#ubuntu-devel 2004-10-11
<jdub> holy cow
* jdub boggles at -users mail last night.
<mdz> jdub: ping?
<mdz> jdub: someone commented on -users that the -users mailman archive is broken, and it looks like they're right
<jdub> mdz: carlos mentioned it too; checking it out.
<Kamion> mdz: gah, we clashed on discover1-data :)
<Kamion> I'll do another upload, I had seven more PCI IDs to add for forcedeth
<elmo_> pcmcia-cs -> ship?  like huh?
<Kamion> elmo_: like yeah
<Kamion> elmo_: hw-detect installs it if you actually have PCMCIA
<bob2> I don't think it's that smart
<bob2> it installed it on my ibook which has no slots
<sivang> who is responsible to the ubuntu-sounds pkg? lamont?
<elmo_> as opposed to what
<Kamion> bob2: bet you have /sys/class/pcmcia_socket/ though
<bob2> Kamion: ah, I do indeed
<sivang> such cool sounds. especially the gnome bootplash sound
<bob2> Kamion: is that a kernel bug?
<Kamion> bob2: go have a long talk with your kernel then ;)
<Kamion> bob2: dunno, could be
<Kamion> bob2: maybe there really are slots internally
<Kamion> sivang: look at the Maintainer: field ...
<sivang> Kamion : oh right..
<bob2> heh, I could belive apple did weird shit like that
<sivang> ah! hooray for Nathanial!
<Kamion> elmo_: anyway, yeah, mdz and I argued this out and agreed this was best, since you so aren't going to upgrade a machine to have PCMCIA when it didn't before
<bob2> are end-users encouraged to file bugs themselves or discuss it on a list first (ie Debian vs Subversion modes)?
<sivang> Kamion : that install went more swiftly than the previous I Had. after I fixed /etc/fstab and excluded from fsck, everything runs fast and sound :-)
<mdz> Kamion: re: discover1-data, I was going to do another upload to sync up with the kernel anyway, thanks
<mdz> Kamion: regarding ntfs resize, how much of a hack is the partman enhancement?
<mdz> Kamion: anything we should look at for Warty?
<Kamion> mdz: hacktastic
<Kamion> mdz: not proven to work yet AFAIK
<elmo_> kamion: I don't understand still - where was it before?
<elmo_> anyway, sorry doesn't matter I can stop being lazy and look myself
<Kamion> elmo_: base
<Kamion> elmo_: it used to be installed on every system, even desktops without PCMCIA
<Kamion> moving it to ship means we can apply detection to it
<Kamion> mdz: anton's hacks often need a certain amount of polishing before they're production-ready :-)
<Kamion> joeyh normally does that ...
<npmccallum> sivang: thanks :)
<mdz> sounds like hoary material
<sivang> npmccallum : you put out some nifty sounds package! Did you make the sounds with a synth or are they gnome's ?
<Kamion> mdz: my inclination at the moment is to wait even though it's a nifty feature
<npmccallum> sivang: mixture of a synth and actual recordings
<Kamion> people can always use partition magic or whatever
<sivang> npmccallum : hand made by you?
<npmccallum> sivang: yes
<sivang> npmccallum : superb :-)
<npmccallum> sivang: thanks, though the phone sound and the card shuffling sound are from gnome.  You can't much improve on them
<sivang> npmccallum : i really like to gnome bootsplash sound. so calming ;)
<npmccallum> sivang: thanks
<sivang> npmccallum : are you a musician at days when you're not hacking ubuntu ? 
<npmccallum> sivang: though I have to say, just about anything would be an improvement on most of the sounds in gnome-audio
<npmccallum> sivang: I'm a musician at night when I'm not hacking during the day :)
<sivang> npmccallum : well, I havn't heared such a nice splash theme in some time now....:)
<npmccallum> sivang: I haven't had so much praise in some time now ;)
<sivang> no, I really like it. as opposed to every single sound theme I checked in the past year on gnome/kde
<sivang> either they were too noisy,
<sivang> or didn't make a difference.
<sivang> KDE's default window close sound is something of a bug material I think :-)
<Kamion> mdz: I'd be happy to deal with #1872, it's not particularly amd64-specific
<mdz> Kamion: you have more than your share of RC bugs already, I think; I'd prefer that you hand amd64 stuff off to tollef so that you can work on other things, unless it's trivial and you're touching that package anyway
<Kamion> mdz: fair enough, discover1-data was to hand that's all :)
<Kamion> well, followed up to that bug asking for more info anyway
<sivang> mdz : I'd like to take some RC bug reproduction and investigation work, if it's possible :) if you have anything you'd wanted someone to look at, please let me know.
<lamont> Kamion: aye.  pri < high.
<lamont> grumbl
<lamont> e
* lamont is reminded how much he hates virtual packages in build-depends
<jdub> can you exclude a file from diff.gz generation?
<jdub> i have a file with bollocks changes that can't be easily cleaned, so i want to ignore it
<Kamion> dpkg-buildpackage -i<regexp>
<Kamion> look at the top of /usr/bin/dpkg-source for the default regexp, you'll need to copy it and append to it; you can put defaults for debuild in ~/.devscripts to avoid figuring out the regexp every time
<lamont> Kamion: if debconf asked all the questions before, does it even run config on a reconfigure?
<Kamion> lamont: config is always run
* lamont expects 'yes'
<lamont> ok.
<lamont> more pondering tonight.  sigh.
<Kamion> debconf does not even consider whether it might have asked all the questions, since in general it can't know that
<lamont> ok
<Kamion> due to config being programmatically arbitrarily complex
* lamont is tired.  almost thinking correctly
<lamont> (forget I asked that...)
<Kamion> mdz: is #1683 really RC? there are probably quite a number of these issues for various languages that need to be looked at in some detail
<Kamion> they've historically been a bit of a nightmare
<lamont> Kamion: do you have a cookbook for rolling i386 install CD's?
* lamont fears he will need to do that to resolve the postfix bugs
<jdub> Kamion: so i can't put smoething in debian/rules?
<lamont> seb128 about?
<Kamion> jdub: rm it in debian/rules clean?
<jdub> i kinda thought that might affect the diff, but it seems the removal will be ignored
<jdub> thanks
<Kamion> lamont: drop in new .deb; edit dists/warty/main/binary-i386/Packages with new Version:, Filename:, MD5sum:, Size:; gzip -c dists/warty/main/binary-i386/Packages > dists/warty/main/binary-i386/Packages.gz; edit dists/warty/Release with new md5sums and sizes for Packages and Packages.gz
<Kamion> lamont: then "mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386", substituting wherever your CD tree is for new-i386
<sivang> Kamion : regarding #1566, i can still use my xphome, although when booting linux i get a CHS warning.
<sivang> Kamion : I used some similar tool to resize my partitions at first, but this was on my first ubuntu install
<Kamion> sivang: after fixing the CHS warning using the directions provided in the bug, if you could try the referenced CD image and verify that it does not make the CHS warning come back, that would be good
<sivang> Kamion : i will, however it didn't damage my fat32 installation, but it'd be better to fix that I guess.
<mdz> jdub: so who needs a nudge to fix the list archive?
<jdub> me
<jdub> nudged already
<jdub> getting to it
<tseng> hah jdub = the man.
<mdz> sivang: everything of severity >= major is considered release-critical
<mdz> sivang: we'd appreciate any help you are willing to provide with those
<mdz> Kamion: we should include a Makefile on the CD which regenerates Packages and Release with apt-ftparchive
<fabbione> morning guys
<bob2> hey fabbione 
<fabbione> hey bob2
<fabbione> 1888 <- notwarty becuase WE know how to backport patches ;) :P
<fabbione> mdz: what do you thing about 1905?
<fabbione> it looks a safe patch to me
<mdz> fabbione: yes, looks safe, feel free to upload it
<fabbione> ok
<fabbione> mdz: samba is up
<fabbione> --- SIGFPE (Floating point exception) @ 0 (0) ---
<fabbione> how bad is this message?
<fabbione> it's the first time i see it
<lamont> Kamion: where does boot.cat come from?
<mdz> fabbione: could be as simple as division by zero
<mdz> if it's randomly occurring, it could be bad
<fabbione> mdz: hmmmm it seems to be reproducible (coming from one user of the new nv driver)
<fabbione> but it's only report.. 
<mdz> brb, reboot
<fabbione> nobody else reported
<fabbione> ok
<lamont> mdz bouncing?
<mdz> rebooting to check more kernel stuff for 1632
<lamont> so why is it that OO says that it's going to print on LETTER, yet the printer asks for A4?
<lamont> a: because the document really wants a4. :-(
* lamont sleeps, to make things clearer.
<fabbione> mdz:
<fabbione>     nvclks = 3; /* lwm -> sync. */
<fabbione>     nvclks += 2; /* fbi bus cycles (1 req + 1 busy) */
<fabbione> the second line here is the one that create that segfault
<mdz> err
<mdz> fabbione: consistently?
<fabbione> compiler error?
<fabbione> yes
<mdz> is nvclks a float?
<fabbione> int
<mdz> are those lines really adjacent, or is there other code between?
<fabbione> exactly as you see them
<mdz> why not nvclks = 5??
<fabbione> no idea..
<mdz> I guess you'll need to look at the disassembly
<fabbione> eh...
<fabbione> if it was on my machine...
<mdz> fabbione: context?
<mdz> is this not with an ubuntu package?
<fabbione> mdz: 1883
<fabbione> mdz: the info are missing because the submitter did post a 1.2MB file
<fabbione> mdz: but it's in the Debian BTS
<mdz> fabbione: if he is using the binary from debian, and you know exactly where it is crashing, you can disassemble the debian binary
<fabbione> mdz: it says in the gdb.txt
<fabbione> it crashes at line 417 of nv_hw.c
<fabbione> that the code i did show you before
<fabbione> but it doesn't happen here
<fabbione> and i use the same driver
<mdz> you're certain that his binaries correspond to your source code?
<mdz> users are sneaky sometimes and will run a different X server :-)
<fabbione> mdz: pretty sure...
<fabbione> but i can check again
<fabbione> how do you suggest to debug?
<fabbione> s/debug/disassemble
<mdz> use gdb
<mdz> disassemble <function> or disassemble <line>
<mdz> or <memory location>
<fabbione> ah so i still need to ask him to do so
<mdz> nah, you can do it on your binary
<mdz> it is the same code
<fabbione> do you know how to read i386 assembly? I know m68k upside down...
<mdz> I can read some
<mdz> enough to find problems usually
<mdz> if you have the gdb output from the user, it should show the exact address of the crash
<mdz> and so you can find the exact instruction
<fabbione> Program received signal SIGFPE, Arithmetic exception.
<fabbione> 0x080e2188 in nv10CalcArbitration (fifo=0xbffffa60, arb=0xbffffa40)
<fabbione>     at nv_hw.c:471
<fabbione> 471     nv_hw.c: Aucun fichier ou rpertoire de ce type.
<fabbione>         in nv_hw.c
<fabbione> what should be the address to look at?
<fabbione> ok got it :-)
<fabbione> 0x080e2188 <nv10CalcArbitration+614>:   idivl  (%ecx)
<mdz> hmm
<mdz> that is of course an integer divide instruction
<mdz> which makes much more sense
<mdz> but would seem to indicate that it is NOT line 471 of nv_hw.c
<mdz> because that is an addition expression
<mdz> fabbione: I'd disassemble nv10CalcArbitration (the whole function, hope it is small) and try to find what it corresponds to in the source
<mdz> pitti: good morning
<pitti> Morning!
<pitti> mdz: I will go for some patch cherrypicking from hal CVS today; according to upstream, this "don't recognize at first plugin" bug is fixed in CVS HEAD
<mdz> oh, nice
<mdz> daniels: ping?
<fabbione> mdz: it's what i am doing now
<fabbione> mdz: and no.. it's not line 417
<fabbione> and that makes me wonder how the hell gdb can believe that's line 417
<fabbione>       us_n = nvclks*1000*1000 / nvclk_freq;/* nvclk latency in us */
<fabbione> found it
<daniels> mdz: pong, just eating lunch
<daniels> mdz: 'sup?
<daniels> fabbione: nvclk_freq == 0?
<fabbione> daniels: yes. there is a bug in static void nv10UpdateArbitrationSettings (
<daniels> fabbione: yay
<daniels> anyoen here familiar with the hig?
<fabbione> MClk can be unitializied and possibly = 0
<fabbione> daniels: ideally static void nvGetClocks(NVPtr pNv, unsigned int *MClk, unsigned int *NVClk)
<fabbione> is the one to check
<fabbione> if somebody can understand the magic behind it :-)
<fabbione> brb
<daniels> fabbione: heh, not I, sorry
<fabbione> re
<fabbione> i think i have a simple fix for it
<fabbione> that code is unreadable
<daniels> jdub: permission to upload http://people.ubuntu.com/~daniels/g-s-m/gnome-system-monitor_2.7.0-0ubuntu2-to-ubuntu3.diff ?
<daniels> jdub: (i can't make the configure changes any smaller -- cdbs insists on re-running autoconf every time you build, even source)
<daniels> jdub: also, right now we can't get any useful errors back from sudo (only 'child exited with error status 1'), so I just hard-coded the error to 'Error (killing process|changing process priority): incorrect password?'
<daniels> jdub: if you have any HIGgy suggestions, please bounce them back my way and I'll fix it up.  i'm new to this whole GNOME thing ;)
<fabbione> mdz: 1889 imho is not major
<pitti> mdz: hmm, cherrypicking CVS patches did not help, but the CVS HEAD version works perfectly
<m_tthew> pitti: no fear, cherry pick the whole shebang ;)
<pitti> mdz: what do you think about the following: I upload the current packages now, package the CVS head version and put that into my unofficial repository?
<fabbione> hey m_tthew 
<m_tthew> fabbione: I don't have full context, but nvglx does not tank X with MGA video
<fabbione> m_tthew: did you manage to test that setup?
<m_tthew> fabbione: I will try with the ATI card asap
<fabbione> m_tthew: ok.. great!
<m_tthew> fabbione: ATI is non-trivial because I have to cannabilize my desktop for the test setup
<m_tthew> fabbione: MGA has no 3d, it is a very old card
<fabbione> m_tthew: doesn't really matter
<daniels> fabbione: if you want, I can test ATI tomororw
<daniels> fabbione: I can start a dist-upgrade now, and then leave, and when I get back tomorrow, try video
<fabbione> daniels: whatever.. if you can good otherwise tought luck
<m_tthew> daniels: that would be helpful, I cannot take my desktop down until saturday.
<m_tthew> fabbione: I will test ATI saturday if no one beats me to it.
<fabbione> m_tthew: thanks
<daniels> fabbione: do you have an updated ati_drv, or do we need the entire server package?
<fabbione> daniels: the problem is not the ati driver
<fabbione> it has been reported that X crashes when nvidia-glx is installed
<daniels> oh
<fabbione> even without using the nvidia driver
<daniels> yeah
<fabbione> so it's not really a question of newer ati driver
<daniels> doesn't it divert away libglcore/libglx?
<fabbione> but as a general mess
<pitti> jdub: what do you think about uploading the utopia crack now?
<daniels> if so, that will break anything that loads them and expects normal libglcore/libglx
<fabbione> daniels: i think so yes
<fabbione> daniels: you should check the package
<fabbione> daniels: but the point is that i can run it ok, like many other people around
<daniels> fabbione: how big is it?
<fabbione> i don't believe all testers have nvidia
<fabbione> what?
<fabbione> the nvidia?
<fabbione> Size: 2815272
<fabbione> that's the -glx
<daniels> hm
<daniels> might download that while I'm in the shower
<daniels> but yeah, if it diverts libglx (which I'm pretty sure it does), we're in deep trouble
<daniels> since it's not going to be the ABI that the other drivers were built with
<daniels> what we need is a wrapper around X that reads the config file and diverts on the fly to whichever one is appropriate ;)
<daniels> brb
<daniels> well, bbiab
<pitti> Everybody get a grip! New uptopia stack coming now! :-)
<m_tthew> tastes like hope
<pitti> m_tthew: It's uploaded, now wait for it to build, then go ahead and beat me up :-)
<mdz> pitti: yes, please do upload the current packages
<mdz> ah, you did
* mdz catches up
<pitti> mdz: yes, since you already agreed to upload the current hal package :-)
<mdz> right
<pitti> mdz: nevertheless, cvs head works even better, but the interdiff is some 8000 lines (due to some refactoring)
<pitti> mdz: I currently run the cvs version, I will put that on my unofficial archive. We can upload it in one or two days if it behaves sanely
* pitti has great fun with closing a bunch of bugs
<jdub> ahr
<daniels> jdub: comments on g-s-m stuff?
<jdub> haven't installed it yet
<jdub> updating...
<daniels> jdub: rad
<jdub> YAY UTOPIA CRACK!
<jdub> pitti: woo :)
<jdub> hrm, not all of it yet
<jdub> daniels: hrm, no g-s-m yet
<pitti> jdub: what's still missing?
<pitti> jdub: these are the packages that needed upgrading
<daniels> jdub: haven't uploaded yet
<daniels> jdub: http://people.no-name-yet.com/~daniels/g-s-m/
<jdub> pitti: don't think they've built yet, i saw your uploads though
<jdub> daniels: 
<jdub> ah
<daniels> jdub: that contains ubuntu3, which uses gksu in a pretty HIGgy way
<pitti> jdub: ah okay, just a matter of time :-)
<daniels> jdub: as per the comment in procdialogs.c, gksu doesn't deliver a useful error message back from sudo, so the error suggests that the password might be wrong
<jdub> oh
<daniels>                 if (type == 0)
<daniels>                         errorMessage = _("Couldn't kill process: incorrect password?");
<daniels>                 else
<daniels>                         errorMessage = _("Couldn't change process priority: incorrect password?");
<daniels> jdub: ok to upload?
<jdub> hold on :)
<daniels> jdub: rad :)
<daniels> mdz: i have a trivial patch to xresprobe to make it respect $TMPDIR -- ok to upload?
<jdub> checking for libgnome-2.0 >= 2.0.0 libgnomeui-2.0 >= 2.0.0 gconf-2.0 >= 1.1.5 libgtop-2.0 >= 2.5.2 libwnck-1.0 >= 2.5.0 gtk+-2.0 >= 2.3.0 libgksuui1.0 >= 0.15.0 libgksu1.2 >= ... Comparison operator but no version after package name 'libgksu1.2' in file '(command line arguments)'
<jdub> ^ daniels 
<jdub> bong
<daniels> jdub: ugh, bong
<daniels> hold on a sec
<jdub> somehow there's an extra I there
<daniels> yeah
<daniels> new version on its way to the same place
<daniels> mdz: http://people.ubuntu.com/~daniels/xresprobe/xresprobe-0.4.9-to-0.4.10.diff
<daniels> jdub: new .diff.gz/.dsc up
<daniels> (and changes, and interdiff, etc, etc)
<jdub> daniels: looks good
<daniels> jdub: rad
<seb128> morning
<daniels> time to head home for dinner
<mdz> daniels: fine by me
<Keybuk> wait!  vicky hasn't returned from lunch yet!  we can't leave the shop floor UNMANNED!
<thom> morning
<seb128> hello thom 
<seb128> daniels: patches in debian/patches for GNOME packages please
<thom> seb128: got anything more you'd like me to test with nautilus? :-)
<seb128> the changes in the diff.gz are a pain
<mdz> fabbione: what is your opinion on #1878?
<seb128> thom: re a bug report ? 
<mdz> seb128: the nautilus-cd-burner thing, I assume
<seb128> I was thinking to that too, but not sure
<seb128> thom: gnome-vfs guy is pretty surprised that gnomevfs-info gives the same result with FAST and SLOW for mime detection
<seb128> are you sure you patched it right ? :)
<seb128> they are thinking to a problem with one or the 2 detections, but since the 2 versions seems to return the right information with gnomevfs-info ...
<fabbione> mdz: we knew that via can't be probed. Either we ban probing in xresprobe or we backport the driver, but the latter won't get enough testing before release
<mdz> fabbione: daniels suggested not only skipping the probe, but forcing vesa. does that seem correct to you?
<fabbione> mdz: hmmmm
<thom> seb128: i'm pretty sure, unless the build does crackful things :-)
<fabbione> mdz: i am not happy to force vesa
<seb128> thom: ok
<fabbione> mdz: i much rather prefer to ask teh resolution question
<fabbione> mdz: we did try already to force vesa if gfx card probe fails and we have seen that it is not good
<seb128> thom: I'll talk again with gnomevfs guys and probably ping you with a small test case after that :)
<thom> seb128: sure it's not nautilus screwing up? :-)
<thom> ok
<seb128> thom: the mime are handled in the gnomevfs level, there is not real reason for nautilus to act in a different way, but I'll check
<thom> fair enough
<mdz> fabbione: so it is only the probe which fails, and the X server running normally should not crash?
<fabbione> mdz: there are 2 bugs in the via drive
<fabbione> 1) it does not store panel information in the bios that means that probing will never be succesful
<fabbione> 2) if probed when X is running it would crash X
<mdz> if skipping the probe means that their X server will still crash, then we should use vesa
<mdz> if it will not crash, we can stay with via
<fabbione> mdz: if we do NOT probe, there is no problem
<fabbione> the 2 bugs above are in case of probe
<mdz> fabbione: ok, then, let's just skip the probe but still use the driver
<fabbione> mdz: that's what it should be already
<fabbione> i explicitly remove the probe ban on the via chipset because daniels told me that xresprobe should take care of it
<fabbione> and xresprobe shouldn't be probing via afaik
<fabbione> so yes. we use the driver, we don't probe and we ask for resolution
<fabbione> that's the best path
<fabbione> and it is the same as like everything else (given a failed probe)
<mdz> fabbione: xresprobe is definitely probing via, that's #1878
<fabbione> the day that we will switch to X.org it will be enough to remove the ban
<fabbione> bah
<fabbione> daniels: that's not what we agreed
<fabbione> well i will write in the bug
<fabbione> done
* Mithrandir wants a 32 bit strace.
* fabbione wants a 64 bit CPU/RAM/MOBO.
<fabbione> mdz: 1911
<fabbione> mdz: afaik new subversion requires new libswig<something>
<fabbione> mdz: should we take a look to a patch?
<mdz> fabbione: I thought in unstable libswig was gone
<mdz> breaking subversion
<fabbione> there was joshk discussing it this morning on d-d
<fabbione> debian has the same version as we have basically
<fabbione> oh well he uploaded .8 but it's not built on i386 yet
<mdz> jdub: what's the status of the list archive inquiry?
<seb128> somebody know why hal 0.2.98 is missing in the archive ?
<seb128> +on i386
<thom> http://people.no-name-yet.com/~lamont/buildLogs/h/hal/0.2.98-1ubuntu3/hal_0.2.98-1ubuntu3_20040930-0909-i386-failed
<thom> python-dbus not new enough
<seb128> http://people.no-name-yet.com/~lamont/buildLogs/h/hal/0.2.98-1ubuntu3/hal_0.2.98-1ubuntu3_20040930-0935-i386-successful
<seb128> too
<thom> dunno then
<thom> give elmo a poke on jabber
<elmo_> it's new
<seb128> why ?
<elmo_> hal-device-manager is a NEW package
<seb128> oh ok
<elmo_> (NEW in katie terms, I'm not shouting at you ;)
<seb128> yes, I was thinking to this NEW :)
<seb128> but since the amd64/ppc binaries are in the archive
<elmo_> i386 build arch: all, and h-d-m is arch: all ...
<elmo_> I've processed it..
<seb128> oh ok
<seb128> thanks elmo_
<Mithrandir> mdz: seems like the kernel hasn't been upgraded, or at least not upgraded to another binary-incompatible one.
<Mithrandir> elmo_: is there any way I could acess the morgue?  I have a fun problem to track down (1854)
<elmo_> Mithrandir: ask me/thom for what you need?  or do you need the whole thing particularly?
<Mithrandir> elmo_: I'd like something like snapshot.d.n to see if I can track it down with a binary search..
<Mithrandir> but given that we don't have that in place, I can try to pull selected debs by hand.
<elmo_> well, you can't have that :P (unless you implement it) but you can have access to the morgue I guess
<elmo_> the rhona dir is date based, but there's no Packages/Sources files like with ssnapshot
<Mithrandir> ok, that's fine; it's a full tree or just the files removed on a certain day?
<elmo_> sec
<elmo_> the latter
<jdub> mdz: meeting atm
<Mithrandir> elmo_: ok, thanks a lot. :)
<elmo_> Mithrandir: copying to rookery:/srv/archive.ubuntu.com/morgue - it'll take a while tho, the IO problems are particularly bad between rookery and jackass for reasons I've yet to track down
<elmo_> it'll also, unhelpfully copy in the wrong order (oldest first)
<Mithrandir> elmo_: ok, no hurry, I should write on my thesis today anyhow. :)
<pitti> mdz: thanks for approving #1509 - nightshift today?
<mdz> pitti: must...sleep...
<fabbione> mdz: 1911 almost done... testing the results right now
<pitti> mdz: mdz.sleep(8*3600)
<mdz> hehe
<mdz> so many bugs remain
<fabbione> mdz: 45 approx.
<mdz> I just found one that lamont forgot to close; that is always nice :-)
<mdz> I count 42
<Kamion> lamont: boot.cat's on the CD already
<fabbione> mdz: 41 in a few secs :PO
<elmo_> Mithrandir: done (somehow)
<fabbione> s/secs/mins/
<Keybuk> did anyone notice that LWN are now carrying Ubuntu Traffic
<fabbione> ah cool
<mdz> I noticed it was linked from distrowatch
<mdz> the LWN issue with the first Ubuntu article just opened to the public today
<mdz> I don't know what to do about #1724
<mdz> (nvidia drivers breaking everything)
<mdz> I don't think it's something that we can fix ourselves
<fabbione> mdz: not without sources ;)
<mdz> downgrading
<fabbione> how long does it take to run that damn test suite
<elmo_> mdz: btw, vanilla 2.6.8-rc2 is working just fine with >= 2GB on emperor, but not with debian style config
<elmo_> err, s/debian/ubuntu/
<mdz> elmo_: mind attaching a copy of the config to the bug?
<mdz> just for giggles
<mdz> maybe I'll try a build with that config and see if it makes a difference for me
<elmo_> it's not even using initrd tho, I mean
<elmo_> but can do, sure
<mdz> initrd doesn't make a difference; it breaks in the non-initrd case too
<elmo_> ok
<fabbione> mdz: i count 39 bugs now
<mdz> fabbione: I just had to import a new one from Debian :-/
<mdz> (possible php4 security issue)
<fabbione> yeah.. that one included
<mdz> I have downgraded a few
<mdz> the pcmcia-cs bug is not RC now, because we only install pcmcia-cs if the hardware is present
<mdz> so downgraded
<mdz> downgraded nvidia breakage
<fabbione> subversion is done
<fabbione> i am waiting katie but the bug is closed
<fabbione> we have approx 14 days to close the others
<fabbione> that's hard
<Kamion> mdz: not getting a whole lot of feedback on this parted thing; just lots of people saying that the preview worked for them
<thom> oh, that php4 one looks joyous
<mdz> Kamion: yeah, I think the original issue was a bit inflated
<Kamion> well, no, I agree it was a major issue
<mdz> well, it was painted as "installing alongside XP fucks the partition table"
<Kamion> I think everybody acknowledged it wasn't broken on all systems; it depends on your BIOS settings and indeed on the make of your BIOS
<mdz> and it seems to be much more narrow than that
<Kamion> it's a system-specific thing, but it's *very* bad on the systems where it's broken
<mdz> maybe the submitter will help
* fabbione goes and crashes in the bed
<mdz> if not, the best we can do is regression-test it
<fabbione> later guys
<mdz> fabbione: good night/afternoon
<fabbione> mdz: yeah just one hour of sleep..
<fabbione> otherwise i will die
<thom> mdz: i'll take the php one
<fabbione> and hopefully i can sleep one hour
<fabbione> :(
<mdz> thom: php security vulnerabilities are the BEST
<elmo_> lol
<thom> *g*
<trukulo> fabbione, good night
<trukulo> fabbione, night?
<trukulo> it has to be midday there
<trukulo> well, sleep well
<thom> mdz: i think your definition of "best" is disimilar to the rest of the world's ;-)
<Keybuk> I used to get excited about PHP security vulnerabilities too
<Keybuk> but you know how it is when the radio just plays the same great song again and again, and suddenly it's no longer great and enough to make you change station?
<mdz> thom: does your X40 power off correctly?
<thom> with laptop-mode, or otherwise?
<thom> (yes in both cases last i checked)
<Mitario> aloha
<Kamion> mdz: even if we don't take the partman ntfsresize support (which apparently works now ...), we should take the ntfstools-udeb and put it on the CD, so that we can point users at it if necessary
<sjoerd> pitti: did you check if the patch i sent to the hal list yesterday fixes your problem
<pitti> sjoerd: not yet, by now I uploaded 0.2.98 proper
<pitti> sjoerd: but I tested today's cvs head, this seems to work; is your patch already included?
<pitti> sjoerd: I already debugged the code to the point you patched away; the last_hotplug_seqnum was nonsense
<sjoerd> pitti: with yesterdays cvs i could still reproduce it here
<jdub> anyone having probs with the server?
<sjoerd> pitti: and it isn't applied yet
<pitti> jdub: sometimes I cannot connect to archive
<jdub> hrm, working now
<jdub> hmm
<pitti> sjoerd: thanks so far. I will wait until David or sb else verifies this, and then upload a new hal version
<sjoerd> pitti: still weird that cvs head fixes it for you though :)
<pitti> sjoerd: I did not test this very extensively, it just worked at the first time after hal restart
<pitti> sjoerd: OTOH, it also seems to work some times with the current hal (0.2.98)
<pitti> sjoerd: so I guess this is sort of a race condition and it is not really fixed in CVS HEAD
<seb128> jdub: do we want the new sound-juicer with some hal love in ?
<pitti> seb128: what does s-j with hal? (being curious :-) )
<sjoerd> pitti: yeah.. it's only triggered if your usb device triggers the first hotplug events and those events come in out of order
<pitti> sjoerd: yesterday I thought it was just a matter of properly initializing this last_hotplug_seqnum
<seb128> pitti: CD detection
<pitti> sjoerd: but if removing the code completely helps, so much the better :-)
<pitti> seb128: ah, thanks
<sjoerd> pitti: see my explaination in that mail :)
<sjoerd> seb128: your need cvs stuff to get sj+hal to compile btw
<pitti> sjoerd: I saw, that's why I want to wait for comments :-) Thanks for your work, though!
<seb128> sjoerd: ?
<seb128> sjoerd: I've a package ready ...
<sjoerd> seb128: 0.5.13 vanilla ?
<seb128> oh no
<seb128> with the fix post release for hal build
<seb128> sorry :)
<sjoerd> hehe ;)
* sjoerd wonders if ross is going to enabled it for debian
<seb128> since it needs hal 0.2.98
<seb128> and debian doesn't have it
<seb128> probably no :p
<sjoerd> seb128: debian has it as soon as it comes out of NEW :)
<seb128> oh, that's why
<seb128> hal-device-manager NEW ?
<sjoerd> yes
<sjoerd> it's been there since sunday
<thom> can people grab http://people.no-name-yet.com/~thom/popularity-contest_1.22ubuntu2_all.deb and run: "/usr/sbin/popularity-contest|/usr/sbin/popcon-upload" please
* T-Bone gets hit by apt-get upgrade failing on "Section" in dpkg-dev
* thom pokes people
<thom> i'm watching the logs you slackers, get to it
<Kamion> thom: s'pose you want this on an Ubuntu machine
<thom> Kamion: it'd be nice, please
<Kamion> damnit, no working Ubuntu system at the moment; /me fires off an install
<thom> heh
<Kamion> welcome to the life of an installer guy; it's just not worth getting too attached to the installs ...
* T-Bone is stuck with a broken Ubuntu, damn
<daniels> seb128: sorry
<daniels> seb128: want me to re-upload?
<seb128> no problem
<seb128> no, that's fine
<elmo_> what webserver log analyzing tools (analog, webalizer, etc.) have people used/do you recommend?
<seb128> daniels:  the changes are pretty easy to get out of the diff for the next upload :) But when you have a bunch of patches mixed here that's a pain
<daniels> fabbione: the two choices are either blanket via->vesa mapping in xserver-xfree86, or via->vesa in discover1-data
<daniels> seb128: yeah, sorry. i thought I looked for debian/patches, but obviously I'm on crack :)
<thom> daniels/seb128/elmo: please test popcon :-)
<Keybuk> so, why don't we ship anacron in Ubuntu?
<elmo_> your not watching MY computer, Big Bro^WThom
<azeem> Big Thom?
* thom chuckles at elmo
<thom> just test it and stop whining, ya bitch :-)
<elmo_> done
<thom> thankee
<thom> seems to work, too
<Kamion> thom: you'll get a weird broken upload from this machine, hope you don't mind, it's a via so installation breaks with the xresprobe bug
<Kamion> thom: did that work?
<daniels> thom: i'm not near an ubuntu machine atm
<daniels> Kamion: can you start X at all -- is it X breaking, or the extra probe breaking (a la i8550?
<daniels> s/8550/855)/
<Kamion> daniels: so just type 'X', you mean?
<thom> Kamion: yep, ta
<daniels> Kamion: startx, yah (assuming you have a halfway valid XF86Config-4 which lists the via driver)
<Kamion> sec
<daniels> arse, something tells me `signfile' won't be installed on suse
<Kamion> daniels: it's kind of hard to tell because it breaks while it's trying to write XF86Config-4 :P
<daniels> Kamion: heh :) you can just copy one out from OH MY GOD
<daniels> (any working system)
<Kamion> I have working systems?
<thom> auckland (archive|cdimage) is doing a GB/min currently. that's awesome
<Kamion> I'll just nobble the xresprobe call
<daniels> this is a jackie chan movie that I think I would made if I smoked a beer bong and then drank all the water.
<daniels> it is the most incredibly bizzare thing I've ever seen in my life, and I've used yast
<daniels> thom: !
<daniels> thom: doesn't that mean we're maxing out our ... what the hell? ... link?
<Kamion> daniels: startx breaks
<daniels> Kamion: huzzah.
<Kamion> oh, oh, no, startx comes back to a prompt
<daniels> Kamion: mind if I quote you on BTS?
<daniels> (oh my god, Jackie Chan in a schoolgirl outfit as Chun-Li)
<Kamion> it's really hard to tell, not sure I'm reproducing everything properly
<Kamion> [drm]  failed to load kernel module "via"
<Kamion> relevant?
<daniels> non-fatal
<daniels> if the driver's that flakey, it deserves to be locked in a room with Lazarus Long
<Kamion> you can have the log file if you like
<daniels> nah, it's OK thanks
<Kamion> but the symptoms of 'startx' are similar until it comes back to a prompt - screen goes blacker, fan pitch rises
<Kamion> yeah, feel free to quote me wherever
<daniels> Kamion: thanks
<Kamion> daniels: do you need the xresprobe debugging stuff mdz suggested?
<Kamion> I'll happily give that a go
<daniels> Kamion: not really; if the driver is total arse under X, then it needs to be blacklisted totally
<Kamion> ok
<Kamion> suppose I should try the other Via machine here ...
<daniels> is that laptop or desktop?
<Kamion> laptop
<daniels> it's probably broken also
<Kamion> I'll chuck the CD in there anyway on the off-chance
* T-Bone wonders if that's the reason why he can't login on gnome since his last update
<Kamion> will take a while, crydee's not the beefiest of boxes
<Kamion> T-Bone: if gdm comes up at all this probably isn't the same problem
<T-Bone> Kamion: on second read yah. If i try to login, it'll segault in session-manager, bringing me back to GDM, and if i try to click on "Session", whatever choice I make (including no choice, just starring at the choice panel) restarts X
<pitti> Gosh, can anybody tell me why gstreamer crashes on reading a file, but does not do so any more if you compile it with debugging symbols? 
<pitti> Hi npmccallum
<daniels> pitti: welcome to a heisenbug :) probably gcc optimising out the file opening code or something to save space
<pitti> daniels: so gcc optimized in a segfault? Nice.
<daniels> Kamion: it's not urgent; as I said, if the driver really is that broken, we shouldn't be using it in X at all, although more data points are always nice (if not essential) :)
<daniels> pitti: file = open("foo", rw); file->stuff();
<daniels> pitti: to file->stuff()
<daniels> pitti: you don't need to waste time on this whole opening the file thing
<T-Bone> lol
<pitti> daniels: thanks. It was only meant as a rhetorical question anyway :-/
<T-Bone> Kamion: what should be my starting point in building an installer for ia64 (assuming I have an archive ready)?
<pitti> daniels: it could be worth a try to compile with symbols, but optimize
<daniels> pitti: -g3 -O2
<T-Bone> pitti: alternatively you can try to compile with symbols, then strip them out ;)
<Kamion> T-Bone: get all the udebs built, backport linux-kernel-di-ia64-2.6 from Debian, try to build debian-installer
<pitti> T-Bone: I don't think that the symbols spoil the show, I think it's the optimization
<T-Bone> pitti: that way you'll be sure of it
<Kamion> T-Bone: I can probably upload a version of debian-installer with a bit of ia64 support, otherwise try to merge the general spirit of i386/amd64/powerpc in Ubuntu debian-installer with the specifics of ia64 in Debian debian-installer
<T-Bone> Kamion: ok. I have a couple of builder issues to solve in the meantime tho, but I'll follow these lines
<npmccallum> pitti: hi :)
<Kamion> T-Bone: just mailed mdz/jdub asking for approval to upload non-risky d-i ia64 changes
<T-Bone> Kamion: thx
<T-Bone> Kamion: i'm stuck with some gcc-3.4 building troubles that i'm currently tweaking to get done, as soon as I can have a working gcc-3.4 i'll be able to bootstrap stage2, aka "warty built on warty".
<T-Bone> the fact is that gcc-3.4 is so damn SLOW to build
<T-Bone> :P
<Mithrandir> you can turn off the tests when debugging
<T-Bone> Mithrandir: ?
* daniels kicks SuSE in the usability bone.
<Keybuk> thom: that kacpid bug does look exactly like what's affecting my laptop
<daniels> 'A new hard disk was detected\nOpen with: kfmclient openURL file:/media/storage/usb-storage-odd-0x0c76-0x0005:0:0:0p1 ?\n[Yes]  [No] '
<Mithrandir> T-Bone: it runs a huge number of compiler tests
<T-Bone> Mithrandir: right, i'm currently parsing the rules* files to find where to disable them
<azeem> you should be able to do so with DEB_BUILD_OPTIONS=nocheck, but that's not implemented yet
* azeem was going to file a bug about that
<Mithrandir> azeem: notest, iirc
<azeem> Mithrandir: last time I checked, gcc doesn't support it
<azeem> maybe I didn't look well enough
<T-Bone> $ grep DEB_BUILD_OPTIONS *
<T-Bone> [varenet@envy ~/build/gcc-3.4-3.4.2/debian] $ 
* T-Bone confirms
<azeem> Mithrandir: the glibc package, cdbs, and automake upstream use 'nocheck' already, so I think that's better than 'notest'
<azeem> eh, automake uses 'check'
<daniels> tv is weird tonight. some documentary about the falklands islands entitled 'fuckland' that featured the words to god save the queen at some point.
* T-Bone has 0 knowledge of the debian way of building GCC, which doesn't ease the process :P
<Mithrandir> set with_check in debian/rules.defs
<T-Bone> Mithrandir: I owe you a beer for that one! ;)
<azeem> Mithrandir: ah, thx
<Mithrandir> T-Bone: where can I collect it? ;)
<T-Bone> Mithrandir: I'll find a way ;)
<T-Bone> Mithrandir: btw, is it normal that when running dpkg-buildpackage, the package rewrites its own control file?
<Mithrandir> not too common, no, but glibc and gcc does it at least.
<Mithrandir> they're kinda special
<Mithrandir> look in debian/control.in/ probably
<Mithrandir> for fragments
<T-Bone> this is pissing me off, cause I have an unmet dependency i'm trying to work around
<azeem> all those packages using type-handling also do this, AFAIK
<Kamion> it's not unknown, linux-kernel-di-* do that too
<T-Bone> i've changed it in the control file, but i guess that it'll be problematic if gcc erase it, when the package will actually be built?
<azeem> I used to do that in one of my library packages to automatically write the correct library package name from the soname in configure.in
<T-Bone> is there a way for me to "properly" change a build dependency?
<Keybuk> T-Bone: edit debian/control or debian/control.in ?
<T-Bone> Keybuk: as i said, debian/control gets overwritten. There's a control.m4 tho.
<Mithrandir> T-Bone: debian/control.m4 for gcc
* T-Bone looks
<T-Bone> Mithrandir: thx! ;)
<Mithrandir> mathias  sick, it seems.
<Mithrandir> using m4.
* T-Bone will have to change version number too, making it look like NMU
* T-Bone fires sbuild and makes some voodoo
<Kamion> daniels: confirmed that the Via C3 laptop locks up too
<daniels> Kamion: huzzah :\
<daniels> vesa it is!
<daniels> mdz: looking at #1897, would this logic be sane -- write out stanza saying '## this file written by dhcp3-client'; then only molest the file if either it doesn't exist, or has that stanza in it?
<daniels> mdz: (or the standard '## OMGDEBCONF' markers or whatever)
<lamont> Kamion: Figured out about boot.cat after asking - took me a minute to realize we were rolling a CD from a CD, rather than virgin plastic
<lamont> thanks
<Kamion> lamont: oh right, yes
<lamont> daniels: gnome-system-tools hates you.
<lamont> pitti: ditto fro nautilus-cd-burner
<daniels> lamont: ?
<daniels> lamont: gnome-system-monitor? seb uploaded g-s-t
<lamont> daniels: path config barfage
<lamont> 1295     Sep 30 Daniel Stone    (  44) Accepted gnome-system-monitor 2.7.0-0ubun
<pitti> lamont: what's wrong with ncb? I'm just following #ubuntu-meeting, I did not listen
<lamont> same issue.
<lamont> may just be bad build-deps - I'll toss them back into the fray
<lamont> we'll see how they don on retry
<daniels> lamont: argh! thankyou.
<daniels> lamont: g-s-m is missing b-d on libgksu1.2-dev/libgksuui1.0-dev
<daniels> did them in one tree, forgot to copy them over to the other
<daniels> lamont: i'll upload to fix and also move the patch to debian/patches in a bit; thanks for the heads-up
<seb128> :)
<lamont> daniels: np
<seb128> what's the problem with n-c-b ?
<seb128> I'm going to do an upload, I've a patch to fix a reported bug
<pitti> lamont: oh, it did not build?
<lamont> pitti: no.
<lamont> seb128: checking for glib-2.0 >= 2.4.0 libgnome-2.0 >= 2.0.0 gtk+-2.0 >= 2.4.0 gnome-vfs-2.0 >= 2.1.3.1 libglade-2.0 >= 2.0.0 libgnomeui-2.0 >= 2.0.0 hal >= 0.2.98... Requested 'hal >= 0.2.98' but version of hal is 0.2.92
<seb128> ok
<seb128> will upgrade the build-dep
<seb128> thanks
<pitti> lamont: I uploaded hal at the same time; a simple rebuild should work
<lamont> pitti: yeah
<lamont> I tossed them back in the pond, see what we catch this time.. :-)
<pitti> seb128,lamont: seb, if you upload a new ncb anyway, the next build should just work
<seb128> no a reason to have bad depends
<lamont> daniels: but yours failed. :-)
<lamont> seb128: true
<daniels> heh :)
<daniels> lamont: mine will always fail, unless you pre-seed it with the two libraries
<lamont> daniels: yeah.  But you said that _after_ I did the 6 give-backs.. :-)
<daniels> lamont: heh
* T-Bone pokes lamont
<lamont> enlightenment uploaded, btw
<amu> successfully upgraded a ppc from unstable to warty, gnome 2.8 looks nice 
<sabdfl> mjg59: what's the status of swsuspend in k2.6 these days?
<Keybuk> sabdfl: to disk generally works, to memory works on a select few laptops, standby generally works aiui.
<lamont> Kamion: still about?
<Kamion> lamont: sure
<lamont> is there a way to ask debconf if it would ask a question, or just looking at the return from input?
<Mithrandir> look at the seen flag?
<lamont> I'm thinking of noticing that things are bad in the first config run, and deferring questions that weren't asked until run 2 (where they still won't be asked, but the default value will then be correct...)
<lamont> Kamion: and could I get your debootstrap/whatever change (seen flag)?
<Kamion> lamont: bug #1781
<Kamion> what I still want to know is *why* are things bad in the first run?
<lamont> Kamion: because the defaults are based on system state, not hard coded.
<Kamion> mdz: mind if I upload the debootstrap half of #1781? it's harmless on its own and will make testing easier
<lamont> and said state isn't there...
<Kamion> lamont: system state *should* be sane at that point though
<lamont> uid 1000 isn't created by the first run, so we decide to use 'NONE' for the default.
<Kamion> aha!
<Kamion> right, that explains a lot
<lamont> so I need to decide to do that one over.. :-)
<lamont> and then I'll calculate a good default, and we still won't actually ask the user, and life is good.
<Kamion> mdz: approval to restore mta configuration step to base-config based on what lamont just said?
<Kamion> (won't introduce a new question, just a dpkg-reconfigure)
<lamont> Kamion: alternatively, the same code that adds uid 1000 to sudoers could add the root alias and run newaliases...
<Kamion> that's possible too, although would prefer not to duplicate code if possible
<lamont> actually, my code is based on _not_ finding a root alias in the map, and picking a default, whereas the baseconfig code would be just 'add this user'
<Kamion> I guess it would be less complex
<Kamion> don't care really, recommend something and assign a bug to me :)
<lamont> ok.
<Kamion> npmccallum: what do the diffs look like for those packages?
<lamont> Kamion: you getting close to bedtime, or want somethign soon?
<Kamion> lamont: it's 19:30 here
<npmccallum> Kamion: same stuff as was happening with ssh, et al
<Kamion> I might be getting close to pubtime :)
<Kamion> npmccallum: which languages though?
<Kamion> never mind, I guess I can check
<lamont> doh
<npmccallum> Kamion: I'll look, I have diffs
<lamont> Kamion: I'll get you what I think should work sometime today, and try to get a patch together tomorrow morning.
<lamont> but I need to go help my wife with some precon crap today before we head down there tonight.
<npmccallum> Kamion: fr, he, nn, tr, id at first glance
<sivang> lamont : any help needed with 'he' ?
<Mithrandir> npmccallum: I can look at nn
<Mithrandir> it's my least-favorite kind of norwegian, but I do it ok-ish.
<lamont> sivang: he?
<sivang> ah sorry, that was directed to someone else.
<sivang> npmccallum : he = hebrew? ;)
* lamont wanders off for a while.  cell phone still works.
<npmccallum> Mithrandir, sivang: the bug is here -- https://bugzilla.ubuntu.com/show_bug.cgi?id=1329
<Kamion> npmccallum: will look, might just be package-specific
* sivang needs to resync his cable modem. the net just got stuck!
<Mithrandir> npmccallum: which are the exact packages that break?
<npmccallum> Mithrandir: its all listed in the bug
<Kamion> npmccallum: the only reason exim4 breaks is because the last upload was an Ubuntu upload built with the old po-debconf
<npmccallum> Kamion: howto fix then?
<Kamion> don't
<Kamion> the exim4 change restores things to the correct state of affairs
<Kamion> let's look at mgetty, that seems different
<Kamion> I can't reproduce any problem with mgetty ...
<npmccallum> hrm... all I changed was the initscript and the changelog
<Kamion> could you attach the debdiff to the bug?
<npmccallum> sure thing
<Kamion> ta
<npmccallum> Kamion: there you go
<Kamion> npmccallum: those changes aren't a problem, closing, you can upload the source package like that safely
<Kamion> it's normal for po-debconf to fiddle with .po files, sometimes when timestamps change and things; the Debian maintainer will probably pick up the same change eventually
<npmccallum> Kamion: ok, great
<npmccallum> Kamion: I'm not great with translation stuff, thanks for helping!
<Kamion> npmccallum: the thing to watch out for is when msgstrs change encoding and stuff, then it's worth paying some attention to make sure it's sane
<Kamion> no worries, po-debconf is ... eccentric sometimes
<seb128> lamont: any news about 1123 ? I've a friend who have the problem right now
<lamont> seb128: that'll get fixed with what I'm giving kamion..
<seb128> ok
<lamont> meanwhile, as root: newaliases
<seb128> any workaround for people having the problem right now ?
<seb128> ok, thanls
<seb128> thanks
<lamont> Kamion: does sounder 9 have the 2nd postfix config?
<Kamion> 2nd?
<Kamion> oh
<Kamion> no
<lamont> ok
<Kamion> npmccallum: with regard to po-debconf:
<Kamion> <joeyh> debconf-updatepo... also known as "I'm feeling unproductive today.
<Kamion>         Please give me a huge diff to check in"
<Kamion> :-)
<npmccallum> lol
<lamont> heh
<mdz> morning
<lamont> morning mdz
<seb128> hello mdz
* lamont prepares to head off with his wife to do precon crap and then to the convention.
<lamont> wifely one is now ready.  I'm gone.
<Kamion> mdz: hm, does your changing the state of #1606 to PENDINGUPLOAD mean you've uploaded it?
<sivang> lamont : what convention?
<Kamion> mdz: approval for last diff sent to #1781?
<Kamion> pub time
<mdz> Kamion: yes
<Kamion> good, will upload later tonight
<thom> mdz: have you laughed at^W^Wapproved my python script for popcon yet? :-)
<pitti> Hi again!
<mjg59> sabdfl: It's got the best chance of working of any suspend mechanism, at the moment
<mjg59> The 2.6 implementation is pretty solid on the hardware it works on. It's fairly slow, though.
<sivang> mjg59v : what steps are needed to enable it onto a already installed ubuntu laptop system?
<sivang> mjg59 : just install the package?
<mjg59> sivang: Heh. I'd have a better idea if I had an ubuntu laptop system :)
<mjg59> In principle, echo -n 4 >/proc/acpi/sleep
<thom> kernel patch too, no? (i've no idea what we have and don't have past standard 2.6.8.1 + latest stable acpi)
<npmccallum> thom: I don't think swsusp is in the kernel
<mjg59> swsusp is part of the standard kernel.org kernel - I don't know if we build it, though
<mjg59> There's probably no harm in doing so...
<thom> grep -r SUSP /boot/config-2.6.8.1-3-amd64-k8
<thom> # CONFIG_SOFTWARE_SUSPEND is not set
<sivang> mjg59 : the support is completely kernlish? no user mode utils?
<npmccallum> thom: should we file a bug to get it turned on?
<thom> npmccallum: i'd prefer not for warty at this point
<thom> we can't support it, really
<npmccallum> thom: we can file a bug now with target milestone for hoary (thats what I was referring to)
<thom> oh, sure
<thom> i think there is one alreayd
<npmccallum> ok, cool
<npmccallum> the bug could be more general too, "Suspend doesn't work" :)
<mdz> thom: yes, I did
<sladen> *** the proxy in front of www.ubuntulinux.org appears to be dead ***
<sladen> elmo: thom: mdz:
<Mithrandir> sladen: we're aware of it and working on it.
* ..[topic/#ubuntu-devel:sladen] : Ubuntu development -- general discussion on #ubuntu || known issue: www.ubuntulinux.org currently down
#ubuntu-devel 2004-10-12
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu
<T-Bone> gack
<T-Bone> missed the community meeting as it seems...
<T-Bone> mako: ping?
<azeem> T-Bone: mako sent minutes to ubuntu-devel
<T-Bone> azeem: i've read them and have questions
<azeem> ah :)
<T-Bone> the first one being "how come i missed it? Where was it advertised?"
<T-Bone> +s
<T-Bone> the other one concerns the "IA64 Port Team"
* T-Bone is currently bootstraping "stage2" on ia64
<Mithrandir> T-Bone: I wouldn't really worry too much about that you missed the CC meeting; there's another one in two weeks and the port teams are a bit fuzzy still. :)
<T-Bone> Mithrandir: k. Still i missed what was said there, and it's stupid since should have I been aware of such a meeting, i could easily have intended it
<mako> T-Bone: salut
<T-Bone> mako: Dewd!
* mako took an Official Ubuntu Nap
<T-Bone> mako: long time no see!
<mako> the nap wasn't that long :)
<Mithrandir> T-Bone: mako will post the log and summary somewhere. :)
<mako> Mithrandir: *so* ahead of you :)
<T-Bone> lol
<mako> Mithrandir: that went out pre-nap
<mako> T-Bone: in answer to your question: this was the first meeting and it was a bit disorganized
<Mithrandir> mako: ok. :)
<mako> T-Bone: it was actualy scheduled for a couple days ago and we missed it entirely
<T-Bone> mako: disorganized, say you? How surprising! ;^)
<mako> T-Bone: so the new time was sort of put together last minute
<T-Bone> okay
<mako> T-Bone: IRT the ia64 port, follow up to the list
<mako> T-Bone: not much was decided about the that team/port except that we confirmed that we want one :)
<T-Bone> mako: lol, we have one! ;^)
* T-Bone ducks!
<mako> oh, then great! :)
<mako> life is good
* T-Bone wonders whether one guy is a team on his own ;^)
<mako> he might be a team leader :)
<T-Bone> lol
<mako> i suppose he would have a hard time *not* being a team leader
<T-Bone> 'leading himself'. Right, sounds good to me ;)
<T-Bone> mako: seems i missed you in europe lately, as lamont told me... Will you be around again one of these days?
<mako> T-Bone: yep, i'll be back in december if not before
<T-Bone> mako: cool, headed where?
<mako> T-Bone: not sure, maybe spain
<mako> i was in uk + germany last time
<T-Bone> mako: ok!
<mako> i think there's a good chance we can meet up this next time :)
<T-Bone> mako: cool, i'll stay tuned! ;)
* T-Bone curses perl, still not building
<T-Bone> okay, gotcha
<T-Bone> debian has some patch for ia64 as it seems
* mako nods
<T-Bone> guess i have no choice but to use them
<T-Bone> maybe someone should consider pushing this patchset into ubuntu, if it actually solves my troubles
* lamont peeks his head in for about 2 seconds before really running away for the weekend
<T-Bone> which i'll be able to tell in ~5mn
<T-Bone> lamont: got gcc-3.4 ready. Perl failed again but i think i have a fix
<lamont> T-Bone: cool.
<T-Bone> i'm awaiting for it to succeed, hopefully. Then i'll debootstrap a stage2 clean chroot. I hope it'll work at once, if you're already away ;)
<lamont> since ia64 won't be there for warty, we can diverge slightly with arch-specific fixes and the like, as long as we know what we did...
<T-Bone> lamont: you said i can get rid of the --exclude=lsb-base, correct?
<lamont> I hope to get online from the hotel throughout the weekend, but not sure how things'll go on that fornt.
<T-Bone> lamont: i just fetched perl_5.8.4-2.3 from debian
<lamont> front, even
<lamont> that works
<lamont> probably shouldn't exclude lsb-base - it got added to the warty bootstrap list for a reason...
<T-Bone> lamont: i'll be online throughout the whole weekend hopefully, trying to achieve a full stage2 build
<lamont> cool
<lamont> will poke you if I get online.
<lamont> tonight is going to be hell, followed by some sleep in the morning, I hope.
<T-Bone> about to pass critical section
<T-Bone> YATTA!
<T-Bone> build is still running!
<lamont> wooohoooo!!
<T-Bone> YEeeeheeEE ;))
<lamont> build of?
<T-Bone> perl!
<mdz> elmo: ping?
<T-Bone> lamont: last but not least: hppa stage1 is over!
<T-Bone> lamont: with _much less failures_ than ia64, so bootstraping stage2 will actually be 34sY! ;)
<lamont> heh
<T-Bone> soooooo cool
<T-Bone> lamont: aside from the installer, it looks like we'll have hppa as well ;)
<mako> awesome
* T-Bone bows ;)
<T-Bone> (and grins! ;)
* lamont grumbles at t-bone for stealing his thunder. :-)
<T-Bone> Niarh Niarh Niarh
* T-Bone laughs evilishly ;^)
* lamont waits for sounder 9 to burn to CD, decides that maybe he wants a CDRW in addition to the 4x dvd drive, because 4x is_SLOW_.
<T-Bone> lamont: side note: i think we've also proven that hppa is stable SMP ;)
<lamont> woohoo!!
<mako> lamont: my 4x just died finally which means i get a new one
<mako> which mean i get a dvd :)
<mako> i have no removeable media
<mako> both my cd drivers AND my usb keychain died at once
<T-Bone> ouch :P
<mako> T-Bone: kind of.. it's not actually that big a deal :)
<lamont> mako: why did you pour water on them, I wonder???
<mako> removeable media isn't really that important
<mako> except when things break
<T-Bone> lamont: lol, bad bad you ;)
<T-Bone> lamont: http://gropaf.esiee.fr/~varenet/stage1 - gcc-3.4, alsa-lib, util-linux and openldap2 missing, build in progress
<lamont> nice.  Gotta run, before I get killed.  Have to buy a tool or 3 at Home Depot (only place open this late), and finish plumbing at least most of the &*%)^ van.
<T-Bone> lamont: bummer
<T-Bone> Failed 35 test scripts out of 840, 95.83% okay.
<T-Bone> make[3] : *** [_test_tty]  Error 1
<T-Bone> make[3] : Leaving directory `/build/varenet/perl-5.8.4'
<T-Bone> lamont: i guess i shall override this?
<azeem> T-Bone: actually, I got this result when I built -2.3/unstable today on i386 as well
<azeem> so I'm not sure who's to blame
<T-Bone> azeem: ah. Maybe i should try -2.2 then
<T-Bone> but it doesn't look like big deal to me
* lamont wonders how well warty's perl would do on current warty...
<azeem> well, -2.3 built fine on most buildds
<lamont> anyway, later.
<T-Bone> lamont: see ya
<T-Bone> azeem: what would you recommend then?
<azeem> no idea :(
<azeem> I mean, not much has changed between -2.2 and -2.3, AFAIK
* T-Bone looks at ia64 buildd
<azeem> but perhaps you could try to build that
<azeem> T-Bone: you don't get these 'Warning: Setting locale failed' thingies by accident, do you?
<T-Bone> All tests successful.
<T-Bone> azeem: kidding? Logs are flooded with those
<azeem> looking at my own log, it seems this is the culprit
<T-Bone> -2.3 did build on caballero
<azeem> some tests include that in their check of the test output, and fail
<T-Bone> azeem: damn! locale would harm perl?
<T-Bone> ouch
<T-Bone> bummer
* T-Bone wonders how to fix those
<azeem> T-Bone: you can build perl without running the test by exporting DEB_BUILD_OPTIONS=x-perl-notest
<T-Bone> azeem: would that work with sbuild?
<azeem> if you export it prior to running sbuild, yes
<T-Bone> ok
<T-Bone> let's try
<azeem> I did the same for other reasons today
<T-Bone> it's a 15' build
<azeem> lucky you, it was 1:50:48 here :)
<T-Bone> lol
<T-Bone> i ought to confess that these sweet boxes do rock hell ;)
<azeem> well, it also just took 12' on my centrino notebook
<T-Bone> hehe
<azeem> the other one was a mobile Celeron 400...
<T-Bone> lol
<Mithrandir> mdz: I _really_ doubt 1221 is amd64 specific; I'll have to check when I get to the university tomorrow, but here, it goes away if I tell nautilus to not look at the magic inside the file.  Or, the magic handling routine is broken
* jdub chuckles at the gentoo forum that keybuk linked to
<jdub> good lord
<jdub> "noticeably faster!"
<mdz> jdub: building things with -pipe will make your computer run faster
<tseng> -funroll-loops used to be in the gentoo release engineering profile
<tseng> i kicked and screamed for a good bit.
<Mithrandir> tseng: so we can't mock you for that any more?
<tseng> Mithrandir: nope.
<jdub> fixed mail archives coming right up
<tseng> we got rid of that crap months ago
<jdub> tseng: as soon as that terrible website went up? ;-)
<tseng> jdub: no long before
<tseng> that website is so bogus.
<tseng> i could do the same thing for ubuntu users
<tseng> or a much better one about fedora.
<jdub> heh
<tseng> as long as there is free support, there will be idiots crying for help or making ridiculous comments
<tseng> has nothing to do with gentoo
<jdub> tseng: you have to admit, gentoo does provide all the ammunition for serious google-archived life embarrassment
<chrisa> Gentoo just needs a page on the website that says "emerge != compiling by hand. Watching text scroll != compiling by hand" in huge point
<jdub> or perhaps, "compiling software yourself is pointless" :)
<tseng> jdub: hah we provide a forum for the uniformed mind of the world to unite into one festering cespool of nonsense
<tseng> ive always ignored it, but im getting tired of some developers/politics as well
<tseng> ubuntu is so fresh and so clean
<Mithrandir> hope we can keep it that way.. it will be challenging at times.
<tseng> already collecting a bunch of pretty low IQ's in #ubuntu
<tseng> but the development team is top-notch
<Mithrandir> one will always have some users who need a lot of help and guidance and are annoying as well, especially if you aim for a low new user barrier.
<tseng> alot of first time irc action happening as well.
<tseng> or just folks lacking manners
<Mithrandir> I like the fact that ubuntu actually has a code of conduct and you will be told off for breaking it.
<tseng> hm
<Mithrandir> which goes for users as well as developers
<T-Bone> 4AM, high time to go offline. See ya
<jdub> amazing how quickly people stop whining when you point out that they can write patches
<tseng> jdub for the win
<jdub> hey
<jdub> who's got latest packages
<jdub> and a usb key
<jdub> ?
<tseng> me
<jdub> can you stick in the key
<jdub> copy something to it
<jdub> and pull it out?
<tseng> well
<jdub> no unmounting
<tseng> hal is seg'ing
<jdub> oh
<tseng> --- SIGCHLD (Child exited) @ 0 (0) ---
<tseng> doesnt print anything just returns
<tseng> doesnt start.
<jdub> ok
<jdub> new specification
<jdub> who has the latest packages, a usb key, and a working hal? :)
<mdz> jdub: I do, more or less
<mdz> not a key, but a usb storage device
<jdub> stick in, copy, pull out
<tseng> :P
<jdub> then check to see if it was written correctly
<mdz> copy something onto it or off of it?
<jdub> onto it
<mdz> testing
<mdz> gzip: mythconverg.mysql.gz: unexpected end of file
<mdz> well that's not very nice
<mdz> hmm
<mdz> even though it's mounted with the sync option
<mdz> if I write something to it, and then sync it later, there's activity
<jdub> yeah
<mdz> that sucks
<jdub> not good :|
<mdz> sync seemed so promising
<mdz>        Some  Linux file systems dont support -o sync and -o dirsync (the ext2
<mdz>        and ext3 file systems do support synchronous updates (a  la  BSD)  when
<mdz>        mounted with the sync option).
<mdz> wanna bet vfat doesn't support it?
<mdz> http://seclists.org/lists/linux-kernel/2002/Oct/1256.html
<mdz> "You are right. The fatfs just ignore the sync flag."
<jdub> ugh
<mdz> it's so sweet for read-only though :-)
* jdub just reformatted ext2 -> fine ;)
<jdub> i'm sure this has worked for me before...
<chrisa> jdub: Still have the url to that thread keybuk linked?
<jdub> no one answered this: http://seclists.org/lists/linux-kernel/2002/Oct/1496.html
<jdub> chrisa: it's in his blog
* chrisa checks planet
<bob2> odd
<jdub> there are millions of people using sync with vfat and don't know that it doesn't support it...
<chrisa> wow, someone said zsh loads faster
<chrisa> I quit
<mdz> jdub: bounty?
<jdub> mdz: herbert?
<mdz> maybe
<fabbione> morning guys
<bob2> jdub: fyi, joshk says the gpdf uploaded to unstable recently has pdf 1.3 support
<fabbione> mdz: permission to upload mdadm to fix 1916.
<fabbione> http://people.ubuntulinux.org/patches/mdadm.274208.diff
<fabbione> jdub: ^^
<mdz> fabbione: wouldn't it be simpler to source the file?
<mdz> is '=' a valid character in an email address?
<fabbione> not that i am aware of
<fabbione> but it could be
<fabbione> i can source the file.. yes
<fabbione> that's a good catch
<mdz> I found some dupes in the RC bug list
<mdz> and also I think my highmem problem might be bad hardware
<mdz> so a couple fewer bugs now
<fabbione> mdz: new patch is up
<mdz> fabbione: beautiful
<mdz> upload when ready
<fabbione> roger :-)
<mdz> this MIB bug, I am not sure if it affects warty
<fabbione> mdz: right a sec :-)
<mdz> ah, I understand
<mdz> it's NOTWARTY
<mdz> upstream modfied the MIB, and upstream has backed out their own patch
<fabbione> ok mdadm is up
<fabbione> i count 35 RC bugs
<mdz> yes
<mdz> I think it may be time to start using critical for truly RC issues
<fabbione> yup
<fabbione> daniels: ping
<fabbione> mdz: 1878 again
<fabbione> if the driver is so crappy we should consider a backport
<fabbione> i really really really don't want to go for vesa
<fabbione> otherwise we need to blacklist the module both in X and in xresprobe.
<fabbione> if there is a via card, prompt a warning and ask for the driver to use.
<fabbione> that means that at a later stage i need ban again both via and vesa from the probin
<fabbione> probing even
<fabbione> actually....
<fabbione> there is only one fix between the via driver we ship and the X.org one
<fabbione> that is related accessing the via_bios
<fabbione> nothing more than that
<fabbione> +    if ((pBIOSInfo->Chipset == VIA_KM400) && !(tmp & VIA_DEVICE_LCD)) {
<fabbione> that's it
<fabbione> Treenaks: you around?
<pitti> Morning guys!
<fabbione> hey pitti
<pitti> Hi fabbione! 
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 35 RC bugs to go
<pitti> fabbione: hmm, on my search list are only 25?
<fabbione> pitti: add NEEDINFO and PEND
<pitti> fabbione: all critical, blocker, and major bugs
<pitti> fabbione: ah
<fabbione> that are hidden from the default search
<pitti> fabbione: now I've got 37 :-(
<fabbione> -2
<fabbione> 2 of them are for the websites
<mdz> gah
<mdz> why are my keybindings broken now?
<mdz> I was testing that xkb stuff earlier
<mdz> hmm, something with the gnome keyboard preferences
<mdz> using setxkbmap cleared it up
<fabbione> Kamion: are you aware of 1711?
<seb128> morning
<fabbione> hey seb128 
<seb128> hello fabbione 
<fabbione> seb128: FYI i can't reproduce 1943 here
<seb128> me neither
<fabbione> seb128: must be mdz faults ;)
<seb128> yeah :)
<mdz> easily reproduced here
<mdz> modprobe -r snd-intel8x0m, log out, log in
<mdz> s/8x0m/8x0/
<mdz> only tried with one system, but several people on ubuntu-users and in bugzilla have experienced it
<seb128> I've a box without any soundcard and no such problem on it
<fabbione> mdz: can you reproduce it if you also modprobe -r snd_pcm_oss ?
<pitti> Hi seb128
<fabbione> because i always removed all modules
<fabbione> not a portion of them
<mdz> I'll check
<fabbione> i have the same chipset here
<mdz> testing live CD right now
<fabbione> testing that too
<fabbione> here it just take a bit longer to login
<fabbione> but it works
* fabbione needs to go and get the keys of the house
<fabbione> later guys
* justdave changes the default query
<Mithrandir> seb128: 1221; SLOW does make a difference -- does that help you track it down?
<seb128> sure
<seb128> thom said it didn't
<seb128> what's gnomevfs-info result with and without SLOW ?
* seb128 kicks thom :p
<Mithrandir> with it's the correct, without it's application/x-arc
<seb128> ok thanks
<thom> it's been right for me all the way through
<thom> (for gnomevfs-info)
<seb128> Mithrandir: I'll ping gnomevfs guys with that, should help
<seb128> thanks
<Mithrandir> thom: very weird, then.
<thom> yeah :(
<Mithrandir> seb128: if I patch the SLOW support of out libgnomevfs alltogether, nautilus DTRT
<seb128> yes, gnomevfs a 2 types of detection
<seb128> the one used by nautilus (the fast one) has a problem apparently
<Mithrandir> no, the other way around.
<Mithrandir> the slow one is fucked.
<seb128> <Mithrandir> with it's the correct, without it's application/x-arc
<seb128> with SLOW it's correct you said
<Mithrandir> MIME type         : application/x-arc
<Mithrandir> that's with slow.
<seb128> ok
<seb128> so the slow is broken :)
<mdz> fabbione: I don't understand why #1951 is invalid
<Mithrandir> MIME type         : application/x-cd-image
<Mithrandir> that's without.
<seb128> ok, thanks
<mdz> fabbione: can't it be handled like alternatives?
<mdz> seb128: do you know why it starts correct, and then suddenly changes?
<Mithrandir> seb128: I think it's something in the xdg* functions, but I couldn't track it down.
<seb128> Mithrandir: I'll ping gnomevfs guys (they should have some ideas on this) and let you know
<seb128> mdz: you're speaking about .. ?
<mdz> seb128: the x-arc/x-cd-image thing
<mdz> I commented on the bug
<seb128> oh yes
<Mithrandir> mdz: it uses fast method first, then slow
<Mithrandir> and the slow one is broken.
<seb128> when you open a dir it just use the extensions
<seb128> when you open a file it does magic mime detection
<seb128> that's the slow/fast methods
<seb128> apparently the slow one has a problem
<mdz> ah
<mdz> and the command-line uses fast?
<seb128> yes
<mdz> I see
<mjg59> Somebody probably ought to steal http://fedora.redhat.com/projects/config-tools/redhat-config-soundcard.html
<bob2> is that using ALSA?
<thom> bob2: yeah
<bob2> hm, seems the defaults work for most everyone...
<thom> until you have two soundcards
<pitti> mdz: what do you think about #1956? Shall we allow to execute files on removable media?
<pitti> mdz: some people might store programs on USB drives, and we cannot prevent that they shoot themselves in the foot anyway
<mdz> what does a "crippled" mouse pointer look like?
<mdz> pitti: I think that #1956 is a Hoary problem
<mdz> pitti: we disable the autorun feature by default anyway
<pitti> mdz: so you want to leave 'noexec' for Warty now?
<mdz> pitti: I don't think it matters very much for warty either way
<mdz> happy mailman day
<thom> october already? damn.
<daniels> mdz: every day is mailman day when you're the moderator for like ten fd.o lists
<thom> elmo_: marnin'
<elmo_> morning
<daniels> mdz: stupid feature request?
<mdz> daniels: ?
<fabbione> mdz: no, because it's not really an alternative
<daniels> mdz: is it worth enabling optical out per default on via cards?
<daniels> i don't know how many people actually use it; all I know is that I haven't used the analogue output, ever
<mdz> daniels: via audio devices, I assume?
<mdz> fabbione: but shouldn't it act like one?
<mdz> if the default X server is XFree86, and then you install -dbg, and then remove it, it seems logical for it to go back to XFree86
<daniels> mdz: yeah, via82xx
<fabbione> mdz: not really. you can have other Xservers running.
<fabbione> mdz: s/running/installed
<mdz> fabbione: /bin/true is not an X server :-)
<fabbione> mdz: i know :-)
<daniels> yes, but presumably if you uninstall -dbg, and the only other current owner is -xfree86, falling back to -xfree86 would be sane?
<fabbione> actually you are not supposed to be running -dbg at all
<fabbione> if not for debugging reasons
<fabbione> i don't completely disagree but how would you define XserverS priority in a "/etc/alternatives/" implementation?
<fabbione> you can't really.. either you ask (and in prerm you might not be able to do so at all)
<fabbione> or you guess
<fabbione> the latter is insane
<fabbione> considering that there might be a bunch of different Xservers
<fabbione> even not registered ones
<mdz> save it and restore it if you want
<mdz> but it should not point to /bin/true when there is an X server installed
<fabbione> mdz: that will be for hoary
<fabbione> but we will use a differnt approach to this stuff
<Mithrandir> seb128: around?
<seb128> yes
<Mithrandir> seb128: are you sure the mime entry for x-arc is correct?
<seb128> which entry ?
<Mithrandir> the entry in /usr/share/mime/magic
<seb128> no
<seb128> but it works on i386
<Mithrandir> it might work by accident on i386
<seb128> hum
<seb128> do you think that the entry is wrong ?
<Mithrandir> I get the mask to be 0x80 0x80 0xff 0xff; the value is (when you swap it) 0x1a 0x08 0x00 0x00
<Mithrandir> if you & those two, you get 0x00 0x00 0x00 0x00
<mdz> I don't understand the format of that file
<Mithrandir> mdz: look at /usr/share/mime/packages/freedesktop.org.xml instead?
<mdz> ah, thanks
<Mithrandir> I don't see how that can _ever_ work.
<mdz> do we ship software which actually reads .arc?
<Mithrandir> I doubt it.
<mdz> pitti: did you see the bad news about vfat and sync?
<daniels> isn't arc patent-encumbered?
<mdz> lha is in Debian non-free
<pitti> mdz: was it on the mailing list?
<Mithrandir> seb128: doesn't work on my debian install if I change the magic file. (i386)
<seb128> ok, so the magic is right ?
<Mithrandir> give me two secs
<Mithrandir> interesting, the amd64 mime file is b0rken
<Mithrandir> which means either mime-support or shared-mime-info is b0rken
<mdz> pitti: no, jdub and I discussed it on IRC, and he was supposed to file a bug for you
<mdz> pitti: the short version: the 'sync' mount option has no effect for vfat filesystems
* pitti cries out loudly
<pitti> mdz: the funny thing is that it _seems_ to work on my USB stick?
<mdz> pitti: I tested it, and I read the code
<mdz> it is a noop
<mdz> I get truncated and/or corrupted files when I yank the device after a write
<mdz> and if I sync(1), there is cached data that is flushed
<pitti> mdz: with sync, copy operations last way longer and umount does not block; without sync, copy is fast and umount does not block; so it seems that there is at least a noticeable difference
<pitti> ugh
<fabbione> AHA
<fabbione> mdz: the new via developers already provides a diff to stick in debian/patches
<pitti> mdz: you read the code, do you think that it can be fixed easily?
<fabbione> because they develop in debian
<fabbione> mdz: merge = 0 time
<mdz> pitti: it is not something I could fix; it might be a bounty project
<pitti> mdz: so that's nothing for Warty
<mdz> fabbione: a diff which does what?
<fabbione> mdz: update the via driver to unichrome
<mdz> pitti: unfortunately not, it seems
<mdz> pitti: please open a bug for horay
<fabbione> mdz: the one daniels was talking about
<mdz> hoary
<pitti> mdz: I do
<fabbione> Applying patch debian/patches/999_debian-xfree86-4.3.0.dfsg.1-7-unichrome_X_r26.diff ... successful.
<mdz> fabbione: does it fix the hang?
<fabbione> mdz: i am building a test driver right now :-)
<fabbione> mdz: i had to read some documentation first
<jdub> mdz: ahr, i haven't been around (re: bug)
<mdz> jdub: feeling any better?
<jdub> not really, actually getting kinda ill now :|
<daniels> fabbione: oooh, nice. didn't know they had a 4.3 patch.
<Mithrandir> seb128: I think it's an _i386_ bug. *grrrr*
<seb128> it works on ppc too afaik
<seb128> Mithrandir: where is the problem ?
<Mithrandir> seb128: in update-mime-database, I think.
<seb128> but what result is wrong ?
<Mithrandir> on i386:
<Mithrandir>       <match value="0x0000081a" type="little32" offset="0" mask="0x8080ffff"/>
<Mithrandir> is mapped into:
<Mithrandir> >0=&
<Mithrandir> uhm
<Mithrandir> some nullbytes in there
<Mithrandir> 1a 0900 0026 7fff ffff 
<Mithrandir> I _really_ don't understand why 0x8080ffff gets turned into 0x7fffff
<mdz> seb128: do you need a login on one of my machines to debug #1943?
<seb128> mdz: I'll try to reproduce it here first but thanks
<mdz> seb128: I can trivially reproduce it here
<pitti> mdz: my list of major bugs is empty; shall I just go on to hunt some segfaults, or do you want me to work at sth particular?
<mdz> pitti: please concentrate on the list of major bugs
<mdz> pitti: especially those assigned to debzilla@ubuntu.com, but any bug where you are able to help, please do
<Mithrandir> seb128: it's i386 that's broken; look at update-mime-database.c, line 841.
<pitti> mdz: okay
<mdz> lamont is gone, so his bugs need attention as well
<Mithrandir> seb128: it's never checked for overflow, and this small test program:
<Mithrandir> #include <stdlib.h>
<Mithrandir> #include <stdio.h>
<Mithrandir> int main(int argc, char **argv){
<Mithrandir>   char *a =  "0x8080ffff";
<Mithrandir> fprintf(stderr, "%ld\n", strtol(a,NULL,0));
<Mithrandir> }
<Mithrandir> returns 2147483647 on i386
<Mithrandir> on amd64: 2155937791
<fabbione> daniels: we should seriosuly involve them with us
<Mithrandir> and on i386:
<Mithrandir> : tfheen@yiwaz ~ > printf "%ld\n" 0x8080ffff
<Mithrandir> 2155937791
<fabbione> printf "%ld\n" 0x8080ffff
<fabbione> 2155937791
<fabbione> i386
<Mithrandir> fabbione: try the small program above.
<mdz> strtol returns a signed value
<daniels> fabbione: unichrome? yeah, I've already talked to them about dragging them into X.Org and they were all for it
<Mithrandir> mdz: so having 0x8080ffff as a mask is Just Wrong, then?
<mdz> Mithrandir: well, using strtol is probably the wrong bit
<daniels> they're all really nice guys; nothing against anyone, it's mainly that they just never really thought to integrate :)
<mdz> strtoul would presumably be better
<Mithrandir> double bug, it seems, both update-mime-database and the mime db.
<fabbione> daniels: yeps
<fabbione> Mithrandir: will do in a sec
<fabbione> ./a.out 
<fabbione> 2147483647
<Mithrandir> mdz: strtoul fixed it, yes.
<seb128> so it's broken on i386 too now ? :)
<Mithrandir> yes.
<Mithrandir> since the mime db is wrong.
<seb128> ok
<seb128> any idea of how many mime will be broken by fixing this ?
<fabbione> Kamion: piiiiiiiiiiiiiiiiiiiiiiiing
<seb128> bbr
* fabbione shakes Kamion 
* Mithrandir summons seb again
<daniels> fabbione: after a Via bitch? :)
<Mithrandir> hooray, I can't reassign bugs in bugzilla due to JS fucking up
* fabbione is always after bitches
<fabbione> Mithrandir: if you are trying to reassign to xfree86 that has been blocked by justdave on my request
<Mithrandir> fabbione: I was trying to reassign to seb128
<fabbione> Mithrandir: bugger :P
<Mithrandir> fabbione: and doing anything like that with JS is Just Wrong.
<fabbione> eheh
* fabbione waits a few secs to see chan response time
<justdave> what's it doing now?
<Mithrandir> justdave: it made focus never enter the "reassign to" field
<Mithrandir> seb128: I updated the bug; 7 MIME types have masks and must be investigated.  Bug reassigned to you, since it's not an amd64 bug. :P
<seb128> ok
<Mithrandir> will you take it upstream as well, please?
<seb128> I'm talking with a gnomevfs guy right now
<Mithrandir> it's not a gnomevfs problem, it's a update-mime-database + mimedb problem. :)
<Mithrandir> gnomevfs just exposes it.
<seb128> yes, but gnomevfs guys work on freedesktop part too
<justdave> Mithrandir: this is on the show_bug page?
<seb128> ie: mime/desktop parsers
<seb128> Mithrandir: is the contact part of evolution supposed to work on amd64 right now ? 
<seb128> I've a friend who can't use it
<Mithrandir> justdave: yes.
<Mithrandir> seb128: worksforme.
<justdave> Mithrandir: worksforme
<seb128> Mithrandir: and "netspeed" ?
<Mithrandir> justdave: using Opera, type something into the component field, then into the comment field, then try to reassign.
<daniels> mdz: mind if I steal #1897?
<Mithrandir> seb128: what about netspeed?
<Mithrandir> seb128: no bugs about netspeed open
<justdave> Ah, I don't have Opera
<seb128> Mithrandir: I'm speaking with a guy who just get an error when he try to add it to the panel
<Mithrandir> well, there's no bug filed
<seb128> take this as a bug report
<Mithrandir> and I'm horribly bad at mind-reading, so.. ;)
<Mithrandir> seb128: please, file a bug in bugzilla
<seb128> I just want to check if that's specific to his config before filling it
<seb128> I'll
<Mithrandir> the network monitor seems happy here; it might have problems detecting the interfaces
<Mithrandir> but if you configure that manually, it's happy
<Mithrandir> is that the error he's seeing?
<seb128> no
<Mithrandir> "an error" is a bit nondescriptive. :)
<seb128> he can't add it to the panel
<seb128> OAFIID:GNOME_NetspeedApplet error
<seb128> looks like a bonobo problem
<Mithrandir> is that the network monitor applet or some other applet?
<seb128> network monitor (the one with "netspeed" in the comment of the add dialog
<Mithrandir> worksforme
<Mithrandir> seb128: you broke e-d-s when you uploaded it, as you didn't get the fixes I did for getting it to work on amd64.
<seb128> arg
<seb128> please, put the patches in debian/patches/
<seb128> so this kind of problem doesn't happen
<Mithrandir> seb128: can you please then just run s_config in libdb/dist and upload?
<seb128> ok
<Mithrandir> seb128: (assuming you get approval, naturally)
<Mithrandir> just make sure the dist/configure includes x86_64 somewhere, so you see it's successful.
<Mithrandir> and please ask upstream to do the same -- they've added the files but forgot to update the configure script.
<elmo_> seb128: you know about g-s-m ftbfs, I assume ?
<seb128> elmo_: no, didn't know
<seb128> I'll have a look
<seb128> Mithrandir: ok
<daniels> elmo_: ... that's my bad.
<daniels> elmo_: missing b-d's, taking care of that now.
<elmo_> guys, highly recommend you keep an eye on the britney output for a hour or two after uploads - it's a nice easy way to keep track of ftbfses, broken deps etc.
<elmo_> (and if thom fixes mozilla-firefox-locale-THEWORLD sometime, it'll even be empty most of the time)
<elmo_> http://people.ubuntu.com/~cjwatson/testing/
<daniels> elmo_: ah, cool. didn't know about that one.
<seb128> me neither
<elmo_> ok, sorry, maybe I should have shouted louder about it.  it is on wiki.ubuntu.com/Archive fwiw
<elmo_> daniels/fabbione: xlibmesa-glu-dev b-d's on libstdc++5 ?
<elmo_> libstdc++5-dev
<daniels> elmo_: yes
<daniels> libstdc++5-dev || libstdc++5-3.3-dev, iirc
<daniels> or maybe the other way around
<daniels> elmo_: is that problematic?
<elmo_> libstdc++5-dev | libstdc++-dev it seems
<elmo_> anyway, no it's okay, it's just my germinate is broken apparently
<daniels> oh
<elmo_> at some stage you might want to update it tho - libstdc++6-dev should be the 'real' alternative
<daniels> ahr
<fabbione> elmo_: i remember i removed that b-d
<daniels> thanks for the heads up
* fabbione checks again
<Kamion> fabbione: yes, I know about #1711
<Kamion> fabbione: what else did you want? :)
<fabbione> Kamion: ok. can you please test the via driver asap?
<Kamion> fabbione: what do I need to grab?
<fabbione> Kamion: see 1878
<fabbione> the via_drv.o from people/~fabbione/
<elmo_> daniels: dude, you didn't actually fix sgml-data, it still b-d-i on symlinks
* Kamion uploads scary debconf change
<fabbione> elmo_: libpaperg, libstdc++5-3.3-dev, tetex-bin,
<fabbione> do you still want me to update?
<elmo_> fabbione: mm?  I'm talking about the Depends?
<Kamion> w00t, joeyh said I could merge scary debconf change into debconf trunk too
<fabbione> elmo_: didn't you say B-d?
<elmo_> fabbione: yes, but I'm on crack
<fabbione> elmo_: can you send me some please? ;)
<elmo_> fabbione: ("don't confuse this argument with facts" etc. :)
<fabbione> Source: fabbione
<fabbione> Live-Depends: crack, pipe, smoke
<daniels> elmo_: it's lucky I didn't reassign you the bug, then
<thom> grah.
* thom beats on the php folk
* fabbione hands the EU sodomotron remote control to thoom
<sivang> fabbione : Hi!
<fabbione> hi sivang 
<fabbione> sivang: do you happen to have a via video card?
<elmo_> elisha 12:17 ~ % mozilla-firefox Email\ Sales\ Quote.HTM
<elmo_> /usr/bin/mozilla-firefox: line 313: [: too many arguments
<sivang> fabbione : I wish ;-) cause I know you need some test lovin' ;-))
<elmo_> neat!
<fabbione> sivang: eheh thanks :-)
* elmo_ blames thom
<thom> elmo_: bwahaha
<fabbione> elmo_: isn't that a simple wrapper script to run the correct mozilla?
<elmo_> fabbione: simple wrapper script that can't handle spaceful-filenames apparently
<fabbione> elmo_: also debconf didn't until a few revisions ago :-)
<fabbione> as well as.. ucf?
<thom> elmo_: file a bug, please
<elmo_> yeah will do.. I just need to read this quote first
<thom> heh
<Kamion> fabbione: X seems to start up with that#
<Kamion> s/#//
<sivang> fabbione : that vert refresh rate drives me crazy, I disabled ddc, dde and still it's not using 100Hz.
<pitti> carlos: here?
<carlos> pitti: yes, is it related to the iPod?
<carlos> :-P
<daniels> Kamion: sensational
<pitti> carlos: how could you know :-)
* carlos saw the problem in your activity report
<pitti> carlos: yes, can you reproduce #1891?
<carlos> :-P
<carlos> not tested yet
<pitti> carlos: I'm lost with this. It works with my USB devices, I can eject them
* pitti wants to have a nice iPod
<carlos> pitti: I still have a problem with my iPod and HFS+
<carlos> but I think it's a bug in hfs+ driver
<pitti> carlos: isn't it mounted automatically?
<carlos> yes, it was last time I tested it (long ago...)
<carlos> but only accesible by root, do you remember ?
<pitti> carlos: there were huge updates in the last two days, bother to try it again?
<pitti> carlos: I remember
<carlos> hmm
<pitti> carlos: that's why I would like to test it again; I think it's a kernel bug, but I could work around it
<carlos> oohh
<carlos> I see the problem
<fabbione> Kamion: cool!
<carlos> pitti: the problem is with sbp2 driver
<fabbione> mdz, jdub: around?
<carlos> pitti: we need a way to remove the device completely
<pitti> fabbione: you have another X to upload? :-)
<fabbione> pitti: yes :(
<carlos> and it only works if your remove the sbp2 from the kernel (rmmod)
<daniels> fabbione: which changes are you making?
<fabbione> pitti: do you have a via video card somewhere?
<pitti> fabbione: not me personally
<carlos> it's a kernel bug
<pitti> fabbione: are these built into these VIA epia boards?
<fabbione> daniels: for monday, not today. we might add the via driver from unichrome
<pitti> fabbione: I know a friend who has an epia
<fabbione> pitti: no idea.. 
<pitti> fabbione: so far I've never seen a VIA graphic card...
<fabbione> daniels: and still ban the probe
<Kamion> fabbione: doesn't want to shut down though, it hangs after I quit X
<fabbione> Kamion: ah shit
<pitti> carlos: so the sbp2 module needs to be manually rmmod'ed after unmounting the device?
<carlos> pitti: yes, but that sucks, if you have two firewire hd (Like I have)
<pitti> carlos: that's ugly; I would not like to do that manually in pumount
<daniels> fabbione: ok
<pitti> carlos: did you submit a bug against the kernel about this? This should affect quite many firewire users
<fabbione> Kamion: it hangs there or it just doesn't want to quit?
<carlos> pitti: the iPod has a "detection" process that knows if you have the device attached to the computer, and as long as it's attached to /dev/sda? it will think that it's mounted and will ask the user to not remove it
<fabbione> Kamion: can you strace it?
<fabbione> Kamion: i still have the -dbg package in case
<pitti> carlos: ah, I remember; you just had to rip it off
<carlos> pitti: it's only a cosmetic problem for other devices != iPod
<carlos> the iPod does not knows that you don't have it mounted
<carlos> that's all
<pitti> carlos: so the iPod still works when plugged in the second time? although the sbp2 module isn't unloaded?
<carlos> hmmm
<carlos> not sure
<carlos> let me check...
<pitti> btw, while you are at it, try 'eject /dev/whatever' :-)
<carlos> well, here we go, the f*cked problem with USB vs. Firewire
<carlos> I need to unload all USB so the iPod is able to be detected...
<pitti> carlos: gar
<pitti> carlos: but I think this cannot be adressed in userspace
<carlos> pitti: it's a kernel bug
<pitti> carlos: let's throw out linux and put in the HURD :-)
<carlos> could we wait to this night and I will debug it better? (I have somethings to do about Rosetta now)
* pitti ducks
<carlos> pitti: X-)
<pitti> carlos: sure, thanks!
<carlos> no problem
<Mithrandir> hm, 1874 doesn't seem to apply to us.
<Mithrandir> thom/mdz: can either of you try to reproduce 1874 on amd64?
<thom> post caffieneation, sure
<thom> i need more to deal with php
<Mithrandir> sure, python-ldap should be a nice break. ;)
<thom> yuck
<thom> yuckyuckyuck
<elmo_> daniels: g-s-m ftbfs
<daniels> elmo_: U*()@#$)U*(OIJ#
* elmo_ devolves to abbreviation-speak
<daniels> forgot the b-d's again, didn't I?
<elmo_> patch failure or something
<daniels> elmo_: wtf?
<elmo_> patches: debian/patches/src_omf_make.patch debian/patches/use_gksu_not_su.patch
<elmo_> Trying patch debian/patches/src_omf_make.patch at level 0...success.
<elmo_> Trying patch debian/patches/use_gksu_not_su.patch at level 0...1...2...failure.
<elmo_> make: *** [debian/stamp-patched]  Error 1
<seb128> daniels: have you restored the original files ?
<Kamion> fabbione: no I can't strace it because I can't get to a console :P
<Kamion> fabbione: 'sudo xresprobe via' still hangs in the same way with that I'm afraid
<daniels> seb128: fixing it now
<Kamion> well, I guess I can do the strace-with-repeated-reboots tricks
<Kamion> trick
<daniels> Kamion: huzzah
<fabbione> Kamion: yes. the xresprobe is another story
<fabbione> Kamion: do you want the -dbg package?
<Kamion> fabbione: not 100% clear to me that it was breaking before though, sorry - turns out I had to 'dpkg --configure -a' after dropping in your driver before the font packages were set up well enough to allow the X server to start anyway
<fabbione> because that one *might* work
<Kamion> really?
<Kamion> why would the -dbg work?
<fabbione> Kamion: ehhhh that's another loooooong story :-)
<fabbione> Kamion: the <whatever_crappy_x_modules_loader> sucks
<daniels> metrolink/xfree86 loader
<daniels> it is COMPLETE BLOODY ARSE
<Kamion> ok, pass it to me I guess
<Kamion> I have a complete strace -f of 'sudo xresprobe via' if that would interest you
<Kamion> it apparently exits successfully, just doesn't do the console switch properly
<daniels> Kamion: could you please dump it in the bug log?
<Kamion> 583K bzipped?
<fabbione> Kamion: 20 minutes and it will be on people
<fabbione> Kamion: -dbg is BIG
<fabbione> on the otherside.. this driver compiled on ppc and amd64.. and that's good
<fabbione> at least it's not a FTBFS
<bob2> someone should port X to use libltdl
<daniels> bob2: FOAD.
<bob2> mwahaha
<daniels> bob2: libltdl requires every symbol to be exported as _modulename_LTDL_foo
<daniels> which is total bong.
<daniels> the Metrolink loader can use libdl, but one day in the car, I got bored and threw the entire Metrolink loader away, so there's now an 800-line shim around libdl.
<daniels> bob2: only in debrix
<bob2> ah
<bob2> you should create a new fork
<bob2> and call it Xizzle
<bob2> that name deserves to live on
<thom> in infamy
<bob2> Xizzle - for me
<bob2> n
<elmo_> daniels: DUDE
<elmo_> like, TEST BUILD YOUR FREAKIN UPLOADS
<elmo_> Trying patch debian/patches/src_omf_make.patch at level 0...success.
<elmo_> Trying patch debian/patches/use_gksu_not_su.patch at level 0...1...2...failure.
<elmo_> make: *** [debian/stamp-patched]  Error 1
<fabbione> Kamion: xserver-xfree86-dbg_4.3.0.dfsg.1-6ubuntu22_i3 100%   52MB  49.1KB/s   18:11    
<fabbione> Kamion: it's on people/~fabbione/
<daniels> elmo_: ARGH
<daniels> elmo_: i did debuild -S, debuild, debuild -S, debuild, debuild -S, debuild
<daniels> wtf
<Mithrandir> daniels: pdebuild -S ?
<daniels> Mithrandir: don't have pbuilder installed
<Mithrandir> apt-get install pbuilder, then.
<Mithrandir> Not Very Hard. :P
<daniels> oh, I know what's wrong
<daniels> BLOODY CDBS
<daniels> WHY MUST YOU INSIST ON RECREATING CONFIGURE
<thom> Mithrandir: um, do you have an example script for 1874?
<Mithrandir> http://users.idf.de/~fs/test2.py
<Mithrandir> is what fs used to test.
<thom> this implies i have an ldap server running
<thom> ber
<Mithrandir> yes.
<Mithrandir> apt-get install slapd and just answer the questions, should be enough
<thom> yeah, it works fine here too
<Mithrandir> I'm going to try to reproduce in a pure64 chroot
<Mithrandir> yeah, see it there.
<Mithrandir> notwarty, then
* fabbione goes to the new house
<fabbione> cya later guys
<Mithrandir> have fun
* pitti goes to buy some food. See you later
<daniels> elmo_: tell me it didn't ftbfs again ...
* daniels crosses his fingers for ubuntu6.
<bob2> do we have a "3 FTBFS" and you're out policy/
<azeem> praying sometimes helps, too
<daniels> bob2: yeah, I feel like THom
<daniels> also, Thom
<bob2> haha
<thom> daniels: my ftbfs's aren't pure incompetence tho ;P
<daniels> thom: i blame cdbs, seriously
* bob2 mutters  something about "private keys"and mailing lists
<daniels> thom: regenerated configure in some apparently random order from random triggers, and there was also control.in from gnome crack
<daniels> bob2: or like six apache2 uploads in a day
<azeem> daniels: then Build-Conflict against autoconf
<daniels> azeem: yeah, because that's productive for my dev machine :P
<thom> daniels: yeah, but that was just stupid unused codepaths that only php users would hit
<bob2> haha
<daniels> went the opposite way and b-d'd on autotools-dev as a temporary hack
<bob2> we cann all unite against PHP users
<daniels> and rasums
<daniels> also, Rasmus
<Kamion> ooh, I have hardware which requires firmware *and* is supported by Linux
<Kamion> good, now I can make ddetect work
<daniels> Kamion: yay!
<seb128> daniels: there is no problem with cdbs, don't blame it if you don't know how to do a patch :p
* thom goes to lunch while the test run for #1915 builds
<elmo_> lude/atk-1.0 -I/usr/include/libxml2 -I/usr/include/libgtop-2.0 -I/usr/include/libwnck-1.0       -g -Wall -O2 -c util.c
<elmo_> util.c:15:18: gksu.h: No such file or directory
<elmo_> util.c: In function `su_run_with_password':
* elmo_ just looks at daniels
<seb128> lol
<Kamion> prism54 *really* doesn't like this card
<amu> remoins
<T-Bone> is there a known bug with gnome-session lately?
<T-Bone> i just can't login, gnome-session crashes immediately
<T-Bone> trashed .gnome* .gconf* .metacity and co, doesn't work anyway. And i wonder why it keeps showing me my personnal backdrop tho i trashed the confs
<T-Bone> it's not only gnome-session, it's gnome-*
<T-Bone> oic, i bet it's #1943
<T-Bone> seb128: ping?
<seb128> pong
<T-Bone> seb128: you reported #1943 (gnome-session not starting when no audio device is present
<T-Bone> i think it's not exactly that
<seb128> I didn't reported anything
<seb128> this bug is assigned to me
<T-Bone> sorry
<seb128> but I can't reproduce it
<T-Bone> that's normal
<seb128> any help is welcome :)
<T-Bone> look:
<T-Bone> hmm, shit it trashed my .xsession-errors
<T-Bone> so here's the big idea:
<T-Bone> i started having troubles after a dist-upgrade
<T-Bone> then any attempt to login would fail
<T-Bone> looking at .xsession-errors showed "/tmp/esd/socket existing, esd already running, exiting"
<T-Bone> or something like that
<T-Bone> i think _this_ is the problem
<seb128> oh
<T-Bone> after rebooting, everything went back in order
<seb128> another esd already running ?
<T-Bone> and it's now working just fine
<T-Bone> i guess so
<seb128> weird
<seb128> there is different problems apparently
<seb128> Matt can reproduce it with a modprobe -r snd_.... apparently
<T-Bone> anyway, to me, esd was the culprit
<T-Bone> whether it was running or not, i don't know, but the fact that its socket was there screwed gnome
<T-Bone> seb128: hope i haven't confused you even more ;^)
<T-Bone> seb128: i'll keep you informed if i can reproduce it easily
<seb128> no problem, that's fine :)
<seb128> thanks for the details
<T-Bone> you're welcome. now i must get back to my ia64 burden ;)
<T-Bone> seb128: side note: dunno if it has been reported already, but i have a "ghost" X cursor on the top layer of my screen, not disappearing...
<seb128> hum
<seb128> how many mouse declared in the XF86Config-4 ?
* T-Bone grins and checks
<T-Bone> seb128: bingo: 2
<seb128> ok
<T-Bone> "Generic Mouse" and "Configured Mouse"
<T-Bone> seb128: nice catch
<seb128> :)
<T-Bone> seb128: though that'd be a configuration problem at install time, i guess then ;)
<seb128> yes
<T-Bone> oh
<T-Bone> waitaminute
<seb128> the issue has already been raised on the list afaik
<T-Bone> i have edited XF86Config-4, still, the X is still there :P
<T-Bone> (and restarted X)
* T-Bone restarts X with ctrl-alt-backspace, just in case
<seb128> you should ping fabbione or daniels about X
<T-Bone> seb128: ok. There's something else. The X won't go away
<seb128> ok
<seb128> bah, I need some fresh air, later guys
<T-Bone> see ya
<thom> T-Bone: try setting Option "SWCursor" in the screen block
<T-Bone> thom: i'll do. Amusingly, this only show in Gnome, not in GDM
<T-Bone> thom: SWCursor fixed the problem, thx
* T-Bone really gets back to ia64 builders now
<sivang> Kamion : around?
<Kamion> sivang: yes
<sivang> Kamion : got my msg?
<Kamion> didn't need to be a private message, just adds to the number of windows I have here ...
<Kamion> sivang: the bug number is #1566
<sivang> Kamion : thank you
<sivang> has anybody witnessed a (I don't know how to define this, really strange) "bug" when browing #1566 using firefox ? using the mouse wheel to scroll, it get's stuck and won't advance. I Must use the mouse cursor to advance it.
<thom> sivang: it won't scroll in certain types of text area
<thom> such as code and possibly pre
<sivang> thom : exactly!
<sivang> thom : browsing it, I see that only in the middle it gets stuck - on the bottom and top of it works fine
<sivang> thom : even if this should be reported upstream, maybe I shall open a bug? or one exists?
<sivang> Kamion : ah, seems like that bug is unrelated to my system - I have my linux partitions on a seperate HD than the fat32 one, only grub sits on the same one.
<thom> search upstream
<sivang> thom : ok
<sivang> thom : I see many issues related to the wheel upstream, however this sepcific issue seems to went unreported.
<sivang> Kamion : why can't I find that C/H/S error message in dmesg or kern.log?
<thom> things you never want to see, part 367:
<thom> 20347 thom      25   0 23288 3268  21m R 86.2  0.3  13:09.69 php
<thom> (from top)
<sivang> Kamion : has the C/H/S patch already in  the daily?
<Kamion> sivang: no, as the bug report states
<Kamion> god, this xfs/grub bug is a right headache
<Kamion> by the time the fix for a bug is in automatic builds, the bug report will have been closed
<sivang> ok. would you think it's a good test for the image, if the 2 partitions are on seperate disks?
<Kamion> it doesn't matter
<Kamion> you may not be able to reproduce it at all; it depends on your BIOS
* netjoined: irc.freenode.net -> sendak.freenode.net
<hazmat> is there a way to reset synaptic's state? synaptic seems to have gotten confused on my install, it doesn't actually see any packages in the ui, the status bar shows the correct counts when searching etc..
<hazmat> i don't see any $HOME/.synaptic directory.. just curious
<m_tthew> hazmat: I see a /root/.synaptic on my box, with a sane date
<hazmat> m_tthew, bingo thank you
<hazmat> that fixed it
<daniels> FAILED?!?
<daniels> cdbs, why must you taunt me :\
<seb128> there is nothing to do with cdbs
<seb128> it just apply the patch and run ./configure && make && make install
<Kamion> mdz: approval to Just Fix linux-kernel-di-{amd64,i386}-2.6 build failures? just a few modules apparently need rearranging
<Kamion> mdz: (stuff in both nic-extra-modules and irda-modules now depends on crc-ccitt.ko)
<Kamion> apparently it's due to via-velocity growing a dependency
<Kamion> I'm going to move crc-ccitt.ko to nic-shared-modules and make irda-modules depend on it (ew, but simplest)
<Kamion> mdz: taking your discover1-data blanket approval to apply to simple usb-discover reuploads too, BTW, hope that's OK
<mdz> Kamion: yes and yes
<Kamion> alrighty
<Kamion> today has been a Hardware Detection Day
<mdz> that's good, because we have RC Hardware Detection Bugs :-)
<Kamion> mdz: do we still? I just closed #1881
<aj> Kamion: poke?
<mdz> Kamion: so I'm looking at this scd vs. sr stuff
<mdz> and it'd be pretty simple to change it from sr to scd with a link from sr -> scd
<mdz> but I think I just disagree with the doc that says to use scd in favour of sr
<Kamion> aj: yo?
<aj> Kamion: if you've got a moment i'd like to chat briefly about debootstrap/ubuntu
<Kamion> aj: sure, I've got a change there that I've been meaning to send back anyway
<Kamion> aj: but yeah, what's up?
<mdz> Kamion: surely there are SCSI removable devices which are not CD-ROMs
<Kamion> mdz: like USB storage, but that doesn't seem to show up as scd/sr ...
<mdz> Kamion: a SCSI removable is basically a storage device with a concept of media presence and an eject function
<mdz> seb128: ping?
<lucas_> hi
<lucas_> who should I talk to about a port of ubuntu to sparc ?
<vuntz> hi lucas_ :-)
<lucas_> hi vuntz :)
<vuntz> lucas_: jeff n'a pas rpondu ?
<lucas_> no
<sivang> does anybody of peopoe.ubntulinux.com supports rsync? 
<sivang> people.ubuntulinux.com
<lucas_> if ensilinx6 could stop crashing for a while, it would probably be easier to use it as a buildd :)
<sivang> i try to download Kamion
<sivang> Kamion
<sivang> Kamion's (damnn that keybd) image for the fixed parted, and can't rsync it
<lucas_> vuntz: what I have gathered is on http://ensilinx1.imag.fr/wiki/index.php/UbuntuSparc
<vuntz> lucas_: ahah: "(Arg that's perl!)"
<lucas_> vuntz: you ever looked at ruby ?
<vuntz> no
<lucas_> you should
<lucas_> perl programmers usually like it
<lucas_> I'll do a short presentation of ruby, probably next week
<mdz> lucas_: regarding a sparc port, ubuntu-devel@lists.ubuntu.com
<mdz> lucas_: there are a few other people who are interested
<lucas_> ok
<lucas_> thank you
<Mitario> hya
#ubuntu-devel 2004-10-13
<Kamion> it's annoying that usb-discover insists on being built with a new discover1-data rather than just using its lists at run-time
<mdz> it's annoying that usb-discover exists
<Kamion> oh, blast, I know why that is, it's because it's used on images too small for discover1-data
<mdz> and discover1-data, for that matter :-)
<Kamion> well, hotplug hasn't had data for some of the hardware detection bugs I've fixed today either
<mdz> from what I see, hotplug should obsolete it
<mdz> Kamion: please file bugs for Herbert with the info for anything which is missing
<Kamion> joeyh's strongly held opinion is that it's better to have devices in discover which are known to work than devices in hotplug which maybe work and might break
<mdz> my strongly held opinion is that the people who wrote the drivers know better which devices work, and they supply the information used by hotplug
<Kamion> I think he does speak from a certain amount of experience here
<Kamion> those people get it wrong too, and it can cause a lot of havoc :)
<mdz> there is data in discover which is plain wrong, loading modules for devices they don't support
<Kamion> sometimes it's worse to load the wrong driver than no driver at all
<Kamion> really?
<Kamion> there's data in the kernel like that too
<mdz> when I did that big comparison, I found some
<Kamion> both discover and the kernel lag behind actual hardware devices to some extent; the extents differ
<mdz> sure
<mdz> but there's no justifiable reason for them to have different data
<Kamion> I guess part of the opinions held by people like joeyh are due to the 2.4 kernel, which is a lot crappier in this respect
<mdz> true enough
<mdz> what were the examples that you found today?
<Kamion> NVIDIA USB, I think, I'll have to go back and compare
<Kamion> probably:
<Kamion>     - Add usb/usb-ohci for 10de00e7.
<Kamion>     - Add usb/ehci-hcd for 10de00e8.
<mdz> I was under the definite impression that USB stuff was handled based on PCI classes
<Kamion> there were some explicit lists in the kernel
<Kamion> of course maybe I was just believing pci_ids.h ...
<mdz> mizar:[~]  grep hci /lib/modules/2.6.8.1-3-386/*pcimap
<mdz> uhci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0300 0xffffffff 0x0
<mdz> ohci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0310 0xffffffff 0x0
<mdz> ehci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0320 0xffffffff 0x0
<mdz> ohci1394             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0010 0xffffffff 0x0
<mdz> that's all that hotplug has for the HCI modules
<Kamion> hm
<Kamion> I wonder if usb-discover could do that (even if we lose it, Debian still has to keep it in form due to heterogeneous kernels)
<Kamion> s/in form/in some form/
<mdz> via discover, or directly?
<Kamion> either
<mdz> depends on whether you have a strong stomach, I guess :-)
<mdz> neither is very palatable
<Kamion> *shrug*, it's no worse than lots of hardware detection
<mdz> in the first case, discover's code is gnarly
<mdz> I guess directly is not that bad, /proc/bus/pci is pretty sane
<Kamion> I don't see anything that might plausibly be PCI classes in /proc/bus/pci/devices
<mdz> hmm
<mdz> you're right
<mdz> well that stinks
<mdz> I wonder where lspci gets it, then
<mdz> /proc/bus/pci/NN maybe
<Kamion> does it?
<mdz> ah, it uses sysfs
<Kamion> oh, it has prog-if
<Kamion> is that what you mean?
<mdz> which looks the same as pci/NN
<mdz> prog-if?
<Kamion> 0001:01:1b.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI] )
<Kamion> it appears to peek PCI configuration registers for that
<mdz> aaha
<Kamion>       c = get_conf_byte(d, PCI_CLASS_PROG);
<mdz> mizar:[/tmp/usb-discover-0.22]  grep -w 0x0c0300 /sys/bus/pci/devices/*/class
<mdz> silly IRC eating my output
<Kamion> maybe you could get it from /proc/bus/pci/*/* if you tried hard enough
<mdz> mizar:[/tmp/usb-discover-0.22]  grep -w 0x0c0300 /sys/bus/pci/devices/*/class | sed -e 's/^/ /'
<mdz>  /sys/bus/pci/devices/0000:00:07.2/class:0x0c0300
<mdz>  /sys/bus/pci/devices/0000:00:07.3/class:0x0c0300
<Kamion> needs to be portable to 2.4 if I'm going to push it into Debian
<mdz> that's all UHCI controllers
<Kamion> although I suppose it could fall back to discover on 2.4
<seb128> mdz: pong
<Kamion> yes, that seems a nice approach
<mdz> yeah, you should be able to add about 10 lines of shell and handle all USB controllers on 2.6
<Kamion> neat
<Kamion> ok, will try to do that
<mdz> seb128: were you able to reproduce #1943?
* Kamion dumps it in ~/TODO
<seb128> mdz: no, tried on my 2 boxes
<seb128> on without any soundcard, the other with module removed
<seb128> no problem
<mdz> seb128: do you have some time to work with me on it?
<mdz> it is causing problems for many users
<Kamion> mdz: advance approval to upload that when I implement it? :)
<mdz> Kamion: yes
<seb128> I've no real idea on the problem, I've never looked on the sound part ...
<seb128> I can make test if you have some idea
<mdz> seb128: I can set you up with shell access on a system which exhibits the problem
<mdz> or I can try some things
<seb128> the problem is that shel access to debug GNOME sessions ...
<mdz> I'll try some strace
<seb128> do you have something in ~/.xsession-errors
<seb128> <T-Bone> looking at .xsession-errors showed "/tmp/esd/socket existing, esd already running, exiting"
<seb128> <T-Bone> or something like that
<seb128> <T-Bone> i think _this_ is the problem
<seb128> this was some hours ago
<seb128> do you have something in /tmp/esd ?
<mdz> checking
<mdz> no /tmp/esd
<seb128> ok
<mdz> in ~/.xsession I have:
<mdz> /dev/dsp: No such file or directory
<mdz> /dev/dsp: No such file or directory
<mdz> /dev/dsp: No such file or directory
<mdz> /dev/dsp: No such file or directory
<mdz> /dev/dsp: No such file or directory
<mdz> /dev/dsp: No such file or directory
<mdz> ** (gnome-session:9507): WARNING **: Esound failed to start.
<mdz> the /dev/dsp error is reapeated a few hundred times
<Kamion> mdz: yup, ten lines. :-)
<mdz> seb128: you want strace?
<seb128> could try that yes
<mdz> attached to the bug
<seb128> ok, thanks
<mdz> it is hard to tell where it is blocking
<mdz> gnome-session itself forks esd
<mdz> many times
<Kamion> mdz: #1932 should be dead with the DMA changes, shouldn't it?
<mdz> Kamion: yes, if that's a bad DMA symptom
<sabdfl> hey guys
<mdz> linux-source-2.6.8.1 (2.6.8.1-10) warty; urgency=low
<mdz>   * Enabled IDEDMA_ONLYDISK.
<Kamion> mdz: think so ... the new kernels won't make it onto the CD until tomorrow sometime, so I'll wait until there's something for him to test and then ask for a retest
<jdub> sabdfl: pipermail's not working with external (lurker) turned on; disabling now and doing it another way.
<Kamion> will probably do a manual CD build sometime tomorrow, I've uploaded enough stuff today that I want to test
<seb128> jdub: do we want to remove the "launch terminal" entry from the nautilus' menu on the desktop ?
<jdub> seb128: what for? :)
<sabdfl> jdub: considered using a cron job to get lurker to parse the mbox files hourly?
<seb128> jdub: #1777
<jdub> sabdfl: won't be dynamic enough
<jdub> sabdfl: i'm just going to deliver mail to it
<sabdfl> jdub: mailman has an explicit option to do both mbox and pipermail
<jdub> sabdfl: which is not working!
<jdub> well
<sabdfl> ok
<jdub> mbox + pipermail is
<jdub> mbox + pipermail + external is not
<jdub> seb128: waste of patch, dude
<seb128> jdub: ?
<sabdfl> any particular reason to keep the pipermail archive?
<jdub> seb128: #1777
<seb128> jdub: "waste" ?
<jdub> sabdfl: because currently, that's what people are looking at, and for some people, it's easier to read
<seb128> jdub: it has been provided by vuntz .. people are free to provide patches afaik
<sabdfl> yes, some views are cleaner in pipermail
<jdub> seb128: we don't have to accept every patch :)
<seb128> jdub: that's why I'm asking :) But I don't get the "waste" part ...
<jdub> seb128: every patch we add is a cost
<seb128> we use it or not, but that's not wasted
<seb128> why ?
<jdub> seb128: we shouldn't throw on frivolous patches just because they exist
<jdub> seb128: because we have to maintain them, and because they set precedent
<seb128> ok, so the answer is no :)
<seb128> let's see if upstream accept it
<jdub> er, 'yes', the answer is 'no' ;)
<seb128> jdub: do you know if some other distro has sound events turned to on by default with GNOME ?
<jdub> seb128: afaik, none do.
<seb128> ok
<jdub> seb128: given that there's minimal support for it upstream. :-)
<seb128> yes, I was fearing that
<jdub> and, um, they're just annoying ;)
<seb128> we have a severe issue for people who don't have a working soundcard
<seb128> session hangs
<jdub> oh?
<jdub> oh
<seb128> we got a bunch of dup of the problem
<seb128> but no problem here ... dunno the condition to get it
<seb128> (#1943 if you want the bug number)
<jdub> mmm, been watching the bug; no useful input as yet.
<seb128> yes, but several dup on the list
<mdz> hmm
<mdz> hald is segfaulting
<mdz> seb128: does the strace reveal anything to you?
<seb128> no ...
<seb128> I'm trying to get details on google, perhaps somebody else got the same problem
<seb128> but most of the people avoid sound events/esd in GNOME
<jdub> lots of people use esd, but veeeery few use sound events
<sabdfl> jdub: prognosis for sound improvement in gnome 2.10?
<jdub> sabdfl: well, i'm going to champion the DEATH OF ESOUND
<jdub> sabdfl: but for sound events, no one cares. it's horrible stuff, needs restructuring if anyone cares about it at all.
<sabdfl> fluendo guys not interested?
<jdub> interface bleeps beyond errors are just annoying
<jdub> no, they care about multimedia
<jdub> i would just recommend avoiding the entire sound event mess for now, and if we think it has any serious benefit for users, help to restructure it
<mdz> so basically, you guys (jdub and seb128) are saying that we should not enable sound events by default in Warty?
<seb128> yes
<jdub> yes
<jdub> mdz: do you think sox is evil?
<sabdfl> fine by me
<mdz> jdub: moderately
<sabdfl> can we play a startup sound using aplay?
<mdz> using aplay would be >> sox
<jdub> sabdfl: how about a gdm "you can login now" sound?
<jdub> mdz: ok
<mdz> jdub: don't we already ring the system bell for that?
<sabdfl> you mean, other than "BEEP"
<jdub> yes, but we can replace it with a sound
* mdz lunches
<jdub> (i would like to)
<sabdfl> seems perfect to me
<jdub> ok
<sabdfl> mdz: there is currently no warty-security universe
<sabdfl> i think it needs to be there
<sabdfl> we'll put stuff in it that's easy and obvious or provided by the comunity
<sabdfl> not sure if that's an oversight or just not done yet
<mdz> sabdfl: elmo was very much against it
<mdz> there is a big problem with testing-security in Debian
<sabdfl> i think it's criminal not to have SOMETHING
<mdz> people see it in the archive and take it as a declaration of support
<sabdfl> the apt.sources.list stuff is as explicit as we want it to be
<mdz> then they send us hate mail when they don't get any updates from it :-)
<sabdfl> the reality is there could be a trivial kde fix or something, tiny patch, as we *can't* get it to people
<mdz> we can always toss it into universe itself
<mdz> not that I'm entirely unsold on universe-security
<sabdfl> by that argument, we could toss warty security updates into warty
<sabdfl> we don't, for very good reason
<sabdfl> i don't think being afraid of a misinterpretation of our level of support for universe is a good reason
<sabdfl> it will happen in the first week, i'm certain of it
<sabdfl> the moment we release:
<sabdfl> joehacker: where's package foo?
<sabdfl> blogghacker: it's in universe, doooood
<sabdfl> joehacker: but that's version, 1.2.1 and there is a security fix in 1.2.2!
<sabdfl> it's going to happen the day we release
<sabdfl> anyhoo... i'm retiring from the battlefield
<mdz> the reason we don't do that for warty is because we provide a certain level of quality and stability, which we don't for universe
<sabdfl> for tonight :-)
<sabdfl> see you all anon
<mdz> ok
<mdz> it's already happening
<mdz> there are already known vulnerabilities in universe that we are not fixing
<sabdfl> that's fine while we are during freeze
<sabdfl> but i think we could quickly get a community hit squad together to approve or veto uploads to universe for security fixes
<sabdfl> might be agood proving ground for new talent
<mdz> sure
<sabdfl> it's not something we need to worry about or invest time in (we explicitly say we won't)
<sabdfl> but if the community process can carry the workload we should support it
<sabdfl> and for hoary, universe will see a lot more work done by other people
<sabdfl> and hence universe will be higher quality
<Kamion> if packages in universe are getting significant work done by externals, the plan is to consider them for supported, isn't it?
<mdz> we currently don't even have infrastructure for warty main security updates
<mdz> I think you'll agree that gets priority :-)
<mdz> Kamion: if it makes it past the comfort threshold, yes
<sivang> mdz : universe sec bugs which are not getting fixed due to lake of priority for warty, or for being officially unsupported?
<mdz> sivang: both
<sivang> mdz : what about a sync up policy from debian?
<mdz> sivang: what do you mean?
<sabdfl> Kamion: yes, but even if they remain in universe for a few releases, it's better for us if universe is higher quality
<sivang> mdz : as I remeber the report I made for 2004, most of the issues could be solved by fetching the newer source packages from sid.
<Kamion> mdz: so, I'm seeing firmware loading problems with this prism54 card I've got here
<Kamion> sabdfl: sure
<sabdfl> and a well managed community process could be great for the community as well as for us
<sabdfl> we will need to empower the right groups in teams and individuals
<sivang> however that could be a very small subset of known and unknown sec bugs currently....
<Kamion> mdz: having updated all the hotplug scripts to current versions etc., it seems to try loading the firmware, then it immediately issues a firmware remove action, then it tries to soft-reset the card and fails miserably, then it loops
<mdz> Kamion: neat
<sabdfl> anyhoo... i'm going to crash for the night... see you all tomorrow
<mdz> Kamion: does it work correctly with the same hardware on an installed system?
<Kamion> haven't tried it outside d-i yet though
<Kamion> that machine is sacrificial weirdo corner-case testing box, so it isn't in an installed system often :)
<mdz> sivang: when we're not in a deep freeze, we'll be more liberal about accepting new versions from Debian for universe
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 32 RC bugs to go
<mdz> Kamion: perhaps you're running into the kill-switch-loop-of-death bug
<mdz> which is fixed in the current kernel?
<sivang> mdz : ok. I was thinking that security related issues can have an exempt from the freeze. but it do sounds more logic to do it for main, not universe.
<Kamion> don't see a kill-switch flag in /sys
* sivang is rebooting, testing Kamion
<sivang> Kamion's special made iso for parted issue
<Kamion> mdz: ok, seems to break in a real system too, I guess it isn't a d-i thing, I'll file a bug
<mdz> Kamion: you're running with the 0.10 version of the driver?
<Kamion> mdz: this is prism54, not ipw2200
<mdz> Kamion: ohh
<mdz> I didn't read that bit at all
<Kamion> hence, no kill switch :-)
<sivang> Kamion : still has that C/H/S message. where can I track it on the logs to see what's really spitted there?
<sladen> is tht implying that it's /not/ actually working with fat*
<sivang> i have only one fat32 partiton there, and grub. the linux parts on on /dev/hdb interestingly.
<sivang> /dev/hda being the boot device
<sivang> if only i could snapshot that scree see the details of this message..
<sivang> anyways, i'm off to sleep.
<sivang> night
<mdz> jdub: ping?
<jdub> pong
<jdub> hrm
<jdub> can't load ipw2200
<jdub> FATAL: Error inserting ipw2200 (/lib/modules/2.6.8.1-3-686/kernel/drivers/net/wireless/ipw2200/ipw2200.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<jdub> ipw2200: disagrees about version of symbol ieee80211_wx_set_encode
<jdub> ipw2200: Unknown symbol ieee80211_wx_set_encode
<jdub> ipw2200: disagrees about version of symbol ieee80211_wx_get_encode
<jdub> ipw2200: Unknown symbol ieee80211_wx_get_encode
<jdub> ipw2200: disagrees about version of symbol ieee80211_wx_get_scan
<jdub> ipw2200: Unknown symbol ieee80211_wx_get_scan
<jdub> ipw2200: disagrees about version of symbol ieee80211_alloc
<jdub> ipw2200: Unknown symbol ieee80211_alloc
<jdub> ipw2200: disagrees about version of symbol ieee80211_rx
<jdub> ipw2200: Unknown symbol ieee80211_rx
<jdub> ipw2200: disagrees about version of symbol ieee80211_rx_mgt
<jdub> ipw2200: Unknown symbol ieee80211_rx_mgt
<jdub> ipw2200: disagrees about version of symbol ieee80211_skb_to_txb
<jdub> ipw2200: Unknown symbol ieee80211_skb_to_txb
<jdub> ipw2200: disagrees about version of symbol ieee80211_free
<jdub> ipw2200: Unknown symbol ieee80211_free
<jdub> 
<daniels> mdz: hm
<daniels> mdz: would solving #1981 be out of the question by creating a small wrapper that modprobes ppp_generic that's suid root, and only executable by dip?
<mdz> jdub: I didn't even consider the possibility that the user was raising the firefox update issue without noticing that it wasn't enabled
<mdz> daniels: I think pppd itself should just modprobe ppp_generic
<mdz> jdub: did you perhaps install the driver from source at some point?
<mdz> jdub: it works like a charm for me
<jdub> mdz: nup
<jdub> this is after a kernel update
<jdub> oh
<jdub> hold on
<jdub> i don't think i've rebooted
<jdub> hrm
<jdub> i'll try that ;)
<daniels> mdz: ok
<mdz> jdub: how would I verify that the firefox thing is disabled?
<mdz> jdub: if I go into preferences->advanced, the "periodically check for updates" bits are checked
<mdz> and clicking "check now" produces a complaint about the critical update
<mdz> there's an 'install now' button, which obviously doesn't work
<mdz> so it seems to be enabled
<jdub> ahr, bong
<jdub> mdz: if periodically check for updates is checked (for the browser, not extensions), then we've messed that up in our update
<jdub> ok, so it was a kernel/restricted sync issue
<jdub> working fine now
<mdz> jdub: ipw2200 isn't in restricted
<mdz> jdub: so I'm having a hell of a time trying to track down #1943
<jdub> oh yeah, good point
<jdub> mdz: sounds?
<mdz> yeah
<mdz> I've tried disabling sound events and esd and stuff, and it's all very weird
<jdub> even after disabling them, it's still happening?
<mdz> no, it's more like I disable stuff, and then it goes away, and then I re-enable, and re-load the sound driver, but I still don't get sounds
<mdz> maybe I do not fully grok gconf
<mdz> right now I can't reproduce the problem, but I can't get it to play sounds either, so I think my settings are stuck
<mdz> esd is running, but sound events are clearly off
<mdz> even though gconf tells me they are enabled
<mdz> mdz@potpal:~ $ !gconf
<mdz> gconftool-2 -R / | grep sound_events
<mdz>     sound_events = true
<jdub> what does the sounds dialogue say?
<mdz> but the box is unchecked if I go into sound preferences
<mdz> (just looked)
<jdub> ahr
<mdz> wtf is that
<jdub> hrm
<mdz> checked the box, sounds are back
* jdub goes to mull this over with a malibu+coke... ;)
<mdz> hmm
<mdz> gnome-settings-daemon is opening the ALSA control device
<mdz> why is it doing that?
<mdz> 16733 open("/usr/lib/gstreamer-0.8/libgstalsa.so", O_RDONLY) = 35
<mdz> jdub: gnome-settings-daemon is into all sorts of things
<jdub> mdz: it handles the keyboard shortcuts for the mixer
<jdub> that's a lot of the reason why it does heaps
<jdub> that pmu on ppc thing is g-s-d too -> backlight control
<mdz> jdub: bingo
<mdz> jdub: removing gstreamer0.8-alsa suppresses the problem
<mdz> so it's something messing with ALSA, and not esd or anything going through it
<daniels> mdz: ok to upload http://people.ubuntu.com/~daniels/ppp/ppp_2.4.2+20040428-2ubuntu5-to-ubuntu6.diff ?
<daniels> mdz: works here when invoking pon as non-root, with no ppp modules loaded
<daniels> actually, holdasec.
<daniels> yep
<daniels> daniels@nanasawa:~% ls -l /dev/ppp
<daniels> ls: /dev/ppp: No such file or directory
<daniels> daniels@nanasawa:~% pon
<daniels> daniels@nanasawa:~%
<doko> good morning
<daniels> doko: 'morning
<Mithrandir> hi doko
<doko> Mithrandir: see #1992, I'm wondering, how you did build OOo for amd64
<mdz> daniels: it would be nice if it waited for /dev/ppp to appear rather than sleep(5)
<mdz> especially when the module is already loaded and the device already exists
<daniels> the sleep (5) was there for a reason
<mdz> doko: look at the source package; it uses the i386 binaries
<daniels> if you wait for /dev/ppp to appear, you could just spin infinitely
<daniels> and that codepath only gets hit if /dev/ppp doesn't exist already
<daniels> it's not a five-second hit on subsequent connects
<mdz> waiting for /dev/ppp does not imply waiting indefinitely
<mdz> but if it doesn't hit that code if /dev/ppp already exists, looks good to me
<daniels> i can wait for /dev/ppp if you like, but seems like additional complexity to be including
<daniels> rad
<doko> mdz: ahh. ok the precompiled i386 binaries ...
<Mithrandir> doko: what mdz says.
<mdz> doko: if you want to track a bug for Ubuntu where there is already a Debian bug open, ask me to import the bug rather than opening a new one
<Mithrandir> doko: make sure you don't end up conflicting with ia32-libs-ooo
<doko> mdz: there was only one for gcc-3.4, not gcc-3.3.
<mdz> doko: ?
<doko> mdz: the problem exists both in gcc-3.3 and gcc-3.4. Debian gcc-3.3 is not biarch, therefore there is no bug report in the Debian BTS.
<daniels> mdz: btw, if you want to make the owner/default assignee for ppp/pppoe/et al myself, I'm fine with that
<daniels> as opposed to the de facto owner/default assignee ;)
<doko> Mithrandir: will look. these are development files only, according to the name 'ia32-libs-ooo', there should be no -dev files in the package.
<daniels> c
<daniels> erk
<mdz> doko: but when you filed the bug in bugzilla, you said it was the same as Debian bug #273755
<mdz> but now that I have imported that bug, it does not seem to be the same at all
<doko> the same for gcc-3.4. in the past you told me to use the BTS to track changes to packages proposed for upload to warty. that's what the bug was for. confused ...
<mdz> doko: in the bug description, you wrote "this is Debian #273755".  what did you mean by that?
<Mithrandir> I just love people who write C++ but just write C.  And I love people who cast pointers to ints.
<mdz> Debian #273755 is a fortran bug
<doko> ahh, ok I see ... I cited the wrong report ... #274362 is the amd64 one ...
<doko> yes, and #273755 should be address as well. wrong code regression from g77-3.3 to g77-3.4
<mdz> not critical for Warty
<doko> which one, or both?
<mdz> g77
<mdz> the amd64 issue is debatable; the only thing we build with biarch is grub, which isn't C++
<Mithrandir> mdz: I think the ooo-amd64 bug might be due to ia32-libs-ooo not shipping myspell. :)
<mdz> but since it seems very simple to fix, it's OK with me
<mdz> Mithrandir: ahh
<Mithrandir> mdz: but it looks like ooo does some weird stuff:
<Mithrandir> open("/usr/lib/libmyspell.so.3", O_RDONLY) = 22
<Mithrandir> /usr/lib/libmyspell.so.3:   symbolic link to `libmyspell.so.3.1'
<Mithrandir> /usr/lib/libmyspell.so.3.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
<Mithrandir> maybe it's ldopen, I don't know.
<Mithrandir> I'll build a 32 bit myspell and test
* Mithrandir wants multiarch
* mdz wants 64-bit to work
<Mithrandir> 64 bit works.. mostly. ;)
<Mithrandir> doko: do we include drdsl anywhere, or how do I get my Fritz!DSL card working?
<doko> Mithrandir: what is it good for? I have a Fritz!DSL as well (the combined one with ISDN), and I don't use it at all.
<Mithrandir> doko: I don't remember, it might be useless.
* Mithrandir goes to hunt about in arcane scripts
<Mithrandir> doko: how do you set the vpi and vci?
<doko> have /etc/drdsl/adsl.conf, but I don't call drdsl ... hmm
<Mithrandir> ok, so it might be enough just to have the file
<doko> controller 2
<doko> protocol adslpppoe
<doko> vpi 8
<doko> vci 35
<jdub> mdz: whoa, wacky
<jdub> mdz: can we not install gstreamer0.8-alsa by default?
<mdz> jdub: this is all so fucked, I am not sure that test was at all valid
<mdz> my machine is fucking crashing now
<jdub> oh.
<mdz> and I am no closer to finding the problem
<jdub> capplets is the only thing that depends on it
<jdub> due to gstreamer-properties
<jdub> hrm, no
<mdz> I can't reproduce the bug when I'm stracing stuff
<jdub> due to gnome-settings-daemon
<jdub> heh, i hate those ones
<mdz> a lot of people are installing ubuntu and finding it completely useless because of this bug
<mdz> whatever it is
<mdz> jdub: are you able to reproduce it?
<mdz> do this: lsmod | grep '^snd' | awk '{ print $1 }' | xargs -n1 sudo rmmod
<mdz> and then try to login in gdm
<mdz> I need to know that I'm not crazy
<mdz> anyone?
<mdz> there are two gnome-settings-daemon processes
<mdz> they appear to have a pipe open between them
<mdz> one is writing to the pipe, and the other is waiting for the one writing to the pipe
<mdz> so they're basically deadlocked
<mdz> I can't stare at this any more tonight. I've put everything useful that I have so far into bugzilla
<mdz> someone else please look at it when you have a chance
<Mithrandir> which bug is this?
<mdz> Mithrandir: #1943
<mdz> the big red one :-)
<Mithrandir> mdz/jdub: permission to upload new ia32-libs-openoffice.org with libmyspell3 included.
<Mithrandir> fixes 1986
<mdz> Mithrandir: yes
<Mithrandir> thanks. :)
<daniels> $(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
<daniels>         cd $(srcdir) && $(AUTOCONF)
<daniels> GNAR
* daniels uploads another g-s-m and hopes for the best.
<daniels> if it lasted twenty invocations of debuild, some with -S, some without, it should be OK
* daniels eats his hat.
* doko wants a photo
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 35 RC bugs to go
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu development -- general discussion on #ubuntu | 34 RC bugs to go
<daniels> g-s-m built!!
<tseng> who what?
<tseng> oh.
<doko> where can I find the query for the (currently 34) warty RC bugs?
<daniels> doko: there are < 34 bugs with a Warty target milestone, so I assume it's just blocker/critical/major bugs
<mdz> correct
<mdz> everything >= major
<doko> hmm, I get 32 when selecting all statuses, but a lot of them are set to resolved.
<mdz> severity: blocker, critical, major + product: ubuntu + status: unconfirmed,new,assigned,reopened,needinfo,pendingupload
<mdz> = 34
<doko> is it possible to save queries like this one for everyone?
<mdz> I'm not sure, ask justdave
<doko> ahh, I did have Target=WartyWarthogFinal set as well
<doko> mdz: ok to upload analog (#1924), missing mkdir in postinst?
<mdz> doko: yes
<doko> mdz: ok to upload samba (#1761), server string without version number?
<mdz> doko: yes
<doko> ok
<sladen> keybuk: does anyone have the Canonical Logo as a vector format?
<mdz> sladen: there is an SVG on the wiki
<mdz> ah, never mind, you said canonical, not ubuntu
<mdz> I only have a bitmap of that one
<sladen> while we're on that subject, I did a cleaned up bitmap for the website that doesn't look so grotty
<sladen> http://www.paul.sladen.org/ubuntu/branding-clean/www.canonical.com/logo.png
<sladen> (contrast with the old  logo.jpg)
<pitti> Hi guys!
<doko> mithrandir: for amd64 we have lib32gcc1, lib32stdc++5, lib32stdc++6 in universe. why are they included/built in ia32-libs-openoffice.org as well?
<pitti> Hi seb128!
<pitti> I added some comments to 
<pitti> seb128: I added some comments to #1919. Are you fine with the patch?
<seb128> yes
<doko> mdz, mithrandir: ping about #1996?
<pitti> Hi sabdfl
<sabdfl> hey pitti
<sabdfl> what no hal-of-the-day? :->
<pitti> sabdfl: no, this time it's gst-plugins :-)
<pitti> sabdfl: but don't be afraid that there won't be further version, yesterday I got two new bugs :-/
<sabdfl> any reason my sound has died recently? can't get a cd to play
<pitti> sabdfl: but I have to care for a Debian applicant today, I dragged that for too long
<sabdfl> but haven't had time to find the bug
<pitti> sabdfl: do you just hear no sound, or does it stop with an error message?
<sabdfl> cd seems to be spinning but no sound
<pitti> sabdfl: so controlling the cd works? you can verify with headphones on the drive
<sabdfl> aplay works fine i think
<sabdfl> yes it works on a headset from the drive directly
<pitti> sabdfl: and it worked with an earlier version?
<sabdfl> i never tried the cd layer applet
<sabdfl> do i need to configure gst?
<pitti> sabdfl: actually this should not be necessary
<pitti> sabdfl: when running the CD-ROM as audio player, you just need a cable which connects the CD with the sound card
<sabdfl> hmm... maybe that's not setup
<pitti> sabdfl: another approach is to read out the audio cd digitally and output it through the normal /dev/dsp
<sabdfl> ok
<sabdfl> i'll play around
<pitti> sabdfl: a nice low-level tool is 'cdplay' from the cdtool package.
<pitti> sabdfl: if that spins up the cd, but you don't hear sound (although the mixer is up), then the cable is probably missing
<sabdfl> hmm... there seems to be a problem with rhythmbox too
<sabdfl> double clicking a song gives me a dialog error:
<sabdfl> "There is no element present to handle the stream's mime type application/x-id3"
<Kamion> any opinions on where to put the new live CD image?
<Kamion> releases/warty/preview/ seems a bit inappropriate since it isn't synced with the preview release
<Kamion> actually never mind, I'll send mail
<pitti> sabdfl: I also found this. gstreamer cannot process some of my mp3s, so I just converted them to ogg :-/
<sabdfl> pitti: it's not just some of my mp3's, and these used to work just fine
<sabdfl> hmm... i wonder if i removed some of the universe stuff...
<sabdfl> Kamion: response coming on the mail front. we need a much simpler cdimage rsync export for mirrors
<sabdfl> we can have a bigger tree of cd images in the full archive, but we'll get MANY more mirrors of just the cdimages
<sabdfl> and we only want to show them the latest stuff, so there is no confusion about which piece they should be downloading
<doko> sabdfl: will we have different background images as you presented in Oxford?
<Kamion> sabdfl: hence my mail way back before preview anticipating this problem :-)
<Kamion> (on sounder@)
<sabdfl> Kamion: ok :-)
<sabdfl> doko: yes, we are trying to figure out the best strategy on that front at the moment
<sabdfl> have the images, just figuring out how to present them, defaults, calendar etc
<doko> could we scan the first name of the user account we ask and then select the "appropriate" theme (m/f) for the user?
<Kamion> how do you even work out the first name? :-)
<sabdfl> doko, Kamion, we could record them saying "Ubuntu" then do a voiceprint analysis to determine gender :-)
<doko> the first string looked up in a table of names. that's not much work. If it's ambigious or not found, fall back to a "safe" default ;-)
<Kamion> doko: that's wrong for a big chunk of the world
<sabdfl> default will be very conservative, no image at all
<Kamion> lots of countries use given-name-last
<doko> kamion: but at this point we already know the country
<Kamion> sabdfl: aargh, I *wish* the cdimage layout had been stabilized before preview, I was really trying to have all the rearrangements finished by then; now we're going to annoy the mirrors we already have
<Kamion> and break advertised URLs, etc.
<Kamion> I also think it's a bad idea to remove previously available images, as the /preview-release/ -> warty symlink implies you want to do
<Kamion> they need to be archived somewhere with a consistent URL
<doko> kamion: during installation on pbook, how do I switch the console (german keyboard)?
<Kamion> doko: loadkeys, I think
<Kamion> if it's available; kbd-chooser does it in C
<Mithrandir> doko: hysterical raisins, I think; do they work with ooo?
<doko> Mithrandir: ???
<Mithrandir> doko: why ia32-libs-ooo contains libstdc++5
<doko> ahh, yes. I never had the chance to run oo on amd64, so I don't know ...
<doko> mithrandir: could you check it out? replacing the libgcc.1 and libstdc++5 from ia32-libs-ooo with these from the lib32* packages?
<Mithrandir> doko: yeah, I'll try
<sladen> doko: remember, it's not just male/female---you have to take sexual preferences into account too!  ;-)
<Mithrandir> hmm, a feature we might want to add, possibly is a question when booting up after an unexpected shutdown, a question on why, with possible reference to problem ticket id and so on.  shamelessly stolen from XP
<sabdfl> Kamion: i think we can keep the existing structure, and add another rsync module which has the minimalist stuff for smaller mirrors
<sabdfl> Kamion: also, i think we should name the iso's in a preview dir "preview-warty-i386.iso" so there is no confusion, in future
<Kamion> sabdfl: I think I disagree there, I'd prefer to keep the image names identical and disambiguate by directory name
<Kamion> makes it easier to have rsync scripts and stuff
<sabdfl> Kamion: for that "simple cdimage" tree, i'd like to have one, and only one, warty dir.
<sabdfl> for the full tree in the full archive, fine, as you wish
<sabdfl> but the simple version should have a single warty dir
<Kamion> maybe we'll just have to copy to the simple tree, then
<sabdfl> Kamion: that's fine too
<Kamion> let me sleep on this, I want to think out the consequences :)
<sabdfl> i'm trying to greatly reduce the amount of knowledge required to find the right iso, know what you're getting, and get it
<Kamion> understood
<Kamion> mdz: uploading ddetect to fix a build problem in the /sbin/hotplug addition (whoops)
<Kamion> sabdfl: the things I'm balancing against that are our need to be able to expect users to know which image they've got, and the need to make it reasonably easy for users to track along with us as we finish off warty without having to change mirroring scripts too often; they aren't contradictory concerns, but we've managed to balance everything thus far and I just want to be careful in ensuring that we continue to do s
<sabdfl> Kamion: understood, what's been done so far is fine, i'm just trying to tweak for a new market of nuuubies
<Kamion> right
* fabbione is back to a world made of bits :P
<fabbione> seconf operation day at home a complete success ;)
<fabbione> s/f$/d
<doko> fabbione: just reinstalled warty on a pbook 12" with german keyboard. there are some other people reporting problems with non-US keyboards. basically I can't type in @, ?, [ ]  { } \ |
<fabbione> doko: yes i know
<fabbione> we miss a file
<fabbione> it has been committed to SVN today
<fabbione> doko: i have the changes already merged in my tree, but i need to collect a bunch of fixes before uploading X
<doko> ok thanks.
<fabbione> it's the us_intl layout definition file missinf
<fabbione> missing even
<fabbione> it is built but Denis forgot just the detail to install it ;)
<fabbione> and both Branden and I didn't notice until yesterday that someone reported the problem
<fabbione> Treenaks: you rock! thanks a lot for all the tests!
<pitti> fabbione: you mean that external screen on ppc will actually work in the forseeable future? Great!
<fabbione> pitti: yes :-)
<pitti> fabbione: Great! Maybe it works until December, then I can implement that beer offer in Spain :-)
<fabbione> pitti: if we had more time to backport some X.org drivers it would be working now
<fabbione> unfortunatly ATI driver has been updated too much and difficult to port
<pitti> fabbione: well, the freeze... But till then I still have a small and uncared-of MacOS X installation :-)
<fabbione> ehhe
<pitti> fabbione: presenting JPGs and PDFs on a beamer is actually the only reason why I still have it
<pitti> Guys, dancing tonight. Have a nice evening!
<sivang> jdub : around?
#ubuntu-devel 2004-10-14
<XXX7> hi
<XXX7> i'm looking for mark shuttleworth - does he visit irc sometimes?
<fabbione> morning guys
<mdz> morning
<fabbione> hey mdz 
<fabbione> mdz: i think i will fix the brasilian stuff with an exception
<fabbione> when i hit that kind of LANG i can check the status of the debconf db from d-i and see which keyboard map to set
<fabbione> i don't see any better solution in the short term
<mdz> for hoary, we can choose the x keymap and console keymap at the same time with the fancy chooser
<fabbione> yes. i am still talking about warty.
<mdz> I don't mind if you want to ask a question in this case for Warty, but I think Mark probably would :-)
<fabbione> nahhh apparently that's the only problematic layout
<fabbione> so i can workaround without asking the question
<fabbione> mdz: i have another fix pending for X anyway
<mdz> fabbione: there was another one, which I marked as a duplicate of that one
<fabbione> due to a missing us_intl layout
<fabbione> mdz: yes i noticed. That's why i am saying that is the only problematic layout
<mdz> fabbione: do you know what #1089 is about, while we're talking about layouts?
<mdz> fabbione: that was a different layout, wasn't it?
<fabbione> i was reading it.. but deep enough..
<fabbione> i will look at it again
<doko> morning ...
<mdz> morning
<fabbione> mdz: I HAD A NC6000 and it works like a charm
<fabbione> the hu,fi thingy afaik is related to the missing file us_intl
<fabbione> (as i wrote before)
<mdz> ah
<fabbione> the missing layout will also fix 1964
<fabbione> since the layout is NOT there i wonder how the submitter could manage to say that it works
<fabbione> but that's another story
<fabbione> mdz: we might want to up a bounty for XKB stuff
<fabbione> i really don't know enough to even thing about touching it
<mdz> fabbione: who do you recommend?  would denis be interested?
<fabbione> Either Denis or Ivan Pascal (upstream)
<fabbione> Denis is a good guy too
<fabbione> but i don't know Ivan enough to be able to say if he is an ok guy or not
<fabbione> i know that he replied to a couple of my mails
<fabbione> but what he wrote back was kinda.. *interesting*
<fabbione> in terms that it's easy to decode a gpg crypted message with RSA4096 manually than read Ivan's emails
<fabbione> one RC less ;)
<daniels> ivan is alright
<daniels> the 
<daniels> other xkb dude we could get is svu, who's maintaining the xkb stuff at fd.o
<daniels> he seems to know a fair bit about it.
<fabbione> splitnode
<fabbione> damn network
<fabbione> <fabbione> one RC less ;)
<fabbione> that's the last message i saw
<doko> fabbione: you hope they vanished while you were absent? ;)
<fabbione> doko: well ... yes!
<pampa> is anyone from the laptop team here?
<pampa> ok, I guess not
<pampa> I just want to let you know that there is a great program for toshiba laptops
<pampa> http://fnfx.sourceforge.net/
<pampa> that maps the fn-fx keys
<pampa> in my laptop in particular (i guess others too)
<pampa> you can't change your monitor brightness if you don't have this
<pampa> or you can use the toshiba extensions to echo some values
<pampa> to acpi
<mdz> pampa: interesting, send an email to the ubuntu-devel mailing list
<mdz> it's a bit late to add new things to Warty, but we'll see
<pampa> ok, I'll do
<pampa> they even have debian packages which I'm using it now
<pampa> without any problem
<pampa> can I send an email without being subscribed?
<mdz> it will be moderated, but yes
<mdz> I'll approve it :-)
<pampa> ok
<pampa> I'll do it tomorrow
<sabdfl> morning mdz
<mdz> sabdfl: morning
<mdz> was that a trick to see if I was taking my own advice?
<sabdfl> taking your own advice?
<mdz> I sent an email earlier
<sabdfl> let me see
<sabdfl> mdz: good thinking on both counts
<mdz> I'm just making a last desperate effort to fix #1943
<mdz> it's brutalizing a lot of users and seb can't reproduce it yet
<mdz> but I can
<sabdfl> ok, then i don't want to see you on this channel all day, 'k?
<mdz> that's the plan
<sabdfl> enjoy
<sabdfl> i got a good nights rest last night, and plan to again tonight, but need to keep coding today
<sabdfl> it's a big cleanup and best done while the rest of the team is resting
<sabdfl> i gave them basically the same instructions for the w/e :-)
<mdz> GMTA :-)
<doko> fabbione: ping?
<azeem> so I read in some comments to some ubuntu review that Canonical/Ubuntu was working/pondering on another GNOME APT/dpkg frontend. Any truth to that rumor?
<chrisa> I'd be surprised, synaptic seems to work pretty well now
<azeem> it's missing some more HIG/GNOME love, but yeah
<azeem> however, it might be a bit too complicated in some areas
<hazmat> otoh, it would be nice to see all this python lovin come to some pratical use ;-)
<pitti> Night everybody!
#ubuntu-devel 2004-10-15
<tseng> jdub: daniels any of you dudes have an interest in hardening?
<tseng> ssp, pie
<fabbione> morning guys
<fabbione> mdz: ping
<pitti> Morning
<doko> morning
<mdz> morning
<Mithrandir> mdz: uhm, you're not supposed to say "morning" when it's morning here. :)
<fabbione> mdz: hey
<mdz> "morning" is the time when one appears on IRC
<Mithrandir> well, true
<mdz> fabbione: so, we seem to have inherited many of these file conflict bugs :-/
<fabbione> mdz: yes i saw them. I need to prepare X for upload with some fixes and i am on them.
<mdz> fabbione: I think that almost all of them are NOTWARTY (universe packages)
<mdz> they are assigned to both packages, but generally it is the universe one which is buggy :-)
<fabbione> mdz: ok
<fabbione> mdz: i need a decision on 1878 now
<mdz> fabbione: confirm a couple of things for me please
<mdz> fabbione: 1. current via driver is buggy and hangs systems
<mdz> fabbione: 2. new via driver from x.org is not significantly better
<mdz> ?
<fabbione> mdz: the driver from x.org = the one we have. The driver from unichrome is not that better. It still has a lot of glitches here and there
<daniels> does it introduce new ones?
<fabbione> I try it seems to be impossible to make TV-out output be "nice": it has
<fabbione> _lots_ of flicker and overscan, and everything is offset to the right
<fabbione> (so when you're watching DVDs, you miss the right half of the movie).
<fabbione> daniels: yes
<daniels> i.e. are we talking about buggy (vs non-existant) support for chipsets we don't support now?
<daniels> or screwing up chipsets that were previously OK
<daniels> if so, it's not worth reverting
<daniels> (imo)
<fabbione> daniels: that was ok before
<fabbione> TReenaks: can you confirm?
<daniels> argh!
<fabbione> + the VT switching. i guess that was working before too
<daniels> no, previously it just hung from Kamion
<daniels> s/from/for/
<daniels> that's progress ;)
<fabbione> daniels: well he wrote something different in the bug report
<mdz> there will be hardware and features that Warty does not support, this is unavoidable and not an RC issue.  However, Warty should not hang the system even if it doesn't properly support the hardware
<fabbione> X starts up fine with the new driver (I suspect it might have started up with
<fabbione> the old driver too if I'd had my font packages configured correctly);
<daniels> mdz: right
<daniels> mdz: hence my suggestion of just having all of via use vesa
<daniels> mdz: afaict that's the least-bad case
<daniels> may not support everything, but it doesn't hang
<daniels> via seems to be a total basketcase in general
<daniels> (the via-supplied driver doesn't even work, there are two external projects -- one of which is dead -- to fix it, but neither of them have great access to hardware)
<mdz> I've never encountered a via graphics card
<mdz> are there some which work correctly?
<daniels> mdz: mercifully, they seem to be rare
<daniels> mdz: i don't know. i assume so, but I've not seen any success reports (not that we tend to, obviously; just the bug reports)
<daniels> i have no access to via, and it's not something I'm terribly upset about
<fabbione> i still suggest that if we enounter a via card, we ask for the driver and we don't probe
<fabbione> i am really not happy to default to vesa
<pitti> mdz: can you please approve #2051? It's trivial (the gimp-print force-reload fix)
<pitti> Hi carlos_!
<mdz> yes
<doko> mdz, mithrandir: what do we want to do about the amd64 gcc-3.3 biarch?
<carlos_> hi
<mdz> doko: well, we only use it for grub and oo.o, right?  as long as the changes are obviously correct and cannot introduce regressions, I think we can do it
<mdz> we should only need to verify grub and oo.o if it is simple enough
<mdz> doko: but when I look at the bug report, it sounds like too big a change for 9 days from release
<mdz> it must touch 3 or 4 packages, replacing things which have been tested and work with new code...
<mdz> jdub: do you have an opinion on #1996?
<doko> yes, it touches many things. however they all look straight forward. for gcc-3.3 I outlined a less invasive approach (and not touching grub). For the gcc-3.4 change, ia32-libs-ooo is affected too.
<mdz> elmo_: you were looking for me earlier?
<elmo_> wondering if ndiswrapper should be going to main?
<elmo_> (cf. jabber)
<doko> elmo_: do we have a ubuntu-admin@, or is this just thom@ ? ;)
<mdz> elmo_: tricky question
<elmo_> doko: admins@admins atm
<elmo_> err, admins@admins.warthogs.hbd.com I mean
<mdz> elmo_: what does Mark say?
<elmo_> the RFC-required addresses at @ubuntu.com etc. will work, but we don't have a proper admins one setup yet
<elmo_> mdz: dunno, he's busy deciding out fate for the day(tm) with Steve - I'll ask him afterwards
<mdz> elmo_: I think it probably belongs in SupportedSeed, but please confirm
<fabbione> mdz, daniels: #ubuntu-meeting please
<seb128> morning
<elmo_> mdz: mark confirmed main - any more detail someone else will have to ask him if needed
<pitti> Morning seb128!
<seb128> hello pitti 
<carlos> seb128: hey
<mdz> elmo_: I'll add to SupportedSeed
<mdz> elmo_: please move pnm2ppa into main; I added it to a seed already
<plovs> are there any ops for the #ubuntu channel? 
<mdz> plovs: why, is there a problem?
<plovs> mdz, some people needs some kicking :)
<plovs> ubuntu has been on slashdot you know
<elmo_> mdz: as long as wvdial is in the seed list it's almost impossible for me to detect any other changes
<mdz> elmo_: yes, that is overdue for fixing
<mdz> apparently, the only other package which uses libwvstreams is "retchmail"
<mdz> which doesn't sound like it uses all the crazy stuff in that library either
<mdz> so I'm thinking we should just have a minimal build of libwvstreams
<Kamion> morning
<mdz> Kamion: morning
<mdz> Kamion: the natives are anxious for the new live CD :-)
<Mithrandir> do we have a bug# for the "splash screen stays around after logging in"?
<mdz> elmo_: minimal wvstreams uploaded, should not require any other packages from universe
<mdz> Mithrandir: with or without causing the entire login process to fail?
<mdz> with = 1943
<mdz> without = an old bug which was closed
<Mithrandir> without
<Mithrandir> mdz: on the mysterious system hangs bug -- it seems like it only happens with some packages, not all..
<mdz> Mithrandir: 1725
<mdz> seb128: ping?
<seb128> pong
<Mithrandir> I love how gnome-terminal is able to use 50% cpu on a 2.4GHz P4 when running tar cvzf
<mdz> seb128: so about #1943...:-)
<seb128> turn sound events off by default ? :)
<mdz> seb128: I confirmed that disabling gnome-settings-sound.c:apply_settings works around the bug
<mdz> so it is definitely related to the sound init
<mdz> though I have not been able to find the exact problem
<mdz> seb128: I would prefer to fix the bug, to be honest :-)
<daniels> mdz: ping?
<mdz> seb128: is there someone who is familiar with that reaper.c code?
<seb128> this part of code is not really maintained upstream, so dunno where to get help. I've not knowledge of this part of code either and I'm not able to reproduce it here ...
<seb128> I would like to fix it too
<seb128> but I've no real idea on where to start
<mdz> it is so strange that you cannot reproduce it
<mdz> seb128: I can give you a shell on my machine if it would help
<mdz> seb128: it is easy to reproudce at the command line
<mdz> by running gnome-settings-daemno
<seb128> ok, I'll have a serious look on this now. I'll start by making some extra tests on my test box and read the code
<seb128> and then I'll ping you back if I need a shell. But I would like to reproduce it here, more easy to debug in local
<mdz> seb128: thanks, this is high priority because many users are encountering it, and it completely breaks their system
<seb128> on my box, if I "lsmod | grep '^snd' | awk '{ print $1 }' | xargs -n1 sudo rmmod" and login again, I don't even have a line about /dev/dsp
<mdz> seb128: if you cannot isolate the problem today, we will need to disable sound events
<mdz> seb128: that's strange; you have sound server startup enabled?
<seb128> yes
<seb128> sound events are working
<seb128> I log out, remove the sound modules and log in again
<seb128> no problem, no error in the log
<seb128> I just get the volume applet to 0
<Kamion> mdz: yeah, I know, will put it up this morning
<Kamion> mdz: I'm just going to shove it in /releases/warty/preview/ for now (the location in the full tree is orthogonal to Mark's request for a simplified tree)
<azeem> seb128: didn't hadess blog about sound being muted on startup recently?
<azeem> might have been a different issue though
<Kamion> wow, #ubuntu is a cesspit now
<azeem> are the forums up yet?
<Kamion> fabbione: defaulting to vesa seriously seems to be much more sane for the two via machines I have here; if you must ask, then at least please default to vesa not to via, I don't want to have to deal with the broken installations that will result otherwise
<seb128> azeem: dunno, apparently you read a lot more blogs than me
<seb128> azeem: any idea of the date of this blog entry ?
<mdz> azeem: I think in this case it is set to 0 because there is no mixer device
<azeem> seb128: heh, it might have been somewhere else again ;)
<seb128> mdz: do you have esd running when to problem happens ?
<mdz> seb128: no, esd cannot start because there is no /dev/dsp
<mdz> it could be some kind of race condition, but my laptop loses 100% of the time
<azeem> http://www.hadess.net/?start=453
<azeem> "The next piece of work for system-config-soundcard is to fix the fact that ALSA starts up muted, and that the UI is starting to suck a bit"
<seb128> ok, on this box I've a lot of "/dev/dsp: No such file or directory" in the log
<seb128> but no problem to login
<mdz> #2  0x0805de6f in vte_reaper_signal_handler (signum=-512) at reaper.c:64
<mdz> I have no idea where signum=-512 comes from
<seb128> vte is a terminal emulator
<seb128> what is that doing here ?
<mdz> that code is in reaper.c in gnome-settings-daemon
<mdz> perhaps the code was copied from another place
<mdz> anyway that handler is only called for SIGCHLD
<mdz> and there is a test in the handler for that
<mdz> so i think gdb is just lying
<elmo_> gnome-nettool is pulling in tcptraceroute which is pulling in libnet0 and rman
<elmo_> ok?
<mdz> gah
<mdz> how about we remove the dependency on tcptraceroute?
* daniels returns from battle with pppconfig, bloodied but victorious.
<daniels> that thing is bloody *obscure*.
<daniels> mdz: permission to upload http://people.ubuntu.com/~daniels/pppconfig/pppconfig-2.3.2ubuntu2-to-ubuntu3.diff ?
<mdz> daniels: yes, thanks
<mdz> I love it when gdb suspends itself and goes into the background
<mdz> that's just the best
<mdz> Detaching after fork from child process 10714.
<mdz> /dev/dsp: No such file or directory
<mdz> Detaching after fork from child process 10716.
<mdz> /dev/dsp: No such file or directory
<mdz> zsh: suspended (tty output)  gdb .libs/gnome-settings-daemon
<mdz> after it does that it seems impossible to get it back; even if I continue it, it doesn't respond to any signals so i can't get back to the debugger
<Mithrandir> run gdb on it?
<seb128> ok, I've tried with the esd maintainer and some other GNOME guys, no clue
<seb128> only advice "run away of this part of code if youy can" :(
<mdz> great
<Mithrandir> mdz: do you have a p4 with HT around?
<mdz> Mithrandir: no, I do not
<mdz> there might be someone I could ask, but they are asleep
<Mithrandir> I can reproduce 1854 with debootstrap here.
<Mithrandir> I haven't tried with a full fresh install, since I forgot to bring an extra hard drive today.
<seb128> mdz: if you try to run esd from the command line, what happens ? 
<seb128> any output, error, log ?
<mdz> potpal:[...2.8.0/gnome-settings-daemon]  esd
<mdz> /dev/dsp: No such file or directory
<mdz> exactly what I see in xsession-errors
<seb128> $ esd
<seb128> $
<mdz> fascinating
<seb128> no log, no error
<mdz> potpal:[...2.8.0/gnome-settings-daemon]  md5sum =esd
<mdz> 59ad6b41a3c86f4e2e8be91a8b10c1ba  /usr/bin/esd
<mdz> your esd != my esd?
<seb128> on this box yes
<seb128> but I've built the package, so that's not the autobuilded one
<Mithrandir> mdz: linux-image-2.6.8.1-3-686-smp version 2.6.8.1-9; debootstrap warty /somewhere ; chroot /somewhere ; <edit sources.list>; apt-get update; aptitude install '~tdesktop'
<mdz> seb128: ok, I have a workaround
<seb128> mdz: could you try to rebuild esound ?
<mdz> or perhaps a fix
<seb128> oh ?
<mdz> I disabled all of the pipe crap in the reaper
<Kamion> Mithrandir: ~tubuntu-desktop
<Kamion> surely?
<mdz> as far as I could tell, its only purpose was for a debug/error message
<mdz> and it looked buggy
<Mithrandir> Kamion: yes, sorry, I was reading off an xscreenlocked screen. :)
<seb128> ok, nice
<mdz> seb128: I attached the patch to the bug
<seb128> ok
<seb128> mdz: dpkg -l | grep esd ?
<mdz> seb128: I still get WAY too many error messages
<mdz> but at least it lets me login
<mdz> "/dev/dsp: No such file or directory" is repeated hundreds of times
<mdz> and it tries to fork esd hundreds of times, which is a bit slow
<mdz> ii  gstreamer0.8-esd    0.8.4-1ubuntu3      Enlightened Sound Daemon plugin for GStreamer
<mdz> ii  libesd0             0.2.35-0ubuntu1     Enlightened Sound Daemon - Shared libraries
<mdz> ii  libesd0-dev         0.2.35-0ubuntu1     Enlightened Sound Daemon - Development files
<seb128> could you try with libesd-alsa0 ?
<seb128> I've this one on this box in fact
<seb128> instead of libesd0
<mdz> libesd-alsa0 is crashy
<seb128> hum
<mdz> try it with libesd0 :-)
<seb128> I'm installing it
<mdz> perhaps then you can reproduce it
<mdz> and then you could verify my patch
<seb128> but on my test box which is a non-modified warty install, no problem
<seb128> $ esd
<seb128> /dev/dsp: No such file or directory
<seb128> ok
<seb128> the non-alsa version sucks
<seb128> are you sure that the alsa version is crashy ?
<seb128> 0.2.29 was crap
<Mithrandir> Kamion: ~tdesktop seems to work fine as well
<mdz> that is why we removed it from desktop
<mdz> even after I fixed the bugs that I saw, it was crashy
<seb128> but 0.2.35 should fixe most of the issues
<mdz> it may be that 0.2.35 is better
<mdz> but this is not an esd bug
<seb128> that an esd/settings-daemon interaction
<Kamion> Mithrandir: strange, there's no Task: desktop any more; maybe aptitude is too clever for its own good
<Mithrandir> Kamion: it probably does substring match -- either works
<mdz> seb128: right
<seb128> mdz: ok, the non-alsa version flood the .xsession-errors, but doesn't hold the session here
<Mithrandir> Kamion: ~tdesk seems to work as well
<Kamion> Mithrandir: seems like bad behaviour, it means the result of the command can radically change if an extra task is introduced
<mdz> seb128: I have no idea why it doesn't break for you, but the patch fixes it for me
<seb128> ok
<Mithrandir> Kamion: true
<seb128> mdz: let's upload a package with the patch and see how it goes ?
<mdz> seb128: ok
<seb128> mdz: could you try without the patch with the alsa version of the lib ?
<seb128> to know if that holds the session too
<mdz> seb128: the stuff that I disabled only existed to emit a signal "child-exited" when the child exited
<mdz> but there was nothing listening for it
<seb128> ok
<mdz> I think this code was cut-and-waste from elsewhere
<seb128> probably
<mdz> ok, I will revert to unmodified g-s-d and install libesd-alsa0
<seb128> thanks
<mdz> seb128: it does not seem to hang with libesd-alsa0
<seb128> ok
<mdz> switched back to libesd0, hangs
<mdz> killall gnome-settings-daemon, install patched gnome-settings-daemon, works
<seb128> ok
<seb128> let's use the patch for now, but we should consider switching to the alsa version after warty
<mdz> after warty hopefully we will get rid of esd :-)
<seb128> true :)
<mdz> yes, let's go with the patch
<daniels> mdz: ok, so for #1897 we just clobber the file if either exists?
<daniels> mdz: about to take care of that now
<carlos> seb128: after warty, esound should die :-P
<mdz> daniels: I'm fine with something similar to the supplied patch, but using grep instead of sed :-)
<aj> elmo_: ?
<mdz> I would probably have merged the stupid thing a year ago, except that I saw that sed and wanted to fix that first
<elmo_> aj: ?
<aj> elmo_: you "?"ed earlier?
<elmo_> oh, one sec
<daniels> mdz: yeah, as I said :)
<daniels> mdz: heh, fair cop
<daniels> mdz: permission to upload http://people.ubuntu.com/~daniels/dhcp3/dhcp3-3.0+3.0.1rc14-1-to-ubuntu1.diff ?
<mdz> daniels: tested the hell out of it?
<daniels> as much as I can, but I suppose more testing is always welcome
<mdz> I don't have one of those broken dhcp servers handy which doesn't hand out nameservers
<daniels> especially with something like the DHCP client
<daniels> mdz: ... me neither
<mdz> the code for the reasonable case is obviously well-tested and unchanged
<mdz> daniels: go ahead and upload
<daniels> mdz: (I just yanked that portion out and played around with calling with different variables)
<daniels> mdz: thanks
<mdz> as long as there are no regressions in the non-broken-dhcp-server case
<daniels> not that I can see
<elmo_> mdz: wvdial's in - I'll hold off on gnome-nettool's deps for now - lemme know if you decide to not fix the package
<pitti> mdz: do you want to have all these universe file conflicts resolved for warty? I can do some of them
<Kamion> I should look at debconf-doc/cdebconf, I guess
<Kamion> um
<Kamion> why does show_bug.cgi return 403?
<Kamion> ah, fixed apparently
<pitti> @all: http://www.piware.de/hal/ contains a new hal package which (among other things) should fix the "sometimes the first plugged in device is not recognized" bug (#1954); can somebody verify that?
<pitti> @all: for me it works perfectly, but since upstream did not confirm the fix yet, it should get more than one person for testing it
<sjoerd_> pitti: could you let me know the results of people testing that :)
<pitti> sjoerd_: of course; I will send my latest three patches to David and you anyway
<sjoerd_> pitti: nice, thanks
<pitti> sjoerd_: BTW, does the patch work for you? Then I had already a second person :-)
<pitti> sjoerd: (I assume it, because you have written it) :-)
<sjoerd> pitti: yes ofcourse it does ;)
* pitti goes to have lunch
<daniels> mdz: oh, yay! cpad is ... um ... interesting.
<daniels> mdz: needs a separate driver, but it appears to register as a usb input device and also lcd
<daniels> mdz: so you can draw shit on your touchpad (!)
<Mithrandir> run xterm on your touchpad today!
<daniels> if you wanted to, yeah
<daniels> someone made an X server with a cpad output device
<fabbione> daniels: i really think 1089 will be fixed with Denis and my changes
<fabbione> daniels: he completely forgot to install the pc/us_intl layout :P
<fabbione> if you want to reassing to me go ahead
<daniels> haha yeah, I saw that :)
<daniels> ok, another bug off my hands is good
<fabbione> i am almost done with 1964 too
<daniels> thanks
<daniels> sounds cool :)
<daniels> fabbione: http://www.dietmar-kuehl.de/Xcpad/
<fabbione>     db_get debian-installer/keymap || true
<fabbione>     if [ "$RET" = "br-abnt2" ] ; then
<fabbione>       LAYOUT="br"
<fabbione>     else
<fabbione>       LAYOUT="us_intl"
<fabbione>     fi
<fabbione>     XKBOPTIONS=""
<fabbione>     ;;
<fabbione> the other exception for br -> abnt2 was already there
<fabbione> so already defining the proper LAYOUT will do the trick
<fabbione> but we must have the ub3r keyboard setting tool for hoary
<fabbione> going or LANG isn't enough
<Kamion> we'll have localization-config from Debian for hoary ...
<Kamion> (Konstantinos' thing)
<fabbione> Kamion: yes. the cose i am using has been stolen from it
<mdz> pitti: don't bother with the file conflicts if the universe package is the buggy one
<mdz> pitti: downgrade the bug if it is universe's fault
<fabbione> 2 problems: 1) he didn't coordinate with X at all. He preseeds templates that might not even be there (last time i checked at least)
<pitti> mdz: okay
<fabbione> 2) the templates needs to go in something/shared and we need to sync translations & co. that hasn't been done
<mdz> pitti: I can't reproduce the "first plugged in" bug, at least not reliably
<Kamion> mdz: we forgot to make lsb-release's Ubuntu version number consistent with everything else (i.e. "4.10" rather than "4-10"); OK to upload?
<mdz> Kamion: yes
<pitti> mdz: its not reliable anyway (it's a race condition)
<fabbione> mdz: you marked 2007 as duplicate of 1964 but they aren't really the same
<pitti> mdz: I thought you were already asleep, but you can test my package before approval
<fabbione> mdz: one option to catch all the possibility is to confirm the layout when LAYOUT=unknown or LAYOUT=us, that seems to be most common problem.
<pitti> mdz: http://www.piware.de/hal/hal_0.2.98-1ubuntu5_i386.deb
<mdz> fabbione: I mentioned that on Saturday, but you said it was the same
<daniels> mdz: comments on 2026 and 2057?
<mdz> already commented on 2026, keep up
<daniels> yeah, just got the mail
<daniels> it's not my fault every bug takes like 3 minutes to load
<daniels> :P
* Kamion gets slightly scared that he's now using db_register routinely
<daniels> Kamion: how I learnt to stop worrying and love dhb_register
<mdz> pitti: I have never seen the warning emitted by that code block
<fabbione> mdz: well i read it again and i noticed that it is not exactly the same
<daniels> mdz: basically, we don't have any support for those touchpads whatsoever (for the cPads, we cannot make a working configuration out of the box; I believe we cannot get any working ALPS configuration) and doing both of 2026 and 2057 would fix this
<mdz> fabbione: ok, feel free to fix up the bug
<fabbione> mdz: asking the question if LAYOUT=unknown or LAYOUT=us ?
<mdz> daniels: ok, that's just missing hardware support, and we'll have that.  not RC, then
<daniels> mdz: -> hoary?
<mdz> fabbione: why LAYOUT=us?
<mdz> daniels: yes
<daniels> mdz	fair cop
<fabbione> mdz: 2007 got a US layout when it should have been es
<fabbione> mdz: probably due to a lang setting
<mdz> fabbione: so probably he chose English install but with Swedish keymap?
<fabbione> mdz: could be...
<fabbione> we don't have console -> X mappings
<fabbione>   *"SE"* ) LAYOUT="se" XKBOPTIONS="" ;;
<mdz> seb128: is it possible to remove the tcptraceroute dep from gnome-nettool?
<fabbione> mdz: he must have got a strange LANG or something that we don't handle directly
<fabbione> mdz: that would explain the "bug"
<fabbione> but there is no winner here until we don't have console -> X keyboard maps
<seb128_> mdz: if we remove a part of the UI yes
<fabbione> daniels:
<fabbione> # Specific via workaround:
<fabbione> if [ "$DEFAULT_DRIVER" = "via" ]  || [ "$DEFAULT_DRIVER" = "vesa" ] ; then
<fabbione>   PRIORITY="high"
<fabbione> fi
<fabbione> db_subst xserver-xfree86/config/device/driver choices "$DRIVER_LIST"
<fabbione> auto_answer db_input "$PRIORITY" \
<fabbione>   xserver-xfree86/config/device/driver "$DEFAULT_DRIVER"
<fabbione> this will ask for the driver if we detect via or the driver is vesa (that is never returned by discover1)
<fabbione> that means=unknown
<daniels> ok
<daniels> that saves me s/via/vesa/ in discover1-data
<daniels> fabbione: fine by me
<daniels> fabbione: you might want to mention that the via driver is buggy as shizzle in that comment
<fabbione> # Specific via workaround:
<fabbione> # the via driver sucks nuts and we can't rely on it. The user will
<fabbione> # have to decide which cracks he prefers and he has 3 options:
<fabbione> # - via
<fabbione> # - vesa
<fabbione> # - visa (or mastercard) to buy a serious video card
<azeem> heh
<pitti> mdz: (sorry, lunch) the new warning is only written in the case where the previous hal segfaulted (as you wrote in the bug)
<daniels> fabbione: heh :)
<fabbione> ok agreed :-)
<mdz> pitti: no, I meant the other patch
<fabbione> time to ban the probe now
<mdz> pitti: the one which removes the sequence number check
<pitti> mdz: ah; I have seen it several times
<pitti> mdz: the last_sequence_number (or so) had a random number and the comparison result was more or less random
<pitti> mdz: BTW, you do not follow your own advice in your energy mail...
<mdz> pitti: today is monday :-P
<pitti> mdz: ask your body :-)
<daniels> mdz: do I get to take Tuesday off in compensation for having worked half of Sunday? ;)
<mdz> pitti: I needed to wake up at 0500 today anyway to take monika to the airport
<mdz> and finish getting ready for the fumigation
<fabbione>       # we know the driver from config.in
<fabbione>       db_get xserver-xfree86/config/device/driver
<fabbione>       DEVICE_DRIVER="$RET"
<fabbione>       case "$DEVICE_DRIVER" in
<fabbione>         via)
<fabbione>           PROBE_DUMP="" 
<fabbione>         ;;
<fabbione>         *)
<fabbione>           set +e
<fabbione>           PROBE_DUMP=$(xresprobe "$DEVICE_DRIVER")
<fabbione>           set -e
<fabbione>         ;;
<fabbione>       esac
<fabbione> daniels: ^^^ banning via from probing
<daniels> fabbione: hm
<pitti> mdz: so far the hal package works for you? Then we are already three; I will still wait a bit, maybe thom returns in the next hours
<mdz> pitti: I have not tested it
<daniels> fabbione: why not do if [ "$RET" = "via" ] ; DEVICE_DRIVER="vesa"; fi
<daniels> fabbione: that still allows for DDC probes, which are harmles
<fabbione> daniels: hmmmmmmmmmmm
<fabbione> daniels: what if the card looks up the machine?
<daniels> fabbione: on a DDC probe? then shit dude, it has bigger problems
<daniels> fabbione: and will be unusable with the vesa driver also
<daniels> think of it as an early warning if a VESA VBE DDC probe kills the machine :)
<fabbione> daniels: didn't you say that via doesn't return DDC stuff because it doesn't store it in the NVRAM?
<fabbione> or BIOS or whatever
<daniels> fabbione: only for laptop panels, and we were trying with read-edid, not ddcprobe
<daniels> read-edid actually misses a massive chunk of the DDC data
<daniels> if we try it with ddcprobe, the best case is we get a working resolution, the realistic worst case is that the resolution is wrong
<fabbione> daniels: i see your point, but i am really not too happy to force that on cards that already sucks
<fabbione> daniels: i much rather prefer to ask the resolution
<fabbione> without hanging the machine
<fabbione> since we can't test it, i would much rather prefer to skip it
<fabbione> 100% to be safe
<daniels> fabbione: um
<daniels> seriously, as I said, if it hangs on a DDC probe, then it won't be able to use either the VESA or Via driver
<daniels> it will also die on Windows installs
<fabbione> ok
<fabbione>       db_get xserver-xfree86/config/device/driver
<fabbione>       DEVICE_DRIVER="$RET"
<fabbione>       if [ "$DEVICE_DRIVER" = "via" ] ; then
<fabbione>         DEVICE_DRIVER="vesa"
<fabbione>       fi
<fabbione>       set +e
<fabbione>       PROBE_DUMP=$(xresprobe "$DEVICE_DRIVER")
<fabbione>       set -e
<fabbione> there
<daniels> cool
<fabbione> daniels: 1999
<fabbione> any idea?
<fabbione> we didn't touch that code at all
<fabbione> and he seems to be the only one with that problem
<daniels> ?!?
<fabbione> otherwise we would have received a few tons of bugs
<daniels> the title looks bizzare, but the body will take like a minute to come down still
<fabbione> no problem
<daniels> wtf
<daniels> i suggest local problem
<daniels> probably hanging on IO?
<fabbione> daniels: i have really no idea
<fabbione> i am pretty sure it's not a problem in the script
<fabbione> we would have noticed in debian too
<daniels> yeah
<daniels> it's bong
<fabbione> mind to ask or comment?
<daniels> you want me to?
<mdz> seb128: there is a part of the UI which uses tcptraceroute? for what?
<mdz> seb128: can we change it to use tracepath instead?
<seb128> mdz: run gnome-nettool :) The UI has differents tab: traceroute, port scan, finger, whois ...
<seb128> no idea, but I can have a look if you want
<mdz> seb128: at first glance it seems to just provide a way to run the program and view its output
<mdz> so I think tracepath would work fine
<seb128> I think so
<mdz> seb128: do you want a bug as a reminder?
<seb128> yes please
<fabbione> daniels: yes please.
<fabbione> mdz: 2054. there are several differences between the 2 logs
<fabbione> mdz: but 2 of them are quite relevant
<fabbione> -(++) using VT number 8
<fabbione> +(++) using VT number 7
<fabbione> -(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
<fabbione> +(II) PCI: stages = 0x03, oldVal1 = 0x8000003c, mode1Res1 = 0x80000000
<fabbione> -       BytesPerScanline: 528
<fabbione> +       BytesPerScanline: 594
<fabbione> + = working config
<fabbione> - = bad config
<fabbione> how come it starts on vt8 in the first place...
<fabbione> the driver hasn't changed 
<Kamion> pitti: what approach are you taking to the debconf-doc/cdebconf bug? I was just about to fix that in Debian.
<pitti> Kamion: none actually
<pitti> Kamion: I just saw that cdebconf is not installable in Warty anyway
<Kamion> (by adding a conflicts)
<pitti> Kamion: it will remove 1GB of packages
<pitti> Kamion: I can reassign it to you if you want
<Kamion> it is perfectly installable, just not simultaneously with debconf :-)
<pitti> Kamion: but half a thousand packages depend only on debconf
<Kamion> yes, I know
<Kamion> it's not really a bug, cdebconf will probably eventually replace debconf
<Kamion> I'm not sure why it's in warty though
<pitti> Kamion: it is a bug in those many packages; they should depend on debconf|cdebconf, not?
<pitti> Kamion: cdebconf is not in warty
<Kamion> pitti: oh, indeed it isn't, madison output confused me, only the source is there
<thom> pitti: hi. what's up?
<Kamion> pitti: noooooo
<Kamion> pitti: cdebconf is *not ready* to replace debconf yet :)
<Kamion> pitti: just NOTWARTY it then, I'd say
<pitti> Kamion: agreed
<pitti> thom: I wanted to ask you if you could review the hal package in http://www.piware.de/hal/ to check bug #1954
<mdz> need to move stuff out for the fumigation, back later
<pitti> Kamion: I write a bug comment and downgrade
<daniels> fabbione: weird. i dunno about that bug.
<Kamion> RESOLVED/NOTWARTY is not so much a downgrade :)
<Kamion> pitti: fixed upstream, anyway
<pitti> Kamion: okay.
<fabbione> daniels: 1989 -> LATER
<fabbione> daniels: 2054 looks to me a user fucks up
<fabbione> we didn't touch the intel driver at all
<fabbione> we didn't change build kernel on buildd
<fabbione> we didn't change anything that touches dri/drm
* fabbione has NO clue
<thom> pitti: ok, building now
<pitti> thom: i386 packages are already available, btw
<thom> pitti: yup
<thom> uname -m
<thom> x86_64
<thom> :-)
<pitti> thom: I repeatedly restarted dbus, watched whether the first and second hotplug produced a Volume node in device manager, goto 1
<pitti> thom: dbus restarts will kill gnome-volume-manager, but that's not the point here; device manager is good for verification
<daniels> fabbione: bong
<Kamion> pitti: (actually, the eventual solution will more likely be for packages to depend on a virtual package like debconf-2.0)
<daniels> fabbione: I suspect we need XF86Config-4
<pitti> Kamion: right, I actually meant that
<occy> Will the pcmcia issues get worked out before a final release is produced?
<fabbione> wtf is wrong with wmdial that asks me if i want to configure the modem in text mode and at install time?
<Kamion> occy: which pcmcia issues?
<occy> I tried to post a bug detailing my problems on my laptop with the Sept 28, Sept 29, and Oct 1 Nightlies...   But bugzilla ate it. :(
<occy> Kamion: I have a Dell Inspiron 7500  (quite a common older laptop)  and all distros work peachy with pcmcia on it.   Ubuntu hangs during install at loading pcmcia
<thom> pitti: yup, looks good to me
<pitti> thom: fine; plovs also tests it right now, if it works for him, I will upload the beast
<pitti> thom: thanks for testing!
<Kamion> occy: related to bug #581?
<occy> Kamion: let me take a look at that one.
<Kamion> although I think that's a Dell desktop, hm
<occy> by "blocking" does that mean prevent installation?
<Kamion> occy: I'm afraid the way to make sure somebody looks at it *is* to file a bug; if Bugzilla keeps eating it, you might want to mail justdave@canonical.com for help
<Kamion> block means waiting for I/O
<occy> ahh
<occy> Kamion: who is this person?   justdave@canonical.com?  Is he a developer?
<Kamion> he runs our Bugzilla installation
<daniels> occy: david miller, our bugzilla dude
<occy> daniels: ahhh... "The Bugzilla Dude"&copy;
<occy> tx guys
<occy> https://bugzilla.ubuntu.com/show_bug.cgi?id=2059
<occy> :)
<occy> Is there any other information I could attach to that bug that might be helpful?
<Kamion> occy: there should be some relevant log messages on tty3 or tty4 (use alt-f3 and alt-f4 to get to them)
<occy> ahh ok, let me go do that so I can add it to the bug.  tx.    /me reboots to get the bug again.
<occy> :)
<occy> tx gang
<occy> Kamion:  Warning: **: bad d-i Packages file   grep:  /cdrom/dists/stable/Release     : Not a directory.      This repeats in a loop.
<occy> Kamion: that same CD installed on my desktop just peachy.
<Kamion> occy: you probably have DMA problems then, we recently disabled DMA by default for CD drives to avoid this problem
<occy> ahh
<occy> ok, I'll go grab a new nightly bud.  tx :)
<occy> sorry to bug the devel channel
<occy> oh, one last thing.  If that fixes it, should I delete that bug?
<Kamion> certainly tell the bug about it
<occy> k
<fabbione> daniels: are you still around?
<daniels> fabbione: sup?
<fabbione> daniels: ubuntu23 is up
<daniels> yeah, saw it on -changes just then
<fabbione> ok good
<fabbione> i am off
<daniels> looks good -- i have a few things to do around the house (moving back out on thursday) so I'll eb around for a while
<fabbione> i start to dream about X.org at night
<daniels> i'll keep an eye on the logs/bz/etc and fix it if anything goes badly wrong
<daniels> dude!! stop working on x for a while.
<fabbione> ok good
<daniels> i had a dream about introducing a rgb vs bgr bug in the x server once and in my dream, I debugged it with a lot of ErrorF()s and gdb
<daniels> and fixed the bug
<daniels> that was pretty bad
<fabbione> daniels: that crack for X.org is good you have no idea
<daniels> heh heh :)
<fabbione> even Branded liked that crack so much that he is all high up for it
<daniels> well, I've gotta pop off for a few minutes, so have a good lunch or whatever, and take care :)
<daniels> hahaha
<fabbione> yeah later
* fabbione knows that he will be soon left alone as X.org maintainer for Debian and Ubuntu
<daniels> nah dude, I'm still here
<fabbione> daniels: you are supposed to be my upstream bitch :P
<daniels> i can be both :)
<fabbione> ahhah you love to suck, don't you ???
<fabbione> later bitch^Wdaniels
<elmo_> is it just me or is "build a kernel image with the warty source" far more complex than it ought to be?
<Kamion> is it not just dpkg-buildpackage from the source package?
<elmo_> err, that'll build all the madness ?
<elmo_> I mean build a custom kernel image
<elmo_> 'export PATCH_THE_KERNEL=yes' isn't exactly intuitive, IMO
<elmo_> CONFIG_BROKEN=y
<elmo_> mmk
<Keybuk> make-kpkg, especially all the patch gubbins, has always been a little Manoj for my tastes
<Kamion> can someone peer-review my patch in #1332 for me, please?
<Kamion> I've tested it in all three mentioned cases
<elmo_> I guess the /tmp use is safe (?), but it's security-team bait :)
<Kamion> the /tmp use in question is run inside d-i, where there are no other users
<elmo_> right.. anyway, nm
<elmo_> it looks fine to me, FWIW, but I can't test it
<Kamion> yeah, not really expecting anyone else to be able to yet :/
<Kamion> thanks
<thom> elmo_: can you apply the patch in #1960 to /usr/bin/mozilla-firefox and confirm it fixes the problem for you?
<elmo_> thom: yes, works for me
<thom> goodo
<thom> mdz: can i upload php with either mine or adam's patches? I don't think going with a new upstream is a good move
<mdz> thom, which is better, yours or his?
<thom> mine fixes a printf, other than that they're identical
<mdz> your call then
<mdz> one of them is OK by me
<thom> k
<mdz> but not both :-)
<fabbione> thom: upload adam's one.. you can have someone else to blaim ;)
<mdz> latest ipw2200 is working nicely
<thom> fabbione: i'm planning to blame you either way :-)
<fabbione> i know NOTTING about php ;)
<thom> mdz: and new firefox with the fix for #1960 also?
<thom> fabbione: that's why you're perfect to blame ;-)
<mdz> thom: 1960 looks good to me
<mdz> Kamion: did I ask you already about using the linux-* metapackages in base-installer?
<mdz> I'm a bit out of it and can't recall
<thom> Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20041004 Firefox/0.10.1 (Ubuntu)
<Kamion> you did, about to look at that now
<Kamion> just uploading that prebaseconfig/base-config thing for UTC handling first
<mdz> argh, silly xchat
<mdz> Kamion: I fixed them up so that they're actually installable on all architectures
<Kamion> mdz: although it's a little awkward due to the lack of easily greppable naming pattern, hmm
<mdz> I think we should probably clean them up so that they don't require 3 levels of metapackages, but that can come later
<mdz> I think linux-foo should depend directly on linux-x.y.z-n-foo
<mdz> rather than via linux-image-2.6-foo
<Kamion> kernel_update_list () {
<Kamion>         # Using 'uniq' to avoid listing the same kernel more then once.
<Kamion>         (set +e;
<Kamion>          chroot /target apt-cache search kernel-image | grep ^kernel-image;
<Kamion>          chroot /target apt-cache search linux-image | grep ^linux-image) | \
<Kamion>         cut -d" " -f1 | uniq > $KERNEL_LIST
<Kamion> }
<Kamion> I'm trying to figure out what to do with that bit ...
<mdz> hmm, that's inconvenient
<mdz> if not for amd64, linux-[^-] * would work
<mdz> I'm a bit crippled on my laptop right now, it having recently been reinstalled and hurriedly prepped to be my primary workstation for a couple of days
<mdz> could someone kindly clean up my mess and squash #2063?
<Kamion> also linux-686-smp etc., which would work on netboot installs
<Kamion> does apt-cache search look at the source package name?
<mdz> don't think so
<mdz> that command-line really should use apt-cache search -n
<mdz> that grep seems to be working around the lack of -n
<Kamion> -n?
<mdz> --names-only
<mdz> matches the package name only, not description
<Kamion> it also works around lack of ^ in the apt-cache search
<mdz> yes...
<Kamion> does apt-cache search --names-only ^kernel-image work?
<mdz> in fact what that really wants to be is "apt-cache pkgnames linux-image"
<mdz> Kamion: absolutely
<mdz> but apt-cache pkgnames would avoid the cut and uniq as well
<Kamion> apt-cache pkgnames returns packages that are not actually available
<mdz> not that we should be tweaking for elegance reasons at this point, really...:-)
<Kamion> <cjwatson@cairhien ~>$ apt-cache search --names-only ^kernel-image | grep 2.2.20<cjwatson@cairhien ~>$ apt-cache pkgnames kernel-image | grep 2.2.20            kernel-image-2.2.20-pmac
<Kamion> kernel-image-2.2.20-prep
<Kamion> kernel-image-2.2.20-chrp
<Kamion> oopsie, but you get the idea
<mdz> true, it'll likely match anything mentioned in a dependency relationship
<Kamion> anyway, still leaves the problem of how to find the metapackages
<Kamion> shame I didn't think of this before, I'd have suggested linux-meta-*
<mdz> we only have 3 architectures; we could hardcode it
<mdz> *duck*
<Kamion> ewwwwwwwww
<Kamion> we could put grep-dctrl in base and then I could use that :)
<thom> mdz: i'll take 2063
<mdz> thom: thanks
<mdz> apt-cache -n search '^linux-(.86|k7|power|amd64)'
<Kamion> there might be a better way, testing now
<thom> oh. for powernow on amd64 it seems like the only module is powernow-k8; i could just hardcode that based on uname -m :/
<mdz> thom: WFM
<Kamion> hm, no, apt-cache search doesn't look at descriptions
<Kamion> s/descriptions/dependencies/
<Kamion> mdz: you know, "apt-cache search 'Complete Linux kernel on'" is actually slightly less gross :)
<mdz> Kamion: ewwww
<mdz> apt-cache search -n '^linux-' | grep -v '^linux-image'
<Kamion> returns linux-headers
* mdz cries
<mdz> wow, #ubuntu really is a cesspool now
<mdz> but a cesspool of 220 persons(!)
<thom> yeah
<mdz> when did we gain another 40?
<mdz> did the live cd announcement go out? :-)
<Kamion> # apt-cache -n search ^linux- | head -n 1
<Kamion> klogd - Kernel Logging Daemon
<Kamion> WTF?
<thom> and 550 mails on the bugs list over the weekend *sob*
<Kamion> so the grep really is needed
<Kamion> mdz: apt-cache search -n ^linux- | grep ^linux- | grep -v 'linux-\(doc\|.*headers\|.*modules\|patch\|source\|tree\)'
<Kamion> returns the right set ...
<Kamion> I'm rather tempted to suggest renaming the packages while we still can, though
<mdz> I am very partial to the simple linux-foo naming
<Kamion> it really sucks for greppability, though
<mdz> one day you will be able to "apt-get install linux" and have it DTRT :-)
<thom> dpkg-buildpackage -rfakeroot -S -sa  21.50s user 52.98s system 20% cpu 5:57.91 total 
<thom> gosh, i wonder what package that could be
<mdz> hehe
<thom> mdz: oh, hey. everytime i reboot, my evms partition doesn't work till i rerun evmsn - i don't get /dev/evms entries till then
<thom> have i missed something obvious?
<mdz> really? that's odd
<mdz> what if you run evms_activate?
<mdz> oh, I know what it is
<mdz> thom: your evms volumes are on a device that is created when hotplug runs
<mdz> and evms runs ahead of hotplug
<thom> ah, yep.
<mdz> it should probably re-run after hotplug
<thom> or get kicked by udev for certain types of things getting loaded?
<mdz> hmm
<mdz> currently there's no way to tell it only to discover volumes on a certain device
<mdz> but that'd be handy
<thom> that seems to be the way things are heading
<thom> but yeah, i have /dev/evms/home        143G  5.9G  137G   5% /home and it seems to be working nicely - xfs over software raid1 on serial ata
<mdz> thom: configured from the ground up with evms?
<thom> yep
<mdz> nice
<thom> the manual is pretty decent
<mdz> so nice to be able to build a volume like that without prodding 3 or 4 different subsystems with their own config files
<thom> definitely
<thom> especially since evmsgui is just nicely clicky-clicky :-)
<mdz> one of these days someone will write a decent CLI for it
<thom> (you should include a .desktop file for it and include it in System Config)
<mdz> with zsh tab completion *swoon*
<thom> heh, that'd be nice
<mdz> thom: I *so* don't want that support headache :-)
<mdz> the GUI, while very nice, is not exactly desktop-user-friendly
<thom> not quite, no
<thom> it'd be cool tho
* thom -> cinema, bbl
<thom> firefox is crawling up my adsl
<mdz> anyone have a 30-second tutorial to set up outbound smtp auth in postfix?
<tseng> http://www.postfix.org/SASL_README.html
<tseng> doesnt look to hook into pam there
<mdz> tseng: it uses sasl for outbound?
<tseng> oh im sorry i misunderstood
<tseng> you want your mta to send smtp auth to another mta?
<mdz> right
<tseng> hm its in the bok
<tseng> *book.
<tseng> smtpd_sasl_auth_enable = yes
<tseng> er, -d
<hazmat> there's some docs for it on gentoo.org
<tseng> smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
<tseng> hazmat: that doc is ridiculous
<elmo_> 62 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
<elmo_> since 6am this morning! (i.e. like, 14 hours ago).. you guys are KraZY
<tseng> ora.com        kdent:Password
<tseng> is the example sasl_passwd file
<hazmat> tseng, why is that?
<tseng> hazmat: um
<tseng> for one thing it uses pam_mysql to read mysql user info when sasl can do it directly
<tseng> also it uses $variable to denote variables to be filled in my the user
<tseng> and also literally a variable, like $mydomain
<tseng> that confused the hell out of people.
<hazmat> its been updated in the last week
<tseng> hm, by whom?
<tseng> it still sucks
<tseng> for the same reasons
<tseng> virtual_minimum_uid = 1000
<tseng> virtual_gid_maps = static:$vmail-gid
<tseng> if you werent paying close attention, you wouldnt replace $vmail-gid with say, 1001
<tseng> because postfix uses $variable as well
<tseng> oh well.
<hazmat> dunno, but its also one of the few good howto docs on how to set it up on the net.. 
<hazmat> mdz, http://gentoo-wiki.com/HOWTO_Email_System_for_the_Home_Network
<tseng> good being relative
<tseng> oh, you are talking about that ^ ?
<daniels> hazmat: cairo
<tseng> http://www.gentoo.org/doc/en/virt-mail-howto.xml is how i mean
<daniels> er
<hazmat> tseng, i know, there were two different topics
<hazmat> the link above answers mdz's question though
* tseng shrugs
<tseng> good deal then
<hazmat> but i was curious about your condemenation of the virt mail howto, as i've used it before
<tseng> ive helped a bunch of people with it
<tseng> it was a painful experience every time
<tseng> hm who is martin pitt on irc?
<ggi> tseng: pitti
<pitti> ggi: yes, what's up?
<ggi> pitti: Nothing, tseng asked who Martin Pitt was on irc.
<pitti> ggi: ah; I just rejoined (just did a Warty installation)
<hazmat> are there seperate team mailing lists?
<mdz> hazmat: not yet, currently everything is on ubuntu-devel
<pitti> Argh, why does bugzilla erase any field when an input is wrong? It just ate my bug report... In addition, I _did_ specify a component (although I was told that I didn't)
<mdz> seb128: here?
<seb128> yes
<seb128> and wanted to ping you about the patches for the control-center
<tseng> pitti: im brandon on "hald segfaults"
<seb128> what do you think about Vincent's patch ?
<tseng> pitti: tracking it down further atm
<pitti> tseng: ah, it still does not work now?
<tseng> no
<tseng> but i found the probable cause
<mdz> seb128: I wanted to ping you about #1943
<tseng> the last device it looks at before crashing is my ipw2200 on irq11
<mdz> seb128: I think we should upload the quick fix that I used now, and then see about cleaning it up right
<tseng> im using pci=noacpi because of bug 1254
<mdz> seb128: we need to do something for the users whose systems are broken right now
<seb128> mdz: ok fine, I've the package ready and tested it the whole day
<tseng> when i boot w/o noacpi, hald does not segfault
<seb128> just wanted to check with you
<mdz> seb128: ok, great, please go ahead and upload
<pitti> tseng: thanks for exploring this.
<tseng> not sure if it doesnt see the ipw2200 at all, or if it doesnt like being on the other irq
<seb128> I've tried to ping you some hours ago, but was just after you left
<pitti> tseng: nevertheless hal should not segfault
<seb128> mdz: ok
<tseng> i should try verbose w/o noacpi
<tseng> see if it looks at the ipw
<tseng> this seemed to work all fine with 2.6.8.1-2
<tseng> iirc
<pitti> tseng: do you have the time and skills to debug hal? Or can you let me onto a noncritical machine?
<tseng> you can do it on here, nothing very critical
<tseng> just dont rm my homework
<tseng> lemme grab that key
<pitti> tseng: actually I do not want do modify anything (not even install a new package), but I need root to debug hal
<tseng> yes thats fine
<tseng> im setup in the broken environment now
<pitti> tseng: broken env?
<tseng> yes, conditions set for a segfault
<pitti> tseng: you plugin this card=
<pitti> tseng: s/=/?/
<tseng> no, if i boot without pci=noacpi, the card does not work (irq conflict) but hald dose
<tseng> if i boot with, the card works, hal does not
<tseng> let me make a port forward here right quick
<pitti> tseng: I have to reboot as well (new kernel), see you in some minutes
<tseng> ok
<pitti> tseng: brb
<mdz> pitti: eek, #2069
<mdz> pitti: will you take care of it?
<pitti> mdz: I can do
<pitti> mdz: BTW, I just got yet another hal segfault
<pitti> mdz: sometimes I wish hal was written in python
<mdz> yes
<pitti> tseng: can you please download http://www.piware.de/hal_0.2.98-1ubuntu6_i386.deb, install it with dpkg -i and check whether hal works now?
<tseng> yes
<tseng> pitti: the pkg restarted dbus
<pitti> tseng: please be aware that hal upgrade will kill gnome-volume-manager (bug #1551), so you need to logout and in if you actually want your devices mounted
<tseng> pitti: and hald is running now
<pitti> YEEEAAHH!
<tseng> hal       6337  4.3  0.7  5480 4096 ?        Ss   16:28   0:00 /usr/sbin/hald --drop-privileges
<pitti> tseng: thanks!
<tseng> you rock, etc
<pitti> tseng: thanks for letting me onto your machine. You should remove my ssh key
<tseng> yeah im on it
<pitti> tseng: I removed my files (up to the backdoors, of course :-), so you should not need to clean up anything other
<tseng> yep.
<mdz> heh, mounting with noatime severely confuses mutt
* pitti 's head smokes. Good night everybody!
<tseng> could someone get rid of that pyramid dude?
<tseng> he's ridiculous.
<mdz> no sleep last night...a nap is called for
#ubuntu-devel 2004-10-16
<Markus_> Hi There.. Can somebody help my? Why isnt my serial mouse not recognized? Where can I change it?
<chrisa> Try #ubuntu
<randomnick> hi...
<Mithrandir> mdz: any idea what to do about 1872?
<seb128> jdub: here ?
<jdub> yeah
<seb128> python-gtk2-docs
<seb128> python-gtk2-tutorial
<seb128> these are documentation
<seb128> and not in ubuntu (uploaded in deb after the warty freeze)
<seb128> perhaps we want to include them somewhere ?
<sivang> just removed lp and parport from system, still now sound device. this is after a fresh install on inspiron 8200
<seb128> ok, time to sleep
<sivang> night seb128
<mdz> Mithrandir: I wanted to ask you the same :-)
<mdz> Mithrandir: I think the bug is probably fixed; he needs to re-test
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 33 RC bugs to go
<npmccallum> anyone having problems with madwifi in the latest kernel release?
<mdz> haven't tried it
<mdz> I will now
<npmccallum> my madwifi card can't get a dhcp since I upgraded the kernel
<npmccallum> it worked fine in previous kernels
<mdz> doesn't seem to want to associate
<mdz> I've never tested it with WEP before, though
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 32 RC bugs to go
* daniels claims 1551.
<fabbione> morning guys
<daniels> hm
<daniels> fabbione: could you please review the g-v-m change on http://people.ubuntu.com/~daniels/gnome-volume-manager ?
<daniels> fabbione: basically, with ubuntu2, if you run /etc/init.d/dbus-1 stop, then g-v-m dies
<daniels> with ubuntu3, it should work just fine if you restart dbus
<fabbione> daniels: gimme a few
<fabbione> daniels: i don't know much about g-v-m. did you write all that patch yourself?
<daniels> fabbione: based on Kinnison's patch
<fabbione> i don't know enough about g-v-m, but it seems ok
<fabbione> daniels: did you tested it?
<daniels> fabbione: yeah, it works fine here
<daniels> hotplug smartcard reader, nautilus window pops up
<daniels> restart dbus with sudo /etc/init.d/dbus-1 restart
<fabbione> does that means is going to break *? ;)
<daniels> with ubuntu3, it should work just fine if you restart dbus
<daniels> er
<daniels> then after that, hotplug smartcard reader, nautilus window pops up
<fabbione> it should or it does?
* fabbione bitches
<daniels> should, and does :)
<fabbione> ok
<fabbione> go ahead
<daniels> thanks
<doko> how were all the newly imported "file conflicts" reports handled for warty?
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 30 RC bugs to go
<fabbione> doko: argh
<fabbione> you were slightly faster than me
<fabbione> for tetex-base
<pitti> Morning everybody!
<SuperLag> any of you guys have Mono installed on your Ubuntu boxen?
<pitti> SuperLag: I had it installed on Sid, for my diploma
<pitti> SuperLag: should not make much of a difference on Ubuntu
<SuperLag> I've added the lines to the repositories, according to the wiki page... but no workey.
<SuperLag> Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed.
<doko> fabbione: just wanted to remove the file from the binary
<fabbione> doko: yes.. you need to fry it from the orig.tar.gz too afaik
<doko> uggh, new source upload?
<fabbione> doko: yes
<fabbione> it's not in the diff.gz
<fabbione> if the file is not free you need to remove it from the orig.tar.gz too
<pitti> SuperLag: sudo apt-get install -s mono works for me, all dependencies seem to be in place
<pitti> SuperLag: I did not actually install the packages, though, but dependencies are checked in the simulation
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 29 RC bugs to go
<fabbione> is 2022 really RC?
<fabbione> hey mdz
<mdz> morning
<fabbione> 4.13 ??
<fabbione> where are you hooked up?
<mdz> verizon
<fabbione> whois 4.0.0.0
<fabbione> OrgName:    Level 3 Communications, Inc. 
<fabbione> not bad :-)
<mdz> my home away from home
<fabbione> mdz: is 2022 really RC?
<mdz> while my house is fumigated
<fabbione> yeah i read that ;)
<mdz> fabbione: well, the last name implies that it is :-)
<fabbione> mdz: well reading the bug i get a completely different idea
<fabbione> otherwise i wouldn't ask ;)
<mdz> it doesn't seem RC for Warty
<fabbione> exactly
<elmo_> Mithrandir: ?
<Mithrandir> yes?
<Mithrandir> elmo_: pong
<elmo_> Mithrandir: do you know about epiphany-extensions on amd64?
<Mithrandir> what about them?
<elmo_> ftbfs
<Mithrandir> I've never heard of them before. :)
<Mithrandir> ugh :/
<elmo_> sgml-validator.c: In function `convert_to_utf8':
<elmo_> sgml-validator.c:309: warning: passing arg 4 of `g_io_channel_read_chars' from incompatible pointer type
<elmo_> could you have a look at some stage and/or should I file a bug?
<Mithrandir> I'll look at it, but please file a bug
<doko> mdz, Mithrandir: what is the decision on #1996?
<Mithrandir> I asked you to ask mdz
<Mithrandir> trivial fix, it seems
<sabdfl> anybody else having trouble with firefox stability?
<pitti> sabdfl: me
<pitti> sabdfl: It just crashes on some websites
<sabdfl> hangs and won't respond?
<pitti> sabdfl: but I could not reproduce this reliably
<pitti> sabdfl: no, no hangings so far
<pitti> sabdfl: It's a pity, mozilla has been rock solid for a long time now; sad to see such regressions
<azeem> it's the wrath-of-epiphany
<sabdfl> perhaps they are suffering from "i want my favourite patch in 1.0" syndrome
* SuperLag is beginning to despise e-mail
<hazmat> i can confirm having firefox stability issues, it randomly crashes for me as well
<sabdfl> or perhaps it's a packaging problem. thom?
<pitti> sabdfl, thom: https://financepilot-banking.mlp.de always crashes at my box the first or second time
<pitti> sabdfl, thom: this is the site I could reproduce it most reliably
<doko> and it's a memory hog, currently at 580M on my machine. you have to restart it every day (if it doesn't crash ;)
<sabdfl> is gnome-nettool generally useful? should we be shipping it?
<seb128> morning
<pitti> Hi seb128!
<seb128> hello pitti 
<hazmat> any consideration of replacing totem/gstreamer with something that works?
<hazmat> like xine/gxine
<pitti> hazmaz: apt-get install totem-xine (or xine-ui)
<pitti> hazmaz: we cannot do that by default because of patent restrictions
<pitti> hazmaz: BTW, personally I still prefer mplayer; this rocks
<hazmat> ic.. thanks for the clarification
<hazmat> perhaps an item for the faq
<plovs_work> sabdfl, as an admin, i personally don't use it, all these tools exist on cli. But for regular users who want something a little more powerfull, i think many would appreciate it. It is on the gnome-website so people miss it when it is not there.
* fabbione does some woody -> warty upgrade tests
<sabdfl> plovs_work: i guess it is in main for those who want it. but i think it would go well in Applications->System Tools
<plovs_work> sabdfl, it *is* part of gnome 2.8, people on irc ask why it is not in the bas-install, they have a point, i would vote for putting it in
<doko> do we a policy how to create a new version, when a new upload of the source is needed? tetex-base-2.0.2b -> tetex-base-2.0.2b-1 ?
<fabbione> doko: why not using the same approach as debian?
<fabbione> dolo: tetex-base-2.0.2b.dfsg.1
<fabbione> or something
<doko> well, it's not permanent, the Debian maintainer and upstream agree on the removal, so it's a temporary version.
<fabbione> doko: a new upstream release means 2.0.2c
<fabbione> or similar
<fabbione> so a b.whatever is fine
<doko> ok, I'd like the version as short as possible.
<azeem> isn't glibc using 'ds'? Like 2.3.2.ds.1? How about that?
<azeem> oh, and what does ds stand for, btw? :)
<azeem> development snapshot?
<fabbione> deliberate suicide
<doko> hey, glibc stole that one from gcc ;) "debian source"
<azeem> so make it 'us' ;)
<fabbione> i can't wait to see the first USA
<fabbione> Ubuntu Security Announcement
<doko> ok, that would become 2.0.2bus :)
<fabbione> yeah and next one is 2.0.2taxi
<fabbione> 2.0.2tram
* lypanov always thinks daniel stone :P
<doko> we run out after underground
<azeem> the term 'ds' is probably older than daniels 
<lypanov> doko: shuttle?
<pitti> sabdfl: yesterday I installed Warty from scratch and now I can indeed not import mp3 files in Rhythmbox any more
<pitti> sabdfl: odd, this worked fine before
<pitti> seb128: do you know why rhythmbox cannot import mp3 files any more? This worked fine some time ago
<seb128> pitti: gstreamer0.8-mad is installed ?
<pitti> seb128: no
<pitti> seb128: I did not install this manually on my previous install, though
<seb128> ok, that's it probably
<seb128>  rhythmbox (0.8.5-1ubuntu2) warty; urgency=low
<seb128>  .
<seb128>    * debian/control.in:
<seb128>      - Remove binary dependency on gstreamer0.8-mad.
<pitti> seb128: we should probably install it by default
<seb128> Jeff did that saturday
<pitti> seb128: do you know whether germinate handles Recommends:?
<seb128> pitti: if Jeff did that, there is probably a reason
<pitti> seb128: okay, I will ask him. ThanksQ
<pitti> seb128: s/Q/!/
<seb128> pitti: no idea sorry, but -mad is probrably problematic for patents issues
<pitti> seb128: What a pity. Playing mp3 files is not patent protected, just creating them
<seb128> are you sure ?
<pitti> seb128: -mad is even in universe now :-(
<pitti> seb128: pretty sure, yes. 
<pitti> seb128: but maybe the -mad library also includes the encoder?
<azeem> RedHat also dropped mp3 playback some time ago
<seb128> pitti: no
<azeem> dunno if they put it back in
<pitti> seb128: I will look for the mp3 licensing issue
<seb128> pitti: better to just ask to Jeff, he knows the details
<seb128> pitti: http://www.mp3licensing.com/royalty/index.html
<pitti> seb128: I'm just reading it
<seb128> ok
<pitti> seb128: seems like my memory did not served me so well: it is free (beer) for private use only
<pitti> seb128: that's why I did not convert my collection completely to ogg
<seb128> ok
<pitti> seb128: but it does not meet the DFSG since you must pay for commercial applications
<azeem> are you talking about the algorithm/spec, or about Fraunhofer's implementation?
* pitti is going to convert his mp3s to ogg now...
<pitti> azeem: the licensing page talks about "technology", not "software"
<pitti> azeem: so I suppose it's the algorithm they patented (which would make sense in their POV)
<pitti> azeem: from the website: "I have my own/third party mp3 software. Do I need a license?
<pitti> Yes. Use of our patents is not related to a specific implementation of encoders and decoders, which means that a license under our patents is needed. "
<azeem> "How do you tell if a piece of software violates a patent? Run wc -l on
<azeem> the source; if the number is greater than 1000, it probably does."
<azeem>                 -- Nat Friedman
<lypanov> hehe
<fabbione> what is the command in vim to go "vertical" visual?
<lypanov> ctrl-v
<doko> mdz, jdub: ok to upload tetex-base without the file with the non-free license? #2066
<lypanov> you mean so you can cut a block?
<fabbione> lypanov: yes, but a vertical block
<lypanov> ctrl-v will do that
<fabbione> doko: read the last mail from Matt about uploads and peer-review
<fabbione> lypanov: thanks
<lypanov> np
* lypanov is writing a vim clone in ruby atm :P
<doko> fabbione: which list/date?
<doko> fabbione: ok, could you do the review?
<sivang> morning fabbione
<fabbione> doko: sure
<fabbione> hi sivang 
<doko> chinstrap:~doko/tetex/
<sivang> hey fabbione, we need to find someway to make nv/nvidia use 100Hz on the flatrons, as it _is_ supported ;)
<fabbione> sivang: it requires a specific mode-line
<fabbione> i saw a message floating around
<sivang> fabbione : I have tested a bit with knoppix, and see it detects the 100Hz capability, although have been unable to make it work on knoppix ;)
<sivang> fabbione : could you point me to the message or else?
<fabbione> doko: basically you purged the file from the .orig and that's it?
<fabbione> sivang: i saw it on #ubuntu
<doko> yes, the .tex and the documentation file.
<sivang> ok, i'll ask see if someone knows about it
<fabbione> doko: ok that's the same i would have done..
<fabbione> doko: do we know if something actually uses that file?
<lypanov> that reminds me
* fabbione -> food
<lypanov> any chance that ubuntu will do modelines and stuff?
<lypanov> as X -configure don't like my dell :)
<doko> well, looking at the package itself, nothing. but it gets recommended in the LaTeX companion :( Then it should be added to tetex-nonfree ...
<fabbione> doko: hmmmmm 
<fabbione> tetex-extra is still in main
<fabbione> there is no tetex-nonfree
<fabbione> apt-cache search tetex-nonfree
<fabbione> tetex-extra - Additional library files of teTeX
<doko> hmm, what to do? if some package build depends on the removed file ...
<fabbione> doko: should we give a fast look to rdepends and run a check rebuild of the packages?
<thom> pitti: i hate asking, but if you move your .mozilla out the way and restart firefox, does it still crash?
<pitti> thom: lemme try
<pitti> thom: although I already tried this several times...
<fabbione> thom: it doesn't look like you hate asking me to hug you :P
<pitti> thom: yes, it still crashes
<thom> pitti: gar. i can't reproduce this at all
<pitti> thom: does it work for you? You might have to try this two or three times
<pitti> thom: okay, I will try to get a backtrace.
<doko> fabbione: these are 55 packages. could these be built in test-only mode? lamont?
<pitti> thom: hmm, I got a backtrace, but it does not say much. I guess I have to build a debugging version
<pitti> thom: but it's not that critical, most websites work okay
<fabbione> doko: we can build 55 packages by hand...
<fabbione> doko: it doesn't take too long
<pitti> thom: strace says "SIGSEGV (Segmentation fault) @ 0 (0)" -> NULL pointer access
<fabbione> doko: but the problem is if we need that file
<fabbione> doko: that means creating or importing that tetex-nonfree thingy, move the packages to restricted and change build-dep
<thom> pitti: eh!?
<fabbione> doko: i don't think that's even possible at 8 days from release
<thom> pitti: hrm, i just created a totally clean user, had no problems at all
<pitti> thom: maybe it does not occurr on amd64?
<pitti> thom: I build a debug version and extract a bt again
<pitti> thom: I can do that in the background
<thom> yeah, i'm gonna install an x86 warty on here in a sec and try that
<pitti> thom: ugh, 40 MB compressed source? This will take a while to compile on my Duron 1.3...
<thom> yeah, it's no fun
<doko> fabbione: we don't need to build them, grepping for the removed file would be enough.
<fabbione> doko: as well...
<fabbione> doko: but it depends how the package is done... a dbs/cdbs or similar will require unpacking first
<sivang> any need for a fast compilatio machine?
<doko> ohh yes, let's see how the upstream author of the file will react, if he changes the license. I'll start on the packages tomorrow.
<sivang> (pentium IV 2.6HT )
<sivang> sitting and wasting it's cycles..:-)
<thom> sivang: that's considerably slower than our buildds :-)
<sivang> thom : they are IA machines?
<thom> sivang: dual 3.3 Xeons
<sivang> thom : oooo. I see
<sivang> thom : I just was pitti was referring to his "slow" 1.3 duron ;)
<sivang> pitti : what to you need to compile?
<fabbione> sivang: thanks but we need to test a package that is not in the archive yet.
<fabbione> sivang: and check 55 packages depending on it
<pitti> sivang: DEB_BUILD_OPTIONS=nostrip,noopt debuild -us -uc -b     for mozilla-firefox
<sivang> fabbione :  it has a source package right?
<pitti> sivang: I'm already at it, but this will probably last over an hour
<fabbione> doko: ok. fine for me. let me know if you need help
<fabbione> sivang: not in the archive
<sivang> pitti : oh, new upstream source?
<pitti> sivang: no, I just need a debugging-enabled version
<pitti> sivang: to find a segfault
<sivang> pitti : i see.
<sivang> instead of blabbering, i
<sivang> 'd better ask for the bug#
<sivang> ?
<thom> pitti: ooi, does this happen for you on ppc, too?
<pitti> sivang: BTW, can you try whether https://financepilot-banking.mlp.de (and then clicking on the continuation link) crashes for you?
<pitti> thom: : I can try
<thom> please
<pitti> thom: booting...
<sivang> thom : I've been to some computer junk yard, they'd sell me an AlphaAXP monster for about 500$
<sivang> thom : :-) does this qualify as a buildd?
<sivang> pitti : it won't even start.
<pitti> sivang: you mean firefox does not even start on your box?
<sivang> pitti : mozilla won't start now, let's kill x and relogin
<fabbione> sivang: 2066. the problem is a bit more complicate than it looks like
<pitti> sivang: not mozilla, firefox please
<fabbione> sivang: removing that file is (at this point in time) the solution for the bug, but there are 55 packages depending on that package.
<sivang> pitti : , sorry that _was_ firefix
<fabbione> sivang: that needs to be checked if they make any use of the file that needs to be removed
* sivang reloggs
<sivang> fabbione : ok
<sivang> brb
<fabbione> sivang: so it's a bit complex. On the otherside there is the option that the author of that file will relicence it and nothing needs to be done
<sivang> hmmm
<sivang> strange,
<sivang> I just upgraded.
<sivang> dpkg segfaulted
<sivang> when I tried to install linux-image-686-smp
<sivang> that didn't happen before..
* sivang trying a reboot
<pitti> thom: firefox on ubuntu crashes as well
<pitti> thom: s/ubuntu/ppc/
<thom> bah
<thom> ok
<thom> just about to reboot and install
<pitti> thom: my locale is de_DE.UTF-8 (but firefox runs as en_EN)
<pitti> sivang: dpkg segfaults? Don't you know that dpkg does not segfault 8 days before release candidate release? :-P
<sivang> hmmm
<sivang> i think I have a dead warty here :(
<sivang> I am now on sid
<sivang> i cannot boot warty no more.
<sivang> "ld has spawned too fast"
<sivang> remember pitti when we thought this was because I extracted my old home dir?
<sivang> well, guess what? ;-)
<sivang> I think it has something to do with dpkg
<sivang> I will have to go out in a sec (getting a new Ultrawide SCSI Server) I will come back to investigate.
<sivang> i will also try to fetch a log if I can from the warty
<pitti> thom: argh, I just see that the firefox package does not respect DEB_BUILD_OPTIONS
<pitti> thom: any easy method to enable debugging?
<fabbione> guys is that true that RHAS or ES requires a yearly licence otherwise "It stops working"???
<fabbione> someone is asking me via sms and i have no clue
<fabbione> last time i checked RH was 7.1 or lower
<pitti> thom: don't bother, I fixed debian/rules
<|trey|> fabbione: no its not true
<|trey|> fabbione: not even microsoft does that.
<|trey|> fabbione: of course, updates via rhn stop
<|trey|> Its in their best interest for you not to become interested in other products though...
<fabbione> |trey|: ok.. i expected so
<tuo2> like ubuntu... ;)
<fabbione> |trey|: i still remember that night i had to install RH.. brrrr i am still shaking
<|trey|> fabbione: enless you want a flame in a devel channel, I suggest that be the end of that discussion  ;)
<fabbione> |trey|: eehhe
<thom> pitti: please send a patch :-)
<pitti> thom: by now I just hardcoded the change, but a patch is easy
<pitti> thom: I will send it to you 
<thom> thanks :-)
<thom> ok, i get crashes on x86
<thom> ROCK and ROLL
<pitti> thom: maybe your 64 bit are enough to make it work :-)
<pitti> thom: as soon as the build finished, I can debug this, if you want
<thom> well, it's litterally the biggest bug i have left, so i might as well
<thom> i have a faster machine too, so it's much less painful for me :-)
<pitti> thom: okay
<pitti> thom: how do you build debugging versions, BTW? If not with DEB_BUILD_OPTIONS?
<thom> i'd not had need to before now, guess i'm just lucky :-)
<pitti> thom: odd, doesn't an -O2 built firefox work on so many arches?
<thom> pitti: apparently not, that's very much legacy but the debian maintainer has been specifically turning them off
<pitti> thom: I have a patch for debian/rules, where shall I send it? thom@canonical.com?
<thom> yes please
<thom> ccache should be in build-essential *g*
<lypanov> thom: build-essential should include a virtual cluster :P
<thom> that'd be nice too
<thom> but possibly a little impractical
<thom> pitti: on your ibook, can you ls /lib/modules/`uname -r`/kernel/arch/powerpc/kernel/cpu/cpufreq ?
<thom> or tell me what cpufreq module you need to load?
<pitti> thom: I have to boto it again
<thom> oh
<pitti> thom: 
<thom> not urgent
<thom> just trying to get the powernowd modules loading stuff right
<pitti> thom: oh, it works well out of the box on my iBook
<thom> really? cool
<pitti> thom: in fact, the latest isos set up almost everything right out of the box
<pitti> thom: the only outstanding issue is the swapped Alt/Apple on the consoles
<pitti> thom: I have the following modules: cpufreq_{userspace,powersave}
<pitti> thom: they are not hw-specific, I think
<pitti> also, apm_emu
<sjoerd> your kernel probably has CONFIG_CPU_FREQ_PMAC=y 
<thom> you should have a cpufreq-something or a powernow-something module
<thom> ah, or it gets built in. which would be odd
<pitti> thom: above two are the only ones
<sjoerd> thom: for ppc there is just one type of cpu freq switching thingie 
<pitti> thom: I can look up specific things in the kernel config, if you want
<sjoerd> afaik
<thom> pitti: grep for the option that sjoerd just quoted, please :-)
<thom> sjoerd: there's only one on amd64, but that's modular. it would just seem a little inconsistent :-)
<pitti> thom: its compiled in
<pitti> thom: CONFIG_CPU_FREQ_PMAC and CONFIG_CPU_FREQ_TABLE are both 'y'
<thom> answers that one then
<thom> cool, makes my life easier
<sjoerd> thom: looks like i can't turn it into a module here
<pitti> thom: btw, any luck with firefox?
<thom> pitti: building
<thom> ah, just finished
<thom> only a glorious 25minutes
<pitti> thom: on a powerful amd64 machine?
<pitti> thom: then I suppose it would have lasted 1.5 hours on mine :-)
<thom> yeah, a marketed-at-3GHz amd64 with a GB of ram
<thom> (ie, it's real clock speed is 2GHz)
<azeem> they still do this with amd64?
<azeem> thought they just use some random numbers these days, or just for the Opteron servers?
<thom> model name      : AMD Athlon(tm) 64 Processor 3000+
<thom> cpu MHz         : 2003.246
<azeem> bah
<azeem> model name      : AMD Opteron(tm) Processor 240
<azeem> cpu MHz         : 1395.656
<azeem> more prudent
<elmo_> is /topic out of date or do I need to update my search?
<thom> azeem: nod
<thom> they obviously couldn't escape the marketroids for the consumer chips :/
<thom> oh man. the backtrace for mozilla is making me tired just looking at it
* thom goes to procure strong tea
<Kamion> elmo_: I can see 23 here
<elmo_> cool, thanks
<Kamion> thom: try bug #1254 :P
<thom> ah, yes
<thom> the good old "dell sucks" bug
<tseng> mmm, i have that bug
<tseng> i can help w/ it between classes
<tseng> be back in 2 hours or so
<elmo_> argh
<elmo_> kamion: what the heck is cdimage/jigit and why do clients go into a tight loop trying to fetch it?
<thom> gack
<thom> that segfault doesn't happen with a mozilla binary download
<pitti> thom: you mean only the warty version crashes?
<Keybuk> mdz, sabdfl: is there a tech-board meeting today?  if so, what time and what's the agenda? :p
<thom> pitti: yep :/
<thom> so now it's binary search time
<pitti> thom: bad. Can you reproduce it with the debugging version?
<thom> the debug version segfaults, yeah
<pitti> thom: my last gstreamer bug did not appear any more as soon as I switched off optimizations... :-)
<thom> yeah, that's no fun
<pitti> thom: do you get a nice bt?
<thom> 109 frames of joy
<thom> i have a hunch
<pitti> thom: good luck! I've got to go now
<|trey|> Who is in charge of Bugzilla? something in the main channel is having probs
<azeem> justdave
<|trey|> azeem: k, thanks  :)
<Kamion> elmo_: because we haven't got the proper snapshot archive set up? I've sent several mails to you and thom asking for this, and Steve has been nagging me too
<Kamion> Mark paid Steve money to get this done
<elmo_> yeah ok, but why are their multiple IPs hitting it repeatedly, like 5 times a minute for 5 minutes?
<elmo_> s/their/there/
<Kamion> I guess jigdo is upset by it not existing
<elmo_>    2340 81.244.129.5] 
<elmo_>    1153 82.161.112.73] 
<elmo_> that's an apache2 style (i.e. crap) failure mode for being upset
<Kamion> maybe I can change the default fallback server for now, although it won't work well
<Kamion> OK, changed, but we really need the snapshot archives soonish
<tuo2> hmmm
<tuo2> anyone here running the security team? If so, and you are looking for members, flick me a message. :)
* tuo2 goes back to lurking
<pII-350> hi there!
<pII-350> can somebody help me.. I got stucked with my Ubuntu installation.. all is installed and seems to work properly, but at the next restart i hangs up with some modules
<m_tthew> pII-350 : try #ubuntu
<daniels> mdz: the only possible solution to the figlet bug seems to be to remove it; imho we should do so
<Keybuk> daniels: except that the "desert island test" bits are bogus ... there's nothing in the DFSG against those, despite what slef & co. might think
<daniels> Keybuk: yes, but in general, it's not too dfsg-free :P
<Keybuk> this is where I think licence-lawyers go way off the deep end.  figlet has been effectively MIT for over a decade, with myriad distribution and modification under that assumption.
<thom> and now firefox is trashing the stack
<thom> *hates*
<sivang> thom are eanybody else here with knowledge of SCSI devices? 
<sivang> are=or
<npmccallum> sivang: whats up?
<lamont> doko: you around?
<Kamion> could I have some developers looking over https://bugzilla.ubuntu.com/attachment.cgi?id=229?
* fabbione checks
<Kamion> testing doesn't seem to be producing particularly excellent results (it's bug #1566); on the other hand, due to the nature of the bug it's very difficult to test a fix reliably once you've encountered it on a given machine, and I haven't heard anyone saying that the patch has behaved any worse than the original
<fabbione> Kamion: why does it patches the config.guess too?
<Kamion> fabbione: nothing to do with me, guv
<Kamion> fabbione: automatic update by debian/rules
<fabbione> Kamion: the patch seems sane to me
<Kamion> fabbione: thanks
<Kamion> What do people think of this text, for an OpenSSH upgrade question?
<Kamion> _Description: Disable challenge-response authentication?
<Kamion>  Password authentication appears to be disabled in your current OpenSSH
<Kamion>  server configuration. In order to prevent users from logging in using
<Kamion>  passwords (perhaps using only public key authentication instead) with
<Kamion>  recent versions of OpenSSH, you must disable challenge-response
<Kamion>  authentication, or else ensure that your PAM configuration does not allow
<Kamion>  Unix password file authentication.
<Kamion>  .
<Kamion>  If you disable challenge-response authentication (the default answer), then
<Kamion>  users will not be able to log in using passwords, only with their private
<Kamion>  keys. If you leave it enabled, then the 'PasswordAuthentication no' option
<Kamion>  will have no useful effect unless you also adjust your PAM configuration in
<Kamion>  /etc/pam.d/ssh.
<Kamion> [note: this will only be displayed to people who have already modified sshd_config themselves] 
<fabbione> Kamion: perhaps you can avoid repeating twice the key atuhentication stuff
<fabbione> (perhaps using only public key
<fabbione> only with their
<fabbione>           private
<fabbione> <Kamion>  keys.
<fabbione> you repeat it twice telling 2 different keys
<fabbione> it might be confusing
<Kamion> "public key authentication" is the term used in the manual page and the correct name for the authentication mode, but you don't use your public key to log in
<Kamion> I could just take out ", only with their private keys" I guess
<fabbione> yes i know what you meam
<fabbione> mean
<Kamion> it did occur to me when I wrote it that it might be a little confusing; since somebody else thought so as well, I'll take it out
<seb128> grrrr, is there anybody reading the bug reports against bugzilla in ubuntu.bugzilla.org ?
<Kamion> you mean bugzilla.ubuntulinux.org?
<seb128> no, bugzilla.ubuntu.com :p
<seb128> but yeah :)
<elmo_> seb128: ?
<Kamion> seb128: justdave does a pass over them every so often; he closed a bunch this morning
<seb128> I want an UPSTREAM state
<seb128> nobody even cares to reply in 10 days
<seb128> and I've pinged last week
<elmo_> ah, ok, that's a justdave thing.. sorry thought you might have meant some of the outstanding admin stuff
<seb128_> sorry, dsl hangup
<seb128_> I've stopped after <Kamion> seb128: justdave does a pass over them every so often; he closed a bunch this morning
<seb128_> was saying, that it would be really usefull to get an UPSTREAM state
<seb128_> most of GNOME issues are upstreams bug and a big part is forwarded
<seb128_> I would appreciate to get at least a comment/reply/something on my bug in 10 days :)
<seb128_> mdz: ping ?
<seb128> justdave: ping ? 
<thom> so, is the correct response on ubuntu-devel to Orlando Fiol "exactly"?
<thom> :-)
<Kamion> thom: :-)
<justdave> seb128: sorry, just replied on the bug.
<justdave> should have marked it ASSIGNED when I initially grabbed it so you knew it was on my radar
<seb128> justdave: no problem that's just that getting the feeling to be ignored is frustating :)
<seb128> justdave: thanks
<justdave> yeah, I know.  I just made the same complaint on a bug I assigned to someone else a week or so ago, so I feel stupid now :)
<mdz> seb128: pong
<seb128> mdz: #1851
<seb128> you've tested the patch, ok to include it ?
<mdz> seb128: I haven't tested the last part (to ifupdown), but the gst patch works fine
<seb128> ok, I'm going to upload gst to fix an another bug, ok to include this patch too so ?
<mdz> seb128: yes
<seb128> thanks
<seb128> mdz: #2088 too :)
<mdz> seb128: fine with me; they don't seem to have any new dependencies
<mdz> I'm happy for them to go in supported
<seb128> no depends, that's only html files
<seb128> ok, thanks
<seb128> I'll add them to the seed and upload
<mdz> ok
* lamont grumbles as the archive copy adds several minutes to his install.,
* lamont wanders off for a bit to fetch children and a powersupply fan
<Keybuk> can I mention that screem's fetish with stealing every available mime type for itself is f*cking annoying
<Kamion> OK, I think I have a fix for #1586
<Kamion> although it will need to be ported from unstable to experimental and thence to Ubuntu
<bradb_> seb128: why does vim show up without an icon in Applications->Accessories?
<seb128> because there is no real point to have it here ?
<seb128> that's not really a desktop user app
<mdz> it should not show up in the menu at all
<mdz> bradb_: are you saying it's there with no icon, or that it's not there?
<sabdfl> doh
<sabdfl> it's there with no icon
<sabdfl> both facts surprised me
<sabdfl> clicking it runs gvim
<seb128> oh ok
<seb128> I'll remove the entry
#ubuntu-devel 2004-10-17
<Kamion> can people have a quick sanity-checking glance over http://people.ubuntulinux.org/~cjwatson/openssh.diff, for #1586?
<Kamion> that diff is against the current version in sarge, but can be ported
<minghua> hi, I am wondering how to get a package in universe updated
<minghua> I am the Debian maintainer of scim package
<minghua> and a user reported it does not work in ubuntu warty
<minghua> he didn't reply my inquiry yet but I have an idea what can be wrong
<Kamion> minghua: mail ubuntu-devel@lists.ubuntu.com and say what doesn't work, please; if it's just a matter of syncing a new source package from universe, then that should be possible
<Kamion> er, s/from universe/from unstable/
<Kamion> minghua: in general universe is frozen at the moment
<yuval> Can I fix the Hebrew translation of ubuntu (debian) installer?
<minghua> Kamion: thanks for the info.  is it possible to update universe even after warty is released?
<minghua> since I am busy now, and not sure if I can sort things out before release
<Kamion> minghua: not for warty. For hoary, we'll be syncing updates automatically from sid.
<minghua> yuval:  I believe ubuntu uses d-i translation
<doko> lamont: around?
<minghua> yuval:  You may want to have a look at http://www.debian.org/devel/debian-installer/
<Kamion> yuval: minghua is correct in general, although there are some branding changes (substituting "Ubuntu" for "Debian", mostly) where the Hebrew translation hasn't been updated. Please file a bug with your changes, and try to keep them confined to the Ubuntu-specific changes if you can so that we don't have to throw the changes away later when merging from Debian.
<minghua> Kamion: thanks, I'll probably target this to hoary then
<yuval> I'll ask the translator of debian installer. I think he fixed the d-i after ubuntu take the installer.
<yuval> There is also a bug in the base-config after the installation. the base-confgi can't display Hebrew...
<yuval> https://bugzilla.ubuntu.com/show_bug.cgi?id=1231
<Kamion> yuval: I know about the bug (it's assigned to me); feel free to tell me how to fix it :-)
<Kamion> ah, you've already updated the bug, hmm
<Kamion> we're already using libfribidi is the thing
<Kamion> I don't know what else it could be, unless it's something in the languagechooser/countrychooser/termwrap maze
<yuval> I don't think libfribidi will help, because the hebrew is not displayed at all. And libfribidi is for reserved Hebrew.
<Kamion> maybe lack of a UTF-8 console?
<Kamion> termwrap has always been a nightmare, but I don't see anything relevant in the base-config changelog since we last synced
<yuval> I think that it's font problam.
<Kamion> yuval: your screenshot looks like garbled high ISO-8859-1 to me ...
<Kamion> ... or maybe not
<yuval> I think that for warty it's ok that this srtings will be in english, but it'll be grea if you can fix this bug.
<Kamion> I have to admit that it's lowish on my priority list right now, but having a known fix would move it a long way up said list :-)
<yuval> Where can I find the sources of the installer?
<Kamion> the relevant source packages ...
<Kamion> it may be easiest to find which source packages are involved by checking out debian-installer upstream (see http://www.debian.org/devel/debian-installer) and looking for the corresponding Ubuntu source packages
<mdz> lamont: ping?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 28 RC bugs to go
* lamont returns
<lamont> postfix fix tested, time to email kamion.  Or would someone else like to review the patch to base-config?
<mdz> Kamion: I'm not convinced that #1586 is RC for Warty
<mdz> lamont: just noticed that James filed a bug about an FTBFS; are there any other failures that may have happened while you were away which need bug reports?
<lamont> will check
<mdz> lamont: can you check for anything which is not built and file bugs as appropriate (is that quinn-diff?)
<lamont> actually, I'll start with http://people.ubuntu.com/~lamont/buildLogs/Lists/warty.all.{i386,amd64,powerpc}, and see what's marked 'Building, out-of-date', or Building from !universe
<lamont> but first I'm going to power down my computer long enough to replace the *(%^_^& powersupply fan.
<lamont> after mailing off my diff.
<lamont> mdz: you want to see the diff?
<mdz> lamont: sure
<lamont> verified to close 1711 and 1123
<lamont> sent.
<Kamion> mdz: I am, if we care about woody->warty upgrades at all
<lamont> back in a few minutes
<lamont> Kamion:  sent to you as well.
* lamont reboots
<Kamion> mdz: it's a significant silent change to the meaning of your configuration on upgrade, which you may not notice and which affects your security policy
<mdz> Kamion: ssh in woody didn't use PAM?
<Kamion> mdz: it did
<Kamion> mdz: the UsePAM directive did not exist until OpenSSH 3.7
<Kamion> that's really a red herring though; the real problem is that ChallengeResponseAuthentication suddenly started working and people who thought they'd disabled all password authentication suddenly found that password-style auth was allowed again
<Kamion> so the fix is to spot PasswordAuthentication being turned off, warn about the inconsistency, and offer to disable ChallengeResponseAuthentication too
<Kamion> (basically, openssh upstream suck and everyone gets to work around them)
<mdz> Kamion: so in woody, if I set PasswordAuthentication no, that implicitly disabled PAM as well?
<yuval> Kamion, I talked with the Hebrew translator of d-i, and it may be also debian bug. I'll check it tomorrow. Good night all!
<Kamion> mdz: no
<Kamion> mdz: PAM keyboard-interactive was turned off in woody
<Kamion> that option was removed in 3.7, and challengeresponseauthentication got applied to PAM
<mdz> I see
<mdz> so we can't solve it transparently due to the change in semantics
<Kamion> right
<Kamion> every so often I go out into a field and scream "I HATE OPENSSH"
<Kamion> [not really, but maybe I should] 
<mjg59> I wholeheartedly recommend abitrary rage
<mdz> Kamion: lamont's base-config diff looks fine to me, but I'll be bouncing you a copy for a quick review
<Kamion> he mailed it to me too
<Kamion> it looks fine
<mdz> ah, ok. he didn't send it at the same time
<mdz> lamont's reboot is lasting awfully long :-)
<Kamion> I've replied to him
<|trey|> Hey... skvidel was in #ubuntu earlier asking about how we will go about "a kickstart alternative"... perhaps someone would like to talk to him about the plans atm?
<lamont> who the hell still _SOLDERS_ powersupply fans into the thing???
<daniels> lam	?!?
<lamont> mdz/Kamion: thoughts on the base-config diff?
<Kamion> lamont: you have mail
<Kamion> |trey|: I was going to answer him, but he left
<|trey|> Kamion: ahh, oh well, his loss  :)
* lamont does an etrn, discovers that Kamion is indeed correct. :-(
* lamont will upload
* lamont adds the bug numbers to changelog first.
<lamont> Kamion: want to review a debootstrap patch for #1879?
<lamont> (ia64 fix, trivial)
<Kamion> lamont: sure
<lamont> sent.  There was a little bit of cleanup in there too, to make the unsupported architectures more obvious.
<lamont> fabbione: sounder 9 asked me for resolutions, etc.
<lamont> ati mach64, ddcprobe ends a nice list of resolutions with 'edidfail', xresprobe gets nothing
<lamont> daniels: thoughts?
<daniels> lamont: edidfail -> your monitor is unprobeable
<daniels> congratulations! :)
<lamont> well, it's not exactly new...
<daniels> the resolutions given before edidfail are the ones your card is capable of doing
<daniels> yeah
<lamont> ah, ok.
<daniels> if you get edidfail, your monitor totally won't talk to us
<lamont> so that's an expected condition, then...
<daniels> yep
<lamont> ok
<daniels> thanks for the case-up
<sabdfl> justdave: ping?
<daniels> chase-up, too
<justdave> sabdfl: pong
<lamont> np
<lamont> mdz: epiphany-extensions is the only ftbfs still outstanding from !universe
<mdz> lamont: ok, thanks
<lamont> mdz: universe trivial bugs still fair game?
<lamont> hrm.. showimg is the only one that is currently d-w libtiff3g-dev, and ISTR there were other issues there..\
* lamont accidently upgrades his desktop. sigh
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 25 RC bugs to go
<mdz> lamont: yes, but RC bugs have priority
<lamont> certainly.
<lamont> actually looks like showimg just needs the d-w cleared.  :(
<lifeless> pmount is interesting...
<lifeless> doesn't seem to add umask=077 to the mount, which makes it useless for ssh keys :[
<mdz> lifeless: for ssh keys on vfat filesystems?
<lamont> lifeless: why are they not correct on the fs?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 24 RC bugs to go
<lifeless> mdz: yes
<lifeless> I've still not done a full install, so pmount doesn't actually run automatically for me, I was just reading the stated behaviour.
<lifeless> any hints about upgrading a debian-stable system to ubuntu such that pmount does work would be great.
* lamont works on epiphany-extensions
<lifeless> lamont: vfat doesn't store modes.
* lamont giggles and points. :-)
<lamont> mdz: 2083 is just a s/int/gsize/, it would appear.
* lamont decides to try that on amd64 as well. :-)
<mdz> lamont: I figured it was something like that
<lamont> if/when the amd64 build succeeds, I'll upload
<lamont> oops.  Fire training in -2 minutes.  bbl
<Kamion> mdz: I only count 18 RC bugs now; what's the correct query to use?
<mdz> Kamion: needs to include NEEDINFO
<mdz> justdave: can we create a global, cooked query for RC bugs?
<mdz> justdave: like the "My Bugs" one?
<justdave> sure
<justdave> make the query that returns what you want, then copy the URL for it and jabber it to me
<Kamion> mdz: aha, thanks
<Kamion> presumably on the Ubuntu product only
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 23 RC bugs to go
<mdz> Kamion: I count 24
<mdz> Kamion: https://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Ubuntu&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PENDINGUPLOAD&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailassig
<mdz> ned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=RC+Bugs&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<mdz> EEK
<mdz> anyway, that's the query I'm using
<justdave> mdz: stick this in your toolbar: javascript:void(location.href='http://tinyurl.com/create.php?url='+location.href)
<mdz> justdave: it would be nice if it would omit the variables that are not being used in the search
<mdz> the stuff which is left blank
<Kamion> mdz: oh, you're using PENDINGUPLOAD too
<justdave> yeah, it would.  needs some javascript hackery on the form in the submithandler to pull that off
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 24 RC bugs to go
<Kamion> mdz: I think I'll downgrade the parted bug until/unless we get feedback that daily builds still break new machines
<justdave> or maybe just have buglist.cgi redirect to itself with the empty fields removed if it gets any passed in that are empty
<justdave> mdz: http://www.squarefree.com/bookmarklets/mozilla.html#shorten_bug_query
<justdave> instead of searching for all of those specific statuses, you can clear the status box and search on resolution=---
<justdave> that gets anything that's not resolved
<mdz> justdave: ah, that's handy, if obscure :-)
<justdave> ok, I just added the query you pasted in here (with it cleaned up a little) to the footer next to My Bugs
<justdave> it's tied to My Bugs though, so if you turned off My Bugs, you'll lose that, too
<justdave> mdz: should https://bugzilla.ubuntu.com/show_bug.cgi?id=1379 be a higher severity?
* Kamion sends himself SIGSTOP for the night
<Kamion> #1379> if so, can it be reassigned to somebody else?
<Kamion> or even possibly if not
<justdave> I was thinking Herbert had it, but I see it's you...
<justdave> is being able to install onto a firewire drive on PPC considered an RC issue?
<justdave> I successfully installed there this time until it got to the point of installing yaboot and it errored out saying it couldn't determine the openfirmware path for the device
* justdave thinks 1379 probably should be NEEDINFO right now pending me getting that /proc/cmdline info posted on the bug
<justdave> unfortunately that's my primary workstation, and testing that means rebooting :)
<sabdfl> lifeless: erk, i think i've found the problem
<lifeless> sabdfl: wrong channel ?
<lifeless> :)
<sabdfl> yup
<sabdfl> wrong tz
<fabbione> morning guys
<lamont> epiphany-extensions is go on amd64.
<lamont> mdz: OK to upload?
<lamont> doko/mdz around?
<fabbione> hey lamont 
<fabbione> lamont: i can review the patch if you want
<lamont> fabbione: ok
<lamont> fabbione: sent.  The debian/control diff is an artifact of dpkg-buildpackage -S
<fabbione> -int len;
<fabbione> +gsize len;
<fabbione> and that's it?
<lamont> yep
<fabbione> hmmm i need more investigation for that
<fabbione> ahaha
<fabbione> go ahead
<lamont> heh
* ..[topic/#ubuntu-devel:lamont] : Ubuntu development -- general discussion on #ubuntu | 22 RC bugs to go
<fabbione> calc: can you open a bug in bugzilla towards xserver-xfree86: module loader broken on amd64
<fabbione> ops
<doko> lamont: around!
<mdz> lamont: yes
<mdz> 22 bugs!
<mdz> today was a good day
<mdz> fabbione: early morning?
<fabbione> mdz: as usual
<fabbione> ;)
* lamont is trying to figure out which tetex-b* he is supposed to use for his regression testing, etc...
<fabbione> lamont: there is one on chinstrap/~doko
<fabbione> if that's the last one
<doko> fabbione: it is
<lamont> given how long it'll take, I'm tempted to wait until morning and sanity return
<lamont> but I'll fetch that.
<mdz> lamont: CCed you on the relevant bug
<lamont> mdz: yeah, but I didn't see any relevant info in the bug...
<doko> lamont: do you let a buildd rebuild the packages?
<lamont> doko: scp ~doko/tetex,yes?
<mdz> lamont: the title of the bug is "Non-free file license in tetex-base"
<doko> lamont: correct
<lamont> doko: I actually have another chroot on the buildd that I toss them at, so that they don't automatically upload
<lamont> mdz: re-reading 2066 provides no usable information, other than the fact that I was cc'ed for regression testing....
<doko> do you have a list of packages to rebuild?
<lamont> whatever apt-cache showpkg tetex-base ... tells me...
<mdz> mako: is "Spell Checkking" in traffic an error or tongue-in-cheek?
<lamont> should be speel checkking if intentional, dammit. :-)
<doko> lamont: not enough, IMO a test-rebuild of packages build depending on tetex-bin|tetex-extra|tetex-base is needed
<fabbione> mako: there is a typo in traffic #06. http://.www.ubuntulinux.org/community/teams
<fabbione> you added a "." too much in the url
<mdz> justdave: is your Warty system in #1379 up-to-date?
<lamont> dpkg: error processing tetex-bin (--configure):
<lamont>  subprocess post-installation script returned error exit status 30
<lamont> I thought that was fixed?
<lamont> doko: yeah, that was the first ... in the list :-)
* lamont decides to deal with things in the morning
<lamont> night all.
<justdave> mdz: 2.6.8.1-3 kernel, newest one.
<fabbione> night lamont 
<justdave> I've got a 10/04 daily already burned sitting here, I'd be happy to wipe it and reinstall if you'd like
<fabbione> mdz: we have some problems with X on amd64
<fabbione> mdz: the solution is everything other than simple
<justdave> I last updated it with synaptic about 2 days ago (when it picked up the new kernel)
<fabbione> mdz: apparently the module loader is broken in some cases and the only solution seems to be to compile a server with modules compiled in, but than users won't be able to install the nvidia drivers for example
<fabbione> mdz: otherwise they need to run the -dbg package
<fabbione> mdz: i am really NOT sure what to do here
<fabbione> and backporting the xorg server with possible fixes is not an option at 7 days from release
<fabbione> mdz: an option could be to install both -dbg and the normal server on amd64 defaulting to the -dbg one
<lamont> mdz: want I should build everything in universe that depends them too?
<lamont> hrm.. build-depends, not depends...
<lamont> more work.
<mdz> justdave: can you try booting the non-smp kernel with only one parameter, root=/dev/hda11?
<mdz> justdave: with no 'quiet' or 'splash'?
<justdave> mdz: did that, it didn't help.
<justdave> (tried that first before I added the devfs thing)
<mdz> very weird
<mdz> justdave: this is a default, non-expert install with an ext3 root filesystem?
<mdz> fabbione: in which cases is the module loader broken?
<justdave> mdz: that is correct
<mdz> fabbione: I have not experienced any problems with the nv driver
<mdz> justdave: could you try booting with rootfstype=ext3 ?
<mdz> justdave: and if that doesn't work, rootfstype=ext2?
<justdave> I asked earlier and no-one answered...  does it mean anything significant if the installer uses a red background?
<lamont> mdz/doko: builds started.
<lamont> 25 packages (not in universe) to build
<lamont> s/not in universe/in main/
<justdave> I remember always seeing it blue before, but I just realized when I boot the CD on the dual G4 it comes up red
<fabbione> mdz: someone reported the problem with Nv, and calc yesterday with ATI
<fabbione> mdz: the server gets a SIG11
<mdz> lamont: don't worry about universe
<fabbione> and dies
<lamont> mdz: right.
<mdz> fabbione: repeatable?
<lamont> that also kinda ignores restricted... will check. :-)
<fabbione> mdz: yes
<fabbione> mdz: installing the -dbg works
<mdz> fabbione: is there a bug filed?
<fabbione> mdz: calc did a test for me creating a normal server but with modules compiled in and it worked
<lamont> no build-deps from restricted
<fabbione> mdz: calc was going to do so soon
<mdz> if the module loader were broken on amd64, I would expect it to fail for me as well
<justdave> ok, with rootfstype=ext3, it hangs.
<justdave> rebooting now to try it with ext2
<fabbione> mdz: i am not sure exactly in which conditions it breaks
<lamont> hrmpf.  and then there were 23. :-(  WTH?
<justdave> lamont: I bumped up 1379
<lamont> ah, ok.
* ..[topic/#ubuntu-devel:lamont] : Ubuntu development -- general discussion on #ubuntu | 23 RC bugs to go
<justdave> which may get bumped down again unless we find an easy way to fix it.  there's a lot of dual ppc's out there, but it's a pretty small chunk of our overall audience.
<fabbione> mdz: 1999
* lamont fixes another trivial non-RC bug (debootstrap/ia64)
<fabbione> s/mdz/guys:
<justdave> rootfstype=ext2 hangs also
<fabbione> i really have no idea wtf is wrong on that system
<lamont> doko/mdz: builds running on all 3 architectures.  since gcc-3.[34]  is involved, I'll check in the morning...
<lamont> night for real, all.
<lamont> fwiw, I had to dpkg --purge tetex-bin in my amd64 chroot (albeit old) before I could successfully install it...  30 == debconf return, of course.
<lamont> must investigate that...
<doko> lamont: you can drop gcc-3.[34] , it's not needed.
<lamont> doko: yeah, but I'm going to bed anyway, and it should finish by morning either way.
<lamont> anyway, to bed.
<mdz> fabbione: re: 1999, maybe a debconf problem?
<fabbione> mdz: if it was a debconf problem, both debian and us will be sharing approx 20000 bugs
<mdz> fabbione: maybe try DEBCONF_DEBUG=.*
<fabbione> that script didn't change for ages
<fabbione> even Overfiend doesn't understand what the problem is
<mdz> fabbione: perhaps something is messing with the debconf file descriptor?
<fabbione> mdz: i really really doubt.. we are shipping that file since 4.3.0-1 was out
<fabbione> joeyh told me that debconf dies automatically once the script exit 
<fabbione> that is by design
<fabbione> if it was a debconf leak, we would be able to see it everywhere
<daniels> justdave: any chance there could be any way we could get slimmed-down bug pages?
<fabbione> hey daniels 
<fabbione> daniels: how is going the organization for the Xsprint meeting?
<justdave> information overload?
<fabbione> daniels: there are only 3 weeks left
<fabbione> daniels: did you find a hotel room or something?
<mdz> justdave: can you send dmesg output from the uniprocessor kernel booted with devfs=mount?
<justdave> hmm, yaboot doesn't let you pass command line params like lilo does?
<mdz> dunno
<justdave> (I'd been editing yaboot.conf and running ybin before, but since I was in the process of rebooting as you said that anyway, figured I'd try it from the boot prompt - didn't work)
<mdz> I've never tried
<justdave> ok, with devfs=mount, it still hangs.
<justdave> trying again with dall
<fabbione> mdz: 2073.. i think that's the easiest solution in a short term.
<fabbione> mdz: i don't believe they will ever manage to fix the licence in 7 days
<mdz> fabbione: how did it get into main?
<mdz> fabbione: does something build
<mdz> -depend on it?
<daniels> justdave: even if it's just back to the component text box with no selector
<fabbione> apt-cache rdepends shows only the 3 packages i mentioned
<daniels> fabbione: not too bad, I've been way too busy lately (moving back home today) and am organising stuff like that
<fabbione> mdz: iirc we forced it into main
<daniels> fabbione: is starting on the 1st or the 8th better for you?
<fabbione> daniels: up to you.
<mdz> fabbione: if it is not in one of the seeds, and it is not depended upon by another package, it should not be in main
<fabbione> daniels: as i wrote you can come the 1st and stay until Dec Conf
<justdave> daniels: oh, you mean the download size on the page because of the component list?
<mdz> elmo has a tool which shows the differences between germinate and the archive, and it should have shown up there
<fabbione> daniels: but you need a room somewhere
<mdz> maybe elmo snuck it in because he needs it to implement the easter egg
<fabbione> mdz: i didn't check the seeds yet...
<fabbione> could be..
<mdz> fabbione: it's not in supported or desktop
<mdz> I don't have germinate stuff on my laptop
<fabbione> neither do I here (in general)(
<fabbione> web?
<mdz> figlet                                | figlet                       | linda (Build-Depend)                     | Carlos Laviola <claviola@debian.org>                                      |          149092 |             832
<mdz> fabbione: linda build-depends-indep
<fabbione> WTF
<fabbione> why the hell linda build-dep on figlet
<fabbione> mdz: should we kick linda?
<mdz> fabbione: no, but we could fix it
<fabbione> so that figlet will be dropped to universe?
<fabbione> mdz: kick = fix linda
<mdz> yes
<mdz> fabbione: I thought you meant kick = kick linda out
<daniels> fabbione: ah, right
<fabbione> well.. that too :-)))
<daniels> justdave: yeah, it really hurts my modem
<fabbione> linda (0.3.1) unstable; urgency=low
<fabbione>   * Building:
<fabbione>     - Put figlet, groff-base, file in the Build-Depends, since passing the
<fabbione>       test suite is required for building. (Closes: #245407)
<fabbione> mdz: i am taking the bug and see what we can do about it :-)
<mdz> ok
<fabbione> i don't think it is too dangerous to drop that specific test suite
<fabbione> since it has been tested already several times
<mako> mdz: that subject was a joke.. if people dont' get it i can change it :)
<mako> fabbione: thanks, fixed in arch
<fabbione> mdz: permission to upload linda :-))))
<mdz> fabbione: sounds good
<fabbione> mdz: change is trivial. 2 lines modified in the tests/run_tests.py
<fabbione> mdz: nothing more than that
<fabbione> package builds fine
<mdz> fabbione: works for me
<mdz> fabbione: check germinate rdepends to make sure nothing else uses it that I missed
* daniels stares at Qantas.
<justdave> mdz: now I can't make it boot with devfs=mount,dall either.  I think it was a fluke when it booted the first time.
<daniels> Melbourne<->London $1845, Melbourne<->Copenhagen $9363.
<fabbione> it seems to be only linda
<fabbione> daniels: buy a Melbourne<->London with quantas and SAS from London to Copenhagen
<fabbione> SAS or maerskair
<daniels> fabbione: that's what I'm going to do
<daniels> fabbione: given I'm Melbourne->London->Copenhagen->London->Spain->London->Melbourne (no direct flights from Spain)
<fabbione> daniels: isn't easier: Melbourne->London->Copenhagen->Spain->London->Melbourne ?
<fabbione> you can skip to fly to london again IF you want to stay around here
<fabbione> it's up to you
<fabbione> also.. we don't know if it is Spain yet
<mdz> justdave: I see; please update the bug if you haven't already
<mdz> justdave: how many times have you tried booting?  maybe it's a race condition and it works sometimes?
<sladen> daniels: what type of dollahs are those?
<daniels> sladen: $au
<pitti> Hi guys!
<fabbione> mdz: can i fix 2049?
<fabbione> pitti: peer-review for 2049: one line change: s/cupsd/cupsys/ in the init script on a var used only to print the name of the script in case of "usage"
<pitti> fabbione: #2049: it looks like you should rather s/reload/force-reload/?
<pitti> fabbione: ah , soory
<fabbione> pitti: no no.. the reload has been removed on purpose
<pitti> fabbione: no, you are right
<pitti> fabbione: yes, that was me :-)
<fabbione> tsk :P
<pitti> fabbione: I thought that was an error message by another program calling cupsys init script
<pitti> fabbione: looks trivial
<fabbione> pitti: wouldn't be better to leave the reload pointing to stop/start ?
<fabbione> pitti: yes i am asking peer review before uploading :-)
<pitti> fabbione: well, it does not really reload cupsys, but restart it
<pitti> fabbione: reload is optional anyway, force-reload is the one which must exist
<fabbione> right
<fabbione> ok can i go for the s/ upload?
<pitti> fabbione: before my changes, there really was a reload option in cups (which restarted 90% of the system anyway, but it was the same process)
<pitti> fabbione: but that did not work as non-root, so I restarted cups completely
<fabbione> yesi read the changelog
<fabbione> pitti: you still didn't answer my question ;)
<fabbione> <fabbione> ok can i go for the s/ upload?
<pitti> fabbione: yes, I thought I said so
<fabbione> oky
<fabbione> done
<fabbione> one orphaned bug less
<plovs_work> where is the transcript of yesterdays technical board meeting?
<pitti> mdz: shall I care for DSA 558-1? (security bug in apache)
<fabbione> pitti: ?
<fabbione> for which version of apache?
<pitti> fabbione: this DSA talks about a fixed problem in 2.0.51-1
<pitti> fabbione: but we still have 2.0.50-something
<pitti> fabbione: or did you already fix it in ubuntu3?
<fabbione> pitti: i think thom did backport the fixes already
<fabbione> and please.. call it apache2 :-)
<fabbione> apache = apache1.3 ;)
<pitti> fabbione: okay, next time :-)
<pitti> fabbione, mdz: forget about this, it's already fixed. Sorry
<fabbione> plovs_work: there was no meeting as far as i can tell
<Mithrandir> doko_: is the fritz driver in the restricted modules package now? (on i386)?
<plovs_work> fabbione, ok, misread wiki then, sorry 
<doko_> Mithrandir: no, the person at AVM was in vacation the last two weeks. He emailed we yesterday that he will respond soon.
<doko_> what kind of agreement (email/fax) do we need to redistribute the drivers?
<Mithrandir> doko_: ok; if you could prod me once we have them, I'll be happy to test on my gateway.
<pitti> Can anybody please peer-review the patch in #2069? It's a bit ugly, but minimal and unintrusive
<elmo_> pitti: looks okay to me
<elmo_> (I assume the configuration is dealt with by pppconfig or something similar?)
<fabbione> pitti: what about dpkg-reconfigure?
<fabbione> wouldn't the exit 0 kill it completely?
<pitti> fabbione: yes
<pitti> fabbione: there's wvdialconf 
<elmo_> so would the exit 0 that's already there? :)
<pitti> fabbione: and there are the gnome-system-tools
<fabbione> pitti: ok
<pitti> elmo_, fabbione: right, if /etc/wvdial.conf exists, the old code did nothing anyway
<elmo_> SKIP (too new)
<elmo_> Rejected: Unknown distribution `unstable'.
<elmo_> pitti: ----^
<pitti> elmo_: gar, sorry. I'll upload again.
<elmo_> *blush* that's in the interdiff, I suck too
<tof--> hi all
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 20 RC bugs to go
<fabbione> Mithrandir: 1854
<fabbione> Mithrandir: does it happen if you run only apt-extracttemplates on a large amount of debs?
<Mithrandir> fabbione: haven't tried yet.
<fabbione> Mithrandir: that can be a test case...
<fabbione> Mithrandir: in order to get the % counter i modified slightly the perl script that calls apt-extracttemplates
<fabbione> i doubt the bug is in the modifications but it can be related to perl?
<Mithrandir> I wonder if it has to do with threading, somehow.
<Mithrandir> or c++
<Mithrandir> but it's weird that gzip is the one hanging
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 19 RC bugs to go
<fabbione> time to prepare some food
<amu> fabbione: is your GF in vacation ;)
<Mithrandir> seb128: 2097, worksforme, ok with you?
<Mithrandir> seb128: as in, the patch fixes it for me.
<seb128> ok, I'll upload the fix
<Mithrandir> thanks
<Mithrandir> it also does a ton of translation, config.{guess,sub}, some XML files updates here.
<seb128> np
<thom> pitti: the bug in 2.0.51 only affects 2.0.51
<thom> so, you won't see anything in the changelog
<pitti> thom: nevermind, I already saw that the security fix from 2.0.51 was already backported. Thanks anyway
<fabbione> amu: eheheh no.. she is at work :-))
<sivang> anybody messed with dpkg / apt / aptitude recently? aptitude upgrade last night, now my warty is dead...
<sivang> kernel boots (i think) however , "cannot execute /sbin/mgetty"
<sivang> "ld has spawned too fast"
<sivang> ??
<pitti> Hi sivang!
<rburton> hm, no "ant" package in universe. i presume contrib isn't being autobuilt into universe
<thom> rburton: nyet
<rburton> darn
<elmo_> not yet,
<rburton> it seems that shutdown with nfs homes hangs
<rburton> would this be a known bug?
<rburton> it appears that something is trying to access portmap, but that has already been shutdown
<pitti> rburton: I can't find it in bugzilla
<rburton> k
* rburton curses https site certificates
<elmo_> amen
* elmo_ is getting openssl(1) to segfault simply by having a reference to a non-existent file.  quality.
<hazmat> hi folks, i have a long install report i wrote up with some suggestions and issues, i'm wondering which list to send it to.. any suggestions?
<fabbione> hazmat: ubuntu-users
<hazmat> is sounder dead then?
<fabbione> hazmat: it was changed to chitchat something, but basically yes
<hazmat> fabbione: ok, thanks.
<fabbione> np
<sivang> hey pitti, whassup?
<pitti> sivang: the usual stuff, bug fixing :-)
<sivang> pitti : ofcourse. I see 19 only now. good work:-)
<sivang> for everybody ofcourse ;-)
<fabbione> i think i am into BDSM
<fabbione> i hate X, i love X
<fabbione> i can't sleep at night thinking how to switch to X.org
<fabbione> but i don't feel happy if i don't fix it
* fabbione is on the edge of a X nerves breakdown
<thom> addict :-)
<fabbione> thom: really.. it's becoming a drug
<fabbione> someone needs to take X away from me
* fabbione can't wait the 1st of Nov to start the X-Men meeting :-)
<sivang> fabbione : X-Men?? ;)
<fabbione> people that maintains X ;)
<fabbione> basically me and daniels 
<fabbione> we all have some kind of unnatural power
<DrXavier> see
<DrXavier> i can read and control people mind
<sivang> fabbione : then I'll be Wolverine ;-)
* sivang rebooting. see ya all laterz
<elmo_> fabbione with mind control - women of the world RUN AWAY..
<elmo_>  :P
<fabbione> elmo_: ahha
<fabbione> too bad Xavier is on a wheel chair ;)
<azeem> it's always the X maintainers who strive for that super power
<fabbione> azeem: WE HAVE SUPER POWERS
<fabbione> :P
* azeem fears keithp :)
<fabbione> ok.. time to stop for today
<fabbione> my brain is melting down
<thom> -rw-r--r--    1 thom     98693974 2004-10-06 12:52 ../mozilla-firefox_0.99+1.0PR.1-0ubuntu1_i386.deb
<thom> *ahem*
<pitti> fabbione: don't let that happen
<fabbione> thom: HOLY S**T!
<fabbione> what did you break this time?
<pitti> thom: what's with this version? I already have it installed...
<pitti> thom: ugh, it's a bit biiiiiig
<pitti> thom: is this the debugging version?
<fabbione> slightly :-)
<azeem> it has the WWW pre-cached
<pitti> ALL the www?
<fabbione> PR0N!!!
<thom> yes, this is the magical no-internet-required version
* fabbione apt-get updates
<pitti> http://unluckystar.net/media/downloadwww.gif
<thom> totally unstripped, -O0
<pitti> thom: unstripped? so it *is* kind of p0rn :-)
<rburton> poor poor thom
<pitti> thom: are you able to get a nice backtrace for the crashing sites?
<fabbione> at least it is VERY sexy!
<pitti> thom: a guy on the mailing list enumerated a few other sites that crash for him
<thom> pitti: yeah
<thom> it crashes reproducibly in gmail
<thom> seb128: dpkg -L libatk1.0-dbg|grep atk-1
<thom> /usr/lib/debug/usr/lib/libatk-1.0.so.0.800.0
<thom> um, me thinks that ain't quite right
<seb128> thom: should be directly in /usr/lib/debug ?
<thom> that's what libgtk2.0-dbg and libpango1.0-dbg have, yeah
<seb128> $ ls /usr/lib/debug/usr/lib/
<seb128> gtk-2.0                libcspi.so.0.10.4  libgnomeui-0             libloginhelper.so.0.0.0
<seb128> libatk-1.0.so.0.800.0  libglade           libgnomeui-2.so.0.800.0  libspi.so.0.10.4
<seb128> grumpf
<thom> pitti: i should've let you take this on, i can't work it out at all
<pitti> thom: I can debug the crash if you want
<pitti> thom: Can I download the deb somewhere?
<Kamion> pitti: surely unstripped is precisely the opposite of pr0n ...
<pitti> Kamion: ugh, right. 
<thom> pitti: it's a 90 meg deb, it'll take longer than a couple of hours to upload it :/
<pitti> thom: okay, then I will build it on my own
<thom> pitti: i'll send you my debian/
<pitti> thom: did you do any changes in it?
<pitti> thom: did you adopt the DEB_BUILD_OPTIONS thingy?
<thom> yeah, adopted those, and added some more to get the libraries stripped
<pitti> thom: doesn't take dh_strip care of it?
<elmo_> thom: tube it to the DC ;-)
<thom> pitti: you need to pass --disable-strip --disable-strip-libs to configure
<pitti> thom: ah, nice
<pitti> thom: of course I already deleted the stuff yesterday, apt-get source'ing again :-)
<thom> d'oh :/
<thom> pitti: my BT is at http://www.planetarytramp.net/firefox-bt
<pitti> thom: nice. #95, var_args looks scary, but maybe that's normal
<thom> yeah, that one concerned me a little
<pitti> thom: did you already send me your debian/? SO far I've got no mail
<pitti> thom: source download is complete, I can start to build it
<thom> it's cleaning, currently
<thom> wait one
<pitti> thom: got it, thanks
<pitti> thom: is it normal that most of the dpatches aren't included in 00list?
<thom> pitti: yeah, i turned them off
<thom> to try and work out if it was a problem with one of the patches
<pitti> thom: ah; should they be normally turned on?
<thom> normally they'd be turned on
<elmo_> is it linking anything statically?
<elmo_> if not, just blame doko and be done with it ;-)
<thom> heh
<pitti> thom: 06_fix_freetype_compile was added by you, but it's not in the changelog nor in 00list; shall I enable it?
<thom> no, leave that turned off
<thom> sorry, that's stolen from redhat and looked initially like they added it in response to similar problems
* Kamion decides to make the ChallengeResponseAuthentication default be to leave it at yes even if PasswordAuthentication was no
<daniels> Kamion: comments on #1683, #1301?
<Kamion> since new installs of openssh since 1:3.8p1-2 have set PasswordAuthentication no
<Kamion> daniels: fixing #1683 properly involves going through languagechooser, countrychooser, base-config termwrap, and possibly console-data, and making sure they all have the right answers for that locale.
<Kamion> I don't think automatic unicode_start is the right answer
<Kamion> if you want to take care of that bug you're welcome ...
* netjoined: irc.freenode.net -> sendak.freenode.net
<daniels> Kamion: ahr.  I might levae it to someone who has a slightly better idea of what they're doing, in that case ;)
<Kamion> daniels: for #1301, xfs_freeze is not anywhere near sufficient, I'm afraid; Daniel Silverstone and I spent most of last Friday trying all the possibilities we could think of and failed
<daniels> Kamion: er? I was always able to hack around it with xfs_freeze followed by xfs_unfreeze
<Kamion> daniels: if you want to learn about localization in the installer, #1683 is a good place to start :) you'll probably know more about it than me by the time you're finished ...
<Kamion> daniels: it's a race condition - you were lucky
<daniels> Kamion: heh
<daniels> Kamion: oh, hooray.  whacky.
<Kamion> you don't need xfs_freeze in a udeb anyway, because the obvious place to put it is in grub-install and that gets run inside a chroot
<Kamion> but we did try xfs_freeze -f /boot/grub followed by xfs_freeze -u /boot/grub, and grub still hung
<Kamion> (in grub-install)
<daniels> Kamion: ah, in the chroot, that's OK
<Kamion> daniels: I'm almost tempted to say that the right answer for warty is to make the install fail hard at partitioning if you try to put /boot on XFS
<Kamion> there's already a warning I think, but people ignore it
<daniels> Kamion: yeah, fair enough
<daniels> Kamion: or grub-install; sleep 10; killall -9 grub-install; xfs_freeze; xfs_unfreeze; grub-install :P
<Kamion> possibly :)
<Kamion> or unmount /target, which we think is the only reliable way, but is *very* hairy to do at that point ...
<daniels> um, btw, if that gets implemented, I didn't suggest it
<daniels> Kamion: does xfs_freeze; sync; xfs_unfreeze help?
<Kamion> not as far as I recall
<Kamion> we also tried sync; xfs_freeze -f; xfs_freeze -u; sync
<daniels> argh!
<daniels> freeze->sync->unfreeze would make the most sense to my mind, since freeze just blocks/queues all IO, and unfreeze reallows it
<daniels> maybe you want sync->freeze->sync->unfreeze(->sync?)
<Kamion> possibly, but apparently sync only guarantees that the data has been written to the journal, not to the disk
<Kamion> s/disk/actual filesystem/
<Kamion> there was a thread about it from March on the xfs-devel list; Google finds it fairly easily
<daniels> iirc _freeze flushes the journal, though
<Kamion> freeze; unfreeze worked for the Fedora guy apparently, but we duplicated what he did as closely as possible and it didn't work for us
<daniels>        The  -f  flag  requests  the  specified  XFS  filesystem  to  be frozen from new modifications.  When this is
<daniels>        selected, all ongoing transactions in the filesystem are allowed to complete, [...] 
<Kamion> the whole thing scares me too much at this stage, I'd rather forbid it and revisit it for Hoary
<daniels> yeah, if it's looking so shakily non-trivial
<Kamion> we're going to get very little testing of installer changes from now on, so they do need to be safe
<daniels> yeah
<Kamion> it's basically only the sort of people who grab daily builds
<daniels> hence why you can have 1683
<Kamion> damn, I wanted to give that to you. :)
<daniels> dude, I'm not going to break the installer a fortnight before Warty :P
<daniels> i mean, learning about stuff is fun and cool, but, er
<Kamion> I'm happy to review your changes, I'm confident I can tell the difference between something that will break things and something that won't
<daniels> hm, OK
<daniels> i might snarf it, then
<daniels> feel free to reassign; you'll probably get to the bug in the next half an hour, before the page loads here :P
<Kamion> daniels: also I think there's a similar bug in Debian that's been discussed recently
<Kamion> look in the changelogs of the packages I mentioned
<Kamion> possibly solved, even
<daniels> Kamion: sure, I'll check it out when I get back from the supermarket
<Kamion> thanks, will reassign
<daniels> cleaning products and energy drinks: two great tastes that taste great together
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 18 RC bugs to go
<lamont> doko/mdz: i386/amd64 built everything they tried (all build-dep-ing), ppc is still chunking away...
<thom> anyone care to review https://bugzilla.ubuntu.com/attachment.cgi?id=356 ?
<daniels> thom: would suggest using modprobe -q instead of redirection, but it fits in nicely with the style, so meh; that aside, the only comment I have is `` -> $()
<daniels> thom: looks otherwise correct
<thom> daniels: 14:13 < tbm> StevenK: hey, do you know how to contact daniels?  apparently his email's not working or something
<daniels> gah. thanks for the heads-up.
<sivang> has both lp and gnome-daemon-settings bug been fixed?
<thom> daniels: on OFTC #d-d
<sivang> where have all critical bugs went? ;-))
<Mithrandir> sivang: crushed. :)
<sivang> Mithrandir : wowo :-)) can I find them (see what's been done to fix) on the "closed" bugs?
<Kamion> they're all in bugzilla ...
<thom> ok, and https://bugzilla.ubuntu.com/attachment.cgi?id=357 (it's unbelievably trivial)
<rburton> and i assumed you were loading toshiba_acpi on purpose
<thom> heh.
<thom> i assume the eventual intent is to handle this crap with hotplug
* Kamion checks in all his openssh changes and ponders uploading
<Kinnison> thom: have you uploaded the nice new acpi-support yet?
<thom> no, i should get that reviewed too
<Kinnison> thom: It's getting *really* tired having to plug my laptop in to shut it down
<thom> Kinnison: i forgot, matt already said i could upload. done
<Kinnison> thom: rock on
<Kinnison> thom: I'll let you know how I get on later
<thom> coolies
<pitti> thom: mine is bigger than yours :-)
<pitti> thom: -rw-r--r--    1 martin   martin   10645500 2004-10-06 15:59 mozilla-firefox_0.99+1.0PR.1-0ubuntu1.1_i386.deb
<pitti> thom: no, it isn't. A digit it missing...
* rburton can't wait for thom to be assigned to oo.o bug hunting
<thom> heh
<pitti> thom: DAMN! After two hours of compiling this thing is still stripped
<pitti> thom: What did I do wrong? I built with DEB_BUILD_OPTIONS=nostrip,noopt debuild -us -uc -b
<pitti> thom: and indeed the files were compiled with -g -O0
<thom> that's exactly what i did
<pitti> thom: $ file browser/app/firefox-bin
<pitti> browser/app/firefox-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
* pitti cries a little
<Mithrandir> pitti:  rm browser/app/firefox-bin ; make ?
<pitti> Mithrandir: and all the libraries?
<pitti> thom: your --disable-strip logic is wrong, AFAICS
<thom> huh
<thom> file ~/tmp/x86-home/usr/lib/mozilla-firefox/firefox-bin
<thom> /home/thom/tmp/x86-home/usr/lib/mozilla-firefox/firefox-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
<pitti> thom: ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) will be false if you give nostrip
<Mithrandir> pitti: find -name \*.so | xargs rm as well, then?
<thom> i'm sure i gave you the version i was using
<pitti> Mithrandir: yes, something along that line. Thanks, will try
<pitti> thom: I think ifeq needs to be changed to ifneq
<pitti> thom: or --disable-strip and --enable-strip swapped
<thom> ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
<thom> STRIP=--enable-strip --enable-strip-libs
<thom> else
<thom> STRIP=--disable-strip --disable-strip-libs
<thom> endif
<pitti> thom: right, that's how it should be
<thom> is what my debian/rules has
<pitti> thom: my debian/rules has it exactly the other way round
<thom> hrm. must have found an old one
<thom> very, very sorry about that
<pitti> thom: well, it does not matter that much, I'm busy with aptitude anyway
<pitti> thom: did you change anything else?
<thom> nope
<pitti> thom: okay, then I will just make the swap myself. Thanks.
<thom> it'll take about 40m for my .deb to upload
<thom> if you want to just download that
<pitti> thom: can I download it right from your machine?
<pitti> thom: my connection is not faster (about 50 kB)
<thom> no, i'm behind nat :/
<pitti> thom: me too :-)
<pitti> thom: nevermind, I just rebuild it
<pitti> thom: I will fix aptitude and maybe #1552 in the meantime
<pitti> thom: or have dinner :-)
<thom> pitti: heh :-) it'll be at www.planetarytramp.net/mozilla-firefox_0.99+1.0PR.1-0ubuntu1_i386.deb in about 40m, so if that's fasdter it's there
<pitti> thom: thanks
<daniels> pitti: only 10MB? that's tiny
<pitti> daniels: see above, due to a slight error in debian/rules it got stripped
<daniels> pitti: even so :)
<daniels> if your source tarball is less than 50MB when .bz2'd, I have no sympathy :P
<pitti> daniels: well, 10 MB for a browser should be more than enough :-)
<daniels> pitti: you'd think that ...
<pitti> daniels: hey, in C64 times software needed to fit into 64 KBytes! :-)
<daniels> do you really want to be running Moz on C64?
<pitti> daniels: _even_ the graphical environment (GEOS), to be precise :-) (SCNR)
<daniels> hm, that reminds me, I still need to get around to seeing how long KDE takes to load on an m68k
<daniels> pitti: X is a hulking PoS, news at 11 :P
<pitti> daniels: poor m68k
<pitti> daniels: it already takes ages at my Duron 1.3
* daniels has been advocating throwing away all existing X implementations and starting from scratch for ages now.
<azeem> it was interesting to read keithp blog about twin
<pitti> daniels: I already heard of several alternatives, one was called 'Y' and was really tiny
<elmo_> azeem: keithp blogged about ben a. ?
<azeem> pitti: twin is supposed to be less than 50KB, from what I read
<pitti> azeem: well, if an X replacement relies on the kernel framebuffer (or something like that), it shouldn't be that big
<daniels> pitti: y is good for a laugh
<pitti> azeem: but something has to provide all this 3D and network stuff, so 50 KB are certainly not enough for a Desktop
<daniels> pitti: and relying on the kernel framebuffer really sucks
<pitti> daniels: I know, I tested it and was pretty amused
<daniels> twin is good for putting on a computer watch or something equally hypothetical
<pitti> daniels: but what makes X actually so big? Only device drivers?
<pitti> daniels: or layers over layers of abstraction layers which abstract other layers?
<daniels> pitti: if you know anyone who wants to fund me, keithp, jaymz, anholt, ajax, and possibly andersca full-time for a year, let me know ;)
<Mithrandir> does the kernel framebuffer support any kind of 3d?
<daniels> pitti: drivers, support for everything under the sun, a whole crapload of useless libraries/fonts/docs (in FrameMaker format, no less), and some useless abstraction layers
<daniels> drivers are also pretty big, I suppose
<pitti> Mithrandir: none that I know of
<daniels> Mithrandir: last I looked, there wasn't any real good 2D acceleration in any of them
<pitti> Mithrandir: however, 2D support is quite good in the specialized drivers (riva, radeonfb etc.)
<pitti> daniels: not?
<pitti> daniels: the radeonfb driver is pretty cool
<daniels> pitti: is it still as buggy?
<Mithrandir> yeah, it's buggy.
<daniels> pitti: last time I tried, when I got it to work, it left droppings all over my screen
<pitti> daniels: on a 9200 it works like charm
<pitti> daniels: no, I never encountered that
<pitti> daniels: but maybe it blurbs on better radeons
<daniels> pitti: i saw it on a 9000 and an 8500
<daniels> anyway, I'm killing my bandwidth by rsyncing all the fd.o CVS repos back here right now so I can do some hacking
<daniels> so, I'll talk to you later :)
<pitti> daniels: odd. Well, if it works on one system and crashes at another, it still counts as buggy, I suppose
* lamont reboots: new kernel
<lamont> well, once X and the other 100 packages install... :-(
<sivang> fabbione : integerating X.org is going to be a pain in the arse? ;-)
<sivang> (seen your comments about it increasing your insomnia sympthoms ;-)
<thom> pitti: 8 minutes
<daniels> sivang: it's a massive amount of work
<thom> pitti: done
<pitti> thom: thanks!
<thom> 94MB  29.8KB/s   54:00
<lamont> yea! new metacity actually remembers what workspace a window is in!
<Kamion> please review https://bugzilla.ubuntu.com/attachment.cgi?id=361
<lamont> Kamion: nothing leaps out at me in 60 seconds or less.
<daniels> Kamion: looks OK to my tired eyes
<lamont> Kamion: would it be simpler to just sync the debian package?
<Kamion> lamont: we've already forked it
<Kamion> otherwise I would :)
<lamont> right
<Kamion> set_config_option is hairy but I think it's right
<Kamion> uploaded
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 17 RC bugs to go
<Kinnison> w00p
<Kamion> ooh, I don't have the highest number of RC bugs any more
<rburton> i should find the time to put ubuntu onto my laptop
<rburton> then i can get thom to fix acpi for me
<lamont> Kamion: yeah, but herbert's are all in _one_ package... :-)
<thom> 14 of the 20 bugs assigned to me are about firefox
<thom> *sigh*
<elmo_> dude, I told you were the Mozilla czar
* lamont solicits ideas for debian #274777 (also in warty)
<Mithrandir> does anybody care about ibcs?
<lamont> Mithrandir: was that a vote for Conflicts?
<Mithrandir> yeah
<lamont> sold
<Mithrandir> or talk to the ibcs maintainer
<Mithrandir> what does trace(8) do?
<lamont> or both. :-)
<lamont> I believe that's sendmail -bt support
<lamont> nope
<Mithrandir> NAME
<Mithrandir>        bounce - Postfix message bounce or defer daemon
<Mithrandir> is what I get from man 8 trace
<lamont> yeah - it's the same man page for all 3
<lamont> bounce defer trace
* lamont goes digging
<Mithrandir> lamont: well, dpkg -S trace | grep post only returns the man page here..
<lamont> looks to be DSN stuff
<lamont> ibcs is universe
<lamont> mdz: thoughts?
* lamont grumbles at people running the price up on a couple of auctions.
<lamont> bidwatcher should be main, dammit.
<mdz> morning
<lamont> mdz: and a fine thought that is, too. :-)
<mdz> lamont: both packages should be shot for naming a binary 'trace'
<Mithrandir> mdz: postfix doesn't have any binaries named trace, it seems.
<lamont> mdz: well, yes... I suppose I could rename it to postfix-trace
<Mithrandir> mdz: it's just a service in master.cf
<mdz> ah, so it's a manpage conflict?
<Mithrandir> looks like it.
<Mithrandir> : tfheen@yiwaz ~ > dpkg -S trace |  grep /trace$
<Mithrandir> oftc-hybrid: /usr/share/oftc-hybrid/help/opers/trace
<Mithrandir> irssi-text: /usr/share/irssi/help/trace
<Kamion> trace.8postfix.gz?
<lamont> man8/trace.8:
<lamont>         echo .so man8/bounce.8 >$@
<Mithrandir> (this box has postfix installed)
<mdz> is ibcs even actively maintained?
<Kamion> man section extensions are the standard way to solve conflicts
<mdz> that sounds reasonable
<lamont> Kamion: I like that - is it just a matter of delivering it as trace.8postfix?
<Kamion> lamont: yes
<lamont> and should I deliver all of them in that section, or just the conflicts?
<Mithrandir> mdz: seen my latest comment on 1854? :/
<pitti> mdz: morning
<mdz> Mithrandir: fortunately, that bug only happens to you :-P 
<Kamion> mdz: what do you think about this wget "security" bug? #261755
<Mithrandir> mdz: has anybody actually tried to reproduce it using the instructions I gave?
<mdz> Mithrandir: yes
<mdz> Mithrandir: except for the bit about "buy a P4 HT and use an SMP kernel"
<mdz> Kamion: I think it's silly
<Mithrandir> mdz: well, given that you need a P4 HT.. :)
<Kamion> that was my initial reaction
<mdz> Jan Minar has filed a bunch of similar bugs
<Kamion> mdz: I'm being asked to review it for pushing into sarge
<mdz> I'm waiting for the one against cat(1)
<mdz> where it will allow arbitrary characters to be displayed on the terminal
<Kamion> can I quote you there, to the wget maintainer?
<mdz> "I think it's silly" -mdz
<mdz> like that? :-)
<Kamion> approximately :)
<mdz> it's especially discouraging that the proposed patch has bugs
<mdz> sure, quote me if you think it'd help
<lamont> Kamion: should I deliver all of the section 8 manpages in 8postfix, or just trace?
<Kamion> probably best to be consistent; perhaps deliver all the ones that are just master.cf services in 8postfix
<mdz> Kamion: did you determine that unfuzzying translations with s/Debian/Ubuntu/ was relatively non-evil?
<mdz> Kamion: (#2085)
* Kinnison goes to try thom's new acpi-support package
<mdz> justdave: please attach a dmesg from a successful boot to #1379
<thom> so my dad was installing ubuntu on a vaio with a usb cdrom drive last night
<thom> he was going to call if he had any problems
<thom> no phone call :-)
<thom> uh, s/usb/pcmcia
<pitti> thom: nice idea from you to disable your phone :-)
<thom> heh
<thom> pitti: having fun with firefox?
<pitti> thom: I just tried to debug it
<pitti> thom: it's a mess
<thom> yes
<thom> :(
<pitti> my current quick "fix" is to use Mozilla.
<pitti> I will return to that tomorrow, I'm too tired today to deal with such a monster
* Kinnison hands thom 2 x $BEER tokens
<thom> eeexcellent
<mdz> pitti: regarding #2085, I noticed the description for 'base' and it should be changed semantically
<mdz> pitti: section 'base' does not at really correspond to the base system at all
<pitti> mdz: okay, I can change that, too
<pitti> mdz: what would you propose?
<pitti> mdz: BTW, I hope that it was okay for me to prepare patches, although the bug was assigned to you
<Kinnison> daniels: Erm; gnome-volume-manager isn't responding to plugin events again :-(
<pitti> mdz: my own list got major-free this morning :-)
<mdz> pitti: I don't know what the text should be; section 'base' is not very meaningful
<mdz> it's not very meaningful in Debian, either, but even less so in Ubuntu :-)
<pitti> mdz: I also stumbled about this in my NM processes
<pitti> mdz: its ,well, just "base packages" - packages which we do not have a special name for...
<sivang> aren't they providing "basic system capabilities" ?
<sivang> the essentials
<pitti> all these are just synonyms
<mdz> the essentials are Essential: yes packages
<pitti> mdz: I know, but an user will not care for the difference
<pitti> mdz: What about "Ubuntu system packages - Packages in the "base" section provide the basic functionality of an Ubuntu installation (hardware support, package management, etc.)"
<fabbione> daniels: 1117, can you give the driver to Herbert please?
<fabbione> mdz: i solved the problems with the ADSL line transfer. In the worst case I will have 2 to 5 hours of downtime
<fabbione> mdz: 2 if the adsl line is ok, 5 if it is not (and my previous employer will host me in his offices)
<mdz> fabbione: nice
<mdz> pitti: the thing is, there are many packages in that category which are not in section 'base'
<mdz> and things in section 'base' which do not fit that description
<pitti> mdz: well, the whole categoryseems to be more or less arbitrary
<mdz> pitti: correct, which is why it is hard to describe :-)
<pitti> mdz: "Packages which we did not find a better section for "
<elmo_> base should be what debootstrap installs or it shouldn't exist
<pitti> elmo_: certainly a nice explanation for a new user :-)
<Kinnison> thom: want an amusing mozilla-firefox bug? </sarky>
<thom> oh, i'm sure amusing is just the word *sigh*
<pitti> mdz: what do you think about the patches in general? Shall we aim for new translations? Any thing I forgot about?
<Kinnison> thom: I can reproducably stop firefox scrolling with the scrollwheel by viewing long bugs on bugzilla.ubuntu.com
<thom> Kinnison: already filed
<Kinnison> thom: Boo hiss; I thought I'd found a new one
<Kinnison> thom: fix it
<thom> <pre> areas and <code> areas seem to do it
<Kamion> mdz: yes
<Kamion> mdz: where it's obviously possible; sometimes it's hard
<thom> Kinnison: #1962
<Kamion> ohbugger; archive-copier needs to copy mdetect, xresprobe, and laptop-detect
<Kamion> forgot about those when I turned off copying of Ship
<mdz> pitti: the patches look fine
<pitti> mdz: so we need a "base section description contest" now? :-)
<mdz> pitti: "miscellaneous packages which provide basic functionality"
<Kamion> miscellaneous sounds wrong to me there
<mdz> Kamion: any idea about that kbd-chooser hang on -users?
<mdz> Subject: Re: Install choking after country selection
<Kamion> it has connotations of "extra"
<Kamion> mdz: haven't had time to look at it yet, will do
<Kamion> it's probably hardware-specific to some extent which makes it annoying
<Kamion> and damnit, I forgot to do anything about Nathaniel's openssh init script patch
<fabbione> mdz: i will have to upload X again. daniels wacom backport is botched
<mdz> fabbione: is that related to the wacom driver update enhancement bug?
<fabbione> mdz: yes
<fabbione> mdz: the driver that is inside X now is not meat or fish
<thom> fabbione: "fish or fowl"
<fabbione> thom: shuuus ;)=
<pitti> Kamion: seems that all in all the Debian description is not the worst one :-)
<mdz> pitti: let's leave it as-is for the sake of getting the other work done
<pitti> mdz: okay, I agree. We can still upload another version with more translations and some tweaks
<pitti> mdz: so any other things before approval?
<mdz> pitti: no, looks good
<pitti> mdz: okay, then away with it
<elmo_> python-gtk2-doc_2.4.10-2ubuntu1_source.changes 
<elmo_> who uploaded that/
<elmo_> s#/#?#
<fabbione> probably seb?
<thom> Kinnison: https://bugzilla.mozilla.org/show_bug.cgi?id=263198
<fabbione> he was the one asking for it in the first place
<mdz> elmo_: yes
<Kinnison> thom: cool
<thom> add additional urls if you have 'em :-)
<elmo_> seb128: sorry, due to an obscure technical problem which I won't bore you with the details of, that file was removed - could you reupload just the .changes, please?
* Kinnison smirks
<seb128> elmo_: ok, no problem
<seb128> just the .changes ?
<Kinnison> elmo_: saved.
<elmo_> seb128: yeah
* ..[topic/#ubuntu-devel:pitti] : Ubuntu development -- general discussion on #ubuntu | 16 RC bugs to go
* ..[topic/#ubuntu-devel:pitti] : Ubuntu development -- general discussion on #ubuntu | 15 RC bugs to go
<seb128> elmo_: done (I've also uploaded a libgnomeprint changes by mistake, just ignore it)
<thom> an obscure 'rm -f' by "ftpmaster" problem? :p
<seb128> time to dinner, later
<Kinnison> thom: ssssh. you'll give his s3kr1t away
* lamont looks around for a postfix reviewer.
<sivang> lamont : I would, as soon as my warty's XFS is fixed..;-)
<Kinnison> sivang: what's up now?
<Kinnison> sivang: or is it in general?
<thom> pitti: https://bugzilla.mozilla.org/show_bug.cgi?id=255372 is the upstream for the firefox bug
<sivang> Kinnison : ah, some funky output from xfs_check, and xfs_repair
<lamont> sivang: most of the change is adding README.Debian files..
<Kinnison> sivang: aah yes; I had that on Friday
<Kinnison> sivang: been running Debian's 2.6.7 kernel since then with no problem
<lamont> patch is at people.ubuntu.com/~lamont/postfix.diff
* Kinnison isn't completely convinced 2.6.8* is safe with XFS
<sivang> Kinnison : this on the bugzilla I hope?
<Kinnison> sivang: Not sure
<thom> we really need an UPSTREAM status badly
<sivang> lamont : this a debdiff?
<lamont> it's a diff -ur between the old tree and new one.
<lamont> what's a debdiff? :-)
<pitti> thom: okay, thanks. Let's just pass the buck to upstream, then :-)
<lamont> er, -urN actually
<pitti> thom: however, if it crashes on all pages with javascript popups, this can even be regarded as RC then...
<sivang> lamont : sorry, misunderstanding. I think it
<thom> pitti: agreed
<sivang> lamont : is something comparing too pkgs if I am not mistaken
<thom> mdz: 1676 as major?
<lamont> sivang: yeah, I read the manpage.. 
<sivang> lamont : do you happen to know it's package name on debian sid?
<lamont> it's in devscripts
<lamont>  /etc/init.d/xfree86-common: line 11: /lib/lsb/init-functions: No such file or directory
<lamont> fabbione: daniels: what's up with that???
<pitti> thom: what makes the warty firefox different from upstream's, if it works with upstream?
<pitti> thom: does upstream already have a newer build?
<lamont> pitti: besides build-depends?
<pitti> lamont: you mean the firefox crash is actually a problem in a library?
<lamont> pitti: nfc
<pitti> lamont.explain( "nfc" )
<lamont> "No F***ing Clue"
<pitti> lamont: ah, thanks :-)
<lamont> but build-deps is certainly a difference between the two, I expect.
<thom> pitti: don't know, i don't understand why upstreams works
<thom> pitti: same build
<pitti> lamont: the stack trace does not suggest that it is in an external lib
* lamont shrugs
<lamont> which architecture?
<pitti> thom: different compilers?
<pitti> thom: maybe the bug is triggered only on a particular way of compilation
<pitti> lamont: ppc and i386
<pitti> lamont: the 32 bit ones, amd64 works well
<lamont> pitti: that's just sick and wrong.
<pitti> usually segfaults potentially occur on all architectures, but sometimes the compiler may hide it
<pitti> the bug in gstreamer I tackled with recently was such a case
<pitti> so I don't really believe that the bug is fixed upstream
<thom> pitti: they compile with gcc-3.2, amd64 is on 3.4 and doesn't have the bug (but x86 with 3.4 still does)
<pitti> well, we could try compiling with 3.2 and see if it works :-)
<thom> we could, indeed
<pitti> 7 days before the RC release we have to find faster methods of bug fixing
* pitti ducks
<thom> ... go back to using epiphany by default? :-)
<pitti> thom: mozilla plain works greeeeeat!
<pitti> epiphany is just mozilla with another UI, isn't it?
<thom> a gnome ui, yeah
<pitti> at least epiphany draws in all the mozilla stuff in the dependencies
<pitti> thom: would it help to revert to an earlier build?
<pitti> thom: the upstream bug said something about reintroducing it in version whatever
<thom> pitti: you'd be looking at backporting a stack of security fixes if we go back to 0.9.3 (which was the last version that didn't suck)
<pitti> hmm, as long as they are properly documented and the CVS is available...
<thom> (but firefox 1.0 is a feature goal AIUI)
<thom> *shrug*, i think we need to speak to mdz and jdub and find out what the goals are here, and what we can do
<pitti> thom: well, as long as the boys fix 1.0, then I'm all for it :-)
<pitti> thom: or maybe we can convince lamont to have firefox built with gcc 3.2 :-)
<lamont> gcc-3.2 is ftbfs on ppc
<lamont> and amd64.
<thom> weee
<mdz> thom: hmm?
<mdz> thom: re: 1676, I've never seen it
<pitti> mdz: aren't you on amd64 as well?
<mdz> pitti: not primarily, but sometimes
<mdz> right now I'm laptop-only
<pitti> mdz: I asked because the firefox crash does not appear on amd64
<pitti> mdz: it is pretty annoying
<pitti> mdz: I cannot do online banking and some webmail stuff with firefox, have to take mozilla proper for that
<mdz> my online banking stuff works with firefox in ubuntu
<pitti> mdz: and according to the mailing list, many other people suffer from this as well
<mdz> what's the story upstream?
<pitti> mdz: same thing. Firefox crashes on every page that opens a window with javascript
<thom> mdz: basically, anything that does window.Open() in javascript crashes firefox
<mdz> anyway I can test it without killing my existing firefox and all its tabs?
<thom> mdz: create a test user, go to Applications/System Tools/New Login, log in as that user...
<mdz> aha, -P
<mdz> thom: just tried it in the javascript console, and it works perfectly, doesn't crash
* lamont logs into his bank, fails to crash firefox
<mdz> is there any website I can test with that doesn't require a login?
<pitti> mdz: https://financepilot-banking.mlp.de/ works nice for me
<pitti> mdz: or, rather, crashes
<pitti> mdz: this is my web banking, BTW
<thom> mdz: www.cpsact.com.au and click on CPS Web-Link
<mdz> pitti: when I load that page, it gives me an error in German and firefox tells me that it blocked a popup
<pitti> mdz: you have to accept the popup
<mdz> thom: no crash
<thom> mdz: did you get a popup window?
<mdz> it does open the popup, but it works fine
<lamont> ditto
<mdz> thom: yes
<thom> huh.
<mdz> this is with a fresh default profile, too
<thom> it crashes 100% with current firefox for me
<pitti> mdz: I also tried with a fresh profile
<thom> fresh, stale, or downright smelly profiles
<pitti> mdz: well, the fact that it works on amd64 and fails on i386 shows that it is a somewhat tricky one...
<lamont> about: says firefox 0.10.1
<pitti> mdz: sometimes it even worked for me the very first time, but it crashes the second time
<pitti> mdz: but now I cannot get it to load a single time any more
<lamont> still works here
<pitti> damn, why demos always tend to fail?
<pitti> thom, this _is_ an ugly bug. It hides itself
<thom> interestingly, i can't get cpsact to crash on my laptop, but gmail kills it every time
<lamont> pitti: just lucky, I guess
<thom> mdz: i can send you a gmail invite :-)
<lamont> thom: if you sent me one, could I give it to someone else?
<thom> pitti: and yes, it is a nasty one for sure
<thom> lamont: yeah, absolutely
* lamont has a use for one or two then
<lamont> (it'll let me boot my fire chief off the itanic in the other room..)
<pitti> thom: Will you beat me up if I tell you that the CPS thingy works for me?
<pitti> thom: can we please swap our online banks?
<thom> lamont: just sent you two invites
<pitti> nice, now my online bank works as well
<pitti> I KNOW: it depends on the current time, obviously
<lamont> pitti: glad that mdz and I could help. :-(
<thom> pitti: you're cursed with heisenbugs recently :-)
<pitti> lamont: it was the aura of the people who would decide to hurt this bug
<lamont> "there are very few things about computers that cannot be explained if you are willing to grant them fear and malice."
<pitti> thom: can we quickly rewrite firefox in python?
<lamont> doesn't have to be quick.. Take until Fridy
* lamont received some interesting insight into someone's mindset when their summary of bittorrent was "I looked at that a while back, but it was just a bunch of python scripts"
<pitti> lamont: with this timeframe we can even add a doom and a tetris plugin :-)
<lamont> there's a tetris plugin for firefox??
<thom> pitti: as long as we can call it pyrefox
* T-Bone waves
<pitti> lamont: not yet :-)
<pitti> Hi T-Bone
<lamont> hi T-Bone
<T-Bone> hey dudes :)
<lamont> T-Bone: where was your gcc-3.4 source again?
<mdz> thom: regarding the powernowd module loading stuff, can we do anything smart about i386 systems which require a speedstep-* module?
<T-Bone> lamont: envy.esiee.fr/~varenet/newgcc iirc
<lamont> ok
<thom> mdz: sladen, mjg59 and i were playing with a script to guess, but it's pretty fragile
<thom> probably hoary material
<T-Bone> lamont: mind that it built fine on ia64
<mdz> Kamion: which kernel made it onto the 1006 daily CD?
<mdz> thom: agreed
<seb128> jdub: ping ?
<mdz> Kamion: never mind, .list tells me
<seb128> mdz: gstreamer/totem release today which improve totem-gstreamer a lot ... FC3 is going to include (they are in hard freeze too). Perhaps we want to do so ?
<seb128> since totem-gstreamer is the default player and works pretty bad, I think we should consider the update
<mdz> seb128: yes, I think so, but let's test it a bit before uploading
<mdz> a few different people
<seb128> ok, I'll prepare the packages and put them somewhere
<mdz> anyone have a printer to test #2114?
<mdz> it stinks of NOTWARTY, but I have no printer at the moment
<lamont> mdz: been printing things for a while, not sure where gs-esp fits into the sequence, though...
<lamont> mdz: btw, when you get bored, 2022 has an attached patch now.
<mdz> lamont: print a postscript file (e.g., from mozilla)
* lamont will try
<mdz> lamont: don't you need to clean up that diversion it used to create?
<mdz> (ewww on that, by the way)
<lamont> mdz: well, um, probably.
<lamont> I could just unconditionally remove it in postinst, with errors redirected... or is that uglier?
<lamont> mdz: wrt those ppds...  which package are you thinking should change? gimp-print? or cupsys?
<mdz> lamont: foomatic-filters-ppds
<mdz> the one with all the ppd files in it
<carlos> seb128: seems like latest gstreamer release improves video playback, will it enter into warty?
<mdz> carlos: scroll up a bit; we already discussed it :-)
<seb128> carlos: read what I said 20 lines up
<carlos> :-P
<carlos> sorry
<seb128> np :)
<seb128> one more voluntary to test the new packages I guess ? :)
<carlos> seb128: send me the URL of the packages and I will test them
<carlos> yes
<lamont> mdz: updated the bug
<pitti> mdz: I will try it; i already produced some postscript printouts which look good
<carlos> mdz, jdub: I forgot to ask about gstreamer-ffmpeg plugin inclusion into universe, is that possible?, I suppose that it cannot be in main because patent problems, right?
<seb128> carlos: ok, they are not ready yet but I'll
<pitti> seb128: if I ever find a video which totem-gstreamer is actually able to play, I would test this as well
<seb128> pitti: ok :)
<seb128> -ffmpeg would help a lot ..
<pitti> seb128: oh, ffmpeg plugin sounds like MPEG4 and stuff?
<seb128> yes
<pitti> seb128: so xvid, divx? 
<pitti> great
<seb128> yes
<carlos> pitti: but it's not in warty or Debian
<mdz> pitti: thanks, please NOTWARTY it if appropriate
<carlos> only external sources
<pitti> mdz: I can only try some BTS pages, the bug does not give other examples
<mdz> pitti, thom: a friend of mine just pointed out that the firefox crash only seems to happen with multiple tabs open
<mdz> pitti, thom: I had been testing with a single tab, but when I opened more than one, I got it to crash on the first try
<pitti> mdz: that could be it, I will try
<pitti> mdz: that would be a more sane explanation than the square root of daytime etc.
<thom> i can get it with a single tab, tho
<pitti> thom, mdz: single tab crashes for me, too
<pitti> thom, mdz: maybe "if you ever had a second tab.." and so on?
* lamont was testing in tab #3 or 4 of one of 2 windows
<pitti> mdz: printing BTS pages works perfectly on my Samsung ML-1410 laser
<pitti> mdz: but before closing the bug, maybe some more people should test?
<mdz> pitti: if gs-esp works with the default setup, fonts, etc. it is at least not RC
<pitti> mdz: could be a specific driver problem then
<pitti> mdz: I downgrade, comment and leave it open for now, then (plus NEEDINFO or so)
<mdz> pitti: I suppose it's possible
<lamont> mdz: fwiw, gimp-print Suggests: cupsys-driver-gimpprint, which Depends: cupsys-driver-gimpprint-data, which appears to provide the driver for the S200.
<lamont> OTOH, those last two binaries are in universe.
<mdz> I don't know much about gimpprint
<mdz> but cupsys uses the ppds in foomatic-filters-ppd directly
<mdz> if it can use the gimpprint ones, too (and they don't conflict), we could look at that
<lamont> or rather, foomatic-filters-ppd (and cupsys, and cupsys-driver-gimpprint-data, and ...) all deliver files into /usr/share/cups/model, where cups can find them...
<mdz> but I think it's best to have all of the ppds in one place
<lamont> cupsys, hp-ppd, foomatic-filters-ppds, gs-esp, cups-pdf, cupsys-driver-gimpprint-data all deliver there.
<lamont> (== too late for that.)
* ..[topic/#ubuntu-devel:pitti] : Ubuntu development -- general discussion on #ubuntu | 14 RC bugs to go
<mdz> hmm, I can't get firefox to crash again
<mdz> even with multiple tabs
<pitti> mdz: as we guessed: a heisenbug
<mdz> pitti: the procedure my friend just posted to the bug works for me
<pitti> mdz: luckily it still crashes in a debugging version (which is a 100 MB deb :-) )
<pitti> mdz: it's annoying, but I'm not sure whether to raise it to RC
<mdz> pitti: try the procedure in the most recent comment
<pitti> mdz: phone, will try later
* T-Gone bbi2h
<lamont> mdz: cupsys-driver-gimpprint comes from gimp-print source, which makes me believe that they added all of the support when they added the part that the submitter says is there...
<lamont> mdz: and reading the internal documentation in gimp-print makes me believe that even more.
<mdz> lamont: so you're saying that we need gimp-print in the default install just to have a complete set of drivers?
<lamont> well, I think we need to move cupsys-driver-gimpprint to at least supported.seed
<lamont> and if we're installing cupsys and gimp-print in desktop, then we should also install that suggested package...
<lamont> s/suggested/(suggested)
<lamont> moving it would just leave escputil in universe (epson stylus printer clean/alignment util)
<lamont> 2.7MB of .debs
<mdz> we're installing cupsys
<seb128_> mdz: ok to sync gdk-pixbuf from debian ?
<mdz> I don't think we're installing gimp-print
<mdz> seb128_: I think so; double-check the changelog
<seb128_> mdz: I've double checked, the only change between warty and debian (out of the security patch which is different) is "Link gnomecanvaspixbuf.so.1.0.0 against gdk_pixbuf.la"
<seb128_> ok, I'm fixing gdk-pixbuf now :)
<npmccallum> mdz: what was the result of your testing madwifi?
<npmccallum> mdz: its still not working at all with the latest kernels for me
* lamont goes to see what his wife wanted.
<npmccallum> pitti: ping
<pitti> npmccallum: pong
<npmccallum> pitti: did you get my email?
<pitti> npmccallum: no personal one
<pitti> npmccallum: somewhere on the list?
<pitti> npmccallum: anyway, I'm going to sleep now. If you sent a mail to @debian.org, please use the direct way with martin@piware.de. @debian.org email sometimes lags for as much as 4 weeks (see lengthy thread on d-devel)
<pitti> good night everybody!
<nasdaq4088> bye pitti
* lamont really runs off - back in a few hours.
<mdz> npmccallum: it works fine for me
<mdz> npmccallum: WEP and all
<thom> mdz: so what do you think about sudo's prompts. leave till hoary?
<npmccallum> mdz: It was working perfect for me as well, however, since a recent kernel upgrade I can't get dhcp at all
<mdz> npmccallum: works for me with what I believe is 2.6.8.1-11
<mdz> I've upgraded since the last time I rebooted, so it's using the new module at least
<Kamion> fabbione: fontconfig's dependencies look a bit barmy
<Kamion> Package: fontconfig
<Kamion> Depends: libc6 (>= 2.3.2.ds1-4), libfontconfig1 (>= 2.2.1), debconf (>= 0.5) | debconf-2.0, defoma (>= 0.7.0), ucf (>= 0.29), ttf-bitstream-vera | ttf-freefont | gsfonts-x11 | msttcorefonts | laptop-detect
<Kamion> what's that | doing before laptop-detect?
<sivang> ah! at last I fixed that dpkg problems.
<sivang> hope my system doesn't break again..
#ubuntu-devel 2005-10-17
<HiddenWolf> yup
<HiddenWolf> http://paste.ubuntulinux.nl/3001
<HiddenWolf> why? strings got dumped?
<zyga> HiddenWolf: 21 updated, 0 new -> needs extra 61,4KB
<zyga> strange
<HiddenWolf> see the paste
<zyga> hmm
<zyga> this is the final update before the release
<Kamion> HiddenWolf: a lot of unnecessary images were removed from ubuntu-docs
<HiddenWolf> Kamion, _images_
<HiddenWolf> 26mb of images?
<Kamion> HiddenWolf: yes. the difference comes to about 30MB
<Kamion> according to Installed-Size:
<HiddenWolf> Kamion, *unk*
<Kamion> was very useful for live CD space freeage
<HiddenWolf> Kamion, what kind of images are we talking?
<Kamion> HiddenWolf: lots of .png files that weren't referenced by the documentation (according to jbailey)
<Kamion> screenshots, by the look of it
<HiddenWolf> Kamion, oops
<Kamion> -rw-r--r-- root/root   1311123 2005-08-31 17:00:08 ./usr/share/ubuntu-docs/gnome/images/C/stones.png
<Kamion> -rw-r--r-- root/root    546775 2005-08-31 17:00:08 ./usr/share/ubuntu-docs/gnome/images/C/ubuntubugzilla.png
<Kamion> -rw-r--r-- root/root    461365 2005-08-31 17:00:08 ./usr/share/ubuntu-docs/gnome/images/C/evolution-calendar.png
<Kamion> -rw-r--r-- root/root    768240 2005-08-31 17:00:08 ./usr/share/ubuntu-docs/gnome/images/C/aisleriot.png
<Kamion> that sort of thing
<HiddenWolf> Glad to be rid of it _before_ release
<Kamion> they were in the docteam svn, possibly for web-published docs - dunno exactly
<HiddenWolf> that's a couple of gigs bandwith saved. :)
<HiddenWolf> mdz, Kamion be nice, post a abc to -devel-list tellling me how I can rsync an ubuntu-daily to final when it's out, then seed it, please.
<mdz> Kamion: ready to approve d-i?
<Kamion> mdz: I'll push a cron.daily first to make sure sparc has this kbd-chooser upload
<Kamion> but otherwise, yes
<Kamion> will do it in a few minutes
<Kamion> hppa is out of time for kbd-chooser and can live with the old version; the udeb is the same anyway
<Riddell> what is the OEM install mode?
<Kamion> Riddell: https://wiki.ubuntu.com/OEMInstaller
<mdz> Kamion: there is some serious crack in ubuntu-docs
<mdz> it is going to need attention post-release
<ogra> Kamion, mdz, i suppose a edubuntu-meta upload for the python-opengl chane is ok ? 
<ogra> *change
<mdz> one of the "frequently asked questions" about installing packages is "How to backup/restore downloaded repositories cache?"
<ogra> lol
<mdz> ogra: only if your CD is overflowing
<ogra> mdz, its a ripoff from ubuntuguide.org ...
<mdz> the section on installing packages talks about apt-get and synaptic but not gnome-app-install
<ogra> mdz, mine arent :) edubuntu is fine, i just wanted to syncronize
<mdz> ogra: what's this about a 10-minute gimp job as the default edubuntu background?
<ogra> mdz, the former background was a placeholder, people seemed to like it
<ogra> but there was complaint in #edubuntu that it wasnt coulorful enough, the current one is http://art.ubuntu.com/backgrounds/edubuntu/13
<wasabi> There a better way to make a chroot Ubuntu install than debootstrap? Perhaps some post-debootstrap thing to run to do the basic configuration
<wasabi> /etc/modules, oem-config, etc?
<wasabi> guess my only idea is to install oem-style into a vmware and copy that to a chroot. =/
<zyga> ogra: is there any *.ubuntu.com map?
<ogra> zyga, ??
<zyga> ogra: I've just learned about art.ubuntu.com
<ogra> ah
<Kamion> wasabi: no, http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/apcs04.html is the standard approach, involving debootstrap
<ogra> zyga, feel free to investigate and make one on the wiki ;)
<Kamion> wasabi: oem-config has quite a narrow range of uses at present, although they may be expanded in the future
<wasabi> yeah
<wasabi> I just want some friendly "please enter your hostname" on boot.
<Kamion> elmo: please sync putty from Debian (fixes build failure with gcc 4.0)
<Kamion> elmo: thanks
<Riddell> Kamion: kubuntu live CDs still in progress?
<Kamion> Riddell: yes
<Riddell> Kamion: quite a difference in dsize there.  do you think we'll revert to the i386 winfoss or should I adjust for this new size?
<mdz> Riddell: er, you intend this kdebase for 5.10?
<doko> mdz: please could you answer to the zope/plone sync email from Monday?
<mdz> doko: at first glance it was a whole bunch of new upstream versions that I could not hope to review, and we could not hope to QA, in 24 hours
<Riddell> mdz: yes please
<mdz> Riddell: you realize this means all new livefs builds as well?
<Riddell> mdz: yeah, but I think we'll get as lot of complaints if it doesn't use anti-aliases fonts
<mdz> Riddell: at this point we are only stopping for real showstoppers
<Riddell> I consider it one
<mdz> Riddell: if it's safe and important, it can be considered for breezy-updates after the release
<Kamion> Riddell: I don't think there's room to switch back; you'd need an extra >10MB
<Kamion> Riddell: let's just leave it as it is
<Riddell> Kamion: ok
<mdz> Riddell: is it a regression? when did it regress? there isn't even a bug open about it
<mdz> Riddell: is this fallout from 3.4.3?
<doko> mdz: these were subminor versions, partly needed for plone-2.1. I can go over them again, but please approve the other ones
<Riddell> mdz: yes, it was a typo in converting the patch for 3.4.3
<mdz> doko: you didn't provide justification for any of these
<goonie> I'm sorry to post a user problem, but could someone help me repairing my Grub installation, please? (Error 17)
<Riddell> mdz: how frozen are we?  I still have to adjust the language packs for size on some of the CDs
<mdz> Riddell: we are VERY VERY FROZEN
<doko> mdz: you did agree to these on 09/14, if uploaded on 09/15. kobold did send the sync list on 09/16.
<Riddell> mdz: so we have to leave these CDs oversized?
<ogra> Riddell, will you adjust the size up or down ? up affects edubuntu
<ogra> ah, ok
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Yes, it is too late to fix that for 5.10.  Please test the current builds: https://wiki.ubuntu.com/BreezyTestPlan
<Riddell> ogra: how would it affect eubuntu?
<mdz> doko: if I approved them for 09/15, they needed to go in on 09/15
<ogra> Riddell, if you size it up, my CDs get bigger
<mdz> that was a month ago
<mdz> it's now the day before release
<Riddell> ogra: why?  it's only the kubuntu seeds
<ogra> Riddell, you said you'd change the language packs, you didnt talk about seeds :)
<Riddell> language packs in the seeds
<ogra> yes, got that now :)
<mdz> doko: if it's safe enough that you feel it could be uploaded the day before release, you can propose it for breezy-updates after release
<mdz> that is the level of freeze we are in right now
<mdz> Riddell: which of your CDs are oversized?
<Kamion> mdz: only the install CDs; quick ship changes would probably do the trick
<Kamion> oh, no, powerpc/live too
<doko> mdz: ok, will do
<Riddell> mdz: powerpc live and amd64 install
<Kamion> Riddell: amd64 install is easy to fix without archive changes
<Riddell> Kamion: what needs done?
<mdz> Kamion: did you work the same powerpc initrd magic for kubuntu that you did for ubuntu?
<Kamion> remove 'amd64' from language packs for less-popular languages in ship
<Kamion> (in the seed)
<Riddell> that was my plan
<Kamion> mdz: yes, that change was global
<mdz> Kamion: or perhaps the cloop needs to be reset?
<Kamion> mdz: powerpc doesn't need that - partimage works fine there
<mdz> oh, amd64/install and powerpc/live, not the other way around ;-)
<Kamion> yes
<Kamion> kubuntu/amd64/live has been reset
<mdz> and is still oversized? ick
<mdz> can we trim winfoss?
<Kamion> no, amd64/live is not oversized
<Kamion> only amd64/install
<Kamion> that one is easily dealt with by trimming language packs
<mdz> why is powerpc/live larger than amd64/live?
<mdz> isn't it the reverse for ubuntu?
<Kamion> language packs again
<mdz> argh
<Kamion> fixing that will require an archive change
<Kamion> sorry I didn't notice that earlier; I was busy fixing lots of other images ;-)
<mdz> it's Riddell's responsibility to monitor the kubuntu images
<mdz> and ogra's to monitor edubuntu
<mdz> an oversized kubuntu/powerpc is not necessarily a showstopper
<Kamion> indeed
<mdz> I don't think anyone plans to press aluminum ones
<mdz> let's go ahead with it unless we find something worse
<mdz> this new ubuntu breezy-live-amd64 is going to take ages to download
<mdz> I'm getting <200k/sec from cdimage
<Riddell> should I adjust ship for the oversized amd64 CD?
<Kamion> Riddell: yes
<Kamion> subtract Size: fields of .debs from the image size, starting from the bottom of the list, until you get to a bit less than 650MB (safety margin)
<Kamion> then remove all of those from amd64
<Riddell> ok
<dholbach> i'm off to bed, see you in a couple of hours
<mvo> good night dho
<mvo> good night dholbach 
<elmo> do I want to process this d-i?
<elmo> Kamion/mdz: ^--
<mdz> elmo: I thought Kamion had done it already...if not, maybe he has a reason for waiting
<mdz> Kamion: so this current CD build is not final anyway, then?
* Kamion release-notes #14485
<Kamion> elmo: yes, please do
<Kamion> sorry, forgot to handle it
<Kamion> mdz: the CD build that's happening right now is a cronned Edubuntu build
<mdz> Kamion: I mean the ubuntu build which is currently on cdimage
<Kamion> correct
<mdz> the one I'm downloading now, with the non-rsyncable amd64 livefs
<Kamion> we won't be seriously breaking rsyncability from now to release
<mvo> the current image (20051011.1) is not the final one? no sense in testing it now?
<Kamion> it is certainly worth testing
<elmo> done
<Kamion> mvo: don't bother testing OEM installations with that image, because a fair bit has changed there, but other than that there are few changes left
<Kamion> elmo: thanks
<Riddell> Kamion: done
<mvo> I'm doing a expert install, it asks me for a root pw. is that intended (I guess so)?
<Kamion> mvo: yes, and it's always been that way
<mvo> ok
<Kamion> elmo: I wouldn't object if you were to nuke breezy's daily-installer-*, either
<Kamion> there will be no more daily d-i builds there
<elmo> ok\
<elmo> what about the last two d-i uploads?  still want them?
<Kamion> and we may as well free that gigabyte of archive space
<Kamion> elmo: 17 can go, leave 18 for now
<Kamion> mdz: FYI, all cdimage cron jobs disabled from now to breezy release
<Kamion> I'll set off a sequence of builds after the currently-running build completes, and then go to bed
<karthik085> I tested today's image and it passed all desktop tests
<mdz> Kamion: ok, I'll get those down and see how they look
<mdz> karthik085: thank you
<karthik085> Where should 
<karthik085> I indicate the status?
<mdz> karthik085: I'll take care of it, thanks
<karthik085> Ok. Thanks. later
<Kamion> elmo: can you chase up the language-pack OODs in http://people.ubuntu.com/~cjwatson/testing/breezy_outdate.txt?
<Kamion> elmo: [urgent for CD builds] 
<Kamion> infinity: alternatively, if you're around ...
<mdz> probably not; he's been gone <7 hours I think
<elmo> en-mass given back
<elmo> the first one I looked at had, silly buildd vs. archive race crap, so I'm asuming that's the problem for all of them
<Kamion> elmo: thanks
<Kamion> elmo: yeah, that happened in the last l-p-* batch too
<mvo> Kamion: does 20051011.1 contains the latest german langpack? or will it be part of the next build?
<Kamion> mvo: the .list files should tell you
<Kamion> breezy-install-i386.list:/pool/main/l/language-pack-de/language-pack-de_20050930_all.deb
<Kamion> looks like not
<mvo> Kamion: ok, next build I guess? otherwise the expert install worked fine (just completed the desktop tests
<Kamion> mvo: next build, yes
<Kamion> mvo: thanks, that's good to know
<mvo> Kamion: should I add this result to the BreezyTestPlan wiki yet? or will we start with that tomorrow?
<Kamion> I think we should probably start with that once we really have candidate images
<elmo> I think most, if not all, will make this cron.daily
<elmo> Kamion: ^-- l-p
<Kamion> elmo: all, by the looks of it
<Kamion> thanks for that
<ogra> yeah, edubuntu isos look good :)
* mvo goes to bed now and continues testing in ~6-7h
<Kamion> cdimage@little:~$ for-project ubuntu cron.daily; for-project ubuntu cron.daily-live; for-project kubuntu cron.daily; for-project kubuntu cron.daily-live; for-project edubuntu cron.daily; for-project ubuntu-server cron.daily
<mdz> Kamion: thanks
<Kamion> mdz: all primary image builds queued up; I'm off to bed, feel free to kill those cdimage processes and restart if they run amok for some reason
<mdz> Kamion: I'll test those and kick off dvd builds after
<Kamion> perfect
<Kamion> mdz: btw, you have an ancient tail -f process running on little
* Kamion &
<wasabi> great. at some point my rear surround volume disappeared from g-v-c
<wasabi> oh cool something to add it. ;)
<elmo> (Kamion: did they fix your router then?)
<wasabi> haha and on 2.6.12-9 my monitor turns itself off randomlly with the ATI driver.
<wasabi> breezy is going to be fun. ;)
<ogra> wasabi, do you have gnome-screensaver installed from an old upgrade we switched to it for some days... the symptom sounds familiar
<wasabi> hmm might
<wasabi> yes, do.
<wasabi> oh cool this power management stuff i just noticed is niec
<wasabi> nice
<ogra> remove it ... or if you want to keep it, adjust the dpms setting in configuration editor... 
<wasabi> Just going to remove it. It never worked with my pam setup anyways.
<wasabi> Every time it came up I had to switch to VT1 and kill it... but I kept being too lazy to remove it.
<ogra> the first upstrem version had a dpms setting to switch the monitor off after 10 mins... :)
<wasabi> Well, it turns off WHile I'm Using It.
<wasabi> But comes back in about 4 seconds.
<ogra> yup, it was buggy
<wasabi> Oh heh
<ogra> should be solved in recent versions...
<wasabi> good to know that was the problem though
<ogra> mdz, the xscreensaver fix was already in the archive before d-i doesnt that mean it gets on the current CD ?
<mdz> ogra: version number?
<ogra> ubuntu17
<ogra> xscreensaver 4.21-4ubuntu17
<mdz> ogra: ARGH
<mdz> it is in the archive but not on the current livefs
<mdz> so we are out of sync again
<mdz> I thought Kamion was doing a new livefs build
<ogra> oh, the livefs wont be rebuild... damn.. 
<ogra> does it nee d-i ? 
<ogra> *need
<mdz> has nothing to do with d-i
<ogra> i thought the new builds were caused by it
<mdz> the livefs and d-i are completely independent
<ogra> yes
<mdz> well now we are forced to rebuild it and we lose a few more hours
<ogra> sorry, i didnt know that...
<mdz> not your fault, I wouldn't have approved the upload if I realized there wasn't a livefs build pending
<mdz> I should have left it for breezy-updates
<ogra> yes... :/ 
<wickedpuppy> could i report a bug here ? or should i send it to bugzilla ??
<ogra> wickedpuppy, bugzilla
<wickedpuppy> okie
<ogra> except it could block the release which must be a really really serious bug
<sistpoty> gn8 folks
<dhonn> whats with my computers the System > About Ubuntu  errors on all my systems!
<elmo> dhonn: update, it's fixed
<bddebian> Heya elmo 
<ajmitch> bddebian: got breezy reinstalled?
<bddebian> Just finished burning the CD
<wasabi> is there a possible way to install a package unconfigured?
<wasabi> with apt.
<ajmitch> wasabi: I guess you're wanting something similar to crosshurd, are you?
<wasabi> depends what that is. ;)
<ajmitch> sets up a chroot (a partition usually), and I think it leaves the configuring step until first boot
<ajmitch> I haven't used it in a long time though
<wasabi> Hmmm
<LaschW> Is there a BreezyTestPlan for OEM-Install?
<mdz> LaschW: I thought I saw Kamion add something to the wiki today
<mdz> ah, it's in the release notes
<mdz> LaschW: https://wiki.ubuntu.com/BreezyReleaseNotes
<jsgotangco> yes
<jsgotangco> mdz, can you review the notes before i ask jbailey to add it to the distro?
<mdz> jsgotangco: it's too late
<jsgotangco> oh ok..so its frozen
<mdz> yeah, I sent a release status update to -devel earlier
<mdz> we're in the very final freeze
<mdz> is there a link from the existing release notes to the wiki version so we can continue to update it?
<mdz> well, we can always continue to update it, but it would be nice to have a quick link there for dapper if we don't already
<jsgotangco> we don't have anything in the distro
<mdz> for dapper maybe it should just be a link
<mdz> since the release notes tend to get edited very close to (and after) the release
<mdz> especially errata
<mdz> one of the things we use the release notes for is to document issues that are discovered too late to be fixed
<mdz> which by definition means it's too late to update the release notes as well ;-)
<jsgotangco> yeah but that would mean a user should be online just to read the notes
<mdz> there isn't much we can do about that; changing the release notes in .deb form on the CD requires a complete livefs and CD rebuild which takes hours
<mdz> and then another test cycle
<mdz> if we are to put a version on the CD, it'll only contain what we have ~7 days before release
<mdz> or at least 2-3
<jsgotangco> ok sounds good then next time we should just use a permalink i guess
<mdz> we could include older release notes and have a link "go here for the latest release notes online"
<mdz> we had a fairly reasonable start on the release notes as of RC; why didn't those get incorporated into the package?
<jsgotangco> well it was my fault really, i didn't fix it up in time along with the omf so it wasn't uploaded along
<mdz> I'll add it to the release checklist for next time
<jsgotangco> the last upload of jbailey had fixed a lot of the translations or so...
<elmo> OK, *.ubuntu.com, launchpad.net, etc. is going down for some emergency network maintenance - ETD is 10 minutes or so
<calc> hmm releases.ubuntulinux.org appears to be down
<segfault> yeap, we know
<calc> ok
<jsgotangco> being fixed by elmo
<bslima> GnuKemist, hi
<GnuKemist> sup dude?
<GnuKemist> bslima, sup dude?
<bslima> still down ?
<GnuKemist> bslima, believe so
<bslima> =/
<wasabi> yay
<wasabi> up
<Trashcan> yay :D
<jsgotangco> crack fiends! :P
<xhaker> why did planet went back a week or so?
<xhaker> or should i say.. why did Stephen Herman get ontop like that.. 
<jsgotangco> hmmm
<LaschW> mdz: Thanks, I'll have a look...
<wasabi> Ya know, a new type of dependency: Configure-Depends, would be nice. Packages required to configure the package, but not to use it.
<wasabi> So I can install all this crap, but ditch perl because I have no need for it to USE the crap heh
<mdz> wasabi: then when the time came to upgrade the package, you'd need to reinstall all that stuff anyway
<wasabi> yup
<wasabi> but neverthe less, it would make building this embedded system easier.
<fabbione> morning
<sivang> good morning fabbione 
<fabbione> mdz: how do we look?
<ajmitch> hi fabbione 
<sivang> mdz: just took a look at BreezyTest plan, shouldn't we add something to test printing as well, "if appropriate hardware available" ?
<mdz> fabbione: slow
<mdz> fabbione: install is up, live is mirroring
<Lathiat> whats this for?
<fabbione> mdz: ok. i am rsyncing now
<Lathiat> test isos for release?
<mdz> yes, a first cut
<Lathiat> ok
<fabbione> mdz: go and get some rest, we will start the test plan asap. If there is any big issue i will drop a phone call
<mdz> sivang: it's meant to be a very fast test. I have to do it 12 times for every test cycle
<sivang> mdz: ah I see, understood.
<mdz> fabbione: it is not even 2200 yet here
<ajmitch> 20051012.1 is the image to grab?
<mdz> I am going to test this set, and if it is good, I will bugger off for a while
<fabbione> oh.. it's me a bit too early :)
<mdz> ajmitch: daily -> 20051012.1, daily-live -> 20051012.2
<ajmitch> ok
* ajmitch will finish getting 20051012, rsync, and test
<wasabi> my flash system boots to gdm + X now. ;)
<wasabi> usplash is busted for some reason though. hmm
<fabbione> jdub: ping?
<spstarr> erm, did we forget to include libavformat and libavcodec packages in breezy? i only see the -dev ones im trying to port xvidcap 1.1.4-pre2 to ubuntu
<spstarr> i know they come from ffmpeg
<fabbione> mdz: did you also rebuild dvds?
<mdz> fabbione: not yet, I will once kubuntu and edubuntu have CDs
<fabbione> mdz: ok
<mdz> amd64/live and powerpc/live OK here
<fabbione> mdz: still resyncing i386.. burning i386 install and rsyncing mirror for netinstall
<spstarr> it looks like we are missing it :(
<wasabi> naw, i think they're all in the ffmpeg package
<wasabi> for some reason
<wasabi> or somewhere
* spstarr installs ffmpeg
<fabbione> spstarr: they are not shared libs
<spstarr> should be?
<fabbione> you get the devel to link static
<fabbione> no, if the ABI is not stable
<spstarr> hmm, so i need to build it as part of xvidcap..hmm 
<spstarr> _ugly_
<spstarr> that explains the failure in finding the .so
<spstarr> /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libavcodec.a(h263.o): In function `ff_mpeg4_encode_video_packet_header':
<spstarr> : undefined reference to `ff_log2_tab
<spstarr> then why do we include the -dev is the lib ABI is changing?
<fabbione> spstarr: -> #ubuntu
<fabbione> we are in the middle of a release
<fabbione> there is no time to look at this stuff
<fabbione> not right now
<spstarr> hmm, i'll make do with what i have i'd like to get this into next ubuntu
<spstarr> xvidcap is rather useful
<mdz> my powerpc test box is so b0rked
<mdz> it has become progressively slower during the time I've had it
<fabbione> mdz: my powerpc is so not here yet :/
<ajmitch> ah, rsync at ~4K/sec is painful
<mdz> it's now at a point where the desktop is becoming unusable on the live CD
* fabbione complains to apple
<mdz> it takes about 3x as long to boot to the point of accessing the CD
<fabbione> mdz: how old is that?
<fabbione> perhaps a good cleaning and new CDrom would do
<mdz> fabbione: about a year I guess
<mdz> a bit before warty
<tritium> I can't get breezy to get along with my iMac G5
<mdz> tritium: did you use the 64-bit kernel?
<tritium> mdz, yes
<tritium> I haven't tried the dailys from the 12th yet
<tritium> mdz, has it been successfully tested on a newer iMac, as far as you know?
<sivang> mdz: that's weird. The hardware just deteriorates to slowness ? :)
<fabbione> tritium: what kind of iMac is that?
<tritium> fabbione, a recent 20" iMac G5
<fabbione> tritium: i know there are some limitations in the kernel with the most recent G5's
<fabbione> tritium: support is still on the way into the kernel
<tritium> fabbione, thanks, that's not too surprising.
<fabbione> tritium: you will have to wait for dapper kernels
<fabbione> kernel's even
<tritium> not a problem.  I'll be glad to try them
<pitti> Good morning
<fabbione> hey pitti
* pitti cranks up jigdo and rsync
* \sh reads heise, phpmyadmin is vulnerable, and my head is paining, what a wonderful day
<elmo> fabbione/pitti: I'm about to kill your rsync sessions I'm afraid
<fabbione> elmo: meh...
<fabbione> is it urgent?
<mdz> fabbione: yes
<elmo> fabbione: no, I'm just doing it out of spite
<fabbione> ok
<elmo> so, once more with feeling
<pitti> ok
<fabbione> elmo: go ahead.. i did stop them
<pitti> ah, shit
* pitti beats rsync to deathh
<pitti> Ctrl-C'ing it removed the original file
<elmo> ok, *.ubuntu.com, launchpad.net going down again for emergency network maintenance. ETD is 10 mins.  Really this time.
<mdz> yes, rsync sucks in this situation
* pitti dd's back
<mdz> pitti: you were using --partial I assume
<fabbione> bah great.. one cdrom is dead..
<mdz> --partial loses if you just started on the file, the default loses if you are near the end
<mdz> fabbione: drive or disc?
<fabbione> drive
<pitti> mdz: yes, I use -P
<fabbione> mdz: no bigge.. machine promoted as candidate for net install :)
* infinity waits for the machines to come back to join the testing fray.
<pitti> nice to see the powerpc and amd64 CDs fit well now
<pitti> 33 MB free space on i386, what a waste...
<elmo> we back, happy?
<infinity> Max connections 15 already.  Dang, you guys are quick.
<fabbione> infinity: nah... just kick it again
<infinity> Yeah, I did.  All good now.
<dhonn> hey i noticed in suse10 that metacity renders windows proportional to the menu bar.  how do i do that in ubuntu
<infinity> mdz : Oh, if you're curious, ath-in-di broke due to a udpkg bug, which Mithrandir has now fixed in upstream svn, so we're good to go for getting it into early dapper.
<infinity> mdz : Shame we didn't try this a week earlier, other than the one bug, it seems fine. :)
<mdz> i386, amd64, powerpc live OK
<sivang> infinity: will be finally able to join the ath testing, will be getting my X300 powered T43 soon :)
<mdz> amd64 install OK, powerpc,i386 installs in progress
<infinity> sivang : You got one with an ath, not an ipw2200?
<infinity> sivang : I specifically ordered mine with "intel wireless" (ipw2200) rather than "IBM wireless" (ath) to avoid the hassle.
<\sh> infinity: what to test?
<infinity> \sh : Hrm?
<\sh> infinity: I just read ath-in-di...just curious if I can test installation via wifi
<fabbione> mdz: winfoss on i386 looks good
<sivang> infinity: ah bah, I didn't get it, that's what the dealer said he can give - I will talk to him shortly then, ath0 support is poor?
<mdz> fabbione: oh, good. please add a column for that to the test plan page
<mdz> er, rows
<mdz> er, row
<mdz> I feel a migraine coming on
<fabbione> mdz: do we have winfoss on DVD too i assume
<mdz> fabbione: yes
<\sh> mdz: send it to me and I'll stay home today :(
<infinity> sivang : It's not poor, per se, but it involes a binary-only blob, and can be a bit sketchy at times.
<infinity> \sh : No, cause we didn't get it in in time (due to the one aforementioned bug... Updating udpkg on the day of release would be very dumb)
<infinity> \sh : Talk to me after the release, and maybe I can build some test images for ath users.
<fabbione> mdz: i386 liveCD is good
<mdz> CDs all good here except powerpc install which is STILL going
<infinity> CD drive buggered?
<\sh> infinity: well..we have to try to overcome the madwifi wpa-psk dhcp bug...cause sitting here now with a ndiswrapper enabled card, all the nice wpa-supplicant stuff and dhcp is working out of the box
<fabbione> mdz: i386 install is good too
<fabbione> (CD)
<fabbione> waiting the mirror to rsync for netinstall
<\sh> and now it's time to hit the bathroom and to have a look to myself...and I'm really afraid of it :(
<\sh> later guys
<fabbione> mdz: do you prefer the reports via email or are you tracking them via IRC?
<mdz> fabbione: tracking them in the wiki, see my latest edits to BreezyTestPlan
<fabbione> mdz: ok
<mdz> ok, 6/6 in my first test pass
<mdz> now I can sleep for a bit
<fabbione> mdz: i will add your i386 install to the wiki
<fabbione> good night
<mdz> fabbione: my i386 install was custom partitioning
<mdz> I didn't have a row for that yet
<fabbione> oh ok
<mdz> you can add one if you want and add my test there
<fabbione> sure
<mdz> but erase disk still needs to be tested
<fabbione> i did test it
* ajmitch digs a laptop out from the clutter for testing
<pitti> mdz: to speed it up, would it be sufficient to do "erase disk" and/or "autopartitioning" and stop the installation after checking what it did?
<fabbione> pitti: you still want to install all of it
<fabbione> specially in custom mode :)
<fabbione> if you make a 10MB /var is unlikely to work :)
<pitti> fabbione: yes, I thought about erase all, then break, then automatic, then break, then custom and install completely
<fabbione> ah yeah
<fabbione> that makes sense
<fabbione> my god.. all these langpacks are slowing down my mirror to death
<infinity> elmo : Are we still letting universe builds trickle in?
<mdz> pitti: I suppose so, yes
<daniels> mdz: so I assume that #15372 will not be resolved for breezy?
<pitti> mdz: I'd just check if the automatically created partitions are big enough
<mdz> daniels: that is unfortunately correct
<daniels> wa-hey.
<mdz> daniels: though if the fix is simple and safe we can consider it for -updates
<jsgotangco> should we add that as a known issue?
<daniels> well, aside from that, I have no major bugs that aren't in NEEDINFO or UPSTREAM.
<ajmitch> infinity: I hope so
<mdz> (which it would have needed to be tobe uploaded the day before release anyway)
<daniels> jsgotangco: i have three of them.  can I edit this as a wiki page or something?
<jsgotangco> daniels, feel free to do so i'll just clean it up later
<mdz> daniels: how is your bandwidth these days?  mini test plan in /topic
<daniels> mdz: it's not simple, but I feel it's safe
<daniels> mdz: and yes, I'm working on getting CDs for testing
<daniels> jsgotangco: URL?
<jsgotangco> daniels, https://wiki.ubuntu.com/BreezyReleaseNotes
<daniels> mdz: half of it's from me, and half from the other guy on the planet who still does stuff with XKB
<mdz> daniels: it should be just as worthwhile in -updates; the bug doesn't screw the install
<daniels> fair enough
<mdz> so we can even take a few days and get confident in it
<elmo> infinity: no ones' told me not to
<infinity> elmo : Cool, can I get a P-a-s sync, then?
<mdz> Riddell: kubuntu install+live CDs are up
<mdz> ogra: edubuntu CDs are building
<infinity> Dear god, we're only up to "g" on the langpack mirror.
* infinity runs to get a drink.
<elmo> infinity: done
<mdz> I'm going to try to escape this migraine by going to sleep.  please cover the test cases in the plan, with a fair variety of languages, while I'm away
<mdz> if any showstopper is found, or something which needs a decision as to whether it is a showstopper, call my mobile
<mdz> night all
<jsgotangco> night mdz
<fabbione> mdz: night
<pitti> night mdz
<pitti> Hi dho
<pitti> Hi dholbach 
<dholbach> good morning
<dholbach> good night mdz
<ajmitch> hi dholbach 
<zyga> morning
<pitti> Hi zyga 
<zyga> hello pitti :)
<zyga> first day when I don't have to work all day :)
<pitti> elmo: can you please sync xloadimage 4.1-14.3 and xli 1.17.0-18sarge1 (both from sarge-security)?
<pitti> elmo: both universe, and both only security updates
<dholbach> pitti: he went to bed
<pitti> ah, I see
<maswan> mdz/whoever: can I get an irc ping when the pool is updated on se.releases? I need to get copies to the offload hosts too.
<pitti> argh, why aren't there jigdo images for DVDs?
<infinity> Because they take forever and a day to generate.
<pitti> Kamion: is it possible to generate jigdo files for the latest dvd to allow us less bandwith equipped folks to test them? By scanning the live CD, install CD, and /var/cache/apt/archives, the required download amounnt would become bearable
<jsgotangco> a jigdo dvd would take prolly a day to build
<pitti> so what
<pitti> it would take me a week to rsync for nothing
<pitti> for the final images one day seems worth the effort
<jsgotangco> you have a point there
<pitti> it takes 8 minutes for a CD, it shouldn't be a whole day for the five-fold amount
<Burgundavia> whiprush, relicensing http://www.flickr.com/photos/whiprush/33275644/ under GFDL or CC-by-sa 2.0 for the doc teams' quicktour
<dholbach> Burgundavia: we just had a brief conversation over cc-by-sa 2.0 - debian-legal doesnt consider it free enough, but i dunno about 2.5
<jsgotangco> Burgundavia, its probably not his image even...
<Burgundavia> dholbach, regardless, that is what the doc team stuff is currently under
<Burgundavia> jsgotangco, if it isn't, then we start again
<Burgundavia> dholbach, as for not being dfsg-free, it is an issue, but not a current huge one (we can't do anything this late anyway)
<dholbach> it was merely a heads-up
<jsgotangco> chill
<Burgundavia> dholbach, When we decided back in Mataro it came up. We realized we were totally squeezed and it sucks
<Mirv> pitti: thanks for the new language packs, with the expection of serpentine (the translation of which was in the "main" rosetta template until yesterday noon when I uploaded it also to the breezy's serpentine-template), everything seems now translated
<dholbach> morning seb128 
<pitti> Mirv: nice
<seb128> hey dholbach
<pitti> Mirv: the missing bits will come in the first round of updates
<zyga> pitti: do you sync that .tar.gz from carlos manually? today's archive is identical to yesterdays
<pitti> Hi sabdfl 
<pitti> Hi seb128 
<dholbach> sabdfl: morning mark
<pitti> zyga: yes, rosetta did not export a tarball today, and we don't currently need it
<zyga> ah, okay
<seb128> hi pitti sabdfl
<sabdfl> ogra: ping
<sabdfl> moin moin all
<fabbione> morning sabdfl 
<ajmitch> hi sabdfl 
<sabdfl> Kamion: can we delay edubuntu without affecting everything else?
<zakame> hi sabdfl 
<sabdfl> hi zakame
<siretart> can someone else than elmo remove obsolete binary packages from the archive?
<dholbach> morning siretart 
<siretart> hi dholbach!
<infinity> siretart : Others have the power to, but generally defer to elmo for removals, as they prefer not to break anything. :)
<siretart> infinity: I've sent him an email. The particular issue is the binary package 'mplayer-amd64', which is no longer built from source 'mplayer', confusing users
<siretart> so mplayer should really be removed. perhaps there are more cases, but can't check that..
<siretart> argl
<siretart> so the binary package mplayer-amd64 should be removed
<siretart> not mplayer as whole..
<infinity> Old binaries that are no longer built from source tend to be purged on a reasonably regular basis.
<siretart> okay. didn't know that
<siretart> just wanted help avoiding having this particular mplayer-amd64 package remove before breezy. a friend was confused by this
<pitti> ouch - I can't start the OO.o help on ppc/install - any confirmations?
<pitti> doko_: oo.o2-help-en-us is not installed on powerpc - any idea?
<jhank> i know... but i just want download the final.... so is there a time set when the new cd image is to be released?
<jhank> i'm sorry, that's the wrong channel guys :(
<atripathi> is it the place where suggestions could be given ?
<jsgotangco> suggestions? we're already testing the cds heh
<Skid> not sure if this is the place, tried the motu channel but its a lil quiet ;) - what does it take to become a mirror, and are there any estimates on usages?
<dholbach> Skid: mirrors@ubuntu.com is the right place afaik
<dholbach> might be mirror@ too... hmm
<Skid> dholbach: alright cheers, I'll cc both.. going to 'unoffically' mirro the breezy dvd/images tomorrow anyway and try to pass them around our peers etc to lighten the load a teeny bit :)
<atripathi> anyway i will put it here. I would like better GUI support to network connections. I am having adsl and need to type pon dsl-provider evertime to connect. I would like better dialing app which could also ping to the dhcp host to keep the connection alive.
<Skid> +r
<atripathi> though its not a big problem but i feel it is essentially required for the pppoe i am using over dsl
<atripathi> and yes....before migrating to Ubuntu i used fedora3 and it had better GUI support to it
<dholbach> Skid: cool
<atripathi> I guess it was worth suggesting here
<pitti_live> DARN - /me beats OO.o help to death
<seb128> ?
<atripathi> Hoary rocks.....hope breezy rocks even more. Likely to get the CDs pretty soon
<maswan> Skid: We're hoping for 2Gbit/s :)
<pitti_live> doko_, Kamion: on amd64-live, ooo2-help-en-us is installed, but pressing F1 just brings "Help system could not be started". on ppc/install, the package is not even installed, and same effect
<Skid> heh I've got a few 100Mb links unused
<pitti_live> doko_, Kamion: it works fine for me on ppc-live
<Skid> but it won't be on outbound gig, sorry :P
<Skid> that'd push me over our cdr
<Skid> s/me/us
<maswan> Skid: Well, if you are around for the peak demand, we might be in need of http redirect targets. I'm se.releases btw.
<maswan> Skid: But hopefully we won't get that much above 2Gbit demand
<Skid> what sort of usages do you see?
<Skid> I've got dual fe's bonded up ready atm..
<maswan> a couple of hundred Mbit/s, I think
<Skid> alrighty :)
<maswan> the entire mirror sees 300:ish Mbit/s daily average, 500Mbit/s peak, but that's more than just ubuntu
<Skid> http redirect targets = ?
<jsgotangco> the mighty hand of maswan at work...
<Skid> heh
<maswan> A bit over half of that seems to be ubuntu
<Skid> rest is what, repo's etc?
<maswan> Skid: During releases I try to find a few extra boxes with lots of ram and gigE that I can redirect the popular files to.
<maswan> http://www.acc.umu.se/technical/statistics/ftp/index.html.en
<maswan> we're also ftp.se.debian.org, ftp.gnome.org, ftp.mozilla.org, se.archive.u.c, and mirror some hobbyist movies
<Skid> ahhh see what oyu mean now :)
<Skid> if only uk transit was cheap :)
<Skid> suppose i could get some cheapo clognet crap in, but like that's nolonger a full table so :P
<maswan> the trick is to be on an NREN where they like usage :)
<jhank> is there a specific time set, when the ubuntu is to be released tomorrow?
<Skid> ah, uni netowkr
<infinity> jhank : When we're good and ready.
<jhank> is there a time set for that? *fg*
<jsgotangco> jhank, nope
<jhank> hehe okay :)
<dholbach> elmo: could you please sync pvm from sid?
<jsgotangco> hey silbs 
<fabbione> Kamion,mdz: install CDs still carry the "Release Candidate" thing around.. noticed on expert install
<fabbione> Kamion: oem install is ok, i found a few glitches tho.. 
<jsgotangco> fabbione, did you oem loop into the creation of the user?
<fabbione> Kamion: aborting the "test phase" brings you back to X.. i didn't see the message that the machine will be reconfigured at the next reboot (i might have just overlooked at it)
<fabbione> Kamion: at the next reboot.. when oem-config runs in X and select "other locations" i am not offered the option to select which one. So either i live in the ones that are presented there or i can't select ;)
<fabbione> jsgotangco: no
<fabbione> how did you get there?
<silbs> jsgotangco: good morning
<jsgotangco> i was testing yesterday's x86 build and somehow after the reboot, the creation of the first user looped
<fabbione> jsgotangco: try with the new images
<fabbione> jsgotangco: Kamion did fix a bunch of oem bugs right 12 hours ago
<fabbione> or so
<jsgotangco> right
<pitti_live> Hi again
<seb128> wb pitti_live
<pitti_live> seb128: do you get OO.o help breakage, too?
<seb128> pitti_live: on a new i386 install no
<seb128> pressing F1 from the writer works fine
<pitti_live> seb128: on which arch and install/live? can you add your results to the wiki?
<pitti_live> ah, ok
<seb128> <seb128> pitti_live: on a new i386 install no
<seb128> "i386 install"
<pitti_live> yep, sorry :-)
<seb128> and I'm going to, I just logged to the desktop like 1 min ago
<seb128> let me play with it before updating the wiki :)
<seb128> I've the wiki page open on my browser :)
<pitti_live> ok, I finished editing the page
* pitti_live goes over to the other two boxes
<pitti_live> ah, wait, I add i386/live
<seb128> WTF
<seb128> the language-selector has not boxes to the second column
<mvo> seb128: that usually means that your sources.list is either missing some deb entries or a apt-get update is missing
<ogra> sabdfl, pong (sorry was up late)
<sabdfl> ogra: artwork email
<ogra> yes, i just see it
<seb128> mvo: right, that's due to this crappy bug making that eth0 is not set on boot
<mvo> seb128: will be fixed very early in dapper 
<mvo> seb128: oh, no. I was confusing this with the ifconfig bug
<seb128> and running dhclient breaks lo which makes GNOME unhappy :)
<seb128> k, I've the boxes now
<mvo> seb128: that one is getting fixed very early :)
<Kamion> sabdfl: we can delay the Edubuntu release a bit, certainly, but changing the archive for Edubuntu now is very awkward and risky
<sabdfl> ok, then let's go ahead
<Kamion> fabbione: release candidate> thanks, will fix that
<Kamion> fabbione: oem> yeah, I know the UI is pretty glitchy - if you could file bugs about those things, I'd appreciate it
<Kamion> I'm not going to sort them out now, but we can polish it up for dapper
<sabdfl> which UI is that Kamion?
<Kamion> sabdfl: OEMInstaller
<Kamion> pitti_live: it's really hard to generate jigdos after the image has been built at the moment
<ogra> Kamion, could you just wipe the current edubuntu-artwork ? the only diff for the last upload was the wallpaper, su that would revert it
<Kamion> pitti_live: I might do a run with jigdo turned on, but can't guarantee it
<ogra> s/su/so
<Kamion> ogra: er, no, I can't "just wipe" anything
<Kamion> what's the problem?
<ogra> Some people, sabdfl included dont like the wallpaper 
<fabbione> Kamion: sure.. i will do in a minute.. i need to get some food first :)
<ogra> my last upload changed exactly this... so if we culd revert the package one revision, it wold at leas be the former one
<Kamion> meh, ReleaseChecklist says that artwork is to be sorted a week before release for a reason
<pitti_live> mvo: ok, so language-support-en was installed for you on i386/oem?
<Kamion> so, Edubuntu doesn't have a live CD, and edubuntu-artwork isn't on any other CD image
<Kamion> which gives us a slim window
<ogra> Kamion, yup
<pitti_live> Kamion: I have severe troubles with OO.o help on various configurations (ppc, amd64), can you confirm?
<Kamion> pitti_live: not yet, I was up late last night and have just got up
<pitti_live> ok, nm
<infinity> pitti_live : I'm about to do amd64 tests.
<pitti_live> I'm running amd64/oem ATM
<pitti_live> and will do ppc/expert now
<ivoks> hi all
<mvo> pitti_live: I haven't tested i386/oem yet
<Kamion> ogra: make a new edubuntu-artwork upload with wallpaper the way sabdfl wants it
<ogra> Kamion, ok
<Kamion> and do it quickly
<pitti_live> mvo, ah, misread, that was expert
<Kamion> (but not without testing ...)
<ivoks> i know this is not the place, but i'm at client, and don't have time for bugzilla
<ivoks> but we have major loss of functionaly with samba and tiger OSX
<ogra> sabdfl, any opinion ? any wallpaper you like best ?
<doko_> pitti_live: why is oo help not on the powerpc cd? oo2-core _depends_ on it ...
<Kamion> ogra: we have one chance to get this right
<Kamion> doko_: it *is* on the powerpc CD. You could have found this out yourself by looking in the .list files
<ogra> Kamion, ok... i would have stayed with the former one... but several people spoke up it was to boring for kids... no idea what to take now
<pitti_live> doko_: the thing is, on ppc/install, l-support-en is *installed* but ooo2-help-en-us is not; it is in the apt cache, though
<pitti_live> on ppc/oem, language-suppor-en is not even installed, and neither is ooo2-help-en-us
<Kamion> pitti_live: check /var/log/base-config-pkgsel.log
<infinity> Kamion : The images are still labelled "Release Candidate"... I assume that means there's one more CD build required?
<Kamion> infinity: yeah, fabbione told me that earlier
<infinity> ivoks : Known issue, a bug has been filed, but without someone isolating the patch to fix it, I can't do much about it, sorry.
<Kamion> dists/breezy/Release needs to be changed too
<ivoks> infinity: it's fixed in .20
<infinity> ivoks : You can always blame Apple for being the only vendor in the world that doesn't fall back to a working auth method when their shiny-new-auth-method fails, though.
<ivoks> infinity: i do blame Apple :/
<infinity> ivoks : Yes, and .20 is a HUGE upgrade.  We're not putting it in.
<ivoks> infinity: i'll try to isolate patch
<infinity> ivoks : So, again, without someone isolating a small and sane patch, no fix until dapper.
<infinity> ivoks : If you can isolate a patch that's sane, I'll argue to get it into breezy-updates post-release.
<ivoks> infinity: i didn't mean to import .20, just that patch...
<ivoks> infinity: ok
<sabdfl> technically, dapper in *Tuesday* for the brave :-)
<pitti_live> Kamion: I'm in ppc/oem installation now. the log has no trace of language-support-en
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti_live> Hi jdub 
<pitti_live> Kamion: neither of ooo help
<\sh> jdub: please...not so loud...my brain is paining a lot
<sabdfl> Kamion, ogra: edubuntu artwork can go as-is
<sabdfl> jdub is clearly in release mode this morning ;-)
<Kamion> pitti_live: please investigate starting with the code in /usr/lib/base-config/menu/pkgsel; it will be a while before I can investigate myself
<Kamion> sabdfl: ok
<ogra> sabdfl, ok :)
<ivoks> infinity: i'll contact you when i have a success... see you
<infinity> ivoks : there's an open bug about it in bugzilla, you can follow up to that and attach the patch.
<ajmitch> morning jdub 
<ivoks> infinity: ok
<infinity> ivoks : http://bugzilla.ubuntu.com/show_bug.cgi?id=17509
<ivoks> infinity: thanks
<infinity> ivoks : I narrowed it down to about a month worth of Jeremy fiddling with rewriting, like, half ot thr RPC code.  Which is unacceptable.  If you can fix it in a tiny and obvious patch, cool.
<ivoks> infinity: can you provide url with patches (or they are in svn?) since i would like to test them
<ivoks> infinity: uh... sounds bad :/
<infinity> We may just suffer with being incomatible with Tiger until dapper.  We're not alone in that boat.
<ivoks> infinity: yeah, i know...
<infinity> Just about everyone out there right now is incompatible with Tiger, and IMO, the onus is on Apple to release an update that works with older SMB implementations.
<ivoks> infinity: trouble is that my buissness depends on osx compatibility :)
<ivoks> infinity: so i'll work on fix and contact you about that
<ivoks> bye all
<jdub> sabdfl: BOS->LON arriving at 6am mode, methinks ;)
<hno73> Of those who are testing images with the very latest artwork, could you grab 4-5 screenshots and send them to me? I'll want to update this page today http://www.ubuntu.com/screenshots (henrik@ubuntu.com) Thanks
<pitti> doko_: ping
<Kamion> pitti: incidentally, if you didn't know already, you can also rsync one of our DVDs more quickly by starting from the concatenation of the install and live CDs ...
<pitti> Kamion: ok, right
<pitti> doko_: on both amd64/live and install-oem, ooo-help-en-us is installed, but help does not work; how can I debug this?
<Kamion> if you were only going to be jigdoing from basically the contents of the install and live CDs anyway, it should be about the same
<Kamion> 10:38 < Kamion> pitti_live: please investigate starting with the code in /usr/lib/base-config/menu/pkgsel; it will be a while before I can investigate myself
<Kamion> pitti: ^--
<Kamion> for the case where it isn't installed, in case you didn't see that
* Kamion goes for breakfast while CD images rsync
<doko_> pitti: looking at it, I usually use strace, but that doesn't seem to work with 32bit bianries
<pitti> doko_: on my previously installed system help works fine, but not with the freshly installed one; I'll try a fresh normal installation, too
<doko_> pitti_: the 32bit strace does work however
* pitti tests amd64/expert
<doko_> Mithrandir: ping
<Mithrandir> doko_: pong
<seb128> is there a place to describe issues?
<seb128> i386 with custom partitionning doesn't boot
<seb128> "Hard disk boot sector invalid. Press 'H' to retry ..."
<fabbione> seb128: works here.. where did you put / or /boot ?
<seb128> I made a automatic-partitionning install before
<seb128> booted this one
<seb128> picked the manual partitionning
<seb128> deleted the previous one
<fabbione> (+ that sounds like a BIOS can't read MBR issue)
<seb128> create a 10G / and a swap
<seb128> and didn't put any boot flag (should I?)
<doko_> It looks like if I add the 32bit libdb-4.2.so in LD_PRELOAD, I can start the help on amd64. Is there a way to determine other libs, which are preloaded, as well?
<seb128> dunno if that's an user error or not ...
<doko_> s/preloaded/dlopened/
<fabbione> seb128: did you put swap before / ? if so how big?
<seb128> no
<seb128> hda1 is 10Go /
<Diziet> Ah, fabbione.  Hello.
<seb128> hda2 is 500M swao
<seb128> swap
<Kamion> seb128: did you make hda1 active?
<Kamion> some BIOSes don't like it if you don't
<fabbione> seb128: looks ok
<fabbione> Diziet: yo, yes?
<Kamion> s/active/bootable/, whatever the terminology in use is
<seb128> Kamion: nop, what I said with "<seb128> and didn't put any boot flag (should I?)"
<doko_> Mithrandir: ^^^
<Diziet> In scrollback you say something about gs and an ICE ?!
<seb128> <seb128> dunno if that's an user error or not ...
<Kamion> seb128: yes, you probably should
<fabbione> Diziet: i already fixed it.. sort of..
<Kamion> seb128: I have a bug open about this; we tried to fix it for hoary, but it was more complicated than expected so we deferred until, um, breezy (oops)
<seb128> Kamion: k, I thought than first partition was set automatically 
<Diziet> Um, OK, I'll go and look ...
<fabbione> Diziet: i had to switch sparc back to gcc-3.4.. one of your patches manage to ICE on sparc with gcc-4.0
<seb128> Kamion: do you have the bug number so I can point it on the wiki?
<Diziet> The stdarg one, no doubt.  But even so I didn't think it was very controversial.
<Kamion> seb128: I'm just looking, one sec
<seb128> thanks
<Kamion> seb128: it's not a regression in breezy though
<doko_> pitti: please check for the amd64 help: copy the 32bit libdb-4.2.so to /usr/lib32, add it in /usr/lib/openoffice2/program/soffice.bin to LD_PRELOAD (white space separated), then start ooo again
<pitti_live> shit, amd64/expert hangs at installing grub
<Diziet> Just in case I'm wrong somehow, I'd like to see it for myself.  DYK what our sparc in the colo is called ?
<Kamion> seb128: #7906
<seb128> Kamion: probably not, I had such issue before hoary
<SteveA> mjg59: hi, around?
<seb128> thanks
<infinity> Diziet : We don't have one.
<pitti_live> doko_: ok, next time when my amd64 has finished stuff
<Diziet> inf: Oh.
<Kamion> sparc's an unofficial port, fabbione runs it more or less solo
<Diziet> Right, OK.
<Mithrandir> doko_: no, there isn't.
<Diziet> In that case, fabbione, can you tell me file and line number or do you not get the line number ?
<fabbione> Diziet: one second...
<fabbione> Kamion: i am not THAT alone :) just for the buildd/integration side :)
<Kamion> right
<fabbione> Diziet: http://bld-3.mmjgroup.com/buildLogs/g/gs-gpl/8.01-5ubuntu4/gs-gpl_8.01-5ubuntu4_20051011-1533-sparc-failed.gz
<fabbione> Diziet: anyway.. that's stuff to look for dapper
<fabbione> Diziet: nothing to worry about for now..
<seb128> Kamion, fabbione: setting the hda1 bootable flag with fdisk fixes the issue
<Kamion> seb128: good
<fabbione> perfect
<Kamion> seb128: what machine?
<seb128> Kamion: the packard bell laptop that jdub had during the Oxford time
<Kamion> right, I think we only ever had this problem with some dodgy laptop BIOSes
<doko_> Kamion: are there 360k place on the amd64 CD's? to get the ooo help working, we need the 32bit libdb-4.2.so
<Kamion> but yeah, we really must actually fix this in dapper rather than forgetting about it
<Kamion> doko_: yes, we certainly have that much room; shame it'll require a livefs rebuild
<fabbione> Kamion: bugs filed..
<doko_> Mithrandir: which package should contain the 32bit libdb4.2.so?
<Kamion> oh, but having to rebuild ooo2 is going to SUCK
<Kamion> ah, only ooo2-amd64
<doko_> Kamion: no, just repackaging the amd64 bits
<pitti_live> Kamion: expert install at both ppc and amd64 hangs; I have an idea about the reason, do you want to discuss this now or shall we ignore this?
<Kamion> pitti_live: now
<fabbione> pitti_live: how do they hang?
<Mithrandir> doko_: ia32-libs, probably.
<pitti_live> Kamion: on amd64 it hangs at installing grub
<pitti_live> Kamion: I killed d-i's apt and chrooted into /target and apt-get install grub
<Kamion> I bet it's having trouble in apt-install
* mvo is goint to test this next once the cd is burned
<pitti_live> Kamion: it asks me to insert the CDROM, I press enter, it asks me again
<mvo> pitti_live: do you have working network at this stage?
<pitti_live> Kamion: d-i's apt hogs 100% CPU, I assume it tries to ask that question, too (non-interactively)
<Kamion> ok, I think I saw this on i386 too yesterday, but I was on a heavily-hacked installer so I disregarded it in favour of other problems
<pitti_live> mvo:  yes, I can ping
<Kamion> in retrospect that was probably a mistake
<Kamion> I suspect the apt-setup integration
<pitti_live> Kamion: same happens on ppc in stage 2 - apt-get hangs without any progress
<pitti_live> Kamion: with the same reason (does not recognize the CD)
<Kamion> perhaps it is buggy and generates a different sources.list at low priority
<fabbione> pitti_live: hangs at the end of the installation?
<Kamion> pitti_live: what's in /target/etc/apt/sources.list?
<sabdfl> hmm... our spell check is broken
<pitti_live> fabbione: amd64 expert: at grub install, ppc install: right at the beginning of stage2
<sabdfl> could someone try to spell check a document in openoffice please?
<pitti_live> Kamion: let me go over and look
<fabbione> oh begining.. pitti_live: bad burn?
<fabbione> no
<Kamion> fabbione: no, this is a real problem
<fabbione> never mind
<fabbione> Kamion: yeah.. it can't be bad burn if it did copy successfully pkgs at stage1
<fabbione> sabdfl: checking now
<pitti_live> fabbione: no, the same CD worked fine for server and normal install
<seb128> sabdfl: works fine for me with the writer
<doko_> sabdfl: do you see the "ABC" icon in the language preferences?
<pitti_live> Kamion: sources.list has the CD-ROM with main aind restricted; on my iBook that's the only source (no nework), on amd64 I have the network sources, oo
<fabbione> sabdfl: looks good here
<Diziet> zcsdevn.i (gcc -E output) from old and new gs-gpl are identical modulo one embedded pathname in a #... line number annotation.  So it's not my change that broke it.
<pitti_live> Kamion: since apt does ask for the CD, it seems that apt wants a different one
<Kamion> pitti_live: is this after installation, or when it hangs?
<doko_> Mithrandir: are the cups libs somewhere in ia32-libs?
<pitti_live> Kamion: I killed d-i's apt and logged in VC 2
<pitti_live> Kamion: still at end of stage 1
<pitti_live> Kamion: and grub is not installed
<fabbione> Diziet: it did build fine previously.. with gcc-4.0.. so something did change :)
<Kamion> hmm, that's very odd
<Diziet> GCC ?  
<Diziet> Are you sure the hardware is reliable ? :-)
<Mithrandir> doko_: I don't think so.
<fabbione> Diziet: dude.. yes. the hw is realiable
<pitti_live> Kamion: as already said, it works fine for normal and server mode, just expert
<Kamion> I'll investigate this myself right now
<Mithrandir> doko_: but printing works fine, so please don't fuck around with that.
<Kamion> pitti_live: yeah, that makes me inclined not to suspect apt
<pitti_live> Kamion: shall I try apt-setup again on amd64? (too late for ppc, already stage 2)
<Kamion> pitti_live: no
<pitti_live> mvo: how do I compare the signature of apt-setup with the actual CD I have in the drive?
<mvo> pitti_live: greek chars look much better after the fontconfig fix btw
<Kamion> I'm betting strongly that sources.list looks different between normal and expert installs at that stage, or else that apt-get update hasn't been run in one of those scenarios
<mvo> pitti_live: apt-cdrom ident should do
<pitti_live> mvo: but apt-get seems to have a different idea of my CD; where can I see the stored id?
<infinity> mvo : Have you learned to reed greek, so you can enjoy your greek install a bit more?
<doko_> Mithrandir: I "don't fuck around with that", please change your tone
<fabbione> hey guys... come on... easy.. we are all overstressed for release
<mvo> pitti_live: "apt-cdrom ident" gives you a identifier for the cd, then you can check /var/lib/apt/cdroms.list
<pitti_live> Kamion: I partially solved ppc: I inserted the CD again and killed the apt-get, now it installs
<pitti_live> Kamion: I didn't copy the debs on hd for ppc; however, it should ask to insert the CD in that case (no blocker, though)
<mvo> infinity: no, of course not. but I still enjoy the nice glyphs
<segfault> too late for a kernel change?
<segfault> :D
<segfault> i mean, recompile.
<fabbione> segfault: yes way too late
<segfault> Your kernel was built with "gcc" version "3.4.5", while you are trying to use
<segfault> "/usr/bin/gcc" version "4.0.2".
<segfault> :(
<Kamion> pitti_live: we don't have a UI for CD insertion at the moment, but that should not be happening at all and is a blocker bug
<fabbione> segfault: no.. that's the correct behaviour... you are doing something wrong to build your nvidia drivers
<fabbione> segfault: export CC=gcc-3.4 and recompile whatever you are doing
<Kamion> UI> in base-config that is - it requires funky fd handling to get a newline back to aptitude's stdin
<segfault> i'm trying to compile vmware, but shouldn't the kernel be compiled with gcc4 too?
<Mithrandir> segfault: no.
<pitti_live> Kamion: ok, more ideas: fingerprints are identical
<fabbione> segfault: -> #ubuntu and no..
<segfault> mithrandir: why not?
<pitti_live> Kamion: but when I chroot /target, I cannot mount the CD
<segfault> its not a user question, i know how to fix it
<Mithrandir> segfault: because it breaks.
<segfault> i'm just trying to figure out why its not using gcc4 :)
<fabbione> segfault: it is a user question.. and it's not a bug
<mvo> Kamion: the strange thing is that it shouldn't hang when the question is asked but fall back to some other source or fail complettly
<pitti_live> Kamion: it says it is "busy"; I can only mount it when I umount it from the d-i root fs before
<Kamion> pitti_live: I think you're on the wrong track, because none of that sort of thing should be affected by the prevailing debconf priority, surely?
<Kamion> not that I know the problem yet, but ...
<pitti_live> mvo: /v/l/apt/cdroms.list has two entries for the CDs: same fingerprint, but the second has a ::Label thing; is that right?
<Kamion> CD handling in the installer is delicate and doing stuff by hand at the same time may well break it; that in itself is not surprising
<Kamion> the question is what happens at DEBCONF_PRIORITY=low that is different from what happens at DEBCONF_PRIORITY=high
<pitti_live> Kamion: how does the package install work? does d-i chroot into /target and calls apt-get?
<infinity> Kamion : I have a spot of good news for you.  In my crazy HDD setup on my girlfriend's computer, the installer managed to get the crazy grub remap-and-chainload magic right for the first time so it dual-boots without hanging.
<Kamion> pitti_live: see /bin/apt-install
<Kamion> infinity: rah :-)
<pitti_live> Kamion: or does it call apt-get with a --target option?
<segfault> What it breaks?
<Kamion> no, it chroots
<Kamion> I cannot paste the line right now because my mouse is acting up
<mvo> pitti_live: yes, two lines should be ok
* Kamion tries a machine without network access, to isolate that factor
<mull> Hello I think I have found an X11 bug .. but it would be nice if someone could confirm it
<mull> If I reach the end of certain "input buffers" the screen flickers (turns to black and redraws)
<infinity> Hrmph.  We really should have the installer dpkg-divert fc-cache, and run it once at the end of the install.
<infinity> I think the collective font postinsts are responsible for about 30% of my install time.
<jdub> infinity: i thought Kamion had done that?
<Kamion> infinity: does it do significant duplicate work each time?
<Kamion> jdub: no, that was scrollkeeper
<mull> Test case: open gvim. press "i". and then the down button.
<infinity> Kamion : Yes.
<Kamion> scrollkeeper *does* do significant duplicate work each time, due to insufficient caching
<Kamion> infinity: ok, can do that in dapper then
* jdub thought you had done both, having mentioned it before ;)
<ogra> infinity, i think its more than 30%
<Kamion> jdub: you did? I don't remember
<Kamion> infinity: file a base-config bug for me please, milestone Ubuntu 6.04
<dholbach> mull: works for me
<mull> typing a not nown search entry in firefox search bar also shows that behavior
<infinity> The only other installer complain I had is the complete lack of password-safety checking.  It let me set a password I'd never be allowed to set at runtime ("foo")
<infinity> Again, far too late to care.
<mull> err nown == found
<Kamion> infinity: iz passwd.config bug, but yeah
<dholbach> mull: i suggest you write a detailed bug report on bugzilla.ubuntu.com (hardware, attach xorg.conf, test cases, versions of stuff you use)
<mull> ok
<infinity> ... And the installer doesn't clear out kernel update-notifications, so the first boot sees a lightbulb.
<infinity> Yay.
<infinity> (Will be fixed differently in dapper anyway, I suppose)
<Kamion> base-config has code to do that
<Kamion> does it not work?
<infinity> Kamion : I'm going to go with "no"... My freshly-installed amd64 system showed me a kernel reboot notification.
<Kamion> it's near the bottom of /usr/lib/base-config/menu/pkgsel
<Kamion> mvo: ?
<seb128> mull: you probably use the visual bell?
<Kamion>                 find /var/lib/update-notifier/user.d/ -type f -printf '%P\n' \
<Kamion>                         | sed "s/\$/ $(date +%s) 0/" \
<Kamion>                         > /etc/update-notifier/hooks_seen
<mvo> Kamion: that should work...
<seb128> mull: gnome-sound-properties, System Bell ... do you use "Visual feedback"?
<infinity> mvo : I'm going to run through the installer all over again and not click the icon this time, so I can see what state the installer is leaving the notifications in...
<doko_> -rw-r--r--  1 doko 2500 8815840 Oct 12 10:35 ia32-libs_1.4ubuntu2_amd64.deb
<doko_> -rw-r--r--  1 doko 2500 9172382 Oct 12 10:51 ia32-libs_1.4ubuntu3_amd64.deb
<doko_> Kamion: ok to upload?
<mvo> infinity: thanks, I'll look for it on my next install too
<Kamion> doko_: subject to having a look at the debdiff afterwards, yes
<Kamion> doko_: (tested, I assume :-))
<Kamion> infinity: FWIW I don't remember seeing the same thing recently
<infinity> If it doesn't do it on the second run, then this is non-deterministic, and I'm frightened.
<infinity> I'm hoping it shows up again this time.
<doko_> Kamion: testing from the package makes sense with the changed oo-amd64 package only. but tested by copying the lib manually
<infinity> Also, do we do a reverse DNS lookup to guess the hostname in the installer?.. I found it infinitely creepy that it knew my machine's name.
<infinity> (And cool)
<fabbione> infinity: yes.. since a long time
<infinity> I probably didn't have functioning reverse DNS the last time I did installer tests. :)
<fabbione> when was that? pre-warty?
<fabbione> i recall it working since warty :)
<pitti> bah, I got disconnected
<pitti> pitti_live Kamion: I just saw it myself
<pitti> pitti_live Kamion: mounting the CD in the chroot fails
<pitti> pitti_live Kamion: that might be the reason
<pitti> * pitti_live tries something
<pitti> pitti_live Kamion: confirmed: when I umount /cdrom in VC2, it works
<pitti> hno73: did you say something?
<hno73> pitti: It's just a general request to people who are doing testing to grab some screenshots of the latest desktop, if you have a chance (for the website)
<hno73> if it's convenient 
<Kamion> doko_: "changed oo-amd64 package"> I didn't think oo-amd64 needed to be changed
<pitti> Kamion: since the install was totally screwed now, I'll try it again and report back
<doko_> Kamion: why? I need to add the lib to LD_PRELOAD
<Mithrandir> doko_: why do you need to do that?
<doko_> Mithrandir: to get the help working?
<Mithrandir> doko_: I hope ooo2 doesn't try to dlopen with full path?
<Kamion> pitti: hmm, it just worked fine for me on i386/expert
<Kamion> pitti: did you select all the defaults?
<segfault> Has anyone tried the latest breezy kernel and VMware 5?
<pitti> Kamion: mostly; I said no to pcmcia support and did not copy the packages to hd at first
<Kamion> pitti: AH
<pitti> Kamion: after the first failure and killing, I copied the packages to hd and tried again, but same result
<segfault> some oops around here.
<Kamion> pitti: don't do that then :-)
<doko_> Mithrandir: ahh, ok, I was missing a ldconfig after the manual installation
<mvo> Kamion: i386/expert worked fine for me too, I didn't copied the packages, but inserted the cd during boot
<mvo> ^--- pitti 
<pitti> Kamion: copying packages to hd is evil (from my POV), so I first tried without :-) and the menu doesn't force me to do it, so I didn't
<pitti> mvo: ok, that's the case of my ppc; but I'm not even at the reboot stage on amd64
<Kamion> pitti: if that's the only situation where it fails, I'm happy to live with the problem for breezy
<pitti> yes
<pitti> I try it with copying ackages now
<pitti> bbl, maybe my main network returns soon
<pitti> mvo: please ring my mobile or landline if I should go online
<pitti> mvo: is that possible?
<pitti> mvo: I need to go offline for a bit
<mvo> pitti: /msg
<Lathiat> when do the archives close?
<Lathiat> universe wise
<ajmitch> Lathiat: not yet, it seems
<ajmitch> for hoary it was just before release
<Lathiat> i guess
<Lathiat> just wanting to sync avahi 0.5.2-2
<ajmitch> what's new in it?
<Lathiat> just a couple dependancy fixes
<Riddell> Kamion: are the current ubuntu dvds excpected to be final?
<Kamion> Riddell: no
<ajmitch> getting a sync might be a challenge, mdz/kamion/elmo will be flat out
<Kamion> but more or less final in terms of content
<ajmitch> I guess you could do a straight upload with those fixes as -1ubuntu1
<Kamion> no don't do that
<Kamion> I'll do a sync in a moment
<ajmitch> though it's not the best thing 
<ajmitch> Kamion: oh good, thanks :)
<Kamion> where does avahi come from? debian?
<ajmitch> experimental
<Lathiat> Kamion: experimental
<Lathiat> bah i just mailed elmo
<ajmitch> Lathiat: so mail him to say it's been done
<mvo> Kamion: amd64/expert looks fine so far (with pkg copyied to hd), stage2 almost finished
<Kamion> Lathiat: ITYM incoming
<ajmitch> yeah, it's probably still stuck there
<infinity> mvo : Second fresh install, lightbulb is back again.  What state files do you need to see to debug this?
<mvo> infinity: I'm doing a fresh install myself right now, but you can /msg me /etc/update-notifier/hooks_seen, ls -laR /var/lib/update-notifier/ and cat /proc/uptime
<Kamion> Lathiat: I don't know how to do syncs from incoming (i.e. how to get the Sources file); you'll have to ask elmo
<Lathiat> Kamion: ok
<pitti> yay network back
<Lathiat> hopefully by the time elmo gets my mail it will hit experimental
<pitti> doko_: do you know the amd64 ooo failure reason now?
<pitti> doko_: I just did ppc/expert and it worked
<infinity> mvo : Kay, will in a bit.  I need to make some food; the natives are restless.
<infinity> mvo : On a hunch, try installing with "the clock isn't set to UTC" (which I did, because this dual-boots with Windows)
<doko_> pitti: copy libdb-4.2.so from an i386 installation into /usr/lib32
<mvo> infinity: I think that's the problem. I haven't seen it in the test-installs I did so far (and I did a lot :) but that's because I always set to UTC 
<mvo> infinity: strange, this bug is probably around for some time then
<pitti> doko_: ok, so you know the reason; thanks
<pitti> Kamion: bad news - I did the expert installation again (amd64) with copying packages
<pitti> Kamion: same result - I have to umount /cdrom and kill the apt-get process, then reattempt grub instalation
<mvo> pitti: worked fine here (amd64, with copying)
<Kamion> pitti: was grub copied to /target/var/cache/apt/archives/, *before* you fiddled with it?
<jkrogh> Is the latest amd64-smp kernel broken? 
<jkrogh> Kernel BUG at "mm/mmap.c":1937   
<jkrogh> http://krogh.cc/~jesper/report
<Treenaks> who uses mmap anyway :P
<Kamion> elmo: please change breezy's Release file to say "Ubuntu Breezy 5.10"; we don't want it Untouchable yet, but this will let me build really-candidate CDs
<\sh> I hope my day off from work tomorrow will be approved
<pitti> Kamion: I'm 80% sure that it wasn't, but I have to check
<mjg59> Kamion: Can I upload a new acpi-support to disable laptop-mode by default?
<Kamion> mjg59: urgh. What exactly's the problem?
<mjg59> It causes various machines to hang
<mjg59> In a way that I can't reproduce and which seems to make no sense whatsoever, but still
<Kamion> and the consequences (apart from making us have to rebuild all the live filesystems)?
<ajmitch> \sh: you deserve a day off :)
<pitti> Kamion: 100% sure; it isn't in apt cache even after installing it (obvious, since installing from CD doesn't copy packages)
<ajmitch> \sh: feeling ill still, or just want to rest?
<mjg59> Kamion: Higher power consumption on laptops
<\sh> ajmitch: I want it, because I want to have a test install run tonight :)
<mjg59> mdz requested the change
<Lathiat> mmm nifty, just got a support request through to a little non profit isp i look after and the user was using breezy firefox :)
<ajmitch> haha
<ajmitch> \sh: nearly 1AM here, but I doubt I can get a day off tomorrow :)
<pitti> Kamion: so probably grub should be copied, too, or even better, the CD should always be unmounted after apt setup?
<Kamion> pitti: what effect would DEBCONF_PRIORITY=low have on either of those things?
<\sh> ajmitch: *g* 
<Kamion> pitti: grub wasn't copied in hoary and it did no harm
<Kamion> and it isn't copied in normal installa
<Kamion> installs
<ajmitch> \sh: I'll just have to have a quiet beer to celebrate the release after work :)
<Kamion> mjg59: when did he request it?
<Kamion> (bug number?)
<mjg59> Kamion: http://bugzilla.ubuntu.com/show_bug.cgi?id=6108
<Kamion> mjg59: urgh, that was a week ago :(
<mjg59> Kamion: I'd also like to disable starting irda services on resume, because it hangs some machines on resume (including the HPs)
<Kamion> but ok
<mjg59> Kamion: Yeah. Sorry, I missed the mail
<Kamion> right, do what you have to and no more
<mjg59> Ok
<Kamion> thanks
<seb128> Kamion: is the eom stage2 of the installer different? it has some untranslated strings
<pitti> Kamion: I have no idea; I just reproduced it three times now
<Kamion> seb128: #17366. they're untranslatable right now
<seb128> thanks
<mvo> pitti: that was amd64/export, any other options? I can't reproduce it here :/
<Kamion> pitti: I'm strongly disinclined to randomly perturb an area of code I know to be very delicate when we don't even understand the problem
<pitti> mvo: yes, I only changed one question (not install pcmcia)
<Kamion> pitti: AFAIK the CD is left mounted at that point in order to allow apt to read packages from it
<Kamion> unmounting it would break things
<mvo> pitti: ok, I didn't included that too. I'll give it another try soon
<pitti> Kamion: but if you can't mount the CD in the chroot a second time, it at least explains the effect
<pitti> ok, if it works for mvo, it's prolly not a blocker
<Kamion> pitti: why is apt trying to mount it a second time at all? it shouldn't be
<Kamion> we bind-mount /cdrom to /target/cdrom in base-installer, and leave it that way until near the start of prebaseconfig
<pitti> Kamion: because it wants to install grub, which is on the CD, but not in apt cache
<Kamion> pitti: but the CD is already mounted; it should not be remounting it
<pitti> Kamion: the CD does not appear as mounted in /target
<pitti> ok, I will check the bind mount next time
<Kamion> ok, so the question is what is unmounting it
<pitti> Kamion: unmouting?
<Kamion> presumably apt-setup, but why only in expert installs?
<pitti> I'll just finish this installation to test the desktop stuff, update the wiki, and try it again
<pitti> and I'll watch out for the bind mount
<pitti> I definitively know that "mount" does not print the CD
<pitti> I'll check
<Kamion> I think apt-setup unmounts and remounts
<Kamion> but that's normally ok
<pitti> ok, I change computer and give back this one, brb
<Kamion> 'mount' might not print it
<Kamion> 'ls /target/cdrom/' to be sure
<Kamion> pitti: I really wish you'd use screen ... makes it hard to have a conversation with you when you keep disappearing
<Kamion> pitti: anyway, if you could put 'set -x' near the top of /target/usr/sbin/apt-setup before the apt configuration stage runs, that'd be helpful
<Kamion> the shell trace should land in /var/log/syslog
<\sh> wow....breezy update party today in the NOC of ISH ;)
<pitti> Kamion: will do
<mjg59> Kamion: Ok, incoming
<Kamion> doko: your ia32-libs upload includes a number of non-changelogged package updates
<Kamion> doko: I would much prefer to have *only* the libdb4.2 addition
<doko> Kamion: hmm, so don't rebuild the package, just do a fake rebuild?
<devid> hi to all . there is someone who can help me?
<bob2> devid: this is not a support channel, particularily when people are trying to do a release; if you need help, try #ubuntu
<jkrogh> Can I find "older" kernel packages somewhere? 
<Kamion> doko: yes - I'd like the only change in a debdiff from 1.4ubuntu2 to be the addition of libdb4.2
<devid> i must use the command top to modify the priority of the process
<Kamion> and the libdb-4.2.so munging
<Kamion> we don't have time to deal with any unexpected problems caused by a general fetch-and-build update any more, I'm afraid
<doko> Kamion: reupload as ubuuntu3 or ubuntu4?
<Kamion> ubuntu4, please
<pitti> doko: I unpacked the i386 libdb-4.2.so, put it into /usr/lib32, called ldconfig, but no change - did I forget anything?
<maswan> \sh: ISH?
<sabdfl> devid: https://launchpad.net/distros/ubuntu/+tickets
<pitti> seb128: in oem, you have to reboot to be able to log in, that's intended
<seb128> pitti: how so?
<seb128> pitti: beeing pushed to a gdm screen asking for a login with no login available is intended? That's plainly wrong ...
<doko> pitti: that was the thing, that did work for me. please call: strace32 -e trace=open -EGTK_PATH=/usr/lib32/gtk-2.0 -ELD_PRELOAD=/usr/lib32/libpangohack.so.0.0 /usr/lib/openoffice2/program/soffice.bin.real
<pitti> seb128: the intention is that the OEM installs the system, does a check, shuts down, and at next reboot, the user will register his account
<pitti> fabbione: you tried autoresizing - does that only work with vfat? I never got this alternative offerered
<seb128> pitti: right, but it didn't reboot, it jumped on the gdm login screen
<pitti> seb128: right, that should be improved
<fabbione> pitti: i did try with ext3.. i got it in partman
<seb128> pitti: do you have some free space?
<doko> pitti: updated ia32-libs on p.u.c/~doko
<mvo> ogra: in oem-hwdb mode I get "network test", under it "is your *mouse* working properly" and then it hangs (I don't have a network setup)
<pitti> seb128: on my hd? yes
<nomed> i'm trying breezy .. it seems /etc/hal/device.d is not present ...where should i put my old hald scripts?
<seb128> pitti: that's probably why you don't get the option
<seb128> mvo: exactly the same here
<pitti> fabbione: ok, thanks. I only have reiserfs, vfat, and xfs partitions
<seb128> mvo: then cancel and welcome to gdm with no login :p
<pitti> doko: where is strace32?
<fabbione> pitti: i did try ext3 because it was there
<ogra> mvo, hmm, i never tested in oem mode...
<mvo> seb128: hrm :/
<pitti> ogra: confirmed, for me too
<mvo> ogra: is there a way to cancel the the network test?
<pitti> ogra: and the sound check is broken
<seb128> yeah, no sound here neither
<ogra> f*ck
<doko> pitti: copy from i386
<seb128> during the eom mode
<seb128> works fine once on the desktop
<mvo> Kamion: is pkgsel run before the timezone question?
<doko> pitti: help works for me
<pitti> doko, I try your package
<pitti> seb128: why free space?
<mvo> ogra: anything I can kill to cancel the network test?
<dholbach> mvo: fping?
<dholbach> ogra: didnt you use fping?
<seb128> pitti: no need to autoresize if you have an available partition
<ogra> dholbach, yup, its a dependency
<seb128> pitti: just a random guess
<mvo> dholbach: thanks, but looks like it's not runing
<pitti> seb128: ah, no, everything is already partitioned
<dholbach> mvo: gets called in the code though
<mvo> dholbach: haven't seen it in ps ax :/
<dholbach> mvo: :-(
<pitti> doko: I installed your new ia32-libs, start OO.o, no help
<seb128> dholbach: the network tab just breaks, it has no "next" button and a label about the mouse
<pitti> doko: ah, -help-en-us is not installed
<doko> pitti: works for me on two different installations ...
<doko> pitti !!!
<doko> :)
<pitti> doko: l-support-en is not installed in expert more as it seems
<pitti> doko: ok, confirmed, works now
<pitti> mvo: in your amd64/expert installation, was l-support-en installed?
<pitti> mvo: for me it's not, but I don't regard it as blocker for expert
<mvo> pitti: I'm going to test that next
<Kamion> mvo: no, pkgsel runs long after, in the second stage
<pitti> mvo: you marked OO-o failure, so you just didn't check the reason?
<Kamion> seb128: login 'oem' with the password you selected in the first stage
<Kamion> seb128: that stuff was changed too late to be able to add UI for it
<pitti> mvo: would be nice to confirm that from a second person
<mvo> pitti: I didn't check the reason, no
<Kamion> seb128: it should be in the release notes; I'll fix that
<seb128> Kamion: thanks
<dholbach> i'll rush out for some fresh air and something to eat, brb
<Kamion> seb128: done
<Kamion> pitti: you don't get autoresize offered if sufficient numbers of partitions won't fit in your partition table
<Kamion> pitti: this is not uncommon with PC partition tables because they suck
<\sh> maswan: 2nd biggest cable tv provider in germany :)
<Kamion> pitti: we attempt to offer autoresize on swap/ext2/ext3/fat32/ntfs at the moment; can probably extend that to reiserfs/xfs in future
<Kamion> oh, and hfs/hfsplus
<pitti> Kamion: yes, that sounds reasonable; I have three primary partitions on hda, and four on hdb
<pitti> (hdc actually, but doesn't matter)
<pitti> I'll play around with it, though
<mjg59> Kamion: Did automounting ntfs partitions ever get fixed?
<mvo> Kamion: the notification comes up when I install internal clock not UTC, the ctime of the notification message is almost 2h newer than the time writen into the hooks_seen file
<Kamion> mjg59: yeah, partman-basicfilesystems 32ubuntu2, five days ago
<mjg59> Kamion: Rock, thanks
<pitti> bah, resolvconf is soo broken...
<Kamion> mvo: oh, don't tell me I got the date invocation wrong :(
<Kamion> pitti: right, need one primary partition for / and somewhere to put a logical partition for swap
<Kamion> at minimum
<mvo> Kamion: I'm looking into it now, after so many test installs my head is spinning a bit, give me some minutes
<maswan> \sh: ah :)
<fabbione> hey maswan 
* pitti goes to debug the grub issue
<Kamion> doko: ia32-libs approved
<Kamion> thanks for that
* pitti asks himself why language-support-en is not installed on ppc 
<doko> pitti: just did see, that I missed openoffice.org2-help-nl. breezy-updates ...
<\sh> wooo....hoary -> breezy upgrade on another nc6000 with {ubuntu,kubuntu}-desktop went really smooth...
<pitti> ah, autoresize worked great this time
<xhaker> hard time accessing cdimage
<xhaker> elmo?
* infinity reboots to test an installation on the laptop.
<Znarl> xhaker : Can I help?
<xhaker> just wondering why i can't access cdimage.ubuntu.com
<fabbione> xhaker: what protocol?
<xhaker> simple http
<fabbione> works from here
<xhaker> wait. i'll try again
<xhaker> connection re
<xhaker> reseted
<xhaker> so it seems it's being hammered?
<Kamion> day before release, not surprising
<fabbione> xhaker: it must be something between you and cdimage
<fabbione> works fine here
<fabbione> Kamion: we are actually doing less traffic than usual (according to an italian isp)
<xhaker> must be my university then
<fabbione> because mirrors are all in sync
<fabbione> and few uploads
<xhaker> oh..talking about mirrors
<xhaker> how would i go about making a mirror on my university?
<Znarl> xhaker : https://wiki.ubuntu.com/Archive?highlight=%28mirror%29 has the details
<xhaker> if i can get them to mirror the isos, or the archives.. do i need any permission from you?
<Znarl> You do not need permission.  
<xhaker> thanks
<xhaker> another thing.. is the daily image still 12.1?
<pitti> Kamion: I'm on it: before apt-setup, there is /target/sys, /target/proc, and /target/media/cdrom0 mounted
<pitti> Kamion: after apt-setup detected and added the CD source, this is still true
<Kamion> xhaker: yes
<pitti> Kamion: but then it asks me for net sources, adds them, and afterwards all bind mounts are gone
<rob_lap> is anyone else having issues with the update-notifier package?
<rob_lap> 404 not found?
<pitti> Kamion: I have the set -x output, I'll copy it to another hd partition and will send it to you once my desktop has network back
<pitti> mvo: did you add apt network sources in expert mode?
<bddebian> Hello
<pitti> Kamion: shall I try anything? I can add back the bind mounts and execute something manually if you want
<mvo> pitti: not sure, what was your setting
<mvo> ?
<Kamion> pitti: set -x output will do for now
<maswan> fabbione: hi, sorry, we didn't get around to swapping disks. Hopefully RSN.
<pitti> mvo: see above; the bind mounts disappear when I add network sources
<fabbione> maswan: no problem :) main is all done ;)
<xhaker> will you rebuild an image today for testing? it looks like 12.1 is already well tested from what fabbione said
<Kamion> xhaker: yees
<Kamion> er, yes
<Kamion> if nothing else, 12.1 says "Release Candidate", we can't release it like that :)
<HiddenWolf> Is anyone here a canonical guru involved marginally with PR?
<xhaker> Kamion.. i meant for testing
<xhaker> not release
<Kamion> xhaker: yes, so did I
<mvo> Kamion: what do you think about http://paste.ubuntulinux.nl/3011 ?
<Kamion> we need to test the final image, we can't just rebuild and release
<xhaker> ohh
<xhaker> :)
<xhaker> any ETA?
<Kamion> xhaker: no
<Kamion> mvo: hmm, I think it's post-breezy
<Kamion> mvo: thanks for the fix though, we can roll it in first thing in dapper
* ajmitch hopes there's enough time to get this moodle security upload in
<ajmitch> pitti: moodle in universe has security holes, want me to lookup CANs & put them in changelog?
<Kamion> mvo: (I've applied it to my local copy)
<pitti> ajmitch: sure
<ajmitch> ok, google found it :)
<mvo> Kamion: thanks, it now uses the ctime of the hook as initial timevalue, that shouldn't lead to any problem (at least I can't think of any)
<Kamion> yeah, I think the problem is probably minor enough that we can get away with it as a known issue
<pitti> mvo, Kamion: I described everything in #17637
<mvo> pitti: thanks, I just rebootet to test (wanted to figure the notification issue first)
<\sh> ajmitch: wanna do the phpmyadmin security upload, too? :)
<\sh> grmpf...brb
<jkrogh> The amd64-k8-smp kernel oopses for me (#17636) Where can I find older versions to test with? 
<ajmitch> \sh: erm, what's the hole there?
<ajmitch> since pitti uploaded it awhile ago
<doko> Kamion: hmm, ia32-libs did FTFBS on ia64, cannot fetch the changelog yet
<Kamion> doko: aargh
<doko> s/changelog/build log/
<dholbach> elmo: could you please add pvm (sid) to your sync list?
<bddebian> dholbach: No, you have to stand in line too ;-)
<Kamion> dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory
<Kamion> dh_builddeb: command returned error code 512
<Kamion> doko: ^--
<Kamion> doko: 1.4ubuntu2 failed too, we'll ignore this
<Kamion> the last version to succeed was 0.5ubuntu6
<Kamion> and that didn't make it to the archive
<Kamion>  ia32-libs | 0.5ubuntu3 |        breezy | ia64
<doko> hmm, the fix looks simple however
<Kamion> doko: it's post-breezy
<mvo> Kamion: vim is acting strange in the install. I choose "edit sources.list by hand (in apt-setup)"
<Kamion> mvo: #6627
<Kamion> best solved by disabling the editor option, I suspect
<Kamion> (but only in the first stage)
<mvo> Kamion: ok, thanks
<mvo> pitti: I can reproduce the hang now too (after adding the network sources)
<pitti> mvo: see my bug report
<Kamion> I need the log file before looking at it
<pitti> Kamion: my desktop install finsihed 30 seconds ago, I'm at the phone, I'll attach it ASAP
<Kamion> ok
<Kamion> I'll be off testing the powerpc install for a while to see if I can duplicate this oo.o2-help-en-us thing
<dholbach> amd64 dvd memtest gives million rows of "0104"
<dholbach> will check with amd64 cd
<dholbach> same
<dholbach> same for live :/
<mvo> dholbach: amd64 memtest gives me "Loading...." here (nothing more)
<dholbach> hrm
<dholbach> will try on i386
<dholbach> i386 dvd gives me 4000, but in a slower rate
<mvo> dholbach: i386 just gave me the same result (but 6 times "Loading....")
<mvo> on two different machine with two different cds :/
<\sh> later guys
<zyga> hi again
<Kamion> dholbach, mvo: I'll look, but if you can try to figure out what's up, that would be great
<Kamion> this used to work
<zyga> mvo: hi
<dholbach> i'll look
<mvo> hi zyga 
<zyga> mvo: problems with update-manager?
<mvo> zyga: I hope not, why do you ask?
<pitti> mvo: are you still in the installer? I can't find my log, I must have put it on a partition that was overwritten
<zyga> mvo: ah, some people on u-translators have noticed a regression in translations
<mvo> zyga: I'm not aware of this, it should be a rosetta thing I imagine?
<zyga> mvo: yes something murky is still happening
<Kamion> I'm fairly sure I tested memtest86+ since the last sync
<zyga> mvo: okay back to work - I'll be out of your way untill dapper
<mvo> Kamion: it works fine after the install, it seem to be broken when run from the cd
<Kamion> whoa, DVD drive goes CHUNKCHUNKCHUNKCHUNKCHUNKCHUNKCHUNKCHUNK when I boot memtest
<dholbach> mine didnt
<mvo> Kamion: nice way to describe the sound :)
<bddebian> hehe
<bddebian> That's what my HD sounded like last night before it died completely :'-(
<zyga> Kamion: lol :'-)
<johnm> Kamion: freeloading tray, or a laptop tray? Thats normally unbalanced cd's or some such
<Kamion> johnm: no, the disc is fine and boots normally otherwise
<Kamion> tray's fine too
<johnm> Kamion: btw.. gold star for the sound->text :)
<johnm> Kamion: I blame electromagnetic solar interference.
* mvo goes to get some food
<zyga> mvo: back so soon?
<mvo> zyga: nah, just needed to switch network connection
<Kamion> it's printing 8000 repeatedly for me on amd64/install
<dholbach> i had 0104 on all amd64 disks and 4000 on all i386 disks
* mvo rsyncs the dvd
<dholbach> mvo was lucky, he even got a "Loading" test
<dholbach> text
<j^> arg, x cashes again after suspend
<j^> XV
<j^> i830m
<j^> it did not do this for some time now
<j^> could this be a regression in 6.8.2-77
<pitti> mvo: got thrown out again, but in case you said something: I recovered the log now (forgot to umount last time)
<mvo> pitti: ok, I rebooted since then
<bslima> launchpad.net is down ?
<jdub> bslima: looks ok here
<bslima> trying to Save & Continue in translation and all i get is Programming Error
<infinity> Argh.
<Kamion> bslima: #launchpad would be a better place to ask about that
<infinity> So, am I the only person who's noticed that hibernate just plai ndoesn't work anymore?
<jbailey> infinity: WFM
<infinity> jbailey : Did you try on a fresh install?
<jbailey> From abvout a week ago
<infinity> I get "reading image ... done" <random junk> "suspend= needs to be in your command line"... And yes, it IS specified in initramfs.conf, and yes I regenerated my initrd and tried again, for paranoia's sake.
<infinity> Try with today's image.  Humour me.
* Kamion reads memtest86+/FAQ
<Kamion> Unpack the file
<Kamion>     from the package and rename it to an 8.3 filename with an extension other
<Kamion>     than .bin
<Kamion> oh, bugger
* Kamion bets that's the problem
<dholbach> did the file name change in the meantime?
<dholbach> (because as you said... it used to work)
<Kamion> I changed it a while back to fix isolinux problems, but I think it always had .bin
<Kamion> however, not sure, and it's worth pursuing
<infinity> jbailey : Interestingly enough, on my "ripe" installation, it doesn't work anymore either (though it used to), so it's not just new installs.
<Kamion> if s/\.bin// fixes it, I can do that very quickly in debian-cd
<dholbach> cool
<infinity> s/\.bin/\.tst/ or something.
<infinity> If it really wants the .3
<Kamion> nah, the FAQ suggests dropping the extension altogether
<infinity> Kamion : What editor is invoked in the "edit sources.list by hand" step in expert?
<mvo> infinity: it's vim, but the bug about it is known
<infinity> Kamion : Whatever it is (well, it was /usr/bin/editor, apparently, but not sure what that would really be), it looked vi-like, and it also didn't work.
<ivoks> jdub: ping
<infinity> mvo : Oh, okay.  Cool.
<infinity> I had to kill it, use nano, then run apt-get update in the chroot.
<infinity> \o/
<mvo> infinity: I noticed it a bit earlier, don't have the bugnumer in scrollback anymore, sorry
<infinity> I assume vim + boglterm = death?
<jdub> ivoks: pong
<ivoks> jdub: could you, please, add me to planet? :)
<infinity> Well, other than known bugs, then, my only bug is hibernate.  I should look into that and see if it's simple breakage, or something to live with for 6 months.
<jdub> ivoks: you're in the config, but it hasn't been updated
<infinity> mvo : Did you test hibernate on any of your installs?
<ivoks> jdub: ?
<mvo> infinity: no, doing that now
<ivoks> hm..
<jdub> ivoks: hrm, actually, no you're not
<ivoks> :)
<jdub> and i can't see an email with a planet addition requesti from you
<infinity> If it's only failing on my laptop, that'd be some kinda special.
<infinity> But I can also deal.
<ivoks> jdub: i didn't send any request
<jdub> ivoks: aha, there you go
<ivoks> jdub: i talked only with you about that
<jdub> ivoks: please send your feed url to me via email
<ivoks> ok
<dholbach> did anyone try amd64-dvd-install yet?
* mvo still waits for the rsync
<mvo> infinity: works here 
<doko> dholbach: yes, life works fine, install as well
<mvo> infinity: on my i386 test-system at least
<dholbach> doko: ok, then it was just a bad burn, it broke spectactularly for me
<infinity> mvo : PATA, SCSI, or SATA?
<infinity> mvo : I suspect it may only be broken (again) on SATA.
<mvo> infinity: PATA, I have a SATA system here to test (but it sync the amd64 dvd right now, so I have to test later)
<mjg59> Hang on, just let me get grub back on this system
<jbailey> I always find the "failed to initialize HAL!" message a bit disturbing.
<Kamion> dholbach, mvo: memtest86+ fixed; thanks for the report
<jdub> Kamion: chance of seeing you at the formal hall tonight, score from 1 to 10?
<pitti> jbailey: when did yo see this?
<mjg59> jdub: 0
<dholbach> Kamion: de rien
<Kamion> jdub: meeting you at the pub afterwards
<mjg59> But he'll be along later
<jbailey> pitti: A couple seconds ago on an i386 live CD
<jdub> Kamion: ok, rad.
<jbailey> pitti: It's still on my screen, I was just digging for the install report instructions.
<pitti> jbailey: hm, WFM - can you please try to run "sudo hald --verbose=yes --daemon=no" to find where it crashes?
<Kamion> jbailey: just on a hunch, can you check that /sbin/start-stop-daemon isn't the dummy version?
<pitti> jbailey: maybe it also was never started in the first place
<Kamion> I saw that the other day and still don't know quite why, but it might have been an artifact of other problems
<bddebian> Hey what is sabdfl doing sending out an e-mail to vote for mjg59 when we can't even do it yet.. :-)
<jbailey> Kamion: It seems to be a binary file.  Is the dummy one a shell script?  Otherwise, how do I tell?
<Kamion> jbailey: it's not the dummy one then
<Kamion> yes, the dummy one is a shell script
<pitti> bah, brb
<jbailey> pitti: I did see a /dev/mem permission denied fly past.
<infinity> mvo : Alright, mjg59 can't reproduce it either, so I'm going to assume I'm just special, and investigate it post-release.
<infinity> mvo : Weird corner-case "only Adam is affected" bugs hardly seem critical.
<bddebian> infinity: You are definetly special ;-P
<Kamion> come back, pitti, I want to talk to you
<whiprush> jdub: chief refrigeration engineer!!
<mjg59> Ooh, it's raining
<whiprush> jdub: i'd like to run the stars of the universe tonite. but i can't for the life of me figure out how to inline screenshots.
<bddebian> Stars of the Universe?
<whiprush> just an overview of cool stuff in universe
<whiprush> for the fridge
<bddebian> Ahh, cool
<dholbach> and cool people in universe :)
<jdub> whiprush: can't do atm, other than using <a>
<bddebian> Oh so \sh, slomo, dholbach, ajmitch, etc :-)
<whiprush> k
<dholbach> bddebian: and you
<bddebian> pfft
<whiprush> jdub: would you be opposed to putting that story on the wiki then and just linking it? It kind of really needs screenshots.
<pitti> jbailey: /dev/mem should be inaccessible to hal, that's fine
<pitti> jbailey: did the hal process stop or did it stay running?
<jbailey> pitti: It stayes running.  I hit C-c, though to clear away the terminal
<Kamion> pitti: right, so apparently you answered "yes" to the "Add another apt source" question, when the default is "no"
<Kamion> the bug appears to only trigger in that circumstance
<pitti> Kamion: yes, right
<pitti> Kamion: but default install does add network sources - it does that differently?
<Kamion> pitti: yeah
<pitti> jbailey: hm, so it is unlikely that it died when it was called by dbus at boot
<Kamion> it's a fabbione special
<jbailey> pitti: Anything I can do to check it?
<Kamion> we're ditching the current apt-setup and moving to a version specially written for use in d-i in dapper
<Kamion> until then I think we'll just live with it - it's too complex to fix in a rush :(
<pitti> jbailey: on the live CD it's hard since you can't alter the boot sequence
<pitti> Kamion: I agree
<pitti> Kamion: but at least we know the reason now
<jbailey> pitti: Does it use initramfs?  Can I issue a break to stop in that and climb in somehow?
<pitti> jbailey: I doubt; dbus is started from normal init script, and hal from dbus
<pitti> jbailey: at boot you could watch out for the dbus and hal messge, though
<mdz> morning
<Kamion> pitti: yep, glad about that
<dholbach> morning matt
<Kamion> pitti: just this powerpc oo.o2-help issue now
<mdz> how do we look?
<Kamion> mdz: what I just said to pitti, basically
<fabbione> mdz: pretty good
<mdz> Kamion: what's the issue?
<Kamion> oo.o2-help-en-us isn't getting installed on powerpc, as yet undiagnosed
<Kamion> I'm about to boot and try it out
<ogra> morning mdz 
<pitti> Hi mdz
<seb128> hi mdz
<pitti> Kamion: actually, language-support-en is not installed
<Kamion> mdz: other than that, not bad - rebuilt livefses for acpi-support and ia32-libs bugs, everything else deferred unless it can be fixed easily in CD builds
<Kamion> mdz: dholbach and mvo caught a broken memtest installation on the CD, fixed
<pitti> mdz: we updated the BreezyTestPlan page eagerly
<mdz> I asked for a phone call if showstoppers were found
<pitti> darn, brb
<fabbione> mdz: https://wiki.ubuntu.com/BreezyTestPlanServer <-
<dholbach> fabbione, Kamion: installed nicely on amd64, just doing some basic testing 
<Kamion> mdz: I'm sorry, I clearly missed that in scrollback :-(
<Kamion> also, CONF.sh still said Release Candidate at last build (updated now) and dists/breezy/Release needs to say "Ubuntu Breezy 5.10" likewise before final builds
<mdz> Kamion: you weren't up yet, but fabbione and pitti certainly were
<fabbione> mdz: yes, but it's all undercontrol and the OO2 is fixed already. it only needs propagation
<fabbione> mdz: so it's not so bad as it seems.. instead the tests look pretty good
<Kamion> er, it is? the ia32-libs fix only affects amd64; pitti reported lots of failures on powerpc
<mdz> fabbione: yes, but it was a showstopper and I was explicit
<fabbione> oh ppc..
<fabbione> Kamion: missed the ppc bit...
<mdz> ubuntu-desktop on powerpc doesn't depend on language-support-en either
<Kamion> and so it shouldn't
<Kamion> base-config installs l-s-* separately
<mdz> ah, yes, only live
<mdz> I thought we just added that to desktop ages ago
<Kamion> nah, I made archive-copier/base-config always install en
<jdub> mdz: good luck
<Kamion> I'm trying to reproduce the failure now
<mdz> the oo.o2 help seems to work fine in my powerpc install from last night
<Kamion> hmm
<mdz> which was a plain english/us install
<pitti> mdz: hm, then I did something different - did you install with network?
<Kamion> pitti: was this a German install?
<pitti> Kamion: yes, German without net
<Kamion> pitti: please mention these little details
* Kamion reboots
<pitti> ok, sorry
<mdz> pitti: that one had network, I believe
<Kamion> it'll certainly only affect non-networked installs
<mdz> pitti: so it's language-support-de which was missing?
<Kamion> well, likely
<pitti> mdz: no, -en
<pitti> mdz: -de is not on the CDs, and not essential
<pitti> mdz: but l-support-en depends on ooo-help-en-us, which makes ooo help work
<pitti> after installing it manually, it worked fine
<mdz> pitti: oo.o2-help-de should make it work, too, of course
<pitti> right
<Kamion> it's possible language-support-de was out of date on de.archive.ubuntu.com at the time of the install
<pitti> mdz: l-support-en and the help package are even on the CD, jsut not installed
<Kamion> that explains oo.o2-help-de not being there, but not oo.o2-help-en-us
<pitti> Kamion: btw, we talk about -en, which is on the CD (just to make sure)
<Kamion> oh, of course, non-networked, so it won't have been able to grab -de
<Kamion> pitti: yep
<pitti> yes
<fabbione> Kamion: could it be that base-config doesn't attempt -en if -de is to be installed?
<Kamion> I don't think this is a showstopper, as described
<Kamion> but I'll test it to make sure
<fabbione> Kamion: see. i was right.. ppc was ok :P
<Kamion> fabbione: anything's possible, but that's not what the code's supposed to do ...
<bddebian> Hey folks, I don't know if it's an issue or not but last night I was re-installing on my thinkpad and my install died (bad CD I think) so I tried to update manually and metacity and thunderbird want to remove themselves but fail on postrm
<pitti> well, installation without network should work
<Kamion> pitti: I'm not disagreeing it's a bug
<infinity> bddebian : postrm bugs aren't particularly release critical at this stage, but filing bugs never hurt anyone.
<bddebian> infinity: OK, thx
<bddebian> Except that I can't get the damn things to remove even with --force
<infinity> No amount of forcing will fix a broken postrm, only editing /var/lib/dpkg/info/${package}.postrm will do it for you.
<bddebian> Doh
<infinity> But, odds are, you're in a special case group where "it broken because other stuff broke first"
<bddebian> Aye
<bob2> unless it's dpkg --force-dont-run-maintainer-scripts or whatever it is
<Lathiat> dpkg could dow ith an option not to run postrm
<Lathiat> or prerm, etc
<infinity> Anyhow, file a bug with the output and wtf appears to be wrong, postrm shouldn't fail even if the package is hideously broken, so it's a bug, just not a critical one.
<bddebian> Lathiat: So fix it ;-)
<Riddell> there's a lot of kernel output messages on these CDs.  I'm sure that didn't happen in breezy
<Riddell> in hoary rather
<bddebian> infinity: Will do when I get home, I can't get to the machine from work since I couldn't install ssh because of it :-)
<Kamion> You can certainly install packages even in the presence of a broken postrm. You might have to resort to dpkg rather than apt.
<Kamion> pitti: could you 'echo GET localechooser/supported-locales' on the system that failed to install language-support-en, please?
<fabbione> Riddell: if you are referring to the [$lotsofnumbers]  it's wanted and on purpose
<pitti> Kamion: hm, I only saved the log files from that system; I need to reinstall it (takes ~ 45 minutes)
<Riddell> fabbione: what's the purpose?
<Kamion> pitti: does that include /var/log/installer/cdebconf/?
<Kamion> pitti: if so, questions.dat from there will do fine
<pitti> Kamion: yes
<fabbione> Riddell: be able to trace async kernel events that leads to crash and track it back to the real order of events.
<fabbione> Riddell: and no.. it's not a boot option
<Simza> hi fabbione :)
<Simza> you're joining us harer, aren't you`http://www.montrealcam.com/en-biodome.html
<pitti> Kamion: http://people.ubuntu.com/~pitti/shots/questions.dat
<bddebian> Kamion: Aye, it was 1:00am so I wasn't thinking well :-(
<fabbione> Simza: hey
<Simza> hm, when did I reconnect..
<Riddell> fabbione: ok, sounds useful :)
<Kamion> pitti: hm, looks fine
<pitti> Kamion: I said "no" to "download language support", but I thought that only referred to l-support-de
<fabbione> Simira: i  guess so... 
<Kamion> pitti: ah, now the penny drops
<Kamion> pitti: that's the bug - saying no there affects -en too
<pitti> Kamion: aah
<fabbione> pitti: TADADA
<Kamion> pitti: if you answer yes, it should be harmless (install won't break due to that just because you have no network, AFAIK) and you'll get l-s-en
<Kamion> definitely a bug, but not a showstopper because there's a workaround
<pitti> Kamion: ok, since it said "download" I always said "no" since I can't download
<pitti> alright, great
<pitti> so if we get the new ia32-libs, everything should be fine? or are there any open issues left?
<pitti> I assume we can't fix hwdb-client 
<Kamion> yeah; perhaps we should have just put oo.o2-help-en-us in desktop since it's more essential than the rest of language support
<Kamion> but too late now
<Kamion> I know of no other open issues, beyond the need for a CD rebuild in about ten minutes to fix the labelling
<ogra> pitti, in oem mode ? i didnt even know it had a versio there
<Kamion> ogra: the OEM installer's "system test" is hwdb-client
<ogra> oh
<Kamion> seemed about as good as anything else
<Kamion> pitti: what's the hwdb-client problem?
<pitti> Kamion: sound test is broken, and network test hangs when there is no network
<ogra> do you have fping in this mode ? it uses fping to get the replys
<Kamion> pitti: bug, but not showstopper
<pitti> but in the latter case you can kill the X server to continue
<pitti> right
<Kamion> ogra: we install hwdb-client and its dependencies
<pitti> ogra: hwdb sound check works fine in normal system - what do you use? aplay?
<ogra> else i'm not sure why it shows the network test at all, since it should skip it if no defaultroute is available
<ogra> pitti, a gnome function...
<pitti> ... which in turn uses esd maybe?
<Kamion> ogra: GNOME isn't started at this point
<Kamion> we just fire up hwdb-client in a custom display manager
<ogra> pitti, which in turn uses what gnome uses
<pitti> ogra: ok, that explains it - maybe use aplay then?
<ogra> Kamion, ahh, that explains it..
<ogra> is aplay always available ? 
<Kamion> ogra: if you need something, depend on it ...
<pitti> ogra: should be
<Kamion> anyway, this is all post-breezy
<ogra> Kamion, i depend on python-gnome2 iirc
<mdz> Kamion: if we're going to rebuild anyway, is there a safe fix for the l-s-en issue?
<pitti> mdz: we could seed l-s-en to the desktop seed, no?
<pitti> erm, maybe only ooo help
<mdz> pitti: we could, but that's intrusive
<pitti> otherwise, let's just forget about it
<Kamion> mdz: everything that doesn't touch desktop that I can think of carries a risk of breaking server installs
<Kamion> server installs preseed that archive-copier question to make sure language-support-* isn't installed
<mdz> so this affects non-English, non-networked installs? or all non-networked installs?
<Kamion> all non-networked installs where you answer "no" to that question
<Kamion> (the default is "yes")
<Kamion> oh, in fact, that means only non-English installs, because that question isn't shown in English installs
<pitti> for dapper, it should not offer the question in the first place when installing without network
<Kamion> we can't reword the question because it's translated and shown in all non-English installs
<fabbione> Kamion: isn't possible to just hide the question?
<pitti> but that's not too bad for breezy now IMHO
<mdz> Kamion: what's the text of the question?
<Kamion> fabbione: no, the question is there because it downloads lots of stuff, and if you're doing only two or three installs at the same time it really canes your network
<Kamion> _Description: Download language support?
<Kamion>  The installation CD does not contain full support for your language. Do you
<Kamion>  want to download the required packages from the Internet?
<Kamion> it's been there since hoary
<mdz> and it asks this question even if no Internet connection is available?
<pitti> yes
<Kamion> yes, archive-copier doesn't know
<pitti> that's why I said "no" in the first place
<Kamion> and the first-stage network might be broken
<Kamion> (e.g. ath0)
<mdz> the natural response will be to say no if the network is unavailable
<Kamion> I'm trying to think of a safe fix
<pitti> Kamion: would seeding ooo-help-en-us to desktop be too intrusive?
<mdz> I thought l-s-en was part of desktop
<Kamion> pitti: well, mdz said above that it was
<Kamion> that's certainly the safest fix
<mdz> pitti: it also doesn't solve the problem
<mdz> it's language-support-en which is missing
<mdz> that contains other important English stuff
<Kamion> yeah, it solves the most obvious manifestation though
<pitti> mdz: but non-english installs won't miss them
<pitti> mdz: l-support-en does not need to be installed by default on non-english systems in the first place (I always kill it)
<mdz> what's the post-install workaround?  can this be corrected with language-selector?
<Kamion> I can possibly hack base-config and debian-cd in tandem
<pitti> mdz: if you select English input help in l-selector, it should work (as any other language should, too)
<Kamion> fwiw, the underlying bug has I think been there since hoary
<mdz> that's easy enough to test
<mdz> pitti: could you repeat your test with hoary and verify?
<pitti> mdz: sure
<mdz> if it's a hoary bug that no one has reported in 6 months then it's not a  showstopper
<mdz> it may not be anyway, but it certainly is a wart
<Kamion> mdz: hmm, one safe fix would be to munge the Ubuntu preseed file to install language-support-en with desktop
<Kamion> possibly Kubuntu and Edubuntu too, but inclined to leave those alone if we can't test them in time
<Riddell> I can test
<Kamion> that will be faster, too, since it doesn't require an upload
<Kamion> hm, although Ubuntu proper doesn't actually have a preseed file right now; it would be better to upload base-config with a new default
<Kamion> (less intrusive to people doing custom work)
<pitti> Kamion: can I test this with hoary without doing a full install? it lasts forever on an iBook
<mdz> Kamion: meanwhile, let's build final live CDs
<Kamion> pitti: not any easy way I can think of
<pitti> ok
<Kamion> mdz: building
<fabbione> pitti: isn't that bug reproducible on all arches given no-net and no-english install? if so you can use anything else than ppc :)
<Kamion> right
<pitti> ok, I use amd64
<pitti> but I have to log off IRC then
<pitti> cu later
<bddebian> OK, I have no patience for installing on a PIII 550Mhz.. :-)
* jbailey gives up on OOo2 ever loading on this livecd and reboots.  Pentium 3 600 is just too slow for this.
<bddebian> jbailey: Tell me about it :-)
<Kamion>  Template: base-config/package-selection
<Kamion>  Type: string
<Kamion> -Default: ~tubuntu-standard|~tubuntu-desktop
<Kamion> +Default: ~tubuntu-standard|~tubuntu-desktop|language-support-en
<Kamion>  Description: preseeded set of packages to install
<Kamion> mdz: ^--
<mdz> Kamion: any new failure modes you can think of?
<spayne> jbailey: don't waste you life - it will take most of it :)
<Kamion> Riddell: to test with Kubuntu, do a normal install (without net and answering no to that question) and, just before you reboot, edit /var/log/debconf-seed and change '~tkubuntu-standard|~tkubuntu-desktop' to '~tkubuntu-standard|~tkubuntu-desktop|language-support-en'
<Kamion> mdz: if language-support-en isn't installable, none of the standard or desktop system will get installed
<Kamion> mdz: oh, and the progress bar will jump a bit, probably
<Kamion> (because language-support-en will take zero time to install the second time round ...)
<mdz> I'm leaning toward leaving it alone at this point
<mdz> I'm not sure we have time for another round if something goes wrong
<mdz> we already need to roll a full set of CDs and DVDs and test them all
<mdz> we don't do edubuntu DVDs, right?
<ogra> mdz, we do
<Kamion> mdz: before doing any CD builds, please remove mcmurdo.ubuntu.com from ~/.ssh/known_hosts and 'ssh mcmurdo.ubuntu.com', ctrl-c'ing the password prompt
<ogra> its essential
<Kamion> I've done that for myself and cdimage
<mdz> Kamion: done
<ogra> mdz, the CD had only space for -en ... kde langpacks are awfully big (15Mb and more) 
<mjg59> Craptop works.
<Kamion> mdz: that's my slight inclination too
<bddebian> Craptop?
<mdz> ogra: we barely have support for non-english languages on the ubuntu CD
<Kamion> at least we know the failure mode here, and it's not *that* bad
<ogra> mdz, yes, thats why a edubuntu DVD is important for people without internet access
<mdz> ogra: they can only be essential if you can actually test them
<ogra> my DVD writer is broken... let me see if i can get a new one until tomorrow... i'll download the DVD iso in any case
<Kamion> if you can't test it, find somebody you trust to delegate it to
<ogra> yup
* fabbione needs some food
<dholbach> me too
<dholbach> and i'll get a bunch of new DVDs (as i take it, i'll need them)
<mdz> dholbach: I bought 10 DVD+RW  and they have lasted the entire lifetime of Ubuntu
<dholbach> mdz: i got CD+RW, but didnt manage to get hold of DVD+RWs, so i burned away all my DVD+Rs
<ogra> dholbach, i have 10 lying around... come over and pick them up :P
<dholbach> anyway, i'll be off to get some and get some food as well, brb
* Lathiat finds that CDs, at 20c each are a much better option that cdrws at $1+ each and having to wait *ages* for them to erase
<ogra> mine erase quite well...
<jbailey> Lathiat: Occasional stretch breaks are good. =)
<ogra> and i use the same media since hoary for hoary, breezy and edubuntu testing
<Lathiat> jbailey: heh
<segfault> kamion: the second stage of installation is not translated to pt_BR, but those strings were translated in Rosetta
<Kamion> segfault: those strings are not subject to language packs and need to be imported into the apt package
<Kamion> segfault: I do not know what translations were imported before release
<segfault> i sent to mvo, iirc
<Keybuk> I just bought 200 CD-Rs instead, for about 10p
<ogra> mdz, have you seen ThinClientHowto ? it has some weird additions 
<mdz> ogra: no
<ogra> editing hosts.allow etc...
<mvo> segfault: I probably only imported them into rosetta 
<segfault> mvo: :(
<mvo> IIRC thery where after the non-langpack translation freeze, sorry :/
<ogra> mdz, and wasnt a hint to run ltsp-update-sshkeys in there before (in case the key isnt populated to the chroot) ? 
<segfault> mvo: you said i had one day, heh
<Kamion> segfault: I'm afraid it definitely wasn't updated in the package
<Kamion> it is too late to fix it now for breezy
<mdz> ogra: no, ltsp-update-sshkeys is automatically run by -build-client
<mvo> segfault: wasn't that the mail with the missing attachment ;) ?
<ogra> mdz, i know, but i thought there was a sentence before...
<jbailey> pitti: hal error didn't reproduce on reboot.
<mvo> (or am I confusing you now with someone else)
* ogra looks at the doc histroy
<Kamion> mdz: daily-live updated
<pitti> mdz, Kamion: ok, install finished
<segfault> mvo: yeah, that with missing attach i sent 27/09, then i sent another one in 28/09
* Kamion rebuilds install CDs
<pitti> mdz, Kamion: l-support-en is not installed either, but OO.o help WORKS
<Kamion> pitti: hoary?
<pitti> mdz, Kamion: (with hoary/amd64 networkless no download)
<segfault> and the nonlangpack freeze was in 29/09
<Kamion> OO.o help was naturally handled in a completely different way in hoary
<pitti> right, probably integrated into the main packages, or so
<pitti> doko might know it
<mvo> segfault: sorry, it looks like it got lost then. it is part of the installed system though (through rosetta)
<Kamion> segfault: if this had been reported after the release candidate (when we'd fixed things not to strip translations from apt), it's possible we could have fixed it; it's too late now, I'm afraid
<pitti> mdz, Kamion: hmm, looking closer: the help browser works, but you do need to install the help packages to make use of it; sorry, didn't look close enough at first
<mdz> Kamion: we can live with the l-s-en bug; let's get install CDs and DVDs going
<pitti> mdz, Kamion: so no regression
<segfault> humm, no problem then
<Kamion> mdz: they're going
<doko> pitti: ?
<mdz> Kamion: thanks
<Keybuk> all passes on i386 for me, and with netboot
<Kamion> Keybuk: cool, we've been light on pre-release netboot testing
<pitti> doko: nevermind
<Kamion> I did a Kickstart test the other day to make sure that still worked
<Keybuk> Kamion: I always make sure I do, as it's the only way to install stuff on my laptop
<Keybuk> X config still fails on my desktop, but I'm getting increasingly convinced it's a card fault
<Keybuk> as the ATI fglrx driver doesn't think there's any monitors connected!
<ivoks> maybe it's keyboard? :)
<ivoks> kickstart has some issues when there allready are some partitions
<ivoks> installation freezes when one trys to run manual partitioning
<mdz> Kamion: fabbione traditionally does netboot testing
<bddebian> Damn, I can't catch a break.  Now this machine at work hangs trying to configure xorg... :'-(
<Kamion> ivoks: doesn't surprise me; interaction during a Kickstart install can be tricky, particularly in partman
<ivoks> yup :/
<ivoks> i tried interactive since non-interactive didn't work :)
<ivoks> Kamion: but appart that, kickstart works great with netboot
<ivoks> i did 60 clients install in one day with it
<fabbione> mdz: it's already tested for i386 (see wiki)
<fabbione> Kamion: 99% of my installs are done via netboot
<fabbione> Kamion: only at release i fire up CD's
<Kamion> ivoks: cool
<ivoks> Kamion: only thing that needs love is ldap auth after install :)
<seb128> fabbione: where are the netinstall files?
<fabbione> seb128: http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/20050317ubuntu19/images/netboot/
<fabbione> change $arch as required
<seb128> fabbione: thanks
<fabbione> np
<Keybuk> seb128: make sure you have tftpd-hpa installed
<Keybuk> not the ordinary tftpd, it doesn't work for netboot
<fabbione> and you also need a proper dhcpd config
<fabbione> otherwise it's foobar
<seb128> Keybuk: k
<Keybuk> yeah, untar the netboot tarball, and stick "next-server blah; filename pxelinux.0;" in the config for your dhcp
<Keybuk> (where blah is your tftp server)
<fabbione> Keybuk: yeah i just pasted him the config snippet
<ivoks> there is one great howto
<ivoks> http://wiki.koeln.ccc.de/index.php/Ubuntu_PXE_Install
<Keybuk> you can get a bit used to netbooting though :p  I actually seed a couple of extra keybuk-* packages into it, which automatically pull stuff I always want and have postinsts to configure shit :p
<Keybuk> so if I netboot my laptop, once it's done, it already has all the packages I want installed and is ready for me to drop in my home directory
<fabbione> Keybuk: that's more or less what i do :)
<ivoks> Keybuk: hehe i did script that does that for me :)
<Keybuk> keybuk-launchpad-devel is a scary package, it rewrites postgresql config and stuff :p
<ivoks> installs new kernel, compiles openmosix tools, sets up ldap auth, etc :)
<jbailey> The ppc64 live test that's wanted is just hte ppc image on a ppc64 box, yes?
<jbailey> I don't see a separate ppc64 image.
<mdz> i386/live, powerpc/live, amd64/live OK here
<fabbione> jbailey: there should be a ppc64 kernel on it
<mdz> jbailey: yes
<mdz> jbailey: as fabbione says
<Kamion> jbailey: boot with live-powerpc64
<mdz> BenC also has ppc64 I believe; has anyone seen him?
<jbailey> 'k, thanks.
<ogra> janimo, you added ubuntu-express to your metapackage ??
<Kamion> it's in ubuntu/live too
<ogra> heh
<ogra> feels a bit like overhead :)
<mdz> Kamion: live CDs are OK here; ping me once there are install CDs to sync
<Lenhador> Hi! I'm trying to install an "user script" on Greasemonkey/Firefox, on Hoary, but my Firefox break with "segmentation fault"... what's happen?
<Lenhador> how I fix it?
<janimo> ogra, I don't bu tI see it's there in both kubuntu/ubuntu
<janimo> maybe it's a diffrenece that they are doen on the server?
<janimo> I just run update locally
<janimo> and d onot use germinate
<janimo> ogra, I thought ubuntu-express was postponed so I am suprised to see it there
<ogra> yes, and the package you have in there is pretty useless... more a proof of concept than a program
<ogra> janimo, nice that you pulled xscreensaver in, make sure it gets started in xfsession ... in a sidenote, i tried xubuntu on edubuntu yesterday, its really slick :)
<Kamion> janimo: did you adjust the seed URL in update to point to your modified seeds?
<Kamion> look for http://people.ubuntu.com/~cjwatson/seeds/
<pitti> why do we disable power management now by default?
<mdz> pitti: why do we what?
<pitti> mdz: I just dist-upgraded, and the new acpi-support disabled power management
<ogra> mdz, laptop mode disabled ? 
<mdz> pitti: what do you mean by 'power management' in this context?
<pitti> mdz: well, the package just said so
<pitti>  * Disabling power management.
<pitti> I'm sure it is intended, I'm just curious about the reason
<elvirolo> hi all
<ogra> mdz, http://bugzilla.ubuntu.com/show_bug.cgi?id=6108
<ogra> pitti, ^^^
<mdz> ogra: I am familiar with that bug, yes
<ogra> thats what was talked about before today in this channel
<mdz> pitti: at what point does it print that message?
<pitti> ah, thanks
<pitti> mdz: after package installation (postinst, I assume)
<pitti> oh, no, preinst
<mdz> pitti: that is the message from the 'stop' action of the init script
<infinity> pitti : Just edit /etc/default/acpi-support and enable laptop-mode, if you know it works for you.
<mdz> nothing to do with 6108 or laptop-mode
<infinity> It breaks for too many people to have it on by default.
<ogra> mdz, 
<ogra>    * Add some extra machines to the whitelists
<mdz> <mdz> nothing to do with 6108 or laptop-mode
<ogra>    * Depend on powermgmt-base
<ogra>    * Disable restarting irda services by default
<ogra>    * Disable laptop-mode by default
<mdz> ogra: that has nothing to do with pitti's question or the message he saw
<elvirolo> does anyone know whether the spca5xx bug has been fixed in the last update or not ?
<mdz> ogra: trust me, I do read breezy-changes
<infinity> Oh, and yes, that message just meant it was stopping/staring on upgrade, I assume.
<ogra> mdz, ah, sorry
<pitti> infinity: yes, it did not start again
<infinity> Neat.
<pitti> infinity: so that's the new intended default; fine
<mdz> pitti: errr
<pitti> I really was just curious
<mdz> pitti: no, you should get 'checking battery state' in postinst
<elvirolo> ideas anyone ?
<pitti> sorry if I caused confusion
<Kamion> elvirolo: no
<mdz> pitti: I do
<mdz> Setting up acpi-support (0.46) ...
<mdz> Installing new version of config file /etc/acpi/power.sh ...
<mdz> Installing new version of config file /etc/acpi/resume.sh ...
<mdz> Installing new version of config file /etc/default/acpi-support ...
<mdz>  * Checking battery state...                                             [ ok ] 
<pitti> me too
<mdz> pitti: the start/stop messages are quite confusing
<pitti> ok
<mdz> since they don't correspond to each other
<janimo> Kamion, I adjusted the seed url to http://localhost/seeds as I have the branch only locally 
<infinity> pitti : Right, that's the (rather unintuitive) output from acpi-support starting.
<elvirolo> Kamion: you don't know or you do know it hasn't been fixed ?
<mdz> elvirolo: the kernel has been frozen for a week now
<Kamion> elvirolo: no, it has not been fixed, and in any case the place for tracking bugs is bugzilla, not polling a development channel
<mdz> elvirolo: it has not and cannot be fixed for 5.10
<elvirolo> OMG, this is an *absolutely critical* bug
<mdz> I don't agree
<pitti> elvirolo: it's not; it just affects a particular piece of hardware
<elvirolo> the complete system *freezes* whenever one tries to access his/her webcam, even sysreq keys don't work
<elvirolo> it would be better to have *no* support for these webcams rather than a system freeze!
<Keybuk> it's not clear that this affects everyone
<fabbione> elvirolo: it's absolutelu not critical
<segfault> I've just finished an installation of x86 20051012 release in pt_BR, everything worked like a charm.
<Keybuk> those it does affect have a simple fix, they can blacklist the module
<elvirolo> and there's aslo the hp printers' bug
<janimo> ogra, yeah xfce is slick but in the current state while better then what we had in hoary there are still rough edges.Many :(
<segfault> besides that segond stage typo
<Kamion> segfault: good, thanks
<pitti> k, gotta leave for a while
<Kamion> segfault: if you could note that on BreezyTestPlan, that'd be good
<pitti> cu later
<elvirolo> many people use hp printers, and many comments have been sent in the bugzilla, but nodoby seems to care
<mdz> elvirolo: see /topic
<ogra> janimo, yes, but its great as a lightweight desktop, i have many requests for this in edubuntu
<elvirolo> ok sorry
<Keybuk> elvirolo: there are always bugs in releases
<mdz> elvirolo: I use an HP printer myself, and it works quite nicely
<Kamion> janimo: ok, well that should work
<ogra> janimo, note that we dont support sound yet in ltsp :) 
<segfault> and some wrong strings inherited after the latest langpack release, there's others relating same stuff in ubuntu-translators
<elvirolo> Keybuk: yes but these have been reported AGES ago
<Kamion> janimo: are you saying that the stuff filled in by update doesn't correspond to your seeds
<Kamion> elvirolo: I have open bugs since before warty
<Kamion> janimo: ?
<elvirolo> well that's very bad
<Keybuk> elvirolo: we don't aim to fix every reported bug within the 6-months; sometimes it takes more than one release to do it
<Kamion> elvirolo: no, it's not
<Keybuk> that's one of the advantages of a 6-monthly release process, if a bug misses a release it's not that long to the next one
<Kamion> elvirolo: don't presume to tell me how I'm performing without having checked what the bugs in question *are*
<elvirolo> well, my printer doesn't work, one of my friends' printer doesn't work ... what am I to say ? I can't use Ubuntu anymore!
<Kamion> they're either less-important or hard
<elvirolo> and she doesn't want to use free software anymore 
<fabbione> elvirolo: do you have patches for this bugs?
<elvirolo> i don't mean to be blaming you, i know you're doing a great job
<janimo> Kamion, sorry was away
<elvirolo> i'm just telling that some things are wrong and are a drawback for ubuntu
* janimo reads backlog
<Keybuk> there will always be bugs
<Kamion> yes, we sadly do not have the resources to fix everything
<mdz> elvirolo: we're working on putting the release together right now; please take this conversation elsewhere or wait until after the release
<mdz> we need to keep this channel clear
<zyga> elvirolo: look at the problem like this
<mdz> all of you, please
<mdz> this is not on-topic right now
<elvirolo> mdz: ok, i'm sorry
<zyga> elvirolo: if there is anyone who can fix this, please - step up
<mdz> I'm happy to discuss it, just not in the middle of release prep
<elvirolo> yeah i understand
<janimo> Kamion, no it corresponds to what I have in the  local baz branch of the breezy seed list (I hope)
<zyga> elvirolo: if not - then releasing another version is good anyway, it fixes lots of other bugs and brings new features
<elvirolo> it's not the right time
<Kamion> janimo: ok, great. sorry I haven't got back to you yet, it's just a nightmare week
<janimo> Kamion, np
<Kamion> you seem to be keeping up by yourself for the moment :-)
<janimo> yes, but I guess I am too late in the game for breezy :(
<Kamion> janimo: your universe change will go in
<ogra> janimo, what i saw yesterday was really ok... 
<dieman> so with this reboot requried information in the info applet, is there any way to glean this information from scripts? (ie: some sort of reboot advised flag?)
<Kamion> janimo: we can see what's doable w.r.t. CD builds later
<Kamion> janimo: note that cdimage is maxed out on the number of derivatives I can support on it, but I'm happy to help you set up CD builds elsewhere later on
<janimo> Kamion, thanks, but the packages are not in the polished state I'd like either
<fabbione> janimo: it's still a very good start for dapper..
<janimo> ogra, I was planning integration with a volume manager, display mgr etc
<janimo> fabbione, thanks
<ogra> janimo, yes, but its a goot first timer to build on... 
<fabbione> janimo: so don't be too upset.. you have time to fix stuff around
<ogra> *good
<janimo> these two past weeks I was working all day but it's too much new stuff for me I guess
<ogra> janimo, edubuntu has probably 70% of the stuff i wanted in... it will get released and attract people to help improve it in dapper... to get more helpinghands, you muist have something to present ;)
<Kamion> mdz: install CDs published; I'll work through the other jobs as time progresses this evening
<dieman> n/m figured out whats there
<mdz> Kamion: shortest job first, please
<janimo> ogra, yes I guess :)
<mdz> Kamion: perhaps for dapper we can work out a sane way to do parallel CD builds
<mdz> the build cycle has become incredibly long
<Kamion> it ought to be doable, it's just a matter of making sure nothing overlaps
<fabbione> or spread it across more machines
<infinity> Is there a reason we can't do CD builds from the buildds like we do with livefs builds?
<Kamion> infinity: LP will do it that way, AFAIK; rejigging it to happen before that is WAB
<infinity> (other than debian-cd currently still requiring a local on-disk mirror, afaik?)
<infinity> Kamion : Ahh.  Right.
<Kamion> infinity: if you're sane, you have an on-disk mirror regardless of whether you're using debian-cd or not
<fabbione> well inside the DC local or not, the access is fast enough not to show much difference imho
<Kamion> CD building is already reasonably careful to use different paths for different projects; install and live builds currently overlap
<infinity> Sure, but having an on-disk ftproot on every buildd is a lot of rsync traffic all over, and a lot of extra disk space required.
<Kamion> fabbione: it's not happening pre-LP, no way
<infinity> Anyhow, off-topic, carry on with your releasing.
<Kamion> fabbione: I think we did the sums and found out it would add an appreciable amount of time (20 minutes or so) to every CD build even at max bandwidth
<Kamion> but, later
<infinity> I need to get some sleep.  I'll have another test cycle in the morning, I assume.
<fabbione> infinity: good night
<dholbach> re
<dholbach> night infinity
<jbailey> The ppc64 livecd works better than my current install, apparently. =)
<mvo> night infinity 
<infinity> Kamion : 20 mins added to each CD build when they're all done in parallel seems a win.
<fabbione> Kamion: yes, that's right, but losing 20 minutes.. as infinity said..
<Kamion> infinity: doing them all in parallel without the extra 20 minutes seems like a bigger win
<infinity> True dat. :)
<jbailey> The only things off were that the keyboard map it detected was wrong jp102 instead of US, so it had the @ in the wrong place, and the CD didn't eject at the end
<jbailey> Aside from that, it has sound from a kernel that I thought had no sound driver for it. =)
<fabbione> jbailey: eheheh
<Kamion> mdz: so basically, I can probably make it use a per-project lock easily enough, so that you can do ubuntu/kubuntu/edubuntu/ubuntu-server builds in parallel; since it's all I/O bound, that should be a nice speedup
<mdz> Kamion: multiple CD build machines might be useful too
<mdz> Kamion: though we'd need to consider how to ensure archive consistency
<mdz> Kamion: what was the ia32-libs problem while I was away?
<Kamion> mdz: libdb4.2 was missing, which openoffice.org2 needed to start the help browser
<doko> mdz: missing libdb4.2
<janimo> Kamion: you wrote earlier but just saw now "janimo: your universe change will go in". You mean xubuntu-related changes in uni after todays release?
<mdz> doko: I could see that much from the changelog :-P
<Kamion> janimo: not after the release, no
<janimo> ok
<Kamion> janimo: I meant the xubuntu-meta upload you made today
<janimo> I see
<Kamion> (openoffice.org2-core Depends: libdb4.2)
<Kamion> we should have an automated way to check this, if multiarch is still some way off
<mdz> yes
<mdz> of course, this is really just fallout from bringing back oo.o2-help at the last minute
<Kamion> right
<mdz> which we won't (need to) do again
<Kamion> yeah, but I wouldn't like to bet money on oo.o2's dependencies never changing again
<janimo> ogra, btw xscreensaver was already in upstream xfce-session so change needed :) .Just need to start with startxfce4 instead of startx
<ogra> janimo, yup...
<janimo> so _no_ change needed
<doko> mdz, Kamion: native builds look better for 2.0, maybe it's worth to evaluate these for dapper
<ogra> as long as it runs and you can click the lock icon its fine :)
<mdz> doko: definitely
<Kamion> doko: oh god yes
<janimo> how long till universe closes?
<Kamion> janimo: answering that encourages people to race the deadline
<janimo> :)
<Kamion> finish off, assume it's closing RSN
<sistpoty> Kamion: will morgues be possible after the deadline?
<ogra> janimo, i'd guess during the day tomorrow ... based on hoary experience
<Kamion> sistpoty: after the deadline, breezy will become untouchable, so no
<sistpoty> k, thx
<ogra> but breezy isnt hoary, so who knows :)
<Kamion> and it's "removals", sheesh. "morgue" is a noun :P
<sistpoty> sorry, no native speaker ;)
<mjg59> elmo: Do you know what time jdub left?
<doko> elmo: is there still to remove zope(2.6) from breezy?
<elmo> mjg59: dunno, if he has - I think he detoured via sabdfl's
<mjg59> Crap. Do you have a phone number for him?
<Kamion> Riddell: final-candidate kubuntu daily-live build published
<Riddell> Kamion: what's the difference?
<Kamion> Riddell: updated acpi-support, ia32-libs
<Kamion> Riddell: fixed memtest boot option on CDs
<Riddell> Kamion: is there a new install CD coming?
<fabbione> it's already out
<Kamion> fabbione: no
<fabbione> oh sorry
<fabbione> Kubuntu
<Kamion> Riddell: yes, it's been building for the last few minutes
<fabbione> never mind
<Riddell> Kamion: ok.  and DVDs coming today?
<Kamion> Riddell: later, but yes
<Kamion> (don't know exactly how much later yet, before you ask ... I expect it to be a long night)
<Riddell> ok :)
<dieman> dieman@runabout:~$ ./machine-needs-reboot
<dieman> 1
<dieman> ok, that was simple enough
<Kamion> Riddell: oh bugger, I forgot to rebuild the live filesystems :-(
<Kamion> Riddell: don't spend too much time on that, I'll do another build later
<Riddell> Kamion: ok
<Kamion> sorry about that, entirely my fault; kubuntu live filesystem builds running now
<zyga> Kamion: to build that faster you can use another boxes on your lan 
<Kamion> zyga: I have no particular interest in keeping multiple cdimage build machines perfectly in sync pre-LP
<zyga> Kamion: all you need is one process running on all those LAN boxes
<zyga> Kamion: create_compressed_fs -l
<Kamion> zyga: I do not control the buildds that do this
<Kamion> I just trigger them remotely
<zyga> ah
<Kamion> zyga: and it's going to be about the live filesystem build time before cdimage is free to do the actual CD build anyway; there's no need to optimise stuff that is not on the critical path
<zyga> building DVDs without this is a real pain unless you've got 8Gs of ram
<mvo> Kamion: but the install/20051012.2 is fine (I'm testing it now)?
<mdz> i386, powerpc and amd64 installs all in progress here
<Kamion> mvo: yes, that's candidate
<Keybuk> 20051012.2 downloading ...
<fabbione> i386 install in phase 1, burning live i386
<fabbione> given no uploads netinstall is still good
* Kamion -> dinner. Sufficient image builds queued up to keep little busy while I'm away, I think.
<mdz> please update BreezyTestPlan for the latest  build when you test
<fabbione> Riddell: ping?
<slomo> elmo: please sync gpass from debian/unstable :)
<Riddell> fabbione: hi
<fabbione> Riddell: it looks like that "login manager" in Kubuntu control panel doesn't work. it asks to push the Administration mode button, you click, you get prompted for a password (the right passewd) and it resets the control like if you have done nothing. You can't change the settings
<fabbione> Riddell: there might more in that status, that was the most obvious one
<Riddell> fabbione: that's a known problem with stikes randomly and malitiously, it's been in KDE for years but seems to happen more often when using sudo
<mvo> mdz: update BreezyTestPlan in what way? clean from the results of older images? 
<fabbione> Riddell: it was working before the upgrade from 3.4.2 to 3.4.3
<mdz> mvo: replace the old entries with your new tests, or add it if there was no previous test in that cell
<Riddell> fabbione: http://bugzilla.ubuntu.com/8681
<mdz> mvo: my amd64/cd/erase install gets a PASS
<mdz> i386 and powerpc are in stage 2
<mvo> mdz: i386/custom partition gets a PASS here too, doing server-install now and burning cds for amd64
<mdz> i386/custom PASS
<mdz> Riddell: any luck with kubuntu install CDs?
<mdz> Kamion: there doesn't appear to be any build in progress on little
<mdz> running an ubuntu dvd build then
<fabbione> i386/erase/standard is go
<mvo> mdz: i386/server/custom is fine here
<fabbione> mvo: ok i am updating the page
<mdz> fabbione: while you're there, my powerpc/erase install is PASS
<mdz> since it takes 4 hours to save the page each time we should batch the updates ;-)
<fabbione> sure no problem :)
<fabbione> ps i am also cleaning up the old tests
<fabbione> the new live is .3 right?
<mvo> fabbione: thanks, I clicked on "save" a moment before you wrote it :)
<seb128> fabbione: don't clean them, let people update them rather
<mdz> Diziet: have you tested the current build yet?
<mdz> fabbione: seb128++, keep the old tests in case we aren't able to repeat them at least we have the old data
<seb128> fabbione: other way you trash the issue before knowing if the new builds fix them for people who had them
<fabbione> seb128: if we don't clean, it gets extremely messy to undestand who did test waht
<fabbione> seb128: the new builds have only 2 bug fixes.. Release Candidate -> //
<\sh> ok...now for the laptop testing and breezy testing
<fabbione> and the ia32-libs
<seb128> still, they don't hurt
<fabbione> seb128: ok i cancelled my edits
<seb128> thanks
<fabbione> seb128: please add i386/CD/erase .2 is ok
<fabbione> seb128: add also what mvo and mdz did
<fabbione> seb128: + i386/livecd is go
<seb128> k
<fabbione> seb128: winfoss from .3 livecd i386 is go
<seb128> you could as well update the wiki instead of listing here, that takes the same time
<seb128> and that would not dup work
<mvo> heh, the problem with the wiki is that it's so painfully slow in saving
<seb128> and you would be sure there is not a com issue
<seb128> anyway, updating
<seb128> seems you are not happy to keep previous linue :)
<fabbione> the page is too messy.. that's why i was cleaning it
<seb128> mvo: yeah
<mvo> how importend is the "ubuntu-server" image?
<seb128> fabbione: easy, let's do a new table for the new set 
<mdz> seb128: good plan
<\sh> elmo: please sync clisp 2.35-2 from debian unstable, thx
<Riddell> mdz: all the kubuntu CDs are working but there's a new install build just done that I'm rsyncing and new live on its way
* fabbione -> dinner
<mdz> Riddell: live is waiting on new livefs builds, no?
<Riddell> mdz: yes, I believe so
<mdz> there was nothing building on little, so I did an ubuntu dvd build
<mdz> once that's finished, kubuntu live should be ready to build
<sistpoty> Riddell: after today's update, kmail lacks of opengpg... says s.th. about gpgme being compiled w.o. opengpg support. my fault or a bug?
<Kamion> mdz: sigh, the command I typed into shell history was ignored when control returned to the shell
<Riddell> sistpoty: a bug
<Kamion> I'm keeping a list of what's done, I'll take it from here
<sistpoty> Riddell: already known or should i file one
<Riddell> sistpoty: known, I don't think a bug has been filed though
<\sh> ok..step 1 in installation went without problems 
<sistpoty> Riddell: as in "go ahead file a bug report" or "don't mind, this is being cared for"
<sistpoty> ;)
<seb128> wiki updated, I'm away a few min for dinner
<Riddell> sistpoty: go ahead please
<sistpoty> Riddell: will do, thx
<mvo> seb128: bon appetite
<Kamion> mdz: I'll do edubuntu daily next, since that's more out of date
<jkrogh> About #17636 .. where can I find older Breezy kernel-packages to test with, so I can find the last "usable" kernel? 
<dholbach> jkrogh: you ask that for the 3rd time now, it's not the appropriate place, try in #ubuntu
<jkrogh> Ok, I just thought it was a development issue that the current kernel wont boot on the hardware, that's why I ask here. 
<sistpoty> Riddell: one last question to gpgme-bug, what package? libgpgme11?
<mdz> who tested a server install with 20051012.2?
<mdz> it has my name in the table, but I didn't test that case
<mdz> ah, mvo
<mvo> mdz: yes, that was me
<mdz> fixed
<mvo> mdz: are you editing right now? live/i386 is fine here too
<mdz> jbailey: what was the result of your ppc64 test?
<mdz> mvo: just saved
<mvo> mdz: ok, I'm editing now
<fabbione> i386/liveCD/good on 2nd machine
<mdz> mvo: I think I got the lock
<mdz> mvo: added your test
<mdz> gah, you stole the lock
<jbailey> mdz: Work.  Keyboard misdetection in the installer (filed as a bug), and the CD didn't eject at the end of the live test.
<mvo> mdz: sorry, I'll keep my fingers off it now
<jbailey> I'm just rsync'ing up new images.
<mdz> jbailey: how long did you wait for the eject?  sometimes it takes a long time on powerpc for some reason
<mdz> jbailey: oh, you were testing the old build?
<mdz> jbailey: when you test the new build, update BreezyTestPlan please
<jbailey> Right, it was from my nightly last night 20051012
<jbailey> I just saw that BreezyTestPlan has a new table. =)
<Riddell> sistpoty: kontact
<Riddell> or kmail
<sistpoty> Riddell: thx... will do
<Riddell> thanks
<ogra> mdz, if you have some spare ressources free, i think a edubuntu build is needed too for acpi-support changes...
<ogra> otherwise the current iso is fine...
<sistpoty> Riddell: FYI, i just found out that 17546 is already adressing this ;)
<\sh> hmmm...
<mdz> ogra: Kamion is driving the builds
<mdz> ogra: <Kamion> mdz: I'll do edubuntu daily next, since that's more out of date
<ogra> mdz, ok...
<ogra> ah, fine...
<ogra> i dont expect any regression though
<mdz> ubuntu dvds are almost ready
<mdz> ogra: we are not testing for expected regressions, only for unexpected ones :-)
<ogra> hehe
<ogra> mdz, if you catch them all in ubuntu and i know all my edubuntu specific issues, whats left  ? 
<mdz> ogra: installation and live CD testing
<Kamion> random weird shit
<fabbione> ogra: moon rays hitting little while building CD
<ogra> i just wanted to say no need to put me on high priority with edubuntu :)
<Kamion> we rather hope nothing will go wrong with any of these builds
<mdz> edubuntu needs to be tested in order to release on time
<ogra> yes, but i cant chage contents, so worst case i'll have a new build if its littles fault
<Kamion> ogra: still needs to happen sooner rather than later
<ogra> mdz, sure thats what i'm doing over here... beside fixing merged wikipages
<apokryphos> a lot of people have been asking if there's an exact time of breezy release so they can organise/arrange events accordingly; is there one?
<mdz> apokryphos: no, there isn't
<apokryphos> ok thanks
<mdz> apokryphos: we could set one late in the day, but I prefer to release as soon as we're satisfied with it, rather than hold it until a scheduled release time
<apokryphos> definitely; keep them on their toes 8)
<mdz> DVD candidates mirroring now
<mdz> Kamion: little is all yours
<Kamion> ok, let me queue up a batch of stuff
<Kamion> cdimage@little:~$ for-project edubuntu cron.daily; for-project kubuntu cron.daily-live; for-project ubuntu-server cron.daily; for-project kubuntu cron.dvd; for-project edubuntu cron.dvd
<Kamion> that should keep her busy for a while
<Kamion> after that it's just non-release stuff like ports and livecd-base left from the crontab
* ogra never noticed little was female :)
* mvo reboots. brb
<mdz> ubuntu DVDs are up; get 'em while they're hot
<mdz> latest candidate 20051012
<Lathiat> i would if it wouldnt eat half my months quota :\
<LaserJock> elmo, I would like to request a sync of dvi2ps and wterm from Debian (allowed by \sh)
<\sh> lamont__ / infinity: could you take a look at http://people.ubuntu.com/~lamont/buildLogs/c/clisp/1:2.35-2/clisp_1:2.35-2_20051012-2010-i386-failed.gz and tell me, why this is not happening in my pbuilder?
<\sh> this message "Add -falign-functions=4 to CFLAGS in the Makefile." I never saw in my pbuilder...:(
<mvo> doko: amd64 is fine, OO.o help works too now, good work!
<mvo> dholbach: please add me to amd64-live (I see you have the lock)
<dholbach> Kamion: memtest works nicely :)
<seb128> mvo: first line i386 for me
<seb128> ups
<seb128> dholbach: 
<dholbach> i didnt have the lock any more
<dholbach> but i can type for all of you guys, no problem :)
<smurf> the DVD .torrent for ppc isn't registered correctly with its tracker, and apparently nobody is seeding the bittorrent files yet ?
<dholbach> smurf: i guess it will be done for the announce, right?
<mvo> dholbach: thanks, amd64-live pass for me then :)
<fabamd64live> yadadada
<fabamd64live> can somebody update the wiki please?
<dholbach> mvirkkil: dude, i added that already
<fabamd64live> i need to do winfoss test on amd64
<dholbach> hahaha :)
<fabamd64live> amd64/live/go
<smurf> dholbach: it might make sense to seed them before the announcement, but then I can easily pull the files directly, and do it myself ;-)
<fabamd64live> dholbach: are you going to add it to the wiki please?
<dholbach> yes
<fabamd64live> thanks
<fabamd64live> dholbach, add also the hostname ;)
<dholbach> no :)
<fabamd64live> ahah
<fabamd64live> later
<Kamion> smurf: need to ping an admin (elmo/Znarl) about that; last I checked it wasn't done automatically
<Kamion> we'll do it once everything's built
<elmo> Kamion: torrent should just work when you trigger it
<elmo> that's the theory anyway, but the torrent software is complete crack
<Kamion> oh, a while back you said it was disabled?
<fabbione> hmmm
<smurf> elmo: seems to be working -- the ppc DVD torrent now registered OK
<elmo> Kamion: nah, re-enabled now
<Kamion> hmm, Colony 5 doesn't need to be torrented any more!
<elmo> Kamion: znarl spent a couple of days beating it into shape
<Kamion> ah, cool, thanks
<fabbione> dholbach: winfoss amd64 is go
<Kamion> god, torrent.u.c is just enormously huge
<Kamion> plz write smaller software kthxbye
* fabbione does the last reboot from the CD tests...
<Kamion> we might want to consider stopping torrenting the daily builds
<Kamion> I doubt they get very much seeding
<Kamion> can we get statistics on that?
<ajmitch> morning all
<dholbach> hey andrew
<ajmitch> how's progress on going? scrollback is lookcing promising :)
<Kamion> the bi-weekly DVDs make marginally more sense to torrent
<bddebian> elmo: Thanks for the syncs!  Did atlas-cpp come through as NEW?
<bddebian> Heya ajmitch
<dholbach> wow... french keyboards are really crackful, i'll never install a french server again :-p
<bddebian> heh
* seb128 kicks dholbach
<elvirolo> hey what's wrong with French keyboards :-D ?  !
<dholbach> elvirolo: the keys are all mixed up :)
<elvirolo> dholbach: ah... well ... yeah :-D
<dredg> hah. german keyboards are just plain weird to use
<dredg> really and truly bizarre things
<dholbach> not really
<ogra> nah...
<ogra> if all the world would use them, we'd never have keymap problems again :)
<ogra> and you could type , thats a big advamtage :p
<dredg> using your logic, we should all be using my new and improved alphabet :)
<ogra> s/m/n
<dholbach> dredg: do you type from right to left?
<ogra> dredg, publish it, we might condsider *g*
<dredg> dholbach: no. there's not much difference between an irish keyboard and a uk one
<dredg> i think the euro symbol is the sum total of the differences
* ogra guesses the irish one is a bit greener...
<ajmitch> heh
<dredg> only if you spill things on it and forget to clean it :)
<ogra> bah, i shouldnt chat with such a lack of sleep
<ogra> lol
<ogra> dredg, that can get very hairy...
<dredg> speaking of irish, i must prod my girlfriend to do some translation
<dredg> ogra: indeed :)
<StR> Hi all
<StR> How can I have php4 and php5 working on the same instalation?
<\sh> I need at least one of the two buildd pros ;)
<carstenh> StR: you will not get a answer here, try #ubuntu
<carstenh> #ubuntu-devel is for develoment only
<RobinhoPeixoto> when will be generated the new version of language-pack?
<ogra> after release
<fabbione> hno_away: ping?
<\sh> elmo: please sync busybox , dbishell , lde from debian unstable, thx
<StR> carstenh: well.. yes, but beacuse it is a feature that comes in breezy (the php5 thing) I thought I would find the answer here
<carstenh> StR: see topic, so support, even with breezy
<Keybuk> no support
<Keybuk> :)
<fabbione> Keybuk: sorry.. are we there yet?
<fabbione> ;)
<Keybuk> fabbione: with?
<fabbione> the release..
<fabbione> :P
<Keybuk> how would I know?  I'm just a monkey
<Keybuk> ook
<RobinhoPeixoto> ogra: Already it has some day certain to leave the new version language-pack?
<fabbione> ahha
<fabbione> RobinhoPeixoto: no there is no ETA yet
<fabbione> RobinhoPeixoto: we still need to release and we are overloaded doing testing right now
<fabbione> it's really not a good time
<dholbach> you all should do some test installs :)
<RobinhoPeixoto> Can I generate this package?  How?
<dholbach> of the CD
<dholbach> s
<Keybuk> how to make Yelp crash
<RobinhoPeixoto> fabbione: I am testing the Ubuntu
<dredg> Keybuk: erm... type while it's doing something?
<dredg> move your mouse?
<dredg> look away? look at it? 
<Keybuk> Load it.  Click "Ubuntu 5.10 Starter Guide".  Click "Desktop" in the main window.  Click "Panel Applets".
<fabbione> dredg: why so sofisticate? just open it
<srbaker> hey
<srbaker> i'm insttalling ubuntu on a Tecra M2.  should i post my experience somewhere?
<srbaker> is there a place to post that it didn't fuck up or catch fire?
<xhaker> you're free to post it on the wiki.ubuntu.com
<srbaker> okay, i may do that.
<fabbione> srbaker: or post the bugs to bugzilla and send a report to the mailing list
<fabbione> it's more useful
<xhaker> infact, it's good practice that you do that.. and if anything really bad happens fill some bugzilla bugs
<xhaker> fabbione, beat me by 5 seconds
<xhaker> lol
<RobinhoPeixoto> I qill test
<RobinhoPeixoto> I will test
<xhaker> RobinhoPeixoto, brasil?
<RobinhoPeixoto> xhaker: yes
<xhaker> portugal here
<juliux> is it known that it is not possible to print landscape from gnome programs e.g. gtklp, abiword, evince
<doko> juliux: where did you get libnspr4 version 2:1.7.12-0ubuntu05.04 from?
<seb128> jdub, robitaille: do you have the url for the ics file?
<Nafallo> seb128: http://fridge.ubuntu.com/event/ical that one?
<seb128> yeah
<juliux> doko, it was on my system since i have installed hoary
<seb128> Nafallo: I want to URL to the file, not a redirection
<Keybuk> random thought about server installs ... does it really make sense to create a new user?  we could replace that with a "enter the root password" kind of affair
<Nafallo> ah
<juliux> doko, and under breezy it is a newer version
<juliux> doko, i searched the mirror manual but i do not found any libnspr4 package
<doko> pitti: ^^^ looks like you messup version numbers in hoary security fixes?
<juliux> doko, and apt-get --reinstall install linspr4 also not works
<seb128> Nafallo: you should just click on the .ics and get the webcal stuff asking if you want to put that to your calendar, atm it opens the download dialog
<Nafallo> seb128: I just pasted the url to evo :-)
<seb128> Nafallo: yeah, but just clicking on it would be nice :)
<Nafallo> baah :-P
<seb128> I want to get the website changed 
<mvo> ping doko 
<doko> mdz, Kamion: uploads to breezy/universe still possible? the mozilla version in hoary-security is newer than in breezy
<doko> mvo: pong
<mvo> doko: see /msg
<ogra> doko, universe is still open
<doko> ogra: thanks
<mdz> doko: universe uploads are still possible, but mozilla is in main
<doko> mdz: so breezy-updates ...
<doko> juliux: download the packages by hand: "aptitude download mozilla-browser libnspr", then install them with sudo dpkg -i ...
<doko> pitti: !
<doko> $ dpkg --compare-versions 1.7.12-0ubuntu2 gt 1.7.12-0ubuntu05.04; echo $?
<doko> 1
<pitti> Hi
<juliux> doko, thxs
<pitti> doko: so what? that version compare looks just fine?
<pitti> doko: oh, wait, it doesn't...
<pitti> doko: ubuntu0.5.04 would be better...
<pitti> but that looks like a bug in the version comparison? ubuntu2 should be newer than ubuntu0...
<juliux> doko, thanks for your help
<doko> pitti: no, it never was.
<wasabi_> guess the unichrome drivers never made it in
<wasabi_> did they?
<robitaille> seb128,  it seems the ical redirect change every day...right now it points at http://fridge.ubuntu.com/event/2005/10/12/ical/all/all/
<pitti> doko: bah; is this weird way documented somewhere?
<pitti> doko: nm, I'll ask keybuk
<Orborde> Is Breezy on bugzilla.ubuntu.com, I suppose?
<robitaille> seb128,  but jdub must know more about the behind the scene stuff.... I'm only an user :)
<doko> pitti: don't know, but I checked on a warty and woody system
<seb128> robitaille: k, I've noticed the redirection but that's still not a direct .ics to click on
<doko> pitti: #17579
<Keybuk> pitti: 'sup?
<dieman> anyone here on i2 or a reasonably fast network? want to see if this gigE card helped :)
<Riddell> mdz, Kamion: all 6 kubuntu CDs are good
<doko> mdz: should we add this upgrade glitch to the release notes?
<pitti> Keybuk: why is -ubuntu05.4 newer than -ubuntu2?
<Keybuk> because 5 > 2 ?
<pitti> Keybuk: because 0 < 2?
<Keybuk> at least, it is in my universe <g>
<Keybuk> 05 is still numerically 5
<Keybuk> sticking a 0 in front doesn't make it bigger
<Keybuk> 000000000005 is still greater than 2
<doko> Keybuk and pitti live in parallel universes ;-P
<pitti> not stringwise, though
<pitti> bah
<ozamosi> pitti: remember that 0.10 is greater then 0.9, and then you see why
<Keybuk> dpkg doesn't compare versions stringwise
<doko> Keybuk: it should be octal
<Keybuk> otherwise we'd just use strcmp
<Keybuk> doko: go stand in the corner
<pitti> ozamosi: that's different; 0.010 is smaller than 0.9
<seb128> Keybuk: what version of Ubuntu do you use? The FAQ has no item "Desktop" here on a fresh install ...
<Keybuk> pitti: not in dpkg-land
<mdz> doko: what changes are in breezy relative to hoary-security?
<HrdwrBob> ozamosi: greather than (sorry, pet hate)
<Keybuk> seb128: hmm?
<Keybuk> which FAQ?
<pitti> you mean 0.01 is bigger than 0.9? weird
<seb128> Keybuk: your crasher
<Keybuk> seb128: that was me testing yelp
<Keybuk> so 20051012.2
<pitti> mdz: mainly building against new libraries
<seb128> yeah, but and now that's me trying to click on the same items to get the crash
<Keybuk> it was because I clicked Desktop while it was still loading the FAQ I think
<seb128> and I've no "Desktop"
<pitti> mdz: we could upload a newer version to breezy-updates if necessary
<mdz> we could potentially allow an update to breezy as well
<Keybuk> pitti: yeah, has always been thus
<mdz> can someone check if the binaries are on any CDs?
<fabbione> what pkg is that?
<doko> mdz: libnspr4 definitely is on all cd's ...
<Keybuk> seb128: if I load Yelp, the first thing is "Desktop" under "Help Topics"
<Keybuk> that's what I clicked
<Keybuk> after clicking the FAQ thing
* Keybuk has ADD
<mdz> doko: that is unfortunate
<seb128> Keybuk: ok, thanks
<mdz> elmo: can we add a katie check for this?
<mdz> elmo: (hoary-security > breezy)
<doko> mdz: so we learn for the testing plan :-) test-upgrades from released hoary and security-updated hoary
<Keybuk> s/katie/soyuz/ no?
<pitti> doko: with all installed packages, that is - mozilla is not installed by default
<seb128> pitti: libnspr4 is
<mdz> pitti: please prepare an upload for breezy-updates
<mdz> I'm still waiting for DVDs to rsync; has anyone been able to  test them yet?
<doko> mdz: already did
<Riddell> I'll need a volunteer to test the amd64 dvd in an hour or so
<Riddell> kubuntu one
<mdz> doko: oh, please update BreezyTestPlan then
<mdz> we seem to be lacking powerpc testing too
<Unfrgiven> mdz: i tried grabbing the latest daily off the torrent last night (as per the test plan) but its stopped at 77% :(
* pitti calls it 1.7.12-1ubuntu1, althuogh that is not strictly true
<Keybuk> mdz: everyone's powerpc is broken
<mdz> mine isn't broken, it's just sick
* mdz  shakes a fist at Apple
<Riddell> I have a powerpc if something needs testing
<mdz> Riddell: https://wiki.ubuntu.com/BreezyTestPlan
<pitti> mdz: mozilla_1.7.12-1ubuntu1_source.changes for breezy-updates prepared
<pitti> mdz: shall I upload now?
<mdz> pitti: check with elmo first
<pitti> ok
<pitti> elmo: ok to upload a mozilla with newer version to breezy-updates?
* pitti successfully tests current ppc live
<jbailey> Does /current/ point to 20051012.3?  The CD seems to still say 20051012
<mdz> jbailey: the CD doesn't include the fractional digit
<mdz> unfortunate but true
<jbailey> mdz: What's the best way to confirm that I've got the .3 version?
<jbailey> ppc64 passed everything but cd eject at the end, but I want to make sure it was on the right version.
<ajmitch> md5sum?
* Kamion returns
<doko> somebody did ignore the lock on BreezyTestPlan
<Kamion> jbailey: .disk/info on the CD-ROM
<Kamion> oh, maybe not
<Kamion> yeah, md5sum
<Keybuk> hmm
<Keybuk> no test sound on OEM install
<Kamion> Keybuk: known, it's because most of GNOME isn't running
<Keybuk> heh
<Kamion> mdz: btw, jdub says that when he gets back from the pub he has an artwork upload to do
<Kamion> ...
<mdz> Kamion: very funny
<pitti> we get dapper artwork so early? :-P
<ogra> Kamion, oh, he took pictures in the pub ? 
<Kamion> I think he wanted to troll about it earlier today but silbs made him stop
<mdz> Kamion: tell him to stop by on his way through here next time for a whipping
<Kamion> :-)
<Keybuk> send him to Brum, I've got one
<fabbione> ok
<fabbione> Kamion: OEM install is still go
<Keybuk> does the oem installer not detect the keyboard?
<Kamion> Keybuk: no, haven't figured out how to extricate that code from cdebconf yet
<Keybuk> shame it doesn't auto-fill in the username box either
<Kamion> ... oh, damn, and it may not tell X about the change either
<Kamion> whoops
<Keybuk> interesting different in partman behaviour, btw
<Kamion> well, there's one for the errata; I'm not banging in a dpkg-reconfigure xserver-xorg at this stage
<Kamion> Keybuk: que?
<fabbione> AH AHHHHHH
<Keybuk> if I do an "automatic" partman, I just get the partitions it made in fstab
<Keybuk> if I hit manual, I suddenly get every partition on every drive in fstab
<fabbione> mdz: remember that livecd/casper problem? i can reproduce it on one of my box...
<mdz> fabbione: no, I don't
<fabbione> mdz: i just noticed...
<Kamion> Keybuk: gah, that's a bug
<fabbione> mdz: the one that you reassigned to me from kiko / minimac
<Keybuk> I have a /media/hda1, /media/hda3, /media/hdc1, et. al. now
<fabbione> let me find the number
<mdz> fabbione: screaming during release prep is prohibited except for showstoppers
<fabbione> mdz: xresprobe not detecting the resolution
<Kamion> Keybuk: that's really sucky, but too late to fix
<Keybuk> Kamion: yeah, it's not critical or anything
* fabbione shuts up
<Keybuk> would be nice to fix for next time
<mdz> fabbione: my poor nerves :-)
<Kamion> definitely; I don't know where the problem would be offhand
<mdz> fabbione: are you able to strace it etc.?
<fabbione> mdz: i will try
<mdz> Kamion: the DVD has a different winfoss tarball, right?
<Kamion> mdz: no, I don't think anyone ever asked for one
<Kamion> no IMAGE_TYPE casing in find-live-filesystem at all
<mdz> Kamion: oh, ok. one less test case
<wasabi_> so like, any idea how to tar some files up perserving perms and untar them preserving them, when /etc/passwd with the original uids doesn't exist?
<Kamion> it probably *should* have
<mdz> fabbione: are you able to test the amd64 winfoss at all?
<fabbione> mdz: i already added it to the wiki
<fabbione> i did it
<mdz> Kamion: yeah, surely hno73 has a larger tarball
<doko> well, what's up with you, second time the lock on BreezyTestPlan is ignored ...
<mdz> fabbione: oh, just saw it. thanks.
<fabbione> mdz: no problem :)
<Keybuk> Kamion: also, I'm not sure, but I don't think I got an ntfs partition in fstab for automatic
<Lathiat> wasabi_: if tar wont do it
<Lathiat> wasabi_: one of the other tools might
<Lathiat> cpio or whatever
<Kamion> Keybuk: I thought I fixed that a couple of days ago
<Keybuk> dunno, will do a reinstall to test that one specifically
<Kamion> Keybuk: but if there's a generic problem with stuff not getting automounted by partman-auto, it would apply to ntfs the same as everything else
<Keybuk> it's on a different drive, don't know if that makes a difference
<fabbione> mdz: i noticed only one small detail about the winfoss implementation. The browser windows that gets autoplayed is like 50 lines too short..
<fabbione> mdz: the rest is perfect
<Kamion> Keybuk: if it's in manual partitioning, that's more annoying, because it worked for me
<fabbione> it tends to cut away the bottom
<Keybuk> it's in manual partitioning yeah
<Keybuk> that definitely worked
<ivoks> so, when do we open champain? :)
<fabbione> but i definetely don't consider it a show stopper :)
<Keybuk> Kamion: live cd doesn't seed fstab either, but that may be a feature ?
<Kamion> Keybuk: missing feature deferred at preview time, didn't get implemented in time
<Bicchi> Sorry to ask but at what time is the release of ubuntu?
<Kamion> Mithrandir's got the code for dapper, I think
<Riddell> Bicchi: sometime in the next 24 hours
<xhaker> 00:00 i think
<mdz> I am getting terrible throughput from cdimage
<Kamion> xhaker: on any particular basis? :-) (wrong)
<mdz> via rsync anyway
<mdz> wonder if http is better
<Mithrandir> Kamion: yeah, didn't make FF.
<pitti> mdz, elmo: btw, the prepared upload is on chinstrap:~pitti/mozilla_1.7.12-1ubuntu1_source.changes, so it it is ok, just dput it
<xhaker> Kamion. atleast is what it says in the Fridge.. haha
<pitti> s/so it/so if/
<Kamion> xhaker: was just set arbitrarily I think
<Bicchi> xhaker: yeah but 00:00 where
<Bicchi> xhaker: UK ?
<mdz> in fact my bandwidth everywhere seems to suck :-/
<mdz> I seem to be capped at 1.5mbit
<mdz> FURY
<HrdwrBob> haha
<HrdwrBob> welcome to australia
<doko> mdz: are the three proposed upgrade tests too much=
<doko> ?
<xhaker> Bicchi i just assume everything is UTC in dev sites
<fabbione> mdz: it's slow from here too
<mdz> doko: should be ok, except s/hoary/breezy/, too late for more hoary CD upgrade testing ;-)
<mdz> fabbione: that may be, but I definitely have a local problem
<Kamion> Bicchi: don't worry about the timezone, since the given time isn't correct anyway; it will be released at some point during 2005-10-13, but no time has been set
#ubuntu-devel 2005-10-18
* \sh needs to fix universe before release...so stay tuned
<Bicchi> Kamion: I just want to avoid slow downloads and do it right away.
<ikmo> Hi all, is there anyone from the art team in here please?
<Kamion> \sh: you are nearly out of time
<Kamion> we aren't going to wait
<Kamion> \sh: remember that the buildds have to catch up with your uploads *before* release, too
<\sh> Kamion: yeah...I'm hurring up
<Kamion> \sh: learn to love the way bugs can be handled next release rather than rushed through for this one
<\sh> Kamion: but for dapper I need to find a quad xeon sponsor
<fabbione> mdz: sparc tftpboot install and miniso install are good too :)
<\sh> Kamion: only some ftbfs stuff the last packages..if someone is saying now..."buildds closed"...I'll just test the cds with my working laptop now
<\sh> good thing is, actually, that I have a free day today
<\sh> elmo: thx 
<fabbione> mdz: i can't see anything obvious in dccprobe.. i will have to look at it when i am more awake
<mdz> fabbione: ok, thanks
<fabbione> no problem
<fabbione> it can't be fixed for breezy anyway
<mdz> ogra: still here?
<ajmitch> \sh: hopefully for dapper we can do builds on the launchpad system
<ogra> mdz, what a question :)
<fabbione> mdz: is there anything else i need to do before crashing?
<mdz> fabbione: if all your test results are in the table, no, good night
<mdz> ogra: how is edubuntu?
<Kamion> (Edubuntu DVDs are currently building, BTW)
<Kamion> Riddell: Kubuntu DVDs are published
<ogra> mdz, last iso was fine, just copying the final iso over to my writer
<fabbione> Kamion: have the Ubuntu-server CD been rebuilded already?
<Kamion> fabbione: yes
<fabbione> mdz: ok.. i am gonna test one of them again
<Riddell> Kamion: only amd64 is there
<fabbione> Kamion: thanks
<Kamion> Riddell: ah, it'll still be mirroring then
<Riddell> right
<mdz> Kamion: what's left to build CD-wise?
<Nafallo> fabbione: there is a special cd for servers?
<Kamion> the only images left to build are Edubuntu DVDs (in progress), then non-release stuff: ports install/live, livecd-base
<fabbione> Nafallo: yes..
<Nafallo> that's news to me :-)
* Nafallo goes to look
<fabbione> Nafallo: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<Kamion> Nafallo: it's rather new
<Nafallo> what's the diffrence from regular with server on the prompt?
<fabbione> Nafallo: the pkgs on CD
<Kamion> Nafallo: different set of stuff on the CD; a bunch of server applications in place of the desktop
<Kamion> (only the server boot option, though, you don't get a huge bunch of servers installed by default)
<jbailey> Is it live + cd for a dvd rsync?
<Nafallo> oki. then regular + internet give me no diffrence :-)
<fabbione> jbailey: yes
<Riddell> jbailey: how does that work?
<fabbione> Riddell: cp live dvd && cat install >> dvd && rsync ;)
<Riddell> I'm sceptical but I'll give it a go
<Kamion> Riddell: works pretty well in practice
<jbailey> Riddell: It seemed to cut about 30% off the last one I did.
<jbailey> Good enough for me. =)
<Kamion> you have to download .debs not on the install CD, obviously, but the rest helps
<dobwan> whiprush, are you going to mirror 5.10?
<\sh> elmo: please sync dbishell 0.8.9-7 from debian unstable (ubuntu override OK, missed that, sry)
<Keybuk> Kamion: confirmed; automatic partitioning doesn't find my ntfs drive
<Keybuk> but manual does
<Kamion> Keybuk: ok, that's at least consistent, thanks
<Keybuk> meh, now where the hell are my gorram hoary CDs?
<Keybuk> I know I blew some
* Kamion applies some reformatting to the test plan tables
<mdz> yay, bandwidth restored
<mdz> should be able to start DVD testing in <30m
<jdong> Is there any plan of fixing 17410?
<ogra> lucky you :)
<fabbione> AHHHHH 
<ogra> jdong, the archive is frozen
<Keybuk> hmm
<mdz> jdong: see /topic
<fabbione> nice midnight snack
<Keybuk> autorun isn't working for me
<ogra> fabbione, !!
<jdong> ogra: those upgrading to Breezy won't be amused
<Keybuk> XP thinks that 20051012.2 install is a "Pictures" CD
<mdz> jdong: we've already discussed that here and it will be addressed through breezy-updates
<fabbione> Keybuk: not here... mine was fine
<jdong> mdz: k, that clears it up :)
<Keybuk> there isn't an autorun anything on it, in fact
<Keybuk> fabbione: live or install?
<fabbione> Keybuk: live
* Keybuk is testing install
<fabbione> oh
<fabbione> ok
* fabbione is closed to 24 hours in a raw in front of his monitors
<Keybuk> maybe that's deliberate *shrug*
<Kamion> BreezyTestPlan reformatted; please insert line breaks as I've done, it makes the whole thing a lot more readable
<fabbione> Kamion: wow... i
<ogra> would someone like to test edubuntu ppc or amd64 ? 
<ogra> or x86 dvd ?
<wasabi_> jbailey, ping
<wasabi_> jbailey, usplashL
<wasabi_>         if [ $VESA = "true" ] ; then
<wasabi_>                 insmod /lib/modules/`uname -r`/initrd/vesafb.ko
<wasabi_> That module is never copied to the initrd.
<wasabi_> that I can tell, anyways.
<jbailey> wasabi_: /usr/share/initrams-tools/hooks/kernelextras
<jbailey> Thekernel maintainers decide on some things that should be always loaded, so we load 'em.
<wasabi_> NOt following.
<wasabi_> Passing vga=* on the command line fails.
<jbailey> You said it wasn't copied to the initramfs, and I told you what copies it.. =)
<wasabi_> Well, /initrd/vesafb.ko isn't present heh
<jbailey> wasabi_: Can you trace the function and figure out why it's not copying for you?  It does on all my machines.
* Kamion frees up enough disk space to sync down DVDs
<Knorrie> hi I would like to know if this has something to do with a bug: http://od251.csrdelft.nl/ubuntu/Screenshot-2.png
<Knorrie> I'm trying to get my keyboard 'e ^e accents working since 16:00 today (it's now 0:53 here)
<wasabi_> hmm. my initrd has no /lib/modules/*/initrd. Tracking it down.
<seb128> what does the lines of the msg write?
<jbailey> wasabi_: Try adding "set -x" to the top of that script.
<fabbione> Knorrie: it looks like your /etc/X11/xkb/base.xml is corrupted
<seb128> or the gconf settings are crappy
<fabbione> seb128: note the keyboard selector has only one kbd listed..
<Knorrie> fabbione: yeah i can add and remove there, but whatever i choose, i get error dialogs like the one in the screenshot
<seb128> is us_intl a correct keymap?
<Knorrie> seb128: I use it at work in breezy, and it has the correct behaviour with ^e etc
<wasabi_> jbailey, it's loadingt he one in ./kernel/drivers/video/vesafb.so instead
<wasabi_> force_load gets it
<Knorrie> fabbione: /etc/X11/xkb/base.xml: No such file or director <== is that bad?
<wasabi_> It is going thru /lib/modules/*/initrd, and it's adding them, but they're being resolved to the ones in kernel
<fabbione> Knorrie: yes.. apt-get install xkeyboard-config
<wasabi_> Which to me seems to make the most sense.
<fabbione> that's the whole reason of all those errors
<wasabi_> the /initrd directory confuses me
<seb128> fabbione: no ...
<Knorrie> fabbione: i have a base.xml in /etc/X11/xkb/rules
<seb128> fabbione: do you have this file?
<HiddenWolf> seb128, I'm having a very odd reproducible bug with keyboard applet 
<fabbione> seb128: yes i do
<fabbione> Knorrie: sorry.. rules/
<Knorrie> fabbione: xkeyboard-config is already the newest version. :)
<seb128> fabbione: right
<fabbione> seb128: at that point yes.. it's not it
<HiddenWolf> seb128, gtk skinning goes on and off if I select a layout that's not US English
<fabbione> seb128: it can still be corrupted and contain invalid xml
<Knorrie> HiddenWolf: here too :)
<seb128> Knorrie: what about reading the dialog instead opening a bunch of them ?
<Knorrie> seb128: lol 
<seb128> HiddenWolf: known, fixed but not pushed for 5.10
<HiddenWolf> seb128, cool
<HiddenWolf> Knorrie, suck it up for now
<HiddenWolf> seb128, thanks
<seb128> HiddenWolf: http://bugzilla.ubuntu.com/show_bug.cgi?id=15372
<seb128> np
<HiddenWolf> seb128, interesting
<fabbione> Kamion: what version of the ubuntu-server has been published? .2 ?
<fabbione> never mind
<mdz> fabbione: aren't you supposed to be asleep? ;-)
<fabbione> mdz: when you said if i finished my tests, i suddenly remembered that i could test ubuntu-server
<HiddenWolf> seb128, I understand it only happens when you have multiple layouts in the preferences dialog?
<seb128> HiddenWolf: yep
<mdz> fabbione: nah, I said if you had updated BreezyTestPlan for the tests you had already done
<fabbione> mdz: yes i did that too :)
<sistpoty> still time to request a sync?
<mdz> sistpoty: for universe
<sistpoty> yep
<sistpoty> cool
<HiddenWolf> seb128, weird, not for me. I can set US-int, delte us-english, and it still keeps un-/rethemeing the windows.
<mdz> might not be processed before we close the archive, though
<mdz> but not too late to try
<sistpoty> ok, thx mdz
<seb128> HiddenWolf: that's a combinaison of options doing that, maybe your keyboard variant does it
<sistpoty> elmo: could you please sync gtalk (0.99.10-10) (no ubuntu patches there)?
<mdz> first DVD burning, finally
<HiddenWolf> seb128, i'll not keep you.
* Kamion goes to fill in some of the powerpc entries in the table
<mdz> Kamion: oh good
<Kamion> ogra: Edubuntu DVDs published
<Kamion> I won't be able to do powerpc auto-resize, I don't think
<Kamion> but I can do the rest
<Kamion> er, nor powerpc erase-whole-disk, but that's been done
<fabbione> ok i am off
<fabbione> cya in 4:50 minutes
<fabbione> minute more, minute less
<fabbione> :)
* fabbione &
<spstarr> mdz: #8879
<Kamion> mdz: I'm running the ports builds now; all release builds are complete
<seb128_> 'night fabbione
<fabbione> night
<spstarr> User has Fedora Core, no problem occuring, solution: Remove qlogicisp or disable it
<mdz> spstarr: please follow up to bugzilla
<dholbach> night fabbionne
* _mvo_ yawns
<ogra> Kamion, thanks
<ogra> Kamion, i just did a edubuntu server install, there is a tail -f /var/log/base-config-pkgsel.log left in the process list after install
<Kamion> ogra: yeah, known, I never did figure out how to get rid of that neatly
<jordi> I'm off to bed. In case I miss it, good luck with the release, folks.
<Kamion> it'll go away on reboot
<Kamion> it's a bug of course
<ogra> Kamion, minor :)
<Kamion> well, it's irritating that you don't get the use of that console
<HiddenWolf> OMG, the fridge is heating up. :)
<HiddenWolf> Eat the icecream before it's melted.
<Keybuk> you put ice cream in the fridge?
<HiddenWolf> Keybuk, combo unit
<HiddenWolf> -> fridge.ubuntu.com timing out
<\sh> mvo: good morning :)
<mvo> \sh: hello
<dobwan> HiddenWolf, to many of us trying to get there at once. I put ice cream in a dish and eat it :-), time for me to be silent and watch again
<HiddenWolf> dobwan, that's silly, on what kind of server is it? :S
* HiddenWolf begs archive won't get swamped too
<Keybuk> HiddenWolf: isn't really -devel relevant though
<HiddenWolf> Keybuk, rodger
<Kamion> mdz: we seem to be doing OK with publishing DVDs at the same time as CDs, but I think I'm going to publish them to cdimage this time rather than releases
<Kamion> mdz: elmo was complaining about the fullness of releases, with some justification
<wasabi_> jbailey, did you get my earlier messages?
<mdz> Kamion: yes, I agree
<Kamion> ok, this install thinks it's in Swiss French, German keyboard, and timezone Canada/Saskatchewan
<Kamion> this'll be one confused little system
<jdub> righto
<jdub> i'm here
<jdub> ubuntu-artwork update coming in a moment
<seb128_> jdub: good one :)
<jdub> :-)
<Kamion> 22:40 < mdz> Kamion: tell him to stop by on his way through here next time for
* dholbach couldnt believe his eyes :)
<Kamion>              a whipping
<jdub> *LOVE* to the FREEDOM BRINGERS!
* Keybuk hands mdz the whip
<jdub> how is it going?
* ogra laughs
<jdub> we are drinking champagne-like stuff
<jdub> in celebration
<mdz> jdub: don't curse us with premature celebration
<HiddenWolf> jdub, something nice in there? :)
<dholbach> hahaha :)
<seb128_> jdub: what about putting a real ics url for the calendar so clicking on it opens the webcal magic? :)
<daniels> Kamion: i'll be interested to see what the final xkb layout is
<ogra> jdub, your fridge is full
<jdub> seb128: hrm, it doesn't?
<jdub> seb128: it shoud have the right mime tuype
<seb128> jdub: there is a redirection to somewhere and I get the download dialog
<Kamion> daniels: server install, unfortunately, but I can install xserver-xorg and see what happens
<daniels> Kamion: booo ;)
<daniels> Kamion: i don't care too much, just morbid curiousity; per -devel, I'm now convinced that the entire logic behind xkb layout selection is fundamentally fucked
<HiddenWolf> daniels, A beer if you fix it in time for release. On a silver platter. :D
<daniels> HiddenWolf: ...
<HiddenWolf> daniels, </joke>
<sistpoty> daniels: is xprint worth fixing?
<daniels> sistpoty: you didn't get my mail earlier?
<sistpoty> daniels: no, unfortunately not... maybe my universities mail-server is f*cked again
<daniels> sistpoty: short answer is: main, no, but some freaks seem to want a functioning xprint in universe, so probably
<sistpoty> daniels: ok, thx
<dholbach> sounds like time for a DeFreakingUniverse BOF :)
<ogra> LOL
<slomo> daniels: is xprint obsolete? or shall i fix it (if it's really broken)?
<sistpoty> slomo: read backlog ;)
<slomo> ok ;)
<daniels> slomo: just stabbing yourself in the head directly is more effective
<HiddenWolf> daniels, can't be _that_ bad?
<daniels> xprint has the same effect, it just takes longer
<daniels> HiddenWolf: you'd think that, and then you realise that selection of config file is based on what locale you start the server in
<ogra> argh... damn, edubuntu workstation failed in archive copier grmpf...
<mdz> amd64 dvd live OK, install in progress
<HiddenWolf> daniels, that's stupid, but not terminal.
<slomo> daniels: ok, i'll add it to my "don't touch" list ;)
<daniels> HiddenWolf: only one of the many stupidities rampant through xprint
<Kamion> ogra: failed in what way?
<HiddenWolf> daniels, I get the piont. :)
<ogra> Kamion, copying axorg package i think my iso is corrupt :(
<ogra> just retrying
<HiddenWolf> ogra, that's what verification of burned cd's is for. :P
<Kamion> ogra: I'd guess a scratched CD or a dirty drive before a corrupt ISO
<ogra> yup, could also be the case, but doesnt save me from copying the iso over to a machine without os...my writer is in the test machine currently...
<HiddenWolf> daniels, xprint is hosted at mozdev.org, and typo's are rampant throughtout the site. I can only imagine the horror they make of the code.
<daniels> HiddenWolf: to be fair, the guy who did it is ESL
<Kamion> daniels: hmm. apparently XKBLayout ch, XKBVariant fr
<daniels> Kamion: \o/
<wasabi_> man tar sucks. Won't extract preserving perms based on uid number. =(
* Knorrie finally fixed his keyboard settings () using the last .debs mentioned at http://bugzilla.ubuntu.com/show_bug.cgi?id=15372 \o/
<mdz> wasabi_: --numeric-owner doesn't work on extract?
<daniels> Kamion: i plan to sit down at some point, go through all the d-i maps, and come up with a d-i -> xkb mapping
<Kamion> daniels: (looks like a lack of any kind of handling for debian-installer/keymap == mac-usb-* in .config)
<mbreit> why is there no svgalib on amd64? it is on architecture any and builds fine on amd64...
<daniels> Kamion: err, we do ##mac-usb-
* _mvo_ grumbles at his network
<Kamion> daniels: so in general powerpc is going to be confused
<Kamion> oh, so you do
<daniels>   db_get debian-installer/keymap || debug_report_status "db_get debian-installer/keymap"
<\sh> _mvo_: ISH?
<daniels>   DI_KEYMAP="${RET##mac-usb-}"
<mbreit> but the buildd does only build it for x86.
<dholbach> \sh: wifi rather
<daniels> it's just a general lack of handling console layouts
<Kamion> it's mac-usb-de-latin1
<wasabi_> mdz not for directories.
<daniels> and instead trying to infer it from languages
<daniels> which is insane
<\sh> dholbach: right...
<daniels> Kamion: right, we only deal with the deadkeys case
<Kamion> which seems to be unhandled
<daniels> er, with the nodeadkeys case
<slomo> mbreit: probably in pas
<wasabi_> acutally I see the prob.
<wasabi_> Tar hasn't actually tarred the dirs
<Kamion> daniels: yeah, although it's a lot better than it was
<daniels> Kamion: markedly, yeah
<\sh> does anybody need a d-link DI-524 with a d-link DWL-G122 USB Stick?
<\sh> router is european version :(
<slomo> \sh: the usb stick is this prism2 thing?
<\sh> slomo: no...
<ogra> Kamion, second try worked :)
<slomo> \sh: what driver does it need? ;)
<\sh> slomo: ndiswrapper somehow
<slomo> \sh: oh... even worse than linux-wlan-ng ;) ok, i won't take it :P
<\sh> 54MBit/s 
<wasabi_> wow that sucks.
<wasabi_> I didn't know tar did that.
<jbailey> Let's see if this dvd burner works...
<wasabi_> jbailey, did you get my stuff from earlier? :)
<jbailey> wasabi_: Stuff? =)
<wasabi_> kernelextras calls force_load for vesafb
<wasabi_> which loads the one not in initrd
<jbailey> Right.
<jbailey> I saw that..  Which makes me wonder why it works for me now.. =)
<wasabi_> Well, verify you have /lib/modules/*/initrd in your initrd, I don't.
<wasabi_> Doesn't seem to be required.
<ogra> meh, i can never ses the edubuntu usplash to its end... damn adaptec, 1min to probe devices is so odd...
<jbailey> wasabi_: Force_load would take care of it otherwise.
<wasabi_> Ahh, that's true. Yeah, it woudl be loaded.
<wasabi_> Still usplash spits an error.
<jbailey> module loading happens after usplashinitialisation...
<wasabi_> usplash itself tries to load vesafb in init-top
<jbailey> Right
<wasabi_> Which fails.
<wasabi_> And prints ot an error.
<mbreit> lamont: ping
<\sh> elmo: please sync atanks from debian unstable (ubuntu override OK), thx
<jbailey> i386 dvd live is giving me a fata ext2 module not found.
<Kamion> I can't remember if ext2 is built-in on i386; if not, is there an ext2-modules-*.udeb on the disk?
<doko> hmm, are smp kernels not fetched on install, if I have network? it get's the -k8 kernel, but not -k8-smp
<Kamion> doko: neither -k8 nor -k8-smp is fetched in a CD install, only -generic. Is this netboot?
<Kamion> it might not detect SMP properly though; that's been a moderately long-standing issue with base-installer, recently improved upstream
<doko> Kamion: no, DVD install
<Kamion> ah, right
<Kamion> as above then
<jbailey> Kamion: NM.  When I do ls in /cdrom, I'm getting IO Errors.
<Kamion> jbailey: ah
<segfault> how's the test going?
<dholbach> http://wiki.ubuntu.com/BreezyTestPlan
<\sh> elmo: please sync trickle from debian unstable, thx
<segfault> nice, all PASS
<jdub> elmo: ping - where's the fridge?
<doko> Kamion: no, it did install -generic, -k8-smp and -k8, the latter as the default
<whiprush> jdub: Chief Refrigeration Engineer to #ubuntu-sounder please!
<jdub> elmo: perhaps we need to crank up the # of apache processes?
<Kamion> doko: please file a base-installer bug with contents of /proc/cpuinfo, I'll chase that up later
<mdz> jdub: elmo was in the data centre until some ridiculous hour of daylight this morning; I don't think he's around
<glick> excuse me, when you make a makefile, what does the error "missing seperator" mean?
<jdub> hrm, i can imagine that
<elmo> I am around
<elmo> tho it seems humboldt has more fundamental problems than apache
<mdz> Kamion: I correctly got -amd64-k8 in my dvd install, fwiw
<mdz> jbailey: any further ppc64 progress?
<jbailey> mdz: I'm burning a ppc64 live dvd right now.
<jdub> elmo: hrm, tho i can log into it
<mdz> jbailey: were you able to do a CD install test?
<Kamion> mdz: at the moment it uses a really dodgy test for SMP that involves grepping dmesg, and the ring buffer has probably wrapped by that stage so it'll in practice always assume UP
<Kamion> I think that's fixed upstream
<jbailey> mdz: It's where I sync everything to, so I don't have enough drivespace elsewhere to copy my data to. =(  I think I can do it last by deleteing all of the CD and DVD images that I have.
<elmo> jdub: yeah, I'm on crack - up the maxclients
<mjg59> My Universe upload is entirely due to Robot101
<elmo> silly php forcing prefork
<mdz> Kamion: BenC has an idea to give us smp support out of the box without penalty for dapper maybe
<mjg59> All blame should go to him
<jdub> elmo: i can't do that tho :-)
<elmo> jdub: up-ed
<jdub> thanks :-)
<jdub> ooh
<jdub> gosh
<jdub> significantly so
<Kamion> mdz: works for me either way
* mjg59 is lying evil scum
<elmo> jdub: box isn't doing anything else ;)
<jdub> :-)
<jdub> thanks!
<Unfrgiven> elmo: hi. there is a package called introdeveloperdocs in the new queue. its a breezy goal. can it be put into universe please? no rush, just wanted to make sure it gets into breezy.
<ogra> mjg59, haha, your name sticks last in the changelog :)
<elmo> Unfrgiven: "no rush".. good one
<mdz> jdub: the fridge's google rankings need work
<elmo> there needs to be a MOTU freeze for the next release - or I need to not be processing the archive stuff
<mdz> Unfrgiven: heh, "no rush, just make sure it gets in the release which is releasing VERY VERY SHORTLY"
<mdz> elmo: anything landing in queue/new this late is not a priority
<sistpoty> hehe
* mdz wonders how many of this massive stream of universe uploads will result in FTBFS in breezy final
<Unfrgiven> elmo: mdz: my apologies. ive had some personal reasons i could not get this in quicker. ive been in touch with janew the last few weeks and have spent many hours trying to do it as soon as possible. i guess all i could do is try to do what i could. im really sorry about the delay.
<\sh> mdz: and only one clisp sync didn't build on the buildd but in any pbuilder...and I'm in need of infinity/lamont to have a look there...cause it's not right
<_mvo_> hm, I got some a postinst error from postfix on hoary->breezy upgrade (hoary-security+hoary-updates) 
<elmo> \sh:  and that's exactly why universe being unfrozen is such a horrible mistake
<elmo> \sh: because the last thing we need is our buildd maintainers spending time on anything but main, 24 hours or less before release
<\sh> elmo: yes, we know...and it will change for dapper...but thanks to every transition we had
<Robot101> drink through it
<Keybuk> I had a similar "discussion" with the bzr guys the other day
<\sh> Robot101: there is no drink anymore
<Robot101> harsh
<ogra> \sh, you should have come over here today already then :)
<\sh> Robot101: amarok killed at least 9MB of my braincells so it has to regenrate until friday
<Robot101> I recommend not involving ogra, drinking and universe uploads :P
<ogra> *g*
<\sh> ogra: I wanted to take off 2 days..but friday two others are off, so I can only have my fun today ;)
<LaserJock> elmo: sorry to bug you at such a busy time, but did you happen to get my sync request for dvi2ps and wterm?
<\sh> ok...this is it for me...
<\sh> no more uploads
<jdub> whhooooaa
<jdub> fridge is getting some serious hit action
<ogra> \sh, bah, lamer
<\sh> breezy buildds + archives are just closed for me now
<ogra> ;)
<Keybuk> elmo: today I discovered that Sainsbury's sell Pizza Express Cheesecake
<elmo> !!!!!!!!!
<\sh> ogra: I'll send now a mail to elmo with the last stuff...so if this is going in, ok, if not, also ok
<elmo> fuck, it's 1am.  they're closed
<Robot101> master of the roflverse
<jbailey> "pizza express cheesecake"?
* ajmitch returns
* mvo gets hungry hearing you talk about pizzzzzaaa
<jbailey> I'm trying to render those words into something that is food, and failing...
<\sh> elmo: thx that's what I wanted to hear...
<\sh> elmo: no mail
<Kamion> \sh: I think he means Sainsbury's, not the buildds
<mdz> jdub: what's with the fist-sized unmatched double quotes on the fridge?
<ogra> mdz, design element :p
<\sh> Kamion: u see :( I'm just tired
<mdz> jbailey: cheesecake such as can be purchased at Pizza Express
<mdz> an important restaurant in the history of Ubuntu
<slomo> elmo: please sync bibletime_1.5.1-1 from debian/unstable... fixes unmet deps/ftbfs
<ajmitch> cheesecake & pizza? hm
<elmo> LaserJock: pls mail me
<LaserJock> elmo: I did (my name is Jordan Mantha)
<elmo> ok, then I'll get to it
<Keybuk> mdz: Mark still has the napkins, I believe
<LaserJock> elmo: thanks so much
<jbailey> mdz: Oh.  He's not sprinkling cheescake on pizza?
<Kamion> I was about to say that we decided on the version numbering scheme in PE, but we didn't, it was in some cafe or other
<Keybuk> that was The Crescent
<mdz> archive-copier certainly is snappy in the server install
<jbailey> I've heard that elmo has... unusual dietary needs. 
* jbailey hides.
<slomo> elmo: and please sync trickle 1.07-4 and bubblemon 2.0.4-3 for \sh
<mjg59> I DENY EVERYTHING
<elmo> slomo: I don't do proxied sync requests
<elmo> not if both parties are MOTU
<jdub> mdz: HATE!
<jbailey> I am apparently a huge packrat.  I had no idea I have 70Gb of crap on this harddrive until I wanted to back the bloody thing up.
<jbailey> *sigh*
<ajmitch> jbailey: oh that's not much
<ajmitch> jbailey: I easily cleaned up 40-50GB of general junk recently :)
<bob2> the crescent being the only cafe in london to make flat whites, too
<ajmitch> and that's before I start really cleaning
<ajmitch> bob2: what?!
<mjg59> jdub: Your mother dresses you funny
<Keybuk> bob2: that was the-cafe-formally-known-as-the-crescent
<Kamion> I dunno, I think 70GB is quite a lot if you aren't a compulsive music/video downloader or whatever
<Keybuk> I can't remember what it's called now
<Keybuk> the burger's aren't as good now
<jbailey> This is almost all cvstrees and builds.
<bob2> it claims to be a bar now
<ajmitch> Kamion: it's easy if you build a lot of universe packages 
<bob2> restaurant bar, anyway
<slomo> elmo: ok... sorry
<ajmitch> but that's a different sort of compulsion :)
<elmo> oh, the cross bar
<elmo> I was wondering what you guys were talking about
<Keybuk> libnspr is known-newer in hoary-updates right?
<bob2> that''s the one
<Keybuk> (than breezy)
<mdz> Kamion: the suppression of resize mode in oem is intentional, right?
<Kamion> mdz: there's no such suppression
<Keybuk> ah, yes, that's the one pitti was complaining about dpkg doing the right thing
<Kamion> mdz: at a guess, you're running into partition table limits
<mdz> Kamion: er
<mjg59> Kamion: "Your"
<mjg59> (lie)
<mdz> Kamion: I already did an auto-resize install on this box earlier today
<mdz> Kamion: and after that erased it
<Kamion> mdz: you probably have three primary partitions already
<mdz> so it currently has just ext3 + swap
<Kamion> hmm
<mdz> hmm, maybe I didn't erase it
<mdz> I did the erase install first, then the resize one
<mdz> so yeah, probably primary partitions
<mdz> possible and plausible
<Kamion> it's annoying, but really hard to do better
<Kamion> you have to start moving partitions around in a number of cases
<Kamion> we could improve it somewhat by not creating primary partitions so gratuitously
<mdz> Kamion: what about making everything logical partitions except the very first one?
<wasabi_> (what about using LVM by default)
<Kamion> mdz: that's what we do, but with successive installs you accumulate "very first one"s
<mdz> there's only one VERY first one
<mdz> i.e., if it already exists, use all logicals
<Kamion> mdz: ah, right, well that's basically what I said above, yes
<mdz> in fact it wouldn't have a choice
<mdz> if all the remaining space was occupied by an extended partition
<Kamion> also reusing existing swap partitions in automatic partitioning would help a lot
<Kamion> mdz: extended partitions are extremely fluid when using parted
<mdz> Kamion: it'll resize an extended partition with logical partitions in it to make room for a new primary?
<Kamion> parted generally makes them only as big as necessary to fit around the logical partitions
<mdz> that's extreme
<mdz> oh, on that end you mean
<Kamion> mdz: parted views extended partitions as just red tape
<Kamion> it mostly deals only in primary and logical partitions
<Kamion> which makes things a lot easier to comprehend, for frontends trying to be mostly disklabel-agnostic
<mdz> is it impossible to deal with extended partitions directly?
<mdz> or do we just not do it currently?
<Mithrandir> it's painful to do so, at least.
<Kamion> why would you want to?
<Mithrandir> partman's UI already sucks enough. :-)
* mjg59 spreads the love
<Kamion> when partman goes to resize a logical partition, it first expands the extended partition to fill all the contiguous space it can, then does the resize, then contracts the extended partition as far as possible
<mdz> because in general it's better to have a big extended partition with freespace in it than unpartitioned space which requires a new primary partition to use
<Kamion> mdz: if you tell partman to create a logical partition, it will sort out the extended partition automatically
<mdz> Kamion: but it will make it only as large as it needs to be to accomodate the logical partition
<Kamion> if it's all empty, it doesn't matter whether it's extended or unpartitioned
<Kamion> mdz: yes, but that's entirely irrelevant
<mdz> I'm saying create a primary partition, then swallow the rest of the disk with an extended partition
<Kamion> pointless
<mdz> are you saying that partman can't figure that one out, either?
<Kamion> if partman-auto goes to create logicals, the extended will be resized automatically to cope
<Mithrandir> it might be actively bad in the oem case, since the OEM might want to put a primary at the end of the disk for a rescue partition.
<Kamion> mdz: I'm saying it figures it out already and shouldn't be micromanaged
<mdz> then why does it fail here?
<mdz> it isn't figuring it out; it's crying in the corner
<Kamion> that's partman-auto, not partman
<mdz> ...
<Kamion> you already have three primary partitions, and the partman-auto recipes currently say that / *must* be a primary partition
<Kamion> in that situation it is not possible to create the partitions that the partman-auto recipe calls for
<Kamion> this is a bug in the partman-auto recipe, really; it has nothing to do with handling of extended partitions
<mdz> why? to support people using ineffectual bootloaders which can't read extended partitions?
<Kamion> aside from situations where you can't put a logical partition somewhere because the extended partition is on the other side of a primary
<Kamion> mdz: like I say, it's a bug
<Kamion> but the solution is not to micromanage extended partitions
<Kamion> doing that will only make partman's job harder
<Riddell> is anyone able to test the kubuntu amd64 dvd?
<Kamion> and will ultimately have no useful effect, because you'd have to fix the recipes *anyway*
<mdz> another quarter of an hour wasted because partman insists on being a billion different pieces
<doko> Riddell: I can start to sync it, but will head to bed soon ...
<mdz> if I'd said partman-auto instead of partman a few times earlier, we would have finished this conversation very quickly
<Riddell> doko: that would be great, I still have powerpc to download so no major rush
<Kamion> erm, no, you're saying this strange stuff about extended partitions that just makes no sense either way
<mdz> and the i386 dvd has almost arrived
<calc> the best part about d-i is how the partition program doesn't use real gigabytes, it uses that lovely ieee bullshit, however lvm configurer uses real gigabytes
<mdz> Kamion: it makes sense to me, or I wouldn't be speaking it
<Kamion> mdz: I've found that when dealing with PC partition tables it is best to forget entirely about extended partitions unless you're actively dealing with the low-level table constraints stuff
<mdz> Kamion: a good strategy for not running out of primary partitions is to stop using primary partitions wherever possible and use logical partitions instead
<Kamion> just dealing in primaries/logicals is so much more straightforward, and all you need to remember is that the logicals must be contiguous
<Kamion> mdz: I certainly don't disagree
<mdz> Kamion: now I have expressed my idea without using the term 'extended partition'
<Kamion> right :-)
<ogra> *g*
<hno73> mdz: I've posted the 5.10 release notes here: http://www.ubuntu.com/support/releasenotes510 It's just a copy of the wiki version with some HTML clean-up. It's not yet 'published' so you have to be logged in to see it. Let me know when I should publish it (or alternatively just link to the wiki version).
<Kamion> mdz: I'm afraid I've been utterly bogged down in the details of late, so perhaps I'm taking things too literally
<mdz> hno73: I'm wary of having so many copies of the release notes; they're already in the wiki, the release announcement, the ubuntu-docs package and now this one
<mdz> 1.5 hours to get breezy-dvd-i386, gar
<hno73> mdz: right. shall I just do a link to the wiki one from the website then?
<dholbach> good night guys, i'm off to bed
<ogra> mdz, 
<ogra> breezy-dvd-i386.iso
<hno73> mdz: the advantage of the website one is that it cannot be changed by random people
<ogra>    675333475  27%   89.00kB/s    5:41:28
<ogra> thats nothing
<dieman> heh
<_mvo_> night dholbach 
<dholbach> nicht michael
<Kamion> doch
<daniels> Keybuk: pizza express cheesecake is overrated
<ogra> dholbach,  night holbi
<dholbach> haha
<Keybuk> daniels: I agree, but elmo doesn't
<mdz> hno73: so far all of the changes from random people have been of reasonable quality, but yes, that's a concern
<dholbach> grawi :)
<ogra> ;)
<_mvo_> ogri
<elmo> the pe cheesecake will have the last on you all
<ogra> dholbach,  thats how they called me at school ;)
<ajmitch> heh
<jbailey> ppc64 live dvd is good, same cdrom eject problem
<mdz> hno73: how long ago did you copy it?
<dholbach> :)
<jbailey> (waited 90 seconds for it)
<mdz> hno73: it seems to be missing the oem install instructions that Kamion added to the wiki
<bob2> after a hard days work, you need a nice cold be^wcheesecake
<hno73> mdz: ~45 minutes ago
<Kamion> mdz: (FWIW, I didn't add most of them, they were there before I got there - I did correct them more recently though)
<mdz> hno73: oh, I see, it's just further down in your version
<mdz> hno73: looks fine to me
<hno73> mdz: I think the structure is the same
<mdz> hno73: maybe I'm crack-addled then; I thought it was directly under Desktop and Server before
<hno73> Default and Server
<Kamion> powerpc/oem ok, apart from a frankly bizarre default language choice offered by oem-config
<hno73> just above known issues
<mdz> Kamion: ah, it was jsgotangco
* infinity wakes up to an INBOX full of build failures and sighs.
<mdz> Kamion: who added the oem stuff yesterday
<Kamion> sounds right
<doko> correct, that server install doesn't show the splash screen?
<Kamion>  2. Note login sound, if equipped with appropriate hardware
<hno73> mdz: I can check the wiki version tomorrow for important changes and port them over
<Kamion> there's a login sound?
<Kamion> doko: yes
<mdz> Kamion: you don't hear the login sound?
<infinity> Kamion : Yes, there's a login sound.
<Kamion> perhaps it's very quiet compared to app launches or something
<Kamion> mdz: don't seem to
<mdz> Kamion: it's very quiet on the headphone jack of this G4 at default volume
<mdz> but it's quite impossible to miss on the other machines
<Kamion> that could be it; sound played through this laptop speaker is not ideal
<infinity> Is universe closed yet, or can I upload fixes for this last round of build failures?
<Kamion> mdz: ah, I can hear it if I put my ear right against the speaker
<\sh> infinity: clisp?
<mdz> Kamion: powerpc systems seem to have wildly differing ideas about what's loud
<infinity> \sh : haskell-http, 2vcard, clamassassin, clisp...
<Nafallo> "And up to now, the buildds are not closed." according to \sh's blog :-)
<mdz> \sh will continue to upload until someone throws the switch
<\sh> no
<mdz> \sh: no? ;-)
<ajmitch> if I have time I've still got a few non-urgent uploads to put together :)
<\sh> mdz: 2005-10-13 00:30 UTC <--- date + time of stopping my work...
* Kamion reads a bit of the starter guide
<Kamion> deb cdrom:[Ubuntu 5.04 _Breezy Badger_ - Release i386 (20050407)] / breezy main restricted
<Kamion> uh-huh
<Nafallo> lol
<ogra> Kamion, dont do that, it causes bad dreams
<Kamion> mdz: it's just strange that one sound is very quiet while the others are quite load
<Kamion> loud
<infinity> Kamion : They're not that drastically different on my laptop...
<jammcq> hey guys, everybody sleeping after the awesome release?
<ogra> jammcq, after ??
<infinity> Kamion : OTOH, I'm probably going to re-floor all the sounds in dapper anyway, since our sounds ARE too loud.
<ajmitch> jammcq: we're still going..
<Nafallo> infinity: they are?
<jammcq> oh, I was watching the fridge.ubuntu.com, and it was doing a countdown earlier
<infinity> Nafallo : Quite, yes.
<mdz> Kamion: oh, you hear the other sounds? that is odd
<Nafallo> jammcq: don't trust the fridge dude ;-P
<Kamion> jammcq: fridge has an interesting idea of when the release is - interesting but wrong (time-wise - it's right date-wise)
<mdz> they're not very different in volume here at all, either
<Kamion> jdub: can you fix the way fridge thinks the release is 00:00?
<Nafallo> infinity: it was perfect here with preview :-)
<infinity> Nafallo : Watch a DVD or something.  Stop the DVD.  Launch an app.  Watch your speakers visibily pop.
<jdub> Kamion: when do you want it set?
<jammcq> heh, I figured if I read it on the internet, it must be true :)
<Kamion> sometime in the future would be a good start
<jdub> :-)
<Nafallo> infinity: oh. will try that next time :-)
<Kamion> I don't particularly want to set precise expectations; does it have to be given a time?
<jdub> it's an event
<crimsun> "we'll release by october 13, 2006" should cover it :-)
<jdub> Kamion: ok, i've given you 12 hours ;)
<Nafallo> jdub: events can't last from say... 00:00 to 23:59? :-)
<Kamion> jdub: ta
<Kamion> will do for the moment
<jdub> well, yes, but then it will be NOW for the whole day
<daniels> infinity: to be fair, DVDs are incredibly quiet compared to anything else
<mdz> jdub: when will NOW be THEN?  SOON!
<jdub> mdz: hahahahaha
<Nafallo> :-)
<\sh> so guys...laying in bed and waiting
<Nafallo> \sh: well, I'm not going to join you this night ;-)
<\sh> Nafallo: hahahha
<infinity> daniels : Yes, DVDs are quiet for a good reason, though.
<infinity> daniels : Mainly that if you use the full 16/44.1 range provided to you by modern sound systems, you don't NEED everything to be full envelope for it to sound good (so you can reserve most of that envelope for things that actually ARE loud)
<daniels> infinity: right
<daniels> infinity: but I'm just saying, possib;ly not the best benchmark to compare everything against
<elmo> did someone mention glxgears?
<daniels> (i'm familiar with the problem of modern CDs, being that they're generally amplified to shit, to the point where you WHAT
<daniels> elmo: ... what about glxgears
<infinity> daniels : <shrug>... System sounds should be subtle.  If a system sound while playing a DVD makes your head explode, I think there's an issue. :)
<daniels> elmo: oh, I see.  nm.
<daniels> elmo: i think we need a new benchmark though.  'my video card is as good as 7.3 pizza express cheesecakes.'
<daniels> 'dude, how fast is concordia?' 'at least 5.9 pecs'
<\sh> hmmmm
<\sh> this speaker of this portege r200 sounds like those old small little mobile radios
<mdz> amd64 is the first to go gold, CD and DVD
<doko> hmm, server install on i386 fails (on a logical partition, /dev/hda7): exiting on error base-install/cannot_install 
<Kamion> there should be useful stuff in /var/log/{messages,syslog}
<mdz> Kamion: how are your powerpc tests going?
<Kamion> mdz: normal install in archive-copier
<Kamion> all looks fine so far
<Kamion> unfortunately my bizarre network arrangements here mean that I have to wait for the laptop to come back before I can start rsyncing the DVD
<Kamion> so it may be a while; I expect to be up until release now, I think
<desrt> man.  breezy = busted
<mdz> I'm in the same boat; the laptop owns the DVD burner here
<Kamion> mdz: in this case it's because the machine with the disk space is only connected to the outside world via the laptop
<desrt> there's a lot of small issues that just never got fixed :/
<mdz> desrt: this is not a good place to vent right now; release time is stressful enough
<Kamion> there are always a lot of small issues that never got fixed
<desrt> not venting.  a lot of the problems don't affect me or will soon not affect me
<desrt> but point taken.
<Kamion> welcome to time-based releases ...
<ogra> *SIGH*
<ogra> my CD is definately corropted argh
<\sh> at least we like the SM way...pleasure and pain 
<Kamion> mdz: are you going to test the i386 DVD next? wondering which to grab
<doko> Kamion: no, not really. some DEBUG messages, then the error message I typed in. The installer adds "No installable CD-ROM was found and no valid mirror was configured". The same DVD from which I completed the "erase disk install"
<desrt> one big problem for example is that i can't find my wireless network card and therefore wireless networking isn't working :)
<bob2> desrt: really really not a place to vent
<mdz> Kamion: I have i386 already downloaded; once powerpc finishes I'll test them in parallel
<mdz> another 60-90 minutes
<Kamion> doko: if you completed the install from that, I don't see how a server install would break
<Nafallo> \sh: yea, those are the same :-)
<speel> well i think you guys are doing a great job :)
<doko> Kamion: restarting ...
* desrt thinks so too
<mdz> thanks, folks
<speel> np
<Kamion> doko: that error message is displayed when there's an error reading /cdrom/.disk/base_components
<\sh> ogra: when finance department transfered the tax back money until friday...let's add 3x24 bottles ,)
<Kamion> mdz: I'll be a good two or three hours behind that. oh well
<mdz> Kamion: you planning to sleep at some point?
* _mvo_ goes to bed now
<doko> _mvo_ ping
<ogra> \sh, yeah
<mdz> he was not kidding
<ogra> heh
<doko> well, that was quick :)
<\sh> ogra: and one/two bottles of suses fav taste of drinks ;) 
<Kamion> mdz: not properly until after release, I think, unless it really gets drawn out
<ogra> \sh, some good whisky will do... 
<ajmitch> \sh: put some in your suitcase for UBZ, please :)
<\sh> ogra: that's what i meant
<ogra> ajmitch, duty free ;)
<\sh> ajmitch: for this ping riddell ;)
<Riddell> hmm?
<doko> Kamion: works the second time ...
<Riddell> ahh
<ogra> heh
<\sh> Riddell: whisky is your area where the good stuff comes from
<Riddell> true
<Kamion> doko: ok
<\sh> Riddell: and some remarks: all the people running kubuntu on their laptops in our company..they fell in love with the new kdm/splash theme
<Riddell> \sh: oh cool
<\sh> Riddell: and good thing..amarok 1.3.3 crashed for me 4 times today...different causes, same result
<\sh> Riddell: 2 causes I can reproduce 
<Robot101> ogra: gnome-power-manager was so broken. I got mjg59 to fix it. there was no alcohol involved. honest.
<ogra> Robot101, i dont belive you...
<ogra> Robot101, but nice that he fixed it even if he was drunken :)
* Robot101 did the patch... it wasn't hard :)
<Robot101> -NICE_NAME +argv[0] 
<ogra> i guess so
<Riddell> \sh: oh...good
<\sh> Mithrandir: I wasn't complaining about a missing hwinfo...I was complaining about the speed of opensuse...
<calc> is the ubuntu/kubuntu dvd install disk going to be merged eventually, aiui both disks have all the files but just not able to install the other version?
<Mithrandir> \sh: ah, that wasn't clear. :-P
<\sh> Mithrandir: the speed was <=0
<daniels> sweet jesus, you only *just* stopped working on universe for breezy?
<\sh> Mithrandir: but anyways...the new source needs a kernel patch from suse year 2003 i think
<Keybuk> he's stopped?
<daniels> calc: how the christ do you expect to fit both kde and gnome on a single cd?
<daniels> Keybuk: p.u.c
<Riddell> daniels: dvd
<calc> daniels: yea dvd, aiui the dvd has all of main on it already
<dieman> not everyone has a dvd burner yet
<dieman> ;)
<elmo> daniels: who's stopped? :/
<\sh> daniels: I? well..i don't want to be the fool who upload the last piece of software which blow up the buildds
<calc> the dvds are only using 2.5 out of 4.5 GB as well
<doko> Kamion: Pressing F1 on boot ... "This is an installation ... built on 20050317ubuntu19"
<desrt> how far away is the absolute-last-minute for changes?
<Keybuk> desrt: about a week ago!
<desrt> oh crikey
<desrt> well... libgphoto is segfaulting on ppc when you try to load pictures off your camera using the gthumb GUI or the commandline tool
<Keybuk> ouch
<bob2> reporting that before the dvds were being built might have been more optimal
<Keybuk> does it with the default thing g-v-m fires up?
<desrt> bob2; i discovered it this weekend while disconnected from the net
<desrt> Keybuk; yes.
<Keybuk> anyone else got a ppc machine to check?
<desrt> bob2; and when i got home i had a gigantic heap.  i've only just opened my laptop up now
<ogra> \sh, the last package is the cherry on the cake, you really want to miss that ? 
<daniels> elmo: \sh
<Kamion> calc: that's not accurate actually, the Ubuntu DVD contains all of Ubuntu supported whereas the Kubuntu DVD contains all of Kubuntu supported; neither of those constitutes all of main
<desrt> Keybuk; before getting too crazy, i have about 300 updates to install.  it might fix itself
<ajmitch> desrt: last upload of libghoto was > 2 weeks ago? noone saw the bug since that upload?
<calc> Kamion: oh
<\sh> ogra: be my guest to upload the last one, boss :)
<desrt> ajmitch; shrug.  i usually use my PC to load photos from my cam... only using laptop since i was at the cottage for the longweekend
<Kamion> doko: the text is suboptimal, but it's actually reporting the version number of debian-installer
<ogra> \sh, i already did that for main ;)
<ogra> ah, noo.. not true...
<\sh> ogra: so lets w8 for barry
<ogra> mjg59, did the last one
<ajmitch> \sh: his box is still dead
<Kamion> I'm not sure where my camera is unfortunately
<\sh> oh...
<ajmitch> \sh: I could probably still upload something if you want :)
<calc> Kamion: does the union of ubuntu and kubuntu supported cover all of main?
<\sh> ajmitch: so u r the one 
<Keybuk> calc: a subset of it
<Kamion> calc: there's Edubuntu too ...
<\sh> ajmitch: if *I* want?
<Keybuk> not to mention the server stuff
<ajmitch> \sh: sure
<Keybuk> which I so want to call 1ubuntu
<robertj> Edubuntu makes me sad :(
<calc> Kamion: maybe a better question is if all of main is supported by all least one project ;)
<Kamion> Keybuk: currently that's drawn from within Ubuntu supported
<Kamion> Keybuk: you're on crack, dude
<ogra> robertj, ??
<ajmitch> robertj: why?
<Kamion> calc: nope
<Keybuk> Kamion: supported == main
<Kamion> Keybuk: bzzt, wrong
<calc> so how do users know if main is supported?
<Keybuk> no?
<robertj> ajmitch: brand fragmentation and such
<\sh> ajmitch: it must be your wish...i'm relaxing and reading and smiling about all the things we managed
<Kamion> was true once but not since Kubuntu arrived
<calc> you could accidentally install stuff that doesn't get security updates?
<Kamion> main is the union of the supported outputs of all projects
<dieman> Kamion: so now how do we figure it out as to what gets security updates and what doesn't
<desrt> Kamion; so kubuntu supports gnome?
<ogra> robertj, brand fragmentation ??
<dieman> this is all too confusing.
<Kamion> calc: don't get too hung up on the "Ubuntu supported" term here, it's semi-historical
<robertj> ajmitch: Do we really need a Churbuntu, Govuntu, Mediabuntu, etc?
<daniels> and then there's universe, which is totally unsupported, which no-one ever touches.  no updates here, move along please.
<desrt> er.  nm.
<Kamion> everything in main gets security updates and is supported in most senses you care about
<calc> Kamion: ah ok :)
<dieman> Kamion: ok.
<ogra> robertj, its a official project whats wrong with using the brand name for it ? 
<Kamion> Keybuk: katie/cron.sync would make your head hurt, I suspect
<robertj> ogra: nothing wrong, I just think it's silly that it's a subproject
<elmo> cron.sync makes MY head hurt
<dieman> heh
<infinity> \sh : It might be a cold day in hell before clisp builds on all (or even most) arches.  It doesn't have a history of building well anywhere.
<ogra> robertj, it has very different targets
<robertj> ogra: I run Ubuntu without problem at my institution
<elmo> infinity: if you could free up some space on king, at some point, I'd appreciate it
<ogra> robertj, thats fine
<Keybuk> Kamion: oh, why?
<\sh> infinity: hmm...strange thing that it builds fine on amd64 and in my i386 pbuilder...well...
<dieman> so is it likely to see cd images in 12 hours, or should I not stay up late to initiate a sync on my mirror? :)
<Kamion> Keybuk: mad munging of germinate outputs
<Keybuk> heh
* daniels upgrades to xserver-xorg 6.9.99.0-1, again.
<Keybuk> germinate was written for simpler times
<Keybuk> and even then it was a head-ache
<Kamion> dieman: I'm actually sorting out pre-publishing now ...
* desrt has a relatively boring 6.8.2-77
<robertj> ogra: what needs do they have that are education-specific?
<dieman> Kamion: ok
<ogra> robertj, we dont target "institutions" we target schools
<daniels> Keybuk: you should rewrite germinate
<dieman> Kamion: i'll check in later then
<Kamion> the symlinks in releases.u.c/breezy/ won't change for some time, but we can get you most of the data before that
<infinity> \sh : It seems to depend on phase of the moon and other such factors.  I can retry it a few times for kicks, it's not like the buildds aren't idle anyway.
<daniels> Keybuk: that is, when you get bored of rewriting hct/dpkg/launchpad/hotplug/udev/other things that seem to work
<daniels> s/seem/&ed/
<dieman> Kamion: ok
<\sh> infinity: leave it then...u have higher prios to deal with, but thanks for looking :)
<dieman> Kamion: i've got a machine i can use for some torrents too
<dieman> see if i can piss off the networking security people
<Kamion> ogra: sorry, I never did get round to publishing that Edubuntu RC
<ogra> robertj, we had a summit where we invited teachers and educational IT staff and now we build what they asked for... 
<dieman> they always love 300mbps+ bittorrents
<Kamion> ogra: there seems little point now :)
<mdz> jdub: doh, we're too late for LWN
<dieman> but they know its me, so its ok
<infinity> \sh : All the other universe build failures from overnight are dealt with, though.
<ogra> Kamion, and i didnt want to poke you after *that* day and there already was no point for it yesterday anymore ;)
<robertj> ogra: I mean, if you want thin clients that are easily managable ,what does it matter if you are running an elementary school or a small business?
<Kamion> ogra: right ...
<Kamion> ah well
<ogra> robertj, our desktop is trageting a totally different audience than the ubuntu desktop... an additional target is to make the install stupidly easy so even my mother cold install a ltsp server
<\sh> infinity: serious...leave it...i'll deal with it from tuesday on (if the timeframe of sabdfl is correct)...
<infinity> Kamion : Which amd64 livefs build are you using?... 20050512.3 (current)?
<mdz> NOOOO
<mdz> rsync: write failed on "/home/mdz/cd/ubuntu/breezy-dvd-powerpc.iso": No space left on device (28)
<ogra> argh
* ogra comforts mdz
<Kamion> infinity: whatever's current
<desrt> excellent.  more time.
<desrt> :)
<mdz> desrt: why does that make you happy?
<robertj> ogra: I don't see why a terminal server should be difficult to set up for anyone though
<infinity> Kamion : Kay.  I'm going to clean a few older ones.  We've had 12 in the last 48 hours.
<Keybuk> \sh: what happens on tuesday?
<desrt> mdz; i'm pretending that i have some non-zero chance of getting changes into the ppc dvd
<ajmitch> Keybuk: we get to start this mess all over again
<mdz> desrt: /topic
<ogra> robertj, and i dont see why you should even have to bother with setting it up...
<ajmitch> aka dapper
<Kamion> infinity: that's fine
<desrt> mdz; this is a reasonably large 'that'
<doko> jdub: "Your message to Universe-bugs awaits moderator approval". Please fix it
<ogra> robertj, in fact all work done for edubuntu is done *in* ubuntu, so both win
<\sh> Keybuk: sabdfl was announcing the next round on tuesday..
<infinity> Kamion : Same for other arches?... current in use, others aren't wanted for rollback/historical reasons?
<desrt> mdz; even so, though, i -am- just pretending :)
<Kamion> infinity: save two before current for pure paranoia
<Keybuk> ah, the heady optimism that launchpad will be ready by Tuesday :p
<infinity> <nod>
<ogra> robertj, but its a totally different product so it deserves a different but familiar branding
<doko> just commenting on a malone report
<robertj> yeah, but being a totally different product is what I don't like I guess
<ajmitch> Keybuk: of course, we have faith in the launchpad team :)
<ogra> robertj, but all pieces, every byte is ubuntu content... so if i develop a LDAP usermanager GUI for my next edubuntu release, ubuntu will have it too...
<\sh> Keybuk: well...I don't mind at all..i need some time to relax...
<robertj> ogra: yeah, I know, but I still think its a mistake, but I think were both clear on the pros and cons
<robertj> ogra: btw, have you looked at Erudite Directory Services?
<Keybuk> nah, it's all good; elmo is personally making sure it's all ready in time
<\sh> it's really scaring me, when I look in the mirror every morning and think...."shit, who is this guy who is looking at you"
<TiMiDo> hey everyone
<TiMiDo> i have a question how can i help around ubuntu?
<elmo> keybuk: choke on my... code of conduct
<elmo> :-P
<jeff_> could the maintainer of sabayon update it to the most current release before breezy? It is a great package and in univers
<ogra> \sh, as long as you dont say "hi santa" everything is still fine :)
<jeff_> But it doesn't work right now
<TiMiDo> /join #ubuntu-love
<jeff_> And the new package released by markmc does
* TiMiDo wants to help around
<\sh> ogra: DUDE...please...before this happens i'm nominated as the new pope
<ogra> giggle
<dieman> heh
<infinity> elmo : Disk space all over the world again.
<crimsun> TiMiDo: please read http://www.ubuntu.com/community/participate/
<dieman> whats with the pony graphic on the fridge. 
<\sh> jeff_: please ask in -motu
<daniels> jeff_: see the topic
<doko> Riddell: the kubuntu live dvd didn't let me select a network interface (having two interfaces)
<jeff_> daniels: So there is no way it will get fixed?
<doko> Riddell: where to report kubuntu results?
<wasabi_> So I got unionfs working pretty much perfectly.
<wasabi_> In case anybody was wondering.
<Keybuk> dieman: http://www.netsplit.com/tmp/no.jpg
<dieman> Keybuk: yeah, i clicked on it too ;)
<dieman> Keybuk: but uh, wtf?! :)
<\sh> jeff_: ask in -motu i think we have the time ... if anybody is in the mood to risk something
<dieman> its so random, its like someone on a caffene trip put it there.
<mdz> doko: that's by design
<Keybuk> dieman: heh, he's changed it to give that image now? :P
<Keybuk> sweet
<mdz> doko: it doesn't ask
<dieman> Keybuk: http://fridge.ubuntu.com/files/no-pony-for-you.jpg
<Keybuk> dieman: yeah
<doko> mdz: ok
<daniels> the next person who says 'upgrading to brezy was a breeze' will get stabbed to death with a knife engraved with the code of conduct
<jeff_> \sh: thankyou
<Keybuk> daniels: because they'd be lying?
<daniels> also, according to the forums, the compost extension will make our desktop look rad, so we should all use composting
<\sh> daniels: ? yesterdays morning it was smooth but that was yesterday...gna 
<Keybuk> X -iagreethatthisisnotausefulenvironment
<\sh> hey bddebian happy badger day
<bddebian> Heya \sh. Thanks, but not for me yet ;-)
<daniels> Keybuk: dude, glxgears -printfps.  so go choke on elmo's code of conduct.
<doko> Kamion: autoresize creates a new swap, even if one already exists
<doko> Riddell: the OOo2 icons in kubuntu look so ugly ...
<\sh> bddebian: oh yes...u have how many hours left?
<Keybuk> Kamion: for next release, could we put a little "5.04" or something on the grub splash
<bddebian> \sh: Depends.  Are we counting at midnight? :-)
<Keybuk> because I'm getting very confused which CD is which here :p
<Riddell> doko: are you using the amd64 dvd?
<doko> Riddell: yes
<\sh> bddebian: yes 
<Riddell> doko: that's the one without openoffice.org2-kde then :)
<doko> Riddell: copying the ubuntu dvd before syncing did help ...
<Riddell> doko: how come amd64 doesn't have openoffice.org2-kde?
<doko> Riddell: not sure, Mithrandir did want to add it, didn't he?
<bddebian> \sh: Oh, then I only have 2 hours.  Should I upload something catastrophic? ;-P
<daniels> Keybuk: '6.04'
<Keybuk> daniels: uh, yes, OBVIOUSLY that's what I meant :p
<\sh> bddebian: relax friend :) 
<Keybuk> spending too much time at Earl's Court
<ajmitch> bddebian: please do :P
<Mithrandir> Riddell: you never responded to my questions about it and how to get it to work properly.
<daniels> good breakfasts
<dieman> do we have a chance in hell in seeing a native openoffice.org for amd64 someday?
<Keybuk> I was actually just thinking of the TARDIS parked outside
<Keybuk> but yes
<bob2> good muffins
<doko> daniels: do you and gravity have plans to sync the -dev names of the xorg mesa packages?
* bob2 prizes his photo of the tardis
<daniels> doko: no, we plan to keep them apart for eternity, and change them randomly at each debian and ubuntu release
* doko notes dieman wants to port ooo to amd64
<dieman> daniels: heh.
<dieman> daniels: misfire
<dieman> doko: heh
<doko> daniels: yeah
<Amaranth> daniels: sounds like fun
* TiMiDo wants to be part of the team
<\sh> Keybuk: tardis? u don't mean dr. whos tardis?
<Mithrandir> dieman: we have one, but it's extremely unstable.
<bddebian> daniels: ;-P
<Keybuk> \sh: there's a real police box outside Earl's Court station in London
<bob2> \sh: right on the footpath
<dieman> Mithrandir: pout. oh well.
<Keybuk> which obviously looks a lot like Dr Who's tardis, yes
<wasabi_> Hmm. usplash simply won't work on this system I guess.
<wasabi_> how sad
<daniels> and also SOOT bins
<\sh> Keybuk: next time when I visit london u have to show me the places ... and actually a record store where i get a first release in white milky vinyl of f.g.t.h. welcome to the pleasuredome...the last time when i was in london, no record store wanted to sell me one :(
* mdz hardlinks the rsync temporary file this time GRRR
<Keybuk> vinyl?  what's that
<daniels> Keybuk: blasphemy
<\sh> u know these black sometimes colored discs u put on something with an arm and a diamond needle?
<wasabi_> wonder if I can at least turn off the text somehow
<wasabi_> like, switch to another VT or something
<\sh> hehe
<mdz> Keybuk: vinyl is what pleather is made from
<doko> Riddell: kubuntu live dvd looks ok
<Riddell> doko: cool, going to do an install?
<doko> hardly awake, will do ...
<seb128> k, time to sleep, 'night
<Kamion> doko: swap> #7557, #12499, etc.
<mdz> seb128: good night
<daniels> night sebarino
<bddebian> Gnight sebest 
<Kamion> Keybuk: sure, if given an image
<mjg59> ENTIRELY UNDER CONTROL
<bddebian> Err seb128
<mdz> mjg59: you? never!
<desrt> uhm.  this gphoto crasher will happen on all architectures, i think
<desrt> is it really really too late?
<mjg59> mdz: Situation is entirely nominal
<mdz> desrt: YES IT IS
<daniels> mjg59: autopilot DISABLED
<desrt> suck
<mdz> mjg59: you have been drinking whiskey
<Kamion> desrt: we can fix things like that in breezy-updates, if necessary
<Amaranth> desrt: breezy-updates or breezy-backports :D
<\sh> mjg59: btw...congrats for nomination to the TB
<mdz> desrt: we are only stopping for, er, showstoppers
<mdz> and that isn't
<desrt> mdz; crashing on import of photos is pretty big
<bob2> desrt: but not as big, say, as elmo launching icbms at your house
<mdz> desrt: even if it crashed EVERY time ANYONE imported photos (which it doesn't) that still wouldn't be a showstopper for the release
<desrt> bob2; well, that would only affect me :)
<Kamion> desrt: put it this way, it has to be serious enough for us to throw away eight hours of testing and embark upon another four/five-hour build cycle and a further dozen or so hours of testing
<desrt> mdz; ok.
<doko> desrt: it's a content filter
<Kamion> I'm making up the numbers somewhat but that's close enough
<desrt> -updates it is, then :)
<Keybuk> Kamion: how long is d-i going to test the network repository for?
<Kamion> mdz: all release CD images are syncing to the .pool directories on releases.u.c now; not changing symlinks for some time yet, obviously
<Kamion> Keybuk: iz apt bug
<mdz> Kamion: thanks
<Kamion> I don't remember the current figure
<Mithrandir> Keybuk: it should take < 5 minutes total.
<Mithrandir> iirc
<Keybuk> right-o, it's been about 4 so far
<Kamion> Keybuk: are you behind a lame proxy that DROPs packets rather than REJECTing them?
<Mithrandir> Kamion: it shouldn't matter.  It should time out in < 60 seconds per request, iirc
<mdz> Kamion: does that include the server images?  or are those not going to releases?
<Kamion> Mithrandir: I think it's faster if packets get rejected. I had a test framework here for it once ...
<Kamion> mdz: oh, I forgot about server, will do that now I guess
<Keybuk> Kamion: no, I just unplugged the network cable to stop it getting to the repository
<mdz> Kamion: I haven't tested those yet
<mdz> Kamion: have you?
<Keybuk> otherwise it would've automatically installed the security updates
<nayif> http://bugzilla.ubuntu.com/show_bug.cgi?id=17555 , http://bugzilla.ubuntu.com/show_bug.cgi?id=16629
<Kamion> mdz: fabbione did, I think; I've got a download somewhere around here that I'll test
<mdz> Kamion: but not the latest build
<Keybuk> Mithrandir: is there any message for each time it's timed out?
<Keybuk> ah, it just timed out the first one
<Kamion> mdz: I'll do so as soon as I can
<Mithrandir> http://bugzilla.ubuntu.com/show_bug.cgi?id=8265 ; it should use 2 x 120 secs with the fix mvo committed
<Kamion> Keybuk: hoary's worse for this than breezy is
<Keybuk> just over 5 minutes then
<Keybuk> Kamion: this is hoary, actually
<Kamion> Keybuk: IIRC in hoary it was something crazy like 40 minutes
<mdz> Kamion: me too; I wonder if rsyncing against a dvd iso would work well
<Mithrandir> Keybuk: yeah, hoary is insane.
<Mithrandir> or s/Keybuk/Kamion/
<mdz> Kamion: interesting; aptitude sucked in the CD in the tray during base-config
<Kamion> nifty
<mdz> never seen it do that before, but I don't think I ever gave it the chance either
<Keybuk> used to do it to me all the bloody time
<Keybuk> when I had the tray-less drive and never bothered to remove the CD
<nayif> Kamion, you ask me to report the bug on a way it can be manageable on this bug http://bugzilla.ubuntu.com/show_bug.cgi?id=16629 , and i report it again on http://bugzilla.ubuntu.com/show_bug.cgi?id=17555
<nayif> and i test it again like you ask me on RC
<Kamion> nayif: I'm not responsible for GDM or GNOME, so I can't help you with that
<Kamion> nayif: I responded to the original bug because it got assigned to me
<mdz> Kamion: perhaps we should remove the RC images from releases?
<doko> Riddell: kubuntu dvd install succeeded, I hate to say, it "feels" snappier than the gnome desktop
<Kamion> mdz: can't do that until the symlinks in breezy/ switch over
<ogra> doko, if you hate it, just dont say it :)
<Riddell> doko: excellent :)
<ogra> Riddell, congats
<Riddell> ogra: hang on, I havn't tested the i386 DVD yet :)
<nayif> did ubuntu will be out with this bug on gonme with broken text on menu and GDM ?
<mdz> nayif: /topic
<ogra> Riddell, you got far more than me... i can only test x86 CD here and that one just turned out screatched :(
<mdz> Kamion: are you any closer to a powerpc dvd than I am?    1832560384  58%  456.84kB/s    0:48:19
<Kamion> mdz: I'm still testing the powerpc CD image. no
<Kamion> and I probably won't bother now, will test ubuntu-server instead
<Riddell> ogra: why can't you test amd64?
<doko> mdz: are you doing the oem dvd i386 install?
<ogra> Riddell, because my DVD writer on the lappie is broken :/
<mdz> the server isos are mentioned in the draft release announcement
<mdz> doko: yes, it's almost finished
<ogra> Riddell, thats the only amd i have and the only DVD writer...
<doko> ok, then I don't start it
<jbailey> Now to try and get the crap on my hd down under 30gb
<mdz> s/crap/pr0n/
<Riddell> ogra: I know how you feel, my new amd64 lasted 2 days before blowing up last week
<ogra> ouch
<ogra> the nice one you blogged about ? 
<daniels> 'nice'?
<ogra> shiny
<Riddell> yes, all those fancy lights don't do much good if it died on you
<daniels> blue LEDs  nice
<Riddell> daniels: blue, red and green.  very tasteful.
<ogra> daniels, agreed, i thought it had more colors
<ogra> ah
<Keybuk> Riddell: mine hasn't arrived yet
<Keybuk> I ordered a processor that's not yet been released, so am still waiting
<bob2> of course you did
<jbailey> When I bought mine a month or so ago, I bought the oldest one I could find on the market to avoid these problems.
<jbailey> Mostly on the assumption that if they were still selling it, it couldn't be that horrible.
<daniels> my amd64 just, y'know, worked
<lifeless> mine did, after I took it back
<dieman> heh
<dieman> are there any faster mirrors? :)
<Kamion> mdz: (ubuntu-server pre-published a while back)
<dieman>   1195409408  43%  767.12kB/s    0:33:17
<mdz> Kamion: dvd->ubuntu-server is a huge win
<mdz>    592136192 100%    3.91MB/s    0:02:24  (1, 100.0% of 1)
<Kamion> mdz: that would be great if I had any DVDs yet
<dieman> mdz: heh, which server is that from? :)
<Kamion> but noted for future reference :-)
<Kamion> dieman: it's rsync based on an image which already has most of the same contents
<dieman> ahh
<mdz> Kamion: wow, server came out more full than I expected
<dieman> i didn't notice releases is a dns round robin
<doko> heading to bed, good night
<mdz> doko: good night and thanks
<Riddell> thanks for testing doko 
<ogra> night doko
<Kamion> mdz: yes, I was interested to see how close it was
<Kamion> mdz: I didn't think you'd checked the size in advance
<Keybuk> hmm
<Keybuk> that's a new one
<Keybuk> word list question during hoary->breezy upgrade
<Kamion> Keybuk: Diziet encountered that too; I posted to ubuntu-devel@ about a related problem a while back - look for dictionaries-common
<Keybuk> yeah it was dictionaries-common/default-wordlist
<\sh> ok...i'll close my eyes for a while...
<sistpoty> gn8 \sh
<mdz> Kamion: have I got my ISOs crossed, or does the ubuntu-server isolinux text still say desktop/laptop, type 'server', etc.
<ogra> night \sh 
<\sh> please send a ctcp sound release_alarm.ogg to me if everything's settled...I won't here it but i think it's a nice joke
<mdz> \sh: good night
<\sh> -here +hear
<ogra> \sh, i could call you :)
<\sh> ogra: do it when u don't sleep as well :)
<Kamion> mdz: the isolinux text is fiddly to update, unfortunately
<ogra> i doubt i'll get sleep, lest see
<ogra> *lets
<Kamion> if you want me to try to update that now, I will
<mdz> Kamion: not if it's fiddly
<Kamion> (it can be done in the CD build process)
<Kamion> I don't really trust myself to get it right at the moment
<Kamion> although I could update the initial screen safely
<\sh> ogra: k...call me when ever u like :)
<mdz> Kamion: these are quick to test; we can roll them tomorrow
<Kamion> ok
<mdz> I've updated the announcement accordingly
<mdz> ogra: how are you doing on testing?
<ogra> mdz, had a scratched CD here took a while to get that fixed... 
<ogra> doing my last test (default install i386) now
<mdz> ogra: what have you tested already, and what remains to be tested?
<ogra> server and workstatio were fine
<ogra> DVD x86 and probably the amd64 iso... 
<mdz> you have 12 tests to do, right?
<mdz> (server,workstation) x (i386,amd64,powerpc)
<ogra> i'm finishing the 3rd ://////7777
<mdz> + DVDs
<jsgotangco> ugghh
<mdz> ogra: are you rethinking your position on the DVDs yet? ;-)
<ogra> i'm not after testing amd64 or ppc DVDs if its not absolutely necessary
<ogra> but i'd like to know x86 works...
<mdz> we can hold them back from the release, but we won't release untested images
<ogra> i'll get some HW tomorrow, probably i can make a ppc and x86 test then...
<ogra> (DVD that is)
<mdz> ogra: this is edubuntu's first public release; we can be conservative in what we ship this time
<Kamion> sometimes I wish we could do releases from an office/lab; we could fill it with DVD burners, a really fast pipe, test machines, and lots and lots of coffee and sugar
<mdz> ogra: we can also release with only CDs, test the DVDs tomorrow and release them iff they work correctly
<ogra> mdz, ok... so a amd64 and ppc CD iso test would be needed i guess
<jbailey> Ooo, only a million and a half files to rsync to the other ox.
<ogra> mdz, yes, that'd be fine with me...
<elmo> Kamion: well, you're welcome to do it in the DC, if you want - it's not a pleasant working enviroment, but it has all of that except for DVD burners
<mdz> ogra: so again, which tests  have you done?
<ogra> we just agrred to have a DVD if possible on the summit, i dont want to dissapoint sabdfl
<mdz> elmo: WHAT'S THAT?  I COULDN'T HEAR YOUR SUGGESTION OVER THE FANS
<ogra> mdz, x86 is just finishing in the other room, all three installs tested
<Kamion> elmo: if we're at this number of images for dapper, I might well take you up on that
<mdz> ogra: what's the third?
<Keybuk> and postfix dep problems *sigh*
<mdz> ogra: rather, what are the three installs?
<ogra> server, workstation and default
<mdz> I thought the default was server
<daniels> Kamion: byo pillow
<Keybuk> sorry, postfix postinst broke
<lamont__> Keybuk: ??
* jsgotangco just finished installing workstaiton and oem for x86 and its PASS
<mdz> jsgotangco: edubuntu?
<ogra> mdz, i kept server as is 
<Keybuk> lamont__: hoary->breezy upgrade, postfix: subprocess post-installation script returned error exit status 1
<mdz> ogra: seriously?
<ogra> mdz, yes
<jsgotangco> mdz, no ubuntu still downloading edubuntu atm
<ogra> mdz, the default is called edubuntu
<mdz> jsgotangco: so you tested desktop and oem, thanks
<ogra> mdz, and we have an additional workstation install thats ubuntu with edubuntu-desktop
<mdz> Kamion: I'm going to test the server images anyway while I wait for the powerpc dvd again
<Kamion> (default installs both edubuntu-desktop and edubuntu-server)
<ogra> mdz, for overview: https://wiki.ubuntu.com/InstallNotes 
<Keybuk> lamont__: in particular, "fatal: could not find any active network interfaces"
<hno73> goodnight all. have fun :)
<jbailey> lamont-ia64-live: Eh, cool.
<ogra> mdz, err, https://wiki.edubuntu.org/InstallNotes
<lamont-ia64-live> jbailey, yeah - works
<Keybuk> i suspect this is the same as mvo found
<dieman> there we go
<lamont-ia64-live> Keybuk, on hoary upgrade?
<dieman> found a mirror that was willing to send to me at 30mbps
<Keybuk> lamont-ia64-live: yah
<lamont__> gah - back to the other machine
<dieman> it will have to do
<Kamion> ogra: you mean EdubuntuInstallNotes?
<lamont__> Keybuk: from a hoary install? or warty>
<Keybuk> lamont__: hoary install without security or updates
<lamont__> Keybuk: ok
<ogra> Kamion, in fact i meant http://wiki.edubuntu.org/EdubuntuInstallNotes, yes :)
<ogra> the wiki merge is quite confusing
<ogra> i had to rename all my stuff and links...
<lamont__> Keybuk: do you have /etc/postfix/{main,master}.cf where I can look at them?
<Keybuk> lamont__: no, it'll be wiped already
<Keybuk> was just whatever hoary made out of the box
<lamont__> ok
<Keybuk> I installed hoary not 20 minutes ago <g>
<Keybuk> specifically to test this
<lamont__> I suspect that the trivial fix is either: (1) postconf -e 'inet_interfaces = loopback-only' or (2) remove postfix and/or fix master.cf to match.  grumble.
* lamont__ will duplicate it and figure out the optimal fix.
<lamont__> just need a crash and burn box
<jbailey> Wow, delete ccache and hct's cache and I'm down to 117k files from 1.5M
<jbailey> Keybuk: Is hct going to clean up after itself? and delete cached things older than a certain period?
<mdz> Kamion: we need to remove the RC (or otherwise shrink the pool) before we can push the release to us.releases
<calc> btw the live powerpc cd isn't up yet
<mdz> calc: yes, it is
<lamont__> calc: I have a copy that I downloaded....
<mdz> calc: where were you looking?
<calc> .pool
<Kamion> mdz: removing DVDs is a better option; I'll sort that out
<calc> perhaps i am looking in the wrong place
<Keybuk> jbailey: new HCT uses bzr, so there's no cache, there's just whatever you have in your project tree
<Kamion> or moving RC DVDs to cdimage.ubuntu.com, I should say
<Keybuk> if you wipe ~/scratch/udev all of the udev repository and shit goes too
<Keybuk> (unless you've published it somewhere, of course)
<jbailey> Keybuk: \o/
<mdz> Kamion: CD images are blessed, ready to go once they're mirrored
<Keybuk> I'm hoping I'll be able to give you something to play with during the pre-conf "quiet period"
<elmo> Kamion: why not just kill RC now?
<elmo> it's not as if having anyone test it is useful
<Keybuk> --> /msg (as off-topic)
<Kamion> elmo: am already shifting DVDs around ...
<Kamion> it'll get killed automatically when I publish the release for real
<calc> ah i see the ppc one now, guess its in the middle of copying right now
<calc> or i was blind
<dieman> im trying to at least get the -install isos
<dieman> im nearly done with -live too
<dieman> wont have the dvd's in time
<Riddell> anyone able to check over the kubuntu announcement?  http://kubuntu.org/announcements/breezy-release.php
<mdz> Kamion: ubuntu-server on i386 and amd64 went splendidly
* Kamion pushes out a quick sync to at least remove the RC DVDs first
<calc> Riddell: kaffeine misspelled
<Kamion> do release announcements need to point to the DVDs?
<calc> also is breezy badger supposed to be capitalized?
<mdz> yes
<calc> Riddell: see above wrt capitalization
* lamont__ watches his download time for i386/dvd shoot to 13 hours
<lamont__> hrmpf
* ogra is down to 3h :)
<carthik> Riddell http://www.kubuntu.org/download.php links test say "5.04" though they link to the 5.10 RC disc images
<calc> Riddell: kaffeine is spelled right in the title but not in the description
<dieman> lamont__: heh
<calc> " Kubuntu 5.10 can be download from http://releases.ubuntu.com/kubuntu/5.10" probably should read "downloaded"
<dieman> lamont__: im busy trying to get them somewhere in the usa.
<lamont__> dieman: if you do, holler.. :)
<dieman> ok
<lamont__> s/if/when/
<lamont__> I'm at 26%, 9 hours remaining.
<lamont__> and gonna kill it and go home, once the i386 install CD is done burning
<dieman> heh
<dieman> i got all the install cds
<dieman> how far off is the -rc dvd from the release dvd?
<dieman> is it worth trying to rsync to that?
<mdz> dieman: yes
<dieman> ok
<Kamion> dieman: are you only mirroring releases.u.c, or cdimage too?
<dieman> just release for now
<dieman> releases
<Kamion> because the release DVD won't be going to releases.u.c
<dieman> hmm
<dieman> i see it on some sites
<calc> "Please download by Bittorrent if possible." by sounds awkward but maybe just to me (via or using seems better)
<dieman> im so confused!
<Kamion> just to cdimage.u.c/releases/breezy/release/
<calc> or maybe even "with"
<Kamion> dieman: er, I haven't put it there on the master
<Kamion> the RC DVD is there
<mdz> dieman: maybe you saw the RC dvd
<dieman> yeah
<jbailey> calc: "The preferred way to get these is through Bittorrent."  "Use Bittorrent if possible", or something.
<dieman> but some people have the rc dvd in their release .pool
<Kamion> it should be going away now, I've moved it
<jbailey> calc: Just sidestep the akwardness
<calc> jbailey: yea
<carthik> Riddell: also "Google suggest" might be "Google Suggest" - sorry if I am bugging you :)
<calc> Riddell: looks pretty good other than the above mentioned things (check all comments i made, not all were prefixed with your nick)
* ogra curses KDE language packs for the 6th time today
<carthik> Riddell, "/etc/apt/source.list" should be "/etc/apt/sources.list"
<calc> carthik: also needs an apt-get update
<calc> or does dist-upgrade do that automagically now
<crimsun> (no, still needs an update first)
<calc> ok
<carthik> Riddell, also, the page https://www.ubuntulinux.org/wiki/KubuntuBreezyReleaseKnownProblems does not exist yet (don't know if this really matters)
<carthik> Riddell, since the www.ubuntulinux.org/wiki redirects to wiki.ubuntu.com and ubuntulinux.org throws an "expired certificate" message, maybe change the links to wiki.ubuntu.com/%s ?
<Riddell> all fixed, thanks much carthik and calc 
<wasabi> So somebody enlighten me. Is universe frozen also?
<calc> np
<bob2> wasabi: /topic
* wasabi reads topic
<mdz> wasabi: it is about time
<wasabi> k
<mdz> why?
<wasabi> Just wasn't sure. If it wasn't I was going to fix a minor Eclipse bug.
<Unfrgiven> mdz: any chance that the introdeveloperdocs package from the new queue will make it into breezy (universe rep)?
<mdz> Unfrgiven: if it isn't in already, it's too late
<calc> Riddell: i think krita desc may be a sentence fragment
<calc> Riddell: though i never did well in grammar ;)
<mdz> Unfrgiven: release times are too busy to expect new packages to be processed quickly
<wasabi> I'm kinda happy to see my Eclipse efforts finally pay off.
<wasabi> Debian maintainer took them and polished them up. ;)
<Riddell> calc: yep, fixed
<Kamion> +The default installation is suitable for servers, and installs only the base
<Kamion> +system. You may install additional packages of your choice from the CD once
<Kamion> +the installation is complete.
<Kamion> mdz: that OK with you?
<mdz> Kamion: yes, thanks
<Kamion> actually, too many "install"s in there, one moment
<Kamion> +The default installation is suitable for servers, and installs only the base
<calc> Riddell: er isn't the subject of the sentence still missing?
<Kamion> +system. Afterwards, you may install additional packages of your choice from
<Kamion> +the CD.
<calc> Riddell: putting a period at the end doesn't make it a sentence automatically ;)
<Kamion> mdz: turned out to be straightforward after all
<calc> Riddell: which is where i get to the point about not knowing for sure whether it is considered a fragment or not
* jbailey prays that the rsync actually worked and wipes his machine.
<calc> heh
<calc> jbailey: you actually want your system wiped? :)
<Riddell> calc: well this isn't prose, it's a list under the subject "new in kubuntu 5.10"
<calc> jbailey: oops misparsed what you wrote
<jbailey> calc: I seem to be the one to do ppc64 tests. =)
<calc> Riddell: true, nm :)
<wasabi> yay flash system "just about done!"
<jbailey> Hmm, no automatic lvm option on ppc64-server.
<Kamion> mdz: drum roll please
<mdz> Kamion: *drums on the desk*
<dieman> heh
* ogra listens
<Kamion> mirrors are syncing the Ubuntu release
<dieman> woo!
<Kamion> install CD and live CD only for now
<Unfrgiven> congrats to all! :)
* mdz crashes a symbolic cymbal
<Keybuk> Kamion: WAIT!
* Keybuk ducks, runs, and hides
<Keybuk> :p
<Kamion> dude
<mdz> Kamion: oh, us.releases wasn't finished with the isos yet
* Kamion drops an anvil on Keybuk
* lamont__ throws tomatoes at keybuk
<lamont__> ew. tomato paste
<Kamion> mdz: nor se.releases, I think
<dieman> ok
<dieman> im active for releases
<dieman> for breezy/ubuntu install/live
<Riddell> Kamion: can you put the kubuntu CDs on release too?
<dieman> waiting for the rest of the isos to make it
<Kamion> I don't entirely understand why se. is lagging
<wasabi> So is this "it"?
<jbailey> we're going to die...
<crimsun> wasabi: yes.
<Kamion> mdz: ack kubuntu?
<wasabi> Who has the champaign?
<jbailey> (mandatory HHGG quote)
<elmo> Kamion: the DVDs probably :P
<mdz> Kamion: let's get ubuntu up first
<elmo> I'll kill it and start the sync again
<Kamion> elmo: what's so hard about removing files?
<elmo> ugh did you just randomly retrigger?
<Kamion> what, just now? no
<mdz> Kamion: then we can remove RC and publish kubuntu at the same time, right?
<Kamion> five minutes ago, yes
<Kamion> mdz: yes
<mdz> we know at least one of the mirrors is tight on space
<Kamion> publish-release does that itself ...
<Kamion> mdz: I removed ~16GB from releases earlier
<mdz> announcement is in the moderation queue now
<Kamion> if they're *still* tight on space, they suck :-)
<Keybuk> Kamion: that's generally a mirror's job isn't it?
<mdz> Kamion: what did you remove apart from the RC DVDs?
<Keybuk> sucking and blowing as hard as they can
<Kamion> mdz: the RC DVDs come to about 16GB
<mdz> Kamion: oh, you did kubuntu as well?
<Kamion> right
<jbailey> ppc64 server install good.
<calc> might be useful to remove the colony/rc releases from torrent site also to keep people from being confused
<Kamion> calc: I thought I removed colony-5 earlier today
<Kamion> but yeah, I'll remove the rc
<calc> though they probably should be downloading via a torrent file instead of the tracker itself
<jbailey> The wiki appears to be unable to see the authentication database...
<Kamion> calc: I've removed most of the RC with prejudice from the master; will sync once elmo gives me the ok
<ogra> mdz, i386 edubuntu completely done and blessed
<mdz> ogra: great
<ogra> yup
<mdz> ogra: how about some sleep?
<Kamion> calc: but note that it gets rm'ed automatically on the master when the release gets published - I just purged some stuff that hasn't quite been superseded yet
<elmo> Kamion: sync yourself happy
<ogra> mdz, there is still some small webpage and wiki stuff in 30 min i'm done :)
<elmo> us.r.c is still syncing the images tho
<elmo> I'll manually rekick it when it's done
<mdz> ogra: you're what?
<Kamion> elmo: I still don't understand what se.r is doing
<elmo> Kamion: is it definitely not up-to-date?
<mdz> ogra: I'm suggesting that you sleep and continue with the release after
<ogra> mdz, i'm done for today in 30min :) i have to ship some screenshots for highvoltage etc...
<Kamion> elmo: http://se.releases.ubuntu.com/ is showing an Archive-Update-In-Progress and an out-of-date HEADER.html at least
<lamont__> elmo: will the poor SCC arch's be allowed a little time to catch up, or is the archive locked down hard already?
<mdz> ogra: ok, agreed
<ogra> ;)
<mdz> us.releases has 4/6
<Kamion> elmo: the actual images seem to be there, but it's not updating the symlinks in breezy/
<elmo> hmm, it's rsync-ing SOMETHING, and a lot of it
<elmo> lamont: archive's not locked down yet
<fabbione> morning guys
<Kamion> the images themselves got (effectively) touched when the symlinks were changed; I don't know if that's relevant
<ogra> morning fabbione 
<Kamion> (actually identical versions re-copied in because publish-release is just that clever)
<elmo> maswan: ?
<mdz> Kamion: timestamps preserved?
<Kamion> mdz: no
<Kamion> er, yes
<Kamion> uses cp -a
<lifeless> elmo: did we just lose all useful bandwidth ?
<elmo> lifeless: err, no?
<lifeless> ok, wiki is just being painfully slow
<elmo> that's nothing to do with the bandwidth
<elmo> that's moin being crap, AFAICT
<Kamion> elmo: oh, meh, ok, it's rsyncing the Kubuntu images I pre-published ages ago, I think
<lifeless> heh, k
<Kamion> or possibly Edubuntu
<Kamion> yay derivatives
<elmo> Kamion: which images?
<elmo> oh, nm, duh, the soon-to-be-golden ones
<elmo> gar
<Kamion> right ...
<jsgotangco> ogra, edubuntu x86 workstation PASS
<Kamion> elmo: not much to be done about that, I'm going for a drink
<ogra> jsgotangco, yay :)
<Kamion> mdz: ubuntu-server rebuilding with updated syslinux.txt (I hope)
<mdz> Kamion: powerpc dvd is looking OK so far
* lamont__ -> home.
<calc> heh there is an old 5.04/array-7 dir still on cdimage full of isos
<mdz> us.releases now has all the isos, not the links yet though
<mdz> announcement is in the moderation queue
<Kamion> calc: *clicketyclick* not any more there's not
<Kamion> (thanks)
<whiprush> mdz: is there a way you can send me the announcement so I can get the fridge ready?
<whiprush> unless jdub is handling it.
<mdz> I think jdub is out for the count
<Kamion> jdub's on UK time
<mdz> I can bounce you a copy if you give me your email address
<whiprush> ah
<whiprush> jorge@whiprush.org
<mdz> en route
<whiprush> ta
<calc> Kamion: heh :)
<fabbione> mdz: sorry, can you forward it here too? lamont and I need to prepare the announce for SCC
<fabbione> (and wiki is locked)
<mdz> fabbione: wiki is what?:
<fabbione> "/!\The authentication database is temporarily unavailable. Anonymous access only."
<fabbione> i thought somebody did lock it on purpose
<Kamion> aha, se.releases is up to date in the parts that matter now
<fabbione> (wiki.u.c)
<mdz> fabbione: no idea what that is about
<Kamion> (it's still dealing with kubuntu, edubuntu, ubuntu-server)
<fabbione> mdz: ok..
<jbailey> fabbione: It's been that way for at least 10m.
<mdz> I can't login to the website either to publish the news item
<fabbione> jbailey: ok
<mdz> elmo?
<Riddell> whiprush: can you do the kubuntu story too?  http://kubuntu.org/announcements/breezy-release.php
<elmo> mdz: uh?
<mdz> elmo: launchpad auth seems to be borked somehow?
<jbailey> Suspect that LP went to sleep. =)
<jsgotangco> whiprush, don't forget our edubuntu story too!
<elmo> stub's doing a  production upgrade
<whiprush> Yikes!
<whiprush> ok
<mdz> oh, hell
<Keybuk> stub's taken it down
<ogra> perfect timing :)
<lifeless> timing!
<mdz> stub: the timing is not ideal
<fabbione> mdz: what time is over your TZ?
<Keybuk> <stub> Anyway... just about done.
<mdz> fabbione: 2134
<fabbione> it's not 13 everywhere in the world yet :)
<jsgotangco> heh
<stub> done
<fabbione> are we going to release the 12 and 1/2?
<mdz> yes
<jbailey> fabbione: Pretend you're Harry Potter.
<fabbione> :)
* dieman watches bittorrent send 1 megabyte per second
<ajmitch> fabbione: the 13th is 3/4 done here
<stub> mdz: Needed for a shipit update which have been getting 'DOIT' priorities
<jsgotangco> ajmitch, heh
<whiprush> jsgotangco: link me to a release announcement or something please.
<mdz> stub: it's not going to hold up the release, just getting it on the website :-)
<mdz> stub: that'll change with soyuz though...
<Kamion> mdz: aren't you just looking forward to it
<stub> mdz: We have plans and a spec for keeping authentication running during these outages. Just a matter of time.
<Keybuk> Kamion: what do you mean?  mdz loves launchpad
<Kamion> Keybuk: absence makes the heart grow fonder
<Keybuk> meeeeow
<mdz> stub: it's no problem for it to go down for this sort of interval, we just need to coordinate in advance
<bddebian> I know you folks probably don't care to hear it from me but Great Work and Congratulations!!! :-)
<mdz> Keybuk: I also love the Easter Bunny and the Tooth Fairie
<stub> mdz: Normally coordination is done automatically in that updates are done in AU time. This obviously needs to adjust to the pre-release 24hour shifts ;)
<mdz> bddebian: what do you mean?  we especially care to hear it from you
<bddebian> :-)
<Kamion> us.r is going to be a while, from the look of it; it's still in edubuntu/.pool/
<dieman> wow
<Kamion> stub: 24-hour shifts are for wusses
<bddebian> Anyway, gnight folks.  Thanks for all your hard work.
<tseng> bddebian: i vote you in top 5 bugfixers
<Kamion> real men do 36-hour shifts
<ogra> bddebian, it wouldnt be what it is now without you :)
<dieman> the i386 install torrent is doing nearly a megabyte/sec on its own
<tseng> bddebian: have a medal
<mdz> stub: distro work is done on AU time as well, and I'm often working during these hours too
<bddebian> ogra: Pfft :-)
<ogra> ;)
<Keybuk> Kamion: what does that make me?  that's my usual working day <g>
<elmo> it's at 4/6 of edubuntu
<elmo> got kubuntu + ubuntu
<Kamion> elmo: Edubuntu only has 3
<Kamion> oh, preview's still there because we haven't published for real yet. it's had those 3 for ages though.
<Kamion> elmo: it doesn't appear to have kubuntu yet, only the rc
<elmo> e < k
<elmo> so, it hasn't got kubuntu sigh
<Kamion> I think I might take the opportunity to go out to the 24-hour supermarket for some more coffee
<Riddell> should the kubuntu announcement mention bugzilla or malone?
<mdz> Riddell: yes
<Riddell> mdz: which? :)
<mdz> Riddell: bugzilla for main, malone for universe
<Riddell> ok
<Keybuk> ah, we must be near release, mdz is getting "cheerful" :)
<elmo> Kamion: back yet?
<elmo> Kamion: in any event, are the server ISOs final?
<jbailey> ppc64 oem and resize ok
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html
<Lathiat> uh, the wiki seems to have recently broken for subpages, the CSS isn't included
<Lathiat> e.g. http://wiki.ubuntu.com/LaptopTestingTeam/DellPrecisionM20
<Keybuk> mdz: \o/
<Keybuk> congrats
<Lathiat> woohoo :)
<mdz> I'm fresh out of champagne
<ajmitch> well done everyone :)
<mdz> talisker it is
<fabbione> yay
<mdz> great work everyone
<jsgotangco> woooo
* Keybuk makes a celebratory cup of tea
* fabbione gets more coffee t
<Keybuk> a whole 6 months before we have to do that again
<whiprush> fridge updated!
<fabbione> Keybuk: ehehhe
<Kamion> elmo: the ones I just built should be - not the pre-published nes
<jsgotangco> wooooo
<elmo> Kamion: ugh
<Kamion> the change should be rsync-trivial
<Kamion> To burn the Ubuntu 5.10 CD images to disk, you will need 700MB
<Kamion> media.
<Kamion> mdz: we forgot to remove that bit
<mdz> Kamion: heh, oops
<mdz> I'll fix it on the website
<mdz> fixed
<Kamion> ta
<ajmitch> it's hard to find 650MB blanks now :)
<bob2> hah
<Kamion> Kubuntu publishing on little, but I'll hold off on the mirror sync until us.releases has caught up
<dieman> yeah
<dieman> i dont even think like walgreens has 650mb ones
<jsgotangco> wheres your release notes link?
<Riddell> Kamion: what is little?
* Riddell will have to keep #kubuntu at bay a little longer
<bob2> Riddell: the cd build machine...
<jsgotangco> the natives are restless?
<mdz> my word there are a lot of people in #ubuntu
<Riddell> jsgotangco: actually most of them have given up and gone to sleep :)
<Keybuk> I think the DISTROWATCH SPIES are asleep
<jsgotangco> hehe
<wasabi> mdz, was it you who mentioned ya'll had looked at unionfs?
<Keybuk> and we missed LWN
<bob2> OMG UBUNTU IS NUMBER ONE ON DISTROWATCH
<mdz> wasabi: yes
<speel> =o did some one sat distrowatch
<lamont> bob2: again?
<speel> say*
<wasabi> mdz got it working pretty good, stable.
<wasabi> Surely it's not a "stable" project righ tnow, but my install is. ;)
<Keybuk> bob2: THE AWARD WINNING UBUNTU (AS SEEN ON TV)
<Keybuk> itym
<bob2> oh, good point
<bob2> yay veronica
* wasabi checks /.
* wasabi cringe
<wasabi> Not there yet.
<Keybuk> slashdot hate us
<Lathiat> whats the website with dapper goals?
<Lathiat> is it in the main wiki?
<Keybuk> they haven't been drawn up yet
<Keybuk> that's what UBZ is for
<Lathiat> err, i mean, promosed UBZ dapper goals
<Lathiat> its ok i found it
<Kamion> dieman: I can find 650MB blanks for sale near the end of dabs.com's listings, although certainly the vast majority are 700MB
<dieman> heh
<Keybuk> elmo: can we upload yet?  can we?  can we?  huh?  huh?
<dieman> heh
<dieman> the DISTROWATCH SPIES
<mdz> elmo: I would like to upgrade to dapper plz help kthx
<wasabi> elmo: can you sync * from debian?
<mdz> distrowatch is asleep; no announcement yet
<Keybuk> actually, has upload-to-breezy been switched off?
<ajmitch> probably a good idea before some random MOTU decides to upload
<Lathiat> wasabi: heh, i read that as 'asterisk'
<wasabi> yeah i did too after I said it. =(
<Lathiat> haha
<elmo> upload-to-breezy will be switched off when all 3 derivatives are released
<Lathiat> so theres still time to do that avahi sync i wanted? *g*
<elmo> Lathiat: no
<wasabi> I love the arrangement of the kernel packages
<ajmitch> Lathiat: you're sol
<fabbione> elmo: ok.. can you please give me 5 minutes notice so i will stop the buildd?
<wasabi> linux-headers-k7 ,always tracking latest version ,etc.
<Kamion> cjwatson@little:~/cdimage/www$ for-project kubuntu publish-release daily-live 20051012.3 live yes
<Kamion> Daily for breezy powerpc on 20051012.3 is oversized! Continue? [yN]  y
<Kamion> YEAH WHATEVER
<fabbione> Kamion: GO GO GO! :)
<elmo> lamont: ?
<carthik> Excuse the interruption in the regular broadcast - but - THANK YOU! All!! - from the bottom of my heart.
<lamont> elmo: si?
<elmo> lamont: ok to disable binary uploads?
<elmo> i.e. hppa/ia64
<lamont> hrm... well...
<CaiN_SA> omw lol
<lamont> if you must
<CaiN_SA> since yesterday
<lamont> but it'd be nice to have a few more hours (hppa has ~100 packages to try)(
<CaiN_SA> only 1 package update came out for my system :/
<lamont> most of which will fail
<elmo> lamont: in universe or main?
<Keybuk> ah, DW woke up
<lamont> I wanna give qt-x11-free the college try, but otherwise purely universe
<jhank> btw i am the distrowatch spy :)
<jbailey> lamont: Does this mean youactually get to keep a breezy archive?
<jhank> tell me what to write *fg*
<mdz> jhank: hey, welcome :-)
<Kamion> us.releases appears up-to-date now
<lamont> jbailey: feh
<calc> jhank: write more about how ubuntu's naming is leet ;)
<jhank> thanks matt
<mdz> Kamion: with everything?
<jhank> okay calc, what else ;)
<Kamion> mdz: it's got the symlinks, which usually indicates it's got everything; they're last to rsync
<elmo> Kamion: no, I cheated
<mdz> jhank: complain about the desktop theme or something
<elmo> Kamion: it's still missing edu and kub
<elmo> they're just starting
<dholbach> how do we look?
<jhank> noooo i don't i like it - bad luck ;)
<Kamion> elmo: ah, ok - thanks
<mdz> dholbach: we look dapper indeed, I say ;-)
<dholbach> ROCK
<fabbione> DAPPER DAPPER DAPPER!
* dholbach hugs the world.
* fabbione does yet another dance
<Keybuk> GAY DUCK!
<dholbach> YAY! :)
<fabbione> Keybuk: YES!
<fabbione> ahhaha
<Keybuk> now, where did I put that mp3 of "Disco Duck" ?
<Lathiat> haha
<mdz> thanks to all of you for the lovely birthday present :-)
<lamont> mdz: is it your b-day?
<Keybuk> mdz: it's not your birthday yet, is it?
<Keybuk> 1h30 by my clock
<mdz> Keybuk: everywhere except local time
<Keybuk> in which timezone were you born?
<lamont> happy birthday mdz
<Kamion> cool - happy mdz-day!
<mdz> Keybuk: -4
<jhank> which is where? mdz
<dholbach> happy birthday matt! :)
<mdz> jhank: Baltimore, MD, US
<jhank> ahh happy birthday :)
<mdz> thanks, all
<Keybuk> ok, happy birthday then :p
<jhank> well done ;)
<mdz> I swear the release date was a complete coincidence
<jhank> hehe
<Lathiat> haha
<jhank> and if not... who cares ;)
<mdz> we moved from wednesdays to thursdays for other reasons and everything fell into place
<fabbione> mdz: dude.. stop trying to catch up with my age :P
<mdz> fabbione: I can only manage one per year
<fabbione> mdz: ehhe
<Kamion> Kubuntu release symlinks heading out to mirrors now
<Kamion> Riddell: ^--
<Riddell> just spotted :)
<Kamion> mdz: DVDs good to go? the test plan at least has some entries for all architectures now, even if the powerpc ones are ppc64
<mdz> Kamion: powerpc live passed, powerpc install in progress
<mdz> (stage2)
<dholbach> i'll take a shower, get some coffee and brb
<mdz> Riddell: announcement moderated, congratulations
<speel> woot :) nice work guys
<wasabi> mdz, Re: #17669; That option prevents start-stop-daemon from being able to stop GDM on my flash-based system.
<wasabi> But lack of the option doesn't have any effect on the outcome.
<wasabi> With it it says GDM is not started. I guess I shoudl look at exactly what that option does...
<mdz> wasabi: yes, that would be a good next step ;-)
<wasabi> Hmm. I'll check it tomorrow. Causes it to check /proc/pid/exe. No clue why that would be wrong. ;)
<wasabi> Since it launches it fine.
<Kamion> you do have /proc mounted?
<wasabi> yes. ;)
<Kamion> just checking :)
<pitti> Good morning
<whiprush> pitti!
<pitti> darn, I missed the release
<pitti> great to see it out! thanks to everybody
<Riddell> pitti: just in time for the kubuntu release
<mdz> pitti: you aren't too late to celebrate ;-)
<jbailey> pitti: Start drinking!
<pitti> mdz: I wanted to go on a ppc testing tour now :-)
<pitti> jbailey: ok, at this time of the day I'll drink tea :-)
<mdz> Keybuk: but you didn't ask what time of day I was born
<jbailey> pitti: The bars don't close here for another 2 hours. =)
<Riddell> pitti: I still need the kubuntu ppc DVD tested
<Keybuk> mdz: or which year ... and then we'd be getting into counting leap-seconds and other stuff
<pitti> Riddell: ok, if I start now, the download will be finished in about a week, since it is 1.5 times of my weekly quota
<jbailey> Keybuk: Didn't the US government just abolish the leap second at the same time as their DST reform?
<bob2> ubuntu drinking game: drink until dapper ships.
<Riddell> pitti: don't worry then, I've only got 1.5 hours to go on my download :)
<pitti> Riddell: if it is urgent, I can go to the uni in about an hour and suck it ther
<Keybuk> jbailey: ?!  are they slowly going out of sync with the rest of the world then?
<jbailey> Keybuk: This is news?
<Keybuk> bob2: drink, until launchpad is ready for dapper
<pitti> Riddell: ok, I won't be faster than 1.5 hours
<bob2> Keybuk: I don't want any fatalities
<pitti> Riddell: btw, you still know the refusal of my computer to boot Kubuntu? :-/
<Riddell> pitti: which arch was that?
<pitti> Riddell: amd64
<mdz> in the excitement I forgot to eat dinner
<ivoks> congrats everyone
<jbailey> Quick! Every order pizza for mdz...
<jbailey> Everyone, even.
<Riddell> pitti: it worked perfectly on mine (until my amd64 broke), must be something strange about yours
<Keybuk> jbailey: send an e-mail, you know, the kind that says you have to forward it to 10 friends
<Keybuk> with any luck, we can keep mdz in pizza for life
<mdz> delivery options are limited at this time ofnight
<jbailey> Riddell: Didn't I repot the same problem?
<pitti> mdz: enjoy it then; you truly earned it :-)
<mdz> I think I will need to actually leave the house
<Riddell> jbailey: yes
<jbailey> mdz: 11pm on a Thursday, really?
<mdz> jbailey: lots open, but not for delivery
<jbailey> Oh, hey, subtract day when crossing over midnight.
<Keybuk> dude, you live in AMERICA, can't you get any form of fast food delivered 24/7
<mdz> I don't eat fast food
<calc> fast food delivers?
<Burgundavia> queue the whining --> http://www.techspot.com/news/19060-ati-catalyst-510-drivers-released.html
<mdz> Keybuk: can your country even manage to deliver a pizza yet?
<calc> only delivery here is for pizza
<Keybuk> mdz: I assume so
<Burgundavia> lxer just picked up the release announcment
<jbailey> mdz: There's a lovely all veggie-Thai place in Montr'eal
<Keybuk> I enjoy cooking too much to find out
<pitti> darn, security flaw in OpenSSL - I think we'll see breezy's first USN today...
<mdz> pitti: so it goes
<fabbione> pitti: wow
<jbailey> pitti: You're just showing off ;)
<mdz> pitti: just make sure the hoar-security version number is < breezy ;-)
<wasabi> Thx jbailey!
<wasabi> evoluiton exchange works again!
<pitti> *cough*
<pitti> mdz: I don't intend to update upstream version numbers for all our software :-)
<jbailey> wasabi: Yay!  Feel free to close any bugs that look like problems you were having. =)
<wasabi> Almost.
<jbailey> Err.
<wasabi> It refuses to conenct ot the backend now heh
<jbailey> wasabi: Try /usr/lib/evolution/2.4/killev
<jbailey> wasabi: And then connect again.
<wasabi> wasabi   22584  0.5  1.8  25740  9472 ?        Sl   01:03   0:00 /usr/lib/evolution/2.4/evolution-exchange-storage --oaf-activate-ii
<wasabi> wasabi   22592  0.5  1.3  17028  7168 ?        S    01:03   0:00 /usr/lib/libgnomeui-0/gnome_segv evolution-2.4 6 2.4.1
<wasabi> heh.
<wasabi> there are bout 30 gnome_segv processes right now
<wasabi> nope, it screws up evo on every launch now
<wasabi> in fact evo is now unusable. =(
<jbailey> wasabi: Is this what you meant when yousaid it's "working"? =)
* jbailey hides.
<wasabi> Heh the config screen worked.
<wasabi> Which was much more than previous.
<wasabi> Got me excited!
<jbailey> I have seen other success repots.  What was this upgraded from, Hoary?
<wasabi> Well, it's been breezy for ages.
<wasabi> Sure, upgraded from Hoary...
<wasabi> And Warty.
<wasabi> rm -rf ~/.evolution     =(
<jbailey> WEll, if it's been breezy for a bit, then it's not just coping with the 2.2 -> 2.4 upgrade...
<jbailey> wasabi: mv ~/.evolution ...
<jbailey> It might help to debug it later.
<wasabi> it worked. ;)
<wasabi> yay!
<wasabi> first time I've ever used this successfully.
<dieman> shit
<dieman> automated rsync nuked out the isos i had
<dholbach> morning mvo
<mdz> Kamion: DVDs are gold
<mdz> Kamion: powerpc install checked out
<mvo> mdz: happy birthday! 
<jsgotangco> oh yeahhh
<mdz> mvo: thanks
<pitti> mdz: Hey, happy birthday from me, too!
<mdz> pitti: and thank you too
<pitti> mdz: now I know why you was eager to release it so quickly :-)
<mvo> heh :) 
<mdz> it was a cosmic intersection of events, I had nothing to do with it
<jbailey> How to claim your birthday beer as a tax deductable business expense. =)
<dieman>           [A
* mvo goes to town now to sort out some administrative stuff *sigh*
<dieman> you sure know when comcast fails
<dieman> one of my downloads went from 10mbps to 30mbps
(dieman/#ubuntu-devel) (im on cable, but we have local peering with the univ)
(dieman/#ubuntu-devel) (so i can just tunnel through work)
* mvo does the release dance 
<Kamion> mdz: great, thanks. publishing now
<mdz> Kamion: talk to elmo
<Kamion> mdz: source and ports CDs are both up on cdimage, though I suspect you don't care :-)
<Kamion> elmo: I don't know what mdz wants me to talk to you about, but ...
<mdz> er, I guess if it's only going to cdimage, it doesn't matter
<mdz> there are some mirror issues right now
<Kamion> indeed, only cdimage
<mdz> Kamion: I do care; I'll be thinking of it all the way from here to my bed
<mdz> where I am headed now, and I suggest you do the same
<jbailey> mdz: Happy bnirthday in local time. =)
<Kamion> we'll see; I don't want to get my body clock horrifically out of sync
<mdz> jbailey: thanks
<Kamion> I'll probably nap for a bit while Kirsten's at work
<mdz> night all
<Kamion> night
<sabdfl> night mdz. congratulations!
<fabbione> night mdz
<jsgotangco> night mdz and happy birthday!
<fabbione> mdz: ah can you wait a second only?
<infinity> mdz : 'Night, dude.  Happy release/birthday
<fabbione> mdz: good old man :)
<fabbione> jdub, mako: ping?
<highvoltage> mdz: happy birthday!
* fabbione needs somebody to allow a post to -announce
<fabbione> sabdfl: do you have enough power on lists to allow the ports announce+
<fabbione> ?
<Riddell> jdub would, but he's on london time
<fabbione> Riddell: yeah
<fabbione> i know
<jane_> can I send out the edubuntu release announcement? or does someone have to formally proof it first?
<infinity> jane_ : It won't hit the list anyway until it's been approved by a list moderator.
<infinity> jane_ : But it might be nice to pass it by a few people before you send.
<Kamion> jane_: have all the images been tested?
<Kamion> last I heard, that wasn't the case quite yet
<jane_> Kamion: I last spoke to ogra about 12 hours ago, so I'd better dbl check, thanks
<Kamion> the images were built later than that :-)
<highvoltage> jane_: ogra still needed to test ppc and amd64 just before he went to sleep 
<Kamion> yes, he said he had tested and was happy with i386
<Kamion> but I'd rather not release just the one arch, if possible
<jane_> ok well then there's no rush on the announcement... we have to get the green light from ogra, and no doubt mdz too
<jane_> Kamion: agreed
<Kamion> I'm happy to release with the green light from ogra and a statement that all the images that are being released have been tested
<Kamion> but mdz was clear earlier that we weren't to release untested images
<JaneW> Kamion: understood
* jsgotangco only got to test edubuntu x86 workstation/server
<Kamion> Riddell: what's the status of Kubuntu DVDs?
<Kamion> (I lost track)
<Kamion> Ubuntu DVDs published, heading towards cdimage
<Riddell> Kamion: i386 good, amd64 reported good and another report on its way, powerpc just about to burn
<Kamion> Riddell: thanks
<Kamion> we can publish that lot if powerpc works ok (preferably in both install and live modes), then
<Riddell> US kubuntu mirror has been in a state of limbo for the last hour
<Kamion> yeah, there's apparently a mirroring problem there
<Kamion> I think it's trying to take the new files before removing old files
<Kamion> and must be on the edge of its disk space limits
<Kamion> I can't do anything about it from here; likely any attempt I make would just make it worse
<elmo> we can't fix it
<JaneW> Anyone who is willing to proof read the Edubuntu Announcement please take a look -> http://wiki.edubuntu.org/EdubuntuReleaseAnnouncement
<Kamion> it seems to have removed the DVD images, so it must have been pretty close beforehand too
<elmo> there's another (non-Ubuntu) projcet eating all the space, so even if we free up some, it'll just get used up before we can mirror it
<elmo> I've pinged the local admin, but it's a bad time timewise
<carthik> JaneW, "Edubuntu is as a version "
<Riddell> JaneW: s/Edubuntu Release /Edubuntu release, /
<carthik> JaneW, "knowledge and skill will be able" "knowledge and skill should be able"
<Kamion> JaneW: "Educational specific applications" -> "Education-specific applications", I think
<JaneW> k
<Kamion> "a writing speed" -> "A writing speed"
<Riddell> s/Basically//  not a word to be used in formal writing
<carthik> JaneW, " default with as less questions as possible" ->  "default with as few questions as possible"
<pitti> elmo: is uploading to breezy-updates ok? I need to bump the mozilla version number to be higher than hoary-security
<carthik> JaneW, capitalize "Ubuntu" "Breezy", "Badger"
<elmo> pitti: you can do - it's untested tho, might break
<pitti> elmo: and -security? I need to do an update today
<infinity> pitti : Err, what?
<infinity> pitti : 2:1.7.12-0ubuntu2 >> 2:1.7.12-0ubuntu05.04
<pitti> infinity: unfortunately dpkg has its own idea about that
<pitti> infinity: breezy is really smaller
<Kamion> "bootprompt" -> "boot prompt"
<elmo> pitti: same deal - untested, may break
<Kamion> infinity: 2 < 05 - numeric parts are compared numerically
<infinity> pitti : Erk, crap.
<elmo> of course we need to find that out one way or anothr, or so
<sabdfl> JaneW: i'll give it a once-over when you're done editing there
<sabdfl> ping me then, please
<pitti> elmo: ok, I uploaded b-updates; let's see how it goes
<infinity> pitti : In that case, I need to update thunderbird as well.
<JaneW> thanks guys
<infinity> pitti : Are you just bumping mozilla to 05.10?
<JaneW> sabdfl: just saving
<JaneW> sabdfl: done. go ahead
<infinity> Kamion : Yeah, I thought all bets were off as soon as letters got involved, I didn't realise it split the string and did the numeric bits on their own.. :/
<Kamion> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version, although I realise it's a bit late now
<Kamion> Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison.
<infinity> pitti : I'll have to do enigmail as well.  If we'd had one more upload, I wouldn't. ;)
<infinity> pitti : -0ubuntu05.04.2 versus -0ubuntu5  <bang head on desk>
<infinity> Kamion : Thanks for the pointer.  The versions seemed lexically okay to me, so I didn't even bother with a --compare-versions.  Go me.
<Kamion> ubuntu-server/amd64 pass
<pitti> infinity: same problem for mozilla-thunderbird
<infinity> pitti : Yes, already mentioned above.
<infinity> pitti : I'm uploading both, unless you already did one...
<pitti> infinity: I called it -1ubuntu1
<pitti> infinity: no, I only did mozilla; thanks
<infinity> For mozilla?
<pitti> infinity: but don't you need mozilla in the archive to build enigmail?
<infinity> I'm going with -0ubuntu05.10, for pure consistency.
<elmo> shit, wait
<elmo> shit shit
<infinity> pitti : It is in the archive.
<infinity> pitti : The build-dep isn't THAT strict, dude. :)
<pitti> ok
<pitti> elmo: did it break something?
<Kamion> so, I suppose I'd better start doing edubuntu testing, sigh
<crimsun> sanxiyn: that's MOM, which we KNOW is generating bad patches. See the topic in /t
<crimsun> err, sorry
<elmo> pitti: no, I caught it
<infinity> elmo : Good to go for a nother pair of uploads, then?
<elmo> for -updates yes
<elmo> don't try and do any security yet
<pitti> elmo: ok; I still have to prepare the packages anyway and I can start with warty and hoary
<infinity> Okay, enigmail and tbird uploaded.
<infinity> Firefox used a different numbering scheme, so it's okay.  And I assume we have no other such version issues?
<pitti> right
<elmo> okay -security should be good to go now too
<pitti> these were the only upstream updates
<pitti> elmo: great, thanks
<elmo> pitti: please try it with one upload first tho, and make sure it goes all the way through the process correctly
<pitti> elmo: but I still can release warty, hoary, and breezy together?
<elmo> uh?
<elmo> not from the same source package no?
<infinity> No, but from the same amber run, I assume he meant.  And yes, of course.
<elmo> if you mean amber them together, yes, normally.  however until we've verified it works, I'd prefer if you amber breezy separately
<pitti> elmo: ah, that's what I meant
<pitti> elmo: yes, no problem
<sadleder> hi Kamion, i have a problem with openssh-client on Debian unstable. when using sitecopy with sftp, it stalles on connect, but manual sftp works fine.
<sadleder> ... ah, and my setup has worked for some years before.
<smurf> sadleder: -EWRONGCHANNEL
<Kamion> I'd prefer you filed a bug anyway
<Kamion> I tend to need ssh -vvv output and that sort of thing, which is a bit verbose for IRC :)
<Kamion> sadleder: plus I've been awake for about 24 hours and not in the best condition for debugging openssh right now :-)
<sadleder> Kamion: sure, i just didn't know how to track that problem down myself.
<dholbach> Kamion: you did an awesome job
<Kamion> sadleder: I'd start by getting sitecopy to run sftp with -vvv for extra debugging
<Kamion> dholbach: thank you
<sadleder> Kamion: ok, i'll try that
<maswan> elmo: yes?
<elmo> maswan: you're syncing super slowly from us - is everything ok on your end, AFAYK?
<Kaloz> Kamion: i'm just mirroring the stuff as I did with hoary. when it's done, can you post it as an unofficial mirror for hungary?
* maswan checks
<maswan> elmo: that's weird slow
<elmo> yeah
<elmo> you've got the machine to yourself at this end, other hosts are syncing off it ok, and I'm sure we've got enough outgoing BW still
<maswan> I'm going to break and restart it
<Kamion> Kaloz: if you give me the URL I'll add it to /download/, sure
<Kamion> though you really ought to mail mirrors@canonical.com instead / as well
<Kaloz> it will be http://dune.hu/ubuntu-releases, as hoary was
<Kamion> and add yourself to http://wiki.ubuntu.com/Archive
<Kaloz> well, i'm still planning to set up a full, official mirror btw
<Kamion> Kaloz: ok, that's easy, I can just copy your entry from hoary when your mirror's done
<maswan> oh, damn. now I know.
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> the cluster is running flat out
<Lathiat> haha
<maswan> so the rsync will have to wait for disk etc
<Kamion> I didn't know your cluster had a flat out
<elmo> maswan: hmm, ok - but even before we broke your cluster, it was going pretty slowly
<elmo> as in 10Mbit or less
<maswan> elmo: can I hit symcproxy with two more hosts?
<HiddenWolf> maswan, nice server names. :)
<elmo> maswan: hit it with whatever you like
<maswan> ok
<Lathiat> maswan: goign to deploy the emergency mirror hosts again? :)
<maswan> Lathiat: yes
<Lathiat> maswan: so what did you pick up in may that like douled your traffic?
<Lathiat> mmm, more april
<maswan> sarge?
<maswan> april? hoary?
<Lathiat> nah i mean like consistently, not just release time
<Lathiat> or do they really make that much of a difference?
<xhaker> dayly 12.2 install i386 = final install ?
<maswan> ah, well, ubuntu and star wars-revelations dvd isos
<xhaker> md5sum match
<Lathiat> maswan: ah ok
<maswan> meeting... :/
<xhaker> Lathiat... am i right?
<highvoltage> hno73: can you join edubuntu as well please?
<hno73> highvoltage: yep :)
<highvoltage> :)
<Kinnison> Can someone on the ubuntu-devel mailing list confirm whether or not a posting from daniel.silverstone@canonical.com about dapper got through?
<makx> hello jbailey asked me to test amd64 breezy images
<makx> https://wiki.ubuntu.com/BreezyTestPlan
<smurf> Kinnison: looks like it didn't
<Kinnison> smurf: Okay, I'll send a new one from my home address as soon as my subscription is processed
<makx> 20051011 worked on hp proliant 385
<Riddell> Kamion: I've had a second good report on kubuntu amd64 dvd and powerpc dvd is working for me so we're good to go
<makx> minor glitches:
<makx> * switching terminal while usplash don't get you back to usplash
<infinity> makx : You're a bit late, we released already. :)
<makx> hehe ok cool.
<makx> anyway just let you know.
<makx> * live didn't recognize swap on cciss partitions.
<infinity> elmo : Those uploads don't appear to have ever made it into wanna-build
<makx> infinity: that's all.
<makx> anyway recieved that nice babe yesterday, soo... :)
<makx> good luck guys!!!
<pitti> sivang: ping
<Kinnison> hey silbs
<Riddell> hmm, se.releases hasn't updated for kubuntu either
* Riddell goes to bed
<crimsun> Riddell: known issue
<\sh> Riddell: hu
<Riddell> morning \sh 
<\sh> Riddell: I just read ubw...i hope u never brought this konqui settings into main ,)
<JaneW> night Riddell 
<\sh> MORNING FREE WORLD HAPPY BADGER DAY
<highvoltage> yippee!!1
<Riddell> which setting?
<highvoltage> \sh: ^5
<Lathiat> \sh++
<\sh> Riddell: kubuntu-konqueror-shortcuts
<\sh> hehe..is ubuntu out?
* Riddell thinks \sh is still waking up
<fabbione> \sh: /topic my friend
<infinity> \sh : According to ubuntu-announce, yes.
<Lathiat> yes
<Lathiat> Riddell: did konsole get fixed?
<Riddell> Lathiat: no
<Lathiat> err :\ thats a nasty bug
<\sh> well...then my dream was no dream :)
<Riddell> Lathiat: -updates.  soon
<Riddell> \sh: I'm off to bed, I need you to keep poking people randomly until the kubuntu DVDs get on the release server and everything is mirrored
<Lathiat> ya
<\sh> Riddell: k...
<Riddell> night JaneW 
<\sh> Riddell: sleep well :) and have nice dreams :)
<dholbach> Riddell: sleep tight... you deserve the sleep now :)
<\sh> ogra: Congrats to Edubuntu :) and u too sleep as well in peace :)
<maswan> finally end of meeting, now I can fix stuff.
<HiddenWolf> How are the servers holding up?
<maswan> elmo: something is broken, I'm rsyncing syncproxy -> test5 now, and still getting pathetic rates. test5 does nothing else.
<Mithrandir> maswan: you've used up the university quota, so you're down to ISDN speed now. :-P
<fabbione> lol
<maswan> Mithrandir: I managed to get the amd64 install iso from ftp.heanet.ie at 20M/s
* dredg sighs at heanet
<dredg> 10mins walk
<dredg> far far longer in terms of routing
<sabdfl> (09:52:49) sabdfl: elmo: i've updated the download page mirror lists
<sabdfl> (09:52:58) sabdfl: separating those that have the final from those that are still showing RC
<sabdfl> also,  removing references to Hoary
<sabdfl> at least, when plone is ready to ack all of this
<sabdfl> also, i've started linking directly to the 5.10 directory at each of the mirrors
<sabdfl> it should be easy during the course of the day, as the mirrors come on stream, to move them from the "still have RC" to the "have the final" lists
<\sh> sabdfl: happy badger to you too :) and congrats to have 3 new babies ;)
<sabdfl> JaneW: how do i edit that edubuntu announcement?
<sabdfl> i don't see a login link, or an edit one
<sabdfl> \sh: thanks a lot for your help in the delivery room!
<infinity> Login is right above the search box.
<\sh> sabdfl: thx :) 
<JaneW> sabdfl: there should be one, they did move the page earlier, are you looking at http://wiki.edubuntu.org/EdubuntuReleaseAnnouncement ?
<sabdfl> JaneW: nevermindiamanidiot
<sabdfl> oh
<sabdfl> JaneW: why did the edubuntu wiki just lose its theme?
<JaneW> sabdfl: JaneW hno73: I was just wondering if it is possible that the edubuntu wiki skin be triggered when accessing the edubuntu wiki through the edubuntu site? It seems to have to set the skin manually and then all ubuntu wiki pages use that skin....
<JaneW> hno73 JaneW: I think the way it works is that if you are logged in you can pick your own skin, irrespective of what URL you are surfing on
<JaneW> hno73 if you are logged out you get the edubuntu skin on wiki.edubuntu.org
<JaneW> hno73 so new users comming in through edubuntu will get the new skin
<JaneW> hno73 try it in a browser that is not your default (like konq)
<JaneW> hno73 and you'll see how new users see it
<\sh> JaneW: and wow...the edubuntu new launched website..looks *great*...I'll ring my son today :) I think he will like it, too
<JaneW> \sh: :)
<highvoltage> \sh: i am pleased to announce that we have found the first easter egg on the edubuntu website :)
<maswan> elmo: you sure you're not exhausting all your bandwidth?
<hno73> It's all one big happy wiki now :)  The skin depends on your user pref if you are logged in or the URL if not
<\sh> highvoltage: which is? :) will a child find it? ;)
<highvoltage> i /msg'd it to you :)
<JaneW> \sh: highvoltage and hno73 are to thank for our cool site and new wiki look :))
<sabdfl> JaneW: ok, i've made my (small) changes
<\sh> highvoltage / hno73: this design rocks :) nice icons and very usable design :)
<Treenaks> have you seen all the fridges on the planet? :)
<hno73> \sh: yepp the gartoon icons are quite cool :)
<JaneW> sabdfl: great, thank-you. So can we send it out once ogra has confirmed that all images are fully tested and ready to roll?
<jordi> JaneW: I love this screenshot :D
<sabdfl> elmo: is that bandwidth topping off because of our equipment?
<jordi> http://wiki.edubuntu.org/EdubuntuScreenShots?action=AttachFile&do=get&target=t_khangman.png
<JaneW> jordi: yes it seems that's highvoltage's easter egg
<highvoltage> accidental easter egg, but brilliant nontheless.
<JaneW> jordi: it was unintentional though and if it is offensive we may need to remove it...
<JaneW> :)
<jordi> heh
<JaneW> I think it's funny though
<jordi> me too :)
<jsgotangco> haha
<moyogo> i keep getting /usr/lib/libpangocairo-1.0.so: undefined reference to `pango_fc_font_create_metrics_for_context' when I try to compile something requiring ligpango
<moyogo> libpango*
<infinity> That's what pkgconfig is for.
<infinity> (I'm pretty sure that was fixed months ago, anyway)
* infinity looks.
<infinity> moyogo : Which architecture.
* Mithrandir gives infinity a - to stuff between pkg and config
<moyogo> x86
<infinity> moyogo : Are you using pkg-config, or just doing -lpangocairo manually?
<moyogo> i'm using what's there, pkg-config
<moyogo> i tried compiling libwnck or marlin and i get this error
<infinity> moyogo : Looks like you want -lpangoft2-1.0
<infinity> moyogo : Not sure why pangocairo doesn't "require" it in pkg-config, but too late now for breezy. :/
<moyogo> how do i fix this here?
<seb128> infinity: why the cairo version would require ft2?
<seb128> moyogo: what is the bug? Do you have your source example somewhere?
<infinity> seb128 : Because pangocairo has a reference to pango_fc_font_create_metrics_for_context, which is provided by pangoft2-1.0
<moyogo> seb128: marlin or libwnck from cvs
<seb128> moyogo: do you use jhbuild or something?
<moyogo> no
<moyogo> just the ubuntu dev packages
<seb128> an ./autogen.sh && make ?
<moyogo> yes
<seb128> lemme try
<moyogo> thanks a lot
<dholbach> hey seb :)
<seb128> hi dholbach
<dholbach> happy badger-day :)
<infinity> seb128 :
<seb128> you too
<infinity> (breezy)root@cthulhu:/usr/lib # for i in libpangocairo-1.0.so libpangoft2-1.0.so; do echo $i; nm -D $i | grep pango_fc_font_create_metrics_for_context; done
<infinity> libpangocairo-1.0.so
<infinity>          U pango_fc_font_create_metrics_for_context
<infinity> libpangoft2-1.0.so
<infinity> 00004bfc T pango_fc_font_create_metrics_for_context
<infinity> seb128 : It's fairly obviously a bug to me, though odd that we never tripped on it.
<seb128> infinity: yeah, I've nm -D them too
<seb128> infinity: pangocairo require pango
<infinity> Yes, but pango doesn't define that symbol.
<infinity> And pango doesn't require pangoft2
<moyogo> sorry i didn't report this earlier
<infinity> (And it shouldn't anyway, since pangocairo is the only other lib with an undefined reference to that symbol)
<seb128> I'm not convinced that's a bug
<seb128> they do some weird stuff with pango to pick the variant (x/xft/cairo/...)
<infinity> pango doesn't need pangoft2, but pangocairo appears to.
<infinity> No other pango lib needs it.
<poningru> hi
<moyogo> make on marlin also errs : /usr/local//lib/libpangox-1.0.so.0: undefined reference to `_pango_engine_shape_covers'
<poningru> I was asked to come back after 5.10 was released with a bunch of question
<poningru> s
<poningru> first where in the US is the repos mirror?
<maswan> heh, I almost flatten the gigE on the first redirect host, just from i386 install isos. :)
<poningru> second how big is a repos mirror?
<fabbione> maswan: ehehe
<seb128> moyogo: pango current CVS builds fine here
<maswan> 75M/s
<moyogo> seb128: yes pango build alright here too
<maswan> and I _just_ started the redirects too
<poningru> I was thinking about asking my uni to host the repos
<maswan> half an hour ago or so
<maswan> now lunch. back for more hacking in a bit
<alisher> hi, does everybody know, how to contact shipit on xchat
<infinity> seb128 : Try libwnck CVS against breezy pango.
<Treenaks> alisher: shipit on xchat?!
<Treenaks> alisher: shipit is a web page..
<seb128> infinity: it's downloading
<moyogo> infinity, seb128: i tried with breezy pango and cvs pango, same errors for libwnck or marlin
<alisher> somebody who knows how shipit works
<highvoltage> alisher: you mean, you want to order cd's via irc?
<alisher> I ordered Breezy just some days after database opened
<poningru> anyone?
<seb128> infinity, moyogo: libwnck built fine
<alisher> Now me and some friend both have a message
<highvoltage> alisher: you can order cd's at shipit.ubuntu.com, and it will be delivered for free.
<alisher> 2005-09-22: 15 CDs (sent to shipping company)
<alisher> is it a mistake, or they are still shipping hoary, though i ordered breezy
<moyogo> seb128: ... my breezy is broken then...
<seb128> moyogo: since nobody else has the issue I'm tempted to say you borked it by installing stuff by hand :p
<alisher> it is ok to me, if i still get breezy later, but is a wasting, since what will i do with these cds
<poningru> so no one here knows about ubuntu repos mirror?
<moyogo> seb128: i had cleans debs for either tho'... rrr... how can i fix this?
<fabbione> poningru: it's all on the wiki
<poningru> ?
<fabbione> poningru: just look there
<fabbione> poningru: wiki.ubuntu.com
<seb128> moyogo: clean debs of what?
<fabbione> search for mirrors
<poningru> my searching didnt give any details apart from an email address
<alisher> thk you highvoltage, i laready run ubuntu for a while, just wanna know is any problem with the shipit database, or they still ship hoary
<moyogo> seb128: well, maybe not so clean, debs of pango, one with a patch and cvs stuff, and breezy's
<poningru> fabbione: ?
<poningru> bazlocal mirrors?
<fabbione> poningru: hold on a sec
<poningru> k
<fabbione> http://www.ubuntu.com/download/mirror/view?searchterm=mirror
<seb128> moyogo: marlin CVS builds fine here
<seb128> jdub: around?
<poningru> fabbione: ic
<moyogo> seb128: thanks
<poningru> fabbione: do you know how big the package mirror is? I can see the bandwidth usage but not how much it would take up
<fabbione> poningru: the archive is about 80G more or less
<fabbione> poningru: i don't know the release site
<seb128> moyogo: http://bugzilla.gnome.org/show_bug.cgi?id=318750
<maswan> In: 2826.78kB/s   Out: 116543.31kB/s   In: 2946.15kB/s   Out: 121231.41kB/s
<pitti> wow - that's what I call bandwidth :-)
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> the normal ftp cluster
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<smurf> maswan: your dfinition of "normal" doesn't quite match mine then
<maswan> farbror (cdimage.d.o) and the offload host
<maswan> I'm going to start spreading the load a bit to the other offload host too
<moyogo> seb128: thanks, i'll follow the bug
<seb128> moyogo: np
<sabdfl> thats.... wow.
<sabdfl> blinkenlights
<dredg> heanet also have a status page at http://ftp.heanet.ie/status/ for anyone interested
<Diziet> I really need to find a way to persuade jigdo not to want to md5sum the whole of my local mirror each time.
<Diziet> I need an IRC client with timestamps, too.
<Diziet> janew: ping
<Diziet> The EdubuntuReleaseAnnouncement uses the word `distro' which is not correct formal English :-).
<pitti> infinity: openssl breezy-security is not built; is this a katie or buildd problem?
<pitti> elmo: ^
<Diziet> What on earth is jigdo doing ?  I could have downloaded half the image by now.
<pitti> Diziet: I have used jigdo for a year now without any problem - what do you try to do?
<fabbione> Diziet: what did you manage to break today? ;)
<pitti> Diziet: and why do you want jigdo to md5sum your mirror? do you *create* a jigdo file, or use one to download a CD?
<Diziet> I'm trying to get jigdo-file to build an image.
<Diziet> I _don't_ want it to md5sum my mirror; it's just decided to do that by itself.
<pitti> Diziet: jigdo-lite http://cdimage.ubuntu.com/daily/current/breezy-install-amd64.jigdo works just fine for me
<pitti> Diziet: I usually tell it to scan the old image and /var/cache/apt/archives to speed up downloading, but that works fast (some seconds)
<Diziet> I don't have an old image lying around.
<fabbione> Diziet: use jigdo-lite
<\sh> anything new on kubuntu dvd front? riddell told me to poke around a little ;)
<pitti> well, scanning apt's cache should still help :-)
<Diziet> Sorry, when I said `jigdo-file' I meant `jigdo-lite'.
<fabbione> i am off
<fabbione> later
<sabdfl> pitti: thanks for the langpack update
<\sh> cu fabbione :)
<pitti> Hi sabdfl 
<Diziet> It wants to scan my whole mirror.  Which is very annoying, as my mirror is just a bunch of hardlinks to files whose canonical name is /export/mirror/Repository/data-md5/<md5sum-in-hex>
<pitti> sabdfl: no problem, sorry for the delay
<pitti> Diziet: ah, sure, if you ask it to scan that directory, it will :-)
<Kamion> \sh: I missed Riddell's comment earlier that powerpc DVDs were working; I'll start publishing them now
<Diziet> Oh, I just need to not tell it to scan it.
<\sh> Kamion: rock :) so he'll be lucky when he'll wake up :)
<segfault> Morning guys.
<sabdfl> pitti: no problem. please work with carlos to try to get it 100% asap
<pitti> sure
<Diziet> Kamion: I have a question about BreezyTestPlan: `Hoary updates, from CD' suggests updating to hoary-updates but not hoary-security.  Is that really right ?
<maswan> whee, getting close to those magical 2Gbit/s now
<Diziet> I tried doing a hoary install in Dutch but (probably because I let it download language updates) it was already updated to hoary-security by the time the install had finished.
<maswan> ~235MByte/s now
<\sh> hmmm...
<\sh> 28k for updating packages list
<Kamion> Diziet: from the look of the table it appears to be deliberate; installs constructed by hand starting with debootstrap, or installs in which you answer "no" to "Download software from the Internet?" (expert mode) or boot with 'install apt-setup/network-updates=false' should avoid that
<Kamion> but I don't think it's a critical test case, merely nice-to-have
<maswan> \sh: we're trying to offload the isos to other hosts, but it takes a bit of time.
<maswan> \sh: If I had gotten an exact time for the release a couple of days ahead, it woudl have been easier. :)
<Kamion> I think we've *probably* caught most of the problems with the other upgrade cases
<highvoltage> chmj: JaneW said she's going to bake an edubuntu cake, please help me put some pressure on her to keep to that ;)
<tseng> nag her to update the cakes status on the wiki
<tseng> does she have all the ingredients?
<highvoltage> hehe. i would hope so.
<ogra> highvoltage, that wont happen if i dont find a amd64 tester ... 
<ogra> morning all
<highvoltage> well, at least her cake would be under a CC license, if it's on the wiki. then we can adapt it for ubuntu and kubuntu too ;)
<\sh> maswan: no problem for me..I know the good old times, when someone could whistle the software through the phone ,)
<\sh> ogra: happy badger edubuntu day :) congrats friend :)
<Kamion> the Breezy installer is more careful about trying not to upgrade from the network during installation
<ogra> \sh, for what ? i have no release yet
<maswan> \sh: I'd like to see the guy that would whistle a full dvd iso, without bit errors. ;)
<ogra> i urgently need to find a amd64 tester 
<\sh> ogra: well...the edubuntu.org site is much better then a silver cd ,)
<highvoltage> anyone here with lots of bandwidth and an amd64?
<highvoltage> ooh, ogra beat me.
<\sh> maswan: hehe...
<TMM> hey! congratulations on the release!
<Kamion> ogra: I've got the amd64 CD ready to test (at least partially), but the DVD will take longer
<TMM> and, thanks! :)
<Kamion> ogra: you can release the CDs first and then the DVDs later
<ogra> Kamion, mdz said so... then i'll buy a new DVD writer today, i have the x86 image here now
<ogra> Kamion, oh, i thought you'd do ppc...
<chmj> highvoltage: sure 
<chmj> highvoltage: she suppose to bake it today ? 
<ogra> ok, request change: **** i ugerntly need a ppc tester for the edubuntu CD *** !!
<ogra> *urgently
<Kamion> ogra: can do as well; that's downloading as I speak
<highvoltage> chmj: she said she'll do it after 3pm today.
<ogra> Kamion, bah, when shall i ever pay you back ? 
<highvoltage> ogra: make it the topic ;)
<Kamion> will take longer though, and I'm half-asleep; other testers would help a lot
<highvoltage> oh, nevermind. no one ever reads the topic.
<ogra> highvoltage, that Kamion is our best tester ? 
<ogra> Kamion, i'll ping the world...
<highvoltage> ogra: the 'we need a tester part', cool that he's testing
<highvoltage> Kamion++
<ajmitch> ogra: what testing is needed?
<ajmitch> ogra: I've got an old iMac & a slow DSL line here :)
<ogra> ajmitch, install test, all three variants (defaut, server and workstation)
* ajmitch checks how close he is to ISP data quota
<mvo> ogra: gosh, cdimage.u.c gives me only ~60k/s (just started to download the image)
<ogra> ajmitch, i'd pay you any overquota ;) but i guess you get locked if you reach it, right ? 
<ajmitch> ogra: I'll end up getting shaped to 64Kbps
<ajmitch> which will be really painful ;)
<ogra> mvo, damned ...
* ajmitch is 1GB from the limit, for the next 10 days :)
<mvo> ogra: this is going to take a bit, I usually get 240k/s
<ajmitch> mvo: I'm getting 4K/sec
<ogra> mvo, anything we can poke \sh to do with your line ? 
<ajmitch> no, it's up to 8K already
<ogra> :
<ogra> )
<ajmitch> ogra: at this rate it'll take me 24h to download :)
<ogra> damned
<mvo> ogra: don't know, maybe I can be part of the 6mbit test-customers team ;)
<maswan> Ok, the netmasters have told us that we're doing 1.93Gbit/s out of our theoretical 2Gbit/s. breezy goodness to the world!
* ogra is going to try to convince his GF to install over her PPC working machine...
<ajmitch> ogra: sorry I can't help again :-/
<ogra> ajmitch, its ok, i understand
* ajmitch can't push the bits much faster
<\sh> mvo: what config do u have 5mbit or 2?
<Kamion> FWIW, rsyncing the Edubuntu install CD starting from a copy of the Ubuntu install CD yields a reasonable speedup
<mvo> \sh: 2
<Kamion> 4.60* for amd64
<Kamion> maswan: impressive
<ajmitch> Kamion: rsync tend to go at about 4K/sec even on a good day for me
<\sh> mvo: i can try to call henning to update your , or better your neighbors config
<\sh> mvo: temporarily
<\sh> mvo: can u get me the customer number of your neighbor?
<ogra> hmm, 22K from here...
* \sh is not in the office today
<ogra> argh, dropped o 2K
<Kamion> Riddell: Kubuntu DVDs published, mirror(ing|ed)
<\sh> Kamion: cool :)
<Kamion> http://cdimage.ubuntu.com/kubuntu/releases/breezy/release/
<Kamion> apologies for the slightly weird URL - I'll stick links in from releases.u.c at some point
<maswan> load average: 0.04, 0.06, 0.06
<maswan> doing 75MByte/s sustained :)
<maswan> and same for the other offload host
<maswan> how is the DC bandwidth doing?
<\sh> Kamion: the http://releases.ubuntu.com/kubuntu/5.10/kubuntu-5.10-rc-dvd-i386.iso is the old one?
<Znarl> maswan : We'er sitting on 750MBits/sec
<Kamion> \sh: yes, I purged that on the master site hours ago, but due to mirroring problems that may not have made it out to mirrors
<\sh> Kamion: k
<\sh> Kamion: missed the cdimages link 
<Kamion> we're not going to distribute DVDs from releases.u.c any longer - not enough disk space on mirrors
<maswan> Znarl: ACK. This is full for you? I'm not getting anywhere near good sync bandwidth from syncproxy.u.c, so I'm only partially mirrored over here. :/
<Znarl> maswan : Yes, we can go no faster.
<maswan> Znarl: oh, well. I guess there will be bandwidth over once europe goes to bed. :)
<smurf> maswan: That's going to get worse before it gets better
<maswan> smurf: can't really get worse than currently. :)
<smurf> Maybe releasing bittorrent a few days before FTP/HTTP would help
<highvoltage> smurf: i don't think that's possible, i think lots of stuff were only finished less than an hour before release ;)
<Znarl> Well, the per connection speed is dropping, and getting worse.
<maswan> Znarl: Ah, you need more bandwidth then. Too bad we don't have much over.
<highvoltage> ok, perhaps that's taking it a bit far.
<maswan> Talk to ftp.heanet.ie and ask them if they are up for a nice little http-redirect for the i386-install iso?
<\sh> http://www.badgerbadgerbadger.com/ the badger flash song for today :)
<smurf> highvoltage: I meant delaying the HTTP release, of course
<smurf> my BT seed has plenty of bandwidth left, and I doubt I'm the only one
<maswan> smurf: yes, but that means limiting access, which is not as nice. :/
<maswan> Znarl: for the future, perhaps trying to reserve 50Mbit/s or so for mirroring might be a good idea?
<Znarl> maswan : Yes, we have plans to split our network.
<maswan> Znarl: great
<smurf> maswan: BT clients are available for everybody who can do HTTP/FTP these days, so I'd call that enabling, not limiting
<maswan> smurf: installing specific software is not always an option, bt software is crap in usability compared to the simplicity of http downloads.
<Kamion> smurf: it's really horribly fiddly on the cdimage side to release bittorrent before everything else
<Kamion> smurf: we did it for DVDs in the past, and it was very awkward - I'd rather avoid it
<Kamion> I nearly lost the DVD images by accident
<Znarl> Our BT stats are pretty good as is.  Those who can are getting it from BT, it seems.
<Robot101> mjg59, Kamion, jdub: lunch?
<Kamion> Robot101: maybe. where?
<Kamion> hmm, probably not actually
<Kamion> still have to sort out edubuntu, and I promised Kirsten she could have my afternoon
<Robot101> were pondering kingston, a late lunch wouldn't help?
<Kamion> nah, she gets home early from work on Thursdays
<Kamion> the idea's appealing but I think I'll pass, too tired anyway really - enjoy yourselves :)
<mjg59> Robot101: Subscribe
<mjg59> Though I'm not out of bed yet
<Diziet> Bizarre.  This Dutch hoary -> breezy upgrade asked me whether I wanted British or American English as my wordlist.
<Robot101> mjg59: only just got up myself
<zyga> Diziet: did you have language-support-XX for your language?
<zyga> if not you didn't have a dictionary available
<zyga> hence - no dutch
<Kamion> Diziet: you found that before, if you remember
<Kamion> we never did get to the bottom of it
<Kamion> (although maybe not in a Dutch install - but it'll depend what wordlist packages are installed, anyway)
<Diziet> Yes, I was expecting it in an English install.  But in Dutch ?  Bizarre.
<Kamion> a non-networked install will only have installed English dictionaries because that's all that's on the CD
<Diziet> Ah, that'll be it.
<zyga> Diziet: did you have the relevant language pack + support for dutch?
<Diziet> No, I said no to getting stuff from the network.
<Diziet> Also, this is extremely painful because hoary doesn't detect my video card properly and it's running in around 800x600.
<zyga> Diziet: first problem solved ;-)
<Diziet> Metacity is _hopeless_ if you don't have enough pixels.  And lots of other things break too.
<Diziet> For example, the text on the login screen is unreadable, quite literally.
<mvo> yeah, we work not very well in 800x600 :/
<ogra> help ! still looking fr amd64 and powerpc testers for edubuntu !
<ogra> *for
<zyga> ogra: amd64 here
<zyga> ogra: howto please
<ogra> http://wiki.edubuntu.org/EdubuntuInstallNotes
<ogra> :)
<ogra> i need a test of all 3 installs
<zyga> ogra: I've got only one box
<zyga> ogra: can I manage on a single one?
<ogra> zyga, you can do them one by one ...
<zyga> k, pullling the iso now
<zyga> hmm web is rather sloooow
<mvo> ogra: at 34% for i386 here :/
<ogra> mvo, x86 is tested
<zyga> ogra: does releases.u.c even work?
<ogra> nope
<ogra> not yet
<ogra> damned...
<ogra> http://cdimage.ubuntu.com/edubuntu/daily/current/
<ogra> zyga, ^^^
<ogra> sorry
<zyga> n/p
<mvo> ogra: ok, canceld
<ogra> mvo, ppc or amd64 would be helpful
<maswan> ogra: I'm mirroring, at 20k/s, half-way through kubuntu, then edubuntu... :/
<mvo> ogra: I don't have a ppc
<Kamion> I'm doing amd64/workstation now
<\sh> woooo....just got the information from the tax department....they'll pay me 1800 eur back
<\sh> means, i could buy a new digicam for ubz
<ajmitch> \sh: great :)
<ogra> \sh, congrats
<mvo> \sh: what a day, breezy relase and money back! party!
<\sh> bad news...it's not on my account yet
<zyga> ogra: bugreport already: the torrents/isos should have edubuntu- prefix 
<zyga> ;-)
<\sh> mvo: yeah :)
<ogra> zyga, they'll have once they moved to release...
<Robot101> robtaylor, mjg59: lunch at 2pm?
<Kamion> zyga: yep, what ogra said, they'll be edubuntu-5.10-*.iso
<highvoltage> 1800 euro's that's very nice.
<zyga> ogra: okay, less than one hour left
<mjg59> Robot101: Sounds good
<ogra> zyga, yeah :)
<\sh> highvoltage: thats less then last years payback
<\sh> highvoltage: but actually my taxsoftware calculated correctly
<\sh> but last year i had more travel expenses
<thesaltydog> \sh, please tell us how did you reached this target: to have money back from taxes!!!
<maswan> thesaltydog: it's simple, pay more than you have to during the year. then you get the extra back, later, perhaps with nominal interest.
<thesaltydog> maswan, :-) I usually try to pay less... if allowed
<\sh> going back to hibernate mode....sleeping another 2 hours..
<mvo> \sh: sleep well
<Diziet> OK, I have some infelicities none of which I think are RC but I was wondering if people knew about:
<Diziet> * After my hoary->breezy, I logged out.  gdm did not present a new login screen; I just got the text leftover from boot.  C-A-D fixed it.
<Diziet> * If you, in order, launch Yelp, ooffice, `About Ubuntu', then `About Ubuntu' doesn't appear on top.
<Diziet> * `About Ubuntu' has a logo which is too small for the default window size.
<Kamion> Diziet: (it would be too late anyway if they were RC)
<Diziet> Oh.
<Kamion> that gdm thing seems like the worst
<Kamion> hmm, well my first guess was that gdm might be using s-s-d --exec and thus not restarting properly on upgrade, but that doesn't seem to be the case
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | Dapper opens ~Tuesday
<Diziet> I had that before with some of my earlier hoary->breezy upgrade tests but it went away.
<Kamion> it would be interesting to know if there's anything relevant in gdm's log file
* zyga can report that knoppix -> breezy update quite works so things are really resistant on some cases ;D
<Kamion> it seems to keep a few versions of the log, so you may still have the information
<Diziet> kamion: Nothing that I can see.
<Diziet> I think it didn't even try to run the server.
<HiddenWolf_> zyga, knoopix to breezy? what kind of move is that? :P
<zyga> HiddenWolf_: a very convulsed one at best
<mvo> carlos: do you have a idea about #17559 (beside the fact that markup shouldn't be in po files)?
<Kamion> Diziet: another interesting question might be whether /etc/X11/default-display-manager still says /usr/sbin/gdm
<Kamion> and whether the upgrade log says "Starting GNOME Display Manager..." or "Not starting GNOME Display Manager (gdm); it is not the default display manager."
<zyga> mvo: I may have a clue
<zyga> mvo: some time ago there was a bug in rosetta regarding escaping various HTML like syntax 
<zyga> mvo: it might be possible that some bogus translations have been comitted
<mvo> zyga: ok, thanks
<HiddenWolf_> zyga, I'd imagine
<HiddenWolf_> zyga, things messed up, or working nicely?
<zyga> HiddenWolf_: I initially removed a whole lot of stuff from knoppix that I didn't need
<zyga> HiddenWolf_: the rest *did* work and after remastering booted quite nicely
<Diziet> /etc/X11/default-display-manager> /usr/sbin/gdm, yes.
<Diziet> Strangely /var/log/installer/messages doesn't seem to mention gdm at all.
<Diziet> Ah.
<Kamion> /var/log/installer/messages is the log from the first stage of the installer
<Kamion> it won't mention gdm, indeed
<Kamion> ogra: edubuntu/amd64/workstation pass
<highvoltage> whohooo!
<ogra> yeah !
<Diziet> `Setting up gdm ... ....    Reloading GNOME Display Manger configuration.  Changes will take effect when all current X sessions have ended.   invoke-rc.d: initscript gdm, action "reload" failed.'
<ogra> Diziet, thats normal
<Diziet> It's true that later gdm goes from half-configured to installed.
<mvo> pitti: around? do you have a idea about #17646? it might be some sort of langpack problem?
<Kamion> all it's doing is sending SIGUSR1 to the process in /var/run/gdm.pid. Why is it failing?
<pitti> mvo: moment, please
<mvo> pitti: sure, no rush
<Diziet> Oh, that's from base-config.log which is the hoary install.
<pitti> Hi Yagisan 
<Yagisan> G'day pitti
<Diziet> daemon.log says   `localhost gdm[5701] : GDM restarting ...      localhost gdm[5701] : Failed to restart self'
<Diziet> And the timestamp is between me logging out and rebooting.
<Kamion> looks more promising
<pitti> infinity, elmo: may I humbly ask again about openssl_0.9.7g-1ubuntu1.1 which does not get built for breezy-security?
<ajmitch> evening Yagisan 
<Diziet> Shame it didn't tell us _why_ it failed.
<Kamion> perhaps gdm fails to Depend on everything it needs?
<Diziet> No, because rebooting (and doing nothing else) fixed it.
<Kamion> sure, but that would have been after a load of other stuff got configured
<Yagisan> G'day ajmitch
<Kamion> I'm assuming that gdm was restarted in the middle of a longer upgrade run
<BenC> any admins alive that can install a package on concordia for me?
<Diziet> No, it seems to have tried to restart exactly when I logged out, which was a minute or two after the upgrade finished.
<Kamion> ah
<Kamion> http://linux.slashdot.org/article.pl?sid=05/10/13/124243&tid=106
<pitti> mvo: hm, could that be a bug in the python gettext langpack support patch
<sabdfl> Kamion: well spotted
<Kamion> say goodbye to DC bandwidth
<mvo> pitti: update-notifier/notification-daemon are C
<pitti> ah, right
<Yagisan> pitti, ajmitch - whats up ? 
<Znarl> Those are very bad links on slashdot. :(
<pitti> hmm, no idea
<ajmitch> Yagisan: not a lot, about ready to sleep
<zyga> Kamion: servers - toasted ;-) ?
<Kamion> Znarl: at least they're not direct links to the datacentre ... but yes
<infinity> Kamion : Can you do me a favour?
<Kamion> infinity: yeah?
<jdub> GOOD MORNING BREEZY LOVERS!
<mvo> pitti: ok, thanks
<ajmitch> Kamion: I think DC bandwidth is already toast?
<ajmitch> morning jdub 
<infinity> Kamion : Have a look in the approval queue, and see if uploads for breezy-{security,updates} are getting hung up there?
<Kamion> ajmitch: well, latency at least to jackass is fine
<ogra> help * edubuntu still looks for a powerpc tester *
<Treenaks> ogra: I'll have a powerpc in a few weeks
<Treenaks> ogra: maybe even days
<ajmitch> Treenaks: minutes would be better
<ogra> Treenaks, great help... :)
<Kamion> infinity: they're in accepted, but not listed for approval
<Yagisan> ajmitch: I didn't think you needed sleep :-P
<ajmitch> ogra: 3% now :)
<ajmitch> Yagisan: oh I do :)
<ogra> ajmitch, 17 here
<pitti> Kamion: the source also appears in my helena, but the debs are not built
<Treenaks> ajmitch: sorry, the previous owner needs to wipe the disk, and he's slow :(
<desrt> man
<desrt> congrats on the release, guys :D
<Kamion> pitti: which package exactly?
<ajmitch> Treenaks: this is blocking edubuntu release :)
<ogra> Treenaks, get it *now* 
<pitti> Kamion: openssl_0.9.7g-1ubuntu1.1_source.changes
<pitti> Kamion: the source is in accepted/, but the binaries aren't
<Kamion> openssl_0.9.7g-1ubuntu1.1_source.changes
<Kamion> I: IGNORING -security upload
<pitti> Kamion: they are either not built, not not uploaded, no idea
<infinity> pitti : That's cause they're not getting into wanna-build./
<desrt> pitti; i have a bug that requires your attention 2 days ago :)
<pitti> desrt: then we better hurry.. :-)
<Kamion> one sec
<infinity> pitti : elmo said he'd look into it in the morning, but if it's urgent, maybe Kamion can poke it with a stick.
<sabdfl> US mirror is going to love that :-)
<desrt> pitti; all gphoto apps crash on powerpc (including the camera import thingy that automatically loads)
<desrt> pitti; due to your duplicate filename vendor patch :(
<zyga> ogra: edubuntu download suddenly seems to be slow as hell... will test ASAP though
<ogra> zyga, thanks...
<sabdfl> zyga: slashdot
<pitti> desrt: hm, sounds like a good candidate for -updates
<desrt> pitti; quite.
<Yagisan> Anyone with an 8139too based card want a fun problem ?
<Kamion> infinity: hmm, /srv/buildd.no-name-yet.com/trigger.daily has special cases for (warty|hoary)-security but not breezy-security
<BenC> Yagisan: I'll bite :)
<desrt> pitti; please note: i have no idea if my patch is correct.  it fixes the issue for me but it might not match the intended logic of the original author
<pitti> desrt: did you send it to the bug?
<Yagisan> BenC: heh - http://bugzilla.ubuntu.com/show_bug.cgi?id=9972 - but I think you should have it already
<Kamion> infinity: is this FIXNOW priority? touching trigger.daily scares me
<pitti> desrt: I neglected my bug mbox for two days now
<desrt> pitti; i opened a new one
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=17670
<zyga> Yagisan: I've got a card like that but I don't want any problems as it powers my home server ;-) if it can wait a week I'll be glad to help
<infinity> Kamion : Ask pitti.  We can certainly wait for -updates, but if he thinks his -security uploads need to go in Yesterday, then...
<infinity> pitti : ?
<Yagisan> BenC, Zyga - 3 separate 8139too cards (2 8139D, 1 8139C) do that on me
<Diziet> Oh, I'm not on ubuntu-announce (!)
<pitti> Kamion: no, that openssl issue is not very critical, a delay of one day is fine
<Kamion> pitti: I think I see the problem, but I don't know if there are knock-on effects
<pitti> Kamion: I can wait for elmo
* zyga has about a dozen of those cards around his house - they were so abundant a few years ago
<Kamion> breezy-updates should just work AFAICS
<Yagisan> zyga: (It's my firewall/apt-cache that is affected)
<infinity> Kamion : But clearly doesn't (unless IT needs approval... Which would make sense)
<infinity> Kamion : Anyhow, we'll wait on elmo if pitti's upload isn't urgent.  I just saw him bugging me up there (points) and assumed otherwise. :)
<Kamion> elmo: jackass:~cjwatson/trigger.daily.diff seems to be the required change - not applied
<Kamion> infinity: they need approval. that I can probably take care of
<Kamion> elmo: a helena mode that shows breezy-updates would be nice
<BenC> Yagisan: Have you tried those cards on another machine?
<Yagisan> BenC: Yes - they work fine and an AMD64 box (in fact I using one now instead of the onboard Gige)
<infinity> Yagisan : The 8139too driver should deal with losing interrupts more gracefully (and pcnet32 obviously does, hence your experience), but it's still almost certainly a hardware/firmware bug, exacerbated by a lousy driver.
<Kamion> infinity: I've approved mozilla on its own; let's see if that works
<Kamion>    mozilla | 2:1.7.12-0ubuntu2 |        breezy | source
<Kamion>    mozilla | 2:1.7.12-0ubuntu05.04 | hoary-security | source
<infinity> Yagisan : And if it supports "just enough ACPI to make Windows happy", that's a pretty good indication that if we try to route the IRQs wrong, it WILL blow up.
<Kamion>    mozilla | 2:1.7.12-1ubuntu1 | breezy-updates | source
<BenC> Yagisan: then that proves it is not the driver, but a problem with the machine you are running it on
<Yagisan> infinity: In so many cards ? and not showing up in older kernels ?
<infinity> Yagisan : It's not the card's fault, it's the BIOS/motherboard.
<infinity> Yagisan : And the driver makes it worse.
<Yagisan> infinity, BenC: while I know acpi is crap on the board - it is actually disabled
<infinity> Yagisan : Other drivers (VIA Rhine comes to mind) have similar issues with losing interrupts on lousy BIOSes.
<infinity> Yagisan : Note that ACPI power saving != ACPI PCI routing.  Disabling one usually has no bearing on the other.
* infinity goes to look at your dmesg output.
<Yagisan> infinity - It has no acpi routing
<Kamion> ogra: edubuntu/amd64/server pass
<Yagisan> infinity, BenC - later tonight I'm putting a P2 233MHz box up to replace it - that will test if it is a BIOS error
<ogra> Kamion, yippie :)
<Yagisan> infinity, BenC - is there anything else I can try as well ?
<infinity> BenC : Do you know, off the top of your head, all the kernel command lines to swap between the 7 billion different PCI routing impementations?
<BenC> Yagisan: you need to tell the kernel ACPI is disabled, it is still trying to use it
<BenC> infinity: off the top of my head, no
<Yagisan> BenC: OK (thankfully I haven't given the pcnet32 back yet)
<BenC> Yagisan: I thought you said that you already tested the cards on another machine
<mjg59> infinity: documentation/kernel-parameters
<BenC> we need a grub menu.lst generator that will allow for testing all kernel workarounds
<Yagisan> BenC: yes I have - but still - if the machines is stuffed - I'll need something to replace it with if nothing else works
<BenC> Yagisan: I'm just saying, the fact that the cards already work on another machine most definitely shows that the driver is not broken in relation to the cards
<Yagisan> BenC - it doesn't seem to handle losing an interrupt well
<Yagisan> BenC - I'd have expected the pcnet32 to fail too actually
<BenC> that's because generally another interrupt will come along to unbork it
<infinity> acpi=off pci=noacpi
<Yagisan> BenC - so why doesn't that happen with 8139 ? 
<BenC> true, it's not handling it gracefully, but the bios/hardware is still broken
<infinity> Yagisan : About half the network drivers in Linux die when they lose interrupts.  While this isn't "graceful", it's also not really their fault.
<infinity> I spent months swearing at the via rhine driver until I figured out the real problem. :/
<infinity> Others definitely seem more resilient (3c59x, e100/eepro100, pcnet32)
<Yagisan> infinity - BenC - I'll test infinitys suggestion in a moment (hence I'll drop out - it is my gateway with the problem)
<Kamion> infinity: mozilla should've appeared in w-b for you now
<Kamion>   Package             : mozilla
<Kamion>   Version             : 2:1.7.12-1ubuntu1
<Kamion>   Builder             : buildd+terranova
<Kamion>   State               : Building
<infinity> Kamion : Yup, it's building.
<infinity> Kamion : A tbird and an enigmail to go with that would be swell.  Or do you want to wait until we do a full cycle (binaries uploaded and installed) before we call it good?
<Yagisan> infinity, BenC - I just updated grub - I'll be back soon with the results.
<Kamion> infinity: I'd rather wait a full cycle with just the one package to make sure it all works
<Amaranth> arg this computer doesn't have a cd burner and the library is closed
<maswan> Znarl: You could always hack yourself out of DNS for a couple of hours to free up bandwidth. ;)
<Znarl> maswan : Really?  Where?
<bddebian> Hello
<infinity> Kamion : Meh, why did you have to accept the biggest of the three packages? :)
<infinity> (Still building)
<Yagisan> BenC, infinity - back from torturing my gateway
<Yagisan> BenC, infinity - the kernel parameters have worked - so how would that be autodetected in future (for similar boxes ?)
<zyga> a solution to ./ crowd = merge canonical with AOL and get cd-pressing factories! :D
<Treenaks> zyga: omg
<zyga> then get merged with goooogle and dominate the world :)
<Kamion> infinity: d'oh
<calc> are the mirrors still not updated?
<infinity> Kamion : Okay, uploaded on the threee primary arches.
* infinity waits for 13 minutes to see what happens.
<calc> i don't see edubuntu/ubuntu-server/dvds on the mirrors
<Kamion> ogra: edubuntu/amd64/default pass; my wife was rather interested watching me play around with it and seemed to quite like the range of educational software (she's a teaching assistant); she wants to know what our interactive whiteboard support is like
<Kamion> calc: edubuntu/ubuntu-server aren't published yet
<calc> ok
<Kamion> calc: dvds are on http://cdimage.ubuntu.com/releases/breezy/release/, http://cdimage.ubuntu.com/kubuntu/releases/breezy/release/ - they don't fit on releases.u.c for disk space reasons
<Kamion> calc: I'll put a link in at some point
<ogra> Kamion, we dont have any yet... there is no good oss solution to my knowledge yet
<zyga> ogra: amd64 keeps failing to download 
<calc> Kamion: ok
<ogra> zyga, gah
<Kamion> ogra: hm :(
<seb128> calc: do you plan to fix the menu-xdg duplicate entries bug one day? The BTS has a patch for months 
<ogra> Kamion, certainly something on my dapper applist :)
<Kamion> ogra: more a kernel/X thing, I imagine?
<ogra> Kamion, thanks for the wiki fixes btw :)
<Kamion> np
<ogra> Kamion, yup
<calc> Kamion: not trying to be annoying but the .pool dir has lots of rc files in it still they might fit once that is cleaned out ;)
<ogra> there are proprietary linux solutions with binary kernel module
<Kamion> calc: they're already removed on the master
<calc> ah ok i guess i am looking at the uk mirror then
<Kamion> calc: the mirrors are having trouble because rsync is mirroring the new files first, then deal with removals
<ogra> but i think it should be possible on a higher layer too... like collaborative editors work
* calc keeps forgetting that the system he is looking at isn't the primary one
<calc> seb128: yea, i er forgot i guess
<infinity> Uh oh.
<calc> seb128: i'm planning on updating theora hopefully today as well
<infinity> Kamion : Can you REJECT those in the next 10 minutes? :0
<maswan> we're serving about 1600-1800 downloads of i386-install right now. :)
<luis__> congrats
<Kamion> infinity: what's wrong with them?
<infinity> Kamion : pkgstripstranslations wasn't in the chroot, afaict.
<maswan> plus some kubuntu, live, adm64, etc.
* zyga remembers beeing here when hoary released
<infinity> Kamion : Which, I assume, means it will conflict with the langpacks, right?
<seb128> calc: cool
<infinity> Kamion : Which would be, uhh, bad.
* infinity curses whoever built these chroots.
<Kamion> infinity: I don't see huge piles of locales in mozilla-browser?
<infinity> Kamion : Pure fluke, then.  pkgstriptranslations definitely wasn't there and din't run.
<infinity> Kamion : I'd feel more at ease if you reject the binaries and give me a chance to fix up all the chroots. :/
<Kinnison> infinity: You're gonna have fun in a day or so when you have to do all new chroots for dapper :-)
<Kamion> infinity: can't reject out of accepted, but, um, I'll see if I can temporarily disappear them or something
<infinity> Kamion : unaccept, then.
<infinity> Kamion : Same difference at that stage.
<Nafallo> maswan: is that more or less load than hoary? :-)
<infinity> Just so long as they don't hit the pool, (and the changes disappears from queu/done), all is good.
<infinity> Kinnison : dapper chroots are easy.  It's fixing up these breezy-{security,updates} chroots that were made 6 months ago and seem a bit.. Wrong... That's the fun right now.
* infinity should have checked this earlier.
<ogra> sigh, still 6h ETA for ppc...
<pitti> infinity: no, if packages ship mo files (i. e. unstripped), they won't conflict with langpacks
<pitti> infinity: it's just redundancy
<pitti> Kamion: ^
<infinity> pitti : How does that work?... Do the langpacks install to a different location?
<pitti> infinity: /usr/share/locale-langpacks :-)
<infinity> Clever.
<pitti> infinity: we have a glibc patch that also looks there
<infinity> Yeah, obviously.
<pitti> infinity: otherwise you could never install a package that you built locally
<infinity> Kamion : Okay, forget my panic, but do me a favour and wait for a green light before approving the other two.  I want to freshen up the world.
<Yagisan> infinity, BenC - perhaps http://bugzilla.ubuntu.com/show_bug.cgi?id=9972 should be reassigned to fails to disable broken acpi ?
<pitti> infinity: yes, stripping security updates is a good idea. Thanks for looking at it
<Kamion> infinity: I can't see how to unaccept manually, but I've moved them out of the way
<Kamion> infinity: does your comment above mean I should move them back?
<sabdfl> pitti: are you the postgres package guy?
<pitti> sabdfl: yes
<sabdfl> psycopg.ProgrammingError: ERROR:  could not open file "/usr/share/postgresql/contrib/english.stop": No such file or directory
<infinity> Kamion : If they're moved completely out of the way, I'll rebuild and reupload with the freshened chroots.
<sabdfl> on breezy :-/
<infinity> Kamion : The comment was more just to save you the trouble.
<Kamion> katie@jackass:~/queue/temp-hold/mozilla$ for x in *.deb; do dpkg -c $x | grep usr/share/locale; done
<Kamion> katie@jackass:~/queue/temp-hold/mozilla$
<infinity> Kamion : But if you've gone to it already, I want t odo it "right".
<infinity> Actually, yeah.  Just move 'em back then.
<maswan> Nafallo: more, much more. but then, the 1.2Gbit/s peak we managed at hoary was enough to double-port the computer club gigE switch to 2xgigE.
<Kamion> infinity: pkgstriptranslations also collects stuff for rosetta, doesn't it?
<pitti> sabdfl: that file is now in /usr/share/postgresql/8.0/
<Kamion> infinity: although I guess nothing's changed?
<infinity> Kamion : Yes, and right.  Nothing's changed.
<pitti> sabdfl: (or 7.4, depending on your server version)
<Kamion> infinity: ok, will move back
<Nafallo> maswan: hehe, nice :-)
<Kamion> infinity: which is good, 'cos I don't know if randomly moving stuff out of accepted breaks katie or not
<infinity> Kamion : Alright.  I'll ping back in 10/15 mins when the chroots are all happy.
<sabdfl> pitti: fine.... but shouldn't the software know that itself?
<sabdfl> that's not a file I told it to use
<pitti> sabdfl: which software do we talk about?
<sabdfl> i'm just using psycopg
<Kamion> infinity: I'm going to test Edubuntu/powerpc for a bit, so may well be longer than that, and I want to have most of the afternoon off
<sabdfl> launchpad
<pitti> sabdfl: oh, psycopg itself wants that file?
<Kamion> infinity: might be best if you pinged elmo/mdz later
<dieman> heh
<infinity> Kamion : Or I can just stop all the buildds and you can approve the uploads now.
<pitti> sabdfl: it does not even depend on postgresql-contrib*
<dieman> my mirror is running a little slow this morning :)
<infinity> Kamion : If you approve them now, that gives me a 30+ minute window anyway, cause we just missed cron.daily.
* jbailey wonders if it's better to hack on making the installer notice two identical disks and smoothly do raid1+lvm, or if it's better to make evms work at that point.
<sabdfl> pitti: i have the file in 7.4 subdir
<sabdfl> but SOMETHING is looking for it in the old place
<sabdfl> hmm
<sabdfl> oh... the db dump i am using came from a hoary box
<pitti> bah, it is impossible to get something from archive.u.c
<pitti> I wanted to look in psycopg sources
<infinity> Kamion : I won't begrudge a man his afternoon off after a stressfuly week. :)
<dieman> pitti: try ftp.heanet.ie, it still seems reachable from here
<infinity> pitti : This is why we have local mirrors.
<pitti> sabdfl: ok, confirmed; psycopg itself has nothing to do with it (and shouldn't)
<Lathiat> pitti: heh, archive.u.c is swamped?
<fabbione> infinity: so the only reason you are not pushing -updates is because of the chroot, right?
<sabdfl> ok, seems like its a local config issue, not a general problem
<pitti> infinity: I just tried apt-get source on concordia
<sabdfl> except i guess that i hope our upgrade scripts trap this sort of thing
<pitti> dieman: I did that in the data center
<pitti> sabdfl: so far I wasn't even aware of that file
<maswan> dieman: at least for now, we'll see. :)
<ogra> NOOOO
<ogra> my ppc download dropped.... damned
<ajmitch> ogra: wget -c !
<pitti> sabdfl: these directories only contain stuff that is actually server specific; clients should not use it
<ogra> yes...
<ogra> i'm already running that...
<ogra> *sigh* i'll never get this release out :'(
<maswan> ogra: that's why I'm trying to encourage the DC admins to unswamp their network. ;)
<lifeless> mdz: congrats
<lifeless> gnight all
<pitti> night lifeless 
<ajmitch> night lifeless 
<ogra> and i dont even think that we'll have any powerpc users with edubuntu
<dieman>  09:11:26 up 17:11,  2 users,  load average: 94.93, 92.84, 82.27
<dieman> bahwhahaha
<dieman> its all iowait too, not enough ram
<Lathiat> heh, whats that on
<dieman> mirror.cs.umn.edu
<Lathiat> ah
<Lathiat> got bandwidth graph?
<maswan> dieman: load average: 0.03, 0.13, 0.10, Out: 85993.16kB/s
<dieman> its doing 187mbps
<Lathiat> i see maswan is doing about 250M/s collectively
<dieman> its a horribly underpowered machine
<dieman> i need to move the NIC too
<Lathiat> maswan: whast the url for your unis whole link?
<dieman> it got ont he same irq as the disk :)
<dieman> which is suuper-suck
<maswan> Lathiat: http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005-10--13,raw,traffic-kbit
<dieman> total:     5.52 Mb/s In   223.57 Mb/s Out -  10242.3 p/s In   18880.5 p/s Out
<dieman> mmmm. happy peak
<dieman> its only a dual 7333, 1gb rambus
<stub> pitti: tsearch2 stores the location on the stop words list in pg_ts_dict. This looks like what bit sabdfl, because the tsearch2 config from the dump made on hoary now references non-existant files.
<dieman> 7333 rather
<dieman> 733 rather
<Lathiat> maswan: eh, nice, so how far can you push it? :)
<dieman> single disk
<ajmitch> maswan: looking good
<Lathiat> maswan: ooh.. looks like it pretty much hit it
<maswan> Lathiat: that far. :/
<Kamion> ogra: I have a powerpc workstation install in progress
<pitti> stub: ah, bad
<stub> pitti: It might be worth considering some symlinks? I'm not too familiar here. 
<Kamion> ogra: it'll take a while because I'm not paying it much attention, but it's running
<maswan> dieman: borrow a temporary machine with a few gigs of ram, http-redirect the i386 install iso there?
<ajmitch> maswan: so you finally managed to saturate your link? congrats :)
<maswan> dieman: http://farbror.acc.umu.se/stats/monitordata/index.shtml
<dieman> maswan: dont have many machines lkike that hanging out
<maswan> dieman: that's what test[01]  is doing there
<dieman> heh
<Lathiat> looks like test1 dropped off
<stub> pitti: I'm not sure though. Using tsearch2 is a pretty manual process, so maybe it isn't a requirement
<maswan> ajmitch: thanks
<maswan> Lathiat: there is some lag in moving the measurement data
<Lathiat> maswan: ah ok
<ogra> Kamion, *sigh* how shall i ever pay that back to you
<pitti> stub: so you migrated to breezy now? how did the db upgrade go, any errors apart from this one?
<pitti> stub: the transition script is pretty complex and there were bugs in the past
<Lathiat> what you need is machines with 16GB of ram :)
<Lathiat> or 48 i think debian has one like that
<stub> pitti: I migrated to breezy a while ago, but I wouldn't have noticed how the db upgrade went - we blow away the dev databases when running the test suite.
<pitti> ah, I see
<maswan> Lathiat: nah, this dataset is small enough. test[01]  have 8 gigs each and hold the hot data in ram.
<Lathiat> maswan: ah cool
<stub> pitti: We can test on our staging server at some point though ;)
<maswan> Lathiat: debian was harder since cd+dvd isos were >16 gigs.
<maswan> Lathiat: for i386
<Lathiat> maswan: ah
<Nafallo> maswan: nice. you have peeks every 6 months ;-)
<zyga> pitti: do you have 160 seconds?
<pitti> zyga: exactly? :-(
<pitti> :-)
<pitti> even
<zyga> pitti: a bit less I hopwe
<pitti> zyga: sure, I also have more
<zyga> pitti: how do you validate exports from rosetta when you build langpacks?
<pitti> zyga: yes, I did
<zyga> pitti: I've ran across some errors in last export tarball
<zyga> pitti: carlos is all aware and will look into them
<pitti> zyga: I produced a normalized diff, looked at the 30 MB diff and throwed out all obsolete and buggy files
<zyga> ah so you dump everything that is borked
<pitti> zyga: for the final langpacks, yes
<zyga> cool that explains it
<pitti> zyga: I didn't want to drop all rosetta updates, so I had to cherrypick
<zyga> you looked at 30 megs of diff??
<pitti> yes :-/
<zyga> god
<pitti> it took about 4 hours to clean it up
<TFP> hi
<zyga> pitti: did you set up any automated stuff that helps with this?
<TFP> i just wondered if ubuntu fixed the HAL problem in their new release, anyone knows more?
<pitti> zyga: of course I used some clever vim regexps
<pitti> TFP: "the HAL problem"?
<pitti> TFP: bug# ?
<zyga> (I'm pretty in the same position now but I don't want to fix it - just be able to process data quickly and get nice results and reports
<TFP> failed to initialize HAL on startup
<pitti> zyga: no, just vim and regexps
<pitti> zyga: but you can have the list of invalid files that I threw out
<zyga> pitti: okay thanks :-)
* zyga has similar list now
<pitti> zyga: I kept it in case I or sb else needs to do it agin
<zyga> I don't care about differences ATM
<pitti> zyga: http://people.ubuntu.com/~pitti/langpacks/rosetta-killed.txt
<pitti> TFP: depends on the reason for it; there was a dbus bug maybe two months ago which caused that
<pitti> TFP: but it generally works in more recent breeezy versions
<TFP> pitti: and is it solved?
<TFP> ah ok
<TFP> that was the reason why i dumped ubuntu
<TFP> cause it crashed randomly
<pitti> TFP: hey, this bug was there for about *two days*
<TFP> and i had to wait 5 minutes for gnome to startup
<pitti> TFP: oh, wait, that bug did not cause it to crash randomly
<pitti> TFP: can you please try the current live CD?
<pitti> TFP: if it still crashes, can you please ping me?
<hunger> TFP: Are you using SATA drives?
<TFP> well i just dl the new breezy and wanted to test it
<TFP> nope
<OddAbe19> did dapper open tuesday as in 2 days ago or 5 days from now?
<hunger> TFP: My system used to be very instable due to the kernel ubuntu used for a while.
<pitti> OddAbe19: it's not yet open
<hunger> TFP: It did not like SATA too much for me:-)
<OddAbe19> check check
<TFP> well i dont have sata
* hunger is looking forward to dapper.
<pitti> hunger: is breezy too outdated for you?
<TFP> well we'll see if the problem was fixed for my pc ;)
<hunger> pitti: No, but there are a couple of items that got postponed in breezy that might be cool:-)
<bddebian> Sheesh :-)
<pitti> hunger: right
<hunger> pitti: And you did not get round to checking out my cryptodick script in time either...
<Yagisan> hunger: cryptodick ?? typo perhaps 
<ivoks> cryptodick :))
<pitti> nice name
<hunger> pitti: Plus I would love to help getting hibernation to work with crypted swap spaces, too (even though I doubt that my current settup will work):-)
<pitti> ivoks: so that you can't fall into  holes *duck*
<Mithrandir> jbailey: do we support booting off USB drives?  That is, my initramfs goes boom when trying to pivot_root.
<ivoks> pitti: ;)
<jbailey> Mithrandir: If your initramfs is trying to pivot_root, you're seeing other problems...
<pitti> hunger: resuming from encrypted swap really works?
<jbailey> Mithrandir: Should be running a command called "run-init" instead.
<jbailey> Mithrandir: Have you forced it back to mkinitrd?
<Mithrandir> jbailey: ah, this is hoary, we're going to dist-upgrade to breezy.  I'll annoy you in a little while. :-)
<jbailey> Mithrandir: =)  No USB booting in Hoary. =)
<jbailey> Mithrandir: You may have timeout troubles in Breezy.  You may need to add a longer sleep in Breezy to get it to work right too, but it will work.
<ajmitch> jbailey: so I should be able to boot off my camera with breezy? :)
<jbailey> ajmitch: Mmmm.  If you can fit everythingo n a fat filesystem, sure.
<jbailey> Most cameras don't do well with ext2 media. =)
<ajmitch> I wouldn't use the card to take photos :)
<highvoltage> have  you guys checked JaneW's edubuntu cake yet? http://www.flickr.com/photos/13916877@N00/52139491/
<jbailey> Ahahah, cool.
<ogra> highvoltage, gah why didn you wait until release with the cacke.... 
<ogra> it might curse us now ....
<ogra> :)
<Mithrandir> jbailey: we'll see in a little while
<JaneW> ogra: it's a good luck charm, I wouldn;t have made it if I thought there was a risk...
<jbailey> Mithrandir: Cool.
<jbailey> Mithrandir: IS this one of your I2O systems?
<highvoltage> dammit
<Mithrandir> jbailey: no, it's a friend's laptop.
<highvoltage> JaneW: whatever you do, don't eat any of the cake!
<ogra> heh
<highvoltage> ogra: i think as long as nobody eats any of it, we're safe.
<ogra> ok
<highvoltage> JaneW: lock your kids in their rooms tonight.
<highvoltage> or sent them to your mother.
<ogra> Kamion gets the first piece !
<Mithrandir> jbailey: I'll have access to the i2o system next week or so, I hope.  It got punted a bit because of some hardware problems.
<jbailey> Mithrandir: It's all good.
<JaneW> highvoltage: good idea!
<jbailey> I don't suppose there's cheap consumer grade i2o systems are there? =(
<Mithrandir> jbailey: hahahahahha.
<hunger> pitti: several people claim so, I have not seen it myself yet.
<jbailey> I ought to try and acquire one for dapper if we want to support that grade of hardware.
<hunger> pitti: My encryption scheme is a bit too ... involved ... to test this with.
<jdub> yay
<jdub> nokia are going to send my 770 to montreal!
<Mithrandir> fish!
<jbailey> jdub: Where are you having it sent to?
<jbailey> jdub: If you want, you can use my address.
<jdub> jbailey: the hotel, methinks
<jdub> jbailey: NOT ON YOUR LIFE!
<mjg59> jeff, you haven't even touched your chicken yet
<jdub> good try though
<jbailey> mjg59: Err, what?
<jbailey> Oh.
<jbailey> *him*
<ajmitch> heh :)
<jdub> he's hassling me for eating my vegetables first
<mvirkkil> dholbach: Uh, what did you add? Docbook export?
<jbailey> jdub: I think that's perfectly reasonable.
<mjg59> jbailey: But you're a food deviant
<dholbach> mvirkkil: erm?
<infinity> kamion : Gone for the afternoon already?
<Robot101> mjg59: stop IRCing and eat, you're the deviant
<infinity> Kamion : If not, those uploads can be approved any time.
<mjg59> Robot101: Hypocrite
<dholbach> mvirkkil: what are you talking about?
<Robot101> restaurants with wifi = win
<dholbach> Robot101: i'm in a cafe with free wifi :)
<mjg59> (Also: never drinking again)
<jbailey> mjg59: Vegans taste better.
<mvirkkil> dholbach: You wrote to me and said: "dude, I already did that" or something to that effect.
<mvirkkil> 22:47:15< dholbach> mvirkkil: dude, i added that already
<dholbach> mvirkkil: that must have been with lack of sleep, and i meant "mvo" - sorry for that
<mvirkkil> dholbach: np
<dholbach> :)
<highvoltage> guys, what's going on with the wiki?
<dholbach> highvoltage: what's wrong? is it slow?
<highvoltage> no, all the pages were gone for a short while, now it's back. very strange.
<highvoltage> i also got those python purple cgi error screens.
<highvoltage> working now again too.
<ogra> mjg59, so we wont see such funny uploads anymore ? bah...
<mjg59> Haha
<mjg59> I haven't actually signed the NDA yet
<ogra> heh
<elvirolo> hi guys
<elvirolo> did the release go as you expected ?
<bob2> breezy went out, mjg59 got drunk, everyone else went to sleep
<bob2> more or less what everyone expected
<elvirolo> great :)
* highvoltage has been awake since 3am
<bddebian> bob2: :-)
<bddebian> Oh yeah we can vote on mjg59 today eh?
<ogra> bddebian, tomorrow
<bddebian> Tomorrow? I thought it said the 13th?
<spayne> well done guys! i'm proud of you all :)
<mjg59> bob2: I was drunk before Breezy released
<mjg59> There was some champagne, though
<Lathiat> mm, the poll page could do with some ui fixes ;p
<bddebian> ogra: From the page: "The voting will be opened on 2005-10-13."
<Lathiat> bddebian: says 2005-10-14 here
<Lathiat> that might be timezone converted or something tho
<bddebian> Hmm.  Must be a timezone thing :)
<dieman> heh
<dieman> that machine *still* has a load of 100
<dieman> even after moving the nic
<dieman> im thinking of bringing thttpd back up ;)
<dieman> jeezus crhist
<dieman> the box is doing 278-300 mbps
<the--dud> grats folks, I'll be sure to update to breezy in a few weeks ;)
<the--dud> even slashdotted the release of breezy, can't remember the last time a linux distro release was slashdotted :o
<jbailey> I doubt if it's just /..
<jbailey> It's not like the release date wasn't well publicised anyway.
<highvoltage> and anticipated
<Keybuk> slashdot like us today?
* Keybuk faints
<Keybuk> I was already weak because I'd managed to catch up with -bugs over just one cup of coffee
<Amaranth> the--dud: every release of ubuntu has been /.ed
<highvoltage> the top distro get's /.ed :)
<Mirv> fi.archive.ubuntu.com seems not responding :( I guess it should be changed to point to se.archive.ubuntu.com if it can't be fixed
<Kamion> Mirv: fi.archive == archive; it's just overloaded
<Amaranth> us.archive is a real seperate mirror, right?
<Mirv> Kamion: ok, thanks, tried to find out but couldn't
<Amaranth> Mirv: http://wiki.ubuntu.com/Archive might help
<jdub> mdz: HAPPY BIRTHDAY!
<jdub> mdz: HAPPY BIRTHDAY!
<jdub> mdz: HAPPY BIRTHDAY!
<jdub>  _  _   _   ___ _____   __  ___ ___ ___ _____ _  _ ___   ___   __
<jdub> | || | /_\ | _ \ _ \ \ / / | _ )_ _| _ \_   _| || |   \ /_\ \ / /
<jdub> | __ |/ _ \|  _/  _/\ V /  | _ \| ||   / | | | __ | |) / _ \ V / 
<jdub> |_||_/_/ \_\_| |_|   |_|   |___/___|_|_\ |_| |_||_|___/_/ \_\_|  
<jdub> 
* pitti joins the choir
<Kamion> Mirv: well, compare 'host fi.archive.ubuntu.com' with 'host archive.ubuntu.com' and it should be obvious
<Kamion> Amaranth: not atm
<Kamion> it was, but I think it broke
<Kinnison> jdub: have you sent me the details yet?
<highvoltage>  _   _                           ____        ____    _ __   __
<highvoltage> | | | | __ _ _ __  _ __  _   _  | __ )      |  _ \  / \\ \ / /
<highvoltage> | |_| |/ _` | '_ \| '_ \| | | | |  _ \ _____| | | |/ _ \\ V / 
<highvoltage> |  _  | (_| | |_) | |_) | |_| | | |_) |_____| |_| / ___ \| |  
<highvoltage> |_| |_|\__,_| .__/| .__/ \__, | |____/      |____/_/   \_\_|  
<highvoltage>             |_|   |_|    |___/                                
<highvoltage>                _     _ 
<zyga> geez
<highvoltage>  _ __ ___   __| |___| |
<highvoltage> | '_ ` _ \ / _` |_  / |
<Robot101> EBLEEDINGEYES
<highvoltage> | | | | | | (_| |/ /|_|
<highvoltage> |_| |_| |_|\__,_/___(_)
<highvoltage> 
<highvoltage> oops, that was a bit big.
<highvoltage> sorry
<Amaranth> ESTABPEOPLE
<highvoltage> well if he doesn't see that he must be blind :P
<jdub> highvoltage: -f small, dude
<highvoltage> aah, /me makes mental note of that
<zyga> jdub: banner didn't do that - what did you use?
<jdub> figlet
<Lathiat> figlet
<Lathiat> eh
<Lathiat> figlet happy bday | cowsay -n -f sodomized
<Mirv> Kamion: true, true, I guess I'm tired as I didn't check that way
<dieman> heh
<dieman> ok i drank the lighhttpd kool-aide
<dieman> and its worthless
<dieman> back to apache we go
<dieman> kool-aid, rather
<juliux> pitti, ping
<dholbach> bbiab
<pitti> Hi juliux 
<zyga> for the first time in my life I cannot connect to nn.archive.ubuntu.com
<juliux> pitti, today release party in dresden?
<the--dud> anyone tried to just switch out your sources.list from hoary to breezy yet?
<the--dud> perhaps it wise to wait out a week or two for some bugs to go away
<pitti> juliux: haven't heard about any, did you?
<juliux> pitti, no but i see that you are also in dresden
<pitti> juliux: I am, right
<Diziet> keybuk: Why does hct depend on python (>= 2.4) rather than python2.4 ?  That makes it hard to get it to install on sarge.
<Keybuk> dunno
<Keybuk> I think that's what Python Policy told me to do
<Diziet> In fact, it depends on both.
<Diziet> Which is just bizarre.
<Keybuk> there used to be 2.3 packages too
<Keybuk> but I dropped support for them
<Diziet> So you're doing `support one or several Particular Version(s)' ?  In which case the Depends: python (>= 2.4) is wrong I think.
<infinity> Python policy says that metapackages should depend on "foo-python$(current-default)" and "python (>> foo) (<< bar)", while the packages the metapackages depend on should just depend on python-$(version they use), no?
<Kamion> if you're using /usr/bin/python, you do need a dependency on python
<Kamion> (so perhaps DDTT, haven't checked)
<Diziet> There's no reason for the metapackages here, since hct only works with 2.4 and the python hct module is for hct.
<Diziet> kamion: Indeed, it doesn't do that.
<Kamion> ok
<Diziet> The situation we have atm is that hct only works if the default python is 2.4 which isn't true in sarge.
<Diziet> Err, only installs.
<Diziet> I haven't tried forcing the dependencies.  That would probably work.
<Kamion> 16:07 < CIA-4> debian-installer: jdthood-guest * r31356 packages/netcfg/
<Kamion>                (debian/changelog netcfg-common.c): Eliminate
<Kamion>                localhost.localdomain as name of 127.0.0.1
<Kamion> woo, about time
<Keybuk> *shrug*
<Keybuk> I care about sarge -> <- this much right now :p
<infinity> etch, even.
<Kamion> and unstable
<infinity> But, we also use that default in ubuntu.
<Diziet> kamion: *excellent*
<Kamion> Keybuk: won't it break when we switch to python 2.5 as default, too?
<Keybuk> Kamion: then I'll fix it :p
<Kamion> I mean, if you're using /usr/bin/python2.4
<Keybuk> I think I just use /usr/bin/env python
<Diziet> keybuk: Fair enough.  I just thought I'd mention itt.  Perhaps you can fix this next time you happen to be in the general area.
<Keybuk> Diziet: yeah, will re-read python policy again
<Diziet> root@anarres:/work# head -1 /usr/bin/hct 
<Diziet> #!/usr/bin/python2.4
<Keybuk> hmm, maybe the python installer does something with that then
<Keybuk> it's #!/usr/bin/env python in arch
<pitti> Keybuk: you should at least usr #!/usr/bin/python, otherwise you will get a bug from `anthony that hct breaks on his machine
<Diziet> When you do, remember that you want `Support one or several Particular Version(s)' and not `Support All/Most Versions (Including Default)'
<siretart> is hct somewhere publicy availabe?
<infinity> Kamion : Are we going to make that same change in dapper, then?
<Kamion> Diziet: localhost.localdomain> discussion established that nobody really knew why it had been introduced in the first place, and it seemed to kind of appear out of nowhere in the bug log with no justification
<pitti> Keybuk: (which still has python1.5 in its $PATH)
<Kamion> infinity: hell yeah
<infinity> Kamion : I patched a couple of packages in breezy to deal with that oddity.
<infinity> Kamion : But they should also deal the other way (I made sure of that)
<Keybuk> pitti: I plan to re-do the packaging before it's released
<trulux> heya fellows
<Keybuk> the current stuff is iterally a 5s hack
<Kamion> infinity: we'll have to deal with it for breezy installs anyway :-/
<trulux> pitti: morning! found some bugs in my vsec packages, going to upload fixed ones now
<Kamion> although possibly hoary installs too, I don't recall exactly when it was introduced
<jdub> YAY Kamion!
<trulux> pitti: just a typo in postinst script and also needs to update modules.conf
<infinity> Kamion : Might have been hoary, one of the bugs I fixed was pretty old.
<Diziet> #!/usr/bin/env python> I think that's wrong.  That'll mean that when you upgrade the default python version, hct will stop working.  Or, to look at it another way, people won't be able to change to a release with a different default python version unless you fettle hct first.
<infinity> Using #!/usr/bin/env python means you need the (>> foo) (<< bar) dependencies.
<infinity> Using #!/usr/bin/python2.4 means you can just depend on python2.4
<infinity> The latter seems more desireable.
<Diziet> Quite so.
<infinity> (for ease of upgrades)
<Keybuk> right, but it looks like the python setup.py thing rewrites the #! line anyway
<Kamion> sigh, installs are annoyingly slow when archive is overloaded
<infinity> Everything is annoyingly slow when the archive is overloaded.
* infinity pats the local mirror again.
<Nafallo> Kamion: you're lucky. I'm still trying to fetch Packages, Sources and Releases :-P
<bddebian> No shix :-(
<Diziet> kamion: I'm considering having my firewall intercept my testbed's requests and divert them to the local mirror ...
<Kamion> Diziet: I think I might start routinely preseeding mirror/http/proxy or whatever it is
<\sh> did isa y 2 hours sleeping? don't trust me 
<Diziet> It doesn't seem to find a proxy or anything.
<Kamion> I think 'install mirror/http/proxy=http://wwwcache:3128/' would work
<Diziet> I should really RTFM, shouldn't I ? :-)
<Diziet> mirror/http/proxy=http://mirror.relativity.greenend.org.uk/ubuntu/ or some such.
<Kamion> oh, it's a deficiency in the installer that it doesn't ask for a proxy, really, I feel; it was one of the casualties of the "as few questions as possible" thing
<Kamion> Diziet: if that's actually a mirror rather than an HTTP proxy, you'd have to resort to different tricks
<Diziet> It could try to discover one by speculating in the dns.
<infinity> Does it kick back out and ask for a proxy if the main mirror times out?
<Kamion> oh, now, that's tempting
<Diziet> Oh, how annoying.
<Kamion> infinity: no
<infinity> Yeah, that's a deficiency, then.
<infinity> Few questions good, if we fall back.
<Kamion> if the main mirror times out, we assume you're non-networked and leave you alone
<Kamion> but that may not be an entirely accurate assumption
<Diziet> Often not, if your network admin is at all paranoid.
<Kamion> and besides, not everyone denies non-proxied requests - for some people they're just slower or, worse, more expensive
<infinity> That wouldn't be correct at any university campus I've been on in the last 5 years.
<Kamion> (c.f. cam.ac.uk international traffic charging)
<Kamion> ogra: edubuntu/powerpc/workstation pass
<Kamion> I do like the Edubuntu icon theme and font. Pleasingly different.
<Keybuk> I like the edubuntu logo, it's clever
<Keybuk> me! oh, me! missss! pick me! me! me! ohhhh miss!
<\sh> Kamion: didn't you want sleep?
<\sh> +to 
<Kamion> \sh: I had a couple of hours
<dieman> crazy
<dieman> i know tds.net has way more hw than i do
<\sh> Kamion: good to hear
<dieman> and their mirror box is only saying its doing 341mbps
<dieman> im doing ~300mbps
* infinity sobs quietly in the corner as he watches an 18 gig ccache get blown away.
<dieman> and im on crap for hardware.
<Kinnison> infinity: yeesh that's big
<infinity> Kinnison : The ccache on the buildds is ~20 gigs per machine.
<bddebian> OK, time to open up the Dapper repos? ;-P
* bddebian ducks
<infinity> Royal's cache corrupted horribly at some point and ccache segvs if you look at it sideways.
<infinity> So, away it goes.
<\sh> Rest In Peace
<infinity> The really sad thing is that royal's been out of rotation for weeks, and I've only now found the time to debug it -- which took about 5 minutes.
<infinity> Oh well.  The last few weeks were easy on the buildds, I don't think anyone even noticed we were missing one. :)
<Kamion> dieman: my wife is wondering how many sides you've got
<Kamion> "he might be a d10 or a d20 ... oh"
<Kinnison> bddebian: Tuesday
<infinity> Kamion : dPi, I'd assume from his domain.
<Kamion> cute, fractal
<infinity> I'm not sure how you can have Pi sides, but whatever. :)
<Kinnison> infinity: a very very spethul die
<bddebian> heh
<Kinnison> bddebian: in all seriousness, dapper won't be open until tuesday or so, sorry
* Kinnison has incredibly large amounts of stuff to do for launchpad by then :-)
<bddebian> Kinnison: I was only kidding.  I actually need to take a little time off to do my RL job anyway ;-)
<dieman> heh
<Kamion> Kinnison: any germinate stuff I can do for you? I have some spare time
<Kamion> for once
<Kinnison> Kamion: germinate ain't going in for now
<Kinnison> Kamion: more useful would be for you to write a raw-installer processor
<Kamion> how's main being determined?
<Kinnison> Kamion: germinate + script-run-on-ftpmaster
<Kamion> manual check?
<Kinnison> aye
<Kamion> ok, good
<Kamion> raw-installer> hmm. most of it's easy enough, the mildly awkward bit is cleaning up the old images
<Kinnison> Kamion: so yeah, a raw-installer installer, and working on getting the CD building utterly automated would be nice
<Kamion> we can talk about this at UBZ, but I'd really like to start off dapper with CD building still happening the way it does now
<Kinnison> okay that's fine
<Kinnison> but the installer stuff seriously needs doing
<Kinnison> and I simply don't have time right now
<Kamion> this is going to be our enterprise release, and CD-build work hasn't even been properly specced yet - we need to get CDs out early in the dapper cycle or it won't weork
<bddebian> Maybe I should shoot for main rights during Dapper.  Wouldn't that scare some people :-)
<Kamion> Kinnison: how does your morgue-equivalent work?
<Kinnison> Kamion: If it made it far enough to get into the archive, it's in the librarian until it's explicitly discarded
<\sh> woa...now I see first, that infinity had the last upload for breezy...
<Kamion> when should unpacked installer tarballs be discarded?
<Kamion> oh, only manually, you mean?
<infinity> Hrm, so I did.
<Kinnison> Kamion: not sure what we're doing about installer tarballs currently
<Kinnison> Kamion: there's nowhere in the db for them to go
<Kamion> that makes it hard to do raw-installer processing, I'd've thought ;)
* Kinnison will work something out, but not until I've finished the rest of pages 7, 8 and 9
<Kinnison> Kamion: basically assume you're given the archive root, the tarfile path, the distrorelease name, and go from there
<Kinnison> Kamion: that way I can invoke you when it's time to be installed
<Kamion> Kinnison: righto, I'll experiment - Friday or Monday, not sure what's on my plate tomorrow yet
<\sh> time to get up from my bed, having a shower and going out for dinner
<Kinnison> Kamion: okay
<Kamion> Kinnison: ok to write just a function that does it, or something, and leave you to work out where to put it in launchpad?
<bddebian> \sh: Have a beer on me ;-)
<Kinnison> Kamion: Either a shell script, or a nice self-contained python module is best
<Kinnison> Kamion: I'm happy to put either into launchpad as needed
<\sh> bddebian: i think i need some food first
<Kamion> Kinnison: do you have a dpkg version comparison routine in lp already?
<Kinnison> Kamion: yes
<Kinnison> Kamion: we have the one from sourcerer
<Kamion> what does it look like to the caller?
<Kamion> (I need it to do purging of older images)
<Travis_Watkins_> hrm, no separator between gnome-app-install and the rest of the menu :/
<Kinnison> You'll be given a callable which when you pass it a string will give you back an object you can use standard python comparators with
<dholbach> re
<Kinnison> Kamion: will that do?
<Kamion> Kinnison: so I can pass in all the versions found in that directory, get a list of objects, and sort
<Kamion> that'll do fine
<Kinnison> okay sure, we can make the contract list->list
<Amaranth> ack, oo2 menu entries are using oo1 icons
<Kinnison> In fact, if you're gonna be like that, you can do something like: string_version_list.sort(key=DebianVersionType)
<Kinnison> Kamion: whatever contract you decide on, we can do, or I can refactor your code afterwards
<Kamion> ok - I mean, the versions are such that plain sort will basically work anyway, but I'd rather be correct
* Kinnison nods
<Kinnison> We'll work something out
* Kinnison gets on with NascentUpload.verify_deb_timestamps
<Kamion> note that the last stage of d-i byhand processing is lisa'ing the .changes into the archive
<Kamion> I trust you can take care of that bit
<Kinnison> Remember that launchpad won't have byhand
<Kamion> yes, I know
<Kinnison> raw-installer is just a custom upload format :-)
<Kamion> but I mean of the procedure we currently follow that I'll be converting
<Kamion> I know, I (co-)invented raw-installer ;-)
<Kinnison> so yes, your stuff will be invoked at the point that the equivalent of lisa'ing in the .changes would take place
<Kamion> (for the purposes of lp later)
<Kamion> all right, fine
<Kinnison> thanks dude
<Kinnison> sorry if I'm being obtuse or unclear
<Kamion> not at all
<Kamion> I'm on two hours sleep, I'm far more likely to suffer from that
<Kinnison> dude, go rest
* Kinnison got 6 hours at least
<Kamion> can't sleep, clowns will eat me
<infinity> Kinnison : Does launchpad have a way for us to add translation tarballs to a .changes in a binary upload and have them automagically imported (or, at least, stored somewhere for later import)?
<the--dud> haha
<Kinnison> infinity: We'll have a form for that yes
<Kinnison> infinity: to get rid of the evil pkgstriptranslations bollocks we currently have
<Kinnison> infinity: basically get them directly imported into rosetta :-)
<infinity> Kinnison : Okay.  We'll need it pretty much at dapper open, unless we want to give pitti http access to the buildds to pull the tarballs by hand as we do now.
<Kinnison> infinity: i'll sic Carlos on it tomorrow :-)
<infinity> Kinnison : I assume pkgstriptranslations will stay, it'll just drop the tarball in dpkg-distaddfile, no?
<Kinnison> aye
<Kinnison> sorry, that, yes
<infinity> The importing part is less important than the uploading part for Tuesday, I assume.
<infinity> But the tarballs need to get off the buildds SOMEHOW, and if they're locked down, the only way is through .changes.
<Kinnison> indeedy
<infinity> Alright.  Just wanted to make sure you were still on that.  I'll leave you the heck alone, then. :)
<Kinnison> thanks
<infinity> And I'll remind pitti that the very first thing we need in dapper is a new pkgstriptranslations upload that switches to using dpkg-distaddfile.
<pitti> infinity: I should prepare and test this a bit before it becomes urgent
<infinity> Easy enough to make it work.
<infinity> Kinnison will have to give you the magic section and priority, though.
<Kinnison> pick one and tell me
<infinity> Cause that's how it will be keyed, I assume.
<Kinnison> the magic section is raw-installer for d-i
<Kinnison> how about raw-translations
<infinity> What's d-i using?
<infinity> Kay.  And you don't care about priority, then?
<Kamion> I originally suggested raw-* as a general "weird shit" namespacew
<Kamion> so raw-translations sounds good
<infinity> Yeah, that sounds fair to me.
<Kinnison> infinity: priority should be a single hyphen
<Kinnison> infinity: as per the installer
<infinity> Check.
<infinity> pitti : Got that?
<Kinnison> infinity: MD5SUM SIZE raw-translations - some_grungy_name.tar.gz
<pitti> Kinnison, infinity: noted in my TODO
<infinity> Don't need md5sum and size, dpkg-distaddfile does that.
<Kinnison> infinity: aye
<pitti> nice to see that cleaned up finally
<Kinnison> infinity: I'm just saying what I expect to see in the Files: section
<infinity> pitti : dpkg-distaddfile foo.tar.gz raw-translations -
<infinity> Kinnison : Right.
<carlos> Kinnison hmm so we will get direct upload into Rosetta next Tuesday?
<Kinnison> carlos: that's the aim
<infinity> pitti : And keep the current tarball naming scheme, as the archive will blow up if you revert to having several with the same name. :)
<carlos> cool
<Amaranth> the forums don't allow access to -devel anymore?
<MasterC> hi
<mdke> elmo, Znarl, do you have an ETA for the help.ubuntu.com request?
<Znarl> mdke : It's urgent?
<Kamion> ogra: edubuntu/powerpc/server pass
<mdz> Kamion: I'm getting a fair amount of mail from people who can't find the DVD images
<mdke> Znarl, fairly
<Kamion> mdz: yeah, I'm going to stick a link in, I've just been too busy with Edubuntu testing
<mdz> unfortunately, we didn't include a link to /download/ in the announcement
<Kamion> (and not having an afternoon off as a result)
<mdz> so the only place people look is releases
<Znarl> mdke : ok, done.
<mdke> Znarl, awesome
<mdke> Znarl, ugh, hang on, is it pointing at the ip for that server, or something else?
<Znarl> The IP.
<mdke> hmm
<mdke> ok there must be something wrong our side then
<Znarl> Check you don't have a cached DNS entry.  
<mdz> Kamion: where is ogra?
<mdke> Znarl, don't think so, i'll play with apache. it should be pointing it at another virtual server, but it is pointing it at doc.ubuntu.com right now
<Znarl> ok, let me know if you need anything else.
<mdke> Znarl, thanks
<pvanhoof> We have an urgent need for Ubuntu cd's for professional/sales purposes in Belgium (so more urgent than the shipit.ubuntu.org can deliver it)
<pvanhoof> who should be contact?
<pvanhoof> s/be/we
<pvanhoof> We have also a few questions about branding possibilities
<pvanhoof> And like to closely work with Canonical/Ubuntu on a few topics
<pvanhoof> +together
<mdke> pvanhoof, you should contact your locoteam probably, they can help with expedited shipments of cd's if you can justify it
<janimo> daniels, ping
<pvanhoof> ok
<pvanhoof> locoteam, do they have a phone, address, url?
<infinity> janimo : It's 3am in Australia. :)
<mdke> pvanhoof, belgium does not have one afaics, you can try the french one (ubuntu-fr.org)
<janimo> infinity, ok
<pvanhoof> ok
<ompaul> pvanhoof, so pay for them the artwork is there and copy shops can do the job :)
<janimo> X would not install here
<janimo> something chaged in the last X uploads, re blacklisting of some ati cards and the noaccel option
<pvanhoof> ompaul, yes well.. we could do the artwork/our logo for the branding stuff. That wouldn't be a problem. We can even compile the liveCD itself. It's maintly the pressing of cd's and the approval to do this etcetera
<mdke> Znarl, it is not a redirect or anything right? It is an A record?
<Znarl> help.ubuntu.com.        1800    IN      A       65.19.178.132
<TMM> hey, just out of curiousity, I just upgraded a hoary box to breezy with the CD, and then added breezy apt mirrors, and now it's upgrading a whole bunch of stuff from main... are the cd's outdated already?
* mvo goes to play hockey
<mdke> Znarl, ok thanks, sorry to bother
<Znarl> No problem.
<Nafallo> TMM: no, but not everything from main is on the cd...
<ompaul> pvanhoof, there _should_ be no problem with that, just drop a note to canonical if you feel uneasy, however the back of the printed copy says: You are legally entitled and encouraged to copy, share and redistribute this Cd for yourself and your friends. Share the spirit of Ubuntu.
<pvanhoof> of course
<pvanhoof> but .. we'd like to change for example the default background of the default theme
<pvanhoof> stuff like that
<TMM> Nafallo, ah, that explains it then, I thought it was, never checked, thanks a bundle!
<pvanhoof> and change the printed image on the cds etcetera
<TMM> Nafallo, I have at leat 20 hoary boxes to upgrade this week, so it's nice to know ;)
<pvanhoof> well, it'd be nice if we could do that
<pvanhoof> and also get assistance with pressing the cd's. Perhaps letting canonical press 'em
<Nafallo> TMM: :-)
<Nafallo> TMM: the dvd should have all of main if that's an option...
<pvanhoof> Our story is that we will be telling our potential customers about Linux on the desktop
<Nafallo> or rather all of ubuntu-supported :-)
<pvanhoof> and we'd like to give 'em Ubuntu LiveCD's (and install cd's) as gadget
<TMM> Nafallo, I've got a DVD burner, does shipit also ship DVD's these days?
<Nafallo> nope
<Nafallo> but cdimage.ubuntu.com does.
<TMM> Nafallo, is the DVD image ready yet? might as well download it now, save me a lot of downloading on crap connections
<TMM> whoops, linky :) thanks
<ogra> mdz, was buying a new dvd writer
<ogra> Kamion, thanks :)
<TMM> Nafallo, my evangelism for normal users has gotten a little bit out of hand :)
<Nafallo> http://cdimage.ubuntu.com/releases/5.10/release/
<pvanhoof> Anyway, I informed our Sales dude about ubuntu-fr.org
<Nafallo> :-)
<TMM> Nafallo, is there a mirror? it's not loading...
<Nafallo> dunno. there should be a list of them somewhere...
<TMM> Nafallo, I'll just dig around a bit then, thanks a bundle!
<zyga> hmm
<zyga> since when do we mount /lib/modues/`uname -r`/volatile over tmpfs
<Nafallo> TMM: https://wiki.ubuntu.com/Archive
<Nafallo> looks empty :-P
<infinity> zyga : Since we devised volatile?
<zyga> good answer, my question was bad
<zyga> why do we do it? :)
<infinity> To avoid shipping GPL-incompatible modules linked with the kernel.
<infinity> They get linked on boot instead.
<infinity> See /sbin/lrm-manager
<zyga> :-)
<Kamion> ogra: you will have to do all of the DVD testing
<Kamion> I can't give it any more time
<zyga> I see GPL 3 explicitly prohibiting this ;-))
<ogra> Kamion, thast why i bought a writer...
<Kamion> ogra: you definitely need to get more volunteers to help with testing before the next time we have to do this
<Kamion> this has been far too drawn-out and painful
<ogra> Kamion, or more HW, i simplyhave no amd64 and ppc around...
<infinity> More people is better anyway.
<Kamion> trust me, go for more people more importantly
<infinity> Different testers test differently sand find different bugs.
<infinity> s/sand/and/
<ogra> ppc == GFs workplace, i'll trysh it today :/
<ogra> Kamion, if i have to do the next release as one man show again, i'll give up on edubuntu... but i suspect we'll attract soem people soon
<ogra> Kamion, its was never planned that you do this much testing for me, i'd have expected some help from others here too
<bddebian> ogra: :'-(
<Amaranth> hey jdub you scare the shit out of the KDE guys, way to go ;)
<bddebian> hehe
<TMM> Nafallo, thanks :)
<TMM> all ubuntu.com stuff is rather sluggish, I wonder how THAT can be? :)
<sivang> Happy release day everyone!!!
<infinity> mdz : Was it you that just REJECTED all the pending universe binary builds?
<Riddell> Amaranth: how does he do that?
<mdz> infinity: nope
<Amaranth> Riddell: http://www.realistanew.com/random/kde-boston2005.txt
<infinity> Weird.  The buildds just got a mess of REJECTED for the last few universe uploads that were made at the 0-hour yesterday.
<elmo> because I just rejected them?
<infinity> Ah.
<Riddell> Amaranth: who put that up?
<Amaranth> Riddell: well, that's my website
<Amaranth> Riddell: I
<Amaranth> err, I'd rather not say where i got it originally
<Riddell> Amaranth: where did you get it from?
* bddebian is innocent this time I SWEAR :-)
<infinity> elmo : I assumed you were letting binary builds trickle in for a bit, s'all.
<infinity> (for universe, that is, obviously not for main)
<elmo> infinity: dude, I did - for like t+12 hours 
<elmo> the REJECTs you just got were all for NEW stuff
<fabbione> elmo: thanks a lot for all your work! you ROCK!
* jbailey takes the happy drugs from Fabio
<bddebian> jbailey: ;-)
<dholbach> jbailey: i like him that way... fabbione: you ROCK too :)
<infinity> elmo : Yeah, I know it was sitting in NEW.  No big deal.
* maswan hopes that the pressure on the DC uplink will get happier during the night
<infinity> (not like I much care, was more just curious)
<sabdfl> maswan: you are a superstar for your mirror
<maswan> about 10TB so far, it seems. some of that (probably 1-2TB) is not ubuntu though, but the rest. :)
<maswan> lots of breezy goodness
* pitti gives up with trying to use multisync to sync evo between laptop and desktop *grumpf*
* Nafallo still thinks we should find more CC-mirrors ;-)
<Nafallo> or atleast make all of EU's CC. go to se. till we find some :-P
<rob^^^> hrmm
<rob^^^> I did a dist-upgrade -y and it still prompted me to restart services :(
<ogra> Kamion, was that a pass for all three installs on ppc ?
<maswan> sabdfl: and thanks, we do our best. I think the netadmins here will be happy for the stresstest we gave them too. :)
<sabdfl> i dont even want to think what your internal switches must look like
<sabdfl> black magic
<fabbione> elmo: is http on ports.u.c down??
<fabbione> elmo: i get connection timeout 
<fabbione> or is it just busy to death?
<fabbione> Znarl: ^^
<\sh> I'll think I'll ask our dc managers if it's possible to setup an ubuntu mirror at ISH...
<HiddenWolf_> Damnit, 5.10 broke my laptop
<blueyed> Thanks! :)
<fabbione> HiddenWolf_: no. your laptop broke 5.10
<HiddenWolf_> fabbione, I had a laptop that could connect over ppp to the internet on 5.04, and now it won't. :P
<fabbione> HiddenWolf_: that's becasue 5.10 is too 31337 for your lappy
<fabbione> ;)
<\sh> ubuntu just works (TM)
<HiddenWolf_> fabbione, and pon gives that poor laptop an ipv6 IP on a ipv4 network.
<Znarl> fabbione : It's just terribly slow right now.
<fabbione> HiddenWolf_: nononono.. the IPv6 address you see it's probably a fe80:: something. That's normal
<fabbione> Znarl: ok thanks! i am much more happy to know that's slow :)
<infinity> elmo : Did you catch Kamion's patch to turn on breezy-security in backscroll?
<fabbione> HiddenWolf_: and interfaces can share more than just one protocol
<infinity> elmo : Ahh, obviously you got it fixed, since wanna-build's now happy.  Nevermind.
<HiddenWolf_> fabbione, running pppoeconf, ok > pon ok, > ping google not ok.
<dredg> i can assure you that google is up :)
<infinity> HiddenWolf_ : pppoeconf may not always upgrade terribly cleanly.  Try removing all the pppoe-related stuff from /etc/network/interfaces, then pppoeconf.
<HiddenWolf_> dredg, yup, so my eth0 is not. :)
<fabbione> HiddenWolf_: check the routing and see if you can actually resolve names
<elmo> fabbione: it's busy
<fabbione> elmo: yup.. fine with that :))
<maswan> fabbione: just busy, I've seen a few similar reports on security.u.c too.
<juliux> ogra, ping
<ogra> juliux, see /msg :)
<HiddenWolf_> infinity, I'll try that.
* HiddenWolf_ lugs laptop to the other room.
<elmo> redirecting s.u.c to a less busy host
<elmo> I'll do the same for ports in a sec
<spayne> what is up with gb.archive.ubuntu.com?
<spayne> DoS?
<elmo> spayne: we released something called breezy today - maybe you heard of it?
<speel> spayne, ubuntu = very popular + servers = overloaded
<spayne> elmo: somehow - i must have :)
<spayne> elmo: just wondering if there was anything particular up or just the huge load?
<spayne> elmo: since i made a 1 in 16000 contribution, i know about it :)
<speel> i hope the servers come back to life soon lol
* bddebian hugs elmo, lamont, infinity, ogra, \sh, ajmitch and the rest of the crowd for putting up with him through Breezy.. :)
<\sh> bddebian: we love u, too :)
<bddebian> :-)
<\sh> JaneW: thx for the pictures of the edubuntu cake...now I'm hungry again
<Nafallo> cake?
<\sh> http://www.flickr.com/photos/13916877@N00/
<Nafallo> I want one of those! :-(
<Nafallo> :-)
<HiddenWolf> fabbione: I got rpppoe to connect, but it doesn't come up on boot.
<HiddenWolf> infinity: any idea. ^^
<Lathiat> haha thast awesome
<Lathiat> HiddenWolf: did you re-run pppoeconf?
<Lathiat> and make sure you cleared interfaces first?
<HiddenWolf> Lathiat: cleared as in 'erased' ?
<Lathiat> HiddenWolf: noooo
<Lathiat> hi	as in, delete dthe ppp related stuff out of it
<Lathiat> gah sslag
<HiddenWolf> Lathiat: everything about ppp and dsl-provider?
<Lathiat> HiddenWolf: yes
<bddebian> Wow, not to be a pig but Jane is an attractive woman. :-)
* Lathiat laughs
<Lathiat> i think bddebian wants some edubuntu cake ;p
<jbailey> bddebian: "Not to be a pig, but I"m going to be anyway..." sort of thing? =)
<bddebian> jbailey: Uhm, yeah apparently :-)
<Lathiat> http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005-10--13,raw,traffic-kbit
<Lathiat> wow, still running full ball
<Lathiat> i wonder how long till it starts to fall off
<Lathiat> and i wonder what canonicals mirrors are doing
<jbailey> bddebian: Just so we're clear on the concept ;)
<hidde> Lathiat I can run pppoeconf, but I have to manually run pon anyway
<maswan> Lathiat: even worse, but with a limit of 750Mbit/s.
<bddebian> Bah, she's away anyway.. ;-P
<Lathiat> maswan: hrm?
<Kamion> ogra: hmm
<ogra> Kamion, did you run all three tests for ppc already ? 
<Kamion> ogra: so, powerpc/edubuntu/default fails at "Build LTSP chroot", because there's no 'linux' package on powerpc
<ogra> f*ck
<ogra> Kamion, why is that ? dont we have a kernel on ppc ?
<maswan> Lathiat: the uk ones only have 750Mbit/s network capacity. and I think they have worse load than we have.
<HiddenWolf> Lathiat: any idea?
<Lathiat> maswan: oh, right
<Lathiat> HiddenWolf: what have you done?
<Lathiat> HiddenWolf: removed it all and reran pppoeconf?
<HiddenWolf> Lathiat: yup
<Lathiat> if that didnt work, please pastebin me your interfaces file
<Kamion> ogra: hardly :-P
<HiddenWolf> Lathiat: one sec
<Kamion> ogra: linux-powerpc and linux-powerpc64 are not compatible; unlike other architectures, there's no generic kernel that fits both
<Znarl> We're still stuck on 750Megabits.
<ogra> Kamion, damned...
<ogra> mdz, ping ? 
* Lathiat wonders what se.releases woudl be pushing if it had the capacity
<Kamion> so, I can complete the rest of the install fine, I think
<ogra> Kamion, does it throw you back to the menu or does it just fail and go on ? 
<Kamion> ogra: it throws me back to the menu; I have to skip the step and carry on
<ogra> hmm, ok
<Kamion> I assume nobody's ever tested powerpc before
<ogra> i wonder if i can release such broken stuff...
<Lathiat> i suppose mac minis could make ok thin clients or something :)
<ogra> Kamion, you did iirc around preview, but there ltsp-client-builder was nonexistent
* \sh is thinking about a school which has money for having a complete IT infrastructure with macs...
<ogra> \sh, in the US macs are popular
<bddebian> Nahhh :-)
<\sh> ogra: but US != the World
<Lathiat> \sh: but US  part of the world
<ogra> \sh, k12ltsp is among ourtarget audience
<Lathiat> err =
<bddebian> Of course Mac == Intel now anyway right? :-)
<Lathiat> altho i tend to think of it as its own world sometimes :)
<ogra> bddebian, that doesnt save my release
<\sh> and well...the amarok 1.3.3 crashes are annoying now
<maswan> Lathiat: if we had enough resources to totally satisfy demand? anywhere from 4-10Gbit/s, I guess.
<Lathiat> \sh: yes, i downgraded
<bddebian> ogra: I know sorry.  I wish I still had a PowerPC box so I could help :-(
<Lathiat> \sh: thank god we didnt do that
<Lathiat> maswan: yeh thats what i was thinking
<ogra> bddebian, nothing you can help with... the final iso is broken
<HiddenWolf> Lathiat, you need /etc/interfaces/network ?
<\sh> Lathiat: the best decision ever..but cost a lot 
<Lathiat> maswan: bets on how long till it starts dropping noticably? :) was 24h or so last time no?
<Lathiat> HiddenWolf: yes
<Lathiat> \sh: cost what?
<Lathiat> not driving me insane? :)
<\sh> Lathiat: my braincells
<maswan> Lathiat: my guess, in 2-6 hours, since by then it will be night.
<mdz> ogra: yes?
<ogra> mdz, any hint for me what i can do now ?
<Lathiat> maswan: mm but this is a worldwide thing after all
<mdz> ogra: what have you done so far?
<Nafallo> maswan: ... and other people wake up... ;-)
<ogra> mdz, ppc has no package called linux o_O i didnt know that
<maswan> Lathiat: well, still, so far it has always dropped during the european night and then picked up again.
<Lathiat> maswan: ah ok
<ogra> mdz, all isos are tested, pc default install fails
<Kamion> ogra: well, it's a bug in ltsp
<Lathiat> well, i should goto bed its 2:50am and i have to leave for uni at 8 :\
<maswan> Lathiat: for ubuntu, debian, and others.
<Kamion> ogra: *powerpc*, not pc :)
* Lathiat nods at maswan
<ogra> Kamion, err, yes sorry
<ogra> mdz, what Kamion said
<mdz> ogra: ok, so powerpc is a bust
<mdz> ogra: i386 and amd64 are all pass?
<ogra> mdz, workstation install is fine... but thats not what you get by default
<ogra> mdz, yup
<Kamion> ogra: you have basically two choices: document the bug and live with the ltsp chroot being broken, or don't release the image
<mdz> ok, then we can release with i386 and amd64
<Kamion> I'm not sure whether the first is an option
<ogra> Kamion, thats what i wanted to hear from mdz :)
<Kamion> mdz: I've tested amd64 and it's fine; ogra (and others, I think) tested i386
<ogra> yup
<Kamion> powerpc workstation and server are fine but the default is broken
<mdz> let's do it, then
<HiddenWolf> Lathiat, http://paste.ubuntulinux.nl/3042
<mdz> we also need to announce ubuntu-server
<ogra> mdz, wipe ppc or note it in the install notes ?
<Kamion> ogra: amd64 and i386 only
<ogra> ok
<Kamion> mdz: I've not had time to do further ubuntu-server testing
<ogra> can we keep the ppc iso around anywhere ? 
<mdz> Kamion: you have new images with the corrected text?
<Kamion> mdz: yes
<Lathiat> HiddenWolf: wow thats fucked up broken :(
<mdz> Kamion: if so, I'll sanity-check them
<Lathiat> hid	sigh
<Kamion> mdz: ubuntu-server/amd64 passed my testing earlier today
<mdz> Kamion: I tested the previous images x3 and they were 100%
<Kamion> I have not tested i386 or powerpc
<Lathiat> HiddenWolf: i'll try look at fixing pppoeconf for -updates
<mdz> i386, powerpc and amd64
<mdz> yesterday
<HiddenWolf> Lathiat, the s on the first line is a typo, btw
<Lathiat> HiddenWolf: yeh, 
<ogra> mdz, i have the DVD x86 here now, how much time do i have left for that and amd64 DVD (still need to download that one) ?
<Lathiat> HiddenWolf: well for now, move that pre-up above auto eth0
<Kamion> ogra: I can keep it somewhere on cdimage, I suppose
<Kamion> ogra: DVDs can be released separately later
<mdz> ugh, rsync servers are busy
<ogra> Kamion, great, in case someone wants it i can point him/her here with a hint
<Nafallo> mdz: everything is buzy :-).
<mdz> ogra: please don't
<ogra> Kamion, yes, but i wanted to know when )
<mdz> ogra: don't publish anything to anyone until it has been tested
<Nafallo> except the buildds ;-)
<\sh> ogra: as I said, downloading the amd64/i386 dvd iso..and I think tomorrow morning in the office, I'll burn at least i386 and test
<ogra> mdz, ok, so we'll wipe it completely, fine with me ...
<HiddenWolf> Lathiat, so it's not me then? :)
<ogra> \sh, concentrate on amd64, i already have x86 here
<mdz> ogra: just wait until it can be tested
<Kamion> ogra: tomorrow
<\sh> ogra: amd64 will be a pain...but I'll ask henning 
<Kamion> >= tomorrow, anyway
<mdz> ogra: assuming you're talking about the DVD.  the powerpc stuff should be taken down
<Lathiat> HiddenWolf: ok so, try moving that pre-up above the auto eth0 line
<ogra> mdz, ah, you talk about the DVD
<Lathiat> HiddenWolf: let me know if that works
<ogra> mdz, sorry, i'm slow
<\sh> ogra: he owes me some favours
<Lathiat> hid	that might work
<ogra> \sh, just bring it with you tomorrow... i'll pay the beer then ;)
<ogra> \sh, i'll wipe my laptop for the test :/
<Lathiat> HiddenWolf: can you mail lathiat at ubuntu.com if that works, im going to bed
<\sh> ogra: k...no problem 
<\sh> ogra: but the beer is mine
<\sh> ogra: I'll pay dude
<ogra> ok ok
<\sh> ogra: u'll pay the food ,-)
<HiddenWolf> Lathiat,  let me see what a reboot does
<ogra> \sh, fine as well
<ogra> :)
<HiddenWolf> Lathiat, a minute or 2
<Lathiat> HiddenWolf: eh,, ok
<ogra> Kamion, so can you publish ? i'll edit the announcement accordingly
<\sh> ogra: and your shirt just came out of the washing machine :) so it's fresh when I return it to you :)
<ogra> hehe
<Kamion> ogra: in progress
<ogra> yay
<Lathiat> ouch, a.u.c really is getting eaten alive, 1.6K/s :\
<ivoks> hi guys
<maswan> Lathiat: be happy that you didn't get a timeout
<ivoks> who's admin of lists.ubuntu.com?
<Lathiat> maswan: heh
<Lathiat> 480B/s, woo. :)
<maswan> btw, elmo and Znarl: feel free to yank the other DC IP from releases.u.c, we seem to be doing fine here.
<Kamion> meh, I hate that stupid publish-release bug
* Kamion pushes again
<hidde> Lathiat: works nicely
<maswan> Kamion: oh, we're still trying to get ubuntu-server. I think we have kubunty since 4 hours or so though.
<Kamion> maswan: eek!
<Lathiat> hidde: ah sweet thanks
<Lathiat> hidde: can you mail me so i dont forget
<hidde> Lathiat: i will when I'm back at my own pc. :)
<maswan> Kamion: Yeah, we've been syncing all day. A good moment, we might get as much as 40k/s, but 20k/s is closer to typical rate.
<Kamion> ouch
* maswan does the ls -l; sleep 100 trick to see how much it grows
<Kamion> I'd hoped the pre-publishing would sort out most of it, but evidently it just wasn't nearly enough time
<maswan> it was fine for ubuntu, but by the time we were half-way through kubuntu, it slowed to a crawl.
<maswan> well, almost done with kubuntu (only ppc left)
<Kamion> ogra: syncing out to mirrors now
<Kamion> (just symlink changes, metafiles, and removals)
<ogra> yippie
* ogra feels a ton lighter now
<HiddenWolf_> Oh my
<Kamion> powerpc effectively disappeared, although the daily build is still there
<maswan> Kamion: average over 100 seconds: 26214 bytes/s
* \sh hugs ogra now and congrats him a second time today...
<HiddenWolf_> Oh no. :S
* ogra can take this now :) thanks \sh :-D
<pitti> congrats ogra!
<ogra> pitti, thanks :)
<HiddenWolf_> Oh no^2 - I sent this guy from Tectonic.co.za an email, and he published it!
<tankenmate> anyone had any problems with the stock amd64 install kernel? I'm have weird oops'es in memremap(). I've run memtest86 for 6 hours, and only one random glitch, but then kernel crashes everytime, a weird heisen / bohr bug combination...
<Kamion> ogra: you'll have to wait until releases.u.c gets it throughout, though, and as above the Swedish mirror is behind
<Kamion> maswan: if there's any way you could do a special catchup on edubuntu/ (should be quick), we'd all be very appreciative
<ogra> Kamion, yup.. i'll wait 
<maswan> Kamion: I'll try
<Kamion> thanks
<tankenmate> no kernel hackers about?
<\sh> Kamion: do u have a topo map of official ubuntu mirrors handy?
<Kamion> \sh: no
<Nafallo> trulux: did you grab my new-built ubuntu1 package? :-)
<trulux> heya Nafallo !
<trulux> Nafallo: going to do that right now
<trulux> :)
<trulux> good job
<Nafallo> trulux: morning. no problem :-)
<maswan> Kamion: probably done now, ogra should probably check though.
<HiddenWolf_> I'm so embarrased.
<ogra> maswan, will do, thanks
<\sh> Kamion: k
<tankenmate> anyone done a debian -> ubuntu cross dist-update? i don't have a working ubuntu machine (only debian), and i need to make a custom installer.
<\sh> let's try to setup a mirror tomorrow somehow in our DC to serve at least our cable customers
<\sh> and ask henning to upgrade mvo's mta config
<ogra> \sh, giggle ... giving him 5Mbit for free ?
<\sh> ogra: that's the plan...but we have as well some 10mbit configs handy...and we need some testers ;)
<HiddenWolf_> Kamion, mdz sabdfl, sorry. :$
<bddebian> HiddenWolf_: ??
<ivoks> so..
<ivoks> we have nasty bug
<ivoks> internet is to narrow for ubuntu :)
<bddebian> ivoks: hehe
<HiddenWolf_> bddebian, I sent an email to a reporter for tectonic.co.za, and he published it, fairly unedited. :P
<bddebian> HiddenWolf_: A "good" one I hope :-)
<trulux> Nafallo: done!
<\sh> HiddenWolf_: link? ,-)
<HiddenWolf_> Yes, but I'm suddenly a "contributer ... wealth of information and help .. " etc
<HiddenWolf_> \sh, http://www.tectonic.co.za/
<HiddenWolf_> 3rd article
<HiddenWolf_> 3 articles on ubuntu/edubuntu/breezy there
<mdz> HiddenWolf_: I don't see anything wrong with the information you provided
<\sh> HiddenWolf_: tell them Breezy is named Ubuntu 5.10 and not 10.5
<HiddenWolf_> mdz, wasn't supposed to go online in raw version. I sent the guy a mail with what I thought why ubuntu rocked so he could write a good review. He made an article out of it
<HiddenWolf_> \sh, I did, twice. :P
<ivoks> mdz: happy bday (sorry, i'm late)
<mdz> ivoks: thanks ;-)
<jbailey> It just makes us cooler than RH9 =)
<HiddenWolf_> \sh, Hi Jason,
<HiddenWolf_> We talked earlier, and I promised to send you an email about the
<HiddenWolf_> upcoming Ubuntu 5.10 release.
<HiddenWolf_> Just to be marginally smarter than the average review, the development
<HiddenWolf_> nicknames are just that, and the name is 5.10 from release onward.
<HiddenWolf_> \sh, still he gets it wrong
<ogra> Kamion, somehow the preview image is still in the download dirs...
<trulux> Nafallo: got time to work together with me on some pakages?
<\sh> wow...
<\sh> http://www.tectonic.co.za/view.php?id=645
<\sh> "Although I'm not a big Wine user (there's very little in Windows that I use for which there isn't an equivalent open source app), other users have been impressed with the Wine support, which loads Windows apps much more reliably and without the usual large amounts of tweaking. You now can double-click on a Windows .exe file in the file manager and it just loads. "
<\sh> i didn't even know, that wine was working ,-) I tried to test, but my tax software never worked 
<ivoks> ah, it's wonderfull to be a part of ubuntu team
<crimsun> :-)
<trulux> Nafallo: http://www.debian-hardened.org/doku.php/ubuntu_hardened_todo
<trulux> is pitti around?
<\sh> elmo: don't worry about the syncs...I knew it was late :) but thx anyways for your great help :)
<kikidonk> congrats for breezy !
<andred> Hmm, is it just me, or does Firefox in Breezy not remember it's window position between launches?
<hamilton> why doesn't http://releases.ubuntu.com/breezy/ have links to the dvd torrents?
<ompaul> andred, I to not think it is just you
<andred> ompaul, Ok, good. I believe this behaviour started with Breezy, because in Hoary I'm pretty sure the position was remembered.
<ompaul>  same in xfce as gnome
<Kamion> ogra: it's not there on the master, so that means that the mirror is not completely synced yet
<Kamion> hamilton: yes, I know - I'll fix that at some point, I've just been run off my feet today and haven't had time yet
<Kamion> will sort it out tomorrow morning
<ogra> Kamion, http://releases.ubuntu.com/edubuntu/5.10/ isnt the master ? 
<maswan> ogra: want me to re-run the edubuntu part with --delete and hope it won't get anything else?
<maswan> ogra: no, that's just a mirror
<ogra> yup, that'd be nice
<maswan> ogra: the primary mirror[s] , but still mirrors
<ogra> i dont want to send the announcement with the preview in there :)
<maswan> ogra: ok, gone.
<Kamion> ogra: little is the master
<ogra> ah, yes
<Kinnison> Kamion: oh, you're still around
* Kinnison expected you to have gone to the carlton by now
<Kamion> about to leave, but yeah
<maswan> oo, .ubuntu-server-5.10-install-amd64.iso is up to 400 megs soon. soon the first iso there will be over here
* ogra oO(still a lot to learn)
<\sh> ogra: amd64 dvd iso ETA 11h
<ogra> \sh, thanks a lot :)
<\sh> jumping between 30 and 60k
<ogra> \sh, does that fit in your travelling plans ? 
<\sh> same applies for i386 dvd...
<ogra> no need for i386 ... i got it here
<\sh> ogra: hehe...sure :) I'll have to work tomorrow morning at least till 15 or 16h
<\sh> ogra: but I need it :) 
<ogra> heh, k
<\sh> ogra: or, anyways...I need to trash 47h extra hours
<\sh> ogra: so it can be that I'm even earlier at your place...
<ogra> fine with me
<\sh> and I have to talk to amu...to have something like "we don't include your ip in the monthly traffic calculation for provider servereyes.de"
<\sh> so i can set up some torrent trackers ;) 
<\sh> or even provide all the isos via http/ftp
<ogra> :)
<\sh> ogra: and include this to your release announcement ;) http://www.badgerbadgerbadger.com/
<mdz> Kamion: -server i386 successful, amd64 in stage 2, powerpc trying desperately to get a Packages file from us.archive
<Kamion> mdz: ok, I'll go out now and if it's all working when I get back I'll do a release
<Kamion> thanks for testing those
<mdz> Kamion: sounds good, enjoy the evening
<\sh> Kamion: have fun and relax :) 
<bddebian> Yeah Kamion, great work :-)
<nomed> i would just say you all great work :)
<nomed> cu
<seb128> moyogo: around?
<moyogo> seb128: yes
<seb128> moyogo: I'm sorry but I'm not competent about fonts and I don't know what to do about https://bugzilla.ubuntu.com/show_bug.cgi?id=17248
<seb128> I'm not even sure to understand the issue
<seb128> do you have some screenshoot of what's wrong and we can do to make it better?
<seb128> better you could do a spec on the wiki for that so it can be discussed at the next conf ... ?
<moyogo> seb128: yes, I realized it wasn't very clear
<moyogo> seb128: but the issue is mainly that pango has no support at all for GPOS and GSUB for latin/greek/cyrillic
<moyogo> seb128: the last patch (gzipped btw) simply allows pango to use them sometimes
<moyogo> seb128: it works with some fonts and not with others
<seb128> that's the same issue than the GNOME bug you pointed right?
<seb128> according to the comments there is some bug on it upstream
<mdz> ogra: congratulations and well done
<seb128> we could just wait for pango to fix that?
<moyogo> seb128: yes... there's a patch upstream too
<seb128> mdz: Hi, happy birthday :)
<dieman> heh
<dieman> nearly *all* the downloads are i386 live and install right now
<moyogo> seb128: the patch works right now, i just need to clean up the g_print calls, pango might just wait for the patch to be complete
<seb128> moyogo: let's wait for upstream to fix it so :p
<dieman> a ppc in there too
<mdz> seb128: thanks :-)
* mdz -> lunch
<Nafallo> dieman: no amd64? :-)
<moyogo> seb128: i'll try to push it upstream, but they might want the whole issue to be fixed, when the patch already fixes some of it
<dieman> Nafallo: yeah, some of that too
<dieman> Nafallo: most of it i386 though, just a smattering of ppc and amd64
<moyogo> seb128: with the patch I'm able to get diacritics at the right place on uppercase letters when the OpenType font defines it
<dieman> i wish we would get java and flash for amd64 soon here
<dieman> sun not doing 64 bit plugins for flash is isnane
<Nafallo> sun?
<moyogo> mdz: happy bday
<dieman> s/flash/java/
<Nafallo> dieman: well, we do have j2re1.4 in multiverse :-P
<seb128> moyogo: they do that because usually when people have a 90% working patch applied they don't keep working to clean the 10 uneeded % :p
<Nafallo> mdz: happy birthday btw! :-D
<ajmitch> morning all
<seb128> hi ajmitch
<Nafallo> morning ajmitch :-)
<moyogo> seb128: the 90% would be usefull for some languages and with half of the good OpenType fonts, the 10% remain persant I am commited to, since it is necessary for the other half of the very few fonts and IPA stuff
<moyogo> percent*
<moyogo> seb128: but behdad is on it too, so there's more hope
<moyogo> seb128: besides the bug is getting old, it's about time we fix it
<seb128> cool, you guys seem to be working on it, it'll probably be fixed before 6.04 so :)
<moyogo> definitely
<moyogo> you should look into graphite too, some languages will require it
<something_else> whats changed with hal in breezy?
<moyogo> i't be nice to have some silgraphite working for 6.04
<something_else> the real question is do some devices have to be registered with hal if not specified by breezy?
<diamond> lo folks
<bddebian> Hello diamond
<ajmitch> hi
<diamond> i have an issue with my laptop here, it keeps going to into suspend. when i bring it back, it suspends again about a minute later
<diamond> i'm only uptodate with the rc release, didn't want to touch things if debugging is required
<diamond> is this a known issue? (bugzilla hasn't shown up anything for me yet)
<something_else> this must be a bug - gnome-volume-manager in breezy thinks an external usb hard disk is not removable :|
<something_else> which is true to some extent ...
<mdke> something_else, best to check bugzilla for gnome or Ubuntu
<something_else> ok
<something_else> im no good at searching bugs
<\sh> good night gentlemen...and thanks for this wonderful release...
<Nafallo> night \sh :-)
<mdz> moyogo,Nafally: thank you
<bddebian> Oh, Happy B-Day and Release mdz :-)
<mdz> bddebian: happy bday from bddebian ;-)
<ajmitch> hello mdz, happy birthday :)
<bddebian> Did I say that already?
<Nafallo> hihi
<trulux> good night fellows
<bddebian> Gnight trulux
<ajmitch> night trulux 
<trulux> Nafallo: I hope to find pitti available tomorrow, I'll try to bring a working tarball of the new vsec stuff
<trulux> ajmitch: 'nite!
<Nafallo> trulux: I'm happy to build it on amd64 :-)
<dieman> babahaha, the EU is saying they might break the internet next month.
<Nafallo> where IS that info from? :-)
<mdz> ajmitch: thanks
<dieman> via slashdot, the guardian
<mdz> Kamion: ubuntu-server isos are gold
<dieman> "EU says internet could fall apart"
<dieman> its all about dns anyhow
<Nafallo> ah
<dooglus> hi.  is it a bug that "shadow"'s configure.in tries to make debian/Makefile when no debian/Makefile.in exists?
<dooglus> when I configure, I see "config.status: error: cannot find input file: debian/Makefile.in"
<ogra> night all
<bddebian> Gnight ogra, Congrats and Good Work! :-)
<ogra> thanks :)
<dooglus> I'm wondering whether to report it or not.
<Riddell> are the DVDs released?
<bddebian> Not last I knew
<bddebian> But I don't know shit ;-)
<Riddell> ok, that explains why I can't see them then 
<dooglus> there's going to be a DVD?  like "ubuntu the movie"?
<Nafallo> dooglus: yepp :-)
<Nafallo> dooglus: no, but live and install in one place ;-)
<bddebian> dooglus: :-)
<azeem> congrats for the release
<dooglus> are all bugs going to launchpad now, rather than bugzilla?
#ubuntu-devel 2005-10-19
<mwright1night> Hello, can someone please seed edubuntu 5.10
<mwright1night> The torrent has no seeds
<mwright1night> and direct download is 4.5k/s
<mwright1night> and a very inefficient way of distributing
<Keybuk> jbailey: ping?
<mwright1night> could someone please seed edubuntu
<Kinnison> ciao all
<Kamion> Riddell: yes, they're on http://cdimage.ubuntu.com/kubuntu/releases/breezy/release/; I'll sort out a link from releases.u.c tomorrow morning, but not now
<Kamion> mdz: great, publishing
<jbailey> Keybuk: pong
<Keybuk> jbailey: so, I was thinking about "assemble"
<Keybuk> and I can't decide where to put the output
<Keybuk> wondered if you had thoughts
<jbailey> hct? md? something I've missed in udev?
<Kamion> mdz: done, I'm off to bed now
* jbailey spent the day trying to convince md not to suck on ppc.
<mdz> Kamion: thanks, night
<ploum> proficiaat allemal :-)
<moyogo> hey... many non-techy people get confused with the PC-Edition and 64bit PC-Edition downloads, 
<Keybuk> jbailey: hct
<Keybuk> jbailey: have been toying with just "..", so when in (e.g.) projects/pmount you'd get projects/pmount-0.9.4 and projects/pmount_0.9.4.tar.gz when you assemble
<Keybuk> but then I thought that's kinda untidy, and I hate the way dpkg does that -- as it makes cleaning up my work/ubuntu directory hard
<Keybuk> but I don't think "." is right either, because ./pmount-0.9.4 is the bzr branch for the diff.gz
<Keybuk> and I hate "ASSEMBLED" type of directories
<doko> jbailey: ping
<Keybuk> (if anyone else has opinions, please feel free to weigh in, because I'm not sure where to put the buggers <g>)
<jbailey> Keybuk: Right.  Preserving dpkg behaviour is consistnat, at least.
<jbailey> Keybuk: Like, I already create ~/Programming/packaging/package
<jbailey> and work in there.
<Keybuk> jbailey: yeah, but I was kinda hoping that "package" would _be_ the hct project directoy
<jbailey> I wind up doing the some for ~/Programming/{cvs,bzr,svn}tree
<jbailey>  /package
<jbailey> So it would itself create subdirectories underneath for everything?
<Keybuk> ie:
<jbailey> doko: pong
<Keybuk> descent scott% cd /tmp/projects/pmount
<Keybuk> descent pmount% ls
<Keybuk> 01-man-plugdev.patch/  debian/  pmount-0.9.4/  pmount_0.9.4.orig/
<Keybuk> descent pmount% ls .hct-project
<Keybuk> manifest  url  version
<jdub> Keybuk: hmm
<jdub> Keybuk: that annoys me too
<Keybuk> (and yes, the evil ++ and ,, and {hct} filenames are all gone now <g>)
<jdub> yay
<Keybuk> but I don't know where to put the resulting source package, dsc, changes, etc. files
<Keybuk> cause that pmount-0.9.4 is a branch:
<Keybuk> descent pmount% bzr info pmount-0.9.4
<Keybuk> branch format: Bazaar-NG branch, format 6
<Keybuk> ...
<Keybuk> anyone?  bueller?
<mdz> Keybuk: cwd
<Keybuk> mdz: do you mean in the projects/pmount directory, or projects/ ?
<Keybuk> the trouble with that is you need to make a pmount-0.9.4 directory for dpkg which conflicts with the one in the project
<Keybuk> (maybe renaming that is the problem, as it's not clear what it is anyway)
<mdz> Keybuk: I mean wherever the build command is run
<mdz> if a command line tool must output something by default to someplace other than stdout, it should end up in cwd
<mdz> least surprising
<Keybuk> but what do you do where that conflicts with stuff in the working directory?
<mdz> if you have a .dsc or .changes in there already, they should be overwritten
<Keybuk> is the name-ver directory I'm having problems with :-/
<zenwhen> Breezy really feels complete and works great guys. Thanks.
<Keybuk> mdz: though you know, I think you're right -- it should just output the diff.gz/orig.tar.gz/dsc/changes in the working directory
<Keybuk> that's the right way to do it
<Keybuk> then if the user wants to unpack the source, they can worry about not overwriting things <g>
<zul> evening
<magnon> congrats on release, everyone!
<magnon> entirely offtopic, what's a packet of cigs in Montreal? =)
<bob2> small cardboard box, contains sticks of tobacco wrapped in paper
<mdz> RIMSHOT
<mdz> beat me to it
<zul> cigs are totally expensive in montreal
* diamond grins
<zul> equivalent to a first born
<diamond> zul: first born are ten a penny these days ,-)
<HrdwrBob> haha
<magnon> bob2: bastard
<zul> diamond: canadian penny is expensive
<magnon> price in CAD, please ;)
<magnon> price of a first born in CAD, then
<zul> meh...looking it up
<Burgundavia> magnon, zul, not cheap, we tax you bastards here
<zul> Burgundavia, i know im in ottawa...thank god i dont smoke
<zul> diamond, i think they are like $10 a pack not sure these days
<magnon> jesus
<magnon> that's like norway prices
<Nafallo> :-)
* Burgundavia watches our numbers on distrowatch climb through the roof
<diamond> zul: that's about 20% more than they are here (ireland) (i think, re: prices, i don't smoke either -)
<daniels> they're ~$10 in .au as well.  sin tax.
<zul> beer is cheap though
<daniels> ish
<magnon> that helps
<magnon> cheaper than here anyway
<magnon> my beer in a somewhat brown place today cost 9 CAD
<diamond> http://www.kidon.com/smoke/int-prices.htm may be of interest
<diamond> ah. it's very out of date.
<magnon> very. :)
* diamond sighs
<dseomn> http://bugzilla.ubuntu.com/show_bug.cgi?id=17744 anybody with access to us.releases.ubuntu.com here?
<diamond> nite folks.
<lamont__> dieman: ping
<magnon> jbailey: ping
<dieman> lamont__: hey
<dieman> lamont__: never got those dvds
<dieman> lamont__: i was just messing with apache, so it was up/down etc
<wasabi> dunt suppose there is a good pptp vpn tool?
<wasabi> (gui)
<bob2> "windows xp"
<_maydayj_> wasabi - try http://pptpclient.sourceforge.net/
<wasabi> Ahh hah!
<fabbione> morning guys
<tseng> hey fabbio, congrats on the annoucements
<fabbione> tseng: thanks
<Nafallo> gnight all
<mxpxpod> has anyone seen "corrupt double-linked list" errors?
<bob2> from what?
<mxpxpod> monodevelop, update-notifier
<mxpxpod> update-notifier does it when I click on it to show updates
<mxpxpod> monodevelop does it when I close tabs
<mxpxpod> bob2: any clue?
<mxpxpod> bob2: it crashes monodevelop, but update-notifier seems to keep going...
<mxpxpod> bob2: ok, that's strange...
<mxpxpod> a recompile of update-notifier fixed is...
<mxpxpod> s/is/it/
<mxpxpod> must be some lib somewhere on my system
<mxpxpod> bob2: still there?
<magnon> I'm wondering, does anyone of you know the hotel rates for ubz?
<mxpxpod> *sigh*
<mxpxpod> so I've narrowed it down to gksudo on the update-notifier thing
<magnon> what update-notifier thing?
<magnon> mine still infinitely loops.
<mxpxpod> when I click on the icon, it says *** glibc detected *** corrupted double-linked list: 0x10067528 ***
<mxpxpod> on the console
<magnon> oh
<mxpxpod> I've narrowed it down to gksudo
<mxpxpod> when I run this command:
<magnon> right
<mxpxpod> when I run this command:
<mxpxpod>  /usr/bin/gksudo --message "Please enter your password to run" /usr/bin/update-manager
<bob2> don't know, sorry
<mxpxpod> it gives me that error
<tritium> hi bob2 
<bob2> hey tritium 
<mxpxpod> magnon: it's got something to do with the --message argument
<magnon> hm
<mxpxpod> I'm building a debugging version of gksu to try and backtrace this
<magnon> sorry, I could possibly look into it but my party starts the yearly weekend long meeting today and I'm preparing a press release on the new govt in norway's political platform from our point of view :P
<mxpxpod> :)
<mxpxpod> that's fine
* magnon is somewhat stressed... and has no cigs
<mxpxpod> magnon: could you check if it does it on another platform other than ppc?
<magnon> uh
<fabbione> guys i am going to take down ubuntulog for a few minutes
<mxpxpod> whoa
<fabbione> upgrading the server to breezy
<magnon> my colleague isn't awake yet, if not I could've asked him
<fabbione> IF i hit the raid disk check
<mxpxpod> gksu FTBFS on ppc
<magnon> 30 minutes =)
<fabbione> it might take me more than 40 minutes to come back online
<fabbione> (actually more, but well..)
<magnon> mxpxpod: I'm not getting the message
<mxpxpod> magnon: what arch?
<magnon> although, I'm not running the newest version of anything on this lappie
<magnon> ppc
<mxpxpod> hrm
<magnon> what's gksudo's package?
<mxpxpod> gksu
<magnon> d'oh
<magnon> newest verison
<magnon> *version
<mxpxpod> huh?
<magnon> wait, wait
<magnon> idea to update lists first
<magnon> jees, I should sleep
<magnon> gksu is the newest version and I don't get your error, that's my conclusion :)
<mxpxpod> hmm
<mxpxpod> so, something on my system is corrupt
<magnon> or the problem is intra-architectural :-)
<mxpxpod> huh?
<crimsun> he's dissing your $arch
<magnon> oh, never mind me preparing political statementish sentences
<magnon> crimsun: I'm using it, though
<crimsun> ;-)
<magnon> I'd rather have x86, but noone makes well designed laptops except apple
<crimsun> I'd rather have ppc, but I'm not complaining. :-)
<magnon> well you get a bunch of stuff not working
<magnon> reason one is arch
<mxpxpod> magnon: try building gksu...
<magnon> reason two is apple+hw vendors
<crimsun> magnon: more stuff to fix, yay
<magnon> mxpxpod: build-dep first and all, could take a few minutes :)
<magnon> crimsun: try fixing flash :-)
<mxpxpod> magnon: thanks for trying all this stuff for me
<mxpxpod> ugh, don't get me started on flash
<magnon> mxpxpod: no problem. I have a 74 page political platform to read, or help you out a bit. It weighs up. ;)
<mxpxpod> :)
<crimsun> magnon: got source? :-)
<magnon> to flash? no :)
<mxpxpod> I just can't believe that gksu ftbfs...
<magnon> hm. what's ftbf?
<mxpxpod> failed to build from source
<magnon> aha
<mxpxpod> I just learned it that the other day
<magnon> googling it got me to
<magnon> http://www.dvocha.org/cgi-bin/four.cgi?FTBF
<magnon> which made me go wtf
(mxpxpod/#ubuntu-devel) magnon: perhaps this would be a good time to try out the breezy installer ;)
* magnon cheers!
(magnon/#ubuntu-devel) mxpxpod: think so :)
(magnon/#ubuntu-devel) wb ubuntulog :P
<mxpxpod> ok, here's something funky
<mxpxpod> if I try to build gksu with DEB_BUILD_OPTIONS="nostrip noopt" sudo apt-get source -b gksu, it fails
<mxpxpod> but if I take off the DEB_BUILD_OPTIONS, it works
<mxpxpod> magnon: how well does dvd playing work with totem-gstreamer on your ppc?
<infinity> Does anything work well with totem-gstreamer?
<magnon> never tried
<magnon> infinity: no
<magnon> well
<mxpxpod> haha
<magnon> if you recon playing sound tracks from videos that should be audiovisual is "well", then yes
<magnon> personally, I am on the verge of installing totem-xine
<mxpxpod> magnon: totem-gstreamer plays most mpegs, wmvs, avis, divxs etc... but totem-xine plays dvds
<mxpxpod> so I'm torn :)
<magnon> hehe
<magnon> hm
<magnon> https://wiki.ubuntu.com/Foo/Bar
<magnon> does anyone else get the css problem?
<magnon> it happens on every two or deeper level page
<infinity> If by CSS problem, you mean "no CSS", then yes.
<magnon> but of course
<infinity> I assume it's using a relative URI for the CSS, rather than an absolute.
<magnon> I'd see that as a CSS problem
<infinity> I'll smack the webmaster folk around
<magnon> yeah, it wasn't that way before at least
* mxpxpod wonders why you would use a relative uri to a stylesheet
<magnon> hawkai.
<magnon> mxpxpod: crossed my mind as well
<magnon> blahblahblah social security with focus on children blah blah
<infinity> mxpxpod : I've done it in the past, but for interesting and weird reasons.
<magnon> puh-lease
<infinity> Oh, and confirmed that gksu doesn't build with -O0
<infinity> So, uhh.  Don't do that, then. :)
<mxpxpod> infinity: :P
<magnon> <infinity> On all arches.
<magnon> <infinity> Quite nicely.
<magnon> :P
<mxpxpod> :D
<infinity> magnon : Note that we don't BUILD with -O0
<infinity> So, yes.  It does.
<mxpxpod> wow, this is a strange bt
<infinity> And this still should have been somewhere else, rather than 5 pages of scrollback in -devel, that's all I was saying.
<mxpxpod> hopefully a reinstall of libc6 will fix this crap
<infinity> Anyhow, add an "#include <locale.h>" near the top of gksu.c and it should build fine, if you'd prefer a -O0 binary.
<jsgotangco> infinity, not even resting even for a day? =)
<highvoltage> JaneW: ping
<JaneW> highvoltage: hello
<\sh> good morning gentlemen
<\sh> ogra: downloading edubuntu isos
<\sh> ogra: onto my laptop that is...
<Keybuk> it's nice, this period, isn't it
<Lathiat> where your doing nothing? :)
<Keybuk> the storm's over, and you've got nothing to do until the emergency crews arrive
<Lathiat> heh
<\sh> Keybuk: hehe...u should work for ISH ;) 
<Keybuk> "ISH" ?
<\sh> Keybuk: if there is nothing to be done for ubuntu , you can fix bloody SUSE servers at our DC
<\sh> Keybuk: 2nd biggest cable tv/cable internet provider in germany :)
<Keybuk> heh, sadly there's plenty to be done
<\sh> just rebooted two fat hp servers and two slim hp servers...and sadly, those guys from frankfurt changed something so badly, that our monitoring system throws out alarms without an end
<Keybuk> heh, I'm just watching the practice times for this weekend's GP while waiting for baz
<Keybuk> and, oddly bzr
<highvoltage> Keybuk: i think there's *lots* of work to be done :)
<Keybuk> though bzr isn't really being slow, it's just outputting a lot of debugging logging output and gnome-terminal is being slow :p
<highvoltage> JaneW: if you need something to be fixed on the website in a hurry, my cellphone number is +27 72 399 6864.
<highvoltage> JaneW: i can always connect via gprs and make a quick fix if needed.
<highvoltage> sorry, wrong window
<highvoltage> :)
<JaneW> highvoltage: thanks, but we wouldn;t have woken you for that! -> moving to #edubuntu
<pef> hello !
<highvoltage> hi pef 
<infinity> highvoltage : Do you have lowlevel webmaster-ish access to the wiki, or should I bug hno73?
<mxpxpod> infinity: so, I've tried reinstalling all (I think) dependencies of gksu and nothing is working to get rid of this bug
<infinity> Okay, so what's the actual bug?  (not the -O0 build failure)
<mxpxpod> infinity: when I run '/usr/bin/gksudo --message "Please enter your password to run:\n /usr/bin/update-manager" /usr/bin/update-manager'
<mxpxpod> I get this:
<mxpxpod> *** glibc detected *** corrupted double-linked list: 0x10068568 ***
<mxpxpod> Aborted
<fabbione> oh interesting
<highvoltage> infinity: you should bug hno73 ;)
<mxpxpod> and this is on ppc
<highvoltage> infinity: i have access to the docroot of the edubuntu static pages
<infinity> Ahh.
<Keybuk> I love those errors, "GLIBC DETECTED!  DANGER!  DANGER, WILL ROBINSON!"
<mxpxpod> Keybuk: and the backtrace gives me nothing
<Keybuk> usually that means Mr Pointer has wondered off the end of Mr Buffer
<Keybuk> have you tried valgrind?
<pitti> Good morning
<mxpxpod> Keybuk: no, it doesn't work on pp
<mxpxpod> c
<mxpxpod> pitti: dude
<Keybuk> I thought it did now?
<mxpxpod> Keybuk: there aren't suppression files for it
<infinity> Keybuk : valgrind only works on i386 and amd64, afaik.
<Keybuk> the website claims ppc versions with download links
<infinity> But pitti runs a ppc desktop, maybe he can tell you wtf is up. :)
<mxpxpod> pitti: I've got some problems :( try running this with latest breezy: /usr/bin/gksudo --message "Please enter your password to run:\n /usr/bin/update-manager" /usr/bin/update-manager
<Keybuk> mxpxpod: is it gksudo or update-manager that has the problem
<pitti> mxpxpod: on ppc?
<mxpxpod> Keybuk: gksudo
<mxpxpod> pitti: yeah
<mxpxpod> Keybuk: because it runs fine if you do gksudo /usr/bin/update-manager
<infinity> Keybuk : Curious.  We should get that into dapper.
<Keybuk> ==21948==  Address 0x1C1E4B84 is 0 bytes after a block of size 4 alloc'd
<mxpxpod> Keybuk: valgrind "works" on ppc, but with no suppression files, it's kinda useless because it'll just pop up errors all the time
<Keybuk> ==21948==    by 0x804A506: (within /usr/bin/gksu)
<pitti> mxpxpod: works
<Keybuk> ==21948== Invalid write of size 4
<mxpxpod> pitti: dammit!
<Keybuk> ==21948==    at 0x1B91486F: gksu_context_sudo_try_need_password (in /usr/lib/libgksu1.2.so.0.0.2)
<Keybuk> ==21948==  Address 0x1C42E784 is 0 bytes after a block of size 20 alloc'd
<Keybuk> ==21948==    by 0x1B914812: gksu_context_sudo_try_need_password (in /usr/lib/libgksu1.2.so.0.0.2)
<mxpxpod> pitti: why the hell am I getting this:
<Keybuk> etc.
<mxpxpod> *** glibc detected *** corrupted double-linked list: 0x10068568 ***
<mxpxpod> Aborted
<infinity> Oh, the PPC port is 2.4.x still.  Someone needs to forward-port those patches.
* Keybuk backs away from gksu with fear in his eyes
<mxpxpod> Keybuk: it's like gksudo doesn't like the --message option
<mxpxpod> pitti: so, basicallly I'm trying to figure out why this is only happening on _my_ machine :(
<pitti> mxpxpod: hm, this is breezy final?
<pitti> mxpxpod: do you get other crashes which could point to corrupted RAM?
<mxpxpod> pitti: yessir... updated today
<mxpxpod> pitti: one in monodevelop that looks similar
<mxpxpod> pitti: but that's it
<pitti> mxpxpod: I installed from scratch, could be worthwile to check if a hoary->breezy update exhibits this
<mxpxpod> hmm
<mxpxpod> I was considering (earlier) doing a fresh install tomorrow
<mxpxpod> it's just frustrating... I reinstalled all the packages that gksudo depends on
<mxpxpod> thinking that somehow they might have been corrupt... but to no avail
<pitti> mxpxpod: you migh build a debugging version and gdb it
<mxpxpod> pitti: of gksudo?
<mxpxpod> pitti: did it... no dice
<pitti> mxpxpod: depends on whether gksudo or u-m crashes
<pitti> mxpxpod: does the crash happen if you execute other programs with gksudo?
<mxpxpod> wait a minute...
<mxpxpod> hey hey... this very well might be an update-manager issue...
* mxpxpod slaps himself
<mxpxpod> ok, this is really strange
<mxpxpod> if I do: /usr/bin/gksudo --message "Please enter your password to run:\n /usr/bin/update-manager" update-manager, it doesn't crash
<mxpxpod> but with the absolute path, it crashes
<pitti> that's really weird
<infinity> do you have more than one update-manager in your path?
<pitti> I tried with an absolute path
<pitti> I used exactly your command
<pitti> mxpxpod: "which update-manager"
<mxpxpod> which update-manager
<mxpxpod> whoops
<mxpxpod> /usr/bin/update-manager
<pitti> ok, fine
<highvoltage> Kamion: is there an rsync server for the edubuntu release cd?
<pitti> mxpxpod: <mxpxpod> pitti: did it... no dice
<pitti> mxpxpod: ^ what does that mean? no usable stack trace?
<mxpxpod> pitti: right
<mxpxpod> pitti: *sigh* this is strange
<mxpxpod> and I need to get to bed
<maswan> highvoltage: se.releases.u.c::ubuntu-releases/edubuntu/ ?
<mxpxpod> pitti: want me to query you the bt?
<pitti> mxpxpod: can't hurt
<infinity> mxpxpod : Do you get the same behaviour if you "sudo su", then "/usr/bin/update-manager"?
<mxpxpod> infinity: no
<maswan> More than 10TB of breezy from over here since release.
<Lathiat> whats that, 16,000 copies of a cd?
<maswan> yeah, something like that
<Lathiat> nice
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<Lathiat> yeh i've been keeping an eye on 3 ;p
<maswan> and as expected, demand dropped during the night, but now it is ramping up again
* Lathiat nods
<maswan> "night" here also means after office hours in north america, so it could be just that the demand is high during office hours in europe and north america
<mxpxpod> infinity: thanks for all the help... I'm going to do a fresh install tomorrow and hopefully I won't have all these friggin problems :)
<Lathiat> gah my phone wont charge :\
<\sh> mvo: ping...-> query
<Kinnison> Morning
<sivang> Morning Kinnison :)
* pitti releases his first Breezy USN
<pitti> Hi Kinnison 
<sivang> pitti:that fast :)
<pitti> Hi carlos 
<carlos> pitti, morning
<dholbach> hellas
* mvo waves to dholbach 
<dholbach> hi michael :)
<pitti> ah, the Greek mood dholbach again :-) Good morning!
<dholbach> hellas pitti! :)
* sivang waves to pitti, dholbach, mvo and the rest of the nice gang.
<pitti> Hi sivang 
<\sh> hey sivang :)
<mvo> hey sivang 
<sivang> hi \sh :)
<\sh> sudo rm -Rvf ~/chroot_breezy 
<jsgotangco> woooo
<sivang> s/chroot_breezy/chroot_dapper ? :)
<maswan> \sh: just make sure you don't have your /home bind-mounted there? :)
<sivang> maswan: can do that without dchrooting :)
<sivang> errm, actually, it's the same
<\sh> maswan: I just unmounted the bind ;)
<zyga> morning everyone
<maswan> \sh: I've been bitten by that, luckily, the earliest part of /home was my homedir, which had a few kernel trees. so I C-c:ed it before it hit the other users. ;)
<Kamion> highvoltage: sure, same as the one for all the other release CDs
* Kamion adds DVD links to releases.u.c
<jsgotangco> i tried the DVD torrents a few hours ago and i didnt get any seeds :(
<\sh> maswan: well...the last time I trashed a home dir, was not even a trashing it was a mess ,-) I wanted to change some permissions on the ftp homedir, and changed finally 300 userhomedirs 
<pitti> elmo: can you please remove evolution from hoary-updates? the version in hoary-security has the same patch and is newer than the -updates one
<maswan> Kamion: sent 453 bytes  received 1689830041 bytes  29821.68 bytes/sec
<maswan> Kamion: the one that finally managed to get ubuntu-server
<maswan> Kamion: got done a couple of hours ago
<pitti> Hi seb128 
<seb128> hey pitti
<Kamion> maswan: hooray!
<maswan> Kamion: indeed
<mantas> Hi all
<mantas> aigarius, hi, long time without a meet :(
<siretart> hey folks
<siretart> no jigdos available for dvd images?
<Kamion> siretart: no, sorry
<Kamion> the build time was too long
<siretart> ah. okay
<mantas> :(((
<siretart> Kamion: do the dvd images contain all of main?
<Kamion> siretart: all of <appropriate distro> supported, which is a (large) subset of main
<mantas> Kamion, maybe it would be wise to build DVD jigdo files at least for final Breezy release ?
<siretart> oh
<Kamion> mantas: maybe I'd already thought of that ;-)
<siretart> :)
<Kamion> it's not trivial to build them after the fact, but I'll see what I can do
<mantas> lots of people have release candidate DVD's, so it's waste of download time and bandwith to download whole DVD again
<Kamion> they can either use rsync, or just upgrade rather than reinstall
<fabbione> mantas: rsync would do fine in that case
<mantas> Kamion, I'm not talking about upgrading installed system, I'm talking about upgrading of DVD images ;)
<mantas> fabbione, really ?
<fabbione> mantas: yes.. rsync the new DVD on top of the old image
<mantas> rsync will not download whole 2,5 GB if I have release candidate dvd ?
<Kamion> no
<Kamion> fabbione brought up a good point
<Kamion> jigdo for our DVDs would be of somewhat limited usefulness
<Kamion> because there are very large pieces of the DVD images that aren't in the archive, namely the live CD image and the WinFOSS stuff
<Kamion> so the .template file would be *huge*
<Robot101> ha
<Robot101> thats unfortunate :)
<Kamion> as in, the template file would be roughly CD-sized
<siretart> hm. what about a dvd jigdo image, with 'just' all of ubuntu/main and nothing else (no winfoss, no livecd)?
* siretart makes a note on the list..
<Kamion> siretart: it wouldn't work
<Kamion> oh, you mean a separate build
<siretart> yepp
<mantas> Kamion, You can publish WINFOSS stuff at download server, then .template will be no big. Btw, maybe it would be wise to add info about rsync to README files at ftp://cdimage.ubuntu.com/cdimage/dvd/ ?
<Kamion> not for breezy, and unlikely in general; we have *far too many* builds
<pitti> Kamion: ah, you can't tell jigdo to scan the live CDs?
<Kamion> mantas: I'm not doing that kind of jigdo messing around for breezy.
<Kamion> I refuse. I've had enough of breezy :)
<bob2> are there really that many people downloading dvds?
<Robot101> pitti: the live CD is not comprised of .debs
<pitti> Kamion: it would be nice to jigdo against the old DVD, the current CD, and the current live CD
<mantas> ;)
<Kamion> pitti: not AFAIK
<siretart> Kamion: for official, I understand and accept, but I don't see technical reasons for not doing this in private, are they?
<Robot101> is it?! :P
<pitti> Robot101: jigdo does not need .debs, AFAIK; I'm talking about the big .cloop image
<Kamion> mantas: we don't publicise rsync very heavily because the server gets easily overloaded
<Kamion> siretart: I am overloaded
<pitti> Kamion: it's just a nice-to-have, but if it is nontrivial, let's just forget about it
<Kamion> especially before release - and cdimage is too
<Robot101> pitti: is that file in the archive though?
<Kamion> pitti: it's non-trivial
<Kinnison> Kamion(int), Kamion(char*) *and* Kamion(float)
<siretart> Kamion: I don't want to overload you. sorry
<Kamion> Kinnison++
* Kinnison tickles Kamion 
<Kamion> siretart: and we don't have "private" CD images :)
<Kamion> maybe one day Launchpad will do CD building and you'll all be able to build whatever weird stuff you want :)
<Kamion> but for now, it all comes out of my time
<Kamion> so we do one of each type of image and that's all
<mantas> Kamion, OK, I understand, thanks for info about rsync
<Kamion> which is good for testing anyway - it avoids dividing efforts
<siretart> Kamion: I was thinking of doing it myself for my private fun. not overloading you ;)
<Kamion> mantas: people often seem to guess rsync cdimage.ubuntu.com:: anyway
<Kamion> siretart: you're welcome to :)
<siretart> :)
<Kamion> it would be fairly trivial to turn off the switches in cdimage that control that
<mantas> ;
<\sh> mvo: pingeling
<mvo> \sh: pongelong
<\sh> mvo: please do a speed check
<mvo> \sh: with pleasure
<highvoltage> i have colour in my bash and i can't see a performance difference at all.
<highvoltage> bah! wrong channel again!
<Treenaks> highvoltage: #gentoo? :)
<highvoltage> Treenaks: close, my local LUG ;)
<Treenaks> highvoltage: try the color prompt on a 9600 terminal
<highvoltage> Treenaks: i've run mc before on a 9600 terminal :P
<highvoltage> (not pleasant though)
<\sh> BAH
<\sh> live cd breezy i386 -> hp nc6000 laptop with port replicator/docking station -> doesn't startup with the right resolution on the external monitor, makes the TFT display freaking around and only after shutting down the lid, and reopening it, you see the correct picture on the tft
<Treenaks> I need to get an external monitor :)
<\sh> the same happens with a nc6120 without a port replicator/docking station but with external monitor directly connected...
<\sh> without external monitor/docking station etc. everything is fine
<Treenaks> \sh: I have a port replicator/dock for my NW8240 -- but I don't know if my monitor is "good enough" to test with
<\sh> Treenaks: is a "nec multisync lcd1830" good enough? 
<Treenaks> \sh: if you're willing to send it to me ;)
<\sh> Treenaks: well...this is what we're using here...and I don't like the quality...2 TFTs broke during the last 2 weeks for me...and they were only 1 year old :(
<Treenaks> \sh: ouch
<Treenaks> \sh: I have an ancient Compaq CRT to test with
<\sh> Treenaks: would be great :)
<Treenaks> \sh: yeah, too bad it doesn't fit on my desk :(
<Treenaks> so I'll have to do some magic to make it work
<spacedman> guys, is there a way of getting the ubuntu version from the command line?
<Treenaks> spacedman: cat /etc/issue :)
<Treenaks> or cat /etc/lsb-release
<Treenaks> the second one works best I think
<spacedman> ooh... didnt know lsb-release...
<spacedman> thats an LSB standard thing I spose... neato.
<spacedman> sweet. cheers.
<Keybuk> Diziet: so, that mysterious python dep shit came from dh_python
<Diziet> That's nice.  Can it be persuaded not to be barmy ?
<Keybuk> apparently not
<Keybuk> I just stopped using it and hard-coded the right dep :p
<Diziet> :-)
<Keybuk> pitti: btw, if you figure out how to _close_ bugs in Malone, please let me know
<Keybuk> because I'm buggered if I can find it
<Keybuk> there's a "* Mark bug as duplicate" but nothing else
<pitti> Keybuk: it took me a while to find out
<bob2> Keybuk: apparently you have to click on the "upstream" link, then change the state to fixed
<pitti> Keybuk: but I closed several ones now
<Keybuk> bob2: that's the thing, it all changed and now I can't find that link
<bob2> Keybuk: but only if you own it, because bug reporters can't be trusted!
<Keybuk> the upstream link tries to make me add it to another upstream
<bob2> haha
<pitti> Keybuk: but it it absolutely nonobvious where to click
<TerminX> so, Tuesday for Dapper, huh?  *marks "change sources.list to use dapper" on his calendar*
<Keybuk> is this another one of those oh-so-shiny links that's done in the same colour as ordinary text?
<Keybuk> so you can only find it by waving your mouse around the page until the pointer changes?
<pitti> Keybuk: right, it's not apparent that this is even a link
<pitti> Keybuk: and even if it was, it is non-obvious that you can edit the status of the bug with it (and close it)
<bob2> Keybuk: the "fixe requested for" column, apparently
<bob2> wow, that's really unintuitive
<pitti> there should just be an "Edit status" in the right menu
<Keybuk> whoah
<Keybuk> it's the "product (upstream)" bit of text you have to click?
<bob2> so it seems
<Diziet> I thought this thing was supposed to be having an email interface.
<juliux> pitti, ping
<bob2> I thought that was a 1.0 feature in june
<maswan> Znarl: How's the DC doing? Got enough bandwidth for now?
<pitti> Hi juliux 
<juliux> pitti, ogra says that i show you this http://wiki.ubuntuusers.de/EVMS-Snapshots_mit_Verschl%C3%BCsselung
<juliux> pitti, i want make this with edubuntu
<pitti> juliux: looks interesting
<juliux> pitti, i will test it in vmware
<Znarl> maswan : It's ok.  Things have become less busy today.
<jmibanez> hello there
<jmibanez> there seems to be a bug mounting floppies using the GNOME (Nautilus) interface
<jmibanez> complains about "UDI is not a mountable volume"
<jmibanez> i'm going to be filing a bug report, but i'd like to ask if anyone here has seen it
<jmibanez> (the bug i mean)
<maswan> Znarl: just so you know, if you are tight, feel free to dump more users on us. we're at about 75% of capacity, so we have some headroom for more users.
<jmibanez> (so far, it looks like something to do with HAL + Project Utopia)
<pitti> jmibanez: hm, neither my desktop nor my laptop has a floppy, and neither do the laptops of my flatmates :-(
<Znarl> maswan : OK, thanks.
<pitti> jmibanez: please file a bug and include the output of "lshal"
<jmibanez> pitti, am in the process, thanks :)
<jmibanez> pitti, err, no need, saw the bug in bugzilla
<jmibanez> pitti, but will attach a comment with output of lshal
<pitti> jmibanez: thanks; is it assigned to me?
<jmibanez> any suggestions on how to trace this thing? would like to help squash it :)
<jmibanez> pitti, errr... are you martin pitt? then if you are, yeah :)
<pitti> jmibanez: let's talk through bz, I'm a bit busy atm
<pitti> jmibanez: there I will see the debug stuff, et.
<jmibanez> pitti, ok
<pitti> jmibanez: which bug#?
<jmibanez> 17562
<jmibanez> pitti, 17562 :)
<Kamion> Keybuk: dh_python creates a dependency on python if you use #! /usr/bin/env python
<Keybuk> Kamion: but by the point it's scanning stuff, that's been replaced
<Kamion> Keybuk: might want to look at the -V flag too
<Kamion>        -V version
<Kamion>            If the .py files your package ships are meant to be used by
<Kamion>            a specific pythonX.Y version, you can use this option to
<Kamion>            specify the desired version, such as 2.3. Do not use if you
<Kamion>            ship modules in /usr/lib/site-python.
<Keybuk> *shrug* was easier to hardcode <g>
<pitti> jmibanez: that UDI looks indeed broken
<Keybuk> you have to sed when there's a new python *anyway*
<Kamion> Unidentified Drinking Injury?
<pitti> jmibanez: but anyway, what does "pmount-hal /org/freedesktop/Hal/devices/computer_storage -v" do?
<jmibanez> same message as the one posted on bz
<pitti> jmibanez: the "is not a mountable volume" one?
<jmibanez> pitti, yup
<jmibanez> pitti, hold on a sec, i'll be diffing the output of lshal on a hoary install on similar hardware
<pitti> jmibanez: right, that UDI does not have the "volume" capability
<pitti> jmibanez: I think I know what's wrong
<pitti> jmibanez: but if it worked in hoary, a hoary lshal output is appreciated
<jmibanez> pitti, ok. do you still need the diff against lshal (hoary)?
<jmibanez> pitti, will attach
<pitti> jmibanez: I can sort of reproduce it here with trying to mount the CD-ROM storage device
<pitti> jmibanez: but with CD-ROMs it works since the media that is inserted generates a hal event and eventually gets its own volume
<jmibanez> pitti, do you want me to attach a diff of the stanza in lshal for the floppy?
<pitti> jmibanez: that would rock - or just attach the hoary stanza
<pitti> jmibanez: that'll even be easier for me
<pitti> jmibanez: I assume that in hoary, hal regarded the floppy as volume
<jmibanez> pitti, looking at it now-- no, block.is_volume=false on hoary
<pitti> jmibanez: does pmount-hal /the/udi work in hoary?
<jmibanez> pitti, yes
<jmibanez> pitti, i noticed however that linux.sysfs_path and sysfs_path_device point to two different places
<pitti> jmibanez: hmm; please attach the stuff, I'll look at it
<jmibanez> pitti, will do
<pitti> jmibanez: thanks for your help!
<Kamion> there, cdimage should support dapper now
<jmibanez> pitti, no prob
<jmibanez> pitti, btw, what else can i do to help trace this? (i'm also a programmer fwiw)
<pitti> jmibanez: if you want to, you can look at the pmount-hal.c code and look what it uses to decide whether it's mountable (the code is trivial)
<pitti> jmibanez: ah - "    volume = libhal_volume_from_udi( hal_ctx, udi );"
<pitti> jmibanez: it seems that this really only catches volumes
<jmibanez> pitti, you'll have to excuse me... how'd i get the code?
<pitti> jmibanez: never mind, I know what's necessary
<jmibanez> pitti, ok :)
<pitti> jmibanez: apt-get source pmount
<jmibanez> pitti, oh yeah
* jmibanez slaps forehead
<pitti> jmibanez: or look into the bzr branch
<pitti> jmibanez: bzr branch http://people.ubuntu.com/~pitti/bzr/pmount/
<jmibanez> pitti, no bzr on this machine (am helping out setup a netcafe)
<pitti> jmibanez: it seems that if the UDI is not a volume, p-hal should check if it is a storage device
<pitti> jmibanez: storage.no_partitions_hint = true  (bool)
<pitti> jmibanez: that's the thing to check
<pitti> jmibanez: if the UDI is a storage device with this property, it should be accepted as well
<jmibanez> pitti, hmm... from looking at it, that moves the problem to libhal-storage?
<jmibanez> pitti, pmount-hal doesn't seem like it's the problem
<pitti> jmibanez: no, it's just pmount-hal not checking for this case
<pitti> jmibanez: well, the real problem is that floppies are not hotpluggable
<jmibanez> pitti, ah, true
<pitti> jmibanez: if they were, hal would pick it up and create a volume node for it
<pitti> jmibanez: but with floppies, you can more or less just try to mount and check if it worked
<pitti> jmibanez: I added a followup
<jmibanez> pitti, thanks. (this is why F/OSS is so great :)) )
<pitti> jmibanez: that's why I love it, too :-)
<pitti> jmibanez: I'll release pmount 0.9.6 to debian soon, and as soon as dapper opens, I'll sync it there
<jmibanez> anyway, am off
<jmibanez> pitti, when will breezy update with pmount 0.9.6, if ever? (just curious)
<pitti> jmibanez: never
<pitti> jmibanez: breezy is closed
<pitti> jmibanez: and it's not a critical bug
<pitti> Hey Yagisan 
<seb128> pitti: waiting on dapper ? :)
<Yagisan> G'day pitti
<pitti> seb128: lots of new crack is waiting :-)
<seb128> he he
<pitti> seb128: but for now I have some time to catch up with security
<jmibanez> pitti, ah... would it be ok if i try backporting it to breezy? my friend who i'm helping with needs floppy access via GNOME
<pitti> seb128: if you happen to be bored, just ask, I have some work :-)
<pitti> jmibanez: yes, breezy-backports should be fine
<pitti> jmibanez: right, I forgot about that
<seb128> pitti: no thanks, I've some bug triage to do :)
<jmibanez> great :)
<pitti> jmibanez: unlike breezy->hoary, dapper->breezy backports for pmount stuff should be fine
<pitti> seb128: me too, actually :-/
<jmibanez> anyhoo... off to meet my SO. thanks for the help pitti 
<Yagisan> pitti - only out one day and already I see a security update released for breezy
<pitti> Yagisan: there will be more today
<Yagisan> pitti - nothing that requires a reboot I hope
<pitti> Yagisan: no
<infinity> pitti : Argh.
<pitti> infinity: meh?
<Kamion> /dev/sda3            562456664 356469920 177415576  67% /
<Kamion> elmo: ^-- little somewhat happier now
<infinity> pitti :         dh_gencontrol -plibcurl2 -plibcurl2-dev -- -v"1:7.11.2-12ubuntu3" -V"cavok:Binary-Version=1:7.11.2-12ubuntu3"
<infinity> pitti : curl in hoary-security.  (version in debian/rules needs to be bumped)
<pitti> infinity: grumble - thanks for the hint
<pitti> infinity: for breezy and warty, too?
<pitti> infinity: the breezy packages are alreadfy there
<infinity> pitti : Check, but I think hoary is the only one that shipped the crazy multiple-curl-in-one-source thing.
<infinity> wary may have as well.
<infinity> warty, too.
<infinity> I think breezy is fine.
<pitti> ok, I check, thanks
<Kamion> maybe some day I'll take a cartload of CD-Rs down to the DC and burn archival copies of all the old releases rather than keeping them around in little:/home/cjwatson/
<siretart> what part in the installer writes /etc/network/interfaces?
<Kamion> siretart: netcfg
<siretart> okay
<siretart> I try to debug why my preseeded installation lacks the 'auto eth0' stanza
<Kamion> we don't add auto eth0 if the interface is hotpluggable
<siretart> huh? this is a test installation in vmware
<Kamion> instead we add mapping hotplug, script grep, and a map line for the interface
<Kamion> so that the interface is brought up when it appears
<siretart> then a 'auto hotplug' stanza should be somewhere, right?
<Kamion> no
<Kamion> mapping hotplug, not auto
<Kamion> Znarl: would you mind doing a couple of loop-mounts on little for me?
<maswan> Kamion: i'll try to mirror cdimage/releases, it is likely to take a long time though.
<Znarl> Kamion : As long as you don't mind creating an RT request?
<Kamion> ok, but it's only temporary
<Kamion> like, for ten minutes while I copy the stuff out :)
<Kamion> maswan: ok, no rush for that
<Znarl> Kamion : Oh, ok.  Message me what you'd like done.
<maswan> Kamion: Indeed, I'm getting a whopping 35k/s now. ;)
<jdub> GOOD MORNING FREEDOM LOVERS!
<Treenaks> hey jdub
<Treenaks> how are you today? :)
<jdub> pretty hammered
<jdub> jetlag catching up with me
<jdub> not dodging timezones quickly enough :-)
<HiddenWolf> maswan, it was 20kbs earlier
<maswan> Znarl: how about we take us.releases until sbrath manages to find a non-crasching router or similar? ;)
* maswan wants faster sync rates ;)
<Treenaks> jdub: luckily the Amsterdam<->London timezone difference is manageable ;)
<Znarl> maswan : Sounds good.
<\sh> well..this is boring...no traffic on -changes anymore...someone has to do something ;)
<Treenaks> yes, let's create dapper :)
<infinity> Oh, just let us have a long weekend, will you? :)
<Treenaks> infinity: well, for this once then
<HiddenWolf> \sh, nothing stops you from hacking up the next wonder of the known world. :)
<mdke> jdub, morning? :p
<\sh> HiddenWolf: I was thinking about Wubuntu...Ubuntu with Windowmaker, or gnusbuntu...ubuntu running emacs os...help would be fine ,-)
<jordi> seb128: how does ubuntu handle the addition of newly created users to the "desirable" system groups like audio, plugdev, etc?
<Nafallo> shouldn't be even better to have all CC.archive.ubuntu.com not go to the DC? ;-)
<HiddenWolf> \sh, you'll get more fame starting blingbuntu, and pimp up E17. :)
<Treenaks> \sh: wubuntu -> ubuntu with the win32 kernel?
<Treenaks> HiddenWolf: no, that'd be eubuntu
<jordi> seb128: do you patch system-tools-backends?
<seb128> jordi: with g-s-t? it's patched for that, why?
<jordi> seb128: we're discussing this for lliurex.
<HiddenWolf> Treenaks, it's marketing, people who use E17 want bling, so they get bling. :)
<Treenaks> HiddenWolf: UBlingtu?
<HiddenWolf> Treenaks, ugh
<\sh> CUbuntu -> Ubuntu for Consoles running TurboVision 
<\sh> bah no crack today anymore
* fabbione takes away the pipes
<fabbione> or i will slam all of you in a chrooted busybox on tmpfs!
<fabbione> ;)
* fabbione &
<maswan> bubuntu - all busybox ubuntu?
<jdub> maswan: sounds not so good when spoken :)
<jdub> well
<jdub> "not so good" doesn't mean "inaccurate"
<jdub> ;-)
<HiddenWolf> maswan, sounds like a make of diapers, really.
<Nafallo> HiddenWolf: dude... usplash? :-)
<HiddenWolf> Nafallo, don't get me started.
* Nafallo got _disturbing_ usplash images in his head now :-P
<ogra> whats wrong ? 
<mjg59> I had a dream about usplash
<HiddenWolf> mjg59, go on vacation. :)
<Nafallo> mjg59: oh? did you fix bugs, woke up and forgot what you did in your dream? :-)
<mjg59> It had gained animation support
<Nafallo> lol
<HiddenWolf> mjg59, disturbing.
<mjg59> Yes
<HiddenWolf> mjg59, why not hack it up to display random sequences of your avi collection? :P
<Nafallo> I rather have interactivity in it ;-)
<Nafallo> for typing in passwords and such things :-)
* Kamion tries out libarchive, which apparently can extract ISO9660 without needing to mess around with loopback mounts
<pitti> Kamion: you can just open images with nautilus (archive-manager)
<pitti> Kamion: oh, on a remote server? (little?)
<jdub> pitti: ooh, we should write that pmount spec
<pitti> jdub: right
* jdub wants to make gnome-vfs pointless for smb and stuff like that for dapper
<mjg59> pointless?
<Kamion> pitti: yes, remote
<mjg59> Wow. Flight prices to Australasia around LCA are stupid.
<pitti> Kamion: I only see libarchive-{tar,zip}-perl, is there something similar for isos?
<Treenaks> jdub: like, pmounting smb shares?
<Kamion> pitti: http://people.freebsd.org/~kientzle/libarchive/
<pitti> we could as well do that with just readding the suid root bit to smbmount
<pitti> Kamion: cool, thanks
<jdub> Treenaks: yeah, and filesystem images (ext3, iso, etc)
<infinity> pitti : Which we probably should do.
<Treenaks> jdub: cool
<infinity> pitti : I keep forgetting to have that argument until it's 3 days before release.
<Treenaks> jdub: I was thinking about something like this yesterday.. more "cooperation" with other OSs, instead of just mostly ignoring them as we do now
<Kamion> jdub: isn't that excessively dangerous?
<Kamion> jdub: unless you had pmount scan for set-id bits in the filesystem first
<jdub> Kamion: i have stupid ideas. pitti makes them sane and secure.
<jdub> i like this system ;)
<Kamion> some things it's *good* that you can't do ;-)
<Kamion> loop-mounting ISOs is probably safe - I don't think there's a set-id equivalent there
<pitti> Kamion: pmount mounts everything with nosuid,nodev
<Kamion> ah
<Kamion> ok, fair enough
<pitti> Kamion: I was pretty paranoid about that :-)
<Kamion> in this case I got screwed on little anyway, 'cos elmo's custom kernel doesn't have iso9660
<pitti> so far I don't see a compelling reason  why pmount shouldn't mount images; I just didn't implement it yet
* jdub loves the p in pmount
<jdub> Kamion: ha ha ha ha
<Kinnison> jdub: like you love the p in pool ?
<pitti> jdub: initially it meant "policy"
<jdub> i love the p in lunch
<jdub> pitti: that's the p i love - what does it mean now?
<jdub> pittimount? :)
<pitti> jdub: I never defined it actually
<Nafallo> paranoidmount :-)
<pitti> jdub: oh, I did - pmount(1) says "policy mount"
<jdub> pimp-my-mount
<Treenaks> pittimount
<jdub> Kamion: i sent my release management thoughts to the list
<Nafallo> pitti: btw, I think I had an error about charset being deprecated when mounting a vfat. :-)
<pitti> jdub: interestingly enough, there is also a "libpmount" that was introduced into Debian about the same time that I started with pmount - but it has nothing to do with pmount :-)
<jdub> pitti: heh, funny
<pitti> Nafallo: known, but I always ignore it - so what, I *want* UTF-8...
<mjg59> Kamion: You coming down to London today?
<Nafallo> pitti: the where a new flag... nls? :-)
<Kamion> mjg59: no, going up to my parents this evening
<Kamion> dad's in a concert
<pitti> Nafallo: ah, I see; nice
<pitti> Nafallo: will change this in bzr head
<mjg59> Ah, ok
<Kinnison> jdub: you know, you never did tell me which sodding pub we're going to
<mjg59> Kinnison: It's on the wiki
<pitti> Nafallo: this is quite messy - for vfat, it is just "utf8", for iso9660 "iocharset=utf8", and for ntfs "nls=utf8". yay consistency
<siretart> grmpf. does hotplug support pcnet32 at all?
<Nafallo> hehe, I wonder what I mounted to get the warning :-P
<Kinnison> mjg59: aah
<jdub> Kinnison: green man, it's on the wiki now
<pitti> Nafallo: I'll read mount(1) in detail again, but iocharset just seems to work everywhere
<jdub> Kinnison: could you tell relevant -uk lists?
<Nafallo> pitti: oki. just noticed it on my logs, I'll see if I can find what caused the warning :-)
* Kinnison waits for his write to the wiki to complete
<Kinnison> it so slow
<mjg59> It's produced an ickle Google Map
<Kinnison> yeah, google-local is a bit cruddy
<Kinnison> jdub: what -uk lists?
<Kinnison> jdub: I was asked by sabdfl not to parade it on debian-uk
<Kinnison> jdub: and I'm not part of the loco or anything
<jdub> oh
<jdub> sabdfl: why was that?
<sabdfl> jdub: we need to make more of an effort with the ubuntu community
<sabdfl> past release parties have had very few ubuntu-specific people there
<sabdfl> and have turned into mark-buys-debian-uk-beer-and-dinner
<mjg59> (very nice dinner)
<Nafallo> pitti: fwiw, I can't reproduce what I just reported ;-)
<infinity> sabdfl : Hrm, we need a mark-buys-debian-melbourne-beer-and-dinner release party.
<pitti> [20739.136463]  FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
<pitti> Nafallo: ^ that one?
<Nafallo> yepp
<Nafallo> or no
<sabdfl> i'm open to suggestions but was trying to encourage a bit more effort to get the guys who really care about ubuntu together tonight
<Nafallo> I had one that said io-charset was deprecated for nls
<sabdfl> at some of the past events i've been a bit nervous to say "ubuntu"
* jdub posts to ubuntu-uk
* Nafallo goes to grep logs :-)
<dredg> what's wrong with google local?
<ogra> sabdfl, just come to the next edubuntu release party... then you can change to mark-buys-candy-for-edubuntu-kids
<dredg> ogra: good thinking! brainwash them while they're young... ;)
<ogra> lol
<ogra> dredg, its rather "show them the bright side and let them decide themselves" ;)
<Nafallo> syslog.0:Oct 12 21:10:52 localhost kernel: [14323.780752]  NTFS-fs warning (device dm-2): parse_options(): Option iocharset is deprecated. Please use option nls=<charsetname> in the future.
<Nafallo> pitti: ^
<Nafallo> I didn't even know I had NTFS-stuff :-P
<pitti> Nafallo: ah, ntfs - ENONTFSHERE
<sabdfl> ogra: oh, the headlines
<pitti> Nafallo: there is no mkfs.ntfs that I'm aware of
<dredg> ogra: feh, now you're just splitting hairs
<pitti> Nafallo: ok, I'll add it to the TODO
<Nafallo> pitti: well, I don't have NTFS either :-P
<ogra> dredg, yes, i have enough to do that still :)
* dredg laughs
<Nafallo> so where is that coming from? :-P
<HiddenWolf> sabdfl, I'm free tonight, but on the wrong side of the channel, sorry. :P
<pitti> Nafallo: ah, you prolly mounted an ext2/3 drive
<pitti> Nafallo: it tries all fs in succession
* dredg wonders what google local is up to
<Nafallo> ah
<pitti> Nafallo: and ext3 is probed after ntfs
<dredg> it's being a tad stupid
<sabdfl> HiddenWolf: it's been swum before, y'know
<Nafallo> yea, that should be it. I think I saw it when I used my cryptostick ;-)
<HiddenWolf> sabdfl, yeah, but you'd want one waiting on the other side with a blanket and tea, not an ubuntu-shirt and beer. :)
<dredg> ah, i see what's wrong. i was using http://local/ which is not the same as http://local.google.com/
<sabdfl> tea, blanket, beer, floor
<HiddenWolf> sabdfl, I prefer boats even then. Specially with sails. :)
<hyperactivecrond> err... is it just me or is the ubuntu site slower than usual when apt-get 'ing something?
<dredg> hyperactivecrond: probably getting hammered by everyone updating
<HiddenWolf> hyperactivecrond, breezy was released, site getting hammered,.
<HiddenWolf> wiki is slow as can be.
<hyperactivecrond> sweet it's been released
<HiddenWolf> hyperactivecrond, you missed it?!
<HiddenWolf> hyperactivecrond, shame on you. ;)
<hyperactivecrond> i'm runnin in breezy prerelease, can i apt-get dist-upgrade?
<hyperactivecrond> and go to straight breezy?
<HiddenWolf> hyperactivecrond, yes, but the mirror is choked. :)
<Nafallo> well, I still can't see a good reason everything CC.archive.ubuntu.com would go to archive.ubuntu.com?
<Kamion> everything doesn't
<hyperactivecrond> won't work
<HiddenWolf> Nafallo, most of those xx.archive.u.c are redirects still. :(
<hyperactivecrond> but oh well... i'll try later
<Kamion> it's just there are only a few specific exceptions to the wildcard DNS
<Nafallo> Kamion: right... everything except se, cz, fr and de ;-)
<Kamion> sure
<dredg> *cough* and ie
<infinity> Is us.archive back again, or is it still broken?
<Kamion> the installer relies on CC.archive.ubuntu.com existing though
<infinity> (ie: still aimed at archive, cause the us mirror is unhappy)
<Kamion> infinity: still aimed at archive
<Nafallo> Kamion: so make all of europe use se. per default?
<Nafallo> Kamion: you get the idea...
<dredg> Nafallo: by all means contact mirror maintainers in various countries and ask them to be local .archive.u.c?
<Kamion> Nafallo: talk to admin about that ...
<infinity> All of europe, except uk, surely. :)
* Kamion doesn't control DNS
<Kamion> but yeah, gb == archive please ;)
<HiddenWolf> Or rather, start writing to ISP's
<Nafallo> dredg: is that the problem we're discussing? :-)
<Nafallo> dredg: or is that _everything_ falls back on archive... ;-)
<Nafallo> Kamion: elmo?
<Znarl> I maintain the mirrors.
<dredg> Nafallo: you can be a mirror without being cc.a.u.c
<Nafallo> dredg: yes, and the installer defaults to a.u.c instead of the most local server :-)
<Kamion> Nafallo: no it doesn't, it defaults to CC.a.u.c
<dredg> not in my experience
<Nafallo> Znarl: follow the discussion? :-)
<Kamion> Nafallo: remember that anything that's CC.a.u.c gets masses of traffic without people even realising it
<Nafallo> well I meant CC.a.u.c defaults to a.u.c
<Nafallo> that's what I know. and that's why not every single unassigned CC should go to a.u.c
<Kamion> every single unassigned CC *must* go to a.u.c
<Nafallo> why?
<dredg> erm, what?
<Kamion> there should be fewer unassigned CCs, but there *must* be a sensible default
<Kamion> and ultimately, the buck stops with a.u.c
<Nafallo> why can't everything unassigned in europa go to se.a.u.c?
<Kamion> that would be an assignment
<Kamion> it would no longer be unassigned
<dredg> it's also rude to force people onto a mirror
<HiddenWolf> unassigned + europe IP = se.u.c ?
<dholbach> mdke: do the ubuntu-docs guys have a launchpad team?
<infinity> If the mirror is known-good, it's hardly "forcing" anything.
<Nafallo> so why can't ever again change A records?
<Nafallo> s/why/we/
<dredg> depends on the mirror admin, doesn't it?
<Kamion> Nafallo: of course we can
<Kamion> the whole reason we use CC.a.u.c is for future flexibility
<infinity> dredg : Trust me on this one, maswan (the admin for se.archive) WANTS traffic. :)
<Nafallo> we still needs a sensible default now... we can't just swamp the most up-to-date mirror for every developer? :-)
<dredg> infinity: heanet WANT traffic too, but forcing someone to a mirror you're not responsible for is not a sane thing to do
<dredg> and besides, ip -> location is unreliable at best
<Nafallo> or atleast us motus that want to prepare stuff for dapper...
<Znarl> Nafallo : Yes, I'm following.
<Kamion> Nafallo: you're entirely free to pick the mirror of your choice. MOTUs surely to goodness have the wit to do that :)
<Nafallo> dredg: we could ask mirroradmins? some of them are on this channel ;-)
<dredg> Nafallo: which is what i already suggested
<Kamion> CC.archive.ubuntu.com is for users far more than it's for developers
<Nafallo> Kamion: well, developing with sync-delays sucks :-P
<Kamion> dredg: so that's why DNS changes are made with the consent of mirror admins
<dredg> cf. <dredg> Nafallo: by all means contact mirror maintainers in various countries and ask them to be local .archive.u.c?
<Nafallo> dredg: I was talking about being fallback for a continent... ;-)
<Kamion> Nafallo: can you ease up a bit?
<Kamion> you've made your point, I think :)
<dredg> Kamion: well, yeah. it's never good to wake up one morning and find you're suddenly serving half of europe because someone else decided it was a good idea
<Nafallo> Kamion: sure. I just want to see this point make a change :-)
<dredg> Nafallo: so contact some mirrors and ask them would they object to being cc.archive.ubuntu.com
<Znarl> A lot of mirrors contact us and request CC.archive pointed at them.
<dredg> Nafallo: myself and diamond asked heanet would they do it. they're now ie.archive.u.c
<Znarl> Mirrors help most countries that have poor international bandwidth by good national bandwidth.
<Nafallo> dredg: ofcourse, but my point now is unassigned stuff shouldn't swamp the datacenter till we get those local mirrors :-/.
<Znarl> Such as Thailand, Japan, China, etc.
<Nafallo> Znarl: agreed. but we still shouldn't send all the unassigned world to a.u.c ;-). better to find good mirrors as near as possible as fallbacks.
<dredg> this is getting boring real fast.
<Nafallo> as said, I hope I made my point...
<maswan> Znarl: do you have an estimate on how much of the DC traffic is isos vs packages?
<Znarl> maswan : No.
<doko> seb128, pitti: what is lp #2134 ? looks like crap ...
<maswan> hmm.. "Need to get 812MB of archives.", upgrades aren't without bandwidth use either, I guess. :)
<Kamion> doko: it's the standard problem with people not having universe/security in sources.list
<pitti> right
<infinity> Which isn't a bug in the least.
<Kamion> doko: so when packages have an = ${Source-Version} dependency crossing the main/universe boundary and the source package gets a security update, the version in universe they're seeing is out of date
<Kamion> infinity: it *was* a bug in base-config, but I fixed it
<doko> Kamion: ohh, but they did have the packages installed before
<infinity> Kamion : Ahh.
<Kamion> doko: right
<Kamion> however people who installed with warty and upgraded may still have the problem
<infinity> Still, tell the user to fix his sources.list, and you're on your merry way.
<Kamion> there's not a lot we can do in general
<pitti> doko: yes, from hoary, but not hoary-security
<Kamion> https://bugzilla.ubuntu.com/show_bug.cgi?id=3599, fixed in base-config 2.58ubuntu5
<Kamion> although since universe is disabled by default, people might still not remember to uncomment the security lines for universe when they uncomment the other lines for universe
<Kamion> again, not a lot we can do about that
<maswan> Kamion: make a small bit about it in the upgrade notes?
<maswan> Kamion: or perhaps that was already done in the hoary upgrade notes?
<Nafallo> does people read those? :-)
<maswan> "see the release notes for breezy" is better than "see bug #3599" when explaining
<Kamion> I think we did, although I don't remember
<Nafallo> indeed
<Nafallo> maybe we could some something like "you've downloaded the packagelist for universe, maybe you want to turn on universe security to?"
<maswan> Kamion: from a quick reading, it doesn't seem to be there.
<bddebian> Good morning oh Gods of Ubuntu
<pitti> Hi bddebian 
<bddebian> Hi pitti
<dholbach> :)
<bddebian> Heya Daniel
<bddebian> Wow, everyone taking it easy after all that work? :-)
<highvoltage> bddebian: apparently, some people are more Godly than others ;)
<pitti> bddebian: no 12+ hour shift today, private live needs some attention, too :-)
<bddebian> pitti: Nahh ;-)
<bddebian> highvoltage: Oh yeah? :-)
<highvoltage> bddebian: yep, according to the BddebianIsAGod wikipage :)
<bddebian> Well Stephan is just sick.  I'm a moron, just ask infinity, lamont, mdz, elmo, etc.  Or even pitti.  Ask him about me trying to package something.. :-)
<Kamion> oh dear, libarchive has a 64-bit-cleanliness bug that manifests while trying to extract DVDs
<jdub> JaneW: you are totally dominating the flickr ubuntu tag queue! :)
<jdub> s/queue/feed/
<bddebian> Heh
<JaneW> jdub: hehe (sorry) ;)
<jdub> nono, it's good :-)
<JaneW> jdub: just can believe edubuntu finally happened!
<jdub> :-) :-) :-)
<Treenaks> http://flickr.com/photos/13916877@N00/52389874/in/photostream/ -> cool
<JaneW> jdub: where is it tho? Saw it yesterday but today I see not flikr feed ?
<jdub> JaneW: that block shows random cool stuff
<jdub> JaneW: just reaload a few times :)
<Treenaks> jdub: I want a pony!
<maswan> JaneW: neat-looking cake
* jdub has to manualy update the flickr feeds atm
<JaneW> jdub: oic, I noticed it changed, but wasn't getting photos I'll try again...
<JaneW> maswan: thanks :)
<JaneW> jdub: only problem is now I have to censor the other pics I upload ;)
<bddebian> JaneW: What are you teaching those children?  Giving everyone the finger?? ;-)
<JaneW> case in point ^^^
<jdub> JaneW: this feed only gets 'ubuntu' tagged ones ;)
<pitti> infinity: you saw the warty-security php ftbfs?
<infinity> pitti : D'oh, need to clean those chroots.
<JaneW> bddebian: You referring to http://www.flickr.com/photos/13916877@N00/48973688/? or ^^^
<infinity> pitti : Stupid shtool in OTHER packages not cleaning up after itself.
<bddebian> JaneW: That one :-)
<bddebian> JaneW: Very cute kids btw :-)
<JaneW> bddebian: it was done in innocence honestly ;)
<JaneW> bddebian: thanks
<doko> jdub: please add a baking BOF for UBZ with JaneW as the lead ;-)
<infinity> pitti : All better.
<bddebian> doko: :-)
<JaneW> doko: LOL - get me access to the kitchen ;)
<doko> JaneW: no escape possible, I'll ask jbailey :-)
<JaneW> :)
<maswan> Making "enough cake for everybody" can be rather tiring, but people do seem to like it. :)
<Lathiat> that bfo woudl ahve to start a week early :)
<ogra> Lathiat, nope, the distro team can bake for the launchpad team...
<ogra> we just have to flip the schedule next time so they can do the same for us
<maswan> Lathiat: an aftersoon should be plenty of time, unless you want to do something really fancy
<jdub> doko: haha
<jbailey> ogra: OOoo..  I can make a decent vegan cake ;)
<ogra> :)
<jdub> jbailey: YAY! free range grain fed vegan cake!!!
* bddebian makes MEATcake ;-P
<jbailey> Free range.
<jbailey> ..
<jbailey> Is that like apie throwing contest? =)
<jbailey> I could be up for that at UBZ.
<bddebian> jbailey: BTW, ignore anything ajmitch tells you at UBZ ;-P
<spacey_ki> :] 
<jbailey> bddebian: Hmm
<jbailey> bddebian: It might be hard to sign his key then...
<bddebian> jbailey: I mean anything he says about me. ;-)
<jbailey> bddebian: Oh? =)
<Kamion> ah, fixed libarchive
<nomed> hi all
<infinity> pitti : All builds are in.
<jbailey> bddebian: Does it involve goats?
<nomed> is there a chan for xubuntu ?
<bddebian> Hello nomed
<bddebian> jbailey: Heh, no, nothing that exciting. :-)  He will probably just chastise you for pointing me at the MOTUs :-)
<JaneW> jbailey: arrrgh Indian Dinner (Goat curry!)
<bddebian> eww
<nomed> i've had some problems using xine based players .. installing breezy from "debootstrap"
<nomed> that didn't happened from install cd
<jbailey> JaneW: I've never tried a meat curry.  I didn't discover indian until I went veggie.
<nomed> i would try to figure out what's the problem
<jbailey> bddebian: And why would he do that?
<bddebian> jbailey: Because I'm a PITA? :-)
<jbailey> Unhuh, sure.  And that's why they've got the "Barry is a God" page on the wiki? =)
<dieman> http://www.theinquirer.net/?article=26935 <-- "Dumber people can run Linux"
<dieman> review of ubuntu on theinq
<Diziet> We seem to fail to provide our users with any pointyclicky way to back up their data.
<dieman> one of my friends setup a backup system that was fairly simple i think
<infinity> Diziet : That was worked on as a Summer of Code project, and I hope to coax my stdent into polishing up his submission for dapper.
<jbailey> Backup solutions under Linux tend to suck at the best of times.
<dieman> yeah, hes using backuppc
<dieman> (backuppc.sf.net)
<infinity> Diziet : Try 'sbackup' and file a zillion bugs on it in the Debian BTS for things you find less than satisfactory.
<infinity> Diziet : He's rather responsive.
<Diziet> backuppc> `BackupPC is a high-performance, enterprise-grade system for backing up Linux and WinXX PCs and laptops to a server's disk' so not what individual users probably need then.
<dieman> yeah, sounds like overkill 
<dieman> still
<bddebian> jbailey: That's just crackful \sh :-)
<jbailey> Mmm.  crack
<dieman> "No client-side software is needed."
<dieman> thats nice
<Diziet> No, not overkill, inapplicable.  What's a user to do if they have one home PC and no server to back up to ?
<dieman> it can backup the local machine, too.
<Diziet> To another server ?
<Diziet> sbackup> Reading now.
<mjg59> http://www.hilmix-shop.de/lshop,showdetail,30454,d,1129065715-30673,1106739778,uc374ge-linux,,Tshowrub--1106739778,.htm
<mjg59> Rocking
<dieman> still, the inerface doesn't look simple
<dieman> damn, i might setup this ting at work
<dieman> thing, rather
<Diziet> Backup with free software is fine if you're like me.  Tape drive, central backup server, tapes, scripts to glue it all together, etc.
<Diziet> Aww, how cute.  I've just seen the icon Nautilus gives to corefiles.  Shiny bombs.
<Diziet> They are, of course, corefiles from Nautilus.
<infinity> mjg59 : Dude, it lists a glxgears score.
<infinity> mjg59 : Also, that's basically identical to the hardware I'm using that refuses to suspend-to-disk. :/
<mjg59> Well, other than that
<infinity> mjg59 : I need to reinstall and see if it's something really wonky going on here.
<infinity> (I only note that because they claim it can suspend-to-disk)
* infinity heads off for a rousing round of sleep and weekending.
<Diziet> sbackup> Hmm.  If I'm not mistaken this program doesn't seem to be capable of doing what I would think of as a backup.
<Diziet> That is, copying the data OFF YOUR COMPUTER.
<infinity> Diziet : Getting it onto CDs is the ultimate goal for that, I believe.
<Diziet> The user might have removeable USB drives or even removeable IDE drives or some such.
<infinity> Diziet : Currently, it allows you to slap it on anything gnome-vfs can get to (which includes removable media), and sftp/ssh/ftp.
<Diziet> Also, it's clearly not finished.
<infinity> But yes, clearly not finished.  Hence why I said "file a bunch of bugs"
<Diziet> `The backup is running in the background; its pid is 12345.   [X]  Close'
<infinity> It's working.  It's just not polished.
<Diziet> The default filenames aren't 8.3 so it won't work with a FAT removeable.
<Diziet> And it should be like update-manager and prompt you to back up rather than hoping you'll do it.
* infinity points Diziet at http://bugs.debian.org/src:sbackup
<infinity> Your pedantry is exactly what's needed to get Aigars to polish this up to something shiny.
<Diziet> infinity: Thank you for your vote of confidence.  I'm looking at the bug reports now.
<Diziet> So should I file my bugs in the Debian BTS despite the fact that all of my tests etc. are on Ubuntu ?
<Diziet> Just to check, so I don't tread on anyone's toes.
<infinity> Diziet : Well, if they get filed in Ubuntu, we'll just have to forward them upstream anyway, so just send them there to start with. :)
<jbailey> Diziet: It really depends on the maintainer.
<infinity> Diziet : Besides, the upstream maintainer is an Ubuntu user, so he won't mind in the least.
<Diziet> jbailey: Yes, I know, that's why I'm asking in this specific case.
<Diziet> infinity: Right, thanks.
<infinity> (He wrote this as a participant in Google's Summer of Code under Ubuntu's guidance)
<Diziet> I just wanted to double-check because there seems to be plenty of room for misunderstanding.
<Diziet> And errors in these kinds of areas tend to cause offence.
<infinity> For future reference, anything I maintain in Ubuntu/Debian, I prefer the bug reports in the Debian BTS, unless it's Ubuntu-specific.
<dholbach> he could be added as a default-qa-contact in bugzilla
<infinity> Diziet : Here's his spec: https://wiki.ubuntu.com/SimpleBackupSolution
<Diziet> infinity: Ta.
<infinity> dholbach : s/bugzilla/Malone/ .. sbackup is in universe currently, waiting on more polish before I try to get it in the desktop.
<infinity> dholbach : It definitely wasn't ready for breezy, IMO, but has potential.
<dholbach> yeah
<infinity> Diziet : Oh, and try not to file a bug titled "Pls rewrite in C, kthxbye", as much as that would be fun. :)
<ikmo> Hi all, is there any of the art team in here please?
<infinity> Python seems an appropriate hammer for this nail anyway, though he needs to profile his code something fierce.
<jbailey> infinity: You need to write something that impots your Bugzilla bugs into the BTS ;)
<infinity> Yeah... I'll call it.. An MUA.
<infinity> It'll revolutionise the software world.
<infinity> Every time I hit "reply" on a bugzilla email and start typing, I scream 5 seconds later when I remember I can't do that.
<infinity> Which leads me to wondering if bradb has finished writing a debbugs-like mail interface for Malone.
<infinity> I believe we had that on our feature list for main adoption. :)
<infinity> (originally... I'm sure it got scrapped as a "nice-to-have, 2.0 feature" later)
* Kamion rediscovers comm(1), and wonders if he'll ever remember how its command-line options work without looking them up every time.
* infinity uses comm(1) all the time.
<infinity> great for comparing installed package lists.
<Kamion> I want its opposite, so that rather than having to remember comm -13 you can say notcomm -2
<Kamion> or something like that
<Kamion> $ for x in `comm -13 dvd-i386.list dvd-powerpc.list`; do cp -a dvd-powerpc/$x dvd-i386/$x; done
<mjg59> Any Germans around?
<pitti> mjg59: me
<ogra> mjg59, nope
<mjg59> pitti: Have you ever heard of hilmix?
* pitti blames ogra of abandoning his home country
<pitti> mjg59: that does not ring anything
<mjg59> Ah, ok
<mjg59> Just wondering how well known these people are...
<ogra> mjg59, nope, never heard of it...
<ogra> what is it ? 
<mjg59> A company selling Breezy Thinkpads
<ogra> ah, they ship IBM laptops
<Robot101> wow
<Robot101> do they have no windows tax?
<ogra> they claim to be SuSE business member on their page, no trace of ubuntu
<mjg59> ogra: hilmix-shop.de
<ogra> yes, thats where i looked
<mjg59> ogra: Under the "linux" section
<ogra> heh...
<mjg59> Robot101: The Linux one seems to be, uhm, 700 Euros cheaper.
<mjg59> !
<ogra> on the top it says "soon to come" and the site is to long to show the laptop at the bottom
<ogra> well hidden :)
<mjg59> Compare http://www.hilmix-shop.de/lshop,showdetail,11223,d,1129301701-11237,1106739778,uc374ge-linux,,Tshowrub--1106739778,.htm and http://www.hilmix-shop.de/lshop,showdetail,11223,d,1129301763-11427,1105901351.1106566918.1106834035.1106843071,uc374ge,,Tshowrub--1105901351.1106566918.1106834035.1106843071,.htm
<Robot101> robtaylor: here
<Diziet> Blimey, what a huge price difference.  They say `special price' - is that some kind of novelty discount marketing thing that we couldn't expect to persist ?
<mjg59> Diziet: They both say "special price" - I'm not sure why
<ogra> mjg59, dont show that page to daniels :) 
<Diziet> Oh, so they do.  Maybe it's just to make you think they're cheap.
<ogra> glxgears:
<ogra> 650.000 fps
<ogra> (from the feature list)
<Diziet> mjg59's URLs: http://tinyurl.com/acwnh and http://tinyurl.com/cg9z7.
<mjg59> ogra: Yeah
<sivang> rehi all
<sivang> pitti: where is ogra living these days? is he not in .de anymore ? :)
<pitti> sivang: he is in .de, don't worry :)
<sivang> pitti: he's living in a region called eifel right? 
<pitti> sivang: yes
<mpt> infinity: Malone has had an e-mail interface for months now
<infinity> mpt : Does it work?
<mpt> People are using it
<mpt> so yeah, it seems to
<infinity> mpt : (no, I've never tried it, as I had no idea there was one, I just click the link the mails sent to me)
<infinity> Is it documented?
<Lathiat> yeh i foudn some yesterday
<mpt> infinity: https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
<mxpxpod> pitti: ping
<pitti> Hi mxpxpod 
<sivang> pitti: anyway, do you want to start specing the BOF on CupsDbusIntegration sometime? I will be available most of this week, also working on some ideas of my own (SetupSnapshots) 
<infinity> Ouch.  That is not an intuitive interface.  And a lot of typing. :/
<infinity> Oh well.  I guess asking for something that worked like debbugs was too much.
<mxpxpod> pitti: so, I still have no clue about that corrupt double linked list
<mpt> infinity: Where is the debbugs e-mail interface documented?
<pitti> sivang: can you please ping me about it next week?
<Kamion> mpt: there are already links to the debbugs documentation from various Malone specifications
<Kamion> e.g. https://wiki.launchpad.canonical.com/MaloneEmailInterface
<pitti> mpt: http://www.debian.org/Bugs/server-control
<infinity> http://www.debian.org/Bugs/ -- specifically the two "Developers' information" links.
<sivang> pitti: ofcourse, I understand that you are still busy  with security? 
<pitti> sivang: I want to do some private stuff this evening
<pitti> sivang: RL needs some attention after the last week :-)
<sivang> pitti: RL  ? :-)
<pitti> sivang: real life
<infinity> Woo, the two archive.ubuntu.com machines are out of sync.
<sivang> pitti: ah sure! I didn't think otherwise, nor am I in rush, whatever we don't finish before UBZ I'm sure we can find time over UBZ
<sivang> pitti: have fun!
* infinity has fun with round-dobin DNS, trying to get the machine that actually has the new openssl on it.
<sivang> infinity: lol
<infinity> Oh, s/two/four/... When did we get two new archive.u.c frontends?
<infinity> No doubt one (or both) of the new ones is what's out of sync.
<apokryphos> out of interest, are there any stats on bandwidth usage/torrent-activity so far? 
<sivang> mvo: ping, around ?
<mxpxpod> pitti: how do I get a tree of dependencies for packages that are installed?
<mvo> sivang: pong
<pitti> mxpxpod: apt-get dotty?
<pitti> mxpxpod: erm, apt-cache dotty
<sivang> mvo: any news from other users about those gnome-terminal crashes?
<mvo> sivang: no, it dosn't happen with the revert lpi change and I haven't looked closer again yet
<mxpxpod> pitti: thanks
<sivang> hmm, so are we now using only malone with dapper starts?
* Diziet files pie-in-the-sky bugs against sbackup.
<Kamion> -rw-rw-r--  1 cjwatson warthogs 5079379968 Oct 14 16:48 ubuntu-5.10-dvd-i386-powerpc.iso
<Kamion> sigh, over the DVD+RW limit
<pitti> ouch
<Diziet> *laugh*  Oh dear, we're outdoing ourselves.
<pitti> hoary's was 2.8G
<Kamion> note that this is i386+powerpc, not just one architecture
<Kamion> as the filename should indicate :-)
<pitti> ah, ok
<Kamion> there's a saving of about 1GB from common .debs
<sivang> mvo: what do you think about http://bugzilla.ubuntu.com/show_bug.cgi?id=14472 ? Maybe that's worth discussing over UBZ , are you interested in possibly specing this as a one click interface to nationalizing Ubuntu installations? (I think it has potential)
<mpt> thanks pitti, Kamion
<Kamion> I can make it fit easily by stripping out the powerpc live filesystem, though.
<zyga> sivang: I second that
<sivang> zyga: I just thinkg mvo's language-selector couldn't be more suitable to catch a ride on, and I get these demand from my LoCo community memebrs all the time  :)
<mvo> sivang: probably, yes. the suggestion came a bit too late for breezy but it's worth considering for dapper. patches are welcome of course :)
<zyga> sivang, mvo: maybe a less textual interface (after all - you are running this to get the right language in the first place) would be better too
<zyga> like flags or world map with several zoom levels (like the timezone applet)
<zyga> but flags are kind of messy when it comes to places like taiwan or tibet :/
<Kamion> flags and world maps are dangerous
<Kamion> developers have been imprisoned for that
<zyga> Kamion: yes :/
<Kamion> (seriously)
<mvo> zyga: at UBU I suggested a map, but it was considered polictically problemeatic
<zyga> mvo: how about a map without the boundaries?
<Kamion> maps without borders (only city locations) aren't too bad
<Kamion> you have to stay well clear of borders though
<zyga> Kamion: maybe like this
<zyga> you click on a place
<zyga> and the GUI pops up 5 nearest capital cities
<zyga> asking which one you associate with
<zyga> that could work
<Kamion> is Taipei a capital city?
<infinity> I'm not sure how important this is, since the user (or an OEM) already had to install the system to this point, and presumably in a language that the user understands a little bit.
<zyga> infinity: how about auto starting this on first login
<minghua> Kamion: well you can always put both capitals and non-capitals on the map
<zyga> that would be easy and usefull
<Kamion> for languages, surely it's easier to just list the language name in its own language
<infinity> Kamion : Exactly, as the installer already does.
<infinity> No reason why the language selector can't too.
<Kamion> languages don't have a good correspondence to countries in many cases anyway
<zyga> true, the installer does this already
<zyga> did anyone think about something speciall to happen on first login anyway?
<infinity> mvo : We can yank the English -> Native language mappings from d-i and use that with a nice UTF-8 font in Language Selector, surely?
<infinity> (or maybe a few fonts, if we don't have one with all the right glyphs)
<sivang> mvo: Just let a user choose a language, let politicians deal with maps :) But after he choose a lanugage, the selector installes the required lang pack or whatever, asks if he wants nationalized menus, and autoconfigures (maybe this can be done in prebuilt gnome kbd selectors packages per each language) 
<infinity> There must be one font with enough glyphs to support printing all the language NAMES, though, even if they're not generally useful fonts. :)
<sivang> mvo: gnome kbd selector with some sane shift group behaviro
<sivang> does anybody get the OSDL survey? I don't really get their intention..
<infinity> zyga : First login popups are dicussed every 2 days, when someone else decides there's something we MUST show new users, which is exactly why we don't have one.  If we did, it would have 400 things in it, and be useless and annoying.
<zyga> infinity: maybe an installer option for OEM stuff that allows to autorun a tutorial or guide
<zyga> then 1) it's not mandatory 2) it's usefull
<infinity> Allowing OEMs to force irritation on THEIR users is always an option, I suppose, but the Ubuntu default install will probabl never do it.
<sivang> infinity: they should probably be limited to (1) register against the distro's supportive infrastructure (which takes care of identification) , (2) nationalization.
<zyga> infinity: default install probably doesn't need it
<zyga> infinity: if someone is installing ubuntu [s] he probably already knows enough
<mvo> infinity: I except so, yes
<mvo> s/except/expect/
<sivang> it's just that I've seen already a couple of "nationalized" derivaties that all they do is exactly that, I am thinking to streamline this and standartize through a one-click to have Ubuntu localized to your favorite language.
<infinity> I do like the idea of having it automagically configure keyboard stuff for you.  Though we need a sane way to turn that behaviour off again, if it's not what you want.
<mvo> sivang: the only problem I can see is how language-selector (runing as root) can do stuff in the users session. OTOH, I would like to do a proper split anyway so that only the backends runs as root ...
<infinity> But this is pretty much what Windows does, and I do find it useful on my girlfriend's English+Japanese+French desktop.
<infinity> I also need to play with Japanese input in the next week, and make sure we have something sane working for dapper.  It still seems a bit of a mess in breezy.
<minghua> what if some language requires additional packages?
<infinity> I'll never get my girlfriend to switch without getting that sort of thing more friendly.
<minghua> like CJK, they likely will need input methods instead of just keyboard mappings
<infinity> minghua : Then the l-s backend installs the packages, while the l-s frontend configures your session.  That's the point of mvo splitting it.
<sivang> mvo: ah , so it would be able to modify only root's gnome kbd settings and not those of the user ?
<infinity> Yes, they'll want scim and such.
<infinity> mvo : Looks like the split would be a Good Thing to do as soon as you find a round tuit. :)
<minghua> infinity: if we can achieve that, it would be really nice
<infinity> Agreed.
<mvo> sivang: yes, that's the problem currently
<infinity> minghua : Which CJK language(s) do you use?
<minghua> infinity: Chinese (zh_CN)
<infinity> minghua : I can use/test Japanese, but have no one to attempt any others.
<infinity> minghua : Perfect.
* minghua is the scim maintainer in debian :-)
<mvo> infinity: I'm currently pondering how to do it cleanly
<infinity> minghua : I'll try to remember your IRC nick when I start fiddling with input method automation.
<infinity> minghua : Ahh, that'll make it easier to remember who you are. ;)
<hunger> ls -alF
<hunger> aehm... sorry for that...
<sivang> mvo: I see, what's the backend written in / using ? python-apt ?
<minghua> infinity: sure, I would be really happy to get involved in such a project
<minghua> I can do the package selection/classification and testing part, but I don't know much about coding
<infinity> minghua : I've only played with CJK input methods once, about a month ago, and decided they were a terrible mess, and no one but a complete nerd/geek would ever be able to configure them.  So, we definitely need to do something. :)
<minghua> infinity: yeah, I'm afraid so.  Using CJK in ubuntu is currently quite painful
<mdke> jdub, if you're still around before going to GLlug, I'd love it if I could blog about the new italian website on planet, please add me!
<infinity> minghua : Well, it's also something I'm reasonably passionate about fixing, so here's hoping I find some time in dapper.
* zyga grabs some food, later
<minghua> infinity: Great.  Now I'm working on getting scim stuff sorted out in Debian, once that is finished I'll take a more serious look in dapper development
<minghua> infinity: maybe writing a summary about input methods and send to mailing list or something
<infinity> minghua : Any input (pun possibly intended) you can provide on the topic will be helpful.
<sivang> infinity: LOL
<infinity> minghua : As I said, I can only really test Japanese, and I know that input methods of choice seem to vary wildly according to the target language, etc.
<sivang> mvo: anyway, if you run a BOF I'm interested in providing all the help that I can give. (if I start a spec suggestion, I'll email you)
<minghua> Oh by the way, as we are talking about fonts for displaying language names, d-i is having the same problem with their gtk frontend, and they use like 10 vector fonts: http://lists.debian.org/debian-boot/2005/10/msg00381.html
<mvo> sivang: thanks
<jdub> mdke: i'll get elmo to update it
<jdub> update from the baz branch
<mdke> jdub, he says he can't do it
<mdke> jdub, only you can!
<minghua> infinity: yes, the root of the problem, is that there are many input methods even in a single language
<jdub> i change the source
<jdub> he updates the installation
<jdub> we're fixing this
<mdke> jdub, ah awesome merci
<minghua> infinity: so for each input methods there is likely going to be a separate program
<infinity> minghua : Right, but unlike Debian, Ubuntu isn't as much about choice as it is about picking sane defaults, so we need to try to figure out what's the "best" for each language (where "best" means "doesn't segfault all the time", "easy interface", whatever)
<minghua> infinity: no, that's not really possible, as one user may only know one input method of his/her language
<infinity> Hrm.  Well, we'll have to discuss and play a bit, I suspect.
<minghua> infinity: there are programs that covers quite a few input methods, like scim and uim
<infinity> Right.
<infinity> Which is what we need.  To pull everything under one roof, and try to give it a consistent interface.
<minghua> infinity: but still some users find the input method in it inferior, and prefer their own program
<minghua> infinity: yeah, I think that's the way to go
<infinity> Again, I'm reminded of the Windows input methods, which may be drastically different (there are 3 or 4 for Japanese) but are all configured form the same place, activated from the same toolbar, etc.
<infinity> users who prefer other things are too advanced to be my target audience.  They can go find and install other stuff from universe if they prefer it.
<infinity> We need "sane defaults" for the average user.
<minghua> infinity: and that's the reason I think I need to write a summary, so that other developers who don't use CJK can understand the situation
<Yagisan> infinity, minghua - where would one find the info to setup CJK on breezy ?
<trulux> morning fellows
* jdub growls at mgp
<minghua> Yagisan: I think the unofficial guide has something for hoary, and it _should_ work for breezy, let me see
<minghua> Yagisan: http://www.ubuntuguide.org/#scim is some instruction about scim, but not that great
<minghua> Yagisan: I remeber seeing something on wiki as well
<Yagisan> minghua: thanks - I was looking for some instructions on how to get Japanese input going
<minghua> Yagisan: https://wiki.ubuntu.com/JapaneseInputHowToInBreezy?highlight=%28japanese%29
<minghua> Yagisan: there you go :-)
<Yagisan> minghua: I'd have thought installing the language packs would have brought input as well
<minghua> Yagisan: no, it doesn't work like that (yet)
<minghua> Yagisan: and we are talking of improving the situation
<Yagisan> minghua: thanks, I can make my wife happy now
<trulux> pitti: ping
<jdub> anhyone know of a good photo of dholbach?
<tseng> maybe
<trulux> jdub: preparing a WANTED DEAD OR ALIVE announcement for him?
<tseng> i need a few moments to dig it out
<jdub> 'face of motu'
<bddebian> hehe
<trulux> heh
<trulux> I hope pitti gets around soon
<tseng> jdub: i have one in mind, i need a few minutes to recover it
<jdub> okay
<jdub> i have one
<jdub> a sneaky bugger snuck one to me off-channel
<dholbach> jdub: what are you up to? :)
<jbailey> jdub: Preparing the April 1 artwork already? =)
<tseng> jdub: here it comes
<tseng> jdub: http://tseng.ath.cx/img-106.jpg
<dholbach> tseng: i just had a look at your pictures: 99.jpg doesnt look THAT stupid :)
<tseng> hah neither looks stupid
* dholbach loved to know what jdub was doing...
<sivang> tseng: whose that?
<sivang> dholbach: probably something nice for the fridge :)
<tseng> sivang: me
<tseng> sivang: arent i cute?
<dholbach> haha :)
<sivang> tseng: ah, plesae to meet you in person then, Brandon :)
<tseng> indeed
<mvo> I'm still for http://gplan.info/blog/hackergotchi.png
<sivang> tseng: I'de send you a link for a pic of mine, if I wasn't looking so bad :)
<trulux> jdub: any idea on why I'm not getting the messages sent to ubuntu-hardened? I look at myself and feel a bit stupid as of my continuous need of reading the web archives for new messages
<tseng> sivang: thats really daniel
<trulux> no mention to the pain of replying also
<jbailey> I should probably make a hackergotchi one day.
* dholbach likes the one for mvo
<tseng> jdub: with hair cascading down intot he next persons post
<dholbach> mvo: you should start blogging, seriously
* jbailey puts it on the TODO list somewhere after "Finish the Hurd"
<tseng> er, that was for ^ jbailey 
<dholbach> haha
<bddebian> jbailey: w00t
<mdke> how does one make a hackergotchi?
<jbailey> tseng: =)
<mdke> is there some kind of easy guide?
<jbailey> mdke: First one slices off one's head, and puts it on a scanner...
* mdke nods wisely
<mvo> jbailey: that would right next to "sign my key" ;) ?
<bddebian> heh
<mdke> jbailey, ok brb just going to do that
<jbailey> mvo: Yeah, I'll be better about that for UBZ.  I'll actually remember most people there.
* jbailey always loves it when people say "But you *have* met me more than once" and my answer can only be "Err.. Really?"
* bddebian REALLY wishes he was going :(
<dholbach> mdke: http://www.livejournal.com/users/wouterverhelst/21322.html
<mdke> too late for that, I've already sliced off my head
<mdke> might as well use jbailey 's method
<mdke> (ty dholbach, bookmarked)
<jbailey> That's the spirit!
<jbailey> POssibly literally...
<zenrox> question when will the dapperdrake-changes email list be avaible??
<sivang> LOL
<sivang> zenrox: things for dapper start on tuesday, as noted in mdz's email
<sivang> zenrox: so probably sometime around there :)
<zenrox> ok
<zenrox> that will work
<zenrox> hehehe
<zenrox> i like watchen the devel process
<zenrox> and might as well fill up my gmail
<dholbach> zenrox: being involved and reading your name on dapper-changes would rock even more, right? what do you think about it? :)
<sivang> zenrox: you could join the MOTU team and make Dapper's universe expand even more :)
<dholbach> sivang: you too :)
<sivang> dholbach: I know ;-)
<dholbach> dapper is YOUR release :)
<sivang> dholbach: Is this a hint ? ;-)
<zenrox> i know  and i am going to try to provide better bookmarks for dapper
<dholbach> yeah... i hope you get cracking with us :)
<dholbach> zenrox: what about fixing packages? :)
* dholbach invites zenrox to #ubuntu-motu :)
<zenrox> dholbach, dont have the skills for that
<sivang> dholbach: I really do plan to crack with you guys on MOTU, as well as try to squeeze my other wish goals for dapper (see them on the BOFs list) :-)
<dholbach> *nod*
<bddebian> You do plan to do crack with us? :-)
<dholbach> . o O { oooohh yeah... crack }
<pef> dholbach: hello Daniel
<dholbach> hey pef
<dholbach> how are you?
<sivang> bddebian: heheh
<bddebian> Heya pef
<bddebian> Oh
<sivang> well, I've went to prepare some pasta and sauce. laterz all
<Mitario> jdub, when were you coming to holland again?
<dholbach> Mitario: on Treenaks' birthday :)
<Mitario> heh which is? (a)
<dholbach> 18th-19th
<dholbach> or rather 17th-20th
<Mitario> yeah oscon
<Treenaks> dholbach: oh you're coming too? :) cool
* Mitario thought we had some 'We are Jeff fanboys!' fanclub meeting ;)
<Treenaks> dholbach: wait, /me learns to read
<dholbach> don't worry :)
<dholbach> i learnt it lately as well
<Kamion> have a good weekend, folks
<dholbach> Kamion: you too, enjoy it! :)
<mvo> enjoy Kamion 
<Kamion> thanks
<dieman> nice
<dieman> the mirror here is at 80% iowait
<hmrocha> hello, i'm having a big trouble trying to set up two applications for a teacher
<hmrocha> he needs wavesurfer and transcriber
<hmrocha> but both hang because of the sound
<hmrocha> i straced wavesurfer and it hangs opening /dev/dsp
<hmrocha> do you know what can i do?
<hmrocha> i straced transcriber too but it simply quits instead of opening a tcl/tk window
<hmrocha> it's also a sound application
<hmrocha> what could make an app hang opening /dev/dsp?
<hmrocha> in hoary btw
<sebest__> hmrocha: if /dev/dsp is already opened by another process
<sebest__> it's certainly the case, maybe esd is already using it
<hmrocha> hmmm, how can i stop esd then?
<sebest__> stopping esd is not the best solution
<sebest__> the best solution is to make your app use esd
<hmrocha> sebest__, thanks very very much
<hmrocha> it worked
<Kinnison> ciao all
<hmrocha> if you were heidi klum i would marry you
<sebest__> ;)
<hmrocha> i have been the whole afternoon around this
<hmrocha> killall esd worked
<sebest__> there is a tool that allow your app to use esd
<sebest__> yes but if you kill esd you don't have sound in gnome anymore
<hmrocha> that's bad
<hmrocha> i thought gnome used alsa
<sebest__> do you have esddsp installed?
<sebest__> it's a wrapper
<sebest__> you use it like this:
<sebest__> esddsp myapp
<sebest__> and "myapp" will you use esd instead of trying to open /dev/dsp directly
<hmrocha> ok, i'll try
<sebest__> it may be in esound-clients
<hmrocha> brb (it's not in this computer)
<sebest__> yes it is
<hmrocha> sebest__, the app starts, but i can't record any sound :(
<hmrocha> i'll try killing esd and trying to record my voice
<hmrocha> it worked killing esd
<hmrocha> but now with esddsp :(
<sebest__> hmrocha,  you could try with the "-m" option
<hmrocha> but not...
<hmrocha> didn't work
<hmrocha> now strace shows that it hangs when reading a socket in /tmp/.esd/socket
<sebest__> you started esd as root?
<hmrocha> no
<hmrocha> hmm, yes, i did "sudo"
<sebest__> you shouldn't
<hmrocha> ok
<sebest__> you should have /tmp/.esd-$uid/
<sebest__> where $uid may be 1000 or 1001 or...
<sebest__> depends on your uid
<sebest__> and a "socket" file in this folder
<hmrocha> i needed to change the default uid for the installation user from 1000 to 500
<hmrocha> i don't have a /tmp/.esd-$uid
<hmrocha> only .esd
<hmrocha> i'll try deleting all /tmp
<hmrocha> brb
<sebest__> maybe the .esd-$uid is a bug fixed in breezy to allow multi user
<hmrocha> sebest__, i need to reboot the system to work in a fresh install (we use an image deploying system)
<sebest__> oki
<hmrocha> i'll have to convince my boss to install breezy
<sebest__> i don't know if i'll be still around at this time :)
<sebest__> should work with hoary i think
<sebest__> the problem is that you started esd as root, so the file belongs to root
<sebest__> and your user couldn't connect to the socket
<sebest__> i think that chown would have fixed the problem
<hmrocha> i hope this works, the teacher needs to start classes but he can't because he doesn't have this programs working
<sebest__> in the worst case, you can make a script that stop esd , lauch the app, and restart esd when you shudown the app
<hmrocha> hmm, that should work, yes
<hmrocha> instead of running from the command line, i could create an icon in Apps->Sound
<sebest__> yes
<hmrocha> i like the way you think :)
<hmrocha> i'll try what you said in a moment, don't run away please, i'll brb
<sebest__> oki :)
<sebest__> btw, as you seem to like strace, you should also have a look at lsof, because it could tell you which process is using a specific file (namely /dev/dsp in our case)
<hmrocha> the script is not working well, but i'll try changing some things
<hmrocha> but killing esd makes the app work fine
<sebest__> kill `pidof esd`
<sebest__> this should stop esd
<hmrocha> i did "killall esd"
<hmrocha> but that "pidof" is cool :)
<dholbach> :)
<sebest__> it 's similar to killall i think :)
<sebest__> /bin/pidof -> ../sbin/killall5
<sebest__> hi dholbach
<dholbach> hey sebest__, how are you?
<sebest__> i'm fine, still working on porting avahi :)
<sebest__> and you?
<hmrocha> sebest__, i'll tell the teacher that if the program doesn't work, he needs to run the "kill pidof esd"
<hmrocha> sebest__, but i'll do the script anyway
<hmrocha> thanks very very very much for the help
<sebest__> hmrocha, the script is 3 lines :)
<sebest__> you 're welcome!
<hmrocha> kill `pidof esd` ; wavesurfer &; esd &
<hmrocha> that's what i did (in the 3 lines)
<sebest__> hmrocha, you may add a sleep
<hmrocha> between kill and wave ?
<sebest__> and use "&&" instead of ";"
<sebest__> yes
<hmrocha> i didn't use ; i placed them in seperate lines
<sebest__> kill `pidof esd` && sleep 1 &&  wavesurfer &
<sebest__> and you shoudn't put a "&" after wavesurfer
<sebest__> because it will work in background and that's not what we want
<sebest__> kill `pidof esd` && sleep 1 &&  wavesurfer && esd &
<sebest__> so it won't start esd until wavesurfer quit
<dholbach> seb128: i'm fine too, a bit tired, but i'll be off to a party soon :)
<hmrocha> it worked, i love you
<hmrocha> :D
<dholbach> UBUNTU LOVE! :)
* hmrocha is happy
<hmrocha> may ubuntu be with you!
<sebest__> dholbach; ah , in germany? :)
<sebest__> hmrocha ;)
<hmrocha> the teacher will be very happy too
<dholbach> sebest__: yes, berlin :)
<sebest__> damn, i must look for one in paris!*
<dholbach> :)
<sebest__> i'll first go back home to have some rest and eat something!
<dholbach> :)
<sebest__> hmrocha, dholbach, c ya later and have a nice ubuntu love party ;)
<hmrocha> sebest__, :D
<hmrocha> sebest__, bye, have a nice weekend
<sebest__> thanx!
<dholbach> sebest__: it's not actually a ubuntu party, but i'll try to make it so
<dholbach> have a good time folks!
<mantiena> mdz, Hi
<mantiena> mdz, maybe you have some time to talk about ubuntu-express ?
<mdz> mantiena: some, yes
<mantiena> mdz, as I understand most ubuntu-express work is done by javier.carranza@interactors.coop, right ?
<mantiena> what are plans for ubuntu-express ? I'm main developer of custom ubuntu-based distribution for Lithuania and other Baltic states - this distribution is installable live-cd and we currently use graphical Morphixinstaller and text mode https://launchpad.net/products/live-installer 
<mdz> mantiena: interactors have produced an implementation of ubuntu-express, yes.  I have not actually experimented with it yet
<mantiena> mdz, I wanna replace Morphixinstaller with ubuntu-express, but it seems in current situation ubuntu-express 0.92 (from http://interactors.coop/~trunks/installer/ ) has too many usability and other problems
<mantiena> I can improve ubuntu-express 0.92 (I have some experience with python), but in current situation it's not comfortable to work together on sources, because last ubuntu-express sources are somewhere at interactors.coop svn
<rob^^^> it's been my experience over and over that noone knows what hostname is for
<rob^^^> and quite a few semi-knowledable users think its something you have to ask a network administrator for
<mdz> mantiena: if ubuntu-express is to be incorporated into Ubuntu proper, it will be imported into bazaar and we'll work out any usability issues
<mantiena> mdz, what you think about adding ubuntu-express to https://launchpad.net/products and importing latest sources from interactors svn to Bazaar ? I'm already registered on launchpad.net and submited my GPG Key
<mdz> mantiena: but I need some time to review it and determine the best approach
<mantiena> I can add ubuntu-express to https://launchpad.net/products if you don't have free time
<mdz> mantiena: time is never free ;-)
<mantiena> mdz, so, you agree, that I will register ubuntu-express on https://launchpad.net/products/ ?
<lifeless> mdz: we'll happy do the trunk conversion for you
<andred> Can Ubuntu really safely include libmad0 in main? Then why not include gstreamer0.8-mad too:-)
<mantiena> yea ;)
<andred> Because I noticed that libmad0 is in main, but not gstreamer0.8-mad.
<mantiena> andred, I think ubuntu developers simply don't want to let users to use proprietary audio/video formats
<Riddell> andred: libmad is a build-depend of various things in main
<Riddell> mantiena: that's not the case
<mantiena> Riddell, then why ?
<Riddell> mantiena: legal restrictions
<mdz> mantiena: don't be ridiculous
<mantiena> mdz, ?
<mdz> mantiena: ubuntu developers are working very hard to provide value for users
<mdz> mantiena: it's insulting to say that we are deliberately making something difficult
<mantiena> mdz, I just tell what other users say
<mantiena> mdz, for me it's no problem
<andred> Riddell, But still, if mp3 decoding can't be shipped in main, then I don't see why libmad0 can be shipped, even if it's a build-requirements for some stuff.
<Riddell> andred: it's not shipped, it's only in the archives
<andred> Riddell, Aha, I see. That makes sense.
<andred> Riddell, But then why isn't gstreamer0.8-mad in the main archive, but not shipped by default then?
<Riddell> andred: nothing in main needs it.  some things in main do need libmad to build so it has to be in main
<Riddell> mdz: IRC or e-mail preferred for breezy-updates? (4 of them)
* tseng watches Riddell let the secret out
<sivang> tseng: what secret? ;)
<tseng> libmad0 in main
<andred> Riddell, Ok. I figured Rhythmbox needed it.
<sivang> tseng: nice license :
<bryanf> infinity: ok, so I just did a fresh install and I'm still getting that corrupted double linked list
#ubuntu-devel 2005-10-20
<mxpxpod> nice work everyone on a sweet release
<mxpxpod> I installed fresh today and it was great
<TMM> hey all!
<TMM> I've got a question, it appears that there is a bug in compaq laptop biosses that put the critical(S5) temperature and the passive temperature both at 73 degrees
<TMM> this is rather stupid, and has some rather undesirable side-effects
<TMM> namely, the laptop shuts down before it gets the chance to cool :)
<robertj> heya all. I've determined that for my sound chipset, a few alsa settings must be set to off for sound to work without headphones, what package should get the bug?
<TMM> should I make a patch to acpi-support to decrease the passive temperature if it is found to be the same as the S5 temperature? or should I just file a bug and let someone else sort it out?
<crimsun> robertj: alsa-base or alsa-utils, we'll punt it to the proper one
<crimsun> robertj: keep in mind it's not possible to always set it, since your ac97 quirk may be chipset-specific
<robertj> crimsun: it is chipset specific
<robertj> without jack sense and headphone jack sense and line jack sense it doesn't work properly
<crimsun> robertj: if it's chipset-specific, have you passed the appropriate ac97_quirk option (depending on your driver)?
<crimsun> robertj: additionally, some quirks have been hard-coded into the appropriate drivers, and you can pass that model as a parameter to the driver. modinfo <your driver>
<mpt> TMM, try reporting a bug and attaching the patch to the bug report :-)
<TMM> mpt, I am still wondering what software should get the bug actually :)
<TMM> mpt, acpi-support is the only bit of software that has the magic to determine the vendor, but currently has no infrastructure to do special things based on that... because, ideally, you need to poke 2 memory adresses for this laptop to get all the buttons to work 
<lifeless> TMM: so, what you do is:
<lifeless> TMM: write the thing to patch the memory address, and use acpi-support to trigger it
<TMM> that's it?
<TMM> this pretty much involves all the recent presario models bij compaq and hp's evo and presario line
<TMM> I've got another one :)
<lifeless> that should be all thats needed
<lifeless> and acpi-support, when you look at it, depends on a bunch of packages, but doesn't have the actual per-platform hacks in it itself.
<lifeless> it would be really good to fix those models :)
<TMM> there is also a light next to the 'mute' button for sound, that, with the poking of the correct address will either turn on or off, I figured it out, but it would require wrapper scripts for the mute button handler in gnome... would such a thing be acceptable?
<TMM> lifeless, actually, acpi-support includes quite a lot of scripts and other goodies
<lifeless> scripts yes.
<lifeless> but all they do is determine what features, and what things from other packages, to run
<TMM> ok
<TMM> so what about the mute light? :)
<lifeless> anyway, however you do it, I'm positive mjg59 will love you for a patch
<lifeless> he can tweak it to be 'right' later :)
<lifeless> for the mute light, I suspect a kernel patch is the 'right way' but.. file a bug with the info you have, and/or chat with mjg59
<lifeless> hes teh acpi king
<TMM> ok, I'll make 2 patches then, one for insane temperature triggers(that is not compaq specific imgo), one to enable the buttons for the compaq
<TMM> lifeless, hard to do, the kernel doesn't really need or want to know the mute-state of the soundcard :)
<TMM> lifeless, although, I suppose I could work it into a soundcard drivers, but the button has nothing to do with soundcards, from a technical point of view, I'd have to add that code to all the soundcards that are in the different laptops that have this weird button
<lifeless> not as a soundcard button
<lifeless> just as an event 
<lifeless> oh, I misread
<lifeless> so you can turn the light on or off, but it is not a button ?
<TMM> the button and the light AND the soundcard don't have anything incommon
<TMM> the light is next to the button
<TMM> but you need to trigger the state of the light manually
<TMM> it's a stupid setup
<TMM> but, hey, here it is! :)
<lifeless> right
<lifeless> so its just a visual that is labelled 'muted'
<TMM> basically, yeah
<lifeless> mmm, so, probably a driver patch to allow setting it
<TMM> in what? :)
<lifeless> and then whatever for gnome to set that thing if present
<lifeless> hardware is usually kernel :)
<lifeless> can you tell that the light is there  ?
<TMM> there is rather a lot of kernel
<TMM> no, you can't tell that the light is there
<lifeless> bugger
<TMM> you can't probe for it or anything
<lifeless> makes it kinda hard.
<TMM> I know :)
<TMM> I know roughly what laptops have it based on their type#'s
<lifeless> so , I think you definately need to talk this through with mjg59 - I suggest filing bugs for each thing, with as much info as possible.
<TMM> I have 3 laptops here that have the light, all 3 with different soundcards
<TMM> all three compaq
<TMM> 'sound chip' is a better term probably :)
<TMM> I have code to set the light that works on all three, I have code to enable the extra buttons 
<TMM> I just don't have a place to stick it :)
<TMM> well, I have a place I could 'stick it up to' but that's hardly productive :)
<TMM> lifeless, I'll dick around a bit, I'll figure something out
<mdz> TMM: mjg59 is our laptop guru, but if he has any sense he's attending the release party right now ;-)
<mdz> he would be the one to talk to about it
<TMM> I'll go do that
<TMM> I hope he's having a couple of drinks :)
<TMM> I see a lot of the regulars are idling now, so I hope everyone is getting nice and drunk :)
<Keybuk> knowing mjg59 he's having a couple of bottles of drink
<mdz> Keybuk: I would see to it personally, but being on the other side of the planet etc...
<mdz> Keybuk: why aren't you there?
<Keybuk> wasn't invited
<Keybuk> and didn't find out anything about where it was until late this evening when it was too late to get there
<mdz> puh-leeze, you're implicitly invited
<mdz> it did sound like rather a last-minute affair
<Keybuk> yeah
<mdz> I think mark just went wherever the wiki said there was a party
<TMM> mark has a chopper :)
<TMM> that helps in those cases :)
<ProN00b> sorry to tell you, but you suck for forcing users to have gcj !!!!!!
<TMM> who?
<ProN00b> the one whos responsible for it
<mdz> ProN00b: first, the code of conduct applies in this channel
<mdz> ProN00b: second, openoffice.org are the ones responsible
<deb_user_ba> Hi!!
<ProN00b> i don't care, i am not a dev anyway
<mdz> that makes no difference
<ProN00b> openoffice needs it ?
<ProN00b> whee
<ProN00b> but why does it have a java binary *_*
<ProN00b> thats just strange
<TMM> ProN00b, the alternative would have been to depend on sun's closed source javaVM, your choice 
<TMM> ProN00b, :)
<ProN00b> i will download it
<ProN00b> still can't you somehow hide that java binary from console
<ProN00b> rename it or something ?
<TMM> ProN00b, yeah, but openoffice will work without it, isn't that a good thing? plus, using gcj is a hell of a lot faster than vm stuff
<ProN00b> nothing against gcj in general, i actually like the idea, but i need to run my jar's and i think there might be some fuckup having two java binaries on the system
<daniels> ProN00b: dude, if you can't be polite and respectful (as well as remain on-topic -- this is more of an #ubuntu question/rant), please leave
<ProN00b> i rather fell this is a development issue, as having a working (as in running sun javavm made for packages) java is quite important to some people  
<xTina> ProN00b: install a package with your proprietary jvm of choice that supports /etc/alternatives, and then use update-alternatives to make it defaut. that's exactly what update-alternatives is for.
<HiddenWolf> daniels, that's way too polite. :)
<ProN00b> whats that strange alternatives stuff, i have never heard of it
<HiddenWolf> ProN00b, openoffice is sponsored by sun, sun develops java, at least openoffice.org2-base is disfunctional without java, and many other options in -writer and -calc also
<daniels> ProN00b: at this point, I'm pretty sure it's ceased to be anything to do with development.
<HiddenWolf> ProN00b, we can't ship javaVM, so we use gcj
<HiddenWolf> ProN00b, and you're trolling, and voilating the code of conduct.
<xTina> ProN00b: I second daniels, please take this discussion to #ubuntu, there you can learn more about update-alternatives.
<HiddenWolf> ProN00b, ubotu Ubuntu is an African concept of "humanity towards others".  The code of conduct is at: http://www.ubuntulinux.org/community/conduct
<TMM> daniels, to his credit, he stopped being impolite and disrespectful a while ago
<HiddenWolf> TMM, he shouldn't have started in the first place
<TMM> HiddenWolf, true
<TMM> but it's also wrong to bash someone for something he stopped doing :)
<HiddenWolf> TMM, "you give me a free OS which works out of the box, but you suck, because it's not exactly how I like it!, Die" 
<daniels> TMM: right, but -devel isn't for answering what update-alternatives is.
<HiddenWolf> daniels, true, that. :)
<TMM> daniels, no, you are right
<TMM> well, I'll just shut up now, I was having a nice converation on intercal in #ubuntu-nl
* TMM votes to change all the python code in ubuntu to intercal
<HiddenWolf> TMM, but really, if you voilate the coc, you lose credit. :)
<TMM> HiddenWolf, obviously, but violating it yourself to tell it to someone in an unpleasant way isn't the way to go either
<TMM> "You will stop making war, even if I have to kill each and every last one of you"
<TMM> something like that
<HiddenWolf> TMM, curt, not unpleasant.
<HiddenWolf> TMM, and let's start by porting beagle and that mono cruft to python, then we can talk about intercal. :)
<xTina> Once you get the hang of d-i preseeding, infecting the whole world with Ubuntu is a joy :)
<TMM> HiddenWolf, noooo, let's port it to intercal!!! :)
* xTina assimilates another 72 machines :)
<TMM> xTina, d-i preseeding?
<HiddenWolf> xTina, nice
* TMM only assimilated 2 machines today :(
<xTina> TMM: fully-automated installation just with debian-installer, a few python scripts, and cfengine2 abused as just an interpreter
* HiddenWolf didn't assimilate anyone today
<xTina> though this server here is bugging me with its network interfaces
<xTina> I should have checked before how it was done :(
<TMM> xTina, I usually assimiate with a good talk and a bunch of cd's :)
<xTina> TMM: :)
<carstenh> 02:23:02 < strahler> o.k ich geh wieder off. carstenh und  man-di vielen dank.
<carstenh> ECHAN sorry
<Mez> fecking hell
<Mez> people want backports already
<calc> Mez: just open dapper that would work well enough ;)
<Mez> calc :P
<Mez> for now
<Mez> lol
<sivang> Mez: it's always like this :) get used to it :)
<TMM> Mez, ARE there any backports? :) there is nothing to backport FROM... :P
<Mez> TMM
<Mez> my point exactly
<Keybuk> it's just occurred to me ... I can't wait to see what the "Drake Dance" looks like
<TMM> Mez, what did they want for backports then? or just backports in general? :)
<Mez> keybuk: at the JD again?
<Mez> TMM: Azureus
<TMM> Mez, azureus is not going to come in universe or multiverse, right?
<TMM> Mez, I'm still trying to get it to work and build with free java SDK :) or is someone else also at that?
<Keybuk> mdz: I assume you have it all planned to the last step by now? :p
<mdz> Keybuk: it?
<Mez> mdz: the drake dance
<mdz> ah
<mdz> I have 2 more weeks to come up with something
<Keybuk> we could all just stand around waiting
<Keybuk> no, no, bad keybuk; cheap shot
<Mez> lol
<jbailey> That should be the hallowe'en costume contest.
<jbailey> The best Dapper Duck.
<Keybuk> are we having a ball?
<jbailey> No idea, but if you want tickets to Rocky Horror... ;)
<Mez> if we are, I'll bring my uniform and come as a croupier
<jbailey> Mez: I plan to come to UBZ in costume on the 31st.  It would be nice if I weren't the only one.
<jbailey> It wouldn't slow me down either way.
<jbailey> =)
<Mez> lol
<Mez> I can do a croup easy
<Mez> lol
<Mez> but... costume  = PITA
<Keybuk> jbailey: I think the last costume I wore to Rocky Horror would scare people
<Mez> jdub, ping
<Keybuk> Mez: almost certainly at the release party
<Mez> lol - just wondering why the wiki is so slow
<Mez> and where is the release party?
<Keybuk> London somewhere
<Mez> ah shame
<Mez> next week and I coulda gone
<Keybuk> there will be more than sufficient parties at UBZ
<Mez> PackageHeadersEducationSession - lol @ Keybuk
<Mez> when was debconf 4
<Keybuk> 2004
<Keybuk> May I think
<Mez> fair enough
<Mez> lol
<Keybuk> http://www.netsplit.com/events/2004/debconf4/
<Mez> elmo didnt like backports back then apparently
<Mez> :D
<Keybuk> 26th May2nd June 2004
<Mez> http://people.debian.org/~taggart/talks/debconf4-backporting/img0.html
<Mez> lmao
<Keybuk> you know, I _STILL_ have chocolate left over from DC4
<Mez> lmao
<Mez> acutally
<Mez> this is funny
<Mez> http://people.debian.org/~taggart/talks/debconf4-backporting/img12.html
<Mez> hmm... how much chocolate did you buy?
<Keybuk> SSDS is what HP guys used to call us before we were Canonical
<Mez> yeah I know :D
<Mez> I just found the slide amusing
<Keybuk> mmm, baz missing --skip-present is today's friend
<Keybuk> so I actually have two non-merged launchpad branches -- and I swear I submitted one of them wayyy back
<jdub> GOOD MORNING FREEDOM LOVERS!
<Keybuk> dude, you're keeping the wrong timezone
<jdub> just got back from GLLUG + release party
<Keybuk> any good?
<jdub> fun
<jdub> GLLUG was smaller than their usual crowd, but they usually meet on saturdays during the day, so this was quite odd
<xTina> Ok, I'm desperate. It's 4:44 am, I spent the past 7 hours debugging a network problem with breezy. Are there _any_ known issues related to using 2 network interfaces on breezy, routing , receiving but not replying on icmp echo requests ... anything?
<Keybuk> none that I know of
<Keybuk> are both interfaces receiving and sending packages separately?
<Keybuk> are the iptables clear?
<Keybuk> if you're trying to forward, do you have forwarding enabled and appropriate lifting between the two?
<xTina> Keybuk: I am not trying to forward, no iptables, both interfaces work just fine unless you are trying to send packets from subnet A to the Interface in Subnet B or from any subnet other than A to the interface in subnet A.
<Keybuk> so it's a forwarding issue?
<Keybuk> you're trying to accept packages on interface A and output them to interface B ?
<xTina> Keybuk: not really
<Keybuk> it would help greatly if you could be clear and precise about what you're trying to do
<xTina> I want a machine to have 2 IPs, each on a separate interface in a separate subnet.
<xTina> It worked this morning on Fedora, it doesn't work any more tonight on breezy.
<xTina> I have a machine still working fine on Fedora with a similar setup, there is no difference except for the last 2 digits of the IP address, routing table is the same, forwarding is off on both.
<Keybuk> right
<xTina> The machine is not supposed to play router.
<Keybuk> from the machine can you ping addresses on either interface?
<xTina> yes.
<Keybuk> so it works?
<xTina> from the machine it works
<xTina> to the machine, packets arrive but the machine doesn't seem to be sending anything out.
<Keybuk> and from subnet A, can you ping the machine's interface A
<xTina> yes
<Keybuk> and from subnet B, can you ping the machine's interface B
<xTina> yes
<Keybuk> and from the machine, can you ping a machine on subnet A
<xTina> yes
<Keybuk> and from the machine, can you ping a machine on subnet B
<xTina> yes
<Keybuk> so you've just described a working machine
<Keybuk> ...what is your problem? :p
<xTina> that from any subnet other than A I can't ping the interface A, and from subnet A I can't ping the interface B
<Keybuk> right
<Keybuk> that's entirely expected behaviour!
<xTina> which should work, did work and does work with the other machine
<Keybuk> no, it shouldn't work
<Keybuk> from subnet A you should not be able to ping interface B
<Keybuk> because it's on a different subnet
<Keybuk> if you want that to work, you need to enable IP Forwarding
<xTina> no
<Keybuk> think: firewall configuration -- you really don't want the kernel lifting packets between the two networks
<Keybuk> you have to enable that
<xTina> I am on a machine in A. If I ping the IP of the interface on B, the packets should go out to my default gw, go through * hops and then end up on interface B at some point.
<xTina> They _do_ end up on interface B.
<xTina> (says tcpdump)
<Keybuk> right, now here's the interesting question ... how do you expect the packets to get back? :p
<xTina> But the machine refuses to reply.
<Keybuk> they have to go back out of B
<Keybuk> but the machine's routing table will tell it to send them out of A
<Keybuk> which requires forwarding, which is disabled by default
<Keybuk> likewise if you ping the machine from a subnet that's not A or B, you need a default route for each interface to indicate how to get the packets back
<Keybuk> iirc. RedHat and Fedora have always enabled forwarding by default
<Keybuk> we choose to disable it by default for security reasons, because it's nearly always someone playing silly buggers
<Keybuk> and you end up with horrible network configurations where your machine takes the ping on interface B but sends the reply out of A
<Keybuk> so the incoming and outgoing packets go totally different routes
<xTina> It's still that /proc/sys/net/ipv4/ip_forward tells me if forwarding is enabled, right?
<Keybuk> yeah
<xTina> it's 0 on both machines
<xTina> the working and the non-working
<Keybuk> ok, fedora are doing something else evil then
<Keybuk> but that network topology you described shouldn't work
<xTina> Keybuk: So, what about having 2 default routes?
<xTina> Keybuk: multiple people have assured me it should be working
<Keybuk> you're basically trying to make your machine behave as if it has two networking stacks
<Keybuk> anyway, this is expected behaviour, so there's no bug here
<Keybuk> there are plenty of howtos and documentation on the net for doing networking correctly
<Keybuk> I'd especially start by learning the ip(8) tool, rather than ifconfig/route
<xTina> I still don't understand why you think this could only work with forwarding packets.
<xTina> The incoming packet and a response are independent to my knowledge.
<xTina> So if I receive a packet on network interface A, nothing prevents me from sending out the response on B.
<xTina> If the routing table says so, that is.
<Keybuk> icmp is treated specially I think
<Keybuk> it's been a while since I heavily played with the Linux networking stack
<xTina> Keybuk: It's the same for SSH.
<Keybuk> I quit working for ISPs a couple of years back, it's seriously not fun
<xTina> ;)
<xTina> I think I have to give up for now.
<xTina> 8 hours in a noisy server room is taking a toll
<Keybuk> I _think_ the responses are generated by flipping the headers around
<Keybuk> so it deliberately replies from the IP that was ping'd
<Keybuk> so it's already generating the reply "from B", and then trying to deliver that
<Keybuk> which it can't do through interface A
<xTina> Keybuk: But this implies that SSH should work.
<Keybuk> the same may be true for TCP too
<Keybuk> certainly I'm not surprised by the behaviour
<Keybuk> check the values of (amongst others) conf/*/arp_filter and stuff
<xTina> identical
<Keybuk> what value?
<Keybuk> certainly dig about; it's almost surely configurable behaviour -- one of the default network options may be different
<xTina> Oh dammit. You're right
<xTina> it's rp_filter
<xTina> it's set to the same value on both machines
<xTina> but turning it off makes it work on the non-working machine
<xTina> it's probably not a good idea though :(
<xTina> it is!
<xTina> apparently it's only useful in combination ip forwarding turned on
<xTina> Keybuk: thanks, i really appreciate your help
<xTina> i thought i was going slightly nuts
<Keybuk> :)
<lilo> hi all.... apologies for our problems earlier
<lilo> we're still piecing it together.... the scope of access was actually fairly limited
<lilo> apparently it was partly social engineering and partly something else, we're still looking at the logs
<lilo> anyway, I have a few more stops to make
* lilo waves
<sivang> Morning all
<zyga> morning
<pitti> Good morning
<fabbione> hey pitti
<fabbione> pitti: security pkgs for sparc are on the way
<fabbione> breezy is done
<fabbione> hoary is building
<pitti> for kernels?
<sivang> morning pitti , fabbione 
<fabbione> nope
<fabbione> pitti: the kernel was already done
<fabbione> pitti: openssl/curl/wget
<fabbione> hi sivang 
<pitti> ah
<hunger> Good morning
* hunger is getting a badsig on breezy-updates since yesterday evening. Is that a known problem?
<fabbione> hunger: what archive are you using?
<fabbione> i get no problems here
<fabbione> perhaps it's an out of sync mirror
<hunger> fabbione: archive.ubuntu.com breezy-updates Release
<fabbione> hunger: are you sure your ISP doesn't have a transparent proxy?
<fabbione> i rsynced this morning and updated all of my machines
<fabbione> no problem at all
<hunger> fabbione: I am not. But I never had this problem before.
<hunger> fabbione: I'll try a different mirror...
<hunger> fabbione: You were right... switching protocolls to ftp helped.
<hunger> Sorry for the noise.
<hunger> Strange... it does work now, even after switching back to http.
<ajmitch> evening all
<bob2> hey ajmitch 
<siretart> morning folks
<ajmitch> hi siretart 
<siretart> fabbione: I see igor stopped building. How much of universe did he managed to build? do you have an overview?
<fabbione> siretart: we manged 90.28% of the entire archive
<fabbione> yes.. igor is stopped becuase breezy is closed
<fabbione> we will start building again when dapper opens
<siretart> fabbione: whoa. thats great! that means poor old igor managed to build almost all of universe :)
<fabbione> siretart: not really.. it did its fair share :)
<siretart> well, there is another sparc upcoming anyway. (perhaps after ubz)
<siretart> ;)
<fabbione> siretart: hopefully we will get buildd's at the datacenter
<sivang> siretart: you coming to UBZ ?
<fabbione> not sure yet tho
<zyga> where does UBZ take place?
<bob2> canadia
<siretart> sivang: yepp :)
<siretart> fabbione: that would be even better! :)
<zyga> bah
<fabbione> siretart: yup
<zyga> ubuntu in center should take place in central europe ;] 
* zyga will wait untill someone comes up with UIC
<sivang> zyga: there was a conf in Spain
<zyga> spain is better than canada but I cannot turn time :)
<zyga> I didnt know of ubuntu back then
* Mez cant wait for the ubuntu conference to eb in the UK
<Mez> though it's usually in exotic locations
<Mez> so, skegness?
<ajmitch> Mez: it was in oxford, iirc
<Mez> ajmithc :P
<ajmitch> isn't oxford exotic enough? :)
<Mez> ajmitch: you're not from the UK are you
<ajmitch> NZ
* ajmitch must leave, bbl
<bob2> Mez: the first two-ish conferences were in england, i'd be surprised if it was back anytime soon
<Mez> bob2 :(
* infinity wonders what's so exotic about either Sydney or Montreal.
<infinity> I mean, they'r enice, large, world-class cities, but hardly "exotic".
<infinity> Except for all the people here in Australia who talk funny.
<sivang> bob2: ah, I thought there was only Oxford one time, where/when was the other?
<bob2> don't be grousing on us like that, mayte
<infinity> Don't get agro, mate.
<sivang> bob2: do you know if spephan richter's cookbook still available on the web?
<sivang> s/spephan/stephan/
<Keybuk> mommy!  GtkTreeView is breaking my fragile little mind!
<sivang> Keybuk: what's wrong?? :)
<Keybuk> it's eeeevil
<sivang> Keybuk: what's it doing to ya ?
<Keybuk> just trying to learn how to use it
<sivang> eh, you bumped into the way the model corrosponds to it? (took me some time to get that in g-s-t)
<gilligan_> sorry to ask here but no-one from the user channel knew -- does anyone know which package includes 'alsasrc' ?
<carstenh> .oO(use apt-file or packages.ubuntu.com?)
<gilligan_> well packages.ubuntu.com brings no results
<gilligan_> so that leaves me puzzled
<bob2> that just means it's not in ubuntu
<bob2> or wasn't when the index was last updated
<crimsun> this belongs in #ubuntu
<bob2> jah
<gilligan_> yes it does.. but as no-one seemed to have any clue..
<crimsun> I'll address that there.
<gilligan_> plus the program ought to be in ubuntu as it is supposed to be used in the  multimedia systems selector as pipeline
<crimsun> please migrate this to #ubuntu
<gilligan_> ok,sorry
<sivang> carstenh: that's nice how you did that comics style thinking ballon ;)
<carstenh> :)
* sivang wonders how a Marvell production would look on the world of Ubuntu, Launchpad, users and hero developers :)
<\sh> moin moin sabdfl :)
<sabdfl> moin moin!
<sabdfl> hey ogra, \sh
<sabdfl> breezy gave me a headache, but only for today :-)
<ogra> hey sabdfl :)
<dmk> sabdfl, good release party then
<sabdfl> rather
<ogra> heh
* ogra looks at \sh who is still recovering from the beerhead...
<\sh> ouch 
<ogra> heh
* \sh just succeeded to comfort ogra yesterday evening...he slept like a bear ...
<ogra> **snorrr**
<\sh> or was it the server room next door
<dmk> quick question guys..in Launchpad there is a bug raised that is fundementally a feature request for gnomebaker. If I mark it for fix in upstream is it going to ask me for the severity so I can put enhancement? if not what should I do?
<dmk> sorry if this seems a stupid one, just don't want to piss off upstream
<ogra> dmk, feature requests are mostly enhancements, sounds ok ...
<dmk> orga, cool - I just did want to click it and it to go in as a bug. wanted to make sure I could change it the enhancement
<dmk> orga, to instead of the at the end
<sabdfl> dmk: we do need a good way to move from a bug to a spec
<sabdfl> i think you can link the two of them, iirc
<sabdfl> so if there is a spec for the feature, registered in LP, you can link to it from the bug
<Mez> morning sabdfl, did the oarty go well?
<sabdfl> Mez... my head thinks
<sabdfl> so
<HiddenWolf> updates _again_?
<infinity> You can never have enough updates.
<dmk> sabdfl, yeah
<HiddenWolf> infinity, I haven't really felt that Breezy is done yet, with -security updates left and right. :)
<infinity> -security will always happen.
<HiddenWolf> infinity, not to mention the version bumps. :D
<infinity> Yeah, uhm.  "oops."
<Lathiat> version bumps?
<infinity> Lathiat : Minor embarassment where the versions for mozilla, thunderbird, and enigmail were lower in breezy than hoary-security, so upgrades wouldn't happen.
<infinity> Go me.
<Lathiat> oh
<infinity> (and pitti)
<Lathiat> how did that happen?
<infinity> Inability to count.
<Lathiat> lol
<\sh> why don't I have a digicam now...this picture is so nice...a white cat in suses arms, and ogra is petting her (the cat) and the cat is closing her eyes..and is relaxing...this is really a nice picture
<Lathiat> wow archive.u.c is up to 15K/s
<Lathiat> woot :)
<infinity> Yeah, I can't wait until it's back to "normal"... Should only be a few more days, I suspect.
<infinity> And sinze we're not opening dapper until Tuesday (at the earliest), that works out well.
<infinity> s/sinze/since/
<infinity> See, my fab typing may have had something to do with the version issues.
<lifeless> mjg59: ping
<jdub> "ugh."
<lifeless> howza
<\sh> jdub: "ugh" or "arghl my head"?
<jdub> a little of both
<\sh> jdub: perfect...;)
<ogra> hehe... all this release party victims
<\sh> ogra: don't be loud....you're one of them *eg*
<ogra> lol
<\sh> and now I will have a look in the mirror and I hope I'm not scaring myself
* sivang reads backlog and giggles
* ogra listens to the scared screams from the bathroom
<sabdfl_still_diz> mjg59 just headed for the train station from y place
<lifeless> sabdfl_still_diz: thanks
<lifeless> still_diz ?
<TMM> ah, is mjg59 coming here today?
<TMM> lifeless, still need to talk to him about the laptop stuff :)
<bob2> lifeless: "zy$", I'd assume
<jdub> http://www.ucc.asn.au/services/ubuntu.ucc
<jdub> ^ UBUNTU ON TAP
<\sh> and a nice picture of a toshiba portege r200 which is working NOW OUT OF THE BOX !
<Riddell> who can review uploads to breezy-updates?
<Mez> lmao at ubuntu on tap
<HiddenWolf> Riddell, more updates?!
<Riddell> HiddenWolf: same ones, still needing review
<HiddenWolf> Riddell, ok
<jdub> sabdfl_still_diz, mjg59: "EBay buys VeriSign payment service division" -> heh
<Lathiat> wow, plane ticket pricese really do vary sildly from day to day
<Lathiat> from $377 to $690 one day to the next
<Lathiat> jdub: talking on avahi at lca. :)
<Lathiat> i should do a gca talk "now it actually works..." :)
<Riddell> Lathiat: are you an avahi developer?
<Lathiat> Riddell: yeh
<Lathiat> Riddell: one of the original authors
<Riddell> Lathiat: excellent, I'll come to you when I have questions about getting the KDE avahi support working :)
<Lathiat> Riddell: cool :)
<Lathiat> Riddell: we have qt main loop integration
<Lathiat> and it works with kdnssd now
<Lathiat> altho its a bit hacky, it works
<pitti> hello
<jdub> Lathiat: rawk
<jdub> yo pitti
<Lathiat> jdub: indeed
<Riddell> Lathiat: what's hacky about the qt integration?
<sivang> pitti: hey Martin :)
<\sh> siretart: hey pitti
<\sh> argl
* tseng watches jdub's bees nest
* \sh should think about siretart and writing to another person
<\sh> shouldn't even
<tseng> nice stir, jeff
<jdub> hmm?
<tseng> release process thread
<pitti> Hi sivang! I just bought a printer :-)
<tseng> i dont feel like telling this guy that thinks it will create "huge flak" that all of the FUD he references comes straight from Ian
<tseng> and that no one cares
<jdub> oh right
<siretart> heh. hy * 
<siretart> ;)
<\sh> siretart: sorry...didn't want to disturb you while u r relaxing ,-)
<siretart> hrhr
<tseng> i guess it means i need a proper spec for approval for keeping up with mono, though
<sivang> pitti: oh you did :) ?
<sivang> pitti: cool, then I need to get one as well - preferbly a laser one,
<sivang> pitti: my deskjet here is dying
<pitti> sivang: yes, I bought a laser
<Riddell> sabdfl_hungover: irn-bru.  best thing for it
<sabdfl_hungover> Riddell: where do i find that?
<Riddell> sabdfl_hungover: scotland mostly I'm afraid
<sabdfl_hungover> it may be worth the trip
<Lathiat> Riddell: the qt integration isnt hack
<Lathiat> y
<Lathiat> Riddell: the kdnssd integration is
<Lathiat> Riddell: because it was designed around howl
<Lathiat> and their usage model is different to ours
<Mez> mdz: ping
<Mez> actually.... probably elmo ping... I'm not too sure
<Mez> either way, can someone please create the breezy-backports archive, people are enabling it, as it's commented out in default sources.list, and it's causing errors and we're geting a load of complaints
<gilligan__> i'll dare asking a small #ubuntu question... the totem mozilla plugin does not have a seperate package ? how can I get rid of it ?
<backports-r-us> are there any kernel folks in here?
<backports-r-us> I'm trying to get rid of the time stamps on all the kernel messages...
<backports-r-us> not having much luck googling or on #ubuntu
<gilligan__> backports-r-us, what do you want to get rid of them for?
<Mez> backports-r-us, backports are me
<backports-r-us> gilligan__: logwatch doesn't enjoy reporting duplicates properly anymroe :)
<backports-r-us> Mez: backup nick; logged in @ home right now
<Mez> :P
<backports-r-us> (too lazy to register it, too)
<backports-r-us> Mez: but now that you've brought it up, do u have a functioning Hoary pbuilder/whatever-you-use environment?
<infinity> backports-r-us : You have to recompile and disable CONFIG_PRINTK_TIME
<backports-r-us> infinity: grr, it takes a recompile?
<infinity> backports-r-us : Hrm, botting with "time=no" might work.
<infinity> backports-r-us : Booting with "time" turns them ON, so maybe time=no turns 'em off. :)  Untested.
<backports-r-us> infinity: LOL, good logic... will test :)
<Mez> godamn
<Mez> ~I realy wish i didnt have backports on a highlight
<backports-r-us> i
<backports-r-us> am
<backports-r-us> annoying
<backports-r-us> mez
<backports-r-us> right
<backports-r-us> now
<backports-r-us> :)
<jdong__> make you happier?
<Mez> actually only when you said mez did it ding me
<Mez> ty
<jdong__> lol
* jdong__ concludes #ubuntu is for those with multithreaded brains
<ivoks> hi
<mantiena> hi
<TMM> mjg59, are you alive yet?
<TMM> mjg59, still having a hangover no doubt ;)
<moyogo> hi I'm one of the dejavu-font developers, how do i got about to update the package in breezy?
<moyogo> should I just contact the package maintainer?
<moyogo> oh... actually, i should just contact peter
<jordi> moyogo: it's late to update the package in breezy
<moyogo> jordi: for the next update then
<jordi> yeah, for 6.04
<moyogo> jordi: actually, could the font be installed by default? at least along with bitstream?
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | Dapper opens ~Tuesday
<jordi> moyogo: you should discuss that with the Ubuntu Desktop guys, I think
<moyogo> what channel?
<jordi> I'd guess #ubuntu-desktop
<moyogo> oh... thanks
<jdub> moyogo: we'll ship dejavu with dapper
<moyogo> jdub: thanks, we'll need to follow up with the updates there too, 1.14 has been out for a month, breezy only has 1.11 packaged
<jdub> moyogo: highly unlikely that we'd update breezy
<moyogo> no prob
<Mez> elmo:ping
<dieman> oh, now thats a nifty idea
<dieman> use jabber to tell machines to update packages
<dieman> or to install something 
<dieman> if the machine is down, it will get the message when it starts back up.
<Robot101> dieman: unlike e-mail how exactly...?
<Robot101> having a jabber client with root priveledges fills me with joy
<dieman> heh
<dieman> theres going to be something evil with any agent implementation.
<jdub> Robot101: wouldn't need to have root - don't be silly :)
<Robot101> jdub: it has root privs to do something, like invoke the pkg manager
<jdub> Robot101: the jabber client wouldn't - separate the tasks (cf. pmount)
<Robot101> yes obviously
<Robot101> but it's still a jabber client which can invoke at least your pkg manager as root
<Robot101> :P
<jdub> you can do plenty to fence that
<jdub> it's a good idea
<dieman> saw the idea on planet gnome
<Robot101> I don't see how jabber is suddenly a better way to do it than e-mail
<jdub> it's not
<Robot101> as they say in london, please mind the crack :)
<dieman> philip van hoof's post recently.
<Robot101> dieman: yes, I read it too
<dieman> ahh, ok
<dieman> im not sure if its better yet, but i hadn't thought about it
<dieman> i was always leaning towards using web services to communicate back to the clients -- having them check a website every so often. 
<dieman> hah, someone finally replied to my mirrors@canonical.com email :)
<mantiena> dieman, no :-P
<dieman> heh
<\sh> hmm...i just got a shock
<dieman> at least the mirror is back down to sub 1-loads
<dieman> instead of 30-80 
<\sh> https://launchpad.net/distros/ubuntu/+sources/elmo/+bug/3122 <- elmo crashes on startup 
<HiddenWolf> dieman, and that's good news? :P
<dieman> "
<dieman> After over half a year not doing anything with Elmo I decided to admit that nothing is going to change. "
<dieman> heh, that sounds like a dead mailer project
<dieman> HiddenWolf: yes and no :)
<dieman> means my fai installs at work will go fast again
<dieman> :)
<HiddenWolf> dieman, I'd rather have archive.u.c was swamped any day. I'm smart enough to find a mirror.
<dieman> oh, im talking aobut the mirror at work :)
<zyga_> hmmm
<zyga_> elmo is a script?
<zyga_> script/program
<psusi> what package do you have to install to get io.h for things like open()?
<Lathiat> you mean stdio.h ?
<psusi> no....
<psusi> stdio is C standard IO
<psusi> fopen()
<Lathiat> you said open not fopen ;p and iirc its in the same header file
<psusi> it is?
<psusi> it shouldn't be
<Lathiat> apt-get install manpages-dev
<Lathiat> man fopen
<psusi> ahh, there's the bloody man pages
<jdub> psusi: libc6-dev, but i recommend installing build-essential
<psusi> I have build-essential an libc6-dev installed
<jdub> oh, but you need the man pages
* Lathiat has never known of an io.h
<Lathiat> and fopen is in stdio.h im sure of it
<jdub> libc6-dev: /usr/include/sys/io.h
<Lathiat> ah i see
<psusi> yes, fopen is in stdio.h, but where is open()?
<psusi> I looked at sys/io.h and it just had stuff for IO port access, not file IO
<Lathiat> isnt open like
<Lathiat> an internal function
<Lathiat> or something
<psusi> it's a kernel system call that is wrapped by the libc library
<psusi> strange.... the man page on open doesn't list O_BINARY
<Yagisan> Is something wrong with the archive ? I'm getting
<Yagisan> W: GPG error: http://192.168.1.1 breezy-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<Yagisan> on my updates now.
<Lathiat> i saw someoen else get that too
<Lathiat> mine are fine
<Yagisan> Lathiat: all my boxes go to the apt-cacher machine at 192.168.1.1, which in turn uses the au.archive.ubuntu.com mirror
<Yagisan> I am not going to upgrade my boxes if the signature fails. I checked and apt-cacher doesn't cache Release files
<Yagisan> so unless the key was changed, I'd have the mirror checked for possible compromise
<Mez> Yagisan, it does that sometimes
<Lathiat> Yagisan: im updating fine
<Lathiat> of au.archive.ubuntu.com
<Lathiat> i figure your apt-cache is b0rked
<Lathiat> or if your really paranoid
<Lathiat> someone is MITMing you ;p
<Lathiat> or your ISP has a proxy
<Lathiat> that cached the gpg sig file or something
<Yagisan> Lathiat: Several boxes get that (I know my isp has a hidden transparent proxy, I found it when mapping my connection)
<Yagisan> Lathiat: It's my job to be paranoid - someone has to do it :)
<Lathiat> your isp has probably just cached the Release.gpg file then
<psusi> shouldn't the cachability of the file on the server be set correctly so that the proxy should go ask it to validate that the file has not changed at relatively short intervals?
<Lathiat> shouldnt ISPs use proxys that actually pay attention to the cache settings? ;)
<psusi> hehe
<Treenaks> Lathiat: why would they? they're transparent!
<psusi> they loose transparency when they fail to obey the cachability rules
<Treenaks> psusi: not to windows people
<Lathiat> because isps suck :)
<psusi> the OS you are running has nothing to do with it
<psusi> if the proxy is caching stale data, you're going to have problems
<Yagisan> excellent - 6 updates and only one without error :-/ somethings stuffed
* Yagisan goes for lucky 7
<Lathiat> yeh in a windows world
<Lathiat> transparent is 'almost opaque' :)
* Yagisan sighs
* Yagisan wishes he knew what exactly causes the problem, because it's become intermittent
<Znarl> We've got two of our master archive machines out of sync.  This is being worked on.
<Znarl> au.archive.ubuntu.com points to archive.ubuntu.com as we don't have an Australian archive mirror yet.  (But hopefully will soon)
<Lathiat> ah
<Lathiat> that makes sense
<Yagisan> Znarl: thanks. I know enough about gpg to be concerned when the sig fails. Will try again in 12 hours or so
<Lathiat> Yagisan: basically your probably getting Releases off one server
<Znarl> You could use security.ubuntu.com, if you're not already.
<Lathiat> Yagisan: and Releases.gpg off the other
<Yagisan> Znarl: already have that :)
<Yagisan> Lathiat: seems like that is the case
<Yagisan> Znarl: the mirror is in london isn't it (it has a horrible ping from here)
<Znarl> Yes, in London.
<Znarl> There's a good local mirror at http://mirror.isp.net.au/ftp/pub/ubuntu/
<sabdfl_hungover> Znarl: has the bandwith situation calmed down?
<Znarl> sabdfl_hungover : Yes, but our machines are still very busy.
<sabdfl_hungover> phew
<sabdfl_hungover> i guess we know to call for more mirror support before dapper :-)
* Lathiat is still only getting 10K/s from archive.u.c
<Lathiat> beats 1K/s / timeouts tho
<Lathiat> Znarl: ftp.uwa.edu.au is good too
<Znarl> sabdfl_hungover : I've added a number of mirrors today.  Working on a Australia and New Zealand mirror right now.
<Lathiat> and ftp.debian.pacific.net.au
<Yagisan> perhaps next time only give to torrents to slashdot ??
<Lathiat> Znarl: ftp.uwa.edu.au is possibly willing to be a proper AU mirror, the guy there mailed the list a while back
* Lathiat knows him 
<sabdfl_hungover> Znarl: cool
<Lathiat> their on gig, and connected to the WAIX exchange in perth
<Znarl> Lathiat : Yep, just sent him an email.
<Lathiat> Znarl: cool
<Lathiat> pacific is usually good too
<Lathiat> dont touch iinet their mirror is useless
<Yagisan> Lathiat: it could be worse, it could be tpg
<Lathiat> haha
<Lathiat> or dodo
<Znarl> I remember when iinet's backbone was a 56k modem.
<Yagisan> ha, dodo - internet that dies
* Lathiat grins
<Yagisan> how smart is apt ? if I add multiple deb lines to different servers - will it pick the best one ?
<Lathiat> it does it based on new version and then order
<Lathiat> it will still whinge about gpg sigs tho
* Lathiat used to stick an ISP local mirror (free traffic) first then a.u.c
<Lathiat> so i got new stuff, but other stuff for free
<Yagisan> Lathiat: I'm with the $50 isp, so I don't get free downloads
<Lathiat> Yagisan: well
<Lathiat> Yagisan: in perth we have WAIX
<Lathiat> and most isps (except iinet really)
<Lathiat> give you free traffic to it
<Lathiat> you often get the same with PIPE and VIX
<Lathiat> unless your on the cheap cheap plans
<Lathiat> (because their already making a loss on those plans, dont want leechers on theM)
<Yagisan> Lathiat: well, there is only one $50 1500/256 plan I can find.
* Lathiat pays $70
<Lathiat> 10G peak, 10G off-peak
<Lathiat> 1500/256
<Lathiat> free waix
<Yagisan> Lathiat: 20G then shape, uploads not shaped (I host a unoffical repo - I got complaints when I took the box offline to upgrade to breezy)
<Lathiat> Yagisan: so same as me
<Lathiat> i get shaped to 96
<Lathiat> tyhen if i do over 120%
<Lathiat> (another 2G)
<Lathiat> i get shaped to 33.6
<Lathiat> no, its 72
<infinity> No shaping here, your ISPs suck.
<Lathiat> then 33
<Lathiat> infinity: yes, they do
<Lathiat> welcome to australia
<infinity> I'm in .au, dude.
<infinity> There are 1001 people reselling Telstra's crap service, pick one that doesn't shape.
<infinity> (I'm using cyberone.com.au)
<Yagisan> Lathiat: 64 flat down for me, infinity - they want more the $50 for that
<infinity> Oh, true, I pay 90/month for unlimited unshaped usage.
<Lathiat> i pay 70
<Lathiat> i cant really afford anymore
<Lathiat> 90/month for what speed?
<Lathiat> infinity: and you are? didnt know that
<infinity> Though I'm pondering switching to iinet, now that my exchange is almost ready for ADLS2....
<Lathiat> infinity: eh iinet suck
<infinity> And then I'll be stuck with limits. :/
<Lathiat> crap quotas
<Lathiat> no free waix
<infinity> Stupid iinet.
<Lathiat> and the autotrainign is crap
<Lathiat> cus
<infinity> Yeah, but the 12Mbps (and 1Mbps up) is tempting.
<Lathiat> a lot of peoples line quality moves around a bit
<Yagisan> infinity: you have to take their phone to get adsl2
<Lathiat> so it autotrains to some speed
<Lathiat> oh yeh
<Lathiat> and that
<Lathiat> and then yoru line quality drops a bit
<Lathiat> so you get bad packet loss
<Lathiat> you reconnect, it renegs lower
<Lathiat> and then it'l decide later to reneg higher again
<Lathiat> and f**k up again
<infinity> Yagisan : I don't care, I already pay 30/month for Telstra's line, what's the difference if the 30 goes to iinet instead?
<Lathiat> it gets quite annoying
<infinity> (Like I really want to give Telstra money?)
<Lathiat> infinity: hrm, most people i know pay 18.50
<infinity> Well, I also make phone calls. :)
<infinity> iinet's plans are much less crap than Telstra's, for call charges.
<Lathiat> as in, 18.50 for rental
<Lathiat> and iinet cahrge 30 for rental
<infinity> But, yeah.  Still evaluating.
<Lathiat> infinity: eh, voip is so m uch cheaper
<Lathiat> or my mobile
<infinity> iinet does voip now.
<Lathiat> yeh its not as cheap as other voip providers but P:)
<Yagisan> infinity: I do vo-ip, and my mobile is cheaper then telstra, I call Japan cheaper!
<Lathiat> and you still have to pay line rental
<Lathiat> you can get 1c/min australia-wide from siphone.com.au
<Lathiat> and it works fine
<infinity> Yagisan : Canada was much cheaper, but I moved, so I'm stuck with this.
<Lathiat> i know a few people that moved it
<Lathiat> s/moved/used
<bddebian> Hello
* Yagisan should sleep
<Yagisan> G'day bddebian
<sivang> hey bddebian 
<sivang> what's cracking?
<bddebian> Heya Yagisan, sivang 
<bddebian> sivang: Not much,  you?
<sivang> bddebian: fine, working on some BOF ideas, trying to remember all the ideas I had and outline them good enough for proposal.
<bddebian> Nice
<LaserJock> bddebian: do you use the web interface when making comments on Malone?
<bddebian> LaserJock: Yep
<LaserJock> bddebian: is there some sort of formatting guide? Or am I just dense?
<Lathiat> formatting?
<Lathiat> their comments ;p
<LaserJock> well, they never come out the way I put them in
<Lathiat> in what way
<LaserJock> look at the bottom of https://launchpad.net/distros/ubuntu/+sources/xfig/+bug/2066
<LaserJock> I bulleted it with - but they came out all running together
<bddebian> Hmm
<LaserJock> I have yet to have a comment formatted the way it was when I was typing it, and there is no preview sooo
<LaserJock> I think I must just retarded or something
<bddebian> It's a comment, who cares :-)
<LaserJock> I guess, it is just frustrating for me. Especially compared to the wiki's
<LaserJock> ohh, well
<sivang> siretart: what is "trac" ?
<Lathiat> sivang: its like a mini wiki style thign with integration to svn to track a project
<mdke> elmo, not around by any chance?
<bddebian> Hello sabdfl.  Congrats! :-)
<Znarl> Only Znarl right now.
<sabdfl> thanks bddebian. still dealing with the fallout from the party :-)
<infinity> Znarl : Talk about yourself in the third person a lot?
<Znarl> He some times does, yes.
<tseng> there is only zul
<bddebian> sabdfl: Heh, nice :-)
<bddebian> Heya tseng 
<tseng> hi barry
<mdke> Znarl, :)
<mdke> Znarl, it was about planet.u.c. Jeff said (if I understood right) that he added my blog to the source but that it needed to be synched. Can you do that?
<Mez> mdke: it does it automatically once a certain amount of time goes by
<mdke> or perhaps I got the totally wrong end of the stick
<mdke> jeff said something about synching with a baz archive
<Mez> oh, maybe it has a baz archive which it syncs to and he edited you into the baz archive
<mdke> i think that is right
<Znarl> mdke : I can't help you.
<mdke> Znarl, np
<Lathiat> im having withdrawl symptoms
<Lathiat> no updates!
<Lathiat> i might have to do some security work to get my daily fix ;p
<bddebian> Lathiat: Aye :-)
<Mez> *bangs head on keyboard
<Mez> there is something seriously f**ked up here
<sabdfl> Mez: did you do surgery on your archive?
<Mez> ...?
<Mez> what do you mean sabdfl?
<Mez> oh, you mean referring to my comment
<Mez> no - I'm getting an error saying that I need version 2.53 or higher of autoconf, but I only have 2.59 :D
<Mez> sabdfl: no I didnt
<Mez> sorry
<Mez> I'm all over the place
<sabdfl> ah, i thought it was a reference to your earlier archive issues
<Mez> oh.. no my archive is fine
<Mez> it's the stuff IN the archive that isnt
<Mez> sabdfl: just out of curiosityL do ubuntu have a sort of server farm anywhere where people can build on architectures they dont have? because I've hit a few stumbling blocks before on amd64 stuff :D and access to an amd64 machine woulda been useful
<bddebian> Mez: Good question ;-)
<sabdfl> Mez: no, we just have the normal buildd's
<sabdfl> a couple of guys do have porting access to those machines
<sabdfl> we could probably arrange access to a DMZ
<sabdfl> put it on the tech board agenda, ok?
<Mez> shame :D I gues sit'll have to be a "throw at buildd till sticks"
<Mez> anyway, I'm going to lunch, Ill talk after
<Mez> have fun, speak soon
<tseng> hah look at the mono build logs from last april
<tseng> total "throw at buildd till sticks" action
<Robot101> it builds -> ship it! :)
<Mez> sabdfl: I would do, but I wont be availble for a TB meeting till after UBZ
<sabdfl> put it on the agenda, we can discuss it anyway
<maswan> thank you breezy: http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005--41,raw,traffic-kbit
<maswan> :)
<sabdfl> dude
<sabdfl> did you *peak*?
<spayne> bddebian: ping
<maswan> university bandwidth is neat
<maswan> during thursday afternoon and evening, we were saturated
<maswan> we "only" had 2Gbit/s
<maswan> but by friday, we've had enough bandwidth and resources to satisify demand
<bddebian> spayne: Yo?
<spayne> bddebian: i got my key signed :)
<bddebian> Awesome
<spayne> bddebian: can you download and check it is good? I'm new to the whole GPG thing
<spayne> bddebian: key ID is C137
<maswan> Znarl: if the DC is still having bandwidth issues, feel free to point more releases iso downloads our way.
<spayne> bddebian: key ID is C137358E
<spayne> bddebian: how do know if it is in the strong set?
<bddebian> gpg: searching for "C137358E" from hkp server subkeys.pgp.net
<bddebian> gpg: key "C137358E" not found on keyserver
<spayne> bddebian: i ran gpg --send-key C137358E and gpg --keyserver pgp.mit.edu --send-key C137358E
<LaserJock> how do you know that a key has been signed?
<spayne> because he sent me a .sig file
<spayne> look at http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0xC137358E
<spayne> LaserJock: is that not signed?
<LaserJock> no, I think you are good, I just was wondering for myself
<LaserJock> for instance mine is http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x92742B33
<LaserJock> obviously mine is not signes
<LaserJock> *signed
<spayne> why do i get this error at http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder/mk_path.cgi?STAT=C137358E&STATS=statistics
<LaserJock> spayne: I am wondering what constitutes the "strong set"
<pef> when does dapper will start ? when the mass sync from Debian will occurs ?
<HiddenWolf> pef, under debate.
<spayne> can anyone help me? i am new to GPG :)
<bddebian> spayne: http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=vindex&search=0xC137358E&fingerprint=on
<spayne> bddebian: great (i think)
<spayne> bddebian: but why didn't it apper before?
<spayne> bddebian: ?
<LaserJock> is anybody listed at biglumber.com as being in the strong set acceptable for key signing?
<spayne> LaserJock: don't you need to find someone who is near you first?
<spayne> LaserJock: and then see if they are acceptable?
<pef> HiddenWolf: ok, thanks :)
<HiddenWolf> pef?
<LaserJock> well, I found 3 in my area but only 2 are listed as being in the strong set
<spayne> LaserJock: so why are you asking then? :)
<pef> about strongset, I can't remember the website where I can search people on this set and see where and when they travel, bigslumber or something like this
<LaserJock> spayne: from https://wiki.ubuntu.com/UnsignedGpgKey "If you can find someone in your area, confirm with a current Ubuntu member that their signature is acceptable for access to Ubuntu resources"
<LaserJock> I'm not sure what "acceptable" means
<spayne> LaserJock: there ain't many around now
<spayne> bddebian seems to have disappeared :(
<mdke> LaserJock, it means you need to find someone in the strong set
<spayne> mdke: how can i check if my key is in the strong set?
<mdke> spayne, has any ubuntu member or developer signed your key?
<spayne> mdke: no, a debian developer
<spayne> mdke: he was 4 steps away from \sh
<mdke> that is fine then afaik
<spayne> mdke: but it is worrying me that it isn't showing up on some key servers
<mdke> keyservers all sync with each other, so if you uploaded it somewhere usual then it will be fine
<HiddenWolf> Backports suck, officialy. :(
<Mez> HiddenWolf, er... why
<HiddenWolf> Mez, lots of people for whom it breaks upgrading, apperantly.
<Mez> yeah... firefox
<Mez> or... the archive not being there cause.... it's not been created for FF yet
<HiddenWolf> Mez, there is no breey backports, that's scary when upgrading for backporting noobs, but not terrible.
<Mez> HiddenWolf, I know... and the shitty firefox thing is the only other thing that bust
<Mez> that was reallu bad
<Mez> and hopefully we can really get it sorted now
<Mez> sudo apt-get clean; sudo apt-get remove firefox; sudo apt-get remove firefox
<Mez> sudo apt-get clean; sudo apt-get remove firefox; sudo apt-get install firefox
<HiddenWolf> throw in an apt-get update for good measure.
<shack\out> --reinstall wasn't enough?
<HiddenWolf> shack\out, firefox is a bit, even on straight upgrades. :P
<spayne> hey Mez
<Mez> hi
<spayne> mdke: this page confuses me: http://keyserver.kjsl.com/~jharris/ka/current/C1/C137358E , can you help?
<mdke> probably not
<spayne> mdke: who knows all about gpg then?
<trulux> heya
<mpt> mjg59: ping
<arkalon> can anyone comment on https://launchpad.net/distros/ubuntu/+sources/linux-meta/+bug/3115
<HiddenWolf> mpt, people have been trying that all day. :)
<mpt> heh
<arkalon> Malone bug #3115: meta (Ubuntu) - Kernel oops when unplugging USB device Fix req. for: linux-meta (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3115
<mjg59> mpt: Hi
<mpt> mjg59, usplash worked in Breezy a few weeks ago, but after upgrading to 5.10 it doesn't. What information/files should I include in my bug report?
<mjg59> mpt: What do you mean by "it doesn't"?
<mae> Is there any talk of having some sort of delta support in apt? so updates don't suck up so much bandwidth? :)
<mpt> mjg59, it boots in text mode and the splash never appears
<mjg59> mpt: What are your kernel arguments, and is usplash actually installed?
<mpt> so it's not the same as bug 14497
<jdub> mae: there has been talk, but not a lot of design and implementation
<mae> jdub :)
<mpt> mjg59, usplash is installed, and I know the kernel arguments include "splash" at the end because I saw that during startup (how do I find out what the full set of arguments are?)
<jdub> mae: definitely something we'd like to do, but may end up involving deeper packaging infrastructure changes than just "deb+delta+apt support"
<mdke> spayne, #gnupg
<mdke> jdub, got a moment?
<Christophe971> well well well
<jdub> mdke: sure
<Christophe971> hello everybody
<ploum> hm, I've just noticed a weird and confirmed bug in epiphany for people upgrading from hoary to breezy. (malone #3203). 
<jdub> mdke: depends how long, i want to grab some food
<jdub> but an actual moment is easy
<mdke> jdub, did I understand right that for me to get onto planet.u.c elmo needs to sync something? if so, how can I tell when it is done?
<jdub> mdke: you can tell when it's done when your blog entries appear on planet ;)
<mdke> jdub, so I can blog now and they will appear backdated?
<jdub> of course
<mdke> ah cool
<mdke> thanks a lot
<jdub> puc is quite slow
<jdub> not a lot of people on it atm
<jdub> so it's not like an entry today would be off-page by tomorrow
<mdke> sure
<jdub> to food!
<mdke> did you put in a request for the sync?
<mdke> or shall I bug him?
<jdub> there are other things in the way of it atm
<Christophe971> i just want to know what about "ubuntu-multimedia" and other packages evoked in the devel list ?
<jdub> you don't need to bug either of us - we know it's in the queue :)
<ploum> jdub, just thank you for correcting me in ubuntu-desktop for dapper and not drapper. You cannot imagine how it saved my life !
<Christophe971> we talked about "ubuntu-game-arcade" metapackage and others, will they be included in dapper ?
<jdub> ploum: heh
<mdke> jdub, ok sorry! I wasn't sure if it was in the queue or not
<mdke> say no more about it :)
<mjg59> mpt: cat /proc/cmdline
<mpt> mjg59, root=/dev/hda1 ro quiet splash
<Christophe971> so so so ? No one remember about this idea ?
<ajmitch> morning all
<mjg59> mpt: Ok. Uhm.
<mjg59> mpt: In that case, I have no idea what's going on
<mae> jdub, what do you think of canary?
<Christophe971> ploum: you're following the devel list no ?
#ubuntu-devel 2005-10-21
<mpt> mjg59, ok, thanks anyway -- reporting the bug now
<Christophe971> ploum_: you're following the devel list no ?
<jdub> mae: conary? interesting, but with the burden of complexity very mich on the user
<ploum__> Christophe971, yes, I'm following it
<Christophe971> ploum__: so what about "ubuntu-multimedia" and "ubuntu-*" metapackages ? it's for dapper ?
<mae> jdub, yeah, but some of its ideas could be taken and integrated into apt, it would require alot of infrastructure change.. would probably need to branch off for awhile... but the transactional features are very nice.
<Christophe971> ploum__: ton pseudo est enregistr ?
<ploum__> yes
<Christophe971> ben alors
<ploum__> (ploum at least)
<Christophe971> tu rponds pas ? :D
<Christophe971> arf
<Christophe971> ploum__: au fait, t'as qu'a nettoyer ta liste jabber, c'est facile
<Christophe971> ploum__: so, this teasing about the marketing campain of ubuntu
<Christophe971> ?
<ploum__> Christophe971, please tell me this in private, not on this channel
<Christophe971> impossible, you're not registered
<Christophe971> kill your ghost
<jdub> mjg59: so
<jdub> mjg59: have you seen the buzzy image you get when you switch an intel card to display on both the lcd and vga?
<jdub> mjg59: which you don't get if you output to the vga alone?
<crimsun> yeah, that's problematic
<mjg59> jdub: Yes
<mjg59> No, there's currently no good workaround
<jdub> bum
<jdub> it's okay when you get another screen in front of you
<jdub> but really annoying when you only have your laptop screen as a reference - or the main projector screen
<mjg59> Yes
<mjg59> Need to speak to alanh about it, really
<ogra> yeah, hi shermann 
<\sh__> jo ogra :) 
<ogra> mdz, around ? 
<\sh__> hehe...funny
<ogra> *g*
<\sh__> my laptop (netboot) via ogras laptop over his wlan card...
<ogra> mdz, we're just running multiarch ltsp over here ...
<\sh__> ogra, it works :) great :)
<ogra> yeah
<\sh__> ok..shutting down the laptop...good night ;)
<shadeofgrey> hello!  im not a coder or developer or anything so ill get out of everybody's way i just...,...  wanted very much to say thanks to everybody who makes ubuntu possible and free for people like me...  i always wanted to learn linux and failed miserably thanks to the daunting task of learning fedora core...
<shadeofgrey> but thanks to ubuntu ive managed to learn thousands of times more than i ever thought possible by myself, and for that, you all deserve far better than my heartfelt thanks could ever give you...
<shadeofgrey> anyway...  my name is Chris and my email address is shadeofgrey@gmail.com -- send me an email if i could ever be of any help - especially with your assistive software because im very physically handicapped, so id make an excellent guinea pig
<shadeofgrey> thanks again for all your hard work and dedication..  you've made it possible for me to kill windows with an Ice pick, and now that I've broken free, I'll never ever go back...  even if i hgave to pay for ubuntu... I would.
<shadeofgrey> keep up the good work and thanks!
* mpt mails shadeofgrey
<Robot101> love that xorg bug where xine initialising the screen makes it hang
<Robot101> crash
<Robot101> and then gdm restarts it in an infinite loop
<Robot101> displaying the cursor before the server crashes again
<Robot101> apparently indefinitely
<Robot101> its not in the slightest bit annoying
<Keybuk> heh
<Keybuk> Robot101: you know gtk stuff a bit, right?
<Robot101> The display server has been shut down about 6 times in the last 90 seconds. It is likely that something bad is going on.  Waiting for 2 minutes before trying again on display :0.
<Robot101> oh it got the message. making me wait a minute and a half sure sucks
<Robot101> Keybuk: yes
<Keybuk> so I have a TreeView, and I want to draw in one of the cells with cairo
<Keybuk> and I've got the puzzle in front of me, and all I have is sky
<Keybuk> if I put a CellRendererPixbuf in there, I can't get a cairo context for it
<Keybuk> etc.
<dieman> http://keithcu.com/wordpress/?page_id=15
<dieman> someones ranting on ubuntu bugs
<dieman> hope hes reporting them
<dieman> looks like a former windows user, too, though.
<Robot101> Keybuk: how do you usually render cairo in a gtk widget?
<Keybuk> Robot101: no idea
<Robot101> Keybuk: I think that's the source of the problem :D
<dieman> when do we get opengl accelerated cairo? :)
<Keybuk> like I say, I just have sky at the moment, looking for a corner or an edge <g>
<Keybuk> never had time to play with this new cairofied gtk
<Keybuk> and I figure what I'm doing is perfect for cairo
<Keybuk> maybe I just need to stop fiddling with pixbufs and sub-class GtkCellRenderer myself to implement a Cairo one
<dieman> with ubuntu server, does it just installa different task and have different stuff on cd?
<dieman> christ, search for ubuntu server edition and you get my mirror instead of ubuntulinux.org
<Robot101> Keybuk: if cairo can target an X window, you should be able to ferret out the right thing from the cell renderer
<jdub> dieman: it installs the minimal server selection by default, includes different extra packages on cd
<Robot101> Keybuk: GTK_WIDGET(foo)->window is the GdkWindow
<dieman> jdub: ok.
<Robot101> Keybuk: but I don't seem to have found any code that does this, or pixbuf rendering
<Robot101> http://live.gnome.org/ProjectRidley_2fGnomeCanvas
<Robot101> there's some vapourware plans
<dieman> jdub: is it a task or just ubuntu-base?
<Robot101> http://www.gtk.org/plan/meetings/20050913.txt refers to some "example code" which I can't find
<jdub> dieman: ubuntu-standard i think, but you should check with Kamion to be sure
<dieman> jdub: thanks tho, just wondering. dont want to stare at bits of d-i to find this ;)
<dieman> d-i is confusing as heck last time i looked
<dieman> just wondering, as I do most of my ubuntu installs through fai
<dieman> (and do work in-house to make fai work well with ubuntu for our needs)
<Keybuk> Robot101: I've worked out how to grab a CairoContext from any drawable
<Keybuk> so I just need to sub-class cellrenderer and override its render function (which gives me a drawable)
<dieman> i've got a new guy to help out at work too, i threw him at the debian policy manual first ;)
<Robot101> Keybuk: cairo_t *gdk_cairo_create(GdkDrawable *drawable) ?
<Keybuk> yeah
<Mithrandir> dieman: pft, d-i is sensibly laid out and easy to grasp, even more so after you understand the basic concepts.
<Nafallo> Mithrandir: oh! why are you awake? :-)
<Mithrandir> Nafallo: just got home from a party.
<Nafallo> ah :-)
<Nafallo> Mithrandir: I've pounded on the www.magicalforest.se ;-)
<jcohen85> One of the breezy goals was to have the ubuntu update manager automatically inform users when a new Ubuntu release was available and to allow a distribution upgrade w/o having to edit the repositories. This goal was unfortunately deferred. Will this be something that's done for dapper?
<eazel7> hi ppl
<fede2> Hey guys about the sparc port... what's the deal with it? I haven't been able to find mutch information other that the repository at http://sparc.ubuntu.com/.
<Lathiat> there was an announcement that went out
<Lathiat> http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000040.html
<fede2> Lathiat, _thanks_.
<mpt> jcohen85, https://wiki.ubuntu.com/AutomaticUpgrade should answer your question within a month
<jcohen85> mpt: why have a seperate application? It makes far more sense to have the ubuntu upgrade manager inform you of a new release and offer to upgrade as that application is used by users on a regular basis anyways. 
<mpt> jcohen85, I entirely agree, and said so on that wiki page
<jcohen85> wasn't the breezy goal an addition to the upgrade manager rather than the creation of a new program?
<mpt> I have no idea
<jcohen85> thanks for the info
<mpt> I didn't know it was a Breezy goal
<jcohen85> https://wiki.ubuntu.com/SystemUpgradeTool
<mpt> Hopefully we can reduce the number of graphical installation/update tools from 3 to 1
<jcohen85> 3?
<jcohen85> aren't the main ones synaptic and ubuntu update manager?
<mpt> synaptic, gnome-app-install, update-manager
<jcohen85> gnome-app-install is the "Add/Remove Applications" one for new users?
<mpt> yeah
<jdub> mpt: update and install are different enough that it's not worth combining (you'd just end up with an over-stuffed ui)
<jcohen85> each one seems to serve different purposes
<jdub> (like synaptic)
<jdub> (which ought to stay, as the advanced admin tool)
<jcohen85> i like the fact that the upgrade tool has a simple interface and just lists the packages to be updated with info on what was changed as an option
<jdub> (so the current number and split is fairly reasonable)
<jcohen85> i think it should also have an option to upgrade automatically- to make the process even simpler. It's good that the upgrade tool is trivially easy to use
<mpt> jdub: The combined tool would be simpler than synaptic is currently
<jcohen85> mpt: what would you do with g-a-i?
<jdub> mpt: it would still be over-stuffed, if attempting to combine install and update
<jdub> (into one ui)
<jcohen85> i can't see it as a replacement to synaptic. synaptic offers many advanced features g-a-i doesn't have and shouldn't have
<mpt> well, there's not much I can say to that, except, I disagree
<jdub> there needs to be more commonality, but not combination at the ui level
<jdub> otherwise you end up going down the path of the windows add/remove thingy, then red carpet, then synaptic (in order of complexity)
<jcohen85> what's red carpet?
<jdub> teh novell/ximian synaptic-like tool
<jdub> it used to be quite simple, but had a frustrating ui
<jdub> now it's almost as complicated as synaptic
<jdub> but a bit nicer for the admin use case than synaptic
<whiprush> i find redcarpet much easier to use than synaptic
<jdub> yeah
<jdub> much clearer
<whiprush> well, except for that monkey molesting a computer icon they have. :p
<jcohen85> what's wrong with synaptic?
<jcohen85> i came from mandrake and i thought synaptic was a great improvement
<jcohen85> very powerful and easy to use
<jcohen85> if you haven't used mandrake- they had a tool for installing AND a tool for removal- it was essentially the same program but you couldn't do both at once which was very frustrating. 
<jdub> it's fine for admin-level users, but still has a difficult user interface for that use case
<jcohen85> isn't g-a-i for new users?
<mpt> jcohen: It's not obvious how to upgrade, editing repositories is very awkward, making selections is very awkward, the workflow isn't obvious
<jdub> gai is for the common use case (not just new users)
<mpt> and every so often update-manager will say "This is too hard for me, use synaptic"
* mpt looks at Red Carpet screenshots
<jcohen85> so- for users that want to view changelogs, need to do a dist-upgrade (run the development version), lock an application at a certain version etc. you would use synaptic. But you see gai as what the average user will use?
<mpt> eww
<mpt> scrolling tabs
<SuperLag> Any of you guys happen to use Ubuntu on PPC?
<jdub> jcohen85: hopefully most users (not new, not average) will find a gai equivalent straight-forward and easy to use for installing and removing applications
<jdub> SuperLag: sounds like a question coming that would be more appropriate on #ubuntu
<jcohen85> jdub: huh- maybe i have to look at gai again. I found it pitifully inadequate in hoary. I spoke with the developer of the new gai and found some of the new features quite interesting but I never saw it as a synaptic replacement.
<SuperLag> jdub: Well.  Normally I'd say yes.  I'm not a newbie though, and though I develop for another distro... I've got things going on with this install that I think I'd get quicker help from a fellow developer.
<jdub> probably easier to ask straight up
<jdub> jcohen85: it landed first in hoary
<jdub> jcohen85: it is not a 'synaptic replacement'
<SuperLag> Yaboot isn't playing nice, and is trying to install a new version from the installer when it's already installed.
<SuperLag> I know I have this set up right, because I can get an install with Gentoo, but no matter what combination of options I try, yaboot fails every time.
<jdub> jcohen85: it's an application add/remove tool, which is overwhelmingly the major goal users have with this kind of tool - synaptic is much more appropriate as an admin tool (and could be vastly better at handling that use case, too)
<jdub> jcohen85: (and gai is going to keep improving release to release)
<Amaranth> and, best of all, the new gai works with newer pyxdg versions! ;)
* mpt tries to run gai without supplying an admin password, and fails
<Lathiat> Amaranth: gai?
<Amaranth> gnome-app-install
<Lathiat> ah
<jsgotangco> greets
<spacey_ki> morning
<jsgotangco> dum dum dee dum
<sivang> Morning all
<jsgotangco> morning sivang 
<sivang> jsgotangco: hi there, what's up?
<jsgotangco> ahhh just relaxing on a sunday afternoon (its raining outside so i can't really go out)
<sivang> jsgotangco: ah nice, where are you in?
<jsgotangco> sivang, here in Manila (Philippines)
<sivang> jsgotangco: oh cool, that's a nice place :)
<zyga> hello
<sivang> hi there zyga 
<siretart> morning folks!
<swestres> mornin' siretart 
<pitti> Hi
<ajmitch> hi pitti 
<ajmitch> how are you this morning?
<pitti> Hi ajmitch! fine, thanks
<pitti> and you?
<ajmitch> good thanks
<ajmitch> just went & visited parents for the weekend
<ajmitch> so it was nice & quiet :)
<ajmitch> now it's time for me to write up some stuff for UBZ
<\sh> todo for tomorrow: package new python-kde3 and hope it's fixed by upstream 
* ajmitch has a bit of selinux stuff to throw together & see if it sticks
<sivang> pitti: Hi Martin!
<sivang> ajmitch: goign to plan SELinux ?
<ndazza> hi! i have a local mirror of the ubuntu repo and i'm looking to build the official CDs/DVDs for all the arch's for my local LUG. can this be done through jigdo or some other mechanism? I have found the jigdo files for the install CDs but not for DVDs or live CDs
<ajmitch> sivang: sure
<pef> hello
<sivang> hey pef 
<Solatis> hello, i'm having some glibc problems (linking never works, returns errors that there are undefined references in the glibc library), did a clean breezy install and still have the same problems, and my bug report @ bugzilla doesn't really get any real responses (other than "do you have all the latest packages installed") ... any recommendations on what to do ? I've created a really simple test case that reproduces the problem... 
<Solatis> anyone has any idea where to go next ? i'm getting really desperate (which is why i'm spamming here)
<mdke> not much more you can do apart from keep answering questions on the bug report
<mdke> maybe try the mailing list -devel
<Solatis> ok, if there are still no respnses to the bug report today i'll do that
<infinity> Solatis : Have you attached your testcase to the bug report?
<Solatis> infinity: no not yet, at the moment i've only pasted it inside the comments ( basically, to show the problem couldn't be my code )
<mvo> Solatis: what bug number?
<Solatis> 17771
<infinity> Solatis : Your testcase works here.  Which arch is this one?
<infinity> s/one/on/
<Solatis> athlon xp, if that's what you mean
<infinity> Kay, this is an i386 system here too, and your test case (compiled exactly as you did) works fine.
<Mithrandir> Solatis: is the system otherwise stable?  Without looking very much at it, it sounds like hardware trouble.
<Solatis> then do you have any idea why/how this can go wrong on a clean breezy install ? i just created one inside vmware
<Solatis> yes, last thursday it worked perfectly... then i upgraded to breezy, and this happened
<Solatis> and the system is perfectly stable otherwise, yes
<infinity> Solatis : What's the output of:
<infinity> nm -D /lib/libpthread.so.0 | grep libc_stack_end
<Solatis>          U __libc_stack_end
<infinity> Right, kay.  Nothing wrong there, then.
<infinity> Does adding "-lc" to your linker line magically make the error go away?  (no, this shouldn't be necessary)
<Solatis> `g++ -lc -o test ./test.cpp` still gives the error
<infinity> Same error?  Cause that's pretty weird, then.
<infinity> Err, you don't have another libc in your search path, do you?
<Solatis> well, no, not really... if i add -pthread option, it finds a fault in libpthread.so.6, if i don't add that option, it find a fault in libc.so.6....
<Solatis> not that i know of
<Solatis> it's a clean breezy install, so it should be... how can i easily check on libc's in my search path ? using ldconfig -p ?
<Solatis> by the way, if i rewrite my application to be fully c instead of c++ it still gives linking errors
<Solatis> this time:
<Solatis> /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1'
<Solatis> /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
<infinity> I assume libc6-dev is installed, and not messed up in some way?
<Lathiat> what on earth are you doing :\
<Solatis> yes, version 2.3.5-1ubuntu12 is installed, and no i did no configuring whatsoever
<infinity> So, I assume a basic C printf("Hello World"); fails to link too?
<Solatis> yep
<Solatis> ok, this does it... i'm going to test if my machine fails even under a totally different linux distro
<infinity> Yeah, very unusual, and you're quite obviously the only person with this issue, or our archive wouldn't build. :)
<Solatis> because i really get the feeling this indeed is very unusual
<infinity> Can you dup your environment to the bug log?
<Solatis> yeah, i'm getting the feeling this really is some problem you guys cannot help
<infinity> s/dup/dump/
<Solatis> sure, what command do i have to use to do that ?
<infinity> The output of "set" would be fine.
<Solatis> ok
<infinity> But it looks like linc isn't being linked.
<infinity> (Well, the RIGHT libc isn't being linked)
<infinity> Which is so clearly not an issue in breezy, or we'd all be broken.  So, it's got to be something local.
<Lathiat> not mounting an old /usr/local or something ?
<Lathiat> or have a LD_LIBRARY_PATH\or LD_PRELOAD
<Solatis> nop, i am mounting an nfs /home
<Lathiat> or something
<infinity> linker looking anywhere in you ~ for libs?
<infinity> s/you/your/
<Solatis> yeah, one of my own homebrew libs, no glibc as far as i'm aware
<infinity> Solatis : An strace of the linker call would be nice too.
<Solatis> ok
<infinity> Solatis : Do a hello world, compile to a .o, then link it.  strace the link.
<infinity> That should show us where it's looking, and hopefully why it's not getting libc.
<infinity> Attach all of this to the report, please don't inline it in massive comments. :)
<Solatis> haha kay kay :)
<Solatis> thanks for your help, i really appreciate it
<Mithrandir> to see if it's something in the environment, try compiling hello as root?
<infinity> Or just with a clean env.
<Solatis> ok, lemme try that
<Solatis> oh boy.... 
<Solatis> ok, that worked
<infinity> "env -i gcc foo.c"
<Solatis> ok, i guess at the moment i'm wasting your time - it's clearly something with my environment
<Lathiat> Solatis: run an export and paste that into a file somewhere
<Lathiat> with your normal env
<infinity> Solatis : Oh, I assumed it was your environment long ago, I'm still curious how you're managing to not link libc, though. :)
<infinity> The only way I can think of off the top of my head is with -fno-default-libs.
<Lathiat> shouldnt -lc change that tho
<infinity> And I somehow doubt your environment contains "alias gcc="gcc -fno-default-libs", y'know?
<Lathiat> Solatis: export output?
<infinity> And yes, -lc would bring libc back even with -fno-default-libs, good point.
<Lathiat> i think the appropriate description is 'f**ked' :)
<infinity> So, the assumption here is that you ARE linking libc from somewhere, just not the one in /lib/
<Solatis> yeah indeed
<Solatis> but where...
<Solatis> :)
<Lathiat> Solatis: run export, and put the output on pastebin or something
<infinity> Solatis : As previously-suggested, an strace of the failing linker call will probably point out your problem in big blinking letters.
<infinity> Cause you should see it scanning the (wrong) directory, and opening the (wrong) libc to link.
<Lathiat> indeed
<Solatis> http://pastebin.com/395292
<Solatis> that's the export
<Solatis> now the strace
* infinity runs off to the store to buy some provisions before packaging the new apache upstream.
<Lathiat> Solatis: nothing strange looking there
<infinity> Not a very exciting environment.
<Lathiat> quite
<Lathiat> strace then
<Solatis> infinity: it's a clean install! i am exciting, usually... :P
<Solatis> ahhhh!
<infinity> I take it the strace was enlightening? :)
<Solatis> ok, i see that he indeed is using a library version i put somewhere in my home directory
<Solatis> but who put it there
<Solatis> hmmmm
<Lathiat> your mother
<Lathiat> its the eyes in the back of her head :)
<infinity> Lathiat : Very helpful.
<Solatis> ahhh, sheesh, i'm so sorry i took so much of your time :)
<Lathiat> infinity: totally
<infinity> Solatis : No big deal.  I live to give.
<Lathiat> Solatis: heh, its ok
<Lathiat> i didnt realise ld searched out libraries in the current dir tho
<infinity> Solatis : Just go update and close the bug, and we're even. :)
<Solatis> haha :)
<Solatis> infinity: roger :)
<\sh> infinity: can u do me a favour for dapper? and include the nice splitlog script from gentoos apache..it works much better in vhost environments then the original ones
<\sh> -s
<infinity> \sh : Uhh, what's wrong with having a log for each vhost, which is what most sane people do?
<infinity> (Okay, if you have millions of vhosts and don't want to eat file descriptors, i could see logging to one log and splitting it, but that's an unusual setup)
<infinity> (One unusual enough that you probably have some pretty interesting custom logging and splitting anyway)
<\sh> infinity: no...it's not unsual...using a ENV var for setting the log to vhost bla and everything works niceley...and the cpu consumption is not worth to mention...
<\sh> infinity: the vhost setup from gentoo is really easy to administrate...and fits perfectly in debians "sites-available, sites-enabled" system....i can give u an example of the config ;)
<\sh> infinity: but it's just an idea of improvement...a nice to have
<\sh> CustomLog "|/usr/sbin/split-logfile" vhost env=VLOG
<\sh> and in virtualhost section
<\sh> Setenv VLOG /var/www/blogweb.de/logs/
<\sh> that's all..ok I missed out the LogFormat line for vhost
<\sh> then a nice clean install of templated mod-logan analyzer stuff, a small script which replaces the hostnames and a hourly cron script...and voila -> \sh is happy, because he's a lazy admin ;)
<infinity> \sh : I don't see how that ends up being drastically different from just setting CustomLog for each vhost.
<\sh> infinity: u set it once serverwide and the rest is done by the split-log script automatically...and using mod_vhost for mass hosting is much easier to handle
<infinity> \sh : Err, but you just said you do a custom SetEnv for each vhost.  That seems pretty much identical to a custom CustomLog for each vhost.
<\sh> infinity: for mod_vhost u do only one 
<infinity> Alright, I'll bite.
<ndazza> hi! i have a local mirror of ubuntu and i'd like to build my own cds/dvds from them, including live CDs. I can probably figure out building the install CDs from jigdo but how can i build the live CDs/DVDs
<infinity> File a bug in Debian's BTS, with the script attached (including whatever license Gentoo is licensing it with, I won't include it if it's not Apache-compatible)
<infinity> ndazza : You don't, at least, not easily.
<ndazza> infinity: bugger! there's no automagic scripts to build a live cd then?
<infinity> \sh : Err, wait.  split-logfile comes from the apache sources.
<infinity> \sh : Unless Gentoo's is somehow different..
<infinity> \sh : Yeah, we include it.  So, how is theirs better?
<infinity> \sh : Ahh, I see, the upstream one doesn't allow you to specify the target of the logs.
<infinity> \sh : Well, file a bug and a patch, please.
<\sh> infinity: will do :)
<infinity> \sh : And make sure the behaviour is backward compatible with the upstream split-logfile, if called the same way.
<\sh> infinity: I'm using it btw on my hoary install :)
<\sh> infinity: yeah it's called the same way
<infinity> (I'm not going to break existing installs)
<infinity> Right, but if it's called without specifying the target location, does it behave the same way?  (split logfiles into ./$(vhost).log)?
<\sh> infinity: hmmm..we can provide a new name for it and bring it in as alternative
<\sh> infinity: yes...including date etc.
<Lathiat> 8/win 38
<\sh> infinity: so it's doing logration on it's own
<\sh> infinity: I'll send you a test setup as well...
<infinity> Alright.
<infinity> Debian BTS, package "apache2-utils".
* infinity points.
<\sh> k
<\sh> looks like if libofx is our waterloo
<\sh> motus waterloo to be exactly
<\sh> infinity: can we make an update to libofx via breezy-updates?
<infinity> After all those uploads, you still got it wrong
<infinity> ?
<\sh> infinity: we focused the replaces on libofx1 and not on hoarys libofx0
<\sh> grmpf
<\sh> two people one bug
<siretart> hm. do we have a breezy-updates policy somewhere on the wiki or elsewhere?
<infinity> \sh : Erm, when have we ever shipped a libofx0?
<infinity> \sh : Oh, you mean libofx0c102?
<\sh> infinity: yes
<infinity> I vaguely recall mentioning that one, way back when. :)
<infinity> You realise that finding overlapping files is as easy as searching for that file on packages.ubuntu.com, right?
<infinity> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=libofx.la&searchmode=searchfiles&case=insensitive&version=hoary&arch=i386
<infinity> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=libofx.la&searchmode=searchfiles&case=insensitive&version=breezy&arch=i386
<\sh> infinity: put some salt into our wounds *headbangingonthetablenexttome*
<infinity> So, that shows the three packages which needed Replaces.
<infinity> Anyhow, breezy-updates is approval-only, probably even for universe.
<siretart> infinity: who approves breezy-updates? and according to what policy?
<\sh> infinity: which is fine with me..I only want to have the possibility
<\sh> s/want/need/
<\sh> and somehow now, this ABBA song is in my head..
<janimo> is there a place I can get old versions of binary debs? I am interested in the ati driver deb from 6.8.2-75
<einheit> on apt-get update:
<einheit> W: GPG error: http://lt.archive.ubuntu.com breezy-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<einheit> 
<einheit> anything to worry about?
<Znarl> einheit : Do you use a proxy server?
<SteveA_> hi karl
<SteveA_> not on purpose
<SteveA_> but i think my isp enforces one
<SteveA_> semi-transparently
<Znarl> Ah, that could be it and that our archive mirrors are falling out of sync again.
<Znarl> I just re-synced our two temp archive servers.  Shouldn't happen now.
<SteveA_> looking better
<SteveA_> thanks Znarl 
<KraetziChriZ> Hi Guys
<KraetziChriZ> After Upgrading to KDE 3.4.3 the QT-Tool "klibido" is a littlebit broken -> http://www.ubuntuusers.de/download.php?id=153 -> anyone know what there is going wrong?
<KraetziChriZ> (too many menues..)
<zyga> everyone is sleeping? :)
<ajmitch> morning
<mdke> morning
<ogra> mdz, around ? 
<pitti> Hi ogra
<ogra> hey pitti 
<ajmitch> hi pitti 
<sivang> hey pitti , ogra , ajmitch 
* infinity yawns and tries not to notice that it's a Monday morning.
<ogra> infinity, come over here.-.. quick... then its still sunday evening
<sivang> infinity: morning Adam :)
<sivang> it's Sun 23:13 here
<Lathiat> haha
<Lathiat> its mon 5:35 here
<ajmitch> infinity: isn't it far too early for people to be up over there?
<infinity> 7:30 for me.
<infinity> Not that it means anything, I've been up all night.
<ajmitch> right, I at least managed to get an early night @ 1AM
* ajmitch did a little malone cleanup & got over the 100 bug mark finally
* infinity looks curiously at his INBOX in thunderbird and wonders how those 119 unread messages magically got marked read...
<infinity> Oh well.  Guess I didn't need them hilighted anyway.
<sivang> lol
<infinity> It's just trying to save me from myself, I'm sure.
<infinity> I had stuff marked "unread" from 8 months ago.
<sivang> infinity: this happens to me all the time actually
<hughsie> ogra: ping!
<ogra> high
<sivang> infinity: you in the US ?
#ubuntu-devel 2005-10-22
<infinity> Australia.
<ogra> sivang, au
<sivang> ah 
<hughsie> ogra: hey, you been following hal-devel list?
<sivang> ogra: are you more comfotable with XChat then irssi?
<ogra> only very rough...
<ogra> sivang, yup
<hughsie> what you make of it?
<hughsie> Another opinion if you will..
<ogra> hughsie, you mean "HAL is not for hardware management" ?
<hughsie> ogra: yes that whole thread with the *really* long emails
<hughsie> just wanted an ubuntu perspective
<ogra> i totaslly agree with you... had a long dispute with pitti already, because he disaGREES
<ogra> whoops.. sorry for the caps
<hughsie> ogra: seems to have got people quite passionate
<sivang> ogra: why HAL is not for hardware management ? (sorry, I haven't been following the threads just curious)
<ogra> i think a "hardware abstraction Layer" should also manage hardware... work in both directions...
<hughsie> ogra: seems crazy to me to do it twice by two different daemons
<hughsie> if we have the information in hal, like acpi.battery
<ogra> else i'd call it a "Hardware Information Layer" ... but we dont talk about HIL :)
<hughsie> then we have to decode the system type, work round bugs, lauch the update addons etc,
<hughsie> and then do it *again* in anothe daemon
<ogra> yes, thats silly
<hughsie> what's pitti's take on this?
<ogra> i  trhin your approach is the right way...
<ogra> pitti sees HIL, not HAL :)
<hughsie> ogra: thanks, i was starting to get worried that i was alone!
<ogra> urg
<hughsie> i think davidz agrees too
<ogra> s/trhin/think
<hughsie> HIL is great when you want to name a disk.
<hughsie> HAL is great when you want to mount that disk using crypto automatically, or change the lcd brightness
<ogra> yes... pitti is our security guy, he's very cautious about possible security flaws being created through a two way HAL
<hughsie> ogra: i can see that too -- but then the dbus stuff lets ppl lock it down
<ogra> but i thnk its the right approach
<hughsie> it's just a big change for the one daeom does this, another does this type way of thinking
<ogra> just design it carefully, and it will be fine...
<hughsie> i'm not quite sure how to reply to matthias
<hughsie> I mean, i respect the guy, and his work is very good, but I think he is wrong.
<ogra> hmm, probably wait for david to speak up
<ogra> he cant ignore that thread
<hughsie> ogra: yes, good plan. will do.
<hughsie> i figured if he didn;t like the direction he wouldn't have merged my patches
<ogra> and since he gives thedirection for HAL, he'd be the authorized source
<hughsie> (he was the one who wrote the script invokation support!)
<hughsie> if he does agree with me, then it will have been good to clarify what HAL is, and what it *should* do
<ogra> i really think HAL must work in two directions
<hughsie> yes, thanks. I'm not going crazy then!
<ogra> so your approach is right imho... but even inside ubuntu we have different opinions about it
<hughsie> yes, it's divided quite a few ppl
<hughsie> but then you can turn HAL back into HIL editing a few fdi files
<ogra> its a hairy thing because it can always introduce security breakage if not designed right
<ogra> its quite fragile... 
<ogra> but we need such a layer imho
<hughsie> yes, i know
<hughsie> when you talk to pitti, can you ask him what other issues he sees using HAL as, well, HAL?
* netjoined: irc.freenode.net -> brown.freenode.net
<ogra> hughsie, will do :)
<hughsie> ogra: I keep upsetting people. first the ial and FnFX guys, now mattias with ppbuttonsd!
<ogra> pbuttonsd sucks a lot, but there is nothing better yet
<ogra> lots of people asked for removal pre breezy here... but there is no replacement yet... 
<hughsie> ogra: yet. there's lots of stuff i could do with HAL for PMU using the pbuttonsd code and enhancing the pmud addon, but that throws up more politics!
<ogra> probably someone should encance HAL enough to replace it
<hughsie> I really need a powerbook laptop to borrow so i can write the pmu stuff
<ogra> sure, but its the right way
<hughsie> ogra: what does pbuttonsd do that hal doesn't at the mo?
<ogra> yes, i need one too, edubuntu ppc couldnt get released, we had not enough testers
<ogra> no idea, no ppc around here
<hughsie> ebay...
<ogra> :)
<hughsie> i want a really shit one with a cracked screen or something
<ogra> heh
<hughsie> cheers for the re-assurance ogra, appreciated.
<ogra> :)
<ogra> thankls for all the work :)
<hughsie> ogra: well, it's getting to the stage where it "just works" for me
<ogra> yay
<hughsie> i.e. i remove the acadapter and the screen gently dims
<hughsie> fc5 has removed battstat applet in favour of g-p-m
<ogra> we'll hopefully be able to do it for dapper
<hughsie> ogra: cool :-)
<ogra> :)
<ajmitch> and hopefully gss to go with it :)
<ogra> yeah
<hughsie> g-s and g-p-m play very nicely together
<ogra> g-s-s is a must for dapper
<hughsie> g-p-m uses g-s for all the X detection stuff
<ogra> i dont want to touch x-s-s again...
<hughsie> x-s-s is a mess..
<ogra> yes
<ogra> and it wont get better
<ogra> as long as it keeps its maintainer
<hughsie> well, it could do with some love... or a re-write... ohh wait..
<ogra> heh
<ogra> if g-s-s hadnt shown up, i'd have started at least gconf integratiojn
<ajmitch> and probably gone crazy because of it
<HiddenWolf> g-s-s?
<hughsie> the architecture in g-s-s is sound too.
<ogra> gnome-screen-saver
<ogra> its a bit odd because of dbus though
<HiddenWolf> ogra, cool
<HiddenWolf> ogra, is that moving along nicely?
<ogra> yup
<HiddenWolf> If I'd had a working video driver, I'd sort out those screensavers.
<HiddenWolf> The bad, the worse, the ugly, and the passable. In that order. :P
<ogra> but integrating with acpid until g-p-m takes over will be a PITA
<ogra> since you cant easily access a users dbus session as root
<hughsie> why would you want to integrate with acpid?
<ogra> berather acpi-support...
<HiddenWolf> hughsie, power down cpu and monitor after a while.
<hughsie> HiddenWolf: that's left to g-p-m
<hughsie> i'm pretty sure g-s will never do that
<ogra> our hibernate tries to lock the screen for example... so you have to giver your password on resume
<hughsie> g-p-m does that now
<ogra> thats very hard to do currently
<hughsie> g-p-m locks the users screen using .lock() from g-s, and then calls hal to do the hibernate
<ogra> but g-p-m runst in the session... we need access from outside the session...
<hughsie> ogra: why must you access from the system?
<sivang> guys, when currently someone chooses a language in d-i, does he get all the menus in that language after installing ?
<ogra> and there the dbus api stands in the way
<ogra> sivang, in german, nearly all...
<sivang> ogra: so you do get all the menus in he choosen language, ok
<ogra> hughsie, probably its solved with your option in g-p-m note we are on a older version in ubuntu
<sivang> ogra: are you also getting a GNOME kbd selector ready to switch between english and germen?
<hughsie> ogra: you have a very old version
<ogra> yes
<ogra> upstream version freeze...
<hughsie> the maintianer of g-s-s only fixed the bug in dpms last week
<hughsie> and i only added support for locking then hibernating a couple of weeks ago
<ogra> the maintainer would be me... that was mjg59 who fixed that
<hughsie> ogra: okay, nice one!
<ogra> upstream version freeze locked the version down... that was a matter of luck that it was updated :)
<hughsie> good show
<ajmitch> luck & pain ;)
<hughsie> in (new ubuntu devel tree) are you going to ship a more up2date g-p-m?
<ogra> until UVF again... its always a matter of the release schedule....
<hughsie> sure, no worries
<hughsie> you def shipping hal 0.5.5?
<ogra> the one for dapper will probably be more strict, because we'll have 3 year support
<ogra> is 0.5.5 out ?
<hughsie> not yet, give it a week
<hughsie> got *lots* of fixes form 0.5.4
<hughsie> all over the shop
<ajmitch> ogra: something we need to discuss for MOTU as well
<ogra> so it wil be int i think
<hughsie> good :-)
<ogra> ajmitch, lets just go with the schedule for motu
* ajmitch will try & set some time aside for the MOTU meeting on tursday (for me)
<ajmitch> ogra: sure, but we'll need to put in a couple of extra milestones for us, imho
<sivang> ajmitch: MOTU and the 3 years support policy that is?
<ajmitch> otherwise we'll have a crazy time in the last 2 months again
<ajmitch> sivang: MOTU & UVF - we want to have universe in extra-good shape for dapper
<HiddenWolf> I think universe UVF would be good. :)
<ogra> yes, for dapper it would
<ogra> for breezy it wouldnt have been achievable
<HiddenWolf> True, due to the conversions.
<HiddenWolf> but people upping new versions till the release day was kinda odd. :)
<infinity> A universe UVF one month after main's UVF sounds reasonable.
<sivang> ogra: what are plans for MOTU stuff over UBZ?
<HiddenWolf> Anyhow, need to go. bye
<infinity> (Though you're welcome to freeze at the same time, if you think you'll be able to do all your syncs/merges on time)
<ogra> infinity++
<ogra> we're not enough people to cope with the real dates, but a month extra sounds like a great idea
<infinity> Well, I expect we may want to discuss Universe a bit at UBZ anyway.
<infinity> At least, Universe for dapper.
<infinity> Not Universe in general.
<ajmitch> yep
<ajmitch> so much good stuff that people want is in universe
<infinity> In general, Universe is unsupported, archive locks down when we release, the end, sucks to be you.  And I'm cool with that.
<ajmitch> then we beg to put fixes in -updates, etc
<infinity> But for a 3/5-year supported release, we may want to pay a bit more attention to make sure the unsupported Universe at least gets enough love to not be a mess at release time.
<ajmitch> you wouldn't be able to recruit another 50 MOTUs for us, would you?
* Lathiat grins
<infinity> No, but there are ways to make it workable.
<ajmitch> ogra: might be time to put out a recruitment mail to the users & devel lists
<ogra> yup
<infinity> Keep your diffs from Debian very small, make sure meges are something that you can do in 5 minutes, not an hours.
<infinity> (And I mean to smack someone around about the diff thing too)
<Lathiat> which diff thing?
<Lathiat> ajmitch: we both need to harass people into sending appropriate patches to debain
<Lathiat> err, debian
<infinity> I've seen many MANY MOTU uploads now that add a patch system for the sake of adding a 4-line patch to the Debian source.
<LaserJock> what about having a level of contribution below MOTU for people to join?
<LaserJock> MOTU can be intimidating
<Lathiat> infinity: well, thats the advise lots of people seemed to be giving out...
<infinity> So, instead of 4 lines in the diff.gz, you now have a 4-line patch, a build-dep on dpatch (debian/control), and a diff to debian/rules.
<infinity> Seems counter-productive to me.
<Lathiat> i thought so to
<Lathiat> but others didn't seem to think so
<ajmitch> infinity: yes, we've been discussing that
<infinity> ajmitch : I can merge a package with a 4-line Debian-Ubuntu diff in about 3 seconds.
<infinity> ajmitch : One with debian/rules and debian/control mangled is more likely to conflict and cause Real Work to happen.  Ew.
<ajmitch> yep
<ajmitch> I've done a number of uploads with just applying the patch, rather than using dpatch
<crimsun> what about changes to source?
<ajmitch> crimsun: that can still be separated out without dpatch
<infinity> crimsun : What about them?... That's what the diff.gz is FOR.
<infinity> The only time it makes sense to use a patch system is when there's already one there in Debian.
<crimsun> infinity: that's what I use; if there's one in place, I use it.
<infinity> (Or when we have a LOT of changes between Debian and Ubuntu, but that's terribly rare, and usually only happens in main)
<Lathiat> on that note, it should be required in the debian policy ;)
<crimsun> there are some packages that already use dpatch that are simply unmaintainable if I apply the changes directly to the source without using dpatch
<ajmitch> crimsun: that's fine, they already use dpatch
<Lathiat> crimsun: as infinity said, if it already uses dpatch its fine
<infinity> crimsun : Well, yes, obviously.  If the packages uses a patch system, use that.
<infinity> crimsun : I'm saying, don't ADD one.
<ajmitch> most of the patches we did were for gcc 4.0 issues
<Lathiat> hopefully alot of that will clear up in dapper
<crimsun> ok, so I misunderstood the intent, and I was following the guidelines all along. Nothing new, nothing to see here. :-)
<infinity> The gcc-4.0 patches shold all clear up in dapper, or mostly so.
<infinity> The libGL changes are something we'll have to carry for anothe release, probably, unless gravity gets Xorg 7.0 in Debian the day it's released upstream.
<infinity> Aside from gcc-4 and libGL, we shouldn't have that many diffs.
<Lathiat> mm, theyre a bit of a hassle
<Lathiat> because those lines have a habbit of changing
<Lathiat> = effort :)
<infinity> Indeed.
<infinity> I'm hoping we can get them sorted in Debian ASAP, so you can drop your patches there.
<ajmitch> and those few dbus-using packages
<ajmitch> another large set we carry is for default python version 
<LaserJock> what is the general policy about sending ubuntu patches to Debian maintainers? If I make a *ubuntu1 or something like that should I be emailing the Debian maintainer?
<Lathiat> LaserJock: well, it depends
<doko> ajmitch: python will clear up as well
<Lathiat> whether it applies to debian or not
<infinity> python versions in Debian shuld jump soon.
<ajmitch> doko: will debian go for 2.4 or 2.5 as default?
<Lathiat> e.g. libGL, dbus dont
<infinity> LaserJock : If you're fixing a bug that applies to Debian too, please forward it to them.
<ajmitch> doko: I haven't heard any rumours of a shift, but I haven't kept track
<doko> ajmitch: first 2.4
<infinity> LaserJock : If it's Ubuntu-specific (ie: packaging related), obviously don't.
<LaserJock> ok, that is what I figured, I just wanted to clear that up
<ajmitch> doko: great, that'll ease the merge load then
<infinity> Universe should ideally deviate from Debian as little as possible, or you guys will be up shit creek.
<Lathiat> any ideas on dates for python?
<infinity> 1000 Debian developers can be reasonably helpful, but not if we keep reinventing the wheel with a couple dozen MOTUs.
<Lathiat> also dbus sicne thats now in experimental
<Lathiat> just wondering about initial merging efforts being wasted
<infinity> It mostly comes down to Debian release managers trying to manage transitions one or two at a time, so sid -> etch testing migration doesn't become such a massive tangle that nothing moves.
<infinity> So, dbus will probably get a green light once the C++ transition looks good, etc.
<infinity> Debian moves a bit slower than Ubuntu with this sort of thing, unfortunately.
<infinity> I have a feeling doko will be pushing for the python transition pretty soon, though. :)
<LaserJock> doko: did you fix Malone #3123 ?
* infinity looks at doko.
<infinity> 'Morning, daniels.
<ajmitch> morning daniels 
<ajmitch> lunch time, bbl :)
<doko> LaserJock: minor
<doko> just install python2.3
<LaserJock> I have to install python2.3 just to get a tutorial?
<doko> LaserJock: it's a bug, I did tell you a workaround, so what? sure, it will be fixed for dapper
<LaserJock> well, that is what I am wondering. I was thinking of trying figure it out. I'm not personally worried about it
<LaserJock> I was just wondering why  python-numeric-tutorial.postinst was getting python2.3 for $PYTHON
<hughsie> ogra: night.
<BenM> mdz, on the wireless bug, i'm having trouble finding a linux laptop that's not a dell 600m
<BenM> is there anything i can do with the affected laptop now?
<bddebian> Hello
<tritium> hey bddebian 
<ajmitch> hello bddebian 
<bddebian> Heya tritium, how's it going?
<bddebian> Heya ajmitch 
<tritium> not bad, yourself?
<bddebian> OK thanks
<dieman> lamont: poke
<daniels> i thought breaking your blog was relatively difficult to do, but then I read planet.u.c and realise that the same ten entries from \sh are at the top again
<Amaranth> daniels: do something to change a timestamp and it's planet \sh
<Mithrandir> Keybuk: any thoughts on 17343?  It's basically "dpkg barfs if user in statoverride doesn't exist", or just close it as user error?
<Keybuk> probably right for it to barf, it can't do what you said
<Keybuk> and that might be critical for security, etc.
<Keybuk> *reads*
<Mithrandir> it might be refiled as "userdel should check for user in statoverride file" and wishlisted instead.
<Keybuk> possibly
<Mithrandir> possibly deluser instead of userdel, though
<pitti> Good morning
<daniels> moin pitti
<Amaranth> daniels: is X in breezy really that bad?
<daniels> Amaranth: it's held together by alarming amounts of duct tape.  it's not long-term supportable; i think that it works is a minor miracle that should result in a payrise for me.
<Amaranth> haha
<Amaranth> any guess on when 7.0 will actually release? from the sound of it waiting for 7.1 would be better
<Burgundavia> daniels, would it have been saner to release a monolithic 6.8.2 and to wait for 7.0 for dapper?
<Amaranth> Burgundavia: 7.0 was supposed to make it in time for breezy, with time to spare
<jsgotangco> 7.0 it'll be fun
<HiddenWolf> Burgundavia, I guess someone needed to make the plunge and break it up, learn from the experience, and get upstream better about it. :)
<Burgundavia> ya, that is what I figured
<daniels> Burgundavia: the plan was to do 7.0 for breezy; it was only after we'd gone far far far far too far to go back that it was decided to defer the rest of 7.0 to dapper
<Amaranth> yeah, i think we were the guinea pigs for modular X :)
<daniels> Amaranth: 7.0 is supposed to release 'soon'.  we're hoping for rc1 this week.
<HiddenWolf> well, only gripe i've got with breezy is that it hardlocks the system when I try running the binary nvidia drivers. Worked out damn well. Props to Daniels. :)
<daniels> Amaranth: after it was decided that we weren't going to do X for breezy, I more or less stopped release-related work on 7.0 (you have no idea how not fun it is), and we started pursuing a less aggressive schedule.
<HiddenWolf> Amaranth, besides, the changelogs where a blast to read. :)
<daniels> HiddenWolf: heh, thanks
<Amaranth> i guess i never paid attention to them
<Amaranth> just "works", "doesn't work, time to pin and hack"
<daniels> in any case, I can't imagine needing to support the monolithic tree for three years
<Amaranth> *shudder*
<HiddenWolf> Amaranth, daniels is an artist when it comes to changelogs. :)
<Lathiat> HiddenWolf: well mine dont hard lock, but i get no 3d :)
<Lathiat> yeh daniel changelogs are great
<Lathiat> daniels: so, how, exactly, did you stitch al of that cruft from X together such that it works?
<bob2> you should totally compile debugging symbols into the module and file a bug
<bob2> oh WAIT
<daniels> should put that on my resum: 'changelog artistry'
<Amaranth> HiddenWolf: I used to do fun stuff like that but I'm too lazy to think up good things to say.
<daniels> Lathiat: 'badly'
<HiddenWolf> Amaranth, make it more fun for us groupies, be creative.
<Amaranth> HiddenWolf: but the only package in ubuntu i touch is smeg, not much to work with there
<Amaranth> i suppose i could swear a lot...
<HiddenWolf> Amaranth, fix up something cool for me.
<HiddenWolf> like, ehm, uwh. *tries to think of something cool and useful that's not default ubuntu yet*
<Amaranth> all of the redhat config tools i was working on got ubuntu replacements
<jsgotangco> oracle
<jsgotangco> heh
* jsgotangco hides
<Amaranth> they made me swear a lot anyway
<HiddenWolf> who needs oracle. :)
<bob2> is smeg in Debian yet?
<HiddenWolf> Amaranth, who needs redhat.
<Amaranth> bob2: maybe?
<Amaranth> bob2: I haven't tried getting it in.
<jsgotangco> HiddenWolf, Amazon uses it? heh
<bob2> due to lack of interest or time?
<Amaranth> a little of both
<HiddenWolf> jsgotangco, their loss. :)
<jsgotangco> yeah right
<jsgotangco> heh
<Amaranth> i wrote it for ubuntu specifically, it seems other distros all like to hack things differently and anything running GNOME 2.10 is a nightmare
<bob2> is smeg obsolete in 2.6.12 then?
<bob2> er
<bob2> "gnome 2.12"
<Lathiat> no because the inbuilt one sucks
<Amaranth> no, 2.12's gmenu-simple-editor only lets you show/hide existing entries
<Amaranth> this is why breezy uses smeg instead :)
<bob2> so there's no current way to edit menus at all in sid, and in experimental the method is crap?
<bob2> mind if I ITP it then?
<Amaranth> if you want
<Amaranth> but it doesn't have any translations and 0.8 is nearing release (for the 3rd or so time)
<Lathiat> Amaranth: you away from college or something?
<Amaranth> Lathiat: Nope, I just finished one of my projects in 2 days, it was supposed to take 2 months. :)
<Lathiat> lol
<Amaranth> It's fun knowing more HTML than the teacher.
<Lathiat> haha
<HiddenWolf> daniels, btw, is there any way to get my thumbbuttons working (mouse) without imwheel?
<Amaranth> 3 months to make a 5 page website, we were supposed to learn a tag and add it to our site as we went
<Amaranth> err, 2 months
<HiddenWolf> Amaranth, LOL
<Mithrandir> HiddenWolf: Just Works for me. :-P
<bob2> what degree is this?
<Mithrandir> HiddenWolf: evdev is rumoured to work, too
<Amaranth> tech school is a joke
<bob2> ah
<Lathiat> my cisco course (1st year) isnt so bad
<Lathiat> multimedia was a joke
<Lathiat> java is a pain in the ass
<Amaranth> but you have to do well in high school or at least, you know, finish to get into a regular school ;)
<daniels> HiddenWolf: probably, with Option "Buttons" "12" or some crap in xorg.conf
<bob2> Lathiat: the only thing I know about cisoco training is some of my friends became CCNAs without knowing about CIDR
* Lathiat laughs
<bob2> which disturbs me deeply
<Lathiat> we do cidr stuff
<Amaranth> sounds like MSCE
<Lathiat> in ccna1 in fact
<Lathiat> they probably  just forgot it
<Lathiat> and muddled through the exam somewhow
<Lathiat> :)
<Mithrandir> bob2: the first cisco course is dead easy.  The next one isn't.  Afaik, at least.
<bob2> ah
<bob2> Lathiat: this was a few years ago
<Lathiat> yeh CCNP is harder
<Amaranth> which reminds me, i'm also Word, Excel, and Powerpoint 2000 certified, whatever that means
<ajmitch> poor fellow
<HiddenWolf> Amaranth, that you're an MS-lackey, and hopelessly out of date? ;)
<Amaranth> well, i am on windows right now...
<HiddenWolf> *shakes head*
<Amaranth> i'm broke so i've got windows only dialup (some compuserve knockoff) and a windows only modem
<Lathiat> heh joy
<HiddenWolf> Youch.
<Lathiat> stick it in a qemu and run winroute and route in and out of it. :)
<Amaranth> hmm
<Amaranth> that would be...awesome
<Amaranth> got a link? google just gives me junk about firewalls
<Lathiat> cisco finally fixed their vpnclien tfor linux
<Lathiat> to use an interface
<Lathiat> rather than eating kernel packets going out the ethernet interface at the kernel level and firing them over the vpn
<Lathiat> except they eat packets goign out *all* interfaces
<Lathiat> so i cant use bluetooth networking, etc
<Mithrandir> Lathiat: use vpnc instead?
<Lathiat> Mithrandir: doesn't work at my uni
<Lathiat> somethign aout tcp tunnels
<Mithrandir> ook.
<Lathiat> Amaranth: yeh winroute is a combined firewall/route/other shit for windows
<Mithrandir> route through a qemu instance or some other crack, then.
<Lathiat> havent used it in years tho
<Lathiat> Mithrandir: well i could do it in a windows qemu
<Lathiat> Mithrandir: but i couldnt do it in a linux one
<Mithrandir> oh, why?
<Lathiat> (because itd eat the ethernet im trying to route through!)
<fabbione> hmmm
<Lathiat> but they fixed it anyway now
<Lathiat> in 4.6 or whatever
<bob2> that's really quite fucked
<Amaranth> winroute sounds like an expensive wrapper around Internet Connection Sharing
<Lathiat> only just last week tho
<fabbione> there was a nice hole in the Cisco VPN client that was dead easy to exploit
<Lathiat> bob2: i thought so
<bob2> unless they use route tags or something
<Lathiat> Amaranth: yeh but it actually does proper routing, i suppose ICS could do it
<Amaranth> i think the main thing is getting qemu access directly to the hardware
<bob2> however you're supposed to route ipsec on 2.6
<Lathiat> Amaranth: its pci right?
<Lathiat> Amaranth: (qemu does that)
<Amaranth> yeah
<Amaranth> this is getting better and better :)
<bob2> I dispute your use of "better" for a plan involving both running windows and letting qemu poke pci devices!
<pef> hello
<Lathiat> bob2: hehe
<Amaranth> bob2: It means internet on linux, it's better than xchat for windows and tortoisecvs
<Lathiat> Amaranth: are you developing smeg on windows? ;p
<Lathiat> python, gtk2 for windows and cygwinX? ;)
<Amaranth> nope, i reboot to work on it
<Lathiat> ah
<Lathiat> poor soul :)
<Lathiat> well i figure
<Lathiat> its probably more productive
<Amaranth> it's not
<Amaranth> i keep playing blobwars
<Lathiat> haha
<Lathiat> uninstall it ;p
<Amaranth> i'd lose all my progress :(
<Amaranth> i beat it on easy, now i'm doing it on hard
<Mithrandir> infinity: shall we just close 11355 as WFM?
<Lathiat> lol "harvesting cherries and studying astro physics"
<Amaranth> Lathiat: got any sites that explain exactly what to do?
<Amaranth> Lathiat: or will it "Just Work"?
<Lathiat> Amaranth: for the qemu thing?
<Amaranth> yeah
<Lathiat> Amaranth: you just need to setup that pci device to go into windows
<Lathiat> and then your right ICS will probably do
<Amaranth> go into windows is the part i don't understand ;)
<Amaranth> ack, it requires a kernel patch?
<Lathiat> it does
<Lathiat> ?
<Lathiat> that sucks
<Amaranth> anyway, bed time
<Lathiat> Amaranth: do you know what im doign right now? :(
<Amaranth> what?
<Lathiat> playing blobwars
<Amaranth> haha
<Amaranth> "Actually, a linux host CAN give that access, as long as it is a PCI card you are giving the guest access to - but then only the guest can use it exclusively."
<Amaranth> yay
<dholbach> good morning
<pitti> Hi dholbach 
<dholbach> hey martin :)
<njr> Congrats, guys - Breezy is a work of art.
<sivang> Morning all!
<sivang> hey dholbach , pitti 
<pitti> Hi sivang 
<dholbach> hi sivan :)
<sivang> hey dholbach 
* sivang brb
<tepsipakki> is there hope for pam >0.76 for dapper?
<dholbach> good morning seb! :)
<ajmitch> tepsipakki: since 0.79 is in debian, I'd say it's likely
<seb128> hi dholbach
<ajmitch> tepsipakki: is there something that you need in > 0.76?
<tepsipakki> ajmitch: ok, didn't notice that..
<tepsipakki> ajmitch: well, nothing that I can point right now ;)
<ivoks> uh, that samba :/
<dholbach> morning mvo
* jsgotangco looks at dholbach face on p.u.c.
<mvo> hey dholbach 
<bob2> that's a lovely flower
<ajmitch> dholbach: great photo there :)
<dholbach> :-p
<mvo> haha
<jsgotangco> looks good as a wallpaper
* \sh blames planet software for spamming the planet with my postings again *gnarf*
<jdub> STALKER!
<jsgotangco> nice i have a new wallpaper
<jsgotangco> time to post to planet
<jsgotangco> heh
<Treenaks> jdub: where?!
* ajmitch needs to put his blog someplace where it could withstand planet punishment
<\sh> ajmitch: i can give u space + bandwidth ;)
<\sh> ajmitch: and a nice s9y ,-)
<ajmitch> \sh: then I'd just need content :)
<jdub> \sh: dude, it's your blog software giving it the irrits
<jsgotangco> sure write like mako
<\sh> ajmitch: no I can't write your blog ;)
<ajmitch> haha
<\sh> jdub: NO ! s9y is rss2 conform
<ajmitch> \sh: but I don't speak german ;)
<Treenaks> ajmitch: Warum nicht? ;)
<\sh> ajmitch: so...s9y is available in many different languages ;)
<jdub> you can push valid rss2 and still be pushing stupid crap
<\sh> jdub: do u have a debug logfile...so we can have a look in it...at least I can work around planets bug ,-)
<\sh> jdub: i need something on how planet makes the decision what planet saw and what he will see 
<jsgotangco> bollywood dreams...
<\sh> hmmm...is there a small netinstall image which fits on a 16mb or < 128mb usb stick?
* magnon notes that 16mb is <128 anyway :P
<\sh> magnon: well...yes..better to say 16 > N < 128 ,-)
<magnon> right ;)
* magnon was at the yearly meeting for his youth political party this weekend and is very very formal and picky today
<hunger> When will the dapper repository go online? tomorrow?
<bob2> hunger: /topic
<magnon> it says about tomorrow in the topic
<hunger> bob2: Aehm...sorry. Don't have the topic visible in this client at all times.
* hunger should do something about his new-debs addiction:-)
<mvo> ping mdke 
<mvo> mdke: could you please correct string 42 of update-manager in rosetta? A typo in the markup (or anyone else from the italian translations team)
<ogra> Kamion, ping.... edubuntu DVDs are good to go (modulo ppc)
<Kamion> Keybuk: how're we going to cope with this "you must PURGE the hotplug package!" business?
<Keybuk> I've a planned set of specs
<Keybuk> we really need to fix all that stuff anyway
<Keybuk> because breezy released in a mess
<Kamion> right
<pitti> Keybuk: nice, you did already? to get rid of hotplug maps, etc.?
<Kamion> ok, if you have a clue what to do, I don't really want to know ;-)
<sabdfl> breezy released in a mess?
<pitti> sabdfl: we still use a lot of obsolete hotplug/udev scripts and the like
<pitti> sabdfl: we made it reasonably working, but it is no option for a 3 year desktop release
<Kamion> Keybuk basically spent two weeks kludging it into submission ;-)
<pitti> sabdfl: e. g. hotplug maps will become hopelessly out of date, since new hardware is developed constantly
* Kamion creates dapper seeds
<sabdfl> right, we need the new devfs, right?
<Kamion> devfs is dead ...
<pitti> sabdfl: well, we need to get rid of this usb procfs
<pitti> sabdfl: right now, scanners and cams access /proc/bus/usb/001/005, for example
<Keybuk> sabdfl: little things ...
<pitti> sabdfl: but this is braindead
<Keybuk> like, oh, plug in any removable device before you boot
<Keybuk> hoary it mounts and works fine
<Keybuk> breezy goes "la la la" and ignores it
<pitti> Keybuk: I thought we caught that?
<Keybuk> Kamion: yup, I know
<Keybuk> pitti: nope!  sometimes it works, mostly it doesn't
<pitti> Keybuk: by switching back hotplug.d->hotplug?
<pitti> bah
<pitti> yes, things like that
<Keybuk> pitti: no, hotplug isn't even run is the problem
<sivang> rehi all, what's the current discussion ? :-)
<Keybuk> because the block events happen in initramfs
<Kamion> Keybuk: know what?
<Keybuk> so all that userspace stacking we have doesn't get a look-in
<Keybuk> Kamion: how to deal with it
<Kamion> ah, right, good
<Keybuk> Kamion: sorry, you caught me right as TAKE A BREAK! came up
<pitti> Keybuk: ok, we should spend a fair amount of time and spec to clean this up
* Kamion is currently doing the upgrade on a Debian system and hoping it comes back up ;-)
<Keybuk> pitti: yes, I added lots of little ones to the BOF list ... I have a two-release (one year) plan in my head for it all
<sivang> pitti: whose the successor for hotplug ?
<Keybuk> sivang: udev
<infinity> Mithrandir : May as well (re: 11355 WFM), the submitter hasn't responded to any of the WFM comments with additional info.
<Seveas> hmm, zilla died?
<Seveas> ignore, it's back :)
<Riddell> Kamion: fancy reviewing some kubuntu breezy-updates sometime?
<Kamion> Riddell: sure, send me mail
<ogra> Kamion, saw my statement about the edubuntu DVDs above ?
* Riddell bounces
<zakame> hi all
<Kamion> ogra: oh, yeah, briefly forgot, will sort that out now
<ogra> Kamion, thanks :)
<Kamion> ogra: so both amd64 and i386 have been tested in default, server, and workstation modes?
<ogra> yup
<zakame> what do I do if I wanted to compile an external kernel module for breezy, and breezy lacks gcc-3.3.5, which the 2.6.12 kernel was compiled on?
<ogra> \sh, witnessed it this weekend... while we were at it we quickly worked out multiarch ltsp :)
<fabbione> zakame: the kernel was compiled with gcc-3.4
* Yagisan has eyes light up at mention of multi-arch
<ogra> Yagisan, your patch needs some fixage, but after that worked fine :)
<zakame> fabbione: not according to /proc/version
<Yagisan> ogra: what was wrong ?
<fabbione>  cat /proc/version 
<fabbione> Linux version 2.6.12-9-amd64-k8 (buildd@king) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:13:36 BST 2005
<ogra> Yagisan, we dont have our chroot in ~/ ;)
<fabbione> i read 3.4 there
<fabbione> zakame: the kernel compiler is forced.. there is no way it could have been built with 3.3
<ogra> Yagisan, i fixed the second script snippet you have in the patch... once i reviewed and tested more, i'll add the updated version to the bug
<fabbione> not by us at least
<zakame> fabbione: wait, gcc-3.4 isn't shipped in the cd :((
<pitti> zakame: neither are the kernel sources
<Yagisan> ogra: oops - thank's for catching the typo
<zakame> pitti: not the sources, but the headers are ;)
<pitti> zakame: right
<Mithrandir> infinity: it's your bug, so I'll leave it to you. :-P
<pitti> zakame: but shipping two compilers on the CD would even more be a waste than shipping one
<infinity> Mithrandir : Bah, if you leave it to me, I'll be inclined to DTRT by installing this Netware trial I downloaded and testing.
<zakame> pitti: but shipping no compiler where the kernel is built on is also unsettling ;(
<infinity> Mithrandir : Best if you close it before I have to do that. :0
<pitti> zakame: so what, you can easily download it
<pitti> zakame: the CDs are already tight enough
<infinity> The past argument for compiler+headers on the CD has always been that if your network requires a custom-compiled kernel module, you're screwed.
<zakame> pitti: that would be fine for my current setup, but think about other setups where downloading isn't easy
<infinity> I have a feeling breezy's lack of kernel compiler has more to do with it not being explicitely seeded, because we always used to ship "gcc" and the headers (and probably still do)
<Kamion> yeah
<Kamion> neither explicitly seeded nor (build-)depended-upon
<pitti> zakame: I know, but we need to fit a good desktop on the CD, we can't ship all development stuff, too
<Lathiat> i had that issue at uni the other day
<Lathiat> needed to compile a cisco pn client
<Lathiat> *vpn
<pitti> zakame: but you can use the DVDs if you need everything off-line
<Lathiat> and couldnt get to an archive unless i did
<pitti> zakame: also, maybe we can build future kernels with the default compiler again
<zakame> pitti: that could do, but i'm a wimp and i don't have a dvd drive at hand :(
<zakame> i am saving up for a dvd combo drive though :)
<fabbione> Kamion: well the kernel must B-D on gcc-3.4 and it does..
<pitti> zakame: compiling your module with 4.0 doesn't work?
<Lathiat> pitti: no, why should it?
<Lathiat> the kernel is compiled with 3.4
<pitti> Lathiat: so what?
<Lathiat> and trying to load a module compiled with 4.0 the kernel will bark at you
<zakame> pitti: works, but the versioning detection of the kernel prevents it to work
<pitti> Lathiat: oh, I didn't know that - there is no intrinsical reason why it should
<pitti> probably just a safety measure then
<Lathiat> pitti: yeh the kernel includes gcc version and some other stuff in the module
<Lathiat> you can override it
<infinity> You can always force insertion, if you really need something to work.
<infinity> But it'd still be nice to have kgcc on the CD.
<zakame> hmmm, pardon my ignorance, but how do I do force insmod again?
<infinity> Too late for breezy at any rate, so not much point in whining about it.  I suspect one or more of us will remember for dapper.
<Lathiat> modprobe -f
<Lathiat> no idea about insmod
<zakame> Lathiat: thanks :D
<zakame> infinity: hopefully :)
* infinity wonders if we could add a "kgcc" meta/symlink package to gcc-defaults, to more easily identify/select the kernel compiler.
* infinity looks at doko.
<zakame> so, the other solution for breezy would be to get linux-sources and kernel-package, right?
<Lathiat> is it possible dappers kernel might be compiled with gcc4?
<infinity> Unlikely.
<infinity> I doubt that gcc4 will like the kernel (or the kernel like gcc4) any more with the next minor revision of each.
<doko> infinity: good idea, but that should be built from a separate source. I don't mess around with kernel maintainers, which compilers should be used
<fabbione> doko: give us a compiler that builds on all arches first :P
<mvo> Kamion: would the debdiff in #17946 something for breezy-updates?
* mvo inserts a "be" at the appropriate place in the last sentence
<doko> fabbione: I thought spaaarc did release, so it must have a compiler :-P
<zyga> morning
<Kamion> mvo: the translation breakage is annoying
<Kamion> can we fix just the error and leave the broken message for dapper?
<mvo> Kamion: right, that can be fixed by leaving the old (potential incorrect) error message
<zyga> mvo: hi :-)
* mvo waves to zyga 
<zyga> mvo: I've got something to show you :)
<mvo> zyga: I hope something nice :)
<zyga> mvo: yes :)
<zyga> a mockup of new gui tool for translation providers :-)
<zyga> ATM I've got a glade file
<mvo> zyga: I'm curious :)
<zyga> :>
<zyga> mvo: I can give you the .glade if you want to have a loook now :)
<mvo> zyga: yes please. either mail it to me or put it on the web somewhere :)
<zyga> mvo: just mounting /www
<zyga> mvo: or better
<zyga> mvo: how about a tla/baz/bzr archive?
<zyga> which one do you prefer?
<zyga> mvo: pick one and msg me, I need to grab some food 
<mvo> zyga: bzr please
<zyga> mvo: okay, one secon
<zyga> mvo: http://www.suxx.pl/ubuntu/gnome-translation-providers
<zyga> I didn't ever publish any bzr archive so tell me if it works
<zyga> I did an import+commit
<zyga> and then cp -R to /www/... 
<mvo> zyga: looks good, just "bzr get" it. there is a "bzr push" plugin that may be interessting for you to publish your changes
* mvo thinks that bzr rocks really really hard
<zyga> mvo: how to get the push plugin?
<zyga> any .deb to pull?
<mvo> zyga: it's in jeff bailys archive 
<fabbione> doko: right :) just dont' break it more :P
<zyga> mvo: apt-source if you may :-)
<zyga> ...
<zyga> sources.list line if you may :)
<sivang> HI mvo :) , this is waht I rolled on last night inspired by my bug report , https://wiki.ubuntu.com/OneClickI18n
<sivang> s/HI/Hi/
<mvo> zyga:  deb  http://people.ubuntu.com/~jbailey/snapshot/bzr ./
<Mithrandir> pitti: what do I need to twiddle to get back my old permissions in /proc/bus/usb?  This was changed fairly late in the breezy cycle, iirc?
<pitti> Mithrandir: actually not, it works that way since warty
<pitti> Mithrandir: what are your "old" permissions?
<doko> fabbione: it's not X ;-P
<mvo> sivang: oh, thanks. looks like a lot of people are interessed in this
<Mithrandir> pitti: some g+rw at least.  I don't want to run gpg as root to access my openpgp card.
<pitti> Mithrandir: uh, I only ever dealt with libsane and libgphoto, not with other USB crack
<Mithrandir> pitti: .. what was the fix in sane?
<sivang> mvo: yes I know :) 
<sivang> mvo: this would also help me reduce 90% of the noise about that over my local community
<pitti> Mithrandir: the real fix is to drop all these hotplug scripts, usermaps, and accessing of /proc/bus/usb by apps
<zyga> mvo: bzrtools?
<zyga> that's the packge?
<mvo> zyga: yes
<pitti> Mithrandir: and instead use udev to create a proper device in /dev, and make libsane/libgphoto use it
<sivang> zyga: what's the gnome-translation-providers app going to do?
<zyga> sivang: ah, that's a long story
<Mithrandir> pitti: and the "I just want this to work, dammit" fix is just to what the hotplug scripts?
<zyga> sivang: check my blog for initial idea: http://www.suxx.pl/blog/index.php/next-generation-l10n-system/
<mpt> arg
<pitti> Mithrandir: libsane intermediately switched to a hotplug.d script, which brkoe
<zyga> sivang: g-t-p will be a end-user tool for manipulating translation providers
* mpt falls into the tarpit of glade
<zyga> sivang: update-manager will be upgraded to support them
<mvo> Kamion: fix for #17946 updated, can/should I upload? or wait a bit and see if something else comes up for gksu?
<Mithrandir> pitti: etc/hotplug is teh new and shiny now, right?
<pitti> Mithrandir: so I switched it back to /etc/hotplug/usb/libsane, as in hoary and warty
<zyga> okay
* zyga is off to dinner
<pitti> Mithrandir: no, it is even older than hotplug.d
<zyga> I'll be back in an hour :-)
<zyga> comments welcome
<pitti> Mithrandir: but both ways are obsolete
<mvo> zyga: are you on planet.ubuntu ?
<zyga> mvo: no I need to be a member for that
<pitti> Mithrandir: this usb file system will disappear in the kernel (in .14?)
<mpt> zyga: What's a use case for wanting to change the translation providers?
<zyga> mvo: I'd love to be a member BTW :-)
<mpt> Is there a spec on it?
<Mithrandir> pitti: *sigh*, what's the newfangled way to do it?  Add a udev script in /etc/udev/rules.d?
<pitti> Mithrandir: and udev with proper /dev nodes is the way to go (it was just too late for breezy)
<mvo> zyga: and you aren't? come to the next CC meeting then
<pitti> Mithrandir: yes
<zyga> mvo: will do
<Mithrandir> pitti: are those scanned on each udev event, so I can just hack it, or do I need to reboot and such?
<zyga> mpt: trivial use case: I'm paid by an organization to translate evolution, they need to get up-to-date messages every day, after my work is done I can upload everything upstream
<zyga> mpt: another use case: I collaborate with a group of friends and provide translations for interesting applications, upstream denies updates as they feel our work is insignificant/bad
<zyga> mpt: a group of translators, say gnomepl.org is providing easy-to-get translations for all gnome apps
<zyga> mpt: you dont want to trust the distributor to pick every signle translations - you can pick them yourself and then send upstream if you whish
<zyga> mpt: another use case: ubuntu is using clean upstream translations and then provides an overlay for all ubuntu-specific strings
<zyga> mpt: that's not all obviously but I hope you get the idea anyway :-)
<mpt> hmm
* zyga really needs to go
<mpt> yeah
<zyga> I'll be back in one hour
<zyga> c'ya then
<mpt> it just seems really complicated to me
<mpt> tchau
<pitti> Mithrandir: and read sysfs attributes to decide about the device class, instead of playing catch-up with silly hotplug maps
<Mithrandir> pitti: hmm, but then I suddenly need inode numbers and other silliness, don't I?  Or I can possibly wrangle it out from /sys?
<pitti> Mithrandir: why inode numbers?
<Mithrandir> pitti: because dev nodes have them?
<pitti> Mithrandir: erm, I don't understand
<Mithrandir> pitti: I'll just fiddle around and see what I manage to break. :-)
<pitti> Mithrandir: you ask udev to create a /dev/usbscanner0 for a new USB scanner
<pitti> Mithrandir: and query device class etc. from sysfs
<desrt> pitti; g'morn
<Mithrandir> pitti: yes, but I supposed it needs major/minor number?
<Kamion> mvo: go ahead and upload; it'll sit in a queue for a bit anyway :-)
<pitti> Mithrandir: yes, of course
<pitti> Hi desrt 
<pitti> Mithrandir: not sure whether they are already defined
<mvo> Kamion: ok, I'll upload to 'breezy-updates' then, thanks
<pitti> Mithrandir: there are definitively numbers for SCSI scanners
<Mithrandir> pitti: this is an USB smart card reader. :-)
<pitti> Mithrandir: but I'm not sure about camera scanners
<pitti> Mithrandir: no idea about those, sorry
<Lathiat> umm, with XFS, the equivalent of 'user_xattr' works by default right?
<Mithrandir> pitti: it says driver -> ../../../../../../../bus/usb/drivers/usbfs/, though.. That looks suboptimal
<jdub> Keybuk, Diziet: what's the current thinking about the alternative proposal on http://www.dpkg.org/Triggers ?
<Keybuk> "current thinking" ?
<pitti> Mithrandir: this shift did only take place in kernels recently
<jdub> Keybuk: you know, those noises in your head
<bob2> like headaches with pictures
<Keybuk> jdub: to be honest, I put no further thought into it after writing it down after debconf
<Keybuk> "not for dapper" :p
* jdub way pefers the alternative design
<jdub> was discussing just that with some of the RH guys during the summit
<Keybuk> I like it, but I'm also not convinced
<Keybuk> it's a bit mad
<Keybuk> come to my LCA talk <g>
<hughsie> pitti: you got a minute?
<jdub> asked Kamion if it were sane,  he pointed out that it was alreayd there
<Keybuk> it does seem like the kind of thing the package manager could do, doesn't it
<hughsie> ogra: help!
<jdub> Keybuk: and only requires a tidbit of configuration from single, tool-owning packages
<jdub> rpm has hacks in it for stuff like this
<jdub> rpm itself
<Keybuk> right
<Keybuk> I've looked at rpm a lot recently
<Keybuk> for example rpm's evil stuff to deal with 32-bit/64-bit shit
<jdub> the only bit i was concerned about was ownership of generated files
<Keybuk> I have a personal distaste for anything "hard-coded" like taht
<bob2> rpm doesn't have multiarch either?
<Lathiat> whats that apt-cache command that prints out available versions
<Lathiat> like the hidden one
<Lathiat> with a girls name
<bob2> policy
<bob2> or madison
<Lathiat> madison, thats the one
<Keybuk> apt-cache madison
<Keybuk> though policy gives more info
<Keybuk> elmo: which madison is that named after ?!
<sivang> lol
<jdub> avenue!
<lamont> dieman: eep
<Kamion> ogra: http://cdimage.ubuntu.com/edubuntu/releases/breezy/release/ - link added from releases.u.c too
* sivang didn't know apt has such hidden easter eggs :)
<Kamion> Keybuk: Madison Michele according to katie/docs/README.names
<Kamion> sivang: it's hardly "hidden" - it's in the man page, although admittedly not in the --help output
<jdub> Keybuk, Kamion: hmm, alternative triggers is interestingly related to proposed classes functionality
<Keybuk> noticed that too, eh <g>
<Keybuk> "when doc installed into <path>, run scrollkeeper"
<dieman> lamont: was wondering how big the scc archive is.
<infinity> dieman : Less than half the size of the FCC archive, at a guess.
<infinity> Or, wait.  No.  More than half.
* infinity can't be bothered to actually check.
<infinity> dieman : You could just run a --dry-run rsync and see.
<infinity> dieman : Note that ports doesn't have source, so it's just 3 binary arches (with fewer packages built, and fewer released versions than the FCC arches)
<dieman> ahh, k
<dieman> thanks
<dieman> i was asking lamont because he was asking for a us mirror 
<dieman> it shouldn't be a huge problem
<jdub> infinity: s/FCC/supported/
<infinity> jdub : FCC is easier to type, and dieman knew what I meant.
<mdke> Kamion, is the TB the correct place for a proposal for an ubuntu-docs update or can/should it be done by approaching you/mdz/A.N.Other?
<jdub> evil language :)
* Kinnison 's partner is installing breezy on an amd64
<Kinnison> it is sat saying "no installable kernel was found"
<nomed> nvidia driver let me use just 800x600 res on toshiba satellite laptop (i should use 1024x768)
<Kinnison> this is very odd indeed
<Kinnison> any clues?
<Kinnison> Kamion: ^^
<Kamion> mdke: the TB seems like overkill; we have an established policy for -updates
<nomed> the card is GeForce4 420 Go 
<Kamion> mdke: probably best to mail mdz
<infinity> nomed : Does it work with the 'nv' driver?
<nomed> infinity: yes
<Kamion> Kinnison: look for base-installer: in /var/log/syslog
<Kamion> Kinnison: chances are that 'apt-get update' failed to read from the CD
<mdke> Kamion, alrighty, i'll do that
<mdke> Kamion, is the policy documented?
<Kamion> mdke: I think mdz restates it virtually every time the subject comes up on -devel ...
<mdke> Kamion, i'll have a search then
<infinity> nomed : Try 'Option IgnoreEDID "1"' in your xorg.conf
<Kinnison> Kamion: what do we try for fixing that?
<Kamion> it's something like "simple, obvious, and safe", or something similarly like what you'd expect for updates to a supported release
<infinity> nomed : In the Device section.
<Kamion> Kinnison: first confirm that that's actually the problem
<zyga> re
<zyga> modem died again, argh :/
<Kinnison> Kamion: seems to be
<Kinnison> Kamion: "apt-update failed: 1"
<Kinnison> s/-//
<Kamion> Kinnison: second, standard advice is (a) burn at a lower speed if possible, (b) invest in disc/drive cleaning kit
<Kinnison> s@//@/ /@
<Kinnison> Kamion: right
<nomed> infinity: ok
<mdke> Kamion, ok i think we ought to be able to satisfy that :)
<Kinnison> Kamion: we'll try, thanks
<Kamion> Kinnison: the installer gives that advice in some other situations, but there are so many places where a failed CD read can kill things ...
<Kinnison> right
<jbailey> jdub: ping?
<jdub> jbailey: pong
<zyga> mvo: when is the next CC meeting?
<mdke> zyga, a week tomorrow, see the wiki page
<mvo> zyga: 25.10 it seems (see topic in #ubuntu-meeting)
<pitti> Kamion: do you happen to have the ssh GSSAPI patch (CAN-2005-2798) easily available?
<pitti> Kamion: if not, I can pull it from upstream cvs (not a problem), but maybe I can save the effort
<Kamion> pitti: mailed
<pitti> Kamion: thanks a lot
<zyga> yay, crappy new exploit for firefox/thunderbird/epiphany/ and everything else based on gecko
<pitti> zyga: ?
<zyga> pitti: slashdot
<zyga> pitti: works and locks the browser in endless htmlparse loop
<zyga> tested on ff/epiphany 
<zyga> looks fixable though (check the attached source)
<zyga> BTW: what *is* based on gecko/
<trulux> heya
<pitti> Hi trulux 
<trulux> pitti: heya! I've been looking for you the last two weeks!
<trulux> How's it going?
<elmo> infinity/lamont: is b-at still in the buildds to-do list?
<pitti> trulux: well, I was online throughout the day
<Kamion> zyga: depressingly short exploit code there
<infinity> elmo : Yes.
<elmo> good good
<infinity> elmo : I meant to discuss that with you, but I'm assuming doko already has?
<elmo> hum?
<infinity> elmo : We wanted to build gcc-4.1 on all arches, pre-seed the b-at chroots with it, and have you do an import.
<elmo> with one buildd per arch?
<trulux> pitti: you should join the ubuntu-hardened channel, we are much more active now and need your word
<elmo> in any event - no prob for me
<infinity> elmo : won't take that long... Just not as fast as the last build.
<elmo> pitti: WORD TO YOUR MOTH... oh never mind
<pitti> trulux: I could not yet review your latest  packages, I was (and am still) too busy 
<infinity> elmo : But there's a catch.  We want to actually upload and save the binaries this time, so we can test them.
<elmo> infinity: just don't do it yet - I need to do a mini-micro-petite b-at partial run, to get some test uploads for daniel
<trulux> pitti: I see, no worries. But be prepared for a bunch of good news
<trulux> :)
<elmo> infinity: we can do that, I guess
<infinity> elmo : Yeah, s'cool.  It's not urgent, though we may want to do it in time for UBZ, so we can disuss the results there when deciding on toolchain stuff.
<elmo> dude, UBZ is like 9 days away - you'll bearly get main built, even if we start now
<infinity> 12 days, but yeah.
<infinity> Just main would be fine for discussion purposes.
<infinity> (If it's building during UBZ, that's also fine, it's not like we'll be taxing the buildds with anything ELSE while we're all at the conference)
<zyga> Kamion: that's a good sign
* zyga is building firefox and hopes to fix this ;-)
<bddebian> Hello
<jbailey> 12 days?  Phear.
* Treenaks can't wait
<bddebian> 12 Days 'til what?  UBZ?
<Treenaks> yeah
* bddebian can't go because of you commies.. ;-P
<Treenaks> bddebian: commies? where?
<bddebian> Aren't all you "Free Software" types communists? ;-)
<jbailey> bddebian: If you have problem with Soviet Canuckistan, then Soviet Canuckistand has problem with you.
<jdub> https://wiki.ubuntu.com/AutopackageIntegration
<jdub> !!!!
<zyga> jdub: autopackage strikes again ;-)
<dholbach> jdub: sounds like a famous last words...
<dholbach> oh that page really exists :)
<zyga> lol
<Treenaks> jdub: om
<Treenaks> jdub: omg, even
<zyga> pitti: who is in contact with ff upstream?
<jdub> well, there is a bunch of stupid crap on the bofs page anyway
<pitti> zyga: Diziet might be, but I'm not sure
<zyga> Diziet: ping
<Keybuk> doko: when are you updating the Python in Debian to 2.4 ?!
<Yagisan> please please don't do autopackage - it's bound to be a support nightmare
<zyga> Yagisan: let's support autopackage by providing a third-party-native-hook
<Keybuk> don't worry, if anyone seriously suggests AutoPackage, I know where I can get an AK-47
<zyga> either third party builds native debs for given distro
<Keybuk> and I'll shoot their balls off
<zyga> or autopackage says 'sorry, go away'
<Treenaks> Keybuk: only their balls?
<Keybuk> Treenaks: do you know how much pain a bullet to the testicle can cause?
<zyga> Keybuk: AK-47?
<Treenaks> Keybuk: a lot, no doubt
<Yagisan> If It integrated into apt I would not worry - but it spews crap everywhere
<Keybuk> then they'll beg for one to the head
<doko> Keybuk: talking with the release-team: not before kde is in testing
<mdke> what if they are a woman?
* mdke looks at the BOF
<Yagisan> It's not hard to maintain a 3rd party repo - I maintain 3rd party ubuntu repos
<Keybuk> heh
<Treenaks> mdke: they have sensitive places as well ;)
<mdke> true
<Keybuk> mdke: I credit the fairer sex with more intelligence than to suggest it :p
<Yagisan> can you imagine on #ubuntu - I installed a backported firefox via autopackage and my system is hosed - help wahhhhh
<mdke> Keybuk, see the BOF posted by jdub
<Treenaks> Yagisan: People already do that
<Yagisan> Treenaks: at least they can downgrade with apt
<Keybuk> mdke: which one?
<mdke> Keybuk, AutopackageIntegration
<Keybuk> mdke: right, that's what I was refering to
<Keybuk> sorry, I thought for a second that you meant jdub had _suggested_ such a BOF
<Keybuk> and I was going to have to kill a friend
<zyga> pitti: it's fixed in 1.5.x
<mdke> no, no
<pitti> zyga: great, let's hope that they backport it quickly
<infinity> pitti : Will I get any support from you if I propose a "MinimisingDuplication" spec, focusing on removing as many duplicate apps/libs from main as we can (multiple versions of libdb, libmysqlclient, libpng, local/static copies of zlib, pcre, libdb, libneon, etc...)?
<dholbach> infinity: + gnome1 :)
<pitti> infinity: you will have my full support :-)
<infinity> Do we have much gnome1 stuff in main still?
<pitti> infinity: add libnss3 and libnspr4 :-)
<Kamion> infinity: not a lot in main; the chief user in universe is gnucash
<bddebian> Hehe, gnucash
<jdub> xmms in main :|
* bddebian hides
<Diziet> I'd quite like to get rid of gs-esp.  Do we know why it's still hanging around ?
<bddebian> How about we move to the unstable/development branch of GNUCash?? ;-)
<infinity> Diziet : Because gs-gpl doesn't support all the same crap, apparently.
<infinity> Diziet : A gs-esp based on the current gs-gpl version would be nice, at least.  A unified package would be nicer.
<elmo> ironically theonly thing that d or b-d on gs-esp is *-desktop
<bddebian> ??
<infinity> elmo : Yeah, and that's an | dep.
<elmo> (in main)
<infinity> elmo : gs-esp and gs-gpl are (meant to be) interchangeable.
<elmo> infinity: oh is it?  hum, I thought melanie knew about them, but apparently not
<infinity> We could kick -esp to universe, though, and still have the | dep in -desktop, no?
<Diziet> What I mean is, why would anyone want gs-esp ?  breezy's gs-esp is _7.07_ !
<Yagisan> bddebian: will that break my existing gnucash accounts ?
<infinity> elmo : Oh, I lie, it's not an | in -desktop...
<elmo> yeah, I was going to ask how the auto-meta-creation stuff created an | 
<Diziet> 7.07 is hopelessly full of crashy stuff.
<infinity> So, if you install gs-gpl, you have -gpl and -esp installed together.
<Kamion> infinity: er ... -desktop doesn't do |-deps
<Diziet> Yes, and the alternatives are set to prefer gs-esp.
<infinity> Kamion : Yeah, I realised that after I said it.
<Kamion> gs-esp's in desktop as a consequence of the germinate workaround to make sure we put only one gs-* on CDs
<Kamion> I don't really care which it is - it was a doko thing, IIRC
<infinity> Diziet : There's a shiny new gs-esp in sid.
<bddebian> Yagisan: No, we should be able to get better HCBI/aqbanking support :-)
<Yagisan> bddebian: Good, I don't particularly want to get reamed by the tax department if I update then lose access to my accounts.
<bddebian> Of course TB would probably hunt me down and kill me too ;-)
<infinity> Diziet : Based on gs-gpl 8.15, which is also the current sid version.
<infinity> Diziet : So, that should make patching and such easier.  But I still don't necessarily see a reason to keep both in main.
<Diziet> inf: Yes, we might be lucky this time.  I think in general the whole gs versions thing is a nightmare.
<Kamion> bddebian: I don't see why the TB would care about a new gnucash in dapper/universe
<Kamion> bddebian: although shipping development versions is on your own head if it turns out badly
<dholbach> bddebian: is xmms the only thing in main that wants gnome1?
<infinity> Diziet : Well, if someone could convince the two upstreams to merge their respective forks again...
<elmo> xmms doesn't use gnome1?
<elmo> it uses gtk1
<hunger> Is xmms even in ubuntu-desktop?
<Diziet> Which one is the real upstream ?  esp keep taking new gs-gsl's.
<Diziet> s/gsl/gpl
<jdub> no, but it's in main
<infinity> Diziet : gs-gpl is the true ghostscript upstream, but ESP (the upstream for CUPS) does heavy modification to make it more CUPS-friendly, and they include new drivers and such.
<infinity> Diziet : At this point, they've been forking and re-merging for so long, it's almost as much fun as asking which of NetBSD or OpenBSD is the "real upstream"
<dieman> morning.
<Diziet> The CUPS-friendliness doesn't seem relevant any more, although it might once have been.  I mean, you can install only gs-gpl and your CUPS will still work fine.
<Diziet> The driver thing is _really annoying_.
<hunger> jdub: What is the criteria of something being in main? I thought it was being a dependency for one of the ubuntu metapackages?
<Keybuk> Kamion: I was chatting to someone at LinuxWorld who said a gtk 2 version of gnucash is coming soon
<infinity> hunger : There aren't metapackages for the "supported" seed (which determines main)
<ogra> Keybuk, yes, since 4 years
<jdub> hunger: xmms is a build dependency of  a package in one of the supported seeds
<hunger> Ah, I see...
<Kamion> Keybuk: "RSN"
<Keybuk> the claim was by the end of the year
<Yagisan> ogra, Keybuk - hasn't it been longer ?
<Keybuk> I did express "yes! please!" and also reservation they'd make it <g>
<bddebian> dholbach: How would I know? :-)
<bddebian> Kamion: Aye, I was kinda joking :-)
<ogra> Yagisan, Keybuk iirc they announce a gtk2 port "real soon" since 2001
<ogra> but Yagisan might be right and its even longer :)
<Yagisan> ogra, Keybuk: when they do port to gtk2, we'll have gtk3, 4 or 5 :)
<ogra> heh
<bddebian> heh
<Yagisan> ogra, Keybuk - at least it's stable :)
<Keybuk> so's my grandma
* Yagisan thinks etch+1 will be out before gtk2 gnucash
<hunger> Yagisan: Now you are being unfair;-)
* bddebian is getting confused.  Are we talking about xmms, gs-gpl or gnucash? :-)
<hunger> bddebian: I think all of them (plus the debian release process).
<Keybuk> is there any reason cups still using gs ?
<Keybuk> it would be a sweet bounty to get that converted to poppel
<zyga> poppel?
<Keybuk> sorry
<Keybuk> poppler
<dholbach> poppler :)
<seb128> Keybuk: I though that pitti converted cups to used poppler some months ago?
<seb128> Keybuk: cups' package has a poppler patch for sure
<pitti> seb128: well, I converted the pdf2ps backend
<dholbach> Keybuk: "popel" in german means bogey :)
<jdub> ha ha
<jdub> dholbach: as in snot?
<dholbach> jdub: yes :)
<jdub> dholbach: after havoc wrote libwnck, he wrote libstartup-notification - everyone was sorely disappointed that he didn't call it libsnot :)
<dholbach> jdub: i'll have a word with him ;)
<Keybuk> hearing havoc pronounce libwnck is an event everyone should witness
<mvo> haha
<Keybuk> because he goes to great and extraordinary lengths to *not* pronounce it them as everyone else
<dholbach> we'll have a libsnot transition soon :)
<jdub> dholbach: "the big sneeze"
<hunger> rofl
<mvo> Keybuk: haha
<ogra> bless you !
<Keybuk> I always wanted to create a libido
<Keybuk> which is one of the few words that also comes out as a word when you do -lido
<jdub> during the ISV bof at the gnome summit, half the room said "lib wank", the other half said "lib wink". finally, someone asked if we were talking about the same thing.
<jdub> Keybuk: carlos is writing a library for using the system tools backends called liboobs
<mvo> jdub: I just wanted to say that :) 
<jdub> hooray for oobies ;)
<zyga> uhhh
<Keybuk> how about a porn video decoder library called libel ?
<zyga> ... sir we need to upgrade our system and install libooobs and libwnck ... 
<Keybuk> or maybe a usenet library
<Keybuk> jdub: could've been worse, HP guys could've been there and called it lieb wunuck
<dholbach> hm, p0rn-comfort depends on neither of those
<jbailey> ajmitch: *poke*
<sivang> zyga: lol, carlos garnacho wasn't sure about this name, but eventually due to the big support from me, and a couple of other guys on #gst, the name stuck :)
<zyga> sivang: gst?
<zyga> sivang: ?? :)
<zyga> sivang: lib oobies?
<sivang> zyga: actually it's liboobs IIRC
<sivang> zyga: http://cvs.gnome.org/viewcvs/liboobs/
<dholbach> zyga: gnome-system-tools
<bddebian> Fuck I hate my job. /me begs for job at Canonical ;-P
<sivang> bddebian: join the club ;-)
<zyga> bddebian: I'll be your sidekick
<bddebian> zyga: :-)
<zyga> bddebian: just feed me with remains from your trash can
<zyga> bddebian: are you an ubuntu member
<bddebian> zyga: I'm supposedly an MOTU ;-)
<sivang> zyga: ROTFL
<zyga> working for cannonical is not reallistic
<zyga> moving to UK?
<zyga> besides
<zyga> filling all those activity reports ;-)
<bddebian> Heh
<bddebian> Hey, we can work remotely can't we? ;-)
<zyga> OTOH it's be the only company I know that pays for sitting on an irc channel ;-)
<zyga> s/ be//
<bddebian> heh
<hughsie> any of you guys help me with a UI problem (gnome-power-manager)?
<mjg59> hughsie: Can give it a go
<hughsie> as i think it was brought up as a concern for ubuntu...
<bddebian> Oh shit, can we vote for you now mjg59? :-)
<zyga> arrrgh, why oh why cannot the pallete in glade-2 be minimalized !!!
<hughsie> mjg59: give me your worst :-)
<hughsie> i was wondering specifically about the "always show in the panel"
<hughsie> and the "show full devices" bit too
<Diziet> I tried to vote for mjg59 but launchpad broke.
<Diziet> (To be fair I hadn't logged in yet and when I did it worked ...)
<hughsie> http://gnome-power.sourceforge.net/gnome_power_prefs.php
<bddebian> NeverMind, done
<Kamion> zyga: are you under the impression that all Canonical employees live in the UK?
<mjg59> hughsie: Hmm. Sorry - which bit are we looking at?
<hughsie> The new version has more options for displaying the icon in the tray
<zyga> Kamion: yes... so I'm wrong :)
<hughsie> i.e. when to display and when not to display
<hughsie> what makes sense?
<hughsie> display the ac icon when battery is fully charged, or show the battery with a full charge?
<ogra> Kamion, thanks for the DVD work :)
<mdke> zyga, it depends how you define UK
<mjg59> hughsie: Hmm. Good question.
<zyga> uhhh
<zyga> how the hell do I force a label with long long text to fill the entire box it's in and NOT wrap after 40 words???
<mjg59> hughsie: I think the behaviour of the battery applet is sensible - an ac icon that changes when you're done charging
<zyga> mdke: and how should I define it?
<jbailey> mdke: Canada and Australia are only commonwealth. =)
<hughsie> so when the battery is charged, we show just the ac_adapter?
<jbailey> We're not *actually* part of the UK. =)
<mdke> zyga, if you include both americas, asia and australasia, and all of europe, we're nearly there afaics
<zyga> ;-)
<bddebian> jbailey: I thought you are a part of France?
* bddebian ducks
<zyga> mdke: darn colonies
<jbailey> mdke: And ISTR the Americans wasting a whole bunch of perfectly good tea over the issue a little while ago.
* ogra didntknow jbailey was a part of france ...
<mdke> heh
<mdke> what a waste of tea
<hughsie> mjg59: so when the battery is charged, we show just the ac_adapter?
<jbailey> ogra: Either the UK or France would suit me.  I'd love to have an EU passport. ;)
<ogra> what do you gain with a EU passport over a canadian one ? 
<jbailey> The ability to work in Europe.
<jbailey> I've wished a few times to go and spend a year or two there.
* Diziet finds another distributed rcs/scm tool, `Mercurial'.
<jbailey> Diziet: jblack has a bunch of comparisons of bzr vs. mercurial.
<mdke> the UK is in the EU?
* mdke runs off
<jbailey> mdke: IIRC, a UK passport gives work priviledges on the mainland.
* zyga creates ubuntu.suxx.pl
* jbailey blinks
<mdke> jbailey, yes it does, for a certain period of time, i was just kidding
<jbailey> Sorry, thought that was a perl script. =)
<mjg59> hughsie: I think there needs to be some indication that you're on ac
<hughsie> there's already the curly adapter like http://gnome-power.sourceforge.net/images/gpm-taskbar.png
<mjg59> Yeah. I think something like that indication is good (though I'm not keen on that specific artwork)
<Diziet> jbailey: Ooh.  Do you have a handy ref. or shall I google ?
<jbailey> Diziet: I don't.  Try pinging him, he lives in te US and might be awake.
<infinity> hughsie : Am I the only person who'se complained that the g-p-m icons look overly cartoonish compared to other taskbar icons?
<hughsie> infinity: they were done for diana fong for bluecurce
<hughsie> *bluecurce
<hughsie> you know what I mean..
<hughsie> i'll happily ship other icons
<infinity> I need to sit down with andyfitz at UBZ and talk icons with him.
<infinity> I'd like to replace g-p-m's icon set, GAIM's, and network-manager's.
<infinity> When I replace the net applet and the battstat applet with n-m and g-p-m, I feel like I'm using a completely different OS, the style difference is that striking.
<hughsie> infinity: if you do some icons, do them in svg
<mjg59> Yeah. Bluecurve is a lot more cartoony than the standard gnome icon set
<mjg59> infinity: Can you replace gaim instead, please?
<infinity> Hah.  What with?
<mjg59> Something that works
<bddebian> heh
<infinity> WFM.
<mjg59> Something that doesn't crash whenever my panel gets restarted, something with a UI that doesn't make me scream in anguish, something that integrates well with the rest of my OS
<tseng> gajim is getting nicer
* dholbach likes gossip
<tseng> if you are cool with jabber transports vs native protocol
<infinity> The only two bugs I feel an urge to fix is the breaking/crashing on panel restart, and the "insists on having a taskbar entry for the buddy list" thing.
<hughsie> so infinity: i would love some more icons :-)
<Keybuk> speak to andyfitz
<Keybuk> he's good at icons
<infinity> hughsie : I'll see if I can whip andyfitz into action.
<Keybuk> just not at delivering them <g>
<infinity> Alternately, my girlfriend kinda likes playing with vector art, maybe I'll sic her on some icons.
<infinity> But, yes, I'd love icons for g-p-m and n-m that match the default GNOME icon set, so I'll see what can be done.
<zyga> cool
<zyga> suspending on my laptop works just like ripping the battery and the power cord at the same time
<infinity> The cartoony theme just doesn't do it for me.
<hughsie> zyga: not cool.
<hughsie> infinity: thanks
<zyga> hughsie: no, not cool at all
<hughsie> zyga: what happens if you use the /sys/power interface? the same?
<zyga> hughsie: I never did, tell me what to do
<hughsie> zyga: echo mem > /sys/power/state
<zyga> hughsie: testing in 30 secs
* Keybuk wishes suspend worked on his laptop
<mjg59> Keybuk: Scream at ATI
<infinity> Suspend is so snazzy on my laptop it hurts.
<infinity> I still can't figure out why hibernate suddenly stopped loving me, though.
<Keybuk> mjg59: sadly I don't expect they'd listen
<mjg59> Or get me a dump of the registers under Windows
<Keybuk> I have no idea how to install windows on here
<jbailey> infinity: We can step through it together if you'd like.
<infinity> jbailey : Sure.  Let me prepare myself for Constant-Reboot-Mode
<infinity> (ie: stop surfing pr0n)
<jbailey> infinity: =)
<jbailey> infinity: Oh, admit it, you were reading FAILED build logs.
<zyga> yay
<zyga> I did see some acpi interrupt messages
<zyga> then everything died again
<zyga> hughsie: no luck 
<Keybuk> if somebody has a CD drive that 
<Keybuk> fits an hp docking thingy, then we should do it at UBZ :p
<jbailey> infinity: First thing, grep ^RESUME /etc/mkinitramfs/initramfs.conf
<infinity> jbailey : Yeah, that's fine, same thing it's been set to for months (RESUME=/dev/sda2, which is my swap)
<hughsie> zyga: kernel bug?
<zyga> hughsie: beats me
<zyga> hughsie: anything else I can echo there?
<infinity> jbailey : Note that this failed not only on my existing "ripe" installation, but on a fresh installation done to another partition.
<jbailey> infinity: Lovely.  Next step is to reboot, add break to the kernel command line
<jbailey> infinity: That'll drop you into the initramfs-tools
<jbailey> err
<jbailey> initramfs
<zyga> hughsie: the exact thing was like that: some message with progress bar, some acpi interrupt stuff, something else, powerdown
<zyga> hughsie: is this logged anywhere?
<infinity> jbailey : Sec.  Let me power up the auxiliary laptop so I can stay on IRC.
<jbailey> infinity: 'kay
<jbailey> infinity: While you're here.
<jbailey> I'll get you to cat /sys/power/resume
<infinity> 8:2
<infinity> Or, you want me to do that after I reboot? ;)
<jbailey> No, now is right.
* infinity is still waiting for the Toshiba-of-doom to boot.
<zyga> hmm what is that file?
<jbailey> So that also tells us that it's setting it correctly.
<zyga> mine has 0:0
<jbailey> Can you suspend rather than rebooting?
<jbailey> And then bring it up without quiet and splash, but with break ?
<infinity> jbailey : Yep, that was the plan.
<jbailey> zyga: That tells the kernel where to hibernate to.
<infinity> jbailey : I assume you mean s/suspend/hibernate/ :)
<zyga> jbailey: where does the system hibernate anyway? I have no swap file around
<jbailey> zyga: If it's not set, the kernel will hibernate to your swap, but it's a hint that initramfs-tools doesn't know how to resume
<infinity> zyga : If you have no swap, it doesn't hibernate.
<zyga> ah, that's why it keeps crashing ;-)
<jbailey> zyga: It needs a swap partition.  We can't resume from a swapfile.
<jbailey> infinity: Whatever.  Suspend to disk. =)
<zyga> infinity: does the swap partition need to be exactly the same size as ram?
<infinity> Alright, screen to the rescue.  Laptop-of-doom on IRC.
<jbailey> zyga: I usually use double on most systems, and triple on low-memory systems.
<infinity> zyga : Or bigger.
<zyga> I've got 512 megs and 509 swap :/
<zyga> that's a rather bad bad luck
* jbailey waves at Adam from the other screen.
<zyga> okay I need to run
<zyga> c'ya guys
<zyga> I'll try to repartition my laptop today and try again
* zyga runs
<infinity> Man, the panel on this Toshiba is PAINFUL.
<infinity> I can't believe I took this thing to UDU.  Imust have been a laughing stock.
<Keybuk> your hat, or the laptop? :P
<Yagisan> infinity: I didn't even have a laptop to take
<infinity> Err, that's right.
<infinity> jbailey : I don't think you can help me.  It doesn't look userlandish.
<infinity> jbailey : I get the wholr "reading image data" thing, then the "stopping tasks" mojo, then... Uhh... Nothing.
<jbailey> infinity: Mmm.
<jbailey> infinity: I don't think my file hack has made it back into Ubuntu yet.
<infinity> jbailey : It's like swsusp just decided that I suck, less than a month before release.
<jbailey> But the newest version of file can tell you if there's a suspend image in the swap.
<jbailey> Heya Carsten
<carstenh> hi jeff
<infinity> jbailey : If there wasn't a suspend image in it, would it even get this far?
<mjg59> No
<infinity> Ed Zachary.
<mjg59> infinity: You have working swap?
<infinity> So, I have no friggin' clue what's decided to break.
<infinity> mjg59 : Yes.
<infinity> mjg59 : Well, I will after I reboot from this failed resume attempt.
<infinity> mjg59 : Same swap (same partition layout) that used to work.
<infinity> What happens during (or right after) the "stopping tasks" progress bar thingee?
<infinity> Am I perhaps in need of unloading some module on hibernate that's causing a hang right there?
<mjg59> That's it resuming your previous console state
<infinity> Hrm.  Let me try hibernate/resume from a clean, no-fb, no-X, text-only boot.
<jbailey> infinity: Maybe kill usplash and console-* ?
<infinity> Y'know, I bet the last time this worked was before usplash suppoted vesafb, so I was booting with vga= and no usplash...
<infinity> But the only thing that would change is the state of vc8...
<jbailey> infinity: The console font setter will also have started working.
<infinity> Yes, ironically, my "fault".
<infinity> Testing that too.  But first, just testing from a very barebones boot.
<infinity> Dang.  Okay, hibernate/resume from a single-user, no-fb boot works fine.
* infinity wonders what to add back into the mix first.
<Kamion> fabbione: where did your broken-out partman-auto-lvm diffs disappear to?
<fabbione> Kamion: *cough*i think i trashed them by mistake*cough*
<fabbione> Kamion: well i guess i will have to take care of the merge later on
<fabbione> Kamion: but most of them are not suitable for upstream
<fabbione> given that they were using lvm2 only commands
<infinity> mjg59 / jbailey : do we restore console state in userspace, or kernel?
<fabbione> Kamion: that's what you told me at least at that time :/
<mjg59> Kernel
<Kamion> fabbione: I checked, upstream's happy with them now
<Kamion> so I suppose I will have to pick them apart piece by piece. lovely.
<fabbione> Kamion: ah.. ok.. well the point is that it is still duplicate code.. the same as in lvmcfg
<infinity> mjg59 : Alright, well, usplash is off the hook, I reproduced the failure without it.
<Kamion> unless the wayback machine has it
<infinity> mjg59 : Next step is exit 0 at the top of console-screen.sh
<fabbione> Kamion: so if you and upstream are nmot in a hurry, we can do a proper merge tomorrow
<fabbione> Kamion: and avoid tons of redundant code
<mjg59> Yay
<Kamion> nope. sigh
<fabbione> Kamion:  i don't mind to resplit them.. really
<Kamion> fabbione: tomorrow's fine, it's just I was about to do it today :-)
<fabbione> Kamion: well i understand.. the patches have been there for ages and i understood they were not ready for upstream.. so i did clean up :)
<fabbione> s/ready/good/
<Kamion> fabbione: http://lists.debian.org/debian-boot/2005/09/msg00210.html
<fabbione> Kamion: ok.. just tell joeyh that i did delete them by mistake
<fabbione> and that i will work tomorrow on a new set of more clean patches
<fabbione> it shouldn't be a big deal
<fabbione> actually
<Kamion> fabbione: ah, I think google's cache has them
<fabbione> that's what i was looking :)
<Kamion> any way to automatically retrieve stuff from google's cache?
<fabbione> not that i know off
<fabbione> iirc there were about 9 patches
<Kamion> try about three times that
<fabbione> i can'
<fabbione> i can't even find them
<Kamion> http://64.233.183.104/search?q=cache:lzdis4VFvXMJ:people.ubuntu.com/~fabbione/pal/2_to_2ubuntu1/+&hl=en&start=1&client=firefox
<fabbione> ah cool
<fabbione> can't you lftp on that url?
<Kamion> no, the links aren't munged to point to the cache
<poningru> mako: you there?
<poningru> can I pm ya?
<fabbione> Kamion: i guess it needs to be done by hand
<fabbione> Kamion: but if i click on them, it still pushes me to people
<Kamion> fabbione: there's a perl module, I'm on it :)
<fabbione> Kamion: ahahha cool
<fabbione> Kamion: anyway if you want to CC me in the thread
<fabbione> we can actually discuss about a batter implementation
<fabbione> like making functions commont to both lvmcfg
<hkais> hello
<fabbione> add the "can_be_lvm" tag into partman-auto reciepe
<Kamion> fabbione: feel free to post to -boot with suggestions; the thread I pointed to was old so nobody will mind a new thread
<Kamion> I'm just acting as a go-between at best here
<fabbione> Kamion: ok
<fabbione> Kamion: i will take time to write tomorrow than.. i really need to spend sometime with my wife today
<infinity> Argh.
<hkais> I was searching for XEN packages if they will be available in the new upcoming release.
<hkais> It seems there won*t be support for XEN?
<hkais> If so, how can I get involved into making pakets for XEN?
<hkais> sorry XEN pakets for ubuntu ;-)
<infinity> mjg59 / jbailey : Alright, commenting out console-screen.sh doesn't seem to help a bit, but doing a normal boot with no vga and no splash (so, no fb loading at all, vga16 or vesa) makes it happy.
<Diziet> hkais: Don't tell me: just like all of those reporters, you've got hold of the top secret Xen 3.0 release :-).
<fabbione> Kamion: oh! important.. there was a patch we did to partman-auto on which pal depends on
<fabbione> Kamion: i remember clearly uploading that one
<hkais> Diziet: I haven't got it?
* infinity tries single with a framebuffer.
<Diziet> Sorry, I should stop joking with you.
<Diziet> I've just been reading about Xen and several journalists claim that 3.0 exists but of course it hasn't been released
<fabbione> anyway i am off
* fabbione &
<Diziet> hkais: https://wiki.ubuntu.com/MOTU and https://wiki.ubuntu.com/UniverseCandidates and http://packages.debian.org/unstable/misc/xen seem relevant.
<hkais> Diziet: hehe.... okay now I got it :-)
<hkais> Diziet: okay as it seems for me I am too late ...
<Diziet> Well, you're too late for Breezy, yes.
<Diziet> But 3.0 in Dapper's Universe seems like a good bet, surely ?
<hkais> sure 3.0 in Dapper would be very fine
<Kamion> fabbione: easy to isolate if need be
<hkais> Diziet: I will contact the responsible maintainer, maybe I can support him
<Kamion> fabbione: apparently Google's cache has the index but none of the actual patches. Oh well.
<ogra> hkais, we dont have particular maintainers for particular packages... we have teams...
<Kamion> ... in theory
<ogra> hkais, in case of Xen i'd contact the kernel team
<hkais> hehe one meening in the one person team ;-)?
<ogra> and see what you can do with the kernel guys that are MOTU
<Yagisan> Kamion: your not team Kaimon :)
* infinity sobs quietly in the corner.
<infinity> mjg59 : Still around?
<ogra> Kamion, hey, i thought we even have a d-i team now :)
<Kamion> ogra: go on, who maintains kickseed then
<ogra> Kamion, not the d-i team ? 
<Kamion> or firefox, say
* ogra thinks that'd be the diziet team :)
<dieman> wow
<dieman> nearly crapped my pants when I saw "SSH server vulnerability"
<dieman> on USN-209-1
<infinity> There is no "I" in "team", but there are three of them in "infinity", which allows me to be a team for all sorts of things.
<Kamion> ogra: nobody but me has ever made any changes to it, and I doubt anyone else understands it; my name's in the maintainer field. If somebody else wants to come along and help, great, but until then saying it's team-maintained is at best a polite fiction
* Lathiat laughs at infinity 
<hkais> hmm okay...
<hkais> now I'm a little bit confused. Have I to contact the debian guys or, have I to contact the ubuntu maintainer team?
<Kamion> there are many packages for which there is no maintenance activity in Debian, and we simply inherit the Debian packaging directly
<Kamion> er, "no maintenance activity in Ubuntu", I mean
<ogra> Kamion, i never give up hope ;)
<infinity> And packages where the Ubuntu and Debian maintainer are the same, so the same person tends to handle both.
<Kamion> ogra: it's still a bit misleading to say things like that to somebody not familiar with our processes; you should make it clear that that's an ideal not always followed in practice, otherwise you're more liable to confuse than anything else, IMO
<ogra> hkais, contact the ubuntu kernel team... there are MOTUs among them 
<mjg59> infinity: Hi
<hkais> orga: thanks I will contact them
<ogra> Kamion, at least for this particular case we actually have a team
<hkais> orga: as soon as I find the correct email/contact
<ogra> but otherwise you are right
<infinity> mjg59 : Curious about findings, or want me to piss off? :)
<dholbach> hkais: #ubuntu-kernel :)
<mjg59> infinity: Oh, curious
<infinity> mjg59 : If I boot with no framebuffers at all (no "splash", no "vga="), it's all good.
<mjg59> Right
<mjg59> I thought we'd already checked that possibility?
<infinity> mjg59 : If I booth with vesafb, it appears to stop after the "stopping tasks" progress bar.
<infinity> mjg59 : But the plot thickens.  With vga16fb, I get a few ACPI: PCI interrupt messages (normal resume fare), then "resume= options should be used to set suspend device............................. swsusp: Need to copy 15145 pages" then it halts.
<hkais> dholbach: thx!
<dholbach> hkais: de rien
<mjg59> infinity: Ok. That suggests that it may be restarting userspace.
<infinity> mjg59 : ... But failing miserably still.
<infinity> Anyhow, I'll poke at it more later and see if I can figure WTF has broken.
<infinity> For now, hibernate isn't a feature I use much anyway (especially not since suspend-to-ram actually works for menow)
<hkais> Diziet: I have already a running environment of XEN under opensuse, but I want to switch from SuSE to ubuntu-server. But XEN is a must for the switch in my case
<Diziet> SuSE shipped a Xen 3.0 prerelease, didn't they ?
<hkais> as far as I know, yes
<dieman> nice
<dieman> thats as good as some of the redhat compiler gaffes
<Diziet> If you don't need the 3.0 features, it's probably worth trying a straight recompile of the Debian 2.0.6.
<infinity> jbailey : Oh, all this booting with various different command line options also leads me to believe there's a (cosmetic) bug in how you/I interpreted "quiet" in initramfs.  The output sent to usplash isn't the same as what you get on the console with no usplash.  I'll fix that in dapper.
<Diziet> gaffe> It's quite confusing.  Lots of journos are confused.  But I think it's the Xen people's fault - they keep talking about `3.0' all the time.
<hkais> 3.0 supports already vanderpool, which will be important for me....
<infinity> jbailey : And once that's fixed, it also means we can remove the initial "Loading..." message, which is good, cause it messes up VC1 sometimes (again, cosmetically)
<Kamion> dieman: pitti's description of that was just drastically confusing
<hkais> Diziet: afaik opensuse wants to update their disrti as soon as xEN 3.0 gets public
<Kamion> dieman: not only does it not affect openssh-server's default configuration, but it doesn't affect openssh-server *at all* unless you apply further patches
<Kamion> (sigh)
<Kamion> Keybuk: fancy adding Packages.gz/Sources.gz files to http://people.ubuntu.com/~scott/pybaz/ ? Or is there some better location?
* infinity decides it's coming up to bedtime.
<Keybuk> Kamion: I just copied those out of chinstrap/~scott/hct-daily
<Keybuk> though that's https, which apt won't do
<Keybuk> done.
<Keybuk> (not that I have a shell-script to do that for any directory, or anything)
<Kamion> ah, thanks
<Riddell> Kamion: did you look at those kubuntu updates?
<mdz> Riddell: if you're asking Kamion about the same changes you sent to me, I've responded to your email
<mdz> and unless there's some emergency, I'll be the only one approving -updates
<ogra> morning mdz 
<mdz> morning
<ogra> mdz, did you see, \sh and i got multiarch ltsp working over the weekend... :)
<bddebian> Heya mdz
<bddebian> ogra: Wow, nice
<ogra> bddebian, there is already a patch, but that needed some changes to work right ... so it was no biggie :)
<mdz> ogra: no, I hadn't. that's nice.  do you have a howto?
<ogra> mdz, not yet, i'll fix up the patch and we should include it in dapper ltsp...
<ogra> mdz, do you plan to develop on top of breezy ltsp or do you pick the mainline for dapper ?
<mdz> ogra: breezy will only receive security and other critical bugfixes; all new development goes into dapper
<ogra> mdz, do you plan to base dapper work on the ltsp-breezy branch ? or on the ltsp-mainline branch you have ? 
<mdz> ogra: it would be awfully confusing to use a branch called 'breezy' for dapper, don't you think? ;-)
<ogra> (wher do i apply my patch for merge)
<ogra> yes, but there is a lot different in the main branch already :)
<mdz> mainline
<ogra> so i thought you'd probably rename the braazy branch and work on top of that one for dapper... to selectively add the features
<ogra> *breezy
<ogra> ah, ok
<mdz> mainline is where new development happens; breezy was the branch created for breezy
<ogra> yup
* bddebian wonders if there is anything he can be doing to help?
<ogra> but all i did were breezy fixes for now... so i only have the breezy branch yet :) just checking out mainline...
<ogra> bddebian, sure
<mdz> ogra: I'm updating my mirror now with the latest mainline, patch-198
<ogra> ok, i'll wait with the baz get
<ogra> mdz, what about a separate ldm packge for dapper ? 
<mdz> ogra: would be reasonable
<mdz> mirror is updated now
<ogra> great :)
<bddebian> ogra: OK, what? :-)
<ogra> lets see, i'll know more after UBZ ... curretly i'm thinking about the specs for the best audio support and for local device support... that will need testers...
<ogra> i thought about something like a tunneled dbus connection to the thin client that uses hal/hotplug/udev to get the device access to th server for example... but thats not fully thught out ....
<ogra> or a theora based streaming tunnel for audio, based fully on gstreamer... but thats not fully worked out either...
<Lathiat> ogra: http://www.livejournal.com/users/davyd/151274.html
<ogra> bddebian, we'll have BOF for both at UBZ ... so the final spec will be done there
<mdz> ogra: our primary focus will be polishing what we have
<ogra> mdz, local devices and sound is a must i think... adding a centralized user management too... beyond that i dont plan enhancements
<bddebian> ogra: Yeah but by then I will probably be working on Merges ;-)
<ogra> bddebian, do you have the HW for ltsp testing ? then grab a edubuntu. install it and help solving the unploished stuff...
<bddebian> Heya sabdfl
<ogra> bddebian, things like omitting error messages on thin client boot wil be one thing thats easy to solve with patches...
* Kinnison heads out, back later
<ogra> also enhancing what i have built for the new ldm would be fine (all python-gnome)
* bddebian has no clue :-)
<ogra> bddebian, huntuing down http://bugzilla.ubuntu.com/show_bug.cgi?id=15244 would be a major help :)
<bddebian> ogra: Hmm, you obviously don't know how st00pid I am :-)
<ogra> bddebian, no need for ltsp to get the bug it also happens with normal ssh -X executed binarys...
<ogra> bddebian, i have no clue either what that is, thats why its not solved yet... dont think im smarter here ;)
<mdz> ogra: we will decide on local devices and sound based on what the LTSP guys have already done
<mdz> ogra: it's not necessarily something we can build from scratch for dapper
<ogra> mdz, yes, i already spoke to them... i'd like to have a spec for it that works a bit more integrated with ubuntu, even if we implement that ltap solution for now...
<ogra> *ltsp
<ogra> mdz, in fact they build something similar to my idea, but introduce a replacement for dbus to manage the communication... 
<mdz> ogra: are you talking about what is in ltsp 4.1, or the new things they have been working on since then?
<ogra> the new stuff i talked with jammcq about
<ogra> mdz, if we introduce that we'll have a lot of dplicate functionallity... i'd rather like to enhance what we have :)
<ogra> mdz, but lets keep this discussion for the edubuntu BOFs i proposed ;)
<lamont__> seb128: you around?
<seb128> lamont__: yep
* lamont__ points seb128 at the other window
* HiddenWolf jumps up and down behind the other window.
* Lathiat shoots HiddenWolf 
<HiddenWolf> Lathiat, Code of Conduct. :P
<Lathiat> err
* Lathiat hids
<Lathiat> *hides
<Lathiat> i hope the CoC doesn't include spelling correctly
<HiddenWolf> Now be good and get your bullet out of my backside!
<Lathiat> i missed anyway
<HiddenWolf> ah, ok. /me figures out he's sitting on his mobile.
* Lathiat grins
<dholbach> bbl
<HiddenWolf> Lathiat, so what's up?
<Lathiat> avahi hacking!
* HiddenWolf misses breezy frenzy.
<HiddenWolf> avahi is the networking service thingy, right?
<tseng> Lathiat: anything on banshee?
<Lathiat> HiddenWolf: yeh, http://freedesktop.org/Software/Avahi
<Lathiat> tseng: nope
<bddebian> ogra: How am I supposed to tell from that .xsession-errors attachment which "can't open display" is the problem?  Are they all indicative of the problem?
<Lathiat> we have daap-sharp, i guess the banshee bit hasnt been done yet
<ogra> bddebian, it shows that a ssh connection was established... it indicates that either xauth is at fault or something with the session handling doesnt work... or that DISPLAY is wrong ...
<ogra> but since DISPLAY should get overwritten by the ssh session it shoudlnt be DISPLAY... i'm not much further with this bug yet
<bddebian> Is DISPLAY even getting set?
<ogra> bddebian, yup
<ogra> ldm calls ssh -X <serverip> /etc/X11/Xsession
<ogra> err user@serverip indeed
<ogra> bddebian, the thing is that i see similar symproms with something like ssh -X user@othermachine firefox (nopn ltsp)
<ogra> so i think its something in ssh's X forwarding that is stuck... since its not only triggered by Xsession it seems
<tseng> is DISPLAY set?
<ogra> tseng, yes
<bddebian> heh
<ogra> to localhost:10.0 
<ogra> as it should be for ssh -X 
<ogra> i was suspecting it doesnt get freed
<ogra> but that cant be it, since it simply gets overwritten...
<ogra> i haven looked at xauth yet, which ssh uses for forwarede X sessions
<tseng> Lathiat: thanks for "fixing" beagle "bug"
<Lathiat> eh?
<tseng> xfs xattr
<tseng> on malone
<tseng> yes?
<lamont__> ogra: and the default ssh config of not forwarding X is changed?
<Lathiat> oh, was that sarcastic? did i do something wrong?
<tseng> no, i said thank you
<Lathiat> ok
<Lathiat> thanks :)
<ogra> lamont__, since ages ? 
<lamont__> ok
<tseng> jdub: !!!ONE
* lamont__ shuts up
<ogra> at least since hoary
<ogra> lamont__, thats not the prob... 
<Treenaks> hi jdub 
<ogra> lamont__, if i run ssh -X user@host x-session-manager and log out there, i cant log in with the same command for about a minute...
<ogra> even if no bits of the X session are left...
<jdub> no wonder irc was quiet
<lamont__> jdub: heh
<HiddenWolf> jdub, packed your bags yet? :)
<jdub> hrm?
<HiddenWolf> jdub, -nl is holding it's breath. :)
<jdub> for me to leave?
<HiddenWolf> *chuckle* Oh, wait. You're there already? :)
<jdub> YEAH
<jdub> er
<jdub> yeah
<sabdfl> does evolution have gpg support by default?
<HiddenWolf> jdub, Amsterdam treating you well? :)
<jdub> sabdfl: sort of - enter your key on the prefs page
<jdub> HiddenWolf: it is ok ;)
<HiddenWolf> jdub, don't do joints on the bosses time. ;)
* jdub is attempting to avoid both types of cones... mayo is evil on frites :)
<HiddenWolf> *chuckle* That's the way here. Ketchup is a treat. :P
<bddebian> ogra: Is there any chance it's just X not cleaning up well?  I.E. a ghosted process or something?
<ajmitch> morning
<ajmitch> jbailey: *poke*
<bddebian> Heya ajmitch
<ogra> bddebian, i didnt find any when i looked
<jbailey> ajmitch: Heya.  You mentioned that you had initramfs-tools selinux patches for me. =)
<ajmitch> jbailey: I did?
<ajmitch> jbailey: I said I wanted to discuss how to do it, I haven't worked on patches yet :)
<jbailey> ajmitch: Oh, I see. =)
<ajmitch> sorry to disappoint :)
<jbailey> ajmitch: Not at all.
<jbailey> What do you need? =)
<jbailey> I thought you had said before that most of the setup took place in init, so pre-init things didn't have to worry much.
<ajmitch> yeah
<ajmitch> but what runs in pre-init?
<ajmitch> and how much more do you plan to put in there for dapper?
<jbailey> ajmitch: Whatever people feel like putting in there, that's the trick.
<jbailey> The hook scripts make it trivial for people to add whatever.
<ajmitch> hm
<sabdfl> doko: do you look after thunderbird in ubuntu?
<ajmitch> how much of /dev is populated there at the moment?
<jbailey> ajmitch: Much of it.
<HiddenWolf> sabdfl, what's up with the mail clients?
<jbailey> ajmitch: It will probably be less for dapper, but you've at least got ttys, null, and the devices for mounting.
<sabdfl> HiddenWolf: i'm trying to ensure consistency
<ogra> sabdfl, Mithrandir does if he didnt give it away
<ajmitch> the trick is to have files created from initramfs to have the right security context afterwards
<sabdfl> Mithrandir: how would you fel about making enigmail a default install with t-bird?
<HiddenWolf> sabdfl, thunderbird is playing a far different ballgame from evo. :)
<HiddenWolf> sabdfl, and no, no pgp, without extentions. 
<jbailey> ajmitch: Oh, like in the /dev that gets migrated to the running system?
<ajmitch> so either have a minimal policy before /dev is populated, or relabel them before they're accessed when policy is loaded :)
<ajmitch> jbailey: I mainly want the system to be bootable & not open up holes accidentally
<Mithrandir> sabdfl: that'd be fine with me.
<jbailey> ajmitch: Right.  I don't know enough about selinux there.
<jbailey> ajmitch: What happens right now:
<jbailey> ajmitch: We start, mount a tmpfs on /dev, and run udevstart.
<sabdfl> hmm... Mithrandir on second thoughts, its probably a bit too tech
<jbailey> ajmitch: Other things can do as they see fit in there.
<Mithrandir> sabdfl: oh, why?  It tends to keep out of the way unless you get encrypted mails?
<jbailey> At the end of the whole thing, we mount -o move /dev /root/dev
<sabdfl> Mithrandir: its a whole extra menu for people to get lost in
<jbailey> So that the devices that we're using now are all present on the target system.
<HiddenWolf> Mithrandir, it adds a lot of clutter to TB interface
<Mithrandir> sabdfl: true.
<ajmitch> jbailey: if init loads a policy in enforcing mode & device nodes aren't labelled, then things are fairly likely to head south
<jbailey> ajmitch: Taht lets us do clever things, like have a usplash socket up, or keep debug informatio around. =)
<ajmitch> mmm
<Mithrandir> HiddenWolf: I wouldn't call it a lot of clutter, but I'm not going to argue that very hard. :-)
<ajmitch> sounds like it could be good fun then :)
<HiddenWolf> Mithrandir, first time I booted it with enigmail, I was "wtf!"
<Mithrandir> HiddenWolf: you know you've lost when you "boot" your mail client. :-P
<ajmitch> it might still be possible to pull off without anything in initramfs
<HiddenWolf> Mithrandir, I usually kick it, ;)
<ajmitch> by having the first scripts run by init doing some relabelling if selinux is loaded
<Mithrandir> sabdfl: I'd actually be happier if somebody who uses tb a bit more than I took it over, though.  I just use it for reading the occasional HTML mail, really.
<ogra> Mithrandir, that'd be a jbailey thing i guess... to add TB to initramfs ;)
* Mithrandir bats ogra with the FasterBoot spec
<ajmitch> ogra: sick
<ogra> bblblbl
<ajmitch> isn't initramfs going to be redundant once the kernel is rewritten in python? :)
<HiddenWolf> lol@ajmitch
<Lathiat> heh
<HiddenWolf> ajmitch, I'd *love* to see you try. :)
<crimsun> that's almost as scary a thought as Linux written in elisp
<ajmitch> hi \sh 
<bddebian> ooohhh X11 forwarding with putty and xming works.  You kick ass tseng
<doko> sabdfl: not on a regular basis, just for bug reports
<bddebian> Heya \sh
<sabdfl> ok
<\sh> re ajmitch 
<\sh> hell of a day :( 
<sabdfl> \sh: life beating up on you?
<\sh> sabdfl: digital tv is driving me crazy...0 or 1 ... is working or not :(
<sabdfl> \sh: where are you?
<\sh> sabdfl: now at home
<\sh> after busy 11h day
<ajmitch> \sh: you need to sit down & relax with some bugfixing
<crimsun> haha
<ogra> come on, he relaxed the whole weekend at my place :)
<\sh> ajmitch: I just tried to relax to spend all my tax payback
<ajmitch> ogra: yes I heard you were all quite relaxed :)
<\sh> hehe
<ogra> yup, was necessary :)
<ogra> we had a release barbecue and a lot of nice alcohol
<ajmitch> great :)
<\sh> ogra: bought the damn panasonic lumix fx8 in black and a 512mb sd card + a 16x dvd-r / dvd+r dual layer burner 
<ogra> \sh, coopl
<\sh> ogra: george is jealous..but now I lost 500  :(
<ogra> lost ?
* ajmitch has to get off to work, for however much longer he has this job :)
<\sh> ogra: I don't need a dvd burner ;)
<ogra> true, but its nice to have one ;)
<bddebian> ogra: Just put a little delay in ldm and say "Loading, Please Wait" ;-P
<ogra> bddebian, 1min delay ? 
<\sh> bddebian: you mean echo 'Load "*",8,1' ; echo 'Loading *' echo 'Ready!'
<lorenzod> sys 8192
<bddebian> ogra: Sure.  We wanna be like MS don't we? :-)
<zyga> re
* zyga hates shopping
<\sh> zyga: p.u.c -> this I don't hate ;)
<zyga> \sh: p.u.c ?
<\sh> planet.ubuntu.com
<zyga> :-)
<zyga> checking
<zyga> niceeee
<zyga> :-)
<\sh> zyga: hehe..it was the only thing what made me happy today :)
<zyga> eh only hi-tech stuff is nice
<zyga> everyday crap is depressing
<HiddenWolf> GPG error: http://nl.archive.ubuntu.com breezy-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<zyga> HiddenWolf: ah, nl. frost must have broken the signature
<\sh> HiddenWolf: which package? I had it this morning or yesterday as well
<HiddenWolf> \sh, anything after apt-get update this morning.
<astronut> i'm helping a friend and the upgrade from hoary -> breezy wants to remove amarok and some mesa stuff...why?
<bddebian> OK, trying to run a full Ubuntu desktop through putty/Xming is NOT such a good idea :)
<ajmitch> bddebian: use freenx then, I used it for several weeks while I was overseas :)
<bddebian> ajmitch: What's freenx?
<ajmitch> it was amazingly fast considering my 128Kbps dsl at home
<ajmitch> compressing X proxy, essentially
<jbailey> ajmitch: Does selinux handle labelling?
<jbailey> ajmitch: We could just as easy say that things loaded in the initramfs need to include some basic policy hints.
<ajmitch> jbailey: hm? there are utilities to do it
<\sh> sabdfl: will soyuz land this evening or only tomorrow?
<ajmitch> policy is still fairly monolithic although it's being split up & made modular now
<jbailey> ajmitch: So those would all be included then?
<ajmitch> if policy is loaded before files are created, they get the right label
<jbailey> Ugh.
<jbailey> So we'd need to regenerate the initramfs on policy changes?
<ajmitch> jbailey: if the policy only covers things in /dev it shouldn't change often
<ajmitch> or a similar subset of the system
<ajmitch> you suggested concatting a cpio file on?
<jbailey> True, that would work.
<jbailey> Well, update-initramfs would solve it either way.
<ajmitch> maybe something to look at when we have the code in front of us at UBZ :)
<ajmitch> I'll try & put something together by then that works
<jbailey> ajmitch: Bah, I want to start off UBZ with sticky notes on the right hand wall ;)
<ajmitch> hah
<ajmitch> I'd like to as well, but I haven't had much time to hack on this yet :)
<Robi> crimsun , alive?
<crimsun> yes. Ping me in #ubuntu, please.
<Robi> can't , no reg
<crimsun> try now
<Robi> yay
<tseng> bddebian: damn right
<tseng> bddebian: xming is the coolest
<ajmitch> tseng: what is this new crack you speak of?
<tseng> ajmitch: its xorg for windows
<tseng> ajmitch: with a simple installer/launcher, no cygwin hell
<ajmitch> nice
<ajmitch> I might need to try it
<tseng> xming.fd.o iirc
<tseng> google knows
<tseng> it can run a fullscreen xnest-alike or single windows
<tseng> just add -ac to the startup command for DISLPAY love
<tseng> or use ssh
<ajmitch> although I think nx is probably still better for me
<ajmitch> to connect to home from work
<jdub> new poll on the fridge!
<dholbach> YAY
* ajmitch runs to the fridge
* dholbach likes the percentage
<jdub> http://lwn.net/Articles/156027/
<jdub> holy crap
<tseng> rage, lwn
<ajmitch> dholbach: 67/33% split? :)
<dholbach> ajmitch: you did those 33% ;)
<ajmitch> jdub: would be nice if I were subscribed :)
<dholbach> ajmitch: ++
<ajmitch> dholbach: of course :)
<lamont__> mjg59: you around?
<sabdfl> hmmm... how does that lwn-subscription-for-dd's magic work?
* jdub mails jon to say, "dude, *proposal*"
<ajmitch> HP sponsored it, DDs are meant to mail someone
<ajmitch> and I still haven't done that yet..
<ajmitch> sabdfl: http://lwn.net/Articles/13797/
<sivang> rehi all
<ajmitch> hi sivang 
<sivang> hey ajmitch , what's cracking?
<bddebian> @#$@#$% subscription
<ajmitch> sivang: not too  much :)
<jdub> you should subscribe to lwn
<jdub> it is worth supporting :)
<sivang> jdub: who, me ? :)
<jdub> everyone
* sivang goes and checks the subscription price
<sivang> maybe we can arrange group subscriptions like debian has ? ;-)
<jdub> debian's subscriptions are sponsored by hp
<sabdfl> ah, ok. /me reachs for the plastic
<bddebian> w00t, sabdfl is buying.. ;-P
<sivang> night all
<dholbach> ok guys, i'm off to bed - have a nice evening :)
<dholbach> night sivang 
<bddebian> Gnight sivang, dholbach
<dholbach> night barry
#ubuntu-devel 2005-10-23
<jdub> yay, jon changed tense
<astronut> did the arvhies get F*'d? some people in #ubuntu (me included) are having gpg errors and 404's with apt
<jdub> man those hp ads with the picture frames are *brilliant*
<astronut> jdub: you jsut saw those?
<astronut> i know the debian organization but not ubuntu..who handles archives?
<jdub> they've been around for a while
* sivang reads the release process proposal thread before sleep
<ogra> jdub++
<tseng> pony++
<astronut> archive person is?
<tseng> astronut: you can point fingers at Znarl 
* Znarl hides
<astronut> Znarl: 404's all over plus gpg errors
<tseng> erm
<Znarl> astronut : Not very descriptive but I believe I know the solution.
<tseng> gpg errors = packages.gz out of sync
<astronut> gpg errors in apt-get update :-P
<astronut> Znarl: immediatly following upgrade to breezy
<astronut> Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/multiverse/m/mplayer/mplayer-586_1.0-pre7cvs20050716-0.1ubuntu9_i386.deb  404 Not Found
<astronut> Err http://us.archive.ubuntu.com breezy/main libxine1c2 1.0.1-1ubuntu10
<astronut>   404 Not Found
<astronut> Err http://us.archive.ubuntu.com breezy/universe amarok-xine 2:1.3.1-0ubuntu4
<astronut>   404 Not Found
<astronut> Err http://us.archive.ubuntu.com breezy/universe amarok-engines 2:1.3.1-0ubuntu4
<astronut>   404 Not Found
<Znarl> ok, ok, fixing.  Hold on mate.
<astronut> appreciate ti
<astronut> what's the issue?
<Znarl> Sync problem, should be solved in a few minutes.
<jdub> tseng: NO MORE PONIES!
<ajmitch> jdub: you're all out?
<dredg> mmm ponies
<jdub> i just can't keep funding tseng's pony habit
<jdub> the return on investment is *terrible*
<jbailey> Are they vegan ponies?
<ajmitch> jdub: was ubuntu on tap going on the fridge?
<jdub> ajmitch: yes, when davyd's docs are ready - that'll make it more relevant :)
* jdub watches CNN savage hugo chavez
<ajmitch> great :)
* ajmitch needs his fridge fix regularly
<astronut> Znarl: let me know when?
* ogra looks up where Vanuatu is... we obviously have a edubuntu user there
<Znarl> astronut : 10 minutes.
<astronut> Znarl: k
* Znarl heads for bed
<tseng> jbailey: only if you eat them
<ajmitch> ogra: interesting :)
<Riddell> ogra: how do you know?
<ogra> Riddell, he just posted to the M :)
<ogra> ML
<jdub> man
<jdub> i should totally do a pacific island tour
<ogra> hmmm :) looks like a Pacific Paradise Island :)
<jdub> ogra: it is near fiji
<ajmitch> jdub: start with LCA 
<ogra> yes, and they are the owners of .vu ... never knew that... wow, edubuntu is sooo educating me :-D
<ajmitch> and then tour from there
<jdub> ajmitch: nz so doesn't count
<ajmitch> sure it does
<ajmitch> we've got the most polynesians of any part of the pacific, I'm sure :)
<jdub> ogra: i'd be surprised if it were a real vanuatuan
<jdub> ogra: there are lots of tongans on the internet, but almost none of them live there (they just want .to domain names...)
<jdub> er, "tongans", with quotes ;)
<ajmitch> jdub: just come to dunedin & you'll see our tropical pacific island weather
<lifeless> ahahhaa
<lifeless> you mean antarctic
<ogra> jdub, he sends "greetings from Vanuatu"
<lifeless> the tropics are WAY north.
<jdub> ogra: rad!
<ogra> yep :)
<ajmitch> lifeless: close enough
<ogra> i realized the .vu part while reading wikipedia
<lifeless> didymo: pong
<mjg59> lamont: Hi
<bob2> oh, dang
<bob2> fn-f12 actually triggers suspend-to-disk now
<bob2> is that disablable?
<HrdwrBob> yes
<HrdwrBob> it would just generate an acpi event
<bob2> oh, good point
<infinity> You're complaining because your silkscreened hotkeys actually work properly?... That's new. :)
<HrdwrBob> infinity: damned if you do...
<bob2> I'm complaining that my fat fingers hit fn-f12 instead of ctrl-f12 sometimes ;)
<bob2> monsieur stub
<stub> yo
<HrdwrBob> bob2: been using a toshiba?
<HrdwrBob> stupid toshiba fn is between crtl and alt, I have an IBM and a toshiba, it's hell switching between them
<bob2> heh, yeah, a friend's vaio
<infinity> HrdwrBob : Yeah, same here, though I tend to say "stupid IBM", only because my fingers are trained from years of desktop use to fly far-left for CTRL... I'm getting used to the IBM, though.
<HrdwrBob> well, stupid both! though it makes it very easy to turn on the thinkpad light, bottom left+top right
<infinity> True, but if they wanted the light to be accessible in the dark, they could have given it its own button. :)
<mjg59> HP have a BIOS option to switch Fn and Control
<HrdwrBob> ooh, damn them to heck.
<mjg59> Only on their business range, though
<astronut> Znarl: still get 404's
* ajmitch wanders back in
<mpt> mjg59, should/could stuff like that be configurable in the Keyboard Preferences?
* mpt hugs uControl
<mjg59> mpt: Not really - most machines don't provide sufficient information for that
<mpt> ah, pity
<dieman> nifty, backuppc found my laptop was back on the network and restarted that full backup i interruped by going away earlier today
<bddebian> ogra: You around?
<mdz> oh god, yada is in main?
<ajmitch> yes
<ajmitch> and it caused pain for breezy too
<bob2> haha
<ajmitch> I'm sure certain maintainers are quite sick for using it :)
* ajmitch looks over at bob2 
<bob2> hey, I've been yada-clean for months now
<ajmitch> I'm glad
<ajmitch> I had to reintroduce bugs in universe packages because I couldn't break UVF for yada days before release ;)
<infinity> mdz : Would accept a trivial fix to -updates for #16911? (usplash exits early in initramfs)
<infinity> mdz : I already assumed "No", since the fix wouldn't be seen until the next initramfs regeneration, but.. <shrug>
<mdz> infinity: I would, but the fix isn't quite trivial...still might be OK
<infinity> mdz : The fix is incredibly trivial.
<mdz> there will be a steady stream of kernel security updates to regenerate initramfs
<mdz> infinity: increasing/decreasing the usplash timeout?
<infinity> mdz : Yup, wrapped around the load_modules() call.
<infinity> (There's also a lingering bug in usplash itself, but that can be fixed in dapper)
<mdz> doesn't quite fall under my definition of trivial, but might be OK for -updates nonetheless
<infinity> Namely, despite the compiled in default timeout of 15, it seems to exit earlier for some people.
<mdz> odd, never seen that
<infinity> Yeah, I assumed that bug submitters just can't count, but mjg59 confirmed it sometimes exits in 5 seconds or so, for no good reason.
<infinity> Though maybe he's also basing this on anecdotal bug submitter evidence.
<mdz> the trouble with touching initramfs-tools at all is that any problem we introduce can break the user's system in a way which is quite complex to fix
<infinity> Generally, submitters inflate numbers though ("Oh my god, loading modules took 3 minutes!"), rather than deflating numbers (well, it took 15 seconds, but I'll tell you 4), so I dunno.
<mdz> even if we upload a fixed version, the user needs to know the magic incantation
<mdz> so while a mistake is unlikely, the impact of one can be extremely severe
<infinity> Yeah.  It's a harmless hack, but I'm also a bit wary of touching it at all when we know it (more or less) works.
<mdz> and meanwhile, it is a cosmetic bug
<mdz> I'm not dead set against it, but it makes me itch
<infinity> Heh.
<infinity> Well, I can deal with a cosmetic bug here and there.
<infinity> So perhaps we should just let it be.
<infinity> More curious is WHY the loading modules stage takes so effin' long on a select few systems.
<infinity> The initramfs isn't really doing much of anything there.
<infinity> I need to find a system where it takes more than 2 seconds, so I can at least see it happening.
<infinity> One submitter claims it happens "only on k7 sysems", but that datapoint seems suspect. :)
<mdz> infinity: plenty of SCSI systems will take a long time there
<mdz> since it'll scan the bus
<jdub> yo mdz 
<Amaranth> is there something wrong with the archive?
<Amaranth> hmm, it might just be the us mirror
<stub> wiki authentication and launchpad will be offline for approx. 20 mins in 15 minutes time unless anyone feels like bitching
<infinity> mdz : True, but I think jbailey had feedback from some pure IDE users on this as well.
<infinity> mdz : Either way, the timout would need to be increased for SCSI users.
<mdz> jdub: sup
<jsgotangco> hmmm opera should warn users that their default ubuntu download requires some kdelibs
<jsgotangco> kubuntu people aren't affected
<crimsun> jsgotangco: the libqt3-mt bit?
<jsgotangco> yeah something like that
<jsgotangco> (i don't remember)
<infinity> jsgotangco : Does their package not properly depend on libqt3-mt?
<crimsun> infinity: not for Breezy, no
<infinity> jsgotangco : In which case, the problem isn't with them, it just with us lacking a really user-friendly way to install .debs with dependency resolution (though "dpkg -i *.deb && apt-get -f install" works fine)
<infinity> crimsun : For breezy, what's the problem?... They haven't recompiled yet with gcc-4.0?
<crimsun> infinity: not sure about Breezy, but they don't depend on libqt3c102-mt for Hoary
<infinity> They do for the breezy/etch download.  Just grabbed it.
<crimsun> or libqt3c102 if it was non-multithreaded
<crimsun> ah, great.
<infinity> Though they do scary and wrong things and depend on "libqt3-mt (>= 3.3.4) | libqt3c102-mt (>= 3.3.4)"
* infinity shudders.
<crimsun> yikes
<jsgotangco> they do actually its nice to stray away from Konqueror to do all the stuff (sorry Riddell)
<infinity> Still, they were built with gcc-4.0, so it will work fine on breezy.
<jsgotangco> it works fine
<jsgotangco> just the dependency
<infinity> Right, that dependency resolution is our issue though, not theirs. :)
<jsgotangco> ahh
<infinity> There was a recent thread on -devel about a simple GUI deb installer.
<jsgotangco> the static binaries re best at the moment though
<infinity> Why?
<infinity> What's so hard about "dpkg -i *.deb && apt-get -f install"?
<infinity> (The latter being what will pull in the deps for you)
<jsgotangco> well its not a problem for me, but for other people i guess...
<infinity> Anyhoe, I expect that if mvo finds a round tuit or two, this will be resolved in dapper.
<glick> excuse me i think gv is broken
<glick> i cant download xaw3dg when i try to install it
<glick> i get a 404 from the mirror
<infinity> glick : If you're getting 404s from mirrors, you're probably in need of an "apt-get update"
<glick> infinity, i get this...
<glick> W: GPG error: http://us.archive.ubuntu.com breezy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<infinity> Try again.  That's a transient error.
<glick> same thing
<infinity> Oh, bah.  us.archive has been pointed back at tds...
<glick> whats that mean?
<infinity> glick : That means that mirror may (still) be broken.
<glick> damn :(
<infinity> If you switch from us.archive to archive in your sources.list, you'll probably be fine.
<glick> thanks infinity, worked
<Keybuk> hmm, it looks mdz has discovered I'm an emacs user
<Keybuk> I suddenly have a bunch of emacs bugs in my INBOX
* Lathiat laughs
<mdz> I knew you were an emacs user, though I hadn't yet made the connection of emacs user<->distro team
<infinity> Keybuk : DOOM.
<mdz> someone needs to care about emacs around here
<fabbione> mdz: rm -rf pool/main/e/emacs* will do :)
<fabbione> nothing more efficient :)
<fabbione> mdz: your way of assigning bugs to me is impressive.. out of 4 i can probably fix 1
<Keybuk> fabbione: bzrk was written in emacs ... think about that before you criticise
<fabbione> mdz: i have no printers, never used LDAP or perl :)
<mdz> fabbione: I have faith in you
<fabbione> Keybuk: *cough*meh*cough*
<fabbione> mdz: ahahha
<ajmitch> Keybuk: bzrk looks quite impressive & shiny
<fabbione> mdz: can i quote that??
<mdz> fabbione: a) that's not a printing bug, it's about adding a package to main (and possibly desktop).  there is nothing in it that requires access to a printer
<fabbione> mdz: i didn't even read all of them yet :) just looking in my inbox :)
<Lathiat> bzrk?
<fabbione> mdz: don't worry.. i will work on them
<mdz> fabbione: b) that's not an ldap bug, it's an autofs bug.  and nobody uses autofs :-)
<fabbione> mdz: just tickleing your reassign power :)
<mdz> fabbione: c) that's not a perl bug; it's a perl-tk bug. perl-tk is a C module
<fabbione> mdz: exactly... i don't use autofs either :P
<Keybuk> Lathiat: http://people.ubuntu.com/~scott/software/bzrk.png
<fabbione> mdz: it still contains perl in the name.. ;)
<Lathiat> oh, nifty
<fabbione> mdz: don't worry tho.. i will look at them.. i just love to see how much you really love me :P
<infinity> Meh, I need to de-yada libnss-db, too.
<daniels> we have tk in main??
<fabbione> first i need to polish some d-i stuff for partman-auto-lvm
<spear> hi !
<pitti> Good morning!
<Keybuk> "Indeed, it's become something of a joke that the only things you can't avoid in life are death, taxes and Ubuntu reviews."
<spear> i can't find what exactly is required by Usplash ... what kernel options ? Same as for Bootsplash ? I checked the readme, nothing's told ... i use a home-built kernel ... i'll try to contact Paul Sladen, but if anybody has an idea ?
<Keybuk> thank gods I'd just finished my coffee
<Keybuk> spear: just "splash" with a kernel framebuffer ... usplash is an entirely user-space solution, no kernel patches
<daniels> try #ubuntu
<spear> thank you Keybuk
<spear> sorry daniels for annoying, but no one seems to know nowhere, in ubuntu-fr, ubuntu and even on the forum ... and documentation is non existing :(
<ajmitch> morning pitti 
<spear> i think i'll make the documentation myself and put it on the wiki
<pitti> Hey ajmitch, how's it going?
<ajmitch> good, how are you today?
<Keybuk> spear: documentation is always most welcome
<spear> so, for a freshly downloaded kernel from kernel.org, framebuffer and splash kernel options are the only needed ?
* spear thinks he should become a developer ... it's so quiet here ... :)
<infinity> spear : You need initramfs support in the kernel too, since usplash is started from an initramfs.
<spear> ok, so initramfs, framebuffer & splash ... that's all ?
<infinity> s/splash/
<infinity> You don't build with any splash options, you just need "splash" on the command line.
<spear> oh, ok !
<spear> so framebuffer & initramfs are the only options required
<infinity> Yup.
<spear> thank you for your patience, i imagine if everyone comes here and ask support questions, you'll get mad ... it was really because i didn't find some documentation that i came here, and i thank you
<spear> so, finally i conclude that usplash is totally different from " bootsplash ", a new program in fact (and it has nothing to do with the bootsplash prerequisites then)
<infinity> spear : yes, I think that was mentioned by Keybuk.
<infinity> spear : usplash is an application that runs in uderspace and writes to a framebuffer.  bootsplash is an intrusive kernel patch that does scary things we didn't really want to do.
<dholbach> good morning
<spear> good morning !
<daniels> whereas solutions like gensplash run in ber space
<daniels> splashy runs in unterspace, though
<infinity> Die.
<highvoltage> is usplash developed for ubuntu? when i google usplash the entire first page is ubuntu related :)_
<daniels> yes
<infinity> highvoltage : yes.
<spear> i read something about Upower in the development pages, it seems to be linked ?
<infinity> No.  Two entirely different projects.
<spear> ok, so i misunderstood
<spear> but it works on the same " objective " as usplash does, no ?
<spear> have a good day ! thanks !
<sivang> Morning all
<pitti> Hi sivang 
<sivang> pitti: Hey Martin, how are you ?
<pitti> fine, thanks! and you?
<sivang> pitti: not bad myself :)
<siretart> good morning everybody!
<Lathiat> evening siretart 
<pef> hello
<pitti> Hi mvo
<mvo> hey pitti 
<sivang> yo zyga 
<zyga> hello sivang
<Keybuk> Kamion: is there any particular reason why, in second-stage if they have configured network, we couldn't download the "better" kernel from the network and install it for them?
<Lathiat> does a "better" kernel actually make any noticable difference?
<Keybuk> quite a bit, depending on the system
<Lathiat> yeh? what commonly?
<Keybuk> performance, generally; the kernel can use more cpu tricks
<fabbione> Keybuk: the kernel is big and you might be on a slow pipe? what if you are installing N boxes at the same time?
<fabbione> Keybuk: that will mostlikely kill your bw
<Keybuk> we already have that bite for language packs though
<Kamion> Keybuk: no code exists for anything remotely like that *shrug*
<Kamion> and if they have configured network in the second stage, they probably have it in the first stage
<fabbione> Kamion: yo.. i am preparing the mail to debian-boot. Please don't spend more time on trying to get diffs out of google cache
<fabbione> Kamion: they miss the steps from ubuntu2 to other revisions...
<fabbione> Kamion: :/
<Keybuk> Kamion: right, but is there any particular reason we couldn't do that (in either stage?)
<fabbione> i noticed too late
<Kamion> fabbione: I wasn't going to spend any more time on it :)
<fabbione> Kamion: perfect :)
<Kamion> Keybuk: just the download delay thing
<Kamion> and more complexity, etc. that step fails quite often as it is
<Kamion> actually, it can't be done at that point in the first stage - haven't set up sources.list yet
<Kamion> so it would have to be in the second stage, which means you need an extra reboot to get your system to its final state, which I'd like to avoid
<Kamion> basically "not now, maybe later once we've reorganised lots of stuff" :-)
<pitti> lifeless: great, bzr push now seems to ignore unknowns. Thanks!
<pitti> Keybuk: ^ that means your bzr-push is now obsolete
<Keybuk> pitti: well, when it's actually folded into bzr proper
<Keybuk> my bzr-push has other bugs though, it's  not perfect
<Keybuk> (it rsyncs local changes, for example)
<pitti> Keybuk: well, bzrtools' push is good enough for me now
<pitti> the old one was annoying
<zyga> bzr is developing quite rapidly
<pitti> yes, it's nice - you report a bug, and lifeless tells you "ah, I fixed it yesterday"
<pitti> :-)
<\sh> hmmm
<Keybuk> heh, I had one of those the other day
<zyga> hehe :-)
<Keybuk> a bug was really annoying me, so I went into the code to fix it
<Keybuk> pulled first to make sure I was up to date
<Keybuk> and realised the bug had gone
<\sh> default breezy (gnome) install...ff -> the default page is missing
<pitti> cool
<pitti> \sh: ? WFM
<\sh> pitti: I installed just now a new 5.10 and the default homepage in ubuntu-artwork is just missing 
<pitti> odd
<\sh> index-ubuntu.html
<jsgotangco> odd
<\sh> better it's a kubuntu-desktop issue 
<\sh> where is the link
<\sh> where is the divert?
<Mithrandir> Keybuk: bzr-tools doesn't appear to be packaged, though
<Keybuk> Mithrandir: it's in jbailey's snapshots thing
<Mithrandir> I should hunt down that sources.list line, then
<Keybuk> people/~jbailey/snapshot/bzr
<Keybuk> I think
<Keybuk> is in there as bzrtools
<pitti> Mithrandir: yes, and it is called "bzrtools" (without the dash)
<ogra> woah, that was a lot of mail to read today...
<ogra> morning
<pitti> Hi ogra
<ajmitch> sadly not in breezy :)
<ajmitch> morning ogra 
<\sh> moins ogra
<ajmitch> how are you?
<pitti> ogra: I agree, yesterday's and today's mail flood was amazing..
<ogra> :)
* \sh needs to configure evolution :(
<ajmitch> plenty of discussion on the UVF ideas
<ogra> yup
<jsgotangco> heh
<ajmitch> first time I've posted to -devel for awhile :)
<highvoltage> JaneW: guess what. telkom now tells me that they don't know when they'll have adsl in my area, and that i should call them back every three months to check.
<JaneW> highvoltage: that's just ridiculous
<JaneW> highvoltage: move to a normal area? ;)
<sivang> hey JaneW 
<highvoltage> i complained to them for 10 minutes, and they're help desk agent put me on hold... for the same amount of time...so i just hang up
<highvoltage> and sent them a loooong e-mail.
<ajmitch> highvoltage: sounds like NZ :)
<JaneW> hi sivang
<highvoltage> oops, thought i was in #edubuntu there
<highvoltage> ajmitch: it can't be *that* bad in NZ ;)
<ajmitch> highvoltage: close enough
<zyga> mvo: ping
<mvo> zyga: pong
<zyga> mvo: are you running non-english locale?
<mvo> sivang: thanks for your mail about "gdebi", the code is availabe as a bzr branch if you are interessted
<mvo> zyga: no, usually not
<zyga> mvo: run firefox and check help->'translate this application'
<mvo> zyga: sometimes for testing
<zyga> mvo: it's not translated even though every other application has this translated alreday
<zyga> mvo: I know that firefox uses different i18n tools
<zyga> mvo: is there any way to fix this?
<mvo> zyga: let me check. IIRC sivang or seb128 did the ff integration
<zyga> sure
<sivang> mvo: :) I'm interested in opening .debs for inspecting their to be installed conffiles, as per SetupSnapshots. (would greatly appriciate your feedback there as well, although the specs are not finished yet)
<seb128> zyga, mvo: it's not translated
<zyga> k, now on how to fix this
<zyga> ff is using some strange xul stuff right?
<seb128> good luck
<seb128> correct
<seb128> and translation don't use gettext
<seb128> and when I marked the string as translatable it crashed with translation packages since they don't have it
<sivang> bah
<sivang> seb128: Bon Jour :) how are you?
<seb128> hi
<seb128> fine
<seb128> you?
<sivang> good, thanks.
<ogra> hey, wont we have a dapper-changes list ? there is nothing on lists.ubuntu.com yet
<seb128> is dapper open for uploads?
<ogra> no idea, but i'd like to subscribe to the list ...
<seb128> if not, why should we already have a list?
<ogra> to finish the bureaucracy in advance ? 
<seb128> what about letting time to jdub or whoever to do that?
<ogra> bah... :)
<zyga> mvo, seb128: is anyone on that ff-i18n bug?
<seb128> you? :)
<mvo> zyga: no, but we are happy about volunteers :)
* sivang stays away from stuff that are named like alien charachters "Xul" :-)
<zyga> mvo: I don't know jack about xul - I don't know how to fix it at all
* seb128 suggests using epiphany-browser, it has a nice GUI using GTK with correct translations :)
<zyga> mvo: is this similar to an extension?
<zyga> seb128: I am using epiphany :-)
<zyga> mvo: extension can ship with their own translations AFAIK
<zyga> but we'd neet to roll all translations into that integration package (again bad thing)
<zyga> mvo: OTOH, what do you think about that mockup of mine?
<mvo> zyga: I haven't read the rational (complettly) yet. it looks like this is going to be quite a development efford 
<zyga> mvo: not really, no
<zyga> mvo: without others to support this it'll be a dead idea anyway 
<Keybuk> hmm
<Keybuk> maybe today I shall update my desktop to breezy
<zyga> mvo: I plan to develop 100% of the backend support, initial repo with all of ubuntu's translations, a gui tool and the evangelization
<zyga> once that is packaged and working I'll try to convince one group I cooperate with to use this
<mvo> zyga: ok (/me goes and reads the blog now)
<zyga> mvo: wait
<mvo> zyga: ok
<zyga> mvo: I was about to update with current progress and other stuff
<zyga> mvo: I'll let you know
<mvo> zyga: ok, thanks. I'll wait for your ping then :)
<jdub> ogra: yeah! dapper-changes!
* jdub potters off to create the list
<pitti> jdub: is it there?
<pitti> ah
<ogra> cool !
<pitti> jdub: can you migrate the breezy-changes subscriptions?
<ajmitch> oh yay
<ajmitch> jdub: there'll be a separate list for autosyncs (if they happen)?
<jdub> pitti: yep
<jdub> ajmitch: hmm
<ajmitch> I think you split the list for breezy at one point
<ajmitch> otherwise our poor mailboxes will hurt
<sivang> so are we open for bussiness already?
<sivang> :)
<ajmitch> sivang: not that I'm aware of
<zyga> mvo: ping
<zyga> mvo: done, check and comment if you whish :)
<zyga> actually, everyone is invided to do so: http://www.suxx.pl/blog/index.php/next-generation-l10n-system/
<Kamion> Lathiat: whoa, assigning bugs to "Ubuntu Development Team" sends mail to a lot of people
<Kamion> could you not do it if you don't have to? :)
<Lathiat> oops
<Lathiat> ok
<ajmitch> Lathiat: uh oh ;)
<Kamion> I don't think it really buys a lot over "unknown"
* fabbione sighs
<pitti> sjoerd: ping
<Diziet> kamion: Joy, another web UI to fight with :-).
<Keybuk> oh, finally
<Keybuk> they're pre-releasing the 770s
<ogra> Diziet, bugzilla will go away for it
<Kamion> Diziet: have fun ... although I'm told there is an e-mail interface (albeit a bit weird)
* Mithrandir chuckles at ogra's newest xscreensaver bug
* ogra waits for the mail notification
<Kamion> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
<fabbione> Mithrandir: number?
<Mithrandir> ogra: http://bugzilla.ubuntu.com/show_bug.cgi?id=18029
<ogra> gah... i get them constantly...
<mvo> haha
<mvo> poor ogra 
<ajmitch> hah
<ogra> *SIGH*
<ajmitch> xscreensaver seems to attract interesting bugreports
<zyga> ogra: add gender to about me dialog ;-)
<ogra> pre release people called me racist because our default background in edubuntu shows a white girl... http://art.ubuntu.com/backgrounds/edubuntu/13
<zyga> and be sure to include options like 'both, none, i ait gonna tell'
<Treenaks> zyga: yes, but what would be the default?
<zyga> Treenaks: ;-))
<ogra> now i'm also a chauvinist :)
<zyga> Treenaks: I aint gonna tell
<Treenaks> ogra: white? she's yellow!
<ogra> Treenaks, people seem not to notice :)
<zyga> oh yes!
<zyga> we need to include skin colour
<Mithrandir> ogra: dude, Magni didn't call you a chauvinist, she just asked for the beard to be removed. :-P
<Treenaks> zyga: just make a hackergotchi mandatory ;)
<zyga> and varioius facial differences too ;-)
<zyga> Treenaks: heh
<Kamion> pitti: btw, I think your openssh advisory text was a bit misleading
<zyga> ogra: I've got a tip though
<zyga> ogra: you can use existing code in the potato guy ;-)
<ogra> hehe
<Kamion> pitti: not only does the vulnerability not affect openssh-server in the default configuration, but it doesn't affect openssh-server unless you rebuild the package with different options
<fabbione> ogra: ahahah you score :)
<ogra> i'll talk to mdz if he sees it as an breezy-update ... but i doubt it... and its simply the default icon ...
<pitti> Kamion: oops, right
<Diziet> The crypto on malone mails is just antispam, right ?
<ajmitch> Diziet: what crypto do you see?
<fabbione> Diziet: that will work until all our gpg keys will be compromised :)
<Diziet> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc says one has to sign various emails.
<fabbione> ajmitch: i think he means gpg sign
<ajmitch> ah right
* ajmitch was thinking of mail that malone sends out
<Kamion> we had a long debate about that at UDU
<Kamion> I thought the sabdfl-conclusion was not to require signing at least for most operations
<fabbione> the interface sounds *scary*
<Kamion> why signing appeared again, I'm not sure; some people had strange ideas about what operations required authentication
<Keybuk> lauchpad has strange ideas about permissions too
<Keybuk> only the developer can resolve a bug, for example
<Diziet> `GPG keys are required to sign the Ubuntu Code of Conduct' ?!
<Diziet> `This key hereby promises not to be a flaming arsehole'.
<Kamion> s/to/in order to/, I think :-)
<Keybuk> that's because it makes it legally equivalent to an ink signature
<Keybuk> so when the user complains about being thrown out, you can show them something they signed to say they wouldn't behave like that
<Diziet> Why do you need to show them anything ?  You can just throw them out.
* Diziet boggles.
<Keybuk> what happens when they decide to sue
<Keybuk> etc.
<fabbione> Diziet[respectpoint] ++
* Diziet sues Keybuk for disagreeing with him.
<Keybuk> exactly that kind of thing
<Diziet> ?
<Keybuk> is just a "dude, you signed a document to say you wouldn't do that, no go away"
<Keybuk> and it makes people read it, too, which helps
<Diziet> _Nothing_ can stop people sueing.  You can sue no matter how idioticly stupid your case is.
<ogra> and its a prerequisite to be an uploader ... so you already signed it, didnt you Diziet ? ;)
<Keybuk> didn't say it _stopped_ them sueing
<Diziet> The point of legal CYA is to avoid _losing_.  But in this case there's no difficulty on that score.
<Keybuk> just said it was for when they did
<Kamion> ogra: Diziet signed a contract with Canonical
<Kamion> which is sufficient
<Diziet> But this is all silly politics and I'm sure we must all have something better to do.
<ogra> Diziet, just hang around in #ubuntu for 24h
<Diziet> Thanks but no thanks ...
<ajmitch> ogra: now..
<sjoerd> pitti: pong
<pitti> sjoerd: Hi! how are you?
<pitti> sjoerd: I'm just merging hal
<sjoerd> cool
<pitti> sjoerd: you did the udev transition, cool
<Diziet> -davenant:~/mail> gpg t.asc
<Diziet> gpg: CRC error; 963a33 - dc3963
<Diziet> gpg: packet(5) with unknown version 149
<pitti> sjoerd: however, your preinst did not remove the obsolete dev.d/hotplug.d conffiles
<Diziet> Bizarre.  Not sure why it faffs with sending me a cryptogram, either.
<pef> is dapper open ?
<Kamion> pef: when it is, the topic will be changed
* Diziet is lost in a twisty maze of hedge-cryptography.
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | Dapper opens ~Tuesday; topic will be changed when it's open
<pef> Kamion: ok, thanks :)
<sjoerd> pitti: hrm, seems that they are removed just fine on my system.. but i indeed forgot to force there removal
<sjoerd> thought that i added that...
<pitti> sjoerd: you do remove /etc/dev.d/block/hal-unmount.dev
<pitti> sjoerd: but not /etc/hotplug.d/...
<sjoerd> right, that needs to be added in debian then..
<ajmitch> Kamion: when dapper opens, what's the general policy for main uploads?
<sjoerd> pitti: i gotta go.. lemme know if your finished merging, then i'll merge it back to the debian package again :)
<Kamion> ajmitch: whether we sync is still open for discussion
<seb128> ajmitch: do them? :p
<Kamion> ajmitch: otherwise open
<pitti> sjoerd: yes; I also do some other fixes
<Mithrandir> Kamion: so it's UVF and we just do bugfixes?
<Kamion> Mithrandir: that's not yet established
<ogra> doesnt work for edubuntu...
<ogra> and i guess neither for kubuntu
<ajmitch> right, there are a few packages that I want to patch for selinux support (chiefly coreutils now)
<Kamion> I think eyeballed merges are likely to be fine at the very least
<Kamion> but check with mdz when he wakes up
<ajmitch> ok
<Mithrandir> ook
<Keybuk> hmm
<ajmitch> since I'd want to be getting things like sysvinit, which are reasonably critical :)
<Keybuk> you know that Nautilus "CD/DVD creator" thing
<Keybuk> why the hell doesn't it tell you how much free space you have ?!
<Keybuk> ajmitch: I want to get rid of sysvinit by dapper+1 :p
<sjoerd> pitti: unfortunately i have very limited time for debian these days.. but hopefully i can merge hal and dbus stuff somewhere this week or next week... 
<ogra> Keybuk, patch it :)
<maswan> Keybuk: rewrite?
<ajmitch> Keybuk: that'd be great, but then I'd need to put selinux support into whatever else we used if it didn't have it :)
<seb128> maswan: sure, every time we find a bug we rewrite a new software
<Keybuk> ajmitch: what kind of stuff needs to be patched for selinux?
<ogra> seb128, and i thought you would only package it :p
<Mithrandir> Keybuk: you're aware that sysvinit in Debian is actually alive again and is getting dependency init support?
<ajmitch> Keybuk: getting init to load policy, debian's sysvinit works with it now
<ogra> now i know why you are so busy
<Keybuk> Mithrandir: yes, and I think they're doing it wrong
<Keybuk> which isn't really very shocking
<Keybuk> if you're doing dependency init (which is also wrong) you don't want to base it off sysvinit, you want to do it right
<Keybuk> ajmitch: "to load policy" ... you'll have to forgive me, but I don't know much about selinux -- isn't that just an init script activity
<ajmitch> Keybuk: no, it's done by libselinux calls
<ajmitch> which is what makes all this fun necessary
<Keybuk> ajmitch: yes, but what does it _do_ ?
<Mithrandir> ogra: isn't the icon in the screensaver supposed to change if you change the picture in "about me"?
<Keybuk> where does it load the policy into?
<ajmitch> into the kernel
<Keybuk> right, so doesn't that just mean it's an S:S01 init script kind of affair?
<ogra> Mithrandir, nope... jwz policy... nothing can be loaded dynamically...
<ajmitch> I don't think that approach works, although it might be worth looking at 
<Mithrandir> ogra: uhm, why is the bearded man there at all, then?
<ajmitch> init itself needs to be put into the right security context when it runs
<ogra> Mithrandir, because its the default icon representing a user everywhere in the desktop
<Keybuk> ajmitch: hmm, but in our system, init isn't the first thing to run
<ajmitch> so that other processes can get the right context
<Keybuk> don't you really want to look at loading the policy in initramfs?
<ogra> Mithrandir, even if i could load it dynamically, it would have to be computed to be a 90colr indexed xpm
<ajmitch> Keybuk: right, I've been talking with jbailey about that
<ajmitch> loading a minimal policy then & then another one from disk later
<Mithrandir> ogra: imo, it shouldn't be there at all, it doesn't have any function.
<ogra> Mithrandir, jwz rewrote libxpm and included it in the code of xscreensaver so there gets no .so loaded 
<ogra> Mithrandir, it shows a user ... as everywhere in the system if you dont set an icon...
<Mithrandir> ogra: the daemon could reread the image on lock and convert it to xpm internally.
<ajmitch> if I can load a full policy from disk, from the initramfs, then I wouldn't need to have init patched
<Keybuk> ajmitch: why can't you load the full policy?
<Keybuk> we're already going to be doing most of the fun stuff in initramfs anyway
<Keybuk> because we have to start udev there
<ajmitch> that's what I have to look at
<Keybuk> which is going to be causing the launch of most of our boot sequence
<ajmitch> right
<ogra> Mithrandir, yes it could... but i had to start hacking xscreensaver 2.5 weeks before release while i had a lot edubuntu stuff todo... it wasnt planned to rewrite it... thats the best i could do without dropping the edubuntu release
<Mithrandir> ogra: not in the users and group admin tool, for instance.
<Mithrandir> ogra: I'm just proposing to drop the image if you can't have it dynamic. :-)
<ogra> Mithrandir, in about me, in gnome-screensaver etc... there are a lo of places, even in gdm its the default icon
<ogra> erm
<ogra> Mithrandir, are you magnio incognito ? 
<Mithrandir> ogra: she's a friend of mine, yes.
<ogra> *SIGH*
<Mithrandir> ogra: no, I'm not her.  Google for her if you don't believe me. :-P
* ogra marks anothe duplicate
<Mithrandir> ogra: I was told to tell you that she'll write evil stuff about jwz and less evil stuff about Ubuntu in her master's thesis (on sex's role in the free software world)
<ogra> Mithrandir, i'm just tired of getting bug reports twice because i marked them as duplicate
<mpt> ogra: If 16895 is a duplicate of a wontfix bug, 18029 is not a duplicate of 16895
<mpt> actually, it's not a duplicate regardless of the status of 16895
<ogra> mpt, as long as mdz doesnt say that i should update its a WONTFIX for me... i dont seethe need
<jdub> mi	sex, or gender?
<jdub> Mithrandir: ^
<ogra> Mithrandir, she can write what she wants, but she should leave jwz out, the icon was my choice
<Mithrandir> jdub: people have sex, words have gender, I've been told.
<mpt> ogra: You mean it's not going to be fixed because xscreensaver isn't going to be used any more?
<jdub> "people have sex" -> ambiguous :)
<Mithrandir> jdub :-)
<ogra> mpt, i dont see the need for it to be fixed, it uses the default icon thats used everywhere... even gnome-screensaver uses it
<jdub> Mithrandir: that distinction isn't entirely true in english
<jdub> like, on a form, i'd answer "M" for either 'sex' or 'gender'
<Mithrandir> jdub: I've heard it for english, since you don't have the distinction in, say, Norwegian.
<jdub> though i'd be tempted to answer "Y" for 'sex'
<mpt> ogra: Well that's just what I was going to say, the bug could be moved to gnome-screensaver, and "the bug occurs everywhere" isn't a reason not to fix it
<ogra> mpt, the fix would be to have a neutral default icon... (which wont happen for breezy) so its consistent currently
<mpt> actually if it occurs everywhere, it's maybe an icon theme bug
<Mithrandir> jdub: yes, but that doesn't mean it (pedantically) makes sense to ask about your gender.  You realise the world around you is buggy, but it's less hassle to second-guess, so you do.
<ogra> yes
<jdub> hmm
<Mithrandir> ogra: well, we don't close all bugs we can't fix for breezy, we leave them open and fix some of them for dapper. :-)
<maswan> Mithrandir: sex is biological, gender is social. when you make that kind of distinction.
<ogra> Mithrandir, i wont touch xscreensaver anymore execpt the hacks...
<Mithrandir> maswan: so if you're a male transvestite, you should answer "male" for sex and "female" for gender?
<ogra> Mithrandir, we'll switch fully to gnome-screensaver.... xscreensaver daemon and binary will go to universe
<jdub> man
<jdub> net connection sucks here
<maswan> Mithrandir: you could, I guess. but it also depends on the context of the question, I guess.
<ogra> Mithrandir, and loose my lockscreen patch in the next sync
<maswan> Mithrandir: the department of biology or medicine or whatever studies sex, gender studies is a social science. in general. there might be local differences. I think asking for gender is better than asking for sex, if the context is similar to "should I call it he or she?"
<Treenaks> maswan: Ask for a prefix (mr, mrs, ms, etc.), and localise the list for each country, with a gender tag
<jdub> dapper-changes is ALIVE!
<Treenaks> jdub: w00t! let's have a beer on that tonight ;)
<ajmitch> jdub: yay, now we just need uploads to fill it
<ogra> jdub, yay
<Mithrandir> Treenaks: how do you handle the fishes that change sex as they grow up?
<ajmitch> everyone who was on breezy-changes is subscribed there?
<Treenaks> Mithrandir: just call them wanda
<maswan> Treenaks: not all countries have prefixes.
<Treenaks> maswan: good point
<poningru> hey guys question
<poningru> it seems audacity plays mp3 out of the box
<poningru> doesnt that make it kinda illegal in the US
<poningru> or is universe exempt from that?
<pitti> poningru: universe is fine
<pitti> poningru: but we have legal troubles anyway, since libmad0 is in main
<ajmitch> night all
<pitti> poningru: mp3 playback is not illegal itself
<poningru> ooph
<pitti> night ajmitch 
<poningru> night dude
<pitti> poningru: you just must not ship it without a license
<poningru> pitti: right, so arent we shipping it without a license?
<pitti> we do
<poningru> so wouldnt the usage of ubuntu in the US be deemed illegal?
<poningru> since its 'bundled'
<pitti> not sure
<poningru> my understanding is not that good either
<pitti> it does not come on the CDs, AFAIK
<ogra> we dont "ship" audacity...
<pitti> so it might not meet the definition of "ship"
<ogra> its fine as it is...
<poningru> hmm ic
<pitti> ogra: I'm talking about libmad0
<pitti> ogra: we put gstreamer0.8-mad in universe for no good reason
<ogra> pitti, yes, audacity build-deps on it
<pitti> and have the actual decoder in main - we need to fix this ASAP
<ogra> libmad0 was planned to get dropped from main soon afaik
<poningru> oh ok ic so universe is ok since we dont actually ship it
<poningru> gotcha
<pitti> it was planned for breezy actually
<bob2> maaaaaaaaaaaaaaaaaaaaaaaad.
<pitti> k, gotta leave for a couple of hours - cu later
<poningru> adios
<ogra> bye pitti 
<zyga> http://www.ubuntu.com/support/marketplace
<zyga> 404
<zyga> errr
<jordi> koke: ping
<zyga> who will/can open dapper?
<bob2> there's five months and 27 days left
<jdub> OH MY GOD!!!! THERE ISN'T ENOUGH TIME!!!!
<Treenaks> jdub in wonderland?
<zyga> hmm ;-) ?
<Lathiat> quick we'll have to cancel dapper
<Treenaks> Lathiat: and then?
<Lathiat> panic?
<Treenaks> Lathiat: good one
* Treenaks starts running in circles
* poningru moons to break the tension
<poningru> sorry had to be done
<Treenaks> poningru: Never moon a werewolf.
<jdub>   ~.
<jdub> heh
<highvoltage> hi, i'm trying to use debmirror to download the breezy archive, and i receive the following message:
<highvoltage> any ideas?
<highvoltage> Won't mirror without dists/breezy/main/binary-i386/Packages.gz signature in Release at /usr/bin/debmirror line 1187.
<Lathiat> you need to pass --ignore-release-gpg
<Lathiat> or whatever it is
<Lathiat> debmirror --help
<Lathiat> i forget why
<highvoltage> Lathiat: ah, thanks.
<highvoltage> still does it.
<Lathiat> highvoltage: what command are you running?
<highvoltage> Lathiat: debmirror --method=http --dist=breezy --section=main,universe --host=archive.ubuntu.com --ignore-release-gpg .
<Treenaks> I'm getting
<Treenaks> W: GPG error: http://nl.archive.ubuntu.com breezy Release: Unknown error executing gpgv
<maswan> Ehm, my debmirror seem to be working without --ignore-release-gpg
<Treenaks> yes, I know how to make it _work_
<Treenaks> I'm getting lots of reports
<maswan> Ah
<highvoltage> Treenaks: so, how do i make it work? :)
<Treenaks> highvoltage: I don't know :)
<bddebian> Hello
<zoot_> hi there - does anyone know what the status (if any) of breezy's apcupsd-3.10.17.2 being upgraded to apcupsd-3.10.18? ... .18 is a bugfix (and in debian unstable) for UPS APC devices which several folks, including myself require. url is http://packages.debian.org/unstable/source/apcupsd
<zoot_> the bugfixes pertain to USB APC cabled APC UPSs under linux 2.6.12 kernels
<\sh> did I miss the opening of dapper?
<Kinnison> No
<Kinnison> jdub got the -changes list ready
<Kinnison> but that's about it so far
<Kamion> \sh: topic
<Keybuk> figlet -fsmall ARE WE THERE YET?
<Kinnison> Keybuk: figlet -fhuge NO!
<\sh> Kamion: well...irssis fault..and my day in hell part 2
<bddebian> Heya \sh.  Opening of Dapper, hell we released already.. ;-P
<\sh> bddebian: nice...U fixed the life, the universe and the rest? ,-)
<pkern> Are the release goals for dapper already available somewhere?
<HiddenWolf> pkern, not decided yet.
<bddebian> After UBZ I assume
<HiddenWolf> pkern, they'll be decided at the summit in a week or so.
<pkern> HiddenWolf: Not even some preliminary ones?
<HiddenWolf> pkern, check the wiki for BOF's
<pkern> Oh I thought UBZ happened already.
<pkern> Sorry.
<bddebian> Nope, end of this month.  NP :-)
<Lathiat> theres a list of bofs at https://wiki.ubuntu.com/UbuntuBelowZero/BOFs
<Lathiat> so i guess thats 'perliminary' 
<pkern> Yep, I'm currently crawling it. UBZ would be quite interesting, but hey guys... Please do your next conference in Europe. (=
<jbailey> pkern: Two conferences ago was in Europe, as was the one before that.
<jbailey> I have no idea how the rotation is done, but it seems to me that it likely wouldn't go there next.
<pkern> Ok ):
<Lathiat> erghhh, something has eaten my ZeroConfSpec
<bddebian> Next is the US ;-P
<Lathiat> hrm actually
<Lathiat> the page seems to never stop loading
* Kinnison hopes we don't ever have a conference in the US
<Riddell> bddebian: conferences in the US are difficult
<wickedpuppy> none in asia ?
<Riddell> Lathiat: it took a while but the page has now loaded fine for me
<Lathiat> Riddell: yeh same
<Lathiat> it took *ages* but
<Lathiat> like, 3 minutes or so
<Riddell> wickedpuppy: it needs someone local to help organise it
<Lathiat> in a wget the speed slowed to 0K/s for quite a while
<bddebian> Riddell: Why is that?
<Riddell> bddebian: visa restrictions
<HiddenWolf> Riddell, why is that?
<Riddell> "what's this free software?  sounds like a communist meeting, you're not getting in"
<bddebian> Oh give me a freakin break
<HiddenWolf> Riddell, lol
<HiddenWolf> Riddell, gnome summit was in boston, right?
* Keybuk won't attend a conference in the US
<pkern> Mh all launchpad merge requests are resulting in "RequestExpired"
<Riddell> true, would be insteresting to know what sort of visa fun gnome summit must have
<Keybuk> Riddell: all the attendees are in Boston *anyway*
<Keybuk> it's basically a RH and Novell love-in, isn't it? :p
<mjg59> Riddell: From Europe? None
<jdub> very few visa issues
<Kamion> bddebian: some Canonical employees have had visa problems in countries with fewer visa issues than the US; it's not a joke
<jdub> Kamion: the south africans. but they're special.
<Kamion> including things like refusal to believe that Canonical exists because of its somewhat weird status
<Lathiat> Kamion: 'weird' status?
<Keybuk> jdub: not just the south africans
<Keybuk> but those are a particular group, yes
<hunger> jdub: Yeap, visa is not the problem... but you do have to give your fingerprints, etc.
<Kamion> Lathiat: multinational, incorporated in Isle of Man, that kind of thing
* Kinnison has no desire to be treated like a criminal automatically upon entry to a country
<Lathiat> what is the isle of man 
<hunger> Kinnison: Neither do I...
<ogra> Lathiat, an island
<Kamion> Lathiat: what is google? :-)
<Keybuk> Lathiat: it's a country just offshore of the United Kingdom
<jdub> Lathiat: in between the big islands
<Kamion> come on dude, first hit
<Lathiat> and why is canonical incorporated in the isle of man?
<Lathiat> Kamion: yeh yeh i got it ;p
<jdub> Lathiat: tax haven
<Keybuk> Lathiat: convenient tax haven
<Keybuk> running an international company that employs developers in 14 different countries is *hard* when you have to deal with local corporate tax law
<Lathiat> ah ok
<wickedpuppy> Riddell, how much money does it normally take for a conference ?
<Riddell> wickedpuppy: lots I imagine, dunno
<pkern> Isle of Man is not under UK law that is?
<pkern> *normal
<Riddell> bandwidth costs at ubuntu down under must have been a lot :)
<Keybuk> pkern: no, because it's not part of the UK
<pkern> And there's a real office at Isle of Man?
<jdub> Riddell: not really, just annoying
<mpt> jdub: yo
<jdub> morning mpy
<Keybuk> pkern: there's a bank :)
<pkern> Keybuk: Ok, but under the crown. (:
<maswan> how big is an ubuntu conference?
<jdub> mpt
<jdub> maswan: > 100 people
<Kamion> pkern: crown> so's Canada
<jdub> maswan: s/conference/developer summit/
<maswan> jdub: but <300?
<mpt> jdub: We have a SoundEvents spec that (afaik) is marooned without an implementor, and we have an Ivic Ico Bukvic in ubuntu-devel@ offering his desktop sound theme
<pkern> Keybuk: *cough*... "a bank"?
<mpt> Perhaps the two could be brought together?
<maswan> jdub: ACK
<Keybuk> pkern: it's a member of the commonwealth, yes
<pitti> hi
<jdub> maswan: yeah
<Riddell> pitti: could you join us in #kubuntu-devel for a second?
<pitti> sure
<sladen> pkern: Bank.  An organisation that pushes money around and scrapes off a little bit for itself
<pkern> sladen: Yes, but so the only part of Canonical that really resides on the Isle of Man is the money? (:
<maswan> jdub: interesting, just curious mostly. I'm not sure I have the local organisation or the international flight connections for UbuntuWithBandwidth 2007. ;)
<Keybuk> pkern: and the board of directors and legal stuff like that
<pkern> Keybuk: Ok.
<pkern> Is the people merger in Launchpad broken?
<Keybuk> but in general no, it's just where the company is "based"
<Keybuk> the offices are in London
<Kinnison> pkern: It is slightly broken at times
<pkern> Kinnison: Ok.
<Amaranth> mpt: that'd be awesome
<Amaranth> mpt: and since the theme was appearently designed for KDE it could be used on kubuntu too
<Riddell> Amaranth: what's that?
<pkern> Malone #3318 is funny, is 5.04 still in the archives as a kind of "oldstable"?
<bddebian> There were several Hoary bugs in Malone still last I looked
<Kinnison> pkern: warty is still supported
<Amaranth> Riddell: http://lists.ubuntu.com/archives/ubuntu-devel/2005-October/012148.html
<Amaranth> Riddell: http://www.kde-look.org/content/show.php?content=12584 is the theme itself
<trulux> pitti: hey
<pitti> Hi trulux
<trulux> pitti: Doing well?
* trulux had an exam today
<pitti> yes, sure
<trulux> pitti: I'm working on the next vsec packages, I've finished the cap_over stuff and will release new version soon
<pitti> trulux: how far is the todo list?
<trulux> pitti: well, we are focusing on vsecurit right now, next will be SELinux. it's going pretty good and I'm proud of the work being done by the volunteers
<trulux> pitti: I need your word though
<trulux> pitti: I told you I want to work all-together with "official" Ubuntu Linux maintainers
<pitti> right, great
<trulux> I really suggest you to join the channel, now there's much more activity
<trulux> I'll introduce you to Jeff, he's helping me on many vsec-related stuff
<trulux> great guy
<pitti> Riddell: right, langpack-o-matic could not determine the locale of -af because of the missing mo files
<pitti> Riddell: can you please install pkgstriptranslations, activate it in /etc/pkgstriptranslations.conf, and build the package again?
<pitti> Riddell: this will produce a _translations.tar.gz
<pitti> Riddell: I can sneak this into lamont's directory, so that it is imported
<Riddell> pitti: ok
<HiddenWolf> any of the server admins, NL.archive.ubuntu.com is having problems again.
<Amaranth> HiddenWolf: so is uk, us, etc
<HiddenWolf> Amaranth, what's up then?
<Amaranth> no idea
<pitti> Keybuk: cool, hal now works without a hotplug.d script and uses a udev RUN rule
<Keybuk> yeah
<Keybuk> I'm tempted to not run dev.d or hotplug.d from the start
<pitti> /etc/hotplug.d$ find -type f
<pitti> ./default/default.hotplug
<pitti> Keybuk: that means after I uploaded the new hal, udev can be upgraded and hotplug.d can go away
<Keybuk> actually, it can't :p
<pitti> Keybuk: however, we need to fix libsane and libgphoto
<Keybuk> because that default.hotplug is still there
<pitti> Keybuk: but it's from hotplug itself?
<Keybuk> exactly
<Keybuk> it's what _runs_ hotplug :p
<pitti> ah, does it to the older-style emulation?
<pitti> OIC
<pitti> so it runs /etc/hotplug/bus/script?
<Keybuk> though obviously, at the same time you upload that new hal
<pitti> or, rather, *.agent
<Keybuk> I will almost certainly be uploading the new udev
<Keybuk> and stuffing hotplug into the jaws of death
<pitti> Keybuk: what about sane and gphoto?
<Keybuk> hell, there'll probably be a new GNOME out by the time dapper opens :p
<Keybuk> pitti: those will break
<Keybuk> and then we shall fix them
<pitti> Keybuk: AFAICS we need to convert them to use proper device nodes
<Keybuk> yes
<Keybuk> there's a patch for that
<pitti> Keybuk: I just wonder which major/minor numbers to use then?
<Keybuk> I have "learn git" on my TODO list
<Riddell> pitti: http://kubuntu.org/~jr/tmp/kde-i18n-af_4:3.4.3-0ubuntu2_amd64_translations.tar.gz
<pitti> Keybuk: devides in /proc don't have major/minors, have they?
<Keybuk> then I'll find out whether that got applied to the kernel
<pitti> Riddell: sweet, thanks
<Keybuk> pitti: the /proc/bus/usb things aren't proper "devices", they're kernel hacks
<pitti> Keybuk: right
<Keybuk> there's a kernel patch for them to move them to under /sys where they belong
<pitti> Keybuk: that's what I meant, there is no obvious major/minor for them - or does the kernel patch introduce a proper device for those?
<Keybuk> I'm not sure whether it introduces a proper device or moves the hack
<Keybuk> I'll learn git tomorrow and find out
<pitti> cool
<Keybuk> (udev itself is now in git)
<pitti> Keybuk: or just quickly write git2bzr and use your favourite tool :-P
<Keybuk> heh
<Keybuk> I'd get complaints for usurping the "import process"
<Diziet> -davenant:~> zcat /export/mirror/ubuntu/dists/breezy/main/binary-i386/Packages.gz |egrep '^Conflicts:.*<<'  | wc -l
<Diziet>     909
<ogra> nice
* ogra guesses there are myn python packages in that list
<ogra> *many
<Diziet> No, the python packages don't seem to do that so badly.  Mainly they're full of dummy packages.
<Diziet> -davenant:~> zcat /export/mirror/ubuntu/dists/breezy/main/binary-i386/Packages.gz |egrep '^Description:.*transitional'  | wc -l
<Diziet>      18
<Diziet> Not so bad, even though it's probably an underestimate.
<Diziet> -davenant:~> zcat /export/mirror/ubuntu/dists/breezy/main/binary-i386/Packages.gz |egrep '^Description:.*dummy'  | wc -l
<Diziet>      29
<Diziet> ogra: the wiki thinks you had the ubz BOF wiki page lock but it has timed out.
<ogra> hmm... i tought i stored
<Diziet> Let me know when you've sorted it.  It gave me the lock but I haven't made any edits.
<ogra> its stored, edit away
<Diziet> Ta.
<ogra> thanks for pointing it out :)
<Diziet> NP
<poningru_class> ls yes
<poningru_class> sorry wrong window
<pitti> elmo: is it possible to add a new langpack to breezy-updates?
<Znarl> HiddenWolf : Hi, I am a server admin.  What's wrong?
<HiddenWolf> Znarl, we've been getting gzip/pgp errors for a few days
<HiddenWolf> Znarl, W: GPG error: http://nl.archive.ubuntu.com breezy Release: Unknown error executing gpgv
<HiddenWolf> W: You may want to run apt-get update to correct these problems
<mirak> hi
<Znarl> HiddenWolf : Darn, ok.  I'll redirect nl.archive back to the UK.  
<mirak> the breezy kernel uses gcc4 or gcc3.4 ?
<HiddenWolf> Znarl, where does it go now?
<mjg59> 3.4
<mvo> HiddenWolf: can you run "apt-get update -o Debug::Acquire::gpgv=true" and store it in a pastebin?
<Znarl> ubuntu.ftp.heanet.ie.
<HiddenWolf> mvo, http://paste.ubuntulinux.nl/3287
<HiddenWolf> Znarl, best to wait untill we can get a solid ISP to mirror ubuntu.
<mvo> HiddenWolf: thanks
<HiddenWolf> Znarl, uk.archive has gotten me up to 600kbs during the Breezy cycle
<\sh> hmmm....gstreamer-mad has problems with 24bit mp3s ,-)
<\sh> or amarok has problems to receive 24bit mp3-stream correctly
<Znarl> HiddenWolf : heanet has 4gigs of bandwidth.  Far far more than most sites.
<ogra> \sh, tra with rhythmbox, if it breaks too, its gstreamer... else its amarok
<ogra> *try
<HiddenWolf> Znarl, true, but it's quite irish. :) #u-nl is working on bugging ISP's about local ubuntu mirrors.
<\sh> ogra: yeah...just now when I setup the r200 ;)
<Znarl> HiddenWolf : mirrors@canonical.com if any ISPs need to contact us, and yes Heant isn't exactly NL.
<HiddenWolf> Znarl, I'm trying to bug my own ISP atm, most have debian mirrors anyhow.
<HiddenWolf> I'll piont them there if they're interested.
<mirak> are you sure linnux-image 2.6.12-9 is built with gcc 3.4 ?
<ogra> mirak, there is no support upstream for newer compilers yet
<mirak> I am tring to build the module cdfs from cdfs-src with module-assistant but it fails
<mirak> it fails at inserting
<mirak> FATAL: Error inserting cdfs (/lib/modules/2.6.12-9-386/kernel/fs/cdfs.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<dholbach> does dmesg say anything useful?
<mirak> cdfs: Unknown symbol PAGE_BUG
<mirak> I used gcc 3.4
<carstenh> ogra: JFYI: debian uses a newer compiler with 2.6.12.x
<ogra> oh ? 
<ogra> has lins finally switched ? 
<carstenh> ogra: try cat /proc/version
<ogra> *linus
<carstenh> Linux version 2.6.12-1-amd64-k8 (buildd@athlon) (gcc version 4.0.2 (Debian 4.0.1-9)) #1 Wed Sep 28 02:31:26 CEST 2005
<carstenh> ^^ on debian/amd64
<ogra> Linux version 2.6.12-9-amd64-k8 (buildd@king) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:13:36 BST 2005
<ogra> ubuntu amd64 :)
<ogra> mirak, cdfs-src_2.4.20+2.6.3-2_all.deb ??
<ogra> mirak, that somehow indicates it works with 2.4.20 and 2.6.3
<HiddenWolf> mvo, just curious, what did you just tell me to execute?
<mirak> ogra: cdfs-2.6.12-9-386_2.4.20+2.6.3-2+2.6.12-9.23_i386.deb
<ogra> mirak, where di you get that ? 
<ogra> *did
<mirak> ok this one is built one from sources, wait
<mirak> Filename: pool/universe/c/cdfs-src/cdfs-src_2.4.20+2.6.3-2_all.deb
<mirak> ogra: this is the sources 
<ogra> yup... see above...
<mirak> ogra: so it can't work
<mirak> ?
<ogra> no idea, but thats what i'd guess with these version numbers
<mirak> ogra: I will try with debian one
<mirak> http://ftp.fr.debian.org/debian/pool/main/c/cdfs-src/cdfs-src_2.4.20.a+2.6.12-2_all.deb
<ogra> most likely it didnt get updated in universe for breezy
<mvo> HiddenWolf: it just turns on debug in apts gpg checking
<mvo> other than that it's a normal update
<HiddenWolf> mvo, cool. :)
<mirak> ogra: this works with this one
<Znarl> HiddenWolf : Changed nl.archive.u.c.  Please let me know if you still get the same error.
<HiddenWolf> Znarl, I'll keep you updated.
<Znarl> Thanks, and be aware of DNS cache issues too.
<HiddenWolf> Znarl, cool
<WaterSevenUb> seb128, would you check http://bugzilla.ubuntu.com/show_bug.cgi?id=18050? Can this be solved through a breezy-update?
<WaterSevenUb> or someone involved with yelp and ubuntu-docs....
<seb128> WaterSevenUb: maybe jbailey has an idea on that
<dholbach> WaterSevenUb: what did the guys on #ubuntu-docs say?
<WaterSevenUb> dholbach: I'm going to ask them....
<dholbach> cool
<predius_> guys, theres a problem with kernel 2.6.12-9-686.
<predius_> it's compiled with gcc 3.4/
<pitti> predius_: that itself is not a problem
<predius_> therefore, to compile alsa modules, I had to get gcc-3.4
<predius_> hasn't ubuntu switched to 4.0?
<dholbach> not for the kernel
<predius_> ah.
<predius_> k
<dholbach> there is other stuff compiled with 3.4 too
<predius_> then gcc-3.4 should be also included in build-essential
<Amaranth> the kernel fails to compile with gcc4
<Amaranth> i think the kernel-source packages depend on gcc3.4
<dholbach> predius_: no, it's not the default compiler
<pitti> predius_: no, linux-source-2.6.12 build-depends on gcc-3.4
<predius_> the headers do not.
<^rob^> stupid slow mirror capped at 5500k/sec
<predius_> and i need the headers to compile the alsa modules.
<^rob^> kinda sad, it's quicker to download a LiveCD and open it in a virtual machine than it is to run updates ;)
<^rob^> hrmm, uhoh, Firefox is showing the download at 930 megs so far :(
<ogra> predius_, there are alsa modules we dont contain in the linux package ? 
<predius_> ogra: i used module-assitant, and did the usual.
<ogra> the ususal ? 
<predius_> prepare, selected alsa, then did all the steps.
<predius_> build failed because compiler was different from kernel compiler
<WaterSevenUb> seb128,dholbach, he isn't around I guess.. well I'll try again tomorrow.
<dholbach> WaterSevenUb: ok
<dholbach> predius_: then you have to set the compiler you use for alsa*
<ogra> predius_, and you are sure the module you need isnt already there ? 
<predius_> i already did it, but i know what gcc-3.4 and gcc-4.0 mean
<predius_> people don't/
<predius_> and they would probably get stuck there.
<pitti> predius_: people usually don't compile ALSA modules either
<pitti> predius_: we already ship ALSA modules, so there is no reason why a newbie would even think about the possibility of compiling ALSA on their own
<sivang> hmm, what mirrors do we have for ISO downloads other then the LOndon one in EU ?
<pitti> sivang: jigdo rocks :-)
<predius_> well, i have to go.
<Znarl> sivang : http://www.ubuntu.com/download/
<predius_> k
<sivang> Znarl: k :)
<sivang> pitti: is it straight forward like using bitorrent ?
<pitti> sivang: I don't know, bt doesn't work for me
<pitti> jigdo-lite http://cdimage.ubuntu.com/daily/current/breezy-install-amd64.jigdo
<pitti> sivang: ^ that's everything
<sivang> cool :)
<pitti> sivang: of course I wrapped it in a script which automatically mounts my old ISO so that jigdo can scan it, and the like
<pitti> but basic operation is trivial
<Kamion> jigdo is really only beneficial if you have either a local mirror or an old image
<pitti> sivang: and you can use an arbitrary mirror (including local ones) and scan existing iso images, /var/cache/apt/archives, and so on
<Kamion> otherwise you might as well download the whole thing :-)
<sivang> yes, I'm at my parentt's house, and left my CDRW with the latest daliy at my flat :-/
<sivang> so it will be from-scratch download for me
<pitti> sivang: then it's indeed no big win, unless your connection to any mirror is significantly faster than cdimage.u.c
<\sh> digital tv nrw is broken again :( 
* dholbach comforts \sh 
<\sh> I hope I can fix it remotely via phone :(
* ogra pats his dish
<jbailey> ogra: Like my cats when they're hungry? =)
<ogra> hehe...
<sivang> pitti: is there a .de mirror for the ISOs ?
<pitti> sivang: none that I'm aware of
<ogra> jbailey, now that you remind me, i have to feed mine... thats the strange noise from the kitchen ... :)
<pitti> sivang: well, my local hard disk :-)
<sivang> hehe, ok
<dholbach> sivang: i pushed out 7GB of isos, but i guess, i don't qualify as a mirror :)
<jbailey> ogra: One of mine has discovered that standing on my hair when I'm sleeping 1) Wakes me up, 2) Keeps me from effectively beating him away. ;)
<dholbach> . o O { cats... :) }
<Nafallo> \sh talked about something 4Gbit pushing out isos.
<Diziet> Hmm.  It looks like most of our HUGE diff from firefox upstream is not necessary any more.
<ogra> mine like to put their paws in your mouth while you sleep... 
<\sh> fck...
<Diziet> And Debian's diff against 1.4.99betawossname is a snip at 5k lines or so.
<dholbach> Nafallo: oh, i was just talking about 7 gigabyte i pushed in total :)
<Nafallo> dholbach: yea, but I'm sure it wasn't you on 4gb/s he was talking about. if you only did 7GB on that speed I'm amazed ;-).
<dholbach> haha :)
<Nafallo> \sh: fck? :-)
<\sh> yes...I have to eat my dinner and hurry into office :(
<Nafallo> ehm, oki :-P
<Nafallo> df
<Nafallo> hf even
<\sh> Nafallo: there is no fun involved anymore
<Nafallo> \sh: something bad happened then? :-/
<\sh> Nafallo: just because i'm the "ops guy living 20 mins from office, so lets call him"
<ogra> Nafallo, 4mio customers without TV ...
<sivang> pitti: should jigdo-list be available by path?
<Nafallo> ah. you should move to za, they can't say that then :-)
<pitti> sivang: I never heard about -list
<sivang> pitti: err, nm. got it.
<sivang> pitti: it's not in jigdo pkg, only in jigdo-file
<pitti> sivang: right, jigdo is for creating images
<Nafallo> ehm, jigit anyone? :-)
<sivang> lol
<\sh> Nafallo: oh yes...moving to ZA helps a lot ;)
<Nafallo> \sh: well.. sure. they can't say you're the closest one to the office then :-)
<sivang> nice, I'm getting HTTP connection timeotus. Iguess I'll stick to rsyncing.
<\sh> so laptop testing team has to wait for my report of breezy final a little bit longer
<sivang> \sh: how does it help? 
<\sh> sivang: first of all: I can eat biltong all the time, second, I can have chili cheese lam burger at durbans coconut grove take away every day and third, I could try to work for a IT company which is using linux as their fav. standard OS ;)
<\sh> but first I have to find no. three to achieve goal 2 and 1
<Nafallo> \sh: just keep the server on your old job... :-P
<sivang> \sh: hehe :-)
<\sh> Nafallo: well...there is no server at my old job...digital tv is only using some pieces of strange appliances running shareware ,-)
<Nafallo> hihihi
<\sh> Nafallo: and the ISP plattform (which is also our responsibilty) is running without any problems...only digital tv :(
<\sh> ogra: you have my voice at TB if i'm not back at 20 UTC...
<\sh> bbl
<sivang> anybody else have experienced the low throughput from a.u.c (rsync) ? It used to be almsot using most of my bandwidth but now...
<pitti> sivang: why do you rsync from archive?
<sivang> pitti: to be able to continue downloaidng should the downlod fail
<pitti> sivang: from archive?? you mean from cdimage?
<sivang> pitti: hrm, yes
<pitti> sivang: wget -c can continue an interrupted download
<pitti> sivang: rsync is a total waste if you don't have an existing image
<sivang> I had the impression it was less robust
<sivang> ok, will do that now, thanks!
<sivang> (robust in recovering an interrupted download)
<dereks__> pitti: rsync would be appropriate for a mirror though, right?
<sivang> pitti: yet, I think the archive is crying under the load
<pitti> dereks__: sure, yes
<ogra> dereks__, you win with rsync if you only snyc diffs
<ogra> else its just a normal download, even if you use rsync
<dereks__> ogra: hmmm
<ogra> i.e. if yo already have an archive, the binary difference only get synced...
<dereks__> ogra: i just built a new comp with tons of hd space to spare, so i was going to make a mirror that syncs nightly
<ogra> during breezy release cycle i could rsync a CD image in 6-10 min over a 768k line here
<dereks__> for my computers
<ogra> (between two dailies)
<dereks__> using rsync
<ogra> thats great... just the first rsync will be a normal download... later you only get diffs
<dereks__> right
<dereks__> i would just run " rsync://archive.ubuntu.com/ubuntu" nightly right?
<Kamion> dereks__: rsync's pretty hard on servers - I wouldn't use it for lots of smallish files
<dereks__> Kamion: so initially do a wget?
<Kamion> unless I was running a full mirror, in which case the maintainability win is obvious
<dereks__> then rsync?
<Diziet> I reallyshould package up magicmirror  one of these days.
<Kamion> dereks__: if you're running a full mirror, it's best to get in touch with admins so that they can point you to a good local mirror to rsync from, rather than everyone turning up and trying to rsync from archive.u.c
<Kamion> saving Diziet's magicmirror, debmirror's probably the simplest packaged option
<dereks__> Kamion: alright, i will keep that in mind, first i have to figure out why amd64-smtp isn't working :)
<Diziet> Maybe I'll do that tomorrow.  That way I can put off fighting the ffox diff swamp :-).
<Kamion> ogra: you don't get any download-differences-only win with rsync over (something like) debmirror, because the files in a Debian-style archive are either preserved, or replaced by files with different names; rsync can't deal with renamings automatically, and in any case .debs aren't usefully rsyncable in general
<ogra> Kamion, ah... ok, i have not much archive mirroring experience...
<Kamion> it's much more useful for large files like CD images because (a) their names don't change often and (b) they tend to be quite rsyncable, in that only bits of the file change from day to day
<Diziet> I should bolt jigdo into the back of it too, so you can have a daily CD ready and waiting each morning, just in case.
<ogra> Diziet, is jigdo better than rsync for that ? 
<Diziet> Yes, much, if you're keeping a mirror anyway.
<Kamion> ogra: if you're already downloading the files for a local mirror anyway, jigdo saves you from having to download them again
<Kamion> read up on how the various tools work, then the trade-offs should be more obvious :)
<ogra> yes, will do ;)
<dereks__> kikidonk: ping?
<kikidonk> dereks__: yes :)
<kikidonk> yes ?
<dereks__> kikidonk: just wanted to say, amazing work on deskbar
<kikidonk> oh ! thanks
<dereks__> my favorite new toy :)
<kikidonk> cvs is much better
<dereks__> hmmm, are you going to make me upgrade now :)
<kikidonk> there is also a #deskbar on Gimpnet, if you want
<kikidonk> i'd do it :P
<dereks__> ahh, let me head over
<herzi> gut, dann kopier' ich dir die auch noch fix
<herzi> sorry
<bddebian> yar
<bddebian> :-)
<herzi> echan
* pitti beats tarfile
<HiddenWolf> pitti, why the violence?
<pitti> HiddenWolf: It took me 45 minutes to debug a problem that is eventually a tarfile bug
* HiddenWolf hands pitti a bat
<HiddenWolf> That sucks. :(
<pitti> HiddenWolf: when I add several files to an open tarfile, it randomly creates hardlinks to already existing files
<pitti> if I close and reopen the tarfile object in between, it works
<HiddenWolf> pitti, nice.
* pitti currently writes a test case
<pitti> any python expert here?
<sivang> mvo: ping
<zyga> hi
<sivang> hey zyga 
<\sh> really..some days I should erase from my calendar
<zyga> I've finally got a working low end printer for linux :)
<zyga> and it's really pretty too...
<zyga> :-)
<mvo> sivang: pong
<zyga> cool article on ./ about yellow dot patterns in laser printers
<sabdfl> mjg59: around for the TB in 15?
<mjg59> sabdfl: Sure
<sabdfl> \sh: yeah, agreed, it's been one of those
<sabdfl> mjg59: cool
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | topic will be changed when Dapper opens
<Kamion> (guessing it won't open today after all, although perhaps I'm underestimating the remaining few hours)
<ajmitch> morning all :)
<ajmitch> jbailey: ping
<jbailey> Andrew my friend!
<ajmitch> jeff!
* jbailey pours a vodka for eacah.
<jbailey> each.
<\sh> sabdfl: what happened?
<ajmitch> a bit early in the morning for that, but oh well :)
<sabdfl> \sh: just trying to get some launchpad stuff landed, and also move myself over to Phase III
<ajmitch> jbailey: where do I access the mounted root filesystem form initramfs?
<\sh> sabdfl: nice...I just had another idea to improve ubuntu for server admins ... 
<jbailey> ajmitch: Once it's mounted, it's in /root
<ajmitch> jbailey: right, when does it get mounted?
<sabdfl> \sh: ok, put it on the TB agenda, unless its a spec, then put it on the UBZ agenda :-)
<\sh> sabdfl: but this is so crazy that I have to think about this idea again and have to do some diagrams
<ajmitch> jbailey: I'm wanting to load selinux policy as early as possible, and it'd be nice to read it from disk
<ajmitch> \sh: sounds tempting
<\sh> sabdfl: it's more a "beat RHN" ,-)
<jbailey> ajmitch: You could probably do this in local-bottom and be certain.
<jbailey> Or perhaps we should have an init-bottom hook.
<ajmitch> jbailey: those hooks run before udev, are the lvm device nodes created before then?
<\sh> sabdfl: I just mentioned a word in a mail about the kernel thread...but right now, don't take me too serious about it...
<ajmitch> I saw that lvm/evms, etc are in init-top
<jbailey> ajmitch: local-premount should have all of the lvm nodes and stuff already.
<jbailey> I think most of those get created in local-top
* ajmitch needs to take a look again :)
<ajmitch> ah right, local-top
<ajmitch> local-premount has suspend
<jbailey> Right.  That's the last ditch effort to resume before we mount the partition and screw it all up.
<ajmitch> jbailey: the main thing is ensuring that both files & processes get the right labels/contexts
<ajmitch> which is why sysvinit is currently patched, and it's not just done in an init script
<jbailey> ajmitch: Great!  What's a labael/context? =)
<jbailey> Got a site for me to look at? =)
<ajmitch> jbailey: files get labels when they're created
<ajmitch> processes get contexts, which the kernel uses to allow access to things :)
<ajmitch> jbailey: there might be a quick summary site, for some weird definition of quick
<jbailey> *lol*
<sabdfl> \sh: not a bad idea, feel free to get into more detail with benc and fabbione about it. fabbione has similar thoughts
<jbailey> ajmitch: Is it important for every file on disk to be touched like that?
<ajmitch> jbailey: it's important that every file that is created gets created with the right label, if it's to be used
<\sh> sabdfl: well it was only "real life thinking" and experiences from some companies which are running more then 100 servers ;)
<ajmitch> relabelling the whole disk manually isn't often done
<ajmitch> but it is possible to relabel :)
<ajmitch> it's the kernel that assigns these labels, with the policy loaded :)
<sabdfl> \sh: elmo builds monolithic kernels too. i like the idea of making that easier
<\sh> sabdfl: well it's a matter of how ubuntu defines "support". I don't think we will have much problems with the desktop (well, ok if ubuntu will focus as well pixelpark, then we have to apply server rules as well to the desktop), but for the server, admins are more conservative then Mr. Bush will ever be
<tseng> haha
<tseng> you are funny
<\sh> Or Mrs. Merkel in germany ,-)
<ajmitch> yay politics
<bddebian> Oh here we go again, it's always got to descend into US bashing doesn't it?
<\sh> forget the politics...
<dholbach> bddebian: first in #ubuntu-bugs and now in #ubuntu-devel?
<\sh> meeting now
<ajmitch> bddebian: that was no bashing :P
<mjg59> bddebian: Calling the US president conservative isn't really bashing
<mjg59> (But yes, this isn't the time or place)
<ajmitch> jbailey: will talk to you later about, I need to look at the code more ;)
<\sh> it wasn't personal...if I hurt somebody, please take my sorry..
<bddebian> \sh: Nah.. :-)
<chimaera> re
<HiddenWolf> ogra, congrats on that blog entry. :)
<dereks__> who would i talk to about questions about kernels built for different architectures?
<ogra> hehe... thats really something that makes me feel its done... i havent had the feeling yet :)
<chimaera> err, no re.. missing a "k". bye ;)
<ogra> HiddenWolf, thanks
<sourcequench> I'm pretty sure I have a bug in the breezy installer for AMD64.  Would this be the right place to mention it?
<tseng> bugzilla would be better
<tseng> assuming its not already reported there
<sourcequench> I didn't see anything--I'll go submit it.
<tseng> great, thanks.
<HiddenWolf> ogra, but still, is sitting around #ubuntu having fun a contribution at all, is writing docs, is it coding, or fixing bugs? 
<zyga> Treenaks: ping
<chimaera> hi. can anyone tell me where the the zd1211 module (wifi) expects to find the configuration for the card? even if i comment the essis, i get " ****** Can't find desiredSSID:" after plugging in the device..
<zyga> Treenaks: about the bearded guy issue
<zyga> Treenaks: is there any way to make him less ... dithered!
<zyga> chimaera: check #ubuntu
<chimaera> zyga: thanks.
<dholbach> good night guys
<ogra> night dholbach 
<crimsun> night daniel
* ajmitch needs something like qemu run from console, so he can test init-like crack remotely :)
<ajmitch> jbailey: you just have test hardware you ran on?
<jbailey> ajmitch: I used my laptop for all my initramfs-tools stuff.
<ajmitch> right
<jbailey> ajmitch: I do almost all of my tests on real iron.
<ajmitch> I don't have my laptop beside me right now, so I guess I'll test at home :)
<ajmitch> it needs another fresh install anyway
<zyga> does anyone remember who has made that tiny python app, fanboy?
<mvo> zyga: IIRC it was keybuk
<zyga> mvo: I'm probably starting to sound like a broken record player
<zyga> but I've got i18n patches and minor bugifix ;-)
<allee> I've a keycodes & description of a Dell USB keyboard.  How to proceed? File a wish (against with pkgs?). Write a xkb file? Add to wiki Keycodes page? Or ...? Any hints lifeless|mjg59?
<mdke> allee, bug against acpi-support i think
<allee> + keycodes of multimedia keys that is
<allee> mdke: Sure? with usb acpi is not involved.
<allee> I have a look at acpi-support pkg
<mdke> perhaps I'm wrong
<mdke> but I'm sure it will be reassigned
<allee> mdke: yeah. it will.  I like the idea :)
<zyga> lol
<zyga> the only things you can't avoid in life are death, taxes and Ubuntu reviews.
<Mithrandir> you can avoid some of them by attaining the first one.
<lifeless> Mithrandir: nup, because then they are not 'In life'. :)
<Mithrandir> well, point.
<zyga> Mithrandir: unless you're caught by the other two while waiting in line for the first ;] 
<Mithrandir> lifeless: but are you alive when doing taxing ubuntu releases?
<lifeless> Mithrandir: FSVOA
<zyga> actually doing taxes on ubuntu is not so nice..
* Loiosh reads the meeting email even though he was there for it. Smart mink.
#ubuntu-devel 2006-10-16
<pygi> Kamion: lemme see if I can grab Luke Biddell on Jabber right now
<mjg59> Yay I can do real-mode BIOS calls
<mjg59> Oh, wait, no I can't
<Kamion> pygi: please don't interact with me on this
<Chipzz> Kamion: anyway, my apologies if my wording was a bit too strong; I just thought it was overkill in this case
<Kamion> the next I want to hear about it is when the upload lands in unapproved :)
<pygi> Kamion: ok, willt talk with Toad :P
<Kamion> I'm going to be going to bed soon and you shouldn't block on me
<Toadstool> Kamion: yeah, you're right, I'll take care of the tests
<Toadstool> thank you
<Kamion> np
<adamh> Heh, the debian/rules file is broken, too -- if /usr/bin/python is python 2.5, it breaks
<mjg59> Argh now it's back to being non-deterministic
<Chipzz> adamh: anyway, what makes you think that file should be there at all?
<adamh> Chipzz: It's supposed to be part of the python-profiler package.
<adamh> Chipzz: And I believe (I'm not 100% sure, I'm not too familiar with it) that /usr/lib/python2.5/cProfile.py (which is installed in the python2.5 package) depends on it.
<Kamion> Chipzz: it's specced to be: https://launchpad.net/distros/ubuntu/+spec/python2.5
<Chipzz> $ apt-cache show python-profiler
<Chipzz> Package: python-profiler
<Chipzz> Replaces: python2.3-profiler, python2.4-profiler
<Chipzz> Python-Version: 2.4
<Chipzz> how is this related to python 2.5 exactly?
<adamh> Depends: python-central (>= 0.5), python (<< 2.6), python (>= 2.4)
<Kamion> yes, and? it's internally consistent, but all packages providing python extensions were supposed to have been rebuilt with python2.5
<adamh> So it can be installed without even installing python2.4?
<Chipzz> it's probably just not updated yet
<Kamion> Chipzz: which is a bug, per the spec
<Kamion> if you'd bothered to read it
<Chipzz> I think the bug would be a total lack of support for 2.5, not the lack of that file
<Kamion> that's nitpicking
<adamh> Chipzz: python-profiler has total lack of support for python 2.5 :)
<Chipzz> Kamion: python-profiler is also universe apparently
<adamh> multiverse, actually, I think :)
<Chipzz> which if I understand correctly is not supported?
<Kamion> adam is correct
<Kamion> Chipzz: have a look through edgy-changes at all of doko's uploads to universe/multiverse for python changes
<Kamion> not supported != invulnerable to changes required by specs
<Kamion> sure, we won't break a huge sweat over it, but it should be sorted out
<adamh> Anyway, I just filed a bug on it, because whether it's supported or not, it's a bug :)
<Chipzz> Kamion: what I meant is, the maintainer probably lacked time or forgot about it
<adamh> And I imagine the fix is pretty easy :)
<Chipzz> :)
<Kamion> Chipzz: how does that justify giving a user who wants to remind the maintainer about it the third degree?
<ctrlsoft> Kamion: ping
<Kamion> ctrlsoft: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
<adamh> In the future, if I think I've found another packaging bug (but I'm not sure), is this the proper IRC channel to use?
<ctrlsoft> Kamion: Any chance you can schedule bzr-svn in edgy for a rebuild?
<Kamion> ctrlsoft: no, I'm not in launchpad-buildd-admins
<Chipzz> Kamion: 'the third degree'?
<Kamion> adamh: this or #ubuntu-motu is fine
<adamh> Kamion: Ah, gotcha. Okay, thanks :)
<ctrlsoft> infinity: Any chance you can schedule bzr-svn in edgy for a rebuild?
<adamh> quit
<adamh> er... :P
<Kamion> Chipzz: sitting arguing whether it's a bug or not and nitpicking about the exact nature of the bug ("total lack of support for 2.5, not the lack of that file". yeah, whatever)
<gnomefreak> are all bug fixes able to be uploaded during the freeze or depends on how severe they are?
<Kamion> gnomefreak: the latter
<gnomefreak> k
<ctrlsoft> Kamion: sorry
<Kamion> ctrlsoft: no problem, I get that a lot :)
<Kamion> gnomefreak: talk to dholbach or ajmitch or one of the other senior MOTUs if in doubt
<gnomefreak> k ty
<Chipzz> Kamion: I thought that bug was not urgently relevant to the release and you guys had more urgent things to handle atm
<doko_> <doko_> Kamion: yes, will take care of it (it's not on the CD ;)
<doko_> * Disconnected (Network is unreachable).
<shining> doko_: hey
<Kamion> Chipzz: users trying to remind us of bugs shouldn't be told to go away; sure, redirect them to a more appropriate location (like launchpad), but trying to argue that it isn't a bug because we don't have time for it is rather perverse
<Kamion> doko_: thanks
<Kamion> Chipzz: we absolutely do not want to lose bugs just because we're busy
<shining> doko_: do you have any clue about the cause of bug 31889 ?
<Ubugtu> Malone bug 31889 in eclipse "Cannot start eclipse: libswt-mozilla-gtk-3139.so: undefined symbol: NS_InitEmbedding" [Medium,Needs info]  http://launchpad.net/bugs/31889
<doko_> Kamion: please review http://people.ubuntu.com/~doko/edgy/ooo.debdiff (just po/pot updates), that one should build on palmer
<Chipzz> Kamion: I was going to point out to him to file a bug in launchpad
<Chipzz> but nm
<shining> doko_: it seems it was fixed once, and then came back, I don't understand why.
<doko_> shining: installing mozilla-browser should work
<gnomefreak> shining: wait in line ;)
<gnomefreak> i so dont want to rebuild this anymore lol
<doko_> shining: do you know how to build eclipse plugins?
* gnomefreak bows to doko_  "i know how much of a pita eclipse is now"
<Kamion> doko_: the diff looks fine on the face of it, although we're past the non-language-pack translation freeze ...
<Kamion> but, since *all* translations are missing, I guess we can let you get away with it
<Kamion> doko_: I can't make it build on palmer though - that needs infinity
<shining> doko_: was this question for gnomefreak or me?
<gnomefreak> shining: you
<doko_> Kamion: right, I dropped them in ~rc3 and didn't notice :-/
<shining> no, I don't
<gnomefreak> shining: he said you nick ;)
<Kamion> infinity: please accept openoffice.org once (a) it's there and (b) you're around and ready to make it build on palmer
<Kamion> doko_: ok, ASAP please
<Kamion> we're going to need the buildds in a hurry tomorrow
<doko_> Kamion: uploaded
<gnomefreak> doko_: i found the problem with eclipse build deps but im shaky on building it i built eclipse itself but the depends go further than just eclipse some of the libs need to be reb uilt also
<gnomefreak> s/reb uilt/rebuilt
<shining> doko_: now I'm confused. a while ago, eclipse didn't work, even with mozilla-browser installed. Now it seems to work in both case (with or without mozilla-browser). eclipse didn't change since, and I don't think mozilla changed neither
<doko_> shining: try to open the help, doesn't work without mozilla-browser
<zul> infinity: uvf for xen-source-2.6.17?
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.2.diff, when you're around
<shining> doko_: indeed, the help is only used on first start, that's why it didn't crash anymore. thanks
<shining> doko_: so the problem is still there, even if mozilla-browser is installed
<Kamion> bhale: can I remove the gmime2.1 source package and its binaries from edgy? it has no rdepends
<Kamion> I think its existence is causing apt to be unsure about how to do an upgrade on my system
<bhale> Kamion: yes please
<bhale> Kamion: (I've rebuilt everything against a later version but it seems apt is still unhappy)
<Kamion> done - let's see if that sorts it out
<bhale> I asked mvo when I first noticed it and he thought I should make sure nothing rdepend'd on it
<bhale> hopefully this one works better
<Kamion> it was having trouble upgrading tomboy here, and an explicit 'apt-get install tomboy' sorted it out
<bhale> else we need mvo to take another look
<bhale> right.
<Kamion> (or would have done; I've been deliberately not upgrading that, suspecting that archive action would solve it)
<doko_> Kamion: please approve openoffice.org-l10n; it should start building now, if it's built on palmer by chance, then infinity may cancel the build to give openoffice.org priority
<keescook> siretart: bug 66273> since it's just a debian upstream sync, what's the right way to do the upload?
<Ubugtu> Malone bug 66273 in dirvish "dirvish-expire never expires any backups" [Undecided,Confirmed]  http://launchpad.net/bugs/66273
<bluefoxicy> http://rafb.net/paste/results/CaePhO63.html  My current dmesg
<ajmitch> keescook: file a sync request, subscribe ubuntu-archive
<ctrlsoft> infinity: Any chance you can schedule bzr-svn in edgy for a rebuild?
<keescook> ajmitch: okay, thanks
<ajmitch> keescook: sync request should have the debian changelog entry in there
<keescook> ajmitch: should I open a new bug for it, or just retitle the old one?
<ajmitch> retitle
<infinity> ctrlsoft: Retried, same dpkg throws the same assertion, I'll have to see WTF that's all about.
<ctrlsoft> infinity: Thanks - it's installing the dependencies that's failing?
<infinity> Yeah.
<infinity> I'll sort it in a bit.
<slomo> infinity: hi :) will you also fix the apache/apache2 bug for edgy? or must this be delayed to next release? :/
<infinity> slomo: Will fix today.
<slomo> infinity: thanks :)
<infinity> (promise)
<zul> infinity: sorry i didnt see your response (if any)
<infinity> zul: xen-source?  If it actually works, I want it uploaded, yes.
<zul> ok will upload now
<pygi> night all
<infinity> zul: Thanks.  I suspect this will be the last (and working) upload of xen-source for edgy?
<infinity> Of course, it's universe, so we're slack there, and you could get approval from dholbach and ajmitch, but since xen-source stuffs up my buildds for a (long) while, I'd still prefer if you took me into consideratoin too. :)
<bluefoxicy> No comments on my awesome amount of CPU speed complaints in dmesg?
<bluefoxicy> I mean I know it's cut off above the last 1223 of them but D:
<zul> infinity: yeah probably :)
<fabbione> morning
<jook> hi
<jook> some ubuntu hacker?
<freet15> Jook:where are u ?
<Hobbsee> hey fabbione 
<fabbione> yo Hobbsee 
<jook> freet15, you are bot?
<freet15> no
<jook> freet15, i need the ubuntu installer source, i need for a university work
<freet15> Jook:test me ?
<jook> freet15, it is upload iin some site?
<freet15> i must go now, bye
<fabbione> ajmitch: about 200 pkgs to go
* mnepton jumps up and down on fabbione
<fabbione> mnepton: remember that you have wife.. and she is for sure more pretty than me
<mnepton> fabbione: but i like the feel of your beard stubble. and my girlfriend shaves every day. :/
* fabbione sighs...
<fabbione> put her online.. i will teach her :)
<mnepton> :)
<mnepton> she's on GIMPnet.
<mnepton> (but alseep)
<mnepton> hkufsrthnrn
<fabbione> who cares about GIMPnet.. take her here
<mnepton> fabbione: she may end up IRCing here more, as she gets more involved in Ubuntu stuffs.
* mnepton does not make demands, but just says "yes, dear," and "whatever you think is beast, dear."
<mnepton> beast?
<mnepton> let's try "best"
<fabbione> ehhe
<mnepton>  /dev/hands needs to be made ro
<fabbione> make[1] : Entering directory `/build/buildd10/ksimus-boolean-0.3.6'
<fabbione> *** YOU'RE USING autoconf (GNU Autoconf) 2.60.
<fabbione> *** KDE requires autoconf 2.52, 2.53 or 2.54
<mnepton> there are serious IO bottlenecks between my kernel and /dev/hands
<fabbione> Riddell: ^^ this is basically the same error on KDE apps in universe
<siretart> keescook: syncing works by subscribing ubuntu-archive and stating exactly from where to sync, and a small report what ubuntu changes got dropped and way. the package in question did not have ubuntu changes IIRC
<siretart> morning
<pitti> Good morning
<ajmitch> morning pitti 
* mnepton tackjlehugs pitti
<mnepton> -j (fo those of you not in .no) :/
<pitti> hey ajmitch, moin mnepton 
* mnepton is educating himself on debian packaging, and thinking a prostate exam might be more fun
<infinity> Prostate exams ARE pretty fun, so that's not a fair comparison, really.
<mnepton> infinity: depends on the girth of the doctor's fingers.
<infinity> The bigger, the better, clearly.
<mnepton> Debian packaging is like a prostate exam by a doctor with psoriassis, swollen joints, and severe hand tremors.
<fabbione> mnepton: you want to take this to #ubuntu-on-crack
<pitti> mnepton: how on earth do you learn packaging? The die-hard close-to-the-metal 'no debhelper' way? :)
<mnepton> pitti: immersion and prayer.
<infinity> Even that's not so much effort, if you learn on something small like "hello".
<mnepton> fabbione: i got banned from #u-o-crack for being too odd. :/
<infinity> pitti: Without dpkg-dev is more fun, really.
<fabbione> infinity: never like a SOC studen that was using deb-build manually and editing stuff in DEBIAN and $layout
<infinity> You've seen the spec file that calls debian/rules, right?  To generate a .rpm and .deb with identical binaries and layout?
<infinity> Perverse.
<fabbione> no i didn't..
<lifeless> meep
* lifeless cries 
<fabbione> well that's sick.. but whatever.. indirection for perversions are unlimited
<bluefoxicy> #ubuntu-on-crack?
<bluefoxicy> what the hell?
<Chipzz> infinity: well by all means, please DO point me to a debian packaging tutorial that does explain more complicated things like debhelper...
<Chipzz> because all the ones I've seen were worthless
<fabbione> infinity: who did allow xorg-server to go in?????
<Chipzz> :)
<infinity> fabbione: Not I.
<fabbione> WTF
<infinity> fabbione: Blame Kamion when he wakes up, I guess.  I didn't get a chance to talk to seb abot it.
<infinity> s/abot/about/
<lifeless> surely thats aboot
<infinity> Probably should have rejected it while I was waiting.  Oh well.
<infinity> It's not like it's hideously broken, just.. Weird.
<infinity> (patching debian/* being the really weird bit)
<fabbione> infinity: well theoretically...
<infinity> I guess pitti's contageous. :)
<fabbione> ehhe
<fabbione> oh well
<fabbione> Seb touched it last.. he will also get the honour to merge it in edgy+1 :P
<infinity> lifeless: I don't want to hear it, Mr No Deeery.
<lifeless> Chipzz: IIRC womble's one is good
<lifeless> infinity: :)
<pitti> infinity: *grrr*
<Chipzz> lifeless: got an url for that?
<fabbione> Chipzz: a real hacker doesn't need a tutorial.. RTF(ine)M
<fabbione> Chipzz: or RTFC
<infinity> pitti: *grin*
<infinity> pitti: It's okay, I've seen someone patch debian/patches from debian/patches before.
<HrdwrBoB> ouch
<infinity> It's hard to top that...
<HrdwrBoB> my logic
<Chipzz> fabbione: yeah there's the Ubuntu packaging guide
<tfheen> Kamion: if bits[2]  in ('dz', 'km'): looks.. wrong.
<tfheen> Kamion: unless bits[2]  is actually the language code?
<pitti> infinity: heh, I know two people who did that :)
<mnepton> how ... masturbatory.
<infinity> Oh, I also saw someone add dpatch to a dbs package, because they didn't understand dbs.
<infinity> I won't name names there, but that was special.
<fabbione> infinity: ehehehe
<infinity> Also, this laptop needs a faster hard drive, so I can actually do something other than babble on IRC while doing test installs.
<infinity> *sigh*
<mnepton>  /m infinity thanks for not naming names. i would have felt like a complete idiot.
<Chipzz> fabbione: I would still call it incomplete though
* pitti removes the fixed bugs from Testing/Current
<Chipzz> but I guess this is off-topic
<infinity> The last 10 minutes was off-topic.  I'll only mind if someone has something on-topic to say and it gets drowned out.
<lifeless> Chipzz: nope
<lifeless> his name is Matt palmer, google is your friend
<Chipzz> fabbione: btw, were you kidding about the SOC student?
<Chipzz> because there is actually a "debian packaging tutorial" somewhere online that explains how a debian package works (in that it explains the DEBIAN dir etc)
<fabbione> Chipzz: no i am not kidding
<fabbione> Chipzz: the best tutorial are the docs on debian.org and the 8000 source packages in the archive.
<fabbione> what else do you need?
<lifeless> fabbione: 16K :)
<lifeless> 8K is so 1990's
<fabbione> lifeless: 8K sources.. =~ 20K binaries
<fabbione> and we are talking about sources here :)
<lifeless> mmm, I was sure it was over 10K sources.
<Chipzz> fabbione: well, a central and complete repository would be nice
<lifeless> but, nevermind.
<lifeless> Chipzz: archive.ubuntu.com!
<fabbione> Chipzz: apt-get source ... more central than that :)
<Chipzz> you have for example debian policy, the Ubuntu packaging guide, other stuff...
<Chipzz> but these are all seperate documents
<infinity> Chipzz: Debian Policy, the Debian New Maintainer's Guide, and the Debian Developer's Reference all seem good enough to me.
<infinity> But then again, I've never seen the point of "Ubuntu is a different distribution, so we must have our own docs" except in the few cases where it makes sense (documenting archive procedures and our whacky versioning scheme, for instance)
<Chipzz> infinity: some very minor nitpick maybe, but I just skimmed through the ubuntu packaging guide; it doesn't seem to refer to the Debian Policy?
<infinity> Maybe I'm an elitist (okay, okay, it's a proven fact that I am), but I appreciate the barrier for entry being slightly high enough that we filter out the truly clueless before they try getting things in the archive that run as root on my machine.
<infinity> Chipzz: I know nothing of the Ubuntu Packaging Guide, but if it doesn't refer to policy, that's clearly a bug, as we do follow Debian policy.  At least, we're sure as heck meant to.
<Hobbsee> last i knew, it does contain a reference to the policy
<Hobbsee> if not, bug laserjock about it :P
<tfheen> fabbione: I told Colin to accept xorg-server even with the weird patching, since it's better to have it in than not.
<Chipzz> infinity: go to system -> help -> system documentation ; click 
<Chipzz>     Packaging new applications for Ubuntu
<Chipzz> Hobbsee: maybe I overlooked it; I only skimmed through it
<Chipzz> but I kinda knew what to look for and still missed it?
<fabbione> tfheen: ok, we were just waiting to talk to seb this morning and get it done properly. There are also 2 other things that i am not sure about.. like the cmd line parsing order that might break the meaning of that patch
<fabbione> tfheen: 17 in the specific
<Hobbsee> Chipzz: i think it's under more documentation or something
<tfheen> fabbione: can you check whether it breaks or not, like, now?
<Chipzz> Hobbsee: ah yes, you're right; but I guess that should be more prominent really?
<Hobbsee> Chipzz: depends.  if the audience the ubuntu packaging guide is for a general idea, then you probably dont need to know that straight away.  as soon as you want to do more serious packaging, you know about the debian stuff, and the more links anywya, because the ubuntu packaging guide doesnt contain all the necessary info anyway
<Chipzz> but I have to say, the Ubuntu packaging guide is a real nice piece of work (not ironically meant)
<infinity> I'm pretty sure it's unrealistic to ask, but I'd like any packaging guide to start with "before you ever consider uploading something to Debian or Ubuntu, please read Debian Policy cover-to-cover to see if you've done something silly"
<infinity> The beginner's guides are nice (and the Ubuntu Packaging Guide looks alright), but there's no way you can know if you're breaking policy without knowing policy.
<Chipzz> infinity: I agree; maybe not in those wording, but at least a reference to it in the introduction with a short explanation of what it is and why it is important, instead of a bare link in an appendix
<tfheen> infinity: it should include "yes, really.  Cover to cover.  And then again." in the advice.
<fabbione> tfheen: not immediatly.. no..
<fabbione> tfheen: i will need a few minutes
<infinity> fabbione: Okay, confirmed, a fresh dapper install gave me a RESUME line.  GRR.
<infinity> fabbione: Now that it's reproduced, I'll go fix it.  Thanks.
<fabbione> infinity: no problem
<Kamion> fabbione: tfheen told me to let xorg-server in (nobody had uploaded anything better to fix the same bug ...)
<Kamion> tfheen: bits[2]  *is* the language code, yes.
<tfheen> Kamion: ok, approved then.
<Kamion> (oh, sorry, wasn't entirely caught up on scrollback when commenting on xorg-server)
<Kamion> Dzongkha;4;dz;BT;dz_BT;UTF-8;;
<Kamion> Khmer;4;km;KH;km_KH;UTF-8;;
<Kamion> it's parsing that
<fabbione> Kamion: no we didn't upload, because we were waiting to talk to Seb..
<tfheen> fabbione: while the patch is slightly on crack, I'm not going to accept another upload to just change that before RC.
<fabbione> tfheen: the patch itself change default behaviour of xvfb-run. I don't care about the patch being dirty. I care to understand why it has been done that way
* infinity does one more test install for paranoia's sake.
<infinity> Kamion: Are we positive that edgy's d-i will no longer write a RESUME= line to initramfs.conf, BTW? :)
<tfheen> fabbione: xvfb-run is used by a bunch of gtk-python packages as part of their build process, aiui.  xvfb didn't always run properly without that patch.
<siretart> Kamion: could you approve mythplugins from unapproved/universe?
<Chipzz> siretart: what changed?
<Kamion> infinity: obviously now you ask I'm paranoid, but:
<fabbione> tfheen: yes i know how it is used.. i reported the bug to seb :).
<Kamion>                         if [ -d /target/etc/initramfs-tools/conf.d ] ; then
<Kamion>                                 ramdiskconf=/target/etc/initramfs-tools/conf.d/resume
<infinity> Kamion: Kay. :)
<Kamion> siretart: when it arrives, sure
<Kamion> (and multiverse)
<siretart> err, I thought I uploaded it yesterady?
<infinity> Does VMware do snapshotting, or is it just easiest to copy my disk image somewhere before I mangle it?
<fabbione> tfheen: i am rebuilding now one of those packages that were FTBFS and see..
<infinity> Oh, look, snapshot in the menu.. But greyed out...
<Kamion> siretart: it's not there
<Chipzz> infinity: do you have vmware player or server?
<tfheen> fabbione: enjoy.
<infinity> Chipzz: Workstation.
<Chipzz> oh, dunnow about that
<Chipzz> I do know server does support it, and I actually allready used it with that
<Kamion> last mythplugins upload was on Thursday, and accepted
<Kamion> siretart: accepted now, though I'd have preferred actually fixing the bashism. :-)
<pitti> infinity: I have workstation here, too, and snapshotting works just fine
<infinity> pitti: Let me guess, the VM has to be off for the menu entries to light up? :)
<infinity> (Will test when I can turn it off)
<pitti> infinity: no, it can be on
<pitti> infinity: do you use a real partition or an image? (I use image files)
<infinity> Image file.
<pitti> weird
<pitti> hey seb128
<infinity> oh, the VM has the snapshotting feature disabled.  I see.
<infinity> How pleasantly intuitive.
<seb128> hi pitti
<Kamion> are we going to fix the xorg NBS packages before RC? Please say yes.
<Kamion> (xbase-clients, xlibs-dev, xutils)
<infinity> Would be nice.
<pitti> tfheen: permission to upload http://people.ubuntu.com/~pitti/tmp/xorg_7.1.1ubuntu3.dsc.debdiff ?
<seb128> "nbs"?
<Kamion> seb128: not built from source
<seb128> ah, k
<infinity> Actually, did Debian drop those binaries altogether?
<Kamion> i.e. still hanging around in the archive waiting for an ubuntu-archive member to remove them (only I'm not doing so in this case semi-deliberately)
<Kamion> xbase-clients | 1:7.1.ds-3 |      unstable | source, alpha, amd64, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<infinity> Err, no, Debian still ships them.
<Kamion>     xutils | 1:7.1.ds.2-1 |      unstable | source, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<infinity> Fun.
<Kamion> Debian doesn't ship xlibs-dev any more
<Kamion> mdz explicitly asked for that to be put back, though
<infinity> What do we want it to depend on?
<infinity> Same list as in dapper?
<seb128> infinity: could you give a retry to libgtk2-perl?
<infinity> seb128: Sure.
<seb128> thank you
<Kamion> hang on, we have xorg-dev
<infinity> Yeah, I believe it was renamed intentionally to force people to fix their build-deps.
<infinity> Or somethng equally clever.
<infinity> If we really want xlibs-dev back, it could just depend on xorg-dev, but I won't like it. :)
<Kamion> nah, that's fine then
<Kamion> except for the *shitload* of deps on xlibs-dev
<Kamion> and build-deps
<infinity> Are there still build-deps?
<Kamion> ok, it's too late for this, it needs to come back as a transitional on xorg-dev I'm afraid
<infinity> If so, I guess we need to bring it back for now. :/
<Kamion> main: djvulibre gimp gnopernicus kmplayer libdv libgd-gd2-perl libgd2 libgdchart-gd2 python-gd scim tk8.3 tk8.4 tuxtype xine-lib zephyr
<Kamion> universe: alevt arla asmon bbdate deskmenu docker dx fbdesk ghc-cvs gngb gpsim gtkglext gvidm itcl3.0 krb4 libgd libgd-perl libgnome-gnorba-perl morse-x pclock pharmacy php-imlib pointless tclx8.3 tk8.0 wm2 wmacpiload wmbatteries wmbinclock wmclockmon wmdiskmon wmfortune wmifs wmpinboard xastir xcingb xemacs21 xfree86-driver-synaptics xgraph xlassie xlife xpcd xpdf xqbiff xreverse xtv
<Kamion> a lot of those are probably |-ed deps though
<Kamion> checkrdepends isn't quite clever enough to check for that
<Kamion> ghc-cvs (random selection) build-depends: xlibs-dev without alternate
<Kamion> likewise python-gd
<tfheen> pitti: approved.
<jdub> dholbach can't join because he's been banned from freenode
<jdub> oh
<jdub> never mind, it was only his entire isp
<pitti> tfheen: uploaded, thanks
<jdub> and apparently it's okay again
<jdub> or something
<Fujitsu> jdub, is he likely to be on at some point in the near future?
<jdub> he's on gimpnet atm
<infinity> Kamion: The ones in main would certainly all be |'ed.
<infinity> Kamion: Can't speak for the ones in universe, but I'd hope they're all fixed by now..
<infinity> Kamion: Or mostly.
<infinity> Kamion: But we can bring it back for one more cycle as a transitional package. :/
<infinity> Hrm.  It's not d-i that was adding the RESUME, it was something in ubuntu-desktop...
<infinity> (A "server" install didn't break)
<pitti> argh, why can't I burn CD-ROMs any more?
* pitti blames a running vmware
<pitti> moin tkamppeter 
<infinity> seb128: libgtk2-perl looks happier this time 'round.
<seb128> infinity: rock on ;)
<Riddell> fabbione: you need to run make -f admin/Makefile.common with this patch http://kubuntu.org/~jriddell/kubuntu_00_autoconf2.60.diff
<tfheen> Riddell: have you investigated the ktorrent ftbfs on ppc?
<Riddell> tfheen: I uploaded a new ktorrent last night to fix it
<tfheen> Riddell: ok.
<Riddell> tfheen: looks like it worked https://launchpad.net/distros/ubuntu/+source/ktorrent/2.0.3-0ubuntu4
<tfheen> Riddell: indeed.  Good.
<tfheen> thanks.
<s4lvuzzo> hi all
<pitti> hm, the CD check still doesn't reboot correctly
<tfheen> pitti: which arch?
<pitti> tfheen: amd64
<tfheen> pitti: and desktop or alternate?
* pitti looks for a bug and will file one if appropriate
<pitti> tfheen: alternate
<tfheen> grr, I though I had worked out all the quirks in that one.
<tfheen> it just loops?
<fabbione> Riddell: i don't need to run anything.. i was just reporting to you the tons of FTBFS from a edgy builds on edgy run
<pitti> tfheen: yup, see http://people.ubuntu.com/~pitti/tmp/cdcheck-boot.png
<janimo> tfheen: http://paste.ubuntu-nl.org/26980/ exception request, only config file changes to better support a11y, and add a trash to the default panel
<fabbione> pitti: did you see the new FTBFS i assigned to you?
<fabbione> mvo: same to you
<janimo> tfheen: having these in place allow enabling xubuntu a11y from casper with very few lines
<pitti> tfheen: followup and screenshot attached to bug 28033
<Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Medium,Confirmed]  http://launchpad.net/bugs/28033
<pitti> fabbione: no, I didn't yet
<tfheen> janimo: no, does not fix 6.10-targetted bugs.  Sorry.
<mvo> fabbione: checking now, thanks
<janimo> tfheen: xubuntu a11y was targeted ad 6.10, it's just not in the milestone bugs because it is not ubuntu or kubuntu
<tfheen> janimo: I said, days, ago that I would not accept changes in main for things which aren't 6.10-targetted.
<tkamppeter> h pitti
<janimo> tfheen: I asked mdz and he said that unless you need to specifically roll livefs-s or I otherwise make you lose time xubuntu changes are my call, but I should be careful
<janimo> tfheen: I could not target xubuntu bugs as 6.10 anyway since it is not officially supported, so I don;t see how I could do anything past freeze this way
<infinity> janimo: If they're your call, they're your call.  We're definitely not in livefs land right now, since we need to wait ~6 hours for OOo-l10n to finish.
<janimo> infinity: I do not want to waste your or tollefs time, so I am not requesting you roll xubutu CDs besides what cron does. This is what mdz meant I should watch out for
<janimo> infinity: I just wanted to knwo if I can still upload as I did not speciifically ask mdz if I need to request permission before uploading
<janimo> I don;t know if things just get queued or rejected unless tfheen approves them before upoad
<janimo> infinity: does that OOn-l10n thing fix the locales depend on OOo-common by the way?
<janimo> infinity: anyway for the xubuntu live Ithink I specify tbird and ffox locales explicitely not via langage-support so it does not pull ooo in by accident
<infinity> janimo: No, the last OOo upload should have, though (just hitting mirrors now)
<tfheen> janimo: if mdz said it's your call, then it's your call and I'll wave through anything which is xubuntu-specific.
<janimo> tfheen: thanks!
<pitti> tfheen: I just noticed that our last imagemagick sync broke SGI image parsing due to an accidentally dropped 'i=0' initialization. But I guess this is too unimportant for edgy at that point?
<tfheen> pitti: which image format did you say? ;-)
<pitti> tfheen: exactly :)
<infinity> Which SGI format?
<tfheen> pitti: so yes, edgy+1
<pitti> infinity: 'which'? well, coders/sgi.c says 'Irix RGB Image format'
<pitti> infinity: i. e. the one you likely never heard of :)
<infinity> Oh, that.  No one uses that.
<infinity> (I asked because TGA is also an SGI format, IIRC)
<infinity> And broken TGA would be a big deal.
<pitti> yeah, I just stumbled across it when reviewing the recent security patch; I notified Daniel Kobras, so it'll get fixed in Debian soon hopefully
<tfheen> doko__: bug 65908 should be marked as fix released, shouldn't it?
<Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Critical,Fix committed]  http://launchpad.net/bugs/65908
<tfheen> Riddell: wasn't bug 65665 fixed by reverting a patch to kdelibs?
<Ubugtu> Malone bug 65665 in kdebase "Cups printing fails after update to kde-3.5.5" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65665
<infinity> tfheen: Once vmware is done arguing with my hard drive, that initramfs-tools bug will have an upload, BTW.  I'll pass the diff to you for review after I'm satisfied that dpkg DTRT with it.
<tfheen> infinity: thanks.
<tfheen> Riddell: same for bug 65697 ; was this fixed in your latest k-d-s upload?
<Ubugtu> Malone bug 65697 in kubuntu-default-settings "kubuntu dapper can't display Chinese in non-Chinese locale" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65697
<Kamion>   109694 | S- | ltsp                 | 0.123                | nine minutes
<Kamion>          | * ltsp/0.123 Component: main Section: misc
<Kamion>   109688 | S- | xorg                 | 1:7.1.1ubuntu3       | 54 minutes
<Kamion>          | * xorg/1:7.1.1ubuntu3 Component: main Section: x11
<tfheen> Kamion: xorg is approved.  I have no idea about ltsp.
<fabbione> seb128: ping?
<seb128> fabbione: pong
<ogra> tfheen, closes #65690 (RC bug)
<tfheen> bug 65690
<Ubugtu> Malone bug 65690 in gst-plugins-good0.10 "should select the esdsink for LTSP_CLIENTs" [Medium,In progress]  http://launchpad.net/bugs/65690
<fabbione> seb128: i was triple reviewing the patch you did to fix xorg-server and i found 2 problems
<Kamion> infinity: are you taking care of the xorg NBS binaries, or shall I?
<seb128> fabbione: feel free to fix them
<fabbione> seb128: first the patch 18_.. patches debian/* :)
<tfheen> ogra: oh, coolie.
<seb128> fabbione: right, is that an issue? 
<fabbione> seb128: i need to understand first why you did it in a certain way
<ogra> tfheen, there is a edubuntu-artwork coming down the drain for #57588 as well
<tfheen> ogra: want me to review the diff?
<fabbione> seb128: well it's not clean :)
<Kamion> +++ /tmp/qnj9PUiNKg/ltsp-0.123/debian/ltsp-server.install       2006-10-16 09:30:37.000000000 +0100
<Kamion> +server/80_ltsp-sound /etc/X11/Xsession.d
<Kamion> +++ /tmp/qnj9PUiNKg/ltsp-0.123/server/80_ltsp-sound     2006-10-16 09:30:37.000000000 +0100
<ogra> tfheen, oh, wait a sec, i'll upload it
<Kamion> +test -z "$LTSP_CLIENT" || rm $HOME/.gstreamer-0.10/registry.*.xml
<fabbione> seb128: the other thing about disabling composite when you use -render
<Kamion> that's it
<seb128> fabbione: 17_ was from fedora, I though it would fix the crasher we have on build, but it doesn't
<ogra> right
<tfheen> Kamion: ok; ltsp is approved.
<ogra> only one line and one new file
<fabbione> seb128: the patch you did partially fix the issue
<fabbione> seb128: look here:
<infinity> Kamion: Did we come to a concensus of two about what to do with them?
<seb128> fabbione: the -render patch is from fedora
<fabbione> root@sunfire:~/libgtk2-perl-1.121# Xvfb -render 
<infinity> Kamion: Resurrecting xlibs-dev for one more cycle (ugh) seems sane, but should we just drop the other two?
<fabbione> root@sunfire:~/libgtk2-perl-1.121# echo $?
<fabbione> 0
<fabbione> seb128: yes i understand that
<fabbione> seb128: but the patch doesn't take into account opts order
<fabbione> you saw that with -render you disable Composite
<fabbione> but
<fabbione> root@sunfire:~/libgtk2-perl-1.121# Xvfb -render +extension Composite
<fabbione> Bus error
<fabbione> that's because the patch doesn't take into account that a user can specify +extensions after
<ogra> tfheen, http://people.ubuntu.com/~ogra/e-a.debdiff thats for the edubuntu-artwork upload
<infinity> I think thats an "enough rope" corner case we can live with for release.
<fabbione> infinity: for what xorg-server?
<seb128> fabbione: so let's drop that patch and keep the xvfb-run one?
<infinity> fabbione: The -render thing.
<fabbione> seb128, infinity: i did test a libgtk2-perl rebuild and it did work here with that stuff...
<seb128> fabbione: the xvfb-run change is what matters since packages usually use xvfb-run
<Kamion> infinity: same story, I'm afraid; there are a lot of dependencies on xbase-clients and xutils
<Kamion> at a casual scan, many if not most of them aren't |-ed
<Kamion> and in any case Debian has those metapackages, so we'd be carrying all the diffs
<infinity> Kamion: Ugh.  Alright, I'll have to resurrect them with the same deps they had in dapper, then.
<infinity> Kamion: Our xbase-clients and xutils aren't even close to in sync with Debian's packaging, hence the discrepancy.
<Kamion> infinity: perhaps same deps as currently in Debian
<fabbione> seb128, infinity: i am just trying to explain what i found.. i am ok for it that way... but other pkgs might FTBFS calling Xvfb +randomextensions
<fabbione> seb128, infinity: but again.. i am ok with it.. just that you are aware of it
<infinity> Kamion: xutils in Debian isn't a metapacakge.  They stuck all the xutils in one package.
<seb128> I only kept the xrender one because I started with that one and fedora is shipping it for some time so I think it was alright
<infinity> Kamion: Same story with xbase-clients.
<seb128> the xvfb-run is enough to fix the ftbfs issues wehave
<fabbione> seb128: ok.. if you are sure it's enough we can live with that and fix it properly in edgy+1 to make sure it doesn't random segfault
<tfheen> ogra: that looks good to me.
<seb128> fabbione: works for me
<ogra> :)
<fabbione> seb128: it does for me too for 2 reasons.. you touched it last and you get to merge it for edgy+1 :P
<seb128> ahah
* fabbione hugs seb128 
<pitti> ouch, amd64/alternate install has failed
<seb128> fabbione: but you are going to do a new upload to drop the -render patch now and take back the merge, aren't you? :p
<Kamion> infinity: oh
<infinity> Kamion: Oh indeed.
<Kamion> shows how much I checked
<Kamion> pitti: what broke?
<pitti> Kamion: too bad I didn't watch the installation; something failed during installing the u-desktop packages
<pitti> but /var/log/syslog isn't too helpful
<Kamion> pitti: errors from tasksel?
<fabbione> seb128: not at all.. i am sane :)
<Kamion> might be helpful to me if I can see it ... :)
<seb128> fabbione: ok ok, I'm going to get dholbach doing it then :p 
<siretart> heno: may I query you?
<fabbione> seb128: ahaah
<pitti> Kamion: ah, some xubuntu task isn't found (unsurprisingly); a moment, please
<heno> siretart: you may indeed
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/amd64-alternate-installfail.png
<heno> is that 'the new ping' ? :)
<neuralis> fabbione: do we support root on raid on sparc?
<fabbione> neuralis: yes.. you need separated /boot
<fabbione> that can be on raid too
<fabbione> you need to skip the first 1Mb of the disk
<pitti> Kamion: shall I file a bug about that?
<neuralis> fabbione: ah, yes, sector 0
<fabbione> neuralis: yes.. the installer doesn't allow you to make raid or lvm on sector 0
<neuralis> right
<pitti> Kamion: wow, publishing debug logs over a webserver in d-i absolutely rocks!
<siretart> sounds sweet.
<siretart> is this already documented somewhere?
<pitti> siretart: well, 'Save debug logs...' in d-i's main menu offers 'web'
<siretart> sweet!
<seb128> fabbione: in fact "Xvfb :99 -render +extension..." works fine
* neuralis adds todo to mention it in the server chapter, under 'bag of installer tricks'
<seb128> fabbione: your example is "+extension Composite", which is the case the patch explicitly turn off because it doesn't work
<seb128> fabbione: did you try with an extension != Composite?
<Riddell> tfheen: yes, I'll close 65665 and 65697
<Kamion> pitti: I fixed that in tasksel last night ...
<Kamion> pitti: does this image have tasksel and tasksel-data 2.50ubuntu7?
<pitti> Kamion: oh, darn, I just filed bug 66371
<Ubugtu> Malone bug 66371 in debian-installer "fails to install packages, derivative tasks not found" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66371
<fabbione> seb128: nope. of course i pushed it on the edge to verify the opt parsing code that does not guarantee that +extension is parsed before -render
<pitti> Kamion: I still have yesterday's iso, since I started with testing this morning when today's iso wasn't yet available
<pitti> Kamion: will update and test again, and close the bug if it's fixed
<neuralis> fabbione: so skip 1mb, then make raid volume for boot, and another for root?
<fabbione> neuralis: yes, that's what i usually do
<seb128> fabbione: my understanding is that the patch would only overrides the +extension Composite option
<fabbione> or use LVM on top of the second raid
<fabbione> root on LVM is supported
<seb128> fabbione: which means we only break a crasher case
<neuralis> fabbione: neat
<fabbione> seb128: yeps...
<seb128> fabbione: so we can let it that way for edgy
<seb128> just to be sure we agree :)
<fabbione> yeah as i said.. it works for me, but be aware that you might get bug reports :P
<seb128> ok ok :)
<fabbione> pitti: 
<fabbione> dh_strip -plibimlib2  
<fabbione> Error: Package: and Architecture: do not alternate in debian/control
<fabbione> make: *** [binary-strip-IMPL/libimlib2]  Error 1
<fabbione> ever seen an error like that?
<fabbione> and what could cause that?
<pitti> fabbione: no, not yet
<pitti> fabbione: it's a sanity check in pkg-create-dbgsym AFAIR
<fabbione> pitti: i got it in the super rebuild of death.. only a couple of times
<pitti> fabbione: please assign them to me, will look into them
<two-face> Hi
<Kamion> pitti: I'll just dup it now
<two-face> I'd like to point out that neither ubuntu nor kubuntu is able to boot on my system
<two-face> (beta)
<two-face> I already filed a bug against linux-source-2.6.17
<pitti> Kamion: thanks; sorry for the noise
<Kamion> np
<two-face> can I help or something?
<fabbione> pitti: i am cursios to undestand if you can reproduce it locally.. because i couldn't on x86
<fabbione> pitti: pkg was imlib2
<pitti> fabbione: /me test builds
<pitti> fabbione: oh, wait, dh_strip - that's pkgbinarymangler, not pkg-create-dbgsym
<fabbione> wanna-build -d edgy --list=needs-build
<fabbione> Total 0 package(s)
<fabbione> uhuh
<fabbione> almost there with the first round
<infinity> pitti: Err, you're confusing yourself. :)
<pitti> infinity: am I?
<infinity> pkgbinarymangler is called from dpkg-deb (or dh_builddeb)
<tfheen> Riddell: thanks.
<pitti> infinity: erm, yeah, of course you are right
<pitti> dh_screwyouall
<pitti> infinity: hmm, debian/control lokos sane, weird
<two-face> i'd like very much to test edgy beta, only if I can boot the live cd
<Kamion> two-face: #ubuntu-kernel might stand a better chance
<seb128> two-face: do you have a bug number to point?
<two-face> seb128: #61987
<Kamion> two-face: have you tried booting with irqpoll?
<Tonio_> hi
<Kamion> (as the message suggests)
<two-face> Kamion: I only tried without acpi
<two-face> Kamion: what syntax for this parameter?
<seb128> bug #61987
<Ubugtu> Malone bug 61987 in linux-source-2.6.17 "Kernel boot failure with Kubuntu knot3 on amd64+nforce4+sata2" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61987
<two-face> Kamion: I tried it yes
<Kamion> just 'irqpoll'
<two-face> Kamion: I recall Itried it
<Kamion> but I'm not a kernel guy; just suggesting the thing that jumped out at me
<two-face> Kamion: I'll try -kernel, thanks for pointing that out
<tfheen> Riddell: your speedcrunch upload FTBFS on all arches.
<doko_> tfheen: set from "fix committed" to "fix released"
<tfheen> doko_: thanks
<mvo> fabbione: the iptuils fix for the FTBFS was a bit of a pain. I assume you have a working ip6 setup? could you please test ping6 and traceroute6 with the patch here: http://people.ubuntu.com/~mvo/tmp/iputils_20020927-3ubuntu2.debdiff ?
<pitti> fabbione: yes, I can reproduce it; will fix
<fabbione> pitti: great
<fabbione> mvo: sure
<fabbione> mvo: nope.. it breaks
<fabbione> mvo: IPV6_HOPLIMIT: Protocol not available
<fabbione> something related to that breaks both ping6 and tracepath6
<mvo> fabbione: thanks, I will check 
<fabbione> mvo: no problem
<mvo> fabbione: strange, it builds apparently in my pbuilder (amd64). what arch was the failure?
<fabbione> oh it builds.. it doesn't work
<mvo> fabbione: aha, ok
<fabbione> sorry if i wasn't clear
<two-face> well, I re-checked with irqpoll, but it didn't change anything
<pitti> tfheen: net-tools ftbfs fix uploaded
<Kamion> tfheen: what do you think about the pnm2ppa side of bug 52814? inconsistency between desktop and alternate installs on whether printing works seems RC to me
<Ubugtu> Malone bug 52814 in pnm2ppa "HP DeskJet 7xxC, 820C or 1000C does not work out of the box" [Medium,Confirmed]  http://launchpad.net/bugs/52814
<doko_> pitti: pkgstriptranslations take 90min for openoffice.org, that are more than 20% of the whole build time ... :-(
<tfheen> Kamion: that fix seems sane enough; can you upload it?
<Kamion> tfheen: sure
<mvo> fabbione: I updated the diff, could you please give it another go?
<Kamion>   109734 | S- | net-tools            | 1.60-17ubuntu1       | 26 minutes
<Kamion>          | * net-tools/1.60-17ubuntu1 Component: main Section: net
<Kamion> tfheen: ^--
<tfheen> Kamion: approved
<Kamion> Riddell: can you close the various bugs for fixes you uploaded in the last few days, please?
<pitti> doko_: ugh; I guess some optimization is due for edgy+1
<thom> doko_: buildbot is uninstallable
<tfheen> ogra: https://launchpad.net/distros/ubuntu/+source/edubuntu-artwork/+bug/65693 ; what's up with this?
<Ubugtu> Malone bug 65693 in edubuntu-artwork "progressbar is distorted " [Medium,In progress]  
<tfheen> mvo: you have a couple of bugs which are RC, what's the status of those?
<fabbione> mvo: sure
<pitti> fabbione: imlib2> indeed, Package: libimlib2-dev has two Architecture: fields
<pitti> fabbione: did you see this more than just once?
<fabbione> pitti: only 2 IIRC
<pitti> fabbione: I can either fix pkg-create-dbgsym to always use the last one, or fix imlib2 to fix debian/control
<fabbione> pitti: is it actually allowed to have 2 Architecture: line in debian/control?
<pitti> fabbione: not sure TBH
<fabbione> i mean.. for the same binary package
<fabbione> i don't think it is, but well.. Kamion ? ^^
<pitti> fabbione: it's like that in Debian for 14 months
<pitti> fabbione: but I agree that it shouldn't be allowed
<fabbione> it might be allowed...
<tfheen> it's not legal.
<fabbione> if so we need to fix pkg-create-dbgsym
<ogra> tfheen, well, see Seveas comment ...
<ogra> tfheen, i'm waiting for the usplash fix
<pitti> fabbione: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356902
<Ubugtu> Debian bug 356902 in imlib2 "imlib2: Cleanup duplicate control fields" [Minor,Open]  
<pitti> fabbione: I think I'll just fix that in imlib2; tfheen, ok with that?
<tfheen> ogra: ok, that'll be uploaded RSN.
<fabbione> pitti: ok..
<fabbione> the other package was in universe IIRC so we don't really care
<ogra> tfheen, i'll cloes the bug if it fixes it, else i'll uplaod a different png for the progressbar
<ogra> *close
<fabbione> mvo: this patch looks good.. or at least it seems to work
<tfheen> ogra: can you just apt-get source usplash; bzr update ; debuild ; debi and test it?
<ogra> sure
<mvo> tfheen: RC bugs targeted for 6.10? or high-importance bugs assigned to me in general?
<tfheen> mvo: 6.10-targetted bugs
<tfheen> Bug #64294 , bug 65679 , bug 63823
<Ubugtu> Malone bug 64294 in language-selector "Synthetic emboldening settings in zh_{CN,HK,SG,TW}" [Medium,Confirmed]  http://launchpad.net/bugs/64294
<Ubugtu> Malone bug 65679 in update-manager "cdrom only dist-upgrade not working because of openoffice.org-l10n" [High,Fix committed]  http://launchpad.net/bugs/65679
<Ubugtu> Malone bug 63823 in update-manager "Edgy : Randomn crash on quit" [Medium,Needs info]  http://launchpad.net/bugs/63823
<fabbione> pitti:  i don't think i did open a bug for imlib2, but i guess tfheen won't kill me for that (i hope)
<pitti> fabbione: *nod* :)
<tfheen> mvo: oh, and 63680 too
<mvo> tfheen: the ftbfs of iputils should be fixed with the lastest debdiff that fabbione is currently testing, the cdrom upgrade issue is hopefully fixed with the latest alternate cd (I check this now) and the fontconfig thing will be done today
<pitti> tfheen: imlib2 FTBFS fix uploaded (trivial, just removes duplicate Architecture: field)
<Kamion> fabbione: I don't think it's specified - can't find it in policy, anyway
<tfheen> pitti: thanks.
<fabbione> Kamion: thanks a lot
<pitti> hmm, ubiquity doesn't like my already existing ppc bootstrap partition... /me files bug
<Kamion> dpkg probably just takes the last one
<Kamion> pitti: I need to know whether it's automatic or manual partitioning, and I need /var/log/syslog and /var/log/partman
<pitti> right, that's what I was going to attach
<pitti> Kamion: I also add an fdisk -l and blkid output
<Kamion> not necessary, but if you like
<Kamion> I can always ignore it ;)
<Kamion> /var/log/partman has all that stuff
<tfheen> Keybuk: what's up with https://launchpad.net/distros/ubuntu/+source/udev/+bug/64909 ? 
<Ubugtu> Malone bug 64909 in udev "Duplicate UUIDs after Edgy update" [High,Confirmed]  
<Keybuk> tfheen: how do you mean?
<tfheen> Keybuk: it's 6.10-targetted.
<tfheen> which means I'd have liked to have a fix for it yesterday or so. :-P
<Keybuk> yesterday was Sunday
<pitti> Kamion: FYI, filed as bug 66384; that never happened to me before, not sure whether it's just a cosmic rays issue or a general regression
<Ubugtu> Malone bug 66384 in partman "ppc/ubiquity manual partitioning does not find already existing bootstrap partition" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66384
<Kamion> please use ubiquity for new desktop CD installer bugs until further triaged
<Kamion> even if they're apparently in a particular component, they're often due to interaction in ubiquity
<Kamion> and in any case partman is an obsolete source package :)
<pitti> Kamion: oh, sorry; will reassign
<tfheen> Keybuk: your last comment on that bug was on Wednesday and afaik it's your only 6.10-targetted bug ATM?
<Keybuk> tfheen: still doesn't change the fact that yesterday was Sunday :)
<Kamion> pitti: already done
<tfheen> Keybuk: I would have liked to have it fixed yesterday, you could have fixed it on Friday. :-P
<Keybuk> tfheen: I had other targetted bugs on Friday
<tfheen> Keybuk: anyway, do you have a fix for it you can upload?
<Keybuk> I don't, no
<Keybuk> I'll start work on a fix today
<tfheen> thanks.
<Keybuk> as I commented on thursday, the difficult bit was going to be notifying users that their fstab couldn't be converted
<Kamion> pitti: oh, meh, I see
<Kamion> I'll have to think about that while running lunchtime errands
<Keybuk> but then I decided not to worry, we can do that in edgy+1 and fail the upgrade in the update-manager if they have "/dev/hd*" in there
<Kamion> (problem is that the bootstrap partition obviously isn't mounted, so isn't found by the mountpoint validation code)
<pitti> Kamion: hm, is that new code? I didn't notice that when testing the beta
<Kamion> yes
<Kamion>   * Read partition flags from gparted (>= 0.2.5-1.1ubuntu9). Display an
<Kamion>     error on the mountpoints page if running on powerpc and there is no HFS
<Kamion>     partition with the boot flag set. Treat HFS partitions with the boot
<Kamion>     flag set as NewWorld bootstrap partitions (closes: Malone #43768).
<Ubugtu> Malone bug 43768 in ubiquity "insufficient handling of HFS bootstrap partitions" [High,Fix released]  http://launchpad.net/bugs/43768
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Tue,  3 Oct 2006 17:04:38 +0100
<pitti> ah, so I just need to add the boot flag
<pitti> well, too late, I already started a new test install with 'use complete disk'; but there is going to be another test install anyway
<Kamion> pitti: no
<Kamion> the boot flag is set - the problem is simply that the validation code doesn't notice that there's an HFS partition there at all
<Kamion> anyway, I have to run
<Huahua> hello, seb128 
<seb128> hi Huahua
<Huahua> seb128: how about the  gtkmozembed in python-gnome2-extras 
<seb128> what about it?
<Huahua> hua@vgh:~$ apt-cache show python-gnome2-extras | egrep 'firefox|xul'hua@vgh:~$ ldd /usr/lib/python-support/python-gnome2-extras/python2.4/gtk-2.0/gtkmozembed.so |  egrep 'firefox|xul'
<Huahua>         libgtkembedmoz.so => /usr/lib/firefox/libgtkembedmoz.so (0xb7f71000)
<Huahua>         libxpcom.so => /usr/lib/firefox/libxpcom.so (0xb7f6e000)
<seb128> and...?
<Huahua> seb128: it seems the libgtkembedmoz.so depends firefox
<seb128> which is expected
<Huahua> seb128: in debian sid , it seems libgtkembedmoz.so use  xulrunner
<seb128> we don't use xulrunner
<seb128> Debian does use it indeed
<seb128> we decided to keep building GNOME apps with firefox since we have to support firefox anyway (it's the default browser on Ubuntu)
<seb128> and we don't want to support firefox and xulrunner, that would be an effort duplication
<Keybuk> tfheen: http://people.ubuntu.com/~scott/udev_093-0ubuntu18.debdiff -- ok to upload?
<seb128> and would mean having both on the CD which takes extra space
<Huahua> agree
<Huahua> seb128: but it seems the depends of python-gnome2-extras pcakage  has not  firefox or xulrunner in it
<tfheen> Keybuk: looks good; have you tested that it works?
<Keybuk> tfheen: yes
<janimo> heno: does the latest ubuntu CD have orca and onboard on it? The casper package still only has references to gnopernicus and gok
<tfheen> Keybuk: ok, approved.
<thom> Keybuk: you pinged the other day?
<Keybuk> thom: oh, yes, you use cryptsetup madness, right?
<janimo> tfheen: what I asked heno above
<janimo> tfheen: neither of bzr  or the debian package of casper mention onboard execpt in the changleog
<heno> janimo: really? last time I checked the Ubuntu live CD it booted Orca directly and I changed the casper scripts myself :)
<thom> i have an encrypted homedir, yes
<heno> Has it been reverted now?
<janimo> heno: I suppose it works am just wondering where the latest 30accessibiklity scriupt is kept :)
<heno> janimo: with the latest source :)
<tfheen> janimo: I guess those settings are just dead settings.
<heno> There was a bug in the onboard launch, but that too should be fixed now
<heno> janimo: onboard runs very nicely on Xubuntu, btw :)
<Keybuk> thom: could you try the openvt hack on the bug
<janimo> heno: lastest source of what? I have casper bzr trunk checked out and grep onboard has only one hit in the changelog
<thom> later yes
<janimo> heno: great! Now let's make it work out of the box :_)
<janimo> heno: does gnome-speech work as well in xubuntu?
<janimo> heno: orca at-spi and gnome-mag or on today's liveCD already, they only need to be hooked into casper
<seb128> Huahua: ah, what you try to say is that it lacks a Depends on firefox, correct, I'll fix that later, thank you
<heno> janimo: yep. let me know how I can help. I guess those should work if you have enough of the deps. Do you have gconf installed?
<janimo> heno: yes, gconf is installed and xfce4-session can look at the a11y settings in gconf
<janimo> heno: so starting onboard comes for free so to speak :)
<heno> ok, cool
<janimo> heno: I'll play with orca now to see how it can be installed
<heno> I'm affraid I've mostly tested Xubuntu on mixed systems in the past with lots of gnome stuff installed
<heno> speech has worked in applications like gedit though
<heno> (not sure about Abiword)
<jsgotangco> it doesn't ive tried it 2 days ago
<jsgotangco> hi heno ;)
<janimo> the only thing I am puzzled by now is where is orca/onboard mentioned on the CD, as the 30accessibility scripts do not seem to have it
<heno> jsgotangco: hi, thanks for testing :)
<sivang> morning
<janimo> hi sivang
<sivang> hi janimo 
<heno> janimo: you're right. just did an apr-get source myself here and it's not there :(
<janimo> tfheen: any idea ^ ?
<janimo> heno: it's not in bzr either FWIW
<tfheen> janimo: probably handled by gnome-settings-daemon or similar.
<janimo> it may be done bypassing casper directly to the CD somehow?
<heno> janimo: my patches are here https://launchpad.net/distros/ubuntu/+source/casper/+bug/58836
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Undecided,Fix released]  
<janimo> heno: yes, I followe that bug
<heno> and here: https://launchpad.net/distros/ubuntu/+source/casper/+bug/65861
<Ubugtu> Malone bug 65861 in casper "onboard fails to start with F5 boot" [Undecided,Fix released]  
<janimo> that too :)
<giftnudel> hi sivang ;)
<heno> tfheen and/or Kamion applied at least the first one
<heno> Both I and the Orca crowd have tested it :)
<sivang> hey giftnudel !
<sivang> giftnudel: approved you, saw the pm, thanks
<janimo> heno: that's good then. It may make it more complicated for xubuntu then, I thought that script had all the setup needed
<giftnudel> sivang: thanks
<heno> http://mail.gnome.org/archives/orca-list/2006-October/msg00021.html
<janimo> heno: if I corrected the script to have onboard instead of gok I do not know how it affects gnome
* sivang wonders if ubuntu-backup would be a more appropriate name for the team, though
<heno> janimo: well, I would not expect it to work the way it's set now on Ubuntu either
<heno> is the at-getable source so out of date?
<giftnudel> sivang: what ever you said there in /me, if it was for me, I can't see it because of a translation bug
<heno> I cannot imagine it's been reverted
<janimo> heno: the package is in sync with bzr AFAICT
<heno> janimo: if you look at my patch, that's all it does really
<janimo> heno: besides you tollef and colin did anyone else work on the ubnutu liveCD a11y support?
<sivang> giftnudel: not sure I follow, what did I say in /me ?
<janimo> I just started looking at it last week, and maybe the script was alreday being replaced by another solution?
<heno> janimo: not that I know
<tfheen> heno: the apt-gettable source is up-to-date, but I suspect parts of the script is no longer needed and you're both barking up the wrong tree.
<giftnudel> sivang: when you type /me does something, instead of "* sivang does something", I only see "* sivang"
<heno> tfheen: then we need enlightenment :)
<tfheen> heno: I guess gct -s -t bool /desktop/gnome/interface/accessibility true for instance does most of the work.
<janimo> could it be that since orca is in gnome now no extra settings are needed?
<tfheen> thats called twice in m2, for some reason, too.
<Huahua> seb128: yes, thank you. I'm sorry for my erroneous saying.
<seb128> Huahua: np
<jdub> yo seb128!
<seb128> hey jdub!
<heno> tfheen: I would be surprised if gct -s -t bool /.../accessibility true was all that was needed. The system needs to know the app name. Might work for Orca (being a gnome default) but not onboard
<tfheen> heno: then there's some other magic thingabob taking effect.
<heno> and even then, it's now set to [gnopernicus]  which should make it fail, surely
* heno goes to download some fresh CDs :)
<Keybuk> why does everybody think that the fact you can get a root shell on the console is a security flaw?
* _ion has no idea.
<Keybuk> I've had almost half a dozen bugs, or related bugs, over the last week or two
<pitti> heh, me too :/
<mvo> fabbione: did you had a chance to test the iputils fix?
<pitti> hm, an ubiquity installed ppc system does not boot for me; it complains about not finding /lib/modules/2.6.17-10-powerpc/modules.dep, although the file is on the root partition (it might still be in initramfs stage at that point, though); does that ring a bell for anyone?
<pitti> update-initramfs -u doesn't help either
<pitti> infinity, Keybuk: ^ any idea about how to track this down?
<tfheen> pitti: is it in the initramfs?
* pitti reboots into live system to find out
<Keybuk> pitti: there's a dup of that I just bounced over to initramfs-tools
<Keybuk> where update-initramfs failed because the directory didn't exist at all
<pitti> Keybuk: ah, nice that it's known already
<ogra> tfheen, the edubuntu-progress issue is fixed with the new usplash
<tfheen> ogra: ok, cool.  Please close the bug, then.
<ogra> tfheen, well, usplash isnt uploaded yet
<_ion> Yay, new usplash?
<tfheen> ogra: well, the bug isn't in edubuntu-artwork, it's in usplash.
<ogra> right
<tfheen> and I'm fighting with the new usplash to make it work correctly.  Since it's not yet doing that.
<ogra> well, it worked fine on two thin clients i tested it on
<tfheen> doko_: can you respond to my comment on https://launchpad.net/distros/ubuntu/+source/flex/+bug/65963 please?
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  
<tfheen> ogra: I'm switching amd64 to use bogl and vga16, but, well, that doesn't seem to work correctly.  I get "out of range" errors from my monitor.
<ogra> oh
<ogra> i'll be able to do some amd64 testing in the late afternoon if that helps
<mjg59> tfheen: Boot with break=top, modprobe vga16fb and see what happens?
<tfheen> mjg59: it loads the module just fine, but seems to give me out-of-range errors.
<tfheen> I can test in the initramfs, sure.
<mjg59> tfheen: That sounds like a kernel issue
<doko_> tfheen: wrong memory ;) checked the irc backlog. IMO there are two possible build failures which didn't trigger yet in main. fix both before release, or both after release in -updates
<tfheen> doko_: those should be fixed if we just add the cast, won't they?
<pitti> Keybuk, tfheen: indeed, the initramfs only has /l/m/2.6.17-10-powerpc64-smp/ (and lots of stuff in it)
<pitti> Keybuk: is that the same bug you spoke about?
<doko_> tfheen: no, not the amd64 build failure (requiring -fPIC compiled code in a separate library)
<tfheen> mjg59: "bogl_init failed: setting screen size: Cannot allocate memory"
<mjg59> tfheen: ?
<tfheen> mjg59: that's what I get in the initramfs
<mjg59> But does vga16fb load?
<tfheen> yes
<mjg59> Without "out of range" errors?
<tfheen> I didn't see any; let me check again
<Keybuk> pitti: that implies that update-initramfs is getting run at the wrong point?
<pitti> Keybuk: I have little knowledge about the process TBH; it's just confusing that the initramfs contains -powerpc64-smp modules, whereas I have the -powerpc kernel installed
<pitti> Keybuk: and, as I said, a manual update-initramfs from a live session (with chroot) doesn't help either
<tfheen> mjg59: no out of range errors (or other errors)
<mjg59> tfheen: Confused now.
<Keybuk> pitti: oh, a manual update doesn't help?  now that's interesting
<Keybuk> weird though
<Mirv> heh, went throug xserver-xorg-video-ati bugs, and managed to gather 13 duplicates for https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/28925
<Ubugtu> Malone bug 28925 in xserver-xorg-video-ati "X fails to start in dapper flight3 & 4 with ati X600, onward all the way through dapper 6.06 LTS" [High,Confirmed]  
<tfheen> mjg59: it seems like it fails to find the fb size and there are no themes for 640x480 or 640x400, so it blows up.
<Mirv> (xorg.conf ending in talking about how mach64 was not detected, etc.)
<Mirv> I mean .log
<mjg59> tfheen: If it knows to try 640x400, it's finding the fb sizze
<Keybuk> pitti: what's uname -r say?
<tfheen> mjg59: I told it explicitly now.
<tfheen> and then it just goes "no usable theme" instead of "meep?"
<ogra> there are still no themes for 640x480 in ubuntu ? 
<ogra> i added the code to edubuntu-ratwork, feel free to copy it over 
<Seveas> Mirv, \o/
<ogra> *artwork
<Seveas> ogra, usplash artwork development for ubuntu seems non-existant
<ogra> right
<pitti> Keybuk: 2.6.17-10-powerpc
<mjg59> ogra: "code"?
<ogra> mjg59, i added the definitions for 640x480 to the code and got a png from the edubuntu-artwork team for beta already
<mjg59> Oh, ok
<ogra> its in since then and seems to work fine
<mjg59> ogra: You'll need 640x400 for amd64
<ogra> meh
<Kamion> pitti: what does 'dpkg -l linux-image\*' say?
<Kamion> it's not impossible that ubiquity's "which kernel should I remove" logic has got confused
<pitti> Kamion: ah, both -powerpc and -powerpc64-smp are installed
<Kamion> it should've removed one of those
<pitti> Kamion: argh, sorry, that was in the live system
<Kamion> indeed, both are installed there
<Kamion> ubiquity should remove one of them after copying
<pitti> Kamion: the metapackage for -powerpc64-smp is uninstalled, but the actual kernel isn't
<Kamion> !
<pitti> Kamion: ah, and /boot/initrd.img symlink points to the ppc64 one
<Kamion> that's just odd ...
<Kamion> pitti: syslog should clarify the logic a bit
<Kamion> pitti: also, /proc/cpuinfo would be good
<pitti> Kamion: alright, will create a bug and attach logs
<fabbione> mvo: yes.. i wrote it before.. it works fine
<mvo> fabbione: thanks a lot for checking! I must have missed the earlier msg :/ I will upload now
<fabbione> mvo: no problem at all... 
<mdz> mjg59: did you have much luck with usplash or i810 over the weekend?
<mjg59> mdz: i810 is fixed
<mjg59> usplash isn't. Tollef is doing the fallback to vga16 for amd64
<mdz> mjg59: do we need new artwork?
<mjg59> mdz: Yes
<mjg59> But we're /still/ missing artwork anyway
<mdz> does fschoep know that?
<tfheen> not yet.
<mjg59> I'd assume he knows about the lack of 640x480, at least
<mjg59> Seveas was supposed to be dealing with him over that
<mvo> tfheen: the debdiff for the iputils upload is at http://people.ubuntu.com/~mvo/tmp/iputils_20020927-3ubuntu2.debdiff - unfortunately its not trivial, but the changes are as little as I was able to manage
<Seveas> fschoep knows about it
<tfheen> mvo: fabbione or somebody else has tested it on an ipv6 network too?
<fabbione> tfheen: i did
<Seveas> I've received images for an animate theme from him and sent him the theme, that's all I knwo
<mvo> tfheen: I tested it too (but only with ip6 lo)
<tfheen> Seveas: for both 640x480 and 640x400 or just the former?
<tfheen> mvo: ok, approved.
<Seveas> just the former
<mvo> tfheen: thanks
<Seveas> up to now I didn't know the 640x400 requirement either
<pitti> Kamion: done, bug 66406
<Ubugtu> Malone bug 66406 in ubiquity "ppc/ubiquity install boots wrong kernel" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66406
<Kamion> ta
<ogra> but thats 640x400@16 not @256, right ?
<mjg59> Yes
<Kamion> pitti: could I see 'dpkg -l linux\*' actually, if you still have that installation handy?
<pitti> Kamion: yes, I just need a minute to boot the live system; I'll attach it to the bug
<Kamion> Oct 16 11:34:01 ubuntu ubiquity: Removing linux-powerpc64-smp ...
<Kamion> Oct 16 11:34:02 ubuntu ubiquity: Removing linux-image-powerpc64-smp ...
<Kamion> weirdness
<pitti> well, that doesn't look wrong, does it? just incomplet (no removal of the actual kernels)
<Kamion> right, but why? the check-kernels script does this:
<Kamion> kernels="$(dpkg-query -f '${status} ${package}\n' -W linux-image-\* | \
<Kamion>                 grep '^install ok installed ' | cut -d' ' -f4 | xargs)"
<Kamion> so it should be looking at the actual kernel package just fine
<Kamion> pitti: in a little bit I was hoping to be able to ask you to test a ubiquity change for the HFS bootstrap partition business; maybe I could prevail upon you to get /var/lib/ubiquity/remove-kernels after the installation but before reboot, too
<Kamion> lunch
<pitti> sure
<tfheen> mjg59: so, it tries to set up a 1024x768 screen size, which, well, falls on its face.
<mjg59> tfheen: Uh. It shouldn't be trying to do that.
<mjg59> Kamion: Wasn't that bit your code?
<pitti> Kamion: info added
<mvo> tfheen: could you please review http://librarian.launchpad.net/4860571/casper_1.76.debdiff ? it fixes not-optimal fonts on the live-cd
<tfheen> mvo: why does the language-selector need to be reconfigured for that?
<mjg59> Seveas: Realistically, we need artwork with a black background
<tfheen> or rather, call fontconfig-voodoo
<mvo> tfheen: we have a thing called "fontconfig-voodoo" that includes fontconfig fragments based on the current locale. it works around the problem that we were not able to come up with a fontconfig config that works well on all CJK languages
<tfheen> mvo: hmm, ok.  Please check it into bzr and upload, then.
<mvo> tfheen: without this call e.g. chinese users get the default fontconfig and that does not look as good as the optimized version 
<Seveas> mjg59, please tell the artwork team (specifically fschoep) -- they are quite unresponsive lately
<mvo> tfheen: ok, thanks
<mjg59> Seveas: I'm afraid I have absolutely no time right now
<Seveas> likewise, I am arranging travel things for uds-mtv
<mdz> mvo: that patch doesn't seem to do what the changelog says
<mjg59> Seveas: I'm dealing with the fact that I've got 2 months to finish a PhD :)
<Seveas> bit more stressing ;)
<Seveas> I'lll poke the artwork list then later today
<mjg59> Thanks
<mdz> Seveas: I've mailed fschoep twice today and he's responded within minutes both times
<mdz> the most recent one confirmed a black background for the usplash artwork
<ogra> tfheen, any objections against http://people.ubuntu.com/~ogra/x-s-s.debdiff (adding a dependency to the universe parts)
<Seveas> mdz, hrm... on IRC I got no response at all several times :/
<mdz> mvo: it doesn't reconfigure language-selector, it runs fontconfig-voodoo
<mdz> Seveas: perhaps because he isn't connected to IRC at the moment? ;-)
<mvo> mdz: right, my wording was badly choosen, sorry for this
<Seveas> mdz, even when he was connected to irc ;)
<tfheen> ogra: 61775 isn't 6.10-targetted (and imo shouldn't be) so, no, not approved.
<ogra> hmm, k
<tfheen> ogra: in addition, I think it should be a suggests or recommends, not a depends.
<mvo> tfheen: the fix for #64294 is at http://librarian.launchpad.net/4860573/language-selector_0.1.29.debdiff (just uploaded new language-selector)
<ogra> tfheen, its universe ....
<tfheen> ogra: the source is main.
<tfheen> mvo: go ahead.
<ogra> right, thats why i asked for approval, but the main part isnt touched
<mvo> tfheen: thanks
<mvo> mdz: I updated the fix (http://librarian.launchpad.net/4860579/casper_1.76.diff) - better now?
<mvo> mdz: ignore my last msg, I need to update the changelog again to make clear what comes from me and what from kamion
<heno> tfheen: so, Orca works on today's Live CD using the old gconf settings :) It turns out gnome has some backwards-compatibility-magic that translates gnopernicus->orca in the AT-autostart system. onBoard does not work (as it is not a new gnome default)
<mvo> mdz: http://librarian.launchpad.net/4860598/casper_1.76.diff is it 
<heno> janimo: ^
<mdz> mvo: looks ok to me
<tfheen> mvo: if you want to be really pedantic, add a blank line between Colin's and your changes.
<elmo> I can't believe we have a progam called fontconfig-voodoo
<thom> it somes up most peoples feelings about linux and fonts, no?
<sivang> heh
<mvo> tfheen: thanks, I will do that
<mjg59> It's so the wrong solution, but it's also the only one that works
<tfheen> elmo: I think it's entirely appropriate.
<mvo> elmo: and its *so* needed
<mjg59> I was going to say "Unless you're happy with your fonts looking like arse", but elmo probably still uses xterm...
<thom> there's nothing wrong with using a proper terminal emulator ;-)
<elmo> mjg59: no, I use gnome-terminal like a good ubuntu user :-P
<mjg59> Ah, right. Well, hurrah for fontconfig-voodoo, or your fonts would look like arse.
<Kamion> mjg59: all characters rendered as (_)(_) ?
<Kamion> (sorry)
<jdub> ( ! ) <- more arse :)
<tfheen> pitti:  Bug #54277; marked as fix committed, should this be fix released?
<Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Confirmed]  http://launchpad.net/bugs/54277
<pitti> tfheen: fix committed is for dapper (-proposed upload was made, but not yet an upload for -updates)
<pitti> tfheen: however, there were some more issues about it, that's why the Ubuntu task was reopened
<tfheen> pitti: oh, sorry, but it's marked as confirmed for edgy though?
* pitti removes the milestone
<tfheen> pitti: ok, thanks.
<jdong> grr... it should be easer to mark backports as bugged...
<Kamion> pitti: ah, I think I might see
<Kamion> pitti: have a look at /usr/share/ubiquity/install.py:do_remove() and note the reuse of the variable 'pkg' in two nested for loops
<Kamion> well, in fact multiple for loops nested within an outer one
<Kamion> then in the outer loop I do:
<Kamion> removed.add(pkg)
<Kamion> not entirely sure if that would cause this bug, but it certainly seems likely to cause confusiong
<Kamion> -g
<pitti> Kamion: ah, indeed, I see it
<pitti> Kamion: I can try another install and rename the variable before starting ubiquity
<Kamion> elmo: did you guys get the mail from a user about popcon@ubuntu.com being broken?
<Kamion> pitti: maybe wait until I get the bootstrap partition fix done and you can try both in one shot?
<pitti> Kamion: sure
<Kamion> unless you have too much time today :-)
<pitti> lol
<pitti> Kamion: well, I do want to dedicate the better part of the day for testing
<elmo> Kamion: don't think so - know where was it sent?
<pitti> previously, I usually started testing only when we had the first real RC images, but that's too late to fix many bugs
<Kamion> elmo: info@u.c and postmaster@u.c among other randomly selected addresses :)
<Kamion> elmo: apparently our popularity-contest packages tries to submit by HTTP but then falls back to mail if that fails
<Kamion> not sure whether that's a bug or not (I haven't investigated)
<tfheen> it's by design; one can argue that it should just fail then, though.
<elmo> do you guys want it to work?
<elmo> the email I mean
<Kamion> pitti: well, it's the last revision in http://people.ubuntu.com/~cjwatson/bzr/ubiquity/ubuntu/ if you want to try it out
<Kamion> pitti: might not do any harm to stick some logging into the loop there to try to find out exactly what it's doing
<tfheen> elmo: it'd be useful, I guess.  It should be routed to some of the scripts on popcon.u.c, though.
<tfheen> elmo: (which is humboldt, immsc)
<elmo> tfheen: does the mail handling side exist on your end?
<pitti> Kamion: 'try it out' -> does that already have a fix for the bootstrap partition?
<tfheen> elmo: I don't think I've broken the stuff from Debian, so yes, I presume so.
<Kamion> pitti: not yet, I'm still thinking about that
<theine> Hi, are there any MPI in Edgy main?
<elmo> tfheen: can you email RT with details of where exactly you want the email to go?
<theine> ...packages...
<pitti> Kamion: ok, will do both in one shot then
<Kamion> theine: not in main, but the usual set imported from Debian should be in universe
<tfheen> elmo: yes, I'll do so.
<elmo> tfheen: thanks
<theine> Kamion: OK, I thought that Ubuntu actually tries to target Beowulf clusters
<seb128> current desktop amd64 CD looks pretty good
<pitti> alternate amd64 works pretty fine here, too
* pitti ^5s seb128
* seb128 hugs pitti
<janimo> heno: thanks. So that script needs you rpatch after all? And it would be cleaner to explicitely state orca and not rely on gnome backwards compat code, if not else to avoid confusing those who read the script :)
<tfheen> mdz: the hard deadline on artwork might be friday, but not having 640x400 and 640x480 artwork is blocking two RC bugs.
<heno> janimo: agreed :)
<mvo> Kamion: could you please have a look at http://librarian.launchpad.net/4860736/ubiquity-fontconfig-foodoo.diff ? we will need this for optimal font configuration (note that it may return a non-zero exit code, we need --force if that is a issue)
<mdz> tfheen: fschoep was replying to both your message (about the bugs) and my earlier message (about the latest joke of an artwork deadline) at the same time, which caused some confusion
<Kamion> theine: I'm not ruling it out obviously, but it's not something I recall coming up as an explicit target
<mdz> tfheen: can we not drop in the dapper artwork for the sake of the bugs?
<Kamion> mvo: a new progress template would break the string freeze; might be best to incorporate the fontconfig-voodoo call into configure_hardware
<mvo> Kamion: thanks, I will do that
<tfheen> mdz: we could, I guess.  I need to find out how that fits together, though.  And I wonder why not even the refcard works correctly.
<Kamion> mvo: non-zero exit codes become a syslog error and 'return False' from chrex(), not an exception, so that's O
<Kamion> OK
<Kamion> tfheen: I don't think usplash falls back to the testcard from themes
<Kamion> unless the theme explicitly chains to it (somehow, if that's even possible)
<janimo> heno: what about the gnopernicus gconf keys /apps/gnopernicus/srcore/sp_active  and mag_active? Do you know if those are translated to orca configs as well and thus needed in the script? 
<mdz> doko_: what's the latest on the python issues?  how can we help?
<mdz> BenC_: ping, re: xuf 65828
<heno> janimo: orca doesn't use gconf so those no longer work actually :(
<heno> janimo: I've asked upstream for advice but no clever plan has emerged yet
<mvo> Kamion: does http://librarian.launchpad.net/4860746/ubiquity-fontconfig-foodoo.diff look better?
<heno> I think that whole autostart feature needs some restructuring to allow for different access tools, with or without AT-SPI, etc
<Kamion> mvo: yup, except that I think it *does* belong there
<Kamion> configure_hardware is for everything that needs to be done to adapt the installed system to the current hardware
<janimo> heno: it does use some config files though? What is missing if those keys are not set properly?
<Kamion> mvo: I'll incorporate that, thanks
<mvo> Kamion: oh - feel free to correct the comment then :) 
<jdub> http://software.seekingalpha.com/article/18470
<heno> janimo: it has python config files. It starts with a screen reader by default, so the magnifier version fails to start on Live CD boot (starts in screen reader mode as well)
<janimo> heno: would just creating a properly inited config file in the users' home dir not work for som ereason?
<Kamion> mvo: actually, I see it's for language detection, so I'll put it in configure_locales
<janimo> for xubuntu as it does not use gconf I just echo and sed in existing config files
<mvo> Kamion: one more thing (just to double-check) - we still write /etc/environment, right? even though it will eventually become /etc/defaults/locale?
<Keybuk> iwj: today's annoying firefox bug ... if you fullscreen a window, subsequent firefox windows are opened sized to fill the entire screen (but not maximised)
<Kamion> mvo: yes
<Kamion> mvo: does this need to be done for d-i installs too?
<heno> janimo: that should work. Orca uses systemwide defaults unless there are files in the user's directory
<mvo> Kamion: the fontconfig-voodoo call? no, it is run in the postinst of language-selector-common then
<Kamion> ok
<heno> I guess those files are not copied onto the installed system (a new account is created)
<mvo> if noone has pending capser changes I would like to upload it soonish
<doko_> mdz: I need a way to reproduce it; all update tests which mvo and I did don't show the failure anymore. I'll provide a test build with debug output enabled on p.u.c and ask for the log
<janimo> heno: for xubuntu I modify system wide config files, I wonder if that has some drawbacks. As I see it if a user does not want a11y it can override with user prefs just like it was the other way around
<heno> janimo: I guess for the live session you could echo to the files in /usr, but then they would end up as installed defaults too
<heno> janimo: it seems ok, yes
<Kamion> mvo: have you tested this, BTW? I'm wondering if LANGUAGE will actually be set in the environment
<Kamion> since just doing 'chroot /target' doesn't start PAM
<mdz> doko_: it's reproducible by the submitter?
<mvo> Kamion: it will read /etc/environemnt directly
<Kamion> oh, yes, just noticed that
<doko_> mdz: yes, apparently.
<mvo> Kamion: I will still need one additional upload because of the change that ENVIRONEMNT is not always set anymore (only LANG)
<janimo> I'll test orca+xubuntu live CD in about an hour and let you know how it goes
<Kamion> mvo: you mean LANGUAGE?
<mvo> Kamion: yes, sorry
<Kamion> mvo: applied my modified version of your change, thanks
<mvo> Kamion: thank you!
<Kamion> pitti: so, how do you feel about testing TOTALLY UNTESTED CODE?
<pitti> Kamion: sounds TOTALLY ADVENTUROUS!
<pitti> Kamion: IOW, if you could put the modified files somewhere, I can put them into the live system and run a test install
<Kamion> pitti: http://people.ubuntu.com/~cjwatson/bzr/ubiquity/ubuntu/ - it's quickest to make sure you have ubiquity* version 1.2.2 and then apply the patches from revision 1665 to 1668 to files under /usr/share/ubiquity and /usr/lib/ubiquity/ubiquity directly
<pitti> Kamion: sounds good
<Kamion> pitti: or http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff
<pitti> ^ that saves me the bzr mangling, thanks
<sivang> morning dholbach_ 
<dholbach> hi sivang
<mdz> fabbione,infinity: is the rebuild test complete?
<fabbione> mdz: almost.. missing about 20/30 pkgs for sparc and ready to fire up a rebuild of main only
<mdz> fabbione: so the two targeted FTBFS bugs are the only failures?
<fabbione> mdz: the only 2 lefts AFAIK
<fabbione> mdz: but there have been uploads.. so another rebuild will NOT hurt anybody
<fabbione> and i can do main only quite fast on sparc
* pitti  fabbione for the rebuild tests :)
<Kamion> mvo: can you hold off on casper for a minute? I have a suspicion I'm investigating
<mvo> Kamion: sure
<fabbione> pitti: do you want to get the emails from the buildd too?
<pitti> fabbione: yes, if you have some interesting ones which are likely my fault, feel free to bounce the log, and I'll care for bug triage/fixing
<fabbione> pitti: it's either ALL or none and wait for me to file bugs :)
<PSUSI> anyone know what to do when someone starts spamming bugs on launchpad?  can it be cleaned up and the offending email unsubscribed?
<pitti> fabbione: ah :) well, second option prefered, of course, otherwise it's just double work
<fabbione> pitti: ehehe ok
<pitti> Kamion: existing bootstrap has been detected, and now I get a ValueError in mountpoints_to_summary, line 1155, gtkui.py (too many values to unpack)
<Kamion> whee
<fabbione> hmmm blue-tooth something /etc/init.d/$something just promped for question on upgrade..
<fabbione> Setting up bluez-utils (3.7-1ubuntu3) ...
<fabbione> Configuration file `/etc/init.d/bluetooth'
<fabbione>  ==> Modified (by you or by a script) since installation.
<fabbione> pitti: ^^ are you the one in charge of bluetooth?
<elmo> fabbione: I reported that as a bug last week, FWIW
<fabbione> elmo: ok thanks
<Kamion> oh, er, yeah, oops
<pitti> fabbione: not really; /me points to dholbach and tfheen
<sivang> fabbione: I think that's dholbach 
<Kamion> -            for device, mountpoint in self.auto_mountpoints:
<Kamion> +            for device, mountpoint in self.auto_mountpoints.iteritems():
<Kamion> pitti: that on line 1155 please
<fabbione> pitti: roger
<elmo> LP #65517
<pitti> Kamion: yup, just did that
<fabbione> dholbach: PIIIIIING
<fabbione> bug #65517
<Ubugtu> Malone bug 65517 in bluez-utils "init.d/bluetooth config file prompts on upgrade" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65517
<fabbione> elmo: thanks dude
<dholbach> fabbione: PONG! PING tfheen instead.
<dholbach> sivang: this time it's not :)
<fabbione> ok
<sivang> dholbach: heh
<fabbione> tfheen: contents less ping :)
<dholbach> fabbione: good you adjusted the volume now :-)
<fabbione> dholbach: i can't shut my voice down too much :)
<pitti> Kamion: package installation running now
<Kamion> mvo: ok, committed my change to casper now; releasing lock
<mvo> Kamion: feel free to upload, I'm done with my changes
<janimo> Kamion: where should apt-install be? I run it from casper script but has no effect?
<dholbach> Riddell: libqt4-dev needs a Depends on libmysqlclient15-dev, libsqlite0-dev and libglib2.0-dev
<dholbach> Riddell: to fix bug 66212
<Ubugtu> Malone bug 66212 in wpasupplicant "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/66212
<mdz> dholbach: is that a regression in the new qt?
<pitti> dholbach, Riddell: I saw a bug attachment today doing these changes to wpasupplicant
<janimo> Kamion: 30accessability also needs heno's patch from bug 58836 http://librarian.launchpad.net/4777068/30accessibility.patch
<dholbach> mdz: I can't tell, bug comparing the build-deps and the deps of the library package, you will note that those 3 are missing
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Undecided,Fix released]  http://launchpad.net/bugs/58836
<janimo> Kamion: otherwise onboard does not start according to him on todays ubuntu CD
<dholbach> Riddell, mdz: ok to do the qt4-x11 upload?
<Kamion> janimo: apt-install should be run from a script in ubiquity-hooks/, *not* from a casper script
<mdz> dholbach: yes
<dholbach> mdz: gracias
<janimo> Kamion: ah.
<Kamion> janimo: I'd like tfheen's ack before applying that patch
<elmo> mvo: is unattended-upgrades activated by default in edgy?
<heno> Kamion: if not the who patch then at least one that changes gok to [onboard] 
<elmo> mvo: also the amount of documentation is, err, impressive :-P
<heno> (it needs brackets too)
<janimo> heno: the whole pacth help for xubutu which does not have backwards compat stuff to turn gnopernicus into orca
<janimo> and it is not confusing ;)
<heno> janimo: good point
<Kamion> heno: has this patch actually been tested now?
<janimo> Kamion: I have tested it with xubuntu FWIW
<heno> Kamion: I've tested the gconf settings individually, but don't know how to test it in casper
<janimo> Kamion: it uses the same gconf a11y keys as gnome
<Kamion> I usually do something like boot without quiet splash and add break=casper-bottom to the kernel command line, then 'ed /scripts/casper-bottom/30accessibility', then 'exit' when I'm done
<janimo> heno: I test using a usb stick and modify the initrd but it is not too straightforward
<Kamion> probably helps to be able-bodied while driving ed though
<heno> Kamion: that's why I have a sticky-keys-in-kernel spec :)
<heno> for stuff like that
<doko_> Kamion, tfheen: please approve http://people.ubuntu.com/~doko/edgy/elementtree.debdiff , restoring dependencies (built with an too old python-support), bug 66424
<Ubugtu> Malone bug 66424 in elementtree "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66424
<doko_>  Kamion, tfheen: please approve http://people.ubuntu.com/~doko/edgy/buildbot.debdiff, removing the python2.3 dependency
<Kamion> heno: I've applied that to casper, but I want to wait to upload until tfheen is back to cross-check
<heno> Kamion: cool. 
<Kamion> doko_: -> just tfheen unless it's his night-time and I'm still around, please
<janimo> Kamion: if the optional gnome packages are only installed by ubiquity hooks it means that when the liveCD is booted up they are not installed and usable right?
<Kamion> doko_: and -> dholbach or ajmitch (IIRC) for universe packages
<mvo> elmo: no, its not active by default
<Kamion> janimo: no, the point is that you put them into the ship-live seed and then apt-install means "keep this installed on the final system"
<elmo> mvo: ok
<Kamion> janimo: er, s/ship-live/live/
<janimo> Kamion: ah live? last time you said ship live so I just happily ship them :)
<Kamion> janimo: apt-install in ubiquity isn't actually supposed to physically install packages, normally
<elmo> mvo: I don't think the code as is will work tho, it checks for an Origin of 'Edgy Security', but the Origin is always 'Ubuntu'
<janimo> ok, so actually get them installed. make sense
<Kamion> janimo: the name is for compatibility with d-i code
<Kamion> janimo: sorry, I might have said ship-live, I meant live
<mvo> elmo: has this changed from dapper? 
<elmo> nope
<mvo> hm
* mvo investigates
<elmo> I think what you actually want to look at is the 'suite', but that info isn't exposed by python's apt module
<janimo> Kamion: if I modify the live seed now do I still need a xubuntu-meta update now that live is a task (whatever that implies)
<elmo> mvo: if it's not targetted at edgy, it may not be important right now, it's just something I noticed while looking at the code yesterday
<Kamion> janimo: no, I checked, I did say "live" :-)
<Kamion> janimo: no, you don't, that's the point of making it a task
<elmo> mvo: AFAICS python-apt doesn't expose the 'suite' information for candidateOrigin which is what you really want to check
<dholbach> doko_: buildbot is good to go
<mvo> elmo: is it possible that there is just naming confusion here? between what apt calls a suite and what dak calls it? the code works with dapper
<janimo> Kamion: you're rigth you said put it in the live seed. I misunderstood sorry.
<Kamion> pitti: how did it go?
<mvo> tfheen: permission to upload http://people.ubuntu.com/~mvo/tmp/gnome-app-install_0.2.21.debdiff ? it re-adds a vanished intltool-update -p to make rosetta happy again
<elmo> component: 'main' archive: 'edgy' origin: 'Ubuntu' label: 'Ubuntu' site 'uk.archive.ubuntu.com' isTrusted: 'True'
<Kamion> ... uk.archive?
<Kamion> was that done automatically by something?
<elmo> mvo: that's from 'print apt.Cache()["dpkg"] .candidateOrigin[0] '
<doko_> dholbach: please approve http://people.ubuntu.com/~doko/edgy/python-dhs.debdiff
<elmo> Kamion: no, probably me by hand
<Kamion> lucky the Ukraine has ua, really :)
<dholbach> doko_: it gives a 404
<dholbach> doko_: ah -dhm... is ok
<dholbach> Tonio_: thanks for fixing kdebluetooth
<Tonio_> dholbach: you're welcome :)
<mvo> elmo: it checks "if origin.origin == allowed[0]  and origin.archive == allowed[1] : return True"
<mvo> elmo: Allowed-Origins is a mileading name in the config, it really means a pair of (origin, archive) 
<elmo> Unattended-Upgrade::Allowed-Origins { "Ubuntu edgy-security";
<elmo> mvo: so is 'archive' going to be 'edgy-security' ?
<mvo> elmo: yes
<elmo> mvo: someone needs shot in the head for that naming scheme
<elmo> I mean SERIOUSLY
<doko_> tfheen: please approve https://launchpad.net/distros/ubuntu/+source/python-goopy/+bug/66425
<Ubugtu> Malone bug 66425 in python-goopy "sync request" [Undecided,Unconfirmed]  
<mvo> elmo: I guess that would be me then ? 
<mvo> elmo: unless you mean the "archive" name, that is historic apt heritage
<elmo> mvo: yes I mean the "archive" name, it's not an archive.  it's a suite (dak), distribution (old Debian), or distroReleasePocket (launchpad)
<mvo> elmo: I will fix that by adding a new name "suite" and mark the old one (archive) obsolete
<elmo> mvo: sweet, that'd be great
<elmo> mvo: FWIW, 'suite' is a culus-ism, so it even has apt history attached to it ;-)
<mvo> elmo: anything else you noticed while reviewing the code?
<doko_> dholbach: please approve rebuild if python-irclib to restore dependencies
<elmo> mvo: nothing substantial, but I wasn't reviewing it, just using it to get an idea of the python-apt 'apt' API, and steal ideas from ;-)
<dholbach> doko_: ok
<mvo> elmo: heh :) ideas for what project if I may ask?
<tfheen> mvo: g-a-i: approved.
<mvo> tfheen: hanks
<tfheen> doko_: python-goopy is universe => dholbach 
<elmo> mvo: just updating the script we use to check for out-of-date packages on our machines.  atm, it groks around in /var/lib/dpkg/status and stuff byhand, which works but is pretty messy
<dholbach> tfheen, doko_: goopy is fine too
<sivang> elmo: that is to check for packages that have newer versions or those that are obsolete now?
<elmo> sivang: former
<sivang> elmo: ah
<doko_> dholbach: please approve rebuild if python-kinterbasdb to restore dependencies
<dholbach> doko_: I'm perfectly happy with rebuilds that make the python world happy again. I'm not sure we have to go through this every time.     mdz, tfheen, Kamion: I hope you can agree with me.
<sivang> dholbach: same for unmetdeps, I would say
<sivang> dholbach: (given the change is failry documented in the changlog)
<sivang> dholbach: (for universe, that is)
<doko_> tfheen: please approve python-pylibacl, python-pylibacl rebuilds to restore the dependencies
<doko_> dholbach: please approve python-xlib, python-yappy to restore the dependencies
<dholbach> doko_: I'm happy with them
<tfheen> doko_: just a no-change upload?  Go ahead; It seems to be missing its Depends line, yes.
<ondrej> hi, there is lag in payment of ubuntu.cz domain, who may I ask to pay for it?
<tfheen> ondrej: I've forwarded your question, wait a sec.
<pitti> Kamion: crap; -powerpc64-smp is still installed with the fixed ubiquity
<Kamion> pitti: ok, did you get /var/lib/ubiquity/remove-kernels before rebooting?
<pitti> Kamion: I didn't reboot yet
<pitti> Kamion: it shows 'linux-image-2.6.17-10-powerpc64-smp' and 'linux-image-powerpc64-smp', that looks good
<Kamion> StevenK: FYI your packagesearch upload has a spurious debian/changelog~ in the diff; no need to reupload pre-edgy though
<Amaranth> Someone was using gedit. :P
<Kamion> sivang: debtags-edit should be build1, not ubuntu1
<Kamion> sivang: please reupload that - it'll avoid merge pain later
<Kamion> (rejectd)
<Kamion> e
<ondrej> tfheen: unfortunately, I have to go, I'll be back tomorrow (or maybe this evening)...  I'll ask again (fortunattely I am working for CZ.NIC - .cz domain registry :-)
<Kamion> tfheen: unapproved: gnome-app-install_0.2.21 qt4-x11_4.2.0-1ubuntu3 kubuntu-default-settings_1:6.10-59 language-selector_0.1.29 iputils_3:20020927-3ubuntu2 xfdesktop4_4.3.99.1svn+r23428-0 imlib2_1.2.1-2ubuntu1
<Kamion> er, sorry, some of those versions are truncated, silly queue output format
<sivang> Kamion: k, thanks
<Riddell> qt4 was dholbach, got a debdiff for me daniel?
<Kamion> gnome-app-install/0.2.21 qt4-x11/4.2.0-1ubuntu3 kubuntu-default-settings/1:6.10-59 language-selector/0.1.29 iputils/3:20020927-3ubuntu2 xfdesktop4/4.3.99.1svn+r23428-0ubuntu1 imlib2/1.2.1-2ubuntu1
<Kamion> that's better
<tfheen> Kamion: iptutils and language-selector is mvo?
<Kamion> Amaranth: emacs does that too IIRC
<tfheen> Kamion: g-a-i is approved.
<Kamion> tfheen: yes
<tfheen> Kamion: iptutils, language-selector are approved, then.
<tfheen> who uploaded xfdesktop4?
<tfheen> I haven't seen a diff for imlib2, I think.
<dholbach> Riddell: I merely added libmysqlclient15-dev, libsqlite0-dev and libglib2.0-dev to the depends of libqt4-dev (bug 66212)
<Ubugtu> Malone bug 66212 in qt4-x11 "FTBFS in edgy" [High,Fix committed]  http://launchpad.net/bugs/66212
<Kamion> tfheen: janimo
<Kamion> +  * Upstream svn snapshot: fix many crashes, fix xinerama mode, fix trash notification
<pitti> tfheen: that's my FTBFS fix? as I said, I just removed the duplicate Architecture: line
<Kamion> +  * debian/rules: sed over the menu config files and remove some application
<Kamion> +    shortcuts.
<Kamion> pitti: and you added debian/compat 5
<tfheen> Kamion: xfdesktop4 is approved then.
<pitti> Kamion: cdbs automatically does that
<pitti> Kamion: it did during build in the previous version, too
<pitti> Kamion: is there anything I can get out of the ppc install? (I'm still in the live system, since booting won't work anyway)
<pitti> I already added a bug comment
<Kamion> tfheen: could you have a look over the recent changes to casper trunk?
<Kamion> pitti: did it fix the HFS bootstrap thing?
<pygi> sivang: hello, you here?
<pitti> Kamion: yes, it did
<Kamion> ok, that's something at least. hold on and I'll try to come up with something further to do
<sivang> pygi: aien't I always? :)
<Kamion> pitti: I don't suppose it's possible for me to get ssh access to the live system?
<pygi> sivang: I won't comment :P
<Riddell> dholbach: I need the debdiff for sending to debian, but actually it needs to include the previous change I made so I'll take care of it, thanks
<Kamion> I wouldn't mind trying some things out in a python shell
<pitti> Kamion: I'm behind a NAT, but I can try to dig an ssh tunnel to a public machine, hold on
* pitti tries to remember the syntax
<tfheen> pitti: ssh -R 1234:localhost:22 -g somemachine ?
<tfheen> and then Colin will use ssh -p 1234 somemachine to get to your machine.
<dholbach> Riddell: no problem hang on - can i have the debdiff of telepathy-qt, so I can put it in bzr? ;-)
<pitti> right, thanks
<sivang> pygi: what's up?
<tfheen> pitti: at least, I think that's the syntax.
<dholbach> Riddell: http://daniel.holba.ch/temp/qt4-x11.debdiff
<slomo> hm, i thought we didn't want libsqlite0 in main anymore ages ago
<Kamion> well, it's still in main ...
<Kamion> and sqlite3 is in universe
<Kamion> I assume it has nonintuitive version numbering or somethingg
<Kamion> oh, no, sqlite3 source and the library are in main too, just not the sqlite3 binary
<slomo> sqlite3 is the new one and sqlite0 only gets a few bugfixes upstream afaik
<slomo> oh, any reason for that?
<Kamion> dunno
<Kamion> the sqlite binary isn't in main either
<pitti> tfheen: that only listens to 'localhost' on somemachine
<Kamion> I assume just nothing needed it
<Riddell> the advantage of sqlite is it's a library and not a separate proccess
<pitti> tfheen: ah, found the option
<Kamion> pitti: actually it forwards port 1234 to localhost:22 on that machine
<Kamion> localhost is the target not the listen address
<slomo> Riddell: yes i know... but the sqlite apps are useful for debugging imho :)
<pitti> ah, GatewaysPorts must be set
<pitti> Kamion: ah, got it
<Riddell> dholbach: http://kubuntu.org/~jriddell/tmp/telepathy-qt.diff
<dholbach> Riddell: thanks a lot
<pef> hello
<carlos> pitti: I guess you will get latest tarball generated on Thursday for Edgy prerelease, right?
<pitti> carlos: I want to upload final edgy packs on Friday, right after RC
<carlos> ok
<carlos> I will need that you send me the timestamp.txt file included in the tarball that you use
<carlos> so we don't have the same problems we had with Dapper
<jdong> pitti: any update on mWhr conversions for hal?
<pitti> jdong: unfortunately not
<pitti> just didn't find time to talk to upstream
<jdong> ok
<jdong> no big deal
<jdong> doesn't seem like many others are affected... just a specific acer laptop
* jdong will just rebuild his hal
<pitti> jdong: maybe they did the same thinko in their ACPI (milli times milli = milli)
<jdong> hehe, perhaps
<jdong> I have noticed that its claimed units are a bit  whack
<jdong> even in /proc/acpi/battery
<jdong> like some things it reports as Whr are obviously mWhr
<jdong> Present rate       : 64459 mA
<jdong> ^^ looks like ACPI bug :)
<jdong> or the Hummer of laptops
<jdong> pitti: I think bug 66370 is the same as my bug
<Ubugtu> Malone bug 66370 in gnome-power-manager "When unplugged the only battery levels used are 100% and 0%" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66370
<Kamion> oh, that's interesting
<Kamion> pitti: I thought apt's broken package count would operate recursively, but apparently it doesn't
<Kamion> so one of the assumptions in my code is wrong
<jdong> pitti: does gnome-power-manager calculate its own time remaining?
<jdong> pitti: because it's quite off from what acpi -V reports
<pitti> jdong: I *think* it gets it from hal
<jdong> (acpi -V being correct)
<jdong> ah, battery.remaining_time
<jdong> pitti: why doesn't hal use the same calculation method that acpi -V would?
<jdong> pitti: it's quirky
<jdong> like when I just unplug, it says 3 minutes remaining
<pitti> jdong: well, it needs its own method anyway for powerpc and other arches
<pitti> otherwise, no idea
<jdong> then 2 hours remaining
<pitti> jdong: can you please bring this up on the upstream hal list?
<jdong> and 30 seconds later, it says 15 minutes remaining, and then slowly starts counting up
<jdong> ok, I'll take this to the HAL list
<pitti> jdong: thanks
<sivang> oh dear,
<sivang> I uploaded to unstable
* sivang prepares another upload
<dholbach> tkamppeter: My sister is happy with Edgy and her lexmark z42 now. Thanks.
<mvo> tfheen: ok to upload http://people.ubuntu.com/~mvo/tmp/language-selector_0.1.30.debdiff ? it will fix the problem that locale-setup does not put LANGUAGE into /etc/environment always
<tfheen> mvo: which bug does it fix?
<mvo> tfheen: its part of the fix for bug #49334
<Ubugtu> Malone bug 49334 in casper "Fontconfig of zh_TW (Taiwan) is pointed to none, not zh_TW" [High,Fix committed]  http://launchpad.net/bugs/49334
<tfheen> mvo: ok; go ahead, then.
<mvo> thanks tfheen
<sivang> so according to new python policy, any pythonX.Y-dev dependecy should be changed to python-dev right?
<sivang> (given the package already depends on pycentral | pysupport)
<keescook> dholbach: can I have permission for two universe uploads?  (both are openssl migration related: http://people.ubuntu.com/~kees/edgy-fixes/)
<BenC_> mdz: Got it, uploading in a few minutes
* sivang pokes the python policy
<dholbach> keescook: sure, go ahead! good work on them!
<keescook> great, thanks.
<mdz> BenC_: thanks
<Treenaks> WOW
<Treenaks> even wifi + wpa came back from hibernation perfectly today!
<ivoks> Treenaks: good for you, i get filesystem errors on resume :)
<Treenaks> ivoks: My X is as broken after resume as before resume (bug 20283 ;)
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Unknown,Needs info]  http://launchpad.net/bugs/20283
<Treenaks> omg.. _sleep_ (suspend to ram?) works too 
* Treenaks hugs mjg59 
<ivoks> ;..*
<ivoks> oh... :)
<ivoks> ;..(
<Treenaks> ivoks: dont do that near jono, the ;)
<Treenaks> ivoks: he hates winks ;)
<ivoks> hehe i noticed that ;)
<Treenaks> dholbach: You're back!
* Treenaks heard horrible stories about ISPs being banned
<dholbach> Treenaks: yeah since 16:34
<dholbach> yeah, *.versanet.de was banned
<Treenaks> dholbach: ouch
<dholbach> it said "stop trolling", when I tried to login
<dholbach> NICE
* Treenaks wants the X people to hurry up fixing the ati driver for his laptop...fglrx breaks too much (sleep, notably)
<shwag_> Not sure who I need to talk to about this. Edgy doesnt support my ethernet nor my wireless drivers on my dell laptop, but they both work fine on dapper.
<Treenaks> shwag_: nice :)
<Treenaks> shwag_: you should file bugs, probably
<Treenaks> shwag_: (what kind of cards are they?)
<rideout> Riddell: do you have the buildlogs of qt4.2? i just rebuilt the packages on my system and all the sql drivers worked, lamont does't have the 4.2 logs up yet
<dholbach> shwag_: you should file a bug report at http://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+filebug
<Kamion> rideout: err, lamont's build logs are hideously obsolete, use launchpad
<Kamion> https://launchpad.net/distros/ubuntu/+source/qt4-x11 as a starting point I guess
<Riddell> rideout: build logs are on launchpad these days
<Riddell> rideout: https://launchpad.net/distros/ubuntu/+source/qt4-x11/4.2.0-1ubuntu2
<rideout> ok, thanks
<Riddell> https://launchpad.net/+builds/+build/255956
<shwag_> Treenaks: Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
<shwag_> Treenaks: Intel Pro/Wireless 3945ABG
<Riddell> rideout: I see  SQLite 2 support .... qt  SQLite support ...... plugin (system)
<Riddell> rideout: is that what we want?
<shwag_> dholbach: filed
<dholbach> shwag_: you can also join the kernel folks on #ubuntu-kernel
<shwag_> dholbach: yah,...in there, no ones talking though.
<dholbach> oh ok
<shwag_> dholbach: can I search for other similair bugs. Ive only tested this on knot 3, not on the new beta.
<dholbach> shwag_: oh, you probably should do an update and test
<rideout> Riddell: both would be better, but SQLite , is actually SQLite 3, they are slowly depreciating 2
<rideout> Riddell: can you do a $ls /usr/lib/qt4/plugins/
<rideout> ?
<shwag_> dholbach: yah, gonna do.
<pygi> sivang: ping once again :P
<dholbach> shwag_: thanks a lot
<shwag_> dholbach: but I have a feeling this is a upstream thing because I also installed the latest gentoo and it doesnt have the network support either...same kernel version.
<dholbach> shwag_: might be, but better to test with the new kernel
<shwag_> dholbach: i hope there is a patch. it sucks trying to get support for something when you cant connect to the internet! I gotta maket his happen before final release!
<dholbach> shwag_: thanks for working on this
<dholbach> shwag_: be sure to add all info to the bug report also
<shwag_> dholbach: someone just pointed me to this:  https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/62452
<Ubugtu> Malone bug 62452 in launchpad "ipw3945 not working (Edgy 2.6.17-9-generic #2 SMP)" [Undecided,Rejected]  
<Riddell> rideout: only imageformats in there
<sivang> pygi: pong
<rideout> Riddell: sqlite is built as a plugin, but it is not copied to the deb, $cat libqt4-sql.install, lists only usr/lib/libQtSql.so.* and thus no plugin is copied
<rideout> Riddell: so we can change debian/libqt4-sql.install or build sqlite support into the shared lib like the other sql drivers
<Riddell> rideout: probably, which do you think would be prefered?
<rideout> Ridell: i was right on the first email i sent you, sqilte isn't built in the lib because of a typo, the configure option currently is -qt-sql-slite, we can just add the q and be done, and it will be consistant with the other drivers
<dholbach> good night
<rideout> Riddell: i think debian has this typo too, so we should let them know as well
<mvo> tfheen: ok to upload a new dist-upgrader http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061016.2032_all.diff ? 
<Riddell> rideout: and chaging it to -qt-sql-sqlite will do what exactly?
<rideout> Riddell: qt will include the sqlite3 driver in the libQtSql.so along with all the other drivers and it will be accessable to all qt4 apps, without that option the driver is built as a plugin, but the deb packages don't include the plugin for installation
<tfheen> mvo: there's no debian changelog?
<Riddell> rideout: ok, doing a test build now
<tfheen> mvo: also, you have a spelling error in your API, but I don't think we'll fix that now. :-P
<Kamion> pitti: ready for another test run?
<Riddell> the ./configure output isn't very good at explaining what the options do
<tfheen> mvo: (upgradable vs upgradeable)
<seb128> tfheen: I've uploaded an orbit2 rebuild to get dbgsym packages for it, I've been Cced on a GNOME upstream bug asked where to find one of those and noticed we didn't rebuilt that package yet. Feel free to accept it after RC or edgy if you think that's better
<rideout> Riddell: try ./configure --help
<wasabi> bug 63988
<Ubugtu> Malone bug 63988 in ifupdown "Bonded interfaces donlt seem to work with DHCP" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63988
<Riddell> rideout: SQLite 2 support .... qt
<Riddell> SQLite support ...... qt (system)
<Riddell> rideout: which looks good
<Riddell> rideout: but why SQLite 2? surely we have 0 and 3?
<tfheen> seb128: just a rebuild?  Ok, now's fine, I guess..
<mvo> tfheen: Upgradable is correct according to my dict. is this maybe a us<->uk thing?
<Kamion> pitti: I've updated http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff - applies to a fresh 1.2.2
<mvo> tfheen: the upgrader is no normal deb package, so it has no debian changelog
<seb128> tfheen: yes, to get a dbgsym available, thank you
<slomo> Riddell: 0 is version 2.X.Y
<tfheen> mvo: but it's uploaded into the archive?
<rideout> Riddell: slomo beat me to it
<Riddell> slomo: how confusing
<mvo> tfheen: yes
<bhale> the 0 reflects the abi version not the so version
<Kamion> mvo: hmm, I'm never sure about that particular case; "upgradable" always reads to me as if it should be "upp-grah-dah-bel" rather than "upp-gray-dah-bel"
<Kamion> but I'm not sure if I'm correct there
<bhale> Kamion: is your tomboy issue resolved?
<rideout> Riddell: 2 is needed since many legacy apps still use it, but both the trolls and the sqlite folks want people to move to 3
<Kamion> bhale: no :-(
<bhale> Kamion: oh crap
<Kamion> tfheen: did you look over the casper stuff in trunk?
<mvo> tfheen: does it look ok (beside spelling ,) ?
<bhale> maybe mvo could have another look at it?
<BenC> mdz: Fixed sparc-utils uploaded
<mvo> bhale: at what in particular?
<Kamion> tfheen: also, if you could also eyeball http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff for possible upload once pitti's tested it on powerpc, that would be good; I've tested it on i386
<tfheen> Kamion: casper looks good to me.
<bhale> mvo: awhile back i asked you about upgrade problems from gmime2.1 to 2.2, holding back tomboy
<Kamion> mvo: old tomboy installed, apt holds it back rather than upgrading
<Kamion> 'apt-get install tomboy' DTRT
<tfheen> mvo: yes, it looks good apart from that.
<rideout> Riddell: SQLite 2 support .... qt, means that qt will use its own version of sqlite included in the source rather than link to the system library, looks like debian did that so since the bug fixed version of sqilte 2 in the repos create incompatibilitys with of db files
<Kamion> I recently removed gmime2.1 from the archive in the hope that that would help, but it didn't
<rideout> Riddell: incompatable old db files, i meant
<Kamion> mvo: http://people.ubuntu.com/~cjwatson/tmp/tomboy.log
<bhale> Package libgmime2.1 has broken dep on libgmime2
<pygi> same with   libgtk2-perl
<bhale> interesting
<pygi> Kamion: same with   libgtk2-perl
<Kamion> bhale: that's a Conflicts/Replaces/Provides
<Kamion> not very interesting
<bhale> Kamion: oh, there was no such package in the archive
<Kamion> pygi: haven't seen that here; apt-get happily wants to install libcairo-perl
<bhale> Kamion: must be kept over
<tfheen> Kamion: eyeballed and looks correct.
<Kamion> bhale: Conflicts shouldn't be removed just because packages are ...
<bhale> yes, agree
<Kamion>  libgmime2 |   2.0.14-2 | warty/universe | amd64, i386, powerpc
<rideout> I have kde4 running on vt8 now! on edgy
<rideout> well as much as possible anyway
<Riddell> rideout: excellent.  from our packages or self compiled?
<rideout> Riddell: self compiled from a fresh svn up
<mvo> Kamion: does apt-get dist-upgrade -o Debug::pkgDepCache::AutoInstall=true add some useful information to this (in addition to the pkgProblemResolver debug)?
<Kamion> mvo: updated http://people.ubuntu.com/~cjwatson/tmp/tomboy.log
<Kamion> confusingly, libgmime-2.0-2 is newer than libgmime2.1
<bhale> that was Beowulf
<bhale> I was less than thrilled about it
<bhale> seemed better to keep in line with debian, though
<mvo> Kamion: it looks like libgmime2.1 still has two rdepends on your system, what packages are those?
<Kamion> mvo: tomboy itself and libgmime2.1-cil
<Kamion> (according to grep-status)
<Kamion> the only rdepends of libgmime2.1-cil is tomboy again
<rideout> http://ats-pos.com/tmp/snapshot4.png, edgy, with beryl trunk and kate from kde4 trunk
<Riddell> rideout: sweet
<Riddell> rideout: although that theme you're using is a bit brown looking
<Riddell> rideout: by the way join us on #kubuntu-devel for more kde/qt chat
<BenC> Can someone approve sparc-utils? Fixed the FTBFS.
<BenC> tfheen: ^^
<tfheen> BenC: yay, nice.
<tfheen> Kamion: please approve BenC's sparc-utils upload.
<Kamion> done
<tfheen> BenC: please close the bug, then
<tfheen> BenC: is bug 57146 fixed with your latest upload?
<Ubugtu> Malone bug 57146 in linux-source-2.6.17 "[prism2.5]  doesn't associate" [High,Confirmed]  http://launchpad.net/bugs/57146
<BenC> tfheen: No idea, let me read up on it
<tfheen> BenC: if not, I don't think I'm going to accept an upload to fix it, so please remove the milestone or close the bug as appropriate.
<BenC> tfheen: Actually, it should be fixed, but I'll wait for confirmation before marking it as such
<Kamion> mvo: actually, now I think of it, that fontconfig-voodoo fix in ubiquity should have gone in a casper ubiquity hook
<Kamion> mvo: but never mind now, we'll sort it out post-edgy
<mvo> Kamion: ok, thanks
<Kamion> infinity: ping, xorg upload for xbase-clients, xlibs-dev, xutils?
<Burgwork> keescook: congrats on your first security notice
<mvo> Kamion: I have dinner now, I may not be able to check the tomboy issue today :/
<mvo> s/have/will have/
<keescook> Burgwork: thanks!  :)  my second, technically, but this one was my first where I did all the bits myself.  :)
<mdke_> i need a bit of help with some scripting... I have "for i in dir/*;" but I need to exclude a couple of files from that, is there any way that can be done?
<mdke_> actually, no worries. Have figured out a workaround
<_ion> mdke: With zsh you could say for i in dir/^(foo|bar), but i presume you want pure sh.
<lamont> Kamion: does it make sense to migrate the build logs page from ~lamont to some more sensible archival site?
<Kamion> lamont: dunno, up to you; there will come a time when only old-timers remember it anyway :-)
<lamont> who's calliong who old? :-)
<lamont> I'm happy to nuke the tree, but figured it'd be nice to archive it somewhere, maybe...
<Kamion> mdke_: for i in dir/*; case $i in dir/exclude1|dir/exclude2) ;; *) do stuff; do more stuff ;; esac; done
<lamont> launchpad has the rest of the known multiverse in it, why not have old build logs?
<Kamion> #launchpad might know a way to inject the old logs
<mdke_> Kamion: good to know, thanks
<lamont> Kamion: yeah - I'll poke them...
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/xorg.diff, since I have a feeling Adam won't be around for a while yet?
<tfheen> Kamion: ok, approved.
<tfheen> I'd like us to kill those (and get them out of the archive) as one of the first things when edgy+1 opens.
* Kamion notes that stuff in the xorg source package itself depends on xbase-clients
<Kamion> removing xlibs-dev ASAP in edgy+1 seems sensible, but xbase-clients and xutils aren't that evil
<tfheen> they should at least be synced with Debian
<mvo> tfheen: could you please approve my dist-upgrade upload?
<tfheen> I think they're silly, but that might just be me.
<tfheen> Kamion: please approve mvo's dist-upgrader upload
<Kamion> syncing with Debian would involve re-monolithing the clients
<Kamion> dist-upgrader> done
* mvo hugs Kamion
* tfheen squishes usplash
<Kamion> tfheen: so, http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff ?
<Kamion> tfheen: pitti's gone for the night I think, and I haven't been able to test it on powerpc myself, but I've simulated a similar situation on i386 and it worked fine; I've also tested ordinary installations with that patch using both automatic and manual partitioning
<Burgwork> doko_: ping
<pitti> Kamion: back now
* bluefoxicy hits places->anything and HOME opens 10 times ugh
<keescook> a universe upload was approved (bug 66273), but it's a sync.  who should I bother about that?  :)
<Ubugtu> Malone bug 66273 in dirvish "sync request" [Undecided,Confirmed]  http://launchpad.net/bugs/66273
<crimsun> no one, u-a is subbed, and you're in ubuntu-dev. It's ready.
<sivang> keescook: subscribe ubutu-archive to the bug, and ask a sync 
<sivang> keescook: ubuntu-archive, that is
<sivang> keescook: that's how I recall sync request can be made :)
<keescook> sivang: it's ready, who should I ask for the sync?
<crimsun> < crimsun> no one, u-a is subbed, and you're in ubuntu-dev. It's ready.
<sivang> crimsun: ? :)
<tfheen> Kamion: let's let pitti finish his test?
<pitti> tfheen: can do if required
<pitti> tfheen: however, I gave Kamion ssh access for the last hours, I'd like to hear about the current status
<pitti> tfheen: unless Kamion wants to upload tonight still, I'd like to do the test tomorrow morning, if you are fine with that. He seems to be off for today anyway?
<tfheen> pitti: I feel like a broken record, but I'd like this in as soon as possible and if you'd rather go off to bed; do so and we'll just put it in the archive.  Worst case, we have to fix it again tomorrow.
<doko_> ajmitch: please approve http://people.ubuntu.com/~doko/edgy/optcomplete.debdiff
<doko_> Burgwork: pong
<pitti> tfheen: ok, then I'll test it now
<Burgwork> doko_: is this an issue" https://launchpad.net/bugs/6647 ?
<Ubugtu> Malone bug 6647 in sp-gxmlcpp "sp-gxmlcpp: merge new debian version" [Medium,Fix released]  
<JanC> Burgwork: it's related to the pycentral problem(s)
<doko_> Burgwork: it's fixed?
<Burgwork> JanC: hm,m I pasted the wrong bug
<Burgwork> just a sec
<Burgwork> https://launchpad.net/distros/ubuntu/+source/sun-java5/+bug/66471
<Ubugtu> Malone bug 66471 in sun-java5 "Circular dep -bin and -jre" [Undecided,Confirmed]  
<doko_> Burgwork: rejected
<Burgwork> doko_: ugh
<Burgwork> oh, that is the "cannot ship only bits of it"
<doko_> yes
<doko_> and even without the license, you need both parts to be meaningful as a runtime
<Burgwork> why not put them in the same package then?
<Kamion> pitti: I logged out of your box, didn't need it any more
<Kamion> pitti: managed to reproduce the same problem locally
<Kamion> (ish)
<pitti> Kamion: ah, good; I'm just testing your latest patch
<Kamion> thanks
<pitti> thanks to you! :)
<Kamion> keescook: just leave it, Keybuk and I each go through the pending sync requests from time to time
<keescook> Kamion: okidoky.  I just wanted to be sure there wasn't something more I needed to do.  :)
<Kamion> I expect we'll do another pass tomorrw
<Kamion> tomorrow
<Kamion> hooray, the NBS list is empty
<tfheen> Kamion: is it ok with you to do that ubiquity upload once you have pitti's results?
<Kamion> tfheen: yes
<Kamion> tfheen: let me just give you the current contents of unapproved
<Kamion> (skipping universe)
<mdke_> I feel bad asking these basic questions here, but you guys are helpful. In my script, I need to use sed to change a line inside a number of files. However my expression "sed -i -e "s@phrase@phrase@g" filename" isn't working (I suspect) because phrase has inverted commas in it. Is that the reason it isn't working? What should I use instead? 
<Kamion> mdke_: "foo\"bar\"baz" at the shell turns into foo"bar"baz as a command-line argument
<Kamion> alternatively, 'foo"bar"baz'
<Kamion> to get a single quote inside single quotes, use 'foo'\''bar'\''baz' (note that that actually closes the single quotes, adds a ' character with \', and then opens the single quotes again)
<Kamion> mdke_: I strongly recommend reading the QUOTING section of bash(1)
<Kamion> or actually the Quoting section of dash(1); it's more concise and obviously doesn't describe bashisms
<mdke_> Kamion: one for a rainy day. Thanks
<Kamion> tfheen: unapproved main/restricted: orbit2/1:2.14.3-0ubuntu2 language-selector/0.1.30 qt4-x11/4.2.0-1ubuntu3 kubuntu-default-settings/1:6.10-59 imlib2/1.2.1-2ubuntu1
<tfheen> orbit2 is ok; just a rebuild.
<tfheen> language-selector is ok
<tfheen> I _think_ qt4-x11 is ok; Riddell didn't scream when dholbach uploaded it.
<tfheen> when's that k-d-s from?
<tfheen> and imlib2 is approved.
<Kamion>   109770 | S- | kubuntu-default-sett | 1:6.10-59            | 8 hours 20 minutes
<Kamion>          | * kubuntu-default-settings/1:6.10-59 Component: main Section: kde
<Riddell> I do indeed approve of dholbach's qt4 upload
<tfheen> Riddell: what about the k-d-s upload?
<Riddell> tfheen: I approve of my k-d-s upload too :)
<Riddell> tfheen: it's just s/Sans Serif Mono/Monospace/
<tfheen> Riddell: heh; ok.  Approved, then.
<Kamion> if/when you do this again, we should really get you into ubuntu-archive. RM <!= ubuntu-archive is just too awkward
<tfheen> Kamion: the RM should really have knobs in LP to just DTRT with this, IMO.
<tfheen> maybe the RM should be a member of u-a too, but I think this should all be knobby.
<Kamion> aye. I'd go with having ubuntu-archive have knobs in LP first :-)
<tfheen> I thought they had knobs, it's just that the knobs aren't connected to anything just yet?
<Kamion> (this is all just command-line at present, for those who don't know)
<Kamion> tfheen: right, but same difference ...
<Kamion> useless knobs =~ no knobs
<tfheen> hello Matt
<mjg59> Could people please *not* reassign bugs to acpi-support unless it's clearly something to do with the scripts in it
<mjg59> Suspend/resume issues go against the kernel
<mjg59> Machine crashes go against the kernel
* Kamion wonders idly if adding .desktop files is really the best thing for MOTUs to be doing at the moment ...
<keescook> mjg59: usplash on amd64/nvidia> on sunday I dumped the BIOS memory segment for int10, just to see if I could figure out why it was rejecting the vbe save.  didn't get far, but I was curious if you wanted a copy of the bios dump?  would that help you at all on that issue?
<mjg59> keescook: No, I've got access to hardware to reproduce it on
<mjg59> It looks like we've run out of time for edgy, so it'll just use vga16 there
#ubuntu-devel 2006-10-17
<keescook> mjg59: okay.  yeah, figured it was going to be vga16, but thought I'd ask anyway.  cool.
<Kamion> pitti: you have about five minutes before I just upload anyway and go to sleep, BTW :)
<mjg59> keescook: But thanks for taking a look!
<Amaranth> Oh, that explains the need for all the new usplash themes to support the old format
<tfheen> Amaranth: they should have all along.
<tfheen> mjg59: the artwork shipped in the usplash package in dapper was the ubuntu artwork, wasn't it?
<pitti> Kamion: install is at 22gnome_panel_data script
<tfheen> BenC: you sparc-utils FTBFS-ed
<tfheen> BenC: https://launchpad.net/+builds/+build/256146
<BenC> tfheen: Hmm, I'll tak a look
<mjg59> tfheen: Yes
<Kamion> pitti: oh, worth waiting
<pitti> Kamion: ah, the skip button for langpack download is nice :)
<Kamion> that was an option designed for us, yes :-)
<pitti> ah, in check-kernels now
<pitti> Kamion: yay, it's removing all the powerpc64-smp related packages now
<Kamion> excellent; let's see if it works
<Kamion> just fixing a bit of KDE frontend desync I noticed
<pitti> I was a bit nervous when I saw update-initramfs before puring the kernel; I hope it'll be called again
<pitti> Kamion: it's purging langpacks now, and /target/boot has no initrd
<Kamion> no, but does it need to be?
<Kamion> oh, hmmmm
<pitti> ok, ubiquity finished
<Kamion> pitti: does 'chroot /target update-initramfs -u' now fix it?
<pitti> Kamion: shall I save the log for you?
<Kamion> pitti: may as well, yes please
<pitti> Kamion: after update-initramfs -s I have an initrd again, contents looks fine
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/syslog
<pitti> Kamion: I do an actual boot test now
<Kamion> -s?
<pitti> erm, -u
<Kamion> Oct 16 22:18:55 ubuntu ubiquity: rmdir:
<Kamion> Oct 16 22:18:55 ubuntu ubiquity: /lib/modules/2.6.17-10-powerpc64-smp
<Kamion> Oct 16 22:18:55 ubuntu ubiquity: : Directory not empty
<Kamion> pitti: what's in there?
<pitti> darn, too late; I have to reboot to find out
<pitti> urgh, 'Unable to mount root fs on unknown-block(0,0)
* pitti boots live again
<pitti> . o O { We are bug. Resistance is futile. }
<pitti> Kamion: the only thing left in the ppc64 modules dir is the 'build' symlink to linux-headers-2.6.17-powerpc64-smp, which is apparently still installed
<Kamion> ah, ok, I'll ignore that
<Kamion> I'm afraid this is going to be slightly more invasive to fix
<pitti> I just wonder why it doesn't boot at all
<ajmitch> pitti: heard that the nvidia driver has a root exploit available?
<pitti> Kamion: I bind-mounted /dev, mounted /proc in the chroot and called ybin
<Kamion> I had to shuffle a chunk of code around, because you have to create the kernel symlink after creating the initramfs
<Kamion> pitti: I bet the initrd symlink isn't there
<Kamion> /boot/initrd.img
<pitti> Kamion: I get 'Failed to initialize HFS working directories: No such file or directory'
<Kamion> check for /boot/vmlinux while you're there
<pitti> Kamion: and 'ybin: /dev/hda2 appears to have never had a bootstrap installed, please run kmkofboot'
<Kamion> sounds like yaboot-installer gave up
<pitti> Kamion: indeed, vmlinuz symlink is there
<pitti> Kamion: but initrd symlink isn't
<pitti> Kamion: it might have given up because there was no initrd at all?
<Kamion> no, mkofboot definitely worked
<Kamion> according to your syslog
<Kamion> Oct 16 22:19:12 ubuntu yaboot-installer: mkofboot: Blessing /dev/hda2 with Holy Penguin Pee...
<Kamion> Oct 16 22:19:13 ubuntu yaboot-installer: mkofboot: Updating OpenFirmware boot-device variable in nvram...
<Kamion> Oct 16 22:19:15 ubuntu yaboot-installer: mkofboot: Installation complete.
<Kamion> pitti: failed to initialize HFS blah> check $HOME
<Kamion> IIRC the HFS tools want to fiddle with $HOME/.hcwd
<pitti> heh, indeed
<pitti> that did the trick
<pitti> still doesn't boot (same error), but oh well, let's do that tomorrow
<pitti> Kamion: let's get some sleep, shall we/
<pitti> ?
<Kamion> I need to upload something of this tonight
<ajmitch> pitti: anyway to mark an existing bug as security-related?
<pitti> ajmitch: sure, there's an entry for that in the menu ('Visibility/Security')
<ajmitch> aha, missed it, thanks :)
<pitti> ajmitch: nvidia root> no, can you please mail any pointer/info? thanks!
<ajmitch> seems that bug 46034 is a bit more serious
<Ubugtu> Malone bug 46034 in Ubuntu "Page crashes X" [High,Confirmed]  http://launchpad.net/bugs/46034
<ajmitch> attaching the info to that
<mjg59> pitti: http://download2.rapid7.com/r7-0025/
<pitti> ah, thanks
<mjg59> (Summary: We're screwed)
<ajmitch> more or less
<pitti> phun
<mjg59> Has anyone actually tested the exploit?
<ajmitch> not that brave
* keescook will do in a bit...
* pitti is curious and tries
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff updated
<Kamion> I had to shovel the symlink fixing code around, and haven't tested this because my vmware setup is in the next room and I honestly don't want to get out of bed again
<Kamion> tfheen: I know this is a bad time for this sort of request, but can I upload it and fix up anything that goes wrong tomorrow if necessary? I've been as careful as I can, and *something* needs to be done about this bug anyway or we have to drop *-desktop-powerpc.iso
<pitti> keescook: gcc -I/usr/include/freetype2/ -o nv_exploit nv_exploit.c  -lfreetype -lX11 -lXft -lXt builds the exploit, but it wants two addresses
<tfheen> Kamion: yeah, skimming it now.
<Kamion> the s/remove_kernels/self.remove_kernels/ stuff is an unnecessary remnant; removing that now
<keescook> pitti: yeah, reading through it now.
<tfheen> Kamion: feel free to upload, my brain is in usplash mode right now so python looks weird.
<Kamion> I think we now have to run the kernel-symlink stuff for all architectures because we removed the initrd
<Kamion> (from the squashfs)
<pitti> keescook: have fun. I think I really need to sleep now, most parts of my brain apparently are..
<Kamion> although I suspect Adam only removed the actual image, not the symlink ...
<keescook> pitti: hehe.  oka, good night!
<Fujitsu> mjg59, that is seriously bad.
<Kamion> tfheen: sorry about this :-/
<ajmitch> night pitti 
<pitti> Kamion: ok, if you'll upload that, it should catch tomorrow's dailies; I'll do a full test again in the morning as soon as the CDs are available
<Kamion> pitti: thanks a lot, I appreciate it
<Kamion> I'll get i386 tested as soon as I wake up tomorrow
<tfheen> Kamion: dude, get some sleep.
* pitti waves goodnight
<tfheen> Kamion: no worries about this; we'll fix it tomorrow.
<sivang> night pitti 
* tfheen tucks pitti in.
<pitti> tfheen: listen to your own advice, btw :)
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.3.diff <- final patch
<tfheen> pitti: I have three uploads left; I want usplash on amd64 to work tomorrow morning.
<pitti> tfheen: good luck!
<tfheen> mjg59: it seems like the "cannot allocate memory" (when using vga16fb) in the initramfs might be because the fb isn't ready yet at that point.
<mjg59> Oh.
<mjg59> I wonder if that's why the sleep was there.
<Kamion> tfheen: bug 66424 is in main. ok to sync?
<Ubugtu> Malone bug 66424 in elementtree "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66424
<Kamion> tfheen: also, did you reach agreement on bug 65963?
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
<tfheen> Kamion: ok; please sync elementtree.
<tfheen> Kamion: doko_ said he needed to investigate two build failures (or possible build failures) in main.
<Kamion> ok
<tfheen> so I'm not entirely sure what happens there.
<Kamion> done the other two targetted sync requests
<tfheen> which one was the last one?
<Kamion> python-goopy (universe)
* Kamion -> bed
<tfheen> oh, ok.
<tfheen> sleep tight
<sivang> so user-mode-linux is building? there are lots of stuff in universe with unmetdeps waiting for it
<tfheen> mjg59: hmm, same error with a sleep in there.
<mjg59> tfheen: Fun
<sivang> hmm, no I'm getting tired then
<tfheen> mjg59: I'm going to look at why.  It might be I just suck.
<shawarma> sivang: user-mode-linux? Where do you see that?
<sivang> shawarma: it's too late :-)
<sivang> shawarma: see my comments to the bug
<shawarma> sivang: -> #ubuntu-motu
<tfheen> mjg59: hmm, no, it's the config file which claims I want 1280x1024.  This doesn't work with VGA, for obvious reasons.
<TheMuso> c/
<mjg59> tfheen: Ha.
<mjg59> tfheen: Ok. The bogl code should try the change resolution ioctl
<tfheen> mjg59: rm -f /etc/usplash.conf if arch is != i386
<mjg59> tfheen: And then if that fails, it should just return whatever resolution it has, rather than returning an error
<mjg59> tfheen: Please don't
<mjg59> Otherwise we'll have to regenerate it on upgrade when we finally get this working properly
<tfheen> mjg59: that won't work either; the artwork picked will be the wrong one, wont it?
<mjg59> tfheen: The artwork picking is done afterwards, isn't it?
<mjg59> Or...
<mjg59> Argle.
<sivang> night all
<mjg59> That's how it was supposed to work. It's possible that it no longer does.
<tfheen> mjg59: it seems to be able to DTRT.
<mjg59> Ah, cool
<tfheen> except it does usplash_set_resolution ; usplash_init;
* jdong just saw /. article on root exploit with nvidia's binary driver
<jdong> just peachy :)
<pygi> :P
<_ion> Yeah.
<bddebian> Heya folks
* tfheen wonders if he should make bogl save errno properly and have a hack in usplash_bogl_init which falls down to 640x400 if the initial bogl_init fails with ENOMEM.
<tfheen> mjg59: ok, how about I make the initramfs script not pass xres and yres if DPKG_ARCH is amd64?  That's easy enough to reverse?
<mjg59> Yeah, that sounds good
<BenC> tfheen: New sparc-utils uploaded
<tfheen> BenC: and this one'll build, I hope.
<tfheen> infinity: please accept sparc-utils upload from BenC once you're awake.
<BenC> yep, I fixed sparc32, but didn't know that audioctl was broken
<BenC> I had to disable audioctl, because it is no longer supported by the kernel
<tfheen> ok
<tfheen> mjg59: It. Worked.
<tfheen> (hooray)
<BenC> http://it.slashdot.org/article.pl?sid=06/10/16/2038253&from=rss
<BenC> Anyone know what we are doing about that for edgy release?
<BenC> "Root Exploit For NVIDIA Closed-Source Linux Driver"
<ajmitch> BenC: dunno, I told pitti about it earlier
<zul> is there a fix yet besides running the nvidia binaries?
<elmo> zul: or not running them even
<elmo> ;-)
<zul> that works
<BenC> there is a 1.0-9625
<ajmitch> zul: I don't know if the 9726 binaries have been tested
<BenC> that supposedly fixed it a month ago
<ajmitch> not sure if they're still beta or not
<BenC> it is beta
<ajmitch> they released 9625 as beta, 9626 didn't appear on their beta page iirc
<ajmitch> either way there's still a lot of problems reported with the 9xxx drivers still
<HrdwrBoB> given the choice between a lot of problems
<HrdwrBoB> and root exploit
<BenC> lesser of two evils
<BenC> and I can't decide which one is lesser :)
<HrdwrBoB> heh
<ajmitch> with 9626 you'd make all the beryl-using junkies happy :)
<ajmitch> not sure if that's a good thing or not..
<Fujitsu> THe solution is simple. Ban binary drivers in Ubuntu.
<HrdwrBoB> ok
<Fujitsu> Hm. I haven't been kicked for trolling yet?
* Fujitsu ducks.
<HrdwrBoB> and now for something useful and contstructive
<HrdwrBoB> constructive
<_ion> Well, it's easy to modify l-r-m to install 'nvidia-beta' just like it installs 'nvidia-legacy' in addition to 'nvidia'. :-)
<tfheen> good night, everybody.
<zul> ] night tfheen 
<infinity> zul_: You around?
<stub> Launchpad will be going down for about an hour in around 30 minutes time. Longer than usual downtime this week due to some data migration that needs doing.
<infinity> stub: Thanks for the warning.
<infinity> stub: BTW, from here until release, we'd probably appreciate something more like 24 hours' notice. :)
<infinity> stub: (But today, this downtime should be fine)
<stub> Hopefully this will be the only significant downtime between now and then anyway. Need to copy a load of translations to edgy, and after that it should be clear sailing.
<infinity> Famous last words. :)
<imbrandon> is that kinda like the redneck saying "hey yall watch this ......" ( just teasin )
<infinity> Okay, this is sad.  I've just spent the last 4 hours dealing with a backlog of requests made while I was asleep, and NOW I can get to work on the things I had planned for the day.
<infinity> Oi.
<imbrandon> infinity, heh
<ajmitch> infinity: any universe uploads for me to pick over?
* ajmitch will probably have to check stuff after the LP downtime, by the time I walk home
<infinity> ajmitch: Here...
<infinity>   109863 | S- | ichthux-default-sett | 1:6.10-2             | 6 hours 30 minutes
<infinity>          | * ichthux-default-settings/1:6.10-2 Component: universe Section: kde
<infinity>   109857 | S- | mythtv               | 0.20-0.2ubuntu2      | seven hours
<infinity>          | * mythtv/0.20-0.2ubuntu2 Component: multiverse Section: graphics
<infinity>   109856 | S- | projectmanager.app   | 0.1.2-1ubuntu1       | seven hours
<infinity>          | * projectmanager.app/0.1.2-1ubuntu1 Component: universe Section: devel
<infinity>   109855 | S- | quixote              | 2.4-4ubuntu1         | seven hours
<infinity>          | * quixote/2.4-4ubuntu1 Component: universe Section: web
<infinity>   109854 | S- | python-pyrss2gen     | 1.0.0-2ubuntu1       | 7 hours 10 minutes
<infinity>          | * python-pyrss2gen/1.0.0-2ubuntu1 Component: universe Section: python
<infinity>   109853 | S- | python-omniorb2      | 2.6-3.1ubuntu2       | 7 hours 10 minutes
<infinity>          | * python-omniorb2/2.6-3.1ubuntu2 Component: universe Section: devel
<infinity> Some of the changelogs are less than informative..
<ajmitch> not even listing bugs closed, I guess?
<infinity> Some do...
<infinity>  python-omniorb2 (2.6-3.1ubuntu2) edgy; urgency=low
<infinity>  .
<infinity>    * debian/omniidl4-python.files: fix file list (Closes: Malone #65411).
<Ubugtu> Malone bug 65411 in python-omniorb2 "[UNMETDEPS]  python-omniorb2 has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65411
<infinity>  python-pyrss2gen (1.0.0-2ubuntu1) edgy; urgency=low
<infinity>  .
<infinity>    * debian/control: fix build-depends to fix FTBFS
<infinity>    * Closes: Malone #65405
<Ubugtu> Malone bug 65405 in python-pyrss2gen "[UNMETDEPS]  python-pyrss2gen has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65405
<infinity> I'm guessing those two are approved?
<ajmitch> yep
<infinity>  quixote (2.4-4ubuntu1) edgy; urgency=low
<infinity>  .
<infinity>    * debian/patches/01-ptl_compile.py.dpatch: fix path to python
<infinity>      (Closes: Malone #65347)
<infinity>    * rename debian/quixote-doc.* to debian/python-quixote-doc.* to get the
<ajmitch> crimsun probably did the mythtv fix as well
<Ubugtu> Malone bug 65347 in quixote "[UNMETDEPS]  quixote has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65347
<infinity>      documentation included into the python-quixote-doc package
<infinity>  mythtv (0.20-0.2ubuntu2) edgy; urgency=low
<infinity>  .
<infinity>    * Import changeset #11365 from mythtv SVN to resolve mythreplex bug
<infinity>      (Closes Ubuntu: #65790)
<infinity>    * Update maintainer to be MOTU-Media
<infinity> Changed-By: Mario Limonciello <superm1@ubuntu.com>
<ajmitch> ok, apprve those two, I saw them discussing the mythtv bug earlier
<infinity>  projectmanager.app (0.1.2-1ubuntu1) edgy; urgency=low
<infinity>  .
<infinity>    * Modified build deps to reflect new libgnustep packages.
<infinity> That one's the "not so informative" one.
* ajmitch wonders if a universe freeze is sane for edgy+1
<infinity> I can grab a debdiff for you, or just reject it.
<ajmitch> yeah, i know the context, it should be approved
<ajmitch> there are about 50 or so gnustep packages that had to be rebuilt/fixed
<infinity> Ahh, kay.
<infinity>  ichthux-default-settings (1:6.10-2) edgy; urgency=low
<infinity>  .
<infinity>    * New KDM/Ksplash themes
<infinity>    * New wallpaper
<infinity>    * New usplash theme
<infinity>    * New kmenu sidebar
<infinity>    * Add Konqueror background
<infinity>    * Add usplash-dev to Build-Depends to build new usplash
<mjg59> infinity: Done
<infinity> mjg59: Danke.
<infinity> mjg59: Tested this time, perchance? :)
<mjg59> Tested lsat time
<ajmitch> ichthux-default-settings should be fine as well, just another derivative
<mjg59> But not in a pbuild
<infinity> mjg59: Ahh.
<infinity> ajmitch: Alright, that clears your queue.  Congrats.
<ajmitch> thanks
<ajmitch> I'll try & fill it up again tonight
<infinity> :)
<infinity> For feisty, I'll make sure some MOTU folk can actually see into the queue.
<infinity> Should make this slightly less painful.
<imbrandon> yea
<infinity> I do think a universe freeze does make sense in the last 1/2-week stretch, though.
<Chipzz> feisty = edgy + 1?
<infinity> Encouraging random buggy uploads for universe isn't any better than for main.
<ajmitch> Chipzz: apparantly, we're still waiting on the official announcement
<ajmitch> the problem is that all uploads to universe have slowed down, and people are afraid to make any fixes
<ajmitch> we just have to get them into line
<imbrandon> maybe just a UVF 1 month out and freeze at RC for +1
<ajmitch> could work, you can discuss it in a few weeks
<imbrandon> yea
<ajmitch> hm
<ajmitch> tempting to grab a flight to MV
<imbrandon> ajmitch, DO IT !!
<imbrandon> would be nice to have you there for the stuff whiprush was speaking about too
<ajmitch> imbrandon: PAY ME! :)
<imbrandon> ajmitch, i wish i could , i would in a second
<infinity> BenC: Where did debian/copyright (and a mess of other things) go in that last sparc-utils upload?
<infinity> BenC: Care to debdiff and tell me WTF? :)
<infinity> BenC: Oh, you dropped audioctl COMPLETELY.  I see.
<infinity> BenC: checking over the diff for sanity, then. :)
<infinity> BenC: approved.
<ajmitch> infinity: reject libsdl-ruby_1.1.0-1ubuntu1.dsc, please - versioning is wrong :)
<infinity> ajmitch: Err, what libsdl-ruby?
<ajmitch> one that was just uploaded, should have been 1.1.0-1build1
<infinity> Oh, won't be in the queue for another 30 seconds, then. :)
<infinity> (Every 5 minutes)
<ajmitch> maybe it hasn't got through to the queue
* infinity waits.
<ajmitch> right :)
<ajmitch> I hope that -1build1 doesn't get rejected
<ajmitch> since that's the right version
<infinity> You did both in the same run?
<ajmitch> not me
<infinity> You'll probably have to re-upload -1build1, since it's the lower version number.
<ajmitch> but yes, they were both uploaded in the same 5 min period
<ajmitch> ok, thanks
<infinity> Oh, no, they both landed in unapproved.  Of course.
<infinity> Since the version checks aren't done until I accept.
<ajmitch> ah, useful
<infinity> It's all good.  Rjecting ubuntu, accepting build.  Yes?
<ajmitch> yes
<infinity> Done.
<ajmitch> thanks
<stub> Launchpad is going down in 15 minutes for a code update and data migration work. Estimated downtime is 1 hour but will hopefully be significantly less.
<ernstp> is usplash meant to work on AMD64 in edgy?
<ernstp> there's some updates today that hints that the developers want splash on AMD64 too?
<keescook> ernstp: there were problems with uspalsh on amd64 at higher resolutions
<infinity> ernstp: Once today's updates build and hit the archive, it's meant to work, yes.
<infinity> keescook: s/were/are/
<infinity> keescook: We're forcing usplash on amd64 to bogl-mode with vga16fb.
<infinity> (As of today)
* keescook nods
<ernstp> hmm... it didn't work at any resolution here
<ernstp> eh, that's great! :-)
<infinity> ernstp: Yes, it won't work for beans until today's stuff hits the mirrors.
<ernstp> right. I've been a bit confused if it was supposed to work or not, didn't find any bugs on the matter either
<caleb-> Hello, edgy uses dash as /bin/sh, and it break *MANY* old scripts. Can it be fixed before edgy's official release?
<fabbione> caleb-: no, you need to fix the scripts to either use /bin/bash or make them *sh* compliant
<caleb-> fabbione: OK. I see. Thank you. :-)
<mnepton> or symlink bash to dash
<Treenaks> mnepton: but that will slow down your system boot
<mnepton> which is The Big F-ing Hammer approach
<mnepton> Treenaks: which is why i don't tend to use The Big F-ing Hammer approach ;)
<pitti> Good morning
<siretart> morning Pitti!
<Huahua> Good morning, pitti 
<Fujitsu> I wouldn't say it was good, but morning!
<pitti> hi siretart 
<pitti> moin Huahua 
* bluefoxicy yawns
<mnepton> moin pittilicious
<Chandan> Hi
* pitti hugs tfheen ecstatically -- yay usplash!
* pitti hugs mjg59 for usplash, too!
<Chandan> I want to know how ubuntu is adding its own version for debian upstream .. like gdm 2.8.0-0ubuntu1 ... XubuntuY form
<Burgundavia> Chandan: yep, what do you need to know about it?
<Chandan> I am working on building a debian based distro ... I am modifying some gnome related packages ..and I want to add my own version 
<Chandan> I have done taht adding same as ubuntu .. like gdm2.8.0 to gdm-2.8.0-0boss1
<Chandan> Burgundavia, I want to on what basis Ubuntu is adding its own version .. Is Ubuntu is adding for all 15000 packagexs of debian
<Burgundavia> Chandan: only those changed in Ubuntu
<Chandan> Burgundavia, What changes that has been done .. 
<Burgundavia> any time the source package gets changed in Ubuntu, we add the -XubuntuY stuff
<Chandan> Burgundavia, I have changes some debian images to our distro boss images .. and in some packages I ahve modified some script 
<Chandan> Burgundavia, If we are adding our version only to the packages we are mdifying  wont it give the depenency problem while isntalling other packages 
<Chandan> Burgundavia, Wont it ask for the Debian upstream version 
<Chandan> Burgundavia, I am facing that problem .. I am trying to install one package ..But it is showing that the pacakge depends on debian sarge version ,but boss version is installed on the system
<Burgundavia> Chandan: that is beyond me. You would need to ask one of the more experienced people around. I would ask in -motu, as they are better equipped to answer your question
<Chandan> Burgundavia, ok ..HOw can interact with motu
<Burgundavia> their channel is #ubuntu-motu
<AnAnt> in which package did Dapper put it's usplash image?
<Kagou> morning
<pitti> fabbione: yup, shadow seems to be a fallout from new gettext 0.15
<fabbione> WOOOO
<infinity> pitti: I'm not sure I wanted to hear that. :/
<pitti> seems to be quite common, there's a lot of Debian ML activity about that
<pitti> I fixed the first failure and now fight with the second
<infinity> Does this mean I get to do another re-run on i386 to catch all of these? :/
* infinity grumbles.
<pitti> infinity: preferably
<pitti> but after all those uploads, another test would be nice anyway
<fabbione> infinity: well i am running main here already
<fabbione> infinity: that should be enough to catch them
<fabbione> infinity: directfb is still FTBFS on sparc 
<fabbione> ah hold on
<fabbione> never mind
<fabbione> skip that
<infinity> fabbione: Are you doing arch:all as well?  Some arch"all stuff uses autotools and could explode on this.
<fabbione> infinity: i think i am...
<fabbione> $sbuild_args .= ' --arch-all' if ($arch eq "sparc");
<infinity> Kay.
<fabbione> well it's still worth to give another run on x86 tho
<fabbione> or ppc for the matter
<infinity> Your machine is faster than terranova, so I'm happy with that.
<infinity> But I can get elmo to re-import for i386/amd64/powerpc.
<infinity> Which might not be a bad plan.
<pitti> yay, shadow builds
* mdke_ curses sed.
<mdke_> I need to go through a document and replace '<!ENTITY language "C">' with '<!ENTITY language "$i">', but for some reason sed won't let me, saying "bash: !ENTITY: event not found". Does anyone know what the problem is?
<infinity> fabbione: perl suite passes on sejong.  You may have a Niagara-specific bug there, or random bogons.
<fabbione> infinity: so it seems.. yes
<infinity> mdke_: Quoting.
<infinity> mdke_: sed -i -e 's/<!ENTITY language "C">/<!ENTITY language "$i">' file
<infinity> mdke_: (works for me anyway)
<infinity> mdke_: Unless you wanted your shell to expand "$i"... I assumed it was a literal string. :)
<mdke_> infinity: yeah, I want it to expand $i.
<tfheen> mdke_: sed -i -e 's/<!ENTITY language "C">/<!ENTITY language '"$i"'>' file should work then
<mdke_> aha. That quoting thing is weird.
<infinity> But with another /
<Kamion> mdke_: you're running into bash's history expansion
<infinity> And some backslashes.
<mdke_> Kamion: you sort of explained it yesterday but I didn't get it 
<Kamion> ! is special unless escaped by \ or single quotes; double quotes aren't enough
<infinity> 's/<!ENTITY language "C">/<!ENTITY language '\"$i\"'>/'
<mdke_> infinity: ok, trying!
<Kamion> personally I turn off that history expansion using 'set +H' because I prefer readline history handling and like using 'shopt -s extglob' (stuff like !(foo|bar*) to expand to all files except foo or those that begin with bar)
<Kamion> but you might as well get the quoting right anyway
<pitti> good morning Kamion 
<Kamion> morning
<pitti> infinity, tfheen: http://people.ubuntu.com/~pitti/tmp/shadow.ftbfs.patch fixes shadow FTBFS
<Kamion> infinity: I would've done 's/<!ENTITY language "C">/<!ENTITY language "'$i'">/'
<Kamion> and actually, no, that's not right, what if $i contains spaces
<Kamion> 's/<!ENTITY language "C">/<!ENTITY language "'"$i"'">/'
<mdke_> gosh
<pitti> infinity, tfheen: I checked binary debdiffs, 1.9 makes no difference
<infinity> Kamion: I doubt it would in this case. (and the backslashes were just the fastest way between tfheen's and something that worked, not how I would have written it) :)
<pitti> infinity, tfheen: and, of course, I did a functionality test
<Kamion> pitti: ugh, but fine
<Kamion> infinity: :-)
<pitti> Kamion: yeah, 'ugh' was my first reaction too. Yay for packages doing dynamic autoreconf'ing :/
<tfheen> pitti: approved.  And ugh.
<pitti> I guess this style of patch works for other gettext fallout, too, I found some hints on Debian BTS and MLs
<Kamion> on the upside, it made the diff less horrible than it might have been
<mdke_> infinity: works, yippee!
<pitti> Kamion: weeel, with static patches we wouldn't need to fix it in the first place :)
<Kamion> true :)
<pitti> uploaded
<infinity> pitti: Wait, err.  Fuck.  Anything using automake1.7 is going to break?
<infinity> pitti: I don't like the sounds of that.
<pitti> infinity: well, anything using gettext 0.15, automake 1.7 *and* doing dynamic autoreconf is likely to break
<pitti> many packages don't autoreconf at build time and should be fine
<infinity> Also, nice UTF-8 TM in the changelog.
<infinity> Freak. :)
<pitti> infinity: that's why I think another rebuild test is a good idea :/
<infinity> Yeah, I've already requested elmo do another import of the current archive and we'll re-do it.
<pitti> infinity: /me  vim's compose key
<mdke_> morning dholbach 
<tfheen> infinity: can we have monthly rebuild tests or something for edgy+1?
<infinity> tfheen: This is an LP spec that was meant to be done during the edgy cycle.
<dholbach> good morning
<dholbach> hey mdke_
<infinity> tfheen: But, if I can't get priority for it in UDS-MV, we'll have to look at doing it the dak way.
<infinity> tfheen: Cause the current situation sucks.
<fabbione> tfheen: i was going to suggest each time we change linux-libc-dev and a week before each milestone
<tfheen> fabbione: milestones are every two to three weeks.
<tfheen> so that's a bit on the too often side.
<infinity> TBH, if it was in LP, we could just do rolling rebuilds.
<fabbione> tfheen: so? .. CPU cycles are "cheap"
<infinity> Nevermind schedules.
<infinity> We have the buildd power to just rebuild forever.
<infinity> Which is what I'd prefer.
<tfheen> infinity: I care less about whether it's in LP/dak; I do care more about that we don't end up in this situation again.
<fabbione> or that
<cbx33> can anyone confirm if the beta nvidia driver is going into edgy?
<seb128> cbx33: beta driver?
<fabbione> cbx33: no it's not
<infinity> cbx33: Well, the root hole does make it "attractive", but we'll see.
<seb128> cbx33: beta doesn't sound something for a stable distro
<cbx33> seb128: no I know hat
<cbx33> was thinking in light of the root hole as discussed
<fabbione> root hole?
<infinity> http://download2.rapid7.com/r7-0025/
<Kamion> fabbione: buffer overflow in the binary nvidia driver
<fabbione> Kamion: oh ok
<Kamion> exploitable by random web page
<tfheen> can't really say I'm surprised.
<pitti> tfheen: well, it was hard to avoid anyway in this case; we synced gettext, like, three days ago?
<fabbione> hmm annoying
<Kamion> tfheen: kicking off some CD builds
* fabbione switches to wget
<tfheen> pitti: yes.  I want a proper toolchain freeze for edgy+1.  And a pony.
<pitti> Kees poked in the assembly a bit, but in the end we'll have to rely on nvidia 
<cbx33> :(
<pitti> fabbione: if you encounter similar build failures, feel free to toss them to me; I'll have some time for them while testing the CDs
<pitti> tfheen: did you disable daily CDs? the daily ones should be there by now, but aren't
<Kamion> pitti: 08:33 < Kamion> tfheen: kicking off some CD builds
<Kamion> (yes, the cron jobs are off)
<pitti> aah
<Kamion> I noticed that the same way. :-)
<pitti> ok, time for some breakfast then, bbl
<cbx33> sorry to seem like I'm banging on about this....does anybody use the nvidia drivers here? - I'm thinking about using the ones from the nvidia site, but is it possible to go back to the repos at a later date?
<fabbione> pitti: yeps will do
<fabbione> pitti: i only did 20% of main in the last 3 hours (pkg numbers).. so it might take up to tomorrow morning to finish *
<Hobbsee> hey jono!
<seb128> cbx33: use the nv driver ;)
<Treenaks> seb128: does that support multi-monitor setups?
<seb128> Treenaks: you are asking the wrong person, I've no multi-monitor and no idea on the topic :)
<Fujitsu> seb128, that's the wrong answer. The correct answer is `Don't buy NVIDIA!'
<Treenaks> Fujitsu: too bad, my boss did it..
<cbx33> seb128: well, I have the slight problem of liking beryl :p - and wanting to play a few games through wine - mainly because my brother - in - law is having a LAN party
<cbx33> Fujitsu: what do you suggest instead....
* cbx33 is fairly clueless here
<cbx33> intel?
<Fujitsu> cbx33, I don't care about anything like that. I'm a console person, so whatever.
<Fujitsu> I am currently using an i915, yes.
<tfheen> you can't get amd64s with intel graphics..
<seb128> I'm happy with my radeon card
<cbx33> I've never had a problem with nvidia thus far.....I know it's all binary drivers and that.......but, I guess, somethings I live with....my main joy is that I'm now totally windows free
<cbx33> :D
<seb128> games with wine, that's not optimal :/
<seb128> what games are you running with it?
<mnepton> Intel graphics are no guarantee of proper Linux support. there are Intel certification machines all over this office with half-working or completely b0rken hardware.
<Fujitsu> mnepton, but they work properly at the moment with FOSS drivers.
<cbx33> seb128, CS:Source
<cbx33> works pretty well actually.
<cbx33> I get between 30-50 fps
<mnepton> Fujitsu: not all of them do.
<cbx33> on 1024x768 with most settings on high
<mnepton> Fujitsu: in fact, the i845 doesn;t work at all without a third party patch
<cbx33> I was pretty pleased with it actually ;)
<mnepton> and the 965? don;t even get me started.
<mnepton> horrendous.
<AnAnt> I got a problem in Edgy, when I proprietry software, I get this error:
<AnAnt> Error: Could not create FontSet for font '-adobe-helvetica-medium-r-normal-*-12-*-*-*-*-*-*'.
<AnAnt> The following character sets cannot be drawn with this font:
<AnAnt> according to xfontsel, I do have that font.
<AnAnt> this software used to work in Dapper
<Kamion> pitti: at least the Ubuntu images are available now
<tfheen> Kamion: doing livefs-es too?
<Kamion> yes
<Kamion> oh, er
<Kamion> no
<Kamion> same thing :)
<Kamion> ok, sigh, guess I'd better do those ...
<pitti> Kamion: thanks, /me cranks up jigdo and rsync
<Kamion> pitti: you'll have to just upgrade ubiquity to 1.2.3 on the fly to test that
<pitti> oh, it didn't make it? sure, no problem
<Kamion> forgot that the livefs cron jobs were also turned off
<pitti> tfheen: hm, maybe it's time to start using the testing matrix?
<Kamion> terranova.buildd starting at Tue Oct 17 09:03:11 BST 2006
<Kamion> terranova.buildd finished at Tue Oct 17 09:04:28 BST 2006
<Kamion> uh, that doesn't look good
<Kamion> E: Couldn't find task ubuntu-standard
<Kamion> DOH
<Kamion> infinity: please change all *-standard tasks in livecd.sh to just 'standard'
<tfheen> pitti: yes, can you please clean the grid for me?
<pitti> sure
<tfheen> thanks
<tfheen> (I'm in the middle of fixing up a few things on lithium and need to take the puppy out for a minute.)
<pitti> I cleaned up the bugs yesterday
<Kamion> oh, I need to bump debian-cd to RC, don't I ...
<pitti> will set the current images to 20061017 for now
<tfheen> Kamion: I did yesterday
<Kamion> tfheen: please tell me when you change code so that I can merge it
<tfheen> if it's just the OFFICIAL thingy.
<Kamion> yes
<tfheen> Kamion: ok; sorry.
<Kamion> but thanks
<infinity> Kamion: Yessir.
<infinity> Kamion: Should I s/ubuntu-minimal/minimal^/ while I'm at it?
<tfheen> Kamion: put a bzr diff into the daily-checks script?
* infinity does so.
<infinity> Kamion: Okay, try now.
<Kamion> infinity: um, not sure about minimal, maybe best to leave that as the metapackage
<Kamion> trying
<Kamion> tfheen: another qt4-x11 upload in unapproved, from Riddell
<Kamion> +  * Fix typo in debian/rules -qt-sql-slite to -qt-sql-sqlite
<Kamion> +  * Add missing plugin files to libqt4-gui.install and qt4-designer.install
<tfheen> Kamion: approved.
<tfheen> Riddell: what is up with https://launchpad.net/distros/ubuntu/+source/kde-systemsettings/+bug/63325 ?
<Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  
<infinity> Come on, queue-builder.  You can do it!
<Riddell> tfheen: I'm still working on a fix
<infinity> Setting up app-install-data-commercial (6) ...
<infinity> Traceback (most recent call last):
<infinity>   File "/usr/sbin/update-app-install", line 17, in ?
<infinity>     from AppInstall.CoreMenu import *
<infinity>   File "/usr/lib/python2.4/site-packages/AppInstall/CoreMenu.py", line 5, in ?
<infinity>     from Util import *
<infinity>   File "/usr/lib/python2.4/site-packages/AppInstall/Util.py", line 6, in ?
<infinity>     import apt
<infinity> ImportError: No module named apt
<infinity> Is that expected?
<tfheen> I hope not.
<tfheen> mvo: ^^
<Kamion> dholbach: big gnunet change in unapproved that doesn't convince me (if a rebuild's all that's needed, it should just be a rebuild, not a 183K merge including a repackaging, surely?)
<Kamion> dholbach: http://people.ubuntu.com/~cjwatson/tmp/gnunet.diff
<mdz> infinity: context?
<mvo> infinity: kubuntu cd build?
<StevenK> Kamion: Oh damn. So noted, though. Thanks.
<dholbach> Kamion: ok, StevenK: you look after it?
<StevenK> Hum?
* StevenK was talking about his packagesearch upload.
<Kamion> dholbach: StevenK was at very high reply latency
<Kamion> the gnunet upload was from Kai Kasurinen
<dholbach> oh ok
<dholbach> Kamion: I'm not sure I know who that is, I'll try to find out what's going on.
<infinity> mvo: ubuntu livefs.
<infinity> mvo: +build.
<Kamion> dholbach: thanks. if you want to reject it, I'll do so and send mail
<StevenK> Kamion: I tend to check IRC before leaving for work, I didn't this morning.
<infinity> mvo: The postinst doesn't error out, so I assumed perhaps you were ignoring that exit code for a reason. :)
<infinity> mvo: Either that, or there are two bugs there.
<Kamion> infinity: python-apt is configured just a little bit afterwards; I assume app-install-data-commercial doesn't depend on it for some reason
<Kamion> (which might be a bug)
<mvo> infinity: yeah, I don't want the postinst to fail if update-app-install fails, its just a cache, its not critical
<infinity> Right, which would be perhaps two bugs.  Missing dep, and postinst ignoring errors.
<mdz> Kamion: it's g-a-i which contains update-app-install (and that does depend on python-apt) but -data doesn't depend on it
<infinity> mvo: Ahh, kay.  Is the missing dep a bug?
<mvo> infinity: strictly speaking the app-install-data-commercial does not really need python-apt - and when g-a-i is installed (later I presume) update-app-install will be called again and that gives us a valid cache
<mvo> infinity: but it shouldn't make that much noise about it :)
<infinity> mvo: Kay, perhaps just a redirect of stderr then, if you know it's likely to fail and spew.
<infinity> mvo: But hardly critical if the cache is rebuilt later, thanks.
<Kamion> pitti: could you reupload shadow without whatever dpkg-buildpackage -i option you're using to skip .svn? It makes the diff rather noisy
<mvo> infinity: if app-install-data or g-a-i is configured later, then that should be fine
<tfheen> just use -i and it'll DTRT
<Kamion> no, don't
<pitti> Kamion: oh, oops; the filterdiff -x output is on http://people.ubuntu.com/~pitti/tmp/shadow.ftbfs.patch
<Kamion> skip -i altogether to keep the .svn directory there, since it's there already
<pitti> yes, I use -i by default, since it makes diff.gz's annoyingly hard to read and big
<tfheen> oh, point
<Kamion> pitti: yeah, the diff without it is fine, but please reupload with a minimal non-filtered diff so that we don't have merge pain later
<pitti> alright
<Kamion> i.e. just dpkg-buildpackage -S
<Kamion> (I use -i by default too, but turn it off when the package already has revision control junk in it)
<pitti> Kamion: do you reject the current version or shall I bump the version number?
<pitti> s/current version/current upload/
<Kamion> pitti: I'll reject the current version
<janimo> infinity: how recent are the packages on the new liveCDs made in the past hours? I see it does not contain packages uploaded and build yesterday
<Kamion> janimo: see scrollback please
<Kamion> janimo: I forgot that the livefs cron jobs were disabled before building the live CD images; I'm rebuilding the livefses now (which will take a while) and will rebuild images after that
<dholbach> Kamion: 0.7.0e-3 seems to bring the big changes (which is from Debian) (cf bug 66507)
<Ubugtu> Malone bug 66507 in gnunet "[DEBDIFF]  gnunet: merge new debian version" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66507
<janimo> Kamion: just logged in, no scrollback but thanks, will look at the irclogs
<janimo> Kamion: ok, thanks
<Kamion> dholbach: that's the CDBSisation, yes, but this is the changelog for -3ubuntu1:
<Kamion> +  * Merge from debian unstable.
<Kamion> +  * Rebuild fixes missing dependencies (Closes: Malone #66467)
<Ubugtu> Malone bug 66467 in gnunet "Missing dependencies" [Undecided,Confirmed]  http://launchpad.net/bugs/66467
<Kamion> +  * Build with IPv6 support
<Kamion> +  * Use debhelper compatibility level 5
<stub> launchpad is recovered and back on its feet in case nobody has noticed.
<Kamion> +  * Update init script:
<Kamion> +   - create /var/run/gnunetd in init script
<Kamion> +   - support reload
<Kamion> +  * Add Spanish translation
<Kamion> I don't see the justification for that merge
<imbrandon> Kamion, ajmitch asked me to look over it and upload then ask dholbach, i dident see dholbach login so i dident poke him and ajmitch isnt back yet
<Kamion> imbrandon: I think it's a big change with few benefits. What was the rationale for the change rather than simply uploading a rebuild (and possibly fixing the init script to create /var/run/gnunetd as well)?
<imbrandon> Kamion, its not critical imho so rejection is fine with me and i'll revist it +1 but ajmitch might have othere reasons for me to have looked it over
<dholbach> Kamion: ok, reject it, I'll ask for a justification of it.
<pitti> Kamion: uploaded; sorry for the inconvenience
<imbrandon> Kamion, the main change was the merge, a rebuild ( and init fix ) would be sufecent imho , would you rather that or wait for justifcation from ajmitch ?
<Kamion> imbrandon: I'm sending mail to Kai
<pitti> wow, apt-get dist-upgrade on current live CDs wants to suck 117 MB of updates
<Kamion> I'll CC you
<dholbach> Kamion: thanks for that.
<pitti> tfheen: ^ hmm, I think I don't advertise this version on the Testing/Current page yet
<imbrandon> Kamion, ok
<dholbach> tfheen: ok to upload the ubuntu-docs (translations added)?
<Kamion> pitti: yeah, not much point until we've rebuilt the livefses
<tfheen> pitti: the desktop one?  No point, as Colin says
<pitti> right
<tfheen> dholbach: yes.
<pitti> Kamion: ok, ubiquity updated, I'll give it a shot now
* pitti orders more RAM for his poor 256 MB iBook to speed up such things in the future
<dholbach> oh lord, it's bloody huge
<dholbach> pitti: I ordered more ram for an (even older) ppc too :)
<pitti> well, 1 GB more should make a difference
<dholbach> definitely
<imbrandon> pitti, heh i've been using my 800mhz 640mb ram ppc lately , intersting to say the leaste
<imbrandon> definately makes me appreciate my fast build box when i'm on it
<cbx33> is there a quick way in the alternative install for skipping the checking the mirror step?
<cbx33> I'm behind a proxy at the mo....but not where I use it normally
<Chandan> imbrandon, How to build custom ubuntu cd
<ajmitch> imbrandon: yeah, that's why I asked you to look over it before I gave an ok - I wasn't completely present either :)
<imbrandon> ajmitch, right
<ajmitch> all I looked at was the changelog
<imbrandon> ajmitch, no worries, i think its pretyy clear now, hopefull kai will take care of it today, if not i will tonight
<ajmitch> ok 
<Kamion> cbx33: no, sorry
<StevenK> infinity: Oh, I've fixed hat too, but my poor Sparc is too crappy to build it.
<imbrandon> Chandan, there is a howto on the wiki ( http://wiki.ubuntu.com )
<fabbione> StevenK: what fix needs to be tested on sparc?
<cbx33> Kamion: can we come up with something for edgy + 1
<pitti> oh, firefox 2.0rc3
<sabdfl> ok, did the "free the fish" thing, now how do i make it go away for good?
<pitti> sabdfl: killall gnome-panel should do
<sabdfl> thanks pitti
<ajmitch> heh
<pitti> sabdfl: . o O { we should totally have an Ubuntu specific easter egg! }
<sabdfl> free the warthog
<ajmitch> pitti: how close to release will april 1 be next year? :)
<Kamion> cbx33: maybe
<Kamion> cbx33: probably a cancel button, the problem is communicating it to apt
<realist> StevenK: Are you Steve Kemp?
<cbx33> Kamion: ah I see, of course
<cbx33> could apt have a shorter timeout period?
<infinity> cbx33: /whois is your friend.
<infinity> Err.
<infinity> realist: /whois is your friend.
<StevenK> realist: I am not.
<infinity> cbx33: Ignore my inability to read.
<Kamion> cbx33: that wouldn't actually help
<StevenK> fabbione: Not including a file. I can send you the (small) diff, if you like.
<fabbione> StevenK: up to you.. i have a machine up
<cbx33> Kamion: heheh, just shows my knowledge level about it all then :p
<Kamion> cbx33: the shortest timeout period that's sane in the face of stupid network conditions is a minute or two, and you have to multiply that up by the number of repositories apt is contacting by default
<pitti> tfheen: current DVD is 20061014; can you roll new ones for testing, too? (once new livefses are ready)
<Kamion> cbx33: there are two real problems here
<cbx33> Kamion: yeh I get ya!
<StevenK> fabbione: I'd rather know it builds sucessfully rather than just upload it.
<tfheen> pitti: yes, we'll want that.
<Kamion> cbx33: (a) apt doesn't notice that it timed out last time; it could just give up if so
<fabbione> StevenK: ok.. send me the patch then.. as i said.. up to you :)
<Kamion> (timed out on the same host)
<realist> infinity: that depends how friendly people's IRC clients are
<cbx33> Kamion: true
<fabbione> StevenK: i don't mind testing it for you since i offered :)
<Kamion> cbx33: (b) no facility to tell apt to give up now in response to a cancel button
<cbx33> hmmm...
<cbx33> indeed those are big problems
<StevenK> fabbione: How do you want it?
<StevenK> I'd put it on the web, but my webserver isn't booting. :-/
<fabbione> StevenK: mail is fine
<fabbione> fabbione@ 
<StevenK> I figured. :-)
<mdz> Kamion: SIGTERM should do fine for (b)
<cbx33> mdz I was wondering that
<Kamion> mdz: ok, no race conditions there?
<cbx33> then we could have a "skip" button
<Kamion> we already have the (c)debconf facility for a cancel button
<Kamion> oh, er, no we don't here
<StevenK> fabbione: Sent.
<Kamion> the state of the cancel button is only checked at each db_progress command
* StevenK checks if it still builds on amd64.
<Kamion> and at the moment db_progress is only run once per apt-get update
<cbx33> I see there is still the Alt-Tab bug too :(
<Kamion> we'd have to rearrange that and have a sleep loop or something
<Kamion> cbx33: what?
<cbx33> if you press alt-tab anytime there is a progress bar it crashes the whole install
<Kamion> cbx33: nobody has ever told me about that, and I've never seen it
<cbx33> I have LP'd a bug about it
<Kamion> so your "still" is a bit much for me ;)
<Kamion> cbx33: where?
<cbx33> I'll find it hang on
<cbx33> sorry Kamion, wasn't a dig at anyone
<cbx33> just an observation
<Kamion> no, I just hate hearing about bugs for the first time two days before release candidate
<cbx33> https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/47643
<Ubugtu> Malone bug 47643 in debian-installer "Alt + Tab freezes progress bar" [Medium,Unconfirmed]  
<Kamion> gar, wrong package, no wonder
<fabbione> StevenK: go it.. will let you know soon.. i need to reboot this machine first
<Kamion> oh, maybe not
<Kamion> cbx33: this is in the alternate install?
<cbx33> I did mention it in here a few weeks ago
<cbx33> Kamion: yes
<Kamion> ok, I thought you meant in ubiquity
<cbx33> which isn't so crucial
<Kamion> a few weeks ago, I was moving house and not reliably contactable
<cbx33> Kamion no....sorry to have scared you
<cbx33> it came about as I was installing in a VM...and alt-tabbing before I'd ctal+alt'd
<cbx33> but I tried it on "real" hardware and it still happens
<mdz> Kamion: I'm pretty sure it DTRT for the downloads; somewhat less so about the cache updating
<Kamion> yeah, that's the bit that concerns me
<mdz> Kamion: anyway, surely this is one for post-edgy unless there's a newer and more serious issue
<Kamion> mdz: absolutely post-edgy
<Kamion> no way am I messing about with that now
<cbx33> hehe
<Kamion> oh, crap, cdebconf-keystep is broken
<pitti> Testing/Current cleaned, live images marked as obsolete
<Kamion> tfheen: ^-- sorry :(
<tfheen> Kamion: broken how?
<Kamion> tfheen: doesn't accept YES/NO after the (new) FINDP command
<Kamion> so it generally falls over midway through layout detection
<tfheen> ouch.
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/cdebconf-keystep.diff
<pitti> seb128, mvo: I'll test the powerpc alternate variants and some amd64; can any of you test i386 alternate and maybe some amd64, too?
<seb128> pitti: are we in grid test mode already?
* cbx33 just installed a 16 build i386 alternative
<pitti> seb128: I just cleaned it
<cbx33> but I guess you want 17?
<seb128> pitti: I've no alternate iso handy so I need to download them completly, it'll take some hours on my not-that-fast-dsl
<pitti> seb128: desktop is out of date, should arrive within some hours, but alternates should be fine for testing
<tfheen> Kamion: go for it.
<seb128> I do desktop CD testing usually
<pitti> seb128: ah, I see; 
<pitti> seb128: I thought you had an i386 installation
<seb128> desktop CD
<pitti> seb128: (jigdo immensely helps with a good apt cache :) )
<seb128> I'll give it a try :)
<pitti> seb128: but nevermind
<seb128> I'll download them anyway
<seb128> still good to give them some testing
<seb128> and so I can rsync next time
* StevenK coaxes his webserver to boot.
<pitti> Kamion: current desktop with dist-upgraded ubiquity installs the kernel fine and creates an initrd, but doesn't boot
<infinity> Yay, dirty chroots.
<infinity> scim-gtk2-immodule can't be removed.
<pitti> Kamion: 'Loading ramdisk...\nramdisk load failed !', and then I get the OF shell
<sivang> mornig
<infinity> Removing scim-gtk2-immodule ...
<infinity> /var/lib/dpkg/info/scim-gtk2-immodule.postrm: line 8: /usr/sbin/update-gtk-immodules: No such file or directory
<infinity> dpkg: error processing scim-gtk2-immodule (--purge):
<infinity>  subprocess post-removal script returned error exit status 1
<infinity> Anyone want to fix the above?
<pitti> infinity: I'll have a look
<infinity> I suspect it's trying to call it in purge, or something.
<infinity> Cause it looks like the dep should be there for remove.
<dholbach> a dep on libgtk2.0-bin is missing
<Kamion> pitti: can you find out if (a) the initrd link is present in /boot and (b) /etc/yaboot.conf is correct?
<pitti> dholbach: dependencies don't help you in purge
<pitti> Kamion: (a) yes; booting live image right now to find out (b)
<infinity> dholbach: libgtk2.0-0 depends on -biso the dep is fine.
<infinity> s/-biso/-bin, so/
<infinity> Latency is hell on my typing. :/
<pitti> infinity: hm, it calls update-gtk-immodules in 'remove', not 'purge'
<infinity> And another:
<infinity> Removing python-zopeinterface ...
<infinity> dpkg: error processing python-zopeinterface (--purge):
<infinity>  subprocess pre-removal script returned error exit status 1
<infinity> pitti: Hrm, I may have to try to replicate this harder, then.
<infinity> pitti: COuld be something else buggering it earlier.
<pitti> inmI can't see an obvious flaw here
<mdz> infinity: can you confirm that -bin is installed at the time?
<pitti> and it should be legitimate to use dependency on 'remove'
<infinity> mdz: Oh, I'm sure it's not, but I need to find out how the chroot got in that state now.
<infinity> Ineed to add a flag to launchpad-buildd (and the DB) to flag builds where chroots are left dirty.
<infinity> This is the one thing we're missing with the new world order of a fresh chroot for every build.
<mdz> doko: would you have a look at python-zopeinterface?
<infinity> Err, wait.  This one could be an apt bug...
* infinity scratches his head.
<infinity> How is this even possible?
<infinity> Removing libgtk2.0-bin ...
<infinity> Purging configuration files for libgtk2.0-bin ...
<infinity> Removing scim-gtk2-immodule ...
<infinity> /var/lib/dpkg/info/scim-gtk2-immodule.postrm: line 8: /usr/sbin/update-gtk-immodules: No such file or directory
<infinity> It pretty clearly shouldn't let me do that...
<mdz> infinity: unless it's doing --force-depends, things are not as they seem in the dependency chain
<mdz> or else dpkg gets it wrong too, which seems increasingly unlikely
<infinity> scim-gtk2-immodule depends on libgtk2.0-0, which depends on libgtk2.0-bin, but it's removing -bin, then scim, then libgtk.
<mdz> infinity: you're certain that you're looking at the same versions of all packages involved, etc.?
<infinity> Yeah, other than being dirty, the chroot is up to date.
<infinity> Trying to remove the cruft, it always removes in the above order (unless I go one pakcage at a time, obviously, which solves it)
<mdz> dholbach: how serious is bug 66323?
<Ubugtu> Malone bug 66323 in bluez-gnome "Problem report for bluez-passkey-gnome" [Medium,Unconfirmed]  http://launchpad.net/bugs/66323
<dholbach> mdz: it seems to crash - I'm on it, needs extraction of bits out of a patch that upstream sent
<dholbach> (although it didn't crash for me in any of my tests yet)
<mdz> dholbach: it crashes under what circumstances?
<infinity> mdz: Completely reproducible at home with a clean --variant=buildd chroot, "apt-get install scim-gtk2-immodule && apt-get --purge remove [list of packages just installed] "
<mdz> infinity: is there a cycle in there somewhere perhaps?
<mdz> aha
<mdz> libgtk2.0-0 depends: libgtk2.0-bin depends: libgtk2.0-0
<fabbione> StevenK: almost done.. sorry but i had some hell of a crash here
<infinity> Oh, that would do it. :/
<mdz> seb128: why does libgtk2.0-0 depend on libgtk2.0-bin?
<infinity> mdz: So, scim-gtk2-immodule needs an explicit dep on -bin, or the cycle needs to be broken.
<dholbach> mdz: "just like that", upstream's patch also "fixes another problem with the D-Bus proxy handling" (cf bug 65645)
<Ubugtu> Malone bug 65645 in bluez-gnome "Die systray icon die!" [Undecided,Fix released]  http://launchpad.net/bugs/65645
<infinity> (The explicit dep seems sane anyway, since it calls binaries from there)
<cbx33> I asked this question earlier on, does anyone know why nvidia-glx depends on the 386 restricted modules...even if I'm using the genreic modules?
<mdz> an explicit dep would probably do it
<seb128> mdz: because the -bin has the program required for the loaders and modules registration
<infinity> Counting on the transient dep to pull in the binary seems iffy.
<StevenK> fabbione: No problem.
<tfheen> pitti: https://launchpad.net/distros/ubuntu/+source/language-pack-pl/+bug/63344 should be fixed with new langpacks, or?
<Ubugtu> Malone bug 63344 in language-pack-pl "rosetta truncated plural form for pl and that breaks python apps" [Medium,Confirmed]  
<cbx33> and is it a bug, or just a thing!
<mdz> cbx33: as you can see by looking at the package, it doesn't
<infinity> mdz: Even then, the removal order seems suboptimal, but whatever.
<cbx33> mdz, why when I try to install nvidia-glx does it try to pull in the restricted modules then?
<mdz> seb128: but libgtk2.0-0 doesn't seem to call those programs when it's installed or removed
<infinity> mdz: (I'd expect "remove evertthing that depends on libgkt|libgtk-bin, then break the loop arbitrarily"
<infinity> )
<cbx33> but the 386 modules....not the generic modules
<mdz> cbx33: because it depends on having _some_ nvidia module, not any one in particular
<cbx33> ok, so if I install the generic one, it'll be fine
<infinity> cbx33: Because we can't express a "install this if you have that" dependency.
<seb128> mdz: no, libgtk2.0-bin does the registration, but it needs to be installed for that
<cbx33> because it then wants to install the 386 linux image
<cbx33> ok that's fine
<infinity> cbx33: If you explicitely install the ones you want, it'll be fine, yes.
<cbx33> thanks guys
<cbx33> sorry to have troubled you with that one
<cbx33> still learning 0_o
<pitti> tfheen: depends, Rosetta has to export correct PO files first
<infinity> mdz: Anyhow, the immediate fix for the scim thing seems obvious, so I'll fix that.
<tfheen> pitti: ok.  If it's still broken with the final export on Friday, can we just hack around it?
<pitti> tfheen: I'll talk to carlos; yes, I can manually put good po files into the tarball and rebuild the packs
<infinity> tfheen: Permission to upload a scim with scim-gtk2-immodule explicitely depending on libgtk-bin?
<tfheen> pitti: ok, thanks, that's all I wanted to know.
<tfheen> infinity: go ahead.
<seb128> mdz: the circular Depends has been broken to Debian by moving things to libgtk2.0-0, that's not for edgy though
<mdz> seb128: oh, i see
<infinity> mdz: After a full rebuild, the only dirt in the chroots was the scim thing anyway, so the consequences of the loop seem limited.
<infinity> mdz: So we can likely ignore it (with the scim dependency hack).
<mdz> <workrave> daily limit reached
<infinity> Hah.
<mdz> that's even sillier than usual
<infinity> It needs to shut off your machine forcefully at that point. :)
<mdz> it's 1103
<infinity> "Now doing 'cat /dev/random > /proc/kcore', hang on"
* inf1nity has quit (workraved)
* StevenK idly wonders if the kernel allows one to write to /proc/kcore.
<Kamion> mdke_: I'm not wild about sucking an out-of-date version of installation-guide into ubuntu-docs
<Kamion> if you're copying that, it needs to be *automatically* kept up to date
<Kamion> mdke_: oh, am I correct that you aren't building it by default?
<Kamion> (I hope not. It's already in the installation-guide source package, we don't need duplication there)
* infinity attacks the python-zopeinterface one..
<ogra> +extern struct usplash_pixmap pixmap_usplash_640_400;
<ogra> +extern struct usplash_pixmap pixmap_usplash_800_600, pixmap_usplash_1024_768, pixmap_usplash_1365_768_scaled;
<ogra> shouldnt there be a theme for 640x480 as well in usplash-theme-ubuntu.c ?
<ogra> (accor4ding to the changelog there is, but there is no definition in the code)
<ogra> Seveas, mjg59 ?? ^^^^
<sladen> StevenK: you can write to /dev/mem ...
<cbx33> in my latest edgy install, the usplash doesn't fit the screen as it did before
<carlos> tfheen: that's a know bug, I will try to prepare a fix before the final language pack generation 
<cbx33> it runs at 1280x1024 with a 1024x768 window for usplash
<ogra> cbx33, what does /etc/usplash.conf say ?
<cbx33> is that known?
<cbx33> can't say I'm not at that machine now
<mdz> infinity: did this initramfs-tools upload turn on a chunk of maintainer script which had been dormant (and potentially untested), as it sounds?
<sabdfl> is xutils supposed to be bringing in xutils-dev and cpp?
<ogra> so can anybody confirm usplash handles 640x480 as it should ? (did anybody test it ?)
<tfheen> ogra: it works with 640x400 at least.
<ogra> tfheen, yes, i see that in the code, but we'll have tons of users where 7etc/usplash.-conf defines 640x480) all from beta had that iirc
<ogra> */etc/usplash.conf
<tfheen> ogra: on amd64 or in general?
<ogra> in  general
<jamesh> does anyone else have problems with truetype fonts not being registered with the old X font system in Edgy?
<tfheen> ogra: well, it ought to work, but I haven't tested.
<ogra> we had a bug in usplash that made these values default to 640x480
<jamesh> I reported a bug about it here: https://launchpad.net/bugs/66360
<Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Undecided,Unconfirmed]  
<tfheen> oh, gnr.  my usplash-theme-ubuntu upload is (slightly) broken.  I removed the update-initramfs call in postinst.
<ogra> ouch
<tfheen> infinity: did you fix that before accepting it or should I upload a new one?
* ogra is not sure he likes to take that usplash theme patch without knowing that 640x480 runs with it ... 
<infinity> tfheen: I didn't notice that in the diff, no...
* ogra goes testing
<sladen> sabdfl: xutils used to depend on imake, which is now provided by xutils-dev.  debatable, perhaps the naming could be better
<infinity> mdz: It was code that was previously testes (and is necessary) in the postinst, and it moved to preinst, hence taking the "configure" test with it (which should now be "install")
* infinity goes to eat some dinner quickly
<tfheen> ogra: which theme patch?  The hack I did in u-t-u last night?
<ogra> yes
<mdz> sabdfl: doesn't sound right, no.  Kamion?
<ogra> tfheen, i know that most of edubuntu testers has 640x480 ... so it would be odd if it wouldnt work 
<ogra> *had
<mdz> infinity: how long ago did it move?
<tfheen> ogra: well, that was just grabbing the dapper artwork and making it look _slightly_ less shit.  No need for it in other packages, I'd guess.
<ogra> tfheen, well, if i want edubuntu usplash themeing, i should have a matching theme for the size :)
<ogra> so i'll have to adjust u-t-e
<ogra> and i guess the others as well
<Seveas> ogra, I'm working on the ubuntu theme right now
<ogra> Seveas, can you provide a proper pacth that i can apply to usplash-theme-edubuntu.c ? i'll care for the artwork
<StevenK> fabbione: Any news?
<Seveas> will do
<ogra> thanks !
<ogra> :)
<fabbione> StevenK: it's building..
<StevenK> fabbione: Ah.
<fabbione> StevenK: the machine has average load of 48.. please be patiente :)
<StevenK> It took 17 minutes on my amd64, so I shouldn't be impatient.
<tfheen> Seveas: please make sure to remove my # from the "update-initramfs" line.
<cbx33> ogra: shouild that sound issue in ubuntu be fixed now?
<Seveas> tfheen, heh, you hate that too when testing>
<Seveas> ?
<tfheen> Seveas: no shit. :-)
<infinity> mdz: The bug was merged in July, and fixed in Debian after that.  It only affects new installs (and only in ways you'd notice if you were looking for them, I suspect), so I'm guessing no one really noticed.
<ogra> cbx33, with the new ltsp-server package
<mdz> infinity: new installs like every beta install?
<infinity> mdz: Half the code if for mkinitrd -> mkinitramfs migration (so not a big deal anymore anyway, I suppose), and the other half is RESUME configuration, which is handled by ubiquity and d-i if you're using "proper installatoin methods".
<cbx33> ogra: ok...i'll investigate..
<mdz> wouldn't this cause RESUME not to be set properly on all of those?
<infinity> mdz: The code is meaningless to most people, IOW.  But still should be there and should work.
<ogra> cbx33, i still cant reproduce it btw, i made various tests on the weekend
<cbx33> that sux...
<sivang> can anybody take a look at http://librarian.launchpad.net/4862302/buildlog_ubuntu-edgy-ia64.debtags-edit_1.1.3build1_FAILEDTOBUILD.txt.gz , seems odd as I can install libapt-front-dev on my local edgy.
<infinity> mdz: But it's a straight cut'n'paste of the old postinst (and well-tested in Debian), so I'm confident it's all good.
<cbx33> i can tell you it's still happeneing here
<cbx33> though I need to update my ltsp chroot
<ogra> nah ... its a gstreamer issue (server sided)
<infinity> mdz: (I also passed it by Kamion and tfheen for review before accpeting it)
<cbx33> ogra: oh...then it still seems present
<ogra> cbx33, did you see that ? http://developer.novell.com/wiki/index.php/Edgy/HOWTO:_PulseAudio
<mdz> infinity: I'm trying to understand the impact of the original problem
<cbx33> ogra: no...oooooooooooooh !
<ogra> :)
<ogra> skype via ltsp :)
<mdz> infinity: the code which used to be in the 'configure' block includes more than just the initrd migration; it sets RESUME, no?
<cbx33> will we be moving to pulse?
<ogra> (and without local apps)
<ogra> yes
<cbx33> nice
<cbx33> is local apps planned for edgy + 1
<ogra> rather +2
<ogra> we'll need a network auth system in place first
<ogra> getting that running properly out of the box will take most of edgy+1 development i guess
<cbx33> right
<StevenK> sivang: I had a look at the build log for libapt-front on ia64, and it blows up violently, and I don't know enough C++ to diagnose.
<StevenK> sivang: The same thing is affecting my packagesearch upload.
<sivang> StevenK: interesting. from what I can see it looks like a libapt-front-dev mis-version dependency ? 
<sivang> StevenK: libapt-front-dev: Depends: libtagcoll-dev (< 1.6) but 1.6.3-1 is to be installed
<StevenK> sivang: The new version built on everything bar ia64.
<StevenK> Um. New version of libapt-front
<sivang> yes, I see
<StevenK> If libapt-front is fixed, both debtags and packagesearch should deal with a give-back on ia64.
<sivang> StevenK: hmm, maybe dropping the << specification would help:
<sivang> StevenK: Depends: libtagcoll-dev (>= 1.6), libtagcoll-dev (<< 1.7), 
<doko_> ajmitch, dholbach: please approve http://people.ubuntu.com/~doko/edgy/optcomplete.debdiff
<doko_> mvo: ping
<sivang> (from libapt-front-0.3.9ubuntu5/debian/control)
<StevenK> Ah.
<dholbach> doko_: looks good :)
<StevenK> sivang: It builds on everything but ia64, though...
<sivang> StevenK: maybe only there the version is higher?
<sivang> anyway, gotta run for now
<StevenK> Doesn't seem to be.
<fabbione> StevenK: it's  still building.. but i need to go offline for one hour or so.. i will ping you back once i am here again
<mdz> ogra: can you confirm bug 63303?
<Ubugtu> Malone bug 63303 in gnome-power-manager "No sleep button in edgy?" [Critical,Confirmed]  http://launchpad.net/bugs/63303
<StevenK> fabbione: No problem.
<StevenK> fabbione: Thanks for your help. :-)
<fabbione> StevenK: no problem.
<Kamion> sabdfl: xutils is a transitional package, and we'll move away from it once we have time; the naming is not ideal
<ogra> mdz, yes, i can confirm at least that the key is set to "nothing" in our default setup ... 
<ogra> mdz, its a one line change if i should enable it again ... but it was like that in dapper already
<mdz> ogra: really?  my sleep key works
<mdz> ogra: why is it disabled by default?
<mdz> i don't remember using gconf to enable it either
<ogra> i think it went hand in hand with a patch from Kinnison 
<pitti> ugh, automatic keyboard detector is broken on alternate, it just loops
<Amaranth> In dapper when you tried to tell gnome-power-manager to suspend on some event it popped up a warning dialog telling you it doesn't work everywhere
<sabdfl> ok kamion - was just checking because it pulled 5mb of CPP into my Xubuntu setup
<Kamion> bringing in cpp is not ideal, but I'm not sure that's fixable right now
<Kamion> xutils-dev is one big package (that was a merge from Debian), depends on cpp, and includes stuff that used to be in xutils
<mdz> pitti: targeted bug please
<pitti> yep, was about to do it
<ogra> mdz, oh, the kinnison patch added a row in the pulldown menu of the UI that set this key, its incompatible with the 2.16.X UI changes of g-p-m ... 
<jdub> Kamion: shouldn't that be changed to mcpp?
<Kamion> jdub: only if whatever uses it can actually cope with mcpp. I have not checked
<jamesh> sabdfl: X resource files get preprocessed by cpp, so a CPP implementation is necessary
<jamesh> Kamion: xrdb should handle it fine ...
<Kamion> jamesh: it's not for X resource files
<Kamion> xrdb is a separate package
<jamesh> ah.
<Kamion> it's for one of ccmakedep, imake, lndir, makedepend, or makeg
<Kamion> probably imake
<mdz> ogra: so it is a regression in fact
<ogra> mdz, so should i change the default for the gconf key to "suspend" ?
<mdz> ogra: why was it set otherwise in the first place?
<Kamion> the only reason I made that xutils upload was that xbase-clients, xlibs-dev, and xutils weren't being built by any source and yet were (build-)depended on by other packages, which was an archive consistency error
<mdz> ogra: is that the default upstream?
<Kamion> I didn't particularly want to end up being responsible for xutils-dev in the process ;-)
<Kamion> s/xutils upload/xorg upload/
<ogra> mdz, well, Kinnison would know ... i think there was a problem that it wasnt selectable at all ... 
<mdz> mjg59: can you think of any reason why that was so?
<mdz> it doesn't make any sense to me but I'm wary of changing the default at the 11th hour if it was done for a reason
<ogra> there was an UI element before ....
<siretart> yay, nvidia we love you! http://download2.rapid7.com/r7-0025/
<ogra> you coul dchange it to 2suspend" via the settings ... which is not possible in the 2.16.x UI
<mdz> ogra: regardless of the UI it doesn't make sense to disable it by default
<ogra> the initial problem was that the suspend button didnt work for everyone ...  if that has changed we should take upstream defaults "suspend"
<mdz> ogra: please revert to the upstream default
<ogra> it does, as long as you can enable it :)
<ogra> yup
<infinity> mdz: It does both the migration and sets RESUME, yes, but our installer(s) also set RESUME in their own fashion so the problem is only visible if you're installing initramfs-tools outside the installer.
<tfheen> mdz: any suggestions on what we should do with the NM bug? bug 63975
<Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
<mdz> infinity: oh? I thought we intentionally moved that from the installer to initramfs-tools
<mdz> tfheen: the one with the unhelpful summary?
<tfheen> mdz: I'm inclined to just untarget it since it's so late.
<infinity> mdz: Which, since it's not a base package or anything, is perfectly doable, both by Ubuntu users, and by derivatives, but not a normal use case for the average "using  aCD" folk.
<tfheen> mdz: that's an accurate description, yes.  The problem is ndiswrapper and n-m aren't friends, it seems.
<infinity> mdz: I can't be positive if d-i still does it (Kamion?), but ubiquity clearly must, since the RESUME partition is chosen long after initramfs-tools has been installed.
<infinity> mdz: Anyhow, I spent a day in vmware, doing install tests and upgrade tests, full-well realising how close we were to RC, and it all seems quite happy with itself.
<mdz> tfheen: definitely not an issue for RC, but worth keeping on the radar if we can get an authoritative opinion on it
<mdz> tfheen: the attached patch does more than just disable the ndiswrapper bits
<pitti> mdz, tfheen: do you deem bug 66532 as important enough for edgy milestone? (this worked until recently)
<Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66532
<mdz> pitti: yes
<mdz> pitti: does it work on the desktop CD?
<tfheen> mdz: it fixed the issue for a friend of mine who needs ndiswrapper, so I know it's not _totally_ broken at least.
<pitti> mdz: I'll check in half an hour, both of my boxes are busy with alternate installs
<tfheen> mdz: but then, I'm wary of doing uploads of any packages we don't have to at this point.
<mdz> tfheen: even if it fixes that particular issue, the fact that it does more than what is described makes me disinclined to trust it
<mdz> if ndiswrapper is the issue, then we should change only that
<tfheen> mdz: http://librarian.launchpad.net/4821656/nm-patch seems fairly clean, though?  It does move a bit of code from a later patch to the workarounds patch, but that doesn't change functionality.
<mdz> -+	else if (!strcmp (kernel_driver, "ndiswrapper"))
<mdz> -+		wpa_driver = "ndiswrapper";
<mdz> ++	else if (!strcmp (kernel_driver, "hostap_pci") || !strcmp (kernel_driver, "hostap_cs") || !strcmp (kernel_driver, "hostap_plx"))
<mdz> ++		wpa_driver = "hostap";
<mdz> those look like entirely unrelated changes
<Q-FUNK> it appears that 'upstart' cannot be used on a host with mixed pinned APT.  it lacks the "Essential: Yes" header in the control file.
<tfheen> mdz: it moves the later changes from debian/patches/11-j-hostap-supplicant-driver.patch ; probably somebody who used dpatch-edit-patch and wasn't careful enough.
<mdz> oh, I see
<mdz> tfheen: if that's cleaned up so that the only change is the ndiswrapper bit, I'm OK with that
<tfheen> mdz: ok.  Now or post-rc?
<mdz> tfheen: now, unless we're otherwise ready to build candidates
<pitti> carlos: can you please take a look at bug 63344? it would be nice to fix the export by Friday
<Ubugtu> Malone bug 63344 in language-pack-pl "rosetta truncated plural form for pl and that breaks python apps" [Medium,In progress]  http://launchpad.net/bugs/63344
<carlos> pitti: I'm already on it, it's a duplicate of #2322
<pitti> carlos: splendid, thanks!
<ogra> tfheen, mdz, http://people.ubuntu.com/~ogra/g-p-m.debdiff (just testbuilding)
<infinity> mdz: Nah, there are still builds trickling in and such, one more publisher run or two won't hurt (especially if someone drives by hand)
<mdz> ogra: ok
<mdz> infinity: rumour has it that the publisher is much faster now
<infinity> tfheen: And yes, I can drive LP by hand for a while tonight, just say the word if you want speed.
<infinity> mdz: Yes, hnce why driving by hand is a win now.
<infinity> mdz: One a good day, it can complete in 20-25 mins.
<mdz> it was a win before, too
<infinity> It was less of wa win when it was hobbling along at the 45 minute mark. :)
<zul_> infinity: pong
<infinity> responseTime++
<tfheen> ogra: approved.
<infinity> zul_: Will you be around for ~10 mins?  I'm running to 7-11 for iced coffee and other such necessities. :)
<zul_> infinity: sure
<ogra> tfheen, great, i'll upload as soon as i know it builds properly :)
<infinity> (literally running)
* madduck kicks  in the shins
<madduck> aye
<madduck> sorry. this was *totally* unwanted
<jdub> http://weihwa.feedback.googlepages.com/seriesoftubes
<tfheen> mvo,doko: https://launchpad.net/distros/ubuntu/+source/gcj-4.1/+bug/64395 ; what's up here?  
<Ubugtu> Malone bug 64395 in gcj-4.1 "Update manager aborts on eclipse-platform-gcj when updating from Dapper to Edgy" [Undecided,Unconfirmed]  
<tfheen> it's targetted for 6.10
<mdz> last I heard they were unable to reproduce it
<tfheen> Kamion: https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/66533 should be fixed by new cdebconf-keystep?  Requires yet another d-i upload?
<Ubugtu> Malone bug 66533 in debian-installer "keyboard detection loops" [Undecided,Unconfirmed]  
<Kamion> infinity: d-i (specifically base-installer) still does it
<Kamion> tfheen: correct, same issue I saw
<tfheen> Kamion: are you on top of https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/66532 too?  (If you're already watching the RC list, tell me and I won't nag you)
<Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  
<doko_> tfheen: unreproducible for me; gij-4.1 depends on libgcj7-0, it's unclear why the library is not found
<tfheen> doko_: are there circular depends involved?
<doko_> in gij-4.1? no
<Kamion> tfheen: only just saw it, will investigate
<Kamion> tfheen: if you didn't see, powerpc ubiquity is still broken
<Kamion> tfheen: I'm proposing this change to ubiquity/scripts/install.py to fix it:
<Kamion> -            self.chrex('update-initramfs', '-u')
<Kamion> +            self.chrex('update-initramfs', '-c', '-k', os.uname()[2] )
<tfheen> Kamion: for all arches or just ppc?
<Kamion> just powrpc
<Kamion> powerpc
<Kamion> I've tested the above change on i386
<Kamion> pitti is going to test it on powerpc
<tfheen> ok; go ahead.
<tfheen> looks good to me
<Kamion> sabdfl: will you be able to make the CC meeting today? I would like to be excused on the grounds that I need my full attention for the multiple edgy-RC issues I'm trying to deal with at the moment
<Kamion> I don't know if mako can be there, thoug
<Kamion> h
<Kamion> so if I need to be, so be it
<doko_> tfheen: please approve http://people.ubuntu.com/~doko/edgy/python-central.debdiff
<tfheen> doko_: looks good to me.
<mdz> tfheen: that was fast; I hadn't even finished reading it yet
<doko_> tfheen: ok, waiting for mvo to have a small review
<tfheen> doko_: yeah, I was going to add "but I don't know python-central, so it'd be good to have somebody else look at it too"
<pitti> weird - I could have sworn http://cdimage.ubuntu.com/daily[-live] / had 20061017 this morning
<mdz> pitti: and now?
<infinity> doko_: Will that fix the zope removal bug?
<infinity> (looks like it should..)
<ogra> mdz, 20061016
<tfheen> doko_: have either of you been able to reproduce the problem?
<doko_> infinity: zope removal?
<mdz> pitti: lithium has 20061017
<ogra> (seems we're moving backwards in time :) )
<mdz> problem with one of the mirrors perhaps?
<infinity> [...] + read t n
<infinity> + case "$t" in
<infinity> + rmdir --ignore-fail-on-non-empty /usr/lib/python2.3/site-packages/zope/interface/common/tests
<infinity> dpkg: error processing python-zopeinterface (--purge):
<infinity>  subprocess pre-removal script returned error exit status 1
<pitti> mdz: only 20061016 for me
<infinity> doko_: ^^^ While removing python-zopeinterface from chroots.
<mdz> pitti: it shows 20061017 for me
<mdz> on cdimage as well
<infinity> doko_: Looks like pycentral is involved somehow.
<pitti> weird, not for me
<pitti> $ host cdimage.ubuntu.com
<pitti> cdimage.ubuntu.com has address 195.248.90.25
<pitti> cdimage.ubuntu.com has address 195.248.90.24
<doko_> infinity: do you have a log?
<ogra> for me neither
<infinity> doko_: I'll put the whole output online.
<pitti> mdz: ah, .25 has the latest image for me, .24 not
<mdz> pitti: .24 is out  of date, e.25 is ok
<ogra> weird
<infinity> doko_: I just added set -x to the prerm before purging.
<tfheen> mdz: http://err.no/patches/network_manager_remove_ndiswrapper_specialcase.diff
<mdz> yep
<mdz> elmo: see above; one of the cdimage mirrors has a problem
<tfheen> mdz: I have at least one verification that binaries built with that patch works where the current edgy version doesn't.
<mdz> tfheen: looks good
<infinity> doko_: http://cerberus.0c3.net/~adconrad/argh.log
<cbx33> 20061016 for me
<tfheen> mdz: thanks; uploaded.
<janimo> Riddell: is the kubuntu human theme shipped by hk-default-settings?
<janimo> s/hk/kubuntu/
<elmo> mdz: fixing
<elmo> I don't suppose someone could fix LP #24519, could they?  It's a trivial patch and cricket is pretty useless without it
<janimo> bug 24519
<Ubugtu> Malone bug 24519 in cricket "cricket: Completely broken with latest rrdtool package 1.2.11-0.4" [Unknown,Fix released]  http://launchpad.net/bugs/24519
<elmo> how does that thing not recognise "LP #" yet? :P
<rideout> dholbach: since Riddell is not here, could you fix the qt4 packages, Riddell submitted a new version, but included a few makefiles that should have been generated and thus the build failed. I can explain the changes that need to be made
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/localechooser.diff for bug 66532
<Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66532
<StevenK> Heh, there's a bug in Ubugtu too.
<StevenK> It reports [Unknown,Fix released] , but that's the Debian status
<Kamion> without that patch it goes "process preseeding, fetch previous language, ask for language, oh, hey, it's the same as the previous one, don't do anything"
<pitti> Kamion: you rock!
<pitti> fixing bugs faster than I can whine about them
<tfheen> Kamion: ok, looks sane to me.
<ogra> oh, what a bad date to run a CC meeting
<dholbach> rideout: I can have a look at it after lunch - if you give me instructions to a query, that'd be a good start - brb
<janimo> dholbach: hi, I took the liberty of subscribing you to bug 65870 :)
<Ubugtu> Malone bug 65870 in human-cursors-theme "xfce crashes repeatedly after changing icon theme to default" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65870
<janimo> dholbach: as it looks like it is fixable in human-cursors-theme
<mdz> ogra: that reminds me to defer next week's TB
<rideout> dholbach: i'm sending you an email right now
<dholbach> rideout: thanks
<mdz> sabdfl,mjg59,Keybuk: OK with you to not hold TB next week due to the release?
<dholbach> janimo: i'll take a look, after lunch
<janimo> dholbach: bon appetit
<mjg59> mdz: Sure
<mjg59> mdz: Though do we then actually have a TB before our terms end?
<mdz> mjg59: unclear; afaik that's on the agenda for UDS rather than an online meeting
<infinity> Argh.
<infinity> Riddell: qt4-x11 is FTBFS.
<tfheen> didn't the previous version just build?  And this one just changed a depends field?
<ogra> tfheen, infinity, see dholbach/rideout conversation above
<infinity> tfheen: No, this was a new upload after the depends change.
<rideout> tfheen: riddell submitted an unclean build, it had makefiles for his machine, that should be generated by the configure script
<infinity> ogra: Ahh, thanks, I'm not glued to scrollback.
<mdz> tfheen: wasn't a diff submitted for review which only changed a dependency field?
<Kamion> 22:55 < tfheen> I _think_ qt4-x11 is ok; Riddell didn't scream when dholbach uploaded it.
<tfheen> Kamion: and then Riddell said he was happy with it.
<Kamion> unless there was a later one?
<Kamion> oh, yeah, this morning
<Kamion> as soon as LP came up
<infinity> mdz: That was ubuntu3
<infinity> mdz: ubuntu4 was this:
<infinity> 02:24 < Kamion> tfheen: another qt4-x11 upload in unapproved, from Riddell
<infinity> 02:24 < Kamion> +  * Fix typo in debian/rules -qt-sql-slite to -qt-sql-sqlite
<infinity> 02:24 < Kamion> +  * Add missing plugin files to libqt4-gui.install and qt4-designer.install
<infinity> 02:24 < tfheen> Kamion: approved.
<infinity> Anyhow.
<infinity> rideout: Care to post a diff somewhere about how to unbugger this?
<infinity> rideout: I'd like to get it fixed ASAP.
<infinity> Kamion: Do we want the ttf-bpg-georgian-fonts udeb in main?
<infinity> 9Yes, it finally built)
<infinity> s/9/(/
<Kamion> infinity: no
* StevenK waits for fabbione
<Kamion> it's only for d-i/gtk
<StevenK> Er.
<rideout> infinity: i just sent dholbach an email with the fix, here is a copy http://pastebin.ca/206437
<infinity> Kamion: Kay, universifying it, then.
<Kamion> rideout: damn, I noticed that in the queue and should have commented on it at the time
<Kamion> I just assumed it was qmake noise
<rideout> Kamion: somehow "make clean" must have gone foobar on riddells machine
<dholbach> rideout, Kamion: I'll do a testbuild with the fix, then do an upload.
<dholbach> rideout: Thanks a lot for investigatin!
<dholbach> g
<infinity> dholbach: Thanks.
<rideout> thanks
<sabdfl> mdz: fine by me
<infinity> tfheen: Has you n-m upload seen more eyes than your own? (ie: should I accept it?)
<ogra> janimo, /usr/share/icons/default/index.theme isnt in the -cursors-theme package ... 
<tfheen> infinity: mdz was fine with it and I have at least one user whose network it fixed, so I think "yes" is fine.
<ogra> no idea where you got that from, but i dont have it on any edubuntu systems (with -cursor-themes installed)
<infinity> tfheen: Alright, accepting.
<ogra> tfheen, is my g-p-m upload still sitting in the queue ? i dotn see it on -changes
<Kamion> all livefses rebuilt; rebuilding live ISOs
<mdz> infinity: yes, I reviewed it
<tfheen> ogra: I presume so, yes.
<tfheen> infinity: how's the queue looking?
<tfheen> elmo: http://err.no/patches/cricket_read_new_rrdtool_x86.diff makes you happy?
<elmo> tfheen: that'd be great, thanks
<tfheen> elmo: just waiting for Adam to tell me that he's happy with it too, since it touches the server CD.
* dholbach goes back to lunch
<janimo> ogra: it is installed by postinst
<ogra> janimo, not here it seems, neither on upgraded system nor on new installs
<ogra> and it shouldnt btw ... its a theme file that belongs into a theme not into a cursor theme 
<janimo> ogra, do you have human-cursors-theme?
<ogra> yes, we use it by default in edubuntu
<infinity> tfheen: 
<ogra> hmm, i have /etc/alternatives/x-cursor-theme -> /usr/share/themes/Human/cursor.theme
<infinity>   110004 | S- | gnome-power-manager  | 2.16.1-0ubuntu3      | 55 minutes
<infinity>          | * gnome-power-manager/2.16.1-0ubuntu3 Component: main Section: gnome
<infinity>   110003 | S- | optcomplete          | 1.2-5ubuntu1         | 1 hour 20 minutes
<janimo> the file is installed here, and the invocation is there in the source package (0.3)
<infinity>          | * optcomplete/1.2-5ubuntu1 Component: universe Section: python
<infinity>   109987 | S- | gnome-panel          | 2.16.1-0ubuntu3      | 2 hours 10 minutes
<infinity>          | * gnome-panel/2.16.1-0ubuntu3 Component: main Section: gnome
<infinity>   109950 | S- | ubuntu-docs          | 6.10.2               | 3 hours 10 minutes
<infinity>          | * ubuntu-docs/6.10.2 Component: main Section: text
<tfheen> infinity: g-p-m is fine if it's from ogra.
<infinity> tfheen: And yes, please fix elmo's bug, keeping elmo happy helps me keep my job. :P
<infinity> tfheen: It is.
<tfheen> infinity: gnome-panel is from dholbach and updates an URL, ubuntu-docs is a general update, also from dholbach?
<tfheen> if so, approved.
<tfheen> infinity: cricket uploaded.
<infinity> tfheen: ubuntu-docs is from mdke
<infinity>  ubuntu-docs (6.10.2) edgy; urgency=low
<infinity>  .
<infinity>    * Adding translations for all documents
<dholbach> I sponsored it
<infinity> Right, then. :)
* ogra wonders why the debian maintqainer gets mailed as well for the g-p-m upload 
<seb128> just curious, how much spaces do translations take?
<pitti> seb128: you mean, how many langpacks are on the CDs?
<tfheen> Riddell: did you or somebody else target https://launchpad.net/distros/ubuntu/+source/katapult/+bug/49901 and what's happening with it?
<Ubugtu> Malone bug 49901 in katapult "Katapult slows down to a near crawl when amarok is open" [Medium,Confirmed]  
<ogra> do we mail the DD by default now ?
<seb128> pitti: no, the ubuntu-docs upload mentioned some lines up
<pitti> tfheen: speaking about langpacks, many CDs have plenty of space; can I fill them with some langpacks (leaving 10 MB grace space?)
<pitti> ah
<seb128> ogra: the maintainer is giskard
<ogra> seb128, yes
<Kamion> pitti: we haven't done the final langpack update yet
<tfheen> pitti: what Colin says; let's hold it off.
<Kamion> pitti: I'd be a bit reluctant to fill up the CDs until we know how big they're going to be
<pitti> Kamion: right; so Saturday would be a good time
<ogra> seb128, but he's in the To: line of the reciept mail i got from LP
<ogra> that appears wrong to me ...
<Kamion> if we're updating langpacks post-RC anyway, then yes
<giskard> ogra: hey :)
<giskard> hello seb128 :)
<ogra> giskard, yo
<dholbach> seb128: translated ubuntu-docs is HUGE
<giskard> hello dholbach :)
<Riddell> tfheen: I didn't target it
<Kamion> pitti: oh yes, and I'd like to know how big the new ubuntu-docs is going to be ...
<dholbach> hi giskard - changed the nick?
<pitti> Kamion: oh, I thought we agreed to doing this at Friday? if not, how and when do you think we should decide that?
<Kamion> pitti: langpack update = Friday = post-RC
<seb128> hi giskard
<giskard> dholbach: yes :) kristog is deprecated ;)
<seb128> dholbach: how huge?
<dholbach> Installed-Size: [-2192-]  {+31352+}
<Riddell> tfheen: in the comments mez says he's working on a patch, but I don't consider it a major issue
<Kamion> dholbach: what about Size?
<seb128> dholbach: and the .deb ?
<pitti> Kamion: ah, I misinterpreted the 'if', sorry
<dholbach> the debs went from: 327544 to 5287886
<seb128> utch
<Kamion> pitti: sorry, yes, s/if/since/
<ogra> seb128, i'm not worried about the fact giskard gets the mails for my uploads, i'm just wondering if any ulpoad i do now generally mails the DD
<seb128> ogra: ah, that would be weird
<ogra> yes
<giskard> ogra: feel free to mail for important changes 
<tfheen> Riddell: Unless you mind, I'll untarget it, then?
<ogra> giskard, you're getting the reciept mails from launchpad anyway it seems
<Kamion> well, we do have space for that extra 5MB for Ubuntu at present
<giskard> ogra: yeah :)
<Kamion> I'd be inclined to accept it since we were only going to fill it up with translations anyway, but I'd like to hear from the rest of the release team too
<Kamion> dholbach: can you check to make sure it doesn't contain the installation guide?
<Kamion> that's in the source, but shouldn't be in the .deb
<Riddell> tfheen: fine with me
<Kamion> tfheen: is anyone doing anything with that imake upgrade bug?
<Kamion> tfheen: actually I wonder if it will go away for most people due to xutils depending on xutils-dev
<Kamion> I think that might have been why it broke
<tfheen> Kamion: I though mvo was going to do it?  Or it should go away as you said.
<Kamion> aha, yes, old xutils had:
<Kamion> Depends: imake (>= 1:1.0.0) | xmkmf
<Kamion> so the Provides wouldn't have been enough
<Kamion> xutils was imake's only rdepends
<dholbach> Kamion:   grep -i install /var/lib/dpkg/info/ubuntu-docs.list    only lists bits in the desktop-guide and server-guide
<tfheen> ogra: you're aware of https://launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/60442 ?
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  
<ogra> tfheen, "... partially diagnosed upstream ..." doesnt seem like a RC exception bug to me
<Kamion> dholbach: ok
<Kamion> thanks
<dholbach> de rien
<Riddell> dholbach: are you working on qt4?
<infinity> seb128: You around?
<seb128> infinity: yep
<dholbach> Riddell: yes, did the suggested fix and now it's testbuilding
<infinity> seb128: https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/9208
<Ubugtu> Malone bug 9208 in gnome-system-tools "Samba upgrade failure due to broken rc.d symlinks" [High,Fix released]  
<seb128> ah, that bug
<seb128> we have it since hoary or something like that
<infinity> seb128: Are you familiar enough with the g-s-t source to know A) how that bug was originally happening, and B) how it's *still* happening?
<infinity> seb128: All the grep-fu in the world, and I still can't nail it down.
<infinity> seb128: And I can't reproduce it to save my life, though users get bitten by it all the time.
<seb128> infinity: g-s-t is only the fronted, the code is to system-tools-backend probably
<infinity> (of course, none of them know HOW they're being hit by it, since it's a sleeper bug, so cause and effect are tough)
<mvo> tfheen: wasn't rodarvus going to add a transitional package to fix the imake upgrade problem? at least I thought so 
<seb128> system-tools-backends rather
<Kamion> mvo: I think it may not be necessary any more
<Kamion> mvo: xutils used to versioned-depends: imake, but now depends: xutils-dev
<Kamion> I think that might be enough to fix it
<seb128> infinity: I'm not sure it has been fixed though
<mvo> yeah, that sounds good. I will do a dist-upgrade test to verify that
<Kamion> mvo: I can do one here
<cbx33> hmm....my tosh laptop won;t recognise when the ac power is disconnected
<Kamion> and/or you can, if you prefer
<infinity> seb128: I'm positive it hasn't been fixed. :)
<ogra> tfheen, the battery_status_changed_primary() function needs to be rewritten, i dont think thats something we want to do now ... and i dont see why this is a regression from dapper ... it seems it never handled that right .... 
<mvo> Kamion: feel free :) 
<seb128> infinity: k :/
<tfheen> ogra: can you please discuss that with mjg59 either now or in the bug?
<seb128> infinity: are we sure it comes from g-s-t or that's a random guess on a potential package?
<infinity> seb128: I'm sure it's not coming from samba, that's the best I can do.
<ogra> mjg59, why is bug 60442 a regression ? it seems it never handled such cases right (according to the upstream bug)
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
<cbx33> oh maybe it has.....seems very slow on the uptake
<infinity> seb128: I can't think all that many things enable/disable samba on a whim.
<Riddell> thanks dholbach 
<dholbach> Riddell: anytime
<infinity> seb128: And if it was a more general thing (like  rnulevel editor), the bugs would be scattered across other packages.
<popey> cbx33: my hp takes a while to spot that power has gone, I thought that was working as designed
<infinity> seb128: So, it's an educated guess, but not a for sure thing.
<seb128> right
<popey> cbx33: I have seen issues with machines that poll too often
<mjg59> ogra: Because dapper doesn't appear to have that problem
<cbx33> popey: yeh it is picking it up, but it is slow
<popey> cbx33: takes about 5-10 seconds here
<ogra> mjg59, according to hughsies comment in the upstream bug it never handled two batteries
<mjg59> ogra: Shrug. It doesn't happen in dapper. It's a regression.
<ogra> (i cant compare since i dont have any machines with two batteries)
<mvo> doko: python-central diff looks good
<zul_> infinity: ping
<tfheen> seb128: system - administration - anything gives me permission denied on my laptop.
<ogra> mjg59, since you set the milestone for it, any suggestion how to fix that without rewriting the battery_status_changed_primary function completely ?
<seb128> tfheen: are you member of the admin group?
<ogra> i dont see how we could fix that today
<tfheen> seb128: no, this machine predates that group.
<tfheen> it was originally installed with hoary, iirc.
<seb128> tfheen: ok, that's why
<infinity> seb128: Another point to note is that googling for the bug symptoms (K09samba dangling symlink) only returns hits for Ubuntu users, no Debian users, so the bug is in a patch we're carrying.
<infinity> seb128: (At least, I'd guess so)
<seb128> infinity: like the shares-admin patch to install samba
<seb128> tfheen: https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/59946
<infinity> seb128: Yeah...
<Ubugtu> Malone bug 59946 in gnome-system-tools "run action as root without prompting for a password" [High,Confirmed]  
<Trewas> mdz: sorry to bother, but old and closed bug 14575 is now back as bug 61989, and you fixed the old bug for hoary... shortly: dhclient.conf was again changed to ask for interface-mtu which some routers get wrong -> network not working. just mentioning it here because it already has few duplicates, probably a lot more if edgy is released with it
<Ubugtu> Malone bug 14575 in dhcp3 "interface-mtu change from yesterday hoses the network interface" [Medium,Fix released]  http://launchpad.net/bugs/14575
<Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [Undecided,Confirmed]  http://launchpad.net/bugs/61989
<mdz> Trewas: the description says dhcp.conf but surely ti means dhclient.conf
<Trewas> mdz: yes, dhclient.conf
<pitti> Kamion: ubiquity 1.2.3 plus the update-initramfs patch from above works great on ppc now; you rock!
<mdz> hmm, that change was propagated to Debian and we re-inherited it
<Kamion> pitti: hooray
* pitti does the Edgy dance
<pitti> erm, I'm afraid we don't even have that, have we?
<Kamion> the only other change in 1.2.4 was to incorporate the localechooser fix for your preseeding bug
<tore> hello.  can I (being a debian developer), upload packages straight to ubuntu?
<ogra> tore, no
<tfheen> tore: no, you need to go through MOTU and such, but it's a quicker process for people who are already DDs.
<tore> MOTU?
<ogra> mdz, want me to care for dhcp3 and remove the "interface-mtu" from dhclient.conf ?
<ogra> tore, masters of the universe
<tfheen> tore: Masters of the Universe; see http://wiki.ubuntu.com/MOTU
<Kamion> tore: MOTU -> masters of the universe -> those people who can upload to Ubuntu's "universe" and "multiverse" components
<mdz> ogra: I'm investigating
<Kamion> i.e. packages not directly supported by Canonical; it's the outer ring of the development team
<ogra> oki
<tore> Kamion: yep.  my munin packages are there, I just uploaded a new version to sid and thought it would be good if it was added to etch as well, as it contains a fix for the /var/run/foo-goes-missing behaviour in ubuntu
<Kamion> tore: of course when we're in the phase of development where we're syncing regularly from Debian, Debian developers often don't need to upload directly to Ubuntu, unless it's a package that has been changed in Ubuntu
<Mirv> tore: https://wiki.ubuntu.com/UbuntuForDebianDevelopers
<Kamion> tore: edgy is deep-frozen for release shortly
<mdz> ogra: yes, i think that's what we need to do.  please do
<Kamion> although /var/run fixes are still acceptable
<tore> oki.
<Kamion> tore: anyway, #ubuntu-motu should be able to help here
<tore> Mirv: sweet, thanks
<ogra> mdz, greyt, will do ...
<Kamion>      munin | 1.2.4-1ubuntu1 | edgy/universe | source, all
<tfheen> and munin is universe, so it's not that frozen
<Kamion> +munin (1.2.4-1ubuntu1) dapper; urgency=low
<Kamion> +
<Kamion> +  * Added patch from Dagfinn Ilmari Mannsker to ensure that directory
<Kamion> +    for PID file exists when munin is started (Closes: Malone #33847)
<Kamion> +
<Ubugtu> Malone bug 33847 in munin "Munin node fails to start after reboot" [High,Fix released]  http://launchpad.net/bugs/33847
<Kamion> + -- Benjamin Montgomery <bmontgom@montynet.org>  Fri, 17 Mar 2006 21:09:47 -0600
<Kamion> tore: looks like we already have that fix, but you incorporating it means that we can drop our modifications next release
<tore> Kamion: yes, but that only handles the munin-node package, for the munin one you need to add this line to /etc/cron.d/munin:
<tore> @reboot         root  if [ ! -d /var/run/munin ] ; then /bin/bash -c 'perms=(`/usr/sbin/dpkg-statoverride --list /var/run/munin`); mkdir /var/run/munin; chown ${perms[0] :-munin}:${perms[1] :-root} /var/run/munin; chmod ${perms[2] :-0755} /var/run/munin'; fi
<tore> (I've also improved the init-script workaround to respect the statoverride)
<Kamion> tore: ah, right; #ubuntu-motu should indeed be able to help then
<mdz> eek
<tore> Kamion: cheers, I'll head over there
<mdz> sfllaw: ping
<tfheen> mdz: can we have a half-release milestone?  Something for bugs which have bit us during the release crunch, but which aren't critical enough that they're RC.
<tfheen> 7.04-early or something like that.
<mdz> tfheen: we can't create milestones for 7.04 until edgy+1 is created in LP
<infinity> mdz: But then we can have arbitrary ones?
<mdz> of course, that was supposed to happen by now...
<mdz> infinity: yes, I can create them at least
<StevenK> I don't know what it is, but the version number 7.04 looks wrong...
<infinity> mdz: Basically, what tfheen and I were discussing was a "take a few days early in the release to fix these bugs that bit us last release, BEFORE it's too late, too hard, and too intrusive"
<elmo> mdz: sabdfl said last night it was blocked on you explaining fawn or some such
<mdz> infinity: yes, I understand and agree
<mdz> elmo: that is utter crap
<fabbione> StevenK: buildd is still munging on it... 
<StevenK> Oh geez.
<fabbione> pitti: ping?
<pitti> fabbione: hi
<fabbione> pitti: did you already uploaded a fix for shadow?
<pitti> fabbione: sure, this morning
<fabbione> what version?
<pitti> fabbione: shadow_4.0.16-2ubuntu3_source.changes
<fabbione> ok.. it has not been accepted yet..
<Kamion> 08:25:20 DEBUG      Subject: Accepted shadow 1:4.0.16-2ubuntu3 (source)
<Kamion> where did it go?
* Kamion looks puzzled
<Kamion> oh, no, that was the one I rejected
<Kamion> pitti: did you definitely reupload?
<pitti> Kamion: aah, wait, I have an already existing .upload filee on chinstrap
<infinity> Ah-ha.,
<pitti> Kamion: I got an Accepted mail, but apparently that was from the previous upload
<infinity> Kamion, tfheen : elmo's reimported the archive for another autotest run for me, but I intentionally have the buildds disabled right now to give you livefs breathing room.  If you'd prefer I hold off on autotest round 2 until after RC, let me know.. If not, I'll turn it on and you can contend for CPU/disk.  Your call.
<pitti> Kamion: confirmed uploaded now
<pitti> fabbione: thanks for the poke
<tfheen> infinity: I'm ok with autotest now, actually, we can always bump the priority of non-autotest builds.
<fabbione> pitti: no problem.. i just noticed that it was FTBFS in this second run and i couldn't understand why
<infinity> tfheen: Err, you misunderstand.
* pitti becomes really content with https://wiki.ubuntu.com/Testing/Current , doing expert now
<infinity> tfheen: autotest runs in dak, which means it's on the livefs buildds.
<infinity> tfheen: So, if I'm building, say, gcc-4.0 in autotest, you get to fight for cpu/disk when doing livefs builds.
<tfheen> infinity: oh, point.
<tfheen> infinity: oh well, post-rc should be fine, then
<infinity> tfheen: Kay.  I'll make sure it's on as soon as I see (or help draft) an RC announce. :)
<Tonio_> tfheen, infinity: I have an upload to commit to universe, missing dep on binary package k9copy, is one of you able to approve ?
<dholbach> janimo: I'm not so happy about renaming files
<tfheen> Tonio_: I don't do universe; talk to dholbach 
<Tonio_> tfheen: okay
<Tonio_> dholbach: ?
<dholbach> janimo: but we can make the 'theme' hidden
<dholbach> Tonio_: sure, go ahead - which dep is that?
<gnomefreak> whats the chances initramfs-tools could affect a net connection?
<Tonio_> dholbach: mencoder... that'll cause the binary package to -> multiverse
<dholbach> Tonio_: not sure, is that an automatic process?
<Tonio_> but that's a change in 1.0 version, now uses mencoder for mpeg2, we have to do with it
<fabbione> Riddell, doko: bug #66561
<Ubugtu> Malone bug 66561 in kdebindings "FTBFS in edgy [kdebindings] " [High,Confirmed]  http://launchpad.net/bugs/66561
<Tonio_> dholbach: afaik I think it is automatic, but I'm unsure
<ogra> tfheen, http://people.ubuntu.com/~ogra/dhcp3.debdiff for Bug #61989
<Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [High,Confirmed]  http://launchpad.net/bugs/61989
<dholbach> Tonio_: best to ask Kamion or infinity about that? how does demotion (because of deps) to multiverse work?
<dholbach> Tonio_: does anything depend on k9copy?
<Tonio_> dholbach: nope
<Tonio_> fabbione: I'm having a look at kdebindings
<janimo> dholbach: as long as it it fixes the crash  I am fine with whatever you chose
<Kamion> dholbach: it's not automatic, we have to be told (or notice)
<Tonio_> dholbach: I'll ask Kamion, no pb
<Riddell> thanks Tonio_ 
<janimo> dholbach: is the theme seen by the gnome icon theme selectro btw?
<dholbach> janimo: it's Hidden=True - I'll have to test if that works with gnome-mouse-properties still
<Tonio_> Kamion: ah okay, so can you handle that if I upload k9copy again ?
<dholbach> janimo: will test
<dholbach> janimo: not icon theme, no
<tfheen> ogra: approved.
<janimo> dholbach: as the reporter of the other bug with kubuntu cursor theme said it crahsed gnome as well
<Kamion> Tonio_: yes, just let me know when you've done it
<dholbach> janimo: which package gives me the "kubuntu human cursor"?
<ogra> tfheen, thanks, uploading
<janimo> dholbach: kubuntu-default-settings
* dholbach installs
<Tonio_> Kamion: sure, thanks
<Lure> I think that regression from bug 61746 should be at least considered as RC (several duplicate bugs, multiple laptops)
<Ubugtu> Malone bug 61746 in xorg-server "Xorg exits when it receives an ACPI button/lid event" [High,Confirmed]  http://launchpad.net/bugs/61746
<janimo> dholbach: what's weird that the section in the desktop file is [Icon theme]  when it is not one :)
<janimo> dholbach: but that's the same for the well-behaving industrial as well..
<doko_> mvo, tfheen: final debdiff to upload: http://people.ubuntu.com/~doko/edgy/python-central.debdiff
<Tonio_> Kamion: done
<dholbach> janimo: Not sure *shrug*
<StevenK> fabbione: I'm off to bed, let me know how the build goes.
<fabbione> StevenK: will do of course
<tfheen> doko_: it looks good to me; have it fixed any test cases for you?
<StevenK> fabbione: Thanks!
<janimo> dholbach: with Hidden=true it shows up  in xfce mouse cursor themes but not in icon themes so it's ok as far as this bug is concerned
<tfheen> doko_: if mvo and you're both happy with it, please upload.  I can't see anything wrong with it, at least.
<janimo> dholbach: but only with true, not True
<dholbach> janimo: kubuntu human works fine for me
<doko_> tfheen: yes (after having installed some packages causing these failures)
<janimo> dholbach: not sure how the reported got gnome to crash then
<tfheen> doko_: ok, cool, upload away.
<janimo> s/reported/reporter/
<dholbach> *shrug*
<mvo> doko_: thanks for fixing the prerm-pycentral stuff!
<doko_> mvo: will require some no-change uploads ...
<dholbach> janimo: I'll test this on two boxes now, then upload a package for you to test with xubuntu
<ogra> could someone approve my dhcp3 upload ?
<janimo> dholbach: thanks
<mvo> doko_: yeah
<ogra> s/approve/unqueue/
<bddebian> Howdy
<Kamion> Tonio_: Depends: libdvdnav is bogus - no such (binary) package
<Tonio_> Kamion: hu ?
<Kamion> -Depends: ${shlibs:Depends}, ${misc:Depends}, vamps, dvd+rw-tools, dvdauthor
<Kamion> +Depends: ${shlibs:Depends}, ${misc:Depends}, vamps, dvd+rw-tools, dvdauthor, mencoder, libdvdnav
<Kamion> the binary package is called libdvdnav4
<Tonio_> Kamion: argh, should be dvdnav4, sorry.....
<Kamion> shouldn't that be picked up by shlibs, anyway?
<Kamion> or is it dlopened?
<Tonio_> yeah I know, I missed this when typing probably.....; I'm reuploading, sorry
<mdz> ogra: accept or reject?
<ogra> mdz, accept indeed
<ogra> :)
<doko_> dholbach: please approve an update for python-cxx, making it compatible with python2.5, see http://people.ubuntu.com/~doko/edgy/pycxx.diff
<mdz> diff looks good
<ogra> tfheen, already accepted it 
<ogra> its just sitting in the queue
<ogra> (it == debdiff)
<Kamion> I'll process it
<mdz> ogra: no it isn't
<ogra> thanks
<mdz> I debdiff'd it and approved it
<Kamion> oh
<ogra> <ogra> tfheen, http://people.ubuntu.com/~ogra/dhcp3.debdiff for Bug #61989
<Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [Medium,Fix released]  http://launchpad.net/bugs/61989
<ogra> <tfheen> ogra: approved.
<dholbach> doko_: sure
<pitti> aah, I think I finally found out when the installer offers resizing and when not -- the big partition must be the last one, as it seems
<Tonio_> Kamion: uploaded a fixed version, sorry for the error
* dholbach hugs doko_
<Kamion> pitti: ... sort of
<Kamion> pitti: read the script? :-)
<Kamion> pitti: that's not actually a requirement, but it could be a consequence of other restrictions
<pitti> Kamion: no, I didn't, I just occured to me that the default layout for 'wipe the disk' does not work, becasue it puts swap last
<pitti> Kamion: right; I don't mind much, I'm just happy to have found how to reliably produce a setup where I can test resizing
<Kamion> resize does get offered in circumstances where the big partition is at the start; I see it all the time
<dholbach> Riddell, rideout: it builds nicely, uploading
<Kamion> indeed, I see it on installations done immediately after "wipe disk" installations
<dholbach> Riddell: debdiff here: http://daniel.holba.ch/temp/qt4-x11.debdiff
<dholbach> 10 insertions(+), 1787 deletions(-) ;-)
<janimo> are new CDs being built for today?
<pitti> Kamion: hm, I had a 5 GB ext3 (sda1) and a 500 MB swap (sda2), no furhter partitions, and wasn't offered resizing. with only a 5.5 GB ext3 I was
<Kamion> janimo: yes
<Kamion> in fact I already did ...
<Kamion> but we'll probably be doing another round later
<dholbach> rideout: thanks for your efforts!
<rideout> dholbach
<rideout> dholbach: thanks, sounds good
<dholbach> janimo: http://daniel.holba.ch/temp/human-cursors-theme_0.4-0ubuntu1_all.deb for your testing pleasure
<rideout> dholbach: will your package be 4.2.0-1ubuntu5 ?
<doko_> dholbach: please approve upload of pysvn to build for python2.5 (b-d on new pycxx)
<dholbach> rideout: yes
<dholbach> doko_: sure
<tfheen> doko_: can you close the python-central bug reports too, then?
<doko_> tfheen: will do
<dholbach> janimo: want to mark the bug as RC?
<janimo> dholbach: would be nice to be fixed but not critocal, as long as it is in final
<dholbach> tfheen: bug 66323 has a comment from upstream - what do you think? at the moment, I'm more tending to unmark it RC (it was the only crasher until now and might have been an upgrade issue / dbus fuckup) and fix it through edgy-updates
<Ubugtu> Malone bug 66323 in bluez-gnome "Problem report for bluez-passkey-gnome" [Medium,Needs info]  http://launchpad.net/bugs/66323
<dholbach> janimo: if it crashes xubuntu all the way, I'd consider it critical :)
<Kamion> doko_: that python-central upload doesn't involve rebuilding any other packages, does it?
<dholbach> tfheen: whatever patch or set of patches we choose to fix it will have to be more tested (as they're not exactly obvious)
<mdz> Kamion: it'll involve testing that they still build correctly at least
<janimo> dholbach: ok, works, thanks. Then try to get it in RC if it's ok with you
<dholbach> tfheen: but I'd leave that to the release-team's discretion
<Kamion> doko_: how much of that have you done?
<dholbach> janimo: oh, I meant: mark it as 6.10 :)
<dholbach> janimo: "release critical" - sorry :)
<tfheen> dholbach: it works in most cases now, it's not really critical for the desktop's functionality, so I'm happy with -updates.
<janimo> dholbach: well no xubuntu bugs are marked 6.10 so far. But as far as xubuntu's definition of release critical this is one :)
<dholbach> tfheen: Ok, I'll 'downgrade' it.
<dholbach> janimo: alrighty
<janimo> dholbach: as this crash sets an invalid theme in the config files so xfce does not only crash but no longer start unless the config file is hand edited
<dholbach> janimo: interesting... the big desktop environments should sit together more often and talk about implementing specifications properly, then. ;-)
<seb128> dholbach: what file is that?
<seb128> dholbach: isn't what freedesktop is about? ;)
<dholbach> seb128: yeah, but some desktop environment means seem to react differently on that kind of stuff ;-)
<dholbach> /usr/share/themes/Human/cursor.theme
<janimo> dholbach: indeed. In this case xfce code which crashes need to be more cautious as well. But I did not debug yet what part crashes.
<dholbach> seb128: I added:
<dholbach> Hidden=true
<dholbach> Directories=
<dholbach> janimo: I'll mark the kubuntu bug as a dup and open a kubuntu-default-settings task
<janimo> dholbach: thanks!
<seb128> dholbach: why the empty directories?
<dholbach> seb128: the fd.o spec says that this entry is mandatory
<tfheen> mdz,fabbione: I'm thinking about removing the milestone from https://launchpad.net/distros/ubuntu/+source/apt/+bug/63680 .  It's certainly a bug, but I don't see a solution which will be implementable in the time we have available.
<Ubugtu> Malone bug 63680 in apt "dapper -> edgy dist-upgrade holds back essential packages" [Medium,Confirmed]  
<janimo> seb128: to keep xfce from crashing. That entry is mandatory in the icon them spec, but gnome seems to cope with it missings
<dholbach> seb128: xfce crashes without it :)
<seb128> I would call that an xfce bug ;)
<seb128> it should not crash on a wrong theme
<tfheen> if an application crashes, it's an application (or library, possibly) bug.
<janimo> seb128: I agree it's an xfce bug. But the thme file not being entirely kosher is a bug even if a smaller one
<tfheen> apps should never crash on malformed input.
<fabbione> tfheen: can we add it at least to the release notes?
<fabbione> tfheen: and remove the tag after?
<tfheen> fabbione: sure, release notes is fine.
<fabbione> it doesn't make me happy at all, but i see no other way out nor does mvo
<seb128> what spec did you look at?
<seb128> there is a cursor theme spec?
<seb128> or you used the icon theme one?
<tfheen> fabbione: I'm not too happy about it either, but given that we don't have a fix and RC is two days away..
<mvo> tfheen: yeah, it sucks - for edgy+1 we get a text-mode dist-upgrader that can solve similar issues for us automatically
<fabbione> tfheen: yeah...
<janimo> no point in agreeing upon standard file formats if everyone implements slightly differnt variants and has to have code to handle all of them
<ondrej> mm all
<fabbione> mvo: we want a working apt-get... sysadmins want apt-get or kitties will die
<seb128> hi ondrej
<janimo> seb128: I looke ta the icon them spec as the cursor file in cause call themselves index.themes instead of cursor.themes
<ondrej> tfheen: hi, did you get any reply on ubuntu.cz yesterday?
<mvo> fabbione: right
<seb128> janimo: what theme is that?
<janimo> seb128:  so they make xfce look at them. If I renamed them that's another workaround but dholbach said he;s not comfortable with a rename at this stage
<tfheen> ondrej: no, sorry.
<fabbione> StevenK: it builds fine.
<janimo> seb128: human-cursors-theme and kubuntu's cursor theme
<dholbach> janimo: human cursors theme (and kubuntu human cursors theme)
<janimo> seb128: for comparison Industrial while it lack Directories= it is properly named so does not cause problems
<seb128> my human-cursors-theme has only a cursor.theme
<seb128> no index.theme
<janimo> seb128: the alternative link needs to be named differently then
<janimo> in /usr/share/icons/default/index.theme
<seb128> $ dpkg -L human-cursors-theme | grep "\.theme"
<seb128> /usr/share/themes/Human/cursor.theme
<janimo> maybe changing postrm would suffice then I dunno
<seb128> right
<janimo> postinst I mean
<seb128> better to do that after edgy though :)
<dholbach> yeah
<dholbach> *uploading*
<seb128> but if any wrong theme can crash xfce you should better patch xfce
<dholbach> tfheen: uploaded a fix for human-cursors-theme to make xfce not crash any more.
<janimo> seb128: right, I wanted to make sure it is worked around in case I don;t find the bug. And one reported said thekubuntu one caused gnome to crash which made me think this could be a more serious issue. As I also had gt warnings related to no Diretcories entry in the error log
<dholbach> tfheen: (buf 65870)
<dholbach> janimo: as I said: the kubuntu cursor works fine for ubuntu - no crash for me
<janimo> gtk warnings.
<janimo> dholbach: right I did not test, so relied on what the reporter said
<dholbach> *nod*
<dholbach> Riddell: bug 65870 should be easy to fix and something for somebody on the kubuntu end to fix and test
<Ubugtu> Malone bug 65870 in xfce-mcs-manager "xfce crashes repeatedly after changing icon theme to default" [Undecided,Confirmed]  http://launchpad.net/bugs/65870
<tfheen> dholbach: I'll respond after som food.
<dholbach> tfheen: bon apptit
<Riddell> dholbach: ok
* dholbach hugs Riddell
<sfllaw> mdz: pong
<doko_> dholbach: please approve http://people.ubuntu.com/~doko/edgy/logilab-common.debdiff, fixing an upgrade error
<Kamion> 15:20 < Kamion> doko_: how much of that have you done?
<Kamion> doko_: ^-- python-central, checking that other packages still build
<dholbach> doko_: sure, go ahead
<doko_> Kamion: oops, didn't notice. building itself isn't affected; infinity reported a removal error on the buildd's (package removal when python-central already is removed)
<doko_> Kamion: for that to fix, ... theoretically all packages with files located in /usr/share/pycentral need to be rebuilt; in practice ... ?
<seb128> Riddell: do you know about https://launchpad.net/distros/ubuntu/+source/pango1.0/+bug/65820 ?
<doko_> dholbach: please approve http://people.ubuntu.com/~doko/edgy/straw.debdiff
<Ubugtu> Malone bug 65820 in pango1.0 "Ugly fonts in gtk apps under edgy KDE (kubuntu)" [Undecided,Unconfirmed]  
<Riddell> seb128: nope, but I can test it out
<dholbach> doko_: looks good
<seb128> Riddell: would be nice. Do you know if KDE changed the way it manages fonts or something?
<Riddell> seb128: I did change the default fonts this week, Deja Sans -> Sans Serif
* sivang -> back
<seb128> Riddell: ok, I've asked since when he has the issue
<mdz> Keybuk: does network-magic need more discussion this time around at UDS?
<Keybuk> mdz: if we want to have more discussion, I think we should create smaller less handy-wavy/christmas-tree specs for it
<Keybuk> seb128 and dholbach may care about NM seeing as it's potentially part of the next release of GNOME
<Keybuk> specs I can invision include
<mdz> Keybuk: what's network-information-sharing about?  sounds very handwavy
<Keybuk> static networks
<Keybuk> vpns
<Keybuk> integration with ifup
<Keybuk> etc.
<Keybuk> hmm
<Keybuk> oh, that's the spec for sharing information with avahi
<mdz> Keybuk: someone else registered it and you put it on the agenda
<Keybuk> I hadn't yet fully tidied it up -- it was the most appropriate spec of the set
<Keybuk> default-network-services is the "discuss what policy we should have wrt open ports, etc."
<dholbach> Keybuk: I'd prefer it, if somebody else who'd know more about network stuff and about integration with the network bits in Ubuntu took care of it.
<Keybuk> and there's a few deps of that
<Keybuk> the spec for d-n-s should be an informational policy
<Keybuk> whereas the spec for n-i-s should be how we plan to exploit the new policy
<Keybuk> if that makes sense
<Keybuk> one is a dep of the other, so the scheduler will ensure they happen in the right order (in theory, the second may never have a discussion bof and go straight to drafting)
* ogra planned to look deeper into avahi for ltsp this time ....
<tfheen> dholbach: about 65870 ; I don't think this is RC in either of the themes.
<dholbach> tfheen: hum... it crashes xubuntu
<tfheen> dholbach: then fix the crash there, if it's not very hard?
<janimo> tfheen: I do not know how hard it is. But that icon them file is not in standard format
<ogra> fixing the xfce thme handling will surely be more intrusive
<dholbach> tfheen: I agree with janimo there.... while it's preferrable to have xfce fixed and it should be investigated and forwarded, this is something which should have been done anyway
<tfheen> dholbach: I'm not saying it's not a bug, I'm merely saying it's not RC for those package.
<janimo> tfheen: right, it's not RC for those specific packages, just affects others :)
<dholbach> So that's the distinction "it's RC" vs. "the implication of this little bug gives another distro RC bugs"? :-)
<dholbach> But alright, I uploaded the human-c-t fix, that's all I could do for my part.
<tfheen> dholbach: yes, and in some cases it can "bleed" over if the fix is really painful.  (Say if xfce-mcs-manager would have to be rewritten completely, I'd be more inclined than in the case here where I would guess a strdup("") is all that's called for.
<dholbach> tfheen: right... it could be an easy fix. agreed.
<tfheen> at this point, I want to not only have minimal changes, I want to not rebuild anything unless we have to.  Bugs have cropped up in the past because some seemingly insignificant piece changed in a subtle way.
<tfheen> so from the POV of ubuntu, kubuntu and edubuntu, it makes more sense to implement the fix in xubuntu.
<mdz> sfllaw: good morning
<mdz> sfllaw: do you have those test cases prepared?
<pirast> infinity, any news on the bootstrap of fpc?
<rideout> the network-manager update that just went out causes knetworkmanger to bomb on me constantly
<Keybuk> *sigh*
<doko_> tfheen: please approve http://people.ubuntu.com/~doko/edgy/python-setuptools.debdiff
<tfheen> rideout: which network card do you have?
<tfheen> rideout: or rather, which driver do you use?
<tfheen> doko_: which problem does it fix?
<rideout> ipw3945
<doko_> tfheen: running easy_install without having python2.5 installed
<tfheen> rideout: the network-manager update only changed behaviour for people using ndiswrapper, so I doubt your claim.
<tfheen> doko_: oh, ok, approved.
<Keybuk> tfheen: no it didn't
<tfheen> Keybuk: oh?
<Keybuk> the guy snuck in another change into the patch
<Keybuk> (at least the one I read)
<Keybuk> which is why I rejected it
<Keybuk> no idea why it suddenly got applied and uploaded
<tfheen> Keybuk: there was no other change in it, but a patch applied on top had to be adjusted.
<rideout> tfheen: well, i'll do some more testing...
<tfheen> Keybuk: http://err.no/patches/network_manager_remove_ndiswrapper_specialcase.diff is the patch.
<tfheen> or, interdiff
<Keybuk> ok, that's somewhat cleaner than the one I read
<tfheen> it's semantically equivalent.  The other guy just fumbled a bit with dpatch.
<Keybuk> wasn't wpasupplicant updated as well?
<Tonio_> fabbione: just fixed kdebindings (and update to 3.5.5)
<Tonio_> mdz: as that is part of kde 3.5.5, I assume it doesn't need uvf exception request for upload does it ?
<doko_> dholbach: please approve python-4suite to add replaces fixing an upgrade error
<dholbach> doko_: sure
<tfheen> Keybuk: I didn't do that, at least, and it works fine with unencrypted networks.
<rideout> tfheen: wpa_supplicant is actually the problem some TKIP error, but it was working 20 minutes ago ... i'll dig deeper
<Keybuk> rideout: try a clean reboot
<tfheen> anyway, I'm afk for a few hours.  Roleplaying session.
<mdz> Tonio_: that exception was granted some time ago and I understood that 3.5.5 was already in
<mdz> Tonio_: it's too late to be pushing new upstreams at this point unless they're incredibly minimal
<Tonio_> mdz: no it isn't since the package failed to build
<Tonio_> mdz: well the problem is that the current package now ftbfs too, due to libgcj7-dev update......
<Tonio_> mdz: isn't that problematic enough to update ?
<mdz> Tonio_: if it fails to build, that should be fixed directly, not by bringing in a new upstream
<Tonio_> mdz: bah I can fix the current package too, the fix is the same
<Tonio_> mdz: I just updated because kde 3.5.5 was approved
<Tonio_> mdz: so I can fix and upload the current package then...
<mdz> Tonio_: that was before the freeze
<Tonio_> mdz: okay, let's fix the current package then
<mdz> thanks
<Tonio_> dholbach: I'll probably upload kdebindings (universe) in a moment, corrects the ftbfs issue, can you aprove ?
<dholbach> Tonio_: No sorry - I'm not allowed to. That's the realm of tfheen, mdz, infinity and Kamion.
<dholbach> oh
<dholbach> that'S universe?
<Tonio_> yup
<Tonio_> ;)
<infinity> No, it's in main.
<dholbach> what I thought
<infinity> Tonio_: Show mdz the diff (I'd say "show me", but I'm in no state to make sound technical decisions)
<infinity> I'm sane enough to know which component it's in, though. :P
<Tonio_> tonio@kubuntu:/usr/lib$ apt-cache show kdebindings-java | grep Filename
<Tonio_> Filename: pool/universe/k/kdebindings/kdebindings-java_3.5.4-0ubuntu1_all.deb
* dholbach hugs infinity
<Tonio_> looks in universe for me
<infinity> Tonio_: The source is in main, that one package is in universe.
<dholbach> apt-cache showsrc kdebindings
<Tonio_> infinity: ah ok sorry, gimme a moment to do the debdiff
<Tonio_> dholbach: yeah thanks I didn't though about the source package indeed
<Tonio_> infinity: http://paste.tonio.homelinux.org/30 the debdiff
<keescook> Keybuk: do have a moment to pull a sync?  dirvish is currently half-broken in edgy: bug 66273
<Ubugtu> Malone bug 66273 in dirvish "sync request" [Undecided,Confirmed]  http://launchpad.net/bugs/66273
<Tonio_> infinity: I'm just testing the fix on the current package and if it builds correctly and you are okay I'll upload
<Keybuk> keescook: done
* keescook hugs Keybuk
<zul> how do you get a spec on the agenda for uds?
<fabbione> zul: it's written in the email from mdz to ubuntu-devel-announce
<fabbione> zul: somebody will review and approve them IIRC
<zul> fabbione: ok thanks
<geser> fabbione: any news on the outdated Contents files on archive.u.c for edgy?
<fabbione> geser: no, you can ask in #launchpad 
<fabbione> geser: malcc or SteveA or kiko
<geser> will do
<Riddell> seb128: I've just done a new install and fonts in gtk apps running under kde look fine
<Riddell> seb128: he seems to have commented that it's fixed for him
<infinity> Tonio_: As I said, please ask mdz for review/approval, I'm not all here.
<infinity> (and going to bed now)
<ogra> does ff take ~30sec for anyone else to open a url you clicked on in IRC or other external apps ?
<ogra> (i.e. evolution)
<ogra> it seems to take ages here to open a new tab if i click anything
<ivoks> no
<Tonio_> infinity: ah sorry, I'll ask mdz then
<Tonio_> mdz: http://paste.tonio.homelinux.org/30 is that okay for upload according to you ?
<agutierr> hello all: I have a serious problem. Someone knows if its possible to convert the yp/nis passwd.byname file to a passwd file ?
<ogra> agutierr, please ask in #ubuntu, this is not a support channel
<agutierr> thanks ogra 
<wasabi> ajmitch: You going to bring up anything about network auth at UMV?
<mdz> Tonio_: what is the effect of that change?
<mdz> sfllaw: did you see my earlier messages?
<mdz> Tonio_: why is that patch no longer necessary?
<Tonio_> mdz: builds correctly, the patch removed caused ftbfs due to libgcj7-dev change
<mdz> Tonio_: what that patch seems to do is replace some find commands with hardcoded defaults
<mdz> Tonio_: why does that cause it to fail to build and how does removing the patch fix it?
<Tonio_> in fact libgcj.so is no longuer in /usr/lib in latest  libgcj7-dev 
<Tonio_> mdz: then configure fails, but works correctly without that patch
<sfllaw> mdz: Ah yes.  Testing/Current is uptodate.
<Tonio_> mdz: the point is that patch simplifies the configure commands, true, but the point is that libgcj.so path as changed
<mdz> sfllaw: you, cr3, pitti and fabbione seem to have an excessive number of test cases
<Tonio_> mdz: /usr/lib/gcc/i486-linux-gnu/4.1.2/libgij.so in currently i386 package , that's why it is necesarry to go back to the find commands
<seb128> Riddell: ok, thank you for testing and confirming it works fine on a fresh install :)
<sfllaw> mdz: cr3 actually has to do these test cases for certification.  :(
<Tonio_> mdz: previous libgcj7-dev created a symlink in /usr/lib which has been removed
<mdz> sfllaw: it will take him all day though
<sfllaw> mdz: So I'm helping him out with those as a side-effect.
<sfllaw> We have a lot of computers, so parallel processing is the plan.
<pitti> mdz: I'm fine with doing two architectures, that doesn't slow me down; it would just not hurt to split one arch between two people
<sfllaw> I'm going to hop out and buy a few more CD-RW.
<cr3> pitti: I can do i386 and amd64, maybe some powerpc if only I had more time (not likely to happen)
<sfllaw> pitti: Is that too much?  We don't seem to have a lot of developers with  PPC machines any more.
<cr3> I'm also working on sparc actually, so scratch powerpc, I definatly won't have time for that
<pitti> cr3: I'm fine with doing the powerpc range
<cr3> pitti: cheers
<pitti> I can easily test them while working on my amd64 desktop
<pitti> sfllaw: it just takes a while, my ibook is painfully slow
<sfllaw> pitti: Understood.
<pitti> I ordered some more RAM today, that should help a little
<sfllaw> pitti: Sadly, our Pegasus box in the lab doesn't boot off of CDs.
<sfllaw> And the lab bandwidth is terrible.
* Kamion rebuilds all alternate CDs
<cr3> by the way, ubuntu 6.10 desktop for i386 built on 20061016 didn't install on two machines. I'm currently updating my iso to 20061017, but is that worth reporting while waiting for the download?
<Riddell> Kamion: why the rebuild?
<sfllaw> cr3: It never hurts to mark down additional information.  Just make sure -fail is in lowercase.
<Kamion> Riddell: new d-i
<Kamion> fixes a couple of targetted bugs
<Kamion> cr3: it always helps if you give more information than "didn't install" when reporting things like that here
<Kamion> we cannot possibly tell you if it's worth reporting otherwise
<keescook> tfheen: is aolserver4 sitting in the queue somewhere?  dholbach said it was okay to upload yesterday (along with ettercap that looks to have gone through)
<cr3> Kamion: oh, I thought the problem might've been known to others in here, so that's why I was so brief. since nobody seems to have encountered such severe installation problems with 20061016, I should definately report it. thanks.
<Kamion> cr3: you say that as if there is only one possible mode of installation failure!
<Kamion> "the problem"
<sfllaw> :)
<Kamion> it could be ANYTHING
<sfllaw> Aliens from outer space have abducted my installer!
<sfllaw> Help!!!
* sfllaw puts on a tinfoil hat.
<Kamion> my wife says that happened to her with Win95, but sadly they gave it back
<Tonio_> mdz: need more infos or is it clear concerning the patch removal ?
<Kamion> cr3: seriously, plain "didn't install" always raises my blood pressure, so please just don't say that :-)
* mvo hugs Kamion
<cr3> Kamion: I tend to be more brief on irc so I'll just report bugs in malone and copy/paste in Testing/Current. thanks for the tip.
<Kamion> sfllaw: for that hang in installer package selection, you didn't accidentally press alt-tab, did you?
<Kamion> I was just told about a bug today where cdebconf hangs if you press alt-tab
<Kamion> (during a progress bar)
<Kamion> I assume it's some crazy code in newt
<elmo> argh, something broke C-s in emacs
<elmo> so much hate
<sfllaw> Kamion: I don't think I did.
<ogra> who cares about emacs anyway 
<sfllaw> I can be careful not to.
<ogra> use openoffice
<fabbione> mdz: sorry about what?
<mdz_> Tonio_: how out of date is kdebindings?
<Keybuk> tfheen: new amd64 usplash utterly screws VT 1
<Keybuk> at least you can't flip back to it again
<mdz_> Tonio_: did the current version originally fail to build, ro did it only start to fail to build due to the other changes?
<fabbione> mdz: sorry .. too many test cases for what?
<mdz> Tonio_: if the current binaries are up to date and it's just an ftbfs due to the gcj changes, then please go ahead
<mdz> fabbione: too many to complete in a reasonable amount of time
<Tonio_> mdz: the current version started to fail building when libgcj7-dev was updated, but it has been built and we have binary packages in the repos
<Tonio_> mdz: okay I'm uploading, thanks
<fabbione> mdz: you mean install tests? or something else? i didn't even get to the test matrix yet. T2000 is still busy rebuildin
<mdz> fabbione: I mean installation tests, yes
<fabbione> mdz: ok.. let me check the matrix
* dholbach hugs mdke_
<pitti> fabbione: don't forget the blue pill :)
<fabbione> mdz: clearly who did the matrix doesn't know that there are no desktop CD for sparc and that we don't support full desktop
<fabbione> mdz: no big deal.. i am going to clean it up
<fabbione> same for kubuntu
<fabbione> we only support server sparc
<sfllaw> fabbione: Ah.
<sfllaw> Sorry about that.
<sfllaw> fabbione: Do you want me to fix it?
<fabbione> sfllaw: do you want to clean up or should I?
<sfllaw> I'll do it.
<mvo> tfheen: would it be possible to upload another dist-upgrader version? http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061017.1916_all.diff <- it fixes one crash for strange dpkg error output and ensures proper upgrading for bzr/tomboy/xserver-xorg-input
<fabbione> sfllaw: there is no check cd for sparc either
<fabbione> or DVD's
<Tonio_> mdz: uploaded thanks
<sfllaw> How do you know if the CD's broken then?
<sfllaw> And is there a DVD version?
<fabbione> sfllaw: when that thing was implemented nobody did it for silo.. so there is no way to execute it AFAIK
<sfllaw> Oh.
<fabbione> sfllaw: nope.. no DVD's
<Kamion> nobody told me about that
<sfllaw> Is there also a Netboot for sparc?
<fabbione> sfllaw: yes.. netboot is VITAL for sparc
<fabbione> it needs more testing than Cd's
<sfllaw> OK.  So Netboot + Server CD is all it has.
<Kamion> fabbione: er, did you ever try booting the sparc server CD with 'check'?
<fabbione> Kamion: i don't blame anybody.. i didn't know about it and when i figured it was too late (like 20 seconds ago)
<Kamion> # Media integrity check
<Kamion> image[sun4u] =/boot/sparc64
<Kamion>   label=check
<Kamion>   append="MENU=/bin/cdrom-checker-menu --"
<Kamion> ^-- in debian-cd/data/edgy/sparc/silo.conf
<sfllaw> fabbione: So is ther Kubuntu support?
<fabbione> Kamion: last i checked it was not there..
<fabbione> Kamion: EVEN BETTER!
<Kamion> that's been there so long I don't remember adding it
<fabbione> EVERYBODY HUG KAMION *NOW*!
* sfllaw hugs Kamion.
* fabbione hugs Kamion 
<Kamion> no, don't :)
* ogra hugs Kamion 
<Riddell> sfllaw: no,there's not
<dholbach> sfllaw: I can't do the ppc tests - i have an *ancient* machine
* pitti gugs Kam'hero of powerpc'ion
<fabbione> Kamion: usually silo does tab complation and it didn't show up for beta.. tho ..well i am happy :)
<pitti> hugs, too
<sfllaw> dholbach: Can you remove your PPC machine from StaffHardware thaen?
<fabbione> sfllaw: anyway the amount of tests are really not balanced
<dholbach> sfllaw: I can do one or another alternate/server install, but not so many
<fabbione> sfllaw: across the team..
<Kamion> fabbione: not saying it's necessarily correct
<Kamion> I added it on 2006-01-04
<fabbione> Kamion: i will test it tomorrow or so
<mdz> mjg59: how do we unintrusively fix bug 60442?
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
<fabbione> Kamion: i am sure these CDs are not 100% gold yet ;)
<sfllaw> dholbach: Hardware on ppc was rough.
<mdz> mjg59: given that gpm doesn't seem to understand properly about multiple batteries at all, adding that functionality isn't feasible
<sfllaw> People have machines that are old, have no hard disks, broken, etc.
<sfllaw> :(
<dholbach> sfllaw: it already says "very aged G4" :)
<mdz> mjg59: what did it do in dapper?
<fabbione> sfllaw: there are people with gazillions of tests and people with none
<Kamion> hmm, I never updated gfxboot-theme-ubuntu at the non-langpack translation deadline
<dholbach> sfllaw: as I said: I'm happy to do one or another install (hoping that the memory for it will arrive soon), but not all of them
<sfllaw> dholbach: It didn't say "Apple Quadra 700".
<Kamion> mdz: how would you feel about me doing a quick update from Rosetta there? should be pretty safe and just requires CD rebuilds
<sfllaw> fabbione: Who are the people with none?  I tried to fill up everyone from the Devel team.
<Kamion> (which I bet are going to happen anyway ...)
<sfllaw> Obviously, I can't steal people from kiko.  :)
<mdz> Kamion: ok with me
<Kamion> thanks. the last translation update was 5 September
<fabbione> sfllaw: BenC? seb128 (and not 123!)...
<Kamion> and predates the rename of "Install a server" to "Install a command-line system"
<BenC> fabbione: Yo
<fabbione> BenC: never mind.. i was just reminding sfllaw that you exist
<ogra> <- dinner/breakfast/lunch, however you wanna call it ... bbl
<fabbione> sfllaw: Kamion is missing from the list.. like our test GOD!
<Kamion> dear god, gfxboot-theme-ubuntu has a fledgling Klingon translation now
<dholbach> seb123 - LOL
* dholbach hugs seb128
<sfllaw> fabbione: Oh, transcription errors.
<Treenaks> Kamion: almost 'enterprise-ready' then
<sfllaw> I had them written out on a piece of paper.
<Kamion> Treenaks: *groan*
<Treenaks> Kamion: ;)
<Kamion> sfllaw: how quaint
<elmo> remember kids, every time you use a winky smiley, jono kills a kitten
<sfllaw> ;)
<sfllaw> ;)
<Treenaks> elmo: ooh! ;) ;) ;) ;)
<fabbione> sfllaw: also.. did you send out a mail for global testing?
<sfllaw> ;) ;) ;) ;)
<Keybuk> ;)
<fabbione> ehhehe
<bhale> if he kills them with a guitar, sign me up
<Treenaks> elmo: he has to eat _something_
<sivang> elmo: ahah, true
<sfllaw> fabbione: I have a draft.
<sivang> I lost my online emotions for a while after reading his blog post
<sivang> actually it was nice feeling so cool and emotionless for a while, but then people are winking at you...wont'ya wink them back? 
* Kamion -> dinner
<mdz> mjg59: we don't have any laptops with two batteries around, so if you feel this bug is this important, I'll need your help to do anything about it
<sivang> bhale: you play ?
<sfllaw> Kamion: Do we know when those "out of date, do not test yet" images will be up to date?
<bhale> sivang: barely, these days
<sfllaw> Kamion: Or should we get users thrown at the Alternates first?
<mjg59> mdz: Right
<sivang> bhale: you should practice or your wrist will stiffen
<sivang> bhale: I do wrist practice to not let it go bad although I have played a note since ages
<_ion> Yay, artists.
<sivang> s/have/haven\'t/
<_ion> Why escape the '?
<mdz> mjg59: I looked at the code a bit and I don't see why it would behave differently in dapper
<mjg59> mdz: I have no rational explanation, merely the observation that it doesn't happen in dapper
<Treenaks> _ion: for the people with strict parsing auto-replacing irc clients ;)
<seb128> fabbione: thank you for reminding people to give me extra work :p
<fabbione> seb128: no.. for you was just a mispell :)
<fabbione> seb128: or do you feel downgraded to sev123 ?
<seb128> hehe
<seb128> no, I just didn't feel concerned since I don't know that seb123
<fabbione> sfllaw: note that also BenC has sparc...
* fabbione hides
<dholbach> seb128: we all know how much you like your name mispellt
<mdke_> Kamion: no, that's not built/shipped by default - it's just in our svn tree. We can exclude it from the source package if that helps
* seb128 hugs dholbach
<dholbach> :-)
<seb128> anyway downloading DVD will take some time for me
<seb128> I've just CD images handy atm
<seb128> and my dsl is not that fast
<mdke_> Kamion: (I hope it's not out of date though)
<sfllaw> seb128: rsync?
<seb128> sfllaw: rsync works fine when you have a base :)
<sfllaw> Start downloading now!
<sfllaw> :)
<seb128> will do
<seb128> it's just going to take 1 day
<sfllaw> Yeah.
<sfllaw> The Montreal office's connexion is not much better.
<fabbione> seb128: cat alternate.iso > dvd.iso
<sfllaw> It takes us a day to get the DVD as well.
<fabbione> seaLne: cat live.iso >> dvd.iso
<fabbione> rsync
<fabbione> seb128: ^^
<fabbione> or was the other way around?
<seb128> fabbione: right, should give a start :)
<sfllaw> The live portion comes after?
<fabbione> iirc it comes first
<sfllaw> Yeah.
<sfllaw> That makes more sense.
<sfllaw> cat live.iso alternate.iso > dvd.iso
<sfllaw> You know, because it concatenates?
<fabbione> Kamion: does live comes first on dvd?
<fabbione> sfllaw: yeah.. i am old lazy schoo
<fabbione> l
<sfllaw> fabbione: Your cat didn't concat files?!?
<fabbione> sfllaw: it probably did.. but i was learning pipes and concats at the time and you know.. once you learn one way you keep it that way
<dholbach> sfllaw: I'm happy to do some amd64 installs instead and some server installs or something easy on ppc
<sfllaw> dholbach: I've got you down for desktop Edubuntu PPC installs.
<sfllaw> The check CD and live session tasks are easy.
<dholbach> I noticed, that's why I said it :)
<dholbach> I know
<sfllaw> Is that still too much?
<dholbach> but not on a VERY AGED G4 :)
<sfllaw> Ah.
<sfllaw> I still work on a PII, you know.
<dholbach> I don't mind test-installing
<dholbach> the problem is that I didn't get the memory for it yet - I hope it'll be there tomorrow, but I can't promise
<sfllaw> If you go down from three installs to two, is that good enough?
<sfllaw> Oh.
<sfllaw> I get it.
<dholbach> I'm happy to do other installs
<dholbach> no problem
<sfllaw> I'm slow today.
<sfllaw> Someone gave me the cold.
<fabbione> sfllaw: you are really tempting me..
<dholbach> fabbione: tempting how?
<fabbione> to say s/ today//
<sfllaw> :)
<dholbach> sfllaw: Ok, rsyncing.
<Lure> mdz: which bug with dual battery?
<Lure> mdz: I got it in backlog - bug 60442 - I can try this as I have looked g-p-m code when implementing kde-powermanager multibattery
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
<mdz> Lure: any help you can provide would be appreciated
<Lure> mdz: the problem is that multi-battery support in g-p-m is limted to presenting remaining time properly, while low/critical is done on battery events - which means that every battery getting to critical state will cause problems
<Lure> mdz: it will work somehow only on laptop that discharge both batteries at the same time (not that many) and if batteries are of similar capacity :-(
<bhale> I admit it is annoying to get a notification when my first battery runs out, but i doubt that is a huge install base
<mjg59> bhale: The default behaviour is then to hibernate
<bhale> oh, I've surely changed that first thing
<Lure> mdz: quick (dirty) fix could be to use remaing from cache instead of from single battery (this is what we do in kde-powermanager)
<mdz> Lure: why was it better in dapper and how can we revert to it?
<Lure> mdz: I do not know (not gnome person), but I suspect that g-p-m did not use events to trigger critical action
<mdz> the code was there, maybe it was somehow broken
<mdz> in which case we should simply disable it in edgy to avoid this regression
<mdz> we could just default to doing nothing on a critical event, and let the user change it if they like
<Lure> mdz: it may have used battery property change event instead and just reclaculated levels at that time
<Lure> mdz: we could hack a quick solution, but I am not sure if it is the right time to include it so late
<Lure> mjg59: are you looking at the g-p-m code?
<mjg59> Yes
<Lure> mjg59: if we would pass gpm_manager_get_warning_type() status from cache (which is cumulative for all primary batteries), then warning level would be properly calculated
<mjg59> Lure: I agree
<Lure> mjg59: I am just not sure how big surgery would this be
<mjg59> Lure: Well, it needs to be slightly more complicated than that.
<mjg59> Lure: Since otherwise you'll never get low reporting for bluetooth devices
<Lure> mjg59: no, because there are different callbacks for different types
<mjg59> Lure: Oh, sorry, I see what you mean
<Lure> mjg59: we would just pull type_status in battery_status_changed_primary() 
<Lure> mjg59: see battery_kind_cache_update() for cache version 
<Lure> mjg59: I know that part as I used this as refernce for all pecularities when implementing kde-pm
<mjg59> Lure: Right. I agree.
<mjg59> battery_status_changed_primary should look at the battery_status entry of the cache, not the status provided by the individual battery
<Lure> mjg59: we would need to call battery_kind_cache_find (power, PRIMARY) to get entry and then pass entry->battery_status to gpm_manager_get_warning_type() 
<Lure> exactly
<mjg59> Lure: That sounds like a demonstrably correct and non-invasive change
<Lure> mjg59: it is correct, not sure if it is the thing the author of g-p-m would do though ;-)
<mjg59> Lure: It's the minimal invasive change and we don't have time to do anything else :)
<Lure> mjg59: and true, it is not as dirty as I though initially
<Lure> mjg59: I can try building something, but it will be the fisrt gnome build for me ;-)
<Lure> mjg59: I can test on my dual-battery hp nw8240 (as I have still test gnome install used to check how ubuntu does laptop support)
<mjg59> Lure: Cool
<mjg59> Lure: Oh, wait. Do we want to update the cache before doing the cache_find?
<Lure> mjg59: I suspect it is already up-to-date as it gets updated on battery propertly change event
<mjg59> And that happens before the manager update?
<Lure> I suspect this is before critical/low warning event
<Lure> but would need to test
<mjg59> Ok
<mjg59> It's an extra line in the worst case
<mjg59> Lure: Every reference to battery_status needs to be changed to type_status in the rest of battery_status_changed_primary
<mjg59> But not the ones before the warning state is grabbed
<Lure> mjg59: not sure regarding before ones though
<Lure> mjg59: if one of two is charging, then we should reset warning to NONE, no?
<Lure> mjg59: my HP charge first the built-in, then external and sure any one charging means that we are on AC
<Lure> mjg59: so no warnings should be issued
<Lure> mjg59: only not sure about fully charged -> do we want one for each battery or only one notify when both are charged (this is what kde-pm does)
<mjg59> Lure: Ah, I see what you mean
<mjg59> Yeah, ok, that makes sense
<cbx33> hmm.....firefox is refusing to start in edgy....
<cbx33> I installed from the 16 build
<cbx33> copied my home dir from nmy old dapper
<cbx33> it said it was checking the plugins/extensions....
<cbx33> that took forever, and to my knowledge I didn't have many/any installed
<cbx33> now it just hangs
<cbx33> no gui no nothing
<cbx33> the process is there
<cbx33> strace yeilds lots of futex and gettimeofday
<mjg59> Lure: Of course, there's the problem that gpm-manager can't call battery_kind_cache_find directly...
<Lure> mjg59: why not?
<Lure> static?
<mjg59> Oh, yeah
<Lure> mjg59: what about gpm_power_get_battery_status() - this is called from gpm-manager.c
<mjg59> Lure: Just make them non-static
<mjg59> Oh, wait, yeah. That might be cleaner.
<mjg59> Yeah, go with that.
<mjg59> It looks perfect.
<Lure> mjg59: it looks like this is external wrapper for cahce_fine
<mjg59> Yup
<Lure> cache_find too
<Lure> mjg59: but this is already done in power_battery_status_changed_cb() :-(
* Lure is confused (theory might be wrong)
<mjg59> Wurgh.
* mjg59 looks closer.
* Lure runs back to drawing board... ;-)
<mjg59> Lure: Yes, that looks awkwardly like it should work
* mjg59 is confused now
<Lure> mjg59: something else confuses gpm_manager_get_warning_type() 
* Lure is not sure if we should move to #ubuntu-laptop ;-)
<mjg59> No, here is fine
<mjg59> I can't see how get_warning_type could be doing anything wrong
<mjg59> Which leaves me wondering about the contents of the cache
<Lure> mjg59: use_time might be tricky if cache value is bad - see comment in line 2808
<mjg59> Which file?
<Lure> gpm-manager.c
<Lure> mjg59: search for GPM_PREF_USE_TIME_POLICY
<mjg59> Ah, yeah
<mjg59> The cache calculations may be wrong when one battery empties?
<mjg59> Lure: I think we're going to have to do this the hard way, add some debugging and then see what actually happens when the changeover occurs
<Lure> mjg59: not sure how (I am using similar for kde-pm and works for me
<Lure> mjg59: only questionable code in cache is for me use of percentage_charge before being set in the check in lgpm-power.c:973
<Lure> mjg59: percentage_charge is set later :-(
<mjg59> Lure: I can't see why that would result in bad things, though
<Lure> mjg59: and this might be exactly the case: one battery just empty (so disharging is false), the other still not reporting it is discharging 
<mjg59> Ah
<mjg59> Yeah
<mjg59> Ok. It's probably worth fixing that, then
<Lure> mjg59: but then, the percentage check is not needed
<mjg59> Yes
<mjg59> Right now, it looks like it'll never go through that block
<Lure> mjg59: it will sure not get in
<mjg59> So you think in this case we'd end up with type_battery not reporting either state?
<Lure> mjg59: and I have seen both charging/discharging being false on my machine when fully charged
<Lure> mjg59: never monitored hal events when switching from travel to built-in though
<Lure> mjg59: do you have contacts with upstream author?
<mjg59> Yeah
<mjg59> Lure: Would you mind commenting in the upstreaem bug?
<Lure> mjg59: upstream bug?
<mjg59> Linked to from the one in Launchpad
<Lure> mjg59: I see - I can add some points there...
<mjg59> Thanks!
* Lure has to get gnome account :-(
<Lure> ;-)
<mvo> mdz:  would it be possible to upload another dist-upgrader version? http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061017.1916_all.diff <- it fixes one crash for strange dpkg error output and ensures proper upgrading for bzr/tomboy/xserver-xorg-input (I asked tfheen earlier, but he is currently away apparently)
<sladen> Lure: is that the multiple batteries?  I think there might be two problems (a) g-p-m not coping with multiple batteries.  (b) Us not handling hotplug events and fixing out how to get ACPI to 're-probe' for new batteries---I'm not entirely sure how to do the latter
<keescook> permission (and sponsorship) for a main upload?  fixes bug 65763.  debdiff/changes: http://people.ubuntu.com/~kees/edgy-fixes/
<Ubugtu> Malone bug 65763 in xorg "X configuration fails with NFS root (simple fix)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65763
<Lure> sladen: g-p-m has code for multi battery, but probably buggy in some special case
<mjg59> sladen: No, the kernel deals with battery hotplug fine
<Lure> mjg59: it does (at least here)
<Lure> mjg59: not sure how g-p-m handles it though
<Lure> sladen: bug is not linked just with plug/unplug battery, but also when both are loaded and first gets empty
<sladen> mjg59: I thought I saw that it only copes with battery hotplug /if/ /booted/ with both batteries inserted
<mjg59> sladen: No
<mjg59> Batteries are fine
<sladen> okay.  I don't have a Ultrabay battery to test
<mjg59> There's two types of evaluation with batteries
<mjg59> Whether the battery object is present, and whether there's actually a battery present
<keescook> mdz: since tfheen is out, can I ping you for upload permission?  (see above for bug and url)
<mjg59> The battery object is always present, so the kernel has no problem
* Lure cannot test as I am after resume (bug 63123) - will have to reboot first
<Ubugtu> Malone bug 63123 in acpi-support "battery info does not change after hibernate (HP nw8240)" [Undecided,Needs info]  http://launchpad.net/bugs/63123
<Lure> sladen: ^^ this is probably kernel bug
<Lure> sladen: but not relatated ;-)
<mjg59> Who is townsonu2003?
<mjg59> towsonu2003, rather
<sladen> mjg59: so BAT1 is present in the DSDT, but not populated?
<mjg59> sladen: It's present and the _STA method evaluates to true
<Burgwork> mjg59:  I have seen him in -marketing once or twice
<mjg59> Because he keeps reassigning random bugs to acpi-support
<mjg59> And I'd quite like him to stop
<Burgwork> mjg59: I have his email, you want to email him
<mdz> mvo: eating
<mdz> mvo: will have a look though
<mdz> keescook: yes
<mdz> keescook: looks ok
<keescook> mdz: great, thanks.
* keescook looks around for someone with core-dev privs to sign the upload
<mvo> mdz: no rush, thanks
<mdz> mvo: ok to upload
<mvo> thanks mdz!
<keescook> mvo: have a second to sign my upload?  :)
<mvo> keescook: please /msg me details
<bluefoxicy> bah there is no #ubuntu-legal
<Lure> mjg59: added note to gnome #361583
<Ubugtu> Gnome bug 361583 in gnome-power-manager "With Two Batteries, Twice as many Notification Bubbles" [Minor,New]  http://bugzilla.gnome.org/show_bug.cgi?id=361583
<Burgwork> bluefoxicy: what is the issue?
<bluefoxicy> Burgwork:  I'm confused about the MIT license is all, it seems to require "the above copyright notice and this permission notice" to be in tact but the disclaimer is below that and not mentioned as needed in tact.
<bluefoxicy> Burgwork:  Copyright (c) 2006 SomePerson, with no disclaimer of no warranty, when a second hand redistributes?  That sounds like it could put the copyright holder at risk; but I'm not a lawyer, so I don't know.
<mdz> Lure: is there hope?
<Lure> mdz: I will try to reproduce it (need to boot in gnome), if not I may build a test version to try for bug reporters - but it is still just theory... 
<ajmitch> morning all
<sivang> hey ajmitch 
<sfllaw> bluefoxicy: The best thing to do is to reproduce the entire copyright notice as well as the warranty disclaimer.
<bluefoxicy> sfllaw:  I'm the one writing the software ;)
<tfheen> keescook: aolserver4> universe; no idea.
<keescook> tfheen: should I re-upload it?
<tfheen> mvo: new dist-upgrader> looks ok.
<mvo> tfheen: thanks
<seb128> are uploads still accepted? 
<tfheen> seb128: what is it that you want uploaded?
<seb128> tfheen: dbus-glib to get a dbgsym, can probably wait after edgy though, I just noticed that there was no debug package when trying to get a debug bt for a crash bug 
<seb128> those dbgsym are handy, I'm becoming lazy to build a debug package :)
<tfheen> seb128: while useful; edgy+1?
<seb128> tfheen: works for me
<pitti> seb128: [nice to see them being useful] 
<seb128> pitti: yeah, they rock
<seb128> and apport rocks too, I really like the coredump attached
<seb128> I can get debug backtraces without relying on the submitter
<tfheen> keescook: sorry for being slow getting back to you; a reupload shouldn't be needed.
<seb128> and print variables from gdb, etc
<seb128> pitti: you rock :)
<tfheen> keescook: I'll chase it up
<pitti> seb128: and you!
<keescook> tfheen: okay, no problem.  it's not high priority.  :)
<seb128> pitti: thank *you* :)
* seb128 hugs pitti
<desrt> goodday, buntus
<pitti> hey desrt 
<desrt> pitti; got some flowers for your hair?
<pitti> desrt: will bring some!
<mvo> can someone approve my dist-upgrader upload please?
<pitti> desrt: in fact, I'm looking for a nice hostel ATM
* sivang wonders what is the occasion
<desrt> pitti; not staying at the hotel?
<desrt> or are you staying past the conference?
<pitti> desrt: well, during the conference we will, of course, but not after it for some holidays
<desrt> cool :)
* desrt has school :(
<pitti> hey rodarvus!
<desrt> 1 week is already a lot of time to miss.
<Kamion> mdke_: it is out of date - I said that because I'd checked :)
<rodarvus> hi pitti :)
<mdke_> Kamion: I downloaded it last week - shall I update it?
<Kamion> fabbione: live coming first> no idea, check the extents with isoinfo. probably
<ajmitch> pitti: what hotel are you at during the UDS week?
<seb128> desrt: hi. Did you mail Claire about UDS?
<Kamion> mdke_: as I say, it should be updated automatically on a regular basis
<Kamion> things that require human intervention will inevitably get out of date
<Kamion> (I have another update pending)
<Kamion> sfllaw: I'm rebuilding the livefses now, but I'm off to bed shortly
<desrt> seb128; yes.  i did.
<mdke_> Kamion: that would require a fair bit of work, and I don't have access to the server either. I'll update it shortly before Edgy goes out for the website
<seb128> desrt: ok, just making sure :)
<Kamion> sfllaw: alternates are close to RC now, so those are good to test
<desrt> seb128; i have yet to book my flight.  will do that tomorrow or later today
<seb128> desrt: k
<Kamion> sfllaw: either desktops will need to wait until tomorrow morning, or hassle somebody else in /people/ubuntu-cdimage to build them once the 'buildlive' processes running as cdimage@lithium (livefs builds) have finished
<Burgwork> desrt: is your hotel in SF?
<desrt> Burgwork; pitti, i think you mea
<Kamion> mvo: dist-upgrader accepted
<Kamion> mdke_: ok, thanks. it is out of date at present
<mdke_> Kamion: will add to todo list, when do you think the last upload will be before Edgy?
<sivang> can we still upload fixes to universe?
<tfheen> mdke_: we're going to accept some select updates on Friday.  Unless we see serious regressions when RC is out or in those, that's the last uploads for edgy main.
<mdke_> tfheen: sorry, I mean the last upload of installation-guide
<Kamion> mdke_: tomorrow probably
<Kamion> tfheen:   * en/appendix/preseed.xml, en/using-d-i/modules/lilo-installer.xml: Device
<mdke_> Kamion: great.
<Kamion>     name updates for no-more-devfs.
<Kamion> tfheen: ^-- pending installation-guide changelog
<Kamion> tfheen: I could upload it now, maybe
<mvo> thanks Kamion
<Kamion> tfheen: unapproved main: xorg/1:7.1.1ubuntu5 kdebindings/4:3.5.4-0ubuntu2 python-setuptools/0.6c3-1ubuntu4 xfdesktop4/4.3.99.1svn+r23428-0ubuntu2 human-cursors-theme/0.4-0ubuntu1 qt4-x11/4.2.0-1ubuntu5 python-central/0.5.6ubuntu2
<Kamion> tfheen: infinity/mdz will have to handle the queue when they're around; I need to go now
<mdz> I'm here
<mdz> for a bit
<Kamion> I've accepted my gfxboot-theme-ubuntu upload, since mdz approved it earlier (translation updates)
<Kamion> otherwise, got to run
<Kamion> mdz: see my comment about live CD builds above, once the buildlive processes are all gone
<mdz> Kamion: I can't stay long myself, need sleep
<mdz> didn't quite nail my $TZ change
<mdz> but I'll check before I go
<mdz> Kamion: gfxboot-theme-ubuntu isn't needed for RC?
<mdz> I'm heading back to the hotel but will be back online from there to do desktop CD builds
<Lure> mjg59: booted gnome, but cannot get g-p-m icon in tray 
<Lure> mjg59: did change option as always show icon, but does not help - any idea
<tfheen> Kamion: sorry, was afk
<tfheen> Kamion: what's the xorg diff?
<tfheen> mdz: once you're around; what's the diff for xorg?
<tfheen> mdz: python-setuptools and python-central are approved.
<rem64> hi all
<BHSPitLappy> yo
<rem64> is there someone here?
<keescook> tfheen: is that the xorg upload with my name on it? mdz approved it for fixing bug 65763
<Ubugtu> Malone bug 65763 in xorg "X configuration fails with NFS root (simple fix)" [Undecided,Fix committed]  http://launchpad.net/bugs/65763
<tfheen> keescook: ok, looks sane.  That is, if NFS is sane in any way.
<keescook> hehe
<sivang> Feisty , then it is :)
<tfheen> mdz: 23:23 < tfheen> mdz: python-setuptools and python-central are approved.
<tfheen> mdz: xorg seems approvable too.
<mdz> tfheen: they're needed for RC?
<tfheen> mdz: python-central fixes two RC bugs, at least.  We can accept it after RC if you'd rather have us do that.
<tfheen> python-setuptools isn't needed for RC, but it allows the use of -setuptools without 2.5
<mdz> tfheen: the python-central diff I saw looked non-trivial; how much review and testing has it seen?
<mdz> new set of ubuntu/desktop CDs are now up
<mdz> sfllaw: ^^
<tfheen> mdz: doko and mvo worked together a fair bit on reproducing the errors and fixing them today.
<mdz> tfheen: I've stared at it a bit more and I hope that it fixes more than it could break
<mdz> accepted that and xorg
<mdz> but I'm not convinced we should ditch the current candidate for these fixes; we will need all the time we can get to validate it
<mdz> kubuntu and edubuntu desktop builds in progress now
<tfheen> mdz: agreed.
<ogra> only desktop ?
<tfheen> mdz: I have no idea about kdebindings, qt4-x11 and xfdesktop4 in the queue and I am reluctant to accept human-cursors-theme.
<mdz> ogra: yes
<mdz> Oct 17 21:36:58 <Kamion>        sfllaw: alternates are close to RC now, so those
<mdz>  are good to test
<mdz> tfheen: kdebindings is an ftbfs fix and it isn't out of date, so it's not urgent
<sfllaw> Hurray!
<sfllaw> Will download now.
* ogra starts the rsyncs and goes for some hours of sleep ...
#ubuntu-devel 2006-10-18
<mdz> tfheen: qt4-x11 is a similar story
<keescook> what's the process for archive removal?  open bug with rationale, subscribe ubuntu-archive?
* mvo goes to bed
<mdz> keescook: yes
<bluefoxicy> ....
* bluefoxicy tests something
<tfheen> mdz: ok, let's hold those off, then.
<mdz> ok, all desktop/live is done except xubuntu, whose livefs is still building
<mdz> I'm falling asleep in my chair, will be back in the morning for tests
<bluefoxicy> hmm, I backgrounded readahead
* bluefoxicy modifies his boot file
<Burgwork> bluefoxicy: why did you background it?
<bluefoxicy> Burgwork:  to see what would happen, of course.
<Burgwork> bluefoxicy: given it was foregrounded to make boot faster...
<bluefoxicy> Burgwork: Windows XP has a readahead-like functionality where it does the readahead while loading drivers, for the purpose of letting the cpu-intensive driver initialization routines run while IO is happening on the disk; I'm working backwards from these thoughts
<bluefoxicy> Burgwork:  overall, the "perfect world" scenario would be that ALL I/O happens while the CPU is otherwise busy, so by the time anything needs files they're in memory.  I'm trying to see if I can get any closer to that.
<bluefoxicy> so far I'm not making any progress.
<Keybuk> doesn't that just involve fiddling with the I/O elevator?
<bluefoxicy> Keybuk:  I'm fiddling with readahead
<Keybuk> oh right?
<bluefoxicy> bootcharts that show the boot process waiting for readahead to finish, then huge IO spikes later down the line, do not impress me and I want to investigate why.  :/
<Keybuk> the huge I/O spikes down the line seem wrong
<Keybuk> what causes them?
<Keybuk> got a copy of the chart?
<bluefoxicy> no clue.  Other processes run after readahead are showing IO
<Keybuk> the chart should show you
<Keybuk> the box for the process will be pink
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061005-1.png  This is the first bootchart I took, unadulterated by any modifications to the boot process.
<bluefoxicy> a huge IO spike begins about 1.0 seconds after readahead ends
<bluefoxicy> (readahead() blocks blahblahblah this shouldn't happen)
<Keybuk> ricer fs?
<bluefoxicy> plus, yes as you said, many of the processes show pink boxes
<bluefoxicy> ext3
<bluefoxicy> I don't use murderfs
<Keybuk> that extra spike is weird
<bluefoxicy> extremely
<bluefoxicy> my next attempt is going to be booting with 'profile' to see if the log is just wrong.
<bluefoxicy> as it stands, backgrounding readahead has made it neither slower nor faster
<Keybuk> readahead should be in the foreground
<Keybuk> otherwise you'll be reading from the disk and skipping the head all over the place
<bluefoxicy> I got a second back by moving all of the /lib/modules lines to the top of the file
<Keybuk> oh
<Keybuk> that immediately after readahead spike
<Keybuk> I know what that is
<Keybuk> there's been an ABI change since I last updated the lists
<Keybuk> so that's it just copying the modules into a tmpfs
<Keybuk> that'll go away when I redo the list before release
<Keybuk> the second bump is PCI I/O -- not unusual during modprobing
<bluefoxicy> nods
<Keybuk> the third one is evms/lvm
<Keybuk> you can uninstall those
* bluefoxicy backs out his changes and reprofiles
<Keybuk> they're not deps of ubuntu-desktop anymore
<bluefoxicy> Keybuk:  does readahead() trigger a file read, or is it invisible?
<Keybuk> the fourth bump set is the log files being written
<Keybuk> dmesg, etc.
<Keybuk> bluefoxicy: it's a magic ioctl
<bluefoxicy> it should be technically feasible to actually profile and readahead() at the same time
<Keybuk> and the last bump is just X.org
<bluefoxicy> if you can detect which files were open(), close()'d
<Keybuk> bluefoxicy: the profiling is done with inotify
<Keybuk> so it detects open()/close() not actual read()
<bluefoxicy> yes, inotify can detect opens, writes, reads, ...
<bluefoxicy> IN_ACCESS          File was accessed (read) (*)
<bluefoxicy> IN_OPEN            File was opened (*)
<Keybuk> in_access is different
<bluefoxicy> there are also closed (no write) and closed (write)
<Keybuk> yes
<Keybuk> that's what the profiler looks for, checks the way the file is closed
<Keybuk> the point is that it can't tell the file is being open()d/close()d by readahead-list
<Keybuk> because inotify doesn't tell us the pid of what's doing the open
<Keybuk> can you try
<Keybuk> 1) remove evms/lvm
<Keybuk> 2) boot with profile
<Keybuk> and then boot again to get a new chart
<bluefoxicy> i don't think there's much interest in files being just open()/close()d without reading/writing
<bluefoxicy> (you know you can readahead() directories?)
<Keybuk> yeah there is, because the kernel will optimistically read the first block anyway on an open
<bluefoxicy> oh, heh.
<Keybuk> besides, finding an open()/close() without a read is cause for a patch <g>
<tfheen> Keybuk: not if it does mmap instead of read. :-P
<Keybuk> tfheen: well, yes
<Seveas> (or if it does write() instead of read())
<Keybuk> tfheen: I assume it's ok to update readahead, btw?
<Keybuk> I was planning to do the profile with the RC
<Keybuk> hadn't talked to you about it
<tfheen> Keybuk: we should be able to get that in when RC is out, yes.
<Keybuk> is just the one file in the source, after all
<bluefoxicy> Keybuk:  reordering based on position on disk seems silly.  Also what about actually detecting things like /lib/modules
<Keybuk> bluefoxicy: hmm?
<Keybuk> why does that seem silly?
<Keybuk> and how would one detect them?
<bluefoxicy> well, what if I have /lib/modules/2.6.17-10-i386/* in /etc/readahead/boot and I boot -generic?
<bluefoxicy> chances are the names of the modules stay the same...
<Keybuk> we don't put any /lib/modules stuff in the readahead list usually
<Keybuk> it's just the restricted modules stuff
<Keybuk> I generate the lists in vmware
<Keybuk> so they're almost certainly useless to anyone else in that regard <g>
* bluefoxicy just moved a bunch of it around, including ac97 codec
<Keybuk> why move it around?
<bluefoxicy> because I put readahead in parallel with the rest of boot and saw it stall around modprobe() running as modprobe started ganking files off disk and wanted to see what happened.
<Keybuk> oh, don't do that
<Keybuk> it's never faster in parallel
<Keybuk> because you're now reading at the same time as other things are reading
<Keybuk> and doing I/O
<bluefoxicy> 0:48 consistently in series vs 0:47 in parallel
<Keybuk> *shrug* that's not consistent with my testing
<Keybuk> see ubuntu-devel post of a few weeks ago
<Keybuk> if it's slow, it just means your list is off
<Keybuk> there's almost no CPU intensive stuff during boot
<bluefoxicy> alright, my re-profiled, series timings are 0:45... the chart looks much better too.
<Keybuk> can I see the chart?
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061017-8.png
<Keybuk> looks much better
<bluefoxicy> yes, a whole 3 seconds.
<Keybuk> 45 is about right
<bluefoxicy> Keybuk:  the reason I want to get lists not reordered by position on disk is because I want to test actually reading the files in the order they're being used-- i.e., attempting to run in parallel and stay slightly ahead of the boot process.
<Keybuk> you run -386 on an AMD64?!
<bluefoxicy> with DMA, I/O from disk is basically a blocker
<bluefoxicy> yes why
<Keybuk> why not -generic 386 or amd64?
<Keybuk> -386 is for plain old real 386s
<bluefoxicy> oh
<bluefoxicy> that's edgy on my laptop
<Keybuk> -generic is for other processors
<Keybuk> -386 has all the shiny optimisations taken OUT
<bluefoxicy> any other kernel (literally any, I have 12 installed) doesn't actually boot
<bluefoxicy> it just hangs for 10 minutes at a blank screen and then I press power
<Keybuk> bluefoxicy: what difference would that have (order being used) to just letting the boot read things as they're used in the order they're used ?
<Keybuk> 10 mins or 3 mins?
<bluefoxicy> Keybuk:  CPU,IO,CPU,IO series vs {CPU & IO} {CPU & IO} series
<lifeless> Keybuk: async lookahead I'm guessing. Certainly you want cylinder at a time though
<Keybuk> there's no CPU at boot though
<lifeless> bluefoxicy: you *really* want cylinder at a time reads
<AlinuxOS> When edgy starts, I've black screen before gdm... maybe it's my card issue: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M  <-that's my video card.
<bluefoxicy> aside from those BIG BLUE AREAS of CPU usage
<Keybuk> if we did anything CPU intensive at boot, then yeah
<bluefoxicy> Keybuk:  the capslock key won't turn on capslock
<Keybuk> bluefoxicy: there's just one
<Keybuk> and that's actually a bug in the bootchart code
<bluefoxicy> ah, ok
<Keybuk> it charts time in kernel as 100% CPU
<lifeless> anything other than cylinder at a time will result in massive multiples of head seek latency
<AlinuxOS> +(ah, it's a laptop)
<Keybuk> so you'll notice the three times are udev, ckbcomp (console setup) and hald
<lifeless> you might be able to go faster than block ordering by starting with the first used block, and doing cylinder at a time from there towards the next used block etc
<lifeless> Keybuk: ^
<bluefoxicy> I did lose a second in parallel
<lifeless> but: thats gonna be finicky to get right, as you'll need to know geometry
<Keybuk> lifeless: what if the next used block is behind the first used block?
<lifeless> Keybuk: then the first cylinder read is optimal - no delay, and the second cylinder read is one for the second block
<lifeless> note that I'm happy with the block ordering approach
<lifeless> I think its just fine
<Keybuk> if you want to tackle a better, go for it
<bluefoxicy> heh
<bluefoxicy> the only /lib/modules in my /etc/readahead/boot is soundcore.ko
<lifeless> I think it would be a PITA to consistently get better
<lifeless> and you'd want to be shuffling the required files on disk in fact at that point... into block order
<lifeless> so thanks, but I'll leave it as is
<Keybuk> I liked the idea of shuffling the entire boot read files into the first area of the disk in order
<Keybuk> some ext3 hackery
<bluefoxicy> Keybuk:  the other thing I was looking into was actually reading only specific sections of ELF files, particularly the parts used in dynamic linking
<Keybuk> any particular reason?
<bluefoxicy> with some heuristic where if the space skipped is less than like 16k just read it in anyway (so if .text has 9k that's not shared in 4k blocks not used by other pages...)
<bluefoxicy> Keybuk:  because the only thing needed to "start" a program is dynamic linking; and programs aren't likely to use "all" of their code.
<bluefoxicy> Keybuk:  gimme a sec.
<Keybuk> and the text
<bluefoxicy> libgtk is 3.4M, its text is 0x23aba4 bytes
<Keybuk> 2.4M ?
<bluefoxicy> Keybuk:  yeah, just about that
<Keybuk> you need more than .hash though
<bluefoxicy> of course.
<lifeless> Keybuk: there is a defraggerr
<Keybuk> the dynamic loader maps it all
<lifeless> Keybuk: probably a small amount of work to teach it to 'defrag only as much as needed to shuffle *these* to *here*
<lifeless> Keybuk: glib handwaving, you could do it from initramfs ;)
<Keybuk> most of libgtk-x11.so.2, unsurprisingly, is the .rodata and .text
<Keybuk> lifeless: boot the entire system from initramfs? :)
<bluefoxicy> .hash .dynsym .dynstr .gnu_version .gnu_version_r .rel.plt .rel.dyn .plt .rodata .data.rel.ro .got .got.plt .data are the ones I know are needed; .init .text .fini and .bss are the ones I know the dynamic linker doesn't need.
<lifeless> Keybuk: no, shuffle the boot files to the start of / and /usr
<Keybuk> .text is very needed
<Keybuk> very very very needed :p
<bluefoxicy> Keybuk:  not for the dynamic linker :)
<Keybuk> there's no such thing as "the dynamic linker"
<Keybuk> there's the dynamic link loader
<Keybuk> which uses .text to, err, load the .so
<bluefoxicy> ld.so then.
<Keybuk> that's the dynamic link loader
<bluefoxicy> um, not really :)
<Keybuk> and it certainly uses .text and .bss
<bluefoxicy> ld.so only touches .text if there are .text relocations, which there shouldn't be because they make loading a program slow.
<Keybuk> what planet are you on?!
<bluefoxicy> Earth, yoU?
<Keybuk> ld.so maps .text into memory
<Keybuk> because otherwise you can't run the code
<bluefoxicy> yes, but the kernel does not bring the data into memory immediately.
<Keybuk> it does
<bluefoxicy> ok so if I mmap() a 2GB database I need 2GB of ram?
<bluefoxicy> (I can do this, and I only have 1GB)
<Keybuk> if you mmap a 2GB file, and then scatter read different sections in it
<bluefoxicy> you'll wind up getting scatter IO
<Keybuk> then you'll need at least 2GB of virtual memory
<Keybuk> yes
<bluefoxicy> you won't need 2GB of virtual memory
<Keybuk> yes you will
<Keybuk> but the file itself counts
<bluefoxicy> if you WRITE to any pages and it's mapped PRIVATE you will.
<bluefoxicy> oh, right sorry :)
<bluefoxicy> I read VM as "swap" D:
<Keybuk> no
<Keybuk> I would have said "swap"
* bluefoxicy just finished a Windows XP professional class D:  blames that!
<Keybuk> if you open a 2GB file, and scatter reads across it
<bluefoxicy> Keybuk:  at any rate my point is that you won't immediately need all of .text
<Keybuk> then Linux would prefer to have as many blocks as possible in the page cache
<Keybuk> if you take libgtk as your example, the chances are you do want it the text the page cache :)
<Keybuk> as lots of things are going to use it
<bluefoxicy> you'll need parts of it; you'll probably need .init as well but since it's wedged between .plt  and the REL sections and is small any heuristic you use will probably read it in anyway.
<bluefoxicy> Keybuk:  yes but you might need i.e. 1 meg of the 2.4 megs of text in GTK in the first hour you're using it
<Keybuk> doubt it
<Keybuk> prove it
<lifeless> Keybuk: 'defrag -i inode-priority-file'
<Keybuk> if you need 1M of the text, chances are you'll only have 1M in the page cache
<Keybuk> Linux is good at this
<Keybuk> not great, but good
<bluefoxicy> you can prove it by instrumenting do_no_page() in the kernel
<bluefoxicy> but I don't feel like doing that :)
<bluefoxicy> so we'll leave it conjecture.
<lifeless> Keybuk: it will need a patch to only optimise the inodes desired, rather than the entire fs
<bluefoxicy> Keybuk:  that's my point.  If you readahead() a whole elf file you read all the text into the page cache; but then, you have to wait while readahead() blocks reading a multi-megabyte file.  As opposed to possibly reading 1 meg
<bluefoxicy> or on some elf files 24K of their whole 76K size (zlib specifically)
<lifeless> Keybuk: and an update to ext3 :(
<Keybuk> blockwise readahead would be required for that
<bluefoxicy> It may be a worthwhile gamble to read only those portions, then read the .text and .bss in parallel
<bluefoxicy> Keybuk:  readahead() does that
<bluefoxicy> it reads in 4K chunks :)
<bluefoxicy> ssize_t readahead(int fd, off64_t *offset, size_t count);
<Keybuk> i mean profiling
<Keybuk> we don't currently have any way to tell which blocks are read
<bluefoxicy> Keybuk:  the only issue is that 1) the first pass is going to read-short seek-read; 2) the second pass is going to be going over the file system in .. a second pass.
<bluefoxicy> Keybuk:  I'm not talking about predicting what parts of .text are used though.
<Keybuk> eh?
<bluefoxicy> I'm talking about, say, if you spend 0.6 seconds reading in all of libgtk+, when you could spend 0.2 seconds and then (possibly) lose 0.1 more (total 0.3) to not having a part of .text in
<bluefoxicy> the idea is to try to take a shortcut, not to superprofile; if you can superprofile go for it
<lifeless> bluefoxicy: the problem with unprofiled shortcuts is that they can be long cuts
<bluefoxicy> lifeless:  nods, I have not ruled out that possibility.  That chart shows readahead-list taking 13.5 seconds of boot time though, which is a pretty big cut.
<bluefoxicy> brb
<lifeless> I thought readahead list backgrounded ?
<bluefoxicy> no, it doesn't
<bluefoxicy> I tried backgrounding it, I lost a second on the last test, some tests I lost nothing.
<bluefoxicy> Keybuk:  write_list says the files are sorted by device and inode number
<Keybuk> yes
<bluefoxicy> that's how you get them in order on disk?  :P
<Keybuk> that's what you call "commenting the code before you write it"
<Keybuk> no
<Keybuk>                 /* Scary ioctl shit */
<Keybuk>                 opened[i] .block = 0;
<Keybuk>                 ioctl (fd, FIBMAP, &(opened[i] .block));
<bluefoxicy> ah, lol
<Keybuk> opened_cmp then uses dev, block, ino
<bluefoxicy> ok
<bluefoxicy> but that line is where they're actually sorted?
<bluefoxicy> ("by device and inode")
<Keybuk> that line just calls qsort and passes in the sort function defined above
<Keybuk> which you'll see also sorts by block
<Keybuk> look at the code, not the comments :p
* bluefoxicy still is annoyed by bootsplash not telling him anything besides that there's a bar that's half way across.
<Keybuk> remove "quiet" from the kernel command-line ?
<bluefoxicy> ok this is annoying, I think it keeps running fsck after every reboot :(
<bluefoxicy> on /, specifically
<bluefoxicy> but I've seen /home once
<bluefoxicy> did I fall on "too many mounts" and "180 days have passed" at the same time or something, cheriste
<bluefoxicy> oh god I have a separate /boot too, what was I smoking when i installed
<bluefoxicy> I've LITERALLY had fsck run because "it's time" over 10 times in the past hour
<shackan_> is vmware-player broken again ? (no bugs on lp)
<Chipzz> shackan_: afaik there's no way to run vmware player on edgy
* shackan_ has a stroke
<Chipzz> vmware player uses a different version of libdbus than the rest of gnome
<Chipzz> which is of course abi incompatible
<Chipzz> errr
<Chipzz> api
<Keybuk> that got fixed, no?
<shackan_> why the hell does vmplayer need dbus ?
<bluefoxicy> GOOD LORD
<Keybuk> shackan_: everything uses dbus now, didn't you get the memo?
<sivang> indeed, why is that?
<Keybuk> they're rewriting the kernel as a micro-kernel on top of dbus
<bluefoxicy> I have rebooted THREE TIMES trying to get it to not fsck, it always says the FS is clean on multiple file systems, is there a 'nofsck" i can pass on the command line or what
<Chipzz> Keybuk: no
<Chipzz> chipzz@Reel:~$ apt-cache show vmware-player | grep Conflicts
<Chipzz> Conflicts: libdbus-1-2
<HrdwrBoB> bluefoxicy: you can set it in /etc/fstab
<shackan_> Keybuk, you're scaring me, seriously
<Chipzz> which I think should actually be Conflicts: libdbus-1-2, libdbus-1-3
<bluefoxicy> HrdwrBoB:  what is that, 0 0?
<HrdwrBoB> bluefoxicy: man fstab, I can't remember :)
<Chipzz> bluefoxicy: you can use tune2fs
<bluefoxicy> Chipzz:  I've had /home, /boot, and / fscked like 12 times now
<bluefoxicy> after clean reboots
<bluefoxicy> HrdwrBoB:  that did it
<Chipzz> bluefoxicy: use -c max-mount-counts
<bluefoxicy> wait, no, no it didn't.
<Chipzz> first option in man tune2fs
<bluefoxicy> Chipzz:  should it fsck one boot, then the immediate following boot, then the immediate following boot, saying something about "mounted 30 times"?
<Chipzz> I'm not sure if you need to set it to 0 or -1 or some insanely high value; anyway, it's possible
<bluefoxicy> and every time tell me fsck exited with status 1
<Chipzz> bluefoxicy: did you ctrl-c the e2fsck?
<bluefoxicy> no
<bluefoxicy> but I'm about to rm -f the e2fsck
<Chipzz> bluefoxicy: just do tune2fs -C 0
<Chipzz> that should get rid of it too, except if your fs is not clean
<bluefoxicy> Chipzz:  tell usplash to say "Hold on, busy fscking myself" when it does this.
<Chipzz> ?
<bluefoxicy> that's weird
<bluefoxicy> it's only doing it when I "Profile"
<Keybuk> you sure it's the fsck?
<bluefoxicy> but eevery time I profile it tells me /boot and /home are clean and / is clean and fsck exited with exit status 1
<bluefoxicy> Keybuk:  this laptop is the victim of a violent edgy upgrade
<bluefoxicy> it's quite likely I busted something.
<Kamion> thom: do you care about pygsm any more? see bug 65376
<Ubugtu> Malone bug 65376 in pygsm "[UNMETDEPS]  pygsm has unmet dependencies (and FTBFS)" [Undecided,Fix committed]  http://launchpad.net/bugs/65376
<malex> Hi. Who should I contact to raise a grievance about an unauthorized import of an upstream project into Rosetta?
<Kamion> malex: #launchpad would be a better place to start than here, at any ratee
<Kamion> rate
<malex> Kamion: thanks, will go there.
<Keybuk> "unauthorised?"  are your .pot files non-free?
<bluefoxicy> hmm weird.  /etc/readahead/boot isn't sorted yet..
<Keybuk> bluefoxicy: sorted?
<malex> Keybuk: Unauthorized according to the Ubuntu's own Rosetta import policy ;)
<Keybuk> malex: yeah, then #launchpad is your best bet
<bluefoxicy> Keybuk:  I commented out the qsort line.  http://bluefox.kicks-ass.org/stuff/bluefox/images/rah/ both those are readahead in parallel, both measure 1 second slower than readahead in series
<Keybuk> really?
<Keybuk> should be no difference :)
<Keybuk> readahead-list sorts them anyway
<bluefoxicy> does it?  I commented that out...
<bluefoxicy> wait
<bluefoxicy> you're sorting in readahead-watch AND in readahead-list?
<Keybuk> yeah
* bluefoxicy code grinds
<Keybuk> why not/
<Keybuk> no point not sorting in -watch, it's not time critical
<bluefoxicy> because..... you're doing work in readahead-list that you don't have to :P
<Keybuk> it doesn't cost much
<Keybuk> a sort of that list takes nanoseconds, even on a slow processor
<Keybuk> and it's gain is immense for non-profile'd list
<bluefoxicy> which only happen when someone like me decides to try and hack it out of the way to see what happens
<bluefoxicy> I'm still surprised there's like 119 modules being loaded but you don't readahead those
<Keybuk> *shrug*
<Keybuk> can't predict the module list
<Keybuk> the entire point of modules is that everyone has a different combination
<bluefoxicy> yes I'm aware.  profile for me generated like, 1 module (soundcore.ko) in the list.
<Keybuk> that's odd
<Keybuk> profile should give you them all
<Keybuk> it's just the default ones we don't ship modules in
<Keybuk> (and even there I've experimented with shipping the common ones like usbcore :p)
<bluefoxicy> and you're right again.  I lost 3 seconds not sorting the list.
<Keybuk> :)
<Keybuk> I did spend a fair amount of time writing this
<Keybuk> and testing it
<sivang> hmm, why does apt-cache show $pkg now shows two instead of one section of packag info?
<jdong> :)
<jdong> Keybuk: and I spend a great deal of time abusing it....
<bluefoxicy> Keybuk:  yes, I'm aware.  :)
<jdong> like preloading OOo, Firefox... KDE.... ;)
<Chipzz> sivang: no, but it can show 2 packages
<Keybuk> not to mention figuring out the best way to make it work
<sivang> Chipzz: it does this for me by default for certain packages, does it show both source and bin now?
<Chipzz> sivang: no, it shows installed and in the archive
<sivang> Chipzz: I see
* jdong still feels that there's still ways to do limited parallelized readahead without causing too much seeking....
<Chipzz> sivang: it does that if the version you have installed is not the last
<bluefoxicy> Keybuk:  it DOES give me all the linux-restricted-modules
<jdong> Keybuk: I was thinking about allowing readahead to slurp while all the module inserting is being done, then having a Sxxreadahead-wait script stall until readahead finishes before continuing
<sivang> Chipzz: has it always done so ? ;)
<Chipzz> yes
<Chipzz> try apt-cache policy
<Chipzz> sivang: it also does so if for example you have both dapper and edgy entries in your sources.list
<Chipzz> apt-cache policy package
<Chipzz> jdong: first reading all modules, then loading udev + reading all the rest makes more sense to me
<jdong> Chipzz: why not do readahead while the IO is not really being used, like while modprobing
<jdong> or bringing up networking
<jdong> because if you readahead while something IO-intensive happens, it's a lose-lose
<Chipzz> jdong: probing modules *does* io
<jdong> not nearly as much
<jdong> as, say, loading dbus
<Chipzz> but still conflicting
<jdong> Chipzz: it's just one thing I was gonna try....
<Keybuk> jdong: I'd rather just get rid of the sleep :)
<jdong> ooh! ooh! move gdm to /etc/rc2.d/S01!
<jdong> (surprisingly it actually didn't break when I tried that)
<Chipzz> jdong: starting udev takes such a long time that I figure you can do most of the readahead (say 70% - 80%) in the background while starting udev
<Nafallo> we're not going to have rc*.d for much longer I thought? :-)
<Chipzz> that is, if you're not getting conflicting io from loading modules
<Chipzz> but then, I'm just guessinhg
<Chipzz> I have no actual figures to back this up
<bluefoxicy> that's odd.
<bluefoxicy> I removed all .so files and the boot time was 46 seconds
<bluefoxicy> I put it back in series (instead of parallel) and the boot time went up to 47 seconds...?  o.O
<jdong> bluefoxicy: I have 1 second fluxuations between boots anyway....
<bluefoxicy> (that's certainly a useless testcase)
<bluefoxicy> jdong:  really?  Mine seem to be rather consistent until I start messing with things.
<jdong> my bootcharts show 36 and 37
<Fujitsu> Kamion, thanks for sending that email to -devel about setting statuses to Rejected... Those antics this morning will have spammed the inboxes of many hundreds of people :S
<jdong> 377 when fsck decides it's the lucky day :D
<jdong> (hint hint do something about periodic fscks hint hint)
<bhale> tune2fs -i 0 /dev/hdX is left as an exercise to the user
<Kamion> Fujitsu: I think there's some fundamental miscommunication somewhere about how duplication is supposed to work, but it's too late for deep thoughts about it
<Kamion> (too late at night, I mean)
* Kamion notes that Testing/Current wants him to test the amd64 DVD, and gets downloading
<Keybuk> Chipzz: starting udev takes no time at all
<bluefoxicy> Keybuk:  give me something to make the little man inside my computer run faster.
<Kamion> best rebuild the DVDs, too
<Chipzz> Keybuk: hrrrm right, udev backgrounds itself, right?
<Keybuk> Chipzz: right, but it's also a very small C program
<Keybuk> it just opens a socket, listens and that's it
<Keybuk> hardly a time-consuming part of the boot process
<Keybuk> the time-consuming bit is the massive sleep() I put in there, because I'm a coward
<Chipzz> Keybuk: in the c code, or in the startup script?
<Keybuk> it's in the C
<Keybuk> udevsettle is just a loop and sleep
<Keybuk> we won't need that for feisty
<Nafallo> oh? is edgy+1 named?
<bluefoxicy> Keybuk:  the joys of artificial improvements
<Keybuk> bluefoxicy: "artificial" ?
<jdub> foxy!
<bluefoxicy> "should we remove bluescreen_test() from loaddriver.c?"  "Yeah sure"  "Alright... *scribble*  WindowsXP... now more stable... with better ... driver... support."
<Keybuk> hmm?
<Keybuk> udev is a huge improvement on the nothing we had before
<bluefoxicy> Yes but you put a big sleep loop into it to let it 'settle'... I assume it has some sort of race condition and needs to settle down after loading?
<Keybuk> sure it's slower than compiling the modules you need into the kernel, but that kernel compile is a bitch <g>
<Keybuk> nah
<Keybuk> the race condition is in the rest of the boot process
<Keybuk> assuming things like "I can mount any hard drive I like now"
<Keybuk> or "if I ifconfig eth0, it'll be there"
<bluefoxicy> ah
<Keybuk> half the reason we wrote upstart
<Keybuk> means we can get rid of that sleep
<bluefoxicy> yeah I was gonna say upstart can wait and get triggered on events can't it
<sladen> ah, welcome to late-night flaming action on #ubuntu-devel
<pygi> :P
<bluefoxicy> sladen:  oh psh, I'm just being a pest
<bluefoxicy> if you want I can bring up the microkernel vs monolith argument, but you'll have to coax Linus into the chan
<sladen> six of one and half a dozen of the other :)
<pygi> bluefoxicy: don't do that!
<bluefoxicy> pygi:  lol :)
<jdong> bhale: oh, this user is a linux nerd who seems stereotypically allergic to exercise.... ;)
<Keybuk> sladen: but bluefoxicy is *so* cute!
<bluefoxicy> I am
* sivang wonders what makes someone cute
<pygi> sivang: !!!
<Nafallo> sivang: the beard :-)
<bluefoxicy> I don't have a beard
<sladen> depends where the 'beard' is
<bluefoxicy> Keybuk:  wait you're not another dirty old man stalking me are you?
<pygi> sivang: pm pls?
<bluefoxicy> I have 2 or 3 guys over 30 that want to get on a plane already, I don't need more  D:
<sladen> ooh, can we all join in?
<Keybuk> bluefoxicy: I'm not old, nor stalking you ... but I am dirty, yes
<bluefoxicy> restraining orders are expensive you know
<jdong> bluefoxicy: how dare you insult hans reiser ;)
<sivang> sladen: hehee
<sivang> sladen: ROTFLs
<Keybuk> bluefoxicy: sugar daddies are so useful though
<bluefoxicy> jdong:  He murdered the Unix file system D:
<bluefoxicy> with his nonstandard crap
<bluefoxicy> (i.e. lack of xattrs)
* jdong resists using his list of tasteless filesystem jokes
<sladen> perhaps he just tried to fsck it and ended up with a bloody mess
<pygi> bluefoxicy: dude, can you write a FS as least half as good as reiser? No? The be shhhh...
<bluefoxicy> jdong:  perverse file system lymerics?  :)
<bluefoxicy> pygi:  I should
<jdong> aww, come in... it's just about efficient storage of small bits....
<jdong> ;-)
<bluefoxicy> but I don't know enough about the unix file system to get all the features right
<bluefoxicy> and I have no concept of extents
<sladen> jdong: yeah, just build a tree on top once you've nearly arranged all the little pieces
<bluefoxicy> I did independently come up with encoding inodes' physical addresses into their inode numbers, but found out 2 days ago that that's in XFS
<jdong> :)
<bluefoxicy> trees suck
<bluefoxicy> O(1) look-ups
<jdong> whatever you say man
<jdong> :)
* pygi agrees with jdong :P
<Keybuk> totally
<sivang> jdong: I invented jet propoltion, not Larry Wall :)
* sivang admits this is late night and his spelling might be off the cliff
<jdong> well.... I invented broken packages
<jdong> oh wait...
<bluefoxicy> I still don't know how to account free/used space and quotas properly (run the system without tracking quotas ... and quotas are messed up); or get a O(1) on looking up file names in a directory tree :/
<Kamion> mdz: I registered ubiquity-driver-updates before seeing install-with-third-party-drivers. Which should we keep?
<_ion> Yay, arguments! KDE is better than Vim!
<bluefoxicy> directory tree to me looks like it'd be best implemented as a Patricia Trie
<bluefoxicy> where you literally read one string (granted, broken at places) and you're done
<Keybuk> wasn't she a drag queen?
<pygi> _ion: lol :)
<sivang> Keybuk: hehe
<jdong> pfft, vim rules, everyone should use reiserfs, ubuntu should adopt portage, why aren't we using -O3 -ftree-vectorize -ffast-math, 686 and k7 kernels should return....
* sivang notes this is getting funnier
<jdong> <insert flamebait here> :)
<pygi> jdong: you are wrong, we should adopt conary and pacman 
<jdong> AND FORUMS BEAT IRC ANY DAY
<jdong> :D
<sivang> jdong: only the 686 kernels ;) (oh dear, I killed another kitten)
* Fujitsu hits jdong.
* jdong ducks
<pygi> jdong: too late =)
<Fujitsu> Far too late, jdong.
<jdong> :(
<_ion> jdong: We should move bug tracking from launchpad to the forums!
<jdong> yeah!
<jdong> hey, it'd still be easier to use than KDE's BTS
<pygi> _ion: I disagree, use irc for bug tracking!
* jdong ducks again
<sivang> we should write an LP bot for that
* pygi makes jdong stand up and waits for _ion ...
<jdong> sivang: hah! that's a wonderful idea
<Keybuk> we should just use tfheen for bug tracking
<sivang> Keybuk: is he a bot now?
<Nafallo> lol
<jdong> a LP bot would be great for drive-by bug reports!
<jdong> (which I certainly don't partake in)
<jdong> ;-)
<Keybuk> drive-by bug fixing is far more fun!
<jdong> it sure is
<jdong> :)
<pygi> =P
<bluefoxicy> it's tuesday
<pygi>  !driveby fix bug #32542
<Ubugtu> Malone bug 32542 in nautilus "It's difficult to save a Nautilus search" [Unknown,Unconfirmed]  http://launchpad.net/bugs/32542
<bluefoxicy> I never could get the hang of tuesdays
<jdong> lol
* _ion would make a joke about launchpad filling up with lilo's Freenode announcements, but unfortunately we don't get to enjoy them anymore.
<HrdwrBoB> it's not tuesday here
<bluefoxicy> I'm actually good with thursdays though.
* jdong has never seen #ubuntu-devel so wacky
<Keybuk> _ion: there's a tasteless joke about hans reiser in there somewhere :p
<Nafallo> jdong: oowrite!
<Keybuk> bluefoxicy: it's wednesday here
<Kamion> mdz: do I need to repropose ubiquity-advanced-partitioner for uds-mtv, or can we just carry it over? (I don't think it desperately needs further discussion)
<sivang> it's wedensday here
<Keybuk> Kamion: mdz is in London, no?
<Keybuk> so probably asleep :)
<Kamion> Keybuk: if he doesn't read scrollback, I can always ask him again later
<Keybuk> the way I understand our earlier discussion though, one shouldn't propose specs that don't need more discussion
<Kamion> I wasn't expecting an immediate reply
<bluefoxicy> Keybuk:  wednesday is better, special on hotdogs
<sivang> heh
<jdong> bluefoxicy: as far as I'm concerned, it couldn't get worse for me than today
<Kamion> I suppose that means I'll have to actually think of other stuff I want to do for edgy+1 then, otherwise my slate is going to look artificially empty in MTV
<sivang> jdong: how so?
* jdong got CD-R shrapnel embedded in his arm today :)
<bluefoxicy> lol
<jdong> apparently the robotics team wanted to see if spinning a CD-R at 50,000 RPM would cause it to fail
<sivang> lol
<jdong> and I walked into the room as they plugged the motor into the 220V transformer
<HrdwrBoB> hahahahaa
<Keybuk> bluefoxicy: eww, icky
<sivang> jdong: *LOL*
<jdong> it hurt... but we all had a laugh
<bluefoxicy> Keybuk:  you don't like hotdogs?
<sivang> jdong: good thing they didn't want to test that with metal hard drive platters :)
<jdong> and oh yeah, don't spin CD's at 50000 RPM :)
<Chipzz> bluefoxicy: 02:34 < bluefoxicy> I never could get the hang of tuesdays >> Hitchhikers Guide to the Galaxy quote? :)
<jdong> but there's a lesson to be learned in all of this
<bluefoxicy> Chipzz:  near quote
<bluefoxicy> Chipzz:  Thursdays, really.
<Chipzz> well, yeah :)
<Keybuk> bluefoxicy: nope
<sivang> jdong: the lesson be ?
<Chipzz> and I think there's a 'really' too in the real quote
<bluefoxicy> Keybuk:  so much for rob's business model
<jdong> when chosing between reiserfsck and putting the platters on a 50000 motor, the latter at least puts on a show before imploding your data
<Keybuk> bluefoxicy: rob's business model?
<jdong> :)
<bluefoxicy> Keybuk:  yeah, he runs a small cafe along the pride parade route
<bluefoxicy> whenever there's a parade he runs a special on hotdogs as a joke
<_ion> jdong: Didn't they know that MythBusters already proved CDrs break down and easily injure people under such RPM rate? :-)
<bluefoxicy> (I'll let you figure it out)
<Keybuk> aren't whistles more traditional?
<jdong> _ion: well, we here take much more of a DIY approach
<bluefoxicy> Keybuk: hotdogs are longer
<malex> Does anybody know a live email for the Rosetta OR/AND Launchpad contact? I tried rosetta@launchpad.net, but it's dead.
<elmo> malex: it's not dead
<Keybuk> bluefoxicy: the real thing is less ... mustardy
<bluefoxicy> Keybuk: rofl
<bluefoxicy> Keybuk:  I hope you know I am holding back dozens of comments right now :)
<malex> elmo: To: rosetta@launchpad.net; Undelivered Mail Returned to Sender; localhost.kvota.net[72.36.154.77]  said: 554 <danilo@localhost.kvota.net>;     Relay access denied (in reply to RCPT TO command
<Keybuk> bluefoxicy: oh, why?
<malex> elmo: It is not a deliverable address.
<bluefoxicy> Keybuk:  Ask the man from Nantucket when you see him
<bhale> bluefoxicy: thats enough of that
<elmo> malex: that's only one of the people on the address
<bluefoxicy> bhale: not a fan of Jay Leno?
<Keybuk> bluefoxicy: no wonder you stay indoors ;)
<bluefoxicy> bhale:  best to be getting back on topic anyway
<bhale> right.
<malex> elmo: Thanks for the info. There was no way for me to know how many forwards there were.
<bluefoxicy> Keybuk:  oh geeze.  I seriously thought that was obscure enough you'd have to look it up.  Then again Leno used it once so
<Keybuk> bluefoxicy: did you need a rib removed? or naturally flexible? :p
<bluefoxicy> Keybuk:  enough :P
* Keybuk has no shame
<Keybuk> or moral limits, for that matter
<Keybuk> I win at this game <g>
<bhale> you're lucky my access level is on the other nick
<bluefoxicy> Keybuk:  I have no shame or moral limits, I just have a higher probability of getting banned :P
<bhale> I havent banned you in ages
<bluefoxicy> lol
<bhale> starting to have withdraw
<bluefoxicy> Yeah I was wondering if you were crawling under the covers with a magazine of old ban logs
<bluefoxicy> and a disconnected optical mouse
<bluefoxicy> anyway I'm going to search for food before somebody draws me into another indeterminite conversation
<Nafallo> food
<Nafallo> hmmm
<Nafallo> LTNS etc...
<Nafallo> brb
<Keybuk> LTNS?
<bhale> long time no see
<Keybuk> ahh
* sivang pokes in apt/algorithms.h
<Nafallo> my mom has just signed on a lifetime buying of this cheese for me :-)
<pygi> !
<bluefoxicy> Keybuk:  will upstart be able to parallelize where proper?  (I microwaved a stale brownie; brownies are never stale)
<bluefoxicy> Nafallo: cooper sharp or feta?  I can eat a whole block of feta; it's like a sport, eat more than a small handful without vomiting.
<jdong> bluefoxicy: have you ever tried putting a wifi device in a microwave before?
<Keybuk> bluefoxicy: it starts all jobs at the same time for a given event
<jdong> (not turn it on, of course!)
<jdong> it's surprising how much leakage you get out of it
<bluefoxicy> Keybuk:  awesome.
<sivang> all this C++ can turn a dude blind
<Keybuk> so if you have two jobs with "start on tuesday", then they both start at the same time when the tuesday event occurs
<Keybuk> start on hotdog
<Keybuk> stop on mustard
<Keybuk> *ahem*
<bluefoxicy> haha
<sivang> hehe
<jdong> sivang: instinct would tell me not to touch apt's source code, and if I did, to stay clear of anything that hints algorithms :D
<bluefoxicy> sivang: if I saw a plusplus I would go blind too.
<jdong> bluefoxicy: doubleplus seegood?
<sivang> I just so wonderfully astonished at pkgProblemSolver,
<pygi> jdong: what's wrong with apt code?
<bluefoxicy> jdong:  I try to stick to C
<sivang> such that I wanted to have a peak in its guts
<Nafallo> bluefoxicy: more something like: http://www.cheese.com/Description.asp?Name=Herrgardsost :-)
<sivang> how kinky o me
<jdong> pygi: sounds intimidating. that's what
<pygi> jdong: not really, trust me
<jdong> I'll take your word for it
<jdong> but it's still on my personal don't-go-near-it list
<pygi> heh :)
<Nafallo> bluefoxicy: but this one is ripened for atleast 12 months :-)
<bluefoxicy> Nafallo:  sort of like swiss?
<pygi> jdong: that way nothing good will ever become
<jdong> pygi: nothing good ever would become if *I* touch its source
* bluefoxicy hates swiss cheese, prefers sharp cheeses like cheddar or cooper sharp, but also enjoys muenster.
* jdong typically is a hack-and-experiment type of person
<Nafallo> bluefoxicy: whatever the page says. I mostly eat the swedish cheeses :-)
<pygi> problems in the history were solved by touching what seemed untouchable, by trying to solve what seems unsolvable
<sivang> pygi: you know anything in algoithms.{h.cc} ?
<Nafallo> bluefoxicy: the well-ripened ones ;-)
<jdong> pygi: have you ever written a linux defragger :D? As I said, 99% of the things I've done I'm ashamed to admit :)
<sivang> pygi: I agree, that was my thought when tryin to read it :)
<pygi> jdong: why would you ever be ashamed of writing anything? heh
<bluefoxicy> pygi:  if your code looks like mine you would be.
<pygi> jdong: so what is it's bad, useless, or something. It's a piece of art, snapshot of your mind in given momemnt. 
<jdong> a linux defragger? an auto-backporter? a legacy terribly hackjobbed auto backporter? Portage for Ubuntu hacked?
* Nafallo thought it was funny that cheese.com was there ;-)
<jdong> hehe
<sivang> pygi: but I changed my mind now :p
<bluefoxicy> jdong:  make portage emit ubuntu .debs
<pygi> o dudes, that's such a negative attitude
<jdong> bluefoxicy: that's a great idea
* jdong pulls up his portage-ubuntu bzr branch
<Keybuk> apt-emerge
<pygi> jdong: my first songs sucked...as did my first steps on  the guitar
<pygi> so should I be ashamed of that?!
<sivang> jdong: HEHE
<jdong> I roughly hackjobbed the concept of portage asking dpkg/apt for dependencies
<jdong> but the rest of it is still portage style
<bluefoxicy> jdong:  I think you can build a dependency graph and actually get apt to apt-source and dpkg-buildpkg as well.
<jdong> apt/dpkg is still blissfully unaware of portage meddling in /usr
<bluefoxicy> jdong:  but I haven't tried, I don't want to try to build a tree of deps and build deps
<Keybuk> apt-get build-dep $src && apt-get source -b $$src
<zul> *sigh* if you want to use portage use gentoo
<jdong> bluefoxicy: I'm personally more interested in the concept of ebuilds in that a "version bump" is a simple rename
<jdong> zul: but I want ubuntu :)
<bluefoxicy> jdong:  nods, that's much <3's
<jdong> zul: I came from Gentoo camp
<pygi> jdong: so answer? :P
<zul> jdong: yeah so did i, doesnt mean i want portage
<jdong> pygi: I'm not all that confident :)
<bluefoxicy> jdong:  If you want something realistic, I still want kernels in backports  :D
<jdong> zul: I don't miss all of portage... :)
<jdong> bluefoxicy: I'm almost afraid to say it, but me too :D
<bluefoxicy> (I WANT 2.6.18 with REALTIME preemption, but it won't happen until Edgy+1)
<bluefoxicy> jdong:  and a mascot akin to ArOS'
<pygi> bluefoxicy: heh
<jdong> bluefoxicy: and I suppose you want compressed memory.. oh wait... you do
<pygi> bluefoxicy: why don't you help it happen then?
<pygi> things don't fall off the sky, you know ... ok, except comets
<jdong> pygi: you mean coming to #ubuntu-devel day after day talking about it isn't the way to make it happen?
* jdong just had his life turned upside down
<bluefoxicy> pygi:  I think it's more policy that there isn't a kernel backport process
<jdong> bluefoxicy: sure, let's hammer it out. I say make edgy kernel backport happen and it magically does
<jdong> minus the build failures, the likely udev incompatibiltiy
<jdong> meh
<jdong> I can dream
<sivang> jdong: hehe
<bluefoxicy> jdong:  udev broke one time (after Dapper was released); and predictably, if you backport a kernel and udev breaks, you have to backport udev too
<pygi> jdong: so tell me, should one be ashamed of his/her's first hello world application?
<jdong> pygi: depends on what it did
<bluefoxicy> jdong:  but again, nobody is going to allow something like udev, a kernel, or X to be backported ever
<bluefoxicy> there's good reason for this
<pygi> jdong: why would it depend?!
<jdong> pygi: mine was written in Visual Basic 6 on Windows 98 :)
<sivang> I am ashamed of mine ;)
<jdong> pygi: and it said "VB6 forever"
<bluefoxicy> jdong:  I have vb6 installed under Wine I think
<sivang> jdong: HAHAHA
<pygi> sivang: o joys, why is that!?
<pygi> even if the app DID NEVER START, it was something yours
<sivang> pygi: it's a point, but frequently when I look at stuff I did in the past, I think "what the f$# was I thinking"
<jdong> pygi: well, technically for(;;)fork(); starts.... it's just that starting is the problem :)
* pygi can find the at least a of masterpiece in every little part of this world
<bluefoxicy> jdong:  psh
<jdong> that was actually my first unix hello world program
<jdong> my "friend" told me to do it
<Keybuk> sivang: it's even more worrying when you realise people are still using things you did in the past that you think are shit
<jdong> on a shared server
<jdong> Keybuk: you mean like the guy who told me the other day that he's recommending pyfragtools to all his linux friends?
* jdong shudders
<bluefoxicy> jdong:  echo '#!`:(){ :&:; }`' > ./it.sh ; . ./it.sh
<Keybuk> the number of people on this channel using dircproxy
<bluefoxicy> jdong:  no compiler needed ;)
<jdong> bluefoxicy: pssh python ;-)
<bluefoxicy> jdong:  actually, check this out.
<sivang> Keybuk: oh goodness, I am both sorry and happy I still did not reach this point ;) (argh! another kitten)
<pygi> heh
<jdong> can someone resolve collegegeek.org for me?
* pygi just doesn't get why people are being so negative all the time
<pygi> cheer up :)
<jdong> my DNS server is down
<pygi> sure, sec
<sivang> pygi: having a bad year ;)
<jdong> Ubugtu should have a !resolve feature :D
<Nafallo> jdong: 64.191.182.77
<pygi> sivang: you must mean bad century, right?
<Keybuk> jdong: finger DNS@158.152.1.222
<sivang> pygi: more of, yeah 
<Keybuk> hmm, maybe that doesn't work anymore
<bluefoxicy> jdong:  http://rafb.net/paste/results/qlL0YE91.html  That should compile but I recommend you don't :)
<Keybuk> sorry
<Keybuk> .65
<Keybuk> syndicate scott% finger collegegeek.org@158.152.1.65
<Keybuk> [158.152.1.65] 
<Keybuk> collegegeek.org has address 64.191.182.77
<bluefoxicy> jdong:  you should also be able to run it as a shell script, but this is not a good idea  >:D
<jdong> GOD that's right I can't ping the tracker if DNS is down
* jdong tells dnsmasq to steal another ISP's DNS server
<sivang> wasn't there a "recent" patch against this type of DoS's ?
<sivang> jdong: using dnsmasq on a home made router?
<jdong> sivang: yeah
<purserj> morning all, can someone tell me if the move to dash for edgy has been accompanied by regression testing of packages (beyond the init scripts)?
<jdong> sivang: is that a crime?
<jdong> purserj: to some degree, yes
<jdong> purserj: but I think most of that has been fixed
* jdong notes that some proprietary stuff is broken too
<jdong> but I don't think anyone in this room will shed tears about that
<jdong> :)
<sivang> jdong: why not?
<jdong> sivang: I've been told that I should grow up and learn to configure bind.....
<jdong> but dnsmasq has worked like a charm for me, and for that I'll stick with it
<sivang> jdong: indeed, I agree. I have used it for a while, it quite nice
<pygi> jdong: I was told that always staying a baby is the best solution
<Nafallo> must be the thing the linksys used before I bricked it ;-)
<jdong> sivang: I still use dhcpd for DHCP server though
<jdong> sivang: the dnsmasq dhcp server is a new feature for me, and I just haven't got the chance to try it yet
<Keybuk> purserj: not a deliberate regression test
<Keybuk> but we figure that if after a few months nobody's noticed, then it's not a major problem :p
<sivang> jdong: works well as well. I've had a dnsmasq + its dhcp server on a p100 machine for 3 years, worked like charm.
<Keybuk> also Nokia use dash on the 770, and got most of the patches into Debian a while back
<jdong> Keybuk: LOL
<sivang> jdong: and the caching seems to be serving quite well
<jdong> sivang: yeah, no kidding. it takes me a while to notice when my ISP's DNS goes down!
<sivang> Keybuk: does sfllaw know about this workflow? ;)
<purserj> Keybuk, are you expecting problems when people start putting it on production systems with custom scripts?
<Keybuk> purserj: they may have issues, but it's a simple fix for them -- just change /bin/sh to /bin/bash
<sivang> jdong: what eventually killed this debian sarge box was a power failure which burnt the power supply. after 3 power supplies, I got lazy and did not replace it anymore
<Keybuk> most hard-core UNIX people are pretty used to /bin/sh not being bash, e.g. from Solaris or FreeBSD
<imbrandon> if they use custom scripts and expect /bin/sh not to be POSIX then they need to use /bin/bash ( it is only a two letter change )
<jdong> imbrandon: yeah, but try getting ATI to listen :)
* sivang recalls trying to make PHP work on Solaris, a day that will never be forgotten
<imbrandon> jdong, i feel about them the same i feel about nvida binary drivers, e.g. the root exploit, down with binary drivers
<sfllaw> sivang: I'm familiar with how much testing our packages get.  ;P
<Keybuk> sivang: ?  "configure && make"
<Keybuk> sfllaw: testing is for users
<Keybuk> I was going to say that if it builds, I upload it ...
<Keybuk> ...but then I realised I don't check that half the time
<Keybuk> <g>
<imbrandon> heh
<jdong> Keybuk: haha, it it builds upload it
<jdong> boy has that reared its ugly head for me several times already
<jdong> Keybuk: luckily for you guys, I learned that lesson in the unofficial backports tree
<jdong> (or unluckily, if people came crying to you)
<sfllaw> Remember folks, this guy wrote your new init system.
<Keybuk> sfllaw: and how many bugs have been filed against it? :)
<jdong> Keybuk: my fonts still look funny :D
<Keybuk> jdong: I'm trying to remember what you broke
<jdong> Keybuk: flashplayer?
<Keybuk> ah yes
<Keybuk> no porntube
<jdong> Keybuk: that was an interesting story in its own...
<jdong> Keybuk: somehow /var/cache/pbuilder/dapper.tgz had an edgy environment inside
<jdong> :)
<jdong> that reminds me, I don't think crimsun ever reverted that change
<jdong> oh well, no harm done
<Nafallo> jdong: reverted the revert? :-)
<jdong> Nafallo: something like that :)(
* jdong remembers other fascinating bugs he's encountered in the past
<sivang> Keybuk: was never easy when tying to configure with oci8.so , ibm_db2.so , packaging this and reconsturcting the experienc on client's system. both extension have special env vars and LD_LIBRARY_PATHs that need to be in effect to work. I also disliked its software update and the patch install tool.
<jdong> apparently, java's plugin segfaults if firefox's version number is too large
<jdong> and the backports version trailer put it over the limit once
<jdong> oh boy was that a fun one to diagnose!
<Keybuk> sivang: of course, our security policy stated that any box running PHP had to be firewalled heavily
<bluefoxicy> jdong:  segfaults huh
<Keybuk> one of the security guys, when asked how heavily, deadpan replied "every port, especially 80"
<bluefoxicy> jdong:  new tell me why that is?  :)
<jdong> bluefoxicy: yeah. makes the security part of your brain shudder doesn't it?
<Keybuk> Solaris packaging rocks though
<sivang> Keybuk: granted
<bluefoxicy> jdong:  yes it does.  If you overflow a stack buffer and smash RETP/SFP up with a character array, you may very well jump into non-executable or unmapped memory and segfault.  :)
<jdong> bluefoxicy: yeah, I'm going with the "what I don't know can't hurt me" excuse on this one :)
<jdong> and pretend it never happened
<bluefoxicy> jdong:  however I have no practical use for this exploit; you should only be able to get access in the context of the current user.
<bluefoxicy> assuming, of course, such an exploit exists.
<jdong> bluefoxicy: expecially since you need to be root to install such an exploit
<bluefoxicy> Well, root or convince the user to run a program you gave him
<sivang> Keybuk: http://www.zend.com/products/zend_core/zend_core_for_oracle
<jdong> bluefoxicy: the latter has issues all of its own ;-)
<bluefoxicy> in either case, you already have access to the account running the code.
<bluefoxicy> still
<bluefoxicy> is that sun's plug-in?
<jdong> bluefoxicy: yeah
<jdong> bluefoxicy: this was back in Hoary days... I don't know if it still applies
<Keybuk> # Make the package, use faspac to compress it if it's set
<Keybuk> pkgmk -o -p "`date +%Y%m%d%H%M%S`-`uname -n`" -d ./spool -f prototype
<Keybuk> [ -z "$PB_FASPAC" ]  || $PB_FASPAC -m cpio -d ./spool || true
<Keybuk> pkgtrans -o -s ./spool $PB_SOURCE_AREA/$PB_FILENAME_GLOB $PB_LOCAL_NAME
<bluefoxicy> jdong:  can you change the version string fora given page with javascript
<Keybuk> eww
<Keybuk> actually, maybe Solaris packaging was a bit icky
<jdong> bluefoxicy: I don't know
<desrt> Keybuk; good policy :)
<jdong> bluefoxicy: just rebuild firefox... dch -i  it with a ridiculously long version string
<jdong> bluefoxicy: warty-backports had the full word "~backported" in the trailer :D
<bluefoxicy> hah
<sivang> Keybuk: and why the hell eveytimeit lost power, it can't boot anymore and spits out those non-human messages that you require a special solaris admin to decipher and fix? :-D
<jdong> oh oh oh lookie lookie my ktorrent backport was accepted
* jdong proceeds to watch it build
<bluefoxicy> sivang:  solaris can kiss my ass
<bluefoxicy> I installed it once, got it multibooting with linux, booted linux
<bluefoxicy> then booted solaris to see what it was about
<bluefoxicy> NOTICE:  FOUND ERROR IN MBR <FIXED>  @*^ *FREEZES*
<desrt> oh man
<bluefoxicy> apparently I no longer had a partition table.
<desrt> <FIXED> is not something you want to see here
<jdong> lol
<jdong> especially in combination with freezing
<bluefoxicy> DO NOT fix ANYTHING without consulting me FIRST.  EVER.
<desrt> "fix"
<sivang> bluefoxicy: right, that how it called me after which I refused to touch it :)
<jdong> bluefoxicy: don't you think e2fsck takes that to an extreme though?
<sivang> desrt: HEHE
<jamesh> Keybuk: I noticed a problem in a package you touched last: it seems that TTF fonts aren't getting registered with the old font system correctly any more
<sivang> bluefoxicy: HAHAH
<jdong> bitmap for 000001 is incorrect. Fix? Bitmap for 00002 is incorrect. fix?
<jamesh> Keybuk: seems to be problems with how mkfontdir gets invoked
<bluefoxicy> sivang:  yeah I was like "no screw this" and never touched sun solaris again
<Keybuk> jamesh: No. Fucking. Clue.
<Keybuk> sorry
<Keybuk> what's the package?
<jdong> jamesh: are you one of the bzr launchpad supermirror guys?
<jamesh> Keybuk: https://launchpad.net/distros/ubuntu/+source/x-ttcidfont-conf/+bug/66360
<Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Unknown,Unknown]  
<desrt> i hear the sun java plugin will fix your mbr if your firefox version number is too long
<jamesh> Keybuk: looks like a simple path problem
<sivang> bluefoxicy: man, that enterprise software did to me :)
<sivang> s/that/what/
<jdong> desrt: yeah, depending on what shellcode you stick in the version trailer :D
* desrt chuckles
<Keybuk> jamesh: no clue, I'm afraid
<Keybuk> defoma and font stuff is a great big mystery to me
<desrt> browsing the web as root -- "just don't do it."
<jdong> desrt: yeah, especially with the nvidia exploit going around... oh wait that even works as a regular user to get root
<sivang> desrt: you miss a handful of nice stuff you could be getting , do you really want to miss that? :)
<jdong> :)
<desrt> hah
<desrt> closed-source java + closed-source video drivers for the win
<Keybuk> jdong: that's just a crasher unless you have bad plugins
<sivang> jdong: wouldn't imagine having an ATI would ever turn to be a godo thing, although they ight have even worse bugs nobody knows about :)
<Keybuk> there's no known way to get the exploiting glyphs *and* shell code into a web page
<jamesh> Keybuk: who would be best to bug about this?  It makes the font rendering of old apps look even worse than usualy :)
<jdong> Keybuk: just the crashing is annoying enough though
<jamesh> jdong: yeah.
<desrt> Keybuk; write your shellcode to run the glyph-exploit
<jdong> jamesh: I tried pushing to the supermirror earlier today and got an error
<jdong> not sure if it's bzr's fault or the supermirrors
<jdong> didn't have a chance to investigate
<sivang> anyway fellas, it's been fun, but I'm way past my timezone. night all!
<jamesh> jdong: what command did you run, and what error did you get?
<jdong> just wondering if you were aware of any known issues
<Keybuk> jamesh: at this point, it's probably edgy+1
<jdong> jamesh: bzr push sftp://bazaar.launchpad.net/~jdong/pyfragtools/newgranch
<Keybuk> jamesh: I can't help but note that the "remaining change" is "X font path"
* jdong tries to find error
<Keybuk> it's entirely possible the merge is bogus
<Keybuk> and the Debian version would work perfectly
<Keybuk> can you check that?
<jamesh> Keybuk: the fix is to change two simple paths in the script (as mentioned in the bug report)
<jamesh> Keybuk: the encodings definitions needed to generate fonts.dir were moved to a different directory in edgy, so the script fails
<Keybuk> right
<jamesh> Keybuk: it isn't a change to the X font path
<Keybuk> so does that make the package identical to Debian
<Keybuk> or different?
<jdong> jamesh: bzr: ERROR: Transport operation not possible: This is not a LocalTransport, so there is no local representation for a path %
<jamesh> Keybuk: from what I can tell the paths used in the upstream debian package would work with Edgy while the paths in the Edgy package don't
<jdong> jamesh: in the past I have pushed to supermirror successfully before
<Keybuk> right
<Keybuk> http://patches.ubuntu.com/x/x-ttcidfont-conf/x-ttcidfont-conf_24ubuntu1.patch
<Keybuk> is the diff from Debian
* jamesh looks
<Keybuk> so basically you're saying we should revert that?
<jamesh> Keybuk: yeah.  The paths from the Debian package would work.
<Keybuk> I guess that our diff is for Xorg 6
<Keybuk> and now we're using Debian Xorg 7, the paths moved again
<jamesh> /usr/share/X11/fonts/encodings doesn't exist on Edgy while /usr/X11R6/lib/X11/fonts/encodings does (and includes a valid encodings.dir)
<jamesh> jdong: what is the full local directory name?
<jdong>  /home/jdong/src/bootdefrag
<Keybuk> probably the former existed on dapper and not edgy
<Keybuk> daniel stone woz 'ere
<jamesh> jdong: probably a Bazaar problem -- have you upgraded your Bazaar since?
<Keybuk> easiest fix is just to sync from debian and pick up a russian translation in the process
<jdong> jamesh: yeah. if it's a bzr problem then I'll investigate on my own
<jdong> as long as it ain't supermirror
<jamesh> jdong: check the ~/.bzr.log file -- it'll probably have a full traceback
<jamesh> jdong: I am not sure why it would be trying to get local representations for remote paths ...
* pygi will cry
<pygi> 4:01 AM
<_ion> Wed Oct 18 05:07:00 EEST 2006
<stub> Launchpad is going down in 15 minutes to allow some data migration to be done. Estimated downtime is 1 hour.
<bluefoxicy> shit
<bluefoxicy> launchpad is down
<infinity> bluefoxicy: Yes, read the last thing typed before what you said.
<bluefoxicy> infinity:  yes I wasn't paying attention, it's 10:48pm and i just realized I need to eat more than a brownie today
<Fujitsu> Twice in 24 hours... What fun.
<Fujitsu> With minimal warning. Fun fun fun.
<infinity> We had lots of warning for this one.
<infinity> We scheduled it with stub yesterday.
* bluefoxicy idly blames things like hunger that don't really affect him anyway.
<_ion> if {
<_ion> Sorry.
<Burgwork> although, why the entire site needs to be taken down...
<fabbione> morning
<fabbione> infinity: ping?
<towsonu2003> hi
<towsonu2003> I heard mjg59 wanted to talk to me?
<infinity> fabbione: pong.
<fabbione> infinity: did you have a chance to restart the rebuild of death at the DC?
<fabbione> infinity: i need to stop the buildd here to start install tests
<fabbione> otherwise i won't make it for RC
<infinity> fabbione: We made a decision to hold off on the DC rebuild until post-RC, though if RC gets held up, I'll rethink that.
<fabbione> ok
<infinity> fabbione: But if you stop your buildd, that's fine by me.,
<fabbione> i know it is ok for you :) i just had to make sure we had plan b around :)
<fabbione> for i in $(seq 1 24); do touch buildd$i/EXIT-DAEMON-PLEASE && chmod 777 buildd$i/EXIT-DAEMON-PLEASE; done
<fabbione> there.. stopping..
<stub> Launchpad downtime looks to be another 40 minutes I'm afraid - I had to restart one of the processes.
<sladen> towsonu2003: something about assigning bugs to acpi-support.  I think he's now gone to bed
<towsonu2003> sladen: he already emailed me about that, it's ok.
<sladen> towsonu2003: groovy!
<towsonu2003> sladen: he doesn't want bugs assigned to acpi-support unless the bug specifically mentions acpi scripts
<towsonu2003> :)
<sladen> magic! :)
<towsonu2003> see you
<jdub> http://www.flickr.com/photos/geddes/272802153/
<jdub> ^ help me baby jesus
<ajmitch> jdub: ah, the future has arrived..
<Burgundavia> jdub: yay! splash screens make the world go 'round
<sladen> oh, dear, goodness
<Burgundavia> easyubuntu has a nasty big thing on it too
<_ion> Wow.
<imbrandon> oh gawd
<Burgundavia> my question is: what happened to common-customizations?
<Burgundavia> was mdz too busy?
<jdub> HELLO, THIS IS THE MOST IMPORTANT SOFTWARE ON YOUR DESKTOP. WE'RE GOING TO SHOW YOU A LITTLE INTRODUCTION, AND THEN ASK A BUNCH OF IRRELEVANT QUESTIONS. IT'S CALLED A WIZARD BECAUSE IT'S STUPID.
<imbrandon> Burgundavia, most likely, i'd like to have another bof on it in mtv, i think it was defered
<jdub> http://people.ubuntu.com/~jdub/2005/amarok-wizard-1.jpg
<Burgundavia> imbrandon: too bad
<jdub> ^ best wizard EVER
<jdub> pics 1 - 5
<Burgundavia> jdub: no, I think the ekiga one is better
<Burgundavia> "lets ask you tonnes of questions that will confuse you"!
<Burgundavia> we have 3 pages in teh book just because of that bloody thing
<ajmitch> that's impressive
<sladen> "what's missing from most software, is an interface that doesn't get in your way".... 
<imbrandon> jdub, heh thats why in kubuntu we disable the first run wizzard for amarok and just use sane defaults
<robitaille> so who is uncle Rodney?  He seems to like Amarok... bug 46526
<Ubugtu> Malone bug 46526 in amarok "Amarok description in Add/Remove programs is silly" [Wishlist,Confirmed]  http://launchpad.net/bugs/46526
<Burgundavia> imbrandon: gimp has a first run wizard too, apparently
<imbrandon> Burgundavia, yea *ALOT* of kde apps do but we disable them and just provide sane defaults
<Burgundavia> imbrandon: KDE - because defaults are evil! <dig?
<imbrandon> hehe
<robitaille> Burgundavia:  I think it is gone from Edgy...but I think gimp in Dapper had it.
<Burgundavia> robitaille: no, it has been dead since warty
<robitaille> I could swear I saw it in Dapper at work.. maybe it was on one of our Mandriva machine.  In any case, that's good that it is gone.
<Burgundavia> changelog only shows it going away in edgy, but I remember a disucssion about it in the early hoary days
* ajmitch should get lewing to code a first start wizard for f-spot
<Burgundavia> ajmitch: I will kill you, you realize that
<ajmitch> but of course
<Burgundavia> excellent
<Burgundavia> however, I realize fspot lacks the ability to change between view and manage mode
<ajmitch> Burgundavia: what's worse is when you can't do anything without going through the wizard
<Burgundavia> ajmitch: for which app? amarok?
<ajmitch> ie click through these 10 steps to even look at the program
<ajmitch> various apps I've run across in the past
<ajmitch> & then removed for that reason
<Burgundavia> back in a flash
<Burgundavia> I need a screenshot of the logout dialog
<Burgundavia> anybody got any smart ideas on how to do that?
<Burgundavia> xnest doesn't give the shutdown and restart options
<bluefoxicy> does gaim beta in edgy have voice and video
<_ion> The dialog probably communicates with the instance of gdm that the gnome session was started from. And if it wasn't started from gdm, no dialog.
<bluefoxicy> why am I asking this in #-devel
<Burgundavia> bluefoxicy: afaik, no
<Burgundavia> _ion: yep, hence the issue
<_ion> Doesn't 'sleep 5; import -window root, click the quit button' work?
<Burgundavia> no tried that
<sladen> what the heck is it doing?   xwd -root -out foo.xwd  doesn't work
<sladen> and gimp screenshot blocks
<Burgundavia> not tried, rather
<sladen> Burgundavia: what about vmware/qemu?
<sladen> possibly just easier to hack the application/theme and fake it
<Burgundavia> sladen: need a cd for that
<Burgundavia> yep
<Burgundavia> or ship a screenshot that doesn't show shutdown and restart
<sladen> maybe "rebuild latest gnome-session deb with logout_no_grab patch" from googling
<sladen> https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/59244
<Ubugtu> Malone bug 59244 in gnome-session "gnome-session logout hang with a composite manager" [Low,Fix released]  
<sladen> try settings GSM_NO_GRAB_SERVER or LTSP_CLIENT depending on which patch went in
<sladen> try running a compositing manager :)
<Burgundavia> right, that is way too much work for one screenshot, even if it is in the official book
<lifeless> tfheen: bug 54659 has a patch in its duplicate for x64 fwiw
<Ubugtu> Malone bug 54659 in cricket "Format.pm does not know about Ubuntu architectures" [Undecided,Unconfirmed]  http://launchpad.net/bugs/54659
<mnepton> Burgundavia: you want to Dapper logout?
<mnepton> s/to/the/
<Burgundavia> mnepton: they are identical
<mnepton> Burgundavia: just a sec
<sladen> sudo apt-get install compiz && compiz --indirect-rendering --strict-binding --replace gconf
<robitaille> Burgundavia:   just search for "dapper logout" in google image :)
<Burgundavia> robitaille: need the edgy icons
<robitaille> yeah...I just realized they are not exactly like Edgy....sigh.
<mnepton> Burgundavia: http://people.ubuntu.com/~mneptok/logout.png
<Burgundavia> mnepton: is that dapper or edgy?
<mnepton> Dapper
<robitaille> the icons are different from Edgy
<mnepton> i can edgy, if necessary
<jdub> gettin' edgy wit' it
<mnepton> arr, jdub
<_ion> mnepton: What Gtk theme is that?
<_ion> Oh, dapper. Right.
<Burgundavia> since I have the attention of everybody. Anybody got a cd handy that could grab me a screenshot of the keyboard chooser in edgy? it has changed
<sladen> Burgundavia: the drop-down menu?
<sladen> Burgundavia: or the keyboard preferences?
<Burgundavia> sladen: in ubiquity, the keyboard chooser
<sladen> ah sorry
* sladen looks around for other helpful people
<sladen> Burgundavia: I can boot it in qemu?
<Burgundavia> I can get it, just figured somebody else might already have it up
<Burgundavia> I will get it tomorrow nigbht
<Burgundavia> thanks everybody
<Burgundavia> I need to sleep now
<ajmitch> night Burgundavia 
<^jcole> why does fedora have bluetooth support in gnome via vfs but ubuntu gnome does not? i can't seen to find anything in synaptic either
<^jcole> gobexftp is another app missing
<^jcole> is it purposely removed from ubuntu gnome?
<^jcole> possibly some dfsg thing?
<jdub> ^jcole: no, ubuntu just doesn't ship the vfs method
<johanbr> ^jcole: From Edd Dumbill's blog: "... removed the crack-laden bluetooth:/// gnome-vfs hack"
<jdub> johanbr: there is a new one
<^jcole> johanbr: that is the "Send To Bluetooth" from a while back
<^jcole> johanbr: i'd like obexftp in gnome on ubuntu the same as one can do on fedora... or kubuntu via konquerer
<^jcole> ubuntu dapper --> http://blogs.gnome.org/view/jamesh/2006/10/05/0
<jamesh> ^jcole: I compiled that stuff on Edgy
<^jcole> jamesh: right :) my bad
<jamesh> ^jcole: now that bluez-utils 3.7 is in edgy, it should be possible to modify the VFS method to work directly against hcid too
<jamesh> rather than requiring an extra dbus daemon
<jamesh> I might see if I can clean it up so other people can use it ...
<^jcole> jamesh: that would be awesome
<^jcole> jamesh: you might want to also add gobexftp to your list for xubuntu :)
<jamesh> what is gobexftp?
<dholbach> good morning
<mdke__> morning
<^jcole> jamesh: gtk obexftp client
<dholbach> HAPPY HUG DAY!
<^jcole> jamesh: it is also in fedora
<bluefoxicy> so uh
<^jcole> jamesh: i'm tempted to alien the rpm
<jamesh> ^jcole: I'm not actually on the distro team
<bluefoxicy> I noticed I can't find bounties on launchpad
<dholbach> oh... we need to add that to http://wiki.ubuntu.com/Bluetooth somewhere
<bluefoxicy> was there a problem?
<bluefoxicy> lack of turn-out?  Deadbeats not paying their bounties?
* jamesh still hasn't got round to learning .deb packaging
<dholbach> ^jcole: you have the link somewhere?
<bluefoxicy> People bountying porno acts?
<dholbach> HAPPY HUG DAY!
<jamesh> bluefoxicy: the bounty tracker code wasn't being maintained or used, so we hid it in the UI
<^jcole> dholbach: here is jamesh's link for gnome-vfs -> http://blogs.gnome.org/view/jamesh/2006/10/05/0
<bluefoxicy> jamesh:  it's burried but living?
<jamesh> bluefoxicy: yeah
<dholbach> ^jcole: I added that to http://wiki.ubuntu.com/Bluetooth/TODO
<bluefoxicy> jamesh:  is it dying off or is there a plan to bring it back?
<dholbach> ^jcole: what about gobexftp?
<bluefoxicy> jamesh:  once in a while I like to browse to see if there's anything dead-simple I can get $10 off :)
<bluefoxicy> (I have run out of articles to write for LWN)
<jamesh> dholbach: as I said in my blog, the Maemo obex-method needs some love before it'd be ready for desktop users
<dholbach> jamesh: Yeah, I read that - but at least it's a good start for investigations :)
<^jcole> dholbach: here is a source package -> http://triq.net/obexftp/gobexftp-0.2.tar.gz
<dholbach> ok, I'll note the tarball on that page
<jamesh> dholbach: I was thinking about cleaning it up in my spare time -- we can get rid of the osso-gwconnect dependency, and it might be best to statically link osso-gwobex into the VFS method if nothing else is going to use it ...
<jamesh> the new hcid in the new bluez-utils upload has all the required features
<dholbach> jamesh: it probably wouldn't hurt to have it as dependency, no?
<dholbach> (and it works with kdebluetooth very well)
<jamesh> dholbach: is kbluetooth using the gwobex library?
<dholbach> libbluetooth2-dev (>= 3.7-1), libopenobex-1.0-0-dev   afaik
<jamesh> dholbach: gwobex is a separate obex implementation (from Maemo)
<dholbach> ah ok
<dholbach> ^jcole: added to https://wiki.ubuntu.com/Bluetooth/TODO - thanks
<tfheen> lifeless: thanks; edgy+1
<mnepton> lol
<mnepton> Bluetooth/TODO must comprise half the raw data on the 'net :/
<BHSPitLappy> gnome just needs a good, non-scattered bluetooth utility set
<BHSPitLappy> a nice panel icon with access to anything you'd need, and good backends of course
<BHSPitLappy> it's definitely not even comparable to what you get with commercial OS's today
<dholbach> BHSPitLappy: get involved in the team and help to fix it
<jamesh> BHSPitLappy: what do you want to do with bluetooth?
<jdub> BHSPitLappy: there is very active work going on in the gnome mobile and embedded space that is improving the situation -- more desktop hackers need to take advantage of it (as jamesh has done)
<jamesh> would it make sense to have a single panel icon for "Ethernet" that'd let you do everything related to that?
<jdub> hadess and jamesh are good people to talk to about it in the gnome community
<BHSPitLappy> jamesh, uhh, do you think there's a better implementation than what you see in Windows or OSX right now?
<jamesh> note that I am a bluetooth newbie -- I only recently got a laptop + phone that supported it
<BHSPitLappy> you right click on a tray icon and click, "Pair new device" for example
<BHSPitLappy> you can also launch a settings module for the system's bluetooth
<jamesh> BHSPitLappy: I haven't played around with bluetooth on Windows or OS X much.  I know it is pretty well hidden on Windows the way Sony sets their laptops up though ...
<BHSPitLappy> or launch a window that shows you all the devices in range, or all your pairings
<BHSPitLappy> or browse another device's available services
<jdub> oh, brainfart -> s/jamesh/mjg59/ 8)
<BHSPitLappy> right now we just have a few individual services, working independently, and mostly in obscure, complex setups
<^jcole> BHSPitLappy: agreed, i do all my gnome bluetooth from the command line, lol... kde is quite good at bluetooth imho
<BHSPitLappy> the only easy-to-do thing is file transfers
<BHSPitLappy> here you have a program that does file transfers to other devices, a program that will set up a headset, another that will connect to a bluetooth modem
<jamesh> BHSPitLappy: there is a gnome-bluetooth-manager app that gives that kind of view -- it is pretty useless at the moment due to lack of integration with the other tools
<BHSPitLappy> I saw on gnome's site, a mockup for a bluetooth panel icon and program 
<jamesh> jdub: all I've done is recompile Maemo code and play around with the bluetooth dbus APIs a bit
<BHSPitLappy> it might be worthy to take a look
<BHSPitLappy> http://live.gnome.org/BluetoothManager
<BHSPitLappy> that's a very good setup there
<BHSPitLappy> they've got most of what I want mapped out on that page
<jdub> jamesh: yeah. i meant matty, but wrote jamesh. i don't know how. no offense. ;)
<infinity> tfheen: Ahh, you're up.  Feel like playing RM?
<BHSPitLappy> in a hypothetical, of course ;) someone's just got to code it
* mnepton now expects jamesh to PEPPER HIS SENTENCES with ALL CAPS about THE FIRE THAT BURNS HIS EYES and MOCKS HIS GENITALS
<^jcole> btw, i had to change "class 0x3e0100" to "class 0x000100" in hcid.conf on edgy so it would pair up on my phone
<^jcole> worked on dapper
<^jcole> was that changed for some reason?
* ^jcole downloads a changelog
<BHSPitLappy> incidentally
<BHSPitLappy> I'm getting a new phone tomorrow ^^
<BHSPitLappy> according to the fedex online tracker
<jamesh> BHSPitLappy: what type?
<BHSPitLappy> Cingular 3125
<^jcole>   * removed merged/obsolete patches:     - debian/patches/007_hcid_typo.patch
<BHSPitLappy> a.k.a., the HTC StarTrek
<^jcole> hmm
<jamesh> BHSPitLappy: the phone companies rename the phones???
<jdub> jamesh: and disable features on the phones!
<Treenaks> jdub: how weird
<BHSPitLappy> jamesh, HTC tends to make phones, and sell them to wireless providers, etc
<BHSPitLappy> who will rebrand them
<BHSPitLappy> and put their logo on it, give it a name
<BHSPitLappy> this phone exists under a few different names, with different brands
<BHSPitLappy> cingular won't rename a RAZR or a nokia phone
<BHSPitLappy> this is just what HTC does
<jamesh> crazy
<jamesh> BHSPitLappy: so it runs Windows? :)
<BHSPitLappy> yes :/
<BHSPitLappy> it's so sad
<^jcole> i cdma/evdo bluetooth through my phone
<BHSPitLappy> it's been so long since I've used a Microsoft OS routinely
<BHSPitLappy> I chose it because having Windows Mobile is still better than most phones, though, with some crappy shell interface
<BHSPitLappy> and, the only Symbian phones I could choose from were crazy expensiv
<BHSPitLappy> +e
<tfheen> infinity: yes, sure
<tfheen> tfheen: that is, after I've had a little bit of breakfast and calmed down the local whirlwind.
<tfheen> infinity:: that is, after I've had a little bit of breakfast and calmed down the local whirlwind.
<infinity> Breakfast sounds good.  I think I should go find food.
<fabbione> tfheen: talking to yourself today? :P
* infinity wonders where...
<^jcole> BHSPitLappy: via verizon?
<tfheen> fabbione: exactly, hence my "after some food"
<fabbione> ehe
<tfheen> infinity: is there anything particular which I should tend to right away, even before breakfast or are things somewhat under control?
<BHSPitLappy> ^jcole,     "<jamesh> BHSPitLappy: what type?  <BHSPitLappy> Cingular 3125"
<infinity> tfheen: Just the ueue.
<infinity>   110159 | S- | bluez-btsco          | 1:0.42-0ubuntu1      | 1 hour 30 minutes
<^jcole> BHSPitLappy: have you done an "sdptool browse {bt id}"
<infinity>          | * bluez-btsco/1:0.42-0ubuntu1 Component: universe Section: sound
<jamesh> BHSPitLappy: so is there anything tying that handset to the Cingular network in particular?
<infinity>   110158 | S- | gossip               | 0.18-0ubuntu1        | 1 hour 40 minutes
<infinity>          | * gossip/0.18-0ubuntu1 Component: universe Section: gnome
<infinity>   110157 | S- | glom                 | 1.1.7-0ubuntu1       | 1 hour 40 minutes
<infinity>          | * glom/1.1.7-0ubuntu1 Component: universe Section: gnome
<infinity>   110086 | S- | installation-guide   | 20060726ubuntu5      | 11 hours
<infinity>          | * installation-guide/20060726ubuntu5 Component: main Section: doc
<infinity>   110081 | S- | kdebindings          | 4:3.5.4-0ubuntu2     | 14 hours
<infinity>          | * kdebindings/4:3.5.4-0ubuntu2 Component: main Section: devel
<BHSPitLappy> jamesh, I dunno. I wouldn't doubt it.
<infinity>   110077 | S- | python-setuptools    | 0.6c3-1ubuntu4       | 15 hours
<infinity>          | * python-setuptools/0.6c3-1ubuntu4 Component: main Section: python
<BHSPitLappy> infinity, ever heard of pastebin?????
<infinity>   110070 | S- | pysvn                | 1.4.2+dfsg-0.1ubuntu | 16 hours
<infinity>          | * pysvn/1.4.2+dfsg-0.1ubuntu2 Component: universe Section: python
<ajmitch> gossip & glom are dholbach changes, they can be approved
<infinity>   110068 | S- | xfdesktop4           | 4.3.99.1svn+r23428-0 | 16 hours
<infinity>          | * xfdesktop4/4.3.99.1svn+r23428-0ubuntu2 Component: main Section: x11
<infinity>   110050 | S- | human-cursors-theme  | 0.4-0ubuntu1         | 17 hours
<infinity>          | * human-cursors-theme/0.4-0ubuntu1 Component: main Section: x11
<infinity> BHSPitLappy: Yes.
<infinity>   110049 | S- | pycxx                | 5.3.5+5.3.6-0ubuntu1 | 17 hours
<infinity>          | * pycxx/5.3.5+5.3.6-0ubuntu1 Component: universe Section: python
<infinity> BHSPitLappy: Any other questions?
* BHSPitLappy pokes his head out and checks both ways
<infinity> ajmitch: Danke.
<BHSPitLappy> is it safe to come out now?
<infinity> pitti: Fix shadow, kthx. :)
<pitti> Good morning
<ajmitch> hey pitti 
<infinity> pitti: Also, good morning. :)
<BHSPitLappy> ditto
<pitti> tfheen: are desktop 17.2 and alternate 17.1 good RCCs now?
* infinity goes to see if 7-11 offers anything even vaguely resembling "food".
<BHSPitLappy> 7-11 is decent eatin'.
<BHSPitLappy> not as good as QT though
<^jcole> hot dogs and taquitos
<infinity> If anything's really urgent, i can probably manipulate the upload queue via my phone, though I'd not lay bets on it being a good idea. :)
<tfheen> pitti: they should be, yes.
* tfheen imagines infinity sms-ing 911-SOYUZ with just the word RELEAZE.
<dholbach> haha :)
<pitti> infinity: fix shadow... harder?
<infinity> pitti: Bug reopened, looks like you missed a build-dep or two.
<pitti> infinity: argh, I suck; indeed I do
<tfheen> infinity: installation-guide is approved. 
<tfheen> infinity: the rest is either defer or universe.
<dholbach> Riddell: we need to check telepathy-qt to make it buildable/installable again
<cbx33> I found a coredump bug in f-spot
<cbx33> anyone interested?
<dholbach> infinity: I added some notes to bug 66690
<BHSPitLappy> dholbach is
<Ubugtu> Malone bug 66690 in speedcrunch "FTBFS in edgy, doesn't like qt4 environment?" [High,Unconfirmed]  http://launchpad.net/bugs/66690
<dholbach> BHSPitLappy: I doubt that.
<BHSPitLappy> I tried.
<cbx33> https://launchpad.net/distros/ubuntu/+source/f-spot/+bug/66694
<Ubugtu> Malone bug 66694 in f-spot "f-spot crashes when viewing SVG" [Medium,Unconfirmed]  
<cbx33> it's a segfault by the looks of things
<cbx33> I just imported a directory with a png and an svg in it, my first time using f-spot
<cbx33> the svg was blank - I clicked on it, and it segfaulted and died
<tfheen> cbx33: not rc.
<mdz> morning
<cbx33> ok np tfheen 
<dholbach> good morning Matt
<ajmitch> best I can do for now is forward the f-spot bug upstream
<cbx33> thought I'd just make you guys aware
<ajmitch> tfheen: would a fix for the f-spot bug be accepted before final release? apparantly there's a fix upstream
<^jcole> cat /etc/skel/.bashrc.postinstall_divert | sed "s@#alias@alias@g" > /etc/skel/.bashrc
<^jcole> crap
<^jcole> sorry
<pitti> tfheen, infinity: fixed shadow uploaded, this time pbuilder-tested; sorry
<pitti> tfheen: Matt asked me to update our Firefox to RC3 (since Ian is on holiday); is that something you would want me to upload today or on Friday?
<cbx33> ajmitch: that'd be good - just seems nasty....seeing as f-spot is nice a nd shiney and new in 6.10
<ajmitch> ok, add a sample image as I asked in the bug report if you can
<cbx33> sure
<tfheen> ajmitch: probably not.
<tfheen> pitti: uh, isn't that massively non-trivial?
<pitti> tfheen: I'll check the diff, but it probably is absolutely nontrivial, right
<pitti> tfheen: my gut feeling is to get RC out with the current firefox, I prepare RC3 today and ask around for testing it until Friday
<pitti> tfheen: but it's your call, of course
<infinity> OTOH, getting it on the RC CDs would guarantee maximum exposure.
<mdz> pitti: after RC, yes
<pitti> ah, hi mdz
<cbx33> I had aproblem with firefox yesterday....well, still have aproblem infact
<pitti> mdz: I still have to get used to you being in an European timezone :)
<mdz> pitti: it's surely non-trivial, but upstream has said that the rc2-rc3 diff is relatively small
<cbx33> it was looking through the plugins-extensions....this was a fresh install, with a copied home dir
<cbx33> when it got to performancing as a plugin...which I don;t even remember installing...it sat there for ages....
<cbx33> eventually finished
<cbx33> but now it won;t install at all
<cbx33> s/install/run
<cbx33> I get no gui at all
<cbx33> running it in terminal produces no output either
<pitti> mdz: let's hope it doesn't break the mozembed ABI, I'll make sure to test the rdepends
<ogra> argh, what was added between 20061017 and 20061017.1 ? my CDs grew by 5M !
<mdz> pitti: moz_justin on freenode is an upstream contact who can confirm answers to those questions
<dholbach> ogra: ubuntu-docs got translations - maybe that's it
<ogra> oh, ok ... 
<cbx33> ogra: are we oversize?
<ogra> i'm at the limit now, please notify me if there are big additions
<ogra> cbx33, 699M
<cbx33> ogra: is handbook going onto CD?
<cbx33> eeek!
<cbx33> I guess not, as it's not finished
<cbx33> and would probably be large 
<ogra> cbx33, did anybody package it ? nobody notified me it would be in a packageable state
<cbx33> no, sorry i wasn't thinking
<cbx33> it's not finished so it won;t be able to go on
<fabbione> hey mdz
<ogra> i think we'll have an awesome handbook in edgy+1 (now that sbalneav is writing on it :) ) lets not release half breeded docs
<cbx33> heh
<cbx33> I gotta touch up the SCP docs
<cbx33> but they are essentailly done
<mdz> fabbione: morning
<seb128> dholbach: do you know about ubuntu-docs translations not being used because there is no .omf shipped for those?
<dholbach> seb128: um, I noticed a lot of .omf files in the package I uploaded and the german translation works nicely
<seb128> dholbach: 
<seb128> $ dpkg -L ubuntu-docs | grep "\.omf" | wc -l
<seb128> 6
<seb128> ii  ubuntu-docs    6.10.2         The Ubuntu Documentation Project
<seb128> dholbach: I would not call that "lot", there are only -C.omf
<dholbach> right, I'll double check
<dholbach> no, that's not a lot
<seb128> and de_DE.UTF-8 doesn't give a frontpage translated for me
<seb128> the title of the sidebar are
<dholbach> it's all in german for me
<seb128> hum, I've no german locale, let me rebuild it, it's not translated in french for sure
<seb128> dholbach: I'm curious to know how you get german without a -de.omf
<mdz> mvo: why does the .changes for the dist-upgrader say only 'new upstream'?  the diff I saw yesterday seemed to have more detail in the changelog
<pitti> mdz: firefox rc2->rc3: a mere 5.8 MB diff
<seb128> pitti: going to love firefox :/
<mdz> pitti: url?
<pitti> (well, there's a lot of CVS crap, it's not that bad actually, I hope)
<pitti> mdz: http://people.ubuntu.com/~pitti/tmp/2.0rc3.diff
<pitti> mdz: I'll filterdiff it a little to clean up
<dholbach> seb128: ok, some are translated, others are not
<seb128> dholbach: is the frontpage full german?
<mdz> pitti: right, that's what I was going to do
<mdz> pitti: it even has CVS metadata in it; don't get discouraged so easily :-)
<dholbach> seb128: one abstract is english
<pitti> no, that's what I meant with 'lot of crap' :)
<mdz> pitti: potpal:[~]  filterdiff -x '*/CVS/*' 2.0rc3.diff|wc -c  
<mdz> 896443
<seb128> dholbach: are you sure you are running the archive package and not one local build? ;)
<dholbach> seb128: archive package
<seb128> weird weird
* infinity grumbles at us arbitrarily moving libraries between packages for kicks.
<pitti> mdz: much better already :) and a lot of stuff is hopefully s/rc2/rc3/ noise, release notes, etc.
<mdz> potpal:[~]  filterdiff -x '*/CVS/*' 2.0rc3.diff |grep -v '^diff.*CVS' |wc -c
<mdz> 311985
<mdz> pitti: mostly branding changes remain
<dholbach> seb128: I asked in #ubuntu-doc
<seb128> dholbach: http://people.ubuntu.com/~seb128/yelp-de.png
<seb128> dholbach: that's how yelp looks with a german locale on my edgy desktop
<mvo> mdz: my bad, the Changelog does not (yet) auto-generate the changes file, I update it by hand
<mvo> (the ChangLog file in the DistUpgrade dir)
<mdz> mvo: ah, I see.  it would be comforting to be able to match the .changes with the diff more easily
<mvo> agreed, I will fix that
<dholbach> seb128: ah, i looked at "about ubuntu"
* pitti cleans up the testing matrix and updates CD timestamps
<seb128> dholbach: I said "frontpage" :)
<ogra> beautiful fonts :/
<seb128> ogra: the yelp screenshot?
<ogra> yeah
<seb128> right
<seb128> I blame firefox
<ogra> heh
<ogra> likely
<dholbach> rc3 will make it better :)
<siretart> https://launchpad.net/distros/ubuntu/+source/cryptsetup/+bug/62751/comments/27 - any objections with disabling building/installing po files for fixing FTBFS?
<Ubugtu> Malone bug 62751 in usplash "Upstart doesn't activate luks volumes in cryptsetup" [Undecided,Unconfirmed]  
<seb128> dholbach: maybe ;)
<seb128> siretart: that MKINSTALLDIRS issue is probably fixeable, doesn't look like a good reason to drop translations to me
<tfheen> mvo: about 66611 ; is our icon a derivative from the apple icon or have they been developed independently.?
<seb128> bug #66611
<Ubugtu> Malone bug 66611 in update-notifier "icon of application crash in the notification area - copyrighted?" [Medium,Confirmed]  http://launchpad.net/bugs/66611
<dholbach> tfheen: glatzor is finding out
<mvo> tfheen: I got it from a team-icon in lp, I'm currently trying to get more info. but I thinks its very similar, so it might be good if it would be replaced even if the person claims it was his original work
<mdz> mvo: it looking similar to another icon is not an issue for the release
<mvo> tfheen: it looks a bit like it is just anti-analised and mirrored 
<mdz> mvo: it being derived from an icon we do not have rights to use, that would be an issue for the release
<tfheen> mvo: what mdz says, basically.  If this is just an unfortunate choice of icon, it's not RC, if it's copyright infringement, it is.
<pitti> ogra: edubuntu DVD is not current; do you want to update it? (I set it to 'out of date' in the testing matrix for now)
<mdz> tfheen: do we have current DVD builds?
<sivang> morning
<mvo> mdz: it maybe, it looks similar enough and I suspect it might be the identical icon just mirrored and flipped
<infinity> mvo: If the derivation is in question, I can draw you a new icon.
<pitti> mdz: ubuntu and kubuntu are from today
<ogra> pitti, surely i'd like it updated
<tfheen> mdz: I haven't done, them, so I suspect no.  I'll do them now.
<pitti> tfheen: we have 20061018??
<mdz> tfheen: someone built them today, apparently
<seb128> are DVD images starting by the alternate or desktop image?
<fabbione> server is 17.1
<pitti> that's what I was just going to put into testing/current
<Kamion> morning
<pitti> hi Kamion 
<fabbione> hey Kamion 
<mvo> infinity: that would be good
<fabbione> Kamion: something really odd... bug #66685
<seb128> (if I want to cat CD images and rsync from that)
<Ubugtu> Malone bug 66685 in debootstrap "wrong free space check?" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66685
<siretart> seb128: sure. I looked at it for 20mins, but I didn't get it. :(
<tfheen> seb128: unsure.
<mdz> seb128: cat desktop alternate > dvd
<Kamion> jdong: if you think the java plugin version string thing is bad, there was one strange sshd somewhere that fell over due to the addition of the Debian version to the ssh banner
<seb128> mdz: thank you
<Kamion> fabbione: debootstrap has a free space check? news to me
<fabbione> Kamion: i still have console in d-i and i can give you access to look at it
<mdz> they're sorted by filename and /casper comes first
<mdz> s/filename/pathname/
<pitti> testing matrix is clear, test away
<fabbione> Kamion: dunno.. that's what syslog claims.. i didn't dig.. had to do other tests, but i did put the machine in stand-by for you
<Kamion> that's ENOSPC
<Kamion> if tar is saying that, it ain't my fault
<fabbione> Kamion: ok... so it's a bug in tar?
<Kamion> mdz: I built all the DVDs earlier, yes
<Kamion> fabbione: stop jumping to conclusions
<tfheen> pitti: edubuntu seems done too:
<tfheen> : tfheen@lithium ..image.ubuntu.com/www/full > ls edubuntu/dvd
<tfheen> 20061018/  current@
<fabbione> pitti: argh dude.. all my tests were from this morning
<fabbione> Kamion: right.. can i give you console on it?
<pitti> fabbione: sorry, there was no timestamp attached; I'll restore it from the diff
<fabbione> pitti: thanks
<mvo> pitti: my edubuntu/alternate tests were against 20061017, so if you could restore those too that would be cool
<Kamion> fabbione: sure, can do
<pitti> mvo: we have 17.1 now
<fabbione> Kamion: do you have ssh keys in LP?
<Kamion> fabbione: yes
<fabbione> ok setting up access for you
<Kamion> thanks
<pitti> fabbione: done
<mvo> pitti: ok, I will update the caption in edubuntu then (it say 20061017)
<fabbione> pitti: thanks
<pitti> mvo: whoops, sorry; thanks
<mvo> mdz: I updated #66611 - I flipped the icon and that shows that its not original art, it needs to be removed
<mdz> bug 66611
<Ubugtu> Malone bug 66611 in update-notifier "icon of application crash in the notification area - copyrighted?" [Medium,Confirmed]  http://launchpad.net/bugs/66611
<mvo> look at the last attachment :/
<pitti> mvo: I'm editing the page ATM, will fix the edubuntu timestamp
<ogra> pitti, can you ping me when youre done, i want to add a link for the ltsp testing procedure 
<mvo> pitti: done already I think 
* dholbach burns edubuntu desktop
<tfheen> mvo: no, it's not the same.
* pitti fixes edit conflict with mvo and releases the page for ogra
<mvo> tfheen: no?
<tfheen> mvo: the apple one has a the firing cord going up a fair bit first, ours doesn't.
<infinity> tfheen: I dunno, the differences could be chalked up to really crap anti-aliasing/dithering.
<ogra> pitti, thanks :)
* infinity shrugs.
<mdz> mvo: the shadow also looks a bit different
<tfheen> mvo: also, our glare doesn't bend back.
<tfheen> they're _quite_ similar, but I don't think it's a derivative.
<mdz> it may be inspired but I agree, not likely to be derivative
<tfheen> I'll untarget the bug
<mvo> ok, I will reject the bug then
<mvo> thanks 
<tfheen> mvo: untargetted and comment added.
<mvo> tfheen: thanks
* tfheen gets nostalgic by looking at that "old mac icons" page.
<fabbione> mdz: are we going to reschedule tomorrow's distro meeting?
<mdz> fabbione: we haven't announced one, have we?
<mdz> fabbione: I'm not planning to have one, no
<fabbione> no
<tfheen> mdz: there's one on the fridge calendar at tomorrow 2300 UTC.
<fabbione> but it is still registered on #u-m
<mdz> fabbione: please ask the fridge folks to remove it and mail a reminder to u-d-a
<fabbione> mdz: ok will do
<fabbione> mdz: should i cancel also the one for the release ='
<fabbione> ?
<dholbach> ogra: what are those moclecules in the edubuntu artwork?
<mdz> fabbione: the what?
<mdz> fabbione: oh, next week
<mdz> fabbione: yes
<fabbione> mdz: yeah
<mdz> fabbione: I thought you meant cancel the release from the calendar :-)
<fabbione> yeah right.. 
<ogra> dholbach, cbx33 or LaserJock would know
<fabbione> mdz: i am still waiting the number of your dealer :P
<infinity> dholbach: Can you tell your flunkies that if they upload anything else that produces NEW binaries before the release, I might actually go insane? :)
<cbx33> ah those molucules dholbach 
<ajmitch> infinity: what do we need to buy you in november? :)
<infinity> ajmitch: Nothing, it's my job, but you're welcome to give me pity. :)
<ajmitch> heh
<dholbach> infinity: NEW binaries? which packages were those?
<infinity> dholbach: kphotoalbum, mclibs, paw.
<dholbach> kphotoalbum replaced kimdaba - that I was aware of.
<fabbione> mdz:  i did send the mail but please reject it :)
<fabbione> it's off by 2 hours UTC that shifted to wrong dates :)
<cbx33> you will have to ask LaserJock for the full meaning - they are from his research
<cbx33> I just made the wallpaper
<cbx33> :p
<Treenaks> where can I see it?
* fabbione sighs
<fabbione> ok
<cbx33> Treenaks: see what?
<cbx33> the wallapper?
<Treenaks> cbx33: the edubuntu artwork
<Treenaks> cbx33: yes
<cbx33> hang on I'll grab wiki page
<cbx33> https://wiki.ubuntu.com/EdubuntuArtwork/Finals?highlight=%28artwork%29%7C%28edubuntu%29
<cbx33> that's largely it...there were a few changes to artwork
<cbx33> to the gdm splash
<fabbione> mdz: ok this one is good..
<mdz> fabbione: not in the queue yet
<fabbione> my brain was off by one day :) the email was good
<Treenaks> cbx33: hm, I have no idea about the chemical stuff either :)
<cbx33> heheh
<cbx33> LaserJock knows...he gave me a name for it....but I culdn't even say it...let alone remember it
<Kamion> infinity: those were syncs I did
<doko_> mvo: please could you have a look at http://people.ubuntu.com/~doko/edgy/python-central.debdiff
<infinity> Kamion: Ahh, right, I'll blame you instead tthen, check .:)
<Kamion> heh
<mdz> fabbione: approved
<fabbione> mdz: thanks
<Kamion> dholbach: that's a big bluez-btsco change ...
<dholbach> Kamion: nobody ever took care of it - we just had a wonky cvs checkout in the archive before.
<pitti> mvo: http://www.ic.unicamp.br/~stolfi/PUB/misc/misc/WoMD-bomb.gif and http://www.pineight.com/tokipona/bomb.png look pretty nice, but I didn't yet find out their copyright status
<dholbach> Kamion: the only comments I ever heard about the package we had in the archive was that it was broken - I'm subscribed to its bugs with the bluetooth team - I'm happy to work on the bugs and forward them upstream.
<mvo> pitti: maybe we can use the xblast bombs...
<mvo> doko_: checking
<Kamion> dholbach: ok, your call
<dholbach> Kamion: I'll ask people to test it and add a test case to Bluetooth/TestPlan.
<Kamion> thanks
<dholbach> thank you
<pitti> mdz: I updated the diff, 250 kB now (our orig.tar.gz doesn't have other-licenses)
<jelmer> infinity: any chance you can have a look at the failures building bzr-svn (https://launchpad.net/+builds/+build/255814) or point me at somebody who can?
<Kamion> infinity: did you apply my patch from https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/52679?
<Ubugtu> Malone bug 52679 in linux-source-2.6.15 "link_in_boot not set correctly" [Undecided,Rejected]  
<tfheen> jelmer: dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
<tfheen> that's.. special
<jelmer> yeah, I haven't been able to figure out what causes it
<Kamion> means roughly "there's a dependency cycle that dpkg couldn't figure out how to break", AIUI
<jelmer> especially as it builds fine here locally on edgy and ajmitch was able to build it fine as well
<Kamion> (but check with iwj)
<Kamion> jelmer: to reproduce it locally you'd need to try from a clean chroot
<jelmer> Kamion: Hmm, that's odd - I'll try an install using piuparts
<mdz> pitti: if you ignore mailnews, BeOS and the updated copyright notices then it's pretty manageable
<infinity> Kamion: Argh, slipped off my queue.  I'll roll that out right now.
<pitti> mdz: I finished reviewing the diff. It mostly looks like bug fixes; the only non-bugfix thing seems to be the addition of toolkit/themes/pmstripe/global/browser.css
<mdz> pitti: I'm not sure that has any effect for us either
<pitti> mdz: that file was added to the 'classic' skin jar, but well, it's only a CSS...
<mdz> pitti: it's probably a copy of one elsewhere in the tree as well
<pitti> however, the changes didn't prevent a linking error *grumpf*
<mdz> pitti: oh?
<pitti> /usr/bin/ld: nsCOMPtr.o: relocation R_X86_64_PC32 against `nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const' can not be used when making a shared object; recompile with -fPIC
<pitti> /usr/bin/ld: final link failed: Bad value
<pitti> the funny thing is, everything *is* built with -fPIC already
<seb128> Kamion: I usually mark duplicate bugs rejected and copy the stock message for duplication when closing them so submitter knows what is going on
<infinity> pitti: Last time I saw that in a mozilla codebase, it had to do with visibility-hidden stuff.
<infinity> pitti: s/-/=/
<seb128> not sure if that's useful, but marking duplicate without any comment doesn't really make clear what is going on for the submitter imho
<infinity> pitti: Our thunderbird (and I thought our firefox) carries a patch for that.
<mdz> pitti: does that happen when building the existing source in edgy as well?
<pitti> mdz: will try
<tfheen> is there a kubuntu version of the dist-upgrader tool now?
<mdz> mvo: bug 66708 <- !?
<Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
<pitti> infinity: it does have a patch in the diff.gz
<mvo> mdz: yes, just happend on a edubuntu workstation install - it didn't happen on a ubuntu/amd64/cli install though
<mdz> mvo: the log shows packages being installed from main though; very weird
<mdz> bug 28033
<Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Medium,Confirmed]  http://launchpad.net/bugs/28033
<mvo> mdz: might be a issue with the german mirror, I'm checking that theory right now
<fabbione> Kamion: i reproduce it in d-i again
<fabbione> Kamion: this time no fancy mount options.. just the same FS set
<fabbione> Kamion: you can login again if you want.. it's a d-i shell prompt
<Kamion> infinity: thanks
<doko_> pitti, fabbione: the visibility stuff has problems in 4.1.x, we disabled it in qt and kde
<doko_> infinity: ^^^ (not fabbione)
<Kamion> seb128: well, I maintain that that's wrong for bug triagers to do; they have a higher probability of being wrong about the duplication, and it's one more thing to fix
<Kamion> seb128: and I do think that the big stamp REJECTED discourages submitters of otherwise valid bugs
<Kamion> even if there's other pretty text around it
<Kamion> seb128: comments are definitely useful, but are totally orthogonal to my point about rejections
<Kamion> seb128: and in any case going through a load of bugs that have been marked as duplicates for months and changing the status of all of them to rejected is a waste of time whichever way you slice it
<seb128> right, I agree that changing bugs already marked as duplicated is of no use
<minghua> seb128: by the way I just noticed that LP now auto-subscribe the subscribers of the bug marked at duplicate to the main bug
<pitti> mdz, doko_, infinity: indeed, current firefox package fails the same way
<Kamion> mvo: implies that the main Packages/Release files were broken
<seb128> I'm not sure I agree on not marking new triaged as rejected though
<seb128> minghua: it doing that for some months now I think
<Kamion> seb128: are your triagers all perfect? mine aren't :)
<mdz> infinity: did the rebuild test succeed?
<pitti> doko_: what do you suggest? i. e. how to disable it?
<infinity> pitti: That's very new, then (as of the last week)
<mvo> Kamion: might have been a transient failure, I'm trying to reproduce it now - do you need anything more (beside the logs) from the install? if not, I will go on with the next testt-install
<infinity> mdz: autotest was fine on all arches.
<mdz> the upload Sunday built too
<seb128> Kamion: no, usually they do no mark bugs as rejected though, I'm the one changing the status and adding a comment to give some feedback to the submitter :p
<pitti> maybe it's something strange on my local system
<Kamion> seb128: I always add a comment but don't change the status
<seb128> you have a point
<seb128> I think I just carry the status change habit from bugzilla or something
<doko_> pitti: remove the test, which check for this feature? this are one or two autconf tests. but the last package did build?
<seb128> I would prefer malone adding a stock comment when marking a bug as duplicate
<dholbach> I agree with seb128, I think it makes sense to mark a dup as 'rejected' once you're really sure and want the discussion on that bug to subside - else you could mark as dup and still have it needsinfo to get information
<Kamion> mvo: there's no indication of any problem in the log. :-(
<pitti> infinity: trying on ronne now
<mdz> pitti: is it a clean chroot?
<Kamion> Oct 18 10:19:15 main-menu[2918] : (process:17505): Get:3 http://de.archive.ubuntu
<Kamion> .com edgy/main Packages [932kB] 
<Kamion> ^-- apt-setup looking happy
<pitti> mdz: no, it's my normal work system
<Kamion> fabbione: thanks, logged in
<mvo> Kamion: strange error :/
<mdz> I'm relocating to the office; back in ~35m
<Kamion> mvo: there is one thing I could do about that, although it's a bit intrusive for edgy maybe
<Kamion> mvo: make apt-setup-verify not bother calling apt-get update if the base system is installable from CD and the line starts with 'deb http'
<Kamion> or 'deb-src http'
<mvo> hm ... let me gather some more data, I will watch out for it on my test-installs
<pitti> mdz: fails the same way on ronne
* pitti creates a clean edgy chroot
<ogra> what is localization-config ? its not found in mvo's log 
<Kamion> ogra: a Debian thing not relevant for us
<ogra> ok
<ogra> there are also many locale errors
<Kamion> that will not be relevant
<ogra> but thats user-setup
<ogra> right
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/apt-setup.no-mirror-check.diff <- possible fix/workaround
<Kamion> er, with the syntax errors now fixed too
<Kamion> that would actually fix a lot of bugs because it would make the mirror validation slowness go away for CD install
<Kamion> s
<ogra> yeah
<Kamion> tfheen: ^-- ? probably too late for RC though ...
<ogra> i often install on my laptop with only a broadcom wlan card ... can get quite longish to wait for the mirrir check to time out 
<ogra> *mirror
<tfheen> Kamion: not RC, imo.
<Kamion> tfheen: any opinions on it for edgy? I'll get it tested here ...
<pitti> doko_: hm, disabling the visibility=hidden attribute in configure doesn't seem to help
<tfheen> Kamion: It's just an annoyance, right?  Nothing actually breaks?
<infinity> pitti: Given that the previous package fails for you too, I think that was a red herring on my part.
<doko_> pitti: in all subdirs as well? hmm ...
<pitti> doko_: subdirs? well, it's changed in confdefs.h
<Kamion> tfheen: 10:54 < mdz> mvo: bug 66708 <- !?
<Kamion> 10:54 < Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
<Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
<Kamion> d'oh, pasting Ubugtu output is silly
<Kamion> tfheen: it's probably cosmic rays, but we're staying out in the sun without sunscreen at the moment
<Kamion> /target/usr # touch foo
<Kamion> touch: foo: No space left on device
<Kamion> er, that got truncated
<Kamion>  /target # touch foo
<Kamion>  /target # rm foo
<Kamion>  /target # cd usr
<Kamion>  /target/usr # touch foo
<Kamion>  touch: foo: No space left on device
<Kamion> fabbione: kernel bug, IMO
<tfheen> Kamion: and this one should fix that problem?
<doko_> tfheen: ok to upload python-profiler (multiverse) to add the python2.5 module?
<tfheen> doko_: ask dholbach, I don't do *verse*
<ajmitch> doko_: might as well upload, dholbach would say the same :)
<dholbach> ajmitch: yes :)
<Kamion> tfheen: the effect of that patch should be that CD installs add all our default sources.list entries unconditionally
<Kamion> without checking the mirror
<Kamion> which is actually what I thought we *were* doing, but I missed a case
<tfheen> Kamion: ok.. post-RC, then?
<tfheen> I'd like not to roll new images now.
<Kamion> tfheen: yeah
<Kamion> tfheen: I wonder if we should roll new powerpc images for bug 52679
<Ubugtu> Malone bug 52679 in linux-source-2.6.15 "link_in_boot not set correctly" [Undecided,Rejected]  http://launchpad.net/bugs/52679
<Kamion> rather nasty sleeper bug
<fabbione> Kamion: make sense..
<Kamion> well, just desktop-powerpc
<infinity> Kamion: I can spin a PPC livefs right now, and you can debate whether or not to make an ISO of it.
<Kamion> infinity: yes, can you do so for all of ubuntu kubuntu edubuntu xubuntu, please?
<infinity> Kamion: Yup.
<Kamion> good stuff
<infinity> Spinning.
<infinity> \ | / - ... I really need to add a spinner to the script output.
<pitti> Kamion, infinity: (for the record, I have the ppc/desktop tests assigned to me, and I didn't start testing them yet)
<tfheen> Kamion: just ppc images?  I guess we can do that, yes.
<pitti> I'll probably start doing them in about two or three hours, when the alternate tests are done
<Riddell> infinity: could you give back telepathy-qt
<Riddell> dholbach: it just needed the build-dep on glib-dev you added ^^
<Riddell> ah, mdz is in England
<dholbach> Riddell: it was not installable
<pitti> infinity: hm, I still get the firefox link failure in a super-fresh and clean amd64 chroot; was that tested in the recent autobuild test?
<infinity> pitti: Yes, it was tested, and it was fine.
<pitti> bugger
<infinity> pitti: It also built on the "real" buildds two days ago...
<Riddell> dholbach: well it isn't built
<pitti> infinity: would it be possible to test-build the package on a buildd without uploading/publishing it?
<pitti> I'm at loss here...
<doko_> dholbach, ajmitch: please approve upload of weather-util to make the build independent of the python version
<dholbach> doko_: sure
<infinity> pitti: I can re-test it right now, sure.
<infinity> pitti: You want the current one retested (it pretty obviously works, though), or yours? :)
<pitti> infinity: http://people.ubuntu.com/~pitti/tmp/ has the rc3 package
<infinity> pitti: Kay, I'll spin that right now.
<pitti> infinity: maybe start with mine, and if that fails, test the one in the archive?
<pitti> infinity: *hug*, thanks
<pitti> shouldn't take long, fails after ~ 5 minutes for me
<infinity> Kay.
<infinity> pitti: Same uild-deps at the one in the archive?
<infinity> build, too.
<pitti> infinity: yes, no changes there
<infinity> pitti: Okay, it's building..
<infinity> Riddell: telepathy-qt happy now.
<mdz> infinity: firefox?
<infinity> mdz: Testing pitti's sources on crested right now.
<pitti> mdz: I'm at loss; it fails in a fresh clean edgy chroot, in my normal system, and on ronne
<mdz> that's not very good news
<pitti> let's see what the buildd test does
<infinity> pitti: If it works on crested, I'll walk you through reproducing the EXACT same chroot, and we can see if it's the chroot, or an external factor (your environment leaking sketchy kernel, who knows)
<infinity> s/leaking sk /leaking, sk/
<mdz> I reviewed uploads since the last time it built and nothing caught my eye
<pitti> infinity: also, if it works, I'd appreciate if I could get the binaries to test them in parallel
<infinity> pitti: Of course.
<infinity> SON OF A BITCH.  Argh.
<infinity> (No, it didn't fail)
<pitti> infinity: *phew*
<infinity> But I did lose access to the livefs host I was building on without a screen session.  Go me.
<pitti> infinity: I was just about to say, if it works on the buildd, no need to urgently track it down on my box
<infinity> (Go sketchy power killing my laptop)
<infinity> pitti: ffox still building happily on crested.
<pitti> that's good news
<infinity> And the livefs build hasn't realised it lost a terminal yet.  Here's hoping it doesn't notice until it's done..
<pitti> I guess it's been a while since firefox was actually built on an underlying amd64 edgy, right? iwj builds on i386
<elmo> infinity: you know about castilla right?
<infinity> elmo: Exploded?
<elmo> infinity: yeah - died mid-build, needs recovered blah blah
<infinity> elmo: Cute, I didn't even do anything to it this time.  It's getting more fickle...
<infinity> Oh, or was therea security build going on?
* infinity goes to check.
<infinity> Oh, pike.
<infinity> We should just purge that from the archive.
<infinity> elmo: Thanks.
<tfheen> Riddell: could you please proofread and fix the dist-upgrader information on https://wiki.ubuntu.com/EdgyReleaseCandidateAnnouncement ?
<tfheen> mdz: https://wiki.ubuntu.com/EdgyReleaseCandidateAnnouncement is now up, a bit late, sorry.  Please proofread.
<mdz> tfheen: thanks
<infinity> Is there a clever way to detach a process from a terminal (from another tty) so when your old ssh session finally dies, it doesn't take the process with it? :)
<fabbione> tfheen: shouldn't we add a link to the ReleaseNotes?
<dholbach> hum.... I managed to hose my grub on /dev/sda  -  with "rescue broken system" -> "reinstall grub bootloader" -> /dev/sda or /dev/sda2 I get a return code 20    (/dev/sda{,2}: Not found or not a block device)  - is there anything obvious I might have missed?
<mdz> mvo,tfheen: update-manager -c is necessary for dapper users to upgrade to edgy, yes?
<tfheen> infinity: cryopid it and restart it in screen?
<tfheen> infinity: http://cryopid.berlios.de/
<infinity> tfheen: That would require cryopid being installed on the build in question in the next few seconds/minutes before the sshd dies, but okay. :)
<mvo_> tfheen: for the upgrade, you need to give it "-c -d" (not only -d)
<infinity> (Though it's awfully resillient.. It's been going strong for 10 minutes now..)
<tfheen> mvo_: please fix the wiki page. :-)
<mvo_> tfheen: I will just fix it in the page
<tfheen> fabbione: yes, please add a link in an appropriate spot.
<infinity> Oh, speaking of resillience and livefs builds.
<infinity> Kamion: You can spin the ubuntu-desktop-powerpc ISO.
<mvo> ogra: the usplash image is full of wrong colors for me on edubuntu/amd64 :/
* infinity needs ot go for a bit, or he'll be in deep trouble for being late for dinner.
<infinity> pitti: I don't think ffox is going to fail (it's still building fine), but I'll let you know either way when I get back from sushi.
<mdz> grr, someone clobbered my lock on the announcement
<pitti> infinity: ok, who knows; I guess this was lingering for ages already then
<pitti> infinity: so I'll download the binaries for testing here
<mvo> mdz: that might have been me, but I haven't seen a message that it was locked
<mdz> mvo: it's easy to miss
<mvo> mdz: my mistake, the history shows it was there :/
<mvo> just overwrite my changes
<fabbione> mvo: are you next in queue?
<fabbione> (editing the wiki?)
<fabbione> if so can you add directly the link to https://wiki.ubuntu.com/EdgyReleaseNotes ?
<fabbione> pointless that we edit the page a gazillion times
<mvo> I can wait, no problem
<fabbione> mdz: are you still editing the page?
<fabbione> oh yes
<fabbione> ok
<fabbione> nevermind
<mdz> fabbione: yes
<Kamion> infinity: running, thanks
<pitti> Kamion: oh, nice, contrary to yesterday an expert install asks me whether or not to install ubuntu-desktop
<mdz> fabbione: finished for now if you have something to add
<fabbione> mdz: ok thanks
<mdz> Riddell: when fabbione is finished, the release candidate announcement needs proper Kubuntu upgrade instructions from you
<Riddell> mdz: yeah, I was waiting on the wiki page lock 
<mdz> fabbione: please also fix the duplicate text in the ubuntu upgrade instructions; that was from an edit conflict
<Kamion> pitti: ... not something I knowingly changed
<Kamion> mdz: should notes about intra-edgy upgrades go in EdgyUpgrades?
<mdz> Kamion: yes, in a separate section
<fabbione> mdz: i don't see any duplicate text.. 
<mdz> fabbione:     *
<mdz>       update manager explicitly. To do this, press Alt-F2 (or open a Terminal using Applications -> Accessories ->Terminal) and type the following command:
<mdz>           o
<mdz>             gksudo "update-manager -c -d"
<mdz>       a Terminal using Applications -> Accessories ->Terminal) and type the command:
<mdz>           o
<mdz>             gksudo "update-manager -c -d"
<mdz>       This step will not be necessary on the final release.
<fabbione> oh
<mdz> bug 64171
<fabbione> it's not there... 
<mdz> tfheen must have fixed it
<fabbione> ok i did stop editing
<mdz> Riddell: all yours
<tfheen> mdz: I haven't edited it since my initial version.
<fabbione> meh.. i am an idiot.. this is going via email..
<fabbione> Riddell: can you please fix the URL to EdgyReleaseNotes to be a full URL and not just a wiki page name?
<Riddell> fabbione: sure
<fabbione> thanks
<mdz> tfheen: there are two entries with your name in the history
<tfheen> mdz: weird.
<mdz> tfheen: it looks as if it was reverted in fact
<Kamion> somebody should put {{{ }}} around that announcement so the wiki doesn't try to render the e-mail formatting
<fabbione> mvo: can you add the apt-get dist-upgrade bug note to EdgyReleaseNotes please?
<tfheen> maybe my browser did something silly.
<mdz> yes, my edits have been lost
<fabbione> you probably know better than me how to express that
<Kamion> tfheen: can we just remove the oem-config bit from EdgyReleaseNotes?
<tfheen> Kamion: yes
<mdz> Riddell: let me know when you're finished so I can redo
<Kamion> fabbione: are you still editing EdgyUpgrades? your lock has timed out
<fabbione> i didn't edit it
<fabbione> not even for a sec..
<Kamion> fabbione: er, EdgyReleaseNotes I mean
<fabbione> just read it
<fabbione> same
<fabbione> go ahead
<Kamion> ok
<tfheen> mdz: sorry. :-(
<mvo> fabbione: yes, once its not locked anymore
<tfheen> Riddell: kubuntu still doesn't have a dist-upgrader?
<fabbione> mvo: ok
<fabbione> thanks
<Kamion> btw, I've tested that apt-setup fix (with strace to see what it was doing) and it works perfectly; IMO we should apply that post-RC
<dholbach> I have a weird feeling about this:   Running the livecd, I mount a partition from my harddisk to /mnt, now I have lots of /mnt/sda{,1,2,3,4,5,..} entries (and not in /mnt/dev/sda*)
<mdz> Kamion: agreed; that's been nothing but trouble
<dholbach> and it hinders me from chrooting and fixing my grub
<tfheen> Kamion: post-rc it is.
<mdz> dholbach: I don't follow
<tfheen> Kamion: I have poked the cdrom-checker bug, but I don't see why it does that.  I can reproduce it just fine, though
<Riddell> tfheen: no it's not been possible until very recently, definately in edgy+1
<Riddell> mdz: I'm done
<mdz> Riddell: thanks
* mdz <- announcement lock
<fabbione> Riddell: feh... wiki.Kubuntu ??
* Kamion -> lunch, then buying DVDs that aren't horribly scratched and dirty
<fabbione> mdz: the url for the ReleaseNotes is wrong :)
<dholbach> mdz: in an attempt to fix grub on my harddisk (it might have been my stupidity during the installation), I boot the livecd, mount the partition on the harddisk to /mnt and now have  /mnt/sda*  entries, instead of having them in /mnt/dev/sda*
<Riddell> fabbione: works for me (but mostly it's the shortcut I have set in konqueror)
<mvo> am I the only one with no shutdown usplash on the livecd (amd64)?
<dholbach> that's why grub-install gives me return code 20    /dev/sda{,2}: Not found or not a block device
<tfheen> dholbach: cd /dev ; MAKEDEV generic
<fabbione> Riddell: yeah it works.. still :) don't try to steal our users :P
<mdz> ok, restored mvo and my edits
<mdz> fabbione: fixed
<fabbione> mdz: thanks
<mdz> but perhaps we should have separate Ubuntu and Kubuntu release notes
<mdz> dholbach: how did they get there?
<mdz> dholbach: and where did your /dev go?
<mdz> dholbach: you should still have an old static /dev on your root filesystem
<dholbach> mdz: that's on the chrooted partition on the harddisk
<dholbach> what I found interesting is that I have /mnt/sda*
<dholbach> mdz: I guess (I'll retry), that on an edubuntu-desktop install to sdb, I was not cautious enough about choosing where to write grub too
<dholbach> s/too/to
<mdz> dholbach: that doesn't explain device nodes appearing randomly in /
<dholbach> no, not really
<simira> Kamion: lots of good work today! Thank you.
<dholbach> tfheen: thanks for the tip with "MAKEDEV generic", it was good enough to make grub-install happy again
<dholbach> and the grub is fixed again -- I'll try another install with a sata and an usb disk now
<mdz> infinity: the sed pattern in initramfs-tools.preinst needs to be anchored
<mdz> infinity: in order to avoid a conffile prompt on upgrade from dapper
<mdz> infinity: -##RESUME=  +#RESUME=
<mdz> I'll fix
<mdz> not needed for RC
<mdz> mvo: did this not turn up during your upgrade tests?
<mvo> mdz: it did, see my bugreport about it
<mvo> mdz: and my entry on the Tests/Current page :)
<mdz> mvo: bug#?
<mvo> mdz: bug 66599
<mdz> mvo: I didn't see it because it's not targeted; please target to 6.10
<mvo> mdz: right, sorry. targeted now
<mdz> tfheen: eyeball the one-liner for me?
<mdz> -                               sed -i -e "s/RESUME=.*/#RESUME=/" /etc/mkinitramfs/initramfs.conf
<mdz> +                               sed -i -e "s/^RESUME=.*/#RESUME=/" /etc/mkinitramfs/initramfs.conf
<mvo> mdz: should all the stuff found during the RC tests (e.g. bug #66726) targeted by default?
<tfheen> mdz: "only comment out if it's not commented before".  Check.
<fabbione> mdz: looks good
<mdz> mvo: things which need fixing for final (and unnecessary conffile prompts generally do) should be targeted
<ogra> mvo, i'm still waiting for Seveas, he wanted to ping me if the usplash theme stuff is fixed completely
<Seveas> ogra, and I'm waiting for fschoep for images and mjg59 to fix usplash :/
<mvo> ogra: I targeted #66726 for release
<mdz> tfheen: I don't think it's necessary to include that on the CDs, but might be worthwhile to accept into the archive
<ogra> bug 66726
<Seveas> (bot dead)
<fabbione> mvo: are you still editing Testing/Current? your lock did time out
<mvo> fabbione: no, feel free to edit/overwrite, don't know why the lock is still there
<Hobbsee> Seveas: resurrect bot, kthnksbye!
<infinity> mdz: D'oh..  I tested it on a broken conffile, not on a good one.  Stupid me.
<tfheen> mdz: so post-RC, then.
<fabbione> mvo: thanks done
* fabbione heads offline for a while
<infinity> pitti: ffox built fine right up until the part where I had an invalid CurrentlyBuilding... Erk.  Re-running to get you binaries.
<slomo> Tonio_: regarding your k9copy upload... mencoder is in multiverse and k9copy in universe
<Tonio_> slomo: Kamion told me he would demote it to multiverse
<Tonio_> slomo: he probably forgot, I'll ping him
<StevenK> My local mirror has it in multiverse.
<slomo> Tonio_: oh ok... i only saw the -changes mail
<Tonio_> slomo: no pb :)
<gnomefreak> i also have it in multiverse
<infinity> Kamion: kubuntu and edubuntu livefses finished while I was at dinner.  Oh, and xubuntu just finished now.  Cheers.
<tfheen> Kamion: so, the cdrom-checker-doesn't-reboot bug is probably a bug in debconf.  It seems to reap the wrong process.
<tfheen> Kamion: I can _probably_ work around that by just calling reboot in the menu script.
<pitti> infinity: ah, too bad
<infinity> pitti: Won't take too long.
<Kamion> tfheen: seriously? nifty
<tfheen> Kamion: which one of them?  That it blows up or that I can fix it?
<Kamion> slomo: I accepted it and then demoted to universe, so the -changes mail is no longer accurate
<Kamion> tfheen: both :-)
<Kamion> but I meant the former
<tfheen> Kamion: of course, this doesn't make any kind of sense since it waitpid's on what I believe is the correct pid.
<pitti> mdz: want me to upgrade mozilla-firefox-locale-all to 2.0rc3, too? This will reintroduce relatively important languages like pt-BR, which have been dropped when we went to 2.0beta in edgy
<pitti> mdz: (this will not cause any NEW packages, there are empty transitional packages ATM)
<tfheen> Kamion: oh, I found the bug.  confmodule_run returns a pid.  debconf(.c) never saves that in the confmodule struct.  What then happens is we wait for any child process in the same process group as ourselves and the catch the wrong one.
<tfheen> Kamion: if we just save the fork-ed pid in the default case in confmodule_run it should all work fine.
<tfheen> Kamion: I'm not sure I want to change those bits of cdebconf now, though
<Kamion> no, absolutely
<janimo> heno: i made v2 start orca in mag mode w/o speech with a one line change to the casper script, do you think it should be in the release?
<tfheen> Kamion: the minimal-impact fix is just to add an if [ "$RET" -eq 12 ] ; then reboot ; fi to cdrom-checker-menu
<tfheen> Kamion: I can do that.
<Kamion> oh, yeah, that sighandler in debconf.c is dodgy#
<Kamion> are you even allowed to waitpid in a signal handler?
<tfheen> probably not.
<Kamion> of course it then goes on to SAVE A DATABASE IN A SIGNAL HANDLER
<Kamion> which I've already filed a bug on
* tfheen chuckles.
<Kamion> I made it not do that in the SIGCHLD case as a band-aid
<tfheen> should we have a "clean out dodgy code from cdebconf spec" for edgy+1?
<tfheen> there's this, there's the crack about using stdin/stdout and other things.
<seb128> vim-tiny built without multibyte support (bug #361378), would it been considered as something to fix for edgy? A bug triager pointed it on #ubuntu-bugs, it seems to be the cause for some bugs already reported
<tfheen> seb128: not edgy.  IMO.
<Kamion> tfheen: the signal handling is just a bug, but I'd like to get unixsocket in for edgy+1, yes
<pips1> bug 66726
<Ubugtu> Malone bug 66726 in usplash "edubuntu artw ork has funny colors on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66726
<seb128> bug #66733 I mean
<Ubugtu> Malone bug 66733 in vim "Edgy's vim-tiny doesn't have multibyte support" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66733
<seb128> tfheen: ok
<seb128> tfheen: I'm asking because that's the default vim, and it doesn't allow to edit utf-8 files correctly apparently
<Kamion> hmm, that is rather nasty
<heno> janimo: does it work in gnome as well?
<tfheen> oh, I thought vim was desktop
<janimo> heno: I only tested in gnome :)
<tfheen> but it's just -ship.
<tfheen> seb128: I think we should fix it, then.  Post-RC.
<heno> janimo: it would be nice if that could ship yes
<Kamion> vim-tiny is minimal
<Kamion> I'm happy to take responsibility for fixing that post-RC
<janimo> heno: I'll attach the patch to the same bug in LP
<tfheen> Kamion: yeah, I knew that, but I thought vim proper was -desktop.
<seb128> Kamion: thank you
<heno> ok, thanks
<seb128> tfheen: the issue is vim-tiny
<Kamion> milestoned and assigned to me
<tfheen> seb128: yes, but it would have been less of an issue if vim (proper) was -desktop.
<seb128> tfheen: right
<tfheen> Kamion: http://err.no/patches/cdrom_checker_workaround_cdebconf_exit_status_propagation.diff works for me.  Post-RC?
<infinity> pitti: chinstrap:~adconrad/ffox/
<infinity> Kamion: Did you get my above message and re-spin the other desktop/live ISOs?
<pitti> infinity: yay
<infinity> pitti: Do you want a matching i386+all build to go with that?
<infinity> pitti: I didn't build arch-indep in that build...
<pitti> infinity: would be nice for a call for testing
<infinity> pitti: Oh, true, I'll do i386+all and powerpc then, so you can get broad testing.
<mdz> Riddell: what's the story with bug 63325?
<Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  http://launchpad.net/bugs/63325
<Riddell> mdz: I've been working on a fix but not got it totally sorted yet, if it doesn't get fixed it's not the biggest of problems
<Kamion> infinity: yes, done
<infinity> Kamion: Cool.
<infinity> Just checking. :)
<Kamion> tfheen: fine by me if it's tested
<Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
<cbx33> is there a known problem with printing?
<cbx33> or was there?
<seb128> cbx33: printing is wide
<cbx33> um....gnome printing 
<seb128> some extra details on what sort of issue would probably make easier for you to get a reply
<seb128> still wide
<seb128> I was thinking to something like
<seb128> "printing from gedit generates only blank pages"
<seb128> or something like that :)
<seb128> (the example is a random example, not a real one)
<cbx33> well....I have to confirm but since my update to edgy...printing seems totally broken
<seb128> "totally broken" still not good
<seb128> how broken?
<seb128> do you get any message?
<cbx33> I'm getting more info
<cbx33> hang on
<seb128> pages are not going out of the printer?
<seb128> content is not correct?
<cbx33> pages seem to go into the queue
<Keybuk> tfheen: jamesh reported bug #66360, it's a trivial fix (sync from Debian -- which just brings in a translation update)
<Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Unknown,Unknown]  http://launchpad.net/bugs/66360
<cbx33> lemme just check the machine it's connecting to
<Keybuk> tfheen: basically a package missed that still uses daniels X paths, rather than real ones
<cbx33> seb128 ignore that 
<seb128> cbx33: ?
<cbx33> it's working now...must have just been having a slow day
<seb128> k
<tfheen> Keybuk: I wonder why I have /usr/share/X11/fonts still.
<Keybuk> tfheen: upgrade?
<tfheen> Keybuk: it should have been nuked then
<Keybuk> mine is empty and just contains fontconfig crap
<tfheen> yes, it's just fonts.* and encodings.dir here too.
<mdz> Riddell: medium or low?
<pitti> mdz: ah, the m-firefox-locale-all question more or less resolved itself -- we need to ship the matching xpis unless we want to ship with a broken hel0p
<pitti> s/0//
<mdz> pitti: oh, I missed that question
<mdz> pitti: does that involve a round trip to rosetta?
<pitti> mdz: no
<mdz> ok
<pitti> mdz: we don't have langpack support for Firefox yet
<mdz> right
<mdz> and we don't export XPIs either
<pitti> mdz: of course I'll test all languages that we ship
<mdz> pitti: how many of those do you speak? ;-)
<pitti> s/ship/support/
<pitti> mdz: well, I can't check the translations obviously, but I can check for XML failures and if the help works :)
<pitti> I can check German, en-GB, and Russian, and I can recognize some Spanish, Czech, Polish, and French words
<pitti> the rest is 'ah, looks nice and looks like Chinese' :)
<mdz> pitti,sfllaw: I think the manual partitioning and auto resize test cases should be reversed in order, since it seems that usually manual partitioning is necessary to get a layout which can be auto-resized
<mdz> the page should probably have a note about how to get there as well
<pitti> mdz: yesterday I thought I had figured out how to get there, but I still cannot reproduce it consistently
<mdz> erase disk -> auto-resize used to work
<mdz> but no longer
<mdz> (used to work in dapperish times)
<pitti> mdz: apparently it does for Kamion
<pitti> but not for me
<mdz> nor me
<mdz> (in vmware)
<pitti> I usually do a manual install with a single large partition
<mdz> and no swap?
<pitti> putting swap as a first partition works, too
<leonel> hello  where can I find or ask about  SUN JDK  in ubuntu ?
<leonel> hello  where can I find information about updates for the    SUN JDK  in ubuntu ?
<Mirv> leonel: ask in channel #ubuntu
<bddebian> Howdy folks
<leonel> ok  Mirv thanks
<Riddell> mdz: low I guess, it just means some translations will be unused
<doko_> tfheen: please consider http://people.ubuntu.com/~doko/edgy/python-central.debdiff for the RC, reviewed by mvo; it makes the upgrade more robust and allows people with broken installations to recover.
<pitti> hi sbalneav 
<sbalneav> Hey pitti!
<sbalneav> I'll be buying you those beers I owe you soon!
<sbalneav> :)
<pitti> sbalneav: you'll come to UMV?
<sbalneav> I will!
<sbalneav> Like a bad penny, I keep turning up :)
<pitti> sbalneav: great! I'm looking forward to seeing you again
<sbalneav> Likewise!
<tfheen> doko_: no, for RC it's not appropriate.
<sladen> hope so
<mdz> Riddell: jane pointed out that the kubuntu upgrade instructions need a bit more detail; please see the FIXME
<mvo> fabbione: I drafted some notes about the upgrade
<pitti> mvo, infinity: on dapper->edgy upgrade I get a conffile question about /etc/initramfs-tools/initramfs.conf (##RESUME= -> #RESUME=); is that known?
<thom> pitti: mdz was fixing that earlier
<mdz> pitti: fix is uploaded and queued for post-RC
<pitti> ah
<Riddell> mdz: done
<mdz> Riddell: thanks
<mdz> sfllaw: ping
<mvo> pitti: yes, see the Testing/Current page
<pitti> mvo: ok, thanks
<mvo> np
* mvo takes a break
<infinity> pitti: Okay, concrete proof I need sleep sometime; I just made the same CurrenlyBuilding mistake on the other two builds.  Re-building for you. :/
<pitti> infinity: you rock
<infinity> pitti: Not today, I don't. :)
<pitti> maybe today a little less than usual :)
<mdz> pitti: so it appears that it works OK on the buildds but not in the chroots you tried?
<pitti> mdz: right
<infinity> mdz: Yeah, I'll have to work with pitti a bit later to see why it's not working on his box.  Could be a sleeper bug somewhere.
<pitti> mdz: I can live with that for the moment, although it doesn't feel right
<pitti> aah, I finally found the culprit that's breaking half of firefox translations
<mdz> infinity: not his box or the porting box
<mdz> pitti: oh?
<infinity> mdz: Yeah, that's even worse.
<pitti> mdz: yeah, installing one faulty XPI ruins a random subset of other translations :)
<mdz> pitti: this was only on amd64 in both cases, right?  did it build for you on i386?
<pitti> mdz: right, I didn't try i386, since I don't have an i386 edgy here ATM
<keescook> (joining in the middle of the conversation) what wasn't building?  Can I help test?  (i've got both amd64 and i386 edgy chroots)
<pitti> keescook: firefox isn't building for me on amd64/edgy
<mdz> keescook: a very strange firefox build failure which happened for pitti locally, and on another manual build as well, but doesn't happen on the autobuilders
<infinity> keescook: firefox doesn't build on ronne or on pitti's machine, but works fine on my buildds and my laptop.
<mdz> infinity: i386 laptop?
<pitti> mdz: ... and does happen on ronne, too
<infinity> mdz: Yeah.
<mdz> pitti: do you have a full build log?
<pitti> mdz: ronne should be quite similar to the buildds, with running dapper kernel and all that
<infinity> pitti: Will you be around tomorrow for me to walk you through recreating a buildd-alike on your machine to narrow down some variables?
<infinity> The buildds don't run dapper kernels, they run a home-brew 2.6.15.7.
<pitti> mdz: http://people.ubuntu.com/~pitti/tmp/firefox_1.99+2.0rc3+dfsg-0ubuntu1_amd64.build
<pitti> infinity: can do
<elmo> infinity: it's dapper kernel source, just custom config
<infinity> elmo: Ahh, kay.
<elmo> and ronne == buildds, for kernels.  for most arches.  the less well supported arches (powerpc, sparc, hppa) all run dapper kernels
<infinity> I expect ronne's is more or less the same anyway.
<keescook> hmm. where's the .dsc?  I can stuff it through my sbuild/schroot setup and see what happens.
<infinity> pitti: How's your bandwidth?
<pitti> infinity: poor
<infinity> keescook: The .dsc is there.
<pitti> infinity: well, 300 kB/s, but only 300 MB quota left for the next couple of days
<keescook> infinity: ah, gotcha
<infinity> pitti: Ow... Kay.
<dholbach> did we get oopses like that already (installation on usb disk):  http://daniel.holba.ch/temp/oops ?
<pitti> infinity: well, should be a little more actually
<pitti> infinity: I have 3 GB in any seven days
<pitti> and I'm at 80%
<elmo> let me dist-upgrade edgy on ronne
<elmo> it's bound to be out-of-date
<infinity> pitti: Alright, well, the chroot tarballs are small anyway, so if you have a hot apt cache you can steal the build-deps from, it won't be too bad. :)
<mdz> pitti: your local chroot is up-to-date, right?
<pitti> infinity: I do have all build deps for firefox here
<mdz> infinity: do we still wrap gcc on the buildds?
<pitti> mdz: right, I just freshly created it and installed build-deps from CD
<pitti> s/CD/archive/
<infinity> pitti: Kay, tomorrow we'll play with "making it just like crested", then.
<pitti> my main system is up to date, too
<pitti> infinity: heh, let's :)
<infinity> mdz: No more gcc-opt or ccache.  It's just bare g++
<Kamion> dholbach: that's usually squashfs reacting REALLY BADLY to a badly burned CD or a dirty CD drive lens
<mdz> pitti: can we compare the nsCOMPtr.o from a good build and a failed build?
<dholbach> Kamion: oh good to know, I'll give it another try then - thanks.
<infinity> mdz: We could if I hadn't blown away the chroot I used to build.  I can always re-do the amd64 build, though.
<elmo> (no ccache?!)
<pitti> mdz: should be fine to compare against ronne:~pitti/firefox/firefox-1.99+2.0rc3+dfsg (against infinity's build tree)
<infinity> elmo: It was on my todo to get ccache back in one way or another after removing gcc-opt from the equation, but it wasn't a high priority, as the package that always seemed to benefit the most (12 xorg uploads in a day, yay!) was a non-issue now.
<infinity> elmo: And taking it out of the equation does prevent some quirkier FTBFS issues with some sketchy build systems *cough*scons*cough*
<elmo> fair enough
<pitti> okay, powerpc/alternate and dist-upgrade is happy
<mdz> http://www.google.co.uk/search?q=nsCOMPtr.o%3A+relocation+R_X86_64_PC32&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:unofficial&client=firefox-a
<pitti> tfheen: so you rolled 17.2 for all architectures again? I thought only for ppc?
<infinity> pitti: Re-rolling powerpc will re-publish everythin else under the same name/directory.
<mdz> also bug 63814
<Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
<mdz> apparently dholbach saw this before as well
<mdz> bug 61104 seems relevant
<Ubugtu> Malone bug 61104 in gcc-4.1 "Build process of firefox trunk is broken with both gcc 4.1.1 and gcc 4.0 !" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61104
<mdz> doko_: ^^
<pitti> infinity: ah, so for i386 and amd64, 17.1 and .2 are identical?
<infinity> pitti: Should be, yes.
<infinity> pitti: Timestamps should give that way.
<pitti> well, given that the desktop testing matrix is empty anyway, I can as well bump the version
<pitti> infinity: s/17.2/18; s/17.1/17.2/ of course
<infinity> pitti: Yeah, note the timestamps at http://cdimage.ubuntu.com/daily-live/20061018/ and how only the powerpc ISO is "new", the rest are a bit stale.
<infinity> (But the torrents get re-done on each re-publish)
<pitti> ah, sweet
<Kamion> pitti: correct, as I said a while back
<Kamion> 14:09 < Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
<pitti> ah, didn't catch that
<elmo> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... test: 1: ==: unexpected operator
<Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
<mdz> there are quite a lot of reports of this same build failure with firefox/thunderbird on the web
<elmo> no
<elmo> are those relevant?
<elmo> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... test: 1: ==: unexpected operator
<Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
<elmo> no
<elmo> I saw that flash past in a build log
<sfllaw> Kamion: Thanks.
<mdz> elmo: oooh
<elmo> god, I would kill for buildd.d.o/pkgname type shortcuts in launchpad
<pitti> mdz: for testing I entirely disabled the visibility=hidden check in configure, didn't help
<mdz> pitti: what does it do if the test succeeds?
<pitti> mdz: I'll fix the == and check if it works with the bug test
<infinity> elmo: I'm to the point of doing javascript bookmark popups in firefox to bounce me places.
<mdz> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes
<mdz> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no
<Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
<Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
<mdz> pitti: that test passes on the buildds
<elmo> mdz: the amd64 buildd doesn't have that unexpected operator gumph
<mdz> infinity: what's /bin/sh on the buildds
<infinity> Ah-ha.
<pitti> right, == is a bashism
<infinity> mdz: /bin/sh on the buildds is bash, because I didn't want to break the world 3 weeks ago when I noticed it hadn't been switched.
<infinity> So, we have a winner here.
<mdz> ok
<mdz> so it's a gcc bug
<mdz> but firefox works around it
<infinity> mdz: (It's going to dash first thing in feisty)
<mdz> but the workaround has a bashism
<pitti> mdz: ok, I'll fix the firefox source accordingly
<mdz> wheels within wheels
<infinity> pitti: If you fix the bashisms, does the world work for you?
<elmo> within wheels within wheels
<mdz> infinity: I bet a dollar
<infinity> I'm not taking that bet.
<elmo> I'm test building on ronne now, will let you know
<pitti> elmo: heh, me too; /me cancels
<mdz> doko: is gcc 20297 the same as bug 63814?
<Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
<elmo> = is the non-bash version, right?
<infinity> elmo: yes.
<Kamion> @bugtracker add gcc bugzilla http://gcc.gnu.org/bugzilla/
<Kamion> wonder if I have leet Ubugtu privileges somehow
<Kamion> gcc bug 26905
<Ubugtu> gcc bug 26905 in c++ "default-visibility class symbol improperly resolved as hidden-visibility" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
<infinity> Apparently.
<Kamion> bingo
<Kamion> GCC bug 20297
<Ubugtu> gcc bug 20297 in middle-end "#pragma GCC visibility isn't properly handled for builtin functions" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
<mdz> doko: I meant 61104
<sladen> elmo: = is posix  == is bash
<infinity> I've never understood why that Cism crept into bash anyway, but whatever.
<infinity> Yay for confusion.
<mdz> pitti: is that an upstream bug?
<pitti> mdz: the bashism? no, that's a Debian specific patch to work around the gcc problem
<mdz> yes, the bashism. ah
<infinity> Oo, go us.
<mdz> pitti: what does it do to work around the bug?
* pitti looks and curses about firefox' total absence of a patch system
<sladen> infinity: mentally I prefer '==' since '=' is something else, namely assignment.  Languages like basic are confusing to beginners because two different operators share one representation
<elmo> the build seems to be going further, I suspect that fixes it
<infinity> sladen: Yeah, but you can't assing in shell with $var = foo, so...
<mdz> sladen: = is equality, == is very very equality
<infinity> sladen: I understand why C (and perl and PHP, and many languages) need to make the distinction, but shell just plain doesn't let you do that anyway, so adding a == operator to make others more comfy with bash just ends up confusing (and making us write bad patches, apparently)
<Ng> hey folks, apologies for being slightly offtopic, but if any of you have a SIP client, could you call 5501@canonical.com now to give us a hand with some testing please?
<sivang> Ng: don't forget those hubackup bugs :)
<sivang> re all
<Ng> sivang: yeah I have them in tomboy. I noticed most of them are reported already
<sivang> Ng: cool
<sladen> Ng: so, who's in there?
<pitti> mdz: it does this: VISIBILITY_FLAGS='-I$(DIST)/include/system_wrappers -include $(topsrcdir)/config/gcc_hidden.h'
<pitti> mdz: and the latter does '#pragma GCC visibility push(hidden)'
<elmo> ok, this isn't actually offtopic, it's for UDS
<elmo> if you have a machine with any kind of soundcard, regardless of whether or not you have headphones or a mic, please help us stress test the conf call facility by dialing 5501@canonical.com
<Spads> also, it helps if you try the echo test out first at 6701@canonical.com
<pitti> does that work with ekiga?
<elmo> pitti: yes
<Spads> pitti: most of us are using ekiga
<elmo> it works with any SIP capable phone
<elmo> or client
* Nafallo makes a search for his headset
<Nafallo> hmm
<Nafallo> low volume :-/
<Ng> turning off echo cancellation is a good plan
<pitti> Spads: if I dial 6701, I get two 'free' tones, and then a 'busy' tone; is that correct?
<Spads> pitti: hmmm, it should stay connected, and repeat everything you say back to you
<pitti> argh, I see, login has failed
<pitti> I do remember seeing 'logged in' (freely translated), now it's failed'
<Nafallo> Ng: I finally found the option, thanks :-)
<elmo> pitti: you shouldn't need to login
<elmo> not to get to the conf call at least
<pitti> hmm
<elmo> I doubt the echo test either
<pitti> elmo: I get the same 2x free, 1x busy, hangup for 5501
<elmo> pitti: hmm, maybe it's your firewall of death
<pitti> sure, I disabled STUN as advised in the wiki
<pitti> but that's only for incoming calls anyway, isn't it?
<Nafallo> oh? supposed to disable that?
<keescook> it seemed to me that if you're behind a NAT, and you can get registered, you don't need STUN.
<keescook> but I've only tried sip once before.
<pitti> hm, it says 'security check failed' in the status bar, does that mean anything?
<keescook> not sure.  :(  wrong password?
<pitti> it's the one I was given by mail
<mdz> tfheen: is the current candidate still without showstoppers?
<mdz> tfheen: and have you heard from sfllaw at all?
<tfheen> mdz: I haven't heard of any showstoppers with them, at least.
<tfheen> mdz: no, I haven't heard from Simon.
<mdz> he mentioned something the other day about not feeling well I think
<pitti> no, still 'login failed: not allowed'
<sfllaw> Uhm, I am here.
<pitti> mdz: ffox build is now going well for me, too
<pitti> \o/
<dholbach> congratulations pitti!
<pitti> dholbach: well, the credit is due to elmo, he spotted the bashism
<dholbach> ahhh great!
<mdz> sfllaw: I take it you didn't see either of my messages in channel earlier?
<doko_> mdz: 61104, tried a backport from the redhat/gcc-4_1-branch, which works for ff, but breaks the OOo build ... it's definitely fixed in 4.2
<mdz> doko_: and we're going with 4.2 after edgy?
<sfllaw> mdz: I saw the one about new PPC images.
<mdz> sfllaw: I didn't say anything about new PPC images
<doko_> mdz: not before it's released. it will branch this week
<sfllaw> mdz: Ah, sorry.  That was Kamion.
<sfllaw> I suppose swapping those auto-resize and manual does make sense.
<mdz> fabbione: why are all of the sparc CD test cases marked N/A?
<mdz> oh, the server ones aren't
* ogra is off for more testing
<mdz> sfllaw: there are no known showstoppers in the current candidate, but very few test cases are filled in
<mdz> sfllaw: all of the most important ones are assigned to cr3, but he isn't in here
<sfllaw> I'll invite him.
<lool> seb128: around?
<lool> seb128: I'd like to discuss the spec on easy codecs installation
<lool> seb128: I wonder if it would make sense to extend its scope slightly to cover more problems; instead of focusing in mime type => gstreamer element mappings, we might want to provide some general feature => package mapping with a common UI to search and install packages or popup web pages
<lool> seb128: this would at least cover the KDE use case
<lool> seb128: concerning the storage of the mappings, I thing Xb- headers would permit some sort of simple implementation which we could automatically provision with gst-inspect at build-time, but it has some limitations because of the packages that would be in repositories not visible to apt; of course, it doesn't cover codecs which are not in packages
<lool> seb128: finally, the specs shortly mentions that non-admin users can't install codecs, but on the other hand gstreamer perfectly permits installing plugins in ~/, so perhaps it makes sense to support this?
<lool> (I've added most of the above on the wiki page of course, but thought it would be interesting to discuss implementation live a little)
<mdz> Kamion: selecting 'use largest continuous free space' with only ~200M of free space seems to allow me to continue although it is doomed to fail
<mdz> and I can't seem to convince it to offer me the resize option
<mdz> cr3: how goes it?
<cr3> mdz: it's going more or less, that installation bug I logged is worrying me
<tfheen> cr3: which bug is that?
<cr3> tfheen: 66632
<tfheen> bug 66632
<Ubugtu> Malone bug 66632 in linux-source-2.6.17 "Ubuntu 6.10 Desktop for i386 installation crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66632
<cr3> sorry for the crappy bug subject, I have no clue what's going on so I preferred to log the bug early instead of waiting a day while trying to gather more information
<tfheen> yes, I'm reading the bug now, judging how critical it is.
<wasabi> ajmitch: ping
<tfheen> cr3: had any chance to test the media, etc on the machine?
<cr3> tfheen: I had tested the media before, as stated in my bug report. I have been running memtest86 all morning, still not finished
<cr3> tfheen: I will update the bug report as soon as I have new information
<tfheen> cr3: I'm worried about your "On the other hand, I am also getting installation failures on other systems."
<cr3> tfheen: I'm trying to get some relevant information from that system as well, and I will probably log another bug report as soon as I have some sort of substance.
<tfheen> cr3: thanks.
<cr3> fuck, crashed again, this time at 22% and last time at 46% :(
<pitti> infinity: are the i386/ppc firefox builds finished?
<mdz> cr3: have you been able to successfully install on any machines?
<cr3> mdz: yes: t1000, t2000, Precision 380, Dimension 9150 and a couple netinstalls on gigabyte boards
<mdz> cr3: great news; could you update Testing/Current with those results?
<cr3> mdz: sure, but I have a few reports to generate beforehand
<mdz> cr3: reports?
<elmo> Kamion: ping?
<Kamion> elmo: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
<elmo> har har
* elmo stabs tollef in the face
<cr3> mdz: certification reports, that is ultimately my responsibility so I need to generate them quickly. it shouldn't take long though, probably an hour or so
* tfheen hugs elmo
<pitti> does anyone else apart from infinity have access to the buildds? infinity did i386 and ppc builds of firefox 2.0rc3, and I'd like to put the binaries on rookery for testing
<tfheen> pitti: the sysadmin team has
<pitti> elmo: ^ if you have a minute, can you please copy these binaries to chinstrap or rookery?
<elmo> what?  soyuz builds?
<elmo> they're not stored on the buildd
<cr3> mdz: I have another installation crash on a Dimension 5150, any files you'd like other than /var/log/dmesg?
<cr3> kern.log seems to contain interesting information as well
<pitti> elmo: I guess so, infinity wanted to manually build them; he did amd64 on a buildd (crested), so I guess he used a buildd for the other arches
<pitti> elmo: right, he spoke about an invalid CurrentlyBuilding, so this must have been a buildd
<mdz> cr3: wiki.ubuntu.com/DebuggingSystemCrash
<mdz> cr3: since it's reproducible, just switch to a text console while the installer goes, and you should either see the panic or at least be able to do sysrq commands to get more info
<elmo> pitti: yeah, sorry, I don't think I can help - you really want a team soyuz person or similar
<elmo> if he built it on crested, that's a soyuz buildd and the binaries are sent back to drescher over XMLRPC and I can't retrieve them from the buildd
<elmo> they really should be available from the librarian, if you can find them in the web UI
<Kamion> mdz: continuous> yes, I don't think we ever filled in that particular bit of intelligence in partman. Bug report on partman-auto please?
<pitti> elmo: ah, thank you anyway
<Kamion> mdz: resize> as usual, I can debug given /var/log/partman (and time to stare at it)
<Kamion> elmo: yes?
<Kamion> right, now that two sets of parents have left I can get some work done ;-)
<Kamion> (though they have been very helpful otherwise ...)
<cbx33> hi guys, inlight of future ubuntu development
<cbx33> what language is most needed by ubuntu?
<cbx33> c/C++/python/mono/Java...?
* cbx33 is itching to be more useful
<pradeep_> cbx33, i think c and python
<thom> c/python/shell
<thom> and you'll be pretty much laughing to start with
<Keybuk> lua!
<pitti> elmo: cprov does not have an accound on adare/vernadsky any more, so he cannot fetch the debs for me; those were manual builds, thus they weren't uploaded anywhere
<mdz> Kamion: ok, it's trivially reproducible for me, so I'll do so now
<Kamion> any chance we could get bug 60071 fixed for final?
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60071
<tfheen> Kamion: I thought I fixed that?
<tfheen> or rather, worked around it.
<Kamion> tfheen: it now fails on /filesystem.squashfs/usr/bin/yelp, but same difference ...
<Kamion> (rather than /casper/filesystem.squashfs/...)
<tfheen> Kamion: is the cdrom mounted?
<Kamion> tfheen: er, it's on a live CD ...
<Kamion> (so yes)
<mdz> Kamion: sounds awfully like a kernel issue
<mdz> presumably /proc/pid/exe has that path
<tfheen> mdz: yes, that's the problem.
<mdz> we could hack around it in l-i for final
<Kamion> tfheen: /proc/pid/cmdline doesn't always have the full path, so that doesn't work
<mdz> but probably not fix the underlying issue
<Kamion> $ cat /proc/7344/cmdline; echo
<Kamion> gnome-terminal
<elmo> Kamion: getting debconf prompts on avril's laptop in the office - 100% sure that's only ever been Ubuntu
<Kamion> elmo: echo GET debian-installer/keymap | sudo debconf-communicate
<tfheen> Kamion: sorry, are the squashfs-es bind-mounted inside the root?
<Kamion> tfheen: not AFAICS
<Kamion> certainly no /filesystem.squashfs directory
<Kamion> no /casper either
<Kamion>   * Don't move-mount all the squashfs-es into / since that confuses mono
<Kamion>     (and some other apps too).  Malone: #62756
<tfheen> Kamion: gnnr. :-/
<tfheen> yes, that's what I hoped fixed it, but apparently not well enough
<Kamion> I think we should be very careful about messing about with the bind/move-mounts at this point
<mdz> Kamion: I am dead serious about hacking around it in l-i
<Kamion> mdz: I entirely agree with you
<tfheen> that sounds like a safer approach, yes.
<Kamion> not much else appears to care
<elmo> Kamion: locked 'cos the config question is still up - is it safe from a diagnosis to just go forward in the upgrade?
<tfheen> I wonder why l-i breaks it, while mono is now happy.
<mdz> why does mono care?
<Kamion> elmo: less /var/cache/debconf/config.dat and see
<Kamion> elmo: also, what default answer did it present? U.S. English?
<tfheen> mdz: ask ajmitch or one of the other Mono guys.
<Kamion> elmo: please don't go forward *quite* yet - shouldn't take long
<elmo> Kamion: noting in config.dat about debian-installer
<bhale> f-spot was looking for a config file in the squashfs
<elmo> /var/log/installer/syslog makes it look like a ubiquity install of some sort
<bhale> not the unionfs
<infinity> pitti: I passed out, sorry, do you still need those builds? (they're done)
<pitti> infinity: would be great
<Kamion> elmo: is there a /var/log/installer/version, or a version number at the top of /var/log/installer/syslog?
<pitti> infinity: as soon as I have them, I call for testing
<mdz> bhale: but why?
<mdz> was it trying to look up the location based on the path to an executable for the running process via /proc?
<avril> Kamion: "Configuring console-setup" is the title, "The origin of the keyboard:" is the question, default answer is "United Kingdom"
<pitti> infinity: (and, no reason to apologize for sleeping in the middle of the night) :)
<bhale> mdz: no idea, tfheen said "hey that looks like l-i, I have a lead on a fix"
<mdz> I don't know where else that's exposed
<bhale> mdz: not sure on what that fix was
<Kamion> interesting that that's the default
<infinity> pitti: Well yeah, it's 3:30am now, but still, I wasn't planning on passing out. :)
<avril> Kamion: no version either in separate file or at top
<bhale> mdz: and yes at /proc
<Kamion> avril: I'm betting it was a pre-release of espresso/ubiquity then
<Kamion> dapper's version copied debian-installer/keymap into the installed system
<Kamion> ubiquity (1.0.10) dapper; urgency=low
<Kamion>   * Copy debian-installer/keymap to the installed system (closes: Malone
<Kamion>     #40627).
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Sun, 28 May 2006 15:46:48 +0100
<avril> hmm, ok
<avril> that's possible, I think I reinstalled this laptop from scratch when it passed from Pregnant Claire to Avril
<Kamion> avril: go ahead with the upgrade - think we just have to suck this up as an annoyance
<avril> Kamion: ok, cool, thanks sorry for the false positive
<bluefoxicy> Nautilus is suddenly misbehaving, it hangs when I access a usb drive
<infinity> pitti: chinstrap:~adconrad/ffox/
<Kamion> it's not necessarily a false positive - ideally we'd upgrade from dapper beta without questions
<bluefoxicy> ls sees the drive fine and I've umounted/mounted/removed/inserted it a bunch of times
<pitti> infinity: thanks! and continue to sleep well
<Kamion> the keymap's just damned hard to parse without the value being recorded
* bluefoxicy guesses a reboot will fix it.
<Kamion> we tried grokking it out of xorg.conf, but console-setup upstream mailed me with some convincing reasons why that was a thorny approach, and I was seeing bugs in it anyway
<Kamion> (convincing reasons> lots of users fix broken autodetected X keymaps using GNOME - the console keymap was probably right because they managed to use it to install, but the X keymap might well not have been)
<avril> Kamion, what about parsing /var/log/installer/syslog? ;-)
<Kamion> avril: ewwwww. is it actually in there?
<avril> Kamion, yep
<avril> ubiquity: apply_keyboard: uk
<avril> ubiquity: apply_keyboard: layout gb
<avril> I was kidding tho
<Kamion> avril: I know how you love parsing non-machine-readable files
<tfheen> avril: don't give Colin ideas, please. :-P
<avril> haha
<Kamion> # What kind of genius logs 3.5 years of removal data in
<Kamion> # semi-human-parseable text and nothing else?  Hmm.  That would be me. :(
<Kamion> # MAAAAAAAAAAAAAADNESSSSSSSSSSSSSSSSS
<avril> thank you for sharing my shame
<Kamion> :-)
<zul> uh..ok
<mdz> Kamion: do we save that stuff somewhere machine-readable on current installs?
<Kamion> mdz: yes, and in dapper too
<Kamion>     for q in ('^console-setup/',):
<Kamion>         misc.ex('debconf-copydb', 'configdb', 'targetdb', '-p', q,
<Kamion>                 '--config=Name:targetdb', '--config=Driver:File',
<Kamion>                 '--config=Filename:%s' % targetdb)
<tfheen> removals.txt is fairly parseable, though.  I wrote something generating RSS out of it some time ago.
<Kamion> aside from debconf-copydb having possibly the craziest command-line syntax evah
<dholbach> hm, it seems that usbdisks get mounted during a desktop install (during/before) the partitioning step
<jonh_wendell> Kamion: are you the person who take care of keyboard setup in edgy install?
<Kamion> jonh_wendell: yes
<jonh_wendell> Kamion: can you take a look at bug 66774?
<Ubugtu> Malone bug 66774 in ubiquity "Wrong configuration for Brazilian keyboard" [Undecided,Confirmed]  http://launchpad.net/bugs/66774
<mdz> Kamion: alternate install in vmware prompts for the X mode?!
<mdz> is that normal?
<Kamion> mdz: yes - vmware doesn't expose that information
<tfheen> Kamion: didn't your xorg upload fix https://launchpad.net/distros/ubuntu/+source/xutils-dev/+bug/65264 ?
<Ubugtu> Malone bug 65264 in xutils-dev "Dapper-Edgy upgrade: three packages are still from dapper" [Undecided,Confirmed]  
<Kamion> AFAIcouldT last I looked
<infinity> mdz: It did in dapper as well.
<Kamion> jonh_wendell: ok, shame I found out about this so late
<infinity> mdz: (I know, since I just did a few dapper test installs in vmware for upgrade testing)
<Kamion> jonh_wendell: may be fixable for edgy, possibly. thanks
<mdz> I don't remember dapper doing that for me, weird
<Kamion> tfheen: yes, I'll close it, thanks
<jonh_wendell> Kamion: thank you
<bluefoxicy> Keybuk:  hey check this bootchart out.
<Keybuk> ...?
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061018-1_desktop.png
<Keybuk> does that thing have an ATI/ALi sound card chip, by any chance?
<bluefoxicy> 00:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
<bluefoxicy> nope
<Keybuk> what about the onboard?
<bluefoxicy> it's disabled in bios.
<Keybuk> just wondering what that long modprobe is
<bluefoxicy> no clue.
<Keybuk> got a copy of /var/log/udev available?
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/udev
<bluefoxicy> Keybuk: can you get udev up earlier, by any chance?
<bluefoxicy> or well, it starts pretty early heh.
<Keybuk> bluefoxicy: nothing much happens before udev
<bluefoxicy> Better question:  What's about the best you can do to get modules loaded as early as technically possible
<Keybuk>       8.710907  add@/devices/pci0000:00/0000:00:09.0/0-0:TR28602
<Keybuk> what's that one?
<bluefoxicy> Keybuk:  Windows XP does its 'preload' (readahead) at boot "while loading drivers" because "drivers take time to initialize and we can capitalize on that time spent doing nothing" or something.  That's what sparked my whole readahead thing. :)
<Keybuk> oh, your sound card
<bluefoxicy> yeah, it is.  Hm.
<Keybuk> bluefoxicy: that's what we tried to do ... except that we don't just load drivers, we do lots of other bits, that also need readahead
<Keybuk> the other one is your usb hub
<bluefoxicy> hmm
<Kamion> and also some of the drivers that take longest to initialise are things like SCSI disk drivers and RAID controllers
<bluefoxicy> Kamion:  nods.
<bluefoxicy> Kamion:  for everything else, there's Vesa?
<bluefoxicy> Keybuk:  will that go away when udevsettle is killed off?
* pitti completes powerpc tests, looks good
<mdz> pitti: great, thank you
<bluefoxicy> boot time is a bunch of little CPU and IO spikes :/  I'm actually pretty amazed at how difficult it is to turn it into one giant massive spike of IO and CPU
<mdz> sfllaw: how is i386?
<pitti> mdz: I can't get ubiquity to offer resizing to me, but it worked fine in d-i
<mdz> pitti: I got it to work
<mdz> my virtual disk needed to be bigger
<Keybuk> bluefoxicy: the fact that the rest of the boot waits for your sound card to faff will go away, yes
<infinity> sfllaw: I noticed you put me on the testing matrix for powerpc.  My powerpc machine can't boot from CDs. :)
<pitti> mdz: hm, I tried with bootstrap/256MB swap/35GB root, bootstrap/35GB root/256 MB swap, and boostrap/36GB root; no dice :(
<mdz> pitti: dunno about powerpc
<Nafallo> lol
* Nafallo read 35G swap first :-P
* Kamion fixes splash-down on amd64
<pitti> Kamion: yay
<pitti> mdz: for the record, firefox 2.0rc3 is prepared and ready for testing on people, locales updated, fixed, and tested, reverse dependencies tested; looks pretty good
* pitti wanders off for some dinner, bbl
<tfheen> "ready for testing on people" sounds like a new drug or biochem weapon or something.
<Nafallo> tfheen: maybe it is :-)
<thom> most mozilla products could be reclassified as pyschological warfare
<mdz> pitti: is there a mail about it?  I'll give it some testing here
<mdz> ah, there it is, on -devel
<Kamion> pitti: first time since breezy that powerpc has gone vaguely smoothly
<Kamion> this is good news
<Kamion> mdz: I always just use vmware's default "8GB, split into 2GB chunks"
<Kamion> which is more than adequate
<mdz> I usually keep them small because I preallocate them
<mdz> usually 4G
<mdz> 6G is enough to get the resize option so I'm using that now
<Kamion> seb128: I've just done two consecutive amd64 desktop CD boots both of which failed to start gnome-settings-daemon
<mdz> I learned this lesson during the dapper release but forgot it
<Kamion> seb128: what do you need me to do?
<mdz> I thought that was fixed
<Kamion> except this time at least it managed to start a usable desktop; last time it seemed to just hang
<Kamion> starting it by hand appears to work fine
<Kamion> classic, strace it and it goes away :(
<pitti> mdz: yup, I mailed u-devel
<pitti> Kamion: indeed, after the recent ubiquity fixes it went surprisingly smooth today
<tfheen> Kamion: it fails during boot because too much other stuff is going on.  It's a timeout.
<tfheen> Kamion: the fix is to increase the dbus activation timeout.
<pitti> Kamion: we increased the timeout from 25 to 40 seconds lately
<pitti> Kamion: if that's still not enough, we have to increase it further, maybe 60 seconds
<pitti> slomo: ^ FYI
* pitti -> really dinner
<Kamion> where does it need to be fixed? g-s-d or dbus?
<slomo> dbus
<tfheen> at least that has been the problem in the past.
<Kamion> it gives a pretty poor impression of the desktop CD, and this is not that slow a machine - increasing that for final sounds relatively safe to me
<infinity> Is this timeout a compiled-in thing?
<tfheen> infinity: yes.
<infinity> Cause it seems one would want a ridiculously long one for the live session, but a shorter one for an installed system.
<infinity> Shame.  So casper can't fiddle with it. :/
<tfheen> we could binpatch it..
<tfheen> we should just not use dbus activation for this, IMO.
<slomo> infinity, tfheen: nope, it's set in the session bus configuration in /etc
<infinity> slomo: Ahh, so there's hope.
* Kamion doesn't see it. Is the key missing by default?
<Kamion> there's /etc/dbus-1/session-local.conf which casper could write
<shawarma> Where can I find a list of the packages installed on the Ubuntu Live CD and the Kubuntu Live CD? (I'm here assuming that it's not just equivalent to [k] ubuntu-desktop and all their dependencies)
<slomo> Kamion: "<limit name="service_start_timeout">40000</limit>" in /etc/dbus-1/session.conf
<Kamion> shawarma: *.manifest files alongside each of them on cdimage
* shawarma slaps his forehead
<Kamion> slomo: not here
<shawarma> Kamion: Of course. thanks.
<slomo> Kamion: oh damn, the patch for it is wrongly applied in the package... i'll add this correctly after RC or now if you want
<mdz> tfheen,Kamion: I've created a 'later' milestone for the 'ooh, really should fix that after the release' bugs
<tfheen> mdz: thanks,
<Kamion> slomo: after RC, please
<mdz> it's a milestone on edgy and might look a little weird but it's something
<slomo> pitti: i wonder what fixed it for you then... :/
<infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
<Kamion> yeah, I've just been uploading my post-RC fixes so that they can sit in the queue
<slomo> infinity: it's just a one-line addition to another file, i forgot that we don't use upstream's session.conf but have our own in debian/
<mc44> pitti: not that this is a regression from rc2, but firefox rc3 still breaks on rss feeds re: bug 61182 - this is not broken in vanilla upstream firefox. I don't know if any who cares for firefox has actually looked at this bug...
<Ubugtu> Malone bug 61182 in firefox "Mozilla Firefox Bon Echo Beta 2 Doesn't show RSS Feed preview" [Unknown,Rejected]  http://launchpad.net/bugs/61182
<mdz> Kamion: this was more for immediately after final
<shawarma> Kamion: Is the manifest by any chance generated from the ubuntu-desktop with some additions? I suppose what I'm actually looking for is what packages are installed on the Live CD, but are not part of ubuntu-desktop (and the same for Kubuntu).
<mdz> ubuntu-6.10 is appropriate for post-RC
<Kamion> mdz: yeah, my comment was unrelated to your comment about milestones; I was replying to 19:20 < infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
<Kamion> shawarma: ubuntu-minimal + ubuntu-standard + ubuntu-desktop + ubuntu-live [+ make sure the right kernel is there] 
<infinity> shawarma: There's an "ubuntu-live" task. (apt-get install ubuntu-live^)
<shawarma> infinity, Kamion: aha! Excellent. Thanks!
<infinity> shawarma: And the one Kamion missed was casper, which isn't in any task. :)
<mdz> Kamion: gotcha
<Kamion> shawarma: easier to see in the seeds (http://people.ubuntu.com/~cjwatson/seeds/edgy/ for a read-only mirror of the Ubuntu edgy seeds)
<Kamion> casper isn't in live because we also build a "livecd-base" that doesn't include the desktop or live seedss
<Kamion> seeds
<Kamion> but maybe casper should be in live anyway, for clarity
<slomo> Kamion: ok, finished... http://slomosnail.de/~slomo/temp/dbus_0.93-0ubuntu3.debdiff if you already want to look at it now...
<infinity> mdz: Do we have any intention of even pretending to care about the nvidia-glx root hole, or is "upgrade to a random beta driver to fix it" just not a good enough answer for us?
<mjg59> infinity: Wouldn't help the legacy ones anyway
<mdz> infinity: we'll wait until there's a proper update
<shawarma> Kamion: Are those seeds the input for germinate?
<Kamion> shawarma: yes
<infinity> Kamion: I vaguely recall we had some reason or other (other than livefs-base) for not having it in the live seeds, but danged if I can remember what that reason was.
<shawarma> Kamion: I see.
<Kamion> c.f. SeedManagement
<mdz> infinity: and -legacy will need to go to universe
<mdz> we can't pretend to support it
<Kamion> multiverse
<mdz> right
<Kamion> mdz: if so, we should make that overrides change nowish
<infinity> mdz: Yeah, like we pretend to support any of it anyway. :/
<Kamion> I don't want to be changing overrides post-release
<mdz> Kamion: still debating whether to change it for edgy
<infinity> It probably should have been in multiverse from its introduction anyway.
<mdz> yes
<mc44> mdz: how about an option for nvidia-beta a la nvidia-legacy, obivoulsy in multiverse as well
<mjg59> mc44: Adds another lump to linux-restricted-modules
<mdz> mc44: far too frozen for that sort of thing
<infinity> A large lump.
<infinity> The nvidia kernel module is huge.
<mjg59> Is it going to be releases-noted?
<mdz> Kamion: ok, let's do it before final
<mdz> mjg59: which? legacy or the bug?
<mjg59> "If you install this, arbitrary websites may 0wn you"
<mc44> fair enough. Just dont like thee idea of random strings on webpages crashing my computer :-/
<pygi> hello all
<mjg59> mdz: The bug
<Kamion> still trying to figure out why nvidia-glx-dev isn't on the demotion list in the first place
<mdz> mjg59: probably a good idea
<mdz> mjg59: though we don't do that for, say, the kernel
<Kamion> s/nvidia-glx-dev/nvidia-glx/
<mdz> I don't think it's necessary
<mdz> Kamion: I think restricted is...weird
<Kamion> mdz: anastacia is supposed to look at both main and restricted
<mjg59> mdz: We don't generally release kernels with known security issues
<Kamion> migration between main<->restricted is entirely manual, yes, but it should notice stuff in restricted that's not seeded
<mdz> mjg59: sure we do; if they become known too close to release there's little point in delaying
<mdz> the difference between releasing with very-recently-known vulnerabilities and unknown vulnerabilities is minimal
<infinity> Kamion: nvidia-glx is in ship.
<Kamion> OH, sigh
<mc44> mdz: but then you expect to update the kernel in a reaobale timeframe
<mc44> *reasonable
<Kamion> infinity: I meant nvidia-glx-legacy, I just can't think/type/whatever
<Kamion> but I worked it out - it's because of Extra-Include: *-dev
<mdz> mc44: and we do. what is your point exactly?
<infinity> Kamion: Fair enough, I can;t do any of those three either. :)
<Kamion> which pulls in nvidia-glx-legacy-dev which pulls in nvidia-glx-legacy
<Kamion> infinity: you can't whatever?
<infinity> Kamion: Indeed.  I'm terrible at it.
<Kamion> mdz: so, Extra-Exclude: nvidia-glx-legacy-dev and demote that pair?
<mc44> mdz: that an update to the kernel would be quick after release so risk is smaller not warrenting a realse note, however it may be a long time before nvvidia fix it in a stable driver, and that may be too dangerous to -update
<mdz> Kamion: yes
<Kamion> mdz: before or after RC?
<mdz> Kamion: after
<shawarma> Kamion: Do you happen to know the Kubuntu equivalents of -minimal and -standard?  Do "they" have such equivalents at all?
<infinity> Makes little difference, since it doesn't ship anyway.
<Kamion> right, I'll do the seed change locally
<mdz> Kamion: unless it's seriously negligible in the risk department
<Kamion> shawarma: all derivatives use the same minimal and standard tasks
<infinity> shawarma: The "minimal" and "standard" tasks are the same for all derivatives.
<Kamion> shawarma: same minimal is a technical requirement (debootstrap); same standard is merely policy
<infinity> shawarma: Again, "apt-get install taskname^"
<shawarma> Kamion, infinity: ah. makes sense.
<shawarma> infinity: apt-get install ubuntu-live^  does not install everything 'apt-get ubuntu-desktop ubuntu-minimal ubuntu-standard' does.
<Kamion> shawarma: it's not meant to.
<infinity> shawarma: No, you need to do all the above-mentioned tasks to get a livefs.
<Kamion> we tried making those inherit at one point and it had complicated undesirable consequences whose specifics I forget exactly (sorry)
<infinity> shawarma: minimal, standard, ubuntu-desktop, ubuntu-live, casper, kernelstuff.
<infinity> Kamion: If nothing else, it makes debugging uninstallable tasks pure hell.
<mdz> Kamion: I believe it was that removing something low on the stack removed all metapackages going upward
<infinity> And that too.
<Kamion> yeah, either of those could've been it
<shawarma> infinity: So 'apt-get install ubuntu-live^ ubuntu-desktop ubuntu-standard ubuntu-minimal linux-generic casper' for ubuntu and 'apt-get install kubuntu-live^ kubuntu-desktop ubuntu-minimal ubuntu-standard casper linux-generic' for Kubuntu?
<Kamion> shawarma: you don't install ubuntu-minimal from scratch - you debootstrap to get that
<shawarma> Kamion: Yes, I was wondering why they didn't just depend downwards.
<infinity> shawarma: More or less, yes, but you start with a debootstrap.
<shawarma> Kamion: Of course, but that's not exactly what I'm trying to do. :-)
<Kamion> and the linux-* are different for different architectures
<shawarma> infinity: Yes, I *would* if I was doing an actual install :-)
<infinity> Kamion: I still install minimal^ anyway, for sheer paranoia's sake.  Not sure why. :)
<shawarma> Kamion: Of course.
<shawarma> infinity: Ah, minimal is a taskk, too?
<Nafallo> pitti: nice changelog on the firefox-build :-)
<Kamion> minimal's only really a task because I'm a completist
<infinity> Kamion: Was there a point when minimal wasn't part of debootstrap?  That could be why it's in livecd.sh
<infinity> (It clearly doesn't need to be anymore)
<shawarma> Kamion: -desktop and -standard are not tasks, right?
<Kamion> infinity: no
<infinity> shawarma: They are.
<Kamion> infinity: before minimal existed, there was base, but that was part of debootstrap then
<shawarma> infinity: Ok.
<Kamion> one of the main reasons for splitting base into minimal and standard was to speed up debootstrap :)
<infinity> Kamion: Right, then, I guess it's just lamont paranoia that I never stripped.
<shawarma> infinity: minimal and standard are not. At least that's why my apt-get tells me.
<infinity> shawarma: minimal^ and standard^
<infinity> shawarma: No derivative stem.
<shawarma> infinity: Garh... I'm so stupid.
<shawarma> infinity: feel free to quote me on that.
<infinity> Only when drunk, and you're paying.
<shawarma> infinity: indeed.
<Nafallo> pitti: firefox looks good in Swedish anyway, nothing jumps at me.
<infinity> pitti: Can we s/BonEcho/Firefox/ on the user agent string?  There are some painfully retarded websites that refuse to work with "unknown" user agents.
<seb128> Kamion: do you have anything to ~/.xsession-errors or any clear message about the issue on boot?
<seb128> that's weird we didn't get some bug reports about that, the package didn't change for weeks now
<seb128> there was an issue some time ago, I fixed it and people who replied on the bug confirmed it's fixed
<seb128> Kamion: does it happen every time?
<slomo> pitti: ping?
<Kamion> seb128: no, not every time - and as I say it's on the live CD so it could well be the dbus activation timeout thing that people were talking about above
<pitti> Nafallo: cheers
<pitti> slomo: pong
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/tmp/xsession-errors - nothing obvious
<pitti> Nafallo: changelog> well, I got sick of tracking all these CVEs in the manual db :)
<pitti> infinity: I'll look into it
<Kamion> (I've already started g-s-d by hand and started ubiquity)
<Nafallo> pitti: hehe, yea. thought so :-)
<slomo> pitti: saw that i managed to not change the dbus timeout? ;) any idea what else has fixed it for you? (and does the bcm43xx driver work for you with latest kernel? i always loose the connection to APs after some time...)
<Lure> mjg59: I cannot reproduce bug 60442, but I have prepared a test package - so if you can test it would be great
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
<pitti> slomo: dbus timeout> no idea, it just works now
<Kamion> seb128: also bug 66124 was filed just four days ago about this and you replied to it ...
<Ubugtu> Malone bug 66124 in control-center "gnome-settings-daemon crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66124
<Kamion> so it's obviously not fixed for everyone
<pitti> slomo: bcm43xx> works fine for me, but I didn't test it for longer than an hour or so
<pitti> slomo: but it's completely broken with network-manager
<elmo> my fonts consistently get mangled on upgrade
<seb128> Kamion: that one is clearly a different issue
<pygi> sivang: ping?
<Kamion> seb128: oh?
<elmo> from subpixel -> best shape
<elmo> who would that be a bug on?
<Kamion> seb128: oh, sorry, you're quite right
<seb128> Kamion: the previous crasher people have had "gstreamer init failed" message
<pitti> slomo: From what I have heard, wpasupplicant wrecks up the settings, and I don't even get an IP
<pitti> slomo: so I'm back at good ol' sudo ifup eth1
<seb128> s/have/had
<slomo> pitti: i loose the connection after < 5 minutes already but don't use NM at all
<pitti> slomo: anything helpful in dmesg?
<slomo> pitti: no... jsut the usual spamming by the bcm43xx module
<seb128> Kamion: would be nice to try with the extra delay for dbus first
<Kamion> mm, I'll see if I can try that out hand-hacked later
<seb128> Kamion: and debug it if the isssue is still there
<pitti> slomo: how come that the timeout isn't changed? I still remember the changelog
<pitti> Kamion: it's nontrivial to hack
<Nafallo> pitti: network-manager bailed out on my rt2500, wifi-radar works though :-). if you want something GUIsch that is :-).
<slomo> pitti: i patched upstream's session.conf but we have our own in debian/ and forgot about it
<pitti> Kamion: in my experiments I never managed to get the effect after logging out and back in - that was just too fast
<Kamion> pitti: I can hack it at boot
<Kamion> break=casper-bottom, mess around with ed
<pitti> ah, nice trick
<Kamion> you have to provide a script that edits the file, but shrug
<seb128> is apport running on the desktop CD?
<seb128> like a g-s-d crash would generate a crash log?
<Kamion> doesn't seem to
<Riddell> mjg59: has usplash changed on amd64?
<tfheen> Riddell: yes.
<tfheen> Riddell: it now works, unlike what it used to.
<Riddell> well that would be handy to know
<Riddell> what do I have to do to make it work in kubuntu?
<tfheen> provide proper (640x400 and 640x480) artwork.
<tfheen> 16 colours
<pitti> sfllaw: do you need help with amd64 testing? I can do some testing tomorrow morning
<Kamion> I'm slowly cranking my way through the amd64 DVD still
<ogra> hmm, gaim is funny as IRC client
<sivang> ogra: I couldn't never get used to it as an IRC client
<Riddell> Gloubiboulga: someone will have to add a 640 xubuntu usplash too, else it won't work on amd64
<seb128> lool: hi, yeah, you have some nice ideas. I think we will discuss that again at next summit. I'm busy with edgy at the moment but I would be happy to discuss that after edgy if you are interested. I think mvo is interested to the topic too
* sivang adds pitti 's firefo testing repo
<mvo> seb128: what topic was that?
<seb128> mvo: easy-codec-install
<mdz> sfllaw: how goes the testing?
<lamont> infinity: what did I do now??
<mvo> seb128: yeah, that is a nice one
<pitti> mdz: btw, I did the whole range of amd64/alternate tests with yesterday's images; the big bugs I noticed have been fixed
<mdz> pitti: thank you
<pitti> my machine is still busy with firefox, but I'll do some more amd64 tests tomorrow
* pitti just hopes that we won't need another image build
<mvo> how can I get the installer to present me the auto-resize option :/
<mvo> do we need more ubuntu testing? it would be a welcome break from edubuntu testing :)
<tfheen> mvo: the disk needs to be bigger than 6G
<tfheen> mvo: ubuntu i386 testing == good
<pygi> get mvo 
<pygi> hey*
<pygi> o joy, what a typo
<gnomefreak> seb128: you mean like amaroks easy install codecs?
<seb128> gnomefreak: what?
<gnomefreak> amarok installs codecs for you now :)
<seb128> gnomefreak: and?
<mvo> tfheen: my disk is 160G and I don't see it in ubiquity 
<seb128> gnomefreak: I don't use amarok and don't care about what it does
<mvo> hey pygi!
<gnomefreak> seb128: is that the same as what you mean?
<seb128> gnomefreak: no
<gnomefreak> oh ok
<seb128> gnomefreak: I mean you try to play a mp3 with totem and it open a dialog "you need to install gstreamer0.10-plugins-ugly"
<seb128> gnomefreak: with an "install" button
<gnomefreak> seb128: yeah thats what amarok does atm
<gnomefreak> it would be nice if it can be done with totem
<seb128> gnomefreak: how do they do the mapping package to install codec?
<seb128> gnomefreak: and is amarok running as admin or is there a daemon to install the package?
<gnomefreak> seb128: that i dont know thats a riddell question
<gnomefreak> seb128: daemon
<seb128> gnomefreak: that's stupid to have an app specific daemon
<seb128> gnomefreak: we should have something you can speak to over dbus or something like that
<gnomefreak> agreed
<seb128> gnomefreak: does amarok install the codec for the user or the package required or the codec out of the package systm?
* mvo got it now! auto-resize
<gnomefreak> out of package system iirc. the last time i played with it it kept running in a loop
<seb128> gnomefreak: ah, k, that's not what the spec is about, the spec is about determining what package is required and install it
<gnomefreak> ah
<seb128> we are not really interested to install codecs out of the packaging system :)
<gnomefreak> ah
<sfllaw> Kamion: You're looking at bug 59983.  EtienneG was wondering if this will make it for edgy.
<Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
<sfllaw> According to the report, it looks like the kernel interface changed.
<sfllaw> And he's already had a call about it.
<mdz> Kamion: I think we had the same idea: https://features.launchpad.net/distros/ubuntu/+spec/install-with-third-party-drivers and https://features.launchpad.net/distros/ubuntu/+spec/ubiquity-driver-updates
<Riddell> gnomefreak: hmm?
<gnomefreak> Riddell: we were talking about how amarok installs the codecs
<Riddell> gnomefreak, seb128: it runs /usr/lib/amarok/install-mp3
<Riddell> which installs libmad
<Riddell> there's no daemon
<seb128> Riddell: is that mp3 specific or does it do that with any codec?
<Riddell> seb128: it's mp3 only, amarok just reads this .desktop file for the script to run which is supplied by the packager /usr/share/services/amarok_xine-mp3_install.desktop
<seb128> Riddell: and does it install the package or a codec it downloads from somewhere?
<dieman> suck, wont be working with ubuntu a ton in my new job it sounds -- the emc software for the SAN requires SLES or RHEL. 
<Riddell> seb128: our install-mp3 runs kdesu adept to enable muliverse if needed and do apt-get install libmad0
<seb128> Riddell: ok, I see. gnomefreak said that amarok was already doing what the easy-codec-install specs wants to do, looks like it's a "light version" :) We want a mapping for any codec
<pygi> dieman: why is that?!
<dieman> pygi: its not 'certified' for ubuntu, etc.
<lool> seb128: fine
<seb128> Riddell: thank you for the details about it :)
<dieman> the SAN people here dislike not using certified platforms, etc.
<pygi> dieman: ok, help us get in contact with the providers of software, we'll certify
<dieman> i can't blame them, because its a support issue for them.
<tfheen> dieman: where you moving to?
<dieman> sticking here at umn in minneapolis
<dieman> moving to oit security and assurance
<dieman> doing network security work
<tfheen> oh, nice.
<dieman> yah
<Kamion> 01:31 < Kamion> mdz: I registered ubiquity-driver-updates before seeing install-with-third-party-drivers. Which should we keep?
<Kamion> 01:36 < Kamion> mdz: do I need to repropose ubiquity-advanced-partitioner for uds-mtv, or can we just carry it over? (I don't think it desperately needs further discussion)
<Kamion> 01:37 < Kamion> I suppose that means I'll have to actually think of other stuff I want to do for edgy+1 then, otherwise my slate is going to look artificially empty in MTV
<Kamion> mdz: yep, I'd noticed that too, shortly after registering u-d-u
<infinity> Kamion: If you already have a large amount of work (and thus no need to spec more for yourself), register a mess of LP specs, and sit in with the soyuz guys and I for distro/soyuz requirements.
<infinity> Kamion: Or register other random specs for cool stuff you hope you can pawn off on other assignees. :)
<Kamion> sfllaw: some total random assigned that bug to me without my consent; I know nothing about it
<sfllaw> Kamion: Ah.
<ajmitch> morning
<sfllaw> When people do that, can you toss it back to Nobody?
<ajmitch> wasabi_: pong (what was it about?)
<Kamion> sfllaw: yeah, I just did
* ajmitch needs that contentless ping script
<Kamion> it was only yesterday
<sfllaw> mdz: Bug 59983 looks like it could cause pain for our users.  The regression seems to be a bad one, but the fix involves a UVF exception.
<Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
<sfllaw> mdz: EtienneG just pointed out that he had a call about it.
<mdz> sfllaw: I have read that entire bug and I don't understand what the problem is
<tfheen> ajmitch: http://err.no/src/contentless_ping.pl
<Riddell> mdz, tfheen: I'm uploading a new kubuntu-default-settings to allow booting on amd64
<mdz> Riddell: bug#?
<pitti> there, firefox User-Agent string fixed
<Riddell> mdz: been to busy making the changes to report a bug yet :) hang on
<mdz> Riddell: so kubuntu/amd64 is completely broken?
<Riddell> mdz: you need to turn off usplash
<pitti> mdz: I fixed firefox' UserAgent: to be 'Firefox' instead of 'BonEcho' (to restore compatibility with some websites which check the string); I hope that's conformant with the branding agreement?
<mdz> pitti: please make it compatible with whatever dapper did
* Riddell files it as https://launchpad.net/distros/ubuntu/+source/kubuntu-default-settings/+bug/66815
<Ubugtu> Malone bug 66815 in kubuntu-default-settings "amd64 usplash boot broken" [Undecided,Unconfirmed]  
<pitti> mdz: alright
<ogra> Riddell: woah, thats evil ...
<mdz> Riddell: was this a regression caused by the most recent usplash changes?
<sfllaw> mdz: The bug is that you can't use ndiswrapper-utils to confiugre a proprietary network card.
<sfllaw> That makes it rough for users who don't have free cards in their computers.
<ogra> in edubuntu the splash is completely broken on amd64, but still boots fine
<mdz> sfllaw: that's the symptom. what's the problem?
<sfllaw> mdz: ndiswrapper.ko changed its interface.
<Riddell> mdz: yes, since nobody told me about the usplash changes I never knew to update it
<ogra> Riddell: it was mentioned loosely on teh last dev meeting
<sfllaw> Our ndiswrapper (1.1) doesn't know how to use the new module.
<sfllaw> Upstream's 1.8 reportedly does.
<sfllaw> EtienneG says he's going to verify that.
<tfheen> sfllaw: so we can just change the seeds to point to 1.8 for release, then.
<mdz> Riddell: why does that cause it to fail to boot?
<tfheen> fwiw, not having proper artwork doesn't make it blow up for me.  It just gives a garbled image.
<Riddell> mdz: it seems to freeze the computer shortly after X starts (presumably when usplash stops)
<Kamion> ugh, cdebconf-keystep doesn't line-wrap one of its questions - that's incredibly ugly
<ajmitch> tfheen: ta for the script
<EtienneG> sfllaw, I will confirm and post a comment in #12016 somewhen before midnight EST
<sfllaw> EtienneG: 12016?
<EtienneG> sfllaw, Sorry !  I am mixing bug/ticket number here ... :)
<sfllaw> tfheen: I'm confused but I presume you're not.  Are you saying you'll point the seeds to 1.8, which is living in?
<sfllaw> EtienneG: Please comment in Malone.
<EtienneG> that's really #59983
<EtienneG> sfllaw, yep, I guess that's better ! :)
<EtienneG> tfheen, my understanding is that ndiswrapper-utils bring in ndiswrapper-utils-1.1
<EtienneG> so just changing ndiswrapper-utils to bring in -1.8 should worked, if confirmed
<doko_> sfllaw: can we swap Ubuntu/Kubuntu testing for amd64 (already have the CD here)?
<sfllaw> doko_: Yes.
<doko_> sfllaw: ok, changing the wiki
<sfllaw> doko_: Thanks.
<mdz> Kamion: I replaced my spec with yours
<doko_> sfllaw: hrm, no, Kamion is testing amd64 Ubuntu, not me, so please keep it ;-) starting with the kubuntu CD's :)
<sfllaw> OK.
<tfheen> EtienneG: no, not changing the package.  Changing the seeds.
<Kamion> doko_: only DVDs
<sfllaw> kozz: Right.
<sfllaw> Desktop CD and Alternates.
<doko_> Kamion: seen
<mdz> sfllaw: I have version 1.8-0ubuntu2 installed
<mdz> but the source package in the archive is 1.1-5
<mdz> oh, it's gone weird
<mdz> the package names changed around
<Kamion> oh, I see - we need to build cdebconf-keystep with libtextwrap
<mdz> there's an ndiswrapper-utils in the archive, built from ndiswrapper-1.1
<mdz> then a bunch of newer stuff built from 'ndiswrapper'
<tfheen> mdz: that's an empty transitional package depending on ndiswrapper-utils-1.1
<mdz> tfheen: 'ndiswrapper' also builds an ndiswrapper-utils though
<mdz> which is not empty
<tfheen> mdz: yes, ndiswrapper-utils is the package I talked about.  It should be empty or just containing symlinks, I'd imagine.
<Riddell> doko_: if you're testing amd64 kubuntu keep in mind the usplash needs disabled
<ogra> Riddell: how does kdm stop usplash ? i dont see the initscript running DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start
<tfheen> the reason for this is to prevent upgrades to break people's networking because the ndiswrapper ABI changed and they didn't get a new kernel at the same time
<tfheen> (and now they can't because they have an old kernel and new ndiswrapper or the other way around)
<Riddell> ogra: there's nothing in kdm to stop usplash as far as I remember
<mdz> tfheen: what I don't understand is that I have two 'ndiswrapper-utils' packages in my apt cache
<ogra> Riddell: aha ... that might be your prob then
<mdz> tfheen: which contains only edgy
<tfheen> mdz: and you don't have it locally installed?
<sfllaw> There's a 1.8 in dapper.
<mdz> tfheen: I have it installed, but I wouldn't have manually installed it
<Riddell> ogra: so that'll be yet another usplash change I've not been told about, grump
<ogra> Riddell: look at gdm in debian/patches/15_usplash.patch
<mdz> it's as if the version number got smaller between dapper and edgy
<sfllaw> It did.
<doko_> Riddell: will do
<mdz> that's not supposed to happen
<sfllaw> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ndiswrapper-utils
<mdz> ndiswrapper-utils |     0.10-1 |         warty | i386
<mdz> ndiswrapper-utils | 0.12+1.0rc2-1 |         hoary | i386
<mdz> ndiswrapper-utils | 1.1-4ubuntu2 |        breezy | amd64, i386
<mdz> ndiswrapper-utils |      1.1-5 |          edgy | all
<mdz> ndiswrapper-utils | 1.8-0ubuntu2 |        dapper | amd64, i386
<mdz> cprov,malcc: ^^^
<tfheen> that's.. special.
* Nafallo growls @ gnome-screensaver
<mdz> so we just need to fix ndiswrapper-utils to depend on -1.8 rather than -1.1 it sounds like
<Nafallo> where are the manpages? :-P
<sfllaw> And up the version number.
<mdz> for good measure
<cprov> mdz: I'm checking
<sfllaw> I'll update the description for 59983.
<sfllaw> Done.
<infinity> cprov: Could it be that version constraints are only checked on source uploads, but not on binary uploads?
<infinity> cprov: Oh, or something more sinister at work...
<malcc> We seem to have two source packages (ndiswrapper vs ndiswrapper-1.1) both publishing ndiswrapper-utils binaries...?
<infinity> mdz: At a glance, I'd say that 'ndiswrapper-utils' was removed from edgy as NBS, then ndiswrapper-1.1 started building it with a lower version.
<malcc> Hmm, the version of ndiswrapper in edgy builds ndiswrapper-utils-1.8
<sfllaw> doko_: What did you decide to do?
<cprov> infinity: have you ran archive-cruft-check recently ?
<infinity> (Which still is no excuse for it not failing version constraints when it was cleared from the new queue)
<mdz> malcc: yes, we had some discussion about it before you /joined
<mdz> malcc: cprov should have a copy
<doko_> sfllaw: just testing the Kubuntu CDs/DVD
<sfllaw> OK.
<sfllaw> Thanks.
<sfllaw> I'll continue with AMD64 on Ubuntu.
<mdz> sfllaw: someone needs to confirm Riddell's bug
<mdz> if it breaks the boot everywhere, it's a problem for RC
<Kamion> cprov: I run a-c-c frequently, and its output was empty yesterday
<Kamion> in fact this morning too, I think
<Kamion> mdz: I checked for versions in edgy << dapper-updates, but looks like I need to check dapper too ...
<cprov> Kamion: good, was just curious about it, thanks
<mdz> Kamion: where do you check that?
<Kamion> cjwatson@drescher:~$ for component in main restricted universe multiverse; do for arch in amd64 i386 ia64 powerpc sparc; do echo "$component/$arch:"; ./suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/dapper/$component/binary-$arch/Packages.gz /srv/launchpad.net/ubuntu-archive/ubuntu/dists/edgy/$component/binary-$arch/Packages.gz gt; echo; done; done | less
* cprov needs to go
<Kamion> ndiswrapper-utils is the only offender for edgy << dapper
<Kamion> suite-diff.py is something I wrote way back shortly after I started working for Canonical; I no longer remember why ...
<Kamion> oh, I think it was to check for newer versions of packages in unstable than warty after UVF
<Kamion> there's also one instance of edgy << dapper-security at present
<mdz> sfllaw: ubuntu/i386 is still lacking confirmed tests as well
<Kamion> mvo: could you (get somebody to) update vmware-player-kernel-2.6.15 for our current kernel, please?
<sfllaw> I'm going to import some of cr3's results from Salesforce.
<Kamion> assuming we're allowed to
<sfllaw> mdz: Is there a DevelTeamMeeting this week?
<mdz> sfllaw: no, as posted to ubuntu-devel-announce
<tfheen> Kamion: should we even have vmware-player-kernel-2.6.15 in edgy?
<Kamion> vmware-player-kernel-modules: 2.6.15.10-10 > 2.6.15.10-6
<Kamion> vmware-player-kernel-source: 2.6.15.10-10 > 2.6.15.10-6
<sfllaw> OK.
<Kamion> tfheen: no, should be 2.6.17
<Kamion> but regardless, the versions of those binaries need to be higher
<sfllaw> Ah.  I see, it's cancelled on fridge, not disappeared like normal.
<tfheen> oh, the binaries doesn't have versioned package names.
<Kamion> which is correct for -source; less sure about -modules
<mdz> sfllaw: I see cr3 is also assigned all i386 DVD cases, but there supposedly isn't enough bandwidth to montreal for CDs, much less DVDs
<tfheen> I can do DVD ubuntu tests in the morning
<Kamion> tfheen: vmware-player-kernel-modules: 2.6.15.10-10 > 2.6.15.10-6
<Kamion> vmware-player-kernel-source: 2.6.15.10-10 > 2.6.15.10-6
<Kamion> oops
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/cdebconf-keystep.libtextwrap.diff
<Kamion> how does that look to you?
<Kamion> need to figure out how to test it
<tfheen> Kamion: it doesn't need to do anything to use libtextwrap?  Just make sure it's present?
<Kamion> it already has that code, AFAICT
<Kamion> which is why I didn't notice the problem earlier - it's all inside #define HAVE_LIBTEXTWRAP
<tfheen> oh, ok.
<Kamion> which is always defined in cdebconf so I assumed it would be in cdebconf-keystep too
<tfheen> I probably got that when I C&P-ed the code out of cdebconf.
<tfheen> yeah, looks good to me otherwise.
<Kamion> it's only 9 lines of #defined-out code in total
<tfheen> yeah, I'm not worried about that bit.
<malcc> Looks like ndiswrapper-utils-1.8 is left behind in universe where ndiswrapper-utils and ndiswrapper-utils-1.1 are in main
<sfllaw> tfheen: Thanks.
<Kamion> malcc: due to not being seeded
<malcc> So, I can't find anything wrong in Soyuz here, unless its whole approach to packages with chunks of version numbers in their names is on crack
<Kamion> malcc: we're talking solely about the ndiswrapper-utils binary package here, not the others
<cr3> mdz: do answer your concer about testing DVDs in the Montreal office, sfllaw has sneakered much of the DVD downloads into the office from home, so we should be able to rsync minor changes in the office
<sabdfl> malcc: evenin'
<malcc> sabdfl: Hi
<Kamion> malcc: the bug is that the ndiswrapper-utils binary package should not have been accepted into edgy when its version was << that in dapper
<tfheen> malcc: you need to never forget about a binary package that has existed in some distro you derive from and also disallow version number downgrades.
<Kamion> well, yes, there are weak and strong versions of this constraint
<tfheen> Kamion: I suspect dak is vulnerable to a similar problem as soyuz is, but I haven't verified it.
<Kamion> the weak version is to check just versions of binaries in other existing distroreleases, with an awareness of the order of distroreleases
<tfheen> I've just pondered with it as an (evil!) way to get rid of epochs.
<Kamion> the strong version is to remember all versions and never allow going backwards, as tfheen says
<Kamion> tfheen: what about epochs?
<tfheen> Kamion: if you're allowed to downgrade, you can get rid of epochs.
<Kamion> you have to arrange for an ftpmaster to remove the binary temporarily
<Kamion> I think eventually ftpmaster would notice :)
<tfheen> so if edgy-2 had a package, you got rid of it in edgy-1, you can reintroduce it in edgy without the epoch and close any bugs as "this was a package that wasn't in edgy-1".
<tfheen> yes, evil, wrong and all.
<Kamion> from the sounds of things, I think I need to get a version of my suite-diff hack into Soyuz sooner rather than later. :)
<Kamion> in case anyone gets any ideas
<Chipzz> I don't see how this can work
<Chipzz> if I have a package installed with an epoch
<Chipzz> I do not update
<Chipzz> you guys remove it
<Kamion> Chipzz: it wouldn't. that's the point
<Chipzz> you guys add it again
<Kamion> Chipzz: that's why it's evil
<Chipzz> I update
<Chipzz> it still wouldn't work
<tfheen> Chipzz: it wouldn't, but I could blame it as user error since you should have removed it when it wasn't supported.
<tfheen> well, 'night.
<Kamion> Chipzz: tfheen's pointing out a failing in the archive's current integrity checks. of course it has negative consequences on users ...
<Chipzz> tfheen: no, I just didn't update while it wasn't supported
<Chipzz> I never noticed that there was a period when it wasn't supporte
<Chipzz> d
<tfheen> Chipzz: you should have.
<Kamion> don't analyse it too hard
<tfheen> what Colin says.
<tfheen> anyway, I need sleep; there's an RC tomorrow.
<Chipzz> uhu :)
<malcc> Ok, I'm feeling a bit better that I didn't understand this now :)
<Chipzz> good night :)
<tfheen> need to be dapper, no, edgy tomorrow.
<Kamion> CAFFEINE
<Kamion> Chipzz: the above is why, by policy, version numbers never, ever go backwards
<Kamion> Chipzz: mostly, this is enforced technically; occasionally it still needs to be enforced socially; sometimes things slip through
<Kamion> malcc: it's actually much more important in some ways that version numbers never go backwards for binary packages than for source packages, because the reason why they mustn't go backwards is that if they do they won't get upgraded on users' systems, as Chipzz describes
<Chipzz> Kamion: uhu
<elmo> tfheen: dak is so not vulnerable to that - it does cross-suite version checking
<Kamion> for source packages we could theoretically get away with only uniqueness (although decreasing version numbers might break things like apt-src; I'm not sure about that) - but in practice it's much less confusing just to have the same constraint, especially considering that you have to go to some lengths to get source and binary versions to differ
<Kamion> elmo: it's vulnerable to it across removals within the same suite, surely?
<elmo> the only thing it's vulnerable to is the temporary removal trick, but if I ever saw anyone do that deliberately I would kick them out of the keyring faster than they could say banana hammock
<elmo> Kamion: not sure how you mean?  dak would have rejected an edgy upload of a package, even if it was new to edgy, if the version was << dapper
#ubuntu-devel 2006-10-19
<Kamion> elmo: I mean the temporary removal trick, as you say
<Kamion> edgy upload -> removed from edgy -> edgy upload with << version
<elmo> if the upload was >> dapper, it would succeed, yeah
<Kamion> so, speaking of ndiswrapper-utils as we were
<Kamion> +ndiswrapper (1.5-1ubuntu1) dapper; urgency=low
<Kamion> +
<Kamion> +  * Resynchronise with Debian.  (Totally me!)
<Kamion> +
<Kamion> + -- Scott James Remnant <scott@ubuntu.com>  Wed, 16 Nov 2005 23:39:48 +0000
<Kamion> that means presumably that ndiswrapper 1.5-1 existed in Debian at some point
<Kamion> ndiswrapper-utils |      1.1-5 |      unstable | all
<Kamion> elmo: fancy some archaeology? :)
<elmo> Kamion: no need, I remember this - dilinger did indeed do the temporary removal trick, but to my shame I allowed him to
<elmo> it didn't affect a released distro though or even testing, only unstable, and only for a matter of days, IIRC
<o_cee> ooh, finally f-spot got the new query stuff! maybe it will be useful after all
<Kamion> ah, but we were unlucky enough that it affected *our* released distro ...
<elmo> he had some relatively convincing reasons, but I forget exactly what they were - something to do with sane transitions from stable
<elmo> Kamion: doh
<elmo> oh my god, the conversation about why it was necessary is horrific
<bettsp> How do I compile a custom kernel in Edgy? KernelCustomBuild in the wiki seems out of date
<bettsp> I ask in dev, because it seems undocumented
<bettsp> (i.e. no one outside of the kernel team actually knows the correct answer)
<Kamion> the only thing that seems liable to be out of date there is the precise list of flavours (686/k7 -> generic)
<bettsp> Karnion: For example, "debian/rules updateconfigs" throws a "No rule to make target" error
<elmo> Kamion: http://people.ubuntu.com/~james/tmp/ndishell.txt, FWIW - I have no idea if that's interesting or relevant though
<elmo> (do we have a madison port for soyuz yet?)
<bettsp> The build command also fails with "No rule to make target"
<Kamion> elmo: no, just madison-lite installed on drescher
<Kamion> 'debian/rules build' is not allowed to fail; that's a policy-required target
<Kamion> bettsp: silly question, but did you cd into the correct directory?
<Kamion> updateconfigs is there
* Kamion <- not on the kernel team, BTW
<bettsp> Kamion: I assume I should be at /usr/src/linux-source-2.6.17, otherwise the paths would be off
<bettsp> I got the source via apt-get install linux-source and un-tar'ing it. Was that correct?
<Kamion> elmo: oh, dear god, that's extremely unfortunate
<Kamion> elmo: that tells me why an epoch won't help, at any rate
<bettsp> Kamion: Where did you get your kernel tree from?
<Kamion> I was looking at the source package. hold on, I'm checking the linux-source .deb
<mdz> Kamion: will you drain the ndiswrapper swamp?
<mdz> (post-RC)
<Kamion> bettsp: in order to use the debian/rules stuff as documented, you need to either use git or 'apt-get source linux-source-2.6.17'; looks like the linux-source-2.6.17 binary package isn't actually enough
<Kamion> DAMN
<Kamion> mdz: I'm not sure I'm up to this particular Herculean labour; still trying to get my head around it
<wasabi> ajmitch: Sorry. What's up with your focus on network-authentication? Anything? Going to make it to UMV?
<ajmitch> wasabi: yes I'll be there if I can organise somewhere to stay
<Nafallo> ajmitch: google should have some serverhalls, no? ;-)
<ajmitch> mmm, the sweet sound of servers to lull me to sleep
<Nafallo> :-)
<johanbr> And nothing beats the halon fire extinguishers as a wakeup alarm. 
<mvo_> ogra: still here? I got no edubuntu usplash artwork on the thin-client (amd64). known issue?
<Kamion> that's known, it was mentioned in the Edubuntu meeting earlier today
<mvo_> Kamion: thanks!
<Kamion> good, my cdebconf-keystep fix works, with some further tweaks
<Kamion> mdz: I'll try to confirm bug 66815 once I've done my last Ubuntu amd64 DVD test
<Ubugtu> Malone bug 66815 in kubuntu-default-settings "amd64 usplash boot broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66815
<mdz> Kamion: thanks
<ogra> hmm, missed mvo, seems he was also bitten by bug 66808
<Ubugtu> Malone bug 66808 in ltsp "first login on ltsp client fails due to missing gstreamer database" [High,Confirmed]  http://launchpad.net/bugs/66808
<Kamion> there's a kubuntu-default-settings fix in the unapproved queue, so we don't need Riddell to be around
<Kamion> (for this particular fix, anyway :-) )
* ogra reboots to normal ... gaim is way to weird for IRC
<mdz> Kamion: alternatively, we could rebuild just kubuntu/amd64 since it would need a second test anyway
<mdz> Kamion: we are able to do that now, yes?
<Kamion> since the breezy era, yes
<Kamion> what do you mean would need a second test anyway?
<Kamion> breezy> er, I think I mean dapper
<Kamion> the one after wherever we had the spec-sprint in the basement
* ogra gets some sleep
<mdz> Kamion: well, we can either test it to confirm his bug, or just apply the fix and test from there
<mdz> the only instance where we would forego the fix for RC would be if it works for most folks other than riddell
<Kamion> mdz: up to you; I'm a little over an hour away from being able to test
<Kamion> bug 66785 should be fixed for final IMHO; targetted
<Ubugtu> Malone bug 66785 in yaboot-installer "yaboot failed to install on resizing partitions" [High,Confirmed]  http://launchpad.net/bugs/66785
<Kamion> easy fix
<jdong> why is ext3 trying to punish me for torrenting 35GB today? :)
<whiprush> wasabi_: hey should we make an umbrella topic for our stuff or do you want to wait until mountain view?
<Burgwork> whiprush: you talking about ldap stuff?
<Burgwork> whiprush: ogra and guy named stelis were also interested?
<Burgwork> s/?//
<whiprush> were they?
<Burgwork> you in #edubuntu ?
<whiprush> no, joining
<ajmitch> hey whiprush 
<whiprush> hi ajmitch 
<bluefoxicy> keybuk.. is not here, damnit.
<ajmitch> whiprush: start speccing now, rather than later
<ajmitch> since they have to be approved for UDS discussion
<Burgwork> whiprush: I plan to work on something tongiht, provided ldap gives me more love
<whiprush> Burgwork: ajmitch: I'm up for a while, you guys want to just start a skeleton up now?
<ajmitch> I won't have a lot of time this afternoon, but I can give some input
<Burgwork> whiprush: start working. I am busy with ldap at work
<whiprush> heh
<whiprush> ok
<Burgwork> whiprush: it is the pain
<Burgwork> convinced my non-techy boss that NIS was a bad idea, mostly by lying through my teeth
<jdong> out of curiousity, has anyone tried ext4 yet?
<whiprush> Burgwork: not a lie, it is a bad idea.
<whiprush> you  just don't know why yet, heh
<Burgwork> whiprush: they use it in our other office
<Burgwork> whiprush: one major piece: openldap or FDS?
<whiprush> Burgwork: I'd be surprised if anyone doesn't choose FDS.
<Burgwork> whiprush: it needs some work
<whiprush> yes
<whiprush> Burgwork: doing it right vs. doing it right now is my opinion on that.
<ajmitch> it needs a hell of a lot of work
<wasabi_> whiprush: No, we should get started.
<Burgwork> ajmitch: one person, how many months?
<ajmitch> many
<wasabi_> Whenever you + I + whomever is available on IRC.
<wasabi_> (which is now for me actually)
<ajmitch> I can't give a good estimate
<whiprush> what do you guys think about moving to like, #ubuntu-ldap and getting a skeleton busted out tonite.
<wasabi_> Totally
<whiprush> Note: there's a huge "enterprise" thread on the forums with some good ideas.
<whiprush> ok, let's do it
<jonh_wendell> is there any chance gaim 2beta4 enter in edgy?
<ajmitch> very little chance
<ajmitch> basically none at this point, I'd say
<bluefoxicy> it's a Hobbsee
<Hobbsee> bluefoxicy: indeed.  *waves her long pointy stick of DOOM around*
<bluefoxicy> ..... you know, that draws far fewer comments to mind when a girl does it.
<Nafallo> :-)
<bluefoxicy> although if steve irwin did it it would be his long pointy stingray of doom
<Hobbsee> heh
<StevenK> Boo, hiss!
<Kamion> hmm, that's interesting, launchpad-integration seems to work fine on the Kubuntu desktop CD
<Kamion> wonder how it manages that given the apparently non-GNOME-specific breakage earlier
<Kamion> and given that the /proc/*/exe symlinks exhibit the same /filesystem.squashfs/* thing
<whiprush> tfheen: infinity: we've started https://launchpad.net/people/ubuntu-directory and #ubuntu-ldap for discussion on shaping up specs for MV.
<Kamion> mdz: re simplify-oem-installation, I've been thinking about merging oem-config into ubiquity; they might not actually be the same application, but they should share more code and probably be built from the same source
<Kamion> mdz: this would make it pretty trivial to e.g. suck the pretty timezone selector into oem-config
* Kamion disables the publisher cron jobs
<Kamion> publisher running by hand
<LaserJock> whiprush: shesh, a whole channel just for ldap?
<whiprush> LaserJock: people are pumped up to help, why not!
<ajmitch> LaserJock: of course
<ajmitch> LaserJock: 8 people there & we just created it
<LaserJock> well, in the Edubuntu meeting this morning at least 3 people said they were working on ldap specs :-)
<ajmitch> yes, which is what we have to clean up
<ajmitch> & I've heard of 3 different people wanting to fight with FDS packaging
<LaserJock> well, you guys can have it :-)
<sfllaw> Kamion: Is auto-resize not an option for ubiquity?
<Kamion> sfllaw: it is
<sfllaw> Kamion: Strange, I'm not offered it.
<Kamion> sfllaw: auto-resize cannot always be offered. If you put /var/log/partman somewhere I can see it, I can tell you why it's not being offered in this case.
<Kamion> sfllaw: the PC partition table sucks, so I just can't always do it
<Kamion> (seriously, the restrictions are insane)
<sfllaw> Is there any configuration where I can guarantee this?
<sfllaw> Also, not showing it at all is a pretty bad UI.
<Kamion> I disagree
<sfllaw> Because there will be installation instructions out there that will say "Choose auto-resize".
<Kamion> but it's not feasible to fix that at present, anyway
<sfllaw> I know.
<Kamion> (even after edgy)
<Kamion> grr, kded medianotifier still pops up
<Kamion> guarantee> >=6GB disk, immediately after a fresh "erase disk" installation
<Kamion> those installation instructions should say "choose auto-resize, if available" and go on to describe what to do if it isn't
<Kamion> they have to do that anyway
<sfllaw> Kamion: I'd prefer to have it discoverable as to why you can't choose auto-resize.  But it's only a minor problem.
<Kamion> showing the option greyed out isn't going to help users reading installation instructions that don't describe what to do if the option isn't available
<Kamion> I agree it should be more discoverable, if only so I don't keep having to read partman logs to diagnose it :)
<Kamion> although once or twice reading those partman logs has uncovered genuine bugs in the auto-resize logic
<Kamion> so I am always interested to see them
<sfllaw> Greyed out with something like "Do foo to manually resize your partitions.  [Details...] "
<sfllaw> Maybe?
<sfllaw> With Details being what's in partman?
<Kamion> "do foo" is in fact going to be "delete some of your partitions" in some cases
<Kamion> if, for example, you already have four primary partitions
<Kamion> the cases where we cannot auto-resize are basically (a) four primary partitions (b) three primary partitions and no extended partition (partman-auto always wants /boot to be on a primary partition) (c) only resizable partitions are separated from the extended partition by a primary partition (d) no partitions we know how to resize (e) not enough room on any partitions we know how to resize
<Kamion> oh and (f) already enough free space on disk
<Kamion> free = unpartitioned
<sfllaw> You need unpartitioned space?
<sfllaw> Not just free space?
<sfllaw> That's sort of brutal.
<Kamion> I think you misunderstand me
<Kamion> if there's already enough unpartitioned space on the disk, then there is no point auto-resizing; you might as well just create a partition in the unpartitioned space
<Kamion> that's case (f)
<sfllaw> Ah.
<sfllaw> Why wouldn't you make auto-resize do the Right Thing?
<sfllaw> Which is not resize anything?
<Kamion> because there's already an option on the menu to do that
<Kamion> labelled "use continuous free space" or some such
<Kamion> I don't like duplicate options
<Kamion> and calling it "resize ... and use free space" would be confusing to say the least if it wasn't resizing anything
<sfllaw> I'd prefer calling it "Co-exist with another operating system" or something to that effect.
<sfllaw> Just a Do the Right Thing for a dual-boot setup.
<Kamion> see UbuntuExpress/Partitioning
<Kamion> that has a UI redesign that I'll get round to eventually :)
<Kamion> sorry, UbuntuExpress/PartitioningTool
<Kamion> the whole thing is exacerbated by partman-auto's inability to reuse an existing swap partition; fixing that would probably be more helpful to auto-resize than all the rest combined
<sfllaw> es.
<sfllaw> Yes.
<sfllaw> That spec seems pretty reasonable, but the "you'll need to decide how much space" option is a bit funky.
<sfllaw> Sharing free space might be a good plan.
<Kamion> "sharing free space"?
<sfllaw> Presume an Ubuntu install takes up 2-3 GB of space.
<sfllaw> Then split the free space evenly.
<sfllaw> We can tell how much free space is on other partitions, right?
<Kamion> yes, but I strongly believe we need to offer that option
<sfllaw> We should probably offer the option.
<Kamion> it needs to have a good default, but it needs to be offered
<sfllaw> Then perhaps the warning is unnecessary.
<sfllaw> It sounds scary.
<Kamion> resizing SHOULD BE SCARY
<Kamion> :-)
<sfllaw> You don't make the resizing sound scary.
<sfllaw> You make the free space allocation sound scary.
<sfllaw> :/
<Kamion> what scary warning exactly are you talking about?
<sfllaw> (*) Put Ubuntu alongside, so you choose a system on each startup
<sfllaw>     If you choose this option, you'll need to decide how much space
<sfllaw>     should be reserved for each system.
<sfllaw> Needing to decide is bad.
<Kamion> oh, sure, don't care about the exact text there
<Kamion> "The implementor should feel free to decide on the exact text used in the following dialogs, in consultation with usability experts. Decisions may be influenced by translated text already available elsewhere."
<Kamion> I think that was mpt's text
<Kamion> removed from the spec now, thanks
<Kamion> though, while the automatic partitioner remains a bit quirky, I think the manual partitioner is a much worse wart right now
<sfllaw> Kamion: Is ubiquity supposed to exit with code 10?
<Kamion> not in general ...
<Kamion> I doubt ubiquity did, but one of its subprocesses might have done?
<Kamion> crash dialog?
<sfllaw> No, sorry.
<mpt> I have yet to actually see Ubiquity in action, except in screenshots in magazines
<sfllaw> ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/bin/partman-commit']  exited with code 10
<sfllaw> And then it disappeared.
<Kamion> sfllaw: that much is normal
<Kamion> the log entry, I mean
<Kamion> sfllaw: can I have the full log please?
<sfllaw> Yeah.
<sfllaw> syslog, right?
<Kamion> (If you're doing manual partitioning, the start of partman-commit is run to get the partitioning summary. We back up out of it (exit code 10) to avoid actually committing the changes.)
<Kamion> sfllaw: /var/log/syslog, yes. Maybe /var/log/partman too.
<mpt> sfllaw, I wrote that text late at night about four years ago, which hopefully explains why it's not as polished as it could be :-)
<sfllaw> You gotta watch out what to do with specs.
<Kamion> mpt: btw, I'm going to have to take the partitioning progress bar back out of the main installation progress bar in feisty
<Kamion> mpt: because if the migration-assistance spec comes to fruition, that needs to be slotted in after partitioning, in order to know what it's migrating from
<mpt> That doesn't reeeeeeally make sense, because migration-assistance should work even if I'm nuking the Windows partition (e.g. by burning a CD)
<mpt> I guess the first stage of migration-assistance assumes the Windows partition is still there?
<Kamion> "by burning a CD"> what do you mean?
<Kamion> migration-assistant has to have the Windows partition mounted, which is hairier than you might think if partitioning hasn't been done yet
<sfllaw> Kamion: Sent.
<mpt> a CD containing the files you want to migrate
<Kamion> mpt: not remotely in the plan for migration-assistant at present
<Kamion> it migrates by copying to the new partition. orders of magnitude simpler
<Kamion> IMO most people wanting a simple migration assistant will want to run both systems in parallel for a bit anyway in case it fails
<mpt> of course, and orders of magnitude less useful :-)
<Kamion> so I'm not too concerned about the "nuking the Windows partition" use case
<mpt> If I'm dual-booting I don't want copies of stuff that gradually get out of sync with each other, I just want easy access to the Windows partition
<mpt> ho hum
<sfllaw> OK.  Rebooting this box to try something else.
<Kamion> mpt: you want the first boot of the Ubuntu side to come up with familiar settings
<Kamion> FSVO "you"
<Kamion> Evan's current stuff lets you choose what to copy, anyway
<mpt> ok, so
<mpt> 1. choose how you want to partition
<mpt> 2. if you chose to dual-boot, ask what stuff you want to migrate
<mpt> 3. actually do the partitioning
<mpt> 4+5. actually do the migration and the software installation
<Kamion> 2. involves mounting partitions in order to find out what's there
<Kamion> I've thought about that quite hard
<mpt> If you're going to shrink an existing partition you need to be able to mount it anyway, right?
<Kamion> I'm not really happy with the complexity involved in mounting the partitions that aren't going to be removed, unmounting them again, doing the partitioning, mounting them again, migrating
<Kamion> mpt: parted doesn't mount partitions in order to resize them
<Kamion> it's more the hideous bookkeeping involved
<mpt> well, ok, I don't pay your salary :-)
<mpt> I'll just say, "that's a shame".
<Kamion> mpt: do you acknowledge that there's such a thing as a first cut? :-)
<Kamion> we can drop in complexity later, but the first iteration needs to work reliably, first and foremost
<unfo> hi all, ubiquity crashed installing 6.06. My case is unusual: I chose French and I set it to mount my FreeBSD partition at startup. 
<unfo> I got these errors in the log: "ubiquity: /bin/partman exited with code 1", "RuntimeError: called outside of a mainloop" at gtkui.py", line 1169, in watch_debconf_fd_helper, and more.
<unfo>  Is this a known bug? Would anyone like to ssh in as root to debug?
<mpt> Kamion, sure, I thought Dapper was the first cut :-)
<Kamion> unfo: please file a bug with a cut-and-paste of the crash dump
<Kamion> mpt: not of either the new advanced partitioner nor of the migration assistant, it wasn't
<Kamion> unfo: also please attach /var/log/installer/syslog, /var/log/syslog, and /var/log/partman
<mpt> ok.
<Kamion> (you can attach files via the comment interface after filing the bug)
<unfo> Kamion: is there a way to file bugs and include attachments by email?
<Kamion> unfo: no.
<Kamion> the bug tracking system can't manage that, I'm afraid :( it's a known bug
<Kamion> unfo: FWIW I believe your bug is fixed in Edgy, but I want the crash dump to be sure
<Burgwork> Kamion, mpt: can you put your thoughts on the m-a spec page?
<mpt> bug 30225
<Ubugtu> Malone bug 30225 in malone "Attach files via email" [High,Confirmed]  http://launchpad.net/bugs/30225
<Kamion> Burgwork: I've already been in extensive contact with the primary m-a developer
<Burgwork> Kamion: ok, no worries
<Kamion> Burgwork: he was my Google Summer of Code student
<Burgwork> yep
<Burgwork> and he is now my employee
<Kamion> ah yes
<Burgwork> anyway, I need to leave work, as it is 9pm
<Kamion> mpt: burning a CD seems like a useful future wishlist, although rather limited :)
<mpt> and he's sponsored for UDS, iirc
<Kamion> yeah, I'm keen to talk to him there
<mpt> Kamion, yeah, or DVD, or hard disk, or iPod, or whatever :-P
<Burgwork> still browbeating work into giving me the time off
<Burgwork> sadly
* Kamion wonders how this would cope with e.g. his parents' large stash of edited holiday videos
<Kamion> "please insert DVD-R 1 of 17"
<mpt> Incremental partition resizing!
* mpt flees
<Kamion> haha
<Nafallo> lol
<Kamion> actually they're only using about half the disk, so it's much easier to just create another big partition with all the data and copy it over, and let them delete it from the Windows side when they're comfortable ...
<Kamion> (well, assuming hypothetically that there was video editing software on Ubuntu that they wanted to use; I haven't tried finding anything for them yet)
<mpt> "Copied 5.8 GB of 60 GB ... Now resizing partition for the 12th time"
<Kamion> the worst bit about that is that it would also require moving the start of the Ubuntu partition
<Kamion> I suppose that's marginally less hair-raising if you haven't installed a boot block yet
<Kamion> wow, awful qtparted message
<Kamion> "You're commiting all changes. Warning, you can lost data! Make sure also that you're not commiting a busy device... In other word PLEASE UMOUNT ALL PARTITIONS before commiting changes!"
<Kamion> (sic)
<Kamion> oh and that's followed by "Yes" and "No" buttons
<mpt> adding inefficiency to injury
<mpt> I count six spelling errors in that string. Anyone get more?
<Kamion> I count UMOUNT as jargon rather than a spelling error, but yes
<mpt> These geeks who don't know English ... it's "dismount", not "unmount", sheesh
<Kamion> (not defending the use of that piece of jargon there)
<Kamion> what, "please get off all your partitions before committing changes"? you're barking. :)
<Kamion> the correct analogy is unmounting a deer's head from your wall
<mpt> Oh, *I'm* mad and the people who use "unmount" in user-facing strings aren't? :-)
<Kamion> dismount is clearly wrong here. :)
* mpt wonders if umount and creat have the same provenance
<Kamion> yes
<unfo> Kamion: done. https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/66859
<Ubugtu> Malone bug 66859 in ubiquity "crashes w/ errors "partman exited with code 10", "RuntimeError: called outside of a mainloop at gtkui.py:1169 in watch_debconf_fd_helper, and more" [Undecided,Unconfirmed]  
<Kamion> in any case, the message above shouldn't appear at all; qtparted can easily determine that no partitions are mounted
<unfo> (note: "ubiquity: /bin/partman exited with code 10" only appears in the log, not onscreen.)
<Kamion> unfo: thanks. replied
<Kamion> unfo: you should also use 6.06.1 in preference to 6.06 if you have the option; the installer is much more stable
<unfo> Kamion: thanks for the quick reply. i will try to hit back and forward slower so as to avoid triggering it. :-)
<mpt> Burgwork, done
<Burgwork> mpt: thanks
<unfo> I remember the dynamic update feature in the, IIRC, Windows 2003 CPP installer that ran at the beginning of the installer. I wonder how hard it'd be to hack such a thing into the Ubuntu liveCD.
<unfo> *Windows 2003 Server
<Kamion> unfo: sucks, I know, sorry
<Kamion> unfo: if you mean something to update the installer on the fly before really running it, mvo had a go at that a while back - I keep meaning to look at it and try to merge it
<unfo> Kamion: dont feel bad, its an excellent installer in general, and is full of nice features like gtparted. crashes happen to people occasionally - thats life.
<unfo> Kamion: yes thats what i meant.
<fabbione> morning
* Kamion untangles sfllaw's crash, I think
<Nafallo> hi fabbione :-)
<sfllaw> It doesn't even look like a normal crash.
<fabbione> Kamion: have you been up all night??!?!??!?!?
<Kamion> fabbione: yes
* fabbione hugs Kamion 
<Kamion> my stepson has a fever too, so somebody being awake is no bad thing
<sfllaw> That's why I'm awake.
<sfllaw> Fever.
* fabbione has a cold too
<sfllaw> We are all going to be super ill after this.
<Nafallo> man... I should just take over all your duties and send you guys to bed or something :-P
* Kamion rebuilds the Kubuntu amd64 livefss
<Kamion> s/s$//
<ajmitch> sfllaw: that's promising for UDS
<Kamion> DEATH PLAGUE
<Kamion> sfllaw: ok, kubuntu amd64 rebuilding for bug 66815. I hope that's the only showstopper
<Ubugtu> Malone bug 66815 in kubuntu-default-settings "amd64 usplash boot broken" [Undecided,Confirmed]  http://launchpad.net/bugs/66815
<Nafallo> hmm. the reverted edgy artwork is available as a package in the archive like the rest of the suggestions I hope?
<Kamion> sfllaw: (as before, I'll carry over other architectures)
<fabbione> neuralis: ping?
<sfllaw> Kamion: Showstoppers are no fun.
<tonyyarusso> Hi, I finally got around to formally writing up a spec (my first), and am looking for feedback on the writeup to see if I'm doing it right.  (And, if you like it, looking for people to subscribe to & develop, since I only have ideas, not coding skills unfortunately.)
<tonyyarusso> It's at https://features.launchpad.net/distros/ubuntu/+spec/gaim-calendar-auto-aways
<Nafallo> kewl idea
<unfo> all: will the migration assistant migrate over a user's wallpaper from Windows?
<tonyyarusso> I've just had someone suggest it might have some crossover with the work on Telepathy - anyone know if this is true / the extent of it?
<unfo> also, how about their email POP3 server settings from Outlook Express?
<Nafallo> unfo: don't forget to take them from thunderbird as well then ;-)
<unfo> Nafallo: I wonder, if you did a random survey of 100 users who were about to install ubuntu: would there really be more thunderbird users than OE users? a lot of people install Ubuntu for others, not just for themselves. :-)
<BHSPitLappy> heh
<BHSPitLappy> true that.
<unfo> also, I wonder if it'd be practical to support something like the Windows XP Files and Settings Transfer Wizard so that we can pull people's settings off their PCs and onto a blank CD, then migrate them over to Ubuntu when they buy a new computer.
<unfo> that way you can migrate settings from an old XP box to a new PC.
<Nafallo> unfo: I migrated my mother to thunderbird and firefox last time I was there and she complained :-)
<Nafallo> complained about the shit ms gave her that is... ;-)
<BHSPitLappy> would it be legal to migrate some of their native dll's, etc to a wine installation, as an option?
<BHSPitLappy> Nafallo, many months ago, XP just stopped wanting to boot on my mom's PC (got messed up somehow), and my fix was installing dapper ;)
<Nafallo> :-)
<BHSPitLappy> so my mom's (and also just the family's) computer ran ubuntu exclusively for a long time
<BHSPitLappy> now she got a new laptop to replace it, but I have it dual-booting
<BHSPitLappy> and today, I caught her in ubuntu :D
<Nafallo> I think I might have a better chance to migrate them now that they actually run open source and sees that it "just works" :-)
<Nafallo> my father already talked quite a bit about it with me :-)
<Kamion> BHSPitLappy: that is to some extent addressed in the existing MigrationAssistance specification (search for wine)
<BHSPitLappy> k
<Kamion> not legality, but whether it's a good idea (spyware vectors, etc.)
<BHSPitLappy> Nafallo, yeah, my dad's oblivious to anything OSS related... oh well
<unfo> wine migration sounds pretty advanced. would most people really need that?
<Nafallo> Kamion: btw, have you planned to sleep anything until release? :-)
<Kamion> Nafallo: maybe
<BHSPitLappy> people that are iffy about losing some of their windows programs might.
<Kamion> do bear in mind please that automatic migration assistance in the installer cannot do everything
* Nafallo hands Kamion some coffe
<Kamion> if you massively overload it with requirements and features, then its UI will end up too big and complex to be usable
<tonyyarusso> Also, I'm not sure whether I should designate myself as the Drafter for the above, or if it's more appropriate for that to be someone more experienced - thoughts?
<Kamion> tonyyarusso: specifications should generally be drafted either by somebody with sufficient technical knowledge to write it all down themselves, or by somebody who's at a meeting with people who have the technical knowledge and is acting as a secretary
<unfo> Kamion: IMO, wallpaper, at least, is important. Where I worked, some users liked to use their own wallpaper - it made them feel like their computer was their own.
<unfo> :)
<Kamion> unfo: yes, that's been suggested on https://wiki.ubuntu.com/MigrationAssistance
<tonyyarusso> Kamion: Okay.  Any thoughts on the initial draft linked above so I can minimize confusion for them, whoever they may end up being?
<Kamion> Kubuntu alternate rebuilt for new kubuntu-default-settings
<Kamion> Kubuntu desktop and DVD building
<Kamion> tonyyarusso: you need to get somebody with knowledge of gaim to assess feasibility and generally comment on it before anything else
<Kamion> feature suggestions are generally best transmuted into specifications by people who know about the software, IME
<Nafallo> tonyyarusso: seb128 is the maintainer, so that might be a good try :-)
<tonyyarusso> Kamion: How do I find them?  -devel mailing list?
<tonyyarusso> Nafallo: Ah, thanks.
<Kamion> mailing lists, looking through changelogs to find out who's involved, searching for IRC channels devoted to the software in question, etc.
<tonyyarusso> Nafallo: Um, actually, how do I contact them?  Apt-cache just lists the devel mailing list under maintainer.
<tonyyarusso> Kamion: Okay
<Nafallo> tonyyarusso: what Kamion said :-)
<Kamion> I'd greatly appreciate it if anyone who can could test Kubuntu desktop and/or alternate 20061019 images to make sure that (a) usplash shows up properly and (b) there aren't any other obvious regressions
<Kamion> I'm rsyncing it, but I need sleep first
<keescook> Kamion: I was just testing the prior DVD release.
<keescook> I'll grab the next one and give it a shot (usplash was busted in prior)
<Kamion> right, that was the problem - my monitor went out of range, which is unusual for a usplash failure (normally it's just a blank screen)
<keescook> oh! that's different.  I just had the wrong colors.
<Kamion> ah, so there were some variations in the symptoms after all
<keescook> any idea where things stand for bcm43xx firmware?
<abattoir> Kamion: testing it on qemu is ok?
<Kamion> Riddell said "failed to boot" which I think may have actually meant "wasn't patient enough" :)
<Kamion> abattoir: can qemu do amd64?
<abattoir> Kamion: hmm no
<Kamion> keescook: blocked on permission from Broadcom's legal staff
<keescook> dang, okay
<Kamion> AIUI our enquiries have gone unanswered
<Kamion> keescook: new amd64 DVD build is up now
<abattoir> Kamion: i can test the alternate cd a bit later in the day, if that's ok
<Kamion> (Kubuntu)
<Kamion> abattoir: sure, release was ETA about ten hours from now last I heard
<keescook> Kamion: cool, I will snag it
<Kamion> should rsync fairly painlessly
<abattoir> Kamion: ok, will do then :)
<Kamion> ok, I've updated the Testing/Current matrix; bed
<keescook> bug 33762
<Ubugtu> Malone bug 33762 in xorg-driver-synaptics "Appletouch trackpad unbearably slow" [Medium,Confirmed]  http://launchpad.net/bugs/33762
<tonyyarusso> Where would I find changelogs?
<tonyyarusso> nm, just found it.
<pitti> Good morning
<keescook> morning pitti
* StevenK waves to pitti
<pitti> hey guys!
<imbrandon> moins pitti
<Nafallo> hi pitti :-)
<lucas> hi
<lucas> I did a rebuild of edgy on i386 to track FTBFS problems.
<lucas> does ubuntu has something similar to Packages-arch-specific ?
<lucas> (that is, a file listing the architectures a packages should be/shouldn't be built on ?)
<minghua> lucas's Grid5000 seems quite handy :-)
<lucas> yup
<lucas> sorry to come up this late in the edgy release cycle btw
<robitaille> pitti:  installed your firefox rc3.  According to the about firefox window, it is the 20060601 version of Gecko.  Is that correct?  Sounds pretty old
<Lure> mjg59, mdz: for bug 60442 we may need to stay with workaround
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
<carlos> pitti: ping
<mdke> Kamion: awake already?
<fabbione> mdke: he just went to sleep
<mdke> holy shit
<mdke> fabbione: thanks
<tfheen> rodarvus: 09:00 <@pej> dpkg: error processing /var/cache/apt/archives/x11-common_1%3a7.1.1ubuntu5_amd64.deb (--unpack): trying to overwrite `/usr/share/man/man5/Xsession.5.gz', which is also in package xinit
<pitti> carlos: pong
<pitti> robitaille: no idea, maybe that's the date of the last ABI change or so
<carlos> pitti: I did a mistake yesterday night and latest Edgy export has the plural form bug (bug #2322)
<Ubugtu> Malone bug 2322 in rosetta "Truncated plural forms" [Critical,In progress]  http://launchpad.net/bugs/2322
<carlos> pitti: I'm exporting a new version with that fixed, but it would take around 2-3 hours
<carlos> am I late to have it in the prerelease version?
<pitti> carlos: ah, then I'll rebuild the edgy packs this afternoon
<pitti> carlos: it won't go into RC anyway
<carlos> ok
<pitti> carlos: the plan is to upload the final packs tomorrow morning
<pitti> carlos: thus I'd like to have today's in perfect shape
<carlos> I see
<carlos> ok
<carlos> pitti: I will ping you when the new version is available
<pitti> carlos: thanks! (and nice to see that bug getting fixed)
<HiddenWolf> (k)
<HiddenWolf> ick
<pitti> carlos: any chance to clean up https://launchpad.net/rosetta/imports?target=all&status=NEEDS_REVIEW&type=pot a little?
<carlos> HiddenWolf: ;-)
<robitaille> pitti: if you download firefox 2rc3 from mozilla.org, in the about window you get a Gecko date of 20061010.  So it's something specific to the ubuntu built
<pitti> carlos: ah, what is the usual Rosetta turnaround time? i. e. if I add a string to Rosetta now, when will it appear in your exported tarballs?
<carlos> pitti: I will take a look, but most of those aren't part of language packs
<carlos> pitti: tomorrow morning
<pitti> robitaille: hm, no idea; I did download the official source and applied our patches
<pitti> carlos: ah, nice
<carlos> pitti: the mirror is done after midnight (London time)
<pitti> carlos: ah, good
<carlos> pitti: and the export process is done after the mirror is done
<pitti> robitaille: hmm, curious
<robitaille> pitti:  another thing:  if you click on "get help online", you end up in the dapper section of LP for firefox
<tonyyarusso> I announced a feature specification proposal involving gaim, telepathy, and e-mail/calendar clients earlier, but a number of new people have joined since then; is it customary to repeat things like that occasionally in here?
<pitti> robitaille: ah, good catch!
<tonyyarusso> seb128: I was told you maintain gaim, and so might be a good person to give feedback on overall feasibility.
<seb128> tonyyarusso: did you register a spec about it?
<tfheen> tonyyarusso: no, we're in the middle of releasing a release candidate, so trying to draw people's attention to anything but the release at hand is frowned upon.
<tonyyarusso> seb128: Yes.  (https://features.launchpad.net/distros/ubuntu/+spec/gaim-calendar-auto-aways)
<tonyyarusso> tfheen: Ah, I see, so maybe bringing it up more in a couple of weeks would be better?
<tonyyarusso> (Already sent an e-mail to the list...I guess just ignore that until after the 28th :) )
<seb128> tonyyarusso: nice spec, I doubt we work on it though
<tfheen> tonyyarusso: yes, in > 1 week you can discuss it as much as you like for what I care. :-)  But not now.
<tfheen> hello Hobbsee 
<tonyyarusso> seb128: Do you mean now, or work on it at all?
<seb128> tonyyarusso: any time soon
<tonyyarusso> tfheen: Okay.
<pitti> robitaille: right, this is easily fixed, doing now
<tonyyarusso> seb128: All right.  Well, maybe I'll get lucky and someone will take interest later.
<Hobbsee> hey tfheen!
<seb128> tonyyarusso: it's a corner feature request, we have zillion of things we are likely to be wanting to do before hacking on that
* Hobbsee wonders when tfheen will become Mithrandir again.
<tfheen> Hobbsee: soon, I hope.  I need to set up a bit of thingabobing to make IRC work from the old machine.
<seb128> hum
<Hobbsee> tfheen: ahhhhh
<seb128> is rsync server supposed to work?
<robitaille> pitti:  everything looks fine; been trying that firefox for my usual surfing tonight, and I didn't see any other obvious problems 
<tfheen> hng, I rsynced the wrong ISO
<Hobbsee> tfheen: where are our current RC iso's?  not rsyncs?
<tfheen> seb128: rsync works fine for me, at least.
<seb128> grumpf
<pitti> robitaille: cool! that makes it six success stories and no reported regressions so far
<seb128> "rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<seb128> rsync error: error in rsync protocol data stream (code 12) at io.c(463) [receiver=2.6.8] 
<seb128> "
<tfheen> Hobbsee: https://wiki.ubuntu.com/Testing/Current has the versions, cdimage.u.c has the images, as usual.
<fabbione> seb128: how many parallel sessions are you running?
<tfheen> seb128: you can't do more than one rsync at a time.
<seb128> I've none running
<tfheen> might need it to time out, then.
<fabbione> seb128: then it's probably a previous session hanging.. it doesn't take long to timeout
<seb128> k
<fabbione> seb128: otherwise tell me what ISO you need and i can put it somewhere rsyncable for you
<seb128> if somebody wants to take edubuntu DVD amd64 I don't have the bandwith to download it (it's going to take like 10 hours to download)
<seb128> fabbione: let's wait a few min, I'm trying to continue on the i386 edubuntu DVD
<fabbione> oh DVD.. ok
<tfheen> seb128: I'll trade you kubuntu-alternate for it?
<seb128> I started yesterday but it stopped in the middle of the night :/
<seb128> tfheen: works for me, kubuntu-alternate on what arch? amd64?
<tfheen> seb128: i386
<seb128> ok
<seb128> thank you
<Hobbsee> tfheen: thanks a lot
* tfheen hugs the local 40Mbit
<fabbione> tfheen: this time i beat you.. got access to a fast machine on real gigabit :)
<tfheen> fabbione: this is the box I'm sitting on.
<tfheen> fabbione: I have access to boxes on gbit too, but those are 500kms away, so useless for burning DVDs.
<fabbione> right.. well.. DVD's suck anyway :)
<tfheen> you'd prefer if we released blu-ray images?
<fabbione> yeah
* ogra still wants to see a DLT release 
<minghua> Does anyone know why http://cdimage.ubuntu.com/daily-live/current/MD5SUMS only has the powerpc one?
<fabbione> minghua: sorry i am still calculating manually the others.. it might take a while to parse 1.4GB of data manually...
<fabbione> like a few years
<minghua> :-)
<cbx33> ping seb128 
<tfheen> minghua: probably because only powerpc was rebuilt.
<tfheen> minghua: we'll fix it up for the RC.
<minghua> tfheen: thanks
<tonyyarusso> ogra: What's DLT?
<ogra> tonyyarusso, http://www.dlttape.com/products/media/DLTtapeS4/index.aspx
<ogra> blue-ray disks ... tsk ...
<Spads> no
<Spads> blu-ray!
<Spads> haha
<carlos> mdke: ping
* pitti wonders what the difference between the 'motu' and 'ubuntu-dev' team is
<Hobbsee> pitti: MOTU is depreciated
<pitti> Hobbsee: ah, I see
<Hobbsee> pitti: also, u-u-s has made MOTU depreciated too, but it seems that people assign things to MOTU out of habit.  *shrug*
<mdz> morning
<ajmitch> because assigning/subscribing 'motu' gets them on the universe-bugs list
<pitti> hey mdz
<ajmitch> since we haven't managed to mass-set bug contacts for universe packages
<ajmitch> hi mdz, pitti :)
<fabbione> morning mdz
<Hobbsee> ajmitch: ahh
<tfheen> mdz: Kamion noticed that we completely forgot about ReleaseChecklist, so I'm going through that now.
<mdz> tfheen: i mentioned base-files/lsb-release last night; was my client disconnected at the time?
<mdz> xchat isn't very good about informing one of that situation
<mdz> tfheen: please merge ReleaseChecklist into ReleaseCandidateProcess
<tfheen> mdz: I'll do that once the RC is out.
<tfheen> it needs to go into ReleaseProcess too.
<tfheen> (or at least, I'd like us to have the checks there too)
<tfheen> I can't see base-files mentioned in lastlog at least.
<tfheen> anyway, fixed version uploaded now.
<mdz> Oct 18 23:49:22 <mdz_>  tfheen: eek, we forgot to update base-files, lsb-release etc.
<mdz> Oct 18 23:49:44 <mdz_>  tfheen: that needs to go in the process doc
<mdz> Oct 18 23:49:53 <mdz_>  I need to dash to get the tube back to the hotel, will be back on from there
<mdz> Oct 19 00:11:23 *       Disconnected ().
<mdz> guess i wasn't connected
<mdz> tfheen: I don't think it's necessary to rebuild RC for those
<tfheen> agreed, but they should go into release.
<mdz> definitely
<tfheen> so better to upload now than forget about it again
<tfheen> they'll just languish in the unapproved queue for a day or so
<mdz> tfheen: releasechecklist claims to be applicable to beta as well, though I think most of the relevant bits are already in betaprocess
<tfheen> mdz: I'll go through and clean up all those on the 27th.
<tfheen> print them out, sit down with a pen and see what edits are needed.
<pitti> sfllaw: I just did alternate/amd64/autoresize, FYI
<sfllaw> pitti: Oh good.
<sfllaw> pitti: I couldn't get it to offer me the option.
<sabdfl> moin moin all
<lifeless> moining
<ogra> hey sabdfl 
<pitti> hey sabdfl
<sabdfl> it's spec season!
<sabdfl> for me at least :-)
<pitti> sfllaw: I'll do a real-hardware desktop/amd64 installation now and I'll try to get auto-resizing
<pitti> sfllaw: it seems easier if the large partition is on a logical partition
<mdz> sabdfl: in this channel it's release season ;-)
<ajmitch> sabdfl: don't worry, we've started cooking up a good batch of specs to talk over in a couple of weeks :)
<sabdfl> ajmitch: registered & proposed for UDS, right?
<ajmitch> of course
* ajmitch just has to sort out the hotel now so that he can be there
<sivang> morning
<ajmitch> hi sivang 
* sivang high fives ajmitch 
<ogra> Kamion, the rescue mode executes /bin/sh in the target filesystem ?
<tonyyarusso> sabdfl: May I ask, when a spec is submitted for UDS consideration, what exactly happens next?
<ogra> Kamion, shouldnt that rather be /bin/bash ?
<tonyyarusso> (And is there a deadline that they would need to be submitted in launchpad to make it?)
<Mirv> if I'm hoping to have five new packages from Debian, to be included in main in feisty, should I do a spec about it or just first get them in universe and then ask for promotion to main separately?
<ogra> Mirv, the latter
<sivang> Mirv: what are they going to be of?
<Mirv> ogra: thanks. 
<Mirv> sivang: the first really working (tm) Finnish spellchecker, which has been worked on for a year or so, and has just landed (4 of 5 packages) in Debian unstable
<Mirv> I mean, really working open source spellchecker
<sivang> sounds nice.
<minghua> the one with a strange name (voikoo?)?
<Mirv> minghua: yes, libvoikko :) and tmispell-voikko (ispell and enchant compatibility) plus openoffice.org-voikko. and libvoikko needs suomi-malaga, which a description of Finnish morphology, written in malaga
<Mirv> so there are the 5 packages
<fabbione> Mirv: they will for sure land in universe when feisty open
<minghua> Mirv: thanks for the explanation
<fabbione> Mirv: to get them into main it's a bit more comples.. you will need to look at MIR and provide proper reasoning for main inclusion
* minghua needs to look at those complex spellcheckers to see if it's possible to write a Chinese one :-)
<dholbach> good morning
<sivang> morning dholbach !
<Mirv> fabbione: yes I know it's going to take some time, that's why I'm asking these things early. optimally it should be part of language-support-fi meta-package in feisty, but we'll see what's needed for that.
<Mirv> ah, main inclusion review, took some time
<pitti> Mirv: ?
<mdz> tonyyarusso: as noted in the announcement, what happens is that the organizers will review the proposals according to the published guidelines and create the agenda
<mdz> tonyyarusso: the deadline is this Sunday the 22nd
<tonyyarusso> mdz: Ah, thank you.  And are they accepted/rejected before the summit starts, or is that how it begins?
<mdz> tonyyarusso: the former
<tonyyarusso> mdz: Okay.
* tonyyarusso has three more to write up this weekend it sounds like
<mdz> tonyyarusso: are you attending the summit?
<tonyyarusso> mdz: No - just submitting ideas.  I don't have the time, finances, or technical knowledge for actually attending (although it would be really interesting!).
<pitti> mdz: ugh, that's a pretty tough deadline; can't we extend it until after the release?
<mdz> pitti: do you realize how soon the summit starts after the release? :-)
<tfheen> seconding pitti; there's no way I can write up sensible spec ideas before sunday.
<ogra> ++
<pitti> mdz: yes, I do
<tfheen> unless you have a time pocket I can grab a couple of days out of.
<pitti> mdz: but I'm not sure whether the distro team is in a good mood for spec writing...
<mdz> I don't, but I do have plenty of specs
<pitti> ok, good to know, tomorrow/Monday should be ok for writing specs
<pitti> thanks for the reminder
<mdz> if history is a guide, there are already nearly as many topics on the agenda as we can expect to cover
<pitti> ugh
<mdz> in Paris there were 173
<mdz> less than half ever went anywhere
<pitti> so we should hurry up to actually get things covered
<cbx33> ogra: are you handling the scp spec?
<ogra> feel free :)
<cbx33> yikes
<cbx33> when is the deadline for specs?
<Lo-lan-do> Hi there -- question about Ubuntu: how are packages going into Universe selected?
<cbx33> Lo-lan-do: submit them to REVU
<tfheen> Lo-lan-do: everything from Debian + various other sources, including direct upload.
<cbx33> revu.tauware.de
<Lo-lan-do> Direct import from Debian?
<tfheen> Lo-lan-do: yes.
<tonyyarusso> cbx33: Well, they just told me this Sunday.  Better hurry!
<cbx33> flippidy jippidy
<Lo-lan-do> Okay.  No QA then?
<cbx33> Lo-lan-do for new pacakges?
<cbx33> or ones already in debian?
<Lo-lan-do> Ones already in Debian.
<seb128> Lo-lan-do: what do you mean by "No QA"?
<cbx33> Quality Assurance I guessed?
<seb128> Lo-lan-do: some people fix bugs for those too :)
<Lo-lan-do> No testing before upload?
<seb128> cbx33: I know what QA means, thank you
<tfheen> Lo-lan-do: they're synced directly if they haven't changed in Ubuntu, yes.
<seb128> Lo-lan-do: no, if they are good enough for Debian we usually consider them good enough for Ubuntu too
<azeem> Lo-lan-do: buildd uploads aren't tested before upload in debian, either
<cbx33> seb128 sorry
<Lo-lan-do> My main beef is with Ubuntu bug #66537
<cbx33> I didn't mean that :p
<Lo-lan-do> The package works in Debian, but breaks in Ubuntu.
<Lo-lan-do> I mean, it prevents the program from even starting.
<Lo-lan-do> I could of course choose to ignore these bugs since they don't concern Debian -- no big decision to make, since I'm not even told about them.
<Lo-lan-do> The problem is that people have no contact address for these packages.
<Lo-lan-do> They only have my name, and I don't think it's appropriate for me to be held responsible for brokenness I'm not involved with (or aware of).
<cbx33> Lo-lan-do are you down as the maintainer?
<azeem> the contact are the universe maintainers
<tkamppeter> hi doko, are you there?
<Lo-lan-do> cbx33: Apparently, yes, since the package was slurped unmodified into Ubuntu.
<cbx33> can you link me to the page on LP?
<cbx33> for the package?
<tfheen> Lo-lan-do: we put X-original-maintainer: $debian_maintainer for all packages built now though, and force Maintainer to be ubuntu-devel.
<tkamppeter> doko_, ping
<Lo-lan-do> azeem: Maybe that should be advertised more?  The poor guy had to google my name, and only found my professional address.
<cbx33> in an alternate install, if there is not enough room to resize is the option removed?
<azeem> Lo-lan-do: this is transitional
<tfheen> cbx33: yes.
<azeem> seems it last got synced in June, the next sync won't have you as maintainer anymore
<Lo-lan-do> (With the amusing side effect that my reputation is hurt because of something completely automated causing problems I'm not even told of)
<Lo-lan-do> azeem: Oh, good.  So you're rebuilding all packages now?
<azeem> Lo-lan-do: I don't
<Lo-lan-do> "You" as in "Ubuntu" :-)
<seb128> Lo-lan-do: no, we don't do a massive rebuild now, that will be changed next time an upload is done for the package
<azeem> I assume they will all get rebuild at some point and this problem will go away
<Lo-lan-do> Okay.
<Lo-lan-do> When do these syncs usually happen?
<seb128> Lo-lan-do: edgy is frozen now, after edgy, something like 3 weeks from now probably
<Lo-lan-do> I see.
<seb128> Lo-lan-do: we can do a rebuild upload of your package if you want though
<Lo-lan-do> Is there any chance this particular bug could be fixed for edgy?
<seb128> I'll do that between RC and edgy
<seb128> if somebody has an idea on the issue yes
<seb128> I don't for my part and I don't use that package
<seb128> I'm fine with applying a patch or rebuilding, I will not spend time learning about the software to debug the issue though
<Lo-lan-do> I'd gladly provide a patch, but... well, the package works in Debian.
<seb128> maybe a rebuild would fix it
<seb128> let me give it a try
<cbx33> ping sfllaw 
<sivang> malone #66537
<Ubugtu> Malone bug 66537 in kino "kinoplus 0.3.5-3 breaks kino 0.9" [Unknown,Unknown]  http://launchpad.net/bugs/66537
<seb128> hum
<seb128> Program received signal SIGSEGV, Segmentation fault.
<seb128> [Switching to Thread 47029115933104 (LWP 11196)] 
<seb128> 0x0000000000fd3b90 in ?? ()
<seb128> (gdb) bt
<seb128> #0  0x0000000000fd3b90 in ?? ()
<seb128> #1  0x00000000004a0f86 in GDKImageCreateRepository::Register ()
<seb128> #2  0x000000000048d83c in PluginImageCreateRepository::InstallPlugins ()
<seb128> after a bunch of
<seb128> "(kino:11196): Gnome-CRITICAL **: gnome_program_get_app_id: assertion `program != NULL' failed
<seb128> (kino:11196): GLib-CRITICAL **: g_string_prepend: assertion `val != NULL' failed
<seb128> "
<Lo-lan-do> Can I get a changelog for an Ubuntu package?
<seb128> after ">>> Image Filter: Superposition"
<minghua> Lo-lan-do: which one?  for kinoplus there is no changes in source package
<Lo-lan-do> kino, actually.   Since there seem to have been Ubuntu-specific changes, I suspect the cause of the bug is in there.
<seb128> kino (0.90-1ubuntu2) edgy; urgency=low
<seb128>   * add 70_fix_builderror to fix ftbfs (debian bug #377174)
<seb128>  -- Oliver Grawert <ogra@ubuntu.com>  Sun, 16 Jul 2006 18:38:40 +0200
<seb128> kino (0.90-1ubuntu1) edgy; urgency=low
<seb128>   * Merge from debian unstable, remaining changes:
<seb128>     - install udev rules according to Ubuntu policy,
<Lo-lan-do> Ah, anyway.  Thanks for the info, I'll explain all that to the submitter.
<seb128>     - drop dependency on libavcodec.
<Ubugtu> Debian bug 377174 in kino "FTBFS with GCC 4.2: C/C++ linkage declarations conflict" [Unknown,Closed]  http://bugs.debian.org/377174
<seb128>  -- Scott James Remnant <scott@ubuntu.com>  Mon, 10 Jul 2006 15:41:22 +0100
<seb128> 
<seb128> those are the changes
<Lo-lan-do> Something's wicked then.  Oh well.
<minghua> Lo-lan-do: http://changelogs.ubuntu.com/changelogs/pool/main/k/kino/kino_0.90-1ubuntu2/changelog
<Lo-lan-do> minghua: Thanks.
<Lo-lan-do> See you :-)
<seb128> Lo-lan-do: I'm doing a debug build of kinoplus if you are interested to the bt
<sfllaw> cbx33: Yo.
<cbx33> sfllaw: just a quick question - in the testing plan - why do not test LVM installs?
<cbx33> I know it would make the matrix twice as big
<cbx33> just curious is all
<tfheen> rodarvus: have you had a chance to do any of your installation testing?
<Riddell> Kamion: I seem to have a complete new set of CDs to test, not just amd64
<snail> I'm seeing that today's build of edubuntu thinks I have a US keyboard rather than a UK one. " and @ are exchanged
<snail> is this normal?
<ogra> snail, on a thin client or in the normal desktop ?
<snail> normal desktop
<snail> this is the live cd
<snail> haven't done the install yet
<tfheen> Riddell: md5sum should be the same for everything not rebuilt.
<ogra> heh, and i havent done the liveCd yet :)
<sfllaw> cbx33: We don't really use LVM any more.
<tfheen> ogra: amd64 live dvd seems good, I'm testing the installation now.
<pitti> Kamion: ubiuity keyboard selector: on ppc I get a second list with alternative keyboards (like nodeadkeys, dvorak, international, etc.), on amd64 I just get the left list with the countries; is that intentional/known/a bug?
<ogra> tfheen, cool ...
<Riddell> tfheen: cool
<ogra> i'm still waiting for my DVD iso to come down the drain 
<dholbach> sfllaw: don't tell that fabbione
<fabbione> sfllaw: you nuts?
<fabbione> cbx33: LVM is only on alternate and manual partitioning..
<tfheen> : tfheen@lithium ..om/www/full/kubuntu/daily > md5sum 20061017.1/edgy-alternate-i386.iso 20061019/edgy-alternate-i386.iso
<tfheen> 5a7d963f317ab57bee1108a1c2a786ad  20061017.1/edgy-alternate-i386.iso
<tfheen> 5a7d963f317ab57bee1108a1c2a786ad  20061019/edgy-alternate-i386.iso
<tfheen> : tfheen@lithium ..om/www/full/kubuntu/daily >
<tfheen> Riddell: ^^
* ogra goes for some quick rescue/check test on i386 ... bbl
<tfheen> seb128: what's the gnome-settings-daemon fails to start in some live session bugs?
<tfheen> s/bugs/bug/
<tfheen> as in, what's the bug #?
<seb128> tfheen: there is none
<seb128> nobody opened a bug about it
<tfheen> dbus is the right package?
<seb128> tfheen: if the bug is actually the timeout issue, yes
<tfheen> I think it is; the timeout was never actually increased, was it?
<seb128> tfheen: in fact https://launchpad.net/distros/ubuntu/+source/dbus/+bug/62763
<Ubugtu> Malone bug 62763 in dbus "dbus activation timeout too short" [Low,Fix released]  
<seb128> tfheen: right, patch was not correct
<seb128> it has to be reopened probably
<seb128> is the usplash supposed to have the old style with a weird progress bar on amd64 now?
<mvo> tfheen: are you currently editing Testing/Current?
<seb128> weird like with no background color
<tfheen> mvo: yes
* mvo waits patiently
<tfheen> seb128: reopened
<seb128> tfheen: ok
<tfheen> bah, slomo beat me to it
<cbx33> fabbione, do we not consider LVM the way forward then?
<fabbione> cbx33: well not everybody does
<slomo> tfheen: sorry... at the moment i saw seb128 pasting the url again i remembered that we had a bug about it and reopened it ;)
<cbx33> fabbione, I'm just intrigued is all...
<cbx33> I heard a lot of ruckuss a year or so ago about LVM...oh it's FANTASTIC
<fabbione> cbx33: i do test LVM always..
<cbx33> was just interested in where "Ubuntu" fell
<fabbione> cbx33: there is an "erase disk and use LVM" option in alternate installer
<cbx33> I like it, I think it's great, but it's easy to bugger up
<cbx33> yeh just running it now
<fabbione> LVM is not a simple thing to work with. there are tons of corner cases and we decided to keep it simple to some extents
<fabbione> if you want a complex LVM config you need to go manual partitioning
<cbx33> yeh, is there a nice gui for lvm yet?
<tfheen> cbx33: evmsgui
<fabbione> no
<cbx33> the worst part when I was new to LVM was trying to recover data off an LVM partition when I knew nothing about LVM :0
<cbx33> it would be great to be able to just plug a new HDD in and for ubuntu to detect it and ask the user if they wanted to expand their system onto it
<cbx33> ;)
<fabbione> tfheen: testing alternate/i386/cli install
* StevenK wonders if he can install onto LVM using Ubiquity.
<pitti> Kamion: nevermind my keyboard question, that was PEBCAK)
<fabbione> StevenK: nope
<cbx33> fabbione we used to in dapper no?
<fabbione> no
<sivang> slomo_: !
* sivang hugs slomo_ 
<slomo_> hi sivang 
<pitti> hi slomo_
<slomo_> hi pitti 
<snail> is there a package which counters machines trying to brute-force their way in via ssh?
<cbx33> why can't gimp easily print
<rodarvus> tfheen, no, I received Simon's email last evening. I'm syncing my images right now
<sfllaw> rodarvus: Thanks.
<lifeless> snail: what do you mean
<rodarvus> cd image is ready, but dvd image will take a few hours to be downloaded
<sfllaw> rodarvus: dholbach has volunteered to do the DVD, because you have low bandwidth.
<rodarvus> nice :)
<sfllaw> Can you pull in another CD, though?
<rodarvus> *nod*
<rodarvus> doing it now
<sfllaw> Can you pull Edubuntu i386?
<sfllaw> That way, dholbach can do less.
<sfllaw> He's got a lot of PPC stuff.
<snail> lifeless: logs show lots of repeated ssh connection attempts from machines I've never heard of. presumably they're trying common suernames and common passwords. I'd like to detect and block them
<dholbach> sfllaw: I'll need to try it
<sfllaw> dholbach: Ubuntu i386 DVD?
<rodarvus> sfllaw, sure, I'll do edubuntu i386 too
<dholbach> sfllaw: yes, ppc dvd - if it works
<sfllaw> dholbach: Yes, thanks.  I meant your doing Ubuntu i386 DVD, instead of rodarvus as you volunteered to do in the other channel.
<snail> lifeless: something like http://www.pettingers.org/code/sshblack.html
<dholbach> alrighty
<sfllaw> OK.
<sfllaw> Updating Testing/Current.
<sfllaw> dholbach: I'll find someone to do the PPC DVD.
<sfllaw> mdz: We don't have enough people with fast connexions and working PPCs.
<sfllaw> mdz: I'm trying to get my hands on one here in Montreal.
<mdz> perhaps we shouldn't release powerpc DVDs
<mdz> there are probably more test installs than downloads for them :-P
<sfllaw> I think jbailey has already promised that it would work for a machine.
<sfllaw> And that machine only installs off of netboot and DVD.
<sfllaw> It's specialized, though.
<sfllaw> Uses its own initramfs.
<mdz> I'm perfectly happy to defer release of those images if that's the blocker
<mdz> it looks like i386 ubuntu/kubuntu/edubuntu DVDs need help as well though
<sfllaw> Anything to do with DVD is bad.
<mdz> I'm going to do them all in vmware here
<sfllaw> Great.  I'm going to have images for those by the end of tomorrow.
<sfllaw> So I can do some testing here in Mtl.
<sfllaw> By tomorrow, I mean today.
<sfllaw> I have the physical resources to do most i386 and amd64 testing, if I have to.
<sfllaw> But I can't do anything to pick up the slack for PPC.
* sfllaw hugs ogra.
* sfllaw hugs dholbach.
* sfllaw hugs pitti.
* ogra hugs sfllaw 
<sfllaw> (Who isn't here.)
<sfllaw> ogra: Thanks for doing Edubuntu PPC testing on CDs.
<sfllaw> ogra: Can you pull down DVDs as well?
<ogra> on it ...
<sfllaw> Hurray.
<ogra> but my bandwith sucks
<sfllaw> Everyone's does, apparently.
<dholbach> I'd love to upgrade to 16 Mbit
<ogra> so that may take some more time ... edubuntu install are all fine on all arches ... i'll do live testing as well as long as i wait for the DVD
<dholbach> the only problem I see is that they will fuckup and I'll end up with 2 weeks without internet at all
<sfllaw> dholbach: Yeah, you need to have both active for a while.
<sfllaw> And cut over.
<sfllaw> Which is $$$.
<doko_> tfheen: was the kubuntu DVD updated tonight?
<sfllaw> doko_: Yes, for amd64.
<sfllaw> doko_: Sorry.
<dholbach> Or I could work for two weeks from doko_'s place
<dholbach> and have Sushi at the place in his street
<sfllaw> Mmm.
<sfllaw> But then you have to live with doko.
<dholbach> . o O { *ponder* }
<sfllaw> ;)
<doko_> dholbach: I thought you would be cooking ... ;-p
<dholbach> He has a HUGE place - I doubt I'd even notice him around ;)
<mdz> doko_: the rsync delta from yesterday should be tiny
<dholbach> doko_: hahahaha
<sfllaw> dholbach: Can you cook?
<doko_> mdz: sure, testing again ...
<sfllaw> dholbach: I know you're a musician, which could be useful to have around.
<dholbach> sfllaw: nobody cried at table yet - and I'm quite happy with it :)
* StevenK can cook - I just don't think any one would eat it. :-P
<sfllaw> If we ever get a hotel with a kitchen, we should totally whip stuff up.
<mdz> tfheen: we can pre-publish the CD ISOs as soon as they're tested; we should aim for that first
<dholbach> sfllaw: no no no no - I'm not that musical
<sfllaw> dholbach: DJing?
<dholbach> yeah, that's better :)
<elmo> seb128: why is totem-mozilla so hateful?
<sfllaw> dholbach: I respect that.
<seb128> elmo: what is it doing now? 
<mdz> what's the rune to start expert mode in d-i?
<elmo> seb128: it's claiming to own RTSP streams, but all it does is popup a box saying "haha, I can't RTSP yet, sucks to be you".  this is less than helpful when realplayer's installed
<sfllaw> F6 F6.
<seb128> elmo: do you have an URL example?
<sfllaw> mdz: ^^
<sfllaw> mdz: I opened a bug saying we should document that.  :/
<mdz> sfllaw: wow, that's more cryptic than I expected
<mdz> sfllaw: please target that bug for final
<cbx33> I found it once by accident
<cbx33> sat on the keyboard
<jsgotangco> wah?
<mdz> tfheen: I think we're almost ready to pre-publish Ubuntu CDs
<ogra> oh, funny ... i can write CDs from a mounted thin client device ... 
* ogra never tried that
<sladen> cbx33: ?!
<jsgotangco> ogra: wow
<cbx33> sladen: there you are :p
<Nafallo> ogra: kewl :-)
<cbx33> did you get my email?
<elmo> seb128: http://www.bbc.co.uk/radio/aod/radio2.shtml
<ogra> well, the device is only the source :) the CD writer is in the server 
<cbx33> ogra: nice - it burns on the server I presume
<sladen> cbx33: and talking of which, are you in Southampton and need your key signing?  I'll swap a signature for a soldering iron to fix my Thinkpad PSU connector!
<cbx33> hehe
<ogra> cbx33, indeed
<seb128> elmo: ah, right, funny :)
<cbx33> sladen....didn't you get my email?
<ogra> cbx33, for that we'll need pygis libburn
<cbx33> ogra: that's what I thought
<cbx33> ogra scp chat before sunday? - possible?
<ogra> sure
<ogra> just not today
<cbx33> EXCELLENT
<seb128> elmo: I'll have a loot at making it not claim the mimetype so you can use realplayer
<cbx33> I have some cool ideas
<seb128> elmo: could you open a bug on totem please?
<elmo> seb128: yep, will do
<seb128> elmo: thank you
<fabbione> hey elmo 
<ogra> cbx33, please try to capitalize SCP if we talk about it in here or make it distinctive from scp in another way to not confuse everybody :)
<cbx33> stuconpan
<ogra> heh
<seb128> cbx33: change your password now :p
<elmo> hey fabbione 
<seb128> ah, no, it was a word for SCP :)
<ogra> yeah :)
<cbx33> can we have a new name for it
<cbx33> :p
<cbx33> something cool like ubiquity
<jsgotangco> cbx33: funny
<ogra> oh, the bounbcing progress is broken for me on ppc live
* cbx33 didn't like that bouncing
<cbx33> confused me
<cbx33> i'd never seen it before
<ogra> well, me neither
<dholbach> seb128: I have a ubuntu-docs upload in the pipeline - it's the "sebonator release" - it has 200 .omf files - just for you :-)
<cbx33> and all of a sudden I had no idea how long it was gonna be :p
<ogra> and dure to the bug i couldnt see it now as well
<ogra> keescook, are you sure you saw 66726 on your ppc kubuntu dvd test ?
<seb128> dholbach: rock on ;)
* seb128 hugs dholbach
<fabbione> can somebody test Alternate CD, auto-resize ubuntu cd i386 ?
<fabbione> i don't have the setup for it
<seb128> dholbach: so it was a bug :)
<dholbach> seb128: still seems broken though
<cbx33> ogra I have a possible new name for SCP - Pupil Fun Destroyer
<ogra> i still like teachers-pet :)
<mdz> fabbione: already am
<Nafallo> SCP? student control panel?
<jsgotangco> yeah
<seb128> dholbach: oh?
<Nafallo> my thoughts went for ssh ;-)
<jsgotangco> rename it the pupilator or something
<fabbione> mdz: ok.. i have almost done with expert mode and that shouldcover all x86/alternate
<ogra> Nafallo, thats the problem with the abbrev. :)
<Nafallo> ogra: then don't abbreviate it ;-)
<mdz> fabbione: oh, wait, I have manual and expert/LVM
<mdz> I can do an auto-resize though
<fabbione> i have done manual
<tonyyarusso> Do we have a teacher control panel to go with that?  (Something that could monitor a class worth of terminal through thumbnails of VNC sessions or the like?)
<mdz> I'll cancel my manual since you've done it
<mdz> and the partitioning step has worked fine
<fabbione> mdz: i can test LVM with netinstall
<ogra> Nafallo, the name is way to long to write it all the time
<pitti> uh, nvidia-glx-config is broken now: it does 'modprobe nvidia' and checks the result before writing xorg.conf, and modprobe nvidia checks xorg.conf before loading - yay deadlock
<Nafallo> ogra: add a .desktop then ;-)
<pitti> fabbione: ^ is that known already or shall I file a bug?
<ogra> Nafallo, i mean discussing it, it has a .desktop file :)
<fabbione> pitti: i dunno.. that's a regression introduced by all the recent changes to l-r-m
<Nafallo> :-)
<fabbione> pitti: nvidia-glx ALWAYS did that check
<pitti> fabbione: I know, I wasn't blaming you  :)
<pitti> but we have to adapt that script to the new weird modprobe behaviour
<pitti> (or fix the latter)
<fabbione> pitti: i blame who decided to do all those changes without testing all the side effects
<fabbione> mdz: expert is done
<mdz> s/$/ well after feature freeze/
<fabbione> what was the reason of changing modprobe behaviour?
<fabbione> or whatever they did to nvidia/fglrx?
<pitti> fabbione: I'm not sure, but I think it was to avoid loading non-free drivers unless necessary
<carlos> is there anyone from the ubuntu-doc team around?
<cbx33> does this mean the beta nvidia driver is in?
<cbx33> or a fix to the old one?
<cbx33> or none of the above
<pitti> cbx33: no fix for the root hole so far
<mjg59> None of the above
<cbx33> rats
<fabbione> pitti: ok.. a bit pointless at the 5th release.. but whatever.. damage is done
<tonyyarusso> carlos: A few people are online, but -doc has been dead for hours.
<carlos> tonyyarusso: thanks, I didn't know there is an ubuntu-doc channel
<mjg59> fabbione: To avoid loading 5MB of junk into the kernel when people aren't even using the non-free driver
<pitti> hm, but a manual modprobe refusing to load the module?
<mdz> pitti: why does nvidia-glx-config need to modprobe?
<pitti> mdz: it checks whether the module is available and working
<pitti> mdz: we probably have to drop that check then
<mdz> pitti: would modprobe -i solve it?
<pitti> or first alter the config, then modprobe
<fabbione> mdz: i did that check to make sure nvidia was available before altering xorg.conf
<fabbione> mdz: it was a sanity check that has always been there
<pitti> mdz: ah, -i helps
<cbx33> bbl
<pitti> mdz: I'd deem that milestone-worthy, do you agree? It's an easy fix, too
<mdz> pitti: yse
<mdz> yes
<pitti> alright, I'll file a bug and see to it
<tfheen> mdz: ok, I'll prepublish now
<sfllaw> mdz: Done.
<tfheen> I just need to find the correct runes
<ogra> whats doing the bouncing progressbar on the liveCD ? casper ?
<mdz> tfheen: once you have, please add them to the documentation
<fabbione> mjg59: how come non-free drivers started autoloading?
<fabbione> mjg59: i always had to either force or wait for X to load nvidia
<tfheen> mdz: what do you want the images called?  release-candidate or rc?
<mdz> tfheen: rc
<pitti> carlos: sorry, I was offline often due to install tests; are the new tarballs ready?
<fabbione> tfheen: my son is blattering something like "AO".. perhaps we should change name schema :)
<carlos> pitti: no, I'm starting the generation now. the mirror was broken and had to wait for our DBA to regenerate the database
<fabbione> "ehhhhh.. aoooo"
<Kamion> ogra: rescue mode tries to do the simplest possible thing in order to stand the greatest change of working
<ogra> well 
<pitti> mdz: dapper-proposed langpacks are 8 days old, I didn't hear regression reports; ok for me to have them uploaded to -updates now?
<mdz> pitti: did you hear success reports? :-)
<ogra> Kamion, we will surely have /bin/bash on every ubuntu system
<pitti> mdz: neither, most of the testers use the dailies
<StevenK> Kamion: I uploaded an unmetdeps fix for galago-gtk-python. Do you have a sec to check if it's been rejected or will be approved?
<mdz> pitti: and the -updates upload is from a known good daily?
<pitti> mdz: the -proposed one is, yes
<mdz> pitti: ok then
<pitti> alright, thanks
* pitti will be glad to see bug 42264, and the 23948234 duplicate subscribers, too
<Ubugtu> Malone bug 42264 in gettext "language pack po files drop cflag comment which causes segfaults in e. g. 'dd'" [Medium,Confirmed]  http://launchpad.net/bugs/42264
<Kamion> pitti: keyboard> that's incredibly freaky / impossible
<pitti> ... see fixed
<pitti> Kamion: right, as I said it was PEBCAK, sorry
<Kamion> pitti: what version of ubiquity is there on amd64?
<mdz> pitti: PEBKAC
<pitti> *blush* I accidentally burned the dapper image *brown paperbag*
<tfheen> mdz: .pool/ubuntu-6.10-rc-alternate-amd64.iso looks like a good name, right?
<mdz> tfheen: yes
<Kamion> pitti: oh, ok, PEBCAK, good :)
<mdz> tfheen: Kamion can confirm that everything is hunky-dory once he's finished with scrollback
<tfheen> mdz: sure
<Kamion> mdz: powerpc DVDs are the only way that Pegasos installs will work; I concede that there are few of those but they are a partner
<mdz> Kamion: the sort of partner whose representatives publicly condemn us
<pitti> mdz, Kamion: if we still lack a tester for them, I can bike to the university to a friend of mine and download them there
<pitti> mdz, Kamion: it's probably too late for RC, but I can do that for the final release if necessary
<mdz> pitti: I believe keescook can do it, but he's not likely to be awake for a few more hours
<tfheen> the DVDs don't need pre-publishing either
<Kamion> ogra: /bin/bash links to more stuff than dash does; it's quite possible that it would be broken due to e.g. libncurses being broken where /bin/sh would work ffine
<ogra> hmm, right
<Kamion> mdz: well, mdy commented on that yesterday
<Kamion> in #canonical
<ogra> but dash is a very uncomfortable usershell
<Kamion> StevenK: was in the unapproved queue last I checked; I haven't looked at it yet
<Kamion> ogra: type 'bash' then
<ogra> heh, indeed
<Kamion> and FWICT Sven seems to be being suppressed as a Genesi representative
<StevenK> Kamion: Righto. Thanks.
<ogra> hmm, the usplash drive CD check on ppc isnt very informative
<ogra> *driven
<pitti> ogra: at least it shows you when it's finished now :)
<Kamion> I'll try to download the Ubuntu powerpc DVD now
<Kamion> well, after testing Kubuntu desktop amd64
<ogra> pitti, right, and it worked flawless .... its just strange that the only indicator is the progressbar
<pitti> right, it actually shows filenames on amd64
<ogra> pitti, did you see any weirdness with the bouncing usplash progressbar on ppc live ?
<Nafallo> hmm. rsync stopped working on cdimage.ubuntu.com?
<pitti> ogra: no idea, after some seconds the screen goes black and I only see a weird-color progress bar
<ogra> seems usplash used a different mode for me
<ogra> the wallpaper turned black and the progressbar was distroted
<ogra> right
<ogra> do we have a bug about that ?
<Kamion> Riddell: Kubuntu amd64 usplash still looks a bit weird. Have you tried it?
<Riddell> we don't seem to have an option for expert install on the CD boot screen any more 
<Nafallo> rsync is back fwiw :-)
<Riddell> Kamion: yes, working fine for me in glorious 16 colours
<pitti> Riddell: two times F6?
<Kamion> it displays fine and all, but the progress bar is just a series of vertical lines with no horizontal lines top or bottom?
<Kamion> Riddell: what pitti said, exact same as in dapper
<pitti> but I agree that it's almost undiscoverable
<pitti> but well, it's expert :)
<Riddell> that is expert :)
<Kamion> I actually don't want expert mode to be very discoverable
<Kamion> people discover it and then file bugs that it asks them lots of questions
<Kamion> "yes. and?"
<mdz> it is poorly named
<StevenK> "That's the point." Rejected.
<pitti> 'enter an 11-digit prime number to do an expert install'
<mdz> it should be renamed ask-me-harder
<Fujitsu> pitti, yes please! :P
<fabbione> ahha
<Mirv> (pitti: my earlier message you asked about with a ? was just me deciphering fabbione's MIR acronym)
<pitti> I wonder why it didn't ask me for my shoe size
<Kamion> Riddell: can you update Testing/Current with that?
<pitti> Mirv: ah, I see
<fabbione> pitti: it already knows that
<Riddell> Kamion: just as soon as I have an install done with X running
<fabbione> mdz: netboot on i386 is good too
<mdz> fabbione: alternate auto-resize succeeded in the partitioning but I'm waiting for the install to complete
<fabbione> mdz: ok.. i think alternate is all covered now
<fabbione> rodarvus: are you testing server cd i386 ?
<pitti> Kamion: still I was impressed how well expert mode actually works; I had a list of 17 non-default answers, and the final system worked well and respected all of the changes
<rodarvus> fabbione, yes, doing it *right now* (download just finished)
<pitti> Kamion: I would bet two beer that most of the possible combinations have never been tested before :)
<mdz> my expert/LVM is paused while auto-resize finishes
<fabbione> mdz: i did expert with manual.. LVM works in all other situations. it shouldn't be required as test
<Kamion> pitti: yeah, it's fairly resilient by design
<dholbach> pitti: we had people installing  ubuntu-server-with-their-big-toe  - i would call that good test coverage ;)
<fabbione> who did edubuntu artwork?
<mdz> fabbione: oh, it looked like it said Keybuk in progress and he's clearly not here
<mdz> (does anyone know where he is?)
<ogra> fabbione, cbx33 and his wife mostly 
<tfheen> dholbach: I should teach my dog to install ubuntu.
<fabbione> mdz: it was my typo and i fixed it once i finished
<fabbione> ogra: ok.. it's just waaaaaayyy toooooooo ooorange!
<mvo> a bit bright too
<fabbione> mdz: i think it's easier to call him.. he is probably in Keybuk's TZ
<tfheen> fabbione: gives ya the real tex-mex feelin'!
<fabbione> tfheen: ahah
<Nafallo> tfheen: ooh. you have a dog now? :-)
<ogra> fabbione, we'll call it the dutch release :)
<Kamion> ETA six hours on the powerpc DVD download
<tfheen> Nafallo: yes
<fabbione> ogra: or the sicilian release.. with real orange juice
<Nafallo> kewl :-)
<Kamion> I'll cancel that and do it overnight so that I have it for final; there's no point using all my bandwidth on it now
<fabbione> Kamion: i can test live DVD for ppc, but that's about it.. no ubiquity or install
<seb128> lunch time; bbl
<Kamion> I'll grab Kubuntu alternate powerpc and do that instead
<fabbione> Kamion: ok, do you still want live dvd tested?
<Kamion> fabbione: if you can, it would be a lot better than nothing
<fabbione> Kamion: yup.. 
<Kamion> fabbione: also try rescue mode to give the d-i environment at least some exercise
<fabbione> Kamion: yes i can do both... i just can't install over there
<rodarvus> fabbione, any specific tests you'd like me to do appart from installation?
<rodarvus> server load, services, remote shares, etc
<fabbione> rodarvus: up to you
<mdz> rodarvus: thin client
<fabbione> keep in mind we are in short of time..
<fabbione> mdz: from server?
<rodarvus> mdz, yup, will do those on edubuntu as soon as server testing is done (in 20-30 minutes, I hope)
<mjg59> fabbione: Because nvidia has a modalias list
<mdz> fabbione: oh, he was also listed for some edubuntu
<ogra> mdz, i can doi the rest of edubuntu, i have the isos around anyway
<ogra> (just pulling the DVDs)
<mvo> mdz: I can do amd64/server-cd
<Nafallo> 20061018 is rc, right? :-)
<Kamion> Nafallo: Depends on the image. See Testing/Current
<Nafallo> oki, thanks
<Nafallo> true for desktop then :-)
<fabbione> oh here is Keybuk 
<mdz> tfheen: do you have a timestamp from when pre-publishing finished?
<mdz> tfheen: so that we know when our 4-hour window ends?
<giskard> hello *
<tfheen> mdz: 14:05 < tfheen> mdz: pre-publishing running.
<mdz> tfheen: that's when you started it?
<tfheen> that was approximately half a minute after I started the pre-publishing.
<fabbione> i assume that it is known that usplash on ppc is half broken
<mdz> oh, we can't tell when it's finished, can we
<tfheen> running sync-mirrors never takes more than ten seconds or so
<mdz> yes we can; there should be rsyncd processes on lithium
<tfheen> mdz: I doubt all mirrors synced 14 cd images in less than an hour.
<Kamion> most mirrors don't rsync from lithium, but from syncproxy or similar
* sivang tries the bittorrent download of DVD
<Kamion> it's only internal DC mirrors that rsync from lithium
<mdz> tfheen: elmo pointed out that we should remove beta
<tfheen> mdz: so it probably requires poking the various mirrors.  I'll ask Znarl for a list if it has changed since beta.
<mdz> tfheen: I've added that to the doc
<Kamion> mdz: no need
<mdz> oh? it replaces it?
<Kamion> mdz: beta gets automatically removed when rc is published for real
<Keybuk> fabbione: did you need me?
<fabbione> Keybuk: i can't live without you... you know that :)
<Keybuk> *hugs*
<Kamion> but not when it's only pre-published, for obvious reasons
<mdz> Kamion: ok
<mdz> Keybuk: did you die?
<tfheen> Kamion: magic!
<elmo> Kamion: could we do it before then?
<elmo> Kamion: releases is 51G atm 
<Keybuk> mdz: no, still sorting out passport issues; have been all week :-/
<Keybuk> took longer in town than I wanted
<Kamion> elmo: if we don't mind there being nothing for edgy on releases ...
<Kamion> (visibly)
<elmo> Kamion: assuming we're going to release today, I don't think that's a problem
<elmo> but  that's just MO
<mdz> Keybuk: if you need to deal with something urgent during release prep, please coordinate with sfllaw to get your test cases reassigned
<tfheen> Kamion: just rm the images (and the symlinks) from the pool or is there a script to do that too?
<mdz> we had a bit of a scramble
<Kamion> tfheen: let me, I forget ...
<Keybuk> mdz: I didn't even realise I *had* test cases assigned to me until I got back in and read my e-mail ;)
<Kamion> mdz: ok to remove beta?
<Kamion> tfheen: they need to be archived, not removed - I'll take care of it
<mdz> Kamion: yes, and please add the procedure to ReleaseCandidateProcess
<Kamion> the procedure involves moving to ~cjwatson/old-images/ :-P
<mdz> Kamion: that's ok
<tfheen> Kamion: could that be ~cdimage/old-images instead?
<mdz> Kamion: "remind Colin to run these commands" is a valid step :-)
<Kamion> tfheen: yes, in principle, but not now :)
<rodarvus> fabbione, browsing the WWW server of the LAMP from a remote machine leaves me in the /var/www/, instead of /var/www/apache-default/ (meaning I don't get to see the 'apache default installation' page). Is this expected, a (known?) bug, or weirdness on my network (unlikely, though)
<tfheen> Kamion: ok, I've put a note on a postit telling me we should fix that post-release.
<tfheen> I utterly hate using personal accounts for stuff which should be something that a role account does.
<fabbione> rodarvus: please file bugs in LP. 
<Kamion> sure, it predates the role account
<Kamion> (I think)
<Kamion> mdz: what is ReleaseCandidateProcess really called?
<doko_> Riddell: openoffice.org-kde isn't seeded for kubuntu-desktop?
<tfheen> Kamion: wiki.c.c
<Kamion> oh
<Kamion> why?
<Keybuk> Kamion: am I picky if I say that the keyboard guesser gives you characters which look very like normal ones :)
<tfheen> Keybuk: it shouldn't; it has a check to avoid that.
<Kamion> Keybuk: it shouldn't normally do that without also offering the "normal" ones
<Keybuk> Kamion: there were normal ones in the list, but I couldn't tell the difference
<Keybuk> so I pressed 'r'
<Kamion> that's ok
<Keybuk> and it bitched
<Kamion> if you can't tell the difference, press something that looks like it
<Kamion> Keybuk: can we go through this in more detail later?
<Keybuk> Kamion: yup
<fabbione> Someone else saved this page while you were editing! Please review the page and save then. Do not save this page as it is! Have a look at the diff of
<fabbione> THANKS!
<mvo> rodarvus: I have seen the same on my server testinstall (does it have a bugnumber yet?)
<mdz> moin's conflict handling is fatally lfawed
<mdz> flawed
<Keybuk> Kamion: I'm also getting "the resize operation is impossible" from the alternate
<Kamion> -v
<Keybuk> trying to resize an existing, or new, ext3 partition
<Keybuk> I get a big resize screen that says "Because of an unknown reason it is impossible to resize this partition."
<Kamion> hmm, not seen that, file a bug on partman-ext3 with /var/log/syslog and /var/log/partman please?
<Kamion> probably a parted bug actually
<rodarvus> mvo, no, I'll fill it in a minute (and write it down on the Testing/Current page)
<mvo> rodarvus: thanks, feel free to add it to my amd64/server/lamp test as well :)
<Keybuk> Kamion: how do I install scp onto this? :)
<rodarvus> mvo, sure thing
<Kamion> Keybuk: anna-install openssh-client-udeb
<Kamion> Keybuk: or use "save debug logs" from the main menu and it can be told to start a web server
<fabbione> Keybuk: dude.. did you really tested all those x86 images and didn't update the wiki???
<Keybuk> fabbione: I have vmware profiles for each of the tests, so didn't take long
<Keybuk> this thing can run half a dozen at a time
<mdz> tfheen,Riddell: Kubuntu looks ready to pre-publish, yes?
<Kamion> elmo: at your convenience, could you please archive lithium:~cjwatson/old-images/ and let me know when I can remove it? some of the stuff in there might be archived already
<tfheen> mdz: yes.
<fabbione> Kamion: dvd live and rescue look good
<fabbione> Kamion: (ppc)
<Kamion> elmo: the host key for mirnyy in lithium:/etc/ssh/ssh_known_hosts is wrong
<Znarl> Kamion : I'll fix that.
<Kamion> thanks. IIRC it's in LDAP?
<Znarl> Kamion : We've taken mirnyy out of cdimage rotation for the time being, as it isn't preforming as well as we'd like.
<Kamion> Znarl: oh. Shall I stop triggering it then?
<mdz> ogra: what's the default for edubuntu when you have two ethernet adapters? which one is inside and which one is outside?
<Kamion> Znarl: according to my list, the only host in the cdimage rotation is now beryllium - is that true?
<Kamion> fabbione: thanks
<Znarl> Kamion : Lets keep triggering it for the time being?  Just in case beryllium gets into trouble?  So it's a hot standby?
<Kamion> ok
<Kamion> beta removed from releases and torrent
<Znarl> Yes, beryllium is the only cdimage right now and it's doing fine.  I think Elmo has a plan to upgrade mirnyy but I'm not sure on the status of that.
<tfheen> Znarl: could you get me a list of all the release mirrors we trigger now?
<tfheen> so I could get them into the release announcement
<Znarl> tfheen : Yes, sure.
<Nafallo> hmm, people where downloading i386 beta from me :-)
<Nafallo> are even
<Nafallo> beta dvds still up?
<ogra> mdz, you select the one for outside in d-i's netcfg
<ogra> mdz, so the other one is the ltsp one by default
<ogra> if you have more than two NICs you get a selection list after the ltsp-build-client installer step
<Kamion> Nafallo: for now, but liable to be removed at any time.
<Nafallo> Kamion: okidoki :-).
<mdz> ogra: ok
<Kamion> mdz: how about we move breezy off releases.ubuntu.com to old-releases.ubuntu.com? would ease some space pressure
<mdz> Kamion: absolutely
<mdz> Kamion: hmm, when installing alongside Dapper, my grub menu now says (single-user mode) rather than (recovery mode)
<mdz> Kamion: did that regress?
<Kamion> I'm not sure, that would have been zul
<sladen> mdz: for both dapper and edgy?
<mdz> zul: ^^
<mdz> sladen: installing edgy alongside dapper
<mdz> the dapper one says recovery
<mdz> the edgy one says single-user
<Keybuk> mdz: you have a combination of both?
<mdz> Keybuk: I believe it copies the menu entries from dapper (as it should), but the edgy one is generated wrong
<mdz> can someone confirm if this happens on an erase-disk install too?
<Keybuk> that sounds like menu.lst is wrong
<mdz> it is
<Keybuk> "(single-user)" is the grub default
<Keybuk> the installer deliberately writes that different
<mdz> it wasn't in dapper
<Keybuk> yeah it was
<Keybuk> _grub_ default
<Keybuk> grub doesn't normally write the first menu.lst
<sladen> Keybuk: it's what /generates/ the menu.lst on upgrade that's likely to be wrong (copied entries okay, appended entries == bad)
<Keybuk> sladen: right, it must copy the entries, but leave the default grub preamble in place
<Keybuk> rather than editing the grub preamble first
<sladen> Keybuk: I suspect it doesn't "leave" preamble, but cat's its own idea of what that preamble should be
<Keybuk> could be update-grub itself?
<mdz> other than that, my alternate auto-resize succeeded
<mdz> Keybuk: update-grub should be changed to say recovery
<Keybuk> mdz: you managed to get a resize out of it?
<sladen> Kamion: what normally generates the /first/ menu.lst?
<mdz> Keybuk: yes, your virtual disk just needs to be big enough (6G is sufficient)
<Keybuk> mdz: right, but then I got a partman error
<Keybuk> same for manual partitioning
<mvo> I have "single-user mode" in a fresh server install in grub as well
<Keybuk> mdz: it says "single-user mode" for a CLI install
<sladen> debian/update-grub in the grub source says 'single-user'
<mdz> yes, that's the bug
<Kamion> sladen: grub-installer
<mdz> we changed this *ages* ago
<Kamion> yes, sounds like a regression
<sladen> ah, a *Debian* fix (debian #370110) changed "from recovery mode to single-user"
<Ubugtu> Debian bug 370110 in grub "please s/recovery/single-user/ in generated menu.lst" [Wishlist,Closed]  http://bugs.debian.org/370110
<mdz> bug 62600
<Ubugtu> Malone bug 62600 in grub ""Single User mode" should be renamed" [Medium,Confirmed]  http://launchpad.net/bugs/62600
* Keybuk prepares a fix
<Keybuk> weird, auto-resize worked that time
<Keybuk> kooky
<Kamion> right, breezy images moved to old-releases.u.c
<Kamion> could somebody with a current powerpc desktop CD handy (doesn't matter what architecture) verify that /etc/kernel-img.conf contains 'link_in_boot = yes'? see bug 52679
<Ubugtu> Malone bug 52679 in ubiquity "link_in_boot not set correctly" [High,In progress]  http://launchpad.net/bugs/52679
<Keybuk> holy crap, vmware just took out my machine ;9
<mdz> I've only had it do that a couple of times
<Keybuk> heh
<keescook> mornin'
<gnomefreak> who do we talk to about dapper-commercial repos
<elmo> is this gnome 'tracker' thing packaged yet in edgy?
<tfheen> elmo: doesn't seem to be
<zul> hmm..
<mjg59> elmo: No, probably to some extent because upstream appears to be on bad crack
<Keybuk> pieceofcrap
<elmo> mjg59: oh how come?
<mjg59> elmo: At various points, he's managed to piss off approximately everyone in gnome upstream
<doko> Riddell: ping
<elmo> mjg59: ah
<bhale> elmo: last i looked at tracker (2 months?) it did indexing of plain text files and provided a command line interface
<bhale> and an optional patch to nautilus
<bhale> grep -R works just fine for me
<bhale> there is an amazing ammount of hype over what it could potentially do
* bhale steps off
<bddebian> Howdy
<keescook> okay, anyone seen keyboard issues on ppc during first X session?  if I flip to console and back, it's solved.  I can't find a bug report that covers this.
<pitti> hi keescook 
<zul> Kamion: ping about the grub-menu bits i didnt touch that
<keescook> hiya pitti
<Riddell> doko: hi
<mdz> ogra: my edubuntu server install + clients seems to work great
<seb128> hum
<seb128> is oem mode supposed to do something special after first boot or first login?
<mdz> seb128: only after you run sudo oem-config-prepare as the instructions tell you :-)
<ogra> mdz, yippie \o/
<seb128> mdz: k, thank you, I was just thinking I should have read the screen before rebooting :)
<mdz> ogra: a 32M client and a 64M client
<mdz> Kamion: I think part of simplify-oem should be making that a login notification and doing autologin for the oem user
<ogra> cool, i didnt test with "real" 32M clients, only with mem= bootoption
<mdz> so they get instructions (or better, a simple wizard) after booting rather than before
<mdz> ogra: I tested with "real" vmware 32M machines
<mdz> I should be able to test local devices with this setup also
<ogra> just dont forget to add the user to the fuse group ... 
<jonh_wendell> mdz: we, translators, have to work in rosetta until today, right?
<mdz> ogra: oh?  why don't we do that by default?
<ogra> security reasons
<ogra> i talked to some educators, they want it rather optional 
<ogra> but look into the users-admin tool, there is a checkbox with proper explanation
<mdz> jonh_wendell: today is the deadline, correct
<jonh_wendell> mdz, thanks
<paulbk_> I just wanted to let someone know I installed Edgy desktop last night - No problems.
<mdz> ogra: ha!  I insert a real CD into the drive, which is mapped to the thin client VM, and it appears on the desktop like magic. :-)
<ogra> YEAH :)
<ogra> sbalneav^^^
<Kamion> zul: yeah, turned out to have been a Debian change we merged without noticing
<sbalneav> \o/
<Kamion> mdz: yes, I agree, and oem-config-prepare should be accessible from menus etc.
<Kamion> mdz: did you see my comment last night to the effect that I'd like to merge oem-config with ubiquity? they (should) share a lot of code
<mdz> Kamion: yes I did
<mdz> Kamion: do you think that should be a separate spec?
<Kamion> I'm not sure that discussing it separately will necessarily be useful
<doko> Riddell: openoffice.org-kde is not on the live DVD -> no KDE widgets, no KDE icons
<zul> Kamion: ok
<Riddell> doko: yes, amd64 only.  probably too late to change unless it's been well tested
<opi> Hi
<doko> Riddell: what do you mean by "well tested"?
<opi> I wonder if you got same xorg mess as I did 
<opi> after I've moved to Edgy, my xorg died claiming drivers (ie. ati) is ABI incopatible with xorg itself
<opi> it seems like I've got 7.0 drivers with 7.1 xorg
<opi> "module API major version (0) dosen't match server version"
<Riddell> doko: used by lots of people.  I'm just being overly cautious, I'm happy to take an opinion from our release dudes
<ZeroCool> Just Read This, Very Interesting Article http://www.madpenguin.org/cms/?m=show&id=7603
<Kamion> What's With The Title Case?
<ZeroCool> has allot to due with Xorg
<opi> ZeroCool: ah, this is link for me? :)
<ZeroCool> This is a link for the group... to read about xorg
<doko> Riddell: we should change it for final, not necessarily for RC.
<ZeroCool> how setting up xorg could be allot easier
<Riddell> oh definately not RC :)
<Kamion> xorg.conf is likely to disappear, not be easier to edit
<ZeroCool> read the link, for a new idea
<Kamion> I read it.
<ZeroCool> cool, and ?
<opi> ZeroCool: that won't solve my ABI problem ;)
<Kamion> see above
<ZeroCool> disappear, where ?
<Kamion> ZeroCool: furthermore, right now we are trying to prepare a release candidate; we'd appreciate not too many distractions, please
<ZeroCool> opi: no for your issue
<ZeroCool> opps.
<opi> Kamion: OK, OK -- I'm going ;-) Have fun with release. I'm going to dig solution on my own.
<jdong> holy crap... flashplayer9... anyone see that coming? 
<jdong> and it actually works
<bhale> they have been blogging it for months
<Nafallo> jdong: we had bugs against firefox about it :-P
<jdong> I didn't expect them to release it so soon
<Nafallo> only beta ffs :-)
<jdong> bhale: they've been blogging so much about it that it was beginning to sound like vaporware :)
<bhale> not when i read it.
<jdong> well, my friend, maybe you're a lot more optimistic than me
<jdong> to me it sounded like they were aiming for next year
* Nafallo looks happy when reading the diff for torrentflux :-)
<Nafallo> security updates :-)
<bhale> this is off topic
<Nafallo> bhale: right :-)
<jdong> oh, are we there yet? ;-)
* jdong ducks
<Nafallo> jdong: you might want to fire up rsync atleast :-)
<jdong> that wasn't a serious question, actually....
* jdong not in the mood for ISO downloadage today
<Nafallo> hehe
<jdong> my wifi is giving me post-traumatic stress disorder
<Nafallo> so I will be a lonely seed with 1Mbit up? ;-)
<jdong> Nafallo: I don't think my 300kbit up would be any contribution ;)
<Nafallo> hehe
<Kamion> pitti: is it just me, or is there a really nasty fd leak in hald-runner/runner.c:run_exited?
<Kamion> pitti: it never seems to close rd->stderr_v
<Kamion> pitti: I have a hald-runner here with 1015 fds open, as a result of which I can't suspend
<pitti> Kamion: looking
<pitti> it never stopped my laptop from suspending, though
<Kamion> it might take a while ...
<Kamion> or it might depend on other errors
<Keybuk> quest scott% sudo ls /proc/5283/fd
<Keybuk> 0  1  2  3
<pitti> same here
<pitti> sjoerd: ^ did you see this?
<keescook> hald-runner> I've only got the 4 too
<sjoerd> pitti: already fixed
<Kamion> if I'm reading the code right, it only leaks for requests with error_on_stderr set
<sjoerd> (fixed in debian thatis)
<pitti> sjoerd: ah, sweet
<Kamion> can we pull that fix into edgy post-RC, please?
<pitti> Kamion: of course, I'll create a milestone bug for it
<sjoerd> pitti: git fcb6aa0df90b7ee61a58c207896448131d3aa180 in the hal tree
<Kamion> thanks!
<pitti> Kamion: debian bug 375143
<Ubugtu> Debian bug 375143 in hal "hald-runner: leaks file descriptors" [Important,Closed]  http://bugs.debian.org/375143
<pitti> sjoerd: cute, thanks!
<pitti> mdz: permission to fix bug 66939 for final? (trivial one-liner patch)
<Ubugtu> Malone bug 66939 in hal "hald-runner fd leak" [Unknown,Unknown]  http://launchpad.net/bugs/66939
<mdz> pitti: yes
<doko> Riddell: kubuntu amd64 alternate install; after installation, kdm doesn't let me type in characters; only random keystrokes are detected, then these are autorepeated
<Riddell> hmm
<Riddell> doko: does that seem like https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/66929 ?
<Ubugtu> Malone bug 66929 in xorg-server "on first boot, ppc keyboard under X repeats forever" [Undecided,Unconfirmed]  
<keescook> doko: that sounds a lot 66929
<keescook> that means it's not ppc-specific at least
<keescook> doko: if you flip to console and back to X, is it fixed?
<doko> keescook: yes
<doko> unfortunately leaving X freezes the kernel when using the fglrx driver ... and the radeon driver doesn't support 1920x1200 :-/
<keescook> strangely, in OEM mode, during user config, they keyboard is fine
<infinity> That was happening to me when I was deboostrapping stuff a while ago, and console-setup's postinst would run and completely hose my X keyboard until I VT switched.
<infinity> I thought that got fixed, though...
<infinity> And I'm not sure how it would happen on first boot.
<TreMobyl> wow.  Big channel.
<lamont> hrm... ia64 livecd fails to detect my keyboard type correctly
<infinity> lamont: Does a VT switch fix it, by any chance? :)
<keescook> but be something specific to kdm: in OEM mode, the keyboard is okay on user setup, but once kdm starts up, the keyboard is busted again.
<lamont> infinity: I go through typing all the keys, and it goes right back to the same question again
<wasabi_> Um. Looking for a resource on the wiki which describes the freeze process, what is acceptable to upload to universe, what times, when, etc.
<infinity> lamont: Oh, you're talking the d-i keyboard guessing thingee.
<lamont> yeah
<lamont> which could be related to my comment in the other channel
<doko> Kamion, tfheen: on amd64, the live CD doesn't use/detect the monitor on the DVI connector during install; it works fine, if I use the VGA connector. results in a black screen for the live CD, and a question about the resolution for the alternate install
<pitti> carlos: what's the word on bug 2322? how can I check whether an exported PO file is wrong or correct?
<Ubugtu> Malone bug 2322 in rosetta "Truncated plural forms" [Critical,In progress]  http://launchpad.net/bugs/2322
<carlos> pitti: don't worry, I will do that check for you
<carlos> before giving you the tarball
<lamont> hrm... ia64 install CD also fails to detect the keyboard type.  syslog has 'Line sequence error: YES 37'
<pitti> BenC__, infinity: does any of you plan an l-r-m upload after RC? if not, I'd like to do an upload to fix bug 66908
<Ubugtu> Malone bug 66908 in linux-restricted-modules-2.6.17 "nvidia-glx-config does not work any more" [Medium,In progress]  http://launchpad.net/bugs/66908
<carlos> pitti: 5000 entries left to finish
<infinity> pitti: I have nothing planned, if you want to upload just for --ignore-install, go ahead.
<mdz> ogra: I think the edubuntu CDs should be named 'server' and 'desktop' rather than 'install' and 'live'
<mdz> especially since you can install from 'live'
<pitti> infinity: right; I just want to avoid two uploads in a row
<ogra> mdz, good idea
<mdz> ogra: coordinate with Kamion to make sure it's done early on for feisty
<ogra> yep
<pitti> carlos: alright, thanks
<doko> urgh, gray on black for LS_COLORS on the console ... nice idea ...
<Keybuk> doko: usplash bug, I think
<Keybuk> it doesn't restore the palette
<azeem> doko: is it for hidden files? ;)
<doko> azeem: heh ;) no, directories :(
<gnomefreak> mvo: does the update-manager now run -c for you or does it still have to be ran?
<mvo> gnomefreak: there are two modes "-d == --devel-release": check for new development releases
<gnomefreak> ok i remember there was a bug that it should have ran -c for you. looking at the RC1 wiki it says to run the -c flag
<mvo> gnomefreak: and "-c --check-dist-upgrades" <- check at all. in dapper the this checking for new distro relesaes if off by default because we assume that most people will want to stay with the LTS release. so they have (even after the release of edgy) run "update-manager -c"
<gnomefreak> ok
<mvo> gnomefreak: might be a mistake, what url is this?
<gnomefreak> https://wiki.kubuntu.org/EdgyReleaseCandidateAnnouncement
<Keybuk> mvo: it's an interesting point that everyone running dapper is going to get an "UPGRADE TO EDGY TODAY!" button
<Keybuk> without any warning that the new release will be supported for less time than dapper, etc.
<mvo> Keybuk: they won't. dapper will not do this by default (unless you force it via gconf or the -c switch)
<Keybuk> ahh
<mvo> it is enabled for edgy, so for feisty everyone will see such a button (but I think that is appropriate)
* Nafallo will test -c -d soon and get feisty :-)
<Keybuk> yup
<wasabi_> I might appreciate a long dissertation included with that on every distro upgrade.
<wasabi_> You are upgrading between releases, your current release is supported until X. Are you sure?
<Nafallo> wasabi: quite a bit nicer, indeed.
<gnomefreak> ok ty
<mvo> good idea
<dholbach> sfllaw: no ppc dvd love - I'll add that to StaffHardware
<wasabi_> I might even be tempted to say that we should be able to alter that message for a given release by updating some message to -updates
<TreMobyl> wasabi_: are you the texas wasabi?
<wasabi_> Yeah. The intensive purposes one.
<mvo> wasabi_: we can do that to a certain amount because it will download the release notes from a selected location
<TreMobyl> wasabi_: alright.  :)
<wasabi_> Yeah, but I think the message depends on botht he source/dest release proposed.
<wasabi_> Just sayin. ;)
<wasabi_> TreMobyl: Anything less than an intensive purpose would be week minded, imo. =)
<bluefoxicy> thunderbird is being weird
<bluefoxicy> every message in a thread shows the same contents
<bluefoxicy> ....
<bluefoxicy> even in non-threaded mode
<TreMobyl> hahaha
<TreMobyl> where's rupert when you need him?
<smurf> Kamion: ping
<Kamion> smurf: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
<smurf> heh
<Kamion> huh, Kubuntu alternate doesn't have language-support-en?
<smurf> Kamion: the "do you have the X key? Only count ..." text needs a linefeed somewhere
<bluefoxicy> alright, threaded mode off :(  and restart thunderbird
<Riddell> Kamion: which platform?
* sivang burns DVD cd
<Kamion> smurf: bug 66817, fix waiting for post-RC
<Ubugtu> Malone bug 66817 in cdebconf-keystep "fails to wrap text of questions" [Low,Fix committed]  http://launchpad.net/bugs/66817
<Kamion> Riddell: powerpc
<Kamion> did it not fit?
<smurf> bah, thanks; I looked for that one in the wrong packages :-/
<Riddell> Kamion: yeah, it didn't fit
<Kamion> d'oh
<Riddell> although that was about 10 days ago, some things may have changed since then
<pitti> seb128, Riddell, anyone else: are you up for some thorough langpack testing in about an hour?
<Riddell> pitti: sure
<pitti> we should probably use the ones I build now instead of tomorrow's dailies; more time for testing
<pitti> unless something important turns up, of course
<Kamion> whoa, yes, I see the X key repeat madness here too
<Kamion> Keybuk: can you remind me how we deal with network cards whose MAC changes when you load the firmware?
<Kamion> at least that seems to be what's happening here
<Keybuk> Kamion: I think it goes something like "la la la, not listening"
<Kamion> I thought there was some iftab magic
<Keybuk> no...
<keescook> hm... G5's nv driver seems to only draw the bottom half of the display.  :P
<Kamion> arse
<Keybuk> the card will get the name eth1 first, then eth2
<Keybuk> when we last talked about it, we decided it was a driver bug for announcing the original interface as an Ethernet one, and not a raw one
<Keybuk> ie. it should go
<Keybuk> eth1  Link encap:UNSPEC HWaddr 00:00:00:00:00:00
<Keybuk> ->
<Keybuk> eth1  Link encap:Ethernet HWaddr 12:34:56:ab:cd:ef
<Kamion> doko: please never just commit the same change to multiple derivatives - it makes it harder to merge later
<Kamion> should always be done with bzr merge
<sivang> I have a T43p and DVD , is this still worth testing?
<mdz> how did we get from 11 to 35 targeted bugs?
<jdub> testing!
<sivang> ah, I see only mdz and dhlobach tested DVD/i386, then I guess it is
<mdz> jdub: ITYM "panic"
<Kamion> quite a lot of those bugs are fix-committed
<Kamion> or otherwise sitting in the queue ready to be unleashed
<doko> Kamion: rebuilding ubuntu-meta will remove linuxprinting.org-ppds from the desktop; is this expected/wanted?
<Kamion> eek, we didn't do that for RC?
<Kamion> yes, that's expected and desired
<Kamion> it's meant to be in supported
<doko> ok
<Kamion> tfheen: confirm the above?
<tfheen> yes, it's desired and what we want.
<tfheen> I thought we did it for RC too.
<tfheen> but, apparently not. :-/
<tfheen> it should go on the checklist.  "Make sure *ubuntu-meta is up-to-date"
<mdz> it is
<mdz> 3. Merge seeds and update metapackages for all derivatives
<Kamion> we probably did and then later discovered the problem
<doko> tfheen, Kamion: please approve http://people.ubuntu.com/~doko/edgy/ubuntu-meta.debdiff
<Kamion> doko: please let ubuntu-meta update use the autogenerated changelog
<tfheen> also, what's that linux-headers diff?
<doko> Kamion: hmm, didn't find one, running update again
<Kamion> tfheen: see #canonical - linux-headers-386 in desktop was a mistake
<Kamion> doko: update runs dch
<tfheen> Kamion: ok.
<mdz> tfheen: wrong set of kernel headers in desktop
<infinity> doko: You didn't update ship...
<doko> Kamion: ohh, right, it failed, because devscripts wasn't installed. I think, I have to restart from a fresh 1.29
<BenC> blah
<BenC> all my installs worked
<Kamion> boring
<infinity> doko: If you're putting -generic in desktop, you need to put -386 in ship.
* sivang looks for the build number on DVD
<Kamion> sigh, I already said that in #canonical ...
<mdz> wow, I see no bug reports about this
<mdz> doko: how did you notice it?
<doko> Kamion, infinity: I did ... apparently it did blow up, because dch was not installed
<doko> mdz: notice what? the header problem? Trying to rebuild my vmware ...
<mdz> doko: yes
<Kamion> doko: he means the seed change, not ubuntu-meta
<infinity> doko: Ahh, yeah, the seeds look right, just your diff isn't.
<Kamion> oh
<Kamion> infinity: ship ain't in ubuntu-meta
<infinity> Oh, duh.
<infinity> I'm retarded.
<tfheen> I forgot to pre-publish sparc; I'll fix that now.
<tfheen> just -server so not too big of an issue
<BenC> tfheen: Sorry I didn't update the testing page yet, but all the stuff I was supposed to test succeeded
<BenC> I remember encountering one bug, can't remember what it was, but I remember that it was already filed
* tfheen crosses his fingers for CDIMAGE_NO_PURGE not blowing up the tree
* sivang reboots to test DVD
<poningru> mdz: ping
<sivang_live_DVD> I had my usbdisk when I booted, it got 2 usbdisk icons on the desktop
<sivang_live_DVD> a bug?
<doko> Kamion, tfheen: updated http://people.ubuntu.com/~doko/edgy/ubuntu-meta.debdiff (and checking for dch in the update script)
<heno> tfheen: which DVDs are in most pressing need of testing (so I can download wisely)? Kubuntu PPC?
<sivang_live_DVD> hmm, also, according to the instructions on testing/current, pressing F1 didn't show me the build number of the volume or so, how can I obtain it to make sure i'm testing current ?
<mdz> poningru: yes?
<tfheen> heno: those were tested successfully by BenC, but more testing is always good
<jonh_wendell> pitti, ping
<BenC> tfheen: I didn't test DVD's
<BenC> if I was supposed to, I missed it, but I wouldn't be able to anyway
<heno> the wiki says Riddell has tested them
<heno> Edubuntu looks blank though
<sivang_live_DVD> boy, ubuiguity is sweet
* sivang_live_DVD chooses manual partitoining
<keescook> is there a way to ask the live cd to use a specific X driver when it start up?
<sivang_live_DVD> I'm dropping my notes as I test at https://wiki.ubuntu.com/SivanTestingNotes?action=show
<sivang_live_DVD> could someone please xplain what does ' It's visible on the F1 help screen on i386 and amd64' mean? :)
<sivang_live_DVD> When I do this on the desktop DVD I just get yelp :)
<Kamion> doko: ok
<infinity> doko: Do you have a fix for the gcc-3.3/amd64 build failure?
<Kamion> sivang_live_DVD: f1 at boot time, not later
<sivang_live_DVD> Kamion: ah :-/
<Kamion> as in on the very first screen when you boot
<Kamion> sivang_live_DVD: just cat /cdrom/.disk/info
<sivang_live_DVD> this should be cleared on testing/current instructions, or I'm just dumb?
<Kamion> feel free to edit Testing/Current to note that it's in .disk/info on the CD/DVD
<sivang_live_DVD> cool, thanks
<Kamion> ah, I'm beginning to get a handle on the fight between console-setup and X
<sivang_live_DVD> Kamion: anyway to reach this info after you're in live ?
<Kamion> 18:13 < Kamion> sivang_live_DVD: just cat /cdrom/.disk/info
<sivang_live_DVD> Kamion: I'd have to mount it first. /media is empty for me :-/
<Kamion> so mount it ...
<sivang_live_DVD> it it by design that the cdrom is not mounted on the live session?
<tfheen> BenC: ok
<sivang_live_DVD> oh , sorry, my bad, found it.
<doko> infinity: no, didn't look yet
<infinity> doko: Fixing the ia64 failure at the same time would win you bonus points, but amd64 is the only critical bug.
<doko> infinity: it's universe ... I can do that if you look at some OOo crashes in the meantime ;-p
<infinity> doko: Err, no it's not.  gcc-3.3 is supported.
<infinity> doko: (libstdc++5)
<doko> that's crack ... :-( will have to look, yes ...
<infinity> If you're swamped with OOo stuff, I can look at gcc-3.3 tomorrow.
<infinity> Was just pinging you about it, cause it's "yours".
<infinity> I'm happy to look.  I doubt it's a difficult bug to fix.
<doko> infinity: dh_shlibdeps seems to fail? interesting ...
<doko> having that in debian/shlibs.local was needed for gcj, which isn't built anymore, so we can just remove the line
<pitti> jonh_wendell: pong
<doko> infinity: ugh, and ia64 tries a biarch build ...
<jonh_wendell> pitti, can you look at bug 65223? i've made a question there
<Ubugtu> Malone bug 65223 in mozilla-firefox-locale-all "Add pt-BR translation" [Wishlist,Fix committed]  http://launchpad.net/bugs/65223
* pitti looks
<infinity> pt-BR will be in the next update, no?
<infinity> 2.0rc3 brought it back, right?
<pitti> it will
<pitti> jonh_wendell: hm, I'm not sure how localized start pages are handled
<pitti> jonh_wendell: TBH I'd like to discuss that with iwj first
<TreMobyl> any hope on getting bug 66547 fixed before release?
<Ubugtu> Malone bug 66547 in xserver-xorg-video-ati "lockup when running glxgears" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66547
<jonh_wendell> pitti, TBH?
<pitti> jonh_wendell: to be honest
<jonh_wendell> :)
<pitti> jonh_wendell: when it comes to Firefox, I'm just the apprentice :)
<jonh_wendell> pitti, ok, i hope you'll investigate it for us!
<pitti> seb128, Riddell, everybody else: please test the candidate langpacks for final edgy! add 'deb  http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./' to your apt sources and scrutinize them
<webben> Currently, Edgy's libtotem-complex.* plugin can't handle RealAudio streaming from the BBC Radio Player. But it also seems to prevent the RealPlayer plugin handling the same (at least using the RealPlayer from the dapper-commercial repo). Would it be possible to fix totem so it doesn't do that? Or would it be necessary to fix RealPlayer instead?
<elmo> webben: already reported as a bug
<jonh_wendell> pitti, i'm going to test it. Firefox issue related to that bug doesn't enter in your rep, does it?
<pitti> jonh_wendell: no, it does
<elmo> LP 66902
<webben> elmo: ah it is... cool :)
<pitti> jonh_wendell: but I have the updated packages for testing, too
<pitti> jonh_wendell: deb http://people.ubuntu.com/~pitti/packages/firefox/ ./
<jonh_wendell> pitti, great!
<Riddell> pitti: how come language-pack-kde-fr doesn't depend on language-pack-fr ?
<pitti> Riddell: hm, we never bothered to do that
<pitti> Riddell: I can fix that for feisty if we want
<jonh_wendell> pitti, perfect! firefox in pt-br
<pitti> jonh_wendell: \o/
<Riddell> pitti: french works good for me in kde
<pitti> Riddell: tres bien!
<jonh_wendell> pitti, there is an update to firefox too, but i prefer to wait until tomorow, or when new firefox enter in edgy
<tfheen> hmm, still no xubuntu people around?
<dholbach> tfheen: crimsun might know something about Xubuntu
<jonh_wendell> pitti, can you check bug 65223 again? I've written there a "proposed patch"
<Ubugtu> Malone bug 65223 in mozilla-firefox-locale-all "Add pt-BR translation" [Wishlist,Fix committed]  http://launchpad.net/bugs/65223
<doko> ogra: ping
<pitti> jonh_wendell: I see
<pitti> jonh_wendell: this would require some hacking in debian/rules for generalizing the approach
<jonh_wendell> pitti, is it hard to do?
<pitti> jonh_wendell: not exactly hard, but a little intrusive
<pitti> jonh_wendell: if you feel like driving this forward, please open a separate bug about that (use localized start pages), ask mdz whether he's fine with that for edgy, then I'll attach the milestone flag
<jonh_wendell> pitti, ok
* ..[topic/#ubuntu-devel:tfheen] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy RC is out | Edgy is FROZEN
<jonh_wendell> pitti, that new bug should be filled against firefox package? or mozilla-firefox-locale-all?
<pitti> jonh_wendell: the latter
<doko> Kamion, tfheen: please approve  http://people.ubuntu.com/~doko/edgy/kubuntu-meta.debdiff
<tfheen> doko: tomorrow.
<Lure> Kubuntu Alternate CD (RC) fails during setting up packages - is this known problem (on LVM setup)
<doko> tfheen, ogra: does edubuntu use the same kernels as ubuntu?
<tfheen> doko: yes.
<doko> tfheen: ok, will prepare that for edubuntu as well (and I assume it's needed for xubuntu as well)
<tfheen> doko: thanks.
<slomo> tfheen: do you have some time to review the dbus fix we talked about yesterday? debdiff is here: http://slomosnail.de/~slomo/temp/dbus_0.93-0ubuntu3.debdiff
<tfheen> doko: the reason for my "tomorrow" is this has been a somewhat intensive day for me.
<tfheen> slomo: tomorrow.
<slomo> ok
<tfheen> I've been working for twelve hours trying not to fuck up the release. :-)
* Nafallo seeds desktop for i386 and amd64 now :-)
<tfheen> Nafallo: using what URL?  I get not authorized
<Nafallo> http://torrent.ubuntu.com:6969/announce
<Nafallo> but I can't see them on the tracker...
<jonh_wendell> pitti, bug 66977 filled, where is mdz?
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66977
<digger3> Hi, after switching from sysvinit --> upstart my X server won't respond to keyboard commands until I select the 'Remove login via XDMCP option', press cancel and THEN I can enter my username+password.
<digger3> BTW everything I type to my x-server appears at a root-prompt which is active at every boot when I press ALT+7
<fabbione> digger3: please file a bug in malone with details
<digger3> I am unsure which details are needed, any tips?
<fabbione> digger3: file the bug and the maintainer will ask for details
<digger3> perfect :)
<ogra> doko, what change is that ?
<digger3> hmm damn, I am getting only error id's like OOPS-292A579 when trying to register in launchpad, oh well
<Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/292A579
<Nafallo> digger3: for those OOPSES #launchpad is the place :-)
<Nafallo> launchpad != ubuntu etc...
<doko> ogra: http://people.ubuntu.com/~doko/edgy/edu.diff
<digger3> I understand
<ogra> doko, ah, thats mostly a no-op anyway (apart from the d-i module packages)
<doko> ogra: ok, preparing an upload ...
<ogra> oh, wait, that means i dont have a -386 kernel on the CD at all ?
<ogra> that doesnt work with ltsp, i need to change stuff in the kernel image selector ... 
<ogra> or is it headers only and i can keeep -386 for edgy ?
<Nafallo> hmm
<Nafallo> elmo, Znarl: you know the torrenttracker seems down I guess? otherwise I just wanted to let you know.
<Znarl> Nafallo : Yes, we are aware.
<Nafallo> goodie then :-)
<wasabi_> Under what conditions are UUIDs inserted into fstab and menu.list?
<wasabi_> My edgy system, which runs EVMS, had this happen (and basically result in /boot not being mountabl, and grub not working)... but I'm unsure on what timeframe it happened.
<wasabi_> rebooty, brb
<thiagocmartinsc> Hi!
<thiagocmartinsc> who is working on asterisk package ?!
<Burgwork> thiagocmartinsc: asterisk is in universe, so best to ask in -motu
<thiagocmartinsc> I see that's asterisk.init doesn't manage varrun correctly...
<thiagocmartinsc> Mmm..!! ok!
<thiagocmartinsc> thanks!
<Burgwork> thiagocmartinsc: if you uhave a bug, please file it
<thiagocmartinsc> my asterisk.init is right at this time.. for asterisk-1.2.12.1 ..
<doko> ogra, tfheen, Kamion: http://people.ubuntu.com/~doko/edgy/edubuntu-meta.debdiff
<slomo> infinity: ping? what about apache and apache2? ;)
<doko> Kamion, tfheen: last one: http://people.ubuntu.com/~doko/edgy/xubuntu-meta.debdiff
<doko> tfheen: last one for today: http://people.ubuntu.com/~doko/edgy/gcc-3.3.debdiff
<jonh_wendell> pitti, did you see bug 66977?
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Medium,Confirmed]  http://launchpad.net/bugs/66977
<mdke> jonh_wendell: he will see it.
<jonh_wendell> mdke, thanks
<mdke> is it possible to do a "for x in whatever; do whatever ${x}; done" phrase in a Makefile? If so, how? I've tried and it doesn't seem to like the ${x} bit
<_ion> You need to escape the $ with a $
<mdke> _ion: can you give me an example?
<pitti> tfheen: congrats for the RC release! So we are free to upload again?
<tfheen> pitti: topic still says "frozen", we're frozen for release, so please don't upload anything which shouldn't end up in the release.
<pitti> tfheen: of course
<pitti> tfheen: just things fixing milestone bugs, and firefox 2.0rc3
<tfheen> pitti: go ahead.  I won't approve a thing today though.  Exhausted now.
<pitti> tfheen: no, that's fine
<pitti> I just want to get it off my hard disk
<pitti> tfheen: you did a great job with RM!
<Nafallo> s/did/does/ :-)
* Nafallo agrees
<jonh_wendell> what's RM?
<_ion> mdke ::
<_ion>         for x in example*; do cat "$${x}" >>$@; done
<Nafallo> jonh_wendell: release management
<tfheen> pitti: thanks a lot, it's been an interesting ride.
<mdke> _ion: doesn't seem to quite work... I have "for x in website-index/*; do y=(basename $${x} website-index/); echo $${y}; xsltproc --stringparam root.filename "index.$${y}" -o $(BASE) $(INDEXCHUNKXSL) website-index/$${y}/website-index.xml;done" can you see what's wrong?
<mdke> _ion: looks like it doesn't like the (
<_ion> Do you mean y=$$(basename $${x} website-index/)?
<tfheen> mdke: you're aware that basename will strip any and all directory names off?
<mdke> _ion: I don't know whether I meant it or not, but it works, thanks :)
<_ion> Why not use the Makefile itself for what you're doing with 'for x in foo/*'?
<_ion> I.e. the Makefile syntax
<mdke> tfheen: yes, I want to strip off the directory names
<mdke> _ion: because I don't know what I'm doing? Anyhow, I'm happy it works now
<tfheen> you're missing a $
<tfheen> mdke: for x in website-index/*; do y=$(basename $$x); echo $$y ; xsltproc [...] 
<tfheen> oh, sorry, y=$$(
<tfheen> or `
<mdke> yep, _ion caught it
<mdke> thanks you guys. *hugs all*
<tfheen> oh, yeah, _ion said it too.
<tfheen> I'm clearly too tired.
<mdke> Kamion: you here?
<mdke> Kamion: emailed instead. *bed*
<thiagocmartinsc> Ubuntu must follow DFSG ?!
<seaLne> if wget is getting strange sizes when downloding the dvd images deom cdimage.u.c is it likely to be wget (on sarge) or the cdimage webserver?
<seaLne> amd: -6,754,304 ppc: -78,450,688 i386: 168,402,944
<seaLne> ^ the Length value that wget outputs while downloading
<tfheen> seaLne: your wget is broken.  Use rsync.
<tfheen> iirc
<seaLne> ok, thanks
<seaLne> rsync for cdimage never works from uni for some reason but rsync of archive is fine
<Lure> can somebody report "grep localhost /etc/hosts" on clean Edgy install (GNOME user, no KDE installed)
<Seveas> Lure, -EROOM, try #ubuntu+1
<Lure> Seveas: sorry, trying to fix RC bug
<seaLne> Lure: i don't get the hostname just the normal localhost stuff
<_ion> Room? :-)
<seaLne> assuming that was the bug you ment, on 2 machine installed from beta
<Lure> seaLne: yes, bug 66813 - you do not see it unless you have static IP and you have used knetworkconf
<Ubugtu> Malone bug 66813 in kdeadmin "kcm_knetworkconfmodule adds hostname to 127.0.0.1 line" [Critical,Confirmed]  http://launchpad.net/bugs/66813
<Lure> seaLne: just localhost (no localhost.localdomain)?
<erdalronahi> Hi all, hi doko, will the openoffice.org-l10n's be updated between RC and final?
<seaLne> Lure: both of those machine are dhcp and no knetworkconf
<seaLne> Lure: nope
<seaLne> localhost and ip6-localhost ip6-loopback
<ajmitch> morning all
<pitti> hi ajmitch 
<ajmitch> hey pitti, how's it going?
<pitti> ajmitch: pretty fine, RC is out of the door
<ajmitch> good news is that I just saw an nvidia 8776 bugfix release for their driver issue :)
<ajmitch> no crackful beta drivers needed
<erdalronahi> Maybe pitti knows whether there will be any update of the openoffice-l10n's between RC and final?
<seb128> pitti: I'm back, will try language packs now
<pitti> erdalronahi: most probably not
<pitti> seb128: *hug*
<pitti> ajmitch: thank goodness
<seb128> tfheen: do you moderate uploads for universe too? I'm looking for somebody to accept the kinoplus rebuild I've uploaded (it makes kino crash on startup atm and a rebuild seems to fix it)
<erdalronahi> pitti, but thousands of translations from Rosetta are not included.
<erdalronahi> For ku it has the upstream translations from 5 months ago
<ajmitch> seb128: any of the motu-uvf team approves them, archive admins wave them through based on that
<seb128> ajmitch: it's not an uvf, it's a rebuild
<ajmitch> seb128: I know, but the team is being reused for all uploads :)
<seb128> k
<ajmitch> I guess infinity will be the next one awake who can approve kinoplus (please do if you see this)
<seb128> ajmitch: so just tell whatever admin who wave to accept it :)
<ajmitch> seb128: just did :)
<seb128> thank you ;)
<erdalronahi> pitty, maybe it's a but, I filed bug #67003 for that
<Ubugtu> Malone bug 67003 in language-support-ku "Edgy: openoffice.org-l10n-ku is very outdated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67003
<Kamion> doko: for *-meta, please just upload and we'll review them in the unapproved queue.
<Kamion> ogra: doko's change is headers only, not images
<tfheen> seb128: nok, I don't do universe
<seb128> ok
<seb128> I've a nautilus upload coming
<Kamion> ajmitch,seb128: kinoplus accepted
<seb128> it fixes a crasher which has over 200 duplicates upstream
<seb128> trivial patch from upstream: http://cvs.gnome.org/viewcvs/nautilus/libnautilus-private/nautilus-directory.c?r1=1.260&r2=1.261&makepatch=1&diff_format=u
<seb128> is that ok?
<Kamion> tfheen: is it ok for me to wave already-approved post-RC uploads through now?
<tfheen> Kamion: I'm fine with it.
<seb128> Kamion: thank you
<tfheen> I'm not going to approve anything more tonight, though, I'm too tired.
<jonh_wendell> translators have until 24h UTC to translate?
<ajmitch> Kamion: ah thanks, didn't see you were around still :)
<erdalronahi> pitti, have the openoffice-l10n's been updated at any time with the stuff from Rosetta?
<erdalronahi> We haven't seen this for ku
<pitti> erdalronahi: yes, several times
<erdalronahi> so it *IS* a bug
<erdalronahi> bug #67003
<Ubugtu> Malone bug 67003 in language-support-ku "Edgy: openoffice.org-l10n-ku is very outdated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67003
<erdalronahi> We have not seen ANY update through Edgy
<erdalronahi> but we have 10.000 new translations in Rosetta
<MoMaT> trying to rsync the RC as described here http://tinyurl.com/yzcanx
<MoMaT> I see only the image from 2006-10-17
<MoMaT> this mirrors of daily-live hasn't been updated to RC yet or is this 2006-10-17 the RC version?
<TMM> hi
<TMM> I just read the RC is released, congratulations! :)
<TMM> but, there's a bug that I think is a large problem, also openoffice related : https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/65226
<Ubugtu> Malone bug 65226 in openoffice.org "Paste from writer to gaim in edgy segfaults writer" [Undecided,Confirmed]  
<TMM> I am hit by this bug as well, and I commented on it, if there is anything I can do to help... but, releasing with an openoffice that b0rked is going to piss off a lot of people :)
<erdalronahi> exactly, TMM
<TMM> basically the only thing that is really 'wrong' I think, I've been running edgy for about 4 weeks now, and it has been very good to me :) suspending with edgy is faster than with dapper, and, it works with aiglx ;)
<TMM> it is not just gaim too, it is any program that supports formatted text (I put that in my comment)
<erdalronahi> Our problem is somewhat bigger. There is a huge celebration planned for the "First Kurdish Linux", and if we have no translated OpenOffice.org, that will be a disaster
<TMM> if a downgrade to 2.0.3 is needed, for gods sake, do it ;)
<TMM> erdalronahi: is there a translation? 
<erdalronahi> yes, in Rosetta
<erdalronahi> and meanwhile also upstream
<TMM> not merged yet?
<TMM> in edgy?
<erdalronahi> yes
<erdalronahi> exactly
<TMM> hum, sad... I think edgy is frozen
<erdalronahi> :S
<erdalronahi> but today was also the deadline for the translations
<Kamion> MoMaT: cdimage.ubuntu.com has daily-live/20061018
<erdalronahi> I hoped there would be a merge, I had no idea there was a bug
<Kamion> which == RC
<keescook> Kamion: so we're clear to start post-RC milestone-fix uploads?
<Kamion> keescook: yes
<TMM> I sure hope edgy won't ship with this broken paste behaviour in OOo
<erdalronahi> Well, the devs may not find a translation bug release-critical
<erdalronahi> but for our team it will be a complete disaster to have 10.000 translations in Rosetta that just weren't merged into Edgy
<Kamion> erdalronahi: talk to doko when he's around
<tfheen> TMM: I can quite reasonably tell you it won't be fixed for edgy.
<erdalronahi> doko, are you around?
<Riddell> tfheen: what current procedure for uploading fixes?  upload and poke you with debdiff for approval?
<TMM> tfheen: euh... why? isn't that release critical?
<tfheen> TMM: is there a tested patch available?
<erdalronahi> tfheen, if it would be fixed some days after the release we could modify a CD
<TMM> tfheen: no, 
<tfheen> Riddell: yes, but I'm not going to review anything before tomorrow.
<tfheen> TMM: then there is no chance it'll be fixed.  Sorry.
<TMM> tfheen: downgrade to 2.0.3? openoffice is just useable at all like this. one mis-middle click and you loose your work
<Kamion> we are NOT downgrading
<Kamion> this can be fixed post-release in edgy-updates if necessary
<TMM> ok, I do not want to piss anyone off, but, why not? it is only a minor point release, but it does major damage
<Kamion> downgrading is enormously intrusive. You think it's the easy option, I gather; it's not.
<TMM> for the current testers... I understand that, deb doesn't allow for easy downgrades
<TMM> well, apt-get doesn't ?
<keescook> Riddell: for bug 66690, it looks like a version bump is needed to do the rebuild.
<Ubugtu> Malone bug 66690 in speedcrunch "FTBFS in edgy, doesn't like qt4 environment?" [High,Unconfirmed]  http://launchpad.net/bugs/66690
<Kamion> it's a sanity constraint there for very good reasons. Plus, if we can help it we're not modifying OOo at all at this point, because building it will take up a lot of valuable buildd time that frankly we need for other things. (translations are potentially a different story)
<TMM> Kamion: so, even if I spend this weekend familiarising myself with the code, and trying to fix this, there is no change it'll make it into 6.10?
<Riddell> keescook: thanks, I'll get onto that
<Kamion> by the end of this weekend, the window for post-RC uploads for final will already be closed
<TMM> this sucks
<Kamion> but if you spend the weekend familiarising yourself with the code and preparing a patch, it can be one of the first updates to edgy
<TMM> this is a pretty big deal
<keescook> Riddell: I don't have -main upload perms, otherwise I'd do it myself.  :)  let me know if you want me to prep the package and put it somewhere for you to sign/upload, though.
<TMM> Kamion: when will that be? I can guarantee that a lot of people will be pissed off
<Kamion> however, according to the bug report, pasting into many other applications works fine
<Kamion> TMM: do not try to coerce a schedule out of me for a patch that does not even exist yet
<tfheen> TMM: edgy-updates opens approximately when edgy is out.
<tfheen> maybe a week or so later.
<Riddell> shouldn't it open before?  that's what we did with dapper
<TMM> Kamion: I am not trying to do that :)
<Kamion> yes you are
<tfheen> Riddell: I don't know, I don't know if it has been decided even
<TMM> Kamion: sorry, it was not my intention, I was just trying to explain the gravity of the situation :)
<Riddell> keescook: probably easiest to just ask for it to be given back
<Kamion> you're being quite obnoxious about it, frankly
<TMM> Kamion: sorry, once again, not my intention.
<Riddell> infinity: able to give back speedcrunch?
<Kamion> we do understand that some bugs are release-critical, some are bad but not release-critical, and some need to wait
<Kamion> and we must have the freedom to decide between the two based on the constraints we're under
<Kamion> you're certainly free to try to persuade us, but ranting "this sucks" is not helpful
<TMM> Kamion: I understand, sorry.
<lamont> Riddell: I suspect that infinity is asleep
<Riddell> ah lamont, you can still do that can't you 
<Kamion> unfortunately OOo problems are very hard to fix close to release because of the enormous time it takes to build
<lamont> Riddell: I can... not sure if I'm allowed to.  but I'll check
<Kamion> almost anything else could still be countenanced if the fix were understood
<TMM> Kamion: I have the nasty habit of typing subconsious 'this sucks' kind of things in IRC when my hands are on the keyboard :)
<Kamion> please break that habit in this channel
<TMM> Kamion: I know, sorry
<tfheen> Riddell: given-back.
<Riddell> thanks tfheen 
<erdalronahi> An update for openoffice.org-l10n should not be so time consuming, right? 
<TMM> Kamion: is the OOo shipped for ubuntu build from source? or is it repackaged official binaries? I would guess 'source' just checking
<Kamion> erdalronahi: as I said above, that's potentially a different story, but needs doko)
<Kamion> TMM: every single package in main and universe is rebuilt from source
<TMM> Kamion: thought so, thanks
<Kamion> and many (but not all) in restricted and multiverse too
<TMM> Kamion: someone suggested that there might be a linker issue, I'll try with the official binaries, see if that still crashes, I kind of hope not :) 
<seb128> pitti: language packs looks fine, there is a '' to a gnome-app-install french string which looks weird but I don't think that's enough to roll new packs :)
<pitti> seb128: I can build new packs with selected manually applied corrections
<pitti> seb128: I just want to avoid a new Rosetta tarball at that point
<seb128> pitti: I've fixed the string on rosetta if you have an opportunity to import a new french po for gnome-app-install :)
<pepsiman> seb128: try grepping the translated strings for _n:
<seb128> pepsiman: ?
<pitti> seb128: can you give me a good substring for the affected string?
<pepsiman> seb128: KDE uses it for plural forms, it shouldn't appear in the translation
<pitti> seb128: I can't grep properly on rookery, locale is POSIX there
<seb128> pepsiman: is that a question you are asking me or something, I'm not sure to understand what you want
<pepsiman> seb128: there are lots of broken kde translations in en_GB, not sure about other langs
<seb128> pitti: 
<seb128> msgid ""
<seb128> "<big><b>Checking installed and available applications</b></big>\n"
<seb128> "\n"
<seb128> "Ubuntu and third party vendors offer you a large variety of applications "
<seb128> "that you can install on your system."
<seb128> pepsiman: ah, good luck with that, I don't do en_GB neither KDE
<seb128> pitti: 
<seb128> msgstr ""
<seb128> "<big><b>Vrification des applications disponibles et installes</b></big>\n"
<seb128> "\n"
<seb128> "Ubuntu et les fournisseurs tierce-partie mettent  votre disposition une "
<seb128> "large palette d'applications que vous pouvez installer sur votre ordinateur."
<seb128> 
<keescook> can someone with -main upload privs please re-sign (and upload) my fix to libx11: http://people.ubuntu.com/~kees/edgy-fixes/ (this is for bug 66776)
<Ubugtu> Malone bug 66776 in xorg-server "[edgy]  fd leak in Xinput module " [Unknown,Confirmed]  http://launchpad.net/bugs/66776
<seb128> pitti: the first line, the char before the '\n' is to drop
<seb128> keescook: looking
<pepsiman> seb128: same with german
<keescook> seb128: thanks
<seb128> pepsiman: don't do german neither ;)
<Kamion> pepsiman: perhaps you mean to be talking to pitti, not seb128; pitti is the language packs master
<pitti> seb128: fixed
<pitti> keescook: wil do
<pitti> pepsiman: will fix
<keescook> pitti: ah, thanks.  seb128 mentioned he was looking at it too...
<pepsiman> pitti: you have an easy way to fix all translations?
<pitti> grrr, /me wants a proper locale on rookery
<pitti> pepsiman: I'm a bit reluctant to do The Super Sed From Hell
<pitti> eventually this should be fixed in Rosetta itself
<tfheen> pitti: RT a request for more locales, then?
<pitti> tfheen: yeah
<pepsiman> pitti: yeah, there are several "_: " in translated strings too
<pepsiman> msgid ""
<pepsiman> "_: NAME OF TRANSLATORS\n"
<pepsiman> "Your names"
<pepsiman> msgstr ""
<pepsiman> "_: Namen der <C3><9C>bersetzer\n"
<pepsiman> "Ren<C3><A9> Fischer"
<seb128> keescook: uploaded
<pitti> ah, fine
* keescook bugs seb128
<keescook> er
<seb128> heh
* keescook hugs seb128 too
* seb128 hugs keescook back
<pitti> right, seb128, fix gnome harder!!!11!!oneeleven
* pitti hugs seb128 too
* seb128 hugs pitti too
<Seveas> pitti, fix langpacks first!!!111
* ajmitch wonders if uds-mtv will be known as the big hugfest
<TMM> Kamion: this is just a hunch, but, is it at all possible, that (since someone in that bug report mentiones he can't reproduce it) there's something wrong with my mirror? I had the new edgy artwork a while ago, but now, it has reverted back to the 'old' artwork... perhaps that's a longshot, but, I think I'll try and to a full reinstall tomorrow from the rc cd..,
<azeem> ajmitch: depends whether the "Hack while Hug" spec will be implemented in time
<MoMaT> Kamion: you're right, there is 20061018 (also pointed by current) but edgy-desktop-i386.iso is dated 2006-10-17
<Kamion> TMM: artwork was intentionally reverted
<Kamion> MoMaT: that's fine, it was carried over without being rebuilt
<TMM> Kamion: ah :) well, the release notes still show the 'new' artwork, so, that is why I thought that... 
<Kamion> the change in 20061018 was to rebuild powerpc for a fix in the livefs build script
<Kamion> TMM: the release notes should be fixed ...
<MoMaT> I see. Thx.
<TMM> Kamion: no new artwork? or just when 6.10 is released?
<Kamion> the deadline for artwork is tomorrow
<Kamion> we reverted in order to be sure to have a fallback option
<TMM> ah, ok
<TMM> well, then I won't be reinstalling :)
<TMM> well, time for bed, again
<TMM> later
<TMM> and, sorry for bugging you :) I'll see if I can make any progress
<keescook> thoughts on bug 65616? it's in universe, but it looks like it'll hold back installation of a few other universe packages.  I wrote a very small hack for it.  should I milestone that, or skip for now, given it's universeness?
<Ubugtu> Malone bug 65616 in dbconfig-common "non-pgsql packages fail to install/upgrade" [Undecided,In progress]  http://launchpad.net/bugs/65616
<ajmitch> keescook: you have a fix for it?
<ajmitch> universe is a little bit more open for uploads, since they won't break cds or the world
<keescook> ajmitch: yeah, but I'm unsure if it's the best fix.  (basically, it registers the failing debconf "add"s that were introduced)
<keescook> the upstream author didn't give me any feedback on my proposed patch, but it does fix it for me.
<ajmitch> does it cause any issues with other packages that use dbconfig-common?
<keescook> Not that I've found; I didn't try nagios-pgsql, though, which explicitly uses the pg stuff.
<Kamion> that patch is reversed, confusingly
<ajmitch> well the last message is "I'll upload asap", so I'd guess your fix is sane to upstream
<Kamion> sounds sensible to me, too
<keescook> oh, it is, how odd
<Kamion> I haven't read the code in detail but it would most certainly be able to cause the reported symptoms; and registering extra debconf templates is generally harmless
<keescook> Kamion: okay, that was basically my worry.
<keescook> I'll get it prep'd and up for people to see the debdiff.
<ajmitch> great
<TMM> whaoh... 70 meg diff for OOo
#ubuntu-devel 2006-10-20
<keescook> Kamion: permission to upload dbconfig-common?  you can see it at http://people.ubuntu.com/~kees/edgy-fixes/
<keescook> or should I be getting perm from ajmitch?
<erdalronahi> doko?
<erdalronahi> welcome
<erdalronahi> doko, we have a massive problem with the ooo-l10n, bug 67003
<Ubugtu> Malone bug 67003 in language-support-ku "Edgy: openoffice.org-l10n-ku is very outdated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67003
<erdalronahi> sorry,
<erdalronahi> doko has just left :)
<Kamion> keescook: it's fine by me, although it's probably better to talk to dholbach/ajmitch for universe in general
<Kamion> but I'd accept that if you uploaded it
<ajmitch> keescook: being a native package, it's probably better to not have -0ubuntu1 version, but rather 1.8.25ubuntu1
<Kamion> oh yeah, true
<keescook> ajmitch: oh! okay.
<ajmitch> though native packages are tricky & annoying like that
<keescook> fixing...
<Kamion> tfheen: hmm, as a consequence of investigating the console-setup vs. X fight, I think I might have figured out why console-setup doesn't work under usplash
<Kamion> though maybe not :)
<ajmitch> keescook: once version is fixed I'm happy :)
<tfheen> Kamion: tell me
<Kamion> tfheen: setupcon uses kbd_mode and loadkeys to prod the keyboard
<Kamion> tfheen: those change the mode of the current tty
<Kamion> there's a patch in kbd (which I want to steal for console-tools) that makes the console utilities try stdin (if it's a tty) before trying the current tty
<tfheen> that'd be nice
<Kamion> but as it stands, they always end up on /dev/tty or /dev/tty0 in practice
<keescook> ajmitch: uploaded with fixed version.
<Kamion> the reason X blows up is that X wants its tty to be in raw mode, and setupcon accidentally sets it to Unicode mode instead
<Kamion> another effect of the way setupcon behaves is that it doesn't (always?) manage to set all the usual ttys to Unicode mode, so you can't actually type Unicode at many of them
<Kamion> so the fix I propose is to incorporate the kbd patch above into console-tools, and change setupcon to iterate over all of $ACTIVE_CONSOLES setting kbd_mode -u on each of them, and then calling loadkeys with stdin redirected from the first active console
<ajmitch> keescook: thanks
<Kamion> I'll fire a set of patches in your direction for approval tomorrow
<keescook> ajmitch: no problemo.
<Kamion> so far I've tested that it no longer upsets X, and that it correctly sets Unicode mode on all the virtual consoles
<jonh_wendell> pitti: can we translate strings in rosetta yet?
<pitti> jonh_wendell: ...yet? you can do that for more than a year now???
<pitti> jonh_wendell: however, things you put in rosetta won't land in edgy final any more, if you need that
<jonh_wendell> pitti: oh no!
<pitti> jonh_wendell: but stuff you translate now will land in the first edgy update packs (in about a month)
<jonh_wendell> pitti: :(
<jonh_wendell> pitti: here it's 19:42, Oct 19
<pitti> johanbr: well, here it is 0:43 Oct 20, but that doesn't really matter :)
<pitti> (well, apart from the fact that I should really go to bed now)
<jonh_wendell> :)
<Nafallo> pitti: you're not alone about that ;-)
<erdalronahi> ping: doko
* Nafallo made the mistake to drink coca-cola for the first time in weeks right before bed :-P
* tfheen ponders a beer.
<Burgwork> tfheen: beer is a wonderful thing to unwind with
<tfheen> Burgwork: yeah, I know, hence my pondering.
<Nafallo> tfheen: still just pondering? :-)
<tfheen> nah, went and picked up a porter.
<Nafallo> :-)
<tfheen> I wonder if we'll be able to find decent beer in MV
<Nafallo> well... it's google. you can find _anything_ :-)
<Burgwork> tfheen: california is pretty good
<tfheen> I'm not sure they serve alcohol on-site.
<Burgwork> there are lots of people who understand that beer should be the colour of piss
<Burgwork> and taste the same
<tfheen> Burgwork: missing "not" in your sentence?
<Burgwork> tfheen: yep
<Burgwork> oops
<Burgwork> seriously, there is good microbrew in Cali
<tfheen> yeah, I just hope there's a good one close by the hotel or campus
<Burgwork> tfheen: the intersection between being a hacker and liking good beer seems be common. I suspect so
<_ion> Velkopopovick Kozel Dark 
<_ion> burgwork: I take it you know what piss tastes like? :-)
<tfheen> Burgwork: there's one a few hundred metres from google HQ at least.
<Burgwork> _ion: they unfortunately make such beer in Canada
<tfheen> Burgwork: we had some great beers in .ca too.
<tfheen> Sleeman's, iirc?
<Burgwork> tfheen: sleemans is pretty mass market. There is much better on the west coast
<tfheen> Burgwork: sleemans is absolutely decent red beer.
<tfheen> it's not excellent, but good.
<tfheen> excellent beer is hard to buy, IME.
<psusi> iirc there was a change in the newer kernels that allows scsi devices to be scanned in the background... my initrd appears to now be running the dmraid detection code before my hard disks have been found
<psusi> is there a way that initrd startup scrtips should be waiting on hardware detection to finish?  right now the script is in local-top
<tfheen> hello Matt
<tfheen> how was dinner?
<psusi> I think this same problem would break lvm disks as well
<psusi> the scripts might run before the disks have been detected
<tfheen> psusi: yes, the right way to do this is to call the discovery scripts from udev.
<tfheen> we don't do that yet
<psusi> hrm.... ahh, so you mean whenever udev detects a new disk as they are scanned, it should call the scripts to probe for lvm/dmraid?
<tfheen> yes, and evms and everything else which might be interested.
<tfheen> your SCSI drives are just a special case of "plugging in an USB drive with LVM volumes on it"
<tfheen> or a variant or whatever
<psusi> hrm.... is this something that would be considered critical and needs fixed before edgy is released?
<psusi> true...
<tfheen> no
<tfheen> it won't be fixed for edgy.
<tfheen> I'm hoping we'll get it fixed for fawn
<psusi> after the system is up and running, is it still running the original udev from the initrd or is it killed and one from the root fs started?
<psusi> also how would you avoid the race condition between hardware detection and configuration and mounting the root and switching to it?
<tfheen> you do everything from udev.
<tfheen> which is crack, but less so now that we have upstart.
<psusi> upstart?
<tfheen> yes, new init system
<tfheen> http://upstart.ubuntu.com/
<psusi> ohh?  we are moving away from classic init?
<psusi> but not to initng?
<HrdwrBoB> only months go
<tfheen> psusi: correct
<Nafallo> calm night :-(
<jdong> THUNDERSTORM!
<jdong> *rumble* *rumble*
<HrdwrBoB> ooh, tis too
<Nafallo> jdong: sounds kewl. is it like being a sourcepackage on a buildd? :-)
<jdong> Nafallo: yeah, only you don't fail on ppc/dapper-backports and work magically on ppc/edgy because autotools wants to run twice
<jdong> *grumble*
<jdong> ;-)
<Nafallo> jdong: lol
<doko_> BenC: after upgrading the amd64 kernel to the current dapper -server, I'm seeing massive problems with xfs; the third time corruption of an xfs filesystem. I can repair it with xfs_repair, however ... how can I get you more information?
<BenC> doko_: whatever dmesg out, description of the how it's corrupted, and any output you can get from the xfs recovery tools of what it found
<Nafallo> doko_: ouch. time I start converting my server to ext3?
<jdong> Nafallo: naw, hopefully it's an isolated instance
<jdong> xfs has been a good boy to me
<Nafallo> jdong: crashed for slomo as well :-/.
<Nafallo> doko should be one to many ;-)
<jdong> ok, good thing I haven't upgraded my XFS box to edgy yet then
<jdong> urr, he said it happened on dapper
<jdong> wow
<Nafallo> ouch!
<Nafallo> right
<HrdwrBoB> I am not upgrading my XFS box to edgy
<Nafallo> nafallo@ogre:~ $ mount | grep xfs | wc -l
<Nafallo> 3
<Nafallo> should be easy enough to convert :-)
* BenC just leaves xfs alone
<doko_> BenC: bug 67047, heading to my bed now ...
<Ubugtu> Malone bug 67047 in Ubuntu "xfs file system corruption" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67047
<Toadstool> 2
<Toadstool> ...
<psusi> what component is responsible for generating grub menu entries when new kernels are installed?
<psusi> every time I upgrade kernel packages, the new grub menu entry fails to load the initrd... I have to add the line myself
<infinity> psusi: update-grub autogenerates menu.lst, based on templating in menu.lst itself, and the contents of /boot
<psusi> k... I'll go kick update-grub around a bit then
<fabbione> morning
<mpt> Heh, an old spec of mine from Ubuntu Down Under has been accepted for UDS-MV
<ajmitch> mpt: wonderful, which one?
<mpt> https://launchpad.net/distros/ubuntu/+spec/topic-based-help
<mpt> Haha
<mpt> While Firefox 1.5's presentation of tabs will be made saner in 2.0, there's a High priority spec on making all tabs in Ubuntu behave like Firefox 1.5
* infinity accepts firefox and unleashes it on the world...
<infinity> ajmitch: Feel like doing some universe RMing?
<nixternal> i thought it was called the frozenferret or something now ;)
<Burgundavia> infinity: I read that rimming...
<nixternal> lol
<infinity> Burgundavia: Are all Canadians perverts, or just you and I?
<nixternal> hahahahah!!!
<Burgundavia> I think the former
<crimsun> infinity: vlc is bug 66686 (UVF exception granted)
<Ubugtu> Malone bug 66686 in vlc "[Edgy UVF exception request]  vlc_0.8.6-svn20061012.debian-1ubuntu1" [Wishlist,Fix committed]  http://launchpad.net/bugs/66686
<Burgundavia> crimsun: appropriate, given the nature of the program
<infinity> crimsun: Thanks.
<infinity> Should I be concerned that I've been rebuilding main on amd64/i386/powerpc for the last ~12 hours and nothing's failed yet?
<infinity> I'll continue being concerned about this.
<fabbione> infinity: ehehhe yeah good idea
<infinity> Success is almost always indicative of impending doom.
* poningru hands infinity half empty glass of water
<tritium> poningru: or is it half full?
<mpt> grumble
<mpt> I entered "rsync -vPz rsync://cdimage.ubuntu.com/cdimage/daily-live/current/*i386.iso"
<mpt> sent 120 bytes  received 80 bytes  23.53 bytes/sec
<mpt> and ended up with nothing
<mpt> sfllaw, what did I do wrong?
<minghua> mpt: I think you need to specify the destination
<sfllaw> mpt: Yeah.  Otherwise, you just get a file listing.
<sfllaw> Did I make a typo in my e-mail?
<minghua> sfllaw: yes
<sfllaw> Dang.
<sfllaw> rsync --dry-run -vPz rsync://cdimage.ubuntu.com/cdimage/daily-live/current/*i386.iso .
<minghua> sfllaw: I had the same confusion as mpt yesterday after trying the commands in your url
<mpt> ahhh, thank you
<sfllaw> That fullstop at the end is important.
<sfllaw> And obviously missing.
<mpt> obviously to you, perhaps :-P
<mpt> That was rather unhelpful feedback from rsync, anyway.
<ajmitch> infinity: what do you have for me?
<infinity> ajmitch:
<infinity>   110537 | S- | tulip                | 2.0.5-2ubuntu1       | 2 hours 30 minutes
<infinity>          | * tulip/2.0.5-2ubuntu1 Component: universe Section: graphics
<infinity>   110536 | S- | brasero              | 0.4.4-0ubuntu2       | 3 hours 40 minutes
<infinity>          | * brasero/0.4.4-0ubuntu2 Component: universe Section: gnome
<infinity>   110505 | S- | gajim                | 0.10.1-0ubuntu5      | 5 hours 50 minutes
<infinity>          | * gajim/0.10.1-0ubuntu5 Component: universe Section: net
<infinity>   110504 | S- | gajim                | 0.10.1-0ubuntu5      | 5 hours 50 minutes
<infinity>          | * gajim/0.10.1-0ubuntu5 Component: universe Section: net
<infinity>   110503 | S- | dbconfig-common      | 1.8.25ubuntu1        | six hours
<infinity>          | * dbconfig-common/1.8.25ubuntu1 Component: universe Section: admin
<infinity>   110245 | S- | mpd                  | 0.12.1-1ubuntu1      | 20 hours
<infinity>          | * mpd/0.12.1-1ubuntu1 Component: universe Section: sound
<infinity>   110197 | S- | weather-util         | 1.2-1ubuntu1         | 42 hours
<infinity>          | * weather-util/1.2-1ubuntu1 Component: universe Section: utils
<infinity>   110176 | S- | thoggen              | 0.6.0-2ubuntu1       | 43 hours
<infinity>          | * thoggen/0.6.0-2ubuntu1 Component: universe Section: graphics
<infinity>   110175 | S- | libipoddevice        | 0.5.1-0ubuntu1       | 43 hours
<infinity>          | * libipoddevice/0.5.1-0ubuntu1 Component: universe Section: libs
<infinity>   110070 | S- | pysvn                | 1.4.2+dfsg-0.1ubuntu | three days
<infinity>          | * pysvn/1.4.2+dfsg-0.1ubuntu2 Component: universe Section: python
<infinity>   110049 | S- | pycxx                | 5.3.5+5.3.6-0ubuntu1 | three days
<infinity>          | * pycxx/5.3.5+5.3.6-0ubuntu1 Component: universe Section: python
<ajmitch> approve mpd, dbconfig-common, gajim, thoggen, brasero, libipoddevice - I know of those ones already
<ajmitch> what are the pysvn & pycxx changes?
<ajmitch> tulip can go through as well
<ajmitch> ok, pysvn & pycxx are done by doko, they can go through
<infinity> Hrm, I wonder which gajim I should accept and which I should reject.
<ajmitch> they look like they were uploaded at the same time, same version
<infinity> Yeah. I'll grab them from the queue and see if they're different in any way.
<ajmitch> just weather-util to check, one min
<ajmitch> weather-util can be approved as well
<infinity> ajmitch: Looks like one has .bzr junk in it and the other doesn't..
<infinity> Not sure which was the intention, though.
<ajmitch> nafallo has gone off to sleep
<infinity> Hrm, I'll debdiff to the previous version and see which has less cruft/change. :)
<ajmitch> ok :)
<o_cee> hmm, guess f-spot won't be updated until after the release of edgy?
<ajmitch> correct
<ajmitch> edgy-updates may get some fixes backported to 0.2.1
<ajmitch> feisty will get 0.2.2 & beyond
<grexk> can somebody help with ldap auth with edgy?
<grexk> I have this already working with dapper. But when I upgrade it doesn't boot anymore
<ajmitch> grexk: this isn't the right channel for help, but try & put 'bind_policy soft' in /etc/libnss-ldap.conf
<grexk> thanks
<o_cee> ajmitch: that's too bad, the one major feature f-spot has been missing has finally (2 years later) been added.. ah well..
<ajmitch> o_cee: yeah, well we freeze for a reason
<o_cee> ajmitch: hehe yeah :)
<ajmitch> there's always "one last thing" that'd be nice to have in a release
<ajmitch> be glad that feisty is only 6 months away :)
<sfllaw> BenC: Have you made any headway on installation testing?
<ajmitch> hey sfllaw 
<sfllaw> ajmitch: Sup?
<ajmitch> friday night, relaxing with some ubuntu :)
<sfllaw> Neato.
<sfllaw> Ever feel the urge to do installation testing?
<slomo> doko_: http://oss.sgi.com/projects/xfs/faq.html#dir2 <--- this xfs corruption?
<sfllaw> ;)
<ajmitch> sfllaw: I would but I'm well over my monthly data cap already
<sfllaw> Fair enough.
<sfllaw> I don't have a monthly data cap.
<ajmitch> I can do some in 3 days when the month starts again :)
<highvoltage> ajmitch: where in the world is it friday night already?
<ajmitch> new zealand
<infinity> Yeah, it's nearly quittin/weekend time for me too.
<infinity> I guess there's something to be said for living in the future.
<highvoltage> heh
<sfllaw> infinity: Yay for the future!
<sfllaw> infinity: Tomorrow, could you devote some background time to doing a few test installs?
<sfllaw> I know you can't do PPC, but maybe you could spot in for some of the ones others haven't been able to do.
<infinity> sfllaw: I can clean up random i386 slots, yeah.
<sfllaw> infinity: Thanks!
<infinity> sfllaw: My hardware has otherwise dwindled recently, which is teh suck.
<sfllaw> infinity: I know.
<infinity> I wonder if I could get Canonical to spot me the other 50% of the Quad-core G5 that IBM wants to sell me for 50% off..
<sfllaw> infinity: You should ask.
<infinity> Seems unlikely. :)
<sfllaw> Well, you can't fault a boy for asking.
<infinity> I suspect someone will point out that I get a salary.
<infinity> And me pointing out that I spend that salary on rent on two apartments right now isn't likelt to garner much sympathy. :)
<sfllaw> Hmm.
<ajmitch> 'work-related expense'
<infinity> Then again, the G5 costs less than flying me to any conference.  Yay for living in the middle of nowhere.
<infinity> (Well, the global middle of nowhere anyway)
<Fujitsu> infinity, it is unfortunate, yes... But ajmitch is really in a worse place :P
<jdub> ajmitch is getting cheaper flights to sydney than the perthies
<infinity> Not really, Air New Zealand has plenty of international flights.
<infinity> In fact, my UDS-MV flights are Air New Zealand.
<ajmitch> infinity: interesting, what day?
<infinity> ajmitch: Flight NZ8 from Auckland, Nov 4th at 20:15
<ajmitch> I may see you on it then
<infinity> mpt is on the same flight too, I believe.
<ajmitch> NZ7 on the 11th returning to NZ for me
<infinity> Yeah, I'm there another week, so those won't match up. :)
<infinity> Though I am on NZ7 coming back.  Just a week after you.
<infinity> I assume NZ8 and NZ7 are the only Auckland<->SFO flights.
<ajmitch> probably
<infinity> Ahh well, it should be fun to be surrounded by people who can't pronounce the word "fish" while I'm stopped over.
<infinity> :P
<ajmitch> you've been living in Australia far too long
<infinity> This is probably true.
<infinity> Three years here has ruined me.  I now want a bright orange ute, wear footy shirts, and drink excessively.
<infinity> Some of the above may have been lies.
<sfllaw> Yeah, the drinking.
<Fujitsu> How long have you been here, infinity?
<infinity> Though, not the drinking sadly. :/  I've drank far more since moving here than I ever did before.
<infinity> Fujitsu: 3 years, pretty much on the nose.
<Fujitsu> Where were you previously?
<infinity> Canada.
<Fujitsu> Aha! I'm also from Canada, but I've been here...
<Fujitsu> 10 years now.
<sfllaw> Traitors!
<sfllaw> ;)
<infinity> Yeah, I think we've had this conversation before. :)
<Fujitsu> Yeah, I think we have.
<infinity> Well, without the interjection from sfllaw;.
<sfllaw> Doesn't change a thing.
* Fujitsu is confused.
<Fujitsu> Too many people.
<Fujitsu> Too much to remember :S
<sfllaw> I know what you mean.
* Hobbsee holds Fujitsu's brain behind her
<sfllaw> Hobbsee!
<ajmitch> hello Hobbsee 
* Fujitsu attempts to greet Hobbsee, but notes that his brain is disconnected.
<Burgundavia> infinity: you have clear come unhinged down under
<Hobbsee> sfllaw!!!
<Hobbsee> hey ajmitch 
* Hobbsee watches Fujitsu's pathetic attempt
<Fujitsu> Cruel, cruel Hobbsee.
<Hobbsee> Fujitsu: indeed.
<Hobbsee> Fujitsu: have you only just learned this?
* Hobbsee gives Fujitsu's brain back
<Hobbsee> ajmitch learned this a long time ago
* ajmitch has the wounds to prove it
<ajmitch> Hobbsee: you'd better have some fixes for universe to upload
<elkbuntu> Burgundavia, you're only jealous we steal all your people :
<Hobbsee> ajmitch: why?
<ajmitch> Hobbsee: because there's only a few days to get things fixed
<Hobbsee> ajmitch: i got one done yesterday!
<ajmitch> well done
<Burgundavia> elkbuntu: you only steal the crazy ones, so it is ok
<ajmitch> now get some more done :)
<Hobbsee> ajmitch: it was a sync request.
<Hobbsee> ajmitch: have you ack'd it yet?
<elkbuntu> Burgundavia, that must mean you are next on our list then...
<Burgundavia> elkbuntu: nah, my brother is at least a few people ahead of me
<ajmitch> Hobbsee: did you ever ask anyone about it?
<Hobbsee> ajmitch: on second thoughts, i dont need to.
<ajmitch> good
<ajmitch> hey pitti 
<Hobbsee> hi pitti 
<imbrandon> moins pitti
<Fujitsu> Evening, pitti.
<pitti> Good morning
<pitti> hi ajmitch 
* pitti waves
<janimo> Kamion: the latest Xubuntu daily builds are good for RC
<pitti> carlos: for the edgy langpacks I just applied some sed hackery to get rid of all those  signs
<carlos> Oh, right!
<carlos> I forgot that one!!!
<pitti> carlos: but eventually this should be fixed in Rosetta proper
<carlos> well, new ones will not appear, we are using an image now
<pitti> carlos: this might require some special hacks, like if msgid does not contain  then all those should be removed from msgstr
<carlos> I should prepare a migration script to remove them
<pitti> yup, I could only do the blunt way now
<carlos> yeah, I already did some migrations like that one, don't worry ;-)
<pitti> but it should be good enough, I doubt that there are many msgid's with '' around
<pygi> morning all
<pitti> I grepped for 'msgid.*' and didn't find anything, but that doesn't cover this char in the second and further line
<pitti> hi pygi 
<pitti> jvw: hi Jeroen
<jvw> pitti: hey :)
<carlos> pitti: the database will give us much more flexibility on that, don't worry
<pitti> carlos: right
<pitti> carlos: I just assumed that we can't do that and roll a new tarball in the next few hours
<carlos> hmmm
<carlos> define 'next few hours'
<pitti> few == 2 or so
<pitti> well, up to 4 would be okay, too, I guess
<carlos> the problem is that I should leave to the bank right now
<pitti> carlos: but I would like to avoid importing a new tarball
<carlos> 2 is not possible, but 4 is doable, yes
<pitti> we are testing the current langpacks, and I want to stabilize on them
<pitti> carlos: don't worry, take your time; I think I'll just take the current ones
<carlos> anyway, your scripts fixed the issue, right?
<pitti> right
<carlos> I will request the run on production today, so we don't forget to do it
<carlos> and get any update already fixed
<pitti> carlos: would be nice for dapper and breezy, too
<pitti> hi jono
<carlos> pitti: it will be for the whole database
<jono> hey
<pitti> moin Seveas 
<Seveas> hi 
<pepsiman> pitti: you can use msggrep to search for 
<pitti> pepsiman: indeed; but what I would have really needed was msgsed or so :)
<pepsiman> pitti: msgfilter
<pitti> nice
<pitti> pepsiman: thanks
<Kamion> janimo: tfheen's the RM at the moment
<dholbach> good morning
<disturboresiduo> how ican upgrade my ubuntu from cd and with terminal?
<fdoving> disturboresiduo: that's a question for #ubuntu
<pitti> tfheen: ok to fix bug 66977 for edgy? it's a regression from dapper and has an easy fix (I just added the patch)
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Medium,Fix committed]  http://launchpad.net/bugs/66977
<disturboresiduo> excureme
<pitti> disturboresiduo: -> #ubuntu please
<disturboresiduo> excureme
<disturboresiduo> join #ubuntu
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/console-tools.diff - as discussed last night, prerequisite for console-setup fix
<tfheen> Kamion: and open_a_console returns -1 if it's not a tty?
<tfheen> Kamion: if so, approved.
<Kamion> tfheen: correct (or if it can't open it at all)
<slomo> tfheen: http://slomosnail.de/~slomo/temp/dbus_0.93-0ubuntu3.debdiff <--- fine with you to upload? :)
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/vim.multibyte.diff - fixes vim-tiny lack of multibyte support mentioned the other day
<tfheen> pitti: why does it have a print statement there?
<pitti> tfheen: I just noticed, I'm currently fixing it harder
<pitti> tfheen: still, do you think we should fix that for edgy?
<tfheen> slomo: tested it this time? :-)
<tfheen> pitti: yes, I think we can and should.
<pitti> ok
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/yaboot-installer.diff - fixes ubiquity breakage with multiple bootstrap partitions
<pitti> tfheen: it's not that easy to append something in a perl -pi script, I'll tinker a bit
<tfheen> Kamion: we need nls and multilang too for vim?
<slomo> tfheen: yes
<tfheen> pitti: I speak perl fairly fluently, if you can wait until I'm more awake, I can fix it.
<tfheen> (I woke up fifteen minutes ago)
<pitti> tfheen: I'll come back to that offer if I run out of ideas :)
<pitti> tfheen: (Good morning, BTW)
<tfheen> Kamion: vim looks good to me; I presume the size hit isn't too bad?
<tfheen> good morning to you too. :-)
<slomo> hm, bbl... tfheen, just tell me when it's fine to upload, i'll upload it later then
<tfheen> Kamion: yaboot-installer is good.
<Kamion> tfheen: nls is actually the default (just needed to kill --disable-nls) and multi_lang is implied by --with-features=big
<tfheen> Kamion: I was wondering if we needed multilang for multibyte support; I presume -tiny isn't built with --features=big?
<Kamion> -tiny uses --with-features=small
<Kamion> I took multilang because that was what the Debian change did
<tfheen> ok, let's do the same, then
<Kamion> it's not clear it's strictly required for multibyte support
<Kamion> oh, it might be needed for automatic encoding detection from the locale, possibly
<Kamion> it enables :language
<tfheen> ok, vim approved.
<tfheen> slomo: dbus looks good to me; approved.
<Kamion> makes vim-tiny 49KB bigger here
<tfheen> acceptable, IMO
<Kamion> yeah
<mjg59> mvo: acpi is a small program that prints battery information. You almost certainly don't want to assign bugs to it.
<mvo> mjg59: sorry, which one is the correct? acpi-support? something else?
<Kamion> tfheen: I don't think bug 66883 is RC. What about you?
<Ubugtu> Malone bug 66883 in cdebconf "Codeset selection dialog has poor layout" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66883
<mjg59> mvo: Almost certainly X
<mjg59> In that specific case
<janimo> tfheen: the last Xubuntu daylies are good to be released as RC
<Kamion> it's probably an off-by-N in cdebconf's newt frontend somewhere
<tfheen> Kamion: I'm inclined to treat almost all expert-mode bugs as not-rc.
<tfheen> Kamion: and in this case, it's not RC, no.
<pitti> tfheen: patch for bug 66977 updated, works fine now
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Medium,Fix committed]  http://launchpad.net/bugs/66977
<Kamion> right, dropped
<Kamion> it might show up in some locales that aren't in console-setup's enormous list
<Kamion> but I'm fairly sure that has at least nearly everything we care about
<pitti> tfheen: I wanted to avoid nasty hacks with -pi, so I changed the script to run without -pi
<Kamion> somebody in the usplash cabal needs to look at bug 64171 again today
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
<Kamion> I haven't figured out exactly what Seveas meant
<Seveas> Kamion, every function that uses the svgalib gl functions will display wrong colors (blue-black)
<Seveas> that's usplash_clear and usplash_text
<Kamion> Seveas: do you know where the bug is? I had a quick look through those functions and didn't notice obvious signed char breakage
<Seveas> well, it started when usplash started to use 16bit-color svga modes
<Kamion> mvo: have you started on hacking around live CD breakage in launchpad-integration? bug 60071
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Medium,Confirmed]  http://launchpad.net/bugs/60071
<Seveas> so I assume the palette needs to be adjusted for that
<Seveas> haven't found out how/what/where though (svgalib is not the best documnted piece of software)
<mvo> Kamion: no, I haven't
<mvo> Kamion: I can have a look now
<Kamion> the palette is unsigned char
<Kamion> does that need to be changed?
<Kamion> (bogl/pngtobogl.c
<Kamion> )
<Kamion> would need some care in the bogl backend too
<Seveas> it should not be changed in there
<Seveas> but in usplash_svga.c
<Seveas> the palette already has to be mangled, it just needs an updated mangling
<tfheen> infinity: can you give me a listing of the unapproved queue for main, please?
<infinity> yessir.
<Kamion> I am massively confused by that / 4 in usplash_svga_set_palette
<infinity>   110502 | S- | kdeadmin             | 4:3.5.5-0ubuntu2     | 11 hours
<infinity>          | * kdeadmin/4:3.5.5-0ubuntu2 Component: main Section: utils
<infinity>   110500 | S- | libx11               | 2:1.0.3-0ubuntu4     | 11 hours
<infinity>          | * libx11/2:1.0.3-0ubuntu4 Component: main Section: x11
<infinity>   110499 | S- | ubuntu-docs          | 6.10.3               | 11 hours
<infinity>          | * ubuntu-docs/6.10.3 Component: main Section: text
<infinity>   110489 | S- | nautilus             | 2.16.1-0ubuntu3      | 12 hours
<infinity>          | * nautilus/2.16.1-0ubuntu3 Component: main Section: gnome
<infinity>   110251 | S- | edgy-gdm-themes      | 0.7-0ubuntu1         | 15 hours
<infinity>          | * edgy-gdm-themes/0.7-0ubuntu1 Component: main Section: x11
<Bernardo> good morning
<Kamion> what the heck is that about?
<infinity>   110249 | S- | edgy-community-wallp | 0.4-0ubuntu1         | 15 hours
<Seveas> Kamion, svga_gl expects integers in the range 0..63
<infinity>          | * edgy-community-wallpapers/0.4-0ubuntu1 Component: main Section: x11
<infinity>   110248 | S- | edgy-wallpapers      | 0.7-0ubuntu1         | 16 hours
<infinity>          | * edgy-wallpapers/0.7-0ubuntu1 Component: main Section: x11
<infinity>   110247 | S- | grub                 | 0.97-11ubuntu14      | 20 hours
<infinity>          | * grub/0.97-11ubuntu14 Component: main Section: admin
<Seveas> Kamion, I already tried without the /= 4, doesn'twork
<infinity>   110077 | S- | python-setuptools    | 0.6c3-1ubuntu4       | three days
<infinity>          | * python-setuptools/0.6c3-1ubuntu4 Component: main Section: python
<infinity>   110068 | S- | xfdesktop4           | 4.3.99.1svn+r23428-0 | three days
<infinity>          | * xfdesktop4/4.3.99.1svn+r23428-0ubuntu2 Component: main Section: x11
<infinity>   110050 | S- | human-cursors-theme  | 0.4-0ubuntu1         | three days
<infinity>          | * human-cursors-theme/0.4-0ubuntu1 Component: main Section: x11
<infinity> tfheen: DoI still have carte-blanche for well-isolated FTBFS uploads?
<tfheen> infinity: I'd like you to at least tell me about them, but yeah, if they're easy, I'm fine with them
<Bernardo> good morning
<infinity> Oh, for the love of... memtest is FTBFS on amd64 too.  Gnar.
<tfheen> infinity: -wallpapers is approved, , edgy-gdm-themes is approved, ubuntu-docs is approved.
<infinity> That'll teach me to do rapid-fire fixes before waiting for all of autotest to finish.
<tfheen> infinity: libx11 is a fd leak fix by Kees (sponsored by somebody)?
<Kamion> er, d'oh, meant to fetch libx11, ran accept libx11 instead
<Kamion> let's hope it's ok
<infinity> Oops. :)
* Kamion fetches it for post-mortem
<infinity>    * SECURITY UPDATE: file descriptor opened from environment variable
<infinity>      leaked, allowing elevated read access to files.
<infinity>    * Add 'debian/patches/018_ximcp_double_open.diff' to stop a file descriptor
<infinity>      leak in the ximcp module.
<infinity>    * References
<infinity>      https://launchpad.net/distros/ubuntu/+source/libx11/+bug/66776
<Ubugtu> Malone bug 66776 in xorg-server "[edgy]  fd leak in Xinput module " [Unknown,Confirmed]  
<infinity>      CVE-2006-5397
<tfheen> yes, that's the one.
<infinity> Looks fine frm the changelog, anyway.
<dholbach> mdz acked human-cursors-theme for post-rc
<pitti> Kamion: I reviewed and checked libx11 patch, that was fine
<Kamion> +-    fp = _XFopenFile (name, "r");
<Kamion> +     if (! (fp = _XFopenFile (name, "r"))) {
<Kamion> looks kinda sane to me ...
<tfheen> infinity: the nautilus one is from Seb with http://cvs.gnome.org/viewcvs/nautilus/libnautilus-private/nautilus-directory.c?r1=1.260&r2=1.261&makepatch=1&diff_format=u as the change?
<infinity> The changelog claims so, do you want me to debdiff it?
* infinity can't wait for diff support in the queue...
<tfheen> no, I'm fine with it.  Seb and I talked about it last night and I trust him enough that he won't sneak in other fixes.
<Kamion> we could write a small script to debdiff a given queue id, y'know ...
<infinity> Kamion: Well, it's the "fetch the previous version" bit that makes it more than a 2-minute fix, unless you speak soyuz.
<Kamion> I've done most of that for backports already
<infinity> Ahh, cool.
<infinity> tfheen: Diffed it anyway, it's sane.  Accepting.
<infinity> tfheen: Does janimo still have approval to upload random xfce stuff?
<tfheen> infinity: as long as it doesn't touch anything else, yes.
<infinity> Yeahp, xfdesktop should be fine, then.
<tfheen> I have no idea about kdeadmin; I think I approved python-setuptools, but three days is a long time
<infinity>  python-setuptools (0.6c3-1ubuntu4) edgy; urgency=low
<infinity>  .
<infinity>    * Use unversioned interpreter for easy_install.
<infinity>    * Depend on python-dev instead of python.
<infinity>    * Suggest python2.5-dev.
<infinity> Sound familiar?
<tfheen> oh, that, approved.
<infinity>  kdeadmin (4:3.5.5-0ubuntu2) edgy; urgency=low
<infinity>  .
<infinity>    * kubuntu_10_knetworkconf_localhost.diff added, hostname should not
<infinity>      be appended as alias to localhost in /etc/hosts
<infinity>      Closes Malone #66813
<Ubugtu> Malone bug 66813 in kdeadmin "kcm_knetworkconfmodule adds hostname to 127.0.0.1 line" [Critical,Fix committed]  http://launchpad.net/bugs/66813
<seb128> what happened to my nautilus upload from yesterday? ;)
<infinity> seb128: I just accepted it.
<seb128> cool, thank you
<infinity>  grub (0.97-11ubuntu14) edgy; urgency=low
<infinity>  .
<infinity>    * s/single-user/recovery/, revert Debian #370110.  Ubuntu: #62600.
<Ubugtu> Debian bug 370110 in grub "please s/recovery/single-user/ in generated menu.lst" [Wishlist,Closed]  http://bugs.debian.org/370110
<Kamion> that's wrong, I mailed Scott
<Kamion> missing )
<Kamion> (grub)
<seb128> is the splash screen supposed to look like that on amd64: http://people.ubuntu.com/~seb128/boot.jpg ?
<infinity> dholbach: Do you want ajmitch to approve your glom upload, or are you happy being both uploader and approver?
<seb128> and note the text in the bottom left corner (it's barely readeable), that's from the "check CD" mode
<dholbach> infinity: I'm happy with that. :-)
<pitti> hm, shall I look into bug 60071?
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Medium,Confirmed]  http://launchpad.net/bugs/60071
<Kamion> seb128: I think that's bug 64171; see the discussion between me and Seveas above
<pitti> or does anyone want to take this who is familiar with lp-i?
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
<Kamion> pitti: mvo said he was looking at that
<pitti> ah, nice
<mvo> pitti: I set it to in progress now
<Seveas> Kamion, no, that bug is "I have no amd64 so cannot check palette colors" -- amd64 uses bogl and not svgalib
<pitti> mvo: assignment to you is good, then it disappears from the 'unassigned edgy blockers' list; thanks
<Seveas> fschoep should be aware of that
<Kamion> Seveas: oh, right, hmm
<Kamion> Seveas: if you describe that a bit more verbosely to me, I can probably take care of it
<Kamion> I have both amd64 and powerpc
<infinity> Seveas: If you boot with vga=<whatever> on the command line, you'll get a vesa fb, and the bogl backend, no?
<Seveas> Kamion, if the new theme has been uploaded (fschoep now has it), someone with an amd64 needs to check the colors in th 640x400 theme and makesure they are readable. COlors are simply palette entries.
<Seveas> infinity, -ENOCLUE, mjg59 does the difficult things
<infinity> Seveas: I'm pretty sure that's meant to work right now.
<pitti> ok, if anyone wants me to work on an urgent bug fix today, please tell me; otherwise I'll look into spec writing and some less urgent matters
<infinity> pitti: You have an amd64 box, yes?
<pitti> infinity: yes
<Kamion> infinity: er, you will? only one backend can be built into usplash at compile time, AFAIK
<infinity> pitti: Want to check the header confusion that's making memtest86 FTBFS on amd64, so I don't have to debug it over a slow link?
<Kamion> oh, no, that's been fixed
<infinity> pitti: Should be a 2-minute fix, then I'm done with you. :)
<seb128_> re
<pitti> infinity: of course
<seb128_> <seb128> Kamion: in my case it's on amd64 and that looks like non-svga, no?
<seb128_> --- Disconnected ().
<seb128_> Kamion: dunno if you get that, if you replied something please say it again
<Kamion> seb128_: 10:38 < Seveas> Kamion, no, that bug is "I have no amd64 so cannot check palette colors" -- amd64 uses bogl and not svgalib
<infinity> pitti: If I see anymore gettext/autotools failures during this current autotest, I may assign those to you too, since you seem to know what the problem and the fix are, but feel free to bounce them.
<infinity> pitti: I've not seen any yet anyway, so it may be moot.
<infinity> Kamion: Want to reject grub, so no one accidentally accepts it later?
<infinity> Also, we really need tracking on the queue tool.  The fact that we all use one user account and there's no auditing is really crap. :/
<Kamion> infinity: done
<janimo> tfheen: can you please publish the last builds frozen before RC as the RC images for xubuntu? thanks
<Kamion> yes
<Kamion> I've suggested multiple possible fixes to the Soyuz team but apparently they're all too functional or something
<pitti> infinity: sounds good to me
<infinity> Kamion: *smirk*
<pitti> infinity: yes, testing them all would be appreciated
<tfheen> janimo: yes, once I have had breakfast, and gone through this morning's email.
<infinity> Kamion: Well, this may fall under the more general "soyuz privsep" BoF I intend to have with elmo, malcc, cprov, and me.
<Kamion> almost missed bug 66895; targetted
<Ubugtu> Malone bug 66895 in partman-base "Ubiquity disappears if you have multiple disks and the last disk is empty" [High,Confirmed]  http://launchpad.net/bugs/66895
* infinity makes a mental note to register that.
<Kamion> fix should be easy, just needs me to set up a test environment
<Kamion> speaking of breakfast, I have to go and buy breakfast cereal before I starve to death. Back in a bit.
<infinity> Hrm, breakfast indeed.  I think I'll order a pizza.
<infinity> (See, there are advantages to keeping weird work hours)
<infinity> Though very few, I'll admit.
<tfheen> infinity: you get to hang out with us on IRC, that's gotta count for something
<infinity> I refuse to comment on the grounds that I may lose what friends I have left. :P
<infinity> Oh look, a cdrom-checker upload.
<infinity> tfheen: Is that as ugly and wrong as it sounds? :/
<pitti> infinity: according to the GccSsp page you already fixed memtest86+ to build without SSP
<pitti> infinity: however, that version doesn't seem to be in the archive yet
<infinity> pitti: Yes, I did.  You're looking at the wrong source.
<infinity> pitti: That version's in the archive, and fails to build on amd64.
<infinity> https://launchpad.net/distros/ubuntu/+source/memtest86+/1.65-1ubuntu1
<pitti> memtest86+ |     1.65-1 | http://archive.ubuntu.com edgy/main Packages
<infinity> (Grab the sources there, if your mirror hates you)
<pitti> infinity: ah, great
<infinity> Oh, hrm, it might just be missing a build-dep on libc6-dev-i386
<pitti> infinity: it is
<pitti> uploading fix now
<infinity> But, yeah, I can't really test easily on this slow-as-crap link, so go nuts. :)
<pitti> -Build-Depends: debhelper (>> 3.0.0), dh-buildinfo
<pitti> +Build-Depends: debhelper (>> 3.0.0), dh-buildinfo, libc6-dev-i386 [amd64] 
<pitti> tfheen: ^ ok to upload new memtest86+ with that?
<infinity> Is there an appropriately sarcastic changelog entry to go with it?
<infinity> I won't accept it without sarcasm.
<pitti> I was very uncreative
<pitti> * Add libc6-dev-i386 build dependency on amd64 to fix FTBFS.
<infinity> You are so not fun during release crunch. :P
<infinity> (looks all good to me, though)
<pitti> what about ' * We only need half the stub bits on amd64'?
<pitti> (nevermind)
<stub> Argh!
<pitti> stub: sorry :)
<pitti> infinity: uploaded
<infinity> I don't imagine stub's very happy about thinking of "half his bits".
* pitti grabs some bioglue and gives stub all his important bits back
<pitti> oops
* pitti looks on the glue tube again and reads the small text, too
<pitti> hi jdthood 
<infinity> "May cause irritation and TCP timeouts"?
<jdthood> pitti: Ahoy there
<pitti> seems the price tag stuck on the 'hazard' word after the 'bio'
<slomo> tfheen: ok, uploaded... thanks
<infinity> tfheen: Filthy hack in cdrom-checker reviewed and accepted.
<infinity> slomo: Was tha dbus upload I just saw what you were talking to tfheen about earlier (and he approved)?
<slomo> infinity: yes
<infinity> slomo: Great, thanks, accepted then.
<mvo> tfheen: can you please review the debdiff for bug 60071 ? its here http://librarian.launchpad.net/4894918/launchpad-integration_0.1.4.2.debdiff . this is build from the bzr repository, if you prefer I can do a version that just adds a patch to the current package into debian/patches (that will avoid the autofoo stuff in the diff)
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Medium,In progress]  http://launchpad.net/bugs/60071
<tfheen> pitti: approved.
<tfheen> mvo: I'd prefer something where you just patch the source like a classic debian package.
<tfheen> Kamion: we need a new d-i upload for cdrom-checker, don't we?
<doko_> tfheen: some cleanup from yesterday ...
<mvo> tfheen: http://librarian.launchpad.net/4894937/launchpad-integration_0.1.4.2.debdiff
<doko_> tfheen: http://people.ubuntu.com/~doko/edgy/gcc-3.3.debdiff
<doko_> tfheen: http://people.ubuntu.com/~doko/edgy/python-central.debdiff
<infinity> pitti: http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt
<tfheen> mvo: we already had a dirty fix in there for the live CD?  EW.
<tfheen> mvo: but ok, looks good to me.
<infinity> pitti: Specifically, the m-f-l-xh out-of-date.
<infinity> pitti: Did we drop a local without an upgrade path?
<mvo> tfheen: yes, but the prefix changed :(
<pitti> infinity: seems so
<pitti> infinity: I'll add a transitional package
<infinity> Am I the only one who's curious how you're shoving random diffs into the librarian?
<infinity> I clearly missed a "librarian as pastebin" BoF.
<tfheen> infinity: he attaches them to a bug report.
<infinity> Oh, that would do it. :)
<infinity> Not really thikning straight, I guess. :)
<pepsiman> which bug is the pastebin?
<tfheen> pepsiman: none
<infinity> pepsiman: None.
<pepsiman> I know, just a joke
<infinity> tfheen: Was just subtly pointing out that I'm a moron.
<infinity> s/thfeen: W/tfheen w/
<tfheen> doko_: gcc-3.3 looks good to me; you've tested that it builds on all arches now?
<tfheen> doko_: doesn't the python-central change fix any bugs?
<Kamion> tfheen: yeah, but I need to do one anyway
<doko_> tfheen: didn't check powerpc and sparc again, just i386 and amd64
<Kamion> tfheen: I'm just waiting until I'm sure that I've caught everything else
<Kamion> and specifically I need to upload console-setup first
<tfheen> Kamion: just making sure we don't miss it.
<Kamion> tfheen: yeah, don't worry, "upload d-i and ubiquity" is firmly etched in the middle of my stack
<doko_> tfheen: yes, it allows you recover from a broken system, and doesn't let you install broken packages (we had some with missing version information, these are already fixed) anymore.
<tfheen> doko_: but no bugs have been filed about it?
<tfheen> doko_: gcc-3.3 looks good to me.
<infinity> doko_: Can the elementree python-support build-dep be relaxed from 0.5.4 to 0.5.3ubuntu1 without breaking?
<doko_> tfheen: these were alread marked as fixed for the previous upload; see 56779, 57121, 64604
<tfheen> bug 56779
<Ubugtu> Malone bug 56779 in python-central "Error during Dapper-->Edgy update, problem removing python2.3" [High,Fix released]  http://launchpad.net/bugs/56779
<dholbach> tfheen: is it ok to upload http://daniel.holba.ch/temp/pwlib.debdiff and rebuild ekiga against it? it will fix a partial upgrade issue seb128 told me about earlier
<tfheen> dholbach: that's a hideous workaround, really.
<dholbach> I know and it gives me the collywobbles everytime I have to look at it
<tfheen> what is the bug it fixes?
<infinity> doko_: Okay, looks like the last python-support upload didn't really fix anything RC, just some (annoyingly) cosmetic issues, so I'll lower the build-dep for elementtree, so it'll build.
<dholbach> tfheen: 
<dholbach> seb128_ $ ekiga
<dholbach>  ekiga: error while loading shared libraries: libpt.so.1.10.2: cannot open shared object file: No such file or directory
<dholbach>  ii  libpt-1.10.0             1.10.1.dfsg-1build1      Portable Windows Library
<dholbach> seb128_ dholbach: looks like the Depends it not tight enough
<tfheen> dholbach: shouldn't that -V to dh_makeshlibdeps + a rebuild fix that well enough?
<dholbach> tfheen: the COMPAT_VERSION stuff is in sync with Debian now
<dholbach> I can drop the other stuff - I just thought that it'd fix other rdepends
<doko_> infinity: yes, thanks
<pitti> infinity: do we really need a transitional package for -xh? we didn't  have that in dapper
<dholbach> (without having to rebuild them all)
<dholbach> 'fix'
<infinity> pitti: If we didn't have it in dapper, I'm happy with just removing the out-of-date one from the archive.
<tfheen> seb128: hmm, ok, approved.
<pitti> infinity: I'd prefer that; I think we had a transitional package in breezy, and I dropped it in dapper
<tfheen> s/seb128/dholbach/
<seb128> good :)
<pitti> infinity: must have accidentally slipped in in a previous edgy version, but it has always been transitional
<dholbach> Ok.
<infinity> pitti: Alright, will remove in a second when I context-switch.
<pitti> tfheen: did you see the new diff for bug 66977? Am I ok to upload?
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Medium,Fix committed]  http://launchpad.net/bugs/66977
<tfheen> dholbach: but please apply appropriate blunt instrument to the packagers for the compat stuff.
<dholbach> haha
<infinity> tfheen: http://cerberus.0c3.net/~adconrad/elementtree.diff <-- for approval.
<dholbach> I'll tell Kilian
<tfheen> pitti: why not just use 'or $_ .= "\nbrowser.startup.homepage=$starturl\n"'  and still call it with -pi ?  I'd prefer minimal diffs too at this point.
<pitti> tfheen: that would replace every line with browser.startup.homepage, wouldn't it?
<pitti> tfheen: well, the script could set $/ in BEGIN, and then use appending
<pitti> tfheen: (sorry, not replace, but append on every line)
<tfheen> pitti: oh, point, undef $/ in BEGIN and it should be fine
<kelmo> is there an appropriate forum (mailing-list or so) for discussing copyright issues for software contained in *ubuntu?
<tfheen> kelmo: -devel would be closest.  What's the issue?
<tfheen> infinity: approved
<kelmo> tfheen: ktorrent contains some text that makes me nervous, my concerns were brought up on debian-legal[1]  before via Fathi
<kelmo> [1]  http://lists.debian.org/debian-legal/2006/06/msg00093.html
<kelmo> tfheen: the text within the orig.tar.gz somehow is not aligned with debian/copyright, at least in my opinion
<kelmo> tfheen: i am a big fan of the application, and tried to work this out with upstream along time ago with limited success
<tfheen> kelmo: if you could bring it up on ubuntu-devel we should be able to handle it.
<infinity> Both the APNIC and ARIN licenses are non-free, yes.
<infinity> I suspect many/most would be willing to look the other way, as it's "static data", but there's obviously non-free.
<kelmo> i do no like to turn the other cheek
<kelmo> not when te app is in release blurb
<infinity> Oh, and the RIPE one.  (I somehow assumed that the ARIN/RPIE license was all one)
<kelmo> tfheen: ok
<pitti> tfheen: updated and tested patch: http://librarian.launchpad.net/4895094/66977.diff
<pitti> would anyone have some minutes to accept the dapper-updates langpacks from yesterday?
<Kamion> yes, one moment
<pitti> (no-change uploads from the -proposed uploads from last week)
<pitti> Kamion: thank you
<StevenK> gnatmake: "/tmp/buildd/libadabindx-0.7.2/build/i-csstli.adb" compilation error
<StevenK> make: *** [build/libadabindx.a]  Error 4
<StevenK> Drat. Sorry.
<infinity> Kamion: I can do that (I'll remember -M this time) if you're busy.
<gnomefreak> am i the only one that cant boot the rc after installing it. I get file not found
<infinity> Kamion: Doing.
<tfheen> pitti: actually, that patch is then wrong, sorry.
<tfheen> pitti: what happens if more than one of homepagedefault and the other alternatives are set?
<tfheen> pitti: please file a bug about that, milestone it later.
<doko_> tfheen: will you come back to http://people.ubuntu.com/~doko/edgy/python-central.debdiff ? mvo did review the patch before the RC.
<tfheen> doko_: I don't see the need for it before release, as I said.  There are no broken versions in RC or the archive, is there?
<infinity> Kamion: Or, rather, not doing, since you were already running it.  Whee. :)
<tfheen> pitti: since no xpi-s set the homepagedefault, I'm fine with accepting your patch.
<doko_> tfheen: but users may have still installed broken versions.
<Kamion> pitti: done
<pitti> tfheen: if there already is a homepage set, then the s/// will return true and nothing will be appended
<pitti> tfheen: that's where the 'or' comes into play
<pitti> tfheen: it DTRT if a homepage is set already
<pitti> Kamion: merci
<pitti> tfheen: m-f-locale-all uploaded, thanks for the review
<pitti> tfheen: ok to upload the final edgy langpacks? they have been tested by several people since yesterday, I manually fixed a few remaining glitches, they look good now
<tfheen> pitti: not if there are multiple occurences of homepage, then it doesn't DTRT any more, but I guess that' broken.
<tfheen> pitti: edgy langpacks sounds good.
<tfheen> pitti: you got the polish problem too?
<pitti> tfheen: hm, multiple homepages? right, but my patch doesn't change that behaviour
<pitti> tfheen: yup
<pitti> (I misunderstood it as 'you have to polish them a bit first :-) )
<tfheen> pitti: ok, good.  (https://launchpad.net/distros/ubuntu/+source/language-pack-pl/+bug/63344 is the bug I was talking about)
<Ubugtu> Malone bug 63344 in language-pack-pl "rosetta truncated plural form for pl and that breaks python apps" [Medium,Fix committed]  
<pitti> right, I got it
<tfheen> good
<pitti> before: "Plural-Forms: nplurals=3; plural=n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10\n"
<pitti> now: "Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 "
<pitti> "|| n%100>=20) ? 1 : 2)\n"
<pitti> carlos: ^ that looks fine to me, right?
<carlos> pitti: yeah
<carlos> that's the fix
<carlos> pitti: allow multiline pluralforms
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/partman-base.diff
<Kamion> er, that's incomplete ...
<Kamion> tfheen: ok, URL above is complete now
<Kamion> (and tested)
<tfheen> Kamion: ok, looks good.
<Kamion> I'll accept the language packs once process-upload has finished munching on them
<Kamion> lp_queue 12470  7.1  2.3 228704 91592 pts/11   Sl+  12:33   0:15 python /srv/launchpad.net/codelines/current/scripts/process-upload.py -C insecure -M -v -v -v /srv/launchpad.net/lang-pack-queue
<malcc> It's taking about 2-3 seconds each and there are just short of 800 of them, so expect it to finish around 1pm drescher-time
<Kamion> dholbach: do you know anything about the current state of Ubuntu artwork? the artwork freeze is today
<Kamion> malcc: thanks
<Kamion> impressive
<tfheen> dholbach: it should all be in, sans usplash which I'm working on now.
<Kamion> ok, good
<_ion> Are you going to revert to the dapper usplash theme, or is there going to be a new theme?
<tfheen> _ion: I'm going to look at the goodiebag dholbach sent me and get that in.
<Kamion> seb128: are you sure that bug 66929 is a duplicate? it seems a bit unlikely to me
<Ubugtu> Malone bug 66929 in console-setup "on first boot, keyboard under X repeats forever" [High,Fix committed]  http://launchpad.net/bugs/66929
<Kamion> seb128: er, I mean bug 66995
<Ubugtu> Malone bug 66995 in gdm "Keyrepeat in fresh install" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66995
<Kamion> seb128: that just looks like key repeat cranked up way too high - the problem with 66929 was that console-setup was putting X's tty into Unicode mode when it was expecting it to be in raw mode, whose symptoms are rather different (for example, while you do get weird key repeat, it's usually not the same symbol as you thought you pressed)
<Kamion> it *could* be the same thing, but I think the submitter of 66995 will need to verify independently
<Riddell> release team: we found some non free data in ktorrent, should we upload a dfsg compiant version?
<Riddell> licences are http://kubuntu.org/~jriddell/tmp/FLAGS_LICENCE and http://kubuntu.org/~jriddell/tmp/GeoIP-LICENSE.txt
<tfheen> Riddell: kelmo talked about it earlier; how are you solving it?
<Riddell> tfheen: copy the dfsg changes made in debian, just remove the data and edit the Makefile.am for that directory
<tfheen> Riddell: sounds like a sensible approach; please let me review the debdiff when you have it ready?
<Riddell> tfheen: sure
<kelmo> tfheen, Riddell, thanks for action
<kelmo> gn8
<tfheen> dholbach: you've tested the usplash on i386?
<Kamion> tfheen: bug 65973? updated information since your last comment
<Ubugtu> Malone bug 65973 in rus-ispell "Please sync rus-ispell (main) from unstable (main)" [High,Confirmed]  http://launchpad.net/bugs/65973
<tfheen> pitti: you've tested the new rus-ispell?
<infinity> tfheen: The 8 billion langpack uploads in queue/unapproved are approved, right?
<tfheen> infinity: yeah.
<tfheen> 8 bajillion sounds about right
<Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/ktorrent.debdiff
<malcc> Wow, talk about inflation. When I were a lad, we called a hundred a hundred
<Hobbsee> tfheen: it's to clog up the buildds again, close to release
<Kamion> infinity: please use -M :-)
<infinity> Kamion: Yes dear. :)
<infinity> malcc: When you say "a hundred", you mean "seven hundred and thirty four"?
<infinity> (does that seem excessive to anyone else?)
<Hobbsee> infinity: seven hundred and thirty three, surely.
<malcc> infinity: It was my intention to keep the "8", and just complain about billions turning into bajillions when hundreds is still a slight over-estimate
<tfheen> Riddell: looks ok to me.
<pitti> 
<pitti> re, even
<pitti> tfheen: sorry, I was out for lunch; I installed myspell-ru and typed a few Russian sentences into OpenOffice.org, and both suffix rules and word correction work fine
<tfheen> pitti: ok, thanks.
<Kamion> Hobbsee: looks like 734 from here, unless I missed a subtle joke ...
<pitti> tfheen:   :)
<tfheen> Kamion: please sync rus-ispell, then.
<Hobbsee> Kamion: darn it.  clearly i cant count
* infinity watches it grind away.
* bhale hugs tfheen 
<bhale> nice work
<malcc> infinity: Don't forget the 38 in NEW, assuming you want those
<infinity> malcc: I do, yes.  But I'll get to them in a week or two when these are done. :P
<pitti> infinity: did you see Lucas Nussbaum's u-d mail about rebuilding edgy? rebuilding everything in 5 hours is quite impressive
<thom> pitti: given the amount of hardware they're throwing at it
<infinity> pitti: Yeah, it was a LOT of hardware.
<thom> it's not that surprising
<pitti> yeah, I know
<Kamion> he also kind of forgot Packages-arch-specific ;-)
<pitti> and it uncovered a lot of FTBFS
<Kamion> had to close a Debian bug out of hand because of that
<thom> "The rebuilt was done on about 40 AMD64 nodes of the Grid'5000 platform" (from the debian bugs)
<dholbach> tfheen: no, I didn't
<tfheen> dholbach: can you please do so?  I'd like to not reboot my laptop right now.
<jono> anyone know Ryan Troy's nick?
<dholbach> tfheen: I'd have to reboot my laptop too :)
<tfheen> dholbach: just dpkg-buildpackage and install and reboot and you should be fine.
<dholbach> Kamion: I plan to upload edgy-gdm-themes and edgy-wallpapers (to update debian/copyright, once I have a missing email address)
<jono> ahhh got it
<jono> :)
<tfheen> dholbach: I have a pbuilder chroot which is in the middle of a debugging session. :-P
<dholbach> tfheen: usplash currently doesn't work for me on that box
<dholbach> Kamion: and I have to update human-icon-theme - but it will make it in today
<dholbach> tfheen: it'd be nice if somebody could have a look at it :/
<dholbach> Kamion: that's all I know about artwork
<tfheen> dholbach: ok, I'll do an i386 install, then
<dholbach> don't we have somebody here who could test that on i386 without doing a new install? :-(
<simira> hm... install... maybe I'll take the opportunity to reinstall the RC...
* infinity freshens the buildd chroots so the langpack builds go faster..
<simira> tfheen: can you burn me an RC?
<Treenaks> edgy-beta =
<Treenaks> + upgrades
<tfheen> simira: sure, there's a dvd-rw in the top of my cake box on the small table besides my keyboard.  pop that into xoog's dvd drive.
<Treenaks> works great for me.. on my LaptopTestingTeam-laptop
<tfheen> simira: alternate or desktop?
<Treenaks> except for the X bug that I've had since day one
<simira> tfheen: whatever needs the most testin? :p desktop, prefferably
<tfheen> simira: ok, it'll consume a bit of bandwidth.
<tfheen> you'll have it in an hour or so.
<simira> tfheen: oh, I thought you had it locally. But ok.
<infinity> Okay, I really need to figure out WTF this means:
<infinity> dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
<simira> Treenaks: what x bug?
<Treenaks> simira: bug 20283
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Unknown,Needs info]  http://launchpad.net/bugs/20283
<Treenaks> simira: (with video evidence! :))
<simira> ah
<tfheen> simira: or it looks like cdimage.u.c is slightly overloaded, so it'll take a bit more.
<infinity> tfheen: pitti's m-f-l-a upload was approved, yes?
<tfheen> infinity: it was.
<infinity> pitti: Alright, all the edgy packs are processed.
<pitti> yay
<erdalronahi> ping: doko
<erdalronahi> ping: doko_
<doko_> erdalronahi: ?
<erdalronahi> hi doko
<erdalronahi> good to see you :)
<erdalronahi> I tried all night to find you
<erdalronahi> we have a serious problem with openoffice.org-l10n-ku, bug 67003
<Ubugtu> Malone bug 67003 in language-support-ku "Edgy: openoffice.org-l10n-ku is very outdated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67003
<erdalronahi> the others told me that only you could say something on that issue
<doko_> please could you look at http://people.ubuntu.com/~doko/GSI_ku.sdf if the messages in this file are up to date?
<doko_> erdalronahi: ^^^
<erdalronahi> doko_, looking...
<erdalronahi> they do not look up to date
<erdalronahi> where did you get them from?
<erdalronahi> the most up to date files are at http://download.ferheng.org/ooo2/GSI_ku.sdf.bz2
<infinity> Damnit.
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349442
<erdalronahi> this is also upstream now
<Ubugtu> Debian bug 349442 in dpkg "dpkg: Assertion `dependtry <= 4' failed (abort)." [Grave,Closed]  
<infinity> Kamion: dpkg in dapper has that bug.  dapper is the base system on the buildds.  Kaboom installing build-deps for a handful of builds.
<doko_> erdalronahi: it's that what is in rosetta
<erdalronahi> well, the file is of 15.10.
<erdalronahi> there have been changes after that
<infinity> mdz: Around?
<mdz> infinity: yep
<infinity> mdz: See my above note to Kamion about dapper's dpkg being broken in a way that's causing a few build failures. :/
<erdalronahi> I uploaded a complete set of files, but it took 5 days until it arrived
<mdz> infinity: is it fixed in edgy?
<erdalronahi> the queue was very full, maybe
<infinity> mdz: Is there any chance ot fasttracking a backport of that bugfix to dapper (quite simple, since the patch in the bug report is, in fact, against dapper's dpkg, and it's 1 line)
<infinity> mdz: Yeah, it's fixed in edgy.
<mdz> infinity: why is the dpkg in base used rather than the one in the chroot?
<erdalronahi> doko, most changes did not arrive before the 16.10.
<infinity> mdz: Other than "that's the way sbuild works"?
<erdalronahi> because the queue was so slow
<infinity> mdz: The easiest argument to make is "so we can keep the chroots free of non-essential packages" (we use the base apt-get, so we can have gnupg in the base system for verification, and using the base apt-get implies using the base dpkg)
<infinity> mdz: Another fun argument was always the "it keeps us honest about not using new dpkg features prematurely" :)
<infinity> mdz: Anyhow, it was a "grave" bug in Debian (and I tend to agree, after now seeing it in action), so I'd be inclined to just fix it.
<mdz> infinity: is it urgent for this week?  iwj is back next
<infinity> mdz: Well, unless I want to hand-build the stuff that's failed (which I can do), it'd be nice to have it fixed pre-release.
<infinity> mdz: The patch (written by iwj) is tiny:
<infinity> mdz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349442;msg=53
<Ubugtu> Debian bug 349442 in dpkg "dpkg: Assertion `dependtry <= 4' failed (abort)." [Grave,Closed]  
<infinity> Ubugtu: Yes, yes, you said that 5 minutes ago, thanks.
<mdz> infinity: if it's been in edgy for a while already, ->dapper-proposed
<infinity> mdz: Was fixed pretty much right after edgy opened.  Wish I'd known about it then and proposed the backport.  Achwell.
<mdz> infinity: dapper-proposed -> install that on the buildds should provide enough testing over the week to put it into -updates
<infinity> mdz: I'll patch, build, test, and upload to proposed (and cheat and toss it on the buildd in question to A) make the build work, and B) test the fix in production)
<infinity> mdz: Yeah, we're on the same wavelength there. :)
<erdalronahi> doko, just checked it: There were some conflicting translations which resulted in fuzzyness. Therefore they never showed up in OOo at all (which I consider a BUG). I corrected all this on Oct 12 and uploaded it, but they all arrived on Oct 16, so they are neither in your file nor in the final package
<erdalronahi> This is serious and affects thousands of translations
<lfittl> infinity: about the dpkg bug, bzr-svn FTBFS because of it, I filed Malone #67106 to rebuild it, but after reading your description of the problem, rebuilding on the buildds would be useless, whats the right thing to do?
<Ubugtu> Malone bug 67106 in bzr-svn "bzr-svn has failed to build on i386" [Medium,In progress]  http://launchpad.net/bugs/67106
<mdz> mjg59,Lure: do we have a workaround for bug 60442?
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Confirmed]  http://launchpad.net/bugs/60442
<mdz> doko_: isn't bug 56779 resolved by the python-central update?
<Ubugtu> Malone bug 56779 in python-central "Error during Dapper-->Edgy update, problem removing python2.3" [High,In progress]  http://launchpad.net/bugs/56779
<mdz> infinity: did you have a look at ndiswrapper (bug 59983)?
<Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
<erdalronahi> doko_, sorry, I always wrote to "doko", did you get my remarks?
<seb128> Kamion: no, I'm not sure that bug #66995 is a dup, it has the same description though, I've probably read it too quickly
<Ubugtu> Malone bug 66995 in gdm "Keyrepeat in fresh install" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66995
<doko_> mdz: not all, these were suggestions made by mvo to be more safe. the patch doesn't break anything, it makes the runtime installation / runtime removal more robust. I want to see this in edgy, tfheen disagrees, mvo reviewed the patch
<mdz> doko_: but it doesn't resolve either RC bug?
<infinity> lionelp: The right thing to do is wait for me to get this dapper-proposed upload in, and get it on the buildds.
<infinity> lfittl: ^^^
<infinity> lionelp: Sorry, misfire.
<doko_> mdz: for me, it's RC
<infinity> lfittl: Also filing bugs for a retry isn't very helpful. :)
<lfittl> infinity: ok, and after that, should I trigger the rebuild with a new upload, or will you do it?
<infinity> lfittl: Never reupload to trigger a build retry, just ask me or tfheen.  (in this case, I'll be retrying it anyway, as it's my testcase)
<doko_> erdalronahi: so which are the current translations? the one from http://download.ferheng.org/ooo2/GSI_ku.sdf.bz2, or the ones in rosetta?
<lfittl> infinity: k, thanks, didn't know that
<erdalronahi> they are the same 
<erdalronahi> doko, but your file is from 15.10.
<erdalronahi> the files in Rosetta are from 16.10, one from 19.10 as is my file
<erdalronahi> doko_  http://download.ferheng.org/ooo2/GSI_ku.sdf.bz2 is the latest
<doko_> erdalronahi: please join #launchpad to talk to carlos
<seb128> mdke_: 4 top level menus, that's a joke, right?
<carlos> doko_: erdalronahi: What's the problem?
<Lure> mdz: nobody confirmed yet that proposed workaround helps and I cannot reproduce it on my multi-battery laptop (HP) - I suspect it should help, but we need confirmation in order to document in release notes
<infinity> mdz: Will tackle the ndiswrapper thing momentarily.
<Lure> mdz: we have similar issues in kde (bug 67081) and it looks like to be more HW related (remaining time reported wrongly) - no easy workaround for kde though (will have to wait for -updates)
<Ubugtu> Malone bug 67081 in kde-guidance "guidance-power-manager thinks battery is low way too early" [Undecided,Needs info]  http://launchpad.net/bugs/67081
<mdz> Lure: was mjg59 able to reproduce the problem?
<Q-FUNK> for bug #66173 and bug #66175 what would be the correct package hint?
<Ubugtu> Malone bug 66173 in upgrade-system "Bad sentence:  "...cannot be canceled at any time later"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66173
<Ubugtu> Malone bug 66175 in upgrade-system "Usage problems in install partitioner" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66175
<mdz> Q-FUNK: hmm?  you're listed as the maintainer, so I'd assume you know whether the bugs are yours or not :-)
<Q-FUNK> I _know_ they are not. :)
<Q-FUNK> I just have no idea on what is the right package to reassing them to.
<Q-FUNK> spotting bugs meant for update-manager is easy.  however, those 2 are about some d-i components.
<mdz> pitti: have you rolled the final langpacks?
<pitti> mdz: yes, they should be in the archive by now
<Q-FUNK> From the user's comment, I'm guessing that he tried a search on a package with a name that contained "update" "install" or "upgrade" when meaning to report about the installer.
<mdz> Q-FUNK: 66173 is update-manager
<mdz> Q-FUNK: 66175 is unclear, something in the ubiquity/partman/gparted chain.  leave package blank and subscribe ubuntu-installer
<Kamion> it's gparted; reassigned
<Kamion> no need to subscribe ubuntu-installer in that case
<Q-FUNK> argh
<Q-FUNK> just did
<Q-FUNK> oh well...
<Kamion> doesn't matter
<janimo> heno: what do we do about bug 58836 ?
<Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [High,Confirmed]  http://launchpad.net/bugs/58836
<Kamion> don't tell me that bug is open AGAIN
* ogra goes to mow some lawn ... bbl
<Kamion> surely by this point it would be better to file a new bug
<Kamion> janimo: your patch needs to also edit ubiquity-hooks/30accessibility
<janimo> Kamion: not the same bug, but attached two more patches to it, one is for xubuntu the other to fix magnifier on ubuntu live
<janimo> Kamion: even if those are system wide files and thus get copied over?
<Kamion> janimo: bet you they don't
<janimo> Kamion: I need to add the apt-install thing you mentioned
<Kamion> janimo: ubiquity copies the unmodified live filesystem, remember
<Kamion> janimo: honestly, I think this is just too late
<infinity> mdz: http://cerberus.0c3.net/~adconrad/dpkg.diff
<Kamion> it would be better to leave that bug closed and attach a complete patch to a new bug, subscribing the right people if necessary
<janimo> I had it ready first thing after the ubuntu liveCD had them in order
<Kamion> and the Ubuntu live CD only barely had it ready in time
<Kamion> that squeaked in under the wire as it was
<infinity> mdz: Okay to upload that?
<Kamion> janimo: this stuff is not trivial and needs testing; the omission of the ubiquity-hooks changes demonstrates that
<Kamion> between RC and release needs to be stuff that's blatantly obvious
<janimo> Kamion: I knew ubiquity needed changing since you told me that.
<mdz> infinity: assuming it's identical to the change in edgy, yes
<janimo> but thought it was copy paste from here as the other pacthes seemed to be done against capser and syned in ubiquity
<infinity> mdz: It is, modulo whitespace.
<Kamion> yes, it's copy-and-paste, but even so historically patches to that pair of files have rarely been right first time
<Kamion> and it takes quite a while to notice problems
<janimo> Kamion: worst case xubuntu a11y will work as now (not at all) those 4 lines do not affect other files in k/ubuntu right?
<Kamion> it's a theory ... but in the past that has not been as true as we might like
<Kamion> for instance syntax errors in Kubuntu changes have broken Ubuntu. We defend against that now, but I wouldn't like to guarantee that there are no other possible modes of cross-flavour breakage
<infinity> mdz: BTW, in StableReleaseUpdates, ubuntu-archive's role is purely robotic (ie: make sure the procedure's been followed, the bug and upload have approval, and accept), yes?  We're not expected to be another barrier of entry and review?
<Riddell> janimo: do you have a 640x400 usplash yet?
<infinity> mdz: If I'm wrong about that, I'll tap a shoulder to get another review of this, since reviewing my own upload before I accept it seems not quite right. :P
<Q-FUNK> could anyone check and hopefuly confirm #66821, #66822, #66823 ?  minor changes in the debian package to make the moduels build again.  nothing upstream involved.
<janimo> Riddell the artwork guy knows about it so we will have shortly
<Kamion> universe sponsorship/confirmation -> #ubuntu-motu
<TMM> Kamion: well, rebuilding OOo didn't help :( 
<janimo> Kamion: at least the last patch the one liner which is for ubuntu. Upstream orca agreed  it's the best solution ATM to get the magnifier working.
<Kamion> janimo: dear god can we have *separate bugs* for all these?
<Kamion> janimo: if there's a huge chain of patches in a single bug, it's no wonder stuff gets lost
<Kamion> it's too confusing for us to follow
<TMM> Kamion: the bug didn't occure with stock binaries btw
<Q-FUNK> oh
<Kamion> TMM: (I know nothing)
<Q-FUNK> alright :)
<TMM> Kamion: just thought I'd tell you
<janimo> Kamion: sure.
<Kamion> thanks
<Kamion> a bzr branch would be even better ...
<infinity> Kamion: For the sake of propriety, and so I'm not fasttracking my own uploads, want to review 'q -s dapper-proposed -Q unapproved fetch 111821' for me, against bug #46530
<Ubugtu> Malone bug 46530 in dpkg "process_queue: Assertion `dependtry <= 4' failed." [Undecided,Confirmed]  http://launchpad.net/bugs/46530
<tfheen> Seveas: do you have new progress bars for 640x400@16 available now?
<Seveas> tfheen, fschoep wanted them to be simply 2-colors
<Seveas> lik the testcard theme
<Seveas> and that is still blocked on bug 64171
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
<Seveas> fschoep already has the rest of the theme since yesterday 
<tfheen> artwork freeze is today and I'm about to upload the new theme.  I doubt I'll accept any more theme updates after today.
<infinity> Does the new theme not give me a letterboxed look on my massive display, by any chance? :)
<infinity> (Just turned on usplash for the first time in a long time today, and turned it off again prompty due to ugliness)
<tfheen> infinity: amd64 or i386?
<Seveas> bluntly said, you'll have to as I have had no opportunity to correct any colors (text, background, progress bar@16)
<dholbach> mdz, Kamion, tfheen: human-icon-theme is ready / I just sent it to fschoep to have another look - just to let you know, that artwork is basically 'in the box'
<infinity> tfheen: i386, but using the bogl backend (vesa fb)
<tfheen> infinity: might be a tad better.  You'll see in a bit
<infinity> tfheen: I haven't looked at it, but I suspect there's a border around the image, so the "bleed" on the unused screen portion is a dark brown, instead of bleeding the background colour to the edges.
<infinity> tfheen: (At a guess)
<Seveas> infinity, that's part of bug 64171
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
<mdz> dholbach: eek, I thought it already was
<mdz> dholbach: I just asked the doc team to update screenshots and expect a usplash update
<bddebian> Howdy
<mdz> dholbach: if there's more, please follow up to my ubuntu-doc post
<tfheen> usplash-theme-ubuntu is just uploaded
<tfheen> with new artwork.
<infinity> Seveas: You sure?  That doesn't look to relate.
<dholbach> mdz: I expect to have his answer quickly and upload it directly
<Seveas> infinity, rr right, I missed the 'with bogl backend'
<Seveas> (and the e and spacebar on my machine are bustd)
<infinity> Seveas: It's not a drawing problem, it's a "small artwork in the middle of big screen, colour bleed is a big dark colour that sucks" thing. :)
<infinity> (hence why I assumed the image probably has a border, and it's the border that's bleeding, which is pretty ugly)
<Seveas> infinity, well, the image has no border but the theme specifies a background color for the places where noimage exists. Part of the result of that bug is that the colors specified in the theme are incorrect
<Seveas> so it's not caused by the bug, but a side effect of it
<infinity> Seveas: Ahh, specifying a background colour would do it too, I guess, yes.  And it's clearly specifying one I disaprove of. :)
<infinity> We'll see how things go after tfheen's upload, then I'll whine again.
<Seveas> infinity, ;)
<infinity> (And then shut off usplash anyway, I suspect)
<Kamion> infinity: reviewed, more formal SRU written, accepted
<infinity> Kamion: I noticed the bug update yes, thanks. :)
<wasabi> Merging patches from RedHat is depressing.
<infinity> wasabi: You need to work on packages where you like the RedHat maintainers, I guess.
<wasabi> It's just like, nobody even tries to push anything upstream
<infinity> wasabi: 99% of my RedHat merges are patches by Joe Orton, and I rather enjoy that.
<wasabi> Lucky you. =)
<thom> well, joe is a bit of a special case :-)
<Kamion> infinity: can you mail sfllaw to ask for wider testing, per StableReleaseUpdates? I've tagged the bug appropriately
<infinity> wasabi: To be fair, we're pretty horrible at sending stuff upstream a lot of the time too.
<wasabi> True.
<infinity> thom: Indeed.  I keep meaning to make it to an ApacheCon or something to meet the man and buy him hideous amounts of alcohol.
<infinity> Kamion: Will do.
<infinity> (once it's built)
<thom> i don't think he's ever been to an apachecon sadly. i think the only way to meet him is to turn up to his house in cambridge and drag him to the nearest pub
<thom> (the real cambridge)
<infinity> Damnit, that's two reasons to go to Cambridge now.  I'm starting to run out of excuses for not wanting to.
<wasabi> Hmm. I guess in this case it's upstream which is being unreceptive.
<wasabi> As in not accepting the patch for 2 years.
<Kamion> Joe Orton is in Cambridge?
<thom> Kamion: yeag
<thom> yeah
<Kamion> never seen him at any of the local geek things. Then again, I only know him by vague reputation
<thom> Kamion: no, he's pretty reclusive afaik
<infinity> thom: Does he even exist?  Have you met him?  Perhaps he's a hyperintelligent shade of the colour blue that just happens to like hacking on webservers?
<thom> infinity: it's entirely plausible. but i do know people who say they've met him
<mdz> seb128: can you elaborate regarding bug 59159?
<Ubugtu> Malone bug 59159 in gst "network-admin doesn't scan for networks [regression] " [Unknown,Unconfirmed]  http://launchpad.net/bugs/59159
<mdz> seb128: did upstream just disable this functionality without providing a replacement?
<seb128> mdz: the g-s-t infrastructure has changed, it uses liboobs and dbus method now instead of some custom xml protocol
<seb128> mdz: the corresponding code has not been ported yet
<seb128> liboobs methods need to be written for that
<seb128> and I think upstream was not that happy with previous code and want to fix it in the same time
<seb128> cf https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/59159/comments/9 basically
<Ubugtu> Malone bug 59159 in gst "network-admin doesn't scan for networks [regression] " [Unknown,Unconfirmed]  
<mdz> seb128: right, so upstream let this functionality break while implementing the new infrastructure?
<seb128> he didn't port that code yet
<seb128> that's not like he broke existant code
<seb128> the old methods can't be used with the new infrastructure
<seb128> but right, the result is that the feature is not available atm
<mdz> seb128: oh, was that code that we added?
<seb128> no, that was upstream code
<mdz> seb128: I'm just surprised that they would abandon it
<seb128> it's not abandoned, it's not ported *yet*
<mdz> seb128: 2.16 is released though
<mdz> it was abandoned for 2.16
<seb128> GNOME 2.16.0 decided to stay with g-s-t 2.14 in fact
<seb128> g-s-t is sort of a special case, Redhat, Suse, Mandriva don't use it because they have their tools
<seb128> so most of people seems to not really care about it
<seb128> we decided to go with 2.15.n because it fixed a whole lot of issues previous versions had and it's easier to maintain
<mdz> seb128: I see
<mdz> This is a serious regression though
<seb128> the fact that this feature didn't get ported in time is unfortunate though :/
<seb128> mdz: I agree. We didn't get many bugs about it though, that's sort of surprising
<mdz> seb128: I think we'll get a lot more after the release
<mdz> seb128: I think probably power users use network-manager at this point
<seb128> I can have a try to implement it before monday if you want
<mdz> while people who are conservative and run stable will be surprised
<mdz> it just bit someone here in the office, which is why I discovered it
<mdz> I use n-m as do most of us
<seb128> might be easy, to use the old function and to plug a liboobs method for it
<mdz> seb128: is there any work in progress upstream?
<seb128> not that I know
<mdz> seb128: it sounds worth a try; even if it doesn't make the release it's something we should fix in -updates
<seb128> ok, will have a look on it then
<mdz> I'm setting a milestone on it
<seb128> k
<seb128> It was milestoned for edgy for some weeks
<mdz> if you solve it then Ckenyon will buy you beer at allhands
<seb128> but nobody picked it and it was after freeze and there was not a lot of dups so I dropped the milestone
<seb128> ah, nice ;)
<mdz> seb128: I understand; we made a tradeoff for other bugs
<infinity> Columns: number-out-of-date, number-newer-than-source, arch
<infinity>      760    0 amd64
<infinity>      760    0 i386
<infinity>      759    0 powerpc
<infinity>      759    0 sparc
<infinity> langpack uploads make me sad.
<infinity> tfheen: You ready for another run through the queue?
<seb128> mdz: right, g-s-t 2.15 is maintained by upstream, fixes a whole bunch of issues and is easier to maintain
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/console-setup.diff - makes upgrade from edgy beta smoother, fixes RC bug 66929 (console-setup vs. X tty fight), RC bug 66774 (Brazilian keymap regression from dapper), bug 66719 (Japanese keymap, not a regression but should be fixed IMO)
<Ubugtu> Malone bug 66929 in console-setup "on first boot, keyboard under X repeats forever" [High,Fix committed]  http://launchpad.net/bugs/66929
<Ubugtu> Malone bug 66774 in console-setup "Wrong configuration for Brazilian keyboard" [Medium,Confirmed]  http://launchpad.net/bugs/66774
<Ubugtu> Malone bug 66719 in console-setup "Japanese Keyboard model isn't set properly on Live session" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66719
<Kamion> tfheen: I haven't tested the Brazilian or Japanese fixes yet, but I will do
<infinity> Kamion: Hooray for fixing 66929
<Kamion> yeah, that was a nasty little lurker
<Kamion> once I realised it wasn't an X bug, it was fairly tractable
<infinity> Kamion: I was seeing it when building livefs images, which was pretty painful.
<jonh_wendell> i think 4 months for edgy very little...
<Kamion> nifty
<infinity> (Or seeing something very similar)
<mdz> jonh_wendell: thank
<mdz> s
<infinity> Every time console-setup's postinst would run in the chroot, my X keyboard would explode.  Tres exciting.
<Kamion> infinity: although the postinst shouldn't actually call setupcon any more; I changed that a while back
<infinity> I actually changed how livecd.sh calls debootstrap just to stop it from happening. :)
<Kamion> I'm not going to revert that workaround for edgy, but will do for feisty
<jonh_wendell> mdz: for what? :)
<infinity> Kamion: Yeah, I know you changed the postinst, hence why I didn't report the bug.
<mdz> jonh_wendell: for your observation
<infinity> Kamion: Didn't really think about this other impact until someone else pointed it out.
<jonh_wendell> mdz: do you agree?
<Kamion> infinity: having it show up on the first boot of a Kubuntu installation was pretty painful
<infinity> Kamion: Yeah, apparently. :)
<Kamion> jonh_wendell: we knew it was short, but decided that we needed to suck up the pain now.
<Kamion> we'll go back to the regular schedule for feisty and later
<jonh_wendell> i'm liking to help ubuntu! :)
<heno> janimo: thanks for filing bug 67155 and making the patch. Looks good to me.  Sorry I missed the discussion earlier.
<Ubugtu> Malone bug 67155 in casper "make magnifier start in Ubuntu LiveCD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67155
<TMM> is an edy install on a dell latitude D610 already confirmed to work? if not, I'm sick at home, might as well try :)
<infinity> TMM: Not sure, but it never hurts to test again. :)
<janimo> tfheen: ping re xubuntu RC images
<azeem> W 33
<azeem> oops
<erdalronahi> doko, I have to leave some time soon. Is a new ooo-l10n-ku possible?
<TMM> hum, the rsync command isn't working for me
<TMM> ghe, stupid
<jonh_wendell> pitti: thanks for your work at bug 65223
<Ubugtu> Malone bug 65223 in mozilla-firefox-locale-all "Add pt-BR translation" [Wishlist,Fix released]  http://launchpad.net/bugs/65223
<jonh_wendell> pitti: the updated package with fix for bug 66977 will be avaliable only tomorow?
<Ubugtu> Malone bug 66977 in mozilla-firefox-locale-all "Use localized start pages" [Medium,Fix released]  http://launchpad.net/bugs/66977
<infinity> jonh_wendell: It's just built on the buildds, should be available in the archive in ~ an hour.
<jonh_wendell> uau
<jonh_wendell> i've just seen!
<doko> erdalronahi: I'll first have to find out, what's going wrong
<TMM> infinity: where do I report problems, if any?
<infinity> Bug reports on the packages in question, if you can determine what's at fault.
<TMM> infinity: well, I am already running edgy, and I've only found one problem, I thought this was more for the installer?
<erdalronahi> doko, fine, but I corrected all the discrepancies manually. If you build one with our latest GSI, it will solve the but
<erdalronahi> the bug
<infinity> TMM: Installation can often uncover problems in a variety of packages.
<TMM> infinity: very well :)
<erdalronahi> doko, that was the upload that I did on 12.10. which only was imported after your checkout
<erdalronahi> Just rebuilding the package for ku will now change 1500 translations at once
<doko> erdalronahi: if the translations are in rosetta, then I should get them
<erdalronahi> yes, I corrected everything there, also
<erdalronahi> so there will be an updated package?
<TMM> Kamion: gaim2 beta4 fixes connecting to groupwise 7 sp1 servers. I suppose it is also too late to merge that? :)
<Kamion> TMM: -> tfheen
<TMM> Kamion: ok
<TMM> tfheen: ?
<infinity> pitti: How do you feel about mangling pkgstrip to be stateful, so it doesn't take an hour to run on OOo? :)
<pitti> infinity: pretty good, but preferably not for edgy
<infinity> Yeah, I know.  Just saying. :)
<mdz> keescook: odds that bug 66976 may have been related to your X upload?
<Ubugtu> Malone bug 66976 in xorg "dist-upgrade Dapper -> Edgy. Conflicting files x11-common <-> xinit" [Undecided,Confirmed]  http://launchpad.net/bugs/66976
<infinity> I assume it's just one bit (the "scan the whole friggin tree" bit) that needs ot be wrapped with a stamp file?
<mdz> seems unlikely based on the changelog, but surprising that this was only reported now
<keescook> mdz: checking
<dholbach> mdz,tfheen: ok to upload  http://daniel.holba.ch/temp/bluez-utils.debdiff ?
<keescook> mdz: strange, I didn't change anything about the actual packaging itself.
<mdz> keescook: I didn't expect so
<mdz> could have been lurking somehow
<keescook> I'll still check it out
<mdz> x11-common Replaces: xinit (<= 1.0.1
<mdz> -0ubuntu3)
<mdz> and the version in dapper is 1.0.1-0ubuntu3
<infinity> Ah-ha.
<infinity> The version in security is -0ubuntu3.1
<pitti> tfheen: ok for me to do a handful of language-support-* uploads to pick up the recent new oo.o-l10n-* packages?
<infinity> That replaces needs to be relaxed.
<mdz> yep
<mdz> should be < -0ubuntu4 most likely
<mdz> keescook: will you handle it?
<infinity> Or just << 1.0.2
<keescook> mdz: yup, I'm on it.
<infinity> Which was where it moved in edgy.
<dholbach> mdz: I'll upload human-icon-theme now - I didn't get a reply from fschoep, but I doubt there's much breakage... will follow up on ubuntu-doc about it
<mdz> dholbach: does it have mark's signoff?
<dholbach> mdz: Ok, I'll ask back. I was under the impression that Mark and Frank had discussions about it, but best to be sure.
<infinity> Huzzah for an empty out-of-date list.
<mdz> indeed
<infinity> (Well, it'll be empty after the current run is through)
<pitti> tfheen: finished the langpack-o-matic changes now; I'd like to upload six l-support-* with an added openoffice.org-l10n-xx dependency
<mdz> seb128,dholbach: any guesses about this?  http://www.ubuntuforums.org/attachment.php?attachmentid=17875&d=1161359748
<seb128> "You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:"
<infinity> pitti: Shouldn't that wait until the final OOo-l10n upload, in case we've got enough translations in rosetta to make new ooo-l10n-xx packages?
<seb128> mdz: I've not forum account ...
<pitti> infinity: oh, will there be another one?
<seb128> s/not/no
<mdz> seb128: stand by
<pitti> infinity: won't make much of a difference; if at all, I have to touch different packages
<infinity> pitti: doko's comments above seemed to imply there was another coming.
<mdz> seb128: http://people.ubuntu.com/~mdz/temp/progressbar_edgy.jpg
<pitti> infinity: I'm fine to wait, doko just asked me to adapt them
<seb128> mdz: what theme is that?
<infinity> pitti: Ahh, well, I'll leave it to you and doko then. :)
<mdz> seb128: unknown, looks like human doesn't it?
<infinity> Obviously not, given the lack of orange progress.
<infinity> THough, I do seem that same font corruption on mine, with the orange progress bar.
<pitti> http://people.ubuntu.com/~mdz/anastacia.txt -> 404 ???
<infinity> I've just never cared enough to mention it.
<doko> infinity: no, no new languages
<seb128> mdz: yeah, it looks like, I think there is some community theme based on human with less orange or something like that
<infinity> pitti: s/mdz/cjwatson/
<mdz> pitti: that moved to ~cjwatson ages ago and I finally removed my symlink :-)
<keescook> mdz, infinity: xinit  <= 1.0.1-0ubuntu4   or   << 1.0.2   ?
<pitti> mdz: aah, heh :) /me updates bookmarks
<mdz> keescook: < the version where the file moved
<infinity> keescook: 1.0.2 is more readable and less likely to get broken again.
<dholbach> or it's another cairo/X-<something> driver bug :)
<infinity> keescook: And more correct, as far as when the file moved.
<seb128> infinity: you have a similar font issue with human?
<seb128> mdz: dunno, the theme doesn't look like human, I would be curious to know if that happens with human too
<infinity> seb128: Perhaps not quite as obviously broken as that.  I'll do an update and catch a screen shot for you.
<seb128> infinity: ok, thank you
<mdz> keescook: which, according to the changelog is 1.0.2-0ubuntu3
<infinity> seb128: Mine looks less like "completely unreadable" and more like "a bit ugly".
<mdz> keescook: looks like rodarvus may have made a typo and meant that in the first place (s/1.0.1/1.0.2/)
<mdz> keescook: so to answer your question, << 1.0.2-0ubuntu3
<keescook> heh, okay.
<keescook> later on, xbase-clients depends on xinit... should that be swapped out with x11-common?
<infinity> Okay, trying to get a screenshot of that in progress is challenging. :)
<infinity> keescook: No.
<infinity> keescook: "Replaces" means "files are overwritten", not "this package is now the equivalent of the other"
<infinity> (Yes, it's a horrible name for the field)
<pitti> well, the name is fine, it's just overloaded
<mdz> seb128: ok, only one report of it
<keescook> Heh, okay, just wanted to be sure.
<infinity> pitti: "Overwrites" would have been a bit less confusing.
<mdz> seb128: there is also bug 66800 but that seems relatively minor
<Ubugtu> Malone bug 66800 in Ubuntu "Edgy Eft Beta - Progress bar font" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66800
<infinity> Ahh, yes.
<infinity> seb128: I'll save myself the trouble, the screenshot in 66800 is what I see.
<infinity> seb128: So, ugly, but not "OMG, WHERE'D MY TEXT GO", like the guy with the custom theme.
<pitti> doko, infinity: language-support-* uploaded
<pitti> Kamion: while I'm at langpacks, I'd like to seed the l-pack stuff in anastacia; I take it you're fine with that?
<doko> pitti: thanks!
<Kamion> pitti: all the language packs should already be seeded by a pattern rule?
<infinity> seb128: I suspect it's the same bug/behaviour, just more pronounced with his more broken theme. :)
<seb128> infinity: it didn't look like that on dapper?
<Kamion>  * /^language-pack-[^-] +$/
<Kamion>  * /^language-pack-gnome-[^-] +$/
<pitti> Kamion: hm, indeed, just saw it again
<infinity> seb128: I don't recall, TBH.
<pitti> Kamion: why is anastacia weeping then?
<Kamion> pitti: it won't realise the source packages need to be in main until the binaries are in the archive
<pitti> ah, do we want command-not-found in main? if so, I'll process the MIR now
<pitti> Kamion: ah, I see; thanks
<Kamion> pitti: I've NEWed all those language packs, which will sort it out
<Kamion> hmm, not sure we should be promoting command-not-found now?
<pitti> ok, so everything but c-n-found should be clear then
<Kamion> pitti: what should happen to those ooo packages?
<pitti> Kamion: I just uploaded updated language-support packages which depend on them
<Kamion> ok, thanks
<pitti> I'll process the MIR anyway, can't hurt
<heno> seb128: I think it did look like that on dapper. There was a similar bug reported as being an issue for colour blind people, but I think was rejected (can't find it now). I made some screen shots in grayscale and such for that. (conclusion being that it wasn't too bad)
<tfheen> pitti: language-support-* sounds good.
<infinity> tfheen: Do you want your uaplash-theme-ubuntu upload once-overed before I accept it?
<tfheen> infinity: feel free.
<infinity> dholbach: mlterm/2.9.3-1build1, ajaxterm/0.7-3ubuntu1, aptsh/0.0.6-0build1.  I'm assuming the two rebuilds are no-brainers, what about the other?
<seb128> heno: https://launchpad.net/distros/ubuntu/+source/ubuntulooks/+bug/37603
<Ubugtu> Malone bug 37603 in ubuntulooks "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits" [Medium,Confirmed]  
<seb128> http://librarian.launchpad.net/4537720/contrast.png
<heno> thanks :)
<seb128> np
<dholbach> infinity: a rebuild too
<dholbach> supposing it's bug 65422
<Ubugtu> Malone bug 65422 in ajaxterm "[UNMETDEPS]  ajaxterm has unmet dependencies" [Undecided,Fix released]  http://launchpad.net/bugs/65422
<pitti> heh, command-not-found is neat
<dholbach> infinity: hobbsee uploaded it apparently
<erdalronahi> pitty, the mozilla-firefox-locale-ku is empty, which is a regression to Dapper
<erdalronahi> We have only today got a new XPI
<infinity> tfheen: That is an incredibly uninformative changelog for that much diff.
<infinity> dholbach: Vassilis Pandis <pandisv@yahoo.co.uk>, actually (though Sarah may have sponsored it..)
<tfheen> infinity: I blame fschoep or maybe dholbach.
<dholbach> infinity: *nod*
<dholbach> tfheen: eeeeeehhhhhhh?
<pitti> erdalronahi: if you can convince tfheen/mdz to have it for edgy, I can add it easily
<dholbach> tfheen: oh... I sent it to you untouched
<mdz> pitti: if it's just adding the xpi and it's ready today, no problem
<erdalronahi> great!
<pitti> erdalronahi: please open a bug, attach the xpi, and set me as the assignee
<pitti> erdalronahi: I'll milestone it
<tfheen> dholbach: so we can blame fschoep, then.
<erdalronahi> great
<tfheen> infinity: works for me on i386 and amd64 at least.
<erdalronahi> is 20:00 CET okay?
<pitti> erdalronahi: I have to leave RSN, but I can do it tomorrow
<infinity> tfheen: Yeah, I'd just like to see changes in changelogs.  I'm picky.  Oh well.
<keescook> okay, xorg fixed, can someone re-sign/upload it for main for me?  http://people.ubuntu.com/~kees/edgy-fixes/
<erdalronahi> ok, great!!!
<infinity> keescook: Done.
<erdalronahi> thanks a lot, pitti
<dholbach> tfheen: did you have time to look at  http://daniel.holba.ch/temp/bluez-utils.debdiff ?
<keescook> infinity: thanks
<tfheen> dholbach: looks good; approved.
<dholbach> tfheen: gracias, seor dogowner :)
<TMM> dholbach: great domain name :)
<dholbach> TMM: thanks :)
<tfheen> dholbach: *growl* :-)
<dholbach> HAHAHA
<TMM> tfheen: did you see my question regarding gaim 2 beta4?
<tfheen> TMM: no?
<TMM> tfheen: it fixes using groupwise 7 sp1 servers for chatting, I wondered if it still could be merged for edgy
<tfheen> TMM: no, sorry.  Too late.
<TMM> tfheen: ok
<TMM> edgy-updates perhaps?
<tfheen> maybe, but that's not my call.
<infinity> If you can isolate the patch that fixes that one bug, it could do -updates, sure.
<pitti> I approved command-not-found, just in case we do want it in edgy; if not, we'll certainly want it for feisty anyway
<infinity> Upgrading to a new upstream at this point (or in -updates) is likely unacceptable.
<TMM> infinity: ok! I'll try to find it
<TMM> infinity: ok, I'll try the rc install now
<TMM> wish me luck :)
<wasabi> Um. I need RedHat edumacation. Trying to track down a patch which is in "rawhide".
<wasabi> I get the gist of what rawhide is. Just can't figure out WHERE it is.
<thom> wasabi: they call it development, under fedora
<wasabi> Is it like an rpm archive in the style of apt archives?
<wasabi> Where I can go pull a .srpm out of and pull apart?
<thom> http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/development/source/SRPMS/
<thom> something like that
<wasabi> Ahh hah
<wasabi> The links on their pages are to broken HTTPish things. 
<wasabi> At least, broken in Ephy
<thom> work for me
<Burgwork> wasabi: remove the  http://www.mirrorservice.org/sites/ and it works
<thom> under ffox (i'd use ephy but it's SSL support is tragic)
<infinity> tfheen: orage/4.3.99.1svn+r23486-0ubuntu1, hwdb-client/0.6-0ubuntu16, ktorrent/2.0.3+dfsg1-0ubuntu1, ekiga/2.0.3-0ubuntu3, edgy-gdm-themes/0.7-0ubuntu2, edgy-wallpapers/0.7-0ubuntu2
<wasabi> Cool. Got what I needed.
<fschoep> dholbach: instead of insta-e-mailing I decided to get on IRC :)
<dholbach> hey fschoep
<dholbach> i was just doing screenshots for you ;)
<fschoep> dholbach: OK, great :-)
<fschoep> dholbach: Odd thing about the icons - they are in the right place but won't show up yet.
<dholbach> fschoep: but try:   killall nautilus gnome-panel     should restart most of it. (alternatively you can restart the session).
<fschoep> I tried logging out and in
<dholbach> oh, that should have done all there is
<fschoep> dholbach: is the new Nautilus icon showing up for you?
<dholbach> fschoep: yes - hang on, I send out the mail in a sec
<fschoep> OK, sorry :-)
<dholbach> ok sent it out
<fschoep> dholbach: screenshot looks awesome
<dholbach> so that's how it should look?
<fschoep> dholbach: yes
<dholbach> hmhmhmhmhm
<fschoep> dholbach: can I borrow your machine? You can have mine
<dholbach> hehe - let's talk about the deal over a few beer again ;)
<dholbach> fschoep: only if I get your band's cds with that box ;)
<fschoep> dholbach: Deal ;) I also installed 2Gb of RAM today, that should be enough, right?
<dholbach> you could try running        sudo gtk-update-icon-cache /usr/share/icons/Human
<dholbach> but I doubt that's the problem
<fschoep> Oh the 2Gb part was just kidding, I'll try the update command
<dholbach> dpkg -l human-icon-theme    says?
<dholbach> (which version?)
<fschoep> dpkg says 0.7-0ubuntu1
<fschoep> update icon theme doesn't seem to have worked
<fschoep> logging out & in once again
<fschoep> hmm, no luck
<dholbach> let me install the package on another box
<fschoep> I'll try a rm -Rf /usr/share/icons/Human and reinstall the package
<fschoep> That worked
<fschoep> dholbach: moving /usr/share/icons/Human and reinstalling the package worked.
<dholbach> it works for me on that other box too
<dholbach> so we're both happy and Mark is happy
<fschoep> dholbach: that last part remains to be seen but should be yes :-)
<dholbach> apart from the media icon - but that's something we need to check in feisty
<fschoep> Yes, I have no clue why it doesn't show up at all
<freshmouse> Hello.
<fschoep> dholbach: on your second machine it worked by only installing the package?
<dholbach> fschoep: yes
<fschoep> dholbach: OK, my installation was probably slightly modified
<dholbach> mdz: we're as ready as we can get with human-icon-theme
<TMM> well, it all seems to have worked quite well
<dholbach> (and I have the mail to ubuntu-doc prepared already also)
<freshmouse> I have "a little" problem with U. EE (I have 1/2 of EE and 1/2 of DD), but I don't know if I'm on the right place (#ubuntu?)... I have a problem after dist-upgrade...
<infinity> freshmouse: You want #ubuntu
<freshmouse> infinity: OK.
<TMM> infinity: I found just 2 small problems, one in the installer, and that my panel resolution wasn't detected properly but, it never was (I need 915resolution)
<fschoep> dholbach: one tiny bit
<dholbach> fschoep: yeah?
<fschoep> dholbach: the small help icon (16x16)
<fschoep> dholbach: it's probably re
<fschoep> dholbach: scratch that, let's leave it at this for now
<dholbach> ok
<fschoep> :)
<mdz> dholbach: sabdfl is online right now if you can get confirmation from him that it's correct
<dholbach> sabdfl: hi Mark - can you take a look at http://daniel.holba.ch/temp/human-icon-theme_0.7-0ubuntu1_all.deb and say how it feels to you?
<dholbach> sabdfl: it has some small changes since the last update
<sabdfl> dholbach: firefox barfs
<dholbach> urg :-(
<sladen> crash barf, or 404 barf
<Treenaks> text/plain barf, I guess...
<dholbach> sabdfl: hum... can you wget or curl it?
<zoobab> hi
<zoobab> do you know if Edgy has support for LTSP?
<bhale> zoobab: check out edubuntu
<bhale> zoobab: its all about LTSP
<dholbach> mdz, sabdfl: I uploaded the source package now too, as I need to take my dog out for a bit. If you decide to upload it - just go ahead, I'll mail ubuntu-doc@ afterwards.
<dholbach> mdz, sabdfl: to http://daniel.holba.ch/temp that is
<sladen> Treenaks: if firefox is getting Encoding Gzip, it's still punting the file off to gedit compressed;  is that the one
<Treenaks> sladen: no, if you mis-configure your webserver, it'll send .debs as text/plain, and choke on binary junk
<sladen> Treenaks: yeah, this is more generally
<sladen> Treenaks: technically I believe it's correct, it's just not useful
<Treenaks> agreed :)
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/console-setup.diff updated and tested, and I think ready for upload now
* highvoltage wonders what nixternal is doing
<mdke__> seb128: no.
<mdke__> seb128: is mpt's idea
<mdke__> seb128: just an idea, anyway. That's a braindump right now
<Lure> mdz, mjg59: workaround for bug 60442 is confirmed at least for one reporter
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Confirmed]  http://launchpad.net/bugs/60442
<tfheen> Kamion: console-setup> approved.
<Kamion> thanks
<tfheen> sorry about the delay.
<dholbach_> tfheen: human-icon-theme is ready (fschoep and I are ok with it), sabdfl still needs to take a look. I deposited the source package (along with the deb) at http://daniel.holba.ch/temp - if you should plan to do it ASAP, go ahead without me. I'll be gone for the day in a bit.
<Kamion> I've uploaded usplash (usplash_down fix on amd64) and casper (modelcode) and am uploading gfxboot-theme-ubuntu and console-setup shortly
<tfheen> dholbach_: can you mail both sabdfl and fschoep to tell me if they are OK with it and if so tell me?  Please also remind them that artwork freeze is today.
<tfheen> Kamion: excellent, thanks.
<dholbach_> tfheen: Ok, will start an email thread.
<Kamion> slight tweak to gfxboot-theme-ubuntu from my earlier patch; it should also adjust its internal keymaps
<tfheen> dholbach_: thanks.
<fschoep> dholbach: ping
<dholbach> fschoep: pong
<dholbach> got your mail
<fschoep> dholbach: OK, can you make something out of it?
<fschoep> dholbach: Can I help out with something?
<Nafallo> Kamion: ah, s usplash-down wasn't supposed to work this morning on amd64 then :-). thanks, I've thought that was fixed with RC, so I got worried :-)
<dholbach> fschoep: you could get me the name and address
<dholbach> mail address
<Kamion> right, it was inadvertently broken by the reversion to vga16
<dholbach> so i can squeeze it into the copyright file
<fschoep> dholbach: Nstor Navas, nestor.navas@gmail.com
<dholbach> release team: just got a wallpaper update - will work on it now
<dholbach> fschoep: have a creative and nice name for the one we had before?
<gnomefreak> does an error 15 file not found on boot a grub ,livecd, or kernel issue. win2k starts fine. and alternate cd installs fine and boots fine
<Kamion> dholbach: thanks
<fschoep> dholbach: "Ubuntu smooth chocolate"  was fine with Jozef
<fschoep> dholbach: ;)
<dholbach> alrighty
<Kamion> 15 : File not found
<Kamion>      This error is returned if the specified file name cannot be found,
<Kamion>      but everything else (like the disk/partition info) is OK.
<Kamion> ^-- grub info documentation
<dholbach> fschoep: and for the new one?
<fschoep> dholbach: "Simple Ubuntu" is fine
<dholbach> fschoep: shall I kick simple-ubuntu out of edgy-community-wallpapers?
<fschoep> dholbach: yes, please
<dholbach> alrighty
<Nafallo> dholbach fschoep: the edgy artwork that got rejected... is that in a seperate package now or something like that?
<dholbach> Nafallo: no, didn't have the time
<fschoep> Nafallo: not really, you can get it on the Wiki though
<dholbach> sorry
<Nafallo> hmm, should be easy enough to create such a package for me? :-)
<gnomefreak> Kamion: i can safely assume its a grub issue (or files not being copied correctly issue) and hopfully will be fixed for release
<Nafallo> I meant... I can probably do that.
<dholbach> Nafallo: you're packaging king
<dholbach> right
<fschoep> Nafallo: ;)
<Kamion> gnomefreak: it won't be fixed for release, sorry
<gnomefreak> k
<Kamion> I have no idea exactly what the above is - I was just supplying a bit more information to help you track it down
<Nafallo> fschoep: could you strip the pre-release text from that artwork or something? :-)
<Kamion> at least, it won't intentionally be fixed for release :-) I'm running out of time today
<gnomefreak> i cant track it down i threw away those 3 installs early this am
<fschoep> Nafallo: the Wiki has the designs without the text, shall I give the link?
<Nafallo> fschoep: please do :-)
<Nafallo> thanks :-)
<fschoep> OK, hold - moving to a different setup
<TMM> is there anything else I can do? 
<Nafallo> dholbach: are you using bzr for the artwork yet? :-)
<dholbach> yes
<dholbach> i am
<dholbach> ubuntu-art-pkg team on launchpad
<Nafallo> kewl. I'll try to use that then :-)
<fschoep> Nafallo: https://wiki.ubuntu.com/Artwork/Specs/EdgyArtworkPlan/Produce/Incoming/CurrentDefault
<fschoep> Nafallo: https://wiki.ubuntu.com/Artwork/Specs/EdgyArtworkPlan/Produce/Incoming/CurrentDefault?action=AttachFile&do=get&target=26-09-06.tar.gz
<fschoep> Nafallo: those links have all the information you need, I see Daniel's given you a pointer to bzr branches?
<Nafallo> fschoep: yepp :-)
<fschoep> seb128: ping
<fschoep> dholbach: did you already read Mark's new mail on the lsplash background?
<dholbach> fschoep: no
<fschoep> dholbach: OK, we should change the background color on top of which the lsplash is shown
<dholbach> ah alrighty
<seb128> fschoep: pong
<fschoep> dholbach: have you got any idea where that is stored?
<dholbach> is that in the edgy-wallpapers .xml file?
<fschoep> seb128: see the last few lines
<dholbach> I'llfind out
<fschoep> dholbach: it's not in there I think
<dholbach> might be in edgy-gdm-themes
<fschoep> dholbach: OK, one thing that might happen is that lsplash suddenly looks ugly
<dholbach> should be in ubuntu-artwork's changelog - seb128 made that change
<fschoep> because it's anti-aliased to the old color
<fschoep> shall I try to do something about that?
<dholbach> we'll find out soon enough ;)
<seb128> dholbach: what?
<dholbach> seb128: background color when you logged in
<dholbach> as soon as you logged in
<fschoep> I'm going to check it in GIMP and work on the edges if it's problematic
<seb128> GraphicalThemedColor=#2b0600
<seb128> gdm.conf specify it
<dholbach> oh, that's in gdm.conf :/
<fschoep> seb128: wow, thanks :)
<seb128> fschoep: np
<dholbach> Mark wants to have #dab082
<dholbach> (for the change I'm just preparing)
<seb128> dholbach: I can do the change if you want
<seb128> for gdm
<dholbach> that'd be cool
<Kamion> tfheen: orage/4.3.99.1svn+r23486-0ubuntu1 hwdb-client/0.6-0ubuntu16 ktorrent/2.0.3+dfsg1-0ubuntu1 ekiga/2.0.3-0ubuntu3 edgy-gdm-themes/0.7-0ubuntu2 edgy-wallpapers/0.7-0ubuntu2
<seb128> dholbach: k, doing it
<dholbach> seb128: I'll just prepare the new artwork, so you can test it
<seb128> dholbach: cool, let me know when it's ready
<dholbach> righty
<fschoep> dholbach: the edges are a problem
<fschoep> dholbach: I'll try my best to work to a solution
<dholbach> super
<o_cee> Till Kamppeter isn't around in here?
<dholbach> o_cee: no, not currently
<o_cee> dholbach: you know what username he goes by?
<dholbach> fschoep: if we have to update edgy-session-splashes too... so be it
<Kamion> till_kamppeter I think
<dholbach> o_cee tkamppeter
<Kamion> oh, sorry, what dholbach said
<fschoep> dholbach: seems like it yes
<o_cee> k thanks, will leave him a message
<cbx33> hey fschoep 
<Kamion> o_cee: mail is probably a better plan
<fschoep> hey cbx33
<fschoep> cbx33: joining in on the fun?
<o_cee> Kamion: mm ok
<Kamion> a lot of people don't notice memoserv these days
<o_cee> true
<Nafallo> fschoep: does the artwork have a name? :-)
<Kamion> tfheen: I also have a couple of oem-config changes I forgot to upload (sorry!):
<Kamion>   [ Colin Watson ] 
<Kamion>   * Remove /var/lib/kdm/kdmsts in oem-config-firstboot after removing the
<Kamion>     oem user; KDM stores the default user there.
<Kamion>   [ Anirudh Ramesh ] 
<fschoep> Nafallo: I called it "Ubuntu Wave"
<Kamion>   * KDE frontend: Fixed bug where set_country combobox was not being
<Kamion>     updated.
<Nafallo> fschoep: okidoki :-) wave-look it is then :-)
<cbx33> fschoep, just saw your name pop up old buddy old pal
<fschoep> cbx33: :)
<Kamion> tfheen: at least the first of those was noticed during RC testing, and I'm confident in the second
<fschoep> dholbach: do you know if the new usplash is in?
<dholbach> fschoep: I think tfheen uploaded it
<fschoep> dholbach: OK, great
<o_cee> ah yeah btw, is beagled supposed to always eat 100% cpu when idle? don't remember it doing that earlier
<Kamion> and I need to update oem-config to new localechooser and console-setup I think
<TMM>  I did find another bug that didn't happen with my dapper > edgy upgraded system, but does accure now that I did a 'proper' edgy install: if I close my laptop lid, and reopen it, the screen isn't turned on
<TMM> where should I file that?
<TMM> mjg59: any ideas?
<dholbach> fschoep, seb128: it's at http://daniel.holba.ch/temp - updated edgy-community-wallpapers to follow
<seb128> brb
<tkamppeter> o_cee, I am here.
<o_cee> tkamppeter: great! :)
<tkamppeter> Did you do the last steps which I described (stop hplip, turn off/turn on printer, remove print queue, re-create queue?
<o_cee> yeah, only difference was that i only got one port to chose from..
<o_cee> and some errors from hplip when trying to print
<seb128> dholbach: looks good, uploading gdm now
<o_cee> but as i said, the printer makes other noises when i've got the drivers installed manually.. it turns on, then off, then on again.. now it just turns on once and then off.. (hehe)
<dholbach> seb128: the color fits and all?
<seb128> dholbach: looks fine to me, there is a black border around the splash though
<dholbach> seb128: fschoep is fixing it
<seb128> dholbach: if you want to try just change your /etc/gdm/gdm.conf by hand
<dholbach> seb128: what is the background called in the wallpaper chooser?
<seb128> faster than uploading a new package :)
<seb128> "Ubuntu Wave"
<Kamion> mdz: I can't fix bug 66881 without breaking the string freeze, since that help file is translated (fairly well by now). Do I have a string freeze exception, or should I skip it?
<Ubugtu> Malone bug 66881 in debian-installer "Help text is misleading or inaccurate for boot methods" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66881
<dholbach> seb128: ok, so you didn't have edgy-wallpapers 0.7 in the meantime
<tkamppeter> o_cee, do the following:
<dholbach> it should be 'simple ubnutu' though
<dholbach> ubuntu
<seb128> dholbach: I didn't upgrade today if that was a package from today
<dholbach> *nod* it was
<seb128> I'm not that an upgrade maniac ;)
<dholbach> for me it's 'ubuntu chocolate' which is completely wrong
<tkamppeter> 1. Stop HPLIP: "sudo /etc/init.d/hplip stop"
<dholbach> strange that the name is not updated
<dholbach> at least not for the already 'chosen wallpaper'
<o_cee> tkamppeter: yep, stopped.
<dholbach> but i guess that's just a small bug somewhere
<tkamppeter> 2. reload "usblp" kernel module manually: "sudo rmmod usblp; sudo modprobe usblp"
<seb128> dholbach: I should probably modify libgnome too then (the 'plain color background' color)
<tkamppeter> 3. "lpinfo -v", post output
<seb128> dholbach: that's the color used when you set no background or the one you see when switching
<dholbach> seb128: I think that's what you change in the xml file
<dholbach> seb128: in /usr/share/backgrounds
<o_cee> tkamppeter: hold on, cups is thinking.. hard..
<dholbach> seb128: I meant /usr/share/gnome-backgrounds-properties/
<dholbach> ok... upload edgy-wallpapers and edgy-community-wallpapers
<o_cee> tkamppeter: privmsgd you
<TMM> hum, looks like a gnome-power-manager fuckup
<fschoep> dholbach: still working on the lsplash, how much time do I have left?
<dholbach> take your time
<dholbach> i uploaded the other packages already, so that's cool
<o_cee> tkamppeter: any more ideas?
<fschoep> dholbach: OK
<cypher1_> anybody here working on usplash bugs ?
<Nafallo> cypher1: almost everyone ;-)
<cypher1_> Nafallo, the issue seems pretty hot
<cypher1_> i can see lot of ppl facing it
<cypher1_> is a fix is released ?
<Nafallo> cypher1: amd64 users? in that case Kamion uploaded something already :-)
<cypher1_> i am triaging bug 66607, bug 66998
<Ubugtu> Malone bug 66607 in usplash "No usplash at all" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66607
<Ubugtu> Malone bug 66998 in usplash "usplash shows nothing on screen" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66998
<cypher1_> Nafallo, no even ppl on x86 with different video hardware
<cypher1_> i guess all of them are facing the problem only when they are upgrading
<Nafallo> k
<cypher1_> Nafallo, can i help with something on the usplash bugs ?
<dholbach> fschoep: how's it looking?
<Nafallo> cypher1: no idea. I wouldn't touch it :-)
<fschoep> dholbach: give me ten minutes, OK?
<cypher1_> Nafallo, ok
<dholbach> fschoep: alrighty
<fschoep> dholbach: I think Mark is (going to be) AFK now, but the design hasn't changed much - should be OK
<dholbach> fschoep: yeah
<cypher1_> dholbach, can one request to raise the severity of a bug ?
<dholbach> cypher1: everybody in the ubuntu-qa team can do it
<cypher1_> dholbach, imho bug 66607 needs to be looked at very fast
<Ubugtu> Malone bug 66607 in usplash "No usplash at all" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66607
<cypher1_> dholbach, i will join it
<dholbach> talk to sfllaw
<cypher1_> sfllaw, hi
<sfllaw> cypher1_: Hi.
<sfllaw> cypher1_: You want to join Ubuntu QA?
<cypher1_> sfllaw, yes.. just subscribed to it too :)
<dholbach> cypher1_: around how many bugs did you triage already?
<fschoep> dholbach: three minutes
<cypher1_> dholbach, really not much
<dholbach> fschoep: rock on
<dholbach> cypher1_: ok... I guess you will need to work some more on bugs then.
<cypher1_> dholbach, ok no problem :)
<sfllaw> cypher1_: Please read the Wiki on Bugs/HowToTriage so that when you apply again in a few days, you'll have great triaging to show me.
<dholbach> usually severity is a tool for maintainers to organize their amount of work
<sfllaw> :)
<cypher1_> but i was really concerned about one bug i am looking at
<sfllaw> cypher1_: Which?
<dholbach> bug 66607, right?
<Ubugtu> Malone bug 66607 in usplash "No usplash at all" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66607
<cypher1_> bug 66607
<dholbach> Ok...
<cypher1_> and its variants
<sfllaw> What happened to ubugtu?
<sfllaw> Ah.
<sfllaw> I get this one.
<sfllaw> It's going to be a Medium priority bug at most.
<sfllaw> Do you experience it?
<cypher1_> sfllaw, but ppl are going to face it every time they boot
<cypher1_> sfllaw, no i am still in dapper :(
* cbx33 goes for a reboot
<cypher1_> cypher1, and by the response i am seeing ppl are really looking forward for a quick solution i guess
<cypher1_> bug 59651, bug 59994, bug 64400 etc etc
<Ubugtu> Malone bug 59651 in usplash "usplash does not come up after dapper-edgy upgrade" [Undecided,Needs info]  http://launchpad.net/bugs/59651
<Ubugtu> Malone bug 59994 in usplash "[edgy]  no shutdown splash" [Low,Confirmed]  http://launchpad.net/bugs/59994
<Ubugtu> Malone bug 64400 in usplash "Usplash doesn't show at all" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64400
<fschoep> dholbach: just a few more minutes, my network's gone fubar
<dholbach> fschoep: ok :)
<fschoep> dholbach: sorry to sound like a broken record :P
<dholbach> hehe :)
<cypher1_> gtg 3am.. need sleep
<cypher1_> bye all
<fschoep> dholbach: it's on the mail
<roshan_s> fschoep: Thanks for the last-minute Edgy artwork, which you must have produced under great pressure. Because of you, we won't be stuck with the stuff from Dapper especially the messy (imho) wallpaper :)
<fschoep> roshan_s: no need to thank me, there's a whole lot of people behind the scenes who worked on this stuff. And dholbach deserves more credit than me here, I think.
<fschoep> roshan_s: but, thanks anyway of course :)
* fschoep hugs dholbach 
<dholbach> fschoep: not true - you guys worked HARD on it :)
* dholbach hugs fschoep back
<fschoep> :)
<roshan_s> Well, then, thanks to dholbach too, and everyone on ubuntu-art who managed to salvage edgy from the reversion to Dapper artwork...
<gnomefreak> we have some edgy artwork now?
<fschoep> gnomefreak: yes, kind of - it's still being uploaded :P
<BenC> tfheen: ping
<tfheen> BenC: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<gnomefreak> cool thank you guys.
<fschoep> gnomefreak: you're welcome
<BenC> tfheen: I got your content right here :P
<BenC> tfheen: bug 62135, I have a fix for i965_dri.so, so that gl actually works for i965 chipsets...just needs i965_dri.so to be compiled with gcc-3.4
<Ubugtu> Malone bug 62135 in mesa "Support for Intel 965 (GMA X3000) doesn't work" [High,Confirmed]  http://launchpad.net/bugs/62135
<BenC> tfheen: Let me know if you want me to upload this
<dholbach> fschoep: good work!
<fschoep> dholbach: so at least three people like it :)
<fschoep> brb
<dholbach> uploaded
* sfllaw hugs fschoep.
<dholbach> tfheen, Kamion, mdz, infinity: seb128 and I uploaded: gdm edgy-session-splashes edgy-wallpapers edgy-community-wallpapers - please approve
<mdke__> nice work chaps
<dholbach> tfheen, Kamion, mdz, infinity: human-icon-theme is still missing, needs Mark's 'ok'.
* dholbach hugs mdke
<dholbach> mdke: I'll mail ubuntu-doc@ once it's all in
<seb128> mdke: hi, Mr "I want 4 top menu items on the panel" :p
<mdke> seb128: hi
<mdke> dholbach: thanks, but we don't have any screenshots, so no worries
<dholbach> mdke: oh, I'm glad this didn't cause you grieve
<fschoep> dholbach: super
* fschoep hugs sfllaw
<dholbach> PHEW :)
<fschoep> Can't we just get the icons in though?
<dholbach> fschoep: I mailed everybody involved
<fschoep> dholbach: I saw that
<dholbach> fschoep: if I get an 'ok' mail tomorrow, I'll upload it
<fschoep> dholbach: OK, tomorrow is still good then?
<dholbach> I suppose so
<fschoep> dholbach: Alright, I'm pretty sure there won't be issues
<fschoep> dholbach: so, this is it for tonight then?
<dholbach> I'm not going to bed now ;)
<dholbach> but I call it a day ;)
<fschoep> dholbach: OK, thanks so much for your efforts, you're amazing. Everyone here is, cheers!
<dholbach> you... most of all
<dholbach> have a great weekend!
<gnomefreak> dholbach: have a good weekend too
<sandrinah> hi all
<dholbach> thanks gnomefreak
<gnomefreak> yw 
<gdh> as per https://lists.ubuntu.com/archives/ubuntu-bugsquad/2006-October/000092.html I'm here to relate my experiences with the RC ...
<gdh> and it's not good. I got stung by https://launchpad.net/distros/ubuntu/+source/xorg/+bug/64825 - can this be affecting every system in the world with a cheap X300/X600 ATI Radeon ?
<Ubugtu> Malone bug 64825 in xorg "Installer won't detect video card Radeon X600" [Undecided,Unconfirmed]  
<gdh> it chooses 'ati' instead of 'radeon' for xorg :/ - changing to 'radeon' in xorg.conf makes X start + run beautifully 
<gnomefreak> isnt radeon non-free?
<gdh> gnomefreak: if it is, it's on the Live CD.
<gdh> fglrx is the ATI-provided binary warez driver
<gdh> I'm not at all concerned about 3D performance or games, but I think it's not too much to expect working 2D on a very popular gfx card :)
<gnomefreak> ah xserver-xorg-video-ati brings in -radeon
* mconnor idly wonders which Firefox security release had a 30k line diff from the previous version
<gdh> mconnor: unless it's the first hint of iceweasel? :)
<mconnor> gdh: if Martin and Ian are claiming that's the upstream diff, I'm pretty curious about when that was supposed to be
<Kamion> which version exactly?
<mconnor> they didn't say
<Kamion> shouldn't take long to search through all the uploaded .orig.tar.gz files
<Kamion> let's see ...
<mconnor> I mean, its possible, there's been a few releases where we fixed dozens of security bugs in a single release, largely because our internal security testers are too smart :)
<Kamion> $ diff -Nru firefox-1.5.dfsg+1.5.0.4.orig firefox-1.5.dfsg+1.5.0.5 | filterdiff -x '*/CVS/*' | wc -l
<Kamion> 50621
<Kamion> there's one that exceeds that, anyway
<Kamion> I have mail from Ian saying that the 1.5.0.2 diff was 35000 lines
<gdh> bah mumble mumble epiphany mumble mumble :)
<Kamion> isn't it usually "security and stability"? that generally seems to be the explanation for the diffs being huge
<mconnor> heh, the fixes are to gecko 98% of the time
<gdh> ah fair enough.
<gdh> Nobody has a Radeon X300 or X600 then?
<Kamion> mconnor: $ diff -Nru firefox-1.5.dfsg+1.5.0.1.orig firefox-1.5.dfsg+1.5.0.2.orig | filterdiff -x '*/CVS/'* | wc -l
<Kamion> 35460
<Kamion> so Martin and Ian's figures seem pretty accurate from here
<gdh> ouch
* mconnor wonders if that was the one where we fixed 60+ sec bugs :)
<Kamion> all the releases have been huge, from what Ian tells me
<mconnor> yeah, rollup releases end up with a lot of bugs
<Kamion> anyway, I don't know the specifics, but you asked for backup for the cited statistics - there's two pieces of backup
<Kamion> the complaint I normally hear is that many of the items in the rollup releases are not just security bugs
<Kamion> I haven't investigated that personally, so that's second-hand
<Kamion> I know Ian generally analyses the diffs as best he can
<Kamion> (which I'm sure he'd be the first to say is to a limited extent)
<mconnor> heh
<mconnor> ah, I see
<mconnor> 1.5.0.2 had a large set of changes to support Intel macs, but most of that code isn't built for Linux
<Kamion> 1.5.0.3 was small
<Kamion> $ diff -Nru firefox-1.5.dfsg+1.5.0.2.orig firefox-1.5.dfsg+1.5.0.3.orig | filterdiff -x '*/CVS/'* | wc -l
<Kamion> 184
<Kamion> $ diff -Nru firefox-1.5.dfsg+1.5.0.3.orig firefox-1.5.dfsg+1.5.0.4.orig | filterdiff -x '*/CVS/'* | wc -l
<Kamion> 27462
<Kamion> another biggie
<mconnor> there was a few endian fixes in there too, that would have helped Linux
<Kamion> it's the big ones people remember
<Evaso2> any fix with the bug of pci-express ati bug seems that is very common: 35601
<Kamion> Intel Macs> see, that's exactly the sort of code we normally don't let into our -security branches ;-)
<Kamion> firefox is the only product we have to make an exception for there
<mconnor> except that you don't build that code, unless you're building for Mac :)
<mconnor> but that was a one-time thing
<Kamion> ... as far as we know. Not knowing the build system, we can't prove that to our own satisfactions
<mconnor> I guess the windows changes to support Vista will be the same...
<mconnor> Kamion: its all about trust!
<mconnor> though I could give crash courses ;)
<Kamion> it's not a one-time thing, if new hardware support is something you routinely import
<Kamion> right, our users trust us to keep our changes in -security minimal ...
<mconnor> its not
<Kamion> people use distributions because they want somebody to do the integration for them, which involves a transferral of trust
<mconnor> so does -security not allow for crash fixes?
<Kamion> depends on the crash. if it's simply data-loss, that would normally go to -updates
<Kamion> as far as possible, -security means what it says
<Kamion> but sure, if it's a potentially exploitable crash then that can/should go to -security
<Kamion> one of our problems is that -security is a fast-path to users' desktops
<mconnor> we consider all crashes exploitable unless proven otherwise
<Kamion> (obviously that's not *normally* a problem)
<gdh> :) Wow, I suddenly see my work life appear...
<Kamion> the reason we demand auditing for all -security uploads is that once it leaves the developer's hands, it lands on users' desktops as fast as we can humanly manage it and there's very little opportunity to stop it if it turns out to be bad
<gdh> oddly, *everything* is 'urgent' there...
<gdh> everyone's 'issue' is priority 1
<gdh> thus defeating the point of priorities <slump>
<mconnor> gdh: imagine trying to prioritize features for Firefox! :)
<Kamion> the recent xorg breakage in -updates made us much more cautious about fixes there, so we now have a process involving sending stuff via -proposed for a trial period
<Kamion> but we can't do that for -security
<gdh> ZOMG flash player should be compiled in statically  (yawn) and so on
<Kamion> crashes exploitable unless proven otherwise> I agree, very sensible
<Kamion> firefox is on a security boundary though, which is not the case for everything (from our point of view)
<mconnor> yeah, web browsers are the best target these days, now that every mail client in the world is locked down and virus/spamfiltered to death :)
<ajmitch> morning all
<Kamion> (and yet evolution still crashes every five minutes or if you breathe in its direction too hard ...)
<mconnor> funny, I was never able use evolution for more than five minutes at a time, but that was just because I couldn't stand it :)
* Kamion <- die-hard mutt user
<mconnor> one of the gecko guys is like that too
<_ion> mutt 
<mconnor> I'm, uh, using mail.app
* mconnor hides
<_ion> Although it has its fair share of flaws.
<Kamion> I'd expect Mozilla is a rather biased camp as far as MUA choice goes?
#ubuntu-devel 2006-10-21
<mconnor> Kamion: so really, my answer to that is to get involved with upstream maintenance, to see bugs as they land etc
<mconnor> (about controlling what goes in)
<mconnor> Kamion: re MUA, you'd think so
<mconnor> but really no
<Kamion> that's fair, and I know Ian's been trying - it's a big learning curve for somebody who never touched Mozilla source before joining Ubuntu though
<mconnor> a lot of people use thunderbird, a lot of others use mail.app/outlook/gmail/random
<fschoep> Kamion: suppose I could fix bug 66107 in a few minutes, could we do something with it for the release?
<Ubugtu> Malone bug 66107 in usplash-theme-ubuntu "Placeholder Theme is a Regression" [Wishlist,In progress]  http://launchpad.net/bugs/66107
<mconnor> Kamion: that's part of the thing that scares me
<Kamion> good developer-oriented changelogs would really help, though
<Kamion> mconnor: not every distro can hire Mozilla hackers right off the bat
<mconnor> Kamion: well
<sfllaw> Riddell: Is the kubuntu desktop CD supposed to do WinFOSS under Windows?
<sfllaw> Because it sort of fails to.
<mconnor> Kamion: sure, we're recruiting them first ;)
<mconnor> Kamion: its more that its a hard codebase to learn, and its hard for people on the outside to evaluate
<Kamion> mconnor: so really Mozilla needs to be working on the assumption that its downstreams are bootstrapping as best they can, but need guidance
<mconnor> Kamion: i.e. there's like four people in the world who really understand the JS engine, if they say its safe, I believe them, because they have a very strong track record
<Kamion> fschoep: probably, yes
<mconnor> Kamion: problem is, detailed changelogs and checkin comments make it pretty easy for black hats to figure out what's changing :)
<Kamion> it would be OK for the detailed changelogs and checkin comments to only become visible to the world after the release is unembargoed
<Riddell> sfllaw: yes
<fschoep> Kamion: OK. I can only fix the artwork part (provide new PNGs), I'd need someone else to update the version number and upload it. Do you know someone who could do that for me?
<mconnor> Kamion: sure, but even better is to just watch the bugs as they happen, and instead of diverging, influence our changes :)
<Kamion> fschoep: I guess I can munge it into shape
<fschoep> Kamion: will you be here for another fifteen minutes?
<Kamion> mconnor: I recognise that's the ideal, but do remember that distro packagers aren't working anywhere near full-time on Mozilla - Ian for example has a number of other significant projects
<Kamion> and yet sometimes we have urgent pressures of our own which we need to have the flexibility to be able to deal with in-house in a hurry
<Kamion> which free software gives us :)
<Kamion> fschoep: yeah
<fschoep> Kamion: OK, great - I'll be back in a jiffy with the new stuff
<fschoep> Well, not exactly new, but updated
<mconnor> Kamion: yeah, it just makes it harder for us to say that Ubuntu's Firefox == Mozilla's Firefox, which is the big problem
<Kamion> right, I don't think I want to get into that particular debate at 11:15pm on a Friday night :-)
<Kamion> (I've stayed resolutely out of it so far)
<Wikipedia-Gast90> why
<keescook> fabbione, infinity: I'm packaging the security-fixed nvidia driver (8774->8776).  debuild -S doesn't like me.  :)
<Wikipedia-Gast90> keescook sucks
<Kamion> oh, wow, we have an nvidia fix? Excellent.
<ajmitch> yes, they were good enough to get 8776 out
<Wikipedia-Gast90> Kamion sucks
<Wikipedia-Gast90> ajmitch sucks
<keescook> Kamion: yeah, they just released it.  the -legacy one isn't vulnerable, they say, which is nice.
<Wikipedia-Gast90> keescook: you suck
<ajmitch> just 8762 & 8774, wasn't it?
* keescook wonders where the chan ops are.
<Wikipedia-Gast90> ajmitch sucks
<Wikipedia-Gast90> keescool: the ops are in your ass
<keescook> ajmitch: yup.
<Wikipedia-Gast90> keescook is gay
<mconnor> Kamion: afaict, following 1.5.0.* branch is like a bug or two a day, seems easier to spread out than big bang when we release :)
<Wikipedia-Gast90> mconnor sucks
<keescook> ajmitch: I meant that 7184 isn't vuln.
* gdh would like to thank Gentoo for sending a representative to -devel :)
<pygi> Wikipedia-Gast90: you'll be kicked
<ajmitch> keescook: right, what does dapper have?
<mconnor> I didn't see the other spam, I figured it was just a debian user
<Wikipedia-Gast90> pygi sucks
<pygi> Wikipedia-Gast90: I seriously suggest you stop!
<mconnor> pygi: its a script/bot, yeesh
<Wikipedia-Gast90> pygi sucks
<jk> he's messing up other channels as well
<mconnor> kline!
<Wikipedia-Gast90> jk sucks
<pygi> mconnor: o joy!
<Wikipedia-Gast90> pygi is a retard
<_ion> Don't i suck? Even a little? :-(
<keescook> anyway, debuild -S doesn't like the new .run files.  Do I need to create a new .orig file to get the stuff in there?
<Riddell> nalioth: Wikipedia-Gast90 
<Wikipedia-Gast90> no, you are a worthless slime
* mode/#ubuntu-devel [+b *!*@84-73-115-78.dclient.hispeed.ch]  by nalioth
* Wikipedia-Gast90 was kicked off #ubuntu-devel by nalioth (nalioth)
<Kamion> keescook: what's the error message exactly?
<keescook> Kamion: dpkg-source: cannot represent change to nvidia/NVIDIA-Linux-x86_64-1.0-8776-pkg2.run: binary file contents changed
<keescook> but looking at the .diff.gz I realize that this is actually something in the .orig.
<Kamion> keescook: you need a new .orig.tar.gz, certainly
<keescook> okay
<Kamion> keescook: or else you have to uuencode it
<mdz> Kamion: I think skip it
<Kamion> mdz: ok. I'd done the change just in case; it's not pretty :(
<sfllaw> Riddell: Will file a bug and target at ubuntu-6.10
<Riddell> sfllaw: it doesn't work?
<mconnor> Kamion: biggest problem is trying to figure out what is the exact nature of the changes you're looking to avoid, and I guess I don't get the split between -updates and -security completely, i.e. does a fix for a regression for a security bug go to -security?
<sfllaw> Riddell: It doesn't.
<Kamion> mconnor: yes, a fix for a -security regression would also go to -security, but would generally receive increased scrutiny just because it had been got wrong before
<sfllaw> Trying to install merely opens a .lch text file.
<sfllaw> It does not actually run the installer.
<Riddell> sfllaw: install anything?
<sfllaw> Nope.
<sfllaw> Let's say I click the "Install" icon for KDE-PIM.
<sfllaw> I get:
<sfllaw> [Launch] 
<mconnor> Kamion: are there any cases of fixes Ubuntu hasn't taken that I can look at in launchpad?
<sfllaw> ExecuteFile=${cwd}\..\programs\kdepim\KdepimSetup.exe
<sfllaw> Whereas I expect KdepimSetup.exe to be executed.
<mconnor> Kamion: trying to wrap my head around this better, since we have a brand new maintenance branch and its easy to amend policy (i.e. 1.0.* was painfully strict on security, and as a result some annoying crashes or bad behaviours were never fixed)
<Riddell> sfllaw: ug
<sfllaw> Is this a casper bug?
<sfllaw> Or some other package?
<Riddell> sfllaw: winfoss is winfoss, not sure where you file it
<fschoep> Kamion: just a few more minutes
<sfllaw> Riddell: I'll leave it in casper for now.
<Riddell> sfllaw: I don't think tfheen will that you for that
<sfllaw> I guess not.
<TMM> Kamion: I think I might have found the offending openoffice.org patch :) rebuilding now... 
<sfllaw> But it is a bug that I found.
<sfllaw> On the LiveCD.
<Riddell> sfllaw: just don't specify a package and make sure heno is subscribed
<Kamion> mconnor: mdz probably has all the good examples of that
* mode/#ubuntu-devel [-b *!*@84-73-115-78.dclient.hispeed.ch]  by nalioth
<Kamion> fschoep: thanks
<sfllaw> Riddell: heno?  OK.
<keescook> within the nvidia subdir there is a debian.binary with it's own changelog.  It looks like it hasn't been touched since Sep 2005.  Should I ignore that file, or does it need an entry for the nvidia update too?
<Kamion> sfllaw: wonder if it's yet another thing being confused by /filesystem.squashfs/
<sfllaw> Unknown.
<sfllaw> I can read the programs directory though.
<sfllaw> And run the setup programs.
<sfllaw> So I think it's probably a MIME type thingy.
<sfllaw> Opening as text instead of launching ExecuteFile.
<Kamion> sfllaw: live CD specific, though?
<sfllaw> Well, WinFOSS isn't anywhere else, right?
<Kamion> oh. winfoss. sorry, thought you meant Kubuntu proper
<sfllaw> Kubuntu WinFOSS.
<Kamion> right, what Riddell said then
<Kamion> mdz: ok to punt all the new artwork through unapproved?
<mdz> Kamion: yes
<Kamion> figured that'd be a no-brainer ...
<sfllaw> Kamion: Make sure it's pretty!
<sfllaw> :)
<Kamion> mm, 'cos the queue interface makes it so easy for me to check that. :)
<claviola> okay, this is a weird question, but... I tried to run "unrar" on a machine and got a warning that I should install either "unrar" or "unrar-nonfree" to have unrar on my machine.  The thing is, which program is displaying that message?  There is *no* unrar on my box at all
<claviola> this is creepy.
<ajmitch> claviola: magic
<claviola> what are you guys up to? :-P
<ajmitch> aka 'command-not-found'
<claviola> ajmitch: oh.  how does that work?  can you link me to something?
<ajmitch> all I know of it is the spec name
<micahcowan> claviola, type "type unrar".
<Kamion> I think it's a bash hook linking up to Contents files, or something similar
<claviola> micahcowan: bash: type: unrar: not found
<claviola> that's what is creepy.
<ajmitch> claviola: https://wiki.ubuntu.com/CommandNotFoundMagic
<claviola> of course I realized something else was doing that on purpose expectedly, I'm just curious how it's done.  it's a nice touch
<Kamion> claviola: yeah, the bash hook gets called if you actually run the program
<ajmitch> and I was right - it even uses magic in the spec name
<Kamion> it's probably best that it doesn't show up in type, so that scripts don't get confused
<Kamion> claviola: I hope unrar still exits non-zero?
<micahcowan> claviola, running edgy?
<claviola> it exits 0
<Kamion> !
<Kamion> that seems like a bug to me - surely that will break scripts
<claviola> sure will
<Kamion> one reason I don't want to promote it to main and have it in desktop for edgy at this stage
<micahcowan> That hook's a Debian extension, apparently.
<micahcowan> Was wondering why I didn't know about it.
<Kamion> claviola: could you file that as a bug?
<claviola> Kamion: sure, why not
<wasabi> Um. automake/conf assistance:  requried file ./compile not found. Not understanding this.
<claviola> what's an easy way to determine if a system is dapper or edgy, btw?  /etc/debian_version is the same old 'testing/unstable'
<Kamion> claviola: lsb_release
* bluefoxicy buhs as firefox repeatedly crashes.
<claviola> ok
<gdh> claviola: base it on the version of libc ?
<Kamion> we deliberately don't change debian_version because there are programs that fall back to that for distribution detection, and if they don't have anything specific for Ubuntu then Debian unstable is probably as good a bet as anything else
<Kamion> gdh: don't do that, please
<Kamion> lsb_release is the interface we provide for this
<gdh> I thought that was a lame idea :)
<lucasvo> Kamion: ping
<Kamion> lucasvo: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
<Kamion> but of course it depends why you want to know which distribution is there
<lucasvo> Kamion: what is the gfxboot-theme-ubuntu for, you packaged?
<lucasvo> Kamion: the makefile doesn't seem to work
<fschoep> Kamion: shall I e-mail the PNGs to you?
<Kamion> lucasvo: it's used on the boot screen of every Ubuntu/Kubuntu/Edubuntu/Xubuntu CD
<Kamion> lucasvo: use dpkg-buildpackage
<Kamion> fschoep: yes please
<Kamion> lucasvo: the Makefile should work fine provided that you install the build-dependencies, though; debian/rules just calls make
<fschoep> Kamion: sent as "usplash-theme-ubuntu-0.4 PNGs", thanks in advance
<lucasvo> Kamion: it has a problem with:  make -C po: no such file or directory
<lucasvo> Kamion: I can't find the command or a package called dpkg-buildpackage :(
<Kamion> lucasvo: well, that directory is certainly there
<Kamion> lucasvo: sudo apt-get install build-essential devscripts fakeroot
<Kamion> (strictly just dpkg-dev, but you might as well have the rest if you're going to be building packages)
<lucasvo> Kamion: is it relative to the current path?
<Kamion> is what relative?
<lucasvo> because /usr/share/gfxboot-ubuntu-theme/ does not have a subfolder po
<Kamion> lucasvo: oh, don't run it in there, that's a known bug
<lucasvo> Kamion: the po-dir
<gdh> lucasvo: You're getting the error because 'make' is not installed
<Kamion> gdh: no he's not
<gdh> no? erps :)
<Kamion> lucasvo: I know about that bug - just ignore the source files in there. only the bootlogo.tar.gz is really useful in that binary package
<Kamion> lucasvo: if you want to build it from source, 'apt-get source gfxboot-theme-ubuntu'
<lucasvo> E: Could not open file /var/lib/apt/lists/ch.archive.ubuntu.com_ubuntu_dists_edgy_universe_source_Sources - open (2 No such file or directory)
<lucasvo> strange
<lucasvo> I already apt-get source-d already packages
<Kamion> you've changed /etc/apt/sources.list since, by the looks of things; 'sudo apt-get update'
<gdh> possible that the ch. mirror isn't .. mirroring edgy yet? :/
<Kamion> $ HEAD http://ch.archive.ubuntu.com/ubuntu/dists/edgy/universe/source/Sources.gz
<Kamion> 200 OK
<gdh> :)
<lucasvo> no, I didn't
<Kamion> well, I expect 'sudo apt-get update' will fix that, anyway
<lucasvo> no it doesn't that's the problem
<lucasvo> :)
<Kamion> lucasvo: I'm not sure what you're going to get out of this exercise, though. :-) What are you trying to do with gfxboot-theme-ubuntu? Just curious?
<lucasvo> I was trying to install it with my grub. but I really don't know if that works
<Kamion> it won't work at all
<Kamion> sorry
<lucasvo> is the livecd using grub at all?
<lucasvo> Kamion: anyway thanks for the help
<Kamion> no, the live CD uses syslinux for its boot screen
<Kamion> fschoep: just upgrading my laptop first so that I can test this
<fschoep> Kamion: no problem
<fschoep> it is very dependent on the screen settings
<fschoep> on my screen I don't normally see the problem, but it is there
<Kamion> this laptop has a 1280x854 panel, so it's usually easy to see not-quite-black rectangles
<fschoep> OK, but the non-black colors are very dark, but I know you know what you're talking about
<Kamion> yeah, may depend on my eyesight too
<fschoep> I must admit I didn't see a problem, but with gamma at 4.0 I can clearly see the issue :-)
<_ion> The new splash is quite okayish. A lot better than the temporary one.
<pygi> _ion: right (I wont enter any discussions), but it's change at last minute once again :P
<pygi> same as always ^_^
<_ion> :-)
<fschoep> Kamion: any luck with it yet?
<Kamion> fschoep: upgrade still running ...
<fschoep> Kamion: ETA?
<fschoep> Kamion: It's just that it's 01:36 here and I can imagine more peaceful things to do :)
<fschoep> But I'd like to be on stand by if the need arrives
<Kamion> yeah, I know, I want to go to bed too - upgrade should be finished inside the next few minutes, then I'll reboot, then shove in the new artwork and reboot again
* Nafallo pushed wave-look
<fschoep> Kamion: OK, thanks - I didn't mean to keep you up, honestly.
<fschoep> Nafallo: :)
<erdalronahi_> ping pitti, doko
<keescook> Kamion, mdz: can you take a quick look at my nvidia debdiff?  (I manually removed the blog changes from this file so I could actually upload it in this lifetime.)
<keescook> http://people.ubuntu.com/~kees/edgy-fixes/nvidia-package-minus-blob-changes.debdiff
* mdz wonders whether keescook forgot that he was in the UK or just assumed he'd be online and working at 0100 on saturday
* keescook forgot :)
<keescook> mdz: but I also saw you talking on the channel earlier.  :)
<mdz> keescook: that can't possibly be the complete diff; where are the upstream changes?
<Fujitsu> `(I manually removed the blog changes from this file so I could actually upload it in this lifetime.)'
<keescook> it's not a complete diff.  I replaced the 2 nvidia blobs also, but that's like 100M of diff.  I'm uploading the full diff and other files ATM
<keescook> though, the gzip'd full diff did just finish now: http://people.ubuntu.com/~kees/edgy-fixes/
<keescook> (only 43M!)
<Kamion> fschoep: ah yes, took a while to see it but was quite obvious once I did
<Kamion> testing the fix now
<mdz> keescook: I think we should hold off on this until after the release
<keescook> mdz: understood.  I'm going to need time to test hoary/breezy/dapper anyway.
<Kamion> fschoep: yep, looking good, thanks! will upload as soon as the laptop's finished booting
<Kamion> fschoep: get some sleep :-)
<Kamion> fschoep_: did you get my comments just now?
<fschoep_> Kamion: I think I just dropped off the net
<Kamion> 01:00 < Kamion> fschoep: yep, looking good, thanks! will upload as soon as the laptop's finished booting
<Kamion> 01:00 < Kamion> fschoep: get some sleep :-)
<fschoep_> Kamion: OK, thanks :)
<fschoep_> Kamion: get some sleep as well :)
<Kamion> fschoep_: I wouldn't mind adding a debian/copyright file though ... who's the author?
<fschoep_> Kamion: that is:
<erdalronahi_> doko_, was it pitti or you who wanted a bug for mozilla-firefox-locale-ku?
<Kamion> fschoep_: and licence?
<fschoep_> Dennis Kaarsemaker <dennis@kaarsemaker.net> , Jonathan Austin <mailforwho@googlemail.com> and Frank Schoep <frank@ffnn.nl>
<fschoep_> I always put myself at the back
<fschoep_> And the license is CC-SA
<Kamion> thanks
<fschoep_> Kamion: so, goodnight then and thanks so much for doing this
<Kamion> not a problem
<fschoep_> BTW, will you also close the bug
<fschoep_> or is that automated or something?
<fschoep_> Kamion: well, I'm off to bed, see you soon hopefully
<doko_> erdalronahi_: -> pitti
<erdalronahi_> ok, he is not here, I think. Good night then.
<wasabi> So I've got this unified diff which is applying weird... it edits a file, and appends to the end of it.    the diff segment starts with the last 4 lines from the opriginal file, then a + for every new line, including a closing +}  because it's a C file and the function is over.
<wasabi> Except that last +} isn't being added.
<wasabi> n/m got it. ;)
<pygi> :P
<nix4me> just wanted to report that edgy rc1 plus current updates works very nicely on Dell Dimension 3000
<doko_> Kamion, mdz: would you consider moving broffice.org into main instead of universe? people from Brazil are asking about this (apparently there is a company which hold trademarks on "OpenOffice"); the package is a dependency package plus it diverts desktop files and icons
<Burgundavia> doko_: don't we use openoffice.org instead of jsut openoffice for that very reason?
<doko_> Burgundavia: seems to be something else, will ask our Brazilian mafia ...
<Kamion> doko_: in feisty, yes
<Kamion> doko_: the current broffice package is broken and will be uninstallable, as far as I can see; it shares files with openoffice.org-common
<Kamion> unless you're pulling some mad tricks
<infinity> keescook: Err, do you need any help with that nvidia/LRM update?
<keescook> infinity: I think I got it figured out, but mdz wants to hold off until after edgy releases.
<infinity> keescook: Fair enough.  I tend to get nervous, personally, when people mangle LRM for the first time. :)
<keescook> did you look at the blobless debdiff?  I just wanted to make sure I got the versioning right for it.
<keescook> it installed and tests out okay for me at least.  :)
<wasabi> Oh. This just gets cooler and cooler.
<Kamion> ok, I'm not going to be around until Sunday and probably not much then, so I'm going to bump edgy CD images to say Release in .disk/info
<wasabi> Guess my bug is now in pam_unix.
<Kamion> I don't expect there'll be many builds between now and Monday, and Monday will probably be nearly the last one
<infinity> keescook: Lookd fine to me.  Replaced the files in /nvidia in the orig.tar.gz, and updated a whopping 1 variable in debian/rules. :)
<infinity> keescook: (updating nvidia is much less hassle than fglrx... If you need to do fglrx at some point, you'll have to talk to me.)
<keescook> infinity: yeah.  not too hard; just had to convince myself I wasn't breaking it.  :)
<keescook> okay, good to know.  :)
<keescook> are there any dedicated systems that have nvidia + old releases?
<infinity> keescook: Rephrase in a way that I can understand after 4 hours of sleep? :)
<keescook> ah, sorry about that.  Are there any computers I can use to test updates of l-r-m on?
<crimsun> Kamion: should http://tiber.tauware.de/~crimsun/lirc_0.8.0-5ubuntu1_to_0.8.0-9ubuntu1.diffstat be a post-Edgy update? It's a straightforward merge from Sid that has been verified to close quite a few bugs (28941, 29641, 45400, 45703, 47997, 53111, 67258).
<keescook> i.e. do we keep hoary + nvidia installed anywhere?
<infinity> keescook: No, we're pretty lacking in a company-sponsored test setup.
<infinity> keescook: I used to use my wife's machine for testing nvidia stuff.
<infinity> keescook: You're not planning on upgrading hoary to 8776, are you?
<keescook> infinity: I need a drive hot-swap bay.  then I can keep a mess of installs.  :)
<keescook> infinity: that's not my first choice, no.
<infinity> keescook: Hoary's current nvidia driver has legacy support, so we'd at least want to wait for them to release an updated -legacy.
<keescook> legacy, says nvidia, isn't vulnerable.
<infinity> Oh, then hoary isn't.
<infinity> Is the whole 7000 series not vulnerable?
<infinity> Cause then breezy's safe too.
<keescook> They say 8178 and earlier are safe.
<infinity> score, then only dapper needs an update.  Easy.
<keescook> nice
<keescook> I hadn't checked earlier versions yet; been busy with qt updates
<infinity> And 8762 -> 8776 in dapper is not going to be painful.
<keescook> very nice.  It looks like the "current" l-r-m build system was introduced in dapper?
<infinity> Yeah.
<infinity> I adopted LRM at the end of breezy and made some changes, but the remval of crack and making versioning and updates simpler happened in dapper.
<infinity> If you ever have to update breezy, you'll want to talk to someone who's been through the pain. :)
<keescook> cool.  I noticed that l-r-m/nvidia/debian.binary/changelog hadn't been updated since breezy, so I figured the magic happened in dapper
<infinity> (The changelog back then can attest to the pain, as people made 3 rapid-fire uploads in a row)
<keescook> yeah, I got scared when I saw fabio's README.  :)
<infinity> nvidia/debian.binary is sketchy at best, and may well not even work right now.  It's not something that gets looked at much.  Feel free to ignore it.
<keescook> I did.  :)
<Kamion> crimsun: I'd need to see the whole diff - but better ask somebody who's more awake
<Kamion> I'm off to bed now; night
* infinity reads nvidia's press release.
<crimsun> thanks
<infinity> keescook: Heh, they mention the exact versions we ship, much easier. :)
<infinity> "NVIDIA can confirm that this bug is only present in the NVIDIA UNIX Graphics drivers 1.0-8762 and 1.0-8774"
<infinity> Handy.
<keescook> infinity: hehe.  Yeah.
<infinity> keescook: When we do the update for LRM, we'll also need to update XRM, by the way.
<infinity> (It uses the same orig.tar.gz, though, which makes life easy... I made sure of that)
<keescook> infinity: xrm? you mean the nvidia-glx stuff?  isn't that all from the same source?
<infinity> keescook: XRM, xen-restricted-modules.
<infinity> keescook: New, as of edgy.
<keescook> ah! okay.
<Burgundavia> infinity: isn't copied source fun?
<doko_> Kamion: ok, feisty, it's not broken, these are diverted files
<Mez> whens the cut off for uploads?
<Nafallo> Mez: some days ago
<Mez> Nafallo, even for bugfix patches?
<Nafallo> Mez: well, all uploads need approval.
<Mez> Nafallo.... It'd be a big bugfix patch for katapult to make it's features work properly
<Nafallo> so depends on those nice RMs :-)
<infinity> Mez: If it doesn't fix a high impact or RC bug, we'll likely not approve it.
<infinity> Mez: If it's a universe upload, talk to ajmitch or dholbach, they are more lenient than I am about main.
* Nafallo should file a bug about Ubuntu Wave :-)
<infinity> Ahh, katapult is main.  I suspect you don't have a hope.
<Mez> infinity, it's for main
<Mez> bug 60136
<Ubugtu> Malone bug 60136 in katapult "Katapult doesn't work with Amarok >= 1.4.2" [Critical,In progress]  http://launchpad.net/bugs/60136
<Mez> bug 48103
<Ubugtu> Malone bug 48103 in katapult "Katapult don't start with swedish localisation" [High,Confirmed]  http://launchpad.net/bugs/48103
<Mez> and bug 49901
<Ubugtu> Malone bug 49901 in katapult "Katapult slows down to a near crawl when amarok is open" [Medium,Confirmed]  http://launchpad.net/bugs/49901
<infinity> Mez: Well, be quick, and make sure the patches are discrete (in case we want to approve one, but not another) and easily-audited, and "we'll see".
<Mez> "easily audited" ?
<infinity> Mez: But no promises.  We release in under a week.
<Mez> yeah - i understand
<infinity> Mez: Easily audited, as in, if the patch is huge and messy, we're not going to understand it well enough to deem it safe.
<Mez> cool - np
<zul> heh how time fly
<infinity> Mez: If the bugs are bad enough, in your opinion, but the changes a bit scary, best to hold off to after release, and try to go the proposed/updates route.
<infinity> Oh dear god, the new wallpaper is BRIGHT.
<infinity> I no longer have any text:background contrast on my desktop.
<infinity> Woo.
<Nafallo> infinity: you want the reverted Ubuntu Wave instead? ;-)
<infinity> Nafallo: Anything darker, really.  I can't actually read anything on my desktop now.  Seems less than ideal.
<Nafallo> I haven't seen the new wallpaper.
* Nafallo goes to look
<infinity> It's very... Caucasian.
<infinity> And while I appreciate skin as much as the next person, it's not an ideal desktop colour.
<Nafallo> looks dark
* infinity blinks.
<Nafallo> maybe I'm not up-to-date or something?
<Nafallo> I am. looks dark to me :-)
<infinity> http://cerberus.0c3.net/~adconrad/Screenshot-3.png
<infinity> Very not dark.
<Nafallo> aha! Simple is default...
* Nafallo thought Dark Chocolate was the default
* bhale notices infinity is an american tv leaching criminal
<infinity> bhale: It's either that or wait 2 years for stuff to run on .au TV.
<bhale> infinity: heh.
<Nafallo> hmm
<infinity> (Or, what happened in this case, Season 1 started running here, I thought it was pretty good, then noticed there were already 3 seasons in the US)
<Nafallo> I shouldn't say how many tv-series I have atm ;-)
<bhale> I doubt disney cares to litigate individuals in au
<bhale> anyway
<Nafallo> 188G  170G   18G  91% /srv/tv-series *whistles*
<infinity> The classic moment was when everyone here was raving about "that new show, Oz", and I had to break it to them that it had been cancelled in the US 6 years ago.
<bhale> hm not that long ago I think
<infinity> Oh, only 3 years, I gues.  Though we were watching season 1 here, which is from 1997.
<bhale> ended 2003
<keescook> that's how I feel about Doctor Who in the US.  :P
<infinity> keescook: yes, but Doctor Who sucks, so that's okay. :)
<keescook> infinity: ssssh! la la la I can't hear you
<Amaranth> infinity: router_password.txt with a nice little thumbnail of the file contents...
<infinity> Amaranth: Not my router.
<Amaranth> hehe
<Nafallo> lol
<Nafallo> that's one way to look at it ;-)
<infinity> Also, not a current password, it looks like.
<infinity> Screenshot-2 had a current password on it, though.  I never learn. :)
<infinity> (It got changed about 3 seconds after I posted it)
<Amaranth> hehe
<keescook> changed by you, I hope.  ;)
<infinity> Yeah, it was on a private network anyway, but I'm paranoid.
<Amaranth> that's alright, when i was working on PyMusique i once gave out a file with my iTunes password in it (hooked to a credit card)
<Nafallo> paranoia is a good thing :-)
<infinity> (Or, rather, only listening on a private interface)
<DMT> hey everyone - http://paste.ubuntu-nl.org/27621/ is a bug im experiencing
<Amaranth> DMT: Do what it says
<DMT> how do I file that information?
<Amaranth> DMT: launchpad.net
* Fujitsu blinks
<Fujitsu> That's quite a quick cleanup of ~adconrad you just performed then, infinity.
<infinity> I realised it was crufty. :)
<infinity> Hey, the important stuff is still there, namely a picture of me with a wombat.
<Fujitsu> Aw, what a cute wombat.
<infinity> And the best picture I've ever taken of a crocodile.
<Fujitsu> That's impressive, yes.
<infinity> Also noticed I name a lot of things "argh.${ext}"
<Mez> infinity, yeah - you need to apt-get install prozac to fix that ;)
* Nafallo cleans as well :-)
<Mez> Fujitsu, how do you know infinity was cleaning his drive anyways ?
<Fujitsu> Mez, I saw its contents rapidly disappearing as I refreshed the page.
<Mez> people.u.c/ ... ?
<Fujitsu> cerberus.0c2.net/, actually.
<infinity> (base)adconrad@cthulhu:~$ if [ "`apt-cache search prozac`" = "" ] ; then echo 'Argh!'; fi
<infinity> Argh!
<Nafallo> hehe
<Mez> infinity, do you have {un,mult}iverse enabled?
<infinity> I do.  I'm sad now.
<infinity> Is prozac only available in 3rd party repositories?  Is it proprietary?  HELP!
<infinity> Maybe easyubuntu can help restore my sanity!
<Fujitsu> No, Automatix!
<Fujitsu> You'd best check the forums.
<infinity> I just might have to.
<Fujitsu> As well as ask in all the development channels.
<Mez> Fujitsu, don't forget to ask in #debian-offtopic too
<Fujitsu> Mez, of course.
<Fujitsu> And throw in #launchpad, and launchpad-users.
<Mez> and debian-private@l.d.o
<argh> Hey guys.
<Fujitsu> Hahahah.
<argh> I know you're busy with the release and all..
<argh> But I need prozac.
<argh> kthx.
<Nafallo> hehe
<argh> WHY WILL NO ONE ANSWER ME, I WAITED 15 SECONDS!!
* Mez starts hacking a program called prozac
<Mez> or should that be prozak ?
<infinity> Only if it's for KDE.
<Fujitsu> gprozac and prozak
<Fujitsu> prozac is just the CLI version.
<Mez> Fujitsu, no - I'm serious - lol - I've been looking for a name for something I'm working on - I think prozak fits
<ajmitch> I feel like installing the beta nvidia drivers & beryl, just for some fun
<Fujitsu> Hahahah.
* Fujitsu attacks ajmitch with an axe.
* Fujitsu watches ajmitch's windows burn, literally.
<infinity> I feel like not being in my house in the middle of a Saturday.
<ajmitch> I tried that
<ajmitch> then it started raining & I came home
* Fujitsu has nowhere better to be.
<ajmitch> I got a few good photos of the steam trains down at the railway station though
<ajmitch> 'f-spot testing'
<Fujitsu> Hahah.
* Nafallo tries pittis requestsync :-)
<Fujitsu> I haven't been down to my local tourist steam railway in a while...
<Fujitsu> Hrm... tetex is gigantic.
<agent> currently, jigdo files are created for alternate and server iso's, could they also be used for desktop iso? this would help those out who create different iso images for different people (less downloading & saves ubuntu bandwidth)
<Fujitsu> agent, I have already rejected that bug.
<infinity> agent: No, the desktop ISO doesn't contain debs, so jigdo is useless.
<agent> i see, thank you
<agent> and you guys are fast :)
<Fujitsu> 10 minutes isn't that fast.
<agent> and amazing job with the bug reports... so many closed and so much updates ;)
<Fujitsu> Would have been faster if Ubugtu weren't so laggy.
<agent> uhh, to me it is :D
<infinity> Ubugtu clearly needs a proza{c,k} plugin.
<Fujitsu> Of course.
* infinity goes back to FTBFS hacking and laundry.
<Nafallo> infinity: good combination :-)
* starsky-hutchy reads infinity goes back to FTBFS hacking laundry.
<infinity> Less good than, say, going outside.  I need try that later. (post-laundry)
<Nafallo> it was raining last time I was outside
<Nafallo> and... WTF I'M I DOING AWAKE?
<Nafallo> Sat, 21 Oct 2006 04:26:00 +0200
<Mez> infinity, wouldnt proza{c,k} just make ubugtu slower?
<Nafallo> Mez: if he depends on it... ;-)
<Nafallo> gnight *. I need to be sleeping.
<infinity> tfheen: Ping when you're alive.
<BenC> tfheen: I'll second that ping
<fabbione> keescook: did you solve the problem?
<infinity> fabbione: Yeah, he got it sorted.
<fabbione> infinity: ok thanks
<tfheen> infinity: hello
<fabbione> hey tfheen 
<fabbione> you are up early
<tfheen> yes, so is the puppy
<tfheen> he slept the whole night in the cage, for the first time
<fabbione> ehehe
<infinity> tfheen: review/approval -> http://cerberus.0c3.net/~adconrad/libsdl1.2.debdiff
<fabbione> infinity: how is the rebuild going?
<fabbione> infinity: uuuuhhhg libsdl ships a copy of XXf86dga ?
<infinity> needs-build for amd64: Total 2086 package(s)
<infinity> needs-build for i386: Total 2007 package(s)
<infinity> needs-build for powerpc: Total 2102 package(s)
<fabbione> well that includes universe...
<infinity> Wish it did. :/
<tfheen> infinity: looks correct to me; those are the only places PAGE_SIZE is used?
<infinity> On the other hand, toolchain builds first, so a mess of GCC builds at the beginning kinda makes it look worse than it is.
<infinity> tfheen: Indeed.
<infinity> tfheen: Testing on i386 and powerpc.
<infinity> s/Testing/Tested/
<tfheen> infinity: go ahead.
<infinity> The new QT appears to make python-qt4 FTBFS too.
<infinity> Which is pretty awesome.
<infinity> Since it worked no more than a week ago.
<crimsun> tfheen: would http://tiber.tauware.de/~crimsun/lirc_0.8.0-5ubuntu1_to_0.8.0-9ubuntu1.diffstat  [http://tiber.tauware.de/~crimsun/lirc_0.8.0-9ubuntu1.debdiff ]  be more suitable for post-release?
<infinity> tfheen: This should make you happy, at least: http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt
<tfheen> crimsun: lirc = universe => motu uvf team.
<tfheen> infinity: HOOORAY
* tfheen bounces
<crimsun> tfheen: ...but it's main
<tfheen> crimsun: ah, lirc is universe, but the source is main for liblircclient0
<tfheen> crimsun: I haven't read the whole diff yet, but it doesn't look appropriate for edgy, no.
<crimsun> tfheen: ok, thanks.
<tfheen> crimsun: unless there's a critical bug in there which I haven't seen?
<crimsun> tfheen: it's a straightforward merge from Sid that fixes seven bugs, the most serious of which is that lirc-modules-source doesn't generate a valid binary package.
<tfheen> crimsun: lirc-modules-source is universe, so no, not for edgy.
<crimsun> bug 67258
<Ubugtu> Malone bug 67258 in lirc "Source package doesn't build" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67258
<crimsun> tfheen: right, thanks again
<tfheen> thanks for asking, though. :-)
<tfheen> infinity: how's the main queue looking?
<infinity> tfheen: queue's empty.
<tfheen> infinity: shiny.
* Hobbsee looks for someone to upload some crack, so it's no longer empty
<ajmitch> Hobbsee: fill up the queue for universe
<infinity> If it's crack, I'll reject it immediately, thus making the queue empty again. :P
<Hobbsee> haha
<Hobbsee> ajmitch: i did some uploads last night.  hush :P
* Hobbsee seems to have excessive trouble typing in her passphrase correctly
<infinity> I wonder how many packages we'd have left if we wrote checks into the upload queue to auto-reject source packages with poor use of whitespace, excessively pointless use of macros and magic numbers, and pretty much any other thing that annys me.
<ajmitch> probably 5
<infinity> We wouldn't have a toolchain anymore, sadly, but I guess we could work around that by being the first ever "truly source-only" distribution.
<tfheen> ogra: why isn't there a fix uploaded for LTSP yet?
<infinity> "It's source-only, even AFTER you install it.  That's right.  Learn to parse C so fast that your brain becomes a JIT compiler, you'll need it!"
<infinity> Maybe we could hire a groupd of overachieving asian kids to be our buildds.
<ajmitch> I hate broken packages, and even worse, 'bugreports' that are only on the forums
<infinity> I love how people think that randomly whining about things on forums, mailing lists, and the worst, blogs, will somehow magically get it to the people who can fix it.
<ajmitch> every so often I feel masochistic & dive into the forums
<infinity> OMG, UBUNTU DEVS ARE FASCISTS BECAUSE THEY DON'T READ MY BLOG AND FIX MY BUGS!
<ajmitch> generally to harass & berate the users for not filing bugs
<fabbione> ROFLT
<Treenaks> infinity: hey, I file bugs and nothing happens... so it's not that much different :P
<ajmitch> Treenaks: but at least they're on malone to be ignored - there's a world of difference
<Treenaks> ajmitch: true :)
<infinity> Treenaks: What's your LP ID?
<Treenaks> infinity: that sounds a lot like a BOFH question ;)
<Treenaks> (why?)
<fabbione> Treenaks: so he can wipe it from LP? :P
<infinity> Treenaks: I want to see if I've ever fixed one of your bugs. :)
<infinity> (And then delete your account)
<Treenaks> infinity: :P
<infinity> (Okay, not the last bit)
<Treenaks> infinity: it's 'martijn'
<infinity> 84 reported, only 24 open.  That's not so bad.
<ajmitch> of those 24, 3 are upstream bugtasks & 1 is debian, so it's only 20 really
<ajmitch> and you complain about people not fixing stuff :)
<freet15> Hi all
<freet15> I want to add some hotkeycode for my notebook, so I use "showkey --keycode" to get the keycode...
<freet15> but it doesn`t work.... I had change the /etc/init.d/hotkey-setup to match, and add the keycode in /usr/share/keycode-setup/.....hk
<keescook> hm.  apt-get build-dep qt4-x11   on dapper fails.  :(
<infinity> keescook: Install libgl1-mesa-dev by hand, then try.
<infinity> s/libgl/libglu/
<infinity> apt isn't always that bright.
<infinity> (sbuild gets it right)
<keescook> this hiccup is killing my sbuild config though... so I'm trying to figure out what's gone weird with it...
<infinity> Or, rather, OUR sbuild gets it right. :)
<keescook> hehe
<infinity> I should give you Canonical's internal sbuild, I guess.
<keescook> what's different on the buildd's?
<infinity> Debian's wants to use the first package in a "foo | bar" dep.
<keescook> that's what I was suspecting...
<infinity> Ours, for easing pain with syncing packages, will pick the first available instead.
<keescook> is there some reason they don't want to take that patch?
<infinity> It's incorrect behaviour for Debian, I've never tried to feed that patch back because it's wrong.
<keescook> oh heh
<infinity> In Debian, "Build-depends: foo | bar" means "you can use bar on your home system if you like, but the buildds MUST use foo"
<infinity> For us, we relaxed that, so that if we're not completely in sync with Debian, we don't have to patch every source package to cope.
* infinity tries to find the relevant change.
<tfheen> I guess that partly because of the universe/main split too?  So if a package synced from Debian has build-depends: foo | bar and then only bar is in main we still want it to build?
<infinity> tfheen: Right.
<keescook> infinity: thanks for the clarification.  let me know if you find the change, I'm going afk for a bit...
<jsmidt>  Hello, I maintain texmaker for debian.  Texmaker fails to build in edgy.  I have fixed Ubuntu's package.  How can I upload the changes?
<infinity> jsmidt: -> #ubuntu-motu
<jsmidt> infinity, thanks
<infinity> jsmidt: And thanks for fixing random bugs, we appreciate it. :)
<jsmidt> infinity, I do what I can. :)
<TMM> ghe.... OOo has been buiding for some 10 hours now 
<TMM> those localisations take, well, forever :)
<TMM> and a day
<infinity> You're building it locally?
<infinity> That was... Dumb. :)
<TMM> infinity: next time fakeroot dpkg-buildpackage binary ? :)
<infinity> Next time, don't build OOo?
<infinity> (Seriously, why are you?)
<infinity> Masochism?
<TMM> infinity: https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/65226
<Ubugtu> Malone bug 65226 in openoffice.org "Paste from writer to gaim in edgy segfaults writer" [Undecided,Confirmed]  
<TMM> infinity: I think I found the patch that causes that, and, there is only one way to be sure... :)
<infinity> Oi.  Fun.
<TMM> infinity: yes, next time I think I'm going to remove the 'clean' target in rules
<infinity> dpkg-buildpackage -nc to avoid cleaning.
<TMM> I've got to remember that
<TMM> really... this is taking forever :)
<TMM> actually, it looks like all the important .debs are build
<TMM> I'll just install them :)
<TMM> fuck
<TMM> err... I did not find the offending patch
<TMM> back to the drawing board
<Kaleo> good luck
<TMM> -nc ... :)
<TMM> I'll just let it finish building
<TMM> perhaps I should leave this to the professionals ;)
<TMM> there is a metric asston of code there
<TMM> doko_: hey! are you there?
<erdalronahi> pitti, thanks a lot for closing bug 49650
<Ubugtu> Malone bug 49650 in mozilla-firefox-locale-all "Newer Kurdish langpack available" [Low,Fix committed]  http://launchpad.net/bugs/49650
<pitti> erdalronahi: thanks to you for translating! infinity or Kamion need to approve it still
<erdalronahi> pitti, it would have the translated startpage like it had in Dapper, right?
<Nafallo> infinity: I agree with you. it's damn bright. especially the gdm-screen...
<erdalronahi> Epiphany also has it
<infinity> pitti: What do I need to approve?
<pitti> erdalronahi: depends, if ubuntu-docs has translations for it, then yes
<infinity>   112677 | S- | mozilla-firefox-loca | 2.0~rc3ubuntu1-1     | 13 minutes
<infinity>          | * mozilla-firefox-locale-all/2.0~rc3ubuntu1-1 Component: main Section: web
<pitti> infinity: mozilla-firefox-locale-all
<infinity> Is that just a new XPI?
<pitti> infinity: yes, the Kurdish one; mdz was fine with adding it for edgy
<infinity> Alright.  Approved.
<pitti> thanks
<pitti> infinity: if you are at it, do you see the language-support-* uploads?
<infinity> And all this language-support stuff?
<pitti> heh
<erdalronahi> file:///usr/share/ubuntu-artwork/home/locales/index-ku.html
<pitti> yes, I forgot to actually supply the 'upload' option
<erdalronahi> this seems to exist, it's epiphany's startpage
<erdalronahi> it is translated since Dapper
<infinity> pitti: accepted.
<pitti> erdalronahi: yup, just tested, works
<pitti> infinity: merci
<erdalronahi> great
<infinity> pitti: de rien.
<erdalronahi> merci beaucoup
<pitti> tres bien!
* pitti activates the very last French sententence he knows: 'jes voudrez deux bierre, sil-vouz plais'
<erdalronahi> :)
<pitti> (although seb128 would kill me for the spelling)
<Nafallo> lol
<Nafallo> pitti: good one ;-)
<erdalronahi> pitti, doko_, anything new from the ooo-l10n-front?
<pitti> erdalronahi: there will be a new upload, AFAIK
<erdalronahi> hope this fixes our issue with the fuzzies
<erdalronahi> actually, there shouldn't be any more, but who knows? 
<Chipzz> pitti: try "Je voudrais deux bi`eres, s'il vous plait"
<Chipzz> not sure if that's 100%, but closer ;)
<pitti> Chipzz: thanks
<pitti> Chipzz: it took me long enough to learn the pronounciation, but I never saw it written down so far
* Fujitsu pounces.
<Fujitsu> Pronunciation!
<Chipzz> pitti: it's been a long time since I've written French ;)
<Chipzz> but it's not really an easy language
<erdalronahi> indeed
<Chipzz> I've had to study it for 6 years in high-school, and have since gladly forgotten most of it :P
<infinity> pitti: Je voudrais deux bieres, s'il vous plait.
<Chipzz> infinity: that's what I said ;)
<Chipzz> infinity: plus the accent in bieres ;)
<infinity> Chipzz: Ahh, I didn't keep reading. :)
* Chipzz mumbles something about living in a bilingual (trilingual actual) country :P
* infinity decides it's time to go pretend it's the weekend and stop working for a while.
<erdalronahi> I am just updating with the latest libsdl1.2debian, it freezes my synaptic. What is it?
<Nafallo> infinity: ;-)
<Nafallo> erdalronahi: wfm
<erdalronahi> wfm?
<mvo> erdalronahi: can you expand the "Termianl" (or details) thing on the installl progress window?
<mvo> works-for-me :)
<mvo> erdalronahi: what is the last dstuff that is written there?
<erdalronahi> the last is
* Fujitsu starts frothing at the mouth upon seeing the new default background.
<erdalronahi> setting up libsdl1.2debian (1.2.10-3ubuntu2)...
<mvo> and it hangs there? hrm ...
<erdalronahi> sorry, it finished. Just for some reason 
<erdalronahi> didn't close the window :)
<mvo> ok
<Nafallo> Fujitsu: hehe
<TMM> OOo is a monster :)
<erdalronahi> TMM exactly
<TMM> too bad it is the only office suite that has good m$ .doc support :(
<TMM> without it, I wouldn't have been able to use a linux desktop at work :)
<TMM> 20 million layers of abstraction, ifdef for every bloody architecture ... aaaaaaah :)
<TMM> huge blocks too
<TMM> is there any place where older .deb's are still present? I'd like to get to the first upload of openoffice.org 2.0.4, then upgrade to each next version to see when it starts breaking
<TMM> I do believe this bug wasn't present in the initial upload
<Hobbsee> TMM: you've checked in /var/cache/apt/archives?  I've not found if/where LP actually keeps old debs
<TMM> Hobbsee: I just did a clean reinstall of edgy to test the installer, my /var/cache/apt/archives is sadly empty
<Hobbsee> TMM: ahhh
<Hobbsee> drat
<TMM> pretty much :)
<TMM> isn't that theoretically a gpl violation? if you still have an older version installed, there is apparently no way to get the originial sources
<StevenK> I have found where Launchpad keeps them, but they may not exist.
<StevenK> Hrm. Seems I'm wrong.
<TMM> ah, you can get to them through launchpad
<heno> Riddell: could you send me or point me at a PNG of the Kubuntu logo image used on usplash? I want to update the WinFOSS splash
<Riddell> heno: let me look it up
<heno> thx
<Riddell> heno: did you get the bug that sfllaw reported yesterday
<heno> Riddell: yes. Seems to be a problem with Server 2003 systems
<heno> Riddell: did he test Ubuntu on the same system?
<heno> (I'll ask in the bug)
<TMM> this doesn't really make it very easy :)
<Riddell> heno: usplash is at http://kubuntu.org/~jriddell/tmp/usplash_1024_768.png
<Riddell> heno: not sure if I have a copy of it transparent to hand, still searching
<Hobbsee> Riddell: isnt it just in k-d-s?
<Hobbsee> source?
<Riddell> Hobbsee: only PNGs in there, with black backgrounds and 256 colours
<heno> Thanks. A transparent one would be better
<Hobbsee> ah
<TMM> well, it DOES happen with the initial upload
<heno> I see sfllaw has written PASS on the Ubuntu WinFOSS tests, presumably with the same Server 2003 in VMware setup
<heno> Riddell: I've emailed kwwii
* heno reboots for some WinFOSS testing
<Riddell> heno: yeah, best thing, I don't seem to have a copy anywhere
<heno> ok
<heno> I might be able to extract what I need using the gimp too
<TMM> I'd bet good money that this crash is related to a fix in 2.0.3 where pasting inserts extra spaces
<pirast> the firefox ubuntu package search plugin still searches for dapper packages in edgy!!
<bhale> dapper is the latest release
<bhale> the default for packages.ubuntu.com search
<pirast> bhale, but /usr/share/firefox/searchplugins/debsearch.src says "dapper"
<bhale> thats a pretty silly bug to expect fixed this late
<pirast> see bug 61687..
<Ubugtu> Malone bug 61687 in firefox "in EDGY, searchplugin 'debsearch' searches for packages in dapper" [Undecided,Confirmed]  http://launchpad.net/bugs/61687
<pirast> its just a debdiff that has to be applied
<pirast> err patch
<pirast> its a one line patch
<TMM> doko_: ? :)
<jsgotangco> its something that can be done on -updates as well
<Nafallo> ehrm..
<Nafallo> xen-source-2.6.17_2.6.17-6 might actually be a smaller orig.tar.gz if .gif was removed...
<Nafallo> .git even
<amachu> hi this is sri ramadas, contact person for Ubuntu Tamil Team, wiki.ubuntu.com/ TamilTeam, we have some issues with Tamil in Edgy
<TMM> that's it, I give up :(
<TMM> does anyone know of a way to reverse just one patch in the OOo deb build environment without having to rebuild the whole thing?
<bhale> no thats not possible.
<TMM> ugh...
<TMM> really?
<bhale> really, i dont know how you think you can change the source code and not rebuild it
<TMM> no, not ALL of it :)
<TMM> I understand that it'll have to rebuild the affected files, and relink some stuff 
<bhale> this would be the case if you had an already-built source tree
<TMM> I have
<bhale> but packages do a clean
<bhale> before they configure, make, etc
<TMM> apparently, you can give dpkg-buildpackage -nc, so it won't make clean
<bhale> well see
<bhale> you already know this
<TMM> yes, but, the patch won't reverse, it claims it is not applied....
<TMM> which is a bit strange
<Treenaks> maybe there's another copy of the source somewhere?
<Treenaks> I mean.. OOo is on crack, why wouldn't the build system be?
<TMM> yeah, I was wondering if anyone knows that about the OOo buildsystem
<TMM> either the patches are all reverse patches, OR, I am really missing something :)
<TMM> ah... apparently not all patches are applied
<TMM> well, that rules out this patch as the source of the trouble then
<TMM> well, that's it then, an expert needs to look at this :) there is just too much code/patches 
<bddebian> Howdy
<doko_> TMM: ?
<TMM> doko_: hi!
<TMM> doko_: are you the OOo doko? :)
<rork> hello, somebody who can check this bug for a moment please https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63937
<Ubugtu> Malone bug 63937 in linux-source-2.6.17 "The SATA disk doesn't power off while shutdown" [Undecided,Unconfirmed]  
<tfheen> rork: it's not a bug; disk drives newer than about 1983 are fine with just having their power cut.
<doko_> TMM: rm debian/stamps/*; debian/rules build, use ccache and set DEB_BUILD_OPTIONS to ccache,nogsi
<TMM> doko_: will that also work when I have already got a build openoffice.org treE?
<rork> tfheen: it just doesn't sounds nice (and comfortable)
<rork> it makes a little tzzzzzzzzt sound
<tfheen> rork: *shrug*; it's still harmless.
<pirast> tfheen, but it should be fixed definitely
<rork> anyway, it's not "nice"
<rork> yep
<rork> you can't convince other users that way to use it
<pirast> rork, could you report it upsteam at bugzilla.kernel.org? and write the bug number down in the bug report?
<rork> pirast: I will do that
<pirast> but I do not really think that it will be fixed in edgy..
<rork> that will be definetly a bummer
<TMM> doko_: also, I wondered if you might have any clue as to what might cause that 'crash on rich-text-paste' I have confirmed that it does not happen in the 2.0.3 series, not in the 2.0.4 'stock' binaries from openoffice.org . but that it does happen in all uploads of 2.0.4 in ubuntu, and it also happens in current debian sid
<TMM> doko_: a hunch would be good :) I have been looking at a lot of code, but, there is lots more :D 
<doko_> TMM: sorry, no, not yet
<Gloubiboulga> tfheen, hello, do we need an approval for universe uploads?
<Amaranth> Gloubiboulga: I believe dholbach is responsible for approving those
<TMM> doko_: well, I'll just continue to poke around then, I am not too sure what happens yet, I am trying to follow the code path that leads to osl_getFileStatus
<Gloubiboulga> Amaranth, right, thanks
<tfheen> Gloubiboulga: yes, but not my approval.
<Gloubiboulga> tfheen, ok
<tfheen> pirast: oh, it definitively won't be fixed for edgy.
<tfheen> if it had been reported a month earlier; maybe.
<rork> pirast: hm, which category -> I/O?
<doko_> TMM: you may want to set BUILD_DBG_PACKAGE as well in debian/rules
<pirast> tfheen, isnt that what i said? ;-)
<tfheen> pirast: you don't happen to be a relase manager. :-P
<TMM> doko_: I assume that WOULD mean a complete rebuild?
<pirast> rork, i would suggest to file it again Drivers but I am not sure
<TMM> doko_: I currently have a build openoffice-2.0.4 directory, and, I really want to avoid having to rebuild the entire thing, because I am not yet all that sure what it is that I am doing, I might end up having to rebuild at least another 3 or 4 times
<tfheen> pirast: also, I was supporting, not contradicting your statement.
<pirast> tfheen, k :-)
<doko_> TMM: yes, use ccache as well for the build, exporting DEB_BUILD_OPTIONS=ccache,nogsi and CCACHE_DIR=~/.ccache
<TMM> doko_: ok, and that won't rebuild my entire tree? :)
<doko_> TMM: I don't know, didn't try ...
<TMM> doko_: debian/rules build
<TMM> make: Nothing to be done for `build'.
<doko_> TMM: as I said: rm debian/stamps/*
<TMM> doko_: I did
<doko_> TMM: oops: rm debian/stampdir/*
<TMM> ah :)
<TMM> doko_: this is a rather annoying bug... I've already lost some work to it... :(
<TMM> doko_: I am now trying to compare patches that went into 2.0.3 to the ones that went into 2.0.4, do you think that is a good strategy?
<doko_> TMM: no, too much
<TMM> doko_: ah... got a better suggestion? please? :)
<nix4me> what is the bug number you files TMM?
<pygi> sivang: ping? :)
<TMM> nix4me: 62432 I commented on one of the duplicates
<nix4me> ok
<doko_> TMM: reviewing the patches in ooo-build/patches/src680/apply
<TMM> doko_: ah yes, I did look at that file... I'll try and diff it against the one in 2.0.3?
<nix4me> that bug should be high importance
<TMM> I thought so
<nix4me> imho
<nix4me> i do that all the time, type schoolwork in oo and then paste into my online discussion board for my school
<nix4me> i guess i better be sure to save before pasting
<nix4me> i just tried it.  it crashed pasting into thunderbird
<rork> pirast: the bug 's filed Bug#: 7396
<pirast> rork, thanks for doing that :-)
<rork> no prob
<TMM> doko_: what parts actually get patched in? :) there are a lot of sections in that file
<doko_> TMM: look at the top and start with UbuntuEdgy
<TMM> doko_: strange... 2.0.3 doesn't have anything specific to edgy, is that correct?
<sivang> pygi: pong
<TMM> doko_: is there any changelog for what happened with the patches in a central place? and why?
<Nafallo> 57M     xen-source-2.6.17_2.6.17-6nafallo1.tar.gz
<Nafallo> 121M    xen-source-2.6.17_2.6.17-6.tar.gz
<Nafallo> hehe, I removed .git in my source :-P
<doko_> TMM: for ooo-build, see ooo-build/ChangeLog
<TMM> ah, great
<TMM> doko_: it apparenty went wrong somewhere in the debian patches, because it doesnt look like the ubuntu specific patches get applied to debian, but the debian ones do get applied to ubuntu, right?
<doko_> TMM: AFAIK there's a debian report as well
<TMM> doko_: yes, I linked to it in the ubuntu bug :)
<TMM> doko_: what is in the ubuntu-*lpi.diff? what does 'lpi' stand for?
<TMM> doko_: language pack... interface?
<Nafallo> launchpad integration
<TMM> Nafallo: that would work as well :)
<Robot101> the rt2x00 wireless driver in edgy's kernel is utterly horrific
<Nafallo> Robot101: that's correct :-)
<Nafallo> Robot101: for rt61 atleast I compile latest legacy cvs daily with good measures :-)
* Robot101 has an RT73 USB thingy
<Nafallo> hmm, I think they have legacy for that aswell now.
<Nafallo> so same should apply
<Robot101> that one's always gone into D state for me whenever I up/down/touch it
<Robot101> (and compiling drivers is problematic if you can never get on-line anyway)
* mconnor finds himself a little lost trying to find a current edgy ISO
<Nafallo> mconnor: cdimage.ubuntu.com
<mconnor> yeah, I'm there, just not sure where to look :)
<mconnor> clicking on edgy gets me the beta
<tfheen> mconnor: just download the RC from releases.ubuntu.com/edgy/
<tfheen> s/edgy/6.10/
<mconnor> that's the ticket
<mconnor> thanks!
<tfheen> (there is no newer image yet)
<Nafallo> daily-live/current would have done the same though :-)
<mconnor> I'll survive, I just haven't touched a Linux install since I lost two days of work time trying to get X to not kernel panic :)
<Nafallo> hi tfheen :-)
<tfheen> hiya Nafallo 
<mconnor> mmm, fast d/l
<erdalronahi> pitti, thanks again
<mconnor> is there an equivalent to rawhide in the Ubuntu world?
* Nafallo wonders what rawhide is :-P
<mconnor> lol
<mconnor> rawhide is red hat's nightly channel, kinda like Firefox nightlies
<tfheen> mconnor: no.  We have the current development version which goes from very unstable to release in six months.
<mconnor> that's too simple :)
<jsgotangco> it works for now though
<tfheen> as we're on the very last leg of the cycle, it's more or less the release, but when feisty fawn opens in a bit (probably a couple of weeks), we'll have something unstable.
<Nafallo> tfheen: hehe :-)
* Nafallo couldn't agree more while looking at the specs ;-)
<Robot101> Nafallo: saying that of course, I just managed to make the RT73 driver work :D
<Nafallo> Robot101: hehe, kewl :-)
<mconnor> I've just spent the last six months balancing a security branch, an app release branch, and our unstable as heck trunk :)
<mconnor> so this is refreshing
<Robot101> you just need to manually set the channel and AP I think
<pitti> hi mconnor, nice to see you here
<TMM> doko_: well, building appears to be a bit faster, but still takes forever and a day :)
<Nafallo> Robot101: Bug #58117 more than that for me ;-)
<Ubugtu> Malone bug 58117 in linux-source-2.6.17 "rt61pci can't scan or associate" [High,Confirmed]  http://launchpad.net/bugs/58117
<mconnor> pitti: I was expecting torches and pitchforks :)
<pitti> mconnor: heh, why so?
<Nafallo> tfheen: btw, care to look at bug #67280 for edgy-final?
<Ubugtu> Malone bug 67280 in Ubuntu "[NEW]  wave-look_0.1-0ubuntu1" [Medium,Needs info]  http://launchpad.net/bugs/67280
<Robot101> Nafallo: I guess I should comment on that, but I have no idea where my lp password got to, hm
<mconnor> pitti: well, there's enough slashdot/digg/blog comments about what a jerk I am and how I hate freedom, or something
* pitti should read more blogs -- or maybe not
<Nafallo> Robot101: yea, but you could scan or?
<tfheen> mconnor: I'm sure we can arrange pitchforks if you really want us to..
<tfheen> Nafallo: I don't think NEW packages are accepted now, and it'll be universe anyway, so not anything I spend time on
<mconnor> tfheen: I'll pass, but thanks :)
<Robot101> Nafallo: you have to up it toscan
<Nafallo> tfheen: hmm, oki.
<Nafallo> Robot101: I know. still couldn't scan.
<Robot101> Nafallo: oh, hm. the drivers are clearly very shoddy, but once you poke the stuff in the right order I managed to make it go
<Robot101> now to chroot into my / and install the edgy kernel and maybe I can get my desktop online :)
<Nafallo> Robot101: I would still have liked us to revert to legacy for rt61 though :-/
<Robot101> Nafallo: yeah, possibly would've been safer :-/
<Nafallo> we'll see what happens to rt2x00 in feisty soon though ;-)
<mconnor> pitti: blogs are a timesink, I just got the choice bits forwarded to me :)
<lritter> heh
<Robot101> haha, you actually have to scan to make it associate
<Robot101> utterly bizzare drivers
<lritter> a giant load of packages just came in
<lritter> i smell release
<mconnor> hmm, you guys are all mostly in London, right?
<tfheen> mconnor: no
<Nafallo> Robot101: hehe, and I can't scan so... ;-)
<Nafallo> lol
<mconnor> hmm, someone said that
<mconnor> must get better sources, obviously
<tfheen> mconnor: some UK, a bunch of Germans, some Frenchmen, an Australian, a couple of people in .ca and .us, I'm in .no together with one other guy.  Some .za too
<mconnor> yikes
<tfheen> and a bunch of .br people.
<tfheen> (I've surely forgotten some countries)
<mconnor> so, uh, that's a lot of flying :)
<sivang> tfheen: who's the other one? :)
<tfheen> sivang: henrik
<mconnor> unless my back magically recovers to go to MV a week early
<tfheen> the distro team meets up four times a year.
<sivang> tfheen: ah, was sure his from the US.
<tfheen> sivang: no, he's from Bergen, but studied in Oxford and stayed for a bit, but recently moved to Oslo
<TMM> doko_: debugging OOo sucks, I hope you get paid ;)
<highvoltage> hi. according to cdimage.ubuntu.com it doesn't seem that there's any daily builds after 17 October?
<sivang> tfheen: good to know, thanks.
<_ion> 0xford
<tfheen> highvoltage: correct
<highvoltage> tfheen: ok, if I want to do testing, is it fine if I use the Oct 17 CD, or is there another one somewhere I should use?
<tfheen> highvoltage: test the RC.
<jsgotangco> RC is best
<tfheen> (it's on releases.ubuntu.com)
<highvoltage> aaah
<highvoltage> tfheen: thank you
<tfheen> I'll roll a new image on Monday, I think, but until then, RC is the freshest and what we want testing on
<jsgotangco> its pretty solid 
<tfheen> there are some nits, but we'll get most of them for release
* highvoltage rsyncs
<highvoltage> from the Edubuntu 17 October build there were a bunch of bugs. I'll do some testing tonight on the RC image. I think most of them is fixable for release too.
<highvoltage> hmmm.. I use the rsync command rsync rsync://releases.ubuntu.com/edubuntu/6.10/edubuntu-6.10-rc-install-i386.iso edgy-install-i386.iso edgy-install-i386.iso
<highvoltage> and I get the error: @ERROR: Unknown module 'edubuntu'
<highvoltage> rsync error: error starting client-server protocol (code 5) at main.c(1171)
<highvoltage> am I doing something wrong with the rsync command?
<highvoltage> (been a while since I used it)
<tfheen> highvoltage: you probably need to use rsync://releases.ubuntu.com/cdimage/edubuntu[...] 
<pirast> there's a problem with the turkish firefox locale... when you select turkish in the language selector it autoremoves firefox, yelp & co
<pirast> bug 67401
<Ubugtu> Malone bug 67401 in mozilla-firefox-locale-tr "[Edgy]  mozilla-firefox-locale-tr depends on Firefox <1.1 - causes breakage  " [Undecided,Confirmed]  http://launchpad.net/bugs/67401
<TMM> doko_: do you have any idea what https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/65226/comments/4 is talking about?
<Ubugtu> Malone bug 65226 in openoffice.org "Paste from writer to gaim in edgy segfaults writer" [Undecided,Confirmed]  
<TMM> well, now I need to do a full rebuild... if it turns out to NOT be this patch, I REALLY give up... fsck OOo (grrrrr)
<Treenaks> wait.. the C++ is so bugg that rebuilding it changes its crashiness?!
<Treenaks> bugged
<TMM> Treenaks: it's a patch against the buildsystem... it needs to relink pretty much everything now it seems, the build system didn't like that
<Treenaks> TMM: yes, but if a build system patch can fix a copy/paste issue, that's scary..
<TMM> anyone got a 4 way SMP system I could borrow/ :)
<bluefoxicy> interesting.  The stock /etc/readahead/boot misses 110 files I need and has 209 I don't need.
* bluefoxicy opts for profiling his own.
<highvoltage> bluefoxicy: how do you do that?
<bluefoxicy> highvoltage:  I had one I profiled on my own, dpkg asked to install the stock one so I cat boot* | sort | uniq -D | wc -l and divide the result by 2 to get the common file count
<bluefoxicy> subtract that from the size of my profile, and that's how many my profile has not in the common file count.
<bluefoxicy> count the lines in the stock list, subtract that from the overlapping files, that's the number of files that are in the stock count but not in my profile
<highvoltage> wow, that's real cool :)
<bluefoxicy> http://rafb.net/paste/results/MLydNu89.html
<bluefoxicy> uniq -D prints the non-unique lines multiple times (each time they occur); in this case this is only ever twice.
<mconnor> http://releases.ubuntu.com/6.10/ubuntu-6.10-rc-desktop-i386.iso is the droid I'm looking for, right?
<mconnor> do I need to boot, then install?
<tfheen> mconnor: boot it, yes, it's a live cd with an "install" icon on the desktop
<maswan> tfheen: don't try to push the release earlier by a couple of days, if you can avoid it, ok? ;)
<tfheen> maswan: we're still aiming for thursday. :-)
<maswan> tfheen: good, because ff 2.0 seems to be aimed for the first half of the week from what I hear. :)
<tfheen> maswan: there's a fc release soonish too, right?
<mconnor> Tuesday as well
<mconnor> basically, you can try to ship early, but you won't have mirrors ;)
<tfheen> next week will be a good week for free software, then
<maswan> tfheen: no clue, I don't mirror that
<tfheen> mconnor: we've shipped on schedule for the previous four releases, I don't intend to do otherwise for this.
<Ckenyon> Quick question:  What is the polished panel called that loads after you have entered your password to login
<desrt> the splash screen
<Nafallo> maswan: will you borrow some nodes from sarek this time again? :-)
<Ckenyon> Cheers
<desrt> Ckenyon; it lives in /usr/share/pixmaps/splash
<maswan> Nafallo: nah, debian has gotten enough donations our way, that we should be able to saturate our 2Gbit/s just "fine" without that
<Nafallo> maswan: nice :-)
<desrt> Ckenyon; but if you want to override it you should know that there is a gconf key /apps/gnome-session/options/splash_image that you can change instead of replacing the file
<mconnor> so, are there plans to make the liveCD start screen tell you to boot first, then install? :)
<Nafallo> mconnor: you don't have many other options as it is, have you?
<heno> sfllaw: ping
<mconnor> I can eject the CD and go looking for the right CD :)
<mconnor> Nafallo: since if I have a CD that I think is an install CD, and it says "this is the Ubuntu LiveCD" and doesn't mention installing anywhere, I'm not going to just boot the liveCD, since that's not the action I'm looking for
<mconnor> I might do it as a guess, but I'm more for making options clear
<Nafallo> mconnor: well, if you don't select anything it will but and you will see the nice big icon to install... ;-)
<Nafallo> s/but/boot/
<mconnor> right, but that takes a while, especially in Parallels, so I ended up stopping the VM a few times
<tfheen> mconnor: it should say "desktop cd", not live cd.
<mconnor> tfheen: I'll check again when the installer is done
<mconnor> speaking of which, should the installing dialog have a progress bar, or just a number?
<mconnor> (boy, its fun being a user and not having to answer these questions)
<tfheen> mconnor: it has a progress bar.
<tfheen> if not, please take a screenshot and file a bug
<mconnor> tfheen: it seems to be invisible, but now that I'm past 50% its obscuring the number :)
<tfheen> mconnor: uh.  Please file a bug. :-)
<mconnor> going to now :)
<tfheen> thanks.
<mconnor> assuming I find my way through launchpad
<tfheen> http://launchpad.net/distros/ubuntu/+filebug
<tfheen> file it against ubiquity
<mconnor> ok, thanks
* mconnor waits for parallels to stop sucking up resources
<azeem> I've seen a screenshot pasted in here by mdz with a similar or identical bug yesterday or so
<mconnor> hmm, fun
* mconnor tries search :)
<azeem> mconnor: http://people.ubuntu.com/~mdz/temp/progressbar_edgy.jpg
<tfheen> ew
<mconnor> that's the same bug
<mconnor> I see a couple of possible dupes in launchpad thus far
<mconnor> https://launchpad.net/distros/ubuntu/+source/human-theme/+bug/67185 and https://launchpad.net/distros/ubuntu/+source/human-theme/+bug/67443
<Ubugtu> Malone bug 67185 in human-theme "Progress bar progress invisible" [Undecided,Unconfirmed]  
<mconnor> looks like the latter is really a dupe of the former? is there a way to "confirm" bugs?
<kagou> hi
<pirast> hi
<mconnor> tfheen: http://steelgryphon.com/firefox2/liveCD.png
<tfheen> mconnor: you're on powerpc?
<tfheen> mconnor: if so, you won't get the same pretty menu that i386 and amd64 are.
<mconnor> tfheen: i386 (via parallels, my x86-64 is a little hosed ATM)
<pirast> tfheen, should milestone set to edgy at bug 61182?
<Ubugtu> Malone bug 61182 in firefox "Mozilla Firefox Bon Echo Beta 2 Doesn't show RSS Feed preview" [Unknown,Rejected]  http://launchpad.net/bugs/61182
* mconnor perks up at the bug description
<mconnor> maybe edgy just doesn't like parallels, I don't get any sort of splash screen
<siretart> tfheen: I don't know if you accepted fai-kernels, but thanks for that. I've just uploaded fai as well. I've been working and testing with upstream to get this working on edgy, and I'm quite confident with this. this was coordinated and in agreement with dholbach approvalwise
<tfheen> mconnor: sounds.. weird.  Unless parallells doesn't give you a framebuffer, that is.
<tfheen> pirast: hmm, hard choice, really.
<tfheen> pirast: I might be inclined to accept an updated package if somebody comes up with a patch RSN.
<pirast> tfheen, i do not know what is exactly wrong.. ill investigate a little bit this evening. i also subscribed martin pitt, maybe he has got a clue.. he does the firefox uploads
<tfheen> pirast: no, he doesn't, he just does security. :-)
<tfheen> pirast: Ian Jackson is our firefox man, but he's been on vacation this week.
<tfheen> I think it's a bug in the ubuntu theme, somewhere.
<pirast> tfheen :-(
<pirast> tfheen, ill try to compile the .orig.tar.gz content.. maybe that helps
<pirast> tfheen, if the cause of the problem being found, can an updated firefox also go to edgy-updates?
<pirast> same question applies for openoffice.org and the copy and paste bug..
<tfheen> pirast: yeah, I think that might be a saner approach.  It's an unfortunate regression, but I think we're too late in the cycle to fix it now.
<pirast> both are annoying bugs that shouldn't be in edgy
<tfheen> bugs are an unfortunate fact of life.
<pirast> tfheen, yeah.. sadly :-)
<pirast> i wish ubuntu would have less ones lying around on launchpad :-)
<tfheen> pirast: patches accepted. :-)
<pirast> tfheen, i do not really know but i imagine there are lots on older releases which are already fixed..
<sfllaw> henPong.
<sfllaw> heno: Pong.
<pirast> tfheen, doesn't seem to be caused by a theme.. i use the default firefox one..
<tfheen> pirast: you're aware that the default theme in Ubuntu is the "human" one?
<pirast> tfheen, yup.. but i do use the default firefox one.. i got the upstream tarball, closed by firefoxes and started the upstream one.. theme looks same and issue does not appear
<tfheen> pirast: hmm, so it might actually be an upstream issue then. :-/
<pirast> tfheen, upstream bug report was rejected because it does not appear with firefox tarball
<tfheen> pirast: but you're able to reproduce with their tarball?
<pirast> tfheen, no :-) as i sayd " and issue does not appear"
<pirast> *said
<tfheen> oh, sorry
<pirast> np :-)
<tfheen> I can't read. :-)
<pirast> hehe :-)
<tfheen> so then it's an issue somewhere in the code.
<pirast> tfheen, or it is caused by a compileoption
<pirast> afaik debian packages only modify things at the upstream tarball via debian/patches
<pirast> but firefox's diff contains lots of changes in the upstream code
<ivoks> well
<ivoks> doesn't debian exclude some stuff from source before applying patches?
<ivoks> like artwork
<pirast> ivoks, i dont really know.. im just a beginner :-)
<pirast> but should be, yeah
<ivoks> i think orig.tar.gz in debian source isn't the same as one from mozilla
<pirast> im away now.. compiliing & comparing source takes some time..
<pirast> ivoks was right, there is a difference between the ubuntu orig and the mozilla source.. but in ubuntu, there are only some branding and cvs specified things removed..
<pirast> tfheen, i give up.. compiled fine, now firefox segfaults
<tfheen> pirast: ew. :-(
<amep> Before I report this as a bug I want to ask if anyone knows anything: I am installing Edgy RC on a iBook G4 12". And once the live gnome environment appears it displays a bunch of errors from gnome-panel like 'The panel encountered a problem while loading "OAFIID:GNOME_ShowDesktopApplet".' and running bonobo-activation-run-query prints "A system exception ('IDL:/omg.org/CORBA/COMM_FAILURE:1.0') occured".
<amep> Anyone know anything about this?
<amep> BTW, I have successfully installed Edgy RC on a Compaq R3000z (AMD64).
<tfheen> amep: might be bad media; have you tested that first?
<amep> tfheen: I'll check that.
<mvo> tfheen: would you accept something like http://librarian.launchpad.net/4921525/compiz-fix.diff to fix bug 58424
<Ubugtu> Malone bug 58424 in update-manager "Can't calculate the upgrade with unofficial mesa/compiz packages " [Low,Confirmed]  http://launchpad.net/bugs/58424
<tfheen> mvo: oh, just 50 dupes.
<infinity> I'm inclined to say that if people install 3rd party packages and stuff breaks, they get to keep both pieces, but since the fix is pretty specific, and obviously otherwise harmless...
<mvo> tfheen: yeah :) everybody is using compiz it seems
<mvo> infinity: in general I agree, but the amount of duplicates is stuning. the good thing is that pretty much every upgrade problem is caused by this (and not by stupid stuff done by me :)
<infinity> As a general rule, you never find the "stupid stuff done by you" bugs until a day after release. :P
<infinity> Thankfully, with our release frequency, you don't have to live with the shame that long.
<tfheen> mvo: I think it looks good; where does the bits from the dist-upgrader actually end up?
<infinity> I've always hated having to live with my stupid mistakes in Debian/stable for ages.
<mvo> tfheen: it ends up in http://archive.ubuntu.com/ubuntu/dists/edgy/main/dist-upgrader-all/
<tfheen> mvo: does it go on the CDs?
<mvo> infinity: total agreement here
<mvo> tfheen: yes, it is imported there too (but only on alternate obviously)
<tfheen> mvo: you've tested this fix well, right?
<mvo> tfheen: I may come again tomorrow to fix a bug in python-apts pkgDepCache.GetCandidateVer() implementation, but that should be small and obvious
<infinity> tfheen: BTW, I intend to bang out 10 or so FTBFS fixes tomorrow.  Do you want me to pass each by you, or only the ones with reasonably large and non-obvious changes?
<tfheen> infinity: the latter is fine.
<infinity> Kay.
<mvo> tfheen: I did, but I will do so even more tonight/tomorrow. but for now it seems to fix the upgrade issue (I tested it with a full dapper+xgl.compiz.info repo). I want to double check against the other common compiz dapper archives too
<infinity> Oh, should I let the qt{3,4} security uploads through the queue?
<Mez> infinity: remember yesterday I was talking about those problems with katapult - how do you want the info regarding the patches submitted to you ?
* mvo leaves now to get some fun for the night
<infinity> Mez: If there are bugs, attach the patches to the bugs (one patch per fix, not a big monolithic patch), and point us (tfheen, ideally, me if he's not around) at the bugs, so we can judge each on its own merit.
<mvo> bye
<Mez> infinity, one already has the patch in it ...
<infinity> Mez: When that's been done, you can prepare a new package with whatever changes (if any) were actually approved.  If we don't approve any of 'em, you get to play with -propose/-updates after release.
<minghua> infinity: I saw you fixed FTBFS for scim-hangul recently.  what is your opinion on bug 67057?
<Ubugtu> Malone bug 67057 in scim "libscim-dev should depend on scim-gtk2-immodule" [High,Confirmed]  http://launchpad.net/bugs/67057
<Mez> infinity / tfheen - bug 48103
<Ubugtu> Malone bug 48103 in katapult "Katapult don't start with swedish localisation" [Medium,Confirmed]  http://launchpad.net/bugs/48103
<infinity> minghua: I had thought of doing that, yes.  It's probably the more correct option, since -dev ships the dangling symlink.
<infinity> minghua: And means I don't have to fix the other scim packages that I just noticed are also FTBFS. :/
<minghua> infinity: exactly, that's when I am mentioning it to you now :-)
<Mez> infinity - thats the forst one - I'm just finishing up the second
<tfheen> mvo: ok, thanks.
<infinity> Mez: Kay.  Lots of alcohol (don't let my reasonably coherent typing fool you) prevents me from auditing anything.  tfheen's the lead RM this time around anyway, so aim it at him. :)
<Mez> infinity, no probs :D
* Mez cuddles tfheen
<infinity> minghua: Yeah, I think I will probably do it that way (and revert my -hangul change while I'm at it)
<infinity> minghua: Just didn't like the idea of -dev pulling in the whole scim stack, but whatever.  We really should have split the library completely, not tossed it in the gtk-immodules package, but too late to fix that now.
<minghua> infinity: great.  I intended to ping Riddell after the weekend.  I'll ask him anyway if you fix libscim-dev that way
<infinity> (libscim and libscim-gtk would be better)
<minghua> infinity: I completely agree, and I plan to do that after etch
<infinity> Anyhow, we can revisit and fix this better in feisty (and maybe in a way that you like enough to adopt in Debian)
<minghua> infinity: yes, I would love to cooperate with ubuntu on this library split
<infinity> minghua: Can you make a note to contact me about it post-release (after feisty is open) and we'll talk?
<infinity> minghua: My brain is mush during the release crunch, so I don't expect to remember much of anything by the end of the week.
<minghua> infinity: sure (if you mean a local note for me)
<infinity> Yeah. :)
<infinity> Like, a post-it on your forehead or something. :)
<minghua> infinity: I think that's your brain's self-protection mechanism to prevent from being overloaded :-)
<infinity> My brain is, apparently, rather clever.
<infinity> But, yeah, I make no future promises or plans when I'm in release crunch mode and working 16+ hour days, becuase I know I'll forget everything I've said to everyone by Friday.
<infinity> And I'm sure that's a defense mechanism, since remembering this week could be painful.
<infinity> I have vague recollections of the breezy crunch still, which is what led me to cleverly erase allmemory of the dapper crunch.
<infinity> Hoary wasn't bad, but I was a new employee, naive, and still thought that working lots to impress my new employer was "fun". :)
<Seveas> you did a good job though, for all ofthe releases
<infinity> I'll take your word for it, since I don't remember. :P
<infinity> Oh, damn.  I was going to ask people to stop uploading, cause I hate upgrading every few hours, and then I realised half my updates were my own uploads.
<infinity> D'oh.
<Seveas> release stress in action ;)
<tfheen> infinity: go to bed. :-)
<infinity> tfheen: Working on it, just winding down.
<FireRabbit> are there plans to update the nvidia-glx package to the new 8776 version, which fixes a remote exploit vulerability?
<FireRabbit> before the edgy release
<Nafallo> FireRabbit: nope
<FireRabbit> why not?
<Fujitsu> FireRabbit, it is scheduled for soon after the release.
<FireRabbit> where are these things posted?
<Fujitsu> It was discussed about 24 hours ago in here.
#ubuntu-devel 2006-10-22
<FireRabbit> oh :)
<FireRabbit> i foudn it in the scrollback, thanks
<mconnor> ah, sonofa
<mconnor> ian's still out on vacation, I'll bet
* mconnor has a theory on Ubuntu's version of Firefox being busted
<mconnor> or, maybe not
* mconnor keeps digging
<jdong> installer folks: disregard my complaints about madwifi not working in alternate installer
<jdong> it does now
<jdong> :)
<jdong> as of RC
<mcquaid> ok i apologize before hand, I'm asking a support question as I can't find the answer anywhere, maybe a dev knows of a method for this I don't
* poningru waves at mconnor 
<mcquaid> I have edgy on a secondary drive which doesn't have the mbr on it, I'm moving this edgy drive to a new computer, so obvisouly I have to write the mbr to it, which I'll do via the live cd
<mcquaid> but menu.1st and fstab will be incorrect, do I have to manually hack them or is there a way to make it recreate them for this new computer
<mcquaid> I guess I'm trying to determine what creates fstab during the install, I'd hack it myself but I thought there must be a graceful way to move a drive from one computer to another
<mcquaid> and I'm not sure if the uuid's that edgy uses in fstab remain the same in a new computer.  not sure how uuid's are determined
<Fujitsu> mcquaid, the UUID is stored on the filesystem, that's the point :)
<mcquaid> ok, so it will remain the same then correct?
<Fujitsu> Yep.
<mcquaid> ok, so should I just hack fstab and menu.1st or is there a way to recreate them?
<jdong> mcquaid: fstab should need no editing
<mcquaid> i know I saw a guide on migrating a ubuntu installed drive to a new computer but can't find it anywhere
<mconnor> poningru: yo!
<jdong> mcquaid: you need to hack menu.lst to make sure the (hdX,Y) entries are right
<mcquaid> jdong, well fstab has entries for drives on this computer which aren't coming over
<jdong> mcquaid: well yeah you need to remove those
* mconnor twiddles thumbs, waits for ubuntu to finish installing for real
<jdong> mcquaid: AFAIK there's no easy/practical way of calling the installer's fstab/menu.lst installers
<jdong> if you know how to do it, you're better off doing it by hand
<mcquaid> ok shouldn't be too bad, final question, while i'm still in dapper (which is the first drive) is there a way to make it write the mbr to the second drive (edgy install) now? or should I only do that via a live cd
<jdong> mcquaid: it won't be correct....
<mcquaid> obviously not wanting it to write dapper's menu.1st but what will be in edgy's boot.1st once i edit it
<erdalronahi> doko, I've been working all day on the OOo-templates
<erdalronahi> I have a bad suspicion that there are some strings missing completely
<jdong> mcquaid: install grub from a livecd once the hard drive reaches its final location
<mcquaid> ok i'll go that route, thanks again and sorry for the questions here
<erdalronahi> remember the bug we discussed yesterday? It may not be about fuzzy strings, it may be about strings that are not there at all.
<mcquaid> btw, a script to recreate fstab/menu.1st would be nice in migrating a drive to a new computer.  win98 dies doing this but winxp actually handles this quite gracefully
<jdong> mcquaid: I agree about the script to recreate fstab/menu.lst
* Mez pokes jdong
<jdong> but the winxp thing, I've had quite opposite experiences...
<jdong> Mez: ouch!
<mcquaid> I've only done it once with xp for a friend and was surprised it went without a hitch
<jdong> mcquaid: I've had bad luck with migrating XP to new hardware
<jdong> mcquaid: activation aside, the process of redetecting all the hardware usually blows up in my face
<jdong> either that or it flat-out BSOD's on bootup due to major hardware differences
<mcquaid> ya I thought the same thing would happen, I was ready to reinstall for him, but it went through all the new hardware, a couple of reboots and it was fine
<mcquaid> I was really surprised actually
<jdong> moving is more reliably when you sysprep it first
<jdong> but sysprepping can screw up some programs
<jdong> especially kernel-mode stuff like Antiviruses
<jdong> anyway, this is completely OT
<jdong> Mez: did you need me for something?
<erdalronahi> ping doko
<jdong> urr, the alternate CD didn't install linux-restricted-modules
<jdong> the linux-generic metapackage wasn't installed
<pirast> night
<elodie_64> Kisss  tous, tout ceux qui on mIRC tapez : /server -m irc.roxshell.net pour une alternative a wanadoo
<elodie_64> Kisss  tous, tout ceux qui on mIRC tapez : /server -m irc.roxshell.net pour une alternative a wanadoo
<theCore> !ops
<Nafallo> bhale: got your privileged nick soon?
<scandium> hi, didn't get an answer on #ubuntu, so trying here, hope it's not considered OT ;) is there a reason why launchpad bug 57595 has been idle for weeks although it's about a package of "main" and a security issue (amongst other bugs)?
<Ubugtu> Malone bug 57595 in jfsutils "jfsutils 1.1.11 resolves buffer overflow, loops" [Undecided,Unconfirmed]  http://launchpad.net/bugs/57595
<pygi> somebody please kick this script thingy :)
<pygi> thanks :)
<pygi> !op
<theCore> scandium, that bug is still unconfirmed 
<pygi> !ops
<Nafallo> pygi: it's not doing anything atm :-)
<pygi> Nafallo: hm? :)
<theCore> scandium, can you confirm it?
<Seveas> pygi, !ops people are not op in here
<pygi> right :P
<Seveas> rob, elodie_64 is a spambot
<Mez> infinity, ping
<pygi> Seveas: thanks for letting me know ^_^
<scandium> theCore: I can't, but since the developers of jfs(utils) issued a new release because of it, that's proof enough for me in my position :)
<bhale> Nafallo: oh, you want me to kick the bot?
<theCore> scandium, got a link for the release?
<Mez> mdz: ping
<bhale> Nafallo: wasnt that annoying :)
<Nafallo> bhale: to late :-)
<mdz> Mez: ?
<Mez> mdz: unping
<Seveas> Mez, please don't ping each individual developer for this
<Mez> ;)
<mdz> good night
<Seveas> Mez, if you had paid attention: freenode staff was already on it
<Mez> Seveas: I wasn't ;)
<scandium> there's also a debian bug about it: 343638
<Mez> there are other reasons for me to ping people
<Seveas> debian bug 343638
<Ubugtu> Debian bug 343638 in jfsutils "New upstream version fixes stack overflow and more" [Important,Closed]  http://bugs.debian.org/343638
<Mez> debbug 343638
<Mez> lol
<theCore> scandium, I will see what I can do, but I doubt the developers will easily accept a UVF, at time
<scandium> I thought so. but I only  noticed this yesterday myself :(
<scandium> but thanks. was just curious if there is a deeper meaning of the bug being untouched as of yet :) bye all for now
<Nafallo> scandium: I subbed the security team for it :-)
<scandium> thanks :)
<Nafallo> hmm
<Nafallo> 15.85 rc-isos seeded from me ;-)
<Onoch> Where do I download Feisty Fawn?
<jdong> Onoch, it's not available yet.. edgy isn't even out the door
<jdong> Onoch, http://archive.ubuntu.com/ubuntu/dists/, distribution feisty doesn't exist to the public yet
<Onoch> jdong: Aha then which one is more recent?
<jdong> though I do recall someone saying they could upload to edgy+1...
<jdong> edgy is the most recent
<jdong> currently in RC status, slated to release next week
<Onoch> jdong: I see, thanks
<Onoch> Oh, next week?
<jdong> Onoch, in the future, ask this question in another channel... this channel isn't meant for any kind of support questions...
<jdong> yeah, the 26th is the release date
<Onoch> But what do you use now?
<Onoch> Sorry
<jdong> Onoch, Dapper Drake is the stable release
<jdong> (6.06)
<Onoch> jdong: Thanks
<jdong> Onoch, the CD images are http://releases.ubuntu.com/
<_ion> onoch: sleep 190d; wget -c http://releases.ubuntu.com/7.04/ubuntu-7.04-desktop-i386.iso
<jdong> _ion, LOL
<jdong> _ion, does sleep actually work reliably for a 190-day sleep?
<jdong> lol
<jdong> I don't know how many people have tested that use case...
<_ion> I have no idea. :-)
<jdong> _ion, do you know if grumpy groundhog is slated to open to the public within this century?
<_ion> I don't know anything about that.
<jdong> ok
<jdong> grr....
* jdong is starting to bald at age 18.... :D
<jdong> and I blame it on all the stupid people that know me
<_ion> When i start to bald, i'll probably just cut all the hair off.
<jdong> anyone have a good wise crack to make to a friend who's asking for help after he lost the pasword to his aes/dm-crypt root?
<jdong> I figure being a smartass is the best thing to do in this situation :D
<_ion> sleep -10d; sudo apt-get install keylogger
<_ion> Then simply look at the log
<Mez> is there not a meta-package for lamp install ?
<fdsd> hey guys, why is it not possible to mount a currupted drive but imaging a drive with dd will allow me to mount the image it creates?  any idea why that works?
<fdsd> anyone know?
<theCore> Mez, it's a task not a meta package
<theCore> Mez, sudo tasksel
<Hobbsee> mjg59: you around?
<jdub> hrm
<jdub> i'm getting "sysvinit in essential" problems during upgrade from dapper to edgy
<jdub> (i've done an upgrade, now doing an install of u-d and friends, doing quite a bit to satisfy depends, until the sysvinit issue)
<tfheen> morning, Sarah
<tfheen> and Jeff
<Hobbsee> hey tfheen 
<jdub> hey tfheen 
<jdub> sudo apt-get install --purge ubuntu-desktop ubuntu-standard ubuntu-minimal nautilus nautilus-cd-burner xorg hwdb-client-gnome xutils xutils-dev x11-common xserver-xorg upstart-compat-sysv
<jdub> a dist-upgrade would remove u-d and a bunch of other interesting stuff
<tfheen> jdub: use the dist-upgrader
<jdub> seriously?
<tfheen> you're probably running into https://launchpad.net/distros/ubuntu/+source/apt/+bug/63680
<Ubugtu> Malone bug 63680 in apt "dapper -> edgy dist-upgrade holds back essential packages" [Medium,Confirmed]  
<jdub> tfheen: half-upgraded to edgy, the dist-upgrader doesn't offer to dist-upgrade... 
<tfheen> jdub: run with -c
<infinity> Yeah, a bit late now.
<jdub> tfheen: already running with -c and -d
<jdub> also switching to dapper in sources.list doesn't work
<jdub> ;)
<infinity> jdub: Where's your upgrade stuck right now?
<jdub> infinity: between no upgrades and an ugly dist-upgrade
<jdub> and see further above for attempting to resolve installing u-d
* jdub tends to agree with fabio re: traditional upgrades :|
<jdub> should i just do the "Yes, do as I say!" schtick and get on with it?
<infinity> No, just upgrade sysvinit first.
<infinity> apt-get install sysvinit && apt-get dist-upgrade
<infinity> If you upgrade to the edgy version, it won't be essential anymore.
<jdub> yeah, good point
<jdub> oh, aside from the removals.
* jdub resolves.
* jdub adds build-essential, everybody happy...
<infinity> I guess I should do that fpc bootstrap today so people stop whining at me.
<imbrandon> infinity, hehe
<crimsun> hmm, I'm receiving an error when using dput: Error '(110, 'Connection timed out')'
<infinity> Could be the connection timing out.
<crimsun> checked from three different hosts, though
<crimsun> (on separate peering)
<infinity> Well, StevenK managed to upload something ~2 hours ago.
<infinity> Let me upload some random crap and then reject it.
<minghua> let's hope infinity doesn't press the wrong button when rejecting it :-)
<infinity> crimsun: Upload went fine.
<crimsun> hmph.
<infinity> crimsun: You're uploading to upload.ubuntu.com, right? :)
<crimsun> yessir
<infinity> (base)adconrad@cthulhu:~/foo$ host upload.ubuntu.com
<infinity> upload.ubuntu.com       A       82.211.81.167
<infinity> ?
<crimsun> yep
<infinity> Whacky.
<infinity> Passive versus active FTP confusion?
<crimsun> blah, went through fine now. Sorry for the noise.
<infinity> Someone must have unclogged the internet tubes.
<crimsun> heh :)
<infinity> http://www.youtube.com/watch?v=P83FGtPCuvc  <-- For those who didn't get the reference.
<erdalronahi> Hi doko
<ubitux> hi
<ubitux> do you know if scite is going to be patch ?
<crimsun> ubitux: for?
<crimsun> ubitux: also, it's better addressed in #ubuntu-motu, probably
<ubitux> crimsun, it's okay Gloubiboulga has make a patch ; it was concerning the tabs who don't work
<ubitux> ok
<giskard> hello
<pradeep> giskard, hello
<highvoltage> wow. I just looked at the ubuntu-devel mailing list for the first time in a while and it has certainly become very noisy.
<sivang> hi
<pygi> hi sivang 
<tkamppeter> doko, Kamion, I have made an exception request for getting the fix of bug 65618 into Edgy -> biff
<Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Medium,In progress]  http://launchpad.net/bugs/65618
<tfheen> tkamppeter: your last comment on that bugs says: "Closing this bug for all packages, as it is not a bug but simply a usability problem.".  Is it a UI problem or is it a bug in the package?
<ogra> tfheen, could you approve ltsp ?
<ogra> (need a debdiff ?)
<tfheen> ogra: yes, I could if I see a debdiff
<ogra> one sec
<ogra> tfheen, http://people.ubuntu.com/~ogra/ltsp.debdiff
<tfheen> ogra: looks good; approved.
<tkamppeter> tfheen, the HPLIP issue was not a bug, the foo2zjs thingy with the firmware was really a bug which is fixed by my new package. As I wrote this comment I did not realize that my fix was not uploaded yet.
<ogra> thanks :)
<tkamppeter> Therefore I returned to "in Progress" for foo2zjs.
<tfheen> tkamppeter: no, it is not clear at all that there is a bug in foo2zjs, what the bug is and what the fix is.
<infinity> ogra: Is that the one that's already in the queue?
<tkamppeter> tfheen, so I explain it from the very beginning:
<infinity> Ahh, yes, looks like it.
<infinity> ogra: Accepted.
<tfheen> tkamppeter: the usual way to read a bug report is that any information in a later message which contradicts earlier information overrides it.  Your "Closing this bug for all packages, as it is not a bug but simply a usability problem." means the RMs read this as "this is not an issue" and remove it from their radar.
<msikma> I have a question for the devs. I just upgraded to 6.10 and it seems that the LegacyHuman controls/widgets have been changed. They were broken a bit and just generally look uglier (I'm active in ubuntu artwork but haven't been noticing these changes).
<tkamppeter> The Hp LaserJet 1000, 1005, 1018, and 1020 are cheapo lasers, which need their firmware loaded whenever they are turned on.
<msikma> Here's a screenshot that shows what I mean: http://gamingw.net/pubaccess/28695/layoutchanges.png
<tkamppeter> tfheen, should I open a new bug to clarify?
<ogra> infinity, yes, and thanks :)
<msikma> E.g. the arrowed buttons no longer fit, the corners of the input boxes are missing and it just generally bothers me that an old theme of previous systems (which claims to be "as it was back then") was changed around by someone who didn't know what he was doing.
<tfheen> tkamppeter: no, you can add correct information to the bug report saying something like "The current state is: $state, $problem still remains, but $fix is the right way to fix this"
<tfheen> tkamppeter: or something to that effect
<msikma> So my question is: does anyone know about this or why it was altered?
<tkamppeter> tfheen, I will add a final comment
<tfheen> tkamppeter: thanks.
<msikma> I reported this: https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/67548
<Ubugtu> Malone bug 67548 in ubuntu-artwork "LegacyHuman controls/widgets visually broken" [Undecided,Unconfirmed]  
<msikma> ah okay
<tkamppeter> tfheen, I have added the commen to bug 65618 now. I hope this helps, as the report got really confusing due to the many other problems the original poster had.
<Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Medium,In progress]  http://launchpad.net/bugs/65618
<tfheen> tkamppeter: much better.
<tkamppeter> tfheen, I have tested this configuration with an LJ 1020 on Mandriva 2007 and the original poster of the bug has tested with an LJ 1020 on Ubuntu Edgy RC.
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<tkamppeter> tfheen, unfortunately, I could not test the LJ 1020 with Ubuntu Edgy, as HP France wanted to have it back.
<tkamppeter> So I had to work with the poster of the bug, but we solved the final problems via IRC and so we got all working on Friday.
<tfheen> ok.  I need to review the patch thoroughly and test it as much as I can before it can be accepted.
<tkamppeter> OK, tfheen, thanks in advance for putting this in.
<erdalronahi> doko, after hours of work I found a fix for the Rosetta problem
<erdalronahi> I already filed a new bugreport for it
<LazyBear> hi
<LazyBear> could anyone reccomend me an rsync program for ms windows? :p I need to get this edgy downloaded
<_ion> Well, rsync. But you don't need it to download edgy.
<PsyTec> LazyBear: getright
<PsyTec> and that is the developer channel by the way. no support questions please
<LazyBear> _ion, if I want to keep an image up to date, wouldn't rsync be the best?
<LazyBear> aokay
<siretart> woah. since when does launchpad send FTBFS notices?
<TMM> doko: hi! are you there?
<Nafallo> siretart: I dunno. My stuff builds ;-).
<TMM> 'if it builds, ship it. If it works, even better!!!'
<TMM> ;)
<Nafallo> TMM: haha
<TMM> Nafallo: :)
<siretart> Nafallo: well, ia32-libs-sdl FTBFS on i386, because.. because.. it is not in the Architectures list!
<Nafallo> :-)
<siretart> on purpose
<siretart> no, seriously, I'd like to get it added to P-a-s
<Nafallo> I was just about to say something along that line :-)
<Nafallo> or make soyuz not try to build stuff it shouldn't ;-)
<infinity> siretart: Mail me a reminder and I'll get it in P-a-s.
<infinity> (bed now)
<siretart> infinity: okay, will do. thanks
<TMM> anyone of the Openoffice munchers here? :)
<siretart> infinity: gn8
<Nafallo> TMM: don't know if doko is here ;-)
<TMM> Nafallo: 'the openoffice munchers' is just doko? :)
<Nafallo> TMM: AFAIK :-)
<TMM> poor bastard
<Nafallo> hehe
<siretart> Nafallo: guess what, it FTBFS on powerpc as well :P
<Nafallo> :-)
<Nafallo> so teach soyuz to not even try to build it, kthxbye :-)
<siretart> Nafallo: this is what's P-a-s is for
<Nafallo> siretart: so soyuz shouldn't be smart itself instead?
<siretart> Nafallo: perhaps there could be some better heuristics for automatically adding things to P-a-s. currently, it is a manually maintained list.
<TMM> I am really beginning to hate this OOo bug
<Nafallo> baah!
<TMM> probably just some small OOB somewhere... I mean, it crashes on creating a new string...
<Nafallo> I got a FTBFS notice :-P
<TMM> Nafallo: what's that?
<Nafallo> failed to build from source
<TMM> nasty
<TMM> and not on amd64... doesn't it make sense that it is an OOB then?
<TMM> input would be greatly appreciated :)
<Nafallo> infinity: why haven't erlang built on ia64? :-)
<Nafallo> infinity: uploaded 2006-09-21 01:03:40 CEST ;-)
<broonie> Is it just me that launchpad appears to have taken to e-mailing build failures to?
<Nafallo> broonie: nope
<broonie> I've just got a string of build failure notifications for packages I maintain in Debian being built on arches they don't support.
<broonie> Ah. I take it this is a bug?
<Nafallo> for Debian maintainers receiving them I would count it as that yes :-)
<infinity> Argh, it's definitely a bug that it's mailing Debian maintainers. :/
* infinity turns off the buildd-sequencer until he can get ahold of Team Soyuz.
<infinity> Tihs feature wasn't supposed to be rolled out yet.
<broonie> I do actually use my autogenerated launchpad account so I might have done something to request notification
<infinity> And certainly not in a broken state.
<Nafallo> crackful then...
<broonie> I can't see any way to access the logs except via the links in the e-mails.
<infinity> broonie: Oh, if you're active in LP, it may be making an exception.  Still, it's not meant to be doing it at all yet, AFAIk.
<infinity> broonie: launchpad.net/distros/ubuntu/+source/<package>/<version> should get you close to the logs.
<Nafallo> infinity: I'm glad I saw that erlang was still in needs-build though :-P
<infinity> Nafallo: It's in needs-build because I did a mass-give-back (which is why everyone's getting mail)
<infinity> Nafallo: It was "failed" a few hours ago.
<Nafallo> ah, oki :-)
<Nafallo> good then :-)
<broonie> infinity: Oh, so it does. It's doing crackful things like try to build lsadb (for Apple Desktop Bus) on all arches.
<infinity> broonie: Is it in P-a-s?
<broonie> I have no idea.
<infinity> broonie: If not (and I assume not), mail me about it, and I'll fix P-a-s in both Debian and Ubuntu.
<broonie> I only use launchpad to report bugs and track issues in my packages.
<infinity> (adconrad@{debian.org,ubuntu.com})
<infinity> Pick one, seeing as how I have to fix P-a-s for both.
<infinity> Err, wait.
<infinity> No, P-a-s is right.  This is a lingering bug from back when it was broken.
* infinity puts that on the list of Soyuz things to fix.
<infinity> (base)adconrad@cthulhu:~/build/dak/srcdep$ grep lsadb Packages-arch-specific 
<infinity> lsadb: powerpc                                                        # macintosh-only bus
<infinity> ^^ Looks right?
<broonie> TenDRA should be i386 only too.
<infinity> Actually, why isn't that powerpc m68k?  Weren't there m68k adb machines?
<broonie> Yes, that's about right. lsadb might support ppc64 too, I guess.
<broonie> Hrm. Yes, there were - Macs always used adb until they ditched it for USB.
<infinity> S'what I thought.
<broonie> If the kernel interfaces are compatible it ought to work on both...
<infinity> I only work with Amigas, Ataris, and Freescale's new ColdFire stuff, but I was pretty sure the mac68k had ADB busses.
<infinity> broonie: Okay, it's 4am and I'm far too tired to actually think rationally about it right now, but could I beg you to send me an email along the lines of "hey, want to try compiling lsadb on a quadra and see if it does anything useful?" for me? :)
<infinity> broonie: I can give it a whirl on one of the Debian buildds when I'm bored.
<broonie> Sure.
<infinity> "bored" probably being something that'll happen after edgy releases. :)
<broonie> No great rush given that it's been packaged for three years or something and nobody cared yet.
<broonie> Thanks.
<infinity> Yeah.  We don't have that many mac68k users, since they're pretty much the slowest 68k hardware known to man.
<broonie> That's pretty dammning, really.
<infinity> Well, the slowest that we fully support.  The Sun pizzaboxes and hppa slabs were slower.
<infinity> s/hppa/HP/
<infinity> brain melting.
<broonie> If it's 4am you probably ought to get some sleep :)
<infinity> It's a theory, yes. :)
<Nafallo> hehe. nightworker ;-)
<Seveas> bronson, infinity doesn't sleep during a release crunch
<infinity> Lies.
<infinity> I slept 3 hours yesterday.
<Seveas> score!
<infinity> And I intend to sleep for the next 4 or so.
* Nafallo laughs
* Seveas should poke freenode staff to k-line infinity so he can get some sleep
<infinity> My reputation is entirely unwarranted.
<Nafallo> infinity: how much will you sleep post-6.10? :-)
<fabbione> probably nothing
<fabbione> we will be all too busy getting drunk :)
<Nafallo> lol
<infinity> fabbione: Only if you're buying in SFO.
<Seveas> hmm, a week of sleep deprivation + alcool abuse == fun
<infinity> I did some incredibly complex math recently to discover that I've spent about twice what I made in the last 4 months, so I'm in no position to buy thousands of dollars in rounds for my coworkers this time.
<fabbione> infinity:  i will 
<fabbione> infinity: at least i will for you
<fabbione> infinity: go and get some sleep dude
* infinity nods.
<infinity> I'm in bed right now.  Just working on the whole passing out thing.
<mconnor> I guess there's no way to force launchpad to sync the upstream status without waiting a day?
<fabbione> infinity: one good step is to close the lid of your laptop
<Seveas> mconnor, you could bribe launchpad admins in #launchpad
<mconnor> Seveas: I'm lazy though :)
<Seveas> mconnor, then there's no way
<mconnor> hmm, fair enough
<mconnor> people can click the link, its not really critical, I already attached the upstream fix
* mconnor twiddles thumbs waiting for iwj or pitti to grab the fix
<TMM> it just bloody well crashes on creating a new OUString ... why
<TMM> on ia32 only
<Riddell> is python 2.5 default in edgy?
<Nafallo> shouldn't be
<Riddell> ah, python-all-dev brings in python2.5-dev as well as python2.4-dev is all
<doko> Riddell: correct
<TMM> hey doko
<TMM> doko: do any of my bug remarks and/or backtraces make any sense to you? 
<doko> sorry, no
<TMM> doko: meh :)
<TMM> doko: I found out that it just segfaults on creating a new OUSTRING for some reason... weird ass OOB somewhere, I haven't been able to track it down yet :(
<TMM> doko: I have now reverted leak-sal-file.diff as it doesn't seem to apply cleanly to the 2.0.4 code, and I didn't see the sense of it too much... but that is just a hunch I'm afraid :) there is just soooo much code :)
<TMM> doko: it does apply btw, just with some fuzz
<doko> I think I found a workaround, will have to test it
<TMM> doko: what did you find?
<mpt> ajmitch, ping
<TMM> doko: well, that wasn't it, I think I have to give up now
<Adri2000> who can ack uploads except dholbach ?
<Nafallo> ajmitch, slomo and siretart?
<Nafallo> I think
<Adri2000> ok, ping ajmitch slomo siretart :)
<ajmitch> mpt, Adri2000: pong
<mpt> ajmitch, are you taking NZ8 on November 4th?
<Adri2000> ajmitch: can you look at bug 54383 and the debdiff I attached ?
<Ubugtu> Malone bug 54383 in pppoeconf "[Edgy]  pppoeconf prints useless error message, doesn't do anything" [High,In progress]  http://launchpad.net/bugs/54383
<ajmitch> mpt: yes, I am
<ajmitch> mpt: I'm flying from christchurch->auckland first though
<mpt> See you in Auckland, then :-)
<mpt> But the reason I asked, is that we arrive in SFO on the 4th
<ajmitch> yes, I don't have the hotel sorted yet
<mpt> not the 5th
<mpt> Do you know that that's ok with the hotel?
<ajmitch> afaik it's expected
<mpt> What do you need to sort, then?
<ajmitch> since UDS itself starts on the 5th
<sivang> mpt: going to mountain view?
<mpt> sivang, yep
<ajmitch> I need to book the hotel :)
<mpt> oh!
<sivang> mpt: ah cool, doing LP work there?
<ajmitch> so I'm not sure if I'll be at the wild palms one or not
<mpt> because you're not a Canonical person
<mpt> silly me
<ajmitch> correct
<mpt> sivang, I hope so
<mpt> but only informally
* mpt should take a bag of chocolate fish
<ajmitch> mpt: are you leaving directly from auckland, not getting a connecting flight there?
<mpt> ajmitch, yeah, Nelson->Auckland
<samuel_> I'm from NZ too
<ajmitch> right
<mpt> samuel_, is it raining where you are too?
<KurtKraut> There is a bug in Edgy, confirmed and with High Priority that makes computers that depend on PPPoE to connect to the internet unable to connect.
<samuel_> yes it has been raining for two days straight
<samuel_> there goes my plans for beer and bbq's.
<sivang> mpt: I see nice
<KurtKraut> This bug was reported on Knot 2 and hasn't been fixed yet. If Edgy is released with this problem, a bunch of people won't be able to connect to the internet to ask for help or make updates
<Adri2000> KurtKraut: bug in pppoeconf ?
<KurtKraut> Adri2000, yes
<sivang> mpt: shame we won't be able to meet over a cup of hubackup ;-) could have helped some improvemnts over the Paris designed GUI.
<KurtKraut> This is a simple bug to be fixed. Envolves only changing 4 lines. How can I endorse the importance of this fix ?
<Adri2000> KurtKraut: eh :) I was asking ajmitch to look at it, ajmitch?
<mpt> sivang, you got declined for sponsorship?
<KurtKraut> The majority of internet connections in Brazil are broadband (60%). And the majority of theses connections are pppoe based.
<sivang> mpt: yep
<mpt> samuel_, what area?
<mpt> sivang, that sucks :-/
<samuel_> Palmerston North
<KurtKraut> This bug will lead ubuntu to an unacceptable situation in Brazil
<mpt> KurtKraut, have you or someone else attached a patch?
<fabbione> KurtKraut: what is the bug number at least?
<Adri2000> mpt: I have attached a debdiff
<fabbione> whining with no reference is pointless
<sivang> mpt: oh well, this is how the world revolves, there's a sentence in arabic for this "One day can be honey, but another can be onion" :-)
<KurtKraut> fabbione,  I'm loading LP at the moment. Just a sec.
<ajmitch> Adri2000: I can look, but the package is in main
<Adri2000> bug 54383
<mpt> yum
<Ubugtu> Malone bug 54383 in pppoeconf "[Edgy]  pppoeconf prints useless error message, doesn't do anything" [High,In progress]  http://launchpad.net/bugs/54383
<ajmitch> Adri2000: I can only approve uploads for universe
<Adri2000> ah :-(
<Adri2000> who can for main ?
<sivang> mpt: how do you like the way the UI is molding ?
<KurtKraut> that's it... bug 54383
<KurtKraut> fabbione, https://launchpad.net/distros/ubuntu/+source/pppoeconf/+bug/54383
<Nafallo> Adri2000: Kamion, mdz, tfheen AFAIK
<KurtKraut> This bug can be fixed by adding a # to 3 lines. Extremely simple.
<mpt> sivang, is the screenshot on the wiki up to date?
<KurtKraut> Adri2000, I've just seen this bug is assigned to you. Any chance this bug to be fixed in Edgy before the official release ?
* sivang is trying to decide if to use ConfigParse instead of my hand crafted module
<sivang> mpt: yes, if you're looking at wiki.ubuntu.com/HUB
<sivang> mpt: HUB= HomeUserBackup
<mpt> Well, there are many small errors
<Adri2000> KurtKraut: I attached a debdiff (to make a fixed package), but I am not a core dev and I can't upload
<Adri2000> Kamion, mdz or tfheen have to check first and then a core dev will be able to upload
<sivang> mpt: but the general directio is rather good isn't it?
<mpt> it's ok :-)
<mpt> I don't think the thing that appears when you double-click a backup file should be an alert
<mpt> That's a bit impolite
<mpt> For conflicts, I suggest listing them all at once with radiobuttons, not one at a time with alerts
<Adri2000> KurtKraut: maybe you can install the .deb I attached and confirm that it fixes the bug
<sivang> mpt: let me look again
<sivang> mpt: the restore/update dialoge doesn't seem like an alret to me, what of it suggests it's an alert?
<mpt> gah, I just closed the window, one moment
<sivang> mpt: sorry
<mpt> not your fault :-)
<mpt> I'm talking about the window with the title "Backup File love-me.dar"
<sivang> mpt: yes, I cna't see why you think its an alret
<mpt> Well, it's shaped like an alert
<mpt> it has an icon like an alert
<KurtKraut> Adri2000, I'm downloading... just a sec
<mpt> it has a "Cancel" button
<mpt> it has primary and secondary text
<mpt> The only thing that's non-alert-like about it is that it has a title!
<sivang> mpt: now I follow yu
<sivang> mpt: so s/Cancel/Exit/ ?
<mpt> No, no, renaming things won't change it :-)
<helmut> Hi. How to correctly hit ubuntu people for sending me ftbfs reports for a package I don't maintain in ubuntu?
<mpt> I suggest merging the functions provided in the alert, into the window currently entitled "Restore"
<Nafallo> helmut: that was #launchpad s fault
<helmut> Nafallo: thanks!
<mpt> huh, Nafallo, what?
<mpt> How was it Launchpad's fault?
<Nafallo> mpt: soyuz has sent out FTBFS reports to Debian maintainers.
<fabbione> mpt: LP is not supposed to send these emails out yet
<Nafallo> mpt: for Ubuntu packages.
<mpt> Nafallo, and this is reported as a bug in Launchpad?
<Kamion> Adri2000: your patch is fine; please get a member of ubuntu-core-dev to upload ASAP
<Nafallo> mpt: dunno. I know infinity stopped something :-)
<Nafallo> I would assume he filed a bug aswell, but that's just my guessing :-)
<sivang> mpt: hmm, interesting.
<Adri2000> Kamion: ok, thanks for ack
<sivang> mpt: yes, I'm buying this :)
<Nafallo> ajmitch: you're a core-dev IIRC? ;-)
<sivang> mpt: you wouldn't happen to have time to note/mock this up using glade on the wiki page? :)
<mpt> Using glade? I don't have a spare week
<mpt> >:-P
<mpt> Each time I see a GTK app with a bad GUI I need to remind myself how difficult glade is
<Seveas> mpt, glade3 isn't better?
<KurtKraut> Adri2000, the fix works
<KurtKraut> Adri2000, now pppoeconf is running as expected
<Adri2000> KurtKraut: cool, you can add a comment to confirm, and it will be uploaded soon
<Gavrila> is grub stopping to recognize UUID at boot on edgy in topic here?
<sivang> mpt: hehe, yes, you should :) 
<sivang> mpt: sure thing, I can imagine how it would look combined, I might give it a try for the next release though :)
<sivang> mpt: the guy who did the glade designs is a very talented glader , I would have to ask him to provide those. I've long given up on trying to work out glade's crunch :)
#ubuntu-devel 2007-10-15
<RAOF> I've put a debdiff up for bug #152505 - I've subscribed u-m-s  u-m-s, and the patcbh is trivial, but it might be an idea to work out why th e pointer is NULL in my case.
<ubotu> Launchpad bug 152505 in gdm "gdmgreeter segfaults when XRandR is not available" [High,New]  https://launchpad.net/bugs/152505
<ccheney> anyone notice weird spacing issues in firefox on pages
<ccheney> sometimes words that should have spaces between them don't but when you highlight the word the space appears and the words more or less reflow
<minghua> calc: AFAIK that bug has existed forever.
* persia seeks an archive admin to sync the remaining few RC fixes from Debian into universe before the archive freezes.
<baked> hey, sorry to bother you w/ a simple question like this. I am having trouble with bug #106418, but it says its fixed.  I wanted to try the latest kernel, is there a way to install the latest kernel from dev through apt-get?
<baked> sorry
<baked> guess i should go to ubuntu+1 for gutsy stuff
<jdong> baked: do you mean installing a gutsy kernel in feisty?
<baked> well, i upgraded, but i was having the same problem w/ feisty
<persia> baked: #ubuntu+1 is a good place for gutsy quasi-support.  #ubuntu-bugs is a good place for bug discussion.  (not to interrupt the conversation currently underway)
<baked> i know the problem has to do with the uuid not coming back the same, although i have not gotten a change to just change grub to boot off the drives instead of the uuid location
<baked> im kind of lost since its marked fixed
<baked> but i know how that goes
<mpt> Datacenter's fallen over?
<mpt> I can't contact launchpad.net, canonical.com, or ubuntu.com
* ScottK neither.
<albertito> mpt: the three work here
<kylem> mpt, i just dropped off of internal irc...
<lifeless> dc seems awol
<lifeless> as mpt is saying :)
<mpt> I know what this means
<mpt> LUNCH TIME
<baked> well, can anyone anser the second half of my question as to install a dev kernel from apt?
<baked> answer*
<ScottK> baked: Are you running Gutsy?
<baked> yea, i know to ask in the other channel
<baked> but im not getting any help there, i just want to know if i can test something to see if the bug is fixed in something other then 2.6.22-14
<ScottK> The odds of your getting help go way down when you decline to answer questions asked by someone who might be trying to help you.
<baked> im sure there are daily builds or soemthing, i just can't figure out how / where thye are
<baked> i understand scott, and as i answers, 'yea
<baked> '
<baked> i am using gutsy
<baked> answered*
<baked> sorry for the confusing response
<ScottK> If the kernel has been built and released, you're running Gutsy, and your system is fully updated, you've got all there is.
<baked> no daily builds or anything?
<jdong> ScottK: are there any newer kernels that plan ot go into Gutsy at this point?
<jdong> I'm pretty sure we're set in stone in that dept, right?
<baked> wow, well a fixed bug is not fixed in that build :(
<ScottK> There is one being built right now.
<mjg59> No
<jdong> oh hah, maybe I should check teh queue before opening my mouth.
<baked> so there is no daily repo i can update from?
<ScottK> jdong: Tough to do with the datacenter sitting in a black hole.
<jdong> ScottK: indeed it is :D
<ScottK> baked: When you run Gutsy, that's what you are doing.
<mjg59> There's nothing relevant in gutsy
<baked> ok
<mjg59> baked: That specific bug was fixed. You have another bug with similar symptoms.
<baked> no, i have that exact bug
<baked> exact symptoms at least
<ScottK> baked: mjg59 generally knows what he's talking about.
<baked> its just hit or miss with booting right now
<mjg59> No, you have a different bug with similar symptoms
<mjg59> That bug was an issue with the amd driver
<baked> well, i have looked this up a lot.  there are a lot of bugs in the system that are all related to the bug i said
<baked> yea, i have nvidia mobo.  the bug was happening with fiesty as well
<mjg59> Yes. It's a different bug.
<baked> everything that people say in that bug report are exactly what i am expeierencing
<mjg59> 106418 was fixed. Yours hasn't been.
<baked> so is there a bug with the same issue on another driver?
<mjg59> I can't tell right now, launchpad is inaccessible
<mjg59> However, if it's not working for you with the current kernel in gutsy, then I'm afraid it's not going to be fixed before gutsy
<baked> well sheit
<baked> only thing left is to take out all these uuid's and boot off the parition itself
<baked> sweet!
<baked> is there a bug # with nvidia already?
<baked> do you need any info from me to submit a bug / find one that I'm not seeing?
<mjg59> If you can boot with explicit partition names but not with uuids, then it's *certainly* nothing to do with 106418
<Burgundavia> ah crap, bloody dc being awol
<mjg59> Anyway. I need to be in the lab in six hours.
* mjg59 heads to sleep
<ScottK> Data center is back for me.
<slangasek> persia: which fixes?
<ScottK> slangasek: They're all waiting to be accepted now.
<persia> slangasek: duplicity, esniper, paketto, papaya, polyxmass-doc, quark, secvpn, and sqlfairy.  They've been pushed to unapproved since my earlier query.
<sn0n> anyone else having problems with wine and sound??
<slangasek> only when I drink too much of it
<mjg59> slangasek: I've uploaded a gdm fix for 152505
<pitti> Good morning
* slangasek waves
<pitti> good morning slangasek
* Starting logfile irclogs/ubuntu-devel.log
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<bryce> hi guys
<bryce> is there still time for additions to gutsy?  I have a fix for 127101 that is well tested, root-caused, passed upstream, verified, etc. and good to go
<bryce> sorry I didn't get it in earlier; been at a customer site, but that gave plenty of extra time for testing
<pitti> bryce: hi; yes, see slangasek's mail: fixes should be in by today 1200 UTC
<bryce> cool
* StevenK is waiting for virtualbox-ose to test-build.
<bryce> I may have one or two others; I need to check that they've gotten adequate testing
<pitti> bryce: bug 151647 is milestoned for final; do you have an idea whether it'll get fixed?
<ubotu> Launchpad bug 151647 in displayconfig-gtk "Cannot configure projector connected to laptop with Intel i915 (driver "i810") using displayconfig-gtk" [High,Confirmed]  https://launchpad.net/bugs/151647
<bryce> huh, hadn't seen that one, didn't realize it got milestoned
<pitti> well, it might have been done inappropriately
<pitti> that's why I'm asking
<bryce> ah, the reporter set it as milestoned
<bryce> hmm, generally I don't like it when the reporter confirms their own bug and sets the priority and milestone for it
<bryce> I don't mind it if they also propose a patch of course ;-)
<pitti> bryce: so it's not a grave bug and it should be unmilestoned?
<pitti> (it sounds like it, but checking; I just spotted it on the list)
<bryce> pitti, right, it's not going to get fixed before 1200 utc
<pitti> and there are probably also worse things to do by then
<pitti> well, better things, worse bugs
<bryce> I'm pretty certain this is a dupe of two other bugs we already know about
<bryce> at this point, I have to restrict my focus not only to worse bugs, but to bugs that also have patches that have received sufficient testing that they're ready for upload
<pitti> bryce: I unmilestoned above bug FYI
<bryce> pitti: thanks
<mdke> dholbach: around?
<carlos> pitti: did I talk with you about the problem with kdevelop translations?
<dholbach> mdke: yes
<mdke> dholbach: good morning :)
<dholbach> hi mdke
<mdke> dholbach: I wanted to have a quick word about that ubuntu-docs upload
<mdke> dholbach: bug 144796, my debdiff was different to yours, I don't know why
<ubotu> Launchpad bug 144796 in ubuntu-docs ""Glossary of Windows terms" link doesn't work" [Medium,Confirmed]  https://launchpad.net/bugs/144796
<dholbach> mdke: if you say that it's OK to upload the version that I checked out on friday, that's fine with me
<mdke> i'm concerned about your debdiff, I don't think we should upload without figuring out what is up with that
<dholbach> mdke: I'll do the following again: get the archive version and the svn version and re-try
<mdke> dholbach: appreciate it. if you could compare the resulting debdiff with mine (attached to the bug) that would be great
<dholbach> it'll either be your or my debdiff again, I think
<pitti> carlos: not that I remember
<mdke> fingers crossed :)
<mdke> dholbach: the other thing was that it would be quite nice to do a gnome-user-docs upload; there are translation updates only, but quite important ones
<carlos> pitti: kdevelop translations are in main (kde-i18n-*), but the template is in universe (kdevelop) so the .mo files are not installed as in other universe packages neither is part of language packs
<carlos> pitti: I guess there are a couple of those in universe too
<carlos> with the same problem
<dholbach> hey lloydinho_!
<soren> lloydinho_: Hey! Long time!
<dholbach> how's it going?
<lloydinho_> hey dholbach!
<pitti> hi lloydinho_, how is it going?
<lloydinho_> things are good. I've graduated
<dholbach> rock on! :-)
<lloydinho_> so now I'm looking for work instead. :-)
<pitti> carlos: hm; I guess there is an existing special case for that in Rosetta already? I. e. not having the .po and .pot in the same package?
<carlos> pitti: yeah
<pitti> carlos: I don't think we can solve this with just component mangling; we can't promote everything to main
<carlos> pitti: I only see two options
<pitti> carlos: does Rosetta know which domains are affected by this/
<pitti> ?
<pitti> i. e. the one it imports from kde-i18n, but never get output?
<carlos> pitti: 1. add a 'blacklist' to kde-i18n-* packages where you don't remove the .mo files in that blacklist
<lloydinho_> oh, by the way. Soren: Congratulations, I hear you've got a job at Canonical now :-))
<soren> lloydinho_: \o/ Yeah, since late May.
<carlos> pitti: 2. Add a way to allow some universe packages translations and include them in main language packs
<soren> lloydinho_: It's rocking!
<carlos> pitti: we could get some information like that
<dholbach> mdke: working on it
<mdke> dholbach: thank you so much
<pitti> carlos: 2 is more appealing IMHO
<carlos> pitti: isn't that a problem that we include universe translations?
* tbf wonders if the update manager should start installing packages while still downloading from a slow link
<lloydinho_> soren:  Cool! I would have thought so, too! :-)
<carlos> pitti: 2. is not a big problem for us because we need it anyway for packages that motu agreed on deploy the translations manually
<carlos> pitti: well, there is a third option... implement the spec to add translation updates for Universe ....
<carlos> pitti: but I guess that's more something to discuss at UDS
<tbf> of course there are some traps, but could be a big timesafer when your link is slow in general - or as it happend to me suddenly drops from 180k to 50k
<pitti> carlos: right, let's
<carlos> pitti: as a workaround, I'm going to add the template manually, that will include the translations as part of next language pack update
<carlos> pitti: btw, which package should I use for bugs in language packs packages that are global to all languages?
<dholbach> mdke: uploading gnome-user-docs
<carlos> pitti: do you have any metapackage I could use for it?
<mdke> dholbach: thanks
<pitti> carlos: please use the langpack-o-matic product
<carlos> pitti: ok
<pitti> https://bugs.launchpad.net/langpack-o-matic
<dholbach> mdke: http://daniel.holba.ch/temp/docs.debdiff
<mdke> dholbach: is it me, or is that even worse than the first one?
<mdke> do you think these are permissions changing? how could our debdiffs be different if we are building the same package?
<dholbach> mdke: that's the same as I posted before
<dholbach> mdke: no I don't think it's permissions that change - do you build it on gutsy? with pbuilder?
<dholbach> mdke: did you compare against the archive version?
<mdke> dholbach: yes, no and yes
<mdke> it really worries me because those are important files, and nothing has changed (in the source) to make them move
<mdke> I think the cause must be in the symlink script somewhere though, because there are a lot of symlinks in there
<dholbach> it seems there's always an instance of each of those important files around
<mdke> yes, and symlinks to them in other places
<dholbach> it just appears in different places (.3 vs .4) and if it's a symlink or the file itself
<dholbach> mdke: it looks OK to me - I just can't tell you why it happens
<mdke> dholbach: can you put the binary up and I'll give it a quick test; I suspect it's fine, as you say
<dholbach> mdke: http://daniel.holba.ch/temp/
<mdke> thanks
<Burgundavia> well, I am off to bed
<mdke> morning sabdfl
<dholbach> hi sabdfl, asac
<mdke> dholbach: I suspect what is happening is the symlink script is finding the same file installed in more than one place, and is choosing the opposite location to install and symlink from the one it chose in the last version...
<mdke> nice motu pants btw
<dholbach> haha :)
<asac> hi dholbach  :)
<sabdfl> howdy mdke, dholbach, how is everyone today?
<dholbach> sabdfl: very good - how are you?
<mdke> not bad thanks, for a Monday
<dholbach> hehe :)
<mdke> dholbach: the package works fine as far as I can see
<dholbach> mdke: OK good
<dholbach> mdke: I'll upload it then
<mdke> dholbach: thanks, sorry for all the hassle you've had over that one
<mdke> pitti: please could you email me if you need anything further to approve gnome-user-docs and ubuntu-docs packages which Daniel is uploading now, I have to disappear from irc now
<pitti> mdke: will do
<dholbach> mdke: don't worry
<dholbach> have a nice day
<rulus> hmm, seems like fglrx breaks suspend.. bug 140766
<ubotu> Launchpad bug 140766 in linux-ubuntu-modules-2.6.22 "Suspend not working on Inspiron 6400 (gutsy)" [Undecided,New]  https://launchpad.net/bugs/140766
<bryce> would someone be able to do two uploads for me?  http://people.ubuntu.com/~bryce/Uploads/
<rulus> any chance fixing this for gutsy?
<mdke> dholbach: you too
<bryce> these fix two release critical bugs (127101 and 127008), and one other critical bug
<dholbach> bryce: can do
<bryce> dholbach: thanks
<dholbach> hey Hobbsee
<Hobbsee> hiya dholbach
<dholbach> bryce: uploaded
<bryce> dholbach: thanks
<pitti> ah, so if all else fails, I found a first workaround for bug 64408; trying harder to actually fix it properly, though
<ubotu> Launchpad 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
<ogra> slangasek, the g-p-m fix was for bug 150777 (there might be more that arent dulplicated ...)
<ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,Confirmed]  https://launchpad.net/bugs/150777
<ogra> pitti, ^^
<sladen> pitti: from a through the code, the int used for fgcolour/bgcolour of text is expected for be in the native form (so 8bit for a 8bit  display, 24bits for a truelcolour)
<sladen> pitti: so I suspect that the background "happens" to work as palette zero "happens" to be also 0x000000
<pitti> slangasek: I'm currently debugging it
<pitti> slangasek: I noticed that using gl_setpixelrgb() works, where as gl_setpixel() doesn't
<pitti> erm, sladen ^, sorry
<pitti> sladen: I think I just found a bug with passing the palette, digging further
<pitti> sladen: a-ha; the libsvga palette is never initialized in the first place
<pitti> slangasek: bpp is 16, and usplash_svga_set_palette() only calls gl_setpalettecolors() if bpp==8
<sladen> interestingly, the blt is doing the indirection correctly
<slangasek> ogra: I don't understand how this patch addresses the issue raised in that bug; the submitter's concern seems to be about having multiple controls that have to be changed to affect the behavior, not about what the default is?
<pitti> slangasek: ooh
<pitti> sladen, I mean
* pitti slaps himself
<pitti> sladen: it seems that usplash is *actually* using 16 bpp?
<ogra> slangasek, it fixes the locking by default for lid closing (which is a regression wrt feisty)
<pitti> sladen: in this case, calling gl_setpixel with a palette index is utter bogus in the first place?
<ogra> slangasek, the options the initial reporter changed have no effect oin that
<pitti> sladen: it should rather get the rgb value from the image's palette and call gl_setpixelrgb then
<ogra> slangasek, and the discussion that starts to the end of the bug is rather offtopic there (thats why i suggested a discussion)
<ogra> (on the ML)
<sladen> imbrandon: I suspect the orange is coming from  hex(0x1f << 11 | 0x38 << 5)  == 0xff00
<sladen> pitti: ^
<pitti> sladen: -theme-ubuntu wants palette index 117, which is actually that orangeish tone, so that might be
<slangasek> ogra: it's a behavior change from feisty, but I don't see that it's a regression; locking on lid close seems an obviously correct default to me :)
<slangasek> and again, it's not even the issue the submitter asked about
<ogra> slangasek, a) i wouldnt like to change it withoiut prior discussion b) it exposes another bug where g-p-m interprets ac plughging as lid action
<sladen> pitti: another question is /why/ a 16-bit mode is being chosen
<slangasek> ogra: but hasn't the current behavior now been the default for most of the gutsy cycle?  AFAICS, this upload /is/ changing it without prior discussion
<ogra> (and c) i dont want to have to login every 10 mins on conbferences where i open/clise my lid quite often :P)
<ogra> slangasek, no it hasnt
<sladen> pitti: one way to prove this is to use an image with pixels that are 1/256th different in value.  Then screenshot the result from virtual box on a 24-bit display
<ogra> upstreamm changed all gconf paths very late in the cycle
<pitti>                 mode = vga_setmode(svgalib_mode);
<pitti> [...] 
<sladen> pitti: if the two pixels have been rounded in value, then it's running on a the 16bit mode
<pitti>                         if (mode != svgalib_mode)
<pitti>                                 bpp = 16;
<pitti>                         else
<pitti>                                 bpp = 8;
<pitti>                         return mode;
<bryce> slangasek, pitti:  I don't know if you've had a chance to review my two uploads, but if so, note we have an update for 127008 (xresprobe_0.4.24ubuntu8)
<pitti> it's trying to set mode 11, and does set mode 21
<ogra> slangasek, there were none of our custom options applied for quite some time
<pitti> bryce: slangasek is doing reviews ATM, I don't want to disrupt his workflow unless he asks me to
<bryce> alrighty
<slangasek> pitti: feel free to take xresprobe so I can get to bed sooner :)
<ogra> slangasek, anyaway, either we go with screen locking on every brightness change and AC plugging (plus locking on lid close) or we get that patch in
<pitti> slangasek: taking then
<davmor2> bryce: bug 151311 with you on that one no point fixing one card to break others :)
<ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DPI in kubuntu incorrect on xorg-video-driver-intel" [High,In progress]  https://launchpad.net/bugs/151311
<slangasek> ogra: um, ok; where's /that/ bug then, that's clearly not bug #150777 and is also not mentioned in the changelog of the upload
<ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,Confirmed]  https://launchpad.net/bugs/150777
<pitti> bryce: ah, makes sense; accepting
<bryce> davmor2: yeah.  Also, that's the type of fix that's fine to roll out later if it's critical enough; the xresprobe fixes however kick in at install time so are more important to get on the CD.
<davmor2> bryce: will it be listed as a know bug though?  In which case we could still use your temp fix for people who have issues
<pitti> slangasek: taking ubuntu-meta, too
<slangasek> pitti: cheers
<bryce> davmor2: not sure - that's only going to be an issue for kubuntu (and xubuntu maybe?) as far as I know, so probably should be listed only on those release notes.  Would you mind checking into that?  Meanwhile this next week I'll look into a stronger fix.
<ogra> slangasek, i'll open one if you need it i discovered it during RC testing and didnt file it yet
<pitti> slangasek: and ubuntu-docs, if you don't mind
<ogra> (the stuff with the AC plugging/brightness changes i mean)
<mjg59> ogra: I don't see screen locking on brightness changes
<slangasek> ogra: it should be opened regardless so that the relevant folks can look at the root issue, yes
<ogra> mjg59, with the latest g-p-m ?
<slangasek> likewise, I don't get any screenlocking here on brightness changes
<ogra> mjg59, how about AC unpliggin
<ogra> *unplugging
<slangasek> I do get screenlocking when I close the lid, and I most definitely want that and am surprised that anyone wouldn't :)
<ogra> slangasek, well, we never had it on
<mjg59> ogra: Nope
<mjg59> All seems to work fine here
<ogra> i'm not opposed to switch, but want a say from the right folks
<slangasek> ogra: by a conscious modification of the upstream policy, you're saying, rather than just as a result of what upstream was doing?
<sladen> pitti: where were you getting the  mode 21 from, from the stderr output?
<pitti> sladen: yes, I added a few fprintf()s :)
<ogra> slangasek, we always had our own gconf defaults for g-p-m ... mainly for lock policy which was decided in edgy and surely could need some makeover
<davmor2> bryce: np I will be test most of the distros over the next couple of days so I will report to the bug exactly which distro's are effected.  If memory server though the login screens of all the desktops are effected until your patch is applied, and only ub/edu are fixed at this point.
<ogra> same goes for gnoime-screensaver
<slangasek> I see that 2.20 was uploaded mid-September, so it appears the current behavior was the behavior present in beta and RC, and no one else has complained; so either way, final will be a "regression" against one of RC or feisty
<bryce> davmor2: cool thanks
<ogra> slangasek, well, if neither mjg59 nor you see anything like i see i'm suspecting there is something wrong on my side (even i tested on two different laptops)
<sladen> pitti: so mode-selecting loop tries to find the first that is "big enough"  then the setting loop counts backwards and finds the biggest that actually succeeds.
<ogra> i'm not happy leaving lock on lid close on, but thats not as bad as having the lock in your face on state changes ....
<ogra> so reject please ...
<slangasek> ogra: are you sure? :)  It's not my place to be setting policy for this stuff either; if the pre-existing policy was to not lock on lid close, I'm willing to accept if you tell me that's the right thing here
<pitti> sladen: ok, I got a patch now \o/
<ogra> slangasek, well, its the right thing *imho* but the patch was mainly driven by the sideeffects it fixed in my view ...
<ogra> i usually care more for the experience of users that upgrade their stable release than about changes for testers so i try to keep the releases in sync ...
<pitti> sladen: I'll apply http://paste.ubuntu.com/928/ now to fix the usplash text color, unless you have an objection or another idea?
<bryce> pitti, there is also an uploaded xserver-xorg-video-intel_2.1.1-0ubuntu9 that I think is still pending review.  The bug report is huge, but the fix fairly modest; I'd love seeing it approved before I head to bed.
<pitti> sladen: I think this fix is correct anyway; it might be another bug that we don't use 8bpp, but that's independent then
<pitti> bryce: ok, I'll check it
<slangasek> ogra: sure, and that's persuasive to me.  I still think not locking on lid close is a wrong default, but I'm happy to argue that for hardy :)
<slangasek> so - accepted
* pitti agrees; hibernating a laptop should lock it
<ogra> slangasek, the discussion on ubuntu-devel-discuss has started ;)
<slangasek> hmm, maybe I should subscribe then
<ogra> i'm fine to use whatever gets decided (i know how to change my personal settings so for me it doesnt matter ... it does for my mother though)
<sladen> pitti: patch looks sane to cover for the moment
<ogra> imho passwords are the worst usabilty experience you can give a user so i like to avoid prompts for them where i can :)
<sladen> pitti: and the 16-bit individual setpixels explain why it's slow
<ogra> (while still keeping security at a moderate level indeed)
<pitti> sladen: right; that's harder and more intrusive to fix, though (not to mention that it needs a lot of testing, etc.)
<ogra> slangasek, thanks :)
<slangasek> ogra: I think having my data compromised because my laptop didn't lock properly is a worse user experience. ;)
<ogra> slangasek, ah, well, i'm fine to hit the lock screen button i have in my panel for that :) its one click more and i doint have to type my bassword on every relocation ...
<slangasek> right, give me a lock screen button by default then >:)
<ogra> but thats as subjective as it can be :)
<ogra> we had one for ages ... but when it moved to the logout dialog it was decided that we only need it once so the default panel item was dropped
<bryce> 'night
<pitti> bryce: looking ATM, but looks good so far
<bryce> cool, I'll check back in the morning.
<pitti> accepting
<pitti> bryce: please do test it properly, though, since this bears the potential for hw regression, etc.
<seb128> pitti: did you read the tracker bugfixes mail? Do you think there is anything there worthwhile for gutsy now?
<pitti> seb128: I saw it, but no time yet to read the patch; did you?
<pitti> seb128: if there are important and simple patches, we can still shove it in; but anything that's not 100% foolproof should be moved to SRU
<seb128> pitti: there is several fixes and quite some code lines changed, I don't think it makes sense to accept the whole, I'll look if there is some small fixes we would like to use now
<pitti> seb128: thanks
<pitti> seb128: if some patches fix initial db building, it's worth taking a look at least
<pitti> seb128: simple crashes etc. could be fixed in a SRU (stuff that doesn't corrupt the DB), if they are nontrivial
<pitti> likewise optimization stuff
<MacSlow> mvo, is there a bug-entry regarding the behaviour of the custom-effects-level radio-button and the properties-button for ccsm in the "Visual Effects"-tab in gnome-control-center?
<MacSlow> just asking for the changelog
<mvo> MacSlow: I don't think so, feel free to create one
<MacSlow> mvo, I assume that's the prefered procedure?
<mvo> MacSlow: yes, at this point at least
<mvo> MacSlow: not during normal development of course (when we are not in sub-zero -final preparations)
<MacSlow> mvo, feels a bit odd though... creating a bug-entry for something that's just getting fixed by yourself.
<Riddell> bryce: so that intel issue davmor2 has isn't being fixed?
<mjg59> sladen: pitti : The reason for preferring 16-bit is that some modern cards don't seem to support the clut registers in 8-bit vesa modes any more
<pitti> mjg59: ah, so that's actually deliberate; then it seems to me that all is well now?
<pitti> well, we might consider using a brighter color for urgent text, but the orange isn't too bad IMHO
<ogra> seb128, any idea about bug 152577 ? i have no clue why its doing that ...
<ubotu> Launchpad bug 152577 in gdm "call to gdmflexiserver in /etc/gdm/PreSession/Default causes gtk setuid warning" [Medium,Confirmed]  https://launchpad.net/bugs/152577
<ogra> its not accessing any suid program and isnt suid itself either
<mjg59> 16 bit is definitely deliberate, yes
<mjg59> As long as you're getting orange rather than blue now, it all sounds good
<pitti> mjg59: yep; I fixed usplash to take the actual color set in the theme, instead of a (pretty much) random one
<mjg59> pitti: Ha. Where was it doing that?
<pitti> mjg59: http://codebrowse.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/revision/167
<mjg59> Ah, I see
<StevenK> pitti: If you have a sec, NBS looks like some -12 packages are still hanging around, along with virtualbox-ose-modules-*-13-*
<seb128> ogra: that's nothing new and a duplicate
<seb128> ogra: gtk doesn't like to run as setuid, gdmflexiserver used to not call gtk_init but it doesn't now
<seb128> ogra: is that an issue for you out of the warnings?
<ogra> seb128, not at all
<ogra> i just saw several users complaining on the weekend and looked into
<ogra> it
<pitti> StevenK: will do
<seb128> why do they complain?
<ogra> because they see errors in their logs :)
<seb128> that's nothing new and should not be user visible
<seb128> bah
<ogra> well, its short before release, users look at such stuff :)
<seb128> they should better look at what doesn't work ;)
<ogra> what i doint get is that gdmflexiserver isnt setuid at all here
<ogra> so i dont understand why gtk complains
<seb128> ogra: gdm is running as root and the code is doing setuid() calls
<ogra> ah
<ogra> now it all falls into place :)
<soren> You're out of order, xresprobe! https://edge.launchpad.net/ubuntu/+source/xresprobe  :)
<pitti> StevenK: done, thanks for the ping
<StevenK> pitti: No problem.
<StevenK> pitti: I just remember you saying we shouldn't release with NBS stuff.
<pitti> right
<StevenK> ... so maybe that should be added to the Release page on the wiki ...
<StevenK> If I could remember its title.
<pitti> https://wiki.ubuntu.com/ReleaseChecklist ?
<StevenK> Hrm. There was one I was reading last night.
<Hobbsee> StevenK: was that ReleaseCandidateChecklist?
<pitti> StevenK: maybe https://wiki.ubuntu.com/ReleaseCandidateProcess or https://wiki.ubuntu.com/ReleaseProcess ?
<StevenK> I think the last one.
<Hobbsee> StevenK: it could be the non-sanitized canonical versions, too, perhaps?
<StevenK> Yeah, ReleaseProcess is it
<pitti> Hobbsee: they are gone (entirely moved)
<Hobbsee> oh nice!
<ogra> "non-sanitized canonical"
<Hobbsee> i thought they were just copied
<ogra> hey, we're not *that* insane
<StevenK> pitti: Hrm. I don't feel entirely comfortable editing ReleaseProcess, do you think a note in Release minus 1 day would be okay?
<Hobbsee> ogra: you sure? there was talk of it needing to be sanitized before it could be made public.
<pitti> StevenK: oh, please do add it there (to release - 3 days or so
<StevenK> pitti: Done.
<StevenK> Well, done when wiki.u.c comes back to me. :-)
<Keybuk> hah, what a surprise ... "we tested your line, and can't find any problem" ... and it's magically working again
<Keybuk> (well, ish; 12s lag)
<StevenK> Keybuk: Sounds like Telstra.
<StevenK> Keybuk: You're sure you haven't moved over here? :-P
<TheMuso> Is the archive frozen yet, including for universe?
<mjg59> We've been frozen for some time
<mjg59> Uploads may still get in at the release team's discretion
<TheMuso> right. nvm then
<RicardoPerez> seb128: hi! i'm the user with the "Loading" bug
<RicardoPerez> seb128: and yes, i'm using the Human theme, which it's the default one in Gutsy, don't it?
<seb128> RicardoPerez: right
<seb128> RicardoPerez: I've no idea what's creating the issue for you then
<RicardoPerez> seb128: there's a difference between my configuration and the one for a new user, but I don't know what is...
<RicardoPerez> seb128: is there any other dot file that I can remove aside from the .gtkrc*?
<seb128> RicardoPerez: you can try moving things around until finding what creates the issue, could be a local font or configuration also
<Keybuk> wow, that solves that bug
<seb128> Keybuk: ?
<Keybuk> for ages, I've been shutting the lid of my laptop, unplugging it, bringing it downstairs, and then plugging it in again and opening it up to find that it has suspended
<Keybuk> which baffled me because my on ac power setting was to just blank screen
<Keybuk> of course, it went to battery while the lid is shut ... but g-p-m isn't checking for the lid shut event, it's checking for the "lid is shut and on battery" state
<Keybuk> so suspends while I'm walking down the stairs
<ogra> sigh ... todays upgrade takes ages ...
<ogra> hmm, might be because oo.o comes down the drain ...
<StevenK> ogra: oo.o clogs it? :-P
<ogra> yeah :)
<RicardoPerez> seb128: it's a .gconf problem
<Hobbsee> ogra: news at 11.
<RicardoPerez> seb128: I move my .gconf dir away, and now the problem is gone
<seb128> RicardoPerez: fonts and themes are configured there
<seb128> RicardoPerez: you should move it back because there is evolution account settings, etc there
<RicardoPerez> seb128: yes... now I'm using 10 pt. fonts, instead of my preferred 11 pt. fonts
<seb128> RicardoPerez: I doubt the font size is creating that issue
<RicardoPerez> seb128: mmmm... maybe I try to deep into the .gconf dir?
<seb128> RicardoPerez: yes
<RicardoPerez> seb128: ok, i'll try :) thanks :)
<seb128> RicardoPerez: you're welcome
<StevenK> pitti, slangasek: Will you hate me if I upload virtualbox-ose-modules in a few minutes?
<Hobbsee> StevenK: no
<Hobbsee> StevenK: mine's still later
<pitti> StevenK: no, fine for me; I'm mostly concerned about packages going on the CDs
<Hobbsee> pitti: i warn you now, i have one of them
<StevenK> pitti: Okay, I'll ping you when I've thrown it up (!), if you don't mind.
<pitti> please
<StevenK> Just testing the thing.
<RicardoPerez> seb128: the problem was in the .gconf/desktop/gnome/font_rendering subdir
<RicardoPerez> seb128: I removed it and now the problem is gone
<seb128> RicardoPerez: ah ok
<seb128> RicardoPerez: so it's due to the font configuration (antialiasing, etc)
<RicardoPerez> seb128: yes :)
<seb128> RicardoPerez: what option did you use?
<RicardoPerez> Subpixel - VRGB
<StevenK> pitti: Sigh. And another virtualbox-ose upload.
<RicardoPerez> seb128: maybe I must to tag the bugreport as "invalid"?
<StevenK> pitti: virtualbox-ose{,-modules} uploaded.
<pitti> checking
<pitti> StevenK: so the modules packages have a Provides: virtualbox-ose-modules?
<pitti> StevenK: but Recommends: sounds fine to me; after all, people might prefer building it from upstream for whatever reason?
<StevenK> pitti: Yes, they do. However, people are still filing bugs saying it needs to be Depends. :-(
<pitti> hm, *shrug*
<pitti> eww @ killall -q VBoxSVC; no pid file?
<pitti> oh, this is the application?
<StevenK> Yup
<pitti> StevenK: shouldn't this kill disappear altogether?
<pitti> StevenK: if you uninstall -modules from a chroot, this would kill your outside app, etc.
<ogra> especially it shouldnt use killall, no ?
<pitti> that too
<StevenK> Hrm.
<StevenK> Let's see. We don't really need to stop it since you're going to reboot anyway, and removing the module and killing Virtualbox on upgrades is BAD
<pitti> StevenK: I still think the depends: is a bit overenthusiastic; people who run an upstream kernel etc. can't install it, and aptitude/synaptic etc. install recommends by default, right?
<pitti> right
<StevenK> pitti: Reject -modules, I'll upload a new 5 with an empty stop
<pitti> done
<StevenK> pitti: I've been told Synaptic doesn't do Recommends by default
<pitti> mvo: ^ oh, I thought all packaging tools do now, except apt-get?
<Hobbsee> StevenK: synaptic behaves like apt, yes.
<Hobbsee> as does adept
<pitti> hmm
<Hobbsee> pitti: dunno where you got that info from - afaik, only aptitude does for all packages.
* ogra thought there was a commandline option for apt-get to enable the recommends install
<pitti> hm, I have operated under false assumptions in the last few releases then
<pitti> ogra: right, but the default matters
<ogra> pitti, well, the default nerver installed recommends in apt ...
<Hobbsee> ogra: --enable-recommends
<pitti> right
<mvo> pitti: sorry, the default behavior for apt (and synaptic/adept) is currently to only install recommends for secrion: metapcakges
<pitti> but I thought synaptic/aptitude/etc. did
<mvo> metapackages even
<pitti> aah
<mvo> pitti: yes, for metapackages, but not for others. but this is changeing soon in debian
<StevenK> And virtualbox-ose is no metapackage
<StevenK> pitti: Changed -modules uploaded
<StevenK> Doh!
<pitti> StevenK: ok, then let's do that depends: thing
<StevenK> I left my WoW character on the boat long enough that I've done a round trip
<StevenK> pitti: Right.
<pitti> StevenK: much better, thnaks
<StevenK> pitti: Great
<pitti> our buildd farm is KDE'ed and OO.o'ed, so no new uploads please
* Hobbsee immediately uploads crack!
<ogra> pitti, eclipse is broken i heard :P
* Spads grumbles about Bug #152113
<ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [Undecided,New]  https://launchpad.net/bugs/152113
<pitti> Spads: smells like the first Gutsy SRU (as well as all other stables, of course) :)
<pitti> uh, that looks weird
<Spads> pitti: so everyone's clock is wrong until then?
<pitti> Spads: I'll try to do dapper/edgy/feisty ASAP
<Spads> pitti: thanks
<pitti> thanks for the reminder
<mvo> iwj: could you please have a look at bug #152813 ? it seems like dpkg is complaining about libpam-runtime not configured yet, however it seems to be configured a few lines above (in the log)
<ubotu> Launchpad bug 152813 in update-manager "Update from Feisty to Gusty fails in multiple packages" [Undecided,New]  https://launchpad.net/bugs/152813
* Hobbsee tries to remember
<Hobbsee> we're referring to our tribes, etc as alpha releases now?
<Hobbsee> i dont remember what mdz said
<liw> Hobbsee, that's what I was told, at least from gutsy+1 onward
<Hobbsee> ah yes, we do.  yay for keeping email.
<liw> a filter rule for automatic archiving + easy and fastish searching in Evolution made my life *so* much better a few years ago
<mdz> Hobbsee: yes
<Hobbsee> mdz: thanks
<pitti> Keybuk: can you please approve the dapper task in bug 152113? (yay LP inconsistencies)
<ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [High,In progress]  https://launchpad.net/bugs/152113
<pitti> doko: darn, OO.o/sparc FTBFSed
<Kopfgeldjaeger> hi
<pitti> doko: gcc ICE :(
<Keybuk> pitti: done
<pitti> Keybuk: thanks
<doko> pitti: I'll give it back, ok?
<pitti> doko: why should that help? it already built on artigas?
<doko> pitti: do you have a btter idea? give it back on sejong? I can build it on a t1000, but that won't help us here ...
<pitti> doko: I don't know how to fix it, but it has failed with an ICE on the buildds often enough to exclude the chance of a random glitch
<pitti> doko: binary uploads FTW :)
<doko> pitti: make it reproducible ... I'll ask for the b-d's on faure
<Hobbsee> !lts
<ubotu> LTS means Long Term Support. LTS versions of Ubuntu will be supported for 3 years on the desktop, and 5 years on the server.
<Hobbsee> long term.  right.
<bddebian> Heya
<soren> Hobbsee: hm?
<Hobbsee> soren: hm w.r.t. what?
<soren> "long term.  right."
<soren> My jedi senses detect sarcasm.
<Hobbsee> soren: i wasnt sure if it was long term, or l<something else, which i've now forgotten> term.
<Hobbsee> and thought i should get it right, for this.
<soren> Hobbsee: Oh, ok.
<soren> Hi, mathiaz!
<mathiaz> hi soren
<mathiaz> soren: did you get a chance to sponsor my dovecot upload ?
<soren> mathiaz: No, I'm afraid I didn't.
<mathiaz> soren: Is it too late to get it for release ?
<Hobbsee> mathiaz: archive isnt frozen yet, but will be RSN.
<soren> mathiaz: Easy answer: yes. Slightly more difficult answer (for you): If you sweet talk an rm to allow it, I'll be happy to upload.
<Hobbsee> chocolate accepted.
<Hobbsee> bribes accepted.
<persia> Hobbsee: How much?  I want to upload aolserver4.
<Hobbsee> persia: more than you can afford, if it contains the string "aol"
<soren> aolserver... Is that as evil as it sounds?
<persia> soren: Yes.
<soren> Thought so.
<zul> soren: worse
<Hobbsee> *much* more.
<zul> it eats newborns
<persia> Hobbsee: But it fixes a FTBFS, and allows removal of libssl0.9.7.
* persia offers 200g
<mathiaz> hum... It fixes some postinst issues - dovecot is not restarted when installing the imapd or pop3d package, but is configured properly.
<mathiaz> soren: everything is on http://people.ubuntu.com/~mathiaz/packages/
<Hobbsee> persia: oh ewww, it's already in here.
<persia> Hobbsee: Yep.  And the ldconfig trigger switch broke it :)
<Hobbsee> persia: do i want the diff?
<persia> Hobbsee: http://launchpadlibrarian.net/10008813/aolserver4_4.5.0-10ubuntu2.debdiff
<Chipzz> ogra: here?
<Hobbsee> persia: bonus points if you do the removal request
<persia> Removal of which?
<Hobbsee> aol*
<Hobbsee> persia: looks fine.
* persia thinks there might be a user or two...
<Hobbsee> hang on, hwo does that FTBFS?
<Hobbsee> that's a postinst?  how does that fail to build?
<soren> Hobbsee: You're confusing mathiaz and persia now..
<mathiaz> Hobbsee, pitti: any chance to get my dovecot upload/request accepted ?
<mathiaz> Hobbsee, pitti: soren had a look at it on friday and agreed to upload it if allowed.
<Hobbsee> soren: am i?
<pitti> mathiaz: see above; buildds are currently clogged, so it'll take a while; I'm happy to review it, though
* Hobbsee hasnt looked at mathiaz's stuff yet.
<mathiaz> pitti: it'S on http://people.ubuntu.com/~mathiaz/packages/
<pitti> mathiaz: please put a debdiff there, too
<persia> Hobbsee: It breaks the aolserver4-nsimap build: http://launchpadlibrarian.net/8094737/buildlog_ubuntu-gutsy-amd64.aolserver4-nsimap_3.2.3-1_FAILEDTOBUILD.txt.gz
<mathiaz> pitti: yes. That's what I'm preparing right now.
<soren> Hobbsee: Yes. Mathiaz is the one speaking about postinst.
<Hobbsee> persia: oh yes, i see.  ack'd.
<Hobbsee> soren: the debdiff for persia's mainly contains a postinst.
<Hobbsee> soren: that, and a changelog entry
<soren> Hobbsee: Oh.
<soren> Hobbsee: My bad.
<Hobbsee> soren: :)
<Hobbsee> soren: i didnt think i was going mad
<persia> Hobbsee: Thanks.  sent.
<StevenK> Hobbsee: But you are. So there.
* Hobbsee thwaps StevenK
<StevenK> Ouch!
* Hobbsee pokes StevenK repeatedly with the pointy end of the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<mathiaz> pitti: http://people.ubuntu.com/~mathiaz/packages/dovecot_1.0.5-1ubuntu2.debdiff
<pitti> mathiaz: looks good; if you tested all cases, please go ahead and get it uploaded
<mathiaz> soren: ^^
<mathiaz> pitti: thanks.
<StevenK> Oh, grumble.
<soren> done
* soren hugs mathiaz 
<soren> Thanks!
<StevenK> pitti: One more, with feeling. -modules didn't contain a #DEBHELPER# in the postinst.
* mathiaz hugs back soren
<pitti> persia: if you are touching aolserver4 anyway, any chance you could include a fix for http://launchpadlibrarian.net/7541603/buildlog_ubuntu-gutsy-amd64.aolserver4-nsimap_3.1-3build3_FAILEDTOBUILD.txt.gz ?
<persia> pitti: The upload for aolserver4 fixes that for me.  It just needs to build first, and then aolserver4-nsimap can build, and then libssl0.9.7 can be purged.
<pitti> persia: ah, great; cjwatson proposed to fix the prctl() call
<pitti> <cjwatson> arg2 to prctl is an unsigned long but prctl is varargs; perhaps:
<pitti> <cjwatson> -    if (prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) < 0) {
<pitti> <cjwatson> +    if (prctl(PR_SET_DUMPABLE, 1L, 0L, 0L, 0L) < 0) {
<persia> pitti: That is probably a better long-term solution.  For now, I just overrode the ldconfig trigger processing to let the libraries be loaded.
<persia> In Debian, they split the package into aolserver4-core (the libraries) and aolserver4 (the daemon), so it will be slightly more sane for hardy.
<pitti> persia: why 'long-term'? if that fixes it as well, it seems more adequate to me than hacking around the problem and hoping that it works? (I might have misunderstood the problem, of course)
<pitti> persia: ah, not instlaling the server as a build-dep in the first place? I agree, that's better
<persia> pitti: Two different issues.  One is that the daemon can't run because it can't find it's libraries.  The other that the daemon isn't written to be portable.
<persia> (unless we're looking at different FTBFS's)
<persia> Nevermind.  We might be looking at different issues.  I wonder why it worked the way it did for me (or is stderr just odd in the LP output?)
<pitti> persia: no, it's the very same you should see in the build log and on your screen
<pitti> persia: the one at my URL only happens on amd64
<pitti> due to sizeof(long int) != sizeof(int)
<persia> pitti: I'm using an AMD64 for this :)
<pitti> ok
<pitti> persia: so, if that FTBFS was on our radar and this upload fixes it, all is well; I just thought I'd check before building it twice :)
<StevenK> pitti: -modules 6 uploaded, review at your leisure.
* StevenK is getting sick of virtualbox again.
<persia> pitti: I'm glad you checked.  I'm seeing http://paste.ubuntu-nl.org/40704/ in a local build log, which matches the Debian report, but shows some extra characters when compared to the LP report.
* persia tries cjwatson's fix to see if it's different
<mvo> mathiaz: hello! I got this here http://paste.ubuntu.com/934/ during a server upgrade test. the release-upgrader overwrites invoke-rc.d failure to be not fatal, but with a regular upgrade, people will get bitten by this. could you please check?
<mvo> mathiaz: I'm happy to provide full logs+typescript
<soren> pitti: Oh, thanks for doing the linux-meta stuff for -virtual. It slipped my mind somehow.
<pitti> soren: you're welcome
<mathiaz> mvo: I'll have a look a bit later. Is it urgent ?
<Hobbsee> mvo: a question for the dist-upgrader - if the line in the sources list cant be read, why does the updater not comment it out and go on, rather than bailing out with an error?
<mvo> mathiaz: no, just FYI (shouldn't be a big issue for all who use the release-upgrader)
<ogra> Chipzz, ?
<soren> mvo: What is your upgrade test stuff running on?
<mvo> Hobbsee: because its silly. seriously, because the line may be important, if e.g. the user accidently put "debx http://country.a.u.c/ubuntu universe", then this may lead to a disabled universe. I agree that the error is pretty bad though
<mvo> soren: it runs in a VM somewhere in the DC, I don't even know, I do not have direct access. but this particular problem I found during some mnual testing
<Hobbsee> mvo: i'm surprised that the lines for their normal archives dont get added though.  what happens in the case where i'm onlyusing a pacificnet mirror, and nothing with archive.ubuntu.com in it?
<soren> mvo: Oh, ok.
<soren> mathiaz: Ah, I think I see what's going on.
<mvo> Hobbsee: if it is a mirror that it knows, it will be happy. it has a mirror list from LP
<soren> mathiaz: After upgrading the new kernel is installed, but not running, so we can't load the apparmour modules.
<Hobbsee> mvo: my pacificnet mirror is not picked up.
<mvo> Hobbsee: is there a particular bug you are refering to?
<mathiaz> soren: yes.
<soren> mathiaz: Because they don't exist for the running kernel.
<Hobbsee> mvo: it's not listed on the official lot of mirrors
<mathiaz> soren: it should be taken care of in the postinst script.
<Hobbsee> mvo: just something i saw a few days back, and thought looked odd - but i'm unconvinced about the mirror checking anwyay (and mean to file a bug abotu it)
<mvo> Hobbsee: hrm, what should happen in this case is, that it should ask you about it. something like "I can't find a mirror, I'm desperate, should I add one for you or just go ahead"
<Hobbsee> mvo: that'd be good.
<mathiaz> soren: in apparmor.postinst: invoke-rc.d apparmor start || true
<mvo> Hobbsee: that is the behavior that it *should* have (unless there is a bug of course)
<Hobbsee> mvo: (our au.archive.ubuntu.com absolutely *sucks*, so most people dont use it)
<soren> mathiaz: How would that fix anything?
<Hobbsee> mvo: ah right.  i have both lots enabled, so i dont come up against it
<mathiaz> soren: the package upgrade won't fail.
<mathiaz> soren: you still get the warning messages, but the upgrade won't fail.
<soren> mathiaz: Ah, right. (/me is trying to do many things at once, apparantly)
<mvo> Hobbsee: I'm happy to talk to you about improving the mirror handling, but if its not a bug, I would prefer doing that post-release (or at UDS) :)
<mvo> upgrade-not-fail++
<mvo> maintainer-script-failure: BAD
<Hobbsee> mvo: i wont be at boston.  in the next one, though...
<Hobbsee> mvo: i will if i get sponsored
<mvo> Hobbsee: oh, a shame :/
<persia> pitti: I've just done some more testing, and the version I uploaded isn't generating any strange characters on installation, and appears to work successfully.
<mathiaz> mvo: we've already seen this situation and it's taken care of in the postinst scripts. An apt-get upgrade won'T fail either.
<pitti> persia: cool, thanks
<Hobbsee> mvo: i turned it down due to uni - i'm doing a fairly complex subject on electrodynamics, and not really liking it.  so, if i go, i'd probably fail the subject.
<mvo> mathiaz: aha, great!
<pitti> persia: accepted then; I'll give back nsimap after it built and is in the archive (that'll take a while, though)
<mvo> mathiaz: aha, I see it now, good
<persia> pitti: Thanks.  I'll take a peek in my morning (~7 hours).
<Hobbsee> mvo: which is, of course, bad, as i want to finish uni at some point in the reasonably near future :P
<iwj> mvo: There's definitely something strange there.
* mvo nods
<iwj> mvo: But the log seems corrupted.
<iwj> It's almost like there are two copies of dpkg running at once.
<dholbach> why was the apt-listchanges 2.74ubuntu4 rejected?
<dholbach> ... upload ...
<ivoks> seb128: when you have time, take a look at #152107
<mvo> iwj: I will request /var/log/dpkg.log from the user
<iwj> mvo: It's very weird.
<iwj> You've got nothing that could remove the dpkg lock, have you ?
<mvo> iwj: no, I can not think of anything
<iwj> Is this term.log collected by u-m via a pty arrangement ?
<iwj> Another possibility is that something there is mangling it, eg processing data twice.
<mvo> iwj: this one is not, its done via vte signals, the next version will use the native libapt pty mangling stuff
<mvo> iwj: yeah; I was thinking the same (broken logging)
<iwj> vte signals ?
<seb128> bug #152107
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
<mvo> iwj: vte is the gnome/gtk terminal widget
<seb128> ivoks: I've read it
<iwj> Although if the log is broken that just means we don't understand what dpkg did and why, not that there is no bug in dpkg.
<iwj> mvo: Ah.
<mvo> iwj: it sends "content-changed" signals to the application
<seb128> ivoks: that's nothing new and not something we will change before gutsy now
<iwj> mvo: Ghgggg.
<mvo> iwj: yeah :/
<mvo> iwj: dpkg.log should give us the details hopefully
<iwj> Well, it'll tell us something hopefully :-)
<ivoks> seb128: ok
<tkamppeter> seb128, ping
<seb128> tkamppeter: hi
<tkamppeter> I have a problem, I want to fix 152107 with a tiny patch so that users can admin printers easily
<tkamppeter> seb128 I have tried
<tkamppeter> --- gnome-system-tools-2.20.0~/src/users/privileges-table.c     2007-09-14 10:25:27.000000000 +0100
<tkamppeter> +++ gnome-system-tools-2.20.0/src/users/privileges-table.c      2007-10-15 16:32:38.000000000 +0100
<tkamppeter> @@ -54,6 +54,7 @@
<tkamppeter>         { "dip", N_("Connect to Internet using a modem") },
<tkamppeter>         { "fax", N_("Send and receive faxes") },
<tkamppeter>         { "floppy", N_("Use floppy drives") },
<tkamppeter> +       { "lpadmin", N_("Administer printers") },
<tkamppeter>         { "plugdev", N_("Access external storage devices automatically") },
<tkamppeter>         { "scanner", N_("Use scanners") },
<tkamppeter>         { "tape", N_("Use tape drives") },
<seb128> tkamppeter: it's too late to get such changes to gutsy now
<tkamppeter> but this does not let the entry "Administer printers" apper
<tkamppeter> ar in the GUI.
<Mithrandir> tkamppeter: gutsy-updates.
<seb128> no
<seb128> new strings to stable is not a good idea
<Mithrandir> that's a point too
<tkamppeter> seb128, so better forget about it completely for now and help people 1 by 1 in private if they report printer admin access problems?
<seb128> tkamppeter: yes
<tkamppeter> seb128 perhaps better suggest this change on the user manager upstream, so they get 6 months to integrate it correctly, translate, and test it so that it gets grabbed by Hardy.
<seb128> tkamppeter: what is the issue exactly? the admin tools run under gksu anyway no?
<seb128> tkamppeter: and users should already be added to lpadmin
<pitti> seb128: not additional users you create
<seb128> the desktop and admin profiles list lpadmin
<seb128> pitti: why not?
<seb128> pitti: /etc/gnome-system-tools/users/profiles has those
<pitti> ah, so it's only an UI issue, not a missing functionality?
<tkamppeter> seb128, printing is special. The printer tool does not run under gksu, as CUPS provides non-root admin for users in lpadmin group.
<pitti> well, it *can* run under gksu, of course :)
<seb128> tkamppeter: well, if the config tool was not working somebody would have noticed for sure
<ivoks> pitti: but then one can't set up options per user
<ivoks> seb128: that was the bug i told you
<ivoks> users-admin doesn't work.
<tkamppeter> the users-admion tool has a bug ignoring the "lpadmin" in the group list of /etc/gnome-system-tools/users/profiles. It adds the new user to all groups but lpadmin -> bug 152107
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
<ivoks> create new admin user, it doesn't add user in lpadmin group - new admin can't manage printers
<seb128> ivoks: so it would be nice to debug it
<tkamppeter> For me it seems that users-admin has somewhere a list of groups with which it deals and all other groups it simply ignores.
<seb128> ivoks: I'm sorry but people tell me about hundred of bugs so it's going to take me some time to get there, but patches are welcome ;)
<ivoks> seb128: i was debugin, but you said it's done for gutsy :)
<seb128> ivoks: did I?
<seb128> ivoks: I said it's too late for gutsy rather
<tkamppeter> So "lpadmin" needs to be added to the secret list of groups in users-admin, so that users-admin adds users to it, both by means of the profiles or the privileges tab.
<ivoks> yeah
<seb128> tkamppeter: looks correct
<ivoks> that's what i tought, but maybe didn't write it clearly
<tkamppeter> seb128, if one patches this "secret list" in users-admin the adding of users to "lpadmin" via profile will work. In addition one could patch users-admin to add users to both "admin" and "lpadmin" if one checks "Administer the system". This way one can fix bug 152107 without adding strings.
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
<seb128> tkamppeter: right
<seb128> jamiemcc: the patch you sent to fix the crasher is not valid
<seb128> jamiemcc: "**** malformed patch at line 24: @@ -537,11 +574,21 @@"
<jamiemcc> seb128: is it malformed?
<seb128> jamiemcc: yes
<tkamppeter> seb128, how much are you knowledgeable about the gnome-system-tools? Could you fix this for Gutsy or at least for Gutsy-Updates?
<jamiemcc> seb128: yeah I did a cut and paste job - will ifx now
<seb128> jamiemcc: thanks
<ivoks> seb128: note that new admin should also be in netdev and powerdev
<tkamppeter> seb128, this is probably a very small patch.
<seb128> tkamppeter: not that much, and I could do a patch but as said it's getting late and I'm not the one approving uploads
<ivoks> (yeah, working on a patch) :)
<seb128> ivoks: what is netdev and powerdev?
<tkamppeter> Someone approving uploads here?
<pitti> o/
<seb128> tkamppeter: pitti does
<Hobbsee> tkamppeter: release team is
<ivoks> seb128: powerdev is for UPS's, IIRC
<tkamppeter> pitti, can you approve an upload of gnome-system-tools? A tiny patch to make it handling the group membership management of admins correctly for Ubuntu.
<pitti> tkamppeter: I can review and approve, but not actually do the patch/uploading
<tkamppeter> Hobbsee, thanks, I meant people here on the IRC to get quick reaction.
<pitti> tkamppeter: besides, it's getting late; uploads were supposed to be done by 1200 UTC today
<pitti> tkamppeter: but TBH this is perfectly valid for -updates
<Hobbsee> tkamppeter: tab completion is your friend, if you know who's there
* Hobbsee yawns, thinks fo bed.
<pitti> tkamppeter: this bug does not impede the installation at all
<ivoks> this can go into -updates
<pitti> tkamppeter: but having a bug report with a patch available would be great, of course (for an SRU)
<jamiemcc> seb128: delete line 23 of the patch and it should work
<tkamppeter> seb128, ivoks, then prepare the patch for -updates. If it drops in by auto-updates a week after release or so no one will notice that there is something wrong.
<seb128> jamiemcc: that works, thanks
<jamiemcc> seb128: gtr thx
<seb128> tkamppeter: right
<tkamppeter> seb128, ivoks, re-milestoned bug 152107 to "gutsy-updates".
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
<seb128> tkamppeter: thanks
<tkamppeter> seb128, ivoks, I have added a longer comment to bug 152107 with suggestions what needs to get fixed and also suggesting it as an urgent SRU.
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
<asac> ogra: bug 137598 -> patch: http://launchpadlibrarian.net/9690288/gpm-backlight.c.diff ... did you ever take a look?
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
<mvo> slangasek: what are the chances to fix a resource leak in libapt at this point (dpkgpm.cc)? chances to go in or should I get it into -updates?
<slangasek> mvo: -updates please
<bryce> mvo, where is the compiz blacklist stored on the filesystem?
<mvo> slangasek: leaks on fd per configure/unpack run so it would be kind of cool to have it :/
<mvo> bryce: in /usr/bin/compiz
<bryce> thanks
<mvo> bryce: we should probably put that into a seperate file in /usr/share/ something for hardy
<bryce> yeah, or /etc/ something
<slangasek> mvo: is this a regression vs. feisty?
<mvo> slangasek: yes
<mvo> slangasek: give me a sec, I add the diff
<slangasek> mvo: ah.  so it's not been a problem so far, but when users try to upgrade from gutsy to hardy it will be?
<mvo> slangasek: yes, also we will be able to work around it by enforcing a upgrade prerequist (special backport that is only used during the upgrade)
<albertito> does anyone know if the bash bug 149527 (reported 10 days ago) is going to be fixed by the time of the release, or will it have to wait?
<ubotu> Launchpad bug 149527 in bash ".profile not sourced anymore" [High,New]  https://launchpad.net/bugs/149527
<slangasek> mvo: right, though upgrade prerequisites are IMHO best avoided where possible
<slangasek> mvo: if you have the fix ready to upload right now, I can at least consider it since I still have to argue with seeds a bit
* Starting logfile irclogs/ubuntu-devel.log
<lamego> albertito, I was unable to reproduce the bug
<mdke> dendrobates: ping?
<dendrobates> mdke: hey
<mdke> damn, phone
<soren> I've just booted the RC livecd on a system with an nvidia graphics card. Isn't the restricted-manager supposed to show up?
<mdke> dendrobates: hiya; I saw an entry for "server-documentation" on scott's schedule for the conference. I just wanted to check that you were aware of the ubuntu-serverguide package and find out if you need any help about who works on it and so on
<stgraber> soren: Why would you want the restricted-manager to show up on a livecd ?
<soren> stgraber: To let me know that I need evil stuff to use the hardware?
<albertito> lamego: using gusty's bash?
<stgraber> soren: as restricted-manager suggests to reboot after installing a restricted driver and you can't reboot a livecd
<stgraber> soren: it'll at first boot
<albertito> lamego: and the testcase I provided in the last comment?
<dendrobates> mdke: I am aware of it.  We would like to be more involved with it and help keep it up to date.
<lamego> albertito, yes
<soren> stgraber: Not all hardware needs a reboot.
<dendrobates> mdke: That is one of the things we plan to discuss at UDS.
<soren> stgraber: e.g. winmodems.
<albertito> lamego: how did you try? did you used "source bash-bug.sh"?
<mdke> dendrobates: more input from you guys would be tremendous
<albertito> lamego: somebody else on this channel confirmed it as well the other day (I don't remember the name :S)
<lamego> unset ok; echo $ok; source .ok ; echo $ok
<mdke> dendrobates: so if you want information about processes or whatever just give me a shout
<lamego> this was my test, with ok=1 on .ok, the output was 1 :)
<dendrobates> mdke: Thanks, I will.
<albertito> lamego: but the readonly thing makes the difference
<mdke> dendrobates: I'm hoping that the team will move to bzr shortly which will make contribution a bit easier
<lamego> what readonly thing ?
<stgraber> soren: well, then the restricted-manager should show up only if a piece of hardware that can be enabled without rebooting (nor restarting X) and hide all the others (we don't want someone to turn on the nvidia X driver on the livecd). Seems a bit hard to implement just for install time, doesn't it ?
<albertito> lamego: the testcase I provided set the variable as read only, like bash-completion does
<Mithrandir> hm, can we blacklist ubuntu-desktop from apport autofiling bugs?  They're not really useful, I think..
<lamego> albertito, the bug report was about "source not working", what does that to do with a readonly variable ? :)
<soren> stgraber: Possibly. anyhowm if it's not supposed to show up, that's good enough for me. I just wanted to know if it was a bug.
<cjwatson> soren: restricted-manager is disabled on the live CD. (Ask pitti.)
<soren> cjwatson: Fair enough.
<albertito> lamego: have you read the last comment? it's not just "source" that doesn't work. It does work, but has a subtle difference when the sourced file fails. The last comment provides a testcase, explains why it happens, and what bash patch in ubuntu11 causes the bug
<albertito> lamego: the bug shows up because sourcing your .bashrc doesn't work anymore, if you source bash-completion inside your bashrc (which is quite common)
<cjwatson> soren: actually, I misremember, Riddell did it
<cjwatson> soren: it's rather beneficial though since it means we save about 20MB of memory by being able to avoid linking fglrx and nvidia* on the live CD
<cjwatson> in the live session at boot, I mean
<albertito> lamego: it's not sourcing in general, the issue is the (very very common) interaction between bashrc and bash-comlpletion
<lamego> ok, I didn't read the last comment careful, my test cased was based on the bug title
<lamego> albertito, to be honest, i never used shell read only variables :)
<albertito> lamego: yeah, the title is the "common symptom", but it's not actually where the bug is
<soren> cjwatson: Right. I was just thinking it'd be nice to know on the livecd that the installed system would need restricted stuff.
<soren> anyhow, I've got to run..
* soren vanishes
<albertito> lamego: neither did I, but bash-completion does it by default, and the bash patch changes the behaviour and breaks it
<albertito> lamego: and while it's not completely critical, many people are used to source their bashrc, and it won't work
<lamego> lamego@lamego-desktop:~$ source bash_bug.sh
<lamego> 1
<lamego> bash: ROVAR: readonly variable
<lamego> lamego@lamego-desktop:~$
<albertito> (if they have bash_completion enabled, which is normal these days)
<lamego> it reports the error, and stops, what is wrong about that behavior, besides it changed ?
<albertito> lamego: let's say you source bash_completion at the beginning of your bashrc, which is quite normal
<albertito> lamego: the way it worked before was that bash_completion complained about the ro variable, but kept on going. So the source succeeeded, and so did the rest of your bashrc
<lamego> albertito, if that is the case, I need to fix my .bashrc to follow the new behavior
<albertito> lamego: now, source bash_completion fails after it tries to set the ro variable, and instead of continuing, it stops. It also stops the bashrc sourcing, so the rest of your bashrc is not ran
<albertito> lamego: no, because the bug is in bash_completion
<albertito> lamego: bash_completion _depends_ on the behaviour that trying to set a ro variable will _not_ halt the sourcing
<albertito> lamego: so either you remove the patch and keep the old behaviour, or you should fix bash_completion not to use ro variables (or use some other trick to avoid setting them)
<lamego> albertito, I must be missing something I do have an . /etc/bash_completion on my .bashrc which is the stock one
<albertito> lamego: yes, as most people do, because it's the stock one
<lamego> and I do have custom code on .bashrc after the bash completation line
<lamego> and that code gets sourced
<albertito> lamego: well, in gutsy's bash, if you touch something in your .bashrc after sourcing bash completion, and do "source .bashrc", it won't run because it halts in sourcing /etc/bash_completion
<albertito> lamego: it rans well the first time because the ro variable doesn't exist. The following invocations (ie. you changed your bashrc and want the current shell to source it) fail
<albertito> (s/rans/runs!)
<lamego> ok, you are correct
<albertito> lamego: the problem is inside /etc/bash_completion and the way it handles the read only variables, it depends on the old behaviour
<lamego> ok, I am convinced, sorry :P
<albertito> lamego: np, thanks for taking the time to test this =)
<lamego> people will just relogin,  but well, it is a bug :P
<lamego> albertito, it is kind of late to fix non critical bugs, i think :P
<albertito> lamego: I guess, I was just curious
<jdong> hmm, I seem to have a suspend regression on today's updates
<jdong> I suspect the new kernel
<jdong> Macbook core 2 duo, Intel GMA950
<jdong> resume just is a black screen
<jdong> maybe it's the new -intel, but I've used bryce's -0ubuntu9 unofficial package before without a problem
<jdong> turned off vbesave and turned on double console switch, and I'm alive this time
* jdong goes to test more
<bryce> yeah, that unofficial -0ubuntu9 is identical to what I uploaded last night, so if it worked fine before, then it's not likely to be the source of a problem that started today
<jdong> ok, turning off vbesave and turning on double_vt_switch has been successful for me over 5 cycles
<jdong> if vbesave is on, then the screen doesn't wake on resume...
<jdong> if double console switch is off, then all the VT's are lost on resume
<mathiaz> keescook: I'd like to make some apparmor profiles changes (not for release though). How should we handled the split gutsy/hardy from the bzr point of view ?
<keescook> mathiaz: if we ever SRU gutsy, we can just branch from the current version.
<mathiaz> keescook: should we create a bzr branch for gutsy and keep developping in the ubuntu branch for hardy ?
<keescook> mathiaz: IOW, hardy is just the normal branch, and we keep moving.
<keescook> mathiaz: I don't see a reason to explicitly create the gutsy branch until we need it, though.
<jdong> keescook: would it hurt to have that landmark?
<jdong> i.e. if someone else were to want to try to create a SRU it's more convenient
<mathiaz> keescook: true. we can always go back in the changelog and branch from that bzr revision.
<keescook> jdong: sure, that's true.
<keescook> jdong: let me push one right now.
<Riddell> mertiki: very strange, I'm sure I uploaded that.  done so now but I don't know if the release dudes will want it in this late
<jdong> cool
<jdong> keescook: unrelated apparmor question... does apparmor have a way to explicitly deny/reduce access to a specific path? i.e. if I want users to have access to all files BUT foo
<keescook> jdong: I think you can do overlapping rules?  I haven't tried.  like:
<keescook>   /path/to/okay/stuff/*  r,
<keescook> er
<keescook> maybe not.  how do you drop perms?
<jdong> that's what I'm wondering
<mathiaz> keescook: good question...
<keescook> I was going to say something like  /path/to/okay/stuff/exceptthis -r
<keescook> but I don't think "-r" exists.  ;)
<jdong> that would be a nice feature of apparmor.... if there's a way to specify no access
<keescook> jdong, mathiaz: I'm pushing http://bazaar.launchpad.net/~ubuntu-core-dev/apparmor/ubuntu-gutsy/   now
<keescook> it'll probably take a while.  ;)
<mathiaz> keescook: great !
<mathiaz> keescook: yes. I confirm...
<jdong> hehe
<Nafallo> keescook: ubuntu-hardy? ;-)
<keescook> Nafallo: nah, we'll keep the -hardy work in just plain ubuntu/
<mathiaz> jdong: denying access would go against the idea of apparmor, which is to deny by default, and then grant specific access.
<Nafallo> keescook: ah, kewl :-)
<jdong> mathiaz: that's what I figured. It's a shame tough, because in some cases the inverse workflow would express what I want to do more easily
<mertiki> Riddell : You think so? Same if it's a fix?
<mertiki> Riddell : Because if Gutsy is released without that patch.. Qt3 apps will be very ugly..
<tkamppeter> Can anyone block the user etos@bk.ru  from posting on the Launchpad? See bug 147800. He has spammed a lot of LP bugs this way.
<ubotu> Launchpad bug 147800 in cupsys "[Gutsy]  : bluetooth printing was working but is not (at the beginning of september)." [High,Confirmed]  https://launchpad.net/bugs/147800
* Adri2000 wonders if there is anyone from the release team available to approve audacious-plugins ubuntu4
<ScottK> Adri2000: Give me the short version of why they should and I'll see what I can do.
<Adri2000> ScottK: it fixes my mistake in the previous upload which breaks the upgrade path
<ScottK> OK.
<ScottK> Adri2000: Looks like it's been accepted already.
<Adri2000> I still see it at http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/audacious-plugins_1.3.5-3ubuntu4.dsc
<Adri2000> and it doesn't show up on https://lists.ubuntu.com/archives/gutsy-changes/2007-October/date.html (there is only ubuntu3)
<ScottK> Publisher is on manual.  It won't show until after the next publisher run.
<Adri2000> ok.
<cjwatson> publisher> ... which is in progress
<ScottK> Adri2000: Did you get any rejection mail?
<ScottK> Adri2000: My bad.  It was rejected. I'm asking to see if we can get it in?
<Adri2000> ScottK: argh. no I got nothing as I'm not the uploader. TheMuso is.
<ScottK> Adri2000: Looks like you need to work on your first Gutsy SRU. ;-)
<ScottK> Adri2000: The goal is to have gutsy-updates ready on release day, so it could be pretty painless.
<Fujitsu> Is gutsy-proposed etc. not available pre-release?
* persia thinks they will be built during the archive freeze
<ScottK> No.  They have to freeze the archive to copy it to dak for -security and -updates.
<ScottK> Actually dunno about -proposed.
<ScottK> If I understand this stuff correctly.
<Adri2000> ScottK: you're sure it's too late? :(
<Fujitsu> dak only does -security. -updates and -proposed are already existing.
<ScottK> Adri2000: Yes.  RM said no.
<ScottK> OK.
<ScottK> Adri2000: Upload it to -proposed and we'll see what we can do to get it published.
#ubuntu-devel 2007-10-16
<TomaszD> hi, I'm working for a publishing company and we need to have access as early as possible to the final gutsy i386 image, so that we can remaster it and release it in our magazine (about 5000 copies). 18th is the release date, but I'm sure the isos are built a day earlier right? is it possible to get them somehow to avoid the inevitable queues?
<pitti> TomaszD: no promises, but we hope to have final images in a few hours
<slangasek> "few"
<pitti> TomaszD: check the dailies tomorrow morning, they *should* be pretty much final
<pitti> TomaszD: but as I said, we can never rule out emergency rebuilds for high-profile bugs
<slangasek> TomaszD: we can make sure you have access to our candidate images, but please don't commit to pressing them until they're publically announced as final
<TomaszD> pitti, alright. I understand. Thanks.
<TomaszD> slangasek, sure I just need something to work on and then send to the office, it'll be pressed on the 19th, but I need time for testing my remastered copy
<TomaszD> it would be downright insane having to do all this in one day
<slangasek> TomaszD: sure :)
<TomaszD> great!
<slangasek> TomaszD: well, as pitti mentions, the candidate images are published as dailies, so they'll be available here: http://cdimage.ubuntu.com/
<TomaszD> I know that place already, yeah :] 
<TomaszD> so I basically need to look here http://cdimage.ubuntu.com/daily-live/current/ tomorrow right?
<slangasek> yes
<TomaszD> and what is tomorrow for you, because here's it's already tomorrow (01:06AM)
<TomaszD> *here
<TomaszD> like, in 10hrs would be fine?
<slangasek> tomorrow for me is different than tomorrow for pitti, but he means the morning of Oct 16 European time, yes :)
<TomaszD> alright, thanks again, will get the daily live in ten hours then and assume it's final, hope I'm not going to die a painful death because of that ;] 
<TomaszD> bbl
<slangasek> TomaszD: at a minimum, could you check that the md5sum of your downloaded image matches the released image once the release is announced, to make sure we didn't re-roll the image?
<TomaszD> slangasek, I will
<pawalls> doko, ping
<doko> pawalls: just ask
<pawalls> doko, Actually, this probably belongs in #ubuntu-bugs. Moving there.
<slangasek> tepsipakki: would you be able to condense bug #132716 to a release note item for me?
<ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Confirmed]  https://launchpad.net/bugs/132716
<Hobbsee> morning slangasek
<slangasek> tepsipakki: there doesn't seem to be a description in the bug of what the recurrent problem is on the 7500, so someone who knows what that issue is will have to do it
<slangasek> Hobbsee: morning
<bryce> slangasek: fwiw, I just got pinged by alex about 30 min ago with a potential fix for that bug.  I'm building a git snapshot for testing.
<slangasek> bryce: it still won't land for final, so I still need a description for release-notes
<thully> Hi - I lost suspend as of the -13 Ubuntu kernel (bug #151016), and I'm currently looking to get this debugged.  Any pointers?
<ubotu> Launchpad bug 151016 in linux-source-2.6.22 "New in 2.6.22-13: No video after resume from suspend on MacBook" [Undecided,New]  https://launchpad.net/bugs/151016
<thully> One thing - I noticed this:
<thully> clockevents: remove the suspend/resume workaround^Wthinko
<thully> in the changelog, and I'm wondering how I may test "un-removing" this patch.  This patch was applied to the tree at the same time I started having suspend issues...
<thully> (un-applied)
<redwoolf> is anyone else having trouble with libglib-2.0 on ubuntu? pkg-config says that it can't find glib-config.
<Hobbsee> TomaszD: at the very least, you can grab the latest daily, then rsync it against the final - so you dont need to download hte whole lot again
<Hobbsee> Mithrandir: we should do that for all -desktop packages (blacklist them from apport).  i've yet to find a useful one.
<redwoolf> my error, not a bug. nevermind!
<thully> hi - does anyone here know who I should bring kernel regressions to the attention of?  Going from -12 to -13 (and-14) killed suspend for me, and my bug on Launchpad has had no response...
<Hobbsee> #ubuntu-kernel, probably when tehy're actually awake
<Hobbsee> if it was going to -13, why wasnt it raised earlier?  it's likely too late for gutsy
<thully> I reported the bug over a week ago and e-mailed several kernel-related contacts
<Hobbsee> ok
<thully> and they ignored me (well, one dev told me not to e-mail him)
<Hobbsee> i'd assume that you'll have to take that up with the kernel team, as it's their domain.
<thully> yeah, these were contacts off the kernel team page... one person mentioned reverting the one patch that seems suspicious, but I can't even find the old code/diffs to do that..
<thully> One question - if I applied for/got QA access, would my bugs be looked at quicker?  I've had many issues which I've attached extensive information and even patches that have gone unresponded-to for months...
<Hobbsee> possibly.  quite unlikely
<Hobbsee> the problem is that there are so many bugs for the kernel stuff, adn so few looking at them
<Hobbsee> it tends to be judged by severity, rather than who reported them
<thully> yes, this is more frustrating because -12 worked fine, and then -13 messed things up
<lifeless> Hi thully
<lifeless> there is a dedicated channel, ubuntu-kernel
<thully> OK
<lifeless> the kernel folk have two problems I know of
<lifeless> one is sheer volume as Hobbsee
<lifeless> says
<Hobbsee> and the other is hardware-specific bugs, and not having access to the hardware?
<lifeless> yah
<lifeless> and also obviously destabilising things
<lifeless> you don't want to break peter by breaking paul
<lifeless> erm fix
<lifeless> anyhow
<lifeless> I've had things sit for months too
<lifeless> and I work with the guys
<lifeless> I find the best way, with kernel bugs, when the fix is known, is to get someones attention in #ubuntu-kernel, and say 'there is a fix, please look, tell me what is missing to be able to apply it'
<thully> I guess i'm curious how I could look at the diffs between kernel revs and try reverting some of the patches.  One of the -13 changes related to suspend/resume, and I'd like to try reverting that
<lifeless> the kernel tree is maintained in git
<lifeless> there is a wiki page doucmenting where it is and how its maintained
<thully> I know nothing about git - particularly doing anything more than checking out the latest
<lifeless> you could also just grab the source package
<lifeless> yeah
<thully> I did, but i only have the latest and not the source from the working version
<lifeless> that is a problem, its in git because upstream is primarily
<lifeless> oh, right, archive churn will make old source disappear when its superceded
<mathiaz> thully: check out kernel.ubuntu.com
<thully> mathiaz: THANKS!  that's exactly what I needed.  I figure I'll try reverting suspicious patches one at a time and see what broke it
<mathiaz> thully: np. Good luck in your quest ;)
<thully> I just found the commits I wanted to try reverting..
<thully> Also, in another issue - does anyone here do gnome-power-manager?  There's an annoying bug I reported long ago that I posted a patch for and haven't heard back on...
<Hobbsee> thully: ogra: does, and he's german.
<thully> OK - will try tomorrow...
<tepsipakki> slangasek: sure!
<pitti> Good morning
<LaserJock> morning pitti
<StevenK> Morning pitti
<lamont> morning pitti
<lamont> :-_
<pitti> hey lamont
<pitti> good morning LaserJock, and Stevenk
* StevenK uploads crack, just so pitti can exercise rejecting packages. :-P
<pitti> no need to, by now I can drive the queue tool without looking at it :)
<lamont> pitti: remind me when the publisher runs
<StevenK> x:03 or so
<pitti> right, it's back on auto
* LaserJock imagines a YouTube video of pitti running Ubuntu blindfolded
<pitti> did someone say something? my IRC client beeped
<pitti> :-P
<TheMuso> LaserJock: I could be that one running it blindfolded if you want. :p
<TheMuso> pitti: Load orca.
<TheMuso> :p
<pitti> TheMuso: I actually tried that; amazing
* lamont glares at kdesdk
<pitti> needs some getting used to, of course, but I switched off my monitor for a while to try
<lamont> the build finished.  why doesn't launchpad want to admit it, i wonder
<StevenK> One of the games we used to threaten to play in the office at my previous job was to take people's screens away and force them to use speakup or emacspeak.
<TheMuso> pitti: Yeah of course.
<TheMuso> StevenK: ROFL.
<TheMuso> pitti: Then theres making it speak as fast as it possibly can. That again takes getting used to. :p
<pitti> uh, yes
<TheMuso> pitti: I'd probably struggle if I had to use GNOME/Orca in a different locale. :) like German.
<TheMuso> Espeak would have no problem pronouncing stuff however.
<pitti> TheMuso: Deutsch ist kein Problem :)
<pitti> TheMuso: I tried espeak with German; it's comprehensible, just sounds funny
<pitti> but that's equally true of the English it produces IIRC
<lamont> pitti: if you're totally bored, once https://edge.launchpad.net/ubuntu/+source/kdesdk/4:3.5.8-0ubuntu1/+build/408426 admits to being done, a manual publisher run to kick kdewebdev in the butt will help it finish sooner... (iz 70 minute avg-pkg-build-tiem)
<TheMuso> pitti: Yeah its getting used to synthesized speech in general.
<lamont>  gutsy hppa   Successfully built  (ACCEPTED)
<lamont> pitti: so if you're bored, :-)
<pitti> lamont: can do, but the current one is still running
* TheMuso should work with the espeak developer to get Australian english available. :p
* pitti watches jigdo construct a server iso from an old server and alternate in no time and hugs it heartily
<lamont> pitti: ah, ok.
<lamont> anyway, sync of the mirror finished, heading home.
<pitti> lamont: I'll start another one right after that, just for you :)
<lamont> some days, sneakernet sucks
<torkel> TheMuso: just add 'mate' at the end of every sentence? :-)
<StevenK> Oh yes, I love jigdo.
<lamont> pitti: damn.  what's that make it now, 20 beers?
<pitti> lamont: not all at once, please
<lamont> lol
<TheMuso> Jigdo absolutely rocks for those who are quota deprived. :)
<TheMuso> torkel: lol
<lamont> anyway, afk for about 30-40 min, then back online for about 2 min before falling into bed.
<StevenK> I can build an image in about 3 minutes thanks to my local mirror.
<TheMuso> Now all we need is something similar for live CDs. :p
<TheMuso> Stop bragging already StevenK.
<pitti> TheMuso: rsync is not too bad for those
<TheMuso> pitti: If quota weren't a problem, yes.
<TheMuso> s/weren't/wasn't/
<pitti> StevenK: did you ever try rsyncing the dvd .template against the desktop CD for jigdoing a DVD?
<StevenK> pitti: rsync'ing a live CD still manages to take me about 45 minutes.
<pitti> TheMuso: it is for me, too (3 GB/7 days)
<StevenK> pitti: So it takes you two weeks to download a DVD?
<pitti> StevenK: no, it doesn't
<pitti> StevenK: simple solution: don't download DVDs :)
<pitti> StevenK: well, I downloaded some at debconf, or in the London office
<StevenK> I have to say, my plan is far better - 24Gb/month, with 12am - 12pm uncounted.
<TheMuso> StevenK: The interndoe plan we stared on was good value, till it was changed.
<TheMuso> s/interndoe/internode/
<StevenK> I'm eyeing Exetel's ADSL2+ plans.
* LaserJock pats his trusty old USA DSL line
<LaserJock> it may not be the fastest, but I can chug away as long as I like
<Burgundavia> indeed
<Burgundavia> this metered internet stuff is crap
<Fujitsu> LaserJock: You mean it's actually unlimited?
* Fujitsu is on Optus' old Unlimited plan, 12/24.
<Fujitsu> Very well named, obviousl.
<StevenK> Look at the map of the Internet that turned up on Planet Debian and you'll see why.
<Fujitsu> *obviously.
<StevenK> The US has all the bandwidth, and the rest of the world has a little bit.
<Burgundavia> most people in Canada are not de jure unlimited, but de facto are
<pitti> stgraber: FYI, ISO tracker staffed, DVDs coming
<Mithrandir> StevenK: heh, sure? :-P
<Burgundavia> I had a friend who got warned at 56 GB in a single month
<Mithrandir> I only have a 6.5MBit here, that's true.
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy release freeze in effect | Please test the Gutsy final CD candiates: https://iso.qa.stgraber.org/
<Burgundavia> pitti: do you have an approx. time of day that you plan to release the final ISO?
<pitti> Burgundavia: the ones in the tracker *are* the final ones (hopefully, *crossing fingers*)
<Burgundavia> no, I mean send the public announcment
<pitti> Burgundavia: oh, no idea; slangasek will do it, but traditionally it's around noon
<Burgundavia> noon UTC?
<pitti> yeah
<Burgundavia> on the 18th?
<Fujitsu> Yay, another `omg I just discovered the ISOs in .pool let's tell everybody to get them now!' coming soon.
<liw> oh, there's new ISOs? I was waiting for the tracker's e-mails about them
<pitti> stgraber: hm, that didn't work so well; all the flavours just say "ubuntu"; can you please have a look?
<pitti> liw: freshly added, you shuold get them, unless there's something else broken
<liw> ah yes, there's the e-mail
<liw> timing is everything
<pitti> hi dholbach
<dholbach> good morning
<dholbach> hey pitti
<Fujitsu> Hi dholbach.
<dholbach> hey Fujitsu
<Burgundavia> LaserJock: can I get a final proof read of my story in the fridge queue?
<LaserJock> Burgundavia: yep, one sec
<LaserJock> Burgundavia: Day 2 right?
<Burgundavia> LaserJock: nah, it is live already :)
<Burgundavia> don';t worry, mdke got it
<LaserJock> pfft
<Burgundavia> you can look at it if you want
<Burgundavia> top story
<Amaranth> Burgundavia: Why the hate on packagekit? :)
<Amaranth> Burgundavia: It seems to be explicitly designed to replace gnome-app-install and update-manager
<Burgundavia> Amaranth: not, it is designed to fit underneath them
<Burgundavia> and I don't hate it
<Burgundavia> just don't think it is good for hardy
<Amaranth> I meant the GNOME UI they have for it
<LaserJock> I was looking at packagekit yesterday
<Amaranth> The whole idea came out of 'making gnome-app-install work everywhere'
<LaserJock> or rather saw what it was and put on my list of "hmm, that could be interesting"
<Burgundavia> well, tbh their UIs suck
<Burgundavia> g-a-i is much better
<Burgundavia> they expose too much of the underlying package crap to the user
<Amaranth> Burgundavia: But not much better and packagekit is only 6 week sold
<Burgundavia> but that is something Fedora has always done
<Amaranth> Burgundavia: So imagine what another couple months will do
<Burgundavia> sadly, I consider that a spurious argument
<Burgundavia> they had all the time to study every updater in existance
<Burgundavia> and every pacakge installer
<Burgundavia> and they still made the same mistakes
<Amaranth> Well, the main problem is gnome-app-install uses a hack to do what it does
<Burgundavia> I don't disagre
<Burgundavia> but the UI is better than anything out there
<Amaranth> it snags every .desktop from the entire archive and matches it to a package
<Amaranth> that could be put in packagekit though
<Burgundavia> without better package metadata, that problem is not going away
<Burgundavia> package kit will not solve that
<Burgundavia> having packagekit provide package metadata is pretty much the same thing as package information itself
<Burgundavia> packagekit should understand how to get that out of the distro, but it is the distro who needs how to figure out how to feed that to packagekit
<Amaranth> I'm not understanding your problem with that
<Burgundavia> packagekit, if it is to be adopted, needs to be a shim over existing packaging systems
<Burgundavia> if it starts replacing bits of the packaging system too early, adoption will fail
<Mithrandir> I must confess as to not understanding what problem PK is trying to solve
<Burgundavia> one of those bits is package metadata
<highvoltage> Burgundavia: read about the AppArmour layoffs?
<Burgundavia> one problem would be to have a third party app be able to say "install java" and it just work on Fedora, Ubuntu, etc.
<Burgundavia> highvoltage: yep
<Burgundavia> the other is for bigger projects like OO.o or GNOME be able to say "install this optional dep"
<Burgundavia> you already see this with gnome-games
<Burgundavia> try enabling 3d mode in chess and see what happens
<Burgundavia> a 3rd major point is to move the idea of package stuff out of the distro silo
<liw> I suspect that moving stuff out from distros will mean stuff won't be adhering to distro policies, meaning worse integration and interesting bugs during transitions, and longer transitions
<Burgundavia> you are conflating the actual packaging with the UI bits that sit above them
<Burgundavia> packagekit is designed to solve the latter, autopackage the former
<mdke> liw: right. A good example is that the packagekit guys have recently been discussing questions about how easy it should be to add third party repositories which may endanger the system. Ubuntu developers have also been discussing the same thing, if they come to a different conclusion, how will the two be reconciled?
<Amaranth> It's more or less so every distro can do what we do with 'find a package that handles this mimetype'
<Amaranth> and cross-distro consistency with the updater UI and such
<Burgundavia> because every distro rewriting the updater is crazy
<Burgundavia> iven they all do 98% of the same thing
<Amaranth> and if it gets to the level of gnome-app-install it's also so every distro has the same UI for installing applications
<Amaranth> GUI applications, anyway
<Amaranth> it's more or less everything we already do but with a better design and cross-distro
<Burgundavia> means gnome-app-install can actually become a GNOME app
<dholbach> the problem we have is that packages ask questions, that's not possible with packagekit in any way
<Burgundavia> indeed, a serious issue
<Burgundavia> the whole EULA thing is a bit messy as well
<liw> Burgundavia, hmm... if PackageKit helps move things out of the "distro silo", how does this not move things out of the control of the distro?
<Burgundavia> liw: because the packaging itself and all those bits remain with teh distro
<Burgundavia> PackageKit is mostly for the end-user facing apps
<Burgundavia> ie: the updater and the equiv of gnome-app-install
<Burgundavia> both of which could easily be on any LInux system, even a source based oen such as emerge
<Amaranth> dholbach: Is dpkg the only package system that does that?
<liw> Burgundavia, how does the packaging remain with the distro if the packages do not come from the distro?
<Mithrandir> Amaranth: rpm doesn't allow it, at least.
<Burgundavia> afaik, rpm devs have rejected the whole "rpm needs EULAs" stuff
<Burgundavia> liw: no, you misunderstand
<Amaranth> I only have basic understanding of rpm and don't know anything about conary
<mdke> dholbach: technical problems can often be solved though; whereas if there is a problem with the model; i.e. policy decisions which should be taken by distros being taken in the upstream project, then that's harder to fix...
<Burgundavia> this is a layer on top of the existing packaging system
<liw> Burgundavia, I understand the layering
<Amaranth> liw: This is gnome-app-install
<Burgundavia> and update-manager
<liw> I understand all that
<Amaranth> liw: gnome-app-install just tells apt to install stuff (through synaptic)
<Amaranth> liw: it doesn't do any packaging stuff
<stgraber> pitti: fixed
<Burgundavia> packagekit doesn't really how stuff gets installed
<liw> I am discussing specifically the point of "distro silo" and making it common to install packages from outside the distro
<Amaranth> liw: Why would this make it 'common to install packages from outside the distro'?
<Burgundavia> most users do that anyway
<Amaranth> liw: Any more than synaptic and gnome-app-install do
<pitti> stgraber: thanks
<liw> yes, many users do that, and yes, it's possible with existing tools, but it's not a "major point" for them to make it easy for users to install packages from any random sites from the net, which is what I understood from Burgundavia's statement is one of the goals of PackageKit
<Burgundavia> liw: umm, not really
<mdke> well, it's been discussed anyway
<Burgundavia> the goal is to smooth out installs of packages
<mdke> I don't know what the conclusions have been, they might be the same as Ubuntu's and they might not
<Burgundavia> a common place to discuss is the server stuff
<Burgundavia> such as IBM's db2
<Burgundavia> never going to be packaged for Ubuntu
<Burgundavia> but what if it needs a dependency/
<Burgundavia> ?
<pitti> stgraber: hm, ubuntu desktop is 16.1, although I added them as 16; alternates are 16.1, but don't show up
<Burgundavia> with PK, they could create it so that it could install those deps by writing a single script, and not dozens
<pitti> stgraber: I just tried to re-add 16 as desktop, but that doesn't seem to work?
<pitti> stgraber: ubuntu alternates added
<stgraber> pitti: ok, so I just have to change Ubuntu Desktop from 16.1 to 16 ?
<pitti> stgraber: right
<Mithrandir> Burgundavia: this is basically just LSB modules, again
<liw> Mithrandir, yeah
<Mithrandir> Burgundavia: also, DB2 is certified on Ubuntu.  I would not be surprised if you could get .debs of it too
<Burgundavia> yes, but unlike last time, this one might stick, as it is not parachuted in from above
<fabbione> Burgundavia: db2 is packaged for dapper...
<fabbione> Burgundavia: archive.canonical.com ?
<Mithrandir> it seems very much so to me.  I honestly don't see what problem it's trying to solve which isn't easier solved in other ways.
<Burgundavia> which other ways?
<Mithrandir> ship anything you need over LSB yourself.
<stgraber> pitti: looking at the logs, you added the 20071016 Ubuntu desktop at 08:33:32, then the 16.1 at 20071016.1. So it doesn't let you add the Desktop ones again as they already exist on the DB. I'll simply hide the Ubuntu desktop 20071016.1 and show the 20071016 so if we have a 20071016.1 for Ubuntu desktop today we won't have to add them again but simply reactivate them
<pitti> stgraber: hm, sorry if I screwed up; thanks for fixing
<Burgundavia> LSB is a very static solution
<stgraber> pitti: just ping me if you have to add a new Ubuntu Desktop set today (with version number 20071016.1) so I simply reactivate the 20071016.1 ones instead of creating them again
<pitti> stgraber: I will, thanks (let's hope it's not necessary, though :)
<stgraber> yes :)
<heno> *** Gutsy-final-candidates are up and ready for testing https://iso.qa.stgraber.org/ ***
<popey> ooo
<slangasek> Riddell, ogra1: are you guys planning separate release announcements for Edubuntu and Kubuntu?
<ogra1> slangasek, i have to talk to RichEd about that, Riddell usually does his own
<pitti> heno: btw, is https://wiki.ubuntu.com/Testing/Phased/Two ok for you? not sure how many bugs you want there, and some are a bit obscure, but I just added everything nontrivial
<liw> seb128, in #147071 you say the bug has been reported already, but it's not marked as a duplicate in launchpad, and I can't the other report
<heno> pitti: looks good. It will probably take some work to track down people who can test them, but that's fine
<heno> *** REQUEST FOR TESTING: Firefox candidate packages for Dapper, Edgy and Feisty are posted at: https://mozilla.qa.stgraber.org/ ***
<seb128> bug #147071
<ubotu> Launchpad bug 147071 in nautilus "When moving files to trash in Live session, nothing appears in trash" [Low,Invalid]  https://launchpad.net/bugs/147071
<seb128> liw: there is ten of bugs about trash applet not working correcly, maybe there is no exact duplicate of this one though
<sladen> possibly bug #34247
<ubotu> Launchpad bug 34247 in gnome-applets "Trash always empty." [Medium,Confirmed]  https://launchpad.net/bugs/34247
<sladen> sorry, bug #42471
<ubotu> Launchpad bug 42471 in casper "[Dapper LiveCD Beta2]  Deleted items are not visible in Trash" [Medium,Confirmed]  https://launchpad.net/bugs/42471
<seb128> liw: things like bug #32466 bug #72468 bug #12494
<ubotu> Launchpad bug 32466 in gnome-applets "External disk trash not shown by trash applet" [Medium,Confirmed]  https://launchpad.net/bugs/32466
<ubotu> Launchpad bug 72468 in gnome-applets "Trash looks empty, isn't" [Medium,Confirmed]  https://launchpad.net/bugs/72468
<ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
<liw> seb128, right, so there's lots of duplicates, good; I get it from the live cd, fwiw (the one currently being tested for release on Thursday)
<liw> in the live session, even
<sladen> it'll probably be something like  inotify not working with unionfs
<rohan> what package does kubuntu use to display OSD when i control volume using volume keys on keyboard ? because atm in gutsy the OSD is not working
<Whoopie> rohan: although using gnome, I guess, it's KMilo
<rohan> Whoopie: ah i see.. since atm it doesn't seem to be working
<rohan> i wonder whether it'd work for a new user though
<asac> ogra1: currenlty live session testing - move to trash appears to auto-delete the files ... e.g. nothing in trash afterwards. is that a feature for edubuntu?
<liw> asac, it's a bug, happens with the ubuntu live cd as well
<ogra1> asac, bug #32466 bug #72468 bug #12494
<ubotu> Launchpad bug 32466 in gnome-applets "External disk trash not shown by trash applet" [Medium,Confirmed]  https://launchpad.net/bugs/32466
<ubotu> Launchpad bug 72468 in gnome-applets "Trash looks empty, isn't" [Medium,Confirmed]  https://launchpad.net/bugs/72468
<ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
<ogra1> asac, see the backlog ;)
<liw> asac, the files are in ~/.Trash, the applet and nautilus just don't show them
<asac> liw: ogra1 thanks
<asac> ogra1: which bug should i attach to the test case?
<ogra1> heh, no idea, seb128 is there a master for the trash bug ?
<seb128> why does everybody notice that the trash is not working correclty now? that's the case this warty ;)
<ogra1> heh
<asac> seb128: maybe it was added to the iso testplan just now?
<seb128> ogra1: not really, pick any of the ton of gnome-applets bug about that
<seb128> asac: no idea
<ogra1> asac, ^^^^
<asac> ok i use bug 12494 then
<ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
<stgraber> seb128: the "move to trash" test was added to https://wiki.ubuntu.com/Testing/Cases/UbuntuDesktop in the Live session testing part :)
<seb128> stgraber: who did that?
<stgraber> Henrik probably
<asac> stgraber: i filed it now ... so maybe we should remove it temporarily to not trigger dupes :)
<seb128> stgraber: can that be reverted? there is no real sense to add things known to be b0rked there
<stgraber> seb128: I'll add a comment next to it so people know that it's not supposed to work
<seb128> stgraber: thanks
<TheMuso> c
<TheMuso> ugh
<stgraber> asac: Why did you mark Edubuntu's Live Session as failed ? only for the Trash applet thing ?
<soren> If anyone else used to use kees' greasemonkey script for adding karma and team emblems to lp pages, here's a patch that makes it work again after changes to edge's UI yesterday.  http://people.ubuntu.com/~soren/lp_karma_update.diff
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<tkamppeter> about bug 152293, are you sure that you have the 3ubuntu10?
<ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed]  https://launchpad.net/bugs/152293
<pitti> tkamppeter: I have whatever is on the current CDs, but that should be 10
<pitti> tkamppeter: I'm currently doing two more test installs (alternate this time); I'll check with those, too
<tkamppeter> pitti, so then it seems that the CUPS startup script exits and the daemon still takes an unreasonably long time to start listening. Then the cups-pdf package would need to launch a background process to wait for CUPS in a loop to create the queue, which can happen half an hour later, if needed.
<pitti> tkamppeter: it would be interesting to compare various installations; if it's a race condition, I might just have been unlucky
* soren -> lunch
<liw> arguably the cups startup script should wait until it's been started
<tkamppeter> pitti, the case that it happens seems to be rare at least, otherwise the problem had been reported earlier. I always got a queue (my network has 2 computers, 5 printers, and ~10 queues).
<pitti> tkamppeter: *nod*
<pitti> tkamppeter: I'm doing several vmware installs in parallel, so it's slow and latent
<tkamppeter> liw, years ago I had a similar problem and had reported an upstream bug then, which got actually fixed. Seems that now there are new discrepancies.
<tkamppeter> pitti, and I have only native installations ...
<asac> stgraber: i commented on it ... yes, just the trash.
<asac> stgraber: its not marked as serious of course
<tkamppeter> pitti, and there are two cases: "force-reload" probably does a "kill -something" on the CUPS daemon and "kill" does not wait for reactions, but "restart" actually kills CUPS and then runs "cupsd", and the command "cupsd" probably really only exits if CUPS really starts to listen.
<asac> ok bad news ... edubuntu install leaves me with a broken X ... ending in a console session :(
<pitti> eww
<tkamppeter> pitti, so a proposed fix could be to not call "/etc/init.d/cupsd force-reload", but this would go directly into the higher impact restart, which kills running print jobs ...
<asac> pitti: .. so here what i did: i did a live session and tried to enable desktop effects before install. live session downloaded nvidia driver ... now xorg.conf has nvidia driver, but nvidia glx is not installed
<tkamppeter> pitti, but is restarting of CUPS required at all? From CUPS 1.2 on (we are at 1.3 already) adding a backend and/or a PPD does not require restarting CUPS, why does this package restart CUPS at all ...?
<pitti> tkamppeter: don't ask me :) worth trying, I figure; if lpinfo -v picks up new backends without restart, that would be great
<asac> cjwatson: evand: what info do you need before i reboot (read a few lines above)
<tkamppeter> pitti, that is the case, replace the unconditional restarting by starting if it is not running and nuke the "sleep 3". Starting CUPS with "/ect/init.d/cupsys start" exits only when CUPS starts to listen (or when CUPS fails).
<cjwatson_> asac: all the installer logs
<tkamppeter> pitti, should we fix the cups-pdf issue before Gutsy? Or do an SRU? Or nothing?
<cjwatson_> asac: if you've rebooted into the installed system, everything in /var/log/installer/
<cjwatson_> sounds like a bug in the restricted-manager hook that's meant to install the packages it needs
<popey> is there a netinst gutsy iso kicking about?
<popey> oop, nvm, found it
<pitti> tkamppeter: at most an SRU, fixing it in gutsy itself is too late
<cjwatson_> asac: are you still in the live session or not?
<ogra> asac, thats -desktop, right ?
<cjwatson_> ogra: yes, he said "live session"
<ogra> just wanted to be sure
<asac> cjwatson_: no ... i have rebooted. live-sessino worked
<asac> ogra: yes ... livecd
<asac> cjwatson_: i can probably reproduce that if you want
<asac> cjwatson_: but let me first file the bug ... which package?
<cjwatson_> err
<cjwatson_> restricted-manager I think
<cjwatson_> though it could be ubiquity
<asac> hmm ... i will use both then :)
<cjwatson_> pitti: I note that the update_installed_packages function doesn't close the filehandle - relying on Python's garbage collection to do that for you in a timely fashion isn't reliable
<cjwatson_> Python code should generally do an explicit f.close()
<asac> cjwatson_: what info would you need from the live-session?
<cjwatson_> asac: /var/cache/restricted-manager/installed_packages would be good (you don't have to install to do that, just do the same stuff you did in r-m)
<pitti> cjwatson_: oh, ok; there goes another convenience...
<cjwatson_> don't know if that's the reason for this though
<tkamppeter> pitti, bug is now marked appropriately.
<pitti> cjwatson_: fixed this and some other instances in trunk, thank you
<pitti> I'm off IRC for about an hour to test-reinstall my workstation
<asac> cjwatson_: 153254
<pitti_live> hi jamiemcc
<jamiemcc> hi pitti_live
<pitti_live> seb128: hm, pidgin still has the bouncy input line by default :(
<cjwatson_> asac: I don't see /var/cache/restricted-manager/installed_packages there
<cjwatson_> Oct 16 10:07:12 ubuntu ubiquity: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.22/nvidia-glx_1.0.9639+2.6.22.4-14.9_i386.deb  Could not resolve 'archive.ubuntu.com'
<tkamppeter> pitti_live, added proposed fix to bug 152293, not doing the unneeded restart of CUPS.
<ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed]  https://launchpad.net/bugs/152293
<cjwatson_> asac: was this a networkless install?
<cjwatson_> hmm, apt-install perhaps needs to learn how to queue until after apt-setup
<asac_> cjwatson_: no the network worked through network manager ... the driver was successfully downloaded and insatlled during live-session
<cjwatson_> asac_: in addition to installed_packages, could I also have /var/lib/ubiquity/apt-installed?
<asac_> cjwatson_: from live session?
<cjwatson_> yes
<cjwatson_> both
<cjwatson_> I wonder if install_extras is just broken
<cjwatson_> oh, nvidia-glx* isn't on the Edubuntu CD
<cjwatson_> fixing this properly will probably have to wait for networkless-installation-fixes in hardy; any attempt to fix it now stands a good chance of breaking other things :-(
<asac_> cjwatson_: isn|t it non-free?
<cjwatson_> we have other restricted packages on our CDs
<cjwatson_> it's a real bug, but that code is horribly, horribly hairy and prone to breakage. I patched it up as best we could for gutsy
<asac> cjwatson_: well ... but ending up in a console because one tried to enable desktop effects is really a show stopper imo ... given that most nvidia cards are probably affected
<asac> cjwatson_: maybe we can prevent nvidia drivers to be installed during live session as a hack?
<pitti_live> asac: we could, but that would again require code changes
<pitti_live> I don't see how to do it with just CD mangling
<cjwatson_> I'm confused about how they got installed, given that we now don't even generate the nvidia modules in the live session
<cjwatson_> does Edubuntu have room to add nvidia-glx-new to the CD?
<pitti_live> cjwatson_: yes, if we kill one or two langpacks
<asac> cjwatson_: does ubuntu have that package?
<ogra> i think so, let me chack in detail
<cjwatson_> asac: yes
<cjwatson_> use rmadison
<pitti_live> IIRC I added it to amd64, too
<cjwatson_> rmadison -u ubuntu nvidia-glx-new
<ogra> daily has 7M spare
<asac> cjwatson_: ok then overall severity isnt that high most likely. i will try to reproduce it with ubuntu livecd though to be sure
<cjwatson_> nvidia-glx-new is 5MB
<ogra> daily-live is around 5
<cjwatson_> for the record, Ubuntu desktop CDs don't have nvidia-glx* either
<cjwatson_> nvidia-glx-new is in the ship seed
<cjwatson_> ogra: only the live CD matters here
<ogra> well, we dont have langs to drop there
<asac> cjwatson_: /var/lib/ubiquity/apt-installed doesnt exist in live session before install ... i will now reboot to the install i previously did and attach that file
<ogra> so it's a va banque game
<cjwatson_> I'm not confident about this fix; I'd prefer a release note
<cjwatson_> asac: odd, are you sure?
<amitk> ogra: see http://people.ubuntu.com/~amitk/edubuntu*.jpg
<asac> cjwatson_: let me reconfirm
<cjwatson_> apt-install should create it, and nothing deletes it
<cjwatson_> oh, no
<amitk> congrats
<asac> ubuntu@ubuntu:~$ ls /var/lib/ubiquity
<asac> ls: /var/lib/ubiquity: No such file or directory
<pitti_live> brb, booting into installed system
<ogra> amitk, !!! WOW !!!
<cjwatson_> asac: did you start ubiquity again?
<cjwatson_> it deletes that file on startup
<amitk> ogra: this is at a local (Finnish) electronic store
<asac> cjwatson_: no ... i just opened the appearence dialog and then installed the nvidia packages through r-m
<cjwatson_> asac: apt-installed won't exist until you've run through the installer
<cjwatson_> installed_packages exists beforehand
<ogra> amitk, thats extremely cool :D
<asac> cjwatson_: ok ... i already attached the restricted-manager installed_packages to the bug ... let me get the other from the real install
<cjwatson_> I don't need that
<cjwatson_> oh, I do need apt-installed :-)
<cjwatson_> ENOTENOUGHCOFFEE
<geser> Hi pitti
<asac> cjwatson_: unfortunately /var/lib/ubiquity doesn't exist :( ... maybe apt-get install nvidia-glx removed it?
<stgraber> Is rhythmbox supposed to trigger the automatic codec installation thing when trying to play or import a mp3 file ?
<stgraber> We have that in the Desktop testcase but it seems to only work with totem
<pitti> hi geser
<pitti> asac, cjwatson_: FWIW, in my fresh desktop installation, find /var -name ubiquity* is empty
<asac> stgraber: seb128 would know ^^^
<asac> pitti: ack
<cjwatson_> pitti: it won't be there after reboot.
<cjwatson_> asac: have you completed an installation yet?
<cjwatson_> asac: run r-m, run through ubiquity to the end, DO NOT REBOOT, grab file
<asac> cjwatson_: ok
<asac> redoing install then
<seb128> stgraber: no, easy codec installation has not been implemented for rhythmbox yet
<stgraber> seb128: ok, so I'll update the Desktop testcase for this one too :)
<seb128> graaa
<seb128> who made the testcase? would be a good idea to actually made them profread by somebody from the corresponding team
<stgraber> It probably was Henrik or Brian, I'll ping them when they show up
<seb128> stgraber: thanks
<ogra> hmm, why doesnt vbox like me today ?
<asac> cjwatson_: apt-installed attached .. anything else?
<cjwatson_> no, that's fine
<ScottK> Is there a core-dev with a few minutes to upload a source backport from Gutsy to Feisty?
<ScottK> The debdiff in Bug #151308 should be all that's needed to get the feisty-backports clamav up to date.
<ubotu> Launchpad bug 151308 in feisty-backports "please backport Clamav from Gutsy to Feisty " [Undecided,Confirmed]  https://launchpad.net/bugs/151308
<gnomefreak> ScottK: is clamav fixed in gutsy? someone yesterday got the post install script failure
<ScottK> gnomefreak: But #?
<ScottK> But/Bug
<gnomefreak> we had to remove it to continue upgrades but that is last i heard.
<gnomefreak> ScottK: i told him to file one but never got a bug number for it
<ScottK> gnomefreak: No bug was filed, so I know nothing about it.
<gnomefreak> ScottK: k if i see it again a bug will be reported before he gets help :)
<ScottK> We've had a lot of testing of the upgrades during the Gutsy cycle so I doubt it was a clamav specific problem.
<gnomefreak> using dpkg to remove it since it was never configured and wouldnt fixed it, i dont remember exacterror.
* ScottK will get interested when he sees a bug.
* asac -> lunch
<ogra> hmm
<lool> Against which package would I report a bug against the menu displayed when booting a CD (the very first menu)?
<ogra> doesn anyone else have probs with virtualbox ?
<lool> ogra: Depends which, I saw many :)
<ogra> i used to use the vbox version which worked fine until last week ...
<lool> I'm using it right now on an up-to-date gutsy
<ogra> since that crashed all the time today i thought i should switch to our packages
<ogra> but apparetnly that crashes too during booting the -desktop iso :/
<lool> It boots here; I'm using the i386 iso on an amd64 host
<ogra> well, nothing boots here for me
<liw> ogra, I had big problems with vbox yesterday, but since the machine in question also has big problems with its RAM, I don't know if the problems were due to vbox or not
<ogra> no matter which iso i try
* ogra tries again
<ogra> i get past the bouncing usplash ... then it hangs at some point during the initscripts ...
<ogra> pretty random
<sladen> ogra: I had somebody reporting that on their system, with usplash was taking 2minutes longer to boot than without;  if you leave it several minutes, does it recover
<ogra> no
<ogra> the vm just closes
<ogra> and the vbox console shows "interrupted"
<sladen> ogra: can you strace/gdb the vbox instance
<ogra> phew
<sladen> :)
<ogra> oh, wait
<ogra> i dropped the second NIC
<ogra> seems it boots now
<ogra> hmm
<ogra> thats weird
<sladen> so for 2 nics it doesn't give a dime, but nicking a nic gets you the booty?
* ogra tries to reproduce
<ogra> i have a second NIC configured as present but without cable
<ogra> to test -server with that
<ogra> oh, beautiful orange text on the shutdown usplash :)
* ogra enables the second NIC again
<sladen> orange.  it's the new brown
<ogra> doesnt it pick it from the theme ?
<lool> Nah, it's for Halloween
<ogra> its a bright orange here
<ogra> very nicely corresponding with the edubuntu logo
<ogra> ok, with second NIC it crashed again
<ogra> yeah, its reproducable ...
<pitti> dendrobates, soren: will you guys coordinate server testing?
<dendrobates> pitti: sure.
<Kmos> there isn't a milestone named feisty-updates on LP
<Hobbsee> no, there isnt.
<Hobbsee> there is not supposed to be.  use "nominate for release"
<Kmos> hmm.. and for bug triage? there is dapper-updates, edgy-updates and gutsy-updates
<Kmos> only feisty there isn't on the list
<cjwatson_> Kmos: yep, feisty-updates never got created. don't worry about it.
<Kmos> cjwatson_: ok :)
<cjwatson_> we only created gutsy-updates so that we had something to punt not-for-final-release bugs to in the release crunch
<cjwatson_> we didn't have a need for that in the feisty cycle
<Hobbsee> cjwatson_: when were you planning to add the hardy milestones, btw?
<Hobbsee> cjwatson_: and nominate for hardy?
<cjwatson_> Hobbsee: can't do it until gutsy is released
<Hobbsee> cjwatson_: why not?  soyuz limitation?
<Hobbsee> norsetto_limbo: ^
<cjwatson_> yep, or at least we don't want to risk it
<cjwatson_> it's part of the hardy bringup process: NewReleaseCycleProcess
<Hobbsee> i still think that launchpad blowing up might be fun to watch.
<Kmos> I see some e-mail about LP remove packages of old distros.. hoary, warty, breezy.. there is a date to clean it ?
<jdong> what is the proper procedure for helping someone with an upgrade breakage in a package?
<norsetto_limbo> Hobbsee: yes M'am?
<cjwatson_> Kmos: I believe the mail from Matthew Revell gives a schedule, but it doesn't matter to you unless you're a mirror admin
<jdong> I've got one guy reporting postinst subprocess failed with error 10 in tzdata....
<Hobbsee> norsetto_limbo: you asked about ^ before, iirc.
<cjwatson_> in fact not even then
<Hobbsee> jdong: see why it breaks, fix it, get it sponsored.
<cjwatson_> it matters very much for people who care about the central archive systems
<Hobbsee> assuming we're not frozen.
<norsetto> Hobbsee: hmmm, no, that wasn't me
<jdong> Hobbsee: ok, person ran off, I'll take a closer look if he pops back
<Kmos> jdong: It doesn't give an better error message?
<cjwatson_> jdong: error codes that are multiples of 10 from maintainer scripts usually need logs with DEBCONF_DEBUG=developer set in the environment
<jdong> Kmos: that's the only error it shows
<Kopfgeldjaeger> hi (amsg)
<jdong> cjwatson_: ok, thanks for the tip
<Hobbsee> cjwatson_: is there a list of what the dpkg error codes are, and what they all mean?  dpkg(1) doesnt show anything of interest.
<cjwatson_> Hobbsee: they aren't dpkg error codes.
<cjwatson_> as in, they're not things returned by dpkg itself. dpkg just passes them through. they could be anything, based on what the maintainer script does.
<Hobbsee> cjwatson_: yeah, that.  which would explain them not being in dpkg(1)
<cjwatson_> The debconf status codes are documented in /usr/share/doc/debian-policy/debconf_specification.html
<tkamppeter> pitti, how important is a thing like bug 153218 for updating from Feisty to Gutsy? The -doc is not on the CDs, but for updates via the internet it can perhaps be a problem.
<cjwatson_> but it's entirely possible for a maintainer script to return anything it likes. e.g. "exit 253"
<ubotu> Launchpad bug 153218 in ghostscript "install ghostscript-doc error" [Medium,Triaged]  https://launchpad.net/bugs/153218
<bddebian> Heya
<soren> I'm a bit unclear of the policies surrounding -backports. The wiki page ( https://wiki.ubuntu.com/BackportRequestProcess ) says that "In addition to syncs, members of [WWW]  ubuntu-core-dev are allowed to upload directly to -backports", but I'm not sure if that means that we can do so without asking the backport team's permission?
<jdong> soren: I'd trust a core-dev to make a wise decision in that regard, but it's recommended that you first talk to someone on the backports team
<soren> jdong: mkay.
<jazzanova> hi
<jazzanova> can someone explain to me this bug
<jazzanova> 732006 December B+ /home/liquidat
<jazzanova> sorry
<jazzanova> this one: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/74664/+activity
<ubotu> Launchpad bug 74664 in upstart "Boot parameters not passed to init scripts" [Low,Invalid] 
<jazzanova> what does this mean: "Rejecting the Ubuntu portion of this bug, since it's an upstream problem"
<cjwatson_> jazzanova: it means that the bug doesn't need to be tracked both in the upstream project and in Ubuntu; since Scott is the upstream maintainer as well as the Ubuntu maintainer, he made a decision to track it in just one place
<jazzanova> cjwatson: so it is not resolved then ?
<cjwatson_> no, it is not
<jazzanova> can I find this entry in the upstream log ?
<cjwatson_> what do you mean?
<jazzanova> can i find the place in which th ebug is tracked
<cjwatson_> you've got it right there
<cjwatson_> that bug has two tasks open on it; one for Ubuntu (closed), one for upstream (open)
<jazzanova> ok
<jazzanova> cjwatson: i need to fix this bug
<jazzanova> do you think its hard ?
<cjwatson_> dunno, I'll ask Scott to comment here when he gets back to his desk
<jazzanova> should I download 'upstart' source and mess with it ?
<jazzanova> if i install sysv-init, am I going to break everything ? i'm on feisty
<cjwatson_> if you install sysvinit you will probably break your system
<soren> jdong: So I'm actually allowed to do so, but I *ought* to talk to the backports team? That's sort of what I expected, too. I just wanted to get clarification.
<jazzanova> ok
<Vlet> Anyone know what the 'indent' args would be for Whitesmith formatting?
<Keybuk> jazzanova: it's not especially hard
<jazzanova> ok, im gonna give it a shot.
<Keybuk> init/process.c - process_setup_environment()
<jazzanova> right now
<Keybuk> you just need to find some way of copying environment there into the child
<Keybuk> and flagging that you want to do it
<mdomsch> apt doesn't seem to have a method to plug in additional modules at runtime, correct?
<pitti> tkamppeter: weird, I thought I fixed that with my last ghostscript update (build system fix to not ship doc stuff in ghostscript)
* mdomsch wants to add code to add more variable substitutions in (like $(ARCH)) in sources.list
<asac_educated> ogra: for desktop search test (https://wiki.ubuntu.com/Testing/Cases/EdubuntuDesktop) ... there is no Examples folder?
<ogra> no space for that
<ogra> edubuntu doesnt ship examples
<asac_educated> stgraber: ^^
<tkamppeter> pitti, have you checked the sizes of the packages produced by buildds?
<pitti> tkamppeter: no, not so far
<pitti> tkamppeter: they look fine
<freeflying> pitti: will you upgrade language-pack before release?
<pitti> freeflying: no, the CDs are pretty much final; we just got a fresh update over the weekend
<tkamppeter> pitti, perhaps there are still a few files remaining duplicate in both ghostscript and ghostscript-doc.
<pitti> tkamppeter: trying here; I have a fresh install
<pitti> tkamppeter: right, I get it, too
<freeflying> pitti: there have some errors in Chinese translation, also have some in other language
<pitti> tkamppeter: seems I removed *.htm and other bits, but not *.html
<stgraber> asac: thanks, I updated the testcase
<iwj> cjwatson_: Do you want me to collect any particular information for bug 153310 and bug 153311, before I wipe that install ?
<ubotu> Launchpad bug 153310 in oem-config "oem-prepare cannot cope if oem creates user (?)" [Undecided,New]  https://launchpad.net/bugs/153310
<ubotu> Launchpad bug 153311 in oem-config "poor error handling - lack of recovery" [Undecided,New]  https://launchpad.net/bugs/153311
<tkamppeter> pitti, can you fix that ghostscript problem then, either in Gutsy or in gutsy-updates?
<Lure> bryce: new ati test package works ok here, could you just give a package version that will not be upgrade by current gutsy version (e.g. 6.7.196~gitXXXX instead of6.7.195~git20071015)
<desrt> jono; fantastically true.
<desrt> (wrt: "a musician should never /ever/ see his guitar bounce")
<jono> desrt: :)
<jazzanova> grep the kernel version ?
<mdomsch> If I want an action to be run by apt or dpkg after all the packages in that transaction are installed
<mdomsch> I could use a trigger - but what other options exist?
<mdomsch> similar to the delayed ldconfig
<sladen> mdomsch: you may just have answered your own question.  Perhaps if you could elaborate a bit more
<mdomsch> sladen, sure
<StevenK> jono: Do you have a close-up of the damage? I'm most likely missing something in that photo
<mdomsch> I have packages A, B, C, and D being installed via apt-get install A B C D
<mdomsch> A, C, and D all have the same command to run, such as ldconfig
<jono> StevenK: the guitar on the right that is the same shape as the one next to it has its point missing on the end
<mdomsch> but I only want it run once, after all of A, B, C, and D are installed
<StevenK> jono: Ahhh
<mdomsch> so it's not a postinst in each
<sladen> StevenK: damage?  Jono crashed his new Ferrari /already/?
<StevenK> mdomsch: Then it's a trigger.
<jono> sladen: not this time :)
<StevenK> New Ferrari? What happened to the old one? :-P
<mdomsch> StevenK, yeah - that's what I figured.  I'm only avoiding triggers because they're pretty new
<mdomsch> and I was hoping the same trick could be used on older releases too
<StevenK> mdomsch: That also makes them shiny.
<Hobbsee> ooo...shiny
<jazzanova> i installed recompiled version of upstart, with minimal changes, ad now i can't reboot.
<jazzanova> is there a way to tell the kernel to reboot ?
<StevenK> jazzanova: sudo reboot -f
<StevenK> jazzanova: Make sure you run 'sudo sync' before that
<jazzanova> oops
<jazzanova> already did it
<jazzanova> thanks
<mdomsch> phooey - no fortune-firefly package :-(
<jazzanova> ok, i intorduced a crash to init
<jazzanova> is there a way to force kernel reboot, some control sequence ?-
<jazzanova> i have a crash in init.
<mjg59> alt+sysrq+b
<jazzanova> whats sysrq ?
<mjg59> The key that says sysrq
<jazzanova> thanks! wow
<jdong> mjg59: shouldn't one try to use the reisub sequence?
<Hobbsee> hiya mthaddon
<sladen> preferably with a  alt+sysrq+s  to sync and a  alt+sysrq+u  to unmount first
<jdong> well since init died, probably sub
<mthaddon> hiya Hobbsee
<jazzanova> sladen: great.
<cjwatson_> iwj: no, thanks, they're problems I've seen before
<psusi> iwj: do you see any advantage to this idea of packing a git repo directly into the source package, and if so, could you explain it to me, because it seems a colossal waste to me.
<sladen> perfect revision control.
<siretart> psusi: have you read the FAQ to that topic?
<psusi> didn't know there was one... just been following the thread on dpkg-list
<siretart> psusi: there are several very verbose and clear summaries in that particular thread in which cases it makes perfect sense to do that
<psusi> I see no advantage to placing the entire git repo into the source package over just having a git repo that people who want to use git can use, and source packages are then automatically generated from there
<siretart> and various pointers to the FAQ.
<siretart> I'd suggest rereading the thread on the dpkg-list
<psusi> ohh, that thing... yea, I read it
<psusi> I still see zero advantage
<psusi> it's a nice explanation of how it will work
<psusi> but I fail to see why it's a good idea
<psusi> I only see bad things... specifically that the size of source packages will be larger and they will be more complex to unpack
<siretart> do you really want me to dig out Ian's perfectly clear summary for this question?
<psusi> I'll go take another look at it, but I still see no real advantages listed...
<psusi> maybe I just don't understand them
<psusi> are you refering to Ian's comments starting with "This is a sensible question to ask.  Goals I would suggest:"?
<siretart> yes
<psusi> it seems to me that all of those goals can be done by linking the source archive to a vcs, not packing the entire vcs repository into the source package
<iwj> psusi: Yes, I definitely see an advantage.
<pitti> tkamppeter: gs> yes, I'll fix it in gutsy-updates
<iwj> Although I don't like the duplication of stuff.
<siretart> psusi: like in, say, the BSDs?
<psusi> siretart: dunno... I know almost nothing about bsd
<tkamppeter> pitti, OK.
<iwj> psusi: No, you can't do those things with just a link to the repo because people without commit access to the repo can't commit.
<siretart> psusi: see http://www.openbsd.org/cgi-bin/man.cgi?query=ports&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
<psusi> but look at the linux kernel... they use git to manage the source, and simply git-tar out the tagged releases into tarballs that just contain the source for that release
<tkamppeter> pitti, what about getting info into the Release Notes (see the e-mails where I CCed you
<psusi> they can't commit anyhow without upload access to the archive
<psusi> that's why they send in patches
<pitti> tkamppeter: it'll be done, thanks
<tkamppeter> ? Who is the right person for this?
<iwj> psusi: Part of the point is to get rid of all that palaver with patches.  They're a PITA.
<pitti> tkamppeter: slangasek
<siretart> psusi: are you arguing there was no need for the change, or are you arguing that approach was harmful?
<iwj> Plenty of people can upload without being able to commit.
<pitti> tkamppeter: you mailed him already, so that's fine
<psusi> iwj: I agree, getting rid of dpatch is a good thing... how is that not accomplished by simply throwing it out and using git, then exporting the working tree to source package?
<psusi> siretart: I am arguing that it seems to be a lot more complicated way to achieve that set of goals
<tkamppeter> pitti, OK, thanks. Informing the users is important in such a situation. Too bad that users start testing only after takeoff.
<psusi> iwj: you mean to like a public write only upload directory?  then just unpack that source tarball over a git checkout of the starting version, and commit to a new branch
<siretart> psusi: I have the impression you haven't had the chance to maintain large packages with extensive patchsets yet.
<tkamppeter> I have the fealing that I got more and more reports of important bugs the closer it came to release.
<psusi> iwj: can be automated and then the person who doesnt know about git doesn't have to have it or download the full repository to hack on the source
<pitti> tkamppeter: yeah, the old chicken-egg problem with testing :/
<psusi> if the goal is to get rid of dpatch to make it easier to extract the actual working source and tinker, why replace dpatch with git?
<iwj> psusi: How would you know what the "original version" was ?
<psusi> siretart: true... but I do track the kernel git tree regularly and have worked on a few packages in ubuntu that have a fair number of dpatches
<iwj> Sorry, you said "starting version".  That.
<psusi> iwj: because it's in the .changes
<psusi> and debian/changelog
<iwj> .changes is no good since the next person doesn't get it.  changelog might work.
<psusi> why would the next person need it?
<psusi> it's only needed by the ftpmaster to decide which version to check out and unpack this source package over
<iwj> Oh, you want the ftp scripts to do it.
<psusi> yea, the nmu can just get the current source tree, hack it it, upload it, and the ftp scripts can auto commit the changes to a new branch in the vcs
<iwj> I'm not wedded to the proposal from Joey.  If you'd like to sketch out your alternative proposal more fully I'm sure people would be happy to hear it.  I don't think I can do a detailed analysis of it here though.
<psusi> for someone with commit access to the master branch to review and merge
<psusi> hrm.... ok
<iwj> Note that your proposal seems to make the VCS repos much more tightly bound to the whole setup.  ATM they're kind of offstage.  That may not be a bad thing but it has political implications.  I think you should think it through and write it up.
<psusi> yea, because the ftp scripts will still have to pull from the git repo they upload anyhow
<psusi> ok
<psusi> ohh, so his proprosal would throw out the sideline vcs repositories
<psusi> and just keep a copy of the git repo in each versioned source package?
<iwj> Well, err, in some sense, yes.
<psusi> what a colossal duplicate of data... and of course, it also doesn't allow people to collaborte committing smaller patches between releases
<siretart> psusi: does your proposal include having the complete archive managed in git repositories?
<iwj> Not to say you can't have unofficial separate repos but they'd be more like unofficial separate branches.  They'd be in the same position as a current VCSless maintainer's random being-edited work-in-progress unpacked package.
<psusi> siretart: yea, if you like git, then I say just have a git repository that auto export/imports release branches to/from the source ftp archive, rather than pack the whole git repository into each source archive
<iwj> psusi: Also note that you shouldn't just say "git".  People get religious about this kind of thing, so if you want to talk in terms of git you should at least say "I'm going to talk about git but other VCSes should be supported" or something near the bottom to avoid getting sidetracked.
<siretart> psusi: I'm not sold to git at all. In fact, I'm still trying to get myself used to it, but I don't think I'll ever love it. It seems to me that your proposal is going to force every uploader to the archive to use git, which is a, errrm, unrealistic assumption
<psusi> iwj: well, not quite... if the maintainer decides to use the git repo, then maintainers of the package should be using the central git repo... that allows them to make and share incrimental patches between releases
<psusi> then when the maintainer decides it's time for release... he tags it and it's exported to the ftp archive
<psusi> yea, I'm talking git because 1) I'm familliar with it and 2) this patch being discussed talks about it heavily
<iwj> psusi: Yes.  That puts the whole group of them together in the position of a single VCSless maintainer, which is obviously good.
<psusi> siretart: it would be up to each package maintqainer which vcs they want to use
<cjwatson_> (in particular you don't need to be sold on git because I wrote a bzr backend for Joey's code.)
<iwj> I mean, that's why people do it :-).  But the question is how to make this more accessible to others.
<siretart> psusi: however, on the 2nd thought, it seems to me that your proposal could be useful for a potential (small) derivative distribution, which needs to track changes in debian.
<ringe> What's up with the missing ipw3945 drivers in newest Gutsy kernels?
<Hobbsee> ...they...arent?
<cjwatson_> psusi: FWIW, in Joey's proposal, source packages typically shrink, not grow.
<Hobbsee> ringe: do you have linux-u-m installed?
<cjwatson_> psusi: (though with bzr the result would be a little bit bigger than before, but not massively so. git's packing is a bit more efficient)
<ringe> Hobbsee: I have just installed from the Beta CD, then kept up to date with update-manager
<psusi> cjwatson_: I saw him claim that but I can not believe it... you can not ADD information to the package and have it come out smaller
<cjwatson_> psusi: you apparently believe that gzip compression is perfect
<ringe> Hobbsee: 2.6.22-12 works good, not 2.6.22-13 or -14
<cjwatson_> psusi: it's entirely sensible to believe that different encodings will come out differently
<psusi> cjwatson_: eh?  gzip is used either way...
<cjwatson_> psusi: in any case you don't have to believe or disbelieve. you can try it.
<psusi> in fact, source packages can use bzip2
<Hobbsee> ringe: okay, so do you have l-u-m installed for the later kernels?
<cjwatson_> or perhaps that is too much effort
<psusi> git can only use gzip afaik
<cjwatson_> source packages can't use bzip2 in the current format unless they use bzip2-in-tar-gz
<psusi> so I don't see how you can save space by switching to a less effective algorithm and adding more data
<psusi> huh?  the .deb can contain a .tar.bz2 instead of a .tar.gz
<cjwatson_> a .deb is not a source package.
<ringe> Hobbsee: No I didn't - why isn't that package upgraded?
<psusi> ohh, so only the binary packages can use bz2?
<cjwatson_> correct
<Hobbsee> oh, headdesk.
<psusi> ok... didn't know that... but git still also uses gzip, so same compression
<Hobbsee> is that why people are reporting problems/
<cjwatson_> psusi: is trying it so hard?
<tkamppeter> pitti, can you have a look at bug 152537? It seems that "sudo aa-complain cupsd" is reset on each boot. Is that the case?
<ubotu> Launchpad bug 152537 in cupsys "After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"" [High,Incomplete]  https://launchpad.net/bugs/152537
<pitti> tkamppeter: no, that's permanent
<psusi> cjwatson_: understanding is more enjoyable than accepting ;)
<linux4me> not sure I have the right channel but here goes, apparently I'm missing glib-devel and libnet-devel, how do I install this on feisty?
<siretart> psusi: it would help everyone if you would just try it and analyse how it works
<psusi> and I can tell you that my linux git repo is a good deal larger than a plain tarball
<ringe> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/134193
<ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed] 
<ringe> ubotu: yes, that's what I' talking about
<tkamppeter> pitti, the user tells he has to do "sudo aa-complain cupsd" after each reboot.
<rulus> linux4me: for support #ubuntu
<linux4me> rulus - tks
<ringe> Hobbsee: I'll reboot to see if that fixed the bug for my part
<Riddell> mertiki: is there a reason why the patch to bug 145709 shouldn't be a stable release update?
<ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 ~/.qt owner root and missing qtrc result result in ugly appearance" [Undecided,Fix committed]  https://launchpad.net/bugs/145709
<mathiaz> tkamppeter: aa-complain cupsd should be persistent between reboots.
<mertiki> Riddell : Yes
<cjwatson_> psusi: read Joey's post a bit more closely, please
<cjwatson_> psusi: "A sample dpkg source package built using this is temporarily here. This demo package includes only the last 200 commits to the dpkg git repo, so it's more than 1 mb smaller than dpkg's normal .tar.gz!"
<cjwatson_> note: not all the information
<Riddell> mertiki: what's the reson?
<mertiki> Riddell : The /etc/qt3 folder in Gutsy has very low permissions because it's not created by the installation of the libqt3-mt package. So if Gutsy is released with the /etc/qt3 folder with very low permissions, the libqt3-mt package won't install correctly same with my patch
<psusi> cjwatson_: yea, but how can adding the 200 commits to the current source code result in less data?
<mertiki> /etc/qt3 folder should be created by libqt3-mt, and the previous package before my patch didn't create it in Gutsy
<cjwatson_> psusi: again, you desperately need to read the post
<cjwatson_> your premise is false
<cjwatson_> http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/
<Riddell> mertiki: ok, but why can't it can be fixed in an update?
<mertiki> Riddell : Because each update in Gutsy would need to change the permissions of the /etc/qt3 folder in order to install correctly.
<psusi> is he not claiming that by switching the source package from containing a .tar.gz to a .git.tar.gz he saved space somehow?
<mertiki> Riddell : This would need additionnal works
<cjwatson_> psusi: your question is dealt with explicitly in his post
<cjwatson_> "Let a debian source package consist of just a .dsc and package_version.git.tar.gz, which contains only package/.git/*."
<mertiki> Riddell : In my point of view, things would be more logical if Gutsy was released with at least a /etc/qt3 folder with good permissions, this would avoid unnecessary work
<tkamppeter> mathiaz, thanks.
<cjwatson_> I don't understand this point about permissions of /etc/qt3. dpkg runs as root and permissions do not impede it
<psusi> cjwatson_: right... and he is saying that worked out smaller than the current package is he not?
<cjwatson_> psusi: "only package/.git/*"
<psusi> cjwatson_: aye... I am calling bs on that
<Hobbsee> did we not seed linux-image-generic in pre-gutsy or something?  or equivalent image?
<pitti> mertiki: since that new package needs to handle upgrades anyway, I don't see why doing it as an SRU isn't possible
<cjwatson_> psusi: this is science, not religion. it doesn't count unless you put in the effort to reproduce it.
<psusi> I just pulled the dmraid package into a git repo without any history... the size of just package/.git is significantly larger than the original source package
<mertiki> cjwatson : I'm not an expert, but the package won't create config files in /etc/qt3 with the actual folder permissions, but it will if the folder has normal root permissions
<psusi> oh wait, it idnd't pack it... hold on
<cjwatson_> Joey's code does explicit stuff to pack the repository better
<Hobbsee> ringe: did you upgrade from feisty, or clean install?
<cjwatson_> which is why I'm saying you should try it, not some random other experiment
<psusi> ok, better, but still larger, as expected
<ringe> Hobbsee: Clean install. The 2.6.22-14 l-u-m didn't fix the problem with missing ipw3945 drivers
<cjwatson_> and you can try the very thing he's talking about. Isn't open source great?
<ringe> Hobbsee: in fact, the audio drivers seems to be missing too
<Hobbsee> ringe: okay, the first half worries me.
<mertiki> pitti : Sorry what's the exact meaning of SRU ?
<Hobbsee> !sru | mertiki
<ubotu> mertiki: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
<mertiki> thanks
<pitti> mertiki: a stable release upgrade, i. e. post-release
<Hobbsee> ringe: is this -generic or -i386?
<ringe> Hobbsee: generic, see also comment 10 here: http://rubyurl.com/nZq
<pitti> Hobbsee: oh, can you teach uboty to not show MOTU/SRU any more? it's been merged
<Hobbsee> !no sru is <reply>  Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<ubotu> I'll remember that Hobbsee
<Hobbsee> !sru
<ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Hobbsee> good bot
<Hobbsee> pitti: as you wish :)
<mertiki> pitti : Ok, so if you all consider that this doesn't cause any problems, that's alright. I just wanted to explain you the problem. It's clear if the package is released as and update that further work will be required on this.
<ringe> Hobbsee: I am concerned since this bug is not given critical priority - it's a clear blocker
<Hobbsee> ringe: it's somewhat of a local problem
<pitti> mertiki: right, no argument on that (the current patch doesn't handle upgrades)
<cjwatson_> Hobbsee: linux-generic should've been seeded for some time
<pitti> mertiki: but AFAICS that additional work would be required even for an upload into gutsy proper
<pitti> mertiki: since a lot of people install beta or RC, or upgraded to it from Feisty
<ringe> Hobbsee: I don't see why a whole range of wireless enabled laptops without wireless support is "local"
<pitti> mertiki: and for an SRU we can take some time to get the upgrade right; as opposed to now, when we need to rush things and potentially make it worse
<Hobbsee> ringe: FYI, if my ipw3945 card wasnt working, i wouldnt be talking to you now. nor would a lot of other people on irc.
<cjwatson_> ringe: we know about the audio drivers - problem is that fixing them breaks other stuff, so instead, it'll be handled in linux-backports-modules
<mertiki> pitti : Ok good, so should everything is already specified in the bug report, should-I do something else around that or everything is Ok?
<Hobbsee> ringe: and that link you provided shows no mention of l-u-m being installed at all.
<pitti> mertiki: I didn't read it entirely yet, but I don't think it has a clear strategy how to fix upgrades?
<ringe> Hobbsee: I'm at ipw3945 myself, running 2.6.22-12 - and I just installed the l-u-m as you said without it fixing the missing files problem
<cjwatson_> you need to install the matching l-u-m
<pitti> mertiki: in particular, the package maintainer scripts must not touch anything in /home/
<Hobbsee> ringe: stupid question, but you used locate to check for the new files?
<cjwatson_> so linux-ubuntu-modules-2.6.22-12-generic
<pitti> mertiki: so that'd boil down to some code changes
<cjwatson_> which probably isn't in the archive any more; upgrade :-)
<Hobbsee> cjwatson_: why do so many people seem to be on linux-image-386?
<ringe> Hobbsee: sorry, I'm stupid - the files are there now. But why aren't they loaded with -14?
<mertiki> pitti : the patch has just one line, and changes a single file in the debian folder of the package which allows the package to create is config files in the /etc/qt3 folder. This is a fix based on the Feisty package which was Ok.
<cjwatson_> Hobbsee: perhaps because they have hardware that doesn't support -generic
<pitti> mertiki: right
<ringe> Hobbsee: and why aren't they automatically installed?
<pitti> mertiki: I'm talking about an upgrade path for people who already have the root-owned ~/.qt
<cjwatson_> ringe: they normally are ...
<Hobbsee> cjwatson_: seems like a higher proportion than expected, though, looking at userland
<Hobbsee> ringe: good question. see my last comment on the bug report
<cjwatson_> Hobbsee: there was also a base-installer bug that treated some old Via C3s as needing -386 when actually -generic is fine
<Hobbsee> did you have linux-image-generic installed?
<Hobbsee> This gets installed with the gutsy cds - is this an upgrade bug only?
<ringe> cjwatson_: I installed the BETA clean, and upgraded from there. What's not normal then?
<cjwatson_> ringe: I'd need to see the full installer logs to tell
<cjwatson_> ringe: /var/log/installer/*
<Hobbsee> cjwatson_: ah right.  -i386 definetly isnt doing the ubuntu modules at all.
<Hobbsee> cjwatson_: presumably this is intentional?
<cjwatson_> Package: linux-image-386
<Hobbsee> oh wait.  my bad.
<Hobbsee> i cant read
<cjwatson_> Depends: linux-image-2.6.22-14-386, linux-ubuntu-modules-2.6.22-14-386
<mertiki> pitti : Oh ok right, I'm surely not the good person to fix that but if a lot of people are using Ubuntu installed from Beta and Alpha, I think that you're right :)
<Hobbsee> cjwatson_: yeah, i suck.  i'm getting tired, i know
<ringe> Hobbsee: nope, the linux-image-generic isn't installed
<Hobbsee> ringe: then that's why.
<Hobbsee> ringe: why is it not installed?
<pitti> mertiki: thanks for pointing this out; it's on the radar now
<cjwatson_> ringe: installer logs should help tell me why
<ringe> Hobbsee: I agree, I was going to ask you the same.
<mertiki> Riddell : Thanks, please tell me if I can do something else around that and thanks again for your work on this
<ringe> cjwatson_: I'll post them to that bug
<cjwatson_> thanks
<mertiki> pitti : Ok right, thanks too
<Riddell> mertiki: no need to thank me, I'm the one who somehow failed to upload it in time
<Adri2000> release team: can I already upload to gutsy-proposed?
<mertiki> Riddell : Haha, don't botter, I'm also the one who found the problem at the last minute
<pitti> Adri2000: yes, it will just sit there for some days, thuogh
<cjwatson_> Adri2000: you can upload, but nothing will be done with it until we release
<Adri2000> ok
<iwj> cjwatson_: Opinion on bug 153336 ?
<ubotu> Launchpad bug 153336 in oem-config "oem-config sudden exit" [Undecided,New]  https://launchpad.net/bugs/153336
<ringe> cjwatson_: installer logs posted to bug 134193: http://rubyurl.com/BAy
<ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
<cjwatson_> iwj: hmm, agreed but it seems cosmetic (if nasty)
<iwj> Right.
<iwj> I just thought I'd mention it since if you thought there was a confirmation screen it might actually be a crash.
<cjwatson_> last week I'd have had no hesitation in fixing it
<iwj> Sorry I didn't spot it then :-).
<cjwatson_> no, there's no confirmation screen (perhaps unfortunately)
<iwj> Fair enough.
<cjwatson_> if it created the user then it's succeeded
<cjwatson_> if it crashes, the failure mode is so unutterably horrible that you'd know :-)
<cjwatson_> one thing oem-config doesn't do is crash quietly.
<Hobbsee> ringe: btw - all the problems in that bug will be fixed with installing the corresponding l-u-m for the kernel that they're on..
<ringe> Hobbsee: I installed it and tried a reboot but the network wasn't loaded. I'll try again now, though. I just installed linux-image-generic
<Hobbsee> ringe: if everyone installed linux-image-{generic, whichever flavour they're using}, this would be solved for them, forever.
<ringe> Hobbsee: I just filed that as bug 153345
<ubotu> Launchpad bug 153345 in update-manager "update-manager should check for linux-image-* metapackage" [Undecided,New]  https://launchpad.net/bugs/153345
<Hobbsee> ringe: i thought you said this was a fresh gutsy install
<ringe> since, as I said - I did a regular install with the BETA cd
<ringe> Hobbsee: it is
<ringe> Hobbsee: The computer is brand new - came with Vista (which I fight Packard Bell to give me money back for)
<Hobbsee> in which case, what's update-manager got to do with it?
<mvo> ringe: update-manager will ensure this in release upgrade mode, but not in regular update mode (as in the regular update mode this situation can only occur if a) a devel release is used b) non-standard sources are used c) the user decided to go without -generic (or -386 etc)
<ringe> Hobbsee: Nothing much. I just figured update-manager would do users a favor if checking for the linux-image package
<ringe> mvo: hmm. There are two questions: why did the missing linux-image become missing in the first place, then what should update-manager do about it if it occurs?
<ringe> I don't know the answer to the first question, since this simply is a fresh install. The answer to the second is that bug I just filed.
<cjwatson_> ringe: not seeing anything in that log about why it wasn't installed, but I suspect it must have been a transient problem with that particular CD image
<cjwatson_> daily builds can be like that sometimes
* Hobbsee thinks update manager should check for a whole lot of stuff, so users cant do stupid things.
<cjwatson_> ringe: no, you didn't install with the beta CD, or at least that's not what your logs say
<cjwatson_> 'Ubuntu 7.10 _Gutsy Gibbon_ - Alpha i386 (20070823.5)'
<cjwatson_> that's over a month before beta
<mvo> ringe: the question why it went missing might be answered with /var/log/apt/term.log. what it should do? IMO it should do nothing because it can't tell if the user did not decided against this kernel for some reason.this is a different matter for feisty->gutsy upgrades, here it should (and will) ensure that linux-image-$flavor is installed (unless the user uses a self compiled kernel)
<cjwatson_> it looks like you actually used Tribe 5
<ringe> Hobbsee: I think we must be careful not to make update-manager become windows update with the trust problem
<ringe> cjwatson_: Hmm, you're right.
<cjwatson_> the livefs log for Tribe 5 shows that linux-ubuntu-modules was installed
<cjwatson_> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070823.4/livecd-20070823.4-i386.out
<cjwatson_> (note: livefs build numbers don't always correspond exactly to CD build numbers)
<ringe> cjwatson_: so any update after that removed it then?
<cjwatson_> I guess it must have done; the installer didn't
<ringe> Well, at least that'
<cjwatson_> it logs the packages it removes, and it didn't mention that
<ringe> good, then
<mvo> ringe: /var/log/dist-upgrade/apt.log may also give a clue
<ringe> Hmm, may the problem have appeared because of mirror sync while upgrading?
<ringe> mvo: find it attached to bug 134193
<ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
* ringe be right back
<LaserJock> grrr, /me kicks firefox
<ringe> cjwatson_: I've added a few logs to show the difference when loading 2.6.22-12 and -14 to bug 134193
<ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
<ogra> LaserJock, careful, it might kick back
<LaserJock> ogra: it started it
<LaserJock> it just keeps locking up with 100% CPU
<ogra> evil thing
<cjwatson_> ringe: I stopped being interested when it didn't seem to be an installer problem any more :-)
<cjwatson_> ringe: (not to be abrupt but I'm having to be pretty focused)
<agoliveira> Hmmm... Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) here and it's working fine with 2.6.22-14-generic
<ringe> cjwatson_: No offense taken. :) Who'd be interested?
<agoliveira> Not the same notebook tough...
<ringe> agoliveira: It works perfect with 2.6.22-12-generic
<agoliveira> ringe: I didn't have any problems that I recall for quite some time and I'm using -14
<cjwatson_> ringe: dunno, #ubuntu-kernel maybe?
<psusi> looks like I found my culprit... it appears that joey removed 8 mb of files from the source tree before packing it into git... that's why it's slightly smaller
<stgraber> ringe: same here too and didn't have any problem with the driver (-12, -13, -14 and previous ones). But I know, the "work for me" isn't of any help ... :)
<ringe> According to the latest logs I put there, the modules are there but they just don't load.
<ringe> cjwatson_: depmod -a fixed the problems for me :)
* Starting logfile irclogs/ubuntu-devel.log
<Riddell> calc: could you do a SRU for 153132?
<Riddell> bug 153132
<ubotu> Launchpad bug 153132 in openoffice.org "Openoffice splash screen includes Ubuntu logo" [Undecided,Confirmed]  https://launchpad.net/bugs/153132
<tkamppeter> slangasek, sorry, did not know that there is a Wiki place to collect the release note entries, I only saw one of your answeres to the bugs I am dealing with where you wrote that you will add the issue to the Release Notes. Where is this Wiki page?
<cjwatson_> tkamppeter: http://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
<tkamppeter> cjwatson, slangasek, thanks.
<YokoZa1> What's the difference between fix-committed and fix-released in Launchpad?  I'm trying to figure out how to tag some bugs of mine that are solved.
<tkamppeter> cjwatson, slangasek, is there a special order in the file? If I add something, where should I add it (the file can get very busy until Thursday)?
<slangasek> YokoZa1: https://help.launchpad.net/BugStatuses
<thully> ogra: ping?
<ogra> thully, ?
<calc> Riddell: huh? still reading the bug, i am confused as to what bug this is
<thully> yes, I have a g-p-m bug that I've been trying to get someone to look at
<thully> I have a patch for it - but I don't know if my patch is perfect...
<calc> Riddell: oh i see after reading the report :)
<ogra> thully, a bit late for the release though, whats the bug # ?
<ScottK> YokoZa1: Generally "Fix Committed" means a fix is uploaded somewhere (could be just in a VCS, not in a release yet), but there's a fix somewhere that will eventually arrive in a development version of Ubuntu.
<thully> bug # 137598
<thully> #137598
<ogra> bug #137598
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
<ScottK> YokoZa1: Fix Released means it's uploaded to an Ubuntu repository (modulo time for the buildd's to build it and the mirrors to mirror it) and available.
<calc> Riddell: would a SRU to just fix the branding bmp even be accepted, it doesn't seem clear it would from the SRU wiki page..
<thully> to reproduce it, tune your brightness manually below maximum and wait (on AC, with default g-p-m settings)
<thully> the "adjust brightness" function is apparently called on idle regardless of "dim on idle" setting - and with that off, it uses the default brightness (maximum) as the "dim" setting
<thully> My patch basically stops the "adjust brightness" function from being called when dim_on_ac (or dim_on_batt if on battery) is turned off
<Riddell> calc: I'd accept it :)
<thully> ogra: are you seeing the issue on your end?
<ogra> i never noticed it, no ...
<thully> but have you tried?  granted, many may not notice if they don't change their brightness to below maximum on idle
<thully> on AC, I mean
* Starting logfile irclogs/ubuntu-devel.log
<thully> ogra: hmm, don't know what's going on. I do know some others are seeng this issue (look in the bug report)
<evand> slangasek: uh, sure.  Didn't we basically already do that for RC or are you talking about something else?
<thully> ogra: are you on a desktop or laptop?  If you're on a desktop, that may explain why you aren't seeing it...
<ogra> thully, i'm on a laptop
<ogra> but it means nothing if i dont see your prob :)
<ogra> my lappie us usually fine with all powermanagement stuff
<thully> ogra: OK - and you were idle (i.e. there wasn't some heavy background activity going on)
<ogra> no, DPMS kicks in at soe point
<thully> what do you mean?  I'm a bit confused...
<ogra> well, on idle my screen gets blanked by DPMS from g-p-m
<ogra> my display doesnt dim or anything
<cjwatson_> evand: it does need a final announce, even if it's mostly the same :-)
* cjwatson_ heads off home
<ogra> and returning from teh black DPMS screen gets me back to the same brightness level
<evand> cjwatson_: gotcha
<thully> Oh - one question - did you adjust your display to minimum while you were idle, and make sure you were on AC?  If not, you won't see the issue
<ogra> not to minimum  ...
<ogra> but pretty low
<thully> OK
<ogra> oh, its actually minimum
<thully> brightness is handled by g-p-m for you, right - not by hardware?
<thully> (i.e. you see a g-p-m display when you use the brightness keys, and not a hardware-specific display)
<slangasek> evand: I'm told that Gobuntu should have a separate email announcement for ubuntu-announce, because it's separate in many respects
<evand> ok
<ogra> thully, no idea really (and i'm quite busy with final iso testing atm) it doesnt really matter as i said, lets see that we get a test package into -proposed and put it into an SRU for g-p-m
<thully> OK
<ogra> if it fixes the issue for all others in a testpackage we can pull it in ... but we need some feedback
<thully> One question - are the daily builds out now = Gutsy final barring a catastrophe?
<slangasek> tkamppeter: I'm not sure it's a good idea to tell folks in the release notes "if you run into any printing problems, try to deactivate AppArmor for cups", I think that leads folks to not bother reporting bugs we don't know about...
<ogra> thully, depends on the bugs we find
<thully> OK - I may try a fresh install to see if they changed some settings to resolve the issue - my current install if from the beta ISO (updated , of course). That is possible..
<YokoZa1> ScottK: So what does fix committed mean then?
<rulus> I would think Fix commited means that the fix is included in upstream's code but not packaged into Ubuntu yet
<slangasek> not necessarily upstream.
<ScottK> It's landed somewhere visible.  It doesn't seem to matter much where.
<slangasek> tkamppeter: can you give me more detail on why your explanation for bug #152537 says "many third-party drivers"? the bug in question only mentions a single backend
<ubotu> Launchpad bug 152537 in cupsys "After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"" [High,Incomplete]  https://launchpad.net/bugs/152537
<slangasek> tkamppeter: i.e., I'd really prefer not to list a number of particular printer manufacturers here without being able to justify their inclusion
<hunger> Will apparmor actually get used in gutsy?
<hunger> So far I only saw some settings for cups, nothing else.
<Seveas> hunger, so it will be used for cups :)
<hunger> Seveas: I was hoping for a bit more coverage:-) Well, I can always roll my own stuff.
<ajmitch> it does cover a lot more than just cups
<hunger> The rulesset generator script seems to try to upload to opensuse. Will that get changed in time for gutsy?
<hunger> ajmitch: Not in my *ubuntu-desktop install.
<ajmitch> hunger: how are you measuring the coverage?
<hunger> ajmitch: aa-status reports two installed profiles.
* ajmitch doesn't have a current matching kernel/userland, but apparmor-profiles does include a bit more than that, afaik it should get used
<tkamppeter> slangasek, I will remove the names.
<hunger> ajmitch: it does, but it is not installed here. Doesn't seem to be part of any -desktop.
<Seveas> ajmitch, http://paste.ubuntu-nl.org/40859/
<slangasek> tkamppeter: I'm fine with listing names if I can understand why these particular names are listed :)
<Seveas> that's a default gutsy
<ajmitch> that's probably the problem with me never running a default install :)
<mathiaz> hunger: apparmor-profiles is in universe, so it'S not installed by default.
<hunger> ajmitch: Plus the aa-profiles are somewhat opensuse specific. Most of the stuff I looked at won't work too well on ubuntu.
<ajmitch> right, I should have checked that
<ajmitch> apparmor probably wouldn't run properly on my laptop anyway since I load an selinux policy at boot
<hunger> ajmitch: You must be pretty clever... I never managed to do that properly.
<ajmitch> it didn't take clever, just an initramfs hook
<tkamppeter> slangasek, pitti, all release notes from my side are added now (more can come if there are more users reporting bugs too late).
<twb> When booting Etch, url=foo will result in an attempt to fetch the preseed file http://foo/d-i/etch/preseed.cfg.  If I just specify url=foo on Ubuntu Feisty/Gutsy, what is the full URL it uses?
<slangasek> tkamppeter: thanks, looks pretty good
<twb> I can't find the analog of Debian's explanation in https://help.ubuntu.com/7.04/installation-guide/amd64/appendix-preseed.html
<evand> twb: I could be wrong, but our d-i doesn't use auto-install (yet?).
<evand> twb: cjwatson would be the person to get a definitive answer on that from, but he's away, possibly for the evening.
<twb> Wouldn't that mean your d-i is even older than Etch?
<evand> no
<twb> I'm confused as to what you mean by `auto-install', then.
<evand> auto-install is a d-i component that does what you're describing above.
<twb> You mean support a default path and protocol?
<twb> Because the preseeding itself is quite plainly documented at the above URL, using url=http://foo/bar/preseed.cfg
<evand> twb: right, and you can specify a preseed location using url=, but you cannot set url=foo and expect it to produce url=http://foo/d-i/gutsy/preseed.cfg or something similar, as I understand it.
<twb> OK.
<evand> twb: I'd suggest filing a bug on debian-installer in LP.
<twb> It's not worth the effort.
<twb> Actually what I'd really like is to be able to preseed via TFTP, rather than having to run an httpd just for the preseed file
<oever> hi, in gutsy, libestraier-dev should depend on libqdbm-dev
<oever> because /usr/include/estraier/estraier.h requires depot.h
<twb> oever: bugs.debian.org/441844
<oever> twb: ah great, thanks
<tbf> seb128: you probably want to apply that patch to gnome-vfs: http://bugzilla.gnome.org/show_bug.cgi?id=487227
<ubotu> Gnome bug 487227 in Async operations "Epiphany randomly crashes and freezes on startup" [Normal,New] 
<seb128> tbf: I've subscribed to the bug and will have a look, thanks for pointing it
<tbf> seb128: i am just selfish ;-)
<Kopfgeldjaeger> n8
<slangasek> tkamppeter: I've adjusted the language in the ReleaseNotes about the PDF printing issue (shorten the description, don't give users multiple options for fixing the problem); I'd appreciate your review of the change
<slangasek> tkamppeter: um, I specifically didn't use System -> Administration -> Printing though, because AFAIK that's not present under Kubuntu?
<tkamppeter> slangasek, I have changed your text again, selcting only one printer setup tool for describing a way to fix the problem of the missing PDF printer I selected system-config-printer due to the fact that the web interface will ask for login and password after setting up the queue.
<slangasek> it will?
<pitti> slangasek: (NB that system-config-printer is not for KDE and not installed by default on Kubuntu)
<slangasek> pitti: yes, that's precisely my point
<tkamppeter> slangasek, and even worse, if you start it with http://... and not with https://... it will autoswitch to https://... in the end of the add printer wizard forgetting all enterd data, throughing the user back to the start page.
<pitti> ah, right, it's for cups-pdf
<slangasek> tkamppeter: well the release notes didn't say http://, they said https://
<tkamppeter> slanagsek, sorry, then one of the quirks I already worked around in my original text, but there is still the password issue.
<slangasek> ok
<tkamppeter> slangasek, pitti, is cups-pdf also installed/available in Kubuntu or any other Ubuntu flavor which does not ship system-config-printer?
<slangasek> yes, cups-pdf is a recommends of kubuntu-desktop
<pitti> tkamppeter: it's not enough to apt-get install --reinstall cups-pdf, or so?
<slangasek> all the other desktop tasks use system-config-printer though
<tkamppeter> pitti, by repeatedly doing this you can get lucky that CUPS will pick up once, but also not ...
<pitti> tkamppeter: also, we'll fix it in an SRU very early; I don't think that this is a real frontline feature that a lot of people will immediately miss
<slangasek> pitti: would you prefer not to release-note it?
<tkamppeter> So this means in the release notes you cannot give workarounds to users based on GUI tools, as Kubuntu has a completely different set of GUI tools?
<slangasek> no, it just means we should be aware of this when picking workarounds to document
<pitti> slangasek: I'd say it depends on the number of caveats that are on the page; it shouldn't be more than a handful
<tkamppeter> So I suggest to perhaps have to release note files, one for Kubuntu, another for the rest
<slangasek> pitti: we already have quite a few
<pitti> tkamppeter: no, that's fine, since Kubuntu has its own web page (including caveats)
<pitti> slangasek: we probably have hundreds of caveats at this level :)
<slangasek> pitti: "its own web page" including the release notes?
<pitti> slangasek: well, I mean the "Caveats" section of the announcement page; you mean something else?
<slangasek> pitti: this is the release notes that I'm talking about
<pitti> ah, https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes ?
<slangasek> yes
<tkamppeter> Does Kubuntu have a menu entry System -> Administration -> Printing? As I did not say "system-config-printer" in my text it will perhaps fit.
<pitti> Riddell: ^
<Riddell> no, k-menu -> System Settings -> Printers
<Riddell> although I don't know if you can install the CUPS pdf device from that (KDE has its own built in one of course)
<pitti> tkamppeter: wouldn't help you much anyway, I figure, since the workflow within the printer tool is completely different
<tkamppeter> Riddell, if the KDE Printing manager shows all entries of "lpinfo -v" it will be able to set up the PDF printer, especially because cups-pdf ships the PPD ready-made and not a PPD generator.
<tkamppeter> Does Kubuntu exclusively ship KDE apps, all having the KDE printing dialog with built-in PDF (so no Firefox, Thunderbird, ...)? In this case one could remove cups-pdf from Kubuntu.
<Riddell> it does (plus openoffice which won't need it), but people also install firefox and thunderbird
<Riddell> not that I'm too fussed if the release notes don't have a KDE fix, as you say it's KDE's fault for being behind on printing
<slangasek> "remove cups-pdf from Kubuntu" -> out of scope, we're discussing issues to be documented, not changes to the OS
<tkamppeter> slangasek, I hope app developers (esp. Firefox/thunderbird) will allow us to do away with cups-pdf in all our flavors in Hardy or at least Hardy+1.
<tkamppeter> Riddell, WDYT, should we describe both the GNOME and the KDE way to set up a PDF printer in the release notes, or should we have separate release notes for KDE (in that ones one can also drop the two points about users-admin).
<pitti> well, IMHO the release notes are full enough already; it's just a race condition of a relatively minor feature which is a perfect SRU candidate, so I wouldn't worry about it too much; just my 2, of course
<pitti> and it only happens on really slow machines
<pitti> my 'two vmware installs and a CD burn in parallel' use case isn't really typical, I'd hope
<pitti> tkamppeter: and I doubt that it affects desktop installs in the first place
<pitti> (just alternate)
<slangasek> why would that be?
<slangasek> I mean, I tend to agree with you that we can probably do without documenting this one
<slangasek> but I don't see why it would be specific to alternates
<tkamppeter> pitti, so my "sleep 3" will probably help in 99% of the cases.
<pitti> well, the PDF queue shuold be created at livefs build time, not when the user installs the system with ubiquity, or am I totally wrong here?
<Riddell> tkamppeter: since I don't know of any GUI workaround in KDE, I would just leave it out
<slangasek> pitti: oh, perhaps it would at that
<tkamppeter> pitti, are print queues from livefs transferred to the ubiquity-installed system on the hard disk?
<tkamppeter> Riddell, you mean points as users-admin points, so that the release notes are fine for you becuase there are no KDE issues worth to document?
<pitti> so merely testing if it is present on the current live CDs ought to be sufficient?
<pitti> s/live/desktop/
<pitti> .. in the live systems
<pitti> tkamppeter: not the ones you create *in* the live system
<pitti> tkamppeter: but AFAICS the default printers.conf from livefs build time shuold be copied?
<pitti> tkamppeter: when we do an ubiquity install, that doesn't run any postinsts
<pitti> that's all done in the livefs build
<tkamppeter> pitti, then you should run a certain amount of the same live CD build and check whether every build has a PDF queue, as otherwise we are either lucky and 100% of our users have a PDF queue or no one (for each flavor).
<Riddell> tkamppeter: the users-admin release note is slightly different, there it is the gnome tool which is broken but the KDE tool is fine so no need to mention KDE, with cups-pdf I don't see a workaround for KDE so I'd just leave out any mention of KDE since there's not much a user can do
<pitti> currently booting i386 and amd64 desktops
<tkamppeter> Riddell, OK. GNOME is better with printer setup and KDE is better with user/group management currently ...
<Riddell> :)
<pitti> tkamppeter, slangasek: hm, neither i386 nor amd64 lives have the PDF queue
<slangasek> in the images?
<tkamppeter> pitti, can it be that the installation of the CD building progress is much slower than an alternative CD installation (or even the single-package installation which I did)?
<pitti> Setting up cups-pdf (2.4.6-3ubuntu10) ...
<pitti> is all the log says
<pitti> there's no debugging info or error reporting
<pitti> tkamppeter: very well possible that cupsd does not even start
<slangasek> heh
<pitti> the livefs build machinery might have a daemon-suppressing policy-rc.d, I don't know
<elmo> it doesn't, AFAIK and FWIW but IANARBA
<slangasek> you are not a red-bearded albatross?
<pitti> slangasek, tkamppeter: a mere "sudo dpkg-reconfigure cups-pdf" DTRT here, thoug
<pitti> h
<tkamppeter_> pitti (and anyone else), can you repost your answers on my last three messages? There was a short interruption.
<pitti> done in /query
<tkamppeter_> Thanks pitti, seems that not all of my messages arrived, I will repeat them.
<tkamppeter_> pitti, the postinst script of cups-pdf restarts CUPS and this should at least say something like "restarting CUPS". Can it be that in an initial installation where all packages get installed at once, cups-pdf is installed before CUPS?
<tkamppeter_> cups-pdf depends on cupsys, does this not mean that the cupsys installation has to be completed before the cups-pdf installation starts?
<tkamppeter_> And what does the "Pre-Depends: cupsys (>= 1.1.15)" mean?
#ubuntu-devel 2007-10-17
<Treenaks> pitti: it compensates by making the bottom bar double height ;)
<pitti> so, that seems to work just fine, including https://
<Riddell> pitti: that's right
<pitti> thanks
<Hobbsee> pitti: kopete breaks, though
<Riddell> I'll release note that
<fabbione> Seveas: ping?
<pitti> Hobbsee: seed?
<pitti> TomaszD: I am, yes
<Hobbsee> pitti: torrents.
<Hobbsee> pitti: if you get people seeding, the torrents will be faster, and so people shouldnt hammer the http so much.
<Hobbsee> that's the hope, anyway :P
<lool> keescook: Around?
<pitti> pitti â© torrents = Ã¸
<Hobbsee> yeah, well.  we know :)
<keescook> lool: yup, what's up?
<lool> keescook: Pango's upstream pointed the distributor at seemingly a minor fix which should be backported; gutsy isn't affected, and it mroe or less could be interpreted like a security issue
<lool> keescook: http://bugzilla.gnome.org/show_bug.cgi?id=463430 what do you think?  Do you think it's worse a security update?  I don't think it's worth a SRU
<keescook> lool: checking...
<jdong> Hobbsee: should I be seeding an image?
<Hobbsee> jdong: that would be nice.
<jdong> Hobbsee: I have roughly 200mbit/s idle bandwidth to donate
<pitti> Hobbsee: /me invokes the magic Jedi wave to get people seeding
<Hobbsee> pitti: they're on r.u.c?
<keescook> lool: It's a client-side DoS, which is certainly annoying, but beyond that, I don't see any security implications.
<Hobbsee> jdong: please do.  find out where htye are.
<Hobbsee> you can test out the tracker while your'e at it :P
<pitti> Hobbsee: yes, in /.pool, kubuntu/.pool, etc.
<nemik> so why don't the repos have 'figlet'?
<Hobbsee> nemik: they do.  in universe.
<nemik> hmm ok thanks
<Hobbsee> pitti: ah, kay, cool.
<lool> keescook: Ok; I wanted to double check as upstream took extra care to point people at this issue, but I didn't find it relevant enough; thanks!
<jdong> ubuntu-7.10-desktop-i386.iso             16-Oct-2007 00:53  696M
<jdong> is that the right one?
<pitti> jdong: right
<keescook> lool: sure, thanks for the heads-up.  :)
<pitti> jdong: /.pool has both the iso and the .torrent
<jdong> ok, thanks, I'll egin to seed then
<pitti> jdong: thanks muchly
 * Hobbsee ponders a "if you have lots of bandwidth over the next couple of days, /msg me" announcement to +1, but thinks that might be a bit over the top :P
 * evand waits for some evil person to submit the URL to slashdot and digg.
<jdong> pitti: I don't see the .torrents in there?
<Hobbsee> evand: if they do, they'll be from this channel.  and be shot.
<nemik> Hobbsee: "figlet is not available, but is referred to by another package."
<nemik> Hobbsee: universe is enabled
<jdong> figlet is multiverse, right?
<evand> right
<stgraber> I should be able to run the bittorrent client on some servers (totalling something like 600Mb/s)
<Hobbsee> er, figlet is in multiverse, for some strange reason
<Hobbsee> stgraber: great!
<nemik> is multiverse in default sources.list?
<Hobbsee> no
<jdong> wow, I'm pulling 6MB/s from releases
<jdong> that's a first...
<Hobbsee> jdong: yeah, well.  people dont know about it yet :)
<nemik> hmm multiverse is enabled as well and no figlet
<evand> am I the only one not seeing the torrent files?
<jdong> so... can someone point blind old me towards the .torrent?
<Hobbsee> evand: no
<Hobbsee> but you're uncool by not seeding them, so get to it :P
<evand> I'm trying!
 * jdong goes onto t.u.c:6969
<stgraber> jdong: 11Mb/s here downloading ubuntu-desktop :)
 * Hobbsee starts poking peple in +1
<cjwatson> stgraber: the translated version should be moved to another page
<cjwatson> stgraber: but in any case it won't end up on www.ubuntu.com
<jdong> hmm .torrent is not on the tracker yet; I guess it's yetto be made?
<cjwatson> I think it's unlikely that the torrents will be available until tomorrow
<cjwatson> there are other ways to get the image to prepare a seed
<jdong> ok, then I'll wait for the release of the torrent to start seeding; I've got the image ready togo
<Hobbsee> evand: sigh.  is there any way i can check if ubiquity has frozen, or is just taking forever?
<pitti> jdong: ah, I see; well, it's identical to http://cdimage.ubuntu.com/daily/current/ which does have torrents; no idea whether that helps, thogh
<Hobbsee> seb128: you were wrong, btw.
<evand> tail the logs, strace failing that
<Hobbsee> evand: syslog would be of most help, i take it?
<evand> syslog, debug if you've enabled it
<cjwatson> Hobbsee: check process list too
<cjwatson> if apt-get update is running and your network connection is dubious, then it's that
<Hobbsee> cjwatson: no migration-assistant, no apt*.
<cjwatson> Hobbsee: what *is* it doing, UI-wise?
<Hobbsee> cjwatson: says 88%, importing documents and settings - and i cleared teh windows stuff out, so it shouldnt tkae forever to import.
<evand> but you don't see ma-* in ps?
<Hobbsee> evand: ah, i lokoed under migration-assistant, not m-a
<Hobbsee> root     18067  0.0  0.0   2872   924 ?        Ss   04:05   0:00 /sbin/mount.ntfs /dev/sda2 /mnt/migrationassistant -o rw,umask=0022,nls=utf8
<evand> look for ma-apply or ma-import
<Hobbsee> evand: nope to both
<evand> uh, odd
<Hobbsee> oh!
<Hobbsee> evand: when you tested m-a, did you ever test where the windows user had no p/w set?
<cjwatson> gar, I fixed that :-P
<cjwatson> (evidently not)
<evand> cjwatson: fixed what?
<Hobbsee> debconf (developer): --> 1 Sarah Hobbs.SARAH
<Hobbsee> Oct 18 04:05:39 debconf (filter): <-- GET migration-assistant/sda2/Sarah:Hobbs.SARAH/user
<cjwatson> Hobbsee: is there a log-output process running? what state is it in?
<Hobbsee> debconf (developer): <-- GET migration-assistant/sda2/Sarah:Hobbs.SARAH/user
<Hobbsee> debconf (developer): --> 1
<Hobbsee> Oct 18 04:05:39 debconf (filter): <-- GET migration-assistant/new-user//password
<Hobbsee> debconf (developer): <-- GET migration-assistant/new-user//password
<Hobbsee> debconf (developer): --> 10 migration-assistant/new-user//password doesn't exist
<evand> ...
<Hobbsee> Oct 18 04:05:39 debconf (filter): <-- PROGRESS STOP
<evand> not good
<Hobbsee> root     16411  0.0  0.0      0     0 ?        Z    03:54   0:00 [log-output] <defunct>
<cjwatson> that's not "no password set in Windows", that's "m-a is wrongly trying to fetch data for a blank username"
<Hobbsee> cjwatson: only ^
<evand> it is supposed to check for that
<Hobbsee> cjwatson: oh, my bad.
<cjwatson> Hobbsee: that I'm *sure* I fixed, but ... oh, hmm
 * evand fires up vmware
<cjwatson> I bet the fix needs to be duplicated into m-a
<cjwatson> (or fixed properly in ntfs-3g, but we didn't have time)
<evand> bug #?
<cjwatson> -       mount $fs /target$mp || exit 1
<cjwatson> +       mount $fs /target$mp 3>&- || exit 1
<evand> ah
<cjwatson> partman-basicfilesystems 54ubuntu4
<evand> indeed
<Hobbsee> erk.  i'm using an old version!
<evand> I imagine there's no time for that now
<Hobbsee> i rebooted since grabbing the latest!
<cjwatson> evand: doubt it
<evand> hahaha
<Hobbsee> this is what happens late at night...
<keescook> Amaranth: see that bug 145123 is not fixed.  :(  Can you point me to the patches needed to fix this for a post-release security update?
<keescook> s/see/seems/
<Amaranth> keescook: All known patches for it are applied
<Amaranth> keescook: It only allows you to alt-tab and such, focus is locked to the password entry
<Amaranth> keescook: And you reopened a dupe
<keescook> Amaranth: see bug 153200 then for further details...
<Hobbsee> cjwatson: evand i'm so sorry.  clearly my brain is going :-S
<mvo> macslow was working on it
<evand> Hobbsee: I'm sorry for creating the hell you're currently faced with.
<Amaranth> Oh, alt-f2
<Amaranth> grr
<Hobbsee> evand: :D
<Amaranth> So much for lock screen
<Hobbsee> evand: what surprises me - i *always* have trouble with ubuntu, or the ubuntu installer.  kubuntu is fine.
<Amaranth> alt-f2, killall gnome-screensaver
<Hobbsee> excluding when it refuses to boot, due to dhcp timeouts on 2 connections (which i think stopped)
<keescook> Amaranth: yeah.... all shortcuts should be disabled...
<Amaranth> keescook: If gnome-screensaver would grab the damn screen properly...
<keescook> Amaranth: heh.  is that fixable?
<keescook> i.e. does it make sense to fix it in gnome-screensaver instead?  (does xscreensaver do it right?)
<evand> Hobbsee: well, kubuntu doesn't have m-a yet, for one.
<Hobbsee> evand: perhaps that's why.  usually, m-a isnt the problem.
<Hobbsee> did the bug about the manual partitioning freezing ever get solved, btw?
<evand> yes
<Hobbsee> \o/
 * Hobbsee glares at ubiquity
<Amaranth> keescook: The funny thing is gnome-screensaver uses the exact same code as gksu
<Amaranth> keescook: and gksu works fine
<Hobbsee> please dont freeze before you've *started* the install.
<evand> haha
<keescook> Amaranth: weird indeed :(
<Amaranth> keescook: iirc the problem is that there is an implicit unmap/map when you unredirect a window (unredirect fullscreen windows option in compiz) which makes gnome-screensaver lose its locks
<Amaranth> So it's possible gksu works because it does the locks at a different time
 * keescook nods
<Amaranth> hell, it's probably a race condition
<Amaranth> because it doesn't always happen
<keescook> Amaranth: can I assign the bug to you?  it needs fixing, but I don't have any experience with the affected code
<Amaranth> keescook: I beat my head against that one for a week
<keescook> eek
<cjwatson> Hobbsee: better it freeze then than after it's starting writing to the disk
<Hobbsee> cjwatson: it's already done that.
<Amaranth> mvo had something that mostly worked
<mvo> Amaranth, keescook: I had fun with it too, I though I fixed it :/
<mvo> I guess I need to do a night shift then
<Hobbsee> cjwatson: and i managed to kill X somehow while running display-gtk, adn trying to display the resolution, so i had to kill the install then too
 * mvo goes to make some tea
<keescook> mvo, Amaranth: okay, I'll let you guys work this out.  I need to get a system that can actually handle compiz.  ;)
 * mvo switches network
<seb128> Hobbsee: wrong? you switched back to KDE after 10min not an hour? ;)
<Hobbsee> seb128: no.  i'm still trying to get the bloody thing to install
<Hobbsee> evand: ROCK ON!  it's actually behaving correctly, it seems.
<evand> Hobbsee: fantastic
<evand> I've been unable to reproduce it letting you pass with an empty password thusfar
<evand> so it at least doesn't occur in the basic case
<Hobbsee> seb128: my kde install is botched anyway, due to reformatting swap.
<Hobbsee> so i may as well fight with this one :P
<Hobbsee> uh oh
<Hobbsee> clock.windback()
<Hobbsee> cjwatson: evand looks like we have success.  dont panic :)
<Hobbsee> however, most unfortunately, i'ts 5am.
<Hobbsee> and the sun is coming up.
<mvo> keescook: its fun, xscreensaver is indeed not affected
 * evand 's heart starts beating again
<Hobbsee> oh wait, perhaps not
<Hobbsee> nope, we got beyond 88%.  excellent.
<Hobbsee> configuring the hardware...
<keescook> mvo: hunh, so the issue is likely with gnome-screensaver then?
<evand> now you're clearly just toying with me ;)
<Hobbsee> evand: no, i got the order wrong :)
<mvo> keescook: or in the interaction, g-s-s and x-s-s work dfferently internaly
<Hobbsee> i thought it did the import at 78, not 88%
<evand> ah
<mvo> keescook: its a bugger of a bug, I have a sledgehammer patch, but there must be a better way
<Hobbsee> and this forecast is mega-cool!  :D
<keescook> I'm going to yank an nvidia card out of my ppc box.  maybe then I can get compiz on my desktop.  ;)
<liw> I'm having trouble upgrading to feisty-updates (as part of an upgrade test for gutsy), and it fails, because of openoffice -- is this known?
<mvo> liw: in what way does it fail ? ttf-opensymbols maybe?
 * Hobbsee heads to bed, after copying files voer.
<Hobbsee> night all!
<Mithrandir> night, Hobbsee
<evand> goodnight Hobbsee
<liw> mvo, yeah
<liw> mvo, ttf-opensymbols is not configured yet, leading to a dependency problem
<cjwatson> liw: check your system clock
<cjwatson> fontconfig has a known bug where it breaks if the clock is wrong
<liw> it seems to be correct
<liw> to within a minute
<mvo> aha, I was suspecting the clock issue
<liw> how exact should the clock be?
<liw> and is there a workaround?
<evand> liw: sudo ntpdate pool.ntp.org
<mvo> I had this issue when my clock was a couple of weeks late, but if your clock is correct, then I don't know about the problem. does /var/log/fontconfig.log has anything interessting?
<elmo> cjwatson: woah, neat bug
<liw> ntpdate adjusted the clock by ... 0.06 seconds :)
<evand> ah, nevermind then :)
 * mvo wonders if update-manager should run ntpdate automatically when it starts
<liw> mvo, nothing that looks interesting to me
<liw> it says /root/.fontconfig is unwriteable, but later that it succeeds anyway
<liw> oh, but in the apt output there's "/usr/share/fonts/truetype: failed to write cache"
<liw> plus several other dirs, same error message
<elmo> every command should run ntpdate, in fact ld.so should run it before running the actual binary of anything
<liw> elmo, but that relies on new processes starting... better tie it to syscalls
<liw> if I run "fc-cache -fs" manually, it gives the same errors
<mvo> keescook: it looks like the actual fix needs to be done in gnome-screensaver, I have a patch (no sledgehammer this time). but a word from upstream would be good here, the code is not trivial
<liw> strace on fc-cache doesn't tell me anything... I guess I'll just report the problem and continue with other tests
<liw> or rather I won't report it, since it's already reported
<keescook> mvo: can you attach the patch, just for future reference?
<mvo> keescook: gnome-screensaver is really fun, it likes to keep track of what windows are created etc
<mvo> keescook: I'm going to attach it and then look a bit deeper
<keescook> mvo: okay, thanks.
<mvo> keescook: can you give me the bugnumber again? I switched machine and it is now on the other machine
<mvo> keescook: neverwind
<TomaszD> hey, I'm currently remastering the gutsy iso and I have a question. What happens if I add the ati and nvidia proprietary driver packages to the standard distribution? Will it mess r-m up or will it just make it easier for people without a network connection? I'm asking because I'm not sure if installing these packages implies changing the configuration that would make e.g. fglrx work out-of-the-box which I don't want to happen or would it comple
<TomaszD> tely mess everything up and it's not advised to include these (apart from religious beliefs about it and the law)
<TomaszD> pitti, ?
<Burgundavia> TomaszD: it is not religous belief, it is genuine concern about breaking the law
<TomaszD> Burgundavia, I'm asking from a purely technical standpoint, nothing else. I need to know if having these packages installed makes them work ootb or do you still need r-m to change the configuration
<Amaranth> TomaszD: You don't want to do that
<Amaranth> TomaszD: Both fglrx and nvidia-glx replace libGL.so.1
<Amaranth> TomaszD: I don't even think you can install both of them and if you can you'll just make users have to remove one or both of them to get 3D
<TomaszD> ah that's what I needed to know, again saved from a potential disaster
<TomaszD> thanks Amaranth
<Amaranth> no problem
<Amaranth> We're going to have to figure out a solution for that eventually
<TomaszD> yeah, besides one could have an ati and and nvidia graphics card in the same computer (one onboard and one in the pci express slot, or both in pci-x)
<Amaranth> TomaszD: Completely not supported :)
<Amaranth> TomaszD: Of course the 'solution' is open source drivers that use mesa
<TomaszD> of course.
<pitti> TomaszD: you mean change the livefs to have them installed by default?
<TomaszD> pitti, yeah. I'm currently modyfing the gutsy iso, basically just adding the Polish localization packages and making Polish as default, but also adding some more applications and games
<pitti> TomaszD: what do you drop instead? just other langpacks?
<TomaszD> pitti, I'm not dropping anything. My medium of choice is DVD :]
<TomaszD> though I've had my 7.04 remix done within 700mb constraints once, downloaded 120 times
<pitti> TomaszD: ah, that would help :)
<TomaszD> indeed
<Intangir> someone put me on the ubuntu development bug tracking mailing list
<Intangir> and im getting like 100 mails a day
<Intangir> how do i get off of it..
<Intangir> its a launchpad thing i think
<cjwatson> Intangir: please put a sample mail (including *full* mail headers) on paste.ubuntu.com so we can see where it might be coming from
<Intangir> oh its cause im on ubuntu-desktop-effects group/project on launchpad
<Intangir> ive been on it for months though and it never sent me all this mail before
<Intangir> how do i get off of a group on launchpad?
<Intangir> nevermind i just found it
<pochu> Intangir: that team's mail address was set to the admin's one, so only he was receiving all those mails. But he might have removed it, so now all the members are getting them.
<Intangir> wow seems like they sure are busy
<cjwatson> from ubuntu-desktop-effects you should only be getting bugs about compiz, compiz-fusion-plugins-main, and xserver-xgl
<cjwatson> of course that may still be rather a lot
<Intangir> ya its alot apparently ;)
<cjwatson> as you've probably already found, https://launchpad.net/~ubuntu-desktop-effects/+leave will let you leave the team
<cjwatson> alternatively it may be worth asking the admin if the team's e-mail address should be set to a mailing list or something
<Intangir> well i already left it
<cjwatson> since it has rather a lot of members
<Intangir> seems like someone recently changed the emailing though
<Intangir> laters
<pitti> BenC: btw, feel free to upload the dapper.2 packages to -proposed once they are ready (not sure whether you are waiting for an ack from me or are just still busy with tests)
<BenC> pitti: just finishing things up
<BenC> pitti: I'm done with changes, just need to dpkg-buildpackage and upload
<pitti> \o/
<calc> slangasek: i uploaded the ooo 1ubuntu5.1 today for gutsy-proposed
<slangasek> calc: ok, cheers
<ScottK> slangasek: There was a gnugpg bug in Feisty that resulted in gpg.conf not being created.  It's fixed in Gutsy, but upgraders from a fresh Feisty install need to do a manual action to get a gpg.conf.  I think it ought to get in release notes.
 * ScottK looks for the reference.
<slangasek> seems to me that should've rather been put in the feisty release notes?
<ScottK> slangasek: Bug #76983 is the bug.
<ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Medium,Fix released] https://launchpad.net/bugs/76983
<ScottK> Well I didn't it wasn't fixed then.
<ScottK> err
<ScottK> It wasn't fixed then.
<ajmitch> sounds more like feisty errata than feisty release note material
<slangasek> yes, release notes are primarily for documenting things that aren't fixed :-)
<ajmitch> if known at the time of release :)
<ScottK> OK.  Well if you don't manually make the gpg.conf and you are upgrading from a Feisty install, it's not fixed.
<ajmitch> I'm sure there are many bugs we could mention in release notes if we knew about them
<ScottK> Well for Kubuntu we have GPG and S/MIME by default as a feature for this release.  If the gpg.conf isn't there, it won't work.  https://help.ubuntu.com/community/KMailGPGAgent#head-c6757d6675d3932eaeffb136479725842a81d9b6
<cjwatson> ajmitch: release notes are editable post-release
<ScottK> slangasek: Up to you, but I think it's worth a mention.
<cjwatson> it does seem that it's something upgraders to gutsy need to know about though?
<ajmitch> cjwatson: good point
<cjwatson> but I don't feel strongly
<slangasek> ScottK: so the specific issue is that use-agent is in the options.skel, and fails to be copied to .gnupg/gpg.conf?
<ScottK> Yes.
<slangasek> ok; that's a lot more specific and IMHO reasonable to document
<ScottK> That's what hurts Kmail, but the lack of gpg.conf is a general not ideal situation.
<ScottK> OK
<slangasek> <shrug> the default gpg.conf has only two options enabled :)
<slangasek> do you want to propose some text, or should I?
<ScottK> Please go ahead if you will.  I'm already 6 minutes past when the babysitter quit for the day.
<slangasek> right
<ScottK> slangasek: If you need me to propose text, I can do it later tonight (+ ~4 hours)
<slangasek> nah, it needs to be done before then anyway if it's going t obe included in the launch version
<ScottK> slangasek: Thanks.  I'm off to find my children.  Good evening.
<slangasek> ScottK: later :)
<slangasek> StevenK: quick! dexter has orphaned libapache2-mod-auth-plain and libapache2-mod-auth-pam, kill the yada!
<soren> StevenK: LOL @ "Accidently convert package to using cdbs, since a few people have a vendetta against yada.
<soren> "
<soren> Dear $DEITY.
<soren> It's the first time I've laid eyes on a package using yada. It's hideous!
<ajmitch> soren: why did you look?
<slangasek> in response to my above comment, I assume. :)
<azeem> another victim of an innocent vorlon comment
<slangasek> I'm like that
<ajmitch> poor, trusting fool :)
<tepsipakki> who broke wiki authentication?
<ajmitch> 11:22 < kiko> we're having problems with the DC machines
<ajmitch> so probably related to that
<tepsipakki> gah
<lamego> grrr
<tepsipakki> my edits are gone then
<lamego> I lost a lot of text
<stgraber> +1
<lamego> I would kick someone right now
<tepsipakki> I have a can on the table, hmm
<tepsipakki> there
<lamego> GRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
<tepsipakki> lamego: advice; just refresh the page :)
<tepsipakki> did the trick here, no change lost
<lamego> grrr, now you tell me
<lamego> too late :(
<tepsipakki> sorry, just noticed it myself
<slangasek> ScottK: 76983 release-noted
#ubuntu-devel 2007-10-18
<LaserJock> arggg
 * LaserJock kicks Firefox
 * LaserJock tries to find a less sucky browser
<ajmitch> hello LaserJock :)
<LaserJock> hola andrew
<lifeless> keescook: ping
<RAOF_> LaserJock: Until ff-3 got native gtk form widgets, I was using Epiphany.  That works well.
<mneptok> w3m
<LaserJock> "N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu team"
<LaserJock> ^^ seems a little harsh for Universe
<ajmitch> unsupported by canonical, at least
<LaserJock> exactly
<crimsun> it seems right on, actually.  It certainly doesn't "give the wrong impression" for best-effort community support.
<LaserJock> I didn't know Canonical == Ubuntu team
<lifeless> there's an equality proof somewhere.
<LaserJock> crimsun: but it's *is* supported by the community
<LaserJock> that statement makes it sound like they're be no sense in filing a bug for a Universe package
<LaserJock> and in fact it would be discouraged because it's unsupported software
<LaserJock> or am I reading too much into "ENTIRELY UNSUPPORTED"
<ajmitch> within universe there are different levels of community support as well
<LaserJock> sure
<LaserJock> but imperfect support is far from no support, IMO anyway
<ajmitch> agreed
<ajmitch> it certainly conveys the impression that people shouldn't expect fixes, at least
<slangasek> I suppose it's a question of not misleading users into thinking they'll get more support than they will
<ajmitch> it probably does go too far in that direction
<LaserJock> I guess I better not get on a "demotivating" kick again
<LaserJock> but seriously, calling Universe entirely unsupported by the Ubuntu team seems a bit much
<lifeless> LaserJock: I think there is a legal issue here too
<lifeless> I can imagine some jurisdictions equating support with liability.
<lifeless> and as there is no guarantee of even a trivial fix for universe in the event of a problem
<LaserJock> ok, so why should there be a Main/Universe separation there?
<LaserJock> so Canonical's taking on legal liability for Main?
<lifeless> thats not what I'm saying
<lifeless> and in fact not even implied. Take security fixes for instance.
<lifeless> there are security fixes for Main.
<lifeless> If you have something in main, and there is a known vuln with it, that will get into -security quite rapidly.
<LaserJock> well, there is a larger chance anyway
<LaserJock> seems like a "Universe is community supported" would suffice
<LaserJock> are there legal ramifications to that statement?
<lifeless> IANAL
<LaserJock> of course, nobody ever is
<RAOF_> Except for *lawyers*, of which I'd imagine Canonical has access to a few.
<LaserJock> seems like a perfectly harmless statement
<mpt> "community supported" is a meaningful phrase if you're familiar with the Ubuntu development structure
<mpt> but perhaps not if you're not
<LaserJock> maybe less
<LaserJock> but I think it's still fairly understandable
<johanbr> I think a true statement understood by some is better than a misleading statement understood by all.
<slangasek> that likely depends on the nature of the misunderstanding in the first case :)
<Burgundavia> it could explicitly say that it is not supported by Canonical
<pwnguin> why does ubuntu publish what canonical does and doesn't support?
<zul> probably more for canonical customers
<pwnguin> i realize the two are highly intertwined in some fashion
<Burgundavia> that has been defined since day 1, pwnguin
<pwnguin> and on day 366 the Ubuntu Foundation was created (dont quote me on that day)
<Burgundavia> because, not shockingly, customers and potential customers like more information, not less
<Burgundavia> the foundation does not do anything
<pwnguin> at least from my point of view, it seems like Canonical has ownership / responsibility of main, but every time someone suggests it, people point out all the non-Canonical people in Core Dev
<pwnguin> which, i should point out, im fine with.
<Burgundavia> both are right
<Burgundavia> basically, there are non-Canonical people who can commit to Main and Restricted
<Burgundavia> but for security patches, that is the job of canonical
<Burgundavia> and they have said, for very sane reasons, that they are only goint o support main and restricted
<mjg59> Canonical take responsibility for main, whoever puts stuff in there
<pwnguin> i figured the ubuntu foundation was taking responsibility for that once it was created, but i guess not
<mjg59> The Ubuntu Foundation exists to take responsibility for Ubuntu should Canonical stop doing so
<Burgundavia> the foundation is currently just a storehouse of money in case anything happens to Canonical
<pwnguin> so the UF is basicaly a 10 million dollar insurance policy ;)
<Burgundavia> don't you love Mark?
<pwnguin> heh
<Burgundavia> in all seriousness, the foundation was setup because at the time, people were questioning whether this was all just a flash in the pan or not
<pwnguin> at the time, i thought the foundation was an effort to seperate canonical legally from ubuntu somewhat
<Burgundavia> nope
<pwnguin> i suppose it does seperate their fates somewhat
<LaserJock> so if Canonical goes under do the copyrights go to the foundation?
<elmo> LaserJock: <unofficial and hand-wavy>yes, that's the plan/point of the foundation
<LaserJock> ah, I see
<LaserJock> makes sense
<pwnguin> plans are like wills
<pwnguin> well, i guess this plan is like a will
<Burgundavia> except wills are legal
<Burgundavia> I honestly have no idea as the actual legal stuff in place
<pwnguin> only if they're written down somewhere
<Burgundavia> although as a member of the CC, I guess I should
<pwnguin> which was sorta my point. wills are a great idea everyone figures they'll do later after everything important's done =/
<elmo> pwnguin: Canonical's not a VC, we're not going to suddenly run out of money
<pwnguin> right
<pwnguin> you havent contradicted anything ive said. i doubt canonical is in any large danger of dying, unless sabdfl suffers a massive paternity suit
<elmo> the only danger of the foundation not happening is the hypothetical of Canonical going evil, and I doubt even the strictest legal stuff could realistically be safe from that (and allow Canonical to function even in non-evil mode)
<pwnguin> the thing a contract outright would do is save on legal costs
<pwnguin> instead of having to prove that Ubunutu community / foundation has a right to the copyrights etc
<elmo> actually, that's not even true.  I'm not expressing myself well at all, as it's way too late
<elmo> pwnguin: copyrights are largely irrelevant?  Ubuntu is all free software
<LaserJock> yeah, I wondered what the heck you were doing up at this hour :-)
<elmo> if the license is truly free, it doesn't matter if the copyright is assigned to Canonical or Billy Bob
<pwnguin> elmo: in a worst case scenario, i imagine the name and logo alone would divide the community
<LaserJock> elmo: I just wondered as I guess technically I've signed over copyrights to Canonical before so I wondered
<elmo> pwnguin: so, that's trademark - a very different thing from copyright.   and ubuntu, IMO, is more than it's logo/name.  i.e. if it had to be changed, it'd hardly be the end of the world
<pwnguin> elmo: hence the etc
<elmo> LaserJock: sure, it's a reasonable question.  the UF stuff isn't as clear as I'd like
<pwnguin> elmo: at any rate, unlike a will, canonical's death is not inevitable
<elmo> pwnguin: right
 * pwnguin wonders what that 10 million does right now
<pwnguin> a guy from ibiblio stopped by today to talk to the uni's library. they have a fairly unique situation
<mjg59> elmo: Well. Mark's pockets only go /so/ deep
<pwnguin> actually, im thinking of the internet archive
<elmo> mjg59: well, sure.  but it would take something pretty dramatic (massive lawsuits?) to stop Canonical, rather than VC people going 'hmm, this isn't making us money fast enough', I guess is my point
<ScottK> slangasek: Thanks (re: ScottK: 76983 release-noted)
<mjg59> Oh, yeah
<ScottK> LaserJock: You can't technically sign over a copyright (at least not in the US).  It requires an explicit transfer (which is why, among other things SCO-Novell was a slam dunk for Novell).
<LaserJock> hmm
<pwnguin> whats the difference between an explicit transfer and "signing over" copyright?
<LaserJock> so what am I doing when I make packages and say Copyright Canonical Ltd. ?
<pwnguin> LaserJock: is it a work for hire?
<ScottK> LaserJock: Well that would be an explicit transfer I suppose, but why are you doing that?
<ScottK> pwnguin: Nothing really, just that it can't be implicit.
<ScottK> As an example, the core of SCO's case against Novell was something like "Everyone knew the copyrights transferred even though it doesn't say that in the contract."  That can't work.
 * ScottK spends too much time reading Groklaw.
<pwnguin> was that in question here?
<ScottK> No.  Probably not.
<ScottK> "technically I've signed over copyrights" is what i was keying on.  Sounded implicit to me.
<LaserJock> pwnguin: no it wasn't work for hire
<pwnguin> LaserJock: what exactly did you turn copyright over for then?
<LaserJock> ScottK: cause everbody else was, I didn't want to be the odd man out ;-)
<pwnguin> ah, heh
<ScottK> Really.  The only people I've seen to that are Canonical employees who are doing it for hire.  For them it would be wrong not to.
<pwnguin> well, i donno about wrong
<pwnguin> canonical can certainly ASK them to
<pwnguin> and condition payment upon it
<ScottK> It varies by jurisdiction.
<LaserJock> in any case, I saw enough of it that I just assumed that that was the status quo
<ScottK> In the US (which is what I'm most familiar with, but not where most Canonical employees are), a work made for hire automatically belongs to whoever pays.
<ScottK> Which is a perfectly reasonable reason to be doing it.
<pwnguin> forgive me for not using names in this example, but i dont know the core devel activities well
<pwnguin> but if the ubuntu gcc maintainer hired by canonical makes a patch to gcc, he'd need permission from canonical to submit upstream?
<holycow> depends on canonical policies
<holycow> their policies may indeed be lax enough so he/she doesn't haveto
<mjg59> pwnguin: If carried out on work time in most jurisdictions, yes
<pwnguin> fun
<mjg59> But it's perfectly possible for there to be an implicit agreement that it's not an issue
<mjg59> And, of course, if it's a derived work of a GPLed product then if you ever distribute it the entire source has to be under the GPL
<pwnguin> now wait a minute. ScottK just suggested implicit assignment wasn't allowed
<mjg59> At which point anyone can do what they want
<mjg59> pwnguin: That isn't implicit assignment
<pwnguin> the point here is that the FSF requires you to hand over copyright
<pwnguin> if they are to accept your work
<holycow> only if you distribute it
<pwnguin> no
<pwnguin> only if you want them to take it
<mjg59> That's because they have different policies to everyone else
<LaserJock> yeah, I always thought that was kinda creepy
<elmo> there's some definite advantages to copyright assignment
<ScottK> Gives them a way to make sure something uses GPL v3.
<LaserJock> yeah
<LaserJock> I understand their reasoning, it's just still a bit creepy
<mjg59> Gives them the right to start lawsuits if someone infringes
<pwnguin> whether you like it or not =/
<ScottK> They aren't the only ones that do it.
<mjg59> It's their project - it's their policy
<pwnguin> do you need everyone's permission to start a suit?
<mjg59> No
<ScottK> mjg59: As long as they have some copyright code that's all that matters, it doesn't need to be all.
<ScottK> It does make it easier for them to settle.
<mjg59> If they infringe the whole of gcc, fine
<elmo> pwnguin: but the judge can dismiss a lawsuit you start as 'without standing' if you don't own majority of the code
<mjg59> If they only take part of it, it's harder
<mjg59> Unless you have copyright assignment
<ScottK> Agreed.
<ScottK> Red Hat does the same for Cygwin (requires assignment).
<ScottK> In that case it's so they can dual license it and make money with it.
<LaserJock> how's that work?
<mjg59> Yes, that's the reason Sun do it for Openoffice
<mjg59> LaserJock: If you own the copyright, you can sublicense under any terms you want
<pwnguin> LaserJock: they own the copyright. it's their property now
<LaserJock> yeah, but how do they make money on a dual-license
<pwnguin> one license is GPL. the other is "pay us and you dont have to publish source"
<LaserJock> ahh
<ScottK> Yep.
<pwnguin> i hear reiser works in a similar manner
<LaserJock> is that the same with QT?
<pwnguin> i think so
<slangasek> "pay us and we'll give you the version of the fs that doesn't eat data muhahaha"
<pwnguin> heh
<lifeless> pwnguin: copyright can be granted without diminishing ones own rights.
<lifeless> pwnguin: so no, its not their property now.
<pwnguin> this conflicts with my understanding of property
<lifeless> clearly you consider copyright property; its not.
<LaserJock> it's the right to copy? :-)
<lifeless> its a mistake to think of abstractions like patents and copyright as forms of 'property', unlike property they can be shared without diminishing in value.
<pwnguin> somehow i think its a mistake to use economic abstractions about constructs of law
<slangasek> lifeless: but "copyright can be granted without diminishing one's own rights" doesn't follow either, copyright is the right of exclusive control to decide who can make copies
<slangasek> s/copyright/licenses to copy/, and ok
<lifeless> slangasek: hmm, not quite right there AIUI. I can assign copyright on something i created to you; wherein you gain and I lose the right to decide.
<lifeless> slangasek: but I can alternatively decide to share that control with you
<lifeless> where you can say 'X can copy' and I can say 'Y can copy'
<pwnguin> i imagine the courts hate that
<lifeless> pwnguin: well, the government grants the root monopoly
<ScottK> Just to complicate things, some countries have moral rights of authorship that cannot be sold transferred or anything.
<pwnguin> i vaguely recall Elite having something similar to that
<lifeless> ScottK: I have vague memories of the Berne convention being involved in that
 * ScottK has vague memories of it being French and common in countries with Napoleonic law systems.
<mjg59> The extent of moral rights differs between states
<ScottK> It doesn't exist at all in the US.  I do know that.
<mjg59> In the UK, it's limited to asserting the right to be identified as the author
<mjg59> In France, it includes not allowing the work to be used in ways you don't approve of
<lifeless> anyhow the primary point is that unlike physical goods while copyright *can* be treated as a fungible good, its got wider transactions available to its owners than any physical media
<mjg59> The interaction between this and the GPL has not been tesetd
<pwnguin> is there any reason to treat copyright as a sharable good?
<mjg59> Yes. It's hard to make money off it otherwise.
<pwnguin> not the copies
<pwnguin> the idea of sharing 100 percent of the right to copy with another entity, without losing the right yourself
<lifeless> by sharable good, you mean e.g. 'like a physical book' ?
<mjg59> pwnguin: Yes. It's hard to make money otherwise.
<mjg59> Well, permiting only exclusive assignments would still work there
<lifeless> we use the shared assignment in bzr
<mjg59> But the opportunity to let someone else make money off your copyrighted goods is a fundamental aspect of the traditional mechanism of making money off copyrighted goods
<lifeless> Canonical as the sponsoring organisation wants copyright on the code in bzr, so that we can manage the licence effectively over time. But we have no wish or need to remove the copyright from the author.
<lifeless> this lowers the barrier to getting authors to assign copyright - they lose nothing compared to a hand-it-all-over scenario
<pwnguin> the code that makes bzr run, or code in bzr repos?
<lifeless> uh
<lifeless> what do you think?
<pwnguin> well, i wasnt aware that canonical was involved with bzr development at all until recently
<pwnguin> what i think is probably not important or correct
<lifeless> the code of bzr itself
<lifeless> what people version with bzr is none of our business ;)
<pwnguin> well, launchpad hosts bzr repos
<pwnguin> it could have been some wierd requirement; look at the ppas
<LaserJock> lifeless: can the code author "back out" of assignment
<LaserJock> ?
<pwnguin> LaserJock: revoke a transfer, or abandon it?
<LaserJock> well, can they at any time say they don't want to share anymore
<elmo> pwnguin: err, what's weird about the PPA requirements?
<lifeless> pwnguin: ppas? What do they need ?
<pwnguin> elmo: last i knew
<pwnguin> i had to indemnify canonical
<ajmitch> from what I can tell, the PPA terms of service are just a fairly standard CYA template
<ScottK> They are not unusual, but they aren't very community friendly IMO.
<ScottK> According to the status on the bug I filed about it, it's being revised somehow.
<ScottK> We'll see.
<lifeless> pwnguin: launchpad requires open source for *the repo's it hosts*.
<pwnguin> like multiverse ;)
<lifeless> pwnguin: which is nothing to do with your using bzr onyour own project or your own site
<pwnguin> i know what you mean
<elmo> JOOI, do other 'community' sites have not have similar terms?
<elmo> SF, savannah, novell's forge, whatever
<pwnguin> google's is pretty lenient
<pwnguin> but i better double check
<elmo> ORLY
<elmo> http://code.google.com/tos.html
<pwnguin> thank you for finding that
<pwnguin> it doesn't matter to me much. im quite enjoying my ppa, patent infrigment indeminifcation be damned
<pwnguin> i just recalled scottk thinking the ppa terms were outrageous. perhaps it is scottK who is outrageous!
<ScottK> pwnguin: It may be the latter.
<ScottK> I think they aren't unusual, but unfortunate and not very community oriented.  I'd have hoped for better from Canonical.
<elmo> ScottK: what's your definition of 'community oriented'?
<slangasek> "lacking in fiduciary oversight" ;)
<ScottK> elmo: In this case, I'd like to feel that if I did nothing wrong, but got sued anyway it'd be Canonical and me versus the idiot that sued.  Bt the TOS, it'd be me and Canonical being sued and Canonical looking for me to pay their lawyer bills even if I'd done nothing to violat the PPA Terms of Service.
<ScottK> I think it's perfectly fine to ask for indemnification if someone uploads something that's not legally distributable.
<ScottK> What bothers me is I can do everything legal and correct, violate no terms of service, and yet Canonical wants me to pay their lawyers.
<elmo> if Canonical gets sued for distributing something of yours?
<ScottK> Right.
<ScottK> They chose to offer this service, so I think sharing of risk for use within the terms of service is reasonable.
<lifeless> well
<ScottK> If I upload something that's not legal to distribute, that's totally different.
<lifeless> You talk about legal-to-distribute
<lifeless> but the whole point of a court case would be about proving something is/isn't legal to distribute.
<ScottK> Sure.
<ScottK> So IMO it'd be quite reasonable to say as long as we win, you don't have to pay.
<ScottK> In some obscure juridications (like the US) it's very hard to collect legal fees even if you win.
<lifeless> so
<lifeless> say I'm a malicious person
<lifeless> I could upload a bunch of stuff that you would say is illegal to distribute
<lifeless> trigger a bunch of lawsuites
<lifeless> who pays from the start of the lawsuit through to the conclusion where I'm shown to be at fault?
<ScottK> I'd say we each pay and then at the end where we lose, Canonical hands me a huge bill.
<lifeless> which you, as a malicious person, don't pay. Probably can't - it might be millions.
<ScottK> I'd imagine that'd be the situation now too.
<lifeless> e.g. upload several thousand copies of windows
<ScottK> If I were Canonical, I'd take them down when notified and since Canonical doesn't pre-scren the uploads, that'd probaby be enough to cover them.
<ScottK> It's just like You Tube and copyrighted videos.  As long as they take them down when notified, they're clean.
<lifeless> well, thats enough IANAL speculation for me today; I have bugs to fix.
<ScottK> Oh, yeah.  Me too.
<tonyyarusso> cjwatson, Riddell, pitti, Hobbsee, slangasek, tfheen: It would be nice if one of you would volunteer to do the offical release announcement in #ubuntu-release-party when the time comes.  You can let us know if you'd be willing to do so in #ubuntu-ops and make appropriate arrangements.
<ScottK> tonyyarusso: I get dizzy just looking in there.
<ajmitch> tonyyarusso: just set it to +m for an hour or two, they seem noisy enough
<tonyyarusso> ajmitch: We'll do that when the time comes.
<tonyyarusso> ScottK: yeah, well.  Try moderating it ;)
<ScottK> tonyyarusso: No way.  I gave up on the user channels a long time ago.  To much for me.
<tonyyarusso> hehe
<ajmitch> tonyyarusso: just play with their minds for awhiel :)
<tonyyarusso> teehee
<ajmitch> they're already anxious about the state of ubuntu.com
<Hobbsee> note to self:  don't power off the machine during a dist-upgrade.
<ScottK> You aren't the only one.  I recall fixing one bug that I'm pretty sure a mid dist-upgrade reboot/power off is the only way it could have happened.
<ScottK> Good morning Hobbsee.
<pwnguin> not without a live CD handy
<pwnguin> and intimate knowledge of chroot
<pwnguin> thats about all i learned from gentoo
<pwnguin> how to effectively use chroot
<ajmitch> Hobbsee: there are more fun ways to wreck a system
<pwnguin> ajmitch: uploading broken dpkg updates?
<ajmitch> now that gets exciting
<ajmitch> though it can still be worked around
<ScottK> Sigkilliing dpkg is always good.
<pwnguin> another favorite daredevil trick: upgrading from lenny to feisty
<pwnguin> or any other trick along the lines of upgrading debian to ubuntu
 * ajmitch successfully did that
<ajmitch> sid->hoary
<ScottK> pwnguin: Not quite the same, but I did do Dapper --> Gutsy direct as an experiment.
<Artemis3> would it be too much to ask to put the .torrents in the pool? just a thought.
<evand> hamm->gutsy?
<ajmitch> evand: that's just wrong
<evand> I'm tempted to try it
<evand> just to see what happens
<ajmitch> though I'm sure it can be done, just ask Mithrandir
<pwnguin> make sure to film it
<evand> haha
<pwnguin> it only counts if apt-get does ti
<pwnguin> no chroot cheating
<pwnguin> http://www.ubuntulinux.org/support/documentation/faq/upgrade-sarge
<pwnguin> be afraid
 * ScottK has one computer still on Xandros 3 (for my kids).  He is pondering Xandros (sarge derived) --> Gutsy (after backing up data).
<Burgundavia> ouch, ubuntu.com just fell over
<ajmitch> afraid of the drupal error due to people constantly refreshing the page?
<pwnguin> heh
<ajmitch> Burgundavia: see #ubuntu-release-party for why
<ajmitch> it's mad
<Burgundavia> oh juoy
<evand> there's a point where IRC becomes completely unreadable.  #ubuntu-release-party seems to be moving at a rate above that.
<pwnguin> are ubuntulinux.org and ubuntu.com the same site?
<pwnguin> evand: #ubuntu itself often approaches that
<evand> pwnguin: I'm smart enough to never attempt to venture in *that* place. ;)
<Artemis3> pretty please .torrents in the pool, help save the server's bandwidth ;)
<evand> Artemis3: It was said earlier that the torrents will probably not hit the servers until tomorrow.
<Artemis3> ok but tomorrow 19 or tomorrow 18? because of utc time, etc...
<Hobbsee> morning ScottK
<elmo> Artemis3: err, it's not that simple
<Hobbsee> ajmitch: oh indeed.  it seems i've been trying them
<Artemis3> build a torrent and upload to any public tracker?
<pwnguin> heh
<pwnguin> put a torrent on thepiratebay
<Artemis3> yeah, that would be faster, maybe i will
<LaserJock> haha, should I yell "ITS HERE!!!" in #ubuntu-release-party?
<Frem> Too late, you've been beaten to the punch like 500 times.
<LaserJock> but I bet they go for it again
<LaserJock> that's the fun
<lifeless> is it done ?
<LaserJock> it's like Pavlov's dogs
<lifeless> what, they got fat ?
<LaserJock> ring a bell and they start drooling
<Frem> It's hilarious. There are countdowns to midnight every single hour.
<Artemis3> thanks for the torrents
<ajmitch> LaserJock: it's madness in there
<LaserJock> it is
<LaserJock> what fun
 * ajmitch might grab the iso images in a week or so
<ajmitch> until then, I'll refresh some QA tools & other things to fix :)
<LaserJock> wow
<LaserJock> ajmitch: I just signed up on shipit
<ajmitch> I tend to leave images to burn on the laptop for when I need them
<LaserJock> I'll get something like 10 Ubuntu and 2 Edubuntu CDs sometime in the future
<Artemis3> hmm the tracker torrent page seems a bit weird...
<LaserJock> wow, that's just ...
<LaserJock> I wonder what the average age in there is
<ScottK> tonyyarusso: The topic in #ubuntu-release-party needs updating as #ubuntu+1 redirects to #ubuntu now.
<StevenK> Did everyone get kicked from #ubuntu+1 as well?
<ajmitch> LaserJock: about 12, I think
<StevenK> LaserJock, ajmitch: Less I daresay
<imbrandon> wow that room gives me a headache
<tonyyarusso> ScottK: k
<LaserJock> I was gonna say IQ, but I that might not be so nice
<LaserJock> *I think
<imbrandon> LaserJock: talk like yoda day?
<tonyyarusso> ScottK: btw, all Ubuntu members have ops in -r-p now
<LaserJock> haha
<LaserJock> tonyyarusso: does that mean I can kick people?!?!
<ScottK> It's hard to tell from age.  At dinner on Monday night our 16 year old was asking questions to her mother (because she didn't know) and our 4 year old answered her (correctly).
<tonyyarusso> LaserJock: yes.
<tonyyarusso> LaserJock: s/kick/remove/ though
<StevenK> ScottK: Blink
<ScottK> tonyyarusso: I don't want my nick to be the one that set the topic in there.
<ScottK> StevenK: Yes.  It was really funny when it happened.
<ScottK> Our 4 year old often seems like she's 4 going on 24 anyway.
<ScottK> That and been a teenager seems to be a cause of temporary brain damage.
<tonyyarusso> ScottK: fair enough
<minghua> ScottK: What was the question?
<ScottK> I wish I remembered.
<StevenK> ScottK: Most 4 years olds do.
<imbrandon> ok time for some sleep, gnight all
<ScottK> But it was definitely something I expected the 16 year old to know and the 4 year old not.
<ScottK> imbrandon: Wimp (he's an hour west of me).
<ajmitch> imbrandon: already?
<StevenK> ScottK: And if you think 16 is bad, wait for 19
<ScottK> StevenK: At least then she'll be away at college most of the time.
<StevenK> ScottK: How does that help? :-)
<ScottK> Actually for her 13 seems to have been (so far) the peak.
<imbrandon> ajmitch: yea i'm just gonna take an 3 hour nap or something
<ScottK> StevenK: I have to deal with it less frequently.
<StevenK> ScottK: But surely then, the problems will be bigger?
<ScottK> Of course her younger step-sister is 13 and just ramping up into her teenagerdom.
 * StevenK has this feeling he isn't helping.
<ScottK> StevenK: No doubt, but I'd rath have a few big problems to deal with than the steady drip, drip, drip, drip continuous pull of them.
<ajmitch> you'd rather lurch from crisis to crisis?
<ScottK> Absolutely.  It's the story of my life.
<ajmitch> sounds liek software development
<ajmitch> s/liek/like/
<LaserJock> I think I should tell #ubuntu-release-party that ajmitch is a release manager
<ajmitch> and then I can tell them that it's delayed until monday?
<StevenK> ajmitch: No no, "No Gutsy for you. Come back one year."
<LaserJock> haha
<LaserJock> "sorry folks, we decided we'd just start on Hardy"
<StevenK> Bwahaha
<ajmitch> "we decided to push the release out by 6 weeks again"
<StevenK> ... past UDS
<Hobbsee> StevenK: i think we did that last release, actually.
<StevenK> Hah
<Hobbsee> Mithrandir: and i kept putting in wrong information - like that we werent going ot release it at all
<ajmitch> "sorry, the release managers are currently hungover & aren't prepared to release today"
<Hobbsee> hahahahaha
<Hobbsee> ajmitch: put that in!
<LaserJock> ajmitch: I've seen that one before, but for alphas
 * Hobbsee muhahahaha
<sladen> 6weeks ... that'd be enough time to change the wallpapers
<Hobbsee> !hungover is <reply> The Release Managers are currently hungover, and wont be releasing gutsy today
<Hobbsee> !hungover is <reply> The Release Managers are currently hungover, and wont be releasing gutsy today
<ubotu> I'll remember that, Hobbsee
<Hobbsee> good bot.
<minghua> poor bot.
<Burgundavia> heh
<slangasek> sigh
<Artemis3> that might explain the funny names in the torrent tracker page
<slangasek> I'm insulted by the implication that I get hangovers
<StevenK> Muahaha
 * lamont has never seen slangasek with a hangover.  who says he gets them?
<Hobbsee> wish the torrents were working though, they could do something useful, like seeding.
<Burgundavia> http://www.wired.com/software/softwarereviews/news/2007/10/ubuntu_gutsy <-- wired jumps the line
<pwnguin>  uh
<pwnguin> that wsj guy reported on gutsy like over a month ago
<sladen> lamont: the release process brings them on, even without any alcohol involved
 * lamont notes that http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy2-short-nohppa.png is getting boring
<minghua> That's what you get for having a hard schedule.  Have you ever seen anybody jumping the gun for a Debian release? ;-)
<sladen> Ubuntu Muslim Edition (UbuntuME) has alread "released 7.04"
<Burgundavia> minghua: they come so in frequently...
<StevenK> And it's so funny watching them scream
<minghua> Burgundavia: That's true, too.
<Hobbsee> StevenK: o hyes :)
<jcastro> sladen: dude you all set for uds? Don't come sick!
<slangasek> minghua: ...yes
 * lamont turns off creation of newer-more-boring gutsy graphs
<sladen> jcastro: dude, that was *sooo* not me
<StevenK> Last time it was lifeless
<minghua> slangasek: You are not referring to the infamous Debian 1.0, are you?  (I just remembered that...)
<jcastro> sladen: :)
<slangasek> minghua: that's the most significant one, anyway
 * StevenK waits for slangasek to join -release-party and tell everyone to be quiet for a few hours so he can get some work done.
<minghua> Yeah, I know it's not a sound argument.  Just trying to say pre-mature reviews are hard to avoid with a fixed schedule.  Maybe I should have just said that.
<pwnguin> http://online.wsj.com/public/article/SB118963540721725614-FnJzx_wcNlkRFOef4cgq74PBW3g_20080912.html
<pwnguin> that was published in september
<pwnguin> and its basically still true =/
<elmo> haha
<StevenK> slangasek: You should release Lenny by accident. :-P
<slangasek> bwaha
<StevenK> slangasek: :-P
 * lamont reboots into gutsy, hopefully
<StevenK> "No, Gutsy isn't out. We add an hour every time some one says that, so we looking to release October 20."
<StevenK> "2016"
<LaserJock> oh man, I might try that
 * StevenK grins at LaserJock 
<minghua> Hmm, that sounds a lot of hours...
<ajmitch> that sounds about right based on how often it's been asked
<sladen> <exhume> im sure they arent just sitting there laughing at us cuz we are all waiting here
<ScottK> Heh.  Have to laugh at that one.
<StevenK> Muahaha
<ajmitch> would we do that?
 * StevenK smirks
<minghua> ajmitch: Okay, so I was just being pedantic and did the calculation.  That roughly equals one asking per second for 24 hours.
<minghua> ajmitch: So you are probably right.
<ajmitch> haha
<StevenK> minghua: Muahaha
<dholbach> good morning
<StevenK> Morning dholbach
<dholbach> hi StevenK
<StevenK> dholbach: I think it's your turn to stir people up in -release-party
<dholbach> I was never under the impression that people who are willing to party need stirring up :)
<LaserJock> hehe
<LaserJock> I think I should introduce dholbach as a Canonical employee
<LaserJock> that would probably work
<StevenK> Then he'll get mobbed.
<Hobbsee> just give him ops
<Hobbsee> besides, we said there was no release today.
<Hobbsee> Fujitsu: does jabber.org hate the world again, or does my pidgin suck?
<Tesla|Work> Hobbsee: my jabber.org acc doesnt works aswall
<Tesla|Work> Hobbsee: they have ALOT of problems late... um... month
<Hobbsee> Tesla|Work: s/month/years/
<StevenK> Morning pitti
<Hobbsee> but fair enough
<Tesla|Work> hehe
<pitti> Good morning
<LaserJock> ahhh, now we're getting somewhere
<evand> morning pitti!
<tonyyarusso> Oh, hey pitti
 * Hobbsee tries to figure out how to unignore joins in irssi.
<tonyyarusso> Hobbsee: /unignore #channel JOINS, I think?
<Hobbsee> tonyyarusso: ah, you rock.  i was using /ignore, thinking it toggled.
<tonyyarusso> aah
<tonyyarusso> well that was a short visit from pitti
<Fujitsu> Hobbsee: Pidgin does suck, but I don't use jabber.org.
<LaserJock> I do
<LaserJock> they say it's supposed to be stable
<Hobbsee_> right
<LaserJock> but I always have problems with it
<Fujitsu> `service unavailable' for you from my Jabber server, so I presume jabber.org is dead, yeah.
<tonyyarusso> pitti: btw, did you catch my hilight from earlier?
<Tesla|Work> disk problems on jabber.org afaik
 * Tesla|Work is going to swithc to jabber.ru
<Artemis3> as usual, jabber.org is not working, nothing unusual since its inception
<pitti> tonyyarusso: no, I don't think I did, sorry; had some connection troubles
<tonyyarusso> pitti: Okay.  I was wondering if you or anyone else from the release team would be willing to pop into #ubuntu-release-party do officially deliver the news when Gutsy is ready.  We could +m it and such, make it all official-like so people can recognize when it's finally for real after lots of false prophets.
<LaserJock> good idea
<pitti> tonyyarusso: oh, by all means; can you make is so that slangasek and me can change the topic there?
<Artemis3> but fix the names in torrent.ubuntu.com:6969 first!
<tonyyarusso> pitti: certainly.  You can also just swing by #ubuntu-ops if you need anything else.
<pitti> tonyyarusso: great
<jcastro> pitti's our man!
<tonyyarusso> pitti: err, why doesn't slangasek have a cloak?
<Tesla|Work> would you recommend to DL 7.10 form torrent instaed of mirrors? ;-)
<Artemis3> they are to dense for that, tried in the last 3 releases already :P
<StevenK> Maybe pitti and slangasek need canonical/cabal cloaks
<pitti> tonyyarusso: he should ask for one, right
<tonyyarusso> pitti: yeah
<Hobbsee> pitti: the question is - does he become a member just by becomming a canonical employee?
<pitti> Hobbsee: no, but tonyyarusso didn't mention that he needs to get an *ubuntu* cloak
<LaserJock> I thought he did have a cloak
<LaserJock> I swear I saw one the other day
<Hobbsee> pitti: this is true.
<pitti> /canonical/release_man_in_charge :)
<LaserJock> it wasn't an Ubuntu one
<LaserJock> hehe
 * Fujitsu thinks we need the usual `no pony for you' photo, with a gibbon instead.
<StevenK> Muahaha
<tonyyarusso> Hobbsee: I just would prefer not to have things in access lists that are nick-linked, providing no guarantee of even being identified with services.
<Hobbsee_> tonyyarusso, true.
<Hobbsee_> tonyyarusso, oh, i thought they had to be identified to op at all
<LaserJock> Fujitsu: totally!
<LaserJock> "no Gibbon for you"
<Fujitsu> Yeah.
<LongPointyStick> tonyyarusso, no, does require a p/w
<LongPointyStick> Password identification is required for [OP]
<LongPointyStick> Type /msg NickServ IDENTIFY <password> and retry
<tonyyarusso> LongPointyStick: oh yeah?  good.
<LongPointyStick> yup
<LongPointyStick> it'd be a bit stupid otherwise, y'know...
<tonyyarusso> ya
<LaserJock> phew
<LaserJock> now I have a headache
<Fujitsu> Heh.
<tonyyarusso> pitti, slangasek: Might be useful to give the ops a quick heads-up before you do, perhaps.  Topic-changing and such around the Ubuntuniverse.
<pitti> tonyyarusso: IOW, ask in #ubuntu-ops?
<tonyyarusso> pitti: yeah
<tonyyarusso> pitti: while we're at it, what are the odds I'll miss the fun if I go get about 6 hours of sleep right now?  :P
<pitti> tonyyarusso: pretty high, I'd say
<sladen> tonyyarusso: oy, stop trying to cheat the system.  You have perfect free will if you dare^Wwant to go to sleep
<tonyyarusso> nuts.  why can't y'all tailor a release to my timezone some day!  ;)
<tonyyarusso> sladen: Yeah, the last few I've ended up all-nighter-ing it anyway, and they've been at like 6 AM
<sladen> tonyyarusso: that is one *hellva* long time to wait for a release
<tonyyarusso> sladen: :)
<LaserJock> pitti: so I'm thinking of a number between 1 and 3, could that number be the time until release? ;-)
<tonyyarusso> LaserJock: In what units?
<LaserJock> hrs, lets say
<pitti> LaserJock: of course it *could* be :)
<sladen> pittifully small ones
<tonyyarusso> haha, good answer
<LaserJock> hmm
<pitti> sladen: why? 3 days should really be enough :-P
<tonyyarusso> I told website-matt that he should make the counter say 2 days left just for like 10 minutes and see what happened in -release-party ;)
<LaserJock> haha
<sladen> it's like racing FedEx "Guaranteed 12:00 delivery by ... well, *sometime* in next week"
<LaserJock> tonyyarusso: you should change the drunken release managers thing
<tonyyarusso> LaserJock: to?
<LaserJock> not sure, but now that pitti is up it doesn't seem right ;-)
<tonyyarusso> oh, just so he knows what we're talking about:
<ScottK> pitti: Care for a bit of archive admining for backports while we wait (dunno how busy you actually are ATM)?
<tonyyarusso> !hungover | pitti (courtesy of Hobbsee)
<ubotu> pitti (courtesy of Hobbsee): The Release Managers are currently hungover, and wont be releasing gutsy today.  No gutsy for you!  NOT YOURS!!!
<LaserJock> oh man, my dissertation is never gonna get done
<LaserJock> night folks
<LaserJock> have fun
<pitti> Hobbsee: :)
<sladen> ScottK: best. line. ever.
<pitti> ScottK: can do, yes; I'll have a look a bit later
<ScottK> Bug #151308 for Feisty and Bug #153378 for Feisty and Edgy
<ubotu> Launchpad bug 151308 in feisty-backports "please backport Clamav from Gutsy to Feisty " [Wishlist,Fix committed] https://launchpad.net/bugs/151308
<ubotu> Launchpad bug 153378 in feisty-backports "please backport pypolicyd-spf 0.4.1-1 from Gutsy to Feisty and Edgy" [Wishlist,In progress] https://launchpad.net/bugs/153378
<ScottK> pitti: ^^ thanks.
<ScottK> pitti: And then two packages in Bug #153287 for dapper.
<ubotu> Launchpad bug 153287 in dapper-backports "Please source backport pyspf 2.0.4-1/pypolicyd-spf 0.4.1-1 from Gutsy to Dapper" [Wishlist,Fix committed] https://launchpad.net/bugs/153287
<Hobbsee> elmo: started the torrents yet?
<pitti> ScottK: noted
<Hobbsee> pitti: people have found the images
<ScottK> Hobbsee: I don't think pitti saw that.
<tonyyarusso> Hobbsee: Remove then if they post links in #ubuntu or #ubuntu-release-party (and in case you didn't notice, he missed that due to disconnect)
<Hobbsee> tonyyarusso: i cant.  i dont have admin rights over the forums these are on :)
<Hobbsee> may as well tell them to seed though
<Hobbsee> if the tracker is not being an utter pain (as usual) thiat is
<Artemis3> ever heard the phrase: genie is out of the bottle?
<tonyyarusso> Hobbsee: Forums?  Ah crud
<Hobbsee> tonyyarusso: no, not those ones.
<Hobbsee> tonyyarusso: clearly you werent at UDS, anyway
 * Hobbsee hides from pricey
<Artemis3> im tyring to drive people way from .pool .... and torrents do help
<tonyyarusso> Hobbsee: no, I'm not nearly special enough for UDS.  Explain?
<Hobbsee> pitti: are you aware that someone forgot to change /proc/version?
<Artemis3> im betting the torrents will change since you messed the names of the .iso tho
<Hobbsee> or is that the gcc prerelease?
<pitti> Hobbsee: what do you want to have changed there?
<pitti> Hobbsee: (and no, we *won't* update Gutsy to 2.6.23 :) )
<Hobbsee> pitti: still says prerelease - but i'm assuming that's of gcc, not ubuntu
<Hobbsee> hahaha, no.
<pitti> right
<StevenK> Hobbsee: The version in /proc/version is gcc
<Hobbsee> but lets have a crack kernel, just for teh hell of it!
<Hobbsee> tonyyarusso: ask pricey.  he'll tell you.  mention that it was about planet editorial policy
<tonyyarusso> Hobbsee: oh boy :S
<Burgundavia> oh bloody hell that spec
<Hobbsee> haha :)
<Burgundavia> I still haven't finished that
<Burgundavia> really need to one of these days
<Hobbsee> yes you do
<Burgundavia> given we almost had another issue with the naked Spanish magazine cover
<Burgundavia> ugh
<Burgundavia> why can't life just be fun, with bunnies and ponies?
<Fujitsu> Burgundavia: You mean with gibbons?
<Burgundavia> no, bunnies and ponies
<tonyyarusso> Burgundavia: naked Spanish magazine?  what?
<tonyyarusso> @pony Burgundavia
<Burgundavia> tonyyarusso: http://www.guardian.co.uk/spain/article/0,,2131498,00.html
<Burgundavia> there was some concern about the cartoon nakedness
<Burgundavia> ugh, I don't want to talk about it
<Burgundavia> ponies and bunnies, dammit!
<sladen> nekkid ponies and bunnies!
 * tonyyarusso gives Burgundavia a bunny, but ubotu says no ponies
<Hobbsee> slangasek: did you manage to find a good quote, btw?
<jcastro> wait, Burgundavia, you were on some magazine cover naked?
<Burgundavia> jcastro: yes, me, jorge
<Burgundavia> it was hideous
<jcastro> I knew it
<slangasek> Hobbsee: I am looking at you blankly as if with no memory
<Burgundavia> I miss you so much, so I had to declare my love for you publicly
<tonyyarusso> Burgundavia: at least it wasn't mneptok
<Burgundavia> and look, you came back to us
<pwnguin> http://www.apple.com/macosx/features/300.html
<Hobbsee> slangasek: but you must have a good quote for the final release!
<pwnguin> you know, i gotta say, gutsy's doing pretty well
<sladen> Burgundavia: you just can't get the models these days!  http://jriddell.org/photos/2007-05-sevilla-paul-jonathan-sarah.jpg
 * Hobbsee thwacks slangasek 
 * Hobbsee thwacks sladen 
<tonyyarusso> rofl
<Burgundavia> my eyes, please sladen
<tonyyarusso> That should be the CD cover ;)
<Burgundavia> pwnguin: fridge.ubuntu.com <-- 10 Rocking Features in 10 Days
<Fujitsu> tonyyarusso: YES!
<Burgundavia> there is your answer
<pwnguin> heh
<pwnguin> 10 vs 300 =(
<Burgundavia> nobody cares about 300 random useless features
<pwnguin> you mean like apparmor? :P
<tonyyarusso> Fujitsu: At least then I'd finally know who the heck the people in the picture were, or at leas one of them.
<Burgundavia> people care about their 1 (or 2) features
<Burgundavia> pwnguin: if I ran a large enterprise app, apparmor or selinux would make me happy
<slangasek> Hobbsee: I don't understand why, *everything* I say is clever and quotable
<Hobbsee> slangasek: including openCubicle, yes.
<Burgundavia> for that matter, apparmor + ltsp is a good win
<pwnguin> Burgundavia: anyways
<Burgundavia> although, pwnguin, if you want to some brownie points: https://wiki.ubuntu.com/7%2e10Tour#preview
<Burgundavia> finish that in the next 2 hours
<pwnguin> my point was, a lot of those 300 are already in 7.10
<pwnguin> cups 1.3
<pwnguin> virtual desktops
<pwnguin> ie workspaces
<sladen> Burgundavia: now you need a post that the "it goes up in 11"
<jcastro> Burgundavia's features don't require you to buy a new computer.
<Burgundavia> cause I don't break people
<Burgundavia> 's computer with my hideous visage, having posed naked and all
<Burgundavia> you are a cruel, cruel man, sladen
<pwnguin> Burgundavia: sadly, i turned compiz and tracker off
<ScottK> pwnguin: Why sadly?
<pwnguin> and i dont think app armor got enabled on my laptop's upgrade
<sladen> "sadly"
<pwnguin> ScottK: its hard to take screenshots
<ScottK> pwnguin: It almost certainly did.
<pwnguin> everyone says that
<ScottK> pwnguin: Well with Tracker enabled it'd take forever to take screenshots, so it's no great matter.
<pwnguin> jldugger@jldugger-laptop:~$ dpkg -l | grep apparmor
<pwnguin> jldugger@jldugger-laptop:~$
<pwnguin> by my estimation, that indicates something apparmor related is not installed
<ScottK> Agreed.  Why not install it then?
<pwnguin> doesn't interest me much
<ScottK> Ah.  Then no great loss.
<pwnguin> im partly worried it'll be a nuisance
<ScottK> You can always remove it.  It's been transparent for me.
<pwnguin> to me, the bigger news story is the semi dissapearance of the laptop team =/
<tonyyarusso> We lost a team?  Did we send a search party?
<Burgundavia> in what sense?
<pwnguin> in the sense that i havent seen any activity in my digging. granted im not qualified to call it dead
 * ScottK having just mailed $REPORT to $CUSTOMER is going to bed.  Good night all.
<sladen> tonyyarusso: the search party is in #ubuntu-release-party though I don't think they've found anything yet
<Fujitsu> Night ScottK.
<tonyyarusso> sladen: Nor do I think they're looking.........  I've trained for searches before, and that crowd isn't anywhere near organized enough
<pwnguin> the only thread on laptop devel ML since June was the one i started on power consumption
 * Fujitsu waits for one of the RMs to head into #-release-party and ask when the release is.
<pwnguin> and even the only message in june was someone quitting the team
<StevenK> Fujitsu: Now that would be cool.
<Burgundavia> pwnguin: laptop-devel was an attempt to create a cross-distro place to talk about laptop issues
<Hobbsee> Fujitsu: heh, why?
<StevenK> Hobbsee: I suspect because everyone is asking
<minghua> Just out of curiosity -- What are we waiting for now?  Building ISOs?
<Fujitsu> minghua: Mirrors, I believe.
<Hobbsee> minghua: website to wake up, i think
<Hobbsee> minghua: and the pushing of the Big Red Button
<minghua> Oh, so we pre-sync to mirrors before announcing?
<Artemis3> as usual
<minghua> I was just told otherwise yesterday.
<Fujitsu> minghua: Yeah, or everything blows up.
<Artemis3> also, as usual (being told otherwise)
<tonyyarusso> Hobbsee: speaking of which, I had a friend ask if there was actually a Big Red Button, who would be very please if you would say someone slapped together a little GTK interface with such a thing
<minghua> But I was told by a mirror admin, so I believed him, assuming he knows what he is talking about.
<Hobbsee> tonyyarusso: haha
<Fujitsu> minghua: Hm, that is odd.
<Hobbsee> tonyyarusso: yeah, but it might be done as a command line, depending.
<Mithrandir> tonyyarusso: then we'd of course have to have a Qt app for releasing kubuntu.
<tonyyarusso> Mithrandir: of course
<Hobbsee> minghua: we tend to, if we can, afaik, yes
<pwnguin> Burgundavia: so then its not a list for the ubuntu laptop team?
<minghua> I see, thanks everyone for explaining.
<Fujitsu> Mithrandir: Haha.
<torkel> tonyyarusso: http://www.85qm.de/up/BigRedButton.swf
<tonyyarusso> hehe
<pwnguin> Burgundavia: it may be that the kernel team has sort of absorbed the bulk of the effort
<cjwatson> LaserJock: FWIW I'd advise against writing "Copyright (C) Canonical Ltd." in things you write unless you have a contract with Canonical that lays out what we can do with your work
<cjwatson> LaserJock: I don't know the exact legal situation, but I've certainly heard others recommend against using another organisation's name in a copyright message unless you have a signed legally-approved assignment in place
<Fujitsu> Ooh, somebody told Mithrandir off. Brave.
<Hobbsee> Fujitsu: are they still alive?
<tonyyarusso> .........
<tonyyarusso> gutsy-changes claims a new version of opera was just uploaded
<Fujitsu> tonyyarusso: It probably was.
<Fujitsu> partner is special.
<tonyyarusso> Fujitsu: That's allowed?
<tonyyarusso> oh
<ScottK> And then there's bug #153798 too.
<ubotu> Launchpad bug 153798 in launchpad "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798
 * ScottK quits hawking $HISPETBUG and really goes to bed.
<cjwatson> should be on soyuz
 * cjwatson moves it
<StevenK> Morning cjwatson
<cjwatson> morning
<minghua> That red button flash has a long story to tell...
<tonyyarusso> minghua: yeah...
 * tonyyarusso got through the whole thing
<AnAnt> Hello, if I use reportbug will it report to Ubuntu or Debian ?
<Burgundavia> it will go the ubuntu-users mailing list
<AnAnt> Burgundavia: won't reportbug send to LP too ?
<Burgundavia> I don't think so
 * Hobbsee heads out to the sydney release party.  have fun everyone!
 * StevenK does too
<AnAnt> when's the release ?
<Burgundavia> when the release happens
<AnAnt> there are serious bugs in the kernel
<Burgundavia> file them
<AnAnt> no one even responded to a bug that makes my laptop crash, although I submitted it weeks ago
<AnAnt> I did file it
<Burgundavia> we get a lot of bugs
<ScottK> AnAnt: What bug?
<AnAnt> bug #146151
<ubotu> Launchpad bug 146151 in linux-source-2.6.22 "Random hangup on HP Pavilion dv6391 when system beep" [Undecided,New] https://launchpad.net/bugs/146151
<minghua> AnAnt: If it only affects you, then probably it's not serious (in a general sense).
<AnAnt> minghua: well, no one decided that it's a duplicate of any bug, nor did anyone say, I have the same problem too
<minghua> AnAnt: I am not saying there isn't a bug, I'm just saying it's not as serious as you say.
<AnAnt> minghua: ah, I see
<ScottK> AnAnt: Does this happen when you are using noapic irqpoll noirqdebug as you mentioned in Bug #103273?
<ubotu> Launchpad bug 103273 in linux-source-2.6.22 "booting HP Pavilion tx1020 laptop requires noapic kernel option" [Medium,Confirmed] https://launchpad.net/bugs/103273
<AnAnt> ScottK: I don't think so, because in that case beep doesn't even work
<AnAnt> ScottK: btw, I think that 103273 was for AMD64 not i386
<AnAnt> ScottK: also I can't use those options as my nvidia won't work IIRC
<ScottK> OK.  It sounds to me like you haven't made a clear, complete discussion of what your problem is in the bug then.  In #103273 you said you needed to use noapic irqpoll noirqdebug and now you say your video doesn't work if you do that.
<AnAnt> ScottK: on 103273, I was on amd64, there isn't a restricted nvidia driver there (at least restricted manager doesn't say so)
<ScottK> OK, so it's two different laptops?
<AnAnt> ScottK: on 146151, it was on using i386 ubuntu
<ScottK> OK.
<AnAnt> ScottK: same laptop, using different ubuntu versions
<AnAnt> ScottK: I gave up on amd64 version because I wasn't able to run 32-apps on it
<ScottK> I see.  OK.
<AnAnt> ScottK: :s/32-apps/32-bit apps
<AnAnt> anyone knows about console fonts ?
<minghua> I know a *tiny* bit.
 * ScottK really goes to bed.  AnAnt I don't know what to tell you.  I file bugs that don't get a lot of response sometimes too.
<AnAnt> ScottK: ok
<minghua> Night ScottK.  (Though I think this is the third time you are going bed tonight :-)
<AnAnt> minghua: ok, I have a program called acon (it's on Ubuntu btw), the upstream has coded a console font in the C code
<ScottK> Third, maybe 4th.
<AnAnt> minghua: is there a way to convert that C code font into PSF ?!
<minghua> Hmm.
<minghua> AnAnt: There should be a way.  Whether it's easy or not, I don't know.
<minghua> After all, console fonts are just 1-bit bitmap fonts.
<cjwatson> AnAnt: there's a bdf2psf package
<cjwatson> oh, I misread you
<cjwatson> good grief, what a crazy way to do it
<AnAnt> cjwatson: well, that program was coded in 1999 or maybe even before
<minghua> cjwatson: More crazy than embedding XPM in C code?
<cjwatson> you could just load it and use consolechars' facility to save the old console font to a file :-)
<cjwatson> conversion via video memory ...
<cjwatson> the -F option
<AnAnt> cjwatson: I tried to do that using kbd-compat, it failed, saying that it was made to convert 256 characters, while the loaded font uses 512 characters
<AnAnt> cjwatson: you think consolechars will work ?
<cjwatson> you might need to use kbd rather than kbd-compat
<cjwatson> but you can try consolechars
<cjwatson> I don't have time to follow all the codepaths through right now to check
<carlos> pitti: Before I forget, next Launchpad code update includes the patch that will allow automatic translation imports from restricted component
<pitti> carlos: ah, so far you imported them manually?
<carlos> pitti: well, as far as I know, only restricted-hardware was there and you provide me with its updates, do you remember it?
<pitti> carlos: right
<carlos> pitti: s/restricted-hardware/restricted-manager/
<pitti> (restricted-drivers)
<pitti> erm, -manager
<carlos> :-P
<sabdfl> HAPPY RELEASE DAY everybody :-)
<tonyyarusso> sabdfl: right back at you :)
<sabdfl> and what a glorious day it is in London, too
<pitti> sabdfl: and to you!
<tonyyarusso> Figures, glorious in London and rainy and foggy all week in Minneapolis
<sladen> tonyyarusso: same answer we keep giving to Hobbsee... "move to Europe" and all your problems will be sorted :)
<tonyyarusso> sladen: I believe me, I'd like to.  Not London though - one of the Nordic countries.
<lukketto> sabdfl: and to you ;)
<sladen> tonyyarusso: you're in luck, I can report that Helsinki is beautiful and sunny today aswell
<Burgundavia> well, I need to sleep
<tonyyarusso> sladen: can you get me immigration papers?
<Burgundavia> have fun with the release all
<pwnguin> huh
<pwnguin> what replaced pmount?
<cjwatson> gnome-mount
<cjwatson> and the hal stack
<sladen> pwnguin: hal + gnome-mount
<pwnguin> some time ago i gather
<pitti> pwnguin: in feisty
<pwnguin> i just noticed it on the list to be removed list
<pwnguin> as unsupported by canonical
 * pitti does a quiet sob
<liw> poor pitti
<pwnguin> it was good stuff
<pwnguin> but such is the mark of progress  -- creative destruction
<liw> I liked pmount when I first saw it, and I still prefer it's command line interface over that of gnome-mount
<pitti> pwnguin: I found someone in Debian who continues to maintain it
<pwnguin> heh
<pwnguin> well, as long as theres a replacement, i dont mind
<pwnguin> my usage has basically been plugging in usb thumb drives
<pwnguin> the end
<pwnguin> maybe cds
<Mithrandir> gnome-mount doesn't have a command line mode, does it?
<pitti> Mithrandir: it does
<pitti> Mithrandir: e. g. gnome-mount -d /dev/sda1
<pwnguin> Mithrandir: maybe if you use the right dbus command ;)
<Mithrandir> oh, nice.
<pitti> or gnome-{eject,umount}
<pitti> Mithrandir: useful for debugging, too, if you invoke it as gnome-mount -vbd /dev/sda1
<liw> when pmount went away, I had to learn about gnome-mount's cli, so as to fix my script to ssh-add a key from a usb stick
 * Mithrandir hugs his gpg card with ssh keys on it.
<davmor2> Mithrandir: :P
<davmor2> git
<Mithrandir> ?
<Mithrandir> it's quite useful
<sladen> davmor2: ssssh.  "bzr" around here   *nods*
<davmor2> sladen: why? Sssssssshhhhh
<liw> I don't have smart card reader, the usb stick is good enough for me
<davmor2> liw: I just used lvm encrypted about a 100 time yesterday :)
 * pwnguin just wishes his SD reader on his laptop worked. it worked for like one release
 * davmor2 lends pwnguin my sledgehammer give it a tap it'll work :)
<pitti> ScottK: all done; I also cleaned all the NEW stuff in backports while I was at it
<LaserJock> cjwatson: ok, thanks for the advice. I was uncertain about it but was "going with the flow"
<cjwatson> the flow of stuff done by Canonical employees, I'm guessing :)
<LaserJock> yes
<LaserJock> when I started working in Main
<Riddell> quiet here this morning :)
<ogra> yeah :)
<LaserJock> Riddell: #ubuntu-release-party has got a lot more action if you're bored :-)
<tonyyarusso> Riddell: It helps balance out urp
<davmor2> Riddell: I can kick your shins again if you want :)
 * tonyyarusso wonders why they don't turn off indexing in apache for release times - it would save us a lot of headaches on IRC
<davmor2> Riddell: if you really want to see fun release and watch the frenzy :D
<davmor2> Riddell: By the way thanks for the mention :)
<Riddell> davmor2: there really is fame and glory for our developers!
<davmor2> :D
<tonyyarusso> cjwatson: Is there a particular reason apache indexing is allowed to create all this confusion right now?  Does rsync require it?
<cjwatson> tonyyarusso: I doubt it would make any difference; the HTML headers have to go out too
<cjwatson> and they link to all the files
<cjwatson> the confusion is really just entertaining noise, I don't view it as significant in the grand scheme of things
<tonyyarusso> cjwatson: Really?  Well, if you don't mind I guess I can't complain as much, but personally it would be nice if they just got 403 errors instead of a list of disk images :)
<cjwatson> tonyyarusso: we'd then have to do *another* mirror sync pass to turn indexing back on
<cjwatson> which we'd have to wait for
<tonyyarusso> cjwatson: Ah, bummer.  nvm then
 * tonyyarusso doesn't really understand the infrastructure stuff
<cjwatson> it's just one of those things with a mirrored distribution network, you get a period when it's "leaked" in some sense
<LaserJock> cjwatson: how long does it take to get an .iso out to all the mirrors, roughly?
<cjwatson> LaserJock: the actual ISOs went out overnight
<cjwatson> LaserJock: but, well, "it depends" - there are a lot of mirrors on wildly varying links. We pre-publish well in advance to allow many hours for it
<cjwatson> the way that the pre-publication process works, we can still make small changes to the ISOs and subsequent "re-pre-publication" will be quicker by the magic of rsync
<LaserJock> ah, right
<LaserJock> so then what determines when the "official" release happens? website stuff or Mark giving a "green light"
<LaserJock> or waking up to find that everything's ready?
<pwnguin> its not an official release until the first upload to fix whatever is horribly broken
<minghua> LaserJock: I suppose it's safe to say it's released when a mail is sent to -announce.
<LaserJock> sure
<LaserJock> but I'm wondering how it's determined that it's time to send the email
<davmor2> pwnguin: that'll be the xorg-intel driver then :)
<LaserJock> or maybe what's the biggest bottleneck
<pwnguin> the slowest official mirror, id wager
<cjwatson> LaserJock: ReleaseProcess
<Kano> hi, is today the release of gutsy or will it be delayed?
<LaserJock> cjwatson: oh, how handy ;-)
<dholbach> Kano: ubuntu.com does not look like that
<tonyyarusso> Kano: Announcement the moment of will take place in #ubuntu-release-party.  At this time all systems look to be go for soon today.
<Kano> well basically i only want to know if the kernel will change before release or not
<dholbach> Kano: no very likely not, maybe through -updates though
<cjwatson> Kano: the kernel will not change
<Kano> ok, then i will use current u kernel as base
<Kano> i dont like to use it and next day there is another one online..
<pwnguin> base for what?
<Kano> kanotix kernel, i need just a different config
<amitk> Kano: do you follow the kernel git tree or the source package?
<Kano> as all patches which i reported are in it - expect one special one for lum
<Kano> for releases i usually prefer to use source packages
<Kano> in case of problems i test git
<Huff> will the derivatives be released simultaneously with Ubuntu gutsy?
<cjwatson> Huff: yes
<Kano> hmm final release seems to be online. ok then i can use the kernel ;)
<Huff> sorry wrong channel don't mean to bother
<Kano> ab it sad that the ati xserver is broken for my x700se
<Kano> but i use that card basically for fglrx testing anyway
<tormod> kano, you can use the 6.6 driver linked in the release notes.
<Kano> 6.6?
<tormod> the -ati driver 6.6.something
<Kano> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/151974
<ubotu> Launchpad bug 151974 in xserver-xorg-video-ati "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Confirmed]
<Kano> thats what i mean
<tormod> Kano: I know
<Kano> i think ati cards dont like intel chipsets
<Kano> thats the 2nd card that does not init after ati driver was used with fglrx
<Kano> mainly i test fglrx...
<Kano> currently fglrx is so borken that restarting the xserver stops the system
<Kano> really fun to write fglrx install scripts
<Kano> with my older nforce3 system that did not happen, just with that pci-e one...
<tormod> Kano: "ati driver was used with fglrx" ?
<Kano> tormod: well when you install fglrx without reboot
<Kano> when the card was first used by ati
<Kano> usually you unload radeon + drm module and all is fine
<tormod> Kano: I see. Like when testing with a live CD.
<Kano> i did not install ubuntu
<Kano> i only use parts of it
<Kano> maybe i do and compile some things i need
<Kano> i compiled full kde 3.5.8 lately for etch, that was real fun ;)
<Kano> at least i can stip this step for gutsy
<Kano> for your next system i would highly advice to update ffmpeg
<Kano> thats the biggest drawback compared to other systems
<Kano> for h264 you need latest code
<sladen> Kano: https://launchpad.net/ubuntu/+source/ffmpeg/+filebug  and justify what updates are required, and why, if they are needed
<minghua> I doubt filing bugs against ffmpeg and ask for update really helps...
<RAOF> Pity they don't have a bugtracker - then you could file a bug upstream asking for some kind of release this decade :).
<Kano> since one week PAFF decoding should work, that was missing for ages...
<Kano> http://ffmpeg.mplayerhq.hu/
<sladen> minghua: it's hopefully slightly more effective than letting the request scroll off the top of the screen on IRC
<Kano> also h264 should now work multithreaded, for hd res thats a requirement
<minghua> sladen: True.  But I doubt the difference matter.  My feeling is just nobody dare to touch ffmpeg.
<Kano> i dislike using coreavc for that...
<Kano> even if there are patches to use it
<Kano> https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/153858
<ubotu> Launchpad bug 153858 in ffmpeg "update to current svn for better h264 support" [Undecided,New]
<ln-> does anyone read and/or care about kernel-related bug reports?
<ln-> this one, in particular: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Undecided,Confirmed]
<Kano> do you really still use 2.6.15?
<Kano> with that i would just blacklist skge and compile new sk98lin
<ln-> that's the one that comes from apt for Dapper.
<minghua> ln-: Have you tried a later version?
<minghua> like, feisty or gutsy?
<Kano> i am using skge all the time with newer kernels...
<ln-> minghua: no, but i have tried the patch attached to that bug report, and it does fix the problem.
<ln-> but the thing is, we've got four or five similar computer here at the office, and after each kernel update from apt I have to replace the skge driver on all of them again.
<Kano> well when you have got lts you maybe better fix it ;)
<minghua> ln-: I suggest you ask in #ubuntu-kernel and see if it's possible to have an update for dapper.
<Keybuk> the glibc "double free detected" panic has to be the most useless thing in existance
<Keybuk> why can't it just abort() so I can catch it in gdb and see *what* I'm double-freeing
<ln-> the silly thing is, there have been about four updates to dapper kernel after that bug was reported, so there would have been chances to fix it in one of them... but ok, i'll try #ubuntu-kernel.
<cjwatson> Keybuk: MALLOC_CHECK_=2
<Keybuk> cjwatson: that does the abort() somewhere inside libc with no useful stack trace
<Keybuk> ie. you can't see which free() it was
<sladen> if you do MALLOC_CHECK_=3, does it warn you about triple-free()s  ;-)
<minghua> sladen: I'm actually more interested in what MALLOC_CHECK=1 do...
<cjwatson> malloc(3)
<minghua> cjwatson: Thanks.
<Fujitsu> Oh dear, who stuffed the website?
<Fujitsu> It's coming soon *and* released on the same page.
<ajmitch> heh
<minghua> I don't see anything mentioning released.
<Fujitsu> Ah, reverted.
<Fujitsu> Like last time, IIRC.
<Kopfgeldjaeger> hi
<ScottK> pitti: Thanks for taking care of the backports.
<pitti> ScottK: yw
* slangasek changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 7.10 released!
<persia> Shouldn't that be "...even with Hoary...", or does that wait for archive open?
<Fujitsu> persia: Hardy, you mean?
<persia> Umm.  Yes.  The other H* release
<cjwatson> persia: doesn't make much difference until the archive opens :)
<persia> cjwatson: Right.  Makes sense.  Thanks.
<cjwatson> (which will be a little while)
<akrill> curiosity: when is the vote on 8.10's name? ;-)
<cjwatson> it's not a vote
<cjwatson> Mark picks it
<akrill> ah, i see
<stdin> you mean Hardy ?
<akrill> no, Hardy = 8.04.
<akrill> i'm talking the one after than, 8.10 ;-)
<akrill> *that
<stdin> oh yeah, my mind is like jelly at the moment :p
<akrill> i'm thinking Itchy Iguana. :-p
<akrill> anyway. im off to bed. night all
<pochu> congrats for this great release! you guys ROCK!
<tonyyarusso> I'm going for Intrepid Impala myself.  /me hopes the powers that be are listening ;)
<pitti> mvo: do you have a feisty at hand? does update-manager find the release notes? there are some complaints in #urp
<mvo> pitti: I checked it and it worked after I flipped the swtich, I can retry, sec
<pitti> mvo: ok, thanks; let's blame the server banging then, if it generally works
<tormod> the formatting of commands got lost in http://www.ubuntu.com/getubuntu/releasenotes/710
<mvo> pitti: works for me, I tried with and without local proxy
<mvo> pitti: downloading the upgrader is a bit on the slow side :)
<mvo> pitti: but it finished successfully
<stgraber> uploading at 60MB/s on bittorrent :)
 * pitti hugs mvo, thanks
<mvo> stgraber: impressive :)
<stgraber> 6x100Mb/s :)
<stgraber> I'll just have to look a bit at our quotas (7TB/month)
<stgraber> at this speed the quota will be used in less than a day
<Fujitsu> Ouch.
<cjwatson> tormod: reported, thanks
 * persia requests a mention of 7.10 at the bottom of http://www.ubuntu.com/getubuntu/downloadmirrors
<cjwatson> persia: reported, thanks
<persia> cjwatson: Thanks.
<cjwatson> persia: 13:21 <@newz2000> its updated, give it a few min to clear the cache
 * persia celebrates
<Pici> Congrats everyone :)
<Whoopie> To all of you: WELL DONE!
<Mithrandir> doko: do I need to do anything more than install icedtea-plugin to get java plugin on amd64?
<doko> Mithrandir: you need to rebuild it yourself, or install it from ...
<doko> #deb http://people.ubuntu.com/~doko/ubuntu gutsy/
<doko> #deb-src http://people.ubuntu.com/~doko/ubuntu gutsy/
<Mithrandir> doko: why's that?
<doko> https://bugs.edge.launchpad.net/ubuntu/+source/icedtea-java7/+bug/152362
<ubotu> Launchpad bug 152362 in icedtea-java7 "icedtea-java7-plugin always crashes firefox" [High,Confirmed]
<doko> help appreciated ...
<Mithrandir> it doesn't crash for me, it just fails to start
<doko> start firefox from a console, and you'll see that it crashes
<doko> firefox itself doesn't crash
<Mithrandir> ahkay
<Mithrandir> that page seems to have older .debs than what's in gutsy?
<kagou> Congratulations ! Bravo !
<doko> Mithrandir: ahh, yes, but they work =) I'll update to b22 soonish, but that doesn't fix things yet
<Mithrandir> doko: heh, ok. :-)
<warsocket> hi ppl i have short a question about launchpad and registerig a blueprint, is the the right channel fo this (have a blueprint for installation of 3rd party non repo apps)
<soren> warsocket: Depends... If it's about using launchpad correctly, #launchpad might be more suitable. If it's about the details of the contents of your ubuntu blueprint, this might be the right channel.
<warsocket> k I have an idea oh how to install appliocations wich are not in the ubunu repo
<warsocket> and i could work on nummerous of those apps wich ahvent even heared of my project
<warsocket> but
<warsocket> if i register my blueprint fo the whole idea at launchpad
<warsocket> Am I then obligated to program the whiole project myself
<warsocket> or is it possible that someone else programs my blueprint
<warsocket> ?
<warsocket> and if I acan program a part of it, will I get help or should i finf my own team?
<BenC> pitti: linux-source-2.6.15 29.61 uploaded to dapper-proposed
<BenC> pitti: that's everything from my end
<pitti> BenC: how, -proposed? I thought -updates due to the ABI skew?
<BenC> pitti: doh
<pitti> BenC: there weren't any fixes in initramfs after all?
<BenC> can I upload directly to -updates?
<pitti> BenC: yes, you can; we just don't do it normally
<BenC> pitti: I uploaded initramfs-tools, udev and linux-meta last night
<pitti> ah, I see
<pitti> BenC: -meta?
<BenC> pitti: needed linux-backports-modules-* meta packages
<pitti> ah, of course
<cjwatson> warsocket: if you aren't likely to contribute a good chunk of it yourself, it would be better to look around for existing projects first and try to join up with one of them rather than starting your own effort
<cjwatson> warsocket: it's relatively rare for people to pick up other people's blueprints, because the people likely to develop large chunks of them already have lots on their own lists :-)
<BenC> pitti: re-uploaded to -proposed
<pitti> BenC: -updates, I assume :)
<BenC> shit, yeah, -updates :)
<pitti> BenC: thanks a lot
<Mithrandir> doko: at least 7~b21-1.4+20071007-0ubuntu1 is still broken.  Do you remember which one works?
<sladen> warsocket: the secret is to document your idea, and then pursuade other people that it's such a good idea that they will help you  (but probably not by spamming people with alot on their plates already
<mhb> pitti: by the way, not sure if you've heard, but I won't be at the uds, usa denied me a visa.
<pitti> mhb: hi; yes, I heard about it yesterday; how unfortunate :(
<pitti> mhb: I had looked forward to meeting you
<mhb> pitti: yes, well... you can imagine I did, too.
<pitti> mhb: weird that you even need one, as an EU citizen
<mhb> pitti: yes, they treat Czech Republic inequally.
<mhb> pitti: also, they kind of ignored that I have an invitation letter.
<mathiaz> pitti: well - it doesn't really matter that you're a EU citizen when you deal with the US.
<mathiaz> pitti: you actually don't have a EU passport (but a german, french, etc...)
<mhb> pitti: I'll help you with restricted-manager rewrite regardless.
<pitti> mathiaz: right; I just had assumed that the visa waiver program applied to all EU
<pitti> mhb: that would be great; I still sub'ed you to the spec, I hope we can discuss it over phone or IRC
<mathiaz> pitti: nope - it's on a per country basis.
<doko> Mithrandir: did you install -jre, -bin, and -plugin?
<Mithrandir> doko: yes.
<mhb> pitti: I saw that, thanks. I'll go read it.
<pitti> mhb: there's nothing on the wiki page yet
<pitti> just the skeleton
<Mithrandir> doko: it seems like it never starts anything, it shows the "click here to download plugin" replacement element
<doko> Mithrandir: are alternatives set correctly? see about:plugins ?
<soren> warsocket: You don't have to do all of it yourself, but the more you can do, the more likely it is to get done.
<soren> warsocket: You can start out be writing the specification in as much detail as you can to make it as easy as possible for other people to understand your idea and possibly help.
<Mithrandir> doko: ah, the alternatives were set wrongly.  Now I get a grey, dead bokx
<doko> Mithrandir: no output in the terminal, if you start firefox from there?
<Mithrandir> load: class no.sb1.detectorapplet.Detector not found.
<Mithrandir> ah
<Mithrandir> Caused by: java.security.NoSuchAlgorithmException: CertBundle KeyStore not available
<doko> Mithrandir: can you open classpath.org and see the stomping fork in the upper left corner?
<Mithrandir> doko: yes, that works.
<Mithrandir> doko: I would guess it's that it's trying to load a class over HTTPS and failing to find the CA certificate store
<doko> Mithrandir: yes, maybe some properties need to be adjusted, patches welcome =)
<pitti> BenC: tons of changes in tg3; has this new driver been tested on a production dapper already? if not, maybe we should test it in a PPA first?
<BenC> pitti: it's been tested from -proposed for quite some time
<pitti> BenC: ah, you took it from there? alright, that's pretty much what we wanted I guess :)
<soren> Gah, I'm tired of gutsy. When does hardy open?
<pitti> soren: using a stable release is sooo boring
<doko> even hardy is stable now =)
<zul> gutsy is so passe
<cjwatson> soren: NewReleaseCycleProcess says release+1day
<soren> pitti: Yeah, I can smell it rotting already. Let's get a move on, people.
<cjwatson> although, for the eagle-eyed, hardy seeds already exist ;-)
<soren> cjwatson: Uh, shiny!
<soren> Er, I mean: Uh, hardy!
<cjwatson> (it was something I could trivially do without disturbing anything else)
<pitti> and now for something entirely different: dapper.2!
 * soren hides again
<BenC> dapper.2 is for the truely hard core
<lamont> "s" so needs to be "shiny spaceship"
<lamont> "shiny serenity" fits even better.
<Treenaks> lamont: and after 'z', rollover to 'angsty astronaut'
<soren> Spaceships are good. We need it right after the ravenous rapor release.
<soren> raptor, of course.
 * lamont is saddened by the dearth of Firefly fans
<lamont> cjwatson: my mirror sync script is running too fast.  lets fix that. kthxbye.
 * lamont waits for trouncing
<pitti> BenC: the other patches look fairly straightforward to me
<pitti> BenC: the struct change in serial/usb-serial.h doesn't break ABI?
<doko> Mithrandir: b22 in my repo
<BenC> pitti: I would have thought so, interesting that it didn't
<pitti> BenC: in the sense of "abi checker should have caught that", or "it's not used anywhere else and this is alright"?
<BenC> pitti: in the sense that if the checker didn't catch it, it should be ok
<Mithrandir> doko: cheers, I'll poke it
<pitti> BenC: so, if you have a third-party module which passes structs of that type, won't that break?
<BenC> pitti: I can do a build again to make sure
<pitti> BenC: (sorry, I'm just horribly nervous to not screw this up)
<pitti> BenC: so in general the abi checker does check for changed structs?
<BenC> pitti: if it passes abi-checker, it's no problem
<pitti> ah, cool
<pitti> BenC: good, I'll walk through the -proposed packages for now and let linux sit there until your build
<pitti> ...finishes
<zul> BenC: what about 65631 for dapper -proposed (i know its late, see -kernel earlier)
<Kmos> hi
<pitti> BenC: call me blind, but I don't see any lbm in dapper-proposed, neither unapproved nor NEW?
<BenC> pitti: ooh, I forgot to upload that
<BenC> pitti: FYI, I should point out that the idea behind lbm is that it is installed by default in dapper.2
<pitti> BenC: by virtue of adding them to the seeds, I assume? (not by adding a dependency to linux-image?)
<cjwatson> we may need to tweak base-installer
<pitti> oh, for people who just install CLI, you mean?
<pitti> ah, ignore me; it's quite obvious
<cjwatson> (to clarify: base-installer installs the kernel and so will need to be taught to install l-b-m too. yes, they'll need to be seeded too so that they're actually on the CDs)
<pitti> cjwatson: do you think you can do this tomorrow, when the linux-meta lbm packages are in dapper-proposed?
<cjwatson> pitti: remind me tomorrow please, but yes, I can give it a go
<pitti> I will, thanks
<BenC> pitti: lbm-dapper uploaded
<pitti> BenC: accepted, thanks
<soren> Who has power to approve/decline nominations in Launchpad?
<ScottK> soren: Any ubuntu-dev.
<pitti> soren: for bugs? specs?
<soren> bugs
<pitti> for dapper at least, only ubuntu-drivers, but I'm able to nominate for edgy/feisty/gutsy myself
<soren> I'm just almost sure it's the first time I've seen the approve/decline link and I was curious..
<soren> ScottK: Oh, really? Hm.
<soren> pitti: Oh, we can't even *nominate* for dapper?
<pitti> soren: I meant s/nominate/actually add the task/
<soren> pitti: Oh, ok.
<pitti> soren: nomination is pretty unrestricted (no idea whether it's ubuntu-dev only)
<soren> pitti: Right, I would have expected it to be.
<sabdfl> https://edge.launchpad.net/~ubuntu-dev/+polls
<sabdfl> polls open in 8 hours for new MOTU council candidates
<sabdfl> please vote, everyone!
<mjg59> sabdfl: Wow, the UI for that is no longer eye-bleedingly painful!
<ProN00b> hey, i have an suggestion for the next release, why not make the stuff avaiable as a preload 1-3 weeks before the actual release so people can start loading the not yet but almost final packages so they only have to download the last minute changes when they download and install the release version
<coNP[uni]> ProN00b: I guess it is.
<jdong> ProN00b: that's a release candidate....
<ProN00b> steam (content delivery platform) does that for example; also i think the game world of warcraft employs a similar method
<ProN00b> jdong, well, a release candidate is installed and not just downloaded, i am talking of just downloading so you have it on the actual release
<jdong> ProN00b: you can download the release candidate and rsync it up to final
<jdong> or even torrent it up to final
<jdong> it's still less than 25% of the chunks that fail hash
<jdong> I don't know what else we can do...
<jdong> oh you mean for the upgrade procedure itself?
<jdong> i.e. apt prefetch distribution upgrades?
<ProN00b> yeah
<mjg59> Because what would be the point?
<kdean06> Congrats on another release guys. :)
<ProN00b> putting it into the "Update Manager"
<bddebian> Heya
<mjg59> People would just install them anyway
<ProN00b> mjg59, the point would be users having their release faster and servers not crawling under huge load
<mjg59> ProN00b: But it wouldn't happen. Once the files were on the servers, people would upgrade to them.
<ProN00b> mjg59, huh ?
<mjg59> How would you prevent people from installing the precached packages?
<cjwatson> ProN00b: we don't have it ready 1-3 weeks before the actual release. The thing that we *do* have ready we *already* put out as a release candidate.
<cjwatson> ProN00b: there are already ways to do everything you suggest
<ProN00b> cjwatson, so how do i preload the release candidate without installing it and use it in the later install ?
<mjg59> ProN00b: I'm getting over 100K/sec from archive.ubuntu.com. It's hardly crawling.
<ScottK> ProN00b: Download the RC CD.  Install that, then update
<cjwatson> ProN00b: apt-get --download-only dist-upgrade
<ProN00b> mjg59, well, my mirror and other peoples mirrors do
<mjg59> Using another mirror is always an option
<ProN00b> mjg59, yeah, but that would interrupt and break the update
<mjg59> No it wouldn't
<ProN00b> well, i am doing it with update manager
<ProN00b> it told me i can't interrupt
<sabdfl> mjg59: well, i have bandages over one eye from having to *create* it :-)
<cjwatson> AFAICT update-manager shouldn't tell you that you can't interrupt the fetch
<jdong> right
<cjwatson> since, hey, it provides a button to cancel the fetch
<cjwatson> mvo: is there a bug about that already?
<mjg59> ProN00b: Delaying the release by 2 weeks would be pretty equivalent to just asking people to wait two weeks after the release before trying to update. In all probability, the worst of the mirror traffic will be over tomorrow. You could just wait until then.
<ProN00b> mjg59, well, they would get it two weeks later instead of getting it exactly on the release date
<ProN00b> cjwatson, does dist-upgrade give me the release candidate ?
<cjwatson> ProN00b: it gives you whatever is current in the archive
<cjwatson> ProN00b: "release candidate" is only a meaningful concept for CD images
<mjg59> ProN00b: Yes. Which would be equivalent to putting the release back two weeks.
<ProN00b> mjg59, delaying makes no sense
<mjg59> ProN00b: It would be the same thing. If we were going to provide a meaningfully stable archive that could be precached for a 2-week period, it would require delaying the release.
<ProN00b> cjwatson, well, wouldn't i have to change my sources.list to the new release first then ?
<cjwatson> ProN00b: yes
<cjwatson> you could change it back afterwards if you liked
<cjwatson> there's no way we can have a stable archive for two weeks without releasing it
<ProN00b> so i do change - download only dist upgrade - change back
<cjwatson> (a) everyone would go berserk (b) developers would always want to upload just one more critical fix (with some considerable justification)
<ProN00b> cjwatson, it doesn't have to be stable, but as jdong said, it would contain 75% of the release already
<cjwatson> the freezes we already do are quite enough
<cjwatson> ProN00b: ok, just do what I suggest above then
<cjwatson> we were frozen for two full weeks before release, accepting only high-priority fixes
<cjwatson> you could have downloaded most of the updates in that time
<ProN00b> yeah, thats what my suggestion is, add that to the update manager
<cjwatson> I think that is unwise; as mjg59 says people will want to install it, and we don't want to promote that to all users before we've declared it stable
<cjwatson> it is better to put up with a little congestion around release time than to break people's systems
<ProN00b> well, it won't make installing any easyer
<cjwatson> and honestly, we need the bandwidth to be available before release time so that we can prepare the release
<cjwatson> it is preferable for us to have the congestion after release, when it doesn't impede development, than before release
<davmor2> Congrats Guys and Gals you've done a smashing job :)
<sladen> ProN00b: the update-manager will spread the offers to upgrade out over a 24-48 window anyway depending on when people are connected and when it tries to fetch
<ProN00b> i see
<ogra> davmor2, wouldnt have happened without cool testers like you ;)
<ogra> davmor2, thanks for the edubuntu tests :)
<davmor2> np bring on the next baych :)
<ProN00b> how much downtime will i have when i always update to the current stuff ?
<zul>  /win 11
<ogra> well, lets see if we get one, edubuntu might change its face in hardy ....
<mvo> cjwatson: about the "can't interrupt fetch"> there is no bug yet, I add one and tag it "later" because the text is no longer true
<cjwatson> thanks
<lamont> mvo: is there a way to tell update-manager about a local mirror
<mvo> lamont: if you sources.list consists of local-mirror urls it should do the right thing. if you have a mixed local-mirror and archive.ubuntu.com it will comment-out your local mirror
<lamont> ah
 * lamont removes archive.u.c
<mvo> lamont: so ensure that you only have local-mirorr deb lines :) and it should ask you "geeh, I don't know those urls, but if you know what you are doing, click "yes"
<lamont> hehe
<lamont> at home it's even easier, since dnat shoves archive.u.c to the local mirror.
<lamont> i win.
<mvo> lamont: did you get the dialog?
<lamont> it's getting there
<mvo> :)
<lamont> "preparing the upgrade" fetching file 1 of 2 at 28.7kb/s
<lamont> are those bytes or bits?
<lamont> :-)
<lamont> does update-manager spew a log anywhere?
<jdong> lamont: /var/log/dist-something?
<jdong> /var/log/dist-upgrade*.log to be more exact
<lamont> mvo: no valid mirror found...
<lamont> for the win.
<ScottK> mjg59: I'd like to discuss your marking Bug #127773 invalid against ACPI.  Booting with acpi=off gets at least the presence of a battery recognized.  That would indicate to me that acpi is in some way involved here.
<ubotu> Launchpad bug 127773 in hal "A/C Status, CPU Temp, and Battery no longer recognized as present after upgrade to Gutsy in Dell Latitude L400" [Medium,Confirmed] https://launchpad.net/bugs/127773
<lamont> mvo: <brett> FWIW, my "installing the upgrades" has taken about 20min to go from "18min remaining" to "16min remaining".
<lamont> <brett> oh, and it took about 3sec to go from "16min remaining" to "Cleaning up".
<lamont> installing the upgrades: about 1 hours 53 minutes remaining.
<lamont> sigh
<lamont> mvo: what is "modifying the software channels"?  is that just updating sources.list?
<cjwatson> ScottK: the package 'acpi' is not what you think
<cjwatson> ScottK: bugs are almost never valid on the acpi package
<ScottK> cjwatson: OK.  What package is that then?
<ScottK> Thanks.
<cjwatson> ScottK: acpi=off is implemented by the kernel
<cjwatson> linux-source-$whatever
<ScottK> Ah.  OK.
<ScottK> Thanks for that.
<cjwatson> 'apt-cache show acpi' - it's just a tool that displays some status information
 * ScottK learns new stuff every day here.
<ScottK> mjg59: Nevermind.
<lamont> sigh.  installing 1400 packages takes a while
<evand> mdz mjg59 sabdfl : Can one of you give the thumbs up to https://blueprints.launchpad.net/ubuntu/+spec/gobuntu-hardy for uds-boston-2007?
<cjwatson> (approved by me but I'm not in the TB)
<Psi-Jack> Hmm, was there ever a "create_user" command prior to 7.10?
<DShepherd> topic needs fixing
<sabdfl> evand: done
<evand> thanks sabdfl
<cjwatson> Psi-Jack: not in 7.10 either; it's called 'adduser'
<cjwatson> assuming you're talking about the standard system and not some database or something
<Psi-Jack> cjwatson: Ahh, okay. I JUST found out what I was looking for. Found a bug in dbmail's postinst. ;)
* cjwatson changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 7.10 released!
<cjwatson> DShepherd: that better? hardy isn't open yet so I haven't made the other edits you may be thinking of
<Psi-Jack> Seems to be in the script itself within the package diff.
<DShepherd> cjwatson, much
<Psi-Jack> Wow. I see why. The entire create_user() function from it is being removed, in this postinst script.
<mvo> lamont: yeah, just modfiying sources.list. the time calculation is pretty rough
<lamont> ok
<lucas> are there known problems with installing ubuntu inside qemu ? I can boot the dapper CD fine, but not the feisty or gutsy ISOs
<CarlFK> lucas: ask again in #ubuntu - i do it
<OpenSorce> okay folks.....this isn't flamebait just a heads up: I'm starting my review of 7.10's fitness for brand new users entitled "Kufailure: a review of Kubuntu 7.10" I'm sorry it worked out like this :-(
<LaserJock> OpenSorce: announcing it ahead of time doesn't relieve you from being flamebait ;-)
<LaserJock> OpenSorce: and I'm glad to see you managed to download the .iso :-)
 * ScottK looks around to see how many bugs OpenSorce fixed?
<OpenSorce> ScottK, I'm a journalist....not a devel.....I'm just paying you guys the courtesy of a heads-up
<OpenSorce> I really had high hopes for Kubuntu 7.10.....maybe the next release will do better
<LaserJock> OpenSorce: would you permit the courtesy of a rubutal? :-)
<LaserJock> OpenSorce: and frankly, a "heads up" that you're going to do a negative reviw is not really very exciting
<OpenSorce> LaserJock, if it gets printed on-line yes there's a comments function
<OpenSorce> LaserJock, didn't want to blindside you guys.....okay I got work to do....good luck with the next release
<LaserJock> OpenSorce: well, you can't blindside us when we don't know you exist, sorry
<LaserJock> I'm sorry you had a negative experience, truly
<LaserJock> but I'm not sure how you expect us to respond to this "heads up" when there is no context
<OpenSorce> LaserJock, actually if this is helpful let me say that the reason it failed our tests is it couldn't pass the "basics" on install
<OpenSorce> Basics: Keyboard, Mouse, Sound, Video (proprietary drivers incl.), Networking (WiFi incl.)
<OpenSorce> it failed in video and wifi
<pochu> Report bugs?
<calc> OpenSorce: which particular video and wifi?
 * ompaul is now very curious as to what kind of hardware was it run on 
<OpenSorce> calc, older Nvidia card and an older usb wifi adapter
<LaserJock> OpenSorce: ok, well that's a good start :-)
<LaserJock> OpenSorce: did you only try it on one machine?
<calc> OpenSorce: which particular usb chipset? broadcom?
<OpenSorce> LaserJock, yes same machine we test all new distros on
<OpenSorce> calc, acx
<OpenSorce> calc, Mandriva 2008.0 set it all up perfect right out of the box.....you guys may want to have a look at what they are doing
<calc> OpenSorce: interesting, i don't know anything about acx wireless but there is a driver for it in Ubuntu
<OpenSorce> and ndiswrapper not even included in the basic install?
<calc> OpenSorce: under /lib/modules/2.6.22-14-generic/ubuntu/wireless/acx  maybe it wasn't detected?
<OpenSorce> calc, yes the driver thinks my adapter is a wired device
<calc> oops
<OpenSorce> calc, it doesn't matter....it has to work out of the box....a new user wouldn't look there or be able to get here for help....he wouldn't have internet to do it.....networking failure is a deal breaker, y'know?
<calc> just as an aside it appears the acx line of wifi chips from TI is some of the worst supported under linux
<calc> OpenSorce: a new user would likely have a centrino system though as well... which is well supported, ymmv
<calc> i didn't know TI still even made wifi chips since intel owns that market now
<calc> but yes filing a bug report about the fact that the acx driver is confused and think it is hard wired would be very useful for people with that hardware
<calc> i'm not certain about the nvidia issue, whether ubuntu installs the proprietary driver by default or not
<OpenSorce> calc, well it's something we do out of fairness....we did polls on the hardware of most new Linux users and found them to have "middle-of-road" systems by and large....so we use a "middle-of-the-road" system for testing
<LaserJock> OpenSorce: you should really use more than one system though
<OpenSorce> calc, well the video issue is NOT a deal breaker provided the user can easily fetch the right driver
<calc> OpenSorce: which middle of the road intel systems use non-intel chipset for wifi? or do you mean middle of the road as in 3-4 year old hardware?
<calc> oh doh i am confusing myself
<LaserJock> I become a bit skeptical of reviews of any OS don't on only one hardware set
<calc> this was usb so was wifi in a desktop?
<LaserJock> *done
 * calc needs to learn reading comprehension again
<OpenSorce> calc, hehe....middle of the road as far as age of  hardware as well
 * calc notes his definition of middle of the road age-wise would be ~ 1.5yr old, 3+ is obsolete ;)
<LaserJock> :(
 * LaserJock is obsolete
<calc> heh
<ogra> no, 3+ is ready for thin client :)
<pitti> calc: in fact I only have three-year old HW (and older), and it's working very well
<OpenSorce> calc, yes it's a desktop system....we use wifi in testing because statistics show that over 55% of computer users today rely on wifi...and pretty much every distro can handle most network cards fine
<calc> of course i went from building kde to building ooo so i need faster hardware than average
<LaserJock> heh
<pitti> the good thing of the past years is that the GHz/MB-Mania has settled down a bit
<pitti> apparently computers are finally fast enough for people not to care about more power so much any more
<pitti> calc: you are special :)
<calc> pitti: heh
<OpenSorce> LaserJock, guys.....you did much better with the news of the article than #debian did....I think I'm still baned from there :-)
<calc> well quad-core is now fairly common and octo-core will be in a few years
<pitti> so I have to agree with OpenSorce that 3 year old HW shouldn't be entirely neglected
<pwnguin> well, #debian has the dual problem of not being ubuntu, and the title basically being a troll
<LaserJock> OpenSorce: heh
<calc> OpenSorce: i think the main reason we don't have ndiswrapper is because its yucky but acx should be made to work better than it did for OpenSorce
<calc> er for you
<OpenSorce> calc, acx_usb works great in Mandriva 2008.0
<LaserJock> OpenSorce: well, look, we obviously don't like negative reviews. If you had hardware-related problems we'd like to fix those
<calc> OpenSorce: ah then maybe we are missing a driver then
<calc> OpenSorce: i only saw a acx.ko
<pwnguin> how is there already a mandriva 2008.0?
<LaserJock> OpenSorce: so if you have time to do some bug reporting or an email or something so we can get stuff fixed for other people it'd be helpful
<calc> OpenSorce: that would something useful to note in the bug report if you create one, since there doesn't appear to be a acx_usb for ubuntu kernel
<OpenSorce> LaserJock, I can fix them myself honestly I just rate these articles for new users and do things the way newbs would so they don't get discouraged downloading one distro after the other
<LaserJock> OpenSorce: right, but you have to admit, one negative install based on a particular hardware set is not really gonna help newbs
<calc> OpenSorce: probably part of the difference in response is that #debian is mostly (all?) users and ubuntu-devel is mostly developers
<OpenSorce> calc, I'll try to do that....gotta get openSuse download and start my review of it as soon as I finish this review
<LaserJock> there are thousands and thousands of people who will have no such problems
<OpenSorce> LaserJock, it's a random sampling....and I just report my findings
<calc> it would be nice to eventually have a hardware database for ubuntu that could note what is known to work and what doesn't
<LaserJock> but it's not random sampling
<OpenSorce> LaserJock, since my review of driva 2008 there have been like 20 installs of it throughout the staff.....no issues....not one
<LaserJock> that's good
<calc> OpenSorce: did the nvidia video not work at all, or just not install the non-free driver?
<pwnguin> well, now we know where to steal patches from ;)
<cjwatson> OpenSorce: FYI, we ship ndiswrapper on the CD for users who are stuck; just don't install it by default because the result is very hard to support in practice
<OpenSorce> LaserJock, I agree with you......I'm going to have at least 5 more people run Kubuntu 7.10 in live cd mode and see if it works before I release the article
<LaserJock> OpenSorce: I've installed Gutsy on several computers with not a single hardware issue too
<OpenSorce> calc, it didn't install the proprietary driver....but I know Kubuntu doesn't do that.....it should
<OpenSorce> LaserJock, did they have wifi?
<LaserJock> OpenSorce: good, please do. I certainly don't mind you reporting what failed for you. But I think it's a stretch to call that representitive
<LaserJock> OpenSorce: yes
<LaserJock> ATI, Nvidia graphics, and Atheros for wifi
<OpenSorce> LaserJock, well most of these folks are running cheap lappies (acer) if it does better as a rule we'll take another look before publishing
<calc> OpenSorce: is it an intel based laptop?
<LaserJock> OpenSorce: all of my machines are chepo machines at least 3 years old
<OpenSorce> calc, yes
<cjwatson> OpenSorce: we'd like to find out why the free drivers are failing for you, as just installing the proprietary driver doesn't move the state of free software forward particularly well; so we'd be interested in your bug report in the context of why the free drivers aren't working, rather than "hey, you guys, you should default to the proprietary driver" :-)
<LaserJock> I'm just a poor grad student
<OpenSorce> brb testing
<calc> OpenSorce: intel ones likely work no problem at all, amd probably too though they usually use broadcom which i am not as familar with
<cjwatson> (we have to think of the longer term as well as the short term)
<calc> cjwatson: it sounds like we might be missing a driver for him, acx_usb
<cjwatson> yes, that may need to be pulled into linux-ubuntu-modules
<cjwatson> (it's not in the stock kernel tree)
<sladen> OpenSorce: short term aim is to try and get _a_ driver that works on that piece of hardware;  longer term we want to get _a free driver_ that works on that piece of hardware
<cjwatson> usb.c is actually compiled into acx.ko ...
<sladen> but that's pretty much was cjwatson said
<cjwatson> so you need a kernel team member to figure this out, which is best done by means of a bug :)
<pwnguin> OpenSorce: if you really want to document the suitability of Ubuntu 7.10 or not, try digging through the bug reports ;)
<pwnguin> plenty of "my wireless doesn't work" and "sound broken [regression]"
<mathiaz> jdstrand: about bug 119075, do you think the priority should still be high ?
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed] https://launchpad.net/bugs/119075
<jdstrand> mathiaz: checking...
<jdstrand> mathiaz: for gutsy and later? no.  IMO this is Wishlist.  gutsy and higher prompts for the password, so not a security issue any more.
<OpenSorce> back
<OpenSorce> pwnguin, I test the suitability for new users.....they would dig through bug reports
<OpenSorce> *wouldn't
<mathiaz> jdstrand: ok. Thanks.
<jdstrand> mathiaz: np
<pwnguin> OpenSorce: im not saying they would. im saying that if you're trying to gather a representative sample of the kinds of problems out there, the bugtracker is a tool for muckracking journalism ^_^
<OpenSorce> so far 3 out of 5 live cd runs fail to recognize and setup the wifi cards....I'm sorry the article is going to run as-is
<OpenSorce> pwnguin, I hate to tell you this but new users who can't connect to the internet do not often file bug reports
<calc> OpenSorce: in the article could you also document which chipsets the wifi you tested are?
<OpenSorce> thanks so much for your time guys
<pwnguin> jeebus h mcchrysty
<pwnguin> im not saying they will
<pwnguin> im saying if you're looking for dirt
<OpenSorce> calc, yes I always list the hardware....it doesn't always get printed but I always submit it
<calc> ok
<OpenSorce> pwnguin, okay and thanks again you guys, good luck on the next release
<LaserJock> OpenSorce: thanks
<LaserJock> OpenSorce: and really, if you have a chance we'd love to get some followup on those hardware issues :-)
<ajmitch> good morning
<pochu> morning ajmitch
<smallfoot-> i downloaded 7.10 gutsy today, then i saw a wubi file on the cd, and i clicked on it, and suddently it started to install stuff on my computer, without ask me
<Mithrandir> cjwatson: mkfs.ext3 on the netboot images is borked, it seems.  Can't find libblkid  (amd64)
<evand> smallfoot-: you shouldn't click on executables that you do not know the purpose of.
<LaserJock> evand: it should also be self-explanitor what executables are ;-)
<LaserJock> you can't expect people to not click on things
<evand> well, if you can think of an easy way of saying "use the windows bootloader to start the install to avoid having to change the drive order in BIOS", I'm all ears :)
<Mithrandir> evand: it could pop up a dialog saying what it's for, then give the user an option to continue or quit
<CarlFK> not all exes can have GUIs
<LaserJock> Mithrandir: exactly
<evand> Mithrandir, LaserJock, smallfoot-, fair enough.  I'll ask xivulon to make the change for Hardy.
<LaserJock> CarlFK: no, but ones that start installing files to disk should ask before doing so
<CarlFK> I will agree it is an issue.  but I think working on it has a pretty low return on investment
<Amaranth> Do you think an SRU to add things to the compiz blacklist would be accepted?
<LaserJock> it really just starts installing?
<LaserJock> I'd click it :-)
<Amaranth> Seems we missed a couple of the new set of ATI cards we blacklisted
<LaserJock> Amaranth: I was utterly shocked that compiz worked out-of-the-box on my ancient ATI card. Really surprised me
<LaserJock> I thought only nvidia and intel were working with compiz by default
<Amaranth> LaserJock: The ancient cards are fine, even the Radeon 7000 (just don't use wobbly)
<Amaranth> The problem is some r300 and r400 cards
<LaserJock> yeah, I vahve a 7000 IGP
<LaserJock> *have
<LaserJock> but I gave me fits so I turned it off
<Amaranth> compiz 'works' on pretty much everything that supports non-power-of-two textures and texture_from_pixmap
<LaserJock> at some point I might try to see if I can figure what was messing up windows
<Amaranth> so older ATI, intel, and nvidia (and new ATI with the just released fglrx 8.42)
<Amaranth> Just released as in it should be out right about now :P
<CarlFK> Mithrandir: cuz you said  "netboot images is borked"... you doing anything with apt and proxies?  'something' seems to have just changed in the last 24 hours
<Mithrandir> CarlFK: yes, I'm using a proxy, but I don't see why that should affect anything.
<CarlFK> seperate issue
<CarlFK> months ago I logged a bug (lloking for it) that I worked around with 'goofy'  preseed file  settings.  it may have gotten fixed, and now goofy=broke
<CarlFK> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/117398
<ubotu> Launchpad bug 117398 in debian-installer "netboot install proxy apt-cacher" [Undecided,New]
<smallfoot-> evand, thanks i look forward to Hardy, i was really scared when it started to install stuff, when i clicked on it, i just wanted to check what it was, i've heard about wubi before, so i thought it would prompt me, not just run the install
<smallfoot-> also, another thing, gutsy comes with firefox, but its not clear what version it is
<evand> smallfoot-: sorry, I believe it was an oversight that grew out of the fact that originally you'd get a dialog (as it was wubi), but as time went on it became just a utility to let you install without changing the boot order.
<evand> smallfoot-: 2.0.0.6
<smallfoot-> oh
<smallfoot-> okie
<smallfoot-> it should be made clear what version it is though, so if firefox is still in hardy, put so it displays its version
<jdong> smallfoot-: why is it unclear the version of Firefox in Gutsy?
<jdong> the help->About box is labeled 2.0.0.6, debin pkg is   Installed: 2.0.0.6+2nobinonly-0ubuntu1
<smallfoot-> oh, sorry for being unclear
<smallfoot-> i meant on the CD
<smallfoot-> on the gutsy cd, there is a windows version of firefox
<evand> smallfoot-: you should probably file a bug.
<evand> smallfoot-: https://bugs.launchpad.net/ubuntu-winfoss/+filebug
<smallfoot-> evand, dont have account
<smallfoot-> would appreciate if you did it for me
<evand> smallfoot-: sure thing
<Keybuk> cjwatson: still around?
<smallfoot-> awesome
<Mithrandir> cjwatson: false alarm, it was something else that went wrong, it seems
<mdke> haha, love the dictionary extract on the website
<OpenSorce> LaserJock, if I get permission to wait 2 weeks on my Kubuntu 7.10 review do you think it'll make much difference?
<ScottK> OpenSorce: I'd say it depends a lot on what exactly your concerns were and are they ones that can be fixed with stable release updates (meaning fit the criteria, have developers interested in working on them, and have reasonable solutions available).
<LaserJock> OpenSorce: well, it's possible that if the issues that are causing you problems can be fixed via a Stable Release Update that they could get fixed
<calc> when does hardy open up? :)
<LaserJock> calc: isn't it already?
<OpenSorce> LaserJock, how often d SRU's come out for Ubuntu?
<ScottK> LaserJock: No.  It's still syncing.
<ScottK> OpenSorce: They are published when they are ready, not on a set schedule.
<LaserJock> OpenSorce: as soon as a fix can be isolated, uploaded, and tested
<LaserJock> if it's a problem with proprietary drivers it might be quite difficult
<LaserJock> if it's a problem that's easy to fix it can be quite quick
<LaserJock> OpenSorce: you've already seen that several of our developers are interested in helping fix the problems you were seeing
<OpenSorce> LaserJock, the problem is that on 6 out of 6 machines Kubuntu 7.10 failed to properly setup the wifi cards
<calc> OpenSorce: are they all the same chipset or different ones?
<LaserJock> if you can work with them giving them information and maybe testing fixes it should be reasonable
<calc> LaserJock: nope no hardy yet on a.u.c ;-)
<LaserJock> but I'm just a lackey so don't take what I say as set in stone
<OpenSorce> LaserJock, you might be interested to know that we did the exact same test with Mandriva 2008....which either set them up or gave us a gui app to help us make ndiswrapper drivers for them
 * calc is guessing it won't open until after uds
<ubotu> Mandriva bug 2008 in Core Packages "reloading the user config or system menu closes the menudrake window" [Normal,Resolved: duplicate] http://qa.mandriva.com/show_bug.cgi?id=2008
<LaserJock> OpenSorce: yes, so we've got to isolate what drivers (and versions), etc. that Mandriva's using
<ajmitch> calc: it's usually open beforehand
<calc> ajmitch: ok
<LaserJock> calc: really? in the past it's copied over but doko doesn't break everything until UDS ;-)
<OpenSorce> LaserJock, ok...well if you think that waiting two weeks will help I will wait and note that in the article
<calc> LaserJock: heh
<calc> doko: its time for you to break hardy ;)
<ajmitch> calc: you just want to upload OOo again, don't you?
<calc> ajmitch: heh not yet, 2.3.1 won't be ready for probably another few weeks
<LaserJock> OpenSorce: well, I would say that waiting alone might not get you much in two weeks. We need to get the kernel guys to help figure out what to do it sounds like
<calc> ajmitch: i just never run stable releases of linux ;)
<ajmitch> hehe :)
 * ajmitch hands calc a copy of sid
<calc> well i did earlier this year but only because ipw3945 was too broken for to use it at all :\
<LaserJock> calc: you don't do new uploads just to change positions of the Ubuntu logo in the splash? ;-)
<calc> ajmitch: i ran sid for about 7 years
<ajmitch> LaserJock: oh that's evil
<calc> ajmitch: well thats not strictly true, when i started using debian in 1998 sid wasn't really unstable it was a spot for completely broken things to go, more so than now
<OpenSorce> LaserJock, okay....we'll wait....thanks again :-)
<ajmitch> "hm, the colour doesn't quite look right, let's upload again!"
<ajmitch> calc: yeah, I started with debian not long after that :)
<LaserJock> OpenSorce: I do hope things can be fixed for you. 0 out of 6 is no good
<calc> ajmitch: iirc they didn't switch sid to be unstable until pools were implemented
<ajmitch> & ran sid until just after warty was out
<calc> i switched to warty when the first cd announcement was made in ~ sept 2004 (i think)
<LaserJock> I *started* running sid a couple weeks ago
<calc> LaserJock: you're a n00b ;-)
<LaserJock> so maybe by 15.04 I can say "back in the day when I ran sid"
 * ajmitch feels sorry for mvo, all these spurious upgrade failures beind filed against update-manager
<LaserJock> just think, by then a whole generation of developers will have no idea where the names come from :(
<calc> LaserJock: hmm yea TS will be ~ 20 years old then
<ajmitch> a cult classic, I'm sure
<LaserJock> by that time we'll have Debian releases like "3rd sheep"
<LaserJock> they'll be digging in the credits looking for names
<calc> debian still hasn't used stinky has it?
<LaserJock> no
<calc> debian stinky sounds like a good release to me
<LaserJock> slinky, but not stinky
<LaserJock> I think
<calc> for stinky pete
<ajmitch> LaserJock: you assume that there'l be that many debian releases in that time
<calc> slink was 2.1 iirc
<LaserJock> ajmitch: ohhh, right. I forgot
<ajmitch> maybe one every 18months-2 years
<LaserJock> is that why the only release when there's some sort of astrological alignment?
<LaserJock> they're afraid of running out of names
<calc> LaserJock: nah, just too much red tape
<calc> if they run out of TS names they will probably move to the next pixar movie
<mc44> Toy Story 2? :)
<LaserJock> calc: well, isn't it a trilogy
<calc> LaserJock: but most of the same characters
<LaserJock> so maybe they can ask Mark to fund Toy Story 4 as a good will gesture ;-)
<calc> they'll gain a few more names
<calc> oh i didn't know TS3 is coming out in 2010
<jcole> does totem-gstreamer now support dvd menus?
<jcole> or do i have to install totem-xine again
<mjg59> jcole: No, it doesn't
<jcole> mjg59: ok
<jcole> mjg59: btw, what is the recommended dvd playback app for ubuntu... totem-xine?
<jcole> mjg59: thats what's always worked for me
<mjg59> gxine will also work
<mjg59> I don't think we have a recommended one
<jcole> mjg59: good point, then i dont have to clobber totem-gstreamer
<jcole> mjg59: thank
<jcole> s*
<jcole> :)
<pipegeek> Hihi.
<pipegeek> I'm wondering what the recommended means of getting reiser4 working under gutsy are.  Seems reiser4progs are in the repository for some reason, but the filesystem itself isn't.
<mjg59> There isn't one
<ScottK> pipegeek: I think the recommendation is don't
<pipegeek> OK..... but, then, why is reiser4progs included?
<pipegeek> if it's not meant to be used
<mjg59> The tools are provided for anyone who wants to build their own kernel, but we don't support the use of the filesystem
<pipegeek> fair enough. :^(
<pipegeek> thanks, folks.
<jcole> pipegeek: http://packages.ubuntu.com/gutsy/admin/reiser4progs
<pipegeek> jcole: that doesn't contain the filesystem
<jcole> pipegeek: kernel-patch-2.6-reiser4 "Package not available"
<pipegeek> ah
<pipegeek> yup
<pipegeek> there's the answer
<jcole> pipegeek: apt-get source kernel-patch-2.6-reiser4
<jcole> pipegeek: or whatever, and patch your kernel
<pipegeek> yeah.... not worth a rebuild
<pipegeek> and there's no such package, fyi
<pipegeek> darn.
<geser> jcole: kernel-patch-2.6-reiser4 is on the sync blacklist
<pipegeek> Just out of curiosity, might I inquire as to the reasons behind this policy?
<pipegeek> (I can think of several, I'm just curious)
<geser> Ubuntu doesn't "support" the packaged kernel patches
<pipegeek> but if I were interested in taking a look for myself (because you seem to imply that they *have* been packaged).... where might I find them?
<geser> it's not only this kernel patch on the blacklist but all packaged kernel patches
<geser> in Debian
<pipegeek> got it
<pipegeek> thank you.
<pipegeek> ^.^  Sorry for being a pain
<geser> but no guarantee that they even apply on the Ubuntu kernel source
<pipegeek> understood.
<pipegeek> well, it's a project for some future day
<Lamego> what are the benefits of using reiser4 ?
<pipegeek> Never have; wanted to play with it.  This is for my home system, not for anything important
<slangasek> calc: so far the Debian release names have been restricted to characters named on-screen in TS1, I don't think stinky pete qualifies?
<calc> slangasek: yea he was in TS2 so it will be a while
<slangasek> calc: assuming the RMs want to use TS2 names at all
#ubuntu-devel 2007-10-19
<pipegeek> o.O  compiz, as configured in gutsy, breaks alt-shift-tab.  Worth a bug report?
<bmk789> can someone tell me the best way to start getting into ubuntu development?
<mjg59> bmk789: Developing under Ubuntu, or developing parts of the distribution?
<bmk789> parts of the distro
<mjg59> One of the easiest ways is to find fixes for bugs
<mjg59> In the long run, you'll want to be able to upload things yourself, which will involve going through the MOTU process
<bmk789> whats that like?
<mjg59> https://wiki.ubuntu.com/MOTU has information on it
<mjg59> The FAQ is probably a good starting point
<mjg59> #ubuntu-motu may also be a good place to ask questions
<bmk789> ok ill look into that, what language would be most beneficial to learn?
<mjg59> Most of our code is in either C or Python
<mjg59> Probably a larger body in C, but a moderate amount of the Ubuntu-specific code is in Python
<bmk789> ok thanks for the help, ill try to grab some books on C
<JohnKarahalis> Hello everyone, congratulations on release!
<JohnKarahalis> is anybody here?
<RAOF> JohnKarahalis: Yeah, just exhausted :P
<StevenK> RAOF: And you didn't come last night. Hmph!
<RAOF> StevenK: Yeah :(
<ajmitch> neither did I, so it's ok :)
<RAOF> ;)
<StevenK> ajmitch: Yeah, but you have the excuse of flights. :-P
<JohnKarahalis> If you don't mind me asking, is anybody in here a paid employee of Canonical?
<ajmitch> there are rumoured to be some around
 * ajmitch is not :)
<JohnKarahalis> I'm looking to interview a professional software engineer as part of a school project. A short interview of just basic questions really.
<tonyyarusso> I'd guess that there are people not employed by Canonical who are also software engineers too.
<tonyyarusso> JohnKarahalis: (it's sleepy-time at Canonical right now)
<JohnKarahalis> ooh haha right
<JohnKarahalis> damn time zones
<ajmitch> tonyyarusso: it is?
<RAOF> People sometimes email such inquiries to the various mailing lists, but I'm not sure how often they get responded to.
<slangasek> tonyyarusso: it's never sleepy-time at Canonical
<JohnKarahalis> unfortunately, the project requires that the person be salaried
<tonyyarusso> slangasek: well, close enough...
<tonyyarusso> the sane ones sometimes sleep
<slangasek> but "software engineer" isn't exactly my job description :)
<JohnKarahalis> slangasek: do you work for canonical?
<ajmitch> what is it, "release monkey"?
<tonyyarusso> teehee
<slangasek> JohnKarahalis: yes
<Burgundavia> trained chimp?
<tonyyarusso> slangasek: you should get some kind of cloak, btw
<JohnKarahalis> slangasek: Awesome! So what is your job title?
<slangasek> ajmitch, Burgundavia: wow, I can see y'all are grateful that Gutsy is out... :)
<ajmitch> slangasek: sure am :)
 * tonyyarusso wonders if there are any mirrors still functioning
<JohnKarahalis> slangasek: Do you program, or are you involved in support and things like that?
<slangasek> JohnKarahalis: Ubuntu Release Manager
<slangasek> so I think they probably let me program some when we're not in a release crunch time, but I haven't had an opportunity to see this in practice yet. :)
<ajmitch> I can't imagine that you'd be kept idle for a few months
<slangasek> tonyyarusso: why?
<tonyyarusso> slangasek: so we can tell who you're with ;)
<JohnKarahalis> slangasek: Ahh I see, so not much coding for you I guess. How is it working for a FS company though (that question is just out of curiosity by the way, not for the interview :)
<tonyyarusso> slangasek: b/c all the cool kids have one
<bddebian> tonyyarusso: heh
<slangasek> ajmitch: heh, certainly not; I just don't know that it would include much "software engineering"
<slangasek> JohnKarahalis: well, it certainly involves some coding, both for keeping the release machinery running appropriately and for helping to fix bugs
<bddebian> So if you are all bored, anyone want to help me with a problem with a package? :)
<JohnKarahalis> slangasek: That's awesome. I hope to work for a company like canonical one day.
<slangasek> as for "how is it" - it's a lot more fulfilling than some software work I've done in the past
<slangasek> bddebian: what package?
<JohnKarahalis> slangasek: That's exactly what I wanted to hear! It seems like it would be more fulfilling.
<bddebian> You don't wannt know. :-)  gnome-breakout
<slangasek> bddebian: ok, so what's the problem?
<bddebian> I have fixed everything I wanted to except that the path for the levels isn't getting set.  LEVELDIR is supposed to be $(datadir)/gnome-breakout/levels and I have datadir=/usr/share/games but it's still getting /usr/share
<JohnKarahalis> slangasek: Do you think you would be interested in conducting a short interview with me via email some time over the next 2-3 weeks? It would be a simple interview, with questions like "What is a typical work day like", "What languages and technologies do you use", "How big is the team you work in".  If you're too busy I completely understand, what with Gutsy and what not.
<slangasek> JohnKarahalis: do you have an estimate of how long the questions take to answer?
<slangasek> though, "what is a typical work day like" would be a hard one for me to answer, hum - you'd probably find other Canonical folks better able to answer that :)
<CarlF1> should the alt installer be hitting archive.u.com even though I specified a host ?
<JohnKarahalis> slangasek: I mean, I wouldn't expect that it would take you more than 10-20 minutes to answer the questions. All I basically have to do is write a 3 page paper on the interview, it wouldn't be hard to do that if I had some background information about yourself and some answers to a few additional questions.
<CarlF1> it does hit the specified host, but not after a long delay given the stress on arc.u.c, sometimes causing an error
<JohnKarahalis> slangasek: But if you can't that's fine. I've got fallback options (not as good as a Canonical employee, but....) :)
<slangasek> JohnKarahalis: sure, I could swing 10-20 min for that; I do think you could probably catch a better-suited candidate if you hung around here for a while though, or tried back earlier in the day (US time)
<JohnKarahalis> slangasek: Yeah, I think I'll try tomorrow morning also. But could I put you down on my list of possible candidates?
<slangasek> sure
<slangasek> slangasek@canonical.com
<slangasek> bddebian: source package showing this behavior?
<JohnKarahalis> slangasek: Wow, thank you very much! What is your name by the way, my prof wants to know the names of the people we are considering. If you'd rather I get that info by email I'll send one to you.
<slangasek> CarlF1: depending on what you mean when you say you "specified a host", no, you shouldn't have to hit the central server with the installer; but for support please see #ubuntu as mentioned in the channel topic
<bddebian> slangasek: Well the current package just leaves stuff in /usr/share.  I ended up having to autoreconf in order to get localedir to work.
<slangasek> JohnKarahalis: Steve Langasek (in my IRC client info, fwiw)
<JohnKarahalis> slangasek: Ahh, this is my first time with IRC. Thanks so much! For now I think I'm gonna upgrade to Gutsy. Thanks again, I hope to talk to you soon.
<slangasek> cheers
<slangasek> tonyyarusso: anyway, my /whois already tells you who I'm with, I'm with the IPv6 goons :)
<TheMuso> Congratulations guys on another great release.
<bddebian> Oh, we released? ;-)
<TheMuso> heh
<CarlF1> slangasek: on 'stuff like this' I can't trust what i get in #u for filing a bug report.  in this case, I have a feeling it is part of https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/117398
<slangasek> bddebian: you need to give me a source package showing the current behavior that you're trying to fix; I'm not going to guess based on a separate version of the source packge
<CarlF1> so if not here, and not #u, any other #chans?
<bddebian> slangasek: http://www.bddebian.com/packages/debian/gnome-breakout/
<slangasek> CarlF1: you're using preseeding?
<CarlF1> yes
<bddebian>  src/Makefile.am:           -DLEVELDIR=\"$(datadir)/gnome-breakout/levels\" \
<slangasek> CarlF1: and you're going through a proxy?
<CarlF1> yes
<CarlF1> well, if apt-cacher is considered a proxy
<bddebian> I wonder how many packages I can stack on mentors before I get a single response.. :-)
<slangasek> CarlF1: usually apt-cacher is not normally run using a proxy configuration AFAIK
<CarlF1> slangasek: that fits with how I had to set the preseed options
<slangasek> CarlF1: honestly, I don't see how that's a bug; the syntax in that bug listed under "the only way I could get it to work were with these settings" look like the obvious and correct way /to/ get it to work
<CarlF1> then maybe the bug is the description for http://packages.ubuntu.com/edgy/net/apt-cacher  "caching proxy system"
<slangasek> CarlF1: it is a caching proxy; but it's not an http proxy, it's an apt proxy
<slangasek> i.e., it only caches and proxies .deb packages, not generic web content
<CarlF1> given is is meant to be used for that it seems odd that the installer settings  would be "weird"
<slangasek> CarlF1: they're not weird to me, but I'm the wrong person to judge because I've been a debian-installer developer for years
<slangasek> CarlF1: effectively, the reason you configure it that way is because you're specifying your local apt-cacher as your mirror, which is precisely how apt-cacher is designed to function
<CarlF1> i say weird because it dose what a proxy does, but instead of the installer using the proxy settings, I have to munge the host/dir names
<slangasek> yes, because it's not an http proxy
<slangasek> so if the documentation doesn't make it clear that "proxy" in the alternate installer refers to an http proxy, I think that's the bug
<CarlF1> that would be a start
<CarlF1> i'm assuming apt-cacher is better than an generic http proxly, right?
<slangasek> hmm, I don't know that I would say it's "better" - it's a different use case
<CarlF1> better for caching .deb s
<slangasek> ok, then yes :)
<slangasek> but the alt installer supports http proxies because some sites *require* all web traffic to go through a proxy
<CarlF1> i see what you are getting at
<CarlF1> The installers proxy settings propose aren't there to hit a caching proxy for speed, they are there for when it is the only way.
<bddebian> Hmm, seems Mr. Langasek did one of the last uploads of stk too :-)
<slangasek> stk?
<slangasek> oh, pff, some package I uploaded in 2005?
<bddebian> Heh
<slangasek> CarlF1: well, if your site has a generic caching http proxy already, using it for .debs is fine too even if not mandatory, and probably saves you the trouble of setting up a separate apt-cacher
<CarlF1> slangasek: cept I have only apt-cacher, no http proxy :)
<slangasek> sure
<CarlF1> I am adding a comment to the that basicaly says "not a bug"
<ubotu> Launchpad bug 117398 in debian-installer "netboot install proxy apt-cacher" [Undecided,New]
<bddebian> Frick, I hate source packages with tarballs :-(
<slangasek> bddebian: I'm out for dinner, but I'm leaving gnome-breakout building and will deliver a diagnosis when I get back
<bddebian> slangasek: Great, thanks!
<StevenK> Diagnosis: "It's broken"
<bddebian> No, I "fixed" it :-)
<bddebian> the build system is fairly broken though :-(
<bddebian> OK, f**k stk
<slangasek> bddebian: um, when I build that source package from scratch, I get the correct path in the binary
<bddebian> slangasek: The path is correct, I fixed that.  When it runs, it looks for the levels in /usr/share/gnome-breakout/levels, not /usr/share/games/...
<bddebian> I am thinking the locales dir may be wrong at runtime too but since I don't know other languages, I'm not sure how best to test that.
<Burgundavia> slangasek: as per my comment a few hours ago, we had to hold back while Gutsy was sitll in development ;)
<bddebian> slangasek: Any thoughts or have I lost your help? :-)
 * bddebian takes that as he's lost the help
<Kano> hi, when do you set the default to gutsy on packages.ubuntu.com?
<jdong> is it true that update-manager will automatically remove non-official repositories and also roll back or otherwise deinstall them? Or is that a Kubuntu/Adept feature? Or is it not a feature at all?
<ScottK> jdong: It's supposed to.  I've helped one person today that had to remove some of the Automatix repositories manually.
<jdong> ScottK: does it just remove the repositories in sources.list, or does it have a mechanism to remove thigns in Local/Obsolete, and/or downgrade packages back to official versions?
<ScottK> AFAIK it just removes the repos.
<jdong> ok
<jdong> so users with unofficial stuff installed, I will still have to tell them to remove them
<ScottK> I know for this release Automatix is recommending removing everything installed by Automatix and Automatix before upgrading.
<ScottK> Yes.
<ScottK> Getdeb makes the same recommendation.
<ScottK> For their stuff.
<bddebian> ScottK: And why did you help them? ;-P
<ajmitch> recommendations & reality never tend to match up
<ScottK> bddebian: I don't think I did.
<bddebian> :-)
<ajmitch> since it requires the users to be able to isolate the set of packages installed from elsewhere
<ScottK> I took stuff that we could legally do and stuffed it into the official repos giving them fewer excuses to exist.  If that counts as helping, guilty as charged.
<bddebian> ScottK: beauty :-)
<Burgundavia> automatix seems to be very interested in helping
<Burgundavia> I wonder if they are seeing less installs which each release?
<ScottK> Burgundavia: I think they've had a "management restructuring".
<StevenK> Burgundavia: That's an interesting point - are Automatix seeing less people using them due to us making an effort with things like easy codec installation, along with things like mjg59's analysis.
<ScottK> The guy that appears to be running the show now at least has interest in cooperating and shows some inclination to listen when being told they're being stupid.
<ScottK> StevenK: I think that's true.
<Burgundavia> I wonder where arnieboy went
<pwnguin> he's still there
<ScottK> I'd like to see mjg59 do a followup of their Gutsy release to see if their claims "we fixed all that" are accurate.
<StevenK> ScottK: Mail the tech board, I suspect the answer is, "Let's check to see."
<Burgundavia> "WARNING: Automatix for Ubuntu 7.10 Gutsy will NOT be upgradeable from previous versions. You must either do a clean install of Gutsy or run Automatix in Feisty and uninstall everything before upgrading to Gutsy." <-- http://www.getautomatix.com/wiki/index.php?title=Main_Page
<ScottK> The code to sigkill dpkg was at least commented out when I looked.
<pwnguin> im sure mjg has plenty of other things to do ;)
<ScottK> StevenK: I was sort of hoping he'd read the scrollback and be inspired.
<ScottK> welcome back milli.
<StevenK> ScottK: Heh
 * ScottK ponders the text of his secvpn removal request.  Good technical terms for "This package is evil and must be destroyed."
<StevenK> ScottK: "This package eats babies."
<ScottK> Sounds about right (and does it using sudo - this part true).
<pwnguin> ScottK: just susbcribe a young priest and an old priest
<tritium> Every time you install this package...Please, think of the babies.
 * StevenK chuckles
<StevenK> ScottK: Are there technical reasons for why it should be destroyed?
<ScottK> Yeah.  I'm not sure I'm knowledgeable enough to enumerate them, but the bottom line appears to be that the current package is unworkable and insecure and would have to be almost totaly redone to have a hope of working safely.  That's without looking at any of the upstream code.
<ajmitch> StevenK: example - the initscript wants to write into /etc/inittab for start/stop
<StevenK> *EW*
<TheMuso> yuck
<TheMuso> yuck
<pwnguin> what about people who dont care about security but have to work with employers who do?
<TheMuso> ok espeak says that weirdly
<StevenK> ScottK: Okay, I think the way forward is to say the bottom line bit in a bug report, and ask pitti to do a short security review - if he finds major flaws, kill it.
<StevenK> TheMuso: How does it pronounce it?
<TheMuso> StevenK: yook
<ScottK> StevenK: That sound like an excellent idea.  Thanks.
<pwnguin> gootsy
<TheMuso> gutsy is spoken correctly.
<ScottK> I already got an opinion from keescook on secvpn adding itself to sudoers.  He wasn't a fan of that approach.
<StevenK> Double ew
<ajmitch> hence the slight reservations of having the package being installable
<ScottK> Right.  Once I saw that I quit trying to fix it.
<slangasek> bddebian: that was while I was still on the way to dinner...
<slangasek> bddebian: anyway, it's doing the right thing at runtime too for me
<bddebian> slangasek: Yeah, just got that with TheMuso.  Sorry to waste your time too :-(
<dholbach> good morning
<myrttiubuntu> how #ubuntu I computer no working
<myrttiubuntu> plz help :)
<myrttiubuntu> op #ubuntu-ops no help rude they broke computer no #ubuntu
<Mithrandir> myrttiubuntu: that's offtopic for this channel though, this is a development channel, not a support channel
<myrttiubuntu> i be like them they kick and no connect #ubuntu
<myrttiubuntu> i can not connect #ubuntu
<OpenSorce> the following review of Kubuntu 7.10 will be released to the public within the next 3 weeks.....not trying to be flamebait....just notifying you guys....my boss is sending an email to you guys as we speak http://bigcatlinux.com/kufailure.html
<myrttiubuntu> people #ubuntu-ops no connect said they rude
<Karnaugh> myrttiubuntu: I can't understand you, and nicknames like "ubuntusucks" is unlikely to get you any help
<Burgundavia> OpenSorce: your review is incorrect
<Burgundavia> OpenSorce: compiz-fusion is for Ubuntu, not Kubuntu
<OpenSorce> Burgundavia, thanks for pointing that out I'll have it corrected
<myrttiubuntu> Karnaugh i same nick as op but no connect #ubuntu, ops rude
<Burgundavia> OpenSorce: the other thing you might want to change is that we don';t install prop. drivers for good reason
<OpenSorce> Burgundavia, whatever
<OpenSorce> Burgundavia, it either wors or it doesn't
<Mithrandir> myrttiubuntu: you are offtopic here, please either stop being offtopic or I'll have to ask you to leave.
<OpenSorce> *works
<myrttiubuntu> all ubountu are rude
<Burgundavia> OpenSorce: it makes no sense to argue with you, suffice it to say, that isn't going to change
<OpenSorce> Burgundavia, not my job to get into the how and the why
<OpenSorce> Burgundavia, okay :-)
<Burgundavia> there, in fact, possible legal issues with shipping binary drivers
<Mithrandir> OpenSorce: you should point out the multimedia keys didn't work with your keyboard.  They work just fine on my keyboard.
<OpenSorce> Burgundavia, Mandriva does it
<Burgundavia> OpenSorce: legal opinions differ on this matter
<OpenSorce> Mithrandir, it's all taken from a sampling of one machine
<OpenSorce> Burgundavia, okay
<Mithrandir> OpenSorce: yes, and you don't say that, nor do you say what kind of hardware you have.
<OpenSorce> Mithrandir, that gets added prior to final publication
<Mithrandir> OpenSorce: I hope you are filing bugs about all the problems you have encountered as well
<OpenSorce> This is a pre-edit copy, btw
<Burgundavia> OpenSorce: I suggest you read this: http://www.ubuntu.com/community/ubuntustory/philosophy
<OpenSorce> and there is an error I gave too many stars for the keyboard it will be 4 in the final release
<OpenSorce> Burgundavia, it doesn't matter.....I am rating it for new user suitability....that holds the distro to a higher standard
<Burgundavia> OpenSorce: binary drivers are not needed for average users
<OpenSorce> Burgundavia, okay....either way I don't want to "troll" in here....just notifying you guys of the article
<Burgundavia> as for your wireless, what kind of driver do you have?'
<OpenSorce> Burgundavia, you are welcome to join #bigcat if you want to discuss this further.....I don't want to clog the channel with off-topic stuff
<holycow> lol
<holycow> dumbass
<Burgundavia> be nice, holycow
<ubuntunonakedgir> how fix?
<ubuntunonakedgir> no help no #ubuntu how fix broken?
<pitti> Good morning
<Burgundavia> morning pitti
<StevenK> Morning pitti
<pizzadude> does anybody know the power output of the PCI bus?
<ScottK> Burgundavia: Did you look at the other content on the site that "Journalist" pointed to?
<OpenSorce> Burgundavia, I'm sorry did you ask me about the chipset in my wifi adapter?
<Hobbsee> bye now.
<Hobbsee> bloody tor
<OpenSorce> Burgundavia, it's acx....which it seemed to think was a wired device
<ScottK> OpenSorce: If you are a journalist, why are you putting your reviews on a web site of another linux distribution?
<OpenSorce> ScottK, that's one of my personal websites....it's just where I uploaded for review
<ScottK> OK.  It looks like that web site of a soon to be Linux distro.
<OpenSorce> ScottK, it is.....I don't know if I'd use the term "soon" :-)
<ScottK> Odd thing for a journalist doing independent distro reviews to have.
<OpenSorce> ScottK, and it's probably a project I'll have to hand off to someone else since it may be a conflict of interest for me
<OpenSorce> ScottK, I'm a geek...we make geeky things :-)
<ajmitch> Hobbsee: you may want to try & get him out of other channels also
 * Hobbsee watches her troll meter go off
<ajmitch> :)
<Hobbsee> ajmitch: i'm somewhat limited by the fact that we have no staffers around.
<ajmitch> unfortunate
<Hobbsee> and i dont have ops on every single ubuntu channel
<ScottK> OpenSorce: It sounds like you've been working on it for some time.
<Hobbsee> yeah well, it is australian day.
<OpenSorce> ScottK, yeah....about oh...a week :-)
<Mithrandir> ScottK,OpenSorce: please take this elsewhere, it's not related to development of Ubuntu.
<OpenSorce> Mithrandir, I apologize
<OpenSorce> ScottK, #bigcat is open
 * ScottK will note that the domain was registered yesterday and shut up.
<OpenSorce> Mithrandir, sorry I just came back to answer a question about my wifi chipset
<Mithrandir> OpenSorce: sure, which is fine, but if (plural) you want to discuss further, please do so somewhere else.
<OpenSorce> Mithrandir, of course :-)
<Hobbsee> sladen: yes, but you miss nice weather, compared to au.
<Hobbsee> perhaps you should move to AU, and all the problems will be solved!
<SlimG2> Why Isn't the locales for Firefox and Thunderbird included in their main package?
<StevenK> They should be included in their own locale packs, becuase they are enormous.
<SlimG2> mkay
<sladen> Hobbsee: I'd consider it, but the latency is just unbareable
<pitti> SlimG2: the main reason is that they use a custom method for translation
<pitti> SlimG2: the entire FOSS world uses gettext, except for Mozilla and OpenOffice products
<pitti> SlimG2: we are aiming at eventually providing them in the normal language packs, but it'll still take a while (maybe we'll manage in hardy)
<SlimG2> pitti: thanks for explaining
<pitti> mvo: can I ask you again to update the status of bug 120957?
<ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [Undecided,New] https://launchpad.net/bugs/120957
<mvo> pitti: this is fixed with 0.59.25 in feisty-updates
<pitti> mvo: and in gutsy?
<mvo> pitti: but let me read up on it again to see why it was reopend
<mvo> pitti: I'm pretty sure it is fixed in gutsy too, but I will double check
<pitti> mvo: thanks; just wanting to make sure that it doesn't fall off the table
<gaspa> pitti: hi. I had reported two bug for uplash (and a wished feature), and subscribed you.
<gaspa> so, in both reports there are my fixes. could you take a look if I didn't make something wrong?
<dholbach> hey seb128
<seb128> hello dholbach
<pitti> gaspa: ah, thank you! Will have a look
<gaspa> pitti: I attacched my bazaar branch, and i got a source package in ppa.
<gaspa> so you can try it.
<pitti> gaspa: hm, I didn't get bug mail yet
<gaspa> strange...
<gaspa> right, you're subscribed only for bug 152952
<pitti> gaspa: what's the use case for 152952?
<pitti> gaspa: we should generally avoid asking questions to the user unless it's absolutely necessary (such as entering a passphrase for encrypted partitions, etc.)
<pitti> gaspa: did you have something particular in mind?
<ubotu> Launchpad bug 152952 in usplash "input command with timeout parameter" [Undecided,New] https://launchpad.net/bugs/152952
<gaspa> we use it. for our products. we don't want that user sees terminal
<gaspa> and i think it could be useful for someone else... but this is only a whish. The other two are bug fix, and probably more important
<pitti> gaspa: right, I'm not saying I don't like it (after all, it's just an optional feature); I was just interested in a concrete use case (maybe we want it for something by default as well?)
<doko> pitti: please accept gcc-4.2
<gaspa> pitti: we ask things like "push 'f' key  if you want to force a check" ... or something like that... in that case the system should not wait forever for a key but instead goes on and boot properly
<pitti> gaspa: ah, I see
<gaspa> ;)
<dholbach> ogra: do you still make use of human-cursors-theme or do you also use dmz-cursor-theme?
<gaspa> pitti: and for Bug #154234? I'm not sure of this. I filed it cause i wasn't able to build the package in ppa.
<ubotu> Launchpad bug 154234 in usplash "build-depend on libgd-dev " [Undecided,New] https://launchpad.net/bugs/154234
<ogra> dholbach, dmz iirc
<dholbach> right, human-* is in universe
<dholbach> I'll ask for its removal in hardy
<pitti> ah, that's a bit special; it works, because libgd2-xpm-dev (main) Provides: libgd-dev
<pitti> gaspa: http://codebrowse.launchpad.net/~gaspa/usplash/usplash-addson/revision/172 looks fine, I'll apply that
<gaspa> pitti, not at all
<pitti> gaspa: thank you for your fixes! what's the other bug#? I still didn't get mail
<gaspa> i'll write: "libgd2-xpm-dev | libgd2-noxpm-dev"
<gaspa> i think it's better
<pitti> gaspa: "libgd2-xpm-dev | libgd-dev" is best IMHO
<pitti> gaspa: make use of the virtual package, but prefer a concrete one
<gaspa> oh, right.
<gaspa> if you want, i'll push it right now.
<gaspa> (now you're subscribed to all three reports)
<pitti> doko: done
<pitti> gaspa: what's the third one?
<gaspa> ... mmm.. which are the first two? :-P :-P
<pitti> gaspa: #154234 and #152952, as above
<gaspa> all are: 152933, 152952, 154234
<gaspa> ok, 152933 then
<pitti> gaspa: splendid! thanks
 * pitti hands gaspa the "official usplash maintainer" badge
<gaspa> lol
<cjwatson> somebody's gotta be ;-)
<pitti> ah, I'm TLA now :/
<pitti> TIL even
<gaspa> pitti: i'm not even a motu. ;)
<pitti> gaspa: ^ that's "touched-it-last", and denotes the poor soul who gets all the bugs henceforth :)
<cjwatson> dholbach: my ubuntu-main-sponsors membership is about to expire; care to renew it?
<dholbach> cjwatson: sure
<gaspa> pitti, but what should happen on launchpad? now it should appear something?
<pitti> gaspa: I assigned the bugs to me and marked them 'in progress', so that I'll get to them soon
<cjwatson> dholbach: thanks
<Label> hi
<Label> I've one question
<Label> http://ubuntuforums.org/showthread.php?t=580557
<Label> Is there any issue with fonts?
 * ogra laughs 
<ogra> debootstrapping stuff under /media makes the /proc and /sys mounts of debotsrap how up on the desktop :)
<ogra> *show
<cjwatson> I think virtual filesystems should be blacklisted from showing up on the desktop
<liw> except for fuse ones, perhaps
<ogra> yeah
<cjwatson> right, but things like procfs, sysfs
<ogra> but its funny it doesnt show u in mount output
<ogra> *up
<cjwatson> ogra: it'll be in /proc/mounts
<ogra> might be (already wiped it)
<cjwatson> ogra: mount reads from /etc/mtab and if you mount something in a chroot then naturally that isn't recorded in the base system's /etc/mtab
<cjwatson> I do wish they'd fix /proc/mounts to expose the loop device information
<Mithrandir> apart from possible politics, that should be easy enough, shouldn't it?
<cjwatson> well, it's been outstanding for years
<cjwatson> I haven't looked, but guess there's some compatibility implication
<cjwatson> anyway, I'm not well-enough-informed so shall go back to prodding debootstrap
<cjwatson> (wow, hoary debootstrap installed so much crap)
 * Hobbsee curses the lack of decent scripting for irssi.  or the script that she's currently lacking.  either way.
<Spads> When will someone write a decent irssi-killer in python
<Hobbsee> Spads: i dont know.  so far, it seems that konversation is the irc client that sucks the least - and that's scary
<Spads> it has a curses mode?
<Hobbsee> nope
 * Spads puts it on the "sucks most" pile
<Hobbsee> but having to call up chanserv by hand is a ruddy pain in the neck.
<Hobbsee> particuarly when on multiple channels,
<soren> Hobbsee: http://www.pthree.org/2007/07/11/irssi-chanserv-and-nickserv-helper-aliases/ ?
<Spads> nickserv is easy.  if you put your nickserv password in as the server password in your config, it gets passed along to nickserv
<Spads> and that method is resistant to juping
<sladen> Spads: didn't know that, thanks
<Hobbsee> Spads: oh, nickserv is easy, yes.
<Hobbsee> Spads: it's the problem of having to op for every channel.  but there is a script, and i'll get my hands on it when the guy comes back
<Spads> sladen: it works more reliably on other networks, but it does work very often here
<ogra> mvo_, would it be possible to make CDs that are used with g-a-i not open a nutilus window by default ?
<Hobbsee> sabdfl: ping
<mvo_> ogra: yeah, that is currently not ideal. is there a bug about it already?
<ogra> mvo_, i dont think so ...
<fatal__> in case anyone is interested, it seems like the ubuntu iproute package fixes a problem which already has a fix in the imported debian package.... I don't know if this "double-fixing" might cause problems.... I'm updating the debian package to use the ubuntu fix, and dropping the debian/patches/ip_address_flush_loop.dpatch .... (I guess you'll get this automagically on some future sync, but thought I'd notify you guys now anyway..)
<fatal__> hth, hand.
<fatal__> btw, the debian iproute package has moved to git .... http://git.debian.org/?p=collab-maint/pkg-iproute.git;a=summary
<dholbach> MOTU meeting in #ubuntu-meeting
<dholbach> cjwatson, Riddell, slangasek, Mithrandir: we're discussing universe and hardy schedule in the MOTU meeting in #ubuntu-meeting right now
<liw> does Ubuntu have a document like the Debian Policy Manual? or a document describing differences from the Debian one?
<pitti> cjwatson: Do you have some time today for looking into d-i/dapper to install lbm?
<JohnKarahalis> Hello everyone
<pitti> seb128: would you mind if we generally drop upstream changelogs from cdbs packages?
<seb128> pitti: yes
<pitti> seb128: they are often quite large, not terribly interesting to users, and easy to get for devs by apt-get source or looking at the upstream page
<seb128> I find it really handy to have those available without having to getting megabytes of sources
<seb128> hum
<seb128> pitti: well if we really need extra space I guess it make sense
<pitti> seb128: I'm currently working on a cdbs patch to symlink identical documentation files
<pitti> seb128: in a generic fasion
<pitti> fashion
<liw> speaking as a sysadmin, I've often found it useful to read upstream changelogs when debugging things
<seb128> we should consider using 2 CDs or DVD one day rather though
<pitti> that shuold already help quite a lot, but if we would drop changelogs entirely, that would help even more
<seb128> because we start doing a lot of compromise on what we can ship due to CD space which sucks
<pitti> liw: I don't argue that they are useless, I'm just weighing CD space vs. the level of utility
<pitti> and I'd rather drop those than eternally argue about which app to kick out next
<seb128> well, I would prefer having extra translations rather than upstream changelog to be honest
<pitti> that too
<seb128> but I would like better having everything
<seb128> is switching to an another format than 1 CD on the table?
<pitti> the Debian changelog is more useful for me at least in many cases
<liw> pitti, well, I'd be in favor of changelogs over, say, oo.o or firefox, but I'm cantankerous and contrary, and I know it's not going to happen
<pitti> seb128: no
<pitti> seb128: ATM, one CD is a design goal (and you don't believe how happy I am about it...)
<pitti> well, it can always be argued otherwise, of course
<liw> any chance of Ubuntu supporting usb sticks officially some day, by the way?
<liw> (I'm all in favor of having at most one CD, personally :)
<pitti> seb128: well, if you want to include the upstream changelog in your package, nobody will stop you, btw
<pitti> seb128: it's just about not doing it any more by default
<seb128> pitti: I like really having one CD, but if it means throwing changelog, translations, limiting the inclusion of some applications, etc...
<pitti> well, let me first finish the symlinking
<pitti> that's unanimous, I take it
<seb128> pitti: I've not strong objection, I'm not sure how the userbase will react though
<seb128> liw: that should be easy enough to do and would be nice for hardy
<cjwatson> liw: we support installing from USB stick - what's missing?
<seb128> liw: there was a post somewhere (planet or list?) this week about a script from redhat, somebody adapted it to Ubuntu and it seems to work fine
<cjwatson> it's not particularly well advertised though
<seb128> cjwatson: there is no obvious way to create the key for users
<seb128> cjwatson: like a "click here to make an usb bootable key"
<liw> cjwatson, well, I looked for that option when I installed my laptop after starting to work for Canonical, and I couldn't find any documented way of doing it
<seb128> liw: there is https://help.ubuntu.com/community/Installation/FromUSBStick on the topic
<cjwatson> seb128: hence "not particularly well advertised". I agree
<seb128> cjwatson: right, I was already typing when you wrote that, I agree with you
<pitti> pong
<seb128> pitti: hi
<pitti> hey seb128 :)
<seb128> not sure why you pong-ed ;-)
<pitti> uh?
<pitti> I didn't
<liw> pitti, multiple times on some channels
<pitti> oh, argh
<pitti> that must be that test autoresponse script going wild
<pitti> sorry
<dholbach> pitti: don't say "it was the cat" - nobody will believe you
<StevenK> Hah
<pitti> seb128: thanks, fixed
<Hobbsee> pitti: you used /ame not /me ?
<Hobbsee> or /a something
<pitti> seb128: takes a little while to migrate to a new IRC client...
<pitti> Hobbsee: I didn't use any command; it was just a test autoresponder which says "pong" when someone says "ping" to me
<Hobbsee> pitti: ahhh
<pitti> I meant to disable it, but forgot
<StevenK> And it matches on "ping", not "pitti: ping"
<pitti> right
<pitti> when I actually tried it, it didn't respond to either
<Spads> haha someone said typing
 * pitti wonders why it suddenly started to work
<pitti> *blush*
<StevenK> Which is naughty, since words like 'typing' and 'zipping' ...
<seb128> pitti: which one do you use now?
<pitti> seb128: weechat
<pitti> seb128: the one and only client I found which supports vertical splitting, and it has nice scripting capabilities, too
<seb128> ah, you liked the screenshots with all the chans splitted on a same screen?
<StevenK> So many terrible places we could take that name.
<pitti> seb128: yeah, that was it; I have three vertical splits now
<pitti> without the need to sort the xchat windows every day, alt+tabbing through them, and so on
<Keybuk> cjwatson: do we want MoM to use unstable for 8.04 or testing?
<cjwatson> I meant ubuntu-devel@lists :-)
<dholbach> MOTU Q&A session in 2 minutes in #ubuntu-classroom
<StevenK> Hrm. My poor newly upgraded Gutsy machine does not like LVM.
<StevenK> Hrm. No, it's because it can't find the first hard disk.
<StevenK> Fun message during boot like "ata3: failed to recover some devices, retrying in 5 secs"
<StevenK> Looks like our good friend HPA is too blame.
<soren> StevenK: Hardy amd64 sbuilder also has all uppercase dpkg output :)
<StevenK> soren: Yay ....
<StevenK> soren: Let's file a bug this time. Then mvo can fix it. :-)
<soren> StevenK: So now we know it not the string "gutsy" that's messing it up. Big surprise.
<soren> StevenK: Yeah, and then he'll say it's dpkg... and the iwj will say it's sbuild, and then elmo will shout at everyone for not getting anything done.
<cjwatson> I'm inclined to suggest stracing the entire damn thing and look at what's fiddling with the tty.
<cjwatson> you'll get a hell of a lot of output but it's faster than bouncing it back and forward between people who can't reproduce it
<soren> cjwatson: If it was the tty that got told to spew only upper case it wouldn't be uppercase in the logs, would it?
<cjwatson> soren: you can't tell the tty to spew upper case without it showing up in strace
<StevenK> Grumble.
<soren> Also, it's only dpkg's output. Not apt or the build.
<cjwatson> we assume that it is some process under sbuild that's doing it
<StevenK> soren: Shows in the builds logs for me.
<cjwatson> therefore, strace -f sbuild
<soren> StevenK: Yes, exactly.
<StevenK> 2.6.22 doesn't boot, and 2.6.20 doesn't start X.
<cjwatson> soren: oh, I misread - but even so, strace will show dpkg printing lower case and something else printing the same thing in upper case
<cjwatson> so you'll be able to isolate from that what's at fault
<cjwatson> or if it *does* show dpkg printing lower case, then you go and beat up some mad locale definition
<cjwatson> s/lower/upper/
<soren> cjwatson: But the logs I get in my e-mail is also upper case?
<soren> cjwatson: strace and schroot is not an easy combo to work with, by the way.
<cjwatson> due to set-id?
<soren> I assume so, yes. I haven't really bothered to look into it just yet.
<cjwatson> if that's it, make a private copy of strace and make it setuid root, then use that; see strace(1)
<soren> If I just try now, I get: E: PAM error: Authentication service cannot retrieve authentication info
<StevenK> Right. X with nv
<StevenK> Now to figure out to disable HPA so 2.6.22 will actually boot
<soren> cjwatson: Didn't help. I'll try attaching to the apt-get process inside schroot when it's running. That should work.
<cjwatson> yeah
<StevenK> soren: If strace is installed inside the chroot. It might be simpler to get schroot to spawn strace apt-get.
<dholbach> can all teams please include their team reports on  http://wiki.ubuntu.com/TeamReports/October2007 ?
<StevenK> Oh, grumble.
<StevenK> Can you not disable HPA without recompiling the whole damn kernel?
<dholbach> PriceChild, mathiaz, Burgundavia, Mithrandir, superm1, popey, bryce: if you teams have, can you please include their team reports on  http://wiki.ubuntu.com/TeamReports/October2007 ?
<popey> wilco
<popey> 22nd is the cut off isn't it?
<PriceChild> gah IRC haven't had a meeting this month... will poke people about it and probably just add things we've decided outside meetings in -ops or ML for gutsy+
<dholbach> popey: jono asked me to ask people to move their stuff :)
<bddebian> Heya
<mathiaz> dholbach: sure.
<Hobbsee_> PriceChild: so stop being slack :)
 * popey makes some stuff up
<pitti> does anyone feel like eyeballing a piece of really horrible shell for me? (http://paste.ubuntu.com/1038/)
<pitti> it's a cdbs patch to symlink identical documentation files to dependent packages
<StevenK> pitti: My only thought is 'Ew' :-)
<pitti> doko, seb128: ^ you maybe?
<seb128> pitti: I'm looking at it
<pitti> StevenK: alternative approaches appreciated; this is the kind of stuff I'd rather do in a 100-line Python script, but that's inaappropriate for a cdbs rule IMHO
<StevenK> BenC: So, how can I disable HPA if I think it's the reason 2.6.22 decides to disable the SATA channel my hard disk is on...
<doko> pitti: later, away now
<seb128> pitti: I'm a bit unsure about the "iterate over Depends", it'll make the result Depends of the packages installed on the system
<pitti> seb128: I tested it with tracker, which has a lot of libraries and packaes depending on them, etc.
<pitti> seb128: well, it iterates over dependencies which are built by the same source package
<StevenK> pitti: Of course, but at this point I'd rather get my desktop machine booting. :-)
<seb128> pitti: right, but I mean what if nautilus and gedit have a common README.GNOME?
<pitti> seb128: that isn't caught with this code
<pitti> seb128: and I don't think it should be
<seb128> pitti: ah, I didn't read the code careful enough then
<pitti> seb128: so, what it does is:
<seb128> I was having a first quick looks before trying to understand the detail of the regexp
<pitti> seb128: it finds the intersection of dependencies and binaries from that source as candidates of packages to consider symlinking to
<pitti> seb128: i. e. I cannot consider *all* binaries of the source as symlink targets
<pitti> seb128: just those which the pacakge I'm editing depends on (or pre-depends)
<seb128> pitti: well, what happens if let's say nautilus Depends on gnome-control-center and they have a README identic?
<pitti> seb128: I never symlink copyright (Debian Policy), and only documentation files, since those are (1) the worst offenders, and (2) if it breaks, we don't ruin the entire system
<pitti> seb128: line 12 in the pastebin will rule it out
<pitti> seb128: since gnome-control-center is not a binary built by the nautilus source
<seb128> doh
<seb128> right, sorry, I misread this one
<pitti> np, it's really horrible
<pitti> seb128: such kind of questions is why I asked for a review ;)
<seb128> the logic looks good to me
 * pitti fixes the comment
<pitti> # fix absolute symlinks created above to relative
<pitti> that makes more sense ^
<pitti> to "be" relative
<seb128> yes, it's better
<pitti> seb128: I'm reasonably confident that it is correct
<pitti> it's not necessarily optimal
<doko> pitti: why reimplement fdupes?
<doko> pitti: there's no possibility to disable symlinking
<pitti> doko: I found it doesn't make the code much simpler, and so I can avoid the dependency and depending on the output format
<pitti> doko: ah, good point
<doko> pitti: and it doesn't help for inter-package symlinking
<infinity> pitti: What if you end up symlinking web docs, and the user's webserver doesn't follow links (for /usr/share/doc, or at all)?
<infinity> pitti: Not that two packages should contain the same web docs ANYWAY, but being unable to disable to feature seems... Likely to cause a problem for someone.
<pitti> line 10 > [ -n "$$CDBS_NO_DOC_SYMLINKING ] || ...
<popey> dholbach: done
<pitti> infinity: web docs should absolutely *not* be in /usr/share/doc IMHO
<dholbach> popey: rock on
<infinity> pitti: Ahh, I'm blind.
<infinity> pitti: And, uhm, lots are.  Always have been.
<pitti> infinity: that's why I confine it to /usr/share/doc
<doko> pitti: and it doesn't help with the bloody gnome help files
<infinity> pitti: We even used to serve /usr/share/doc from webservers by default for that reason.
<pitti> doko: as I said, it's a first start, not complete yet
<pitti> I rather do it in steps
<pitti> doko: "inter-package symlinking"?
<doko> pitti: I'm not sure if you find even one link ...
<infinity> pitti: The obscurity > security camp is the only reason we don't serve /usr/share/doc anymore, not because docs aren't there (they are).
<pitti> infinity: right, but if you explicitly server /usr/share/doc, this should be fine then?
<pitti> doko: lots (such as changelog.Debian.gz, changelog.gz, NEWS.gz, etc.)
<doko> pitti: cd debian/$(cdbs_curpkg)
<infinity> pitti: The point is likely moot, as long as the feature can be disabled, since maintainers can just clean up breakage as they see fit (only have web docs in one package, which is correct anyway, or disable symlinks, or whatever)
<doko> pitti: you can't find any duplicates you search for
<pitti> infinity: ah, point; they shouldn't really be duplicated
<pitti> doko: hm?
<pitti> doko: ah, I see what you mean; $rootdir takes care that I will
<infinity> pitti: My only practical concern is "what if people are already managing this differently, and changing CDBS breaks their carefully-mangles rules file to do something Very Bad"?
<doko> pitti: ahh, ok.
<infinity> s/mangles/mangled/
<doko> infinity: they can disable it
<pitti> infinity: do you see how it can break?
<infinity> doko: Yes, but who reads every CDBS changelog and then checks if their package build changed?
<pitti> infinity: if people already symlink it manually, that should be fine
<pitti> since this is a general and by-default rule, it should be designed not to break anything, right
<StevenK> Right. The find only looks for real files anyway
<pitti> infinity: oh, I see that bug
<doko> infinity: without it you'll never get people like our gnome maintainers to change their habits (although it's known ...)
<pitti> infinity: I shouldn't use find -L
<infinity> pitti: Say I have a setup that removes dupes forcefully and symlinks.  From the opposite package that you find first.  And I do it after this new code exeuctes.
<infinity> pitti: And I end up with packages with no changelogs.
<pitti> infinity: instead I shuold change the *target* test to -f || -L
<infinity> StevenK: You're making the same assumption pitti is... That this code will never run *before* my hypothetical custom-mangling code.
<StevenK> infinity: Ah ha
<infinity> (So, you remove a dupe, add a a link, then I blindly "rm -f foo/changelog", which was the only "real" one left, because CDBS and I disagreed about which to keep)
<pitti> http://paste.ubuntu.com/1040/
<doko> infinity: well, it runs in dh_builddep ?
<pitti> ^ new version with "disable" variable and symlink fix
<pitti> infinity: no, since any code you run afterwards cannot change the .deb any more
<mathiaz> dholbach: I've added the ServerTeam report to the Monthly report.
<pitti> infinity: since that very rule calls dh_builddeb
<dholbach> mathiaz: rock on
<dholbach> :-)
<pitti> infinity: and any code you run before is fine, since I only look for real files, not for symlinks
<infinity> pitti: Kay, I admit to being mostly CDBS illiterate (by choice)... There's no way to modify the builddeb phase with rules?
<pitti> infinity: there are quite a lot of hooks
<infinity> pitti: If not, then my concern seems to be addressed.
<infinity> pitti: If it can be hooked/altered, then it still stands.
<pitti> infinity: but I deliberately put that code in between dh_gencontrol and dh_builddeb (which are in the same rule)
<doko> pitti: where's the variable?
<pitti> infinity: i. e. there is binary-predeb which you usually do to chmod files, remove files, etc.
<pitti> doko: I suck, wrong paste
<pitti> http://paste.ubuntu.com/1041/
<pitti> try again
<pitti> infinity: in the diff context you still see the dh_builddeb call at the very bottom
<infinity> pitti: Ahh, so I do.
<infinity> pitti: Alright, seems to address that concern, then.
<pitti> infinity: I need to do it after dpkg-gencontrol to see all dependencies, and before dh_md5sums to avoid mangling it agai
<pitti> W: tracker-utils: debian-changelog-file-is-a-symlink
<pitti> bah, lintian
<infinity> Does it have a direct dep?
<infinity> lintian's not supposed to warn on linked-docs-with-direct-deps...
<pitti> yes, it has (it doesn't consider any others)
<infinity> Or maybe it's only smart enough to do the doc directory, not files.
<pitti> it could be made more efficient by also considering transitive dependencies, but I guess that code will give us 90% of the effect already
<infinity> Easy enough to fix lintian, your solution is policy-compliant.
<infinity> Oh, wait.
<infinity> Uhm.
<doko> if [ ! -h debian/$$dep/usr/share/doc ] && [ -d debian/$$dep/usr/share/doc ]
<infinity> You realise dpkg behaves pretty "special" when files change to links, right?
<doko> pitti: ^^^
<infinity> (Not as bad as when directories do...)
<pitti> infinity: well, I do know that it is spethial when directories change to links; which is why I don't touch directories at all
<pitti> doko: ah, can do
<pitti> doko: hm, wait; why for the depending package? that shouldn't matter
<infinity> pitti: For peace of mind, build on of these sets of packages, and upgrade one that got itself symlinks (but not the dependency)... And make sure dpkg didn't do anything weird.
<pitti> doko: I need to add a check that $(cdbs_curpkg)/usr/share/doc isn't a symlink
<doko> pitti: that as well
<infinity> pitti: Weird things may include unpacking the links, then following them when "removing old files", and other really bizarre stuff.
<doko> pitti: do you miss indirect depends?
<pitti> doko: yes, I do, see above (first correctness, completeness later)
<pitti> infinity: dpkg follows symlinked files? eww
<infinity> pitti: It's had such bugs in the past.  I'd want to verify that it no longer does. :)
<infinity> pitti: It's not SUPPOSED to.
<pitti> infinity: ok; I could imagine that this would wreak havoc in interesting ways
<StevenK> Oh, I forgot about that. Now that I've upgraded, tracker is taking over my machine.
<Hobbsee> StevenK: it hasnt taken over mine yet.  i'm really wondering why.
<pitti> infinity: at least I can dpkg -i the old and new package back and forth, and both symlinks and files work fine
<infinity> pitti: Alright, good, good.
<pitti> seb128, doko, infinity, StevenK: thanks for your review!
<seb128> pitti: thanks for the work on that ;-)
 * seb128 hugs pitti
<StevenK> pitti: I don't see what I did, but sure. :-)
<infinity> StevenK: Same thing I usually do.  Be grumpy while pitti makes random changes and blames his improved code quality on your grumpiness.
 * StevenK grins
 * pitti wonders why his shiny new tracker package still doesn't have any symlinks
<Hobbsee> pitti: it has a crackmeter.  if the level is too high, no symlinks for you!
<pitti> seb128: wouldn't it make -- kind of, just a little -- sense if tracker actually depended on any of the libtracker* stuff?
<pitti> hm, I guess the daemon doesn't use any of its own client libs
<StevenK> Nice how tracker-status doesn't actually work
<pitti> although this proves that my code DTRT, it's still weird
<jamiemcc> pitti: they are client side libs only
<StevenK> So, if I start something that grabs a shedload of CPU, should tracker stop using CPU time and heel?
<seb128> pitti: right, it doesn't use those libs
<pitti> jamiemcc: ah, ok
<Hobbsee> pitti: DTRT?
<infinity> Hobbsee: Do The Right THing.
<pitti> Hobbsee: "throws a gummy bear at Hobbsee"
<Hobbsee> infinity: ahhh
<Hobbsee> pitti: :P.  i dont eat lollies.
 * Hobbsee throws the gummy bear to infinity
<pitti> gummybear != lolly
<infinity> Hobbsee: Neither do we, we just lob them at each other.
<infinity> Hobbsee: You should have seen the laptop damage at UDU...
<dholbach> mentos! :)
<Hobbsee> infinity: i did :D
<Hobbsee> infinity: for sevilla, anyway
<Hobbsee> pitti: they class as a lolly in my book
<Spads> MENTOS DO NOT BURN
<Hobbsee> infinity: oh, udu.  right
<infinity> Hobbsee: High velocity Mentos = Very Bad for laptop screens.
<Hobbsee> Spads: really?
<Hobbsee> infinity: hahhaa, yes
<JohnKarahalis> Hey, everyone.
<pitti> Hobbsee: hm, in my country, a lolly is a round piece of candy on a stick
<infinity> Spads: Peeps do, though.
<StevenK> infinity: Who coped a dented laptop screen?
<infinity> pitti: That's a lolly-pop.  Australians, however, refer to anything vaguely candyish as a "lolly"... And I imagine that's of British origin.
<soren> Would it be confusing if I started filing sync requests already?
<Spads> Hobbsee: three independent reports here: http://www.pigdog.org/naked_splicer/html/tnipnaz.html
<Hobbsee> infinity: excluding chocolate
<dholbach> http://images.google.com/images?q=lolly - hm
<infinity> StevenK: Daniel's took damage, and I think one of thom's many dents was from UDU.
<infinity> StevenK: Others likely suffered too.
<ScottK> soren: If you did, you wouldn't be the first.
<StevenK> Neeat
<pitti> soren: no, that's fine
<pitti> soren: there are quite a couple of them already
 * dholbach did today :)
 * Hobbsee has a sudden, unpleasant thought
 * ScottK did 9 or 10 yesterday.
<JohnKarahalis> I was wondering, does anybody in here work for Canonical?
 * pitti whistles innocently
 * infinity points at someone else.
<Hobbsee> no, no, anyone who works for canonical we took out and shot.
<JohnKarahalis> no one? Is it still night time in Canonical HQ? I tried last night but not many were around then eihter.
<Hobbsee> !hungover
<Hobbsee> but now it's all the canonical employees, not just the release manager
<JohnKarahalis> So are you all pretty much volunteers?
<dholbach> !hangover
<pitti> JohnKarahalis: quite a few of us are; why?
<dholbach> hrm :)
<Hobbsee> dholbach: bot is lagged, i think
<JohnKarahalis> oh really
<Hobbsee> (again)
<JohnKarahalis> good
<Hobbsee> !ping
<pitti> ubotu: *shake*, wake up
<agoliveira> At least the ones who matter :)
 * agoliveira ducks quick!
<infinity> agoliveira: Tsk.
<JohnKarahalis> Well. I'm a first year SE major at RIT. As part of a project I am required to have a short interview with a professional Software Engineer (or computer scientist, you know, anything along those lines). Would anyone be interested in conducting a short interview with me. It wouldn't be long. Mainly questions like "What is a typical day at work like?", "How big is your project team", "What languages and technologies do you use?" Would anyone be
 * Hobbsee beats agoliveira
<Hobbsee> pitti: you'll make him fall over more, doing that :)
 * agoliveira falls in love for Hobbsee
<Hobbsee> oh dear.
 * Hobbsee is very unlovable, she assures you.
<soren> pitti: Ok, rock. I'll start filing them. Thanks.
<agoliveira> Hobbsee: I'm married, I know how it goes :-D
<Hobbsee> agoliveira: :P
<Hobbsee> agoliveira: glad to hear it.  i'm not interested in ubuntu to meet a boyfriend, per se.
<infinity> Hobbsee: Ouch, I'm crushed.
<Hobbsee> infinity: "You Poor Bastard"
<dholbach> where's the CoC police?
<Hobbsee> dholbach: kickbanned.  i have ops in here.
<agoliveira> JohnKarahalis, many people here can help but we all have some sort of different attributions. I, for example, work on the embedded project, doing mostly packaging for now and a bit of software development but if you think I can help, just call me in private
<agoliveira> Hobbsee: Would be a very poor place to find one anyway ;)
<JohnKarahalis> agoliveira: What do you mean by packaging?
<agoliveira> JohnKarahalis: Create software packages in a format that a distro can understand, install, uninstall, etc. In our case, .deb. pcakages.
<agoliveira> packages
<JohnKarahalis> agoliveria: ahh right that's what I thought. Just wondering because my school has a degree in "Packaging Science" as in physical packages. :P
<JohnKarahalis> agoliveria: Anyway, do you think you would want to participate. It wouldn't take more than 10-20 minutes to answer the questions probably, but I understand that you're all very busy so if you can't that's fine.
<SlimG3> Is there any (plans for) logos representing the (current) ubuntu release codename? like a drake for dapper drake, this would be doable since all the codenames represents animals in different "moods"
<ubotu> The Release Managers are currently hungover, and wont be releasing gutsy today.  No gutsy for you!  NOT YOURS!!!
<Hobbsee> sheesh.  have some lag!
<sladen> JohnKarahalis: I suspect lots of people will help;  might be better to ask via the mailing list though, and none of the people here are likely to be "typical" software people
<agoliveira> JohnKarahalis: I would love to help. I just can't do this right now but if you poke me in about 1 hour, I think I'll be able to help.
 * agoliveira thinks that ubotu snapped :)
<JohnKarahalis> agoliveria: Awesome, thank you! I actually have a class in a little bit, but when would be another good time to contact you? I have about 2 weeks before this paper is due, so no rush.
<persia> agoliveira: It's the bug count - ubotu keeps getting in trouble for flooding.
<sladen> telflon flood-resistant upgrades for ubugtu
<agoliveira> JohnKarahalis: So call me monday.
<JohnKarahalis> Cool, what time? And IRC?
<soren> pitti: Even though filing sync requests is ok, I don't suppose uploading new stuff is kosher at this point, is it?
<sladen> Hobbsee:
<cjwatson> sladen: depends how you count it. I certainly have been a traditional software engineer, though that's not so much what I'm doing at the moment
<cjwatson> soren: you can upload, it just won't be accepted yet
<pitti> soren: you can upload away, it'll land in unapproved
<soren> cjwatson: Oh, ok.
<agoliveira> JohnKarahalis: about this time is fine
<SlimG3> Is there a dedicated channel for the ubuntu graphics/design/theme apartment?
<soren> I for some reason assumed we were supposed to wait.
<Hobbsee> sladen: ?
<sladen> SlimG3: #ubuntu-art
<sladen> Hobbsee: tab Ã¼ber completetion
<agoliveira> JohnKarahalis: Just look for me on freenode and call me.
<Hobbsee> sladen: ahhh
<JohnKarahalis> agoliveria: Great! Thanks! And if you don't mind me asking, what is your official title?
<SlimG3> thanks sladen
<JohnKarahalis> agoliveria: And, sorry, but what do you mean by call? I'm new to IRC. Is a "call" like an IM?
<sladen> Job title: Typical Software Programmer #437
<agoliveira> JohnKarahalis: You know what? I don't have the slightest idea :-D
<JohnKarahalis> agoliveria: haha that's fine, I have a general idea of your responsibilities, thats all my prof needs
<agoliveira> JohnKarahalis: Yes, you can just open a private conversation like on IM.
<JohnKarahalis> agoliveira: Awesome. Thanks so much for participating!
<agoliveira> JohnKarahalis: My pleasure
<pitti> doko: what did you mean with gnome help files?
<pitti> doko: ah, symlinking identical pngs, and so on?
<doko> pitti: yes. but IMO large -help guides should be splitted out anyway (like it's already done for gimp)
<pitti> doko: right, but lots of small changes will help as well
<doko> sure
<pitti> doko, seb128: so I do the same "symlink to depending packages" trick for /usr/share/gnome/help?
<seb128> pitti: /usr/share/gnome/help should not be duplicated
<doko> seb128: did you change it?
<seb128> pitti: do you have any example of where it happens?
<seb128> doko: change what?
<doko> seb128: gnome-games, totem,
<seb128> doko: what is duplicated in totem?
<doko> pitti: all the packages that were rejected before release
<seb128> doko: and no, user help should not be splitted from the package
<doko> seb128: then fix gimp
<seb128> doko: what about gimp?
<doko> seb128: it has splitted user help
<doko> seb128: OOo as well ...
<seb128> doko: that's a different source package which contain those
<seb128> that's not part of the program
<doko> seb128: how do you decide this?
<seb128> doko: decide what?
<doko> so the list is: gnome-applets gnome-games gnome-power-manager gnome-utils totem tomboy
<doko> seb128: "that's not part of the program"
<seb128> doko: apt-cache showsrc gimp-help
<seb128> it's gimp-help
<seb128> it's not from the gimp upstream tarball
<seb128> I didn't decide it
<seb128> upstream did
<doko> seb128: sorry, that's a bogus argument; with the same argument I can add all the OOo help to OOo-common
<seb128> doko: I think it makes no sense to remove the user documentation from programs
<doko> pitti: you find the list of all current duplicates in the liveCD build log
<seb128> most users expect F1 to work
<seb128> and to have documentation
<persia> Is it possible to do something at install time, with the right hints?  The packages will not get smaller, but the footprint will, and users will never not have the basic docs.
<doko> seb128: yeah, but we do have to make compromises due to CD size. OOo opens a dialog and asks the user to install the help package. sure you could do better offering an option to start the installer/update manager
<seb128> we surely don't want to start doing that for every desktop application
<seb128> and I'm not sure we need that much space yet
<seb128> let see how it goes without the duplication
<doko> sure, removing gnome-games from the CD is an option as well
<doko> seb128: we already know, we do have the numbers
<seb128> doko: gutsy was not oversized and we will win extra space with the cdbs change, what do you need space for now?
<doko> seb128: translations
<doko> seb128: java plugin for the browser
<seb128> we should not start creating complication and make users run installers when clicking on an help menu only for the sake of having free CD space we don't use
<doko> looking away from cd sizes is "creating complication" ...
<seb128> ?
<pitti> seb128, doko: so while the separation of help into extra packages is debatable and should be decided on a case-by-case basis, symlinking identical files should be ok, right?
<pitti> doko: I'll test it with gnome-power-manager and gnome-utils
<seb128> pitti: if that actually works yes
<doko> pitti: yes, if you can turn it off; I think turning it on by default is the right thing to do
<pitti> seb128: right, of course
<seb128> pitti: dholbach tried on ubuntu-docs before gutsy no?
<pitti> I don't know
<doko> ubuntu-docs is fixed
<pitti> mvo: can I ask you to verify bug 152113?
<mvo> pitti: let me have a look
<pitti> mvo: I'd like to put it into -updates today, so that we fix feisty->gutsy upgrades ASAP
<mvo> pitti: oh, gutsy was missing?
<pitti> mvo: the actual upgrade breakage is bug 116193 (fixed in the same upload)
<mvo> pitti: ok, I check this out
<pitti> mvo: yes, gutsy-proposed didn't have builds yesterday
<pitti> mvo: thank you!!!
<sladen> seb128: I would *love* if F1 didn't work.  It pops up everytime I try and aim for escape
<sladen> separating docs out helps the embedded case
<seb128> sladen: not really, or it needs to be made in a smart way, not by just not installing those and having a broken menu item
<pitti> slangasek: swapping caps lock and escape works *wonders* for us vimers :)
<pitti> (except that I always erroneously switch on caps lock when I sit on a different computer than mine)
<ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [High,In progress] https://launchpad.net/bugs/152113
<ubotu> Launchpad bug 116193 in tzdata "error upgrading tzdata_2007e to tzdata_2007f" [Critical,Fix committed] https://launchpad.net/bugs/116193
<slangasek> pitti: what does one switch tab with to avoid nick collisions? ;)
<pitti> that is still a mystery to be solved
<pitti> seb128: tested now; images in yelp do break with broken symlinks (so I rule out caching), and work again with fixed symlinks
<RvGaTe> heya
<pitti> seb128: that rule indeed buys us quite a lot of space without any noticeable behaviour change
<RvGaTe> i thought i'd come in here to report that some hardware is not supported by default...
<seb128> pitti: good ;-)
<pitti> doko: I shamelessly stole the basic approach from your g-p-m upload :) (although I do not modify debian/<package>.links, I think this is too evil)
<pitti> cjwatson: would you mind if I upload and accept cdbs? it's arch-all, toolchainish, and I'd like to have it before we start the rush of syncs and Gnome packages, for maximum effectiveness
<RvGaTe> with this setup: motherboard, Abit IP35-E. And a hdd, Western Digital Caviar SE 200GB 7200rpm S-ATA..... is not detected the hdd... making it unable to install.... if you need any stats, just ask... (if you have a solution, #ubuntu ofc... :P)
<cjwatson> pitti: not at all
<pitti> seb128: that also means that we can probably drop most of the hacks from evolution et all
<pitti> seb128: s/all/al/, d'oh my Latin
<doko> pitti: all such packages like debhelper, devscripts should be uploaded now
<pitti> right
<seb128> pitti: good ;-)
<seb128> doko: is hardy open yet?
<cjwatson> https://wiki.ubuntu.com/NewReleaseCycleProcess
<cjwatson> somebody should merge base-files
<cjwatson> (and change it for hardy)
<doko> ok, doing ...
<cjwatson> the debootstrap change in question is syncable from unstable (or will be soon) whenever somebody feels the urge; but note that debootstrap-udeb has C code so it should wait until doko's happy with the compiler
<doko> the buildds are still happy building it ... ;)
<Hobbsee> doko: pedal faster...
<cjwatson> doko: are you planning to upload glibc afterwards?
<cjwatson> (still 2.6 rather than 2.7, I assume from our earlier discussions0
<cjwatson> )
<doko> [ Uploading job glibc_2.6.1-6ubuntu1_source
<doko>  glibc_2.6.1-6ubuntu1.diff.gz 676.1 kB, ok (15 s, 45.08 kB/s)
<doko>  glibc_2.6.1-6ubuntu1.dsc 2.2 kB, ok (0 s, 2.21 kB/s)
<doko>  glibc_2.6.1-6ubuntu1_source.changes 11.4 kB, ok (1 s, 11.35 kB/s) ]
<cjwatson> aha
<doko> has a b-d on the new gcc, so accepting should be ok (plus gcc-snapshot)
 * pitti pokes gutsy-proposed queue
<pitti> seb128: so, as discussed, we'll push gnome* gutsy-proposed under a blanket approval and have it publicly tested extensively until after allhands, right?
<seb128> pitti: yes please
<doko> pretty please have a look at the pango changes first ...
<seb128> pitti: I've only uploaded safe updates and read debdiff until now
<pitti> seb128: you rock! :)
<pitti> doko: yes, I'll process the entire queue now
<doko> pitti: I mean *look* at the diff, and/or test OOo / firefox with the new version
<pitti> asac, Riddell: please do follow the SRU rules for SRU bugs (subscribe ubuntu-sru, gutsy and hardy tasks, etc.); otherwise this will fall off my radar
<seb128> pitti: the only one which has non trivial changes is gnome-games which should be ok, that's only games and upstream said the code was not used
<pitti> cjwatson: aah, the traditional vim upload \o/ (not accepting yet, though)
<cjwatson> heh, wasn't me this time :)
<pitti> which reminds me that I need to merge mutt :)
<slangasek> haha, best autoresponse evar on ubuntu-announce from a hotmailer: "You e-mailed <foo>@hotmail.com, this is no longer my e-mail address anymore<br><br>Since Microsoft is communist, it does not let me forward my e-mail, so i am stuck with this automated reply"
<pitti> bdmurray: would you have some time to SRU-verify bug 152113? that'll include the fix for bug 116193 which breaks an awful lot of upgrades and thus I'd like to get it out ASAP
<ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [High,In progress] https://launchpad.net/bugs/152113
<ubotu> Launchpad bug 116193 in tzdata "error upgrading tzdata_2007e to tzdata_2007f" [Critical,Fix committed] https://launchpad.net/bugs/116193
<Spads> slangasek: haha yeah, I get those too
<bdmurray> pitti: let me look at the report
<sladen> slangasek: must admit, "communist" would not have been the first word that came to mind
<pitti> doko: there is no pango in gutsy-proposed, BTW
<slangasek> sladen: that's what's great about it :)
<doko> pitti: and no glib?
<pitti> doko: no
<doko> fine =)
<pitti> doko: was it meant to?
<doko> I don't know
<doko> pitti, cjwatson: http://people.ubuntu.com/~ubuntu-archive/queue/ doesn't show hardy yet
<bdmurray> pitti: only gutsy needs verification?
<pitti> bdmurray: yes, dapper/feisty/edgy are already verified by mvo and in -updates
<pitti> bdmurray: mvo is on it, too, now (he just told me)
<bdmurray> pitti: okay, I'll let him do it then. ;)
<bdmurray> pitti: is -proposed available now?  I was looking at verifying the kopete crash with msn bug too
<pitti> bdmurray: yes, it works; I'm just processing the queue, most stuff is flushed
<pitti> bdmurray: will still take some 3 hours to build, though
<pitti> (and get into the archive)
<bdmurray> pitti: okay, it is still early here
<mvo> pitti: verification daeon
<mvo> done
<bdmurray> mvo: I was looking at some update-manager bugs and noticed a couple with errors regarding medibuntu
<cjwatson> doko: fixed
<mvo> bdmurray: oh? can you give me a example please?
<bdmurray> bug 153958
<ubotu> Launchpad bug 153958 in update-manager "update-manager problem when upgrading from Feisty to Gutsy" [Undecided,Incomplete] https://launchpad.net/bugs/153958
<doko> pitti: maybe accepting OOo at this point waiting for the bootstrap is not helpful
<superm1> mvo, how come the extra repos aren't disabled before the package lists is updated to run update-manager's dist-upgrade?
<superm1> i ran into something similar a few releases back, but never queried further into it
<doko> trying to lower the build score by hand
<superm1> mvo, it appears that they are disabled after the apt-get update
<mvo> superm1: its important that it knows where it starts from, its important for the calculation of obsolete packages
<superm1> mvo, but what about cases like this that the old repo is no longer valid?
<mvo> superm1: it basicly compare the packages that are not downloadable anymore before and after the upgrade to figure out what is no longer needed
<superm1> mvo, is there a better way to handle that
<superm1> or not necessarily no longer valid, but perhaps not contactable at that time
<superm1> perhaps catching the IOError, but still heading forward?
<doko> cjwatson, pitti, seb128, Mithrandir: please approve gcc-4.2 in binary NEW
<geser> does somebody know what happened to the accepted packages for gutsy-proposed?
<geser> or where they are currently?
<joshk> does any ubiquity-automation documentation exist, or am i going to have to trawl through the source
<joshk> ?
<bdmurray> I think there was a post to ubuntu-devel or ubuntu-devel-announce about it recently
<evand> joshk: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-October/002001.html
<joshk> evand: cool! thanks.
<joshk> so automatic-ubiquity will generate a preseed file after a normal attended install?
<evand> no
<joshk> oh, i get it
<evand> you need to generate a preseed file yourself
<evand> hit f6 at the CD bootloader (isolinux)
<evand> and append url=http://yoursite/yourpreseedfile.seed
<evand> the values in that file will get pulled into debconf
<evand> which will be used by ubiquity
<joshk> yeah, got it
<evand> ok, great
<evand> if you have any questions, feel free to ask them here (though #ubuntu-installer would be more appropriate) or drop me an email.
<joshk> hm, partman crsahed
<evand> Yikes.  If this was using the automated installer, file a bug against ubiquity and attach /var/log/syslog and the preseed file you used.
<evand> well, either way file a bug :)
<joshk> i'm betting my preseed file isn't working, since i last used it with feisty
<joshk> in short: ubiquity/components/partman.py:360, assertion failed
<evand> hrm, you may be missing a question or two.  Check it against the preseed file I posted in that email to ubuntu-devel-discuss.
<joshk> yeah
<joshk> brb
<cjwatson> though it's still a bug if it fails an assertion
<cjwatson> joshk: hey, didn't you use to hack on partman? we could do with more people working on ubiquity's partman integration ... ;-)
<cjwatson> basically it'll fail that assertion if it doesn't go through ok_handler with partman-auto/{init_,}automatically_partition as the current question
<cjwatson> which may be a little too fragile ...
<lamont> Do you want to continue [Y/n]?
<lamont> E: Internal Error, Could not perform immediate configuration (2) on libc6
<lamont> hrm.  I hate it when dist-upgrade says that
<cjwatson> at some point I must grab Ian and find out what that means
<elmo> it's an apt thing?
<elmo> I thought
<elmo> and had to do with not being able to break dependency loops (or whatever) for essential (or virtually essential like libc6) packages
<cjwatson> hmm, you're right
 * mvo_ hides
<pitti> geser: gutsy-proposed binaries should be accepted automatically (unless they are new, of course, but that shouldn't happen)
<pitti> mvo_: ah, there you are; my /query timed out on 'mvo' :)
<[knap]> hello, any ubuntu audio team member?
<Amaranth> mvo_: We missed a couple things for the blacklist
<Amaranth> mvo_: And maybe we should use --indirect-rendering again for nvidia now that the driver is fixed
<Amaranth> mvo_: So people don't get the memory leak thing as quickly (or at all depending on their hardware)
<ajmitch> hi
<pitti> mvo_: thank you for verifying
<[knap]> or anyone involved with alsa
<ajmitch> Amaranth: why would compiz refuse to use gtk-window-decorator? it looked weird upgrading compiz on my laptop (was a few weeks old) & the window decorations changing
<Amaranth> ajmitch: If you have emerald installed it uses it
<ajmitch> I can run gtk-window-decorator manually & it worked, I just never saw where it got set
<ajmitch> interesting
<ajmitch> is that optional, or it just happens?
<pitti> doko: meh, lots of -dbg
<[knap]> why isn't this bug fixed? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/93859
<ubotu> Launchpad bug 93859 in linux-source-2.6.20 "[Feisty] Very low volume on Toshiba satellite a100-155" [Medium,Confirmed]
<[knap]> it is araound since 7.04
<[knap]> still happens with 7.10
<pitti> doko: done
<LaserJock_> [knap]: well, the simple answer is because nobody's fixed it
<[knap]> I would fix it myself if I had the knowledge, does this have to be fixed with the alsa guys or here in ubuntu?
<evand> isn't model=auto the default for snd-hda-intel anyway?
<[knap]> evand the line "options snd-hda-intel model=auto" doesn't exist in /etc/modprobe.d/alsa-base
<evand> [knap]: my point is that I'm not sure it needs to be.
<[knap]> ok, I don't know but it fixes the problem
<[knap]> so is there anything i can do to get this fixed?
<LaserJock_> [knap]: you could talk to kylem or TheMuso about it, I think they're in charge of the audio team
<[knap]> LaserJock_ ok i will try that, thanks
<Vlet> How much space does a full mirror occupy?
<LaserJock_> of the archive of .isos
<LaserJock_> *or .isos
<Vlet> the archives
<LaserJock_> hmm, I think it's something like 40GB for i386 and amd64
<geser> Vlet: for one or all archs? for one release or all?
<Vlet> geser: Well, depends on how much space each release occupies. I would like to at least get each arch for gutsy. I know many people here on campus running ubuntu, so I thought a local mirror would reduce load on other mirrors
<geser> 40 GB for i386 and amd64 for gutsy is a good estimate
<Vlet> thanks. I just wanted to make sure the machine I have had enough space before I started rsyncing
<geser> Vlet: http://www.ubuntu.com/getubuntu/mirror
<cjwatson> for reference, feisty+gutsy main+restricted amd64+i386+powerpc+source is:
<cjwatson> 30599976        /mirror/ubuntu
<cjwatson> of course that may be a totally useless number to you if you want to mirror universe+multiverse too
<geser> Vlet: according to that page the complete archive is around 170 GB (I found a site mentioning it around 200 GB)
<LaserJock_> hmm
<LaserJock_> I should talk to the CS department at my uni about mirroring
<LaserJock_> 170GB isn't really that much space wise
<LaserJock_> bandwidth around campus at least wouldn't be much
<ivoks_> 230GB is official mirror of all archs
<ivoks_> but that will grow with new releases
<ivoks_> hr.r.u.c is nearing 1TB of traffic :)
<ivoks_> (in two days)
<Vlet> I seeded 86 gigs of the iso today :)
<LaserJock_> it'd be interesting to get bandwidth numbers for all the official mirrors for the first week of Gutsy release
<cjwatson> cjwatson@rookery:~$ du -s /srv/archive.ubuntu.com/
<cjwatson> 174628444       /srv/archive.ubuntu.com/
<cjwatson> FWIW
<LaserJock_> thanks
<cjwatson> non-ports
<LaserJock_> does that go back to breezy?
<ivoks_> breezy wasn't first ubuntu :)
<LaserJock_> ivoks_: I'm aware of that
<cjwatson> LaserJock_: no, breezy isn't on archive.ubuntu.com any more
<LaserJock_> right
<Burgundavia> LaserJock_: what we really need is more crappy bandwidth country mirrors, but another mirror is always good, I suppose
<LaserJock_> Burgundavia: well, it'd probably be a uni-only mirror I'd guess
<LaserJock_> I don't seem like my uni cares much for Linux in general, let alone Ubuntu
<LaserJock_> but I might convince them that providing a mirror for the uni would be chep
<Burgundavia> it is a good way to get Ubuntu in
<LaserJock_> I gotta get them to stop shutting down linux labs
<LaserJock_> :(
<hunger> I get a invalid signature from the ubuntu archive automatic signing key on gutsy-proposed.
<gcarrillo> hi all
<gcarrillo> does anybody know of an online browser for GNU source?
<hunger> gcarrillo: ?
<gcarrillo> does that mean the question was unclear or that you don't know :)
<hunger> gcarrillo: I don't know what you want.
<hunger> gcarrillo: A online browser as in some app to look up docs on the internet? firefox springs to mind here... ;-)
<gcarrillo> sorry no
<gcarrillo> http://cvs.opensolaris.org/source/
<gcarrillo> for example
<gcarrillo> thats the source browser for opensolaris
<hunger> gcarrillo: I am not aware of something like that.
<gcarrillo> i wonder if theres something similar for gnu
<gcarrillo> ok
<hunger> gcarrillo: Some projects offer it, but more on a per-project base.
<gcarrillo> i wanted to look at the source for echo
<hunger> gcarrillo: There is no central entity that can collect all the source and stuff:-(
<gcarrillo> i thought gnu was the central entity for the userland stuff like that
<gcarrillo> like command line tools and such
<hunger> gcarrillo: "apt-get source bash" will get it for you.
<gcarrillo> oh cool
<gcarrillo> thanks ;)
<hunger> gcarrillo: Nothing gnu related, just normal ubuntu/debian goodness. You can grab the sources of everything in the main/universe/multiverse repositories that way.
<gcarrillo> ok so where in my fs will that source live?
<gcarrillo> once i've apt-get'd it
<geser> gcarrillo: in a dir below $PWD
<gcarrillo> oh sorry
<gcarrillo> dumb question
<mdke> how does one get a package removed from the archive? just a regular bug report?
<geser> mdke: yes, plus the usual sponsoring for non-MOTUs/non-core-devs
<mdke> geser: so I just subscribe the sponsor group and ask them to remove the package? I thought it was much harder :)
<slangasek> hmm? what sponsoring is involved in removing a package?
<sistpoty> mdke: you should have a good reason though :P
<mdke> sure
<mdke> slangasek: I dunno, I was asking
<slangasek> yes, I'm questioning geser's response
<geser> slangasek: only the ACK from a MOTU/core-dev is the reporter is none before subscribing ubuntu-archive
<slangasek> ah
<mdke> right, I see
<geser> MOTUs/core-devs can directly subscribe ubuntu-archive to the remove request/bug
<mdke> ok, I'll do that. Thanks
<mdke> actually, perhaps it's not necessary. The packages i had in mind (ubuntu-quickguide and ubuntu-faqguide) don't appear to be in the archive, they are only in my tab completion for apt-get install... perhaps a remnant of having a system upgraded over many releases
<geser> packages.u.c doesn't know any of them (also for past releases)
 * mdke nods
<mdke> my bad
<mdke> anyway, useful to know how to do it, sorry for the timewasting
<geser> np
<purpleposeidon> To the individual who thought that using UUIDs for all of the disks was a good idea: Please type=UUID=9dd73528-841d-4ced-a0fc-be130e88a5de  at least 7 times.
<purpleposeidon> I'm sure you'll soon be almost as good as me at typing it.
<sistpoty> for i in 1, 2, 3, 4, 5; do echo UUID=9dd73528-841d-4ced-a0fc-be130e88a5de; done #:P
<sistpoty> (sorry, couldn't resist)
<TheMuso> sistpoty: lol. The slight inconvenience of typing it pays off in the end.
<TheMuso> Many a time a UUID instead of a device node has helped me considerably.
#ubuntu-devel 2007-10-20
<purpleposeidon> TheMuso: Howso?
<TheMuso> purpleposeidon: UUIDs save you from having to re-adjust your fstab if you move a hard disk containing a Linx install from one computer to another for example.
<TheMuso> In my case, I swapped out a PCI controller for another one in a box, and Linux just came up working, thanks to UUIDs.
<TheMuso> Device nodes may work, but there is certainly no garentee that they will be the same for new hardware.
<purpleposeidon> What happens to UUIDs when you modify partitions?
<slangasek> UUIDs are embedded in the filesystem metadata
<TheMuso> purpleposeidon: I don't know.
<TheMuso> slangasek: thanks I was wondering that
<purpleposeidon> Well, it would be a nice to make them just a little bit shorter. Or descriptive.
<slangasek> if they were shorter, they wouldn't be UUIDs
<slangasek> if they were descriptive, they would be labels rather than UUIDs :)
<purpleposeidon> So.... why not labels then?
<slangasek> I don't know, I wasn't involved in the choice
<Spads> there are some catastrophic failure modes involving stale label values
<slangasek> perhaps because in the general case you want to use something automatic in the installer, and dual-booting can easily result in conflicting labels
<sistpoty> TheMuso: hah (btw. seems that I've been having an enourmous lag right now, as 1 and a half minute of text suddenly popped up in my irc)
<TheMuso> sistpoty: ouch
<sistpoty> well, known problem for me, also known fix... /me needs only to call my isp *g*
<TheMuso> heh
<purpleposeidon> !UUID
<ubotu> To see a list of your devices/partitions and their corresponding UUID's, run this command in a !shell: Â« sudo blkid Â» (see https://wiki.ubuntu.com/LibAtaForAtaDisks for the rationale behind the transition to UUID)
<rstanca> hello, if I customize the livecd(add new packages to it) will the new packages be installed too(when I'll do an hd install) or there's something else I should do? (I found docs from here https://help.ubuntu.com/community/LiveCDCustomization )
<ubuntu> i can't belevice
<BigPick> A user named ubuntu... thats different.
<ubuntu> that someone persons here didn't make good the gutsy
<Jordan_U> BigPick, It's because he is connecting from a LiveCD session and that is the default
<ubuntu> and i download yestrday this 7.10 and now i have much error
<BigPick> Ah ha, I see.
<Hobbsee> and support is in #ubuntu
<ubuntu> this peoples who make gutsy are sucking
<pwnguin> ubuntu: before you go blaming the developers, make sure your disc burned okay :P
<Hobbsee> ubuntu: if you want support, #ubuntu.
<ubuntu> Hobbsee and the bad peoples making ubuntu are here
<Hobbsee> if you want to troll, you can have a kickban.
<Jordan_U> ubuntu, If you want to yell at someone pay for commercial support,
<ubuntu> i will go and sleep,you are having problems,making shits and then the peoples install it,bah 7.04 was working good,and every times the new version is bad.
<minghua> Hobbsee: It would be a bit disheartening to kickban "ubuntu" user though. :-(
<Hobbsee> minghua: you assume that i plan to kickban by username.
<BigPick> Didn't know you could do it by ip.
<Hobbsee> you can.  otherwise it'd be pretty pointless.
<BigPick> Ah, good point.
<BigPick> ignore the idiot behind the curtain
<Hobbsee> and wildcards, etc.  it works, as long as you get enough of it, and dont set the ban too wide (like banning an entire IP by accident)
<minghua> Hobbsee: you mean IP _block_?
<Hobbsee> minghua: from the channel.  yes.
<BigPick> Yeah banning a class A block would be... interesting
<minghua> Hobbsee: Alas.  I understand you can kickban according to IP instead of username.
<Hobbsee> BigPick: well, we have banned entire ISP's by accident before - or large subsets
<Hobbsee> minghua: indeed.
<minghua> Hobbsee: What I was asking is: did you mean "IP block" instead of "IP" when you said "dont set the ban too wide (like banning an entire IP by accident)"
<BigPick> HAHAHA, good times. Nothing like a little irc passive-aggression.
<BigPick> I think he meant ISP
<minghua> That makes sense, too.
<Hobbsee> minghua: oh, ip block, yes.
<minghua> I just couldn't think of anything other than an "entire" IP...
<Hobbsee> i see nwo :)
<Hobbsee> yeah
<ScottK> Hobbsee: If you got creative you could use geoip and ban entire countries.
<Hobbsee> ScottK: i'd prefer *!*@*!*
<Hobbsee> oh, *!*@*
<fit4lfe> I can't get update-manager to work cause i need pygtk now i can append pygtk in python but have no idea how to make it work for ubuntu
<fit4lfe> can someone tell me how ? do i need to change the enviroment variables if so could you please send me in the right direction
<fit4lfe> i have tried to the #ubuntu channel but no one knows what i am talking about
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<winchesterPAT> Hi!
<winchesterPAT> My name is borat.
<geser> pitti: Hi, have you time to look over the debdiff in bug #154811?
<ubotu> Launchpad bug 154811 in drupal5 "[SA-2007-{24,25,26,29,30}] Fix for several security issues in drupal 5.2" [Undecided,New] https://launchpad.net/bugs/154811
<Lutin> bdmurray: you talked about medibuntu-related upgrade issues...what are the bug numbers ?
<winchesterPAT> let me kiss you
<Kano> hi, is there a way to stop drives from being added to hal
<Kano> the problem is: when there is a raid set, which you usually control via dmraid
<Kano> then one of the drives still has a valid partition table
<Kano> and hal finds it
<Kano> http://paste.debian.net/40221
<Kano> here you see an example
<Kano> dmraid lists it as raid 5
<Kano> i patched the kernel + added a new dmraid to be able to access it
<Kano> but that would happen with raid 0 too i think
<Kano> when you try to mount it via hal you can create real damage
<lamont> after I was stupid and told the preferences/Appearance/Theme widgit that it was OK to do the font load, how do I get back to sane size fonts on my machine?
<Keybuk> I wish there was an emacs option to put the name of the function in the modeline
<Keybuk> ...
<Keybuk> oh, there is
 * Keybuk hugs emacs
<IntuitiveNipple> lamont: There's a gconf setting you can change from the command-line
<Hobbsee> pitti: hiya.  i presume i cant blacklist?
<Hobbsee> pitti: can you remove kubuntu-restricted-extras (source) from hardy.  it should have been the first time, i'm not sure what happened to it
<pitti> hey Hobbsee
<pitti> Hobbsee: blacklist what? the sync blacklist?
<Hobbsee> pitti: sorry, s/blacklist/removal things/
* Hobbsee changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 7.10 released!
<pitti> Hobbsee: can do; what's the rationale? is there a bug about it? (please file one, to have a paper trail)
<Hobbsee> pitti: i filed you a bug last time, and we discussed this last time.
<Hobbsee> pitti: (decided to integrate it with u-r-e, not maintaining them separately)
<pitti> oh, did we? I don't have the faintest memory about it, and yesterday I cleaned up archive bugs
<Hobbsee> like i say, i thought it didnt exist.
<pitti> ah, ok
<Keybuk> pitti: what does -D_FORTIFY_SOURCE=2 do?
<Hobbsee> yes, this was the source that was in the archive for the shortest lenght of time, for a new ubuntu package :)
<pitti> Keybuk: it adds some wrappers around critical functions to check arguments, IIRC
<pitti> Hobbsee: ah, that one; I remember
<Hobbsee> pitti: :)
<Hobbsee> Hobbsee_laziness++
<Keybuk> pitti: is there a reference for it?
<Hobbsee> pitti: maybe that will stop people reporting bugs on it.
<pitti> Keybuk: last time I searched for it (maybe two years ago) there wasn't a good one; kees might know
<pitti> Hobbsee: done
<Hobbsee> pitti: thanks a lot
 * Hobbsee tries to remember what else she was going to do.
<Keybuk> gnargh
<Keybuk> WHY does our glibc have an out of date version of the reference manual?
<Keybuk> because upstream haven't updated the docs
<Keybuk> ok, don't mind me :
<Keybuk> their website carries a later version of the manual than the tarball
<Keybuk> and it doesn't have fortify_source in it anyway
<keescook> Keybuk: I've found nearly 0 references to the _FORTIFY_SOURCE=2 (which requires -02 or higher, btw).
<Keybuk> keescook: "nearly zero" ?
<keescook> Keybuk: I've mentioned it a few times on public mailing lists.  ;P
<Keybuk> do you know what it does?
<pitti> keescook: weird that this didn't change (i. e. got documented at all) over the past years, given its popularity in Fedoar...
<keescook> pitti: yeah, it's odd.  I wanted to hunt down all the the features and document them.
<keescook> Keybuk: I know a few things it does:
<keescook> - converts strcpy, sprintf, etc functions into their +n versions when the size of a buffer is known
<geser> keescook: can you look at the debdiff in bug #154811?
<keescook> - blocks %n in format strings when the target is executable memory
<ubotu> Launchpad bug 154811 in drupal5 "[SA-2007-{24,25,26,29,30}] Fix for several security issues in drupal 5.2" [Undecided,New] https://launchpad.net/bugs/154811
<keescook> geser: sure, but not at the moment -- I have to drive a friend to the airport shortly.
<geser> np
<keescook> Keybuk: where have you encountered it?
<Keybuk> keescook: it generates extra compiler warnings
<Keybuk> from a bug report from Fedora ;)
<keescook> Keybuk: btw, if my first bullet didn't make sense:  char buf[10];  sprintf(buf,"%s",argv[1]);     turns into    snprintf(buf,10,"%s",argv[1]);
<keescook> Keybuk: heh.  well, I'm hoping to turn it on in Debian and Ubuntu.  While you're at it, try -Wformat -Wformat-security too  :)
<Keybuk> it also seems to add warn_unused_result to a lot of things
<keescook> back in a bit...
<pipegeek> OK, I've got a question.....
<pipegeek> Why is it that, when compiz is enabled in gutsy, the desktop page preferences dialog no longer allows you to name your desktops, or explicitly add more?  This seems like a bug.
<pipegeek> particularly since you can switch off compiz, make the change, turn it back on again, and have it stick.
<pipegeek> Ought I to submit a bug report?
<Amaranth> pipegeek: known
<pipegeek> Amaranth: thanks
<pipegeek> Appreciate all the work you folks are doing. :^)
<rohan> mjg59: are you around ?
<mjg59> rohan: Hi
<rohan> mjg59: hi .. can you please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/133677 ? the bug is occurring again :(
<ubotu> Launchpad bug 133677 in acpi-support "System unusable after resume from suspend or hibernate" [Undecided,Fix committed]
<mjg59> rohan: Whch aspect of it?
<rohan> mjg59: resuming from suspend doesn't work
<rohan> actually, it's a bit different, in that the screen backlight doesn't start at all, and the hard disk activity led shows full activity
<mjg59> rohan: You said it did
<rohan> i am sorry .. the bug is not exactly the same this time
<mjg59> Then it's a different bug
<rohan> should i file one more bug ?
<rohan> also do i provide any more information ?
<rohan_> mjg59: sorry i got disconnected .. you had replied ?
<hunger> I get a invalid signature from the ubuntu archive automatic signing key on gutsy-proposed.
<hunger> Would it be possible to fix that? It is pretty scary:-)
<beuno> hunger, it's been known to have problems due to some sort of caching in the middle (ISP, local network, etc)
<hunger> beuno: Thanks for the info. I don't have anything between me an a.u.c afaik.
<hunger> Well, maybe my ISP is messing something up. It is known to do such stuff.
 * beuno remembers some sort of workaround in Ubuntuforums, but can't quite find it
<dandaman33> ubuntu homepage seems badly broken unless the cache is bypassed... someone perhaps could tweak expiry settings?
<jdong> dandaman33: Ubuntu server is reporting accurate Last-Modified/etag info.....
<jdong> dandaman33: you sure you don't have an insanely aggressive proxy server between you and ubuntu?
<dandaman33> the homepage itself loaded, but CSS and image files were loaded from the cache
<dandaman33> lemme give this a shot on the laptop real quick, assuming i've loaded the ubuntu homepage in the past few days on there
<dandaman33> yep, loaded fine on there
<blix__> Hi Ubuntu folks
<attunix> Is there a guide on developing for Ubuntu? I've only done command-line development up until now and would like to start GUI programming.
<nemik> attunix: most of that is done in python and pyGTK. there are good tutorials out there on that. just google it.
<attunix> nemik: So it's all pyGTK?
<nemik> well, not all. but most smaller ubuntu apps are written using that
<attunix> thanks :)
<nemik> you could of course use C or C++ and others too if you want; they have GTK libraries as well
<attunix> nemik: Is there pyGTK documentation in the system?
<nemik> but ubuntu and shuttleworth are all about python
<nemik> attunix: not in the system from what i can tell. you might be able to apt-get documentation for GTK libraries but IMO google search is much better
<blix__> I quite like to do C/C++ network dev for Ubuntu
<attunix> nemik: thank you :)
<nemik> np
<attunix> nemik: since Python is interpreted, how can I make installers for my applications for them to run as stand-alone apps?
<norsetto> attunix: in python?
<attunix> norsetto: pyGTK
<LaserJock_> attunix: there are some python and pygtk docs you can install
<attunix> LaserJock_: such as what?
<LaserJock_> attunix: diveintopython for python
<slangasek> python-gtk2-tutorial, python-gtk2-doc?
<slangasek> "apt-cache search pygtk doc"
<norsetto> LaserJock: is that the one installed by default?
<attunix> thanks :)
<LaserJock_> I think it's installed by default
<LaserJock_> I find devhelp good for that kind of thing
<attunix> what's devhelp?
<LaserJock_> "Devhelp's primary goal is to be an API documentation browser for GNOME."
<attunix> Ok.
<attunix> I'll install that
<slangasek> attunix: installers for stand-alone apps: python has what are called "eggs", but they're horrible things that destructively interfere with packaging systems, and as such off-topic for this channel (per /topic)
<LaserJock_> you can also ship it similar to an ordinary C program too
<attunix> ok
<attunix> thank you!
<TheK> uhm, who wrote the system requirements for Xubuntu?
<TheK> 1,5 GB is just and plain wrong, it needs close to 2 GB just after install
<slangasek> TheK: where are you reading this?
<TheK> http://www.xubuntu.com/get
<slangasek> ok.  you should probably contact the xubuntu development list: https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel
<LaserJock_> hmm, I would think Xubuntu should have a smaller footprint
<slangasek> one would think so
<erosa> Hi all, don't know if this is the right channel for this question, but here I go just in case.. I missed the pidgin.mo file, so asked a friend to locate it through dpkg and found it was in package "language-pack-gnome-es-base". He's on x86 and I'm on powerpc. So I checked I had that package installed, but without that file. Finally I found pidgin.mo in package "language-pack-es-base",which had not being installed during the installatio
<erosa> n... Any idea on why is the file on different packages?
<LaserJock_> erosa: is that on 7.10?
<erosa> LaserJock, yes
<LaserJock_> erosa: it could be because powerpc is no long an officially supported arch
<LaserJock_> I wonder if something got messed up and nobody noticed
<slangasek> LaserJock_: no, it's simply because his x86-using friend isn't running 7.10
<erosa> LaserJock, I though non official ports used the same source debs
<slangasek> the language packs are all arch: all packages
<erosa> sladen, yes, he is
<erosa> we both use 7.10
<slangasek> erosa: no, he's not. :)  he does not have the current version of the language packs installed.
<slangasek> he may have installed gutsy, but the official 7.10 release has pidgin.mo in language-pack-es-base, not in language-pack-gnome-es-base
<erosa> slangasek, well, I did a fresh install and I think he dist-upgraded, cat be the reason?
<erosa> s/cat/can
<slangasek> erosa: it's possible that he hasn't dist-upgraded to the final release, yes.
<slangasek> otherwise, he simply misidentified the package.  But language-pack-es-base is definitely the correct package for 7.10, on all archs.
<erosa> slangasek, LaserJock, thank you two :)
<erosa> I was starting to think that the powerpc port was worse than expected
<slangasek> I'm more puzzled that language-pack-es-base wasn't installed by default, really
<erosa> I installed with alternate-cd-powerpc dated 16102007
<erosa> don't know if there were more releases after that
<slangasek> that should be the final release
<slangasek> and language-pack-es-base should be on the CD
<slangasek> so I really don't know why it wasn't installed, if you chose Spanish at install time
<erosa> Sure I did
<slangasek> oh, wait
<slangasek>  * language-pack-${Languages} [i386 amd64]
<slangasek> right, for some reason we didn't include it on the powerpc alternate
<LaserJock_> what seed is that from?
<slangasek> LaserJock_: ubuntu.gutsy/ship
<slangasek> that's a shame, we had plenty of room for more language packs on powerpc
<LaserJock_> are the ppc discs built from that seed?
<slangasek> cjwatson: is it kosher to reroll the ports images for 7.10 to shove some more langpacks on?
<slangasek> LaserJock_: yes
<slangasek> erosa: when you installed, did you have a network connection from the computer?
<slangasek> if so, the language packs should have still been downloaded automatically
<erosa> slangasek, yes
<slangasek> right, so I still don't understand what happened
<erosa> sladen, i remember it started downlading language packs
<slangasek> but filling the CD with langpacks would still probably be a goodidea
<calc> how do you force reload the gnome menu without restarting gnome?
<calc> ooo disappeared from the menu on me and i am doing bug triage :\
<LaserJock_> calc: were you messing around with the menu?
<LaserJock_> or it just disappeared
<calc> LaserJock_: i think i know what happened i probably screwed up my menu entries
<calc> reinstalling ooo now
<jdong> calc: kill gnome-panel with HUP?
<calc> jdong: hmm yea that would probably work
<calc> thanks
<jdong> np
#ubuntu-devel 2007-10-21
<attunix> Hi. Earlier I came in to ask about writing GUI apps for Ubuntu, and I didn't like pyGTK. Anything C[++]-like?
<calc> gtk is C
<attunix> calc: but I didn't like pyGTK... that's Python
<persia> gtkmm is c++ :)
<attunix> anything else
<calc> attunix: you wanted to know if there was anything C[++]-like which regular gtk is C so it is very much C like :)
<attunix> calc: oh. ok :P
<calc> pyGTK is the python bindings so if you want to write in python for gtk/gnome that is what you use...
<attunix> Glade pre-setups the interface for you, right?
<calc> i believe so
<attunix> Thanks.
<attunix> How do I set up my own package repositories?
<calc> with apt-ftparchive
<attunix> calc: thanks :)
<ion_> calc, attunix: falcon ftw.
<attunix> ion_: what's falcon ftw?
<ion_> https://edge.launchpad.net/falcon
<ion_> https://launchpad.net/falcon without the edge.
<attunix> thx
<sladen> attunix: also Qt, which is /very/ C++
<attunix> ooh! thanks :)
<sladen> attunix: or WxWindows
<attunix> ok
<persia> Umm..  wxWindows has vast issues.  If you must use WX, please use wxWidgets.
<sladen> persia: thanks for the tip; I never realised there /was/ a difference
<attunix> I'll look into QT and GTK
<persia> sladen: wxWindows is the old, non-unicode version
<sladen> "wxWidgets (formerly wxWindows)" ah, nod
 * lamont looks around for the big red "RESET" switch for gnome-preferences
<ion_> lamont: gconftool --recursive-unset / or something like that.
<lamont> ion_:  how do I dump the entire config first?
 * lamont rtfc
<lamont> rtfm even
<ion_> gconftool --dump / :-)
<attunix> In Gambas, when I try to create a project it says I can't because access is forbidden. Please help.
<ion_> Please read the topic.
<attunix> Ok.
<attunix> Anyone have any ideas?
<attunix> ion_: it's an IDE, by the way.
<jdong> grr what do I have to do to make tracker actually useful?
<jdong> it doesn't seem to be indexing contents of textfiles (such as irclogs) in a way that actually serves any purpose to me
<Burgundavia> jdong: use deskbar with tracker live search
<Burgundavia> likely it is not going into . files
<Burgundavia> this why Beagle is better, as it supports more files
<jdong> Burgundavia: oh no, it's recusing into the dirs, but only recognizes a few keywords
<jdong> Burgundavia:  it odesn't seem to default to text for textfiles *.log
<jdong> Burgundavia: like I can search for "gutsy" and not find a thing in ~/irclog... which is hard to believe that 2 months of #ubuntu has no mention of gutsy :)
<jdong> Do I have to do something to get it to think .log = text?
<jdong> I have it set to index 10240kb into each file and 100000 unique words
<jdong> is that not enough? :(
 * jdong strongly considers reverting back to beagle if this doesn't work out
<Burgundavia> personally, I think we should have gone with Beagle
<jdong> beagle actually worked for me
<jdong> I'd be more than happy to give the daemon 100MB RAM if it does for me what grep couldn't
<jdong> aha, it finds it with a .txt extension
<jdong> *sigh* I'll just comply and move all my logs to a .txt extension
 * jdong files bug, too
<attunix> How do I get GTK installed? I keep getting an "error: gtk/gtk.h: no such file or directory".
<attunix> anyone familiar with GTK?
<sbalneav> A bit.
<attunix> This is my first GTK program
<attunix> i'm trying to use gcc to compile it,
<attunix> but i keep getting an error that gtk/gtk.h doesn't exist
<attunix> my first line in the program is #include <gtk/gtk.h>
<ion_> Please read the topic.
<attunix> i already installed build-ess
<attunix> *essential
<attunix> ion_: oh.
<sbalneav> Cripes, so, he messages me, I start to explain to him, switch to another terminal to figure out a simple command line for him to compile with `pkg-config ... `, and he buggers off.
<sbalneav> What do people want, answers in 10 seconds?
 * sbalneav sighs
<ajmitch> yes
<persia> sbalneav: 10 seconds is far too long.  Faster! :)
<ajmitch> 10 seconds is an eternity on the internet :)
<sbalneav> I guess it must be.
<sbalneav> Fortunately, my first modem was an acoustic coupled 300 baud, so I learned patience early :)
<ajmitch> a what? ;)
<persia> ajmitch: One of those newfangled contraptions one attaches to the phone to let the computer have a conversation.
<ajmitch> that doesn't sound safe!
<sbalneav> If you were really good, you could whistle at the right frequency, and make the other guy's carrier light come on :)
<ajmitch> try doing that with adsl now.. :)
<ion_> :-)
<Keybuk> ah
<Keybuk> the old /ctcp ping looser +++ATH trick
<sbalneav> All my truly great hacker skills are now obsolete :)
<sbalneav> I used to have the entire stty() option set in my head.  I could wire RS232 breakout boxes with nothing but paperclips.  All these memories will be lost in time, like tears in rain.
<Keybuk> Oranges and Lemons...
<erosa> bye all
<wisu> I modified the flash-plugin.deb  post install to download the flash...tar.gz from a local cd... Q: how does the revision of the deb supposed to look like?
<b4sic> hey, i was hoping someone in here with experience developing (freelance or otherwise)
<b4sic> would be available for me to run an idea by.
<b4sic> welcome, lure.
<Lure> hi b4sic
<b4sic> you script any?
<b4sic> hey j_ack.
<OpenSorce> If it's okay to ask this here: If you were evaluating Linux distros for new user suitability, would you consider whether or not it offered Live CD mode and install from Live CD as a "must" or just a plus?
<rob> a plus I think
<OpenSorce> rob, thank you....but not a must per se, right?
<rob> no, they tend to be slow and its "hard" for a user to save their work
<OpenSorce> rob, yeah the speed bothers me too....I'd hate for a new person to perceive Live CD speed as the speed the installed system will run
<rob> yeah
<jdong> rob: I disagree, I'd say it's almost a must
<jdong> I, and any potential user, does NOT want to spend time installing a new operating system, making room for it on their system, just to learn that some piece of hwradware is unsupported, or the OS is otherwise dissatisfactory
<jdong> as long as the LiveCD boots in a reasonable amount of time, it is essential for evaluating a new operating system
<OpenSorce> jdong, thanks.....good point as well
<rob> I think live cd environments have their uses, but there are also various negatives to them too. Another issue I have seen is people think it is the installed Linux, and get all confused when you tell them it isn't. Ubuntu even adds a pop up to explain this iirc.
<jdong> I find myself almost unwilling nowadays to test new operating systems that do not have an evaluation CD
<rob> jdong, I guess you haven't tested Vista then ;)
<jdong> rob: unfortunately curiousity lead me to do it
<jdong> rob: fortunately their installer is lightning fast, otherwise I would've had more non-CoC things to say about it
<OpenSorce> jdong, my boss agrees with you....he won't even let me evaluate openSuse until they release a Live CD version
<jdong> OpenSorce: they DO have a livecd/livedvd, no?
<jdong> just not installable
<jdong> the live-eval thing is totally separate
<OpenSorce> jdong, not for the latest release, no
<jdong> OpenSorce: ah, ok
<jdong> OpenSorce: the thing is, I don't just want a LiveCD evaluator, I want a livecd that boots as closely to the final system as possible
<jdong> OpenSorce: IMO the Ubuntu livecd is almost 100% accurate diagnosis of how well Ubuntu works with a particular machine
<rob> ever tried to use the live environment on a low spec pc? I almost would consider a Live CD to be a bad thing for those users.
<jdong> because the bootup process and hardware detection routines are basically the same as an installed system.
<OpenSorce> jdong, good point.....I also think it's essential to see if the hardware is going to work on that distro
<jdong> rob: low-spec systems are a weakness, good point.
<OpenSorce> maybe a big pop-up that says "This is just Live CD mode, once installed your system will run much faster than this" is a good idea
<OpenSorce> rob, did you say ubuntu has that?
<rob> I tried using a low spec pc once, this very laptop actually. 256 Mb ram and an old AMD sempron processor, I would click next then wait several hours before the next screen of the live installer appeared.
<OpenSorce> rob, ouch!!
 * ScottK is reading the scrollback and having trouble finding anything about Ubuntu development.
<rob> I'd consider this laptop to be a perfect candidate for Linux too since Windows XP went to heck on it and I inherited it.
<OpenSorce> ScottK, so good to see you again....it was quiet and I wanted opinions....so sorry to clutter the channel with off-topic discussion :-)
<ScottK> We have #ubuntu-offtopic for that.
<OpenSorce> ScottK, of course.....again...my apologies :-)
<jdong> apart from low-RAM or slow-CD machines, I'd say a live evaluation CD is a very important feature for a distribution that would like to get people to switch from some other operating system
<OpenSorce> rob, jdong, I'm going to move to #ubuntu-offtopic you are welcome to join me.....thanks again ScottK.....please continue your Ubuntu Devel discussions...
<OpenSorce> Hobbsee, so nice to see you again, how are you?
<Hobbsee> hiya
<Hobbsee> pondering doing a talk in india, among other things
<OpenSorce> Hobbsee, ah....I detest public speaking :-)
<ScottK> Good afternoon (I think I did the TZ math right) Hobbsee.
<Hobbsee> ScottK: indeed!  good morning to you!
<Hobbsee> OpenSorce: so do i, somewhat, depending on what it's on :)
 * Hobbsee managed not to have to get up and speak at all for UDS.
 * lamont yawns, waves
<Hobbsee> hiya lamont
<ScottK> Hello there lamont.
<ScottK> Any noise yet on when we'll be able to start uploading to Hardy?
<lamont> ScottK: I haven't been paying attention
<Hobbsee> ScottK: toolchain is going
<lamont> OTOH, I'd expect that we want to let release/archive/etc have until monday or so to recover from the release.  (several back-to-back 20+ hour days do take a toll)
<ScottK> That's good.  So far I've not gotten any FTBFS mails I didn't expect.
<lamont> and I'm not sure where they're at in the checklist
<Hobbsee> meh.  sleep is overrated.
<ScottK> Sleep is for the weak.
<OpenSorce> Seeya later guys
<OpenSorce> ScottK, my apologies again :-)
<ScottK> I've got a narrow window I need to catch for a bugfix.  It's not SRU worthy, but important.  There's already a newer version in Debian.  So I need to upload the bugfix and get it backported between when the repo opens and the first autosync.
<Hobbsee> however, i did get pinentry-gtk-2 working.
<Hobbsee> unsure why it's not standard in gnome.
<ScottK> Hobbsee: They didn't do the same encryption by default stuff we did in Kubuntu AFAIK.
<ScottK> pinentry was in Universe until I got that in.
<Hobbsee> ScottK: seahorse is just weird!
<Hobbsee> yeah, well.  i might have to fix that
 * calc got rid of about 50 ooo bugs today
<Hobbsee> calc: yay!
<Hobbsee> now 100 more!
<calc> heh the next 100 will be a bit more work ;)
<Hobbsee> hmm, gnome is much smaller than kde.
 * Hobbsee restarts X
<calc> but uses more memory
 * ScottK missed the transition from "0" to "o" there for a second and was really stunned.
<calc> ScottK: lol
<calc> ScottK: i know a way to get rid of that many... nuke LP ;)
<persia> Regarding pinentry: in GNOME (not XFCE), seahorse-agent takes care of the GPG stuff.
<ScottK> calc: Well given how the implemented the auto expiration stuff you ought to just file a bug and ask for it.  They may just close them all for you </bitter>
<ScottK> persia: But isnt' that in Universe too?
<calc> what auto expiration stuff?
<persia> ScottK: Ah.  I missed the sense of things.  Apologies.
<ScottK> They added a "feature" to auto expire bugs left incomplete to long.
<Hobbsee> persia: yes, but seahorse *sucks*
<Hobbsee> or at least, it doesnt do what i want
<Hobbsee> persia: i cant seem to set it so that it asks for my passphrase the first time, and then keep it cached fro a set time, for ssh
<calc> ScottK: ah cool
<Hobbsee> whereas you can set pinentry to do exactly that, and it works for *ssh* and gpg
<ScottK> Their initial implementation got just a "little" more than they planned to get.
<Hobbsee> er, *and*, not *ssh*
 * persia ceases to defend seahorse
<ScottK> calc: Actually I think not.  For one the one size fits all timer works better for some things than others.
<ScottK> I cuts down on LP useability for some projects.
<ScottK> I/It
<calc> ScottK: how long was the timer?
<Hobbsee> persia: it's quite possible that i got the settings wrong, and it's really nice that it caches...but my user p/w is far less secure than my gpg and ssh passphrases (obviously), and so dropping down to that particular level of security is kinda unnerving.
<calc> true if it just closes bugs regardless of their status that could be very bad
<Hobbsee> whereas pinentry you do have to persuade to work, somewhat.
<ScottK> calc: I may have managed to erase that fact from my brain, but I think 4 months.
<calc> ok
<ScottK> So far every bug I've seen it expire that I got bugmail for was a valid issue that ought not be lost, but that's just me.
<persia> Hobbsee: I'm not sure you got your settings wrong.  I don't use seahorse for SSH, just GPG.
<Hobbsee> persia: ahh.  then you're missing out.
 * persia doesn't ssh much
<superm1> hey Hobbsee you got a few for ~ubuntu-archive'y stuff?
<Hobbsee> superm1: yes, but i'm limited in what i can do
<superm1> Hobbsee, oh didn't sort out the part about announcing to $release-changes yet?
<Hobbsee> superm1: no.  they wont fix that until late november.
<Hobbsee> what were you after?
<superm1> well accepting an SRU: bug 154985
<ubotu> Launchpad bug 154985 in mythbuntu-control-centre "MCC fails on amd64 if medibuntu hasn't been used in the past" [High,Fix committed] https://launchpad.net/bugs/154985
<superm1> into -proposed
<ScottK> Good night all.
<calc> is there a way to search bugs for any assignee other than nobody?
<Hobbsee> superm1: ahh.  dont thik so, sorry
<superm1> Hobbsee, no biggie, for now i'm just pointing amd64 users to a ppa until its in :)
<Hobbsee> superm1: come to think of it - does -proposed actually mail anywhere?
<Hobbsee> slangasek: might be able to do it, too
<superm1> Hobbsee, well i think it still announces to gutsy-changes.  because when it goes into gutsy-updates, its just cross pocket copied, and not announced then
<Hobbsee> superm1: ahh, kay.  then i'd better not touch it
<Hobbsee> (sigh)
<DShepherd> does anyone else thing it would be helpful to add a factoid to ubotu about the new appearance menu and whats located there? There seems to be a number of questions just related to find that appearance option much less the stuff under it
 * Hobbsee suspects that's more of a question for #ubuntu-ops
 * DShepherd takes Hobbsee suspected advice
<frimjon> Hi guys.  I want to report something that could fall somewhere between policy and bug, it's my first report, I'm just not sure how to report it.
<frimjon> It's about improving the error message in the Save dialog, whenever you save something with a forward slash it will give you a "file not found", I'd like to suggest that it be fixed to tell the user what the actual problem is (that they're using a slash) instead.
<frimjon> Should I be unafraid to report that as a bug?
<dsas> frimjon, be unafraid, be very unafraid
<frimjon> Hee hee, alright, I'll go straight into the wilderness of Launchpadland.
<frimjon> dsas: Actually, after some thought I found out that it really wasn't a bug, but rather the feature to allow paths in the file name (to save at that path instead of browsing) that's inevitably making shaky messages for those unfamiliar with the Linux file structure.  I can't see a proper way to remove that newcomer unfriendliness without changing something that veterans probably like.
<Keybuk> mail ubuntu-devel-discuss, describe the perceived problem and why you think it should behave differently
<Keybuk> (and also why you think it should behave like that)
<Keybuk> other people might have ideas
<Keybuk> a problem shared is a problem solved
<frimjon> Keybuk: That's a great idea, Keybuk, thank you.
<Keybuk> ubuntu-desktop might be a good alternative to ubuntu-devel-discuss
<Keybuk> though it has fewer subscribers, they're probably able to give a better help
<frimjon> Okay, I'll check that out.  Thanks again.
<popey> is there a way to determine why a package that was in dapper through feisty, isn't in gutsy? jpilot-syncmal is the one in question
<Hobbsee> popey: check the blacklist for why it got removed.  check if the source is there, but hasnt built.  check if the binary has a new name.
<lamego> where is that blacklist ?
<popey> glad you asked that
<Hobbsee> hmmm...off people.ubuntu.com/~ubuntu-archive/
<popey> i see no pages mentioning the package on the wiki
<Hobbsee> no, the wiki isnt used to track such things
<Hobbsee> popey: is it a package from debian, or only in ubuntu?
<lamego> http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt this one ?
<Hobbsee> lamego: looks good
<popey> it's not listed
<Hobbsee> lamego: of course, it will only show up on there if it's in debian too
<lamego> right, sync blacklist
<popey> it is in sid
<Hobbsee> popey: do the launchpad bugs show anything interesting?
<geser> http://people.ubuntu.com/~ubuntu-archive/removals.txt mentions it: "(From Debian) RoM; FTBFS since libmal-dev is no more available"
<popey> that's helpful, thanks
<Hobbsee> oh, that's the one i wanted.
<lamego> what is the removals.txt purpose ?
<Hobbsee> ....
<Hobbsee> to document what's been removed, and why?
<geser> Debian has it only on oldstable
<popey> yeah
<geser> s/on/in/
<lamego> I am lost, that means, it will be synched for the next release ?
<popey> (the reason I ask is the question has been asked in a lp answers post)
<Hobbsee> popey: FYI, RoM is "request of maintainer"
<Hobbsee> popey: ie, because it doesnt build anymore.
<popey> also helpful, thanks Hobbsee
<geser> lamego: no, as it got removed in Debian too
<lamego> ah ok
<Hobbsee> lamego: no, it means it didnt build in debian, so the maintainer asked for it to be removed.
<popey> thanks everyone
<lamego> geser, Hobbsee for how long are you working with debian/ubuntu packaging ?
<Hobbsee> lamego: hmm.  a year and 3/4?
<lamego> ok, just profiling :)
 * popey hands Hobbsee Â¾
<Hobbsee> lamego: it helps to learn the acronyms, and i've got an interest in archive admin stuff
<Hobbsee> so might tend to know more than most
<geser> lamego: my first sponsored upload is around 14 months ago
<Hobbsee> popey: thanks. i dont have those funky keys on my keyboard.
<Hobbsee> (and so ignore symbols too)
<StevenK> Hobbsee: That would have been using a compose key
<popey> Alt+Gr + 6 = Â¾
 * Hobbsee wonders what Gr is
<popey> Graphics ?
<StevenK> It's a growly Alt, duh
<StevenK> Hum.
<lamego> I am trying to estimate how long I will take to have an average know-how :P
 * StevenK can't find his Compose key
<Hobbsee> okay, maybe i should have asked *where* it is
<StevenK> (Which is what AltGr is usally mapped as)
<Hobbsee> lamego: depends.  people have their specialties
<StevenK> Hobbsee: AltGr is right Alt
 * popey specialises in â»
<lamego> Hobbsee, sure, but regardless of that, you need a certain time to get a broader knowledge
<Hobbsee> interesting.  it tehn takes me to window 6
<Hobbsee> lamego: true.  in which case, a couple of release cycles.  more than one.
 * geser has Compose on the menu-key
<StevenK> I've never understood how to bind keys in X.
<pitti> soren: FYI, I'll do the mutt merge; it's a tradition :)
 * Hobbsee closes a couple of bugs
 * pitti hugs Hobbsee
<StevenK> Hey pitti
<pitti> moin StevenK
<Hobbsee> right, no more bugs for that source package
<luk_> StevenK: xbindkeys might help
<pitti> soren: oh, nevermind, it can be synced
<geser> StevenK: either do it through gnome-keyboard-properties or through the right option in xorg.conf (for Compose)
<StevenK> I suppose I have to restart X for that option to work
<StevenK> steven@liquified:~% tracker-status
<StevenK> zsh: segmentation fault (core dumped)  tracker-status
<StevenK> Tracker, please jump off a cliff. kthxbye
<luk_> System->Preferences->Keyboard Shortcuts works fine in Gnome
<StevenK> luk_: Oh, absolutely, but the key doesn't work, I suspect I have to restart X.
<StevenK> pitti: What's that -Wl,--as-needed love page you were telling me about?
<norsetto> stevenk: this http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html under 9.1 ?
<leleobhz> someone can explain me how the package restricred drivers are generated?
<leleobhz> because i want to make a updated kernel package but im getting trouble with restrited modules
<soren> pitti: Oh, sorry about that. I didn't know :) I already filed a sync request.
<soren> pitti: I was actually referring to mutt when I asked on Friday if it was ok to file sync requests now.
<pitti> soren: NP, I checked
<phillips321> hi guys, any1 here?
<soren> phillips321: Er.. Yes? 226 of us, actually :)
<phillips321> what options are available for someone who wishes to use full hdd encryption but also be able to remotely reboot a box?
<soren> None that I know of.
<phillips321> i would like to try the 7.10 encryption but i'm riddled with needing physical access to reboot a box
<phillips321> it's a pain, im thrying to think of other options like partition encryption and then mouting once booted
<soren> You can hack something together with a tiny partition only used to boot and ask for the password, mount the real root and chroot your way into that, but it's not something we support. I'm just making it up right now.
<phillips321> ive thort about that, /boot and / not encrypted and only encrpting the /home partition
<phillips321> but i might not be able to boot correctly if my /home partition cant be found...
<soren> Why not?
<superm1> pitti, would you be able to release something into gutsy-proposed for me?
<phillips321> guess it's something i shud try....
<soren> Is there any way to see packages that have been uploaded to hardy, but not accepted yet?
<Mithrandir> soren: http://people.ubuntu.com/~ubuntu-archive/queue/hardy/unapproved/
<soren> Mithrandir: That wasn't there 10 minutes ago, was it?
<soren> Or am I going loony?
<Mithrandir> soren: no, it wasn't. :-)
<soren> phew..
<soren> Thanks!
<Mithrandir> publish-queue isn't smart enough to DTRT when we start publishing new distroreleases.
<Mithrandir> so it requires a little bit of handholding, aka mkdir
<soren> <g>
<alex-weej> asac: spare a couple of mins to talk about NM?
<Mithrandir> I should rewrite p-q to be a) faster and b) smarter, but just haven't had the time yet.
<Mithrandir> that'd make queuebot more useful too
<soren> Mithrandir: I actually really have no idea what either of those do, to be honest. :)
<Mithrandir> soren: publish-queue is the script that pushes the queue from the ftp-master to p.u.c/~u-a/queue, queuebot looks at a status file and tells us on IRC when there's a new queue item there.
<soren> Mithrandir: Hm? Which channel?
<soren> Mithrandir: Does it perhaps /msg the archive team?
<Mithrandir> soren: #ubuntu-release
<soren> Mithrandir: Shiny.
<Mithrandir> not that there's much going on there outside of release times.
<Dekans> what's the matter with nvidia drivers ?
<Dekans> several people just can't have 3D acceleretion on gutsy
<Dekans> are nvidia-glx and nvidia-glx-new broken ?
<Dekans> is it l-r-m ?
<soren> linux-restricted-modules
<Dekans> ok, so they have to wait for an update of it
<Dekans> :/
<lamego> Dekans, I have no problem with the nvidia driver
<Dekans> when i upgraded to gutsy, i installed succesfully nvidia-glx
<Dekans> but no X server at reboot
<Dekans> I instelled the .run binary from nvidia.com
<Dekans> a fe days later, no X server again
<Dekans> I removed this driver and reinstalled nvifia-glx
<Dekans> and it works...
<Dekans> but several people cannot use it on gutsy
<Dekans> at all
<lamego> I am using nvidia-glx-new, without any issues
<asac> alex-weej: sure
<alex-weej> oops sorry, bad timing
<alex-weej> need to cook
<alex-weej> ttyl
<asac> alex-weej: hehe ... ok
<Dekans> but some people cannot ahve 3D
<Dekans> have*
<Dekans> so no fix planned :(
<Karnaugh> Dekans: blame the manufacturers
<Dekans> it seems to be a issue related to l-r-m
<lamego> hello, anyone will an nvidia card and 3d enabled that could help me with a test ?
<blueyed> lamego: yes
<lamego> bluekuja, sudo apt-get install snowballz
<lamego> snowballz
<lamego> I am getting: Major opcode of failed request:  135 (XFree86-VidModeExtension)
<blueyed> lamego: works for me (nvidia-glx-new, Club3D 6600GT)
<lamego> hum
<lamego> I am using nvidia-glx
<lamego> no, i have the new
<lamego> a google for the error gave me the idea it was related to the nvidia driver, but it could be also with the display setup, for the video mode switching
<bluekuja> lamego, huh?
<lamego> the X Error of failed request:  BadValue (integer parameter out of range for operation), on the set video mode function
<lamego> which is what I am getting when launching the game
<attunix> What libraries are needed to develop in QT?
<lamego> libqt4-dev ?
<attunix> thanks
<mekius> bryce: Hey, was wondering if you had any estimate on the inclusion of Xorg 7.3?
<Kmos> mekius: try to ask that tomorrow
<mekius> ok :)
<mekius> Kmos: didn't really need an answer right away, just throwing it out there
<ec158148> hi all, i don't seem to have the manpage for scanf
<ec158148> could somebody guess as to why?
<azeem> ec158148: please ask in #ubuntu
<ec158148> ok
<ec158148> thanks
<bryce> mekius: I do
<bryce> mekius: in fact timo has just done the xorg merge and is getting ready to upload it; xserver is either done or to be done soon
<bryce> mekius: also if you're interested, I've prepared a Ubuntu-X project list at http://wiki.ubuntu.com/X/Projects
<bryce> essentially, the plan is to get all the Xorg 7.3 bits incorporated as soon as Hardy is open for business
<bryce> mekius: I personally am probably going to stay focused on bugs a bit, as there's several I'd like to -sru for Gutsy (esp. -ati and -intel)
#ubuntu-devel 2008-10-13
<cjwatson> it seems like essentially a paranoia check to me
<cjwatson> but evand could say if I'm missing something
<ogra> mmc ususally registers as /dev/mmcblk[0,1,2,..]
<cjwatson> mmc> ah, I see, "block device corresponds to the controller on the card rather than the MMC host adapter"
<ogra> apart from the numbering the naming is pretty reliable
 * cjwatson makes a note in the bug
<cjwatson> ogra: search> I knew it was the pkgbinarymangler package, so ran dpkg -c, which reminded me that it had a dpkg-deb wrapper script, so I looked at that
<ogra> ah, well, i knew i had talked to pitti about it twice and tried to find it in the logs :)
<johanbr> Hmm. Making the obvious changes to backend.py doesn't make my SD card appear.
<ogra> johanbr, does it get mounted if you dont use ubiquity ?
<johanbr> Yes. And I think I made a stupid mistake. Just a sec.
<ogra> i noticed that it doesnt work after using SD's several times, i fear thats a kernel issue
<ogra> or udev
<johanbr> I've never had any problems like that.
<johanbr> Still no luck with modifying usb-creator, though. Hmm...
<ogra> on what do you match now ?
<ogra> probably storage.drive:_type=sd_mmc is better
<ogra> -:
<johanbr> Missed one place. Just a minute,
<johanbr> Yes! It works. Or well, it detects the device. :)
<ogra> cool
<johanbr> I just took out the usb detection parts, though. When I have something more proper, I'll add a patch to the bug.
<Pollywog> I need to recompile kmail from deb-src with debugging enabled but it seems as though the format of the debian/rules file has changed.  How to I change the configure options for a package when compiling from deb-src?
<Pollywog> a Howto or other reference would suffice
<Pollywog> a recent Howto
<TheMuso> Ok something in intrepid wants to keep re-inserting my tray loading external DVD drive. Its actually an IDE drive mounted in an external USB box, but every time I eject it, it is re-inserted straight away...
<StevenK> TheMuso: Can you try and build the latest libtunepimp from Intrepid on your PowerPC?
<StevenK> TheMuso: It will fail, but I'd like the config.log from the build, if you can swing it
<TheMuso> StevenK: Sure, just give me a sec.
 * TheMuso updates his powerpc intrepid chroot and prepares to build libtunepimp by hand.
<StevenK> TheMuso: Yeah, that's the trouble with sbuild. pbuilder can be asked to give a shell
<TheMuso> StevenK: I just schroot into the chroot, install build-deps, and run commands manually. I find it more flexible than pbuilder, since there is no time wasted unpacking the chroot.
<StevenK> TheMuso: Yeah, me too
<TheMuso> StevenK: 0.5.3-7ubuntu2?
<StevenK> TheMuso: Right]
<StevenK> s/]//
<TheMuso> StevenK: It builds, but fails in the binary step.
<TheMuso> StevenK: What log do you want?
<StevenK> TheMuso: Yup. The cause for the failure is checking for mad_version in -lmad... no
<StevenK> TheMuso: config.log
<TheMuso> StevenK: do you want it emailed, or will pastebin do?
<StevenK> TheMuso: pastebin is preferable, if you can swing it
<TheMuso> StevenK: Sure.
 * StevenK keeps testing -mid
<TheMuso> StevenK: http://paste.ubuntu.com/56855/
<TheMuso> ...and I'm out for a bit.
<StevenK> TheMuso: I've got the error, thanks
<TheMuso> StevenK: np
<StevenK> What that actually means, I have no idea
 * StevenK will have to beg doko
<TheMuso> what is the problem exactly?
<StevenK> /usr/bin/ld: /tmp/ccWjbBvF.o(.text+0xc): unresolvable R_PPC_REL24 relocation against symbol `mad_version'
<TheMuso> lovely
<StevenK> james_w: Bug 281561 commented on about libmad PPC brokenness
<ubottu> Launchpad bug 281561 in nufw "libgnutls13 transitions build failures" [Undecided,In progress] https://launchpad.net/bugs/281561
<calc> anyone know if there is an air quality index applet for gnome?
<unfo> hi all.  I convinced upstream Xorg to change things last week.  Now DontZap is the default.  Will DontZap also be the default on jaunty jackalope?
<unfo> i.e. will Xorg's change automatically propagate to jaunty?
<unfo> bryce_: you're involved with X.  do you know the answer?
<unfo> *X packaging
<bryce_> unfo: yes when we re-sync for jaunty it will come in
<unfo> bryce_: sorry to ask again; but I want to be sure, and I realize I didn't ask so well before.  I don't fully understand the code of the change dstone made.  But I do know that sudo dpkg-reconfigure xserver-xorg -pcritical causes Ubuntu to write out a new Xorg.conf.  Will that Xorg.conf negate the new default by specifying that users may zap?  Or will it keep the new default and leave zapping disabled?
<RAOF> unfo: We don't write that value currently, and I don't see any reason why we'd suddenly start writing it.
<unfo> RAOF: ok thanks for clarifying.
<unfo> another question.  all :  there are a lot of games in Ubuntu main.  Some are quite bad.  Can we move the bad ones into universe or make some other change, thereby raising the average quality of games in Ubuntu?
<StevenK> What do you mean by bad?
<unfo> Or maybe can we ship more of the best games on cdrom 1?
<unfo> StevenK: pick a few random games in main.  Install them.  Try them.  See if you like them.
<unfo> StevenK:  Let me give you examples of bad games, some are in main, some in universe, I don't remember:  btanks, tennix,
<Hobbsee> i've often wondered why some of the stuff in gnome-games doesn't get split out, and demoted.
<Hobbsee> unfo: neither of those are in the default install
<StevenK> gnome-games is quite good
<unfo> Hobbsee: sorry, I'm now on the phone IRL.  I agree, neither is in the default install.
<bryce_> Hobbsee: I'm sure it boils down to manpower
<unfo> I can list more in 1 hour once I am off the phone.
<Hobbsee> bryce_: i would have thought the manpower would get allocated rather easily, seeing as it'd be a good way to cut down cd space.
<bryce_> unfo: file demotion requests in launchpad for each you'd like to propose eliminating
<Hobbsee> !info gnome-games intrepid
<ubottu> gnome-games (source: gnome-games): games for the GNOME desktop. In component main, is optional. Version 1:2.24.0-0ubuntu1 (intrepid), package size 1070 kB, installed size 2736 kB
<Hobbsee> hmmm, not that big.
<StevenK> Yeah, there's more low-hanging fruit. Or there has been, at least.
<Hobbsee> it seems to be decreasing.  THere's not that many more langpacks, either
<bryce_> the games in gnome-games aren't really that horrible.  Some are a bit eye-candy poor, but they're all quite playable
<bryce_> but it's definitely true games available in ubuntu need a lot of work
<StevenK> Some games
<aaronp> Sorry if this is a FAQ, but can someone please point me towards the documentation on how to upload PPA builds?  I can't seem to find it.
<aaronp> Never mind, I found it in some random IRC log.
<unfo> aaronp:  That's not really such good documentation.  :)  Someone should write some real documentation.  Don't volunteer me for the job though.
<unfo> aaronp:  Or at least you should write something on the Ubuntu wiki.
<unfo> I haven't used gnome-app-install ("Add/Remove...") for a few years now.  But IIRC it listed a star rating for each application based on popcon data.  But most apps had a star rating of "1 out of 5".  Some apps (the apps on the Ubuntu Desktop CD) had 4 stars or 5 stars.  Is that still the case?  If it is, we should bell-curve the star ratings so that more packages get 2 or 3 stars and less get 1 or 4 or 5.
<unfo> That would help the games problem by helping people decide which games to add to their PC based on their star ratings.
<dholbach> good morning
<StevenK> pitti: So, in the removal of libcgi-perl, you said it was superseded by libcgi-pm-perl and perl-modules. You failed to check if libcgi-pm-perl was shipped by us, and it isn't.
<pitti> Good morning
<pitti> StevenK: uh, where? when? me?
<pitti> that package name doesn't ring a bell
<StevenK> # Deleted on 2008-06-20 by Martin Pitt - (From Debian) ROM; obsolete; superseded years ago by libcgi-pm-perl
<pitti> ScottK: restricted-manager-kde> hm, do you still have the restricted-manager-kde package removed, but not purged?
<pitti> slangasek: coreutils SRU> it's for dapper
<pitti> slangasek: it was removed in Debian, perl-modules now provides it AFAIR
<pitti> ogra: no problem, not much time any more to fix up stuff :)
<pitti> ScottK, slangasek: apparently I missed the libfile-temp-perl discussion, but if we need it still, let's just put it back instead of wasting a lot of work on it
<StevenK> pitti: Right, but bugzilla3 in Intrepid requires a newer CGI.pm than perl-modules provides.
<StevenK> pitti: And when that bug was reported in Debian, the reporter said "Use libcgi-pm-perl, kthxbye"
<pitti> ArneGoetje, Riddell: not quite sure what you were discussing, but the extra KDE files are in extra-files/kde-LL.tar
<pitti> ArneGoetje: they originally came from extracting them from KDE, but they are maintained in langpack-o-matic's bzr now
<pitti> cjwatson: gaspa mailed me about usplash overflow, I'll followup there
<pitti> StevenK: ok, then let's just copy-package it back from hardy
<pitti> StevenK: (for intrepid, anyway)
<StevenK> pitti: libcgi-pm-perl? It doesn't exist in either
<persia> pitti, Wouldn't it be better to sync the new package than copypackage the obsolete package?
<StevenK> steven@liquified:~% rmadison libcgi-pm-perl
<StevenK> steven@liquified:~%
<pitti> StevenK: oh, sure; syncing is fine, too
<dholbach> asac: if you could push another thunderbird with the last change from ~saivann/thunderbird/fix_desktop_file you could close the thunderbird task from bug 190688
<ubottu> Launchpad bug 190688 in thunderbird "Use of explicit suffix in 'Icon' field of application launcher" [Undecided,Confirmed] https://launchpad.net/bugs/190688
<StevenK> pitti: Oh, what was the other library that we should transistion away from?
<pitti> StevenK: libfile-temp-perl ?
<StevenK> pitti: Sorry, you mentioned it last week the same time as libgnutls13
<pitti> StevenK: oh, that's opencdk10, but its only user is gnutls13
<StevenK> Ah
<pitti> StevenK: hm, so I earned the powerpc libtunepimp FTBFS
<StevenK> pitti: Talk to persia about that :-)
<StevenK> pitti: I've analysed it, as you can see from the bug comments, but I have no idea how to fix that
<persia> pitti, I just randomly assigned stuff to the cruft-busters.  Feel free to reject it if you're too busy.
<StevenK> pitti: Looks like the breakage is in libmad, too
<pitti> persia: right, that's fine
<pitti> just wonder how to tackle it
<StevenK> My plan was "Ask doko how to fix it"
<doko> fix what?
<StevenK> doko: libmad on PPC. It's giving a realloc error
<doko> StevenK: bug?
<StevenK> doko: Bug 281561
<ubottu> Launchpad bug 281561 in nufw "libgnutls13 transitions build failures" [Undecided,In progress] https://launchpad.net/bugs/281561
<EvanCarroll> hallo! I just wanted to report that I have working sound using a custom compiled radeonhd under the git branch HDMI audio
<doko> StevenK: is one of the libraries built with -fpic instead of -fPIC?
<persia> EvanCarroll, Cool.  Have you been able to extract the relevant patches yet?
 * StevenK asks searching questions of libmad's PPC build
<EvanCarroll> persia: they are all extracted and applied to the branch HDMI-Audio if the concern is that the branch is old, I can surely extract or find them
<StevenK> doko: libmad itself uses -fPIC
<doko> StevenK: or you try to install an earlier binutils version, and see if it works there
<persia> EvanCarroll, No, it's that I'm doubting we'll be able to get them into intrepid from there, given the timeframe.  Still great news.
<StevenK> doko: Right, they all use -fPIC
<StevenK> I didn't check -lm, but if glibc isn't using -fPIC, I'd be shocked
<EvanCarroll> persia: Aparently the patch set in HDMI-Audio, is old and there is a newer one that can applied to newer git
 * persia isn't sure what is in intrepid today, or which is more useful
<pitti> StevenK: there's a bunch of remaining libgnutls13 universe rdepends which aren't mentioned in bug 281561
<ubottu> Launchpad bug 281561 in nufw "libgnutls13 transitions build failures" [Undecided,In progress] https://launchpad.net/bugs/281561
<pitti> gnash-common
<pitti> kio-sword
<pitti> libflashsupport
<pitti> libgnutlsxx13
<pitti> pnet-assemblies
<StevenK> kio-sword is
<persia> pitti, kio-sword will get a removal bug as soon as ichthux is fixed
<pitti> oops, ignore libgnutlsxx13 of course
<StevenK> libgnutlsxx13 is built from gnutls13 source
 * ajmitch saw a removal bug on pnet-assemblies
<ajmitch> surprised that it was still in the archive, tbh
<persia> libflashsupport and gnash are special
<StevenK> And pnet
<StevenK> I should dig those up
<pitti> persia: ichtux? by now this metapackage probably has more uninstallable dependencies than good ones..
<StevenK> Bwahah
 * pitti processes some removal bugs then
<StevenK> libgnutlsxx13 has no rdepends, too
<persia> pitti, Shouldn't.  txwikinger has been trying to keep up.
<StevenK> Not sure what to do about libflashsupport
<ajmitch> kill it off?
<StevenK> gnash is waiting for asac
<StevenK> Well, a few people have said kill it, and a few people have said keep it
<StevenK> So I'm confused
<directhex> who uses pnet?
<pitti> bug 281411, I'll remove it
<ubottu> Launchpad bug 281411 in pnet "Please remove pnet source and binaries from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/281411
<directhex> oh, there's a delay on mono 1.9.1+dfsg-4ubuntu1 - we want top get another bug fix backported to -4 before we tag & ship it
<cjwatson> pitti: usplash> thanks
<cjwatson> TheMuso: FYI I've removed partman-dmraid from intrepid, since it's been removed from Debian now
<pitti> doko: bug 276739, I don't understand the rationale; does the netbeans source now include the IDE?
<ubottu> Launchpad bug 276739 in netbeans-ide "please remove netbeans-ide src + bin, and blacklist" [Undecided,New] https://launchpad.net/bugs/276739
<persia> pitti, That's leftovers from previous packaging efforts.  "netbeans" is the source package we want.
<kwwii> seb128: one question about gconf...how do I set a bool? I tried with TRUE but that appears not to work...is it 1/0 ?
<Mithrandir> kwwii: gconftool-2 --set --type bool /foo/bar true
<pitti> persia: ok
<seb128> kwwii: what are you tring to do?
<seb128> grrrr compiz
<persia> pitti: I've just filed 282561 on a closely related topic.
<pitti> bug 282561
<ubottu> Launchpad bug 282561 in libnb-platform7-java "Please remove libnb-platform7-java from intrepid" [Undecided,New] https://launchpad.net/bugs/282561
<pitti> persia: done
<persia> pitti, Thanks.  I think those two ought complete the netbeans confusion.
<kwwii> seb128: trying to set the panelbg to stretch...I set it to TRUE but it returns an error so that can't be right
<seb128> what is that? and how do you try to set it?
<kwwii> Type mismatch: Expected `bool' got `string' for key /apps/panel/toplevels/top_panel_screen0/background/stretch
<Mithrandir> kwwii: are you using "TRUE" or "true"?
<kwwii> I set it in gconf-defaults in the ubuntu-artwork package with
<kwwii> /apps/panel/default_setup/toplevels/bottom_panel/background/stretch   TRUE
<seb128> use lowercase
<kwwii> Mithrandir: hi, btw, and yes, TRUE
<kwwii> seb128: cool, thanks for the help!
<Mithrandir> kwwii: try true lowercase, as I told you thirty minutes ago. :-P
<Mithrandir> also, hiya. :-)
<kwwii> ;-)
<mdz> pitti: someone suggested a patch for bug 264767, could you have a look?
<ubottu> Launchpad bug 264767 in sysvinit "usplash pulsates intermittently during boot" [Low,Confirmed] https://launchpad.net/bugs/264767
<mdz> pitti: I can't tell if it's a proper fix or just disabling the pulsating entirely
<pitti> mdz: ah, usplash has *just* started to work for me again, with the -7 kernel
<pitti> I think I saw this effect, too
<pitti> mdz: yes, it basically disables pulsating for fsck completely
<seb128> grrrr, mvo!!!
<pitti> mdz: hm, whether that is desired is pretty much a matter of taste, I think
<pitti> but we didn't do it in earlier releases
<seb128> mvo: ;-)
<cjwatson> well, you want pulsating if there's no other visible sign of progress, potentially a long time on one step, and no way to calculate the length in advance
<pitti> I see how that got into Debian, but for the really long ones we already have our usplash fsck integration
<cjwatson> I like Coucouf's approach
<pitti> so reverting to the hardy behaviour makes sense for us, IMHO
<pitti> (e. g. that patch)
<cjwatson> if I'm reading it right it seems to enable pulsating only when it's going to take a while?
<pitti> cjwatson: only if there's an actual fsck happening
<pitti> but I discussed that case for hardy with mpt, and he said keeping the progress bar steady and reporting textual progress was better
<mdz> pitti: I find it confusing that it pulsates even when no check is taking place
<mdz> since the progress bar advances, advances, suddenly pulsates, advances some more, suddenly pulsates, then advances to the end
<pitti> and for the actual fsck case we don't need pulsating either
<pitti> we can report actual numbers and percentage there
<cjwatson> pitti: I agree on textual progress
<gaspa> pitti: just about that.
<pitti> gaspa: your mail> that's indeed a tricky one
<gaspa> actually status line with percent and steps of fsck overflow off the chars box.
<pitti> cutting off the status is evil, then you don't see anything
<gaspa> in fact.
<gaspa> i prefer that it wrap.
<pitti> I'd rather fix it to properly clean up
<pitti> wrap? that looks even more ugly?
<gaspa> the other solution is to enlarge the status width...
<pitti> if we can't easily fix the status column, then we shouldn't use it at all and change the text instead, or so
<gaspa> pitti: but why status should be limited? couldn't it take the whole line, if it need to?
<pitti> gaspa: making the status column much wider to fit would be the best, indeed
<pitti> even in 640x480 there's still quite a lot of unused space at the right, so it should fix
<pitti> s/fix/fit/
<gaspa> I agree, it's a theme specific parameters, though
<gaspa> t
<pitti> mdz: thanks for pointing out, I'll apply the relevant bits of that patch then (just tested in kvm to make triple-sure)
<mdz> pitti: thank you
<mdz> fortunately, I have not received any strong confirmation for bug 262567
<ubottu> Launchpad bug 262567 in powernowd "Scaling governor set to 'performance' on boot, rather than 'ondemand'" [Medium,Triaged] https://launchpad.net/bugs/262567
<mdz> pitti: bug 276857 is very confusing, X says that it finds no keyboard or mouse, but they turn up in lshal
<ubottu> Launchpad bug 276857 in xorg "On reboot X requires restart because mouse and keyboard are unresponsive" [Undecided,New] https://launchpad.net/bugs/276857
<jcristau> mdz: looks like hal isn't up when X starts
<mdz> jcristau: but I had him add an lshal to the init script, and it works
<jcristau> weird
<seb128> mdz: ah, bug #271138 is likely the same issue, thanks for the other bug number ;-)
<ubottu> Launchpad bug 271138 in gdm "mouse and keyboard unresponsive when gdm first runs" [Medium,Confirmed] https://launchpad.net/bugs/271138
<jcristau> i love how people say 'I have exactly the same problem.' and then go on to describe something unrelated
<mdz> jcristau: do you know if X logs an error if it cannot connect to hal?  I see no such error in the log; the first one is that it cannot find a core pointer/keyboard
<jcristau> (EE) config/hal: couldn't initialise context: (null) ((null))
<jcristau> it logs that when libhal_ctx_init() fails
<gaspa> pitti: in conclusion: what are you doing, and what could I do?
<pitti> gaspa: I'm not working on this right now (will do later when I get back to my email)
<pitti> gaspa: maybe you can run some tests with enlarging the width and see if it looks ok then?
<gaspa> yep
<asac> StevenK: ok i will do gnash today
<mdz> jcristau: oh, I see, the error about core pointer/keyboard is normal (happens here too).  only the error at the end is meaningful
<ogra> tjaalton, what do we do about the -nsc Xserver ?
 * ogra just marked bug 281490 as duplicate of bug 265035 .... seems we need to take some action before release for that
<tjaalton> ogra: what do you mean?
<ubottu> Launchpad bug 281490 in xserver-xorg-video-psb "can't run X -configure in a T61 (dup-of: 265035)" [Undecided,New] https://launchpad.net/bugs/281490
<ubottu> Launchpad bug 265035 in xserver-xorg-video-psb "Xorg -configure breaks on  undefined symbol: xf86GetPciVideoInfo" [Undecided,New] https://launchpad.net/bugs/265035
<james_w> StevenK: thanks
<ogra> tjaalton, it still chokes on nsc
<jcristau> mdz: right, the first error is when parsing xorg.conf, so it's ok
<james_w> and TheMuso, thanks for building.
<ogra> and i still dont get why both got assigned to -psb ... its definately not at fault
<tjaalton> ogra: ok, didn't know about that
<james_w> one thing I can see is that it is defined as "extern char const mad_version[];" and then it tries to link against it as "char mad_version ();", should that work?
<ogra> you assigned it to psb :)
<tjaalton> hmm :)
<ogra> nsc isnt ported yet and apparentl wornt be ported as far as i heard ... we should probably drop it (though i know lots of ltsp users that will kill me)
<ogra> s/wont be ported/wont be ported in time/
<tjaalton> ogra: it should be ported, the current version has a patch for that
<tjaalton> ogra: but maybe it's not complete
<ogra> yes, that was at least what Q-Funk told me
<ogra> who does the debian package
<tjaalton> the debian X team
 * ogra rephrases
<ogra> Q-Funk, who does the debian package for geode and nsc :)
<tjaalton> ah :)
<jcristau> no he doesn't
<ogra> not anymore ?
<ogra> oh
<jcristau> he does geode
<ogra> wasnt nsc the result of a package split of amd into geode and nsc ?
<pitti> mdz: indeed, and the hal init script blocks until all devices and FDIs have been processed (the "coldplug" phase)
<ogra> we had a lot of grief with his packages back when that split happened
<pitti> mdz: I subscribed to the bug
<ogra> i thought it wasall his work
<tjaalton> nsc has been here for quite some time
<jcristau> ogra: there was no split
<tjaalton> geode should support those chips in the future
<jcristau> there's a pciaccess patch for nsc in git, you may want to try that
<ogra> jcristau, bug 219630
<ubottu> Launchpad bug 219630 in xorg "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Medium,Fix released] https://launchpad.net/bugs/219630
<ogra> (only open that LP page if you have a lot of time ... its loooong) ;)
<ogra> it looked like he maintained both packages
<ogra> to me at least
<ogra> but if tehre is a fix, we should indeed urgently get that
<tjaalton> ogra: btw, that bug was about psb, not nsc
<ogra> tjaalton, which one ?
<tjaalton> ogra: bug 281490
<ubottu> Launchpad bug 281490 in xserver-xorg-video-psb "can't run X -configure in a T61 (dup-of: 265035)" [Undecided,New] https://launchpad.net/bugs/281490
<ubottu> Launchpad bug 265035 in xserver-xorg-video-psb "Xorg -configure breaks on  undefined symbol: xf86GetPciVideoInfo" [Undecided,New] https://launchpad.net/bugs/265035
<tjaalton> er, 265035
<ogra> no, i filed it against xserver-xorg originally, the breakage was on -vga and when that was gone it broke on -nsc with the same error message as on bug 281490
<ubottu> Launchpad bug 281490 in xserver-xorg-video-psb "can't run X -configure in a T61 (dup-of: 265035)" [Undecided,New] https://launchpad.net/bugs/281490
<ubottu> Launchpad bug 265035 in xserver-xorg-video-psb "Xorg -configure breaks on  undefined symbol: xf86GetPciVideoInfo" [Undecided,New] https://launchpad.net/bugs/265035
<ogra> you were the one who assigned it to -psb (which i still dont understand as i said in the beginning)
<tjaalton> (EE) Failed to load module "psb" (module requirement mismatch, 0)
<tjaalton> that's why :)
<ogra> but thats not the xf86GetPciVideoInfo message :)
<tjaalton> hm right, but still
<ogra> right ... :)
<tjaalton> jcristau: the ubuntu package already has the patch, but seems like it doesn't work
<jcristau> tjaalton: ah. then i guess someone with the hardware needs to fix it...
<tjaalton> jcristau: exactly :)
 * ogra just confirmed again
<ogra> (EE) module ABI major version (1) doesn't match the server's version (4)
<ogra> (EE) Failed to load module "psb" (module requirement mismatch, 0)
<ogra> Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers//nsc_drv.so: undefined symbol: xf86GetPciVideoInfo
<ogra> ogra@osiris:~/Desktop/ltsp$ sudo apt-get remove xserver-xorg-video-nsc
<ogra>  ....
<ogra> ...
<ogra> (EE) module ABI major version (1) doesn't match the server's version (4)
<ogra> (EE) Failed to load module "psb" (module requirement mismatch, 0)
<ogra> (++) Using config file: "/home/ogra/xorg.conf.new"
<ogra> Xorg detected your mouse at device /dev/input/mice.
<ogra> Please check your config if the mouse is still not
<ogra> operational, as by default Xorg tries to autodetect
<ogra> the protocol.
<ogra> Your xorg.conf file is /home/ogra/xorg.conf.new
<ogra> To test the server, run 'X -config /home/ogra/xorg.conf.new'
<ogra> even though it has the EE line for psb, it properly creates the config
<persia> Why is it trying to load psb?  Ideally, nothing should load psb, because it's known not to work.
<ogra> it walks all available drivers
<ogra> on a sidenote it detected everything correctly in the config file ...
<jcristau> hrm.
<jcristau> +#ifndef XSERVER_LIBPCIACCESS
<jcristau> if (xf86GetPciVideoInfo()) {
<jcristau> +#endif
<tjaalton> that's what I was looking at as well..
<ogra> tedg !!! i cant log out from ltsp sessions anymore
<ogra> *sight*
<ogra> -t
<tjaalton> jcristau: umm, maybe running autoreconf would make it work?
<jcristau> maybe pcpa screwed up
<tjaalton> maybe, but looks like the package was not built against libpciaccess
<jcristau> the configure.ac patch looks broken
<mdz> tjaalton: bug 222796 indicates that the thinkpad_acpi default hotkey mask is not in fact correct
<ubottu> Launchpad bug 222796 in linux "Brightness up not generating ACPI event on Thinkpad T43p, T42, X31, X40, R52" [Medium,Triaged] https://launchpad.net/bugs/222796
<StevenK> asac_: Okay, cool.
 * ogra is angry and files bug 282595
<ubottu> Launchpad bug 282595 in ldm "fusa prevents ltsp sessions from logging out" [Critical,New] https://launchpad.net/bugs/282595
<tjaalton> mdz: hmm ok, maybe the change should be reverted then. Would be nice if upstream told why it was bad to change the mask
<cjwatson> ogra: if you want that to be RC then it needs to be nominated for release as well
<ogra> cjwatson, ah, thanks, will do
<cjwatson> ogra: (http://wiki.ubuntu.com/RCBugTargetting)
<ogra> done
<mdz> tjaalton: I have asked mjg59 on #ubuntu-kernel
<ogra> thanks, i doubt i have any other RC bugs though ...
<cjwatson> the LP translations import queue seems to have progressed through about three or four weeks' worth of imports over the weekend; glad to see it's catching up
<tjaalton> jcristau: right, autoreconf didn't help at all
<jcristau> tjaalton: it's missing the AC_CHECK_DECL(XSERVER_LIBPCIACCESS, ..)
<tjaalton> jcristau: yeah..
<asac> Mirv: are intrepid langpacks ok?
<ogra> woah, the guest session just locks up ltsp
<asac> ogra: ffox?
<ogra> grrr .... we had deliberately disabled user switching in fusa
<Mirv> asac: yep, as far as Firefox is concerned
<persia> Hrm?  Isn't that what the "us" in "fusa" represents?
<asac> Mirv: ok cool. could you please verify that language-pack-fi-base contains the xulrunner-1.9 translations ? e.g. dpkg -L language-pack-fi-base  | grep xulrunner-addons
<ogra> asac, no, i'm just discovering that a) all ltsp related fusa patches were dropped b) you cant log out anymore and c) the gnome-power-manager patches that prevented users from shutting down the server seem to be dropped as well
<ogra> *SIGH*
<highvoltage> ouch.
<asac> ogra: how comes?
<Mirv> asac: yes it does, xulrunner-1.9-fi.jar among else
<ogra> and beyond that i can switch to a guest session that kills the server
<asac> Mirv: great. thanks for confirming
<asac> Mirv: do you have a hardy install?
<ogra> asac, new fusa, missing patches or dropped patches i wasnt told about :/
<asac> poor ogra
<asac> ogra: there still is time ;)
<seb128> ogra: talk to ted, he's the one working on those
<ogra> seb128, yes, i just didnt expect that much fun that late in the release :/
<seb128> ogra: that's not late, those changes are there for a while
<asac> ogra: why wasnt that reported earlier in the cycle? do ltsp users only test at the very end?
<seb128> ogra: the fusa applet didn't change for weeks now
<highvoltage> asac: in many cases, yes (sorry)
<ogra> seb128, the debconf note and the switch only happened on thurs/fri on all my systems here
<ogra> seb128, bu it wasnt the default logout option until last week
<seb128> ogra: ah right, the configuration migration is new, debconf note?
<asac> yeah. its a common problem for NM too. all the wierd chipsets get on it short before release
<ogra> yes
<ogra> a broken note btw
<seb128> ogra: it was on new install for weeks, there was just no configuration migration on upgrade
<ogra> saying (null) as header, referring to an "update" button i dont get in german
<seb128> mvo: read that?
 * ogra was sure he saw a fusa changelog entry that the ltsp patches were forward ported 
<mvo> ogra: is your update-notifier up-to-date (and/or restarted)?
<cjwatson> ogra: debconf? are you sure you don't mean the notification icon?
<ogra>  * 71_no_ltsp_user_switching_option.patch: Refressing to new build and making
<ogra>      sure that LTSP_CLIENT is checkd on GConf key change also.
<ogra> cjwatson, yes, i meant that, sorry i'm very upset atm ...
<ogra> mvo, yes
<persia> mvo, There's no "Name:" in the note.
<mvo> ogra: hm, so the update script needs to check for ltsp too?
<mvo> persia: yes, that is a feature, the new update-notifier should deal with that correctly
<ogra> mvo, well, that wont help on fresh installs
<ogra> fusa used to not offer user switching at all, now it offers the guest session, picking guest kills my system
<mvo> ogra: right, what about upgrades? should I add code that checks for ltsp? what is the right thing to do here?
<ogra> fixing fusa is the only thing i fear
<Mirv> asac: I have one hardy install, and can confirm the reported problems that the -proposed language packs (20080929) break firefox translations in hardy.
<mvo> ogra: ok, thanks
<ogra> you cant rely on the fact that the sysadmin doesnt update while sitting on the server
<ogra> which means it will become the default logout option
<ogra> for all users
<ogra> though logout does nothing because fusa only respects gdm it seems
<asac> Mirv: are there translations in xulrunner-addons and firefox-addons?
<asac> Mirv: proposed? could you please test the PPA?
<asac> Mirv: i think this is about the cure which is ment to be in PPA
<asac> ArneGoetje: err, where is that PPA?
 * StevenK checks if he can kill -6
<StevenK> Hah, I can.
<StevenK> pitti: Once gnash is fixed, I think libltdl3 can *finally* be NBS'd out. mit-scheme remains on i386, but I have no idea how to fix it, and it's been broken since Hardy.
<slytherin> pitti: need some help. The binary for libxstream-java was eaten by LP when moving from multiverse to universe and back again. (bug #268538). Any idea how can it be restored?
<ubottu> Launchpad bug 268538 in libxstream-java "Please move package to universe" [Wishlist,New] https://launchpad.net/bugs/268538
<persia> tjaalton, About bug #274203 : is there any way to just blacklist everything that wants to be a joystick by default?  Most users won't have (or know to install) xserver-xorg-input-joystick, and even when installed, it breaks use of joystick+mouse (e.g. for FPS games).
<ubottu> Launchpad bug 274203 in xorg-server "Joystick detected as mouse, crashes X" [Undecided,Fix released] https://launchpad.net/bugs/274203
<Mirv> asac: the -proposed packages seem to delete the ff/xr translations that were in the language-pack-fi-base package. having reverted to versions in hardy-updates that work, installing update from the langpack PPA breaks translations again
<tkamppeter> Can someone have a look at the buildds? On HPLIP I got
<tkamppeter> libcups2-dev: Depends: libgnutls-dev
<Mirv> asac: in the PPA case, the translation files are there, but Firefox complains that firefox translation is not compatible with ff 3.0.3. (xulrunner works, though)
<asac> Mirv: so is there anything in those ppa langpacks?
<tkamppeter> libcups2-dev: Depends: libgnutls-dev but it is not installable
<asac> Mirv: *sigh*
<asac> Mirv: ok. thats a launchpad bug then most likely :(
<asac> Mirv: what size do the .jar files have?
<asac> Mirv: and what maxversion/version is in install.rdf for xul and ffox
<Mirv> asac: xr 111kB, ff 48kB, ie. the same as on this working intrepid installation
<Mirv> asac: xr version 1.9.0.3, maxversion 1.9.0.*, ff version 3.0, maxversion 3.0
<asac> oh dear
<asac> that sounds like a launchpad-doesnt-like-some-kind-of-security-uploads issue
<asac> Mirv: thanks
<Mirv> asac: no prob. good that intrepid now works, anyway.
 * asac goes and looks what is in the full hardy export
<asac> yeah.
<asac> ok so the delta back from 9th sep is ok; next one is 29th sep which contains an old export :/
<ogra> pitti, did you write the guest session patch for fusa ?
 * ogra sees various checks for LTSP_CLIENT in that patch which doesnt seem to do anything at all
<pitti> ogra: yes, the original one; ted ported it to the new one
<ogra> ah
<pitti> slytherin: hm, I guess we can only upload a build1 and shove it through NEW
<Keybuk> cjwatson: is the Launchpad auto-bug-closing stuff actually working?
<tjaalton> persia: not really.. and that crasher should be fixed, but maybe it crashes somewhere else now
<persia> tjaalton, I've several devices (joystick, gamepad, half-keyboard for FPS) that can crash X with a single button press.  What's the best information to get you to make it not crash?
<jcristau> persia: gdb backtrace
<persia> jcristau, Of X?
<jcristau> if X crashes, yes
 * persia cringes.
<persia> Is there a way to get apport to do this, or should I be attaching gdb to X remotely, installing dbgsym manually, and calling bt ?
<mdz> sladen: fiddling with thinkpad hotkey mask issues, are you around?
<cjwatson> Keybuk: I've seen it work recently, yes
<tjaalton> persia: apport should work, in theory at least
<Hobbsee> mvo!
<StevenK> pitti: NBS cleaned out
<pitti> :)
<StevenK> pitti: Do you agree about breaking mit-scheme?
<kwwii> asac: did the rounded gtk entry bug-fix patch make it into firefox for intrepid?
<pitti> StevenK: if it didn't even work in hardy, sure
<slytherin> pitti: Ok. I will ask geser or persia.
<cjwatson> Keybuk: e.g. bug 271796 just got automatically closed
<ubottu> Launchpad bug 271796 in gparted "gparted doesn't see raid /dev/mapper devices in Intrepid Alpha 5 installation" [Medium,Fix released] https://launchpad.net/bugs/271796
<seb128> Keybuk: you were asking about the gnome-screensaver bug? that's because the bug had no gnome-screensaver task listed
<seb128> Keybuk: the bug need to have a task corresponding to the package uploaded otherwise launchpad just does nothing (it would make sense to add a comment in the bug about the upload though)
<seb128> hum
<seb128> "Depends: libgnutls-dev (>= 1.4.0) but it is not installable"
<seb128> StevenK: do you know about that?
<StevenK> seb128: Nope
<StevenK> We didn't remove it yet
<StevenK> Unless pitti has
<seb128> StevenK: http://launchpadlibrarian.net/18496352/buildlog_ubuntu-intrepid-i386.gst-plugins-good0.10_0.10.10.2-1ubuntu1_FAILEDTOBUILD.txt.gz
<StevenK> Hmmm
<pitti> no, I just moved gnutls13 and opencdk to universe
<pitti> but libgnutls-dev is built by gnutls26, isn't it?
<StevenK> There your answer might be
<pitti> urgh, so soyuz moved gnutls26's binaries to universe when I moved gnutls13?
<StevenK> It did?
<pitti> checking
<pitti> bah, apparently it did
<persia> jcristau, I've been trying https://wiki.ubuntu.com/X/Backtracing but I can't seem to get gdb attached, and then send the crash event to X.  Any suggestions on alternate ways to discover this?
<pitti> fixed
<jcristau> persia: over ssh?
 * persia tries more
<StevenK> pitti: Not until the next publisher run, surely?
<pitti> yes, of course
 * StevenK tries to fix octave-gpc
 * StevenK will say "Lalala, what's lpia?" when NBSing out libhdf5-serial-1.6.5-0
<persia> hey.  Some of us use that arch!
<persia> (not that it matters for that package)
<highvoltage> StevenK: hehe
<StevenK> Or it's rdepends
<StevenK> Hmmmm.
<StevenK> How did we lose octave2.1-headers, and Debian didn't?
<persia> There was some confusion with the octave transition.  I think sistpoty might know about it.
<wgrant> (pitti) superseded by octave3.0
<pitti> that's what I was told by shermann
<pitti> \sh: still remember the octave 3.0 transition? ^
<wgrant> Why should it ahve stuck around, StevenK?
<StevenK> wgrant: octave-gpc still Build-Depends on it
<wgrant> Ah.
<pitti> slangasek, cjwatson: I'd appreciated if one of you could review/ack my gparted/hardy SRU for bug 37768
<ubottu> Launchpad bug 37768 in gparted "gnome-volume-manager mounting Partition, while working with GParted" [Medium,In progress] https://launchpad.net/bugs/37768
<mvo> pitti: I see a some duplicates of bug 145360 where I can not find a retraced stacktrace in the report but that  got marked duplicate. is that because apport does not attach the retraced stacktrace when it things its a duplicate?
<ubottu> Launchpad bug 145360 in compiz "compiz.real crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/145360
<pitti> mvo: yes, that's what usually happens
<mvo> pitti: those we can be certain that its not a artifact because the stracetrace contained only "??" ?
<mvo> s/those/so/
<pitti> mvo: those are never auto-duped
<pitti> mvo: as soon as there is a single ?? it is failed-retrace
<mvo> ok, thnaks
<mvo> thanks
<pitti> cjwatson: FYI, linux-debug is now built with a .ddeb extension, so that it's on ddebs.u.c.
<Hobbsee> mvo: is there anything specific that i need to know about modifying unattended-upgrades?
<mvo> Hobbsee: don't break it
<mvo> Hobbsee: nothing other than this
<mvo> Hobbsee: what do you want to modify?
<Hobbsee> mvo: it still refers to hardy.
<mvo> Hobbsee: d'oh
<Hobbsee> mvo: oh, i thought it might have been some frankenstinean apt-like thing, or something.
<wgrant> I doubt you can not break unattended-upgrades; users manage to remove half of GNOME even with attended ones...
<ogra> seb128, would you mind a patch to gnome-session that hides the shutdown item in the system menu if LTSP_CLIENT is set ? its not critical as the action is a no-op but would be nice to not have it shown
<Hobbsee> mvo: do you want to fix it, or are you happy for me to?
<mvo> Hobbsee: I can update it too, I don't mind, just make sure you update bzr as well please
<Hobbsee> mvo: ahhh, k.
<Hobbsee> will do.
<seb128> ogra: that would rather be a gnome-panel patch no? but I'm fine adding ltsp patches just ping me for review before uploaded and use bzr so mvo is happy too ;-)
<mvo> Hobbsee: ok, let me know when its ready please
<mvo> bzr!
<ogra> seb128, will do, ah, gnome-panel is it then :)
<StevenK> checking for Octave version... 3.0.1
<StevenK> configure: error: version of octave must be 2.1.57 or later
 * StevenK kicks it
<directhex> StevenK, does it really work with 3, or is it a simple "looking for wrong pkg-config entry" thing?
<mvo> pitti: would it be possible to get the retraced stacktrace in the duplicates too? for the compiz report it would be useful to see how the line numbers changed
<seb128> mvo: the issue is that somebody would have to check those for private informations then
<seb128> mvo: now we can mark the duplicates public because we clean the bugs before
<pitti> mvo: sure, I can revert the change; someone, I think bdmurray, asked for removing the stuff and make the bug public
<pitti> mvo: and it also avoids quite a lot of bug mail spam
<mvo> hm, I see
<Hobbsee> mvo: oh man...you've still got references to gutsy in here too!
<seb128> pitti: speaking about the retracer I gave some human readable names to the screen there
<pitti> so I'm not quite sure what the right thing is here
<mvo> Hobbsee: tsss
<pitti> seb128: cool, that's possible?
<seb128> pitti: yes, look on ronne ;-)
<pitti> nice!
<asac> kwwii: no. 1.9.0 branch doesnt get that kind of fixes anymore
<asac> kwwii: upstream is a bit harder about branch rules now that they have a quicker release cycle
<Hobbsee> mvo: pushed to bzr.  Can I upload it too?  :)
<persia> jcristau, I installed some -dbg packages, and crashed X a couple times.  My stacktrace is still two lines, with #1 at 0x0000000000000000, so I'm guessing there's something wrong at a fairly high level.  I submitted the bug to apport, to see if the retracer would be able to get any more information.
<mvo> Hobbsee: sure, looks fine
<Hobbsee> hmm.  it didn't show up my mail right.
<persia> jcristau, It's bug #282640, if you want to take a look before apport gets to it.
<ubottu> Bug 282640 on http://launchpad.net/bugs/282640 is private
<pitti> Riddell, ScottK2: in order to fix bug 274189 I need to teach jockey to start itself through kdesu or kdesudo; which one should be used nowadays, and in which package is it? kdesudo?
<ubottu> Launchpad bug 274189 in jockey "jockey-kde crashed with dbus ServiceUnknown error in call_blocking (KDE PolicyKit agent not available)" [High,In progress] https://launchpad.net/bugs/274189
<Hobbsee> mvo: uploaded :)
<mvo> thanks Hobbsee
<Hobbsee> mvo: you're welcome
<Riddell> pitti: /usr/lib/kde4/libexec/kdesu
<pitti> Riddell: ah, thanks; that's in which package?
<Riddell> pitti: it's in kdebase-runtime
<pitti> splendid, thanks
<pitti> hm, now if only jockey-kde --check would actually produce an icon in gnome-panel...
<jcristau> persia: iz private :)
<wgrant> It's really, really private.
<wgrant> Or my membership in ~ubuntu-dev has expired.
 * persia subscribes more people.
<ogra> persia, keeps it in his closet :)
<persia> It's *really* private.
<persia> jcristau, You should be able to open it.  If you can't, that's an LP bug.
<persia> wgrant, You too, now.
<persia> apport keeps bugs *super* private until the coredump is processed.
<wgrant> Hmm.
<wgrant> I though we were subscribed from the start.
<persia> No, not until the retracer has run.
<wgrant> Maybe I just never get to them quickly enough.
<wgrant> Well, I guess I never see them.
<persia> Right.  You'd only know if you reported bugs with apport, and watched :)
<jcristau> meh. i thought i'd fixed GKVE
<wgrant> Yes,
<persia> Indeed.  The changelog gives that impression, but ...
<cjwatson> pitti: sorry, can't deal with 37768 at the moment :(
<cjwatson> pitti: linux-debug> ah, thanks; please mention that in the bug if you haven't already
<pitti> cjwatson: no problem; I just pinged you becuase you created the hardy task
<pitti> cjwatson: done
<cjwatson> the patch makes sense though
<persia> tjaalton, I've a concern about the idea of adding any joystick that is reported to crash X to the .fdi file.  This doesn't sound like something that can be maintained.  Is that really the only way to go about it?  I'm not concerned about joysticks not working in X, only about them breaking other things.
<jcristau> persia: the idea is to fix the server so it doesn't crash..
<persia> (By "not working in X" I mean "not detected as XInput devices")
<persia> jcristau, OK.  That works.  I'm just responding to https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/274203/comments/40
<ubottu> Launchpad bug 274203 in xserver-xorg-input-joystick "Joystick detected as mouse, crashes X" [Undecided,New]
<wgrant> apport is being a bit sluggish.
<kwwii> asac: so that means it'll have to wait until intrepid+1? (I am asking because I need to change all our gtkrc's and doing it in advance will break things)
<persia> Indeed, but I think I had most of the -dbg packages installed.  Stacktrace.txt is mostly readable (and completely different than what gdb showed me)
<asac> kwwii: yes. ffox 3.1 will have that feature
<asac>  /bugfix
<asac> 3.1 will be our main browser in jaunty unless something unexpected happens
<tjaalton> persia: the priority is to make it not crash, and after that add support for -joystick to pick up the device
<persia> tjaalton, OK.  That works for me.  Given that most of the tools that use joysticks currently break when they don't have exclusive access, I'm tempted not to add anything to the .fdi file, but that's more because I don't want to fuss with SDL than because it's the right solution.
<Keybuk> seb128: oh, I see - it was on gnome-desktop
<kwwii> asac: great, thanks
<mdz> tjaalton: I've put a test package into my PPA, could you test it on your thinkpads? (bug 222796)
<ubottu> Launchpad bug 222796 in linux "Brightness up not generating ACPI event on Thinkpad T43p, T42, X31, X40, R52" [Medium,Triaged] https://launchpad.net/bugs/222796
<mdz> (anyone else with a thinkpad: testing appreciated)
<crevette> mdz: HELLO TESTING WHAT?
<crevette> oupssss
<crevette> sorry
<mdz> crevette: install the new hotkey-setup package from my PPA and check that your hotkeys still work (or if they aren't working, that they start working)
<crevette> Ok, I'll test on my t61
<crevette> I'm coming for a regression on my webcam, does my bug is clear: https://bugs.edge.launchpad.net/ubuntu/+source/linux-meta/+bug/282641
<ubottu> Launchpad bug 282641 in linux-meta "[regression] pwc driver claims it can use v4l2 for Philips 740 webcam where it shouldn't" [Undecided,New]
<crevette> and is it open against right component
<crevette> ?
<wgrant> crevette: No - the package you want is linux.
<crevette> tx wgrant
<mdz> wgrant: just fixed that
<mdz> crevette: also, please report bugs using "ubuntu-bug" in the future
<mdz> crevette: see
<mdz> https://help.ubuntu.com/community/ReportingBugs
<wgrant> mdz: Thanks.
<mvo> ogra: if you work on gnome panel, please let me know, I will have to do a upload today too I think
<mdz> crevette: that will attach your hardware info (which is missing from the bug)
<ogra> mvo, ok, i just started
<crevette> mdz: I didn't get you about "ubuntu-bug", whayt are you talking about?
<crevette> ah okay
<crevette> I use to report on website for ages :)
<crevette> I'll try ubuntu-bugs now so
<Ng> mdz: do you want comments of it not breaking anything on the bug? all the hotkeys I know to have previously worked on my X300 still do
<mdz> Ng: yes please
<Ng> k
<mdz> Ng: I know it fixes the problem I found, but I need regression testing
<Ng> done
<ogra> meh, shutdown sits in an enum ... thast harder than i thought
<tjaalton> mdz: works on my X61 like before, so no regressions there
<mdz> tjaalton: thanks
<pitti> Riddell: do I really need to call kdesu with full path, or is /usr/lib/kde4/libexec/ in $PATH under Kubuntu?
<mdz> does anyone have an nvidia-based thinkpad?
<Keybuk> mdz: my nvidia-based machine is a desktop
<mdz> Keybuk: there are a couple of places in hotkey-setup where it special-cases nvidia-based thinkpads
<Riddell> pitti: it's not in the path.  kdesudo is in the path but it's possible people will uninstall that so /usr/lib/kde4/libexec/kdesu is more reliable
<mdz> mjg59 says this is because the driver didn't/sometimes-still-doesn't support xrandr 1.2
<Keybuk> right, if you have it in TwinView, for example
<Keybuk> or Xinerama enabled
<ogra> seb128, is teher a reason my gconf-editor is gotten so extremely slow ?
<seb128> ogra: no idea, mine is as fast as usual
<ogra> (slow enough for compiz to grey out the window very often if i jump between items)
<ogra> hm, k might be me if nobody else complains
 * ogra testbuilds gnome-panel to test the change
<tseliot> mvo: ping (you know why)
<mvo> tseliot: today!
<tseliot> mvo: really?
<mvo> tseliot: yeah
<mdz> along with slangasek's rfkill fix, the hotkeys on my thinkpads now work as well as they did in 8.04
<tseliot> mvo: \o/
 * sladen looks at the mask fix
<mdz> sladen: in particular, I'd like to confirm that I understood the logic for thinkpad-keys correctly
<Keybuk> it would be nice to put some effort into eliminating all of these pieces in jaunty
<Keybuk> acpi-support, hotkey-setup, vbetool, etc.
<mvo> tseliot: what is the bugnumber for it?
<liw> Keybuk, will Ubuntu use upstart natively, ditching run levels, and rc.[0-9]d?
<ogra> liw, thas a massive amount of work ...
<ion_> liw: Yes, but not yet.
<ogra> espectially if you take universe into account ...
<ogra> the change wil likely span over several releases
<mvo> tseliot: "    - remove input devices from xorg.conf (handled via hal now)" <- correct?
<tseliot> mvo: yes, that's correct
<mvo> tseliot: and xkit is installed by default now on {ku,u}ubuntu-desktop?
<tseliot> mvo: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/247608
<ubottu> Launchpad bug 247608 in xserver-xorg-input-synaptics "[Intrepid] touchpad on dell laptop does not scroll" [Medium,Confirmed]
<mvo> thanks tseliot!
<tseliot> mvo: jockey-common and some other stuff depend on python-xkit
<mvo> tseliot: excellent, thanks
<tseliot> mvo: :-)
<ogra> yay, my gnome-panel patch works :)
<seb128> pitti: did you change the gnutls binary back to main in intrepid?
<Keybuk> liw: I like how my answer is so well known, other people answer it for me :p
<Keybuk> I have a veritable bunch of work to do from jaunty onwards, some of it is foundation laying, and other bits will actually have an effect on boot speed
<pitti> seb128: yes, I did; was a soyuz glitch
<seb128> pitti: ok because they are still in universe, I guess publisher is still running or something?
<pitti> seb128: hm, maybe; it should be done by now, though
<pitti> libgnutls-dev | 2.4.1-1build1 |      intrepid | amd64, hppa, i386, ia64, lpia, powerpc, sparc
<pitti> seb128: in main, feel free to retry the build
 * pitti is off for a bit
<seb128> pitti: retried, thanks, seem they have just been updated between my ping and now ;-)
<ogra> mvo, where is the bzr tree for gnome-panel ? debian/control has no hint
 * ogra also files bug 282669 for it with the fix attached
<ubottu> Launchpad bug 282669 in gnome-panel "should hide shutdown action on ltsp clients" [Undecided,New] https://launchpad.net/bugs/282669
<ogra> *filed
<cjwatson> liw: note that using upstart natively doesn't necessarily mean ditching runlevels, as event.d jobs can trigger on runlevel changes
<ogra> seb128, ^^^ fix included, i think its small enough
<seb128> ogra: there was no need to open a bug, you can just upload the change if you want, wait for mvo's reply about bzr though
<ogra> yep
<ogra> seb128, well, i wanted you to take a look at the change first :)
<seb128> I did, the change look correct and is trivial enough
<ogra> thanks :)
<ion_> Could someone please apply http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
<ubottu> Launchpad bug 278195 in gnokii "Incorrect encoding for the synchronized entries" [Undecided,New] https://launchpad.net/bugs/278195
<mdz> sladen: thoughts?
<slytherin> mvo: has slomo already talked about the broken codec installation magic?
<crevette> kees: /msg hello
<crevette> mdz: hotkey-setup seems to work fine for me on my T61
<mdz> crevette: thank you
<crevette> mdz: perhaps this is totaaly unrelated but the duration between pressing the light button and the menu apperance is long (0,7 sec) and it feelsing sluggish if it press the same button several times
<crevette> the light change is not change immediatly
<crevette> s/change/request/
<mdz> crevette: yes, that's known, and not a regression
<mdz> crevette: unless it worked better before you installed that update
<crevette> okay, fine then
<sladen> crevette: ps aux | grep thinkpad-keys   is it in polling mode?
<lool> pygtk failed to build on ppc in Xvfb startup; I suspect the chroot is the issue as the previous version built fine and the new one built fine on other arches
<lool> Who could I poke to unbreak the chroot?
<crevette> sladen: it returns no process
<seb128> lool: try infinity I would say
<sladen> crevette:
<lool> seb128: thanks
<seb128> superm1: hey, any idea about bug #282325?
<ubottu> Launchpad bug 282325 in nautilus-sendto "nautilus-sendto doesn't support Obex Push file transfer anymore" [Undecided,New] https://launchpad.net/bugs/282325
<superm1> crevette, ^
<superm1> seb128, I've seen the same thing, crevette and slytherin were the last to look at it.  If they don't have any update for it, i'll try to look at the code once I make more progress on the KDE solid stuff.  It's turning into a rather large mess :(
<seb128> superm1: I pinged crevette about it but he has no idea about the issue apparently
<seb128> superm1: ok thanks
<lool> Actually pygtk failed to build on all real chroots
<lool> tjaalton: I see you pulled a new xvfb in intrepid a couple of days ago; I suspect it broke xvfb-run for pygtk
<crevette> superm1: I'm not really fluent in bluez code
<crevette> I need to see with upstream developer
<crevette> hello by the way
<davmor2> mvo: ping
<mvo> davmor2: pong
<davmor2> mvo: is it you whose written the update config script to remove the log out icon from the panel?
<mvo> davmor2: yes
<davmor2> mvo: Is it meant to move the fusa icon to the top right too?
<mvo> davmor2: yes
<mvo> davmor2: what does it do for you?
<davmor2> mvo: It leaves it to the left of n-m applet where the quick switch user applet was.  Do you need to reboot with it at all?
<mvo> davmor2: the dialog that comes up should tell you to logout to complete it, did that appear?
<dholbach> james_w: in the "eliminating debdiffs" thread - what did you think about the "patch triage" idea?
<james_w> dholbach: what's that?
<james_w> going through the "bugs with patches" list?
<ogra> #1
<dholbach> james_w: it was my last reply to the thread (to Colin's mail)
<davmor2> mvo: The dialog read the same I think I'll double check should be too long :)
<superm1> crevette, well if you can try to look if you can make sense of the code, that'd be good at this point.  i probably won't be able to until later in the week
<mvo> davmor2: there is a bug in the gnome panel it seems that require logout/login after the script is run. could yu please check if the button is in the right position after the logout?
<superm1> crevette, and hello :)
<mvo> (or rather on the next login)
<davmor2> mvo: double checking now
<tjaalton> lool: somehow doubt it :)
<davmor2> mvo: is it down to the way it locks to the panel by any chance?
<davmor2> mvo: yeah it's in the right place I'll double check the dialog in the windows though
<mvo> davmor2: thanks! not sure if its related to the "lock to panel" option, I may try
<davmor2> mvo: I found it frustrating when adding snapshot applet that in order to get it by the power applet I need to switch of lock on all the applets re-arrange and lock everything back down.
 * mvo nods
<mdz> cjwatson: were the notes/actions from the release meeting mailed out anywhere? I can't find them
<mdz> I know I signed up for a few things but am not sure if I have done them all yet
<lool> mdz: if you like the log: http://irclogs.ubuntu.com/2008/10/10/%23ubuntu-meeting.html
<mdz> lool: I think we ought to have a proper summary, but thanks
<dholbach> james_w: for a smooth transition from "millions of patches in LP" to "~0" by using 1) a tag that basically says "we know this is a patch, it's documented and we know where it's from, etc", 2) the sponsorship queue
<crevette> superm1: I'm blocked 1 hour feeding my son, i'll try to see after
<lool> mdz: Yeah, this was just to unblock you
<cjwatson> mdz: I was going to refer you to mootbot for the time being but it seems not to have a record of that meeting despite allegedly logging it (?)
<lool> mdz: (mootbot log not being uploaded yet)
<cjwatson> mdz: I haven't seen a proper hand-written one yet
<cjwatson> slangasek: -
<cjwatson> blink, whatever that was
<lool> cjwatson: the logs are pushed manually by someone from time to time
<dholbach> james_w: so we don't have to interpret the bug status as a patch status, and write document what needs to be done for stage 1 and 2, also it will help us so that sponsors only need to check the actual programming changes in the patch and not if it applies, etc - if somebody adds a changelog entry along the way, even better
<james_w> dholbach: yeah, I think it would work quite well. Is it possible to get notifications of new patches?
<dholbach> james_w: AFAIK there's only the huge list
<dholbach> james_w: but I'm sure that a bunch of bugdays/bugjams would help with that :)
<ogra> mvo, have you seen bug 282669 ? (and where is the bzr branch, debian/control doesnt point to any)
<ubottu> Launchpad bug 282669 in gnome-panel "should hide shutdown action on ltsp clients" [Undecided,New] https://launchpad.net/bugs/282669
<mvo> ogra: I haven't. I have a local bzr tree, but feel free to just upload, I will merge manually, I haven't pushed my branch
<ogra> oki
<ogra> sigh, quilt
 * ogra curses
<mvo> ogra: I share your pain
 * ogra testbuilds to make sure he didnt make quilt errors 
 * ogra hugs james_w ... thanks for the netbook-launcher upload
<ogra> though you didnt pull the new upstream
<s0u][ight> is there someone around with the iwl4965 device?
<james_w> ogra: there was only one change upstream. Neil is going to port the rest of the fixes this week.
<ogra> ah, k
<davmor2> mvo: upgrade is saying 30-ish minutes for the packages to be installed will you still be around?
<mvo> davmor2: yes
<s0u][ight> where can i find the devs of wireless network device drivers?
<davmor2> mvo: cool :)
<unfo> hi all.  My doctor is a total noob.  Maybe things are different now, but last time I checked, she didn't know how to use the Location bar.  So to get to CNN, she would Google for www.cnn.com.  Should we change the ubufox start page to www.google.com to help people like her?
<Laney> The ubuntu start page has a google box
<davmor2> mvo: yes the window has popped-up I must of hit update and close pretty much straight away and missed it.
<Laney> Which gets the focus by default
<mvo> davmor2: ok, so everything is normal?
<davmor2> just rebooting now
<unfo> Laney: I dunno if that would work for people as noobish as my doctor.
<unfo> all : what do you think?
<davmor2> mvo: Yeah fine after reboot.  It took a little while for the lightbulb to pop up but other than that it's fine
<unfo> Laney: I suspect that http://start.ubuntu.com/8.04/ is too different from the Firefox Start screen she is used to, and that it would confuse her.
<cjwatson> unfo: I think if you assume people don't read, can't absorb any kind of information, etc. then at some point you have to conclude that helping them is going to impede others
<davmor2> unfo: it already does
<cjwatson> unfo: life in OS design is a trade-off
<cjwatson> unfo: I would expect (and hope!) that doctors are generally intelligent people capable of absorbing information even if they happen not to know it to start with (and if not shouldn't you be worried about them being your doctor? :-) )
<unfo> cjwatson:  no, I don't care that my doctor doesn't care and doesn't want to learn anything about computers.  she is an excellent doctor.
<cjwatson> unfo: the only way to find out whether it will work or not is to try
<unfo> here's the only solution I could think of.  use a traditional "Firefox Start"-like webpage, but at the bottom, when you scroll down, have a few screens of Ubuntu-related info.
<cjwatson> unfo: I didn't mean to imply she wasn't; I meant to imply that given that she is a good doctor, the ability to absorb information is generally a transferable skill
<unfo> cjwatson:  I'm not offended at all.  Just always keep in mind that to some people, a computer is like a toaster.
<cjwatson> unfo: I would suggest trying it (in a hands-off style; see whether she picks it up in a few minutes without helping her) rather than making assumptions
<unfo> cjwatson:  They assume, "plug it in and it works."
<cjwatson> unfo: sure, but we can't design for people with *no* ability to do *anything*
<unfo> cjwatson:  no.  I see my doctor rarely.  She is happy with Windows.  She is the last person I would ever consider converting.
<cjwatson> then leave it be
<unfo> cjwatson:  why don't you design for those people?  many of those people are plagued with spyware.
<cjwatson> unfo: where did I say that Windows users had no ability to do anything?
<unfo> They might benefit from Ubuntu.
<cjwatson> unfo: I said that we can't design for people with no ability to do anything. That's quite a different statement
<unfo> cjwatson: you didn't say that.  I put the words in your mouth maybe :)
<cjwatson> unfo: I think you're making an unwarranted assumption about people's inability to see a bar with "Google" printed next to it and work out that it is related to Google
<unfo> I am saying, many people have no ability to do anything.  Most of them now use Windows.  Why shouldn't we design Ubuntu so it meets those people's needs?
<cjwatson> (oh, and with "Search" written on the other side)
<cjwatson> but that simply isn't true. They had to pick up a certain amount in order to use Windows too
<unfo> cjwatson: could we use a real Google logo, and enlarge that search bar area with lots of padding so it takes up 200 vertical pixels?
<unfo> cjwatson: true
<ogra> it is using a real google logo, isnt it ?
<cjwatson> it looks like a real Google logo to me
<unfo> ogra: oops, I was browsing with images off..
<unfo> I had only set "allow images from start.ubuntu.com" under Exceptions.  my bad.
<unfo> does anyone here have a true noob in their home or office?  could they test start.ubuntu.com/8.04/ on them?
<cjwatson> I really don't think the current page is unreasonable. Yes, I know that developers are usually the worst people to make these kinds of decisions, but even so I think it is a fair trade-off between access to the ability to search and provision of information. Surely there are many worse problems?
<unfo> cjwatson: I am not 100% sure but I suspect it is not the ideal trade-off.  But it depends who your audience is.
<juliux> hi
<unfo> Perhaps the right thing to say is "people as noobish as unfo's doctor, who don't want to learn anything about computers, should not use Ubuntu".
<juliux> is there any way how i can test something in on a 64bit system without having a 64bit cpu?
<broonie> unfo: How many of these people are going to be confused by anything that isn't exactly IE?
<cjwatson> you can certainly make general-purpose computers easier, but you can't turn them into a toaster. A web browser requires more controls than that.
<unfo> juliux: wrong channel.  join me in #ubuntu
<unfo> broonie: a lot.
<mvo> davmor2: cool. the delay is know and a "feature". it makes the session statup faster if  the update checks are run later
<davmor2> mvo: np's
<cjwatson> I really don't buy this. My mother was AFAICT an excellent example of this; she was generally uninterested in learning about computers, and exhibited some confusion when things changed around, but had no problem using Firefox. Yes, it was different, but she picked it up.
<ogra> unfo, what will your doc do if XP is done and only vista is available ?
<ogra> ir vistas successor
<ogra> the world simply changes all the time ...
<cjwatson> (in other words I've already done this test ...)
<pitti> juliux: possible with qemu according to http://qemu-forum.ipi.fi/viewtopic.php?f=3&t=4296
<cjwatson> in fact this was before the start page offered Google as prominently as it now does
<ogra> juliux, be aware thats really slowish
<pitti> of course, full emulation
<davmor2> cjwatson: ditto My wife had never used a pc I showed her quickly what to do how to bookmark and how to find them after and she's quite happy browsing to her hearts content
<liw> on newbies switching to Linux: http://liw.iki.fi/liw/log/2006-Debian.html#20060728c and http://liw.iki.fi/liw/log/2007-Debian.html#20070124b
<cjwatson> unfo: (for the avoidance of doubt I think there are plenty of things we should improve for new users; I just don't think this is one where we need to worry too much)
<juliux> ogra: pitti thanks i will order a 64bit cpu at work;9
<pitti> juliux: definitively the more performant solution :)
<pitti> juliux: it might even ship by the time an emulated install finishes :)
<juliux> pitti: yeah and the cheaper one;)
<ogra> heh
<cjwatson> gah, cdimage got stuck on a lock again
 * lool gives the claws to cjwatson 
<unfo> cjwatson:  phone.  back in 1 hour.
<lool> tjaalton: Any idea on what's going on with http://launchpadlibrarian.net/18503157/buildlog_ubuntu-intrepid-hppa.pygtk_2.13.0-0ubuntu7_FAILEDTOBUILD.txt.gz
<lool> Xvfb failed to start is all I get
<jcristau> meh. no error log?
<lool> jcristau: Do you spot anything wrong with my -e usage?
<jcristau> xvfb-run, i officially hate you.
<lool> infinity: Sorry for the annoyance, but Xvfb is failing on some buildds and we get no output; do you think you could check what's going on?  e.g. http://launchpadlibrarian.net/18503157/buildlog_ubuntu-intrepid-hppa.pygtk_2.13.0-0ubuntu7_FAILEDTOBUILD.txt.gz
<cjwatson> TheMuso: the patch submitter of 122607 responded to your query; you might like to get back to him
<james_w> ogra: yeah, wireless doesn't work on your image, as both ath5k and ath_pci are loaded I believe.
<james_w> ogra: but your image boots automatically for me, whereas ones created with usb-creator require me to select the USB stick from the boot device list. Do you know why that is?
<lool> james_w: Are you writing to /dev/sdz versus /dev/sdz1 in some cases?
<ogra> james_w, our syslinux.cfg is just set to not prompt
<ogra> or rather to timeout
<james_w> lool: ah, that's probably it. I'm using ogra's image-writer for his images
<ogra> ah
<lool> ogra: I guess that "select USB stick from boot list" is BIOS
<ogra> the imagewriter is just a graphical DD frontent
<ogra> *frontend
<ogra> it uses hal to find eth device as usb-creator does though
<lool> mvo: Reproduced the -D_GNU_SOURCE issue you had with acpid with Debian experimental's libc6; thanks!
<crevette> heya
<pitti> tkamppeter: I'm currently considering making jockey only look for packaged PPD files, and not for drivers (at least not by default), as recently discussed; is there a printer model for which openprinting.org db returns a packaged PPD?
<tkamppeter> pitti, not yet. In which time frame do you want to do this? I could create a test package tomorrow or so.
<tkamppeter> The characteristic to recognize such a package is that it is for all architectures, which is found by searching for the architecture noarch or any (Packages without binaries in general).
<ogra> oh, who uploaded screem ?
 * ogra was just tinkering with that
<tkamppeter> pitti, do you have a PostScript printer? Then please tell me which brand and model, then I can make a package which you can directly test.
<ogra> since crimsun had asked me to
<pitti> tkamppeter: no, I don't; well, I have a bunch of "fake" printers to nonexisting ports :)
<pitti> tkamppeter: but I don't need to have the printer, querying for it and getting back a PPD package is enough
<pitti> tkamppeter: right, noarch=1 seems to be close, but woulnd't onlyppdfiles=1&onlydriverpackages=1 be more correct?
<crimsun> ogra: laserjock did.  I pinged him on identi.ca a couple days ago
<ogra> ah, k
<ogra> i was just confused :)
<mvo> lool: cool, cheers
<james_w> ogra: install went well, wireless works once ath_pci is blacklisted.
<munckfish> hi calc are you there?
<cjwatson> pitti: should bug 176994 be closed? I'm not sure what the packageless task is for.
<ubottu> Launchpad bug 176994 in ubuntu "Update Maintainer field in packages modified before DebianMaintainerField spec" [Wishlist,Confirmed] https://launchpad.net/bugs/176994
<mdz> does anyone know how to get the python gconf api to do the equivalent of "gconftool-2 -g"?
<mdz> I think I want gconf_engine_get but can't find it in the python api
<mvo> mdz: give me a sec
<mvo> mdz: /usr/share/gnome-panel/migrate-fusa-config.py should be a good example
<mdz>     client = gconf.client_get_default()
<mdz> mvo: I tried that, but it only seems to work within a session
<mvo> mdz: gconf.client_get_default() is the one
<mdz> mvo: gconftool-2 seems to work even outside of an active session
<mdz> maybe I should just call out to gconftool-2
<mdz> glib.GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not running within active session)
<mvo> mdz: oh, right. sorry, I missed that
<mdz> there is a gconf.Engine but it has only one method on it, associate_schema
<mvo> mdz: there is also gconf.client_get_for_engine() were the engine can be passed to. but I tried it and it just gives me the same error
<mvo> mdz: heh :) /usr/sbin/update-gconf-defaults is written in python but for the actual gconf manipulation it calls out to gconftool
<mdz> mvo: what I want to do is, for a list of keys, print those which are not at the default
<mdz> running gconftool-2 for each one takes a long time
<mdz> about 300ms each
<mdz> it does work though
<ogra> james_w, thanks a lot :)
<cjwatson> mdz: I wrote a gconftool module for ubiquity to deal with this :-)
<cjwatson> it also calls gconftool-2 for each key though
<cjwatson> and far from a complete API wrapping
<lool> mdz: import gconf; c=gconf.client_get_default(); c.get_without_default('<key name>')
<lool> mdz: returns None if unset
<mdz> lool: same problem
<mdz> glib.GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not running within active session)
<mdz> lool: get_without_default() seems to return a lot of false positives, too.  what I want is only keys whose value is not the default value
<mdz> gconf seems to have a different notion of what is 'default'
<lool> Ah only read last part of your question, didn't see "out of the session" constraint
<mdz> lool: I have already written the gconftool-2 version as a fallback, but want to use the fast path when there is a session
<stefanlsd> how long after intrepid is released does dev for jaunty open?
<ScottK> Usually a couple of weeks.
<stefanlsd> heh. looking forward too that
<cjwatson> I think we should be able to do the actual creation in a small number of days, but it can take a little while for the toolchain to settle enough to allow general uploads
<sebner> cjwatson: remember the gcc fun at the intrepid beginning ^^
<cjwatson> sebner: sure, it takes a while each time
<cjwatson> believe me warty was a lot more fun ;-)
<sebner> cjwatson: ah you were here since the very beginning? nice. 2004 /me not even own a computer
<cjwatson> sebner: yes - warty involved completely rebuilding the archive from scratch because we realised it was broken on Via C3
<cjwatson> that was before the archive was publicly mirrored so we could pull that sort of stunt :)
<sebner> hehe
<johanbr> cjwatson: I got usb-creator to detect the SD card, but it's still not quite working. Do you know if it's supposed to detect a block device or a partition?
<johanbr> I don't have a standard USB key handy, so I can't test.
<cjwatson> evand: ^- could you help johanbr?
<evand> sure thing
<evand> johanbr: where is it failing?
<johanbr> evand: It says the card needs formatting, so I click on Format, the button is greyed out, and not much more happens.
<nellery> bdmurray: the light does turn on when X is disabled
<evand> johanbr: can you pastebin the output of hal-device
<johanbr> evand: http://pastebin.ca/1226174
 * evand digs through the code
<johanbr> evand: Well, this is with some changes I made to make it detect the SD card.
<evand> johanbr: can you put up a diff as well then?
<murdok> Does anyone know how can I open the cursors in /usr/share/icons/DMZ-White/cursors ?
<murdok> which is the format :?
<ogra> its X cursor format :)
<murdok> lol :Ã¾
 * ogra would try a cursor editor :)
<murdok> where can I find one?
<murdok> mmm I'm looking in x11-apps
<mdke> slangasek: in previous releases we've tended to upload ubuntu-docs translations a bit after the NonLanguagePackTranslationDeadline, more around the LanguagePackTranslationDeadline. Would it be ok if we do the same again this release? Translators have had very little time due to LP issues
<murdok> no, x11-apps provides a cursors generator but not a viewer :?
<mdke> slangasek: so I'd like to give them a few extra days if possible. It shouldn't create any problems
<murdok> ogra: do you know any?
<ogra> murdok, no,and this isnt actually a support channel
<ogra> there is a lot documentation out theer how to generate cursors, best is to look that up i guess
<murdok> well, i know. but my goal was develop
<johanbr> evand: http://pastebin.ca/1226194
<evand> thanks
<johanbr> Just found something I got wrong, actually...
<evand> oh?
<johanbr> evand: I missed one check for storage.drive_type
<evand> we should take this to pm rather than spam #ubuntu-devel...
<ogra> infinity, is anyone looking after hppa nowadays ? feels like i get an FTBFS mail for every second upload
<jibel> slangasek: Hi, bdmurray told me you're familiar with grub. Could you take a look a bug 269539 ? This is an issue with the 3 way merge in update-grub.
<ubottu> Launchpad bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539
<hwilde> anybody here know about rsync --partial ?
<hwilde> it seems to just create a new temporary file instead of resuming
<TheMuso> Yay! The launchpad mail processing interface is actually working today...
<directhex> and it's official, latest bugfix-frenxy mono version landed on ftpmaster. now for an ubuntu1 merge diff
#ubuntu-devel 2008-10-14
<directhex> right. should i prepare a debdiff against -3ubuntu2, or -4? i forget which is preferred
<slangasek> pitti: ok, looked at the coreutils SRU now; and patched sru-accept to support a -s argument :-)
<mathiaz> slangasek: could you promote the -virtual kernel flavor to main?
<slangasek> mdke: ubuntu-docs translations> yes; what deadline are you giving translators?
<slangasek> mathiaz: it's seeded somewhere, I assume?
<directhex> bam. who wants to give bug 282952 a tickle? seeped in double-security-hole goodness!
<ubottu> Launchpad bug 282952 in mono "Please merge mono 1.9.1+dfsg-4 from Debian Unstable" [Undecided,New] https://launchpad.net/bugs/282952
<mathiaz> slangasek: yes - in the server-ship seed
<mathiaz> slangasek: It's in the component-mismatch.txt file
<slangasek> mathiaz: done
<mathiaz> slangasek: thanks you ! :)
<TheMuso> RAOF: I have uploaded 0.9.13 of pulseaudio to my PPA if you are interested.
<RAOF> TheMuso: I'll play around.
<gustavold> I upgraded my ubuntu to intrepid, now sound is not working properly... anyone could help me?
<RAOF> gustavold: Support in #ubuntu+1
<gustavold> RAOF: thanks
<TheMuso> cjwatson: ok that hang I mentioned earlier was a one off.
<StevenK> TheMuso: Oh!
<StevenK> TheMuso: Can I get you to retry libtunepimp on powerpc, but with an older binutils?
<TheMuso> StevenK: If I know where I can get an older binutils, sure.
<StevenK> TheMuso: Launchpad? :-)
<TheMuso> I thought launchpad didn't keep older binaries.
 * TheMuso looks
<wgrant> TheMuso: It does.
<wgrant> It has all old binaries and sources.
<TheMuso> ok great.
<wgrant> ANd build logs, unless somebody gave the build back. And everything else on the planet.
<wgrant> Librarian must be *huge*.
<TheMuso> StevenK: how many versions back do you want?
<StevenK> doko didn't say, just an older version :-(
<StevenK> I was guessing 2.18.50
<TheMuso> ok will try the one before the most current one.
<TheMuso> unless you want me to use that version.
<StevenK> TheMuso: Try that version, then a few more back. Then we can hit up doko with the results
<wgrant> Can I convince somebody to run xinput list-props on Intrepid !(i386|amd64)?
<StevenK> If the penultimate versaion works, that's fine.
<TheMuso> StevenK: ok.
<TheMuso> StevenK: Ok building...
<TheMuso> StevenK: ok going back another version of binutils
<StevenK> TheMuso: Should be finished? :-)
<StevenK> TheMuso: Only it fails the same way?
<TheMuso> StevenK: i checked config.log
<StevenK> TheMuso: No news is good news?
<TheMuso> StevenK: No, still moving back through binutils versions.
<TheMuso> back to 2.18.90
<TheMuso> ls
<TheMuso> oops wrong tab
<TheMuso> StevenK: back to 2.18.50
<TheMuso> which is what I am trying now.
<kees> slangasek, sbeattie: heads up on 230877 -- I'm about to release a dbus security update which will need the current -proposed to get rebuilt
<TheMuso> StevenK: Ok just tried binutils_2.18.50.20080610-0ubuntu1_powerpc.deb and still getting the error. Mind you I am only using the binutils package. Should I use any other of its binaries as well?/c
<StevenK> TheMuso: At this point, let's bug doko
<StevenK> TheMuso: Thank you for your help
<TheMuso> StevenK: np
<dholbach> good morning
<lukehasnoname> good morning
<lukehasnoname> 21:18 here in Lubbock
<dholbach> lukehasnoname: 7:21 here :)
<dholbach> good morning :)
<lukehasnoname> er.. 12:18
<lukehasnoname> haha
<pitti> Good morning
<StevenK> Morning pitti
<StevenK> pitti: I killed pnetc to go along with your pnet/pnet-assemblies death.
<pitti> cjwatson: 176994> indeed, closed
<pitti> slangasek: sru-accept -s> nice, thanks
<pitti> StevenK: yay killing!
 * pitti sings the cruft-busters hymn
<pitti> StevenK: ah, http://people.ubuntu.com/~ubuntu-archive/NBS/ has some more to kill; do you want to have the honour?
<StevenK> pitti: Yup.
<StevenK> pitti: Observe the 13K firefox-2 file ...
<StevenK> pitti: I guess libppl-c0 can go. Do we mind if gcc-snapshot is broken on ppc?
<pitti> StevenK: right, I forgot to kill mozilla-firefox-locales-all along with the firefox-2 source
<pitti> StevenK: don't tell doko, but I don't :)
<StevenK> And now that you've said his nick, you've drawn his attention to it :-P
<pitti> StevenK: and stuff like adblock-plus already DTRT with alternative dependencies
<pitti> ubufox, too
<pitti> so it can just go
<pitti> along with m-f-l-a
<StevenK> Right, I'll just kill it
<StevenK> pitti: m-f-l-a source and binaries should die?
<pitti> StevenK: yes; for f-3, translations are in the langpacks
 * StevenK hits up cocoplum
 * pitti holds on something while StevenK makes the earth shatter
<doko> pitti: libppl-c0 is obsolete. StevenK: bootstrap on sparc and powerpc is currently broken.
<StevenK> 2008-10-14 06:00:50 INFO    337 packages successfully removed.
<StevenK> *DAMN*
<pitti> *tremble*
<ajmitch> that looks promising
<ajmitch> great way to clean up bugs :)
<viviersf> silly question ? is openofice 3 going into the release ?
<StevenK> pitti: NBS flushed
 * StevenK kicks octave-gpc a little more
<TheMuso> doko: pulseaudio 0.9.13 is in my PA if you are interested.
<Hobbsee> ajmitch: the question is...*did* he automatically mark all the bugs as wontfix, with all those removals?
<doko> TheMuso: ok, thanks. but probably won't show up in intrepid ...
<TheMuso> doko: No it won't.
<TheMuso> jaunty most likely
<doko> TheMuso: openjdk does need it (as an option) from now on
<TheMuso> doko: Thats actually really nice to hear.
<StevenK> doko: So, TheMuso and I poked at libtunepimp more. Going back version of binutils didn't help either
<Burgundavia> given how many distros seem to release about this time, I am kind of shocked that so many major projects are busy stuffing out major releases right now
<Mithrandir> Burgundavia: shouldn't you be surprised the other way around?  The distros should align themselves around releases of their components.
<Burgundavia> Mithrandir: no, they are pushing out releases that are missing distros cutoff dates
<Mithrandir> Burgundavia: depending on the project, they don't care.  There's always another distro release in six months' time.
<Burgundavia> true
<TheMuso> Well pulseaudio is a rather fast moving target, so its released when Lennart thinks a new release is worthwhile. 0.9.12 could have probably made it in, however there were some regressions between it and 0.9,10.
<TheMuso> Regressions that I think were too much of a problem, since they took away some of pulse's advantages.
<TheMuso> Mithrandir: I'd agree with that.
<Mithrandir> so getting them into lenny and RHEL is more important than getting them into 8.10.
<Mithrandir> (simply because they release more seldomly)
<StevenK> checking for Octave version... 3.0.1
<StevenK> configure: error: version of octave must be 2.1.57 or later
<StevenK> octave-gpc, I'm going to get you.
<pitti> slangasek: ah, I fixed s/sys.argv/args/ in sru-accept, it actually works now
<mdke> slangasek: I was thinking about something like exporting the translations on Sunday 19 with the translations to be uploaded by Thursday 23
<pitti> StevenK: libtunepimp builds fine locally now; cross fingers that it works on ppc now, too :)
<tkamppeter> pitti, any chance t fix bug #271288 for intrepid? It is possible that manufacturers also ship PPDs with strange licenses.
<ubottu> Launchpad bug 271288 in jockey "Require the user to confirm the license before downloading a driver if it is non-free or if it has patent issues" [Medium,In progress] https://launchpad.net/bugs/271288
<pitti> tkamppeter: shouldn't be too hard; I'll target it for intrepid, yes
<pitti> tkamppeter: I need to work on jockey anyway, for only offering packaged PPD files by default
<pitti> tkamppeter: right now, e. g. splix is broken: it adds the openprinting.org archive, but since that has a smaller version, it installs the ubuntu version anyway (which is probably just fine and working)
<pitti> tkamppeter: so I think we should back this out and only install PPD packages for now, until the namespacing is solved (and packages get signed as well, perhaps)
<pitti> tkamppeter: what's your feeling about that?
<pitti> StevenK: \o/ worked
<tkamppeter> pitti, can we do the following: We start only with PPDs, and as soon as there is a naming spec (or better automatizaton in the macro set) we do an SRU of Jockey switching over to binary download support (is probably only a small switch in a config file).
<StevenK> pitti: On PPC?
<StevenK> pitti: I see that. Woot!
<tkamppeter> pitti, will you also fix bug #269454
<ubottu> Launchpad bug 269454 in jockey "show printer driver support contacts, status, and unsupported color mode warning" [Undecided,Confirmed] https://launchpad.net/bugs/269454
<pitti> tkamppeter: it's a small switch (although not in a config file, but it's fine)
<pitti> tkamppeter: if I still have time, yes
<pitti> tkamppeter: I have two RC bugs on my lists still, which will probably keep me busy today
<pitti> but there's still some time until the release
<tkamppeter> pitti, this bug is also very important, as this info is very important for the user to decide about the download.
<pitti> right
<persia> pitti, Brilliant!  Nice job.
<kwwii> pitti: what is the status with the logout stuff? I need to know because of the icons (the little green man is not the desired "look" but I want to make sure that if I replace it with the old red "power button" icon that it will not show up next to another copy of the same icon)
<persia> wgrant, Are you still looking for list-props testers?
<pitti> kwwii: we don't change it automatically, but on upgrade users get a notification with a "fix it up" button which replaces logout with new fusa and removes old fusa
<persia> I still have both Logout and Shutdown in the menu, despite having the new fusa.
<pitti> kwwii: so users see it after the first reboot, until they run the upgrade hook (or always if they don't want to get it changed)
<pitti> persia: well, it shouldn't be dropped from the menu surely?
<pitti> it's my standard way to call the suspend dialog...
<persia> pitti, Could be done, but it's tricky.  I suspect it only happens with the consolidated menu.
 * persia checks
<pitti> well, g-p-m offers it too, but it doesn't offer reboot/shutdown
<pitti> persia: what happens?
<persia> pitti, I suspect that the "Logout" and "Shutdown" entries only appear in the consolidated menu, rather then the default split menu.  I'm checking in a VM now.
<persia> No.  With the split menu, there's still both "Log Out" and "Shut Down" in the System menu.
<persia> And it's available from the fusa applet (this is today's liveCD)
<persia> (Or, rather, yesterday's : today's seems to have gotten stuck somewhere)
<persia> Anyway, the point of bringing this up was to encourage kwwii to still have two icons, for the two menu items.
<kwwii> pitti: hrm, that makes things kinda hard then...I guess I should not change the icon or it will confuse some people who upgraded
<kwwii> persia: exactly :-)
<persia> kwwii, Note that Logout just logs out now, and can't power off, so you might want something different than a power button anyway.
<kwwii> persia: yeah, I will probably have to come up with something new and amazingly different :-)
<persia> kwwii, Isn't that your superpower anyway?
<kwwii> persia: *exactly* (you are really on the ball today!)
<wgrant> persia: On obscure archs, yes.
<persia> wgrant, Ah.  Does lpia count as obscure?
<wgrant> persia: I doubt it... it's too i386.
<persia> Well, closer to i686, but yeah.  I don't think I can help then.  Sorry.
<pitti> re
<pitti> persia: what do you mean with "Still logout and shutdown" in the menu? that's the way it's supposed to be?
<pitti> persia: right, but we can't assume that the user has the fusa applet
<pitti> I have an upgraded system since, erm, something like woody, and I don't have either applet
<pitti> well, for the purposes of GNOME it was really warty, I didn't use GNOME before
<persia> pitti, Precisely, so we need visually distinct icons for each function.
<persia> And yes, on my continuously upgraded system, I don't have them either (although I don't use that system much anymore : the hardware is aging).
<pitti> persia: hm, on my system all functions have a different icon
<pitti> not on your's?
<persia> pitti, On my system, there are all different icons also.  kwwii wanted to replace the little green man because it didn't match the current look.
<persia> He asked you what the plan was for logout, and whether it would go away.  I tried to be helpful, and apparently introduced confusion.  My apologies.
 * liw wishes people would stop messing with the logout/shutdown/etc UI
<liw> I don't particularly mind what it is like, as long as I don't have keep hunting for it...
<Mithrandir> liw: what do you mean, messing with the logout/shutdown UI?  pkill -u $USER and shutdown -h now wfm. :-P
<persia> Well, some of the various variations have been unfortunate.  The current one provides way too many ways to do things, but at least it works.
<persia> Mithrandir, You do realise that shutdown is just a legacy wrapper now, and may well go away in the future, right?
<liw> persia, I've been hearing that for a decade...
<persia> liw, Really?  On my system it didn't become a legacy wrapper until just a couple years ago.
<persia> (or not that I noticed).  Now it's explicitly provided by a transitional package (upstart-compat-sysv)
<persia> Hmm.  Might have only been a year even.  edgy/feistyish I think.
<liw> persia, I suspect people have been going back and forth between the various commands for a long time now
<persia> liw, Indeed.  I suspect it will be a while before # kill -9 1 breaks, but even that will probably go someday.
<Mithrandir> persia: no, given that it's never said anything about being a legacy wrapper, how would I know?
<persia> Mithrandir, I guess you'd have to read the changelogs.
<Mithrandir> persia: surprise, people don't.
<persia> (and as liw points out, fashions may change again)
<persia> Mithrandir, I'm not that surprised.  I think it's irresponsible not to read changelogs when installing software, but I'm in the minority.
<Mithrandir> persia: my upstart changelog doesn't say anything about shutdown being deprecated.
<persia> Mithrandir, Ah.  Hmm.  Maybe I'm mistaken.
<Mithrandir> the closest would be:
<Mithrandir>     - some upstart-specific options to shutdown and reboot dropped, as
<Mithrandir>       these are considered SysV-compat tools.
<Mithrandir> that they're a compatibility layer does not mean they'll go away.
<Company> dholbach++
<dholbach> Company: hm?
<Company> swfdec 0.8 finally in intrepid
<dholbach> Company: I merely sponsored the upload - it wasn't my work :)
<dholbach> but I'm glad you're happy
<seb128> dholbach: did didrocks rebase the update on 0.7?
<dholbach> seb128: yes
<seb128> dholbach: did you sponsor swfdec-gnome too?
<dholbach> seb128: no, I didn't know what the verdict on swfdec-mozilla was
<emgent`> hello
<seb128> dholbach: swfdec-mozilla is yet an another one no?
<emgent`> http://www.securityfocus.com/bid/30794/discuss
<emgent`> hahah red hat.
<seb128> Company: do you really need to version those this way btw? are there really users running several versions?
<dholbach> seb128: yes, but still I wanted to keep the options open until I knew what the plan forward is
<didrocks> seb128: yes, I did
<Company> seb128: i was told it's the best way to handle API instability
<didrocks> dholbach: I am working on swfdec-mozilla
<dholbach> didrocks: ROCK
<didrocks> dholbach: :)
<dholbach> emgent`: I'm not sure that gloating is appropriate
<directhex> ding dong, this is your early morning merge request. https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
<seb128> Company: usually the best way to handle instability is to change the soname
<emgent`> dholbach: I'm laughing because redhat long ago said that their archives were damaged but there was no danger to users.
<seb128> dholbach: ok, swfdec-gnome is technically GNOME so having 2.24 would be nice ;-)
<seb128> dholbach: thanks for the sponsoring
<pitti> me, seems I have a real mind blocker here; "sudo pbuilder --create --basetgz /var/cache/pbuilder/hardy.tar.gz --distribution hardy --mirror http://de.archive.ubuntu.com/ubuntu" says "E: File /var/cache/pbuilder/hardy.tar.gz does not exist"; what am I doing wrong her?
<pitti> of course it does not exist, I want to create it, you silly pbuilder
<liw> pitti, touch the file, pbuilder is happy with that (I don't know if that's considered to be a bug)
<dholbach> emgent`: still - I'm not happy about it -- being glad because it didn't happen to us or to you is very different from laughing about mistakes and problems from somebody else
<pitti> hm, it's by far not the first pbuilder I created, and I never had to do that
<pitti> liw: hm, that helped; thanks
<dholbach> emgent`: when we ran into the openssl debacle I didn't see  "haha, look at those Ubuntu/Debian people" - it's just not a response I'd expect from an Ubuntu developer
<Company> seb128: i don't really care how i do it (if by soname or libname or whatever), but for me this approach works well, is gnomey and i know what i'm doing
 * pitti utters another curse about pbuilder defaulting to cdebootstrap, but is happy now
<Company> seb128: plus, every distro seemed happy with it
<wgrant> dholbach: While I agree that gloating isn't good, lots of people did you "haha, look at those Ubuntu/Debian people".
<directhex> dholbach, i saw plenty of "haha, look at those Ubuntu/Debian people"
<wgrant> s/you/go/
<dholbach> wgrant, directhex: Redhat developers?
<wgrant> And then people gave Red Hat and Fedora hell for their issue.
<emgent`> dholbach: yes it`s seems correct, but i dont like redhat devel aggressivity. anyway sorry if you still has problems
<seb128> Company: swfdec0.8 is sitting in debian NEW for some weeks now and that's the reason we can't sync it in ubuntu and it's waiting there too
<wgrant> dholbach: True. Perhaps not.
<dholbach> I'm not talking about uninformed users or trolls
<seb128> Company: that requires NEWing new sources, migrating bugs, etc every time
<seb128> Company: I would not say distro are happy about it, that's just lot of extra work for no real win, no other GNOME software does that
<Company> seb128: the debian stuff is not really my problem, but debian's (or yours)
<Company> seb128: yeah, the other gnome software considers itself stable
<wgrant> Wait, the upstream source name has the version number in the name? I thought it was just Debian people being strange.
<seb128> Company: what is wrong with changing soname when you break abi?
<seb128> Company: and that's not really true, having distros shipping your software is somewhat your problem too
<Company> seb128: nothing is wrong with it, it's just not how we've done it before
<seb128> Company: we could just decide that if you decide you don't care about distro we don't care about your software, which is no-win situation
<Company> seb128: btw, there's some debianites running swfdec stable and unstable at the same time
<Company> but other than that, noone runs 2 libswfdecs
<seb128> Company: people doing that probably know what configure option to use to install in a different directory
<pitti> with that argument we could version every package...
<Company> although i could imagine that happening when amsn etc start using it for winks (they wanted to)
<Company> seb128: debian ships swfdec-mozilla-unstable
<Company> (orsomething like that)
<emgent`> gh
<seb128> Company: which probably conflict with the normal version, mozilla doesn't let you choice the plugin to use at runtime anyway so you need to uninstall the one you don't want by some way
<Company> seb128: yeah, i guess so
<seb128> Company: anyway no big deal we got 0
<seb128> .0.8
<seb128> Company: I'm just letting you know that the versionning is really annoying for some distros
<Company> seb128: but as i said: currently it doesn't matter for me how it's done, whatever fits distros best
<Company> seb128: yeah, ubuntu is special there - but every distro is special somewhere ;)
<seb128> the usually way to deal with abi breakage is soname updates
<directhex> osc-bigmac:/home/jms# apt-cache search swfdec unstable
<directhex> osc-bigmac:/home/jms#
<Company> yeah, no swfdec-mozilla-unstable in debian
<Company> good thing, i wasn't convinced of the idea anyway ;)
<directhex> seems broken in debian anyway
<directhex> most arches have 0.6, amd64 has an incomplete uninstallable 0.8
<Company> yeah
<Company> hanging in the NEW queue
<Company> lenny freeze issues people tell me
<cjwatson> TheMuso: *user-params* causes update-grub to be called a second time? are you sure?
<cjwatson> TheMuso: oh, mediated by grub-installer I suppose
<StevenK> pitti: So, octave-gpc is busticated, and I can't make it work with octave3.0
<dholbach> somehow accents on my keyboard don't work anymore - ^e for example doesn't give me e with circumflexe
<dholbach> anybody had the same issue on intrepid?
<dholbach> I just moved away my xorg.conf and configured gnome to use "german nodeadkeys" which worked in the past
<RAOF> dholbach: Ãª seems to work for me, at least as long as you mean <compose>^e
<pitti> dholbach: but nodeadkeys is exactly that, it doesn't wait for composition
<dholbach> RAOF: I didn't have to use the compose key before
<pitti> dholbach: try with dead keys?
<pitti> dholbach: so it should give you ^e with nodeadkeys, i. e. the ^ appears immediately
<dholbach> yes, it appears immediately in both cases
<pitti> sounds like 'nodeadkeys' is working as it should then
<dholbach> ok... maybe I should have asked differently ... how do I get the "old behaviour" back? ie: pressing ^ then e gives me Ãª ?
<Keybuk> compose doesn't work for me today?
<dholbach> same for ~ ` and '
<Keybuk> compose-e-^ just beeps at me
<RAOF> Keybuk: How about compose-^-e?
<pochu> dholbach: I have the asme issue... but even pressing "^" twice, it doesn't print ^ at all
<pitti> dholbach: Deutschland/Germany works
<Keybuk> RAOF: that works
<pitti> dholbach: i. e. don't choose the deadkeys
<RAOF> Is it meant to work the other way 'round?
<Keybuk> RAOF: it always has for me
<dholbach> pitti: it doesn't work for me - in all cases I always get first ' ` ^ ~, then the other character
<dholbach> whatever I pick in the keyboard configuration thingie
<pitti> I tested it here, works fine
<pitti> dholbach: maybe you have "separate group for each window" or something such?
<dholbach> Ã© Ã¨ Ãª áº½ Ã¸ Ã¯
<dholbach> ok, I'm happy again
<dholbach> thanks pitti - that was it
<dholbach> although I can't remember having checked that box
<Keybuk> ooh, you can do âdouble quotesâ with compose :)
<Keybuk> I didn't know that!
<dholbach> seb128: do you have an opinion about bug 280806?
<ubottu> Launchpad bug 280806 in tomboy "Please sponsor tomboy 0.12.1 (main) into Intrepid" [Wishlist,New] https://launchpad.net/bugs/280806
<Keybuk> though, inconsistency of the week: compose = C gives you â¬  (shouldn't that be - e ?);  compose - L gives you Â£;  but compose | S doesn't give you $ :p
<StevenK> asac_: So, why does gnash ship a .desktop file?
<ogra> besauce it can standalone ?
<asac_> StevenK: because the viewer is ment to be a viewer. we might hide it from menu
<ogra> *because
<asac_> but we need the mime-type mapping i guess
<ogra> *run ...
<StevenK> asac_: Sure, but it just exec's gnash which gives a usage message
 * ogra gets more coffee
<asac_> StevenK: which is a bug in the gnash viewer from my point
<asac_> StevenK: the mime-type associated thing should work though
<asac_> e.g. right click on a swf file... select gnash -> done
<StevenK> asac_: Well, the reason I bring it up is it appears in Kourou, the MID launcher
 * StevenK tries to sort out the rubygems mess
<asac_> StevenK: yes. imo we should consider to not show it in menu
<asac_> i think that should be fairly easy to do
<StevenK> asac_: NoDisplay=true
<asac_> StevenK: so is mobile team caring for gnash?
<StevenK> asac_: No, we just seed it because we like it.
<asac_> StevenK: NoDisplay -> will that also remove the mime-type suggestion?
<asac_> or only in the launcher?
<StevenK> The mime-type suggestions use .desktop files?
<persia> MIME types are registered in .desktop files, but the format for a MIME Entry should be different than an application launcher.
<james_w> do we freeze again on Thursday?
<persia> Specifically, the Type key shouldn't be an application
<StevenK> And the gnash .desktop is a [Desktop Entry]
<asac_> persia: err. its an application
<persia> RIght, but should be [MIME Type] if it's just MIME registration
<asac_> persia: it just doesnt start without argument ;)
<ogra> james_w, the schedule doesnt say so
<james_w> ogra: yeah, that's what is confusing me
<persia> asac, If there's not a way to start with sensible default arguments, it oughtn't be registered in the menu.
<asac_> hmm the mimetype isnt even in there
<asac_> persia: yes. but thats NoDisplay?
<ogra> i think we'll likely freeze for CD builds but monday should suffice
<persia> asac, No, that's not having a menu entry .desktop file at all.
<ogra> there seems to be no official RC freeze though
<persia> asac, I think you want a .desktop file to register your MIME Type, but I think you don't want one that would be a menu entry : just a context entry for MIME-aware file browsers.
<asac_> persia: not sure. at some point i want it to be an application. but for now i just want the mime mapping yes.
<persia> asac, Something that launches from a menu directly, without any arguments?  In that case, yes, you'd want a menu entry.  In this case, I think you want something smaller.  I'm searching for a good example now.
<asac_> persia: no for now gnash only starts with the content file as an argument
<davmor2> mvo: just finished an install of Ubuntu for smoke testing would your compiz fix be on this mornings iso or is it in repo?
<asac_> (which is the point why the complained about having it in menu is right)
<persia> Right, so it needs the other kind of .desktop file
<asac_> let me check. i think i have a bug
<asac_> persia: http://launchpadlibrarian.net/8613124/gnash.desktop thats the current suggestion
<StevenK> pitti: Want to cast your eyes on http://people.ubuntu.com/~ubuntu-archive/NBS/libltdl3 ?
<asac_> persia: what opther changes?
<asac_> Type=MimeType?
<StevenK> pitti: I think we're close enough to kill it
<pitti> StevenK: I agree
<asac_> anything else? maybe i need to put it in a different location? e.g. not /usr/share/applications
<persia> No, /usr/share/applications is correct.
<asac_> pitti: could you also remove firefox-2 and the mozilla-firefox-locale-all package? i will include a transition package for firefox-2 in the next upload
<StevenK> asac_: I've already killed them both
<pitti> asac_: IIRC StevenK already did
<asac_> StevenK: brave
<StevenK> asac_: mozilla-firefox-locale-all was 337 packages!
<asac_> there should be stilla bunch of extensions dangling (like 2 or three never supported firefox 3)
<StevenK> asac: If you get a list, make a bug and subscribe -archive
<asac> but i have to wait for jazzva who will hopefully return tomorrow or so from holiday
<asac> StevenK: yeah. jazzva has prepared that list, but i forgot where he posted it
<StevenK> ogra: Can you stop ubuntu-mobile needing gimp-python, and I'll fix the other thing
<seb128> dholbach: just don't do the update as the recent comment suggests on the bug
<ogra> StevenK, the seeds are fixed already
<dholbach> seb128: ok, I'll unsubscribe the sponsors
 * StevenK resists the urge to set the comment to "Finally NBS this damn thing out"
<seb128> dholbach: danke
<dholbach> de rien
<StevenK> pitti: libltdl3 killed
<pitti> yay!
<james_w> StevenK: I've got a fix for nufw, just waiting for Michael to check he hasn't got one waiting for sponsorship. Is that the last of the gnutls transition?
<cjwatson> NBS> I don't suppose anyone is planning to deal with the enormous component-mismatches list? :)
<persia> asac, I'm not finding the docs I want right now.  For now, just use NoDisplay=true (as is used by vinagre-file.desktop vs. vinagre.desktop).
<asac> persia: http://paste.ubuntu.com/57361/
<pitti> cjwatson: that looks like a full-week job of all archive admins
<asac> persia: hmm
<asac> so no Type=MimeType?
<persia> asac, Not according to the spec I just read.  I was sure I saw it somewhere.
 * persia checks the dh_desktop call to see if that provides a hint
<persia> asac, No, that just checks for the MimeType= key.
<seb128> persia: what are you looking for exactly?
<asac> seb128: applications that shouldnt be in the menu, but are helper for mime-types
<asac> seb128: are they supposed to have a Type!=Application ?
<asac> in .desktop
<persia> seb128, The way to create a .desktop file that registers a MIME Type that can be actioned, but doesn't register a menu entry.  Is it just the absence of Categories?
<persia> asac, No, use Type=Application.  That's mandated for that sort of thing in the spec.
<seb128> persia: the way it's done usually is just by using NoDisplay=true
<asac> persia: StevenK: please check if you are happy with this ;) http://paste.ubuntu.com/57366/
<persia> seb128, I thought I remembered seeing a guide on either the Debian wiki or a Debian mailing list with some other advice, but that's what I'm seeing in my current .desktop file selection.
<StevenK> asac: Looks great to me
<seb128> persia: dunno about debian but GNOME uses NoDisplay=true in a consistant way
<persia> asac, s#/usr/bin/gnash#gnash %U#
<persia> seb128, RIght.
<persia> asac, also, s#/usr/share/pixmaps/gnash.xpm#gnash#
<persia> asac, lastly, /^Enco*/d
<asac> k
<asac> persia: the final artwork -> http://paste.ubuntu.com/57371/
<ogra> Koon, heh, your fix for dhcpd looks great apart from the fact that you have  space in the shebang line :)
<ogra> *a space
<persia> asac, Looks great to me.
<Koon> ogra: oops
<persia> ogra, The spec calls for a space ...
<ogra> Koon, fine to upload if you prepare a debdiff
<ogra> persia, ?
<persia> "#! ${interpreter}"
 * ogra wonders what spec that might be 
<persia> Single Unix Specification
<Koon> indeed, the space comes from the copy of the openssh-server one.
<pitti> cjwatson: for bug 256131, we need to make sure that xml-core is at least at 0.11ubuntu1 before even unpacking rarian-compat (old/new prerm script fail to "upgrade" otherwise); this would work with rarian-compat Pre-Depends: xml-core (>= 0.11ubuntu1); do you see an issue with that? should I use something less intrusive than pre-depends?
<ubottu> Launchpad bug 256131 in rarian "failed to upgrade : "update-xmlcatalog: error: entity already registered"" [High,In progress] https://launchpad.net/bugs/256131
<persia> Most shells will accept the absence of the space, but the space is technically correct
<asac> do we still need dhcpd?
<asac> at least NM doesnt use it anymore
<pitti> asac: I don't think so, n-m 0.6 was teh only user
<ogra> persia, wow, i didnt know .... i always thought it fails to execute with a space :)
<pitti> woudl be nice to remove it on upgrades, though
<StevenK> pitti: So, I have 7 uploads to clean up this libgems-ruby1.8 or rubygems -> rubygems1.8 mess. Will you hate me if I upload them without test building?
<ogra> Koon, fine then
<persia> ogra, heh.  No. :)
<pitti> StevenK: no, buildds are free ATM, it doesn't cause congestion
<StevenK> pitti: Six of them now have Ubuntu changes that they didn't before :-(
<asac> pitti: i guess we can remove it then from CD/main? or has that happened?
<pitti> asac: that too (shouldn't even be on current CDs), but I meant on upgrade
<pitti> asac: i. e. new network-manager coudl conflicts:/replaces: dhcdbd perhaps
<asac> pitti: which package should take care of that?
<asac> ok
<pitti> I'm not sure
<pitti> in theory, any package in ubuntu-desktop could
<asac> update-manager ? ;)
<pitti> well, sure, but apt-get dist-upgrade compatible solutions are always nice :)
<pitti> asac: hm, hang on
<mvo> asac: hm?
<pitti> mvo: if dhcdbd gets demoted to universe, u-m will clean it up, right? but what if the package doesn't exist at all any more?
<mvo> pitti: if it gets removed from the archive it gets cleaned up, if it moves to universe the user will be warned about it
<cjwatson> pitti: I *think* that's OK but could you raise it on ubuntu-devel@ ?
<pitti> cjwatson: ok
<asac> yeah. but making NM conflict it isnt nice either
<cjwatson> new Pre-Depends should be discussed there really
<StevenK> pitti: I'm tempted to bin libhdf5-serial-1.6.5-0 and libopenvrml5c2a anyway. They're both broken, and I can't fix them.
<StevenK> pitti: Er. Their rdepends are both broken, I mean
<cjwatson> pitti: dhcdbd> my take is that "needs to be removed" should be handled by Conflicts and "would be nice to remove" should be handled by update-manager
<asac> i think its the latter
<pitti> I agree
<asac> i dont see a reason why people cant have NM + dhcdbd installed at the same time
<pitti> but mvo just confirmed that it gets cleaned up,so if we remove the package, all shuold be well
<pitti> asac: no, it's just cruft; shouldn't break
<pitti> ok, I'll remove dhcdbd then
<persia> package removal is usually better, unless there's a lack of good alternatives.  We have several other DHCP clients and servers.
<asac> pitti: remove completely? or demote/unseed?
<pitti> asac: I'd just remove it; nobody is going to look after it, I suppose
<pitti> and it has empty checkrdepends
<pitti> asac: do you want to keep it?
<asac> hmm ... deosnt that come from debian?
<pitti> yes, it does
<ogra> StevenK, do you want me to do the -meta update as well ? or do you have a new meta change pending anyway?
<ogra> (gimp-python)
<StevenK> ogra: I don't, so go ahead
<asac> pitti: personallyi dont want it. just wonder whats our policy to decide whether we want a debian package in universe or not
<ogra> oki
<persia> Historically, we've wanted everything from Debian in universe, but old packages with clear replacements don't tend to get a lot of effort by MOTU, so it's likely to just bitrot unless it's actively maintained in Debian.
<pitti> removed and blacklisted
<pitti> if anyone is missing it, he can ask for it
<asac> yeah ;)
 * StevenK is plotting uploading gimp-plugin-registry to stop needing gimp-python and python
<persia> StevenK, Is there any chance that there will be python bindings for gimp in intrepid?  Also, don't a few other things depend on python?
<StevenK> persia: I've not investigated what happened to the Python bindings
 * persia looks at Debian
<persia> StevenK, There's at least the gimp-gnomevfs fix we want from Debian.
<StevenK> persia: gimp 2.6.1-1 is in experimental, and we have 2.6.1-1ubuntu2 ?
<persia> Ah.  I missed the version numbers somehow :/
<StevenK> persia: Who do I hit up for cra^Wbackports?
<ogra> silly firefox
<persia> StevenK, Looks like the python bindings are in the "gimp" binary package now.  I suspect ari will eventually split them out, but they aren't meaningful in a package context right now.
<ogra> your browser needs to be restarted .... so i reboot the system .... the first thing coming up when i start the browser after a reboot: your browser has been updated and needs to be restarted :P
<persia> For backports, I'd recommend jdong or ScottK, but NCommander has been increasingly active there as well.
<StevenK> persia: So gimp-python just gets NBS'd out. Sweet.
<persia> StevenK, As far as I can tell.  I'm not a gimp-python user, and haven't verified that the python-support hooks are doing the right thing, but that shouldn't affect the old binary package (which wouldn't work anyway due to API changes)
<Treenaks> ogra: that's nothing, try 'man gzip'
<ogra> heh
<persia> Didn't there used to be a manpage for gzip?
<persia> (info gzip still works)
<Treenaks> persia: https://bugs.edge.launchpad.net/ubuntu/+source/gzip/+bug/281825
<ubottu> Launchpad bug 281825 in gzip "gzip, gunzip and zgrep manpages are missing" [Undecided,Confirmed]
<james_w> NCommander: hi, are you working on nufw? I have a candidate fix here, do you mind if I upload?
<StevenK> james_w: If I didn't answer your question, it's the last thing we fix for libgnutls13.
<persia> james_w, There's a trivial patch from Dave Love that would be good to merge with that if you don't mind (check the other nufw bug)
<james_w> persia: it's fixed already
<persia> Oh, cool.
<james_w> as is the bug
<pitti> BenC: btw, thanks for getting uvesafb fixed up; usplash now works again even on my external monitor (on dock)
<pitti> BenC: do we still actually need v86d in main/anywhere? or can it go back to universe?
<pitti> BenC: (it currently wants to go to universe since nothing is depending on it)
<pitti> how do I tell git "show me the diff of commit 1234"? "git diff 1234" is something like bzr diff -r 1234, but I want bzr diff -c 1234
<pitti> and git diff --help is utterly nonhelpful for that
<broonie> pitti: git show
<BenC> pitti: uh, I did nothing to fix it
<jcristau> git show 1234
<TheMuso> cjwatson: Yes it is run by grub-installer. The difference which makes things take a different logic path is that the user_params variable = quiet when using netboot, but doesn't contain anything in a normal CLI CD install. I used CLI mode in netboot also.
<pitti> broonie: ah, thanks
<BenC> pitti: git-diff-tree -p --pretty 1234
<pitti> TIMTOWTDI apparently :)
<cjwatson> TheMuso: ah, right. So how come it breaks when update-grub is run again?
 * ogra tries to pronounce what pitti wrote there ...
<TheMuso> cjwatson: I don't know. That requires looking in update-grub, and I am not sure if its possible to get output of the execution path like it is with sh.
<TheMuso> because afaicr update-grub is perl.
<pitti> ogra: "there is more than one way to do it", the Perl mantra
<ogra> ah :)
<StevenK> ogra: Pronounced "Tim-toe-de"
<pitti> tim-towdee or so
<directhex> jms@osc-bigmac:~$ head -1 `which update-grub`
<directhex> #!/bin/bash
<directhex> FYI.
<cjwatson> what directhex said :)
<TheMuso> oh ok. I just remember seeing something to do with perl in the syslog. Will dig again tomorrow morning.
<directhex> see, i'm full of useful info. like a really easy way to close a couple of intrepid CVEs!
<StevenK> What the?! jpoker failed on i386?
<StevenK> And took 41 minutes. Wonderful
<StevenK> gem install --include-dependencies --no-rdoc --no-ri --install-dir gems tiddlywiki_cp || \
<StevenK> 	gem install --include-dependencies --no-rdoc --no-ri --install-dir gems tiddlywiki_cp
<StevenK> Oh, you *have* to be kidding.
<ogra> fun
<Mithrandir> can we replace gem with a very small shell script?
<StevenK> IE: #!/bin/sh\nexit 0\n ?
<StevenK> Why not just symlink it to /bin/true? :-)
<Mithrandir> StevenK: because /bin/true doesn't output "No, you fool" when you run it?
<StevenK> Mithrandir: I think it needs to face-stab people when they run it.
<StevenK> That'd fix those pesky rails developers, too
<Treenaks> I've attached a patch to debian/rules to the gzip bug (281825) which fixes it
<Treenaks> at least, for me
<lool> at this point of the cycle, I would be more confortable if someone could confirm the fix in #283200
<lool> I couldn't find an already reported bug, which kind of surprized me
<Koon> ogra: please see https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/280123/comments/3
<ubottu> Launchpad bug 280123 in dhcp3 "dhcp3-server needs if-up.d/if-down.d scripts for better network-manager compatibility" [Undecided,New]
<Koon> lool: bug confirmed, testing te fix right now
<lool> Koon: I pushed the package to my ppa if you like
<lool> Koon: it's built
<Koon> lool: the patch fixes it for me
<lool> Koon: thanks a lot for confirming, will push to intrepid then
<Koon> lool: haven't tested from your PPA though, I patched rc directly
<lool> Koon: Ok, thanks; I pushed to intrepid now
<BenC> cjwatson: new lrm that created nic-restricted-{modules,firmware} is being uploaded
<BenC> cjwatson: it includes ipw2[12]00 and iwl{3945,4965,5000} firmware
<cjwatson> BenC: is there a non-restricted nic-firmware these days?
<cjwatson> BenC: what about scsi-firmware?
<BenC> cjwatson: there used to be a restricted one from lrm, and since I'm creating this from lrm, I figured I would be consistent
<cjwatson> BenC: but is there nic-firmware *now*?
<BenC> cjwatson: no
<cjwatson> BenC: many devices certainly used to need scsi-firmware. Does that still exist?
<BenC> cjwatson: It doesn't...let me check what we have
<directhex> ding dong, this is your early afternoon merge request. complete with security vulnerability healing powers. https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
<ubottu> Launchpad bug 282952 in mono "Please merge mono 1.9.1+dfsg-4 from Debian Unstable" [Undecided,Confirmed]
<BenC> cjwatson: I guess aic94xx and qla2x00 should be in one
<cjwatson> BenC: have you given any consideration to the upgrade path for users of those modules who did not have l-r-m installed yet?
<elmo> (like, say, servers? :-P)
<cjwatson> elmo: do you use do-release-upgrade on servers?
<elmo> cjwatson: yep
<maswan> as a random server admin, so do I
<cjwatson> I think the main/restricted split makes it somewhat inevitable that modules will occasionally move the wrong way, so I'm OK with release-noting this and having do-release-upgrade prompt if necessary; but this needs to be implemented
<BenC> cjwatson: Well, if they don't have lrm-common installed, then likely they removed it themselves
<cjwatson> if we hand-wave until after release we'll just get bad press about it
<cjwatson> BenC: yes, they did. that doesn't mean we get to screw them over
<mvo> if do-release-upgrade/update-manager should deal with it, I would like to know as early as possible .)
<elmo> JOOI, why is this particular firmware being punted to restricted now?
<cjwatson> elmo: I have no idea, and have argued against it
<BenC> mvo: consider yourself in the know :)
<BenC> elmo: because we have no place else to move it?
<cjwatson> BenC: it's permitted in main
<elmo> BenC: err, what's wrong with leaving it in main?
<cjwatson> BenC: the licence policy is quite explicit that we'll consider firmware on a case-by-case basis
<BenC> elmo: it was in lum, and lum is gone
<BenC> it's not main...it's that I don't want to add it to the linux source
<cjwatson> BenC: put it in linux, or create a new linux-firmware source package in main, or *something*
<cjwatson> (I think I suggested linux-firmware before)
<elmo> cjwatson++
<BenC> that still doesn't help the upgrade path
 * liw suggests linux-firmwarez
<cjwatson> sure it does, if linux-image-* depends on the firmware
<cjwatson> which would be totally reasonable
<elmo> BenC: sure it does, just make stuff depend on it?
 * BenC notes there are underlying issues in making linux-image depend things that gnu would consider non-free
<BenC> not technical ones, but "I'm going to hear about it later" ones
<cjwatson> BenC: this isn't new; the files were already there
<cjwatson> and Ubuntu is very clear on our position here
<BenC> cjwatson: So are you prepared to NEW and MIR this new package for me?
<BenC> going to require a new kernel upload and everything
<cjwatson> if you want to move them in jaunty, I'd be OK with that, but I think it's bad to have to add update-manager UI for this two weeks before release
<cjwatson> we should have planned the upgrade path way in advance
<BenC> actually, I'll make linux-foo meta depend on it
<cjwatson> BenC: certainly
<BenC> will be easier
<BenC> cjwatson: either way, this is a good bit to do 2 weeks before release :)
<cjwatson> linux-meta> OK in the short term but I do think the actual kernel binaries should depend on it
 * Hobbsee notes users won't be happy if ipw3945 has been replaced by another "nonfree" driver, which it will be judged to be if it appears in l-r-m - particularly as a lot of users have had trouble with it (such as no LED, for all of hardy).
<cjwatson> but I suppose that doesn't matter so much
<BenC> Hobbsee: umm, way off on the discussion
<cjwatson> BenC: we did bring it up last week when it would have been three weeks before release ;-)
<cjwatson> before that, at least I wasn't aware of the problem
<Hobbsee> BenC: oh, right, so this is "created based off l-r-m, but would be called something completely different, and also not restricted".  I agree, i'm kinda late.
<BenC> cjwatson: Ok, linux-firmware == new package, created nic-firmware/scsi-firmware udeb's, lrm will have firmware removed but still create nic-restricted-modules, linux-meta updated to have linux-image-foo depend on linux-firmware
<BenC> s/created/creates/
<BenC> cjwatson: sound complete?
<pitti> BenC: we don't need to make a lot of MIR fuss about it; if that firmware is in hardy main, we can NEW it straight into intrrepid main
<pitti> we traditionally haven't done MIRs for package renames/splits (which is what this amounts to)
<BenC> pitti: ok
<ogra> tedg, !
<tedg> Good morning ogra
<ogra> great to see you :)
<ogra> IRC is a lot faster than discussing stuff on bugreports :)
<tedg> ogra: Heh, yeah.  I'll try to get those fixed.
<ogra> i think the two with patches are trivial to do, what do you think about the logout issue ?
<tedg> ogra: I don't think that's a big deal.  I'm curious how the command line gnome session works if there's no gnome-session though.
<ogra> there is a gnome-session
<ogra> Xsession spawns it
<tedg> ogra: Can you also try the GNOME Power Manager in my PPA?  It changes the power button behavior, it should use DBus and then fall back to XSMP.
<ogra> well, Xsession spawns x-session-manager, which is an alternative linking to gnome-session
<cjwatson> BenC: I think that makes sense
<tedg> ogra: But the gnome session is running on the server?  So one can't do DBus to gnome-session?
<ogra> right
<cjwatson> BenC: thanks
<ogra> until dbus gets a proper TCP protocol for remote connections
<ogra> which we then could tunnel through the ssh tunnel
<ogra> but even if that was there now, that would mean massive infrastructural changes to the way ltsp/ldm work atm
<ogra> with intrepid we at least have a dbus installed in the client env, i'm happy to discuss session dbusification for jaunty, but in intrepid that wont be possible yet
<seb128> ogra: how is your session working at all without dbus?
<seb128> ogra: gconf is using dbus to get started in intrepid for example
<ogra> it uses the servers system bus
<ogra> that works fine until you want hw related things
<seb128> gconf is not a system service
<ogra> for which we have ltspfs
<sebner> cjwatson: maybe you can tell me if the kernel team have plans with jaunty and ext4 or should I ask in #u-kernel
<ogra> seb128, well, it works
<ogra> seb128, and until now we refrained from dbus and hal installs on clients ... such devices usually have around or less than 64M ... every byte counts ...
<ogra> with Xorg forcing that my only chance to still <support such devices was compcache ...
<cjwatson> sebner: I don't know why I would know
<cjwatson> sebner: -> #ubuntu-kernel
<cjwatson> sebner: note that I am not a member of the Ubuntu kernel team
<sebner> cjwatson: ah kk, thx
<davmor2> mvo: Which compiz fix is meant to resolve the menu issue?
<mvo> davmor2: the issue in the apperance capplet? the libcompizconfig -0ubuntu2 and the compiz -0ubuntu3 uploads
<mvo> davmor2: I'm not 100% sure if they are enough though, but its definitely a step forward
<davmor2> mvo: yeah got them rebooted and checked the menu and it is still happening.  Sorry.
<mvo> davmor2: ok, thanks for the test. I will dig deeper
<davmor2> mvo: Np's I'll be smoke testing all week so if you find a fix just ping me :)
<tedg> ogra: Do you have a setup that you can look at the GPM update?  I wanted to ask for sponsorship on it this morning, but now I'm concerned it'll break LTSP.
<ogra> tedg, i have a vbox setup of ltsp, easy for testing
<tedg> ogra: Cool, can you attach a thumbs up/down to bug #252795?  Thanks.
<ubottu> Launchpad bug 252795 in fedora "pressing the "Power" button shows a logout dialog" [Unknown,In progress] https://launchpad.net/bugs/252795
<tedg> Heh, ubottu is reporting it as a bug in Fedora. ;)
<ogra> tedg, oh, thats hard
<BenC> cjwatson: Have you heard anything about the installer and disks with host-protected-area in intrepid?
<ogra> tedg, i have no clue how to emulate a powerbutton press in vbox :)
<ogra> tedg, but it wont affect ltsp at all, the session will never see the button event anyway
<tedg> ogra: Not in vbox, but in virt manager if you press the "shutdown" button it behaves like hitting the power button.
<tedg> ogra: Will GPM see the powerbutton?  It then calls the session manager.
<ogra> no
<cjwatson> BenC: I don't think so - why?
<ogra> the client HW is totally separated from the session ...
<tedg> ogra: Cool, then I'll assume it won't break LTSP :)
<ogra> right :)
<BenC> cjwatson: I've seen a report in lwn of the installer ignoring HPA when the kernel honors it (like it should) and it tries to use the whole disk when it should only use a partion
<BenC> cjwatson: note in hardy and prior, we ignored HPA and caught a lot of static from upstream because of it (was not the default in the kernel)
<tedg> ogra: Dave Richards presented at the GUI Hackfest.  They're doing a thin client implementation, not LTSP, but you might find some of the presentation interesting.  http://live.gnome.org/Boston2008/GUIHackfest/CityOfLargoPresentation
<ogra> tedg, as long as gpm still hides suspend and hibernate on ltsp clients all will be fine ... btw, the gnome logout from the system menu wors fine
<BenC> cjwatson: http://lwn.net/Articles/301862/  last paragraph
<alex-weej> can someone tell me why developers keep removing the "regression" tags i add to bugs
<alex-weej> and then adding "regression-potential"?
<alex-weej> james_w: i'm looking at you now :P
<james_w> tedg: hey, did you see my gpm patch?
<cjwatson> BenC: I'll look at it after this call but it seems deeply implausible
<james_w> alex-weej: because that's the documented tag to state that if we release with something it will be a regression.
<alex-weej> where is it documented?
<alex-weej> and what is "regression" for, in that case? after the "damage" is done?
<ogra> tedg, that looks like he essentially just resembled ltsp, though he uses XDM and XDMCP which i wouldnt ever do
<tedg> james_w: Not yet... but I'm still catching up on mail.  (I was in Boston until late last night)
<ogra> (you can actively take screenshots from the network traffic under XDMCP)
<james_w> tedg: no problem it's on the sponsors list, feel free to roll it up with any updates you are doing, but it's quite a serious bug for amd64 users
<tedg> ogra: Yeah, one of the interesting things that he did was set up an entire server for Evolution.  That way he could keep it under support contract and run more modern stuff on his other machines :)
<BenC> cjwatson: that's what I thought, since I suspect it would get its geometry from the kernel anyway
<ogra> i wonder why he didnt just take ltsp and did his session modifications on that
<BenC> cjwatson: if it's getting geometry directly from the drive and ignoring hpa, that would be odd
<ogra> looks like a lokt of wasted manpower :)
<ogra> ltsp would have given him 80% of that setup out of the box
<cjwatson> BenC: I'd be amazed if libparted did that
<ogra> the evo server is a cool idea though
<cjwatson> BenC: it doesn't explicitly shrink the disk to accommodate HPA, but I'm not entirely sure how it reliably could
<ogra> tedg, lol, and he has no answer for dbus either :) i guess i should contact him so we can work together on a dbus over TCP implementation ;)
<BenC> cjwatson: if it relied on the kernel geometry, it wouldn't have to do anything special
<tedg> ogra: Yeah, I think that he has a big Novell contract -- do they support LTSP?
<BenC> cjwatson: the block devices would simply map to the non-hpa portion of the drive
<cjwatson> BenC: it calls HDIO_GETGEO, I believe
<ogra> tedg, nope, they have a proprietary solution they push instead, but there is a ltsp frok called kiwi-ltsp in opensuse
<cjwatson> BenC: but if the partition layout is already outside the HPA then you can end up screwed; that's why the kernel ignored HPA
<ogra> *fork
<cjwatson> BenC: for reasons that were discussed with lkml at the time
<BenC> cjwatson: well, for the first time we have hpa honored by default...would be a simple module-init-tools addition to change that
<ogra> tedg, they have a closed system that sits on flashcards on the clients instead of using a diskless ltsp setup
<tedg> ogra: Hmm, I wonder if that's what they're using.  He did mention they have flash in all the thin clients.
<ogra> i guess so
<ogra> its quite annoying to administer compared to ltsp where you only have one chroot for all clients to boot from ...
<ogra> i.e. for security kernel updates you need to run around and update the flash
<cjwatson> BenC: it's not the first time we've done that. We did it in a previous cycle and it was a last-minute panic to back it out again.
<ogra> in ltsp thats one command
<cjwatson> BenC: are you *sure* this is a good idea?
<BenC> cjwatson: In the long run, it is the right thing to do
<cjwatson> it totally breaks existing dikss
<cjwatson> disks
<BenC> cjwatson: I can add the ability to pass ata_ignore_hpa=1 to the kernel command line and upgrade-note that
<nullie> Hello. Is it good to setup ppa and put debian source packages there?
<BenC> cjwatson: the alternative is to keep creating bad partitions that cause this sort of problem to begin with
<tkamppeter> pitti, I have answered your question in bug #271288
<ubottu> Launchpad bug 271288 in jockey "Require the user to confirm the license before downloading a driver if it is non-free or if it has patent issues" [High,In progress] https://launchpad.net/bugs/271288
<nullie> oh, well
<ogra> tedg, ah, i just found you can send an acpi poweroff in vbox, tried that to confirm it does nothing
<Riddell> ArneGoetje: how are the new language packs doing?
<tedg> ogra: Great, thanks for looking into that.
<ogra> tedg, btw, did i mention that the logout item from the system menu works just fine in ltsp  ?
<ogra> probably fusa should just resemble that behavior
<ogra> instead of calling gnoe-session-save or something in ltsp
<cjwatson> BenC: I agree that we should try to avoid creating them, but doesn't that really involve installer work rather than just making bits of the disk invisible in the kernel?
<cjwatson> BenC: if ata_ignore_hpa=0 is the default, I think we'll see machines just fail to boot on upgrade, unless update-manager basically just adds ata_ignore_hpa=1 to all upgrading systems (and in that case why not just make it the default?)
<BenC> cjwatson: exposing the HPA to userspace can cause more problems (kylem had outlines some really bad ones awhile back)
<cjwatson> BenC: I'd like to hear examples
<cjwatson> I know Kyle was involved in arranging to ignore the HPA after mjg59 raised it as an issue a while back
<cjwatson> has anything significant changed since feisty when we decided to ignore the HPA?
<BenC> cjwatson: a lot of upstream pressure is the main reason
<BenC> cjwatson: and the fact that HPA was actually designed to be ignored by the OS :)
<cjwatson> BenC: I'd rather have a clear plan that actually addresses all the problems rather than just bow directly to upstream pressure
<cjwatson> or rather, I'd prefer to bow to upstream pressure by means of a clear plan :)
<BenC> cjwatson: upgrades defaulting to ata_ignore_hpa=1 sounds like the right plan
<BenC> cjwatson: I can upload a new module-init-tools that adds that on upgrade, but not on new install
<cjwatson> but even then new installs on systems where there's a previous install with partitions extending into the HPA will be screwed
<cjwatson> I'm uncomfortable with us running different kernel options on a very wide swathe of systems (all upgrades) in general
<BenC> then the only alternative is to keep ignoring it, and revisit this at UDS
<cjwatson> BenC: we should probably talk about this on ubuntu-devel@
<BenC> cjwatson: for intrepid, if we aren't comfortable with the upgrade path, then I suspect there's not much choice other than to revert to what we have been doing all along
<BenC> at least it's consistent
<cjwatson> mm, I would tend to agree
<cjwatson> BenC: I won't be at UDS, but if it's possible I'd like to call into discussions on the subject, e.g. on getting the installer to behave differently going forward
<BenC> cjwatson: Ok
<cjwatson> seems like we could educate libparted a bit
<stgraber> cjwatson: How can you not be at UDS ?
<cjwatson> stgraber: we're expecting a baby just around that time; seems a bad time to be on the wrong continent :-)
<stgraber> hmm, yes, that makes sense then :)
<ArneGoetje> Riddell: building, I guess...
<cr3> is there a process that checks that all dependencies are met before building an image?
<Riddell> ArneGoetje: you guess?  they don't seem to be in launchpad e.g. https://edge.launchpad.net/ubuntu/intrepid/+source/language-pack-kde-fr/1:8.10+20081013
<cjwatson> cr3: for alternate/server CDs, we check (and output report.html) but we don't block building the image on it
<cjwatson> cr3: for desktop CDs, we install things with apt so it'll refuse if there are unmet dependencies, which will break the CD build
<cjwatson> cr3: it's common enough for optional packages (e.g. language packs) to be uninstallable and we'd rather be able to proceed with testing in the absence of those
<cr3> cjwatson: might you happen to know off hand if yesterday's daily had missing packages for smartpm-core and/or update-motd? I can't find them on the image and the installation fails with those unmet dependencies. I'm rsync'ing today's image, just to be sure.
<mathiaz> cr3: they're on the -server cd
<Riddell> james_w: is bug 267478 likely to be resolved before freeze in two days?
<ubottu> Launchpad bug 267478 in pyclutter "Please remove pyclutter from Intrepid archive" [High,Incomplete] https://launchpad.net/bugs/267478
<cr3> mathiaz: weird, something in my installation seems to depend on server stuff
<cjwatson> cr3: look at report.html, published on cdimage
<cjwatson> I don't know offhand, that's where I'd check
<mathiaz> cr3: smartpm-core/update-motd: that would point to landscape-client
<james_w> Riddell: not sure, I was going to act tomorrow. I'm hoping to get a reply from the author
<james_w> Riddell: I'm leaning towards removing at the moment
<Keybuk>  * Error: The server must be started under the locale en_GB.UTF-8 which does not exist any more.
<Keybuk> cjwatson: any ideas?
<Keybuk> my desktop seems to have reset to "C" as well
<ArneGoetje> Riddell: 1:8.10+20081011
<cr3> mathiaz: I wonder if the problem is that I'm taskselecting both ubuntu-standard and ubuntu-desktop, maybe I should just specify ubuntu-desktop although I thought one encompassed the other
<cjwatson> Keybuk: locale -a - does it list en_GB.utf8?
<cjwatson> (ignore the slightly different spelling)
<Keybuk> cjwatson: no
<Keybuk> C and POSIX only
<cjwatson> Keybuk: do you have language-pack-en-base installed?
<Keybuk> language-pack-en-base	1:8.10+20080920
<mathiaz> cr3: which cd are you refering to?
<cr3> mathiaz: alternate
<Riddell> ArneGoetje: that's the one you said you were going to make yesterday?
<tedg> Keybuk: Make sure to add some 'z's to your computer.  WIthout en_GB you'll probably run out otherwise.
<Riddell> ArneGoetje: that doesn't contain kdelibs4.mo
<cjwatson> Keybuk: meep, no idea. Try 'sudo /usr/share/locales/install-language-pack en ""'?
<Keybuk> cjwatson: it's generating locales
<cjwatson> cr3: (a) the task is called standard not ubuntu-standard (b) you don't need to select standard explicitly
<Keybuk> cjwatson: locale -a lists en_OMGLOTS
<ArneGoetje> Riddell: I can't influence that. I'm talking with jtv in the moment. Maybe we can get an intermediate update before Friday.
<Riddell> ArneGoetje: we're freezing on thursday!
<cjwatson> Keybuk: sorted. wonder why that happened
<cjwatson> Riddell: language packs have historically gone later, though
<cjwatson> although the sooner the better given the problems
<cjwatson> Riddell: unfortunately the export takes a week :(
<ArneGoetje> cjwatson: currently we seem to be down to 3 days. However, we will have a full export on Friday with the database contents from the same day. We are pulling plan B for that.
<cjwatson> I see we're finally into October on imports
<cjwatson> the number is still big but that must be almost entirely updates now
<ArneGoetje> cjwatson: yes, hopefully
<cjwatson> I've been compulsively reloading the queue ;-)
<mvo> davmor2: could you check if the session plugin in loaded for you (via ccsm)
<davmor2> mvo: that's the compiz advanced editor thing isn't it?
<mvo> davmor2: yes
<davmor2> np's
<superm1> asac, could you take a look at bug 277302 sooner than the current milestone for it (ubuntu-8.10)?  It's got a fix attached, and is kinda preventing doing wubi testing with mythbuntu.
<ubottu> Launchpad bug 277302 in ubiquity "NetworkManager is starting up "after" ubiquity in only-ubiquity mode" [Undecided,Invalid] https://launchpad.net/bugs/277302
<asac> superm1: hmm. did you do a merge request?
<superm1> asac, ah no, I didn't realize I was supposed to
<asac> superm1: did you investigate what is run in 28,29 ?
<asac> superm1: you use an email for commits that isnt known to launchpad :)
<superm1> asac, so on a fairly default install of mine (i've only "added" stuff rather than removing services etc), I don't see anything else at 28 or 29
<davmor2> mvo: I got session management
<asac> superm1: dont we need to bump the minimum version in the if on top of that?
<asac> superm1: did you try if the "migration" works well?
<superm1> asac, you mean from the previous runlevel to this one?
<asac> yes
<mvo> davmor2: cool, thanks
<mvo> davmor2: I think I pinpointed it, now I "just" need to fix it :)
<superm1> asac, No I haven't.  I wasn't positive what needed to be checked for this type of change, so I wanted to clear with you before anything else was done
<asac> superm1: bump the version above to the proposed package version of this upload
<asac> superm1: at best merge the latest first
<superm1> asac, okay will do
<superm1> asac, i'll re-propose it for merging after I can double check it migrates right then
<asac> superm1: yeah. proposing for merge would be nice
<asac> superm1: try to use the right email :)
<asac> superm1: look: https://code.edge.launchpad.net/~superm1/network-manager/ubiquity-fix
<superm1> asac, ah yeah, that computer I did on didn't have my bzr info set right.  i'll do it from my main one sand it will work correctly
<superm1>  *sand=and
<asac> ;)
<asac> superm1: oh. it was the wrong branch you asked it to be merged in
<asac> superm1: https://code.edge.launchpad.net/~network-manager/network-manager/ubuntu.0.7
<superm1> asac, that's what the default had pulled up, what's the proper one then?
<asac> thats the right target ;)
<superm1> ah okay
<superm1> thanks
<asac> superm1: that was the upstream branch
<superm1> ah
<johanbr> evand: I thought I'd try usb-creator with a usb memory, just to see how it works. But it stalls at "102% complete".
<Keybuk> clearly it did too much
<evand> curious
<BenC> cjwatson: module-init-tools with libata ignore_hpa=1 uploaded
<Keybuk> BenC: is that a default option?  shouldn't that be a kernel aptch?
<evand> johanbr: is there anything relevant in ~/.usb-creator.log
<BenC> Keybuk: we have modprobe.d and module options so we don't have to patch the kernel
<Keybuk> no we don't
<Keybuk> modprobe options are error-prone
<Keybuk> they are difficult to apply
<Keybuk> a huge number of situations exist in which they could fail to be applied
<BenC> Keybuk: then why does /etc/modprobe.d/options even exist?
<Keybuk> they are difficult to override
<johanbr> evand: actually, it just finished :)
<Keybuk> since they are conffiles
<johanbr> evand: but I did get "GtkWarning: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed"
<Keybuk> and they are *expensive*
<Keybuk> BenC: I have been steadily attempting to get rid of it
<Keybuk> I had got down to two drivers that needed patching
<BenC> Keybuk: I'm not patching the kernel unless you can provide me a solid reason
<Keybuk> BenC: because if the kernel default is wrong, the right thing to do is change the kernel default!
<BenC> Keybuk: it's not wrong...OUR default is wrong
<Keybuk> so we change OUR kernel ;)
<BenC> Keybuk: I'd rather our changes to the kernel default options be more visible
<Keybuk> I'd rather they be more reliable and cheaper
<BenC> changing them in source obfuscates them
<Keybuk> hardly
<Keybuk> changing them *outside* of course obfuscates them
<Keybuk> quest scott% modinfo ipw2200 | grep associate
<Keybuk> parm:           associate:auto associate when scanning (default on) (int)
<Keybuk> "default on"
<BenC> Keybuk: uh, I can grep /etc/modprobe.d/ but if I change the source, there's no way to know unless you check the source code
<Keybuk> except if I modprobe "ipw2200" that will be *OFF*
<Keybuk> and I have to hunt around the filesystem, to find a strange file that has it set otherwise
<Keybuk> *AND*
<cjwatson> most options aren't set in /etc/modprobe.d/ at all so the natural place to look is in the source code
<Keybuk> if I change that file, and reboot
<Keybuk> the default doesn't *GET CHANGED*
<evand> johanbr: hrm, do let me know if the resulting image is broken in any way (persistence support will land you in a busybox shell at the moment)
<Keybuk> because I forgot to run update-initramfs, or something
<BenC> I prefer they be in userspace rather than changes to the kernel source
<Keybuk> I prefer kernel defaults be set in kernel source
<BenC> The point being that upstream set defaults, and we are changing them using prefered methods
<Keybuk> no, it is not the preferred method
<BenC> the same methods that users would use
<Keybuk> the preferred method is to change the kernel source
<Keybuk> exactly
<Keybuk> we should not set defaults in the same way that users would use
<Keybuk> because it makes it difficult for the user to override that to their value
<BenC> Keybuk: if modprobe.d has shortcomings, then users will experience them too...isn't that a bug?
<Keybuk> BenC: no
<Keybuk> it's a bug that modprobe options are even needed
<Keybuk> and it's slowly being deprecated
<BenC> Keybuk: vi /etc/modprobe.d/options; sudo update-initramfs -u
<Keybuk> at some point in the very near future, we won't *have* a modprobe.d
<Keybuk> just like Fedora doesn't already
<johanbr> evand: Sure. Is it possible to recover from that, or is persistence just broken atm?
<Keybuk> they have a much better way of doing it by taking module options from the kernel command-line
<BenC> Keybuk: If I change the source, some users may want to change this default, and they will have to do the same thing that they would do if I change the source instead of a modprobe.d file
<Keybuk> so it doesn't matter whether the driver is a module or built-in
<Keybuk> the same parameter still gets applied
<Keybuk> in fact
<Keybuk> that's YET ANOTHER argument for changing the source
<BenC> Keybuk: you can't take module options from the kernel command line
<Keybuk> if we rely on modprobe options, we utterly break things for users that compile drivers in
<BenC> we've had to hardcode that functionality for a few special cases
<Keybuk> since modprobe doesn't apply options to built-in drivers
<Keybuk> BenC: err, explain "can't" ?
<Keybuk> they parse /proc/cmdline
<BenC> if users compile their own kernel, they are on their own
<Keybuk> they should not be
<BenC> Keybuk: Not all of them
<BenC> Keybuk: only ones I know is video fb drivers
<Keybuk> compiling drivers into the kernel has real performance benefits
<Keybuk> it is something we should support
<Keybuk> and indeed, is something I'm recommending we *do* by default ourselves
<BenC> Keybuk: either way, I'm not hitting source for this one
<Keybuk> there are about 10 reasons why you should patch the kernel to fix the defaults
<Keybuk> and the only reason you've given for not doing it is "because you don't want to"
<BenC> Keybuk: you haven't given me a _good_ reason
<Keybuk> what breaks by patching the kernel to fix the kernel default?
<BenC> Keybuk: maintaining, merging, rebasing...
<evand> johanbr: at the CD boot menu, hit F6 and remove peristence from the kernel command line arguments.  This will disable persistence support, but as mentioned, it's broken.
<Keybuk> BenC: I've given you a pile of things that *break*
<Keybuk> BenC: surely git makes all that easier?
<Keybuk> it's a one line patch, after all
<BenC> Keybuk: yeah, if users compile their own kernel
<Keybuk> modprobe options are expensive to parse and apply
<Keybuk> modprobe options fail to be applied if:
<Keybuk> - module loaded in initramfs
<Keybuk> - module loaded by insmod
<Keybuk> - driver compiled into kernel
<BenC> modprobe options work in initramfs, so that's bull
<Keybuk> modprobe options involve modifying a conffile, and getting a conffile prompt every upgrade
<BenC> insmod isn't used directly, and if it is, by a part of our system, that's broken
<BenC> if a user compiles their own kernel, they take on responsibility
<Keybuk> BenC: only if you put it in a file that happens to be copied (upgrade pain) and don't remember to run update-initramfs
<Keybuk> you're advocating giving users the merging pain
<Keybuk> which is bullshit, sorry
<BenC> Keybuk: all of /etc/modprobe.d/ is in initramfs
<Keybuk> BenC: WRONG
<BenC> Then that's fairly broken
<Keybuk> in fact
<Keybuk> I can't even find the code that copies any of it in anymore :)
<Keybuk> oh, yes I can
<Keybuk> we copy in various bits of it
<Keybuk> but other bits get left out
<Keybuk> I'm planning to actively get rid of modprobe.d entirely
<BenC> Keybuk: uh, on my system all of /etc/modprobe.d is in initramfs
<BenC> Keybuk: Ok, when you get rid of it later, I'll revisit this, but for now, two weeks before release, I'm relying on modprobe.d, since it works, is what we used before, and your corner cases don't seem to be valid for 99.9% of people
<johanbr> evand: Alright, thanks. I'll give that a try.
<Keybuk> "patch" works even better
<Keybuk> I'm told git works too
<BenC> Keybuk: patch doesn't work if people compile their own kernel from vanilla sources
<BenC> which falls into your same argument
<Keybuk> there's a great mailing list you can send patches to
<Keybuk> it's called something like "lkml"
<BenC> Keybuk: it's called they want the default at =0, and we are forcing it to =1
<BenC> they wont change it
<Keybuk> where do they want the default at 0?
<BenC> Keybuk: ignore_hpa= for libata
<Keybuk> I can't see any mails from you to that list in the last several weeks?
<Keybuk> you don't seem to have actually asked?
<BenC> Keybuk: you seem to be assuming a lot
<BenC> Keybuk: this was discussed over a year ago
<BenC> Keybuk: OS's are supposed to honor the host-protected-area, we are broken for not doing so by default
<BenC> Keybuk: but we must because the upgrade path from previous releases is too complex to worry about right now
<Keybuk> fair enough
<Keybuk> if we're going to be broken, we should ship with broken defaults
<psyke83> asac: I got around to testing nspluginwrapper 1.1.2, and it seems to work well. Should I file a FFe or are you already working on an update?
<Keybuk> modinfo libata should show that ignore_hpa's default is 1
<Keybuk> since this is us being broken, I assume it's something we plan to fix at some point - so your argument about carrying a burdensome 1 line patch doesn't apply?
<Keybuk> in fact, looking at it
<Keybuk> most drivers set all their option variables in one block
<Keybuk> so the only time one of these option default patches would fail to merge is if the options to the module have changed
<Keybuk> or even the defaults
<Keybuk> and arguably, those are times we _really_ want to know about it
<munckfish> calc: have you guys got a sec to discuss bug 273268. I'm really concerned to do something about this cause it's a big show stopper for the ports.
<ubottu> Launchpad bug 273268 in ubuntu-ps3-port "ftbfs on all !x86 archs" [Critical,Confirmed] https://launchpad.net/bugs/273268
<munckfish> calc: If there's a lot on your plate let me know and I'll try to do as much of the foot work as possible
 * munckfish knows that calc is a single person, not many, and should have re-read his text before pressing <return>
<asac> psyke83: please use the bzr branches
<cjwatson> Riddell,ArneGoetje: is bug 281779 fixed by the langpack-o-matic changes you've been working on?
<ubottu> Launchpad bug 281779 in language-pack-kde-he "entry.desktop is in wrong directory" [Critical,Confirmed] https://launchpad.net/bugs/281779
<cjwatson> (nobody is assigned and there's no in-progress indicator or anything)
<ArneGoetje> cjwatson: yes, Jonathan updated the files in langpack-o-matic. the current langpacks should have the files at their correct location.
<slangasek> mdke: ok
<slangasek> pitti: did you see kees' comment about bug #230877?  Requires an updated SRU for dbus, which was one of yours
<ubottu> Launchpad bug 230877 in dbus "dbus inherits parent filedescriptors" [Undecided,Fix committed] https://launchpad.net/bugs/230877
<munckfish> cjwatson: if I were to need to do a test build of OpenOffice.org on powerpc do you still have that machine in your office that could be used for that?
<munckfish> I think it would takes days on my PS3
<kees> slangasek: I'll make a note on the bug as soon as dbus publishes (should be on the next publisher run)
<mathiaz> slangasek: could you have a look at bug 277658?
<ubottu> Launchpad bug 277658 in landscape-client "[ffe] update landscape-client to 1.0.23" [Undecided,In progress] https://launchpad.net/bugs/277658
<slangasek> mathiaz: will do so today, yes
<calc> munckfish: yes i have the fix for this presumably, need to build it later today, currently i am trying to make 3.0 build for some reason it decides to start OOo in the middle of the build and hangs :-(
<cjwatson> munckfish: not easily :-(
<cjwatson> munckfish: oh, you mean in the Canonical DC?
<munckfish> calc: cool, did you see my last comment on that bug - I'm a bit worried OO won't be compatible with OpenJDK what's your opinion on that?
<cjwatson> munckfish: yes, though calc can too
<munckfish> cjwatson: ok np, just wondered in case it would allow me to test a fix without bothering calc
<Mithrandir> munckfish: if you have .debs I can test build, I can do a test build for you.
<munckfish> if he couldn't make time for it
<calc> munckfish: looking back at it now
<munckfish> Mithrandir: it would be from deb source
<calc> munckfish: wrt ppc that isn't an issue as ppc doesn't work with gcj either
<munckfish> Mithrandir: thx for the offer
<Mithrandir> munckfish: obviously, I meant "source packages".
<calc> munckfish: so if it doesn't build with the change for cacao it just needs to be disabled overall
<munckfish> calc: ok, so is it a better idea to switch off Java? Less risky?
<munckfish> Mithrandir: sorry yes of course
<Mithrandir> munckfish: anyway, is it just the current source packages in intrepid or some other packages?
<munckfish> calc: well build/run/install worries me based on that debian bug
<calc> munckfish: well i will upload with the patch if it still fails i will turn off java for ppc/sparc if that happens
<calc> munckfish: hmm maybe it would be best to just disable java entirely for ppc if it is making a problem even for install
<munckfish> Mithrandir: it would be current with a patch but I think calc is going to be able to test it this time around
<Mithrandir> munckfish: ok.  Tell me if you need anything.
<munckfish> calc: My concerns are - your time so close to the end of the cycle, and the fact that powerpc is low priority. Would your schedule allow us to build with Java, test and then upload again with java disabled if need be, all before Interpid goes live?
<calc> munckfish: should be able to yes
<munckfish> calc: excellent
<cjwatson> I strongly recommend just ripping it out if it's in doubt
<munckfish> lets go for it then
<calc> munckfish: but if ppc needs working java to even install then we probably should just disable it
<cjwatson> we know it's been a problem in the past, it's low-priority - why mess around?
<munckfish> cjwatson: that would be fine too
<cjwatson> and we don't have much time
<munckfish> Being able to install from CD is my biggest concern
<calc> munckfish: because i'm fairly sure that the cacao java is broken as you mentioned i found the debian bug report about that a while back
<munckfish> and currently this stops that altogether
<calc> i'll disable java on ppc and use the patch to see if sparc starts working again
<munckfish> calc, cjwatson: lets just disable Java then. I can mess around with it in jaunty
<calc> sparc usually fails to build due to gcc ICE though so i'm not too sure it will work regardless
<munckfish> calc: fantastic!
<calc> and i will try to get that uploaded today as soon as I can get 3.0 built properly and uploaded and get my taxes done :\
<calc> they have to be mailed by tomorrow, yuck
<calc> i can probably do them while the build is running, lol
<munckfish> calc: great thx for looking at this :)
 * calc is trying older ooo-build checkout hoping it will fix this stupid ftbfs for 3.0.0
<nullie> Look. Is it ok to put unmodified debian packages to ppa, if they aren't available in ubuntu?
<jdong> you can put anything you want into a PPA as long as it doesn't violate its license.
<nullie> well, FAQ says: "We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian"
<jdong> well uploading to a PPA will almost certainly require modification of at least the changelog
<persia> jdong, Why?  Couldn't one just run genchanges?
<cjwatson> you shouldn't
<persia> True.
<jdong> I've used PPAs for testing backports with just changelog changes before and they worked. whether or not it's a good idea to be doing it extensively is another story
<nullie> is there place I can ask, why certain packages not getting included in ubuntu?
<jdong> you can probably ask here or #ubuntu-motu
<calc> nullie: if it was uploaded to debian after june 26 it would have to have been manually added to Ubuntu (aiui)
<nullie> why?
<calc> nullie: see https://wiki.ubuntu.com/IntrepidReleaseSchedule
<nullie> oh, that
<calc> nullie: "DebianImportFreeze"
<nullie> thanks
<calc> nullie: things can be updated after that but it isn't automatic after that (at least aiui)
<cjwatson> correct
<nullie> but I guess new packages for beta are not welcome?
<ion_> Ooh, the new background image is nice.
<cjwatson> nullie: probably not a great idea at this point unless it's critical for Ubuntu as a whole for some reason
 * ogra thinks X strike force uses quilt because they want to make sure *you really really want that fix in* ... for trivial fixes i wouldnt go through the pain to use quilt 
<pitti> slangasek: dbus SRU> will do
<ogra> lool, we could ask jcristau or bryce or tjaalton
<lool> ogra: yeah, I had that in mind as well :)
<lool> jcristau, bryce_, or tjaalton: the psb driver isn't available in combination with a recent kernel anywhere; we saw that xorg-server has a pci id hinting to use psb
<lool> But as psb isn't working, I dropped it from video-all and would like to remove autodetection for it
<lool> While still enabling autodetection when support lands, perhaps in some external repos later
<bryce_> lool: okay I'd be fine with that
<lool> I thought the xorg drivers had external pci ids for this purpose: if the driver is installed, it selects itself, otherwise it doesn't
<lool> So is it ok if we make sure this pci id is in psb.ids and drop the xorg-server pci id?
<bryce_> yes
<lool> thanks!
<bryce_> or should it be directed to -vesa?
<ogra> looking at debian/patches/142_psb_auto.patch it seems just adding driverList[1] = "vesa"; to the psb line might help
<lool> bryce_: it should be directed at vesa
<ogra> in xorg-server-1.5.1
 * bryce_ nods
<ogra> s/to/below/
<lool> Now I just need to locate the tree for -psb
<ogra> what we both didnt get where the *.ids files come into play here
<bryce_> also unless someone has fixed it, the -psb we ship in the regular intrepid archive != what we ship for moblin
<lool> to check whether it lists the ids in xorg-server already
<slangasek> pitti: do you have some time to look at bug #267875 (the hal part)?
<lool> bryce_: You mean ubuntu-mobile ppa versus intrepid?
<ubottu> Launchpad bug 267875 in linux "rf_kill interface not available for iwl3945, iwl4965 in 2.6.27" [Medium,Confirmed] https://launchpad.net/bugs/267875
<bryce_> lool, right
<persia> bryce_, They should be the same : there's no intrepid at archive.mobile.ubuntu.com
<lool> bryce_: i'm not sure we fixed that either, simply because we didn't want to carry over the drm hack in intrepid
<lool> persia: So we merged everything in intrepid?
<bryce_> persia: nope, the version in intrepid is 0.2.1-* which is an antique
<lool> Yeah
<bryce_> the correct version is 0.15.* and was last updated for hardy
<persia> lool, No, but the current -mobile and -mid images are from the standard repos (and will remain that way)
<bryce_> iirc it's not changed during intrepid
<ogra> lool, http://paste.ubuntu.com/57531/
<lool> It doesn't matter too much to update it I think, because of the drm requirements, bu
<ogra> thats the updated patch
<persia> bryce_, Even 0.15 doesn't compile in intrepid.
<lool> persia: That's fine
<persia> RIght.  Just a note.
<lool> persia: Exactly bryce's points
<lool> 0.15 is the latest version, doesn't compile on intrepid, so intrepid as an older version
<bryce_> anyway, just want to make sure no one gets confused by that 0.2.1 version... it's so old it might as well just be purged
<lool> we don't want the latest version
<lool> Do we care about some changes in the ubuntu-mobile ppa?  perhaps, but we will get a new upstream drop in a distant future and then we'll advise where to do what and whether there's anything to carry over
<lool> But trying to merge our 0.15 changes in intrepid doesn't make sense IMO
<lool> bryce_: Actually purging is perhaps the best option
<ogra> bryce_, does http://paste.ubuntu.com/57531/ look sane to you (line 28 was added)
<bryce_> ogra: mmm, won't the break; on line 27 prevent line 28 from executing?
<persia> ogra, Shouldn't that be driverList[0] = "psb";  driverList[1] = "vesa"; break; ?
<ogra> bryce_, whoops, indeed
<ogra> http://paste.ubuntu.com/57534/
<ogra> :)
<bryce_> ah yes that looks better
<persia> tab/space confusion aside.
<bryce_> make sure to test the fallback to make sure it gets to vesa correctly
<bryce_> if not, we can comment out line 27 until psb is available.
 * persia hopes the fallback works in case someone does for -psb what is already done for -nouveau in a PPA
<bryce_> I think if a psb.so is present but broken, this code may select that, and fail to fallback properly.  I'm not certain though because we've been doing some improvements that may make this work as expected.
<ogra> bryce_, well, the idea was to have the code in a way that we probably can provide a backported psb or PPA psb package laer
<persia> As -psb isn't installed by default, that's an unlikely case.  If someone installs it, presumably the error in the log will help encourage them to uninstall it.
<ogra> without having to upload xorg-server
<ogra> psb isnt in -all so it shouldnt be installed by default
<bryce_> alright, sounds like it should be safe then
<bryce_> still, definitely worth testing on a couple systems once its uploaded
<ogra> lool and persia have such systems
<persia> It will certainly be tested on the Jax10 and D4.  I don't know what other -psb HW people have.
<ogra> and i should too, though not really mobile :)
<persia> If you've different HW, that'd be great.  The more the better.
<lool> I have the CB
<ogra> me too
<persia> OK.  That's three devices.  Anyone have an SC3, or something else with that video card?
<lool> the dell mini also has psbN
<lool> *psb?
<ogra> i could get one if i ever answered steves offer :)
<ogra> i think he still has that thing laying around if i want it
<superm1> lool, the mini inspiron 910 doesn't have psb.  it has regular ol open source intel 945 graphics?
<ogra> well chosen :)
<lool> superm1: oh ok
<lool> (didn't known hence the "?")
<pitti> superm1: btw, is there still a pending regression for wl in hardy-proposed kernel now?
<tjaalton> bryce_: the fallback doesn't work if there's a configfile present
<superm1> pitti, that's on my TODO today to double check.  i think the last one is fixed now
<superm1> pitti, I was out of the office yesterday so I didn't get a chance to look then
<pitti> superm1: no problem, just checking
<bryce_> tjaalton: ah thanks, I was just looking to see if that's the case when no driver is listed in the xorg.conf?
<ogra> bryce_, tjaalton, what i dont understand is why we have the .ids files if everything is hardcoded anyway in xf86AutoConfig.c ... what do they do ?
<bryce_> lool: I forget, is the UME xorg.conf we ship still listing "psb" as the video driver?
<ogra> i dont think we ship any xorg.conf
<lool> We don't do this anymore
<tjaalton> ogra: the .ids are used if found
<ogra> tjaalton, so the hardcoding is overridden ?
<tjaalton> ogra: well, kind of. if no match from .ids is found, it'll use what's in driverList[0]
<ogra> ah, cool
 * ogra learned a bit again :)
<ogra> thanks ! :)
<tjaalton> not really, that's why there's the bug about -nv failing to load when the driver doesn't really support the device
<bryce_> ogra: I think the xf86AutoConfig.c code is semi-legacy; that's the old way pci id's were mapped to drivers.  The new way places this logic into the drivers themselves.
<ogra> yeah, thats what i though
<ogra> and thats why i was surprised to see all the ids in xf86AutoConfig.c
<tjaalton> bryce_: well, the _latest_ code tries to load the correct driver which should handle it, but if that fails it'll use the fallback. too bad that it doesn't work unless there's no xorg.conf
<ogra> but if .ids files override that makes sense
<bryce_> tjaalton: do you have more info on why it doesn't work when there's an xorg.conf?  are there plans in place to address that?
<tjaalton> ogra: only if there's a match. it doesn't stop there :)
<ogra> indeed, understood
<tjaalton> bryce_: pretty simple.. it builds an internal conffile if there isn't one. that'll include all the sections for fallback drivers
<lool> Ok; will look at uploading xorg-server after dinner
<tjaalton> hw/xfree86/common/xf86Init.c
<tjaalton>       case CONFIG_NOFILE:
<tjaalton>         autoconfig = TRUE;
<bryce_> ok so presumably the code that parses the xorg.conf needs to include logic that if no driver is specified, it should use the routines from the internal conffile handling algorithm to determine the driver, rather than what its using currently
<lool> unless the nice xorg folks beat me to it
<bryce_> tjaalton: do you know if anyone upstream is working to fix that?  If not we could put it on our todo list for jaunty
<tjaalton> bryce_: alanc wrote the support for fallback drivers, but I'm not sure if he's working on improving it
<jcristau> i don't think anyone's working on it right now. it's somewhere on my todo list, but..
<nxvl> pitti: are you waiting for an sru on dbus or it will hit the archive today?
<pitti> nxvl: do you mean my re-applied SRU patch? I already uploaded and accepted it
<nxvl> ubuntu3.2
<nxvl> pitti: so it will hit the archive any minute from now on?
<tjaalton> what I had in mind was to just use vesa/fbdev if there's no match from the .ids files. not worthy upstream, but should fix the problem with -nv
<pitti> nxvl: rather like 1.5 hours, when the binaries are built and the next publisher is finished
<nxvl> awesome, thnx
<nullie> humm, how I should decide, to which repo add package?
<rainct> nullie: what do you mean by "which repo"?
<nullie> main, universe or multiverse
<pitti> ("component", BTW)
<nullie> "Set the bug title to: Please merge <sourcepackagename><debian-version> (repository) from Debian <repository> (<component>)"
<nullie> For instance: Please merge zoph 0.7.0.2-2 (universe) from Debian unstable (main)
<ogra> nullie, you can only add it to universe (or multiverse if it has a nonfree license)
<rainct> nullie: as ogra says, there's no choice, it just goes into universe or multiverse (depending on the license, not on you)
<pitti> nullie: zoph is already in universe ("rmadison zoph" or "apt-cache show")
<nullie> well, that was example from wiki
<nullie> I want to add python-rope
<rainct> nullie: you can fill a MIR (Main Inclusion Report) once it's in universe and has been tested, etc., given that there's a good reason to have it there
<pitti> nullie: oh, for a package which is not in Ubuntu yet? that's not a merge then (which is merging the chagnes in debian and ubuntu), but a "sync"
<nullie> humm
<pitti> nullie: for those you don't need to worry, the archive admins will decide the component
<nullie> ok
<NCommander> persia, ping
<lool> bryce_: heh I think I found how nxvl was able to get the antique psb with current intrepid xorg
<lool> bryce_: the provide is in place, but not 'include debian/xsfbs/xsfbs.mk'
<nullie> backport requests should be filed too?
<lool> bryce_: I think I'll add an explicit conflict with psb to xorg-server and request removal of -psb from archive at this point
<james_w> NCommander: hey, are you able to look at nufw? My blind attempt failed to fix it apparently.
<NCommander> james_w, I just pined you in -motu about it ;-)
<NCommander> james_w, I apperiate you looking at that task since I went AWOL recently this weekend
<james_w> NCommander: no problem, I thought I had it, but an upload was my testbuild unfortunately.
<NCommander> yeah
<NCommander> You should see the changelogs on some of the KDE port bugs
<NCommander> "Fix for PPC"
<NCommander> "Fix for PPC"
<NCommander> "Fix for **** PPC"
<james_w> :-)
<NCommander> james_w, you inlined your changes?
<lool> Riddell: Hey, could you please lp-remove-package.py -u $SUDO_USER -m "Requested by LoÃ¯c Minier <loic.minier@ubuntu.com>; obsolete and broken" xserver-xorg-video-psb
<james_w> NCommander: yeah, there's no patch system
<bryce_> lool, sounds good
<lool> Riddell: or would you prefer a bug report?
 * NCommander normally adds one in these cases
<NCommander> and my pants are singing
<infinity> NCommander: Adding patch systems to packages to apply a single path is a much larger delta to maintain than just fixing the bug.
<NCommander> Not really
<infinity> NCommander: (Assuming we're talking about a package Ubuntu inherited and continues to sync/merge from Debian)
<NCommander> If I have to have multiple patches
<NCommander> A patch system is perferred
<NCommander> And inlining ins pure evil when something breaks
<NCommander> james_w, we really need porting boxs
<james_w> NCommander: I can get access to one if you don't have time to fix it
<NCommander> I'm building it now on my PPC
<james_w> and I don't think a one-line inline change is "pure-evil"
<lool> hmm wont watch Riddell today
<lool> I'll drop an email to StevenK for the removal
<lool> or rather, file a bug and mail StevenK
<infinity> lool: I can do it.
<infinity> lool: Done.
<lool> infinity: would be pleased if you do
<lool> infinity: thanks!
<lool> infinity: I'm afraid I forgot about US holiday yesterday, did you see my poke about Xvfb?
<lool> infinity: It looks like pygtk is failing to build on buildds with a real chroot (rather than xenish stuff)
<lool> infinity: The error message from xvfb-run -e is completely useless, so it's be nice if you could see what went wrong
<superm1> pitti, yeah I can confirm it works properly now.
<superm1> pitti, do you have a particular bug you'd like that on?
<lool> infinity: see e.g. https://edge.launchpad.net/ubuntu/+source/pygtk/2.13.0-0ubuntu7/+build/738828 or https://edge.launchpad.net/ubuntu/+source/pygtk/2.13.0-0ubuntu7/+build/738827
<pitti> superm1: not really, maybe the one you last commented on, where you said it was broken?
<superm1> pitti, ah yeah okay.
<infinity> lool: Canadian holiday yesterday actually.
<pitti> superm1: also, on bug 263097 you said "not yet", so another "yes, it fully works now" would be appreciated for SRU purposes
<ubottu> Launchpad bug 263097 in jockey "wl vs. b43 are not properly configured" [Undecided,Fix committed] https://launchpad.net/bugs/263097
<infinity> lool: And yeah, I can poke it in a sec.  Xvfb needs massaging several times per release, it seems.  I wish we had a better way to run these testsuites. :/
<lool> infinity: We actually discussed this with jcristau
<lool> infinity: Everybody hates xvfb-run, and we need to make the whole thing much more robust
<lool> it's hard to get build-deps right, and they change with Xvfb features, it's very hard to launch xvfb-run in an useful way for testsuites, and even harder to get output
<ogra> just run real X servers :)
<lool> error output
<infinity> Same problem.
<infinity> xvfb's inheriting its moving-target CLI switches and other issues from X itself.
<infinity> (Plus the part where people use xvfb to avoid asploding machines that just plain can't run a real X server, but that's beside the point)
<lool> Well perhaps we should run xvfb-run in the xvfb's package testsuite muahahaha
<lool> hmm sorry
<infinity> lool: I wouldn't be against that.
<infinity> lool: If we have a known target for expected CLI switches it should accept, and expected output from some basic scripts thrown at it, then we can stop blowing up every OTHER package's testsuite at the source.
<infinity> lool: I don't actually see a problem with that.
<lool> i'm adding that to the long list of things to fix in xvfb then!
<infinity> lool: Ugh, it only failed on big-endian architectures?  I don't like the looks of that.
<lool> infinity: There was a new snapshot taken recently
<infinity> Well, good thing my house is filled with BE arches.  Doing some local testing to see if we can get more verbosity...
<lool> thanks
<lool> infinity: There's also the option of git bisecting the regression
<infinity> lool: I'll leave that back in your hands once I give you a failure to look for.
<lool> Sure
<infinity> lool: "LOL, DOESN'T START, SUX2BU!!!111" isn't a great failure mode.
<lool> I might bounce it on tjaalton    O:-)
<slangasek> I read that and wondered if infinity was starting a new distro flavor called "sux2buntu"
 * infinity coughs.
<infinity> slangasek: Yeah, it's just like regular Ubuntu, except the entire system runs in xvfb, on top of qemu.
<lool> Not very useful when HOME isn't writable
<cjwatson> infinity: wishlist bug report: please implement sux2buntu from vnc in a browser window
<ogra> with virtual input devices ?
<infinity> cjwatson: Should I introduce artificial intercontinental latency, even when running on a local network?
<slangasek> no, you should introduce /real/ intercontinental latency, even when running on a local network ;)
<infinity> slangasek: Ahh, so the mouse emulation should be hosted in the DC.  Check.
<slangasek> using geoip to helpfully locate the server farthest from you
<cjwatson> virtual input devices> you can do wonderful things with mouseemu
<infinity> slangasek: I'm sure I can get buy-in from elmo for that!
<cjwatson> err, uinput
<cjwatson> redirect all keyboard events via your antipodes
<Mithrandir> or just use userspace device drivers and advanced sleep(3) technology.
<infinity> We're getting dangerously close to speccing yet another way to stab people in the face over the internet.
<cjwatson> you could use the whole thing as a test of the comment in linux/net/ipv4/tcp_timer.c:tcp_retransmit_timer
<cjwatson> infinity: no, you've got it all wrong. This is a way to stab YOURSELF in the face over the Internet.
<slangasek> the great thing about stabbing people in the face over the internet is that there are so many specs to choose from
<slangasek> ArneGoetje: I understand Riddell is still in a holding pattern for proper KDE langpacks; is that being worked on?
<cjwatson> hmm, 39 undecided-priority bugs targeted for intrepid
<cjwatson> Riddell: the kde-i18n-es task on bug 259180 should be rejected, shouldn't it? we don't need both it and the kde-l10n-es task
<ubottu> Launchpad bug 259180 in kde-l10n-es "KDE translation packages (kde-l10n-xx) missing on Intrepid" [Undecided,New] https://launchpad.net/bugs/259180
<cjwatson> (just trying to minimise task count on the RC page ...)
<Riddell> cjwatson: so long as it's on something in intrepid that's fine
<Riddell> it's really a bug in rosetta not kde-l10n-xx
<cjwatson> Riddell: yeah
<cjwatson> TheMuso: did you get a UI freeze exception for bug 279288? that needs to move ahead RSN
<ubottu> Launchpad bug 279288 in partman-base "User interface exception request: Ask the user if they wish to activate dmraid arrays." [High,In progress] https://launchpad.net/bugs/279288
<Riddell> lool: "ERROR   Could not find source 'xserver-xorg-video-psb/None'" I guess someone else removed it?
<lool> Riddell: Yup, infinity did; sorry for the bother and thanks!
<NCommander> ajmitch, is rezound still broken?
<ajmitch> NCommander: depends if someone else had time to look at it, since I didn't
<NCommander> given the version number still screwy as hell, I'm going to say no
<infinity> lool: Still around?
<lool> infinity: yup
<infinity> lool: Do you recall how to coax xvfb-run into writing out an X.log somewhere?
<lool> infinity: It's what pygtk does in the build
<lool> infinity: -e
<infinity> lool: That doesn't seem to be getting a log to disk.
<lool> -e debian/xvfb-2.5.log
<lool> infinity: It doesn't?
<infinity> lool: (I see error stuff in strace, I'll just bump the string size and yank it from there)
<lool> infinity: If you open xvfb-run, -e sets ERRFILE which is used as the target of the >"$ERRFILE" 2>&1 redirs after Xvfb and other commends
<lool> commands
<lool> fuck.
<infinity> [pid  3703] write(2, "\nFatal server error:\n", 21) = 21
<infinity> [pid  3703] write(2, "Cannot establish any listening sockets - Make sure an X server isn\'t already running", 84) = 84
<lool>         XAUTHORITY=$AUTHFILE xauth remove ":$SERVERNUM" >"$ERRORFILE" 2>&1
<infinity> Hrm.
<lool> It's cloberring the ERRFILE in cleanup
<jcristau> i fixed that :)
<lool> infinity: Can you remove the redirs in a local copy of xvfb-run
<lool> jcristau: Eh
<calc> OOo 1:3.0.0-2ubuntu1 should be in the ppa in a couple hours
<calc> i was about to upload when i noticed there was another update, heh
<lool> infinity: This should fix the issue with logigng
<jcristau> lool: so if you rebase on 2:1.5.2-1 you get the fix!
<jcristau> ;)
<lool> I will
<lool> I'm doing it already :)
<lool> Hmm xserver 1.5.2
<lool> bryce_, tjaalton: do we want xserver 1.2 for itnrepid?  looks like bug fixes mostly
<infinity> Hrm, I call BS:
<infinity> _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
<infinity> _XSERVTransMakeAllCOTSServerListeners: server already running
<infinity> Fatal server error:
<infinity> Cannot establish any listening sockets - Make sure an X server isn't already running
<bryce_> do you mean 1.5.2?  yes we already have all the changes from 1.5.1->1.5.2
 * rainct notes that the "busy" status on the new user/status/logout-thingie doesn't work for him with Pidgin
<infinity> lool: Given that it fails only on sparc/hppa/powerpc, I'd be willing to bet there's an endian-cleanliness issue in the routine that checks for a current listener.
<tjaalton> bryce_: in fact one commit is missing
<cjwatson_> ogra: could you check up on the status of bug 258110 in intrepid, please?
<ubottu> Launchpad bug 258110 in cmpc "Camera application cannot record video" [Critical,In progress] https://launchpad.net/bugs/258110
<infinity> lool: (This is on a headless server with no X, no other Xvfb, and in a chroot with a clean (just deleted and recreated, no less) /tmp
<cjwatson_> ogra: it looks like both are backports and so might already be in intrepid if we have a new enough version, but I'd appreciate you checking
<infinity> lool: So, no xauth breakage, no other users messing with me, and it still seems to think it's clashing with another server.
<lool> bryce_: Hmm are the changes pushed to git.d.o?
<ogra> cjwatson, erm, so i need to buld an intrepid image ?
<lool> infinity: aha
<cjwatson> ogra: no, I'm just looking through the bugs currently targeted to intrepid
<infinity> lool: Is that enough for you to go on?
<cjwatson> ogra: and I would like to know if the intrepid tasks on that bug can correctly be closed
<ogra> cjwatson, i'll check the code
<lool> infinity: Perhaps it's enough for tjaalton or bryce_
<cjwatson> ogra: thanks
<lool> tjaalton: What do you think?
<jcristau> infinity: but /tmp/.X11-unix/ exists?
<cjwatson> jdstrand: sync bug 281456 was processed; can the intrepid task on bug 257122 be closed now?
<ubottu> Launchpad bug 281456 in ruby1.9 "Please sync ruby1.9 1.9.0.2-7 (main) from Debian unstable (main)." [High,Fix released] https://launchpad.net/bugs/281456
<ubottu> Launchpad bug 257122 in ruby1.9 "Multiple vulnerabilities in Ruby" [Undecided,In progress] https://launchpad.net/bugs/257122
<jdstrand> cjwatson: yes
<jdstrand> cjwatson: removed
<cjwatson> BenC: do we still need the initramfs-tools task on bug 246269?
<ubottu> Launchpad bug 246269 in linux-meta "Switched from vesafb to uvesafb, but uvesafb can't work without v86d" [Undecided,Invalid] https://launchpad.net/bugs/246269
<cjwatson> jdstrand: thanks
<tjaalton> lool: sigh, the changelog was not finalized, but it's in the archive
<infinity> jcristau: Indeed.
<lool> tjaalton: Ok, cause I see a lot of diff between origin/debian-experimental and origin/ubuntu; I guess it's because the changes are as patches perhaps?
<infinity> jcristau: chowned back to root:root after I deleted it and had it recreated as a regular user (which caused a different complaint :P)
<lool> Looks like it
<tjaalton> lool: duh, maybe I didn't push at all
<tjaalton> lool: done
<lool> thanks
<infinity> jcristau: Hrm.  Get a different error when I whack the X99 socket and let it get recreated, my bad.
<infinity> jcristau: The real error is:
<infinity> (EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/base
<infinity> (EE) XKB: No components provided for device Virtual core keyboard
<infinity> No core keyboard
<infinity> Fatal server error:
<infinity> failed to initialize core devices
<infinity> That seems much more easily resolved.
<cjwatson> jdstrand: hmm, the bug still seems to be open ...?
<jdstrand> cjwatson: it shows here as 'Fix Released' with no milestone...
<lool> tjaalton, bryce_: so do we care to rebase on 1.5.2 (upstream or debian)?  IOW, should I merge debian-experimental or should I cherry-pick xvfb-run?
<infinity> jcristau: (Sorry, had one failure as root, so the socket stuck around... Entirely different bug there, that really should be cleaned up)
<cjwatson> jdstrand: the ruby1.9 task
<cjwatson> jdstrand: it doesn't have a milestone, but it does have an intrepid target
<cjwatson> which is "In Progress" and assigned to you
<jdstrand> cjwatson: oh heh, yeah-- I removed the milestone for the closed bug
<jdstrand> cjwatson: sorry
<lool> infinity: Does installing xkb-data workaround the bug?
<bryce_> lool, I'd asked tjaalton that question a few weeks back, and it wasn't felt necessary to rebase to it
<tjaalton> lool: rebase sounds fine by me
<tjaalton> :P
<jcristau> infinity: thanks
<lool> you say rebase, but we actually git merge, right?
<tjaalton> lool: you can also just cherry-pick the only missing commit that was added to 1.5.2
<jdstrand> cjwatson: done
<jdstrand> (for real this time :)
<lool> tjaalton: TBH I'm a bit lost in mixing cherry picks with real patches
<cjwatson> jdstrand: thanks, much better :)
<lool> I'm cherrypicking debian/ commits, but stuff from upstream in the .diff along with patches from upstream in debian/patches?  hmm
<lool> +fine
<tjaalton> there aren't patches from upstream in d/p
<tjaalton> at least not from the 1.5-branch
<tjaalton> master is different
<infinity> lool: I assume I'm still missing a package:
<infinity> sh: /usr/bin/xkbcomp: not found
<infinity> (EE) Error compiling keymap (server-99)
<infinity> (EE) XKB: Couldn't compile keymap
<infinity> No core keyboard
<infinity> Fatal server error:
<infinity> failed to initialize core devices
<lool> x11-xkb-utils
<lool> I don't quite get why it works in my chroots though
<lool> or on other arches
<lool> tjaalton: ok, understood
<infinity> lool: Nah, still fails:
<infinity> No core keyboard
<infinity> Fatal server error:
<infinity> failed to initialize core devices
<cjwatson> ogra: yay, thanks
<jcristau> xkb failure shouldn't be fatal..
<infinity> jcristau: Shouldn't be, sure.  My machine disagrees.
<lool> infinity: At least that's consistent
<lool> You don't have a core keyboard for some reason; the xkb issues are probably on all arches
<cjwatson> slangasek: do you know what's going on with bug 251683? nobody's tried to get any more information
<ubottu> Launchpad bug 251683 in grub "Grub fails to mount partitions on Kubuntu amd64 and i386 Alpha3 install" [Undecided,New] https://launchpad.net/bugs/251683
<cjwatson> vorian: what filesystem type were you using for your / (and /boot if separate) partitions in that test?
<cjwatson> vorian: and is this problem still present for you?
<slangasek> cjwatson: mmm, no I don't
<lool> tjaalton: Hmm I see you drop the last ubuntu changelog entries when merging with debian, but I don't understand why other changelog entries were kept
<cjwatson> is anyone working on bug 260235? does it actually make sense for it to be targeted to intrepid?
<ubottu> Launchpad bug 260235 in Ubuntu Intrepid "[needs-packaging] php5-gtk2" [Wishlist,Confirmed] https://launchpad.net/bugs/260235
<infinity> lool: So, can I leave it to you and the X guys to sort out why sparc/hppa/powerpc have no core keyboard?
 * slangasek pattern matches on php.*gtk and foams at the mouth
<vorian> cjwatson: it is not, i'll mark it invalid
<lool> infinity: I guess we'll come back to you if we need more info; thanks a lot!
<infinity> slangasek: It's the Way and the Light.  We're moving launchpad to PHP with a PHP-GTK frontend, too!
<lool> *needs-packaging*  needsnot!
<infinity> lool: Sure.  I won't destroy my test environment, so you can come back to me.
<cjwatson> vorian: fantastic, thanks
<vorian> no problemo
<cjwatson> vorian: I guess we're just so hot we fixed it without noticing ;-)
<vorian> hell yeah!
<calc> slangasek: i am going to attempt to get the last 2.4.1 build in tonight or by early tomorrow
<cjwatson> TheMuso: what's the state of bug 191027? should it be targeted to intrepid?
<ubottu> Launchpad bug 191027 in pulseaudio ""Failed to connect stream: Invalid argument"" [High,Confirmed] https://launchpad.net/bugs/191027
<vorian> thanks :)
<calc> slangasek: currently getting the 3.0.0 build done so that forum users will be happy ;-)
<slangasek> calc: ok, thanks :)
<slangasek> <cough> the release is lower priority than keeping forum users happy?
<lool> It's not clear to me how I should sort changelog entries when the Ubuntu version was started from an UNRELEASED entry which got its version bumped in Debian later on
<calc> slangasek: well i thought it wouldn't take long but i ran into a small issue, its now fixed so shouldn't take much longer
 * slangasek extrapolates that all forum users are cannibals
<calc> somehow when code doesn't change the build still manages to break (rc4 and 3.0.0 are the same code)
 * calc mutters something about rene flipping a switch that blew up the build :-\
<tjaalton> lool: you are free to sort them using the version numbers.. I don't think it's that important
<lool> tjaalton: If I sort them using version numbers, we'll see the first changes from Debian appear higher in the changelog than your "merged from Debian"
<tjaalton> lool: ok then, your call :)
<lool> If I don't sort them, they will be after your "merged with debian" instead of being between the merges
<seb128_> kees: hello
 * lool thinks debian/changelog merging doesn't work so well
<tjaalton> lool: you can skip the merge, just cherry-pick what you need
<jcristau> tjaalton: the cherry-pick would conflict in the changelog ;)
<cjwatson> lool: you could always move the old changelog entries around if they've never been uploaded
<tjaalton> jcristau: argh
<cjwatson> lool: you don't have to religiously keep old changelog entries that don't correspond to an upload
<lool> cjwatson: It's a) ubuntu changelog entry about merging changes from Debian b) unreleased changes from Debian
<Riddell> evand: what's planned for bug 270423 ?
<ubottu> Launchpad bug 270423 in ubiquity "[kde] doesn't show dialog after installation" [High,Triaged] https://launchpad.net/bugs/270423
<lool> and now my real history is A) merge from debian B) some debian changes C) merge from debian (a)) D) unreleased changes from debian (b))
<lfaraone> Hey, how can https://bugs.launchpad.net/bugs/277302 (patch inlcuded) get shipped?
<ubottu> Launchpad bug 277302 in ubiquity "NetworkManager is starting up "after" ubiquity in only-ubiquity mode" [Undecided,Invalid]
<evand> Riddell: I'm working on it, I hope to have it resolved tonight.
<lool> I can't possibly describe the real history AND preserve the real uploads
<lool> It's funny cause I faced the same issue in bzr branches recently, when merging debian/changelog changes from Nokia into Ubuntu
<lool> it gets fun when Debian does the same thing
<lool> I guess we shouldn't ever rely on the changelog entries from the merge party staying where they are, but mention explicitely up to which point they were pulled and list them in a separate place
<superm1> pitti, ah just make sure LBM was copied at the same time at jockey to hardy-updates, I might have missed it if it already was
<pitti> superm1: currently at it
<superm1> pitti, alright, sorry for stepping on your toes, just saw an email about jockey :)
<pitti> superm1: when did you "step on my toes"? :)
<kees> seb128_: hi!
<lool> jcristau: FYI rmdir --ignore-fail-on-non-empty
<seb128_> kees: I just got upstream complains about the vte patch you added, which is to list their concern: adding ubuntu specific api which is not ubuntu namespaced, incorrect and for which one you didn't follow up upstream to say ubuntu is using the change etc
<seb128_> kees: they will fix it properly in svn soon, can you try to backport the change before intrepid?
<Riddell> evand: good luck!
<evand> thanks
<kees> seb128_: "ubuntu-specific api" ??
<seb128_> kees: http://launchpadlibrarian.net/17143914/vte_1%3A0.17.2-0ubuntu1_1%3A0.17.2-0ubuntu2.diff.gz
<seb128_> kees: it adds a libvte function no?
<kees> seb128_: ah, that.  if they've actually fixed it, I have no problems.  They were incorrectly stating it wasn't a vte problem.
<seb128_> kees: the change is ubuntu specific since the patch has not been accept upstream so it should be namespaced to avoid issues
<seb128_> kees: they are fixing it now but complaining about ubuntu again
<seb128_> kees: would be nice to stop giving them reason to rant against ubuntu ;-)
<kees> seb128_: how about they commit the other VTE bug-fixes instead of complaining about stuff we've actually fixed?
<seb128_> kees: looks like the bug has been discussed upstream but nobody bother to look there after the change had been uploaded to intrepid
<jcristau> lool: for /etc/X11/xserver? yeah, i thought of that, and then decided I didn't care why rmdir would fail :)
<kees> seb128_: well that's not my fault fault -- they chronically ignore important bugs to VTE, even when patches have been put into their bug tracker.
<seb128_> kees: they say the fix is not correct, anyway I told them we will try to namespace the functions which are ubuntu specific and we will backport what they consider the correct change
<kees> seb128_: like I said, if they've _actually_ fixed it, I have no problem merging their fix.
<kees> seb128_: I don't see any solution for the bug still (http://bugzilla.gnome.org/show_bug.cgi?id=518405)
<seb128_> kees: behdad said he's working on a fix now so it'll probably be fixed soon in svn
<ubottu> Gnome bug 518405 in VteTerminal "Mouse scroll wheel generates unintended 8x<Up> or <Down>" [Normal,Unconfirmed]
<kees> seb128_: okay.
<seb128_> kees:
<seb128_> <behdad> seb128_: two things: 1) would help immensely if ubuntu-added API is clearly marked so (by appending _ubuntu for example), 2) would be helpful if existence of such patchs be reported to upstream.
<seb128_> <behdad> in this specific case, the solution really is something different.  and I'm working on a fix right now.
<seb128_> just for the record there
<kees> seb128_: I hadn't heard the suggestion of adding _ubuntu namespaces, which I'm happy to do.  The patch I used was already in their tracker.
<seb128_> right I pointed there to him too
<seb128_> <behdad> seb128_: the patch was indeed sent upstream, but the fact that ubuntu is actually shipping it was not pointed that.  that's the information I can use when prioritizing and making decisions.
<kees> can they please commit http://bugzilla.gnome.org/show_bug.cgi?id=54926 too then?
<seb128_> kees: anyway let's try to namespace ubuntu specific api next time and backport this svn change when it's available
<ubottu> Gnome bug 54926 in VteTerminal "Should try bold version of font before pseudo-bolding" [Minor,New]
<kees> seb128_: okay, if that makes a difference to them, sure.
<seb128_> kees: not blaming you, just forwarding upstream concerns
<lool> bryce_, tjaalton: I've pushed the Debian merge and psb changes; Debian re-adds xserver-common, is that fine with you?  If in doubt, please take a look before I upload
<kees> seb128_: okay, sure.  I'm just really sensitive about vte bugs because I spent an entire weekend of my own time fixing bug 54926 and it's been virtually ignored even though the bug has been open for 7 years.
<ubottu> Launchpad bug 54926 in ubiquity "installer crashed" [Undecided,Invalid] https://launchpad.net/bugs/54926
<bryce_> lool: I don't have an opinion; tjaalton might but I think he may be in bed
<lool> Rationale:
<lool>   * Re-introduce the xserver-common package, containing
<lool>     /usr/lib/xorg/protocol.txt and the Xserver(1) manpage for now.
<lool> The changes look safe, it's just going to NEW, but I don't think that's a big issue
<bryce_> ahh, that looks familiar, yes I think those things are safe
<bryce_> xserver-common was dropped, but then it was found certain packages were expecting to see the protocol.txt file
<lukehasnoname> who is allowed to edit community documentation?
<lool> bryce_: Ok, will push it then, thanks
<stgraber> oh oh, a new fglrx !!!
<RAOF> stgraber: What?  One that might possibly work in Intrepid?  Surely not!
<bryce_> stgraber: yep, just uploaded it
<wgrant> I'm afraid so.
<stgraber> bryce_: thanks !!! I'll test that tonight
<ogra> oh, sigh
<bryce_> stgraber: great thanks :-)
<stgraber> (not that I don't like the free driver but some 3D and compiz would be great)
 * ogra just notices that the rest of linux-lpia can only be uploaded if the kernel has built
<ogra> stgraber, intel FTW :)
<wgrant> RAOF: Are you on your amd64 machine with xinput issues right now?
<RAOF> wgrant: Yes.
<stgraber> ogra: yeah ... that's the only non-intel component in that laptop ...
<RAOF> (That's my only machine)
<wgrant> RAOF: Can you grab https://edge.launchpad.net/%7Ewgrant/+archive/+files/libxi6_1.1.3-1ubuntu5~wgrant1_amd64.deb and try it?
<stgraber> wgrant: should I too ?
<wgrant> stgraber: If you're on amd64, sure.
<stgraber> yes
<ogra> lool, i guess i dont have to care if linux-lpia is ftbfs on i386, right ?
<lool> ogra: Well actually I asked OEM and they could find the tree useful
<jcristau> lool: some packages from the xorg source package Conflict with xserver-common. i changed the conflict to (<< 7) recently, but i'm not sure if that's in ubuntu yet
<lool> ogra: But right now, it's not used
<ogra> ok
<stgraber> wgrant: works
<ogra> though i dont really get why there is an attempt to build it at all
<ogra> Architecture: lpia
<stgraber> wgrant: no more error when doing: xinput --list-props <id>
<wgrant> stgraber: You can see the properties? Can you set them to?
<wgrant> +o
<ogra> shoudnt that prevent it from building on i386 anyway ?
<wgrant> ogra: That will just make it fail. P-a-s stops it from building at all.
<ogra> ah
<ogra> k, thenk i'll just wait for the lpia build
<ogra> oh, sigh
<ogra> Package: linux-image-2.6.27-4-virtual
<ogra> Architecture: i386 amd64
<RAOF> wgrant: So, Sys->Pref->Mouse->Touchpad now shows up, but doesn't do anything.
<ogra> i bet that will get us probs
<lool> jcristau: grep-aptavail -F Conflicts xserver-common -s Package tells me x11-common, xserver-xorg, xserver-xorg-core; i guess I need to push x11-common as well
<cathyal> anyoen running dell hardware?
<wgrant> RAOF: Restart gnome-settings-daemon.
<cathyal> are they alright with linux?
<wgrant> cathyal: Yes.
<ogra> .oO(why did amit leave -virtual in)
<wgrant> In general, yes.
<cathyal> specially the integrated graphics chips
<cathyal> no issues whatsoever?
<wgrant> cathyal: They vary significantly, and this isn't the channel.
<cathyal> ok pvt then?
<wgrant> I don't think so.
<stgraber> wgrant: Mouse preferences now work here too
<cathyal> ..k
<RAOF> wgrant: Works.  You rock.
<wgrant> stgraber: As in the touchpad tab?
<stgraber> yeah
<wgrant> RAOF: This is jcristau's doing. He rocks.
<wgrant> stgraber: Excellent.
<wgrant> Thanks for testing, both of you.
<stgraber> wgrant: I just played with vertical/horizontal scrolling and could turn them on/off correctly
<stgraber> wgrant: thanks for the fix :)
<wgrant> I'm glad that's fixed...
<lool> ogra: I didn't see virtual last time; I suspect he pulled it when he rebased
<stgraber> so now I have perfectly working touchpad and soon video driver, quite a good day it seems :)
<ogra> lool, do we want for a failure or should i act right now and fix the control file in suspicion ?
<lool> ogra: Sorry, don't understand what you're referring to: virtual or i386?
<ogra> lpia
<ogra> lool, look at the control file on -changes
<lool> We want it to build on lpia  :)
<ogra> lool,
<ogra> Package: linux-image-2.6.27-4-virtual
<ogra> Architecture: i386 amd64
<ogra> thats in debian/control
<ogra> assuming that binary exists already we wil likely produce some kind of errors
<lool> Well it wont generate them
<lool> because it ftbfs on these arches
<ogra> oh, indeed :)
<lamont> wth does ekiga keep its config?
 * ogra is to tired
<lool> lamont: /apps/ekiga, in gconf?
<lamont> lool: rsync of .gconf/apps/ekiga between two machines, and ekiga still wants to be configured
<lool> lamont: Did you restart gconfd?
<stgraber> superm1: Who did you say I should contact about the Mythbuntu ISO testing testcases ?
<lamont> meh
<lamont> lool: SIGHUP will do?
<lool> I think any signal will do :)
<lool> yeah HUP is fine
<lool> kill -s HUP `pidof gconfd-2`
<superm1> stgraber, tgm4883 or tgm4883_laptop
<lool> (gconfd supposedly writes the list of dbus listeners to some on disk file and reloads it on startup)
 * lamont liked the system better when it wasn't all bolted into stupid daemons
 * lool finds it odd from the maintainer of postfix :)
<BenC> cjwatson: no
<BenC> cjwatson: (re: initramfs-tools and uvesafb)
<lamont> well... still no address book or acct info... sigh
 * ogra guesses thats saved in some gnome-keyring protected area
<lamont> registered accounts: 0
<ogra> or some such
 * lamont declares total fail on rational configuration, and will do the manual clone between ekiga configs once he can sit with the stupid widgits up on both machines
<lamont> still, what would be wrong with  putting it all in one directory, I wonder
<cjwatson> BenC: marked invalid then, thanks
<pitti> bryce_, tseliot: oh, just saw the fglrx-installer upload; two questions, (1) I thought we'd ship the driver in xorg-driver-fglrx? (2) if it actually works with intrepid now, can we update xorg-driver-fglrx, too? then I'd re-enable it in jockey
<pitti> bryce_, tseliot: oh, nevermind me; fglrx-installer is the source for xorg-driver-fglrx
<slangasek> xorg-driver-fglrx is built from ...yeha
<slangasek> bryce_: so should the comments on fglrx be dropped from the release notes completely at this point?
<bryce_> slangasek: yes
<jdong> so fglrx is gonna be really really good on Intrepid right? :)
<slangasek> w00t
<bryce_> pitti: righto
 * jdong digs out his dungeon laptop
<slangasek> jdong: no, it's going to be non-free binary crap like always ;-)
<bryce_> jdong: I sure hope so!
<jdong> slangasek: lol I have a big collection of {free, non-free} {binary, source} crap right now :D
<jdong> I think I'll survive
<bryce_> jdong: actually I'll be satisfied with "sort of works almost as good as it did in hardy"
<pitti> bryce_: so I guess https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/262819 can actually be closed now, too?
<ubottu> Launchpad bug 262819 in jockey "Jockey doesn't offer fglrx" [Critical,Triaged]
<jdong> speaking of that, bryce_ while you're here, what will it take for concurrent AIGLX sessions?
<pitti> that also means we need to revert the update-manager transition to ati
<jdong> i.e. two VTs running Compiz with Intel
<cjwatson> yay, under 100 targeted bugs
<tseliot> pitti: yes, and we will also have to make jockey depend on the modalias package
<jdong> pitti: while I have you here, can I get your opinion on bug 281835?
<ubottu> Launchpad bug 281835 in gdm-guest-session "Guest's home doesn't unmount after logout, stuck bonobo-activation-server process" [Undecided,New] https://launchpad.net/bugs/281835
<slangasek> cjwatson: also-w00t
<jdong> pitti: I can't see the trivial workaround causing any problems
<bryce_> pitti: I figured this was a prereq for that, so didn't list the upload as closing the bug, but yeah once jockey is suitably poked, can be closed.
<slangasek> now give me a second to pile some more on from the other end ;)
<pitti> bryce_: yes, I just closed the fglrx-installer task.
<bryce_> jdong: concurrent AIGLX - not sure maybe ask upstream
<cjwatson> slangasek: yeah, I've been slightly futilely trying to sort wheat from chaff in +nominations too
<jdong> bryce_: ok so it's not supposed to work right now on -intel right?
<jdong> bryce_: the 2nd display started up lacks any DRI
<bryce_> pitti: re reverting the update-manager transition, yes I was about to mention that to mvo, but if you know what needs reverted, please proceed
<cjwatson> but the list is horrific
<cjwatson> (ally long)
<wgrant> cjwatson: I often wonder if Launchpad needs some defense to prevent Joe Random from nominating for every release...
<tseliot> bryce_: I worked with mvo on that (with xkit). I'll talk to him
<pitti> bryce_, slangasek: I added release-notes and update-manager tasks to bug 247376
<ubottu> Launchpad bug 247376 in ubuntu-release-notes "undefined symbols when trying to load fglrx" [Undecided,In progress] https://launchpad.net/bugs/247376
<bryce_> jdong: it's not something I've tested, but it would not surprise me to see it not working; again, upstream is probably the best to talk to to see what work needs done.
<seb128> slangasek: I just read your freeze email, GNOME has a standing exception right? ;-)
<jdong> bryce_: ok, gotcha
<slangasek> pitti: uh, didn't we already /have/ a release-notes task on 247376?
<pitti> yeah, "reopened"
<pitti> jdong: thanks for the pointer, will fix tomorrwo
<slangasek> pitti: oh meh, I already reverted the release notes before you did that :)
<pitti> ok, sorry, closing again then
<jdong> pitti: sweet, thanks! btw I love the guest session feature :)
<slangasek> seb128: as long as you don't upload anything that depends on webkit...
<TheMuso> cjwatson: re 279288? I haven't received an exception yet. I've subscribed ubuntu-release, but no movement on the bug as yet.
<slangasek> (or otherwise bump us oversized)
<bryce_> cjwatson: yeah...  It took me a full day just to get through all the Xorg nominations.  It occurred to me that maybe a launchpadlib script could be written to just bulk-close all bugs not meeting certain criteria.  E.g. bugs with no attachments, without a priority assigned, and state undecided, probably are probably safe to decline without looking at them, and that might chop the list down considerably
<seb128> slangasek: that was not GNOME but gimp, GNOME 2.24.1 update will only bug fix updates for desktop applications
<pitti> slangasek: I did the corresponding change (fglrx) to https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview
<seb128> slangasek: but right the new webkit requirement was not nice, good that pitti fixed this one ;-)
 * seb128 hugs pitti
 * pitti hugs seb128, no problem
<pitti> seb128: nothing against webkit in general, but a bit too late for intrepid, I'm afraid
<slangasek> pitti: ok :)
<TheMuso> cjwatson: re 191027?, that was a hardy bug, but users using intrepid decided to comment on that bug as they were having problems, which appear to be resolved now.
<pitti> seb128: epy-webkit by default in jaunty, right? *duck*
<slangasek> heh
 * slangasek weeps at all the SRU bugmail from the linux SRU
<cjwatson> slangasek: can you look at 279288? I didn't want to do it myself since I was involved in suggesting the changes
<seb128> pitti: I didn't want to advocate for webkit, we had just quite some user pressure to update gimp and I didn't notice the webkit requirement before doing the update
<slangasek> cjwatson: looking
<cjwatson> oh, never mind, pitti already did
<cjwatson> :-)
<bryce_> pitti: let me know when you've updated jockey, and I'll notify the fglrx-installer bug reporters to re-test
<cjwatson> TheMuso: reload 279288 ;-)
<slangasek> er, yes, I have that bug open in a window in fact
<slangasek> :)
<seb128> pitti: doubt of that ;-) but it's not impossible that GNOME applications using gtkhtml or gecko for rendering will switch next cycle
<slangasek> seb128: s/GNOME applications/all &/ ? please?
<seb128> slangasek: all those we have on the CD will likely switch
<slangasek> woohoo
<calc> had a doh moment about why his phone is not working well, not sure why it stopped recently though
<seb128> slangasek: we still need to have xulrunner for firefox though so it doesn't really help CD space
<calc> his phone is 2.4ghz and next to a wireless router at 2.4ghz, heh
<cjwatson> TheMuso: I've seen 191027 myself in intrepid, but it was a couple of weeks ago
<TheMuso> cjwatson: Right, how do things stand now?
<cjwatson> TheMuso: I haven't seen it for a while, but it was intermittent to start with
<slangasek> seb128: getting rid of gtkhtml would help more than not getting rid of it :)
<cjwatson> TheMuso: did you consciously fix it or did it just go away?
<seb128> slangasek: right agreed on this one
<TheMuso> cjwatson: I conciously made an effort to fix it.
<seb128> anyway that's for next cycle
<cjwatson> TheMuso: ah, right
<cjwatson> TheMuso: it wasn't clear to me from the bug log that anything had been uploaded to intrepid to fix it; could you add details where appropriate?
<slangasek> hmm, I wonder if branch merge proposals are at all effective for Ubuntu at present
<TheMuso> cjwatson: Sure, when I get to my bug mail, I'll do so.
<cjwatson> thanks
<lukehasnoname> who is allowed to edit community documentation?
<mdke> anyone with a Launchpad account
<lukehasnoname> I was told I was not authorized to edit the nagios community page.
<mdke> lukehasnoname: link?
<Hix-2> hey guys, just wanted to say thanks for a linux OS that 'just works'
<Hix-2> see ya
<mdke> :)
<lukehasnoname> Well, not it works. I feel foolish. It didn't work earlier, even though I was clearly logged in.
<cjwatson> Hix-2: you're welcome :-)
<cjwatson> Riddell: does lp:~ubuntu-core-dev/language-selector/ubuntu r193 look right to you?
<mdke> lukehasnoname: no worries
<Riddell> let mw look
<cjwatson> Riddell: review of bug 266971 looks like it'd be good as well
<ubottu> Launchpad bug 266971 in language-selector "[PATCH] qt-language-selector crashes during startup in certain locales" [Undecided,Confirmed] https://launchpad.net/bugs/266971
<calc> yipee 3.0 build finished successfully
<cjwatson> slangasek: I'm feeling as if the hit rate on +nominations is about the same as that from going through a random sample of bugs. Does your experience match this?
<Riddell> cjwatson: revision 193 seems fine.  I also fixed the bug in revision 192, but both fixes seem good to have
<slangasek> cjwatson: I'm not sure I've ever gone through a random sample of bugs to compare it with :)
<slangasek> cjwatson: but it's certainly lower than I would like, yes
<cjwatson> Riddell: does that also cover bug 266971, then?
<ubottu> Launchpad bug 266971 in language-selector "[PATCH] qt-language-selector crashes during startup in certain locales" [Undecided,Confirmed] https://launchpad.net/bugs/266971
<cjwatson> hmm, doesn't look like it
<Riddell> cjwatson: no, I think we want that patch too
<cjwatson> Riddell: could you please use UNRELEASED in changelogs when you haven't uploaded them? I just realised it was incorrect for me to start a new changelog entry for that
<Riddell> hmm, I wonder why I didn't upload
<cjwatson> I'll merge the changes back
<cjwatson> I always use UNRELEASED even if I'm going to upload immediately; I find it a useful habit
<ogra> cjwatson, what do you think how many years will it take until you converted us all :)
 * ogra totally agrees with cjwatson but still constantly forgets about it
<cjwatson> echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts
<lool> Yeah, it rocks
<cjwatson> much more sensible for anything maintained in revision control
 * ogra copy pastes
 * TheMuso uses UNRELEASED also. Very handy.
<stgraber> bryce_: bug !!!
<ogra> i refrain from setting DEBEMAIL to force me to look over the changelog again
<ogra> but i think my changelog typos show it doesnt really help much
<stgraber> bryce_: http://ubuntu.pastebin.com/f6529441d http://ubuntu.pastebin.com/f34a0d549
<cjwatson> Riddell: I've committed but testing involves:
<cjwatson> Need to get 49.1MB of archives.
<cjwatson> After this operation, 149MB of additional disk space will be used.
<ogra> stgraber, all your fault :P
<cjwatson> Riddell: don't suppose I can con somebody into testing it before upload? :-)
<stgraber> ogra: why ? :) (except from choosing ATI)
<Riddell> cjwatson: I can try it
<ogra> stgraber, no exceptions allowed :P
<cjwatson> ta, r196
<stgraber> ogra: :(
<bryce_> stgraber: hmmm... come to #ubuntu-x plz
<directhex> ding dong, this is your tuesday night merge request, required to make sure intrepid doesn't ship with CVE-2008-3422 and CVE-2008-3906 haunting it: https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
<ubottu> Launchpad bug 282952 in mono "Please merge mono 1.9.1+dfsg-4 from Debian Unstable" [Undecided,Confirmed]
 * ogra cries
<ogra> lool, http://launchpadlibrarian.net/18545026/buildlog_ubuntu-intrepid-lpia.linux-lpia_2.6.27-4.5_FAILEDTOBUILD.txt.gz
<ogra> :(
<ogra> i thought we dont have the abi check anymore in lpia
 * ogra thought that was the whole purpose of having separate source packages
 * ogra mumbles something that should better be not understood by anyone and adds the abi overrides
<lool> ogra: grah :-(
<calc> uploading openoffice.org_3.0.0-2ubuntu1 now
<calc> er to PPA of course ;)
<directhex> aw, scaredycat
<ogra> calc, phew
#ubuntu-devel 2008-10-15
<directhex> gwaaaaan, dare you. double dare you!
<Hobbsee> calc: will that be in the final?
<RAOF> Man "glitch-free" pulseaudio is a barefaced lie :)
<directhex> so, i wonder if Hobbsee here feels like being a hero & uploading that ickle security-driven mono merge
<RAOF> TheMuso: If you're interested in pulseaudio 0.9.13 feedback, it suffers from _more_ underruns than 0.9.12
<TheMuso> RAOF: Oh wonderful. :S
<directhex> RAOF, thank god for my soundblaster!
<TheMuso> The more I deal with hda hardware, the less I like it.
<RAOF> I belive crimsun came to the same conclusion!
<Hobbsee> directhex: mono?  No.
<directhex> aw, poopies.
<Hobbsee> RAOF: it's glitch free for me.  *shrug*
<NCommander> WHen does jaunty open specifically?
<NCommander> Start of november, right?
<Hobbsee> NCommander: fail.
 * NCommander never claimed to succeed ;-)
<Hobbsee> NCommander: you've just managed to make this the worse release we've had that question :P
<NCommander> o_o?
<NCommander> My English parser failed
<Hobbsee> people are watching for when that question first gets asked.  usually, the previous one manages to release first before anyone asks when the next one will open!
<TheMuso> RAOF: What would be interesting is someone else who had the same codec on different system hardware, and whether they got the same underruns.
<Hobbsee> yeah, i think my english writer failed in the first sentence, too
<james_w> start of November?
<NCommander> Hobbsee, I only ask because we have a serious bug that happens to a backport
<Hobbsee> NCommander: now you've gone beyond that record (asking a couple of days after release).
<TheMuso> RAOF: Did you post your alsa-info output anywhere?
<NCommander> er wait
<Hobbsee> NCommander: ahhh.  I thought you were just desperate to start merging, or something.
<NCommander> intrepid was released and I missed it?
<Hobbsee> no.
<NCommander> Hobbsee, no, this is just backport related
<NCommander> We normally only backport from the latest release
<Hobbsee> right, yes.
<NCommander> We need a new upstream to fix the bug
<NCommander> The new upstream is in sid
<NCommander> you can see where this is going
<Hobbsee> if the next release is impossible to put things in, then just backport it regardless, and push it to intrepid when you can.
<Hobbsee> IIRC, that was the policy previously
<RAOF> TheMuso: I did at one point.  I can do so again this evening.  It's probably attached to one or more of my PPA regression bugs, though.
<Hobbsee> er, no, not intrepid.  jaunty.  whatever the release after this one is.
<NCommander> We have bent the "Must be a packaged version" to do a backport rule before
<NCommander> I'd like to avoid doing that if possible however
<Hobbsee> NCommander: well, even after we release, it'll take a while for the toolchain stuff to be done, and the general archive to open.
<NCommander> Hobbsee, ok, I'll talk to ScottK/jdong and see if we're willing to bend the rule in this case
<TheMuso> RAOF: I'll have a dig first.
<NCommander> I'm going to guess the general archive opening won't be for more like a month, right?
<TheMuso> But later...
<NCommander> (like second week of November)
<Hobbsee> NCommander: they usually are.
<Hobbsee> NCommander: and yeah, that's probably a reasonable estimate.
<calc> Hobbsee: no 2.4.1 will be in intrepid final
<NCommander> Ok
<calc> Hobbsee: final is for most intents this thursday
<Hobbsee> calc: ahhh
<NCommander> I'll have to ask ScottK on bending the rule
<Hobbsee> calc: i thought we delivered an rc of it now
<calc> Hobbsee: and 3 days of shake out for 3.0 wouldn't be nearly enough
<calc> Hobbsee: just in the ppa
<Hobbsee> ah.
<calc> Hobbsee: even with 2.4 in hardy it had major issues until a few months later
<calc> Hobbsee: so i updated it with 2.4.1 later but that was a lot of work
<Hobbsee> calc: fair enough.  I've just seen lots of people asking.
<TheMuso> crimsun: any ideas as to how we can better solve 274124?
 * calc is considering trying to get 2.4.2 in later with more fixes but that might not even fly
<calc> Hobbsee: yep, been responding to the comments on the forum
 * directhex empathises with calc, given past history with mono. except diff.gz is rather terrifyingly enormous for OOo
<Hobbsee> calc: fun.  have you gone mad yet?
<calc> Hobbsee: some of them are a bit crazy it seems
<NCommander> Stupid question
<NCommander> If we do a new upstream in an SRU or security, what is the versioning?
<calc> Hobbsee: insisting that Debian has 3.0 in their main repo (its not it is in experimental)
 * NCommander is trying to figure out how the versioning for this backport should be done
 * directhex has been responding to mono 2.0 posts on the forum
<NCommander> directhex, do you need any mono help?
<directhex> NCommander, i need a merge, which should be the absolute final version for intrepid
<NCommander> a merge from Debian?
<directhex> NCommander, yeah. latest upload, 1.9.1+dfsg-4, includes a bunch of bug fixes including two security holes
<directhex> NCommander, note the name in the 1.9.1+dfsg-4 changelog \o/
<NCommander> Sounds like *fun*
<NCommander> wait
<NCommander> O_o?
<Hobbsee> calc: hah.
<NCommander> Why does that sound like its going to burn?
<directhex> NCommander, http://svn.debian.org/viewsvn/pkg-mono/mono/trunk/debian/changelog?rev=3727&view=auto
 * calc hopes the mono update doesn't blow up OOo ;-)
<NCommander> directhex, that looks like loads of fun
<calc> seeing as debian has been in freeze for a while i think it should be safe :)
<directhex> calc, i can't think of any changes that would be harmful for libuno-cil
<calc> ok
 * ogra hopes the OOo upload doesnt blow up his lpia-linux build :P
<calc> i remember before the packaging split surprised me :)
<calc> ogra: >:-)
<ogra> :)
<directhex> calc, okay, advance warning then: jaunty will have a new mono package split
<calc> directhex: ok that should be fine
<calc> directhex: as long as it doesn't happen right before final freeze ;-)
<directhex> calc, i don't have time to read the OOo build deps before bed, but i don't see any binary deps which will change after the new split
<directhex> calc, you could sponsor my mono merge, y'know. it'd be neat!
<lool> Hmm there is no daily-live for ppc
<Riddell> cjwatson: needed a couple other fixes :-/ but seems to all work now running in multiple locales
<directhex> see this tiny diffstat? it's a teeny tiny diffstat! http://launchpadlibrarian.net/18515040/mono_1.9.1%2Bdfsg-4ubuntu1.diffstat
<calc> directhex: i have a fairly large merge to finish by tomorrow, sorry :(
<Riddell> cjwatson: I'm assuming you've gone to bed so I've uploaded language-selector (and shall go to bed also)
<directhex> calc, poo, never mind. i was hoping to avoid bugging pitti, but i really wanna make sure -4 gets in
<RAOF> TheMuso: http://www.alsa-project.org/db/?f=dad977e638055d5d42e035221185e6c519cd3990 if you haven't already found it.
<TheMuso> RAOF: thanks
<asac> calc: will you do another upload for intrepid?
<ogra> asac, he's only doing PPA uploads atm
<directhex> calc, oh, one other thing. we have, as a packaging goal, complete elimination of mono merges for jaunty. syncing fo' life, y'all.
<asac> calc: could you please fix the milestoned bug #272772 :)
<ubottu> Launchpad bug 272772 in ubuntu-docs "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix committed] https://launchpad.net/bugs/272772
<asac> ogra: PPA only until jaunty?
<calc> asac: yes
<asac> calc: did you miss that bug above?
<ogra> heh
<calc> asac: er no i am doing another upload for intrepid tonight (hopefully unless i pass out)
<calc> asac: i will include the abrowser fix in the upload tonight
<asac> calc: ok. please remember to fix that bug. shouldnt be that hard ;)
<asac> cool
<asac> thanks a bunch
<NCommander> jdong, ping
<kirkland> slangasek: hey, i might need a hand with a PAM issue
 * slangasek ducks and covers
 * directhex shoves his mono merge bug under slangasek's cover
<kirkland> slangasek: i'm trying to figure out if pam_ecryptfs is the culprit
<kirkland> slangasek: hmm, okay, not an ecryptfs problem
<slangasek> ummm ok :)
<kirkland> slangasek: well, it occurs on a system without ecryptfs ;-)
<kirkland> slangasek: intrepid system, non-root user, run "passwd"
<kirkland> slangasek: enter an "incorrect" current password
<kirkland> slangasek: passwd exits with "password updated successfully" even though it isn't (thankfully)
<kirkland> slangasek: same thing if you enter two non-matching new passwords
<slangasek> kirkland: bug #272232
<ubottu> Launchpad bug 272232 in pam "passwd - passwords do not match but updated successfully" [Undecided,Confirmed] https://launchpad.net/bugs/272232
<kirkland> slangasek: excellent, thanks.
<kirkland> slangasek: i think this is leading to some confusion on the pam_ecryptfs front
<kirkland> slangasek: i'll point at that bug
<slangasek> on my personal hit list for intrepid wrt the pam-auth-update stuff, I need to triage the bug state properly so it's on others' radar too
<fbond> Hiya, pardon the attention getting, but I think it is deserved in this case.  I've just nominated it for Intrepid:
<fbond> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264019
<ubottu> Launchpad bug 264019 in linux "unable to visit some websites and ftpsites with 2.6.27" [Undecided,New]
<fbond> Seems to be some bug in TCP that gets triggered somehow when using Verizon DSL.
<kirkland> slangasek: okay, thankfully, pam_ecryptfs isn't re-wrapping the passphrase
<kirkland> slangasek: my heart stopped for a few minutes back there ;-)
<slangasek> kirkland: yes, I got /that/ part of the framework right, it's really just the error messages that we got wrong :)
<kirkland> slangasek: :-D  thanks for that, at least
<slangasek> fbond: could you please provide wireshark captures in pcap format, instead of text dumps?
<TheMuso> RAOF: and its Realtek ALC660 is that correct?
<RAOF> TheMuso: Yes.  The other one would be the USB speaker.
<TheMuso> RAOF: yeah. Well the hda code supports your notebook with no problems so what causes the underruns I don't know yet.
<slangasek> fbond: and I guess you're doing a manual test here, since this is an HTTP/1.0 request instead of HTTP/1.1...?
<RAOF> TheMuso: Another data point might be that "pulseaudio -vvv" does not report the underruns unless there's a pavucontrol client connected.  The underruns happen regardless of the existance of pavucontrol.
<fbond> slangasek: I can provide pcap files, sure.
<fbond> I saved them.
<TheMuso> RAOF: Right.
<fbond> slangasek: Um, maybe wget uses HTTP/1.0?
<fbond> slangasek: I did some manual tests, too, but I think those were with wget.
<slangasek> wget might use HTTP/1.0 by default, I guess
<fbond> Should I upload pcap files?
<slangasek> well, no, I don't see any options to wget to specify the protocol, so that doesn't seem possible
<slangasek> fbond: yes, please
<fbond> slangasek: Okay, brb.
<fbond> (Hoping my pr0n d/l cron job wasn't running then ;)
<fbond> Ah, crap, one of them is 2MB.  Forgot to compress, sorry.  The last may be the most interesting, anyway...
<fbond> slangasek: uploaded
<fbond> Hm.  Wget appears to use HTTP/1.0.
<slangasek> fbond: hmm, I didn't remember HTTP/1.0 supporting Host: headers at all... ohwell
<slangasek> fbond: do you have a firewall configured on your Intrepid system?
<slangasek> (i.e., does iptables -L -n return anything?)
<fbond> slangasek: Just default policy accept on everything.
<fbond> Default configuration.
<fbond> I did try installing firestarter in an effort to correct the issue (didn't make any sense, but some users said it fixes things for them.  Didn't fix anything for me.  I wasn't sure if it did some iptables magic that might've been affecting things for them...)
<slangasek> fbond: ok; what I see here when tracing a comparable test is fragmented packets being sent by the remote server (www.youtube.com)
<nixternal> problems with drive encryption on install by chance? I am having issues
<slangasek> fbond: and given that you don't see the same thing, it's likely that your router isn't passing them through
<slangasek> fbond: ok, I've taken that bug as far as I can, I think; it's up to the kernel team to take it from there
<fbond> slangasek: Thanks.  The issue at hand is that the problem only exists with 2.6.27.
<fbond> I'm on 2.6.24 now and it does not exist at all.
<fbond> (2.6.24 with intrepid userland)
<fbond> You think it might be a library?
<slangasek> no
<fbond> slangasek: Okay, thanks for looking into this.  I think it may be a serious issue.  I've added one more comment.  I hope the kernel team is able to find the problem.
<TheMuso> slangasek: re 274124 I am not sure what more can be done at this point. The only thing I could do is wrap pulseaudio in a script to either prevent it from loading if something is using a sound device, or make it wait and load when the device is free. Other ideas are welcome.
<slangasek> TheMuso: I think the latter is Obviously Correct, but maybe there's some reason you don't?
<TheMuso> slangasek: The problem here is that pulseaudio detects sound devices on load, and a user may have more than one, so the script would have to check all devices. Even then since it seems pulse behaves weirdly when it tries aaaato connect to a device and fails, I am not sure if that script will help.
<crimsun> TheMuso: (sorry, just returned from class.)  What was the rationale for --disable-pulse --enable-alsa being used as libcanberra-0.6's extra configure flags?
<TheMuso> crimsun: pulse 0.9.11 or greater is needed for canberra.
<crimsun> TheMuso: ah, right.  Yeah, busy-waiting isn't the approach I'd recommend, either, so I'll have to give your proposed steps a try here in a bit.
<TheMuso> crimsun: Ok. The pulse-session wrapper is needed due to the way thigns are started in /etc/X11/Xsession.d, and I wanted pulse to be run after the dbus session is started.
<lifeless> does lennart use pulse yet ?
<TheMuso> lifeless: I believe so.
<lifeless> it should improve soon then :P
<slangasek> TheMuso: ok, I've tried putting pulseaudio into the X11 session here as you suggested in the bug, and it worked
<slangasek> TheMuso: but I still have concerns that we're only reducing a race, not solving it
<TheMuso> slangasek: I understand, however due to the way GNOME starts up, there is the potential for a lot of race conditions in general, and afaik there is no reliable way to get a signal from pulseaudio to say "I'm started, go ahead". If there was, I'd get the login sound playback to wait for that signal before it does anything.
<slangasek> TheMuso: no, the point is that each component should be /resilient/ in the face of races
<TheMuso> Since gnome now uses desktop files in a couple of locations to start things, there doesn't really appear to be a reliable way to have one startup item be a dependency for another.
<slangasek> unless there's specifically a reason that it's also wrong for these other bits to start before pulse is running
<TheMuso> slangasek: Point taken, but as far as I understand things re the GNOME startup process, short of not using pulseaudio at all, there is no way the libcanberra login sound startup item can know that pulse is ready. Things however will be much better for jaunty, as we can build libcanberra with pulseaudio support only, which will require it to wait for pulseaudio.
<TheMuso> Unless crimsun has any other ideas to make things more resilliant.
<crimsun> TheMuso: not really any more (hence my first question regarding libcanberra0.6)
<slangasek> why does libcanberra need to know pulse is ready?  I don't see why pulse isn't doing a better job of recovering if the device is in use when it starts up
<TheMuso> Newer version of pulse may recover better than 0.9.10 does. I'll dig through upstrea git, but I don't remember seeing anything in the logs about improving such behavior.
<TheMuso> slangasek: Because the race here is caused by libcanberra playing a sound, and pulseaudio is either not fully loaded enough to receive the audi ofrom the alsa pulse plugin and play it, or its not loaded at all. What makes this extra difficult is that on all my machines, the race condition never seems to eventuate to where pulse cannot load properly.
<TheMuso> so fixing pulse is whats needed, I'll see what I can find.
<slangasek> so I think you should be able to reproduce this by: 1) kill pulseaudio, 2) play a long sound with aplay, 3) start pulseaudio again
<slangasek> I haven't tested this, but that seems to be the race in question, and I think pulseaudio should be made robust in the face of it
<sbeattie> slangasek: dumb question time: what's the procedure for getting uninstallable packages out of the archive? e.g. xserver-xorg-video-unichrome wlassistant
<slangasek> sbeattie: file a bug on the package requesting removal, subscribe the sponsors team for the corresponding archive component if needed, subscribe ubuntu-archive if not
<sbeattie> slangasek: okay, thanks, will do.
<TheMuso> slangasek: thats what I'm doing now.
<crimsun> right, my test case has been running aplay -Dplug:hw:0 foo.wav in a loop on tty1 and logging in to GNOME
<crimsun> in that case, pulseaudio --fail does not fail catastrophically, which is also a problem
<TheMuso> crimsun: Right. Just checking a log I made here, pulse doesn't try again to connect to an audio sink if it didn't succed in finding one on the first go.
 * slangasek nods
<TheMuso> The fun bit is finding where in pulse we need to tell it to try again.
<slangasek> TheMuso: I would propose that you tell it to try again when it receives a new client request
<TheMuso> slangasek: My thoughts as well.
<TheMuso> Well, the same bug exists in 0.9.13, but instead of doing nothing, 0.9.13 has a null sink that gets used if other sinks are not available.
<NCommander> Hey TheMuso
 * calc remembered to write the mimetype identification for Microsoft files :)
<sbeattie> hrm, anyone know why libfile-temp-perl got removed? libmime-tools-perl depends on it, and a few things depend on that, etc.
<slangasek> because it's obsolete and people were trying to fix the libmime-tools-perl dep but there was a build failure if I've distilled IRC correctly
<sbeattie> ah, okay, as long as its already known. thanks.
 * StevenK tries to find run-init
<StevenK> Since this device booting jumps out of the initramfs and seems to hang.
<ScottK> Hobbsee fixed it.
<ScottK> Err Hobbsee changed it to avoid a brain dead area of Soyuz.
<calc> one last bit to fixup then final OOo 2.4.1 test build :)
<calc> is there a /usr/lib/abrowser/plugins dir?
<dholbach> good morning
<evand> good morning dholbach
<dholbach> hi evand
<NCommander> ScottK, so now what? (w.r.t to the backport)
<ScottK> NCommander: I'm gonna upload it.
<NCommander> Cool :-)
<NCommander> Its in the PPA to save you some work
<ScottK> It's just a debian/changelog entry, so I just grabbed it from Debian.
<NCommander> Oh ;-)
<ScottK> Uploaded.
<calc> uploading openoffice.org 1:2.4.1-11ubuntu1 now
<NCommander> \o\ /o/ :-)
 * calc prays it builds properly on all working archs
 * NCommander watches it FTBFS on hppa just to spite you
<calc> NCommander: it definitely will on hppa
<calc> NCommander: it doesn't support hppa at all, configure fails
<NCommander> O_o;
<NCommander> OpenOffice supports m68k o_o;;;
 * calc is hoping this build will pass on ppc though
<calc> NCommander: yea, i'm not exactly sure why it hates hppa, haven't taken the time to look into why
<NCommander> We even managed to build it on m68k
<calc> probably it works on m68k because someone bothered to fix it ;-)
<calc> now i get to work on taxes :\
 * calc wants to sleep instead of doing taxes :\
 * ScottK high fives calc.
<ScottK> calc: I'm mailing mine tomorrow too.
<calc> i have until jan but i don't know if they extended the stimulus checks for texas also
<calc> so i am filing tomorrow to be safe
<ScottK> Ah.  Well I had until tomorrow.
<ScottK> slangasek: If you're still around, it's be nice if you would accept kdesvn in hardy-backports.
<sten_> hi.  I'm trying to semi-automate adding debian/changelog info.  Any pointers?
<sten_> (cat leaves EOF markers which break dpkg-buildpackage)
<evand> dch?
<StevenK> Yeah, dch will can do it semi-automatically
<StevenK> s/will //
<RAOF> s/semi-//
 * RAOF uses dch from a script for nouveau.
<slangasek> calc: didn't build with -v1:2.4.1-9ubuntu2?
<sten_> ahh.  I figured someone would have already written something!  Thanks!  (in ignorance, some of us end up trying to re-invent the wheel)
<slangasek> ScottK: done
<liw> sten_, what are "EOF markers"?
<NCommander> Is anyone here a Linux kernel guru?
<dholbach> NCommander: #ubuntu-kernel
<NCommander> ooh
<NCommander> handy
<sten_> liw: End Of File.  I was using a combination of cat, cut, and sed (and maybe awk...but I don't remember, since I haven't looked at the code in months, and I just deleted it)
<sten_> liw: anyways, this produces and EOF in the middle of a file, apparently:
<sten_> liw: echo "This is normal text" > orig.txt ; echo >> orig.txt ; echo "This is line 3 of normal text" >> orig.txt
<sten_> liw: then,
<sten_> liw: echo "This is going to be pre-pended text" > additions.txt
<pitti> Good morning
<sten_> liw: and finally, cat additions.txt orig.txt > newfile.txt
<sten_> liw: dpkg-buildpackage fails, due to the EOF at the end of additions.txt, which gets place in the middle of the newfile.txt, between additions.txt's text and orig.txt's text (there should only be one EOF, and it should actually be at the end of the file!)
<liw> sten_, er, I don't think things work the way you think they do. unix does not have an "end of file marker", it keeps track of the length of a file and does not use a marker of any kind
<slangasek> sten_: I'm afraid you're mistaken, that command will not produce an EOF where you suggest it does
<sten_> liw: (of course, I was mucking with the changelog.  It's really nice to know about "dch" :-)
<sten_> slangasek, liw: then why does dpkg-buildpackage fail with this output?
<liw> sten_, http://paste.ubuntu.com/57761/
<slangasek> I don't know, your example text isn't exactly a valid changelog entry
<liw> sten_, I think you did something else that went wrong
<liw> sten_, anyway, I'm glad you find out about dch
<slangasek> indeed, dch is Happy
<sten_> yup, :-)  I'm not even going to bother with the strange, illogical debugging process I've been taking a look at every few weeks or so (seriously, it didn't make sense.  I also didn't think that unix had EOF markers for normal files -- mind you, I'm quite familiar with them when using tape...)
<StevenK> pitti: I note you marked bug 281144 as a dupe, removed source and binaries for bluez-libs, but didn't remove source for bluez-utils
<ubottu> Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid (dup-of: 281135)" [Wishlist,Confirmed] https://launchpad.net/bugs/281144
<ubottu> Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Fix released] https://launchpad.net/bugs/281135
<pitti> StevenK: argh, that would be me not being able to read
 * StevenK removes it
<pitti> StevenK: thanks
<sten_> I know it's not a bug, because modifying /etc/modprobe.d/aliases causes it, but I've noticed that gnome no longers starts unless the ipv6 module is allowed to autoload.  Does anyone know why this might be?
<sten_> (steps to replicate: change ipv6 on L11 to off, reboot, attempt to start a gnome session)
<StevenK> pitti: Looks like libflashsupport and kio-sword still want libgnutls13. kio-sword just needs to be pulled out from ichthux-desktop and it can get killed.
<StevenK> pitti: I'm not sure what to do about libflashsupport -- some people say kill it, and others say it is useful.
<slangasek> wasn't there discussion about libflashsupport being the cause of all flash crashes everywhere?
<slangasek> and/or conflicting with pulseaudio?
<pitti> slangasek: can you please commit your hal change to bzr?
<slangasek> oops
<slangasek> yes, sorry
<StevenK> slangasek: That's what I've heard. But I've heard others say it makes Flash work with Pulse ...
<StevenK> So, I'm fairly confused about it.
<pitti> StevenK: I don't know about libflashsupport, I'm afraid; I think we shuold ask ogra
<StevenK> pitti: Sounds good to me, I need to ask him about the lpia kernel, too
<slangasek> pitti: done
<pitti> slangasek: thanks
<slangasek> hrm; how did pwlib build prior to the latest upload, given that it depends on libdc1394-13-dev in universe?
<StevenK> slangasek: libdc1394 was demoted on the 26/07/2008
<slangasek> StevenK: ah, where do you see that?
<StevenK> slangasek: https://edge.launchpad.net/ubuntu/+source/libdc1394/1.1.0-5ubuntu1
<StevenK> slangasek: Specifically, the Superseded section with "Removal requested  on 2008-07-27. "
<StevenK> Er, rather "Superseded  on 2008-07-26  by libdc1394 - 1.1.0-5ubuntu1"
 * StevenK glares at his mouse
<slangasek> ah, yes
<StevenK> Pity it doesn't tell who changed the overrides. :-)
<slangasek> yeah :/
<slangasek> not that any of us are likely to remember now the reason :)
<slangasek> well, the build-dep is probably expendable anyway, from what I see
<pitti> maybe it just appeared in component-mismatches and we demoted it en masse?
<pitti> if it previously was in main, there shouldn't be a problem just promoting it back
<StevenK> pitti: Speaking of component-mismatches, how does one go about fixing some of that stuff?
<pitti> StevenK: main -> universe can "just be done"
<slangasek> pitti: AFAICS it should never have appeared in component-mismatches since pwlib build-depended on it continuously
<slangasek> but I think that b-d can be scrapped, checking
<pitti> StevenK: universe -> main is a mixed thing; watching for MIRs, fixing packages to not need them, or dropping main packages which pull in a lot of stuff
<slangasek> ah, it is needed, the plugin package it builds just winds up in universe
<slangasek> so yes, I'll re-promote it to main
<slangasek> ogra: I don't remember now what needed to be done for rasmol, but it's still dep-wait in intrepid...
<StevenK> pitti: Some the main -> universe looks due to no reason for staying in main. I'm a little retiscent to demote stuff that I know either I or someone else worked hard to get into main in the first place. :-)
<slangasek> if it's supposed to be in main, it should've been seeded by now
<StevenK> usb-creator is in main, and is "supposed" to be.
<StevenK> bluez-utils erroneously appears, but that has to wait for a britney run
<StevenK> Reverse-Depends: Rescued from sendmail]
<StevenK> The hell? Like sendmail is in main anyway
<slangasek> the source is (libmilter)
<StevenK> Oh, eeek.
<StevenK> Actually, britney is a little confused. a52dec is listed for main due to gstreamer-plugins-ugly, which source and binaries are in universe
<pitti> StevenK: also, please NB that some of the main->universe are not justified, because they are in the mobile seed
<pitti> StevenK: like midbrowser
<StevenK> The mobile seed is in universe
<slangasek> StevenK: it's transitive, and something else wants gst-plugins-ugly0.10 (elisa)
<pitti> StevenK: oh, I thought you wanted those packages in main for langpacks, or so?
<StevenK> pitti: It's a long story
<pitti> StevenK: is the result "they are fine in universe"?
<slangasek> StevenK: and I'm pretty sure that's not britney...
<StevenK> pitti: The result is "They can stay where they are for the moment"
<StevenK> slangasek: I was wondering if it was britney or annastacia
<pitti> StevenK: hm, then we need to teach britney about the mobile seed
<slangasek> StevenK: britney doesn't know anything about germinate
<pitti> StevenK: otherwise it's just too easy to accidentally demote either those or (less obvious) one of their dependencies
<StevenK> Hmmmm. I see that. elisa is the cause of a lot of c-m stuff
 * slangasek drops off for a bit of sleep
<bigUSA> ÃÃ°Ã¨Ã¢Ã¥Ã² Ã¢Ã±Ã¥Ã¬.
<bigUSA> ÃÃªÃ Ã¦Ã¨Ã²Ã¥, Ã³ ÃªÃ®Ã£Ã® Ã¯Ã®Ã«Ã³Ã·Ã¨Ã«Ã®Ã±Ã¼ Ã±Ã¤Ã¥Ã«Ã Ã²Ã¼ ÃªÃ³Ã¡ Ã¨ 4 Ã®Ã²Ã¤Ã¥Ã«Ã¼Ã­Ã»Ãµ Ã°Ã Ã¡Ã®Ã·Ã¨Ãµ Ã±Ã²Ã®Ã«Ã ?
<pitti> mvo: hi
<pitti> mvo: did I see the "u-m must revert fglrx migration" bug I threw at you last night?
<mvo> pitti: yes, I talked with bryce_ about it, I upload the revert soon
 * pitti hugs mvo, thanks
<mvo> cheers
<bryce_> mvo, thanks :-)
<jibel> pitti: Hi
<jibel> pitti: I don't think 256131 is fixed. There's still an issue because of the order in which scrollkeeper / xml-core are uninstalled/installed
<jibel> bug 256131
<ubottu> Launchpad bug 256131 in rarian "failed to upgrade : "update-xmlcatalog: error: entity already registered"" [High,Fix committed] https://launchpad.net/bugs/256131
<pitti> jibel: I know
<pitti> jibel: that's why the rarian task is still open; I need some feedback on ubuntu-devel@ on it
<jibel> oh, ok.
<davmor2> mvo: there are lots of dupes of the screensaver bug coming in :(
<mvo> davmor2, meh, ok
<mvo> davmor2, when you do the next install test, would you watch out for the control-center issue again? I uploaded a new plugins-extra package that should fix it
<Koon> mvo: it's juste the merge of the other bug you were assigned to. I merged them into the one that has been nominated for intrepid release
<davmor2> mvo: this morning after I drop my wife off at a meeting so np's there
<mvo> Koon, thanks, did you do some bug triage on the screensaver bugs? or did you ran accross it yourself?
<Koon> mvo: I ran accross it myslef, found the two bugs and merged them
<Koon> mvo: do you already have an idea how to fix it or are you still searching ?
<mvo> Koon, no idea, ogra  did some tests and thinks dpms is probably mixed in, but I haven't found time to look into it properly
<mvo> Koon, what video card/driver do you use?
<mvo> for me it went away after upgrading to compiz 0.7.8
<Koon> upgrading to 0.7.8 doesn't fix it for me, as well as xset -dpms. I have to uncheck "unredirect fullscreen windows" in compiz config
<Koon> I have it both on my laptop (Intel X3100) and my workstation (nvidia 8xxx)
<mvo> Koon, ok, thanks
<Koon> mvo: if you can't reproduce it, don't hesitate to ping me for any test you may require
<mvo> Koon, thanks, will do
<Hobbsee> ScottK: well, I *tried* to fix it.  Then managed to somehow get an interesting dpkg error.
<sbeattie> mvo: I commented on bug 282830; update-manager is still failing for me in that VM despite apt-get dist-upgrade -y working.
<ubottu> Launchpad bug 282830 in update-manager "update-manager claims to do a release upgrade, but doesn't actually install packages" [Undecided,New] https://launchpad.net/bugs/282830
<mvo> sbeattie, ok, good (or bad) - that narrow the problem down a bit, I check it out and sent you debug patches
<sbeattie> mvo: cool. it will probably have to wait a few hours, I need to sleep soon.
<tseliot> mvo: did you have a look at this (and at Aaron Plattner's solution)? https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/269904
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed]
<mvo> sbeattie, sure, it must be really late in your TZ
<mvo> tseliot, no thanks for pointing it out
<tseliot> mvo: I think it's something worth having ;)
<mvo> tseliot, yeah, I need to check how complete it is before adding it
<tseliot> ok
<liw> hmm. I get a notification that my quit button can be replaced by the new thing. but I don't have a quit button. shouldn't the updater check for that?
<seb128> liw: it'll tell you that you don't have the applet and that you need to update the configuration
<liw> seb128, what configuration is that? (I already told it not to bother)
<seb128> those are question for mvo ;-)
<seb128> but right the migration tool is not really smart right now
<seb128> I think it doesn't verify if the switch user applet is installed either before adding it
<liw> I admit that I'm probably an unusual case for removing the quit button in the first place
<mvo> liw, its pretty difficult to do that (check for it before showing the notification) because the notification is created with a postinst thing that can't easily look into the users gconf
<mvo> liw, so while we could do it with some extra work so far I stayed away from it assuming it would be somewhat unusual
<liw> mvo, what change does it do if one presses the update button?
 * mvo thinks we could have made all of this better and more clever if it came up a little bit earlier in the release process
<mvo> liw, it moves the fast-user-switch applet to the top right corner and removes the quit button object
<liw> mvo, how does it do that? that still requires talking to the users gconf, doesn't it?
<mvo> liw, yeah, its a two stage process. the notification is generate during the postinst of the gnome-panel (on upgrade) and copied into /var/lib/update-notifier/user.d - that is a directory where update-notifier checks for user notification that are releated to package upgrades. they are shown for each user and can have scripts attaached to them
<mvo> liw, htere is a InteractiveUpgradeHooks wiki page with more information
<mvo> liw, its a somewhat underutilized feature, but quite useful for cases like this
<TomaszD> pitti, hey. People from #launchpad forwarded me to you, could you check what is wrong with cheese's translation template? no pending updates, last ones failed months ago.
<pitti> TomaszD: you mean the package doesn't build one/
<pitti> ?
<TomaszD> pitti, https://translations.launchpad.net/ubuntu/intrepid/+source/cheese/+imports
<pitti> Building cheese.pot...
<pitti> the package seems to be fine
<seb128> "Wrote cheese.pot"
<seb128> right, the build log suggests it builds it correctly
<pitti> TomaszD: right, that seems to indicate that the help templates are not imported (since they aren't shipped in langapcks); that seems to be correct?
<TomaszD> hmm, seems to be working fine indeed
<TomaszD> sorry for the false alarm
<TomaszD> I've got just one more package to check
<TomaszD> bluez-gnome
<TomaszD> there is this new version out, templates approved 8 days ago
<TomaszD> but still not uploaded
<TomaszD> is this something of concern
<TomaszD> or just patience?
<TomaszD> pitti, ?
<seb128> TomaszD: that would be a rosetta question
<pitti> TomaszD: latest intrepid packages are from a 20081011 export, so it might just have missed it
<seb128> TomaszD: if the build update the template the ubuntu job is done basically
<TomaszD> oh, but did the build update the template? how can I be sure?
<seb128> TomaszD: look to the build log?
<seb128> TomaszD: http://launchpadlibrarian.net/18301573/buildlog_ubuntu-intrepid-i386.bluez-gnome_1.8-0ubuntu1_FULLYBUILT.txt.gz
<TomaszD> well it did update the template
<TomaszD> lp can be really terrible to navigate
<tseliot> liw: see if you can test what I suggested here (I talked to mvo about this): https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/278963
<ubottu> Launchpad bug 278963 in fglrx-installer "fglrx kernel module crashes system hard during hardy to intrepid upgrade" [Critical,Confirmed]
<lool> tjaalton: Hey, I see we have xserver-xorg-video-openchrome 1:0.2.903-0ubuntu2, but I don't see any ubuntu branch in git.debian.org:/git/pkg-xorg/driver/xserver-xorg-video-openchrome.git
<lool> tjaalton: perhaps you need to push the new branch explicitely?
<liw> tseliot, yeah, I will. I'll start the upgrade once I don't need the desktop machine anymore today (tonight at the latest)
<jcristau> lool: not all the ubuntu xorg stuff is in git. i think openchrome isn't
<tseliot> liw: thanks a lot :-)
<lool> ok, it has a vcs-git though
<liw> tseliot, argh, no, I forgot: I had some hardware trouble (a case's power button broke), so I had to swap hard disks to another computer; I'll fix the original computer and then re-try the test (still hopefully tonight, but might only happen tomorrow)
<lool> ah, I kept xserver-xorg-video-via on upgrades but it's not built in intrepid anymore
<liw> (hardware is the nemesis of progress)
<tseliot> liw: ok, thanks
<NCommander> morning seb128
<seb128> hello NCommander
<NCommander> seb128, how goes it?
<seb128> NCommander: got a cold but other good, you?
<NCommander> seb128, celebrating my 50th upload to the archive :-)
<seb128> good ;-)
<seb128> time for motuing? ;-)
<Koon> mvo: about the screensaver issue, reenabling something equivalent to your sledgehammer.diff from bug 145123 fixes it here.
<ubottu> Launchpad bug 145123 in gnome-screensaver "Keyboard shortcut works even when the screen is locked" [High,Fix released] https://launchpad.net/bugs/145123
<NCommander> I've been told to wait for DIF Jaunty
 * NCommander will be at UDS it seems
<seb128> NCommander: oh, I though you couldn't go to this one?
<NCommander> I managed to clear my schedule
<mvo> Koon, possible, if I can not come up with a better solution, its time for the sledgehammer again :)
<Koon> mvo: will post fix and PPA it for more testing if you want
<NCommander> After someone (and I have no idea who) put me down on the list for sponsorship
 * NCommander managed to call in a last minute favor
<mvo> Koon, could you show me the diff please?
<NCommander> seb128, so yes, I'll be at UDS :-). I look forward to meeting you and the rest of ubuntu-*
<NCommander> and kubuntu-* and xubuntu-*
<seb128> NCommander: good ;-)
<ogra> mvo, Koon, either xset -dpms, reoving gpm or switching off the mentioned compiz setting fixes the issue
<Riddell> NCommander: great
<Koon> ogra: xset -dpms doesn't fix it here
<Koon> (or I missed something)
<pitti> tkamppeter: sorry, I forgot the status about that: does openprinting.org have any packaged PPD files?
<ogra> Koon, bug 278112, right ?
<directhex> dholbach, can you check the integrity of your /tmp? i've run amd64 intrepid builds of mono on multiple systems without seeing the error you mention
<ubottu> Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112
<Koon> ogra: yes
<asac_> calc: thanks for the abrowser fix
<ogra> Koon, intel graphics ?
<dholbach> directhex: what do you want me to test?
<Koon> ogra: or nvidia.
<dholbach> directhex: /tmp seems to be working nicely
<directhex> dholbach, what's the md5sum of the mono-1.9.1+dfsg/mcs/mcs/cs-parser.jay being used for that build? i really can't reproduce a build failure
<Koon> mvo: for the diff, just a sec
<dholbach> directhex: let me try it again, will let you know in a sec
<Koon> mvo: http://pastebin.ubuntu.com/57826/
<mvo> Koon, heh :) ok- thanks
<Koon> it's just a refresh of your old sledgehammer :)
<mvo> yeah
<mvo> I remember that one
<Koon> will post it as proper debdiff on the bug + PPA it so that people on the bug can test it
<mvo> the original bug (in X) that made it required in the first place got fixed
<mvo> Koon, excellent, thanks
<tjaalton> lool: it's not in git at all
<tjaalton> lool: our changes to openchrome I mean
<tkamppeter> pitti, packaged PPD files will come soon, at least one manually created package. Have you any preference of printer brand?
<ogra> Koon, mvo, for me the prob happens with gnome-screensaver uninstalled as well
<mvo> ogra, intel?
<ogra> yep
<ogra> unchecking the option in gnocf helps though
<ogra> *gconf
<ogra> as well as xset -dpms (which doesnt seem to help Koon though)
<doko> bryce_, tjaalton, infinity: any idea why xfb-run fails on the buildds on sparc and powerpc? see the recent openjdk-6 build log
<tjaalton> doko: I understand the new xorg-server that lool uploaded should fix that
<jcristau> tjaalton: don't think so. it just makes error output work.
<tjaalton> jcristau: ok
<davmor2> mvo: \o/ Yay works Dude :)
<mvo> davmor2, excellent!
<lool> tjaalton: ok thanks
<lool> tjaalton, bryce_: I moved the ppa-only xserver-xorg-video-psb to xsfbs; it now has correct provides, so wont need new special conflicts in the future; only the one I added is needed
<dholbach> directhex: builds nicely now
<directhex> dholbach, gremlins, then?
<dholbach> directhex: no idea :)
<mvo> davmor2, when you get tomorrows daily alternate CD, could you do a cdrom release upgrade with it please?
<ogra> oh, pitti that gdm fix could also have pointed to gdm-cdd.conf as well :)
<lool> ogra: hmm openchrome will need a Pas tweak unfortunately
<lool> ah ECHAN
<lool> tjaalton, bryce_: I synced the latest vars.i386 cleanup into vars.lpia, hence the new xorg upload
<lool> (and I should be mostly done fiddling with xorg now  O:-)
<lool> I might chase that xvfb issue on big endian arches now if qemu supports one, such as ppc
<pitti> ogra: argh, too many files...
<ogra> :)
<ogra> pitti, well, not to important, i just saw the changelog entry
<james_w> Keybuk: hi, bug 256216 looks sensible to me, am I missing something?
<ubottu> Launchpad bug 256216 in librdmacm "Ubuntu is missing /dev/infiniband/rdma_cm group ownership udev rule" [Undecided,New] https://launchpad.net/bugs/256216
<directhex> people run ubuntu on clusters?
<lool> tjaalton, bryce_: dropping vcs-* from -intel as well, didn't find ubuntu branch in git.d.o
<unggnu> hi all
<unggnu> I just wanted to know if the Adobe Flash Ubuntu package is maintained through the Ubuntu devs and if so will it be considered while e.g. upgrading to Intrepid?
<directhex> yes, yes, and wrong channel.
<unggnu> It seems to have a different package naming than the standard one
<unggnu> ok, thx
<mvo> evand, so gobuntu-desktop is now gone in intrepid, right? what should the upgrader do for people who have it installed (and no other meta-package)?
<kelemengabor> hi mvo
<mvo> hey kelemengabor
<kelemengabor> what's the schedule for publishing the ddtp descriptions's updates?
<kelemengabor> I mean, tomorrow is non-langpack freeze
<kelemengabor> and they will be published on the servers, but after that?
<kelemengabor> we have currently lots of pending translations and would be really nice to see them later in Intrepid
<kelemengabor> is there any public schedule/plan at all?
<rainct> Will OO.o 3.0 from https://launchpad.net/~openoffice-pkgs/+archive get into Intrepid?
<Hobbsee> rainct: not for release.
<rainct> Hobbsee: and as an update? or hasn't that been decided yet?
<Hobbsee> rainct: possibly.  currently undecided
<rainct> Ah. Well, anyway, if some of the maintainers is around: I've been told that the Catalan translation of the documentation is missing
<Hobbsee> calc: ^
<lool> jcristau: Weird, there are two entries in Pas for xorg-intel: one for binary and one for source; not quite sure how this works to decide building sources
<lool> Looks like launchpad and wanna-build have two different interpretations
<tjaalton> lool: is it necessary to remove those tags?
<ogra> oh, console-tools confolcts with ubuntu-minimal now ?
<lool> tjaalton: I don't know; the !s390 entry looks funny if you ask me, but I filed a bug on soyuz
<lool> bug #283731
<ubottu> Launchpad bug 283731 in soyuz "P-a-s interepreted differently in Debian and Ubuntu" [Undecided,New] https://launchpad.net/bugs/283731
<BenC> cjwatson: linux-restricted-modules (sans firmware), linux-firmware and linux-meta (with linux-image-foo deps on linux-firmware) are being uploaded now
<BenC> cjwatson: FYI, nic-restricted-firmware => nic-firmware
<tjaalton> lool: I meant the Vcs-* tags :)
<lool> tjaalton: Well we don't use this Vcs, so it's confusing for ubuntu developers; for instance apt-get source will complain, and debcheckout will do the wrong thing
<lool> tjaalton: but if you ask me, we should just use git repos; would make merging painless
<tjaalton> lool: yeah
<liw> hmm, X has frozen twice for me today.
<tjaalton> liw: fglrx?
<liw> tjaalton, should not be, should be the free driver
<tjaalton> liw: ok
<liw> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
<liw> [mi] mieqEnequeue: out-of-order valuator event; dropping.
<liw> tjaalton, there's a lot of that in Xorg.0.log
<BenC> cjwatson: all uploads complete
<BenC> cjwatson: linux-firmware is the only one that needs handling
<tjaalton> liw: ok.. there's a patch which dumps the trace when that happens. would be better than nothing to aid debugging it
<liw> tjaalton, can I do something before I reboot to regain control of the machine? (first time it happened, restart X did not help)
<tjaalton> liw: probably not
<liw> tjaalton, this patch, how would I use it?
<tjaalton> liw: patch the server and build it
<tjaalton> liw: http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.5.2-mieq-backtrace.patch?revision=1.1
<liw> tjaalton, ok, I'll give that a try later
<tjaalton> liw: great, thanks
 * ogra doesnt understand ow he can end up having console-tools, console-setup and kbd installed at the same time on his laptop 
<ogra> trying to install conaole-setup and -tools on a thin client results in removal of kbd :/
<ogra> hmm, and installation of libconsole
<Hobbsee> ogra: you installed them all before the conflicts were set?
<ogra> when did that hapen ? the client build is from friday
 * ogra checks -changes
<ogra> no
<cjwatson> BenC: thanks
<ogra> my prob is that recommends break the thin client chroots so it omits them, apparently the console stuff is resolved through recommends normally
<cjwatson> ogra: the conflicts were set eons ago
<cjwatson> ogra: also, ubuntu-minimal Depends: kbd, not Recommends
<ogra> cjwatson, right, but i dont get why i have all three installed on my laptop and am not able to install them on a thin client
<cjwatson> ogra: I don't get how you have them all installed on your laptop; the latter is expected
<cjwatson> hardy => console-setup + console-tools; intrepid => console-setup + kbkd
<cjwatson> kbd
<ogra> ooooh
<ogra> illy me
<ogra> i looked at the initscripts :)
<cjwatson> ah
<cjwatson> purge console-tools ;-)
<ogra> yeah
<cjwatson> mvo: excuse my command-not-found upload, just trying to hoover up some bugs I found
<cjwatson> it's all in bzr
<mvo> thanks cjwatson
<stefanlsd_> mm. i wish people did specific vcs commits more often.
<rainct> mvo: btw, a  try: .. except KeyboardInterrupt: sys.exit(1)   in command-not-found wouldn't hurt :P
<stefanlsd> trying to pull security updates out of a commit which includes a bunch of feature stuff.
<emgent> hello
<rainct> hi emgent
<cjwatson> seb128,pitti: did either of you have any thoughts about my proposal to turn totem content acquisition plugins on by default?
<pitti> cjwatson: I don't think I saw that proposal?
<cjwatson> pitti: sent by mail
<cjwatson> Subject: Re: BBC: New code drop?
<seb128> cjwatson: only if the download happens when selecting the plugin in the combo and not when totem starts
<cjwatson> on Fri 10
<cjwatson> seb128: right, Collabora are going to be working on that RSN
<cjwatson> seb128: is it feasible/sane/acceptable otherwise?
<cjwatson> I agree that ought to be a blocker
<pitti> argh kyboard fail, rboot, brb
<seb128> cjwatson: I forget to reply to the mail, I was in a rush before the weekend and it forgot to keep it unread to reply then
 * cjwatson nods
<seb128> cjwatson: but otherwise I agree with what you wrote
<cjwatson> good thing I checked if pitti didn't see it though :)
<seb128> cjwatson: I think it's a good idea if they manage to fix that
<cjwatson> seb128: is it a fairly trivial switch to flip in gconf?
<seb128> cjwatson: add a debian/totem-common.gconf-defaults which has "/apps/totem/plugins/bbc/active true"
<cjwatson> and youtube presumably
<cjwatson> ok
<evand> mvo: tough call as they wont want any non-free software
<seb128> cjwatson: right
<cjwatson> mvo: ask them if they want to disable restricted if it isn't already, maybe? install abrowser rather than firefox?
<ogra> hmm
<seb128> cjwatson: btw the bbc plugin displays a "could not connect to server" in the playlist at the moment for me, is that a known issue?
<evand> mvo: but I guess we shouldn't leave them in a poor state, so perhaps s/gobuntu-desktop/ubuntu-desktop?
<ogra> why is discover1 in main (or discover-data in universe) ?
<cjwatson> seb128: worked for me just now
<ogra> discover1 Depends: discover1-data
<ogra> oh
<ogra> sigh, i guess i need glasses
<seb128> cjwatson: do you use the same server is the uk that in other countries?
<cjwatson> ogra: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/rdepends/ALL/discover1 says ltsp-client-core
<cjwatson> oh, you meant that, ok
<ogra> is that all thats keeping it in main ?
<cjwatson> ogra: yes
<ogra> do we want to get rid of it ?
<cjwatson> seb128: yes, any filtering is supposed to be handled server-side by geoip
<cjwatson> ogra: if possible, yes
<ogra> i think its only there because mdetect used to use it
<pitti> argh, e ky is still brokn
<seb128> 0:00:01.897669340  7415  0x80a4490 WARN                python contentview.py:672:_query_done_cb: Could not query http://open.bbc.co.uk/rad/uriplay/availablecontent: Error while getting mount info: Invalid reply
<mvo> evand, hm, I may just do that
<seb128> 0:00:01.897778225  7415  0x80a4490 WARN                python contentview.py:793:_on_content_pool_error: Failed to load available content: Could not connect to server
<seb128> cjwatson: that the gstreamer debug log
<pitti> cjwatson: I didn't s33 it, I wond3r wh3r3 it w3nt, looking
<seb128> oh
<cjwatson> seb128: can you open that url in a browser?
<cjwatson> it should be a pile of rdf
<davmor2> mvo: afk.  Any preference on what from hardy/gutsy/dapper for the upgrade?
<pitti> cjwatson: last mail I got was from 12.09.08, and containd python-rdflib
<seb128> cjwatson: yes, works fine in firefox
<cjwatson> pitti: it was sent to Martin Pitt <martin.pitt@ubuntu.com> - shall I bounce it?
<pitti> cjwatson: plas
<cjwatson> seb128: odd, maybe transient
<cjwatson> ?
<pitti> argh
<cjwatson> done
<pitti> lt m sort out my kyboard, bbl
<seb128> cjwatson: seems that I managed to confuse gvfs rather, gvfs-cat on the mount doesn't work either
<seb128> brb restarting session
<mvo> davmor2, hardy->intrepid with cd please
<davmor2> mvo: NP's
<Keybuk> james_w: we're attempting to get rid of groups like "rdma" which are for device access only
<davmor2> mvo: should the tabs look like this http://www.davmor2.co.uk/cli.png
<james_w> Keybuk: does that require modifications to the applications that want to access the devices?
<Keybuk> james_w: yes, in some cases. they would use a D-Bus backend to access the device and authorise through PolicyKit
<Keybuk> otherwise we can always provide implicit "at console" authorisation through HAL's PolicyKit backend
<mvo> davmor2, the gnome-terminal tabs?
<davmor2> mvo: yes
<james_w> Keybuk: is rdma going to be a good subject for that?
<Keybuk> james_w: who should have permission to access rdma devices?
<Keybuk> what _is_ rdma?! :p
<james_w> I have no idea :-)
<james_w> Keybuk: I'll ask for some more details in the bug, unless you want to do it. I'm sure you will ask more insightful questions.
<Keybuk> there tends to be a pattern upstream of "just create a gnomovision group" when dealing with permissions
<MacSlow> greetings everybody
<seb128> cjwatson: ok, it's working now, I managed to screw gvfs by running non matching gvfs and libgvfscommon versions while doing some testing
<Keybuk> james_w: commented, though I can't unsubscribe the sponsor team
<james_w> Keybuk: thanks, I can do that
<davmor2> mvo: sorry closed the wrong window.  Should the tabs on terminal be transparent?
<stefanlsd> crimsun: you around?
<mvo> davmor2: hm, no
<doko> ubuntu-archive: please process xorg-xserver binaries in NEW. breaks installation of xvfb
<seb128> doko: looking
<seb128> doko: accepted
<doko> thanks
<Keybuk> liw: "python-fstab" ?!
<Keybuk> *please* don't tell me that parses it itself
<ogra> it probably rewrites it more beautifully :P
<liw> Keybuk, it does, in order to be able to write it back without losing comments, etc
<ogra> with flowers and decoration
<Keybuk> liw: but how many of the corner cases of that file do you handle?
<Keybuk> read the glibc implementation of getfsent() - it's *complicated* to parse
<tseliot> ogra: and this is why we have decorators in Python
<liw> Keybuk, everything I could think of, based on the manpage spec for the format of the file
 * tseliot hides away
<Keybuk> it's just just "non-space chars" "space chars" "non-space chars"
<Keybuk> ie. do you cope with spaces in the mount point name?
<ogra> tseliot, ah, i knew they were useful for something :)
<liw> Keybuk, fstab(5) says tabs and spaces separate fields; do you have a better spec?
<Keybuk> liw: I don't think there's a spec; getfsent() etc. is the canon way to read that file
<liw> Keybuk, they don't seem to allow _writing_ it
<Keybuk> no, sadly not
<lool> tjaalton, bryce_: hmm tested new xorg on jax10; a PCI id needed to be added; pushing a new xorg-server as a result; also merged the xvfb-run patch in git, makes more sense IMO if patches are for upstream changes only
<Keybuk> certainly not rewriting it
<cjwatson> you can write spaces in the mount point name using %40
<Keybuk> cjwatson: and \040 and \x20 and "\ " etc.
<cjwatson> I don't think "\ " is reliable
<cjwatson> I'm sure I tried that last time I needed to figure it out and it didn't work
<Keybuk> it's unreliable in that the silly repeated shell in our init scripts will choke on it ;P
<Keybuk> it probably won't get mounted :p
<cjwatson> Keybuk: seems sort of important :)
<liw> the libc code does not seem to support escaping a space with a backslash; it splits a line based on spaces and tabs and then decodes those
<liw> where decoding un-escapes certain things
<tjaalton> lool: hmm, you mean that our changes should poke the code directly?
<lool> tjaalton: xvfb-run is in debian/
<lool> tjaalton: So it's like our debian/control changes
<tjaalton> lool: oh, heh
<Keybuk> liw: ah, I could be mistaken there then
<tjaalton> lool: yep, got that right. the patch was old
 * ogra wonders where all these segfault messages in his dmesg for firefox come from
<ogra> FF is definately not crashing or something
<ogra> firefox[24482]: segfault at b794fa9e ip b7c8d571 sp bff2f0a4 error 4 in libc-2.8.90.so[b7c5f000+158000]
<\sh> bryce_: thx for the new ati working crack :) I wonder how much you paid for that to amd ;-)
<ogra> a truck of beer :)
<\sh> ogra: that's cheap ;)
<ogra> \sh, do i see you on the weekend ?
<\sh> ogra: where?
<ogra> \sh, its UBUCON !!!! man, you guys are so uninformed down there in the south
<\sh> ogra: ah ubucon...no, sorry...
<ogra> http://ubucon.de/index.php
<calc> crap, i forgot a line of code in rules that broke i386 build :(
 * calc kicks himself
<calc> at least powerpc works now :)
<kwwii> \sh doens't really live in the south, or?
<\sh> kwwii: karlsruhe is more south then cologne ;)
<\sh> kwwii: but not as south as bamberg, right?
<kwwii> \sh: *exactly*
 * ogra looks from kassel and notes that *most* of germany is south
<kwwii> lol
 * kwwii should take another trip to see ogra ;-)
<ogra> :)
<\sh> kwwii: if you do, just come to karlsruhe and hijack me ,-)
<\sh> kwwii: if you go to kassel I mean...
<\sh> or I'll plan visiting ogra around xmas time...when I hopefully have some days off from work
<\sh> kwwii: the "bamberg" next to wÃ¼rzburg"? then karlsruhe is more south ;)
<maswan> \sh: are you in karlsruhe?
<lool> liw: mir acked for systme-cleaner
<liw> lool, cool, I was just about to ask you. thank you
<\sh> maswan: yes
<maswan> \sh: Ok, cool. I might ping you closer to january, I might be visiting.
<liw> hmm, trying to eject a cd from the drive: it gets ejected and then immediately pulled back in and mounted again
<\sh> maswan: try to make it around the 11th :)
<maswan> \sh: Unfortunately I'm not the one scheduling it. :)
<\sh> maswan: much better around the 10th and we can celebrate into my birthday ,-)
<maswan> \sh: hehe. good plan.
<\sh> maswan: you are not visiting the university here in KA?
<Riddell> dholbach: I've removed the triaged packages in bug 283543, do you know a clever way to close all those entries?
<ubottu> Launchpad bug 283543 in knetload "archive removal request: wlassistant is uninstallable due to kicker being dropped" [Undecided,Fix released] https://launchpad.net/bugs/283543
<dholbach> hang on :)
<maswan> \sh: FZK which is now KIT or something like that
<dholbach> Riddell: "An internal server error occurred. Please try again later." :-/
<Riddell> aww
<dholbach> Riddell: bug basically http://paste.ubuntu.com/57928/
<dholbach> but
<dholbach> thekorn: do you know why http://paste.ubuntu.com/57928/ could fail?
<sistpoty|work> dholbach: karma overflow? *g*
<dholbach> sistpoty|work: that might be :)
<dholbach> commiting each individual change does not work either :-/
<ogra> asac, its a fn key combo, i dont have a HW switch
<rainct> dholbach: here it worked
<dholbach> rainct: great
<asac> ogra: ok. that works for me too i think
<asac> ogra: hardware thing was broken. i will verify latest fix by slangasek
<ogra> [104163.897885] iwlagn: Radio Frequency Kill Switch is On:
<ogra> [104163.897890] Kill switch must be turned off for wireless networking to work.
<ogra> [104169.336140] wlan0: No ProbeResp from current AP 00:14:6c:e5:f7:ef - assume out of range
<ogra> [104176.983910] Registered led device: iwl-phy0:radio
<ogra> [104176.983969] Registered led device: iwl-phy0:assoc
<ogra> [104176.984036] Registered led device: iwl-phy0:RX
<ogra> [104176.984066] Registered led device: iwl-phy0:TX
<ogra> [104176.994772] wlan0: authenticate with AP 00:14:6c:e5:f7:ef
<ogra> thats the dmesg for switching off and on once
<slangasek> ogra: and does NM keep pace when you toggle it?
<ogra> oh, wait, i didnt check NM ... only noticed the slack meter in xchat went to 100%
 * ogra tries again
<rainct> Uhm.. Epiphany's URL bar currently has "search the web (ie, google)" and "debian BTS". Shouldn't we add LP Bugs?
<ogra> yup
<ogra> its not really immediate, but does what it should after a bit delay
<slangasek> right
<slangasek> then I think the real issue in there is the one bdmurray identifies, that if you boot with the rfkill switch on, you can never associate
<rainct> seb128: ^
<ogra> ah, well, i never tried that, i'm not even sure that would work with the fn key combo my lappie uses
<slangasek> ogra: oh, I read you backwards; yeah, if you don't have a hw kill switch, nevermind
<Riddell> mvo: that update notification from gnome-panel is surprisingly confusing when popping up on a non gnome desktop
<ogra> get a gnome desktop then :)
<seb128> rainct: what?
<mvo> Riddell: hm, we need a "per-desktop" swithc maybe
<rainct> seb128: if I add Ubuntu & LP bookmarks to Epiphany (browser), will you sponsor that?
<mvo> Riddell: but seriously, I think we can fix that
<Riddell> mvo: yeah I've no paticular suggestions on how to improve it, a OnlyShowIn= key maybe, also s/your Quit button/the Ubuntu Quit button/ might help
<seb128> rainct: there is already such bookmarks?
<rainct> seb128: nope, only Debian and GNOME
<thekorn> dholbach: let me check
<dholbach> thekorn: seems it worked out for rainct - nevermind :)
<dholbach> thekorn:  it was a LP failure
<seb128> rainct: bug #137491
<ubottu> Launchpad bug 137491 in epiphany-browser "epiphany does not have launchpad customizations by default" [Wishlist,Fix released] https://launchpad.net/bugs/137491
<thekorn> dholbach: okay
<dholbach> thekorn: might have been a too-old cookie too
<dholbach> *shrug* :)
<seb128> rainct: seems that the intrepid version didn't get the change, will fix that
<siretart> is there some hickup with archive.u.c?
<thekorn> dholbach: you should start using launchpadlib for such things, it's much more comfortable ;)
<mvo> siretart: I was wondering the same
<dholbach> thekorn: I slowly have to get used to it :)
<rainct> seb128: OK :). I'd change the "Ubuntu Bugs" one to "Launchpad", though
<slangasek> bdmurray, mdz: please confirm whether you're still having any problems with bug #193970; I'm optimistic that the hal change is all that was needed to fix this
<ubottu> Launchpad bug 193970 in linux-ubuntu-modules-2.6.24 "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Undecided,Confirmed] https://launchpad.net/bugs/193970
<seb128> rainct: feel free to raise the topic for discussion on the lists
<lool> tjaalton, bryce_: noticed an error being printed on console during upgrade on my crownbeach in xserver-xorg-core; shouldn't confuse debconf, but there's a risk so I prefer pushing
<seb128> rainct: I'm just going to use the hardy patch for now
 * lool needs to cut on xorg-server uploads lalala
<bdmurray> slangasek: Alright, I'll test today.
<slangasek> thanks :)
<mdz> slangasek: can do
<seb128> lool: and you need to start using -v so people reading -changes know what debian changes you backported ;-)
<rainct> seb128: if it's that one from the patch on the bug, does it even work?
<cjwatson> bryce_: there's another task on 185311 which is still targeted, btw - pygtk
<seb128> rainct: no, I didn't use the debdiff on the bug, try on hardy
<rainct> seb128: oh ok, because there's a %s missing there :)
<cjwatson> bryce_: ah, thanks, you sorted it
<bryce_> cjwatson: yep, in fact was just looking into that
<lool> seb128: Bah I could have included more, but it's completely confusing because an old Debian entry moved around
<pitti> tjaalton, bryce_: http://gitweb.freedesktop.org/?p=mesa/mesa.git gives me "no such directory"; do you happen to know a working gitweb for mesa?
 * lool should start a wider discussion about best practices on the debian/changelog merging front
<bryce_> cjwatson: I'm quite tempted to break out all the remaining issues as separate bugs.  The original issues are long since gone, and the current remaining ones just got me-too'd onto it.  Well, something to look at for jaunty I guess.
<cjwatson> I'm all for small, focused bugs
<bryce_> pitti: checking
<bryce_> pitti: hmm should work - see http://www.mesa3d.org/repository.html for full directions
<pitti> bryce_: that's what I was looking at
<pitti> bryce_: I wanted to provide a gitweb URL to bug 283175 (and for the SRU changelog)
<ubottu> Launchpad bug 283175 in mesa "Intel i915 cannot swizzle TEX arguments" [Unknown,Fix released] https://launchpad.net/bugs/283175
<bryce_> pitti: ah, use cgit.freedesktop.org
<bryce_> pitti: they took down gitweb because it got too slow; guess the mesa docs didn't get updated
<pitti> bryce_: ah, I didn't know that; anyway, http://cgit.freedesktop.org/?p=mesa/mesa.git gives me the same error
<bryce_> pitti: ok, fdo infrastructure goes down a lot, maybe it's just one of their typical outages
<pitti> bryce_: anyway, WDYT about that SRU request? sounds like a new feature, but I can't say at all whether it is important
<bryce_> pitti: I've mentioned the dns or whatever issue on #xorg-devel
<bryce_> <ajax> there's an apache suicide script that runs on annarchy when the load gets too high
<bryce_>  should be back up shortly
<pitti> bryce_: fun, that causes errors like "no such path"? ok, thanks for poking
<bryce_> pitti: I must have missed the link in the scrollback - bug id please?
<pitti> bug 283175
<ubottu> Launchpad bug 283175 in mesa "Intel i915 cannot swizzle TEX arguments" [Unknown,Fix released] https://launchpad.net/bugs/283175
<bryce_> fdo looks back up btw
<ogra> tjaalton, bryce_ was there any outcome for teh nsc driver yesterday ?
<ogra> its still failing here (and for lool as well)
<pitti> bryce_: swell, works now; thanks
<bryce_> pitti: 283175> it includes an API change, are you certain it's safe?
<pitti> bryce_: not at all; I have NFC about what "swizzling a TEX argument" is
<bryce_> me either
<bryce_> well, it adds a calling arg to i915_emit_texld(), so unless this code is the only place where that API is called I think it could cause breakage in other things
<pitti> right, I asked the same thing in the bug
<bryce_> ok reading
 * bryce_ comments there
<lool> ogra: I think I only dropped -nsc from video-all yesterday; there should also be a breaks in palce somewhere, dunno why there's not
<lool> ogra: Might not have been in todays images
<ogra> ah
<ogra> well, i thought tjaalton and jcristau were working on getting a git fix in
<ogra> but i might have gotten that wrong
<lool> dunno
<Hix-2> morning yall
<doko> slangasek: well, jaunty can't be yet targeted
<bryce_> pitti, heh, if I google "swizzle TEX" I get our launchpad bug.  Guess we can both be forgiven for having no idea what this guy's talking about.  ;-)
<slangasek> doko: yes, but the bug shouldn't be targeted to 'intrepid' either then :)
<ogra> doko, i use "later"
<slangasek> ogra: targets, not milestones
<doko> slangasek: how can a target be undone?
<ogra> ah
<bryce_> pitti: ok wikipedia to the rescue - http://en.wikipedia.org/wiki/Swizzling_(computer_graphics)
<geser> jdong: Hi, about the jhead security bug: have you had already time to look at the new jhead version?
<slangasek> doko: for a stable series, fix released or wontfix; for a devel series, wontfix
<doko> slangasek: not a solution for me, it's not on my radar anymore in the bts
<slangasek> doko: (if you look at the bug state now, you'll see there's a status for 'intrepid', but also one for Ubuntu without a target)
<slangasek> doko: why not?
<bugabundo_work> jdstrand: ping
<doko> slangasek: ohh, I see
<jdstrand> bugabundo_work: yes?
<bugabundo_work> hi
<jdstrand> hi
<bugabundo_work> about that pidgin LP bug
<bugabundo_work> with a pass on the log?
<bugabundo_work> lol
<bugabundo_work> 274380
<bugabundo_work> which account was it?
<bugabundo_work> do you know?
<bugabundo_work> so I can protect my self and change it
<jdstrand> bugabundo_work: I stripped out the password and reuploaded the log
<bugabundo_work> still
<bugabundo_work> other users were notified
<jdstrand> before marking it public
<bugabundo_work> and might have access to it
<bugabundo_work> I want to safe guard my self
<bugabundo_work> as you understand
<jdstrand> sure
<bugabundo_work> didn't know pidgin crash logs would send passwords in the clear
<bugabundo_work> :(
<tjaalton> ogra: the package we have already includes the pciaccess-patch from upstream, but it was made blindly. so, someone with the hardware should fix it :)
<ogra> ah
<ogra> well, i wont have time to do that before freeze
<ogra> oh, wait and i only have gode HW ... no nsc
<geser> jdstrand: Hi, about bug 271020: would it be a good idea to contact the Debian Maintainer and the Debian Security Team about the issue?
<ubottu> Bug 271020 on http://launchpad.net/bugs/271020 is private
<geser> jdstrand: it's the jhead security bug
<jdstrand> geser: yes, as it's now public, I'll mark the bug public too
<ogra> cjwatson, bug 283861 look like its worth to have in intrepid
<ubottu> Launchpad bug 283861 in oem-config "Wrong time zone defaults for some countries" [Undecided,New] https://launchpad.net/bugs/283861
<ogra> *looks
<bdmurray> slangasek: I still had to use the workaround in bug 193970
<ubottu> Launchpad bug 193970 in hal "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed] https://launchpad.net/bugs/193970
<slangasek> bdmurray: "the workaround" -> "rmmod && modprobe"?
<bdmurray> slangasek: yeah
<slangasek> ok :/
<slangasek> bdmurray: before you do the rmmod, does iwlist scanning return any results?
<slangasek> that would pin down whether this is truly a driver bug, vs. a hal issue
<bdmurray> slangasek: No iwlist scan does not return anything and I see "iwl3945: MAC is in deep sleep!" after deactivating the kill switch
<ogra> sounds like kernel then
<slangasek> ok
<ogra> do you have yesterdays kernel ?
<ogra> iirc there were some firmware updates
<ogra> but meta seems to be not there yer
<slangasek> bdmurray: can you follow up to the bug report with this info, then?  I'll close the hal task
<ogra> *yet
<slangasek> ogra: er?  there was no new linux ABI yesterday
<slangasek> 2.6.27-7 is current, and meta already points to itt
<ogra> slangasek, see the lrm changelog, at least something changed
<pitti> slangasek: do you have an opinion about the proposed xml-core pre-depends? (on u-devel@); it's for an RC bug, so I'd rather settle it sooner than later
<slangasek> ogra: ok, but why does that involve meta?
<ogra> slangasek, and there was  2.6.27-7.11
<slangasek> pitti: hrm, let me go back and look
<bdmurray> ogra: 2.6.27-7.11
<ogra> well, u-m cleary wanted to remove linux-image-generic here
<slangasek> ... that's not normal, even during an ABI change
<slangasek> sounds like you've got something wrong locally
<ogra> linux-meta (2.6.27.7.9) intrepid; urgency=low
<ogra>   * linux-image-<flav> now depends on linux-firmware for upgrades
<mdz> slangasek: I still don't see an event from hal when I flip the kill switch
<jdstrand> jdong: fyi-- requested CVEs for jhead and CC'd you, so you can respond if there are any questions
<slangasek> mdz: ok.  hmm, and it seems I can confirm the can't-recover-from-kill-switch behavior here, which I wasn't able to previously
<ogra> slangasek, might it be that linux-firmware sits somewhere in NEW ?
<mvo> ogra: I see this too, looks like linux-firmware needs to go through NEW
<ogra> snap :)
<slangasek> ogra, mvo: yep, apparently
<cjwatson> ogra: oem-config> thanks for the heads-up, we'll look at that
<Awsoonn> is there a timeline for OOO3 to be uploaded?
<cjwatson> Awsoonn: after Oct 30
<cjwatson> Awsoonn: i.e. not for intrepid, sorry
<cjwatson> I posted a detailed explanation on whatever bug report it was, as did calc
<Awsoonn> cjwatson: thanks
<sbeattie> TheMuso: is bug 275233 related to or the same as bug 274124?
<ubottu> Launchpad bug 275233 in libcanberra "canberra-gtk-play crashed with SIGSEGV in pa_operation_unref()" [Medium,Confirmed] https://launchpad.net/bugs/275233
<ubottu> Launchpad bug 274124 in alsa-plugins "Race condition in pulseaudio loading for GNOME session" [Undecided,Fix released] https://launchpad.net/bugs/274124
<heno> TheMuso: could you join #ubuntu-meeting?
<sebner> TheMuso: does your jailbreak also works for the new ipodtouch2?
<pitti> okay, with that f-spot upload digicam handling should be back to sanity; now off to Taekwondo, see you all tomorrow!
<slangasek> gstreamer0.10-packagekit
<slangasek> ... what
<slangasek> is that a source or a sink for gstreamer? :P
<tedg> slangasek: apt-get netflix wizard-of-oz
<james_w> slangasek: codec installer alternative, sorry, I forgot it would hit NEW
<slangasek> james_w: ah, weird
<sebner> james_w: do we already have intrepid-security?
<james_w> sebner: I don't think so, there's no need for it, just target intrepid for that upload
<sebner> james_w: with -ubuntu2 or -ubuntu1.1 (CVE-fix) ?
<james_w> ubuntu1
<james_w> er ubuntu2
<sebner> kk thx
<kees> sebner: technically, the repository exists (i.e. you can add it to your sources.list without error) but it will be empty until intrepid releases.
<sebner> kees: ah, k
<emgent> evening people :)
<sebner> emgent: \o/
<calc> Awsoonn: it is however in the ppa already
<Awsoonn> calc what ppa? is there a wiki page for installing it yet?
<ogra> superm1, hey, typig from my BT freedomkeyboard, apart from my GPS reciever all BT devices work with a different dongle with bluez 4.x now
<superm1> ogra, that's awesome :)
<ogra> yeah
<superm1> ogra, do you know what was wrong with the old dongle?
<ogra> sad though that the gps doesnt work
<ogra> some weird very old MSI thing
<superm1> ogra, if i remember right, it was because it expected a particular pin code?
<superm1> that you didnt have the ability to enter
<ogra> yeah, but that seems to actually work with the new dongle
<superm1> oh.  i was gonna say, we could always add a quirk for it to the bluez-gnome source and submit it upstream
<ogra> i didnt know the kbd would be able to input a pin, its not documented
<superm1> oh that was for the keyboard - what's the issue with the GPS then
<ogra> nah, all fine now, i discovered today that i had timeouts in dmesg
<ogra> gps simply says "cant pair" now
<ogra> no info in dmesg about that one
<ogra> headset has still the same alsa issue
<ogra> but the BT side works fine
<ogra> and i can still browse my razr
<superm1> while i'm adding this patch for my apple keyboard, is there a particular way to do imported translations?  Or is there a document explaining what i'm supposed to do?  Someone else has always done the translation imports on the packages i've worked on
<ogra> the new dongle is a "Cambridge Silicon Radio, Ltd"
<ogra> the translations should automatically end up in the langpack
<ogra> soyuz strips them out of your package
<superm1> okay so I dont need to do anything for them then.  awesome
<ogra> just have them in your source package
<superm1> well i'd say that part is covered, they got imported: https://translations.edge.launchpad.net/ubuntu/intrepid/+source/bluez-gnome/+imports
<superm1> so i'll not need to worry then
<sebner> james_w: around?
<james_w> hey sebner
<sebner> james_w: hey. I'm off for today but I attached a debdiff for ssmtp/intrepid (But also used the Security wiki posted by you). If you are fine with it I'll prepare the debdiffs back to dapper tomorrow. just comment if it's ok or not :)
<slangasek> pitti: xml-core pre-depends> eew, but ok, I don't see any better options
<mvo> Riddell: I will disable the kde debian frontend during upgrades if you don't mind. it seems to cause crashes during the upgrade
<calc> Awsoonn: https://launchpad.net/~openoffice-pkgs/+archive
<dashua> Quick search in synaptic is buggied.  Type a few letter and CPU spikes over 50%, completely locks up synaptic.  Will check for bugs.
<mvo> dashua: how fast is your machine/how much mem do you have?
<lool> bryce, tjaalton: Just for the record, the xorg uploads were not in vain and it finally works almost out of the box with current xserver-xorg-core on psb hw to use vesa; sorry for the high number of uploads to fix misc things
<lool> thanks for your help in reviews
<bryce> excellent
<lool> There are two things which remain high on my list of things to fix, the -nsc symbol lookup error should be garded by some conflict (any idea of the specifics?) and xvfb is still useless on ppc, ia64, sparc, hppa etc.
<kirkland> anyone around here use wireless N under Ubuntu on a daily basis?
<lool> Will start looking at it in qemu soon now; fetching ppc alternate cd
<bryce> lool: sounds good, I've had my eye on the xvfb issues, but haven't had time to really dig into sorting them out
<dashua> mvo: Dell XPS m1530 2 gig of RAM Core 2 Duo 1.66 GHz
<dashua> I have to killall synaptic at times to clear it
<mvo> dashua: uh, that is quite a powerful one - strange. could you create a screenshot for me when it freezes?
<lool> ogra: BTW the vesa psb patch is now a noop as jcristau pointer out; vesa is the default when this function doesn't match any PCI ids
<dashua> I tried to add a debug symbol to the synaptic package, no luck.
<dashua> mvo:  Sure
<lool> Will be a template when we get psb for real
<ogra> lool, well, drop it if you feel like
<lool> I could drop it in git; doesn't change any really, as I said it will serve as a template when we get back psb
<lool> in 2 years
<ogra> or four :P
<bryce> 2 years??
<nxvl> heh
<nxvl> lool: i still can't configure xorg because with the psb error
<lool> nxvl: What's the error?
<lool> nxvl: what's your xserver-xorg-core version?
<nxvl> mm
<nxvl> i will look for the bug report
<ogra> nxvl, note that lool just fixed it with the very recent packages
<lool> nxvl: The bug report you filed was failing with -nsc symbol errors
<nxvl> Bug #265035
<lool> bryce, ogra: one thing which remains broken is for people with Driver "psb" in their xorg.conf
<ubottu> Launchpad bug 265035 in xserver-xorg-video-nsc "Xorg -configure breaks on  undefined symbol: xf86GetPciVideoInfo" [Undecided,New] https://launchpad.net/bugs/265035
<nxvl> i tried it yesterday
<lool> Should be actually upgrade these people to vesa?
<nxvl> with my system up to date
<lool> nxvl: Xorg -configure should pick up vesa if you don't have -psb installed now; and there's a conflicts against -psn
<lool> *-psb
<nxvl> oh
<nxvl> i will try it with Xorg instead of X
<lool> But that's since a couple of hours
<nxvl> but, shouldn't it be the same?
<lool> nxvl: Well with X
<nxvl> ok i will try later
<nxvl> thank you
<dashua> mvo: http://picpaste.com/pics/Screenshot-1.1224099130.png
<bryce> lool, yeah probably.
<jcristau> lool: xserver-xorg.postinst has some code to handle the upgrade, because i had to deal with the i810 -> intel transition, so you can probably adapt that
<dashua> mvo: Just locks then Compiz' OBS saturates the screen
<lool> jcristau: yeah, that's actually why I thought about doing this
<lool> jcristau: So we should provide a dummy package in this case?
<lool> jcristau: (for -psb)
<jcristau> lool: why would you do that?
<lool> Or should we simply rely on the conflict deselecting -psb?
<jcristau> the conflict should be fine
<lool> jcristau: I just fear that people stay with the old -psb and server, but upgrade their kernel
<lool> Ok; thanks!
<lool> Then it's not too hard to copy the upgrade code; thanks
<mvo> dashua: thanks, that is with the latest intrepid version? I remember I fixed a problem with that some days ago
<dashua> mvo: Yes, latest with all the updates.
<mvo> dashua: and does it matter what charackters you type there? ie "li" ? or is it any char combination?
<dashua> mvo: ii  synaptic       0.62.1ubuntu9  Graphical package manager
<dashua> It seems to really lock on characters with multiple entries, like lib
<dashua> mvo: bug #282188.
<ubottu> Launchpad bug 282188 in synaptic "Quick Search in Synaptic not working" [Undecided,New] https://launchpad.net/bugs/282188
<dashua> Not much info though
<lool> jcristau: I think the upgrade snippet doesn't work when there are trailing comments
<lool> jcristau: Since I have some lines with trailing comments in my xorg.conf, it might be worth fixing
<jcristau> lool: yeah. this is a "don't do that then".
<lool> jcristau: Why not support it?  it's just a matter of removing "[[:space:]]*$"
<jcristau> well. i'm happy enough if i keep dexconf-generated stuff working
<jcristau> but i won't complain if you fix that :)
<lool> Ok, will do
<mvo> dashua: I can reproducce it on one of my machines (but not the other) - how strange
<dashua> This is 32 bit, I had tried 64 and don't recall this issue.
<mvo> dashua: that is my impression as well, seems to be fine with 64bit
<lool> nxvl: Did you upgrade yet?  Please don't if possible
<lool> nxvl: It'd be nice if we could use your system to check for upgrades of -psb
<nxvl> i think i'm up to date
<nxvl> let me check
<lool> Well don't fix your xorg.conf manually
<nxvl> i'm up to date
<nxvl> i haven't touch it
<nxvl> it still sayd nothing
<kirkland> slangasek: hey, i was wrong about one thing yesterday, related to bug #272232 ....
<ubottu> Launchpad bug 272232 in shadow "passwd - passwords do not match but updated successfully" [Undecided,New] https://launchpad.net/bugs/272232
<kirkland> slangasek: actually, jeez, nevermind, i've confused myself
<kirkland> slangasek: okay, sorry.  you can smack me.
<mvo> dashua: could you rebuild synaptic and see if that fixes it? its funny, I just build a debug version and that makes the issue disappear for me
<slangasek> kirkland: if I smack you will that unconfuse you, or reconfuse you? :)
<kirkland> slangasek: actually, i'm still not sure what's going on....  i will wait to speak more, until I have enough concrete data to report :-)
<lool> nxvl: xserver-xorg 7.4~5ubuntu1 should convert your xorg.conf to use vesa on upgrades; could you confirm that happens correctly?
<kirkland> slangasek: okay ...  here we go ....
<kirkland> slangasek: passwd, enter a "Correct" current password, and then, enter 3x2 times a password that's too simple
<nxvl> lool: what am i supposed to have in my xorg.conf?
<kirkland> slangasek: the system password change will fail, the spurious "success" message will happen
<lool> slangasek: Around?  Would you like to discuss a release note: we don't have psb in intrepid anymore, so people with psb (such as dell mini owner AIUI) will lose 3D and 2D acceleration on upgrades; is this release notes worthy?  How do I make it happen?  file a bug tagged release-notes?
<kirkland> slangasek: and, very, very, very unfortunately, ecryptfs will re-wrap your passphrase
<nxvl> lool: i have this: http://paste.ubuntu.com/58028/
<lool> nxvl: What does it have right now for Driver?
<lool> nxvl: oh
<lool> nxvl: Then everything we did doesn't matter to you, your config has absolutely nothing to do with psb whatsoever
<nxvl> i fixed it 2 days ago, before that i didn't have the Driver line
<lool> nxvl: You're just a victim of the -ncb symbol issue, that's all
<lool> nxvl: You don't need one
<lool> nxvl: It should autodetect based on PCI ids
<lool> bryce, ogra: (xorg_7.4~5ubuntu1 (grah forgot to -v the debian changes) should upgrade psb driver lines now)
<slangasek> kirkland: ok, noted
<kirkland> slangasek: i'm checking the pam_ecryptfs source, at the moment, in case the bug is there
<slangasek> it's not
<slangasek> :)
<slangasek> it's a bug in the pam stack; pam_ecryptfs should never be invoked in this case
<kirkland> slangasek: okay, thanks.
<slangasek> I think I can fix this at the same time as fixing the rest of that bug
<kirkland> slangasek: cool, thanks.
<kirkland> slangasek: sorry for the back and forth messages
<slangasek> kirkland: no worries, compared to the stock market this is downright placid ;)
<lool> slangasek: Ok; I just confirmed that Dell mini users wont see the "upgrade to intrepid" popup; so the hardy psb user base is much smaller
<kirkland> slangasek: funny, even though it shouldn't be :-)
<lool> slangasek: So probably not release notes worthy
<slangasek> lool: so you're saying you don't think it will need release notes? ok
<slangasek> lool: otherwise, for reference, you can open a bug task on the 'ubuntu-release-notes' project for anything you think should be noted
<lool> slangasek: Unless there's a way to trigger the notes only when Xorg uses psb?
<slangasek> lool: nope :)
<slangasek> for that you'd have to talk to mvo about adding it to u-m
<lool> Ok; then not worth it to pollute everybody with it
<slangasek> well, are there /any/ users of psb that are affected?
<mvo> lool: xorg.conf rewrite? on upgrade? no problem, buy one, get one free!
<mvo> lool: we do that for nvidia already (and used to do it for fglrx)
<lool> slangasek: I'd say developers with dev hardware, so it's fine I think
<slangasek> ok
<lool> mvo: The rewrite part is done; I'd like to use something like for fglrx to tell them about the loss of acceleration
<lool> mvo: But now that I see that real world mass users aren't affected, it's not worth it
<lool> mvo: Just for my own curiosity: any drawbacks in doing it in xserver-xorg instead of update-manager?
<mvo> lool: doing it in xserver-xorg is better because it will work for apt-get users too
<slangasek> calc: hmm, are there more ooo uploads coming yet? if so, I have a request for a Recommends->Suggests downgrading to clean up the component-mismatches report :-)
<mvo> lool: the nvidia case is a bit more complex because the driver changed from hardy->intrepid, basicly we have 4 now instead of just 3
<slangasek> mvo: nuh-uh, we only have 2 because the other two are bustificated ;)
<mvo> slangasek: right, but you can't tell that from the one that is installed in hardy, you need to check which one you would need in intrepid to figure it out :)
<lool> mvo: Ok; thanks
<DktrKranz> zul, xen-restricted-modules-2.6.17 is still in Intrepid, can it be dropped from the archives?
<lool> james_w: I think you worked on clutter recently?  two tarballs were just announced, including the long awaited pyclutter 0.8
<lool> Thought you might want to know :)
 * slangasek resents that the PAM module writer's guide documents a different set of PAM return values for pam_sm_setcred() than the ones pam_unix will actually return
<lool> james_w: they were announced on dev@moblin.org btw
<lool> slangasek: It's to filter programmers allowed to program with pam
<bdmurray> slangasek: I've updated bug 193970 with my findings
<ubottu> Launchpad bug 193970 in hal "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed] https://launchpad.net/bugs/193970
<slangasek> lool: hmm, you seem to be positing that there is a conscious force responsible for anything in PAM :
<ogra> slangasek, do you have an actual time for the freeze set ?
<ogra> 0:00 UTC today or rather noon UTC tomorrow ?
<slangasek> ogra: morning-ish, UTC
<ogra> oki
<james_w> lool: yeah, I requested the removal of pyclutter yesterday :-/
<james_w> lool: what was the other?
<slangasek> bdmurray: looks good, thanks
<bdmurray> slangasek: not good but informative I guess
<slangasek> bdmurray: right - consistent with what I'm now seeing, and lets us narrow the scope of the bug :)
<mdz> slangasek: is 263059 on your radar?  it's looking very serious
<mdz> slangasek: intermittent boot failure, apparently on systems using iwl3945
<slangasek> mdz: yes, high+targeted; FWIW it only seems to happen with Dell hardware (== I can't reproduce it here), I'll nudge the kernel team
<mdz> slangasek: both davidm and silbs reproduced it on ThinkPads
<slangasek> hmm
<mdz> slangasek: or at least something which matches the symptoms closely
<mvo> I have a 3945 and it seem to not happen for me
<bdmurray> nor I and I've been rebooting a lot lately
<james_w> was there a suggestion it was 3945 + intel sound?
<NCommander> hey apachelogger
<davidm> mine hangs very frequently from cold boot
<davidm> james_w, I do have intel sound too.
<apachelogger_> yo NCommander
<slangasek> james_w: yes; but AFAIK that's the common case as well, I definitely have both snd_hda_intel and iwl3945 and have never seen this
<NCommander> apachelogger, what's up?
<james_w> slangasek: probably not that then
 * apachelogger_ is waiting for his core to get in sync with all his channels :P
<slangasek> well, it might be specific hardware revisions, or specific motherboards
<mdz> slangasek: it seems racy, could be anything
<dashua> mvo: Sure, I'll give it a try.
<ScottK> slangasek: Clamav announced a RC for a clamav 0.94.1.  It's almost all bugfix, but one new feature.  Typically their RC are followed by release ~ a week later.  Assuming this doesn't break any rdepends (generally correct for their .x releases) I think we want it.
<ScottK> slangasek: What do you want from me for an FFe next week when they release so I can be ready?
<NCommander> ScottK, got any good packaging tasks that needs doing?
<NCommander> superm1, ping
<superm1> pong NCommander
<slangasek> ScottK: upstream changelog, debdiff, and preferably some confirmation that the package is tested and works
<lool> james_w: other is Clutter-GTK 0.8.2
<lool> slangasek: I don't have dell hardware and I get the bug
<ScottK> slangasek: OK.  Thanks.
<slangasek> lool: can you send your lspci -nn to the bug, so we can start trying to pin down the common denominator?
<lool> mvo: Do you have snd-hda-intel?
<slangasek> is there anybody who has iwl3945 that *doesn't* have snd-hda-intel?
<james_w> lool: thanks, I might upload that tonight then.
<lool> slangasek: I think it's a race between two modules doing irq detection or something; I often see snd-intel-hda in dmesg when it hangs
<lool> slangasek: I tried loading them in shell for loops concurrently to no luck, but I couldn't hang my laptop in this way
<slangasek> lool: yes, but it's a race condition that's hitting some users frequently, and other users not at all
<lool> Yeah
<lool> I'm using root on lvm on md
<lool> perhaps that influences my initrd's code path to trigger it
<slangasek> well, please send any information you think might be relevant to the bug log then
<lool> slangasek: Also another thing which might be of interest is that I sometime hang in thinkpad-acpi since about the same time, but much less frequently
<lool> slangasek: Will update the bug with what I just wrote here; I tried to do some research when I worked on another iwl3945 hang which seemed similar with amitk, but didn't update the bug after the irc exchange
<calc> slangasek: i don't believe so, but the suggestion could be helpful in case it happens
<slangasek> calc: openoffice.org-qa-tools currently recommends openoffice.org-qa-ui-tests, which is in universe; downgrading that relationship looks right to me, unless you think we should MIR the other way
<calc> erm something is broken on ia64 buildd
<calc> The following packages have unmet dependencies: default-jdk-builddep: Depends: default-jdk (= 1.6-30ubuntu3) but it is not going to be installed
<calc> slangasek: taking a look
<slangasek> openjdk-6 was uploaded about the same time as OOo, yes
<calc> ah ok
<calc> so it just needs to be retried once it has finished building i guess
<slangasek> that's my best guess, I haven't chased that trail to be sure yet
<calc> slangasek: if i am reading annotate correctly the recommends has been there for a long time
<slangasek> sure
<slangasek> this is the first cycle we care about Recommends outside of main
 * calc looking at the reasoning if i can find when it was added
<calc> ok
<calc> yea been there for ~ 2.5 years, heh
<calc> slangasek: as best as i can tell if qa-tools is in main then qa-api-tests should as well
<calc> qa-tools appears to be the bit that runs the tests in the tests package :)
<calc> and the description of qa-tools tells you to make sure to install qa-api-tests also
 * calc does a rdepends on qa-tools
<slangasek> oh, actually qa-tools isn't in main...
<lool> slangasek: Upstream bug on iwl3945 also hints at hda
<calc> slangasek: ok... so is there something that is causing the problem? :)
<calc> i don't see a rdepends on qa-tools that should be causing an issue
<slangasek> calc: now I'm not sure :/
<calc> of course i am going by slightly old data
 * calc chroots into intrepid
<ogra> chroots ?
<ogra> you mean you dont run it after beta ?
<slangasek> maybe I need to take another look after the latest OOo publishes on amd64
<calc> ogra: i didn't want to risk breaking my machine in the middle of a bunch of OOo updates, so haven't updated yet
<ogra> heh
<calc> ogra: i am planning to probably later this week since i got everything uploaded finally :)
<ogra> well, final freeze is tomorrow
<ogra> should only improve after that
<calc> i booted a amd64 cd and it still was giving be weird resume issues so i think i will have to stick with i386 on my laptop
<calc> some sort of fs issue (i forget now which it is)
 * calc kicks apt-cache
<calc> ogra: yea :)
<TheMuso> sbeattie: re 275233 I am not entirely sure. The only thing I can do is ask those people to let us know if the rash still exists once we reduce the possaibility of the race conditions occurring.
<TheMuso> sebner: What jail break?
 * ScottK idly wonders if the response would be different off a publically logged channel.
<sebner> TheMuso: ipod. I think you are the maintainer
<TheMuso> sebner: No I am not.
<calc> slangasek: yea on up to date intrepid i still don't see anything that would be pulling in qa-tools, only rdepends are -qa-ui-tests -qa-api-tests
<sebner> TheMuso: argh, you are right. Sorry
<crimsun> stefanlsd: hi
<ScottK> slangasek: If you have a moment, would you please accept kdepim in hardy-backports?
<sbeattie> slangasek: elisa-plugins-bad/main depends on python-cssutils/universe; want bug?
 * calc is glad he managed to not annoy slangasek too much this cycle ;-)
* spm changed the topic of #ubuntu-devel to: LP down 00:00-02:00 UTC | 8.10 beta released | archive: Feature Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<nixternal> bryce: do you have a quick second?
<nixternal> I might have an issue you are familiar with concerning X
<ogra> spm, wow, thats the worst timing you guys had yet
<ogra> spm, you know that we have final release freeze tomorrow ?
<bryce> nixternal: okay... sort of in the middle of debugging two issues but if its quick go ahead
<ogra> spm, and everyone will need to make heavy use of LP, soyuz etc to get the last fixes in
<nixternal> intel gm965, external monitor blinks, log shows the following:
<nixternal> (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
<bryce> nixternal: bug id?
<nixternal> I fixed this the other day I am sure, but I have totally brain died
<nixternal> bryce: no bug id yet
<nixternal> just wondering if you have come across this one yet
<bryce> dude, I've been looking at sooo many bugs, if I did come across it I wouldn't remember :-P
<bryce> no it doesn't sound familiar offhand
<nixternal> hehe, OK thanks
<bryce> but all these bugs seem to run together after a while
<mthaddon> ogra, we were asked to delay from our normal time of 22:00 UTC to 00:00 UTC - I think kiko co-ordinated with engineering...
<bryce> nixternal: did you search launchpad?
<nixternal> ya, there are other reports with it, but no fix or anything
<nixternal> actually a few of them I have found are "RESOLVED" or "FIX RELEASED"
<ogra> mthaddon, even that is bad, i would have asked for 24h delay if i had been involved ... (i wasnt though) ... its one of the two busiest days for the distro team in a release
<ogra> mthaddon, it wont affect me personally but i guess a lot of universe contributors would try to get their fixes in tonight
<mthaddon> ogra, well, sorry you weren't involved - might be worth taking it up with kiko and/or Rinchen to make sure you're involved next time
<bryce> nixternal: if there are open ones with that, it'd be great if you could lend a hand triaging those.
<ogra> mthaddon, well, i dont ask to be involved :)
<bryce> nixternal: although, be aware that it's often the case where two people will see the same symptoms/error message yet may not have the same problem exactly
<mthaddon> yeah, careful what you ask for, eh?
<calc> why isn't there a hardy or intrepid updates milestone target?
<ogra>  mthaddon i just noticed that whoever was involved didnt really get across how important pre-final freeze day is :)
<bryce> often different error conditions can trigger the same error message
<ogra> mthaddon, at least its not the day before release ;)
 * calc has some bugs he needs to make in some way and those two would be helpful
<calc> er s/make/mark/
<slangasek> sbeattie: bug, and you might want to grab lool's attention on that
<ogra> mthaddon, as i said i'm mostly safe myself
<mthaddon> ogra, we'll do all we can to make sure the downtime is as short as possible (in any case, should be way less than 2 hours)
<slangasek> ScottK: hmm, try me again in a few hours please
<bryce> nixternal: if you're uncertain if you have exactly the same bug, file a new one via ubuntu-bug xserver-xorg-video-intel, which will collect all the files and stuff.  Make sure to describe the error message, symptoms, steps to reproduce, etc.
<cjwatson> calc: for hardy, would ubuntu-8.04.2 make sense?
<ogra> mthaddon, i'm just surprised that the distro team didnt actually ask for a 24 delay or for doing the outage a day earlier ...
<calc> cjwatson: yea i suppose that will work well also
<mthaddon> ogra, fraid I wasn't involved in the discussions either - we just rollout when we're told to :)
<cjwatson> calc: I'll create ubuntu-8.04.3, ubuntu-8.04.4, and intrepid-updates now
<cjwatson> ogra: I think it's probably better to have it now rather than later; wouldn't want it in the middle of the final freeze cycle either
<ogra> mthaddon, yeah, i didnt mean to complain, no worries
<cjwatson> ogra: at this point pretty much all times such
<cjwatson> suck
<ogra> yeah
<mthaddon> ogra, no offense taken :)
<calc> cjwatson: ok
<crimsun> TheMuso: do you need any assistance w/ munging pulseaudio to retry sinks (and sources) upon a new client connecting?
<calc> gar i found a bug in launchpad, i think
<calc> i approved hardy task for 173090
<TheMuso> crimsun: If you can offer help, that would be much appreciated. Last I was looking was sink-input.c in src/pulsecore.
<calc> it approved it for both openoffice.org2 and openoffice.org
<calc> now i can't mark it invalid for openoffice.org2 because it tries to reassign it openoffice.org
<crimsun> TheMuso: ok
<TheMuso> But I think this may need to be done in each of the connection type modules.
<cjwatson> calc: milestones done
<calc> i really wish we could get a feature to nuke whole package entries on bugs
<calc> i often end up with bugs like that which can't have a package incorrectly associated with it deleted
<cjwatson> calc: reproduced, yes that does look like a bug
<ogra> bryce, is i810 dead now ? seems there are some usecases whaere it would be worth having it
<bryce> ogra: it's dead jim
<ogra> thats bad
<TheMuso> heh
<pitti> slangasek: eek indeed, but I don't have a better solution either :(; but xml-core is so low in the stack that there shouldn't be any circular dependencies
<ogra> we just have a user whose HW doesnt work with intel
<ogra> in -mobile
<bryce> ogra: what's the chipset?
<ogra> Intel GMA 900
<ogra> seems to result in a black screen
<ogra> ASUS R2h
<bryce> ogra: bug id?
<ogra> no bug, the user just popped n asking for help
<bryce> dah
<bryce> ok, well talk to me again if/when there is a lp#
<ogra> though he is running -mid which is lpa
<ogra> *lpia
<bryce> upstream no longer supports -i810; we are not in a position to take over maintenance of it
<ogra> not sure there are any diffferences wrt intel
<ogra> yeah, i thought so
<ogra> lool, can we get him to file a bug ?
<bryce> for supported chipsets (i855 or newer), upstream will provide support, so bugs can be upstreamed for those
<lool> ogra: I think we should
<ogra> yeah
<lool> ogra: I'd like to make sure he can retrive some info
<ogra> not sure it helps that late in the release though
<lool> It's probably too late unless we can debug it
<bryce> people asking for help with unreported X bugs this late in the release cycle just aren't going to get help; there's already too many bugs already reported where we're close to a solution, that we're focusing the limited time on
 * ogra really wonders how intel will support their scaling and panning modes in teh classmate without the i810 driver
<bryce> best bet is for them to help us help them get the bugs upstream and fixed there, so they'll have a chance with jaunty
<ogra> the intel driver will never support either by design
<pitti> slangasek: rarian with pre-depends uploaded now, FYI
<pitti> yay, that will make https://bugs.edge.launchpad.net/ubuntu/intrepid/+bugs?field.assignee=pitti empty
<ScottK-palm> NCommander: Upstream react.  He'll have a patch shortly, so you may as well move onto something else.
<NCommander> ScottK-palm, too late
<NCommander> I just kicked out a patch myself
<NCommander> :-)
<NCommander> (three line fix, it needed an addition check)
<ScottK-palm> Did you mail it to me?
<NCommander> I *just* finished it
<ScottK-palm> Send it to Shevek too then
<NCommander> Had to make sure it worked ;-)
<NCommander> Who?
<ScottK-palm> I'll tell him to expect it.
<NCommander> Wher?
<NCommander> What?
 * NCommander is lost
<ScottK-palm> The upstrw
<ScottK-palm> upste
<ScottK-palm> urgh
<ogra> that thing where our software comes from :)
<ScottK-palm> Upstream.
<bond`> what needs to be done to get a patch backported to 8.04?  Bug #276472
<ubottu> Launchpad bug 276472 in linux "cp -p on CIFS mount does not preserve timestamp" [Undecided,Incomplete] https://launchpad.net/bugs/276472
<NCommander> ScottK-palm, I can't find his email
<NCommander> bond`, if its a small patch, it can usually done via SRU
<ScottK-palm> It's in the contributors file
<bond`> NCommander: bug 276472 is still status incomplete, what is missing?
<ubottu> Launchpad bug 276472 in linux "cp -p on CIFS mount does not preserve timestamp" [Undecided,Incomplete] https://launchpad.net/bugs/276472
<ScottK-palm> NCommander @annares.org I think)
<NCommander> Sent
<ScottK-palm> K.  thanks
<NCommander> ScottK, he fixed the bug but didn't release a new upstream
<NCommander> Which is anonying but ...
#ubuntu-devel 2008-10-16
<NCommander> Bug #272576
<ubottu> Launchpad bug 272576 in revu "Provide alternate login method" [Undecided,New] https://launchpad.net/bugs/272576
<calc> grr seems like launchpad is always going down for maintainance
 * calc thought he was going to be doing bug triage but apparently not
 * NCommander watches REVU die
<NCommander> I can understand shutting down edge for maintance, but is it really necessary to completely kill everything?
<kwwii> calc: did you get the updated icons and license info into OOo?
<ogra> kwwii, what are yu doing up at 2am ?
<TheMuso> calc: I know what you mean, as it generally lands smack bang in the middle of my work day, so I have to find other things to do.
 * ogra can blame the glenvilet and RichEd but whats your excuse :P
<ajmitch> NCommander: did that kill revu due to the openid hooks?
<crimsun> TheMuso: hey, no boogs!
<directhex> zaroo boogs.
<ajmitch> iz gtk boog?
<TheMuso> crimsun: heh
<NCommander> ajmitch, yup
<kwwii> ogra: waiting to come kassel for release :)
<ogra> hehe
<ogra> feel free
<kwwii> hehe
<kwwii> time for sleep here
<ogra> yeah
 * ogra did his final upload ...
<TheMuso> crimsun: Any luck with that pulse sink stuff? I'm going to start again in a bit since LP is down. Am happy to go from where you have left off.
<slangasek> kirkland: still around?
<kirkland> slangasek: yessir
<crimsun> TheMuso: been chasing ALSA and PA stuff concurrently, and honestly, didn't have time to look at the latter.  Sorry.
<TheMuso> crimsun: np
<calc> gar when lp goes down all hosted things go with it
<slangasek> kirkland: hmmm.  are you going to be around until the end of the LP maintenance window? :-)
<calc> they really need to make lp more robust if they are going to keep bringing it down (what seems like) every week for several hours
<kirkland> slangasek: :-)  probably, how much longer is that?
<slangasek> I just got done smoke-testing my pam fix, and there goes LP, whoops :)
<slangasek> kirkland: up to but not to exceed 2 hours
 * calc can't even run bzr log on one of his checkouts
<kirkland> slangasek: i'll probably have my laptop with me, watching the debate
<slangasek> ok
<calc> oh well as long as i can't get anything done right now i might as well upgrade to intrepid, lol
 * NCommander sleeps soundly waiting for LP to return :-)
<StevenK> calc: Unbind it
<cjwatson> yeah, bzr unbind
<ogra> grmbl
<StevenK> calc: Maybe 'bzr log --local' works too
<cjwatson> you can bzr push and bzr bind again later
<ogra> i uploaded at 23:52 UTC ... no trace that LP got it in time
<cjwatson> it won't have vanished, it'll be in the queue
<ogra> yeah, indeed
<cjwatson> even if you had got an acceptance it wouldn't have been published anyway
<ogra> but i wont know if it built
<StevenK> ogra: If you're worried, one of us can poke on cocoplum
<cjwatson> I imagine they'd just taken the cron jobs down in preparation
<ogra> yeah
 * StevenK runs to the doctors
 * ogra watxhes "blow up" on tv ...
<calc> ah ok
<calc> bzr log --local doesn't seem to work for me, maybe after i finish upgrade to intrepid though
<kirkland> slangasek: launchpad just started responding for me, fwiw
<slangasek> kirkland: ok, please test lp:~ubuntu-core-dev/pam/ubuntu :)
<TheMuso> yeah working here too.
<calc> yipee it works for me again too :)
<TheMuso> edge is at least.
<NCommander> Lauchpad returns
<NCommander> SHort downtime
<bryce> NCommander: wow that was impressive
<NCommander> bryce, what is?
<bryce> NCommander: the shortness
<calc> its always good to be early ;)
<slangasek> augh, why did cracklib break
 * slangasek shoots the cracklib packges
 * directhex offers a convenient c# version of cracklib
 * NCommander shoots C#
 * directhex hands NCommander vb.net instead
 * NCommander bursts into flames
<slangasek> oh, geez; this is the worst bashism I've ever seen
<slangasek> [ /usr/share/dict/words -nt non-existent-file ]
<slangasek> true in bash and false in dash \o/
<directhex> with #!/bin/sh ?
<TheMuso> ew
<cjwatson> add it to DashAsBinSh?
<directhex> i thought intel were bad. do they still "support" ubuntu for their compilers as long as you replace the /bin/sh symlink?
* spm changed the topic of #ubuntu-devel to: 8.10 beta released | archive: Feature Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> cjwatson: adding, thanks
<bryce> ogra: what do you think of the patch in bug #222164?  Looks simple enough to me but I'm not sure what its implications are so have held off applying it
<ubottu> Launchpad bug 222164 in xf86-input-evtouch "evtouch works incorrectly when the screen is left or right rotated" [High,Triaged] https://launchpad.net/bugs/222164
<kirkland> slangasek: hmm
<slangasek> ?
<kirkland> slangasek: i pulled that tree, did a build, installed the debs, but I'm still getting the 'success' messages
<kirkland> slangasek: is that supposed to be fixed?
<slangasek> kirkland: post me your /etc/pam.d/common-password, please
<kirkland> slangasek: http://pastebin.com/f7ea2568d
<slangasek> kirkland: hmm
<slangasek> kirkland: please run grep -vE 'pam_unix.so|pam_ecryptfs.so' /etc/pam.d/common-password | md5sum for me
<kirkland> slangasek: 86180c1552203d9b58582cf547309d01
<slangasek> kirkland: you built with -b and installed libpam-runtime, right?
 * TheMuso grumbles at being pointed to an ubunt forums thread in a bug, and not being told on which page at the very least may be helpful.
<slangasek> that md5sum matches the one I have listed
<kirkland> slangasek: i just did "debuild" (no -b)
<kirkland> slangasek: libpam-runtime 1.0.1-4ubuntu5
<slangasek> kirkland: can you confirm that you see 86180c1552203d9b58582cf547309d01 in /usr/sbin/pam-auth-update?
<kirkland> slangasek: negative
<kirkland> hmm
<slangasek> kirkland: what bzr revision do you have?
<kirkland> let me check my bzr branch
<kirkland> slangasek:  -- Steve Langasek <steve.langasek@ubuntu.com>  Thu, 09 Oct 2008 16:35:46 -0700
<kirkland> slangasek: Tree is up to date at revision 760.
<slangasek> I have revision 763 here
<kirkland> slangasek: have you pushed?
<slangasek> yes
<calc> "This bug doesn't affect me (change)" what does that mean?
<calc> i don't think i have seen that before on a bug page
<kirkland> slangasek: let me try pulling again
<slangasek> kirkland: checking whether I can pull it here as well
<kirkland> slangasek: i did "bzr branch lp:~ubuntu-core-dev/pam/ubuntu"
<slangasek> kirkland: right. I see revision 763 when I pull here, so perhaps we had a race condition there :)
<kirkland> slangasek: i blew away my copy, pulling again now
<kirkland> slangasek: okay, now i got 763 revisions
<stgraber> calc: it's the new "me too" feature of LP, you probably are on edge
<Hobbsee> greetings
<calc> stgraber: ok
<nxvl> hi Hobbsee
<Hobbsee> hey nxvl!
 * Hobbsee celebrates that the uni has unblocked some of their ports again
<nxvl> i saw you are going to UDS this time!
<stgraber> Hobbsee: oh, as in 6667 ? :)
 * nxvl is at the university using an open 21 for ssh connections and ssh tunnels
<Hobbsee> stgraber: nah.  993, etc.
<Hobbsee> stgraber: i have an irc proxy, so don't use 6667 from my laptop.
<slangasek> kirkland: ok, let me know how that goes :)
<stgraber> ok
<Hobbsee> nxvl: indeed!
<stgraber> nxvl: oh, they let ftp go through their firewalls, that's good :) (for you)
<kirkland> slangasek: aha!
<kirkland> slangasek: that's looking together
<slangasek> @yay
<kirkland> slangasek: looking better
<stgraber> nxvl: I used to connect on a Windows network with everything blocked except the proxy server ... so I had to use ntlmaps to connect to the ISA proxy (using NTLM), then use ssh over https on port 443 and finally openvpn over tcp going through a ssh tunnel to get complete internet access :)
<stgraber> (all that scripted, it's not that difficult to setup and quite fast actually)
<nxvl> yeah
<kirkland> slangasek: but now quite there yet
<kirkland> slangasek: checking the current password now does the right thing
<nxvl> i have no proxy, just port blocking, so it's some steps less
<kirkland> slangasek: it fails immediately, with the wrong password
<slangasek> huzzah
<kirkland> slangasek: but hit <enter> 6 times for the new password
<kirkland> "No password supplied" x 3
<nxvl> i just need an ssh running on 21, 80 or 443, and a lot of tunnels (on my .ssh/config)
<kirkland> then "password updated successfully"
<Hobbsee> stgraber: these guys were allowing 22, 443, and 80 for a while.  Only.
<nxvl> and i'm done
<kirkland> emma: :-)
<TheMuso> crimsun: Did you try my interim Xsession.d fix to reduce the race condition's possibility?
<kirkland> emma: $1000 says he lives on "Main Street"
<kirkland> emma: "Not Wall Street"
<crimsun> TheMuso: yes, and it helps.  I haven't been able to trigger the race yet.
<nxvl> Hobbsee: for a geek it's only needed some imagination and patience
<TheMuso> crimsun: Ok.
<Hobbsee> nxvl: that's true.
<nxvl> Hobbsee: there is no no-geek sysadmin that can make us be quiet
<Hobbsee> hehe
<nxvl> and even some geek sysadmins that can't
<crimsun> TheMuso: OTOH, with current pulseaudio packages (i.e., no interim Xsession.d fix), the race on my machine is, at best, very difficult to trigger.  Seems it nondeterministically triggers once every twenty or so logins.
<TheMuso> crimsun: Right.
<TheMuso> crimsun: I am the same, but I can never trigger it.
<slangasek> kirkland: ok, wheels turning in the noggin'; I may have to wait until after dinner to fix that
<slangasek> (if I'm right about how to fix it at all, that is)
<kirkland> slangasek: k
<crimsun> Laney: how many audio devices are in your computer (experiencing the pulseaudio race on session login)?
<stgraber> nxvl: well, the only thing that could have stopped my hack is some packet analysing (basicalling detecting that I'm not sending http over SSL but something else) that needs quite a powerful firewall to do and a lot of tweaking
<stgraber> nxvl: so not really an option on a big network :)
<ScottK> slangasek: It's been a couple of hours, so I'm asking again about kdepim in hardy-backports.
<nxvl> stgraber: or a real proxy rejecting non http traffic, but for that we have http tunneling :P
<slangasek> ScottK: right, looking :)
<nxvl> stgraber: or a traffic analyzer and someone reading the logs and seeing what's going on and rejecting that connection, which is hard for any network
<ScottK> slangasek: Thanks.
<stgraber> nxvl: well, I was over HTTPS so the "rejecting non http traffic" is not possible as it only sees HTTPS (and the purpose of https is to not have man in the middle thing possible) :)
<NCommander> So Canonical loves REVU
<stgraber> nxvl: so a very well configured traffic analyser can detect that from the packet size and some other parameters (I remember reading about that) but it's not that easy to do and a real wast of CPU in most case
<NCommander> http://revu.ubuntuwire.com/ - try logging in and look at the login page
<slangasek> ScottK: accepted
<nxvl> stgraber: that's why you need a real geeky sysadmin
<ScottK> slangasek: Thanks.
<stgraber> NCommander: :)
<calc> crimsun: ping
<crimsun> calc: pong
<calc> crimsun: i see you followed up to 77435 but wasn't quite sure what you meant by 0.6/0.7/0.8 and another user claims it works fine
<StevenK> nxvl: Looks fine to me
<crimsun> calc: sorry, I should have been more specific; those versions refer to xmonad.
<nxvl> StevenK: what did i did now/
<nxvl> ?
<StevenK> Er. NCommander, rather than nxvl
<nxvl> oh
<StevenK> nxvl: Sorry :-)
<NCommander> StevenK, look closely at the text
<NCommander> There is a thankyou on behalf of Canonical
<calc> crimsun: oh ok
<NCommander> (and the new working men image)
<StevenK> Oooh, I see that
<NCommander> It was an added bonus when I got REVU added to the trustroot so we can get full openid support
<NCommander> which lead to this: https://bugs.edge.launchpad.net/launchpad/+bug/284133
<ubottu> Launchpad bug 284133 in launchpad "GPG over OpenID" [Undecided,New]
<nxvl> cody-somerville: the xubuntu instaler is livecd too?
<cody-somerville> yes
<nxvl> cody-somerville: just as the ubuntu installer?
<cody-somerville> Right
<nxvl> cody-somerville: so i can run the livecd and install from there
<cody-somerville> yes
<nxvl> awesome
<nxvl> thanks
<cody-somerville> no problem
<kirkland> slangasek: another pam question for you when you come back from dinner
<kirkland> slangasek: i have some people complaining that their ~/Private directories are being unmounted by their cronjobs
<kirkland> slangasek: pam_ecryptfs is in the common-session stack, and cron opens/closes a session
<kirkland> slangasek: the close session unmounts ~/Private
<kirkland> slangasek: the current work-around is for those users to rm ~/.ecryptfs/auto-umount, which umount.ecryptfs_private checks for
<kirkland> slangasek: but that disables automatic unmounting across the board
<kirkland> slangasek: that's not ideal
<kirkland> slangasek: a counter, has been suggested, but i'm not sure that's the best approach
<calc> crap my upgrade to intrepid now won't boot
<mrooney> calc: no more bugs, then!
<calc> mrooney: yea sorta
<calc> looks like i will need to download and completely reinstall
<cjwatson> calc: :-(
<cjwatson> try the live CD just as a checkpoint?
<cjwatson> it'd be odd if a boot failure was due to upgrade vs. fresh install, though it's not unheard of
<kirkland> slangasek: actually, i'm wondering, perhaps we should drop pam_ecryptfs from common-session?  would common-auth and common-password suffice?
<cjwatson> though if it is due to upgrade vs. fresh install, then it should be rectifiable in-place
<MacSlow> I'm trying to get a custom kernel going and currently hang at the initrd-creation-step ...
<MacSlow> yaird gives me an error like: "yaird error: bad device link in /sys/block/sda (fatal)"
<MacSlow> yaird -vd --output=initrd.img-2.6.27-rc9 2.6.27-rc9
<MacSlow> is the command I use
<MacSlow> but neither the "verboseness" nor the debug-output of yaird help me getting further clues what might be the cause of the error
<DrPepperKid> but neither the "verboseness" nor the debug-output of yaird help me getting further clues what might be the cause of the error
<DrPepperKid> hm... my connection crapped out
<crimsun> TheMuso: have you settled on patching pulseaudio instead of libcanberra0.6?  I'm wondering if it doesn't make sense to touch the latter instead for intrepid...
<calc> i managed to revive it
<calc> i booted off 8.04 cd and remade the initramfs and that seemed to fix it
<TheMuso> crimsun: I am unsure as to what we could do with libcanberra.
<calc> it originally had hung right after loading the wifi driver (3945 card)
<StevenK> libcanberra as in the city?
<StevenK> calc: iwl3945?
<calc> StevenK: yea
<Hobbsee> calc: known bug.  just kepe trying tob oot
<Hobbsee> calc: https://bugs.launchpad.net/bugs/263059
<calc> Hobbsee: oh lovely
<ubottu> Launchpad bug 263059 in linux "[regression] 2.6.27-7 sometimes fails to boot (iwl3945 issue?)" [High,In progress]
<StevenK> calc: davidm has been having problems with it too
<calc> StevenK: ok
<Hobbsee> i thought it was a more local problem.  apaprently not.
<calc> so maybe the initramfs did nothing then, just trying to reboot probably fixed it
<crimsun> TheMuso: perhaps I'm hitting a different bug, but all of my crashes have been with "GNOME Login", which would be from libcanberra-login-sound.desktop's canberra-gtk-play invocation
<TheMuso> crimsun: crash as in segfault?
<crimsun> TheMuso: apparently, and it seems to be caused by the same race
<TheMuso> crimsun: Right, I am not sure how to solve that, there is a bug filed about it. Let me dig it up.
<TheMuso> crimsun: 275233
<calc> how do you see the me-too status of a bug?
<calc> or is it just a feel good button? :)
<Hobbsee> calc: you can't.
<Hobbsee> calc: eventually, they say they'll do something with it - but not actually let you see the raw numbers.
<calc> hmm ok, so its turned on but of no use at all
<calc> lol
<Hobbsee> it has the aim of making people not write "me too" and such in bug reports.
<calc> Hobbsee: and instead since no one can see the stats a developer has no idea how widespread the bug is
<calc> especially if users actually start using this placebo button ;-)
<slangasek> kirkland: I have no idea whether pam_ecryptfs should be dropped from common-session; it would have no effect on this bug, and I don't think it's a great idea to make changes there at this point if we don't have a specific bug in mind
<slangasek> kirkland: oh, you said that earlier, sorry :) - I don't know if it should be dropped from common-session, then
<calc> Hobbsee: the main usefulness of such a button would be to get the info out of the comment log, it is still very useful to know their launchpad id's and the overall number (raw number whatever)
<Hobbsee> calc: you'd have thought so, but...
<Hobbsee> calc: i just heard this.  I don't have much to do in LP development.
<calc> doing it the way it currently is useful to no one really at all
<calc> less comments in a bug without any way to see its due to this button is actually worse than before
<Hobbsee> calc: you could try to get that POV across to #lp, in a few hours, if you wanted.  No guesses on your chance of success, though
<TheMuso> crimsun: do you get that crash even with the pulse Xsession.d fix?
<calc> Hobbsee: probably would be easier to just do it at UDS
<calc> its only about 6 weeks from now
<kirkland> slangasek: okay, i need to think more about this later
<ScottK> calc: This button got discussed at the last UDS.  They seem to have proceeded anyway.
<ScottK> calc: Currently it's pre-production.  If you wait until UDS it'll be "Everyone is used to it now, we can't change it".
<slangasek> kirkland: ok, I don't seem to be able to reproduce the earlier bug with other optional modules besides ecryptfs, testing now with ecryptfs
<calc> ScottK: a button that does nothing or a button that can collect data?
<calc> ScottK: i don't recall them planning on a useless button at the last UDS
<beuno> calc, ScottK, it should soon start showing up in listings as an icon, for the most user-affected bugs. I don't know what the exact status of that branch is. I also know there are plans to figure out what the best way to provide that information for bug triagers is, probably through the API.
<kirkland> slangasek: it also works with current = (correct), new1 = foo, new2 = bar
<beuno> please, file bugs with what would make it more useful for you guys  :)
<slangasek> kirkland: "works", or "triggers the bug"?
<ScottK> calc: Trying to have a 'me too' button instead of having people comment.  Next step in the master plan is to have Confirmed disappear as a status.
<kirkland> slangasek: triggers the "password updated successfully" report
<Hobbsee> beuno: will the bugs be looked at promptly?
<Hobbsee> beuno: or will they wait 6+ months?
<beuno> Hobbsee, don't be mean!  they will be looked at soon, and something will be done to make the feature more useful for you guys, which is why it was done in the first place
<beuno> the implementation is just being made in smaller steps
<calc> beuno: ok, it would be very useful to have some way to get at the names/total number from the page as well
<Hobbsee> beuno: right.  And i'm not being mean, i'm more just used to reality.  I'm pleased to see the bug I filed in sevilla (april 07, iirc) about an implemented feature has finally been triaged.
<calc> ScottK: then just get rid of bug reporting entirely :)
<ScottK> calc: That's the best way to get the count to zero.
<calc> ScottK: heh
<slangasek> kirkland: ok - it seems to be pam_ecryptfs specifically that returns PAM_SUCCESS in this case when no password token has been set
<beuno> calc, right, there are some concerns that the feature may be used to blackmail developers into fixing certain bugs, so we want to be careful with it
<slangasek> kirkland: why doesn't pam_ecryptfs return PAM_IGNORE?
<ScottK> beuno: In most projects 'having something useful' is something you do before fielding it.
<kirkland> slangasek: ignorance on our (ecryptfs-devel) part, probably
<beuno> calc, so, we want to make it useful, but be careful not to shoot ourselves in the foot
<kirkland> slangasek: i'll look at that tomorrow
<beuno> ScottK, sure. I guess this isn't most projects
<calc> beuno: blackmail?
<ScottK> That's for sure.
<calc> beuno: ah you mean vote stuffing, i guess?
 * RAOF presumes "blackmail" means "gaming the system for fun and profit"
<beuno> calc, yes. "1103 users voted for this, you should fix it!"
<calc> heh
<Hobbsee> beuno: now that sounds like brainstorm.
<calc> i'm sure large numbers of users would vote for put OOo 3.0 in intrepid, but its not happening :)
<beuno> right, so, I think the proposed solution is to show in the listings, with an icon, the top 5% or so
<calc> beuno: could make the number only visible by bug squad or something if that is a concern
<beuno> and maybe provide actual counts or something similar through the API
<tedg> calc: Is there a PPA for OO.o 3?
<beuno> but, please, take with a grain of salt, I'm not 100% sure where the discussion is
<calc> tedg: yes ~openoffice-pkgs
<ScottK> beuno: It sounds like a very elaborate attempt to hide information that's actually useful.
<tedg> calc: Cool, thanks.
<calc> tedg: will most likely go into backports around the beginning of Dec
<tedg> calc: I'm working on making my system unstable before the jaunty archive opens ;)
<beuno> ScottK, I'm with you in the elaborate part
<beuno> there's a lot of things to consider
<beuno> I'm sure we'll work out something
<calc> tedg: heh :)
<slangasek> kirkland: ok.  I think that's the reason for this behavior; I'm going to have a closer look at pam_ecryptfs code, and if that conclusion stands, I'll go ahead and upload these pam changes and we can look at ecryptfs tomorrow
<beuno> calc, Hobbsee, so, if you guys can file bugs with your concerns, or even ideas, it would be great, and I promise to chase up answers for them if you don't get any soon
<Hobbsee> beuno: ok, cool.
<beuno> we have a big 2 week sprint coming up from next week on
<beuno> so response times may vary a bit
<ajmitch> beuno: another long flight for you? :)
<beuno> but I'll keep an eye out for bugs on this, feel free to subscribe me
<beuno> ajmitch, heh, yeah. But it's only 16hs this time!
<calc> beuno: is it possible to make something only visible on a bug page by a certain group?
<calc> beuno: so we could have the stat there but only by eg bug squad or something like that, then have it available via api for whoever wants it there as well
<beuno> calc, I suspect that it would involve special-casing a team in LP, and would be very hard to convince anyone to do something like that. APIs are less user-visible, so it's less of a risk.
<beuno> I'm not saying no
<beuno> and, in no way do I decide any of this
<beuno> so give it shot
<calc> beuno: ok
<ajmitch> there's already special-casing on changing bugs
<ScottK> beuno: I already gave my feedback at UDS.  No reason to waste time on it now.
<calc> beuno: oh another feature i want is the ability to delete packages from a bug
<calc> :)
<beuno> is it christmas already?  :p
<Hobbsee> oh, now there's an idea...
<calc> well i found a real bug that could be fixed by allowing that
<Hobbsee> calc: you can already do that, though.  entirely obtuse, though
<beuno> I know that's a common headache, not sure why it's still there
<beuno> or if there's a bug open for it, which I suspect it is
<calc> for eg openoffice.org any bug assigned to openoffice.org2 gets autoreassigned to openoffice.org but it fails if it already is assigned to openoffice.org as well via a separate package entry
<calc> Hobbsee: how do you delete it?
<Hobbsee> calc: edit it, take out the package field.  then it just gets assigned to ubuntu.
<calc> Hobbsee: ugh that isn't a real solution
<calc> Hobbsee: i'm sure bdmurray would like to remind you about that ;-)
<Hobbsee> calc: it's a workaround :)
<Hobbsee> calc: ah well.  Maybe he needs more agressive mail filtering :P
<calc> in this particular case it caused a hardy task to get opened and i couldn't even mark it invalid becaue it would try to rename the package entry which won't work
<Hobbsee> ah yes, there's no way back from nominate for release.
<calc> i didn't even nominate it for openoffice.org2, i nominated it on the other package entry for openoffice.org
<calc> and i wasn't trying to remove it, i can't even mark the bug as invalid under openoffice.org2 because it tries to rename it to openoffice.org and fails
<calc> er i mean remove it from nomination
 * calc can't recall the bug number atm but i mentioned the number earlier today
<calc> bug 173090
<ubottu> Launchpad bug 173090 in openoffice.org2 "[upstream] [hardy] Special characters are not displayed correctly, fonts dissappear from the menu" [Undecided,New] https://launchpad.net/bugs/173090
<calc> thats it
<calc> and is the reason why i think we should be able to delete package entries, or at have the option via restricted access (bug squad?)
 * beuno agrees
<calc> i have quite a few bugs that are screwed up like that overall
<calc> or at least used to
<calc> actually in this case i can't even close the bug entirely, lol
 * calc headed for bed, bbl
<StevenK> Hmmm. What's the graphical tool that give you a device-manager-esque thing from HAL?
<TheMuso> hal-device-manager?
<wgrant> It's actually gnome-device-manager these days.
<wgrant> And is apparently no longer installed by default.
 * StevenK is trying to track down the wireless device in this device
<wgrant> Can I please attack forum users if they suggest to alter /var/lib/dpkg/status and the local Packages files in order to resolve dependency issues?
<TheMuso> wgrant: I'd say yes go ahead. :p
<RAOF> Wow.  That's a disturbing concoction of cluelessness and knowledge.
<wgrant> Exactly.
<wgrant> If they know enough to be able to do that, they should know enough to realise that's its stupid and wrong.
<StevenK> Hmph. Can't find the network device or the touchscreen in hal-device
<TheMuso> StevenK: what about lshal?
<ScottK> wgrant: Either that our they're Automatix devs and it's the way things are done.
<StevenK> lshal for 'touch' gives nothing, and 'network' only the shows the USB Ethernet I plugged in
<wgrant> ScottK: Indeed, that's a good theory.
<r_rehashed> hi all. any idea when mono 2.0 will be released for hardy?
<slangasek> kirkland: ok, pinned down the ecryptfs issue; yeah, it's an ecryptfs bug
<Burgundavia> r_rehashed: it might be backported, but that is a huge amount of work, given all the mono apps that would require rebuilding and testing
<r_rehashed> since hardy is an LTS release i thought it will be backported. but i hope ibex uses 2.0 instead of 1.9
<wgrant> LTS also means "don't break everybody's systems"
<wgrant> And backporting mono is a sure way to do that.
<RAOF> r_rehashed: Intrepid won't have 2.0
<r_rehashed> :-/
<RAOF> On the basis that there aren't actually any packages available yet, despite the work of the Debian mono team.
<r_rehashed> i see
<RAOF> And also the horrible risk of regressions in the tiny, tiny time available to test.
<r_rehashed> yes, i understand
<dholbach> good morning
<Burgundavia> morning dholbach
<MacSlow> dholbach, hi here too
<MacSlow> hey Burgundavia
<dholbach> hiya Burgundavia
<MacSlow> any yaird expert here?
<Burgundavia> MacSlow: how goes the banging at GDM?
<MacSlow> I get the error "bad device link in /sys/block/sda (fatal)" when trying to execute "yaird --output=initrd.img-2.6.27-rc9 2.6.27-rc9"
<MacSlow> Burgundavia, coming along
<MacSlow> There are three symlinks in /sys/block/sda all of which seem to be find (I can "cd" to them)
<kagou> good morning
<MacSlow> Is there any other way/tool to create a initrd.img under intrepid? The old mkinitrd seems to be gone.
<StevenK> MacSlow: mkinitrd is long dead. "update-initramfs -u"
<MacSlow> StevenK, that'll work with a self-compiled kernel?
<StevenK> MacSlow: update-initramfs -u -k <version>
 * MacSlow assumes that uses some assumptions regarding special ubuntu package actions done before it
<MacSlow> StevenK, does that do anything besides creating /boot/initrd.img-version.bla ?
<MacSlow> StevenK, it's not touching any of /boot/grub/menu.lst or the like?
<StevenK> MacSlow: None, just creates the initramfs
<MacSlow> StevenK, ok ... seems to work sofar
<dholbach> Riddell: do you have the source of example-content/kubuntu-leaflet.png somewhere? It still mentions powerpc
<slangasek> pitti, doko: could you take a look at the cssutils MIR, please?  elisa is currently uninstallable in main without it
<doko> looking ...
<sbeattie> slangasek: system-cleaner passed its MIR, but python-fstab needs to go along with it.
<slangasek> sbeattie: is there a separate MIR for python-fstab?
<sbeattie> slangasek: no, liw included it in his system cleaner MIR: https://wiki.ubuntu.com/MainInclusionSystemCleaner
<sbeattie> bug 279554 is the tracking bug
<ubottu> Launchpad bug 279554 in system-cleaner "Main Inclusion Request: system-cleaner" [Undecided,Fix released] https://launchpad.net/bugs/279554
<slangasek> hmm, the MIR team expanded when I wasn't looking :)
<sbeattie> heh
<pitti> slangasek: cssutils mir> will do
<slangasek> vorian: kdiamond-kde4 is uninstallable because it depends on a package that conflicts with it; please drop the kdiamond Conflicts: on kdiamond-kde4 and make the Replaces: versioned
<slangasek> pitti: doko is already looking
<slangasek> python-fstab promoted
<pitti> Good morning
<Hobbsee> slangasek: alreadyknown,#kubuntu-develwasdiscussing itearlier.
<slangasek> Hobbsee: great, will be fixed soon?
<Hobbsee> ithink so
<slangasek> \o/
<sbeattie> Hobbsee: ScottK got tired before he could take care of it, not sure anyone else picked it up.
<Hobbsee> sbeattie: yeah,isaw.  don'tthink anyone has so far.
<doko> slangasek: done
<slangasek> doko: thanks
 * Hobbsee sighs.  to all:  apologies: it looks like part of my spacebar has kicked the bucket.
<tkamppeter> pitti, hi
<pitti> tkamppeter: good morning; just saw your mails, many thanks!
<tkamppeter> pitti, now it is all perfect with the PPD package on OpenPrinting.
<tkamppeter> pitti, I have already successfully installed the package with s-c-p, by doing a small modification on s-c-p that it even does the look-up when there is a local driver (this mosification I only do for debugging, not for upload).
<mdke> pitti: thanks for the ubuntu-docs upload yesterday
<pitti> tkamppeter: nice, my test suite succeeds now \o/
<mdke> pitti: any idea when it will be available in hardy-proposed for testing?
<pitti> mdke: let me just process it right now
<mdke> pitti: yay!
<pitti> mdke: bug 153124 and bug 220889 are still open in intrepid; can you please check if they are fixed?
<ubottu> Launchpad bug 153124 in dell "Firefox Non-English Start pages not localized properly" [High,Confirmed] https://launchpad.net/bugs/153124
<ubottu> Launchpad bug 220889 in ubuntu-docs "wrong 8.04 codename in Korean start page" [Undecided,Fix committed] https://launchpad.net/bugs/220889
<pitti> mdke: I added hardy tasks to all bugs now (please do that next time, too)
<tkamppeter> pitti, I have done the first test with UNMODIFIED s-c-p and an actual printer, but I had to remove a lot of packages to pretend that the HP LaserJet P3005 is not supported locally:
<pitti> tkamppeter: heh; Ubuntu printer support is *too* good :-P
<tkamppeter> sudo dpkg -P --force-depends openprinting-ppds-postscript-hp openprinting-ppds hpijs foomatic-db cups-driver-gutenprint
<mdke> pitti: bug 153124, to the extent that it is valid at all, is probably not fixed in either hardy or intrepid; bug 220889 should be fixed in both
<ubottu> Launchpad bug 153124 in dell "Firefox Non-English Start pages not localized properly" [High,Confirmed] https://launchpad.net/bugs/153124
<ubottu> Launchpad bug 220889 in ubuntu-docs "wrong 8.04 codename in Korean start page" [Undecided,Fix committed] https://launchpad.net/bugs/220889
<mdke> pitti: so should we be adding distro tasks to all of our bugs now?
<pitti> mdke: already done for those 5
<mdke> i mean, as a matter of common practice?
<pitti> mdke: but general rule is that a bug needs to be fixed in intrepid (well, the current dev release) until it is fixed in stables
<pitti> mdke: right
<mdke> yes, we generally treat a bug as fixed if it is fixed in intrepid
<mdke> it's only in the case of important bugs that we would consider fixing it in hardy
<mdke> but generally, most of our bugs (there are about 40 open) don't have specific distro tasks on them
<stefanlsd> Does anyone know how i get the download link for flash player?
<pitti> mdke: that's fine; I mean "the bug needs a hardy task if it gets an SRU for hardy"
<pitti> mdke: it doesn't mean that all bugs that you fix need intrepid tasks, or so
<mdke> pitti: got it, ok thanks
<pitti> mdke: please close the intrepid tasks in those two then; thanks
<pitti> mdke: btw, I recently filed bug 281143 with "almost" a patch (proposed text really); should I create a branch with it, or supply a diff, or how is that generally handled?
<ubottu> Launchpad bug 281143 in ubuntu-docs "restricted drivers description needs update" [Undecided,New] https://launchpad.net/bugs/281143
<doko> slangasek: I would like to get python-reportlab (2.2) into intrepid. the only use in main is the fax cover sheet generation in hplip, which tkamppeter did test with the new python-reportlab
<doko> any chance?
<slangasek> doko: what does an updated python-reportlab give us?
<slangasek> (bugfixes and or risks of regression^W^W^W features ;)
<doko> slangasek: for me, maintainance in one package (reportlab-accel and renderpm are built out of one source)
<slangasek> doko: but these don't seem like packages that should need SRUs for intrepid...?
<doko> well, I'll start writing a FF exception
<slangasek> ok
<lool> pitti: Can you promote python-fstab as well?  it's a dep of systme-cleaner
<lool> It was discussed shortly in the MIR IIRC
<tkamppeter> pitti, what about bug #271286, can you fix it in the Intrepid package?
<ubottu> Launchpad bug 271286 in jockey "Jockey should not only get "recommended" drivers from OpenPrinting" [Undecided,In progress] https://launchpad.net/bugs/271286
<pitti> lool: did you review it?
<lool> Yeah
<pitti> tkamppeter: yes, I have that prepared, I'll upload it today
<lool> as part of reviewing system-cleaner
<pitti> promoted
<lool> "From security and maintenance povs, python-fstab and system-cleaner seem ok for inclusion in main,[...]" when I did the initial review of both
<lool> I only required i18n for main promotion of system-cleaner (as it's in the menus when installed) and liw also fixed the 3 other bugs which I raised :)
<mdke> pitti: yeah I saw the bug; if you'd like to send a bundle or diff, that would be fine, otherwise one of the team will get to it after intrepid is released. It wasn't early enough for us to include it in intrepid, I'm afraid
<pitti> mdke: ok, I'll see what I can do
<mdke> pitti: thanks!
<davmor2> mvo: ping
<mvo> hi davmor2
<davmor2> mvo: alt cd upgrade has some issues
<mvo> davmor2: oh, what is wrong with it?
<lool> Hmm is there a way we can ask an arch: all package to be built on another arch than i386?
<slangasek> pitti, lool: python-fstab was already promoted :)
<slangasek> lool: nope
<lool> openhackware is ppc specific assembly, and produces an arch: all binary for use as a BIOS in qemu
<tkamppeter> pitti, if you get any ugly display when fixing bug 271286, note that the short discription can contain simple HTML formatting. This can be rendered correctly with the markup functionality of GTK. License texts are foreseen to be plain text though.
<ubottu> Launchpad bug 271286 in jockey "Jockey should not only get "recommended" drivers from OpenPrinting" [Undecided,In progress] https://launchpad.net/bugs/271286
<lool> Perhaps I should request a way to do this as a wishlist against soyuz?
<davmor2> mvo: I don't think it's major but I get an error window pop-up that reads "subprocess post-install script returned error exit staus 1" on package rarian-compat
<lool> We do have ppc, would be kind of sad to not have ppc qemu support here
<davmor2> mvo: also there is a polite pop-up informing me that my evo-alarm-notify might not work
<davmor2> mvo: other than that seems fine
<mvo> davmor2: riight, the rariant is a known issue, pitti has a fix
<mvo> davmor2: I have seen the evo thing too before - if its otherwise ok, I'm quite happy, then we are on a good way :)
<davmor2> mvo: I selected not to get update from the internet too so we knew it was all from the cd
<pitti> mdke: so can those two be closed?
<mvo> davmor2: thanks for that, that was what I wanted to have tested :)
<davmor2> mvo: about a minute left
<pitti> tkamppeter: I hope HTML works in treeviews too, I'll check
<lool> eh already reported as 217427
<davmor2> mvo: lastly it's thrown up a complaint that n-m could find all it's resources
<lool> Oh yeah, got that too
<davmor2> s/could/couldn't
<mvo> davmor2: thanks, I think asac was working on the "n-m could find all it's resources" bug (he said he has a fix ready
<lool> davmor2: I think it's because it needs new icons and they weren't gtk-update-icon-cached
<davmor2> okay well rebooting now
<tkamppeter> pitti, if needed replace the treeview by something else, I think it is more important to have the "This driver is a development version" in bold than having a treeview.
<pitti> tkamppeter: well, it's the only GTK widget which provides lists or trees :)
<pitti> tkamppeter: anyway, I'll figure it out
<davmor2> mvo: something isn't right but I need to go now.  I rebooted now I get no bars even in failsafe mode I think it maybe an nvidia thing but can debug when I get back
<mvo> davmor2: thanks, see you
<ogra> bryce, i cant imagine that fix in bug 222164 works without restarting X
<ubottu> Launchpad bug 222164 in xf86-input-evtouch "evtouch works incorrectly when the screen is left or right rotated" [High,Triaged] https://launchpad.net/bugs/222164
<asac> mvo: isnt that fixed?
<asac> err. i mean i think i uploaded the fix yesterday ;)
<asac> let me check
<mvo> asac: might be that it was just not on the CD that davmor2 tested yet
<mvo> thanks a lot for the fix asac!
<asac> mvo:  0.7~~svn20081015t194645-0ubuntu1
<asac> Published in intrepid-release 9 hours ago
<asac> fix LP: #277084 - ...
<asac> ;)
<mvo> excellent
 * mvo hugs asac
<asac> mvo: well ... dont hug before its confirmed ;)
 * mvo unhugs asac
 * asac hugs mvo 
<ogra> lol
<slangasek> StevenK: you appear to have uploaded libruby-extras recently, probably as part of NBS processing, but libruby1.8-extras still depends on libgems-ruby1.8; oversight?
<Nafallo> Keybuk: hey. you're aware pam-thinkfinger requires enter presses after the swipping in intrepid and that it is a regression from hardy, right? :-)
<Koon> mvo: apparently the sledgehammer patch for bug 278112 introduces at least as many regressions as it fixes things... so I'll let a compiz expert properly solve this one :)
<ubottu> Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112
<mvo> Koon: hmm, thanks. I had hoped it would be a usable fallback if no better solution can be found.
<mvo> Koon: thanks for your work on this!
<Koon> I seem to have a variation from the common case, black screen instead of the unlock password box
<Koon> mvo: I need to debug that first before I can be of any help in testing fixes
<slangasek> ogra: hmm, so linux-lpia is FTBFS?  This holds up NBSing of linux-headers-2.6.27-3 currently
<ogra> slangasek, amitk is on it
 * directhex hands slangasek cake, begins on work for mono 2.0 in jaunty
* slangasek changed the topic of #ubuntu-devel to: 8.10 beta released | archive: Release Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> wheee
<slangasek> ogra: ok, great
<slangasek> directhex: cake at 2am is not a good plan, I'll just put that in the fridge for the morning :)
 * ogra gets his coat
<ogra> gotten cold in here
<tkamppeter_> pitti, as license texts are given as plain text, can you display them with a fixed-width font and in a window which is wide enough for 80 characters of the fixed width font? Thanks.
<tkamppeter> pitti, and in the main description display, can you let the items about supplier and support come at first and the functionality as the last? This makes the case that the driver comes from the manufacturer more visible.
<pitti> tkamppeter: I shouldn't change the UI much any more; we just froze...
<pitti> (I hoped we'd freeze on Steve's Thursday...)
<pitti> tkamppeter: but I can change it in trunk, so that it'll be fixed in the future; maybe you ca report bugs about that?
<slangasek> pitti: it's been Thursday here for 2 hours
<pitti> tkamppeter: fixed font? for multi-paragraph text?  that looks pretty ugly?
<slangasek> FYI :)
<StevenK> Haha
<pitti> slangasek: yeah yeah, I'm just looking for more time to fix bugs :)
<slangasek> pitti: /you/ can have more time to fix bugs, that's fine :)
<StevenK> slangasek: Just him?
<slangasek> just him
<StevenK> Haha
 * ogra reassigns all his bugs to pitti
<pitti> slangasek: oh, btw, in the next days I planned to do some component-mismatches fixes; can I have a blanket approval to shove through things which just fixes depends/recommends and the like?
<slangasek> pitti: yes
<pitti> slangasek: since these packages are generally not ones I particularly care about, I don't think that there is a conflict of interest
<pitti> ok
<Laney> crimsun: Just the one audio device
<tkamppeter> pitti, if you display such a license with "less" in a terminal, it shows nicely, and it should show the same way in Jockey.
<tkamppeter> pitti, all lines in the paragraph end with newlines and at the end of the paragraphs there are two newlines (=1 empty line).
<tkamppeter> pitti, this should show perfectly with a fixed-width font like Courier.
<ogra> kwwii, !!!!! where is my wallpaper ?
 * ogra shrieks
<StevenK> ogra: I think your theme no longer exists
<tkamppeter> pitti, and this UI change does not break any freeze criteria, as it does not change the logic (for the documentation) nor the text content (for the translations).
<ogra> StevenK, apparently, ubuntu-mobile is without wallpaper now :/
<ogra> slangasek, seems i need a freeze exception for ubuntu-mobile-default-settings and add the wallapaer back :/
<kwwii> ogra: ???
<ogra> kwwii, mobile used the elephant skin as default wallapaer
<StevenK> ogra: That's a guess, though
<ogra> kwwii, its gone it seems
<ogra> with my last update here
<kwwii> ogra: it is sitll there, just as a jpg now
<kwwii> and under a different name
<kwwii> simple-ubuntu.jpg
<ogra> ah, k, then i only need to change the gconf key
<kwwii> :-)
<slangasek> ogra: ubuntu-mobile-default-settings seems to be in universe, so you don't need a freeze exception from me in any case
<ogra> slangasek, heh, yeah, sorry forgot about that .... i'm not used to ll that freedom yet :)
<ogra> hrm, the fusa message doesnt really make sense if you dont have any logout item on your panel
<slangasek> oh, I don't know about freedom, I'm just saying you don't need a freeze exception from /me/ ;)  the motu-release team's freeze guidelines, TTBOMK, are at https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html
<slangasek> but they may want to do some delegation for mobile as well
<ogra> slangasek, i'm the release manager for mobile :)
<sistpoty|work> ogra: you'd need one from yourself :P
<directhex> bribe yourself with cake.
<ogra> sistpoty|work, yeah, already mailing me :P
<sistpoty|work> heh
<ogra> hmm, all my menu items i had manually enabled on my desktop are hidden again ?
<ogra> do we muck about with user settings now ?
<seb128> no
<seb128> and GNOME packages didn't change recently
<ogra> weird
<sistpoty|work> slangasek: FYI current delegates are listed in https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026306.html
<seb128> indeed
<ogra> i definately enabled gconf-editor on that device
<ogra> but had to re-renable it now
<slangasek> sistpoty|work: ok; perhaps I should've referenced that page in the freeze announcement, ohwell :/
<slangasek> sistpoty|work: but I assume most of the affected people already know who they need to go to :)
<ogra> seb128, could it be that fusa runs something to restore defaults in its postinst ?
<sistpoty|work> slangasek: yes, I assume so as well
<ogra> because i also had the fusa logout change message
<ogra> (without having a logout item in the panel on mobile)
<seb128> ogra: no
<seb128> ogra: and menus items are in .local not in gconf anyway
<ogra> seb128, i used gconf-editor before the reboot from the menu ....
<seb128> ogra: do you have a gconf-editor item in .local?
<StevenK> ogra: Oh, what is happening with libflashsupport?
<seb128> .local/share/applications
<ogra> after reboot i had the fusa message, when i went to the menu then the editor was gone
<ogra> seb128, well, i enabled it again, so indeed there is a .desktop file now
<seb128> ogra: way to go for debugging ...
<ogra> seb128, but i'm pretty sure i had more items customized, gconf-editor is the only thing in that dir now
<seb128> ogra: you should try to figure what was wrong before workarounding the bug
<seb128> ogra: ok, so something cleaned your .local
<ogra> seems like
<seb128> ogra: the layout migration does only very selective gconf changes so that's doubtfully it
<ogra> and i assume update-gconf-defaults is safe and doesnt do such stuff either
<seb128> ogra: it touchs only system gconf locations
<seb128> there is no packaging tools changing .local in any way
<mvo> ogra: if you just saw the message and did not click on "update" then nothing happend to your gconf, its just a message. if you did click, then not a lot happend either :)
<ogra> yeah
<cjwatson> liw: ooh, system-cleaner promoted. Now where are we seeding it?
<ogra> mvo, i sadly didnt click, i should have to see what happens on mobile
<ogra> since we dont have any logout item on the panel
<mvo> ogra: it would have told you "no logout button found, please update manually"
<ogra> ah, good
<mvo> ogra: no worries, defensive code
<ogra> wouldnt affect new installs anyway, but i was slightly worried about the handfull of testers getting their panel setup trashed :)
<mvo> ogra: the migrate-fusa-config.py would not do that, run the trash-panel-setup.py instead
<ogra> though that gconf thing is pretty weird ... and i dont really see a way to reproduce it
<ogra> haha
<mvo> ogra: seriously, we had oddness with gconf defualts in the past
<ogra> right, i remember that
<mvo> but we never managed to reproduce it or get any clue why some defaults would not update
<ogra> though i wouldnt know why anything would touch .local
<seb128> in this case that's not a gconf issue
<seb128> but local datas which vanished
<mvo> stuff in ~ should really be safe
<seb128> are you sure you didn't clean those?
<ogra> seb128, well, as i said, i looked at the gconf key for the wallapaper using gconf-editor from the menu
<seb128> I don't deny that
<ogra> then i rebooted and my menu missed the systemtools category
<seb128> but there is nothing touching .local
<seb128> so it's weird that it got changed
<seb128> did you get a fsck running?
<ogra> the only thing i did before looking at the menu was confirming the fusa question
<ogra> nope
<seb128> either that's a local issue
<ogra> i'll watch for it on other upgrades
<seb128> or ted added some code to clean your menus because you were complaining about fusa yesterday ;-)
<ogra> gconf-editor is enabled on all my systems usually, i will notice if it goes away
<dholbach> argh, my machine just froze
<ogra> seb128, ah, indeed, that would be it
<dholbach> no, magic sysrq, nothing
<mvo> dholbach: which one?
<dholbach> amd64, intrepid
<mvo> video card?
<dholbach> nv
<mvo> hmmm
<ogra> call the vendor
 * dholbach slaps ogra
<ogra> :)
<mvo> I had a freeze yesterday with compiz/r500/ati :/
<dholbach> . o O { free software shit }
 * dholbach takes a look at the logs
 * ogra logs out of dholbach's machine again
<mvo> dholbach: CoC!
 * mvo hugs dholbach
<kwwii> seb128, mvo, pitti: did you get and email from me about the gnome-themes stuff? (Not to mention the FUSA situation)
<persia> Hrm?  That's not a CoC issue.  It's only.
<persia> !ohmy
<ubottu> Please watch your language and topic to help keep this channel family friendly.
<kwwii> mvo: it is these aggresive community people
 * mvo sticks his head in the sand
<dholbach> -- MARK --
<dholbach> nice
<StevenK> dholbach: -- MARK -- is useful
<ogra> oh, he ws logged in as well ?
<mvo> aha! I suspected it might be HIM
<lool> mvo: Oh you're running ati compiz now?  I'm really happy we have free 3D on r500 now
<persia> dholbach, Well, when it freezes, it's frozen.  You probably want a serial console to chase it.
<lool> mvo: I couldn't suspend / resume with it though
<mvo> lool: yes, it just tends to freeze
<mvo> lool: but I suspect that is a thermal problem of the laptop its pretty bad with it
<dholbach> I just thought I'd might find something somewhere
<mvo> lool: hm, I think that worked, but I'm not 100% positive
<lool> I didn't get freezes when using xorg with ati yet; I had various issues with intrepid in general, or when doign specific things, but not just using compiz
<ogra> Keybuk, i'm waiting to be able to test fusa before i close the ldm task on the bug
<ogra> for some reason it wasnt available yet for my vbox ltsp install
<ogra> hmm, it still isnt
<pitti> kwwii: answered
<kwwii> pitti: and I already sent a reply :-) Thanks!
<ogra> can some archive admin let my ubuntu-mobile-default-settings through ?
<liw> cjwatson, re seeding of system-clenaer: I would suggest system-cleaner in the standard seed, and system-cleaner-gtk in the desktop seed; does that sound reasonable?
<pitti> ogra: done
<ogra> mvo, hmm, my ltsp testserver in vbox still has xscreensaver installed and i didnt get any dist upgrade option, isnt that supposed to go away on one of the upgrades ?
<pitti> liw: -gtk in deskto, and system-cleaner in server perhaps?
<ogra> pitti, merci
<mvo> ogra: yes - what version of ubuntu does it run?
<ogra> intrepid
<mvo> ogra: and it was upgraded from what version?
<ogra> xss was installed at some point from recommends
<ogra> it was intrepid all the time
<cjwatson> liw: either that or pitti's suggestion is fine by me
<liw> cjwatson, pitti: server instead of standard is very much ok with me
<emgent> heya
<Riddell> anyone know about libcap?
<ScottK> slangasek: motu-release has concluded that it does not want to start approving every Universe/Multiverse upload until after the RC is released (i.e. a week from now).  For now it should be the same as the Beta freeze.
<Riddell> ScottK: what was beta freeze?
<mvo> Riddell: a bit, what the issue?
<ScottK> Riddell: Unless it needs and FFe, ubuntu-release just shoves Universe/Multiverse stuff through.
<ScottK> and/an
<Riddell> mvo: bug 248577 has been assigned to me, but I really don't know what it's about
<ubottu> Launchpad bug 248577 in avahi "avahi-daemon uses 32 bit legacy capabilities on AMD64" [Low,Triaged] https://launchpad.net/bugs/248577
<Riddell> mvo: or whether it's something we should care about now we're frozen
<mvo> Riddell: uhh, I can have a look after lunch
<liw> cjwatson, ok, I've figured out how to add things to seeds, I think, but I can't bzr push since I am not core-dev; should I give you a patch/bundle or something?
<liw> stdin, ping
<cjwatson> liw: either push to lp:~liw/ubuntu-seeds/some-name and mention the branch name for merging, or send an ordinary patch
<liw> cjwatson, ack, sent
<liw> stdin, I got the fridge bot's date parsing code to run, at least (it crashed on my laptop on an unknown WKST keyword arg, fixed that)
<persia> liw, So it understands recurrance now (or could if your changes were merged)?
<liw> persia, I don't know yet, but at least it doesn't crash
<persia> That's a start :)
<liw> persia, would you happen to know what the exact problem is?
<persia> liw, Precisely, when there is a recurring scheduled meeting, the bot only sees the first occurrence, and doesn't report repeats.
<persia> As a result, the #ubuntu-meeting schedule is a bit funny.
<persia> There's a human trying to copy stuff, but that's suboptimal.
<jdstrand> mdz_: hi! so I have been watching bug #263059 with interest because I see these hangs too, but I have an ipw2200 in my t42 laptop. as the bug is so iwl3945-centric, I didn't want to cloud the issue.
<ubottu> Launchpad bug 263059 in linux "[regression] 2.6.27-7 sometimes fails to boot (iwl3945 issue?)" [High,In progress] https://launchpad.net/bugs/263059
<jdstrand> mdz_: should I add my dmesg, photo and lspci to that bug or another?
 * directhex awaits jaunty for his new laptop, intrepid is too ooooold
<mdz> jdstrand: please open a separate bug, we can always dupe it if appropriate
<mdz> jdstrand: please try DebuggingSystemCrash, it may not be the same bug
<jdstrand> mdz: ok, I'll add a 'could be related to...' note to it. thanks
<dholbach> why was example-content 34 rejected?
<mdz> jdstrand: and report it with "ubuntu-bug linux"
<Riddell> dholbach: I got the kubuntu-flyer source from kwwii so I'll reject your example-content upload and add the source and reupload based on that version 34
<dholbach> Riddell: ok
<dholbach> Riddell: let me know when you've accepted it, so I can add the changes to bzr
<Riddell> dholbach: there's a bzr?  I looked but didn't see one
<Riddell> oh, debian/control knows it
<dholbach> no, that needs changing too
<dholbach> lp:example-content
<dholbach> it's ubuntu-core-dev now, not ubuntu-art-pkg
<liw> stdin, I can't seem to figure out the real problem in an hour, but http://paste.ubuntu.com/58326/ should be a necessary fix anyway
<dholbach> the core-dev branch was marked as 'merged' instead of 'mature' - that's why it probably didn't show up
<dholbach> I just changed that
<Riddell> dholbach: accepted, I can put it in bzr if that's easier
<dholbach> as you like it, I can do it too
<dholbach> Riddell: but right now it does not get installed - what's your plan?
<dholbach> ah, you updated the kubuntu-leaflet.jpg too - nevermind
<dholbach> Riddell: pushing to branch - thanks
<Riddell> dholbach: I've already committed, I win!
<siretart> asac: I've added your last vlc upload to our bzr branch.
<Riddell> dholbach: I don't want the .svg installed, it's just the source
<dholbach> alright :)
<asac> siretart: sorry
<asac> siretart: didnt notice apparently
<siretart> no problem
<asac> siretart: do you have a EAP setup somewhere?
<siretart> asac: but perhaps you can explain me what's the deal with these UUIDs in debian/control
<siretart> asac: do we want them in debian as well?
<asac> siretart: its for the plugin finder service. the uuids indicate which application this plugin works on
<siretart> asac: what is the 'plugin finder service'? isn't that in debian as well?
<asac> siretart: the new fields are required for advanced features
<asac> siretart: http://people.ubuntu.com/~asac/tmp/pfs1.png
<asac> siretart: http://people.ubuntu.com/~asac/tmp/alt1.png
<siretart> my university is doing TTLS with PAP as inner authentication. so no EAP
<siretart> asac: so that's only for firefox? no epiphany, konqueror etc love at all?
<siretart> asac: and do you plan to port that plugin finder to iceweasel as well?
<asac> siretart: it doesnt need to be ported. it just needs to be uploaded and the database needs to also provide info for etch/lenny/sid etc.
<asac> siretart: i suggested that to debian mozilla maintainers at some point and they didnt really cheer for it.
<asac> siretart: but we can retry ;)
<asac> or just do
<siretart> asac: do you have a bug number were I can read their response?
<asac> siretart: someone would need to write a wizard for epiphany and konqueror
<siretart> asac: I'm wondering if it is worth to push these changes to debian as well. that's why I'm asking
<asac> siretart: hmm. i am not sure where that happened. i can look that up asap
<asac> siretart: imo its worth it.
<asac> siretart: for instance: gnuzilla tries to provide a plugin finder service with just free plugins
<siretart> asac: I'd think a bug in debbugs would be useful in any case. that way we can at least point people if they are wondering what these ids are about
<asac> but that doesnt work because there  are no binaries available on the net
<asac> but debian can do that by just including main plugins
<siretart> asac: what package in ubuntu implements that 'plugin finder'?
<asac> ubufox
<siretart> aah, so that's what this ubufox is about
<asac> mostly yes.
<siretart> ok. thanks for clarification
<ogra> pitti, can you approve linux-lpia ?
<torkel> asac: is TLS with client certificates supposed to be working in n-m (intrepid)?
<asac> torkel: well. i guess it doesnt work for you?
<asac> of course its supposed to work ;)
<asac> torkel: do you see anything in syslog?
<torkel> asac: thought so. So it must be DBTK :-)
<asac> torkel: i think there might be a bug as we also have issues with WPA-EAP
<asac> torkel: whats the exact problem?
<torkel> asac: it seems it succeeds with authentication, but fails with association (association with AP XX:XX:XX:.. timed out)
<asac> torkel: could you please open a bug and attach your complete syslog there and then point me to it?
<asac> torkel: i would like to test then something ;)
<torkel> on the other hand the wpa_supplicant log complains that it fails to verify the certificate, so that may very well be the problem
<asac> oh
<asac> torkel: yes. please do the above. i will give you instructions what exactly to test then
<torkel> asac: sure. Not sure I will have time to it today though. I'm off in about 45 minutes
<asac> torkel: please today ;)
<asac> torkel: if not, just file the bug and lets continue asasp
<torkel> asac: sure
<torkel> asac: bug 284409
<ubottu> Launchpad bug 284409 in network-manager "Fail to connect with TLS and client certificate" [Undecided,New] https://launchpad.net/bugs/284409
<jdstrand> mdz: fyi-- filed my t42 boot hang (non-iwl3945) as instructed as bug #284406
<ubottu> Launchpad bug 284406 in linux "[regression] boot failure with thinkpad laptop" [Undecided,New] https://launchpad.net/bugs/284406
<asac> jdstrand: what is non-iwl3945? ath8k?
<jdstrand> asac: ipw2200
<asac> oh
<asac> jdstrand: is it broken now?
<jdstrand> so, still intel
<asac> (after the associate= fix)?
<jdstrand> asac: it shows just like bug #263059
<ubottu> Launchpad bug 263059 in linux "[regression] 2.6.27-7 sometimes fails to boot (iwl3945 issue?)" [High,In progress] https://launchpad.net/bugs/263059
<jdstrand> asac: but I filed separately per mdz's instructions
<asac> jdstrand: did this start with the last upload?
<jdstrand> asac: no, I don't think so. the problem is, I don't use this system that much... I know I got occasionaly boot hangs during intrepid, but haven't tried to troubleshoot until today
<jdstrand> :(
<asac> torkel: self-signed cert. is that what you are using?
<asac> siretart: any idea if we can make wpasupplicant accept self-signed certs? or whether thats an issue at all? 284409
<torkel> asac: no. It shouldn't be
<asac> torkel: thats what i see in the log you posted
<asac> torkel: TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 2
<asac> torkel: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
<asac> so your CA appears to be not known
<asac> torkel: http://www.madboa.com/geek/openssl/#verify-standard
<asac> torkel: can you try that?
<torkel> asac: seems to be working if I drop the CA certificate from the connections editor
<asac> torkel: well. then you dont use tls?
<torkel> but the certificate verfied OK (with openssl verify)
<torkel> and now I get "Updating connection failed: client cert", when trying to readd the CA cert
<siretart> bug 284409
<ubottu> Launchpad bug 284409 in network-manager "Fail to connect with TLS and client certificate" [Undecided,Incomplete] https://launchpad.net/bugs/284409
<torkel> asac: should't I be able to specify as CA path instead of a CA certificate?
<tedg> kwwii: Is this one in your theme update?  bug 278006
<ubottu> Launchpad bug 278006 in human-theme "The red square 0/1 icon doesn't fit in a standard 24 pixel panel" [Undecided,Confirmed] https://launchpad.net/bugs/278006
<siretart> asac: you need to specify a root certificate in any case. so it doesn't matter
<torkel> or does N-M/wpa_supplicant search in /etc/ssl/certs by default?
<siretart> asac: TBH, that bug looks to me like an invalid certificate, or the root certificate was not specified
<siretart> torkel: no. you need to add the root CA to your config
<asac> siretart: oh ... that explains it
<geser> what's the current process to get a security fix synced from Debian? ask first the release-team for an ack and then subscribe u-m-s or vice versa?
<asac> siretart: why would we need to add the root cert if the root CA is a well known one?
<siretart> asac: err, please rethink about that
<siretart> asac: the root CA cannot be a well known one. it needs to be site specific so that you get any security benefit
<jdstrand> geser: I followed SyncRequestProcess recently and it went fine
<jdstrand> geser: eg bug #281456
<ubottu> Launchpad bug 281456 in ruby1.9 "Please sync ruby1.9 1.9.0.2-7 (main) from Debian unstable (main)." [High,Fix released] https://launchpad.net/bugs/281456
<nazgul> hi asac . I believe the prio of launchpad Bug #259214 should be raised as it severely cripples static network config. My comment is the last one on this bug.
<ubottu> Launchpad bug 259214 in network-manager "wired connection settings are lost after reboot" [Medium,Confirmed] https://launchpad.net/bugs/259214
<jdong> is it a known bug that if the magical logout button starts before g-p-m (which always seems to be the case) the suspend/hibernate buttons don't show up?
<Keybuk> no
<Keybuk> please file that
<cjwatson> TheMuso: FYI I've targeted bug 275233 since heno flagged it
<Keybuk> tedg: ^^
<ubottu> Launchpad bug 275233 in libcanberra "canberra-gtk-play crashed with SIGSEGV in pa_operation_unref()" [Medium,Confirmed] https://launchpad.net/bugs/275233
<jdong> Keybuk: what package is the logout applet in?
<Keybuk> jdong: fast-user-switch-applet
<jdong> Keybuk: thanks
<tedg> jdong: Send me the bug number.
<jdong> already filed; bug 278810, tedg
<ubottu> Launchpad bug 278810 in fast-user-switch-applet "Doesn't always display suspend / hibernate options (race between g-p-m and f-u-s-a?)" [Undecided,New] https://launchpad.net/bugs/278810
<tedg> Keybuk: what do you think about the change on that bug?
<jdong> does g-p-m correctly show up in the panel if it starts before the panel does?
<Keybuk> tedg: -v
<jdong> Keybuk: proposed X-GNOME-Autostart-Phase=Windowmanager for g-p-m's xdg entry
<tedg> Keybuk: It basically changes GPM to start up with the window manager.
<tedg> jdong: Could you try setting the phase to "Panel" to see if that works?  I'd be happier with that.
<Keybuk> isn't that just leaning the race in one direction?
<Keybuk> g-p-m may still not be on the bus in time
 * jdong agrees with Keybuk 
<jdong> can f-u-s-a poll for g-p-m if it's not immediately available?
<jdong> I know the p-word is bad these days too :)
<tedg> Not really leaning, I believe that gnome-session completes phases before continuing on.
<Keybuk> tedg: how does it know that g-p-m is on the bus?
<jdong> tedg: I think Keybuk is saying g-p-m started doesn't imply it's on the bus
<kwwii> tedg: I looked into that...the icon is 24x24 (and 22x22) so I cannot figure out where that comes from
<asac> nazgul: you cannot save a auto generated connection. so you either have to rename it or to create a new one
<asac> nazgul: then it should work
<kwwii> tedg: my update only kills the little green man (and adds an svg for the computer icon)
<tedg> Keybuk, jdong: Yes, I guess it doesn't guarantee, but man, it works for most users in the Application phase now.  I imagine changing to Desktop would fix it, much less Panel or WindowManager.
<Keybuk> it's not a fix, the race is still there
<jdong> well it's a tmporary workaround
<tedg> kwwii: Okay, well what is the size of the icon when it's an IM status one?  Perhaps it needs 18px or 16px?
<RicardoPerez> mvo: ping
<tedg> Keybuk: correct, not a fix, but a one line change to a desktop file.
<mvo> RicardoPerez: pong
<Keybuk> which doesn't fix the problem, just reduces it
<RicardoPerez> mvo: Hi, Michael. Can you tell me if the packages description translations are up to date into Intrepid?
<RicardoPerez> I can see translations done on 2008-08-14 which aren't in Intrepid's Translation-es
<jdong> tedg: is it prohibitively difficult to have the applet check occasionally for the presence of g-p-m?
<mvo> RicardoPerez: not currently, I want to that this week. I had hoped to be able to merge from debian but debian does currently not export them
<mvo> RicardoPerez: the lastest upload if from ~20080812 - high time for a new one
<mvo> RicardoPerez: do you know about  http://people.ubuntu.com/~mvo/nightmonkey/ btw?
<RicardoPerez> mvo: oh, great
<RicardoPerez> mvo: mmmm sorry, I didn't knew. What's that?
<tedg> jdong: No, it is not.  But it'll be a larger code change.  If you can convince the release team to accept it, I'll code it :)
<mvo> RicardoPerez: it make  finding the right strings in the translations in rosetta easier for the descriptions
<kwwii> tedg: 16x16
<mvo> RicardoPerez: I request a export now, it usually takes a bit until its done (some hours)
<RicardoPerez> mvo: Oh, sounds great!
<RicardoPerez> mvo: I'll take a look, but sounds very interesting :)
<kwwii> tedg: but that icon does not exist at that size
<RicardoPerez> mvo: Thank you very much for the update request!
<kwwii> tedg: and the svg is also square so it cannot come from that either
<tedg> kwwii: So that's probably why it's getting cropped.  Pulling in a larger one and trying to make it 16px
<mvo> RicardoPerez: I need to write something about it, it was done Nyitrai and should really make the translation work for the package descriptions easier
<mvo> (hopefully :)
<mvo> thank RicardoPerez
<kwwii> tedg: yeah, could be
<RicardoPerez> mvo: "ok" means "translated"?
<mvo> RicardoPerez: yes
<RicardoPerez> mvo: great, it's a very useful tool!
<Riddell> persia: you uploaded casper?  editing ubiquity-gtkui.desktop at the end of that script won't help for the copy in ~/Desktop
<RicardoPerez> well, thanks again, bye!
<jdong> Riddell: while you're here, can you comment on tedg and my discussion regarding GNOME's fast user switching applet?
<RicardoPerez> mvo: btw, are you into Compiz developing, too?
<persia> Riddell, Yeah, but nothing in ~/Desktop is visible in Ubuntu MID, so I don't really care.
<RicardoPerez> s/developing/development/g
<mvo> RicardoPerez: I maintain the packages
<mvo> (well, with the compiz team)
<RicardoPerez> mvo: I've found that compiz takes too much time to start during GNOME startup... Makes GNOME idles for about 4-5 seconds
<RicardoPerez> what can be done with that bugreport?
<Riddell> persia: ok, accepting
<jdong> RicardoPerez: I've always wondered what that lag is, too.
<jdong> it's not really an idle as much as it is a UI hang
<persia> Riddell, Thanks.
<RicardoPerez> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/284366
<ubottu> Launchpad bug 284366 in gnome-session "GNOME has ~4 seconds idle during startup" [Low,Incomplete]
<mvo> RicardoPerez: I have not profiled it, but I strongly suspect its the xml parsing it does on startup
<Riddell> jdong: seems like a gnomey change, what do you want me to add?
<RicardoPerez> jdong: so you've see that issue, right?
<jdong> Riddell: something along the lines that if tedg takes the time to code up that, then release team will allow the upload
<RicardoPerez> mvo: great, I don't know if that bugreport should be redirected from gnome-session to compiz...
<ScottK> jdong: Can you go ahead and get intrepid-backports set up?  asac is interested in pushing Firefox-3.1 packages there ASAP after release.
<jdong> RicardoPerez: yes. on all of my systems. I think it's something related with AIGLX
<jdong> ScottK: ok. That's probably an infinity job, right?
<RicardoPerez> jdong: but I'm not using AIGLX, but NVIDIA
<ScottK> jdong: Dunno.  You're Mr. Backports.
<jdong> RicardoPerez: I haven't looked at the code yet for compiz. it for me happens after compiz takes over the UI, hanging all of the windows for some time
<jdong> RicardoPerez: you can see that from running compiz --replace
<RicardoPerez> jdong: "compiz --replace" from metacity, right?
<jdong> RicardoPerez: or from compiz itself.
<RicardoPerez> jdong: mmm, ok, let's see
<jdong> RicardoPerez: for me it takes about 2.5secs of fidgeting around before it settles
<jdong> similar to what's done on login
<Riddell> jdong, tedg: having g-p-m check for dbus periodically seems the sensible thing to do, I expect it would get accepted if it was suitably tested, ScottK just did a similar fix in our g-p-m
<ScottK> I extracted the interval of 30 seconds from the usual place and used that.
<tedg> Riddell: It doesn't need to poll, just listen to DBus namechange requests.
<tedg> Riddell: You guys have a copy of gpm that's different?
<ScottK> We have Guidance Power Manager
<ScottK> Totally different beast with an unfortunately similar arcroynm
<RicardoPerez> wow. sorry. crash after compiz --replace
<tedg> ScottK: Ah, okay.  How confusing.
<tedg> It was kinda like them replacing gnome-vfs with gvfs.
<RicardoPerez> well, not exactly a crash, but renders all the windows unusable
<jdong> RicardoPerez: sounds like a bug :)
<RicardoPerez> jdong: I've done "compiz --replace", but it isn't take 5 seconds, but < 2
<jdong> RicardoPerez: right, but that's after startup with no activity
<RicardoPerez> however, the bug I reported appears even when you log out & log in then...
<RicardoPerez> jdong: I've just done "compiz --replace" again, and all works OK, without idle
<RicardoPerez> jdong: I just repeated "compiz --replace" one more time, and again I had no idle
<RicardoPerez> jdong: however, If I log out and log in again, I have a ~5 seconds idle...
<cjwatson> RicardoPerez: the translations import queue is only up to 2008-10-08 right now, so some things are still behind
<cjwatson> RicardoPerez: (even aside from any manual exports that are needeD)
<cjwatson> s/D/d/
<cjwatson> RicardoPerez: the good news is that it is catching up
<RicardoPerez> cjwatson: great, thanks a lot for the news. It could be great if the queue were reduced ;)
<cjwatson> RicardoPerez: yeah, it's getting there; it was only up to, er, something like 2008-10-03 this time yesterday
<RicardoPerez> cjwatson: ok, thank you very much again for your i18n efforts ;)
<mdz> bryce: bug 275285 and bug 274045 are the last remaining Intrepid targeted bugs in main without an importance set.  could you evaluate their importance?
<ubottu> Launchpad bug 275285 in xorg-server "[intrepid] Flash, VirtualBox, Dosbox etc. video freezes after few seconds" [Unknown,Confirmed] https://launchpad.net/bugs/275285
<ubottu> Launchpad bug 274045 in xserver-xorg-video-intel "[intrepid alpha6] X.org cannot find PLL settings for mode" [Undecided,Confirmed] https://launchpad.net/bugs/274045
<ogra> seb128, hmm, my evo has some folders again where it doesnt clean out the status
<seb128> ogra: what do you mean?
<ogra> seb128, showing unread mails where there are none
<james_w> archive admins: libruby1.8-extras just built, so libgems-ruby1.8 should be possible to clear from NBS
<ogra> s/where/while/
<ogra> seb128, gdmsetup has the old bug of taking a century to come up again it seems
<seb128> ogra: nobody else complained about either of those
<ogra> seb128, i just noticed them, sorry
<seb128> ogra: are you sure that evo is just not updating the count but not the list? ie switching to an another box and back to this one
<ogra> tried already
<ogra> i'll close and open it again, lets see what it does then
<ogra> ok, closing it fixed that
<ogra> might be becase i rebooted after the upgrade
<ogra> i should probably close it first after upgrades before rebooting
<ogra> could some archive admin process linux-lpia please ? i pinged pitti before but seems that was swallowed by his outages
<calc> does transmission no longer minimize to notification area?
<sebner> calc: asking myself the same
<kirkland> slangasek: ping
<kirkland> slangasek: hey, i'd like to fix pam_ecryptfs now, if possible
<kirkland> slangasek: i'm looking at pam_sm_chauthtok()
<calc> ugh, nautilus displays the full mimetype name in the properties next to the human description
<calc> this makes nautilus properties window REALLY wide for some file types
<ogra> not here
<ogra> did you play with the options ?
<calc> ogra: i don't think so, hmm i'll look for the option to fix it
<calc> ogra: i didn't do a fresh install so maybe its some old setting i forgot about
<calc> i don't see an option in nautilus to adjust that
<calc> eg i get: "PowerPoint 2007 slideshow with macros enabled (application/vnd.ms-powerpoint.slideshow.macroEnabled.12)"
<calc> all on one line
<calc> which makes a 918x433 nautilus property window
<ogra> hmm, there is a mime type checkbox in the settings for listview
<ogra> but thats unchecked by default
<calc> ah, looking now
<calc> ogra: is that in nautilus or gconf?
<ogra> nautilus
<ogra> third tab in the settings
<ogra> err
<ogra> fourth, sorry
<calc> well this is in properties not in the nautilus list view
<calc> and that option is disabled for me
<calc> the properties view (right click on file) is where i am seeing it
<kirkland> slangasek: ah, i see now you have an almost-working patch;  i'll take it from there
<calc> hmm i need to determine how to make these icons look better as well, they are just plain paper icons for the Office 2007 files :\
<calc> is that something set in the shared-mime-info files or something else?
<calc> hmm i see the mimetype name for the icon file
<kirkland> slangasek: i do need you to explain one thing to me...
<kirkland> slangasek: if the two new passwords DON'T match, why do we even get to pam_ecryptfs in the stack?
<kirkland> slangasek: why doesn't pam just bomb out at that point
<kirkland> slangasek: like it does when you give a "wrong" current password
<kirkland> slangasek: ohhhhhhhh
<kirkland> slangasek: see /etc/pam.d/common-password
<kirkland> slangasek: pam_ecryptfs.so is just below pam_permit
<kirkland> slangasek: which, according to the inline comments, "primes" the stack with a positive return value
<ogra> mdz, amitk has a Q1 and knows the problem, do i really need to put the info on the bug ?
<ogra> (its just the paperwork to a probelm we already worked out the solution for on irc)
<cjwatson> ogra,amitk: linux-lpia accepted
<ogra> cjwatson, merci :)
 * ogra has lrm and -meta sitting on the disk waiting for the build to be done :)
 * ogra needs to go help moving some furniture around, back later
<mdz> ogra: if you've already agreed with Amit what needs to be done, please document that in the bug
<mdz> ogra: I've never heard of a PCI quirk controlling which driver is selected...
<nazgul> asac: ok thanks. I will file an upstream bug then.
<asac> nazgul: if you do, please post the bug in launchpad bug too
<asac> nazgul: or add it as upstream task. thanks
<asac> nazgul: (and set ubuntu status to triaged)
<jdstrand> jdong: ping re jhead
<jdong> jdstrand: sup?
<jdstrand> jdong: can you respond to Steven M Christey's questions-- he CC'd you on your @ubuntu address
<jdong> jdstrand: yeah let me grab a diff of jhead and see exactly what the author fixed
<jdstrand> jdong: cool, thanks!
<pitti> I can haz an interweb plz??
<amitk> mdz: i didn't suggest a quirk to select the driver. I suggested removing certain PCI IDs from the driver if they didn't work. But for the ath5k this is moot until rtg rolls out the wireless backports. ath5k has known issues in 2.6.27.
<Treenaks> pitti: Even more interwebs?!
<cjwatson> mdz: the lbm bug is done now FYI (once the binaries get through new anyway0
<pitti> Treenaks: the one which just started working again is quite alright
<cjwatson> )
<pitti> ogra: someone beat me to it
<mdz> cjwatson: is the bug number in .changes so I can forget about it?
<mdz> amitk: that makes more sense. the bug report says a quirk.
<cjwatson> mdz: yes
<asac> amitk: whats the idea of these "backports" driver packages. i understand that everything that comes late goes there, but how does this fix normal users? is there an easy mechanism so users that have issues can switch to the backport modules?
<amitk> asac: backports will not be a default install. Users experiencing problems with the in-kernel drivers can choose to try out new drivers from backports. But they are not heavily tested. We've used backports to supply users with latest alsa and wireless bits before.
<asac> amitk: ok. so backport modules are not something that help the normal user experience.
<amitk> asac: not out of the box.
<asac> i understood that. just wondered why we ship them or if there is a way we communicate to the user "hey, your current card doesnt work, but you could try the backports"
<amitk> asac: i don't know of any formal communication about it. So these suggestions are made or IRC/Mailing lists/Forums, etc. No jockey-like interface.
<asac> i see
<amitk> hope that answers your question...
<asac> amitk: its just that it sometimes feels a bit like: "well, some chipsets just dont work. as long as we have backports this isnt really release critical"
<asac> of course thats an exaggeration ... so excuse that ;)
<asac> it just means that for an "outsider" like me its not really obvious when wireless breakage is considered release critical and when a fix in backports is enough
<amitk> asac: if a 'few' patches fixed a driver to make it work we would apply it to the ubuntu tree. Backports are usually done when there are significant changes to the underlying subsystem so that while fixing newer chipsets it also introduces regressions.
<amitk> asac: in the above case, rtg is planning to just grab upstream wireless.git (that will probably be merged in 2.6.28) and compile it against 2.6.27.
<asac> amitk: ok thats understood
<asac> amitk: but when does the kernel team consider a problem critical enough to do a proper fix in the current stable tree
<asac> even if it might not be trivial?
<sharms_> are there any downsides if I run intrepid using ld.so.nohwcap?
<asac> a problem == a problem in wireless
<asac> amitk: sorry, i guess you are actually the wrong one to talk about that ;)
<asac> lets carry that somewhere else ;)
<asac> and discuss during UDS ;)
<ogra> amitk, so ath5k wil be removed from -generic as well ?
<amitk> asac: alright :)
<amitk> ogra: no. In case of the Q1 I only intended to remove the pci id for that particular chip in the Q1.
<ogra> ok
<asac> amitk: and go for ndiswrapper instead? (when the driver isnt loaded)
<asac> or what is the other option for ath5k users?
<amitk> asac: madwifi?
<ogra> asac, ath_pci works fine on the Q1 ...
<asac> amitk: err. and what about wpasupplicant?
<asac> there is no madwifi module for that anymore
<asac> hmm
<asac> ogra: on intrepid. good to hear then
<ogra> yes
<asac> ok thanks. i guess thats good enough then
<asac> wasnt aware that ath_pci now properly supports wext
<ogra> well, i havent heard any bad reports so far
<ogra> i only use WEP myself here
<asac> ogra: where is the last image?
<asac> latest i mean ;)
<ogra> http://cdimage.ubuntu.com/ubuntu-mobile/intrepid/current
<asac> ok easy enough
<asac> now you should add instruction sin that directory too ;)
<asac> ogra: ^
<ogra> ??
<ogra> for what ?
<asac> how do i use this image ;)
<asac> for beginners
<ogra> https://wiki.ubuntu.com/MobileTeam/Mobile/HowTo
<slytheri1> Can any archive admin please process bug 267816. The last time it was processed only source was moved to universe.
<ubottu> Launchpad bug 267816 in cglib2.1 "Please move to universe" [Undecided,Fix released] https://launchpad.net/bugs/267816
<amitk> asac: WPA will have to wait till we can fix ath5k i guess.
<ogra> asac, its all pointed out in the #ubuntu-mobile topic
<asac> ogra: hehe. yeah. whatever, having those in the directory would be helpful ;)
<ogra> yeah, i'll consider that for final
<ogra> ayway
 * ogra actually goes to do what he said before and moves some furniture now 
<slytheri1> slangasek: now that cglib2.1 is in universe, can you please also take care of libxstream-java? bug #268538. Or do I need a new ack?
<ubottu> Launchpad bug 268538 in libxstream-java "Please move package to universe" [Wishlist,New] https://launchpad.net/bugs/268538
<tkamppeter> pitti, I have installed the newest Jockey and want to test the situation when there are two drivers for one printer. How can I switch Jockey to also idownload and install real binary packages (I also need it for general testing)?
<pitti> tkamppeter: /usr/lib/python2.5/site-packages/jockey/detection.py, line 562; remove the 'architectures': 'noarch'
<tkamppeter> pitti, I have done so and do not get any answer on printer_deviceid:MFG:Samsung;MDL:ML-1610;CMD:GDI;, nor on printer_deviceid:MFG:Epson;MDL:Stylus Photo 1290;
<tkamppeter> pitti, with the second I tried to trigger Gutenprint
<pitti> tkamppeter: did you sudo killall jockey-backend? it only times out after 10 minutes
<tkamppeter> Thank you, pitti, now it works (the 10 minutes passed).
<pitti> tkamppeter: you can use above killall, too, then the GUI will just start a new backend
<tkamppeter> pitti, I have done so and it told that the process has already gone away.
<pitti> ah :)
<pitti> tkamppeter: in future versions I want to make this configurable, but right now jockey doesn't have a configuration thingy so far
<tkamppeter> pitti, now I have requested printer_deviceid:MFG:Samsung;MDL:ML-1610;CMD:GDI; and I get only one entry, not two (aplix, splix2).
<tkamppeter> s/aplix/splix/
<pitti> tkamppeter: right, that's because they both have the same package name (the bug I mentioned as "disambiguate")
<pitti> I have a rough idea how to fix this, but didn't yet
<tkamppeter> pitti, so I have to rename them on the server at first?
<pitti> tkamppeter: that would work (splix-snapshot?), but I'd also like to fix it more generally in jockey
<cjwatson> acpi-support (0.114) intrepid; urgency=low
<cjwatson>   * The rfkill interface has changed again in the 2.6.27 release(!), so
<cjwatson>     play catch-up once more.
<cjwatson>  -- Steve Langasek <steve.langasek@ubuntu.com>  Wed, 15 Oct 2008 03:08:58 +0000
<cjwatson> mdz: ^- do you have that installed?
<tkamppeter> pitti, it would be great if you could fix that, because released versions and development snapshots of the same driver usually have the same package name but only a different version number.
<cjwatson> just happened to notice it in an upgrade
<pitti> tkamppeter: right, that's my plan (disambiguate by version number)
<tkamppeter> pitti, for the test case of two drivers I have requested an HP now, as they are supported by HP's PPDs and by Gutenprint.
<pitti> that should work, yes
<tkamppeter> pitti, some small details:
<tkamppeter> 1. If one of the multiple drivers is recommended, the selection should be on that driver, either by positioning it or by putting the recommended driver to the top.
<tkamppeter> 2. Can you simply change the font of the license window to Courier and make it so wide that 89 characters per line fit into it?
<tkamppeter> If you cannot change the font, Make it simply much wider, so that the probability of too long lines gets negligible.
<tkamppeter> s/89/80/
<tkamppeter> 3. If I switch forth and back between the two drivers the line with the driver description at the top of the lower big box (gray part, over "Not tested by Ubuntu developers") does not change. It simply stays one of the two.
<pitti> tkamppeter: what dbus-send command did you use? I'll try to reproduce 3
<tkamppeter> dbus-send --print-reply --dest=com.ubuntu.DeviceDriver /GUI com.ubuntu.DeviceDriver.search_driver string:"printer_deviceid:MFG:Hewlett-Packard;MDL:HP LaserJet 3020;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL"
<tkamppeter> pitti, it is the command which you gave me earlier.
<pitti> ah, that one
<slangasek> kirkland: mmm, no; you get to pam_ecryptfs because the way pam_chauthtok() works is to make two passes through the password stack, once with PAM_PRELIM_CHECK set and once with PAM_UPDATE_AUTHTOK set
<kirkland> slangasek: k
<kirkland> slangasek: i'm looking at pam's modules/pam_cracklib/pam_cracklib.c
<slangasek> kirkland: and one of the things Linux-PAM does, that's not in the original spec, is to "freeze" the module stack for the second run so that it always matches what was done in the first run; that means any module that was seen on the first pass will also be seen on the second pass, regardless of return codes
<cjwatson> lool: re xorg 1:7.4~5: FWIW debconf doesn't care if you output random junk to stderr
<kirkland> slangasek: nice, handles racey config changes
<slangasek> kirkland: however, I think it's because pam_ecryptfs doesn't give different return codes for the two passes that the stack winds up returning success as a whole
<cjwatson> lool: IME you should usually use rmdir --ignore-fail-on-non-empty rather than 2>/dev/null
<kirkland> slangasek: but i'm having this problem without pam_ecryptfs in the stack
<kirkland> slangasek: you indicated that you were not able to reproduce it in that case?
<slangasek> ah, it's not for racey config changes; it's more difficult to explain, and I suspect that there are actually some subtle bugs there which I've never pinned down, but it's what we have to work with
<pitti> tkamppeter: ah, I get it, too; weird, I never saw this before, looking
<slangasek> slytheri1: libxstream-java appears to already be half in universe for some reason; I'll clean that up
<kirkland> slangasek: see modules/pam_cracklib/pam_cracklib.c, the block that handles MISTYPED_PASS
<kirkland> slangasek: i see retval = PAM_AUTHTOK_RECOVERY_ERR, and then continue (rather than return)
<Mirv> mvo: with nonlanguagepacktranslationfreeze, would there be time to a) sync from Debian to Ubuntu DDTP, this time from Debian main servers (or actually not ftp.debian.org but eg. ftp.de.debian.org), b) sync from there to Ubuntu repositories?
<pitti> tkamppeter: might be because of the <br> in the text or so; I guess I shuold just filter that out
<kirkland> slangasek: it looks to me like the continue is to allow the user to try again
<kirkland> slangasek: but that's not what's executing for me
<Mirv> mvo: (ddtp.debian.net does not host the translations any more since they are nowadays properly mirrored)
<kirkland> slangasek: i changed it to return PAM_AUTHTOK_RECOVERY_ERR
<kirkland> slangasek: but that didn't quite fix it alone; so I'm recompiling shadow against the updated pam library
<slangasek> kirkland: right, if I don't have pam_ecrytpfs in the stack, I'm not getting this bug.  You're reproducing it with cracklib, now?  I was leaving cracklib out, fo the sake of simplicity
<slangasek> what does the full stack look like on the system where you're reproducing this without ecryptfs?
<kirkland> slangasek: hrm, i was grepping for "password updated successfully", and that sent me to cracklib
<kirkland> slangasek: though i do see another hit in unix
<kirkland> slangasek: http://people.ubuntu.com/~kirkland/pam.d
<tkamppeter> pitti, if there is no easy way of GTK rendering the tags correctly, filter them out, as they also look ugly when they do not get rendered.
<pitti> tkamppeter: that's what I did now, and it fixes 3); committed to trunk
<slangasek> kirkland: how are you reproducing it with this stack?  pam_unix is the only module listed
<kirkland> slangasek: sorry, i was grepping for "Sorry, passwords do not match"
<kirkland> slangasek: passwd.  correct password.  enter first password.  enter different password
<kirkland> slangasek: passwords do not match (which I thought was cracklib, but perhaps it's unix), then passwd says "updated successfully"
<slangasek> ok
<kirkland> slangasek: okay, so i should be looking around MISTYPED_PASS in modules/pam_unix/support.c
<slangasek> hmm, I think this would be one of the subtle bugs with the PAM chain freezing I mentioned :P
<kirkland> slangasek: :-)
<slangasek> pam_unix isn't doing anything wrong; it's the stack itself that does it
<tkamppeter> pitti, great, and 1 and 2 should also be easy and as they do not change text content or UI logic it is also no problem after the freeze.
<tkamppeter> And for 3 make sure that you filter the tags not only for the big box but also for the small box where one chooses the driver.
<slangasek> kirkland: I think this part of the bug is intractable for intrepid; but I think we can still fix the ecryptfs case, which adds its own wrinkle
<kirkland> slangasek: okay, i'm all ears;  though i'm surprised to hear you call the pam part "intractable" :-)
<slytheri1> slangasek: thanks.
<slangasek> kirkland: well, here are the constraints that we have to work with: we want a completely stackable system where no package's profile accidentally short-circuits the stack on either success or failure; that means that we avoid setting the stack's return value from any of the password-changing modules; so something has to set the return value, and that's pam_permit at the end
<pitti> tkamppeter: yes, already done
<pitti> tkamppeter: looking at 2 and 1 now
<slangasek> kirkland: and pam_permit will /always/ return success, so when it returns it on the first pass, the PAM stack says "ok, this module matters and we should pay attention to it on the second pass", so it always sets the return value to success
<slangasek> kirkland: correcting that means deep changes to how PAM handles the chain freezing for pam_chauthtok()'s two passes
<kirkland> slangasek: okay; so from the pam_ecryptfs perspective, was that under no circumstances, prevent the rest of the PAM stack from operating as expected
<slangasek> and I think I can give you that :)
<kirkland> slangasek: and i think the PAM_SUCCESS we return was in the interest of that :-)
<slangasek> it'll take me a couple of hours, though
<kirkland> slangasek: the oneliner you posted isn't enough, then
<slangasek> correct
<slangasek> but I have a sense of what it needs to be instead
<kirkland> slangasek: okay.  i expected you to levy that one on me ;-)
<kirkland> slangasek: i'll gladly step aside and go try to fix https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259293
<ubottu> Launchpad bug 259293 in ecryptfs-utils "Ecryptfs Private Directory Randomly Unmounts" [High,In progress]
<kirkland> slangasek: that's the one that cron is causing
<kirkland> slangasek:  is there any way for pam_ecryptfs to "not" execute as when it's cron that's opening/closing the session?
<slangasek> kirkland: mumble need split configs for interactive vs. non-interactive sessions mutter
<kirkland> slangasek: and determine interactive/non-interactive based on .... ?
<slangasek> kirkland: I think you really want the counter, honestly; what if a user ssh's in to their system to try to troubleshoot something?
<slangasek> kirkland: X and ssh and login are interactive, cron and http are not? :)
<kirkland> slangasek: :-)
<kirkland> slangasek: for the counter, jdstrand suggested something in /tmp/USERNAME-ecryptfs/
<slangasek> kirkland: interactive vs. noninteractive session handling is a longstanding request, I've acknowledged that the current setup is deficient here; it's just not bubbled up the priority list yet
<slangasek> why in /tmp, instead of in the user's homedir?
<jdstrand> actually, I suggested /tmp/ecryptfs-USERNAME/ :P
<kirkland> slangasek: okay
<kirkland> jdstrand: :-)  thanks for keeping me honest
<slangasek> hmm, I guess if the homedir is NFS-mounted, the counter would easily be wrong
<kirkland> slangasek: i think it was mostly about guranteeing a reset on reboot
<slangasek> ok
<kirkland> slangasek: we started out thinking /var/run
<kirkland> slangasek: but that requires priv's
<kirkland> slangasek: and while mount.ecryptfs_private is setuid, bumping the counter shouldn't really need to be priv'd
<slangasek> yep
<zul> slangasek: if possible can you kick ec2-ami-tools out of NEW and into multiverse please
<slangasek> zul: not at the moment; maybe there's another archive admin you could grab?
<zul> slangasek: sure
<crimsun> TheMuso: regarding the pa_*unref() crash - I have not experienced it yet with the Xsession.d workaround
<zul> Riddell: ping
 * mpt is momentarily confused by http://www.intrepidmuseum.org/About-Us/Press-Room/Press-Releases/Intrepid-Returns-RELEASE-and-CALENDAR.aspx
<pwnguin> the most inspiring adventure in america!
<mpt> I should have included "ubuntu" in my search terms
<mpt> but the New York LoCo should totally have their release party on an aircraft carrier
<pwnguin> heh
<pwnguin> air drop ubuntu software aid on the people
<cjwatson> kees,lool: what's the state of the remaining gspca milestoned bugs?
<cjwatson> s/milestoned/targeted/
<pitti> tkamppeter: splix vs. splix2 conflict fixed in bzr now, too
<bryce> mvo: there is a patch now for compiz on bug #269904.  Have you had a chance to look at it?
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed] https://launchpad.net/bugs/269904
<bryce> mvo: I don't see anything wrong with the patch, but it alters a realloc call and switches from use of single variables to arrays, which makes it hard to say just by eyeballing that the patch is safe
<torkel> siretart: why shouldn't you be able to use a well know root CA? It should only be used to establish/verify the certificate chain, not authorize you. Right? (Re 284409)
<pitti> tkamppeter: and finally, (1) (show recommended drivers first) fixed in bzr as well; I think I addressed all your points now, and will do another intrepid upload
<mdz> cjwatson: I don't know if I did when I last tested, will retest
<psusi> is there an archive admin around who can help me figure out why the defrag package appears to have been dropped from the archive in hardy and later?  lp says it was superseded, but there is no newer version and it is no longer in the archive
<cjwatson> psusi: it was removed using the old removal tool which didn't leave a very clear record in LP
<psusi> cjwatson: why was it removed?
<Keybuk> mdz: typically I now can't seem to replicate the iwl3945 problem
<cjwatson> psusi: the log of its operation is here: http://people.ubuntu.com/~ubuntu-archive/removals.txt
<cjwatson> ------------------- Reason -------------------
<cjwatson> (From Debian) RoM; orphaned upstream and out of sync with common ext2/3 features
<cjwatson> date was Fri, 30 Nov 2007 12:13:52 +0000
<psusi> it seemed to be in good working order the last time I updated it...
<cjwatson> so presumably as part of the initial sync passs
<cjwatson> pass
<cjwatson> psusi: might depend on what features you have on your filesystems ...
<cjwatson> at a guess, perhaps it doesn't handle resize_inode?
<cjwatson> libparted has that failing too
<psusi> I think I fixed that...
<cjwatson> feel free to reintroduce it (in jaunty) if you think it should be, but it might be a good idea to track down the people who asked for it to be removed from Debian and debate it with them,
<cjwatson> s/,$//
<psusi> oh wow... it WAS removed from debian.... hrm...
<psusi> well, I know it had issues with the ext3 jornal, and something else... might have been the resize inode... I forget now... I fixed it up 2 years ago and I think I filed the patch with a bug report in debian but I don't think anyone there ever applied it so their version was still broken
<liw> hmm. is it possible for a graphics card to break in such a way that it seems to work quite well, but occasionally freezes and colors go quite strange (as if it didn't produce green anymore)?
<psusi> liw: if one of the colors goes out and you have a CRT, it is usually just a loose connection to the monitor
<psusi> but yea, it's possible
<liw> it's a tft, and the connectors are tightly screwed, I check that twice
<cjwatson> psusi: Debian bugs #396449 and #401622 seem particularly relevant
<liw> (tft with vga, though)
<ubottu> Debian bug 396449 in defrag "Re: e2defrag - Unable to allocate buffer for inode priorities" [Grave,Closed] http://bugs.debian.org/396449
<ubottu> Debian bug 401622 in defrag "Not ready to release, too much bitrot, breaks new ext2/3 features" [Grave,Closed] http://bugs.debian.org/401622
<cjwatson> psusi: the first of those is an explicit request from the e2fsprogs maintainer to remove defrag
<cjwatson> psusi: so I suggest you argue with him :)
<cjwatson> psusi: your changelog in https://launchpad.net/ubuntu/+source/defrag doesn't mention resize_inode at all, which is a critical thing to support nowadays
<cjwatson> so I stand by the removal
<cjwatson> (though I don't think I was the admin who did it)
<psusi> cjwatson: hehe, I guess I will... first I guess I need to rebuild it and do some more testing to make sure it still works... if it does, then I just need to point out to them that I did fix those issues and they just never applied them to debian
<psusi> it is likely that it was just the generic issue of defrag not working properly with ANY reserved inodes, which I fixed
<psusi> which was also why it clobbered the journal inode
<psusi> but I'll make sure to make a test filesystem with resize support, then actually resize it, stress the hell out of it, and make sure defrag doesn't break it... then proceed from there
<lool> cjwatson: I'm not working on gspca/libv4l; just helped getting the libv4l ready and in the archives
<lool> cjwatson: If the bugs need help though, I have such a webcam and can help
<cjwatson> psusi: I don't see the patch from you in the Debian BTS, but feel free to demonstrate that I'm wrong ...
<bryce> cjwatson: heya
<liw> hey, bryce, second upgrade test still running, fyi
<liw> (5+ hours remaining)
<bryce> cjwatson: we've got one fglrx issue to consider still
<bryce> liw: excellent :-)
<bryce> cjwatson: currently due to its libsigc++-5 dependency (iirc), it's stuck in multiverse
<liw> bryce, of course, I'm now suspicous of my card since my colors are all wrong :)
 * lool waves
<bryce> er, libstdc++5
<bryce> cjwatson: bug #271794
<ubottu> Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794
<pitti> oh argh, there is again a new tzdata
<psusi> cjwatson: it tells me there are NO bugs of any kind filed against it
<liw> pitti, which country this time?
<cjwatson> psusi: there's a thing at the bottom to get archived bugs
<pitti> liw: haven't checked yet
<cjwatson> psusi: RTFM
<psusi> ahh ;)
<cjwatson> the drop-down that says "Unarchived"
<cjwatson> bryce: oh god, um
<cjwatson> pitti,doko: ^- fglrx/gcc-3.3 help?
<crimsun> cjwatson: I think he's referring to his most recent debdiff at https://bugs.edge.launchpad.net/ubuntu/+source/defrag/+bug/6546
<ubottu> Launchpad bug 6546 in defrag "Failed to build on amd64" [Medium,Fix released]
<pitti> cjwatson: oh, the "needs gcc-3.3" thing?
<cjwatson> crimsun: yes, that doesn't exactly count as something that Debian can be blamed for missing if it was never sent to them
<pitti> cjwatson, superm1, bryce: what's actually the pressing reason to have it in restricted and not in multiverse?
<cjwatson> crimsun: he said "I think I filed the patch with a bug report in debian but I don't think anyone there ever applied it so their version was still broken" above
<bryce> pitti, the specific issue is that this prevents it from being on the DVD
<doko> ohh crap, is this a binary only, or is this a dependency of the driver package as well?
<pitti> bryce: ah, good point
<superm1> pitti, <putting on dell hat> It significantly simplifies factory installation
<superm1> being able to have it on the DVD
 * pitti doesn't understand how AMD can still use such an ancient libc++ for their current builds *sigh*
<superm1> pitti, from what i understand, it's a single library in there that is used for it, not the whole thing
<pitti> it would essentially force us to support gcc-3.3 ad infinitum
<pitti> superm1: is it actually the X driver, or just some shiny GUI configuration thingy?
<bryce> pitti: yeah we raised the issue a while back, but this was a minor issue compared with the Xorg 1.5 issue so didn't get priority
<superm1> so I was saying perhaps if that single library can be split out to it's own package in multiverse
<psusi> cjwatson: well... I can't find it either... odd... I could have sworn I put it in there and bumped it one or twice in the subsequent 6 months... oh well
<superm1> pitti, its the library that provides XvMC acceleration I believe
<pitti> superm1: right, if it's some setup tool, it could be split out, or libstc++5 could become a suggests or so
<bryce> superm1: I wouldn't have a problem seeing that slipt out
<pitti> bryce: what is XvMC? Xv is kind of important for watching videos..
<cjwatson> bryce: do we have to build-dep on it in order to build it, or do they ship a binary application?
<superm1> pitti, so would the archive allow for that put source package and most binary packages in restricted,  a workaround in debian/rules for dpkg-shlibdeps complaining, and then another binary package in multiverse?
<bryce> pitti: X-video Motion Compensation
<cjwatson> superm1: yes, that's possible as long as it doesn't need to build-dep on libstdc++5
<superm1> it does currently have a  build-dep only because dpkg-shlibdeps looks for it
<pitti> superm1: yes, if it's just a binary dependency and not a build dep
<cjwatson> (transitively or otherwise)
<superm1> surely something can be added to not bail out when it complains about it not being around
<bryce> I don't know a lot about it but I gather it's a performance enhancing thing, rather than a hard prerequisite for video playback
<cjwatson> --ignore-missing-info I believe
 * pitti still remembers the time when he symlinked libc.so.6 to libc.so.5 just to get some old binary crap running
<amitk> Keybuk: if you are still available can you join #ubuntu-kernel
<superm1> bryce, i'll scrap the library out and see if I can still do video playback with some basic files
<superm1> bryce, i'm pretty sure it's only necessary when you are doing accelerated playback
<bryce> superm1: great
<pitti> so if we can split out just that one lib into an extra package, or just drop it, that WFM
<tedg> jdong: bug 278810 has a fix attached to it.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/278810/+text)
<mvo> bryce: I have the patch on my radar, but I haven't tested/reviewed it yet
<bryce> mvo, great thanks
<badp> Hello. I found a broken package in the Ubuntu repos. Who do I bother?
<badp> The problem's with libffi4.
<tkamppeter> pitti, great, thank you very much.
<wgrant> badp: What's wrong with it?
<wgrant> Apart from not existing in Intrepid.
<badp> Hmm, I was pretty sure it existed before I reloaded again the repos and before I added the source packages.
<badp> In that case the ball passes to the miro devs including that package as a dependency since 1.2.7 I guess.
<badp> Well, thank you anyway.
<wgrant> https://edge.launchpad.net/ubuntu/intrepid/amd64/libffi4 suggests that it was removed 1.5 months ago.
<wgrant> Same on i386.
<badp> I guess I'll grab the .deb file from launchpad then
<badp> erm, except it's not for my architecture.
<badp> Well, anyway, thank you for the pointer.
<wgrant> badp: We have a libffi5 from a separate source package.
<badp> Yep, but it doesn't satisfy the miro requirement =/
<badp> I know it isn't your fault
<badp> external packages and all.
<cjwatson> argh, cdimage got stuck on a lock AGAIN
<cjwatson> screw this, I'm going to write a wrapper that kills that process if it takes too long
<kirkland> jdstrand: hey, ecryptfs counter design question for you
<jdstrand> ok
<kirkland> jdstrand: i'm leaning toward making the counter only increment/decrement when called from PAM
<kirkland> jdstrand: ie, not when called from the command line
<kirkland> jdstrand: or, rather......
<kirkland> jdstrand: that wasn't put very clearly
<kirkland> jdstrand: okay, start over :-)
<kirkland> jdstrand: i have the increment/decrement code mostly working, incrementing when mounting, decrementing when umounting
 * jdstrand nods
<kirkland> jdstrand: now i'm thinking about the logic for "when to refuse to unmount based on counter value"
<kirkland> jdstrand: i will want a "force" method, whereby it's unmounted and the counter zero'd out
<kirkland> jdstrand: so i'm thinking ....
<kirkland> jdstrand: should that "force" be the default (which is basically the current methodology), or the exeception (with some new --force option)
<doko> ubuntu-archive: pleae could somebody accept sun-java6 (multiverse)
<kirkland> jdstrand: if the former, I add some new option (--counter), and tack that onto the PAM call
<jdstrand> kirkland: I think it needs to be a simple and straightforward as possible for now. also, I'm not sure I understand the need for pam to know about the counter stuff
<kirkland> jdstrand: pam = automated call
<kirkland> jdstrand: manually calling mount.ecryptfs_private, versus happening automatically
<jdstrand> kirkland: what is the advantage of it in pam? (esp considering that other upstream people will likely have objections)
<kirkland> jdstrand: ?  having what
<jdstrand> kirkland: maybe I am still confused by your previous comments...
<kirkland> jdstrand: can we chat on the phone briefly?
<pitti> slangasek: ok for me to sync http://packages.qa.debian.org/t/tzdata/news/20081015T091712Z.html ?
<slangasek> pitti: yes
<slangasek> kirkland: ok, got a patch now
<slangasek> kirkland: posted to the bug; see if that takes care of the symptoms you see
<kirkland> slangasek: k, nearly done with the ecryptfs counter patch
<pitti> liw: tzdata country> syria; it's pretty much the only change between 2008g and h
<calc> when is jaunty going to open?
<sebner> calc: usually some weeks (1-2) after release ;)
<calc> cjwatson: could we get a jaunty-alpha-1 milestone target?
<calc> would be useful for my 3.0 targeted bugs
<slangasek> no, it's not possible
<slangasek> use the 'later' target
<calc> slangasek: oh that can't happen until its opened?
<slangasek> yes, because milestones are attached to series
<calc> ok i'll just use that
<calc> ah i see
<cjwatson> calc: what he said, also we can't open jaunty until intrepid's done because it screws with LP's internal idea of package ancestry
<calc> cjwatson: oh ok
<cjwatson> calc: the series is usually opened in LP within a day of the release though
<calc> ok
<cjwatson> sebner is a little pessimistic :)
<cjwatson> it may take a week or so before you can actually *upload* to it ...
<calc> i'll just stick this all as later then reassign it after release
<cjwatson> yeah, that's pretty much what later's for
<calc> ok
<cjwatson> silly hack, but ...
<calc> hehe
<calc> oh yea the jaunty page has a link to the release schedule but its not there yet, is that something that doesn't get put up until after UDS?
<slangasek> that'll get put up this week
<slangasek> (I'm hoping)
<calc> ok
<calc> looks like the cycle will start dec 18(?)
<slangasek> the cycle "starts" Oct 31, surely? :)
<cjwatson> oh, don't pay any attention to where the IntrepidReleaseSchedule calendar ends
<calc> oh ok
<calc> i was getting really confused as to when that would put jaunty releasing
<calc> 27-28 weeks out from there would have been june
<calc> looks like we are targeting ~ april 30 then for the release
<slangasek> April 23
<calc> ok
<mdke> pitti: when you uploaded ubuntu-docs, did you apply the debdiff or do a fresh checkout from the bzr branch?
<pitti> mdke: the attached debdiff
<mdke> pitti: rats. Say I wanted to do an upload from the bzr branch, would the best idea be to do a fresh SRU and new changelog entry?
<mdke> pitti: there are a couple of revisions which aren't included in the debdiff which would be good to get
<pitti> mdke: yes, that's necessary, since it needs a new version number
<mdke> pitti: ah, ok. Sorry about that inconvenience. Ok, I'll get the other revisions in at a later stage when doing another translation update or something
<mdke> pitti: anyway, I've tested the package and it works fine
 * lamont wonders  why the current hardy network mangler(?) keeps disconnecting him from a perfectly good access point
<lamont> OTOH, I "fixed" it with a little judicial kill -9 love, applied to nm-applet
<ScottK> lamont: When did you update the box last?
<lamont> last night
<ScottK> I was having trouble like that yesterday, but not last night or today.
<lamont> the current update list is just cups
<Riddell> zul: you pinged?
<TheMuso> cjwatson: well I only have a work-around since the crash is part of the whole race condition stuff I've been talkign with slangasek and crimsun about.
<cjwatson> lool: what's the status of xvfb on hppa/powerpc/sparc/
<cjwatson> ?
<bryce> pitti, slangasect: I've reviewed and cleaned up the patch for targeted lp #274045 to apply to our version of -intel.  Should I upload the package?
<lamont> OTOH, I am running a -19 kernel, now that I htink about it
<cjwatson> TheMuso: ah, ok
<ubottu> Launchpad bug 274045 in xserver-xorg-video-intel "[intrepid alpha6] X.org cannot find PLL settings for mode" [Undecided,Confirmed] https://launchpad.net/bugs/274045
<TheMuso> I'll ask the users in the bug to try it, pointing out that it is only a work-around.
<cjwatson> lool: if that isn't easily fixed we should disable pygtk's test suites on those architectures so that we can build everything else
<lamont> ScottK: I'll reboot here and see if that helps any
<TheMuso> slangasek: Upon further thought and digging, to get pulseaudio to try and reconnect to a device requires unloading, and reloading the hal module, which has to then detect everything over again. While this is probably possible, I still need to work out where that has to be done.
<slangasek> TheMuso: that sounds... like a bad design.
<cjwatson> StevenK: could you please stop NBSing kernel udebs before the new ones are in the archive? :)
<TheMuso> slangasek: Yeah, well thats what I've come up with anyway from investigating.
<slangasek> bryce: 274045> yes, please
<bryce> slangasek: thanks, uploaded.
<cjwatson> StevenK: (assuming it was you ...)
<slangasek> cjwatson: if that was lpia, that might've been me
<cjwatson> lpia, yeah
<cjwatson> StevenK: ah, sorry, I just know your deep abiding love for NBS ;-)
<slangasek> yeah, sorry, I didn't notice that linux-lpia was completely FTBFS when I did it
<TheMuso> slangasek: I'm going to get wider testing of my workaround, but I fear its our best option at this point. I can then talk with upstream as to how we could possibly solve this better for a future release of pulseaudio.
<cjwatson> I'm pushing the new one through now
<slangasek> TheMuso: oh, I agree, we need to stick with the workaround
<slangasek> I think I expressed that a couple days ago :)
<TheMuso> slangasek: Yes, but then we weren't sure as to how it could have been done in pulse to reload the alsa module.
<mathiaz> Riddell: 14:20 < zul> slangasek: if possible can you kick ec2-ami-tools out of NEW and into multiverse please
<mathiaz> Riddell: zul was looking for an archive admin to do that ^^
<slangasek> TheMuso: I asked you if you could have it done before the freeze; you said no, so I said no
<slangasek> doko: hrm, this sun-java6 upload shows a changelog branched from before the last intrepid upload
<TheMuso> yeah but I wanted to be sure that it wasn't as easy as thought, which it doesn't appear to be.
<TheMuso> anyway, will get more testing from affected users.
<Riddell> mathiaz, zul: that ec2-ami-tools looks fine for universe, why multiverse?
<mathiaz> Riddell: I don't know. I heard there was some licensing issues.
<doko> slangasek: looking ...
<cjwatson> Riddell: is that the one with the licence that says "The Work and any derivative works thereof only may be used or intended for use with the web services, computing platforms or applications provided by Amazon.com, Inc. or its affiliates, including Amazon Web Services LLC."?
<cjwatson> Riddell: that's non-free if so
<Riddell> cjwatson: so it is, that's a perfectly nice licence apart from that paragraph
<cjwatson> Riddell: yeah, otherwise it's basically just BSD
<cjwatson> Riddell: although I'm not entirely sure about the patent termination clause - it's quite broad
<cjwatson> but given the use restriction I didn't bother to investigate that
<doko> slangasek: all changes are merged, just the changelog entries are missing. I'll add these for the next upload
<Riddell> mm right.  multiverse it is
<slangasek> doko: ok
<slangasek> doko: hmm, there seems to be a large delta under debian/ though, which seems like it might be the result of not having the latest Debian merge in?
<slangasek> ah, no, because 6-07-4 is a parent of both
<doko> diff -Nru sun-java6-6-07/jdk-6u10-dlj-linux-amd64.bin sun-java6-6-10/jdk-6u10-dlj-linux-amd64.bin
<doko> --- sun-java6-6-07/jdk-6u10-dlj-linux-amd64.bin 1970-01-01 01:00:00.000000000 +0100
<doko> +++ sun-java6-6-10/jdk-6u10-dlj-linux-amd64.bin 2008-10-16 19:19:56.000000000 +0200
<doko> do you mean this?
<doko> that's the upstream blob
<slangasek> no
<doko> all ok from my point of view. the last upload to ubuntu had a few *.log files left
<slangasek> the debian/ delta turned out to be mostly debhelper log files
<cjwatson> slangasek: cdimage shouldn't get stuck if britney happens to hang on a futex now
<cjwatson> workarounds 'r' us
<slangasek> ok
<cjwatson> superm1: rebuilding mythbuntu for you now since that was a casualty of the above
<cjwatson> (probably others too, that's just how I spotted it)
<slangasek> ScottK: this new kdvi upload ships a /usr/lib/libdjvu.so that doesn't seem to have been in the hardy version of the package
<slangasek> ScottK: (and a lot of other files)
<ogra> slangasek, there is an lpia-linux-restricted-modules awaiting your gentle approval
<slangasek> ogra: I'm aware, thanks
<ogra> oh, sorry, didnt want to be pushy ... ;) (meta following as well then)
<ogra> just wanted to do my duty before leaving for the evening
<slangasek> things you don't want to see in a "security fix":
<slangasek> -       if (length_of_file(MINDI_CACHE"/changed.files") > 2) {
<slangasek> +
<slangasek> +       if (length_of_file("/tmp/changed.files") > 2) {
<lifeless> slangasek: well, that looks like its no worse :P
<lifeless> slangasek: though the leading whitespace might be a problem :>
<slangasek> lifeless: except that now it's been published as part of a CVE so everybody knows it's there :(
<lifeless> slangasek: yay
<lifeless> slangasek: /sarcasm
<TheMuso> 8/c
<slangasek> lifeless: bug #216601, if you'd like more entertainment
<ubottu> Launchpad bug 216601 in mondo "[CVE-2008-1633] unspecified vulnerability relating to use of /tmp" [Medium,Confirmed] https://launchpad.net/bugs/216601
<lifeless> slangasek: OMFG
<lifeless> slangasek: all software sucks; some programmers suck more
<elmo> wow, that is special
<elmo> and not in a good way
<StevenK> cjwatson: Yup, it wasn't me this time. :-)
<slangasek> kees: who's working on getting the remainder of the v4l transition done?
#ubuntu-devel 2008-10-17
<StevenK> slangasek: Is it a bunch of rebuilds?
<slangasek> I don't think so
<slangasek> bug #260918
<ubottu> Launchpad bug 260918 in xawtv "needed: libv4l and associated application patches (or "gspca stopped working in 2.6.27")" [High,Fix released] https://launchpad.net/bugs/260918
 * StevenK waits for LP
 * ogra sighs
<ogra> lpia-lrm ftbfs'ed
 * ogra decides to leave that to amit
<cjwatson> ogra: it did? where?
<cjwatson> I only see the one for the old ABI
<ogra> The following packages have unmet dependencies:
<ogra>   linux-headers-2.6.27-4-lpia: Depends: linux-headers-2.6.27-4 but it is not installable
<ogra>   linux-headers-2.6.27-4-lpiacompat: Depends: linux-headers-2.6.27-4 but it is not installable
<ogra> E: Broken packages
<ogra> lpia-linux-restricted-modules_2.6.27-4.4
<cjwatson> oopsie
<cjwatson> well that isn't going to work :)
<ogra> apparently
<slangasek> hee
<cjwatson> the perils of excessive kernel source package splitting
<slangasek> so much for "getting rid of the ABI checks"
<ogra> but i spent a night on the broken linux-lpia this week already with getting nowhere
<cjwatson> you don't get to use common stuff any more, at least not easily ...
<ogra> so i'll leave it to amit to fix it
<cjwatson> all this split source package stuff is a confusing mess
<cjwatson> slangasek: speaking of lpia, could you accept d-i?
<ogra> slangasek, dont say abi checks ... that costed me a night to just find out even my ignore files get ignored
<slangasek> cjwatson: already did, unless you've uploaded another in the past 30m
<StevenK> ogra: So, slangasek said you're the person to talk to about libflashsupport?
<slangasek> I did?
<StevenK> Blah. Someone did.
<ogra> it should die die DIE !
 * ogra looks for a shotgun
 * ogra realizes he isnt american and thus doesnt own something like that 
<crimsun> (err?  who/what needs libflashsupport still?)
<StevenK> I'll take that as I shouldn't fix it to use libgnutls26 and should purge it from the archive.
<slangasek> crimsun: we don't know; if it's supposed to go away, this hasn't been communicated effectively to ubuntu-archive
<ogra> crimsun, its just idling in the archive
<StevenK> Someone file a removal bug and I'll get killed.
<ogra> slangasek, i pinged here several times but always during busy times
<StevenK> Errrr. s/I'll/it'll/
<ogra> so that likely got lost ...
<StevenK> ogra: Right, so file a bug.
<slangasek> ogra: well, pinging here is not the right way to go about requesting package removals anyway, there's no review or accountability
<StevenK> Bugs assigned to -archive tend not to get lost.
<StevenK> Er, subscribed
 * StevenK gives up on this whole IRC thing and goes to inject a bunch of caffeine
<ogra> StevenK, really, i just came here to quickly upload the kernel for amit after a 14h day, now i'm stuck in conversations for 2h already again
<crimsun> bug 267749
<ubottu> Launchpad bug 267749 in libflashsupport "investigate removal of libflashsupport from archive and ia32-libs" [High,Triaged] https://launchpad.net/bugs/267749
<crimsun> just to note, libflashsupport is gone from ia32-libs thanks to \sh
<ogra> if you want to remove it, just wipe it ... else i'll file a bug tomorrow
<ogra> s/kernel/lrm/
<cjwatson> slangasek: oh, I lose
<cjwatson> ok
<kwwii> libflashsupport should be killed
<cjwatson> that's what I get for failing to catch up on -release
<StevenK> kwwii, crimsun, ogra: Then one of you file a bug asking for removal. :-)
<crimsun> StevenK: I've just pointed to the one I'm going to modify
<StevenK> crimsun: Fair enough
<slangasek> cjwatson: no worries :)
<crimsun> ogra: your LTSP use cases are fine with libasound2-plugins in intrepid, correct?
<crimsun> (I've asked before, but it doesn't hurt to ask again)
<ogra> crimsun, i hope so
<ogra> i didnt have the time to test ltsp on real HW this cycle
<kwwii> is there any info on how to create a sponsoring bug?
<ogra> well, tats not true, but all testing until mid cycle i did had to be for hardy
<StevenK> kwwii: Attach debdiff with rationale, and subscribe ubuntu-{main,universe}-sponsors
<ogra> for intrepid i didnt have the opportunity
<kwwii> I have a new human-icon-theme package which fixes a bug in the fusa applet stuff and have anew package
<kwwii> erm, debdiff...something new to me
<ogra> crimsun, let it go, worst case i'll revive it in a PPA
<kwwii> StevenK: how does one make a debdiff?
<kwwii> or pointers to info?
<crimsun> ogra: I'll try to create a vm and test it tonight then modify the bug into a removal request
<kwwii> sorry for asking stupid questions but /me is an artist :p
<crimsun> kwwii: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<ogra> kwwii, debdiff human-theme_1.2.3.dsc human-theme_1.2.4.dsc >human-theme.debdiff
<StevenK> kwwii: Okay, so you have your two source packages, foo_0.1.dsc and foo_0.2.dsc. If you run 'debdiff foo_0.1.dsc foo_0.2.dsc > foo.debdiff' it will give a diff of everything that changed between the two versions
<james_w> hey kwwii, did you see my bug about the location of the panel background for DarkRoom? I'm not sure whether it actually breaks anything, is the panel background looked up based on the theme name when you switch?
<kwwii> StevenK, ogra, crimsun: considering the fact that I already removed the old dsc files that sounds like more work than just buggin seb128 tomorrow :p
<kwwii> james_w: yes, I saw that..stupid mistake of mine
<kwwii> james_w: not sure if I can fix that before the release though
<ogra> kwwii, apt-get source human-icon-theme (in a different dir) ;)
<kwwii> ogra: but the last version was not released either
<kwwii> I guess I could get it per bzr somehow
 * ogra has a bautifully looking DarkRoom theme here, no breakage seen so far
<kwwii> ogra: the panel bg gets installed in a dir called Darkroom
<slangasek> kwwii: for sponsorship, one typically wants to see the whole diff from the last version in the archive
<kwwii> which, althouh not a direct bug is stupid
<slangasek> but if it's normally released from bzr, there are other ways to achieve this that don't involve sending debdiffs to LP
<ogra> kwwii, hmm, so i am supposed to have a pixmap background, not a plain color ?
<kwwii> slangasek: everything is in bzr
<kwwii> ogra: nope, for the dark theme I just include the bg but cannot set it per default
<kwwii> I need to ask vuntz how to do that within a theme
<kwwii> but I don't even know him
<ogra> hmm, trying that out i must admit it like it better without
<kwwii> funny, he works for us :-)
<slangasek> ?
<kwwii> oh, try the bg
<ogra> i do
<kwwii> and set the gconf setting to stretch first
<ogra> kwwii, i see what you mean, but that doesnt make it brighter :)
<kwwii> ogra: true
<kwwii> I tried to make it very subtle
<kwwii> erm spelling
<ogra> i like it in the system color
<kwwii> hehe, and mark thinks it looks good
<kwwii> funny how that works, eh?
<ogra> heh
<kwwii> sometimes it would be easier if mark wasn't my boss :p
<ogra> it somewhat hides the beauty of the button and menu effects
<ogra> i like how the taskbar buttons look slighty sunk in with that soft shadow ... the drakness of the background just makes that go away
<kwwii> ture
<kwwii> ahh
<ogra> same for the rounded menu top items
<kwwii> true
<kwwii> if I removed the alpha is you would like better
<kwwii> -is
<kwwii> anyway
<kwwii> time for sleep
<kwwii> night
<ogra> heh
<ogra> night
 * ogra goes to bed as well
<slangasek> bryce: haven't we had bug #277831 previously, or am I thinking of a different driver?
<ubottu> Launchpad bug 277831 in xserver-xorg-driver-ati "System freezes on rotating screen" [Unknown,Confirmed] https://launchpad.net/bugs/277831
<bryce> slangasek: yep, rotation on -ati sucks big
<bryce> has for some time.  but it's been getting better
<bryce> hmm, is proper grammar even that?
<slangasek> bryce: right, so no reason I should accept the intrepid nomination under the present circumstances, really
<bryce> slangasek: no reason.  In the upstream bug it says rotation isn't supported on this hardware.
<slangasek> funny, some software will return error messages instead of locking up when something isn't supported ;)
<bryce> slangasek: yeah :-/
<bryce> I've been keeping a close eye on -ati lately, and if a patch turns up that implements that, I'll hopefully notice it and we can consider bringing it in
 * slangasek nods
<bryce> but -ati crashing on rotate is nothing new, I don't think it's going to be seen as a regression
<bryce> (indeed I'm not sure r6xx cards even worked on -ati when hardy was out)
<slangasek> well, the submitter is one who makes voracious use of the regression-* tags when they apply, so I would suppose not :)
<bryce> heh
<bryce> wouter's a good triager.  I'm surprised he didn't have a bugzilla account at fdo already
<mrmike> Hi, looking for a sockets library in the repository? ideas?
<mrmike> Also, i saw libasio-dev, is that boost::asio?
<TheMuso> slangasek: yeah re the totem segfault with pulse, I can not, with mp3s, oggs, flacs etc, reproduce it at all.
 * slangasek nods
<slangasek> tjaalton: did the X logs posted to bug #256142 help you any?
<ubottu> Launchpad bug 256142 in xserver-xorg-video-intel "Flickering with version 2.4.0" [Undecided,Confirmed] https://launchpad.net/bugs/256142
<ScottK> slangasek: All the binary for kviewshell is also shoved into kdvi.  Kdvi needed it as a dependency, but nothing else does so re-introducing two binary packages didn't make sense.
<slangasek> ScottK: ah, so this usr/lib/libdjvu.so existed before, yuck
<ScottK> slangasek: The new kdvi conflicts/replaces kviewshell, so it should work out OK.
 * slangasek nods
<ScottK> slangasek: Taking the entire kdegraphics package for KDE3 and paring it down to build just one package involved some compromises.
<slangasek> sure
<ScottK> slangasek: Would you please accept guidance-power-manager.  This patch has a funny story behind it.  I thought I fixed this bug number yesterday, but I fixed a large fraction of the dupes stacked under it instead, so this is a good patch.
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<kirkland> slangasek: fyi, i'm rolling and testing your ecryptfs patch, as well as the counter
<kirkland> slangasek: still around?
<tjaalton> slangasek: well, they are more helpful for upstream, and those are already there but no solution yet..
<tjaalton> slangasek: also, that particular bug is a strange one, since one patch fixing things for others can (and has) broken it for others
<tjaalton> and the root cause can be in the kernel DRM driver too
<slangasek> kirkland: in and out
<kirkland> slangasek: k, tested your patch
<kirkland> slangasek: it fixes at least one case (non matching passwords)
<kirkland> slangasek: but not cases where it asks you to try again 3 times
<kirkland> slangasek: like leaving a blank password x6
<kirkland> slangasek: or a 'too simple' password x6
<slangasek> hrm, I thought I tested that case
<kirkland> slangasek: anyway, i put a test package in my ppa
<kirkland> slangasek: i rolled your fix for that bug, plus mine with the counter
<kirkland> slangasek: counter is working quite well
<kirkland> slangasek: that patch is here: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259293
<ubottu> Launchpad bug 259293 in ecryptfs-utils "Ecryptfs Private Directory Randomly Unmounts" [High,In progress]
<dholbach> good morning
<NCommander> morning dholbach
<dholbach> hi NCommander
<slangasek> sbeattie: I notice that http://people.ubuntu.com/~sbeattie/regression_tracker.html shows entries with Release: none for bugs that, if you look at their bug pages, are "tracked in Intrepid"
<kirkland> slangasek: i posted an updated patch at https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/272232
<ubottu> Launchpad bug 272232 in ecryptfs-utils "passwd - passwords do not match but updated successfully" [Medium,In progress]
<kirkland> slangasek: it contains the fix for 283477 as well
<kees> slangasek: not sure about the remaining v4l bits -- I handled everything in "main" plus some stuff in universe.
<kirkland> slangasek: i'm grouping those together, as i'd like them sponsored together, after kees reviews the counter code :-)
<sbeattie> slangasek: example bug number? (I'm not surprised, just want a quickly identifiable testcase)
<kees> kirkland: I won't be back "at work" until monday.
<kirkland> kees: :-) sure
<slangasek> sbeattie: 260918
<slangasek> sbeattie: i.e., the first one listed in the regression-potential list :)
<kirkland> kees: i'll get jdstrand to review it tomorrow, then
<kees> kirkland: cool
<slangasek> kirkland: ok; I'm dead for the night, so I'll have a look tomorrow after the release meeting
<kirkland> slangasek: i hear ya
<kirkland> slangasek: thanks for your help with this
<slangasek> sure
<kirkland> kees: fwiw, i added an increment/decrement counter to the mount.ecryptfs_private/umount.ecryptfs_private code
<kirkland> kees: it's before the setuid bits
<kirkland> kees: which makes the private mount "survive" cronjobs, and multiple simultaneous ssh/console logins/logouts
<kees> kirkland: ah, cool
<kirkland> kees: sports an flock() and everything :-)
<kees> hehe
<StevenK> kees: Since you're here, do you want help with the libv4l stuff?
 * StevenK actually reads backscroll
<kees> StevenK: I helped package it and fixed everything in main.  :P
<StevenK> Right. vlc, mplayer, camstream, camorama and amsn]
<StevenK> s/]//
 * StevenK curses his ] key
<kees> StevenK: I'm not interested in writing those patches, no.
<kees> StevenK: camstream is very strange -- it didn't like the patch from the v4l website either.
<StevenK> kees: I think most of them have patches
<StevenK> kees: Send a mail to ubuntu-motu mentioning the bug number and "Fix them, please? :-)" ?
<pitti> Good morning
<StevenK> Morning pitti
 * pitti declares a component-mismatches squashing day
<StevenK> \o/
<StevenK> pitti: If you want my help, throw me bits
<pitti> StevenK: awesome work on NBS!
<StevenK> pitti: The last thing is octave-gpc, which is broken, and I can't fix
<pitti> StevenK: this gtklookat thing is unfixable, too?
<StevenK> pitti: And has already been killed
<pitti> great
<pitti> and linux-lpia?
<StevenK> It's dead upstream, and has been for a while
<StevenK> Not sure, didn't look very closely
<NCommander> Pici, can I do anything to do to help?
<StevenK> Heh
<NCommander> oh
<NCommander> screw me
<NCommander> *pitti
<StevenK> pitti: We don't have -meta yet for lpia
<StevenK> pitti: And LRM FTBFS, since linux-headers-2.6.27-4 doesn't exist, and I probably need to resurrect it :-(
<NCommander> StevenK, isn't it a little late in the cycle to not have it?
<StevenK> NCommander: We don't have a meta for -4
<pitti> StevenK: why doesn't linux-lpia build -headers?
<StevenK> IE, it isn't uploaded yet, smart alec
<StevenK> pitti: Because it doesn't build on i386. It's neatly complicated :-(
<NCommander> StevenK, can I help?
<pitti> StevenK: right, it would probably be Architecture: lpia, not all?
<NCommander> We had the same problem with -ports
<StevenK> pitti: Right
<NCommander> And we managed to get it to work
<StevenK> NCommander: How did you solve it?
<NCommander> I *think* we made it so the kernel packages build on i386
<NCommander> But I'm not sure offhand
 * NCommander looks at the git tree to remember
<StevenK> pitti: I'm not sure if Soyuz will like a linux-headers-2.6.27-4 package since it already saw one
 * StevenK pokes at the -lpia kernel on rookery
<NCommander> We have linux-ports-headers
<NCommander> (provides linux-headers/linux-headers-2.6)
<wgrant> StevenK: Why wouldn't it?
<StevenK> Hmmm
<StevenK> wgrant: Why wouldn't it what?
<wgrant> StevenK: Why wouldn't Soyuz like it?
<pitti> StevenK: oh, we aren't talking about -headers-2.6.27-4-lpia?
<NCommander> StevenK, I'm looking at the package right now
<StevenK> pitti: No, we're talking about -headers-2.6.27-4
<pitti> StevenK: anyway, if you actually need -headers-2.6.27, reintroducing that should be ok as long as it has a newer version than the one built from linux
<StevenK> pitti: Or I can fix the kernel to build linux-lpia-headers-2.6.27-4
<NCommander> StevenK, I think I can fix it for you
 * NCommander is checking out ubuntu-lpia.git now
<StevenK> Which then doesn't rely on this mess
<NCommander> StevenK, I've been dealing with the same mess for ports :-)
<StevenK> Heh
<NCommander> You'll forgive me if I'm a git-tard though
<tjaalton> pitti: hey, I've got a new evdev ready, finally fixes bug 274203
<ubottu> Launchpad bug 274203 in xserver-xorg-input-evdev "Joystick detected as mouse, crashes X" [Undecided,Fix committed] https://launchpad.net/bugs/274203
 * NCommander tries to avoid git at all costs
<StevenK> NCommander: Me too.
<tjaalton> pitti: upstream change; http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=7243116f55609a2a5f73bb88cf6ad6386c9bbc0b
<StevenK> NCommander: I e-mail diffs to Amit
<tjaalton> pitti: ok to upload?
<pitti> tjaalton: yay, I already wondered about that, nice! (I wanted to fix the default permissions of the joystickdevice)
<StevenK> Actually, no, I just throw them onto rookery
<NCommander> StevenK, I think I can pull the build-indep rules from ports which does what you want
<pitti> tjaalton: curious fix :) sure, go ahead
<tjaalton> pitti: thanks, uploading
<StevenK> NCommander: Yeah, except we want to be binary-arch (And ITYM binary-indep)
<NCommander> Wait, you want the all package to be built by lpia and not i386?
 * NCommander can see Soyuz crying not
<tjaalton> pitti: hmm, what permissions?
<pitti> tjaalton: of /dev/input/jsX
<StevenK> NCommander: Make it any, not all
<tjaalton> pitti: ah
<pitti> tjaalton: hal sees it as a mouse device, not a joystick one
<StevenK> NCommander: IE, linux-lpia-headers-2.6.27-ABI should be arch: any, even if it's a hack
<pitti> tjaalton: so I can't apply the magic dynamic ACL trick
<NCommander> StevenK, I'm trying to understand your reasoning :-/
<pitti> doko: python-reportlab> did this get slangasek's blessing? there's no bug associated, and new upstream version doesn't explain what it changes
<StevenK> NCommander: -lpia won't build on i386, and I suspect I don't want it to
<pitti> StevenK: arch: lpia?
<StevenK> pitti: Well, probably
<doko> pitti: not yet, have to write a FF ex report
<StevenK> NCommander: Does my reasoning make sense?
<NCommander> StevenK, make ARCH=i386 headers would work fine on i386
<NCommander> It could be an all target
<StevenK> NCommander: Except that it never gets that far
<StevenK> NCommander: Since i386.mk doesn't exist in -lpia
<NCommander> We added one for -ports
<StevenK> Sure, but ports tries to build everywhere
<NCommander> No
<NCommander> ports is Arch powerpc, hppa, ia64, sparc
<StevenK> Well, if you can make it build on i386, then I'm all for it
 * StevenK kicks his local mirror
<StevenK> So, you synced at 8:00am this morning. Why do you have an newer packages file, and want to download 1.2GB?
<StevenK> apt-mirror, I will get you.
 * NCommander shall do so
<NCommander> :-)
 * NCommander creates an lpia intrepid tarball
<NCommander> StevenK, the changelog file for the kernel is kinda odd ...
<StevenK> Duh
<NCommander> Ok, how do I make a new changelog ;-)
<NCommander> entry
<StevenK> dch -i
<pitti> bryce: do you have the patch for bug 226668 in a PPA? if not, I'll start a build now
<ubottu> Launchpad bug 226668 in xorg-server "Xorg crashes do not work with apport" [Wishlist,In progress] https://launchpad.net/bugs/226668
<NCommander> Er, what about the point numbers?
<StevenK> NCommander: You want 2.6.27-4.8
<NCommander> Ok
<NCommander> Makes sense
<tjaalton> pitti, bryce: there are related patches on the fedora xserver, but I don't know if they fix apport as well
<tjaalton> they also turn modedebugging on by default, hmm
<NCommander> StevenK, I think you also need linux-lpia-doc
<NCommander> so there is no conflict with the regular -doc packages
 * StevenK hand waves
<StevenK> Not so concerned about -doc
<NCommander> Ok
<StevenK> NCommander: Is it done yet? :-P
<NCommander> Figuring out how to make source package, I haven't messed with this before
<StevenK> dpkg-source ?
<NCommander> Make?
 * NCommander finds debuild -S -sa doesn't work
<StevenK> Due to no i386/amd64.mk?
<StevenK> NCommander: Do it by hand. cd .. ; dpkg-source -b <dir>
<NCommander> I got debuild -S -sa to work
 * NCommander had to install kernel-wedge
<NCommander> No, there is an i386.mk now
<StevenK> Ah
<StevenK> You nasty man
<NCommander> And a check in the makefiles to make sure it doesn't build linux-lpia on i386
<NCommander> (so just the binary-indep target is hit)
<NCommander> I'm not completely sure I got it right.
<NCommander> I have that off feeling I need to rename the abi folder for the new point release
<StevenK> Why?
<NCommander> Cause its linux-2.6.27-4.6
<NCommander> And the changelog says its 4.7~ppa1
<StevenK> Where did you pull it from? 4.7 is in the archive
<NCommander> er
<NCommander> sorry
<NCommander> .7 and .8 respectively
<pitti> StevenK: so, as a first step, should hildon-control-panel, midbrowser, etc. really go back to universe?
<StevenK> pitti: I want to say no, because I fought tooth and nail to get them into main, but they can probably be demoted.
<StevenK> pitti: Let me wait for lool to surface
<pitti> StevenK: that's ok, britney just wants them to go
<pitti> it seems that c-m got unfixed again
<pitti> StevenK: problem is now that I can't really see now which of the main->universe depends can actually go
<NCommander> StevenK, test building on i386 with debuild -B -A to simulate an arch all pass
<pitti> StevenK: ok, I'll ignore that for now
<NCommander> StevenK, this is going to take a few minutes to build, brb for some food
<lool> cjwatson: xvfb is still broken; I tried to setup qemu ppc and qemu sparc envs yesterday to debug it, but wasn't successful; I'm looking at using porter machines now
<StevenK> pitti: How can I debug why a key doesn't get automounted on Hardy?
<pitti> StevenK: do you see it in the computer place, unmounted?
<pitti> or not at all?
<StevenK> pitti: I do
<pitti> and can you mount it from there with clicking?
<StevenK> pitti: Double clicking it and right-clicking -> Mount Volume seems to be a no-op
<pitti> StevenK: ok, that would be it then
<StevenK> But how does one debug that?
<pitti> StevenK: gnome-mount -vbd /dev/whatever output?
<StevenK> ** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_48F2_CE36
<StevenK> org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.mount-removable no <-- (action, result)
<StevenK> Thank you for telling me, Nautilus
<StevenK> pitti: /sys/block/sdb/removable is 1, though
<StevenK> NCommander: No news?
<NCommander> StevenK, I can build the headers, but not in a sane way yet
 * NCommander is debugging the makefile ATM
<NCommander> oh THAT's ugly
<StevenK> Now you have to share
<NCommander> THe -ports control file has a i386 kernel to make rules happy
<NCommander> But
<NCommander> It looks like I can fix this with a little hacking to remove that requirement
<NCommander> I can generate the headers file on i386
<NCommander> Its just a matter of rules hacking
<PecisDarbs> is there OpenOffice.org 3 PPA for Hardy?
<cjwatson> NCommander: I think it's inappropriate and worryingly complex for linux-lpia to build on i386, FWIW
<pitti> StevenK: I guess you don't have a CK session?
<NCommander> cjwatson, the -headers package?
<cjwatson> lool: can we just turn off the test suite in pygtk for now?
<cjwatson> NCommander: yes
<NCommander> cjwatson, that's how the other kernels do it, both -ports, and amd64's kernel
<lool> cjwatson: finishing that as we speak
<NCommander> and how it was done when it was just a single kernel package
<cjwatson> NCommander: both of them naturally build on i386
<lool> wanted to do something too clever which is taking me too much time
<cjwatson> -ports builds the 386 kernel
<cjwatson> NCommander: I'll reject a linux-lpia that builds on i386; I really think it's wrong
<NCommander> cjwatson, ports-headers also builds on i386.
<cjwatson> NCommander: yes, that's because linux-ports builds other i386 packages
<NCommander> Fair enough
<NCommander> So then its just a matter of making it Arch: lpia, and then hacking rules to build headers in the right spot
<cjwatson> NCommander: plus, if you build linux-lpia on i386 just so that it can build linux-header-2.6.27-4, then you'll run into trouble when the ABI is the same as the main linux package
<NCommander> I was just building the headers on i386
<NCommander> THe main kernel would be built on lpia
<StevenK> cjwatson: If it's called linux-lpia-headers-2.6.27-4, I can deal
<cjwatson> NCommander: yes, I know, that's what I object to.
<cjwatson> just build the whole thing on lpia.
 * StevenK notes saying that roughly 40 minutes ago
 * NCommander runs away
<NCommander> Ok, ok :-P
<cjwatson> it's only needed for one architecture, there's no reason to mess around with i386 just so that you can have an arch: all package.
<NCommander> Point taken ;-)
<cjwatson> lool: thanks
<StevenK> pitti: I ought to have a CK session
<StevenK> ... except I don't
<NCommander> I'll cook a package then that builds the headers on lpia. It needs some rules love, but not that difficult
<pitti> StevenK: CK crashed?
<StevenK> root     11053  0.0  0.1  32712  1596 ?        Ssl  Oct14   0:00 /usr/sbin/console-kit-daemon
<NCommander> cjwatson, for my first venture into kernel hacking, I shot myself into the foot quite well ;-)
<cjwatson> NCommander: first rule, keep it simple :)
<pitti> cjwatson: is it actually deliberate that the mobile seed isn't considered in component-mismatches?
<StevenK> pitti: Yes. The mobile seed meta packages are in universe
<NCommander> cjwatson, so shouldn't Linux be microkernel based if we're keeping things simple ;-)
<pitti> lool: seems we need to demote the Recommends: elisa-plugins-ugly to Suggests:; it's pulling in two handfuls of non-main-wanted packages; ok for me to do that? (or do you want to do it in bzr or so?)
<cjwatson> I take it you've never actually seen a microkernel
<NCommander> cjwatson, I wrote /dev/random for GNU Hurd :-P
<cjwatson> they are elegant, but hardly simple
 * NCommander was being sarcastic 
<lool> -ugly is supposedly in universe I think
<lool> let me check
<lool> yeah it is
<lool> besides, it's lagging, don't look at the current version
<StevenK> main can't really Recommend universe
<pitti> that's the very thing I want to fix, yes :)
<lool> right, I think we can demote the recommends from elisa to a suggests
<lool> i thought you were speaking of recommends of -ugly on other stuff
<lool> It's weird cause I thought I had fixed this before uploading elisa
<pitti> lool: no, just from the "elisa" package, that should solve it
<NCommander> cjwatson, so do you agree that linux-headers -> linux-lpia-headers makes sense?
<StevenK> pitti: And empties component-mismatches by about half?
<cjwatson> NCommander: more or less
<NCommander> cjwatson, ok, so I wasn't completely loosing my mind ;-)
<cjwatson> it'll certainly do the job for intrepid
<pitti> StevenK: not quite, by maybe 10 packages
<StevenK> pitti: Pity
<NCommander> cjwatson, what i386 kernels built out of -ports? That seems wrong ...
<cjwatson> for jaunty I really think some kind of re-merging of all these kernel sources makes sense
<StevenK> -386, isn't it
 * NCommander also notes the ports package needs some serious love
<cjwatson> NCommander: the 386 variant, as I said above
<NCommander> Oh
<pitti> lool: ok, I'll do the change now
<NCommander> sorry
<cjwatson> I think this is wrong
<NCommander> When I think of 386, I think of -generic
<cjwatson> and have said so several times to the kernel team
<StevenK> cjwatson: Me too
<NCommander> Its hard to think of it as a varient ;-)
<cjwatson> but nevertheless, it is the case
<lool> pitti: pushing already
<pitti> lool: oh, nice; thanks!
<pitti> lool: let me know when you uploaded,  I'll wave it through the queue
<lool> done
<StevenK> pitti: So the daemon didn't crash, but I lost my session?
<pitti> StevenK: well, did it crash? anything in /var/crash? or apport.log?
<pitti> StevenK: you don't "just lose" your session
<pitti> StevenK: ck-list-sessions is empty?
<pitti> it's usually because CK crashes
<StevenK> pitti: ck-list-sessions is empty, yes
<StevenK> pitti: /var/crash is empty, too
<StevenK> pitti: And nothing in apport.log
<StevenK> Well, nothing relevant in apport.log{,.1,*.gz}
<lool> cjwatson: (I'm testing my pygtk change in my ppa)
<seb128> StevenK: look for how long the ck daemon is running compared to your session?
<StevenK> Hm. A whole month difference
<StevenK> steven   27114  0.0  0.2 193700  3572 ?        Ssl  Sep24   0:03 x-session-manager
<StevenK> root     11053  0.0  0.1  32712  1596 ?        Ssl  Oct14   0:00 /usr/sbin/console-kit-daemon
<pitti> StevenK: so aport.log and crash report just got rotated away then
<cjwatson> lool: won't build on any of the affected architectures, mind you ...
<bigon> could someone have a look at bug 258192 it breaks ldap support of dhcpd
<ubottu> Launchpad bug 258192 in dhcp3 "problem with paths and binding to ldap server" [Medium,Confirmed] https://launchpad.net/bugs/258192
<StevenK> pitti: But it covers crashes before this boot, like back in May
<pitti> hmm
<lool> cjwatson: I changed it to trigger on amd64
<lool> cjwatson: But it was a good idea to remind me nevertheless, thanks
<seb128> StevenK: maybe it did abort and not crash
<NCommander> StevenK, I'm test building the changes now
<StevenK> NCommander: Which will take like 3 hours?
<NCommander> On this machine, kernel builds are pretty fast
<maco> can someone look at bug 282977 ? xscreensaver and gnome-screensaver both have entries in System->Preferences as just "Screensaver" in Intrepid.  Is it too late to nominate a semi-cosmetic but also rather confusing bug like that for release?
<ubottu> Launchpad bug 282977 in xscreensaver "gnome-screensaver and xscreensaver both appear in preferences list" [Low,Confirmed] https://launchpad.net/bugs/282977
<StevenK> seb128: That's possible.
<StevenK> I can recall that bug happening before
<StevenK> Like Dapper or Edgy
<maco> StevenK: the one i mentioned? crimsun said it was in hoary
<StevenK> I wasn't around for Hoary, but I remember it happening
<StevenK> maco: But yes
<StevenK> Ah, Breezy is the bug
<StevenK> pitti: Would that result in my lost session? console-kit-daemon abort()'ing?
<directhex> duplicate screensaver icons definitely worth fixing IMHO, it's a stupid annoying bug
<pitti> StevenK: yes, if it hits an assert or so
<Mirv> mvo: thanks for upload, fine now for intrepid. but out of interest, did you merge from Debian? I'd now have at least certain case of non-import.
<pitti> ScottK: still awake?
<Mirv> mvo: in case you did a merge, see http://paste.ubuntu.com/58718/
<pitti> StevenK: hm, seems that clamav slided back to universe, repromoting
<lool> cjwatson: Concerning the xvfb issue itself, it's relatively important to fix, I have little time today due to meetings and other issues here (see email), so feel free to grab someone to chase it -- especially if you know someone with ppc, sparc, or hppa hardware
<lool> Just for the record, I have ppc, but never used linux on it, would take me a while to setup
<mvo> Mirv: I can not currently merge from debian, they stopped publishing the po files - I think it was due to some hardware problems
<mvo> Mirv: it used to be on http://ddtp.debian.net/debian/dists
<lool> cjwatson: I was fortunate to test with ppa: testsuite fails on all arches when g_get_home_dir() isn't writable
<lool> cjwatson: I've pushed pygtk_2.13.0-0ubuntu8 with testsuite running everywhere but not failing the build
<mvo> Mirv: if you have more information, I would love to reenable the merge
<NCommander> lool, I have powerpc hardware I can test on
<lool> Can someone please accept pygtk?
<lool> NCommander: Cool, I need to disappear in some minutes to move to a new location to work
<lool> NCommander: Let me give you instructions
<lool> NCommander: the problem is that Xvfb doesn't work anymore on some arches
<NCommander> lool, I also have sparc (hardy only), and hppa (intrepid) access, but I don't have physical access to those boxs
<lool> NCommander: Might be an endianess issue, we don't know
<NCommander> And I don't have root on the sparc box
<lool> NCommander: A chroot on any of these arches is fine
<NCommander> I'll have to ping a sysadmin to get a sparc chroot
<NCommander> I do have ia64 also ;-)
<lool> NCommander: What you need is the intrepi's xvfb, try e.g. to launch "xvfb-run xterm -e ls" or something along these lines
<Mirv> mvo: like I said in another message earlier, DDTP is now hosted on official mirrors like ftp.de.debian.org, so there was no need for ddtp.debian.net hosting anymore
<NCommander> lool, I have never used xvfb, what's susposed to happen?
<lool> NCommander: You might want to pass -e xvfb-run.log to xvfb-run to see Xvfb errors
<lool> NCommander: xvfb is just like Xorg, except it doesn't use any physical device
<Mirv> mvo: eg. http://ftp.de.debian.org/debian/dists/sid/main/i18n/
<mvo> Mirv: right, but that is just the "Translation-*" files, right?there used to be a po file export too
<NCommander> lool, ok
<lool> NCommander: So what's supposed to happen is that the applications runs as if it was displayed on the screen, but it doesn't use any real hardware
<Mirv> mvo: oh, ok then, I have no idea about any PO export...
<lool> NCommander: it's used for graphical testsuites of misc packages, e.g. gtk, pygtk, bonoboui etc.
<NCommander> Ok, checking on powerpc
<mvo> Mirv: thanks, I will add code that does a Translation->po translation I think
<lool> NCommander: So the current Xvfb doesn't work; it seems it's since the new snapshot we pulled recently, around beginning of oct
<lool> 2:1.5.1-1ubuntu3 I would guess
<NCommander> lool, xvfb is not installable on powerpc it seems
<pitti> lool: pygtk accepted
<Mirv> mvo: yes, it might be they don't have resources to develop/admin it or something. would be nice for jaunty.
<lool> NCommander: It would help if you could test the current intrepid version, the 2:1.5.1-1ubuntu3 version, and git bisect between the two
<NCommander> git bisect?
<mvo> Mirv: I hope to find a bit of time to write this import for intrepid so that we can do another merge, but for jaunty we should talk to the debian team again I think
<lool> NCommander: Ok, so upstream and the ubuntu package use git
<NCommander> ok
<Mirv> mvo: ok, of course it'd be great for intrepid too, I just assume a great bit of hurry everywhere :)
<lool> NCommander: git allows you to do a dichotomy between two git "revisions" to see which is the first one which caused a regression
<NCommander> lool, its nice that someone cares about ports ;-)
<mvo> Mirv: it is, it just means longer hours ;)
<mvo> Mirv: but I think its worth it
<NCommander> lool, I try to avoid git like the plague, so your probably going to need to talk me through this (I apologize)
 * directhex gives NCommander the plague
<Mirv> mvo: it'd be great, yes, since together with the new app-install-data translatability it brings a better experience for gnome-app-install users
<lool> NCommander: It's called git bisect, has a man page, and it basically helps you in checkouting all intermediate revisions of a tree; you tell the tool what version you know fail, which one works, and it tells you to try one between the two; after each step, you tell the tool whether test failed or not, and it tells you next rev to try etc.
<lool> pitti: thx
<NCommander> directhex, I'm immune to your plague, I already suffered from mono
<pitti> doko: libspe2-dev recommends: cell-gcc, which is in universe; ok to drop that to suggests:?
<NCommander> lool, sounds like a feature bazaar should adopt ;-)
<mvo> Mirv: yes! that reminds me, have you seen  http://people.ubuntu.com/~mvo/nightmonkey ?
<mvo> Mirv: I think Nyitrai posted about it on the i18n list a while ago
<pitti> doko: (this wants to pull in cell-binutils, too)
<mvo> Mirv: it hopefully makes it easier to find out about relevant strings
<lool> NCommander: Projects using bazaar never have any regressions, they don't need the feature
<Mirv> mvo: actually not your version, someone hosted one for Finnish, though
<Mirv> mvo: yes it does
<mvo> Mirv: another think I would like to talk to debian about if/how we can push our translations back to debian
<NCommander> lool, so Microsoft should adopt bzr in place of source safe for Windows 7 ;-)
 * wgrant points NCommander at https://code.edge.launchpad.net/bzr-bisect
<pitti> doko: or can we demote elfspe2 instead?
<pitti> doko: (it seems to be seeded, no rdepends)
<Mirv> mvo: would be interesting. I've tried to suggest people to Debian's DDTP primarily (https://wiki.ubuntu.com/DdtpLpHtml etc.), but some languages have good amount of work done on ddtp-ubuntu as well
<mvo> Mirv: I share this view
<StevenK> pitti: Oh, blah
<StevenK> pitti: My -mid install does the same thing
<StevenK> pitti: But that has a session
<NCommander> lool, the PowerPC box is updating now, and the sparc one is available as well
<pitti> StevenK: still EPERM from gnome-mount?
<pitti> StevenK: can you pastebin the ck-list-sessions output?
<lool> NCommander: #281610
<lool> NCommander: I'm disappearing now, will read your comments via the bug
<StevenK> pitti: Not really, no network
<pitti> StevenK: check if is-local is TRUE and x11-display-device exists?
<pitti> StevenK: and if active is TRUE
<StevenK> pitti: active is FALSE
<pitti> StevenK: that would be it then
<StevenK> pitti: is-local is TRUE and x11-display-device is ""
<pitti> StevenK: hm, is that actually for your currently running session then?
<pitti> or maybe for VT1 or so
<StevenK> pitti: It says display-device = '/dev/tty7' , so I think so
<StevenK> NCommander: Still building?
<pitti> weird
<NCommander> StevenK, yup
<pitti> StevenK: how was this started? its not gdm, I figure
<StevenK> pitti: Directly
<StevenK> Let me dig
<pitti> StevenK: so probably through ck-launch-session in /etc/X11/Xsession.d/90consolekit
<StevenK> pitti: Sounds right
<StevenK> Hm.
<StevenK> I may have done a bad thing.
<StevenK> I gave my Q1 running -mobile to my wife. She has discovered playing Aislerot with a touchscreen, and now I might not get it back.
<wgrant> Haha.
<StevenK> pitti: Why would it not be active, then?
<StevenK> pitti: Do we need to call something later in mid-gui-start?
<pitti> StevenK: no, CK should be able to figure it out
<StevenK> pitti: It seems that doesn't hold true. :-P
<pitti> StevenK: so it doesn't have an x11-display?
<StevenK> pitti: Nope
<pitti> if not, that would probably be the reason
<StevenK> Surely $DISPLAY should be set that late ...
<pitti> seb128: is there a particular reason why we use 'libgtop' source package name, while Debian uses 'libgtop2'?
<seb128> pitti: no
<pitti> seb128: mind if I do an upload to change the name?
<seb128> pitti: that's just the upstream name
<pitti> seb128: and remove libgtop?
<seb128> pitti: go for it, I don't really see the point but whatever
<pitti> seb128: well, just being able to merge/sync later
<pitti> seb128: (it appears in component-mismatches, too)
<pitti> seb128: one source package should go; I don't particularly mind which one
<seb128> pitti: how is the source name revelant to component-mismatches?
<pitti> seb128: libgtop2 source doesn't build current binaries and thus wants to go to universe
<seb128> pitti: rename it, I was expected debian to rename the source but lool is against that so they will not likely do it
<pitti> seb128: ok, thanks
 * StevenK manages to prise his Q1 out of his wife hands
<doko> pitti, cjwatson: we did seed libspe2 because we wanted it on the cd. if we want to keep it, we should use binutils-spu and gcc-spu to build it. but I don't mind demoting
<StevenK> doko: You're no archive admin :-P
<StevenK> doko: I can demote it, unless pitti is all over it
<StevenK> NCommander: Is it done yet?
<pitti> doko: right, I guess the real question is "do we want to support cell in intrpeid"; so I guess we should either promote cell-gcc and the spu binutils as well, or demote it all?
<doko> StevenK: no time for that, have to fix packages like cacao and that ;p
 * pitti delegates resolution of this to StevenK, to fan out the enormous pile a bit :)
<cjwatson> cell-gcc/binutils must have been demoted, since I'm sure they used to be in main
<StevenK> cacao is broken?
<pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | gutsy/universe | source
<StevenK> I thought I fixed it
<doko> we never had the cell packages in main, afaik
<pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | hardy/universe | source
<pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | intrepid/universe | source
<cjwatson> odd
<pitti> cjwatson: it's just a recommends, wasn't relevant so far
<pitti> cjwatson: libspe2-dev recommends: cell-gcc, that's everything
<doko> the recommends does make sense
<cjwatson> hmm, ok, no build-dep?
<doko> no
<NCommander> StevenK, no
<StevenK> NCommander: How about now?
<StevenK> NCommander: Sorry :-P
 * NCommander takes his HPPA box and smashs StevenK head on it
 * StevenK re-adds ClueBat to his packing list
<StevenK> pitti: Any way to debug this mess, like ck-launch-... -v ?
<pitti> StevenK: you could augment 90consolekit with some gdb/strace/set -x love
<StevenK> set -x is no fun
<StevenK> "Yes, it calls ck-launch-session. I knew that already."
<StevenK> Bah, no strace
<pitti> StevenK: does ck-launch-session work correctly if you run it from an X terminal?
<pitti> StevenK: i. e. do you get a proper active session then, with DISPLAY?
<StevenK> pitti: Yup
<pitti> ArneGoetje: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt "binary-only main->universe" has a couple of packages which should be added to the language-support packages; can you please have a look?
<pitti> ogra: ah, discover1 can go now, thansk for fixing ltsp
<pitti> StevenK: gnutls13 can go now?
<StevenK> pitti: libflashsupport and kio-sword needs to die
<pitti> -- intrepid/universe i386 deps on libgnutls13:
<pitti> kio-sword
<pitti> libflashsupport
<pitti> oh, darn
<pitti> StevenK: any word from ogra about libflashsupport?
<pitti> or TheMuso?
<StevenK> pitti: ogra says kill it
<StevenK> pitti: No bug, though
<StevenK> pitti: Bug 267749 is close-ish
<ubottu> Launchpad bug 267749 in libflashsupport "investigate removal of libflashsupport from archive and ia32-libs" [High,Triaged] https://launchpad.net/bugs/267749
<pitti> StevenK: ok; want to do? I'd just ignore kio-sword, it seems to be stale anyway
<StevenK> pitti: icthux blah blah wants kio-sword
<StevenK> pitti: So we can bin libgnutls13 leaving it brokener
<pitti> right
<pitti> done
<doggymenz> 8.10 isnt out yet, and im looking forward to 9.04, with kernel 2.6.28 having merged GEM (kernel memory manager) in rc1
<StevenK> pitti: But that will make icthux uninstallable
<pitti> StevenK: it can just be unseeded there?
<StevenK> pitti: So we probably want to remove the package anyway
<StevenK> pitti: Since it doesn't make what cleaning we do, we break icthux
<slytherin> Now that default-jdk on powerpc is openjdk, can someone try doing a test build by enabling java features in openoffice.org for powerpc as well?
<maco> StevenK: what about that bug?
<pitti> tjaalton, bryce: x11proto-dri2, xserver-xorg-video-{nsc,radeonhd,tga} all want to go to universe; ok?
<maco> StevenK: libflashsupport is not needed in intrepid from what crimsun's been telling me
<maco> the combination of flashplugin-nonfree version 10 and libasound2-plugins and "asoundconf set-pulseaudio" takes care of it
<tjaalton> pitti: yep, dri2 is not needed yet, nsc doesn't work, radeonhd is not used by default and tga useful only on alpha
<maco> flashplugin-nonfree installs libasound2-plugins, and the configuration is pre-seeded in systems that have pulse, like ubuntu (as opposed to kubuntu since it uses phonon)
<pitti> tjaalton: thanks
<pitti> evand: usb-creator wants to go back to universe, please seed it to an appropriate place
<StevenK> maco: It hasn't effectively said "Please kill it"
<maco> StevenK: does a bug need to be filed saying it's unneeded in intrepid and reiterating its instability (as if that hasnt been mentioned by everyone but me all through hardy's cycle)?
<StevenK> maco: It needs to be effectively communicated to -archive, though
<maco>  ah wait now that firefox stopped timing out, that's basically what that bug says
<pitti> zul: you recently seeded virt-viewer to DVD, but there is no MIR, and it pulls in xen-3.1 into main; I unseeded it again for now; if you need it in main, please fix the package and create an MIR. thanks!
<pitti> zul, kirkland, dendrobates: nagios wants some more packages in main; can you please have a look at http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and check what should be promoted or demoted, or which dependencies should be weakened?
<StevenK> NCommander: Please grab me when the kernel finishes
<NCommander> StevenK, it's finishing now building packages
<pitti> seb128: hm, gnome-games-extra-data is in universe; is that deliberate, or a glitch?
<NCommander> StevenK, I need to make some tweaks because we now have package collisions
<NCommander> (i.e. linux-source/linux-doc now collide with the non-lpia packages)
<seb128> pitti: that's deliberate, there is no real point to have it in main since it doesn't bring anything useful
<pitti> seb128: ok; gnome-games-data recommends it, so that should be dropped to suggests then?
<seb128> pitti: and this way motu can do the updates, etc
<seb128> pitti: suggests look correct
<pitti> we do instal gnome-games by default, so the recommends doesn't do anything anyway
<pitti> seb128: ok, thanks; uploading
<seb128> pitti: thanks
<mvo> Riddell: the notification about fusa (that confused you yesterday) will only be shown when there is actually a gnome-panel running :)
<pitti> TheMuso: I dropped the festival recommends from libgnome-speech7 (see changelog for rationale); please yell if that wasn't right
<mvo> Riddell: thanks for reporting that!
<Riddell> mvo: thanks, that should sort it
<pitti> mvo: oh, that update-notifier change looks quite intrusive (run for non-admins)
<mvo> pitti: it is
<mvo> pitti: sorry for that :/
<mvo> pitti: its required so that every user seens the notification
<NCommander> StevenK, pijng
<NCommander> *ping
<pitti> mvo: it won't show the icon or upgrade stuff to non-admins?
<mvo> pitti: so far update-notifier did not start for non-admin users
<mvo> pitti: that means that no notification is shown for non-admins
<mvo> pitti: the patch changes it so that only the icon for updates is not shown, the other stuff (notifications, crashes, ...) are shown
<mvo> pitti: I'm not very happy about that myself, its unfortunate that this did not get the fusa migration work speced/discussed early
<amitk> NCommander: if you can work through the whole ports and lpia dependency mess, you should probably have an account on kernel.u.c :)
<NCommander> amitk, well, I got lpia's headers building
<amitk> NCommander: nice
<NCommander> amitk, now I just need to remove the package collisions, and then fix meta to refer to the new linux-lpia-* packages
<amitk> NCommander: meta has a git tree too
<NCommander> amitk, its not the prettest hack ever (I simply hooked binary-indep from binary-arch, but it does the trick)
<NCommander> Right :-)
<amitk> NCommander: just send me the patches with your signoff and I'll commit it to the git tree.
<mvo_> pitti: sorry, disconnected
<NCommander> amitk, Well, at the moment, I'm avoiding commiting, since I'm not quite sure how to make patches with git expect from the last commit to working base :-/
 * NCommander is really a git idiot
<NCommander> amitk, I assume a freeze exception for the kernel freeze date will be given since lpia doesn't have a working kernel?
<realist> I haven't quite got the hang of it yet, either.
<amitk> NCommander: ok, after the successful build, fakeroot debian/rules clean, and git diff > lpia.patch should work for now
<NCommander> amitk, is there a how to use git for idiots guide ;-)
<amitk> but the command you really want to look up is git-commit
 * NCommander understands rebasing and all that
<NCommander> DO I use debcommit once I'm done with everything and attach a new changelog?
 * amitk laughs. NCommander understands rebase and not commit. That's a first :)
<NCommander> amitk, I'm surprised no one else attacked this mess before :-/
<amitk> https://wiki.ubuntu.com/KernelGitGuide
<NCommander> amitk, I understand git commit -a easy enough, just not the specific rules w.r.t. to Ubuntu since it seems every patch landing is a single commit, and not ten
<pitti> mvo_: hm, wouldn't that mean that non-admins get a notification about a new ubuntu release?
<amitk> NCommander: kernel team has a lack of packaging experts. Most are simple kernel folk.
<NCommander> amitk, so I take it I'll be usefult hen
<amitk> absolutely
<NCommander> I looked at lpia lrm
<NCommander> That's going to be *fun* to fix
<NCommander> amitk, oh, this is everything I need to know about git, perfect :-)
<mvo_> pitti: no, that is the job of update-manager to display those
<amitk> NCommander: my motto was get it to work with minimal changes to the base Ubuntu kernel packages.
<mvo_> pitti: they won't see that in their menu and its not available via update-notifier (because the update icon is not shown for them)
<NCommander> amitk, lpia, lrm, or in general?
<amitk> NCommander: lpia, lpia-lrm, lpia-meta
<mvo_> pitti: its not ideal for crashes, because they will be asked about system crashes too, but because we disable crashreporting for final that should be ok
<NCommander> amitk, I'm just happy ports-meta finally cleared new, so we can have CDs for intrepid
<mvo_> it will also show reboot notifications for them, but that should be ok too, it uses the session to request the reboot so it should be equivalent for them to hit the menu item
<NCommander> amitk, I've done some kernel hacking before, I managed to get my ethernet card working on Hurd ;-)
 * NCommander also ported Linux's entropy framework to Hurd
<amitk> hmmm.. "Starting Administrative Application" and then nothing. Doesn't ask me for my password.
<amitk> NCommander: good to know...
<NCommander> amitk, so I won't break the kernel too badly
<amitk> heh
 * NCommander has more interest in ports vs. lpia/main
<NCommander> amitk, I actually been doing some work in rebasing ports to a more recent kernel
<amitk> NCommander: yes. we talked about this yesterday in #u-k
<NCommander> oh right
<NCommander> sorry, time is relative when you have a screwed up sleep cycle ;-)
<NCommander> w00t, successful build run :-)
 * NCommander now figures out what magic is needed to get docs and other fun packages not conflicting with each other
<amitk> mvo_: who should I ping if the graphical sudo dialog doesn't pop up?
<mvo_> amitk: that would be me I guess - what app do you try to start?
<mvo_> amitk: intrepid I assume?
<mvo_> amitk: could you please open a terminal and run "gksu id" there and see what it prints?
<amitk> mvo_: intrepid. update-manager and the bug-buddy both
<NCommander> amitk, are linux-doc packages not normally built?
<amitk> mvo: Segmentation fault (core dumped)
<mvo_> amitk: geh
<NCommander> or do we care about those at all?
<NCommander> (the rules file suggest that they are disabled on autobuilder runs, thus not built on Ubuntu)
<mvo_> amitk: do you have a crash file? or could run run gdb with it please?
<amitk> NCommander: they would be nice to have.
<emgent> popey: around ?
<NCommander> amitk, well, is it going to be different from the normal docs? (I can only see that being the case if the lpia and main kernels diverage in version parity)
<amitk> NCommander: they should be exactly the same i think
<amitk> s/i think//
<mvo_> amitk: can you see if gksu is crashing or sudo (that is called from gksu)
<mvo_> amitk: is that with compiz or without?
<NCommander> amitk, if thats the case, then the normal docs should suffice
<NCommander> (i.e., not much point in having a seperate linux docs package)
<amitk> mvo_: no compiz, amd64. I have the crash file in /var/crash. Any tool to extract the core out of it?
<lool> amitk: apport-cli should get you a bt
<amitk> mvo_: sudo apt-get blah works fine. So probably not sudo.
<pitti> lool: I demoted elisa-plugins-bad to universe for now; it pulls in tons and tons of stuff
<mvo_> amitk: update-notifier should have poped up a notifciaton about the crash, but apport-cli will do
<pitti> lool: if that's wrong, let's discuss that in a bit (I have a phone call now)
<mvo_> apport-cli -c /var/crash/crashfile iirc
<NCommander> amitk, building in my PPA to confirm success, and then I'll have a patch for you
<lool> pitti: It needs to stay with elisa
<lool> pitti: Perhaps we can demote some of its deps, but not -plugins-bad as a whole
<pitti> lool: ok, promoted back
<pitti> lool: at least the -ugly recommends needs to be dropped then
<lool> (or we can perhaps split it)
<lool> pitti: Sure
<pitti> lool: and gstreamer0.10-ffmpeg, too
<lool> pitti: Will look after lunch
 * lool disappears
<pitti> lool: libvisual-plugins -> MIR or drop recommends?
<popey> emgent: yes
<amitk> mvo_: https://pastebin.canonical.com/10309/ <-- top part of apport report. I think this bug is already in LP, let me find it
<mvo_> amitk: https://bugs.edge.launchpad.net/ubuntu/+source/gksu/+bug/277189 ?
<ubottu> Launchpad bug 277189 in gksu "(lib)gksu SIGSEGV" [Undecided,New]
<mvo_> amitk: could you still submit it via apport so that the retracer can do its work and produce a debug backtrace?
<amitk> mvo_: sure
<mvo_> amitk: and that happens for you without compiz, right?
<mvo_> amitk: (I ask because that code should be run only if compiz is available)
<mvo_> amitk: what video card/driver do you use?
<StevenK> NCommander: I'm back, I was eating
<NCommander> StevenK, success
<StevenK> \o/
<NCommander> StevenK, the headers came out properly
 * NCommander is doing one final build run to confirm success
<StevenK> NCommander: Won't that build run take another hour?
<NCommander> I caught a minor bug which I corrected, but I don't want anything to land in the tree until I'm absolutely sure I'm not going to hose a build ;-)
<NCommander> StevenK, not with -j4 and ccache
<StevenK> Heh
<NCommander> amitk & StevenK: http://paste.ubuntu.com/58754/ - current diff. If it looks ok to you, I'll put it in proper patch format and send it to ubuntu-kernel@l.u.c
 * NCommander realizes he's going to get that long awaited upload to restricted by fixing lpia lrm
<StevenK> NCommander: Actually, it's lpia-linux-restricted-modules
<NCommander> StevenK, yeah, lpia lrm :-)
 * NCommander is just lazy to type out the whole thing
<amitk> mvo_: https://bugs.edge.launchpad.net/ubuntu/+source/gksu/+bug/284894 , intel graphics. I'll attached details to the bug
<ubottu> Error: This bug is private
<NCommander> oh
<NCommander> you mean in the changelog
<NCommander> d'oh
<StevenK> NCommander: Right.
<StevenK> amitk: If you're okay with me sponsoring NCommander's work, I'm happy to do so.
<NCommander> I"ll correct that when I make a patch that can land in the tree
<mvo_> amitk: hm, could you make the bug public please? I can not access it it seems
<StevenK> NCommander: s/autobuilder/buildd/
<StevenK> NCommander: And the reason should be "this allows linux-headers-2.6.27-4 to use it's own headers, rather than the ones provided by the linux source package" rather than "this allows linux-lpia-meta
<StevenK> ... and linux-lpia-restrict-modules to exist and work correctly"
<NCommander> ok
<StevenK> Er, linux-headers-2.6.27-ABI-lpia
 * NCommander edits the changelog
<StevenK> NCommander: Besides, the kernel is in main
<StevenK> linux-lpia-meta is in restricted
<NCommander> er, wait, what?
<NCommander> Yeah
<StevenK> NCommander: "You looz"
<mvo_> MacSlow: could you please have a look at this crash http://launchpadlibrarian.net/18001582/Stacktrace.txt ? it seems to be in the blur patch for the gksu dialog
<amitk> mvo_: interesting why it became private. Try now.
 * NCommander figures out how to write the new changelog ;-)
<mvo_> amitk: excellent, thanks
<StevenK> NCommander: If you write in lol-speak, I'll steal your upload. :-P
<NCommander> lol-speak?
<NCommander> ack, THAT's evil
<StevenK> Haha
<mvo_> amitk: could you (just for the fun of it) enable compiz and run "gksu id" again? does it crash than too?
<NCommander> StevenK, see PM
<amitk> StevenK: let me look at it real quick. And I have no issues with you sponsoring him.
<NCommander> amitk, maybe this is a stupid question, but shouldn't the Signed-off-by: flag only be done by people who are ubuntu kernel team members, and not by the patch submittor?
<StevenK> amitk: It seems NCommander will feed you a git diff
<NCommander> *submitter
<amitk> NCommander: StevenK: diff looks ok to me except the ~ppa in the version.
<NCommander> amitk, that's gone for now just because I was uploading it to my PPA :-)
<amitk> NCommander: no, signed off is from anybody who does the work. I can append my sign-off saying I have reviewed it.
<StevenK> NCommander: I'd prefer it just go to the archive
<NCommander> amitk, oh I see. So commit locally, run git commit with the right message, then git format-patch and send it where specifically?
 * NCommander is learning fast
<NCommander> StevenK, any changes to the kernel need to land in git first AFAIK.
<NCommander> StevenK, and I'm just always a tad paranoid when touching the kernel ;-)
<StevenK> NCommander: They do not.
 * StevenK has broken that rule
 * NCommander would think thats bad practice then :-/
<NCommander> hola emgent
<amitk> NCommander: you have the correct sequence
 * NCommander waits for his build run to finish so I can do extactly that ;-)
<StevenK> pitti: How does c-m look now?
<NCommander> amitk, I assume linux-lpia-meta needs to be fixed next, right?
<StevenK> No
<StevenK> lpia-lrm needs to build next
<NCommander> restricted-modules then?
<NCommander> ah, ok
<StevenK> There's already a linux-lpia-meta upload, too
<StevenK> So after I sponsor you, I get to fix the rest
<NCommander> StevenK, that might need to be changed because of the changes in the headers package names
<NCommander> StevenK, you sure you want to fix the lrm package?
<StevenK> NCommander: As long as you fixed linux-headers-2.6.27-4-lpia Depends, lpia-lrm shouldn't
 * NCommander won't mind getting more experience in this respect in
<NCommander> StevenK, its linux-lpia-headers now
<NCommander> (might not be strictly necessary, but that puts it in line with -ports, which does the same thing)
<StevenK> NCommander: Right. Only -4$ should change
<StevenK> Beh
<NCommander> Er, its linux-lpia-headers-2.6.27-4-$FLAVOR
<StevenK> Grumble
<StevenK> I like that less
<StevenK> Then lpia is in it twice
<NCommander> amitk, which way should be it set
<ogra> cant we drop $FLAVOUR altogether from it ?
<NCommander> ogra, probably the lpia flavor should become generic
<NCommander> i.e. linux-lpia-headers-2.6.27-4-generic
<ogra> heh, fun
<NCommander> It's only -lpia because it used to be built out of the main source package
<NCommander> oh wait
<NCommander> We can't do that
<NCommander> wait
<NCommander> we can
<StevenK> Argh
<ogra> heh
<amitk> my head hurts
<StevenK> NCommander: Stop breaking the world!
<NCommander> :-)
 * ogra doesnt mind, as long as he fixes it again
 * NCommander forgot you can have the same package name from multiple source packages as long as there are no collisions
<StevenK> NCommander: I'd rather it stayed with 'linux-headers-2.6.27-<ABI>-<FLAVOUR>' which Depends on linux-lpia-headers-2.6.27-4
<StevenK> Er, linux-lpia-headers-2.6.27-<ABI>
<NCommander> There is still a provides linux-headers
<NCommander> and linux-headers-$version
<NCommander> (and 2.6)
<StevenK> That way doesn't involve an upload of lrm, fix it.
<NCommander> Well, the problem I have is the linux-headers package is arch all
<mvo_> amitk: could you please run "python -c 'import gtk.gdk; print gtk.gdk.display_get_default().get_default_screen().is_composited()'" ?
<StevenK> linux-headers-2.6.27-<ABI>-<FLAVOUR> isn't Arch: all
<StevenK> linux-lpia-headers-2.6.27-<ABI> won't be either
<NCommander> amitk, so you agree with StevenK that it shouldn't be linux-lpia-headers?
<StevenK> NCommander: Half of them shouldn't be linux-lpia-headers
 * NCommander notes his diff gets a hell of a lot smaller then
<NCommander> StevenK, er, what?
<StevenK> NCommander: It should stay for the package that ends with -<ABI> but not the -<ABI>-<FLAVOUR> packages
<amitk> NCommander: not being linux-lpia-headers would bring it more in line with the rest of the kernel packages
<NCommander> Oh
<NCommander> OH
<NCommander> I get that
<NCommander> That makes perfect sense
<NCommander> :-)
<StevenK> It should make the diff smaller, too
<amitk> mvo_: Just tried enabling compiz, it was refused for my graphics chip
<NCommander> StevenK, not really, I need to make additional rules changes to make this fly, there is an assumption on the header package name being consistent
<NCommander> Ok
<NCommander> Now to test build :-)
<amitk> mvo_: interestingly, your python script returns "True"
 * NCommander notes someone should bump the standards version
<NCommander> 3.6.1 is old!
<NCommander> amitk-lunch, how do I undo a commit?
 * NCommander discovered gedit should not be used as EDITOR when dealing with git
<StevenK> Haha
<StevenK> git uncommit ?
<amitk-lunch> git reset --soft HEAD^
<highvoltage> heh
<pitti> StevenK: a bit better, but elisa is still wreaking a lot of havoc; I'm back from my phone call, I'll continue to attack it now
<pitti> there's a plethora of perl modules which want to get in, too, untangling this will take a while
<NCommander> THat didn't work
<NCommander> bah
 * NCommander saved a diff
 * NCommander blows away his branch and reclones
<NCommander> Git feels like RPM. You can shoot your foot off, then spend the next week figuring out how to reattach it
<Mithrandir> amitk-lunch: or just git commit --amend
 * NCommander has already rebuilt the git tree in the time it would take to figure that out ;-)
<NCommander> amitk-lunch, I got a patch for you when your back
<StevenK> NCommander: Can I see the new diff?
<StevenK> pitti: I note bug 221844 looks like what I am seeing
<ubottu> Launchpad bug 221844 in consolekit "no session is set active by consolekit" [Undecided,New] https://launchpad.net/bugs/221844
<mvo_> amitk-lunch: thanks, I was suspecting this
<amitk-lunch> Mithrandir: git commit --amend doesn't help if you want to remove some stuff from the existing commit AFAIK.
<amitk> NCommander: shoot
<cjwatson> asac: have you gone through all the possible NM regressions listed in http://people.ubuntu.com/~sbeattie/regression_tracker.html?
<cjwatson> asac: there aren't lots, but some of them are still New/Undecided
 * NCommander returns with coffee :-)
<NCommander> StevenK & amitk http://paste.ubuntu.com/58771/
<StevenK> NCommander: Stop saying linux-lpia-headers-* in the Description
<StevenK> That is my complaint. If it builds, I'm good
<StevenK> My only complaint
<NCommander> You said that changelog entry was good!
<amitk> frozen browser...
<NCommander> :-P!
<StevenK> NCommander: That's the Description
<StevenK> NCommander: The changelog entry is fine
<emgent> heya NCommander
<emgent> sorry for delay..
<NCommander> Morning emgent
<NCommander> emgent, no problem, I just got a crash course in kernel hacking, and for some strange reasoning fixing linux-lpia ... :-)
<emgent> hehe
<StevenK> NCommander: Description of packages != changelog entry
<NCommander> StevenK, ok, ok, point taken!
 * NCommander will give you a revised patch once I confirm the rules build properly
<mvo_> amitk: is there anything special in your /etc/X11/xorg.conf ? sorry for asking so many questions, but I wonder what might cause that you get the is_composited = true
<amitk> NCommander: so you haven't tested this yet?
<NCommander> amitk, I had to make one additional change to rules which is in the patch, its still building
<NCommander> SOrry if that wasn't clear
<asac> cjwatson: no. will go through this afternoon. thanks. actually havent used that site :/
<amitk> mvo_: https://pastebin.canonical.com/10311/ xorg.conf, glad to help track this down.
<amitk> NCommander: ack
<NCommander> amitk, I need to change the package description in the control files, but the stuff that actually changes stuff is fine as is.
<StevenK> NCommander: It builds correctly?
<NCommander> Still building
<fta> seb128, pitti, i'm having a problem with the last nspluginwrapper i pushed 2 days ago. it's supposed to build "Architecture: amd64 i386", yet, only the amd64 deb has been produced, seems i386 was just ignored. See https://edge.launchpad.net/ubuntu/intrepid/+builds?build_text=nspluginwrapper&build_state=all and https://edge.launchpad.net/ubuntu/+source/nspluginwrapper/+publishinghistory#  Any idea why?
<pitti> fta: I bet it's in P-a-s
<pitti> %nspluginwrapper: amd64      # 64-bit wrapper for 32-bit i386 plugins
<pitti> fta: can you please talk to lamont or infinity? They can fix that, if the package actually makes sense on i386
<fta> now it does
<fta> the previous version was already on 64 + 32
<NCommander> pitti, nspluginwrapper can prevent firefox from crashing if flash hangs
<directhex> what's the use-case for it on i386? i don't get it :|
<NCommander> pitti, so there is some point to having it on i386
<directhex> nspluginwrapper is doom. we hatses it. why would you use it if you had the option not to?
<lool> pitti: Pas was borken two days ago
<lool> After the move to cocoplum
<NCommander> who broke P-a-s?!
<ogra> asac, midbrowser doesnt pick up the gnome proxy settings (i guess thats by design since it wasnt built for gnome), can you point me to the area where to look in FF to make that hapen ?
<ScottK> pitti: Here now if it's still relevant.
<lool> Bug #283731
<ubottu> Launchpad bug 283731 in soyuz "P-a-s interepreted differently in Debian and Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/283731
<lool> (bug title is wrong, it was Pas missing from cocoplum entirely)
<pitti> ScottK: sorted out now, thanks
<ogra> asac, or would that be a heavy patch to midbrowser ?
<fta> lool, pitti: so, if it's fixed, how can i force the build? bump and repush? or ask an lp admin ? or what?
<NCommander> amitk, waiting for the kernel to build sucks
<lool> fta: You're saying nspluginwrapper should be built on more than amd64?
<pitti> fta: it's not fixed yet, P-a-s says "just amd64"
<pitti> see my copy&paste above
<lool> Now the Pas entry needs fixing
<fta> lool, yes, it was before too, no reason to stop.
<lool> You need to mail lamont + elmo + infinity to ask for the addition on other arches
<fta> pitti, ok, i'll ask. thanks
<lool> fta: Sent you list of email addresses in query
<fta> lool, thanks
<amitk> NCommander: story of my life :) Though I do have slightly faster machines.
<lool> pitti: I'll try testing elisa without the packages you hinted at in a sec
<lool> If I get it working on ati r500
<NCommander> amitk, it reminds me of xkcd
<lool> Otherwise, it will have to wait that I get back home
<pitti> lool: promoting some harmless packages is fine, too, but some are tricky
<pitti> lool: merci
<lool> gstreamer0.10-ffmpeg obviously isn't possible
<seb128> lool: why?
<lool> Doesn't it pull ffmpeg libs which we don't want?
<lool> pitti: In general, elisa isn't trivial because it's huge python import hub
<seb128> lool: the ffmpeg source is in main apparently
<lool> seb128: Ok; I know it's handled very specially
<lool> Indeed libavcodec51 is in main, so it wouldn't be a problem to promote gstreamer0.10-ffmpeg due to ffmpeg I'd guess
<lool> the dep was added for 0.5 by Phil
<lool> seb128: Promoting gstreamer0.10-ffmpeg to main seems risky in terms of codec installation though
<lool> It provides many codecs, and I'm not sure I'd be confortable making the list visible to users at this point of the cycle
<ogra> Keybuk, do you plan to revisit https://wiki.ubuntu.com/DesktopTeam/Specs/Prefetch for intrepid ? (and are you aware of sreadahead ? http://www.moblin.org/downloads/super-read-ahead-002) ...
 * ogra was asked that by some mobile community people yesterday
<ogra> err
<ogra> s/intrepid/jaunty/
<seb128> lool: right, I just know slomo asked why ffmpeg was in main and not gst-ffmpeg this week and I was not sure if there was a good reason
<Keybuk> Some amount of revisiting prefetch/readahead/etc. is definitely on the cards
<ogra> great
<ogra> thats what i thought
<ogra> but wanted sure i didnt talk rubbish
<ogra> +make
<Keybuk> the biggest problem with jaunty is going to be prioritising
<lool> seb128: There's an interesting problem that the package faces: it supports more codecs than advertized via it's headers when it's used with the multiverse libs
<ogra> yeah
<lool> I'll mention to slomo
<lool> ogra: sreadahead is being itped in Debian IIRC
<lool> debian #502121
<ubottu> Debian bug 502121 in wnpp "ITP: sreadahead -- Super Read Ahead" [Wishlist,Open] http://bugs.debian.org/502121
<lool> I wonder how the next readahead with additional features will be called -- hreadahead?
<directhex> sreadahead++
<lool> Or MiReadAhead
<pitti> mvo_: u-n will only start for UID >= 500? (it says 'make sure to not run for guest')
<ogra> extra-readahead :)
<ogra> uber-readahead
<pitti> lool: skimahead
<lool> -ng
<directhex> of course, doesn't readahead violate microsoft's superfetch patents? :O
 * lool scratches-head
<Keybuk> directhex: what patents?
 * Keybuk never investigates such things
<lool> patents to read from files before using them!
<Keybuk> which means I don't know about them
<Keybuk> which is a valid defence
<cjwatson> wise advice for programmer
<cjwatson> s
<NCommander> Keybuk, it's not a complete defense
<cjwatson> NCommander: it's a defence against punitive damages
<NCommander> Keybuk, it just means that you'll be hit with lesser max charges
<cjwatson> AIUI
<cjwatson> which isn't to be sneezed at
<NCommander> cjwatson, you can still be hit with charges, just to a lesser extent
<NCommander> */criminal justice student*
<cjwatson> yes, that's what I said
<NCommander> oh
<NCommander> Hrm
<directhex> actually, seems every bugger has a prefetch patent. ibm, sun, hp...
<cjwatson> or triple damages, or whatever they're called in your jurisdiction
<directhex> dec
<NCommander> I won't be suprised if someone had a patent on breathing
<pitti> NCommander: yes, Darth Vader
<Keybuk> if they don't, I think I'll register one ;)
<lool> NCommander: Make sure you check before your next breath
<ogra> check *fast* though :)
<Keybuk> a friend of mine once tried to patent entry of text onto a computer screen through use of a mechanical input device
<lool> haha
<Keybuk> it only got rejected because a patent already existed
<amitk> NCommander: http://www.freepatentsonline.com/5685292.html luckily it is free :)
<pitti> seb128: deskbar-applet recommends python-soappy; however, that's in universe and it explicitly says it's deprecated and not maintained any more
<pitti> seb128: it also pulls in python-fpconst, but that's a no-ob
<NCommander> Keybuk, that's wrong
<asac> ogra: hmm
<seb128> pitti: no clue about those, that comes from debian, I guess it's alright to just not recommends those or change to a suggest
<asac> ogra: in the past we maintained a fork for xulrunner in mobile
<asac> ogra: the question is, whether you really need "gconf" integration ... or if the env http_proxy... support is enough
<pitti> seb128: ok
<pitti> seb128: doing another gnome-games upload, FYI
<pitti> seb128: (ok for you?)
<StevenK> NCommander: Is the kernel still building?
<asac> ogra: if you need gconf integration we need to do a mobile specific xul build again ... unfortunately
<NCommander> StevenK, yes
<seb128> pitti: yes, I'm not working on any package right now so feel free to do any desktop upload
<asac> ogra: so let me know ;)
<pitti> seb128: roger
<lool> asac: Sorry, didn't have time to work on tihs
<mvo_> pitti: yes, that is modelled after the gdm-guest-session, I added the same checks in u-m as you did in the guest session
<StevenK> asac: You can't enable gconf for everything?
<lool> asac: I prefer we live without; we have no place for forks anymore, nor do we want to live with non-Ubuntu bits
<asac> StevenK: no, simply because upstream doesnt want that (YET)
<ogra> asac, well, -mobile uses standard packages and the generic arch
<lool> "ubuntu4ever"
<pitti> mvo_: ok, thanks; seems we don't have much choice about it anyway, I'll wave it through now; after it's built, can you please mail u-devel@ about a call for testing?
<asac> ogra: right.
<mvo_> pitti: sure, thanks
<lool> StevenK: It needs to be moved as an extension, it can't be in libxul
<asac> ogra: so ... it should support the "normal" mechanism that picks the proxies from environment
<apachelogger> james_w: hey, are there concrete plans for a migration to bzr based development?
<ogra> asac, so thats set in xul, not in the frontend, i see
<lool> It shouldn't be too hard to move it, if I recall asac's instructions, just ENOTIME
<ogra> asac, i'll have to ask ian_brasil about it then
<asac> ogra: xul has to provide the backend capability
<ogra> asac, btw, ubuntu ?
<asac> ogra: midbrowser has to select the default it wants
<ogra> *ubucon
<ogra> heh
<james_w> apachelogger: yeah, though the concrete is just being poured
<asac> ogra: most likely that default is currently gconf -> which means that it doesnt work
<james_w> apachelogger: is there something you want to know specifically, or you are just interested?
<ogra> asac, well, gconf means gnome setting, no ?
<ogra> so that should work
<asac> lool: right. i didnt do it yet. ENOTIME is one reason... the other is that it dropped off my radar as noone complaine :/
<lool> ogra: It doesn't because we don't have the xulrunner backend fo rit
<ogra> i think the main prob is that you cant reach the midbrowser menu in mobile
<asac> ogra: gconf means "perfect gnome setting"
<apachelogger> james_w: if I can get the fellow Kubuntu dudes to agree, I'd like to move all core KDE packages to bzr in the jaunty cycle, does that make any sense?
<ogra> so my guess was it would be best to just have it use the setting we have an UI for
<asac> ogra: for instance apt or update-manager use the "env" either afaik
<ogra> ah
<asac> ogra: so its not midbrowser alone that would have a "not perfect" solution
<ogra> right
<lool> Right
<lool> But if you set http_proxy, everybody should be happy
<asac> but that gconf thing is nice
<lool> Damn, just setup iptables!
<lifeless> mvo_: so
<ogra> lol
<NCommander> apachelogger, no objections here
<asac> if you edit proxy settings in gconf it will instantly update midbrowser and if you edit it in midbrowser it will update gconf ;)
<james_w> apachelogger: yeah, we're aiming to have packages available in bzr for the opening of jaunty, but it doesn't look like we'll be able to put them on launchpad for a little while, so they will be read-only to start with.
 * ogra tries 
<asac> lool: yes. but i think we have to switch the default proxy setting still
<asac> e.g. midbrowser currently has "gconf" as proxy method
<asac> and it should be "system2
<james_w> apachelogger: but they will be kept up-to-date from uploads to the archive.
<lool> asac: We should do that now; doesn't sound long to do; it's still in git at moblin?
<james_w> apachelogger: and Debian won't be available, which means you won't be able to merge from there yet.
<lool> asac: (are you working with moblin people?)
<asac> lool: its just a one line patch
<lool> Yeah
<james_w> apachelogger: but we can work around these issues if you want to go for it.
<asac> lool: well. midbrowser is in maintenance mode. just basic communication is still done with them
<lool> asac: Would you have the time to push that fto git and intrepid?
<ogra> hey, it works perfectly with the gnome capplet
<lool> asac: Ok; I wondered about midbrowser for moblin 2
<asac> ogra: what does midbrowser have for network.proxy.type
 * ogra will keep quiet in the future before he complains
<asac> lool: most likely everything will go for fennec ... which we should do to in the next cycle i guess
<sdschwarz> Hi! I've got a question about usb-creator: When creating space for persistency, does it make a casper-rw file or a casper-rw partition?
<ogra> all persia's fault
<NCommander> StevenK, its almost done building
<StevenK> \o/
<persia> ogra, What?
<ogra> asac, 5
<ogra> persia, proxy works fine if you use the gnome proxy applet to set it
<asac> ogra: ok so it works?
<persia> ogra, Right.  That's not in -mid.
<apachelogger> james_w: sounds good :) I'll add the topic to a Kubuntu meeting and contact you to find a date/time, so you can attend
<james_w> apachelogger: great, I'd be happy to
<mvo_> lifeless: so?
<ogra> asac, if i use "apply systemwide" at least, i didnt try it differently yet
<ogra> asac, but there is a way to make it work, so nothing i need to look deeper into for mobile at least ... no idea about mid though
<lifeless> mvo_: conflict finder
<lifeless> mvo_: I see you changed the error :P
<lifeless> mvo_: I haven't had time to dig
<asac> ogra: ok. but changes dont apply instantly right? e.g. you still have to relogin
<pitti> Riddell: koffice-i18n-engb (main) currently recommends kde-i18n-engb (universe); what's the best course to fix that?
<ogra> no, works i get a direct complaint that the proxy is unreachable in midbrowser
<lifeless> pitti: I suggest a patch and an upload
<ogra> looks perfect to me
<lifeless> :>
<Riddell> pitti: make it recommend language-pack-kde-en I guess
<pitti> Riddell: I wondered whether koffice-i18n-engb actually makes sense in main
<apachelogger> Riddell: wouldn't that be the KDE 4 translation?
<pitti> Riddell: isn't it just stripped and thus completely empty?
<pitti> lifeless: well, in this situation it's not actually obvious
<Riddell> pitti: it has to be in main so launchpad extracts the files from it (same as k3b-i18n)
<lifeless> pitti: its 2345 here, I was being entirely silly
 * pitti hugs lifeless
 * lifeless hugs back
<Riddell> apachelogger: it should be all translations in kubuntu intrepid
<pitti> Riddell: hm, then I wonder why kde-i18n-engb isn't actually in main; it should be stripped and moved to langpacks, too?
<zul> pitti: is  it nagios-plugins having problems?
<Riddell> pitti: it's not used not, that's the KDE 3 one
<Riddell> pitti: it's not used now, that's the KDE 3 one
<pitti> zul: nagios-plugins-extra pulls in fping, nagios3-common pulls in nagios-images; just search for "nagios" on the URL
<apachelogger> *cough* used in KDE 3 apps
<pitti> Riddell: ah, ok; then the changed dep makes sense; shall I just uplaod that?
<Riddell> pitti: yes please
<Riddell> apachelogger: only universe ones
<pitti> zul: and -extra wants qstat, too
<apachelogger> ok
<pitti> zul: should -extra actually be promoted to main? (isn't now)
<cjwatson> sdschwarz: a file
<zul> pitti: we had this problem in hardy as well, I dont think -extra needs to be in main Im not sure what nagios-images is gimme a minute
<pitti> zul: or nagios-plugins? (both that and -extra are in universe ATM)
<pitti> zul: ah, nagios3-common (main) Recommends: nagios-plugins (universe); that's probably what should be changed?
<zul> to a suggests?
<pitti> zul: if you don't actually want the plugins in main, then yes
<mvo_> lifeless: I have some code in my branch that mostly makes it work, but the remaing issue is the one where strom complains, I think I sent you the error message some days go
<pitti> zul: if you do, we need some MIRs or dependnecy changes for fping and qstat
<lifeless> mvo_: oh
<zul> nagios-plugins should be in main nagios-plugins-extra shouldnt (because of fping etc)
<apachelogger> ogra: what is the difference between ubuntu-mobile and ubuntu-mid?
<pitti> zul: and the -images thing is an entirely separate problem
<lifeless> mvo_: uhm, can you send it to me again, evolution-fail
<mvo_> lifeless: its not merged into the production tree yet, I didn't want to break anything
<zul> pitti: yeah I didnt handle nagios this time around so Im not quite sure what that is
<mvo_> (harder)
<lifeless> :P
<pitti> zul: ok, then plugin can't depend: plugin-extra
<zul> pitti: yep
<ogra> apachelogger, https://wiki.ubuntu.com/MobileTeam/Mobile/History
<persia> apachelogger, ubuntu-mobile is based on GNOME, and loosely designed for 7-9" screeens (although it has been used on larger and smaller).  Ubuntu MID is based on hildon, and loosely designed for 4-6" screens (although it also has been used on different sizes).
<NCommander> amitk, note to self, figure out a better way to hook up pbuilder and ccache :-)
<pitti> zul: who in the server team can I bother about nagios then? (or will you pass it on?)
<mvo_> lifeless: this is the error from my branch https://pastebin.canonical.com/9716/
<zul> pitti: Koon but he isnt here today afaik
<zul> im dealing with it now though
<lifeless> mvo_: its trying to insert something it already has, or thinks it has
<zul> pitti: what we did for hardy was to split off nagios-plugins-extra for its own package
<lifeless> mvo_: is that testing on your machine, the test suite, or trying to run it live ?
<apachelogger> ogra, persia: so basically -mid is the better mobile desktop?
<pitti> Riddell: hm, that looks curious; all koffice-i18n-* are in universe, except koffice-i18n-engb; I guess it is the one main package which keeps the entire source in main and thus translation-stripped
<mvo_> lifeless: running it life with a copy of the database
<ogra> apachelogger, no
<mvo_> lifeless: (in my homedir)
<pitti> zul: aah
<persia> apachelogger, Nope.  They are different, and meet different use cases.
<zul> pitti: so I will do that now :)
<pitti> zul: thanks
<persia> apachelogger, join #ubuntu-mobile, and we can discuss in depth.
<lifeless> mvo_: we need to trap the failing data, and then confirm that a) it is a dupe, and b) why
<pitti> zul: so, the -extra dependency and look what -images does (promote or drop dependency)
<ogra> apachelogger, mid is better for devices you carry in your pocket usually, mobile rther targets UMPCs
<zul> pitti: sounds like a plan :)
<pitti> zul: I promoted nagios-plugins to main; let me know about -images
<pitti> zul: great, thanks!
<zul> pitti: do we still have to do the MIR if we want nagios-images in main as well?
<pitti> zul: no, it's from a source already in main
<pitti> zul: just make sure it's sane and something we want
<zul> k
<mvo_> amitk: I uploaded a new libgksu (macslow fixed it) - please let me know if that fixes the issue for you, it should be available in ~1-2h if its not in unapproved for too long
<lool> pitti: Sorry, elisa on ati r500 is too slow; I could setup fglrx, but prefer testing on intel this we or next week to confirm whether libvisual is fine
<Riddell> pitti: not a very elegant solution but it works
<lool> (it's demotion)
<lool> demoting -ffmpeg is fine, it's only to enable more formats
<amitk> mvo_: thanks
<mvo_> lifeless: right, let me add something so that is prints what it add
<pitti> Riddell: yeah, I know; koffice-l10n upload prepared
<pitti> Riddell: kpovmodeler -- remove from Kubuntu.Intrepid dvd seed or promote?
<NCommander> StevenK, it's almost done building
<lool> pitti: pushed -bad demoting -ffmpeg for now
<Riddell> pitti: hmm, let me install and see how well it works
<lool> I know that libvisual is used for visualization, and I think there's an alternate renderer, but need to try out without to see how it looks
<StevenK> NCommander: You said that before
<pitti> lool: right, was just going to ask
<NCommander> StevenK, its in the install phase :-)
<lifeless> StevenK: only another day or so
<rainct> Uhm.. Rhythmbox on Intrepid crashes with "(rhythmbox:6703): GLib-GIO-CRITICAL **: g_file_get_uri: assertion `G_IS_FILE (file)' failed" each time I try to import my complete audio library..
<Riddell> pitti: works for me, promote?
<lool> rainct: isolate the culprit and file a bug with a test case please
<pitti> lool: oh argh, soyuz ate the binaries of -plugins-bad (demotion/promotion in the same run, it doesn't seem to like that)
<pitti> Riddell: ack
<lool> rainct: You can rhythmbox -d to see what it's doing
<lool> or strace if all fails
<pitti> lool: so we now need a -bad upload anyway :/
<lool> pitti: We might promote visual?
<pitti> Riddell: done
<pitti> lool: yes, if libvisual is sane, ok for me
<lool> But I prefer not promoting it at this point if possible
<lool> So will test and report
<pitti> lool: do you still have hte old c-m page? the current one has all of elisa dropped due to the binaries going to oblivion
<lool> if it's ugly, will review or file a MIR
<lool> c-m?
<pitti> lool: promoting a sane package is less intrusive than ripping apart the package
<pitti> lool: component-mismatches.txt
<lool> No, it's not in my cache anymore
<lifeless> gnight
<pitti> lool: ok, so let's sort out ffmpeg and libvisual (for both: either promote or drop recommends), and see later what remains
<pitti> sleel well, lifeless
<lifeless> mvo_: drop me mail if you would
<lool> pitti: I dropped recommend on ffmpeg already
<mvo_> lifeless: sure, will do
<mvo_> lifeless: its rather late in your TZ, right?
<lifeless> 0002
<lifeless> so very early :P
<mvo_> :P
<NCommander> Oh ****, got to run
<rainct> lool: ok, it crashes if there's a directory without execution permission
<pitti> $ change-override.py -S -c main ubuntu-policy
<pitti> oh dear, how could we have *not*? :-)
<geser> Riddell: do you know if qyoto can be build with libsmokeqt4-2-dev? This would allow to kill the libqt4-ruby source package (it got merged into kde4bindings)
<cjwatson> oh, that reminds me, I need to push current ubuntu-policy bzr to the archive
<lool> rainct: Please look for an existing bug or file one :)
<StevenK> pitti: Haha
<pitti> cjwatson: if you do it now, it will fail to upload (no problem, we can give it back, just FYI)
<rainct> lool: yep, I'm doing that right now :)
<pitti> anyway, high time for lunch, bbl
<lool> pitti: bon appÃ©tit
<pitti> lool: merci Monsieur
<cjwatson> pitti: yeah, I know
<cjwatson> though thanks for the reminder :)
<Riddell> geser: what does qyoto use currently?
<geser> Riddell: it build-depends on libsmokeqt4-dev (build from libqt4-ruby)
<Riddell> geser: I suspect it doesn't use that, qyoto is from kde4bindings so it should build with the smoke from kde4bindings
<geser> Riddell: ah, I see now qyoto got also merged into kde4bindings
<Riddell> yep
<geser> so it can get removed to (the old qyoto source package)
<directhex> it did. i'm talking to pusling about qyoto right now
 * rainct created bug #284970
<ubottu> Launchpad bug 284970 in rhythmbox "Rhythmbox crashes if you try to import a directory which contains directories without execution permission" [Medium,Confirmed] https://launchpad.net/bugs/284970
<Riddell> directhex: for Debian?
<geser> Riddell: should I reassign the old qyoto bugs to kde4bindings before filing a remove request for it?
<Riddell> geser: ok
<bugabundo_work> doko: ping
<directhex> Riddell, aye
<ScottK> geser: Bug reassinging can be done after it's removed.  It's not a prerequisite for the request.
<jdong> tedg: what's the status on getting 278810 into Intrepid?
<Riddell> geser: I can just remove it, no need for a request
<doko> bugabundo_work: ?
<bugabundo_work> doko: can you give a kick jump to #ubuntu+1 to answer the usual question if OOo will be in ibex? thanks
<Riddell> don't we have a list of source packages that don't build any packages?  opposite of NBS
<doko> OOo is in intrepid
<bugabundo_work> sorry
<bugabundo_work> OOo3
<bugabundo_work> lol you knew that...
<tedg> jdong: Needs release team approval.  I realized I didn't subscribe them... I can do that.
<cjwatson> tedg: at this point, please upload before approval; it will be held in the queue
<Riddell> geser: removed
<bugabundo_work> doko: danbh_intrepid was the guy asking
<jdong> tedg: ok, cool
<doko> no
<tedg> cjwatson: Well, I can't do that :)  If you'd like to sponsor it... ;)
<cjwatson> well, I mean get somebody to upload before approval
<tedg> cjwatson: Should I still subscribe the release team?
<jdong> Keybuk: ^^ you were interested in bug 278810; can you upload? :)
<ubottu> Launchpad bug 278810 in fast-user-switch-applet "Doesn't always display suspend / hibernate options (race between g-p-m and f-u-s-a?)" [Medium,Fix committed] https://launchpad.net/bugs/278810
<geser> Riddell: can you also remove the libqt4-ruby source package?
<Riddell> ok
<Riddell> geser: gone
<cjwatson> that's probably a good idea, I don't currently speak dbus well enough to review this
<geser> Riddell: thanks
<cjwatson> (I should ...)
<tedg> DBus, ten times more useful than Esperanto.  :)
<jdong> tedg: but DBus doesn't get you into the cool clubs on campus
<jdong> it does get you strangled every time you non-sarcastically start a sentence with "I love how NetworkManager..."
<nand> Hey!
<Keybuk> looks reasonable
<nand> I'm tracking down and updating the status of the latest "in development" ideas. Unfortunately some of them, I can't find out myself the status.
<nand> Anyone knows about the status of https://wiki.ubuntu.com/KernelTeam/removing-old-kernels ?
<ScottK> nand: I think the latest in development ideas this week is get Intrepid out the door.
<nand> ScottK: Sorry, was not clear : I'm updating this list : http://brainstorm.ubuntu.com/ideas_being_worked_upon/
<zul> pitti: ping (nagios-plugins) when you are back from lunch
<directhex> okay, qyoto stuff is looking good
<pitti> zul: pong
<pitti> zul: oh, why did you split the source? just changing the dependencies would have been enough?
<amitk> NCommander: still building?
<gouki> Can anyone tell me where is the .xml file used to generate the menu entries in Gnome?
<zul> pitti: keep it like it was in hardy
<zul> pitti: anyways nagios-images should be ok in main as well is just a bunch of icons and images for the web frontend
<persia> gouki, /etc/xdg/menus/
<gouki> persia, thank you very much!
<StevenK> amitk: It looks NCommander ran off
<pitti> zul: yes, that sounds fine
<amitk> StevenK: ouch!
<pitti> zul: I just mean, wouldn't it be easier (and less delta to Debian) to just drop the -plugins depends: -plugins-extra instead of completely splitting the source?
<zul> pitti: yeah it would have, can you reject it Ill upload it again
<pitti> zul: sure
<evand> seb128: Is System Tools an apporpriate menu location for usb-creator?
<davmor2> evand: will it be in the default install or not?
<pitti> zul: nagios-images promoted (trivial, and just a splitout from earlier package)
<evand> davmor2: it will be
<zul> pitti: thanks
<persia> evand, There's been great effort in several previous releases to not put anything at all in system tools.  I'd recommend Accessories.
<davmor2> evand: in that case do you really want another menu option on by default? Might be easier in System -> Administration along with thing like gparted etc...
<persia> davmor2, Good point, as it requires root access.
<evand> ah, will do
<zul> pitti: uploaded
<gouki> persia, any idea of how to find a specific entry? On a .ISO I built Evolution entry keeps getting created, even though the application isn't present on the OS.
<persia> gouki, Check in /usr/share/applications/
<gouki> persia, thank you.
<persia> gouki, I highly recommend reading the desktop item and desktop menu specs at freedesktop.org.  I suspect they will answer your next question :)
<gouki> persia, hehe. I will. Thank you for the help.
<pitti> mvo_: what's the current status of bug 145360? (it's an outstanding TODO item from release meeting)
<ubottu> Launchpad bug 145360 in compiz "compiz.real crashed with SIGSEGV" [Unknown,Confirmed] https://launchpad.net/bugs/145360
<pitti> mvo_, tseliot: with the workaround in compiz for bug 269904, the nvidia task shouldn't be intrepid RC any more, right?
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed] https://launchpad.net/bugs/269904
<ScottK> slangasek: I will be late for the Release meeting today.  I have a kid pickup to do at the meeting start time, so I'll be there ~20 minutes late.
<tseliot> pitti: mvo_ told me that he would have a look at the patch but I don't know if it can be included in the RC
<pitti> tseliot: the compiz workaround mentioned in the bug is uploaded
<tseliot> pitti: ah, nice
<pitti> tseliot: so we can say "yes, it is a bug in nvidia, but we have a workaround, thus it's not RC"; does that sound right?
<tseliot> pitti: AFAIK it's a bug in the xserver
<tseliot> but it seems to affect nvidia users
<tseliot> pitti: would it be a problem to include it in the RC?
<pitti> tseliot: which? the only patch I see is http://launchpadlibrarian.net/18617329/049-damage-report-non-empty.patch, and as I already said, that is already uploaded
<tseliot> pitti: aah, sorry, I've read your first question again and the answer is no, the nvidia task shouldn't be intrepid RC any more
<cjwatson> tseliot: any idea what's happening to Brian Watson in bug 278963?
<ubottu> Launchpad bug 278963 in fglrx-installer "fglrx kernel module crashes system hard during hardy to intrepid upgrade" [Critical,Confirmed] https://launchpad.net/bugs/278963
<tseliot> let me check
<tseliot> cjwatson: it's hard to tell without a Xorg.0.log
<cjwatson> tseliot: could you ask him for one?
<tseliot> sure
<cjwatson> thanks
<tseliot> but maybe the log is lost as we store only Xorg.0.log and Xorg.0.log.old
<tseliot> I can ask him to try the upgrade again and post his Xorg.0.log.old
<tseliot> mvo_: it looks like my workaround worked for liw in in bug 278963
<ubottu> Launchpad bug 278963 in fglrx-installer "fglrx kernel module crashes system hard during hardy to intrepid upgrade" [Critical,Confirmed] https://launchpad.net/bugs/278963
<cjwatson> liw: usb-creator just moved from System Tools to System -> Administration - should system-cleaner do the same? it's going to be orphaned in that menu
<persia> liw, Please do move it: getting rid of System Tools was a Dapper goal (IIRC)
<cjwatson> liw: (see lp:~ubuntu-installer/usb-creator/trunk r42)
<StevenK> NCommander: I'm not sure if amitk has commited yet
<NCommander> amitk, ping?!
<amitk> StevenK: had to re-create diff to remove the git remains
<amitk> about to commit now
<mvo_> tseliot: having a look now
<pitti> Riddell: in bug 280997, woudl using bluez-gnome actually be possible/sensible? it looks quite curious to me
<ubottu> Launchpad bug 280997 in kdebase-workspace "solid-bluetooth needs update for bluez 4.x" [High,Confirmed] https://launchpad.net/bugs/280997
<cjwatson> bryce,tjaalton: any movement on bug 270002? there's a fix in wgrant's PPA
<ubottu> Launchpad bug 270002 in xserver-xorg-input-synaptics "Multi-finger tapping broken" [High,In progress] https://launchpad.net/bugs/270002
<tseliot> mvo_: basically making Update Manager upgrade the linux-restricted-modules (with a hack) before any other package seems like a good workaround
<liw> cjwatson, a) I have more things in the menu, such as virt-manager and something to config x screensavers b) can I just unilaterally edit the .desktop file or do I need permission from some grand master of menus?
<cjwatson> liw: so do I, but I believe nothing else is there in the default install
<cjwatson> liw: might be worth stating your intentions on #ubuntu-desktop and asking for objections
<pitti> mvo_: FYI, testing the patch in bug 278112 now; if it works for me, too, I'll sponsor this
<ubottu> Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112
<Riddell> pitti: no that's not acceptable.  I'm pretty much resigned to not having a working bluetooth at release, maybe we can backport the port to the new bluez when it happens for -updates
<liw> cjwatson, ok, I'll do that; I need to run out now to catch a bus, I'll take care of it before Monda
<pitti> Riddell: ok, what I thought
<Riddell> I'll add that to the bug
<pitti> Riddell: ok, then I have my snippet for the release meeting
<amitk> StevenK: diff.gz pushed to regular place on rookery.
<amitk> NCommander: git tree updated too
<mvo_> pitti: the if strcmp() one?
<NCommander> amitk, d'oh
<mvo_> pitti: I think koon mentioned that there was some negative feedback on it
<NCommander> amitk, there was a part of that patch that should have been dropped
<NCommander> (nothing critical but ...)
<pitti> mvo_: yes, it does strcmp(w->resName,"gnome-screensaver") != 0
<NCommander> amitk, the change to control.d/flavour-stub should be dropped (its a change in the description)
<amitk> NCommander: https://pastebin.canonical.com/10321/ what part?
<pitti> mvo_: oh, was it? it wasn't entirely successful, but no regression reports
<Riddell> pitti: that in 10 minutes?
<NCommander> ^- amitk
<pitti> Riddell: yes
<StevenK> amitk: NCommander can't read that.
<NCommander> (StevenK caught that mistake, there are no problems with the rules themselves, I dunno if you saw, but it builds successfully now ;-))
<mvo_> pitti: I only talked to him briefly about it, I check if he is around
<StevenK> amitk: For obvious reasons
<amitk> aah shit
<StevenK> amitk: http://paste.ubuntu.com/
<pitti> mvo_: is there any update on "the" compiz crasher bug?
<pitti> mvo_: (#145360)
 * NCommander didn't even know there was a canonical pastebin
<Riddell> NCommander: it still turns line endings into windows ones :)
<NCommander> StevenK, did I earn my service award for LPIA this cycle now ;-)
<StevenK> NCommander: Heh
<mvo_> pitti: no, sorry. I talked to upstream about it and it seems to be a memory corruption. the currnt theory is that it happens on shutdown so people see the crash report on the next login
<slangasek> ScottK: ack, thanks for the heads-up
<amitk> NCommander: http://pastebin.ubuntu.com/58840/
<pitti> mvo_: ok, so that isn't so important once we disable apport :)
<Riddell> pitti: you have a line about language packs too?  or is that cjwatson's domain for release meeting?
<pitti> Riddell: I do
<mvo_> pitti: yeah, I *think* so - its funny because everybody says that they get the notification but compiz works fine :)
<cjwatson> wgrant: and re the above, do you believe your xfree86-driver-synaptics PPA change is ready for merging?
<NCommander> amitk, Looks fine. obviously the change in the description was fixed without me being there
<NCommander> amitk, commit when ready ;-)
<pitti> mvo_: screensaver works fine for me, too, with this patch
<StevenK> NCommander: Can you run dpkg -c linux-lpia-headers-2.6.27-4 | wc -l for me?
<StevenK> Sigh
<StevenK> dpkg -c linux-lpia-headers-2.6.27-4_lpia.deb | wc -l
<amitk> StevenK you need to upload it
<StevenK> amitk: I know
<pitti> mvo_: do you actually think the patch is bad?
<StevenK> I need to sign it first
<NCommander> wait
<NCommander> Bah
<NCommander> Hold that thought
<NCommander> The build didn't work right
<NCommander> (the latest one)
<mvo_> pitti: no, probably not - might be not ideal, let me talk to upstream about it
<StevenK> NCommander: Because that command returns 0?
<NCommander> I think so
<pitti> mvo_: right, I won't upload just yet, waiting for your ok
<NCommander> The first test build didn't do that I think
<mvo_> pitti: its a bit hackish, but we had it enabled for some time to workaround a issue with the xserver when it did redirection of windows
<pitti> mvo_: I know it's a hack, but hey, we are in final freeze, a.k.a. "bad hacks" time :)
<mvo_> pitti: :)
<mvo_> pitti: if I don't hear hear anything I upload, I have a new compiz patch for nvdiai and damage problems pending as well
<StevenK> NCommander: The first test build had every -headers being linux-lpia, too
<pitti> mvo_: ok, great
<emgent> hello
<NCommander> StevenK, yes well, you asked if the build successed, you didn't say if it worked ;-)
 * NCommander is figuring out what went wrong
 * StevenK is poking too
<NCommander> linux-lpia-headers didn't get made
<NCommander> and linux-headers is empty
<StevenK> amitk: We have another problem
<StevenK> amitk: Where's the orig tarball?
<NCommander> StevenK, you generate it by hand with a script
<amitk> StevenK: with the 'linux' source
<StevenK> amitk: And why didn't -4.5, -4.6, -4.7 have one?
<amitk> StevenK: i dunno, ogra uploaded it
<amitk> we use the 2.6.27 final tar ball now
<StevenK> I'm not sure if Soyuz will reject it
<StevenK> amitk: Can you upload the .orig to rookery?
<amitk> StevenK: sure. its big
<StevenK> Oh, I know that.
<StevenK> That's the main reason I'm not uploading the dratted thing from my home machine.
<StevenK> Because we would have reached Jaunty DIF, and it would have just finished
<amitk> StevenK: eta about 10 mins
<NCommander> StevenK, it looks like binary-arch-headers does the right thing
<NCommander> Which is a good thing
<NCommander> but its not building the actual headers package itself
<NCommander> which is a bad thing
<NCommander> StevenK, have you done a build recently?
<StevenK> NCommander: Nope
<StevenK> I want the source tarball so I can read the rules file
 * amitk kicks off a build
<neighborlee> does ubuntu use debug mode during development , as in things run slightly slower, or do they say just use the ubuntu crash handler ...
<NCommander> StevenK, grab the git tree, its all theres
<amitk> StevenK: there is no rules in orig tarball
<StevenK> amitk: No, but I need it to unpack it
<persia> neighborlee, The debug symbols are stripped in the builds, and can be used to recover symbols when needed (sometimes with the crash handler, and sometimes manually).
<StevenK> dpkg-source -x doesn't like it if the files listed in Files: don't exist
<persia> StevenK, That's a feature.
<StevenK> amitk: Besides it, I'll need it to upload
<neighborlee> persia, ok thx ;0
<NCommander> Bah
<NCommander> I think I see what went wrong
<NCommander> One of my changes to 3-binary-indep got dropped
<StevenK> I thought so
<NCommander> That prevented the arch all package from building
<amitk> NCommander: dropped by me?
<NCommander> no
<NCommander> My fault
<NCommander> It simply didn't get into the diff I gave you originally
 * NCommander thinks he had an old commit lingering by accident
<amitk> StevenK: I _have_ to leave for a couple of hours now. I'll look for NCommander's fix when I get back.
<StevenK> Argh
 * StevenK goes to bed
<NCommander> amitk, thats ok, this will take a couple of hours to build another round
<amitk> NCommander: if you can get me the patch in the next 15-20 minutes, I can kick off a build on my machine too...
<NCommander> amitk, how long does the build take on your machine
<amitk> StevenK: when did you last sleep?
 * NCommander has to leave in 50-ish minutes for class
<StevenK> Umm
<amitk> NCommander: 1.5 hrs approx
<NCommander> It only took about an hour here ...
 * NCommander hugs his dual cores
<StevenK> amitk: I got up at 10am local
<amitk> NCommander: debuild -b?
<StevenK> Ah ha
<NCommander> just debuild
<StevenK> indep_hdrpkg = linux-headers-$(abi_release) should be indep_hdrpkg = linux-lpia-....
<NCommander> yeah
<NCommander> That's what I just said ;-)
<NCommander> But one of the packages still isn't building
<amitk> NCommander: send me the patch nevertheless. In case you disappear, I'll get the build started
<StevenK> Which?
<NCommander> StevenK, the actual linux-lpia-headers-*api* meta package
 * amitk really goes off now
<NCommander> (the linux-headers package does build, in that case, the files just ended up somewhere other than devscripts expected them to be)
<StevenK> amitk, NCommander: I'm going to crash, I'll resurface at ~ 10am local and upload the kernel
<NCommander> StevenK, make sure there is a fix to upload ;-)
 * NCommander is going to sleep tooish :-/
<StevenK> NCommander: I daresay your patch is a brilliant starting point
<NCommander> StevenK, it would have worked if not for sleep-deperivation ;-)
<StevenK> Heh
<NCommander> StevenK, I'll figure out what went wrong, but its progress. This should be fully fixed by tommorow
<ogra> its all about training
<StevenK> NCommander: Mine, or yours?
<NCommander> StevenK, probably both
<NCommander> ogra, well, I already shot myself in the foot with git by mixing up git reset and git revert
 * ogra stays away from git based software 
<NCommander> ogra, don't you hack on the kernel too?
<ogra> nah
<ogra> i just play upload bitch for it :)
<StevenK> ogra has teeth marks from linux-lpia
<ogra> and probably make config changes on package level
<ogra> StevenK, hey i bult my own one for classmate
<NCommander> StevenK, right now I'm just trying to figure out why not all the meta packages are getting properly built
<ogra> but all changes happened on package level
 * NCommander notes he'll get the silver star of good try vs. execellence
 * NCommander caught another bug
<NCommander> StevenK, we have yet another package collision that was overlooked
 * StevenK sobs like a 2 year old
<NCommander> linux-source collides :-)!
<StevenK> Right
<NCommander> Easy fix
 * StevenK really goes to bed
<NCommander> StevenK, good night
<StevenK> NCommander: Night
<NCommander> oh bugger
 * NCommander found the issue
<NCommander> :-P
<StevenK> NCommander: Oh?
<NCommander> StevenK, binary-arch is loaded before binary-indep
<NCommander> Thus the laters rules aren't called
<StevenK> Err?
<NCommander> StevenK, binary-indep is what generates the metapackages -source/-lpia-headers, etc.
<NCommander> 2-binary-arch.mk is before 3-binary-indep.mk, so the rules don't seem to properly call each other if I make sense of this
<NCommander> actually
<NCommander> ignore me
<NCommander> I'm an idiot :-)
<pitti> tseliot: hm, nvidia-settings is in universe; is that actually free?
<tseliot> pitti: yes, it's gpl
<pitti> tseliot: right now, nvidia-glx-177 Recommends: it, so it would be suitable in restricted
<pitti> tseliot: is the recommends: actually appropriate? do people need it to set up their graphics stuff?
<pitti> oh, just read the package description
<StevenK> NCommander: Did you set the Arch: to lpia for them?
<pitti> tseliot: I'd rather have it as Suggests:, tough
<tseliot> pitti: in a number of cases it can help users with the screen resolution, multiple screens, etc.
<NCommander> StevenK, yes
<StevenK> I don't remember seeing that in the diff
<NCommander> StevenK, it still builds out of the binary-lpia rule however
<NCommander> StevenK, it was already set before I got here
<tseliot> pitti: actually they used to complain about having to install nvidia-settings manually
<StevenK> NCommander: I'll stop second guessing you and go to bed
<NCommander> StevenK, I wish I could do the same
<tseliot> pitti: I don't think it hurts to keep it as a Recommends
<pitti> tseliot: main/restricted can't depend/recommend on universe/multiverse stuff
<sistpoty|work> pitti: it used to live in restricted, was removed from there and I reuploaded it and it was put in universe, but I checked all code bits, and all that's in there is gpl-2 (or mit/bsd license)
<pitti> nvidia-settings | 1.0+20070502-1ubuntu2 | gutsy/restricted | source, amd64, i386, ia64
<pitti> oh, indeed
<pitti> ok, so maybe it's easiest to put it back there
<tseliot> pitti: yes, it's restricted. It's what I was about to suggest
<sistpoty|work> pitti: erm, the static lib is used in universe as a build-dependency
<tseliot> pitti: s/it's restricted/in restricted/
<pitti> eww
<sistpoty|work> pitti: for a gnome applet thingy to display the gpu temperature (but I don't recall the package name right now)
<pitti> having that thing in main doesn't feel right
<pitti> -- intrepid/universe build deps on nvidia-settings:
<pitti> sensors-applet
<pitti> sistpoty|work: ^
<sistpoty|work> pitti: yep, that's it
<RainCT> pitti: what script are you using for that?
<pitti> http://people.ubuntu.com/~pitti/scripts/checkrdepends
<pitti> it's conveniently installed on our archive master
<pitti> but it works from anywhere with a fast network connection
<pitti> (downloads all the packages.gz/sources.gz0
<RainCT> oh ok, then it's nothing for me :P
<RainCT> thx
<maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
<cjwatson> maestrolinux: please don't spam this channel
<tseliot> pitti: if recommends on universe/multiverse are not allowed then let's make nvidia-settings a Suggest. Users won't be pleased though
<persia> Is there a reason nvidia-settings can't be in main?  For a while it was built from sources in restricted, although that changed.
<MacSlow> amitk, ping
<pitti> persia: not technically, mainly political ones, I guess
<persia> pitti, It's not non-free or anything.  Does it break anything?
<pitti> persia: if that thing is actually GPL, it just needs a MIR, I figure
<persia> pitti, Looks GPL/BSD to me (http://changelogs.ubuntu.com/changelogs/pool/universe/n/nvidia-settings/nvidia-settings_177.78-0ubuntu2/copyright)
<persia> tseliot, You seem to have been chasing that source : up for drafting an MIR?
<tseliot> persia: ok, I can do it
<persia> tseliot, Feel free to ping me if you get stuck : I've drafted a couple before, but it's always best to have someone familiar with the source start it (and my contributions to nvidia-settings were about changing Conflicts entries)
<tseliot> persia: ok, thanks
<pitti> oh good, I wish there was a tool to display the 203942304 perl modules on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt as a graph
<pitti> s/good/god/
<gouki> persia, sorry to ping you, but .. I'm getting a launcher created at the top bar, even though I deleted all entries for launchers. Any idea of how I can troubleshoot that?
<persia> gouki, Nope.
<seb128> what is the question exactly?
<gouki> seb128, mine?
<seb128> gouki: did anybody else asked a question? ;-)
<gouki> seb128, I scrolled up a bit, but didn't see it :P
<gouki> seb128, I'm editing the files responsible for creating the menus in Gnome. For some reason, a launcher, right next to the menu bar, is being created. I've look in all the .xml I know and can't find any reason for it to be created.
<seb128> gouki: the layout is a gconf configuration
<gouki> seb128, yes, but I'm building an .ISO, and so I'm editing the files by hand. I removed all entries (three actually) for the launchers, but 1, empty one, stills shows up.
<gouki> By default yelp, evolution and firefox are created. Since none of those are present on the CD, I removed them from the .xml configuration files.
<seb128> what xml?
<gouki> seb128, /etc/xdg/menus/
<seb128> that describes the menu not the bar layout which is gconf configuration as said before
<gouki> I've also looked into /etc/gconf, but didn't find anything there.
<seb128> gouki: /usr/share/gconf/defaults/05_panel-default-setup.entries is the default configuration
<gouki> seb128, hmmm. Interesting. Let me look into that one. Thanks!
<gouki> seb128, indeed. There is an entry for the browser_launcher. Thank you.
<seb128> gouki: the schemas are not used at runtime but registered in the gconf database at installation time so you might need to change the gconf configuration directly
<seb128> gouki: the configuration is in /var/lib/gconf
<gouki> seb128, I will. Thank you very much for the help.
<kirkland> Keybuk: i know you've told me this before, but which of these two are preferred ... "udevsettle" or "udevadm settle" ?
<Keybuk> only one of them exists ;)
<Keybuk> udevadm settle
<kirkland> Keybuk: thx
<pitti> cjwatson: FYI, I'll upload installation-report with the reportbug recommends dropped
<cjwatson> pitti: ok, please commit to bzr too
<pitti> cjwatson: yeah, just checking out
<tseliot> persia: I haven't filed a bug report about the MIR yet but what do you think of this? https://wiki.ubuntu.com/MainInclusionReportNvidiaSettings
<persia> tseliot, In what situatins does the package not work out of the box without configuration: when the "nvidia" driver is not enabled in X.
<tseliot> persia: ah, right
<persia> tseliot, Has it had different names in the past : In Edgy, Feisty, and Gutsy this package was produced by linux-restricted-modules, although previous and current releases have maintained the name.
<persia> s/this package/the nvidia-settings binary package/
<persia> (that didn't actually work, but it's worth mentioning for posterity)
<tseliot> persia: but doesn't the question refer to the binary i.e. to nvidia-settings the binary?
<persia> tseliot, I thought it was source+binary, but your answer is correct for the binary.
<tseliot> from what I remember its name has always been nvidia-settings
<tseliot> persia: ok
<bryce> cjwatson: okay I didn't know about the fix for 270002; I'll follow up with wgrant on getting his patch in.
<radix> Can I get a core-dev to look at Bug #285030? It's a minor change to the "Replaces" line for landscape-common to allow upgrades to intrepid to work (mathiaz? slangasek?)
<ubottu> Launchpad bug 285030 in landscape-client "private-pre-intrepid to intrepid upgrade of landscape-client -> landscape-{common,client} fails with file ownership conflict" [Undecided,New] https://launchpad.net/bugs/285030
<tseliot> persia: as the questions are What do upstream call this software ? Has it had different names in the past ?
<bryce> cjwatson: it may be just some confusion over freeze exception procedures
<mathiaz> radix: I'll have a look at it
<radix> mathiaz: you're a wonderful person :)
<cjwatson> bryce: thnks
<cjwatson> +a
<persia> tseliot, Ah, yeah, upstream never called it anything else, it was just us breaking it for a few releases because we didn't want to maintain it.
<tseliot> persia: ah, ok. I'll file a bug report now and add a reference to it to the wiki
<persia> tseliot, "Main Inclusion report for sourcepackage" should probably be "Main Inclusion Report for nvidia-settings" :)
<tseliot> persia: yes, right ;)
<persia> And the MIR bug number is wrong, but everything else looks good.  Thanks for writing that up.
<radix> mathiaz: fwiw, we have stopped the release of non-split landscape-client packages in our own repos, and our next release will have the split packages, so this shouldn't happen again
<tseliot> persia, pitti: the MIR is here: https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/285067
<ubottu> Launchpad bug 285067 in nvidia-settings "MIR for nvidia-settings" [Undecided,New]
<radix> mathiaz: ah, and as usual I forgot to include the "(LP: #foo)"... I'll update the branch
<mathiaz> radix: ok. I haven't looked at the bug yet.
<radix> cool :)
<pitti> lool: elisa-plugins-bad still recommends gst-plugins-ugly0.10
<pitti> lool: I think we need to drop that to Suggests:, too
<pitti> lool: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt just got updated
<lool> That's going to be bad, but I'll test as well
<lool> and given that I'm not at home and the release meeting isn't over yet, I don't see myself testing tinight
<lool> *tonight
<persia> pitti, What wants JACK?
<pitti> [Reverse-Build-Depends: libvisual-plugins]
<pitti> another thing that elisa pulls in
<persia> OK.  Part of elisa then.  Thanks.
 * persia wants jack-in-main, but for jaunty, not intrepid, and was confused
<amitk> MacSlow: pong
<MacSlow> amitk, hi there
<pitti> Riddell: kttsd currently Recommends: festival | flite | epos
<MacSlow> amitk, did you already have a change to test the updated libgksu package for interpid to see if you still encounter the crash?
<pitti> Riddell: of those, festival is in universe (and IIRC TheMuso wanted to keep it that way, flite could be moved to main, and epos is in universe
<MacSlow> amitk, s/change/chance
<pitti> Riddell: any idea about that, or anyone I could ask about a11y in KDE?
<amitk> MacSlow: no, haven't upgrade since afternoon. Hold on.
<Riddell> pitti: probably easiest to move kttsd to universe
<Riddell> pitti: would need kdeaccessilibity meta package changed
<pitti> Riddell: right now it seems to get installed by default without any backend
<pitti> so we could either add a backend (easy: flite), or drop kttsd, right
<pitti> Riddell: either solution involves a kdeaccessibility upload, yes
<Riddell> yep
<pitti> I just don't know what the better solution is
<amitk> MacSlow: there is not libgksu available on a dist-upgrade
<amitk> *no
<MacSlow> amitk, hm ... still taking it's time
<MacSlow> amitk, are you comfortable with creating you own packge from a set of .dsc/.diff.gz ? If so you could give my patched version a try.
<MacSlow> amitk, you would have to create a .deb yourself.
<amitk> MacSlow: I could. I'm just a bit busy with guests :) So I'll just wait another couple of hours.
<lool> MacSlow: Push to your ppa perhaps?
 * lool keeps amitk all for himself
<MacSlow> lool, yeah I could do that
<MacSlow> lool, initially I just pointed mvo to my patch (.diff.gz, .dsc, .changes) and he sponsored it... that's why I initally thought doing a PPA for that is not needed
<MacSlow> amitk, lool: let's see
<pitti> Riddell: hm, so shall I drop kttsd to universe or promote flite?
<Riddell> pitti: drop kttsd, I've no idea what sort of a working state it's in
<pitti> Riddell: alright
<jdstrand> pitti: hi!
<jdstrand> pitti: can you de-NEW bind9 for hardy-proposed?
<jdstrand> (bug #257682)
<ubottu> Launchpad bug 257682 in bind9 "dig compiled without -DDIG_SIGCHASE!" [Undecided,Fix committed] https://launchpad.net/bugs/257682
<MacSlow> amitk, just uploading it to my PPA ... let's see which is faster ... offical repo or my PPA :)
<MacSlow> amitk, btw... while I never saw a crash for libgksu with my inital version, I found tiny rendering artefacts that I only recognized today ... after mvo pointed me to the bug LP #275172
<ubottu> Launchpad bug 275172 in gksu "libgksuui crashes on statup in the blur code on some systems" [Medium,In progress] https://launchpad.net/bugs/275172
<pitti> jdstrand: done
<jdstrand> \o/
<jdstrand> pitti: thanks! :)
<MacSlow> amitk, hm... the upload hangs
<pitti> zul, dendrobates: bacula-sd currently recommends: mt-st (*blowing the dust off*, a tape control thingy); do we really want that in main (MIR needed), or the recommends dropped?
<MacSlow> lool, is some ppa-server down?
<zul> pitti: yes its necessary, ill write the MIR for it
<sbeattie> slangasek: is bug 269539 likely to go away now that last-good-kernel has been postponed.
<ubottu> Launchpad bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539
<MacSlow> amitk, uploaded to PPA ... compiling now
<MacSlow> amitk, https://edge.launchpad.net/~macslow/+archive
<pitti> sbeattie: hm, isn't that from update-grub when a new kernel ABI hits?
<pitti> i. e. not really related to last-known-good-boot
<sbeattie> pitti: looking at http://launchpadlibrarian.net/17780561/menu.lst.ucf-new is what makes me suspect last-known-good-boot, but that's with little knowledge of what's happening.
<pitti> sbeattie: ah, ok
<pitti> sbeattie: sorry, I just read the bug title
<sbeattie> pitti: well, I'm not sure either, that's why I'm asking. :-)
<pitti> I got a similar situation when I edited the autogenerated stanzas without editing the defaults
<pitti> but I got a proper ucf dialog
<lool> MacSlow: dunno
<tedg> Can someone please sponsor bug 278810 ?
<ubottu> Launchpad bug 278810 in fast-user-switch-applet "Doesn't always display suspend / hibernate options (race between g-p-m and f-u-s-a?)" [Medium,Fix committed] https://launchpad.net/bugs/278810
<bdmurray> tkamppeter: Have you seen bug 255583?
<ubottu> Bug 255583 on http://launchpad.net/bugs/255583 is private
<ScottK> pitti: If an apport crash is consistently put against the wrong package, is that an Apport problem or a Launchpad problem?
<pitti> ScottK: it's not at all a LP bug; it is an apport bug, but in some cases it's not practically fixable without concrete manually maintained lists
<pitti> ScottK: do you have an example?
<ScottK> pitti: Bug 281918 and the bazillion dupes.
<ubottu> Launchpad bug 281918 in guidance-power-manager "guidance-power-manager crashed with Exception in _initHAL()" [Medium,In progress] https://launchpad.net/bugs/281918
<ScottK> pitti: I've seen it on other guidance-power-manager bugs too.
<pitti> ScottK: where was it originally assigned to?
<pitti> oh, python2.5
<ScottK> pitti: python2.5
<pitti> ScottK: that's indeed a bug which should be fixable; it works correclty for a lot of other python packages; can you please file an apport bug about it?
<ScottK> Sure
<pitti> ExecutablePath: /usr/bin/python2.5
<pitti> Right
<pitti> that should usually be /usr/bin/guidance-power-manager
<pitti> i. e. the python script
<pitti> I'm off for today, have a good weekend everyone!
<ScottK> pitti: Have a good weekend.  Bug #285106 filed.
<ubottu> Launchpad bug 285106 in apport "apport mistakenly attributes guidance-power-manager crashes to python2.5" [Medium,Confirmed] https://launchpad.net/bugs/285106
<didrocks> slangasek: around?
<calc> what package does the workspace switcher belong to?
 * calc is trying to determine which package to reassign this bug to
 * calc guesses at gnome-panel
<james_w> calc: depends what the bug is, might be libwnck, but I think you are right to assign it there, it can be moved if necessary.
<tkamppeter> bdmurray, Bug 255583 is already fixed in Intrepid.
<ubottu> Launchpad bug 255583 in hplip "systray.py crashed with ImportError in <module>()" [Undecided,Fix released] https://launchpad.net/bugs/255583
<slangasek> sbeattie: 269539 - I really have no idea, because I have yet to see a menu.lst.ucf-new that tells me what the source of the conflicts are
<slangasek> oh, but apparently there's one available now
<slangasek> didrocks: hi
 * ogra wonders why http://paste.ubuntu.com/58928/ can result in http://paste.ubuntu.com/58930/ if compiled and run
<ogra> sems my system cant compile gtk binaries anymore
<slangasek> sbeattie: ok, that particular conflict is a non-issue because last-good-boot is disabled now, yes
 * ogra is irritated
<slangasek> I'll have to keep an eye on that for jaunty when l-g-b is revisited
<didrocks> slangasek: hi :) does pitti spoke with you about bug #212098
<ubottu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098
<didrocks> ?
<slangasek> didrocks: we discussed it in the release meeting today, yes
<didrocks> slangasek: ok, apparently, pitty told me that what we planned initially will not work
<didrocks> that is to say get the group from the current session
<slangasek> sbeattie: which of the dupes was that menu.lst.ucf-new hiding in, btw?
<didrocks> and then compare it to getpwent
<slangasek> didrocks: the issue is not the group.  there were two reasons why the user needed to logout and log back in
<didrocks> pitti spoke to me about some pass hash ?
<slangasek> er - trying to compare groups by hand is definitely not going to work, no
<didrocks> (the idea was just to warn user if getpwent tell that the user is in the right group, but that the session has not been reloaded)
<slangasek> that part has been resolved by adding sambashare to the list of groups created by the installer
<slangasek> the other part is that libpam-smbpasswd has to be installed, and then the user has to authenticate, before that user can be used for authentication to shares
<didrocks> yes, and all users with admin "profile" in "user and group" are in the sambashare group
<tseliot> pitti: thanks ;)
<slangasek> if you're only doing anonymous shares, then that doesn't matter
<slangasek> sorry, libpam-smbpass
<slangasek> but if you're doing authentication, then each user needs to authenticate to the local system in order for libpam-smbpass to pick up the password and create the NTLM password hash
<didrocks> is libpam-smbpass installed on enabling sharing?
<slangasek> yes
<didrocks> ok, so, this is harder to detect. Is there any API or I have to parse some conf files?
<mvo_> amitk: did you had a chance to test the new libgksu?
<slangasek> didrocks: what are you trying to detect?
<didrocks> slangasek: that libpam-smbpass didn't create a NTLM password hash for the current user
<tseliot> cody-somerville: can you have a look at my FFE for Hardy, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
<ubottu> Launchpad bug 261816 in linux-restricted-modules-envy-2.6.24 "nvidia: Multiple versions in DKMS" [Medium,In progress]
<slangasek> didrocks: libpam-smbpass *doesn't* create an NTLM password hash for the user *until the next time that user logs in*
<slangasek> didrocks: this is why we wanted a notice telling the user to log out and log back in :)
<didrocks> slangasek: yes, and that's a way to detect that we have to tell to a user that he has to log out and back in :)
<slangasek> didrocks: the first iteration should always tell the user to log out and log back in
<slangasek> didrocks: or to do this any time the libpam-smbpass package was not previously installed
<didrocks> slangasek: but for "normal" user (not admin one)
<slangasek> hmm?
<didrocks> slangasek: see last case on https://bugs.edge.launchpad.net/ubuntu/+source/nautilus-share/+bug/212098/comments/57
<ubottu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed]
<didrocks> we still have the group issue there without noticing
<slangasek> under what circumstances is a non-admin user installing packages?
<slangasek> oh, you're talking about a user being given sambashare privs by the admin
<didrocks> no, that's not what I described in my use-case
<didrocks> yes
<didrocks> and the admin ssh to the host
<didrocks> or use "switch user", without unlogging the current one
<slangasek> then the user has to log out and log in again
<slangasek> and we have no communications channel by which to tell them this
<didrocks> yes, but he has no warning about that
<slangasek> so the admin has to tell the user
<slangasek> that's far out of scope for what we're trying to get fixed...
<didrocks> and what about getwgrent to detect this case?
<didrocks> getpwent, sorry
<slangasek> what component is going to do the detection?
<ion_> pitti: May i suggest renaming âGuest sessionâ as âNew guest sessionâ to avoid confusion with the âGuestâ item which shows up when there is a guest session running?
<ion_> pitti: Alternatively, fusa could hide âGuest sessionâ in that case.
<slangasek> didrocks: is nautilus-share supposed to do this when the user clicks on 'sharing options'?
<didrocks> slangasek: that's what I was thinking, but I might be totally wrong :)
<slangasek> didrocks: so if the current process doesn't have the group permissions, but getgrnam("sambashare") lists the user, pop a warning telling them to logout/login
<didrocks> exactly
<didrocks> and we fix both issues
<slangasek> didrocks: I think that makes sense.  But I also think it's out of scope for what we should be trying to fix for intrepid
<slangasek> which "both"?
<slangasek> it doesn't fix the NTLM hash issue
<didrocks> yes, but it will force them to unlog too
 * ogra cries ... my system cant build working gtk binaries anymore ... no seb128 either :(
<slangasek> that issue needs to be fixed with an *unconditional* message after installing libpam-smbpass, *regardless* of the group membership
<slangasek> ogra: debsums -s?
<ogra> slangasek, debsums ?
<ogra> its a plain .c file
<ogra> slangasek, http://paste.ubuntu.com/58928/
<slangasek> ogra: I mean you should check the integrity of your sysetm
<slangasek> system
<didrocks> slangasek: yes, I agree, but do we want to add this additional detection too? It's a workaround, yes, but waiting for a better solutionâ¦
<ogra> oh
<slangasek> didrocks: I would, on the first iteration for intrepid, not mess around with trying to detect group memberships
<slangasek> didrocks: an unconditional message, after installation of libpam-smbpass, addresses the immediate problem, and we can refine it from there
<didrocks> slangasek: ok, I will build my first proposal on that :)
<didrocks> thanks for having clarified that :)
<slangasek> didrocks: ok, thanks :)
<slangasek> didrocks: when do you think you might have a chance to work on this?  We're obviously well into freeze territory already
<didrocks> slangasek: yes, I think it would be possible to do this for Monday/Tuesday (will try to handle it this week-end), will be it ok?
<slangasek> didrocks: Monday would be best
<didrocks> slangasek: ok, will do my best, so :)
<slangasek> didrocks: ok, thanks. :)
<didrocks> slangasek: you're welcome!
<ogra> slangasek, that prouces some output, but nothing strikes me as related to gtk ... the segfaulting started out of the blue
<ogra> *produces
<ogra> i first thought i had a typo in my code
<ogra> which made me write that little test code to notice it segfaults as well
<slangasek> hmm, it produces output other than "no md5sums for <package>"?
<slangasek> ogra: ok, I just tested your code, it segfaults here too :)
<ogra> wow
<slangasek> but nothing else does
<ogra> weird
<slangasek> ogra: google: gtk "hello world" says you're missing a gtk_init()
<ogra> eek
<ogra> oh man ... i should probably stop for the day instead of wasting other peoples time with my sillyness
<kiffi1> I have a question about Ubuntu 8.10 beta...
<ScottK> kiffi1: #ubuntu+1 is almost certainly the place to ask it.
<kiffi1> If I install it can I easily upgrade to 8.10 via package manager or do I have to reinstall everything again?
<ScottK> Upgrading should be fine.  If you have to reinstall we messed up bad.
<kiffi1> Had a heck of a time getting my atheros wifi card to work properly so this should be okay right?
<kiffi1> Alright then, here I go. Keep those old fingers crossed...
<kiffi1> I have a dual boot Windows Vista (1st partition) and Ubuntu 8.10 (2nd partition), can I use gparted to remove the 1st and move/resize the original Ubuntu partition to take up the whole disk?
 * ogra would like to know why evo forgets his pop passwd after every reboot 
<directhex> it forgets your password on every failed connection
<directhex> on the assumption that it must've been a password-based fail
<ogra> hmm, it didnt do that in hardy
<ogra> i cant even remember when i had to type it in the last time
<ogra> probably early gutsy or so
<slangasek> kirkland: did you get a security review of the mount counter?
<maco> ogra: i think it does do that in hardy.  i just unlocked my screen after it being off overnight, and it was prompting for my IMAP password
<ogra> maco, well, i'm sure it didnt do that for me
<ogra> and it does it on every reboot in intrepid since about a week (it didnt do it either in intrepid until recently)
<maco> ogra: i dont think it did that a few months ago, but i'm not sure
<maco> er, not the computer being off, the screen being locked overnight.
<Laney> TheMuso_, crimsun: Commented on the pulseaudio race bug. Latest fix seems to nail it for me, good work
<LimCore> hi
<LimCore> how to have my event.sh evecuted when ever the power button is pressed?
<maco> now that acpi-support's going away
<maco> (adding to the end of LimCore's question)
<wgrant> cjwatson: It's not entirely, but somebody upstream decided to merge it anyway... I've got a new version pretty much ready, but I'm talking to upstream. And what is "the above"? I can't see any relevant conversation earlier.
<LimCore> is there nttp NEWS access to ubutnu devels ML ?
<persia> LimCore, There's some mirrors, but nothing official.
<slangasek> TheMuso_: is bug #273507 something we should fix for intrepid?
<ubottu> Launchpad bug 273507 in libcanberra "No sound effects play when "play sound effects when buttons are clicked" is enabled" [Undecided,Confirmed] https://launchpad.net/bugs/273507
<cjwatson> wgrant: I mentioned your name about a page above that (on my screen anyway) when asking bryce/timo if they were aware of your patch; but doesn't matter, you got the idea anyway
<wgrant> cjwatson: Ah, right, lastlog sees it.
<bryce> yeah we were just chatting about that
<wgrant> The tapping fix is fine to go in.
<wgrant> The syndaemon one isn't small, but it reduces the overall patch size and simplifies it significantly, and it's less braindead and thus less likely to crash in the signal handler.
<wgrant> (and syndaemon isn't used by many, and most existing users run it in the old SHMConfig mode, which this change doesn't touch)
<maco> wgrant: i mentioned your patch in a security talk at Ohio Linux Fest because SHMConfig isn't exactly nice for security
<wgrant> We've very nearly got rid of the need for it.
<wgrant> bryce: New debdiff on bug #270002. I've also attached the more useful final patch to syndaemon, as the diff between the two patches is horrific.
<ubottu> Launchpad bug 270002 in xserver-xorg-input-synaptics "Multi-finger tapping broken" [High,In progress] https://launchpad.net/bugs/270002
<bryce> wgrant: hmm, that's a more involved patch than I'd hoped
<wgrant> It is, yes.
<wgrant> But with the old one, you're likely to be without a touchpad until you reboot if the signal handler doesn't work properly. And my old signal handler was awful.
<emgent> heya
<bryce> wgrant: how much testing has been done on this so far?
<wgrant> bryce: I've been using it for a couple of days in both configs, and I had two forums users test a version that was only slightly different.
<bryce> wgrant, the 106_fix_twofinger_disentanglement.patch patch that closes #270002 I'm totally comfortable with, it's the other patch I'm less certain about
<wgrant> Same.
<wgrant> 106 is clearly fine.
<bryce> as well, the other patch is fixing a non-release-critical bug
<bryce> so I'm wondering, would it be okay if we isolated this to just the fix for the release critical bug for now?
<wgrant> If you feel that way, of course.
<wgrant> I realise it's likely far too late for the 104 changes, but it's a nasty problem and it was worth a try.
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:30 UTC until 23:00 UTC for a code update | 8.10 beta released | archive: Release Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingW
<bryce> wgrant: ok, I've uploaded that fix
<bryce> wgrant: the syndaemon fix may still be doable, but I'd like to see it get some additional independent testing first
<maco> bryce: if im running intrepid in a vm, can i test it?
<wgrant> bryce: Sure.
<wgrant> bryce: Thanks.
<maco> or is actual hardware required?
<wgrant> You'd need a touchpad, and VMs don't have touchpads.
<bryce> maco: yeah hw required
 * maco looks at unused laptop
<bryce> wgrant, I figure separating these out will make future regression testing simpler too, in case there's problems
<crimsun> maco: get daily-live, get deb, install deb, restart gdm
<maco> crimsun: you're smart
<maco> ooo so this is why i bought more blank cds a few weeks ago
<crimsun> no, I'm crimsun.
<wgrant> bryce: True, true.
<maco> wgrant: do you have 32 and 64bit debs available in your ppa?
<wgrant> maco: They should both be there, yes.
<wgrant> And lpia, if you're that way inclined.
<maco> ok
<wgrant> maco: Make sure you get ~wgrant2 and not ~wgrant1.
<maco> hey, there's no daily live
<maco> just alternate
<persia> maco, Which arch?
<maco> there's no daily live for x86 or amd64
<persia> I have an i386 daily live from the 17th.
<maco> http://cdimage.ubuntu.com/daily/20081017/ <-- not there
<wgrant> maco: For testing syndaemon, try to use it as normal both with and without -S. Also kill it in various ways (just not SIGKILL) and make sure you're not left with your touchpad not working.
<persia> http://cdimage.ubuntu.com/daily-live/current/ has some links to the latest ones.  New ones come out in three or four hours.
<maco> ah ok thanks
<bryce> slangasek, pitti: fix for 270002 has been uploaded; please review/approve
<slangasek> ack
<persia> maco, daily is the alternate CD.  daily-live is the live CD.  That said, I wonder why Ubuntu Desktop didn't get generated for i386/amd64, as I did get a daily alternate for Ubuntu Desktop lpia and Ubuntu Studio i386.
<maco> persia: yeah, i got the url wrong
<maco> it exists
<persia> Oh.  You typed it wrong in the browser and perfectly in IRC?  I see.  Sorry for the confusion.
<bryce> cjwatson: ok debs built for testing for 264462, for all combinations of patches.  I'm cool to upload whatever combo solves the problem.
<bryce> cjwatson: it sounds like the OEM folks are going to need some of my time this evening and this weekend, so I'm going to nip out to get a haircut right now, and will be back in an hour or so.
<cody-somerville> doh
<cody-somerville> I wanted to get a haircut today
<cody-somerville> I totally forgot
 * jdong got a haircut today :)
 * maco doesn't get haircuts
<calc> damn it why is launchpad always going down
<calc> that is twice in the past what two days now
 * calc thinks launchpad needs some sort of backup so they don't have to take the whole thing down every week or so
<wgrant> They must have found some regression in 2.1.10.
<mthaddon> calc, it's a follow up to yesterday's rollout
<slangasek> launchpad is always going down because Canonical pays a team of programmers to make changes to it. :)
<calc> mthaddon: ok
<calc> slangasek: yes but usually for important sites there is some sort of redundancy
<calc> they do it late at night european time which is almost always while i am still working here in the US :\
 * calc hopes it is another short 20min outage like yesterday
<mthaddon> will see what I can do (expect it to be a short one)
<calc> mthaddon: ok
<calc> i guess the big deal is that there is only one database server on the backend so whenever they do make changes it takes the whole thing down?
<calc> i guess i can use this time to do the complete reinstall of my laptop that i wanted to try out
<slangasek> calc: er, considering how often the roll-outs include database schema changes, db server redundancy doesn't help
<calc> slangasek: maybe those should be stacked together to only do database changes every (large time gap) apart
 * wgrant notes that read-only-launchpad is nearly implemented, and should mean that Launchpad will be up, though read-only, during rollouts.
<calc> wgrant: ok that would help quite a bit
<wgrant> calc: It done monthly now...
<wgrant> s/It/It's/
<calc> wgrant: ah it seemed more often than that, but maybe i just have bad timing of when i work on a lot of bug reports, heh :)
<calc> i think part of it may be the multiday rollouts though, i remember one time lp was down for a long time (6hr+ iirc)
<calc> then out again the next day for a while, but i might be wrong about that
<wgrant> The last time it was down for ages for a rollout was for the Rosetta schema changes.
<wgrant> That was particularly bad because somebody stuffed up the time calculation, and they had to abort the 8-hour upgrade before it was finished, and schedule an even more ridiculous window for some other day.
<calc> wgrant: would there be some way with read-only lp to queue up changes while it is running in that mode to not commit them to the database until later?
<calc> iirc there is some way to make changes via email as well, which basically would be queued anyway, right?
<wgrant> calc: That's probably a lot more work than it'd be worth...
<cjwatson> maco: doesn't get haircuts> that's the one true way to do it
<calc> wgrant: ah yea i think that is the outage i am remembering, heh
 * wgrant hasn't had a haircut for a little while.
<slangasek> "Launchpad will be going offline for maintenance very very soon." heh
<wgrant> I wonder how much of the downtime window is actually upgrading things, and how much is stopping and starting it all.
<maco> cjwatson: well, ok, its a lie. i get a haircut when, once a year, my mom gets sick of my split ends and makes me get a hair cut.  but id rather it just get longer
<calc> hmm that reminds me i need to get a haircut
 * calc looks a bit shaggy for his wife's school reunion tomorrow
<cjwatson> you know, just after reading news about an LP code update, I should know not to try to 'bzr up'
<wgrant> Does maintenance really could as scheduled if we're told an hour beforehand?
<wgrant> GAH
<wgrant> s/could/count/
<brendan_> is OpenOffice.org 3, going to make it into ibex?
<RainCT> brendan_: Not for the CD. Into -updates/-backports, I don't know.
<brendan_> dam (am using ibex, now and would like to try it)
<RainCT> brendan_: there's a PPA
<slangasek> not into -updates, switching OOo major versions is not an appropriate SRU
<RainCT> brendan_: https://launchpad.net/~openoffice-maints/+archive or something like that (I've just closed my web browser so I don't know the exact url)
<slangasek> but there's a PPA and it might find its way into -backports, yes
<brendan_> cool
<calc> brendan_: ~openoffice-pkgs/  of course lp is down now
<brendan_> might just install it from the main OOo website
<calc> brendan_: well if you want less bugs the one on the ppa should be better
<calc> brendan_: or you could get the one from go-oo.org which is roughly equivalent
<brendan_> calc, ok
<brendan_> thanks all
<calc> brendan_: ubuntu's uses ooo-build which is what go-oo.org uses and has 500+ patches that aren't in upstream
<brendan_> oh, ok
* mthaddon changed the topic of #ubuntu-devel to: 8.10 beta released | archive: Release Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<calc> hmm lp is still working
<wgrant> calc: It's back.
#ubuntu-devel 2008-10-18
<calc> wgrant: that was fast :)
<wgrant> calc: That's one of the fastest rollouts I've seen them do. Pleasantly surprising.
<calc> wgrant: yea :) short outages are fine with me :)
<calc> i'm just scared of those 8hr+ outages ;-)
<wgrant> I remember back when they used to take it down for >2 hours every Tuesday night. That was annoying.
<calc> yea
<beuno> 12 minutes total downtime
<beuno> we're getting better!
<wgrant> beuno: But I guess you can't be so quick during normal rollouts :(
<beuno> wgrant, probably not, but quick-er
<beuno> and just wait until read-only launchpad lands...
<wgrant> That has been coming for a long time... but it does seem to have a hard target now...
<beuno> well, you know, good things come to those who wait...
<beuno> if you don't, onlt bad things (>)
<bryce> I has haircut
 * wgrant blames developers' haircuts for RC being buggy.
<persia> wgrant, You think it's better to fix bugs than cut hair?
<wgrant> persia: You obviously haven't seen my hair.
<persia> No :)
<persia> Although, personally, every five or six months, my hair starts getting in the way of my doing useful things like seeing or typing, and I find a haircut assists in bug closure.
<bryce> persia: indeed
<wgrant> There are workarounds for that which don't involve cutting it, fortunately.
<bryce> timing haircuts to coincide with lp downtimes == priceless
<persia> bryce, Admit it: it was luck.
<bryce> yeah pretty much
<persia> wgrant, Depends on your hair.  Mine tends to break.
<ogra> pfft heairs
<ogra> *hairs
<wgrant> Mine has survived quite well for a number of years.
<ogra> mine too ... but i find beards more significantly showing that state of my workload :)
<ogra> *the
<ion_> pitti: Heh, thereâs already a bug report about it. Iâll see whether iâll get around to creating a patch for the issue.
 * StevenK appears
<persia> StevenK, There's no kernel, and been no word for ~8 hours.  Apparently it was evening in Europe.
<persia> Oh, and Good morning :)
<StevenK> Hmm
<munckfish> cjwatson: you there?
<cjwatson> munckfish: if you don't mind a zombie
<munckfish> well I am one myself :)
<munckfish> :S
<munckfish> cjwatson: could we add a "recovery" option to the kboot-installer package?
<munckfish> I needed that today
<cjwatson> not now, maybe for jaunty
<munckfish> ok
<cjwatson> can't add features 12 days before release :)
<munckfish> yeah true, it's a feature
<munckfish> sorry
<cjwatson> so you mean like a rescue CD type thing?
<munckfish> umm like we have in grub
<cjwatson> "rewrite my kboot.cnf"
<munckfish> two items for each kernel
<cjwatson> oh, you mean a separate boot menu entry
<munckfish> second one boots kernel with "single" as it's arg
<cjwatson> yeah, sure, that would make sense for jaunty
<munckfish> which boots into that recovery menu which allows you to get root shell or fix X etc
<munckfish> cool
<munckfish> Oh I nearly cried today
<munckfish> I never expected to see such bad bad problems so late
<cjwatson> can't you edit the menu in kboot to some degree?
<cjwatson> or boot manually or something
<munckfish> especially as Intrepid  was running so nice just last week :(
<munckfish> cjwatson: oh yeah I can edit it
<cjwatson> I agree the framebuffer thing is bad, you'll have to delve into initramfs to figure that one out
<munckfish> It just occurred to me it'd be useful for "users"
<cjwatson> hopefully my kboot-installer change will fix the label thing, I'm pretty confident
<cjwatson> it's definitely a correct fix
<munckfish> ah cool
<munckfish> roughly what did you change? Or where can I see the patch?
<cjwatson> munckfish: http://paste.ubuntu.com/59077/
<munckfish> cjwatson: do you ever sleep?
<cjwatson> was a global change across partman, we just missed kboot-installer :-(
<cjwatson> munckfish: not nearly so much as I'd like
<munckfish> aha that defo looks like the thing
<munckfish> you in BST/GMT?
<cjwatson> BST, yes
<munckfish> me too
<cjwatson> ... and I have to be up in reasonable time tomorrow so I think that has to be a wrap :)
<munckfish> yeah I need to quite now too
<munckfish> thx for your help so late
<cjwatson> no problem
<munckfish> c ya!
<wgrant> Oh ffs.
<wgrant> Is there somebody around with an amd64 xserver with a Synaptics touchpad?
<wgrant> Something continues to be borked in the X stack.
<bryce> wgrant: sadly my amd64 box is a desktop
<wgrant> bryce: Are you able to run xinput list-props on one of your real mice?
<wgrant> Somebody is complaining that my new syndaemon version doesn't work properly, but xinput is segfaulting, so I think we can blame it elsewhere...
<wgrant> Oh.
<slangasek> wgrant: amd64 w/ synaptics here, yes
<wgrant> I can reproduce it with an i386 server... but only on the synaptics device.
<wgrant> What the....
<wgrant> The other devices work fine.
<wgrant> So amd64 clients don't like synaptics properties for some reason.
<wgrant> Regardless of server arch.
<wgrant> amd64 needs to die. Or X.
<bryce> slangasek: btw, fix for targeted bug 275285 is tested and uploaded
<ubottu> Launchpad bug 275285 in xserver-xorg-video-intel "[intrepid] Flash, VirtualBox, Dosbox etc. video freezes after few seconds" [High,Fix released] https://launchpad.net/bugs/275285
<wgrant> So XGetDeviceProperty now works fine.
<bryce> slangasek: wait a sec
<wgrant> But XListDeviceProperties segfaults for -synaptics. How stupid.
<bryce> slangasek: ok 275285 ready for approval
<RAOF> wgrant: Uuuh, yeah!  What the hell happened there?  xinput list-props "Syn..." _worked_ for one blessed day, and now segfaults?
<slangasek> bryce: well, hasn't reached the queue yet :)
<wgrant> RAOF: I'm stepping through upgrades to work out what broke it.
 * RAOF 's internet is currently capped at a princely 64kbit/sec, so is not the ideal candidate for that. :(
 * bryce turns attention to 261977
<wgrant> RAOF: I've only been capped once this year, but back two years ago when we were on the 1GB plan we were frequently capped to 28.8kbps for half a month...
<LimCore> hi devels \o/
<RAOF> wgrant: I forgot how utterly dependent on a fast connection Intrepid testing is.
<wgrant> RAOF: Yes...
<wgrant> Though it's not so bad now we're frozen.
<RAOF> At the current rate, it'll be _tomorrow_ before I finish downloading yesterday's updates.
 * RAOF thanks OOo and Java for that.
<wgrant> Why won't X just stay unbroken?
<LimCore> so, I would like to fix the braindeadness in logout funcionality ( https://bugs.launchpad.net/ubuntu/+bug/285141 ) but there are rumors of APIC changes... So, what is now the proper way to have script power.sh executed when ever someone presses power button (the one on PC, not on keyboard)
<ubottu> Launchpad bug 285141 in ubuntu "logout box + no way to kill computer = data corruption" [Wishlist,Confirmed]
<bryce> wgrant: what fun would that be??
<bryce> LimCore: the acpi stuff is sort of in a state of flux
<bryce> LimCore: acpi-support is still used for some things, but other stuff is moving towards hal, and pm-utils
<wgrant> bryce: True...
<wgrant> But I think this might be a clientside change.
<wgrant> Hmm.
<LimCore> bryce: but I hope, that no matter what system uses, in the end system WILL provide a way to execute user script on common ACPI event like power-off button, right?!
<wgrant> Er, serverside.
<bryce> LimCore: I haven't had a chance to go through pm-utils and learn the new world order for acpi, so sorry I don't know
<LimCore> there should be some  powerdown.d/ directory or something.  And there my patch would go, to fix above bug (to do, so that pressing power button repeataly will turn off pc)
<LimCore> *turn off the system
<bryce> LimCore: I'd encourage you to review the pm-utils source
<LimCore> bryce: I dont have now time for that, unfortunatelly, yet I like to fix the problem.  If I do it using current acpi-support, then can I ask someone to port it to the new way, pack it, and include in 8.10?  current way of logout is realllly brain dead
<persia> Looks loosely like they belong under /etc/pm/ somewhere, although one wants to check the implementation before blindly stuffing something there.
<Hobbsee> LimCore: is that release critical?
<Hobbsee> if not, it won't get done.
<LimCore> Hobbsee: yes
<LimCore> bad design of logout funcionality leads to fs corruption.  seems horrible to me
<Hobbsee> LimCore: provide patches then.
<LimCore> I almost lost my fs today, thanks to that
<LimCore> Hobbsee: thats what I want to do, and therefore my question.
<bryce> LimCore: for intrepid, if you can make it work in acpi-support, porting it to pm-utils should not be necessary
<LimCore> bryce: cool, thanks
<LimCore> can I implement this in C++?
<LimCore> or in C or even bash, this utility must go to base system imho
<bryce> LimCore: bash would probably be the only thing likely to get accepted
<LimCore> ok
<persia> Well, actually, POSIX shell would be preferred to bash, generally.
<LimCore> like, /bin/sh ?
<bryce> right
<persia> /bin/sh means different things for different people, but yes :)  Test with dash.
<bryce> acpi-support is currently a mix of bash and sh.  I did convert some simpler stuff to sh
<james_w> um, have you tried on an up-to-date Intrepid Ubuntu (GNOME)?
<persia> james_w, tried which?
<james_w> doesn't pressing the power button show a menu to shutdown, with a 60 second timeout that shuts down the machine?
 * Hobbsee notes kde used to support that, too.
<Hobbsee> (as in, automatic shutdown when power button is pressed)
<persia> james_w, Does for me.
<RAOF> james_w: Actually, it shows a logout dialog, not a shutdown dialog (at least here).
<persia> RAOF, how updated are you?
<james_w> RAOF: are you up to date, it was changed this week.
<RAOF> A day or two late.
<LimCore> james_w: 60 s is too much.  Plus, the goal is pressing button will also shutdown machine that is partially hanging (i.e. 100% cpu usage)
<persia> Might be it.  I got the logout yesterday.
<james_w> LimCore: well, that's quit a bit more work.
<LimCore> also, it will not work when not in X
<LimCore> my idea is simple: system (scripts) react to pressing the power button.  first 1,2,3 times nothing (but WM can react)
<LimCore> 4 - shutdown   5 - more aggressive shutdown  etc
<LimCore> another use case is to get machine almost hanging by fork bomb
 * jdong mumbles Alt-sysrq-REISUB under his breath
<Hobbsee> LimCore: if it's partially hanging, or fully hanging, will it really result in the filesystem getting finished properly anyway?
 * jdong agrees with Hobbsee 
 * LimCore jdong points to his use cases in which lights are out and/or keyboard doesnt work. but yes, this is the goal, only by power button instead
<james_w> you want to run a script when the system is being fork-bombed?
<persia> In the case of a hang, it doesn't help at all, as it won't trigger acpi-support|pm-utils
<jdong> there's no guarantee that the flurry of shutdown scripts will execute correctly if it's fork-bombed
<LimCore> ok, perhaps this is not solution for forkbomb use case.   it is for no-keyboard  and no-screen cases
<jdong> why is 60s too long?
<LimCore> user perhaps wants it off in 10s
<LimCore> a) ups will die in 30 s
 * persia notes that it would be nice if the 60s didn't count down in 10s increments.
<jdong> will the user die if the computer turns off in 60s?
<LimCore> b) thunderstorm
<LimCore> c) fire
<LimCore> etc
<jdong> ok those are ridiculously far-fetched usecases.
<LimCore> jdong: no, but FS will
<Hobbsee> jdong: if you were out drinking, and didn't notice that there was a thunderstorm.
<persia> LimCore, It's going to take a while to sync the disks and shut down anyway.
<Hobbsee> jdong: until the first boom
<Hobbsee> persia: well, that's what I would have thought.
<LimCore> persia: that is why waiting 60 is too long.  sync takes 1-3 sec usually
<ion_> d) nuclear holocaust
<LimCore> jdong: thunderstorm  and   ups die in 30 s  are my own use cases
<Hobbsee> ion_: i'm sure that c & d mean that you don't care about the laptop, in that case.
<persia> LimCore, How long does it take your machine after you select shutdown from the menu?  Takes me 20-30 seconds.
<Hobbsee> or other computer.
<jdong> so for that we should make the shutdown button work with less confirmation?
<LimCore> persia: correct, this is why 6th press will just  sync and remount ro
<jdong> frankly I already think Intrepid has gone off the nazi end for lacking confirmation
<jdong> i.e. the logout/restart/shutdown buttons all have no confirmation prompt
<Hobbsee> jdong: as long as they *never* become like my work system...
<persia> Hobbsee, What's that like?
<Hobbsee> jdong: "shutdown".  "OK!  bang!" "oh, shit, another 3+ min wait for it to boot again"
<LimCore> jdong: first 3 presses do nothing.  its not like users will press them by accident
<Hobbsee> persia: ^
<jdong> sync and remount-ro is not any less likely to corrupt your data!
<jdong> particularly if it involves some SIGKILLS first
<persia> Oh.  I had a configuration like that once.  Very annoying.
<bryce> LimCore: hmm, given this is sounding feature-ish, you may find it challenging to get such a thing accepted by the intrepid release team
<LimCore> jdong: sync + remount-ro  is not less likelly to corrupt file system, then pulling out the plug?
<Hobbsee> bryce: yeah, i can outright decline it now, if you like :)
<jdong> and we don't need morse code sequences for the power button... I'd be very much against that idea from a UI perspective.
<Hobbsee> but i figured i should at least listen to it first.
<bryce> Hobbsee: *nods*
<jdong> LimCore: it is not any less likely to corrupt the data, no.
<Hobbsee> jdong: ++.  Little kids and computers.  argh.
<Hobbsee> arent' filesystems good enough nowadays to handle this stuff, particularly when the machine is locked, anyway?
<LimCore> jdong: ok, then unmount, or whatever is needed
<jdong> LimCore:  are you listening? interrupting all disk activity via SOFTWARE is no safer than doing the same in HARDWARE.
<LimCore> Hobbsee: if you are so sure, you can try right away, especially try with XFS fs
<jdong> LimCore: XFS doesn't even remount-ro when you tell it to
<jdong> LimCore: nor does it completely sync.
<Hobbsee> LimCore: right, well, last I checked, we don't use xfs by default...
<jdong> if you are worried about powerdown corruption you shouldn't be anywhere *NEAR* XFS.
<jdong> hell XFS makes assumptions about disks that aren't even true except on expensive corporate storage devices.
<LimCore> jdong: well, then unmount
<jdong> LimCore: how do you propose doing that? :)
<LimCore> this is a related problem, it should be more userfriendly to unmount DVD in use etc, is that fixed
<Hobbsee> why don't you test it?
<LimCore> afair latest gnome finally shows a list why it cant unmount
<Hobbsee> actually, last ichecked with a dvd in use, pressing the eject button worked fine.  Maybe tha'ts not user friendly enough for you, i'mnot sure.
<LimCore> it could use a button to kill thoes applications.  but that is not critical
<jdong> lol no, we shouldn't give users a magical button to kill processes.
<jdong> you do that and I will personally write an exploit for it.
<Hobbsee> jdong: there already is one, anyway.
<Hobbsee> jdong: well, at least, for GUI bits.  in the panel.
<Hobbsee> (not on by default, fortunately)
<LimCore> why not?
<ion_> hobbsee: It should only eject after you hit the eject button five times. :-P
<Hobbsee> jdong: it's how i save firefox's state :P
<jdong> *sigh* where is desktop Linux going these days...
<jdong> LimCore: because it can be used to kill processes maliciously?
<Hobbsee> jdong: just be greatful that the ones who tend to make the decisions upstream aren't currently here and talking...
<LimCore> ion_: no no, sudo something something ;   ps aux ;  kill -9 etc etc,  is much more user friendly. For humanbeings.
<Hobbsee> LimCore: you shouldn't *have* to be force killing anything *at all*.
<jdong> you shouldn't be using kill -9 if you care about corruption either.
<jdong> I still don't see *ANY* sense in fscking killall -9'ing userland to "unmount the filesystem safely"
<jdong> isn't there something counterproductive about doing this? anyone?
<Hobbsee> if the program's freezing, it's a bug.  fix the program, instead of making it easier to killthings.
<LimCore> jdong: corruption of filesystem -vs- corruption of data in file written by given program because I terminated that
<Hobbsee> jdong: sure, but i don't thinkhe'slistening...
<jdong> LimCore: your filesystem should not be corrupting when you uncleanly shut down
<LimCore> well, Im reading all you say
<jdong> LimCore: take that up with your hardware and filesystem vendor.
<jdong> namely for XFS this is a hardware problem
<jdong> your hardware was obviously not designed to run XFS
<LimCore> jdong: I had such corruptions on ext3 as well, but I did not test recently. Still Im quite sure randomly pluging out power cable in middle of writes to ext3 will corrupt more then just the files that where being written to
 * jdong thinks hard about why we don't configure to use XFS by default...
<jdong> LimCore: it won't corrupt the filesystem but any in-transit data is at risk for being stale or incompletely written.
<jdong> and that's *GASP* the same symptoms of killall -9.
<LimCore> so you are saying that killing -9 one program is not better then randomly pulling out the plug from pc?
<Hobbsee> guys, we have a release soon.  This being discussed now is *not* a release critical bug, and it would be great if these discussions could be held elsewhere.
 * jdong agrees with Hobbsee 
<jdong> LimCore: depending on what program, absolutely not.
<james_w> it would be great if the participants would go and fix RC bugs instead of discussing it :-)
 * bryce +1
<LimCore> data corruption sounds like RC problem, doesnt it?  With the confirmation box, no need to kill -9 anything
<Hobbsee> james_w: that too.
<LimCore> so, is it not?
<bryce> LimCore: RC bugs are ones targeted | milestoned in launchpad
<LimCore> do we want to make some users have to hard reboot their boxes, or do we want to take 2 hours to fix it?
<james_w> 2 hours?
<elkbuntu> LimCore, i'm not a developer, and not even i can take what you're saying here seriously.
<LimCore> elkbuntu: do you have some reasoning for that?
<Hobbsee> LimCore: provide the patch, and get it uploaded.  It will then be reviewed.  It may be declined for intrepid, which means you can get it into jaunty.
<elkbuntu> LimCore, yes. you're refusing to listen to other people's reasoning.
<jdong> yes. what you are saying does not make much sense, you have not provided any valid solutions, and now you are continuing to disobey the requests to keep this channel on topic.
<Hobbsee> LimCore: unless you do this, no it will not be considered, and the discussions will not continue here.
<LimCore> elkbuntu: I responded to all arguments so far.  Ok, which channel is on topic for this then?
<elkbuntu> LimCore, responding does not mean you listened properly.
<slangasek> apachelogger: how does it happen that a patch that's been in kde4libs for a year was responsible for bugs just filed?
<slangasek> (in the past two months, that is)
 * Hobbsee eyes that kdebase-workspace upload
<slangasek> Hobbsee: yes, I skipped over that one in the queue
<apachelogger> slangasek: the one about kmenuedit wasn't visible in KDE 4.0, because there was no visible way to start the editor at all
<apachelogger> I am not sure why he broken icons one isn't older though, TBH bug reports for KDE 4 are really rare still
<apachelogger> s/he/the
<Hobbsee> slangasek: i don't think it's right, either.
<apachelogger> Hobbsee: what's it changing?
<Hobbsee> apachelogger: well, it's bumping an unsatisfiable recommends to an unsatisfiable suggests, to start with.
<NCommander> StevenK, hola
<apachelogger> Hobbsee: python-plasma-examples is available here
<Hobbsee> apachelogger: in what repository?
<apachelogger> Origin: Ubuntu
<Hobbsee> apachelogger: (apt-get policy  python-plasma-examples)
<apachelogger>         500 http://archive.ubuntu.com intrepid/main Packages
<Hobbsee> apachelogger: hmmmm, i'll try updating again, but my apt-cache isn't finding it.
<apachelogger> Hobbsee: kdebase-workspace is actually the source package for python-plasma-examples
<Hobbsee> apachelogger: ah.  wonder why it refused to find it previously.  p.u.c doesn't know about it either yet
<apachelogger> https://edge.launchpad.net/ubuntu/intrepid/i386/python-plasma-examples/4:4.1.2-0ubuntu10
<apachelogger> Hobbsee: puc is not the fastest ;-)
<apachelogger> very weird either way though
<Hobbsee> apachelogger: ahh.  so itis new.
<apachelogger> pretty much
<Hobbsee> slangasek: if we're not building cds yet, then i presume that one's safe.
<slangasek> Hobbsee: kdebase-workspace?  If you think it's appropriate, feel free to push it through
<Hobbsee> slangasek: OK
<Hobbsee> slangasek: i'm just not sure of cd building status.
<slangasek> CDs on Monday
<Hobbsee> right.
<Hobbsee> mdke: was ubuntu-docs going to get updated before release?
<nixternal> he is probably sleeping
<Hobbsee> nixternal: that's a point.  it's been updated in the bzr branch, but never got uploaded.
<nixternal> actually, the final upload of ubuntu-docs will be for translations only
<nixternal> and that typically happens like, damn right now
<Hobbsee> nixternal: https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+bug/272772 too, preferably.  it's RC.
<ubottu> Launchpad bug 272772 in ubuntu-docs "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix committed]
<nixternal> ya, I just saw that
<nixternal> ubuntu-docs shouldn't depend/recommend/suggest firefox as they aren't built to HTML, they stick in DocBook/XML format for ubuntu-docs
<nixternal> unless something has changed
<Hobbsee> nixternal: ubuntu-serverguide does
<nixternal> ahhh
<nixternal> does it dep on www-browser?
<nixternal> www-browser | x-www-browser or whatever it is
<nixternal> haven't looked in a while to be honest
 * nixternal looks
<Hobbsee> nixternal: not on my sysetm.
<nixternal> looking now
<Hobbsee> Suggests: firefox
<nixternal> hrmm, that is nuts
<nixternal> should just recommend either www-browser | x-www-browser, not a specific browser
<Hobbsee> oh,score, Keybuk's tracking down this iwl3945 bug for us!
<nixternal> what is the bug?
<Hobbsee> nixternal: well, yes.
<Hobbsee> nixternal: the one above?
<Hobbsee> or the iwl?
<nixternal> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev
<nixternal> mine has worked great actually, but then again I don't use it all that much
<Hobbsee> nixternal: boot hang bug - https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/263059
<ubottu> Launchpad bug 263059 in linux "[regression] 2.6.27-7 sometimes fails to boot (iwl3945 issue?)" [High,In progress]
<nixternal> Hobbsee: yes, mdke fixed ubuntu-docs in bzr by suggesting www-browser ....
<Hobbsee> nixternal: right, yes, I see that in the bug, but it's not in the archive yet :)
<nixternal> Hobbsee: looks like he is currently importing translations
<Hobbsee> nixternal: oh, so that's related.  right.
<nixternal> not related, but he will probably prepare the package shortly and get it uploaded
<Hobbsee> ah, cool.
<nixternal> he has been highlighted enough, he will update us in the next 12 or so hours I am sure :)
 * calc back, and got his hair chopped off
<calc> slangasek: thanks wrt 223476
<calc> slangasek: i'm pretty sure i brought that bug up before but it was several months ago
<calc> slangasek: and we were already too low on space at the time
 * Hobbsee kills more bugs off the intrepid list.
<nixternal> kill kill kill
 * calc is getting rid of his bugmail queue
 * nixternal is trying
<calc> gar, new vmware installs into /usr without asking you
<calc> it should at least into /opt if not /usr/local
<lifeless> the FHS is for other people
<Hobbsee> sbeattie: were you planning to provide a patch for https://bugs.edge.launchpad.net/ubuntu/+source/djvulibre/+bug/277301?
<ubottu> Launchpad bug 277301 in djvulibre "package update-manager 1:0.93.18 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)" [High,Triaged]
<calc> lifeless: until 6.5 it asked where you wanted to install it
<calc> well it is a lot simpler install, but too simple i think since it installs into an illegal (for 3rd party) location :\
<Hobbsee> calc: 223476 should probably be fix committed / fix released - i accepted the u-m upload to add -math to the seeds.
 * NCommander is finally free from classwork!
<Hobbsee> NCommander: yay!  so, fix some bugs!
<calc> Hobbsee: cool :)
<NCommander> Hobbsee, working on fixing lpia's kernel ;-)
<Hobbsee> NCommander: that's good too :)
<calc> Hobbsee: done, i added it to hardy as well on the bug report to have it examined when i get a chance
<lifeless> calc: I was being droll
<Hobbsee> calc: \o/
<calc> lifeless: i know, i just wanted to rant about it since it is really annoying :\
 * lifeless hands calc a blog
<calc> heh :)
<lifeless> (it is ontopic here, just saying, a good rant deserves an audience)
<calc> yea
<calc> i haven't had a blog in several years, i probably should set one up again
<NCommander> calc, join the planet
<StevenK> NCommander: Hey hey
<NCommander> StevenK, so amitk broke the lpia build ;-)
<NCommander> (he forgot to bump the abi folder name)
<StevenK> Argh
<NCommander> Yeah
<NCommander> I'm getting closer to nailing this
<NCommander> Almost everything is getting built now, but I'm debating if I should move the binary-indep rules to binary-arch
<NCommander> (since the lpia kernel strictly speaking has no arch all packages)
<StevenK> Right
<StevenK> Personally, do whatever makes the diff smaller
<StevenK> amitk might feel differently
<NCommander> Well, that would technically make the diff get larger, but having binary-indep called from binary-arch shouts hack
<StevenK> "Duh"
<calc> launchpad should host blogs :)
<calc> it does everything else already, heh
<Hobbsee> calc: erk.
<StevenK> Yes, "Erk"
<NCommander> calc, SourceForge has that feature even
 * calc wonders why up arrow in vmware 6.5 causes printscreen
<NCommander> StevenK, WOOO< success!
<StevenK> Woot
<NCommander> dpkg-deb: building package `linux-headers-2.6.27-4-lpiacompat' in `../linux-headers-2.6.27-4-lpiacompat_2.6.27-4.8_lpia.deb'.
<[reed]> calc: 8.10 remapped all my keybindings on my thinkpad
<NCommander> Need to go through and make sure everything actually worked sanely
<[reed]> I wasn't happy at all
<[reed]> considering they are all wrong
<[reed]> and like three different random buttons now printscreen instead
<NCommander> StevenK, I can upload this to a PPA, and then smoke test lpia-lrm/lpia-meta
<NCommander> StevenK, second woo moment, it appears at first glance the linux-lpia-headers packages are also properly working
<NCommander> dh_installchangelogs: I have no package to build
<StevenK> NCommander: To be honest, don't bother with a PPA
<NCommander> That however I'm still figuring out
<StevenK> NCommander: I just want it in the archive
<NCommander> Find someone who can commit to the git tree :-)
<StevenK> NCommander: It's more to be in the archive than the git tree at this point, given where we are in the release
<StevenK> more important
<NCommander> StevenK, well, right now, I'm ripping the rules a new one
<NCommander> THe actual debs are not being built because the debhelper magic is screwed up
<NCommander> So give me some time to finish twisting the rules into submission (everything is getting built which is a good thing)
<NCommander> and since I just need to rerun the install phase over and over, its not that time consuming
<NCommander> ^- StevenK
<StevenK> Fair enough
<NCommander> It will probably take me an hour or so to get this properly locked down (an install run takes about 10 minutes), and then I would like to do a full build run if you can tolerate it ;-)
<StevenK> I'd like to upload before I have to leave at 4:45pm local
<NCommander> StevenK, how long is that?
<StevenK> NCommander: An hour and change away
<wgrant> 1.5 hours.
<NCommander> StevenK, its building packages, I'll post the list once it finishs so we can make sure all the necesities are there
<NCommander> -rw-r--r-- 1 root root 556K 2008-10-18 00:41 linux-headers-2.6.27-4-lpia_2.6.27-4.8_lpia.deb
<NCommander> getting closer
<StevenK> We knew that one built
<StevenK> linux-lpia-headers-2.6.27-4 is the question mark
<NCommander> StevenK, the files weren't getting loaded into it
<NCommander> (I just fixed that)
<NCommander> (the important thing is dpkg -c actually listed stuff :_-))
<NCommander> *:-)
<NCommander> -rw-r--r-- 1 root root 5.6M 2008-10-18 00:58 linux-lpia-headers-2.6.27-4_2.6.27-4.8_lpia.deb
<NCommander> \o/!
 * NCommander needs to clean and make sure allt he files still end up in the right places however
<NCommander> StevenK, all the packages aside from the -debug ones seem to get built, but I need to do a full build run to make sure all the files are properly ending up int he right place
 * NCommander however saves the debian/build directory so the kernels themselves do not need to be recompiled
<StevenK> NCommander: Still building?
<NCommander> StevenK, well, I had to restart it because of a bug
 * NCommander got the build script stuck in an endless loop <g>
<StevenK> Woot
<StevenK> NCommander: I'll be leaving in a few, can you mail me the debdiff?
<slangasek> calc: well, it was never nominated for intrepid until now... :)
<NCommander> However, I did get a proper linux-headers and linux-lpia-headers package it seems
<slangasek> calc: anyway, we'll see if it fits :)
<Mez> anyone here know lots of linker voodoo ?
 * Mez needs some help with a question from his Debian NM thing, and I REALLY don't know the answer (and can't find much, and man gives a horrible explanation)
<NCommander> Mez, depends on what sorta voodoo
<Mez> NCommander: an explanation of ld's -Bsymbolic?
<NCommander> That's usually a bonus question
<NCommander> Are you sure you have to answer it?
<slangasek> Mez: the explanation in ld(1) is complete, as far as it goes; what part is confusing?
<slangasek> it's true that this is a bonus question; it's certainly not the question I would ask about library linkage if I'd written those templates :P
<Mez> slangasek: It's evil... though - ld confused me a little as I wasn't reading the right bit of the man page explanation
<Mez> slangasek: "Bonus" Question ?
<slangasek> Mez: being able to answer the question correctly has no real bearing on your NM application
<Mez> slangasek: o_O ok... *confused* wasn't aware of that, but have managed to find a better explanation now
<NCommander> slangasek, the T&S bonus questions though are useful, the AM_MAINTAINER_MODE is handy for someone who hasn't heard of it before
<slangasek> I happen to find the current written test approach to NM distasteful in general, and fundamentally, the lack of a support structure for a more skills-oriented NM process was a big reason why I failed at being an AM
<lifeless> NM is broken
<slangasek> news at 11
<wgrant> I'm not sure that NM is more broken than our process.
<Mez> slangasek: Indeed, a more skills oriented approach would be nice (like in Ubuntu) ... but... *shrugs*
<lifeless> wgrant: its way more broken
<NCommander> slangasek, I personally learned a lot during NM
<Mez> NCommander: so have I ;)
<lifeless> NCommander: thats to your credits, not the NM process' credit
<NCommander> slangasek, so its not completely useless, and for the one or two questions I did get stuck on, my AM was extremely helpful
<Mez> NCommander: yeah, my AM has been extremely helpful too ;)
<Mez> if a little pedantic ;)
<NCommander> Well, I feel the P&P test is extremely useful for those unexposed to licensing issues, but for T&S, I think I would perfer something more hands on
<slangasek> NCommander: that's fine; but it ought to be "here's some stuff you should digest, ask me if you don't understand something, now here's a handful of random questions about it, ok now let's see what you're actually *doing*"
<slangasek> wgrant: NM doesn't do a good job of selecting for the things it should
<Mez> slangasek: don't they actually check your packages etc though?
<NCommander> slangasek, well, my biggest concern with NM is two fold, is that the length of the process is insane, and for people who are porters (or do things beside packaging as a main task), its completely lopsided
<slangasek> wgrant: too much of it is a test of one's tolerance for paperwork and sitting alone in a cold waiting room waiting to be called in for your interview
<NCommander> It's meant for people who package pretty much exclusively. Even my AM admitted its not well suited to people who are pretty much porting vs. packaging
<wgrant> slangasek: Right, and it's particularly fun when your AM vanishes.
<Mez> wgrant: haha, I'm lucky and havent had that happen yet, though it's part of the reason I wouldn't become an AM at the moment. I have a tendency for doing that ;)
<slangasek> Mez: yes, but the package checks are pretty weak; they amount to "can the AM find bugs in your package?" when it should be "can the NM find bugs in this package and fix them?"
<wgrant> Mez: white is your AM, isn't he?
<Mez> slangasek: I thought that part of the process was going and fixing RC bugs/other bugs
<NCommander> slangasek & wgrant: that just happened to me
<Mez> (and I've been told to do QA uploads too)
<Mez> wgrant: yes... you stalking me ? :P
 * NCommander is considering applying for DM status so I can help with pkg-xfce without constantly stalking for uploads
<wgrant> Mez: Heh. Maybe.
<slangasek> Mez: "find one RC bug and fix it" is, IMHO, an insufficiently high bar for DDship on a point that counts
<slangasek> we have high bars in the wrong places
<NCommander> slangasek, well, looking at debian-qa, there are very few people who are seemingly working on RC issues if the package maintainer hasn't tackled it already
<Mez> slangasek: I've been told at least 2 and a couple of important or higher
<slangasek> NCommander: why are you expecting to see evidence of this on debian-qa...?
<NCommander> Most of the work on solving RC bugs is split up between #debian-qa and #debian-devel on IRC
<NCommander> ^seems to me
<slangasek> debian-qa has always focused on unmaintained packages; that's the last place I would expect to see folks holding a Bsp
<slangasek> SP
<NCommander> well, the bug count is going down slowly. It was over 200 a few days ago as lenny gets closer and closer to release
<Mez> slangasek: so where are the high bars that shouldn't be there, and where should the high bars be?
<slangasek> Mez: the long written test for T&S shouldn't be there; it should be reduced to a random scattering of questions per applicant.  And there should be higher bars for demonstrating functional knowledge and involvement, including being able to fix an artificially broken package, and demonstrate a record of healthy contribution to Debian (which definitely does /not/ mean having a pet package in the archive).
<Mez> slangasek: multiple pet packages ? :P
<slangasek> heh
<slangasek> a pet desktop environment
<Mez> slangasek: what about evil non-free stuff taken over from someone else, but that people seem to want to use for some unknown reason?
<slangasek> sure, that's ok... if I were the AM, I would quiz someone extra hard about the DFSG if that was their only package, though :)
<Mez> slangasek: I probably don't pass on your score then ;)
<Mez> http://qa.debian.org/developer.php?login=mez@ubuntu.com
<slangasek> <shrug> looks fine to me. :)
<slangasek> you have three pet packages, *plus* non-free packages, so. :-)
<Mez> slangasek: I wouldnt exactly call symfony a "pet" package atm ;)
<Mez> It's annoying the heck outta me... and upstream need a good slap ;)
<slangasek> there are people who keep chihuahuas as pets
<Mez> slangasek: ;)
<Mez> good analogy.
 * Mez is going to have to get the word "chihuahua" in the changelog now somehow
<NCommander> Mez, O_o;
<bryce> slangasek: fix for 283921 uploaded and ready for review.  I've promoted it to be an RC bug because its inhibiting input-hotplug configuration from working.
<bryce> slangasek: it's just a one line fix, but took wgrant an appreciable amount of the day to debug it.
<bryce> slangasek: he's also identified all the packages that depend on that header and will be putting in builds for each.  I've reviewed all this and it looks correct.
<NCommander> cjwatson, are there lpia CDs?
<bryce> NCommander: not afaik
<NCommander> How can it be installed?
<wgrant> Of course upstream had to fix it just a couple of hours after I had the first part uploaded...
 * NCommander has a friend who has an atom board, and has great interest in lpia
<bryce> NCommander: when I've done it, I've gotten a USB iso image, put it on a USB stick, and booted from that
<slangasek> bryce, wgrant: accepted; how many packages are we looking at for needing rebuilds?
<NCommander> bryce, where can I find that?
<bryce> slangasek: 7, listed on 283921
<wgrant> Isn't x11proto-input one of the 7?
 * wgrant counts.
<slangasek> bryce: bleurgh
<bryce> ok 6
<bryce> slangasek: huh, I hadn't heard ack pronounced that way before
<wgrant> Heh.
<slangasek> will these all get uploaded over the weekend, so as to not block CD builds come Monday?
<bryce> yes
<slangasek> ok
<wgrant> They're trivial rebuilds, so I don't see why not.
<slangasek> just making it clear :)
<wgrant> They only depend on x11proto-input-dev being published.
<wgrant> Sure.
<bryce> only fair :-)
<NCommander> bryce, bah, my friend will be disappointed by the lack of lpia installability
<bryce> NCommander: well, really you should talk to the UME guys directly.  There's a ubuntu-mobile mailing list that's the best place to ask
<slangasek> NCommander: he could install i386 instead and pretend lpia doesn't exist?
<bryce> I've not done an install in some time, so my knowledge is dated.
<wgrant> lpia has some nasty MID-specific patches... it should probably be avoided.
<NCommander> slangasek, he could, but lpia is compiled for atom ... ah
<maco> wgrant: any chance bug 278418 was intentional?  i personally find the similarity of the icons confusing, but crimsun says it might have been on purpose
<persia> NCommander, There is an lpia alternate CD, and a MID live environment.
<ubottu> Launchpad bug 278418 in human-icon-theme "human-icon-theme no longer replaces System->Administration icon" [Medium,Triaged] https://launchpad.net/bugs/278418
<NCommander> persia, where's the later
<persia> wgrant, It should work fine for Kubuntu.
<wgrant> maco: They're very different styles, so I doubt it...
<persia> NCommander, http://cdimage.ubuntu.com/ubuntu-mid/intrepid/current/
<maco> ugh, he says i have bad quoting because "no idea if it was on purpose" is totally not the same thing as "might have been on purpose" though i dont understand the difference...
<wgrant> Heh.
<wgrant> One just implies a slightly different magnitude of suggestion, I guess.
<maco> my interpretation was "*shrug*"
<NCommander> persia, I think I got the LPIA kernel fixed
<persia> NCommander, Cool.  It builds cleanly now?
<NCommander> persia, and it generates proper header packages
<NCommander> ;-)
<persia> Is it still -4 ?
<NCommander> Yup
<NCommander> (-4.8 now)
<NCommander> BUt yeah
<persia> Excellent.
<NCommander> No ABI changes
<persia> Anyone feel like uploading a kernel?
<NCommander> I did give the rules file a lobotomy
<persia> It probably needed it.
<NCommander> I actually wanted to make more changes
<NCommander> (its a rather nasty hack at the moment)
<NCommander> But that can wait for jaunty
<persia> How nasty?  Will it break on SRU?
<NCommander> It sorta fails the builds in a sane way test now, binary-indep is called from binary-arch
<NCommander> since lpia kernels aren't built at all on x86 to generate the meta packages
<persia> See, the details are unpleasant, offensive, and likely wrong ...
<persia> Will it break on SRU?
<NCommander> Oh
<NCommander> No
<persia> OK.  Then it needs uploading :)
 * NCommander couldn't see how a rules change could break SRUs ...)
<persia> Well, it's possible to create a rules file that works until it's been used to compile the package on the buildds.
<NCommander> I tested an earlier version of this package in my PPA
<persia> Such a file would then break if the package was included in the archive, and it was rerun.
<NCommander> (that one had a few bugs which have been since exercised)
<NCommander> it built without issues
<persia> Next step is testing on HW?
<NCommander> you mean an actual lpia machine?
<NCommander> Yeah
<persia> That, or use the lpia-compat flavour if you don't have an i686 available.
<NCommander> I have an i686
<NCommander> So you want make to make sure the kernel boots
<NCommander> It would be lovely if I could install the packages, but I'm arch amd64, not arch i386 :-/
<persia> Well, that's a bonus :)
<persia> Should work in kvm if you can do that.
<NCommander> Well, I'm waiting for a final build run to finish
<NCommander> With debug packages, docs, and sources generated
<NCommander> (I fixed everything with the rules evil ;-))
<persia> This one is expected to finish?
<NCommander> I've already built it before
<NCommander> But without the debug kernel
<NCommander> I also just need to make sure files are ending up in the right places (since we've never built headers out of the lpia)
<NCommander> persia, do you have a kernel.u.c account?
<NCommander> (I have git patches)
<persia> No.  Just send them to amitk.
<NCommander> works for me ;-)
<NCommander> persia, its a LARGE debdiff because a folder has to be renamed
<persia> Just a folder under debian/ right?
<NCommander> yeah
<NCommander> the abi folder needed a version bump
<persia> OK.  No worries.  That part is the part that kernel developers don't like to change.
<NCommander> There are no source changes
<NCommander> and the ABI check confirms nothing changed
<NCommander> the lpia-lrm and meta packages *should* just compile out of the box once this available
<wgrant> Won't they need build-dep changes for the new header name?
<maco> ABI check? is there documentation somewhere i can read about that? i didnt know there was some automated way to find out if the kernel ABI was changing
<persia> maco, There's a script in the kernel source packages.
<wgrant> maco: It is perhaps the hardest part of building a custom kernel. It's nasty.
<NCommander> wgrant, no, there is a provides linux-headers, so it should in theory just do the right thing if I follow StevenK right
<NCommander> If not, then I can kick off the packages
<NCommander> Ok, all the udebs built
<persia> wgrant, They got those in the last upload, which then promptly FTBFS because they weren't built.
<NCommander> persia, you must be happy this got fixed ;-)
<NCommander> persia, what was the last linux-lpia package to be uploaded? (packages.u.c is giving me issues)
<maco> persia, wgrant thanks
<persia> NCommander, p.u.c is not a reliable way to check anyway.
<NCommander> an earlier version of my patch landed in git (it wasn't finished testing when it got committed, and the repo was tagged)
<NCommander> I'm not sure if that package was uploaded or not
<persia> NCommander, https://launchpad.net/ubuntu/+source/linux-lpia
<NCommander> persia, ok, that makes life easier, I'll have amitk simply pop off the patch in git, and pop mine in place, which will get everything synced up :-)
<NCommander> Err http://us.archive.ubuntu.com intrepid/main linux-lpia 2.6.27-4.7 (dsc)
<NCommander>   Could not open file linux-lpia_2.6.27-4.7.dsc - open (13 Permission denied) [IP: 91.189.88.31 80]
<NCommander> Uhhhhhhhhh
<NCommander> WTF
<NCommander> oh wait
<amitk> NCommander: you got something for me?
<NCommander> amitk, I got the build fixed
<amitk> splendid
 * NCommander is waiting for one last build run to finish
<NCommander> its builiding linux-lpia-source ;-)
<NCommander> It just finished linux-lpia-doc :-)
<NCommander> amitk, here, I got the patch, its still building (my HDD is thrashing ATM so ... :-/)
<NCommander> persia, http://paste.ubuntu.com/59191/ - kernel patch, I can have a debdiff in a few minutes
<persia> amitk, ^^
<NCommander> ;-)
<NCommander> My laptop sucks
<NCommander> I dunno why its taking forever to build the source package
<NCommander> and to whoever uploaded the package
<NCommander> PLEASE, upload a .orig.tar.gz
<NCommander> s/uploaded/uploads
<amitk> persia: NCommander: reworking this into git and recreating a diff.gz now. Give me 20mins
<NCommander> amitk, give me upload credit this time :-) *shot!*
<NCommander> amitk, so I take it your the lpia kernel guy?
<lool> moving from linux-lpia-headers to linux-headers hmm
<NCommander> lool, its consistant with linux-ports
 * lool refuses to ponder on the usefulness of having a separate source if we don't have separate headers
<lool> Whatever fixes the installability :)
<NCommander> lool, we do
<NCommander> lool, 2.6.27-4.8-lpia(compat)
<persia> lool, binary package name has no relation to contents.
<amitk> NCommander: I did give you credit in git. Do you want to do the deb diff?
<NCommander> amitk, I was referring to upload credit ;-)
<NCommander> Yeah
<NCommander> I was doing that now
<amitk> NCommander: go ahead
<NCommander> I was just making sure the headers came out in the right place
<NCommander> http://pastebin.ca/1230022 - there we go!
<amitk> persia: ^
<amitk> looks ok to me
<persia> lool, ^^
<amitk_> NCommander: how are we doing? upgrade killed my network...
<NCommander> amitk, got a debdiff
<NCommander> amitk_, someone needs to test the resulting kernel to make sure it works, and as an added bonus, the header packages are all installable and usable
<amitk_> NCommander: your patch doesn't apply cleanly - lots of trailing CRs and a reject
<amitk_> I wonder if the first part is pastebin's doing
<NCommander> amitk, might be
<NCommander> Hold on, let me just fire you an email
<NCommander> amitk, you got mail
 * amitk_ back from breakfast in 15
<amitk_> NCommander: did you create the patch against the existing patch in git or against -4.7?
<NCommander> The git patch I sent you was against git, the debdiff was against 4.7
<amitk_> ahh
<elmo> hmm
<elmo> if, in a postinst, I'm starting an initscript that depends on ldconfig actually being run rather than triggered; what's the BP way to do that? just setting LDCONFIG_NOTRIGGER to something?
<elmo> also, is there a better way than /etc/modules to get a module permanently installed, from a packaging POV
<persia> elmo, In the one case where I encountered a package like that, I just called ldconfig.real in the postinst.  Best practice is probably to separate libraries from daemons so you never have to do that.
<elmo> persia: I'm not sure that would help?  there's no guarante the trigger would have run by the time the daemon's package's postinst comes to run?
<elmo> oh, duh, yeah there is.  don't mind me
<elmo> persia: ta
<NCommander> amitk_, the kernel smoke test works!
<NCommander> amitk_, I'm testing to see if I can build modules against the headers
<NCommander> persia, do you have a core-dev who can upload?
<persia> lool, care to upload linux-lpia ?
<elmo> next stupid question: why doesn't libc6-i686 include a ld.so.conf.d/ for */lib32/ ?
<NCommander> persia, forget it for the moment
<NCommander> persia, I caught a bug in the headers package
<NCommander> One of the headers came out in /usr/src/linux-lpia-headers by accident
<Hobbsee> bryce: not to pressure you, but will xserver-xorg-input-evdev appear soonish in the queue?
<Hobbsee> OTOH, the buildds just got langpack'd, so you've got time..
<amitk_> NCommander: I've folded in your latest patch with your previous one and pushed to git
<NCommander> amitk_, d'oh
<NCommander> (we just caught a bug)
<NCommander> indep_hdrpkg = linux-lpia-headers-$(abi_release)
<NCommander> indep_hdrdir = $(CURDIR)/debian/$(indep_hdrpkg)/usr/src/$(indep_hdrpkg)
<NCommander> Two points to anyone who can see the bug :-)
 * NCommander does note we're making progress here
<persia> NCommander, You forgot a : ?
<NCommander> No
<NCommander> it needs to be usr/src/linux-headers-$(abi_release)
<NCommander> or module-assistant can't find the headers
<NCommander> (they came out in /usr/src/linux-lpia-headers)
<persia> Ah.  I see.
<wgrant> Hobbsee: bryce advised me that all of my rebuilds were uploaded, and he went to bed some time ago.
<NCommander> persia, its just a minor oversight, so I just need to rebuild the kernel, and test in two/three hours
<cjwatson> wgrant: bryce uploaded evdev to hardy by mistake ...
<cjwatson> so somebody will need to fix that and reupload
<Hobbsee> cjwatson: ah, was *that* the problem.
<wgrant> cjwatson: Ah, that would do it.
<cjwatson> same happened to xserver-xorg-video-intel
<wgrant> Did the others go there?
<wgrant> I'm no core-dev, so somebody else will need to do it.
<cjwatson> the rest are in unapproved
<Hobbsee> no
<cjwatson> bryce: ^-
<Hobbsee> cjwatson: were
<cjwatson> :-)
<NCommander> StevenK, ping
<wgrant> 19:58:13 < bryce> ok, I'm too tired.  --> bed.  night
<Hobbsee> -intel wasn't in the list of rebuilds..
<mdke> Hobbsee: yes, ubuntu-docs will need a translations update which I'm aiming to do by thursday
<cjwatson> intel was a different upload
<wgrant> Hobbsee: Indeed, it wasn't relevant.
<cjwatson> 2008-10-18 01:05:07 DEBUG     * 27_disable_fbc_on_965.patch:
<cjwatson> 2008-10-18 01:05:07 DEBUG       - Works around issue where flash videos freeze after playing for a few
<amitk_> NCommander: so it should be indep_hdrpkg = linux-lpia-headers ?
<cjwatson> 2008-10-18 01:05:07 DEBUG         moments on i965 chipset, by disabling Frame Buffer Compression, which
<cjwatson> 2008-10-18 01:05:07 DEBUG         is not working reliably on this chipset.  It can be re-enabled via the
<cjwatson> 2008-10-18 01:05:07 DEBUG         FrameBufferCompression option for testing purposes.
<Hobbsee> cjwatson: ah, right.  actually, That was in intrepid too.
<cjwatson> ah, ok, I didn't check
<cjwatson> right, really gone now
<Hobbsee> mdke: cool
<Hobbsee> cjwatson: cya!
<Hobbsee> wgrant: if you put it somewhere, i can sponsor it.
<Hobbsee> we won't discuss who then goes on to accept it
<mdke> Hobbsee: the www-browser update for ubuntu-serverguide will go in at the same tim, unless you desperately need it earlier
<wgrant> Hobbsee: It's a trivial rebuild - it's probably more work for you to apply a debdiff. But if you want me to, I'll do it.
<Hobbsee> mdke: not really.  just hope it gets done.
<Hobbsee> wgrant: sorry, that's what i meant
<mdke> Hobbsee: well, it is done.
<Hobbsee> mdke: ok, cool
<wgrant> Hobbsee: You want a debdiff?
<Hobbsee> wgrant: yeah, why not :)
<wgrant> Hobbsee: Sure, give me a sec.
<wgrant> Hobbsee: http://www.qeuni.net/f/1/2008/evdev.diff
<Hobbsee> wgrant: thanks, got it
<StevenK> NCommander?
<NCommander> StevenK, 90% success
<StevenK> NCommander: 90%?
<NCommander> StevenK, we got the headers and sources packages building and installable
<NCommander> StevenK, but one bit of the headers ended up int he wrong place when the package was installed (would break lpia-lrm)
<wgrant> Hobbsee: Thanksl.
<NCommander> StevenK, so we're almost there, I have a potential fix, but I need to wait for the build to finish to make sure the headers end up in the right folder
<NCommander> StevenK, not bad for 24 hours of work and coming in with no git/no ubuntu-kernel experience ;-)
 * NCommander has learned from his sponsors to slow down when doing work
<NCommander> StevenK, second BTW, ubuntu-mid, when installed, doesn't seem to properly setup X11
<StevenK> It ought to
<NCommander> DIdn't for me in QEMU
 * NCommander actually made sure the resulting kernel images were installable :-)
<NCommander> StevenK, I want this to be a single upload to fix everything
<NCommander> StevenK, so it should just be a matter of uploading, waiting for it to get published, and then clicking retry on lpia-lrm, and lpia-meta
<StevenK> Er, yeah, I know all that.
 * NCommander just feels the need to be complete
<pitti> ion_: right, ted and I just discussed doing the latter (hiding "new guest session" if one is running), he's working on it
<ion_> pitti: I emailed a preliminary patch to him last night. I didnât get around to testing it or refreshing the following patches yet, though.
<StevenK> NCommander: Any news?
<NCommander> StevenK, not yet
<NCommander> StevenK, well, it just finished compiling, now its installing
<NCommander> StevenK, ok, it built
<StevenK> \o/
<NCommander> StevenK, testing module assistant now
<persia> NCommander, dkms might be more interesting than module-assistant, given that more things use it.
<NCommander> persia, I just want to make sure I can build a kernel module
<NCommander> As long as a kernel module can be compiled, I'm satisfied ;-)
<ion_> dkms handles kernel upgrades better.
<persia> NCommander, Right, but the common case of compiling a kernel module in Ubuntu is going to be with DKMS, rather than with modass
<NCommander> GIve me a command and I shall run it
<persia> apt-get install kqemu-source ought to do it.
<NCommander> persia, looking promising
<NCommander> persia & StevenK: success!
<lucas> sma
<lucas> oops
<StevenK> NCommander: So I can have a kernel now?
<NCommander> StevenK, give me a moment
 * NCommander is making a debdiff
 * NCommander notes debdiff on the kernel is a SLOW process
<NCommander> still debdiffing
 * NCommander pokes his laptop to see if it just died without anyone noticing
<gaspa> cjwatson: I tested and added a simple correction to a your patch on thi bug:#259761
<gaspa> bug 259761
<ubottu> Launchpad bug 259761 in usplash "usplash segfaults on shutdown when pulsating" [Undecided,Confirmed] https://launchpad.net/bugs/259761
<StevenK> NCommander: It's still debdiffing?
<NCommander> The debdiff IS getting bigger
<NCommander> so it hasn't stalled
<NCommander> my HDD is trashing like mash
 * NCommander thinks his laptop ready to segfault and die on me
<persia> NCommander, You do have patchutils installed, right?  And you're using the same orig.tar.gz?
<NCommander> persia, what orig.tar.gz?
<NCommander> persia, the linux-lpia in the archive didn't have one
<NCommander> (yes, it is debdiffing two 70MB tarballs)
<persia> Oh, right.  I forgot.  No diff.gz shortcut.
<NCommander> persia, yeah
<NCommander> persia, someone needs to upload a orig.tar.gz
<persia> NCommander, Not at this point in the release cycle.
 * NCommander puts it on the jaunty todo
<NCommander> "No-changes orig.tar.gz upload"
<NCommander> DONE!
<NCommander> FINALLY
<NCommander> 31629 linux-lpia.debdiff
<NCommander> :-)
 * NCommander had to rename a directory
<NCommander> woo, its a 1.9MB patch
<StevenK> Oh, argh
<NCommander> StevenK, where should I send it?
<StevenK> NCommander: stevenk@canonical.com
<StevenK> Given the size, I'll review it tomorrow
<StevenK> NCommander: CC amitk@canonical.com, please
<NCommander> StevenK, its just a directory rename, that's whats so massive
<NCommander> StevenK, you got patches
<n3hima> does anyone know of a way do extract a partition image from a disk image
<Treenaks> n3hima: http://tuxinarow.com/2006/12/27/loopback_mountin_a_specific_partition_inside_a_disk_image ?
<n3hima> Treenaks, thx v much
<Treenaks> n3hima: It was a simple google query...
<n3hima> hmm
<n3hima> sorry
<amitk> StevenK: NCommander:  1.9Mb?
<NCommander> amitk, the directory rename
<NCommander> amitk, really bloats a diff up REAL nice
<persia> amitk, directory name change means that there's *lots* of duplication.  git supports rename, so git change would be much smaller.
<amitk> NCommander: could you just send me the git diff. I don't care too much about debdiff...
<NCommander> amitk, yes sire
<amitk> NCommander: thanks.
<amitk> NCommander: this will be on top of what is already in git, or on -4.7?
<NCommander> Its a replacement for the last commit I gave you
<NCommander> (reset that diff, and then put this in that place)
<amitk> NCommander: ooh...
<NCommander> yeah
<NCommander> Hold on
 * amitk hopes it is against e3a18175deaed9f2af0b7694e44e6dd686906f1e in the git tree
<NCommander> amitk, nope
<NCommander> amitk, its a one line change from that
<NCommander> If you want, I can do that
<NCommander> or tell you specifically what to change :-)
<NCommander> amitk, I sent a patch that susposed to replace e3a18175deaed9f2af0b7694e44e6dd686906f1e
<amitk> NCommander: ok... I'll diff it just to be sure.
 * NCommander hugs amitk 
<NCommander> THis is motivation to get me an account so you don't have to constantly merge in patches
 * amitk thanks NCommander for his hardwork and promises him a beer if he is at UDS
 * NCommander isn't 21 ;.;
<amitk> then root beer for you :-p
<Mithrandir> or you can come to a real country where you're allowed beer before 21.
<Mithrandir> ;-)
<NCommander> Mithrandir, cheaper to wait for 21
<amitk> Mithrandir: true
<lfaraone> Hey, there are a collection of GPL'd documentation for a variety of software included in Ubuntu at flossmanuals.net, I'm wondering how to go about packagign them for ubuntu and whether to make them a separate package from the projects they document. (sabdfl sent me here)
 * NCommander asks that someone flog me
 * lfaraone flogs NCommander 
<NCommander> sweet
<NCommander> I made a joke involving race conditions and a proof about P=NP :-P
<persia> lfaraone, I'd recommend starting with a few cluster packages for related stuff, and working with all the upstreams to get the documentation for their stuff included.
<persia> Once each thing is included upstream, it can be split out as foo-doc in the packaging, and removed from the combination package.
<NCommander> persia, so StevenK got the linux-lpia patch
<NCommander> its fixed
<NCommander> finally
 * NCommander feels his brain melt
<persia> This is somewhat similar to that being done with ia32-libs : where some libraries are being updated to build 23-bit and 64-bit variants, and dropped from the combination package.
<persia> NCommander, Don't we still have a few hours to wait until it hits the right count of publisher cycles and everything rebuilds?
<NCommander> persia, that's for my sponsor to worry about. Once I'm an MOTU I'll worry about that bit ;-)
 * NCommander runs
<persia> Well, actually, linux-lpia is in main, so being MOTU doesn't make any difference.  That said, what one worries about ought have little relation to ones entries in an ACL : it's about what is interesting.
<NCommander> persia, ok, core-dev
<NCommander> persia, I'm sorta worried about sleep. By time I wake up, it should have all automagicially resolved itself ;-)
<persia> NCommander, Again, no, it shouldn't matter.  If you change something, you've told the world you're responsible for that change, so it's worth making sure that anything else that needs doing is done, rather than counting on a sponsor.
 * NCommander has to file a bug against ubuntu-mid about their daily image
<persia> What's wrong with the ubuntu-mid daily image?
<lfaraone> persia: so we'll have "flossmanauls-collection" which will include all the unassociated docs, and evrentually we'll have separaet "inkscape-fm-doc" etc packages?
<NCommander> The lack of X11 working on install
<persia> lfaraone, Or just inkscape-doc, if you can build the right spirit of collaboration.
<NCommander> persia, I'm being sacastic. I realize that for any changes I make, I'm responsible for the resulting breakdown of the universe
<lfaraone> persia: ah, kk. (in that spesific case, inkscape was the group that commissoned those docs, so yeah, that'd work)
<persia> NCommander, Which package is missing?
<NCommander> persia, I dunno. I can startx to a grey screen
<lfaraone> persia: and we'd just make -doc a Reccomends: of inkscape?
<NCommander> persia, I install it just fine, but I get dumped to a command line
<persia> NCommander, I suspect it's an issue with something other than the image.  The image is responsible only for making sure certain packages get deleted on install (see http://paste.ubuntu.com/59306/)
<persia> Which username are you using?
<NCommander> persia, the one I set during install?
<NCommander> persia, no, X11 doesn't come up period
<NCommander> I get a terminal login prompt
<persia> NCommander, RIght.  I suspect you want to file a bug against ubuntu-mid-default-settings that it doesn't work if the username isn't "ubuntu".
<persia> I don't think it's an image problem.
<NCommander> Ok, I shall do that
<NCommander> persia, I'm just happy linux-lpia is resolved :-)
<persia> NCommander, Create an "ubuntu" user and reboot to verify I've guessed the right bug.
<NCommander> persia, why would it be dependent ont he existance of an ubuntu user?
<persia> NCommander, read /etc/event.d/session
<NCommander> persia, what priority would you mark that? I guess its low since normal users won't see it, but I'd like a second opinion
<lfaraone> Are dates appropreate for version numbers of packages?
<lfaraone> (Docs0
<persia> NCommander, I'd call it medium.
<NCommander> persia, yup, your right
<persia> lfaraone, best to use a numerical format like 20081230 so it's guaranteed not to have issues (Nov10 > Dec15)
<lfaraone> persia: Ok.
<NCommander> persia, bug filed :-)
<persia> NCommander, Cool.  Be jaunty before it's fixed, but handy to have for reference.
<NCommander> persia, Ubuntu mobile looks pretty cool
<NCommander> If I buy a freerunner
<NCommander> Beware of port
<pwnguin> isnt the freerunner arm?
<lfaraone> pwnguin: yeah
<pwnguin> that seems incompatible with mobile stuff / ubuntu
<NCommander> pwnguin, like I said
<NCommander> beware of port
<NCommander> I AM crazy enough to port Ubuntu to bring -mobile/-mid to the freerunner
<pwnguin> NCommander: last i knew, mobile had a flash component
<pwnguin> NCommander: is the -mobile stuff installable via package & regular ubuntu yet?
<NCommander> no idea
<tseliot> pwnguin: you can install ubuntu-mobile
<persia> pwnguin, mojo.handhelds.org
<persia> pwnguin, Also, intrepid has everything you'd expect for ubuntu-mobile and ubuntu-mid.  Nothing external.
<pwnguin> persia: ah; i got frustrated with the xephyr / chroot setup
<persia> pwnguin, Yes, that's just pointlessly broken.  Use kvm, vbox, or some other virtualisation if you want to run it as a guest on your normal workstation.
<pwnguin> i'd rather run it installed alongside my other stuff, but apparently this is not in the cards?
<lfaraone> Hey, what package contains the Ubuntu keyring?
 * james_w guesses ubuntu-keyring
<pwnguin> alrighty. enough embedded stuff, at least until my Pandora arrives in December
<ogra> nah, thats likely a trick question :)
<lfaraone> Lol.
<pwnguin> i got a complaint from upstream that the libgnomecanvcas shipped in ubuntu is broken
<lfaraone> I have a feeling that bug 283890 will be a wontfix, am I right?
<ubottu> Launchpad bug 283890 in ubuntu-keyring "put medibuntu's pgp key / keyring into ubuntu.org official repo" [Wishlist,Confirmed] https://launchpad.net/bugs/283890
<LimCore> could we allow to access medibuntu-keyring in ubuntu.org repos?  Just keyring, its legal;  It will close a possible security hole (how you know medibuntu keyring was not spoofed when you download it unsigned by ubuntu)
<pwnguin> legal rammifications aside, i dont think it's a good idea to place keys from 3rd parties in by default
<pwnguin> LimCore: the question is, should we trust medibuntu by default?
<LimCore> no legal rammifications, just the key ring.  So the reason is that ubuntu developer can not trust medibuntu developers enought to sign it?
<LimCore> pwnguin: dunno... I thought it was lead by trusted people asociated with ubuntu
<lfaraone> LimCore: it's a potential MOTM attack.
<lfaraone> LimCore: if you install it by default.
<james_w> man on the moon?
<LimCore> mitm attack?  man in the middle?   my idea is exactly to avoid mitm
<jdong> it does NOT belong in ubuntu-keyring
<jdong> I'd have no objection to having a medibuntu-keyring package in Ubuntu
<LimCore> jdong: this is exactly what I said
<jdong> but I do not want medibuntu's key as a part of the central Ubuntu keyring
<LimCore> yes
<LimCore> ok, so lets do it \o/ ?
<jdong> sure, jaunty.
<LimCore> well ok
<pwnguin> I wonder if that would be contributory patent infrigement
<jdong> haha does such a thing exist?
<pwnguin> yes
<jdong> accessory to patent infringement
<pwnguin> http://en.wikipedia.org/wiki/Patent_infringement_under_United_States_law
<NCommander> o_O;
<NCommander> I
<NCommander> ...
<NCommander> No comment
<pwnguin> 35 U.S.C. Â§ 271(c), or "contributory infringement," is triggered when a seller provides a part or component that, while not itself infringing of any patent, has a particular use as part of some other machine or composition that is covered by a patent.
<pwnguin> obviously wikipedia is not legal council
<LimCore> lol
 * LimCore loves USA... the Freedom country. lol yea
<jdong> well I still don't think medibuntu's keyring falls under that.
<jdong> I remind you that libdvdread contains a script that directly fetches medibuntu's css package.
<pwnguin> heh
 * LimCore sends troops to arrest all the evil patents terrorist from ubuntu
<pwnguin> im just suggesting that maybe it's not cut and dried. canonical being incorporated in an offshore island territory helps them a bit i suppose
 * LimCore back to back reporting - xorg crashes epically on intell in 8.10 up to date
<pwnguin> there's also the fact that medibuntu provides some packages offensive to ~50 percent of the target userbase
<Lutin> e.g. ?
<pwnguin> http://packages.medibuntu.org/intrepid/hot-babe.html
<Lutin> sigh. no one forces anyone to install it. ubuntu has firefox, too. which can offense potentially 100% of the userbase, as it allows access to internet.
<lfaraone> pwnguin: 50? bah. I think you're underestimating people's level of offense.
<pwnguin> i'm just trying to give a complete picture of the relationship between medibuntu and ubuntu proper. i can't say which parts are relevant from a key perspective
<mr_pouit> pwnguin: the key is used to sign the Release.gpg files, nothing moreâ¦
<lfaraone> So we can make it a medibuntu-keyring package.
<pwnguin> http://packages.medibuntu.org/intrepid/medibuntu-keyring.html
<pwnguin> on a related note, is it too hard to manually include a key?
<lfaraone> Remind me, what's the package that ubuntu uses akin to WNPP in debian?
<lfaraone> pwnguin: it's a security risk, you're downloading it over an unsecured line.
<lfaraone> w/o auth
<pwnguin> lfaraone: so use https
<LimCore> pwnguin: lol?
<LimCore> pwnguin: medibuntu uses real ssl cert? like from cacert?
<pwnguin> LimCore: why not?
<LimCore> The certificate is not trusted because it is self signed.
<LimCore> The certificate is only valid for zeus.flosoft.info
<LimCore> The certificate expired on 10/09/2008 09:08 PM.
<LimCore> wow, that really helped.
 * LimCore fells secure now
<jdong> frankly if you use medibuntu you should not be worrying about security.
<jdong> who the hell are making the packages?
<jdong> are they in a verifiable build system such that the sources are turned into the binaries you see?
<jdong> who maintains the server that it's hosted on?
<pwnguin> jdong: i think you've got it backwards. if you care about security, don't use medibuntu ;)
<lfaraone> jdong: well, the medibuntu team.
<LimCore> most desktop media users will get medibuntu
<pwnguin> but yes, those are the core reasons to not trust medibuntu
<LimCore> its huge user base.  we should consider this
<lfaraone> jdong: https://launchpad.net/~medibuntu-maintainers/+members
<jdong> lfaraone: I know that.
<LimCore> perhaps ubuntu should start another company (for legal resons), that would be trusted,  and they will run "officiall" medibuntu
<LimCore> it is lead by trusted people from ubuntu staff? well, seems fine to me
<pwnguin> lfaraone: you've already seen two of them speak here
<jdong> oh great... more flash md5sum fun.....
<pwnguin> ttps://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/284530
<pwnguin> bah
<pwnguin> http://bugs.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/284530
<ubottu> Launchpad bug 284530 in libgnomecanvas "Writing in xournal lags or doesn't complete and selection boxes render incorrectly" [Undecided,Confirmed]
<pwnguin> i hope it's not too late to fix that
<jdong> needs https://bugzilla.novell.com/attachment.cgi?id=242687 that patch?
<LimCore> we have crashes on intel gfx card(s?) under openGL load.  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/285298
<ubottu> Launchpad bug 285298 in xorg "intell gfx glitches: on X3100 GM965/GL960, freez when running few openGL applications - Error in I830WaitLpRing(), timeout for 2 seconds, Ring at virtual 0x7f5c1d6c0000 head 0x0 tail 0x100 count 64" [Undecided,New]
<LimCore> if I can help more to debug it a bit, let me know :)   bl.
<jdong> it would be more helpful if you attached logfiles so the discription isn't a 5 page register dump.
<LimCore> jdong: the log file in 150 mb.   but ok I will attach the shortened version and remove it from descr
<pwnguin> jdong: yes, it seems
<jdong> yes, that's what I meant. thanks.
<asac> hmm ... no sound on my X61 speaker :/
<jdong> pwnguin: do we have any confirmation that fix works?
<james_w> pwnguin: isn't that bug a dupe?
<jdong> pwnguin: it's not too late to fix the bug but it's probably too late to play the *upload* "are the lights on yet?" game.
<james_w> ah, no
<pwnguin> jdong: there's confirmation the patch works in suse. nothing tried on ubuntu yet
<james_w> the fix has been accepted upstream
<pwnguin> im not sure what all patches are applied yet. i just started looking at this
<avb> guys, im examining boot procedure of ubuntu
<avb> i filled some bugs
<avb> but im wondering
<avb> what the point to load bunch of modules with modprobe at boot time on each pc instead of compiling them into kernel?
<avb> im talking about /etc/init.d/acpid and /etc/init.d/powernowd
<avb> they modprobing like 15 modules
<avb> i convert acpid to use insmod to reduse load time, but its not that easy to do in powernowd, coz modules there have dependencies
<avb> once this modules will be builtin into kernel, we will save about 1-2 seconds at boot
<amitk> avb: these issues are already known and on the agenda to be fixed for Jaunty. You should attend UDS or participate in the teleconf in December if you would like to participate in the discussions.
<avb> amitk: unfortunately im located not in US or Europe :)
<avb> and its a bit hard to get visa for me
<avb> at least that nice, that problem is known
<amitk> avb: you can still call into various sessions of the UDS. Schedule will be published closer to 8th Dec.
<avb> originaly im from belarus, but now im in dominican republic, caribbean
<avb> maybe Mark can fund UDS summits on the boards of caribbean sea? :)
<avb> anyway, we will see. thanks for the info
<doggymenz> when someone fix http://start.ubuntu.com/8.10/ so it say 8.10 instead of 8.04 ?
<mdke> doggymenz: the website team is working on updating that page in time for Ubuntu 8.10
<doggymenz> ok, i want it get updated fast
<doggymenz> so i can whine at them, if they do it wrong
<doggymenz> somene tried sneak in an ugly wallpaper
<doggymenz> but luckily we caught it, whined, and it got fixed, now we got a very pretty one
<mdke> I preferred the previous one, myself.
<mdke> anyway, no, you don't get to do that with this webpage, but you can of course subscribe to the webteam mailing list and participate in the discussions there
<mdke> it's not whining, but it's second best
<doggymenz> i think they should set up the page now, as per open source tradition "release early, release often"
<doggymenz> because 8.04 sucks, it has google search, but it goes to .uk for all users, even those who not .uk
<RainCT> mdke: uhm.. that page isn't displayed correctly on epiphany
<RainCT> mdke: the "Ubuntu Merchandise" entry is not aligned with the other ones, unless you increase the text size
<RainCT> and in Firefox two of the images get a weird border if you decrease the size o_O
<mdke> RainCT: feel free to report that as a bug, I have a bad memory at the best of times, let alone for stuff I don't work on
<RainCT> mdke: against which product should I fill it?
<mdke> ubuntu-website
<RainCT> ubuntu-website?
<RainCT> ok
<mdke> the page is getting a complete redesign from what I've read, but I don't know if that will be ready for 8.10, so it's worth filing bugs for the existing version
<doggymenz> gnome start menu is much easier than kde
<doggymenz> kde is slow and confusing to navigate
<Plagman> hey
<Plagman> my wireless adapter stopped working after upgrading to intrepid
<Plagman> getting "rt2x00lib_request_firmware: Error - Failed to request Firmware." errors when trying to bring the interface up
<Plagman> is this a known problem?
<james_w> Plagman: install linux-firmware
<james_w> Plagman: I think you just got unlucky with the time you upgraded
<Plagman> oh.
<Plagman> installing now
<Plagman> sweet
<Plagman> worked
<Plagman> thanks a lot
<Plagman> so it was just a temporary gap in the dependencies on the intrepid repositories and I was unlucky enough to dist-upgrade right then?
<james_w> I think so
<james_w> I got hit too
<james_w> the -generic image depends on it, but I think we upgraded before that caught up
<james_w> unless you don't have that installed
<Plagman> I think it's installed
<directhex> depends or recommends?
<Plagman> anyway, thanks for the tip
<james_w> depends
<Plagman> time to unplug the good ol' rj45, see ya
<Plagman> thanks again for the tip, I wouldn't have figured that out right away :)
<calc> nomination appears to be broken on LP
<calc> slangasek: bug 278943 (i can't seem to approve nomination
<ubottu> Launchpad bug 278943 in openoffice.org-dictionaries "Spellchecking doesn't work in Pidgin and Tomboy with LC_ALL=fr_CH.UTF8" [Undecided,New] https://launchpad.net/bugs/278943
<wgrant> calc: You don't get an "(approve/decline)" button on the nomination line?
<persia> Could an archive-admin please reject linux-rt 2.6.27-3.6 from unapproved?  I'll be pushing 2.6.27-3.7 fairly soon (3.6 works against 7.11, but FTBFS against 7.12), so there's no advantage to keeping this one.
<slangasek> persia: done
<persia> slangasek, Thank you.
<calc> wgrant: i do and it keeps giving me launchpad errors
<calc> wgrant: er whenever i click approve
<wgrant> calc: OOPSes?
<calc> wgrant: i suppose so
<calc> wgrant: looking at the bug again
<wgrant> calc: Lovely. See if somebody else is able to do it.
<calc> wgrant: gives me (Error ID: OOPS-1022F2097)
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1022F2097
#ubuntu-devel 2008-10-19
<calc> hmm it can't find the oops yet
<calc> er via that url
<wgrant> Ah, I guess you might be able to do something useful there with your credentials.
<wgrant> You'll need to wait up to 5 minutes for it to appear there.
<calc> well i have access to it, it just said nothing was there yet
<wgrant> calc: It's probably worth seeing if you can see it now.
<calc> oh its there now
<wgrant> I think it's on */5.
<calc> says TimeoutError
<wgrant> Oh dear.
<wgrant> It's reproducible?
<calc> yes
<calc> every time i have tried to do it oops on me
<wgrant> Over how long has it been doing this?
<calc> today
<calc> at least 2-3 hr i would guess
<wgrant> Lovely.
<calc> i've tried it probably 4-5 times for that one bug
<wgrant> I wouldn't have thought that would be a particularly DB-heavy operation, really.
 * persia suspects it to be ~ 12 hours
<calc> i have to leave now though, headed out to school reunion
 * calc bbl
<Hobbsee> LimCore: please keep all discussions about the US, and patents, away from ubuntu development channels.  We have a release to do, and do not need you soapboxing.  If i see you do again, you'll get a holiday from both here and -motu.
<jtisme> how do i mount internal floppy in 8.10  automount not in fstab
<Hobbsee> jtisme: this isn't a support channel.
<jtisme> ok thanks
<pwnguin> i wonder if bootchart should be saving pngs instead of svg
<pwnguin> i've got like 150 megs of bootcharts since dapper
<pwnguin> it would be neat to graph out the trajectory of boot speed over time, but that'd be hard with pngs =(
<NCommander> StevenK, now that I see linux-lpia in the queue, does that mean we're making progress?
<NCommander> StevenK, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux-lpia-meta/+bug/284368 - want me to tackle this?
<ubottu> Launchpad bug 284368 in linux-lpia-meta "linux-lpia-meta needs to depends on linux-firmware" [Critical,New]
<StevenK> NCommander: No, it's fine
<wgrant> calc: You should be able to approve that nomination now that LP is fixed.
<NCommander> StevenK, know any good RC bugs that could use a hand?
<NCommander> StevenK, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux-ports/+bug/213668 - if I cook a patch for this, would upload? (the fix was already SRUed, it simply needs to be repeated for Intrepid)
<ubottu> Launchpad bug 213668 in linux-ports "Hardy: please enable PASEMI_MAC for powerpc64-smp" [Medium,Fix committed]
<calc> wgrant: ok, just got back home
<ScottK> StevenK or slangasek: Would you please accept libspf2.  I have one rdepend I need to upload for a rebuild after it's built/published (this is the one we discussed at the last release meeting).
<StevenK> I'm no release team member
<ScottK> Ah.  Right.  Got the roles confused.  Sorry abou that.
<slangasek> StevenK: it's in universe though, and ScottK /is/ motu-release, so he's allowed to ask archive folks directly for approvals :)
<StevenK> Fair enough
<slangasek> I'll grab it in a sec, anyway
<StevenK> slangasek, ScottK: Accepted
<ScottK> StevenK: Thanks.
<ScottK> slangasek: I'll have a Main upload I can ask you about here in a few minutes.  Just so you don't feel left out ...
<StevenK> Hehe
<slangasek> :-)
<NCommander> StevenK, did you get an ack from ubuntu-release on linux-lpia?
<StevenK> NCommander: Yes, it's building.
<NCommander> YAY
<NCommander> that makes me happy
<ScottK> slangasek: Would you please accept kdebase.  Its a two line patch and it makes it so you can actualy create a working new user via KDE.
<ScottK> There.  Now it's even.
<slangasek> kdebase, or kdeadmin?
<ScottK> slangasek: Bah.  Right.  kdeadmin.  Sorry.
<slangasek> done
<ScottK> slangasek: Thanks.
<pochu> slangasek: thanks for the sponsorship!
<lool> persia: only seeing your question now and lastlog is short
<lool> yeah I care to upload linux-lpia
<pzn> I'd like to report a wishlist bug: when screen is locked, the keyboard buttons volume-up volume-down suspend and some others could work without unlocking the screen. to which package should I post this kind of wishlist?
 * RainCT doesn't know but thinks that that's a nice idea :)
<ogra> there is a bug already somewhere
<ogra> a quite old one
<ogra> look for "media keys" among the gss bugs
<ogra> (gss -> gnome-screensaver)
<pzn> ogra: thanks
<zul> 2cheeks
<scuser> how to redirect simple bind authentication is redirected to saslauthd ?
<scuser> how to redirect simple bind authentication to saslauthd ?
<james_w> release team: bug 269651 isn't release targeted, but it has a lot of subscribers and duplicates, and is a pain for those who get hit, as they lose some desktop functionality until they restart their session. Would you accept and upload of my proposed patch to fix it?
<ubottu> Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [Medium,In progress] https://launchpad.net/bugs/269651
<jspiro> hi all.  Idea:  the desktop editions of *buntu should check at startup if the computer's clock is way off.  If it is, it should automatically retrieve the correct time using Internet time service.
<NCommander> jspiro, submit it to brainstorm
<cjwatson> ntpdate is already in minimal
<jspiro> NCommander:  i will file a bug.  but wait, there's more
<cjwatson> and comes with an /etc/network/if-up.d/ script
<cjwatson> if that isn't working, it's a bug, not an "idea"
<Hobbsee> i wonder if that's compatible with the new NM world order.
<jspiro> cjwatson:  ah, i didn't know my idea was already implemented.  thanks for pointing that out :)
<cjwatson> yes, I don't know what NM does with /etc/network/if-up.d/, if anything
<jspiro> cjwatson, Hobbsee, I am going to irc.gnome.org to ask.  (Btw I am the same person as "unfo".  I have registered both nicks.)
<Hobbsee> jspiro: wouldn't be that hard to test out, actually.
<jspiro> I don't have network-manager installed on this PC.  It is a Debian PC with KDE.
<jspiro> (I got my idea when my hacker friend told me about a computer with noob owner whose clock was wrong, and the owner kept getting Firefox "certificate not yet valid" errors.  I suspect it was a Windows computer.)
<jspiro> cjwatson, Hobbsee, http://kutuma.blogspot.com/2007/11/changing-default-gateway-using-network.html seems to me to *probably* imply that network-manager executes if-up.d scripts.
 * Hobbsee eyes cjwatson
<jspiro> Hobbsee: why did you eye him? :)
<cjwatson> (connection fixed)
<Hobbsee> oh, finally
<Hobbsee> wonder why she didn't come to -ops and tell us that.
<cjwatson> don't know, she /msged me for help
<Hobbsee> ah well.  guess i'll find out soon :)
<Hobbsee> (and hurrah for sucky connections!)
<cjwatson> jspiro: implies that, in that particular release of Ubuntu, if-up.d scripts were executed when using network-manager
<cjwatson> that could be due to NM indirecting through something that executed them, rather than executing them itself. At any rate this is speculation; somebody should check.
<jspiro> cjwatson: ok I will ask in channel #nm (it's right here on Freenode)
<jspiro> what should i ask?
<jspiro> all : how's this?  "Do all versions of NetworkManager always run the scripts in if-up.d at every bootup?"
<cjwatson> no, you should try it
<cjwatson> on current Ubuntu
<jspiro> cjwatson: all I have is 8.04
<jspiro> I don't have a wireless card
<cjwatson> please don't ask network-manager upstream how network-manager behaves in Ubuntu
<cjwatson> it's inappropriate and will just annoy people
<jspiro> cjwatson: ah.  fair
<jspiro> is 8.04 and no wireless card good enough for testing?
<cjwatson> I have no idea
<jspiro> oh btw we forgot modem users
<cjwatson> perhaps somebody else will have some time to help out
<jspiro> I wonder if modem users' PCs run if-up.d scripts at login time
<jspiro> *ppp_up time
<Hobbsee> james_w: that probably should be release targetted.
 * Hobbsee pokes it
<james_w> thanks
<jspiro> someone in #kde-devel said I am being annoying.  am I?
<jspiro> *was I
<jspiro> I mean was I here
<RainCT> heh
<jspiro> RainCT: I mean was I annoying here before I corrected myself twice :)
<RainCT> dunno, I wasn't reading :)
 * Hobbsee mutters at nutcases on planet
<Hobbsee> yeah, really, 11 days before release is a *great* time to decide to start a spec to get mono out of intrepid.  not!
<sebner> Hobbsee: PATENZ FUD
<Hobbsee> sebner: probably.  I'm just stunned people still want to make contraversial changes like that at this point...
<jspiro> Hobbsee:  I have no clue if mono is good or bad.  But are they saying it should be removed from *Intrepid*?
<sebner> Hobbsee: well, maybe some think. let's discuss and 2 days later everthing is fine and finished
<Hobbsee> jspiro: yup.
<Hobbsee> sebner: yay, clueless people! But yes.
<jspiro> Hobbsee: oh :(
<NCommander> Hobbsee, link?
<Hobbsee> NCommander: planet ubuntu
<jspiro> IMO someone official should tell them there is no point trying to get it removed from Intrepid because the release is too soon.
<Hobbsee> jspiro: i've already done that...
<jspiro> Hobbsee: ah, I see your comment at http://gquigs.blogspot.com/2008/10/language-leadership-i-actually-gave-up.html#c5045436021106559200 - it was kind of you to do that.  I wonder what the original poster will respond.  :)
<scuser> hi all, I've disabled simple authentication using the configuration "security simple_bind=64" in the slapd.conf, but the system refuses to login although I can obtain tickets for the same user which I'm trying to login with and that user is in the ldap database and I can login using it when the binding method is simple; here is what kerberos logs produces http://paste.ubuntu.com/59709/ any...
<scuser> ...help please ?
<geser> scuser: this is not a support channel, please try #ubuntu
<kirkland> slangasek: hiya, could you please review the patch attached to https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/ecryptfs-utils/+bug/272232
<ubottu> Launchpad bug 272232 in ecryptfs-utils "passwd - passwords do not match but updated successfully" [High,In progress]
<kirkland> slangasek: it fixes both 272232 and bug #259293
<ubottu> Launchpad bug 259293 in ecryptfs-utils "Ecryptfs Private Directory Randomly Unmounts" [High,In progress] https://launchpad.net/bugs/259293
<kirkland> slangasek: jdstrand has reviewed it, and I have incorporated his suggestions and tested it
<jdstrand> kirkland: did you see my comment about decrement()?
<lfaraone> Hey, kinda important bug (from a legal standpoint): bug 285469
<ubottu> Launchpad bug 285469 in firefox-3.0 "XML Parsing Error: unclosed token when clicking on "Know your rights" button" [High,Confirmed] https://launchpad.net/bugs/285469
<sroecker> I need help with bug 250425, it's actually a gcc bug
<ubottu> Launchpad bug 250425 in zsnes "zsnes crashes with buffer overflow on startup" [Medium,Triaged] https://launchpad.net/bugs/250425
<james_w> lfaraone: hey, please ask if they restarted firefox after the upgrade.
<james_w> lfaraone: or do you see it too?
<RainCT> I guess the nominations on bug #268996 can be rejected
<ubottu> Launchpad bug 268996 in nmap "Update nmap to version 4.75" [Wishlist,Fix committed] https://launchpad.net/bugs/268996
<lfaraone> james_w: I see it too.
<lfaraone> Oh, and what's the best way to package docs in docbook format? (where do I put them in the FS)
<lfaraone> (for use with Yelp and the kde help ssytem)
<drH0use> perchÃ¨ Ã¨ sconsigliato installare oo3?
<cjwatson> lfaraone: thanks - marking as release-critical
<lfaraone> cjwatson: thanks.
<a11en> I need to load my network card to ubuntu, but I don't have the driver-cd. Is there anyway I can pack it up on Vista and since Ubuntu is on the same partition reach into the backup file and load it that way?
<ScottK> a11en: Support is in #ubuntu or #ubuntu+1 (for Intrepid).
<ogra> mumble ....
<ogra> why did my webcam vanish
<james_w> ogra: a gspca one?
<ogra> james_w, uvcvideo
<ogra> but it seems to be simply gone
<ogra> nothing shows it anymore
<james_w> ah, ok, that I know nothing about
<ogra> not even if i load the module its discovered
<directhex> not in lsusb?
<ogra> its really weird
<ogra> nope
<ogra> not even there
<directhex> then it's just plain not detected
<ogra> if the laptop wouldnt be that new i would think its actually broken
<directhex> shows up plugged into a different pc?
<ogra> its integrated in the LCD :)
<directhex> oh. um... rebooting doesn't help? nothing in dmesg about attempted usb handshakes?
<ogra> it worked in hardy beta and thats actually when i used it last time
<ogra> i would have thought i dreamed i used it but there are stored pics and test movies in cheese :)
<ogra> and i just tried to use it again on friday
<ogra> so i dont even know when it vanished
<directhex> it might be fluke that it's not working now - the lack of metion on lsusb is serious. much moreso than nothing from uvcvideo
<directhex> it should show up on lsusb even if there are 0 drivers
<ogra> i know
<ogra> i'm not sure though it is even attached to usb ...
<ogra> it might be attached to some PCI bus, ot to the internal firewire
 * ogra makes a note to store lspci and lsusb next time he buys a new system
<ogra> lshal obviously shows an unknown button with info.product=Video Bus
<ogra> (no its not the lid switch)
<ogra> and apparently hal decided to apply keyboard settings and evdev to it because it has button in its input.capabilities
<stgraber> ogra: and you have it working when botting an hardy livecd ?
<ogra> no
<ogra> thats the fun
<stgraber> did you do a BIOS update recently ? (sounds like broken ACPI)
<ogra> nope
<ogra> and the BIOS has no option to switch the cam on or off
<ogra> the hardware is like i bought it, didnt change a thing
<ogra> and the most funny thing is:
<ogra> ogra@osiris:~$ lshal|grep camera
<ogra>   access_control.type = 'camera'  (string)
<stgraber> yeah ...
<ogra> ... belongs to a
<ogra> udi = '/org/freedesktop/Hal/devices/fuse'
<ogra>   access_control.file = '/dev/fuse'  (string)
<ogra>   access_control.type = 'camera'  (string)
<ogra> :P
<stgraber> I also have this one but I have no camera in my laptop
 * ogra doesnt really get why fuse is access_control.type = 'camera'
<ogra> might be a libgphoto thing though
<stgraber> yes, so that also means your system doesn't see your webcam at all (as I also get that on a system without a webcam)
<ogra> i think the unknown button attached to the video bus with keymap settings applied might be the cam though
<ogra> well
<ogra> have a look at that device
<ogra> http://paste.ubuntu.com/59880/
<stgraber> ogra: I have the same here :(
<ogra> oh
<stgraber> ogra: http://paste.ubuntu.com/59881/
<stgraber> except the keyboard layout is fr_CH and not de_DE :)
<ogra> i dont get why hal applies keymap and friends to it ... it shouldnt
<ogra> yeah
<stgraber> well, in my case I'm sure it's not a webcam so I don't quite get why hal would say "Video Bus" for a keyboard
<ogra> yeah
<ogra> do you have any special buttons ?
<ogra> i have two, one for rotation of the touchscreen and one as a virtual mouse button if i use the convertible tablet mode
<stgraber> I have some multimedia things (sound level, mute, information center (?) and presentation) but these are mapped to standard keycodes
<ogra> GEEEZ !!!!
 * ogra found his camera
<ogra> !!
<stgraber> oh, where was it ? :)
<ogra> hidden in an unnamed fn-F key sequence you can toggle its power on/off
<stgraber> oh
<ogra> there is no icon on the F10 key for it
<ogra> i just fund the combo in the handbook
<ogra> all other fn key sequences have a little blue icon on the F keys
<stgraber> ogra: btw, what do you think of the MSI WInd ?
<ogra> nice device
<ogra> though i would invest the 150â¬ to get a clevo 120 :)
 * ogra really really loves clevo lappies
<ogra> stgraber, http://www.clevo.fr/index1.html
<ogra> look at the tn129r
<ogra> err
<ogra> tn120r
<stgraber> oh, looks good
<stgraber> and cheap for that kind of device
<ogra> thats waht i'm using atm :)
<ogra> just know the webcam is switched on with fn+f10 :)
<stgraber> :)
 * ogra does a reboot to see if the module is detected properly
<ogra> hmm, cheese doesnt really get along with it anymore
<ogra> but ekiga does :)
<ogra> hmm, gstreamer doesnt seem happy either
<ogra> hrm
<TheMuso> slangasek: re bug #273507, I'l look into adding the gconf schema referenced to our existing package. While the ubuntu theme doesn't have such sounds defined for windw actions, other themes that people use may.
<ubottu> Launchpad bug 273507 in libcanberra "No sound effects play when "play sound effects when buttons are clicked" is enabled" [Undecided,Confirmed] https://launchpad.net/bugs/273507
<TheMuso> pitti: Demoting festival is fine by me. As for flite, why do you want it in main? IMO its not needed, as espeak covers the vast majority of use cases.
<james_w> ogra: make sure you have latest gstreamer-plugins-good0.10, an ubuntu2 one, the v4l patch was accidentally dropped in ubuntu1
<ogra> james_w, i upgraded 1h ago
<ogra> i think the latest came in there
<ogra> but cheese doesnt show anyhing and locks up after a while
#ubuntu-devel 2009-10-12
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Launchpad bug 448918 in cryptsetup "Insecure Cryptsetup defualts" [Undecided,New]
<slangasek> mdke: status on the wiki> no, I don't think editing a wiki is a good way to keep track of that stuff, I track it locally instead
<Darxus> Is there a way to monitor packages in debian type archives for new versions (other than throwing a few lines of perl together myself)?
<superm1> pitti, using http://pastebin.com/f95b5c26 and this apport package hook http://pastebin.com/f350d087e I was still redirected into the normal source package area rather than the mythbuntu product on launchpad https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/449181
<ubottu> Error: This bug is private
<superm1> it let me file a bug surprisingly even though it's not a genuine source package though
<ScottK> slangasek: I saw your bugmail on emacs23.  Seems at least slightly impolite.
<slangasek> ScottK: yes, I'm at least slightly annoyed that no one took responsibility for checking the set of packages emacs23 was generating, and we now have to do stupid version tricks to get emacs installable again
<ScottK> I can imagine.
<LaserJock> was it assumed that emacs23 was going into Main and taking over for emacs22?
<ScottK> LaserJock: No.
<slangasek> no, it was explicitly approved as a universe-only FFe
<ScottK> Several of us didn't catch it.
<LaserJock> hmm, I just wondered as the changelog says that the maintainer was set to Ubuntu Core Developers
<stooj> Is the rss feed on planet.ubuntu.com down?
<trip0> so i used to be able to auto login from /etc/event.d/tty1 using mingetty.  it doesn't seem to be working now?  Does this have to do with the conversion to upstart?
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Launchpad bug 448918 in cryptsetup "Insecure Cryptsetup defualts" [Undecided,New]
<ScottK> slangasek: If you didn't fix emacs23 already, I'll take it.
<vigo> Hello, I am subscribed to this letter/email and wanted to know if I erred in one of the posts?
<slangasek> ScottK: hadn't gotten to it yet - feel free (and thanks)
<ScottK> OK.  Thanks.
<vigo> I did suggest a Debian like install, where the user can choose the applications that they want at this time, MySQL, or not, Browser and so on, I have installed a few systems and I rather like the option to choose what goes in, after all, packages can be added after the initial install, so that makes sense to me?
<RAOF> vigo: General consesus has been that the (livecd) installer is the wrong time to choose applications.  For most users it's presenting a choice without any of the information needed for them to make that choice.
<vigo> RAOF: Thank you.
<RAOF> As you say, it's simple to install & remove software after the install; this allows for experimentation, while also having everything just work out of the box.
<vigo> That does make sense.
<vigo> It also helps the learning part of it.
<RAOF> I forget if the alternate installer lets you choose tasks.  It's been some time since I actually installed :)
<vigo> RAOF: Ubuntu does not really give choices like that. It is Language, Name, Partition, GO!
<vigo> Wich is neat
<geofft> The debian-installer does pop up a tasksel menu, just like Debian's. I netinst; I assume the alternate is the same
<vigo> geofft: I will be installing Kdeb later tonight and take notes, if I see anything of note, I will mention it, after that install I will be putting the backup of this dev on to test that.
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Launchpad bug 448918 in cryptsetup "Insecure Cryptsetup defualts" [Undecided,New]
<ScottK> crypt-0: Tossing bug links into the channel less than once an hour is rude and unlikely to improve your chances of getting a fix.
<crypt-0> ScottK, sorry, no one even acknowledged it
<crypt-0> i hope karmac doesnt plan on using SHA1 to hash its password, when SHA2 and whirlpool are available
<ScottK> crypt-0: Odds are the people most likely to do something about it get bugmail for the package.  It's late a night virtually everywhere Ubuntu devs work, so not getting a response on IRC shouldn't be much of a suprise.
<RAOF> It's only been 9 hours since you filed the bug.  What sort of response were you expecting?  I'd guess that many of the people who actually handle that sort of core package are still asleep in Europe.
<crypt-0> is karmac beta out now?
<ScottK> Yes
<crypt-0> is it tested on crypted systems?
<RAOF> Some people do, yes.
<crypt-0> mabye ill try it
<crypt-0> thought it want supposed to go beta for a week or so
<crypt-0> is there somewhere where i can take a hack at the automated crypto installer?
<crypt-0> id like to make one where you can choose the hash, cipher, and cipher mode
<RAOF> I'm not sure what, precisely, you mean by "hack" in that context.  "apt-get source cryptsetup" will get you the source + packaging for cryptsetup.
<crypt-0> im looking for the gui part in the alternate CD
<crypt-0> some sort of ncurses interface?
<RAOF> That'd be debian-installer.
<crypt-0> ok ill take a look and see if i can make it do what i want it to be able to, i can alread do whatever, with manual cryptsetup, or manual dm crypt etc. , this so the Joe PC user can Choose what to use
<crypt-0> i just find the defaults insecure, but then again what defaults aren't? However, when it comes to crypto, the defaults inst something i believe you should use
<RAOF> That's not an attitude we'd share around here; the defaults should be the right thing for as many people as possible.  With crypto, that's even more important because naieve fiddling with crypto almost always results in worse security.
<crypt-0> true
<crypt-0> but the defualts should be the 3 AES finalasts, Whirlpool, or SHA2
<crypt-0> essiv-cbc or xts-benbi
<crypt-0> any combination of that can not be insecure
<geofft> As a user, I have no idea what any of those are, other than a vague idea about SHA2. Is there a single suitable default?
<crypt-0> well there have been recent attacks on AES
<crypt-0> basically , SHA1 is broken, which is how your password is hashed by default
<dtchen> arguably once someone has access to the disk, you're up a creek anyhow
<crypt-0> password hash :sha256 cypher mode twofish-cbc-essiv:sha256
<geofft> yeah, I tend to treat /etc/shadow as if it contained a crypted pw
<crypt-0> dtchen, yeah, but its  better encrypted then not
<crypt-0> dtchen, in my bug report i describe a new feature in cryptsetup
<crypt-0> that wipes the key from ram on suspend/ sleep
<crypt-0> making cold boot less of a problem for laptop users, if your desktop gets cold-booted you have some home security issues to adress :)
<crypt-0> it works for desktops also
<[reed]> RAOF: *cough* Debian developers *cough*
<stooj> Jono, you there?
<ScottK> slangasek: emacs23 uploaded.
<vigo> ScottK: Ratso, I am still on Emacs22
<ScottK> vigo: emacs22 is the default supported emacs for Karmic.  We have 23 in Universe for people that want it.
<vigo> ScottK: Thank you, I am on Karmic development branch, I like testing stuff.
<slangasek> ScottK: cheers!
<crypt-0> Have there been major changes in the Linux Crypto API since juanty?
<TheMuso> cd
<TheMuso> woops
<lifeless> #ubuntu-devel
<crypt-0> yep, your here lifeless :P
<dholbach> good morning
<lifeless> crypt-0: I was reporting TheMuso's cd
<crypt-0> not filmilar with his CD, or him
<lifeless> crypt-0: read scrollback
<pitti> Good morning
<pitti> bryce: hi
<crypt-0> you thought your IRC client was a shell? :)
<crypt-0> its 2AM here and ive had 1 hour of sleep
<crypt-0> so im off..
<lifeless> crypt-0: no, I was making a joke.
<pitti> superm1: the "native package" check isn't applied if you set a custom crash database
<superm1> pitti, well shouldn't it have still been put against the product that i asked then?
<pitti> superm1: your is_ppa hook could be written much simpler, btw, but that's not the cause
<ebroder> Now that bug #429445 has an ubuntu-release ACK, do I need to subscribe the archive admins?
<ubottu> Launchpad bug 429445 in zephyr "[Karmic FFe] Sync zephyr 3.0~rc.2544-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429445
<crypt-0> Have there been major changes in the Linux Crypto API since juanty?
<lifeless> crypt-0: if you're tired go to sleep. You might want to mail the list you question (not that I'm sure anyone knows ;P)
<pitti> superm1: hm, at first sight the crash conf looks fine, let me try
<pitti> superm1: where did you put http://pastebin.com/f95b5c26 ?
<superm1> /etc/apport/crashdb.conf.d/mythbuntu-crashdb.conf
<pitti> superm1: /etc/apport/crashdb.conf.d/something.conf ?
<crypt-0> lifeless, ill just shoot a mail to the linux crypt mailing archive
<pitti> superm1: just for testing, does it work if you unconditionally set report['CrashDB'] in the hook?
<superm1> pitti, not sure, how do I trigger a "crash"?
<superm1> i know that report['CrashDB'] ended up in the resultant bug
<pitti> superm1: ^ oh!
<pitti> superm1: crash trigger> kill -SEGV <some process>
<pitti> superm1: but easier is "ubuntu-bug somepackage"
<pitti> it should work for bugs as well as for crashes
<pitti> superm1: right, bug, it doesn't remove CrashDB from the report
<pitti> but that's just a cosmetic issue, and it tells us that the hook worked
<superm1> so that's one bug, and the other is it not actually using that crashdb
<superm1> pitti, hm using ubuntu-bug got me even worse results
 * pitti tests locally
<superm1> i'm using apport-cli, and it told me to go to https://bugs.launchpad.net/None/+source/mythtv/+filebug/o0FTrYbT0dwUJEuotA1XXCYZqCy?
<superm1> which is certainly wrong
<pitti> https://bugs.edge.launchpad.net/none/+source/usplash/+filebug/3aqU0P3yTj1coNm2fS6NFZaF6yE
<pitti> indeed
<pitti> superm1: thanks, investigating
<superm1> cool, thanks
<dholbach> pitti: I'll unsubscribe the sponsors from the ibus syncs
<mdke> pitti: I've assigned bug 441401 to you because I wanted to get your view on it before making the change - hope that's ok!
<ubottu> Launchpad bug 441401 in ubuntu-docs "Symlink not working with Karmic translations" [High,Confirmed] https://launchpad.net/bugs/441401
<pitti> mdke: I'll have a look
<pitti> dholbach: they are done?
<dholbach> pitti: they have the sponsors ack, no?
<pitti> I didn't look
<dholbach> pitti: so nothing to do for other reviewers :)
<dholbach> you said "release/sponsor ack"
<pitti> ah, thanks
<dholbach> no worries :)
<pitti> superm1: oh argh!
<pitti> superm1: s/product/project/, please :)
<superm1> pitti, doh.  that could be clearer in documentation for the future :)
<pitti> superm1: I'll add an assertion, to point this out earlier
<pitti> superm1: I'll add that assertion ("must set distro or project" and add a blurb to doc/crashdb-conf.txt
<superm1> pitti, sounds sufficient, thanks
<superm1> pitti, while i'm updating, what did you have as a recommendation to simplify is_ppa?
<pitti>     if not apport.packaging.is_distro_package(report['Package'].split()[0]):
<pitti>     report['CrashDB'] = 'mythbuntu'
<superm1> ah, yeah, definitely better
<pitti> superm1: this reports bugs against ubuntu/+source/mythbuntu if it's an original ubuntu package, otherwise against a product
<pitti> (if that's the behaviour that you want)
<superm1> *project :)
<pitti> *cough*
<pitti> AssertionError: Need to have either "project" or "distro" option
<pitti> superm1:  ^ just committed that
 * Mirv got permission to attend UDS-L, see you there
<liw> Mirv, congratulations
<Mirv> liw: thanks
<Mirv> too bad it will shorten my FSCONS trip a bit, have to see if I will move my lightning talk on Sunday to an earlier time
<mneptok> liw: going to UDS?
<liw> mneptok, I doubt it
<mneptok> bah.
 * mneptok will be there
<liw> mneptok, I'm sure you'll have fun there anyway :)
<mneptok> need to book travel and hotel this week. going to see who from Montreal might want to share a room.
<mneptok> liw: i doubt it. it's Texas. ;)
<pitti> superm1: http://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/revision/1621 FYI
<superm1> pitti, thanks, that is definitely much more clear
<TheMuso> 1/c
<Mirv> hmm, I wonder if it would be ok or not to leave at ca. noon, Friday
<Mirv> the other option is Saturday evening which would mean quite late arrival back, on Sunday
<Mirv> (ie. noon or a little after from the hotel)
<mneptok> TeTeT!
<TeTeT> mneptok: Hi Kurt, how are things?
<mneptok> TeTeT: very good, thanks! Kristine and i are just completing a home purchase, and she starts a new job here next week. you?
<TeTeT> mneptok: currently at the London HQ of Canonical, having a training sprint
<mneptok> TeTeT: you're learning to make tea?
<TeTeT> mneptok: yeah, I look forward to the eating biscuit class
<skar> hi, i've got a patch to be applied to glibc source package. How do I apply the patch and build glibc?
<RAOF> skar: dpkg-source -x glibc_whatever_the_version_is.dsc, cd to the unpacked source dir, apply the patch (in some way; this depends on a number of things); debuild
<skar> RAOF: ok, i got to that stage. now, how do i make sure the build is done only for i386? it seems to be building for a long time :(
<RAOF> It'll only build for your arch (and possibly build a libc-i386 package if your arch is x86-64)
<pitti> mbiebl: do you see bug 444915 in linux 2.6.30 in sid, too? IOW, do you want to use "usefree" until this gets fixed again as well, or should I keep this as an Ubuntu specific change?
<ubottu> Launchpad bug 444915 in devicekit-disks "regression: statfs() takes a long time on VFAT without "usefree"" [High,In progress] https://launchpad.net/bugs/444915
<skar> RAOF: thanks. i was following http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/, so running debuild or "fakeroot debian/rules binary" both should work?
<RAOF> skar: Yes, although I doubt many developers actually do the latter.
<skar> RAOF: ok, that link i sent, it suggested that. also how do i force make to use "-j5". i've got a quad core machine, so compile would be faster.
<RAOF> That's package-dependent; there's no guarantee there's a switch to allow you to do that.  If there were, you'd want to shove something in the DEB_BUILD_OPTS evn variable IIRC.  Check out the debian/rules file for details :)
<skar> RAOF: thanks, debian/rules had a NJOBS where it seems to be detecting the no.of cores
<tsdgeos> hi, can anyone confirm wheter poppler in ubuntu is built against libopenjpeg or not'
<tsdgeos> ?
<tsdgeos> missing h somewhere
<bigon> could someone sponsor bug 439921 for me?
<ubottu> Launchpad bug 439921 in clutter-1.0 "libclutter-1.0-doc doesn't appear in devhelp" [Low,Confirmed] https://launchpad.net/bugs/439921
<seb128> bigon, subscribe ubuntu-main-sponsors so it's on the sponsoring queue
<seb128> we do sponsoring almost daily during the week
<bigon> seb128: ok
<ebroder> Is there a Python library that groks the apt repository format? I want to point something at an apt path and be able to poke at things like what version of a given package is in a particular component
<ebroder> My current alternatives are parsing the output of reprepro or finding the Sources (or Sources.gz...) file and parsing that with python-debian, and those both kind of suck
<skar> hi, i'm trying to apply a patch to glibc source pkg and compile it. now i've got a glibc-2.8~20080505/ dir with some bz2 files in there. how do i unzip them and then apply my patch?
<pitti> cjwatson: hm, the recent usplash change doesn't seem to send QUIT to usplash any more, so that it fades out?
<pitti> mat_t just complained
<pitti> it seems to just stay around until the computer powers off?
<cjwatson> pitti: yes, that was a hack to avoid text messages showing up after usplash quits but before shutdown
<cjwatson> pitti: if we can make it fade but not actually tear down the graphical vt, that would be better
<cjwatson> ebroder: python-apt should be able to do that?
<mat_t> pitti: well, that's not really about me complaining, I just think it would be good to keep this effect, which was already very well received in the reviews etc
<skar> hi, i'm trying to apply a patch to glibc source pkg and compile it. now i've got a glibc-2.8~20080505/ dir with some bz2 files in there. how do i unzip them and then apply my patch?
<joaopinto> when switching to VTs I just get garbage output, it started last week, I see some more people reporting it at #ubuntu+1 could it be related to usplash changes ?
<joaopinto> I get the same garbage output before gdm startup
<cjwatson> it could, yes
<joaopinto> I mean, for a second, I guess during a graphical mode transition
<cjwatson> oh, it's not permanent? when you switch back to vt1, does that work ok?
<joaopinto> it is permanent, but it also happens during boot, for a second, before gdm starts
<joaopinto> it is permanent if I do a manual switch to a VT
<joaopinto> I am using fglrx, not sure if that's part of the problem
<cjwatson> it usually isn't part of the solution ;-)
<cjwatson> usplash is meant to be torn down strictly before X starts
<cjwatson> maybe usplash isn't managing to restore the console correctly with fglrx
<cjwatson> that said, *that* part of the code hasn't changed recently to my knowledge
<skar> how do i unzip glibc's source deb so that i can access the individual files under "build-tree"?
<cjwatson> skar: there are usually debian/rules targets that help. (And please don't repeat yourself at five-minute intervals.)
<joaopinto> skar, if you need to learn about packaging, #ubuntu-motu is probably a better place
<pitti> cjwatson: I'm happy to add a new "FADEOUT" command to do just that, and not QUIT
<pitti> mat_t: don't worry, it's justified :)
<pitti> mat_t: I should have said "reported a bug"
<mat_t> ;)
<skar> cjwatson: thanks. i'll look into the source unpacking targets. won't repeat myself :)
<skar> joaopinto: thanks, will ask in that channel :)
<cjwatson> mat_t: it's a good effect, but I thought the text after usplash was even more likely to result in complaints at the moment ;-) having both is obviously the right answer
<mat_t> cjwatson: absolutely :)
<evand> pitti: is this indicative of the retracing service failing: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/441709
<ubottu> Launchpad bug 441709 in ubiquity "Ubiquity crashed when "Starting up the partitioner"" [Undecided,Confirmed]
<pitti> evand: indeed, weird; let me check the logs
<pitti> evand: hm, it's not even in the logs; I re-tagged it
<evand> thanks!
<evand> pitti: the retracer removed it again :)
<Keybuk>  short read in buffer_copy (backend dpkg-deb during `./usr/lib/openoffice/basis3.1/program/libcuilx.so')
<Keybuk> huh
<seb128> Keybuk, there is quite some similar bugs on launchpad
<Keybuk> seems to be an lzma issue?
 * Keybuk is having it with the new linux-source too
<Keybuk> that's odd
<Keybuk> removing the file and redownloading it seemed to fix it
<Keybuk> before:
<Keybuk> Preparing to replace openoffice.org-core 1:3.1.1-2ubuntu4 (using .../openoffice.org-core_1%3a3.1.1-4ubuntu1_amd64.deb) ...
<Keybuk> Unpacking replacement openoffice.org-core ...
<Keybuk> lzma: Decoder error
<Keybuk> dpkg-deb: subprocess <decompress> returned error exit status 1
<Keybuk> dpkg: error processing /var/cache/apt/archives/openoffice.org-core_1%3a3.1.1-4ubuntu1_amd64.deb (--unpack):
<Keybuk>  short read in buffer_copy (backend dpkg-deb during `./usr/lib/openoffice/basis3.1/program/libcuilx.so')
<Keybuk> after:
<Keybuk> Preparing to replace openoffice.org-core 1:3.1.1-2ubuntu4 (using .../openoffice.org-core_1%3a3.1.1-4ubuntu1_amd64.deb) ...
<Keybuk> Unpacking replacement openoffice.org-core ...
<Keybuk> kooky
<Keybuk> the files were different sizes too
<mvo> Keybuk: how much different?
<pitti> evand: ah, got it now:
<pitti> 10/12/09 10:51:02: retracing #441709
<pitti> report file does not contain required fields: CoreDump Package ExecutablePath
<pitti> evand: indeed the report doesn't have a Package: field
<pitti> I wonder where that went
<evand> ah, cool
<Laibsch> lool, ArneGoetje: what about kasumi?  Has the window for MIR closed?
<seb128> dholbach, joaopinto was wondering if there is any reason you didn't look at bug #439638 again or upload
<ubottu> Launchpad bug 439638 in papyon "Unable to login into MSN" [Undecided,New] https://launchpad.net/bugs/439638
<Laibsch> ArneGoetje, lool: There is a new upstream release.  To avoid duplicate work, I'd like to work on that for Debian and fix what's necessary to finish the MIR for karmic.
<dholbach> seb128: no, no reason just that I had a bunch of other stuff to do
<dholbach> so if anybody wants to grab it, do it
<seb128> dholbach, you touched it, you upload it I would say ;-)
 * seb128 hugs dholbach
<seb128> I will have a look later otherwise, still fighting my 800 emails backlog from the weekend
<dholbach> seb128: lotsofemail: I totally see what you mean
<chrisccoulson> seb128 - i don't envy your task of going through 800 e-mails ;)
<lool> Laibsch: It's tight IMO
<lool> Laibsch: Couldn't we revisit that next cycle?
<lool> Laibsch: Does it cause serious issues in karmic?
<Laibsch> I don't think so
<Laibsch> It's about whether or not scim-anthy will get a bugfix that is in Debian or continue to have a delta explicitly to drop the fix
<lool> Laibsch: If you need to merge a new scim-anthy to fix serious bugs, that's still ok at this time; but I wouldn't focus on dropping delta with Debian at this point of the cycle, we usually focus on that at the beginning of the ccyle
<Laibsch> Well, I did focus on that around June ;-)
<Laibsch> bug 332041
<ubottu> Launchpad bug 332041 in scim-anthy "Problems adding a new vocabulary, "kasumi" package not installed by default" [Medium,Triaged] https://launchpad.net/bugs/332041
<Laibsch> so, not a very serious bug
<Laibsch> but one that was fixed in Debian
<Laibsch> and we could otherwise sync scim-anthy from Debian (I made sure we can)
<Laibsch> if kasumi was in main (or scim-anthy wasn't)
<lool> I am not sure I can judge of the severity of this bug; I'd prefer if Arne would comment
<Laibsch> it's not serious
<Laibsch> scim-anthy is in main
<Laibsch> there is a knob to pull up a user dictionary
<Laibsch> that calls the kasumi program
<Laibsch> currently kasumi is not installed by default, the fix is to recommend it
<Laibsch> but kasumi is in univers
<Laibsch> e
<Laibsch> debian scim-anthy now recommends kasumi
<Laibsch> and thus can't be synced
<Laibsch> debian does the right thing, ubuntu can't until kasumi is in main
<Laibsch> in essence, that is the issue
<simon-o> kirkland: Hi, why is the default for byobu the commons keybindings and not the f-keys? Was this changes recently?
<lool> Laibsch: I understood that part of the issue, I don't understand how much of a big deal it is to have this feature slightly broken
<lool> Laibsch: The issues are relatively easy to fix though; I guess you could easily get a hold on these
<Laibsch> It's obviously an easy fix: "sudo aptitude install kasumi"
<Laibsch> lool: Actually, the build issues are not that easy for me
<Laibsch> lots of new stuff
<Laibsch> It will take me some time
<lool> Laibsch: Ok; I can help you there
<Laibsch> cool
<lool> Laibsch: Looking at comment #1 on the MIR bug, which one is the first issue which you can't resolve?
<Laibsch> I haven't gone through the comments
<lool> Ok; ping me when you're stuck
<Laibsch> sure
<Laibsch> thanks
<jml> hi
<Keybuk> seb128: 800 e-mail backlog?
<Keybuk> is that why you're only #3 in the bug traffic volume ranks this month? :p
<jml> where might I find stats on the number of bugs filed per day against ubuntu?
<Keybuk> the apport retracing service is beating you!
<ion> keybuk: Any thoughts about what i posted to http://launchpad.net/bugs/432089, btw?
<ubottu> Launchpad bug 432089 in sreadahead "performs poorly on slow HDD" [High,Triaged]
<Keybuk> ion: foreground isn't enough
<seb128> Keybuk, lol
<ion> The bug report is about sreadahead performing poorly on a slow HDD, but my HDD is quite good for a laptop HDD and simply disabling sreadahead makes the system boot more than five seconds faster.
<seb128> Keybuk, I can give you some bugs if you want ;-)
<Keybuk> ion: how good is quite good?
<Keybuk> seb128: I have plenty, I'm personally beating all of the QA team except pedro ;)
<ion> keybuk: The laptopâs quite new, the HDD has a capacity of 320 GB and the maximum throughput in bootchart reaches 54 MB/s.
<hunger> ion: How do you disable sreadahead?
<ion> hunger: By commenting out the âstart on...â line.
<hunger> Good point:-) I am not used to upstart yet:-)
<Keybuk> ion: what's the hDD?
<hunger> Keybuk: Hard Disc Drive?
<ion> keybuk: http://pastebin.com/f53cf5098
<Keybuk> ion: 5400RPM, 12ms seek
<Keybuk> that fits the "slow drive" pattern
<james_w> jml: ubuntu-bugs mailing list archive?
<ion> keybuk: Ah, alright. I expected the âslowâ to mean something slower than a typical laptop HDD.
<ion> Of course, a 5400 RPM laptop HDD *is* slow compared to a 7200 RPM desktop HDD.
<Keybuk> no, I mean that typical laptop HDDs *are* slow
 * liw thinks all hard disks are slow
<jml> james_w, I was kind of hoping for something more digested than that.
<james_w> jml: bdmurray might have stats
<jml> james_w, I think that even if he does, Launchpad should track this information also.
<james_w> jml: http://people.canonical.com/~brian/graphs/ but it seems to be busted right now
<jml> james_w, thanks.
<james_w> 10 minutes with http://people.canonical.com/~brian/graphs/bugstats.data could get you the information in the meantime
<jml> ta
<jdstrand> zul, mathiaz: hi! (I'm not really here) I just noticed bug #449358. The reporter's issue is clearly a dupe of 444479, however, I thought that it was odd that /usr/sbin/mysqld-akonadi was confined (I thought /usr/sbin/mysqld-akonadi was supposed to be a hard link and not a symlink). I'm not at all up on the akonadi packaging, but this sounds like it could be a problem
<ubottu> Launchpad bug 449358 in mysql-dfsg-5.1 "Warning message from apparmor about /usr/sbin/mysqld-akonadi" [Undecided,New] https://launchpad.net/bugs/449358
<Riddell> seb128: your sync of poppler from April says "don't use openjpeg it's in universe", why not get openjpeg into main?
<seb128> Riddell, I'm not the one who did the change I just reapplied the ubuntu diff we had
<seb128> Riddell, it's slangasek who did the change iirc
<seb128> Riddell, I've no opinion on the topic
<Riddell> seb128: mm, the changelog is incomplete, found the complete changelog on lauchpad
<Riddell> slangasek: " Disable openjpeg on all archs for Ubuntu, this lib is in universe
<Riddell>     and isn't needed."
<Riddell> slangasek: any reason for that?  it is needed if you want to see jpeg2000 decently
<seb128> Riddell, right, I don't copy all the changelog entries when resyncing on debian but just summarize the changes
<geser> can a core-dev please give-back bacula (FTBFS fixed by recent upload of libbonoboui)
<pitti> geser: done, thanks!
<seb128> jdstrand, hey, could you look to bug #447292?
<ubottu> Launchpad bug 447292 in evince "permission denied on various files while starting evince" [Low,New] https://launchpad.net/bugs/447292
<seb128> jdstrand, not sure if that's an apparmor or evince issue
<seb128> jdstrand, I guess the issue is due to nfs user dir
<seb128> jdstrand, bug #449286 too
<ubottu> Launchpad bug 449286 in evince "[karmic] evince apparmor profile breaks zotero reference database" [Undecided,New] https://launchpad.net/bugs/449286
<jdstrand> seb128: that is a dupe of another bug that jjohansen is working on a fix for
<jdstrand> seb128: (the first one that is)
<jjohansen> jdstrand: building a new test kernel on that one, should have something up soon
<jdstrand> seb128: hmm, the second is thornier
<jdstrand> seb128: I've assigned ti to me for now-- it can probably be solved in apparmor
<jdstrand> seb128: btw, I'm not here today :)
<jjohansen> hehe me neither :)
<jdstrand> jjohansen: I didn't have a chance to test your nfs fix yet. I won't until tomorrow (at which point I am still 'not here', but can test your kernel)
<jjohansen> jdstrand: okay :)
<jdstrand> jjohansen: do you have that bug number off-hand?
<jdstrand> s/off/on/
<jjohansen> jdstrand: Bug #415632
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/415632/+text)
<jdstrand> jjohansen: thanks
<seb128> jdstrand, ok, thanks for replying, enjoy your holiday ;-)
<Keybuk> ugh
<Keybuk> trying to figure e2fsck out, every time I think I'm getting close, I get eaten by a grue
<tkamppeter> pitti, I have found a big problem in CUPS 1.4.1: It seems that for broadcasts it always uses the host name and never tyhe IP of the server (in 1.3.x it used the IP). This requires that host names in networks are always well-defined and this is not the case in many small networks or for temporarily connected machines.
<pitti> tkamppeter: hm, is that configurable?
<tkamppeter> pitti, there is a ServerName entry in cupsd.conf where one can set this, by default this is not set.
<tkamppeter> pitti, I have tried "cupsctl ServerName=192.168.2.105" now and got a correct entry in cupsd.conf, but the client still gets "ipp://noname:631/printers/b" in lpstat -v (for the printer b on the server).
<tkamppeter> pitti, I have even tried to restart CUPS on the server but this does not help.
<Keybuk> dear git.  how is not pushing tags by default *useful* ?
<pitti> well, it's just consistent
<pitti> "1. No command shall do useful things without any arguments."
<pitti> tkamppeter: hm, I'm using cupsd from my wife's computer, it seems to get picked up just fine
<pitti> ipp://dagobert.local:631/printers/ML-1610
<pitti> ah, heh
<pitti> .local names FTW
<chrisccoulson> Keybuk - do you not like git?
<ion> :-D
 * pitti sees Keybuk turn red and explode
<ebroder> Wait, why is subscribing ubuntu-archive to bug #429445 the wrong thing? It's a sync that's been approved by ubuntu-release...
<ubottu> Launchpad bug 429445 in zephyr "[Karmic FFe] Sync zephyr 3.0~rc.2544-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/429445
<pitti> ebroder: fixing bug again
<sistpoty|work> seb128: what's wrong with the fix in bug #445633?
<ubottu> Launchpad bug 445633 in pygobject "FTBFS: automake-1.10 missing" [Low,Fix released] https://launchpad.net/bugs/445633
<seb128> sistpoty|work, why do you want to run autotools there?
<sistpoty|work> seb128: b-d on autotools-dev?
<sistpoty|work> seb128: so config.sub/.guess don't match the current version?
<james_w> ebroder: it needs a sponsor check
<seb128> sistpoty|work, well, why? I would have went the other way, make sure autotools are not run at build time
<seb128> sistpoty|work, but why is there any need to run autotools at all there?
<sistpoty|work> seb128: iirc they aren't, but rather run and in the patch
<seb128> sistpoty|work, configure && make && make install ought to work from the tarball
<tkamppeter> pitti, does your wife have Karmic (or CUPS 1.4.x) on her box?
<seb128> why do you want to run autotools in the diff or at build time
<sistpoty|work> seb128: due to the version mismatch of autoconf
<seb128> sistpoty|work, what mismatch?
<tkamppeter> pitti, in addition in your network host names seem to be well defined, but this is not assured in all networks.
<sistpoty|work> seb128: "aclocal.m4:16: warning: this file was generated for autoconf 2.63." --> build fail
<sistpoty|work> seb128: what would be the better way to fix this?
<Keybuk> pitti: I have an apport hooks question
<seb128> sistpoty|work, but why are autotools run in the first place during the build?
<seb128> sistpoty|work, not run any autotools at all since we don't change any build file there
<Keybuk> do you think it would be possible to create a hook that includes the reporter's exact location, address, GPS info, etc. and usual times when they are there
<Keybuk> that way the next time someone reports a "last mount time in future" bug, I can go round their house with a shotgun? :p
<sistpoty|work> seb128: isn't there a configure script that gets run? (/me looks at pygobject again)
<seb128> Keybuk, I though that bug was fixed?
<seb128> sistpoty|work, configure && make yes, configure != autotools
<Keybuk> seb128: the bug is fixed, the fact that users are idiots is not fixed
<liw> Keybuk, you can get the location from LP for many people...
 * Keybuk has submitted http://permalink.gmane.org/gmane.comp.file-systems.ext4/15847
<seb128> sistpoty|work, the fix would probably be to comment 03_maintainer_mode.patch from the serie
<Keybuk> which will probably be refused by upstream ;)
<Keybuk> . o O { maybe I just need Ted Tso's location :p }
<seb128> sistpoty|work, that's useful only in the case you have an autotools update change
<sistpoty|work> seb128: would that build then? the patch-stamp target copies config.sub/.guess from autotools-dev, so these mismatch the other generated files in the build
<seb128> sistpoty|work, why a config.sub and config.guess update trigger an autotools run?
<seb128> sistpoty|work, and if that's the case why do we need to update those to start?
<seb128> sistpoty|work, we don't have an autotools patch in every package doing a config.guess update
<Keybuk> seb128: can't see any reason they should
<Keybuk> config.guess is used by configure *invocation* not by autoconf
<Keybuk> just grepped through automake, they certainly shouldn't
<seb128> sistpoty|work, I guess the issue there is the maintainer mode change updating configure.ac and autotools trying to be clever
<seb128> sistpoty|work, the fix I guess would be to just comment the unrequired configure.ac from the series
<sistpoty|work> seb128: hm... that would make sense, indeed
<\sh> moins
<ebroder> cjwatson: I looked at python-apt, but I can't figure out a way to point it at an arbitrary repository, as opposed to just examining what's in my sources.list
<Keybuk> seb128: why would it update configure.ac ?
<Keybuk> ironic if trying to turn off maintainer mode resulted in one last rebuild just for luck <g>
<seb128> Keybuk, there is a patch to set the maintainer mode which is useful sometimes
<Keybuk> just leave it on - it doesn't hurt
<seb128> Keybuk, no, it's setting it on so when we have versions with autoreconf patches things are not run on buildds again
<Keybuk> adding autoconf, automake, libtool to build-depends is easier than having to keep an autoreconf patch up to date ;)
<Keybuk> we could even have an "autoreconf" meta package that depended on the current versions :)
<seb128> running those at build time sucks
<seb128> it takes build time and create often issues when different versions are used
<seb128> working sources start ftbfsing which lead to extra work
<cjwatson> ebroder: you can configure it in much the same way you configure other apt tools, by setting options
<cjwatson> apt.conf(5) has details
<cjwatson> you may need to write a temporary sources.list file
<lool> OMG linux-libc-dev didn't build on armel since the linux-* trees were split
<lool> We still have 2.6.31-5.24
<lool> apw: ^^  It this known?
<cjwatson> oh, yeah, I noticed that myself
<cjwatson> seems worth fixing ;-)
<lool> That seems a really serious issue to fix before end of week
<cjwatson> need to make the linux source build just that binary on armel, presumably
<lool> Yeah
<lool> With a sensible config
<apw> lool, when we were discussing linux-libc-dev earlier in the week it was implied it was architectur eindependant
<lool> apw: You mean subarch
<apw> actually we were talking about it being built 'only on i386' cause it was 'all'
<apw> sounds like its not
<lool> apw: We were discussing issues related to subarch specific divergences in linux-libc-dev, how to handle that; but in all cases our armel packages should be built against a standard linux-libc-dev, subarch independent
 * apw will have a look at that, that sounds all foobared
<lool> apw: I'm not sure whether headers rely on a .config or not, but it seems there's a target to generate all headers at once
<lool> bug #449637
<ubottu> Launchpad bug 449637 in linux "linux-libc-dev not built on armel anymore and seriously out of date" [Undecided,New] https://launchpad.net/bugs/449637
<lool> apw: make headers_install_all
<lool> "The command "make headers_install_all" exports headers for all architectures
<lool>  simultaneously.  (This is mostly of interest to distribution maintainers, who create an architecture-independent tarball from the resulting include directory.)
<apw> lool, its clearly broken ... will get it discussed shortly
<Riddell> ccheney: how much of the fixes from shtylman for bug 424132 are in our packages?
<ubottu> Launchpad bug 424132 in openoffice.org "[kubuntu] OOo KDE file dialog is utterly broken." [Medium,Confirmed] https://launchpad.net/bugs/424132
<joaopinto> any core dev available that could me help me testing a bug that migh be classified as security vulnerability ?
<zul> jdstrand: im not here either Ill take a look at it tomorrow
<Darxus> That's odd.  If I run X by itself (no window manager, etc.) I just get a blank screen.  Not even a mouse.  Jaunty though.
<lfaraone> Is there a reason that one can no longer "remember this authorization" for administrative actions in Karmic? (ex: setting CPU scaling via the applet)
<jcole> happy monday
<lfaraone> jcole: you too.
<jcole> what would it take to get evolution-mapi functional in ubuntu karmic? if someone would tell me, i'll host a functional version internally
<jcole> or even a ppa
<jcole> this is bugs 446626 435881 etc.
<ubottu> Launchpad bug 446626 in evolution-mapi "evolution crashed with SIGSEGV in camel_header_raw_append()" [Undecided,New] https://launchpad.net/bugs/446626
<jcole> the evo guys claim it works in suse
<Darxus> Ignore what I said about X.  I don't know why I didn't find the mouse.  The default background should *not* be all black.
<jcole> if i was to alien up the suse evolution-mapi rpms to .debs, can those be posted to a ppa? or, are ppa for source only?
<chrisccoulson> jcole - no, that won't work
<jcole> chrisccoulson: any suggestions?
<chrisccoulson> it needs properly packaging as a source package
<jcole> chrisccoulson: is there any tools for converting suse source packages to debian/ubuntu
<chrisccoulson> i'm not familiar with packaging in suse at all
<jcole> chrisccoulson: i know a few guys here running evolution-mapi on suse.. i'll ask them about converting source packages...
<chrisccoulson> You would need to make a Debian package from scratch if there isn't one already
<jcole> chrisccoulson: there is one already
<jcole> chrisccoulson: it just doesnt work
<chrisccoulson> you should try and fix the existing package then ;)
<fagan> mvo: *ping*
<chrisccoulson> evolution-mapi is in karmic anyway. what doesn't work with it?
<jcole> chrisccoulson: that is what im trying to do.. if i could figure it out, ill post a working version internally
<jcole> chrisccoulson: it crashes when reading a message
<mvo> fagan: pong
 * james_w hugs mvo 
<james_w> good timing
<mvo> hey james_w
<james_w> mvo: update-notifier has started (in karmic) shipping /var/crash, with standard permissions, which prevents apps running as a non-root user from reporting crashes
<james_w> mvo: I guess this isn't intentional?
<jcole> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/evolution-mapi?orderby=-datecreated
<james_w> update-notifier-common sorry
<jcole> chrisccoulson: last 4 bugs
<mvo> james_w: no, not intentional (and odd)
<mvo> james_w: I can't remember changing that :/ is there a open bug about this?
<james_w> mvo: the fix is probably easy, but I guess we should do something to fix it for current users?
<james_w> mvo: I'm just looking for one now
<james_w> I just discovered this now with the help of ahasenack
<fagan> mvo: im just looking into Bug #438870 could you point me to the part of the software store that deals with installing the software
<jcole> chrisccoulson: i tried to install a newer version of evolution-mapi from debian unstable... but its compiled against a newer evolution so dependency fail
<ubottu> Launchpad bug 438870 in software-center "Downloads should start when the previous one ends" [Wishlist,Confirmed] https://launchpad.net/bugs/438870
<mvo> fagan: it does probably need support from aptdaemon, my idea was to start a transaction with --download-only
<fagan> mvo: that would work
<mvo> fagan: there is a apt config option that can be set if that is all that is required, it may run into issues with multiple locks, in this case its probably best to just create private download dirs and move them into place when all is finished
<jcole> chrisccoulson: thre is also a gnome bug for this at https://bugzilla.gnome.org/show_bug.cgi?id=595810 ... but, why does it work in suse? does this bug only apply to the version in karmic?
<ubottu> Gnome bug 595810 in Mail "evolution crashed while doing initial message fetching" [Critical,New]
<mvo> fagan: so the transaction would be split into (download, install) and download could be done in parallel
<fagan> mvo: yep that would be a lot quicker than the current system too
 * wolfe yawns
<chrisccoulson> jcole - i'm sorry, but i've no idea why that would be the case. evolution-mapi isn't a package i have any particular interest in, so i don't know much about it ;)
<wolfe> :|
<james_w> mvo: can't find a bug on either update-notifier or apport, so I'll file one and we can discuss how to do the fixup at the same time as the fix?
<mvo> fagan: ideally we would make the daemon so clever that it automatically does that (transparent to the frontend)
<mvo> james_w: yes, sounds good to me
<james_w> "Package update-notifier-common does not exist"
<james_w> oh, typo
<fagan> mvo: That would be the ideal solution and it could be done by lucid
<mvo> fagan: great, I will not have time to look into it myself before karmic-final, but I'm happy to help and give feedback :)
<mvo> james_w: I will have to leave soon for tonight, but I will have a look tomorrow morning
<james_w> mvo: sure, I thought you had gone already.
<fagan> mvo: ill give it a look :)
<mvo> james_w: I was (almost) - but then there was a odd FTBFS that looks like something in python recently broke my setup.py :(
<james_w> mvo: you fixed it?
<mvo> doko_: could you please have a look at bug #449734 ?
<ubottu> Launchpad bug 449734 in python2.6 "update to 2.4.0~rc1 break update-manager setup.py (and possible others)" [Undecided,New] https://launchpad.net/bugs/449734
<mvo> james_w: no, I don't have a fix yet - is this a known issue ?
<james_w> mvo: not that I have heard
 * fagan gos back to his super secret project so it can be ready for the UDS
<jcole> chrisccoulson: ya, this is not your normal "consumer" package... and, it probably works in suse because they target the "enterprise" desktop whereas ubuntu targets the "consumer" desktop... but, i'd still like to get a working version in ubuntu for those of us that want to run ubuntu... maybe you could direct someone to me who knows about this package and ill create a working version in a ppa :)
<chrisccoulson> jcole - do suse use a different upstream version? Do they have any patches that might fix it?
<doko_> mvo: looking
<james_w> I see a very suspicious hunk in the diff for the last upload
<james_w> doko_: http://paste.ubuntu.com/291771/
<mvo> doko_: thanks
<james_w> mvo: do you have python-pyrex installed in the error case?
<mvo> james_w: I'm not sure, but it happens on a pbuilder too
<james_w> probably not then
<jcole> chrisccoulson: im thinking its not actually evolution-mapi itself (since it just creates the account)... but suspecting the underlying libmapi libraries and/or the evolution email rendering engine
<mvo> no pyrex
<mvo> james_w: I saw that too, its in tests/ though, this is puzzling
<jcole> chrisccoulson: im looking for a way to browse suse source
<james_w> mvo: the hunk I pasted?
<james_w> python2.6-2.6.4~rc1/Lib/distutils/command/build_ext.py
<mvo> james_w: oh, sorry
<mvo> james_w: indeed, its in build_ext.py - its pretty certainly the problem :)
<mvo> james_w: amazingly quick!
<james_w> just looking for the bug that was fixing
<james_w> python bug 7064
<ubottu> Launchpad bug 7064 in discover1 "Replaced by hotplug" [Medium,Invalid] https://launchpad.net/bugs/7064
<james_w> no! python!
<mvo> heh :)
<james_w> http://bugs.python.org/issue7064
<jcole> chrisccoulson: whats really stupid about exchange server, is that not only does it save messages on the server as .txt and .html, but also as .rtf ... im wondering if the evolution rendering engine in ubuntu is crapping out on those, because it only crashes on certain messages
<james_w> mvo: perhaps it should be "Extension('UpdateManager.fdsend',"?
<james_w> that's what the documentation implies?
<james_w> i.e. use the dotted module name, not the path to the module dir
<jcole> jcole: /j #suse
<jcole> bleh
<wolfe> ewww, suse ;D
<wolfe> lynch him!
<james_w> wolfe: easy please
<chrisccoulson> jcole - i don't know - you seem to have a better grasp of the issue than me ;)
<chrisccoulson> i can't help you much as i'm trying to figure other things out right now
<jcole> chrisccoulson: of course, thanks for your time... i'll figure out something for us ubuntu users :)
<chrisccoulson> thanks:)
<mvo> james_w: thanks, I try that now
<samba> hi all - i'm working with a number of chroots that need to include valid kernels and modules (like PXE boot) but when I install updates on the server, DKMS tries to build against the running kernel (via uname) - is there any way to override that?
<samba> (i.e. i want it to look at installed kernels - in /lib/modules or so - not at uname)
<samba> (I see the options on dkms itself, but i'd like it configurable so DKMS will automatically map to the proper kernel)
<slangasek> Riddell: if I said it wasn't needed, I must have consulted someone before dropping the dep, but I don't know who
<tkamppeter> pitti, still there?
<debfx> slangasek: have you had a chance to look at my updated powerdevil detection for acpi-support (https://code.edge.launchpad.net/~debfx/acpi-support/fix-lp387750/+merge/12466)?
<Steeley> Cisco IOS
<Steeley> oops, apologies. wrong channel
<wamty> having trouble with vnc-viewing my ubuntu desktop, when I single click it almost always translates it into a double click, makes it impossible for me to do anything, any ideas?
<lucas_> Hi there, I would like to report a bug with some ruby files but I don't  know  how to find which package the files involved belong to
<lucas_> for instance  /usr/lib/ruby/1.8/x86_64-linux/rbgtk.h has some includes of files that are not provided
<spaetz> lucas, dpk -S file ???
<spaetz> dpkg
<wamty> ideas?
<lucas_> ok so the culprit is ruby-gnome2-dev
<kklimonda> wamty, you would have more luck on #ubuntu channel probably.
<wamty> i did
<wamty> noone answered there
<lucas_> spaetz, I ve seen that it was corrected in debian ? should I report a bug on launchpad ?
<spaetz> no clue, i'm no ubuntu dev
<spaetz> but reporting a bug can never hurt
<lucas_> ok because it seems to prevent me from building a gnome/ruby app
<wamty> so?
<kklimonda> lucas, yes, you should report that (make sure that it wasn't reported before)
<spaetz> lucas, if you report it, do point to the resolution in debian
<lucas_> kklimonda, definetly I will, but it is really unlikely that it was, since at that stage such things should have come up. I believe the fix is available form debian packages
<spaetz> bug no, etc
<lucas_> I will
<lucas_> thanks
<mdke> pitti: many thanks for looking at that ubuntu-docs issue, I'll fix it accordingly
<lucas_> BTW do you guys now a way to report bugs without the command ubuntu-bugs, I find myself unable to find the appropriate menu on launchpad
<kklimonda> wamty, you could try ubuntuforums.org, I think that you have the best chance of getting a good answer there (#ubuntu channel is crowded and this one is for development discussion)
<kklimonda> lucas, when you are redirected to the wiki page scroll down and you will see a direct link (with ?no-redirect argument) you can use
<tgpraveen1> the launc hpad has been made too difficult to file bugs
<tgpraveen1> now
<ccheney> Riddell: all except the ones sent this morning
<chrisccoulson> james_w - have you experienced the hanging policykit dialog recently?
<james_w> hey chrisccoulson
<james_w> never have
<chrisccoulson> hmmm
<chrisccoulson> i haven't seen it for a while either
<james_w> I'm a bit lost to be honest
<chrisccoulson> i wonder if it's magically fixed now? ;)
<jdong> chrisccoulson: I've seen it today
<chrisccoulson> i hate not understanding why things are broken
<jdong> chrisccoulson: happens when I use ENTER to confirm my password entry
<jdong> the password textbox disappears
<jdong> but the dialog still persists
<chrisccoulson> jdong - i wish i could recreate it reliably
<jdong> clicking either button is NOACTION
<spaetz> the one with no line to enter a passwd? got that dialog today
<chrisccoulson> i might try pressing enter and see if it makes a difference
<jdong> but clicking the window's X causes update-maanger to work
<jdong> chrisccoulson: yeah clicking Authenticate the first time works 100% for me
<jdong> chrisccoulson: but pressing ENTER "hangs" the dialog 100%
<james_w> enter works for me
<james_w> jdong: 100%?
<jdong> :-/
<james_w> you're just the person we've been looking for!
<jdong> james_w: well 4 of the 4 times I've tried in the past 2 days :)
<jdong> in fact let me humor myself and do it right now!
<james_w> jdong: would you do some debugging for us please?
<jdong> sure
<jdong> GRR it worked this time
<chrisccoulson> lol
<jdong> well ok 80% :P
<chrisccoulson> it worked here too;)
<jdong> so I guess I just need to complain to the right people!
<jdong> AH BROKE THIS TIME!
<jdong> ok I've got an authenticate dialog without a textbox
<jdong> what would you like me to do?
<james_w> can you "strace -p $(/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1)"
<james_w> oh, with -f as well
<james_w> doing that before triggering it would be good
<james_w> you know you can drop priveledges with the "keys" icon in the notification area?
<jdong> correct
<james_w> cool
<james_w> you'll want to check that your password isn't in the strace output before you show us
<chrisccoulson> i need to learn how the new policykit works:)
<james_w> that process runs in your session all the time
<james_w> it registers with polkitd when it starts as the agent for your session
<james_w> when something requests auth polkitd calls it over D-Bus with the info that it needs
<jdong> ok got it to happen
<james_w> it then pops up and asks for the passwords
<jdong> once thin that I do notice:
<james_w> at the same time it runs a suid helper to talk to pam
<jdong> when it works, strace just says "pid 65xx attached"
<jdong> but when it doesn't work, I get multiple attached and detached messages from strace
<jdong> with pid's in the high-25000 region
<james_w> once you give the password it gives this to the helper
<jdong> seems like it's spawning some new pid repeatedly
<james_w> it auths with pam, and then calls back over D-Bus to polkitd to tell it all is well
<james_w> chrisccoulson: clear? ;-)
<chrisccoulson> james_w - i think so;)
<james_w> jdong: interesting, could we see the redacted trace?
<jdong> http://jdong.mit.edu/~jdong/broken_polkit_strace.txt
<jdong> james_w: this time it didn't even ask me for a password the first time... :-/
<james_w> thanks
<james_w> really?
<jdong> james_w: http://jdong.mit.edu/~jdong/broken_polkit.png
<jdong> the dialog looked like that
<jdong> and there was no key in the systray either
<jdong> neither of the two buttons do anything, and I clicked them a couple times during the strace
<wamty> I googled this and can't getr a straight answer. anyone else running ubuntu 9.04 server with wifi? The adapter is listed, I can ifconfig it and it's tx/rx packets, but I have no outside network access.. I explored all avenues at the command line. The *only* thing I noticed is that the listed supported encryption modes do NOT include WEP, which is what i'm using (crucify me for this later please). The onyl ubuntu network manager handled this
<jdong> clicking the big X did work
<wamty> FWIW, my old version was 6.06 and it worked fine.. also on the post 6.06 releases RADI croaks one of my drives.. but it works fine and is physically configured fine. Hit a brick wall there as well.
<jdong> wamty: -> #ubuntu
<james_w> polkit-grant-helper-pam: needs t
<james_w> "...to be setuid root" I predict
<james_w> does strace interfere with suid?
<jdong> james_w: I don't think it does when attached to an existing process...
<jdong> at least as far as I understand
<james_w> well, it's going to be tracing the spawned process, so it might thee
<james_w> I think I know what the race is that breaks it in this case
<james_w> but I'm not sure that will be what breaks it normally
<jdong> I'm gonna be out for 10m to grab dinner but will check back if I can provide any more assistance :)
<james_w> thanks
<wolfe> how sad, I see 10m and think 10 meters, as in radio frequency :)
<directhex> how do i see the current nbs list?
<seb128> directhex, http://people.canonical.com/~ubuntu-archive/NBS/
<directhex> webkit, thought so
<james_w> jdong: some packages put at https://edge.launchpad.net/~james-w/+archive/polkit/+packages
<james_w> if you could install libpolkit-agent-1-0 from there and then kill the process you were stracing and launch it again as "strace -f -o /tmp/strace.txt /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1" that would be great
<james_w> if I am right you won't be able to trigger the lack of the password to start with any more
<james_w> but it will always fail
<james_w> so it won't have really got us anywhere, but we might as well fix bugs as we find them
<james_w> "man strace" states that if you make the strace binary suid root then you can strace suid programs correctly
<james_w> would you be willing to do that while we test
<james_w> if so, then please do so and re-run the above, and you should see the prompt as before
<james_w> and if you can then trigger it the strace should be useful
<Darxus> There's no 2038 bug open?
#ubuntu-devel 2009-10-13
<slangasek> debfx: you've tested this fix yourself, right?  I don't have a kubuntu setup here to test it on, so I can only check that the code looks right
<slangasek> debfx: is the 'su -' actually needed? acpi-support runs as root, so shouldn't it have access to the dbus session bus anyway?
<slangasek> (or is this done to isolate the dbus process from root privs?)
<slangasek> debfx: btw, I don't think I received a notice of this merge proposal, in the future you might want to check that your merge proposal was requesting a review from whoever you're looking to have review it
 * directhex invokes a release manager
<debfx> slangasek: yeah I tested it on my kubuntu installation
<debfx> the "su" is necessary, it doesn't work otherwise (not sure why though)
<slangasek> ok
<slangasek> debfx: uploaded, thanks :)
<directhex> slangasek, do i subscribe a release manager then sponsor, or the other way round?
<slangasek> directhex: either way is ok with me
<directhex> (lp: #449970 FYI)
<debfx> slangasek: ok, glad I could help :)
<directhex> i'm all sleepy now. that's the first hard debugging session in an alien API i've had for a very long time
<Riddell> debfx: what's this fix?
<debfx> Riddell: powerdevil detection in acpi-support http://bazaar.launchpad.net/~ubuntu-core-dev/acpi-support/trunk/revision/163
<Riddell> oh cool
<YokoZar> doko_: Mind if I poke you ~ ftlk1.1 ?  https://launchpad.net/ubuntu/+source/fltk1.1  has it still FTBFS and the mismatch is blocking me from updating ia32-libs
<directhex> YokoZar is the poor sod who looks after the most unmaintainable package ever?
<YokoZar> directhex: mostly because I'm the biggest (ab) user of it
<YokoZar> directhex: but yes it seems that way
<Laibsch> Does http://packages.ubuntu.com/ubuntu-laptop-mode still serve a purpose?  It hasn't been updated for ages and there is the generic laptop-mode-tools package available.  Time for removal?  Where to request?
<johanbr> Laibsch, I think the answers are "no, yes, file a bug" respectively
<Laibsch> OK
<Laibsch> Thanks
<Laibsch> Will do
<johanbr> you're welcome
<Laibsch> bug 450004
<ubottu> Launchpad bug 450004 in ubuntu-laptop-mode "time for removal of ubuntu-laptop-mode package?" [Undecided,New] https://launchpad.net/bugs/450004
<spstarr> any reason libasound-plugins is not built with jack output?
<spstarr> [AO_ALSA] alsa-lib: pcm.c:2171:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_jack.so
<TheMuso> spstarr: Because jack is not in main.
<spstarr> license problem?
<TheMuso> No
<spstarr> does debian build it?
<TheMuso> If there was a license problem, it wouldn't be in the archive
<TheMuso> spstarr: I believe so.
<ScottK> archive/universe
<spstarr> so then why is ubuntu turning it off(?)
<ScottK> spstarr: Do you understand the difference between Main and Universe?
<spstarr> not really
<spstarr> I just want what debian provides, not isolating this from that
<ScottK> The most relevant bit here is that Main needs to be self-contained complete, so packages in Main cannot build-depend on packages in Universe.
<TheMuso> spstarr: If you want what debian provides, use Debian.
<spstarr> so then move jack to Main?
<ScottK> Part of the original plan for Ubuntu was that it would focus on an subset of the Debian archive and try to make that really shine and provide security support for it.
<ScottK> So every time you move stuff to main, there has to be a good rationale as it ups was has to be officially supported by Canonical.
<ScottK> There was some discussion about that this cycle, but it didn't get done.
<spstarr> i'll just get the src deb and turn it on myself.
<ScottK> Since TheMuso is an Ubuntu Studio dev, you're probably talking to one of the people that wants that more than most.
<spstarr> my audio card has no PCM capture (DRM likely) and I cant record any output from it
<spstarr> so thus I need workarounds that Ubuntu is turning off ;(
<TheMuso> ScottK: This cycle has seen a push to get jack into main to solve just this problem, as it would allow firewire audio interface users to use their cards with alsa, if in a somewhat round-about way. But there are other reasons as well.
<TheMuso> However, it didn't happen due to lack of time by those involves
<TheMuso> s/involves/involved/
<ScottK> Right.  So maybe for Lucid.
<TheMuso> I am thinking that archive reorganisation may help resolve this problem/
<TheMuso> ScottK: Right.
<spstarr> im not happy at all my new laptop conveniently disables PCM capture
<spstarr> DRM shit
<TheMuso> spstarr: I don't think its to do with the laptop, its to do with the Linux driver, depending on what audio hardware you have.
<jdong> I'd say you're too quick to jump to conclusions!
<spstarr> jdong: from what I read, there is no capture on these cards at all
<TheMuso> these cards being?
<spstarr> â Card: HDA Intel                                                                                                   â
<spstarr> â Chip: Conexant CX20561 (Hermosa)
<TheMuso> ah ok
<spstarr> Conexant isn't eactly FLOSS friendly at ALL
<spstarr> with that old linuxant shit
<spstarr> thanks Lenovo!
<jdong> how was linuxant Conexant's fault per se?
<spstarr> its not
<jdong> the whole issue with a software modem is that the modem is just physically two wires
<spstarr> but this company 'Conexant' is making things difficult for me now in Audio
<spstarr> nevermind models
<jdong> linuxant was a third party attempt to reimplement the modem part in software :)
<lifeless> uhm, linuxant licensed the IP didn't they?
<jdong> lifeless: ah yes that may have been; at least licensed some part of the IP
<jdong> considering the DIL tone was the same as the original Conexant drivers probably more or less the entire modem software :)
<spstarr> ooh i got it working.. almost
<spstarr> until the audio just hangs :(
<spstarr> hah I got it working with jack
<spstarr> evil
<spstarr> I can record audio from jackd via jack_capture (obscure tool)
<pitti> Good morning
<pitti> mdke: thanks
<pitti> tkamppeter_: hih
<pitti> erm, "hi"
<mdke> pitti: it didn't work to remove the fdupes script - something else has run a similar script anyway in the package build - http://paste.ubuntu.com/292122/
<mdke> pitti: I don't know where that has come from though, it isn't in debian/rules
<mdke> ah, it's in /usr/share/cdbs/1/rules/debhelper.mk
<mdke> perhaps someone can tell me how to exclude that script?
<geofft> ... wait, do you just want to set CDBS_NO_GNOME_HELP_SYMLINKING=1?
<mdke> geofft: yes
<pitti> mdke: right, we do that by default now, but these aren't meant to interfere; hm
<pitti> mdke: seems like the symlinking to help-langpacks/ is buggy then :-(
<mdke> pitti: can't I just disable it by setting CDBS_NO_GNOME_HELP_SYMLINKING?
<pitti> mdke: you can
<mdke> that should work, no?
<mdke> the help-langpack thing isn't interfering because this is a local build without that
<pitti> it works around the problem, yes
<mdke> I suppose all packages with Gnome documentation should be setting CDBS_NO_GNOME_HELP_SYMLINKING, not just ubuntu-docs
<mdke> otherwise the same bug will appear in those packages, maybe
<pitti> mdke: I should probably just disable it for now, since with stripping them out we don't need to symlink them any more
<pitti> oh, wait, we do
<pitti> they only point to the C version, which is already installed with the package
<pitti> mdke: would you mind reporting a bug against cdbs with the particular failure you see, and assign it to me?
<pitti> mdke: I'm interested in what actually goes wrong
<dholbach> good morning
 * mneptok waves to various .de peoples
<mdke> pitti: ok. should I disable this in ubuntu-docs and gnome-user-docs anyway? if so, could you show me how to do it? :p
<pitti> mdke: if it wreaks havoc, just disable it, yes
<pitti> export CDBS_NO_GNOME_HELP_SYMLINKING=1
<pitti> mdke: sorry, without the "export"
<mdke> just somewhere at the top of debian/rules?
<pitti> yes
<mdke> ok, thanks
<mdke> pitti: I think we can use the same bug and just open a cdbs task
<mdke> pitti: ok, so it's bug 441401 - thanks for the help
<ubottu> Launchpad bug 441401 in ubuntu-docs "Symlink not working with Karmic translations" [High,In progress] https://launchpad.net/bugs/441401
<pitti> mdke: thanks
 * mvo_ hugs doko__ for his super fast python fix
<tkamppeter> pitti, hi
<doko> mvo_: do you have an idea about bug #448140? I do see this with other packages as well.
<ubottu> Launchpad bug 448140 in python2.6 "package python2.6-minimal 2.6.4~rc1-0ubuntu1 failed to install/upgrade: error writing to '<standard output>': Input/output error" [Undecided,New] https://launchpad.net/bugs/448140
<seb128> dholbach, you should stop using pbuilder for every build ;-)
<mvo_> doko: looking
<doko> mvo_: no info in the log, but the subject "error writing to '<standard output>': Input/output error" repeats
<mvo_> doko: odd, nothing in the log - I will followup and move away from python (that is most certainly not a python issue)
<mvo_> doko: there seems to be a lot of those reports
<mvo_> hey glatzor!
<glatzor> morning mvo_ !
<doko> mvo_: when do these start?
<mvo_> doko: the earliest so far is 2009-09-28, but LP is not that great for bug searches, I look further
<mvo_> doko: my initial guess is that its packagekit releated, but I'm not sure yet
<mvo_> hm, no. there is one report about the software-center
<glatzor> mvo_, reports that affect me too?
<mvo_> glatzor: I don't think so, but I'm not sure yet, its inconclusive at this point
<AnAnt> Hello, can some sponsor this: http://revu.ubuntuwire.com/details.py?upid=6920 ? It's FFe request has been approved (LP 440153)
<ubottu> Launchpad bug 440153 in sabily "FFe: Add an xsplash theme for Sabily" [Wishlist,In progress] https://launchpad.net/bugs/440153
<seb128> dholbach, will you sponsor that gdm update?
<dholbach> seb128: it didn't build for me - does it build for you?
<seb128> dholbach, I didn't try but there is no change in the build system so no reason for it to start breaking
<seb128> dholbach, I would rather blame your pbuilder ;-)
<seb128> let me try
<pitti> tkamppeter: hm, seems your host name->ip change now causes build failures :-( (http://launchpadlibrarian.net/33580906/buildlog_ubuntu-karmic-i386.cups_1.4.1-5_FAILEDTOBUILD.txt.gz)
<seb128> dholbach, build fine there, I will upload
<seb128> is there any known libssl issue?
<seb128> I got some gnome builds failing on -lssl not being there
<seb128> ie some .pc or .la or something listing but not having the corresponding depends
<dholbach> seb128: thanks
<dholbach> shouldn't ubuntu-xplash-artwork be Arch:all?
<seb128> dholbach, it should
<dholbach> kenvandine: ^ :)
<directhex> thanks ttx
<ttx> directhex: np
<directhex> ttx, quite embarrassing issue - but it was news to upstream (and is now my first proper upstream patch for mono, svn r143994)
<taavikko> just wondering why I have the "vitruvian man" on my notification-area, while there's no accessibility features enabled?
<apw> cjwatson, the _all packages, am i correct in understanding that they are actually constructed on all architecture builds, but they are only taken from i386?
<maxb> apw: They aren't even built on any arch but i386
<maxb> It's the difference between dpkg-buildpackage -B and -b
<apw> so the buildd's do -B ?
<maxb> Pretty sure they do, yes
<apw> maxb, thanks ... makes much more sense here now ...
<cjwatson> apw: yes, what maxb said. i386 buildds do -b and everything else does -B.
<apw> now getting _all out of my armel builds makes sense
 * apw mutters as he wanders off to get a bigger brain fitted
<debfx> seb128: could you please have a look at my pidgin debdiff at bug #346840
<ubottu> Launchpad bug 346840 in pidgin "Buddy List taskbar icon shows on all virtual desktops" [Low,Confirmed] https://launchpad.net/bugs/346840
<debfx> it fixes that bug and provides a workaround for wrongly sized tray icon on kde
<Riddell> yay
<seb128> debfx, what is the rational for the scrollbar value change?
<seb128> debfx, the kde hack looks weird too, what about fixing kde rather than adding weird hacks to pidgin?
<seb128> debfx, I'm not sure about any of those 3 changes...
<debfx> seb128: the preferences dialog got bigger, it needs around 700px
<seb128> debfx, the purpose of the patch is to add scrollbars to fit on screen though no?
<seb128> that value should match netbook resolution
<debfx> seb128: afaik kde says the system tray specification is broken regarding to icon size and I'm not sure if it affects other desktop environments as well, but kde always uses 22x22 tray icons so the patch doesn't have negative effects on kde
<seb128> debfx, could you upstream that workaround just to get their opinion?
<debfx> I hope the problems are gone when pidgin switches from eggtrayicon to gtkstatusicon
<seb128> there is no such hack in other softwares, ie rhythmbox
<seb128> I think adding one there is not the way to go
<debfx> are they using eggtrayicon?
<seb128> no
<\sh> grmpf...Karmic you have a problem
<seb128> why is pidgin still using that?
<seb128> the correct fix would be to port pidgin to modern apis ther
<debfx> because they don't want to depend on higher gtk versions
<seb128> there
<debfx> they want to raise the gtk requirement in pidgin 2.7
<seb128> well so if that works in gtkstatusicon there is a bug in pidgin
<seb128> and the way to go is to fix it
<debfx> true, but I doubt anyone will fix eggtrayicon
<debfx> especially not in time for karmic
<seb128> I'm not qualified to judge that hack since I've no clue about how kde is buggy there
<seb128> and why it doesn't handle correctly icons
<seb128> so I will not upload that hack
<seb128> I will wait on ted's comment about the focus issue though
<seb128> thanks for you work on that
<debfx> regarding the scrollbars: don't we want the preference window to display correctly on 7XX resolutions?
<Riddell> seb128: it would be polite to assume that KDE isn't buggy since every other app works fine
<seb128> I've to go for lunch bbl
<seb128> Riddell, and pidgin works fine in any other de too
<seb128> debfx, we want but we want those to be displayed correctly on netbooks too
<Riddell> seb128: so there's no reason to think which side is at fault and it's probably as debfx says the spec which is buggy and incomplete
<seb128> the change will make it not fit on smaller screen no?
<seb128> Riddell, whatever I don't care, I'm just not going to upload that workaround since it seems wrong, if the code is buddy fix it, that works with other applications now
<seb128> really have to go for lunch
<seb128> bbl
<apw> pitti, i think we have found the FAT slow mount issue, and i've pushed some test kernels (linked in the bug) ... if we want to get it in before  kernel freeze we need to get it tested pronto
<pitti> apw: my hero!
<pitti> I'm happy to test them
<apw> wicked
<apw> it was a long old day finding that one
<\sh> if someone could do me a favour, please review debdiff from bug #401982 and push it to the buildds? Thx :)
<ubottu> Launchpad bug 401982 in quilt "quilt_0.46-7 still same error on intrepid" [Undecided,Fix committed] https://launchpad.net/bugs/401982
<amitk> apw: so what was the issue?
<apw> readahead requests were not merging in the elevator at all, leading to sychronous 512 byte reads of the FAT
<\sh> brb lunch
<amitk> apw: at the VFS layer?
 * pitti hugs magic Andy
<pitti> apw: it works perfectly, thanks
<apw> pitti, wicked thanks ...
<apw> anyone know if we are expecting fsck to trigger usplash like it used to atm?
<pitti> apw: I think we resorted to always starting usplash onw
<pitti> s/onw/now/
<pitti> but in lucid, it's supposed to
<apw> yeah i had usplash, the new sexy logo
<apw> but then it went into 20 mounts without fsck, fsck
<apw> and usplash said nothing then timed out and showed it to me behind
<apw> but no sexy progress bar, no hit esc option
<apw> pitti, ^^
<apw> i presume that that is a bug then
<pitti> right, looks like
<pitti> I'll have a look at it, noted on my TODO list
<apw> pitti, thanks
<debfx> seb128: for netbooks nothing will change, if the screen resolution is 1024x600 it doesn't matter if I check <=600 or <=700
<seb128> debfx, I've to read what the change do then, would be nice to give explanation in the bug next time
<seb128> debfx, ok, the 700 change makes sense after looking at the dialog geometry in karmic, sorry about the too quick replies but I've a zillion things on my list and not always time to look at what other people wanted to do and why if there is no explanation in bugs
<seb128> debfx, I will wait for ted to reply before sponsorting that though just to know if the other change is worth uploading too
<seb128> debfx, I'm not sure we should change the behaviour now just before karmic, ted added that to workaround other issues
<cjwatson> apw: you're not the first one to report that ...
<apw> cjwatson, ok ... so i'll wait for a fix :)
<debfx> seb128: I know but that particular calls I removed don't really help the pidgin window to appear in the front
<seb128> debfx, ted probably added it for a reason though, it might workaround some wm behaviours or something
<debfx> seb128: to me that patch seems like a "try everything that might help" approach, but you're right we should wait for a response from ted
<seb128> debfx, it's sort of that yes since standard calls were not doing what is expected
<zul> pitti: ping
<pitti> zul: pong
<zul> pitti: i been working on the m2crypto testsuite failure and its still not building properly
<zul> i tried updating it my ppa and it still suffers from the same problem but it builds fine locally
<pitti> zul: I guess it needs network of some sort?
<zul> pitti: it looks like it but it says its connecting to a localhost
<Hattory> Hi all is it possible that all icons and folders, after the last update in karmic, have the <ubuntuone-synchronized> emblem applied?
<zul> pitti: i was thinking of opening up a bug in the upstream bug tracker and trying to get it fixed for lucid
<pitti> zul: yeah, makes sense
<pitti> zul: I think for karmic you should just || true the test suite, so that the results are in teh build logs, but it doesn't fail the build
<zul> pitti: ok i can do that ill let you know when I uploaded it
<pitti> apw: I like your definition of "obvious fix" :-)
<apw> pitti, i think the fix is obviously correct even to those not looking at the rest of the code, now finding the issue ...
<pitti> apw: I was just kidding; I didn't understand a word of your bug explanation :)
<apw> :)
<\sh> re
<liw> I seem to be totally unable to track down bug #420307 -- mysterious segfaults in computer-janitor for some people. My best guess it's a python/pygtk/threading problem, but I can't see where, and I can't reproduce either. Any ideas?
<ubottu> Launchpad bug 420307 in computer-janitor "computer-janitor-gtk crashed with SIGSEGV in gdk_window_set_geometry_hints()" [Medium,Confirmed] https://launchpad.net/bugs/420307
<tgpraveen> lool:  https://bugs.launchpad.net/ubuntu/+source/humanity-icon-theme/+bug/436462 can you please upload the changes for this
<ubottu> Launchpad bug 436462 in humanity-icon-theme "Have different icons for usb hardisks and pendrives" [Undecided,Confirmed]
<tgpraveen> it would really increase usability/visibility and is something
<seb128> liw, get a valgrind log for the crash?
<tgpraveen> that many people have asked for on different bugs and the change is already on upstream and has very little chance of breaking anything
<liw> seb128, I'll ask bug submitters for that... how would they do that?
<seb128> liw, https://wiki.ubuntu.com/Valgrind
<seb128> liw, for python software you need to run valgrind python binary
<seb128> not valgrind binary directly I think
<mterry> cjwatson, it looks like you looked into sponsoring bug 430220 at some point in the past.  Can you (or Keybuk) look at it again?  I'd like to get this in before release.  It prevents delays in logging messages due to buffering (and has some cleanup as well)
<ubottu> Launchpad bug 430220 in rsyslog "[karmic] Upstart fixups" [Undecided,Confirmed] https://launchpad.net/bugs/430220
<liw> seb128, thanks, let's see what happens
<seb128> ok
<seb128> so the build failures in rhythmbox and totem are doko's fault
<seb128> /usr/lib/python2.6/config/Makefile: LOCALMODLIBS=                       -lssl -lcrypto  -lssl -lcrypto      -L$(exec_prefix)/lib -lz
<seb128> but python2.6 doesn't install those libs
<seb128> doko, ^ do you know about that? is that something which changes recently?
<lool> tgpraveen: I was told it's not release critical and will only consider it if I update h-i-t for another reason; it took me hours to understand + review the last icon changes I had to upload, so I'd prefer avoiding that happening again
<doko> seb128: yes, that was a bug fix for python2.6. It's a mistake to link extensions with LOCALMODLIBS, just remove it
<seb128> doko, it makes several packages ftbfs out of the blue, will we do an archive rebuild test to spot those now?
<seb128> doko, otherwise I would argue to wait until karmic+1 for the fix since it breaks things which were working
<cjwatson> 0/wg 166
<cjwatson> (sorry
<lool> Does someone know how to fix a non-booting system like this onw http://people.canonical.com/~lool/IMG_2345.JPG?
<lool> One error is binfmt misc being missing in the dove kernel, not sure if that's the reason for the failure
<seb128> doko, ?
<doko> seb128: that was the fix for #445540
<doko> #445530
<seb128> bug #445540
<ubottu> Bug 445540 on http://launchpad.net/bugs/445540 is private
<seb128> bug #445530
<ubottu> Launchpad bug 445530 in python2.6 "dh_pysupport -a fails in private/movemodules with python2.6" [Undecided,Fix released] https://launchpad.net/bugs/445530
<seb128> doko, any reason you couldn't add the lib as python-dev depends?
<doko> seb128: I'll look at it tonight, but it would just hide the problem.
<seb128> doko, what problem? rhythmbox and totem and some other things fail to build right now...
<seb128> would be nice to get that fixed quickly
<seb128> those software have not changed and building them works fine on other distros or karmic before your change
<doko> seb128: the correct fix is not to link with LOCALMODLIBS; I'll look at a workaround later today
<seb128> doko, thanks
<seb128> doko, could be but it's late now in the cycle to break all software doing that
<doko> seb128: no, it was a fix for another bug which obviously has side effects
<seb128> doko, ok, thanks for looking into it
<lool> Keybuk: hey, I get http://people.canonical.com/~lool/IMG_2345.JPG with a mountall from a couple of days ago; there's notably a binfmt misc missing error (reported already) but I'm not sure what's failing the boot exactly nor how to recover
<lool> Keybuk: I can remount / rw and mount /boot but if I ^D, only the network comes up and not gdm etc.
<Keybuk> did you update mountall today?
<lool> I cant find that /forcefsck thing on any fs
<lool> Keybuk: No, I'd like to...
<Keybuk> right, that one's fixed
<lool> Keybuk: It's the one from one or two days ago
<lool> Keybuk: What shall I do to resume boot?
<lool> I have a /, a /boot, swap, all with UUID in fstab; I only have proc in fstab apart of that IIRC
<lool> Keybuk: Do I have to manually dpkg -i mountall from an USB stick or smth?
<mvo__> kirkland, hi - I noticed that that kvm got replaced by qemu-kvm. could you please add a transitional package to ensure that it upgrades smoothly? currently its considered obsolete and removed after a upgrade (apt is unfortunately not very clever when it comes to understand that it really should install qemu-kvm instead)
<mvo__> kirkland, I'm happy to report a bug and/or do that myself (should be quick and easy)
<zul> asac: yes I need tht review for libaugeas-ruby
<mathiaz> mvo__: hi!
<mathiaz> mvo__: thanks for adding some upgrade logic to update-manager to handle the mysql upgrade
<mathiaz> mvo__: IIUC a plain dist-upgrade won't work in karmic
<mathiaz> mvo__: however a do-release-upgrade will correclty update mysql-server from 5.0 to 5.1
<mvo__> mathiaz, correct - sorry that I haven't found a good way for the plain dist-upgrade
<mvo__> mathiaz, we should just release note it, it should be simple enough to fix for people faimilar with apt-get
<mathiaz> mvo__: that's fine. We can document it in the release notes as well
 * mvo__ nods
<mathiaz> mvo__: something related to the mysql upgrade
<mathiaz> mvo__: 5.0 supports cluster, while 5.1 doesn't
<mathiaz> mvo__: so there is a check in the preinst script - if cluster is enabled the package upgrade fails
<mathiaz> mvo__: I was wondering if we could some logic to update manager
<mathiaz> mvo__: if there is a cluster configured, remove the mysql-server package (but leave mysql-server-5.0
<mathiaz> )
<mvo__> mathiaz, yes, we should
<mvo__> mathiaz, how hard/reliable is it to detect ?
<mathiaz> mvo__: reliable - it's a grep in some configuration files
<mathiaz> mvo__: the logic is already in the preinst script
<mathiaz> mvo__: right now the package fails with an error message
<mvo__> mathiaz, ok cool - I can add that to the upgrade, thats pretty easy. could you just add a bug and target for 9.10 ? I will do it today
<mathiaz> mvo__: ok - I'll file a bug
<mvo__> mathiaz, thanks
<lamont> so how do I get something wider than 1 pixel borders on my windows again?  grabbing the little beggars with the thumbpad is kinda challenging
<Gp> i ma getting Invalid execution envioroment at grub
<Gp> i ma getting Invalid execution envioroment at grub
<cjwatson> Gp: I don't think you are; I think you're more likely to be getting the message "invalid: environment block"
<cjwatson> Gp: see bug 439784
<ubottu> Launchpad bug 439784 in grub2 "invalid: environment block" [High,Fix committed] https://launchpad.net/bugs/439784
<scoop21> Einen wunderschÃ¶nen Tag zusammen
<lamont> Well, this is embarrassing.  <-- yay for firefox. :-(
<wolfe> ?
<lamont> amusingly, leaving all the tabs selected and choosing 'restore' gets me a working firefox
<lamont> wolfe: firefox can't restore the session
<wolfe> :) oh how I know that too well
<lamont> I wonder if it has anything to do with needing passwords to loginto stuff
<wolfe> I've disabled much of the bloat which causes firefox to mess up
<lamont> wolfe: execpt for the part where the session restores just fine when you say "oh, try anyway, kthx"
<wolfe> yeah... isn't that nice?
<wolfe> it crashed on me twice yesterday when I had all the default bloat enabled, and FF actually apologized asking which session to restore
<scoop21> Hi guys in the house
<sistpoty|work> maybe a procrastination avoidance feature? :P
<wolfe> heh
<lamont> I do hate it when coders think their program should apologize.  just wrong.
<LaserJock> lamont: I suppose it's better than having them insult you
<lamont> LaserJock: pretty much the same, actually
<LaserJock> it's more like an insult with a smile
<liw> lamont, my most sincere and humble apologies for having written a program that apologized, please let me assure in the strongest possible way that this will not be a unique instance
<lamont> liw: meh
<liw> :)
<lamont> window panel bar is totally weird, too.
<lamont> so if anyone asks, no, you many not like the results of running a jaunty kernel with your karmic system
<scoop21> does anybody tried to install karmic on a laptop?
<lamont> scoop21: aside from loosing support for winxppro sp>=2 in kvm, it's been working pretty OK for me
<lamont> some _might_ see that as a feature
<scoop21> lamont: do you tried to plugging ac/battery?
<lamont> liw: long ago I came to realize that parts of the kernel have gender.  Then I realized that gender  was based on who owned that component in the OS I  was working on a the time.
<lamont> scoop21: suspend/resume even works much of the time - big improvement over the last time I tried it.
<lamont> and yeah, AC and battery op both happy
<kirkland> mvo: hi
<lamont> haven't tried hibernaet yet
<Gp> https://bugzilla.mozilla.org/show_bug.cgi?id=439784 not opening
<ubottu> Mozilla bug 439784 in Networking: Cookies "Chrome XMLHttpRequest does not send/set cookies if third-party cookie's are blocked" [Normal,Resolved: duplicate]
<kirkland> mvo: would you mind sending me a quick debdiff for the transitional package?
<kirkland> mvo: i'm working on a couple of other high priority things at the moment :-/
<kirkland> mvo: including adding a critical patch to qemu-kvm
<mvo> kirkland: sure, I can also do the upload
<mvo> kirkland: oh, ok
<kirkland> mvo: i'd like to fix both with the same upload
<mvo> kirkland: yeah, I file a bug with patch then - or is there a vcs I should use?
<scoop21> lamont: mhh, tried to boot with both ac and battery and than plugged ac out and so?
<kirkland> mvo: bug with patch is best for now
<spaetz> scoop21, works like a charme here
<mvo> kirkland: thanks
<lamont> scoop21: booted with and without AC, plugged and unplugged, even suspended.. all with good happiness.
<kirkland> mvo: thank you :-)
<lamont> OTOH, networkmangler has decided that eth0 is non-existant
<lamont> brb
<scoop21> lamont: which label do you have?
<lamont> scoop21: label?
<lamont> the laptop is a dell inspiron 1520 with an ubuntu label. :-)
<lamont> gory details of the machine in bug 445456
<scoop21> lamont: haha, yes i meant the producer
<ubottu> Launchpad bug 445456 in linux "kvm hangs booting windows XP Pro SP2 or later, since at least 2.6.28-15" [High,New] https://launchpad.net/bugs/445456
<liw> mvo, there's at least two instances of openoffice packages being corrupted (uno and ure packages)... update-manager does check the checksums, so that's worrying
<scoop21> lamont: you hasn't that bug too? -> https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/432838
<mvo> liw: it is - my theory is currently that it arrives ok from the net and gets corrupted when writing out to disk - i have test code that tries to download files with invalid checksums and that errors out
<ubottu> Launchpad bug 432838 in pm-utils "laptop goes standby after gnome login on battery" [Undecided,New]
<mvo> liw: but I'm still worried because its just so scary
<LaserJock> james_w: is http://jameswestby.net/bzr/builddeb/user_manual/ an authoritative place to get info on using bzr-builddeb?
<liw> mvo, given that oo.o files tend to be a bit large, I guess it's possible that two people would have problems with them, but it's still a bit of a coincidence
<zul> pitti: it still fails if I add the || true
<mvo> liw: it calculates the checksum from the network data, not from the on-disk data (maybe it should)
<mvo> liw: absolutely!
<lamont> scoop21:  sounds like you have ntp coming up and snapping your clock forward far enough for gnome to go "ZOMG long time idle -> suspend"
<lamont> go edit things to not suspend for a couple hours or more of idle, and see if that makes it go away
<mathiaz> cr3: hi
<mathiaz> cr3: re checkbox sponsorship request - there are some new strings in there
<cr3> mathiaz: yo
<mathiaz> cr3: and we're in String Freeze
<cr3> mathiaz: new strings?
<scoop21> lamont: i tried to change something but there are no much possiblity
<mathiaz> cr3: po/checkbox.pot
<mathiaz> cr3: some new strings, some have been removed
<mathiaz> cr3: 'Fixed backend to use dbus instead of policykit' <- how is that a bug fix rather than a new feature?
<cr3> just the string "Info" has been added, maybe I could remove that
<cr3> mathiaz: I needed to either migrate to polkit-1 or just use dbus, pitti and I agreed it would be preferable to just use dbus
<mathiaz> cr3: and this is acceptable for karmic?
<pitti> mathiaz: the old policykit is deprecated, and it's not even installed any more
<pitti> mathiaz: which means that checkbox doesn't work at all ATM
<mathiaz> pitti: ok
<pitti> mathiaz: so at the very least, it needs to grow a policykit dependency to work at all
<pitti> but it'd be the only thing which needs it
<cr3> mathiaz: fyi, pitti also reviewed my change and he approved the dbus part
<pitti> mathiaz: the actual PK changes in that branch are essentially "remove all PK code"; there are other (unrelated) code changes which I couldn't assess
<lamont> right.. back to a karmic kernel
<cr3> mathiaz: the other unrelated code changes were because the old policykit wasn't even working before and had been neglected, so I needed to update the code accordingly
<james_w> LaserJock: /usr/share/doc/bzr-builddeb or there
<LaserJock> james_w: k
<cr3> mathiaz: this problem had been worked around by using gksudo instead of using the dbus backend, but that was an unfortunate hack
<Aji-Dahaka> fellas, I reported a bug (449935) which was marked duplicate of a non-public bug (443340) by apport service.  The message asks me to look at the other bug report, though I can not.  What does one do to address this situation?
<Aji-Dahaka> (if this is actually a #ubuntu question, let me know and I'll migrate it there)
<Aji-Dahaka> join #ubuntu
<Aji-Dahaka> (sorry, missed the / *sigh*)
<kirkland> mvo: would you ping me here when you file that bug/patch?
<kirkland> mvo: i'm building/testing my other changes now
<mvo> kirkland: sure, I'm test-building (to be sure its all good) currently
<kirkland> mvo: cool, thanks
<mvo> liw: I just created a fault-injecting proxy and get a error (as expected) - not only one, loads of them .)
<liw> mvo, whee
<mvo> (checksum mismatch)
<liw> I'd expect checksum mismatches if packages got garbled on the wire
<mvo> liw: yes, that is whats happening
<mvo> liw: the file does not make it on disk
<Keybuk> mvo: I keep seeing lots of duplicates of "standard output: No such file or directory" errors from apport about upgrades
<liw> mvo, but the bug reports had errors at a later stage, so your theory of corruption happening while writing to disk seems fair
<mvo> Keybuk: I looked into that briefly this morning without much success, no pattern yet afaics
<mvo> liw: it may well be something in the apt http downoader that write the data out wrongly
<Keybuk> mvo: indeed
<Keybuk> I've had that reported for a number of different packages
<Keybuk> including mountall, which has no maintainer scripts *at all*
<mvo> Keybuk: I have done a LP search and see about ~30 or so of them
<mvo> Keybuk: yeah, eglibc
<mvo> and the like, initially it looked like kpackagekit, but I got one report from software-center too
<Keybuk> right, I initially thought kpackagekit too
<Keybuk> in fact, I started assigning them there to begin with
<mvo> oh, that was you then :P
<Keybuk> the two more recent ones weren't with that though
<Keybuk> :p
<Keybuk> mvo: I've probably had more reasons than most to be on top of my bugs folder these last couple of weeks
<mvo> there is/was a similar bug in kpackagekit
<mvo> don't talk to me about my bug folder, that makes me cry
<Keybuk> mine has zero unread ;P
<mvo> Keybuk: heh :) because of the upstart changes?
<mvo> zero? impressive!
 * mvo hands Keybuk a virtual cup of finest green tea
<Keybuk> all bugs are either in "know what causes it, it's in my notebook to fix" ... "know what causes it, I'll fix it later" ... "no idea, too low priority to care about" ... or ... "needs more info" stages :p
<Keybuk> mvo: I still can't beat seb on the bug traffic volume though
<mvo> haha - he got *years* of experience and probably a twin brother that he hides from us
<Keybuk> wasn't it you that had the twin brother? :p
<davmor2> Keybuk: No he has a clone :D
<liw> I'm convinced seb128 is just a front for a secret French government agency that processes bug reports on the same supercomputer Lucas uses
<Keybuk> cjwatson: so I think there must be still a usplash b ug
<Keybuk> if I boot with "splash" my consoles are corrupted when I switch away from X
<liw> mvo, bug #412806 seems weird... we've not had to start update-manager as root for several releases, have we?
<ubottu> Launchpad bug 412806 in update-manager "update-manager no longer setuid, fails for non-root" [Undecided,New] https://launchpad.net/bugs/412806
<mvo> liw: *weh* it was noever setuid
<mvo> liw: and yeah, no need to run it as root since ages
<cjwatson> Keybuk: hmm, I had that until I arranged to be more careful about tearing down usplash before X starts
<cjwatson> Keybuk: can you tell whether that's happening?
<cjwatson> I guess an upstart debug log might be handy
<Keybuk> cjwatson: "more careful" ?
<mvo> Keybuk: a twin sister, but she refuses to do work for me :P
<Keybuk> mvo: ah, that was it! :)
<Keybuk> cjwatson: yeah, was going to stick a log-priority debug in there somewhere and see if I could capture the job transitions
<liw> I haven't had this many false highlights since twin peaks went out of style
<cjwatson> Keybuk: I think I cavalierly tried to start X without tearing down usplash at one point during testing :-)
<liw> mvo, but in very ancient times it was necessary to start u-m with sudo, wasn't it? anyway, I'll note that it shouldn't be needed in the bug
<mvo> liw: yeah, a long time ago
<Keybuk> cjwatson: yeah, the whole starting-dm thing should be enough
<PedroLeKoi> Riddell: I wrote the iso file on a CD and I am trying to run that CD now one way or the other.
<Keybuk> there won't be a usplash process when that finishes, etc.
<PedroLeKoi> Riddell: Thing is that the boot process is interrupted pretty early.
<PedroLeKoi> Riddell: Error message:
<PedroLeKoi> Riddell: (initramfs) ata2.0: revalidation failed (errno=-5)
<PedroLeKoi> Riddell:     ata2: COMRESET failed (errno=-16)
<PedroLeKoi> Riddell:     ata2: exception Emask 0x1 SAct 0x0 action 0x0 t4
<PedroLeKoi> Riddell:     ata2: irq_stat 0x40000008
<Keybuk> I wonder whether this is actually something to do with the nvidia agpgart or driver
<mvo> liw: it looks like for some reaosn his permissions are (very) wrong
<Riddell> PedroLeKoi: it doesn't boot up into a running live CD system?
<PedroLeKoi> Riddell: Right.
<Riddell> PedroLeKoi: maybe the CD did not burn properly, do you have another CD you could burn to?
<PedroLeKoi> Riddell: What is the meaning of 'ata2'. Does it mean the (sata) hdd, partition 2?
<Riddell> PedroLeKoi: I don't honestly know.  it's possible your hardware is too new for hardy so it's not possible to run the install at all
<PedroLeKoi> Riddell: Maybe it's just because I formatted the hdd with 'ext3'?
<PedroLeKoi> Riddell: If that is the reason I can take an other live CD to reformat the partition.
<cjwatson> ata2 is more likely to mean the third disk the kernel has seen on the ata bug
<cjwatson> bus
<Riddell> PedroLeKoi: your hard disk formatting doesn't matter, it's not using the hard disk
<Riddell> PedroLeKoi: try burning another CD and if that doesn't work we can use a chroot instead for the install
<PedroLeKoi> cjwatson: So it's maybe a question of the amount of data? sda0: swap, 4GB; sda1: /, 40GB; sda2: /home, 150GB.
<Riddell> PedroLeKoi: no that won't be a problem
<liw> do we support direct upgrades from LTS to each release before the next LTS? or should the upgrades go through intermediate releases? i.e., hardy->karmic or hardy->intrepid->jaunty->karmic?
<Riddell> PedroLeKoi: please join #kubuntu-devel, this channel is a bit too general
<PedroLeKoi> Riddell: I am working on my second laptop right now. This one is much older than the former one. So I am going to try to run the live CD on that one first. I am pretty sure that the CD is allright.
<liw> heh, a bug report with a video of the bug as the attachment
<Riddell> malone will soon be replaced with youtube
<mvo> much more fun this way too
<liw> (#450451)
<liw> mvo, and he's using a funny font, too
<davmor2> liw: sometimes it's easier to describe it and have the dev understand what your on about too :)
<liw> davmor2, sure, it's an excellent idea
<liw> only problem is... after I mentioned the bug number, LP stopped talking to me :P
<mvo> liw: he does :)
<debfx> tedg: could you please have a look at bug #346840, it seems to be caused by your buddy_list_really_show patch
<ubottu> Launchpad bug 346840 in pidgin "Buddy List taskbar icon shows on all virtual desktops" [Low,Incomplete] https://launchpad.net/bugs/346840
<joaopinto> Keybuk, I also have corrupted VTs with ATI, so it's not nvidia related
<cjwatson> s/not/not only/
<cjwatson> (I'm on Intel here and it works fine ... of course this could be a red herring)
<Keybuk> indeed, it's just a wild guess
<davmor2> Keybuk: I can confirm on ati on nvidia on both nv and nvidia, radion and fglrx drivers if that helps.  In fact intel is the only one without the issue
<joaopinto> aren't we a bitt advanced on the dev cycle to be experimenting boot changes ?
<cjwatson> joaopinto: consequence of boot changes made at alpha 6
<superm1> mvo, re bug 413789, how will someone know if they have the update manager with this fix in it?
<ubottu> Launchpad bug 413789 in mysql-dfsg-5.1 "mysql-server has been kept back with dist-upgrading" [High,Fix committed] https://launchpad.net/bugs/413789
<kirkland> cjwatson: around?
<kirkland> cjwatson: i think this is a typo, want to check with you though
<kirkland> cjwatson: $ grep -n configure_interface eucalyptus-udeb.finish-install
<kirkland> 156:configure_interface () {
<kirkland> 235:    configure_interfaces
<cjwatson> kirkland: yes, that's a typo
<cjwatson> should be configure_interfaces in both places
<cjwatson> nice catch
<kirkland> cjwatson: i wonder if that might help our dhcp/static issue
<cjwatson> worth a go
<kirkland> cjwatson: i was just fixing that with some nasty grepping and sedding
<kirkland> cjwatson: what's the best way for me to inject this change into an install?
<joaopinto> superm1, once the package which fixs that bug get's built it will set the bug to fix released and will display the version
<kirkland> cjwatson: build the udeb and copy into the install ?
<superm1> joaopinto, there is no update-manager task for it
<joaopinto> superm1, ah :|
<statik> hi slangasek, do you have 10 minutes for a phone call? I'd like to get some advice/guidance from you on evaluating the risk of a couchdb update
<cjwatson> kirkland: nah, just edit /usr/lib/finish-install.d/whatever with nano
<kirkland> cjwatson: perfect; willd o
<kirkland> will do
<Keybuk> joaopinto: I'd still rather play around now than before LTS beta ;)
<joaopinto> Keybuk, sure, but still it's an high risk change during post beta :P
<Keybuk> which are you talking about?
<joaopinto> Keybuk, broken VTs
<cjwatson> the change wasn't "break people's VTs, we'll fix it up later"
<Keybuk> joaopinto: well, that kind of change would be a "bug fix" :)
<cjwatson> the change was to fix other high-priority bugs
<cjwatson> and whatever this is appears to have been an unforeseen consequence
<joaopinto> ah ok, so it's a fix, sorry
<cjwatson> assuming of course that this was caused by usplash changes
<Keybuk> bugs are a bit like bubbles in wallpaper
<Keybuk> when you push one out, another one appears somewhere else
<Keybuk> the aim of the release is to make sure that they're all hidden behind bits of furniture
<robbiew> fwiw, I have the no VTs issue on my nvidia box, if you guys need some debugging or testing...just let me know
<Keybuk> well, the first obvious test will be to stick "sleep 10" in between usplash exiting and gdm starting ;)
<free> mathiaz: hey
<robbiew> Keybuk: and where would I put that sleep
<Keybuk> robbiew: in /etc/init/gdm.conf after the initctl emit
<robbiew> l
<robbiew> k
<robbiew> Keybuk: no change
<Keybuk> that's interesting
<Keybuk> that tells us that this is a pure usplash bug
<Keybuk> and it's not racing with gdm
<Keybuk> robbiew: here's another fun experiment
<Keybuk> remove that sleep
<Keybuk> but then comment out the "start on" lines of the gdm.conf
<Keybuk> then boot
<robbiew> ok...back in a min
<oroz> can someone help me turn off "Emulate3Buttons"?
<robbiew> Keybuk: that was worse, as there was no tty or gdm sessions..I had to remote login and start
<Keybuk> ok
<Keybuk> definitely just a usplash bug then
<Keybuk> was the display black or corrupted?
<robbiew> black...and nothing happened when I tried switching VTs
<stefanlsd> who would be the right channel or person to help me with access to people.ubuntu.com?
<Keybuk> cool
<Keybuk> that fits what I've seen too
<joaopinto> the VT problem was introduced with the latest usplash update right ?
<cjwatson> joaopinto: we don't know for sure
<Keybuk> I'm out for a bit, will look into this when I get back unless someone beats me
<Keybuk> just confirmed both of robbie's tests, so I should be able to debug
<mathiaz> free: hi!
<free> mathiaz: I just sent you an email about the landscape-client
<mathiaz> free: right
<mathiaz> free: I'll look into that later
<free> mathiaz: awesome! thank you
<joaopinto> virtualbox VTs gets a funny (wide) resolution
<kirkland> cjwatson: okay, that one-char fix didn't solve the static ip bug, but I have about 5-lines that does
<kirkland> cjwatson: let me pastebin that for you...
<kirkland> cjwatson: http://paste.ubuntu.com/292543/
<kirkland> cjwatson: i think that should do it; i'm testing now
<NCommander> mterry, ping? You around?
<mterry> NCommander: yes
<NCommander> mterry, I need a promotion for partman-uboot which is a minor installer component which is only present in the live system. Do I really need a full blown MIR for it?
<mterry> NCommander: I assume so.  It can be a somewhat brief MIR.  I'm not comfortable enough with my MIR role to start blessing corner-cutting.  :)
<cjwatson> kirkland: if that works with busybox sed (and, well, generally works), then it's cool by me!
<kirkland> cjwatson: the backreferences work, yes
<kirkland> cjwatson: i'm installing end-to-end now to test
<NCommander> mterry, I should be done with the MIR in another 10-15 minutes, if your still around, mind handling it?
<mterry> NCommander: sure
<LaserJock> cjwatson: were you able to find the issue with the d-i on the Edubuntu DVD?
<kirkland> cjwatson: works like champ!
<kirkland> ttx: the static/dhcp network configuration issue is solved!
<ttx> kirkland: yay
<NCommander> mterry, https://bugs.edge.launchpad.net/ubuntu/+source/partman-uboot/+bug/450605
<ubottu> Launchpad bug 450605 in partman-uboot "Main Inclusion for partman-uboot" [Undecided,New]
 * mterry reads
<kirkland> cjwatson: ttx: i'm regression testing the diff against dhcp nodes
<mterry> NCommander: this is just a split package from something that was already in main?
<NCommander> mterry, no, the original is in universe(?)
 * NCommander isn't sure if it sync'ed across because Soyuz used to reject packages that had no build candidates
<mterry> NCommander: ah
<slangasek> superm1, cody-somerville: are things working better with the latest dailies?  the dbus problem should be fixed now
<cody-somerville> slangasek, it is indeed fixed
<slangasek> and the updated mountall is included in all ISOs
<slangasek> ok, cool
<cody-somerville> kudos
<kenvandine> robbiew, ping
<robbiew> pong
<kenvandine> robbiew, when you had that crash in empathy doing audio/video
<superm1> slangasek, yes much better wrg to that problem
<kenvandine> robbiew, did you see a spike in cpu load by chance?
<robbiew> kenvandine: I honestly don't remember, sorry.  Do you need me to try another call and let you know
<robbiew> ?
<kenvandine> nah
<kenvandine> let me ask around
<kenvandine> :)
<kenvandine> i think i have an idea where the problem is
<robbiew> ok
<superm1> slangasek, i did come across bug 448988 though, which i've milestoned since that was explicitly added functionality
<ubottu> Launchpad bug 448988 in usplash "--pulse-logo doesn't actually pulse the logo" [Undecided,New] https://launchpad.net/bugs/448988
<mathiaz> cr3: is checkbox documented?
<mathiaz> cr3: are there any reference to checkbox in the Ubuntu documentation?
<cjwatson> LaserJock: remind me what it was?
<cr3> mathiaz: not as far as I know, is there any particular consideration you had in mind?
<LaserJock> cjwatson: I get something about multiverse Packages file can't be found
<mathiaz> cr3: the changes in debian/checkbox.pot
<mathiaz> cr3: the addition of the Info string
<mathiaz> cr3: it may have an impact on documentation and translation
<LaserJock> cjwatson: and then in the other VT it says it can't find libnewt0.52, libuuid1, ext2-modules, and efi-modules
<kirkland> cjwatson: ttx: fix looks good, working on both static and dhcp networking
<kirkland> cjwatson: ttx i'm committing
<cr3> mathiaz: I'm quite positive this level of detail about checkbox is not documented, I'm willing to bet my non-existent reputation on it :)
<cjwatson> LaserJock: oh, right, that was a cdimage bug
<cjwatson> LaserJock: not yet but on the list, sorry I haven't managed it yet
<LaserJock> cjwatson: np, just trying to keep an eye on it
<ttx> kirkland: ok
<cjwatson> hmm, scanpackages is kind of unconditional
<mathiaz> cr3: what kind of testing did you do on 0.8.4?
<cr3> mathiaz: I just tested upgrading and running it, but I've also asked davmor2 and fader to kick the tires. one moment, I'll see what was their feedback
<simon-o> fabrice_sp_: bug 447245 has a branch attached which contains the fix. If you need a debdiff I can surely provide it, but imho merging the branch is easier
<ubottu> Launchpad bug 447245 in basket "FTBFS when using automake 1.11 and autoconf 2.64" [Undecided,Confirmed] https://launchpad.net/bugs/447245
<mdke> pitti: around?
<fabrice_sp_> simon-o, I still have to learn how to deal with branch and merging... I'm used to debdiff :-/
<simon-o> fabrice_sp_: ok, no problem I'll attach a debdiff
<simon-o> fabrice_sp_: thanks for sponsoring :)
<fabrice_sp_> thansk ;-)
<fabrice_sp_> thanks for taking care of the bug ;-)
<simon-o> fabrice_sp_: Here is the diff from the merge proposal, is that ok? https://launchpadlibrarian.net/33593085/uIn3Ug7FHgtr2ECEckVu5bKom4a.txt
<fabrice_sp_> seems good
<fabrice_sp_> simon-o, ^
<simon-o> fabrice_sp_: great.
<simon-o> it would be really cool if someone could sponsor bug 428104 for main. This is a regression and should make it into karmic.
<ubottu> Launchpad bug 428104 in lftp "3.7.15 removes support for https" [Undecided,Confirmed] https://launchpad.net/bugs/428104
<kees> cody-somerville: want to use your new super-power for 428104?  :)
<mathiaz> cr3: hm - I've tried to run checkbox-cli
<mathiaz> cr3: and selected network test (f)
<mathiaz> cr3: I was then prompted for two fingerprint reader tests, and a firewire tests
<mathiaz> cr3: which I've skipped - and then a report has been generated
<cody-somerville> kees, sure thing :)
<mathiaz> cr3: is this normal?
<cr3> mathiaz: I'm trying to figure out whether this problem was there before
<cr3> mathiaz: there may still be a bug or two, this candidate release doesn't necessarily fix everything
<mathiaz> cr3: I saw something similar with the fingerprint reader a couple of months ago
<mathiaz> cr3: I was never prompted for the firewire test though
<simon-o> cody-somerville, kees: thanks
<mathiaz> cr3: http://paste.ubuntu.com/292588/
<mathiaz> cr3: is there a prompt missing here somewhere?
<mathiaz> cr3: I was never prompted for an email adresse
<kklimonda> kees, would it be possible to get a micro release exception for Django? Upstream has a strict API policy and lots of regression tests..
<mathiaz> cr3: http://paste.ubuntu.com/292590/
<mathiaz> cr3: ^^ this is when I tried to enter an email address when nothing was happening
<slangasek> does someone know what changed recently to pull ibus-qt4 into the Ubuntu CDs?
<slangasek> was ibus-qt4 recently promoted to main?
<cr3> mathiaz: looking into that problem and I just fixed bug #450673 at the same time
<slangasek> mm, indeed it was
<ubottu> Launchpad bug 450673 in checkbox "Checkbox command line interface does not interpolate $output variable" [High,In progress] https://launchpad.net/bugs/450673
<cr3> mathiaz: that problem was there before, just thought I'd fix while we're at it
<pitti> slangasek: hm, should we fix "Recommends: ibus-gtk, ibus-qt4" to have s/,/|/ ?
<slangasek> pitti: yes; do you want to take care of it?  If not, I was about to
<pitti> can do
<slangasek> bug #449966
<ubottu> Launchpad bug 449966 in ibus "Forced to install ibus-qt" [High,Triaged] https://launchpad.net/bugs/449966
<cjwatson> might want to seed one or the other in each desktop seed, if that hasn't been done already?
<pitti> kubuntu does already (both desktop and netbook)
<pitti> uploaded
<slangasek> pitti: thanks!
<slangasek> now for the other problem, why is a new 4MB openoffice.org style package being pulled in
<pitti> cjwatson, Keybuk: can you please point me to what you changed to have usplash not QUITed on shutdown? (the change that caused the fade-out effect to disappear); I'd like to split QUIT into the old QUIT and a FADEOUT command, so that we'll just send the latter
<slangasek> ... because the latest openoffice.org upload has changed the dependencies of openoffice.org-common, nice
<pitti> slangasek: ccheney plans a final upload on Thursday or Friday FYI
<slangasek> pitti: the question is, why are random parts of the Ubuntu delta dropped in this merge?
<cjwatson> pitti: r310
<pitti> cjwatson: ah, thank you
<kirkland> could a build admin please bump https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1290730 to build ASAP ?
<kirkland> cjwatson: ^
<pitti> doing
<pitti> kirkland: there
<kirkland> pitti: cheers, thanks
<mathiaz> cr3: so are you planning a new merge proposal?
<kirkland> pitti: re http://bugs.freedesktop.org/show_bug.cgi?id=23196
<ubottu> Freedesktop bug 23196 in DeviceKit-power "Do not offer hibernate with encrypted swap" [Normal,Assigned]
<kirkland> pitti: i've had no time whatsover for ecryptfs
<cr3> mathiaz: I think that would be the right thing to do, although I suspect the problems you are reporting might already exist in 0.8.3
<kirkland> pitti: eucalyptus has totally swallowed my life
<pitti> kirkland: understandably :) but it's not a regression really
<mathiaz> cr3: well - it makes testing complicated
<cr3> mathiaz: however, I'm quite pleased to fix those problems right away and submit another merge proposal so that you only have to do one
<mathiaz> cr3: as I can't validate a full test
<cr3> mathiaz: good point
<mathiaz> cr3: I think it would be great to fix this bugs
<mathiaz> cr3: otherwise checkbox-cli doesn't work
<mathiaz> cr3: hm - well - it works
<mathiaz> cr3: you could always submit the report afterwards
<mathiaz> cr3: since it's saved on the system
<mdke> perhaps someone could give me a hand. I tried to set a cdbs setting in debian/rules but it doesn't seem to have worked. debian/rules is at http://paste.ubuntu.com/292579/ (line 8) and the build log is at http://paste.ubuntu.com/292580/ - any ideas welcome!!
<pitti> mdke: ah, sorry, forgot that; debhelper.mk checks an environment variable, not a make variable
<LaserJock> is postinst run on a package ugprade?
<pitti> mdke: so, you do need to do "export CDBS_NO_GNOME_HELP_SYMLINKING=1" after all
<pitti> LaserJock: yes, with "configure <previously configured version>"
<mdke> pitti: I can just do a straight swap in line 8 for that?
<pitti> mdke: just prepend "export "
<mdke> pitti: awesome, thanks. Ok - will try the build again
<beuno> pitti, hi. Would you now who can look at bug 431023?
<ubottu> Launchpad bug 431023 in gnome-power-manager "gnome-power-manager crashed with SIGSEGV in g_cclosure_marshal_VOID__VOID()" [Medium,New] https://launchpad.net/bugs/431023
<beuno> it's been happening more frequently lately, and it seems to get a lot of dupes
<simon-o> james_w: Hi, I had a merge proposal for a bug, but it was sponsored the "traditional way" (with a debdiff) what do I do now with the MP? Delete it or keep it open?
<james_w> hey simon-o
<simon-o> hi
<james_w> simon-o: you can delete it
<simon-o> james_w: ok, but how gets the branch updated?
<james_w> there is a bot running that sees the upload and updates the branch
<james_w> your branch won't be merged, but your changes will get in to the branch, with you recorded as the author
<james_w> what package was it?
<seb128> chrisccoulson, ^ in case you fancy looking to a gpm crasher rather
<simon-o> james_w: basket
<simon-o> james_w: that was the information I was looking for. I sometimes see packages where the branches are outdated, so I guess the bot failed there
<lifeless> james_w: hi
<chrisccoulson> heh, lots of crashers to look at.
<pitti> beuno: can you reproduce it?
<chrisccoulson> so, the g-p-m crasher is triggered on a signal from dk-power
<chrisccoulson> gpm_manager_client_changed_cb
<pitti> beuno: I looked at the code, and it seems that there's one possible code path which could trigger this
<pitti> chrisccoulson: looking at 431023 ?
<chrisccoulson> pitti - i just took a very quick glance at the stacktrace
<beuno> pitti, not on demand, no. It happens once or twice a day, usually when I unplug the powewr adaptor or resume
<james_w> simon-o: yeah, it's not as robust as I would like yet
<james_w> hi lifeless
<pitti> chrisccoulson: right, I downloaded that older version and checked, but line 101 isn't correct
<pitti> chrisccoulson: my best guess is that disks->priv->cookie == NULL, and it segfaults in the last egg_debug
<simon-o> james_w: thanks. I'll have a look next time I see an outdated branch, maybe there's some way to fix it.
<chrisccoulson> yeah, i've not had a look in any detail yet
<pitti> chrisccoulson: it checks for NULL in the first if, but not in the last egg_debug
<seb128> pitti, <pitti> chrisccoulson: right, I downloaded that older version and checked, but line 101 isn't correct
<james_w> simon-o: when you see one if you can drop me a message that would be great
<simon-o> james_w: sure, I'll do. thanks
<seb128> pitti, how come that we don't source stacktrace? did that break again in karmic cycle?
<james_w> simon-o: the failure reasons aren't publically accessible currently, but I can look for you no trouble
<pitti> seb128: no deb-src lines apparently; I think we disabled them back then when xulrunner did weird stuff on "patch" and hung them
<seb128> pitti, oh, that xulrunner thing again, right
<seb128> pitti, thanks
<pitti> chrisccoulson: humm, no, "ret = 0", so the last egg_debug shouldn't trigger
 * chrisccoulson should probably download the latest source:)
<simon-o> james_w: lftp is the first outdated branch I remember
<simon-o> it's some months old
<pitti> chrisccoulson: so I think it fails in gpm_disks_register(), and the compiler optimized it away and inlined it
<pitti> chrisccoulson: oh, can it be that ret == FALSE, and error is NULL?
<pitti> chrisccoulson: i. e. that the DriveSetAllSpindownTimeouts() call didn't set error?
<chrisccoulson> hmmm, that shouldn't happen though
<chrisccoulson> (at least i don't think it should)
<pitti> beuno: got a minute to try something? are you on a laptop right now, and can go on battery?
<pitti> mine is currently docked, and I can't shutdown right now
<beuno> pitti, yeap
<beuno> I suspect that the bug is triggered when the battery is full and I unplug, but I'll need about 40min to verufy it
<pitti> beuno: I have another suspicion
<pitti> beuno: please do "sudo killall devkit-disks-daemon", then unplug AC and let it run on battery
<beuno> pitti, devkit-disks-daemon: no process found
<pitti> beuno: ps aux | grep devkit-disks doesn't give anything?
<beuno> the only thing with devkit is: /usr/lib/devicekit-power/devkit-power-daemon
<beuno> nope
<pitti> beuno: ok, perfect; if you pull the plug, does it crash?
<beuno> pitti, not at the moment, no
<beuno> I did bring it back up again manually
<pitti> beuno: killall gnome-power-manager
<chrisccoulson> you have some idea whats causing it then pitti?
<pitti> gnome-power-manager --verbose 2>&1 | tee /tmp/gpm.log
<pitti> chrisccoulson: my best theory is still error == NULL
<chrisccoulson> yeah, that seems to be the case, but i'm not sure why
<pitti> beuno: if you pull the plug with this running in debug mode, what are the lines that you see right after unplugging? do you see something like "on_battery:" and then "registered 0xDEADBEEF (60)"?
<pitti> chrisccoulson: dk-disks always returns true, it might be the d-bus call itself that fails?
<beuno> pitti, this is the full output: http://paste.ubuntu.com/292648/
<beuno> I can't find that specific line
<pitti> beuno: I don't even see a "discharging there; did you pull AC actually?
<chrisccoulson> pitti - does the value returned from devkit_disks_daemon_drive_set_all_spindown_timeouts in dk-disks correspond to the value returned from dbus_g_proxy_call in g-p-m?
<beuno> pitti, I did
<chrisccoulson> the documentation suggests that dbus_g_proxy_call only returns false if an error is set
<pitti> chrisccoulson: can't say for sure
<pitti> chrisccoulson: oh, ok
<chrisccoulson> i could be wrong though
<beuno> pitti, http://paste.ubuntu.com/292649/
<beuno> that's the output when pulling it and plugging in again
<pitti> chrisccoulson: ooh, hang on!
<pitti> chrisccoulson: gpm-disks.c 101 is indeed
<pitti>                 egg_warning ("failed to set spindown timeout: %s", error->message);
<pitti> chrisccoulson: I was misled first and thought that 101 was wrong, because it's in gpm_disks_register() and not in gpm_disks_set_spindown_timeout() as the stack trace claims
<pitti> but I guess that's just because gpm_disks_register() is just called in set_spindown_timeout, and once, and is static, so it was optimized/inlined
<pitti> chrisccoulson: and since %s with NULL works fine, we can conclude that error is NULL
<chrisccoulson> yeah, that seems to be the case
<pitti> beuno: nevermind then
<chrisccoulson> it's confusing when the compiler optimises things out and messes up the trace
<beuno> pitti, ok. Let me know if there's anything else I can do to help debug it
<pitti> beuno: I'll upload a fix, would be nice if you can test it and verify that it's gone?
<beuno> pitti, absolutely
<beuno> I'll install, reboot, and watch out for it
<seb128> chrisccoulson, I think alex (nautilus upstream) had some blog post about how to read optimized stacktrace some time ago and some tools to make that easier
<chrisccoulson> seb128 - would be interesting to look at. i just tend to look at the line numbers to figure out where it crashes
<pitti> I should have just trusted the line number
<seb128> same here
<chrisccoulson> so the next thing to figure out is why the error is NULL
<pitti> chrisccoulson: http://library.gnome.org/devel/dbus-glib/unstable/dbus-glib-DBusGProxy.html#dbus-g-proxy-call
<pitti> chrisccoulson: so what you said, it shouldn't be FALSE and error == NULL
<chrisccoulson> yeah, thats how i read it. which is confusing ;)
<chrisccoulson> so it could be something wierd in dk-disks then
<seb128> chrisccoulson, http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/ is the blog post I though about I think
<mathiaz> cr3: still not able to run checkbox-cli: http://paste.ubuntu.com/292655/
<mathiaz> cr3: this time I ran checkbox-cli as a normal user
<mathiaz> cr3: However I do understand now how to (un)select tests
<cr3> mathiaz: can you send me the logfile: ~/.cache/checkbox/checkbox.log
<elops> do you suppose 4gb is enough for a basic media install of ubuntu?
<mathiaz> cr3: http://people.canonical.com/~mathiaz/checkbox.log
<elops> or am I going to get screwed trying to run updates?
<kirkland> Keybuk: question about "start on ..."
<kirkland> Keybuk: what's the expected behavior if we're starting on $something being started/stoped and $something doesn't exist?
<kirkland> Keybuk: is it possible to use some best effort logic?
<kirkland> Keybuk: ie, start on $something started if $something even exists
<slangasek> kirkland: the condition is never satisfied if $something isn't known
<slangasek> (I've had this problem as well, and haven't found a solution w/ the current upstart)
<elops> anyone?
<cr3> mathiaz: you're running from the branch rather than an installed package, right?
<elops> thank you kmos
<mathiaz> cr3: nope - it's a package install
<kirkland> slangasek: ugh; that's highly unfortunate
<slangasek> kirkland: in some cases, you can flip it around and have the optional service do 'start on starting' instead
<cr3> mathiaz: might you be able to explain why you're getting this: DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<cr3> mathiaz: do you have dbus running?
<mathiaz> cr3: nope
<kirkland> slangasek: right, but the optional service may not even be installed
<mathiaz> cr3: it's a base system image
<mathiaz> cr3: not a desktop
<cr3> mathiaz: ok, that will only prevent tests which require root from running, I fixed that recently :)
<cr3> mathiaz: now, you're experiencing another problem because of an unrelated bug
<slangasek> kirkland: yes, in which case said optional service's upstart job doesn't exist and it's not a problem
<mathiaz> cr3: ie: ubuntu-standard is installed
<kirkland> slangasek: hmm, then i'm misunderstanding your statement
<mathiaz> cr3: well - this is the latest code you've asked for merging
<kirkland> slangasek: in eucalyptus upstart ....
<kirkland> slangasek: we have eucalyptus-sc-registration
<kirkland> slangasek: which has:
<elops> can I just install a clean install, and then copy another install over the top of it?
<kirkland> start on (started eucalyptus-sc and started eucalyptus-cloud and stopped eucalyptus-cc-registration)
<kirkland> slangasek: eucalyptus-cloud may, or may not exist at all on this system
<elops>  my kiosk install is only 2.6gb
<elops> but I don't have xbmc or anything on there
<elops> and that's on an 80gb drive
<cr3> mathiaz: could you send me the output of udevadm info --export-db
<kirkland> slangasek: in which case, will this condition ever be satisfied?
<slangasek> elops: this is not a help channel; I think you'll find #ubuntu better suited to such questions
<slangasek> kirkland: it won't be satisfied when eucalytpus-cloud is not installed, no
<slangasek> kirkland: but what you can do is this:
<slangasek> eucalyptus-sc-registration: start on (started eucalyptus-sc and stopped eucalyptus-cc-registration)
<slangasek> eucalyptus-cloud: start on starting eucalyptus-sc-registration
<mathiaz> cr3: http://people.canonical.com/~mathiaz/udevadm.info.txt
<cr3> mathiaz: thanks for your patience, this is helping a lot
<slangasek> kirkland: that ensures that, *if* eucalyptus-cloud is installed, it's always started before eucalyptus-sc-registration is started
<kirkland> slangasek: really?  i would have thought "starting" implies parallel execution
<mathiaz> cr3: sure - you owe me 278 poutines and 4242 beers
<slangasek> kirkland: nope, it's "do this first whenever this other thing is about to be started"
<kirkland> slangasek: interesting
<kirkland> slangasek: i'll give this a go
<slangasek> kirkland: feel free to use the nfs-common package as an example, I think I've used all possible combinations there ;)
<cr3> mathiaz: damnation, virtio-pci is exposing itself as an incomplete pci class, no wonder I hadn't encountered this before
<mathiaz> cr3: right - this is a virtual guest running virtio network devices
<mathiaz> cr3: and virtio block devices
<kirkland> slangasek: http://paste.ubuntu.com/292665/
<kirkland> slangasek: see if that looks reasonable to you
<kirkland> slangasek: i'm concerned about the huge or-statement in eucalyptus-cloud.upstart
<kirkland> slangasek: that it might start over and over and over again
<pitti> beuno: uploaded
<slangasek> kirkland: what do the dependencies of the 'eucalyptus' job look like?
<beuno> pitti, updating apt, will install and reboot. If it comes up again, I'll re-open the bug. THANK YOU
<kirkland> slangasek: http://paste.ubuntu.com/292668/
<kirkland> start on runlevel [23]
<pitti> beuno: it still needs 2 hours to get built and published
<slangasek> kirkland: the way to ensure eucalyptus-cloud doesn't start over and over again is to make it a job that winds up in state 'started' when it's done; eyeballing the diff I think that would be the case here, but it's easy enough for you to check this
<slangasek> (if you have a running system, I mean)
<kirkland> slangasek: okay
<beuno> pitti, I just figured that out. On the bright side, I'm pulling in updates  :)
<pitti> beuno: always a good thing to collect the latest breakage
<kirkland> slangasek: i'll build a package and test
<slangasek> kirkland: ok, given that eucalyptus job I think it looks fine
<kirkland> slangasek: just passing by you to make sure that it's not doa
<beuno> pitti, I appreciate the quick turnaround
<kirkland> slangasek: related question ...  i need some logic in these init scripts that take different actions based on what's installed
<kirkland> CC_PKG_INSTALLED=$(dpkg -l eucalyptus-cc | grep -c "^ii")
<kirkland> slangasek: is that sufficient?
<kirkland> slangasek: is there a better way?
<slangasek> sufficient, but expensive - surely there's some sentinel file you can check for the presence of?
<slangasek> (something the package ships which is not a conffile, that you can check for the existence of)
<kirkland> slangasek: okay, i'll find something like that
<cr3> mathiaz: pushed fix to support virtio-pci devices, updated merge proposal and bug correspondingly
<lifeless> james_w: still around?
<lifeless> james_w: I want to do on-demand builds of some upstreams; you were saying that the bzr nightly stuff wasn't all that reusable yet?
<Keybuk> kirkland: here's another way of looking at it
<Keybuk> if the optional service does not exist, what would start it?
<kirkland> Keybuk: nothing; it doesn't exist
<Keybuk> no, I mean
<Keybuk> let's say that you have a process
<Keybuk> we'll call it gandalf, because the Upstart test suite is full of references to The Hobbit and Lord of the Rings
<Keybuk> now, the quest depends on gandalf
<Keybuk> so
<Keybuk> /etc/init/quest.conf:
<Keybuk>   start on gandalf
<kirkland> slangasek: duh, look for [ -f /etc/init/eucalyptus-cloud.conf ]  :-)
<Keybuk> but the quest also depends on thorin
<Keybuk> so
<kirkland> Keybuk: okay
<Keybuk>   start on gandalf and thorin
<slangasek> kirkland: no, that's a conffile
<Keybuk> following me so far?
<kirkland> Keybuk: with you, yup
<Keybuk> ok
<Keybuk> now the quest optinally depends on bilbo
<Keybuk> but we can go without him
<slangasek> kirkland: my stipulation that it not be a conffile was not idle :)
<Keybuk> in this model, how do we know we have to wait for bilbo
<Keybuk> if we say
<Keybuk>   start on gandalf and thorin and bilbo
<Keybuk> then we'll wait for bilbo
<Keybuk> if we say
<Keybuk>   start on gandalf and thorin
<Keybuk> then we won't wait at all, and won't know what bilbo is wearing
<mathiaz> cr3: great thanks. I'll find another bug now
<Keybuk> if we say
<Keybuk>   start on (gandalf and thorin)
<Keybuk>     or (gandalf and thorin and bilbo)
<Keybuk> then we'll pick bilbo up as long as he arrives before gandalf or thorin
<Keybuk> but if he's late we won't
<Keybuk> but none of these is what you're after
<kirkland> Keybuk: right
<Keybuk> you want to know, in advance to either gandalf or thorin showing up, whether bilbo is coming
<Keybuk> so you need some kind of signal from bilbo the night before
<ia> hello. I've found out about this bug - https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/439138?comments=all (discussion really very intresting); and (just for curiosity) i would like to know - do ubuntu core developers have some plans about fixing this bug?
<ubottu> Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [Undecided,Confirmed]
<Keybuk>   start on ((gandalf and thorin)
<Keybuk>     or (gandalf and thorin and bilbo-is-coming and bilbo))
<kirkland> Keybuk: yeah, that sounds a bit closer
<Keybuk> but that only works if bilbo tells you he's coming before gandalf and thorin arrive
<Keybuk> but that's probably ok
<kirkland> Keybuk: basically, if we are to expect bilbo, wait for him; but if he's not around at all, don't wait for him
<Keybuk> so you can emulate this pretty easily with events
<Keybuk> initctl emit have-eucalyptus-cloud
<kirkland> slangasek: http://pastebin.com/f7b88450c
<kirkland> slangasek: the copyright file?
<kirkland> slangasek: i was hoping for something with a bit more meat as to the functionality of the package
<slangasek> kirkland: if [ -d /usr/share/doc/eucalyptus-cloud ] ? :)
<slangasek> kirkland: but your earlier example was the eucalyptus-cc package, not eucalyptus-cloud?
<kirkland> slangasek: my stipulation that it be core to the functionality was not idle ;-)
<kirkland> slangasek: :-P
<Keybuk> kirkland: what's missing from upstart is a state that says a job exists, but isn't running
<kirkland> slangasek: i suppose that'll do
<kirkland> slangasek: right, i'm attacking this from a slightly different angle
<kirkland> Keybuk: okay, cool; i think i might be able to solve it with "starting ..." from slangasek
<kirkland> Keybuk: i'll poke you if that doesn't do what we need
<pitti> chrisccoulson: moving here, since meeting is in place
<chrisccoulson> ah, i didn't realise ;)
<pitti> chrisccoulson: I can't commit, but Richard is usually fast with that; if not, we can also ask seb128 to apply them
<chrisccoulson> i should pay more attention!
<chrisccoulson> pitti - i can commit now, but i generally prefer to wait for the maintainer to tell me it's ok
<pitti> chrisccoulson: oh, nice to know
<chrisccoulson> i don't know if i'm just paranoid though ;)
<pitti> chrisccoulson: Richard says that we should just go ahead and commit obvious fixes, and just wait for him if it changes UI/behaviour
<chrisccoulson> ah, ok
<pitti> chrisccoulson: so I'd say, go ahead; he can still change/revert in the very unlikely case that he disagrees
<pitti> chrisccoulson: I still think we should apply all three patches, though
<pitti> (well, the first one is really obvious)
<NCommander> Keybuk, lool, so mountall 0.2.2 doesn't fix the regression on armel+dove; the image still hangs :-/
<Keybuk> NCommander: "the regression"
<Keybuk> pretend nobody's told me about that ;)
<Keybuk> kirkland: I do plan to fix this in Upstart ;)
<Keybuk> kirkland: part of the whole point of the exercise this cycle was to find out what we still needed from it
<kirkland> Keybuk: righto
<NCommander> Keybuk, hrm. armel+dove is failing to boot with both mountall 0.2.1 and 0.2.2. the board hangs hard in initramfs
<cjwatson> kirkland: in response to the exact same problem, the eucalyptus-cloud init script checked for /usr/share/eucalyptus/eucalyptus-cloud-@EUCA_VERSION@.jar
<cjwatson> kirkland: though of course that requires generating the upstart job
<NCommander> Keybuk, nothing useful on the console (I'll grab the output of that in a minute)
<Keybuk> NCommander: if it hangs hard in the initramfs, I'll be elsewhere ;)
<chrisccoulson> pitti - i just had a quick look at the patch. there's no need to change the DriveUnsetAllSpindownTimeouts call though, as the parameter is going in the other direction there (ie, it's not a return value)
<chrisccoulson> so that call is already correct
<pitti> chrisccoulson: ah, I see
<pitti> sorry
<chrisccoulson> heh, no worries:)
<NCommander> Keybuk, :-P
<pitti> chrisccoulson: can you please just commit the right version, and then under your name?
<chrisccoulson> pitti - yeah, can do
<slangasek> Keybuk: do you have any thoughts on https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/439138/comments/98 ?
<ubottu> Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [Undecided,Confirmed]
<slangasek> Keybuk: I think that comment got lost among the thread of people repeating themselves :P
<NCommander> Keybuk, I'll file a bug and debug some more
<slangasek> Keybuk: specifically: cryptdisks-enable stop on starting-dm - madness or inspired?
<Keybuk> slangasek: the question I guess is how cryptsetup should prompt
<Keybuk> if usplash is running it can use usplash
<Keybuk> if usplash is not running, maybe it should start usplash and use it
<Keybuk> if X is running, should it not use X?
<Keybuk> etc.
<pitti> chrisccoulson: new g-p-m uploaded
<slangasek> so if usplash is not running and X is not running and it needs to prompt, it starts usplash, tries to prompt, and hopes X doesn't start in the meantime and kill X?
<slangasek> kill X -> kill usplash
<Keybuk> slangasek: well, that's a big thorny mess
<chrisccoulson> pitti - thanks
<Keybuk> thinking about the big thorny mess while stuck in the middle of it is not going to solve it ;)
<slangasek> as for "should it not use X" - no, I don't think it should
<slangasek> since the X session belongs to an arbitrary user, and the decryption prompt belongs to the admin
<Keybuk> ok
<Keybuk> so let's look at the pieces here
<Keybuk> we have a process that needs to interact with the user on the system console
<mathiaz> cr3: yo - still failing - http://paste.ubuntu.com/292686/
<Keybuk> (cryptsetup isn't the only one, the same is arguably true for fsck, and a future system recovery app, etc.)
<Keybuk> but thinking about "the system console" like that is dangerous
<Keybuk> because anything can be running there (especially X)
<Keybuk> so we really need to think "how do we interact on the console in an output-independant way"
<Keybuk> we can do it with text
<Keybuk> we can do it via a graphical program like usplash
<Keybuk> and we can do it via X
<Keybuk> and, depending where we are, any of the above may be running
<Keybuk> if we need to prompt while X is running, what do we do?
<mathiaz> cr3: http://people.canonical.com/~mathiaz/checkbox.log
<Keybuk> the start usplash approach is actually kinda ingenious I thought ;)
<Keybuk> it switches to VT8 to prompt
<Keybuk> and when done switches back to whatever VT you were on before
<Keybuk> so it can still prompt while X is running
<Keybuk> bit of a experience jump, but kinda cute
<Keybuk> this stuff is actually easier with Plymouth - because plymouth can run on a VT that's not the active one
<slangasek> so there are no problems with usplash and X running at the same time?
<Keybuk> (unlike the svgalib mess that is usplash)
<Keybuk> there are no problems that I'm aware of
<Keybuk> usplash cannot run if it's not on the active vt
<Keybuk> but there's code in usplash to deal with that
<Keybuk> this is why usplash switches to a new vt
<slangasek> cjwatson: ^^ can you confirm?  I thought this was a consideration for stop on starting-dm in usplash?
<chrisccoulson> pitti - i've committed the change now
<Keybuk> slangasek: that's there because X can't start on a VT which is ruined by svgalib
<Keybuk> once X has started, it's fine
<Keybuk> (X can start on a VT which has plymouth running on it
<slangasek> so we have to somehow ensure that cryptsetup doesn't start usplash during a critical X startup period
<Keybuk>  sorry I'm merging an e-mail thread with this, but I have a feeling we're going to have to use plymouth for lynx)
<Keybuk> slangasek: right, that's the only issue
<Keybuk> (that I know of)
<slangasek> well, and how do we solve that?
<Keybuk> dunno :P
<Keybuk> haven't got that far yet
<cr3> mathiaz: ok, I thought I had worked around running checkbox when dbus is not running, I will look into this problem tomorrow and either fix or add a dependency
<Keybuk> slangasek: having the same issue with mountall
<Keybuk> a simple option might be to use usplash if it's running
<Keybuk> if it's not running, assume X has been started, and don't bother?
<slangasek> and doing that would mean we could drop the 'console owner' from the job?
<Keybuk> yes
<Keybuk> a quick fix could be just to make it "console output" for now ;)
<Keybuk> that'd break ^C and things though
#ubuntu-devel 2009-10-14
<slangasek> and defeat the purpose of 'console' at all in the case of cryptsetup
<slangasek> it only wants it for prompting, not output
<slangasek> (rather: if there's no prompting, there's no reason to output either)
<Keybuk> does it defeat it?
<Keybuk> not sure
<slangasek> cryptsetup wants the console for prompting
<slangasek> does that work with 'console output'?
<Keybuk> yeah, but does it need to have it as the controlling terminal?
<Keybuk> sure, the difference between the two is whether you get signals from the console driver
<slangasek> ok, then perhaps not
<Keybuk> if cryptsetup doesn't need SIGHUP, SIGINT, SIGTSTP, etc. it should be ok
<Keybuk> but I still don't like the idea of cryptsetup prompting for a passphrase while X is running
<Keybuk> sits badly with me
 * jdong watches some funky policykit-gnome-auth-handler-thingie arise out of this discussion...
<Keybuk> god know
<Keybuk> god no even
<jdong> haha joking :)
<slangasek> Keybuk: no, I agree, I think we either need cryptsetup to block X until it's done, or die when the dm starts
<Keybuk> right
<Keybuk> but then I start to wonder whether the same shouldn't really be true of mountall as well
<Keybuk> should we really be checking filesystems behind X ?
<slangasek> perhaps not... but mountall is trickier because it may be running waiting for remote filesystems and there's no way presently to distinguish that from the "going to fsck" case?
<slangasek> I guess it could emit a "no more fsck" signal
<slangasek> anyway, is mountall getting fixed to talk to usplash for karmic so people don't get into a reboot loop wondering why their systems have hung at boot?
<Keybuk> doesn't cryptsetup use X already?
<Keybuk> err
<Keybuk> I mean use usplash already?
<slangasek> should do
<slangasek> but you're the one who added the 'console owner' upstart job, so I don't know :)
<Keybuk> yeah I think that was wrong of me ;)
<slangasek> heh :)
<Keybuk> writing an operating system is *hard&
<crypt-0> anyone know how to prevent malicious hardware initialization while im away?
<crypt-0> is stopping hald while im good enough?
<Keybuk> crypt-0: turn off the machine?
<chrisccoulson> i would go one further and unplug it from the wall
<chrisccoulson> just in case it switches itself back on again
<Keybuk> chrisccoulson: I was being serious ;) rather than just joking
<slangasek> right, you only need to disable wake-on-lan for the latter
<chrisccoulson> Keybuk - i wasn't sure if you were being serious or not ;)
<cjwatson> Keybuk: I wonder if it would make sense to use usplash's bogl backend on KMS
<Keybuk> cjwatson: isn't it only 16-colour?
<cjwatson> 256
<cjwatson> I don't think that's intrinsic anyway, depends on the framebuffer type
<Keybuk> hmm
<Keybuk> how easy would it be to test? :p
<slangasek> is the current problem KMS-specific?
<crypt-0> Keybuk, besides turning off the machine
<slangasek> or would we need another solution for !KMS cryptsetup users?
<Keybuk> current problem?
<Keybuk> crypt-0: if you want to avoid attack, powering off the machine is the only solution
<slangasek> Keybuk: the bug number I cited 800 lines ago?
<cjwatson> Keybuk: I think you just need to nobble uplash_setup_func
<Keybuk> I don't think bogl vs. svgalib is relevant here
<cjwatson> usplash_setup_funcs
<crypt-0> Keybuk, why wont stopping hald work?
<cjwatson> apparently my  key is a bit wonky
<crypt-0> Keybuk, can i PM you?
<Keybuk> crypt-0: no.
<Keybuk> crypt-0: seriously though, there's no way to disable things against malicious use short of powering down the box
<Keybuk> crypt-0: assumedly you're leaving it up so you can access
<Keybuk> crypt-0: well, so can naughty people
<Keybuk> (and for the exact question you were asking, hardware configuration and activation is largely performed by the kernel - which you kinda need running <g>)
<Keybuk> so my answer was correct
<LaserJock> am I supposed to have green check marks on all my files?
<TheMuso> LaserJock: Known, its an UbuntuOne bug.
<LaserJock> oh
<LaserJock> can  I just uninstall UbuntuOne and it'll go away?
<TheMuso> I guess so, I don't know for sure./
<crypt-0> is there a way to "lock" the kernel?
<crypt-0> as in make no hardware initialization possible without x password
<sladen> urm.  Don't load the kernel?
<Keybuk> bryce, tjaalton: either of you around?
<bryce> I am
<Keybuk> bryce: how do I make nouveau work?
<sladen> crypt-0: you will *require* the kernel have have initialised various bits of hardware in order for you to interact with the machine
<bryce> Keybuk, first you must have the right hardware
<Keybuk> bryce: I have an nvidia ;)
<Keybuk> [    7.994703] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086700a2)
<Keybuk> [    7.994981] [drm] Initialized nouveau 0.0.15 v2.6.31-rc6-539-ged53f9fcabd42f004 for 0000:01:00.0 on minor 0
<Keybuk> I have that in dmesg
<pwnguin> lspci is smarter
<bryce> Keybuk, seriously, in my testing I've found so many card-specific bugs that I ended up giving up trying to make it the default driver for us
<Keybuk> bryce: I want to try something out with usplash which needs mode setting
<pwnguin> Keybuk: right now I use xorg.conf
<pwnguin> Driver "nouveau"
<bryce> pwnguin, you using any special kernel?  xorg-edgers?
<Keybuk> X isn't smart enough to use nouveau automatically?
<bryce> Keybuk, re: my comment about defaults on karmic
<lifeless> its smart enough not to :P
<Keybuk> bryce: even if you've loaded the nouveau module?
<pwnguin> Keybuk: smart enough is the wrong phrase. crazy enough is the rgiht one
<bryce> there was a patch floating around to make it try nouveau first if installed, then -nv if failed, but don't know the status on that
<pwnguin> bryce: honestly, i switched to nvidia a few weeks ago to try out 3d accelleration of unr
<bryce> Keybuk, in any case, that's a pretty minor issue, like pwnguin says it's sort of a box of chocolates at the moment
<crypt-0> sladen, right but if hald inst running "evil" hardware cant be intilizied right?
<pwnguin> bryce: but until then it'd been running nouveau on karmic
<Keybuk> bryce: ok
<Keybuk> bryce: if I have nouveau modeset=1 will X burn in flames?
<pwnguin> no clue
<pwnguin> err
<bryce> pwnguin, was this stock karmic or were you using one of our special ppas?
<Keybuk> crypt-0: evil hardware will still be initialised, the kernel does the initialisation
<pwnguin> bryce: i believe it's stock. might have what's his name's ppa
<pwnguin> RAOF?
<bryce> ah yes
<bryce> Keybuk, I'd certainly wear flame retardant underware
<pwnguin> anyways, it's at home and im not
<bryce> I think it's nouveau.modeset=1 btw
<Keybuk> right
<pwnguin> its probably time for me to turn off the nouveau hilight on irssi
<pwnguin> im not smart enough to handle it
<bryce> apw also had a special kernel built for us with updated nouveau bits, although I think by now that's all in the stock kernel
<crypt-0> Keybuk, but wont it be "ignored" rendering it useless?
<crypt-0> Keybuk, how about killing dbus?
<Keybuk> crypt-0: no, it will not be ignored
<Keybuk> killing dbus won't help you either
<Keybuk> frankly, you're being rude now
<Keybuk> you asked us a question, we gave you answer
<Keybuk> we're not lying to you
<bryce> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<bryce> that's it... but looks like it's probably way out of date now
<crypt-0> Keybuk, so there is no software solution then. Will have ti implement a hardware one
<bryce> in any case, was buggy as hell when I tested it on a few cards, but the intro directions might be useful
<Keybuk> crypt-0: there's already a hardware solution - it's the plug on the wall
<crypt-0> Keybuk, i know, but i like to run my pc 24.7
<Keybuk> crypt-0: your electricity supplier loves you
 * walters likes the "kill dbus" solution to arbitrary problems
<crypt-0> Keybuk, rmod <drivers_for_evil_hardware>
<Keybuk> walters: "kill init" works well ;)
<crypt-0> Keybuk, correct me if im wrong, but blacklisting and unloading every kernel module for anything hot-swappable excapt for PS/2 should do it , but its a rater crude way of doing it
<lifeless> crypt-0: if you don't trust the hardware don't use the machine.
<Keybuk> crypt-0: PCI is hot swappable, as is USB
<lifeless> crypt-0: its extremely simple.
<Keybuk> in fact, Linux supports hot-swappable CPUs
<Keybuk> so good luck with *that*
<crypt-0> no need for USB. my mobo doenst support PCI hot swap
<Keybuk> crypt-0: you'd need a custom kernel though, ours has the USB host drivers built-in
<crypt-0> Keybuk, for example with a "live image hack tool" wouldnt you need to root the system?
<crypt-0> (no DMA for anything hot-swappable is already applied)
<Keybuk> crypt-0: always assume that's possible
<crypt-0> Keybuk, but if your sys gets rooted, arent you owned anyway?
<slangasek> LaserJock: this edubuntu karmic livefs build failure looks kinda edubuntu-specific, like it doesn't want to install the default kernel or something?
<LaserJock> slangasek: for which build?
<slangasek> LaserJock: edubuntu/karmic/amd64, email just came in
<sladen> crypt-0: r00ted == 0wned.
<slangasek> (not on the website yet)
<LaserJock> slangasek: k
<LaserJock> slangasek: I wouldn't think that'd be edubuntu-specific. Could it be that the build caught the archive at a bad time?
<LaserJock> slangasek: we don't do anything with the kernel I don't think
<slangasek> LaserJock: possible; let me double-check, then
<crypt-0> sladen, i know, there is no point to protecting against any attack if your rooted...
<crypt-0> unless the evil hardware is what roots you
<sladen> crypt-0: unplug the evil hardware.  It's not forcing you to use it
<sladen> crypt-0: if you're running Free Software, you've got the source code and are free to analysis.  If you're choosing to run on hardware you don't have source code for, then that's a risk you are *choosing* to take
<slangasek> LaserJock: can't reproduce the problem locally, so I don't know
<slangasek> LaserJock: can try to respin in a bit
<LaserJock> slangasek: ok
<crypt-0> sladen, evil hardware such as in a hackers laptop plugged into my USB port
<Keybuk> I go test usplash now
<crypt-0> ive seen windows machines rooted from something like a hackers laptop,
<sladen> crypt-0: I'd care if somebody had a firewire cable... unsolicated incoming DMA
<sladen> crypt-0: if you can't unplug the USB hardware, get some superglue and bung it up
<cjwatson> LaserJock: I've committed a cdimage fix which might sort out Edubuntu on the next build, so please shout if it doesn't (unfortunately I'm probably not going to have enough attention to check myself)
<LaserJock> cjwatson: no problem, I'll let you know
<virtuald> Turn off all ports and DVD etc in BIOS setup then though the computer wouldn't be very useful
<virtuald> That includes network
<cjwatson> LaserJock: thanks
<crypt-0> sladen, i have no firewire, its de-soldered
<sladen> crypt-0: cricky.  +1.  That is paranoid
<Keybuk> cjwatson: well, this is truly fascinating
<crypt-0> sladen, what use is disk crypto if any script kiddie can crack your system wide open with thier laptop?
<ion> If you give an attacker physical access, youâre screwed.'
<jdong> I still haven't seen any reasonably plausible demonstrations of how SHA1 in this case comprises a major vulnerability
<Keybuk> bryce: well, that's nice
<Keybuk> usplash uses bogl with noueveau too ;p
<Amaranth> Keybuk: are you subscribed to 'boot' bugs just because people like to file boot issues there or do you actually use it? :)
<Keybuk> Amaranth: because people like to file boot issues there
<Keybuk> I have never knowingly known anything about 'R'
<Amaranth> hehe, figured
<Keybuk> including why 'R' maintainers think namespaces only happen to other people
<ion> Well, R isnât even a word. âAâ would be a better name.
<cjwatson> I'm pretty sure I objected to R's namespacing on debian-devel in like 2002 or something
<lifeless> the way its packaged, or some internal of its implementation?
<Keybuk> slangasek: around?
<Keybuk> can you remember why we decided to unconditionally load vesafb?
<nixternal> cjwatson: I take it dirk objected to your naming? :)
<geofft> is it just me or is packages.ubuntu.com down? (port 80 closed)
<nixternal> he sure loves his R
<nixternal> geofft: there are a few machines that are experiencing issues...I just ran across a bug report for p.u.c so it is known
<geofft> okay, thanks
<nixternal> keyserver is another one with issues
<cjwatson> lifeless: the binary packages have r-cran-* namespacing; the source packages typically do not, hence 'boot' (binary: 'r-cran-boot')
<slangasek> Keybuk: ... was I around when that decision was made?
<cjwatson> there was some excuse about "boot" being the upstream name
<Keybuk> slangasek: yup
<Keybuk> I have a feeling it got noted down somewhere with a ? and the ? got lost, so we force load it
<slangasek> Keybuk: well, I don't think I was party to the decision...
<Keybuk> I was talking at you :)
<slangasek> hmm :)
<Keybuk> you were being a teddy bear
<Keybuk> I wondered if you could remember *why* I did that
<d3xter> hey guys
<d3xter> is anyone here?
<LaserJock> cjwatson: yeah, I remember when I was doing MOTU Science we got a ton of mis-filed bugs :-)
<Keybuk> d3xter: no
<d3xter> alright ^^
<d3xter> well, one of my friends tryed to install nvidia 185 on 9.04, but the installation messed up, so he tried to get back to 180, but the links libGL and libGLcore still remained at the 185 versions of this libraries
<d3xter> is there any way, so that other users dont get stuck with this problem?
<Keybuk> usplash hates me
<Keybuk> I bet it's pitti's fault
<lifeless> cjwatson: ughhhhh
<Keybuk> that's interesting
<Keybuk> it is *kinda* pitti's fault ;)
<Keybuk> the problem isn't that the console is screwed
<Keybuk> the problem is that usplash isn't exiting
<Keybuk> but you can't tell that, because he's set the entire palette to a trendy black-on-black :p
<exarkun> I seem to find the ?no-redirect thing for filing Ubuntu bugs offensive somehow.
<exarkun> It doesn't help that it combines with the frequent timeout bug in a way which probably makes it even harder to report bugs against Ubuntu than whoever came up with the idea intended.
<exarkun> timeout, hit back, get bounced back to the wiki page asking for people to not report bugs
<exarkun> I almost gave up and didn't report this bug that I'm now going to report
<ScottK> exarkun: #ubuntu-bugs is probably the best channel for feedback on that decision.
<exarkun> I'm sure the average Ubuntu user wouldn't have gotten nearly this far
<exarkun> ScottK: This is about barrier to participation.  And as a demonstration, I'm afraid I'm going to have to decline to join #ubuntu-bugs and re-complain about it there.  If no one here cares enough to pass on the message, then I guess the feedback will be lost and the community will suffer.  Or maybe not even notice.  Beats me.  Anyway, this has already taken twice as long as I expected, I'm not going out of my way to find more work.
<Keybuk> exarkun: we've been shouting about the message ourselves
<ScottK> exarkun: It wasn't anyone here who made that decision.  You are declining then to discuss it with the people that can do something about it.  Not very effective.
<exarkun> ScottK: Yes, it's too bad.
<exarkun> My bug is filed.  Good night.
<LaserJock> hmm
<LaserJock> well I wish everything was that easy
<Keybuk> :-)
<ion> Hereby world peace has been achieved. Good night.
<StevenK> Ah ha! 2.6.31-14 did hit universe. Thanks for making that helpful to find out, LP.
<Keybuk> ok
<Keybuk> so usplash is getting SIGTERM ok
<Keybuk> and is exiting
<Keybuk> but is not unpainting the screen
<Keybuk> or changing the console
<Keybuk> or, in fact, anything
<hyperair> StevenK: it did?
<StevenK> hyperair: Yup
<hyperair> er where does it say?
<hyperair> i only see it in main
<StevenK> I can see the kernels themselves in universe.
<hyperair> huh?
<hyperair> link?
<StevenK> hyperair: I can't give you a link, I'm doing it from a shell on the archive master.
<hyperair> aah i see
<hyperair> but why are there kernels in universe?
<StevenK> They aren't supposed to be
<slangasek> Keybuk: do you have a way to reliably reproduce the X+cryptsetup conflict bug?  I've never seen it here and can't reproduce it at all, regardless of what sleeps I put where
 * hyperair doesn't understand
<Keybuk> slangasek: I can't even get cryptsetup to work for me normally
<lifeless> slangasek: whats the bug ?
<slangasek> Keybuk: getting cryptsetup to work is orthogonal to reproducing the bug
<slangasek> Keybuk: most users complaining about this aren't using crypted disks
<StevenK> slangasek, cjwatson: The 2.6.31-14 kernel was accepted to universe, I'm just in the middle of processing it into main.
<slangasek> well.  I /hope/ it's orthogonal... maybe you have to not be using cryptsetup to reproduce it :P
<slangasek> StevenK: ah, sigh; thanks
<lifeless> slangasek: is there a bug # ?
<slangasek> lifeless: bug #439138
<ubottu> Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Confirmed] https://launchpad.net/bugs/439138
<kirkland> slangasek: hey, i need to move a couple of upstart scripts from one binary package to another
<kirkland> slangasek: should i purge it in the old package in a preinst script (conditional on the version)?
<Amaranth> kirkland: that's what Conflicts/Replaces is for
<kirkland> Amaranth: good call
<TheMuso> /c/c
<Keybuk> ok bogl is fine
<Keybuk> it's the svga backend
<Keybuk> which explains why intel people don't see this
<lifeless> wow busy bug
<Keybuk> the best ones are
<Keybuk> hmm
<Keybuk> that's the third screwed initramfs in a row
<kirkland> what's the recipe for moving a file from one package to another, when both packages are going to be installed at the same time on the same system
<kirkland> conflicts/replaces i know, more detail please
<kirkland> (it's late)
<Keybuk> replaces:
<Keybuk> that's all you need
<kirkland> Keybuk: okay
<Keybuk> I think I just beat usplash
<Keybuk> that's like the biggest end-of-level boss ever
 * kirkland high fives Keybuk 
<Keybuk> in the last four hours, I have learned more about svgalib than any human should have to
<kirkland> Keybuk: is it 3:20am for you?
<Keybuk> 4:20am
<kirkland> Keybuk: prime hacking time
<Keybuk> exactly, and this is a *good* bug
<Keybuk> one of the ones you can really get your teeth into
<Keybuk> ooohohhhhhh yes!
<Keybuk> usplash just exited normally with a console flip ;)
<Keybuk> and now I just got a getty
<Keybuk> now the ultimate test, booting into X
<Keybuk> then seeing if C-A-F1 works again
<Keybuk> \o/
 * TheMuso follows with interest. :p
<lifeless> kirkland: replaces says 'when this package is installed take over files from that package'
<lifeless> kirkland: so its necessary; sometimes its not sufficient,and in that case 'breaks' is wanted - not conflicts. conflicts is a last resort
<kirkland> lifeless: thanks that makes more sense
<kirkland> lifeless: replaces is confusing, because only a couple of files are replaced, not the whole package
<lifeless> to determine if you need breaks:, consider 'if the old version of the other package is not upgraded will things still work'
<lifeless> if the answer is no, you need to either breaks other << VERSION or depend other >= VERSION
<lifeless> depending on why things wouldn't work, which is clearly situation specific
<lifeless> if you cannot _unpack_ the packages at all at the same time, then you need conflicts: rather than breaks:
<Keybuk> TheMuso: https://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/revision/323 if you're curious
<kirkland> lifeless: great, thanks, that's very helpful
<lifeless> anytime
<slangasek> Keybuk: why intel> ah, damn, so that's why I can't reproduce it at all here
<NCommander> Keybuk, please disregard earlier noise on a possible mountall regression; it was an unfortunate red hearing
<Keybuk> NCommander: yes, most mountall bugs that happen before it's even started are ;)
<Keybuk> slangasek: right, you had mode setting
<Keybuk> mode setting uses the bogl backend
<Keybuk> which is fine
<slangasek> right, just means that the time I spent trying to reproduce the problem was wasted
<slangasek> (AIUI)
<Keybuk> yeah we never saw corrupted text on intel
<Keybuk> if you added intel.modeset=0 to your command-line you may well have done <g>
<NCommander> Keybuk, *cough*. I'm not very familiar with mountall. So sorry for the noise ^ 2
<kirkland> Keybuk: what's the upstart debug variable i can set to get more verbose output in syslog?
<Keybuk> kirkland: initctl log-priority debug ?
<slangasek> well, I also couldn't reproduce the 100% CPU usae
<slangasek> usage
<Keybuk> slangasek: that's a different issue to this one
<slangasek> should that be reproducible on intel?
<slangasek> oh
<slangasek> what bug # are you working on?
<Keybuk> this was the "text consoles always corrupted and unusable, whether or not you start X" bug ;)
<slangasek> StevenK: did you get through moving the kernel back to main?  it looks like only amd64+i386 have been fixed, maybe?
<StevenK> slangasek: I took the binary names from the ACCEPTed .changes
<kirkland> Keybuk: cool; i can put that anywhere in there?
<slangasek> StevenK: on all archs?
<Keybuk> kirkland: anywhere in where?
<slangasek> kirkland: it's a command to be run
<StevenK> slangasek: lpia and ia64 should have it that list too
<Keybuk> slangasek: what is the 100% bug # ?
<kirkland> Keybuk: oh
<slangasek> kirkland: so you need to run it before the stuff you care about logging
<kirkland> slangasek: thx
<StevenK> s/ it/ hit/
<slangasek> Keybuk: bug #439198
<ubottu> Launchpad bug 439198 in nvidia-settings "using propretory drivers for my nvidia 9500gt did not function correctly. also, i got a crash when trying to install the upgrade tool." [Undecided,New] https://launchpad.net/bugs/439198
<slangasek> no, that's not it
<slangasek> Keybuk: bug #439138
<ubottu> Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Confirmed] https://launchpad.net/bugs/439138
<slangasek> better
<Keybuk> ok
<Keybuk> I shall upload the owner -> output fix
<StevenK> slangasek: I can pastebin the entire list of packages I touched, but I can see powerpc, ia64 in that list. Interestingly only -di bits for i386/amd64
<Keybuk> and if that makes it go away, we know we isolated the real cause
<slangasek> we do?
<Keybuk> and can "improve" it later
<slangasek> StevenK: ah.  Ok, I've punched the rest into main now; I just did it by source package, and after the next publisher run I'll demote those that aren't supposed to be in main
<StevenK> Ah, I did the piecemeal approach.
<slangasek> ehm, if there even are any
<StevenK> slangasek: I think it's because the publisher hasn't run yet
<StevenK> slangasek: Contents generation is running, which has taken over the publisher running this hour
<slangasek> StevenK: change-override assured me that there were packages still needing their components updated
<StevenK> Curious
<StevenK> I'm concerned that I didn't see -di bits for !i386,amd64
<slangasek> yeah, that's what I saw being picked up by change-override this time
<kirkland> slangasek: i just uploaded eucalyptus_1.6~bzr931-0ubuntu1_source.changes ... should this make it onto tonight's daily CD build?
<slangasek> kirkland: server daily build is at 10:30 BST, so yeah
<ttx> pitti, slangasek: please trigger a -server daily CD respin
<dholbach> good morning
<dholbach> lool, paulliu: there's a bunch of sync requests of new packages in the sponsoring queue... did you guys talk to the release team about it?
<paulliu> dholbach: not yet. How to do that? We only have an FFE.
<dholbach> oh... you have a FFE
<dholbach> sorry
<dholbach> nevermind me
<paulliu> dholbach: Those new packages are already well tested in our PPA for a long time. We are conservative now and not chasing the latest version of Intel's Moblin repo.
<dholbach> ok
<dholbach> where does libmoblin-panel-dev come from?
<paulliu> dholbach: mutter-moblin.
<paulliu> dholbach: There are some dependencies. anerley should go first. And then mutter-moblin.
<dholbach> looks like they are still waiting in the queue somewhere?
<paulliu> dholbach: Yes. In New.
<dholbach> ok
<lool> dholbach: (Right, we have a LP #425547 as some kind of standing FFE on Moblin packages)
<ubottu> Launchpad bug 425547 in Ubuntu Karmic "Ubuntu Moblin Remix: Merging ~moblin PPA packages into karmic" [Undecided,In progress] https://launchpad.net/bugs/425547
<lool> (Morning)
<dholbach> ok, super
<dholbach> hi lool
 * dholbach loves Launchpad's -changes mails that tell us how to spell "non-Standard" letters: ALEFHAHMEEMDAL ALEFLAMMEEMHAHMEEMWAWDALYEH
<dpm> pitti, hey good morning. I've tried to provide a fix for bug 449411 (extracting .desktop translations for onboard). Onboard is using the auto module from python-distutils-extra, which should autodetect .desktop.in files. However, it didn't seem to do it, and I had to explicitly list them in a setup.cfg file. I'm just wondering, was that the right way to do it?
<ubottu> Launchpad bug 449411 in ubuntu-translations "Make the desktop entries translatable" [High,In progress] https://launchpad.net/bugs/449411
<ttx> cjwatson: do you have the magic power to respin server ISOs ? My usual helper doesn't seem to be around :)
<pitti> Good morning
<ttx> pitti: good morning !
<pitti> dpm: hm, can you please show me your changes?
<pitti> hey ttx
<ttx> pitti: see backlog, I need a server CD respin when you have 2 minutes.
<nikolam> HI! packages.ubuntu.com does not work again. Who to report that?
<slangasek> wgrant: I guess none of the counts on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html deduct the "superseded source versions"?
<pitti> ttx: running (CC: slangasek)
<ttx> pitti: great!
<dpm> pitti, yes, the changes are here -> http://launchpadlibrarian.net/33487525/make-desktop-files-translatable.debdiff
<dpm> (I basically renamed the .desktop files to .desktop.in, marked them for translation and added them to setup.cfg)
<wgrant> slangasek: No, they don't. I can easily enough fix that.
<pitti> dpm: oh, there are two patches, one for renaming and one for adding the X-Ubuntu-Gettext-Domain one
<pitti> dpm: (they could be just merged, but nevermind; just looked confusing)
<liw> hm, LP isn't talking to me -- is this happening to anyone else?
<dpm> pitti, ah, ok, I'll take that into account for the next time
<slangasek> wgrant: would appreciate it, seeing as I noticed this 5 minutes /after/ sending out a mail to u-d-a with some overinflated numbers ;)
<pitti> it's not automatically handled since the .desktop file is explicitly mentioned in data_files[]; if you drop it from there completely, does it work?
<wgrant> slangasek: Oops. Sorry.
<slangasek> hmm, here's a nice NM regression, if a network ever fails to connect then clicking on it again in the applet doesn't retry
<dpm> pitti, I'll try. I've also noticed just now that the translations from the .ui files are not extracted, and it might be that's because of this as well (*.ui files are also mentioned as data_files)
<slangasek> either that or my driver is really unhappy
<Darxus> It's been 11 minutes since I uploaded a (large) package to my ppa, should I be concerned that I haven't gotten a confirmation or rejection from launchpad?
<wgrant> Darxus: Yes. But #launchpad is better.
<pitti> ttx: image built
<wgrant> slangasek: Code should be fixed, but LP is being disagreeable so it's not updating.
<Darxus> wgrant: Thanks.
<bryce_> "No apport report written because MaxReports is reached already" (on doing apt-get dist-upgrade)
<slangasek> wgrant: thanks :)
<ttx> pitti: thx. rsyncing and going for a coffee
<wgrant> liw: What is the problem you're having with LP?
<liw> wgrant, I can't get any page to open
<wgrant> It's not processing uploads, and I'm getting 502s and 500s far too often tonight. I think something might be wrong.
<wgrant> But normal page views work most of the time.
<dpm> pitti, ok, I've dropped the .desktop files from data_files[] in setup.py and I've also removed setup.cfg. That caused translations from the .desktop.in files to be extracted as expected, but the .desktop files don't seem to be then neither generated nor present in the package
<\sh> moins
<mac_v> kees: hi.. could you file a separate bug for the apport icon? or you could edit your existing bug accordingly
<pitti> dpm: I removed 20-add-i18n-setup-cfg.patch and desktop from data_files and applied your patch; 30-make-desktop-files-translatable.patch doesn't apply now
<james_w> mvo: would you have a few minutes to chat about bug 449738 today?
<ubottu> Launchpad bug 449738 in update-notifier "ships /var/crash when it doesn't need to, breaks apport for non-root processes on karmic installs" [High,New] https://launchpad.net/bugs/449738
<mvo> james_w: yes! right after lunch?
<james_w> suits me fine
<mvo> great, thanks!
<andersin> Can someone please point me to the place in shutdown that removes the grub2 environment variable recordfail
<andersin> The reason is that in karmic, whenever I come out of hibernate, grub does not have a timeout
<andersin> it does when I come back from normal shutdown
<cjwatson> andersin: there is no place on shutdown that removes that
<andersin> really, then how is that ever removed?
<cjwatson> andersin: however, there is a known bug that it is not removed on resume from hibernation
<cjwatson> andersin: that bug is fixed in the upload I'm currently testing
<cjwatson> andersin: it's removed on boot, not shutdown
<cjwatson> the purpose of recordfail is to determine whether the last boot succeeded
<andersin> ah, so once the boot is complete, it is removed?
<andersin> do you have a bug number for me by any chance, so I can take a look?
<cjwatson> andersin: bug 447725
<ubottu> Launchpad bug 447725 in grub2 "grub nice 'recordfail' feature doesn't work for hibernation" [Undecided,Fix committed] https://launchpad.net/bugs/447725
<andersin> thanks
<walterl> hi
<dpm> pitti, re: python-distutils-extra, sorry, I had some breakage after an update, got disconnected and sidetracked. The last thing I got from you was:
<dpm> "dpm: I removed 20-add-i18n-setup-cfg.patch and desktop from data_files and applied your patch; 30-make-desktop-files-translatable.patch doesn't apply now"
<pitti> dpm: right, I then just noticed that the patch was already applied
<pitti> dpm: it's a bit weird, if I do ./setup.py install --root=/tmp/x, the desktop.in files get installed automagically
<pitti> dpm: but with a .deb build they aren't
<dpm> pitti, what I've done now is to simply drop the 20-* patch, replace it by this -> http://ubuntu.pastebin.com/d352a1a1e and rebuild the package
<dpm> ah, ok
<pitti> dpm: just keep the setup.cfg for now, seems there's a p-distutils-extra bug somewhere
<dpm> pitti, ok, thanks a lot, I'll see if I can file a bug
<dpm> pitti, any recommendations on how to extract the translations from the *.ui files? They don't seem to be processed automatically, and I'm not sure how I can specify the .ui files in setup.cfg
<pitti> dpm: how do you mean? ui files (as in GTKBuidler) don't have translations
<pitti> dpm: oh, you mean extract the translatable strings into the POT?
<dpm> pitti, yes, they don't seem to be extracted
<dpm> and merged into the POt
<dpm> using the p-distutils-extra auto module
<pitti> this is all just supposed to happen automatically..
<pitti> dpm: you can manually add it to po/POTFILES.in, of course, but then you need to add all the other source files as well
<dpm> pitti, yes, that's what I thought, but it doesn't seem to happen with this package, and I couldn't find any other packages that use p-distutils-extra 'auto' instead of 'command', to use as an example
<pitti> dpm: jockey and apport
<dpm> pitti, ah, ok, I'll have a look at them
<pitti> dpm: aah, got it
<pitti>                 if '<interface>\n' in contents and '<requires lib="gtk+"' in contents:
<pitti>                     files.add('[type: gettext/glade]' + f)
<pitti> dpm: ^ that's my check if it's a GTKBuilder file (since Qt also uses *.ui)
<pitti> but your's has
<pitti> <interface domain="onboard">
<pitti> dpm: can you please file a bug about it?
<pitti> dpm: I think I can manage to fix it today, and upload a new version
<dpm> pitti, about the check? Sure, I can do it
<dpm> give me a couple of minutes
<pitti> dpm: about not picking up your .ui file
<dpm> ok
<pitti> dpm: I'm not entirely sure why it doesn't pick you your .desktop.in file for installation automatically
<pitti> feel free to file a bug about it as well
<dpm> Yes, I was intending to file a separate one :)
<dpm> pitti, ok, filed bug 451170 and bug 451175, let me know if you need more information
<ubottu> Launchpad bug 451170 in python-distutils-extra "GtkBuilder *.ui files are not recognized for translation extraction" [Undecided,New] https://launchpad.net/bugs/451170
<ubottu> Launchpad bug 451175 in python-distutils-extra "Desktop entries are not generated from .desktop.in files in auto mode" [Undecided,New] https://launchpad.net/bugs/451175
<ogra> cjwatson, could you let the two armel kernels out of NEW ?
<cjwatson> ogra: already doing
<ogra> thanks :)
<cjwatson> ArneGoetje: I've sponsored language-selector 0.4.12. I'm afraid I had to 'bzr upgrade' the ubuntu-core-dev branch to the 2a format in order to work around problems here, so you may find that you likewise have to 'bzr upgrade' your local branches before you can do anything useful
<amitk> hmm.. why is my "lock screen" option grayed out in the indicator-applet-session?
<seb128> amitk, because you use autologin I guess
<seb128> amitk, "design decision", we will change it before karmic with a distro patch though
<statik> hi james_w, i wonder if you could take another look at https://code.edge.launchpad.net/~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/snapshots-with-packaging/+merge/13209 ? from what I can tell, chad fixed the review comments
<james_w> hi statik
<james_w> it's on my list for today
<statik> you rock
<pitti> dpm: ok, got these two testcase'd and fixed; uploading now
<joaopinto> VTs are fixed, great
<dpm> pitti, that's awesome, thanks!
<amitk> seb128: aah. Thanks for the info.
<cjwatson> joaopinto: excellent
<\sh> do we have some problems with X + nvidia closed source drivers? I have a very fast blinking console after latest upgrades and a reboot on my ThinkPad R61
<ArneGoetje> cjwatson: thanks a bunch
<\sh> not an nvidia issue
 * Keybuk begins a mental countdown
<mterry_> slangasek, I'd like bug 430220 to get pushed before final freeze.  It fixes a buffering issue with rsyslog that prevents kernel messages from being immediately logged.  It also fixes some minor upstart packaging issues, but the buffering is the real win.
<ubottu> Launchpad bug 430220 in rsyslog "[karmic] Upstart fixups" [Undecided,Confirmed] https://launchpad.net/bugs/430220
<joaopinto> cjwatson, tks
<\sh> ok...removing old xorg.conf with nvidia driver entry helped...
<ArneGoetje> cjwatson: are you going to collectively pull translations from LP and update those packages which don't use language-packs?
<cjwatson> ArneGoetje: I normally do
<ArneGoetje> cjwatson: :) can you please include language-selector for that? That would save us the sponsoring step. ;)
<cjwatson> ok, can do
<ArneGoetje> cjwatson: thanks a lot
<cjwatson> ArneGoetje: any particular timing?
<ArneGoetje> cjwatson: well, deadline for those translations is tomorrow... so, I guess those uploads should happen on Friday?
<cjwatson> fine by me, maybe remind me then if you could :)
<ArneGoetje> cjwatson: ok.
<cjwatson> memory like a ... thing with holes in
<ArneGoetje> cjwatson: :)
 * Keybuk stops counting
<Keybuk> nobody jumped on me
<Keybuk> I guess I didn't break anything ;)
<StevenK> Keybuk: That we've found ... :-P
<Keybuk> StevenK: the thing about things I maintain is ...
<Keybuk> well...
<Keybuk> if I break things, people notice
<Keybuk> quickly
<StevenK> Heh, I know :-)
<Keybuk> siretart: around?
<Notch-1> hi, i'm developing an utility for gnome, but i do not have a samba share right now,so should somebody tell me how the samba mounted filesystem looks like, in ~/.gvfs directory please? i need just the name of the folder, like "smb on 192.168.0.1" or "samba on 192.168.0.1"...
<Notch-1> please guys, nobody uses samba? it will take a microsecond to help me :Â°
<TheMuso> Notch-1: For me, its "sharename on server"
<ttx> Notch-1: looks like "SHARENAME on SERVERNAME", but localized
<chrisccoulson> If you're developing a utility for gnome, then why do you need to know about stuff in ~/.gvfs?
<Notch-1> there is not something like "WebDAV on 192.168..."... like for ftp, ftps, dav, davs, etc ? in  other words: is the SHARENAME part fixed?
<Keybuk> bryce_: around?
<ttx> Notch-1: no, it's the share name, so it's not fixed.
<Notch-1> chrisccoulson:  because with gnome is very difficult to use smb://192.... so i'm replacing it with "~/.gvfs/SOMETHING on 192..."
<chrisccoulson> why is it difficult to use smb://?
<chrisccoulson> just do it all through GIO
<Notch-1> ttx: ah well, so i can't get my utility working with samba, only the others protocol...
<chrisccoulson> not everyone uses gvfs-fuse...
<hyperair> use the gfile functions
<hyperair> it'll automatically convert
<Notch-1> chrisccoulson: ask python people :D (http://groups.google.com/group/wxpython-users/browse_thread/thread/dafae506fc629087)
<Notch-1> hyperair: gfile function, of who?
<hyperair> er gio_whatever
<hyperair> i remember there was something
<hyperair> lemme dig it up
<chrisccoulson> Notch-1 - the GIO reference is here: http://library.gnome.org/devel/gio/stable/
<hyperair> Notch-1: i think g_file_get_path in C. not sure about the python equivalent
<hyperair> or wait.. i think i might know.
<hyperair>     path="$(python -c "import gio; print gio.File('$uri').get_path()")"
<hyperair> that was in a bash script
<Notch-1> thank you very much, i'll check it out
<thomas_sch> my friend can't use his sound card (Creative Labs SB Live! EMU10k1) anymore since he updated ubuntu.i modprobed als emu10k* modules and this is the dmesg output is http://nopaste.info/1595709da2.html
<thomas_sch> s/my friend/a friend of mine/
<seb128> wgrant, what is "superseded" on your ftbfs list?
<sistpoty|work> seb128: a new version was already uploaded after the test-build
<seb128> sistpoty|work, is there any point to list those?
<sistpoty|work> seb128: not too much I gues, unless you want to look at past build failures (funnily I did just this at the moment *g*)
<seb128> ok ;-)
<seb128> I've enough to do without looking at those I think ;-)
<sistpoty|work> heh, you could enjoy knowing how much is fixed already :P
<cjwatson> that is actually a useful thing to see
<cjwatson> an indication of progress ...
<TheMuso> /c/
<mdeslaur> tedg: I have a couple of questions about indicator-applet-session: how does it populate the "Guest session" item in it's menu? What does that run?
<tedg> mdeslaur: I'm not sure what you mean by "how does it populate" but it runs /usr/share/gdm/guest-session/guest-session-launch
<mdeslaur> tedg: that answers my question, thanks. I couldn't figure out what it was launching by looking at the source in the indicator-applet package...
<mdeslaur> (still can't...)
<tedg> mdeslaur: The code you're looking for is in indicator-session.  bzr branch lp:indicator-session ; cd indicator-session/src ; vi users-service.c
<mdeslaur> tedg: thanks!
<pitti> Keybuk, cjwatson: oh, now it's quite obvious why usplash fsck integration doesn't work any more -- mountall completely replaced /etc/init.d/check{root,fs}.sh :)
<Keybuk> yes ;)
<Keybuk> I actually ported your shell to C ages ago
<Keybuk> and have it sat here in a branch
<Keybuk> but needed to fix usplash first, because every time I tried to debug, I corrupted my console <g>
<pitti> Keybuk: you mean the entire /lib/init/usplash-fsck-functions.sh, or just the bits that called it from check*.sh?
<Keybuk> most of it
<pitti> Keybuk: since bug 451087 is currently assigned to me, should I take this up?
<ubottu> Launchpad bug 451087 in sysvinit "usplash fsck integration broken in Karmic (dup-of: 446596)" [High,In progress] https://launchpad.net/bugs/451087
<Keybuk> no, I have it
<ubottu> Launchpad bug 446596 in mountall "fsck does not show progress during boot" [High,In progress] https://launchpad.net/bugs/446596
<Keybuk> I dup'd your bug against the one assigned to me :p
<pitti> ah, awesome
<Keybuk> pitti: it's basically done, I just need to do some testing and upload today
<pitti> so, off to fixing the next dozen..
<pitti> Keybuk: many thanks
<Keybuk> it stalled because my Dell laptop died
<Keybuk> (which had the Intel card, on which usplash worked)
<Keybuk> so I'm on a different laptop, which has nvidia, and usplash didn't work :p
<pitti> hm, that means I need to go back to fixing gdm
<Keybuk> I fixed usplash early this morning ;)
<Keybuk> what's up with gdm?
<pitti> Keybuk: https://edge.launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=12698 is still full of it
<Keybuk> slangasek: I've been staring at the mountall bugs trying to work out why a bug you marked Won't Fix is still in the list
<Keybuk> slangasek: just realised, when you Won't Fix a release-targeted task, it puts the master task back!
<Keybuk> pitti: eep
<cjwatson> yeah, it's the only way to achieve that effect
<cjwatson> i.e. Won't Fix for karmic -> previous state for some future release
<pitti> Keybuk: yes, in fact that's the only way to throw something off the release monitor
<Keybuk> yeah, I think steve actually really intended to Won't Fix the bug though ;)
<tormod> pitti: would you be able to look at the debdiff in bug 440852 please?
<ubottu> Launchpad bug 440852 in sane-backends "saned is very verbose about not being started" [Undecided,New] https://launchpad.net/bugs/440852
<pitti> tormod: I looked at it :)
<pitti> tormod: do we even install that by default?
<tormod> pitti, I think so, I did not install it
<pitti> tormod: If we do, I'm all for it; but if you have to install it explicitly, I'd rather leave it in TBH
<pitti> http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.manifest
<pitti> ah, ther it is
<pitti> pulled in by hplip
<tormod> pitti, maybe you have an opinion (for karmic or not) on 45883 as well?
<pitti> wow, a five-digit bug?
<tormod> pitti, yes I have been waiting for years :)
<pitti> tormod: sane-backends uploaded
<tormod> pitti, thanks
<pitti> tormod: hm, I seem to remember reading about that in some changelog recently
<pitti> tormod: ah, in indicator-session 0.1.7-0ubuntu1
<pitti> bug 444391
<ubottu> Launchpad bug 444391 in gnome-media "Sound recording doesn't produce sound when it plays." [Low,Incomplete] https://launchpad.net/bugs/444391
<pitti> erm
<pitti> tedg: ^ you clearly referenced the wrong bug in the indicator-session changelog :)
<sladen> mpt: suggestions for bug #334544 ?
<ubottu> Launchpad bug 334544 in indicator-session "indicator applet needs keyboard shortcut" [Medium,Confirmed] https://launchpad.net/bugs/334544
<tedg> pitti: Indicator-session is so good it fixes sound bugs too! ;)
<pitti> wow
<sladen> indicator session is so awesome that usability is an after-thought
<pitti> tormod: hm, I wonder if that will just land in 2.28.1 (which we'll upload anyway); I'm going to ask Richard about it
<tormod> pitti, is it on the trunk but not yet in 2.28 branch
<pitti> tormod: right, I just checked; that's why I'm asking hughsie
<pitti> tormod: either way, thanks for getting that fixed
<tormod> pitti, thanks, would love to see it finally fixed in Karmic :)
<pitti> tormod: updated; Richard will land it on 2_28
<tormod> pitti, alright thanks for checking! that was my last fix in the queue for karmic :)
<pitti> nice
<mathiaz> cr3: yo!
<pitti> I never expected karmic to get that level of polish, given how much new crack went into it..
<mathiaz> cr3: how is checkbox 0.8.4 progressing?
<cr3> mathiaz: fixed, but I'm looking into removing my existing branch and having one commit instead of the multiple commits I've been done
<cr3> err, s/done/doing/
<mathiaz> cr3: as you wish
<cr3> mathiaz: I should ping you in a moment, when done. I'll go through the same process and create a merge request for you
<mathiaz> cr3: awesome
<mathiaz> cr3: you don't need to send me an email anymore - just subscribe me as a reviewer
<mathiaz> cr3: LP sends out notifications now
<cr3> mathiaz: yay!
<pitti> tormod: http://git.gnome.org/cgit/gnome-power-manager/commit/?h=gnome-2-28&id=26182959c7fea5aa63a23e57de4cf62b8da5fe54 :)
<tormod> pitti, excellent
<cr3> mathiaz: all done, I'm pleasantly surprised that I was able to remove a branch and then create another branch with the same name after. sweet!
<mathiaz> cr3: has all your natural optimism gone away overnight?
<cr3> mathiaz: nope, it is eternal
<cr3> mathiaz: if it hadn't worked for some reason, I would've still been optimist that there was a good reason :)
<cr3> mathiaz: that reminds me of removing people or teams in launchpad, the name still seems to be kept and there's a good reason for that... which I unfortunatley don't remember :)
<liw> cr3, re-use of names leads to opportunities of identity theft
<mathiaz> free: hi - could you mark https://code.launchpad.net/~free.ekanayaka/landscape-client/jaunty.fix-347983/+merge/12172 as being merged?
<free> mathiaz: hello, sure
<free> mathiaz: btw, thanks for the karmic upload of the latest landscape-client, I'll use a bug next time :)
<junjun> hi
<mathiaz> free: could you have a look at bug 450907?
<ubottu> Launchpad bug 450907 in landscape-client "package landscape-common 1.3.2.4-0ubuntu0.9.10.0 failed to install/upgrade: error writing to '<standard output>': Input/output error" [Undecided,New] https://launchpad.net/bugs/450907
<junjun> any idea on how to install gcc-3.4 (to compile some old apps) on Karmic?
<free> mathiaz: we saw it, but didn't quite understand it
<zul> pitti: ping
<mvo> free: there a few dup on various package with this error, I have no idea yet what causes it
<free> mvo: you mean various packages are failing with this error?
<james_w> mvo: are these from upgrades with aptdaemon do you know?
<mvo> james_w: not sure, that was my first instinct, but there is one kpackagekit as well
<mvo> free: yes, including eglibc
<james_w> that would still fit I guess
<free> mvo: the only thing that comes to my mind is a "usermod -g landscape landscape" in landscape-common.postinst, which makes the script write a "usermod: no changes" to stdout
<mvo> but not in a reproducable way
<mvo> james_w: my gut feeling is that it is releated to aptdaemon
<james_w> I've seen that error a couple of times
<free> mvo: it would probably better to "> /dev/null 2>&1"-it
<james_w> I put it down to the frontend going away
<james_w> as X went away
<mvo> james_w: oh? you saw it with PK? or aptdaemon? or both?
<james_w> aptdaemon
<mvo> cool, any way to reproduce?  ctrl-alt-backspace while it is running?
<james_w> I had X die I think
<james_w> so that might work
<james_w> however, I'm not sure why that would break a pipe to dpkg's stdout?
<james_w> I guess the X session going kills D-Bus, which kills aptd?
<james_w> no, it's on the system bus isn't it?
<mathiaz> cr3: checkbox-cli still failing in a guest - http://paste.ubuntu.com/293187/
<mathiaz> cr3: I've run a successful test on my laptop though
<mathiaz> cr3: so I'll upload 0.8.4 to the archive
<siretart``> Keybuk: yes?
<Keybuk> siretart``: I had to smash the cryptsetup repo
<mathiaz> cr3: the issue on my virtual guest should still be tracked down - at some point
<Keybuk> siretart``: you might have to pull --overwrite
<siretart``> I notice that you preferred to overwrite my commit over adding an mkdir -p to debian/rules :-/
<mvo> james_w: its on the system bus - the only thing I can think of is that its a bug in aptdaemon. it feed stdout back and forth over the bus for the terminal
<james_w> mvo: that could well do it then
<siretart``> regarding the cryptsetup branch, it is royally messed up anyway. we should probably just replace it with launchpad's auto imports
<mvo> james_w: I have a look
<siretart``> besides, I image that apport hook would have been very useful
<mathiaz> cr3: could you mark https://code.launchpad.net/~cr3/ubuntu/karmic/checkbox/0.8.4/+merge/13347 as being merged?
<siretart``> james_w: has the launchpad package-branch importer been suspended, or is it 'just' slow?
<james_w> siretart``: which package are you looking at?
<james_w> it's not suspended
<james_w> and it is quick :-)
<james_w> so it's probably a failure
<siretart``> james_w: cryptsetup
<james_w> siretart``: yeah, it's a failure, sorry
<james_w> bzrlib.errors.DuplicateFileId: File id {tree_root-20090616034229-jktmk6p46y1yuzrw-182} already exists in inventory as InventoryDirectory('tree_root-20090616034229-jktmk6p46y1yuzrw-182', '', parent_id=None, revision='james.westby@ubuntu.com-20070109215306-1r0mkhd5igfx7a8z')
<james_w> on fetch
<james_w> which is odd
<siretart``> no problem, but how could I check if an package import failed myself?
<james_w> they are not currently publically accessible, sorry
<james_w> I should talk to IS about that
<siretart``> OK, just wanted to confirm. no problem
<james_w> I was hoping that no-one would need to care ;-)
<siretart``> :)
<debfx> seb128: ted acked my changes to fix bug #346840, please also read my last comment on that bug in the hope to convince you to apply the workaround for kde
<ubottu> Launchpad bug 346840 in pidgin "Buddy List taskbar icon shows on all virtual desktops" [Low,Incomplete] https://launchpad.net/bugs/346840
<slangasek> Keybuk: heh, yes, that's how wontfix+devel target works :)
<seb128> debfx, ok for the workspace thing, I'm still not convinced for kde
<slangasek> mterry: right, someone nominated that as a "fix this before release" bug in response to the email announcement... I can take a look at that today
<Keybuk> slangasek: yeah I just got confused
<Riddell> seb128: if we have a fix for an issue surely we should use it?
<seb128> Riddell, yes, a fix, not a random hack to do something non standard depending of an environment variable
<Riddell> seb128: how else is this going to get fixed before final freeze?
<seb128> Riddell, I don't know, either by somebody wanting to look at what is wrong in the code or not
<seb128> Riddell, is pidgin the default kubuntu im client?
<seb128> we have thousand of small glitches, I don't see that one as a priority for karmic right now
<Riddell> because it's one we have a workaround for
<slangasek> ScottK: hrm, it seems emacs23 is still building 'emacs' - debian/control.in :/
<james_w> I was once told you could override the version of a single binary package from a source package by putting "Version: whatever" in its binary stanza
<james_w> experimentation suggests this was a fib, and intuition suggests it would cause trouble any way
<dholbach> james_w: I hope that's one of the best-kept secrets of the world ;-)
<james_w> is there any way of doing this?
<slangasek> james_w: right, you have to do it with dpkg-gencontrol -v instead
<slangasek> and it's a horrible, horrible thing
<james_w> we want to provide a transitional package from the new source, but the old source had an epoch
<ScottK> slangasek: Sorry.  I'll fix it again
<slangasek> which is why the gcc package does it on every single binary it generates :)
<slangasek> ScottK: thanks
<james_w> so would that be frowned upon?
<cr3> mathiaz: done and thanks!
<slangasek> james_w: well, that's what I just did in emacs22
<james_w> oh, I'll crib then
<slangasek> and I did more of the frowning than anyone else ;)
<mathiaz> cr3: that's 394 poutines and 5822 beers you owe me now
<james_w> heh
 * sistpoty|work is sorry for not having checked good enough to make slangasek frown
<slangasek> sistpoty|work: I don't think it's really the responsibility of the release team to check for arbitrary craziness in the package when ok'ing freeze exceptions... but I fear the uploader may have been expecting this to happen :/
<Keybuk> slangasek: the release team should check every single upload
<Keybuk> with an oscilloscope!
<sistpoty|work> well, I do have a few oscilloscopes here (at work) :P
<LaserJock> I have some lasers
<LaserJock> maybe that'd help
<ttx> Keybuk: sorry for the lazy upstart assignment. And thanks for the detailed explanation.
<mpt> sladen, no, I don't have any
<mpt> sorry
<mpt> I'm not familiar with keyboard navigation of the panel in general -- is there a help page describing it?
<slangasek> wgrant: I'm still not seeing the statistics I would expect to on the rebuild status page; the only summary figure for 'main' is 89, and I can tell at a glance that this doesn't equal 3 ;)
<kirkland> jdstrand: do you recognize this?  http://pastebin.ubuntu.com/293242/
<jdstrand> kirkland: I've never seen it except for maybe once when you asked me about it before (ie, it seems vaguely familiar, but I've never encountered it in my work)
 * Riddell hugs bryce_ for finding the fix for bug 432521
<ubottu> Launchpad bug 432521 in xserver-xorg-video-intel "kdm does not restart X server (that crashed on logout)" [High,Fix released] https://launchpad.net/bugs/432521
<cjwatson> bryce_: this -nr patch that's in your 'red' PPA - are you considering it for karmic?
<kirkland> cjwatson: hey, could you rescore https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292104 ?
<kirkland> cjwatson: eucalyptus needs to test that to fix a release critical bug
<cjwatson> kirkland: done
<mathiaz> zul: why is puppet still in universe?
<zul> mathiaz: because of libaugeas-ruby asac hasnt looked at it yet
<mathiaz> zul: ok
<ccheney> slangasek: hey what did you determine was the cause for it pulling in the other ooo style? I followed up to the bug just now and was wondering why the openoffice.org-gtk, which openoffice.org-gnome depends on would have pulled the proper style without pulling in both?
 * zul returns
<ccheney> er would not have
<slangasek> ccheney: because openoffice.org-gnome depends on openoffice.org-core, openoffice.org-gtk, and the dependencies are traversed depth-first
<ccheney> slangasek: oh
<slangasek> so it was still seeing -style-default before -human-style
<ccheney> oh ok
<ccheney> we might run into that same issue on kubuntu then if i understand what you said
<ccheney> since it wants -style-oxygen (iirc)
<slangasek> right, I haven't checked kubuntu - I noticed Ubuntu because it pushed the CDs oversized
<ccheney> ok
<slangasek> ccheney: ok, checked now and kubuntu still has -style-oxygen
<slangasek> and not -style-galaxy
<ScottK> ccheney: IIRC we seed the oxygen style directly as a work around.
<ccheney> ScottK: ok
<mathiaz> is there a reason why avahi would change the existing ip address configuration when started?
<sladen> mathiaz: it fires up a link-local address and attaches to that
<mathiaz> I've got a system that uses dhclient. Then I installed eucalyptus-cloud (which starts avahi) - the IP address of the system has changed to 169.254.169.254
<mathiaz> the old address (10.153.108.210) is still pingable though
<mathiaz> but ifconfig eth0 doesn't list the old address anymore
<hyperair> shouldn't it be eth0:avahi having the link-local address?
<hyperair> speaking of which network-manager fails to communicate with avahi, iirc
<hyperair> avahi will get an address, then nm will timeout and complain that ip config failed or something
<hyperair> it can get rather annoying
<mathiaz> hyperair: the system doesn't use nm
<hyperair> hmm
<hyperair> so what does ifconfig say?
<sladen> mathiaz: can you pastebin   ifconfig -a
<mathiaz> sladen: http://paste.ubuntu.com/293272/
<mathiaz> kirkland: hey - do you remember the bug about detecting the wrong ip address for the CC (ie 169.254.169.254) we saw last week
<mathiaz> kirkland: has this been fixed?
<kirkland> mathiaz: it's been hacked around
<mathiaz> kirkland: right - hacked around
<mathiaz> kirkland: see above - I may have find another clue
<kirkland> mathiaz: my CLC still occasionally thinks its ip address is 169.254x2
<mathiaz> kirkland: I've installed eucalyptus-cloud and now eth0 has 169.254.169.254
<mathiaz> kirkland: where it used to have 10.153.X.Y
<kirkland> mathiaz: right, i'm seeing that occasionally -- that sucks
<kees> seb128: I need bug 446395 assigned -- I've been totally unable to reproduce it, but more and more people are hitting it (and we're starting to see some hopefully useful debug output)
<ubottu> Launchpad bug 446395 in gnome-screensaver "Screen lock unlocks after 5 wrong attempts" [Critical,Confirmed] https://launchpad.net/bugs/446395
<pitti> cr3: *hug*
<cr3> pitti: right back at you!
<seb128> kees, looking
<chrisccoulson> kees / seb128 - i wonder if that's related to a gnome-screensaver crasher that's just been submitted
<kees> chrisccoulson: I sure hope so, because I've been having a terrible time getting more info about it.  :P
<kees> chrisccoulson: which bug # is the new crash?
<chrisccoulson> i've just triggered the bug anyway
<chrisccoulson> the crash is bug 451345
<ubottu> Launchpad bug 451345 in gnome-screensaver "gnome-screensaver-gl-helper assert failure: gnome-screensaver-gl-helper: ../../src/xcb_io.c:542: _XRead: Assertion `dpy->xcb->reply_data != ((void *)0)' failed." [Medium,Incomplete] https://launchpad.net/bugs/451345
<cr3> pitti: man, you've had a lot on your shoulders this release: policy kit and hal seem to have been big ones
<seb128> chrisccoulson, kees: the log has
<seb128> "The program 'gnome-screensaver' received an X Window System error.
<seb128> This probably reflects a bug in the program.
<seb128> The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
<seb128>   (Details: serial 11249 error_code 9 request_code 53 minor_code 0)
<seb128> "
<pitti> cr3: that was quite a large chunk indeed, but it was fun, too; lots of nice upstream development for me :)
<kees> seb128: yeah, but they didn't have dbgsym installed, so they couldn't catch the error to get a backtrace
<cr3> pitti: oh nice! always feels good to give back
<chrisccoulson> right, so they're the same bug then
<kees> chrisccoulson: while I certainly want that to be true -- how do you know?  does the helper crashing do this?
<chrisccoulson> i need to try and see if i can get a better backtrace then
<pitti> cr3: yeah, I was able to port the entire gvfs from hal to DK, and write the udev bits for hotkey management; for the other bits I mainly coordinated and gave some suggestions
<pitti> cr3: with the benefit that I can now pretty much ignore all those 500 hal bug reports :-P
<pitti> cr3: (which was actually the entire purpose of the show, to get rid of this bug and race condition laden monster)
<cr3> pitti: that's an awesome idea: when there are too many bugs, remove the project!
<seb128> chrisccoulson, kees: I can confirm that after 5 tries it does from password prompt to screensaver
<seb128> chrisccoulson, kees: I can confirm that after 5 tries it does from password prompt to screensaver
<seb128> ups
<seb128> does -> goes
<seb128> so maybe the screensaver hack they use lead to a crash
<kees> seb128: right, that's the expected behavior.  they're saying it goes to the desktop.
<seb128> seems gnome-screensaver is quite crashing when using nvidia binary drivers and 3d screeensavers
<kees> seb128: having a hack crash shouldn't take out the whole screensaver.
<seb128> good point
<pitti> ScottK: oh, so karmic's emacs is supposed to be 22? I think I installed it for my wife at beta, and she ended up with 23
<seb128> let's wait for chrisccoulson to get a debug stacktrace
 * kees nods
<seb128> chrisccoulson, what videocard do you use?
<kees> I will try to create a local crashing hack...
<ScottK> pitti: If you want the supported one, 22 is what you want.
<pitti> cr3: yes, indeed! and since users don't really see hal, we can actually do it :)
<pitti> ScottK: hm, if emacs23 doesn't build "emacs" any more, how can we make sure that the old 22 "emacs" package becomes current again?
<seb128> chrisccoulson, you crash was a gnome-screensaver-gl-helper one, what would be useful is a gnome-screensaver stracktrace
<ScottK> pitti: I think slangasek had some kind of black magic for this.
<pitti> ScottK: I'm not entirely sure whether LP will like us when we rebuild emacs22 with the binary having a lower version number than the previous one
<pitti> ScottK: ok; so it's been discussed already then? fine
<slangasek> pitti: it won't; we have to do stupid version tricks
<pitti> slangasek: ok, so binary specific version number then
<chrisccoulson> seb128 - i'm trying to get one but it doesn't happen consistently here
<slangasek> pitti: yep
<pitti> release times are fun; time for nasty hacks :)
<chrisccoulson> and i've no virtual consoles either, which makes debugging a pain
<seb128> chrisccoulson, use user switching and a real user?
<chrisccoulson> seb128 - yeah, i'll have to do that
<kirkland> cjwatson: could I trouble you for a rescore of https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292274 ?
<kirkland> cjwatson: thanks, as always
<chrisccoulson> would be nice to have some consoles though:)
<chrisccoulson> right, triggered it again in gdb but forgot the sync option
<kirkland> pitti: slangasek: hey, do you guys have build rescoring capabilities?
<pitti> kirkland: I do
<slangasek> not I
<kirkland> pitti: https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292274
<kirkland> pitti: could you have that build now?
<pitti> kirkland: well, I can't do "now", but I can do "next"
<kirkland> pitti: good enough :-)
<pitti> kirkland: i. e. only sysadmins can actually cancel build jobs
<pitti> but I guess that's not necessary here
<pitti> kirkland: (done)
<kirkland> pitti: thanks muchly
<pitti> np
 * pitti discovers grep --color=auto in the guest session (apparently new ~/.bashrc default); nice!
<seb128> pitti, same here ;-)
<pitti> having used my /home directory since pre-warty, I wonder how much other goodness I have missed
<kees> seb128: okay, I can reproduce it with an explicitly crashing hack.
<seb128> kees, good
<chrisccoulson> kees - you recreated it too right?
<kees> chrisccoulson: yeah, but it doesn't always happen.
<kees> chrisccoulson: still can't catch a backtrace, though
<chrisccoulson> i've got one
<chrisccoulson> http://paste.ubuntu.com/293307/
<kees> chrisccoulson: I selected antmaze, then replaced it with "sleep 10; kill -SEGV $$" shell script
<bryce_> cjwatson, the DX team wanted to test the norootbg patch to see if it'd help with what they were doing.  I never heard back from them on how their testing turned out or if they needed it.  So at this point I do not have plans to put it in.
<chrisccoulson> it's calling XFreePixmap with an invalid pixmap somewhere
<chrisccoulson> hence the BadDrawable error
<seb128> chrisccoulson, kees: I got one too, http://paste.ubuntu.com/293308/
<seb128> but I lack libx11 debug symbols
<kees> are those different?  chrisccoulson's was a crash through "shake dialog"
<kees> seb128's was due to a keypress?
<chrisccoulson> was it with --sync?
<seb128> new one
<seb128> http://paste.ubuntu.com/293308/
<seb128> it's by running "gnome-screensaver --sync --no-daemon"
<seb128> and attaching gdb from an another session
<seb128> and breaking on gdk_x_error
<chrisccoulson> hmmm, they look different
<seb128> then I do a serie of wrong passwords
<seb128> yes, the first one was not a crash
<seb128> on the second one I got the "The error was 'BadDrawable (invalid Pixmap or Window parameter)'."
<seb128> doh
<seb128> the new one is http://paste.ubuntu.com/293311/
<seb128> sorry wrong url before
<seb128> chrisccoulson, kees: ^ that's the crash one
<chrisccoulson> that's better :)
<chrisccoulson> XFreePixmap is what throws the error
<kees> ok, that one might be the same, some unresolved functions, but the path looks similar
<seb128> right
<seb128> http://paste.ubuntu.com/293316/
<seb128> that one is a debug one
<seb128> seems similar to chrisccoulson's one now
<seb128> the bug is quite easy to trigger indeed
<chrisccoulson> i found it quite hard to trigger :/
<kees> hmpf, I hit it once now and not yet since then.  :(
<chrisccoulson> it takes a lot of tries before i trigger it
<seb128> I set the screensaver hack on random hack there
<seb128> and I do enter, wait a second, enter, wait a second, enter, etc
<seb128> it takes 6 to 8 tries to get it
<seb128> I sometime to esc between to display the screensaver and try again though
<seb128> not sure if that makes a difference
<kees> the 5th failure shuts down the password prompt dialog, at which point g-ss will sometimes crash
<kees> I can't reproduce it under gdb
<seb128> I don't always get it on the 5th try I think, but I'm not sure
<seb128> kees, run gnome-screensaver --sync --no-daemon and attach gdb from an another vt
<seb128> then break on gdk_x_error?
<kees> oh, good idea
<seb128> that's what I do there
<seb128> because otherwise I had no way to go back to gdb to type "bt" there
<seb128> since the screensaver was frozen on the session
<kees> hrm, I still can't get it to crash now.
<kees> tedg, bryce_: either of you working on inkscape pre4 for karmic yet?
<tedg> kees: No, I haven't made a package.
<chrisccoulson> kees - my eyes are starting to hurt trying to figure out how gnome-screensaver works right now - i'm going to send the bug upstream just in case they come up with some ideas before we do
<tedg> kees: It should just be the grab tarball thing, right?
<bryce_> kees, I've not looked at it
<bryce_> hmm, ought inkscape have released by now?  getting kinda late...
<tedg> bryce_: Apparently one planned patch is outstanding.
<kees> chrisccoulson: ok
<tedg> bryce_: And translation updates.
<kees> tedg: yeah, me either.  I'll snag the tarball
<tedg> kees: What's the command to grab the tarball, I'm looking, but I never remember it.
<kees> tedg: "uscan" (I'm running it now...)
 * tedg tries "iscan" but apparently it only works when you tell other people "you scan"  (hmm, pronunciation puns don't work well over IRC)
<kirkland> mvo: ping?
<kirkland> mvo: I have that qemu-kvm upload ready to go...  did you have that transitional package patch for me?
<bryce_> tedg, we all scan
<bryce_> (our eyes can)
<tedg> bryce_: Heh, you're not convincing me that these type of jokes are good for IRC ;)
<kirkland> mvo: okay, i found https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/451508 from james_w
<ubottu> Launchpad bug 451508 in qemu-kvm "should ship a kvm transitional package" [High,Triaged]
<james_w> kirkland: good timing :-)
<kirkland> james_w: thanks, man!
<seb128> debfx, I've uploaded your debdiff I'm too busy to argue but I will probably not keep the workaround in karmic+1 so you should still look at make things work with KDE correctly
<mvo> kirkland: yeah, that the one
<kirkland> mvo: perfect, got it!
<mvo> cool, thanks
<cjwatson> bryce_: I'm experimenting with it now in conjunction with a usplash change Scott suggested
<cjwatson> bryce_: apparently it's working nicely for him, and gets us away from an ugly transition that's attracting a lot of attention
<cjwatson> bryce_: not got it working for me yet, though, just wanted to check whether I was wasting my time
<bryce_> cjwatson, ideally for something like this I'd like to see some good coverage to make sure we're not improving one driver at the expense of others, it's getting kind of late to make a decision on it though
<cjwatson> is it all that driver-specific? aside from KMS vs. non-KMS
<cjwatson> my plan was to only pass that option if KMS is up; we can't do very much about the non-KMS usplash->xsplash transition anyway
<bryce_> cjwatson, well, mainly I'm thinking of an earlier patch that affected how root background was handled, which provided a nice solid performance boost on -fglrx, but after we put it in we found it caused nasty window corruption issues for kde users on a few other video drivers
<bryce_> I guess if it's limited to only KMS, that narrows it to one driver effectively (at least for Karmic) so that'd reduce the risk
<bryce_> still worth testing at least with ati KMS; folks are starting to use that now even though it's not the default
<cjwatson> mm, right
<cjwatson> if it isn't obvious, what I'm trying to do is leave the usplash logo on-screen until xsplash gets around to replacing it
<bryce_> right
<cjwatson> incidentally when testing this sort of thing I REALLY want network-manager to get a command-line interface that we install by default
<bryce_> AGREED
<bryce_> I run into that problem a lot
<mathiaz> kirkland: hey - doing an UEC install - run into this problem: http://paste.ubuntu.com/293351/
<cjwatson> having no working X and being unable to apt-get install <last version of stuff that worked> is no fun
<bryce_> I suppose if I were less lazy I'd figure out a workaround
<mathiaz> kirkland: have you seen this with the current packages?
<bryce_> cjwatson, yuppers
<mathiaz> kirkland: note that this is not an ISO install
<cjwatson> there are a couple of command-line interfaces floating around the internet, but of course I can't download them right now
<mathiaz> kirkland: just a package install on a base system
<kirkland> mathiaz: i've never seen that on
<cjwatson> there was a python one which I contemplated just typing in interactively, but (a) it looked a bit hatstand and (b) it didn't actually support activating connections
<bryce_> cjwatson, fwiw I recall noticing asac had a wireless-with-no-x-running setup on his laptop once when I was helping him with an X problem.  I've neglected to inquire what that was, but maybe he knows a good trick
<cjwatson> it may depend on the wireless driver
<cjwatson> some of them, you can just dhclient
<bryce_> ah could be
<cjwatson> in fact I'm sure I used to be able to do mine that way, or maybe I had /e/n/i configured
<debfx> seb128: ok, thanks
<pitti> Riddell: any idea what happened to PyKDE4.kdecore?
<pitti> /usr/lib/pyshared/python2.6/PyKDE4/kdecore.so
<pitti> hm
<pitti> $ python -c 'import PyKDE4.kdecore'
<pitti> ImportError: No module named kdecore
<mathiaz> http://paste.ubuntu.com/293427/ <- does this mean there are multiple ip addresses for eth0?
<pitti> mathiaz: you might have virtual subdevices, such as eth0:avahi?
<mathiaz> pitti: probably - how can I tell?
<pitti> mathiaz: check "ifconfig eth0"?
 * pitti isn't familiar with ip output, sorry
<mathiaz> pitti: http://paste.ubuntu.com/293430/
<mathiaz> pitti: well - I've seen that a couple of times - dhclient gets the 10.X address and then avahi starts and there is the 169.Y address
<pitti> mathiaz: erm, sorry; does "ifconfig" give multiple interfaces for eth0? above looks pretty normal
<mathiaz> pitti: nope
<pitti> mathiaz: yes, it's supposed to actually
<mathiaz> pitti: ifconfig -a only shows one interface for eth0
<mathiaz> pitti: the 10.X address has disappeared from ifconfig
<pitti> in the past it used to run avahi-autoipd on them which created virtual subdevices for link-local addresses
<pitti> but apparenty that changed
<mathiaz> pitti: although the system is reachable via the 10.X address
<mathiaz> pitti: the problem here is that I'm trying to get the IP address of the system
<mathiaz> pitti: and ifconfig shows 169.X which is not working well
<Lure> pitti: afaik, due to python-sip4 upgrade (license issue), whole PyQt depends needs to be rebuild
<Lure> pitti: so it may be related to this
<pitti> Lure: right, but that already happened for kdebindings
<pitti> see bug 450851
<ubottu> Launchpad bug 450851 in kdebindings "ubuntu-bug fails with most recent karmic kubuntu updates" [High,Confirmed] https://launchpad.net/bugs/450851
<pitti> ah, got it
<pitti> /usr/lib/python2.6/dist-packages/PyKDE4/__init__.pyc still stayed around
<pitti> ... only to get the next crash, darn
<mathiaz> pitti: bug 441669 <- does that ring a bell?
<ubottu> Launchpad bug 441669 in openssh "User with restricted rights is able to shutdown machine while ssh superuser is connected" [Low,New] https://launchpad.net/bugs/441669
<kees> pitti, slangasek: I'd like to get some eyes on bug 449535 before I upload what I think is the fix.  e.g. I don't want to break it further.
<ubottu> Launchpad bug 449535 in apt "/etc/cron.daily/apt doesn't run apt-get update anymore" [Critical,Confirmed] https://launchpad.net/bugs/449535
<kees> (I'm assuming cjwatson is asleep, and mvo is offline)
<slangasek> kees: looking
<slangasek> kees: I still get an 'E: The update command takes no arguments'
<kees> slangasek: with the evals missing?
<slangasek> kees: yes; the eval isn't the cause of that error
<slangasek> the 'update' needs to be moved to the end of the commandline, after the -o
<kees> hrm
<kees> + apt-get -y update -o APT::Update::Auth-Failure::=cp /usr/share/apt/apt-auth-failure.note /var/lib/update-notifier/user.d/
<kees> Ign file: karmic/main Translation-en_US
<kees> I didn't need that...
<slangasek> kees: ah, because you set VERBOSE
<slangasek> if it's not set, the command is 'apt-get -qq -y update -o ...', which fails for some reason
<slangasek> heh, the apt-get manpage says never to use '-qq update', and that '-qq -y' is redundant :P
<kees> with verbose unset, it runs correctly with eval removed...
<kees> oh, no, my bad
<kees> those evals are still wrong...
<slangasek> the evals are wrong, yes
<slangasek> I don't know what possessed someone to put those there
<kees> + apt-get -qq -y -o 'APT::Update::Auth-Failure::=cp /usr/share/apt/apt-auth-failure.note /var/lib/update-notifier/user.d/' update '2>/dev/null'
<kees> E: The update command takes no arguments
<kees> hrm
<kees> oh, heh, the redirection is getting escaped.  ;)
<kees> that's what the eval is for?  madness
<slangasek> oh, I suppose it is
<slangasek> nice :)
<slangasek> so, ok, the eval isn't broken, just CRAAAAAZZY
<kees> right, so actually the originally suggested patch is more correct...
<chrisccoulson> kees - you had a look at this screensaver issue at all?
<kees> chrisccoulson: got side-tracked, sorry
<chrisccoulson> no worries ;)
<chrisccoulson> i have my suspicions what might be triggering it, but i'm having a hard time trying to figure out how to prove it
<kees> chrisccoulson: seems like the "shake" animation somehow?
<chrisccoulson> yeah, on each shake iteration, some events are queued on the main loop to realign and redraw the window contents. i suspect what might be happening is that the lock dialog disappears whilst the events are being dispatched (when gnome-screensaver-dialog exits)
<chrisccoulson> i'm going to rebuild gnome-screensaver with some extra debug info in, to give me a better idea what order the different events get dispatched in
<chrisccoulson> just to see if there is a difference between crashing/not crashing
<kees> chrisccoulson: I also noticed that sometimes while validating, the dialog with grey out the "unlock" button and highlight "cancel" for a moment before shaking.  other times, the whole dialog would go grey before the shake.
<chrisccoulson> yeah, i'm not too sure why that would be
<mdke> pitti: I think probably for the fix to bug 441401 to become available for ubuntu-docs, the langpacks need to be rebuilt? Am I right? The bug is still appearing with ubuntu-docs 9.10.10 which has now been published (ie the symlink is still broken)
<ubottu> Launchpad bug 441401 in ubuntu-docs "Symlink not working with Karmic translations" [High,Fix released] https://launchpad.net/bugs/441401
 * chrisccoulson is thinking xtrace is going to come in handy here for me
<mdke> pitti: if I'm right, then I'll just wait for the next langpacks. If not I'll do some more digging :)
<slangasek> mdke: why is ubuntu-docs suddenly so much bigger?
<slangasek> it looks like the language split has been dropped?
<chrisccoulson> kees - the X call which generates the error is actually CreatePixmap (as shown in my xtrace log here: http://paste.ubuntu.com/293501/ )
<chrisccoulson> the invalid drawable is 0x05400020, which my log shows was destroyed earlier on
<chrisccoulson> which sort-of backs up my suspicion
<chrisccoulson> so the fix is probably for gnome-screensaver-dialog to not exit on its own accord after 5 failed auth attempts, but rather wait for gnome-screensaver to kill it after it has done the shake animation
<kees> chrisccoulson: yeah
<chrisccoulson> i hope that's it anyway
<asac> bryce_: connections marked as automatically connect + available to all users should work without X
<bryce_> asac, ah 'available to all users'... hadn't seen that option, I'll look for it
<ScottK> lamont: What's the status on maven?  ETOOHARD?
<slangasek> kees: are you uploading the 449535 fix, then?
<kees> slangasek: yeah
<slangasek> ok
<kees> slangasek: er, no, after looking at the bzr tree, I'd like mvo to do it -- there are a number of changes pending
<slangasek> ok
<slangasek> seems the bug has been there long enough that one more day won't make much difference
 * kees nods
<slangasek> mdke, pitti: is the "ubuntu-docs has ballooned" bug known to be linked to bug #441401, or is it a new issue?
<ubottu> Launchpad bug 441401 in ubuntu-docs "Symlink not working with Karmic translations" [High,Fix released] https://launchpad.net/bugs/441401
<lamont> ScottK: EPOSTKARMIC I expect - it's below a few other much more critical activities
 * lamont afk
<ScottK> lamont: OK.  Would you please comment in the relevant bugs then.
<ScottK> slangasek: ^^^ I think we need to remove maven2 then, since it's currently, as I understand it broken.
<lamont> gar.  once I read the ticket to see where doko got to with his trying to get something installable for me to use for bootstrapping
<ScottK> OK.
<TheMuso> /c/c
#ubuntu-devel 2009-10-15
<pitti> mdke: eww, right, we must strip gnome help files, otherwise we'll install the files in both places; sorry, I'm afraid we need to fix the symlinking instead
<pitti> slangasek: ^
<PovAddict> does anyone know what other distros use apport, if any?
<pitti> PovAddict: OpenSUSE does
<slangasek> pitti: does that mean the solution is known and in progress?
<pitti> slangasek: not yet, I'm afraid, it basically turned up yesterday
<pitti> slangasek: that's the cdbs task on that bug
<chrisccoulson> kees - are you interested in working on bug 446395?
<ubottu> Launchpad bug 446395 in gnome-screensaver "Screen lock unlocks after 5 wrong attempts" [Critical,Triaged] https://launchpad.net/bugs/446395
<chrisccoulson> i'll work on that tomorrow if nobody else has fixed it in the meantime
<Notch-1> news about the loop module? still =y?
<pitti> mdke: yes, it will need a langpack rebuild to pick up the new gnome help files
<pitti> slangasek, mdke: got a DSL reconnect (I really ought to sleep at this time..), did you answer?
<pitti> slangasek: hm, the .deb is 450 kB; what do you mean exactly with "baloon"?
<slangasek> pitti: apt says upgrading ubuntu-docs here will take up 64MB more space
<pitti> mdke: ignore the "we must fix symlinking" bit, I was confused; fdupes is unrelated to translations
<pitti> ?!?
<PovAddict> wow, 446395 looks serious
<slangasek> pitti: installed-size: 169084 vs. 231408
 * pitti looks at debdiff ubuntu-docs_9.10.9_all.deb ubuntu-docs_9.10.10_all.deb
<slangasek> pitti: hah - something is calculating installed-size *before* pruning files from the tree (!)
<slangasek> (AFAICT)
<slangasek> hmm, no
<pitti> slangasek: it seems the new version replaced all the relative symlinks with absolute ones
<slangasek> pitti: which shouldn't change the package size at all, really
<pitti> well, slightly
<pitti> but certainly not in the MB range
<PovAddict> not much after compression
<PovAddict> how many symlinks are we talking about?
<Notch-1> PovAddict: only if you count on your screensaver for your security, luckly
<slangasek> pitti: right, in both cases the installed-size is way overestimated - the actual unpacked size is 17-19MB, the installed-size figures are > 160MB.  I think it's being calculated before the tree is trimmed
<pitti> PovAddict: 5270
<slangasek> pitti: relative and absolute symlinks should still take up exactly one block on disk, surely?
<PovAddict> oh true, blocks... yes, it should take the same space
<pitti> slangasek: right; I just purged and reinstalled ubuntu-docs, and df says before/after is a difference of 20.9 MB
<PovAddict> unless you have a crazy-long path somewhere
<pitti> slangasek: uncompressed yes, just the .deb gets a tad bigger (not much presumably)
<slangasek> pitti: right - apt is reporting the installed size
<pitti> ok, so I think this is a red herring
<slangasek> which shouldn't differ for absolute vs. relative symlinks
<slangasek> pitti: yeah; it's a bug in its own right though
<slangasek> I'll report it
 * pitti -> bed, really this time
<slangasek> 'night!
<directhex> night pitti!
<jdong> directhex: gasp do I see banshee tagged?
<slangasek> ArneGoetje, pitti: was language-support-extra-eu meant to be removed from the archive?  (No rdeps, depends on NBS myspell-eu-es)
<directhex> jdong, 1.5.1? yes
<jdong> directhex: indeed
<jdong> directhex: heh a friend and I are now whining over how banshee psychically stole our smart playlist shuffler XD
<jdong> directhex: we chose to build a student's t-distribution modeling each song's preference score though ;-)
<directhex> jdong, the code in libmono-system-corlib2.0-cil which steals the user's brainwaves also serves to send all user-made extensions upstream silently
<jdong> directhex: I KNEW IT! THEYVE BEEN WARNING US FOR YEARS ABOUT THIS!
 * jdong registers boycott(2n+1)novell.com
<directhex> jdong, you want to boycott boycott-boycottnovell?
<jdong> :)
<jdong> well the site for n <=2 has been taken, hasn't it? ;-)
<directhex> dunno dude, i'm just a packager
<ArneGoetje> slangasek: all language-support-extra-* packages got removed from the archive. Instead of myspell-eu-es, hunspell-eu-es gets installed with the language-support-writing-eu package.
<slangasek> ArneGoetje: well, language-support-extra-eu didn't get removed :)
<slangasek> ArneGoetje: is there a bug # I can reference for a removal request?
<spotter> anyone having trouble upgrading gdm?  failing in configure scripts
<slangasek> ArneGoetje: in fact, I see 11 language-support-extra-* in karmic presently
<ArneGoetje> slangasek: eh? I thought pitti removed them already...
<slangasek> ArneGoetje: apparently not - could I ask you to file a quick bug report requesting their removal and explaining (briefly) why they should go away, and I can knock them out of the archive?
<ArneGoetje> slangasek: ok
<ArneGoetje> slangasek: against "ubuntu"?
<slangasek> ArneGoetje: against one of the source packages
<ArneGoetje> slangasek: ok
<spotter> nm, figured it out.  gdm doesn't like being upgraded as root
<spotter> needs to be done as sudo'd user
<slangasek> spotter: um
<slangasek> spotter: that's not something gdm is entitled to have an opinion on; could you please file a bug report (with error messages)?
<chrisccoulson> the GDM upgrade issue is already reported isn't it? (the failures due to the su calls in the postinst script)
<slangasek> ah, ok
<spotter> slangasek, bugs already filed
<slangasek> (is the bug targeted to karmic?)
<spotter> not by me
<spotter> by many others
<spotter> I just commented on one
<chrisccoulson> slangasek - yeah, that's the one
<spotter> its been this way for a few weeks
<spotter> been ignoring it as had other things, and laptop still worked
<slangasek> what bug?
<spotter> here's the bug I commented on https://bugs.launchpad.net/bugs/438789
<ubottu> Launchpad bug 438789 in gdm "package gdm 2.28.0-0ubuntu8 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed]
<spotter> might be a duplicate of others
<chrisccoulson> that's a slightly different issue but it's the same root cause
<slangasek> ah; looks like that should be marked as a duplicate of 438561?
<chrisccoulson> the stuff in the postinst script causes a gvfs daemon to be spawned in the GDM session
<chrisccoulson> slangasek - yeah, you're right
<slangasek> ok
<slangasek> thanks for confirming :)
<chrisccoulson> i need to speak to seb128 tomorrow and see what he wants to do with this one
<chrisccoulson> i've got an idea for fixing it but it involves a non-trivial patch to g-s-d
<spotter> btw, I didn' (and don't currently) have a .gvfs file in my /var/lib/gdm directory
<spotter> nto before it refused to configure and not after I got it configured w/ sudo
<chrisccoulson> spotter - it's still most likely a related issue. the su calls seem to cause multiple problems at the moment
<spotter> ok
<ArneGoetje> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/language-support-extra-de/+bug/451802
<ubottu> Launchpad bug 451802 in language-support-extra-de "[karmic] please remove from archive" [Undecided,New]
<slangasek> ArneGoetje: thanks!
<zul> slangasek: i think m2crypto is ok without the testsuite enabled
<ArneGoetje> cjwatson: seems the installer still doesn't know about the Chinese package split... it still installs the -zh metapackages, instead of only -zh-hans or -zh-hant for Simplified and Traditional Chinese respectively. Against which package should I file the bug? pkgsel?
<ArneGoetje> cjwatson: ah, ok. the latest daily Live CD doesn't have the latest ubiquity and language-selector yet... updating and retry...
 * hyperair notes the wonderful clicking sounds his soundcard makes when resuming from powersave
<slangasek> zul: well, that's for the MIR team to say
 * hyperair pokes dtchen 
<LaserJock> cjwatson: good news! The Edubuntu DVD seems to be working again! Thanks so much, you rock
<hyperair> does root-on-dmcrypt result in the root partition not being unmounted properly?
<hyperair> oh great, now my /etc/init/gdm.conf went missing. wtf?
<hyperair> lolwut now encoding problems
<hyperair> win
<TheMuso> hyperair: gdm.conf is no longer used
<hyperair> i meant /etc/init/gdm.conf
<TheMuso> oh
<hyperair> ext4's driving me up the wall
<hyperair> even after a clean reboot, fsck complained endlessly about all kinds of things, and whacked up /var/lib/dpkg
<hyperair> ugh
<jdong> gasp ext4 loses tons and tons of data in the writeback cache? :)
<hyperair> jdong: why, is it a known issue?
<hyperair> well i could probably blame myself for running an rc kernel, but i didn't think things would get *this* bad with a filesystem that's supposedly stable
<slangasek> TheMuso: ubuntustudio-desktop depends on gstreamer0.10-schroedinger, but that package is NBS (and I'm removing it) - can you update ubuntustudio-meta?
<ScottK> slangasek: IIRC it moved to a different gstreamer package and we didn't sync the one it moved to.
 * ScottK recalls no details though.
<TheMuso> slangasek: RIghto thanks
<slangasek> ScottK: hmm, looking
<ScottK> It's also 1AM here and I'm very tired.  I could be totally full of crap.
<ScottK> Just so you're warned.
 * TheMuso waits to see if further updates are necessary
<slangasek> ScottK: right, confirmed; the changelog said it moved to -bad, and I took it at face value
<slangasek> TheMuso: ^^ so please hold off wrt uploading, at least
<TheMuso> slangasek: Right, I agree, since I have bad installed and /usr/lib/gstreamer-0.10/libgstschro.so is not in bad
 * slangasek nods
<hyperair> where does upstart's umount code go?
<hyperair> or does it not unmount filesystems at all?
<slangasek> hyperair: scripts are still in /etc/rc[06].d/
<hyperair> ah i see
<slangasek> ScottK: has anyone taken a position wrt the right way to fix this for karmic, that you're aware of?
<slangasek> I see bug #436350
<ubottu> Launchpad bug 436350 in gst-plugins-bad0.10 "Please Upgrade Gstreamer Bad and Multiverse Plug-ins To 0.10.14" [Undecided,Confirmed] https://launchpad.net/bugs/436350
<ScottK> slangasek: Not that I know of.
<slangasek> and I don't see slomo on IRC :/
<TheMuso> slangasek: ok meta is ready fr upload, waiting for your call in the event something needs changing
<slangasek> TheMuso: ok; everything I see here currently tells me we should drop the dep from the meta packages and pull in a new upstream version of plugins-bad, because the current upstream version of schroedinger doesn't even have the plugin in the source anymore
<slangasek> TheMuso: I would advise you to go ahead with uploading
<TheMuso> slangasek: ok
<hyperair> slangasek: you're wanted.
<hyperair> er whoops
<hyperair> slomo:
<slangasek> works well enough, though ;)
<hyperair> haha
<slangasek> slomo: hi, you seem to have synced the new upstream version of schroedinger which drops the gst plugin, but there doesn't seem to be any work done on getting the new upstream version of gst-plugins-bad in that takes it over?
<hyperair> hmm it seems that banshee hasn't been seeing karma support for quite some time
<slomo> slangasek: blame seb128, i asked him to sync gst-plugins-bad0.10 0.10.14 more than a month ago :) unfortunately i didn't notice that he forgot to do it
<slomo> slangasek: sorry
<hyperair> what was the tool used to do reverse build dep?
<maco> hyperair: apt-cache rdepends?
<hyperair> that's r *binary* dep
<slomo> hyperair: grep-dctrl on apt's Sources files
<hyperair> i'd like reverse build-dep
<maco> ah ok
<hyperair> slomo: ah right thanks
<slomo> hyperair: good work on updating banshee btw :) does it already use the external hyena?
<hyperair> hmm so it seems libkarma-cil only has one reverse build-dep
<hyperair> slomo: no it doesn't. that's still stuck in binary new
<hyperair> slomo: also, i don't see anything in the build system that looks for hyena
<hyperair> so i guess not
<ScottK> hyperair: reverse-build-depends script in ubuntu-dev-tools wraps grep-dctrl and makes it easy.
<hyperair> ah cool
<hyperair> thanks
<mdke> slangasek: sorry, I don't know what has caused that, the deb is the same size
<hyperair> whose brilliant idea was it to make https://launchpad.net/ubuntu/+source/<pkg>/+filebug point to a wiki page instead?
<hyperair> >=(
<hyperair> i know what information i want to include and don't need apport damnit
 * hyperair grumbles
<ScottK> hyperair: #ubuntu-bugs is the best place to provide feedback on that decision.
<hyperair> alright, i'll do that when i figure which channel to leave
<cjwatson> ArneGoetje: probably a bug with tasks on pkgsel and ubiquity, yes; although I'm afraid we may not have time to get that dealt with this cycle
<spaetz_> shite, my firefox-3.5 crashes 100% on start now, even when removing the profile directory....
<spaetz_> amd64
<spaetz_> asac: you signed of the latest release a couple of hours ago. Can that be related?
<spaetz_> reboot helped with the firefox crash issue, sorry for bothering
<dholbach> good morning
<slangasek> slomo: ah - ok, I'm following up on bug #436350, then
<ubottu> Launchpad bug 436350 in gst-plugins-bad0.10 "Please Upgrade Gstreamer Bad and Multiverse Plug-ins To 0.10.14" [Medium,Confirmed] https://launchpad.net/bugs/436350
<slangasek> mdke: bug #451764 filed, with analysis
<ubottu> Launchpad bug 451764 in ubuntu-docs "Installed-Size header in ubuntu-docs is broken" [Low,Triaged] https://launchpad.net/bugs/451764
* slangasek changed the topic of #ubuntu-devel to: Archive: Final Freeze! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<simon-o> Hobbsee: What do you think about bug 359934? Is this ok with you and can we get this into karmic?
<ubottu> Launchpad bug 359934 in ubuntu-restricted-extras "Java is not included in ubuntu-restricted-extras" [Undecided,Confirmed] https://launchpad.net/bugs/359934
<seb128> doh
<seb128> slangasek already froze the archive
<seb128> I was expecting an extra day to get work done ;-)
<slangasek> seb128: I work European hours on Thursdays now ;)
<seb128> slangasek, still I was expecting freeze at the end of the day
<dholbach> seb128: I'll mail the press letting them know that we'll delay by a day, so we can get more new gnome crack!
<slangasek> heh
 * dholbach hugs seb128
<seb128> dholbach, we plan to get GNOME 2.28.1 anyway as every cycle ;-)
 * seb128 hugs dholbach
<seb128> which is on monday next week
<dholbach> seb128: if you need help with sponsoring, let me know
<seb128> dholbach, would be nice thanks!
<dholbach> can't let my old desktop buddy down :)
<seb128> ;-)
<Hobbsee> simon-o: ie, reverting version 29?  This seems to be a policy decision that keeps switching, which is why i've been trying to ignore it.  mvo:  your thoughts?
<slangasek> mvo: 451428> hrm, that's not a bug in grub, that's a bug in whatever called grub to be installed...
<mvo> slangasek: so you think he is installing kernels from some location that is not ubuntu?
<simon-o> Hobbsee, mvo: Yes it is. Right now the java plugin is installed on amd64 but not on i386 which is inconsistent. I would like to keep the plugin in u-r-e until the open source plugin is stable.
<slangasek> mvo: no, I think something removed grub-pc from his system and replaced it with grub on upgrade
<mvo> simon-o: it seems like pitt did this change in 29
<mvo> slangasek: aha, I misread the bug then, that makes sense. I will ask for more info
<slangasek> mvo: already done, just wanted to get a heads-up since you see these bugs before I do
<simon-o> mvo, pitti: yes he did. But it seems like icedtea6-plugin isn't stable enough yet, what do you think pitti?
<slangasek> s/get a/give you a/
<mvo> slangasek: I had one report about a jaunty grub2 being removed on upgrade, but was not able to reproduce yet as my VM did not boot with grub2 in jaunty
<mvo> slangasek: thanks
<slangasek> right; there've been a few reports from people saying grub-pc went away in favor of grub, I /think/ these are all actually fallout from old (fixed) bugs but am chasing them up to be sure
<cjwatson> slangasek: of course there are still some cases where we need to use grub rather than grub2, e.g. dmraid
<slangasek> cjwatson: sure - those aren't the people that have been filing bugs, though :)
<pitti> Good morning
<\sh> moins pitti
<pitti> ArneGoetje, slangasek: hm, I wasn't aware of -extra; I just removed language-support-translations*
<chrisccoulson> good morning pitti
<slangasek> pitti: ah - well, they're knocked out now
<pitti> good, thanks
<pitti> simon-o: icedea-plugin? what?
<simon-o> pitti: sorry, I didn't provide any context. We were talking about bug 359934 and if u-r-e should contain sun-java6-plugin or not (currently this is the case on amd64 but not on i386). icedea-plugin is maybe not stable enough to replace the sun plugin
<ubottu> Launchpad bug 359934 in ubuntu-restricted-extras "Java is not included in ubuntu-restricted-extras" [Undecided,Confirmed] https://launchpad.net/bugs/359934
<pitti> simon-o: hm, I'm afraid I have no idea how stable it is; but given that we're about to remove sun-java6, I'd rather point people to openjdk TBH
<pitti> doko might have a better opinion
<simon-o> pitti: I think the wish to include the sun plugin came because of bug 344705
<ubottu> Launchpad bug 344705 in openjdk-6 "IcedTea Plugin Doesnt Work" [High,Confirmed] https://launchpad.net/bugs/344705
<mvo> Keybuk: could you please give me a hand with bug #451556 ?
<ubottu> Launchpad bug 451556 in update-manager "fails to reboot during recent 9.04 -> 9.10 upgrades" [High,Confirmed] https://launchpad.net/bugs/451556
<mvo> Keybuk: it seems to be upstart releated
<ArneGoetje> cjwatson: ok...
<ArneGoetje> cjwatson: BTW: Evan's libwebkit-1.0-2 fixes the crash issue for me.
<evand> ArneGoetje: can you post a comment to that effect on 451980?
<ArneGoetje> evand: ah, you are online... :) yes, I will post a comment
<evand> ArneGoetje: thanks!
<evand> pitti: is the fact that bug 401381 didn't pick up the core dumps for grub a bug in apport, or more fundamental to how apport works?  If it's the latter, do you see any use for rules that say something like, "if ubiquity crashed, and the following processes also have crash dumps, include them in ubiquity's crash report"?
<ubottu> Launchpad bug 401381 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader()" [Undecided,New] https://launchpad.net/bugs/401381
<evand> (the grub crash appears near the bottom of the syslog)
<pitti> evand: that bug is against ubiquity with a python traceback; I don't quite understand why it should have a core dump?
<evand> Jul 19 13:00:50 ubuntu grub-installer: Floating point exception (core dumped)
<evand> Jul 19 13:00:56 ubuntu last message repeated 4 times
<evand> (from UbiquitySyslog)
<pitti> evand: well, of course the package hook could do some magic to pick up the related .crash reports, but if you just attach them you wouldn't get auto-duplication and retracing
<pitti> evand: the .grub crash ideally gets submitted to LP separately, and gets retracing/duplication love
<evand> Perhaps it could offer to file both at once (so there's a greater chance the user will actually do it), and link the two together with a comment?
<pitti> evand: FYI, just updated bug 451263; unblocked now
<ubottu> Launchpad bug 451263 in ubuntu-artwork "Ubuntu logo is not redistributable" [Critical,In progress] https://launchpad.net/bugs/451263
<evand> hooray
<pitti> evand: would be nice indeed; unfortunately right now we have no control about the actual filing process in the browser;
<evand> pitti: ah, unfortunate. Do you want a wishlist bug for this anyway?
<pitti> evand: sure; don't hold your breath for it, though, it requires large changes, also in LP (be able to file bugs through launchpadlib, replicate the bug filing interface in GTK/KDE, etc.)
<pitti> and looking for duplicates, etc.
<evand> understood
<slangasek> bryce_: something strange in the diff of your latest -evdev upload; a patch to configure.ac to make it think it's 2.2.2 instead of 2.2.5? (+ some undocumented source changes)
<slangasek> bryce_: I'm looking at this to fix the FTBFS, but the other stuff looks notable
<bryce_> slangasek, hrm, I'll doublecheck
<bryce_> hmm, didn't show up in my debdiff
<slangasek> bryce_: well, somehow you also skipped -1ubuntu3 (or rather, seem to have renumbered -1ubuntu2 to be -1ubuntu3 (!)), the previous upload was -1ubuntu2 - all very confusing
<slangasek> uploading -1ubuntu4 in the meantime for the build fix
<bryce_> oh crap, I know what I did
<bryce_> slangasek, let me do the -1ubuntu4 if you've not done it already
<slangasek> bryce_: ok, go ahead
<tseliot> slangasek: can I upload a fix for nvidia-common (bug #292606)? It should fix a rather nasty problem with dist-upgrades
<ubottu> Launchpad bug 292606 in nvidia-common "dkms - error when installing custom kernel" [Medium,New] https://launchpad.net/bugs/292606
<slangasek> tseliot: yes, no need to ask before uploading :)
<tseliot> slangasek: ok, thanks
<bryce_> slangasek, can I re-upload fixed -1ubuntu4 or does it need to be -1ubuntu5?
<slangasek> bryce_: I haven't uploaded a -1ubuntu4 yet, just use that number
<lool> slangasek: I just pushed a new partman-uboot to fix the initial implementation of the mkfs.ext2 call in there; Marvell had told me in the past that -I 128 should be used (not -b 4096), and they just confirmed in https://bugs.launchpad.net/bugs/450906
<ubottu> Launchpad bug 450906 in adana "u-boot is not tolerant of unclean ext2 file systems" [High,Incomplete]
<bryce_> slangasek, fixed package uploaded
<slangasek> bryce_: cheers
<slangasek> lool: will see it as I process the queue, I'm sure :)
<lool> slangasek: Oh yeah sorry; I guess you should poke if you have any question rather than me poking you whenever I upload, sorry
<slangasek> lool: no worries, and if you have anything that's you need pushed through the queue urgently, just shout
<lool> Ok I dont
<lool> Thanks
<bryce_> slangasek, I got an error trying to upload -1ubuntu4
<slangasek> oh?
<slangasek> er, wait
<dholbach> lool: where is mutter-moblin? is it still sitting in some queue?
<dholbach> lool: the other sync requests build-depend on libmoblin-applet-dev or whatever it's called
<slangasek> bryce_: sorry, -1ubuntu4 was the one you already uploaded?  Sorry, I was talking nonsense when I told you to reuse that number
<bryce_> ahh ok
<slangasek> bryce_: -1ubuntu4 was already in the archive, so you have to increment; was getting my wires crossed
<bryce_> slangasek, ok -1ubuntu5 uploaded
<slangasek> bryce_: thanks
<lool> dholbach: mutter-moblin is in Debian; I thought paulliu would request a sync for it
<lool> paulliu: Hey ^
<dholbach> oh, I thought it was sitting in some queue already
<dholbach> paulliu: usr/share/mutter-moblin/theme/moblin-panel-myzone is empty (not sure if that's empty) and src/mnb-scale-group.* are LGPL-2 (not sure if that's an upstream oversight)
<dholbach> other than that the package looks good to go
<lool> I need some help with brainstorm
<dholbach> lool: ^
<lool> dholbach: thanks for the review
<dholbach> no worries
<lool> I updated http://brainstorm.ubuntu.com/idea/21684/ but would like to subscribe to it
<lool> Also, I'm not sure of the good way to link a brainstorm idea with a bug report
<lool> I just put a link in the solution description which is not ideal
<dholbach> lool: jcastro will know, but he's not awake yet, I guess
<lool> dholbach: thanks
<dholbach> and ndeschildre does not seem to be around either
<ogra> Keybuk, moo ...
<ogra> Keybuk, why did you move the framebuffer hack in usplash into the C code ? i would like to change the script to use fb1 instead of fb0 (my external monitor with way higher resolution) moving the code into C means i need to recompile the whole thing
<lool> ogra: i dont think the language of the implementation should matter; the issue is rather with usplash not handling multiple screens which is well known
<sladen> lool: urm.  you're supporting the hardcoding of configuration options?  (!)
<sladen> lool: hardcoding a setting that might need changing is different from simply ensuring it has a good default
<lool> sladen: fb0 was not configurable either
<ogra> it was just easier to change in the shellscript ... it wasnt meant to be configurable at all though
<lool> sladen: ogra's critic was that he couldn't update the /usr/share/initramfs-tools script to set fb1 easily as a hack to workaround usplash picking the wrong res
<lool> The real bug is usplash handling of multiple screen
<ogra> indeed
<ogra> well, deeper even i guess
<lool> In fact we shouldn't be reading the size from /sys but just let bogl figure out the best size
<ogra> the kernel seems to pick the res for my laptop LCD in kms
<lool> But that's orthogonal to fb0 versus fb1
<ogra> instead of using the external one
<cjwatson> putting it in C code let us simplify the upstart job quite a bit
<cjwatson> if it needs to be configurable for now, have the C code read it from usplash.conf
 * sladen blantently assumed the script in question was under /etc already
<ogra> cjwatson, it doesnt need to
<slangasek> tseliot: I don't understand why in nvidia-common you aren't just making sure the stdin/stdout of the nvidia-detector call are on clean fds?
<slangasek> mvo: should bug #432819 be un-targeted as well as un-milestoned, or do you consider this a candidate for SRU?
<ubottu> Launchpad bug 432819 in software-center "software-center doesn't respect X-AppInstall-AlwaysOnTop" [High,Confirmed] https://launchpad.net/bugs/432819
<slangasek> mvo: could you also comment on bug #434173?
<ubottu> Launchpad bug 434173 in language-selector "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [Undecided,Fix committed] https://launchpad.net/bugs/434173
<tseliot> slangasek: cleans fds such as?
<tseliot> s/cleans/clean/
<slangasek> tseliot: use shell redirection to control what goes in and out of the process?
<ttx> kirkland: around ?
<paulliu> dholbach: hmm. I'll upload a new package for those changes.
<ttx> kirkland: committed a euca -0ubuntu3 with a hotfix for the wrong IP issue and the web UI changes from Gustavo. I waited for the CD spin to go with the euca_rootwrap change so that it can be tested independantly
<pitti> ogra: do you get pulsating ubuntu logo on livefs boot now? it works for me now
<ttx> but the wrong IP issue was a pita that needed to be avoided asap and the ui changes had to go in urgently
<ogra> pitti, i havent tested live images since a while
<tseliot> slangasek: patches are welcome ;)
<mvo> slangasek: 432819> the alwaysOnTop should be removed for karmic. I don't think it can be done in a way suitable for a sru
<mvo> slangasek: I have a look at the language-selector one now (I have to add that l-s is no longer officially my baby)
<pitti> ogra: would be nice to confirm
<slangasek> tseliot: shall I reject the upload in the queue, and put together a patch?
<ogra> pitti, will do once the board is available (it's busy atm)
<tseliot> slangasek: with my solution I made sure that things don't crash in any case
<tseliot> slangasek: so, please accept it and if you have the time to work on a patch, I'll be glad to review it
<slangasek> mvo: the language-selector bug has a task open on update-manager, and cjwatson commented in the report that ArneGoetje should talk to you
<ttx> kirkland: note that the wrong IP hotfix doesn't address the question of "adding a linklocal address confuses ifconfig" which needs to be discussed more.
<Riddell> mvo: do you have any observations on bug 452090 ?  davmor2 failed to upgrade from hardy
<mvo> Riddell: I just commented on it
<Riddell> mvo: hum, anything that can be done about it?
<mvo> Riddell: not sure, was this a stock kubuntu hardy setup?
<Riddell> mvo: I expect so, davmor2?
 * mvo tests in a VM
<pitti> tkamppeter: ah, the buildd hostname fix is being worked on
<tkamppeter> pitti, I got this mail from slangasek, too.
<tkamppeter> So probably we can upload 1.4.1-8 today and it will get built.
<tkamppeter> pitti: It is unusual for a package investigating the build server (reading IP, searching for printers and available PPDs, ...) during build.
<slangasek> tseliot: I'm looking at this nvidia-common bug report and the changes, and I don't see how this could ever work... the script you're calling this from is invoking debconf, which means stdout of this script is *always* attached to the debconf frontend - flushing output doesn't help anything?
<tseliot> slangasek: I can't reproduce the problem here. The script won't crash though, which is a big win.
<tseliot> slangasek: if the script gets garbage instead of the proper output it won't give it to debconf as a reply
<davmor2> mvo: yup
<slangasek> tseliot: I really can't figure out why you've gone with this solution, or which fd it is you think has the garbage on it (which is generally confusing enough when debconf is involved...)
<davmor2> mvo: stock + proposed for the adept update
<slangasek> tseliot: why should nvidia-detector ever need to be run in a loop?
<davmor2> mvo: sorry forgot + updates
<slangasek> tseliot: nvidia-detector doesn't appear to read from stdin; if it did, you could work around this with LATEST=$(nvidia-detector < /dev/null); and the stdout of nvidia-detector is already being captured
<tseliot> slangasek: if all goes well, it is called once, otherwise try again and, if this goes wrong, just give up
<slangasek> yes, why do you think it should *ever* need to be called more than once?
<tseliot> slangasek: no, it doesn't read from stdin
<slangasek> this doesn't seem to have anything to do with the bug=
<slangasek> I'm not going to accept something I don't understand during final freeze...
<tseliot> slangasek: as you can see in the bug report, it can happen that my script doesn't get the output of nvidia-detector because dkms leaves something like " * Running DKMS auto installation service for kernel 2.6.27.2" on stdout
<tseliot> and LATEST will be assigned that value
<slangasek> tseliot: eh, I don't see that at all from the bug report, or from the code
<tseliot> slangasek: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/292606/comments/4
<ubottu> Launchpad bug 292606 in nvidia-common "dkms - error when installing custom kernel" [Medium,New]
<tseliot> slangasek: what I know for sure is that nvidia-detector can give print "nvidia-glx-$VER" or "none"
<slangasek> tseliot: that shows the bufferred stdin being sent *to debconf*, not preventing reading the correct output from nivdia-detector
<tseliot> slangasek: how?
<tseliot> that's the point
<slangasek> tseliot: the parent process has already started the debconf frontend before calling this script; it looks like the garbage has already been sent to the debconf frontend before the nvidia-common script has ever been called, and nvidia-common is just the first process to read back the resulting error code from the pipe
<slangasek> (i.e., I agree with Mike Stroyan's analysis in the bug)
<cjwatson> oh, yes, this is like malloc debugging
<cjwatson> it's often the next thing along that gets to encounter the problem
<tseliot> slangasek: ok, so are you suggesting that I simply prevent the script from failing without trying again?
<tseliot> or do you have a different solution in mind?
<slangasek> tseliot: yes - and that the way to do this is by fixing dkms, not nvidia-common
<slangasek> what's starting debconf, though?
<tseliot> slangasek: ouch, again. superm1 has a few objections though (to fixing that in dkms) and this is why I tried to deal with the problem in nvidia-common
<cjwatson> kernel postinst?
<slangasek> cjwatson: not that I see
<tseliot> yep ^^
<cjwatson> hmm, it used to I think, obviously no longer
<tseliot> /etc/kernel/postinst.d/
<cjwatson> 2.6.27.7-k8 though, that's kind of old
<cjwatson> and looks custom
<tseliot> nvidia-common installs the script there
<tseliot> this is meant to help users who dist-upgrade with apt from the command line
<tseliot> as Update Manager already uses nvidia-common to get rid of obsolete drivers
<cjwatson> kernel image packages generated using make-kpkg still load the debconf confmodule in the postinst
<slangasek> right
<slangasek> so kernel postinst starts the frontend, dkms inherits the fd and throws garbage at it, nvidia-common catches it
<tseliot> yes, it could be
<cjwatson> and while Ubuntu images of that same vintage apparently didn't, /etc/kernel/postinst.d/ in general probably has to assume that stdout might be debconf
<slangasek> so this is a dkms bug, and superm1 will just have to accept that :)
<davmor2> mvo: I've commented on the bug as to what I had done.
<tseliot> slangasek: ok, so in the mean time I'll modify nvidia-common so that it's capable of detecting garbage but doesn't call nvidia-detector more than once. Right?
<slangasek> tseliot: that sounds better to me, yes - how are you going to detect the garbage?
<tseliot> i.e. I'll get rid of the while loop
<mvo> davmor2: thanks, I have a look
<slangasek> cjwatson: won't this garbage cause all subsequent debconf transactions to be out-of-step, unless you know exactly how many lines to read back from the confmodule?
<mvo> davmor2: I had it running in my auto-upgrade testing setup and it seems to be doing fine there, but it might have a slightly different setup
<davmor2> mvo: I'll start it back up from fresh.  I'm wondering if it pulled in something else from proposed that it should of so I'll double check
<cjwatson> slangasek: yes
<cjwatson> the solution to garbage on debconf's input is *not to send it there in the first place*
<cjwatson> there's no reliable way to recover
<slangasek> tseliot: ^^ so basically, once dkms has broken things, you cannot reliably recover and ensure you get correct behavior out of the debconf commands
<slangasek> so I wouldn't even try - this should get fixed in dkms
<tseliot> slangasek: I know that nvidia-detector can print either "nvidia-glx-$VER" or "none". So if VER=${1#nvidia-glx-*} isn't either only made up of digits or "none" then I know that something went wrong. Furthermore I DKMS print strings which begin with "*" hence this shoul help a bit too: VER=${VER%\**}.
<slangasek> tseliot: no, because *that's not where you'll be seeing the error*
<cjwatson> dkms is sending those strings to debconf, not to you
<cjwatson> as I understand it
<mvo> Riddell: I'm just looking at a apturl kde issue and get "from PyKDE4.kdeui import *" -> "ImportError: No module named PyKDE4.kdeui" ? I assume this works fine for you? any idea what python package or lib is missing that makes it fail?
<slangasek> tseliot: nvidia-common will abort before you ever get around to calling nvidia-detector
<tseliot> cjwatson: I think we all agree on what "the solution" is :-)
<cjwatson> debconf is entitled to respond to out-of-spec input basically any way it pleases
<slangasek> tseliot: it will abort with the first db_set call
<tseliot> cjwatson: I give debconf the reply with this, no? db_subst nvidia-common/obsolete-driver latest $LATEST
<tseliot> well, it's not entirely correct
<cjwatson> tseliot: once debconf's input is out of step with its output, all bets are off
<slangasek> tseliot: your debconf input and output streams are already out of sync by that point because of the extra output dkms has helpfully inserted
<cjwatson> you'll be getting the return from some previous thing each time you call db_*
<tseliot> :-/
<cjwatson> at best
<lool> ENODOKO
<slangasek> tseliot: so I'm going ahead and rejecting this nvidia-common upload, since it doesn't actually fix the real problem
<tseliot> cjwatson, slangasek: ok, so you're basically saying that there may be nothing I can do about it
<slangasek> (in fact, users who are running custom kernels would still get the abort)
<cjwatson> tseliot: as the problem has been described to me, I don't think there is, no
<tseliot> if so, then ok, reject the upload
<cjwatson> BTW I think the reason this breaks is partly due to an infelicity in the way that the perl and shell confmodules differ
<tseliot> cjwatson, slangasek: some users reported that this works: http://launchpadlibrarian.net/27310838/dkms.patch
<cjwatson> I don't think they were ever designed to be nested in this way
<tseliot> oh
<slangasek> cjwatson: right, the perl client only redirects fds if the shell client is called first, heh
<cjwatson> tseliot: if updated to a current version, I think that ought to work
<mterry_> Keybuk, have you been getting bugs that look like a bunch of postinst failures with "Failed to connect to socket /com/ubuntu/upstart: Connection refused" messages?  I just got a couple for rsyslog, but I note from their apt logs that lots of packages were generating them.  I didn't see a likely master bug against upstart just now.
<slangasek> mterry_: in a chroot?
<cjwatson> though counterintuitively, sourcing the shell confmodule in /etc/kernel/postinst.d/dkms might also do it :-)
<mvo> mterry_: I see something similar in #451556
<cjwatson> but I haven't tested that, and it's possible it won't - the fd redirections are kind of twisty here
<mvo> my theory is that the telinit -u removal causes it
<mterry_> slangasek, dunno.  reporters didn't say
<mvo> but I need Keybuk to confirm
<slangasek> mterry_: there was a master bug about that, Keybuk closed it as invalid: bug #430224
<ubottu> Launchpad bug 430224 in upstart "misc: packages cannot be upgraded in a chroot" [Medium,Won't fix] https://launchpad.net/bugs/430224
<mvo> I'm pretty sure it happens on real systems too
<slangasek> ok
<mvo> (I get it in my auto-upgrade test VM and I'm sure it was not there some days ago)
<slangasek> cjwatson: yeah, sourcing the confmodule would do it.. :)
<mterry_> slangasek, interesting
<cjwatson> of course sourcing the confmodule, if it does anything, merely does 1>&2, so you might as well just do that directly
<tseliot> ah
<mterry_> mvo, so you're seeing it recently in a VM (not chroot) that used to work fine, is what you're saying?  I guess I'll ask the reporters if they were in a chroot
<tseliot> cjwatson, slangasek: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/292606/comments/18
<ubottu> Launchpad bug 292606 in nvidia-common "dkms - error when installing custom kernel" [Medium,New]
<mvo> mterry_: yes
<mvo> mterry_: used to work fine in kvm, now it does no longer
<tseliot> slangasek: oh, I didn't notice that you had added a comment to that report. Thanks
<slangasek> cjwatson: <cough> no, if you source the confmodule, it does ( 1>&3 ) 3>&1 ;)
<cjwatson> slangasek: surely 3>&1 1>&2
<tseliot> heh
<cjwatson> or am I missing something?
<slangasek> let's assume I am
<slangasek> and find more productive pursuits :-)
<bdrung> james_w: i want to talk about bug #446856 with you.
<ubottu> Launchpad bug 446856 in eclipse "eclipse*-gcj packages have unsatisfiable version dependencies in karmic" [Undecided,New] https://launchpad.net/bugs/446856
<cjwatson> yes, I had enough of debconf file descriptor mapping to last me a lifetime when implementing debconf-apt-progress and predecessors
<bdrung> james_w: do you agree that those outdated packages should be removed?
<slangasek> bdrung: all NBS (not built from source) binary packages are always removed before release
<slangasek> (I removed 4 of those packages yesterday, the others will also go as we have a chance to work through what will break when we do it)
<bdrung> slangasek: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/446856/comments/7
<ubottu> Launchpad bug 446856 in eclipse "eclipse*-gcj packages have unsatisfiable version dependencies in karmic" [Undecided,New]
<slangasek> bdrung: ah
<slangasek> bdrung: please add tasks to that bug for the source packages you want removed
<bdrung> slangasek: k, done
<pitti> Riddell: I'm confused by the arora upload; it has an inline patch to src/arora.desktop which changes translations, but then debian/patches/kubuntu_06_fix_desktop_translations.diff
<pitti> Riddell: which changes the same thing back again
<pitti> Riddell: ah, sorry, other way round: the patch is shippe,d but additionally applied inline
<pitti> won't that fail?
<pitti> apw: your linux meta upload> I don't think that this syntax actually works: Depends: foo [i386]; AFAIR, architecture specific stuff only works for build-depends
<pitti> apw: I could be wrong, of course, but was this tested?
<slangasek> pitti: it works when the package is architecture-dependent; dpkg-gencontrol parses it out
<slangasek> (I've just accepted that upload, fwiw)
<pitti> ah, great; that was the missing bit
<slangasek> (dpkg-gencontrol parses it out when it's Arch: all, too, that's just not what you want :-)
 * pitti closes the bug, it has a missing # in changelog
<pitti> slangasek: thanks, learned something again; but at this time I better ask twice
<apw> pitti, yeah i built it in PPA and it seemed to do what i wanted
<apw> slangasek, thanks for the explanation :)
<slangasek> n/p :)
 * slangasek glares at the seasons.  When I'm still up at 7am, I should be rewarded with *light*, dammit
<pitti> slangasek: here it snowed for the first time .. *shudder*
<bdrung> slangasek: thanks
<mvo> ArneGoetje: is bug #452065 caused by language packs not having apturl translations? does that need manual hinting?
<ubottu> Launchpad bug 452065 in apturl "Missing translations in the ui" [Undecided,New] https://launchpad.net/bugs/452065
<evand> it will never properly snow here :-/
<ArneGoetje> mvo: looking
<torkel> pitti: lucky you. We still haven't got any snow...
<ion> I wish it were summer already. :-(
<torkel> ion: we are still on summer time, so per definition it is summer? :-)
<ArneGoetje> mvo: we have one apturl template in Rosetta with 33 msgids... is this correct?
<kirkland> ttx: back from running now
<dpm> mvo, ArneGoetje, I've also noticed that. It seems that translations from the apturl.ui file are not extracted and merged into the POT template, if I'm not mistaken
<ArneGoetje> dpm: that was my guess
<dpm> python-distutils-extra bug?
<seb128> when will the karmic language pack be rolled?
<seb128> ie is it still worth doing changes on launchpad for karmic today?
<ArneGoetje> seb128: full-export from Rosetta tomorrow
<davmor2> mvo: right running again now
<ArneGoetje> seb128: today is translation deadline for non-language-pack translations. Langpack translation deadline is on 22nd.
<seb128> 22nd doesn't seem realistic
<seb128> that's the candidate image day
<seb128> and it takes a while to roll the language packs no?
<cjwatson> we've always landed the final langpacks post-RC
<ArneGoetje> seb128: these dates have been decided with the release team. :) The ones which get exported from rosetta tomorrow will go onto the RC images.
<cjwatson> even though in principle that's suboptimal
<cjwatson> but it's been that way since language packs were implemented ...
<Riddell> pitti: my fail on arora, I'll reject
<seb128> oh ok
<superm1> slangasek, tseliot my understanding is that nvidia-common is starting the debconf frontend, not the kernel postinst.  i see no references in a linux-image postinst to debconf.
<slangasek> superm1: incorrect
<pitti> Riddell: ok
<slangasek> superm1: if nvidia-common were starting it, dkms wouldn't have an fd to it and wouldn't be able to pollute it; this is a bug that only affects users who have custom kernel packages built with make-kpkg
<superm1> slangasek, so custom kernel's postinst are what's spawning debconf?
<slangasek> yes
<superm1> well that's just plain silly.  why don't custom kernels use the same postinst as regular ones
<slangasek> because the regular ones use a hand-hacked debian/ tree that can't be applied at will, people use make-kpkg instead when they want to generate custom kernel packages
<superm1> hm.  then that means that an artificial requirement needs to be added to stay away from certain fd's for anything in kernel postinst
<slangasek> just the one fd :)
<superm1> is there any way to to query if debconf *has* been loaded and polluted fds?
<slangasek> yes, you can check for $DEBIAN_HAS_FRONTEND; but see my comment in the bug, you shouldn't be making noise on stdout anyway
<superm1> well i'll be willing to check for that environment variable and only redirect in that situation, but I'd rather not change general behavior
<slangasek> the general behavior is inconsistent with the expectations of Ubuntu Policy, and not just in the case that debconf is running
<seb128> jdstrand, hi, could you look at bug #452057?
<ubottu> Launchpad bug 452057 in evince "Document Viewer won't print DVI files, but prints .pdf files with no trouble." [Undecided,New] https://launchpad.net/bugs/452057
<seb128> it's due to the apparmor profile, it's probably easy to fix but I'm still busy with other karmic things
<jdstrand> seb128: I'll fix it
<seb128> jdstrand, thanks!
<jdstrand> seb128: sure, np
<tordne> hi I had some problems with AppArmor, it doesn't want to load, i found out while installing mysql
<jdstrand> tordne: apparmor doesn't want to load?
<LaserJock> anybody know off-hand what a "normal" size for including a language on the CD is? ~10MB?
<tordne> yes, I tried to load it again /etc/init.d/apparmor start
<tordne> but it gives me the same answer
<tordne> loading failed
<jdstrand> tordne: can you paste the output somewhere?
<dholbach> Keybuk: I don't know much about vserver internals (vserver-linux.org), but I have upstart-vserver problems with the upgrade to karmic: reboot won't work anymore, start/stop/restart <service> won't work, etc.
<dholbach> "Failed to connect to socket /com/ubuntu/upstart: Connection refused"
<tordne> root@Cynara:/etc/init.d# ./apparmor start * Starting AppArmor                                                                                                                                                   * Loading AppArmor module...                                                                                                                                  [fail]
<tordne> it doesn't say much
<tordne> if looked in all the logfiles but i didn't find anything that talked about apparmor
<jdstrand> tordne: what kernel?
<jdstrand> tordne: cat /proc/version_signature
<tordne> 2.6.29-1-netbook
<tordne> i'm using eeebuntu
<jdstrand> tordne: is that a custom kernel?
<tordne> that's why the netbook
<ttx> kirkland: ok
<dholbach> Keybuk: some services already removed old style init scripts (rsyslog, cron, probably others too)
<jdstrand> tordne: it seems apparmor is not enabled in the kernel.
<kirkland> ttx: new iso's ready?
<jdstrand> tordne: you can try adding to the kernel command line 'security=apparmor', or apparmor.enabled=1. I don't remember when the kernel command line changed
<ttx> kirkland: the current ISO only contains the euca_rootwrap
<ttx> kirkland: the idea was to have a spin which just contains that fix, for regression testing
<jdstrand> tordne: you might check your /boot/config-2.6.29-1-netbook and make sure apparmor is built at all
<ttx> kirkland: but I uploaded a newer eucalyptus that you should test
<kirkland> ttx: okay
<ttx> kirkland: so don't hesitate to ask for a respin if you want to test it from installer
<ttx> kirkland: note that I only fixed the "wrong IP for cloud" issue, not really the "adding a linklocal address breaks things" part of it
<ttx> kirkland: since I don't really understand what gets broken
<kirkland> ttx: yeah, i don't totally understand it either
<kirkland> ttx: but i have a feeling that ip address is going to cause us months and months and months of hurt
<ttx> kirkland: but hey, I don't really understand the need for that address anyway :)
<ttx> kirkland: doing it link local is the right way to do it though, since it's a non-routable address
<mathiaz> kirkland: I thought about that
<ttx> kirkland: so basically it boils down to "why do you need that extra address for"
<mathiaz> the way to fix it is to add a virtual interface
<mathiaz> the same way as avahi does
<kirkland> mathiaz: yeah, that's what I was thinking
<kirkland> mathiaz: there should be a separate interface for this address
<mathiaz> IIRC you always have a eth0.avahi network interface
<kirkland> mathiaz: right
<kirkland> mathiaz: have you attempted this yet?
<mathiaz> kirkland: the same for the private network
<mathiaz> kirkland: nope - I got that idea overnight
<ttx> kirkland, mathiaz: in all cases that doesn't invalidate the fix I committed, the conffile should only look at scope global addresses anyway.
<mathiaz> kirkland: upstream does an ip add addr or something
<mathiaz> ttx: right
<tordne> jdstrand : I look in the boot file and didn't find anything about apparmor
<mathiaz> ttx: but you may run into issue if you have multiple global addresses
<mathiaz> ttx: which is what I've noticed on one of my cluster
<ttx> mathiaz: you don't really run into issues. You just pick the first one arbitrarily
<mathiaz> ttx: I wasn't using public IP - only private addressing
<jdstrand> tordne: you'll need to file a bug with eeebuntu then
<Riddell> mvo: sorry missed your message about apturl, pykde is currently broken, I'm looking into it
<jdstrand> tordne: or run a custom kernel
<tordne> jdstrand : how can i add security=apparmor', or apparmor.enabled=1. to the kernel command line
<kirkland> mathiaz: ack, i saw multiple global addresses too
<apw> pitti, we seem to have a bug in suspend/resume handling (one which i think has been around for a while) if you suspend with AC in and remove AC and resume we always suspend one more time ... i've checked that when it occurs pm-utils is called 2x so it and the kernel are in the clear ... whats the next layer devicekit-power ?
<ttx> kirkland: for euca_rootwrap and the changes I uploaded, my basic testing works. Didn't install it from ISO though (since there is no ISO yet)
<pitti> apw: I think I have a fix for that in unapproved
<kirkland> ttx: mathiaz: i was going to rework that hack to pick the address that's in the same subnet as y our default route
<jdstrand> tordne: if you don't have these lines in your /boot/config... file, then it doesn't matter:
<pitti> apw: are you on amd64?
<jdstrand> CONFIG_SECURITY_APPARMOR=y
<jdstrand> CONFIG_SECURITY_APPARMOR_NETWORK=y
<jdstrand> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
<kirkland> ttx: mathiaz: that requires some ip math, though
<apw> pitti, i am seeing it on i386
<pitti> apw: I meant, I have amd64 .debs here, ready to try
<jdstrand> tordne: the last one could be '0'
<mathiaz> kirkland: well - if upstream would use virtual interface it would be easier
<apw> pitti, ahh ... right
<kirkland> ttx: good to hear that euca_rootwrap didn't break our back
<pitti> apw: I was debugging that yesterday, and used those for verifying
<mathiaz> kirkland: one eth0.avahi for 169.X
<kirkland> mathiaz: absolutely, agree
<pitti> apw: otherwise I can just push it to my PPA
<ttx> kirkland: maybe it's late to change that logic more. I think its acceptable to ask the user to edit that /etc file anyway
<kirkland> mathiaz: this needs to be fixed at the address configuration level
<mathiaz> kirkland: and one eth0.eucapriv for the private address
<kirkland> mathiaz: grepping and awking it is purely a hack
<apw> pitti, if me testing would help then do ... else i can just wait :)
<pitti> apw: pushed to desktop PPA now, I'll ping you when they were built
<ttx> kirkland: if they use a complex network config, they should
<pitti> apw: I tested it under slightly different conditions, but it sounds related
<kirkland> ttx: acceptable, yes; not ideal, IMHO
<pitti> apw: testing would be heavily appreciated, yes
<apw> can do ...
<pitti> apw: bug 425411 FYI
<ubottu> Launchpad bug 425411 in devicekit-power "Computer suspends immediately after resuming if power is unplugged while suspended" [Medium,Fix committed] https://launchpad.net/bugs/425411
<ttx> kirkland: well, if that's the only issue left, why not :) I fixed it so that I could actually use my setup. That 169. address showing up as CLOUP_IP was breaking everything here :)
<pitti> apw: I tested the inverse, though
<apw> i didn't find the inverse affected it ... only the one reported in that bug :)
<ttx> kirkland: now we get some time to design an alternative proposal :)
<pitti> seb128: nice, no "High" any more on https://edge.launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=12698
<pitti> dpm: do you still get bug 408474 ? It works just fine everywhere else
<ubottu> Launchpad bug 408474 in gdm "Language variants information missing in the language selection list" [Low,New] https://launchpad.net/bugs/408474
<seb128> pitti, ;-)
<seb128> pitti, I can add some new ones if you want though ... ;-)
<pitti> seb128: I think we should raise bug 451613
<ubottu> Launchpad bug 451613 in gvfs "all disks and partitions are automounted in the live session" [High,Triaged] https://launchpad.net/bugs/451613
<pitti> apw: PPA built, I updated the bug; testing appreciated!
<apw> pitti, i installed devicekit-power_01-1ubuntu1 and libdevkit-power-gobject1_011-1ubuntu1 ... still seems to occur
<seb128> pitti, is that a new issue? weird that nobody noticed until now
<pitti> seb128: doesn't happen in kvm for me
<pitti> apw: hm; I need better debugging then, hang on
<dpm> pitti, I could still reproduce it last week when I last tried it, let me check again...
<apw> pitti, no problem ...
<pitti> dpm: variants in the keyboard selector should have worked for months..
<seb128> pitti, btw could you review the pending gvfs and rhythmbox changes from robert_ancell when you have some slot?
<seb128> pitti, I guess they are after karmic material now but want confirmation
<seb128> pitti, they are in bzr waiting for upload
<pitti> apw: https://bugs.edge.launchpad.net/devicekit-power/+bug/425411/comments/13
<ubottu> Launchpad bug 425411 in devicekit-power "Computer suspends immediately after resuming if power is unplugged while suspended" [Medium,Fix committed]
<davmor2> mvo: crash and burn again I'm afraid
<dpm> pitti, the bug is not about them not working (actually selecting any language didn't seem to work from gdm either, but that's a separate issue). It's about them being displayed in the list as exactly the same as the non-variant options, with the result that you don't actually know what you are selecting (see screenshot in the bug)
<pitti> dpm: oh, it's the language selector, not the keyboard one, sorry
<dpm> np :)
<bddebian> Heya gang
<bddebian> whoops ECHAN
<LaserJock> bddebian: and hello to you too
<apw> pitti, i cannot get gnome-power-manager to emit anything in --debug mode
<pitti> apw: ah, that's because I suck and meant to say "--verbose"; sorry
<mvo_> ArneGoetje: I disconnected, sorry. is there anything that need to be done to add apturl to the langpacks (if it is not already)
<bddebian> Heh heya LaserJock
<tordne> jdstrand: I was reading the apparmor docs and found this
<tordne> jdstrand:                                                                 AppArmor
<tordne> cannot be used together with other Linux Security Modules, so if CONFIG
<tordne> SECURITY CAPABILITIES or CONFIG SECURITY SELINUX
<tordne> is set to y or m
<mvo_> dpm: https://bugs.edge.launchpad.net/ubuntu/+source/apturl/+bug/452065 is a open bug about it, but when I build it with the rosetta translations locally its all there
<ubottu> Launchpad bug 452065 in ubuntu-translations "Missing translations in the ui" [Critical,Confirmed]
<jdstrand> tordne: they can both be compiled into the kernel, only one can be loaded at a time
<tordne> jdstrand : and i got CONFIG_SECURITY_SELINUX=y
<pitti> seb128: ugh, quite intrusive
<ArneGoetje> mvo_: can you check if the apturl.ui strings get added to the .pot file? The template in Rosetta has 33 msgids. Is that correct?
<seb128> pitti, ok, what I though and that's why I didn't upload
<tordne> jdstarnd: but how can i change this?
<jdstrand> tordne: you don't want to change it
<seb128> pitti, btw please don't use triaged for bugs not upstreamed yet
<pitti> seb128: oh? I usually use this for "bug is understood/reproducible  and can be looked at by dev"
<seb128> pitti, we use it as "is sent upstream" for GNOME bugs
<pitti> hmkay
<mvo_> ArneGoetje: that sounds about right
<tordne> jdstrand : i just got a problem with mysql, it doesn't want to start unless apparmor is loaded
<jdstrand> tordne: eg, the Ubuntu kernel has: http://paste.ubuntu.com/294042/
<jdstrand> tordne: you'll need to adjust your kernel config to have apparmor support
<dpm> mvo, mvo_, ArneGoetje, I built the package locally with pkgstriptranslations from pkgbinarymangler enabled, and the apturl.ui translations are not extracted and merged into the POT file
<simon-o> Hi, I fixed a FTBFS for a package in universe. What do I do next? Just subscribe the sponsors as usual or the release team?
<jdstrand> tordne: as for mysql requiring apparmor-- that doesn't sound right. I would file a bug on mysql giving as much detail as possible
<jdstrand> tordne: mysql doesn't depend on apparmor afaik
<\sh> jdstrand, I would complain if it does ;)
<jdstrand> tordne: it supplies a profile, but if apparmor isn't available it shouldn't matter
<sebner> Simira: still the sponsors
<sebner> argh
<sebner> simon-o:  still the sponsors
<mvo_> dpm: its still using apturl.glade for some reason afaics
<jdstrand> \sh: heh
<simon-o> sebner: ok, thanks
<mvo_> dpm: oh, you mean the kde .ui file?
<apw> pitti, debug is attached to the bug
<mvo_> dpm: sorry, I confused that with the gtk gtkbuilder .ui file
<dpm> mvo_ no, you were right, I meant the gtkbuilder file, I thought apturl was already using gtkbuilder
<tordne> jdstrand: apparnor is automatically installed, and when i wanted to install msql it gave the message that apparmor wasn't loaded.
<mvo_> dpm: its the kdebuilder .ui file, I got confused by this as well
<\sh> btw...is anyone working on a working jboss integration in ubuntu? if so, how can I help :)
<jdstrand> tordne: please file a bug
<dpm> mvo_, for the kde part, it might be bug 427358, for the glade part, I'm not sure
<ubottu> Launchpad bug 427358 in python-distutils-extra "extracting strings from KDE *.ui files to the POT doesn't work, and needs intltool support" [Undecided,New] https://launchpad.net/bugs/427358
<mvo_> dpm: right
<dpm> mvo_, the glade file translations (there are only two of them) seem to be extracted ok and put into the POT template
<tordne> ok i will
<tordne> jdstrand: ok i will file a bug report
<mvo_> dpm: is apturl part of the langpacks? I wonder why its not showing up translated?
<dpm> let me check...
<dpm> mvo_, it seems to be, in my system -> /usr/share/locale-langpack/ca/LC_MESSAGES/apturl.mo
<ArneGoetje> mvo_: according to rosetta, the translations will be exported into langpacks.
<mvo_> dpm: thanks, odd. I look a bit more to figure out what is going wrong then
<mvo_> thanks ArneGoetje too
<dpm> mvo_, actually... can you reproduce the bug in your system? I can't. Apturl appears translated in Catalan, at least
<jdstrand> tordne: thanks!
<mvo_> dpm: I have a local build (without striptranslations) now, let me downgrade
<mvo_> dpm: I see it here, the problem is apparently that the mo file is in language-pack-kde-de-base:
<mvo_> dpm: but it should be in a base language pack or something
<dpm> mvo_, oh I see... yes, that's why I can't reproduce it, I've got the kde langpack also installed
<mvo_> yeah
<dpm> ArneGoetje, ^ should that be filed against langpack-o-matic?
<ArneGoetje> dpm: I think so
<mvo_> ArneGoetje: I added a bugtask to #452065
<lool> Keybuk: poke
<lool> Keybuk: Do you have any issue with adding this check during boot http://bazaar.launchpad.net/~bratsche/gdm/xsplash-check-cmdline/revision/146 ?
<Keybuk> makes sense to me
<Keybuk> though why would you want to disable xsplash?
<Keybuk> you disable usplash because you want to see things going on under it
<Keybuk> all that goes on under xsplash is the pinwheel
<lool> Keybuk: Just in case something goes wrong or you simply don't want it
<ion> That would match anything with a âsplashâ substring.
<lool> Keybuk: we had the case where it broke and we had no facility to document a workaround, and some people don't like it
<lool> ion: I suggested adding -w
<Keybuk> though strictly speaking, that grep is wrong
<Keybuk> since that will match root=/dev/mapper/ubuntu-splash-top
<Keybuk> -w won't help, since - is a word boundary
<lool> Hmm true, I think gdm was using that though
<Keybuk> the gdm upstart job reads /proc/cmdline using for
<Keybuk> random thought
<Keybuk> if you check for splash in that list and set an ENVVAR, does that end up in the gdm session scripts
<Keybuk> ie. could you modify /etc/init/gdm.conf, set SPLASH=true at the top
<lool> we dont need to send an envvar I guess
<Keybuk> then when it reads the command-line, set SPLASH=false
<Keybuk> (or however that should work)
<Keybuk> then just check that var in the scripts
<Keybuk> that'd save you a lot of processor time of re-reading /proc/cmdline a dozen times
<lool> just for ... splash) start xsplash;
<Keybuk> (well, not that it's much, but each one adds up)
<ArneGoetje> mvo_, dpm: fixed in langpack-o-matic, should go into the main langpack now, not kde anymore.
<dpm> ArneGoetje, cool, thanks
<mvo_> ArneGoetje: great, thanks
<ccheney> bug 451772  seems to claim openoffice.org-l10n-fr isn't being installed even though they have the rest of the localizations, is that supposed to be happening?
<ubottu> Launchpad bug 451772 in openoffice.org "no french menu into the oocalc application" [Undecided,Incomplete] https://launchpad.net/bugs/451772
<ccheney> and which package should that bug be reassigned to?
<ccheney> or is it some sort of strange user error?
<LaserJock> cjwatson: for some reason Ubiquity is not being removed from Edubuntu livefs installs, am I not supposed to have ubiquity packages in the dvd-live seed?
<ccheney> pitti: ping
<pitti> ccheney: hi
<ccheney> pitti: any ideas about the above? i saw you have been working on fixing OOo getting pulled in by mistake and didn't know if it was related
<pitti> ccheney: I think that should now get pulled in by the language-selector
<pitti> ccheney: we don't have explicit l-support packages for that any more, I think
<pitti> ccheney: ArneGoetje knows the details
<ccheney> ok
<ccheney> i'll ask the user if they used language-selector
<ccheney> looks like that user is also missing the gnome/kde stuff assuming they are running one of those two
<cjwatson> LaserJock: the manifests look right, so I'll need to see logs
<LaserJock> cjwatson: is that /var/log/installer/syslog?
<cjwatson> yes
<didrocks> jdstrand: hi, I thought you merged my ufw branch a while ago, why rejecting it now?
<jdstrand> didrocks: hi!
<LaserJock> cjwatson: http://pastebin.com/f44d0c38d
<cjwatson> LaserJock: anything in /var/log/installer/debug? (Perhaps we could do this in a bug report instead?)
<jdstrand> didrocks: I was just doing some housekeeping. I rewrote your patch and included it in 0.24 (with a 'Based on work by Didier Roche' in the changelog)
<jdstrand> didrocks: since I didn't explicitly take the merge as it was written, I used Rejected
<didrocks> jdstrand: ok, it was just for an explanation :)
<LaserJock> cjwatson: http://pastebin.com/f2c4467c7 and yeah, if you would like me to file a bug I can, is there an easy way to do it that will get you the logs via apport?
<cjwatson> 'ubuntu-bug ubiquity'
<cjwatson> your logs so far don't seem to explain it at all though
<cjwatson> it's not removing any packages, but it doesn't say why
<slangasek> ScottK: fwiw, I'm just about done with libkrb53 now; there are still some revdeps that are going to be uninstallable, but one of them is root-system, which I gave up trying to fix
<slangasek> (s/one of them is/most of them are/)
<LaserJock> cjwatson: is ubuntu-bug meant to be run with sudo? I get some long traceback that says that it doesn't have permission to the .crash
<cjwatson> no
<cjwatson> that's a bug somewhere else; ISTR update-notifier?
<cjwatson> something was shipping /var/crash with bogus perm
<cjwatson> s
<mvo_> LaserJock: the update of update-notifier from some minutes ago should fix that
<kees> mvo_: hi! did you see the apt cron bug from yesterday?
<mvo_> kees: bug #449535 ?
<ubottu> Launchpad bug 449535 in apt "/etc/cron.daily/apt doesn't run apt-get update anymore" [Critical,Fix committed] https://launchpad.net/bugs/449535
<kees> mvo_: I committed a fix for bug 449535 to the apt bzr tree, but since there were other things pending, I didn't upload it.
<ion> keybuk: So, any hope of getting better sreadahead performance with laptop HDDs, or will readahead be put back?
<kees> mvo_: yeah
<Keybuk> ion: I'm still working on that
<Keybuk> ion: it's a non-trivial problem ;)
<mvo_> kees: I upload in a bit, thanks a lot for the commit
<ion> I wonder if i could do anything...
<mvo_> kees: there is a karmic branch for apt already that I will port to and upload from
<kees> mvo_: oh! ok, sorry, I went from the Vcs in the karmic source package.
<mvo_> kees: my mistake, thanks again
<mvo_> kees: the vcs-bzr header fix is commited but not uploaded (ironically)
<kees> hehe
<Amaranth> ion: a clean install will fix it ;)
<ion> amaranth: Why is that?
<Amaranth> ion: afaik the main problem is that sreadahead ignores the location on disk and just loads the files in the order they are used in the boot
<Amaranth> so you seek like mad
<ion> Ah
<PovAddict> package 'lcov' includes a 'genpng' tool that when run, says "ERROR: required module GD.pm not found on this system (see www.cpan.org)."
<PovAddict> shouldn't libgd-gd2-perl be in the "recommends" line at least?
<PovAddict> er, nvm... I'm filing a bug *right now*... lcov doesn't depend on/recommend/suggest *anything*!
<LaserJock> cjwatson/mvo: I just can't get ubuntu-bug to work to save my life. I fully dist-upgraded. what logs should I attach? everything in /var/log/installer/?
<andersk> Keybuk: Can you take a look at bug 452196?
<ubottu> Launchpad bug 452196 in mountall "mountall tries to resume boot when it shouldn't" [Undecided,Confirmed] https://launchpad.net/bugs/452196
<Keybuk> andersk: it was only reported 3 hours ago
<Keybuk> I'm not that far through my bugs folder yet
<PovAddict> heh
<andersk> Fair enough.  I think this oneâs important, though, since it can exacerbate filesystem corruption.
<Keybuk> everyone thinks that bugs they care about are important
<Keybuk> that's how it works :p
<andersk> Yeah, yeah.  Iâll let you get back to work.  :-)
<jdstrand> cjwatson: hi! so, I just rebooted and got the '... has been mounted... check forced.' message (fine). I have a large disk, and it is spinning away, but other than the check forced message, I have no visual cue as to what is happening
<jdstrand> cjwatson: I come to you cause I know you have worked on the boot quieting stuff
<jdstrand> cjwatson: I assume it is still fscking, but even I am beginning to wonder at this point. I'd imagine a user might be inclined to power off the machine
<jdstrand> cjwatson: is this a known bug?
<jdstrand> s/a user/another user/
<jdstrand> cjwatson: should I bother someone else? :)
<jdstrand> \o/ it's done
<sroecker> pitti, hi, can jockey handle debconf guis? I wrote a handler that installs isight-firmware-tools but it doesnt show the debconf menu
<superm1> pitti, sroecker perhaps switching jockey to using aptdaemon would solve that type of problem
<superm1> too bad it's too late for that kind of thing
<sroecker> superm1, so it just can't handle debconf stuff?
<superm1> sroecker, not currently, it can't handle any interactive debconf right now
<sroecker> superm1, thanks, I thought I didn't use the right command/handler
<jdstrand> slangasek: hi! is subscribing ubuntu-release to a milestoned bug with a debdiff attached enough to get your attention? I realize I am contacting you on irc now, but in the future, is this enough
<jdstrand> ?
<pipegeek> is the version of empathy im in karmic going to support im formatting?
<cjwatson> LaserJock: yes, that should do
<sladen> Keybuk: is usplash (since today) supposed to prevent you from using Alt-F1 (this isn't any worse than it was a week ago, but...)
<cjwatson> jdstrand: that's bug 446596
<ubottu> Launchpad bug 446596 in mountall "fsck does not show progress during boot" [High,In progress] https://launchpad.net/bugs/446596
<Keybuk> sladen: no, what happens when you do?
<sladen> Keybuk: nothing
<Kage_Jittai> hello, I am with the project called "The mana world" our project is in the ubuntu repos
<sladen> Keybuk: the same (static) usplash screen displays for ~30seconds, then ~30seconds of blank, then ~15 seconds of xsplash, then gdm
<Kage_Jittai> the ubuntu repos are very outdated some as many as 4 versions old
<Kage_Jittai> We have requested backports
<sladen> Keybuk: I think the throbbingness is quite important for the whole haven't-crashed-yet reassurance, as it responding to keypresses when they're hit
<ion> I âonlyâ have 15â20 seconds of blank screen between usplash and xsplash. :-P
<Kage_Jittai> but they have gone unanswered
<ion> sladen: They are working on the gdm slowness, i hear.
<Kage_Jittai> we are now considering dropping support for versions in the repo
<sladen> ion: yeah, boot went from <1:30 seconds in jaunty to ~2:30 in karmic
<Kage_Jittai> and only maintaining one active version
<Kage_Jittai> this will break the projects in the repo
<sladen> ion: but the GDM slowness doesn't really matter if the user is reassuring entertained by livid pulsations in the meantime
<ion> sladen: Yeah, it would be nice if X could just start while usplash is still running and usplash would handle that properly. Dunnno whether itâs feasible.
<sladen> ion: we had ideas about this in a conference room in Oxford ~5 years ago.  I'm sure it'll happen one day ;-)
<cjwatson> it is, we're working on it
<pitti> sroecker: right, it doesn't right now
<pitti> sroecker: you'd need to write a handler which pokes the answers into debconf db first
<PovAddict> I'd like async logout... so my mom can logout, and I can get back to my locked session while her apps and X are still in the process of shutting down
<jono> slangasek, can you reply to Joe Casad email re. interview, he needs to know fairly soon
<robbiew> jono: slangasek worked UK hours today...FYI
<jono> robbiew, ahhh cool
<mvo_> mathiaz: could you add a example config file to bug #450837 so that I can test against that?
<ubottu> Launchpad bug 450837 in update-manager "If mysql is configured to use the ndb engine a karmic upgrade should keep mysql-dfsg-5.0 and remove the mysql-server package" [Medium,Triaged] https://launchpad.net/bugs/450837
<mathiaz> mvo_: sure - let me dig one
<mvo_> thanks mathiaz!
<mvo_> mathiaz: is it ok if the mysql-client stuff for 5.1 is installed (i assume it is) when the 5.1 server is not ?
<mathiaz> mvo_: yes
<mathiaz> mvo_: but mysql-server 5.0 requires mysql-client 5.0
<mathiaz> mvo_: so I guess you'd also wanna remove mysql-client
<mathiaz> mvo_: in addition to mysql-server
<ccheney> lamont: your city is on the news :)
<mathiaz> mvo_: I'll update the bug description
<mvo_> mathiaz: ok, thank
<mvo_> s
<mathiaz> mvo_: bug updated
<mathiaz> mvo_: the second configuration file has been mangled (text wrapped)
<mathiaz> mvo_: I've added a link to the location where I've got the examples configuration
<mathiaz> mvo_: let me know if you have any more questions
<ion> Woot http://www.ouaza.com/wp/2009/10/08/3-way-merge-of-debian-changelog-files/
<Keybuk> wow
<Keybuk> X doesn't like "modprobe nouveau" much
<bryce_> get any fun colors?
<Keybuk> no, just a crash
<bryce_> aw
<Keybuk> (X was running with the ordinary nv driver :p)
<jdong> aww disappointing
<ion> Does nouveau use KMS? Iâd almost expect something to go wrong with a driver initializing the framebuffer for KMS while some random stupid userspace program is poking the hardware directly. :-P
<Keybuk> nouveau is KMS yes
<Keybuk> that's interesting
<Keybuk> usplash sometimes fails to start with the bogl backend too
<akgraner> rickspencer3, I upgraded to Karmic on the machine I use everyday..  It is my understanding that the old notifier (the one with the orange burst and the red arrow) won't work anymore is that true?
<rickspencer3> akgraner, can you switch to #ubuntu-desktop?
<akgraner> yeppers
<akgraner> :-)
#ubuntu-devel 2009-10-16
<directhex> anyone else have broken colorspace issues on video files using nvidia on karmic?
<chrisccoulson> how broken? i know there is an issue with totem and nvidia users having to adjust the hue when they first run it
<TheMuso> directhex: I used to have weird colour issues when viewing flv/youtube videos in mplayer/totem/xine earlier in the cycle, although after a fresh install, that went away.
<directhex> chrisccoulson, adjust it where? the weird thing is it's fine for the duration of having nvidia-settings running
<chrisccoulson> directhex - that's wierd. i had to adjust the hue slider to the center in totem preferences when i did a fresh install
<directhex> hm, not anymore. worked last week
<directhex> wow, wait, what? chrisccoulson, well spotted! why is that randomly so low?
<chrisccoulson> directhex - that's likely the same issue as bug 395476
<ubottu> Launchpad bug 395476 in nvidia-graphics-drivers-180 "nvidia sets HUE to -1000" [Undecided,Confirmed] https://launchpad.net/bugs/395476
<directhex> low priority?
<chrisccoulson> heh, i'm not sure who set that
<directhex> YokoZar i guess
<LaserJock> dailies up in ~ 1 hr?
<kees> Keybuk: bug 452503 -- both "file" and older "blkid" worked correctly.
<ubottu> Launchpad bug 452503 in util-linux "blkid fails to recognize swap partition / file" [Undecided,Confirmed] https://launchpad.net/bugs/452503
<Keybuk> kees: did older vol_id work correctly?
<Keybuk> actually, the argument is that file is working *in*correctly
<kees> or blkid should say "LUKS" but it doesn't
<Keybuk> blkid should say neither
<Keybuk> it has BOTH metadata
<kees> the main point is that it _is_ a valid swap partition.  the kernel can use it, etc
<Keybuk> it could be either, you can't pick one without risking corrupting the other
<Keybuk> yes, but blkid doesn't know it's *not* a valid LUKS partition
<Keybuk> that's the point
<kees> ok, that's reasonable.
<kees> it'd be nice to have a --verbose :)
<Keybuk> if blkid tells you it's swap, and you really meant LUKS, you just trashed your LUKS
<Keybuk> if blkid tells you it's LUKS, and you really meant swap, you just trashed your swap
<Keybuk> now
<Keybuk> replace LUKS and swap in those with
<Keybuk> say
<Keybuk> ext4 and vfat
 * kees nods
<Keybuk> (which are the other common pairs)
<Keybuk> that's why this is a Won't Fix
<kees> almost seems like a bug in mkswap then...
<Keybuk> indeed, I'm surprised mkswap didn't wipe
<Keybuk> that is certainly a bug
<Keybuk> especially given ff3bed806863d1c2075d0efda70b39ea6af9ecba
<Keybuk> which is the code in mkswap to explicitly wipe things out
 * kees changes the bug title's name
<kees> er, bug's title
<AdamSchackart> quick question, what VCS are you guys using?
<LaserJock> AdamSchackart: all kinds but mostly bzr is what you'll find in Ubuntu
<Keybuk> AdamSchackart: bzr and git
<AdamSchackart> cool
<mathiaz> Keybuk: hey - upstart job question
<mathiaz> Keybuk: http://people.canonical.com/~mathiaz/eucalyptus.conf
<mathiaz> Keybuk: ^^ will the opts variable be passed to the exec?
<Keybuk> mathiaz: no.
<mathiaz> Keybuk: ah!
<mathiaz> Keybuk: how should this be done?
<ion> script
<Keybuk> mdz has some weird things elsewhere to output that stuff to a file, then source the file in the exec line
<ion>   opts=foo
<ion>   exec $opts
<ion> end script
<Keybuk> alternatively just put the whole lot of pre-start and exec into one script
<Keybuk> as ion just demo'd :p
<mathiaz> Keybuk: great - thanks
<mathiaz> ion: thanks as well
<Keybuk> holy crap, I just read the moblin sreadahead pack
<Keybuk> and really wish I hadn't
<Keybuk> this thing really is SSD optimised ;)
<Keybuk> find / | make-pack
<ion> Hehe
<Keybuk> oh, I see
<Keybuk> then that mincore()s it
<Keybuk> so it's not quite as crazy
<ion> Ah
<slangasek> Keybuk: so if you call 'stop' in a script instead of a pre-start script, does it still work?
<slangasek> (i.e., the only thing you don't want to do in a script is fork another process that's not the one to be supervised?)
<mathiaz> Keybuk: exec . /var/run/eucalyptus/eucalyptus.options && eucalyptus-cloud $opts
<mathiaz> Keybuk: would something like this ^^ work?
<mathiaz> Keybuk: (provided that the opts are dumped correctly in /var/run/eucalyptus/eucalyptus.options in the pre-start part of the job)
<chrisccoulson> is kees likely to be about this evening?
<kees> chrisccoulson: he is! :)
<slangasek> mathiaz: a) should be in a script instead; b) really would be better to not need the tmp file
<mathiaz> slangasek: ok
<chrisccoulson> kees - i'm confused - i don't see you on the list of users ;)
<slangasek> mathiaz: I think the current script has a bug anyway, because calling "exit 0" from pre-start doesn't stop the job from running, which I think is what the goal was there?
<mathiaz> slangasek: should I exec in the script?
<chrisccoulson> must be empathy playing up!
<slangasek> mathiaz: yes
<chrisccoulson> kees - i have a patch for the screensaver issue. not sure if you want to take a quick look at it (or test it)?
<chrisccoulson> it seems to be working ok here
<kees> chrisccoulson: sure!
<chrisccoulson> kees - the patch is here: http://pastebin.com/m239703a2
<slangasek> mathiaz: do you want the job to fail, or just not stop, if eucalyptus is not configured yet?
<mathiaz> slangasek: hm - what does "just not stop" mean?
<slangasek> mathiaz: it means "just not start" :-)
<slangasek> mathiaz: modulo the answer to the above question, I think what you really want is this: http://people.canonical.com/~vorlon/eucalyptus.conf
<mathiaz> slangasek: exit 1 will make the job fail?
<slangasek> mathiaz: if you want the job to stop instead of failing, you can replace 'exit 1' with 'stop'; and then you can also mark the job as 'respawn'...
<slangasek> mathiaz: yes
<mathiaz> slangasek: exit 0 will make the job not start ?
<slangasek> no
<kees> chrisccoulson: nice!
<slangasek> mathiaz: exit 0 called from the pre-start script just says "the script is done, exited successfully" and the job will still start
<kees> chrisccoulson: can you attach that to the bug, and I can get it built and get a freeze exception.
<mathiaz> slangasek: what does script+respawn do then?
<mathiaz> slangasek: it reruns the script until it's successfull?
<slangasek> mathiaz: 'exec foo' is shorthand for 'script exec foo end script'
<slangasek> mathiaz: for a normal job, the definition of "successful" is "running"
<slangasek> mathiaz: "respawn" says "if the job dies for any reason, respawn it"
<chrisccoulson> kees - yeah, no worries. i can push it to ubuntu-desktop bzr if you're happy with the change
<mathiaz> slangasek: ok
<slangasek> mathiaz: updated the script a little, to use the Keybuk-approved 'stop' runes
<kees> chrisccoulson: if it works, yeah!  :)
<mathiaz> slangasek: { stop; exit 0; }
<mathiaz> slangasek: ^^ that will mark the job as stopped
<slangasek> mathiaz: yes
<mathiaz> slangasek: if euca_conf is not there
<mathiaz> slangasek: however exit 1 will make the job fail if it's not configured
<slangasek> mathiaz: right - hence, asking what you want the behavior to be :)
<mathiaz> slangasek: ok - just making sure I understand the semantics :)
<mathiaz> slangasek: hmmm... so what's the difference between a failed job and a stopped job?
<mathiaz> slangasek: the default configuration after package installation should be a working one
<slangasek> mathiaz: whether or not 'respawn' will try to start it again :)
<slangasek> (and what gets logged, etc)
<slangasek> I would expect eucalyptus-cloud to be a normal service, where you want init to be the process supervisor and respawn it if needed
<mathiaz> slangasek: yes
<slangasek> so I think you want to change that 'exit 1' to a 'stop; exit 0' and then add 'respawn'
<mathiaz> slangasek: even if there isn't any respawn option?
<mathiaz> slangasek: ok
<slangasek> mathiaz: updated again, have a look there
<mathiaz> slangasek: what would 'exit 1' + no respawn option do?
<mathiaz> slangasek: in the case of a non-configured system
<slangasek> mathiaz: result in the job being marked failed, with upstart not trying to restart it
<slangasek> but, if you want upstart to *ever* restart your job for you when it dies, you need 'respawn', and then you want to write your job to avoid upstart getting into a busy loop
<mathiaz> slangasek: busy loop meaning that the job would always fail and upstart would always restart it?
<ion> Upstart will stop trying if itâs respawning too fast for a while.
<Keybuk> the difference between exit 1 and { stop ; exit 0; } is, basically, in the return code ;)
<Keybuk> a job that just does exit 1 is marked failed
<Keybuk> the event tells everybody that you failed
<Keybuk> and that it was your pre-start that failed
<Keybuk> the user who runs "start" gets told it failed, and gets a "1" return code
<Keybuk> etc.
<Keybuk> { stop; exit 0; } means you're not marked failed
<Keybuk> you just stopped again
<Keybuk> the event says you stopped normally
<chrisccoulson> kees - i've pushed the change to bzr now. do you want me to subscribe u-m-s or will you handle this?
<kees> chrisccoulson: I can handle that, thanks!
<Keybuk> the user gets told (basically) that the job they wanted started, stopped again
<Keybuk> etc.
<chrisccoulson> kees - thank you too:)
<Keybuk> probably the biggest difference is that you don't get a console message ;)
<mathiaz> Keybuk: so for the use case of: 'service not configured' what is the option to tell the user to first configuring the service before retrying to start?
<Keybuk> mathiaz: there's no method to do that right now
<mathiaz> Keybuk: failed job or start/stopped job?
<mathiaz> Keybuk: which are the existing options for now
<Keybuk> as slangasek says, we've settled on stop
<mathiaz> Keybuk: ok
<Keybuk> in the next version of Upstart, you won't need that at all
<slangasek> mathiaz: are you assuming that the output of the pre-start script will be passed to the user calling 'start'?
<Keybuk> you can just ship your package in manual mode
<Keybuk> (then it won't be automatically started - but will be started if the sysadmin starts it by hand)
<ion> Keybuk is planning to implement output logging for jobs. With it, it would be easy to print what the script said when e.g. the start command fails.
<mathiaz> slangasek: hm not really.
<slangasek> mathiaz: ok good ;)
<mathiaz> slangasek: I'm just asking questions about how upstart works :D
<Keybuk> mathiaz: the problem is I tend to answer such questions with the question "how do you think it should work?"
<Keybuk> ion: yes, but Keybuk is also planning to implement manual mode - which will do away with the need to say "aha! you didn't enable it"
<mathiaz> Keybuk: ah ok. Than I'd like to be able to tell the user to configure the service by editing this file before attempting to restart the job
<Keybuk> mathiaz: you can't do that
<LaserJock> so ... how bad is it to do a Pre-Depends if you can't see a reasonable way without it?
<mathiaz> Keybuk: right - I understand that. I'll use the stop+exit0 for now
<Keybuk> personally I strongly dislike that kind of message anyway
<Keybuk> "start foo" ... "but you didn't enable foo"
<Keybuk> "yes, but I just told you to start it, stop being stupid and do what I told you"
<slangasek> Keybuk: the use case here isn't /enabling/ foo, it's /configuring/ foo
<Keybuk> slangasek: well, that's different ;)
<mathiaz> Keybuk: so you don't consider that upstart could help the sysadmin in diagnosing wrong configuration?
<slangasek> yes, it is
<slangasek> :)
<mathiaz> Keybuk: a similar use case is to check for incompatible options
<Keybuk> in that case, you probably *do* want to exit 1
 * Keybuk misunderstood, sorry
<mathiaz> Keybuk: right - that's a good use of failed job
<mathiaz> Keybuk: IIUC there isn't for now good logging?
<slangasek> Keybuk: "respawn" only affects the main script, not pre-start, yes?
<Keybuk> slangasek: we don't respawn pre-start scripts ;)
 * slangasek nods
<mathiaz> Keybuk: like being able to say: your job has failed because foo option is incompitble with bar
<Keybuk> but a pre-start script failed stops the job in a way that won't be respawned
<slangasek> who here knows how to grab translations out of rosetta for, e.g., ubiquity?
<mathiaz> slangasek: seems like your eucalyptus job is doing what it's supposed to then
<slangasek> mathiaz: except Keybuk suggests 'exit 1' is better for the unconfigured case
<slangasek> instead of stop ; exit 0
<mathiaz> huh?
<LaserJock> slangasek: mind if I upload this: http://launchpadlibrarian.net/33762653/moodle_1.9.4.dfsg-0ubuntu3.debdiff ?
<Keybuk> if it's unconfigured, or the configuration is wrong, that's a failure
<Keybuk> you want that communicated
<Keybuk> it's not the same as "you didn't put splash on the kernel command-line" (which is a normal condition meaning the job is disabled)
<mathiaz> Keybuk: ok - gotcha now.
<slangasek> LaserJock: <blink> what's the libc6 change that makes this necessary?
<slangasek> LaserJock: oh, it's doing IPv6
<LaserJock> slangasek: yep
<LaserJock> slangasek: you get a 403 when trying to configure moodle without that patch
<slangasek> LaserJock: I think you probably want to list both values, then?  Otherwise, you'll also be denying connections to <hostname> on systems that have dynamic IPs, which is arguably a regression?
<LaserJock> slangasek: ok, makes sense
<slangasek> (since /etc/hosts is set up with 127.0.1.1 <hostname>, and users may expect that to work)
<mathiaz> kees: has eucalyptus 1.6~bzr931-0ubuntu4 been already uploaded?
<mathiaz> kees: the bzr branch still show UNRELEASED
<LaserJock> slangasek: but good to go with that change?
<Keybuk> damnit, fingers, remember how GRUB1 works
<slangasek> LaserJock: I think so, yes
<Keybuk> oh
<Keybuk> that's neate
<Keybuk> echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink
<Keybuk> slangasek: would you have any objection if we did something like
<Keybuk> tty1 - boot messages, then a getty
<Keybuk> tty2 - splash, then X
<Keybuk> tty3+ - more gettys, if configuration allows
<Keybuk> (lynx obviously)
<Amaranth> Where do the other Xes go?
<Keybuk> that's what I mean
<Keybuk> ie. we hardcode something to own tty1
<Keybuk> we make usplash appear on tty2, then move it out of the way for X
<Keybuk> X will claim the first free tty (taking out the tty7 hardcode), which will be tty2
<Keybuk> then tty3+ will be gettys and Xs depending on configuration
<Keybuk> each taking the first free
<Keybuk> if we don't boot with splash, you stay on tty1 until X chvts
<Keybuk> and then you see useful messages
<Amaranth> ah, neat
<Keybuk> if boot appears to hang while usplash is up Ctrl-Alt-F1 will take you to useful messages
<Keybuk> (Alt-F1 even)
<Keybuk> Ctrl-Alt-F1 will still work in X
<Keybuk> we could use tty7 for splash/X but then we need to keep the ugly hack that makes it go there
<Keybuk> the hack that I keep breaking by accident :p
<Keybuk> and then if you had only one getty configured, you'd have the weird thing where the second X login would be on tty2 ;P
<docro> HI! I was wondering if anyone has noticed the default netcat behavior for waiting on STDIN has been changed. It appears that it indefintely waits on stdin, whereas the default use to be to terminated immediately upon EOF
<docro> this seems to be a result of the addition of the -q flag, but I can't be entirely sure
<Keybuk> docro: I don't think that's changed
<Keybuk> netcat has always been a bit weird about EOF
<docro> I know at least in suse distros it termiantes immediately on stdin closing
<docro> echo "foo" | netcat server.com
<docro> will close once foo is written
<docro> let me grab the version #s real quickl
<docro> ubuntu: [v1.10-38] ... SLES 11: [v1.10]
<docro> SLES11 does not offer the -q option in its version of netcat
<Keybuk> docro: suse could have patched it
<docro> Keybuk are you running ubuntu right now?
<docro> I doubt they would patch functionality OUT of netcat
<Keybuk> docro: yes.
<docro> what version? if not 9.04 can you test the behavior
<Keybuk> 9.10
<docro> what version of netcat? netcat -h will show
<Keybuk> as you say, v1.10-38
<docro> hmmm I guess I would need to troll through commits to netcat in both distro to figure it out
<Keybuk> the documentation says without -q, it will not quit on EOF on STDIN
<docro> for now I have juas aliased netcat to netcat -q 0
<docro> Keybuk: the ubuntu documentation, yes
<Keybuk> docro: just about every tool has minor differences between distros
<docro> Keybuk: agreed, it's just causing me grief :) I was wondering if ubuntu ever worked the other way
<Keybuk> I don't think so, we inherit from Debian
<docro> not closing on EOF is not really a minor difference
<Keybuk> according to the changelog, -q isn't even *in* the upstream netcat ;)
<Keybuk> it looks like netcat is one of those "maintained by patches" tools
<docro> I have lots of code that depends on netcat closing upon EOF to gather results
<docro> because that is how it works in red hat and suse
<Keybuk> it looks like there's netcat-bsd and netcat-traditional in Ubuntu as well
<docro> hmm
<docro> Maybe I will try those
<docro> thanks :)
<Keybuk> docro: and just as many people (more in fact, we have more users <g>) have code that depends on netcat not closing on EOF
<docro> Keybuk: you have more desktop users maybe :P
<docro> enterprise is dominated with RH and SUSE
<Keybuk> so? :)
<docro> who pays the bills :)
<Keybuk> they don't pay our bills
<docro> not yet hehehe
<docro> Thanks for your help though, I will try the traditional package. Otherwise I will just leave my alias in
<sladen> docro: think OEMs, ODMs, SoC chip/CPU designers (... companies that actually have *serious* amounts of money)
<docro> sladen i work for a company with serious amounts of money
<docro> not that my nagging would make them pay up!
<sladen> docro: I'd approach Canonical for a support contract :)
<docro> sladen: currently one of the lone wolves moving towards desktop ubuntu for dev box and trying to get our tools working :) Doubtful our servers will ever go that way :(
<docro> alright good night, thanks for the help again
<Keybuk> he was pleasant
<Keybuk> normally there's more depramming of toys
<LaserJock> heh, depramming of toys, I like that
<mathiaz> kirkland: have you seen https://code.launchpad.net/~mathiaz/eucalyptus/karmic-fix-cloud-upstart-job/+merge/13452?
<mathiaz> kirkland: for https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/452665
<ubottu> Launchpad bug 452665 in eucalyptus "eucalyptus-cloud runs without any option set" [High,In progress]
<kirkland> mathiaz: the upstart fixes?
<kirkland> mathiaz: yeah
<kirkland> mathiaz: why the respawn?
<mathiaz> kirkland: if eucalytpus-cloud dies, you wanna get it restarted no?
<kirkland> mathiaz: i think so; just didn't see a note about that in the changelog
<kirkland> mathiaz: ifconfig eth0:1 169.254.169.254 netmask 255.255.255.255
<kirkland> mathiaz: that looks to be working for me
<mathiaz> kirkland: you may wanna call it differently
<mathiaz> kirkland: like eth0:eucalocal
<kirkland> mathiaz: i couldn't get it to work with a string
<kirkland> mathiaz: only with an int
<mathiaz> kirkland: avahi creates an eth0.avahi
<mathiaz> kirkland: IIRC
<mathiaz> kirkland: hm - may be you don't wanna have a virtual interface
<kirkland> mathiaz: i couldn't get it to work with the ip command either
<kirkland> mathiaz: had to use ifconfig
<sladen> kirkland: ip ... label xyz
<kirkland> sladen: hmmm
<kirkland> sladen: sudo ip addr add 169.254.169.254/32 scope link dev eth0 label eth0:1 ?
<sladen>  ... dev eth0:myfoo label eth0:myfoo
<j1mc> ScottK: ping
<kirkland> sladen: ubuntu@cluster:~$ sudo ip addr add 169.254.169.254/32 scope link dev eth0:9 label eth0:9
<kirkland> RTNETLINK answers: File exists
<sladen> kirkland:
<sladen> j1mc:
<mathiaz> kirkland: have you removed the existing 169.254.169.254/32 ?
<sladen> kirkland: try adding an address that isn't in-use, eg   .169.253
<kirkland> sladen: mathiaz; bingo
<kirkland> mathiaz: would you like me to merge and upload your upstart changes?
<kirkland> mathiaz: i have no objections
<mathiaz> kirkland: yes please
<slangasek> Keybuk: I would object to us changing that in karmic ... :)
<kirkland> mathiaz: how much longer are you online
<mathiaz> kirkland: don't know
<mathiaz> kirkland: why?
<mathiaz> kirkland: are you off tomorrow?
<kirkland> mathiaz: i was thinking about it, but i didn't hear from alice
<kirkland> mathiaz: i wanted you to review my eth device labeling
<mathiaz> kirkland: why - do you have a fix to test?
<kirkland> mathiaz: i'm testing it now
<mathiaz> kirkland: sure - send a branch
<kirkland> mathiaz: k
<kirkland> mathiaz: the lintian output for eucalyptus is a mess
<kirkland> mathiaz: brilliant!
<kirkland> sladen: thanks for the pointer!
<mathiaz> kirkland: I know - thanks :)
<kirkland> mathiaz: lp:~kirkland/eucalyptus/eth-label
<kirkland> mathiaz: looks like it's working to me
<mathiaz> kirkland: I'll build a local version here and run through my tests
<Teddy_> Hi there.  My package needs updating from Debian testing.  Is this the right place?
<kirkland> kirkland: 1, scorpion: 0
<kirkland> http://rookery.canonical.com/~kirkland/CIMG0097.jpg
<kirkland> back to eucalyptus
<mathiaz> kirkland: hm - build your branch
<mathiaz> kirkland: upgraded packages - still 169.X on eth0
<kirkland> mathiaz: i had to reboot
<kirkland> mathiaz: restarting networking and eucalyptus might do it, though
<mathiaz> kirkland: does this mean that on shutdown eucalyptus-cloud doesn't remove its ip address?
<kirkland> mathiaz: probably
<mathiaz> kirkland: well - the package upgrade should restart eucalyptus-cloud
<mathiaz> kirkland: well - I've just rebooted my CC
<kirkland> mathiaz: i'm fixing it to handle the pub and priv addresses too, with a label
<kirkland> mathiaz: eth0:pub and eth0:priv
<kirkland> mathiaz: for the guest ip's
<kirkland> mathiaz: which are also stacked on eth0
<mathiaz> kirkland: hm
<mathiaz> kirkland: are you using multiple addresses?
<kirkland> mathiaz: ?
<mathiaz> kirkland: there can be more than one public IP assigned to the CC
<mathiaz> kirkland: like .2 .3 .4 .5
<mathiaz> kirkland: all assigned to the CC
<kirkland> mathiaz: i'm not using an enumerator right now
<kirkland> mathiaz: that's more complex
<kirkland> mathiaz: mainly, i'm getting the superflous addresses off of eth0
<mathiaz> kirkland: right - just saying - multiple public IPs are common
<kirkland> mathiaz: and onto their own label
<mathiaz> kirkland: right - so eth0:pub would have multiple public IPS
<kirkland> mathiaz: i'm just fixing the ones that eucalyptus creates for vm guests
<kirkland> mathiaz: right
<mathiaz> kirkland: ok - if that works well that's great
<kirkland> mathiaz: i'm pushing an update now
<kirkland> mathiaz: did your CC come back up?
<mathiaz> kirkland: yop
<kirkland> mathiaz: actually, pushing to lp:~kirkland/eucalyptus/eth-label2
<kirkland> mathiaz: and?  ifconfig says?  and ip addr says?
<mathiaz> kirkland: the eht0:metadata is there :)
<kirkland> mathiaz: nice
<mathiaz> kirkland: let me check if instances are working correclty
<kirkland> mathiaz: please
<mathiaz> kirkland: http://paste.ubuntu.com/294367/
<kirkland> mathiaz: looks good
<kirkland> mathiaz: and ifconfig?
<mathiaz> kirkland: well - there is still 169.X in there
<mathiaz> kirkland: ifconfig properly shows eth0 and eth0:metadata
<kirkland> mathiaz: pastebin that
<mathiaz> kirkland: http://paste.ubuntu.com/294368/
<kirkland> mathiaz: good
<kirkland> mathiaz:           inet addr:192.168.12.118  Bcast:192.168.12.255  Mask:255.255.255.0
<kirkland> mathiaz: that's the key one
<mathiaz> kirkland: yes
<kirkland> mathiaz: i'm please with that
 * mathiaz nods
<kirkland> mathiaz: okay, branch lp:~kirkland/eucalyptus/eth-label2
<kirkland> mathiaz: sorry, had to push a new branch
<kirkland> mathiaz: i uncommitted something, and things diverged
<mathiaz> kirkland: now eucalyptus-ipaddr.conf uses ip addr
<mathiaz> kirkland: ok
<kirkland> mathiaz: yeah, i think it should use ifconfig
<kirkland> mathiaz: but that's just my preference
<kirkland> mathiaz: i'm not going to change it, but i would support someone else in doing so
<mathiaz> kirkland: so I was poking around the configuration and found something interesting in /etc/eucalyptus/eucalyptus.conf
<kirkland> mathiaz: ?
<mathiaz> kirkland: VNET_PUBINTERFACE="eth0"
<mathiaz> VNET_PRIVINTERFACE="eth0"
<mathiaz> kirkland: seems that we already know which interface should be used for private /public interface
<kirkland> mathiaz: i suspect that's intended for servers with multiple eth cards
<kirkland> mathiaz: so you could put eth0 in one, and eth1 in the other
<mathiaz> kirkland: so we wouldn't need to do the ip route default thingy
<kirkland> mathiaz: oh!
<mathiaz> kirkland: right - one of my setup is like that
<kirkland> mathiaz: you mean to get the default interface
<mathiaz> kirkland: yes
<kirkland> mathiaz: yeah, good idea
<mathiaz> kirkland: and in that setup the ip was wrong
<mathiaz> kirkland: ie the avahi_publish process was using the wrong ip
<mathiaz> kirkland: that being said things weren't working afterwards
<mathiaz> kirkland: the NC was using the wrong IP address to access walrus
<kirkland> mathiaz: ip addr show label eth0
<kirkland> mathiaz: ;-)
<kirkland> mathiaz: that drops the metadata labeled interfaces
<mathiaz> kirkland: nice
<mathiaz> kirkland: instances seem to be running correclty
<kirkland> mathiaz: http://paste.ubuntu.com/294373/
<mathiaz> kirkland: http://paste.ubuntu.com/294374/
<mathiaz> kirkland: ^^ this is with a running instance
<mathiaz> kirkland: with a public IP
<kirkland> mathiaz: right, that's without my latest patch
<mathiaz> kirkland: yop - I'm building your label2 branch
<fabrice_sp> Hi. I've found a problem with binutils libs: the soname does no match the shlibs file. Is it still possible to get it fixed for Karmic, or it has to go though SRU, and will be fixed after release?
<kirkland> mathiaz: http://pastebin.ubuntu.com/294379/
<mathiaz> kirkland: 2x nice
<kirkland> mathiaz: i'm quite happy with this
<kirkland> mathiaz: perhaps would be better if there was an interator on :pub
<kirkland> mathiaz: but, meh, this is easy, clean
<mathiaz> kirkland: did you try to boot two instances?
<mathiaz> kirkland: and see if two IPs can be added to the labeled interfaces?
<kirkland> mathiaz: this is 2 instances
<kirkland> mathiaz: see lines 49 and 50
<mathiaz> kirkland: ah right
<mathiaz> kirkland: I was looking at the ifconfig output
<kirkland> mathiaz: and both can communicate
<kirkland> mathiaz: right, that's what i mean by an iterator on :pub
<mathiaz> kirkland: which only supports one IP
<kirkland> mathiaz: yeah
<kirkland> mathiaz: we could add the last octet of the ip address to that
<kirkland> mathiaz: so mine would be eth0:pub30 and eth0:pub31
<mathiaz> kirkland: can you log on both guests via their public IP address?
<kirkland> mathiaz: yup
<mathiaz> kirkland: well - you can necessarly use the last octet only
<mathiaz> kirkland: what happens if you have a /16 network?
<kirkland> mathiaz: eucalyptus only supports /24 networks
<kirkland> mathiaz: dan told me that last week, while you were dozing in the car :-)
<mathiaz> kirkland: :o
<kirkland> mathiaz: for the public ip's
<mathiaz> kirkland: hm well. I think for the time being the current solution is enough
<kirkland> mathiaz: i agree
<mathiaz> kirkland: we'll have to get upstream opinion on this
<kirkland> mathiaz: we could also add a random string
<mathiaz> kirkland: it's cleaner - is it worth putting in the release?
<kirkland> mathiaz: i think it is
<kirkland> mathiaz: i was going to roll all of this
<kirkland> mathiaz: i could put it into a ppa right now
<kirkland> mathiaz: until we get approval
<mathiaz> kirkland: let me do more testing of label2
<kirkland> mathiaz: agreed
<mathiaz> kirkland: I don't think putting in a PPA is helpfull at this tage
<mathiaz> kirkland: stage
<kirkland> mathiaz: what more testing do you suggest?
<kirkland> mathiaz: do you have it running yet?
<mathiaz> kirkland: well - it's more that noone is using a PPA
<mathiaz> kirkland: I'm upgrading
<kirkland> mathiaz: eucalyptus has been using my ppa every day
<kirkland> mathiaz: i meant ppa it for us + euca to test
<mathiaz> kirkland: oh ok.
<mathiaz> kirkland: I guess it could help then
<kirkland> mathiaz: for the ~12 hours it would take to get an upload approved
<kirkland> mathiaz: i think dan will gladly take this change
<kirkland> mathiaz: it doesn't affect the actual networking, which was dan's concern
<mathiaz> kirkland: so IIUC the 169.X address is not deleted when eucalyptus is stopped?
<kirkland> mathiaz: the diff only adds a label argument
<mathiaz> kirkland: right - which is a good thing
<kirkland> mathiaz: that's probably true; and a bug
<mathiaz> kirkland: right - priv and pub addresses are removed correctly
<mathiaz> kirkland: what does happen to the :pub and :priv when there are no more instances running?
<kirkland> mathiaz: let's find out!
<kirkland> mathiaz: http://pastebin.ubuntu.com/294382/
<kirkland> mathiaz: pub removed, priv not
<mathiaz> kirkland: right - probably make sense
<mathiaz> kirkland: the remaining address is the private gw IIRC
<kirkland> mathiaz: ack
<kirkland> mathiaz: did you see the fun you missed here tonight?  http://rookery.canonical.com/~kirkland/CIMG0097.jpg
<kirkland> mathiaz: i had to take a 10 minute catch-the-scorpion-without-getting-stung-break
<mathiaz> kirkland: well - fun - like you life was at stake?
<mathiaz> kirkland: sounds like fun
<kirkland> mathiaz: :-)
<mathiaz> kirkland: who won?
<kirkland> mathiaz: i'll save him in a jar for you
<kirkland> mathiaz: it was a very close battle
<kirkland> mathiaz: but i bested him with my wit, and stunning looks
<mathiaz> kirkland: so you caught him alive?
<kirkland> mathiaz: yessir.  in a jar now
<kirkland> mathiaz: i'll save him for you
<mathiaz> kirkland: tya
<mathiaz> kirkland: will it survive 3/4 weeks?
<kirkland> mathiaz: absolutely
<kirkland> mathiaz: they can go a month without water
<kirkland> mathiaz: i'll treat him better than that, though
<kirkland> mathiaz: okay, what else should we do tonight?
<kirkland> mathiaz: after the scorpion battle, i'm ready to turn in
<kirkland> mathiaz: i think i'm going to commit this to the core-dev branch
<mathiaz> kirkland: right
<kirkland> mathiaz: push to my ppa
<mathiaz> kirkland: I'd still ask upstream for their opinion
<kirkland> mathiaz: email the relevant parties
<kirkland> mathiaz: we need to get a release team member's approval to upload, right?
<mathiaz> kirkland: well - you can upload - they will review it anyway
<kirkland> mathiaz: ah
<mathiaz> kirkland: it's actually easier for them
<mathiaz> kirkland: as they will see the diff directly
<mathiaz> kirkland: it just won't get in
<kirkland> mathiaz: okay, should we wait to do that, until after we get upstream's opinion?
<mathiaz> kirkland: yes - I'd wait for upstream's opinion
<mathiaz> kirkland: if you push it to your PPA
<kirkland> mathiaz: ack
<mathiaz> kirkland: upstream can easily test it and give feedback
<kirkland> mathiaz: should i upload the rest, minus my network change?
<mathiaz> kirkland: if they're happy with it and accept the change, we can push into the archive
<kirkland> mathiaz: okay, cool
<mathiaz> kirkland: I wouldn't do two uploads
<kirkland> mathiaz: cool
<mathiaz> kirkland: I'll ask in the release meeting tomorrow morning
<mathiaz> kirkland: the diff is not that big
<kirkland> mathiaz: cool
<kirkland> mathiaz: i think i have it
<kirkland> mathiaz: pushed to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/
<kirkland> mathiaz: uploading to PPA
<kirkland> mathiaz: uploaded
<kirkland> mathiaz: emailing upstream
<kirkland> mathiaz: mail sent, you're on cc
<kirkland> mathiaz: nurmi likes it :-)
<Laibsch> ArneGoetje: The information you asked for in bug 338217 has been given.  What now?
<ubottu> Launchpad bug 338217 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::Module::unload()" [Medium,Incomplete] https://launchpad.net/bugs/338217
<Laibsch> That ticket is receiving dupes almost daily now.
<Laibsch1> @all, can we please see a sync to fix bug 444883?
<Laibsch1> bug 444883
<ubottu> Launchpad bug 444883 in whereami "please sync whereami 0.3.34-0.2 from Debian testing" [Undecided,New] https://launchpad.net/bugs/444883
<pitti> Good morning
<ScottK> Good morning pitti.
<pitti> hey ScottK, how are you ?
<ScottK> Tired.
<ScottK> I should be asleep.
<ScottK> pitti: Do you still have your Latitude D430?
<pitti> ScottK: yes, I do; you as well?
<ScottK> Yes.
<ScottK> I've been having trouble the last couple of days with lid opening not being recognized.
<pitti> weird
<pitti> ScottK: works quite well her
<pitti> e
<ScottK> So if I close the lid, it never notices it opens and so never turns the display back on.
<ScottK> OK.
<ScottK> I tried the previous intel driver, just to make sure and it's not that.
<pitti> ScottK: could you do the following: install input-utils, then "sudo lsinput" and find the event number of the lid switch, then do "sudo input-events N" with that number and close/open the lid?
<ScottK> I guess I'd have to ssh into the machine
<liw> I had trouble once with the open/close sensor being wonky (it was a pin that got pushed in to indicate close, and the spring that pushed it back out went bad and didn't push it out enough)
<ScottK> Because I won't have a working X
<ScottK> It's not hardware
<ScottK> Coming back from suspend on lid open works fine.
<Laibsch1> I think ubuntu-laptop-mode should be removed: bug 450004
<ubottu> Launchpad bug 450004 in ubuntu-laptop-mode "time for removal of ubuntu-laptop-mode package?" [Undecided,New] https://launchpad.net/bugs/450004
<ArneGoetje> Laibsch: I can't fix the bug. In related (if not the same) bug #199592 Zhengpeng Hou has asked for testing his PPA package, so far no reply on that. As I cannot reproduce this issue at all anyways I'm afraid I'm unable to help on this issue. From the comments it seems to appear at random for some users.
<ubottu> Launchpad bug 199592 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::Module::unload()" [Medium,Confirmed] https://launchpad.net/bugs/199592
<Laibsch> OK
<Laibsch> Why did you ask for removing the config files and reinstallation of the package?
<ArneGoetje> Laibsch: sometimes old config data can cause such things... it happened in the past.
<Laibsch> Can you read stack traces?
<ArneGoetje> Laibsch: no. I'm not a programmer.
<Laibsch> If those two are indeed dupes with a certain degree of certainty, it would be nice to mark them as such
<Laibsch> OK
<Laibsch> Bummer
<Laibsch> Neither am I
<ScottK> pitti: I'm going to wait until my kdelibs build finishes to close the lid (I have a theory about the Kubuntu netbook RC bug you assigned to Riddell today), so that'll probably be after I sleep.
<dholbach> good morning
<Laibsch> ArneGoetje: I'll ask for help in #ubuntu-bugs with reading the stacktraces
<mvo> hey dholbach
<dholbach> hi mvo
<ArneGoetje> Laibsch: thanks
<slangasek> Keybuk: no bug numbers in this usplash upload?  What's broken if we don't do this?
<Laibsch> slangasek: Are you aware that the latest change to the emacs package now forces the installation of emacs22 again?
<Laibsch> From what I can see it's a step back, not a step forward
<Laibsch> towards the migration to emacs23
<pitti> Laibsch: emacs22 is in main, 23 is in universe, so the default should be 22
<pitti> it wasn't considered for main early enough before FF
<Laibsch> ic
<dholbach> lool, paulliu: what happened to mutter-moblin now?
<paulliu> dholbach: Can I upload the new package to Debian and then request sync again?
<paulliu> dholbach: Just fix the things you mentioned yesterday.
<dholbach> sure, but the earlier the better
<paulliu> dholbach: OK. I do it now.
<dholbach> rock on
<dpm> hi slangasek
<dpm> re: bug 447383, and since the string freeze break was granted after NonLanguagePackDeadline, thus not leaving translators time to do their work, would it be possible to have an exception on ubiquity-slideshow-ubuntu so that translations are exported by LanguagePackDeadline on the 22nd and still used in the LiveCD?
<ubottu> Launchpad bug 447383 in ubiquity-slideshow-ubuntu "UI freeze exception for ubiquity-slideshow-ubuntu 9 (Ubuntu One and FF 3.5)" [Undecided,Fix released] https://launchpad.net/bugs/447383
<dpm> If so, how could I request this exception?
<pitti> dpm: we can't upload it _on_ the 22nd, since that's the day when we release RC
<pitti> dpm: but we can do/accept an upload next Friday, after RC, so that they'll be in final
<dpm> pitti, that would be perfect. How do I go about requesting this?
<pitti> dpm: best would be to open a bug against it and subscribe ubuntu-release, then nominate it for karmic
<pitti> dpm: please point me at it, then I'll approve/milestone
<pitti> dpm: then it'll be on the release radar and we won't forget about it
<dpm> pitti, ok, I'll do that now, thanks a lot!
<pitti> I'm off for ~ 2 hours for a doctor appt.
<cjwatson> kees: re that mkswap/luks thing you were discussing with Keybuk, I think it would be worth filing a bug on busybox; I don't think its mkswap clears out the bootbits
<cjwatson> kees: (but unfortunately I also don't think it's safe to try to do that for release; util-linux mkswap has several checks in there that aren't trivial to implement in busybox)
<dpm> pitti, (when you're back), here it is -> bug 452889, please feel free to approve/milestone if appropriate
<ubottu> Launchpad bug 452889 in ubiquity-slideshow-ubuntu "NonLanguagePackTranslationDeadline exception request" [Undecided,New] https://launchpad.net/bugs/452889
<geser> pitti: do you have time to sponsor the diff in http://paste.ubuntu.com/294525/? it fixes the upload failure for your openthesaurus upload
 * ogra is looking at the gltk FTBFS ... if i refresh the .symbols file with the 1.1.9 symbols added, it works error free with fakeroot debian/rules binary ... as soon as i build it in pbuilder it fails with differences in the .symbols file ... 
<ogra> *the fltk FTBFS
<mdz> mathiaz, what's wrong with the script as written? the weird temporary file stuff that Keybuk was referring to was fixed ages ago, and it now has the logic in a start script as he suggested
<mdz> (the eucalyptus upstart job)
<pitti> dpm: done
<pitti> geser: oh, that was still on my list, thanks!
<pitti> geser: any idea why it does that hackery at all?
<geser> pitti: no idea
<jdstrand> mdeslaur: is 'Low' the right priority for bug #446524? as I read it, aa-logprof is busted for everything. is that an incorrect assessment?
<ubottu> Launchpad bug 446524 in apparmor "aa-logprof: doesn't parse new null profile syntax" [Low,In progress] https://launchpad.net/bugs/446524
<mdeslaur> jdstrand: no, I'll change it to high
<jdstrand> mdeslaur: can you add a regression-potential tag as well?
<mdeslaur> jdstrand: If I can ever figure out how to add a tag, sure!
<mdeslaur> jdstrand: oh, found it
<mdeslaur> d'uh
<jdstrand> :)
<ogra> pitti, what exactly does devicekit disks do with usb disks when i fire up gnome-session
<ogra> pitti, trying to debug bug 431963 i found a weird issue ... it doesnt boot into graphical mode at all. i can set text on the cmdline and properly boot into a text console though ... creating ~/.xsession that only fires up xterm i can even startx ...
<ubottu> Launchpad bug 431963 in linux-fsl-imx51 "io/fs errors when launching gdm on imx51 with sata" [High,Confirmed] https://launchpad.net/bugs/431963
<ogra> as soon as i fire up gnome-session from that xterm, the system hangs and i see the following in dmesg ... http://paste.ubuntu.com/294674/
<ogra> i suspect one of the gdu monitors or devicekit-disks to be the issue here, the disk is sitting on a special SATA->USB controller that lives on the board
<Chipzz> ~..
<mnemonikk> Chipzz: flaky ssh connection? 8-)
<pitti> cjwatson: do you happen to know if usplash uses bogl insead of svgalib when running under KMS? (if you don't know, nevermind)
<cjwatson> yes, it does
<pitti> aaaah
<cjwatson> this is a feature :)
<pitti> ok, then I know why bug 448988 happens
<ubottu> Launchpad bug 448988 in usplash "--pulse-logo doesn't actually pulse the logo" [Medium,Triaged] https://launchpad.net/bugs/448988
<pitti> and usplash sets an entirely black palette
<pitti> cjwatson: thanks
<cjwatson> beware, Scott's last upload doesn't seem to be in bzr ...
<ion> mnemonikk: Whenever i have to do ~.enter and irssi is active, i try to create a new screen window first before typing that, in case the input actually reaches the box. :-)
<ion> enter~., that is.
 * cjwatson tends to hit C-u first
<pitti> cjwatson: I know, Steve had a question about it; thanks for the warning
<pitti> ogra: highvoltage
<pitti> oops, meant to say "hi"
<ogra> ?
<ogra> heh
<mnemonikk> ion: 8;-)
 * ogra feels shocked
<cjwatson> DANGER DANGER HIGH VOLTAGE
<ogra> hehe
<pitti> bzzzzzt
 * cjwatson puts on his stovepipe hat
<pitti> ogra: dk-disks itself doesn't do anything by itself, but vfs currently has a bug that it (sometimes) automounts all internal hard disks at startup
 * sistpoty|work tried tab-completion for his password once :P
<pitti> ogra: bug 451613
<ubottu> Launchpad bug 451613 in gvfs "all disks and partitions are automounted in the live session" [High,In progress] https://launchpad.net/bugs/451613
<cjwatson> oh wait, that was a different Electric Six video :)
<ogra> pitti, hmm, any way to disable that to prove it's actually at fault ?
<Chipzz> mnemonikk: flakey wireess connection :S
<Chipzz> think someone is trying to hack my wireless
<ogra> pitti, mounting shouldnt trigger a device reset though
<paulliu> dholbach: I've pushed new mutter-moblin into sid few hours ago. It still needs some time to appeared for requestsync.
<pitti> ogra: uninstall dk-disks temporarily? or move aside devkit-disks-daemon
<dholbach> paulliu: just file the bug manually then?
<dholbach> if necessary we can sync from incoming
<paulliu> dholbach: ok. I'll do that now.
<paulliu> dholbach: sorry. Which package/target should I report to?
<dholbach> ubuntu
<paulliu> ok
<dholbach> https://launchpad.net/ubuntu/+filebug?no-redirect I think
<paulliu> dholbach: thanks.
<ogra> pitti, will try ...
<ogra> i removed everything in /etc/xdg/autostart already but that doesnt seem to help
<paulliu> dholbach: oops. Launchpad timeout error.
<sivang> anybody know where the group photo from UDS paris is ?
 * sivang admits a rather odd question at this time of year
<dholbach> paulliu: without edge. maybe?
<paulliu> dholbach: I disabled beta tester for 2 hours but still Timeout.
<paulliu> dholbach: strange.
<sivang> hmm, close to release time, I'm being ignored, granted :)
<ogra> seb128, is there any code in gnome-session that could trigger something like that: http://paste.ubuntu.com/294674/
<ogra> i have cut down all preipherial apps to nearly zero, starting gnome-session or gdm (which spawns gnome-session) makes the root disk disappear
<seb128> not that I know about no
<seb128> gnome-session is mainly starting other things
<ogra> if i use ~/.xsession, install xfce and put startxfce4 in there it works fine with startx
<ogra> i have removed everything from /etc/xdg/autostart
<ion> Those look like USB problems.
<seb128> it's probably devicekit-disks
<ogra> i wouldnt know what else to remove
<ogra> ion, its a SATA drive :P
<seb128> ther are quite some things dbus activated
<seb128> ie gvfs, devicekit-disks
<seb128> you can move the binaries to try
<ogra> hmm, how do i disable them
<seb128> move the binaries away
<ogra> i removed devkit-disks-daemon, that didnt help yet
<seb128> or dbus .service
<seb128> dunno then
<LaserJock> cjwatson: do you think you'll have time to look at my cdimage merge request today?
<james_w> Ng: I think there's a chance that you could get the latest bash-completion synced from Debian. You'd have to talk to a release manager though
<Ng> james_w: I've had it installed since lunch and I'm pretty much on the verge of retracting what I said. It's nice not having the regression, but the new avahi stuff is driving me crazy ;)
<Ng> avahi-browse takes 5 seconds to complete
<james_w> heh
<cjwatson> LaserJock: I don't know, I'll try
<LaserJock> cjwatson: k, thanks, I know you're busy
<ccheney> mvo: ping
<mvo> ccheney: pong
<kees> cjwatson: yeah, the checks util-linux's mkswap does depend on the libraries, etc.  are we using the busybox mkswap for installs?
<kees> kirkland: oooh, I'd never seen "label" from ip before.  nice.
<kirkland> kees: it was new to me too
<kirkland> kees: sladen showed it to me
<pitti> elmo, james_w: btw, bug 395302 is another report of this
<ubottu> Launchpad bug 395302 in gdm "kills X session during upgrade" [Critical,Fix released] https://launchpad.net/bugs/395302
<pitti> (at the bottom)
<cjwatson> kees: yes
<cjwatson> always have
<kees> cjwatson: oh, I thought the liveCD and alt have util-linux?
<cjwatson> kees: live CD uses util-linux mkswap
<cjwatson> kees: alternate CD *installs* util-linux, but doesn't have it in the installation environment
<kees> ah-ha.
<mathiaz> mdz: re eucalyptus job start: the pre-start script was setting up the correct opts variable - however eucalyptus-cloud was using an exec statement with an opts variable
<mathiaz> mdz: and variables are *not* propagated from the pre-start block to the exec block
<mathiaz> mdz: the fix was to move all the code that deals with updating the opts variable within a script statement instead of an exec statement
<ccheney> doko: ping
<ccheney> doko: are you doing that new binutils upload?
<bdrung> TheMuso, dtchen: is bug #453158 a alsa or pulseaudio bug?
<kirkland> pitti: looks like richard hughes has a fix for the encrypted-swap/hibernate problem
<ubottu> Launchpad bug 453158 in xmms2 "problem with xmms2 toggleplay" [Undecided,New] https://launchpad.net/bugs/453158
<kirkland> pitti: you think this is SRU-able?
<pitti> kirkland: I saw the bug mail
<ccheney> slangasek: or do you happen to know if he is doing it? I'm trying to determine when I should do the OOo upload
<pitti> kirkland: looked quite complex, so I wouldn't like to upload it now; but if we tested it a bit in lucid, we can consider that
<kirkland> pitti: okay, cool
<kirkland> pitti: i'll leave this with you
<kirkland> pitti: cheers
<pitti> thanks!
<kirkland> pitti: there's a dozen or so bugs in launchpad related to this
<kirkland> pitti: filed against linux, hal, acpi, gnome, cryptsetup, pm-utils
<mathiaz> which component is responsible for the fsck on boot?
<mathiaz> I've run into a fsck check this morning but couldn't cancel it
<jcastro> http://www.fewt.com/2009/10/i-give-up.html <-- anyone know anything about this?
<pitti> mathiaz: known bug, Keybuk has a branch ready
<jcastro> specifically the part about being ignored by ubuntu developers?
<mathiaz> pitti: great thanks
<doko> ccheney: will reply on email. are all planned changes now really included in the upload? ,P
<ccheney> doko: the ppc fix and the kde4 fixes will be in, not sure if there were any other planned ones?
<ccheney> the kde4 fixes didn't even exist when i did the previous upload
<xan_> Hi, sorry for the inconvenience but I can't get information via web. Anyone know if it's planning to improve the UNR with the "speed" of the ubuntu moblin remix?
<ccheney> doko: ok will get the upload staged for you today
<EvanCarroll> This very big perl-xml-sax bug is set to plague the jaunty upgrade
<EvanCarroll> https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/13917
<ubottu> Launchpad bug 13917 in libxml-sax-perl "CPAN's XML::SAX update conflicts with libxml-sax-perl's XML::SAX" [Medium,Confirmed]
<doko> ccheney: thanks
<EvanCarroll> like 20 dupes of the bug now, with 2 of them being posted since karmic beta
<EvanCarroll> I wish i could change the importance
<EvanCarroll> I talked to the debian guys about the bug and the changes need to fix it, they're pretty perl retarded though
<EvanCarroll> I'd say the best of them has 2 credit hours and no real life experience with the language.
<james_w> EvanCarroll: insulting our colleagues isn't likely to be a good strategy to get us to help you
<james_w> please try and state your concern without the unnecessary editorialising
<pitti> james_w, mvo: with u-m switched back to synaptics, is bug 445303 still an issue for karmic then?
<ubottu> Launchpad bug 445303 in update-manager "update-manager stucked on polkit password dialog" [High,Invalid] https://launchpad.net/bugs/445303
<james_w> pitti: it's seen in other polkit using things, so I would say yes
<EvanCarroll> I'm not needing help -- this was more of an informative message if anyone cares to do some work on the issue moving away from debian. They simply do not undersatnd perl, I've written letters filed bugs, and fixed both launchpad and their tracker marking dupes of this issue as appropriate -- they don't get it.
<pitti> james_w: but the crashes in NM for example were fixed in today's uploada
<EvanCarroll> I'm thinking about requesting permissions from XML::SAX author to send a request to cease and decist.
<pitti> james_w: right now I'm a bit puzzled what to do with this bug, if it's not even reproducible in karmic any more? (since u-m switched backend)
<james_w> pitti: I don't think they are the same bug are they?
<pitti> james_w: not originally, I just asked to test the new PK again because 445303 is obviously also a crash
<pitti> d-bus timeouts usually mean that the backend has crashes
<EvanCarroll> they hack code into the module in an unsupported fashion, without subclassing, and it litterally breaks everything when you upgrade that module outside of dpkg.
<pitti> s/crashes/crashed/
<james_w> pitti: oh, I see
<EvanCarroll> their answer is, "CPAN is not supported on debian systems"
<EvanCarroll> which is laughable.
<ScottK> EvanCarroll: It's not.
<pitti> james_w: it was worth a shot, anyway
<james_w> EvanCarroll: please desist
<ScottK> We have a package management system and people should use it.
<james_w> pitti: I suspect that fix will not have made this go away, but it would be good to know.
<cjwatson> we should do a better job of it, and I don't think CPAN should be declared as unsupported since it is very useful for admins using Perl
<james_w> pitti: as for tracking the bug, I suggest we still do for software-center etc.
<EvanCarroll> Nothing should /have/ to use it for modules, Firefox (add-ons) doesn't use it, ruby (gems), and even python (pypi), php (pear) don't have to use it -- why should perl.
<cjwatson> but I don't see the point of discussing it here - I believe I commented on the patronising attitude last time too!
<james_w> jdong: did you have a chance to test the policykit changes I made?
<pitti> james_w: ah, right; that uses aptdaemon, too
<cjwatson> it needs to be fixed in Debian
<jdong> james_w: no; sorry, got caught up in back-to-back midterms...
<james_w> jdong: no problem
<james_w> jdong: don't worry if you have more important things to be doing
<jdong> I'll try to make some time tonight to get that info back to you
<jdong> james_w: haha admittedly I wasted some time earlier in the week converting to a btrfs root... ended in tragedy ;-)
<james_w> jdong: sounds like a sensible thing to be doing ;-)
<jdong> :)
 * jdong views "EXPERIMENTAL" as an empty threat ;-)
<james_w> heh
<ScottK> pitti: I got the event information for lid close/open on my D430 that we discussed early this morning.
<ScottK> http://paste.ubuntu.com/294833/
<jcole> fyi guys, seems to be another problem with flash on 64 bit firefox again... reddit users are starting to complain (they suggest to just get the 64 bits from adobe directly) -> http://www.reddit.com/r/linux/comments/9tr3d/the_ubuntu_flash_flu/
<jcole> ive also got my own strange "white box" problem happening lately
<JanC> jcole: AFAIK Adobe forbids Canonical to distribute the 64-bit alpha plugin...  :-(
<jcole> JanC: maybe "someone" should throw some "support" towards the swfdec developers ;)
<JanC> both swfdec & gnash work for some sites and not for others, maybe they should start working together first...
<kees> chrisccoulson: so, I'm trying to force the g-s-s crash by adding delays, etc, so I can "prove" that your patch fixes the problem (also so I can test jaunty and earlier).  I'm not having much luck.
<chrisccoulson> kees - i tried to force it by adding delays too, but i don't think delays make it any worse
<chrisccoulson> you just need to be unlucky with the timing
<chrisccoulson> i've not had a look at older versions of g-s-s yet
<kees> chrisccoulson: but where is the actual problem...
<kees> chrisccoulson: I'm trying to figure out at which line of code having the dialog vanish causes the problem.
<kees> chrisccoulson: the shake_dialog even checks window->priv->lock_box before the alignment_set_padding call..
<kees> chrisccoulson: I assume it's during the gtk_main_iteration(), but it's not clear what
<kees> shake_dialog is called via lock_command_watch.
<chrisccoulson> kees - yeah, it will occur once gtk_main_iteration is called. gtk_alignment_set_padding registers some sources on the event loop
<chrisccoulson> and then those events are dispatched with gtk_main_iteration
<kees> so at what point are those sources unmapped?
<chrisccoulson> the issue will occur if the dialog exits after dispatching an event that accesses the resource at some point
<kees> lock_command_watch is called on pipe input
<chrisccoulson> because once the event has been dispatched, the main process cannot notice the dialog has disappeared until execution has returned back to the main loop
<kees> chrisccoulson: right, but doesn't that mean everything stays allocated?  I'm not clear what's tearing down the allocation.
<chrisccoulson> i'm not 100% sure how XEmbed works, but i'm fairly sure it is the gnome-screensaver-dialog process which allocated the resources on the server
<kees> chrisccoulson: so, some event happens between gtk_alignment_set_padding and gtk_main_iteration in shake_dialog that causes gtk_container_idle_sizer to die?
<chrisccoulson> kees - yeah, that's likely. it could also happen at any point in the while loop too
 * kees tries adding more delays...
<jdstrand> kirkland: hi! can you explain to me the issue with pulseaudio and qemu-kvm?
<kirkland> jdstrand: "the issue"?
<jdstrand> kirkland: yes-- debian/patches/10_qemu-allow-pulseaudio-to-be-the-default.patch
<kirkland> jdstrand: i reverted that one
<kirkland> jdstrand: i had cherry-picked it from fedora, thinking that might be a good thing
<jdstrand> kirkland: something is not right. specifically, on a brand new vm I hit bug #453329
<ubottu> Launchpad bug 453329 in libvirt "libvirt apparmor profile denies access to pulseaudio" [Medium,Triaged] https://launchpad.net/bugs/453329
<kirkland> jdstrand: the initial bug reporter just wanted kvm to "prefer" pa over oss and alsa
<jdstrand> kirkland: (fine). so I go to fix the apparmor profile, and now when I start the vm, it hangs
<jdstrand> kirkland: in other words, now that the apparmor profile isn't denying access to pulseaudio, the vm won't start
<chrisccoulson> kees - you might have more luck recreating the issue by ignoring the "destroy" and "plug_removed" signals from the GtkSocket in gs-window-x11.c, but i can't predict what other wierd effects that would have
<chrisccoulson> perhaps delay executing the callbacks?
<chrisccoulson> you could maybe use those signals to trigger a callback which just registers the real callback to be executed after a delay with g_timeout_add
<chrisccoulson> i need to go for dinner shortly, but i may try that afterwards
<kees> chrisccoulson: ok, cool.
<jdstrand> kirkland: let me rephrase-- it starts just fine, but during boot it hangs
<kirkland> jdstrand: hmm, i'm not sure what to say ...  i added that patch, and then reverted it
<kirkland> jdstrand: guest kernel hangs?
<jdstrand> kirkland: I don't know
<kirkland> slangasek: i just uploaded eucalyptus for exception approval; please let me know if you need anything of me
<jdstrand> kirkland: but if I do:
<jdstrand> echo autospawn = no|tee -a ~/.pulse/client.conf
<kirkland> jdstrand: okay, let me install a new deskto vm
<jdstrand> killall pulseaudio
<jdstrand> actually, strike that
<jdstrand> kirkland: if I remove the sound device from the libvirt xml, it starts fine
<jdstrand> kirkland: it showed up by default as an es1370 iirc
<jdstrand> kirkland: yeah, es1370
<jdstrand> kirkland: you won't reproduce it without a patch to the apparmor profile
<jcole> big windows 7 releases and promotions happening all over this weekend and next few weeks... so, hold onto your hats... apparently, windows 7 can cure cancer and create world peace
 * jdstrand goes to get it
<kirkland> jdstrand: ?
<kirkland> jdstrand: you're seeing this on a package that's not in karmic right now?
<jdstrand> kirkland: no
<jdstrand> kirkland: like I said, the apparmor profile denies access to pulseaudio
<jdstrand> kirkland: that is a bug I was trying to fix
<kirkland> jdstrand: oh
<kirkland> jdstrand: okay, and in trying to fix that, you're getting a hanging vm
<jdstrand> kirkland: when I fixed the bug (ie, kvm has access to pa), then I saw this issue
<jdstrand> kirkland: simply put. pulseaudio doesn't work with libvirt/kvm due to apparmor. however, when I fix that, you will find that kvm and pulseaudio aren't getting along
<jdstrand> kirkland: http://paste.ubuntu.com/294893/
<kirkland> jdstrand: http://cvs.fedoraproject.org/viewvc/F-12/qemu/qemu-allow-pulseaudio-to-be-the-default.patch?revision=1.3&view=markup
<kirkland> jdstrand: that *was* the patch I had cherry picked
<kirkland> jdstrand: i periodically do a sweep over fedora's patches, and pick ones that look tasty
<kirkland> jdstrand: i thought that one looked good, but as soon as I applied it and uploaded, i got a complaint from a user whose bug I had previously fixed, and he said my upload regressed his fixed
<kirkland> jdstrand: tbh, I didn't really dig too deeply into his issue
<jdstrand> kirkland: apply my diff to /etc/apparmor.d/abstractions/libvirt-qemu, then try to install karmic off the livecd in a new vm
<jdstrand> kirkland: using virt-manager
<jdstrand> kirkland: assuming pulseaudio is running on your machine, the vm will hang somewhere during boot
<kirkland> jdstrand: what's your command line say?
<kirkland> jdstrand: -soundhw ?
<jdstrand> kirkland: -soundhw es1370
<jdstrand> kirkland: http://paste.ubuntu.com/294897/
<kirkland> jdstrand: hmm
<jdstrand> kirkland: are you seeing it with straight kvm?
<kirkland> jdstrand: i was able to get sound okay, with straight kvm
<kirkland> jdstrand: i'm syncing the daily desktop iso now
<kirkland> jdstrand: i should be able to reproduce it with just that, right?
<jdstrand> kirkland: well, my desktop-iso was old. I used virt-manager with generic/generic, kvm/i686 and an i386 desktop livecd
<kirkland> jdstrand: hmm...  there could be any one of a number of kernel problems with an old iso ....
<kirkland> jdstrand: i'm rsyncing now
<jdstrand> kirkland: related to sound specifically? like I said, if I don't use -soundhw es1370 it works fine
<kirkland> jdstrand: so no -soundhw at all, or a different -soundhw ?
<kirkland> jdstrand: when it works ^
<jdstrand> kirkland: no -soundhw at all (I removed the sound device from the xml)
<kirkland> jdstrand: and sound works?
<kirkland> jdstrand: or it's just able to boot?
<jdstrand> kirkland: no. the vm boots to the desktop
 * kirkland would not expect sound to work
<jdstrand> kirkland: with -soundhw es1370 it hangs during the boot
<kirkland> jdstrand: okay ....
<kirkland> jdstrand: i'm applying your patch
<kirkland> jdstrand: actually, i'm going to first boot today's desktop iso with sound, without your patch
<kirkland> /usr/bin/kvm -m 512 -smp 2 -usb -usbdevice tablet -net nic,model=virtio -net tap,script=/home/kirkland/bin/bridge.sh -soundhw es1370 -cdrom karmic-desktop-amd64.iso
<jdstrand> kirkland: you should then see apparmor denied messages in kern.log (or /var/log/autit/audit.log if you use auditd)
<kirkland> jdstrand: okay, here's what I have ...
<kirkland> jdstrand: my desktop hardware is running pulse audio
<kirkland> jdstrand: i have not applied your patch yet
<kirkland> jdstrand: i booted today's desktop iso using bare qemu-kvm
<kirkland> jdstrand: with the command line above (with es1370)
<kirkland> jdstrand: i did get the startup sound, though it was a little garbled
<kirkland> jdstrand: okay, so i assume applying your patch won't have any affect, unless i run through libvirt, right?
<kirkland> jdstrand: i'll try virt-manager
<jdstrand> kirkland: the apparmor protection does not apply to kvm on its own, no. you must use libvirt
<jdstrand> kirkland: use generic/generic with kvm/i686 (that is what I did)
<jdstrand> I'm rsyncing the image now too
<kirkland> jdstrand: okay, i'm using amd64, ubuntu/karmic
<kirkland> jdstrand: and i'm setting a placebo using virt-manager, without your patch
<kirkland> jdstrand: will apply it in a moment
<jdstrand> I too use amd64/karmic
<kirkland> jdstrand: http://pastebin.ubuntu.com/294909/
<kirkland> jdstrand: okay, no startup sound
<jdstrand> kirkland: what version of libvirt do you have?
<kirkland> ii  libvirt-bin                              0.7.0-1ubuntu11                            the programs for the libvirt library
<kirkland> jdstrand: ^
<jdstrand> ok
<kirkland> jdstrand: okay, so i didn't have sound working ... is this expected at this point?
<jdstrand> I wonder why it is looking in /home/kirkland/.pulse-cookie
<jdstrand> kirkland: yes, but I have a feeling you'll get another denied message after the patch, but let's see what happens
<kirkland> jdstrand: http://pastebin.ubuntu.com/294913/
<jdstrand> kirkland: a blank line may have crept in. can you eyeball the result to make sure it applied right
<kirkland> jdstrand: okay, looks right
<kirkland> jdstrand: do i need to restart libvirt?
<jdstrand> kirkland: no
<jdstrand> kirkland: just try a new VM
<kirkland> jdstrand: http://pastebin.ubuntu.com/294916/
<kirkland> jdstrand: it booted to the desktop
<jdstrand> kirkland: ok good-- apparmor is not denying access anymore
<jdstrand> kirkland: do you have sound?
<kirkland> jdstrand: no
<jdstrand> kirkland: do you have the sound device?
<kirkland> jdstrand: yes
<kirkland> jdstrand: http://pastebin.ubuntu.com/294918/
<kirkland> jdstrand: that's what i get when i try to run the same command by hand
<kirkland> jdstrand: no libvirt
<jdstrand> kirkland: well, at least it booted. I'll try with a new vm. sounds like there may be a bug somewhere between how you start it with kvm and how libvirt starts it
<kirkland> jdstrand: not sure it's related
<kirkland> jdstrand: have you tried with the latest iso yet?
<jdstrand> kirkland: still downloading
<jdstrand> kirkland: is 'sound' the name of your vm?
<kirkland> jdstrand: yeah
<jdstrand> kirkland: that is unrelated
<kirkland> jdstrand: okay, i've simplified the command line
<jdstrand> kirkland: 0.7.0 started using a monitor socket
<jdstrand> kirkland: Switch to using a unix socket for the qemu monitor (Mark McLoughlin)
<jdstrand> (from the NEWS file)
<Chipzz> Mark McLoughlin, now there's a name that sounds familiar :)
<jdstrand> kirkland: are you running the barebones kvm as root? that is how libvirt starts it when using qemu:///system
<Chipzz> be it from GNOME and not qemu :P
<kirkland> jdstrand: no, as non-priv user
<kirkland> jdstrand: i'm trying it with sudo now
<jdstrand> kirkland: dude, it is taking *forever* to get the iso...
<kirkland> jdstrand: where are you pulling it from?
<kirkland> jdstrand: and at what rate?
<jdstrand> cdimage.ubuntu.com
<kirkland> jdstrand: i have pretty good upload
<jdstrand> 61.06kB/s
<kirkland> jdstrand: private link coming
<walters> Chipzz: he's on the Red Hat virt team now
<kirkland> jdstrand: sounds works if i don't use libvirt
<jdstrand> kirkland: let's try this
<jdstrand> kirkland: can you do:
<jdstrand> sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd && sudo /etc/init.d/libvirt-bin restart
<jdstrand> kirkland: then do 'virsh capabilites | grep apparmor'
<jdstrand> kirkland: what this does is start libvirt without the apparmor security driver. if you can't get sound to work there, it is clearly a problem between libvirt and kvm
<jdstrand> kirkland: it is also temporary, so on the next reboot (or profile load and restart of libvirt) you'll have the standard, default libvirt configuration
<kirkland> jdstrand: how urgent is all of this sound business?
<mdke> Riddell: something seems to have gone wrong with https://help.ubuntu.com/community/KarmicUpgrades - did you overwrite the page somehow? I can't see the old page history to revert it
<kirkland> jdstrand: i don't particularly care about it, tbh ... i think i have some higher priorities
<jdstrand> kirkland: well, I only brought it up to you because I plan to fix the apparmor issue. if this then exposes a pulseaudio/kvm/libvirt bug that causes a massive regression, I thought it be best to let you know about it first :)
<kirkland> jdstrand: i have working sound when i use qemu-kvm; non-working sound when i use libvirt
<jdstrand> kirkland: I don't care about sound working
<jdstrand> kirkland: I care about the vm not starting
<kirkland> jdstrand: right; i haven't reproduced that
<jdstrand> kirkland: err, not booting to the desktop
<kirkland> jdstrand: i suspect you won't either, when you get an up-to-date iso
<jdstrand> kirkland: feel free move on. If I continue to have problems with the newer iso, I'll let you iknow
<kirkland> jdstrand: and if the vm is still hanging, i'd start looking at the guest's kernel's dmesg
<kirkland> jdstrand: okay, thanks;  sorry to be abrupt :-)
<kirkland> jdstrand: i don't mean to be rude
<jdstrand> kirkland: it isn't rude. I just don't want to catch you off guard with my upload
<kirkland> jdstrand: right; vm not booting, that would be a regression.  vm without sound...well, i don't have sound right now through libvirt
<kirkland> jdstrand: which i'm sure people will complain about
<kirkland> jdstrand: but i'm not that bothered right now
<Riddell> mdke: there was nothing there before
<chrisccoulson> kees - any luck trying to trigger the g-s-s crash reliably?
<chrisccoulson> i had a look through my xtrace log again, and that shows that it is the gnome-screensaver-dialog process which creates the resource which gnome-screensaver tries to access after it is destroyed
<kees> chrisccoulson: no.  :(
<kees> chrisccoulson: I can see the child defunct while I wait.
<kees> chrisccoulson: it must be a very specific order of events
<chrisccoulson> kees - i agree. i could only recreate it occasionally before
<chrisccoulson> but i've tried and tried to trigger it with the patch, and i don't get it any more
<chrisccoulson> i tried for 20 minutes continuously entering the wrong password last night, with the change in, and i didn't make it crash
<jdstrand> kirkland: fyi, I tried with an intrepid desktop livecd. I disables 'splash and quiet' and it booted all the way
<chrisccoulson> and i tried again today too
<kirkland> jdstrand: excellent
<jdstrand> kirkland: there may be a race, I don't know
<jdstrand> kirkland: oh, I left out part of it
<kirkland> jdstrand: for your iso woes ...  i just realize that we're not building qemu-kvm against libcurl
<jdstrand> kirkland: I tried with an intrepid desktop livecd. the first time, it hung. the second time I disabled 'splash and quiet' and it booted all the way
<kirkland> jdstrand: if we did, you could -cdrom http://...iso and stream over the internet :-)
<chrisccoulson> kees - want me to put it in my PPA and ask some of the reporters to test it?
<kees> chrisccoulson: I'm nearly 100% sure your patch is correct, but I'm mostly after trying to prove that Jaunty and earlier are/aren't affected.
<mdke> Riddell: hmm, that used to be quite an important page. not sure what happened to it then
<mdke> Riddell: but I hear the release managers are working on getting it back
<kees> chrisccoulson: PPA> sure, yeah, can't hurt
<ccheney> grr is the a way to make chroots work now that we use upstart?
<ccheney> i'm getting stuff like: start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<ccheney> causing package installation in a chroot to fail
<chrisccoulson> kees - i had a look at the code for the jaunty version, and not much has changed in that area, so i can't see why jaunty wouldn't have the same issue. but then, there might be a GTK change in karmic that exposes the underlying issue
<kees> chrisccoulson: yeah, that's what I was thinking
<chrisccoulson> kees - if i get some time, i will test my jaunty VM and see if i can trigger it there
<chrisccoulson> but i could do with a more automated way of testing it really:(
<Riddell> mdke: well it's never existed for karmic
<Riddell> mdke: I thought ubuntu desktop used a page on ubuntu.com now
<kees> chrisccoulson: does dogtail or the other thing let someone automate hitting enter on that dialog?
<chrisccoulson> kees - i'm not sure. i was thinking that i could maybe do a special jaunty build which bypasses all the pam stuff in the dialog process, and instead just loops and sends auth failure message back to gnome-screensaver, to simulate a user repeatedly entering the wrong password
<chrisccoulson> and then just leave that running for a while
<kees> chrisccoulson: oh, heh
<chrisccoulson> but perhaps there is a way of faking the enter keypress event
<jdstrand> kirkland: well, 1 out of 10 times in hung. I think I'm done poking at this for now.
<kirkland> jdstrand: ugh, that does sound racy
<kirkland> jdstrand: i think we actually do need qemu-allow-pulseaudio-to-be-the-default.patch
<kirkland> jdstrand: i thing i was too quick to revert that patch
<kirkland> jdstrand: and i think the user/bugreporter may have been wrong
<sebner> mighty Riddell, any plans to update k3b?
<jdstrand> kirkland: it *really* feels like a too many resources accessing the sound card issue
<kirkland> jdstrand: i have had working sound at various times duing karmic
<jdstrand> kirkland: eg, one time I was listening to rhythmbox (ie pa was using the soundcard) and no sound in the vm
<jdstrand> kirkland: other times sound in the vm
<jdstrand> kirkland: and then the one time it hung
<mdke> Riddell: ah, possibly I may be out of touch
<mdke> Riddell: false alarm maybe
<Riddell> sebner: update to what?
<jdstrand> kirkland: can I hand this off to you for investigation whenever you see fit?
<sebner> Riddell: alpha3
<kirkland> jdstrand: you can hand off the non-libvirt, non-apparmor piece to me, yes
<sebner> Riddell: 1.68.0 alpha3 > 1.66.0~alpha2-0ubuntu7
<kirkland> jdstrand: i really won't be able to efficiently debug the libvirt or the apparmor aspects
<jdstrand> kirkland: this was all with apparmor disabled
<jdstrand> kirkland: it is not an apparmor issue. it hung without it
<kirkland> jdstrand: i'll own the getting bare qemu-kvm to work with audio
<jdstrand> kirkland: I'll just file a bug then
<kirkland> jdstrand: oh, the hang?
<kirkland> jdstrand: file that against the linux package
<Riddell> sebner: guess I'll add it to my evening's todo list :)
<kirkland> jdstrand: if the guest kernel is hanging, that's not a qemu-kvm issue, i don't think
<jdstrand> kirkland: I don't think it is a 'linux' issue
<sebner> Riddell: cool! (I'm not using kde or k3b though, just let you know because of your users sake ;-D)
<jdstrand> kirkland: I think the kvm process hung cause it was trying to access the soundcard
<kirkland> jdstrand: okay, sure file the bug, i probably won't look at it until after karmic
<jdstrand> kirkland: I believe this to be true because all of libvirt hung and I could use 'virsh list' until I killed off the kvm process trying to access the soundcard
<kirkland> jdstrand: did you strace -p the kvm process?
<kirkland> jdstrand: attach that to the bug
<jdstrand> no
<kirkland> jdstrand: that would help a lot
<jdstrand> I can
 * jdstrand tries to get another hang...
<kees> slangasek: I've just uploaded m2crypto for bug 451998.  no changes to the installed package -- just enables the testsuite and works around a weird issue on the builders.
<ubottu> Launchpad bug 451998 in m2crypto "Please run the test suite on build by default" [Medium,Fix committed] https://launchpad.net/bugs/451998
<kees> chrisccoulson: heh, I've gotten as far as getting these, but no crashes:
<kees> (gnome-screensaver:20207): Gtk-CRITICAL **: gtk_alignment_set_padding: assertion `GTK_IS_ALIGNMENT (alignment)' failed
<chrisccoulson> kees - those would suggest that the dialog has exitted at a point where gnome-screensaver has noticed it, and freed some client-side resources
<dobey> anyone around that can sponsor an upload for karmic main?
<kees> chrisccoulson: yeah.  I'm more and more convinced this is an internal gtk change.  anyway, I'm going to upload your fix, as I think it is good for karmic, and I want to keep the late churn for RC down.  :)
<chrisccoulson> kees - thanks. i'll try and come up with a way of automatically testing this on a jaunty machine too
<chrisccoulson> i don't want to sit here for hours hitting my enter key ;)
<kees> hehe
<kirkland> jdstrand: question for you about your hang ....
<kirkland> jdstrand: what cpu do you have?
<kirkland> jdstrand: and do you have cpu freq scaling enabled?
<kirkland> jdstrand: there are some known, non-deterministic hangs related to some AMD rev-F or old CPUs, when freq scaling is enabled
<jdstrand> kirkland: dual core Intel. model name: Genuine Intel(R) CPU 3.00GHz
<kirkland> jdstrand: okay, should not be affected
<jdstrand> kirkland: it also hung in the same place in usplash each time
<jdstrand> kirkland: 3 'ticks' in
<kirkland> jdstrand: k
<jdstrand> kirkland: fyi, bug #453453
<ubottu> Launchpad bug 453453 in libvirt "libvirt sometimes hangs when using pulseaudio" [Undecided,New] https://launchpad.net/bugs/453453
<jdstrand> kirkland: I don't have the strace, but will attach when I see another hang
<kirkland> jdstrand: thanks
<kirkland> kees: could you throw some build super powers at https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1295329 ?
<kees> sure, one sec
<kees> kirkland: "Start in 1 minute"
<kirkland> kees: beautiful
<elleuca>  hi, could someone try to check this bug? https://bugs.launchpad.net/bugs/451974
<ubottu> Launchpad bug 451974 in compiz "Black video minimizing Totem window" [Undecided,New]
<jdstrand> kirkland: fyi-- bug #453495
<ubottu> Launchpad bug 453495 in virt-manager "virt-manager does not allow selecting other architectures when using qemu" [Undecided,New] https://launchpad.net/bugs/453495
<jdstrand> kirkland: I haven't looked to the why, but thought it might have had something to do with the qemu-kvm packaging
<jdstrand> kirkland: that title was misleading. this is more accurate (bug #453495)
<ubottu> Launchpad bug 453495 in virt-manager "virt-manager does not allow selecting other architectures when using qemu" [Undecided,New] https://launchpad.net/bugs/453495
<jdstrand> meh
<jdstrand> virt-manager does not honor other architectures when using qemu
<kirkland> jdstrand: perhaps... other arches are in qemu-kvm-extras
<jdstrand> kirkland: see the bug. it's installed
<mathiaz> mvo: hi tried a mysql cluster bug upgrade - run into bug 453513
<ubottu> Launchpad bug 453513 in update-manager "mysql-server-5.0 is removed if mysql-server is removed on jaunty->karmic upgrade" [High,Triaged] https://launchpad.net/bugs/453513
<mathiaz> mvo: mysql-server-5.0 is removed on upgrade because it became an unused dependency (mysql-server being removed)
<cjwatson> ccheney: link /sbin/initctl to /bin/true; this will be in the release notes
<cjwatson> (you'll probably want to move it aside rather than just blatting it)
<cjwatson> (or maybe dpkg-divert)
<kirkland> jdstrand: okay, i think i'm seeing your virt-manager hang
<kirkland> jdstrand: so when i run kvm by hand, i see in my sound mixer qemu under the processes that pulse audio is attached to
<kirkland> jdstrand: that's when sound works
<chrisccoulson> kees - i have an automated screensaver test up and running on jaunty now
<chrisccoulson> so i'll leave that going overnight and see what happens
<kees> chrisccoulson: oh, cool; does it work in karmic?
<chrisccoulson> kees - i've not tried it in karmic yet, as it's implemented as a patch in gnome-screensaver
<chrisccoulson> it just repeatedly fakes keypresses
#ubuntu-devel 2009-10-17
<ccheney> cjwatson: thanks
<jdong> why doesn't /dev/fd exist on this new Karmic install... :-/
<jdong> that is supposed to be a symlink to /proc/self/fd, no?
<jdong> symlinking worked (tm)
<xxtjaxx> Hi I'm trying to add my key to the keyserver but currently it seems like it doesnt work with gpg --keyserver keyserver.ubuntu.com --send-keys any help would be great
<xxtjaxx> Can somebody help me get my keys on the keyserver?
<xxtjaxx> Ah now it works for got to add the key name when sending my key sorry for bothering you guys
<slangasek> ok... why is upgrading udev hanging?
<slangasek> unpleasant things to see output by your initramfs:
<slangasek> udevadm trigger is not permitted while udev is unconfigured.
<jdong> is the /dev/fd symlink nonexistent for anyone other than me on Karmic?
<TheMuso> jdong: I have it
<TheMuso> amd64 here
<jdong> just fresh installed a Karmic image today and *cough* (converted it to btrfs... don't look here)...
<TheMuso> ext4
<maco> i have it amd64 and ext4 as well
<jdong> I'll blame it most possibly on my crackpot config then :)
<jdong> and work up the un-laziness to boot up the karmic daily sometime $soon
<lamont> so why is it that my karmic laptop now prefers wlan0 over eth0?
 * lamont runs apport-collect, and decides that, no, he won't give it complete control over his launchpad account.  at least not tonight
<ccheney> doko_: done with the upload to chinstrap
<jdstrand> kirkland: ok good, then I'm not crazy
<slangasek> jdstrand: surely that's orthogonal ;)
<jdstrand> slangasek: heh. you always keep me honest :P
<YokoZar> Found a nasty problem in current karmic -- apparently my / partition is filling up continuously because the log file is way too huge.  /var/log/syslog.1 is 600 something megabytes at the moment
<ebroder> What are the chances of syncing kerberos-configs from Debian at this point? The version in Ubuntu still includes a krb4-config
<mattn> morning - current karmic daily live-cd isn't able to enter X with my mobile nvidia card
<mattn> is that a known issue?
<mattn> erm - sorry, not nvidia -wrong notebook. it's an ati mobility radeon x600
<mattn> getting a stacktrace from somewhere in libglx.so (GLXInitExtension)
<xxtjaxx> Hi whats the ubuntzu equivalent to debians unstable?
<joaopinto> xxtjaxx, ubuntu uses a different model, the current dev version is ubuntu karmic
<xxtjaxx> ok tahnks
<xxtjaxx> hi i get this failure when dputting my stuff to launchpad http://pastebin.ca/1624753. Why could this be?
<siretart> xxtjaxx: don't upload binaries, lp accepts sources only
<xxtjaxx> aha
<xxtjaxx> Thansk
<xxtjaxx> hmm still cant write it
<siretart> xxtjaxx: the .upload file is not supposed to be uploaeded. the .changes file is the important one
<xxtjaxx> yeahbut it didnt write the file for some reason
<xxtjaxx> what section do you have for kde apps about multimedia
<pitti> ScottK: it looks a bit confusing that you called it twice?
<pitti> ScottK: but otherwise the events get picked up, so it's not a low-level kernel problem
<geser> bdrung: re eclipse build: my guess it's because of the common-install-indep target
<geser> the amd64 build complains about missing files in /usr/share. the missing files are the images moving in this target from /usr/lib/ to /usr/share
<bdrung> geser: yes. your hint was sufficent
<bdrung> thx for that
<geser> and this target isn't called on amd64 (and others)
<bdrung> geser: i have fixed in in the git repo and testing it now. will upload -0ubuntu4 soon.
<siretart> does kubuntu also use pulseaudio by default?
<dtchen> no
<ScottK> pitti: I did call it twice just so I could remember which was the lid open and which was the lid close.
<ScottK> pitti: Any suggestions on which packages I should look for changes in (I don't know a lot about this part of the system)?
<dtchen> ScottK: mind uploading a FTBFS fix for whois for me, please? http://pastebin.com/dc948ea6
<ScottK> dtchen: Heading off to do some stuff.  Ping me in a couple of hours if no one else got it in the meantime.
<dtchen> ScottK: sure thing, thanks
<mbiebl> Hi, this might be a bit OT, but what's the best way to fully automatically deploy Ubuntu 9.10 on Desktops/Workstations?
<mbiebl> I started reading into FAI until I noticed that it had been removed for karmic
<chrisccoulson> kees - i left this screensaver test cycling all night on my jaunty machine, without a single crash
<chrisccoulson> so i think that the issue only seems to have affected karmic
<siretart> mbiebl: depends on what you mean with 'the best way'. AFAIUI you have 3 options: 'd-i preseeding', 'kickstart' and 'fix FAI for karmic' :-)
<mbiebl> siretart: could I use the sid packages on karmic? Are there alternatives to FAI that you know of?
<azeem> mbiebl: 17:31 < siretart> mbiebl: depends on what you mean with 'the best way'. AFAIUI you have 3 options: 'd-i preseeding', 'kickstart'
<mbiebl> siretart: what I need is, deployment over the net, installing a custom set of packages, push configuration to the client (like e.g. the hostname) or the config for libpam-mount
<siretart> mbiebl: the biggest problem with fai in ubuntu is the kernel. we always had big trouble with unionfs over NFS. AFAIUI nobody has tried karmic's kernel yet, though.
<mbiebl> and setting up the user
<siretart> sounds pretty much doable with d-i preseeding
<mbiebl> siretart: got a good howto somewhere, otherwise I'd just start investigating in that direction myself
<siretart> if you want to use FAI, you could setup an FAI server under debian, and use an ubuntu karmic bast.tar.gz. that *should* work
<siretart> d-i preseeding is documented in the d-i manual
<mbiebl> siretart: ok, thanks
<ccheney> slangasek: ping
<ccheney> slangasek: aiui doko uploaded OOo sometime this morning after testing it, i think its being held by the freeze though
<ScottK> ccheney: It is
<ccheney> ScottK: ok
<EvanCarroll> I think i found an issue in karmic with my Atheros driver being software switched off, not responding to Fn+<F5> the thinkpad key sequence.
<EvanCarroll> right-click enable driver also doesn't work
<EvanCarroll> I've fixed this problem through the new rfkill interface, to turn it on
<EvanCarroll> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/395358
<ubottu> Launchpad bug 395358 in linux "thinkpad fn+f5, Asus fn+f2: regression, rfkill toggling in the kernel instead of userspace" [Medium,Won't fix]
<EvanCarroll> nevermind found the report
<dotblank> Hi there I just installed my updated remastered livecd on my laptop and and im speechless. I love you guys.. This is just incredible. NEVER have I seen such an awesome release
<cjwatson> it's nice to get praise for a change; obviously we normally only hear about it when things are going wrong. Thanks!
<jdong> dotblank: indeed, thanks for the kind words :)
<dotblank> I mean this is amazing... everything works out of the box.. nothing wrong... its just plain awesome
<dotblank> Now only if adobe could be as awesome as you guys are.... and get 64 bit flash proper
<jdong> heh
<jdong> flash is a bit of a 64-bit headache right now in Karmic
<cyberix_> Is the operation of Ubuntu installer explained somewhere?
<jdong> I'd guess somewhere in ubiquity's source
<cyberix_> Is first boot somehow different from later reboots?
<dotblank> well the flash 10 pre release is ok
<jdong> it segfaults firefox pretty often for me
<dotblank> OMG
<dotblank> OMG!
<dotblank> I just installed cheese and my webcam is upside up.. its always been upside down even in vista
<cyberix_> dotblank: Maybe it is upside down?
<dotblank> cyberix_, well its built into my laptop but in 9.04 and in vista it played back the camera upside down.. the only fix was using cheese's v flip option but it was annoying because its not system wide so it did not help with skype or any other program. I spent 2 months trying to fix and never found a solution
<cyberix_> dotblank: I'm talking about the physical object
<dotblank> yea its inside my laptop monitor
<dotblank> I cant flip it
<dotblank> without flipping my laptop
<cyberix_> The folks assembling your laptop probably installed it upside down then
<dotblank> yup
<dotblank> but then why does it work now
<jdong> haha two bugs make a fix.
<AdamSchackart> dotblank: like i said yesterday, flip your laptop and video output upside down
<AdamSchackart> typing will be extremely awkward, but you gotta do what you gotta do amirite?
<dotblank> AdamSchackart, but its fixed now... just how... how did it know!
<cyberix_> I need to find out why direct rendering does not work.
<cyberix_> It works, if I run Karmic from live cd
<cyberix_> so it cannot be a software bug unless someone broke it since beta was released
<cyberix_> I have no /etc/X11/xorg.conf file
<cyberix_> so it cannot be that
<cyberix_> So
<cyberix_> I did not have this graphics card when I originally installed Ubuntu
<cyberix_> Is the installation different for different hardware?
<cyberix_> Is there a guide for steps to be taken after swapping your graphics adapter to another model?
<tormod> cyberix_, wrong channel, I can help you in #ubuntu-x
<slangasek> ccheney: yes, and binutils is still in the queue, so OOo shouldn't be accepted just yet
<Laney> am I likely to get a sync of ndesk-dbus through now? fixes 377672 which causes crashes
<Laney> I'll just request it
<ccheney> slangasek: ok thanks :)
#ubuntu-devel 2009-10-18
<YokoZar> slangasek: Are FTBFS bugs going to hold up the release?  (eg https://bugs.launchpad.net/ubuntu/+source/fltk1.1/+bug/445560)  -- I need those fixed before I can update ia32-libs, which really needs a push before release.
<ubottu> Launchpad bug 445560 in fltk1.1 "FTBFS: conversion errors" [High,Confirmed]
<slangasek> YokoZar: it's supposed to be fixed before release, but we don't really have any traction on that bug yet AFAIK - why does ia32-libs need updated?
<LaserJock> slangasek: would uploading http://launchpadlibrarian.net/33791667/moodle_1.9.4.dfsg-0ubuntu4.debdiff be OK?
<LaserJock> it seems to fix the bug in Karmic anyway, I was going to test Jaunty->Karmic upgrades before uploading though
<slangasek> : why is dropping puppet's recommends: on libaugeas-ruby the right thing to do?
<slangasek> zul: why is dropping puppet's recommends: on libaugeas-ruby the right thing to do?
<slangasek> superm1: is the patch for bug #385658 really tested to DTRT on unsupported cards? (cf. bug #413439)
<ubottu> Launchpad bug 385658 in xserver-xorg-video-nv "'nv' is selected when no xorg.conf is present even if it doesn't support the nvidia hardware" [High,Fix released] https://launchpad.net/bugs/385658
<ubottu> Launchpad bug 413439 in xserver-xorg-video-nv "karmic alpha 4's xorg 'nv' driver does not handle Nvidia 8200" [Undecided,Confirmed] https://launchpad.net/bugs/413439
<slangasek> superm1: in particular, I notice that the code now adds an entry to NVChipsets,NVPciChipsets even if walking the list explicitly does *not* find a matching chip
<slangasek> superm1: oh, n/m, I guess you must have tested it on your own hardware as the bug submitter :)  still, bug #413439 is still open
<ubottu> Launchpad bug 413439 in xserver-xorg-video-nv "karmic alpha 4's xorg 'nv' driver does not handle Nvidia 8200" [Undecided,Confirmed] https://launchpad.net/bugs/413439
<AnAnt> Hello, I have a question regarding the latest change in gdm (setting the default theme using an XML file), will this step help to ease branding ?
<Laibsch> ArneGoetje: Any idea on the issue of CJKV characters again not displaying properly in Flash?
<Laibsch> bug 207198
<ubottu> Launchpad bug 207198 in fontconfig "Adobe Flash player 9 displays CJK text incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/207198
<Laibsch> Who could we ask?
<Laibsch> Unfortunately, flash is becoming more and more important and difficult to avoid
<YokoZar> slangasek: ia32-libs needs updating because the libraries it contains are over a month old and out of sync with the real 32-bit libs (so any bugs fixed in them remain).  There's also a few bugs that I've patched in the ia32-libs package itself (mostly missing symlinks for apps to not get confused when they're on 64 bit)
<bdrung_> who can close this blueprint? https://blueprints.launchpad.net/ubuntu/+spec/eclipse
<ArneGoetje> Laibsch: hmm... was it working before? And if yes, what changed?
<Laibsch> I think it was working before
<Laibsch> I don't remember specifically changing anything as far as configuration
<Laibsch> Just the normal upgrade routine
<Laibsch> But this stretches over such a long period of time that I cannot absolutely guarantee that there were no changes to the configuration
<Laibsch> All I can say is what I (Rolf) wrote in that ticket, IOW currently flash and CJKV don't mix for me, no matter what I do
<ArneGoetje> Laibsch: well, we haven't changed anything in fontconfig or language-selector in that regard. the only package which was updated, was firefox
<Laibsch> does CJKV work for you in FF?
<Laibsch> and flash
<ArneGoetje> Laibsch: let me check
<Laibsch> In general CJKV works for me in FF, of course, but not in flash
<Laibsch> Try the links I gave (jal.co.jp)
<Laibsch> some things work, some don't
<ArneGoetje> Laibsch: I tried the flash map of JAL, which you reported as not working. Works for me. But I would need to confirm on a fresh install in a VM...
<Laibsch> thanks
<Laibsch> interesting
<Laibsch> I wonder what I may have done to break things
<ArneGoetje> Laibsch: I'm starting up a VM with the Live CD... wait a few minutes, I will try to confirm.
<Laibsch> If this is OffT, let's move this to a private chat?
<Laibsch> ArneGoetje: Just to be sure, the innosked link works for you?
<ArneGoetje> Laibsch: yes, that one works
<ArneGoetje> Laibsch: just tried the same page in the daily Live CD from yesterday. Works without problems
<ArneGoetje> Laibsch: I just installed the Adobe Flashplugin from software center
<Laibsch> I'll see if I can try a different user and a live USB boot tomorrow
<ArneGoetje> Laibsch: which locale did you use for testing?
<Laibsch> I'll let you know the results
<Laibsch> Which LC_* setting do you want to know?
<Laibsch> I don't think that it had any relation to the problem, though
<Laibsch> My locale is usually UTF8
<ArneGoetje> Laibsch: LANG and LANGUAGE, maybe LC_CTYPE
<Laibsch> some setting de_DE
<Laibsch> others en_US
<ArneGoetje> Laibsch: I tried en_US and it worked... will try other locales as well
<Laibsch> LANG=de_DE.UTF-8, LANGUAGE=de_DE.UTF-8, LC_CTYPE="de_DE.UTF-8"
<Laibsch> I think that is probably what FF is running at
<ArneGoetje> Laibsch: just tried with de_DE: also works fine.
<ArneGoetje> Laibsch: will try with CJK font settings
<Laibsch> yes
<Laibsch> I don't think it had any relation to the locale
<Laibsch> I may have broken something in fontconfig
<Laibsch> and it may be something totally different altogether
<Laibsch> But judging from the reports in that bug ticket, I'm not the only one who currently has problems
<ArneGoetje> Laibsch: there we go! using fontconfig-voodoo with ja_JP displays fine... but zh_TW has the empty boxes...
<Laibsch> OK
<Laibsch> I'm glad you can at least reproduce sometimes
<Laibsch> That helps at least ;-)
<ArneGoetje> Laibsch: yeah... I'm just trying now to find out what's the problem with the fontconfig snippets
<Laibsch> cool
<Laibsch> let me know if there is anything I can do to help with my limited knowledge
<ArneGoetje> Laibsch: ok, found the problem... and I'm afraid it's not something easy to fix. :(
<ArneGoetje> Laibsch: seems Adobe Flash can only use one font and doesn't fall back to another font when glyphs are missing.
<ArneGoetje> Laibsch: For ja-JP we prefer Japanese fonts, even for ASCII, so there it's not a problem a Japanese font is used for the whole system
<ArneGoetje> Laibsch: but for zh-* we prefer DejaVu and then the Chinese fonts, because Latin glyphs in DejaVu look better. apparently this doesn't work with Flash.
<ArneGoetje> Laibsch: when I remove the DejaVu stance in the fontconfig file, a Chinese font is prefered, even for Latin glyphs. Then Flash displays the CJK characters fine.
<ArneGoetje> Laibsch: it's just funny that this only happens if we prefer the specific ordering of DejaVu, followed by a CJK font... if we don't specify this and fontconfig picks a font by itself, flash also displays fine.
<ArneGoetje> Laibsch: (i.e. we remove the 69-language-selector-* files)
<Laibsch> OK
<ArneGoetje> Laibsch, freeflying: will test more for bug #207198 tomorrow, need to sleep now
<Laibsch> So what's the suggested solution and its drawbacks?
<ubottu> Launchpad bug 207198 in fontconfig "Adobe Flash player 9 displays CJK text incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/207198
<Laibsch> ArneGoetje: Sure, I was about to hit the sack myself much earlier
<ArneGoetje> Laibsch: don't know yet. Let me do some more testing tomorrow.
<Laibsch> I hope I'll get to it soon
<Laibsch> Ok
<Laibsch> If I'm not in this channel, please ping me
<Laibsch> I should be online
<Laibsch> good night
<Laibsch> and thank you for your work
<ArneGoetje> Laibsch: ok, good night
<ArneGoetje> Laibsch: np
<slangasek> YokoZar: what do you mean, missing symlinks?  ia32-libs can't use any paths that are used by the native 64-bit packages
<LLStarks> hi.
<siretart> slangasek: OK to upload http://launchpadlibrarian.net/33910661/g-s-s.diff, cf. lp bug #428884? should fix screensaver issues with xine and vlc (and any app that uses gnome-screensaver-command --poke)
<ubottu> Launchpad bug 428884 in vlc "Vlc does not inhibit screensaver" [High,Confirmed] https://launchpad.net/bugs/428884
<siretart> patch against gnome-screensaver, not vlc's fault
<LLStarks> hey reinhard, do you know if anything is being done to make sure that usplash isn't a static image for the final release?
<superm1> siretart, by chance would you suspect that to help bug 453377 too?
<ubottu> Launchpad bug 453377 in mythtv "[ubuntu karmic] mythtv-frontend does not prevent display being put to sleep during tv watching" [Undecided,New] https://launchpad.net/bugs/453377
<siretart> LLStarks: sorry, I don't really follow usplash development
<siretart> superm1: looking
<LLStarks> who should i ask about it?
<superm1> siretart, that patch, gs_monitor_simulate_user_activity, is that the function called when --poke is used?
<siretart> I'd guess Keybuk or cjwatson, but check usplash's changelog yourself
<siretart> superm1: AFAIU the code there, yes.
<Keybuk> which code?
<Keybuk> aiui, the current usplash theme is the final one
<slangasek> siretart: we should certainly fix that bug; I can't comment on whether the code looks reasonable, I don't know what it's doing
<siretart> superm1: yes, I'm actually fairly confident that the patch should fix that
<slangasek> Keybuk: thread interleaving, he was responding to LLStarks' query
<superm1> siretart, yeah, i just saw that do_poke calls into simulate activity, so it looks like that is the same.  i'll mark duplicate accordingly
<siretart> slangasek: I'm not a g-s-s guru myself, but the patch is taken from upstream, and after reading the upstream comment on the patch, I believe we should include it
<siretart> plus: we have an independent user who confirms the patch works
<Keybuk> LLStarks: the current usplash theme is the final one I believe
<slangasek> siretart: then yes, please upload it; you don't have to get prior approval before uploading
<Keybuk> it's not entirely static, the logo does pulsate etc. in certain situations, and it does fade
<slangasek> siretart: fwiw, I don't count "one user says it works" for much for changes like this :)
<sladen> Keybuk: so, just to confirm, the _intended_ final theme is a static one (eg. no progress indication, no throbber)
<LLStarks> i can't get it to pulse even on a fresh daily.
<siretart> slangasek: ah, I see
<Keybuk> sladen: right
<slangasek> siretart: so the vlc task there should be closed as invalid?
<Keybuk> LLStarks: the pulsing is quite subtle, it shows up for me on this laptop, but on my other one it's hard to see
<superm1> LLStarks, it only pulses when using casper (eg booting the daily, not on the post install)
<sladen> Keybuk: okay, so what is this "logo does pulsate etc. in certain situations, and it does fade" you speak off
<LLStarks> if i was new to linux and had an old machine or non-ssd hard drive, i'd think my computer locked up.
<siretart> slangasek: yes, I wanted to confirm first that it's really not vlc's fault
<LLStarks> i have a 3 year old laptop and it spends about 20 seconds at usplash.
<sladen> Keybuk: where should I be looking?---if I know that there should be some (a fortnight ago it faded on shutdown) and I can report bugs and it not doing so
<sladen> Keybuk: do you have a video of what's intended
<LLStarks> sladen, there is fade in and fade out on my machine, but no pulsing whatsoever. it would be awesome if that wasn't restricted to livecd/liveusb.
<Keybuk> sladen: I don't understand? are you saying it does nothing for you?
 * sladen reboots to confirm his presumped madness.  bbiab
<LLStarks> for me, the shutdown usplash almost never runs.
<sladen> Keybuk: right, fade on shutdown worked.  Bootup takes 2:20 from Grub finishing.  4 seconds textmode, 2 seconds cleared textmode (cursor blinking), 20 seconds usplash (no action, no throbb, no nothing), 9 seconds text mode "calling settle", 5 seconds blank text mode (again), 4 seconds blank/black graphics mode, 1 second busy cursor, 1 second nothing, 13 seconds Xsplash, GDM ... 12 seconds Xsplash, 13 seconds semi-desktop, 8 seconds Panels, 37 seonds Panel
<Keybuk> sladen: bootchart
<sladen> Keybuk: http://www.paul.sladen.org/ubuntu/karmic-20091018-2.png
<chrisccoulson> siretart - that gnome-screensaver patch makes the assumption that the MIT-SCREEN-SAVER extension is always available, which might not always be the case
 * sladen stars at the couchdb forkbomb "wtf"
<chrisccoulson> if it's not, then gnome-screensaver will just crash instead
<Keybuk> sladen: yeah you have the I/O problem of death
<siretart> chrisccoulson: oh, can you perhaps improve the patch to check for that extension?
<Keybuk> sladen: 4200 RPM hard drive?
<slangasek> sladen: you should purge the couchdb package
<slangasek> it's not installed by default
<slangasek> (it was earlier in the cycle, then the package was split for this exact reason)
<Keybuk> sladen: if you look at the chart, you're basically in I/O wait the entire time
<Keybuk> (top graph mostly red)
<Keybuk> but while there's always something on the I/O queue (bottom graph mostly red), you're achieving almost no throughput from your hard drive (green line almost flat)
<Keybuk> if you want a challenge, figure out why!
<chrisccoulson> siretart - i'll have a look if i get the chance, but the patch doesn't really look right anyway. gnome-screensaver currently gets session idle-ness from gnome-session, which uses the SYNC extension and IDLETIME counter. applications which want to inhibit the screensaver should really be the gnome-session inhibit API now, although it would be nice to get gnome-screensaver to work correctly too
<chrisccoulson> anyway, dinner time for me
<sladen> Keybuk: right, so the lack of I/O is the reason that usplash does not throb?
<Keybuk> sladen: no...
<Keybuk> nothing went PULSATE at it I guess
<sladen> Keybuk: whilst I can make do with bootup taking twice as long as jaunty, I'd like it not to look rubbish
<siretart> chrisccoulson: is there some migration documentation? The vlc developers seems pretty confused about this bug and I'd like to help them to understand the issue...
<Keybuk> sladen: I'd rather we figured out why this has got so bad
<Keybuk> than wasted time with pixels
<siretart> slangasek: based on chrisccoulson comments, I please reject my gnome-screensaver upload :(
<Keybuk> from my POV, screenfuls of random text that are only visible for a few seconds is better than something pretty that lasts an hour
<Keybuk> sladen: you didn't confirm your drive, btw?
<Keybuk> sladen: could you paste me your model number, I'm collecting some data on who's affected
<sladen> Keybuk: no idea, but it's HDD, not flash
<slangasek> siretart: ok, rejected
<Keybuk> sladen: cat /sys/block/sda/device/model
<elmo> hey, is there a wiki page on bootcharting?  my karmic boot is horrific, and I'd like to generate pretty pictures once I purge some of the non-desktop packages
<sladen> Keybuk: ST980825AS
<sladen> elmo: sudo apt-get install bootchart
<Keybuk> sladen: interesting
<elmo> sladen: that's it? :-P
<sladen> elmo: then reboot and look in /var/log/bootchart/*
<elmo> ok
<slangasek> chrisccoulson: incidentally, after upgrading gnome-screensaver last night, this morning I came to a hung 'time expired' dialog... did this "who kills the child" change get tested to DTRT for running instances of gnome-screensaver?
<Keybuk> sladen: that's 7200RPM with a 10.5ms seek
<Keybuk> that's a *fast* drive
<Keybuk> something's seriously fucked there
<Keybuk> sladen: could you upload your dmesg somewhere
<sladen> Keybuk: http://www.paul.sladen.org/ubuntu/karmic-20091018-2.dmesg.txt
<Keybuk> sladen: one thing to try
<Keybuk> boot with break=bottom
<Keybuk> stick deadline into /sys/block/sda/queue/scheduler and then ^D to continue the boot
<Keybuk> see if your chart looks better
<Keybuk> sorry
<Keybuk> break=top :)
<Keybuk> (you may have to mount/unmount sys)
<Keybuk> sladen: nothing in dmesg suggests a DMA problem or anything
<Turl> hello
<Turl> in a bootchart I just made I can see gnome-session taking a *lot* of time to launch things http://ubuntu-pics.de/bild/27825/laptop_karmic_20091018_1_uY9yMi.png
<Turl> any ideas why?
<Keybuk> Turl: uninstall couchdb
<Turl> why Keybuk?
<Keybuk> Turl: that's what's causing your problem and you don't need it
<Turl> why is it included by default then?
<Keybuk> it isn't
<Keybuk> we did for a while during the development phase, but the package has now been split apart
<Keybuk> apt-get remove --purge couchdb
<Keybuk> should do it
<Turl> mhm, I shouldn't have removed everything that had couchdb on its name ^^
<Turl> reinstalling desktopcouch should reinstall it right?
<Keybuk> right ;)
<Turl> done :)
<Turl> any other thing I should remove/add to gain more performance?
<Turl> I'm using karmic since alpha 5/6 iirc
<Keybuk> you have a bug we're trying to track down too
<Keybuk> that's going to be my #1 task for all of next week
<Turl> what bug Keybuk?
<Turl> I can help with testing if you need :)
<Keybuk> 432089
<Keybuk> bug 432089
<ubottu> Launchpad bug 432089 in sreadahead "performs poorly on slow HDD" [High,Triaged] https://launchpad.net/bugs/432089
<Turl> yep my disk is a bit slow
<Turl> Keybuk: do you know if gnome power management bugs are high priority?
<Turl> I reported one, https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/228932 but it is set to low
<ubottu> Launchpad bug 228932 in gnome-power-manager "Gnome Power Manager doesn't show battery tab if accumulator isn't inserted" [Low,Confirmed]
<Turl> and IMO, it's high importance as it can cause data loss and system damage
<Trewas> actually I just tested and sreadahead seems to improve boot speed, 80s with it and 120s without (5400rpm laptop disk)... however I only tested once without sreadahead
<Keybuk> Turl: out of my remit
<Keybuk> Trewas: yeah, it's that it doesn't *really* improve it, or *always* improve it
<Keybuk> with sreadahead I'm looking for a particular shaped I/O graph that we're not achieveing
<Keybuk> something in the kernel is defeating I/O performance
<mdke> slangasek: just uploaded a new gnome-user-docs with new translations, in due course could I call on you to do your NEW dance for the new binaries?
<Trewas> yeah bootchart shows that I/O is very slow and the processor is mostly waiting, and this is a slow atom
<ion> su224300 < Turl> any other thing I should remove/add to gain more performance?
<ion> Gnome for starters ;-)
<Turl> ion: nah :P
<LLStarks> keybuk, is there any chance that pulsing logo from the casper environment can be implemented for installed systems. also, do you find it acceptable that the usplash on an installed system shows no indicators of progress even if it takes 30 or more seconds for the usplash to be passed on a slower system?
<Keybuk> LLStarks: I find it unacceptable that it takes 30s at all
<Keybuk> I'd rather spend my time fixing that
<LLStarks> http://img38.imageshack.us/img38/5394/kingfisherkarmic2009101.png
<LLStarks> take a look at my bootchart.
<LLStarks> 17 seconds of usplash.
<LLStarks> 54000 rpm drive
<slangasek> chrisccoulson: the 'time expired' hang is reproducible even after restarting gnome-screensaver; we've got a regression here
<LLStarks> keybuk, i don't expect you get a system without a solid-state drive down to 10 seconds, but this is ridiculous.
<Keybuk> LLStarks: you have the exact same I/O performance bug as sladen
<Keybuk> you're getting almost no throughput on your drive
<Turl> Keybuk: also, if fsck checks the disk, usplash stays there and there's no written indication that the disk is being checked
<Keybuk> yes there is
<Turl> so you wonder what's going on
<Keybuk> grab the mountall package from the ubuntu-boot PPA
<Keybuk> that'll be in the final release
<Turl> Keybuk: the last time it checked my disk, there was none
<Keybuk> you didn't have that installed
<Turl> mhm, can you link me to the ppa?
<Keybuk> yes.
<Keybuk> PPA
<Keybuk> err
<Turl> nevermind, found it :)
<Keybuk> http://launchpad.net/~ubuntu-boot/archive/++A
<Keybuk> http://launchpad.net/~ubuntu-boot/archive/+ppa
<Keybuk> even
<LLStarks> keybuk, link to bug?
<Keybuk> llstarks: bug 432089
<ubottu> Launchpad bug 432089 in sreadahead "performs poorly on slow HDD" [High,Triaged] https://launchpad.net/bugs/432089
<LLStarks> what kind of boot times can i expect with the ppa package?
<Keybuk> the PPA package isn't about boot times, it's about fsck progress notification
<Keybuk> you're crossing threads
<Turl> Keybuk: what happened to the graphical OS selector that karmic was suppoused to bring?
<elmo> Keybuk: http://people.canonical.com/~james/tuna-karmic-20091018-1.png
<Keybuk> Turl: unknown, not my dept
<Keybuk> elmo: yup, same thing :-(
<Keybuk> elmo: I wish I knew what causes it
 * Turl reboots
<LLStarks> bbiab
<chrisccoulson> slangasek - i'll tty and reproduce that g-s-s hang now
<slangasek> chrisccoulson: thanks
<slangasek> mdke: yep, I'll be here for the NEWing when needed
<chrisccoulson> slangasek - i can't recreate it here. i get the "timeout has expired" message, and then the dialog goes away
<chrisccoulson> any chance you could get a backtrace of both processes after it appears to have hung?
<slangasek> chrisccoulson: sure; it'll be a few minutes
<chrisccoulson> no worries, thanks
<mdke> slangasek: :)
<LLStarks> keybuk. here's my bootchart with the newer mountall.
<LLStarks> http://img32.imageshack.us/img32/5394/kingfisherkarmic2009101.png
<joaopinto> LLStarks, <Keybuk> the PPA package isn't about boot times, it's about fsck progress notification
<LLStarks> i know
<LLStarks> but how would he know that my machine was affected?
<ion> keybuk: progress[61] = '\0'; should be progress[60].
<slangasek> chrisccoulson: bug #454959 with backtraces
<ubottu> Launchpad bug 454959 in gnome-screensaver "after latest update, 'time expired' dialog hangs indefinitely, has to be hard-killed from the consol" [Undecided,New] https://launchpad.net/bugs/454959
<chrisccoulson> thanks
<slangasek> chrisccoulson: including a likely pointer to why it's not reproducible for you
<joaopinto> LLStarks, becaue your symptom matches the bug already reported
<joaopinto> because
<LLStarks> okay
<LLStarks> next topic. can we get this bug elevated?
<LLStarks> https://bugs.edge.launchpad.net/firefox/+bug/438868
<ubottu> Launchpad bug 438868 in firefox "Address bar autocomplete doesn't always work" [Unknown,Confirmed]
<LLStarks> this is a very visible bug and i think asac needs help.
<ion> keybuk: The PPA version crashed with an assertion in nih_free with ctx->destructor != NIH_ALLOC. I bet the progress[61] write happened to overwrite that pointer. :-)
<chrisccoulson> slangasek - i found an issue with my patch
<chrisccoulson> it seems that SIGTERM might be raised to quit the dialog after the main loop has already quit, which will probably make it hang like you describe
<bdrung_> ScottK: i will let you know if we have something usable
<slangasek> chrisccoulson: ah, ok
<slangasek> chrisccoulson: I'm happy to test a patch
<lifeless> slangasek: hi
<lifeless> slangasek: are you aware of the bug with intel graphics sluggishnish + corruption ?
<lifeless> slangasek: if so, is it a release blocker, if not, whom should I talk to to make it more widely known ?
<sladen> Keybuk: still ~100 seconds with echo deadline > .../sda/queue/scheduler  do you want to see the chart
<Turl> Keybuk: hi
<Turl> Keybuk: that mountall left my system unbootable T_T
<slangasek> lifeless: no, I've not heard of such a bug
<Turl> Keybuk: usplash appeared, then it said sth like "/ waiting on /dev/..../by-uuid/...., /home waiting on /dev/...., /temp waiting on (null) press esc for a recovery console" and esc did nothing
<slangasek> not counting the "Xorg eats 100% CPU because upstart stole its controlling tty" bug
<Turl> rebooted, and the same thing happened
<lifeless> slangasek: not that bug, no.
<slangasek> lifeless: bug #?
<Turl> so I reverted it to the karmic one and I'm using it now
<lifeless> slangasek: digging, sec
<Turl> slangasek: you published the mountall package on the ubuntu-boot ppa right?
<slangasek> Turl: no
<Turl> oh, it was Keybuk, sorry :P
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/421232
<ubottu> Launchpad bug 421232 in xserver-xorg-video-intel "Sluggish performance on Intel video card" [Undecided,Confirmed]
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/454984
<ubottu> Launchpad bug 454984 in xserver-xorg-video-intel "graphics corruption occuring with normal use" [Undecided,New]
<lifeless> slangasek: ^
<lifeless> the corruption bug I just filed because I saw there didn't seem to be one for it
<slangasek> lifeless: I think it's pretty clear that you should open a new bug report for your performance issue, since you say you started seeing it on Thursday and the original submitter filed his report back in August
<slangasek> lifeless: a list of what packages were upgraded for you on Thursday would be helpful, as well as information about what chip you actually have
<lifeless> slangasek: that was thursday a week back
<lifeless> slangasek: right after bryce announced mesa 3
<slangasek> lifeless: a week back was still not August ;)
<lifeless> slangasek: ack; filing new bug.
<Turl> lifeless: my graphics performance on intel seems to have decreased recently, I don't know the exact date though
<Turl> but compiz feels more sluggish
<chrisccoulson> slangasek - would you mind testing http://paste.ubuntu.com/296366/ please?
<chrisccoulson> the issue seems to be that when the dialog times out, it quits the main loop, and raises SIGTERM if there are still any PAM threads. the SIGTERM does nothing because i registered a handler which quits the main loop (which has already quit)
<chrisccoulson> i think that's what causes your hang
<dtchen> pitti: ok, i fixed your mute issue harder.
<lifeless> slangasek: I've got another corruption bug a friend of mine is reporting; its suspend related but a regression.
<lifeless> slangasek: [I'm taking advantage of your being online to talk about this :P]
<slangasek> lifeless: yah, I can confirm bug #454984 here (done so in the bug report now)
<ubottu> Launchpad bug 454984 in xserver-xorg-video-intel "graphics corruption occuring with normal use" [Undecided,New] https://launchpad.net/bugs/454984
<slangasek> lifeless: suspend-related> new bug report?
<lifeless> slangasek: intel card, when the user comes out of s2 gets corruption of a different sort
<slangasek> chrisccoulson: something better than a pastebin for a patch, please?
<slangasek> chrisccoulson: there's a bug open, you could upload it there :)
<slangasek> lifeless: s2, not s3?
<slangasek> (do we even have quirk handling for s2?)
<chrisccoulson> slangasek - i've attached the patch to the bug report as well now
<slangasek> chrisccoulson: building now
<slangasek> and testing now
<chrisccoulson> thanks
<m3ga> lifeless asked me to log a bug about xserver-xorg-video-intel : https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/454999
<ubottu> Launchpad bug 454999 in xserver-xorg-video-intel "video corruption after coming out of s2disk" [Undecided,New]
<slangasek> chrisccoulson: how long is the dialog timeout?
<slangasek> oh, there it goes
<slangasek> chrisccoulson: yep, confirmed fixed
<chrisccoulson> excellent, thanks for testing
<chrisccoulson> do you want to upload this once i've pushed it to bzr?
<slangasek> (at least, with a sample size of 1)
<slangasek> chrisccoulson: can do
<chrisccoulson> cool, thanks
<slangasek> m3ga: what does "s2disk" mean?  Are you using the standard hibernate functionality in GNOME, or does this refer to some other utility?
<slangasek> m3ga: IIRC, s2disk is the name of a program provided by uswsusp?
<chrisccoulson> slangasek - i've pushed it here: https://code.edge.launchpad.net/~ubuntu-desktop/gnome-screensaver/ubuntu
<slangasek> chrisccoulson: got it
<chrisccoulson> thanks
<m3ga> slangasek: suspend to disk
<slangasek> m3ga: yes, by what means?
<m3ga> yes provided by uswsusp.
<m3ga> running "sudo s2disk"
<m3ga> in an xterm
<slangasek> ok, I'm going to reassign this bug to uswsusp then
<slangasek> unless you can reproduce this using pm-utils' hibernate mode?
<slangasek> (sudo pm-hibernate)
<m3ga> then i probably need to file a new bug about sluggish performance.
<slangasek> chrisccoulson: uploaded
<slangasek> m3ga: sluggish performance of what? pm-hibernate?
<slangasek> (I think that bug's been filed a few dozen times before)
<m3ga> x server has been sluggish in karmic for about 2 weeks
<slangasek> ah
<m3ga> i thought it was bug 421232 but lifeless seems to think it needs a new bug
<slangasek> m3ga: can you please check whether this problem is reproducible with 'sudo pm-hibernate' instead of 'sudo s2disk'?  That will let us establish whether it should be treated as a driver bug, or if uswsusp is missing quirk handling that pm-utils knows about
<ubottu> Launchpad bug 421232 in xserver-xorg-video-intel "Sluggish performance on Intel video card" [Undecided,Confirmed] https://launchpad.net/bugs/421232
<m3ga> ok, i'll lose my xchat session but i'll be back
<slangasek> m3ga: 421232 has a generic description and was reported months ago - it's far better to file a new bug report and let the triagers decide whether it's the same bug
<m3ga> will do
<lifeless> thanks slangasek
<slangasek> sure
<m3ga> slangasek: 'sudo pm-hibernate' causes similar screen corruption.
<slangasek> m3ga: ok, thanks for confirming
<m3ga> before it did it I restarted x server and it was fine.
<m3ga> ie no corruption before pm-hibernate' corruption after
<m3ga> slangasek: you want the sluggish perf bug report now or can that what til my evening (9am here).
<m3ga> s/what/wait/
<slangasek> m3ga: I'm not the person who's going to be triaging it anyway, I'm sure it can wait if you have other things to do
<m3ga> i'll do it this evening. its monday morning and i'm at work :-)
<slangasek> mdke: gnome-user-docs's build-dependency is on *both* iso-codes *and* isoquery; but it's only used for regenerating debian/control, which shouldn't happen at package build time, so can be ignored
<slangasek> mdke: but if you're going to put it in build-depends, it should be both packages (which is what I tried to do in the previous upload, but then I regenerated debian/control right over myself)
<slangasek> dtchen: how is this alsa-utils change supposed to fix a race condition?
<dtchen> slangasek: apparently alsactl store was being called at odd times during reboot/shutdown, resulting in muted slevels
<dtchen> ugh, lag
<dtchen> slangasek: anyhow, the previous change in ubuntu5 was broken, so it's definitely a regression from 8.10 and 9.04
<slangasek> dtchen: and how do you figure that this isn't also "at odd times"?
<dtchen> slangasek: it can only be called once
<slangasek> how is that different from the init script, which only shows up once in /etc/rc6.d?
<dtchen> slangasek: asound.state was not being written to /var/lib/alsa
<dtchen> slangasek: i can't reproduce it on my machines; maybe their disks are too slow
<slangasek> so you don't actually have any evidence that there was a race
<slangasek> or that this will fix it?
<slangasek> sysvinit scripts are handled *serially* in Ubuntu, and upstart jobs are handled in *parallel*.  if anything, you've increased the chance of a race condition here
<dtchen> i'm waiting for gmail to load so i can dig up the bug report
<slangasek> ok
<slangasek> I'm afk for a few hours, but if there's a bug report that explains how this is a race, please throw it at me while I'm out
<dtchen> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/352732/comments/63
<ubottu> Launchpad bug 352732 in pulseaudio "[jaunty] Sound muted after boot" [Undecided,Confirmed]
#ubuntu-devel 2010-10-18
<YokoZar> Are the canonical folk gonna be at an all hands meeting this week?  I'd hate for my "0-day" maverick SRU to take another 2 weeks to go through
<persia> I don't think those are closely related.  Anyone in https://launchpad.net/~ubuntu-sru/+members can approve an SRU.
<persia> And I don't believe the archive-admin portion requires shell access.
<persia> How is the verification proceeding?  That's usually the biggest blocker.
<ScottK> I can accept packages into -proposed if ubuntu-sru approves it.  Copying from -proposed to -updates needs shell access AFAIK.
<poolie> YokoZar: if by 'this week' you mean this week now, then there's no allhands afaik
<poolie> can i apply for a per-package-upload permission for 'bzr*' (conceptually or literally)
<persia> poolie, Yes and Yes.
<persia> Best to prepare an application, and get support from a few folks before you file.  There's little less embarrassing than having an application fail because everyone thought someone else was going to say something nice about you.
<poolie> :)
<poolie> i'm drafting it now, then i'll call in my favors
<persia> But be aware that bzr* would be expanded at application time: changes over time would require manual action.
<poolie> i wondered if i had to manually list all the packaged plugins
<poolie> sure
<persia> The person implementing it has to manually list all the packaged plugins.  If you want to make the LP API easier before you apply so that this isn't required... :)
<poolie> 'rdepends bzr' is close to it, though not quite all of them are needed
<persia> I hope not.  There's stuff in that list which I'd have some reservations about granting to someone based on their experience with bzr alone.
<persia> Note that successful applications typically have a couple examples of prior uploads (to Ubuntu or Debian) for any of the packages included in the set.
<persia> You might get away with significant upstream work in those packages, but it's unlikely that you'd be granted access to something for PPU without some demonstrable prior involvement, given the lack of social groups related to PPUs.
<poolie> sure, that makes sense
<YokoZar> persia: it's been verified for a while now
<persia> Hrm.  Needs one of the SRU folk to poke it then.
<poolie> persia, i drafted https://wiki.ubuntu.com/MartinPool/DeveloperApplication
<poolie> i'll just see about getting some endorsements or feedback and then propose it
<pitti> Good morning
<ion> that.
<pitti> cjwatson, slangasek: FYI, I updated "sru-release" to also copy to devel release if the final/-updates versions matches the devel release
<dholbach> Good morning!
<\sh> moin
<geser> good morning
<dholbach> hi geser
<dholbach> tumbleweed, thanks for your work on the sponsoring overview
<dholbach> tumbleweed, I added a few comments
<tumbleweed> dholbach: np, yeah I must respond :)
<tumbleweed> when I get to my desk...
 * dholbach hugs tumbleweed
<dholbach> thanks a lot tumbleweed
<tumbleweed> :)
<geser> Could an ubuntu-devel-announce moderator please let my minutes pass? Thanks.
<pitti> geser: will look
<pitti> geser: done
<pitti> cjwatson, slangasek: I uploaded postgresql-common to hardy/lucid for bug 661061; do you have a minute for a review in the next days?
<ubottu> Launchpad bug 661061 in postgresql-common (Ubuntu Hardy) "pg_createcluster silently deletes existing cluster" [High,Fix committed] https://launchpad.net/bugs/661061
<Laney> I think the libgpod sru needs copying to natty
<SpamapS> heh.. is it bad when a USB HD starts sounding a lot like a 1940's typewriter?
<ogra_ac> depends ... did you put a sheet of paper in ?
<SpamapS> No, but I did copy a bunch of things with icons that look like sheets of paper to it!
<ogra_ac> aha !
<ogra_ac> dont forget to also copy some ink tape then ;)
<SpamapS> your wisdom will save my USB HD/typewriter ogra.. thank you...
<ogra_ac> lol
<cjwatson> Laney: can/should it wait until the SRU is validated and it goes to -updates?  (otherwise, would prefer it to be acked by the uploader, who appears to be hyperair)
<TLE> pitti: hallo, I'm Kenneth, I'm working with dpm on the regular language pack update specification, do you have a minute?
<hyperair> cjwatson: i'm assuming that you mean banshee?
<pitti> TLE: hello!
<TLE> hey
<TLE> do you have time for a few questions?
<hyperair> speaking of which i need people with ipods to test libgpod in -proposed
<cjwatson> hyperair: 12:07 <Laney> I think the libgpod sru needs copying to natty
<pitti> TLE: just shoot
<TLE> great
<hyperair> cjwatson: ah. if you have an iPod could you do the test case?
<TLE> I'm just gathering information for use during the UDS session, one thing to consider is how many update cycles we want, during first 6 months and possibly after
<TLE> One thing that I am wondering there
<TLE> is how much work it involves for you to push a set of newly build language pack to the proposed repository
<TLE> the reason I'm wondering is, that if it is very easy, then maybe we can affort to offer more update cycles than the teams will in general use
<TLE> pitti: ^^
<dragonlord> hi there
<dragonlord> i made recently an update to 10.10 and now gnu-smalltalk is gone breaking things
<dragonlord> trying to reinstall gives "missing package" and "gnu-smalltalk being virtual" error
<dragonlord> looking at http://packages.ubuntu.com/search?keywords=gnu-smalltalk I noticed gnu-smalltalk is missing "amd64" in maverick
<dragonlord> any chance to build this package and making it available?
<pitti> TLE: the human effort to build and upload new langpacks is very low
<pitti> TLE: it's a significant hit on the builder machines
<pitti> TLE: but the primary limitation here is testing
<pitti> and we don't want to overdo those updates because we can't possibly test every string
<pitti> but every string change can potentially be a regression
<dragonlord> it's just a bit strange since it seems "some" packages in gnu-smalltalk are "all" and include amd64 but not the "gnu-smalltalk" package itself
<TLE> pitti: yes ok
<dragonlord> seems to affect only "gnu-smalltalk" package but unfortunately that's the one containing the lib to link against
<dragonlord> what you think, how long it typically takes for an amd64 package to arrive?
<TLE> pitti: I realize that testing is a bottleneck. What I was hoping is that we could change the way we think about the language pack updates a bit. So in stead of thinking, we do 4 language pack updates per cycle, and if only very few teams manage to test and have one released then there are to many and testing is the bottle neck
<pitti> TLE: we can release them individually
<pitti> TLE: in the previous couple of rounds we collected feedback for some time, and then released the languages we got feedback on
<TLE> pitti: then in stead we could say, we give you the _opportunity_ to release a language pack so and so many times, if you don't have fixes important enough to warrant using time on testing then that is fine and we just wont release one for your language for this cycle
<pitti> TLE: right, that's pretty much what happened
<TLE> pitti: ok, great, but then I think the idea of this schedule should work just fine
<TLE> pitti: but that also means that if we want to in principle give language teams the opportunity to release a langauge pack update after the first 6 months, then there are 2 ways that we could do it
<pitti> TLE: after that we should probalby switch that aronud and only do them on request?
<TLE> pitti: we could just include them in the schedule, and if only very few uses them, then that is ok, but we could also work towards making the late update per request
<TLE> yes, that is an options as well
<TLE> exactly
<TLE> pitti: great, I just needed a little of your input, I'll add some more info to the discussion section of the specification and then we can talk more about specifics at the UDS session
<pitti> TLE: cool, thanks!
<TLE> pitti: thank you
<cjwatson> hyperair: I don't
<cjwatson> hyperair: Laney was asking me a question as an archive admin rather than as somebody who cares particularly about libgpod
<Laney> cjwatson: I thought it was routine that uploads were copied as they went into -proposed, as a point of procedure
<Laney> if not, don't worry
<hyperair> Laney: ?
<Laney> what?
<hyperair> nevermind
<BUGabundo> eheh you scared him off
<ari-tczew> does armel builds working?
<ari-tczew> I've recived a lot of mails about armel FTBFS.
<ogra_ac> so the buildds are obviously working
<ogra_ac> check the logs and fix them ;)
<ari-tczew> ogra_ac: I'm not going to do this - no knowledge, no time.
 * ogra_ac only sees very few ftbfs that are actually armel specific on http://qa.ubuntuwire.org/ftbfs/
<ogra_ac> 5 in main so far
<ogra_ac> 57 in universe
<ogra_ac> but the majority fails on all arches anyway
<kurrata> hi i made .deb package and made it so icon shows under "start menu" thingy. But it is under section other not games.  http://codepad.org/xIb475Fe .desktop file
<cjwatson> Laney: currently, we're doing them on the way into -updates, although that procedure is new
<Laney> ok
<seb128> cjwatson, seems to not really make sense
<seb128> you usually want things tested before they go to updates
<seb128> it seems it would rather make sense to copy them before the testing period to increase the chances to catch an issue
<Chipzz> kurrata: you want #ubuntu-app-devel (cfr topic)
<kurrata> koey, thanks
<cjwatson> seb128: possibly, yeah, I was just describing current state
<cjwatson> personally I find copying from -updates is a no-brainer, copying from -proposed I sometimes have to think about
<seb128> pitti, ^ didn't you use the pocket copy directly things?
<seb128> cjwatson, why do you have to thing about? if the version match just pocket copy
<pitti> seb128: I did; it's easier to do it at the time when you move stuff to -updates, though
<pitti> (which now happens automatically, with this morning's sru-release update)
<seb128> well we lack the testing on unstable before copy though
<pitti> otherwise you'd have to go through all of them twice
<seb128> sru rules used to be "get the fix in unstable before doing the sru"
<pitti> not sure how many folks test natty at this time, though
<cjwatson> still are, we only bend that at the start of release cycles
<seb128> which we relaxed to "if versions match let's pocket copy when it's accepted"
<pitti> seb128: right, but we can copy them unchanged to natty, so they won't get lost
<cjwatson> thus I don't think it really matters because hardly anyone tests the unstable release at the start of cycles
<seb128> ok, fair enough
<seb128> it just seems copying before the testing period than after would be no work difference and be better
<pitti> that said, http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html looks way smaller than I feared :)
<pitti> seb128: I agree; it's just twice the amount of work
<seb128> pitti, because you need to wait for the binaries to be available to copy?
<pitti> right
<pitti> which includes powerpc/armel
<seb128> alright
<pitti> and in the past couple of days that would have meant "three days"
<cjwatson> right, and if you get that wrong by mistake it's hard to undo :-(
<pitti> seems the builds calmed down now
<pitti> tseliot: is nvidia 173 supposed to work on maverick?
<tseliot> pitti: yep
<pitti> tseliot: ok, thanks
<tseliot> np
<jcastro> robbiew: who is responsible for approving blueprints in "other"?
<robbiew> jcastro: no one that I know of....though I've approved other- submitted by my team
<robbiew> jcastro: why?
<robbiew> what do you need?
<jcastro> they're just piling up
<robbiew> damn it...I nominate allison :)
<jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n/+settopics
<jcastro> this page is getting huge
<robbiew> rickspencer3: ^^^^^
<jcastro> and we barely have anything scheduled because no one is approving specs
<rickspencer3> fudge
<jcastro> (linaro's bp's are all messed up, I'll fix them though, that one's easy)
<jcastro> pgraner and leann are unavailable so apw's taking care of hardware, multimedia will be fine when asac returns
<jcastro> rickspencer3: robbiew: also, summit now won't schedule things unless they're both approved and named right.
<jcastro> this was the price for automagic colorization and scheduling without having track leads in the admin UI for hours.
<robbiew> jcastro: by "approved" you mean the check mark by UDS-N, right?
<jcastro> yup
<jcastro> robbiew: here's what I'm telling people in our track "here's the naming convention, it's on YOU to name it right, if jono doesn't approve or decline in a day or so ping him."
<jcastro> that seems to work
<robbiew> yeah
<jcastro> the people who schedule the sessions should be doublechecking that they hit the schedule, there's no way we can expect a track lead to check all those sessions by hand
<robbiew> exactly
<jcastro> and daviey and I can catch the occasional straggler
<Daviey> !
<jcastro> Daviey: you can still grep the orphans right?
<Daviey> jcastro: yes
 * ogra_ac wonders if we will have many tracks beyond "other" after all :P
<jcastro> Daviey: if you want to cron it to mail me the broken tracks that'd be fine
<Daviey> jcastro: I can do that
<jcastro> Daviey: not yet please, I need to fix linaro, they've named everything different
<Daviey> jcastro: currently only - appselection-n-thunderbird-on-ubuntu
<Daviey> gdb-replay
<Daviey> server-natty-lxc-production-ready
<Daviey> ^^ nothing else is showing as trackless / orphane
<Daviey> +d
<jcastro> k
<ogra_ac> mvo, the number computation for installs in sw-center seems to be slightly wrong ... do you have a bug open for that already ?
<ogra_ac> (installing the addons fro the TI PPA talks about downloading 80GB ... thats slightly scary)
<mvo> ogra_ac: woah, indeed - I wonder if that is a long long problem on arm or is that on i386?
<ogra_ac> arm indeed
<ogra_ac> updates seem to also go into the 700MB area :)
<ebroder> Hmm...is it part of the API guarantee that /usr/share/debconf/confmodule uses fd 3 for communicating with debconf?
<ScottK> dyfet: Would you please merge gcl.  It's blocking other builds.
<antileet> Hi jcastro, do you have a minute?
<apw> jcastro, hey how and who is renaming blueprints?  one of mine just got a mad prefix added ... one that doesn't even need a session ... any idea how i can fix it?
<apw> all this renaming is causing havock with any chance of tracking whether ones team has done their 'prints given they keep moving
<fagan> apw: there are a few people renaming them I think there was an email sent around to explain it
<fagan> <track>-<team>-<uds>-<title> if I remember right
<apw> fagan, yep, they got renamed once and i had to find them, and now they are moving again
<ogasawara> apw: pgraner just mentioned to me that the "other" track had too many blueprints assigned and was breaking the summit system So asked if I could move any "other-kernel-*" named blueprints to "hardware-kernel-*".
<ogasawara> apw: but I only touched three of em:  the kernel misc blueprint, the bughandling, and stefan's stable testing
<fagan> that would explain it
<apw> ogasawara, heh your fault huh :) i moved the misc one to none- as it doesn't have a session
<fagan> apw: you could find them in your blueprints list again
<ogasawara> apw: I think I'll just stop touching the blueprints all together, I'm confused about them as it is
<apw> fagan, yeah thats all very well in theory, but in practice most don't belong to me, they belong to one of 20 people
<fagan> ah yeah that would be a problem
<apw> ogasawara, its a merry nightmare for sure
<apw> its ok if they are correctly targetted to natty, but if not they just dissappear
 * fagan is suprised how many blueprints are actually made and never ever looked at 
<fagan> we need some way of expiring really old blueprints too
<sille777> Hello all
<sille777> Just referred here from #ubuntu
<sille777> I seem to have a bug with Chromium and Maverick
<persia> sille777, Tell us a bit about it, and maybe we can help, or send you to a better place.
 * fagan has a bit of experience with chromium in maverick 
<sille777> Persia - Chromium will not start... I reinstalled and same thing...I tried to start from command line and ...
<fagan> sille777: use pastebin.ubuntu.com please
<persia> No, that's a bug.
<persia> Please file a bug with `ubuntu-bug chromium-browser` and follow-up in #ubuntu-bugs.
<fagan> ah ok
<sille777>  Attempting to load the system libmoon  Segmentation fault (core dumped)
<sille777> ok
<fagan> sille777: sudo apt-get remove libmoon
<fagan> that should get it working
<persia> fagan, 1) that's a big hammer, and may hide an easily fixable issue, 2) this isn't a support channel.
<fagan> yeah I know I just thought I should offer up the solution
<persia> Yeah, but that's not a solution: it's a workaround, and perhaps not even a good one.
<sille777> Bug has been reported
<persia> sille777, Thanks.  Please follow-up on #ubuntu-bugs, and I'm fairly sure that folk there can help you find the root of the problem, and a solution or at least a good workaround.
<fagan> persia: Well I had a few issues with moonlight in the repo so I used to grab it from the website instead because it was up to date
<sille777> Bug# 663007
<sille777> Thank you for your help persia!
#ubuntu-devel 2010-10-19
<hicham> usb-creator doc is in ubuntu-docs package ?
<GanonKiller> were gps drivers made for meerkat?
<persia> There are usually some in the archive.  I'm unsure how heavily tested they are.  I would expect maverick to have slightly more coverage than lucid in that regard.
<persia> I'd recommend either asking in #ubuntu for your specific hardware, or testing your specific hardware with a LiveCD, and if it doesn't work, filing a bug and following up in #ubuntu-bugs.
<GanonKiller> #ubuntu aint helping.. too many people
<GanonKiller> thats why i was asking if any were developed... i have a old PCMCIA GPS Card
<RAOF> The easiest way to find out is to boot a 10.10 live cd, and see if it's detected.
<persia> I don't know which GPS chipsets happen to be supported, and this isn't a support channel.  Really, your best bet is test with a LiveCD, and if it doesn't work, report a bug and use that as a place to discuss getting support working.
<GanonKiller> am looking on support sites.. but no luck
<ion> Hardy herons? http://4.bp.blogspot.com/_yu-22ZXfW0E/TKZtXqQ54SI/AAAAAAAAAnI/80V_hfVFN7c/s1600/herons.jpg
<pitti> Good morning
<ajmitch> morning pitti
<micahg> python-numpy is FTBFS because it now use python-matlibplot to buildk the docs, is it better to make an MIR for matlibplot and its build-deps or to not build the docs (or another option)?
<persia> micahg, if doing an MIR would increase the install-time set, it needs real thought.  If it's just the build-time set, it's worth looking through the MIR process, and if there's no obvious reason the package would fail, process the MIR.
<micahg> persia: the doc is only suggests, so no install-time issue, but matlibplot has a lot of universe build-deps
<persia> Worth a look.
<persia> The MIR process is mostly so that we know anything in main has an acceptable level of maintenance effort and can sanely receive security support.
<micahg> persia: so that means going through each of the build deps and looking if they require a lot of universe packages?  how much recursion is too much in this case?
<persia> We, alas, don't have any process to *ensure* things stay that way, but that's different.
<persia> And we probably need a new way to handle "code-review-passed" in the face of Archive Reorganisation anyway.
<persia> micahg, recurse to the point of frustration.  If you're still motivated enough to keep doing it, you aren't doing too much.
<persia> As soon as it feels like it's not worth it, it's probably not.
<micahg> I guess 14 packages doesn't look so bad and some of them are probably from the same source
<persia> Note that it's worth considering that all of them will need at least a code review and security review: it may take a while.
<dholbach> Good morning!
<lifeless> cjwatson: +1 on libpipeline
<cjwatson> lifeless: :-)
<mvk> how do we get into Ubuntu/Kubuntu development, we would like to add geolocation to the timezone screen for the installation
<mvk> so we need to modify the 'setup', were do we start?
<mvk> this here https://help.ubuntu.com/community/InstallCDCustomization says that its 'The process of customizing or "remastering" Ubuntu installation CDs is not especially complex, but it is a little tedious and finicky.'
<mvk> but we need to create a production stable image after modification!
<mvk> how does one commit patches for the ubuntu-installation?
<apw> mvk, normally you need to find the package within which the changes are to be and add the patches to that package
<mvk> hi
<mvk> apw: what packages does the installer (screens) reside in?
<apw> mvk, (not being an expert on that side I am guessing some) but that might be casper
<mvk> do they even exist in the repos
<mvk> or just on the cd images
<apw> everything on the CD is in the archive in a package
<mvk> (extracked, i doubt they are .deb packages)
<apw> (as far as i know)
<mvk> ow
<apw> mvk, i would suspect the people who know are hanging out on #ubuntu-installer
<mvk> now thats a nice pointer, thanks apw
<apw> mvk we try
<apw> mvk, one does sometimes have to be patient, the team may be US based for instance
<TLE> pitti: Hey. David and I were discussing that we would like to create some guidelines for how language teams can request a manual language pack update. The actual requests should be probably be in the form of a bugreport and of course it requires that you get informed somehow.
<TLE> pitti: so the questions is, against which package do you think these bug reports should be files?
<TLE> pitti: and can we find one where you will automatically be subscribed?
<TLE> s/be files/be filed/
<rsFF> hello there
<rsFF> where do the package dgbsyms for the kernel installs
<rsFF> since the gdb is not automaticly loading the symbols
<rsFF> i used to use vmlinux for that
<rsFF> but after i found out that ddebs were provides i tried to use them
<rsFF> but i cannot find it
<kklimonda> rsFF: dpkg -L <package> will give you the list of packages. Debug symbols are installed in /usr/lib/debug/
<persia> ddebs.ubuntu.com
<rsFF> yeah i already installed
<kklimonda> there is for example /usr/lib/debug/boot/vmlinux-2.6.35-22-generic and /usr/lib/debug/lib/modules/...
<rsFF> hummm
<rsFF> i think that should do it
<rsFF> thanks
<TLE> afk 20 min
<pitti> TLE: you should assign "ubuntu-langpack" to the bug (or subscribe); the actual package isn't that important, it could be any language-pack-* or the langpack-o-matic project
<jdstrand> pitti: hi! I was wondering if there was anything else needed from me re bug #660077
<ubottu> Launchpad bug 660077 in apparmor (Ubuntu Maverick) "update AppArmor to 2.5.1 (for upstream and backported maverick kernels)" [High,In progress] https://launchpad.net/bugs/660077
<jdstrand> (it is still waiting for approval)
<pitti> jdstrand: didn't get to review it yet; this makes me horribly nervous, though
<pitti> so I don't just want to wave it through, but read the diff
<pitti> this has such a huge regression potential
<jdstrand> pitti: in terms of abstractions, it should be fine. I was very careful on those
<pitti> right, but also for kernel<->userspace ABI or version expectancies, etc.
<jdstrand> pitti: jj-afk can speak at length on all of that
<jdstrand> pitti: but the upstream changes were very conservative to not break things like that. but certainly, I am not trying to rush you. I just want to make sure you have everything you need
<pitti> yes, I think I do
<pitti> (except enough time for the SRU queue.. :) )
<jdstrand> heh
<pitti> still have a couple of bugs for OEM which I need to get done this week
<pitti> next week -> back to platform :)
<jdstrand> pitti: (this is actually needed for an oem thing as well, since you mention it)
<jdstrand> pitti: but please talk to jj-afk if you have questions. he is extrememly familiar with these patches, the hows/whys, etc, etc
<pitti> okay, thanks
<TLE> pitti: ok thanks
<jdstrand> pitti: oh, one other thing. I plan to run the -proposed apparmor packages on several production systems and have committments from sbeattie and jj-afk on verifying the -proposed packages as well
<jdstrand> (that is in addition to all the testing I said I would do in the bug)
<avinashhm> hi, is there any tool or script to remove dos line endings for a patch ???
<micahg> avinashhm: vi can do it, I don't remember the command offhand
<avinashhm> micahg, yep tried :s/^M//g .. this worked .. thanks micahg
<micahg> avinashhm: actually, vi can just modify the line endings, but as they say in the Perl world TMTOWTDI
<avinashhm> whats TMTOWTDI ??
<ogra_ac> GIYF
<ogra_ac> :)
<avinashhm> ogra_ac, yeah ... theres more than one way because of google :-)
<ogra_ac> hehe
<micahg> avinashhm: http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
<avinashhm> micahg, thanks .... got it ..:-)
<mdeslaur> pitti: could you please release webkit for lucid and maverick so I can publish a USN? Thanks! (LP: #660075)
<pitti> mdeslaur: will do, thanks for testing
<mdeslaur> pitti: thanks!
<pitti> mdeslaur: done
<micahg> pitti: could you please accept gnome-shell in lucid-proposed?
<ari-tczew> cjwatson: is it possible to create a special blacklist for merge-o-matic to prevent showing merges? e.g. it's necessary for chromium-browser
<ximion_> Riddell: ping
<ximion_> I created a Debian package for packagekit, which will be present in Debian soon.
<ximion_> This package is a little bit different from the current one present in Ubuntu.
<ximion_> I was asked by Michael Vogt to ask you about "joining forces" in PackageKit Debian/Ubuntu packaging
<micahg> ari-tczew: why not fix the code to read teh archive blacklist file?
<ari-tczew> micahg: I don't mind.
<micahg> ari-tczew: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<SpamapS> so, while merging cheetah, I find that its only building for python2.6 in natty.. but 2.7 is available right? So should we also add a build-dep on python2.7-dev to get the C extension part built for 2.7?
<SpamapS> or is that what python-all-dev does eventually?
<james_w> python-all-dev would be appropriate I think, but there may need to be debian/rules or debian/control tweaks to get it to build for 2.7
<SpamapS> it loops through the pyversions already
<tumbleweed> err, python2.7 isn't supported yet. It's there, but your package won't build for it until it's listed in pyversions -s
<SpamapS> Ah, so basically.. just let it get rebuilt whenever python-all-dev is updated and it becomes a supported version?
<tseliot> cjwatson: have you ever seen this error with quilt (note: it's not true that the patch was already applied)? http://pastebin.ubuntu.com/516334/
<tumbleweed> SpamapS: yeah, that'll have to be done for many packages
<ScottK> ximion_: Riddell is expecting to mostly be offline this week, so don't expect a quick answer.
<ximion_> ScottK: Thanks for the info :) Okay, I don't need a fast reaction on this topic.
<SpamapS> woooooooot mdadm v3 uploaded! :-D
 * SpamapS would ^5 surbhi were she here. ;)
<SpamapS> hrm, and now I see when I do a pbuilder build, it does pull in python 2.7 .. and, unfortunately, fails horribly because of it. :(
<SpamapS> wow.. 2.6 all tests pass, 2.7, no tests pass. I'd say cheetah is not even capable of supporting python 2.7 yet.
<SpamapS> AttributeError: attribute '__dict__' of 'type' objects is not writable
<smoser> i have a debconf question that shows itself to debconf-get-selections as
<smoser>   eucalyptus-nc   eucalyptus-nc/no_vmx    error
<smoser> how can i seed it so i dont have to press 'Ok'
<smoser> anyone ^
<ScottK> SpamapS: barry has tons of advice for people fixing 2.7 stuff.
<barry> SpamapS: what's up?
<ScottK> barry: Do you have the backscroll where he talks about cheetah?
<barry> ScottK: i do.  SpamapS, i'll take a look at cheetah and see what i get.
<ScottK> Cool.  That's all I know.
<ScottK> Python problem?  Dial 1-800-barry.
<barry> or 1-800-flufl
<ScottK> That would be more pythonic, you're right.
<ScottK> It wouldn't work as well on IRC unless you highlight flufl too?
<SpamapS> barry: I haven't tried 2.4.3 yet, but 2.4.1 has quite a few issues.
<micahg> ScottK: 1-800-PEP3118 :)
<barry> SpamapS: lp:ubuntu/cheetah is 2.0.1-2ubuntu7 yes?
<SpamapS> barry: I just submitted a merge request with 2.4  bug 663343
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<barry> SpamapS: ack
<barry> SpamapS: does the test suite run as part of the build?
<SpamapS> barry: yes
<SpamapS> barry: if you remove 2.7 from debian/pyversions you get a whole mess of failures
<SpamapS> barry: or you can just run python2.7 /usr/bin/cheetah test
<SpamapS> barry: definitely worth trying out a uupdate to 2.4.3
<barry> SpamapS: ah, even 2.0.1 has test suite failures during the build, though the build apparently still succeeds
<barry> lots of these:
<barry> TypeError: importHook() takes at most 5 arguments (6 given)
<barry> let me try to merge 2.4.3, and then i might have one more source of useful patches...
<SpamapS> barry: I don't recall the end of the discussion about 2.7 in natty.. was the final call that it would be pushed for, but not set as default for some time?
<barry> SpamapS: i don't think we've made a final decision.  for now, 2.7 is supported but 2.6 is still default.  i *hoping* we can go with 2.7 as default for natty, but we'll see
<barry> SpamapS: i believe doko and ScottK agree with that plan
<barry> SpamapS: 2.4.3 builds but i need to update the rules to run the test suite in its new location
<barry> SpamapS: cheetah 2.4.3 + py27 + tests == fail
<SpamapS> barry: wait
<SpamapS> oh sorry n/m
<SpamapS> barry: the failures all seem to be around 1 or 2 problems like overwriting __dict__ in Template
<barry> SpamapS: i have one more trick up my sleeve...
<ScottK> barry: I do (agree with that plan).
<SpamapS> ScottK: hostname detection/setting.. I got mentioned in that conversation, but I wasn't sure what context it was under.
<ScottK> SpamapS: General system context of we suck at doing it consistently and correctly and we should fix that.
<SpamapS> ScottK: other than using the name fed to us via DHCP, I've never liked any of the other auto-detection methods. :-P
<SpamapS> Of which I can only think of one.. reverse dns.
<ScottK> SpamapS: We should look at what the various installers do, dhcp, anything else we can think of.
<SpamapS> ScottK: I wonder if we can lump this in with the upstart improvements discussion, and call it "server bootup improvements" instead.
<ScottK> SpamapS: No.  I think it's a different, but slightly related topic.
<ScottK> It's not just server for a start.
<SpamapS> Ah, good point. I don't ever think about the desktop. Desktops are just terminals for servers. ;)
<barry> SpamapS: branch with successful 2.7 build+test on its way :)
<barry> SpamapS: https://code.edge.launchpad.net/~barry/ubuntu/natty/cheetah/py27-compat/+merge/38883
<SpamapS> barry: nice. :)
<Riddell> ximion_: great, what's different?
<barry> SpamapS: i can't upload it though, perhaps you can sponsor?
<SpamapS> barry: nor can I. We're in the same boat that way. ;)
<barry> SpamapS: :)  perhaps ScottK, or i will ping doko tomorrow
<ximion_> Riddell: Nearly everything :P It produces some additional packages, has a few renamed to match the newest Debian policy and has a completely new copyright file.
<ximion_> these are chages Ubuntu can easily take.
<ximion_> the only thing you will want to change in Ubuntu is the vendor patch.
<SpamapS> barry: I will ask one of my usual sponsors to take a look if its not uploaded by Thursday.
<ScottK> barry or SpamapS: If someone presents me with an actual debdiff, I'll look at it.
<ximion_> Riddell: I suggest one Bazaar-Branch "packagekit" and one "packagekit-debian" which belong to the PackageKit-Team at LP, where both packages are maintained.
<barry> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/cheetah/+bug/663343/+attachment/1702084/+files/cheetah-663343.debdiff
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed]
<ximion_> Riddell: This should make sharing patches and other changes between both distributions really easy.
 * ximion_ is away for a short time
<ScottK> barry: Looking
<ScottK> barry: Is this a new upstream version?  If so, I need just the diff.gz.
<barry> ScottK: it is.  hang on, i'll upload that
<Riddell> ximion_: that sounds good
<barry> ScottK: http://barry.warsaw.us/cheetah_2.4.3-0ubuntu1.diff.gz
 * barry -> reboot
<pwnguin> obviously sin city has warped bav
<ximion_> Riddell: Is there an existing branch I should use for the Ubuntu packaging? Or should I create a new one?
<Riddell> ximion_: there's an existing branch, don't have it to hand but it'll be in the debian/control of our existing package
<ximion_> Diddell: The code assigned to the PK team only has a branch for maverick
<ximion_> woops :D sorry, I mean Riddell :P
<ximion_> Riddell: I would create a generic PK branch, which always contains the newest packaging version available in Ubuntu.
<ximion_> (so if e.g. Maverick closes, the content goes to packagekit-maverick and packagekit ist the branch where the natty development takes pace)
<maco> ordinarily the "trunk" branch refers to the devel version of ubuntu
<ximion_> there's a PK branch for the current dev version, but only members of Ubuntu branches can upload to it.
<maco> uh yeah that
<ximion_> I'm not familiar with the branch management in Ubuntu, so I don't know the best practice there
<maco> i think you just described it correctly
<Riddell> ximion_: practice differs from package to package
<ximion_> Riddell: What do you suggest?
<Riddell> ximion_: well presumably we need a debian one and an ubuntu one, which would be branches of each other
<ximion_> Riddell: The Debian packaging is currently in lp:~ximion/+junk/packagekit-debian, the Ubuntu packaging is in lp:~packagekit/packagekit/ubuntu-maverick
<ximion_> cause maverick is reserved for maverick, i would suggest lp:~packagekit/packagekit/ubuntu for Ubuntu stuff and lp:~packagekit/packagekit/debian for the Debian packaging
<ximion_> I would need to ask Sebastian to register the branches, as he is the maintainer of the PackageKit project at LP
<ScottK> barry: Thanks.
<Riddell> ximion_: I agree on the branch names, anyone with access to the team can push to them
<Riddell> ximion_: looks like glatzor and mvo can add you to the launchpad team, I'd recommend we get them to do so
<Riddell> ximion_: ah, you're Matthias Klumpp and have been a member for some hours
<Riddell> ximion_: so you just need to bzr push lp:~packagekit/packagekit/debian
<Riddell> ximion_: and we can see if we can manage without an ubuntu specific branch for now
<ximion_> Riddell: You probably want to have a different vendor patch for Ubuntu
<Riddell> ximion_: mm
<ximion_> Riddell: Also, the pkg is new on Debian, so it might lack the transition stuff needed for the Ubuntu pkg
<sladen> where is the Gtk+ menubar -> window manager integration done?  (My desktop theme has just reverted itself to defaults, as though something has crashed)
<ScottK> ximion_: It isn't wrong to carry the additional transition stuff in Debian so we can sync.  You might consider it.
<ximion_> ScottK: yep, I just need to figure out what exactly is needed for a Maverick -> Natty transition
<ximion_> you can watch the Debian packaging at lp:~packagekit/packagekit/debian now
<Riddell> ximion_: groovy, thanks
<ximion_> Riddell: Tomorrow I'll try to merge the Debian changes to Ubuntu and vice versa and then create an ubuntu branch. Then you can take this branch to upload a new PK version to Natty instead of using MoM on the Debian pkg
<sladen> ah... desk full wrecks Gtk+
<debfx> ximion_: dh_install should be in its own override target
<debfx> also you don't need to pass --list-missing to dh_install
<debfx> --fail-missing implies listing
<ximion_> debfx: Already changed this, but needs testing. The version in the repo represents the initial upload to the Debian archive
<ximion_> debfx: Oo...
<ximion_> you pointed me at a really bad regression I introduced
<ximion_> debfx: Phew! It wasn't uploaded to the Debian archive. The archive received the correct version
<ximion_> debfx: The call to dh_install was only for testing purposes, you can delete it if you want
<ximion_> gn88
<ximion_> whoops, I really need to sleep (this was typing error number fourteen in just twelve minutes!)
<ximion_> night!
<TheMuso> 6/c
<barry> ScottK: thanks for uploading cheetah.  SpamapS it failed to build, even though it built fine locally on my natty chroot.  will investigate.
<ScottK> barry: I did make some changes, so please review them for next time.
<barry> ScottK: will do, thanks
<ScottK> It built here too before I uploaded it.
<ScottK> barry: There's .pyc shipped in the 2.7 stuff.
<barry> ScottK: yikes
<ScottK> So that's why.
 * ScottK waits for a diff ....
<barry> it looks like the 2.6 stuff also has pycs though
<ScottK> barry: In my local build there's stuff in pyshared and python2.7/site-packages and only the latter has .pyc.
<barry> ScottK: where can i see your changes?
<ScottK> apt-get source the package and then diff it with yours.
<ScottK> None of hte changes I made would have affected the current problem.
<ScottK> (it was mostly changelog enhancement)
#ubuntu-devel 2010-10-20
<barry> ScottK: gotcha (i'm still using bzr, but the branch hasn't been updated yet, which is why i asked).  i may not get to it until tomorrow
<SpamapS> ScottK: err.. uhm.. there were a number of other changes too that somehow got missed there.
<ScottK> barry: dget https://launchpad.net/ubuntu/+archive/primary/+files/cheetah_2.4.3-0ubuntu1.dsc also works.
<ScottK> SpamapS: I just uploaded what barry gave me, so please get it sorted out with him.
<SpamapS> We've leap-frogged the debian package
<ScottK> Which is OK since it gets us ~OK with 2.7.
<barry> SpamapS: we'll have to get this back into debian experimental
<ScottK> (modulo whatever blew up the current build)
<micahg> ScottK: barry: since you're into python, what do you think about wxwidgets in main?  python-numpy now uses python-matplotlib to generate the docs (So it FTBFS ATM), so matplotlib has several universe build deps, but wxwidgets accounts for most of them
<SpamapS> Just minor stuff that was fixed in the debian 2.4.2.1 package
<barry> micahg: isn't there still some controversy about python-numpy support especially w.r.t. py2.7
<barry> er, python-numpy version
<ScottK> barry: http://kitterman.com/kubuntu/cheetah.debc is what my build looked like.
<ScottK> barry: re numpy/matplotlib - We ought to decide sooner rather than later if we'll split the package or promote all the depends.
<ScottK> SpamapS: re "minor stuff" work it out with barry and I'll upload the fixed version when you both have it ready.
<micahg> barry: idk much about the package, just happened to be browsing through FTBFS and saw this
<micahg> barry: I think 1.5.x has support though
<SpamapS> barry: one way to get this right is to make 2.4.3-0ubuntu2 from the 2.4.2.1-1ubuntu1 that I merged on bug 663343 (sans the pyversions limitation)
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<SpamapS> barry: and then send that back to debian for experimental.
<barry> SpamapS: i'll take a look at that tomorrow.  unfortunately, gotta run
<SpamapS> barry: np will throw the bug at you when its ready
<ScottK> barry and SpamapS: The debian/watch file also needs to be updated to point at http://pypi.python.org/pypi/Cheetah/2.4.3.
<SpamapS> ScottK: IIRC, pypi watches don't need to point to a particular version
<ScottK> SpamapS: Yes.  We don't want to point to just the particular version, that was meant to be exemplary and not precise.
<SpamapS> ScottK: the shebangs in /usr/bin/* for cheetah come out as /usr/bin/python2.7 .. I doubt thats intentional.
<ScottK> Probably not.
<SpamapS> especially since it breaks without python2.7 installed
<ScottK> Yep.
<SpamapS>  Depends: python (<< 2.7), python (>= 2.6), python-support (>= 0.90.0), libc6 (>= 2.2.5)
<SpamapS> is that a bug in pysupport?
<ScottK> Yes.  Or more correctly the change to support python2.7 as a supported version was probably incomplete.
<SpamapS> I'm thinking that setup.py should be called in such a way where it sets the executable to /usr/bin/python, no?
<ScottK> There's some option for that -externally-managed or so.
<SpamapS> 		--install-platlib=/usr/lib/python$buildver/site-packages/ --prefix=/usr --no-compile -O0 --single-version-externally-managed; \
<SpamapS> its being called that way..  but clearly didn't work. :(
<ScottK> Sounds right, except we want to install in dist-packages
<ScottK> Throw --install-layout=deb in there somewhere.
<SpamapS> thats just from the build log.. :-/
<SpamapS> guessing cdbs is doing something naughty
<SpamapS> actually, hmm..
<SpamapS> DEB_PYTHON_INSTALL_ARGS_ALL += --single-version-externally-managed
 * SpamapS tries adding it right there..
<SpamapS> crap, its right there in the rules file
<SpamapS> there's an attempt to fix it
<SpamapS> which looks really hacky
<SpamapS> ScottK: --install-layout=deb doesn't do it.. but I think I have a workaround. Like barry, I'm out of time too. :-P
<ScottK> OK.  Tomorrow then.
<twb> hardy's ffmpeg is FTBFSing on a hardy host, with unintelligible C datatype mismatch errors.
<twb> Where would I find Ubuntu's equivalent of buildd logs, so I can check when *ubuntu* last successfully built hardy ffmpeg?
<ajmitch> http://launchpad.net/ubuntu/+source/ffmpeg
<twb> Thanks.
<ajmitch> build logs are linked in the hardy section when you expand it
<twb> (I'm trying to build it with DEB_BUILD_OPTS=risky for a customer who wants ffmpeg with lame, but I can't even get it to build normally.)
<GanonKiller> has easycam been developed for meerkat?
<twb> I had no luck with an ordinary hardy VM, but I rolled a pbuilder chroot and that is building ffmpeg just fine
<twb> I speculate that my hardy VM had an optional build dep installed, and ffmpeg's ./configure was set to enable it if found, and it doesn't actually work with that version of the build dep.
<pitti> Good morning
<dholbach> good morning!
<pitti> hey dholbach
<dholbach> hey pitti
<dholbach> tumbleweed, what do you think about adding merge proposal info to the sponsoring overview (like in the last column of https://code.edge.launchpad.net/loco-directory/+activereviews for example)?
<dholbach> probably best to put that info in the status column
<tumbleweed> yeah, sounds good
<dholbach> I'll file a bug and see what I can do about it :)
<geser> dholbach: is the sponsoring overview page going to stay? As I hope to finally finish the splitting of code and template for it.
<dholbach> geser, I hope that a lot of it can go into Harvest instead
<dholbach> which uses Django
<delan_> what's the process for getting a package accepted into the official main/universe if it's already packaged in a PPA?
<delan_> 'i've had a look at the wiki, but that's more about the wishlist needs-packaging bugs (mine are already packaged)
<persia> delan_, There's lots of different ways.  The basic rule is that you want to have two members of ~ubuntu-dev say it's packaged well (because we all make mistakes)
<persia> If the initial packager isn't already a member of ~ubuntu-dev, usually the second reviewer uploads it.
<delan_> how can I contact the team?
<persia> There's no reliable way to contact everyone.  What kind of package is it?  Maybe one of the flavour teams would want to help.
<delan_> one is mathtext, a simple c-based shell-like program that transforms text into various 'styles' using Unicode
<delan_> the other is getbooru, a php-based downloader that can scrape images from a website once a profile of regexes is written
<persia> delan_, Hrm.  Neither of those strikes me as being tightly integrated with any of the flavours.  You might ask the MOTU if one of them would review it (ask in #ubuntu-motu).  You could also upload to REVU, but I'm not sure how many people check that regularly.
<delan_> please tell me, what is REVU?
<delan_> ah, i see
<delan_> https://wiki.ubuntu.com/MOTU/Packages/REVU
<delan_> i'll probably talk to the motu first, as you said
<delan_> thanks for that ;)
<persia> Be aware that a large number of MOTU don't really like more packages that don't have a maintainer, and may advise you to maintain it in Debian and let Ubuntu sync it.
<delan_> my problem with that is (i'm not sure how to fix this, though it must be simple)
<delan_> in the debian/changelog, I could enter 'unstable' and let it build on debian
<delan_> but if I try to upload that to a PPA, it won't work
<delan_> it will only work with an ubuntu version as the name, maverick
<persia> Oh, sure.  The assumption seems to be that once you get it into normal distributions, you won't need it in the PPA anymore.
<dholbach> hey slomo
<persia> And I doubt anyone is going to fuss too much about the changelog entry for review: most folk consider that a trivial change.
<slomo> hi dholbach :)
<delan_> hm, okay then.
<delan_> brb
<geser> pitti: can you please moderate my voting announcement mail to ubuntu-devel-announce? Thanks
<pitti> geser: done
<dholbach> tumbleweed, maybe you can review my ubuntu-sponsoring merge proposal? :)
<tumbleweed> lol, /me looks
<tumbleweed> geser: err I got a german ballot
<dholbach> geser, 2 nominees?
<geser> damn, why did CIVS sent out german ballots. I didn't pick any language. Or did it took by browser language.
<geser> dholbach: yes, only 2 :(
<dholbach> thanks geser for organising this
<geser> tumbleweed: but you still manage to vote?
<ebroder> geser: The site itself was English
<tumbleweed> geser: yes, I understand enough german to see what it was, and the subject line was english.
<ebroder> And the vote description was English. And there was only one link that could possibly have mattered
<geser> I feared the voting page was mostly in German too
<dholbach> geser, beware of seb128 - he marks all German mails as spam
<tumbleweed> an option for members with private e-mail addresses is to mail launchpadusername@ubuntu.com - AFAIK that should work for almost-everyone
<tumbleweed> dholbach: yay, looks good - I'll test it later today
<dholbach> tumbleweed, ok, just follow up on the merge proposal and I merge it when you're happy
<persia> tumbleweed, It doesn't: lots of folks have differences between LP username and @ubuntu.com addresses, for complicated reasons.
<tumbleweed> hmm, I thought those were the minority (and that they tended to have their lp username, too) - I also assume some of them will loop
<persia> tumbleweed, hard to say.  The first few hundred @ubuntu.com addresses were given out before LP integration.
<persia> And lots of folks have changed LP names, but that doesn't automatically change @ubuntu.com alias (or didn't, for a very long time)
<Laney> haha
<tkamppeter> pitti, slangasek, hi
<ScottK> ajmitch: When you upload boost, would you also please make sure to add -py27 for boost-python?
<ScottK> pitti: I think clamav in lucid-proposed is ready to go now: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/653738/comments/6
<ubottu> Launchpad bug 653738 in clamav (Ubuntu Lucid) "Microversion update SRU for clamav in Lucid" [High,Fix committed]
<pitti> ScottK: ok, thanks
<Eximius> yello
<Eximius> After giving up  on #ubuntu
<Eximius> i came here to look for hhelp
<Eximius> anyone having probs with BCM43** drivers and ad hoc?
<Laney> this isn't the place for support, sorry.
<Eximius> #ubuntu doesn't have real support, rather slackers with no idea whatsoever
<persia> You might try #ubuntu-cc (where cc is your country code) to ask in your LoCo
<persia> Or file a question on launchpad.
<Eximius> hmmm
<dholbach> Eximius, dissing people who spend a lot of time helping others won't increase your chances elsewhere
<Eximius> I'm developing a app to use BCM43** drivers for ad hoc
<Eximius> :D
<Eximius> I'm not dissing
<persia> That might be #ubuntu-app-devel, but I very much doubt anyone there can help with the problem, although they may be able to help with app creation.
<dholbach> well, "slackers with no idea whatsover" is dissing in my book
<Eximius> rite, so "no idea whatsoever" might be a little not true
<dholbach> ...
<SpamapS> Is there some reason that people use cdbs now that dh 7 exists? Seems like it just confuses things. :-P
<bilalakhtar> SpamapS: There are some reasons why people *have* to use cdbs
<bilalakhtar> for example, in python packages
<bilalakhtar> though dh7 can handle that
<dholbach> SpamapS, AFAIK at least in desktop land we have a couple of extra things that cdbs just sorts out (language-packs, etc.)
<bilalakhtar> dholbach: yes, you're right
<SpamapS> ah
<tumbleweed> err dh7 is much nicer for python packages
<bilalakhtar> the gnome-*.mk files
<SpamapS> for python modules its just confusing me
<SpamapS> right, dh7 gets them right
<tumbleweed> although some people use it for python+autoconf packages (which is vaguely relevant)
<bilalakhtar> hmm, I cannot say much about python
<tumbleweed> yeah, CDBS screws up shebangs (I must actually test my patch for that)
 * bilalakhtar gets pinged the moment someone says 'cdbs'
<bilalakhtar> but as for GNOME packages, there are some CDBS includes which help
<SpamapS> tumbleweed: yeah I think thats a bug in python-distutils.mk
<SpamapS> no?
<tumbleweed> SpamapS: yes and no. dh7 works around it by building with /usr/bin/python last (after all the versioned ones)
<tumbleweed> but these days setup.py can take a --executable option to force a specific shebang (in many cases)
<dholbach> tumbleweed, replied :)
<SpamapS> I worked around it with DEB_PYTHON_BUILD_ARGS += --executable=/usr/bin/python
<SpamapS> but now I'm getting leftover files in /usr/lib/python2.7/site-packages
<SpamapS> its like dh_pysupport doesn't even see them.
<bilalakhtar> coolbhavi is also facing similar problems
<bilalakhtar> in his mail to ubuntu-motu
<SpamapS> ugh.. I am loathe to subscribe to yet another mailing list
<ScottK> bilalakhtar: There aren't any reasons why people have to use CDBS.
<geser> ScottK: do you know what needs to be changed to fix FTBFS with python 2.7 and files being installed in site-packages? need the python packaging tools need to get updated for python2.7 or the package itself?
<SpamapS> I'm on 37 already
<ScottK> geser: I don't, but barry was going to look into it today.
<bilalakhtar> Does natty use python 2.7 by default rather than 2.6 ?
<geser> ok, then I wait on barry
<SpamapS> bilalakhtar: not yet no
<ScottK> bilalakhtar: No.  It's an additional supported version for modules and extensions, but not default.
<geser> bilalakhtar: but it's already part of python-dev package
<bilalakhtar> :)
 * ScottK hands geser an "all".
<geser> right
<tumbleweed> dholbach: replied
<dholbach> tumbleweed, super
<dholbach> tumbleweed, which vote summary page are you referring to?
<dholbach> (just making sure I don't misunderstand :-))
<tumbleweed> dholbach: err, +activereviews and the summary table at the top of +merge
<highvoltage> Ubuntu 4.10 was released 6 years ago today
<highvoltage> on week 42!
<highvoltage> that means that 42 was built into the Ubuntu computer since the beginning.
<ari-tczew> who maintain hall-of-fame ?
<highvoltage> I hope the project doesn't get destroyed before it figures out the question.
<dholbach> ari-tczew, it's slightly unmaintained, but there's a session at UDS to revive it - what's your question about it?
<ari-tczew> dholbach: Interviews is not updated. Last interview was reffer to Rhonda.
<dholbach> ari-tczew, ah yes
<tkamppeter> pitti, slangasek, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, slangasek, it is about bug 494141. It seems that the upstartification of CUPS is not enough, but also the upstart config of Samba needs to be modified.
<ubottu> Launchpad bug 494141 in cups (Ubuntu) "CUPS starts after SAMBA; printers are not available (convert cups to upstart)" [Undecided,Fix released] https://launchpad.net/bugs/494141
<tkamppeter> pitti, slangasek, and the fact that smbd re-reads the CUPS config every 750 sec seems to be wrong.
<pitti> tkamppeter: but cups' upstart script already reloads samba
<tkamppeter> pitti, and how do the complaiunts of the users come, like comment #32 and #34?
<bilalakhtar> geser: You have been uploading package multiboot for quite some time. Can I go ahead with a merge?
<pitti> tkamppeter: then perhaps reloading samba isn't sufficient? I don't know
<chrisccoulson_> hey pitti - would you mind sponsoring a pango SRU for me please?
<chrisccoulson_> (for bug 655707)
<ubottu> Launchpad bug 655707 in pango1.0 (Ubuntu) "Firefox crashes opening pages that use webfonts " [High,Triaged] https://launchpad.net/bugs/655707
<geser> bilalakhtar: I wouldn't count two uploads within 15 min "for some time" :)  but sure, you can merge it.
<bilalakhtar> thanks
<tkamppeter> pitti, perhaps "kill -HUP" has not the desired effect on smbd. Perhaps it needs to be like a "restart smbd" or so.
<pitti> chrisccoulson_: the attached branch is already in natty, and I don't see a debdiff?
<chrisccoulson_> pitti - yeah, after i pushed my change to bzr, robert did a natty upload
<chrisccoulson_> pitti - it's rev 7 that needs to go in to maverick - do you want me to branch off that?
<pitti> chrisccoulson_: if you could prepare a debdiff or a branch, with the necessary changelog bug ref and all that, that'd be great
<pitti> chrisccoulson_: (sorry, working a bit "under the gun" today)
<chrisccoulson_> pitti - ok, no problem :)
<chrisccoulson_> i'll do that in a bit
<pitti> . o O { and why isn't pango1.0 in the desktop set? }
<chrisccoulson_> pitti - it might be worth backporting this specific fix also to lucid
<chrisccoulson_> not sure why it's not in the desktop set ;)
<DktrKranz> lool: hi! now that python2.7 is a supported version in natty, python-support needs to be aware of that (some FTBFS have been reported already). Do you plan to look at it?
<ScottK> DktrKranz: IIRC barry was looking at it.
<DktrKranz> ScottK: ah, good. Thanks
<lool> ScottK: Would you think we should implement the changes I committed in Debian for Ubuntu?
<ScottK> lool: I haven't checked the details to have an opinion.
 * ScottK is really hoping barry is up for worrying about it.
<lool> barry: I committed some changes to the python-support SVN to read the supported and old versions from debian_defaults; POX and Np237 weren't too sure about that; I personally think that's ok, but it might be that it causes this list to be odd at some times
<ari-tczew> cjwatson: I'm not sure, but I'm afraid, that MoM is not updated anymore.
<mvo> ari-tczew: yeah, it appears to be locked since 18th
<barry> so i was looking at this message: https://lists.ubuntu.com/archives/ubuntu-motu/2010-October/006931.html and james_w and others suggested to install pkgbinarymangler to see the failure reproduced locally.  yesterday i was successfully building cheetah locally but the buildd failed.  turns out to be the exact same failures.  but the meta issue is: why isn't pkgbinarymangler a builddep for python packages since its sanity check seems
<barry> critical (and somewhat magical)?
<james_w> barry, we don't want to modify every package for that
<james_w> we could e.g. make python depend on it, but then it would put the package in the default install, which we don't want
<james_w> we could have pbuilder and other tools automatically install it in the chroot
<mvo> ari-tczew, cjwatson: I killed the hang process, mom should recover with the next cron run
<barry> james_w: those are downsides, for sure.  we'll probably be touching most python packages anyway to transition to dh_python2.  i suppose we could do it then, *if* that was a direction we wanted to go in
<barry> but having pbuilder and other tools install it might be a better way to go
<tumbleweed> pkgbinarymangler is ubuntu-only - so it can't be a bulid-dep for python packages
<barry> tumbleweed: i see
<tumbleweed> yeah, it should probably be installed when variant=buildd (although I know nothing aobut debootstrap)
<barry> another thought: that particular check is appropriate for both debian and ubuntu, so maybe that check should live somewhere else?  dh_python2 or related?
<james_w> barry, that would be good
<tumbleweed> barry: sounds like it should be in dh_python2, yes. In fact dh_python2 should just put them in the right place - that's what it does for /usr/local/... AFAIK
<barry> tumbleweed: yes, dh_python2 will (or should :) just put them in the right place
<barry> so maybe it's a moot point after that transition is complete
<ScottK> barry: There are other reasons pkgbinarymangler can cause a build to fail, so it's generally a best practice to have it installed in your build chroot (I'll confess I forgot to add it to mine after I made it for natty).
<cyphermox> ScottK, it's the second time I see this come up today... would it make sense to have pkgbinarymangler added to extra packages that pbuilder should install to a chroot (though that would only work for ubuntu?)
<dholbach> ari-tczew, fixed
<ScottK> cyphermox: It only applies to Ubuntu buildds, so not necessarily.
<Keybuk> shtylman: whoah, fast grapevine!
<shtylman> Keybuk: your own doing... shouldn't use twitter :p
<Keybuk> I haven't actually said anything specific on Twitter yet
<pitti> hey Keybuk, how are you?
<Keybuk> pitti: hey, good thanks - you?
<pitti> Keybuk: fine -- wrapping up my last week @ oem
<barry> ScottK: do you agree that the python check it does will not be necessary once everything's transitioned to dh_python2?  if so, then i will just add that as a recommendation to the wiki page i use to build out the chroots
<Keybuk> pitti: looking forwards to getting back to the distro or will you miss oem?
<jcastro> he misses distro surely!
<barry> or, iow, it would be okay not to install it by default
<pitti> Keybuk: little bit of both, but I'm definitively looking forward to some natty work
<chrisccoulson_> hi kees. would appreciate your help with bug 663294 if you get some free time :)
<ubottu> Launchpad bug 663294 in gcc-4.5 (Ubuntu) "Firefox built with gcc-4.5 is a non-starter on i386" [Undecided,Confirmed] https://launchpad.net/bugs/663294
<shtylman> Keybuk: lets say I have good analytical skills
<pitti> and working on stuff that *I* actually use :)
<ogra_ac> Keybuk, question is will *you* get to the distro at some point :P
<Keybuk> ogra_ac: hmm?
<ogra_ac> Keybuk, youre such a rare guest recently
<Keybuk> heh, to IRC?  I'm usually on Jabber :
<ogra_ac> ah
<Keybuk> IRC is full of users who want to rant at me for things I write in changelogs and stuff
<ogra_ac> secret communication channels ;)
<Keybuk> but mostly been coding, so IRC is kinda distracting for that
<jcastro> Keybuk: weren't you referring to yourself in that changelog?
<ogra_ac> yip
<jcastro> I thought it was just some clever wordplay.
<Keybuk> jcastro: I don't remember - it's quite probably
<ScottK> barry: In what century do you think the transition will finish?
<ScottK> I'd just add it to the wiki page though.
<barry> ScottK: the same one we remove python-support and python-central in <wink>
<ScottK> I agree with that.
<ScottK> Although century was probably overly pessimistic.  I should have said decade.
<barry> ScottK: given that this decade technically ends in about 2.5 months, yeah :)
<ScottK> It won't be this one.
<barry> no, it won't
<barry> but i'm mildly optimistic it will be the next one :)
<ScottK> Right, but you're the optimist in the room.
<barry> it's a dirty job but someone's gotta do it
<ScottK> ajmitch: Transitioning packages off of boost1.40 is now blocked on boost-python1.42 having -py27 support ...
<pitti> cjwatson, slangasek: do you have a minute to review postgresql-common in hardy/lucid?
<pitti> ogra_ac: please reupload alsa-utils SRU with -v to include previous SRU
<pitti> that didn't go to -updates yet
<ogra_ac> pitti, oh, i need to do that for every update ? ok, no prob
<pitti> ogra_ac: only if you put another upload on top of a -proposed one
<ogra_ac> k
<pitti> ogra_ac: once it goes to -updates, it's not required any more
<pitti> i. e. we always need -v<version in final or -updates>
<ogra_ac> oki
<ogra_ac> i never did multiple uploads to proposed before ...
<ogra_ac> thanks
<micahg> pitti: I think the current gnome-web-photo SRU should be accepted
<micahg> pitti: we won't have a better fix for a couple months
<pitti> micahg: so that one will work then?
<pitti> the bug trail sounded like there were some doubts
<pitti> but sure, I can accept it
<micahg> pitti: yes, it'll work, chrisccoulson_ was just saying that they app itself should connect differently, but that type of change  seems more risky for an SRU
<pitti> okay
<micahg> *the
<tseliot> pitti: if we have changes that involve the debian directory and we're dealing with a package that uses 3.0 (quilt) format, shall we modify the files in debian/ directly or shall we create a patch that does the same thing?
<pitti> tseliot: directly, please
<tseliot> pitti: ah, this could be the reason why quilt is giving me so many problems. Thanks
<SpamapS> barry: good morning.. are you around? I've been working on trying to get cheetah to build and work w/ python 2.7 properly...
 * geser guesses that every IRC ping barry gets today it about python 2.7 related FTBFS :)
<SpamapS> haha
<SpamapS> you reap what you sow
<SpamapS> cheetah at least builds, but it borks things up quite a bit.
<dholbach> can somebody moderate my mail on u-d-a?
<geser> SpamapS: that's a common error in the build logs, I guess barry will fix the tools to cope with python2.7 too. I guess you just need to wait for that fix.
<SpamapS> geser: Yeah, I'm hoping I can offer some help in some way.
 * SpamapS is on an SRU/merge/backports mission in between reading blueprints.
<kees> chrisccoulson_: sure, I'll take a look
<chrisccoulson_> kees - thanks
<chrisccoulson_> i'm just building mozilla-central with -fstack-protector now
<kees> chrisccoulson_: looks like a glibc bug
 * kees continues to read
<chrisccoulson_> kees, OOI, what makes you think glibc?
<zyga> mvo, around/
<kees> chrisccoulson_: hadn't gotten far enough, just saw the top level pthread stuff.
<chrisccoulson_> kees - ah, yeah, there's a bit more analysis below that ;)
<kees> does firefox overload malloc somehow?
<kees> anyway, I'll shut up until I read all the way through it :)
<chrisccoulson_> kees - yeah, it provides it's own malloc implementation
<chrisccoulson_> the stock glibc malloc suffers too much from fragmentation
<Keybuk> chrisccoulson_: huh?
<chrisccoulson_> Keybuk, was that in response to my last comment?
<Keybuk> yes
<Keybuk> I'm curious as to why this *matters*
<chrisccoulson_> Keybuk, when mozilla did a lot of work to optimise the memory footprint of firefox before 3.0, they found a lot of memory was being wasted due to fragmentation, which ends up with memory not really being released back to the system
<Keybuk> sure, but it doesn't matter
<Keybuk> Linux assumes no process releases its memory
<Keybuk> firefox manages to consume so much it actually hits swap
<Keybuk> which will be unrelated to that fragmentation
<Keybuk> sounds more like they're blaming something else for their own failure
<kees> I do find it scary that it uses its own malloc; glibc's is actually pretty safe.
<smoser> anyone used the python-apt ? i was hoping to use it to download and inspect archives from a different arch than the running arch.
<smoser> but I didn't see a way to do so.
<kees> smoser: I always use the LP API to do archive validation
<smoser> kees, well, this particular itch was converting binary package -> source package
<smoser> to which i was told launchpad was not capable
<tgardner> cjwatson, whats the normal way for enabling bootstrap chroots? I have a patch to enable natty in Lucid debootstrap. Shall I upload it?
<kees> smoser: well, that's just because multiple sources can produce a binary package
<smoser> (other than the screen scraping that "works for me" right now) from https://launchpad.net/ubuntu/<release>/<arch>/<binpkg>
<kees> smoser: but yeah, it's a fair point.
<kees> open a bug! :)
<kees> I can't search by CVEs in the API either. ;)
<smoser> well, i supposed that is true. but i have binary package, version, and know it came from one of main  universe updates or security
<smoser> and i can't get what i want.
<kees> when I did the seed analysis, I'd pull down the Packages files and parse them. :(
<smoser> yeah, which is what python-apt would do for me
<smoser> but i dont see how i can tell it to pull from something other than arch=(uname -m)
<smoser> just trying to re-invent as  little as i can
<smoser> mvo, ^^ do you know if i can tell python-apt to pull cache for a different arch than current ?
<Q-FUNK> mvo: wrt bug #587186 I wanted to ask, what did you end up checking for?
<ubottu> Launchpad bug 587186 in update-manager (Ubuntu Natty) "libc6 upgrade fails: illegal instruction" [Medium,Fix committed] https://launchpad.net/bugs/587186
<kees> pitti: still around? how do I get something onto the sync-from-debian-blacklist?
<kees> I don't want python-pyftpdlib coming in unless it clears its current hurdle of WAY too many CVEs open. :)
<pitti> kees: need to run now, sorry; any archive admin can do that
<ScottK> tgardner: The usual way is just to backport debootstrap from the development release (or in this case from Maverick)
<tgardner> ScottK, I have the patch developed from a previous example. I just wanted to make sure I wasn't stepping on any toes
<ScottK> tgardner: It should be a no change backport that any Canonical archive-admin can just do.
<kees> jdstrand: why hello. :) got a moment for a blacklist addition?
<kees> chrisccoulson_: what happens if you turn off the malloc replacement logic?
<kees> chrisccoulson_: you just did a test build with -fstack-protector or with -fno-stack-protector?
<chrisccoulson_> kees - i haven't tried turning off the internal malloc, but i guess it will work
<chrisccoulson_> i did a build with -fstack-protector, and it works fine
<kees> how were you building where it didn't get -fstack-protector automatically?
<jdstrand> kees: whatcha need?
<smoser> ok. so i'm not real familiar on the process for this, but currently natty python-paramiko depends on python-crypto (>= 2.1.0-2). but 2.0.1+dfsg1-4ubuntu2 is current.
<jdstrand> kees: and hi!
<smoser> do i need to file a "sync from debian" request for python-crypto ?
<kees> jdstrand: hi! :) can you blacklist python-pyftpdlib so it doesn't enter natty from Debian? It has a stack of CVEs, and I want to make sure they're addressed before we get that into Ubuntu (it's very new in Debian)
<smoser> oh. actually i see its already done: https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/662883
<mvo> smoser: yes, set "apt.apt_pkg.config.set("Apt::Architecture","armel")" at the start (before you init your apt.Cache()"
<ubottu> Launchpad bug 662883 in python-crypto (Ubuntu) "Sync python-crypto 2.1.0-2 (main) from Debian unstable (main)" [Wishlist,New]
<smoser> mvo, awesome. thank you.
<chrisccoulson_> kees - i'm just building a stock checkout from mozilla-central (make -f client.mk with a minimal set of build options in mozconfig)
<mvo> Q-FUNK: hold on a sec, I can look for the commit diff
<kees> chrisccoulson_: but our compiler forces -fstack-protector ...
<mvo> smoser: you know apt.Cache(rootdir="some-dir") too, right?
<chrisccoulson_> oh, ok. i didn't realise that
<smoser> mvo, yeah, thats what i was using/abusing
<kees> chrisccoulson_: perhaps it's the -fPIE -pie bits from hardening-wrapper?
<mvo> smoser: make creating multiple "apt-roots" really easy
<mvo> smoser: oki
<chrisccoulson_> kees - yeah, possibly. will try with just those now
<kees> chrisccoulson_: so, just so I understand, which builds have worked, and which have failed?
<hicham> chrisccoulson_: you updating to xulrunner2 ?
<chrisccoulson_> kees - building our ubuntu packaging branch with our gcc-4.5, and also debians gcc - all fail
<chrisccoulson_> building stock mozilla-central with both gcc versions - both ok
<kees> chrisccoulson_: okay, but a stock build worked? sounds like PIE
<chrisccoulson_> building our packaging without DEB_BUILD_HARDENING also works with both gcc versions
<kees> yup.
<kees> so that means it's either PIE or BIND_NOW
<bilalakhtar> Keybuk: Are you serious on leaving Canonical?
<kees> chrisccoulson_: let me check something and see if you can easily eliminate BIND_NOW as a variable without doing a full recompile...
<chrisccoulson_> kees - i'll need to do a recompile anyway, i've borked my build environment
<kees> chrisccoulson_: hah, whoops
<smoser> doko_, can you please re-evaluate 662883 ?
<kees> chrisccoulson_: okay, well, leave DEB_BUILD_HARDENING=1 but add DEB_BUILD_HARDENING_PIE=0 to disable just the PIE part.
<chrisccoulson_> kees - ok, doing that now
<chrisccoulson_> thanks
<kees> chrisccoulson_: and if that works, then we've isolated the problem, and can try to forward this to gcc or something.
<hicham> what does DEB_BUILD_HARDENING_PIE do ?
<kees> hicham: http://wiki.debian.org/Hardening#DEBBUILDHARDENINGPIE.28gcc.2BAC8-g.2B-.2B--fPIE-pie.29
<kees> hicham: it enables relocation for the text segment of the binary
<kees> hicham: i.e. -fPIE -pie compiler flags, like -fPIC for shared objects, but for the main binary
<jdstrand> kees: done
<kees> jdstrand: thanks!
<hicham> kees: there are some text relocs in libxul.so FWIW
<chrisccoulson_> judging by my analysis of the problem, -pie sounds like a plausible culprit ;)
<chrisccoulson_> right, that's building now
<kees> hicham: all of libxul.so should be relocatable (since it's a shared object and must be compiled with -fPIC)
<chrisccoulson_> i will also do a stock mozilla-central build with -pie, which is the only combination i haven't done so far i think
<kees> chrisccoulson_: weird that it would show up in this way. but if gcc-4.4 works but gcc-4.5 doesn't, then we should be able to show the problem to upstream
<hicham> kees: most have been fixed ( the relocs from libvpx), but there are one or two relocs remaining from gfx/Layers code
<kees> chrisccoulson_: injecting -fPIE -pie can be tricky, depending on how they call the linker
<chrisccoulson_> kees - yeah, i'm running 2 stock mozilla-central builds now - 1 with DEB_BUILD_HARDENING_PIE=0 and 1 without
<chrisccoulson_> this is where my machine begins to smoke
<chrisccoulson_> :)
 * chrisccoulson_ goes to find some dinner to cook on his laptop
<hicham> kees : who maintains ff in ubuntu ?
<kees> hicham: chrisccoulson_ IIUC :)
<chrisccoulson_> yeah ;)
<hicham> kees:  thanks
<kees> hicham: ah, I may have confused the language around "relocatable text" vs "text relocation". I just just say "position independent code"
<kees> *I should just ...
<hicham> kees: i just wanted to know ubuntu's stand on the bundled libvpx
 * kees tries to pick a hat to wear for a reply to that
<chrisccoulson> what do you want to know?
<barry> doko_: ping
<kees> chrisccoulson: so, in your bug report, you show 0xf7ff6720 twice
<kees> chrisccoulson: in the first instance, it has a nop and other stuff before the mov to %edi. in the second, it's been reduced to 1 instruction
<kees> chrisccoulson: that seems mighty strange.
<tgardner> kirkland, re: debootstrap in Lucid, ScottK says 'tgardner: It should be a no change backport that any Canonical archive-admin can just do'. Can you do that?
<kirkland> tgardner: what is it you want to do?  put Maverick's debootstrap into lucid-backports?
<tgardner> kirkland, yep, I need a natty schroot
<kirkland> tgardner: and you want it in the official lucid-backports archive, rather than just putting it in a PPA, or building it locally for yourself?
<tgardner> kirkland, yes. the kernel team  uses the schroot on a bunch of machines. Adding it to -backports is what has been done in the past
<kirkland> tgardner: okay, let me take a look
<smoser> i believe that we have had updates like that into -updates (not -backports) in the past
<smoser> just for adding new release names
<smoser> (which is all you need for debootstrap, a single 'ln -s gutsy natty')
<tgardner> smoser, I have a patch for the Lucid debootstrap that does just that, but I wanted to make sure it was the right way before I uploaded it.
<smoser> i swear that there was a special allowance for "release names" to be "back ported". but maybe i just dreamed that.
<tgardner> smoser, looking at the lucid package I think thats what was done.
<tgardner> for maverick at least
<kirkland> tgardner: yeah, i think i'd rather that -- a small fix that adds natty
<tgardner> kirkland, ok, I'll upload in a few minutes
<kirkland> tgardner: cool, thanks
<kirkland> pitti: looks like debootstrap 1.0.20ubuntu1.1 has been in lucid-propose for 9 weeks
<kirkland> tgardner: make sure you base your update on debootstrap 1.0.20ubuntu1.1 from lucid-proposed
<kirkland> tgardner: i'll try to get pitti to clear that one from the queue
<kirkland> tgardner: so that your .2 can go right in
<tgardner> kirkland, right, thats the version I started from
<kirkland> tgardner: good
<tgardner> kirkland, ok, uploaded
<SpamapS> can I get somebody to take a look at bug 660990 for sponsorship? would like to ship an SRU into maverick for it.
<ubottu> Launchpad bug 660990 in libdbi-drivers (Ubuntu) "undefined symbol: _dbd_parse_datetime" [Medium,Confirmed] https://launchpad.net/bugs/660990
<kirkland> tgardner: okay, pitti has to clear out the .1 version from -proposed first
<AnAnt> Hello, what are :: entries for in makefiles ?
<tumbleweed> AnAnt: http://www.gnu.org/software/make/manual/make.html#Double_002dColon
<AnAnt> tumbleweed: thanks, so that means, if I have several build:: targets in the makefile, all of them will get executed ?
<tumbleweed> AnAnt: yes. cdbs uses that for customisation
<AnAnt> thanks
<barry> is someone available to review and/or sponsor bug 664068?
<ubottu> Launchpad bug 664068 in python-support (Ubuntu) "Add support for Python 2.7" [High,In progress] https://launchpad.net/bugs/664068
<SpamapS> barry: reviewing now.. but cannot sponsor. ;)
<SpamapS> barry: ugh, all those hard coded versions are what is driving us nuts?!
 * SpamapS gives it a whirl
<barry> SpamapS: yeah, but eventually it will all be better (tm)
<SpamapS> barry: testing now w/ cheetah ;)
<barry> SpamapS: thanks!
<SpamapS> pitti: looks like drizzle is picking up our work! ;) http://drizzle.org/workitems/
<chrisccoulson> kees - doing 2 parallel builds probably wasn't a good idea ;)
<chrisccoulson> it would have been faster to do them one after the other
<SpamapS> barry: hmm.. it did remove the site-packages dirs now.. but no pyc compilation
<barry> SpamapS: on build?  that's actually a good thing :)  pycs are built at install time
<SpamapS> no on install
<barry> that's bad :(
<SpamapS> Could be something else wonky in this system
<Pici> 22
<SpamapS> Pici: how'd you know my lucky number? ;)
<Pici> SpamapS: Magic ;)
<directhex> asac: can i talk to you regarding a mono patch you wrote for ARM?
<SpamapS> barry: update-python-modules uses the same source for supported versions, right?
<SpamapS> barry: even manually running 'sudo update-python-modules -f' doesn't create the pyc's for cheetah, though it did create them for others
<barry> SpamapS: hmm.  i'm distracted with something else atm, but will get back to this asap
<SpamapS> barry: ok, I'll post my experience to the merge proposal
<barry> thanks!
<chrisccoulson> kees - ok, build with DEB_BUILD_HARDENING_PIE=0 is good :)
<chrisccoulson> just waiting for the other build to finish, just to confirm that one fails to start
<kees> chrisccoulson: well, that's a bit scary, but okay, at least we've isolated it.
<chrisccoulson> kees - yeah, i want to wait for the other build to finish first, because they're totally identical except for that one option
<kees> cool
<ajmitch> ScottK: sorry, are there other things you need me to break in boost1.42 before I upload it?
 * ajmitch is still waiting on the laptop to resume properly before he can check it
<doko_> smoser: well, why drop a patch, which we will introduce later again this cycle? if you want to go forward, please use dh_python2 instead of python-central
<chrisccoulson> kees - ok, now i'm really confused. the other build works too :/
<kees> O_o
<smoser> doko_ will admit to not really being knowledgable about what was going on there. but the poster said the end result is the same with or without the patch that was droppd.
<doko_> smoser: there is no guarantee that a helper will do the correct things within /usr/local, and dh_python2 warns about that too. I'll have a look at the merge if nobody wants to do it
<smoser> well, i personally would appreciate it.  i can do it, but having my uec-images build *right now* is my main interest.  and the learning curve would be more time consuming than leaching from you
<smoser> :)
<chrisccoulson> kees - oh, it helps if i actually use the right gcc version.....
<chrisccoulson> ;)
 * chrisccoulson crawls under a bus
<kees> chrisccoulson: oops. :P
<chrisccoulson> i'm deeply embarassed now, i've just wasted 2 hours of my evening waiting for those to finish ;)
<tumbleweed> doko_, smoser: I'll happily provide a merge. I just thought that if it works unmodified there's no point in having ubuntu-modifications.
<doko_> tumbleweed: in principle, yes, but we finally want to robustify the python packaging, eliminating symlinking at install time for packages on the CD
<tumbleweed> doko_: I'm aware of that
<doko_> tumbleweed: so do it now, and don't touch it later again ;)
<tumbleweed> heh, well that won't happen until 2.6 is gone, I assume
<chrisccoulson> kees - ok, take 2 now (builds kicked off, with the correct gcc version this time)
<kees> chrisccoulson: okay, cool.
<tumbleweed> doko_: oh on the CD, you mean before then. Should I do a merge that also converts to dh_python2 then?
<doko_> tumbleweed: would be appreciated, yes. just make sure that all files are still included
<tumbleweed> sure
<smoser> tumbleweed, doko_ thank you.
<ScottK> ajmitch: Just adding -py27 to the versions for boost-python.
<ajmitch> from a 10-second overview, I don't see python versions hardcoded in it at the moment
<smoser> anyone aware of code to parse 'LP: #' bug identifiers from a string ?
<smoser> ideally woudl support debian style bug reference also, and 'LP: #1, #2'
<geser> somewhere in a perl module from dpkg (IIRC)
<micahg> doko_: is the icedtea plugin going away, or did it just move somewhere?
<doko_> micahg: split out into a separate package, so that you can take over maintenance ;)
<micahg> doko_: heh, happy to help if I can :)
<TommyBrunn> Hello everyone. I'm trying to find some up-to-date information on creating Gnome panel applets in Python, but I can only seem to find old, outdated and incorrect resources. Do any of you have any idea where I can find good documentation?
<BUGabundo> guud evening
<tuxmountain> Hi
<tuxmountain> how are you?
<BUGabundo> tired
<BUGabundo> in need of a couple new eye balls
<tuxmountain> I've a question (I don't know if it's here the best place for that but I try!)
<tuxmountain> Why WUSB600N is totaly supported in 9.04... but not in 9.10 or 10.4...?
<tuxmountain> With 9.04 you install ubuntu, and the wifi works
<tuxmountain> but with 9.10... you need ndiswrappers! Why?
<tuxmountain> It's not possible to use a old paquet for the wifi?
<tuxmountain> /etc/modprobe.d/blacklist.conf is the file for active the old module?
<chrisccoulson> kees - ok, confirmed it is pie now
<chrisccoulson> i guess it would be useful for me to figure out a minimal case to reproduce it
<kees> chrisccoulson: that would be optimal, yeah
<lifeless> barry: here ok ?
<lifeless> barry: is there a session about multiple versions of python libraries being supported planned for uds ?
<barry> sure
<lifeless> barry: I know jos said (roughly 'mmm, nice idea, no time'), but I think it would be -awesome- to get this actually moving.
<barry> lifeless: not as such.  we have a few blueprints carried over from mav but no sessions planned.  i think we[*] are pretty much in agreement on the plan for natty
<lifeless> barry: And I'd be delighted to be the grain of sand
<barry> [*] ScottK, doko, myself at a minimum
<lifeless> barry: oh, I don't mean python3.1+3.2
<lifeless> I mean zope.appserver1.3 + zope.appserver1.4
<barry> ah, right.  no nothing planned for that
<lifeless> barry: I don't think that *that* has been previously specced? Or maybe its the same thing (but I don't believe so?)
<barry> lifeless: no you're right, i misread
<ScottK> Wasn't the zope answer "Use buildout"?
<lifeless> ScottK: which is terribly unsatisfying
<barry> well, the python answer is buildout|virtualenv
<lifeless> in fact, you could use buildout + concurrent package installs
<lifeless> but until we support it in the core, its very hard to start sending better-support patches upstream
<barry> lifeless: if you create the blueprint/session i will definitely attend <wink>
<lifeless> barry: I'm seeking a champion :)
<lifeless> barry: and I figure, given your knowledge, that you're ideal!
<barry> lifeless: i am very sympathetic, but i have so much on my plate right now ;}
<lifeless> :(
<barry> lifeless: i'd really love to defer this until pycon 2011 time frame.  i want to sit down with tarek and maybe the fedora guys and think about what can be pushed into the core and what must be done on the distros
<barry> i know that sucks for you though
<lifeless> barry: ok
<lifeless> I doubt I'll be at pycon though
<barry> lifeless: apol if you've already done this, but at a minimum, can you write up a wiki page about what you'd *like* to see?  something that i can show tarek and say, "hey, what can distutils2 do to help us"?
<lifeless> barry: that mail I sent you :)
<lifeless> I'll look at something more referencable though
<barry> lifeless: yeah, i know.  email is so easily buried ;) (like wiki pages aren't easily forgotten)
<barry> lifeless: that would be great.  please know i understand how important this is and as i say i'm with you.  there are other things that have to get finished by 13-nov (python 3.2's beta 1)
<slangasek> ajmitch: brainstorming: I think a key here is going to be a client tool that keeps track of Packages files, can extract a list of updated packages from those files, and use that to decide which branches to pull from - to avoid polling 16k branches, one TCP connection at a time, when maybe only 200 branches have been updated that day
<lifeless> slangasek: context?
<ajmitch> keeping a local mirror of packaging branches
<lifeless> just use the ubuntu branches rss feed
<slangasek> lifeless: "UDD will always be slower than my local mirror until I can have UDD on my local mirror" :)
<slangasek> where's that?
<lifeless> looking
<lifeless> it *should* just exist, as the project group ones etc doo
<lifeless> but if it doesn't, I'll file a bug
<slangasek> ok
<slangasek> is the RSS feed over SSL?
<ajmitch> lifeless: want me to file a bug still for LP timeout OOPS that I run across?
<lifeless> ajmitch: god yes
<lifeless> ajmitch: if there isn't one tagged timeout
<lifeless> launchpad-project/+bugs?field.tag=timeout
<ajmitch> I'm guessing that https://code.edge.launchpad.net/~ubuntu-branches must be a fairly large list
<lifeless> ajmitch: yes
<lifeless> but thats not wher eyou should look
<lifeless> thats the old style
<ajmitch> there's a bug open for it at least
<lifeless> http://feeds.edge.launchpad.net/launchpad-project/revisions.atom is the lp project one
<lifeless> ok, there isn't an ubuntu one
<lifeless> I'll file the bug
<slangasek> ok
<slangasek> lifeless: what kind of detail will that give me?  For instance, if I want a mirror of all of main + a selection of packages from universe that interest me, will I get enough info from that RSS feed or do I need to poke at supplementary sources anyway?
<lifeless> slangasek: no idea; you could certainly use it to decide what to inspect and use germinate rules for better control
<lifeless> slangasek: how important is this
<slangasek> lifeless: I think having a flexible mirroring tool for UDD is a tipping point for its wider adoption; not necessarily asking you to dedicate resources to solving it right at the moment
<barry> do any sbuild users know how to make sbuild use an schroot session?  i have a locally built .deb that i'd like to build another package against.  i can create an schroot session and install that .deb but i can't figure out how to get sbuild to use that session when building the second package
<barry> sbuild --schroot `cat session-id` doesn't seem to work
<lifeless> slangasek: https://bugs.edge.launchpad.net/launchpad-code/+bug/664195
<ubottu> Launchpad bug 664195 in Launchpad Bazaar Integration "package branch feeds missing" [Undecided,New]
<barry> er, --chroot `cat session-id`
<ajmitch> slangasek: the other side of that is changing the bzr-lp plugin to prefer local repositories for fetching revisions from, so that you can still do 'bzr branch lp:foo'
#ubuntu-devel 2010-10-21
<doko_> micahg: icedtea-plugin available in the openjdk ppa
<micahg> doko_: cool, I'm still on maverick though, I was just wondering so I know what to do with bugs
<micahg> doko_: will that be in Debian as well eventually?
<ScottK> lifeless: I didn't say it was a good Zope answer, just the one we have.
<lifeless> ScottK: ;)
<TheMuso> Yay, tdb breakage...
<psusi> tdb?
<TheMuso> trivial database, used by samba, as well as a few other packages in Ubuntu, of which I maintain 2. I suspect its a gcc 4.5 related problem, just trying to confirm that first.
<ajmitch> TheMuso: what sort of breakage are you seeing?
 * TheMuso fetches a sample from a build log to pastebin.
<TheMuso> ajmitch: http://paste.ubuntu.com/517147/
<TheMuso> Ok, I am pretty sure its not gcc 4.5 specific.
<ajmitch> is it not including the #define for _PUBLIC_?
<TheMuso> I just built natty's version of tdb in maverick, and attempd to build pulse against it, and it failed in the same way.
<TheMuso> Haven't looked closely yet.
<TheMuso> I'm also getting the same failure with libcanberar.
<TheMuso> libcanberra even
<ajmitch> looking at the tdb source, _PUBLIC_ is defined in lib/replace/replace.h, if that's relevant
<TheMuso> Ok thanks.
 * TheMuso will dig some more...
<ScottK> ajmitch: Thanks for being TIL boost.
<lifeless> lol
<ajmitch> ScottK: of course I remembered that I forgot to reference the bug in the changelog about 20 seconds after uploading
<ScottK> Detail.
<ajmitch> so I get to complain about security uploads DoSsing the buildds until boost gets built :)
<ScottK> It build on i386, so I can test build anyway.
<TheMuso> ajmitch: Yeah _PUBLIC_ is not being defined anywhere in tdb.h, and it doesn't reference any other headers to get it.
<TheMuso> So, gotta sort that out.
<ajmitch> TheMuso: ping jelmer about it, he ought to know if tdb needs fixing
<TheMuso> ajmitch: Yeah, thats what I was thinking.
<TheMuso> Better yet, I'll file a bug in Debian.
<ScottK> Numpy is still going to screw with me I see.
<ajmitch> I'd expect that
<ScottK> It needs to be rebuilt for Python2.7 and it can't build right now because the new version build-deps on matplotlib which build-deps on wx2.8 and no suprise, that's not in Main.
 * ScottK shakes his fist at barry for not getting the transition done already.
<ajmitch> and noone really wants to support wxwidgets in main?
<ScottK> Open question.
<ScottK> matplotlib is a pretty sane piece of software.
<ajmitch> wx is a bit involved to check over
<ScottK> So we might bring it in and split it or split numpy.
<ScottK> Yep.
<ScottK> Or they might hoover the whole thing up.  Not sure.
<ScottK> Somehow my pbuilder update got a mix of ubuntu1 and ubuntu2 boost1.42.  The -dev are all ubuntu1 and the main ones are ubuntu2.  very odd.
<ScottK> Since it's i386, I'm not sure how that happens.
<ajmitch> that is just a bit strange
<ajmitch> & worrying
<ScottK> Yep.
<ScottK> Maybe wgrant knows.
<ScottK> (he seems to have insight into all the hidden warts in soyuz.
<ScottK> )
<ajmitch> especially as https://edge.launchpad.net/ubuntu/+source/boost1.42/1.42.0-4ubuntu2/+build/2011663 lists a whole lot of -dev packages for i386
<ScottK> I'm sure it's some weird archive skew thing that I didn't think was possible.
<ScottK> It shouldn't matter though.
<wgrant> What's borked?
<ScottK> (in this case)
<ScottK> wgrant: How'd I get that: http://paste.ubuntu.com/517164/
<ScottK> (it's all i386, so no architecture skew)
<wgrant> ScottK: boost-defaults or something looks out of date.
<wgrant> The unversioned -dev packages aren't in that build.
<ScottK> Ah.
<ScottK> Right.
<ScottK> Thanks.
 * ScottK slaps forehead.
<ajmitch> heh
<wgrant> Soyuz isn't broken again :D
<ScottK> That's fine.
<ScottK> wgrant: Soyuz isn't broken in that way.  I'm sure it's got something else to make up for it.
<wgrant> Indeed, indeed.
<wgrant> But it's not really my problem for a few weeks yet, so it can be broken now if it wants to be.
<ajmitch> until then, we pin the blame on someone else?
<wgrant> Please.
<ajmitch> I'm sure StevenK won't mind then
<ScottK> Only numpy stands in my way now.
<wgrant> Of what?
<ScottK> Being able to request removal of boost1.40.
<wgrant> Ah, excellent.
<ajmitch> it'd be nice to have only one version
<ajmitch> thanks to your source double-up for MPI
<ScottK> I'm thinking I'll drop the numpy docs for now and assign barry a bug to figure out how to get them back.
<ajmitch> is it just the docs causing the build failure, due to main/universe?
<ScottK> Yes.  matplotlib is just needed to build the docs.
<cr3> what might be wrong with having DH_ALWAYS_EXCLUDE in the debian/rules file? seems like calling debuild with -e explicitly seems to be the preferred approach
<danners> hi i try to integrate ubuntu 10.04 with active directory i use likewise which works fine. on login the users have do type domain\username which sucks for not computersavy users. so i got a patch which is included by suse and applied it by hand. now when i compile it it says: http://paste.ubuntu.com/517249/ can someone tell me what this kind of error means?
<pitti> Good morning
<pitti> SpamapS: hah, awesome!
<pitti> kirkland: can't move yet, needs testing
<tjaalton> danners: uhm, likewise should have a config option to use the default domain (just like "winbind use default domain = yes" in samba)
<tjaalton> danners: ah, seems it's only in the enterprise version.. sucks http://www.likewise.com/resources/documentation_library/manuals/open/likewise-open-guide.html#SetDefaultDomain
<danners> tjaalton: yeah that would have been perfect...
<dholbach> Good morning! :)
<ion> that.
<ajmitch> morning dholbach
<dholbach> hey ajmitch
<nigelb> morning ajmitch
<ajmitch> nigelb: it must just about be time for another behindthecircle interview to be released? :)
<nigelb> ajmitch: lucidfox and I are just swamped.
 * nigelb could only grab 3 hours of sleep last night :/
<ajmitch> fair enough
<dholbach> can somebody approve my mail to u-d-a?
<pitti> dholbach: looking
 * dholbach hugs pitti
<pitti> dholbach: the "Be young when making love", right?
 * pitti hugs dholbach
<pitti> dholbach: done
<micahg> cjwatson: if you get a chance, can you please approve my mail to devel-permissions
<dholbach> pitti, yes that one and the one about the 4th annual business jets conference please
<pitti> I had expected that one to come from Mark
<pitti> or did you get one as well by now?
<pitti> dholbach: just played around with new harvest, nice!
<dholbach> pitti, as I said in the mail: we might have to fix some of the "data feeds" and add new ones, but it should be good and easier to maintain now :)
<geser> dholbach: is there a way to filter on sponsoring for universe/multiverse?
<geser> in harvest
<dholbach> geser, there's just "unseeded" right now
<geser> which also lists packages in main (git-core) :(
<dholbach> geser, no, git-core exists in an older release, it's "git" nowadays
<geser> dholbach: harvest lists bug 636999 for sponsoring
<ubottu> Launchpad bug 636999 in git-core (Ubuntu) "[SRU] gitweb.js missing in gitweb package" [Low,Confirmed] https://launchpad.net/bugs/636999
<dholbach> geser, in launchpad it's git-core
<dholbach> although it should be git
<dholbach> harvest can't find git-core in any packageset
<dholbach> that's why it gets on the unseeded list
<geser> ah right, it was in main (till lucid)
<dholbach> yeah, it was renamed
<geser> but it's still confuses me on the sponsoring page too
<dholbach> ok, changed source package name
<dholbach> in the bug report
<geser> dholbach: do have an idea why bug 635406 is still listed in the FTBFS category?
<ubottu> Launchpad bug 635406 in libgc (Ubuntu Maverick) "armel build failure (no thumb support)" [High,Fix released] https://launchpad.net/bugs/635406
<dholbach> geser, no, I don't - that's weird
<dholbach> geser, ok found the bug
<geser> dholbach: what data format does harvest need? there is http://qa.ubuntuwire.com/ftbfs/natty.csv if harvest can use it (it can be changed if harvest need an other data format)
<dholbach> geser, it needs to be a tiny little bit different
<dholbach> just like http://reports.qa.ubuntu.com/reports/launchpad-database/ftbfs.csv
<dholbach> http://bazaar.launchpad.net/~harvest-dev/harvest/trunk/annotate/head:/HACKING
<geser> ok, will look at it and update the FTBFS data file
<dholbach> geser, bug 664356
<ubottu> Launchpad bug 664356 in harvest "Opportunities that are not in the final update of the opportunity list should not be displayed" [Undecided,New] https://launchpad.net/bugs/664356
<dholbach> I'll mark it as Critical
<geser> could a core-dev please give-back https://edge.launchpad.net/ubuntu/+source/pciutils/1:3.1.7-4ubuntu3/+build/2011386 so we get fresh logs (a bug in LP caused it). Thanks
<ajmitch> ok
<dholbach> geser, done
<ajmitch> looks like I was too slow
<geser> ajmitch: thanks for your try
<ajmitch> next time I'll have to setup my irc client to open the LP page & retry it automagically :)
<dholbach> geser, I got a fix for it, I'll try to get it reviewed soon
<YokoZar> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable   <-- what causes this error to occur (during --configure of a particular package)?  I suspect the problem is not in the package apport automatically files this against.
<StevenK> kirkland: I owe you your choice of beverage for the pointer to the 'alert' command
<pitti> cjwatson, slangasek: besides postgresql-common I also uploaded a new udev to lucid-proposed (see bug 653568); I'd appreciate a review
<ubottu> Launchpad bug 653568 in udev (Ubuntu Lucid) "mounting hardware encrypted usb stick failes" [Undecided,In progress] https://launchpad.net/bugs/653568
<bilalakhtar> bug #585468 has a fix in lucid-proposed for quite a long time, and till now nobody stepped up to test the proposed fix. But today RoAkSoAx checked the fact that the patch that I have applied is the same one that Debian and upstream have used. Can this be counted a a verification-done ?
<ubottu> Launchpad bug 585468 in cluster-glue (Ubuntu Lucid) "/usr/lib/stonith/plugins/external/sbd works uses wrong shell commands" [Medium,Fix committed] https://launchpad.net/bugs/585468
<pitti> bilalakhtar: we still need someone ot actually install that deb and confirm that it's working; it might have been misbuilt due to a race condition or toolchain change, etc.
<ogra> pitti, i merged all my alsa-utils changes into one upload now, can you delete everything greater than 1.0.23-2ubuntu3 from proposed ?
<bilalakhtar> ok thanks pitti
<ogra> i think at least one was accepted
<pitti> ogra: there's no alsa-utils in the queue
<ogra> pitti, i think you accepted my first upload
<pitti> ogra: but 1.0.23-2ubuntu3.2 is in maverick-proposed, so your upload needs to be bigger than that
<ogra> hmm, k, i didnt want to have multiple changelog entries for the same bug ... butu if there is no way around
<pitti> just add the new stuff and use -v
<jibel> bilalakhtar, and this sru needs a specific setup, so even if the deb installs, we can't say if the most basic functionality of the package is working.
<bilalakhtar> jibel: yes I know that
<ogra> pitti, ok, 3.3 uploaded, please accept it if it appears (additional fixes needed for the bug)
<jibel> pitti, I think that you can publish bug 582035 to lucid-updates too. The bugnum is missing from the pending sru list.
<ubottu> Launchpad bug 582035 in e2fsprogs (Ubuntu Lucid) "User cancel of fsck gives: "fsck.ext4: Inode bitmap not loaded while setting block group checksum"" [Undecided,Fix committed] https://launchpad.net/bugs/582035
<pitti> jibel: thanks!
<aselims> Hello
<kirkland> StevenK: \o/
<kirkland> pitti: hmm, okay;  there's another upload queued behind it then
<kirkland> StevenK: sure thing, i use it *every* day
<hyperair> kirkland: ping
<kirkland> hyperair: hi
<hyperair> kirkland: is there a reason /var/run/motd needs to be created from scratch every boot?
<hyperair> i was inspecting my bootchart, and i noticed that lsb_release takes an incredibly long time to finish
<sladen> kirkland: doesn't it have the landscape-pr0n added each time?
<kirkland> hyperair: lsb_release is really slow, yes
<kirkland> hyperair: what is blocking on /var/run/motd being created
<hyperair> kirkland: lsb_release.
<kirkland> sladen: only where landscape-client is installed
<kirkland> sladen: i mean landscape-sysinfo
<hyperair> kirkland: lsb_release is run at boot when motd is being generated.
<hyperair> kirkland: can't we cp /etc/motd /var/run/motd?
<kirkland> hyperair: and what blocks on lsb_release?
<hyperair> kirkland: what do you mean?
<kirkland> hyperair: /etc/motd is a symlink to /var/run/motd
<micahg> hyperair: how much of lsb_release is needed by motd?
<kirkland> hyperair: if it happens in the background at boot, who cares?
<kirkland> micahg: lsb_release -r basically
<hyperair> kirkland: because it wastes CPU cycles and disk seeks.
<hyperair> well of course, disk seeks are factored away with ureadahead, but we still have CPU cycles being wasted there that could go elsewhere.
<kirkland> micahg: i lied ... printf "%s\n" "$(lsb_release -s -d)"
<micahg> hyperair: kirkland: fta had performance issues with lsb_release and switched to sourcing /etc/lsb-release and that helped tremendously
<micahg> the issues were with chromium start time
<hyperair> heh that looks pretty awesome.
 * micahg doesn't know if that's available at boot time though
<kirkland> micahg: that looks reasonable
<hyperair> it should be.
<kirkland> hyperair: is there a bug number?
<hyperair> nope
<hyperair> do you want one?
<hyperair> i mean should i file one?
<kirkland> hyperair: sure
<pitti> kirkland: did you ever happen to use kvm with ipv6?
<kirkland> hyperair: i'm fixing it now
<hyperair> kirkland: thanks.
<kirkland> pitti: i don't think so ...
<pitti> kirkland: ok, thanks
 * hyperair starts looking into postfix taking 5 seconds to start
<kirkland> pitti: something particular you're looking for?
<pitti> kirkland: I'd like to test IPv6 in a VM
<pitti> seems I should try setting up a tap device on my host, attach a DHCP server on it which spits out IPv6 addresses, and then connect to that using -net tap / -net nic
<chrisccoulson> kees - do you know if gcc uses the gs segment register on x86 for anything specific?
<chrisccoulson> i'm still trying to figure out what it is that actually triggers this bug
<Ian_Corne> which kernel will be used in 11.04?
<micahg> Ian_Corne: that'll probably be discussed at UDS
<Ian_Corne> ok :)
<chrisccoulson> oh, i think i found the answer already kees
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<kirkland> hyperair: bug #?
<hyperair> kirkland: i just filed it and assigned you. i think you should have it..
<kirkland> hyperair: it's not in my inbox yet.  can you please paste the number here?
<hyperair> kirkland: i need to look. damn launchpad doesn't give you feedback when you file the bug over email
<hyperair> okay i think the first round didn't register. this one should >_>
<kirkland> hyperair: the commit is blocking on getting a bug number from you
<tkamppeter> pitti, I have posted a very important SRU, as with Maverick Duplex on HP inkjets does not work with most apps. Packages hplip and system-config-printer, bug 657357, bug 487695, bug 428588.
<ubottu> Launchpad bug 657357 in gtk+2.0 (Ubuntu) "GTK Printing Dialog: Duplex printing on HP inkjets does not work" [High,Confirmed] https://launchpad.net/bugs/657357
<ubottu> Launchpad bug 487695 in HPLIP "autoduplex constraints should be dropped" [Undecided,New] https://launchpad.net/bugs/487695
<ubottu> Launchpad bug 428588 in HPLIP "Problems with hpcups driver: Setting duplex too complicated, miscellaneous regressions" [Undecided,Confirmed] https://launchpad.net/bugs/428588
<jml> james_w: why is https://blueprints.edge.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning in "Other" and not "Ubuntu the project"?
<JontheEchidna> ogra: sorry for stepping on your toes with that bug report. :(
<ogra_ac> JontheEchidna, no prob, fix is uploaded now
<JontheEchidna> nice
<ogra_ac> JontheEchidna, and it was not you who missed the triaging ...
<ogra_ac> i guess i'll need to blog about armel triaging practice to make people aware
<JontheEchidna> yeah, that'd be great.
<ogra_ac> it was just that i already had the bugnumber in the changelog and the package ready
<ogra_ac> else i wouldnt have cared which is duplicate and which not
<JontheEchidna> totally understandable
<JontheEchidna> I try to help out w/ triage in that package when I can, but it still needs a bit of love
<ogra_ac> on arm it needs massive love
<ogra_ac> that build time neon detection doesnt fly, we will need a proper fix for runtime
<ogra_ac> for natty
<james_w> jml, no particular reason
<zyga> SpamapS, ping
<Riddell> ogra: could you renew my membership of canonical-arm-dev?
<ogra_ac> Riddell, indeed, with pleasure ;)
<ogra_ac> done
<Riddell> thanks
<cjwatson> ari-tczew: merge-o-matic already has a special blacklist, and it also already reads sync-blacklist.  please file a bug on merge-o-matic if you want it changed - requesting things on IRC isn't scaling well, particularly when I'm away
<hyperair> kirkland: i guess you've gotten your bug number/
<sladen> hyperair: kirkland: micahg: lsb_release really needs rewriting as a piece of C or Shell, currently IIRC it pulls in a mass of Python
<sladen> hyperair: kirkland: micahg: this had a use somewhere else;  it's forcing Python to be installed on basic systems
<sladen> hyperair: kirkland: micahg: bug #646795
<ubottu> Launchpad bug 646795 in lsb (Ubuntu) "lsb_release requires >9MB of Python, replace with C/Shell script" [Wishlist,New] https://launchpad.net/bugs/646795
<micahg> sladen: well, it serves multiple functions, maybe it can be split into a shell piece and a python piece
<cjwatson> micahg: devel-permissions> done
<kirkland> sladen: yeah, i've hated on lsb_release many times before
<kirkland> sladen: i like the idea of rewriting it in shell
<cjwatson> it should be done upstream, not in Ubuntu ...
<cjwatson> I think I said that in the bug already, too
<ogra_ac> could some SRU team member let my qt4-x11 upload through, so we have a chance to test it before UDS ?
<pitti> kirkland: like, "source /etc/lsb-release"?
<kirkland> pitti: yeah, basically
<kirkland> pitti: and a case statement to handle to couple of args lsb_release has
<pitti> kirkland: I meant, you are certainly not asking for the "user calls it interactively" case
<pitti> we recently changed the chromium startup script to try sourcing /etc/lsb-release first, and only call lsb_release if that fails
<pitti> bought us more than one second on armel :)
<kirkland> pitti: right, i just did the same in /etc/update-motd.d/00-header
<kirkland> pitti: and byobu has done that for a while too
<pitti> kirkland: right, for those you just source and use $DISTRIB_ID, etc.
<kirkland> so maybe we just need to find all the callers of lsb_release and fix them individually
<kirkland> alternatively, it would probably be easier to just "fix" lsb_release
<pitti> well, only for those where speed matters
<micahg> cjwatson: thanks
<kirkland> cjwatson: are you comments about upstream related to this lsb-release conversation, or to your conversation with micahg
<cjwatson> kirkland: this one, nothing to do with micahg
<kirkland> cjwatson: k
<cjwatson> (I thought it relatively obvious that complete reimplementations ought to be discussed upstream, but maybe I'm alone on this)
<cjwatson> /etc/lsb-release is an internal implementation detail of the lsb_release interface, even though it's pretty well entrenched in Ubuntu
<sladen> yup, which is why ideally it should be fixed in the executable call (/usr/bin/lsb_release is /the/ interface), whilst the presence of the file is a non-portable psuedo-standard
<pitti> hm, did anyone play with connecting two kvm instances through a vlan? I have tried to do that for half an hour now, and I can't get them to talk to each other
<pitti> I tried with -net user; do I need -net tap for this and create a tap device on the host?
<cjwatson> tseliot: sorry, don't know about your quilt problem.  plymouth isn't packaged the way I usually use quilt, so I find it hard to follow myself sometimes
<cjwatson> (I normally use separated patches for 3.0 (quilt) packages)
<tseliot> cjwatson: no problem, in the end I figured out how quilt is meant to be used ;)
<kirkland> pitti: i typically do it through a bridge
<cjwatson> merging that one with Debian is going to be interesting
<kirkland> pitti: the easiest way is to fire up virt-manager
<kirkland> pitti: otherwise, i can dig up some helper scripts for you
<pitti> kirkland: ah, ok; I'll try virt-manager then
<kirkland> pitti: with that, all your vms should be on 192.168.122.*
<kirkland> pitti: and be able to talk to one another
<pitti> kirkland: v-m has two networks "default" and "specify shared device name" -- that again asks me for a "bridge name"; so it seems I still need to create something locally then?
<pitti> on the default I'd get DHCP and everything, but I need a separate vlan
<kirkland> pitti: oh, the vlan is required?
<pitti> kirkland: one kvm should have "default" (eth0 with dhcp) and eth1 on a separate vlan, and another VM shuold have a single eth0 on the same vlan
<pitti> hm, maybe one vlan is enough, let's see
<pitti> kirkland: http://paste.ubuntu.com/517489/ was my first naive approach for taht
<pitti> kirkland: but the vlan1 of both instances aren't connected apparently
<kirkland> pitti: right, i think you'd a bridge for that vlan
<kirkland> pitti: let me see if i have something
<kirkland> pitti: http://paste.ubuntu.com/517495/
<kirkland> pitti: # To use, append the following on your qemu or kvm command line:
<kirkland> #   -net nic,model=virtio -net tap,script=/usr/sbin/qemu-bridge
<kirkland> # and make sure that uml-utilities exists (to create /dev/net/tun)
<kirkland> pitti: and i think you might have to use sudo kvm
<pitti> kirkland: ah, thank you
<kirkland> pitti: let me know if you're still struggling
<pitti> kirkland: with virt-manager it actually works
<kirkland> pitti: well there you go :-)
<pitti> that looks quite nice these days; it's been a while since I used it
<kirkland> pitti: yeah, it sucks far less than it use to :-)
<kirkland> pitti: i actually use it, any time i need two vm's to talk to one another
<ttx> pitti: when ant was upgraded to 1.8, debian kept an ant1.7 source package for compatibility with things that don't like 1.8... It's in universe right now, but is required to build tomcat6 (main). Do you need a MIR for it ? It's the same as the old ant_1.7, which was in main.
 * pitti throws hands into the air for even more java duplication
<pitti> ttx: anyway, I'm not in ~ubuntu-mir any more; we at least need a bug for tracking it, though
<ttx> pitti: we have a spec about that at UDS, feel free to join the therapy group
<ttx> "Java libraries housekeeping"
<pitti> ttx: but that sounds like an easy one indeed
<pitti> ttx: oh, good luck on that one!
<kirkland> pitti: btw ...  this doesn't solve your current problem, but since you like KVM hacks ...
<ttx> pitti: I file bug and subscrive ubuntu-mir ?
<kirkland> pitti: hallyn has done a great job putting together https://wiki.ubuntu.com/VirtFeatureVerification
<kirkland> pitti: which has short howto's on dozens of obscure kvm  and qemu features
<kirkland> pitti: there is a section on bridging in that page at least
<smoser> $ dpkg-query --show dmsetup
<smoser> dmsetup 2:1.02.39-1ubuntu4.1
<smoser> but dmsetup comes from source package lvm2, at version 2.02.54-1ubuntu4.1
<smoser> how does that happen ? i'm looking at the control file and dont see anything obvious to me.
<pitti> kirkland: ooh, that looks useful, thanks!
<kirkland> smoser: line 97
<kirkland> smoser: grep -n "Package: dmsetup" debian/control
<kirkland> smoser: http://paste.ubuntu.com/517509/
<smoser> i'm missing something obviously
<smoser> i'm confused on where the version differences come from
<kirkland> smoser: do you have the right sources?
<smoser> why dmsetup is '2:1.02.39-1ubuntu4.1'
<kirkland> smoser: what is this?  lucid?
<smoser> yes
<smoser> but the debian/changelog shows 2.02.54-1ubuntu4.1
<kirkland> smoser: yeah, there's an epoch bump in there;  i'm looking for the source
<kirkland> smoser: see debian/*symbols
<cjwatson> look at the dpkg-gencontrol calls in debian/rules
<cjwatson> and the DEVMAPPER_* stuff at the top
<kirkland> ah yes, there it is, in debian/rules
<smoser> ok. that makes more sense now.
<kirkland> pitti: thank hallyn, he did 99% of the work on that page :-)
 * pitti sends hallyn some cookies
<smoser> hm.. ok. so, given a package manifest that says 'dmsetup 2:1.02.39-1ubuntu4.1' and one that says '2:1.02.39-1ubuntu4'
<smoser> do i have *any* hope of determining which changelog blocks for lvm2 were relavant
<smoser> in order to do that, it would seem that i would have to determine that 2:1.02.39-1ubuntu4.1 was built by 2.02.54-1ubuntu4.1 and 2:1.02.39-1ubuntu built by lvm2 at version 2.02.54-1ubuntu4
<smoser> is that at all possible or am i SOL .  in this particular case, the archive could possibly help me as both those versions would exist, but its possible that one does not (if it had been replaced in -updates)
<SpamapS> zyga: pong, yes?
<zyga> SpamapS, hi
<zyga> SpamapS, you registered a very interesting blueprint that I want to attend :)
<zyga> SpamapS, about command-not-found improvements
<zyga> SpamapS, could you tell me briefly what you'd like to see happen?
<SpamapS> zyga: With command-not-found, its somebody else's idea, but basically, instead of just doing a string match on the files in packages, have common misunderstandings resolved by offering alternatives that maybe aren't spelled at all the same.
<zyga> SpamapS, hmm, could you be more specific? I don't understand you exactly
<SpamapS> zyga: the example is to suggest tracepath when somebody types 'traceroute' and its not installed.
<zyga> yes, I remember that issue
<SpamapS> or you could also suggest 'mtr'
<zyga> I worked to resolve it but I did not finish my rewrite
<damascene> What do you think of having Ubuntu Fedora testers? many bugs will be discovered there before it land in Ubuntu if there were enough testers.
<zyga> so you'd like to see a general suggestion framework?
<zyga> damascene, ?
<SpamapS> zyga: yes, my hope is we can embed the suggestions somewhere in the packaging information.
<SpamapS> zyga: please excuse me, I have to run out and move my car to the other side of the street...
<mneptok> damascene: Fedora should be reporting their bugs upstream (and do for GNOME at least) at which point the bug becomes distro-agnostic.
<zyga> SpamapS, that would be awesome, it also aligns with other changes linaro would like to do there (delcarative alternatives) but it's an big volume of work in _Debian_
<zyga> SpamapS, I'd love to help that to happen
<zyga> SpamapS, but we can do something else before such extensive features land
<zyga> SpamapS, we might extend the control files with some attidional meta-data that c-n-f could pick up
<zyga> SpamapS, did you see how c-n-f data is obtained?
<damascene> mneptok: zyga. I think testing fedora could help Ubuntu stability but I think the problem is their lack of tester. you might know better.
<damascene> *lack of testers.
<zyga> damascene, lack of testers might be translated to lack of automatic tests that make sense - I'd love to see that fixed
<zyga> damascene, especially very _high level_ tests
<dholbach> geser, so I got the fix reviewed, now I just wait for somebody in IS to deploy it
 * mneptok tacklehugs dholbach 
<zyga> SpamapS, do you plan on working on that blueprint? (who will be the asignee)
<damascene> zyga: I'm a simple user and when I was testing Ubuntu beta, some fedora release user were having the same bug.
<dholbach> hey mneptok
<SpamapS> zyga: no I haven't dug into the internals of c-n-f yet. I do intend to work on it, or maybe kirkland, I know he's interested in it as well.
<azeem> have there been many complaints that the "admin" group is too similar to the "adm" group?
<zyga> SpamapS, I'd love to be a part of that as I wrote the program and have a vastly improved version on my disk (based on different architecture and dbus)
<damascene> would you like to have the domain upaste.org instead of the paste.ubuntu.com/
<damascene> I find it is easier to use fpaste for Ubuntu than it's own.
<SpamapS> zyga: cool! Will you be in attendance then?
<zyga> SpamapS, yes, I subscribed myself as essential
<zyga> SpamapS, I'd also like to see some interaction between mvo's software center as the data source seems to be getting similar
<zyga> SpamapS, and getting a common API for everything would benefit people using ppa's/other repos (currently there is no way to support this in c-n-f without a dedicated package that the repo contains and someone has to install
<SpamapS> zyga: awesome. Make sure to introduce yourself at the beginning so I don't cut you off as a blowhard wannabe when you start schooling all of us on how it works. ;)
<zyga> hehe :D
<zyga> I'll stay silent and bash you as newbies at the end ;-)
<zyga> SpamapS, it's awesome you are working on this, I'd love to see this happen and will definitely help you, see you at the session
<kirkland> Spads: what is c-n-f?
<zyga> mvo, do you imagine we could work on getting some extra metadata into dpkg this cycle and have a centralized service that would allow you to access that metadata from aptd somehow?
<zyga> kirkland, command-not-found
<kirkland> ah
<SpamapS> kirkland: we were discussing bug 508606 and the blueprint its attached to https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-commandline-userfriendly
<ubottu> Launchpad bug 508606 in Command Not Found "Recommend tracepath for "traceroute" and "tracert"" [Wishlist,In progress] https://launchpad.net/bugs/508606
<SpamapS> kirkland: I seem to recall you had an interest in that bug, though I may be mistaken.
 * zyga just needs some motivation to finish his new-and-shiny branch
<tkamppeter> pitti, mvo, hi
<mvo> zyga: command-not-fond as additional data into the pakcages file? that would be doable
<mvo> hey tkamppeter
<zyga> mvo, that would be perfect but the point here is to be able to query a single service for it _and_ to make it work with custom repos with new packages
<zyga> mvo, it sounds like some extra data that'd need to be visible at apt level _or_ some hook similar to what you do with software center metadata in extra repos (but I don't know how that works)
<tkamppeter> mvo, we talked earlier here in the IRC also with pitti about the needed changes in Jockey and for the keys to be shipped with Ubuntu so that manufacturer-supplied printer drivers from OpenPrinting can be autom,atically downloaded. Do you remember?
<zyga> mvo, essentially two tasks 1) make each repo  drop a file somewhere  + 2) proposal to have better API for getting that data
<jmelis> hi, I have some doubts regarding uploading packages to a PPA. I have created a package and uploaded it successfully to the PPA, but I realised it doesn't have the suffix of ~lucid1 (I need that suffix because the package needs to be recompiled for each Ubuntu version) so I erased it from the PPA. My question is, where do I have to add this suffix ~lucid1? renaming the changes file is enough?
<mvo> tkamppeter: vaguely
<mvo> zyga: 0) extract the data from the repo on build/publishing time
<zyga> mvo, correct
<mvo> zyga: there is a long term plan for this, with this step solved I think the rest is trivial
<mvo> zyga: it requires soyuz hook in the way I envision it
<mvo> zyga: I would love to discuss this at uds
<zyga> mvo, and -0.5) decide if this data is declerative or somehow automatically guessed which is a deeper dpkg problem
<zyga> mvo, during which session?
<mvo> heh :)
<zyga> declarative even
<tkamppeter> mvo, we did not get this implemented in Maverick, but in Natty we should do it.
<mvo> tkamppeter: will you be at uds?
<tkamppeter> mvo, should we have a meeting to coordiante this on the UDS? Should it only be  pitti and you or perhaps someone else to participate in the meeting?
<tkamppeter> mvo, I will be on UDS, as always since fall 2006.
<kirkland> Spads: thanks, i just subscribed to it
<kirkland> SpamapS: ^
<kirkland> Spads: gah
<mvo> tkamppeter: great, lets schedule a meeting there
<SpamapS> tkamppeter: Did you want to add it to the spec about improving the command line experience? Or is this much bigger than that?
<mvo> zyga: I think its worthwhile to have a session about this (maybe even informal)
<mvo> zyga, tkamppeter: I need to leave for dinner now, sorry
<zyga> mvo, shall I schedule it?
<SpamapS> kirkland: did you have other stuff you want to throw in there? I always appreciate the compassion for users that your ideas bring. ;)
<zyga> mvo, k, see you
 * kirkland blushes
<kirkland> SpamapS: aw, SpamapS
<SpamapS> kirkland: well lord knows somebody has to care about them.. most of us are more the "send them over the hot coals, the ones that come out the other side can keep talking to us" types. ;)
<pitti> tkamppeter, mvo: quick meeting is fine for me
<tkamppeter> SpamapS, which spec about command line experience? I think it has nothing to do with command line experience. Automatic printer driver download should happen if the user plugs in a printer and system-config-printer does not find a driver for the printer on the local system.
<pitti> ogra_ac: qt4-x11> ah, that already hit us in an OEM project; nice catch
<SpamapS> tkamppeter: ahh, yeah, thats a bit out of scope.
<zyga> tkamppeter, apple did that for snow leopard, since they also use cups maybe we might see some common code that they have
<tkamppeter> pitti, who should participate and how should I obtain a slot? "Informal" Blueprint?
<pitti> tkamppeter: not sure who planned UDS for desktop this time; we already have a bug report, so a non-blueprint meeting will do
<pitti> rickspencer3, seb128: hey, how's the sprint going? wo planned UDS for desktop?
<rickspencer3> pitti, uh, no one?
<rickspencer3> pitti, are there things missing?
<pitti> tkamppeter: Till was asking for a new meeting above
<rickspencer3> ah
<rickspencer3> well, with the new theme-based tracks, it's a bit more complicated
<rickspencer3> pitti, if someone makes a blueprint and pastes me a link, I'll take care of it
<tkamppeter> pitti, rickspencer3, I have also scheduled a meeting for something else and had to put it under "Other" because there was no desktop track.
<pitti> rickspencer3: we have a bug report for it so far
<rickspencer3> ah
<ogra_ac> pitti, yeah, hits me hard on the ac100 atm ... :)
<rickspencer3> well, without a blueprint, it'll be hard to schedule, with a blueprint it will be easy to schedule ;)
<ogra_ac> (tegar2 , no neon... just got sound working ... mumble is Qt :p)
<pitti> tkamppeter: ^ seems we do need a BP then :)
<ogra_ac> *tegra
<tkamppeter> pitti, so I will make one, referring to the bug report, and making you and mvo required participants. Anyone else who should participate?
<pitti> tkamppeter: I think the three of us will be fine
<tkamppeter> pitti, OK.
<seb128> pitti, hey, sprint going well
<jml> james_w: I just noticed your bug at https://bugs.edge.launchpad.net/launchpad-code/+bug/603606
<ubottu> Launchpad bug 603606 in Launchpad Bazaar Integration "Recipe Build failure emails aren't as binary package build failures" [Medium,Fix released]
<jml> james_w: would you have been ok with a fix that addressed all of your concerns but didn't follow the binary build failures as closely?
<tkamppeter> pitti, I have forgotten the naming convention for the BP, would should I do? Forget it and start over? Or can one rename it?
<tkamppeter> pitti, sorry, I have found the solution.\
<tkamppeter> pitti, still there?
<james_w> jml, abentley and I discussed that in depth, as he felt that following the binary build failure mails was too constrictive, and that they weren't as useful as they could be. I encouraged him to improve both of them to keep them consistent and have them both be useful. He said that he wasn't happy modifying another team's code, and wanted to just fix that particular email.
<jml> james_w: ok, thanks. I'm inclined to agree with you.
<smoser> anyone able to confirm this for me ?  i know that binary package previously 'P' existed at version 'V' in one of <suite>, <suite>-updates or <suite>-security.
<smoser> there is no guaranteed way to convert that binary package to a source package and version
<james_w> jml, as to your original question, the mail were pretty awful, so any improvement would have been good. I was keen to follow the spirit of the other emails, but wouldn't have kicked up a big stink if that wasn't the way that it was going to go. I think it's unfortunate that nobody ended up happy with the eventual fix.
<jml> james_w: *nod*
<micahg> smoser: you can grab the source from LP
<smoser> archive data can only provide me with the most current version in any of those pockets. and since source version != binary version, i'm stuck.
<smoser> micahg, but i can't even definitively determine which source to grab
<jml> james_w: I'm going through the daily builds stuff now, trying to identify things that need to be done before we consider it to be finished
<jml> james_w: most of it is polish on things like this.
<micahg> smoser: not sure what you're asking for
<tkamppeter> pitti, the CUPS SRU has broken the build servers. see http://launchpadlibrarian.net/57980548/buildlog_ubuntu-maverick-i386.hplip_3.10.6-1ubuntu10.1_FAILEDTOBUILD.txt.gz
<james_w> jml, that's good to know
<smoser> micahg, i know that at one time, a installed system contained binary package 'P' at version 'V'. and I need to determine what *source* (and version) built that.
<micahg> smoser: if you know the version, you can go to LP and grab the source that built it
<micahg> smoser: build logs are available as well so you can see what deps were usedc
<smoser> micahg, but i dont know the version
<smoser> i know the binary version
<smoser> assuming i can convert binary package to source package (which assumes that a binary package didn't move source packages) binary version != source version
<micahg> smoser: huh? binary should be the same as the source version
<smoser> no. i made that assumption.
<micahg> smoser: all packages in teh archive are built from a source version and the binary packages inherit that source package version
<smoser> current lucid dmsetup is dmsetup 2:1.02.39-1ubuntu4
<smoser> which was built by lvm2 version 2.02.54-1ubuntu4
<smoser> (read backscroll for others giving me help to that)
<micahg> wow, I see that, weird
<micahg> smoser: is that the package you're looking for?
<smoser> i'm looking to solve the general problem
<smoser> i can manually determine it for a given package
<micahg> smoser: there might be something in the LP API to help, idk
<tkamppeter> Can it be that the buildds for maverick is broken?
<barry> ls
<nemo> Hey guys. I'm trying to find bugs on Xorg memory usage - is this a known issue in maverick?
<nemo> (mine seems to be steadily climbing.  an increase of 50 megs in just the past hour)
<_Groo_> hi/2 all
<_Groo_>  just a quick notice, alsa-utils (1.0.23-2ubuntu3.3) post install script is broken
<didrocks> doko: hey
<didrocks> doko: do you know a little about cython?
<nemo> And since I asked that question about 40 minutes ago, memory has gone up another 32 megs
<nemo> guess I'm going to have to log out and restart X
<ogra_ac> crimsun, hmm, what did i mess up ?
 * ogra_ac doesnt see the issue 
<ogra_ac> oh my !
<ogra_ac> pitti, still around ?
 * ogra_ac now sees it 
<seb128> ScottK, there is no need to play close, reopen with bugs
<seb128> it's usually not an useful way to get what you want
<nemo> aaand one reboot later.  memory usage is at 132m
<cjwatson> smoser: you could iterate through all versions of the source package known to build that binary, and look at which binaries they generate
<cjwatson> smoser: (obviously LP should be enhanced to give you a more efficient lookup mechanism, but the information is all available)
<smoser> cjwatson, i dont think it is exposed via lp
<smoser> just talked some with lifeless and james_w in #launchpad and opened https://answers.launchpad.net/launchpadlib/+question/130600
<ogra_ac> cjwatson, could you let alsa-utils_1.0.23-2ubuntu3.4 into proposed ? the alsa guys drown in bugs due to a mistake i made in 3.3
<smoser> i was going to attempt what you were proposing
<ogra_ac> (pitti seems to not be around and i want to stop the bug flooding asap)
<cjwatson> smoser: each source_package_publishing_history object has a getPublishedBinaries method, and the binary_package_publishing_history objects that returns each have binary_package_name and binary_package_version properties.  So you can work it out, it's just slow
<smoser> oh.
<smoser> i guess i left something out (i think)
<smoser> build.current_source_publication_link is empty for anything not in current archive
<cjwatson> smoser: you can't go backward from the build, no, I didn't say you could
<cjwatson> that was why I was saying that unfortunately AFAIK you have to go forward from every possible source
<cjwatson> might want to build a cache :-)
<smoser> yeah.
<smoser> i guess i'm confused.
<smoser> how do i get a list of source_package_publishing_history
<cr3> what would be the best practice for packaging web projects which include html and js files? could they go under /usr/lib/python2.6/site-packages... or should they really go under /usr/share/project?
<seb128> cr3, hey
<cr3> seb128: ahoy, matey!
<seb128> cr3, how are you?
<cr3> seb128: working hard... you'd think that it might be more relax once releases become stable but it just continues :)
<cr3> seb128: and you, looking forward to uds?
<seb128> yes
<cjwatson> smoser: getPublishedSources() on an archive object (probably lp.distributions['ubuntu'].main_archive)
<cjwatson> cr3: non-python files shouldn't go in /usr/lib/python*/, as far as I'm aware
<cjwatson> /usr/share/<package> would be better
<cr3> cjwatson: what about /usr/share/pyshare, same thing as /usr/lib/python*?
<cjwatson> cr3: but they aren't python files, so shouldn't go in python directories
<cjwatson> /usr/share/pyshared/ is a directory used by one of the python helpers to organise python files across multiple versions of the interpreter
<cr3> cjwatson: understood, I was using launchpadlib as an example which has /usr/share/pyshared/launchpadlib/wadl-to-refhtml.xsl
<chrisccoulson> kees - any thoughts on this gcc/FF issue? I'm starting to get really stuck now ;)
<kees> chrisccoulson: I haven't had time. we can pick doko's brain at UDS, though
<chrisccoulson> kees - sure, that's ok
<chrisccoulson> thanks
<kees> chrisccoulson: sure thing. :)
<smoser> cjwatson, it appears you are correct.
<cjwatson> cr3: hm!  well, evidently there is prior art; all I can say is that I certainly wouldn't have done it that way
<doko> chrisccoulson, kees: yes, please lets delay until next week
<chrisccoulson> doko - thanks
<jmelis> Hi, can someone give me a hand with the upload of a package to a PPA? last version was 1.2-0ubuntu5. Since there is a new upstream version the new version should be 2.0-0ubuntu1 BUT it needs to be recompiled for each release, so it's unclear if it should be 2.0-0ubuntu1~lucid1
<statik> jmelis: yep, that is what I would use
<jmelis> statik: problem is, I'm trying to upload the changes file with dput and it says "unable to find ...orig.tar.gz in upload or distribution"
<ansgar> jmelis: The first upload has to include the upstream tarball. Pass -sa to debuild/svn-buildpackage/... to include it. (You can check the .changes file to be sure.)
<jmelis> ansgar: great!
<slangasek> pitti: postgresql-common accepted, sorry for the delay
<slangasek> pitti: btw, why is the bzr-vcs branch for this pointing at a personal branch?  Should this be lp:ubuntu/postgresql-common instead?
<BUGabundo> guud evening everyone. may the moon shine over you
<TheMuso> Oh, my, goodness. Sooo many people have maverick-proposed enabled when they *probably* shouldn't.
<ajmitch> TheMuso: getting a few alsa bugs?
<TheMuso> ajmitch: urm yeah, alsa-utils to be precise.
<ajmitch> at least you know that people are testing the uploads to -proposed :)
<ajmitch> looks like a new version was published for -proposed 5 minutes ago
<TheMuso> Yeah I know.
<poolie> yeah, i just saw that too
<poolie> a version that fixes it was pushed?
<TheMuso> ...until then, more bugs will come in as people who use laggy mirrors hit the bug.
<poolie> TheMuso: how do you dispose of the dupes?
<poolie> i mean, do you do it through the web ui, or by mail, or ...?
<TheMuso> poolie: I do as much via mail as I can. Especially with dupes like this, its 10 times faster, particularly since mutt caches my GPG passphrase for a short time.
<poolie> you can try using hydrazine's bugclient if you want
<TheMuso> I knocked over about 6-7 dupes just then, probably taking me about 3-4 minutes.
<poolie> it's a text mode interactive too
<poolie> *tool
<TheMuso> Hrm will have to check that out at some point, but I am used to the email interface atm.
<poolie> it does have the drawback that atm it makes synchronous api calls which can be slow
<TheMuso> Thanks for the suggestion.
<poolie> sure, just though i'd mention it
<poolie> 'bug 664815' 'duplicate 664807' etc
<ubottu> Launchpad bug 664815 in alsa-utils (Ubuntu) "package alsa-utils (not installed) failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/664815
 * poolie pets the bot
#ubuntu-devel 2010-10-22
<TheMuso> 1/c
<psusi> I'm getting unexpected change events on a partition device according to udevadm monitor, is there a way to get more information on why the kernel is emitting the event?
<psusi> I thought a change event on a disk meant the partition table changed... why on earth with a partition emit a change event?
<\sh> moins
<dholbach> Good morning!
<\sh> hey dholbach *hatschew*
<dholbach> hi \sh
<dholbach> Gute Besserung! :)
<\sh> dholbach: danke :)
<\sh> three days in bed...:(
<dholbach> ugh :(
<\sh> dholbach: but regarding the weather outside, I think it's normal to have a cold these days
<dholbach> I'm not a big friend of the weather either :)
<bilalakhtar> dholbach: in orlando?
<\sh> it's just too cold for autum...
<dholbach> bilalakhtar, Berlin, Germany
<bilalakhtar> dholbach: ah, I thought you reached for the UDS :)
<dholbach> Orlando will be different :)
<dholbach> tomorrow afternoon I'll be there
<bilalakhtar> cool
<pitti> Good morning
<pitti> tkamppeter_: no, was already off; you can rename blueprints, yes
<pitti> ogra_ac: hello
<pitti> slangasek: p-common> thanks! the trunk is in ~pitti, because I upload those to Debian and sync over; but yes, the Ubuntu stable ones should be reowned; I'll do that on the next SRU, when I can update Vcs-Bzr
<pitti> tkamppeter_: ah, indeed -- cups-ppdc is in universe
<pitti> tkamppeter_: seems we need to update cups again to move the files to cups-common, sorry
<pitti> apw: good morning! do you know who uploaded linux-linaro? It needs to be reuploaded with -v to include previous changelogs
<apw> pitti, normally that is rtg
<pitti> apw: thanks
<apw> pitti, if you know the -v you want i might be able to sort it out
<pitti> -v2.6.35-1006.12 (maverick final)
<apw> pitti, and what version did he actually upload?
<pitti> apw: there are two uploads in the unapproved queue, so in theory they could just be merged into one rev; but I guess that'd juggle git too much
<pitti> apw: latest is 2.6.35-1008.15
<pitti> in unapproved
<pitti> .15 and .14 are in the queue, .13 is in -proposed, but untested
<pitti> so the .15 upload needs to cover all three
<pitti> cover -> in .changes
<apw> got ya
<pitti> apw: cool, thanks; rejecting the current two
<pitti> jdstrand: can you please update the lucid tasks for the apparmor SRU? many are missing, some are already marked as "fix released" (which sounds wrong?), and some are "won't fix" (contradiction?)
<pitti> jdstrand: also, the changelog points out that this needs adjustment of third-party profiles in some cases; that makes me nervous
<apw> pitti, ok just uploaded, should be in the queue shortly
<pitti> apw: thanks
<apw> pitti, do shout if its not right
<ajmitch> Rush
<ajmitch> hm
<pitti> apw: hm, nothign in the queue yet
<apw> pitti, let me check
<apw> pitti, ahh a permissions issue, am working on getting it resolved
<tkamppeter_> pitti, hi
<pitti> hi tkamppeter_
<tkamppeter> pitti, it is about the CUPS SRU. Can one not simply move cups-ppdc to main?
<pitti> tkamppeter: we can't retroactively fix maverick final; we can technically move it in maverick-updates, but not sure whether that'd break anything else; cjwatson, WDYT?
<cjwatson> pitti: that would be OK
<cjwatson> jibel: re your comment 19 on bug 664645 - please see slangasek's comment 5 on the same bug for why it was Fix Released rather than Fix Committed
<ubottu> Launchpad bug 664645 in alsa-utils (Ubuntu Maverick) "package alsa-utils 1.0.23-2ubuntu3.3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,Fix committed] https://launchpad.net/bugs/664645
<pitti> tkamppeter: ok, moved to main; we missed the publisher by a minute, so hplip build can be retried in two hours
<jibel> cjwatson, oh right. Thank you.
<tkamppeter> pitti, thanks.
<pitti> apw: hm, still nothing in queue - forgot to kill the .upload file or so?
<dholbach> geser, it should be fixed now
<geser> thanks
<apw> pitti, it seems it just took a long time, its there now
<bilalakhtar> bdrung: Any news on that audacious maintainance thing?
<wgrant> Hm, this cups thing forces a "partial upgrade" on everyone :/
<bilalakhtar> wgrant: Not for me
<bilalakhtar> wgrant: You mean the recent cups SRU?
<wgrant> Oh.
<wgrant> That may actually be the resolver breaking on something else, i suppose.
<wgrant> But cups wasn't checked for upgrade by default.
<wgrant> Maybe the other failures made it angry.
<Ian_Corne> Is this the correct place to "complain" about a lacking kernel update?
<bilalakhtar> Ian_Corne: go ahead, we will suggest the proper place then
<bilalakhtar> Ian_Corne: though #ubuntu-kernel
<bilalakhtar> would be better
<ogra_ac> pitti, all sorted now, there was a bug in my postinst in alsa-utils that caused a bug flood, slangasek accepted the fix quickly though
<tkamppeter> wgrant, bilalakhtar: The problem of the CUPS SRU was that a new dependency on a package in Universe was added. If a user has no Universe activated (or if you are on the buildds) CUPS fails to install/update.
<bilalakhtar> oh! But why was such a change made after release?
<tkamppeter> wgrant, bilalakhtar, this is fixed now (by moving the package cups-ppdc to main) and the fix will appear in around one hour.
<bilalakhtar> tkamppeter: yes, I just discovered the flaw by apt-cache searching
<tkamppeter> bilalakhtar, the cups-ppdc contains some files which the main cups package needs to build the PPDs for the drivers which CUPS ships. These drivers are very rarely used and most developers and ddevelopment version users have Universe activated, so the bug was seen only after release.
<bilalakhtar> aha!
<bilalakhtar> yes, I got to the bug report
<bilalakhtar> bug #485383
<ubottu> Launchpad bug 485383 in cups (Ubuntu Maverick) "Zebra driver not found" [Medium,Fix released] https://launchpad.net/bugs/485383
<tkamppeter> bilalakhtar, and these label printers are only supported by the drivers which come with CUPS. For all other printers there are more sophisticated drivers like HPLIP or Gutenprint.
<bilalakhtar> yup
<bilalakhtar> Thanks tkamppeter for the fix
<Ian_Corne> thanks bilalakhtar I reported there
<akgraner> Hey all I wanted to share with you something that Associate Publisher, Linux New Media posted on Facebook this morning praising the Ubuntu Developers (its a couple lines sorry if I am flooding you all)
<akgraner> Rikki Kite (via Facebook) "I would like to take this moment to thank the Ubuntu developers -- U Rock. I didn't bother reading the instructions for my new HP printer/copier/faxer or running the Windows/Mac 'starter CD'. I just plugged her in, Ubuntu searched for the drivers, and away she prints! Yay Ubuntu! Yay for not having to read the stinking printer manual!"
<pitti> tkamppeter: ^
<pitti> *applauds*
 * nigelb sends hugs to Desktop Team
<ogra_ac> wow, tkamppeter, congrats !
<TheMuso> ogra_ac: The only annoying thing about the error with alsa-utils, is that it shows how many people run proposed when they probably shouldn't/don't need to.
<ogra_ac> TheMuso, yeah, i was a bit shocked about the flood
<ogra_ac> but its all fine now, sorry for the bugmail spam
<TheMuso> ogra_ac: Its ok, I am m more shocked at users running proposed, as above.
<ogra_ac> yeah
<ScottK> Last I looked, the way it's described in the GUI for adding repositories isn't nearly scary enough.
<ogra_ac> TheMuso, btw, do you have an idea why we dont create any debvices in /dev/snd anymore ? is it a deliberate decision to not be compatible with alsa only setups anymore ?
<tkamppeter> Thanks, setting up supported printers with Ubuntu is MUCH faster than under Windows, and no reboots at all.
<TheMuso> ScottK: I am enclined to agree.
<TheMuso> ogra_ac: Udev takes care of all /dev/snd stuff.
<ogra_ac> TheMuso, well, i have some HW where it doesnt
<ogra_ac> i need to create a rule in /etc/udev/rules.d to have devices under /dev/snd to make it work at all
<ogra_ac> (its a non std. kernel on very exotic HW)
<TheMuso> ogra_ac: Right, does support exist for the hardware upstrea? If so, the udev glue should probably go somewhere upstream as well.
<rneese_> morning
<ogra_ac> TheMuso, no support upstream yet, its an arm tegra2 (the toshiba ac100), there is only a 2.6.29 kernel for it with ubuntu config, the sound device needs special initialization by a proprietary nvidia tool initi
<rneese_> anyone here good with how remaster a cd and make it install extra pkgs
<TheMuso> ogra_ac: Right.
<rneese_> looking to have a custom cd for installing a pbx setup
<rneese_> I have a script that does it now
<ogra_ac> TheMuso, if i dont divert pulse on that HW (without initializing the sound device) pulse goes into an endless probe loop and consumes 100% CPU
<rneese_> but we want a iso to do all the work
<ogra_ac> TheMuso, so i tried to use a soundblaster play (USB soundcard) which i can only make work with the udev hack
<ogra_ac> TheMuso, the rules are trivial and just make sure sound devices end up in /dev/snd instead of /dev http://paste.ubuntu.com/518017/
<rneese_> https://help.ubuntu.com/community/InstallCDCustomization is what I am reading now
<ScottK> barry: I'm unable to replicate the python2.7 build failure on powerpc (builds fine on the hardware I have access too).  I was thinking it might make sense to try not doing the profiled build on powerpc as that's solved similar issues in the past.  Unfortunately I'd have to just heave it at the buildd's and see.  Thoughts?
<rneese_> so no remaster specialist here
<TheMuso> ogra_ac: hrm interesting indeed. I think I'd want to work out what causes most things for most people to work normally, i.e things go into /dev/snd, since there are no rules to do that on my system, so far as I can see, so I think it must be done at the kernel level.
<ogra_ac> TheMuso, well, we used to have rules to create the devices in /dev/snd until lucid i think and gstreamers alsasink looks there for cards
<ogra_ac> TheMuso, but i can well understand if there was an upstream decision to drop the old behavior
<ogra_ac> the kernel by default creates them in /dev which is what we have today
<TheMuso> ogra_ac: Hrm ok, I'll have to investigate that further, we may have missed something with packaging...
<TheMuso> Anyway, afk.
<rneese_> anyone here good with modifying the ubuntu-server iso to add a post install script
<persia> rneese_, Generally post-install scripts are done on a per-package level, rather than per-image level (although the installer supports certain sorts of things if absolutely required).  I'd suggest describing the thing you wish to accomplish (not the technique by which you might do so) in #ubuntu-server.
<rneese_> looking for a way to use the ubuntu-server iso to install a 1st boot script that will add pkgs and configure the system
<rneese_> I wrote a script yesterday
<rneese_> we are working to get a iso that builds our pbx system
<rneese_> or make the iso install all the needed pkgs with out having to reboot to do it
<persia> Oh.  You probably want to read the installation-guide for your architecture, and use some preseeding.
<rneese_> looking at preceed.txt now
<rneese_> thing is I have no understanding of how ubuntu does it compaired how we do it on bsd
<rneese_> the preceed txt is just not easy to grep at first
<cjwatson> simply installing extra packages can be done with pkgsel/include
<cjwatson> general post-install commands can be run using preseed/late_command
<cjwatson> you should be able to grep for those two keys
<rneese_> well have to add the 3 repos
<cjwatson> preseed.txt probably isn't particularly good - use https://help.ubuntu.com/10.04/installation-guide/i386/appendix-preseed.html
<cjwatson> https://help.ubuntu.com/10.04/installation-guide/i386/preseed-contents.html#preseed-apt explains adding local repositories
<rneese_> been reading but I guees its to diff from bsd my mind is not greping
<rneese_> will read more
<rneese_> I have to have a iso by end of the weekend
<rneese_> thought maybe someone here was good enogh to look at the script and suggest/help with a cleaner faster way
<rneese_> but dont want to overstep
<cjwatson> I'm happy to look at an existing preseed file; I'm unlikely to be able to help with something done any other way
<rneese_> I just found out about the preceed this am
<rneese_> only have the script I wrote
<rneese_> that might have to merge into the preceed
<barry> ScottK: re: python2.7 on ppc.  yes, turn off the profiled build.  any chance you can also file a bug?
<rneese_> http://pastebin.com/dWkf0E2F
<rneese_> merging that into the preceed might be the answer
<cjwatson> jcastro: is there anywhere to sign up for UDS lightning talks yet?
<ScottK> barry: What would be bug be?  profiled build fails on powerpc?
<barry> ScottK: if the non-profiled build succeeds, yep :).  attach or point to the buildlog.  i do have a powermac ppc dual g5 sitting around gathering dust.  would that make a decent machine to try this on?  i've dual booted my intel mbp, but haven't tried it on this ppc.  maybe i'll try that after uds
<jcastro> cjwatson: no, we just line up on the friday
<ScottK> barry: OK.  The bad news is I can't replicate it on the hardware I have access to.  Maybe you'll have more luck.
<cjwatson> jcastro: ah, OK
<jcastro> cjwatson: basically, sit in the front on Friday and we'll just line em up
<rneese_> how ward would it be to make that script into a preceed file ?
<cjwatson> righto, that allows for me to get cold feet with no shame attached. :-)
<jcastro> cjwatson: an ARM guy sits up front with a tablet with a clock and that's basically it.
<cjwatson> rneese_: probably not hugely, a lot of it seems to transfer over.  I can't do it all for you, but give me a minute and I'll sketch it
<ScottK> barry: Uploaded.  We'll see.
<barry> ScottK: +1.  also, i want to test it a little bit on a vm, but i think i'm ready to upload a new python-support to enable 2.7.  could you sponsor me on that in say an hour?
<rneese_> ok it would help
<jcastro> cjwatson: it's ok, james_w has the market cornered on botched demos, so you should be fine.
<rneese_> I want to learn but
<rneese_> its time consuming
<ScottK> barry: Probably.  Any excuse to avoid working on a proposal that's due Monday.
<rneese_> cjwatson: thnks ahead of time
<rneese_> the file will be added to a iso
<barry> ScottK: :)
<cjwatson> rneese_: entirely untested, but I think something like http://pastebin.com/SQQV3q3v
<rneese_> ok looking
<cjwatson> rneese_: you should get static network configuration prompts during the installer itself with that
<cjwatson> rneese_: please note that you can only assign one value to any given preseeding question, so I aggregated all your packages together into a single value for pkgsel/include
<cjwatson> rneese_: also, of course, no point starting services given that preseed/late_command is run just before reboot
<rneese_> ok I agree
<rneese_> thansk
<rneese_> reading it'
<cjwatson> rneese_: see the installation guide for various ways to tell the installer to use the preseed file; I suggest also adding the DEBCONF_DEBUG=developer kernel parameter to the installer while you're working on this, which makes it easier to see what's going on
<rneese_> ok
<rneese_> reading and learning
<rneese_> if your around is it ok to ask you questions if I dot grep ?
<ogra_ac> does anyone know a way to find out if the currently running kernel matches the installed package version ?
<ogra_ac> dpkg-query -W -f='${Version}\n' linux-image-$(uname -r)
<ogra_ac> that gets me the packge version, but how would i know this verysion is what is being executed ?
<cjwatson> rneese_: oh, blast, bit of a mistake in preseed/late_command since everything needs to be done inside the chroot, will edit
<cjwatson> rneese_: yes, but #ubuntu-installer might be better than here
<ogra_ac> (if the ABI is the same indeed)
<ION> ogra: /var/log/dmesgâs third line perhaps.
<ogra_ac> ION, nope, also only up to the ABI
<rneese_> ok I joined installer
<ogra_ac> ah, no, there is a version at the end of the line too
<ogra_ac> ugh, that will be ugly hackery to extract
<ION> /proc/version_signature
<ogra_ac> ION, perfect ! thanks
<ScottK> siretart: xine-lib has my name on it on m.u.c since I rebuilt it for a transition, but I'd be ever so grateful if you'd merge it.
<ScottK> cjwatson: Would you please rescore python2.7 (powerpc).  I'd really like to see if we can get 2.7 built there.
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<seb128> cjwatson, I think one of the issues with bug triaging is that different maintainers have different workflows
<seb128> (cjwatson, just commenting after reading your reply on the list)
<seb128> some people like to keep the noise out of the buglist so they can handle it, some other just want things to stay on state until they have time to investigate issues
<seb128> cjwatson, not sure that lettings bugs without any reply for years reflects better on Ubuntu though...
<seb128> no easy solution either way though
<ScottK> seb128: I'd say that people feeling the need to mark bugs closed in order to declutter lists suggests we need better bug searching/list making.
<cjwatson> seb128: do you disagree with me that bug triage is a skilled task, though?
<cjwatson> I thought that we could find common ground at least on that
<cjwatson> it may be that bug triagers manage to do better on desktop packages, for instance, since it's often easier for them to fire up the application and have a look
<cjwatson> I mean it may be that relatively unskilled bug triagers manage to do better ...
<ScottK> cjwatson: Most of the "Is this still a problem -> Incomplete" responses I see there's no evidence that anyone even tried to reproduce the problem themselves.
<cjwatson> I wonder if there's some mileage in adding some exhortations to whatever wiki page those responses come from
<ScottK> I was thinking more like threaten to smack people who don't at least try to replicate it themselves first, but yeah.
<cjwatson> or edit the response on the wiki page to have something like "[Edit this to say what you tried to do to reproduce the problem.  Dear reporter: if this sentence is in the message you retrieve, then feel free to ignore this message as the bug triager wasn't paying attention.]"
<ScottK> heh.
<ScottK> bdmurray: ^^^ What do you think?
<ScottK> Sounds good to me.
<cjwatson> seb128: I agree it isn't good to have bugs not getting replies - I just don't really think form letters count :-)
<persia> I've gotten that class of response to some of my more obvious bugs (e.g. apt-get source linux doesn't), but I'm not sure we can usefully change behaviour simply by adding more to the wiki page.
<persia> Lots of the newest folks seem to want to focus on volume of bugs touched, rather than usefulness of work done, which probably indicates some lower-level issue.
<chrisccoulson> i've seen people ask the reporter if their bug still occurs in the latest release, despite the particular application being removed from the archive several releases ago.....
<chrisccoulson> ....which obviously means people aren't trying to reproduce problems for themselves
<ScottK> Nice.
<seb128> cjwatson, sorry got sidetracked, yes we agree that triaging is a skilled tasks
<seb128> ScottK, well closing bugs is a way to tag them to be out of the default list
<ScottK> chrisccoulson: I think it's one of the inherent side effects of keeping bug metrics.  People see a number and want to make it go in the right direction.
<seb128> they are not deleted from launchpad
<persia> Note that in the special cases of X and the kernel, there are *heaps* of absolutely useless bugs that nobody but the submitter can reliably reproduce because they are related to some specific piece of flaky hardware.
<seb128> the issue is not metric
<seb128> the issue is to be able to open a bug list and to have something you can work on
<persia> ScottK, You suggest we should drop the metrics?
<ScottK> seb128: I think for triagers it can be.
<persia> seb128, I don't believe I can usefully do that based on current triage policies.
<ScottK> persia: I think if we keep them, we have to engage in work to discourage unhelpful practices they encourage.
<persia> ScottK, I'd rather do that, as I have found them motivating in some ways (although maybe for the wrong reasons).
<ScottK> persia: It's a matter of recognizing the unhelpful consequences of them and dealing with them.
<cjwatson> seb128: my problem is that I want to decide what I want to work on myself, and I find that I spend too much time overruling triagers' incorrect decisions on what they think I should work on ...
<cjwatson> so maybe we have similar goals but different problems leading up to them
<cjwatson> merge@casey:/srv/patches.ubuntu.com/code$ time ./syndicate.py -q
<cjwatson> real    3m50.843s
<cjwatson> that's more like it.  it was well over half an hour before
<siretart> ScottK: new xine requires graphicsmagick-libmagick-dev-compat, which is in universe. do you know if there are plans to promote it to main?
<cjwatson> (that's not all of MoM, just a particularly slow bit I noticed)
<ScottK> siretart: Not until you write the MIR I would guess.
<ScottK> (no idea really)
<seb128> cjwatson, well ideally yes, but really is that the number of bugs we get just means in the end we don't have time to read half of the incoming ones
<siretart> hm, I don't really fancy that idea...
<seb128> really -> reality
<seb128> cjwatson, just letting things stacking doesn't make any better and realistically we will just never come back to most of those waiting for a year
<persia> seb128, I think it's highly package-dependent.  I've often found time to read 6-12 months of old untouched bugs for some arbitrary package (which clearly didn't get much triage), if it mostly works.
<cjwatson> seb128: what happens to me is that I get people coming in and asking for more information when the bug doesn't need it and when I've already commented on it with details
<seb128> persia, well you probably don't pick things like ubiquity
<cjwatson> seb128: that sort of thing just wastes my time for absolutely no benefit to anyway
<cjwatson> *anyone
<cjwatson> I don't see how the issues of bugs stacking up over time really relates to that
<seb128> cjwatson, right, the issue is not bugs being set to incomplete and expiring then
<cjwatson> um, but that's exactly what's going to happen to me
<seb128> it's people doing bug triaging who don't know what they are doing
<cjwatson> sure, but we're implementing this expiry policy based on the assumption that triagers know what they're doing
<cjwatson> or perhaps based on the assumption that somebody with clue is going to have time to clean up in cases where that wasn't the case
<seb128> well I find the expiry feature useful
<seb128> it means I don't need to care about cleaning bugs I set to incomplete
<cjwatson> it would be useful if the statuses weren't such a mess as it stands
<cjwatson> maybe there should be some detection of who set the bug to incomplete
<seb128> right
<seb128> I think we agree that the issue is not bugs set to expire
<seb128> is that triaging is done wrongly
<cjwatson> anyone at all can mark a bug Incomplete
<cjwatson> there is absolutely no access control on that
<seb128> we should perhaps restrict the set of people who can do that
<cjwatson> well, aside from "must have an account"
<seb128> to the same people who can set priority etc
<cjwatson> I think that might help
<persia> Can we do that *before* we auto-expire more bugs?
<seb128> ideally we would have a way to say whether as the maintainer you care about this bug or not
<seb128> like "keep it on the list of things I want to know about" or "just get it out of my way"
<seb128> the first category should be things that random people are not able to modify
<persia> Some sort of integrated project/task management in Launchpad?  mpt had some interesting ideas about that.
<seb128> the second ones is things you know as a maintainer that are nothing useful to you and can go to triagers or answer tracker or whatever
<cjwatson> like "all crash reports"? :-)
<seb128> the "doesn't work, please help" descriptions
<cjwatson> it would really help for crash reports to be a separate database, but we knew this ...
<seb128> well stacktrace are often useful
<cjwatson> the workflow I'd like is for a developer to be able to promote a crash to a bug once it's been analysed
<seb128> but there is lot of user questions or requests for help coming as bugs
<cjwatson> same way you can promote a question to a bug
<seb128> right...
<cjwatson> but I don't hold out a lot of hope of this happening
<persia> seb128, But we should be using convert-to-question for that, not incomplete.
<seb128> well people argue that "doesn't work" is still a bug
<seb128> it just that it doesn't have enough information about the issue to be useful
<seb128> those are different from real question, like "how do I do that"
<cjwatson> I think I would say that it isn't a bug yet
<seb128> well that's what we use incomplete for atm
<cjwatson> but it might be if it were made more precise
<seb128> right
<seb128> the thing is that the way you get things out of the list is to set those incomplete
<robbiew> cr3: I'm assuming you want a UDS session for https://blueprints.edge.launchpad.net/certify-planning/+spec/other-ps-n-manual-testing-patterns, right?
<seb128> but ideally you should tell the submitter what is missing when you set to incomplete
<seb128> there is no way right now to say "that's not useful to me but I've no time to be the one helping to get the required informations"
<cr3> robbiew: if there's an available slot, it would be nice
<mpt> Like ScottK, I have sometimes felt the urge to smack people who didn't even try my steps to reproduce before marking a bug as Incomplete
<persia> seb128, So we maybe need to change the training for bugsquad?  I'm not sure that most triagers currently know what is missing.
<seb128> or to put on a list "needs to be triaged by somebody"
<ScottK> I'd really like to get away from the "we haven't heard from you in a while, please prove it's still a problem".
<robbiew> cr3: done ;)
<persia> ScottK, In practice, bugsquad typically doesn't do that anymore (although our information dissemination procedures are fairly slow in bugsquad).
<seb128> we do
<mpt> but the purpose of a bug tracker is not to record every bug that exists or might exist in software
<ScottK> robbiew: Are you accepting other-* specs?
<persia> seb128, Only the Desktop team, and only for Desktop bugs, because you insist.
<persia> mpt, Why not?  How else do we know what we can fix?
<cr3> robbiew: that was easy, I should propose a bunch of other sessions if it's that easy! :)
<seb128> that's the only way to clean the list of weird issues who happened one time to one user in an old version
<seb128> things we have no clue about and just let there because we didn't know what to do with them
<robbiew> ScottK: I'm accepting whatever's needed ;)
<robbiew> cr3: heh...well, it's not THAT easy
<ScottK> OK.  Let me find it.
<mpt> persia, because the purpose of a bug tracker is to help engineers make best use of their time. And usually, spending an hour fixing a bug will improve the software more than spending that hour trying to clarify an incomplete bug report.
<seb128> but realistically those are often not useful especially if it happened once to one user and not for years
<persia> seb128, So, most of those would be better to try to reproduce, etc., no?
<persia> seb128, In my experience, it's not that hard to reproduce something in e.g. feisty (from oldreleases), and then show it fixed in e.g. maverick, and so mark a bug closed.
<seb128> lot of those are not reproducable
<seb128> it's a thing one user got one time without knowing how
<persia> Even in the original environment?
<seb128> and nobody has got since
<seb128> yes
<persia> mpt, I think it very much depends on the nature of the issue.  As an example, how about "Ubuntu hardy boots really slow".  That was a worthwhile bug to fix, although it took *months* of developer effort to get it even close to being a useful bug report.
<mpt> persia, sure, I'm not saying there are no exceptions
<ScottK> robbiew: Nevermind.  It got accepted while I wasn't looking.
<persia> mpt, I guess I'm saying I think every real bug is worth tracking (even when it can only be reproduced in hungarian on a full moon (real example))
<ScottK> The existence of an incomplete bug may be a key for someone else who has the problem to come along later and add needed information.
<robbiew> ScottK: ;)
<ScottK> I've, more than once, seen people not report bugs because they thought it was "just them".
<maco> persia: or on tuesdays?
<persia> Although some secondary reporters damage the utility of a bug, sadly, just because of apparently similar symptoms.
<persia> maco, I've yet to see a bug that only happens on Tuesdays (there was one about Thursdays, but that was in a closed-source project)
<maco> persia: hmm i thought the printer bug was on tuesdays
<persia> Might be: I didn't see that one.
<maco> yeah... OOo couldnt print to Brother printers on Tuesdays
<cjwatson> mpt: my experience is that this argument is extended to ridiculous extremes, including removing things from my to-do list that I've already acknowledged as bugs and just haven't got round to yet.
<maco> https://lists.ubuntu.com/archives/ubuntu-users/2009-April/182642.html
<cjwatson> mpt: I certainly agree that endless back-and-forth to try to clarify "my computer doesn't seem to be working quite right" is not a good use of engineering time
<maco> cjwatson: isnt that why there are triagers-who-arent-devs?
<mpt> cjwatson, I don't think the human Incomplete-bots are working on the basis of any particular argument. :-)
<cjwatson> maco: yes; but there is a limit to how far from a developer skill level I think they ought to be
<cjwatson> mpt: when challenged, they generally say that they didn't think the bug report could have been valuable if it had stayed around for so long (where "so long" can be anything from a week up)
<maco> cjwatson: fair enough. i quickly run out of steam on bugs in non-gui programs
<maco> (  *frown*  )
<siretart> ScottK: seems that build dependency isn't strictly necessary; package builds and seems to work without for me
<siretart> ScottK: uploaded
<ScottK> siretart: Cool.  Thanks.
<ScottK> Related to the whole bug expiration question: http://lwn.net/Articles/410846/
<rneese_> when remastering a iso where do you place a custom preceed.cfg file ?
<lool> cjwatson: FYI latest tasksel fails to upgrade for me: Erreur d'analyse de message vers Â«Â Description-sr@latin.UTF-8: Izaberite softver za instaliranje:Â Â», dans la partie #1 de /var/lib/dpkg/info/tasksel.templates
<lool> https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/665178
<ubottu> Launchpad bug 665178 in tasksel (Ubuntu) "tasksel doesn't get configured... Natty" [High,Confirmed]
<smoser> barry, are you able to fix https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/662883
<ubottu> Launchpad bug 662883 in python-crypto (Ubuntu) "Merge python-crypto 2.1.0-2 (main) from Debian unstable (main)" [Medium,New]
<smoser> (mainly asking if you have commit privs to python-crypto, or if we need someone to sponsor it)
<smoser> ScottK, would you feel comfortable sponsoring that now ? we have a placeholder "fix it right" bug around.
<smoser> i'd really like to move on to the next hurdle for natty uec images
<shadeslayer> rickspencer3: around?
<rickspencer3> hi shadeslayer how can I help?
<shadeslayer> rickspencer3: whats the Gifting plenary about?
<rickspencer3> shadeslayer, about how Ubuntu is a gifting culture
<rickspencer3> it's totally mushy
<rickspencer3> not at all technical
<shadeslayer> ah ohk ...
<rickspencer3> 4 freedoms -> Ubuntu Manifesto -> CoC -> how we behave
<smoser> totally mushy
<rickspencer3> shadeslayer, were you worried I was going to pass around a collection plate?
<rickspencer3> ;)'
<statik> kirkland: all these blog posts about bikeshed have me wanting to install it, but the package is stuck in new. cmon dude, stop teasing ;)
<persia> Note that there are other equally valid ways to interpret such things.  The "You are all my slaves, making everything work because you are hopelessly addicted to my code" works well for some folks.
<shadeslayer> rickspencer3: hahaha .. no, was just wondering if we had to bring gifts for other people attending the plenary :P
<kirkland> statik: fixed
<statik> awesome
 * smoser now has 'signs' stuck in his head due to the 'pass the plate' reference above.
<barry> hi folks.  can i get a sponsor to upload new python-support and python-central packages to enable py2.7 in natty?  tested locally, it seems to be working as expected
<persia> barry, If you don't get a response soon, either use UDD and file some merge requests (which automatically end up in the sponsors queue), or file a bug and attach relevant information so folks can get your packages.
<corecode> hi
<barry> persia: i have merge requests open already
<corecode> anybody know where eglibc people hang out?
<persia> barry, Excellent.  I just try to guard against lots of sponsorship requests in other channels: my experience is that when there's lots of requests in other places, the sponsors queue gets ignored.  When more folk are using the sponsors queue, latency goes down.
<barry> persia: nod, thanks.  what is average turn around time for merge proposals?  or iow, how patient should i be? :)
<geser> barry: if it didn't change much recently, you probably need to go hunting for a sponsor if you want get it sponsored fast
<barry> geser: is this the right forum for that?  i really do want to get these uploaded before weekend/uds
<geser> barry: yes, but you might have trouble find a core-dev now as it's a) weekend and b) many are travelling to UDS
<geser> you might have better chance to bribe a core-dev at UDS :)
<persia> barry, The nice target is 3-4 days, but, especially for stuff in "main", sometimes it takes weeks, sadly.  If you need it pre-UDS, you will need to find someone (and this is a forum that has folks that can do it, although see above for why I don't think asking for quick sponsoring is good for the overall health of contributions by folk without direct upload rights)
<barry> geser, persia gotcha, thanks.  see you at uds
<rneese_> anyone here good at remastering the server iso
<rneese_> it seems like a pain to remaster
<ScottK> smoser: Maybe in a few hours.  Still tied up with other stuff.
<avo> Hey guys.. so I'm writing a SUPER small app that is literally only useful to one or two other people (my friends.. it's about our school). However, I'd like them to be able to code the little project as well, and use a system to keep all this straight. There's no reason, and frankly I wouldn't want to make this visible to the public. How/can I do this? Thanks!
<persia> avo, If you just want have a shared source repository to collaborate with a couple friends, you might want to store your code in bzr on launchpad.  The folk in #launchpad would be happy to help you get started.
<avo> That sounds great.. I'll head on over there. Thanks!
<corecode> i can't wrap my head around bzr... too much git
<corecode> i updated roundcube, anybody interested in getting this in?
<bjf> jdstrand, Could I trouble you to "New" some kernel uploads for me?  karmic, lucid and maverick
<jdstrand> bjf: that is a lot of uploads for eod on friday...
<jdstrand> bjf: I'll take a look
<bjf> jdstrand, thanks
<bjf> jdstrand, we're still recovering from the security release
<jdstrand> that's cool
<jdstrand> bjf: my day just ended up being not at all what I expected. no worries
<jdstrand> bjf: (nothing to do with your request)
<bjf> jdstrand, glad to hear it's not me
<YokoZar> Any known issues with libc6 on 10.10?  My friend reported a clean install causing a broken package on first update manager run...
<TheMuso> YokoZar: He's not using -proposed I hope.
<YokoZar> TheMuso: nope
<wgrant> There was a security update a few hours ago...
<wgrant> But "broken package" isn't terribly descriptive.
<YokoZar> wgrant: by broken I mean doesn't install
<YokoZar> getting more info now ;)
#ubuntu-devel 2010-10-23
<cjwatson> lool: debconf bug really, not going to fix before travelling to UDS now though
<ScottK> corecode: We don't really want a newer roundcube than Debian has as we want to be able to leverage their security support (my opinion anyway)
<cjwatson> lool: (changed my mind, see bug)
<corecode> fair
<RoAkSoAx> /win/win 2
<RoAkSoAx> bah
<jorgenpt> Hi, I've built a package using apt-get source package, then dch -l myversion, debuild and dpkg -i.
<jorgenpt> How can I tell Ubuntu to downgrade to the one from the repo instead
 * jorgenpt downloads .debs and dpkg -i
<jorgenpt> But is there a better way?
<Sarvatt> sudo apt-get install package/release
<zxt> d
<rohan> why does nouveau driver not support modeset in maverick? i only get a black screen on boot. is there any way to solve it? i want to use nouveau only, don't want to switch nvidia binary driver. thanks.
<ScottK> cjwatson: Somehow python2.7 got bumped back down.  I'd appreciate it if you'd rescore it (again) for powerpc.
<cjwatson> ScottK: apparently already failed to build
<Madkiss> hi folks
<stefano> i got this error when uploading to my ppa: "Source/binary (i.e. mixed) uploads are not allowed." (first time i created the deb myself) - could anybody spare a minute helping me out with this?
<persia> You might want to ask in #launchpad (PPAs are a service of launchpad).  I suspect you wanted to have run `debuild -S` to create the source package.
<stefano> persia, i'll try that in reverse order, thanks!
 * ogra_ac guesses cjwatson will love monkey.libre today ... oh my
<ogra_ac> mass incompleting installer bugs is really not a good idea
<persia> Let's hope we can find a good solution: https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-qa-n-triage-revisited
<ogra_ac> sure, up to then people should refrain from running bug scripts though
<ogra_ac> at least for incompleting installer bugs
<persia> I'm not sure that's *ever* a good idea, unless one is an active member of the installer team.
<ogra_ac> right
<ogra_ac> sigh, another 6 ...
<ogra_ac> since i typed the above
<ogra_ac> sigh, and he is not in #ubuntu-bugs or something
<persia> Most folk who are messy aren't.
<ogra_ac> and another 6
<ogra_ac> 9 this time round ... at that frequency i'll drown in bugspam if i arrive in floriday
<ogra_ac> -y
<ScottK> cjwatson: Yep.  Thanks.
<ogra_ac> ah, and for the fun of it the script he uses is so buggy that it incompletes some bugs up to three times
<bdrung> kirkland: what do you think about moving errno from ubuntu-dev-tools into bikeshed?
<geser> how much history is to preserve during a merge? my debdiff for the vim merge contains around 1k insertions and over 90% of those insertions belong to debian/changelog. The history is around 9 times bigger than the actual changes.
<geser> kirkland: as you were involved in changing "syntax on" by default for vim, what's your opionion on bug #572627? (see also the comment from James Vega (Debian maintainer of vim) in bug #63172)
<ubottu> Launchpad bug 572627 in vim (Ubuntu) "ftdetect scripts not loaded from directories added to runtimepath" [Undecided,New] https://launchpad.net/bugs/572627
<ubottu> Launchpad bug 63172 in vim (Ubuntu) "Better vimrc default" [Wishlist,Fix released] https://launchpad.net/bugs/63172
<ScottK> geser: The usual answer is all of it.  Should be motivation to work to a sync so it can go away I guess.
<geser> ScottK: I'm already working on at least minimizing it, but I doubt that all remaining Ubuntu changes make sense in the Debian package (like Launchpad integration)
<ScottK> vim needs launchpad integration?
<geser> ScottK: it's more getting links to Launchpad in the Help menu
<ScottK> I see.
<Peace-> hi
<Peace-> i would like know if here there is someone that can help me with udev
<Peace-> and nokia 5800
<Peace-> i was creating a script to syncronize mny nokia
<Peace-> but...
<Peace-> udev seems doesn't recognize my udev.rules
<Peace-> i have some informations here
<Peace-> http://ubuntuforums.org/showthread.php?t=1603921
<Peace-> that is what i get from my nokia
<Peace-> i tried this
<Peace-> SUBSYSTEMS=="usb",DRIVERS=="usb",ATTRS{idVendor}== "0421", ATTRS{idProduct}=="0156", OWNER="root", GROUP="disk", RUN+="/tmp/aresyn-qt-bash"
<Peace-> but ... doesn't work
<ScottK> Peace-: Help is in #ubuntu.
<Peace-> well... that is not an official issue
<Peace-> xD
<ScottK> It's off topic here.
<Peace-> oh
<Peace-> ScottK: and where shoudl i go ?
<Peace-> to develop this script?
<ScottK> Not sure, but it's not about development of Ubuntu.
<Peace-> ok
<Peace-> ty anyway
<G__81> hi everybody i am interested in contributing to Ubuntu. I am interested in fixing bugs and adding features, though adding features is a futuristic goal at the moment but bug fixing is something that i want to start off with
<G__81> is this the right channel to ask this question first of all ?
<ScottK> G__81: It depends on what your interests are.
<ScottK> For example, if you are a Kubuntu user and interested in KDE, #kubuntu-devel would be better.  Similarly #ubuntu-desktop for Ubuntu Desktop.
<G__81> yeah i am interested in bug fixing and have been using Ubuntu
<G__81> currently using the 10.10 version
<G__81> looks brilliant
<ScottK> Sounds like you might want #ubuntu-desktop then.
<G__81> whats this channel all about ?
<kirkland> geser: sorry, I'm unfamiliar with pathogen and ftdetect
<kirkland> geser: is there a proposed solution to the problem?
<geser> kirkland: as far as I understand it, the solution is to not set "syntax on" in /etc/vimrc
<kirkland> geser: users of pathogen are welcome to do that
<ScottK> G__81: This channel is the central channel for all sorts of Ubuntu development.  You'll generally do better to start in a place more focused on your interests.
<kirkland> geser: sorry, i'm AFK for a while now
<G__81> oh ok thanks ScottK
<kklimonda_> are we going to get tcl 8.5 into natty?
<penguin42> kklimonda_: Seems to be there already
<penguin42> kklimonda_: Actually, it's 8.5 in maverick as well
<ScottK> We've had it since Hardy.
<kklimonda_> ah, my bad - the question was supposed to be "is tcl 8.5 going to be default in natty"
<penguin42> are the build logs for packages on line somewhere?
 * penguin42 is trying to see why something just doesn't seem to be in the package yet the config is there
<ScottK> penguin42: Yes.  On launchpad.net/ubuntu/+source/$PACKAGENAME (then click on the version/architecture you're after)
<geser> penguin42: yes, in LP
<penguin42> ScottK: Thanks
<ScottK> You're welcome.
<slangasek> james_w: can you help me solve http://package-import.ubuntu.com/status/gourmet.html#2010-10-18%2000:43:53.361984 (in the immediate instant, if not the general bug)?  I've got a bunch of work I'd like to do on this package and I'd rather like to be able to use the bzr branches I've already been working on
<slangasek> s/instant/instance/
<james_w> yes, provided it takes less than 10 minues
<james_w> slangasek, took a stab at it and asked for a retry, but I have to dash now, sorry
<slangasek> james_w: no worries - have a safe trip :)
<levu> is here anyone working on evolution? i have a question concerning one of the patches ubuntu applied to evolution
<slangasek> levu: not working on it, but maybe I could divine the intent if you tell me the patch
<levu> slangasek: it's patch 89_express.patch. The settings for "format new message in HTML" was removed with this patch for express edition, which is really bad
<slangasek> levu: looks like you want to talk to didrocks for that - or just file a bug; it's a large patch, this may just be a problem that was overlooked
<slangasek> james_w: alas, failed with the same error again :(
<levu> slangasek: ok, i've filed a bug but i want additionally talk to didrocks. for the future: where can i have a look if i want to know who is responsible for a bug?
<slangasek> levu: the package changelog under /usr/share/doc/$package shows you who's been uploading it to Ubuntu (the changelog entries that have 'ubuntu' in the version number anyway), that's usually a good first approximation; in this case, didrocks is both the usual uploader, and the person whose name is attached to the changelog entries that reference 89_express.patch
<levu> slangasek: k, thanks. Is he sometimes in here? or just on launchpad?
<slangasek> levu: he is often here, and in #ubuntu-desktop; developers will be more scarce on-line today, both because it's a weekend and because it's the weekend before UDS so most are traveling
<slangasek> (indeed, from the logs it seems didrocks is already at UDS)
<bmhm> hi there. How can I make a bug in launchpad more "interesting" to other people? We (users and main dev) think, that the importance is chosen to low.
<bmhm> It's a showstopper in ubuntu 10.04 and 10.10, a bug in shotwell: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/555408
<ubottu> Launchpad bug 555408 in shotwell (Ubuntu) "Shotwell makes USB mouse jumpy/jerky" [Low,New]
<levu> slangasek: ok, i'll wait until he comes back and do my work and write a patch for his patch so that he doesn't have much work :)
<amikrop> hello, in a fresh 10.10 install I only have sound when the speakers are not connected
<amikrop> I mean, the big speakers
<amikrop> the internal laptop speakers play sound
<levu> amikrop: please go to #ubuntu, here is a developer channel
<amikrop> but when I connect the external big ones no sound
<amikrop> levu: I cannot speak to #ubuntu
<amikrop> it says cannot send to channel
<levu> amikrop: what happens if you try to join?
<amikrop> levu: ok, now I can send, thanks
<levu> lol
<levu> joining a channel helps :)
<bmhm> again, how can I ask for a bug's importance to be re-evaluated?
<bmhm> or can somebody help me subscribing the right team?
<bmhm> Bug #555408
<ubottu> Launchpad bug 555408 in shotwell (Ubuntu) "Shotwell makes USB mouse jumpy/jerky" [Low,New] https://launchpad.net/bugs/555408
<nigelb> !importance
<bmhm> nigelb, you probably need to add my nick
<nigelb> https://wiki.ubuntu.com/Bugs/Importance
<bmhm> nigelb, this table tells me it should be high instead of low: Has a severe impact on a small portion of Ubuntu users
<bmhm> so the next thing to do is?
<bmhm> UbuntuBugControl <-- overe there?
<nigelb> #ubuntu-bugs would be a good place
<nigelb> but let me read the bug
<bmhm> thx
<ebroder> Does gphoto seriously not use udev to monitor for new devices?
<bmhm> seems so
<bmhm> at least digikam worked
<bmhm> ah wait, I get it. Libusb is polling, udev is event-based - is this a true assumption?
<BUGa_brokenkerne> evening folks
<BUGa_brokenkerne> with the latest kernel natty upgrade, i stop being able to boot
<nigelb> bmhm: I'd rather not override desktop team on this bug's importance
<BUGa_brokenkerne> grub complains that it should load a kernel 1st
<BUGa_brokenkerne> i guess 2.6.36.x is messing with grub
<bmhm> nigelb, but things have changed since then. I'd really like to ask them to reconsider. it fulfills at least 2 Â»highÂ« criterias.
<nigelb> bmhm: the thing is, this has to be looked into by upstream, and it is being lookd into by upstream
<nigelb> as soon as upstream fixes it, we will hve the fix
<nigelb> the importance on LP isn't /very/ significant here
<ebroder> nigelb: If the fix is using udev instead of libusb, which I bet it is, that's going to be a *big* fix for an SRU, and it'll affect more than just shotwell
<bmhm> It could be just gphoto2 then
<bmhm> shotwell relies on gphoto2
<ebroder> bmhm: Right, that's what I'm suggesting
<bmhm> true
<bmhm> then a workaround would be a better idea, until gphoto makes use of udev. Like... adding a virtual dummy camera
<penguin42> why does polling cause the mouse to get unhappy anyway?
<BUGa_brokenkerne> https://launchpad.net/bugs/665471
<ubottu> Launchpad bug 665471 in grub2 (Ubuntu) "[natty] GRUB no longer finds kernel with separate /boot partition" [Undecided,Confirmed]
<BUGa_brokenkerne> brb
<bmhm> penguin42, maybe DDoS? I don't know the interval
<bmhm> *DoS, not DDoS of cause
<bmhm> I'm looking into the source code. Maybe there's something interesting there.
<penguin42> bmhm: I just mean that it just shouldn't screw it up by polling
<bmhm> penguin42, I know. What i meant was that there may be some denial of service if polled too often
<bmhm> I'd call that a fairly good reason to screw up
<levu> slangasek: i don't think leaving the option was accidentially: /* Express mode does not honor this setting. */
<zygomatik> hi! would someone help me with the grub shell ?
<zygomatik> i'm trying to recover from a root fs kernel panic
<zygomatik> but i cant use the kernel and setup commands
<levu> zygomatik: have you tried it in #ubuntu?
<zygomatik> levu: yeah some people advised me to boot from cd/usb key
<levu> zygomatik: so have you tried it?
<kklimonda_> BUGabundo: what, is kernel already broken? :)
<zygomatik> no i cant
<kklimonda_> BUGabundo: here goes natty ;)
<BUGabundo> yep
<zygomatik> at least not easily
<zygomatik> i used a friends cd since i dont have one
<kklimonda_> good I haven't decided to do an upgrade before UDS after all
<kklimonda_> I was *this* close :)
<BUGabundo> kklimonda_: easy fix, don't you worry
<kklimonda_> BUGabundo: all I need now is to break my laptop - I'm already freaked out enough about flight ;)
<BUGabundo> kklimonda_: edit grub conf and remove /boot
<BUGabundo> easy fix
<zygomatik> my question is just is it normal that i cant see "kernel" and "setup" commands inside the grub shell ? has something changed or my grub is also broken ?
<zygomatik> sorry to insist...
<zygomatik> kklimonda_: BUGabundo are you talking about the same problem i'm having: apt-get upgrade messed the grub conf ?
<BUGabundo> zygomatik: no idea
<BUGabundo> I had no such thing
<BUGabundo> https://launchpad.net/bugs/665471 this is it
<ubottu> Launchpad bug 665471 in grub2 (Ubuntu) "[natty] GRUB no longer finds kernel with separate /boot partition" [Undecided,Confirmed]
<zygomatik> i see
<zygomatik> i dont have a separate boot partition
<zygomatik> so that shouldnt be it
<zygomatik> BUGabundo: i have kfreebsd and kopenbsd as grub commands but no "kernel" is this normal ?
<BUGabundo> no idea
<BUGabundo> beats me
<zygomatik> well i guess i have to wait for my friends usb cd drive...
<zygomatik> my grub version is 1.98+20100804-5ubuntu3 btw
<slangasek> levu: so the thing is that reading the history, I don't think Ubuntu wrote this patch, but instead has taken it from somewhere else; Ubuntu might decide they disagree with the patch author regarding the disabling of such a feature and just haven't realized yet that this was done
<levu> slangasek: is anywhere mentioned, where the patch is taken from?
<slangasek> levu: probably from http://live.gnome.org/Evolution/Art (first google hit for 'evolution express' :)
<levu> slangasek: thanks, what i've read is that the code is from MeeGo, so i attach a patch to my bug report on launchpad and hope that some one reads the bug report :)
<levu> slangasek: if i understand it correctly this issue is fixed upstream, so i may have a talk to the gnome developers first :)
<slangasek> ok :)
<owen1_> is it possible to install ubuntu-arm on archos 101 tablet?
<owen1_> https://wiki.ubuntu.com/ARM/RootfsFromScratch  is this the correct steps to do that?
#ubuntu-devel 2010-10-24
<dev001> what package installs/provides "stddef.h"?
<penguin42> dev001: Interesting I don't see one in /usr/include, but gcc-4.4 provides one in  /usr/lib/gcc/x86_64-linux-gnu/4.4/include/stddef.h
<dev001> penguin42: I have gcc-4.4 installed, but i still get lots of 'makedepend: warning: ... cannot find include file "stddef.h"' messages
<ebroder> I only see a /usr/include/linux/stddef.h on my machine
<ebroder> (in linux-libc-dev)
<dev001> been googling for hours ... lots of instanced of the problem, no solutions that actually SOLVE it
<ebroder> Do you need to #include <linux/stddef.h> instead of just <stddef.h>?
<penguin42> dev001: That sounds like a makefile problem though, I *think* if you #include <stddef.h> it should pick it up from the gcc directory (if it doesn't thats broken)
<dev001> ebroder: perhaps ... it's a "standard" build from source of openssl that's throwing the error, atm.  no my own pkg.  works perfectly on every _other_ platform I build on.
<dev001> i've also installed requisite "gcc build-essential libc6 libc6-dev xutils-dev".  no help -- still getting that error.
<ebroder> dev001: Are you building with the Ubuntu source package, or with a download from upstream?
<penguin42> dev001: a hello world that #include's <stdef.h> works for me
<dev001> ebroder: upstream
<dev001> all our openssl builds are latests source, from upstream
<dev001> fwiw, this is a nominal, headless install -- adding packages only as req'd.  _maybe_ something's missing, but i'll be darned if i can find it atm
<jubei> hello. I am doing "make" on some software but the output is too long and dissapears on the terminal's buffer. I tried make | more but doesn't work. I tried make >> make.log but I only get the 1st line. Any tips?
<lennix> make >log 2>logerreur
<jubei> lennix, thank you I'll try it
<BUGabundo> Boa tarde o/
<ggeorgy> hi  :D
<jubei> hello. my compiler complains during linking that it cannot find some libraries i.e. cannot find -lopencv and others
<micahg> jubei: in Natty?
<jubei> I have compiled and make install opencv manually soo.. I'm kinda lost
<j1mc> micahg: howdy
<jubei> micahg, natty? i:ve no idea what it is. I'm trying to compile a ustom app
<micahg> jubei: which version of Ubuntu?
<jubei> micahg, latest
<micahg> jubei: yes,  but is that 10.10 or 11.04
<jubei> micahg, 10.10
<micahg> jubei: if you're installing opencv from source and you're missing opencv, I think that's beyond the scope of the channel, you might want to try #ubuntu-app-devel
<micahg> hi j1mc
<jubei> micahg, thanks
<bitshuffler> Hello. Is there some site that allows me to identify which package contains a file? (reasoning is that I'm trying to setup a 10.10 chroot on OBS which doesn't work ootb so I now have to debug it without having an Ubuntu version installed so any help would be really great)
<bitshuffler> Or more verbose: it currently fails during procps' postinstall - sctrace is http://pastie.org/pastes/1245069/text . I'm just wondering what makes it fail there ;D
<penguin42> bitshuffler: packages.ubuntu.com
<penguin42> bitshuffler: You can also use apt-file to search or dpkg -S to find which package a file on your system comes from
<bitshuffler> penguin42: Thanks you :)
<bitshuffler> penguin42: heh, yes, but that only works if it is already installed
<penguin42> yes
<penguin42> apt-file finds it even if it isn't
<bitshuffler> penguin42: but that doesn't work in a minimal chroot, right?
<penguin42> true, you need apt-file installed
<penguin42> but apt-file is a truly wonderful thing
<bitshuffler> (as in I don't have any real Ubuntu installation available but just trying to fix 10.10 for OBS)
<bitshuffler> Hm, why does procps fail if it can't connect to upstart? As in in a chroot that is only used for building packages I don't run any services so I _thought_ I wouldn't need upstart. Any ideas what the "proper" solution would be?
<penguin42> is it trying to do    start procps ?  Thats an upstart command isn't it?
<penguin42> (although I spent an hour fighting procps start up this week - any incompatibility in the set of sysctl settings causes it to fail....)
<bitshuffler> penguin42: yes, "start procps" is what it is trying to do which fails with "cannot connect to upstart" (somehow obviously since it is only a chroot with no servies running).
<penguin42> bitshuffler: Yeh well start is an upstart command
<bitshuffler> penguin42: well, upstart should be installed but not running - am I right that /com/ubuntu/upstart is a socket which only exists when upstart is actually running?
<penguin42> bitshuffler: I'm not sure where that path comes from - there is no /com
<bitshuffler> penguin42: the postinstall of procps fails with "start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused" when trying to do "start procps"
<penguin42> yeh I can see from that strace
<bitshuffler> penguin42: on what version are you? (we have that problem only with / since 10.10)
<penguin42> bitshuffler: 10.10
<bitshuffler> hm, makes me wonder how that postinst worked for you ;D
<penguin42> I think it's just something I don't understand about socket naming - I can also see the connect(3, {sa_family=AF_FILE, path=@"/com/ubuntu/upstart"}, 22) = 0
<bitshuffler> where do you see that?
<penguin42> strace of start procps
<penguin42> ah - Linux has a private namespace for sockets that aren't in the filesystem - I can see it with a netstat
<ion> https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes, search for âUpstart jobs cannot be run in a chrootâ, run the two commands in the chroot.
<penguin42> yeuch nasty work around :-)
<bitshuffler> ion: thanks for the pointer :)
<bitshuffler> hm, when exactly would I run that command since I currently can't create the chroot?
<penguin42> bitshuffler: What OS are you running on?
<bitshuffler> penguin42: opensuse - but what I'm trying to do is to fix the 10.10 chroots on their build service so it should work on pretty much any linux distro
<penguin42> bitshuffler: If I was trying to create an ubuntu chroot I'd use debootstrap
<bitshuffler> penguin42: well, all that stuff is a bit hard to do if you have no native ubuntu install around ;D
<penguin42> bitshuffler: No, I think you can download debootstrap from somewhere and use it to unpack a minimal chroot
<bitshuffler> hm, reading about that it sounds somehow sensible, not sure why it isn't used
<penguin42> can use it for most debian and ubuntu
<bitshuffler> otoh it makes me wonder how that debootstrap then installs the chroot since it must run into the same problem
<ion> debootstrap seems to handle the initctl thing automatically. /usr/share/debootstrap/scripts/maverick:echo \"Warning: Fake initctl called, doing nothing\"" > "$TARGET/sbin/initctl"
<penguin42> bitshuffler: Get yourself a debootstrap from the most recent ubuntu and it should handle older ones as well
<bitshuffler> hm, sounds shiny. Do I have to compile debootstrap myself or is it just some perl script?
<ion> Itâs implemented in sh.
<bitshuffler> ah, nice
<bitshuffler> Hm, your repo layout is pretty confusing tbh - where would I find a debootstrap package at http://ftp5.gwdg.de/pub/linux/debian/ubuntu/dists/maverick/ ?
<Laney> http://ftp5.gwdg.de/pub/linux/debian/ubuntu/pool/main/d/debootstrap/
<bitshuffler> oh, so the distro just contains the package lists with versions and then it gets taken from the pool which contains packages for all the distro versions?
<penguin42> bitshuffler: Yeh pretty much
<bitshuffler> ah, now it make sense :D Thanks a lot :)
<ion> One can find a link to the package quite easily via http://packages.ubuntu.com/
<ion> Also https://launchpad.net/ubuntu/+source/debootstrap
<bitshuffler> Where would that link be? (I was at http://packages.ubuntu.com/maverick/debootstrap but saw no link to a repo)
<Laney> click wher eit says "all"
<Laney> or the .tar.gz on the right for the source package
<ion> The architecture: all link under âDownload debootstrapâ for the built .deb; âDownload Source Packageâ for the sauce.
<bitshuffler> heh, that prolly was the only link I didn't click, cheers :)
<bitshuffler> hm, does debootstrap have some "minimal" option - as in 144 packages is a bit much, not?
<ion> The minbase variant perhaps.
<bitshuffler> ion: is there a list with what variants exists? --help claims there are just "buildd, fakechroot & scratchbox
<dev001> hi. i can't seem to find the 'right place' to get this actually posted, so, while i figure THAT out, a courtesy fyi in here ... for anyone that may be interested.
<dev001> i've tried to submit an openssl-on-ubuntu bug to openssl-rt last week; it never posted.  tried again today -- waiting.  i see also that @launchpad, openssl trunk is tracked only @ openssl-rt. hm.  in any case, i've filed this @ RT (https://gist.github.com/991e5c720926687bb620).  Will try again to get it to appear there ...
<dev001> thx
<ion> bitshuffler: The man page mentioned minbase. The help text seems to lag behind the code. /usr/share/debootstrap/scripts/maverick contains the authoritative list of variants supported for maverick.
<bitshuffler> ion: ah, nice, thanks for the pointer
<yassine> is there some mutter developer in here?
<yassine> i get this here when i try to start any application in my ubuntu maverick box: Oct 24 20:32:53 suncemoje kernel: [  793.258275] mutter[1988]: segfault at 0 ip 01dfa11c sp bf8a3a00 error 4 in libclutk-0.3.so.0.360.0[1deb000+4e000]
<darkenvy6> hello, I just have a question
<darkenvy6> a handheld device that runs ubuntu? (non ARMEL)
<darkenvy6> an eee-pc is the closest I found but its not pocket sized. I figured this channel would know
#ubuntu-devel 2011-10-17
<pitti> Good morning
<ajmitch> morning pitti
<didrocks> good morning
<dholbach> good morning
<McPeter> hi
<hrw> precise opened - wonder how many people will switch to it during month
<amitk> hrw: 5-6? :)
<amitk> including you
<dholbach> I switched a vm to precise :-)
<amitk> dholbach: that's cheating :)
<hrw> amitk: ;)
<diwic> dholbach, what vm infrastructure do you use/recommend?
<dholbach> I just use kvm - I used a normal .iso to install it there
<dholbach> https://wiki.ubuntu.com/UsingDevelopmentReleases has a lot of different options
<diwic> dholbach, okay, thanks
<FourDollars> dholbach: Could you sponsor my patch at https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ?
<ubottu> Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed]
<dholbach> FourDollars, I'm a bit busy with other stuff right now - maybe you could ping the patch pilot in the topic of the channel?
<FourDollars> dholbach: I see. Thanks a lot. :)
<dholbach> no problem
<FourDollars> smoser: ping
<janimo> FourDollars, from what I read here https://wiki.ubuntu.com/StableReleaseUpdates , it is better to have the fix already in the development series before requesting an update to the stable one
<janimo> a fix for P should probably happen anyway right?
<janimo> FourDollars, also the upload now targets a released version, so the changelog should have oneiric-proposed as the series name
<FourDollars> janimo: Thanks you for your correcting. :)
<janimo> FourDollars, I just read that doc now, I also need to work on a separate SRU :)
<tumbleweed> I think in the first week, fixing relatively straightforward issues directly into -proposed is ok
<tumbleweed> it's not like it would actually be tested by anyone in precise
<tumbleweed> (assuming you copy-up from oneiric-proposed to precise)
<FourDollars> ibus-chewing that I work on is the same version in precise and oeniric.
<FourDollars> How should I do ?
<FourDollars> Changing oneiric to oneiric-proposed ? Or oneiric to precise?
<tumbleweed> upload to proposed as usual, and request that it be copyied to precise when accepted
<FourDollars> I see. Thanks, tumbleweed.
<janimo> tumbleweed, I am glad to hear there are some exceptions :)
 * tumbleweed isn't in the SRU team, I just know what I've done in this situation :)
<FourDollars> I have changed bzr repo from oneiric to oneiric-proposed.
<FourDollars> What should I do next?
<FourDollars> What should I do in next step?
<FourDollars> This patch should just be a Stable Fix .
<tumbleweed> FourDollars: target oneric-proposed in the changelog, use 1.3.9.2-3ubuntu1.1 as your version, and get a sponsor to upload it. Then add a comment on the bug, asking the SRU team to copy it up when accepting it.
<FourDollars> tumbleweed: Should I use 1.3.9.2-3ubuntu1.1 because 1.3.9.2-3ubuntu1 is my upload?
<FourDollars> tumbleweed: I just want to upload second patched version.
<tumbleweed> FourDollars: the .1 makes it obvious that it was an SRU. See the security team's verisoning policy linked to from the SRU wiki page
<FourDollars> tumbleweed: I see. Thanks for your explanation.
<FourDollars> I have changed to 1.3.9.2-3ubuntu1.1 .
<apw> mvo, i saw your analysis of the upgrade issue, do you want me to remove the package to confirm its my issue, or wait until you have something to test
<mvo> apw: please remove I have the dpkg status file that was enough to reproduce the problem
<apw> mvo, awsome preplanning ... will do and update theb ug
<superm1> mvo, i've been seeing people reporting in forums about 11.04->11.10 mythbuntu upgrades pulling in unity-greeter rather than mythbuntu-lightdm-theme.  no one has filed a proper "bug" yet for it, but do you think this can be a side effect of calling do-release-upgrade without --mode=desktop?
<mvo> superm1: it shouldn't be, the release-upgrader should figure this out automatically, it would be cool to get access to the logs when this happend
<tjaalton> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, smo
 * cjwatson flushes through an initial batch of mass syncs to precise, up to fonts-vlgothic
<cjwatson> I'll do the next batch after a publisher run has happened
<pitti> cjwatson: oh, sync-source.py is working again?
<pitti> or do we use an lplib tool now?
<Laney> huzzah
<Daviey> Hmm.. precise-changes mailing list doesn't seem to be showing everything.
<pitti> WFM
<pitti> Daviey: oh, "everything" -- what's missing?
<Daviey> yeah, not me
<Daviey> pitti: https://launchpad.net/ubuntu/+source/nova/2011.3-0ubuntu7
<Daviey> https://launchpad.net/ubuntu/+source/ajaxterm/0.10-12ubuntu1
<Daviey> https://launchpad.net/ubuntu/+source/antlr/2.7.7+dfsg-1
<Daviey> https://launchpad.net/ubuntu/+source/libxml-security-java/1.4.5-1
<Daviey> Infact, everything i have done.. :)
<pitti> right, confirmed
<Daviey> (including sponsorships.)
<cjwatson> pitti: wgrant fixed sync-source
<cjwatson> pitti: moving to an lplib tool is blocked
<cjwatson> Daviey: #launchpad(-dev) might be better placed to look into this
<wgrant> Daviey, cjwatson: I poked bigjools about that earlier, but I think he's distracted.
<cjwatson> Daviey: FWIW I think I have been saying that I don't yet advise using syncpackage for sponsorships, and that people should continue to use old-style sync requests for those for now
<wgrant> I don't know if mailman is stopping them, or LP isn't sending them, or...
<Daviey> cjwatson / wgrant: ok, thanks
<Daviey> cjwatson: Yeah, i'm not sponsoring sync's.. (although i did do one that someone had requested shortly before).
<Tanguy> Hello.
<Tanguy> I am the maintainer of the Debian package itstool, which is ahead from the one in Ubuntu.
<Tanguy> So if someone is able to sync, please do so. :-)
<cjwatson> Tanguy: https://wiki.ubuntu.com/SyncRequestProcess
<cjwatson> somebody will need to verify that there are no Ubuntu-local changes lost by a sync
<Tanguy> There are.
<cjwatson> there are changes lost?
<Tanguy> The package currently in Ubuntu was done for Ubuntu only.
<Tanguy> Because at that time itstool was not in Debian.
<cjwatson> I mean substantive changes, not changelog or whatever
<Tanguy> I do not think there are.
<cjwatson> please put this information in a sync request bug
<cjwatson> we don't process syncs by IRC, it would get unwieldy :-)
<cjwatson> definitely appreciate your interest though
<cjwatson> hmm, why is merge-o-matic showing differences relative to unstable
<cjwatson> I told it usto use testing
<FourDollars> tjaalton: ping
<tjaalton> FourDollars: pong
<FourDollars> tjaalton: Could you help https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ?
<ubottu> Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed]
<FourDollars> tjaalton: There is a crash bug existed in oneiric and precise.
<Tanguy> cjwatson: Okay, as long as it is simple, for I have no specific interest in Ubuntu except the will to be nice. :-)
<tjaalton> FourDollars: so upload to both oneiric-proposed and precise?
<FourDollars> tjaalton: Yes, if it is ok.
<tjaalton> FourDollars: sure, setting up chroots first
<cjwatson> Tanguy: otherwise perhaps ask mterry, since he prepared the Ubuntu package
<FourDollars> tjaalton: Are you asking me to set up chroots or you are setting up chroots?
<Tanguy> cjwatson: I think I can assume he will see the sync request.
<Laney> did we make syncpackage / requestsync default to testing?
<tjaalton> FourDollars: no, I'm doing that right now, will get to your bug later
<FourDollars> tjaalton: I see. Thanks.
<cjwatson> Laney: not in oneiric at least
<Laney> indeed
<tumbleweed> Laney: I assumed we'd still want to default to unstable for manually requested syncs (or I would have made the change near the end of oneiric)
<cjwatson> I can see that argument, certainly
<tumbleweed> cjwatson: maybe you'll know: I noticed that lp doesn't have a release date for oneiric. Can someone set one? http://paste.ubuntu.com/710708/ (Asked a few times on the weekend, with no response) Should this be on one of the release checklists?
<cjwatson> can't, requires an LP admin
<tumbleweed> ok, I'll poke #launchpad, thanks
<cjwatson> this went wrong in natty too, but IMO it shouldn't be checklisted, LP should be fixed to set it automatically when the distroseries goes to CURRENT
<tumbleweed> right, a bug then :)
<Laney> hmm, not bothered either way. At least for haskell that is true (because migrations are pretty awful there).
<tumbleweed> filed bug 876345
<ubottu> Launchpad bug 876345 in Launchpad itself "distro series releasedate not automatically set" [Undecided,New] https://launchpad.net/bugs/876345
<cjwatson> ah, bzr update in mom's deployed branch failed
 * cjwatson runs bzr upgrade to fix that
<cjwatson> with any luck it won't run out of disk
<cjwatson> I've also fixed rmadison to not have stale data for precise (its mirror wasn't using --delete so it had stale uncompressed Packages/Sources lying around)
<geser> tumbleweed: for the last lts where we also synced from testing, requestsync defaulted to testing. IMHO it should do it now too. It might not be important till DIF (when the tools are used seldomly) but more important after DIF. If someone sync from unstable it should be because they passed an option and not because they missed to tell it should sync from testing.
<tumbleweed> hrm, u-d-t SRU time then
<doko> cjwatson, is -Werror=format-security really that a good idea?
<pitti> in general I appreciate these warnings, as they are often real bugs
<cjwatson> doko: I think it is
<pitti> did you find a case where it isn't?
<cjwatson> it has a pretty good hit rate
<cjwatson> sure, there's the odd FP, but also lots of cases where people assume that translators never get format strings wrong
<cjwatson> (or are never malicious ...)
<doko> well, what it the use for something like printf("foo\n"); ?
<doko> just watching the ftbfs list grow because of this
<pitti> if that generates an error, that indeed looks wrong
<cjwatson> that shouldn't fail -Werror=format-security
<cjwatson> it is certainly not documented to fail it
<cjwatson> if gcc is failing that, that's a gcc bug
<pitti> it doesn't here, at least not in precise
<pitti>    printf("foo\n");
<pitti> -> no error
<pitti>     printf(f);
<pitti> -> error, as it should
<pitti> sorry, s/not in precise/not in oneiric/
<doko> yes, it was the latter. however if we didn't have this until now, why for the lts?
<cjwatson> we had it in oneiric, no?
<doko> no
<doko> this comes with the dpkg merge
<cjwatson> oh, do you mean that this is a dpkg change?  I wondered why you were asking me
<cjwatson> context helps!
<doko> sorry =)
<cjwatson> if you want to back that out of dpkg for the LTS, feel free
<pitti> is there a way that we could keep that for main packages only?
<doko> let's see how many ftbfs we'll get with this
<cjwatson> it was a 445000-line change, I didn't look at all of it :-)
<doko> pitti: if you want to mess with dpkg-dev, maybe.
<cjwatson> yeah, it would be nice to see if it's feasible to keep that; given that the change is in Debian we should not be getting new failures added from here on, only old ones
<cjwatson> I wouldn't want to hack dpkg to know about different components
<pitti> doko: too fiddly within dpkg-dev IMHO
<cjwatson> it would be horribly confusing for local builds
<pitti> I meant, could the buildds export a different CFLAGS depending on the components
<pitti> but right, local reproducability
<pitti> ok, ignore me then
<ev> I don't suppose anyone has written a tool to unpack all the source for the base system? I'm trying to find out what packages use the automatic codec installation, and grepping for the header seems like the most straightforward approach.
<pitti> yay @ component-mismatches explosion
<pitti> ev: I have a little "for-srcarchive" script on lillypilly:~pitti/bin/ which you give an archive root (/srv/archive.ubuntu.com/ubuntu), a sources path (dists/precise/main/source/Sources.gz), and a command to run there (like grep ...)
<pitti> ev: it outputs ==== pkgname === and then the output from the command
<pitti> it runs a couple of hours for universe, though
<seb128> ev: it's likely going to be mostly totem, rhythmbox, banshee
<seb128> dunno about others
<ev> pitti: awesome!
<ev> seb128: indeed, thanks
<McPeter> hi ev are you here ?
<McPeter> grmlmgmr (sorry)
<lool> slangasek: Hey there, I see "syncpackage: Source package u-boot is blacklisted." when using syncpackage on u-boot; I can't find it in the old http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt and I can't find a link to an explanation at https://launchpad.net/ubuntu/+source/u-boot but would you remove it from the blacklist?  I can't see a reason it should be blacklisted, we need it to provide mkimage in Ubuntu
<lool> (and it's in already in Ubuntu since some cycles)
<tumbleweed> lool: it's only blacklisted for a particular pair of versions
<cjwatson> lool: that's just syncpackage/LP being obscure about the fact that it has Ubuntu changes.  Use -f.
<tumbleweed> LP does that automatically, and in a buggy way, this isn't the only package with that problem
<lool> cjwatson: I checked on another package and didn't get this warning, maybe I picked my sample wrong though
<cjwatson> lool: it's not blacklisted, anyway.
<cjwatson> lool: use -f.
<tumbleweed> lool: bug 841372
<ubottu> Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372
<lool> cjwatson: Yup, I actually sync-ed with with -f already
<lool> tumbleweed: thanks
<lool> tumbleweed: where did you find the list of blacklisted versions?
<tumbleweed> you can do an api query
<lool> slangasek: (never mind, apparently a known LP bug)
<\sh> hmmm...oneiric and an asus pro 61S laptop is a total nogo
<cjwatson> hm, I need to merge gnutls26 pronto apparently
<Rantpaste> Looks like mono-xsp-base was deleted from Oneiric - anyone know if it was put in another repo?
<Rantpaste> Alternatively, is there a better place to ask?
<Laney> now that size of build queue is what I like to see
<cjwatson> Laney: and I haven't even completed the mass sync ...
<Laney> are you doing new packages at the same time?
<cjwatson>   * [9e2a65a] Move XSP4 features into a new mono-xsp4-base package, and
<cjwatson>     rename mono-xsp-base to dh-xsp since it only contains dh_installxsp.
<cjwatson> Rantpaste: ^-
<Laney> yeah, 1.1 has gone away
<Laney> we have xsp2 and xsp4 now
<Rantpaste> Cool
<cjwatson> Laney: a few at a time, yes
<Rantpaste> so my iFolder package needs updating :)
<Laney> didn't that have license problems or something?
<cjwatson> Laney: not terribly consistently, so shout if anything's urgent
<Laney> can't think of anything major, there was some mono stuff that people wanted backporting but a) I can't remember what it was and b) it's not so urgent
<Laney> if you could do haskell-* from unstable at some point though
<cjwatson> I did :-)
<cjwatson> oh, well, from testing
<cjwatson> for stuff from unstable I'd prefer to have sync request bugs (or you can syncpackage them)
<Laney> waiting for it to migrate is a pain
<Laney> I'll sort something out at some point then
<cjwatson> right, I don't mind people explicitly syncing stuff from unstable when they know what they're doing, I just don't want rationale/requestor hidden behind the autosync machinery
<Laney> fair
<Laney> maybe the clever new hinters will make migration behaviour nicer at some point
<cjwatson> oh, BTW, I added http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html
<kees> doko, cjwatson: yeah, the Werror=format-security caused about 120 ftbfses in the debian archive, iirc. most of them have been tagged in the bts and patches and being made. I think it's worth it too, but I did intentionally only turn it one in dpkg-buildflags so that it would slowly make it's way into the builds instead of putting it in the compiler like the others.
<kees> it has a fair bit of FP, but catches enough real bugs to make it worthwhile
<tkamppeter> pitti, hi
<Laney> wait, I forgot, iulian wants to help look after Haskell this cycle :-)
<tkamppeter> pitti, can you have a look at https://launchpadlibrarian.net/83022758/buildlog_ubuntu-precise-amd64.ghostscript_9.04%7Edfsg-0ubuntu12_FAILEDTOBUILD.txt.gz, seems that the buildds is not able to install CUPS on precise.
<geser> Laney: any haskell transitions this time?
<Laney> just the usual
<Laney> probably get a new ghc with the new platform at some point
<cjwatson> oh argh, gnutls26 indirectly self-build-depends and is currently uninstallable
<geser> tkamppeter: this could be due to the gnutls merge cjwatson is working on
<cjwatson> maybe it will build cleanly in an oneiric PPA?
<cjwatson> tkamppeter: yeah, ignore it for now
<tkamppeter> pitti, problem is on all supported archs.
<cjwatson> tkamppeter: yes I know
<tkamppeter> cjwatson, it builds cleanly in an Oneiric PPA, as the main change (liblcms1 -> liblcm2) I have already made available via PPA, the other differences to my PPA version are small patches.
<tkamppeter> cjwatson, geser, it will be rebuilt after the buildds is fixed?
<cjwatson> tkamppeter: yes, please leave me alone for now to work on it
<geser> tkamppeter: yes if someone gives it back after the buildds got fixed
<cjwatson> I will take care of it
<chrisccoulson> bdrung, do you look after vlc?
<bdrung> chrisccoulson: you are thinking about 1.1.12 for oneiric?
<chrisccoulson> bdrung, no, i just got pinged by someone from mozilla about bug 876625 ;)
<ubottu> Launchpad bug 876625 in vlc (Ubuntu Oneiric) "VLC plugin is making Firefox crash" [Critical,Triaged] https://launchpad.net/bugs/876625
<bdrung> chrisccoulson: oh, haven't seen this bug yet. i am on amd64
<chrisccoulson> yeah, me too
<bdrung> chrisccoulson: i have no time this week to look at it deeper
<bdrung> chrisccoulson: can we get vlc 1.1.12-2~oneiric1~ppa1  from https://launchpad.net/~bdrung/+archive/ppa tested against this bug?
<chrisccoulson> bdrung, if we can find someone to reproduce it :)
<superm1> mvo, ok, i'be been trying to get people to file bugs, but nothing yet.  with how prevalent it is, hopefully someone will
<Daviey> slangasek: Hey, are you able to chime into bug 862129, would like to try and get this moving.  Dupes are arriving quickly
<ubottu> Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<mvo> superm1: thanks, once there is a useful log, please let me know I will jump onto it
<superm1> ok
<Q-FUNK> cjwatson: is there some special trick one must do to enable dh_apport or is dh7 supposed to call it automatically on ubuntu?
<cjwatson> dh --with apport
<cjwatson> and build-depend on dh-apport
<cjwatson> (sorry, to be clearer, it's typically 'dh $@ --with apport' - I should mention that since the command-line ordering is counterintuitive)
<Q-FUNK> cjwatson: ok. could it be a good idea to implement it by standard, witout the need to explicitely --enable-it or is there any particular reason for not doing it?
<cjwatson> it's an Ubuntu-specific thing and I don't think we should change the default behaviour of debhelper
<cjwatson> besides, --with is a common way to extend dh's behaviour
<cjwatson> see e.g. --with python2
<Q-FUNK> yes, it's ubuntu-specific, but it would seem to make sense to auto-install any *.apport found whenever building for ubuntu.
<Daviey> stgraber: Is merging fetchmail on your plan?
<cjwatson> to do that it would have to be integrated into debhelper proper
<cjwatson> which is not currently on my list of things to do
<Q-FUNK> yes, it would, and it would make sense to include this as a standard part of the debhelper diff for ubuntu.
<Q-FUNK> ah.  oh well.
<cjwatson> that's a guaranteed way to ensure it never gets into Debian
<seb128> cjwatson, is dh-apport doing anything out of installing the hooks?
<cjwatson> so I'm not going to slam it into Ubuntu's debhelper, no
<cjwatson> seb128: no
<seb128> cjwatson, I usually just list those in the .install, that seems smaller diff than adding a build-depends and a rules change but I might be overlooking something
<seb128> ok, thanks
<cjwatson> I prefer having a dh_ command for it.  you are welcome not to use it.
<cjwatson> I really don't care :)
<seb128> yeah, I just wanted to check if I missed a good reason to use it ;-)
<Q-FUNK> we welcome the command, not the extra build-deps.
<Q-FUNK> but ok, fair enough :)
 * cjwatson shrugs
<seb128> don't count me in this "we", I'm fine with the build-depends being there ;-)
<Q-FUNK> fair enough :)
<cjwatson> it seems kind of bizarre to me to have an extension mechanism and then object to using it :-)
<Q-FUNK> it seems even more bizare to not include it by standard in the ubuntu diff for debhelper. :)
<cjwatson> politics, to some extent.
<stgraber> Daviey: not really, am I touched-it-last on it?
<Daviey> stgraber: looks like it :)
<stgraber> Daviey: well, if you want to do it, feel free :) otherwise I'll look at all of these where I'm touched-it-last either this week or next
<Daviey> stgraber: Are you attached to the delta, https://launchpad.net/ubuntu/+source/fetchmail/6.3.19-1ubuntu1 ?
<slangasek> Daviey: what chiming are you looking for on bug #862129?  I've commented on the historical reasoning for the package being the way it is, I don't really have input beyond that
<ubottu> Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<stgraber> Daviey: nope. I never used fetchmail as a daemon :) I think I'm touched-it-last on this one because I took all of Artur Rona's merges last cycle, so feel free to sync from Debian if you're not attached to that delta either
<Daviey> stgraber: It doesn't look worthwhile to carry IMO, can always re-introduce it.
<Daviey> thanks
<stgraber> thanks for reducing my list of merges ;)
<Daviey> (fwiw, i don't think the touched-it-last is the best way of allocating work.. but *shrug*)
<cjwatson> it's not a way to allocate work
<cjwatson> it's a way to avoid duplicating work
<cjwatson> people are welcome to hand things over
<cjwatson> "I'd like to do this merge; are you working on it?" is entirely reasonable
<micahg> stgraber: I grabbed a few of those as well :), unless you're referring to main only
<stgraber> micahg: I only looked at main, I'm sure he had a lot more in universe
<micahg> pitti: would this be a good week to get Firefox 7/final langpack run for maverick going or would you like to wait until after UDS?
<micahg> stgraber: ah, yeah
<maco> tjaalton: still piloting?
<hyperair> hmm the new umask in oneiric seems to be affecting the buildds.
<geser> hyperair: how? some packages might be buggy by assuming a umask instead of setting the one they expect
<hyperair> geser: no, it's a dh_thing
<hyperair> geser: what's that dh_ thing that optimizes pngs?
<tumbleweed> pkgbinarymangler
<hyperair> -rw-rw-r--  root/root   /usr/share/icons/hicolor/48x48/apps/gnome-mplayer.png
<hyperair> see that?
<hyperair> i suspect it's the same for all png files of packages using dh_blah that are built after the umask change
<geser> file a bug against pkgbinarymangler and pitti will look at it
<debfx> I think that pkgbinarymangler bugs has been fixed already
<hyperair> hmm really?
<hyperair> i had issues with sbuild very recently
<hyperair> something like yesterday or the day before
<maco> anyone want to sponsor a really simple fix for a main package for me?
<debfx> bug #817792
<ubottu> Launchpad bug 817792 in pkgbinarymangler (Ubuntu) "pkgstripfiles doesn't preserve permissions of png files" [High,Fix released] https://launchpad.net/bugs/817792
<stgraber> maco: sure
<maco> stgraber: thank you! https://code.launchpad.net/~maco.m/ubuntu/oneiric/nvidia-settings/fix-missing-dependencies-for-kubuntu/+merge/79588
<hyperair> debfx: oh nice.
<stgraber> maco: was that uploaded to Precise already?
<hyperair> debfx: would it be wise to rebuild the affected packages?
<hyperair> a quick check of my /usr/share/icons reveals upwards of 600 affected icons.
<maco> stgraber: no. i thought (from -devel ml) that syncs were busted on precise... are there packages there to futz with now?
<debfx> I don't think so as long as the files are owned by root:root
<maco> if so i guess i can make a merge proposal for that too, but itll be the exact same diff :P
<stgraber> maco: I think syncs have been fixed today, though if that's in Debian it'll get synced automatically and fixed then. I just want to make sure we don't get a regression on Precise
<hyperair> debfx: true that. i guess we can just leave it then
<stgraber> maco: does 280.13-1 in Debian contain that fix?
<geser> some mass-syncs from testing were done today
<stgraber> maco: uploaded to oneiric-proposed
<maco> im looking. i dont see anything in debian's changelog about it, but downloading to check the control file anyway
<stgraber> maco: and also uploaded to precise so whoever ends up doing the merge won't iss it
<stgraber> *miss
<maco> debian's missing it too
<maco> thanks
<maco> guess i should talk to the debian maintainer
<stgraber> yep, would be good to have that fixed in Debian
<stgraber> maco: oops, that didn't quite work because of the package using a control.in... I should have seen that
<stgraber> maco: I'll upload a new one to precise and -proposed
<maco> crap :(
<maco> hmm....
<maco> oh how odd
<maco> debian's DOESNT use a control.in
<maco> but ours does
<stgraber> SpamapS: Hi! There's currently two nvidia-settings package with the same version number in the proposed queue for Oneiric. Can you reject the first one (the one where the only change is debian/changelog)?
<SpamapS> stgraber: ACK, will take a look shortly as I'm about to start doing SRU reviews
<stgraber> SpamapS: thanks
<maco> stgraber: thats confusing
<maco> because lp's diff preview on the merge request shows changes in control
<maco> or are control & control.in both in the source package even though control is generate?
<stgraber> yeah, it's one of these cases where the branch looks good but running debuild drops the change... except that "bzr bd" runs outside of the branch so you really need to debdiff the result...
<maco> i think i get why ScottK doesn't use bzr branches
<maco> they're hell with quilt and sometimes hide problems
<stgraber> both are in the source package with the real control being generated when you run debuild. I guess it would probably be better not to have debian/control in the branch at all as it's generated, that'd avoid the confusion
<micahg> stgraber: I try to remember to debdiff the new version against the old before uploading in case something like this happens
<stgraber> micahg: yeah me too, though this time I forgot and only did it post-upload...
<micahg> stgraber: it happens :)
<micahg> stgraber: if it's only -proposed, it can be rejected still if it hasn't been accepted yet
<maco> i have a question
<stgraber> micahg: it needs up taking quite a bit of bandwidth though when you need to: grab the branch, merge, commit, push the change, grab the current source package, diff the two and upload :)
<maco> that answered it
<maco> wanted to know how you debdiff when youre going from a branch
<maco> i guess you could bzr branch, bzr bd, change, bzr bd, debdiff
<micahg> maco: grab the old source :) pull-lp-source works for that
<stgraber> micahg: yeah, I asked SpamapS to reject and I uploaded a clean one with the same version number. Though I had to do two uploads to Precise as I initially pushed to both -proposed and precise :)
<stgraber> maco: yeah, that's assuming you trust the bzr branch ;) I prefer to trust what's in the archive
<maco> at that point i wonder why use bzr then :-/
<maco> if youre gonna make a debdiff ANYWAY...might as well just submit that
<maco> and then even the anti-bzr sponsors will take it
<micahg> maco: exactly why I don't use it :)
<geser> lool: can I take the vim merge of you?
<stgraber> it's nice to stage changes and get more meta-data on what's been commited
<micahg> maco: well, I don't use it for stuff that I don't actively maintain (random universe packages)
<maco> oh right. maintain. i should fix that debian package...
<maco> (not this one. the one im actually listed as an uploader on)
<lool> geser: I've uploaded it already?
<lool> geser: sorry, upload was rejected for some reason, but it's ready
<geser> ok then
<lool> re-uploaded
<lool> it was missing the .orig.tar.gz the first time, I thought I had pushed it again, but apparently not
<lool> geser: but in general, I wouldn't mind you caring for it in the future as you seem to be used to this diff  ;-)
<geser> sure, therefore I asked as I did the last merge but you did the last upload
<lool> ack; thanks for the offer
<geser> I need to shorten the diff to the changelog on the next merge as it is way longer than the actual changes
<jbicha> quilt doesn't support binary diffs, right?
<tumbleweed> jbicha: they can be included directly in the .debian.tar.gz with dpkg-source's included-binaries option
<jbicha> tumbleweed: I'm trying to add a missing binary to a ubuntu-desktop branch, how would that work?
<maco> jbicha: is the binary supposed to be in the source package?
<lool> geser: Eh
<lool> geser: If you're tempted to look into it, it FTBFSed due to other packages being uninstallable
<lool> probably mass sync issues
<jbicha> I'm trying to backport this commit which missed 3.2.1 by a few hours http://git.gnome.org/browse/aisleriot/commit/?h=gnome-3-2&id=b9a1f676657a729f1a3bfd0952879c25c9c74f76
<maco> oooh oggs
<maco> yeah i think youre gonna have to go with what tumbleweed said
<tumbleweed> jbicha: with svn, one just included them in the tree, outside the ubuntu dir. Never done it with bzr. /me looks
<jbicha> I think it's a little more complicated since we generally only have debian/ in our packaging branches?
<tumbleweed> no I'm also talking about merge mode in svn
<jbicha> oh ok
<geser> lool: the problem is the pending libgnutls merge but it's being worked on
<micahg> jbicha: I think with source format 3, you can throw it in the debian dir and move it into place in .install
<zimmerle> Hey kees, can you point me where i can find information about the AppArmor mediation of DBus communications?
<zimmerle> i saw the blueprint, its says "Beta Available". Where i can find out this code?
<zimmerle> jdstrand: ^
<micahg> zimmerle: jjohansen might be able to help you
<jjohansen> zimmerle: ah, I still need to get the code posted
<zimmerle> micahg: thanks ;)
 * jjohansen keeps meaning too, but has treated posting as low priority, as it needs to be reworked
<zimmerle> jjohansen: cool, what is the current status?
<jjohansen> zimmerle: its a direct dbus patch, it needs to be reworked into something less ugly.  The plan was to make an lsm/xace type interface for dbus and push that upstream, so that selinux, apparmor and others can be plugins
<kees> zimmerle: sorry for the delay :) yeah, jjohansen and jdstrand are the people to talk to (which you've found...)
<jjohansen> zimmerle: beyond that, there is an outstanding bug that can't be fixed until the apparmor kernel module properly supports the get_peer_cred, and policy can't handle the task labeling yet
<jjohansen> zimmerle: beyond that it seems to work okay.  It fairly flexible, I can forward you the email I sent out about it
<jjohansen> there were some testing packages I built
 * jjohansen will try to get the code up to a bzr tree this afternoon
<jbicha> micahg: thanks, your suggestion works
<jjohansen> zimmerle: the code rework I mentioned isn't strictly necessary, it just makes sense, and should make pushing upstream to dbus easier
<micahg> jbicha: where in the debian directory I think is up to team policy, but not 100% sure on that
<tjaalton> maco: "oops"
<tjaalton> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smo
<zimmerle> jjohansen: would be nice to have your code, so I can see if I can help with anything.
<jjohansen> zimmerle: oh I am sure we could find ways for you to help
<jjohansen> :)
<zimmerle> :)
<tumbleweed> jbicha: for the record, I had to bzr-buildpackage -S -- -uc -us --source-option='--autocommit' --source-option=--include-binaries for it to work, so yes micahg's suggestion is preferable :)
<tumbleweed> ah, I must have deen doing something wrong, once it was listed in include-binaries it worked without that...
<cnd> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smo, cnd
<yofel> pitti: could one SRU the precise version of kdenlive to oneiric to fix bug 863186 - I have no idea what exact modification fixed the issue, but kdenlive in oneiric is unusable - unless you know how to manually write configuration files.
<ubottu> Launchpad bug 863186 in kdenlive (Ubuntu) "[Oneiric] Kdenlive configuration vizard doesn't founding MLT SDK" [Medium,Fix released] https://launchpad.net/bugs/863186
<lool> jono: Hey there!  Would you have some 5-10 minutes to discuss some UDS bits?
<jono> lool, can you give me a few mins, just wrapping a call
<lool> jono: Sure
<jono> thanks!
<jono> :-)
<jono> lool, hey
<jono> what's up?
<lool> jono: where would I call you?
<cjwatson> I think gnutls26 is disentangled now.  I've given back everything in main that appeared to be affected and a fair bit of universe too.
<geser> vim (i386) build succesfully now
<geser> lool: ^^
<lool> geser: thanks a lot for looking after it
<mdeslaur> cjwatson: I blame you for bug 876829 :)
<ubottu> Launchpad bug 876829 in ifupdown (Ubuntu) "Oneiric's ifupdown breaks ip aliases" [Undecided,New] https://launchpad.net/bugs/876829
<stgraber> mdeslaur: and now he's gone ;)
<mdeslaur> stgraber: coward :)
<stgraber> mdeslaur: though my guess is that you want to blame Debian on that one (well, we're shipping an alpha version of 0.7, so not entirely Debian's fault ;))
<slangasek> mdeslaur: if you run 'ifup -a' post-boot, does it work?
<slangasek> i.e., does it bring up the alias
<mdeslaur> slangasek: nope
<slangasek> ok
<slangasek> definitely an ifupdown bug, then
<slangasek> can you note that on the bug please?
<mdeslaur> slangasek: yes, thanks
<slangasek> stgraber: regardless of who's to blame, could you please look into this :)
<stgraber> mdeslaur: Debian ships 0.7~alpha5+really0.6.15 in wheezy/sid and has 0.7~beta1 in experimental, so quite likely that something was flagged as being wrong on their side too
<mdeslaur> hehe, I was only joking about the blame part :)
<stgraber> slangasek: happy to look at that tomorrow ;) enjoying my day off (kind of) today
<slangasek> ack :)
<stgraber> my guess is that the diff from 0.7~alpha5 and 0.7~beta1 may well contain the fix for mdeslaur's bug
<seb128> slangasek, hey, don't use "ubuntu-desktop" for bug assignments, that spams the ubuntu-desktop list ;-) Use canonical-desktop-team or desktop-bugs ;-)
<slangasek> seb128: hmm, ok
<slangasek> seb128: sorry
<seb128> slangasek, no worry, it's a frequent mistake, we should perhaps fix our list to block all launchpad emails ;-)
<slangasek> seb128: well, or fix the team configuration in LP to not send mail to the list if that's not what you want to have happen :)
<seb128> slangasek, well if the team has no list it sends the emails to all members
<slangasek> right
<seb128> not really better ;-)
<slangasek> yeah, I dunno then
<slangasek> cjwatson, TheMuso: e2fsprogs has a very old change to the optimization flags being passed on powerpc, to "avoid a suspected toolchain bug" when using -Os; but I don't find any references to this toolchain bug having ever been reported.  I don't suppose one of you could follow through on that, so we can possibly drop that part of the delta?
<slangasek> cjwatson, TheMuso: (low priority, best case we'll still have a delta due to dietlibc)
<cjwatson> TBH I have no idea what that was, perhaps just drop it and let's see what gets reported?
<cjwatson> it looks easy to reproduce at least ...
<slangasek> cjwatson: I'm hesitant to just drop it and see what gets reported because I have the impression we don't get a lot of powerpc coverage, so I'm worried it might make it all the way into release without being noticed if I just drop it
<slangasek> OTOH, I guess by this point if the bug were still present, Debian would have the same problem...
<cjwatson> slangasek: I do know how to test powerpc installs in qemu nowadays (although it's really slow so I don't do it very often); one option would be to drop it and then assign me an alpha-1 bug or something to test if it's still needed, perhaps
<slangasek> cjwatson: will do that then, thanks
<cjwatson> sigh, it's amazing how quickly failed builds can rack up when core packages are broken
<geser> does somebody know if "INFO Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression." from a "Failed upload" is an Ubuntu-specific error or does it apply to Debian too?
<tumbleweed> geser: ubuntu-specific, we need it for LTS-to-LTS upgrades to precise
<tumbleweed> squeeze supports xz, IIRC
<geser> ok, so it doesn't need forwarding to Debian?
<tumbleweed> don't think so. Saw grumbling about it in #debian-devel today...
<micahg> !info dpkg squeeze
<ubottu> 'squeeze' is not a valid distribution: hardy, hardy-backports, hardy-proposed, kubuntu-backports, kubuntu-experimental, kubuntu-updates, lucid, lucid-backports, lucid-proposed, maverick, maverick-backports, maverick-proposed, medibuntu, natty, natty-backports, natty-proposed, oneiric, oneiric-backports, oneiric-proposed, partner, stable, testing, unstable
<micahg> !info dpkg stable
<ubottu> dpkg (source: dpkg): Debian package management system. In component main, is required. Version 1.15.8.11 (stable), package size 2282 kB, installed size 6864 kB
<geser> what is "kubuntu-experimental"?
<cjwatson> geser: no, it doesn't need forwarding, because Debian's last release had xz support
<cjwatson> we got unlucky
<cjwatson> geser: I fixed five or so of those missing pre-depends this evening
<cjwatson> e.g. altree
<Daviey> seb128: We *want* people to use ~ubuntu-server, rather than ~canonical-server for server bugs.. People keep assigning bugs to ~canonical-server.. Desktop being opposite helps this confusion :)
<micahg> Daviey: I know one Ubuntu Server team member that's quite opposed to that
<Daviey> micahg: I don't care for annon opposition TBH :)
<seb128> micahg, hey, sorry I was away when you pinged, I've discussed with upstream webkitgtk about their schedule and they say they are strongly aligned on GNOME
<seb128> micahg, i.e we should track 1.8 next cycle
<micahg> seb128: indeed, but if we're sticking with GNOME 3.2, shouldn't we track 1.6 by default?
<seb128> micahg, no session needed at UDS imho, it's a bit too technical to do an useful on schedule session, that was as well be discussed out of a session
<micahg> seb128: re session> no disagreement here
<seb128> micahg, well, I'm usually in favor of updating the platform libs when we cna
<seb128> i.e we plan to update glib and gtk
<seb128> updating webkit should be fine, there is not a lot of GNOME depending on it and stuff like epiphany-browser can be updated as well
<micahg> seb128: ok, then I can try to push for 1.8 as an LTS upstream as well (should work out about right for Debian as well, I guess I should ping them too)
<seb128> micahg, great
<seb128> Daviey, well I don't like much abusing the canonical teams for assignments but there is pro and con for each, including how we structure our desktop teams and lists ;-)
<Daviey> seb128: sure.
<seb128> Daviey, usually we use assignment to canonical-desktop-team for issues somebody think our team should officially look at, i.e escalation, for the other desktop bugs we tend to nominate for a cycle but not assign
<Daviey> seb128: makes sense.
<cjwatson> kirkland: may I merge cdebconf?  you're touched-it-last, but it's installer core and I'd like to get it merged
<kirkland> cjwatson: sure thing!
<kirkland> cjwatson: please
<kirkland> cjwatson: fyi, newt upstream upstream released a modified version of my color changes
<kirkland> cjwatson: we might be able to drop our patches against newt, though we'll need to rework the configuration file it reads, as the author chose a different format
<kirkland> cjwatson: i've not checked to see if debian has the latest newt from upstream, though
<cjwatson> I don't really need to look into that, I think
<cjwatson> just focused on merging and getting everything building at the moment
<kirkland> cjwatson: okay, sure, was just a related fyi, while i was thinking about it
<cjwatson> yup, thanks
<spickle> Can I post a crazy idea about ubuntu development in this channel?
<poolie> barry, hi?
<barry> poolie: hi
<poolie> hi there
<poolie> jelmer just suggested in bug 794353 that perhaps ubuntu's sys.getfilesystemencoding() should be always utf-8
<ubottu> Launchpad bug 794353 in Bazaar "ascii is a bad default filesystem encoding" [High,Confirmed] https://launchpad.net/bugs/794353
<poolie> (or at least a fairly strong default)
<poolie> at the moment it goes off $LANG (perhaps also other things)
<poolie> istr ubuntu generally has a strong expectation it be utf-8?
<poolie> obviously we can work around it
<poolie> ah actually that's not totally obvious, but we probably can
<barry> yeah, this is definitely not something i'd a) want ubuntu to deviate from debian; b) debian deviate from upstream
<barry> i think it's just asking for trouble if we deviate
<barry> e.g. what if someone installs python from source and runs bzr against that?  you'd still have to work around it
<cjwatson> "filesystem encoding" is a nonsense concept on Unix anyway (unfortunately)
<lifeless> its bytes all the way down
<cjwatson> file names are a byte stream, and encoding is up to the readers and writers
<lifeless> cjwatson: except on darwin :)
<poolie> cjwatson: i know, that's the problem
<cjwatson> I don't think the situation would be improved by having Python lie about it
<poolie> well
<cjwatson> bzr is actually in a better position to say "screw it, I have a convention" than Python is
<poolie> ubuntu has the choice to say "actually, it's normally utf8"
<cjwatson> Ubuntu can't control what people have on disk
<cjwatson> people might be using Python on their music collections with non-UTF-8 filenames
<cjwatson> (a not entirely uncommon setup ...)
<poolie> sure, they often are too
<lifeless> perhaps Ubuntu could make it -hard- to get a non-utf8 locale though
<cjwatson> it doe
<cjwatson> s
<poolie> there have been a bunch of u1 bugs about exactly that case
<barry> iirc, nl_langinfo(3) isn't always accurate either
<cjwatson> nl_langinfo is pretty good
<poolie> python itself seems to have a default to utf-8, but people commonly accidentally have it set to ascii
<cjwatson> I've never heard of it being wrong for this purpose
<poolie> i guess specifically LANG=C will assume the filenames are ascii
<tumbleweed> yay for C.UTF-8
<poolie> so the problem with bzr working around it is that there is a C variable inside python that holds the encoding, and no python api to reach it
<poolie> (i think)
<barry> sorry, i don't remember the details atm, but i do remember something weird with `locale charmap` not agreeing with nl_langinfo(CODESET) or somesuch
<cjwatson> barry: ok, all I can say is I've never seen that in the programs I've written that use nl_langinfo(CODESET), so I wonder if perhaps it was on some other OS
<poolie> i think the key issue on ubuntu is that LANG=C probably shouldn't mean "blow up on non-ascii filenames"
<poolie> nl_lang(CODESET) is what python calls fwiw
<barry> cjwatson: definitely ubuntu at some point, but no matter, i don't remember the exact details anyway ;)
<poolie> so the answer is basically: ubuntu's going to do what upstream python does, upstream python's going to believe nl_langinfo(CODESET), and that's ascii for LANG=C
<poolie> and other things people might set
<poolie> so either bzr needs to work around it, or we need to make it obvious to people they ought to use a locale that can decode their filenames
<barry> there's also $PYTHONIOENCODING if that helps
<slangasek> the only potential gotcha I can think of with nl_langinfo(CODESET) is that sometimes the "native" names for encodings returned by glibc don't look like the strings you might expect elsewhere (e.g., ASCII is not called "ASCII")
<slangasek> but in that case, it still matches 'locale charmap' anyway
<slangasek> $ LANG=C locale charmap
<poolie> barry: i think that's just the stream encoding not for filenames?
<slangasek> ANSI_X3.4-1968
<slangasek> $
<poolie> also LANG=''
<barry> slangasek: that could have been it
<cjwatson> I do think using nl_langinfo(CODESET) for filename encoding and raising exceptions when it doesn't fit is basically brain-damaged, but I agree with barry that diverging from upstream Python here would probably be a cure worse than the disease
<barry> i'm still trying to slog through the bug tracker to see if we have any related issues
<poolie> it's pretty bad to assume the terminal encoding and the filesystem name encoding are always the same
<cjwatson> and regrettably the right answer does quite often seem to be application-specific, so if there's a bug that you can't touch the filename encoding from applications, then I think that's what we (FSVO we) should fix
<slangasek> it's pretty bad that we have filesystem encodings at all, since they're not enforced by the filesystem :)
<slangasek> and we can't even sanely mount fat filesystems with utf8 as an encoding because of the case-smashing issue :P
<cjwatson> there'd be a case for forcing all filename operations to happen using bytes, except that I suspect that breaks other OSes ...
<barry> >>> import sys
<barry> >>> sys.getfilesystemencoding()
<barry> 'UTF-8'
<barry> >>> import locale
<barry> >>> locale.nl_langinfo(locale.CODESET)
<barry> 'ANSI_X3.4-1968'
<barry> >>> locale.setlocale(locale.LC_ALL, '')
<barry> 'en_US.UTF-8'
<barry> >>> locale.nl_langinfo(locale.CODESET)
<barry> 'UTF-8'
<barry>  
<barry> note that the above is python 2.7.  python 3.2 behaves differently:
<barry> >>> import sys
<barry> >>> sys.getfilesystemencoding()
<barry> 'utf-8'
<barry> >>> import locale
<barry> >>> locale.nl_langinfo(locale.CODESET)
<barry> 'UTF-8'
<barry>  
<barry> http://bugs.python.org/msg96095
<cjwatson> python 2.7 does an internal setlocale(LC_CTYPE) around setting Py_FileSystemDefaultEncoding
<slangasek> SpamapS: do you have an opinion on whether the lvm2 merge from Debian is safe?  Debian is now at 2.02.86; bug #726677 comments on 2.02.84 being "the safe" version, but I don't know if that's changed since.
<ubottu> Launchpad bug 726677 in lvm2 (Ubuntu) "[Wishlist] Upgrade lvm2 to at least 2.02.73" [Wishlist,Confirmed] https://launchpad.net/bugs/726677
<slangasek> SpamapS: also, maybe you're better poised to test this merge than I am?  I'm TIL on it, but it was for a minor build-system thing
<SpamapS> slangasek: I can take a look.. I'm impressed LVM2 actually made a real release. ;)
<SpamapS> IIRC it had been quite some time
<slangasek> SpamapS: heh.  they seem to have made several, upstream is at .88 now
<SpamapS> RHEL6 probably propelling that
<poolie> ok, thanks for the discussion
<slangasek> SpamapS: should I assign the bug to you for tracking?
<SpamapS> slangasek: please do, I plan to start working on merges tomorrow, will put that at the top of my list.
<slangasek> SpamapS: done, thanks
<SpamapS> slangasek: btw, did the mdadm situation in Debian ever get sorted?
<SpamapS> I recall there was a call for help.
<slangasek> SpamapS: I don't know
<SpamapS> Been bogged down in other things.. fairly interested in making sure mdadm is solid for 12.04
<slangasek> yep
<slangasek> we still have that un-worked spec proposing that we document the architecture :/
<SpamapS> if we cna justify it, I'd love to move that forward to P
<cjwatson> slangasek: FYI, I have coreutils merged, but I'm going to wait for tomorrow to upload it so I can be around for a solid block of time afterwards, just in case it plays the buildd exploding game
#ubuntu-devel 2011-10-18
<slangasek> cjwatson: heh, right :)
<cjwatson> TheMuso: I think vdk2 and vdkxdb2 can be synced; do you agree?
<cjwatson> (you're touched-it-last)
<luist> hey guys.. i need a live usb to identify the hardware on a machineâ¦ i found this project that is supposed to do it: http://sourceforge.net/projects/dhlu/files/  but i dont know how to use the tar.gz or its contents. They said it was tested in ubuntu! How can i test it?
<TheMuso> cjwatson: I haven't even looked TBH.
<TheMuso> cjwatson: So go ahead.
 * TheMuso is still doing alsa related merges.
<cjwatson> TheMuso: fair enough, thanks - done.  I think those two were you-as-patch-pilot rather than you-as-yourself anyway
<TheMuso> Right.
<cjwatson> (just noticed because I was fixing vdkbuilder2 to stop failing to sync)
<TheMuso> ah ok.
<TheMuso> slangasek: Unless you have a particular need/desire to do so, I'm happy to take care of the jack merge, as I need it to merge alsa-plugins with debian.
<slangasek> TheMuso: please go ahead
<TheMuso> Ok thanks.
<slangasek> cjwatson: new upstream version of wget in Debian adds libidn support, and there's no udeb for that.  It looks like you've done some work on that recently for libssl udeb support (bug #503339).  Do you know if wget-udeb has features over the busybox one that we need, or would we maybe be just as well off to drop wget-udeb?
<ubottu> Launchpad bug 503339 in wget (Ubuntu Lucid) "UEC lucid installer: CC fails to register when separated from CLC" [High,Fix released] https://launchpad.net/bugs/503339
<slangasek> cjwatson: in fact, I can't find any references to wget-udeb in seeds or in the debian-installer source
<nigelb> *groan*
<nigelb> Morning
<slangasek> RAOF: hi, I see that you have changes staged in bzr for avahi; do you want to take over the Debian merge as well?  I have no attachment to it
<RAOF> Neither do I, except that I wanted debugging symbols for it at one point.
<RAOF> I'll take the merge if you want, though.
<slangasek> RAOF: it's yours :)
<pitti> Good morning
<pitti> micahg: ffox7 maverick> fine for me this week; I need to request a full maverick export and prepare them, so I need a week of advance notice
<micahg> pitti: so what would be the timeline for hitting updates?
<pitti> micahg: I need to ask dpm to have a maverick LP export (they don't happen automatically any more), so I think I can have the new packs ready for -proposed upload at EOW
<micahg> pitti: that only gives us 10 days in updates before the next firefox release, can we do the week after UDS instead and target for Firefox 8?
<pitti> micahg: sure
<micahg> pitti: ok, thanks
<micahg> pitti: do you have moderation rights to the precise-changes list?
<pitti> micahg: no, I don't; is that moderated at all?
<micahg> pitti: must be, all my upload E-Mails seem to be stuck in moderation, I noticed Daviey's were cleared earlier today
 * micahg will bug the sysadmins when one is around then...
<slangasek> pitti: morning
<pitti> hey slangasek, how are you?
<slangasek> pitti: not bad! you?
<pitti> slangasek: pretty well, thanks
<slangasek> pitti: great :)
<pitti> playing whack-an-SRU
<pitti> they feel like a hydra these days, but that's pretty normal right after release :)
<slangasek> pitti: yep, I see :) and I just saw bug #788514 had an SRU for onboard, which seems rather strange to me... surely we're not changing packaging helpers in an SRU?
<ubottu> Launchpad bug 788514 in pyxdg (Debian) "python packages on the CDs not using dh_python2" [Unknown,New] https://launchpad.net/bugs/788514
<pitti> the whole SRU is rather strange..
<pitti> I left a comment in the FFE, and it has some details
<slangasek> which bug is the FFe?
<pitti> bug 872374
<ubottu> Launchpad bug 872374 in onboard (Ubuntu) "Oneiric-proposed: new version of Onboard with GI, gsettings,..." [High,New] https://launchpad.net/bugs/872374
<slangasek> pitti: ah... makes sense I guess
<slangasek> and anyway, it's had enough eyes on it by now ;)
<slangasek> actually, it looks like 788514 shouldn't have been listed in the changelog at all
<slangasek> will be interesting to see if this SRU successfully passes verification, I guess
<pitti> yeah, I'd like to get some feedback from actual onboard users there, not just a cursory "it still starts" kind of thing
<TheMuso> I'll make sure the word gets out the community at large. I certainly wouldn't have uploaded it if Kate hadn't put a provisional stamp on it.
<micahg> any tips on -Werror=format-security errors?
<micahg> seems to be new in precise
<slangasek> micahg: insert a "%s" in front of whatever string variable you're currently passing
<pitti> micahg: doko and cjwatson discussed it yesterday, and it seems it was a not-quite-intended effect of the merge
<pitti> ... dpkg merge
<pitti> while it's certainly a great thing to have, it makes tons of universe packages FTBFS, so I think they wanted to back it out again
<micahg> pitti: so, should I wait rather than fix?
<micahg> slangasek: would this be something to upstream, at least to Debian?
<pitti> micahg: well, fixing format string errors is always good :)
<pitti> micahg: yes, definitively something for upstream
<slangasek> yes
<pitti> we wanted to back it out not because the warnings are bad, but because it'd introduce too much universe FTBFS just yet
<micahg> ok, will give it a shot then
<micahg> the package I'm fixing ATM is in main (directfb)
<pitti> the usual case is something like printf(var) or printf(_("hello %s"))
<pitti> sorry, second without the %s
<micahg> wanted to get the libjpeg changed and got more than I bargained for :)
<pitti> i.e . if a translator translates "hello" as "foo %s" etc, you get crashes
<slangasek> I "upstreamed" unixodbc fixes to myself for this already; they were false positives in that the strings aren't user controllable, but all the same
<slangasek> s/crashes/exploits/
<Chipzz> pitti: I wonder how much such a thing really happens though. And I wonder /if/ such a thing happens, bad intentions weren't involved in the first place?
<pitti> Chipzz: certainly not bad intentions in most cases
<pitti> and we did have crashes due to bad format strings, it's not just a theoretical issue
<slangasek> yes, it happens due to bad tooling, not bad intentions
<micahg> something like this seems like a false positive: snprintf( ret_desc->name,   DFB_GRAPHICS_DEVICE_DESC_NAME_LENGTH, device_info.name );
<slangasek> micahg: are you sure device_info.name can never contain a format string?
<slangasek> better safe than sorry
<RAOF> There's no special attention needed when merging packages which now use dpkg-buildflags to get hardening flags, is there?  That'll just work for us, too?
<micahg> RAOF: that's what I was told
<slangasek> RAOF: correct
<micahg> got it, those format string errors weren't so bad...
* micahg changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cnd
 * micahg wonders if cnd is still piloting...
<dholbach> good morning
<didrocks> micahg: I guess he is forever! :-)
<didrocks> hey dholbach
<dholbach> salut didrocks
<slangasek> jamespage: is libslf4j-java on your radar already for MIRs?  mysql-connector-java also wants it; if libslf4j-java goes to main (along with ant-contrib, which I see the MIR for), we can make that a sync
<jamespage> slangasek, its not but I can add it to the list
<jamespage> ant-contrib has already been in main so should not be an issue
 * slangasek nods
<slangasek> libslf4j-java is wanted by libmaven2-core-java... I guess that means we probably need it?
<jamespage> slangasek, I'm working on removing the maven parts in component mismatches at the moment
<slangasek> ok, I'll go ahead and sync this then, and assume the rest will shake out on its own - thanks :)
<jamespage> slangasek: should be fine libslf4j-java was in main until oneiric anyway
<slangasek> ah, ok
<cjwatson> slangasek: we use wget-udeb in eucalyptus-udeb and system-integrity-check; it was originally introduced for the latter, I think on the grounds that it had HTTPS support, although system-integrity-check doesn't seem to use that facility
<cjwatson> slangasek: in the case of eucalyptus-udeb we use wget-udeb because the CLC only speaks HTTPS
<cjwatson> slangasek: perhaps the udeb could straightforwardly be a separate build pass without libidn support?
<micahg> hi Mirv, thanks for the update on the libvoikko issue, I'll should be able to take care of it later today
<micahg> which reminds me, pitti, Bug #832582 is a regression caused by a firefox security upgrade in another package (libvoikko), would you like it to sit in -proposed for a week before pushing to -updates/-security or is me running through the test case sufficient?
<ubottu> Launchpad bug 832582 in libvoikko (Ubuntu Natty) "mozvoikko makes Firefox 6 crash" [Medium,In progress] https://launchpad.net/bugs/832582
<pitti> micahg: I'm fine with moving to -updates as soon as it's verified
<apw> cjwatson, i have been musing about how hard it is to switch to a verbose debug boot, as the construction of the command line etc includes variables i am wondering if we could have a separate menu entry in the top level grub2 menu which would toggle the type of boot "Option: Verbose" and that could set variables to flip the boot style
<micahg> pitti: thanks
<micahg> pitti: I'm going to build it in the Mozilla Security PPA since it needs to go to -security, do you want it copied through proposed at all?
<pitti> micahg: ah, security route WFM
<pitti> micahg: in fact, better to have in -security, as people who only have -seurity, but not -updates should still get it
<micahg> pitti: exactly, thanks
<cjwatson> apw: it starts getting unwieldy; really once we start having toggleable options I think we want to be doing something involving gfxmenu
<apw> cjwatson, sounds like a beermat conversation at UDS level problem to me
 * cjwatson uploads coreutils.  what could possibly go wrong
<nigelb> Famous last words? :P
<cjwatson> this is why I'm doing it at the start of a day not the dend
<cjwatson> end
<Mirv> micahg: ok, thank you for the information!
<nigelb> heh, good idea :)
<nigelb> You lose a day and not a night of sleep.
<nigelb> Speaking of sleep.... haven't seen infinity around since the release.
<cjwatson> nigelb: everyone's entitled to the odd holiday
<nigelb> cjwatson: Ah! :)
<apw> crazy notion ... noone is allowed to sleep let alone have time _off_
<lynxman> apw: I'm all for that, clockwork orange style
<doko_> pitti, seb128: could somebody from the desktop team take over the gamin merge?
<pitti> doko_: yes, can do
<cjwatson> doko_: could you merge hdf5 (or I'll do it if you prefer)?  switching that to libjpeg-dev via the merge will fix several build failures
<doko_> cjwatson, will do
<cjwatson> ta
<OdyX> pitti, tkamppeter: FYI, http://wiki.debian.org/Teams/Printing/RethinkingTheStack#Action_1_-_Rename_printing_driver_packages
<cjwatson> tkamppeter: BTW, the cups installability problem from yesterday should be resolved; I gave back all the failed builds, I think
<OdyX> cyphermox: did you get my "RFC: usb-modeswitch *" mail (that is To: debian-devel) ? I'd like to have your input on that. (or slangasek's fwiw).
<cyphermox> hadn't seen it no, looking now
<cyphermox> I rather 5, but that's because I've already been spending lots of time on that; I do need to bug upstream to include it in the tarball though, after making sure it's in sync with the current tcl stuff
<ximion> hi! does someone know why all recipe-builds on LP fail with this error:
<ximion> dh clean --parallel --with python2
<ximion> make: dh: Command not found
<ximion> This happens now for three days, is it just me or is there something wrong for everyone?
<geser> missing debhelper in Build-Depends?
<OdyX> cyphermox: I would have guessed so. :-)
<OdyX> cyphermox: what about 2 ? What would be the impact on the first CD ?
<OdyX> (jimtcl's package being currently 464k, before me stripping most of it out.)
<cyphermox> OdyX: embedding doesn't sound like such a bad idea to get to a standalone binary; but it won't be possible to know that it needs a rebuild when jimtcl changes (if separate), since it won't show up in nbs and stuff
<OdyX> cyphermox: embedding is nice at first sight as it "converts" the tcl script into a standalone binary, but it's clumsy. From the distribution point of view, it's hard to justify to do static-linking where everywhere else we do dynamic, especially for a script under /usr.
<cyphermox> right
<cyphermox> OdyX: well, 240k on the CD isn't huge but CD size is always a major concern; if we have to I guess it can be done. that said...
<cyphermox> OdyX: ... it doesn't cover the second case that we'll again have a tcl interpreter getting loaded at boot time, which was another reason why usb-modeswitch-dispatcher was rewritten
<OdyX> cyphermox: we could even consider a "jimsh-tiny" that has only what usb-modeswitch needs.
<OdyX> cyphermox: ah right. Could you maybe explain that in a mail answering mine to debian-devel ?
<cyphermox> OdyX: otoh, how is the jimsh that usb-modeswitch ships?
<cyphermox> I mean, is it very big?
<OdyX> cyphermox: as far as I can see, it's a libjim.a of 316K
<cyphermox> OdyX: ok
<OdyX> cyphermox: when compressed into usb_modeswitch_dispatcher, the remaining binary is 188k
<cyphermox> I wish Josua would be so kind as to ship both and allow for which version to be chosen at build time :)
<OdyX> cyphermox: well, as I always said (I think), if the (your) C program is included upstream, I consider that "upstream" and will use that; problem solved.
<cyphermox> right
<cyphermox> working on it, I just sent another email to him :)
<OdyX> nice .
<pitti> doko_, seb128: committed our gamin chagnes to Debian, uploaded, synced
<seb128> pitti, thanks
<tkamppeter> cjwatson, thanks, I have already seens it.
<doko_> lucas, what's the status of ruby1.9? should we get it into main for precise?
<lucas> doko_: the target for finishing the migration to gem2deb is the freeze date for wheezy
<lucas> doko_: doing it for the freeze date for precise might be difficult
<lucas> doko_: burndown chart: http://pkg-ruby-extras.alioth.debian.org/wheezy/
<lucas> doko_: unless we get help from the ubuntu side, of course :P
<kelemengabor> mvo: hi, could you take a look at bug #873905 ? The proposed update-manager package seems to contain a high impact translation regression.
<ubottu> Launchpad bug 873905 in update-manager (Ubuntu Precise) "Update-manager not using current translations during upgrade" [High,In progress] https://launchpad.net/bugs/873905
<mvo> kelemengabor: sure
<kelemengabor> thanks!
<doko_> lucas, just wondering if we should get ruby1.9 into main then (to build 1.9 extensions) ... and keeping 1.8 as the default
<doko_> cjwatson, ^^^
<cjwatson> I'm OK with that, presumably it's not on CDs
<Riri> New development site
<Riri> http://goo.gl/lBJYo
<Riri> http://goo.gl/lBJYo
<doko_> jdstrand, are you ok having ruby1.9 in main (in addition to 1.8)? ^^^
<jdstrand> whoa
<jdstrand> no way
<jdstrand> unless things have changed a lot recently
<jdstrand> aiui, 1.9 was basically a test bed is and constantly changing
<jdstrand> very, very hard to support
<doko_> jdstrand, see lucas plan above
<jdstrand> if it has stabilized, then maybe
<lucas> doko_: ah, then you probably have to include it in main given that gem2deb depends on both
<doko_> jdstrand, please lets sort it out this week. so we don't merge packages, removing ruby1.9 support
<jdstrand> lucas: has 1.9 stabilized?
<jdstrand> lucas: keep in mind, my recollection may be quite old...
<lucas> jdstrand: yes
<lucas> jdstrand: in debian, we are considering switching to 1.9 as default for wheezy
<jdstrand> so we are actually talking about ruby1.9.1
<jdstrand> the problem is that supporting 2 rubies for 5 years is suboptimal
<doko_> jdstrand, but iiuc, we would have to patch a lot of packages for precise, if we do not?
<slangasek> cjwatson: yep, looks like a separate no-libidn pass is the way to go
<jdstrand> doko_: I don't know, I just now am coming up to speed
<jdstrand> doko_: on the other hand, it looks like 1.8.7 will only get upstream support unitl June 2013
<jdstrand> http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
<jdstrand> so upstream is recommending 1.9
<doko_> jdstrand, right, but iiuc, gem2deb will build for both (and we'll have to have both in main), unless we commit to convert to 1.9, going ahead of Debian
<jdstrand> looking at upstream and lucas' comments, I think ruby1.9.1 in main would be fine. I wonder if we can demote ruby1.8...
<doko_> cjwatson, do you fix libgd2?
<jdstrand> doko_: it might be worth helping them, as we will be stuck with 4 years of 1.8.7 support without upstream. last I looked at the codebases, they were radically different
<jdstrand> again, that was a couple of years ago
<doko_> lucas, do you stick to 1.9.1, or will there be minor updates?
<jdstrand> well, that is jsut the package name
<lucas> doko_: see package description:
<lucas>  .
<lucas>  In the name of this package, `1.9.1' indicates the Ruby library
<lucas>  compatibility version. This package currently provides the `1.9.3'
<lucas>  branch of Ruby, which is compatible with the `1.9.1' branch.
<jdstrand> the actual upstream version is 1.9.3~rc1-1
<doko_> ahh, ok
<lucas> we are very likely to stick with 1.9.3 in wheezy, yes
<jdstrand> I'm guessing that is because of the early 1.9 prerelease snapshots
<lucas> there will be a few, bugfix-only updates
<lucas> the stable branches of ruby tend to be maintained quite reasonably
<jdstrand> that is consistent with my experience. last I looked at ruby1.9 (the source package) it had not yet stabilized
<jdstrand> hence the initial reaction :)
<jdstrand> doko_: we would probably want Daviey to weigh in on ruby1.8 demotion or ruby1.9 by default
<hallyn> tyhicks, do you want to create a blueprint for ecryptfs?
<kirkland> hallyn: i think he has one
<hallyn> oh lemme search harder
<tyhicks> hallyn: https://blueprints.launchpad.net/ubuntu/+spec/security-p-ecryptfs
<hallyn> cool, thx
<tyhicks> hallyn: np - let me know if you have other ideas we need to discuss
<mvo> kelemengabor: its uploaded now, thanks again for the quick notification !
<kelemengabor> yw :)
<hallyn> tyhicks, nope, testing is on there, i'm good :)
<doko_> jdstrand, Daviey sounds find, but lets sort out it this week
<tyhicks> hallyn: despite it being at the bottom, it is one of the top items to discuss
<hallyn> tyhicks, hopefully i'll be disciplined enough to review the emails from this cycle about it beforehand
<cjwatson> doko_: I already did
<doko_> cjwatson, ahh, I see. binaries not yet avail
<cjwatson> doko_: should just have published but maybe not yet mirrored, except for powerpc which was stuck behind firefox/thunderbird builds last I looked
<cjwatson> oh, powerpc has built too, so should be available in ~1hr
 * cjwatson retries libgd-gd2-perl for giggles
<pitti> oh, someone flushed the precise-changes@ queue?
<cjwatson> we've been asking IS about that, maybe somebody processed it
<cnd> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cnd> micahg, thanks :)
<didrocks> cnd: what a commitment, a full day of piloting! :)
<cnd> hah
<ricotz> hello, is this a known debhelper problem "dpkg-shlibdeps: error: package. is not a valid version" on precise?
<cjwatson> ricotz: if it is it is certainly not affecting all packages
<cjwatson> ricotz: sounds more like a broken shlibs file to me
<cjwatson> ricotz: I noticed that in cogl - is that what you're looking at?
<ricotz> cjwatson, yes, and a custom cairo packages which uses a splitted symbols file too
<cjwatson> ricotz: so I think this is probably junk in the shlibs file and that that would be a good place to start investigating; I can't reproduce this with a cogl/i386 build in pbuilder
<cjwatson> ICBW of course but it doesn't look like a general debhelper problem at this point, to me
<ricotz> https://launchpadlibrarian.net/82920262/buildlog_ubuntu-precise-amd64.cairo_1.11.3%2Bgit20111015.3813066f-0ubuntu1~12.04~ricotz0_FAILEDTOBUILD.txt.gz
<ricotz> i havent built it locally yet, but this failed on i386 and amd64
<cjwatson> ok, so build locally and then peer at the shlibs files; maybe also run with DH_VERBOSE=1
<ricotz> cjwatson, alright, will do, thanks
<Daviey> doko_ / jdstrand: I don't have a weighted opinion either way TBH (RE: ruby)
<superm1> mvo, got some logs for the lightdm upgrade problem that keeps happening https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/876945
<ubottu> Ubuntu bug 876945 in update-manager (Ubuntu) "Upgrade didn't properly set-up lightdm" [Undecided,Confirmed]
<brendand> eh, why has unity stopped working after the most recent updates?
<seb128> did it?
<seb128> what is your .xsession-errors?
<brendand> /usr/lib/nux/unity_support_test: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<brendand> looks suspicious
<mvo> thanks superm1, I'm not sure I will manage tonight, but I put it on my list for tomorrow
<brendand> unity-2d-panel: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<brendand> seb128: also, though i've been trying both 3d and 2d
<seb128> brendand, seems your libGL is screwed, do you use binary drivers?
<seb128> brendand, dpkg -S libGL.so.1
<brendand> seb128 - ah. i activated fglrx and then deactivated it.
<superm1> thanks mvo
<seb128> brendand, seems like it let you libGL alternative broken or something
<slangasek> brendand: please file a bug against fglrx-installer then; it's not supposed to ever leave libGL.so.1 broken like that
<mvo> thank you superm1
<brendand> seb128 - actually i deactivated it because my display wouldn't come back after suspend with it activated. i'll file the bug
<seb128> brendand, did you use jockey to enable,disable it?
<seb128> slangasek, bregma: bug #855943
<ubottu> Launchpad bug 855943 in fglrx-installer (Ubuntu) "Installing then uninstalling FGLRX makes Oneiric's Unity unbootable" [Undecided,Confirmed] https://launchpad.net/bugs/855943
<seb128> "known", I pointed it to tseliot before Oneiric released
<seb128> but maybe it should get milestoned or assigned to somebody
<maco> stgraber: http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2011-October/006721.html this was debian response to that
<slangasek> seb128: yes, that surely should be a higher priority than 'undecided' :/
<slangasek> seb128: triaged, thanks
<seb128> slangasek, thanks
<dobey> is there any policy documentation on how to split up gir1.2-foo packages from a single source? don't recall seeing anything in deb policy manual
<luist> hey im getting this problem: http://pastie.org/2718936 on my chroot. im following this: https://help.ubuntu.com/community/LiveCDCustomizationFromScratch is that really a problem?
<ricotz> cjwatson, this debhelper problem is caused by "/var/lib/dpkg/info/libegl1-mesa:amd64.symbols", so it seems like debhelper changed its behaviour here
<ricotz> libEGL.so.1 libegl1-mesa #MINVER# | libegl1-x11
<ricotz>  # package.
<ricotz>  _eglBindContext@Base 7.8.1
<slangasek> no, debhelper doesn't interact with symbols files
<slangasek> dpkg-shlibdeps / dpkg-gensymbols do all the work
<ricotz> slangasek, ok, it looks like the "old" one left this comment part in the symbols file which looks like
<ricotz> +libEGL.so.1 libegl1-mesa #MINVER# | libegl1-x11
<ricotz> + # These are all internal symbols between libEGL and the
<ricotz> + # drivers.  Handle the dependency explicitly in the driver
<ricotz> + # package.
<ricotz> + (regex)"^_egl.*@Base$" 7.8.1
<slangasek> so it looks like a dpkg-shlibdeps behavior change; I can confirm that comment was present in /var/lib/dpkg/info/libegl1-mesa:amd64.symbols in oneiric, and we didn't have the build failure there
<slangasek> is rebuilding libegl1 enough to fix the broken comment?
<ricotz> slangasek, havent checked, i was looking at the cogl and my cairo failures which leads to this
<cjwatson> I'm failing to find any relevant changes in dpkg
<cjwatson> it seems to think comments must start at the beginning of a line ("#" not " #") in both oneiric and precise
<slangasek> looks like it might be a difference in the packages actually being pulled in as build-dependencies?
<slangasek> building cogl in oneiric doesn't use libegl1-mesa
<ricotz> cjwatson, looks like it, but why are two lines stripped and one left in?
<slangasek> so maybe libegl1-mesa is busted in oneiric but nothing uses it
<ricotz> slangasek, the armel build does
<slangasek> oh, that's going to be actual work to test
<slangasek> alright
<slangasek> go go gadget cross-compiler
<ricotz> slangasek, you can try this too https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2004607/+listing-archive-extra
<ricotz> which uses libegl on all archs
<cjwatson> ricotz: I haven't parsed my way all the way through this code, but perhaps the shorter line with only one word in the comment looks enough like a legitimate symbol line that dpkg's parser retains it
<ricotz> and went fine on oneiric
<ricotz> cjwatson, could be, the other lines have more spaces
<slangasek> pfffff, can't cross-compile cogl because of gir
<slangasek> ok
<zul> slangasek: is there a reason why we cant have samba 3.6.0 for percise
<ricotz> slangasek, mesa build fails too on precise
<slangasek> zul: I don't know; currently it's only in experimental, please don't merge it from there as the packaging is not current wrt various improvements in unstable
<zul> slangasek: k
<slangasek> zul: as for whether it's ready for prime time and should be included in precise, I can't say - I suggest posting to the mailing list (pkg-samba-maint@lists.alioth.debian.org) to find out what bubulle's planned timeline is for unstable
<ricotz> slangasek, cjwatson so this is parsed as valid entry instead of being ignored
<zul> slangasek: k i will
<cjwatson> ricotz: regardless of parser bugs, the file is buggy
<cjwatson> the leading space before # should be dropped
<cjwatson> (though I can't say for sure that that will fix the bug)
<slangasek> kees: are you planning to take care of the merges that you're TIL on, or would you like me to find someone else to do them?
<ricotz> cjwatson, i already pinged RAOF and Sarvatt ^ and now again ;)
<slangasek> kees: oh, pam is one of them, I guess I know someone who could do that merge ;P
<slangasek> RAOF: say, what's the difference between a fake merge from experimental and a real one? (mesa)
<slangasek> ricotz: since I have Debian XSF commit rights, I'll go ahead and commit the fix now to the Debian git
<ricotz> slangasek, ok
<cjwatson> slangasek: it does occur that the parser bug might misfire even without the leading space, so still worth testing ...
<slangasek> cjwatson: yep, will do
<kees> slangasek: please feel free to find other folks if I'm blocking. I probably won't have time for merges for a few weeks
<slangasek> kees: ack - I don't know that anything's blocked currently, but I'd rather we not let things like sudo linger until FF :)
<kees> hehe
<slangasek> cjwatson: what do you think about changing MoM to spit out UNRELEASED as a changelog target instead of the current devel dist?
<slangasek> cjwatson, ricotz: confirmed that egl1-using cairo package builds fine on oneiric in spite of this broken .symbols file comment, so something certainly seems to have changed in dpkg
 * SpamapS got his askubuntu T-shirt today. :-D
<SpamapS> jcastro: ^^ :-D
<jcastro> Not me. :(
<cjwatson> slangasek: makes sense; done (at least for future merges)
<SpamapS> jcastro: sent priority mail, so may be stuck somewhere :p
<slangasek> cjwatson: cool, thanks :)
<ricotz> cjwatson, oh, did you fix it? where?
<cjwatson> ricotz: no.  there were two overlapping conversations heree.
<cjwatson> *here
<ricotz> ah, i see
<c2tarun> hi, my system froze few minutes ago, I have to power reboot, is there any way to know the reason by viewing log files/
<cjwatson> I think on the whole working on a library transition with a half-day build queue is too frustrating and I should do something else for a while instead
<highvoltage> I suggest some ice-cream, cjwatson.
<cjwatson> ... but icecream isn't involved in this library transition - no, wait
<nigelb> I as about to suggest alcohol, but I see the irony in suggesting icecream :)
<stgraber> slangasek: for that ifupdown bug, I confirmed that it's a regression in the 0.7 series (reproduced on Debian using unstable and then installing the latest ifupdown from experimental). I'll file a bug and then see if I can maybe figure out the fix (I tend to get lost in ifupdown's code...)
<slangasek> stgraber: oh, you found ifupdown's code to get lost in, did you ;)
<slangasek> would love to see ifupdown rewritten in straight C someday
<slangasek> cjwatson, ricotz: confirmed that installing dpkg-dev+libdpkg-perl from precise is enough to trigger this build failure with oneiric packages... so wherever that behavior change is, it's in dpkg somewhere
<LoRez> where would I go to find a contractor to package something?
<ScottK> Here is not a bad place perhaps.
<LoRez> I need ftp://ftp.comtrol.com/dev_mstr/rts/drivers/linux/devicemaster-linux-4.22.tar.gz packaged up.  It's a kernel module and utilities.
<LoRez> preferably for lucid
<micahg> are there any plans for xz debs on images for P?
<slangasek> what plans do you have in mind?  I believe we already went through several cycles ago and changed the compression type for all the low-hanging fruit
<micahg> slangasek: oh?  I thought there were issues w/it for the live fs  I was thinking Firefox/Chromium since they're huge
<slangasek> there are issues in that compressing .debs has no impact whatsoever on livefs size
<cjwatson> micahg: you're welcome to use it for individual debs, as long as you Pre-Depends: dpkg (>= 1.15.6)
<cjwatson> but as slangasek says, it won't affect the livefs
<micahg> cjwatson: ok, it might be worthwhile for bandwidth issues though since we update these often, I'll make the changes if there are no objections. what about in a stable release?  would this be something we could switch safely
<cjwatson> I can't advise making non-required changes in stable releases
<micahg> ok, will ask pitti about it later
<cjwatson> I mean that's a no vote (though not a veto) from me, not "no opinion"
<cjwatson> it's definitely not possible for lucid
<cjwatson> it didn't have a new enough dpkg
<micahg> ah, ok, will discuss amongst my team then, yeah, not for lucid, but for everything later, I can at least do it for Precise though
<cjwatson> yes
<cjwatson> after precise we'll be able to drop the Pre-Depends
 * micahg doesn't mind the Pre-Depends, these are Ubuntu only anyways
<cjwatson> Unable to obtain lock  held by cjwatson@bazaar.launchpad.net on crowberry (process #20203), acquired 4041 hours, 14 minutes ago.
<cjwatson> that might not be current any more
<StevenK> cjwatson: bzr break-lock ?
<cjwatson> yes I know
<cjwatson> I just found the length of time amusing
<StevenK> Hah, yes.
<cjwatson> pretty much exactly a release cycle :)
<slangasek> hah
<penguin42> can a qt person look at bug 877791 please - multiple qt apps crashing under unity and someone has attached a one line fix; if the fix is right it would seem appropriate for an update (appmenu-qt)
<ubottu> Launchpad bug 877791 in appmenu-qt (Ubuntu) "appmenu crashes on AppMenuPlatformMenuBar::setAltPressed" [Medium,Confirmed] https://launchpad.net/bugs/877791
<SpamapS> pitti: when you're around.. I think its about time we wave bug 665185 through to lucid-updates. It hsa been in -proposed a long time, and was allowed in without a TEST CASE...
<ubottu> Launchpad bug 665185 in sysvinit (Ubuntu Lucid) "/etc/init.d/sendsigs fails to kill some processes" [High,Fix committed] https://launchpad.net/bugs/665185
<SpamapS> pitti: since its effectively a race condition that it is testing.. I think we should allow it through.. simple patch.. clearly needed to help keep peoples' data safe.
#ubuntu-devel 2011-10-19
<mwhudson> who can i chase to get a fix for this bug SRUed? https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/877883
<ubottu> Ubuntu bug 877883 in offlineimap (Ubuntu) "offlineimap occasionally deletes mail it has previously downloaded" [Undecided,New]
<mwhudson> it's a bit exciting
<RAOF> Mmm.  I'm all about deleting people's main!
<RAOF> s/main/mail/gc
<mwhudson> heh
<ajmitch> it's all about inbox zero these days
<RAOF> Bah.  There's a lot of *entirely unrelated* change there :/
<RAOF> Stupid embedding of libs.
<mwhudson> i guess it might be possible to dig out the relevant fix to imaplib2
<RAOF> Yeah.  It's probably not a huge change.
<mwhudson> can't find it though :/
<mwhudson> going by timestamps it must be one around here
<mwhudson> http://imaplib2.git.sourceforge.net/git/gitweb.cgi?p=imaplib2/imaplib2;a=commit;h=187658d4f11ecbadcab8244dba732aff5caba48b
<mwhudson> but there are no tags in the repo (unless i fail at git)
<mwhudson> so i don't know which commit corresponds to 2.24
<pitti> Good morning
<pitti> micahg: you'll need a condition for this in debian/rules anyway, so I'd advise to only switch it on for precise an dup
<pitti> "and up"
<micahg> pitti: ok, will do
<pitti> SpamapS: release to maverick-updates you mean?
<pitti> sure
<SpamapS> pitti: yes I do mean maverick-updates. :)
<slangasek> SpamapS: bug #811823> blast, I was too slow; based on Steve Atwell's last comment, I was going to push a fix for the other race condition he pointed out...
<ubottu> Launchpad bug 811823 in nfs-utils (Ubuntu Maverick) "idmapd upstart job ends in an inconsistent state if /usr is a separate partition" [Medium,Fix committed] https://launchpad.net/bugs/811823
<slangasek> guess I'll do it as a follow-on SRU
<SpamapS> slangasek: heh, sorry, its been waiting so, so long.
<slangasek> SpamapS: I see though that you've only pushed for natty, but have marked it 'verification-done' for all?
<SpamapS> slangasek: if done and needed are there, that means "pay attention SRU team, some things are not done"
<didrocks> good morning
<SpamapS> slangasek: and I'm holding off on lucid to see if we get maverick verified. Its such a shame when upgrades cause regressions. :-/
<SpamapS> my guess is that we won't though
<SpamapS> the list of unverified SRU's for maverick is quite long
<slangasek> SpamapS: hmm.  when it's been verified already for both lucid and natty, I would argue that it should also be pushed to maverick on that basis.
<slangasek> or if not, it should at least be pushed to lucid, as there aren't likely to be many users upgrading from lucid to maverick now - but there are still plenty of people using lucid
<SpamapS> slangasek: agreed, and done. ;) this will henceforth be known as the Langasek Release Sandwich Policy
<slangasek> mmm
<slangasek> just the right amount of mustard
<SpamapS> And paprika
<broder> SpamapS: haha, so that's the trick to getting rid of it? i'm still working through the tiny souvenir bags i picked up in Budapest :)
<dholbach> good morning
<vin__> qualcuno sa come configurare thunderbird con exchange?
<sroecker> hi, are you guys using unity2d? i am trying to debug why i only have 1 workspace
 * ogra_ has 4 with a default install 
<sroecker> yes, when i use unity i got 4. unity2d only shows me 1
<ogra_> even with ctral-alt and the left/right cursor key ?
<sroecker> yes
<geser> I had to change the number of workspaces to get more than 1 (unity-2d), I don't remember if I had in natty more then 1 or not (I upgraded from natty to oneiric)
<ogra_> if you can run unity 3d there the 2d version might use compiz instead of metacity
<ogra_> i clearly run metacity here on my non GL capable device
<ogra_> and get proper 4 workspaces
<sroecker> looks like metacity
<sroecker> ah, thats why trying to configure compiz with ccsm doesn't change anything
<chihchun> it seems code.launchpad.net does not sync changes for precise yet?
<chihchun> there are some new packages in precise, but the code is not sync in lp:/ubuntu/package
<sroecker> ogra_: thx, metacity num_workspaces was set to 1. although i am sure i had 4 before the upgrade to oneiric
<ogra_> yeah, thats weird, i still have four here
<ogra_> (not that i would ever need more than one)
<chihchun> the latest version of gtg is https://launchpad.net/ubuntu/precise/+source/gtg/0.2.4-6, but the code is still 0.2.4.5 https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/gtg/precise
<elleuca> seb128, do you know why gnome-terminal 3.0.x is available in oneiric, instead 3.2.x?
<seb128> elleuca, no
<seb128> elleuca, it's likely because the first vte 0.29 tarball was 08-28
<seb128> i.e way after feature freeze etc
<elleuca> seb128, oh yes, I forgot about vte dependence
<chrisccoulson> sroecker, have you used gnome-shell at all?
<sroecker> chrisccoulson: yes, i tried it once
<chrisccoulson> i find that the number of workspaces is reset to 1 after i use gnome-shell
<chrisccoulson> every time
<sroecker> ah
<seb128> chrisccoulson, it's a design decision
<seb128> you always start at 1 and add them dynamically
<chrisccoulson> seb128, ah. it's a bit of a pain that it interferes with the unity-2d session :(
<chrisccoulson> i alternate between them a fair bit
<ogra_> bah, oneiric makes debian crash !
<ogra_> http://people.canonical.com/~ogra/debian-crashing.png
<seb128> chrisccoulson, get a script settings the few keys it reset on unity-2d start ;-)
<chrisccoulson> seb128, won't that slow my login down? ;)
<chrisccoulson> (which is pretty fast in 2d)
<chrisccoulson> perhaps i should just stick to using one desktop shell
<sroecker> ogra_: whats that irc client? looks nice
<ogra_> sroecker, xchat
<sroecker> ogra_: vanilla or gnome?
<ogra_> vanilla
<ogra_> with indeed the defaults adjusted a bit (userlist and channel list on the right, some color defaults changed etc, nothing big though)
<Judge> Hi there. We need support for advanced GD features in PHP like imagerotate() for example. In LP: #74647 there was a question about why this isn't supported in Ubuntu and it was answered with "won't fix".
<Judge> Therefor, we set up a PPA, changing the GD support to the bundled one, which supports these functions.
<Judge> Now, we updated PHP to the latest Repo-Version by accident on lucid and hardy and suddenly: This is working with the default packages !
<Judge> Can someone tell me when and why this has been changed and if this will be a permanent change this time?
<ajmitch> Judge: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321237 has the information about it - there were changes in php5 upstream in 5.3.x which added a compatibility layer
<ubottu> Debian bug 321237 in php5-gd "php5-gd: not using gd bundled with php5" [Wishlist,Fixed]
<Judge> ubottu / ajmitch : Great! That makes it clear for Lucid / PHP5.3 - What's the matter with Hardy / PHP5.2 ?
<ubottu> Judge: I am only a bot, please don't think I'm intelligent :)
<Judge> LOL
<ajmitch> Judge: afaik, it's just a general issue around avoiding bundled libs
<Judge> ajmitch: That's right.
<Judge> But somehow, it seems to work now.
 * ajmitch doesn't know how, unless you're still getting your self-compiled php5 loaded
<Judge> However: Thank you for your help :)
<cjwatson> Daviey: can you deal with the xmlrpc-c merge?
<cjwatson> (I forget whether I asked already)
<Daviey> cjwatson: you have not, and yes i will
<Daviey> (unless i missed it)
<cjwatson> great, thanks
<Daviey> Riddell: Hey, happen to remember why http://launchpadlibrarian.net/62034463/xmlrpc-c_1.16.32-0ubuntu2_1.16.32-0ubuntu3.diff.gz happend?
<Riddell> Daviey: hmm, no, although it feels like I should
<Daviey> Riddell: no worries, thanks
<Riddell> Daviey: must be related to cmake
<doko> lucas: any hint about bug 874306
<ubottu> Launchpad bug 874306 in ruby1.9.1 (Ubuntu) "package ruby1.9.1 1.9.2.290-2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/874306
<lucas> doko: yes, see ubuntu-devel@ on friday
<lucas> doko: ppa introduced alternatives in an incompatible way
<Laney> get the tools to report that a broken upgrade was from an unofficial package and advise purging it?
<doko> mvo: ^^^ can the upgrade tools figure this out? that would be indeed a big help
<doko> I agree that purging is the right solution
<fabiand> is csanchez around or does someone know where to find him? :)
<mvo> doko, lucas: sure, the upgrader can special case this and go it, i need the exact version of the incompatible pkg
<doko> hmm, I was more thinking about having a general solution. but I assume, you don't want to have a list of "official" package versions
<lucas> alternatively, ubuntu could carry a patch that adds a Conflicts or a Breaks with all the packages ever published on those PPAs
<lucas> (conflicts or breaks on the ruby1.{8,9.1} packages)
<doko> only if they get the alternatives removal right
<Laney> there is some way to tell if a package is official because apport does it
<hyperair> apt-cache policy?
<hyperair> check against a whitelisted bunch of mirrors?
<Laney> Origin:
<hallyn> didrocks, hey, just wondering, i noticed you had a newer version of gnome-keyring in oneiric-proposed, but not precise.  Is there a reason for that?
<hallyn> I'm looking at it because, with libvirt 0.9.6 (no idea why yet), it keeps spitting out annoying warnings about WARNING: unable to connect to socket
<didrocks> hallyn: we are in sync basically, so once the version in -proposed is validated and move to -updates, it's generally copied to precise
<Laney> i thought stuff is usually copied when it goes into proposed
<hallyn> heh, i thought it could only go into proposed after it's in precise :)  But, was just wondering, thanks.
<hallyn> does my 'WARNING:' problem ring any bells for you?
<hallyn> google searching brings up a few other people having that problem with other software.
<didrocks> hallyn: as long as we are in sync, it's not a big deal
<Laney> it they are equal then the proposed package can be copied to the next release
<didrocks> hallyn: I guess yo uhave perm issues
<hallyn> it only happens when you're not logged in on console
<didrocks> you*
<hallyn> so /tmp/whatever/pkcs11 doesn't exist
<hallyn> annoyingly, it also happens when I sudo, since root isn't then logged into X
<didrocks> hallyn: not sure about gnome-keyring and sudo, normally is export variables like GNOME_KEYRING_CONTROL=/tmp/keyring-* which is accessible only to your user
<doko> slangasek, your cron merge pulls in universe stuff. see bug 878155
<ubottu> Launchpad bug 878155 in libprelude (Ubuntu) "[MIR] cron pulls in b-d's from universe" [Undecided,New] https://launchpad.net/bugs/878155
<hallyn> right.  it's just, gnome-keyring shouldn't be spitting out warnings on console about it.  ok it was late last night, i'll see if i can find the offensive line, thx
<seb128> Laney, one issue is that it needs to be built on all archs to be copied
<seb128> Laney, so it can't be copied when accepted
<seb128> Laney, but yeah, it would be nice to have things copied over before the one week validation delay
<Laney> yeah, i thought that's what was done
<seb128> depends of the archive admins I think
<seb128> there was some discussion previous cycle about that but some were in disagreement with pocket copied from proposed iirc
<seb128> I don't remember the details though
<frafu> pitti: Concerning Onboard 0.96.0 and LP: #872374 . The Onboard developer already committed some small fixes. I now wonder what is better for the oneiric proposed procedure: should we wait for the procedure to get onboard 0.96.0 into oneiric to be terminated, or is it better to release 0.96.1 as soon as possible and add the corresponding debian package to the bug thread?
<pitti> frafu: if the current SRU makes it better, but not perfect yet, it can progress to -updates first; if there is any regression, we should push another -proposed version
<frafu> pitti: thanks for the reply; so, if I get it right: it is better to wait and see whether there is any regression before releasing 0.96.1; correct?
<pitti> frafu: the upstream release shouldn't need to block on the ubuntu SRU
<doko> hallyn, please see bug 878162
<ubottu> Launchpad bug 878162 in qemu-kvm (Ubuntu) "[MIR] qemu-kvm pulls packages from universe" [Undecided,New] https://launchpad.net/bugs/878162
<hallyn> doko, qemu-kvm-spice (which should be in universe) does, but qemu-kvm shouldnt...
<doko> hallyn, it's the build depends
<hallyn> sigh, i was assured that was ok :)
<hallyn> does that mean i must have a separate source pkg?
<doko> no, it's not
<doko> yes
<hallyn> ok, thanks.
<hallyn> i was goin gto merge 0.15 today anyway, so i'll do that and pull the -spice package out
<frafu> pitti: Ok. I will talk with the other Onboard developer about it and we can decide about the upstream release independently from the SRU, unless there is a regression. Thanks.
<cjwatson> Daviey: doesn't block this upload, but I wonder if perhaps libxmlrpc-core-c3-0-udeb should be renamed to libxmlrpc-core-c3-udeb in line with the deb variant
<Daviey> cjwatson: Yeah, probably right.. I'll raise a bug.. will handle that and it's rdepend soonly.
<Daviey> it's only a wishlist, right?  They isn't any impact?
<cjwatson> wishlist, yeah
<akgraner> Day 3 of Open Week just started - https://wiki.ubuntu.com/UbuntuOpenWeek
<Daviey> cjwatson: did you fire the amd64 rebuild?
<cjwatson> yeah
<cjwatson> I gave back everything I could find that had failed due to transient perl breakage
<Daviey> thanks muchly, i did fire it earlier.. and just went to check it, and saw it was built \o/
<pitti> cjwatson: ah, so it was you; thanks (wanted to give back bluez and saw that it was built already)
<pitti> I also pushed the powerpc build score, but firefox/linux are blocking it
<pitti> cjwatson: want me to temporarily set the powerpc ones on manual until perl is built/published?
<cjwatson> yeah, firefox looked stalled last I checked
<doko> Daviey, looked serverish, bug 878170
<ubottu> Launchpad bug 878170 in libnetfilter-conntrack (Ubuntu) "[MIR] new b-d's of dnsmasq" [High,Confirmed] https://launchpad.net/bugs/878170
<cjwatson> pitti: no, it was only a problem because amd64 built before perl, AFAIK
<cjwatson> pitti: err ... because amd64 built before i386
<Daviey> doko: yeah, i raised a bug and assigned it to the person that did the sync :)
<pitti> ah, ok
<Daviey> doko: marking as a dupe of bug 875818.
<ubottu> Launchpad bug 875818 in dnsmasq (Ubuntu) "dnsmasq sync introduced new non-main depends, causing dep-wait" [High,Confirmed] https://launchpad.net/bugs/875818
<cjwatson> i386 has built now so I don't think it should repeat for other architectures; I haven't noticed a similar pattern of failurebombing from armel
<doko> Daviey, thanks, subscribed ubuntu-mir to let this show up in our list
<Daviey> doko: do we have a richer c-m tracking list?
<Daviey> I've got http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html , but i'd rather someone was in the main page
<hallyn> zul: didrocks: I needed http://people.canonical.com/~serge/gnome-keyring-warning.debdiff pushed on gnome-keyring for libvirt to shut up.  zul, do you know why gnome-keyring is being used by libvirt 0.9.6 at all?
<hallyn> (I'm hoping that will allow the qa-regression-tests to succeed :)
<zul> hallyn: no idea
<didrocks> hallyn: well, not sure that commenting warning is a nice way to make things work :)
<hallyn> didrocks: but that warning is not helpful.  it gives no indication who is trying to open what socket or why, and strace doesn't help either.  I suppose you could find it under gdb...
<hallyn> in a program it'd be fine i suppose, but this is a library.
<didrocks> hallyn: yeah, deubbing under gdb, maybe it worthes rather discussing with gnome-keyring people?
<tjaalton> forgot about bug 838091 until now, is the proposed fix doable?
<ubottu> Launchpad bug 838091 in ntfs-3g (Ubuntu Precise) "should link fsck.ntfs -> ntfsfix/ntfsck" [Undecided,Confirmed] https://launchpad.net/bugs/838091
<didrocks> would be better to know why and how you get this warning in your condition
<hallyn> didrocks: yeah definately we need to bring it up.  I was just showing waht I needed :)
<hallyn> didrocks, the reason I get it is clear;
<hallyn> gnome-keyring lib wants to talk to gnome-keyring, but i'm not logged into gnome, so it can't
<Daviey> hallyn: do you know why spice is being pulled into main?
<cjwatson> Daviey: I think bug 878180 is a NEW blocker though
<ubottu> Launchpad bug 878180 in xmlrpc-c (Ubuntu) "missing Breaks/Replaces" [Undecided,New] https://launchpad.net/bugs/878180
<hallyn> Daviey, bc you told me I could put a binary package depending on universe packages in with a source pkg in main :)
<didrocks> hallyn: the right fix will then be to ensure you have libvirt only using gnome-keyring if you are under a GNOME session
<hallyn> Daviey, I will merge qemu 0.15 today and drop qemu-kvm-spice into its own source pkg
<Daviey> hallyn: did i?
<hallyn> zul, I trust you'll look into dropping gnome-keyring from libvirt libs?
<cjwatson> hallyn: you can if that binary package is itself destined for universe
<hallyn> I can't see why it's using it
<hallyn> cjwatson, the binary package is
<tjaalton> basically, if you have old ntfs mounts in /etc/fstab, the bootup process will complain about "serious problems"
<cjwatson> hallyn: evidently not ...
<hallyn> but the universe libraries are in build-depends for the src package
<cjwatson> hallyn: ah, well, that will indeed cause those libraries to be pulled into main
<hallyn> right
<cjwatson> main must be transitively closed under Build-Depends+Depends+Recommends
<cjwatson> and all source packages that deliver binary packages in main must be in main, but not vice versa
<soren> Any ideas why reportbug can't seem to contact Debian's BTS?
<Laney> is it a package with a lot of bugs?
<soren> wnpp :)
<Laney> sometimes times out
<Laney> reportbug -b if you don't need the query
<soren> Ah, neat.
<soren> Thanks.
<Pici> Hrm.  http://changelogs.ubuntu.com/meta-release seems to be pointin to files that don't exist for the Oneiric release, getting a bunch of reports in #ubuntu about this.  Whose attention do I need to bring this to?
<soren> mvo: ^ ?
<soren> I think.
<Daviey> ev: ^^ Was that something you were working on last week?
<ev> nope
<seb128> tseliot1, hey
<tseliot1> hi seb128
<seb128> tseliot1, is bug #855943 or your list? should it be assigned to you or to somebody else?
<ubottu> Launchpad bug 855943 in fglrx-installer (Ubuntu Precise) "Installing then uninstalling FGLRX makes Oneiric's Unity unbootable" [High,Confirmed] https://launchpad.net/bugs/855943
<seb128> tseliot1, just asking because we get quite some user who get a non starting box due to it :-(
<tseliot1> seb128: let me have a look
<seb128> tseliot1, I've triaged several unity and lightdm bugs which were in fact duplicates of that one now
<seb128> tseliot1, thanks
<seb128> brendand ran into it yesterday
<seb128> brendand, did you use jockey btw or just the command line?
<brendand> seb128 - jockey
<seb128> tseliot1, ^ so it's not command line specific, people screw their system by using jockey...
<seb128> brendand, thanks
<tseliot1> seb128: I saw the bug report but I kind of lost track of the issue as I was busy with other work. I'll make sure to spend some time on the bug to fix it ASAP
<seb128> tseliot1, thanks a lot!
<tseliot1> seb128: thanks for bringing this to my attention again
<seb128> yw ;-)
<mvo> Pici: should be fixed now, sorry for that
<mvo> pitti: is there a chance that we can get u-m 0.152.25.1 that used to be in proposed into -updates? its a rather important fix for a crash with unusual fstab layouts (that turn out to be not that unusual)
<pitti> mvo: sorry, is that update-manager? -updates has 1:0.150.3
<pitti> 0.152.25.1 looks like a very odd version number
<Pici> mvo: thanks
<pitti> mvo: ah, ignore me, that was natty
<mvo> pitti: i mean oneiric, there is 1:0.152.25.4 in proposed, but 0.152.25.1 would be really good to have in -updates by now :/
<pitti> mvo: there's nothing to copy, tohugh, as .1 is not published anywhere :(
<pitti> mvo: perhaps we can fast-pace 1:0.152.25.4 instead? that would be a good idea either way, for people who upgrade these days
<mvo> pitti: yeah, I asked jibel if he has some spare cycles and I will also give it a go
<pitti> jibel, mvo: does either of you have a natty VM for testing an oneiric upgrade? could we test an upgrade with the current -proposed u-m, and if that works, release it?
<mvo> pitti: I will do it now, and +1 for fast tracking :)
<mvo> thanks!
<akgraner> Up next for Ubuntu Open Week in #ubuntu-classroom and #ubuntu-classroom-chat at 1400 UTC is How to contribute translating Ubuntu -- David Planella (dpm)
<hallyn> zul, yay, fix is going into gnome-keyring upstream :)  meanwhile, i'm down to two failures in libvirt regression tests
<zul> hallyn: sweet what are the failures?
<hallyn> zul, dunno yet, just saw the summary.  trying to finish off qemu+ipxe first
<zul> k
<hallyn> zul, any interest in looking over my qemu 0.15 merge to make sure I didn't mess something up?
<hallyn> (it tests fine and isn't much different from the one i ran for a month in september :)
<zul> hallyn: i dont have any experience with qemu-kvm packaging so im probably not a good candidate
<hallyn> nm, i'll just push
<hallyn> to fix that archive problem i created at least
<hallyn> what a day
<hallyn> zul, failures are from test_CVE_2010_2237_2238 and test_virt_install_location
<zul> k then it should probably be updated :)
<hallyn> latter looks like a testcase bug:  it says it can't find <kernel>/home/serge/.virtinst/boot/virtinst-linux
<hallyn> zul, biab
<lfaraone> For UDS, Is it still possible to mark oneselv as attending specific talks / meetings?
<maco> lfaraone: participation essential checkbox in blueprint
<LoRez> I need ftp://ftp.comtrol.com/dev_mstr/rts/drivers/linux/devicemaster-linux-4.22.tar.gz packaged up for lucid.  It's a kernel module and utilities.  anybody know of a contractor willing to take it on?
<mvo> pitti: fwiw, update-manager release upgrade with the -proposed version for natty->oneiric worked fine for me, jibels is still running afaik
<seb128> slangasek, hey, could you look at bug #856988?
<ubottu> Launchpad bug 856988 in gstreamer0.10 (Ubuntu) "totem cannot play quicktime file after upgrade to oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/856988
<seb128> I've no real clue about it, but comments seem to indicate that the .gstreamer-0.10 cache could be confused by some of the multiarch changes
<pitti> mvo: yay, thanks
<seb128> it got some comments and user subscribed, it might be worth keeping an eye on it
<pitti> mvo: jibel confirmed as well; releasing
<pitti> mvo: oh, bugger
<pitti> ATTENTION! update-manager requires a special procedure for releasing to -updates:
<pitti>     https://wiki.ubuntu.com/ArchiveAdministration#Special_case:_update-manager_updates
<pitti> mvo: ok, I'm afraid I don't have time for this today, as I'd need to wait for the publisher to finish, and I need to run out in 40 mins
<pitti> mvo: so I can do it tomorrow morning, or you bug someone else with cocoplum access (infinity/cjwatson/slangasek) for help
<mvo> pitti: well, I can tweak the metarelease file in the meantime to point to the proposed version
<pitti> mvo: so, the actual package is in -updates now
<jibel> pitti, the postgresql upgrade is still running, results in ~45min or so.
<pitti> jibel: many thanks for the quick testing of everything, you rock!
<pitti> mvo: but I suppose the wiki procedure is needed to really use the new version?
 * mvo hugs jibel
<cjwatson> pitti: I can do it
<mvo> pitti: well, I can workaround by pointing to the explicit version in -proposed in the meta-release file, but once its in -updates that is much cleaner
<pitti> cjwatson: thanks
<mvo> thanks cjwatson!
<cjwatson> pitti,mvo: done
<slangasek> seb128: gstreamer hasn't been multiarched, so I have no idea why the cache would be confused.  Note that he says it works with /usr/lib32/gstreamer-0.10, which has nothing to do with multiarch
<mvo> thanks cjwatson!
<seb128> slangasek, ok, dunno then, I just wanted to point it
<mvo> cjwatson: http://archive.ubuntu.com/ubuntu/dists/oneiric-updates/main/dist-upgrader-all/ is currently empty, will this take a bit until it hits the public server?
<slangasek> seb128: doesn't look like anything I can help with, sorry.  I'll pull the multiarch tag off
<slangasek> seb128: would probably be good to get a copy of one of these corrupted ~/.gstreamer-0.10 directories...
<cjwatson> mvo: yes, it'll be visible after the next publisher run
<seb128> slangasek, right, I will ask for details, I figured I would ping in case that's something which speaks to you ;-)
<seb128> doesn't hurt to ask
<cjwatson> so ~40 minutes I guess
<slangasek> seb128: :)
<seb128> slangasek, thanks
<mvo> thanks
<smb> cjwatson, could you work magic to allow kernel package uploaders to upload linux-lts-backport-oneiric. There must be something for the older lts-backport ones... Just cannot run the query_acl correctly it seems
<cjwatson> smb: hmm, I can't see any sign that it was done for maverick or natty either
<cjwatson> smb: I've added linux-lts-backport-{maverick,natty,oneiric} to the kernel packageset in lucid
<cjwatson> smb: I think that should be enough
<smb> cjwatson, OK, so it is not just my bad query skills... How the heck did we get those uploaded then...? Probably Tim did it all
<smb> cjwatson, Great, yes that should be it
<cjwatson> must have been done by a member of ubuntu-core-dev, yes
<micahg> cjwatson: shouldn't MOTU be able to upload a new package as well?
<cjwatson> micahg: I guess
<cjwatson> micahg: I don't think that's relevant here though
<micahg> cjwatson: adds another 70 or so people that can be poked :)
<cjwatson> smb: oh, and done for linux-meta-lts-backport-{maverick,natty,oneiric} now too
<micahg> unless it's already uploaded
<smb> cjwatson, Ah, yes. Is that effective immediately or does it need some propagation time?
<micahg> which it seems like it is../me goes whistling off in another direction
<herton> cjwatson: this is the upload error: Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
<cjwatson> smb: immediately
<cjwatson> herton: that might actually be a known red herring
<soren> herton: I got that a lot a couple of days ago, too. The uploads went through just fine, though.
<cjwatson> herton: you sure it didn't work anyway, despite the error?
<cjwatson> herton: I see linux-lts-backport-oneiric in https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages, uploaded 49 minutes ago
<herton> yeah, it is building, so it's ok I guess
<smb> Oh darn, forgot we only upload there. So the upload rights do not matter at all
<herton> cool, thanks, didn't come to my mind checking there
<stgraber> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<penguin42> stgraber: Hi
<stgraber> penguin42: hey
<penguin42> stgraber: I was helping someone on -bugs yesterday, they've got a 1 line patch on bug 877791
<ubottu> Launchpad bug 877791 in appmenu-qt (Ubuntu) "appmenu crashes on AppMenuPlatformMenuBar::setAltPressed" [Medium,Confirmed] https://launchpad.net/bugs/877791
<penguin42> stgraber: It probably needs a qt person to know if it's the right solution; but it's a fix for crashes of a bunch of different apps which seems like a good thing
<stgraber> didrocks: ^
<stgraber> would indeed be nice to have that tested and commited to the appmenu trunk branch. Then we can get that in Precise and as SRU to Oneiric
<didrocks> stgraber: penguin42: appmenu-qt is handled by agateau who is upstream, he's probably the best to review it
<didrocks> not sure he's still around though
<sroecker> penguin42: stgraber: that was me who filed that bug :)
<penguin42> sroecker: Ah hi; I noticed there was a patch pilot around and remembered it from yesterday
<maco> didrocks: agateau is still around. he works at canonical :)
<agateau> stgraber: penguin42: will look into this tomorrow
<maco> oh hi
<agateau> maco: hi :)
 * agateau has to go
<didrocks> maco: depends, see :-)
<stgraber> agateau: perfect. I assigned you the bug so you don't forget ;)
<maco> didrocks: i thought you meant "around" in the "still maintaining" sense :P
<didrocks> maco: ah not in that sense, indeed! :-)
<yofel> mvo: can you take a look at https://code.launchpad.net/~yofel/software-properties/lp-819793/+merge/79424 ? Just so I know if that's correct. (it works for me)
<jdstrand> !regression-alert bug 877905
<ubottu> Launchpad bug 877905 in xorg (Ubuntu Lucid) "After upgrading Xserver video does not work properly" [Critical,Confirmed] https://launchpad.net/bugs/877905
<ubottu> jdstrand: I am only a bot, please don't think I'm intelligent :)
<jdstrand> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jdstrand> bug #877905
<jdstrand> I am starting an incident report
<jdstrand> this is a result of http://www.ubuntu.com/usn/usn-1232-1/
<skaet> jdstrand,  ack.
<jdstrand> mdeslaur is in the processing of confirming/triage/etc
<jdstrand> https://wiki.ubuntu.com/IncidentReports/2011-10-19-xorg-server-security-update-breaks-glx
<mvo> yofel: hello, thanks! this looks correct, but I will have to give it a fresh look in the morning to double check
<jdstrand> fyi, problem found and fix being uploaded
<LoRez> is there a better place to ask around for packaging contractors?
<Laibsch> where can I see how long the SRU queue is for "ready to upload"-debdiff patches?
<Laibsch> I've been waiting for over a month now.  It feels like being back in the "bad old days".  Reactions had been much swifter in the past which was nice.
<Laibsch> stgraber?
<micahg> Laibsch: doesn't exist anymore, SRU reviews are in queue
<stgraber> http://reports.qa.ubuntu.com/reports/sponsoring/index.html will give you an idea of how far your item is in the queue
<micahg> ah, sponsoring queue...
<Laibsch> micahg: what doesn't exist anymore?  I was indeed asking about the queue, wasn't I?  I'm puzzled.
<Laibsch> micahg: OK, seems we misunderstood each other.
<micahg> Laibsch: I thought you meant SRU approved debdiffs to upload, not debdiffs to upload as SRUs
<micahg> Laibsch: BTW, as long as I have you here, I had the unfortunately luck to be the last person to touch isdnutils, could we chat towards the end of next month about cleaning up the Ubuntu package
<Laibsch> hehe
<Laibsch> a terrible piece of work, I know
<Laibsch> I'm HOPING to be able to get that in shape for syncing in time for precise
<Laibsch> but there's a lot of obstables
<Laibsch> micahg: and to be honest I'm still miffed about some of my patches I think that were even related to isdnutils that rotted for months and years without anybody bothering to even look (long time ago, granted)
<micahg> Laibsch: Ubuntu has a higher version, so syncing will be hard (unless Debian takes the newer version), I can't discuss right now though, only 3.5 hours until eow for me
<micahg> Laibsch: I'm happy to help you from the Ubuntu side next month
<Laibsch> but that left me with the feeling that while I try to help Ubuntu by helping Debian (which I don't really use) that serious efforts are routinely wasted in Ubuntu :-(
<Laibsch> micahg: obviously, I'm looking to get Debian up to that higher version.  I'm even trying to get upstream to make at least another bug-fix release.  But some stuff in Debian is now newer than in Ubuntu.  And that's the stuff that I actually care about.  So, a simple "push back the Ubuntu package" will not work.
<tumbleweed> Laibsch: patches in launchpad are routinely ignored, yes. But if you can supply a debdiff and put it on the sponsor queue, it will be reviewed
<micahg> Laibsch: right, that's part of what confused me about the whole thing...
<Laibsch> tumbleweed: unfortunately, I'm speaking out of experience a few years past.  I followed all the steps. Trust me.  It used to be BAD (around the time lucid was released, IIRC)
<Laibsch> micahg: let's chat about the details when you have time.
<tumbleweed> Laibsch: the patch pilot process seems to have fixed things for the sponsorsorship queue, although it can still get a little long, it stays under control
<micahg> Laibsch: ok, will come find you later
<Laibsch> micahg: in a nutshell, what I'm trying to do is take small steps with what we have, make the build system sane and then hope for a smoother update.
<Laibsch> instead of take newest upstream first and hope to backport the patches, for example.
<Laibsch> tumbleweed: yes, the patch pilot is what fixed this.  Before it was terrible and that's the time I was referring to.  That's why I was a bit anxious to see things slipping back.
<tumbleweed> Laibsch: yeah, those bad days predate me :) Please shout if things regress
<Laibsch> tumbleweed, stgraber: It seems that my patch went back in the queue because I rebased it to the latest changes (which had ignored my debdiff :-( )
<Laibsch> bug 379382
<ubottu> Launchpad bug 379382 in gnome-utils (Ubuntu Lucid) "gnome-screenshot (Alt-Printscreen) black/blanks out top of windows in multi monitor xinerama" [Medium,Triaged] https://launchpad.net/bugs/379382
<Laibsch> stgraber: thank you for the link. exactly what I was looking for
<jdstrand> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jdstrand> please consider bug #877905 resolved. updated packages are confirmed to fix the problem. we are currently waiting for other architectures to finish building
<ubottu> Launchpad bug 877905 in xorg-server (Ubuntu Lucid) "After upgrading Xserver video does not work properly" [Critical,Fix committed] https://launchpad.net/bugs/877905
<ScottK> Thanks for jumping right on it.
<jdstrand> sure thing
 * jdstrand hugs mdeslaur 
<mvo> hallyn: if you don't mind I will upload a new vm-builder for precise that can build precise images
<stgraber> Laibsch: uploaded
<Laibsch> stgraber: great. Many thanks.
<stgraber> Laibsch: btw, what are the plans for maverick and natty?
<Laibsch> how do I read that link, though. There's still patches several months old.
<Laibsch> I suppose those are waiting for fixes to the patches themselves?
<Laibsch> stgraber: maverick and natty did not apply cleanly.  Personally, I'm mostly concerned about lucid/LTS-releases.
<stgraber> yeah, some are there because they aren't worth an SRU at this time (typo fixes and similar), some are waiting feedback, ...
<Laibsch> that's why I left it at that.  I did not feel confident to rebase the patches from upstream. I merely packaged them.
<hallyn> mvo, great, thanks
<Laibsch> stgraber: so, you have to follow that list/URL to have a feel of where things are at?  I'm a bit unsure of how to read it.
<stgraber> Laibsch: yeah, ideally that list should really only contain things that are either ready for review or ready for upload. Unfortunately it's not entirely the case at the moment. We also have the problem of some of them appearing twice (once has a bug and once as a merge proposal)
<stgraber> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> bah, we really need smarter tools for merging .po files as part of package updates
<salty-horse> hey. where can I find the source for the installer's (ubiquity?) partition manager? I think I found a bug
<smoser> ls -l /proc/SOMEPID/fd/
<smoser> shows ' 0 -> pipe:[12113]'
<smoser> what is 12113 ?
<Laibsch> salty-horse: "pull-lp-source $packagename"
 * Laibsch invites salty-horse over to #ubuntu-bugs
<salty-horse> Laibsch, I know that :). I'm asking which package name :)
<Laibsch> OK.  Next try ;-)  "dpkg -S $pathtobinaryname"
<salty-horse> that's hard since it's part of the installation
<Laibsch> $pathtobinaryname = $(which $binaryname) ;-)
<salty-horse> I looked at ubiquity, but I'm not sure where exactly is the partition editor. it seems to have third party debian code
<DoctorPepper> hi guys !!!
<Daviey> jbicha: Hey!
<DoctorPepper> agateau:  are you here ?
<Daviey> jbicha: did you see bug 875818?
<ubottu> Launchpad bug 875818 in dnsmasq (Ubuntu) "dnsmasq sync introduced new non-main depends, causing dep-wait" [High,Confirmed] https://launchpad.net/bugs/875818
<lightnin> I see that some 32 bit packages can now be installed on amd64 Oneiric.
<lightnin> How does one create a i386 package that is compatible with amd64 architecture? (And doesn't make users Force the install?)
<broder> lightnin: the term you're looking for is "multiarch". https://wiki.ubuntu.com/MultiarchSpec is the spec
<cjwatson> lightnin: also http://wiki.debian.org/Multiarch/Implementation
<lightnin> cjwatson: Thanks! That second one I hadn't found...
<Laibsch> lightnin: There's also #multiarch channel on oftc servers
<Laibsch> stgraber: is the upload already building or will that have to be handled by somebody else?
<lightnin> Multiarch is enabled by default in Oneiric, correct?
<Laibsch> IOW, will this be "verification-needed" in a few hours?
<cjwatson> lightnin: on amd64 systems, yes
<stgraber> Laibsch: it's been uploaded to the -proposed queue, the SRU team will review and let it through to -proposed if that looks good
<bdmurray> lucas: is there a reason ubuntu bug descriptions don't appear in the ubuntu_bugs table in udd?
#ubuntu-devel 2011-10-20
<bdmurray> I could use a sponsor for bug 878585
<ubottu> Launchpad bug 878585 in update-manager (Ubuntu Natty) "update apport package hook in natty" [High,Triaged] https://launchpad.net/bugs/878585
<stgraber> bdmurray: looking
<bdmurray> stgraber: thanks
<Keybuk> oh, now the tree goes red
<StevenK> RAOF: MPRIS works out of the box with Quod Libet and Do in Oneiric :-)
<RAOF> StevenK: Woot!
<StevenK> RAOF: And it seems the music menu uses MPRIS, since it shows what is playing
<RAOF> Yup, that's right.
<Keybuk> ww
<stgraber> bdmurray: uploaded
<bdmurray> stgraber: thanks!
<RAOF> StevenK: I guess that means I should clean up that plugin, adapt it for some of the new Do infrastructure that'll make it better, and then make a release ;)
<StevenK> RAOF: Sounds great to me. :-)
<ok2cqr> Hello,
<ok2cqr> for the first time, my package got into Ubuntu repositories. But there is a bug which prevents users to use my program. Hi could I get fix to the upstream package, please?
<ok2cqr> How could I ...
<pitti> Good morning
<ajmitch> morning pitti
<didrocks> good morning
<toshaSA> Idea. Develop to the main system that when an application is run, it checks what that application is with a server. the server returns all packages to the client to make sure that the application will run. This will benefit when running .Net throu wine. E.g.... Running COD4, it retrieves the wine package, Directx.dlls and then executes.
<nigelb> Laney: ping, around?
<pitti> there, all SRU queues empty again *phew*
<nigelb> pitti: *applause* :)
<Chipzz> toshaSA: in one word, HORRIBLE. real solution: package the application. EOT
<RAOF> toshaSA: To some extent that's what winetricks does; that's packaged in the archive and wine Recommends it.  To turn it into a general-purpose solution you'd end up doing essentially the same work as packaging the app.
<Chipzz> but his solution ends up reinventing apt. we already have apt.
<dholbach> good morning
<mvo> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mvo
 * dholbach hugs mvo
<dholbach> happy birthday Ubuntu! https://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000003.html :)
<pitti> oooh! /me lights a candle
<pitti> with TLRS!
<didrocks> :)
<Laibsch> pitti: SRU queue is empty?  what's missing in bug 508545? I thought I had completed all the necessary steps for it to enter the queue...
<ubottu> Launchpad bug 508545 in aptitude (Ubuntu) "Aptitude ignores /etc/apt/preferences.d/*" [Undecided,Fix released] https://launchpad.net/bugs/508545
<pitti> Laibsch: it wasn't uploaded yet
<pitti> Laibsch: but look! there's your friendly patch pilot!
 * pitti hugs mvo
<pitti> and as it happens, also our apt guru
<mvo> Laibsch: I check it out
<Laibsch> pitti: the process changes too rapidly for me to keep up with it.  Haha.  I was just surprised by your statement "queue is empty" when I was in here yesterday complaining about my debdiff rottening away again in LP. ;-)
<pitti> Laibsch: by "queue" I just meant stuff that was uploaded, but needs processing by SRU team
<Laibsch> mvo: thanks.  By the way aptitude in oneiric and precise does not load changelogs with C.  There's a ticket so I guess you already know about it.  Just wanted to raise awareness of bugs dear to my hear, hehe.
<Laibsch> bug 824708
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "Changelog download failed: Download queue destroyed." [Undecided,Triaged] https://launchpad.net/bugs/824708
<Laibsch> pitti: I see.  That's what I meant by "process changes".  AFAICR, this process and responsibility for it wasn't separated in the past, or was it?
<pitti> sponsoring and SRU review have always been distinct processes
<pitti> but in the past the SRU team was able to keep up with uploading patches themselves (i. e. the sponsoring parts)
<mvo> Laibsch: oh, but this other bug has no patch or anything yet, right?
<Laibsch> pitti: I see.  I was wondering if that's why I got the perception.  Simply the same person wearing two hats at the same time.
<Laibsch> mvo: unfortunately, no.  And I don't even have a workaround inside aptitude.  The program does seem to actually download the log, I believe, but somehow fails to display it.
<Laibsch> mvo: indeed, my local proxy has copies of several changelogs for precise packages.  So, they must have been downloaded but fail to display.
<Laibsch> I'll annotate the ticket
<Laney> hi nigelb
<nigelb> Laney: Do you often download the mbox file from lists.ubuntu.com?
<nigelb> (I vaguely remember you having to do something with changes list)
<Laney> yes
<nigelb> I tried a wget and got a 403. :(
<Laney> use rsync
<Laney> lists.ubuntu.com::changes-mboxes
<nigelb> aha. ok
<nigelb> Hrm, I wanted a differnt list.
<Laney> oh, well either bug IS to set up rsync for you or fake the referrer and risk wrath
<nigelb> heh
<nigelb> ah, one needs to fake referrer as well?
<Laney> to use wget
 * nigelb tries.
<nigelb> Its a one-time thing, so I hope IS doesn't ban me permanently ;)
<dholbach> pitti, is piware.de a bit overloaded? :)
<pitti> ugh, seems so
<dholbach> everybody, including me, wants to see those old pictures :)
<pitti> hm, load 0.03, 0% cpu
<nigelb> hehe
<nigelb> I've been refreshing every few minutes :P
<dholbach> nigelb, you're not helping :-P
<nigelb> heh
<nigelb> offload it to people.ubuntu.com!
 * ajmitch wants to see old photos! :)
 * mvo too
<pitti> nigelb, ajmitch, dholbach: try again
<dholbach> Waiting...
<pitti> it's 0.5 s for me now
<mvo> I can see them now - woah, that was a loooong time ago
<pitti> I didn't actually have them online until today, but I thought it was worth it for the occasion
<pitti> dholbach: thanks for pointing out, couldn't resist :)
 * ajmitch was looking at photos from the sydney UDS the other day, these are even older :)
<pitti> meh, ten people looking at it can't possibly bring down the box
<geser> ajmitch: put them online (if they aren't)
<nigelb> pitti: 10 people that you know of ;)
<ajmitch> geser: I think any of my photos are online, I was looking at others, but at least half the links are broken these days
<nigelb> hrm, someone needs to point out who's who.
<nigelb> scott had a link with old pictures somewhere
<nigelb> From the one in montreal, I think.
<pitti> ah, netstat shows some 50 pending connections
<nigelb> heh
<dholbach> nigelb, on picture one, I'm not quite sure who the guy on the left is, but from left to right: ?, Fabio Massimo di Nitto, Jordi Mallach, Matt Zimmerman, Thom May and on the second one: Rob Weir, Daniel Stone, Scott James Remnant, Jeff Waugh
<nigelb> I can't load picture one :|
<pitti> # netstat | grep www|wc -l
<pitti> 205
<pitti> heck
<nigelb> lol
<ajmitch> just 10 people
<ajmitch> ?
 * Laney is reminded of http://oskuro.net/blog/freesoftware/new-project-to-discuss-2011-01-14-20-19 post
<pitti> dholbach: ah, trying to remember his name..
<ajmitch> Laney: ah, the dodgy email?
<nigelb> that was a fun prank!
 * ajmitch shouldn't have closed those tabs, can't see pictures now :)
<nigelb> Ah. https://wiki.ubuntu.com/DeveloperSummit links to old summits and each page has their own photo links for the older ones :)
<ajmitch> nigelb: right, not all links are still working
<dholbach> nigelb, it's Nathaniel McCallum
<nigelb> dholbach: You have a spectacular memory :)
<nigelb> someone who opened photo one can mirror it elsewhere? :)
 * ajmitch wonders who http://www.grawert.net/udu-gallery/img020.jpeg could be :)
<nigelb> Is that dholbach!!
<pitti> it's that hug freak dude
<geser> ajmitch: are you trying to get the next host down? :)
<nigelb> heh
 * pitti hugs dholbach
 * nigelb hugs dholbach as well
<ajmitch> geser: I'm sure ogra's site can handle it :)
<nigelb> geser: "DDoS all servers with old Ubuntu summit pictures" seems to be today's motto
<pitti> nigelb: http://people.canonical.com/~pitti/photos/07%20-%20Warty%20Hack%20room.jpg
<pitti> that's the "picture one" people talk about
<nigelb> pitti: aha, thanks!
<geser> and who is hiding in the background? whose hand is it?
<seb128> geser, jordi
<geser> I see there 4 hands on the notebooks and a 5th in the back (and Matt is sitting to far away for it to be his hand)
<lool> Hmm how would I get in touch with people interested in CAcert and coming to UDS?
<lool> would it be ok to bring that up on ubuntu-devel@ or is there some better forum for it?
<glatzor> morning mvo, I wrote some lines about the PackageKit compat thingy https://blueprints.launchpad.net/ubuntu/+spec/aptdaemon-p-pkcompat
<Daviey> lool: uds-announce@lists.ubuntu.com ?
<Daviey> I suppose that implies you will be organising an assuring event?
<mvo> glatzor: thanks, I will ask to get this on the agenda
<lool> Daviey: Actually I have no experience with CAcert events, so certainly not proposing to organize one myself
<lool> but interested in getting the conversation going
 * dholbach hugs you all back
<tumbleweed> lool: it's common for CACert assural to happen at keysignings. I'm an assurrer (alhtough I can't give maximum points), and I'm sure there'll be others there too. Announce it at the party, and let  people coordinate it themselves?
<Daviey> tumbleweed: don't you need 2 x offical id's?  Without prior warning, i suspect people will only have their passport on them.
<Daviey> lool: FOSDEM always has a good CACert turnout btw.
<zyga> hi, I've seen some mentions of a hook that disables useless triggers (like man pages update) for pbuilders but I cannot find details on how to do so, does anyone remember how to do it off the top of their head?
<lool> Daviey: Yup; I was hoping to start something at UDS though
<lool> Daviey: Do you know of some CAcert people coming to UDS?
<lool> tumbleweed: cool
<tumbleweed> Daviey: oh fair point, warn people to bring two IDs, yes
<Daviey> lool: nope :(.. I believe i have some points.. but largely gave up on it.
<lool> tumbleweed: But things like driving license are accepted for most countries, right?
<tumbleweed> yes, many countries don't have a better second ID than that (although a US visa is also a vaguely reasonable ID)
<glatzor> mvo, there is also https://blueprints.launchpad.net/ubuntu/+spec/aptdaemon-p-threading - but I haven't written a wiki page yet, but it helps to keep track of the bugs and branches
<mvo> glatzor: I saw this one, thanks for it too
<geser> zyga: /usr/share/doc/pbuilder/examples/D80no-man-db-rebuild
<zyga> geser, oh, I have not looked there, thanks :)
<tseliot> cjwatson: what's the recommended way to permanently disable grub's fb in Ubuntu?
<mwhudson> grrr my x220 fails to resume more than once
<mwhudson> seems completely consistent
<mwhudson> at least it boots fast :-)
<mwhudson> i get a flashing caps lock key on the second resume
<mwhudson> is this known?
<amitk> mwhudson: kernel oops
<mwhudson> amitk: so i gather, is there a way of finding out anything about the oops?
<zyga> mwhudson, still up?
<zyga> mwhudson, working for the release I guess
<mwhudson> zyga: just hanging around, not really up
<cjwatson> tseliot: GRUB_TERMINAL=console
<tseliot> cjwatson: thanks a lot
<doko> cyphermox, please merge xapian-core today, there are dep-waits
<doko> barry, hmm, you did upload libvigraimpex with the hdf5 b-d, see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<dholbach> shadeslayer, happy birthday! :)
<cyphermox> doko: ah, okay, but I wouldn't be able to upload it anyway, it was a drive-by fix
<cyphermox> that said, I'll be happy to do it, just can't now (in a train to get to the office)
<doko> cyphermox, I can sponsor, or anybody else
<cyphermox> sure, I'll do the merge as soon as I get in the office (30 min to an hour) then ping you
<mvo> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> doko: i am working on a patch for that.  it's more difficult than just merging in the changes from oneiric because there are many more references to hdf5 that need to be commented out, which led to a few other issues.  right now i'm working out the dpkg-gensymbols differences.
<lool> pitti: Hey, https://code.launchpad.net/~kelemeng/pkgbinarymangler/bug855085/+merge/76296 still shows up as Approved rather than merged and I don't see the changes in the bzr history, but you confirm in the bug that they have been uploaded; should we close the mp then?
<ubottu> Ubuntu bug 76296 in libapache-mod-security (Ubuntu) "mod-security removed from Feisty?" [Undecided,Invalid]
<Daviey> lool: you just outlined a bug in ubottu :)
<lool> erf
<pitti> lool: thanks for pointing out, I set it to "merged"; no idea why it wasn't done automatically
<lool> pitti: Maybe lp:ubuntu/pkgbinarymangler != lp:pkgbinarymangler?
<pitti> ah, that might be the case, yes
<victorp> mdz, ping
<jamespage> is syncpackage --no-lp ... the right way todo fakesyncs?  I have a few I need to deal with due to inconsistent generation of .orig.tar.gz's from github
<Daviey> jamespage: no, that still won't work.
<Daviey> oh, maybe it will.
<jamespage> its the advice from syncpackage when it encounters one - but there is a WARNING in the man page about using it
<Laney> discouraged unless necessary
<tumbleweed> jamespage: --no-lp is the right way, yes
<Laney> which it sometimes is, like for fakesyncs
<Daviey> jamespage: The warning is due to possible breakage in the users hands..
<Daviey> I didn't know syncpackage could handle fakesync's.. i thought you had to do it manually.
<jamespage> great - thanks for the guidance
<tumbleweed> yeah the warning is for people using syncpackage for non-fake syncs
<Laney> that sounds annoying though; can you write a get-orig-source to avoid it in future?
<tumbleweed> whenever there's a get-orig-source and we leapfrog debian, there are going to be mismatches
<Laney> not if it gives you identical output
<Laney> sounds like using github is almost guaranteed to give you mismatches
<tumbleweed> that too
<tumbleweed> get-orig-source normally does some kind of repackaing, which will never give you identical output
<Laney> no reason why it can't
<jamespage> Laney, tumbleweed: took me a while to figure out that github was doing this
<Laney> directhex figured out the runes some time ago
<directhex> snuh?
<Laney> involves gzip -n and tar --mtime iirc
<Laney> for deterministic get-orig-source
<directhex> oh, yes
<tumbleweed> Laney: can we document that somewhere?
<jamespage> it would be great if it could be added to the uscan man page - it has a specific section about using the github redirector so would fix nicely there
 * tumbleweed added my list of gotchas to the repacking section of the packaging guide (back when it was on the wiki)
<jamespage> I've tried to avoid this happening by using git to maintain my Debian package branches
<Laney> pristine-tar takes care of it for you, indeed
<jamespage> and storing the .orig.tar.gz alongside the source and packaging branches
<Laney> you just need to make sure that debian use an identical orig if they upload second
<jamespage> but it relies on the DD that sponsors my upload using that rather than get-orig-source
<Laney> both using a properly deterministic get-orig-source is one way of achieving this, pristine-tar is another
<jamespage> using both covers both bases
 * cjwatson defeats scons.  Another three-quarters of an hour of my life lost to obtuse build systems.
<barry> cjwatson: \o/
<pitti> mvo: can you please reupload software-properties with -v to include https://launchpad.net/ubuntu/oneiric/+source/software-properties/0.81.13 ?
<barry> doko, or perhaps cjwatson: here are the changes to libvigraimpex that produces a successful (local) build on precise.  could you take a quick sanity check on them before i upload?  esp. the .symbols changes: http://paste.ubuntu.com/714185/
<cjwatson> looks plausible enough from a quick scan
<barry> cjwatson: thanks.  i guess that's what bug reports are for, right? :)
<tumbleweed> barry: why are we making the symbols optional, why not remove them?
<cjwatson> ugh, has that symbols file not heard of (c++)
<cjwatson> tumbleweed: it would make the patch submittable to Debian
<barry> tumbleweed: because in debian, there are using (optional) all over the place, so i followed suit
<barry> cjwatson: i wonder if debian would want this patch since it's purely a result of our main/universe b-d policy
<tumbleweed> barry: fair enough I see what you muean
<barry> tumbleweed: slangasek did comment on the bogosity of that, but not for us to worry about :)
 * tumbleweed wonders what the point of a 70% optional symbols file is
<cjwatson> barry: maybe or maybe not; sometimes it's worth a try
<barry> cjwatson: i guess it can't hurt to submit it
<Laney> the package is orphaned?
<Laney> â QA upload
<OdyX> tkamppeter: wrt http://wiki.debian.org/Teams/Printing/RethinkingTheStack#Action_1_-_Rename_printing_driver_packages what should we do with hplip, hp* ?
<doko> dbarth, just looking with cyphermox into xapian-core. your patch is not applied
<mneptok> anyone here familiar with debian-installer and parted stuff? i'm curious if during installation it is possible to choose a partition table format (e.g. GPT) or if MS-DOS type is the sole choice.
<cyphermox> dbarth: ^^ the cjk tokenizer patch
<cjwatson> mneptok: Interactive partition table type selection requires booting d-i in expert mode.  However, d-i will automatically select GPT if installing on EFI-based systems or if the disk is >2TiB.
<jcastro> charlie-tca: 15 minute session warning!
<charlie-tca> Got it.
<charlie-tca> Thank you
<dbarth> doko: uh?
<dbarth> doko: how come?
<dbarth> didrocks: ^^
<didrocks> dbarth: wait, on mumble
<dbarth> doko: without the patch, it's not supposed to be working
<dbarth> doko: hm,, let me check the email thread; we may carry a point release that contains the cjk-support patch
<dbarth> doko: ie, without the need for a distro-patch; i know that upstream had done something special and upstream in debian, to accommodate our case
<doko> dbarth, ENOCLUE. I just do see that it is not applied
<dbarth> doko: ugh, do you have a log to that build issue?
<cyphermox> dbarth, I don't think there's anything special, added by debian or upstream in 1.2.7 to accomodate this
<mneptok> cjwatson: my UEFI ThinkPad got an MSDOS table, probably because the rudimentary BIOS was set to "Legacy" boot during installation. that mode then fails to boot, and i'm using UEFI. not knowing about the option in d-i expert mode, i wrote a new table with the drive out and in a dock.
<dbarth> well, i re-read http://trac.xapian.org/ticket/180#comment:29
<dbarth> the patch was re-hashed especially for us
<dbarth> which was cool
<doko> dbarth, just download the package, there is nothing applied before or during the build, afaics
<cjwatson> mneptok: right, if it's booted in legacy mode, it's a BIOS system as far as d-i is concerned
<popey> hello! https://launchpad.net/ubuntu/oneiric/+source/policykit-desktop-privileges/0.6 "* Allow local admins to update already installed software without password"
<popey> Does anyone have a link to where/if that was discussed?
<didrocks> doko: dbarth: the patch is applied in the ppa, I was on vacation when cyphermox pushed it, I have no clue what's different from the version I pushed in the ppa
<cyphermox> didrocks: same patch if you took it from the upstream bug
<didrocks> doko: dbarth: but I confirm there is no debian/patches/series containing it
<didrocks> cyphermox: you don't took my packaging it seems
<didrocks> cyphermox: there is no reference of the patch in a debian/patches/series
<didrocks> so quilt doesn't pick it up
<cyphermox> didrocks: I had no idea you had packaging, or where the ppa was
<cyphermox> I do realize that :P
<didrocks> cyphermox: who asked you to push it then?
<didrocks> (as I was on holidays with no internet connexion, I didn't track it)
<cyphermox> might have been seb128
<cyphermox> I don't recall
<didrocks> would have been nice people connecting the dots :)
<cyphermox> the weird thing is, it seems to work anyway
<didrocks> but anyway, what is needed now is a SRU
<didrocks> with this patch applied
<didrocks> it's working? O_o
<cyphermox> didrocks: I'm pretty sure things were working properly when I tested it
<cyphermox> didrocks: plus someone else should have been testing this too, no? xapian-core was uploaded a while before the rest of the unity stuff for this CJK thing
<seb128> didrocks, what?
<cyphermox> (e.g. time to catch it if the upper layers don't appear to work)
<didrocks> cyphermox: I'm not sure, not sure why I'm pinged by dbarth either, there is no context :/
<didrocks> just the "patch is no applied"
<didrocks> cyphermox: from what I knew, OEM tested it, not sure if it's from the ppa or oneiric proper, by yeah
<didrocks> but*
<cyphermox> didrocks: well, doko caught that as he was reviewing my merge of xapian-core 1.2.7-1ubuntu1
<didrocks> cyphermox: ok, we need to ensure if it's needed or not (it seemed to be needed for at least software-center), can you sort this out or do you need help?
<didrocks> cyphermox: basically, the fix is easy, it's adding it in debian/patches/series (but if your patch is different from the one we tested in the ppa, it needs careful testing then)
<cyphermox> didrocks: I can sort it out; I just installed ko and jp inputs to give this testing, and software-center was what I was using
<cyphermox> didrocks: the patch I took straight from the upstream bug, it just needs a refresh to apply properly to 1.2.7... not sure if that was required for 1.2.5 as well
<didrocks> cyphermox: great! keep us in touch :)
<didrocks> cyphermox: well, I'm more concerned for Oneiric right now
<cyphermox> sure
<cyphermox> didrocks: I'll just pick up yours from the PPA
<mneptok> cjwatson: my rudimentary BIOS also allows "Both." i'd be interested to see what d-i chooses. someone what to buy me a 2.5" laptop drive? O:)
<seb128> didrocks, cyphermox: is the issue https://launchpad.net/ubuntu/oneiric/+source/xapian-core/1.2.5-1ubuntu1 ?
<didrocks> seb128: yeah
<mneptok> s/what/want/
<cyphermox> seb128: yup
<seb128> what about it?
<didrocks> cyphermox: just test without first :)
 * mneptok pokes cr3
<didrocks> seb128: see backlog ^
<cyphermox> didrocks: yeah, working on it, I'm at restarting my session now, which I can't do if I need to answer things on IRC :)
<seb128> didrocks, is that a quilt package and the patch didn't make it to the series?
<cyphermox> seb128: correct
<didrocks> seb128: seems so
<seb128> ok
<seb128> Signed-By: Michael Vogt <michael.vogt@ubuntu.com>
<didrocks> cyphermox: reboot please
<didrocks> :)
<didrocks> now now! ;)
<cyphermox> didrocks: zug zug :)
<cr3> mneptok: yo mama, what's up?
<seb128> cyphermox, did you provide a debdiff?
<mneptok> cr3: PM (busy channel)
<seb128> well dunno, it was a packaging screwup at the time th work was done
<cyphermox> yes
<didrocks> seb128: I guess we don't care about who did it wrong, just trying to figure out if not having the patch for Oneiric is critical right now
<didrocks> I know that people testing it starting september and didn't notice issues
<didrocks> so, there is hope
<didrocks> in that case, not sure what's the xapian patch is for then
<bdrung> jamespage, Daviey, tumbleweed: the man page should be more clear that --no-lp is the way for fakesyncs. should it fall back to --no-lp if a fakesync is detected?
<rigved> hi everyone...can anyone tell me how to apply the patch as mentioned in the last comment on bug 849967
<ubottu> Launchpad bug 849967 in alsa-driver (Ubuntu) "[Lenovo Y300] Microphone is unable to record any audio" [Undecided,Triaged] https://launchpad.net/bugs/849967
<seb128> didrocks, did we ever get any complain on the bug tracker about cjk?
<jamespage> bdrung: I think the message it give ATM is sufficient - I would probably want to take a look at why before I went down that path anyway
<didrocks> seb128: didn't notice
<seb128> didrocks, I guess the people who hit the issue don't interact much with us so we will not notice it
<didrocks> right
<seb128> didrocks, we need to check with oem teams
<didrocks> but OEM tested oneiric in beta1
<didrocks> IIRC
<didrocks> when we landed everything
<didrocks> just need to be sure they didn't take the ppa version
<jamespage> bdrung: hrm - thats the message that syncpackage gives (not what it says in the man page)
<jamespage> just to be clear :-)
<Kaleo> any idea of how that could happen? http://pastebin.com/NbJ2Mite
<cjwatson> mneptok: at any one time you can only be booted using one or the other; some Ubuntu images support both and in those cases either the firmware will pick one or it will ask you to choose
<cjwatson> Kaleo: what version of apt?
<Kaleo> cjwatson: one in an unstable version of oneiric, let me check
<cjwatson> Kaleo: I expect this is bug 871731, affecting the version shipped in 11.10 beta-1 but not 11.04 and not 11.10 beta-2 - run 'apt-get install apt' and then 'apt-get update' again
<ubottu> Launchpad bug 871731 in Release Notes for Ubuntu "Direct upgrades from beta-1 will produce annoying error message" [Undecided,Fix released] https://launchpad.net/bugs/871731
<cjwatson> it was fixed in, I believe, apt 0.8.16~exp5ubuntu9
<Kaleo> cjwatson: 0.8.16~exp5ubuntu6
<cjwatson> Kaleo: right, that was what was shipped in beta-1.  Your 'apt-get update' got far enough that you should be able to upgrade apt and try again.
<Kaleo> cjwatson: it fixed it
<Kaleo> cjwatson: you rock my world :)
<cjwatson> Kaleo: we decided this was worth it because otherwise we'd have had to roll back several Launchpad changes and regress bandwidth costs for multiarch users
<Kaleo> cjwatson: ok
<Kaleo> cjwatson: what would you like for UDS?
<Kaleo> cjwatson: beer?
<cjwatson> which we did consider, but given that the upgrade works and is just ugly ...
<Kaleo> I get it
<cjwatson> Kaleo: heh, I have a two-year-old, sleep is high on the agenda ;-)  but beer rarely goes amiss
<Kaleo> cjwatson: :)
<didrocks> cyphermox: is it working?
<xtian> hi everyone. i'm seeing a funny behaviour with ubuntu/precise. have set up a precise chroot (amd64) on an amd64 host
<xtian> ...using debootstrap --arch=amd64
<xtian> chrooted into it, added few sources, updated, selected a bunch of packages (~100), and ran apt-get upgrade
<xtian> now apt would try to install i386 packages randomly, for about half of the packages selected
<xtian> removed 'foreign-architecture i386' from /etc/dpkg/dpkg.cfg.d/multiarch, re-ran apt, now everything is installed as amd64
<xtian> did not see this with oneiric, even though the i386 multiarch entry was also there
<xtian> (i've been redirected here from #ubuntu)
<cjwatson> xtian: it may be transient due to i386 and amd64 builds not necessarily being in perfect sync at the moment
<cjwatson> which is slightly inevitable with development releases although unfortunate
<cjwatson> xtian: do you have specific examples that are going wrong at the moment?
<cjwatson> I kind of think apt-get shouldn't pick foreign-arch packages to satisfy explicit requests, but I can't remember what the spec says ...
<cjwatson> slangasek might have a better handle on that
<xtian> cjwatson: yeah, apt was picking i386, although amd64 packages were available
<xtian> cjwatson: after removing the multiarch entry for i386, everything went fine
<cjwatson> available but perhaps not installable
<cjwatson> do you have specific examples?
<xtian> cjwatson: not at the moment, i could do it again (afresh) and post the result
<xtian> cjwatson: would take a little whilre
<cjwatson> yep.  you might find the results changing from hour to hour at the moment, of course
<xtian> cjwatson: should i open a bug for that
<cjwatson> it probably wouldn't hurt, although I don't know how immediately addressable it would be
<xtian> cjwatson: okay, if it is not a bug in apt/dpkg, then i'm not worired
<xtian> *worried
<cjwatson> it sounds like a misfeature at least
<cjwatson> although I don't know if it's fixable without breaking other things we rely on
<xtian> ...in the light of the respective amd64 packages available and installable, a misfeature, yes :)
<cjwatson> (e.g. smooth transitions of biarch/traditional -> multiarch)
<cjwatson> xtian: how do you know they were installable?  you know they were available, but ...
<xtian> cjwatson: after removing the multiarch entry for i386, the amd64 packages were installed
<cjwatson> my unproven hypothesis here is that apt wasn't able to resolve some dependency using only native-architecture packages, and fell back to foreign-arch
<cjwatson> xtian: right, but you ran apt-get update in between, right?
<xtian> cjwatson: yes
<slangasek> xtian, cjwatson: would like to see specific commands and output of what's happening; yes, apt is meant to always prefer the native packages, but I know there's at least an issue that once it's picked *one* i386 package to satisfy a dependency, it will remain sticky to that arch when it shouldn't
<cjwatson> so the situation might have changed in the archive
<slangasek> i.e., whereas installing an i386 library that depends on a multi-arch: foreign package should prefer the amd64 version of that package, apt is preferring the i386 version
<cjwatson> it doesn't sound like xtian's situation ought to have involved anything from i386, though
<xtian> slangasek, cjwatson: i've searched all regular files in the chroot, and all ELF objects were amd64 after removing the multiarch entry
<slangasek> xtian: much easier to run dpkg -l '*:i386' :)
<slangasek> bug #877681 is the apt bug about wrong m-a: foreign packages being chosen
<ubottu> Launchpad bug 877681 in apt (Ubuntu) "Oneric's ia32-libs has unresolved dependencies, breaks subversion" [Low,Triaged] https://launchpad.net/bugs/877681
<xtian> slangasek: true... but i wanted to be sure and see what's actually *there* (didn't trust dpkg at that moment) :)
<slangasek> dpkg is trustworthy in this regard
<slangasek> if you ever found that it wasn't, that'd be a critical bug
<xtian> slangasek: ok, convinced... :)
<slangasek> cjwatson: right, so bug #877681 describes the one issue I know where there's an apt bug; I agree that xtian's situation sounds more like transient archive skew
<ubottu> Launchpad bug 877681 in apt (Ubuntu) "Oneric's ia32-libs has unresolved dependencies, breaks subversion" [Low,Triaged] https://launchpad.net/bugs/877681
<cjwatson> slangasek: right, I'm unconvinced that transient archive skew ought to be allowed to lead to this though
<xtian> slangasek, cjwatson: okay, i'll keep an eye on it, just wanted to make sure it is not apt/dpkg/... failing somewhere
<slangasek> cjwatson: right; it may be difficult to enforce though
<cjwatson> ah, well, that is sort of that apt bug
<xtian> slangasek, cjwatson: thanks for your insight, i'll also check out #877681
<cjwatson> (maybe)
<xtian> slangasek, cjwatson: will it be worth it to file a bug, if only for the record?
<xtian> then again, it's always a pain searching in a bug-db, so not sure how much good a report could do
<slangasek> xtian: probably only worth filing a bug if you can provide apt-get output showing the issue in question
<slangasek> when you can do so, yes, please file a bug on apt
<slangasek> (without the output, I'm sure it's too vague to ever get actioned)
<xtian> slangasek: i can just set up the chroot again (freshly) and provide the commands and their output
<slangasek> xtian: if it's reproducible this way, then that would definitely warrant a bug report, thanks :)
<xtian> slangasek: as i'm thinking i see it cjwatson's way that even if there's rumble on the archive, apt should not prefer a foreign arch over it's native one, if the packages are available
<xtian> (in native format, that is)
<slangasek> the problem is in deciding what to do when the foreign arch package is installable and the native one isn't
<slangasek> our choices are a) install the foreign arch one or b) hold the package back; both have drawbacks
<xtian> hum, i've just checked, sources.list has oneiric and precise, in that order
<xtian> maybe, after removing i386 multiarch, apt fell back to oneiric and used amd64 packages from there
<slangasek> that could be it indeed
<xtian> while, with the i386 multiarch in-place, it was seeing newer i386 packages in precise and used them
<xtian> (amd64 not yet built or something)
<xtian> .oO( live and learn... )
<tumbleweed> anyone have any ideas why ubiquity might hang on "Detecting file systems" ? I see someone filed a similar bug, but it's light on information (bug 801223)
<ubottu> Launchpad bug 801223 in ubiquity (Ubuntu) "oneiric amd64 ubiquity hung on detecting file systems" [Undecided,New] https://launchpad.net/bugs/801223
<xtian> slangasek, cjwatson: thanks again, i think the apt mystery is solved
<slangasek> xtian: I think a bug report against apt showing the specifics would still be worthwhile; preferably including 'apt-cache policy $pkg' output, with multiarch enabled, for one of the packages that apt picks the i386 version for
<xtian> slangasek: okay, will do.
<slangasek> bdmurray: I don't know how many people will really be trying to upgrade from lucid to precise at this stage, but bug #878960 is an issue to watch out for (could get reported against arbitrary packages, key word is '--warning=no-timestamp' in DpkgTerminalLog)
<ubottu> Launchpad bug 878960 in dpkg (Ubuntu Precise) "dpkg in precise missing pre-dependency on later version of tar than shipped in lucid" [High,Triaged] https://launchpad.net/bugs/878960
<xtian> slangasek: will take some time, i'll start out with a fresh chroot and put precise sources in it only, let's see what happens
<xtian> slangasek: quitting time first, EOD... at least, for work :)
<slangasek> xtian: ah, enjoy :)
<xtian> slangasek: thanks, cu tomorrow, when i have my bug report done
 * xtian -> ~.
<stgraber> pitti: ping
<cjwatson> slangasek: well, let's minimise the window for that; fix uploaded.  I knew I'd forgotten something, as I had seen that thread on debian-devel ...
<slangasek> cjwatson: :)
<slangasek> thanks
<tkamppeter> OdyX, hi
<slangasek> $ time dput ia32-libs_20090808ubuntu28_source.changes
<slangasek> [...]
<slangasek> real	0m5.877s
<slangasek> user	0m0.420s
<slangasek> sys	0m0.136s
<slangasek> <cackle>
<james_w> \o/
<debfx> http://bugs.debian.org/644412 is quite annoying, it would be good to have dpkg 1.16.1.1 merged soon :)
<ubottu> Debian bug 644412 in dpkg-dev "dpkg-buildflags: use DEB_BUILD_MAINT_OPTIONS when including buildflags.mk" [Normal,Fixed]
<simple_user> I installed the python-qt4-doc package on my system for PyQt4 docs, but don't know how to access the docs.  Where are they located on my system (oneric)
<jtaylor> simple_user: /usr/share/doc/python-qt4-doc/html/index.html its probably registered under docbase too http://wiki.debian.org/doc-base
<simple_user> jtaylor, thank you
<bdmurray> Is casper supposed to be installed / installable? bug 821445
<ubottu> Launchpad bug 821445 in casper (Ubuntu) "Casper fails to install on 10.04.3" [Low,New] https://launchpad.net/bugs/821445
<bdmurray> stgraber: I've run into an issue with the test you provided in bug 787212
<ubottu> Launchpad bug 787212 in isc-dhcp (Ubuntu Natty) "isc-dhcp-server doesn't work in ipv6 mode" [Medium,In progress] https://launchpad.net/bugs/787212
<stgraber> bdmurray: ah?
<bdmurray> /etc/dhcp/dhcpd.conf line 25: IPv6 addresses are only available in DHCPv6 mode.
<bdmurray> option dhcp6.name-servers 2001:
<stgraber> bdmurray: why do you have a dhcp6.name-servers in /etc/dhcp/dhcpd.conf? you're supposed to have that in /etc/dhcp/dhcpd6.conf
<bdmurray> stgraber: okay sorted
<bdmurray> stgraber: okay now it is failing to start because it is not configured to listen on any interfaces
<stgraber> bdmurray: right, you need to actually have an IP in the subnet you defined in your dhcpd.conf/dhcpd6.conf for the daemon to start
<bdmurray> stgraber: or I could change the subnet to include the IP I have correct?
<stgraber> bdmurray: indeed
<bdmurray> stgraber: not having used ipv6 before how can I sort that out?
<stgraber> bdmurray: ip -6 addr add <ipv6>/64 dev eth0
<stgraber> that should add the IPv6 to the interface, making dhcpd happy
<stgraber> if you want something more permanent you can use:
<stgraber> iface eth0 inet6 static
<stgraber>     address <address>
<stgraber>     netmask 64
<jo-erlend> guest users cannot use IM because they don't have a keyring. How do I report bugs like that?
<cjwatson> debfx: yep, I hope to merge dpkg tomorrow
<jo-erlend> I mean.. What is the "guest user package"?
<doko> chrisccoulson, firefox hangs again on powerpc. please could you investigate the reason before new uploads? this blocks the powerpc builds again and again
<cjwatson> heh, snap
<cjwatson> (#-release)
<jo-erlend> perhaps someone can just fix it then, so it doesn't remain unfixed forever. I have no idea how to even find out how to report a bug for bugs like that. The list is growing fairly long. Sort of feels like testing and QA is worthless.
<SpamapS> doko: FYI, we were holding off merging PHP 5.3.8 because of a regression it introduces in many PHP apps
<doko> SpamapS, I didn't see an issue filed about that
<doko> nor a ntification that it shouldn't be merged
<SpamapS> I didn't know how to make any such notification. :-P
<SpamapS> 5.3.9 will revert the problem
<SpamapS> no idea when its supposed to release
<doko> at least email me that you'll care about the merge (and MoM does offer some kind of commenting)
<SpamapS> Yeah that would have been good
<SpamapS> zul and I usualy take care of it. :-P
<doko> hmm, at least not about the ftbfs in oneiric ;-P
<SpamapS> anyway, will try and figure out from upstream if 5.3.9 is expected soon
<SpamapS> Otherwise http://pear.php.net/bugs/bug.php?id=18749&thanks=3 will break all apps that depend on PEAR
<SpamapS> so we may have to revert back to 5.3.7
<SpamapS> err
<SpamapS> 5.3.6
<SpamapS> anyway
<SpamapS> have to run..
<SpamapS> doko: no hard feelings, the effort is of course always appreciated :)
<doko> SpamapS, I know now, and I'll pester you from now on, instead of doing merges myself ;)
<bdmurray> I could use a sponsor for a debdiff in bug 787212
<ubottu> Launchpad bug 787212 in isc-dhcp (Ubuntu Natty) "isc-dhcp-server doesn't work in ipv6 mode" [Medium,In progress] https://launchpad.net/bugs/787212
<StevenK> When I tell my machines to reboot via the menu in the top right, it drops back to the login screen only. When I attempt to reboot via that menu, there is no effect, what am I missing?
<penguin42> I've sene a few bug reports like that
<penguin42> seen
<slangasek> StevenK: do you have another login going at the same time?  The old "You have multiple accounts logged in, type admin password to force shutdown" integration seems to be broken; I've filed a bug but don't remember where
<slangasek> bdmurray: looking
<StevenK> slangasek: No, just me, once.
<slangasek> dunno then
<penguin42> StevenK: Even via ssh?
<slangasek> might still be consolekit breakage of some kind
<StevenK> Any logs or anything I can paw through?
 * slangasek defers to the desktop team
<StevenK> I'll ask seb when he appears, he owes me a favour. :-)
<slangasek> bdmurray: uploaded
<bdmurray> slangasek: thanks
<slangasek> n/p!
<bdmurray> slangasek: the grub tasks in bug 816036 seem invalid to me. do you agree?
<ubottu> Launchpad bug 807950 in zeitgeist (Ubuntu Oneiric) "duplicate for #816036 zeitgeist-daemon crashed with LookupError in remove_from_connection(): <_zeitgeist.engine.remote.RemoteInterface at /org/gnome/zeitgeist/log/activity at 0xb74ee2cc> is not exported at a location matching (None,None)" [High,Triaged] https://launchpad.net/bugs/807950
<bdmurray> yes of course not valid there but in bug 816035?
<ubottu> Launchpad bug 816035 in grub2 (Ubuntu Oneiric) "Memory upgrade makes Ubuntu painfully slow" [Undecided,New] https://launchpad.net/bugs/816035
<slangasek> bdmurray: if it's already fixed in linux, I guess it's probably invalid on grub, yeah
<bdmurray> right thanks
<slangasek> hallyn: I'm a bit surprised to see qemu-kvm-spice as a separate source package (looking at NEW queue) - did spice get shot down for an MIR?
<slangasek> hallyn: bug #878162... doesn't look like it was ever really considered, I guess the dependency chain is too messy.  But then, why is it worth having a separate qemu-kvm-spice build?
<ubottu> Launchpad bug 878162 in qemu-kvm (Ubuntu) "[MIR] qemu-kvm pulls packages from universe" [High,Fix released] https://launchpad.net/bugs/878162
<bdrung> doko: will precise get multiarch support for openjdk?
<bdrung> doko: i want to install an 32 bit libreoffice on an amd64 system
<doko> bdrung, it already does have it. get lo to use it
<bdrung> doko: really. i tried with openjdk 7 and it complains
<bdrung> s/really./really?/
<doko> bdrung, please file a report. hope, Sweetshark will care about it. didn't check with 7 myself
#ubuntu-devel 2011-10-21
<bdrung> doko: even openjdk-6 fails
<doko> bdrung, file a report, even with patches
<doko> and fixing eclipse issues as well .... ;-P
<hallyn> slangasek, I'm working on spice MIR right now
<hallyn> well, not RIGHT now.  it's dinner time
<hallyn> slangasek, MIR for spice was not feasible for oneiric cycle.  qemu-kvm-spice was.  Now, it's unfortunate that in the end we missed oneiric after all :)
<bdrung> doko: first step done: bug #879167
<ubottu> Launchpad bug 879167 in openjdk-6 (Ubuntu) "Missing or broken multiarch support" [Undecided,New] https://launchpad.net/bugs/879167
<bdrung> doko: next step for me: go to bed :p
<bdrung> doko: btw, should openjdk multiarch already work in oneiric?
<doko> bdrung, yes with 7, no with 6
<bdrung> doko: doesn't work too: bug #879170
<ubottu> Launchpad bug 879170 in openjdk-7 (Ubuntu) "Missing or broken multiarch support " [Undecided,New] https://launchpad.net/bugs/879170
<slangasek> hallyn: ah.  Do you know if qemu-spice could reasonably be built from the qemu-linaro branch?
<hallyn> i think so
<hallyn> its in universe right?
<slangasek> yes
<hallyn> i figured you were pinging me on lvm+udev :)
<slangasek> so maybe that would be better than having Yet Another Build?
<slangasek> nah, I was leaving lvm+udev for another day :)
<hallyn> well it is a different tree...
<hallyn> and we'd need a separate configure+make in any case
<slangasek> you saw the change proposed on the bug?  I don't know what --noudevsync does
<slangasek> sure, but keeping it in a single source package means one fewer source package to be uploaded for each upstream release
<hallyn> true.
<hallyn> i don't know that the people who want spice woudl care much about it being qemu-based instead of qemu-kvm-based
<hallyn> so it might be doable
<hallyn> i personally dont' much care, apart from these poor folks being able to use spice at last :)
<slangasek> OTOH, if you're doing an MIR for spice anyway, maybe we should wait for the outcome of that before changing the packaging
<slangasek> but if we don't get spice in main, I'd like to pull this into qemu-linaro
<hallyn> ok, that sounds like a good plan
<hallyn> thanks :)
<slangasek> thank you!
<hallyn> i'll look into EXACTLY what --noudevsync brings and comment later
<hallyn> i fear it will just hide boot problems
<penguin42> but you need the kvm built to have the spice stuff enabled?
<hallyn> penguin42, kvm would be enabled.
<hallyn> the qemu and qemu-kvm trees are pretty darned close these days
<hallyn> minor differences wrt io threads and such
 * penguin42 shudders
<hallyn> at what?
<penguin42> io threads :-)
<hallyn> heh
<hallyn> aio threads i should say
<hallyn> grr, yeah i guess bug 878162 showed me the dependency chain for spice MIR.  That is NOT pretty :)
<ubottu> Launchpad bug 878162 in qemu-kvm (Ubuntu) "[MIR] qemu-kvm pulls packages from universe" [High,Fix released] https://launchpad.net/bugs/878162
<pitti> Good morning
<pitti> stgraber: pong
<pitti> lool: can you please commit your udev changes to lp:~ubuntu-core-dev/ubuntu/precise/udev/ubuntu ? (there's no diff in LP yet)
<didrocks> good morning
<mbiebl> pitti: hi
<mbiebl> we were talking some time ago about updating g-i and pygobject in debian
<mbiebl> and seb128 was mentioning, that you would take care of that
<mbiebl> (for exp, ie)
<pitti> hey mbiebl
<pitti> mbiebl: I'm happy to do that, yes; but we really need a newer glib
<mbiebl> 2.30.1 landed in exp some days ago
<mbiebl> I assume that should be sufficient
<pitti> oh, nice!
<pitti> mbiebl: I'll update the packages today then
<mbiebl> great, thanks
<mbiebl> this way we can stage some of the 3.2 changes in exp until the current GNOME 3 transition is ongoing
<pitti> slangasek: committed your udisks multi-arch fix to debian git, so we can sync again next time. thanks!
<pitti> ah, I see your deiban bug, thanks
<lool> pitti: Done, thanks; odd that I don't see it in the package import queue
<lool> albeit, import-dsc didn't work because the upstream tag was "173" instead of "upstream-173"
<pitti> LP has trouble generating udev diffs, because of the test/sys stuff
<pitti> lool: this isn't an UDD branch
<pitti> it's derived from the upstream trunk bzr import
<lool> oh right
<pitti> i. e. a manual one
<lool> I guess we could replace the UDD branch with it, but I don't work on udev often enough that I should push for this myself
<dholbach> good morning
<soren> mvo: http://paste.ubuntu.com/714898/ <--- Does this sound familiar at all? (from #ubuntu-installer last night)
<mvo> soren: no, sound like it failed to download the signature file for some reason? is this a common failure or was it a one-off thing?
<soren> mvo: That was two people reporting it.
<soren> mvo: And hour and a half apart.
<soren> mvo: So at least a two-off thing :)
<mvo> soren: hm, hm, thanks!  I wonder if maybe one of the archive.ubuntu.com servers was/is out of sync, I est now
<mvo> soren: thanks, that is fixed onw
<soren> mvo: \o/ Thanks.
<mvo> thank you!
<xtian> slangasek: ping
<xtian> cjwatson: ping
<xtian> cjwatson, slangasek: i've filed https://bugs.launchpad.net/ubuntu/+source/apt/+bug/879324 for this supposed multiarch-misfeature of apt
<ubottu> Ubuntu bug 879324 in apt (Ubuntu) "apt-get dselect-upgrade prefers multiarch over native" [Undecided,New]
<xtian> cjwatson, slangasek: (the issue we talked about yeasterday)
<cjwatson> xtian: ok, I was just helping you narrow it down, I doubt I'll be fixing it ;-)
<cjwatson> so no need to ping me
<cjwatson> but thanks for filing that
<cjwatson> I can confirm joe is currently in sync between amd64 and i386
<xtian> cjwatson: ok thanks anyway :)
<cjwatson> although it was changed relatively recently
<xtian> cjwatson: yeah, depends on the mirror you're using. i tried with german mirrors today, but could not reproduce, since these mirrors caught up overnight
<cjwatson> there was a period of about two hours on Monday when amd64 and i386 had different versions of joe in precise
<xtian> cjwatson: that's why i picked a mirror with a reasonable lag for reproducing :)
<xtian> cjwatson: interesting detail maybe, the misfeature shows with 'apt-get dselect-upgrade' only, not with 'apt-get upgrade' or 'apt-get install'
<xtian> (it's all there in the report, detailed console logs of what i did included)
<xtian> ...moving on...
<cjwatson> yep, that definitely looks like a good way to narrow it down; I'll mark it Confirmed
<cjwatson> or actually triaged
<mdeslaur> !pilot in
<mdeslaur> argh
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<nigelb> heh
<nigelb> mdeslaur: TGIF? :)
<mdeslaur> nigelb: hehe :)
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<mdeslaur> mvo: hi!
<mdeslaur> mvo: I installed a couple of maverick machines yesterday, and the "upgrade to new release" window that popped up points to an invalid URL: http://archive.ubuntu.com/ubuntu/dists/natty-proposed/main/dist-upgrader-all/0.150.2/ReleaseAnnouncement.html
<mdeslaur> mvo: are you aware of that? I also seem to recall someone saying the tarball couldn't be downloaded to upgrade maverick also
<soren> mdeslaur: Fixed earlier today.
<mdeslaur> soren: ah, cool. thanks!
<mdeslaur> mvo: never mind :)
<soren> mdeslaur: http://paste.ubuntu.com/715103/
<mdeslaur> hmm...the web page still doesn't seem to be there though
<mdeslaur> unless the url got changed with whatever mvo changed
<cjwatson> 0.150.2 has been garbage-collected; the current version is 0.150.5
<cjwatson> shouldn't it be using current anyway?
<stgraber> pitti: that ping was for yesterday's TB meeting :)
<cjwatson> unless this is a version-specific tarball that's being downloaded, but then why is it an out-of-date version ...
<pitti> stgraber: erk, I wasn't at home last night; sorry, I thought it was next week
<Chipzz> cjwatson: another question that pops to mind is why the archive is hosting a .html file... doesn't look like the proper place to me
<mdeslaur> cjwatson: this was a fresh installation from cd media
<mdeslaur> without updates installed
<cjwatson> hm, changelogs.ubuntu.com lists current
<Chipzz> but that may be a matter of (subjective) opinion
<cjwatson> the archive's a reasonable place in this case, given that it comes from a custom upload
<cjwatson> mdeslaur: is it possible that http://changelogs.ubuntu.com/meta-release has been cached?
<cjwatson> mdeslaur: force-refreshing that might help
<Chipzz> well it feels wrong to me. I'm used to archive.ubuntu.com and ftp.debian.org only hosting .deb's, sources, Packages etc...
<Chipzz> but again, subjective opinion :)
<cjwatson> Chipzz: installer kernels, initrds, package index translations, ...
<cjwatson> (to list a few other things that live in custom uploads)
<mdeslaur> cjwatson: I don't know where it would get cached...there's nothing on my network that would cache it, and this was two fresh installs, immediately after reboot
<cjwatson> mdeslaur: "transparent" proxy at your ISP
<mdeslaur> possibly
<Chipzz> cjwatson: right, but those are all still closely related, and binary data, instead of a document
<mdeslaur> hope not :)
<cjwatson> mdeslaur: open that URL in a browser, look for the ReleaseNotes/ReleaseNotesHtml entries in the Dist: maverick block
<cjwatson> er, Dist: natty I mean
<Chipzz> cjwatson: for example, http://www.ubuntu.com/download/ubuntu/download isn't hosted on a.u.c either
<mdeslaur> cjwatson: looks fine here...it's the "current" url
<cjwatson> Chipzz: *shrug* this doesn't cause any harm and it arises from the structure of the software involved, I don't see that it's worth rearchitecting
<Chipzz> but I'll shut up and keep my opinion to myself :)
<mdeslaur> I wonder where it got the versioned url from
<cjwatson> the current symlink points to 0.150.5
<doko> TheMuso, pitti: not sure who handles audio stuff in general, please see bug 879434
<cjwatson> mdeslaur: have you done a test install today?
<ubottu> Launchpad bug 879434 in liboggz (Ubuntu Precise) "[MIR] mutagen introduces b-d's on faad2 and liboggz" [High,Confirmed] https://launchpad.net/bugs/879434
<mdeslaur> cjwatson: I'll try a fresh install now to see
<cjwatson> mdeslaur: because that file was last modified this morning
<cjwatson> mdeslaur: so I suspect mvo edited it during the conversation soren pasted above
<mdeslaur> cjwatson: oh, d'uh...sorry, my installs were from yesterday
<cjwatson> right, so I think it was fixed today
<mdeslaur> ok, cool. thanks cjwatson
<cjwatson> sigh, I really must write an actual germinate test suite; this is tedious
<smoser> anyone know why sudo forks and not execs ?
<smoser> ie, 'sudo sleep 1m'
<smoser> then i'll have 2 processes running, the sudo and the sleep.
<smoser> why wouldnt sudo exec sleep?
<soren> To keep track of the pam session.
<soren> If you exec, there's nothing left to close the pam session.
<soren> smoser: ^
<smoser> that makes sense.
<smoser> i was looking at rabbitmq-server, which on start up has like 8 differen't sh -c hanging around
<smoser> (ok, 3)
<smoser> and was trying to get rid of some of them, but i can't get rid of the 'su'
<smoser> thats why i was asking
<soren> Yeah, we have the same problem in OpenStack.
<Daviey> smoser: are you working on the rabitmq-server remove bug?
<soren> The ideal solution (AFAICS) would be if upstart would support setuid'ing on its own.
<smoser> Daviey, well, sort of.
<soren> For now, we have to resort to su which does the same.
<Daviey> smoser: surely that is a binary question? :)
<smoser> well, i was aware of that bug.
<Daviey> smoser: handy, because you raised it :)
<smoser> and that (bug 878597) and bug 878600 was what made me look at it.
<ubottu> Launchpad bug 878597 in rabbitmq-server (Ubuntu) "rabbitmq-server fails to uninstall" [Medium,New] https://launchpad.net/bugs/878597
<ubottu> Launchpad bug 878600 in rabbitmq-server (Ubuntu) "service start rabbitmq-server' does not fully detach from parent" [Medium,Triaged] https://launchpad.net/bugs/878600
<smoser> soren, so this seems like the best i can do:
<smoser> http://paste.ubuntu.com/715116/
<soren> smoser: Yup.
<soren> Unless rabbitmq could learn how to setuid.
<smoser> right.
<soren> Or upstart could.
<soren> Well, either that, or you write a custom wrapper thing to do it, but that's an entirely different kettle of fish.
<cjwatson> https://bugs.launchpad.net/upstart/+bug/586942
<ubottu> Launchpad bug 586942 in upstart "init: support dropping privileges" [Wishlist,Triaged]
<smoser> soren, or modify sudo so it could exec for me (or su to do the same). thats why i originally asked about sudo.
<soren> cjwatson: Oh, so that'll probably have the same sort of issue.
<smoser> but i assumed there was good reason.
<cjwatson> soren: no, I don't think so
<soren> cjwatson: No? How would you take care of closing the pam session?
<cjwatson> Scott isn't saying "setuid needs to have a PAM session", he's saying "use a different keyword (i.e. setuid not user) because the user keyword is going to imply a PAM session"
<cjwatson> basically just a quibble with the text of the bug description
<soren> cjwatson: Ah, right, yes. I meant the "user" directive would exhibit similar behaviour (i.e. the "extra" process hanging around just for this purpose).
<soren> cjwatson: I didn't realise there were plans for both.
<cjwatson> Probably, unless pid 1 learned about PAM (which might be a bad idea)
<soren> cjwatson: YEah, I think it's unsafe to assume that pam modules won't mess things up when closing the session.
<cjwatson> I mean I suppose you could marshal the PAM state back to pid 1 and then it could start a new process just to close the session, but (a) I don't know if that would even work and (b) it sounds like a lot of bother to save a process
<soren> Yeah. It sounds like no fun at all.
<smoser> ok. related question.
<smoser> other than not depending on sudo, is there any reason i would not want to use sudo to change permissions rather than su ?
<soren> su is always present.
<soren> sudo might not be.
<soren> and sudo's config is more prone to being screwed.
<smoser> i dislike the fact that su executes things through sh
<smoser> as root to non-root, sudo is not likely screwed i would think.
<soren> Nope.
<soren> Try it :)
<smoser> yeah, you're right.
<smoser> that does suck.
<smoser> it should just get out of your way.
<smoser> am i right that there is no sane way to get su to execute things without re-shell-quoting like at http://paste.ubuntu.com/715120/
<soren> I'm not entirely sure why it doesn't just use "$@".
<smoser> because su sucks
<smoser> su -c "command"
<smoser> not
<smoser> su -c "command" "arg1" "arg2"
<cjwatson> smoser: su is awful for this.  Personally I use a tiny perl wrapper for this job.
<soren> su -- "command" "arg1" "arg2"  ?
<soren> Wouldn't that work?
<cjwatson> (I used to use start-stop-daemon; that's still OK for things that aren't liable to be installed via debootstrap.
<cjwatson> )
<smoser> su sucks, soren. try it.
<soren> Well, really: su -- "command" "$@"
<cjwatson>     # start-stop-daemon isn't available when running from debootstrap.
<cjwatson> (man-db.postinst)
<cjwatson>     perl -e '@pwd = getpwnam("man"); $( = $) = $pwd[3]; $< = $> = $pwd[2];
<cjwatson>              exec "/usr/bin/mandb", @ARGV' -- "$@" || true
<cjwatson> But modifying rabbitmq to have a drop-privileges option surely wouldn't be that hard.
<cjwatson> <root@sarantium ~># su cjwatson -c echo foo bar
<cjwatson> Sessions still open, not unmounting
<cjwatson> <root@sarantium ~># su cjwatson -- echo foo bar
<cjwatson> /bin/echo: /bin/echo: cannot execute binary file
<cjwatson> Sessions still open, not unmounting
<cjwatson> su really has an awful command-line syntax.
<jamespage> I've switched most of my use of start-stop-daemon to daemon with upstart (although that is not in main)
<cjwatson> <root@sarantium ~># su cjwatson -c 'echo foo bar'
<cjwatson> foo bar
<cjwatson> Sessions still open, not unmounting
<soren> Madness.
<cjwatson> it wants it all in one arg, which is a quoting nightmare.
<soren> So that happens to the stuff after "--" ?
<smoser> cjwatson, so for the perl magic novice.. the stuff up there is going to change perms to the man user ?
<cjwatson> Interfaces designed sometime in the last decade or two tend to be sensibly adverbial and not require differing levels of quoting.
<cjwatson> smoser: yes
<cjwatson> smoser: I should probably change mandb to have a drop-privileges option instead, though, given that it already has all the code for that.
 * smoser imagines cjwatson sitting there thinking "duh, smoser, that was *so* obvious! $( = $).."
<cjwatson> no, I have to look those up too :-)
<cjwatson> there are more friendly spellings of it but they require 'use English'
<tumbleweed> please mark merged: https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/visualvm/813165-formattingTypo/+merge/68469
<mvo> mdeslaur: yeah, I'm really sorry for the trouble with this last night, a new SRU broke it, it used the explicit version to workaround a old issue that launchpad does not copy the release upgrade from -rpopsoed to -updates. but now this is done manually be the archive-admins so the current symlink in -updates works
<smoser> soren, cjwatson. just fyi, i realize that getopt is completely capable of correctly quoting variables for you.
<smoser> so
<smoser> sh -c 'x=$(getopt -s sh -o "" -- -- "$@"); x=${x# --}; exec su -c "set -- $x; \"\$@\""' arg0 echo howdy world
<mdeslaur> mvo: no problem, I just wanted to make sure you were aware of it
<mvo> mdeslaur: indeed, thanks for this, if something like this happen, you can always mail the issue to me too if I'm not on irc :)
<mdeslaur> mvo: cooll, thanks
<soren> smoser: My eyes began watering when I read that. Seriously.
<smoser> well, it works, and its more reliable than the sed in the pastebin i showed earlier.
<smoser> but other than being in /usr/bin, getopt is probably pretty likely to be around.
<soren> "Priority: required" agrees.
<soren> As does "Essential: yes"
<AnAnt> Hello, is there a way to control the logo position in unity-greeter ?
<SpamapS> FreakinInstallMe: uh-huh  is the only one stronger than that
<SpamapS> AnAnt: you probably want #ubuntu ;)
<SpamapS> smoser: Isn't 'getopts' built in to dash/bash ?
<smoser> it is not.
<smoser> oh. wait. getopts is.
<smoser> getopt is not
<SpamapS> smoser: can you make it work w/ getopts ?
<smoser> getopt is IMO actually usable for parsing parameters. but getopts is not.
<smoser> but yeah, maybe you could.
<Chipzz> smoser: heh
<Chipzz> smoser: a page I just read yesterday actually claims the compelete opposite
<SpamapS> smoser: getopts claims to be more advanced than getopt ;)
<SpamapS>             The getopts command deprecates the older getopt(1) utility due to its
<SpamapS>             handling of arguments containing whitespace.
<Chipzz> smoser: getopt might be buggy wrt spaces in arguments, so you shouldn't use it
<smoser> bah.
<smoser> might be.
<smoser> but is not
<Chipzz> is on some OS'es
<smoser> and its not like 'sh' is changing its parsing all that often.
<Chipzz> so don't use it if you want your script to be portable
<SpamapS> smoser: come on you can't make it work with a builtin? ;)
<smoser> SpamapS, they're completely different beasts.
<smoser> the reason that the builtin can do what it does is because it doesn't attempt to understand shell quoting.
<smoser> it uses a global basically.
<DoctorPepper> agateau:  are you here ?
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<DBO> slangasek, can you help me with my flashplayer? it doesn't seem to work with pulse
<slangasek> DBO: apt-get install libasound2-plugins:i386?
<DBO> already done
<DBO> still doesn't work
<DBO> tried installed adobe-flashplugin instead of flashplugin-installer also
<DBO> that just made it not work all together
<slangasek> DBO: this is amd64?
<DBO> slangasek, yep
<slangasek> restarted nspluginwrapper / the browser after installing libasound2-plugins:i386?
<DBO> slangasek, restarted the entire machine
<DBO> slangasek, its a fresh installed too
<DBO> I remember it working once, but after installing my development environment
<DBO> it stopped working
<slangasek> sorry, what do you mean by "development environment"?
 * ogra_ glares at the title of bug 879448
<ubottu> Launchpad bug 879448 in ubiquity (Ubuntu) "during upgrade from 4.11 to 10.11 the command grub-install/dev/sda failed error" [Undecided,New] https://launchpad.net/bugs/879448
<ogra_> i hope that doesnt mean a typoed upgrade from warty to whtever 10.11 might be :)
<Amaranth> *boggle*
<Amaranth> DBO: Wait, you're using a flash that requires nspluginwrapper still?
<Amaranth> Doesn't the partner repo contain a native amd64 package?
<slangasek> it's not yet integrated into flashplugin-installer
<slangasek> DBO: but, if you installed adobe-flashplugin and it still didn't work, I don't know what the problem is
<slangasek> DBO: how did you determine it's not talking to pulseaudio?
<DBO> adobe-flashplugin simply didn't give me flash
<DBO> like chrome didn't think it had flash
<slangasek> heh
<slangasek> you might need to make sure you uninstall flashplugin-downloader as well?
<DBO> okay hold on
<DBO> let me try that
<DBO> as for not using pulse, lets assume I know what i am talking about :)
<DBO> (I do)
<Amaranth> slangasek: Right, I know the downloader package still does 32-bit and nspluginwrapper but adobe-flashplugin in partner is the native 64-bit 11.0 release
<Amaranth> Oh, and I took too long to type that
 * Amaranth goes back to watching paint dry^W^Whis panda board compile
<DBO> slangasek, okay that worked
<DBO> thanks :)
<DBO> you're a champ
<slangasek> ok, good :)
<slangasek> I still don't know why the 32-bit one isn't working for you
<alex-weej> is readahead standard in ubuntu now?
<ogra_> ureadahead is
<ogra_> since several releases
<ogra_> normal readahead was dropped in favor
<alex-weej> ogra_: thanks. is there some documentation anywhere for how it works? or is it a 'Use The Source, Luke' thing? :)
<ogra_> both i think. there should be a blueprint on launchpad and possibly a spec on the wiki for its implementation
<ogra_> beyond that there surely is also source code to inspect :)
<broder> http://ubuntuforums.org/showthread.php?t=1434502 is also helpful
<alex-weej> ogra_: thank you
<alex-weej> broder: also :)
<smoser> cjwatson, so where do you use that perl snippet?
<smoser> it seems odd to add a perl dependency on a pakage just for that, although its very helpful.
<cjwatson> smoser: as I say, in man-db.postinst.  perl-base is Essential: yes so no dependency is required.
<cjwatson> smoser: I do think having an option in the daemon to drop privileges itself is a strictly better approach.
<smoser> yes.
<soakda> i have ubuntu 11.10 and have problem with booting fakeraid (dualboot with windows 7), everything installed like a charm, it even booted after installation to both windows and ubuntu but after updating and rebooting one more time i get kernel panic and message that root= is wrong, didn't get any help on #ubuntu..
<Pici> soakda: This is not a support channel. You'll just need to be patient in #ubuntu, or check out our other support resources.
<Pici> soakda: htps://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<soakda> Pici: ok, thanks
<Daviey> cjwatson: How would you rate the chances of bug 833994 being resolved this cycle?
<ubottu> Launchpad bug 833994 in debian-installer (Ubuntu) "debian-installer does not support https when using with preseed files" [Medium,Triaged] https://launchpad.net/bugs/833994
<Daviey> superm1: can python-mysqldb be sync'd from sid? It seems it includes your fixes, dh_python2 and change to quilt.
<penguin_03> is it possible to re enable module loading after 'echo "1" > /proc/sys/kernel/modules_disabled' ?
<stgraber> penguin_03: no, that's the whole point of this option
<penguin_03> stgraber, assuming you have physical access the the machine there *has* to be a way to disable it though
<stgraber> penguin_03: rebooting it is the easiest way
<penguin_03> thanks
<__keybuk> just had one off those annoying upgrade problems where after upgrade mdadm is picking up /dev/sdb rather than /dev/sdb1 :(
<slangasek> "one of those"?  I thought those were all in the distant past
<__keybuk> slangasek: apparently not
<__keybuk> this was on installing natty
<__keybuk> so it may be fixed in oneiric?
<slangasek> I don't remember any reports of anything like this happening in several years
<slangasek> it's not something anyone fixed in oneiric
<slangasek> TTBOMK
<__keybuk> if you have a partition that fills the entire disk, how does mdadm know to ignore the whole disk?
<cjwatson> Daviey: *shrug* I don't care about it, but if you escalate it in the usual way with a justification then I guess I'll have to bloat up the initrd to do it :-P
<cjwatson> Daviey: I think I checked and Debian wasn't going to do it
<cjwatson> (but that's only a vague memory)
<slangasek> __keybuk: I don't know, but I thought it was solved :)
<slangasek> so if not, well, doh
<cjwatson> __keybuk: I thought that was fixed by using a more modern md format; also the installer deliberately leaves a gap at the end of the disk to avoid ambiguity
<__keybuk> cjwatson: the installer didn't make these partitions, I did\
<cjwatson> in 1.1/1.2 the md superblock is at/near the start of the device rather than the end
<__keybuk> and I didn't leave a gap
<cjwatson> well then :)
<__keybuk> cjwatson: hmm, the mdadm version is 0.9
<cjwatson> yeah, the ambiguity is inherent then unless you leave a gap
<barry> any syncpackage (for fakesync) experts around?
<cjwatson> I can't remember how to deal with the situation where the partition already exists and can't conveniently be shrunk a bit
<__keybuk> I wonder how you update the mdadm version
<slangasek> barry: I know things about syncing, if that counts :)
<barry> slangasek: that's okay, i think i figured it out.  fwiw, after i uploaded python-support 1.0.14ubuntu1 we discussed just dropping the ubuntu delta.  i'llmanually prepare a 1.0.14ubuntu2 that drops it and make it clear in the changelog that next debian upload can do a sync for real
<slangasek> barry: right, that's the thing to do there
<barry> slangasek: cool, thx
<cjwatson> I don't know of a way to change the metadata version in place
<cjwatson> you could probably force the disk to be avoided by tweaking mdadm's udev rule locally
<__keybuk> yeah
<cjwatson> that's probably the simplest local fix (but not generally suitable since some people deliberately use entire disks as components, of course)
<__keybuk> except that gets lost each upgrade
<__keybuk> I suspect that's what I did
<cjwatson> dpkg-divert?
<__keybuk> indeed
<__keybuk> I think I actually dropped a replacement in /etc/udev/rules.d
<cjwatson> or /etc/udev/rules.d/ I guess, you probably remember the details better than I do :)
<__keybuk> but it didn't get copied into the initramfs after upgrade
<cjwatson> ah
<cjwatson> initramfs-tools ought to have a helper function to DTRT there
<cjwatson> (probably doesn't, but)
<__keybuk> ok, a little ENV{DEVTYPE}=="partition" seems to have solved my problem
<bdrung> barry: yes (i wrote the syncpackage fakesync stuff)
<barry> bdrung: thanks, i figured it out though (can't use syncpackage for this particular use case)
<bdrung> barry: fakesync building assumes that the content is the same of the mismatching tarballs
<barry> bdrung: so, here's a new situation.  i'm trying to sync python-peak.rules.  it's blacklisted, so it suggests --no-lp --force, but --no-lp is "not recommended" (lp sync'ing was rejected).  should i just use --no-lp --force?
<bdrung> barry: if blacklisted, use only --force. if this does not help, ask the archive admins to remove this package from the blacklist
<barry> bdrung: okay, thanks
<bdrung> barry: but --no-lp --force is the right way, if it needs a fakesync
<barry> bdrung: nod
<bdrung> barry: the comment is clear to me: http://paste.debian.net/138672/
<bdrung> barry: and it seems to need a fakesync
<barry> bdrung: right, that part makes sense.  it's a little confusing that it's recommending to use --force and --no-lp to override the blacklist, but the manpage warns against --no-lp
<barry> or should i say "seems to recommend"
<bdrung> barry: --no-lp is the only way for fakesync (patches to make that clear are welcome)
<bdrung> barry: --no-lp for fakesync are not discouraged by the admins
<barry> WARNING
<barry>        The use of syncpackage --no-lp, which generates a changes file  to  be
<barry>        directly  uploaded to the Ubuntu primary archive or a PPA, is discourâ
<barry>        aged by the Ubuntu Archive Administrators, as it introduces an  unnecâ
<barry>        essary window for error.  This only exists for backward compatibility,
<barry>        for unusual corner cases, and for uploads to archives other  than  the
<barry>        Ubuntu  primary archive.  Omitting this option will cause Launchpad to
<barry>        perform the sync request directly, which is the preferred  method  for
<barry>        uploads to the Ubuntu primary archive.
<barry>  
<bdrung> barry: fakesyncs are the "unusual corner cases"
<bdrung> barry: patches for better wording are welcome
<bdrung> tumbleweed: ^
<barry> bdrung: gotcha.  i'll think about and file a bug/patch if i can come up with anything better ;)
<infinity> barry: Why not get a new upstream of python-peak.rules into Debian, ask us to remove the blacklist, and be done with the mess? :P
<barry> infinity: well, right now i'm slogging through a ton of packages i touched since oneiric, so i'm trying to do a minimal amount of yak shaving.  please do comment on the bug though if you think that's a better way to go and i will address it later
<infinity> barry: "The bug" being?
<barry> infinity: ah, i thought you were commenting on bug 879708
<ubottu> Launchpad bug 879708 in python-peak.rules (Ubuntu) "Remove blacklist and fakesync 0.5a1+r2707-1" [Undecided,New] https://launchpad.net/bugs/879708
<infinity> Err, we can't remove the blacklist.
<infinity> The reason it's there is because of the mismatched orig.
<barry> infinity: isn't that what fakesync is for?
<infinity> Yes, fakesyncing isn't an LP function.  Or an AA function at all.
<infinity> It's something you do locally to work around breakage.
<barry> infinity: all these differing recommendations seem quite contradictory
<bdrung> infinity: you can remove the blacklist for the fakesynced packgae
<infinity> bdrung: No I can't.
<infinity> bdrung: Because if a -2 lands in Debian, the next autosync will choke on it.
<bdrung> infinity: no, because it has a different ubuntu version
<infinity> bdrung: The entire reason the blacklist is in place is the mismatched orig.
<bdrung> infinity: you wont autosync a version that has -XfakesyncY in Ubuntu, do you?
<infinity> Eww, we actually do that? :P
<infinity> That's new (ish).
<barry> https://wiki.ubuntu.com/fakesync
<infinity> Right, the naming scheme on fakesyncs is new.  I was gone for a year and a half. :P
<barry> infinity: :)
<infinity> Either way.  It's all less hassle if you just update the Debian package.
<infinity> Cause wasn't the Ubuntu one a snapshot that was ahead of the Debian one anyway?
<infinity> Oh, maybe not.
<tumbleweed> IIRC they were uploaded at almost exactly the same time (I rushed the rview so we wouldn't have to leap ahead in Ubuntu, but barry hadn't noticed that)
<infinity> I'm confusing the two -r1234 strings.
<barry> tumbleweed: right, we were like ships passing in the night
<barry> and my apologies for screwing everything up :)
<tumbleweed> it's just a mismatch :)
<infinity> Yeah, it's not the end of the world.
<infinity> barry: Fakesync away.
<infinity> barry: When it's accepted, I'll drop the blacklist, if this shiny new autosync behaviour is indeed the way and the light. :P
<barry> infinity: i'm actually uncertain how to do that now :(
<bdrung> infinity: the naming schema for fakesync is over a year old :)
<infinity> bdrung: Yes, that was in the point when I was not around. ;)
<tumbleweed> bdrung: --no-lp --force
<barry> $ syncpackage --force --no-lp --simulate -d wheezy -r precise python-peak.rules (without the --simulate)... ?
<tumbleweed> err barry
<bdrung> infinity: i is easier to see the fakesync and to avoid problems with the autosync (no blacklist required for fakesync)
<infinity> barry: That should do it.
<bdrung> barry: yes
<barry> tumbleweed, infinity, bdrung thanks, executing now
<infinity> barry: That won't actually sync anything.  Should just generate a nice source package and a .changes for you.
<barry> infinity: fair enough.  i upload that and then it needs to be accepted?
<infinity> barry: It'll accept like any other upload, the archive isn't frozen.
<barry> gotcha, thanks
<infinity> barry: The blacklist doesn't apply to uploads, just actual syncing mechanisms.
<barry> infinity: ah, okay!
<cjwatson> bdrung: 'fakesync' in the version doesn't inhibit autosync - only 'ubuntu' does
<infinity> (If it applied to uploads, maintaining, say, udev, would be awful)
<barry> right, so i dput the -1fakesync1 package
<tumbleweed> barry: yes
<bdrung> barry: please send patches for things in the docu that confuses you
<infinity> cjwatson: See, that's what I thought, but hadn't gone digging.  So, this "fakesync and then remove the blacklist" business is... Crazy talk? :P
<cjwatson> infinity: correct
<cjwatson> fakesyncs still need to be blacklisted, until we can move to something copyPackage-based for autosyncing at which point it will be easier to apply more Ubuntu policy
<infinity> bdrung: ^
<cjwatson> right now, if you remove the blacklist, I'll probably just have to swear and put it back at some later point
<tumbleweed> bdrung, barry: We could add a --fakesync option that does all of the above. Then only --no-lp needs to print scary warnings
<infinity> Yeah.
<bdrung> cjwatson: can the autosync learn to not sync package with fakesync in the version string?
<barry> awesome, thanks guys.  uploaded.  bdrung i will (though not right now ;)
<bdrung> tumbleweed: good idea
<cjwatson> bdrung: I don't want to modify the old-style autosync process any more
<tumbleweed> bdrung: it needs to not autosync, before the first fakesync version exists in Ubuntu
<cjwatson> bdrung: when we switch to new-style copyPackage autosyncing, I'd be happy to make it smarter
<cjwatson> (in that case, there'd be no need to look at the version, it could just compare orig checksums)
<infinity> barry: So, I'm still going to fall back on my initial statement.  Getting a new upstream into Debian and syncing it would be less hassle. :P
<barry> tumbleweed, bdrung agreed, great idea
<barry> infinity: apparently so :)
<cjwatson> new-style autosyncing is presently blocked on LP fixing the inability to credit a copyPackage action to somebody else
<barry> of course, it's all my fault originally for leapfrogging tumbleweed
<cjwatson> (no way do I want all autosyncs listed under my name)
<barry> cjwatson: oh c'mon :)
<tumbleweed> even better, according to discussion a few days ago, Apparently there's a known way to write repacking scripts, that'll produce deterministic output.
<infinity> cjwatson: Think of the karma.
<cjwatson> I was thinking of the mail.
<infinity> ;)
<infinity> You read mail from LP?
<cjwatson> some of it ...
<cjwatson> (actually, perhaps more of the people who might think I in some way cared about those packages)
<mika> hi, we're at the FAI developer sprint and working on Ubuntu LTS support within FAI. Is there an option to get FAI into universe of lucid (it's present in maverick, natty, oneiric and precise but just missing in lucid)?
#ubuntu-devel 2011-10-22
<jbicha> !backports | mika
<ubottu> mika: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<ScottK> Yes, that's what I was about to say.
<blahsphemer> Does the passwd executable change the ownership of any file? cuz it's capability list seems to list: CAP_CHOWN as one of the capabilities
<infinity> It's entirely possible that it does so when it creates backups and copies things around.  Though why it doesn't create with the permissions it wants then, I don't know.
<infinity> (I haven't checked, though, the CAP may be entirely unnecessary)
<blahsphemer> infinity, no. THe cap is necessary. I tried removing the cap and change a passwd, it says Authentication token manipulation error
<blahsphemer> How do I investigate this? As in how do I find out which file it's modifying?
<infinity> strace it.
<infinity> Or read the source.
<infinity> But stracing is the simpler way to quickly find the opens/creates/renames/chowns.
<blahsphemer> infinity, ok
<blahsphemer> infinity, I unable to change passwords if I run passwd using strace. Would you know why?
<blahsphemer> infinity, running from the terminal normally,  am able to change the password, though.
<infinity> Are you doing it as root?
<infinity> stracing suid binaries doesn't work so well.
<blahsphemer> infinity, oh no. I completely forgot that part. I'll do it now.
<blahsphemer> infinity, found it. It chowns /etc/nshadow. Thank you very much
<mika> ScottK: thanks (and also to jbicha who isn't here anymore :))
<asac> hmm. weren't there bzr branches for ppa packages similar to UDD? whats the url scheme for those?
<asac> james_w: i guess you know :) ?
<maxb> asac: I never heard of such a thing
<asac> maxb: kk
<Daviey> infinity: Sync's don't seem to provide karma.. so there is no risk of gaining too much :)
<StevenK> Daviey: If there isn't a bug for syncs not providing karma, please file one.
<Daviey> StevenK: that would imply we care about karma :)
<StevenK> Well, we as in the LP team do.
<erle-> when will there be a fglrx update? who is in charge?
<erle-> maybe a update fixes it
<erle-> repos have version 8.889, amd has version 8.892 released
<infinity> StevenK: I want karma every time I perform queue manipulation.
<infinity> StevenK: But more seriously, I want every queue change audited.
<zub> Hi, what package is reponsible for the distro upgrade dialog - is it update-notifier?
<hyperair> update-manager i should think.
<zub> ah, ok
<zub> http://linux.fjfi.cvut.cz/~zub/Screenshot-Ubuntu%2011.10%20Upgrade%20Available.png
<zub> seems it ignores http proxy, so I'm looking if there's a bug reported for this already
<hyperair> try setting it in /etc/apt/apt.conf.d/
<zub> it is set, come on
<zub> aptitude works ok
<hyperair> ah
 * hyperair shrugs
<zub> and it's set in http_proxy, and even in the gnome thing, whatever that does
<zub> hyperair: sorry :)
<zub> in that window, it's trying to fetch a web page with some info about the upgrade - I think... so it shouldn't be using apt's proxy, but http_proxy or whatever else the gnom proxy setting changes
<zub> but anyway as far as I know, all that's needed was set at that box, web works, apt works
<slangasek> zub: please file a bug against update-manager, yes
<penguin_03> has this patch "DM-CRYPT: Scale to multiple CPUs v3" http://lkml.org/lkml/2010/10/10/44 been applied to any versions of Ubuntu?
<zub> slangasek: ok, thanks for info
<zub> I'm also filing/commenting on some unity bugs
<zub> I've been using it for 1 day and found several issues I believe to be bugs :-(
<slangasek> penguin_03: there's no reason we would have picked such a patch unless it's included in the upstream kernel we're shipping
<penguin_03> do the newer kernels have any parallel dm-crypt support?
<slangasek> no idea
<dajhorn> penguin_03: That patch is in the Oneiric kernel.
<penguin_03> dajhorn, thanks
<dajhorn> penguin_03: Welcome.
<SpamapS> slangasek: https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/876959 ... he's right that the dbgsym packages for the version of mysql 5.1 in lucid-updates aren't on ddebs.ubuntu.com. Any ideas?
<ubottu> Launchpad bug 876959 in mysql-dfsg-5.1 (Ubuntu) "no mysql-server-5.1-dbgsym for security/updates repositorires" [Undecided,New]
<SpamapS> though they are available for the highest version in lucid-security
<slangasek> SpamapS: ICMP redirect pitti
<slangasek> in general the ddeb archive is a mess because there's no LP-driven reference counting; but I'm never clear on what bugs are present at any given time
<SpamapS> pitti: https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/876959 ... he's right that the dbgsym packages for the version of mysql 5.1 in lucid-updates aren't on ddbes.ubuntu.com. Any ideas?
<ubottu> Launchpad bug 876959 in mysql-dfsg-5.1 (Ubuntu) "no mysql-server-5.1-dbgsym for security/updates repositorires" [Undecided,New]
<SpamapS> slangasek: I've had mostly failure when trying to make use of it. :-/
<SpamapS> partial success... but almost always some piece missing
<SpamapS> slangasek: so there's no LP project that is specific to the dbgsym repo?
<SpamapS> was going to redirect the bug to that
<slangasek> ah, I don't know; my point was about soyuz not knowing about ddebs
<SpamapS> oh right
<SpamapS> slangasek: so, the PHP upstreams want us to include PHP 5.4 in 12.04
<SpamapS> slangasek: maybe I'll make the condition that their build process stops smoking crack for 3 months before we do that. ;)
<slangasek> heh
<slangasek> good luck, it's a lifelong addict
<SpamapS> Like taking the weed from snoop
<SpamapS> it wouldn't be PHP if it didn't have the rock
<luist_> can anyone point me a simple .dsc to build a deb package?
<cjwatson> .dsc files are generated by the dpkg-dev toolchain from a source tree; you won't get anywhere at all trying to write a .dsc by hand
<marw> i'd like to assist in development of a project/application, and i know only python. any advice on where to start?
<luist_> oh godâ¦. i have a folder with 1 executable and 1 .desktop file. i compressed them in a tar.gz. how do i make a deb package out of itâ¦ that should be so simple but all the freaking guides i find shows the tons of useless stuff that i dont needâ¦!
<cjwatson> dh_make should get you most of the way there; or I'm sure if you put the .tar.gz somewhere public then somebody could give you the files you need under debian/
<cjwatson> (I would, but need to deal with children's bedtime ...)
<marw> luist_: there is a good video tutorial by a german guy about deb files for py projects
<luist_> marw: link?
<SpamapS> luist_: dh_make will indeed build you a pretty good debian/ dir
<marw> luist_: you're in luck, i saved it. http://showmedo.com/videotutorials/video?name=linuxJensMakingDeb
<cjwatson> python packaging can actually be a fairly complex case and is more than you need if it's just a single executable
<cjwatson> (because of all the complexities around supporting multiple python versions)
<maxb> And the infelicitous profileration of methods of doing so
<maxb> *proliferation
<cjwatson> yes, though that's getting better
<SpamapS> luist_: you probably jus need to run that, and then list the files you want installed in debian/install  like   executable_file /usr/bin      then  exec.desktop /usr/share/applications
<cjwatson> (it did involve the creation of a third method, but the previous two are now deprecated and their use is dropping)
<maxb> Sadly, despite my best efforts, I have yet to eliminate Debian etch at work, so I'm doomed to live with the variety for a while longer :-)
<cjwatson> yep, what SpamapS said
<cjwatson> *etch*?
<luist_> SpamapS: ok nice! but what am i doing wrong here: http://pastie.org/2742190  the dir names seems to be right
<maxb> I know, I know
 * cjwatson passes maxb an archaeologist's hat
<cjwatson> cd hinfo-0.1; dh_make
<SpamapS> indeed
<luist_> oh
<cjwatson> (actually you may need to 'mv hinfo-0.1.tar.gz hinfo_0.1.orig.tar.gz' first)
 * SpamapS recalls similar happy days learning to package his first real C application.. pipemeter.. some 10 years ago :)
<maxb> The one thing to bear in mind about dh_make is that it writes an informative *template* - it might just work even if you don't customize what it emits at all, but I'd strongly recommend deleting all the bits you don't need and ensuring you understand everything you keep
<luist_> SpamapS: ook! whats exactly is this debian/install
<cjwatson> 'man dh_install' will tell you
<luist_> cjwatson: ok :P
<maxb> many of the debian/<something> files are declarative instructions for the dh_<something> program
<cjwatson> but briefly, it's just a declarative way of installing specific files to specific locations, especially useful if your project doesn't already have 'make install' or similar
<SpamapS> if you have a Makefile that understand 'make', and DESTDIR=foo 'make install' ..  it generally works IIRC
<SpamapS> maxb: they're all .ex so they just sit there
<SpamapS> cruft, but thats ok, he's not trying to get included in the distro ;)
<maxb> SpamapS: Agreed, they don't harm the functionality of building the package, but they do obfuscate the new packager's understanding if they don't take the time to delete as appropriate
<SpamapS> thats one reason we started pkgme ... trying to be smarter about building a real package, not just a templated one
 * SpamapS sorely wishes he could raise contributing to pkgme on his priority list
<luist_> i just tried this: /work/HardwareInfo/hinfo-0.1$ dh_make -f ./hinfo-0.1.tar.gz  and i have no idea what happened rofl
<cjwatson> just dh_make, you shouldn't need options
<luist_> cjwatson: well its not like i see any difference here :T
<luist_> cjwatson: is there any default folder where packages should be built, like with rpms?
<cjwatson> no, that's rpm brain-damage :)
<luist_> cjwatson: yep :(
<cjwatson> anywhere under your home directory is just fine
<luist_> cjwatson: well /work/... doesnt seem like my home dir right ;)
<cjwatson> or anywhere you can write to
<luist_> ok
<cjwatson> as I say, if you're in a rush, it's fine to put the tar.gz somewhere and it would probably take an experienced packager five minutes.  it depends whether your goal is to make a package, or to learn how to do it
<luist_> cjwatson: today: make a package   next week: learn how to do it to provide an update :T
 * cjwatson nods
<luist_> yes it would take less than 5 minutes for me to make an rpmâ¦ but im not really in the mood of working on a weekend -.-
<cjwatson> (note, then, that dh_make is one way to create the initial files, but you don't use it to update to new versions, and if you try you'll get confused)
<luist_> cjwatson: well as long as it have a version, i can update right?
<cjwatson> the basic idea of rpm and debian packaging is much the same; install files into a temporary directory, then bundle it up into a package with some metadata attached
<cjwatson> debian packaging is split out into several files rather than using a single .spec file, that's all really
<cjwatson> (and sure, lots of tools and so on, but at the basic level ...)
<luist_> well what exaclty should i do after running dh_makeâ¦ plus i dont now what im doing until now: prepare Debian packaging for an original source archive sounds a bit abstract for me
<cjwatson> the bare minimum for a Debian package is (a) debian/rules (which can be a copy of /usr/share/doc/debhelper/examples/rules.tiny) (b) debian/control with some metadata about your package (c) debian/changelog with version history in a specified format (d) if you want it to be accepted into a public repository anywhere, debian/copyright
<cjwatson> there are usually a few other files as well but that's the guts
<luist_> cjwatson: do i create these inside my folder?
<cjwatson> then 'debuild' builds source + binary packages
<cjwatson> yes
<cjwatson> dh_make should have done that for you
<luist_> cjwatson: no it didnt
<cjwatson> did it produce any output at all?
<luist_> cjwatson: but now a lot of things make sense.. that would replace the .spec right
<cjwatson> indeed
<luist_> cjwatson: nop it didnt
<cjwatson> blink
<luist_> cjwatson: what about hinfo_0.1.orig.tar.gz ?
<luist_> cjwatson: my bad it gave me output
<maxb> luist_: Do you use Bazaar? If so, check out the trivial example package https://code.launchpad.net/~maxb/+junk/example-package
<cjwatson> um, introducing more tools may not be the correct response to a confused person :)
<cjwatson> but you can just look at it on the web
<maxb> or just browse it, there are only 6 files
<cjwatson> yep, that's a good place to start
<maxb> In fact, go here: http://bazaar.launchpad.net/~maxb/+junk/example-package/revision/1 then click "expand all"
<cjwatson> luist_: pastebin the output?
<luist_> cjwatson: oh i just used --createorig and it worked now
<luist_> cjwatson: :)
<cjwatson> I'd have renamed hinfo-0.1.tar.gz to hinfo_0.1.orig.tar.gz, but whatever works
<luist_> cjwatson: http://pastie.org/2742277
<luist_> cjwatson: theres no debian/install :T
<cjwatson> that's ok, create it
<luist_> cjwatson: did with the line: HardwareInfo    /usr/bin
<luist_> cjwatson: or it should be just usr/bin ?
<maxb> I have a feeling either might work, but usr/bin definitely will
<cjwatson> either will work
<luist_> cjwatson: ok also added: hinfo.desktop     etc/xdg/autostart
<luist_> cjwatson: now what :)
<cjwatson> run 'debuild', and if it gives you any errors then fix them up.  repeat.
<cjwatson> (until successful.)
<cjwatson> if it completes successfully, run 'debc' to show what the resulting package looks like.
<luist_> cjwatson: oh god: http://pastie.org/2742328
<cjwatson> you'll need to edit debian/changelog then.  it should be self-explanatory; if it isn't, paste it
<luist_> cjwatson: wasnt it generated by dh_make rofl
<cjwatson> where it apparently says " -- root", it should be something like (example from one of my packages):
<cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Wed, 19 Oct 2011 22:53:40 +0100
<cjwatson> please don't use "rofl" as punctuation, it sets my teeth on edge :)
<cjwatson> it can't autodetect everything - it generates a template for you to edit, hopefully fairly close to usable but it probably does need a few edits to work
<cjwatson> (it's a long time since I actually used dh_make myself, sorry, I've been in this game long enough that I just do it by hand)
<luist_> cjwatson: ok :) btw this is not self-explanatory at allâ¦ the line thats giving me the warning has the same syntax from the example u gave me: -- Max Bowsher <_@maxb.eu>  Sat, 22 Oct 2011 21:58:42 +0100
<cjwatson> the error output you pasted disagrees; it says that the line reads " -- root"
<maxb> The format is quite strict, including the number of spaces in each place, and the date format
<maxb> There is a tool, called "dch" for adding new changelog entries, such that you never need to type those lines manually
<cjwatson> I'm surprised dh_make gets it wrong by default though :-(
<luist_> cjwatson: well i changed to   -- SEE-MG <_@anything.com> Sat, 22 Oct 2011 19:27:23 +0100
<luist_> cjwatson: but same error
<maxb> The *two* spaces between the email and the date are mandatory
<luist_> maxb: oh
<cjwatson> oh meep, bug 875705
<ubottu> Launchpad bug 875705 in dh-make (Ubuntu) "dh_make in Oneiric outpus wrong content to changelog" [High,Confirmed] https://launchpad.net/bugs/875705
<cjwatson> sigh
<maxb> outpus!  irta octopus initially :-)
<luist_> errrâ¦ hinfo-0.1/debian/control at line 5: line with unknown format (not field-colon-value)   http://pastie.org/2742358
<Laney> hah
<cjwatson> yeah, same bug
<cjwatson> 'export DEBFULLNAME="Your Full Name"; export DEBEMAIL=your@email.address'
<cjwatson> rm -rf debian  and start again
<cjwatson> sorry - I'll look into getting this fixed reasonably urgently
<luist_> o.O
<cjwatson> looks like it's because LOGNAME isn't set, perhaps a desktop-level change?
<cjwatson> I bet this is actually a lightdm bug
<luist_> cjwatson: ok.. going to install these now: Could not find a signing program (pgp or gpg)!
<luist_> cjwatson: i can feel im almost there
<cjwatson> you can ignore that
<luist_> cjwatson: really?
<luist_> http://pastie.org/2742381
<cjwatson> it won't have cryptographically-signed the package but it will have generated one, if it got that far
<cjwatson> you can use 'debuild -uc -us' to stop it trying
<luist_> ok good
<luist_> cjwatson: oh god i have a deb package!!
<luist_> cjwatson: thanks a lot :)
<cjwatson> excellent, sorry about that roadblock
<cjwatson> I think I have a fix, just will need to test it a bit and do the paperwork for a stable update
<luist_> cjwatson: its okâ¦ ive learnt a lot here
<cjwatson> (http://paste.ubuntu.com/716397/)
<cjwatson> fix uploaded to precise, doing the writeup for oneiric-proposed now
<Laney> hm, I use lightdm yet have $LOGNAME set
<cjwatson> something in your shell startup scripts?
<Laney> not knowingly
<cjwatson> or even your shell
<Laney> gnome-panel/xmonad instead of unity
<maxb> lightdm/unity here ... and no $LOGNAME
<cjwatson> the bug seemed fairly clear when I looked at the lightdm source
<Laney> yeah, I checked on another unity laptop and it didn't have it
<Laney> zsh must set it
<cjwatson> it does
<cjwatson> ./Src/params.c:703:    setsparam("LOGNAME", ztrdup((str = getlogin()) && *str ? str : cached_username));
<Laney> luverly
<foresto> Hi, all.  I'm packaging a driver module that was removed from ubuntu ages ago. Someone forgot to remove the man page from the ubuntu 'manpages' package when the driver was removed from ubuntu, so my new package (which contains an updated man page) now clashes with 'manpages', and dpkg won't install it. What is the best way to avoid the conflict?
<cjwatson> you could give the man page a slightly different name; perhaps append a short string to the section number
<cjwatson> (called a "section extension" - see e.g. the "3pm" pages documenting perl modules)
<cjwatson> luist_: OK, I've uploaded a dh-make fix to oneiric-proposed as well now (waiting for review) and forwarded the patch to Debian
<foresto> I'm considering that. Is there an officially blessed (by debian/ubuntu) way to handle this?
<cjwatson> luist_: so the next person shouldn't have the same problem, hopefully
<cjwatson> foresto: not that I know of, but I maintain man-db so I guess my advice is about the best approximation to that you'll get ;-)
<foresto> Thanks, cjwatson.  I've filed a bug on the dangling man page, too.
<cjwatson> right, and if that gets fixed then you could rename the page in your package and add Breaks/Replaces on manpages; but until then (and for <= oneiric) I'd definitely advise working around the file conflict
<cjwatson> are the pages basically the same between manpages and your package?  is there a problem with people getting the manpages version if they have that installed?
<cjwatson> oh, you said updated, hmm
<cjwatson> there probably isn't an ideal short-term solution
<luist_> cjwatson: :)
<cjwatson> I suppose you could dpkg-divert away manpages' version, but that feels rather heavy-handed to me
<foresto> Yeah, it's the sk98lin driver, and the one in manpages is ancient. Options have changed since then.
<maxb> ooi, what would be the downsides to having the new package declare a Replaces: manpages ?
<maxb> Or, would that all go horribly wrong the first time manpages was updated after the custom package was installed?
<cjwatson> maxb: I think we did make that work in dpkg a while back (dapper, maybe)
<cjwatson> maxb: but even so, I kind of take the attitude that anything I have to look up in dpkg source to conclusively determine its behaviour may not be a good idea :-)
<cjwatson> I think it's best to avoid file conflicts wherever possible
<DoctorPepper> hi guys !!!
<foresto> I did see the note in the debian policy about using Replaces: when a package takes over a file from another package, but it looked to me like it was intended for use when a new package takes over the duties of an old one. That's not really what's going on here.
<DoctorPepper> agateau:  are you here ?
<cjwatson> foresto: it is used for single files moving between packages too.  I prefer to only use it consensually though (i.e. when the file is actually moved, not just to slam something over the top of an existing package that still ships the file).
<cjwatson> the definition of Replaces is a little confusing as it does double duty depending on whether the packages also Conflict or not.
<foresto> Yes, that usage was hinted as well. Thanks for making sure I didn't miss it.
<foresto> Okay, so I have the man page in a subsection now (4opt), but of course, it doesn't show up unless the user runs "man -a sk98lin" or "man 4opt sk98lin". Anyone know if there's a subsection that would override section 4 as the default?
<foresto> An appropriate subsection, that is.
<foresto> and thanks, cjwatson.
<penguin42> the order seems to be set by /etc/manpath.config
<foresto> Thanks, penguiin42.  Hm... None of the sections preceding 4 really apply, but since it's just a temporary workaround until the ubuntu manpages bug is fixed, maybe I could put the new man page in section 8.
<foresto> (It is a network module after all, and there are plenty of network-admin-related things in section 8.)
<slangasek> foresto: section 8 is "system management commands"; a network module doesn't sound like it belongs.
<slangasek> (cf. man-pages(7))
<foresto> slangasek: Yes, note my comment two lines up:  None of the sections preceding 4 really apply.
<foresto> IMHO, it's more important to avoid giving the user bad instructions on the use of his kernel driver than it is to adhere perfectly to the section categories, and since this is only a temporary workaround and only necessary due to a bug in the stock manpages, I think abusing section 8 a little is warranted.
<foresto> In other words, I'd rather annoy someone for bending the man section rules than really screw someone by leading them to render their system unbootable.
<infinity> foresto: Why not just fix the manpage shipped in manpages?
<slangasek> foresto: well, if you're just putting it in a section where it doesn't belong as a workaround, rationalizing which section is less bad than the others to abuse is unnecessary :)
<slangasek> to someone who cares about the sections, it'll be in the wrong section; to someone who doesn't, any section will do
<foresto> slangasek: heh... point taken. I'm just trying to do this as well as I can.  :)
<foresto> infinity: The bug is already filed. I don't have the power to alter the official manpages package, and I don't think anyone has the power to retroactively do it on packages that have already "shipped".
<infinity> Well, we can push updates, if it matters deeply.
<infinity> But you could just dpkg-divert the manpages' copy out of the way too.
<foresto> Your suggestion would make sense if my package was not going to be released until manpages is fixed. I'm releasing in a PPA though. Today.
<foresto> We talked about dpkg-divert a couple hours ago. cjwatson didn't like the idea.
<infinity> He just said "that feels heavy-handed".
<foresto> Yea.
<infinity> It's still more correct than throwing the manpage in the wrong section to force it to have priority. :)
<infinity> I'm pretty sure he didn't suggest that either. :P
<foresto> Actually, he suggested using a subsection.
<infinity> Right.
<foresto> A subsection  to the existing section doesn't solve the problem.
<infinity> But then you disliked that because it won't sort the way you want.
<foresto> No.
<foresto> Because it leaves the average user with bad instructions on configuring rather delicate part of his system.
<infinity> It's a NIC driver, not a nuclear reactor.
<infinity> But yeah, having the right info is nice.
<infinity> dpkg-divert still sounds like the right solution to me for a third-party package that wants to overwrite files without overwriting.
<infinity> Which is, in the end, what you're after.
<foresto> It's very possibly the user's only convenient connection to the net, which means a misconfiguration would leave him unable to easily find out how to fix it.
<foresto> To be fair, I do see your point.
<foresto> dpkg-divert seems heavy-handed to me too, but I'll consider it.
<infinity> Well, it's the "right" solution to the problem.
<infinity> Having manpages in the wrong section thwarts people like me who read by section intentionally.
<foresto> No wonder you're pushing so hard for it. :)
<infinity> For instance, I'm used to typing "man 2 open", and if I ever read manpages for kernel modules, I'd probably instictively read "man 4 sk98lin".
<infinity> So, I'd still get the wrong info if you shove it in section 8.
#ubuntu-devel 2011-10-23
<infinity> That said, I doubt there are many people who look for kernel module manpages anyway, so the entire discussion may be rather moot.
<infinity> But that's just a hunch.
<foresto> I suspect you are in the minority there, and that you don't use a Marvell Yukon chip anyway. Like I said, I'll give it some thought.  This really is taking way more time than I intended to burn on my weekend, just for a private package that few people will use.
<penguin42> is there a way to get crichton to capture more of the ubiquity traceback; the python traceback is so long it doesn't seem to be unusual for it to miss off the previous diag of the command that failed
<ricotz> tgall_foo, hello
<ricotz> tgall_foo, i saw you packaged libjpeg-turbo, why isnt it replacing the header files too which are needed to use the new colospaces
 * nonix4 ponders where to file a wishlist bug against >100 packages... apt-cache rdepends libusb-0.1-4 to be exact. Regarding porting to libusb-1.0 & thus reducing amount of electricity used worldwide a bit.
<micahg> nonix4: you'd probably want a transition rather than bug reports, you might want to bring that up on the mailing lists (ubuntu-devel and ubuntu-release) as there's already a lot of work to do this cycle
<penguin42> pitti: Why did you put bug 873058 into nvidia-common; it seems to be fglrx ?
<ubottu> Launchpad bug 873058 in nvidia-common (Ubuntu) "Jockey fail to install binary ati driver (post release) version" [Medium,Confirmed] https://launchpad.net/bugs/873058
<citybong__> i want to upload a screenshot at http://screenshots.ubuntu.com/ .. my app Wallch is in USC at ubuntu 11.10 but i can't see my app in the packages list here (http://screenshots.ubuntu.com/upload). it must be outdated.. any ideas?
<tumbleweed> citybong__: I'd assume that screenshots.ubuntu.com isn't using the right release of Ubuntu. No idea who maintains it though. /me waits for someone in canonical, who does
<citybong__> at thei about page ( http://screenshots.ubuntu.com/about ) they are giving some link from where they have their packages.. still can't see my package there
<citybong__> their^
<tumbleweed> citybong__: that's because oneiric universe isn't one fo the repositories
<corecode> hi
<corecode> how would i update a package maintained in bzr?  lots of file shuffling and copying of debian/ ?
<tumbleweed> corecode: http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version ?
<corecode> thanks
<corecode> seems so hard to find every time i need it
<corecode> how would i do that for svn repos?
<corecode> slim, the package in question, didn't release a new tarball since
<tumbleweed> corecode: merge mode or not?
<corecode> whatever is applicable
<tumbleweed> doesn't look like it's maintained in SVN: http://packages.qa.debian.org/s/slim.html
<tumbleweed> (at least, there is no Vcs-Svn header
<tumbleweed> are you talking about the debian packaging being maintained in SVN, or the upstream source?
<corecode> upstream is
<corecode> well, it looks like it is in git, in fact, but their website has a svn repo
<corecode> http://developer.berlios.de/svn/?group_id=2663
<tumbleweed> corecode: build a tarball the same way that upstream builds it (or just svn export / git export if you can't work that out), then use uupdate to update the debian packaging
<corecode> ok
<corecode> thanks
<tumbleweed> some packages have an automated way to build the latest SVN/git/whatever HEAD, but this one doesn't
<corecode> yea
<corecode> ok, that worked, thanks
<Daviey> jbicha: Hola
<Daviey> jbicha: Are you planning on working on bug 875818?
<ubottu> Launchpad bug 875818 in dnsmasq (Ubuntu) "dnsmasq sync introduced new non-main depends, causing dep-wait" [High,Confirmed] https://launchpad.net/bugs/875818
<jbicha> Daviey: I don't know much about dnsmasq, I can try to file MIRs if needed, all I did for that bug was verify that the Ubuntu diff wasn't needed any more
<Daviey> jbicha: Oh sure.  I wondered if you wanted to follow through with it.  If you don't, let me know :)
<luist_> hey guysâ¦ im using ubuntu 11.10 in a live usb (just going to run 1 simple qt app) and i'd like to make it lighterâ¦ what can i unninstall to make it boot faster and use less space in the disk??
<arand> !support | luist_
<ubottu> luist_: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<luist_> hey guysâ¦ i built a deb package with dh_make + debuild. Now i changed the binary and want to increase the release, but i cant find out how to do itâ¦ any help? its still generating the package as 0.1-1
<tumbleweed> luist_: add a new changelog entry (dch makes this easy)
<luist_> tumbleweed: ok more details please? :P
<tumbleweed> run "dch -i"
<luist_> tumbleweed: hmâ¦ this is my changelog if it helps: http://pastie.org/2746656
<luist_> oh i got it now thanks :)
<tumbleweed> :)
<leex> hi I have "i   ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems" installed, nevertheless I get "no such file or directory: ./adb" and adb is a "adb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped" application, what else do i need except for ia32-libs?
<leex> well of course I am running a 64bit system, ubuntu 11.10, and I am trying to get the android sdk to work with eclipse
<tumbleweed> leex: ldd will tell you what it's looking for
<leex> ldd adb not a dynamic executable
<tumbleweed> probably a shell script that calls an executable
<leex> file adb adb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
<leex> tumbleweed: there is no 64bit version of the android sdk out there and no ubuntu ppa, so I have to use the provided 32bit sdk
<maco> leex: no such file or directory sounds like youre giving the wrong path to reach adb
<leex>  ./adb ;)
<maco> and is it chmod +x?
<leex> -rwxrwxr-x 1 leex leex 156K 2011-10-23 19:00 adb*
<leex> if it helps: Linux alpha 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux and: i   ia32-libs, so it is installed
 * leex whispers: Shibboleet
 * maco snorts
<leex> the funny thing is, it works on my other arch machine :S
 * ion engraves: Elbereth
<leex> what bugs me is that file tells me adb would be dynamically linked and ldd tells me that it is not
<stgraber> leex: the "no such file or directory" in that case means that your system is 64bit only and is lacking a 32bit version of the libc required to execute that file (yeah, the error is weird)
<leex> stgraber: and the libc is not part of the ia32-libs package?
<leex> i A libc6-dev-i386                  - Embedded GNU C Library: 32-bit development
<leex> i A libc6-i386                      - Embedded GNU C Library: 32-bit shared libr
<stgraber> ok, that's weird :)
<leex> stgraber: yeah, that's what brought me here ;)
<stgraber> leex: what's the output of "file adb"?
<stgraber> got it sorry, didn't scroll enough :)
<leex> was just about to paste it again ;)
<stgraber> hmm, can't reproduce your problem here. I'm running a 64bit only system, I indeed get the "no such file or directory" on a test binary, then I install "libc6:i386" and it works as expected
<leex> the same sdk (same md5sum) works on my arch
<stgraber> leex: can you try installing "libc6:i386", the multiarch version of the libc6?
<leex> stgraber: ok, give me a second
<leex> stgraber: :) ymmd!
<leex> thanks stgraber and everyone else too
<stgraber> np
<luist_> hmâ¦ if i tell my debian/install to install a file in a folder that doesnt exist, does it create the folder for me?
<JontheEchidna> yep
<luist_> yay
<slangasek> leex: yes, that error indicates you had libc6:i386 installed at one time (recently) and then removed it - since libc6:i386 and libc6-i386 both try to own the 32-bit ld.so, and libc6:i386 Replaces libc6-i386, the linker disappears when you remove libc6:i386.
<slangasek> (this is a known bug that should be fixed for precise)
#ubuntu-devel 2012-10-15
<TheMuso> c
<jamin> you guys concerned with regressions for non-default packages?  such as xfce
<micahg> jamin: #xubuntu-devel for xfce* packages
<jamin> micahg, cool will let them know.
<mfisch> I'm working on a bug and the filer left one of the repro steps as "install any package which adds a system user", anyone know any off hand?
<mfisch> perhaps davfs2
<elky> mfisch, postgres?
<mfisch> I'll try it
<mfisch> davfs2 also worked
<mfisch> thanks elixey
<mfisch> stupid tab, thanks elky
<elky> yw
<pitti> Good morning
<pitti> doko_: I didn't reject it, it just didn't seem useful/appropriate for an SRU at that time; but it seems some third-party packages do need it, so fine for me
<pitti> doko_: I didn't promote/demote any package
<dholbach> good morning
<pitti> dholbach: guten Morgen, wie gehts?
<dholbach> hey pitti - sehr gut - und bei dir? allet jut?
<pitti> dholbach: jau, danke! had a nice relaxing weekend
<dholbach> great :)
<dholbach> hyperair, happy birthday :)
<hyperair> dholbach: thanks :)
<Techna_Rave_Pony> Hello?
<pitti> doko_, stokachu: FYI, gdb has waited in the precise-proposed queue for over a week
<dholbach> diwic, hey - how are you doing?
<dholbach> diwic, I got a USB sound card a few days ago and plugging it in and having it immediately activated for sound works great. do you know if there's plans to also make the sound indicator and volume controls use a newly plugged in soundcard?
<diwic> dholbach, hi! you mean activate a newly plugged in card to be the default input and output?
<dholbach> yes
<diwic> dholbach, because the sound indicator and media keys follow what you set as default in gnome sound settings.
<dholbach> I'm not sure if that's feasible in every single circumstance, I just found myself using the audio preferences a couple of times before controlling volume and everything
<diwic> dholbach, that's a design question. And one that sounds simple but it quite complex under the hood.
<dholbach> yes, I can imagine :-/
<diwic> dholbach, e g, upstream has the idea of role-based stuff, e g phone calls in your headset and music through your speakers
<xnox> dholbach: but in the sound prefs, I can select the new usb card as default and then control it from the indicators & media icons...
<dholbach> in any case I'm happy that it generally works, even if I have to use the gnome sound settings more often than I'd like :)
 * xnox not great but....
<dholbach> xnox, yes that works for me too - it's just that I have to do it whenever I plug it in :)
<dholbach> diwic, ah, that might be interesting indeed
<diwic> dholbach, add to that the kernel does not give us a clear signal after resume, so we don't know if we just plugged in the sound card right after resume, or if it showed up as part of the resume process
<dholbach> in any case it's not a huge deal - I just wanted to hear what is planned :)
<xnox> dholbach: time for you to learn udev rules & write one which will flip the setting for you. =)))))
<dholbach> xnox, yes, so much to learn :)
<diwic> dholbach, btw, this is one of the discussion topics on the pulseaudio mini-conference, colocated with UDS :-)
<dholbach> excellent!
<diwic> xnox, dholbach, as an option you can add "load-module module-switch-on-connect" to your /etc/pulse/default.pa
<dholbach> alright, I'll note that down and experiment with it
<diwic> I think it is shipped by default
<dholbach> thanks a lot diwic
<diwic> but it isn't activated by default because it would interfere with the rule-based stuff
<dholbach> right
<jamespage> stgraber, around? I have an iscsi root query re bug 1057635
<ubottu> Launchpad bug 1057635 in Ubuntu "initramfs does not use iscsiroot device presented by ipxe" [Undecided,New] https://launchpad.net/bugs/1057635
<stgraber> jamespage: going for lunch now, I'll be back in 30-45min
<jamespage> stgraber, ok - give me a ping when you are back
<jamespage> ta
<stgraber> jamespage: I'm back
<jamespage> stgraber, hey!
<jamespage> stgraber, so - bug 1057635
<ubottu> Launchpad bug 1057635 in Ubuntu "initramfs does not use iscsiroot device presented by ipxe" [Undecided,New] https://launchpad.net/bugs/1057635
<jamespage> stgraber, slightly odd-ish case in that I use ipxe to directly sanboot from iscsi volumes, rather than using a tftp accessible kernel and initrd
<jamespage> within the initrd the iscsi initiator does not appear to be configured; so iscsistart stuff fails;
<jamespage> I can work around it by specifying it a) on the commandline in grub (iscsi_initiator) or b) adding it to /etc/iscsi/iscsi.initramfs and updating accordingly
<jamespage> stgraber, any thoughts?
<stgraber> right, so the question is what happen if you add iscsi_initiator on the boot command line when booting that system without iscsi
<stgraber> basically we don't want to regress the case where someone dumps their iscsi disk in a VM or standard system, IIRC that's why we don't put the iscsi_initiator in grub's config
<stgraber> but if the initramfs detects that case and just ignores iscsi_initiator in such case, then it should be fine to just have iscsi_initiator set in grub too
<jamespage> stgraber, I think that is entirely appropriate; however surely it would be better to set it up in the initramfs?
<jamespage> stgraber, that way its all contained to open-iscsi; and does not pollute grub
<stgraber> indeed, if we can just get rid of the boot parameter completely, that'd work too
<jamespage> stgraber, well it appears to work if I add it manually and update
<jamespage> stgraber, hmm - odd - TBH I'm not sure why its not actually working
<jamespage> stgraber, if I force a manual boot by specifying iscsi_initiator and then just update the initramfs it all works again...
<jamespage> stgraber, it feels like /etc/iscsi/initiatorname.iscsi is not making it into the initramfs during install
 * jamespage digs more
<jamespage> stgraber, eureka! I see the issue; the initiator is not generated until first start of open-iscsi
<jamespage> so its "Generated=Yes" when the initramfs gets built
<stgraber> jamespage: oh, fun
<jamespage> stgraber, looks like this change "Generate the random initiatorname during postinstall rather than in the init script." got dropped on last merge
<stgraber> doh, so my fault again right? :)
<stgraber> we'll really need to forward those changes to Debian or the next merge will be as much of a pain as the previous one...
<jamespage> stgraber, lol
<jamespage> agreed
<jamespage> stgraber: I've stuff details in that bug report - are you OK to fix? feels like something that needs fixing for release
<stgraber> jamespage: if it's easy for you to fix, I'd prefer that you fix it and I do the review once it's in the queue (with my release team hat on). Otherwise I can certainly find some time to do it and nag someone else on -release to do the review
<jamespage> stgraber, OK - on it now
<jamespage> stgraber, just uploaded to quantal-proposed queue
<stgraber> jamespage: thanks
<lamont> what package should I use for filing a bug that when I grab a window border and drag to resize the window, it gets horribly confused if the mouse moves before it gets around to noticing position, and suddenly I'm dragging a marker about an inch away from where the border of the window is (and the window never catches up to the cursor) (did that sentence even make sense?)
<tsimpson> lamont: probably compiz
<lamont> tsimpson: ta
<doko> jodh, so was upstart just build related?
<jodh> doko: I believe so - cannot force the failure on scheat.
<cjwatson> SpamapS: Do you guys have any idea what's happening with the zookeeper/armhf build failure?
<cjwatson> SpamapS: I don't really want to remove it since it's a build-dep of juju
<jdstrand> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
 * dholbach hugs jdstrand
<jdstrand> heh
 * jdstrand hugs dholbach :)
<dholbach> :)
<cjwatson> jamespage: oh, any luck with eigenbase-resgen?
<mvo> ev: is there a way to get instance for a problem from errors.ubuntu.com by version? i.e. I suspect that bug #1044141 is fixed or a different error with a similar backtrace but to be sure I would need some instance of the bug with the most recent versions or date. is there a way to get that?
<ubottu> Launchpad bug 1044141 in software-center (Ubuntu) "software-center crashed with UnicodeDecodeError in __str__(): 'ascii' codec can't decode byte 0xc3 in position 29: ordinal not in range(128)" [High,Fix released] https://launchpad.net/bugs/1044141
<xnox> Laney: you are briliant =)
 * Laney gets nervous
<Laney> can xnox hear me singing along to this song?
<xnox> Laney: maybe...
<xnox> Laney: actually I was about reproducing bug 1057690
<ubottu> Launchpad bug 1057690 in ubiquity (Ubuntu) "ubiquity crashed with KeyError in partman_dialog(): 'method_choices'" [Medium,Confirmed] https://launchpad.net/bugs/1057690
<Laney> oh that
<Laney> yeah it's annoying :P
<xnox> Laney: basically the partition is locked, and you shouldn't click it. /me did disable the plus button, but not the double click action
<Laney> what should I have clicked on?
<Laney> the other one?
<Laney> doesn't sound like Brian was doing that, so perhaps it can be triggered in other ways too
<xnox> Laney: well it's locked, so you can't edit that one, instead you should edit the loop mount on the top =)
<Laney> so very clear ;)
<xnox> Laney: and by locked, I mean there isn't even an unlock button.... partman doesn't have it & I didn't code it yet.
<superjoe> how hard would it be to convince you guys to upgrade this package to a newer release before QQ comes out? http://www.ubuntuupdates.org/package/core/quantal/universe/base/mpd
<xnox> Laney: "anyone familiar with d-i interface will feel right at home"
<Laney> also the automatic partitioner is a bit stupid when the drive is small
<Laney> it creates a / which it can't installed onto
<Laney> s/installed/install/
<Laney> due to being too small
<xnox> Laney: funny. It should check the prepare step and if that passes it should work. How small are we talking here?
<Laney> 8G
<Laney> it made a 2.7G /
<Laney> and the error message told me that /I/ created it too small!
<xnox> Laney: and how much RAM did you give your VM     :-?
<Laney> err
<Laney> xnox: 8G also
 * Laney tosses RAM around like confetti
<micahg> superjoe: you can request a backport to QQ once it gets into R
<micahg> (or now if you really want to)
<xnox> it works fine with 8GB drives here for me.... unless it created a (8 - 2.7G) ~= 5.3G swap. Aha. So it tried to go for 100% * RAM swap, but it had a minimum hard-code at 2.7 for / which is no longer enough.
<xnox> Laney: can you file a bug about it?
<superjoe> micahg, could you direct me to where I might do that? do I send an email to a mailing list?
<Laney> xnox: clever. Will do
<Laney> I assume you don't need logs for that?
<micahg> superjoe: https://wiki.ubuntu.com/UbuntuBackports
<Laney> well ...
<Laney> that package looks to not be in sync
<superjoe> thank you micahg
<xnox> Laney: no logs, text only. just make sure you include "tossing RAM around like confetti" in the bug report please =)
<Laney> so I'd check if it can be a straight backport from anywhere
<Laney> xnox: ack :P
 * xnox score update from the field of play: Laney 2 - 0 Partman
<Laney> test installs are fun
<Laney> xnox: bugs #1066964 (I didn't manage to use the keyword, soz)
<ubottu> Launchpad bug 1066964 in ubiquity (Ubuntu) "Auto partitioner can create a root partition which is too small" [Undecided,New] https://launchpad.net/bugs/1066964
<tkamppeter> slangasek, hi
<slangasek> tkamppeter: hey there
<tkamppeter> slangasek, I have uploaded a possible fix for bug 1034045 to quantal-proposed. It is not yet accepted. Can you test this as soon as possible.
<ubottu> Launchpad bug 1034045 in dbus (Ubuntu) "cupsd assert failure: *** glibc detected *** /usr/sbin/cupsd: free(): corrupted unsorted chunks: 0x00007f3dc478c0f0 ***" [High,New] https://launchpad.net/bugs/1034045
<slangasek> tkamppeter: I can probably get it into -proposed and test it today; though I don't think this is something we want to respin the CDs for, so don't panic if I don't get to it :)
<jdstrand> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tkamppeter> slangasek, Zero-Day-SRU would be good enough. If you quickly move it into -proposed and test it, we get it quickly into -updates for a zero-Day-SRU.
<slangasek> yep
<tkamppeter> slangasek, and in the positive case Apport will stop saying "Good Morning" to you ...
<slangasek> quite :)
<pitti> soren, kees, mdz, stgraber: ready for TB meeting in a bit? still waiting for the previous meeting ot finish
<stokachu> is gnome-keyring out of sync when the code branch shows version 3.2.2 with last modification @ 4/26/2012 and the actual built package is 3.6.0 last modified on 9/27/2012?
<pitti> stokachu: yeah, unfortunately a lot of UDD branches often go out of sync
<stokachu> i was under the impression to alway swork from the latest dev branch though is this not the case during this time?
<stokachu> and where would i find the latest code commits that show where gnome-keyring 3.6.0 was imported in the development branch
<kees> pitti: yeah
<stokachu> do i need to open a bug about the branches being out of sync for gnome-keyring?
<pitti> stokachu: you can also ping james_w and ask him to kick it
<stokachu> ah ok
<pitti> stokachu: for now I suggest the old way and apt-get source/change directly
<stokachu> james_w: ping
<stokachu> pitti: ok ill look into that
<stokachu> i just like my workflow :D
<james_w> hi stokachu
<stokachu> james_w: hey there, was curious if you have some spare cycles to sync gnome-keyring branches?
<stokachu> the quantal one is showing version 3.6.0 but the latest branch commit doesn't
<tkamppeter> slangasek, did you test my new cups package?
<slangasek> tkamppeter: all in good time
<tkamppeter> slangasek, sorry, I only asked because you moved around status bits of the bug report.
<slangasek> tkamppeter: yes, I'm cleaning up the state of the bug wrt the SRU process :)
<stokachu> james_w: thanks for getting that synced up
<james_w> stokachu, np
<stgraber> pitti: oops, sorry for that, in Europe this week and completely forgot to check for my evening meetings as my phone was dead and I only just got back now...
<slangasek> hggdh: server images being respun for maas
<slangasek> (bug #1065763)
<ubottu> Launchpad bug 1065763 in maas (Ubuntu) "UI URL displays "200 Error" page after CD install" [Critical,Fix released] https://launchpad.net/bugs/1065763
<slangasek> barry: is bug #1066883 the same as your video-on-mac bug?
<ubottu> Launchpad bug 1066883 in xorg (Ubuntu Quantal) "Fatal server error: Can not run in framebuffer mode on reboot" [Undecided,New] https://launchpad.net/bugs/1066883
<barry> slangasek: i don't think so.  i never see an error message, just blank screen
<slangasek> alrighty
<slangasek> figured it was worth asking
<barry> yep :)
<slangasek> since the reporter mentions different behavior on first vs. second boot
#ubuntu-devel 2012-10-16
<pitti> stgraber: no worries
<pitti> good morning
<dholbach> good morning
<Laney> hm, the e.u.c graph hasn't updated in 5 days
<cjwatson> Laney: it has ... *drumroll* ... an error
<cjwatson> quis custodiet ipsos custodes?
<Laney> Host errors.errors.ubuntu.com not found: 3(NXDOMAIN) :(
<xnox> Laney: I heard that ev was calculating / updating the graph in a "semi" automatic way, e.g. by computing it somewhere and pushing the result.
<xnox> ev: are cron jobs fixed?! =)
<brendand> does anyone know difference between 'NO_PROXY' and 'no_proxy'?
<cjwatson> The latter is an environment variable I've heard of; the former isn't
<marga> Is this an appropriate channel to ask upstart questions?  I need to know the difference of having an "exec" line alone in the file and having it inside a "script" block (no pre-start or post-stop, just script)
<brendand> did i really need to specify 'and no smart answers' :)
<cjwatson> brendand: Um, I thought that was a perfectly straightforward answer.
<cjwatson> marga: The latter will involve an unnecessary /bin/sh process that then execve-s (or similar) the thing you actually wanted to run, rather than having upstart exec it directly
<cjwatson> brendand: IOW, without further context, I would have assumed that NO_PROXY was an error, perhaps influenced by the way the *_proxy environment variables are curious anomalies in being lower-case.
<marga> cjwatson, ok, but I need to pass some env variables to it.
<cjwatson> (I don't know the history behind that.)
<marga> I'm going to go paste something.
<cjwatson> marga: Why not use 'env'?
<cjwatson> The Upstart stanza, I mean, not the command
<marga> cjwatson, just let me paste this and you tell me how to make it better.
<cjwatson> Sure
<marga> http://paste.ubuntu.com/1282738/
<marga> The thing is, if I add my stanza like that, upstart gets very angry and refuses to start or stop anything.
<cjwatson> Ah, you need to compute the environment variables; that's trickier
<cjwatson> OK, I'll work something out for you, few minutes
<cjwatson> Your basic problem is that you've confused fork tracking
<marga> Ok...
<cjwatson> marga: I don't think that's the whole file; can you show me the whole file, please?
<brendand> cjwatson, it seems that all proxy env variables have both an upper and lower-case form (https://bugs.kde.org/show_bug.cgi?id=54898) ?? how confusing
<ubottu> KDE bug 54898 in kcmproxy "implement NO_PROXY in preset environment variables proxy configuration" [Normal,Resolved: fixed]
<cjwatson> brendand: I have never heard of that.
<marga> I was reading the cookbook, which I found very interesting, but I still can't figure out why upstart stops working
<cjwatson> Perhaps it's something KDE made up.
<cjwatson> Note that the w3.org reference quoted there has no mention of upper-case forms.
<brendand> cjwatson, i'm not on kubuntu, fyi
<cjwatson> But of course environment variables are all just conventions of varying strengths.
<cjwatson> brendand: Use the lower-case forms and ignore these alleged upper-case forms.
<brendand> cjwatson, i wonder where the upper-case form is getting set though?
<cjwatson> brendand: Nowhere, quite possibly :-)
<marga> cjwatson, ok, 1 min.  I think the rest is just the original /etc/init/gssd.conf, although I'm not totally sure
<brendand> cjwatson, something has set it, without my knowledge
<marga> http://paste.ubuntu.com/1282741/
<cjwatson> brendand: Could be anywhere
<brendand> cjwatson, exactly
<cjwatson> But I doubt it's terribly interesting
<cjwatson> Anything can set whatever environment variables it likes, with or without any meaning
<cjwatson> marga: Yeah, so 'expect fork' means that Upstart tracks the first process in the main script
<cjwatson> Running dpkg-query and dpkg --compare-versions throws that off
<marga> ok.
<marga> Is there a way to fix it?
<cjwatson> Can you not do this with a dependency instead, and lose the dpkg* calls?
<marga> No, this file is distributed to the clients via puppet.
<cjwatson> Otherwise, the only way I can think of to do this is to move the dpkg* calls to the pre-start script and have it write out a temporary file which is then sourced by the main script
<cjwatson> Although the temporary file would have to be in a fixed location
<marga> But wouldn't sourcing have the same effect?
<cjwatson> No
<cjwatson> Sourcing doesn't fork a subprocess
<marga> ugh, this is ugly
<cjwatson> marga: Regard it as the cost for getting rid of the ugliness of pid files :-)
<marga> Uhm, it's saying that the pre-start process terminated with status 1.  I already have initctl logpriority in 1.  Is there anyway I could find out WHY it's finishing with status 1?
<marga> logpriority in debug, I meant
<cjwatson> marga: set -x at the start, and look at the logs?
<cjwatson> (the start of the pre-start script)
<marga> ok, that would have been better.  I used logger on each line.
<marga> So, now it works when the flags are empty, but it hangs when there are flags.
<marga> This makes me miserable...
<marga> I'll paste how it looks now.
<marga> http://paste.ubuntu.com/1282778/
<marga> What did I do wrong this time?
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<cjwatson> marga: Use '.' not 'source'
<cjwatson> 'source' is a bashism
<cjwatson> marga: 'export EXTRA_FLAGS' is useless
<cjwatson> Oh, actually you initialise that, never mind.  You could drop the export and make it just env though
<marga> ok.  That was in the cookbook.
<cjwatson> I think just 'env EXTRA_FLAGS='
<marga> What's the difference between env and export?
<cjwatson> 'man 5 init' documents it
<marga> ok, thanks.
<cjwatson> So, I don't totally understand why it hangs, so I'm not sure that'll fix it
<cjwatson> Maybe jodh can take over if that isn't enough; I have two bugs I need to be fixing urgently
<marga> Ok, thanks a lot for the help!
<marga> Good luck with your bugs
<jodh> marga: do you see anything in /var/log/upstart/<job>.log? when you say it hangs, is a rpc.gssd process actually running and if so with which flags?
<marga> jodh, I just rebooted (once it hangs, nothing I do will make it right again, except a reboot).  Just a moment
<jodh> marga: does it hang on boot or when you attempt to start the job manually?
<marga> It hangs when I do something that upstart doesn't like...
<marga> I mean, if I modify the file in some ways, it hangs on start/stop
<marga> But not on boot.
<jodh> marga: when you attempt to start it manually, are you sure there isn't already a rpc.gssd process already running?
<marga> Yes
<marga> I found the bug
<marga> It was a shell escaping bug
<jodh> marga: that should have been logged in /var/log/upstart/<job>.log
<marga> It was in the upstart log that you mentioned.  I didn't know about it till now
<marga> I was looking at the syslog which wasn't helpful at all.
<marga> Now I know better.
<marga> Thanks.
<jodh> marga: also, if you'd run 'init-checkconf job.conf', that would have given you an error.
<marga> No, it was a more convoluted syntax error
<cjwatson> Oh?  I didn't spot that ...
<marga> I am echoing into a file and then sourcing it, and I'm missing some escaping quotes
<marga> cjwatson, no, because it was not in the original paste. My bad.  I don't have a -e capable rpc.gssd, so to test it, I was using -t 600
<cjwatson> I didn't see anything that clearly required quotation
<cjwatson> Ah
<marga> And I didn't escape the space
<cjwatson> Yeah, so echo "EXTRA_FLAGS=\"${EXTRA_FLAGS}\"" then
<marga> Right.
<cjwatson> (or echo "EXTRA_FLAGS='${EXTRA_FLAGS}'")
<marga> Thanks a lot cjwatson and jodh !
<dholbach> Riddell, are you planning to do another kubuntu-docs upload before release?
<dholbach> I saw there's https://code.launchpad.net/~bkerensa/ubuntu/quantal/kubuntu-docs/fix-for-1049278/+merge/125965 and https://code.launchpad.net/~m-alaa8/ubuntu/quantal/kubuntu-docs/fix-for-1066132/+merge/129598 in the queue
<dholbach> Riddell, ^ I'll ping Darkwing about it too
<dholbach> dpm, pitti: any opinions about https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/997248?
<ubottu> Launchpad bug 997248 in langpack-locales (Ubuntu) "Inconsistency in decimal point for es_MX and es_NI locale" [Undecided,In progress]
<pitti> dholbach: I always demand forwarding them upstream (http://sourceware.org/bugzilla/enter_bug.cgi?product=glibc, "localedata" component), with a reference to an official documents which proves that the proposed change is correct
<pitti> I've seen too many wars about other people then chiming in and saying "but that's all wrong!!!"
<dholbach> ok
<dholbach> will do
<dholbach> thanks pitti
<pitti> thanks!
<Laney> -devel discussion> seems like a tag defer-next-release which hides from the overview, together with a script that untags all such bugs would work?
<Laney> for bugs, not sure about MPs
<dholbach> yes, sounds good
<dholbach> it'd be nice if we could do the same for MPs easily
<Laney> a hack would be to make an account whose purpose is to cause a MP to be hidden, then request a review from it
<dholbach> what would the hack do? mark the MP as 'WIP' (or something) and then repropose it?
<Laney> does WIP hide?
<dholbach> yes
<dholbach> not sure though if you need special permissions for that
<dholbach> seb128, does https://code.launchpad.net/~carifio/seahorse/seahorse-remove-broken-help-buttons/+merge/129303 look OK to you? or is it something that should be forwarded upstream?
<Laney> at least I can do it
<dholbach> cool
<Laney> so the unhide script has credentials for this account, sees which 'reviews' it has to do, flips the status back to Needs review and abstains
<Laney> assuming this is possible via API
<dholbach> I guess it should
 * Laney can probably implement this
<xnox> Laney: dholbach: I don't like "work in progress" because many "work in progress" are actually sponsor asking sponsoree to do something, which has not been done yet. Maybe we should reject those, but I have been setting to "work in progress".
<Laney> it's WIP+review from role account
<dholbach> xnox, WIP is something everyone can do, but not 'reject' :-/
<xnox> Laney: that would be nice =)
<Laney> call it ~defer-sponsorship
<xnox> "needs reivew" -> "WIP+review" with a comment on the merge proposal would be nice indeed =))))
<Laney> haha
<Laney> dholbach: was "HOLY PATATAS BRAVAS" you?
<dholbach> yes :)
<seb128> dholbach, I will have a look to the seahorse merge request, I looked a bit at it before
<dholbach> seb128, merci beaucoup mon ami
<seb128> dholbach, de rien ;-)
<amb__> I am trying to port a debian experimental package (xen 4.2.0) to Precise. When I debuild I get /usr/bin/ld.bfd.real: unrecognized option '-Wl,-Bsymbolic-functions'. AIUI if -B is passed to ld, it should be without the -Wl. The text 'symbolic-functions' does not appears anywhere within the source. But config.log & config.status (built) have 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' - it's coming from inside the ship (um, inside Pr
<amb__> ecise). That surely must be wrong. Any ideas?
<alexbligh1> $ dpkg-buildflags | fgrep LDFLAGS
<alexbligh1> LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
<alexbligh1> manpage suggests the -Wl etc. should not be there.
<cjwatson> Man page doesn't document the Ubuntu vendor defaults
<alexbligh1> "Options passed to the compiler when linking executables or shared objects (if the linker is called directly, then -Wl and , have to be stripped from these options). Default value: empty."
<cjwatson> Sure, man page bug
<cjwatson> The actual program behaviour is correct for Ubuntu
<cjwatson> Although note that further down there's a bit about relro which says it's enabled by default
<alexbligh1> Ah, does it mean '-Wl' has to be stripped by the setter? or by the consumer?
<cjwatson> You should be linking with gcc, not with ld
<alexbligh1> AFAICT it's running a bog standard autoconf
<cjwatson> As the man page says, if you want to link with ld, you need to strip off -Wl,
<alexbligh1> Ah, I read that as 'the setter needs to strip it'.
<cjwatson> No, that's wrong
<cjwatson> autoconf doesn't control how programs are linked
<cjwatson> automake does, but bog-standard automake will link with gcc
<alexbligh1> oh sorry, auto*
<cjwatson> Can't be bog-standard
<cjwatson> I expect there are some custom rules somewhere
<alexbligh1> seems to be using $(LD) ...
<cjwatson> The Ubuntu package in precise had a patch to adjust LDFLAGS for use by ld
<alexbligh1> The Xen package? How do you remember all this stuff? :-)
<cjwatson> I looked up the changelog
<cjwatson> It was dropped in quantal because the quantal packaging toolchain no longer exports LDFLAGS to the environment by default; you have to ask for it using dpkg-buildflags
<alexbligh1> ha ha
<cjwatson> However this means that the quantal package has the (far from uncommon) bug of not using the default build flags
<cjwatson> If upstream can be persuaded to use $(CC) rather than $(LD) to link, that would be best, but they may have reasons not to
<cjwatson> Failing that, restore the patch to hack LDFLAGS
<alexbligh1> I'm trying to build on Precise anyway, and there is no Xen4.2.0 anywhere in Ubuntuland as far as I can tell (even in PPA)
<alexbligh1> Hence stealing the Debian one.
<cjwatson> Sure, but there's no reason you couldn't borrow most of the packaging, or at least that patch from it
<alexbligh1> No indeed, that is exactly what I shall do.
<cjwatson> xen ought to be modified to use dpkg-buildflags, at which point it'll start noticing this problem again, even in Debian
<alexbligh1> I may not steal the ubuntu packaging, as the xen 4.1 ubuntu packaging was 'interesting' (like the dev libraries were incomplete)
<cjwatson> (Debian's packaging toolchain never exported LDFLAGS to the environment by default; that was an Ubuntuism which we dropped in quantal in the cause of getting closer to Debian)
<alexbligh1>  dpkg-buildpackage -rfakeroot -D -us -uc -b
<alexbligh1> dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
<alexbligh1> dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): -D_FORTIFY_SOURCE=2
<alexbligh1> dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
<alexbligh1> dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
<alexbligh1> dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions -Wl,-z,relro
<alexbligh1> doesn't that suggest it is?
<cjwatson> That's precise's behaviour, yes
<cjwatson> Notice that I said quantal
<alexbligh1> ah it's an implict call to buildflags.
<alexbligh1> cjwatson, thx
<cjwatson> no problem
<dholbach> can the people from lubuntu,mythbuntu,xubuntu,ubuntustudio please have a look at https://code.launchpad.net/~gunnarhj/ubuntu/quantal/lightdm-gtk-greeter/lang-chooser-on-by-default/+merge/129758 and see if that's what they want?
<smb> cjwatson, I am somewhat torn between trying to ask you one evening in Copenhagen what should be done exactly with the buildflags and the Xen package or after it when there is a bit time (and not release week). Though both has somewhat illusional chances. I try to keep it in mind/on a list for the next time I touch it...
<mr_pouit> dholbach: not an issue for xubuntu/lubuntu because we use our own config file.
 * smartboyhw thinks so too with Ubuntu Studio
<dholbach> mr_pouit, do you by chance know how other flavours deal with this?
<dholbach> aha
<dholbach> maybe you could reply on the merge proposal?
<dholbach> just so it's easier to track down for us
<dholbach> and maybe we should ask some of the other flavours to review this too
<mr_pouit> in the bug report, Gunnar already stated this (https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/803858/comments/27) too
<ubottu> Launchpad bug 803858 in lightdm-gtk-greeter (Ubuntu) "No language chooser on login screen in LightDM" [Undecided,In progress]
<dholbach> ok cool
<ochosi> dholbach: ping
<dholbach> ochosi, pong
<ochosi> dholbach: astraljava passed a question about this merge-request along: https://code.launchpad.net/~gunnarhj/ubuntu/quantal/lightdm-gtk-greeter/lang-chooser-on-by-default/+merge/129758
<dholbach> mr_pouit, smartboyhw and I were just talking about it
<smartboyhw> dholbach, some comments in our dev channel says it is ok
<ochosi> sorry, i was informed about that just now :p
<dholbach> ochosi, so it seems like xubuntu/lubuntu because use their own config file
<dholbach> so it might well be that the change is not necessary
<dholbach> (and it might be similar for Ubuntu Studio)
<smartboyhw> dholbach, I wonder: Actually what will the lightdm-gtk-greeter look like after the merge?
<ochosi> dholbach: just out of interest, is this the language-selector here: http://www.zimagez.com/zimage/screenshot-10162012-020905pm.php
<smartboyhw> dholbach, should I go and ask the Kubuntu guys?
<mr_pouit> dholbach: it's useful for people who use lightdm-gtk-greeter with ubuntu
<dholbach> smartboyhw, they use lightdm-kde-greeter
<smartboyhw> dholbach, er....Wait
<dholbach> mr_pouit, right, yes
<dholbach> ok, I guess I will just ping mterry about it once he turns up later on
<smartboyhw> dholbach, hmm....Since I do saw the select language menus in 12.10 Ubuntu Studio builds.....maybe that wasn't needed for Ubuntu Studio..It is just derived from Ubuntu Studio
<cjwatson> smb: In general, if not using sufficiently smart helper tools (dh(1) from debhelper compat level >= 9), packages should fetch at least the default values of CPPFLAGS, CFLAGS, and LDFLAGS from dpkg-buildflags in debian/rules and pass those to the upstream build system in whatever way is appropriate
<cjwatson> There are various options and exactly which to use depends on the build system
<smb> cjwatson, Yes, I guess I would have the do the latter as the Debian Xen package was (iirc) not using the shorter dh variant but a more complex rules file. I was wondering when it did not need the hack anymore but I think back then when I asked around it was not persistent/widely enough.
<cjwatson> The LDFLAGS hack ceased to be required when we changed dpkg-buildpackage in early quantal to no longer export flags by default, but the flip side is that you've probably lost hardening flags.
<cjwatson> So it's moderately important to fix that for R.
<smb> cjwatson, Sure I saw that in the scrollback. It is now on my my list at least (and hopefully I do not forget to look at it when I touch it next). Probably also to go backwards into Q if opportunity permits.
<doko> cjwatson, which hardening flags do we loose exactly? these are still defaults in gcc
<cjwatson> Oh, maybe
<cjwatson> I looked into this a while back but I forget the results
<cjwatson> Not hardening then, but -Wl,-Bsymbolic-functions
<doko> right, that would be the one
<doko> jamespage, are you ok with building gwt, mondrian using openjdk-6 to work-around the build failures?
<jamespage> doko, +1
<cjwatson> doko: Would that help with eigenbase-resgen too?
<doko> I'll check
<cjwatson> But yeah, we can't remove that stack, too many build-deps
<gogo_> Hello, in Ubuntu 12.10, I cannot change window animation duration from CCSM. Any altered value have no effect on duration and default values are still used. Is this a bug or intended behavior?
<stokachu> Would someone be able take a look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=open-iscsi? its been in the unapproved queue since 10/3
<stokachu> dholbach: so once the package is in the upload queue ubuntu-sponsors is not needed and it relies on ubuntu-sru at that point?
<dholbach> stokachu, yes
<stokachu> dholbach: ok cool just checking so I dont incorrectly subscribe sponsors again
<dholbach> it's all good :)
<dholbach> thanks for your work on this
<stokachu> sure thing :D
<xnox> stokachu: most of SRU folks are busy doing the release =)
<stokachu> xnox: ah
<stokachu> xnox: http://people.canonical.com/~ubuntu-archive/pending-sru.html, does the package show up once the upload has been approved?
<xnox> stokachu: yes. these are packages that were accepted into $release-proposed and now are tracked how long they are in the -proposed and if they are "aged", "verified" and did not regress.
<doko> Laney, your handbrake upload ftbfs on amd64
<Laney> yes I know
<doko> =)
<Laney> I pinged jbicha, it's his backport really
<Laney> the way we upload those makes it appear to be the backporter on the hook
<Laney> doko: is there a way to do that scanning locally with sbuild?
<doko> Laney, don't know. maybe ask lamont, I think he did add the code to the buildds in ia64 times ...
<jbicha> implicit pointer conversion build failures are so annoying
<cjwatson> It's in lp:launchpad-buildd
<xnox> doko: yeah I totally want to know how to run that check locally, as it's not integrated into something useful which get's installed by mk-sbuild (same as pkgstripper, binary manglers & dbgsym generators).
<cjwatson> lpbuildd/check_implicit_pointer_functions.py <foo.build
<cjwatson> or sbuild | lpbuildd/check_implicit_pointer_functions.py --inline
 * xnox takes a note to add a further wrapper to my sbuild....
<stokachu> xnox: is there anyone in particular i could bug about this package being in the unapproved queue?
<stokachu> without losing some fingers
<cjwatson> stokachu: I'll take a look.
<xnox> stokachu: looking at https://launchpad.net/~ubuntu-sru/+members the usual suspects are steve, colin, adam, clint... =) for that sort of package.
<cjwatson> stokachu: accepted
<stokachu> cjwatson: awesome thanks man
<hallyn> safe to assume we have no sparcs in build farm?
<cjwatson> We have two sparc builders.
<cjwatson> artigas and sejong.  https://launchpad.net/builders
<hallyn> cjwatson: so openbios-sparc, which must be built on sparc, *could* be pulled into ubuntu?
<cjwatson> No, that's a different problem
<hallyn> i'm looking into how closely we can mirror debian's qemu packaging layout for r
<cjwatson> We have no way to do architecture: all builds on anything other than i386
<hallyn> ok so i should drop sparc
<hallyn> cjwatson: thanks
<cjwatson> bug 183495
<ubottu> Launchpad bug 183495 in openbios-sparc (Ubuntu Hardy) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [High,Confirmed] https://launchpad.net/bugs/183495
<cjwatson> Although I'm sure there's a bug on Launchpad somewhere, where it more properly belongs
<hallyn> cjwatson: but as it's been around since 2008, low prio i assume
<cjwatson> hallyn: Bug 217427
<ubottu> Launchpad bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427
<xnox> cjwatson: but there is no way to currently express that in .dsc e.g. build-arch field
<hallyn> cjwatson: i'm a little surprised a powerpc - on - x86 crosscompiler isn't packaged...
<xnox> cjwatson: hallyn: (ugly-hack) arch: ppc, Multi-Arch:
<xnox> cjwatson: hallyn: (ugly-hack) Arch: ppc, Multi-Arch: allowed
<cjwatson> xnox: See that bug report.
<cjwatson> xnox: I'd rather you didn't work around it that way.
<cjwatson> If nothing else, that's no use for cases that involve build-deps.
<cjwatson> hallyn: *shrug*
<hallyn> cjwatson: i'm wondering whether, if it did, that sufficed
<cjwatson> hallyn: Don't know.  Possibly
<xnox> hallyn: well all rdeps would need to be changed to: package [sparc]
<xnox> hallyn: well all rdeps would need to be changed to: package [ppc]
<cjwatson> xnox: No, they wouldn't.
<cjwatson> Cross-compile binary, put it in an architecture: all binary just as it is now.
<cjwatson> Also, you can't specify a particular architecture in Depends.
<hallyn> cjwatson: any sense having a uds session on this?
<cjwatson> hallyn: No, we'd just all sit around and agree that either the Launchpad bug needs to be fixed or we need a cross-compiler
<hallyn> ok :)
<hallyn> there used to be a simple howto for locally creating cross-compiler, but might be a bear to package
<cjwatson> hrw might know
<hrw> hi
<hallyn> hrw: wondering about feasability of creating a set of cross-compiler packages
<hallyn> (specifically gcc for powerpc and sparc)
<hrw> hallyn: doable with arm cross compiler packages as base
<hrw> hallyn: but openbios-sparc on debian is arch:all - can't be same in ubuntu?
<hrw> I see - 'This package must be built on a SPARC machine'
<hallyn> hrw: right (same with openbios-ppc, and presumably openhackware)
<hallyn> so gcc-arm-linux-gnueabi as an example?
<hrw> hallyn: going for cross compilation with them means maintaining 3 packages per arch (6 for biarchs).
<hrw> hallyn: binutils-armel-cross, armel-cross-toolchain-base, gcc-4.7-armel-cross
<hrw> hallyn: first gives binutils, second glibc and libgcc, last one gives compiler
<cjwatson> Might be less effort to fix the LP bug ...
<hrw> cjwatson: and then we will pray that no one wants openbios-hppa :D
<cjwatson> OK, that's true, fixing the LP bug wouldn't help with openbios-sparc since it's no longer an architecture in modern series
<cjwatson> So a cross-compiler would be needed for that either way
<hrw> or package removal but that will hurt all users of qemu-sparc
<cjwatson> The package was actually removed ages ago
<cjwatson> But it'd be nice to be able to reintroduce it
<hrw> question is: who wants to maintain those cross compilers?
<cjwatson> hallyn's the one pushing for this currently :)
<hrw> hallyn: grab binutils-armel-cross source, sed -i s/armel/sparc/ debian/changelog then debian/rules control and build. then same with armel-cross-toolchain-base and gcc-4.7-armel-cross. when all done, grab gcc-defaults-armel-cross and do changelog and rules trick then rebuild.
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hrw> hallyn: if you are lucky then small amount of work needed.
<hallyn> hrw: thanks, will give it a shot
<hrw> hallyn: wookey did aarch64 cross compiler recently from those packages so it is doable ;)
<hrw> hallyn: in case of problems - ask me
<hallyn> will do thx
<lamont> jbicha: like cjwatson said - it's just a logfile scan that looks for implicits that were conversion truncation, or so
<cjwatson> jtaylor: abiword/armel failed to build
<jtaylor> Oo
<jtaylor> can't be the abiword change
<cjwatson> jtaylor: No, but now we're in a bit of a bind for release
<cjwatson> We *were* at the point where there were zero out-of-date binaries in the archive
<cjwatson> abiword has broken that
<cjwatson> The last build was only 2012-10-08 ...
<jtaylor> yes not long ago
<cjwatson> Looks like somebody has retried it already?
<jtaylor> I didn't expect toolchain breaking
<cjwatson> He says as the build log goes away
<cjwatson> jtaylor: I should have noticed it was in images and required your sync to go through -proposed
<jtaylor> but isn't this a larger issue jut discovered by abiword
<cjwatson> Maybe, but such fine principles are for earlier in the cycle
<cjwatson> Now we need to not break stuff or expose breakage
<micahg> cjwatson: if it's just armel, it shouldn't impact any images at least
<cjwatson> No, but if fixing it requires a source upload, that'll hit Xubuntu and Lubuntu
<cjwatson> I am *not* going to leave out-of-dates just after we spent weeks getting them clean
<cjwatson> I mean *literally* just after, as in the next publisher cycle
<micahg> true
<mwhudson> probably not the place to ask this question, but:
<mwhudson> why would apt-get remove $package (unattended-upgrades in this case) want to install over 100 new packages?
<slangasek> possiblybecause something else on the system depends on $package and apt looks for a way to satisfy your request that results in the smallest number of additional packages having to be removed
<mwhudson> ah right
<mwhudson> i think i don't want to remove it in fact
<mwhudson> just disable it
<ScottK> cjwatson: Is you comment on Bug #674627 at all indicative that it's still an issue or you just doing cleanup?
<ubottu> Launchpad bug 674627 in sip4-qt3 (Ubuntu) "python: /build/buildd/sip4-qt3-4.11.2/siplib/siplib.c:10613: sipEnumType_alloc: Assert-makro "(((currentType)->td_flags & 0x0007) == 0x0003)" ei pidÃ¤ paikkaansa." [Undecided,Confirmed] https://launchpad.net/bugs/674627
<cjwatson> ScottK: Just cleanup.
<ScottK> OK.  Thanks.
<cjwatson> ScottK: I was hunting for bugs filed on the upstream ubiquity project, which we don't use.
<ScottK> The sip4 upstream has been very responsive about fixing stuff, but since he actually spends time on stuff I send him, I'm reluctant to forward old bugs that I can't confirm are an issue.
<cyphermox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<slangasek> barry: so did you also hit bug #1054712?
<ubottu> Launchpad bug 1054712 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712
<stgraber> slangasek: I had that happen to me a couple of times lately while testing persistence. Seemed to happen pretty often when dealing with fast storage (external USB3 SSD).
<barry> slangasek: yep.  i was investigating bug #915626 but realized it was different.  my reported bug #1064072 was duped to bug #1054712 but i didn't investigate further
<ubottu> Launchpad bug 915626 in usb-creator (Ubuntu Quantal) "usb-creator-gtk crashed with SIGSEGV" [High,Confirmed] https://launchpad.net/bugs/915626
<ubottu> Launchpad bug 1054712 in usb-creator (Ubuntu) "duplicate for #1064072 usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712
<ubottu> Launchpad bug 1054712 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712
<stgraber> segfault would typically happen after the file copy and before the boot sector would get written. Apparently killing the leftovers udisk and usb-creator processes was helping but it was still mostly random in my case (using the same source image and destination drive)
<barry> stgraber: it sure smells like a reference counting bug
<stgraber> at the time I was in the middle of sorting a bunch of casper bugs so didn't have much time to investigate. I just ended up manually setting up the MBR and the disk then worked fine.
<cjwatson> jtaylor: Yeah, you're off the hook - a retry succeeded
<cjwatson> (phew)
<jtaylor> uff
<jtaylor> strange
<barry> stgraber, slangasek: i can take a closer look tomorrow.  the crash sure seems like dbus-string.c is trying to delete something it doesn't own but thinks it does
 * jtaylor sticks big red marker onto scren "hands off seeded packages"
<jtaylor> sorry for the screwup
<cjwatson> Ah well, no real harm done in the end
<jtaylor> at least i saw another potential issue scroll by in the log
<jtaylor> Wsequence-point
<jtaylor> and reported to debian
<slangasek> barry, stgraber: so for me the problem is consistently reproducible when trying to write to a USB stick without persistence
<slangasek> haven't tried with yet
<barry> slangasek: yep, when i was looking at it, it crashed every time for me.  debugging it will be fun though
<slangasek> yeah, segfaulting python is my favoite
<barry> slangasek: especially memory ownership bugs :)
<bdmurray> slangasek: is that the usb-creator bug?
<barry> bdmurray: yep
<slangasek> well, apparently a different one than the one we currently have targeted
<slangasek> barry: python is very noisy under valgrind
<barry> oh yes
<barry> slangasek: Misc/vgrindefs from python's source helps (though it's been ages since i valground python ;)
<barry> slangasek: oops
<barry> slangasek: wrong file
<barry> Misc/README.valgrind
<slangasek> ta :)
<barry> np!
<slangasek> though it's possible I can just ignore everything up to the point right before it crashes, anyway; it's fairly quiet while it's running the disk copy
<slangasek> ==12322==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
<slangasek> well that's helpful
<slangasek> hah, and when I run it under pdb it completes successfully :P
<slangasek> barry: bah, what does pdb permute that causes this command to succeed? :/
#ubuntu-devel 2012-10-17
<mfisch> robert_ancell: bryceh suggested I write an appoort script for lightdm
<mfisch> robert_ancell: I think it would be pretty useful
<robert_ancell> mfisch, we already have one
<robert_ancell> debian/source_lightdm.py
<mfisch> that was my first question
<mfisch> robert_ancell: bryceh's xorg script prompts the user before collecting the logs, wonder if we should too
<robert_ancell> sure, sounds good
<mfisch> I'd also like to grab lightdm.conf
<mfisch> robert_ancell: is there a reason the hook script isn't being installed?
<robert_ancell> mfisch, it isn't?
<mfisch> let me check an unmodified deb
<mfisch> robert_ancell: it is not in 1.4.0
<mfisch> it's also not in the lightdm.install scripts
<robert_ancell> must be broen
<robert_ancell> broken
<mfisch> I'll fix that too
<mfisch> robert_ancell: you want a bug for this?
<robert_ancell> sure
<mfisch> or just a MP
<hallyn> hrw: jinkeys, my sparc-cross-toolchain-base-1.89 has been building here all day long :)  hopefully it doesn't bail right at the end and want to be restarted :)
<mfisch> robert_ancell: just need to fix one thing: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1067591
<ubottu> Launchpad bug 1067591 in lightdm (Ubuntu) "test bug" [Undecided,Invalid]
<mfisch> robert_ancell: thats the bug that apport made
<pitti> Good morning
<ajmitch> hi pitti
<dholbach> good morning
<OdyX> tkamppeter: Hi. I've been trying to debug this ipp-1.1 failure in cups for 4 hours now and can't get to a solution. I noticed it works with testfile.pdf though. Any idea where I should look into?
<OdyX> (in cups, eh)
<hrw> hallyn: share packages please :)
<didrocks> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks
 * dholbach hugs didrocks
<didrocks> dholbach: not sure how much I can do today, unity SRU world (well, sponsoring popey's team, it's still sponsorship) :)
<didrocks> will try to do as much as possible :)
<dholbach> yeah, I did clean up mostly yesterday
<dholbach> and looked at some SRUs
<dholbach> that's the time of year, isn't it? :)
<didrocks> indeed :)
<tkamppeter> OdyX, unfortunately, I do not have an idea there, I never looked into the test programs. They always worked and when they stopped I had too many other, more important bugs to fix.
<OdyX> tkamppeter: yeah; guessed so. I'll file a bug at cups directly as they also fail without any patches (well, the test runs with a .ps file which is probably not supportedâ¦)
<ev> Is it possible to do a one off sync to precise-proposed?
<ev> gnat-gps is still causing trouble on the retracers and 5.0-13 fixes it
<cjwatson> Not sure it would be sensible to sync back quantal binaries - could you backport the fix instead, please?
<cjwatson> (We can't do a sync without binaries either because same pool)
<Laney> mvo: is it known/intended that apt-cache show pkg doesn't show the long description on Q?
<mvo> Laney: neither
<Laney> :P
<mvo> Laney: what do I need to do to reproduce?
<mvo> Laney: don't ansewr apt-cache show apt ;)
<Laney> apt-cache show apt
<Laney> hahaha
<mvo> Laney: is that on the livecd?
<Laney> no, I'm trying it in a quantal schroot
<mvo> Laney: or a fresh install? before the first evar apt-get update was done?
<mlankhorst> Laney: hey when does https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda get updated? I want to put myself on for core-dev :)
<Laney> mlankhorst: when bdrung updates it, but you can add yourself whenever
<Laney> the next meeting is during UDS
<mlankhorst> I know
<Laney> just do it any time
<Laney> mvo: you don't see it in your setup?
<mvo> Laney: I don't use schroot but I'm happy to give it a try
<Laney> weird, I don't see it on our porter-amd64
<mvo> Laney: which setup should I follow? https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment  ?
<mvo> Laney: aha, is that one a server that I can use to reproduce?
<Laney> no, because I don't reproduce it there
<Laney> that is Description-en: foo whereas in my chroot it's Description: foo
<Laney> and outside of the chroot it's the same as inside for me locally
<mvo> Laney: so no apt-cache show apt even outside the chroot for you?
<Laney> nope
<Laney> I made the chroot with mk-sbuild quantal (from ubuntu-dev-tools)
 * Laney fires up the VM
 * mvo runs this now
<cjwatson> Laney: there are separate Translations files - you may need to set a locale
<cjwatson> now, apt is supposed to use English for LANG=C
<mvo> yeah, exactly
<mvo> this is whats puzzling me
<Laney> well, on my bare metal it's en_GB.UTF-8
<mvo> Laney: does apt-get update show it fetching Translation-en files at all?
<cjwatson> mm, I don't see it in my schroots
<Laney> ah, wait
<Laney> they all share my local mirror, I bet that's busted
<cjwatson> --include=i18n/Translation-en
<cjwatson> Well
<cjwatson> My debmirror run has --i18n --exclude='i18n/Translation-' --include='i18n/Translation-en' actually
<Laney> Ign .../Translation-en{,_GB}
<cjwatson> it's the --i18n that matters but you probably don't want to fetch all the translations if you have any kind of limited bandwidth
 * Laney wonders how to do that in config
<Laney> mvo: yeah that was it, sorry for noise
 * Laney goes to twiddle debmirror
<mvo> Laney: puhh, I was a bit worried
<mvo> good that its fixed now
<mvo> (or on the way)
<mpt> omg the error rate is going down
<mpt> for four days straight
<pitti> ev, mpt: btw, what exactly does the y axis mean on errors.u.c.? avg errors per calender day is certainly not the whole story -- that should be a magnitude of 1.000 to 100.000 submissions per day surely?
<mpt> pitti, why would it be 1.000 to 1000.000?
<pitti> mpt: well, how can we get 0.04 error reports on a day?
<pitti> we should get several thousands, and certainly not a fractional
<pitti> I assume this number is "average errors per calender day per <something I don't know>"?
<mpt> pitti, if 4% of the active machines reported exactly one error that day, for example. Or if 2% reported exactly one error and 1% reported exactly 2 errors.
<pitti> mpt: ooh, so "errors per day per active machine"
<mpt> yes
<pitti> thanks, that's what I was missing
<Laney> what's an active machine?
<mpt> I knew someone was going to ask that :-)
<Laney> those who have submitted an error over some time period?
<mpt> Correct, an active machine is one that has submitted any error reports in the past 90 days.
<mpt> That overcounts machines that have been destroyed or had Ubuntu wiped from them sometime in the past 90 days.
<mpt> And it undercounts machines where the user would have reported errors, but was fortunate enough to get none at all.
<mpt> Hopefully those two biases roughly cancel each other out.
<pitti> seb128, cjwatson, Daviey, all: dholbach and I were just discussing for which packages we would like to see autopkgtests for; we are going to have a little competition at UDS and want to collect a list (people can work on their own packages, of course); so far I came up with http://paste.ubuntu.com/1284747/, do you have any others?
<seb128> pitti, there are a lot of those in desktop we could add
<pitti> seb128: FYI, I know that indicator-* is probably not going to happen there, but it's something that would benefit
<pitti> seb128: dholbach will set up a wiki page, and I'll put the list there
<dholbach> pitti, seb128, cjwatson, Daviey: shall we use a pad to brainstorm now?
<pitti> seb128: so if you know of a library that breaks often, it shoudl be there
<dholbach> then I can move it to a wiki page later
<dholbach> pitti, gtk- too many gtk boogs!
<pitti> dholbach: GTK already has tests
<pitti> glib, too
<dholbach> http://pad.ubuntu.com/lHeOelgRuJ
<seb128> pitti, like I can image we could add libsoup librsvg libsecret libunity libarchive libdbusmenu libgdata libical
<cjwatson> dholbach,pitti: count me out, busy with 12.10 emergency
<seb128> pitti, poppler
<dholbach> cjwatson, good luck!
<pitti> cjwatson: *ack*
<pitti> seb128: libunity is already on the list; thanks
<seb128> pitti, cairo
<pitti> seb128: ooh, poppler
<pitti> dholbach: we already have s-c
<dholbach> ok
<pitti> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-software-center/
<pitti> they need to be fixed, though
 * pitti bats eyelashes towards mvo
<dholbach> hah :)
<mvo> pitti: *cough* indeed
<pitti> dholbach: actually, anything that's red on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/, like maas or network-manager
<seb128> pitti, dholbach: you can drop "libindicate-gtk3-dev", that lib is deprecated in quantal
<pitti> done
<seb128> it's replaced by libmessaging-menu from indicator-messages
<pitti> seb128: just libindicate-dev now?
<pitti> aah
<pitti> that seemed more specialized, though
<seb128> pitti, no, libindicate stop being used, lars is brining sanity to indicators
<seb128> pitti, well, libindicator is still used
<seb128> libappindicator as well
<pitti> seb128: GMenuModel?
<seb128> pitti, no, orthogonal things, libindicat* is confusing
<pitti> seb128: added libindicator3-dev then
<seb128> libindicate -> indicate message -> lib to use for client to integrate in indicator-messages ... that's libmessaging-menu now
<seb128> libindicator -> lib to do system indicators
<pitti> aah
<seb128> libappindicator -> lib for apps, equivalent of the gtkstatusicon
<pitti> yeah, I've always been confused about these two
<cjwatson> pitti: FWIW I fixed software-properties and about half of unattended-upgrades in bzr, but didn't think it worth disrupting the release process with uploads
<pitti> cjwatson: thanks, noting so in pad to avoid double work
<seb128> pitti, lars plan to consolidate with only a libindicator gmenumodel based
<cjwatson> (since the bugs were test-only)
<seb128> pitti, so hopefully all the confusions go away
<pitti> dholbach: that looks like a lot of fodder now :)
<dholbach> yes, a good start :9
<dholbach> :-)
<dholbach> I'll set up the wiki docs and add this there
<seb128> dholbach, pitti: great list ;-)
<pitti> seb128, dholbach: I'm not sure whether unity is suitable as an autopkgtest -- sounds more like a case for UTAH to me (i. e. testing under a full desktop session, not just a tiny server environment with no session/system d-bus, no gnome session, etc.)
<pitti> if someone can make it work, sure :)
<pitti> (this would certainly deserve the "winner" prize)
<seb128> pitti, sorry, I misunderstood "system installed packages"
<dholbach> pitti, yeah, I listed it because I thought it must have a bunch of upstream test cases (built tree) as well
<dholbach> but I'm sure you're right
<pitti> seb128: clarified in the pad
<seb128> pitti, danke
<seb128> pitti, btw how far are we to be able to e.g throw a gtk update somewhere and have the system tell us if it breaks any autotest somewhere else?
<seb128> e.g rdpends testing
<pitti> seb128: that's called https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/
<seb128> pitti, well, where somewhere is not the archive :p
<pitti> seb128: it tests -proposed uploads and all its rdepends, and creates red dots
<pitti> seb128: well, for somewhere == -proposed
<seb128> proposed is not supposed to be used as a test bed afaik
<pitti> seb128: in principle we have the machinery to do it for PPA
<cjwatson> seb128: not a manual test bed
<pitti> just not wired up to do it
<cjwatson> seb128: it's definitely intended for autopkgtests to run on it
<pitti> but with that we'll run into capacity issues, so we'd need to limit that a bit
<cjwatson> this is part of the grand plan
<seb128> cjwatson, right, but I guess it would be nicer if we had a way to see the result of autopkgtests without having to send the package to proposed
<pitti> we certainly need a facility like that
<cjwatson> seb128: oh, sure, though of course you can just run it locally :)
<seb128> like "I'm not ready to upload to the archive yet but I would like to know how good that GTK is"
<cjwatson> maybe not all the rdepends
<pitti> we are very close to having the whole thing charmed (not including jenkins itself, though)
<pitti> but this needs some more love, as well as documentatino
<seb128> where I'm getting at I guess is that I whole love to have a daily gtk-trunk build going through autotests
<seb128> I would*
<seb128> so we know when upstream breaks something
<seb128> rather than waiting for the next tarball 3 weeks later
<pitti> seb128: right, that sounds like an excellent case for "juju deploy ubuntu-adt" with an extra PPA
<pitti> seb128: but it also ties into what we are doing with jhbuild
<seb128> pitti, yeah
<pitti> seb128: did you see https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/ ?
<pitti> that now runs with --check
 * pitti hugs jibel
<seb128> pitti, I think I bookmarked a blog post from jibel about that
<seb128> or email, or g+ or something
<seb128> but I didn't go back to read it yet
<jibel> seb128, we have something very close https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/
<seb128> does that run autopkgtests?
<seb128> or just upstream tests?
<pitti> seb128: so my hope is that https://code.launchpad.net/unity-jhbuild will work well enough to be able to integrate it there, too
<jibel> not autopkgtest, it does a checkout, build and run upstream tests
<pitti> seb128: that's upstream tests; "jhbuild --check build" by and large
<seb128> ok
<jibel> so we know when upstream breaks something
<seb128> so it's great
<seb128> but it doesn't tell me when I break s-c for mvo :p
<pitti> seb128: oui, that's where the juju charm for setting up the adt environment with an extra PPA comes into play, I think
<seb128> but combined with the ""juju deploy ubuntu-adt" with an extra PPA" we have the best on both side
<pitti> we can certainly enable an extra PPA, but for a more general service the DC doesn't scale
<seb128> pitti, sounds great to me ;-)
<seb128> pitti, yeah, I don't want that level of testing for everything, mainly glib and gtk
<seb128> it might convince me to keep tracking the unstable serie of those :p
<pitti> jibel: capacity issues aside, I guess it would be relatively easy to enable adt runs with the ubuntu-desktop PPA enabled, right?
<pitti> now that it works for -proposed
 * pitti really feels bad for never having tried juju yet; something high on my "want to try" list
<jibel> pitti, yes, it'd be easy, the functionality to test from a ppa has been added to the tool a couple of weeks ago
<seb128> \o/
<seb128> pitti, I feel bad that I didn't have more time to play with autopkgtests this cycle and add some, I hope to fix that next cycle ;-)
<seb128> pitti, jibel: https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/job/jhbuild-gnome-amd64-nautilus/28/artifact/nautilus.log ..."Could not open X display", do you consider that an upstream test bug (e.g they should use xvfb-run) or a setup bug on the qa machine?
<pitti> seb128: or at UDS, where we'll hopefully get a whole bunch
<seb128> pitti, well, I count on UDS to get started and keep that ball rolling from then on ;-)
<pitti> seb128, jibel: I guess for jhbuild in GNOME it'd probably be appropriate to run the whole thing under xvfb-run?
<seb128> +1 from me
<jibel> seb128, I'm fixing the system to run tests through xvfb
<pitti> I always run it under my normal desktop session
<pitti> we just need to check if you can nest those
<pitti> i. e. for test suites which call xvfb on their own
<cjwatson> might need [ "$DISPLAY" ] || xvfb-run, or similar
<jibel> seb128, I'm reviewing all the failures and reached package 49/206
<seb128> jibel, ok
<cjwatson> Well, or not
<cjwatson> I guess under a regular X session you still want xvfb-run so that it doesn't pop up windows all over your desktop
<pitti> right
<pitti> I have an env var in apport to disable xvfb, in case I actually do want to see the windows (visual inspection), but most of the time I don't
<cjwatson> 'xvfb-run xvfb-run xterm' gives 'xvfb-run: error: Xvfb fails to start'
<cjwatson> *failed
<cjwatson> OTOH
<cjwatson> 'xvfb-run -n 98 xvfb-run xterm' works
<pitti> maybe with -n 87?
<pitti> right; I'd use a different number in the "outside" jhbuild machinery, so that the defaults work "inside"
<cjwatson> yeah
<pitti> jibel: that might actually fix a lot of failures; I don't use xvfb in pygobject either
<pitti> "DISPLAY= jhbuild run make check" indeed fails
<cjwatson> ubiquity's test runner automatically uses xvfb
<pitti> a/way -all lunch
<pitti> erk, let's try that again
<jibel> jhbuild is supposed to start the tests with xvfb when it doesn't find a display, but it doesn't for some reason. I'll search why after the release.
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<OdyX> tkamppeter, pitti: https://cups.org/str.php?L4214 :)
<quadrispro> hello everybody!
<pitti> OdyX: ah, thanks :)
<OdyX> pitti: besides that bug, the testsuite runs fully without too many problems here, you might want to include my patches into quantal's cups.
<ev> cjwatson: just saw your reply. Thank you and I will.
<gogo> Hello, I am writing an app in python for Ubuntu. I am using pkexec and subprocess to escalate privileges. Is there a way to get user authorization without using subprocess?
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cyphermox> oops.
<micahg> ogra_: I'll be spinning up a webkit update for quantal after the release team is done with respins, so I can switch the optimization to -00 to see if that helps on arm* if you like
<ogra_> yeah, i surely do
<micahg> ogra_: ok, I'll let you know when it's ready for testing then
<ogra_> thx !
<ScottK> bryce: Could you have a look into https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1019444/comments/5 ?
<ubottu> Launchpad bug 1019444 in mesa (Ubuntu Precise) "Update Precise to mesa 8.0.4 (bugfix micro-release)" [Wishlist,Fix committed]
<gogo> Hello, When I run my Ubuntu indicator as root, i am getting this dbus error > http://pastebin.com/thvqYZFh Any idea what is this about?
<dobey> gogo: root processes can't user the user's session bus. you need to run indicators as the user you're logged in as, not as root
<gogo> dobey: Oh, my indicator app asks user for root access 4-5 times. Is these a way the indicator can be granted root access for whole session. I tried polkit policy and pkexec but as you said, it wont work.
<gogo> there*
<ScottK> You need to break your app into a front end that runs as user and a backend that runs as root and use policykit.
<gogo> ScottK: Right, that makes sense. Thanks for the suggestion.
<dobey> gogo: what does your indicator do?
<gogo> its for managing fan speed
<barry> slangasek: wondering if you had any other progress on bug #1054712
<ubottu> Launchpad bug 1054712 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/1054712
<doko> jodh, can you attach your test program for 1066351?
<jodh> doko: done.
<stokachu> slangasek: http://paste.ubuntu.com/1285155/ - would something like this be acceptable for that appmenu-gtk bug?
<slangasek> barry: no other progress besides getting angry at pdb permuting things to where it doesn't crash
<slangasek> stokachu: is UBUNTU_MENUPROXY a single variable, or are there separate ones for gtk2 vs. gtk3?
<stokachu> slangasek: its just a single variable
<stokachu> slangasek: though one thing to note is that libappmenu.so is the same no matter which package is installed
<slangasek> stokachu: oh, then that looks perfectly fine then
<stokachu> no hardcoded paths
<slangasek> yep, that's important
<stokachu> slangasek: ok cool ill get a debdiff create and sent up for when you have time :)
<slangasek> stokachu: so that looks great as a script snippet; there's some monkeying that has to go into the package around deprecating the old file too
<doko> jodh, and assign a kernel task, if you think it's the kernel? ;)
<slangasek> stokachu: oh, I guess we can just ship two copies of this exact file for now, which is probably the simplest change and not incorrect
<stokachu> slangasek: hmmmm this is after purging you mean?
<slangasek> stokachu: pretend I didn't say anything :)
<stokachu> slangasek: lol ok
<barry> mvo: what's the difference between ~mvo/ubuntu/quantal/dbus-python/lp846044 and lp846044-2?
<mvo> barry: none, sorry, I will delete the later one
<barry> mvo: np
<mvo> barry: if you take care of the SRU that will be great and I erase it from my memory^Wtodo list :)
<barry> mvo: sru for quantal?  np, i can take care of that
<mvo> barry: yeah, once we get final approval from upstream I think it should go into quantal-proposed ASAP
<barry> mvo: +1.  what about the oneiric bug task? (currently assigned to you?)
<dholbach> pitti, I set up https://wiki.ubuntu.com/QATeam/RequiredTests
<dholbach> seb128, jibel: ^ - so we can drop the pad page
<mvo> barry: fixed
<barry> mvo: perfect
<mvo> (well won't fixed butâ¦)
<stokachu> mterry: hey are you planning on pushing pbuilder-scripts into precise as well?
<mterry> stokachu, no, since it'd be a new package.  I suppose I could add it via extras, but I hadn't planned on it
<stokachu> mterry: ok i can just rebuild it myself -- the scripts are an awesome addition btw
<mterry> stokachu, thanks!  :)  Hope they are useful
 * micahg reminds mterry about backports for stable new packages and ubuntu-dev-tools for putting dev helper stuff
<micahg> s/stable new packages/new packages in stable/
<ogra_> stapled new packages ?
<stokachu> mterry: definately useful, the organization part is particularly sweeet
<mterry> micahg, yeah  :)
<fishor> hallo all, are any one of ubuntu devs works on gnome-bluetooth?
<stgraber> cyphermox: ^
<pitti> dholbach: merci!
<cyphermox> fishor: what's up
<fishor> cyphermox, hi! i fallowing some crashes in G-B, and have some patches... but it looks like the problem is a bit deeper. I jast lost the trace. On some casts between Device -> GDbsProxy -> Device, device is lost..
<fishor> and i confused with this self genretade gdbs code. some times it used some times it is replicated on main code
<fishor> should it dependencies on bluetooth-client-glue* actually be removed?
<fishor> or are they other reason why the code is so confusing :)
<fishor> currently im in bluetooth-client.c:disconnect_collback
<tkamppeter> pitti, hi
<stokachu> no patch pilots today?
<micahg> stokachu: need something right now?
<stokachu> micahg: ive got an FFe but not sure if its possible to include at this point?
<micahg> stokachu: no, at this point an SRU is probably best
<micahg> stokachu: what's the bug?
<stokachu> micahg: http://pad.lv/932860
<ubottu> Launchpad bug 932860 in appmenu-gtk (Ubuntu Precise) "[FFe] Broken (or missing) multiarch support" [High,In progress]
<stokachu> if the archive is frozen are -proposed being accepted for quantal now?
<micahg> stokachu: yes, SRUs are being accepted time permitting
<stokachu> micahg: ok, quantal isnt my biggest concern its just getting it in quantal so i can create a precise proposal
<stokachu> but i guess they go hand in hand anyway
<micahg> stokachu: yeah, both are SRUs at this point
<stokachu> micahg: ok cool so ill need to wait until time permits then?
<micahg> stokachu: well, unless you need this today, someone will get to it in the queue, if you need it uploaded today I can have a look in a bit
<stokachu> micahg: pm
<fishor> hmm... looks like i DoS-ed cyphermox, was it my english or question?
<_jmp_> pgraner: hi! is tomorrow too late for the pandaboard? I can bring mine tomorrow 9ish
<pgraner> _jmp_, too late sorry
<stokachu> _jmp_: dont forget to check your email before partying
<_jmp_> stokachu: hmm surprises.. /me checks :)
<_jmp_> stokachu: let me get you the agent bits
<stokachu> thanks
<stokachu> _jmp_: and also I wont "taint" my contributions by looking at it either
<_jmp_> stokachu: https://launchpad.net/ubuntu/+source/walinuxagent
<_jmp_> stokachu: nah its fine imo, apache license
<stokachu> ok
<stokachu> slangasek: so when upgrading appmenu with my changes it keeps around /etc/X11/Xsession.d/80appmenu-gtk3 should I remove that file in our rules?
<slangasek> stokachu: ah, that was the bit I was thinking out loud about earlier
<stokachu> yea i just realize that during testing
<slangasek> stokachu: don't remove it, we want both files
<slangasek> stokachu: otherwise, we have two packages having to share a single config file, and that's not pretty
<stokachu> slangasek: so for whatever reason though only 80appmenu gets updated with latest but appmenu-gtk3 stays untouched
<stokachu> so its still looking for a hardcoded moduledir
<slangasek> oh really
<slangasek> did you update both packages?
<stokachu> oh
<stokachu> no LOL
<slangasek> :)
<stokachu> damnit ok lemme check right quick
<stokachu> slangasek: lol ok forget i ever said anything
 * stokachu needs coffee
<slangasek> stokachu: coffee++
<barry> slangasek: thanks for the great email follow up there
<slangasek> barry: at your service :)
<barry> :)
<stokachu> slangasek: is it advisable to set #!/bin/bash in these xsessions scripts?
<stokachu> i dont see it done in any other ones though
<slangasek> stokachu: the files are sourced, not executed, so it doesn't matter
<slangasek> (must be sourced, not executed, otherwise you couldn't use them to set env vars)
<stokachu> hmm ok
<bdmurray> mterry: could you have a look at bug 1065806?
<ubottu> Launchpad bug 1065806 in update-manager (Ubuntu Quantal) "diff window is too small on upgrade" [High,Triaged] https://launchpad.net/bugs/1065806
 * mterry looks
<smoser> stgraber, around ?
<smoser> you looking at https://bugs.launchpad.net/bugs/1061639 ?
<ubottu> Launchpad bug 1061639 in ifupdown (Ubuntu Quantal) "Upstartification of /etc/init.d/networking has lost deconfiguring-networking event causing bad side-effects" [High,Fix released]
<stgraber> smoser: I saw the comments, but I highly doubt it's still ifupdown's fault
<smoser> well, have you tried to reproduce?
<stgraber> smoser: yes, without any success so far. The guy is also saying he had that with 12.04
<slangasek> smoser: those users are reporting a symptom and asserting that they have the same bug, which is not helpful
<slangasek> smoser: any upstart job that's wrongly holding files open at shutdown could trigger a "device busy" error; these users really need to file separate bugs and work through them from first principles
<slangasek> I think there is a bug open on plymouth about this exact problem at the moment, fwiw
<slangasek> (bug #1019347)
<ubottu> Launchpad bug 1019347 in plymouth (Ubuntu) "A message: "mount: / is busy" appears every time shutting down or rebooting." [High,Incomplete] https://launchpad.net/bugs/1019347
<slangasek> which, er, probably needs to be escalated to the desktop team
<smoser> slangasek, "really should open another bug" doesn't mean "problem doesn't exist"
<smoser> i agree that separate issues is right, but i just dont want to ignore the complaints.
<slangasek> smoser: there are limits to how much handholding we can do for users who fail at the basics of bug reporting.  It is not an efficient use of our time to chase up every dogpile comment from a user that is mis-diagnosing their own bug.  If you're seeing this issue, you could help by filing a bug report yourself?
<smoser> i'm not seeing the issue. but the comments were implying almost fresh install.
<smoser> i really just wnted to ensure that that was not the case (which i've not seen)
<slangasek> ok
#ubuntu-devel 2012-10-18
<slangasek> bryce: bug #1066883 can only be a plymouth bug if there's a regression in lightdm's handling of shutting down plymouth; is there any reason to think that might be the case?
<ubottu> Launchpad bug 1066883 in linux (Ubuntu Quantal) "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<bryce> slangasek, feel free to reassign to where you think it belongs
<pitti> Good morning
<RAOF> Ho pitti!
 * RAOF seems to remember having a question to ask pitti, but not what that question actually was.
<joiseystud> anyone know when QQ final will be released?
<lifeless> see #ubuntu-release :)
<micahg> #ubuntu-release-party would probably be better
<pitti> every time someone asks for the precise time, a kitten dies
<joiseystud> lol
<sarnold> poor kitten
<joiseystud> thanks
<pitti> sarnold: exactly!
<micahg> Thu Oct 18 04:34:51 UTC 2012 on my precise system :P
<sarnold> micahg: wow, one of our clocks really skewed, looks like you're fifteen seconds in the past!
<ScottK> lifeless: Please don't send them to #ubuntu-release.
<lifeless> ScottK: doh, I meant -party. Sorry.
<RAOF> pitti: Oh! I've remembered the question I was going to ask - is it possible to influence how the apport retracer munges the bug reports it touches?
<pitti> RAOF: not much right now, what are you trying to do?
<RAOF> pitti: I was thinking of post-processing the xserver backtraces and pulling out the interesting information - basically the top 4 frames of an xserver backtrace contain no useful information.
<pitti> RAOF: apport has a thing called "stack unwinding" which chops off things like the implementation details of g_assert() and g_log_(), to get to the "interesting" part
<pitti> RAOF: the trimming you want to do, would you say this applies to all X-ish backtraces, or is that just a special subset?
<RAOF> All xserver crashes, I think.
<pitti> RAOF: we don't currently have hooks which run on the retracer side, that would be too brittle and also insecure
<RAOF> Plus I'd like to pull out the signal that killed X.
<pitti> RAOF: the latter sounds like something which should happen on the client side?
<pitti> RAOF: ah, I remember that weirdness of X's signal handlers :)
<RAOF> Yeah - X catches everything and then abort()s
<pitti> RAOF: so perhaps apport on the client side should have some code to set Signal: to the real thing?
<pitti> and the stack unwinder should be updated to get rid of X' signal handlers/logging stuff
<RAOF> As long as we can get the signal out, yes.
<pitti> RAOF: as for the unwinding, the code is at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L714
<pitti> RAOF: and the corresponding tests at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/test/test_report.py#L1403
<pitti> RAOF: if that's all gibberish to you, I propose you file a bug with linking to a few example bugs, and explain what part of the stack trace shoudl be chopped off?
<RAOF> I'll have a butcher's.
<RAOF> Thanks.
<pitti> RAOF: i. e. you tell me how it should look like, then we transform that into test cases, and then hack gen_stacktrace_top() into submission
<pitti> RAOF: we actually already have X error handling there, but perhaps it's out of date
<RAOF> Yeah, we have _Xerror handling.
<lbbef> Hi, I would like to help update the blender package in the universe repo, how do i go about doing that?
<SpamapS> lbbef: #ubuntu-motu would be better, since its a universe package. But.. basically you'll want to follow the packaging guide..
<SpamapS> lbbef: https://wiki.ubuntu.com/PackagingGuide
<SpamapS> lbbef: note that the debian maintainer will likely update to 2.64a soon, and then that will sync/merge into the next release (raring) when auto-syncs start
<dholbach> good morning
<pitti> jibel: FYI, jhbuild doesn't run xvfb for "make check", only for some test modules (ldtp, dogtail)
<pitti> jibel: I'm filing an upstream bug now to discuss whether it should (I think it should)
<pitti> jibel: in the meantime, I'll work on a charm fix to run it through xvfb-run by itself, ok?
<jibel> pitti, ok.
<pitti> lool: bonne anniversaire!
<dholbach> lool, bon anniversaire, mon ami! :)
<didrocks> google betrayed him, right? :)
<pitti> didrocks: you mean me or lool?
<didrocks> lool ;)
<didrocks> that's how I noticed TBH, telling "oh this guy is olderâ¦" :p
<pitti> but lool's birthday _is_ today, unless he lied in the directory ;)
<didrocks> yeah, I meant, he couldn't lied in the directory and in google, there are prooves all over the place! :)
<pitti> jibel: https://code.launchpad.net/~pitti/charms/quantal/jhbuild/run-under-xvfb/+merge/130294
<pitti> jibel: I will now work on a config option to use jhbuild from git instead of the packaged version, as this is more appropriate and robust
<jibel> pitti, ok, thanks. I'll merge your xvfb change ASAP as the charm is under review for charmstore inclusion and it'd be nice to have it.
<pitti> jibel: *nod*
<pitti> jibel: hm, curious that you didn't stumble over the missing python-dbus package (glib tests fail due to that); I'm going to propose a merge
<pitti> jibel: MP sent for this, too
<jibel> pitti, I added on the internal instance IIRC, let me check.
<lool> pitti, dholbach, didrocks: Thanks all!  :-)
<jibel> pitti, actually dbus-python is a dependency of gnome-core but not glib, so the bug is in the moduleset. python-dbus should be built before not after glib
<pitti> jibel: ah, so it would work the second time
<jibel> pitti, yes, if you build all the packages of gnome-core, if you build only glib and it's dependencies it will fail.
<jibel> pitti, since I started by building everything without check to make sure all the build dependencies were met, I didn't notice.
<pitti> jibel: ok, then perhaps the MP is moot; I'll file an upstream glib bug with a suggested jhbuild patch
<pitti> jibel: oh, juju deploy only uses the bzr committed bits, not the uncommited ones?
 * pitti tears down test unit and retries
<pitti> jibel: oh, heh, can't
<pitti> jibel: dbus-python needs glib and GI to build
<pitti> jibel: so it'd be a circular dependency
<pitti> so perhaps installing the package would be ok after all
 * pitti makes a note in the MP
<bkerensa> cyphermox: is there any reason why ipv6 is set to automatic in 12.10 for network-manager? This seems to add anywhere from a few hundred milliseconds to a couple seconds of lag time when connection to networks that do not support IPv6
<bkerensa> ?
<bkerensa> !s/connection/connecting
<jibel> pitti, hm, it is not installed here and the test pass, unless I missed something. I'm rerunning a check of glib
<pitti> jibel: presumably it's installed in ~/gnome then?
<xnox> ivanka: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-landscape-fde
<jibel> pitti, correct, it is installed in ~/gnome/packages
<stgraber> bkerensa: ipv6 is enabled by default on Ubuntu because that's the right thing to do as it's getting more and more popular. However NM considers the network as up and running if any of ipv4 or ipv6 is working, so it shouldn't add any delay. If it does, file a bug so cyphermox can take a look.
<bkerensa> stgraber: ok
<bkerensa> stgraber: my understanding is its actually a known delay http://blogs.gnome.org/desrt/2011/06/14/quick-network-manager-note/
<bkerensa> stgraber: there also seems to be a bug in debian for it too
<stgraber> bkerensa: that blog post is pretty old... a lot of IPv6 work happened for 12.04 and 12.10, better talk to cyphermox
<bkerensa> stgraber: ok I will ping him
<pitti> jibel: there are more loops like that; I think building everything without --check first, and then again with --check is better
<develop7> hello all. What is *proper* way to get sources of package from precise with bzr? `bzr branch ubuntu:p/network-manager` says "bzr: ERROR: Not a branch:`,  `bzr branch ubuntu:precise/network-manager` says "bzr: ERROR: Revision {package-import@ubuntu.com-20120316143219-pj6ax8nyf4n504ry} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"."
<develop7> should I report a bug?
<cjwatson> yes, on launchpad.net/udd
<cjwatson> some packages just can't be fetched using bzr - the always-works method to get source for any package is still 'apt-get source PACKAGE-NAME' (or pull-lp-source from ubuntu-dev-tools makes it easy to get any version, if you want source for a version that doesn't match your running system)
<tumbleweed> (pull-lp-source is broken today, because it's quantal release day and it doesn't know about raring yet)
<Laney> deja vu
<develop7> cwatson, got that, thanks
<tkamppeter> pitti, can you have a look at bug 1026921? Will CUPS need some improvement here? Or should we simply tell the user to touch the missing file and all is OK?
<ubottu> Launchpad bug 1026921 in cups (Ubuntu) "package cups 1.5.3-0ubuntu1 failed to instal/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Invalid] https://launchpad.net/bugs/1026921
<pitti> tkamppeter: yeah, that shoudl work, and then sudo apt-get -f install
<tkamppeter> pitti, so we simply tell this to the user and close the issue?
<pitti> tkamppeter: yes, I think so
<develop7> I'm filling a merge request in LP. What is proper branch for merge request to network-manager in quantal? I'm aware it's frozen â I'm hoping my patch is going to hit proposed or something.
<develop7> here is branch itself â https://code.launchpad.net/~develop7/network-manager/dnsmasq-conf-dir-cherrypick
<tkamppeter> pitti, what I have seen is that if there is something wrong in /etc/cups/cupsd.conf making the CUPS daemon not start this blocks the whole apt-get mechanism. Should we improve on this somehow in R?
<develop7> This is cherry-pick from upstream, so there's no need to merge it to lp:network-manager
<pitti> tkamppeter: this is how Debian packages behave in general; I don't have a good answer to this, I'm afraid, as the other option is to leave it broken silently
<pitti> tkamppeter: if people or programs often mess up cups.conf, then changing the postinst to not fail on failed start might be an option, yes
<tkamppeter> pitti, or could the postinst then pop up a debconf like screen telling that the CUPS system could not be started and giving the option to continue or abort the installation?
<pitti> nono, please no debconf
<cjwatson> develop7: 'apt-cache showsrc network-manager' says lp:~network-manager/network-manager/ubuntu (but if you're filing a merge proposal against that, make sure you branched from that in the first place)
<tkamppeter> pitti, OK. debconf is really very complicated to set up and we should reduce its use.
<Andy80> hi, is there any know issue with Nvidia GeForce GT 640 graphic card? I've just upgraded my work machine to quantal and even if I'm using the same driver version (304.51), now the maximum resolution is 1024x768 while it was 1680x1050. p.s: on precise I was using the x-swat PPA to have 304.51 of course...
<develop7> cjwatson: that branch contains only debian directory. should I convert my branch to debian patch, and request a merge of patch, not source?
<cjwatson> develop7: yes
<develop7> cjwatson: awesome, thank you
<cyphermox> bkerensa: ipv4 and ipv6 gets done in parallel, there shouldn't actually be a delay caused by ipv6 if you don't have it; maybe file a bug so we can see what's wrong
<cyphermox> develop7: we already carry that upstream change in quantal.
<develop7> cyphermox: yeah, I've noticed that. whew.
<cyphermox> ok ;)
<cyphermox> oh, wait, perhaps I'm getting confused by a previous message, you want to SRU that to precise?
<develop7> cyphermox: well, that would be perfect, but I don't insist, I'm planning to upgrade anyway
<develop7> e.g. upgrade to quantal
<cyphermox> develop7: ok
<tkamppeter> pitti, seems that there are major problems with the AppArmor stuff in CUPS, see bug 1026921.
<ubottu> Launchpad bug 1026921 in cups (Ubuntu) "package cups 1.5.3-0ubuntu1 failed to instal/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Invalid] https://launchpad.net/bugs/1026921
<jdstrand> tkamppeter: I think that is overstating it. the main profile is installed in /etc/apparmor.d/usr.sbin.cupsd. the packaging will create /etc/apparmor.d/local/usr.sbin.cupsd. the main profile needs the second. the user doesn't have the second. it isn't clear the touch command was run
<jdstrand> the second is also intentionally not a conffile
<jdstrand> tkamppeter: if the cups packaging doesn't use dh_apparmor, then the packaging needs to create it
<jdstrand> I just did some iso testing yesterday and /etc/apparmor.d/local/usr.sbin.cupsd was created
<jdstrand> gotta run
<GunnarHj> Riddell: Hi Jonathan! Are you there?
<Riddell> GunnarHj: I am
<GunnarHj> Ridell: Great! I noticed that Kubuntu quantal is shipped without language-selector-kde. Does it mean that you have replaced language-selector with other code in Kubuntu, and that we may now drop language-selector-kde in the language-selector source package?
<Riddell> GunnarHj: might be best to wait until after UDS
<Riddell> I replaced it with a patch to the KDE language config tool, but it's a bit limited and doesn't have all the features
<Riddell> but going back to language-selector-kde isn't an easy option as we can't do python 3 plugins to kde system settings
<pitti> Riddell: well, we've been trying for several releases to get rid of it actually :)
<pitti> in favor of moving to the one from gnome-control-center (but that's still not on feature parity)
<Riddell> pitti: I know, this was my initial desire to change out, then the python 3 switch stopped a chance of changing back
<GunnarHj> Riddell: Really? I got the impression that your current language/locale thing is rather complete. But it's no hurry; it can of course wait til after the UDS.
<Riddell> it misses various things like setting up input methods and notifying if you don't have them all installed
<GunnarHj> Riddell: Ok, I see.
<GunnarHj> pitti: I'm going to write a document for UDS about differences between l-s and the region capplet in g-c-c.
<pitti> GunnarHj: ah, that's helpful, thanks!
<doko> hallyn, ping
<hallyn> doko: hi
<doko> hallyn, was just looking at your sparc cross toolchain packages? are these built for biarch sparc?
<hallyn> doko: i was just building for sparc64 (i think) so that the openbios-sparc package could be built from that for sparc32 and sparc64
<hallyn> doko: though i'm starting to think i don't need sparc, i only need powerpc
<doko> ahh, ok
<hallyn> hm, no, i guess we do.
<hallyn> doko: building for sparc32 would be a completely separate set of packages with almost identical soruce, iiuc
<hallyn> what on earth?  ppa says build failed, but https://launchpadlibrarian.net/119958672/buildlog_ubuntu-quantal-amd64.binutils-sparc-cross_1.86ppa1_BUILDING.txt.gz says it succeeded
<doko> hallyn, no my question was if the build is configured with --enable-multilib. But I assume you're not that interested in the packaging like it's done for the linaro arm cross packages
<hallyn> doko: oh.  right i just want to be able to use it to build openbios for qemu;  but i did use the arm packages as a base.
<hallyn> i don't see enable-multilib in the buildlog
<stokachu> infinity: ive got a definition addition for eglibc http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=cf7c9078a5acdbb435498ace92cd81009637a971
<stokachu> infinity: is this something you would entertainf or lucid?
<stokachu> infinity: a backport for libhugetlbfs exist in lucid https://bugs.launchpad.net/lucid-backports/+bug/1035365
<ubottu> Launchpad bug 1035365 in lucid-backports "Please backport libhugetlbfs 2.11-0ubuntu1 (universe) from natty" [Undecided,Fix released]
<stokachu> and i believe this patch is whats needed to make this work
<micahg> umm, if it didn't work, how did it "run"?
<infinity> stokachu: Do I want to know why we care about hugetlb in lucid and why we're not just telling people who need it to upgrade to precise?
<stokachu> infinity: lol probably not
<stokachu> infinity: however, if you say no (with a possible explanation) it is perfectly acceptable to run with that
<stokachu> to me this feels like a feature request whereas lucid is basically in a state of accepting crtical's and other bug fixes
<infinity> stokachu: Your explanation there seems like the right one.
<infinity> stokachu: That said, we still need to SRU the AVX disabling fix to lucid, so we could dump this in with it.
<stokachu> infinity: thats totally your call
<infinity> stokachu: I'm not against the change, it's minimal and auditable, just against upload for JUST that.
<stokachu> infinity: im currently building eglibc with the patch
<stokachu> infinity: ok sounds good -- ill finish the build and have the interested party test it
<stokachu> infinity: if all is well ill update the avx sru to include this other bug
<infinity> stokachu: That sounds reasonable to me.
<stokachu> infinity: cool, ill probably ping you in a couple days once the customer has tested
<stokachu> err 'interested party'
<stokachu> lol
<infinity> stokachu: Shiny.  I'd like us to get those old AVX SRUs out of the way so they stop nagging my TODO.
<stokachu> infinity: sweet, thanks man
<infinity> stokachu: And the one for lucid is really more just a violent "break AVX" fix, so less effort than precise's "fix it all to behave correctly" thing.
<infinity> stokachu: So, should be a bit easier (I hope) for us to verify.
<infinity> stokachu: Oh, I'm guessing you guys noticed that the precise one finally landed in updates?
<stokachu> infinity: we sure did
<stokachu> infinity++
<infinity> I should rebuild d-i for precise tomorrow for that.
<infinity> Maybe I'll wait for the current round of SRU kernels to land, and kill two birds with one stone.
<infinity> And fix the omap netinst bug too.
<infinity> So, three birds.
<infinity> That's some stone.
<Laney> poor birds
<infinity> They had it coming.
 * micahg thinks the kittens were behind it
<astraljava> So infinity was the one who stole the bird out of Xubuntu wallpaper. *grumble*
<stokachu> doko: if you got a second could you approve series nominations for bug http://pad.lv/802782
<ubottu> Launchpad bug 802782 in network-manager (Ubuntu) "Please add NetworkManager option not to auto-enable new network devices" [Wishlist,Confirmed]
<stokachu> babaei: die antwoord?
<doko> stokachu, done
<stokachu> doko: thanks! :D
<stokachu> doko: sorry one more, http://pad.lv/1068199, spoke with infinity on it and going to try and get this included with another SRU approved to go in
<ubottu> Launchpad bug 1068199 in eglibc (Ubuntu) "please add support for MAP_HUGETLB in eglibc for Lucid" [Undecided,New]
<doko> stokachu, done
<stokachu> doko: thanks again
<quadrispro> hello everybody
<mitya57> Does anybody think we can cherry-pick this lintian commit:
<mitya57> http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commitdiff;h=c04b5ad34c;hp=0c7245dcba
<micahg> mitya57: why?
<ScottK> There's no need.
<mitya57> to make lintian not complain about packages using s-v 3.9.4 that are built on quantal
<cjwatson> who cares :)
<babaei> stokachu: ummm, no?
<cjwatson> lintian output is meant to be read intelligently by humans
<cjwatson> who can ignore stuff that doesn't matter
<stokachu> babaei: saw your id as 'zef' was curious if you knew the south african rap group :)
<mitya57> OK, and will we teach it that raring is a valid codename?
<babaei> ah. nope.
<ScottK> In raring.
<ScottK> Once again, one can ignore it.
<stokachu> mitya57: in NC we have to euthanized raccoons because they are rabies vectors
<mitya57> OK.
<micahg> mitya57: I'd be happy to entertain a lintian backport if you're interested in testing the reverse dependencies, but yeah, what everyone else said
<micahg> (full backport, not cherry pick)
<slangasek> cjwatson: well, the difference between empty and non-empty lintian output has an annoying cost in attention in order to do that ignoring.... but meh, why would anybody be using the quantal lintian for 3.9.4 S-V packages
<mitya57> I've anyway filed bug 1068208 (with a patch attached) to get it fixed in raring at least
<ubottu> Launchpad bug 1068208 in lintian (Ubuntu) "Needs to know about raring" [Undecided,Triaged] https://launchpad.net/bugs/1068208
<micahg> wait, this fix isn't even in Debian yet?  Why would we bother...
<ScottK> mitya57: The usual practice is to update in Debian first.
<ScottK> slangasek: lintian will whine when you make a source package too, so for those of us that run current and build in sbuild/pbuilder, it'll definitely come up.
<mitya57> I don't know why you call it usual (bug 994208 was fixed in Ubuntu first), but I agree anyway
<ubottu> Launchpad bug 994208 in clang (Ubuntu) "Needs to know about quantal" [Undecided,In progress] https://launchpad.net/bugs/994208
<slangasek> ScottK: addressed by getting raring open and updating lintian there? :)
<ScottK> Certainly.
<ScottK> mitya57: Usual for lintian.
<stokachu> slangasek: ok i made those requested changes to appmenu-gtk for the build deps
<stokachu> slangasek: *hopefully* thats everything /me crosses fingers
<cjwatson> slangasek: well, yeah, exactly
<cjwatson> and there's always grep
<cjwatson> or lintian profiles if you want to overachieve
<micahg> stokachu: as mentioned in PM, I have the changes staged in the desktop VCS (my local copy with me changing the build-deps), it's ready for upload if that's ok
<stokachu> micahg: sorry i didnt see your PM light up :(
<stokachu> micahg: yes please do if thats ok
<micahg> stokachu: ok, uploaded
<stokachu> micahg: awesome thank you very much for your help
<micahg> stokachu: now I can't get the branch up though :(
 * micahg blames debcheckout
<stokachu> appmenu doesn't like change apparently :)
<micahg> stokachu: that was quantal, I'll upload precise a little later
<stokachu> sounds good to me
<tkamppeter> Are the ISOs linked on http://releases.ubuntu.com/quantal/ already the finals?
<ScottK> tkamppeter: #ubuntu-release-party - otherwise wait for the announcement like everyone else :)
* ChanServ changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion 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:
<mitya57> congrats to everybody!
<mapreri> Good work people! :)
<stokachu> infinity: ok i got that eglibc patch uploaded and sru done: http://pad.lv/1068199
<ubottu> Launchpad bug 1068199 in eglibc (Ubuntu Lucid) "please add support for MAP_HUGETLB in eglibc for Lucid" [High,In progress]
<ScottK> pitti: The HISTORY file for postgresql 9.1.6 says, "However, you may need to perform "REINDEX" operations to recover from,  the effects of the data corruption bug described in the first changelog item below." - Does that need some kind of debian/NEWS entry or such to let people know?
<stokachu> micahg: did the appmenu-gtk for precise go through yet?
<micahg> stokachu: no, not yet, I saw the unsubscribe sponsors thing though, it's still on my list
<stokachu> micahg: ok cool no worries
<nigelb> asac: Your twitter account seems to be sending spam via DM.
<nigelb> (FYI)
<alexbligh> possibly stupid question: on a normal boot, am I correct (as I believe) that the stuff in /etc/rc.S is not run? I am trying to work out why /etc/init.d/multipath-tools-boot (only run from rcS) needs to modprobe dm-multipath but /etc/init.d/multipath-tools (run from elsewhere) does not.
<sarnold> I've got no /etc/rc.S on my system any longer; is it a hold-over from earlier inits that you may have had installed?
<slangasek> alexbligh: /etc/rcS.d (assuming the previous path you gave was a typo) is run at boot.
<alexbligh> slangasek, hmm, even if one's going multi user? I never knew that.
<slangasek> yes
<slangasek> historically, it's the directory for scripts that do "put together enough of the system's brain so we can start a runlevel"
<alexbligh> slangasek, is it run from upstart these days then?
<slangasek> everything is run from upstart these days. :)
<bdmurray> slangasek: are you familiar with bug 1066445? I'd like to verify the fix in precise-proposed but the test case didn't work out.
<ubottu> Launchpad bug 1066445 in apt (Debian) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Unknown,New] https://launchpad.net/bugs/1066445
<bdmurray> well the alternative one at least
<slangasek> bdmurray: yeah, a test case for that is problematic, it basically comes down to hitting a magic cache size with the apt lists
<slangasek> bdmurray: you might want to start with the known-buggy version of apt in quantal, reproduce it there, and then downgrade to the precise apt to see if it's still reproducible
<asac> nigelb: thanks
<asac> nigelb: not sure... changed password and removed access to all apps in case that was it
<highvoltage> ~/win 11
<wmp_> hello, i have problem... on 12.10 i have only one thread on CPU
<wmp_> on 12.04 work good
<sarnold> wmp_: what's the output of 'uname -a'?
<wmp_> 3.5.0-17-generic
<wmp_> x86_64
<sarnold> no 'SMP'?
<wmp_> "inux wmp-AO722 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<slangasek> wacky
<slangasek> wmp_: please file a bug report against the linux package by running 'ubuntu-bug linux'; this will attach logs (dmesg, etc) that should help the kernel team figure it out
<wmp_> amd c-50 processor on acer aspire one 722
<wmp_> maybe i shoud use PAE kernel?
<ScottK> wmp_: On amd64, -generic is PAE.
<ScottK> Actually it's PAE on i386 now too.
<slangasek> on amd64, there's no such thing as PAE
<ScottK> Right.
<slangasek> (since PAE is a kludge to give you paged access to a larger space than is addressable in 32 bits)
<wmp_> hmmm, interesting
<wmp_> after reboot i go to bios setup
<wmp_> exit without save changes
<wmp_> and go to rescure mode
<wmp_> and from root in rescure i have 2 threads
<wmp_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1068340
<ubottu> Launchpad bug 1068340 in linux (Ubuntu) "I havent second thread" [Undecided,New]
<sarnold> wmp_: "Booting paravirtualized kernel on bare hardware"
<sarnold> oh, never mind, I've got that too. :/
<wmp_> ? i dont understand
<wmp_> ok
<wmp_> :)
<wmp_> so i go try if in rescur ei have 2 threads
<sarnold> "CPU1: Not responding."
<wmp_> lol
<wmp_> now i have 2 threads
<wmp_> and i dont know why
<sarnold> wmp_: from your dmesg, "CPU1: Not responding."
<wmp_> now i havent this, but before yes
<wmp_> and now i installing amd64-microcode
<wmp_> sarnold: can i reboot or you want to check some?
<sarnold> wmp_: don't mind me, I think your problems are well beyond my abilities  ;(
<wmp_> ;(
<sarnold> wmp_: I'm just afraid you may have dying hardware
<wmp_> sarnold: so why on 12.04 work good? :D
<wmp_> ok, reboot
<wmp_> and one thread :(
<sarnold> wmp_: I don't know why 12.04 would have supported more, but 12.10 doesn't. It _is_ strange..
<wmp_> sarnold: now i try with noapic acpi=off
<sarnold> wmp_: acpi is required to enumerate hyperthreads
<wmp_> sarnold: but on 12.04 i have acpi=off
<wmp_> and: http://ubuntuforums.org/showthread.php?t=1740798
<sarnold> wmp_: oh, are these real cores?
<wmp_> i dont know
<wmp_> but maybe yes
<wmp_> The number of cores	2
<wmp_> yes
<wmp_> ok, reboot
<slangasek> pitti, cjwatson: hey, I could use some clarification around the GNOME SRU MRE.  The wiki page says "only the core modules and apps"; the TB discussion says "what is released with GNOME in the usual cadence"; either way it's not entirely obvious to me how to figure out if a particular piece of software (e.g., gnome-orca) is or is'nt
<stgraber> slangasek: the DMB has a list somewhere, let me dig it out quickly
<slangasek> stgraber: oh?  I wouldn't have assumed that the MRE set maps directly to a packageset?
<stgraber> slangasek: nope, but we have a packageset that's defined as "take the list of gnome components and ignore those in the desktop packageset", so the same upstream list should qualify as "what is released with GNOME in the usual cadence"
<slangasek> stgraber: hmm, ok
<slangasek> stgraber: is that list published somewhere, that the MRE wiki page could link to directly?
<wmp_> nothing
<wmp_> and with noacpid i havent wifi
<wmp_> and in dmesg i have: [    0.274307] Brought up 1 CPUs
<stgraber> slangasek: we look at http://git.gnome.org/browse/jhbuild/tree/modulesets and look at gnome-apps, gnome-suites-core and gnome-suites-core-deps for the current gnome release in the archive. Those files need a bit of parsing to get the actual components.
<stgraber> I vaguely remember someone wanting to write a reasonable parser for that stuff, doesn't look like it happened though and those seem to have grown quite a bit since I last looked at them (was fairly readable back then...)
<stgraber> yeah, definitely quite a mess at the moment, you actually have to look at the comments to find the right stuff, for example, for -apps you need to start looking at "<!-- Apps start here -->" as everything before that is just dependencies
<cjwatson> bdmurray: possibly tweaking the value of APT::Cache-Start randomly might help ...
<cjwatson> (defaults to 24MiB IIRC; note that the man page lies)
<wmp_> ok, work good after turn off and turn on
<wmp_> after reboot i have only one thread
#ubuntu-devel 2012-10-19
<hyperair> hmmm ubuntu's switching to systemd?
<hyperair> http://www.markshuttleworth.com/archives/1200#comment-397370 <-- is this for real?
<micahg> hyperair: not a reliable source of information
<micahg> * i.e. no clear relation to the project
<RAOF> hyperair: I don't know why you'd get that impression.
<hyperair> RAOF: i figured it would have been flamed to hell already if it wasn't true.
<hyperair> RAOF: so the lack of flames were a cause of concern.
<ajmitch> hyperair: I think the lack of flames are probably due to moderated comments
<RAOF> Possibly also that it's basically just noise.
<hyperair> heh
<ajmitch> hyperair: might as well write that there's 'no question' that unity will be rewritten in C# :)
<hyperair> ajmitch: good idea!
<ajmitch> hyperair: it's probably on news sites already after commenting on it in here
<RAOF> ajmitch: I'd support that!
<ajmitch> RAOF: think of how confusing it'd be to have unity & unity3d, both in C# :)
<pitti> Good morning
<ajmitch> morning pitti
<pitti> ScottK: I put it into the changelog; I haven't maintained a NEWS file for postgresql so far, perhaps I should for stuff like that
<ScottK> pitti: I suppose that'll do, but I think NEWS is better.
<pitti> slangasek: GNOME SRUs> A good indication is the version number, it should be 3.6.x for quantal; but that is indeed a bit blurry
<pitti> hey ajmitch
<ScottK> pitti: Done.
<pitti> ScottK: done what?
<ScottK> pitti: Accepted the SRUs.
<pitti> oh, the ecpg one; thanks!
<ScottK> pg on precise and quantal.
<slangasek> pitti: ah, good point.  Well, stgraber provided pointers to the upstream module definitions, which is probably good for now.
<pitti> skaet, cjwatson, stgraber, infinity, release team: congrats to the final release! that was a rather difficult birth
<ScottK> I think it would have been a lot smoother with less last second featuritis.
<slangasek> TheMuso: hey, is there really any reason for us to ship libasound2-python?  Debian doesn't ship the smixer plugins at all; I can't find any documentation for how this plugin is supposed to be used, and it's definitely not ported to python3
<invalidopcode> This is probably a simple answer but can one "clone" a package from a public launchpad project and then build the project easily?
<ScottK> invalidopcode: You probably want #launchpad.
<invalidopcode> ScottK: okay, thanks.
<invalidopcode> I'm trying to work on the
<invalidopcode> lp:ubuntu/quantal/pidgin-libnotify project, that's why I asked here
<slangasek> invalidopcode: 'bzr branch lp:ubuntu/quantal/pidgin-libnotify' is the bzr equivalent of a git clone
<slangasek> as for building, you perhaps want 'dpkg-buildpackage'
<invalidopcode> okay, thanks! I'll try that
<invalidopcode> slangasek: it gives me "dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ..."
<slangasek> invalidopcode: ah - so you should probably install the bzr-builddeb package, and run 'bzr bd' instead of 'dpkg-buildpackage'
<invalidopcode> ah thanks! It seems to be going now :)
<invalidopcode> it seems to complain about not being able to sign the package
<invalidopcode> it might be because I haven't logged into launchpad
<invalidopcode> but if I'm just doing dev, do I need to sign the package?
<slangasek> invalidopcode: that will be because you haven't set up your environment with a pgp key; and no, you don't need to sign the package
<slangasek> invalidopcode: there are some pages somewhere that talk about this initial env setup, let me see if I remember where they are
<invalidopcode> okay thanks!
<invalidopcode> yeah I don't want to keep bothering you if I don't have to
<slangasek> http://developer.ubuntu.com/packaging/html/getting-set-up.html
<invalidopcode> thanks
<invalidopcode> I'm new to the Ubuntu dev community... I'm more familiar with the Archlinux pkgbuild system :)
<invalidopcode> slangasek: after following all those steps it still fails with "gpg: /tmp/debsign.UclxAL3H/pidgin-libnotify_0.14-4ubuntu11.dsc: clearsign failed: secret key not available"
<slangasek> invalidopcode: so in order for debsign to know which key to use, either your PGP key's UID must exactly match the uploader field in debian/changelog, or you need to pass -k<keyid> to tell it which key to use.  (for instance, if you're signing a package that someone else prepared, you need to use this latter option)
<slangasek> invalidopcode: however, if you're not actually uploading this anywhere, you can use the -uc -us options instead: bzr bd -- -uc -us
<invalidopcode> ah okay
<invalidopcode> thanks
<invalidopcode> yay! it worked :)
<invalidopcode> thanks for all the help slangasek!
<invalidopcode> is the new libmessaging-menu library this http://developer.ubuntu.com/api/ubuntu-12.10/c/messaging-menu/ ?
<invalidopcode> disregard the stupid question :)
<invalidopcode> okay last question. slangasek. what does one to do fix "aborting due to unexpected upstream changes"?
<slangasek> invalidopcode: that depends on what those changes are... you might run dpkg-source --commit to keep them, or bzr revert to get rid of them
<invalidopcode> so for every change I make I have to do that before building?
<slangasek> well
<invalidopcode> or is there a better way to do quick development?
<slangasek> if you're testing the build, you can also pass -b to bzr bd
<slangasek> and skip the source package generation, which is what's failing here
<invalidopcode> okay
<dholbach> good morning
<hallyn> slangasek: so i'm playing with the debian experimental qemu git branch that's taking the place of qemu-kvm soon.  working well for me.  i looked at a diff to the qemu-linaro git tree, and it seems contained enough to arm stuff that it would seem fine to add as a patch, imo, to consolidate the trees.  (there are other barriers of course)
<hallyn> something to talk about at uds if nothing else
 * hallyn calls it a night
<obounaim> Good morning
<jibel> mvo, good morning
<jibel> mvo, I found bug 1068389 this morning
<ubottu> Launchpad bug 1068389 in ubuntu-release-upgrader (Ubuntu) "P->Q - do-release-upgrade crashed with UnicodeEncodeError: 'ascii' codec can't encode character u'\xbb' in position 1: ordinal not in range(128) in DistUpgrade/DistUpgradeViewText.py", line 143, in showInPager" [Critical,Triaged] https://launchpad.net/bugs/1068389
<mvo> jibel: thanks, let me have a look
<tjaalton> is there a way to disable automounting certain media/mountpoints?
<pitti> tjaalton: put them into fstab (LABEL= or UUID=) and don't mark as "auto"
<tjaalton> pitti: ah, thanks
<sarnold> tjaalton: 'noauto' in fstab(5) :)
<tjaalton> yeah I thought there was a "newer" method :)
<tjaalton> but this works too
<mvo> jibel: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2581 - I will upload that now
<jibel> mvo, thank you
<mvo> jibel: thank you for finding it!
<jibel> pitti, about https://code.launchpad.net/~pitti/charms/quantal/jhbuild/jhbuild_from_git/+merge/130365
<pitti> jibel: oui?
<jibel> pitti, I'd rather not delete the local copy on configuration change or upgrade and preserve any change the user could have made locally
<jibel> pitti, what do you think ?
<pitti> jibel: you mean in the checked out jhbuild tree?
<jibel> pitti, right
<pitti> jibel: I can change it accordingly, yes
<pitti> jibel: i. e. [ -d jhbuild ] || git clone jhbuild?
<pitti> jibel: d'accord, I'll change it accordingly
<jibel> this 2 lines +        rm -rf jhbuild
<jibel> +        git clone git://git.gnome.org/jhbuild
<jibel> as it can be an unpleasant surprise
<pitti> jibel: right, and the ones below that for autogen and make
<jibel> yes
<pitti> jibel: did they approve your charm now?
<pitti> jibel: you said yesterday you wanted to wait with the merges until that happened
<jibel> pitti, not yet but the fixes are safe, and xfvb something we want by default.
<pitti> jibel: ah, so we'll shelve the jhbuild-from-git one for now?
<pitti> jibel: good, then I'll continue with my pygobject stuff today, and get back to the charm on Monday
<mpt> ev, so, what are the possible causes of a spike
<ev> jockey
<mpt> (1) There's a big new bug: unlikely, since we were in Final Freeze, and the table doesn't show anything obviously new.
<mpt> (2) People installing from scratch experience bugs disproportionately to pre-release testers, e.g. bugs in the installer or, yes, jockey.
<ev> A binary program crash that's suddenly appearing and not showing up on the front page because the retracers are down (thanks gnat-gps).
<mpt> But the first ubiquity problem is #68, jockey #45.
<mpt> ah
<ev> So there were 18187 reports for 12.10 yesterday, compared with 6320 the day before.
<mpt> (3) There's something wrong with the denominator in the calculation. We're counting many fewer users than we should be.
<mpt> (Or fewer machines, rather.)
<ev> hmmm, suspicious: there were 63630 unique systems for the 90 day period ending yesterday. There were 565335 for the 90 day period ending on the 17th.
<ev> That's not as big an increase as I would suspect.
<mpt> UTC, right?
<ev> yes
<mpt> 12.10 was out for only ~6 of those hours.
<ev> sure
<ev> so we should definitely see how much the unique system in a 90 day period count grows after today
<ev> but this still doesn't explain the big upward swing of reports
<jtaylor> is there a way we can modify the fontconfig deprecation warning? it is not clear at all what it wants you to do.
<jtaylor> "Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated."
<Laney> it's software, so yes
<sladen> jtaylor: apt-get source fontconfig && grep -r "is deprecated" fontconfig-*
<jtaylor> I'm just looking at it
<jtaylor> would a patch be accepted for an sru?
<sladen> concentrate on fixing the next release, and think about SRU as a secondary wishlist
<sladen> I believe the general tendancy is to ask/warn a user if they are able to do something about it (and tell them how), or not bother them with science if they can do nothing about them.  Thus, either fixing it to a proactive comment, or disabling both make sense
<cjwatson> ev: oh, sorry, I promised to deal with the gnat-gps SRU didn't I
<cjwatson> done
<dupondje> Somebody else is noticing shutdown issues sometimes?
<ev> cjwatson: thanks! And no worries at all - I wasn't expecting anything to happen yesterday, given the release
<ev> mpt: responding to your PM here: yes, sorry, that should be 56335 systems in the 90 day period ending yesterday
<mpt> ev, another example of (2) might be the RecoverableErrors, if people install and then try to install a bunch of apps
<ev> mpt: yes, but we separate out the effect of RecoverableErrors into its own line
<mpt> ev, not yet :-)
<mpt> oh, I see on poppy-dev
<ev> :)
<mpt> it goes up just as high
<doko> barry, ping
<mpt> ev, just throwing ideas out there, but do you have something like an off-by-one error in the period you're counting users in? E.g. dividing the number of errors for yesterday by the period up to the day before?
<mpt> (...by the number of computers in the period up to the day before, I mean)
<ev> I'll do a review of the code now
<mitya57> barry, doko: please don't add python3.3 to supported versions until python-docutils is fixed
<mvo> stgraber: could you have a look at #1068614 please? probably something relatively easy to fix on the server
<mitya57> I would prefer to upload docutils 0.9.1 with some cherry-picked patches, but that would require uploading python-roman
<mitya57> and MIRing it
<mitya57> is that possible before the archive opens?
<mitya57> https://code.launchpad.net/~mitya57/ubuntu/raring/python-roman/1.4.0-1ubuntu1
<mitya57> otherwise I can try to backport those patches to 0.8
<doko> mitya57, where is the MIR?
<mitya57> doko: I haven't filed it because the package is not yet uploaded
<mitya57> should I do that?
<ScottK> mitya57: Given that the python3-defaults patch for 3.3/multi-version support is incomplete, I don't think we'll have it at the open in any case.
<doko> yes please, and upload the package
<doko> ScottK, ?
<mitya57> I think he means issues with pyqt
<ScottK> doko: See my last mail to -devel.  I tried barry's patch and it didn't work out so well.
<ScottK> mitya57: Yes, but I don't think it was an issue specific to that package.
<doko> hmm, it did work for me for a simple extension. if just qt4 fails, then let it fail ...
<ScottK> I'll try another one.
<mitya57> MIR done (bug 1068630), so are we uploading new python3-defaults before the archive opening?
<ubottu> Launchpad bug 1068630 in Ubuntu "[MIR] python-roman" [Undecided,New] https://launchpad.net/bugs/1068630
<stokachu> cjwatson: i was in the process of converting gnome-keyring to multiarch and noticed in the rules file it does this install -m0755 -D debian/gnome-keyring.ubiquity debian/gnome-keyring/usr/lib/ubiquity/target-config/50gkd-caps, i didnt see ubiquity as an rdepends so was wondering what implications this has
<stokachu> or if ubiquity will never be multi-arched i guess it wouldn't mattter
<cjwatson> The lack of a dependency doesn't matter - it just provides a hook for ubiquity to run in case it is installed
<cjwatson> There's no reason for ubiquity ever to be multi-arched as far as I know, so if this is in a multi-arch: same package then you just need to make sure it's identical across architectures as usual
<stokachu> libgnome-keyring is MA: same
<stokachu> so should be ok then
<mitya57> doko: ^
<mitya57> and I'm thinking of going with an svn snapshot of docutils because it includes my patch for debian bug 677929.
<ubottu> Debian bug 677929 in python-docutils "python-docutils: remote copy of MathJax needed to render maths" [Serious,Open] http://bugs.debian.org/677929
<stgraber> mvo: hmm, yeah, that's fixable on the server. I'll assign that one to me
<mvo> stgraber: thanks
<doko> mitya57, and the docutils upload?
<mitya57> doko: so I should do it now?
<doko> mitya57, yes, both please
<mitya57> doko: OK, doing
<doko> mitya57, did you upload?
<mitya57> I've prepared it, will now file a bug report and upload tarballs there
<mitya57> I'm not a core developer :)
<mitya57> doko: bug 1068667
<ubottu> Launchpad bug 1068667 in python-docutils (Ubuntu) "Please upload docutils 0.9.1+svn7532-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1068667
<mitya57> I'm not able to test it now thoroughly because I have to go
<mitya57> But I can do that tomorrow
<mitya57> doko: ^^
<mitya57> and the branch with python-roman packaging is at 1048259
<mitya57> *bug 1048259
<ubottu> Launchpad bug 1048259 in Ubuntu "[needs-packaging] python-roman" [Wishlist,Confirmed] https://launchpad.net/bugs/1048259
 * mitya57 has to go offline now, sorry :(
<mitya57> I'm back :)
<stokachu> stgraber: bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"., know anything about this? happens when doinga bzr branch lp:ubuntu/quantal/ssd
<stokachu> sssd*
<Laney> stokachu: I suggest you file a bug on launchpad.net/udd
<stokachu> Laney: ok will do thanks
<tumbleweed> there's a source package called ssd?
<Laney> sssd
<tumbleweed> I see 'ssd' in the pasted URL
 * Laney shrugs
<stokachu> oh
<Laney> typo
<stokachu> rofl
<Laney> laney@quantal> bzr branch lp:ubuntu/quantal/sssd                                                                                      ~/temp
<Laney> bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<tumbleweed> right :)
<stokachu> cjwatson: if you got a few seconds could i get appmenu-gtk and libgnomecanvas approved in the upload queue for precise?
<mitya57> doko: attached tested and updated tarballs to bug 1068667, will you sponsor it?
<ubottu> Launchpad bug 1068667 in python-docutils (Ubuntu) "Please upload docutils 0.9.1+svn7532-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1068667
<cjwatson> stokachu: Won't running dpkg-query in an Xsession.d script slow down desktop startup performance?
<cjwatson> stokachu: And shouldn't this get into a development release first?
<stokachu> cjwatson: is raring open for that now?
<stokachu> cjwatson: startup performance maybe affected by a small amount
<cjwatson> It could be quite significant - opening the dpkg database can be expensive
<cjwatson> I think this needs to take a file-based approach instead
<cjwatson> Perhaps use a wildcard?
<stokachu> cjwatson: hmmm i could do that
<stokachu> all arch are basically similar in where its put right? /usr/lib/<arch>/..
<stokachu> i wasn't sure for arm etc
<cjwatson> It's always one subdirectory down, yes
<cjwatson> The name of the subdirectory isn't necessarily what you expect of course
<stokachu> yea i can try that approach and see
<cjwatson> stokachu: huh, I see slangasek suggested the dpkg-query approach
<stokachu> cjwatson: lol i didnt want to say anything :X
<cjwatson> slangasek: ^- did you consider the desktop startup performance implications of calling dpkg-query in Xsession?
<stokachu> the plot thickens :D
<cjwatson> The question of what happens if it's missing is a bit murky anyway, because surely it depends on which architecture of libgtk is running that might try to load it
<cjwatson> Or something
<stokachu> cjwatson: from my tests it works either way
<cjwatson> stokachu: so, unclear about appmenu-gtk, but libgnomecanvas is nice and simple - there were two roughly-identical copies of it in the queue, so I accepted the first and rejected the second
<infinity> stokachu: conffiles can be arch-specific, I'd just generate it at build-time with the full path.
<cjwatson> infinity: not in a multi-arch: same package
<cjwatson> see the bug :)
<infinity> cjwatson: Oh, it's in the library.  Ick.
<slangasek> cjwatson: hrm, there was a vague tickle in the back of my head, is this actually having a noticeable startup impact?
<infinity> But if it's MA:same, the dpkg-query defeats the entire purpose.
<infinity> Since it's going to tell you if you have your primary-arch version installed.
<infinity> Which may or may not be what you wanted to know.
<slangasek> it is
<slangasek> this config file is used to set a single environment variable that affects all versions of gtk
<infinity> Yes, but.  How does that relate to what I just said?
<slangasek> either you have some version of appmenu and you want to set it, or you don't have any and you don't set it
<slangasek> oh, sorry, misparsed
<slangasek> no, that query doesn't just return for the primary arch
<slangasek> try it and see
<cjwatson> slangasek: I haven't profiled it, but it would definitely seem to me to be a concern
<cjwatson> If we're cracking down on forks during boot, forking something that loads a substantial text database just seems unwise :)
<stokachu> cjwatson: i think i attempted the file based check first and slangasek mentioned that wouldnt work
<stokachu> i'd have to go back into the notes and see why that was
<infinity> slangasek: I bed to differ.  I just installed sl:i386 (so, not having the amd64 one installed at all) and, as I expect, I get "unknown ok not-installed" for sl, and "install ok installed" for sl:i386
<infinity> slangasek: So, I maintain that if your appmenu-gtk doesn't match your dpkg arch, this fails.
<mitya57> doko: so will you sponsor that or no?
<infinity> slangasek: Which kinda seems to defeat half the point of multiarching.
<slangasek> infinity: that's not a multi-arch: same package
<cjwatson> The dpkg-query call takes ~0.2s here after dropping caches
<stokachu> cjwatson: barely enough time to sneeze! :D
<cjwatson> stokachu: tight budgets
<ScottK> It all adds up.
<slangasek> cjwatson: fwiw the tickle in the back of my head also said "what is this crazy design, why are we exporting variables instead of just letting gtk probe it on the filesystem"
<cjwatson> slangasek: So for "some version of appmenu is installed", why not just glob over @moduledir@/*/libappmenu.so and test if any of the results exist?
<slangasek> infinity: that's not how the dpkg-query output for libc6 looks, to take an example M-A: same package
<cjwatson> Equivalent and faster
<slangasek> cjwatson: yeah, that should be fine too
<infinity> slangasek: That would be hard for me to test, given that it's impossible to remove the native libc6...
<cjwatson> for x in @moduledir@/*/libappmenu.so; do if [ -e "$x" ]; then ...; break; fi; done
<cjwatson> stokachu: ^-
<cjwatson> maybe -f rather than -e to match the original
<slangasek> cjwatson: I think I didn't recommend that because of an aversion to dealing with globs in shell scripts
<slangasek> clearly that did not serve me well here :)
<cjwatson> The above is my standard form, and avoids the usual no-nullglob-related bug
<slangasek> stokachu: cjwatson's approach is definitely better
<stokachu> so no immediate issues with globs then?
<cjwatson> If the design is to test whether *any* libappmenu.so is available, then the glob approach should work
<stokachu> ok, cool! ill work on getting that implemented and retested
<cjwatson> I don't know whether gtk breaks if $UBUNTU_MENUPROXY is unavailable
<stokachu> the original menus are used
<cjwatson> OK, good
<stokachu> yea i tested that when i broke the build :D
<micahg> a fs grep is faster than dpkg-query?
<infinity> micahg: In that case, sure.  It's not a find /
<infinity> slangasek: I'm curious what you mean by libc6 output looking different.
<stokachu> slangasek: and do you ever hear a giggle in the back of your head?
<infinity> slangasek: (Purely academic now, since he's not using this approach)
<Will123456> hey guys. when you view windows scaled back in the overview/spread mode in either unity or gnome shell, it seems like there's no point in drawing all the UI chrome, buttons and scrollbars and so on. it's an ambitious idea in terms of requiring toolkit/application support, but is the idea of being able to request applications draw only their "content", rather than UI chrome a realistic idea?
<Will123456> (and/or a useful idea)
<Will123456> an example would be libre office drawing only the text and hiding toolbars, gimp only drawing the image being worked on and none of the toolboxes, calculator only displaying the current result
<infinity> slangasek: Just to show I'm not insane, http://paste.ubuntu.com/1289641/
<cjwatson> Will123456: #ubuntu-unity might be better for that kind of thing
<ScottK> infinity: That only shows this isn't evidence of insanity.  It's not proof otherwise.
<infinity> ScottK: ...?
<infinity> ScottK: Oh, right.
<infinity> ScottK: Yes, I'm clearly insane, we all know that, just not in regards to this. :P
<cjwatson> insane on at least one side
<Will123456> cjwatson: good call, i'll ask there
<stokachu> cjwatson: hmm, i think im going to have to use /usr/lib/*/ rather than moduledir
<stokachu> moduledir expands to /usr/lib/<arch>/gtk-2.0/2.10.0/menuproxies/*/libappmenu.so
<stokachu> and that won't even work fully
<stokachu> i could glob 3 spots perhaps
<slangasek> infinity: http://paste.ubuntu.com/1289689/ fwiw :)
<infinity> slangasek: izzat quantal or precise?
<slangasek> infinity: quantal
<infinity> slangasek: Ed zachary.  His upload is to precise.
<cjwatson> stokachu: Ah, right, I wasn't clear on the exact directory layout
<cjwatson> stokachu: Maybe there's some other piece you can extract from the build system; or *cough* run sed over @moduledir@
<stokachu> so i guess my question is that acceptable to do /usr/lib/*/*/*/menuproxies/libappmenu.so
<cjwatson> That doesn't feel right
<stokachu> yea
<cjwatson> maybe you can get hold of the gtk-2.0/2.10.0/menuproxies part separately
<stokachu> cjwatson: http://paste.ubuntu.com/1289701/
<stokachu> line 36 starts where it handles the appmenu.in portion
<cjwatson> but you could always use shell's text processing facilities
<cjwatson> moduledir=@moduledir@
<cjwatson> moduledir_suffix="${moduledir#/usr/lib/*/}"
<cjwatson> etc.
<cjwatson> then you can look at /usr/lib/*/$moduledir_suffix/libappmenu.so, or something like that
<stokachu> ok ill dig into it some more to see what i can come up with
<infinity> stokachu: What's the full path?
<stokachu> infinity: http://paste.ubuntu.com/1289706/
<stokachu> that was with the splat in there
<infinity> stokachu: No, the full path.  What's that extra * expand to?
<stokachu> infinity: well thats all that is put into 80appmenu from the configure
<stokachu> only @moduledir@ is expanded to what you see there
<cjwatson> Yeah, that certainly won't work, try my moduledir_suffix stuff instead
<stokachu> the splat was what i put in there
<infinity> stokachu: What I mean is, where is the actual file?
<stokachu> infinity: oh just remove the splat
<cjwatson> infinity: /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so
<stokachu> and that would be the full path
<infinity> stokachu: I'm going to assume a splat is an asterisk? ;)
<stokachu> yea sorry
<stokachu> lol
<infinity> cjwatson: Right, and globbing works fine, if that is used, then.
<cjwatson> Just a matter of picking the expansion of @moduledir@ apart in shell.
<infinity> Yeah.
<drizt> hi.
<drizt> i opened bug with nfs-utils on launchpad two weeks ago but still didn't get any answer.
<drizt> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1062022
<ubottu> Launchpad bug 1062022 in nfs-utils (Ubuntu) "exportfs crash with long path" [Undecided,New]
<drizt> also I opened the same bug on Red Hat bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=863054. And the result: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=a16f4a13677d13b0aae9327a3b9e8414470b7927;hp=b010d126bbb8265e5717e596711d754baec11e6c
<ubottu> bugzilla.redhat.com bug 863054 in nfs-utils "exportfs crash with long path" [Unspecified,New]
<nod> hi.  i noticed some errors during an "apt-get update" and was told I should drop this here. http://33ad.org/pb/vp
<nod> this was about 15 mins ago.  I tried again just now and it seemed to sync ok, so not sure what the transient issue was related to
<hallyn> ^ more W: Failed to fetch bzip2:/var/lib/apt/lists/partial/it.archive.ubuntu.com_ubuntu_dists_precise-updates_main_source_Sources  Hash Sum mismatch
<sarnold> nod: it looks like there's three it.archive... mirrors; try it a few times and see if it comes back?
<nod> it's completed already now, i just thought you guys might want to know
<nod> i'm more concerned from an infrastructure standpoint and not this silly vm I'm hacking on :)
<infinity> nod: It's not a mirror we directly control, so not a whole bunch we can do about it sometimes being skewed.
<sarnold> :)
<infinity> (Except to take away their CC DNS entry, but that's probably not necessary here)
<nod> interesting. could clock skew introduce issueslike that?
<nod> i'd figure it's just a simple rsync of some flat file structure
<infinity> nod: It's a flat file structure, but if the Release and Packages files need to match.
<infinity> nod: Most mirror admins run scripts to try to mitigate the windows between those two being transferred to seconds (or less), some don't care and it can be minutes.
<infinity> nod: Err, that first sentence took a turn when I lost context elsewhere.  "if the Release and Packages files don't match, you get that error" is what I meant to say. :P
<nod> heh i grok'd.
<infinity> nod: Which is, of course, a feature.  The bug is that they can not match while a mirror is updating.
<infinity> (Which is a bug in how we publish the archive and/or in how people mirror it, depending on where one likes to place blame on days that end in 'y')
<cjwatson> Also web caches occasionally get unlucky and then get stuck on the mismatching versions until they expire.
<infinity> cjwatson: Yeah, that can be unfortunate.
<nod> quirky. so it's not an atomic operation by moving to an alternate location, then flipping over to the new repro?
<cjwatson> Figuring out the relevant URLs and running wget --no-cache on them can sometimes clear this for an entire office-worth of people at once.
<cjwatson> nod: Unix doesn't have atomic directory replacement
<infinity> nod: It is on our end, we don't dictate what mirrors do.
<cjwatson> It's not even on our end
<nod> cjwatson: symlinks :)
<cjwatson> It's just close
<cjwatson> Well, OK, I guess
<infinity> cjwatson: It is on our end on the publishing side is what I meant, as in, we don't push mirrors until ftpmaster is consistent.
<cjwatson> nod: But even then, a client's update could straddle the symlink change
<cjwatson> So that doesn't really solve the problem ...
<nod> other option is to rewrite httpd config to new loc then send HUP
<cjwatson> Same problem
<nod> yeah.. good point
<infinity> The problem is only solvable by subtle mangling the archive format, and we've talked about it a lot.
<infinity> Some day, someone might write the code to actually make it happen.
<cjwatson> Right, we had a plan to put everything in SHA-512-named files or similar
<infinity> cjwatson: Yeah, I vaguely liked that one.  Ugly to humans, simple for computers.
<nod> alright... this conversation is getting too interesting.  i can't continue or i'll get distracted from paying the bills with cool stuff.
<cjwatson> Mitigatable for humans with symlinks.
<cjwatson> More or less.
<nod> thx all for your help. bbl when i can spare cycles
<infinity> The ugly to humans bit being solvable by linking Packages to the "current" SHA.
<infinity> Jinx.
<infinity> And the above is necesarry to provide backward compat anyway.
<hallyn> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion 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: hallyn
<stokachu> neat gnome-keyring places gnome-keyring-prompt in /usr/lib/gnome-keyring
<stokachu> on precise
<stokachu> i think ill mess with that and appmenu on monday
<ahasenack> hi!
<ahasenack> with the release over, I wonder if someone has time
<ahasenack> to look over this SRU of mine: https://bugs.launchpad.net/landscape-client/+bug/1053057
<ubottu> Launchpad bug 1053057 in landscape-client (Ubuntu Oneiric) "Client queues up lshw calls if talking to old server" [Undecided,New]
<ahasenack> just precise was uploaded so far
<ahasenack> (to proposed)
<hallyn> ahasenack: the SRU team is a few weeks behind.  thanks for your confirmation of that bug(fix) though.
<ahasenack> hallyn: ok, thanks
<slangasek> ahasenack: are you looking for upload sponsorship or SRU processing, though?
<slangasek> SRU processing we're getting caught up on (I'm on deck today)
<ahasenack> slangasek: sru review/processing
<slangasek> ah, ok
<slangasek> yeah, I tend to process SRU queues newest release to oldest so I'm not sure if I'll make it to oneiric & earlier today
<ahasenack> slangasek: ok, thanks anyway
<slangasek> but hopefully we'll get the queue down far enough to solve the starvation problem this coming week
<alex-foo> what does ubuntu use for file indexing these days?
<sarnold> alex-foo: I've got the mlocate package providing my /etc/alternatives/locate ...
<alex-foo> for desktop search, i mean.
<sarnold> ah.
<alex-foo> i think it used to be beagle, then used to be tracker
<slangasek> zeitgeist
<dobey> well, zeitgeist isn't an indexer
<dobey> and the unity lenses do various different things; they don't integrate into a single search solution like tracker or beagle.
<fishor> cyphermox, hi. i need your help.
<fishor> in gnome-bluetooth, each device has proxy, but not each proxy has device. is it correct?
<fishor> cyphermox, bluetooth-client.c:get_proxy_for_iface returns only proxy (no device), but disconnect_callback use it as device.
<fishor> so, the problemm is in get_proxy_for_iface or in disconnect_callback
<cyphermox> ok
<fishor> cyphermox,  so, should get_proxy_for_iface return proxy with device? or just proxy?
<cyphermox> no, looks correct to me
<cyphermox> just a second
<Sexy-Girl-Buntu_> serious bug in python3 that makes ubuntu 12.10 upgrade unusable -> http://paste.ubuntu.com/1290050/
<Sexy-Girl-Buntu_> caused by faulty ubuntu-provided python3 packages
<Sexy-Girl-Buntu_> "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xeb in position 114: invalid continuation byte"
<Sexy-Girl-Buntu_> python3 requires encoding to be explicitly specified according to PEP
<ScottK> That's a bug in the driver detection package, not python3.
<ScottK> pitti: ^^^
<Sexy-Girl-Buntu_> ScottK, any ideas for workaround?
<ScottK> No.  I'm not familiar with the code.
<slangasek> while it's a bug in the ubuntu-drivers package, it also looks like the trigger may be some database / cache corruption
<Sexy-Girl-Buntu_> slangasek, is there a way to purge the cache / db?
<slangasek> Sexy-Girl-Buntu_: probably; but I'm also not familiar with this code so I'm trying to work through where the bad data likely is
<slangasek> Sexy-Girl-Buntu_: have you filed a bug report in launchpad about this?  it really should be tracked there
<Sexy-Girl-Buntu_> slangasek, yes but even the bug reporting is broken and crashing with SIGSEGV so i manually reported
<Sexy-Girl-Buntu_> just looking for a temp workaround
<slangasek> bug reporting is broken?
<slangasek> this code wouldn't have any effect on bug reporting
<Sexy-Girl-Buntu_> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1053749
<ubottu> Launchpad bug 1053749 in software-properties (Ubuntu) "software-properties-gtk cannot launch" [Undecided,Confirmed]
<slangasek> ok
<slangasek> Sexy-Girl-Buntu_: so if there's corruption, it's most likely in the apt cache.  Could you please save aside /var/cache/apt/pkgcache.bin, run 'sudo apt-get update', and see if the problem goes away?
<slangasek> and if it does, please attach pkgcache.bin to that bug report
<hallyn> infinity: https://code.launchpad.net/~dannf/ubuntu/precise/open-iscsi/lp1053306/+merge/127359  IIUC that should be marked 'merged' right?  (to take it off sponsor queue)
<hallyn> (i'm not allowed :)
<Sexy-Girl-Buntu_> slangasek, did not work. also, the md5sum after moving and rebuilding is identical
<slangasek> ok
<slangasek> Sexy-Girl-Buntu_: do you happen to have the dctrl-tools package installed on this system?
<Sexy-Girl-Buntu_> slangasek, not installed -- shall i install it?
<slangasek> if so, I'd be interested in the output of this command: grep-available . | iconv -f utf-8 -t ucs-2le > /dev/null; echo $?
<slangasek> sorry, make that: grep-available -r . | iconv -f utf-8 -t ucs-2le > /dev/null; echo $?
<slangasek> if you can, yes please
<Sexy-Girl-Buntu_> slangasek, iconv: illegal input sequence at position 226269
<Sexy-Girl-Buntu_> status output 1
<hallyn> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion 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:
<slangasek> Sexy-Girl-Buntu_: perfect, that's what I was hoping to see - so it means somewhere in your apt sources there's bad input data, since these files are all supposed to be utf8
<slangasek> Sexy-Girl-Buntu_: to narrow it down to a file, please run: for F in /var/lib/apt/lists/*Packages; do iconv -f utf-8 -t ucs-2le > /dev/null || echo $F; done
<slangasek> Sexy-Girl-Buntu_: that will tell us which package source has the bad data, you can then comment it out of your apt config, run 'apt-get update' again, and bypass the problem for now
<slangasek> Sexy-Girl-Buntu_: er, except I got the command wrong again
<slangasek> for F in /var/lib/apt/lists/*Packages; do iconv -f utf-8 -t ucs-2le $F > /dev/null || echo $F; done
<Girl-Buntu> ok
<Girl-Buntu> slangasek, no output
<slangasek> hmm, really
<slangasek> interesting
<slangasek> Girl-Buntu: ok, how about: grep-available -r . | head -c 226300 | tail -n 20 ?
<slangasek> perhaps this is due to a locally-installed (i.e., not from apt) package that has bad metadata
<Girl-Buntu> slangasek, yeah that seems to be it
<Girl-Buntu> Maintainer: Mickaï¿½l Guessant <mguessan@free.fr>
<Girl-Buntu> Package: davmail
<slangasek> if you don't mind sharing the details of that package in the bug report, that would be helpful
<slangasek> Girl-Buntu: easiest workaround is probably to edit /var/lib/dpkg/available and remove the offending character
<slangasek> (that way you can leave the package installed)
<bdmurray> slangasek: there are some similar tracebacks with different KeyError numbers - they are duplicates correct?
<Girl-Buntu> slangasek, not the root cuase...still not working
<Girl-Buntu> slangasek, edited to no avail
<slangasek> bdmurray: if the trace signature is otherwise the same, yes
<slangasek> Girl-Buntu: does running 'apt-get update' after the edit make a difference?
<Girl-Buntu> slangasek, no
<Girl-Buntu> slangasek, the iconv error is removed but not the ability to run the app
<slangasek> Girl-Buntu: if you re-run the grep-available -r . | iconv command now, it gives no errors?
<Girl-Buntu> slangasek, correct. no errors. still cant run the app though
<slangasek> ok
<slangasek> Girl-Buntu: how about if you run the same command with grep-status instead of grep-available?
<slangasek> i.e., this may require fixing up /var/lib/dpkg/status in addition to /var/lib/dpkg/available
<Girl-Buntu> iconv: illegal input sequence at position 223829
<Girl-Buntu> ah...
<slangasek> sorry, I wasn't sure exactly what dpkg information apt was pulling into its cache
<Girl-Buntu> FIXED!
<Girl-Buntu> slangasek, u rock -- i will update the bug
<slangasek> Girl-Buntu: perfect, thanks for sticking with it
<cyphermox> fishor: I'm still debugging it, it's not obvious. I think there's some piece of the recursion that is wrong when cleaning up the device, services behind it and all, but it's complicated
<fishor> cyphermox, i see.. i think some extra comments it this source will help in future :)
<cyphermox> meh
<fishor> cyphermox, meh? what is it?
<cyphermox> fishor: I'm not convinced it's a matter of comments
<fishor> cyphermox, ah... i just tried to justify my incompetence ;)
<cyphermox> don't have to, I'm just as lost ;)
<cyphermox> fishor: there's a bug open in launchpad or gnome right?
<fishor> cyphermox, in gnome and only for this crash
<cyphermox> Bastien can take a look, he's going to have a much easier time figuring it out. I suspect it's a matter of a change in bluez API
<fishor> cyphermox, will you contact him, or i should open a bug some where?
<fishor> cyphermox, https://bugzilla.gnome.org/show_bug.cgi?id=686172
<ubottu> Gnome bug 686172 in properties "[patch] fix crasher on error == NULL" [Normal,Unconfirmed]
<cyphermox> yeah, that's fine
<cyphermox> that one looks good but it brings very little, since the device then doesn't get disconnected either
<fishor> cyphermox, yep. it was initial fix of symptom, not real fix.
<fishor> cyphermox, can you please assign Bastien to this bug, i do not have his email
 * fishor go to sleep
<cyphermox> it should be done already
<cyphermox> or anyway, he has received the bug mail
<sarnold> pwd
<xrdodrx> How do I clear the notifyOSD queue?
<xrdodrx> I have 4000 notifications in queue due to an application bug.
<stgraber> xrdodrx: not really the right place to ask, but I guess killing notify-osd and restart it manually should do the trick
<xrdodrx> failed to run command `notify-osd': No such file or directory
<xrdodrx> :\
<trism> xrdodrx: don't have to restart it, it will be restarted when a notification is sent
<stgraber> xrdodrx: /usr/lib/notify-osd/notify-osd though indeed it's dbus activated so should get auto respawned on the next notification
<xrdodrx> oh, good. thanks :)
<xrdodrx> yes, it was my application that filled up the queue
<xrdodrx> ;)
 * xnox realised why I can't pronounce raring correctly, because to me it's the act of archiving with RAR, RARing
<ScottK> You've finally noticed this name is part of Canonical's secret plan to promote non-free software.
<xnox> ScottK: it's Russian, so it's ok.
<infinity> hallyn: Only the tech board can mark that merged (or, rather the members of ~ubuntu-branches)
<infinity> hallyn: Though, I'm not entirely sure what the point is of merging into a branch no on can write to. :P
<slangasek> xnox: it's ok anyway, just as long as you know how to pronounce YOU bun toe
<infinity> stgraber: Want to mark https://code.launchpad.net/~dannf/ubuntu/precise/open-iscsi/lp1053306/+merge/127359 merged? :P
<xnox> slangasek:  Ð£Ð±ÑÐ½ÑÑ ? =) correct ?!
<stgraber> infinity: done
 * xnox is confused which pyflakes is the real pyflakes
<ScottK> Will the real pyflakes please stand up.
<slangasek> ScottK: you're the real flaky?
<ScottK> Probably, but nothing to do with the current conversation.
<marrusl> infinity, http://pad.lv/1068889 ... i'd assign it but i can't.  :)
<ubottu> Launchpad bug 1068889 in eglibc (Ubuntu) "nscd should not cache netgroups by default" [Undecided,New]
<infinity> marrusl: Fixed.
<marrusl> dig.
<slangasek> marrusl: so in Soviet Russia, Different Strokes watch you?
<marrusl> slangasek, +1
<marrusl> reminds me... it's probably time to change that one.  :)
<slangasek> heh
#ubuntu-devel 2012-10-20
<ion> Oookay. âCould not back up the following files. Please make sure you are able to open them.â ---x------ 1 ion ion 0 loka  19 12:19 .cache/unitydashlegalseen
<ion> Interestingly, .cache is in the ignored âfoldersâ list.
<OdyX> tkamppeter: did you see http://bugs.debian.org/690982 ? I plan to take a look but my week-end is packed, so if you had a chance I'd be grateful!
<ubottu> Debian bug 690982 in cups "Printouts are incomplete" [Grave,Open]
<perriman> config.add_apps_prefix("cloudsn.desktop")
<perriman> sorry
<perriman> How must I migrate an application to use the new message indicator?
<perriman> I'm using Indicate with gir
<vibhav> Any idea when will the archieve for Raving will open?
<vibhav> archive*
<infinity> vibhav: It'll open for general upload "soonish", when we're done with both toolchain and some infrastructure mangling.
 * vibhav waits impatiently
<vibhav> I get excited when I imagine myself writing "raring" in the changelogs :P
<infinity> That's a curious fetish.
<vibhav> heh
<alexbligh1> I'm trying to (re)build Precise's openvswitch package on Lucid (yes, I know). Building works fine with a few tweaks until I get to a missing dh_python2. dh_python2 is provided by Precise's python package. Precise's python package has dh_clean erroring on a '7 being the highest version supported by this debhelper' even though debian/compat is 5. Is there an easier way to do this?
<infinity> alexbligh1: debian/compat should probably be 7, not 5.
<alexbligh1> infinity, but surely debian/compat LOWER than 7 should be fine? (after all I just pulled the source package from precise)
<alexbligh1> s/dh_python2/dh_pysupport/ seems to mostly work (fails to include some python bindings I appear not to need), but is not a complete replacement.
<infinity> alexbligh1: The one I just grabbed from precise has a debian/compat of 7...
<infinity> alexbligh1: But I don't recall the state of dh_python2 in lucid.  I vaguely recall it's incomplete.
<alexbligh1> amb@DBS:~/openvswitch/python/python-defaults-2.7.3$ cat debian/compat
<alexbligh1> 5
<alexbligh1> It's python-defaults that whinging about compat levels.
<infinity> Oh.  That was you rebuilding python-defaults, not openvswitch.
<alexbligh1> yeah I was rebuilding python-defaults, to get dh_python2, to build openvswitch.
<alexbligh1> But my python knowledge can be written on the feet of a snake.
<alexbligh1> dh_python2 is non-existent in lucid. There is a bug saying it is meant to be backported
<alexbligh1> https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524
<infinity> I'm unconvinced that just backporting python-defaults would be remotely sane.
<ubottu> Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [High,Confirmed]
<alexbligh1> infinity, yeah, that's why I wondered if there was surgery I could do to debian/rules in openvswitch.
<infinity> alexbligh1: Sec.
<infinity> alexbligh1: http://lucifer.0c3.net/~adconrad/openvswitch.patch2
<infinity> alexbligh1: ^-- That should be all of the pysupport->dh_python2 diff, I believe.  So, just apply that backwards. ;)
<alexbligh1> infinity, fantastic, thanks
<infinity> alexbligh1: (Was a debdiff between 1.2.0-1 and 1.2.1-2 with all upstream changes removed, and random other bits to debian/ that didn't seem to relate)
<alexbligh1> infinity, thanks - I think the python bit has worked. It's now complaining about an xml file being in 2 packages, which I suspect even I can sort
<alexbligh1> infinity, I can ping between 2 lucid boxes over an openvswitch gre tunnel so it all 'must work' (tm). Needed to adjust the .install files a bit. Patch here. https://github.com/abligh/openvswitch-lucid/commit/621cedca505bb8af473a1625620bc0bf9c64626b
<infinity> alexbligh1: And now to upgrade to precise and stop caring? :)
<alexbligh1> infinity, yeah that would be nice. Our new release runs on Precise throughout but is built on lucid partly because our build system is tied to lucid, and partly because half our dev is still on lucid so we can still support lucid easily. Once this release is out we no longer need to do that, so there will be a grand upgrading, and just have some legacy lucid build boxen /vms.
<infinity> alexbligh1: Well, we support all the way back to hardy on our (Ubuntu's) build machines, but they're all precise with hardy/lucid/etc chroots.
<alexbligh1> infact the very reason for me playing with this was to get two Precise VMs that are distant on the same LAN :-)
<alexbligh1> infinity, indeed. All doable, it's mainly the developers' own machines which are the pain right now. I think you guys have some fancy tool that generates a chroot of a different distro (schroot or something?)
<infinity> alexbligh1: The only caveat is that we use linux32/linux64 --uname-2.6 to work around the fact that some build scripts have a hissy fit about kernels that are 3.x.x
<infinity> alexbligh1: mk-sbuild, which is just a fancy wrapper around debootstrap, makes schroot/sbuild chroots, which is what our devs tend to use (or they use full VMs), yeah.
<alexbligh1> infinity, yeah we have a backlog of housekeeping stuff awaiting the end of month release (including a long awaited switch from svn to git - finally!)
<infinity> alexbligh1: \o/
<infinity> Thanks for accidentally reminding me that I need to get around to moving the debian-glibc revision control from svn to git...
<infinity> Maybe this is a good week to do that.
<alexbligh1> infinity, I think our svn repo is now larger than any one hard disk (eek), due to some design naivity early on. So we have had fun running a constant incremental conversion to git.
<jamin> got a permissions regression with polkit between 12.04 and 12.10 (presumably due to move to udisk2): https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1069234
<ubottu> Launchpad bug 1069234 in gnome-disk-utility (Ubuntu) "regression: local admin not authorized for many tasks" [Undecided,New]
#ubuntu-devel 2012-10-21
<hyperair> hmm this is weird. i can't seem to upgrade from precise to quantal due to unmet dependencies
<hyperair> oh crap, i forgot i pinned quantal to prio 1
<apw> ;b 9
<tkamppeter> OdyX, Debian bug 690982 is easy to fix, you only nedd to upload the current GIT og the CUPS package to Debian, the fix is already contained there and tested under Ubuntu.
<ubottu> Debian bug 690982 in cups "Printouts are incomplete" [Grave,Open] http://bugs.debian.org/690982
<OdyX> tkamppeter: aww well. I can't upload 1.6 to Wheezy. You mean the patched backend/usb-libusb.c ?
<geser> is there something wrong with publishing currently? the latest python3-defaults from raring is missing on archive.u.c but LP says it's published
<mitya57> geser: http://archive.ubuntu.com/ubuntu/pool/main/p/python3-defaults/python3-defaults_3.2.3-5ubuntu2.dsc
<mitya57> it's not missing
<geser> hmm, apt-get complained about a 404 for fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python3-defaults/python3_3.2.3-5ubuntu2_all.deb
<geser> but I checked it a couple minutes ago and didn't see it (now it's there)
<geser> I wonder what happened in the last 5 minutes
<geser> looks like one of the archive.u.c mirrors isn't up-to-date
<geser> because I forced reload that listing in FF again, but this time I don't see -5ubuntu2 anymore
<geser> http://archive.ubuntu.com/ubuntu/dists/ doesn't list raring for me either
<geser> looks like only 91.189.92.176 it affected (out of sync)
<xnox> geser: aren't we meant to be "pre-release frozen" and publisher not pushing stuff out for raring yet? /me is not sure at all.
<geser> xnox: in that case the published Packages files shouldn't mention it either, but it looks like 1 of 6 archive.u.c mirrors was out of sync (didn't have raring at all)
<xnox> sigh
<geser> at it probably also affect quantal-updates if you got the package list from a different mirror than it tries to fetch the debs later
<geser> (3 days out of sync)
<psusi> what is up with the livecd no longer fitting on a cd?  I thought the plan was to turn the dvd image into a ~1 gb image meant for usb sticks, not enlarge the desktop image?
<infinity> psusi: We decided to give up on shiny spinning things at the last UDS.
<infinity> psusi: At least, for Ubuntu images.  Many flavours have tried to stay CD-sized.
<infinity> psusi: For serial installers (ie: people who seem to install more often than they actually use their computer), writing images to USB sticks is way more convenient anyway, and for one-off folks who need shiny spinning things, if you have a newish computer with a CD burner, it's probably also a DVD burner, so that works out.
<infinity> psusi: (And for people doing bulk installs and other such things, it shouldn't affect them at all, cause they probably all use netboot, or should do)
<cjwatson> xnox: in general, if the publisher weren't running for a given series, it would be impossible to prepare it for general opening in any meaningful way ...
<xnox> cjwatson: ack. Maybe I should read up about https://dev.launchpad.net/Soyuz
#ubuntu-devel 2013-10-14
<xnox> Laney: did i break transition tracker or has it not updated yet?
<xnox> (see my recent commits on +junk)
<pitti> Good morning
<tvoss_> doko, ping
<tvoss_> cjwatson, you might know, too: which package contains the STL pretty printers for gdb?
<tvoss_> doko, we are looking into getting pretty printers for the STL working and would need some help :)
<pitti> RAOF: hey Chris, how are you?
<pitti> RAOF: are you still doing SRU? it would be great if some SRU member could accept the postgresql uploads for all releases (it has an MRE, no packaginag changes, all auto-tested, so shoudl be easy)
<pitti> people keep asking me for them..
<RAOF> pitti: Sure.
<dholbach> good morning
<RAOF> pitti: 9.1 or 8.4?
<RAOF> pitti: Or, I guess, both?
<pitti> RAOF: both for precise, 9.1 for quantal/raring, 8.4 for lucid
 * RAOF will deal with that after dinner, it seems.
<rbasak> infinity: what do you think about an SRU for http://launchpadlibrarian.net/144462697/dpkg_1.16.10ubuntu2_1.16.10ubuntu3.diff.gz? We're backporting juju-core for the cloud archive, to build against a barely modified Precise, and so I we need to carry that dpkg patch - either in the cloud archive or as an SRU in precise-updates.
<rbasak> I assumed we'd need to carry it but just noticed 1.16.1.2ubuntu7.1 and wondered.
<rbasak> (we'll probably need to carry it in the short term anyway, so we can have a working juju-core on Thursday)
<pitti> RAOF: thanks (btw, no need to actually review the upstream diff that much)
<pitti> slangasek, xnox: I tested automatic and manual partitioning with EFI in qemu, and manual partitioning on my workstation, and it has always worked, so it seems this bug either got fixed, or I can't reproduce it any more
<soren> cjwatson: I'd never heard of RUNPATH before... Reading the docs about it, I'm a bit confused then RPATH would be preferable over over RUNPATH  (particularly since man ld-linux.so(8) explicitly says RPATH is deprecated).
<Laney> xnox: looking
<xnox> Laney: thanks.
<Laney> woah
<Laney> didn't expect you to be up
 * xnox why not?
<Laney> 14/10 01:50:54 <xnox>
<xnox> oh that... =) well..... release week jibbies.
<infinity> mlankhorst: xdiagnose could do without all the .git noise in the package.  Can you build it with '-i -I'?
<mlankhorst> yeah just delete it, I'll ask for tjaalton to responsor, didn't notice it. :P
<infinity> rbasak: I'd be happy to SRU that back ASAP.
<infinity> rbasak: It's easy enough to validate and push through without a 10-day wait, IMO.
<rbasak> infinity: thanks. I'll get on to it now then. What do you think about regressions for rebuilds of other armhf packages? I can't think of anything specific, but it does seem to have a rather large window.
<infinity> rbasak: Hrm?  It shouldn't cause any regressions.
<infinity> rbasak: I need to SRU to add ppc64el too, let me prep it.
<rbasak> infinity: yeah I can't think of anything either. Just that it has the potential to impact many things.
<rbasak> infinity: OK, I'll leave the patch/upload to you then? I'll do the bug paperwork.
<infinity> rbasak: It shouldn't impact anything.  If things have the new ABI tags, they'd pass both tests, if they lack the new ABI tag, they'll fall through to the old test, if they lack both, they'll fail as always.
<rbasak> Right.
<infinity> rbasak: And yes, please SRUify the bug for me, that would be great.
<Laney> xnox: It has the revision, waiting to see if it runs normally
<caribou> I need advice from someone familiar with start-stop-daemon in init-scripts;
<caribou> the stud init-script stop portion uses --pidfile (as the start section) which restricts the SIGKILL to the parent PID
<caribou> if I understand it correctly
<caribou> but STUD has children processes so when we do 'invoke-rc.d stud restart', the start comes in while the children still have the socket open and fails
<caribou> bug 1123950
<ubottu> bug 1123950 in stud (Ubuntu Precise) "/etc/init.d/stud restart does not start the daemon" [Medium,In progress] https://launchpad.net/bugs/1123950
<caribou> my question is : would it be a problem to remove the --pidfile from the 'start-stop-daemon --stop' while keeping it in use in the 'start-stop-daemon --start' section ?
<caribou> the --pidfile in the start section is required so STUD can start multiple instances
<xnox> Laney: looks good. Hm I wonder why it didn't update before? how often is it cronned for?
<xnox> Laney: (after the move)
<Laney> I found a missing occurence of arm64
<Laney> (in the runner script)
<rbasak> infinity: the bug is ready
<rbasak> (bug 1187722)
<ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,New] https://launchpad.net/bugs/1187722
<cjwatson> tvoss_: I always assumed those were in the gdb package itself
<cjwatson> soren: I think RUNPATH is generally better, it's just newer
<infinity> rbasak: Cool, I'll upload today, and we co do a quick verification turnaround.
<infinity> rbasak: Verifying my ppc64el change takes about half a second, so that won't hurt your chances. :)
<rbasak> Thank you!
<rbasak> jamespage: ^^ infinity will SRU the dpkg fix to Precise
<xnox> Laney: ah, ok. and why is boost1.53 still there? i thought that should be auto-garbage collected (or is it removed only after X days of not being updated or some such?) /me's memory is fuzzy
<Laney> xnox: 3 days
<infinity> caribou: The point of pidfile is to limit the stopping to only the thing you started.  If children take a while to eff off, you might want to find a way around that...
<caribou> infinity: yeah, I understood that, but in the case of stud, it loops through the whole set of parents to stop them anyway so I thought that stopping all procs at once would be acceptable
<infinity> caribou: It loops through all the parents *it started*, I assume.  Not all the occurrenced of that process name on the host.  Subtle, but important, difference.
<caribou> infinity: the alternative is to have stud manage the ramping of of his children when the parents is told to exit, which is what the Debian maintainer suggest
<infinity> caribou: Having the parent not exit until all the children do is probably the right answer.
<caribou> infinity: indeed; ok that answers my query; thanks
<caribou> infinity: in the case of stud; it does stop --pidfile on all the stud configurations present in /etc/stud so that would be all of them anyway but it is indeed a better solution
<infinity> caribou: That's not all of them on the system, that's all of them on that root.
<infinity> caribou: Think chroots.
<caribou> infinity: yup, true I have too much of a server centric view
<caribou> infinity: and this is *exactly* the clarification I was after!
<infinity> caribou: I have a server-centric view too, clearly just different types of servers. ;)
<caribou> infinity: btw, we have a current workaround to add a "sleep 1" in the start sequence that seems to work; does that sound like a valid option for SRU up until we get the final fix from Debian ?
<caribou> I have a debian bug opened on this one btw
<infinity> caribou: A sleep is an icky but valid workaround, a second seems optimistic, if it could potentially be under load or running on a slow machine.
<caribou> bug 1123950
<ubottu> bug 1123950 in stud (Ubuntu Precise) "/etc/init.d/stud restart does not start the daemon" [Medium,In progress] https://launchpad.net/bugs/1123950
<caribou> infinity: ok, I'll look into it
<infinity> rbasak: What was the bug number for that?  I didn't seem to mention it in my previous changelog entry (naughty me).
<rbasak> infinity: bug 1187722
<ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,New] https://launchpad.net/bugs/1187722
<infinity> rbasak: http://paste.ubuntu.com/6235232/ <-- Sanity check.
 * rbasak looks
<rbasak> infinity: lgtm
<infinity> rbasak: Alright, I'll do a quick test build and local test and then upload and see if I can find a fellow SRU member to review and let it in for me.
<rbasak> infinity: FWIW, before I spoke to you earlier I verified that the patch applied against dpkg precise successfully builds saucy golang on precise. Just another (non-SRU-team, non-dpkg-uploader) data point.
<infinity> rbasak: Shiny, it's uploaded.
<infinity> cjwatson: Can I get you to do a quick SRU review of dpkg in precise-proposed?  We need to fasttrack this for server team stuff.
<cjwatson> infinity: done
<infinity> cjwatson: Danke.
<infinity> rbasak: Once that builds, want to re-verify your bug with the archive binaries?  I'll verify my bug.
<infinity> rbasak: Oh, look, it's already built and published, even.
<rbasak> infinity: ack. Working on it.
<wgrant> didrocks: Around? unity needs a trivial arm64-specific patch to build there (just extending the existing -fPIC that's conditional on amd64 and armhf to arm64). But it would need to be uploaded quickly.
<wgrant> didrocks: Is it reasonably practical to get something like that in ASAP, or does the autolander make it awkward?
<didrocks> wgrant: we can always fast-pass the merge in trunk
<didrocks> wgrant: let me look at what's in trunk that was not released
<wgrant> I'll pretend I know what that means.
<infinity> Ideally very fast, I intend to lock down the archive for seeded uploads after I've had lunch.
<infinity> But I'd like to see this fix in for kicks, if we can make it.
<didrocks> wgrant: first, do you have a MP somewhere?
<wgrant> No, I'm still downloading the branch
<wgrant> if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
<wgrant> is the line, needs to also match "aarch64"
<didrocks> infinity: there are 2 commits in unity trunk that are not released yet, if I test that quickly, does the release team +1 for them?
<infinity> didrocks: Toss me a quick diff somewhere?
<infinity> didrocks: But if they're both bugfixes and obviously sane, I'm fine with that.
<didrocks> infinity: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3567 and http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3568
<didrocks> they seem sane to me, I want to give them a 10 minutes poke first though
<lool> didrocks, infinity: http://paste.ubuntu.com/6235437/
<lool> debdiff
<infinity> didrocks: Both those look fine to me.
<didrocks> infinity: I'm currently testing, as soon as wgrant has the MP ready, I'll push that and run a build
<infinity> didrocks: If those test fine, and you grab wgrant's change, we'll call that the final non-SRU upload for the release. :P
<didrocks> infinity: \o/
<cjwatson> infinity: (ubiquity, possibly)
<wgrant> No changelog change required?
<didrocks> oh no, wanted to be the latest!
<didrocks> wgrant: no, just give a sane commit message :)
<infinity> cjwatson: I meant the final non-sru unity upload.
<infinity> cjwatson: I'm confident that we'll have installer uploads.
<infinity> cjwatson: I have to do one or two myself still. :/
<infinity> Okay, lunch.  Back in a bit.
<cjwatson> ah right
<wgrant> didrocks: https://code.launchpad.net/~wgrant/unity/arm64-pic/+merge/190919
<didrocks> wgrant: pushing your change to trunk and then kicking a rebuild
<didrocks> thanks :)
<wgrant> Thank you :)
<lool> didrocks: are you running the ci stuff?
<lool> didrocks: can kick it if you like
<didrocks> lool: already on the page
<didrocks> (started)
<lool> already merged I guess
<didrocks> yep
<lool> and cu2d building ok
<doko> tvoss_, hi
<tvoss_> doko, hey
<doko> tvoss_, should be in the libstdc++6-4.8-dbg package
<tvoss_> doko, those are all python2, and gdb is linked against python 3
<doko> tvoss_, wait, I had a patch for that ...
<tvoss_> doko, would be quite helpful :) plus: can we wire that up to our retracing infrastructure, too? Would love to have more readable stack traces
<steveire> Is it known that clang++ doesn't work with the stl in 13.10?
<steveire> http://pastebin.kde.org/pzd9fvzs2
<tvoss> doko, did you have any luck digging up your patches?
<sabdfl_> hi folks, quick q re whoopsie in syslog
<sabdfl_> seems like I have a steady stream of debugging info there - whoopsie online / offline
<sabdfl_> is that expected, or a bug? can we dial back on the chatter?
<ev> sabdfl: yes, filed as https://bugs.launchpad.net/whoopsie/+bug/1239690
<ubottu> Ubuntu bug 1239690 in Whoopsie "syslog doesn't need to know about offline / online" [Medium,Confirmed]
<doko> tvoss, won't be for saucy
<tvoss> doko, can you point me to the patch?
<doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches/libstdc%2B%2B-python3.diff?view=log
<sabdfl> ack, thanks ev
<rbasak> infinity: verification-done on bug 1187722. Thanks!
<ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,Fix committed] https://launchpad.net/bugs/1187722
<tedg> xnox, Hmm, did you push to this branch?  https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190847
<xnox> tedg: yes.
<xnox> tedg: on behalf of doko (he didn't want to deal with branches/upstream merger / daily landing etc)
<tedg> xnox, Hmm, seems LP doesn't think there's any diff...
<xnox> tedg: i believe that's in the archive already thus, needs merge into upstream branches to unbreak integration.
<xnox> tedg: LP sent me an OOPS via email failing to generate diff.
<cjwatson> LP is on "updating diff" implying it oopsed
<cjwatson> xnox: delete the branch and repush
<cjwatson> (and probably re-MP)
<xnox> cjwatson: ok.
<cjwatson> that's usually the simplest way
<xnox> hm, branch is updating as well.
<cjwatson> might want to keep the MP window open in a tab :)
<cjwatson> s/window //
<cjwatson> xnox: same thing
<xnox> ack.
<cjwatson> rare on small branches, sadly pervasive on large ones like ... er, LP itself
<cjwatson> so I've got used to it
<xnox> ok. first time happening to me =)
<xnox> tedg: https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190967
<xnox> tedg: better?
<tedg> xnox, No hugs and kisses in the MR? ;-)
<tedg> xnox, Thanks!  Approved.
<xnox> =)
 * xnox blows a kiss to PS jenkins integrator
<psusi> anyone know how to translate a UTF-16 string into whatever the native C string format the process is using?
<doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
<xnox> psusi: libicu?
<tvoss> slangasek, ping
<pitti> psusi: wcrtomb() convers a wchar_t string to an UTF-8 char string; that might be what you want?
<pitti> psusi: sorry, that's for an individual character; you probably want wcsrtombs()
<psusi> pitti: I don't have a wchar_t, I have UTF-16
<pitti> psusi: iconv_open("UTF-16", "UTF-8");
<pitti> psusi: or use libicu (haven't tried that, though)
<psusi> there's really nothing in the standard C library to do that?
<psusi> I hate to add another dependency
<cjwatson> libiconv is a bit fiddly but not hopelessly painful
<cjwatson> If you're already using glibc, it's there
<pitti> libiconv is reasonably close to glibc, isn't it?
<psusi> ohh
<cjwatson> It's built into glibc on GNUish systems
<cjwatson> It's not in every libc
<psusi> well here's the other thing... I don't know if I want to convert it to UTF-8... doesn't the locale determine the proper encoding, which may not be UTF-8?
<cjwatson> nl_langinfo (CODESET)
<pitti> yes, that's right; if you want to directly show that on stdout or so (most toolkits actually always expect UTF-8 as input regardless of the locale)
<cjwatson> again somewhat libc-dependent, there are bits in e.g. gnulib to help
<cjwatson> so with gnulib it's locale_charset ()
<psusi> well parted right now is using the w*mb* family of functions and passes around char *
<cjwatson> parted uses gnulib, so it wouldn't be particularly painful to add more modules from there
<cjwatson> in fact you already have locale_charset
<cjwatson> and for that matter all the iconv bits
<doko> xnox, did you get feedback from ev about whoopsie's b-d on valgrind?
<psusi> the problem seems to be that when it reads a UTF-16 string from the gpt, it discards the upper 8 bits and calls it a char *... for non ascii strings, that leaves it with bogus encodings when it tries to convert that to wchar_t from the locale encoding
<cjwatson> if you have a known source encoding you should store it in that encoding if you need to round-trip, and iconv to the locale encoding for display
<psusi> so I need a char * that instead has valid encodings in whatever the correct locale is
<cjwatson> char * is just a sequence of 8-bit characters, it would depend on the function you're using to read into it what gets discarded, not on the type as such
<xnox> doko: he is in front of me, and says he does not care for saucy about that =)
<xnox> doko: since no-one will be using whoopsie for a while on arm64.
<cjwatson> although for the case you're talking about I would be inclined to treat the GPT data as a byte array except when converting for display
<psusi> right.. the function just has a loop assigning each 16 bit source char to an element in the char *, thus discarding the upper 8 bits
<xnox> doko: i'll fix it in saucy? or do you want it for bragging points?
<cjwatson> haha
<cjwatson> yeah, that's not too smart
<psusi> the name is displayed and I think also sometimes substitued into messages that are then translated with gettext
<cjwatson> But surely the code itself gives you the answer
<cjwatson>   char name[37];
<cjwatson>   for (i = 0; i < 72 / sizeof (efi_char16_t); i++)
<cjwatson>     gpt_part_data->name[i] =
<cjwatson>       (efi_char16_t) PED_LE16_TO_CPU ((uint16_t) pte->PartitionName[i]);
<cjwatson> rather suggests (reasonably) that name should be an array of efi_char16_t
<psusi> so with the 8 high bits chooped off, it doesn't survive the trip through gettext to wchar_t and back to utf-8 for printing
<psusi> cjwatson: sure, but then get_name and set_name only pass/excpect a char *
<psusi> so it needs converted
<cjwatson> either that, or, if it's more convenient for iconv, a byte array in whatever endianness is correct
<cjwatson> psusi: right, get_name and set_name are to/from display clearly, and want converters at their borders
<cjwatson> psusi: but I'd suggest that you should otherwise store in a fairly raw format, since otherwise you may introduce round-trip errors
<doko> xnox, just did see avtivity-log-manager dep-waiting, but that's an ev package too. but well, with his new hat on ... ;)
<psusi> aye
<cjwatson> the user's encoding may not be able to represent all the characters in the label, for instance
<psusi> right
<cjwatson> iconv () takes pointers to char * buffers
<cjwatson> which is fair enough, so that would suggest you just want to fix the loop there to be less rubbish
<cjwatson> I can sort of see what it's trying to do in _partition_generate_part_entry
<psusi> yea... fix the terrible loop, and convert in the get/set methods
<cjwatson> You could instead do *((efi_char16_t) &gpt_part_data->name[i]) = ...
<cjwatson> or something like that.  But I'm not sure that's the clearest option
<cjwatson> actually i * 2 and bump the size of the array
<cjwatson> you get the idea :)
<doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
<cjwatson> psusi: bug 1220165 is indeed weird, but reproducible every time here.  I wish we were using udev cookies in the right way
<ubottu> bug 1220165 in parted (Ubuntu) "Error informing the kernel about modificatons" [Critical,Triaged] https://launchpad.net/bugs/1220165
<psusi> cjwatson: iirc, cookies are a device-mapper thing arent' they?
<cjwatson> psusi: they're a fairly general concept that device-mapper happens to be one thing that implements
<psusi> cjwatson: so who is adding the partition?  did we enable a partx rule or something?  a change event that makes someone else open the device shouldn't cause that...
<cjwatson> I've seen buggy udev rules in the past that responded to change events that way
<cjwatson> they're a proper nightmare to track down
<psusi> what way?
<cjwatson> by opening the device ...
<psusi> sure, we have plenty of those
<psusi> but they won't cause that error
<cjwatson> oh I think I see what you mean
<cjwatson> hmm
<psusi> this has to be someone else actually ADDING the partition, after it has successfully been removed
<cjwatson> I wish I could find a way to instrument this without it vanishing
<psusi> can you set a kprobe on the blkpg stuff?
<psusi> or trace
<xnox> doko: pushed fix to lp:whoopsie, but infinity doesn't want it in, as it wasn't ev who proposed the fix =))))))
<psusi> and besides partitioning tools, the only other thing I know of that adds partitions is partx
<psusi> so unless someone added a udev rule to run partx -a...
<cjwatson> there is /lib/udev/rules.d/95-partx.rules
<cjwatson> kpartx sorry
<cjwatson> (and a similar thing for dmraid but I doubt it's that)
<psusi> right, those only apply to dm
<cjwatson> the kpartx rules should also only be for dm-*
<cjwatson> but, let me try removing them and seeing what happens
<cjwatson> nope, not kpartx
<psusi> blast... doesn't seem to be a kernel trace event in the partition add path
<psusi> yea, kpartx just creates a new dm device anyhow, doesn't know about BLKPG
<psusi> it's regular partx that does that
<psusi> unless... someone is calling BLKRRPRT?
<cjwatson> I could strace -f udevd; it'll probably make the bug vanish, but I could look for block ioctls
<psusi> I'd say kprobe it at the source in the kernel... get exactly what you want without dragnetting and changing timing
<psusi> just one printk in those two ioctls
<cjwatson> psusi: I can't realistically install a new kernel; which existing trace event would you suggest?
<cjwatson> (I've not used kprobes before - if you have a recipe I'd appreciate it)
<psusi> I don't see an existing trace event... and I've not yet figured out how to use kprobes myself either
<psusi> but supposedly it is fairly simple to add a printk somewhere, build and insert the module, and bam
<psusi> where fairly simple is, as usual, once you climb the initial learning curve ;)
<cjwatson> stracing udev didn't perturb the bug away, actually
<cjwatson> but it also doesn't show any BLKPG* or BLKRRPART
<psusi> it wouldn't be issued by udev directly but by something it executes
<cjwatson> yes I used -f, of course
<psusi> ahh, right
<cjwatson> are you sure that a duplicate add is the only possible cause of EBUSY here?
<psusi> only way I can see... you only get to the add call if the remove succeeds or fails with ENXIO
<cjwatson> also happens if the add attempt overlaps an existing partition
<psusi> i.e. the device was removed, or already does not exist
<psusi> ohh, right
<psusi> aha!
<cjwatson> or if the partition number already exists, or if kzalloc fails
<psusi> I bet it's overlapping
<cjwatson> let me strace parted_server to see what it's doing
<psusi> yea... didn't think of this when I made the patch to avoid removing and re-adding unmodified partitions
<psusi> there's a higher numbered partition ( thus has not been removed yet ) that overlaps with the partition we are trying to add
<psusi> yea... that loop needs to be split in two passes... first remove partitions that don't match the new table, then loop again adding the new ones after the first loop has already removed all of the modified old ones
<psusi> so yea, it isn't a race at all ;)
<cjwatson> 17:00 <cjwatson> psusi: hm, this is an "erase disk" install
<cjwatson> 17:01 <cjwatson> psusi: but maybe some of the partitions happen to coincide in extent
<cjwatson> psusi: yes, looking at the trace, there's an add with no matching remove
<psusi> working up a patch now
<cjwatson> what's the bug?  you're a little ahead of me here
<cjwatson> in fact, it's attempting a resize, not an add
<cjwatson> 4041  16:02:52.716798 ioctl(6, BLKPG, {0x3 /* BLKPG_??? */, flags=0, datalen=152, {start=1048576, length=52613349376, pno=1, devname="/dev/sda1", volname=""}}) = -1 EBUSY (Device or resource busy)
<psusi> I guess you lagged out... I think there's an existing partition on the disk that we are wiping out and it overlaps the new partition we are trying to add
<psusi> but it has a higher partition number than the one we are trying to add
<cjwatson> 3 == BLKPG_RESIZE_PARTITION
<cjwatson> just checking that theory against the logs
<psusi> so it hasn't been removed yet
<cjwatson> yeah, that's right
<cjwatson> prior state:
<cjwatson> 1   1048576-28468895231     28467846656     primary ext4
<cjwatson> 6   28469886976-52615446527 24145559552     logical ext4
<cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
<cjwatson> desired state:
<cjwatson> 1   1048576-52614397951     52613349376     primary ext4    /dev/sda1
<cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
<slangasek> tvoss: asynchronous pong
<tvoss> slangasek, pong
<tvoss> ah, sorry :)
<tvoss> slangasek, wanted to check on the mem leak? was that fixed?
<slangasek> tvoss: it is not fixed, we haven't root caused it yet; jodh has been working on it
<slangasek> tvoss: please pick his brain about the progress :)
<tvoss> slangasek, yup :)
<tvoss> jodh, ^
<cjwatson> psusi: more than happy to test things here BTW
<cjwatson> since I have a nice 100% reproducer handy
<psusi> cjwatson: about to email you the git patch
<cjwatson> psusi: awesome
<jodh> tvoss: still investigating I'm afraid: putting together a simple dbus server + client (without upstart and (with+without) nih) to try to simulate the problem.
<jodh> tvoss: trigger it even.
<tvoss> jodh, is there any way we can get valgrind results?
<jodh> tvoss: there are valgrind logs on the bug if you're interested. However, neither I nor slangasek have been able to get it to show the leak.
<psusi> cjwatson: patch sent... I haven't tested it though
<tvoss> jodh, do you have a theory in which subcomponent the leak might occure?
<jodh> tvoss: all our findings are on the bug. We believe the problem is in libdbus "somewhere". That's about as much detail as we've got so far.
<psusi> off to lunch
<cjwatson> psusi: OK, I'll look it over, thanks!
<tvoss> jodh, looking, thx
<jodh> tvoss: progress! see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/59
<ubottu> Ubuntu bug 1235649 in unity (Ubuntu Saucy) "uevent spam causes libdbus client code in session upstart to consume massive amounts of memory on Ubuntu Touch" [Undecided,New]
<tvoss> jodh, \o/
<tvoss> jodh, might be an artifact of pool allocation, though
<tvoss> jodh, a though: does nih replace libdbus memory allocation routines? I would think that it tries to force libdbus to allocate from a preallocated memory slice to avoid malloc at all cost
<jodh> tvoss: no - nih does have its own alloc rouintes. But it just makes libdbus calls and is careful to document which nih routines return memory managed by dbus rather than nih.
<tvoss> jodh, got a link to source?
<jodh> tvoss: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libnih/saucy/files/head:/nih/
<infinity> sarnold: Any hope for bug #1220434?
<ubottu> bug 1220434 in curtin (Ubuntu) "[MIR] curtin" [Undecided,New] https://launchpad.net/bugs/1220434
<DiegoTc> hi bkerensa
<DiegoTc> hi lfaraone
<apachelogger> pitti: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/446 it appears you'll also need to add kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer
<apachelogger> or source package kubuntu-debug-installer kubuntu-firefox-installer kubuntu-web-shortcuts kubuntu-notification-helper
<apachelogger> oh, template list is actualy  kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer notificationhelper kcm-notificationhelper
<DiegoTc>  /join #ubuntu-locoteams
<Riddell> apachelogger: I am not sure thy will need to be added to the language packsbeacuse they are in universe
<tedg> ev, What's the LP project for the geoip data?
<thad_> pitti: logind gets stuck in PrepareForSleep mode after suspend/hibernate, it happens occasionally, but I already saw it on two complete different machines. should I file a new lp report or continue commenting on this one bug 1234469 ?
<ubottu> bug 1234469 in network-manager (Ubuntu) "Network does not come up after resuming from suspend." [Medium,Confirmed] https://launchpad.net/bugs/1234469
<pitti> thad_: I think that bug is the very issue, so continuing investigation there is fine
<thad_> pitti: alright, guess I'll test kernel 3.10 and 3.12 to get some more information, not quite sure how to debug this systemd/logind "madness" :)
<pitti> thad_: thanks; you can run logind in the foreground to see what it's doing, perhaps there's an error message somewhere
<thad_> ok, hopefully I can gather some useful debugging information
<psusi> so what if characters can't be reprepsented in your current code page?  it looks like iconv fails the conversion by default, or has an option to ignore... shouldn't you substitute a generic block like character like you get when you don't have the correct font installed?
<cjwatson> psusi: sounds like you want //TRANSLIT
<cjwatson> psusi: changing the default behaviour would break things that use iconv to tell whether something is valid text in a given encoding
<psusi> cjwatson: the man page says it tries to use multiple similar characters, but isn't clear on what happens if it just plain won't work... like if you are using straight asci or latin1
<cjwatson> You tend to get "?" for ASCII//TRANSLIT
<psusi> ok... sounds good then, maybe I'll use that
<psusi> cjwatson: that patch work out earlier?
<cjwatson> Just testing it now following your clarification
<cjwatson> That still fails, but a bit differently
<cjwatson> Now fails to add (or resize?) /dev/sda5
<psusi> what's sda5?
<cjwatson> Which is odd since that should've been in the exact same position as before
<cjwatson> Yeah, same before and after
<cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
<cjwatson> Oh, you have no handling in the add loop for same start/length before and after
<psusi> doh!
<cjwatson> so lift the start/length handling up out of the ifdef I guess
<cjwatson> want me to just do the obvious fix?
<psusi> sure
<psusi> it's just slightly tricky because of the #ifdef for the resize
<psusi> you want to handle unchanged partitions with or without the resize
<psusi> bbl, heading home
<cjwatson> psusi: This is looking better now - http://paste.ubuntu.com/6237966/
<cjwatson> (My changes are around lines 81-105)
<cjwatson> Seems to work, trying a resize
<psusi> cjwatson, looks good
<cjwatson> There's no single non-confusing view of this change, unfortunately, apart from looking at the patched source file
<cjwatson> The patch is enough of a refactoring that it's difficult to read on its own, and a patch of the patch is even worse ...
<cjwatson> psusi: Thanks very much for the help - I'll get this into Debian as well once I'm not in such a hurry
<cjwatson> And have slept
<psusi> hehe, yep
#ubuntu-devel 2013-10-15
<pitti> Good morning
<pitti> RAOF: thanks for the psql reviews!
<RAOF> pitti: No problem!
<pitti> RAOF: could you review the lucid one, too?
<RAOF> Hm, did I not do that one too?
<pitti> it's still in the queue, and I didn't get a message for it
<RAOF> Ah. That's because sru-review barfed on it last time. Done!
<pitti> RAOF: cheers! barfed how?
<RAOF> pitti: I think it was a timeout. My internet is being a bit wonky.
<pitti> I'll run the test suites with the proposed .debs today
<dholbach> good morning
<xnox> pitti: can I quickly poke you about libudev? i'm looking to add nomatch filters to the  udev_monitor. Similar to how filter_subsystem_list and filter_tag_list, expect that i need to add exclude / nomatch (similar to how nomatch works with enumerate functions).
<xnox> this is for bug #1234743
<ubottu> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<pitti> xnox: you can poke me, but as I said last week I never did anything with netlink filters, so I'm afraid I have zero experience there :/
<pitti> xnox: besides, libudev is the wrong place for that
<pitti> xnox: what we want is to apply that filter in udev daemon, on the "kernel" side
<pitti> they shouldn't even appear on the "udev" netlink side
<pitti> (IMHO)
<xnox> pitti: the way I see it, is that udevd will add a filter, but it's using libudev api throughout. So libudev needs "nofilter" functions that one can set excludes, which are applied to the requested monitor.
<xnox> and udev netlink side is generated by udevd listening to kernel events?
<pitti> xnox: yes, it has a private libudev API for that
 * xnox thought that if I filter kernel netlink in udevd, nothing will appear on the udev netlink.
<xnox> or is that not correct?
<pitti> xnox: yes; udevd listens to the "kernel" originated uevents, applies its rules etc., adds the extra properties, tags, etc from them, and re-sends them as "udev" uevent source
<pitti> and usually clients only listen to the "udev" source
<xnox> i was hoping to record and replay the stream of udev events, with/without my filter to make sure that my filter is correct.
<pitti> that's the difference between udevadm monitor --udev and --kernel
<xnox> ok. so i understood that correct.
<pitti> xnox: so it seems easiest to filter out that one event in udevd
<pitti> without making any public API changes
<pitti> (OMG, please let's not change any API/ABI for such a hilarious hack)
<xnox> =)
<xnox> ok.
<xnox> it's just i don't want udev to wake up at all for those, hence the netlink filter.
<pitti> xnox: exactly
<pitti> xnox: hence applying that filter in udevd on the kernel side
<pitti> instead of on the udev side, where udevd would wake up all the time
<xnox> pitti: ack.
<xnox> pitti: looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/7  i think that's variables as exported by upstart bridge.
<ubottu> Ubuntu bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete]
<xnox> pitti: but in uevent/udev terms are those properties?
<pitti> xnox: yes, they are
<pitti> xnox: attributes are in sysfs, like in /sys/devices/platform/omapfb/<fileX>
<xnox> i think I just want to ignore any VSYNC.
<xnox> change events.
<pitti> xnox: properties are stuff that udev rules can add, and some come from the kernel or udevd itself (DRIVER, ACTION, USEC_INITALIZED, and so on)
<pitti> xnox: hm, I guess you need to add an accessor to udev_monitor->sock to src/libudev/libudev-private.h
<pitti> xnox: perhaps it's easiest indeed to add the hack to src/libudev/libudev-monitor.c indeed, to udev_monitor_new_from_netlink_fd() if name == "kernel"
<xnox> well there is udev_monitor_filter_update() which applies the filters already
<pitti> xnox: there you have the sock and can can attach the extra filter
<xnox> (filter by subsystem or tag)
<xnox> if i access and modify filter directely any calls to filter_update() will wipe mine. (i think, unless i'm careful to use a different magic #)
<pitti> xnox: ah yes, that's fine; udev_monitor_enable_receiving() calls that, and is called by udevd at the beginning
<xnox> so i was thinking, if I am to add api-less hack that would be there.
<pitti> xnox: agreed
<xnox> ack.
<xnox> pitti: can udevmock reply kernel src uevents?
<pitti> xnox: it doesn't actually make that distinction between kernel/udev
<pitti> xnox: but I doubt that you currently can run udevd itself against umockdev, as all of its netlink filter operations just won't work on our fake unix socket
<xnox> i see.
<pitti> xnox: for testing, I propose you take any existing driver on your system, where you can trigger a kernel-level uevent by writing into /sys/.../udevent
<pitti> xnox: and write your code with some other device name/property
<pitti> xnox: s/udevent/uevent, of course
<pitti> xnox: then, if filtering that out works, it should be a mere string replacement in your hack, and just one verification on maguro (or wherever that happens)
<pitti> xnox: e. g.
<pitti> $ echo change | sudo tee /sys/class/misc/uinput/uevent
<pitti> $ udevadm monitor -e --kernel
<pitti> [...]
<pitti> KERNEL[16115.645262] change   /devices/virtual/misc/uinput (misc)
<pitti> ACTION=change
<pitti> [...]
<pitti> (you need to start the monitor before, of course)
<xnox> pitti: right, can i add attributes to it? or shall i write something in c then to emit proper uevent?
<pitti> xnox: no, you can't change the set of attributes of a kobject, that's defined by the driver (only)
<xnox> ah.
<pitti> xnox: the /uevent attribute shows the kernel-defined properties
<pitti> xnox: but I don't know whether you can "inject" them with that method
<pitti> the naive approach with "echo -e 'change\nFOO=bar'" doesn't work
<pitti> xnox: so perhaps test with MINOR= or something
<mpt> mvo! Could you please review <https://code.launchpad.net/~brunonova/software-properties/update-apt-on-exit/+merge/190498>? It's a grand total of two lines change.
<xnox> pitti: is systemd-udev statically linked againt libudev? cause i don't think i want to change the behaviour of libudev1 et.al.
<pitti> xnox: yes, it is; it builds a libudev-private.la durig package build and links udevd, udevadm etc. against that
<pitti> so that the private symbols don't appear in the public lib
<pitti> xnox: actually I think with above approach you will
<pitti> xnox: but that's ok; any other program which uses libudev to listen for kernel events will then also have these filtered out
<xnox> pitti: i'm now thinking to cheat.
<pitti> xnox: you are considering making the change in udevd.c only? then you'll need an accessor for "int sock" in libudev-private.h
<xnox> pitti: i'd like to invert the meaning of lilter tag - from include only this tag, to drop anything tagged. Then add udev rule to tag omapfb device with tag "ignoreme" and then add udevd filter tag "ignoreme"
<xnox> overall that should be quite small and obvious, yet horribly breaking all existing conventions.
<xnox> unless that would break udevadm monitor =/
<xnox> hmm... or I shall copy & paste.
<tvoss> jodh, ping
<jodh> tvoss: hi
<pitti> xnox: re (sorry, was OTP)
<pitti> xnox: "invert meaning of filter tag" sounds quite intrusive?
<xnox> pitti: well, i think i came up with something even better now.
<xnox> pitti: let me hack a bit, and I'll ping you for code review.
<pitti> ack
<tvoss> doko, mind pinging me the link to your fix for the pretty printer python scripts again?
<kubuntu83> Greetings, everyone. Am I understanding correctly that, in Saucy, the appmenu-gtk* packages were superseded by packages which no longer work outside of Unity (particularly KDE)?
<xnox> kubuntu83: define "no longer work" they do work with gtk2 and gtk3 panels (applets), indeed so far there is no appmenu-ng port to qt4/plasma. It does work in qt5/declarative for example.
<xnox> no port to qt5/framework5 yet either, I think.
<kubuntu83> xnox: Gtk2/3 apps are no longer exporting their menus under KDE -- not to KRunner, KWin, or Plasma (all of which are picking up Qt menus just fine).
<xnox> kubuntu83: correct.
 * xnox ponders if we should disable menuproxy for gtk under kde then.
<kubuntu83> xnox: Any idea which packages I would need to downgrade/pin to get the old functionality back, or if that's even possible?
<xnox> kubuntu83: i don't think it will be possible, as it's abi transition, you'd have to downgrade all the gtk apps to get them linked against older indicators, which in turn will bring a large can of worms and you end up running quantal.
<cjwatson> barry: Er, WTF - running the system-image autopkgtests, they chmodded my /tmp to 2700
<xnox> kubuntu83: i think it should be possible to export a varible / change gsettings such that the menubar is back within the app and clickable, but it will not export the menus anywhere either.
<cjwatson> barry: I uploaded http://paste.ubuntu.com/6240379/ to make the autopkgtests pass again; Vcs-Bzr points to lp:~ubuntu-system-image/ubuntu-system-image/client, but that doesn't contain the packaging, so I didn't know if there was anywhere I could commit this
<kubuntu83> xnox: It's already showing up within the app, so I guess it could be worse.
<xnox> kubuntu83: oh, that's ok then.
<xnox> kubuntu83: i don't think you can get better than that.
<xnox> (i guess it checks and finds out there is no dbus service listening to receive the -ng menus, and gives up)
<kubuntu83> :'(
<kubuntu83> Sorry to bitch and moan. I just spent the weekend porting packages to Saucy, only to run into an issue that will probably keep me from using it.
<barry> cjwatson: yikes, that's not good.  yeah, i'll fix that
<kubuntu83> xnox: Sorry to keep bugging you, but do you have any idea who I should be petitioning to get a Qt4/Plasma port of appmenu-ng?
<xnox> kubuntu83: can you write code? if not find a volunteer who wants to write it. it should be fairly straight forward from gtk port.
<xnox> kubuntu83: it simply needs to find somebody with time to volunteer and contribute the qt4 port. no petitioning is required.
<kubuntu83> xnox: Right, I was using "petitioning" figuratively. ;)
<doko> mvo, apt ping
<xnox> kubuntu83: ok =) i see.
<kubuntu83> xnox: By the way, you said I'd end up running Quantal if I tried downgrading the relevant packages, but... Everything (appmenu-wise) was working fine in Raring. Not sure if that's relevant. I assumed appmenu-ng is new to Saucy, right?
<xnox> kubuntu83: oh was it. can't remember if it was quantal or raring where the -ng appmenu was introduced, i might be wrong.
<mvo> doko: apt pong (but in a meeting, so expect some delay in asnwering)
<kubuntu83> xnox: Alright, well... Thanks for filling me in. Peace.
<knocte> how can I know who is in charge of some ubuntu package?
<mdeslaur> knocte: Ubuntu doesn't have maintainers like Debian does. Looking at the changelog may give you an indication of who usually updates it though.
<xnox> pitti: here is my work in progress (sorry for so late, been pinged to do other stuff) http://paste.ubuntu.com/6240591/
<mdeslaur> knocte: any package in particular?
<knocte> mdeslaur: libgstreamer packages
<xnox> pitti: completely untested at the moment, so the idea is that netlink filter will drop packets from devices tagged "ignore". Reusing existing netfilter logic used to _match only_ tag.
<pitti> xnox: heh, fun; ages ago, udev actually had something like that already, but it was removed because nobody used it and it was considered a bad workaround for a kernel bug :)
<pitti> xnox: right
<mdeslaur> knocte: doesn't look like anyone in particular takes care of them. Best bet is to file a bug if you have an issue, or want to submit a debdiff to fix something.
<knocte> I'll file a bug, thanks
<pitti> xnox: so, I don't understand the logic in the first block (how does adding to udev_monitor->filter_tag_list suddenly make it a "no match" tag?)
<xnox> pitti: well it still does have "nomatch" type of filters in the enumerate, just not in the monitors.
<pitti> xnox: ah, filter_tag_list is actually that "filter out these tags" already?
<xnox> pitti: so the difference is for all tags, compare lower/upper part of tags and if matched.....
<xnox> ... previously jump after drop packet
<xnox> now branch: for "match-only tagged" (old / normal) jump after drop packet; for "nomatch" jump _to_ drop packet;
<pitti> (no idea how that code/bpf is working)
<xnox> pitti: BPF_JMP -> jump instructions, BPF_JEQ if equal to BPF_K constant value. If true instruction location, false instruction location.
<pitti> xnox: so, if that works, it looks fine to me; unintrusive (API-wise) and shoudl avoid all wakeups
<xnox> pitti: depending on the value of the tag, i jump one instruction less or not.
<xnox> (or jump past the drop or not)
<pitti> xnox: what does the "nomatch" string value do?
<xnox> i think it will drop everything if no tags matched at the moment. let me think about it.
<pitti> list_entry in the top corresponds to udev_monitor->filter_tag_list?
<xnox> pitti: at the moment it can be any. _add_match_filter results in value NULL, and at the moment i simply use ! NULL to consider that it's nomatch branch.
<pitti> otherwise it would break the default behaviour
<xnox> pitti: so "nomatch" can be any string.
<pitti> ah, ok
<xnox> pitti: i guess instead of if (udev_list_entry_get_value(list_entry) == NULL)  I could do explicit string comparison.
<pitti> the code uses filter_tag_list for positive matches, though
<pitti> so if you change that list to mean "filter out" tags, how does that not break current behaviour?
<xnox> pitti: i'm trying to conditionalise it.
<xnox> pitti: by adjusting the actions when tags are matched. I guess i'm wrong now.
<pitti> xnox: ah, that's just a check if it works at all, not yet meant to be fully working
<xnox> pitti: since untagged by default would be now dropped, if there is only one nomatch tag.........
 * xnox needs to think about it.
<xnox> maybe i need a global flag / option then (not on per tag level) if the filter_tags are to include-only or exclude-only
<pitti> xnox: hm, that sounds a bit dangerous as well
<xnox> pitti: well, the api is private and not public, and we only expose / use it in one place in udevd, such that if behaviour for udevd is correct and the libudev behaviour is un-changed we should be ok.
<barry> jdstrand: ping
<jdstrand> barry: hi!
<barry> jdstrand: hi!  could you sanity check: https://bugs.launchpad.net/ubuntu/+source/system-image/+bug/1235975/comments/5
<ubottu> Ubuntu bug 1235975 in system-image (Ubuntu) "Unsafe file and directory permissions" [High,Fix committed]
<jdstrand> barry: I think that is all reasonable, but might mention this-- now that /var/log/system-image and /var/lib/system-image will be created with the correct permissions, why not move the 'correct bad permissions' code into postinst conditional on an upgrade to the release (or past) the one that fixes the issue?
<jdstrand> barry: furthermore, shouldn't the debian packaging be creating those directories in the first place? that way they can be cleaned up on uninstall
<jdstrand> (perhaps the debian packaging is already doing that-- it wasn't clear from the comment)
<barry> jdstrand: it's not, but i do think it makes sense to have the packaging change any existing directories, and leave the s-i code to *create* files and directories correctly.  that would leave just the logfile itself and the random temp subdir.
<barry> jdstrand: of course, if someone changes the config file to point to different locations, their on their own
<barry> *they're
<jdstrand> barry: yes. I think that is reasonable in this case
<barry> jdstrand: i think i will open a new bug for this and try to squeeze in a 1.9.1.  if you want to review the branches (yes, two of them) let me know
<jdstrand> ok
<cjwatson> barry: could you look at the current system-image autopkgtest failures?  Linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#system-image (the public link probably isn't up to date yet; the private link requires batuan VPN access)
<barry> cjwatson: lool is pinging me on #ubuntu-touch, probably about the same thing ;)
<cjwatson> yep
<barry> jdstrand: LP: #1240105
<ubottu> Launchpad bug 1240105 in Ubuntu system image "An update to LP: #1235975 (permission fixing)" [Critical,In progress] https://launchpad.net/bugs/1240105
<jdstrand> barry: ack
<infinity> sarnold: *pokity poke*
<jtaylor> stgraber: re bug 1236957, python3-pyparsing is provided by pyparsing, a different source package
<ubottu> bug 1236957 in python3-pyparsing (Ubuntu) "please remove from archive" [Undecided,New] https://launchpad.net/bugs/1236957
<stgraber> jtaylor: oh, indeed, so source only removal then, good
<stgraber> well, no, source and one binary
<stgraber> jtaylor: done
<jtaylor> thx
<PeterCassetta> Is this the right place to ask about getting certain universe packages updated?
<sarnold> infinity: sorry, I've not yet started 1220434 for curtin, but if it's any consolation I took my dog for a good long walk in the wonderful weather on yesterday's day off :)
<xnox> PeterCassetta: usually, just ask whatever you want to ask =)))) then people can respond and/or redirect.
<infinity> sarnold: We're cutting it pretty dangerously close to release.
<xnox> PeterCassetta: nobody asks to ask a question on irc ;-)
<PeterCassetta> xnox, okay, cool.
<sarnold> infinity: indeed :(
<PeterCassetta> There's a few applications I use fairly often which are pretty out of date.
<PeterCassetta> OpenTTD in the software center is 1.2.3, but the latest stable version is 1.3.2.
<PeterCassetta> Blender is also two versions behind (soon to be three), at 2.66a.
<PeterCassetta> The latest official stable version is 2.68a.
<cjwatson> Realistically, the best way to get that kind of thing updated is to get the Debian maintainer to update their packages, and then we'll sync/merge them into whatever the current Ubuntu development release is at the time
<cjwatson> And maybe then backport to stable releases
<cjwatson> In saucy, openttd is 1.3.1, blender is still 2.66a
<cjwatson> But we don't update stable releases with new upstream versions, generally - that's what the various -backports repositories are for
<cjwatson> https://wiki.ubuntu.com/UbuntuBackports
<cjwatson> blender is 2.68a in saucy-proposed, but unfortunately it fails to build everywhere
<cjwatson> https://launchpad.net/ubuntu/+source/blender/2.68a-3
<cjwatson> So that needs to be fixed
<cjwatson> Looks like it may perhaps be blocked on the libav 9 transition, which will be happening early in the next release cycle
<cjwatson> Might need extra work to be backportable then, though
<PeterCassetta> cjwatson, are universe packages generally not updated after an Ubuntu release comes out?
<cjwatson> No
<cjwatson> Except sometimes in -backports
<PeterCassetta> cjwatson, just to be clear: If, say, OpenTTD is backported from saucy, would I then be able to install it on ringtail?
<cjwatson> PeterCassetta: I don't recall how it shows up in software-center, but worst case it would be installable on raring with "apt-get -t raring-backports install ..."
<PeterCassetta> cjwatson, okay, one last question: When asking for a backport from, say, saucy, would I report it in the project "saucy-backports"?
<cjwatson> No, report it on the target (e.g. raring-backports)
<PeterCassetta> cjwatson: Okay, cool, thanks for the help. :)
<rbasak> PeterCassetta: full explanation here: https://wiki.ubuntu.com/UbuntuBackports#Requesting_a_Backport
<cjwatson> np
<Bluefoxicy> bah.  I can't figure out how to get dpkg to stop deleting everything and failing.
<Bluefoxicy> dpkg-source: warning: ignoring deletion of file tests/test_gridfs.py
<Bluefoxicy> clint byrum... that's who I need to find.
<alkisg> Hi, this recent bug fix causes a regression, i.e. it no longer respects the default Xorg resolution but gnome-settings-daemon now forces the highest one: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1065979
<ubottu> Ubuntu bug 1065979 in gnome-settings-daemon (Ubuntu) "external/internal monitors mirrored on boot when laptop lid is closed" [Wishlist,Confirmed]
<alkisg> Should I file the regression as a separate bug report, or just comment in the same one?
<Laney> alkisg: bah
<Laney> alkisg: There's already bug #1236752
<ubottu> bug 1236752 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon (3.4.2-0ubuntu0.6.3) breaks nvidia multi-monitor-config" [Undecided,Confirmed] https://launchpad.net/bugs/1236752
<Laney> We should probably revert it and then Ritesh can try again if he wants to
<alkisg> Thank you Laney, yeah, please do so :)
<alkisg> I just commented on the first bug report a minute ago
<Laney> FourDollars: ^ you verified this
<mercury00> hello all. I've built a .deb package with a postinst script that edits a grub config (enables console). However, rather than call update-grub in the postinst, I'd like to 'trigger' grub to update once all packages are updated (the correct way). I believe there's a way to do this but simply cannot find it. any ideas?
<mercury00> for instance my package might get installed when someone also installs a new kernel. rather than update grub twice, I;m sure there's a built-in way to make grub update after all packages are installed, and I'm sure the kernel packages use it but don't know how they do so. Thanks for any help.
<Laney> alkisg: Uploaded
<alkisg> Thank you, I'll give feedback as soon as it builds
<Laney> bdmurray: ScottK: (picking on two of you at random) could you look at accepting gnome-settings-daemon/precise-proposed? It's a regression-update revert.
<smoser> bdmurray, ping
<smoser> do you have a thought on bug 1239893
<ubottu> bug 1239893 in software-properties (Ubuntu) "PPAs added using GUI Software and Updates have an extra space added to repository line" [High,Triaged] https://launchpad.net/bugs/1239893
<mercury00> also, I assume this is the correct channel to ask such questions? Just want to make sure I'm not spamming the wrong place
<bdmurray> smoser: I'm looking at your changes now.  Could you elaborate on your question though?
<infinity> mercury00: That would require update-grub supporting triggers, which I don't believe it currently does.
<mercury00> ah, ok - what's the general way to trigger update-menus and such though?
<infinity> mercury00: Generally, packages handle this by triggering in their own update scripts so you don't have to think terribly hard about it.
<mercury00> I know that when I run updates on several packages, I only see the update menus and all that at the very end of the process, but I don't know how to to that
<infinity> mercury00: For instance, calling update-initramfs or ldconfig from a postinst will make them trigger, rather than run immediately.
<mercury00> infinity: ah, ok so it's captured by dpkg or something then, if I call update-initramfs in postinst it triggers it instead?
<infinity> mercury00: dpkg exports some magic variables when executing a postinst, and then if the called binary understand what that means, it can defer to a trigger instead.
<mercury00> infinity: good to know: is there a list anywhere of what programs are /triggered/ rather than executed in postinst? I'm mostly only curious at this point, but still couldn't find any documentation on that
<infinity> mercury00: /sbin/ldconfig is likely the simplest example of that on your system.
<smoser> bdmurray, just wanted to know if you had a clear idea on what had regressed. i didn't understand how this path would hav regressed.
<infinity> mercury00: There's no definitive list, as this is up to the packages themselves, not up to the distribution as a whole.
<mercury00> infinity: aha, that makes sense
<infinity> mercury00: The idea is that, as the caller, this should all be transparent to you.  You call what you should intruitively call (directly, or via debhepler-inserted things), and if the package does fancy things behind your back, that's its business.
<alkisg> mercury00: $ cat debian/ltsp-client-core.triggers
<alkisg> activate update-initramfs
<bdmurray> smoser: did software-properties used to accept ppa: style lines?
<smoser> yeah.
<alkisg> mercury00: With a .triggers file you specify what trigger you want to activate
<alkisg> You don't call update-initramfs
<smoser> bdmurray, i just tested. and this bug existed in 0.92.26
<mercury00> alksig: I saw some documentation on that, but couldn't find any list of what the triggers actually were,
<alkisg> mercury00: https://wiki.debian.org/DpkgTriggers
<mercury00> alksig: just how to call them
<mercury00> alksig: ah, thanks,
<alkisg> mercury00: there's a list there. also, tab in irc autocompletes the name so that you get it right :)
<mercury00> alksig: aha, that's the one I was looking for, I was sure that ubuntu had patched grub to accept the trigger for multiple kernel updates
<sarnold> (more like, it changes how you get it wrong :)
<mercury00> or multiple whatever updates
<mercury00> thanks, didn't know about autocomplete in irc
<arges> Hi. bug 1065979 seems to be a regression for some users. How can I properly tag it so that patch gets reverted?
<ubottu> bug 1065979 in gnome-settings-daemon (Ubuntu) "external/internal monitors mirrored on boot when laptop lid is closed" [Wishlist,Confirmed] https://launchpad.net/bugs/1065979
<Laney> arges: I uploaded it and pinged bdmurray but he chose not to reply ;-)
<arges> Laney: should it be tagged 'regression' or something so it gets on somebody's radar? or bdmurray can handle it since you already pinged him
<Laney> arges: I think I did the right thing in the bug referenced from the changelog
<Laney> anyway, off now
<arges> Laney: ok thanks
<mercury00> alkisg: one last question then: my package source builds several packages, so i have package1.postinst and package2.postinst --- does this mean I also want package1.triggers?
<bdmurray> Laney, arges: I'll look at it before my EOD
<arges> ok
<smoser> bdmurray, i take my above comment back . i've never used that before.
<mdeslaur> bdmurray: can I attack an apport file to an existing bug?
<mdeslaur> s/attack/attach/
 * mdeslaur searches for appropriate magic incantation
<bdmurray> mdeslaur: what do you mean my apport file? a .crash file or something else?
<mdeslaur> bdmurray: I ran ubuntu-bug on a machine without a browser, and I selected the "save for later" option. It generated an .apport file
<bdmurray> mdeslaur: just ubuntu-bug .apport file will work
<mdeslaur> bdmurray: but that wants to open a new bug, instead of attaching to the bug I already have...
<mdeslaur> bdmurray: https://help.ubuntu.com/community/ReportingBugs says I should be able to use -u, but it doesn't work
<alkisg> mercury00: not all packagesXX will need to trigger the trigger. For example, ltsp-client-core does need to trigger update-initramfs, but ltsp-client doesn't. So there's no ltsp-client.triggers file.
<bdmurray> mdeslaur: ah so no there isn't a way to do that
<mdeslaur> bdmurray: ok, thanks!
<mdeslaur> xnox: I've attached requested info to the ubiquity timezone failure bug
<mercury00> alkisg: right, only one of my packages will need to trigger something, so I'd put the instructions in my package1.triggers file then it seems?
<alkisg> yup
<cappyt> Hi everyone, i have a problem doing a live/installable iso based on my current system. I run 13.04 and i tried using remastersys, but it seems not working anymore... anyone has suggestions?
<mercury00> cappyt: do you have any info about what's not working in particular? error messages? (I have no idea myself, but you'll probably get better help if you have some idea what's wrong)
<cappyt> i can provide a log, if you want
<bdmurray> smoser: I think you need to use strip() as DialogAdd adds a '\n'
<cappyt> This is my remastersys.log https://docs.google.com/file/d/0B1x0krrddxExV0RJbEh1VEpDLXc/edit?usp=drive_web
<cappyt> i can't figure out why is not creating the ISO.
<sarnold> infinity: security team ACK on including curtin in main, details to follow in bug report "soon"
<stgraber> sarnold: yay!
<stgraber> infinity: was about to promote but just noticed that we only have a security team ack and not an ack from a MIR team member so I'll let you deal with that (since you've got all the hats necessary to deal with it)
#ubuntu-devel 2013-10-16
<sarnold> doko,infiniti,jdstrand, curtin's MIR still requires a MIR team member review: 1220434
<Noskcaj> Has anyone looked at bug 823254  recently?
<ubottu> bug 823254 in software-center (Ubuntu) "Port to python3" [Medium,Confirmed] https://launchpad.net/bugs/823254
<FourDollars> Laney: Yes. Please see my comment at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1065979/comments/37.
<ubottu> Ubuntu bug 1065979 in gnome-settings-daemon (Ubuntu) "external/internal monitors mirrored on boot when laptop lid is closed" [Wishlist,Confirmed]
<pitti> Good morning
<asac> o/
<dholbach> good morning
<infinity> smoser: Can you get a team subscription to curtin set up?
<doko> infinity, did you see 1203496 in other packages too?
<infinity> doko: I don't remember if I saw it elsewhere, sorry.
<snowyrooftops> Hi!
<snowyrooftops> I read about plans to include only Python 3 in Ubuntu 14.04
<snowyrooftops> I'd love to help, but don't know where to look
<cjwatson> jamespage: could you add a server team (or whatever) bug subscription to curtin?
<jamespage> cjwatson, done
<cjwatson> ta
<smoser> infinity, done.
<infinity> smoser: Danke.
<mantas-baltix> xnox: Hi Dmitrijs
<mantas-baltix> Latest ubiquity build fails on amd64, see https://launchpad.net/ubuntu/+source/ubiquity/2.15.25
<mantas-baltix> It would be nice if you update ubiquity-debconf translations from Launchpad in next build -  Lithuanian translation is missing in Ubuntu one step because of bug #1235192
<ubottu> bug 1235192 in ubiquity (Ubuntu Saucy) "Strings in U1 window for 13.10 installer are not in pot file" [High,Fix released] https://launchpad.net/bugs/1235192
<mantas-baltix> I'm currently finishing translation of missing strings in Ubiquity-debconf template
<mantas-baltix> cjwatson: few years ago you helped us to update ubiquity-debconf translations from Launchpad, could you help again ? ;)
<cjwatson> mantas-baltix: Too late
<cjwatson> mantas-baltix: That's an arm64 build failure, not amd64.  ubiquity/arm64 is not yet expected to work.
<cjwatson> mantas-baltix: And I updated translations four days after the non-language-pack translation deadline, I don't think that's unreasonable ...
<xnox> cjwatson: well the strings to be translated weren't there 4 days ago.
<cjwatson> Although I know that those strings were only added four days after *that*, but I believe that was on the understanding that they weren't expected to be translated for release
<xnox> ah, ok.
<ScottK> xnox: Did you figure out what the boost version for "T" is?
<mantas-baltix> cjwatson: ok, sorry, our translation team isn't very fast...
<cjwatson> mantas-baltix: I think this was just not expected to be translated; we accepted the bug-fix because having it untranslated and in the .pot is no worse than having it untranslated and not in the .pot, and gives translators more of a head-start for next release
<cjwatson> mantas-baltix: If there's another build, I'll update, but I don't know of a cause for one at this point
<xnox> ScottK: 1.54 with multiarch.
<ScottK> xnox: OK.  That's probably worth a mail to u-devel or u-d-a.
<xnox> ScottK: also thinking libav9,  emacs24 as default.
<xnox> ScottK: yeah I know, but I'm not yet preparing / evaluating for T opening yet.
<cjwatson> perl 5.18 too
<ogra_> do we have a name yet btw ?
<cjwatson> rickspencer3: ^-
<ogra_> no-name-yeT Tiger
<ogra_> :)
<mantas-baltix> cjwatson, xnox: OK, thanks, Lithuanian users will be happy if you update ubiquity-debconf translations from Launchpad in next build - we will create localized Ubuntu 13.10 installation image next week using ubuntu-defaults-builder, it would be nice to see fully translated installation :)
<xnox> tclk/tk 8.6 maybe.
<cjwatson> mantas-baltix: I'll do it in bz rnow
<cjwatson> *bzr now
<rickspencer3> *sigh*
<rickspencer3> every
<rickspencer3> single
<rickspencer3> time
<rickspencer3> :)
 * mdeslaur votes for Tasty Turkey
<cjwatson> sing it
<ogra_> lol
 * xnox says Tasty TinTin
<xnox> mdeslaur: don't still my adjective!
<ogra_> TinTin isnt an animal
<rickspencer3> if it helps to know, I made several suggestions last week, but they each got shot down
<ogra_> Terrific Tapir !
<mdeslaur> Toxic Tuna
<Laney> Quality LTS name :P
<mdeslaur> hehe
<mantas-baltix> cjwatson: please wait 5 minutes, I'm finishing translation
<cjwatson> mantas-baltix: *sigh*
<cjwatson> don't ask before you're finished :)
<jibel> barry`, lool I reported bug 1240516
<ubottu> bug 1240516 in system-image (Ubuntu) "autopkgtest failure: test output goes to stderr" [Undecided,New] https://launchpad.net/bugs/1240516
<barry> jibel: will look
<jibel> barry, I'm looking at the failure on amd64, it is a timeout in download.py but on different tests between my run and automated runs
<lool> jibel: thanks
<barry> jibel: sigh.  i've been fighting this one for days.  i think there's a weird problem with download manager
<barry> jibel: it's hard for me to tell from that jenkins page what exactly is going to stdout
<barry> *stderr
<mantas-baltix> cjwatson: thanks for waiting, I've just finished :)
<mantas-baltix> good luck with Ubuntu 13.10 :)
<cjwatson> mantas-baltix: ok, re-requested a tarball
<infinity> smoser: Is curtin itself (and python3-curtin) meant to be seeded to main, or are you happy with just the bits that maas depends on being in main?
<smoser> i really dont care about 'curtin' and 'python3-curtin' themselves at the moment.
<smoser> infinity, i have a related question though...
<infinity> smoser: Alright, good.
<infinity> smoser: What's the related question?
<smoser> what is the reason why you'd have something split like that?
<infinity> smoser: Because we only have binaries in main that are needed in main.
<smoser> is there any real beneift?
<smoser> since we have to support the source package anyway.
<smoser> ok. thats fine.
<infinity> smoser: The benefit is for times when a binary produced from a main package happens to be something we don't WANT to support, so we only have things in main explicitly.
<infinity> smoser: nscd being the pathological case here.
<smoser> infinity, ok. then one more related question.
<smoser> give binary upackage 'foo', is there a way that i can easily
<smoser> a.) know what the source package is (other htan 'apt-cache show')
<smoser> b.) know if other binaries from that source are in main
<smoser> infinity, i know you're busy
<infinity> smoser: For (b), 'rmadison -S foo' works.
<infinity> smoser: For (a), apt is the simplest method.
<smoser> thanks infinity
<ScottK> xnox: While you're multi-arching boost, you might look at splitting the python binaries into python and python3 packages so they can have proper depends.
<xnox> ScottK: maybe. but boost is already multi-arched.
<xnox> ScottK: (1.53 in saucy)
<ScottK> Oh.
<xnox> i just was going to multiarch 1.54 into debian and sync it.
<ScottK> In any case, it needs doing.
<xnox> ScottK: true. but at the moment those boosts libs are still not abi-tagged and there is a request for dbg builds.
<ScottK> Yes, but they don't have correct python/python3 depends at all right now.
<ScottK> So even splitting py/py3 would be progress.
<jibel> barry, ah, I pasted a link to the console, on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-system-image/5/ARCH=i386,label=adt/ stderr is dsc0t-unittests-stderr
<barry> jibel: so *all* the test output is going to stderr?
<jibel> barry, yes
<barry> jibel: okay
<mpt> mvo_, hi, do you have five minutes to look at <https://code.launchpad.net/~brunonova/software-properties/update-apt-on-exit/+merge/190498>?
<mvo_> mpt: hi, sure! done - sorry I saw your question yesterday but did not quite manage to get to it
<mpt> thanks!
<bdmurray> mvo_: Hi, I was wondering if you might have a look at bug 1024590.
<ubottu> bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590
<mvo_> bdmurray: sure, I can do that later this evening, gtg now :) but thanks for the pointer to the report
<barry> jibel, didrocks, lool i'm uploading this change now: http://paste.ubuntu.com/6246069/
<lool> barry: keep it for next release
<barry> lool: ?
<lool> barry: I mean it doesn't need to be uploaded
<lool> barry: we've forced system-image in
<lool> barry: unless you want to use uploads to debug autopkgtests issues
<barry> lool: ah, okay.  no, i don't ;)
<lool> barry: there was another issue on the other arch too
<barry> lool: i haven't seen that.  i'll bet it was a timeout error in the autopkgtest
<lool> barry: one has FAILED (SKIP=3, errors=1)
<lool> barry: the other one FAILED (SKIP=3, errors=4, failures=2)
<barry> lool: were those all timeouts?
<lool> barry: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-system-image/
<lool> barry: jibel looked into reproducing these, you might want to sync with him to debug
<barry> lool: those are going to be extremely difficult to debug.  we may need to enlist mandel to get more debugging out of u-d-m
<lool> barry: sounds good
<barry> lool: it'll be a fun project for tremendous tadpole
<lool> barry: cant wait for the fun
<seb128> tedg, hey, do you know if anyone is looking at https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1230222 ?
<ubottu> Ubuntu bug 1230222 in unity (Ubuntu) "unity-panel-service assert failure: dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Connection was disconnected before a reply was received" [Undecided,Confirmed]
<seb128> not sure if that's a libnih or unity issue
<seb128> that's the most reported unity bug in saucy
<tedg> Hmm, no I don't know if anyone has.
<syeekick> im willing to upgrade its just that, im having trouble with my wificard not being supported properly
<tedg> But it'd be a no-op.
<seb128> tedg, wdym "no-op"? if the error is harmless we shouldn't bother users with apport prompt for it...
<syeekick> would the bcm4312 work fine in the beta?
<tedg> seb128, yeah, I think that's the solution.
<seb128> tedg, who would be the right person to own it? you? bregma? ;-)
<tedg> seb128, Though, has it been in recent versions?  I think slangasek was changing that code to fire-and-forget.
<slangasek> who am I firing and forgetting?
<tedg> slangasek, The nih signals in unity
<seb128> tedg, https://errors.ubuntu.com/problem/bdbd27d4a927ab7cb0fa8edbd1787564e7be8852
<seb128> tedg, yes, still happening
<seb128> slangasek, ^
<slangasek> "still happening" - seems unrelated to the changes we were making
<bregma> I think that bug started happening when u-p-s was moved to an upstart job
<bregma> dbus stops first, u-p-s barfs and dies
<tedg> I think it's related to the indicator signals
<tedg> Those are the only ones using libnih
<tedg> slangasek, Oh, were you only changing the Unity8 ones?
<slangasek> tedg: that's the only code we touched
<tedg> K
<slangasek> that's a strange backtrace - is it really throwing an error in an exit handler?
<tedg> \o/  NIH!
<tedg> Hmm, interesting, we're emiting the events sync...
<jodh> slangasek: nih registers an atexit handled to make sure the app dealt with all errors.
<slangasek> ok
<slangasek> tedg: so basically, this backtrace can only occur when u-p-s is exiting, so why is u-p-s exiting?
<tedg> slangasek, user logged out?
<jodh> tedg, slangasek: all the calls need their return checking to ensure no NihErrors are lurking.
<tedg> jodh, But they're all _sync calls.
<tedg> jodh, Wouldn't that do that already?
<slangasek> tedg: the bug report says "Unity doesn't load, no Launcher, no Dash appears" - are we looking at a user-affecting bug here, or not?
<slangasek> tedg: a sync call just means you know immediately whether an error occurred; you still have to check the retval to handle the error itself, AIUI
<tedg> slangasek, So we're checking to see if it's non-zero, but we need to remove it from the nih stack?
<jodh> tedg: if we're talking about indicatorsmanager.cpp, nih_dbus_proxy_new() isn't checked and it can return an error and create an NihError in the process. That code doesn't handle the failure scenario by consuming the NihError if there is one.
<tedg> jodh, We're talking about panel-service.c
<slangasek> right
<jodh> tedg: package?
<tedg> jodh, unity
<bregma> the bug is confusing, because the stack dump is from unity-panel-service but he's complaining about Unity proper not working (which is unrelated)... then apport marked a bunch of other u-p-s crashes as dups
<jodh> tedg: right - my comments still apply.
<jodh> tedg: if priv->upstart = nih_dbus_proxy_new () fails, you need to call "NihError *err = nih_error_get(); nih_free (err);"
<tedg> jodh, Okay, and the same for the emit events?
<jodh> tedg: you may want to print err->message somewhere before freeing the object to get a human-readable message.
<slangasek> tedg: this is the only nih_dbus_* call in the code, FWICS, so the only place it needs to be handled.  However, fixing that nih api issue will prevent apport crashes from being generated, but not actually get to the heart of why this error is happening
<slangasek> tedg: oh, but of course the upstart_* calls could also raise nih errors, yes
<jodh> tedg: Looking at the auto-generated code, yes, it does seem to raise NihErrors on failure.
<tedg> slangasek, Sure, this is probably masking another error, but we have to get this cleaned up before the other becomes visible.
<slangasek> tedg: well, no, because handling the error is going to give you the exact same message: "Connection was disconnected before a reply was received"
<tedg> slangasek, Sure, but I'm fairly certain that's unrelated to the comment on the bug.  Which is probably a different error.
<slangasek> right, that seems likely, since if upstart crashed I would expect the session to end
<slangasek> (crashed, was killed, whatever)
<tedg> So does this look correct? https://code.launchpad.net/~ted/unity/nih-signals-complete/+merge/191457
<tedg> (for the proxy)
<tedg> Do I need to check if nih_error_get() returns NULL?
<bregma> I'm actually using https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1236720 to track that particular bug to avoid confusion
<ubottu> Ubuntu bug 1236720 in Unity 7.1 "unity-panel-service crashed with SIGABRT" [High,Triaged]
<slangasek> tedg: that code looks correct to me; none of the upstart code checks for a NULL return in that scenario, it's pretty safe to assume it won't be
<tedg> Okay, now building Unity... we should have a fix by tomorrow.
<tedg> :-)
<seb128> tedg, thanks for working on that one ;-)
<chiluk> bdmurray, or any other coredev can one of you guys revert the fix that went in for 1150413...   It seems to have cause a regression bug 1157643..
<ubottu> bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643
<bdmurray> chiluk: bug 1157643 seems to deal with a couple of different issues, can you explain what happened with your SRU to me?
<ubottu> bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643
<chiluk> bdmurray... I'm still trying to figure it out myself.
<chiluk> I just found out 5 minutes ago that a number of users are complaining about procps in bug 1157643 since yesterday when the update was released
<ubottu> bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643
<chiluk> I can run service start procps just fine..
<slangasek> chiluk, bdmurray: I don't think it's a regression; I think 'service procps start' fails for these users every time they boot, but it doesn't block anything when it happens at boot
<slangasek> so the issue is that this is the first time they've upgraded procps since making whatever customizations they have made to /etc/sysctl*
<bdmurray> slangasek: I agree I was just testing with an lxc container and the old version of the package had the same issue
<chiluk> phew...
<verterok> chiluk: I'm here :)
<seb128> hey
<seb128> so my laptop is not booting anymore since today's update
<seb128> is there a known issue in saucy?
<chiluk> verterok, slangasek and bdmurray think this is not a regression, but instead simply the first time procps has been upgraded
<seb128> the boot stops on plymouth and displays "waiting for network" after a bit
<slangasek> bdmurray: it still seems an SRUable issue in its own right, but it's not a regression and trying to revert the change won't help ;)
<sidnei> chiluk: ah, that's likely yes. i mean, i do remember now trying to restart procps for some other reason and the start always failed
<seb128> hum
<slangasek> seb128: "waiting for network" should only wait for 120 seconds max
<seb128> intel driver fails to load as well... kernel issue?
<slangasek> shouldn't be any kernel changes in today's update
<seb128> slangasek, I got bored enough 120s, went to a vt and did startx from there
<slangasek> looking to see what came in with the latest updates
<slangasek> new X packages yesterday
<seb128> slangasek, well, I didn't update yesterday either
<seb128> dmesg has
<seb128> [   16.371270] wlan0: Limiting TX power to 27 (30 - 3) dBm as advertised by 18:3
<seb128> 3:9d:16:e7:e0
<seb128> [   17.492514] init: Failed to spawn nmbd main process: unable to execute: No su
<seb128> ch file or directory
<seb128> [  128.597580] audit_printk_skb: 180 callbacks suppressed
<verterok> sidnei, chiluk: so, what are our options here? fix lxc config to allow access to those sysctl keys?
<slangasek> "no such file or directory"? is your fs corrupted? :/
<slangasek> or is the samba package in state 'rc'?
<sidnei> verterok: i think procps needs an update to fix the start/restart initscript target
<sidnei> verterok: or something along these lines
<seb128> rc  samba                                                 2:3.6.9-1ubuntu1                               i386         SMB/CIFS file, print, and login server for Unix
<seb128> slangasek, yeah, I uninstalled it some days ago to test something
<slangasek> ok, so ignorable
<seb128> hum, I wonder if uninstalling samba is what created the issue
<sidnei> verterok: although, yeah, the failure is because of perms
<slangasek> seb128: not sure how it would
<seb128> slangasek, yeah, me neither...
<seb128> ok, let me fsck and try old kernel (and need to get lunch)
<seb128> bbiab
<slangasek> seb128: oh; except you're waiting for network, and the nmbd job starts on network, so if the job managed to get itself into a bad state...
<slangasek> well, timing
<slangasek> tedg: so I have a question about dbus best practices, maybe this is something you can help me with
<verterok> sidnei: looks like the apparmor profile is the culprit
<verterok> sidnei: /etc/apparmor.d/abstractions/lxc/container-base
<slangasek> tedg: we've been working on the memory leak in upstart, and jodh has succeeded in pinpointing the source of the leaking memory, and thinks he has a way around it - when we go to send messages, if the client still has one queued we drop instead of appending to the queue.
<sidnei> verterok: that's in the host?
<verterok> sidnei: yes
<slangasek> tedg: but my question is... why are we sending these messages to all clients anyway.  Apparently any time we see an upstart event we broadcast the message to all clients, and rely on the clients to filter out which events they care about... is that really the dbus way?  Because this seems to me to be an awful lot of cycles wasted sending messages that the clients know they don't care about
<sidnei> verterok: uhm, that's not even installed on my machine, im using a precise host
<verterok> sidnei: this is a saucy host
<verterok> sidnei: probably in another file?
<sidnei> verterok: which line you think it's the culprit on that apparmor profile for saucy host?
<sidnei> deny @{PROC}/sys/kernel/*/** wklx ?
<verterok> sidnei: yes: https://pastebin.canonical.com/99156/
<sidnei> verterok: right, so /etc/apparmor.d/lxc/lxc-default in precise
<verterok> sidnei: see the part: # deny writes in /sys except for /sys/fs/cgroup
<sidnei> verterok: so yes, while it's the apparmor profile that's blocking it, i don't think that needs to be changed. perhaps the fix is to not try to set those keys when running within lxc, or to fail gracefully instead.
<verterok> sidnei: you'r probably right :)
<sidnei> and the files that try to set those keys are part of the procps package
<bdmurray> smoser: did you see my comments in bug 1239893?
<ubottu> bug 1239893 in software-properties (Ubuntu) "PPAs added using GUI Software and Updates have an extra space added to repository line" [High,Triaged] https://launchpad.net/bugs/1239893
<sidnei> verterok: so if i understand the whole context, procps start has always been broken in lxc, but when called from upstart the failure to start is ignored. dpkg is not as forgiving, so trying to upgrade the package blows up because the service start step blows up.
<sidnei> verterok: and we only hit this on lxc because of the apparmor profile
<verterok> sidnei: I think that's the whole thing
<sidnei> chiluk: ^ dropping that into a bug, against procps i suppose?
<smoser> bdmurray, it doesn't seem to make sense to me to ad dthe newline there.
<smoser> (in your ocmment 8)
<smoser> fwiw, i'm not terribly personally interested in this. i think its not good that there is apparently a regression (but i've never tested ppa: in the gtk box on raring).
<smoser> i was primiarily concerned that i'd cauased a regression so thats why i initially  jumped in.
<chiluk> thanks sidnei...I'm really not the one to decide where the fix needs to be ..
<sidnei> chiluk: i'll append that as a comment to the existing bug then, let someone else sort it out.
<chiluk> so sidnei if I understand this correctly this only happens in an lxc guest
<sidnei> chiluk: yes, best i can tell.
<chiluk> or some other virtualization guest...
<chiluk> that has sys mounted from the host?
<sidnei> chiluk: possibly, or anything that has an apparmor profile restricting /sys?
<chiluk> sorry, I haven't had much of a chance to play with lxc..
<chiluk> alright.. I need to step away for a bit, but I'll take a look later today with this... at least document in the public bug what the understanding of the problem is.
<sidnei> slangasek: do you have any opinion on this? since the sysctl setup that's breaking under this environment is added by procps itself, but the failure only manifests under lxc (and apparently openvz too?) im unsure if the bug should be filed on procps or lxc.
<slangasek> sidnei: which option is breaking under lxc/openvz?
<slangasek> or are they all breaking?
<bdmurray> In my case it was the kernel ones
<slangasek> what kernel ones are those?
<sidnei> slangasek: there's 3 of them, let me get you a list
<bdmurray> kernel.printk
<bdmurray> kernel.kptr_restrict
<bdmurray> kernel.yama.ptrace_scope
<slangasek> ok
<sidnei> thanks bdmurray
<bdmurray> np
<slangasek> stgraber, hallyn: ^^ so /etc/init/procps.conf does not work reliably in containers because lxc doesn't want us writing to /proc/sys/kernel (apparently).  What should we do here?
<stgraber> slangasek: what's the problem caused due to LXC preventing writes in there?
<stgraber> slangasek: most of the files under /proc/sys/kernel aren't namespace aware so we certainly don't want to allow writing to them
<stgraber> (kernel.yama.ptrace_scope is one of those at least, I suspect the two others might be too)
<hallyn> accept that it might fail?  not run in containers?  what exactly is it failing on?
<bdmurray> upgrading the procps package
<hallyn> which variables i mean
<sidnei> hallyn: see a couple lines above
<hallyn> i thought procps used to proceed if it couldn't st seomthing
<slangasek> stgraber: the problem is that we expect the sysctl command to be reliable, and the procps maintainer script expects the upstart job to be reliable, and so these writes, which are allowed in a normal system, will fail
<hallyn> there are cases where the sysctl ceases to exist too right?  how are those handled?
<slangasek> hallyn: '-e': 'Use this option to ignore errors about unknown keys'
<slangasek> but that's specifically unknown keys, not "ignore errors when the kernel hates us" ;)
<stgraber> so if we want the upstart job to succeed we'll have to teach sysctl to ignore EACCESS
<slangasek> interesting, sysctl now has a --system option that makes the cat in /etc/init/procps.conf gratuitous
<stgraber> as there's no way we'll allow it writing to those files in a container
<slangasek> stgraber: and they can't be hidden in the container?
<slangasek> I guess you still want to be able to read them
<stgraber> unfortunately not, short of doing some very bad magic like using a fuse overlay on /proc
<stgraber> and indeed you still want read access
<stgraber> and some of those should actually be writable (and probably are, we unblock any entry that we know is namespace aware)
<bdmurray> smoser: fwiw I tested software-properties in raring and it doesn't have the bug
<smoser> so it is regression, probably shoudl tag that on the bug.
<bdmurray> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/software-properties/saucy-proposed/revision/126
<bdmurray> in line 707 you can see a strip()
<smoser> bdmurray, yeah, that would make sense. but i tested.
<smoser> i tried with version before my changes. and it was present.
<smoser> unless i just completely screwed that up
<tedg> slangasek, So the clients set up filters in the dbus daemon, so it doesn't really send them to all clients.
<tedg> slangasek, So from the perspective of the sender, they're going everywhere, but we're not waking everyone up.
<slangasek> in the case of a dbus daemon, right
<slangasek> but these are direct connections to the upstart server
<slangasek> tedg: what's the api for the client to set up the filter?
 * tedg looks for a link
<tedg> slangasek, http://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-add-match
<tedg> slangasek, And then click on the match rules link to see the format of the string.
<tedg> slangasek, Generally, point to point DBus interfaces don't install match rules.
<slangasek> tedg: got it, thanks.
<tedg> slangasek, Is there a reason we're not putting the session Upstart on the session bus?
<bdmurray> smoser: anyway, will you fix it or should I?
<slangasek> tedg: I don't know.  Up to now, the clients of upstart's dbus service have been either upstart bridges or short-lived clients
<slangasek> so there probably was no perceived need
<stgraber> tedg: the session bus doesn't exist when upstart starts, though that's fixable with something like is done for the system bus. I think we just assumed it wouldn't gain us much since the socket address is exported to all sub-processes anyway
<slangasek> tedg: but even if we put it on the session bus, we would still have point-to-point clients (the bridges), for whom these emitted events are *also* a waste
<tedg> Yeah, I was just noticing how the system bus worked there.  Was thinking that might be a nicer solution.
<smoser> bdmurray, you're welcome to.
<tedg> slangasek, The bridges could send directed signals.
<slangasek> tedg: meaning the bridges become dependent on the dbus session bus
<tedg> I'm probably more okay with everything being dependent on dbus than you are :-)
<slangasek> yep
<slangasek> stgraber: curiously, I see that all the bridges in the user session already 'start on started dbus'
<slangasek> stgraber: do you happen to know why that is?
<sidnei> stgraber, hallyn: as a result of this sysctl issue, anyone using (precise, at least) lxc containers has a broken system since procps landed on precise-updates yesterday. the maintainer script fails, and further apt invocations fail until that's resolved.
<stgraber> slangasek: no idea. I know that the first version of my event bridge was using upstart on session bus, but I changed that a bit later on. Maybe I forgot to change the start condition and everyone else copied it without thinking much about it? :)
<slangasek> sidnei: workarounds are possible (e.g., editing /usr/sbin/policy-rc.d to ignore requests for procps; or editing the config file in the container to comment out the problematic bits).  A proper fix is going to take a bit.
<slangasek> and it's going to have to be fixed in procps, not in lxc.
<slangasek> stgraber: heh, could be
<hallyn> sidnei: is there an open bug to track that?
<slangasek> tedg: so you would argue for having upstart register on the session bus and moving its clients over there, where we get filtering for free and only have to send our signals to one "client" (dbus); and not for adding support to upstart for supporting matches, which in the common case would avoid us having to send any signals about upstart events?
<sidnei> hallyn: bug #1157643 seems like it could be it
<ubottu> bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643
<tedg> slangasek, Yes, that would be my suggestion.
<tedg> slangasek, I think it also masks sense for the "DBus in the kernel" possible future, where we wouldn't want that support in Upstart as well.
<hallyn> sidnei: th
<hallyn> x
<smoser> bdmurray, please go ahead and apply your fix.
<slangasek> tedg: wouldn't want what support in Upstart?
<smoser> i verify that it *was* broken by me. :-(
<tedg> slangasek, The matches.   It would be dead code as we'd use the kernel support.
<slangasek> tedg: I don't follow you at all
<slangasek> is moving to the kernel intended to change the API for matches?
<tedg> slangasek, I'm just saying that adding support to Upstart to allow for matches on point to point connections wouldn't be used in the future.
<slangasek> still not following
<slangasek> having dbus in the kernel changes nothing about what interfaces upstart exposes
<slangasek> upstart is still a server that speaks dbus
<hallyn> slangasek: stgraber: so would teaching sysctl to check whether it is in a container, and, if so, check access(2) to the file, and not try writing if it gets EACCESS; seem reasonable?
<tedg> Sure, the question would be whether it's a service that talks to a DBus server or supports more DBus server functionality on its own connection.
<slangasek> hallyn: the "check whether it's in a container" worries me a little
<slangasek> tedg: upstart will *always* support more on its own connection, there are privileged operations that upstart (as pid 1) only allows on its private socket, not from the system bus
<hallyn> slangasek: well we *could* just not do that.  but /bin/running_in_container is supposed to be trustworthy...
<hallyn> i can see why that would be unsettling though
<slangasek> hallyn: I don't think sysctl should be shelling out to /bin/running_in_container
<tedg> slangasek, Why is that?
<slangasek> hallyn: and I don't like having to invoke running_in_container, because I don't like it when things are different inside containers than out :)
<slangasek> tedg: because upstart doesn't trust the system bus ;)
<tedg> slangasek, Does Upstart trust the kernel?  :-)
<slangasek> tedg: not as far as it can throw it
 * tedg may know the answer
<hallyn> slangasek: EACCESS is probably a good enough check.
<hallyn> the question is only, if you're on the *host*,. then you may want startup to actually break if you weren't able to set /proc/sys/FOO_i_rm-rf-/-if-unset
<stgraber> hallyn: just ignoring EACCESS seems reasonable, there's nothing sysctl can do about it, so just plain failing on it seems suboptimal. We can have it whine about it though.
<hallyn> stgraber: nothing it can do about it, but it *could* be a case where you're better off breaking boot (or upgrade) if it failed.
<stgraber> well, it wouldn't actually block startup though
<hallyn> then i guess it's worthless :)
<hallyn> ok lemme whip up a patch
<hallyn> (i assume noone else is yet?)
<stgraber> nothing appears to block on procps, so having it fail wouldn't really do anything
<seb128> back from lunch
<seb128> still no booting laptop though :/
<slangasek> seb128: so I think you're right about nmbd being involved
<seb128> slangasek, oh?
<slangasek> seb128: you're waiting for network, and the nmbd job starts on network, so if the job managed to get itself into a bad state, maybe it's blocked the static-network event
<seb128> slangasek, how do I see what is blocked?
<slangasek> seb128: do you have interfaces configured through ifupdown besides lo?
<slangasek> (i.e.: is NM in charge of everything?)
<seb128> nm is on charge of everything afaik
<slangasek> ok
<slangasek> that shoots a hole in that theory, then
<slangasek> as for seeing what's blocked, have a look at the output of 'sudo initctl list' and see if anything looks askew
<slangasek> (or pastebin it and I can have a look)
<seb128> slangasek, that's a bootchart: http://ubuntuone.com/2RwScS79hEMlQA7oxsRLmU
 * seb128 gets initctl list
<stgraber> seb128: are you at the office?
<seb128> slangasek, http://paste.ubuntu.com/6247160/
<seb128> stgraber, yes
<stgraber> I was thinking of coming to say hi, I guess I could take a look at that directly if that helps
<seb128> stgraber, that would be nice, but no hurry, I've a "working" system through ctrl-alt-f1/startx, so I'm not stucked
<seb128> stgraber, slangasek: does the pastebin gives you any clue?
<seb128> half of that list is stop/waiting :/
<hyperair> hmm, odd. for some reason i had a root-owned ~/.config/upstart and ~/.cache/upstart which blocked upstart from starting up in 13.10.
<slangasek> seb128: ... "boot-hooks/unity8-setcap"?  so you have unity8 packages installed on your laptop?
<seb128> slangasek, yes
<seb128> slangasek, ok, that was it
<seb128> slangasek, moving the boot-hook unblocked immediatly things
<slangasek> ok
<seb128> stgraber says it's lool's fault
<stgraber> that boot-hooks is "on starting lightdm" and was introduced this morning I believe
<stgraber> so anyone with that hook on a non-touch machine (that doesn't get the boot-hooks event) will get stuck
<seb128> lool, thanks for making my desktop not booting... :-(
<seb128> we have lot of unity8 testers/hackers on desktop
<stgraber> the solution would quite likely be to only ship the boot-hook on machines that have boot-hooks
 * seb128 reboots in a proper session
<seb128> stgraber, slangasek: thanks! system back to normal
<chiluk> so stgraber, slangasek... did we ever decide how to fix the lxc, procps not starting issue?
<chiluk> or was teaching sysctl how to and eaccess the proposed solution.
<stgraber> chiluk: yep, hallyn is working on patching sysctl not to fail on EACCESS
<chiluk> stgraber, ok... can I make a suggestion to make it print an error in the log on failure... that..
<chiluk> way, people who expect it to fail on error should hopefully still see a log entry
<stgraber> I'm fine with it printing a permission denied or similar error, not sure whether hallyn did that already
<seb128> lool, stgraber, slangasek: so, any taker on making unity8 not screw non-touch systems, before that bites more users?
<slangasek> stgraber, chiluk: hallyn has already posted a patch which does output a message to stderr, which means it'll go to /var/log/upstart/procps.log
<chiluk> close enough
<chiluk> do we have a new bug number?
<slangasek> seb128: no immediate ideas, other than moving the job to a separate package as stgraber said
<slangasek> chiluk: no, there's an existing bug report
<chiluk> ah nm.. I reloaded.
<chiluk> my earlier comment was based on trusting that others had done their due diligence.
<hallyn> yeah i didn't make a change, sysctl already prints out an error message and i left that there.
<alkisg> Hi, the last version of firefox in 12.04 no longer reads /etc/firefox/pref/apturl.js, breaking all apt:// URLs like e.g. https://apps.ubuntu.com
<alkisg> If we move apturl.js to e.g. /usr/lib/firefox/defaults/pref, then it works fine again
<smoser> joy. firefox now has 1.8g resident.
<smoser> this is possibly related to recent pentadactyl upgrade
<lool> seb128: Bah
<seb128> lool, just got somebody else here bitten by it
<lool> seb128: the worst is that I tried to design the contents friendly for desktop, but didn't remotely imagine it was already used
<lool> so
<seb128> lool, well, it's used to screw boot only it seems...
<lool> I guess one option is to move it to another package
<lool> another option is to remove it
<lool> seb128: problem is that this thing will also break apt/dpkg upgrades of unity8
<lool> not an issue on touch though
<seb128> lool, well, just move the conffile to the lxc package (what stgraber suggested before) and clean the conffile behind in unity8
<lool> seb128: Yes, that's what I was thinking by moving
<lool> slangasek: Mind reviewing r114 and r115 of lxc-android-config?
<lool> slangasek: in lp:ubuntu/lxc-android-config
<lool> slangasek: I wish I remembered the code.launchpad.net/ name for these branches
<slangasek> code.launchpad.net/ubuntu/+source/lxc-android-config - much too long to type, not worth remembering :P
<stgraber> the real branch is code.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy (and that's defnitely not worth remembering :))
<lool> Ah didn't try with +source
<slangasek> lool: structurally, it looks fine; I'm assuming the only thing you changed was the [ -e /usr/bin/unity8 ] check and that the job is otherwise unmodified from the previous version, so not reviewing that part
<lool> and the stgraber syntax is the one I dind't remember
<lool> slangasek: correct
<lool> slangasek: and it should work even if both jobs are in
<lool> so will upload this now
<slangasek> ok
<lool> slangasek: and https://code.launchpad.net/~lool/unity8/drop-setcap-conf/+merge/191520
<slangasek> lool: acked
<lool> thanks
<slangasek> lool: so taking a step back... why is this crazytown 'exec' mount needed?
<lool> slangasek: so yesterday I was told unity8 had to be setcap CAP_SYS_RESOURCE, but this didn't work on ext2
<lool> slangasek: we use ext2 because we only have mkfs.ext2
<lool> slangasek: I also didn't really like shipping xattr over system-image updates
<lool> slangasek: I chekced whether /etc/system-image/writable-paths would allow taking a tmpfs copy of unity8 to patch it there, but it didn't
<lool> slangasek: so the best option we found was a job to copy it before it starts, and add the xattr -- ugly, as noted there
<lool> slangasek: the hunt for writable locations only returned /run, but that's noexec
<lool> slangasek: hence the tmpfs on top of run; could also have been /var
<lool> slangasek: a proper way would be to use some root utility to gain this
<lool> slangasek: but the truth is we dont even truly need this
<lool> so we ought to revert it soon
<stgraber> in short it's a terrible hack for a case where we should have a service to do that kind of stuff (oom_adj changes) instead of giving fs caps to unity8
<stgraber> CAP_SYS_RESSOURCE isn't something you usually want to give to your users to begin with
<stgraber> man capabilities if you want to know why ;)
<slangasek> lool: right, what was the original justification for giving unity8 privileges to fill up the filesystem? ;)
<slangasek> I guess maybe it was for naughty rlimits
<stgraber> slangasek: unity8 apparently needs to set oom_adj
<slangasek> hmm
<slangasek> so of course, upstart supports this natively, as we discussed before
<slangasek> but you only get that from the system upstart
<lool> slangasek: So unity-mir gained yesterday the ability to set oom_score_adj as to recommend the Android OOM killer to prefer backgrounded apps
<stgraber> wouldn't exactly help for a user session
<stgraber> unless you give upstart cap_sys_ressource
<lool> the truth is you need no power to set oom_score_adj
<stgraber> which would be just as difficult (and arguably wrong) as giving it to unity8
<lool> you can do it, if you use a higher score than yours
<stgraber> right
<lool> so I think unity8 should just set scores higher thann its own
<slangasek> aha
<slangasek> yeah, agreed
<lool> also, the whole session is already started with -10, but that too isn't needed
<lool> (this is via upstart BTW  :-)
<lool> /etc/init/lightdm.override from lxc-android-config
 * slangasek nods
<lool> slangasek: Do you know why the released image need to match archive?  is this for GPL compliance?
<lool> does that imply we should do the same for touch?
<stgraber> lool: this is amongst other things to avoid re-downloading the whole release pocket indexes after install, match between the source CDs and the binary CDs is another reason for that indeed
<slangasek> lool: yes, broadly speaking it's about making sure we have the source for the images; less of an issue for touch where the images will be superseded soon after release
<lool> ok
<lool> seb128, slangasek: http://people.dooz.org/~lool/unity8-drop-setcap-conf/
<lool> seb128, slangasek: Tested by dpkg -i -O installing .debs here; I had the boot-hooks before, and now it's gone
<seb128> lool, great
<slangasek> lool: looks good print it
<seb128> lool, the files permissions are wrong on that people page, can't see those
<lool> ah sorry
<seb128> in fact only some of the files
<lool> fixed
<seb128> thanks
<lool> not sure why either, source file coming out of sbuild or something
<seb128> lool, your debdiff has code source changes, the debian diff looks fine to me
<lool> seb128: debdiff only misses changelog update for me: http://paste.ubuntu.com/6248252/
<lool> this is from unity8_7.83+13.10.20131016.1-0ubuntu1.dsc
<seb128> lool, oh, your version is unity8_7.83+13.10.20131016-0ubuntu1dooz1.diff.gz
<seb128> lool, so I diffed with 16 not 16.1
<seb128> lool, so yeah, looks fine to me like that
<lool> seb128: yeah; the root cause of the changelog diff and of that version delta just hit me
<lool> the changelog had not been automerged
<lool> I've merged it by hand now
<seb128> thanks
<lool> FYI the broken conf was published ~7 hours ago
<cjwatson> It's "distro-info-data is broken" day
#ubuntu-devel 2013-10-17
<pitti> Good yawning
<stgraber> hey pitti (probably a sign I should stop working soonish ;))
<pitti> hey stgraber, Ã§a va ?
<stgraber> pitti: bien et toi ?
<pitti> stgraber: un peu fatiguÃ©, mais bien, merci !
<RAOF> pitti: Good morning!
<pitti> hey RAOF, how are you?
<RAOF> I'm pretty good, yourself?
<RAOF> pitti: Feel like doing a colord upload from git?
<pitti> RAOF: can do
<pitti> RAOF: any hope this will fix https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/?
<RAOF> Oh, *that's* what I forgot!
<RAOF> So, maybe :)
 * RAOF checks
<RAOF> Bah. Stupid run-adt-test wanting an ubuntu-distro-info update that doesn't exist!
<pitti> RAOF: that was fixed in September already..
<pitti> revno: 232
<pitti>   Install distro-info during initial provisioning
<RAOF> âPlease check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for detailsâ wasn't.
<pitti> RAOF: ah, I think you can ignore that
<RAOF> Except that it appears to be a fatal error for run-adt-test :)
<RAOF> But I can work around it by extending Saucy's lifespan into November âº
<pitti> hm, I never ran into that
<sarnold> seen roughly six hours ago... < cjwa tson> It's "distro-info-data is broken" day
<pitti> oh, because there is no development series
<RAOF> Indeed
<stgraber> we just need to make distro-info send an e-mail to Mark asking for the new dev release name every time someone runs it, that may make things move faster ;)
<pitti> RAOF: built fine in sbuild; ok to upload? (I guess you don't want to un/re-tag that upload anyway, but would be nice to fix the autopkgtest at some point)
<RAOF> pitti: I don't mind blocking the upload on working out precisely why the test is broken.
<RAOF> It's not urgent.
<pitti> RAOF: ok
<RAOF> pitti: Hm. I think the particular adt failure is fixed, to be replaced by a new and exciting test failure!
<sirblubber> exit
 * hyperair wonders if it's an intentional design decision to have zero spacing between the icon and the text in appindicators.
<hyperair> which looks even better when the icons are not of the same width.
<RAOF> Grargh.
<RAOF> Stupid libtool stupid stupid stupid waaarghl.
<StevenK> RAOF: Tautology
<RAOF> pitti: Bah. I might just disable the tests :/
<mlankhorst> hahha
<pitti> slangasek: oh, still awake? must be release day..
<pitti> slangasek: or are you in London?
 * tumbleweed grumbles at distro-info
<tumbleweed> I wonder if we'll ever get a release name in advance of release, again
<tjaalton> meh, a local news site jumped the gun on the release..
<smartboyhw> tjaalton, which one?
<smartboyhw> (Can't these news sites be a bit patient?)
<tjaalton> smartboyhw: http://www.tietokone.fi/artikkeli/uutiset/ubuntun_uusi_versio_julkaistiin
<Laney> Wouldn't worry about it, happens every time
<tjaalton> hmm actually the headline is in past tense ("was released"), and the subtitle says "will be released today"
<smartboyhw> Nice grammar
<tjaalton> you bet :)
<mlankhorst> can someone accept mesa-lts-raring to precise-proposed
<mlankhorst> and then the binaries again after that?
<lifeless> slangasek: heh - are you really still working on https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/864466 ?
<ubottu> Ubuntu bug 864466 in kbd (Ubuntu) "break=foo boot option incompatible with gfxpayload=keep" [Medium,Triaged]
<mlankhorst> hm distro_info complains about being outdated :(
<Laney> yeah :(
<xnox> mlankhorst: file a bug and assign to sabdfl ?! =)
<mlankhorst> well I guess we need to know the new series first :P
<Saviq> pitti, ping
<pitti> hello Saviq
<cjwatson> mlankhorst: we've set silbs on the problem
<Saviq> pitti, hey, Q: since we can't send bug reports to LP from apport, how do I know it's actually sent et all?
<Saviq> pitti, for a 32MB report of Banhsee, it exits straight away after pressing S
<pitti> Saviq: they are (supposed to be) uploaded in the background; you should eventually get an .uploaded stamp in /var/crash/
<pitti> Saviq: pressing S will just generate the .upload stamp, which whoopsie should pick up
<Saviq> pitti, aah, so it needs to be there in /var/crash - if I retraced, need to put it there anyway
<Saviq> pitti, got it
<pitti> Saviq: (as I said, you can also comment out the problem_types line in /etc/apport/crashdb.conf to send it to apport, but you don't want that on the phone anyway)
<Saviq> pitti, yeah this one's from the desktop, but yeah, thanks
<pitti> Saviq: whoopsie doesn't do anything with the retraced result
<pitti> so that won't help
<Saviq> pitti, ah ok, so I just need to send the raw crash then :)
<pitti> Saviq: local retracing is mostly for your own benefit, not for error.u.c./LP
<Saviq> pitti, yeah
<YokoZar> http://i.imgur.com/FC5VM2S.png
<ion> :-D
<smoser> worlds most annoying bug
<smoser> chromium alerts me to something in the middle of the night. its dialog window goes beind some other window i have.
<smoser> no way to find it.
<smoser> clicking on the launcher chromium just brings the primary window forward
<StevenK> smoser: Alt-` ?
<smoser> StevenK, i guess the other part i didn't mention was the dialog goes on a different desktop
<smoser> (ie, i left the machine on a different desktop at night, so the dialog popped up there)
<smoser> so what would i open that bug on ? it reproduces with other non-chromium things. anything with a dialog.
<smoser> is that unity or compiz
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: closed | 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:
<Saviq> hyperair, ping
<hyperair> Saviq: pong
<Saviq> hyperair, hey, wanted to ask if I could help you somehow in getting banshee 2.9.0 packaged?
<hyperair> Saviq: eh well, i'm waiting for a dependency to pass throguh NEW
<Saviq> hyperair, ah, so probably not on release day :D
<hyperair> :)
<Saviq> hyperair, got a branch I could build locally?
<hyperair> Saviq: nope
<hyperair> Saviq: there are quite some changes in 2.9.0
<Saviq> hyperair, yeah I saw that
<hyperair> a lot of build-deps are changing
<hyperair> stuff moving to gtk3
<Saviq> hyperair, interesting all (save one) distro patches apply cleanly :D
<hyperair> oh that's nice
<Saviq> or with some offsets at most
<hyperair> configure flags will need fixing, build-deps will need tweaking..
<Saviq> hyperair, and what's the dep that's NEWing/
<Saviq> ?
<hyperair> gudev-sharp
<Saviq> hyperair, k thanks, feel free to ping me if you need help with it
<hyperair> sure
<smoser> anyone able to triage https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1240977
<ubottu> Ubuntu bug 1240977 in unity (Ubuntu) "some modal dialog windows such as chromium-browser get stuck/lost/do not raise if on different desktop" [Undecided,New]
<smoser> i'm not even sure if that is the right package.
<ChrisTownsend> smoser: One of us on the Unity team will take a stab first
<pitti> infinity: congrats!
<infinity> pitti: Thanks, I did it all by myself.
<pitti> infinity: and will receive all the blame, too!
<infinity> pitti: well, all the VAC bounces, anyway. :)
<seb128> is t open yet?! :p
<knocte> hyperair: speaking of 2.9.0, have you tested it with the mono that ubuntu 13.10 bundles? it crashes for me
<Laney> Onwards to Turgid Teletubby
<hyperair> knocte: er. nope, haven't tested 2.9.0 art all.
<hyperair> at*
<hyperair> knocte: but the last git version before gtk3 works
<hyperair> (the one in banshee-daily)
<knocte> I see
<knocte> well, I'm going to test with mono 3.2.1 now from directhex PPA
<pitti> seb128: telephatic tortoise
<knocte> I think it will fix it
<hyperair> okay
<pitti> away with hud, keyboard, touch, and mouse -- it will just read your mind
<barry> twerking turkey
<knocte> hyperair: if that's the case, maybe the daily ppa should depend on mono 3.2.1? can ppas depend on other ppas?
<hyperair> knocte: yes they can
<hyperair> knocte: but why?
<seb128> pitti, turbulent turkey you mean?
<hyperair> knocte: doesmono 3.2.1 not work?
<barry> tangy toucan
<knocte> hyperair: the other way around, I'm saying banshee 2.9.0 crashes for me with mono 2.10.x (the one that ubuntu has by default)
<hyperair> oh
<tumbleweed> surely tranquil for an LTS?
<hyperair> well try it and see, i guess
<hyperair> knocte: the problem is upgrading mono typically means upgrading the world
<directhex> hyperair, (banshee breaks on sgen on amd64)
<knocte> I know :(
<hyperair> knocte: i don't want to force such invasive changes for one app.
<knocte> directhex: I wasn't talking about that crash
<hyperair> (if possible)
<hyperair> directhex: what's sgen?
<directhex> the new default GC which was previously optional
<hyperair> bleh
<hyperair> is that a mono bug or a banshee bug?
<knocte> mono bug, but there's a patch for that which already fixes it
<knocte> cherrypicked from master
<knocte> but I wasn't talking about that crash at all now
<hyperair> oh
<hyperair> so there's another bug?
<knocte> I'm talking about mono 2.10.x crashing
<directhex> knocte, stack trace on paste.ubuntu.com ?
<knocte> directhex: unmanaged stacktrace for now, not very useful before I install debug symbols: http://paste.ubuntu.com/6251188/
<directhex> that's new and exciting
<knocte> the weird thing is that it doesn't happen with ubuntu 13.04 (which ships the same mono AFAIU)
<knocte> at least that's what Bertrand runs I think
<knocte> directhex: http://paste.ubuntu.com/6251236/ your ppa doesn't work with saucy right?
<directhex> knocte, add the raring repo, it should work the same on saucy
<knocte> ok thanks
<slangasek> lifeless: heh... no, not working on that one :/
<seb128> Laney, ara: hum, I wonder if there is an issue with https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.12
<seb128> the most frequent issues on e.u.c are segfaults in g-c-c networks's panel and e.u.c seems to indicate it started with that version
<seb128> though the diff is a bit weird as a cause of the stracktraces
<seb128> e.g
<seb128> https://errors.ubuntu.com/problem/7fe3809ac4806e554174f3ea41f1f31656f91a3a
<seb128> well, it didn't start with that version, but it was very unfrequent before
<ara> oops
<Laney> hmm
<slangasek> pitti: so, you think this code is too ugly to be enabled on !arm?
<pitti> slangasek: we don't need it on !arm, and we'd just make the filter chain unnecessarily slower
<Laney> seb128: yeah it's probably caused by this
<seb128> Laney, :-(
<seb128> Laney, do you see the bug in the patch?
<Laney> not immediately
<pitti> slangasek: also, I wanted to make as un-invasive as possible for an SRU
<pitti> slangasek: sorry, need to run now; TTYT?
<slangasek> pitti: ok.  fwiw I'd be more comfortable with it as an SRU if it were being applied consistently across architectures
<slangasek> I don't like arch-specific code paths
<seb128> Laney, do you want to have a look or should I follow up via email with the certification team/the guys who worked on the backport?
<pitti> slangasek: well, it's a signle-platform specific hack anyway, and while the overhead might not be that big it's certainly there
<slangasek> so I wonder what the actual overhead is of the filtering :)
<Laney> seb128: I'll look quickly but I can't verify it because I don't have precise/wifi to test flight mode
<pitti> slangasek: it's "no filter chain at all" vs. "having that filter chain" (i. e. not jsut three more commands)
 * pitti really off now, sorry
<bdmurray> seb128: could you or someone have a look at bug 1239226?
<ubottu> bug 1239226 in Ubuntu "battery suspend interval applies even when plugged in" [Undecided,New] https://launchpad.net/bugs/1239226
<seb128> bdmurray, seems like the bug Laney fixed in https://launchpad.net/ubuntu/+source/upower/0.9.22-1ubuntu1
<seb128> bdmurray, I've asked on the bug if that's still an issue
<bdmurray> seb128: thanks, I'd see it to and am rebooting to test again.
<seb128> bdmurray, thanks
<Saviq> kirkland, hey, is it possible that bug #878547 is back in byobu 5.17 (precise)?
<ubottu> bug 878547 in byobu "starts "apt-get -s upgrade" everytime it starts, but doesn't stop them when it exits" [Medium,Fix released] https://launchpad.net/bugs/878547
<kirkland> Saviq: hmm, the fix to that bug did land in precise, so if you're still seeing, it's probably another bug
<Saviq> kirkland, I was definitely having a bunch of apt-gets hogging my machine - and it seems to have stopped after disabling byobu - if I confirm I'll file a new one
<seb128> would be great if e.u.c was waiving a flag when a new bug jumps out, especially after a SRU in the lts
<seb128> (e.g that -
<seb128> (e.g that g-c-c segfault that was recently added in a sru)
<seb128> is that on some roadmap from someone?
<seb128> ev: ^?
<Laney> more bdmurray's turf I'd say
<Laney> We have the phased update stuff, it'd be similar-ish to that without the client side bits
<bdmurray> seb128: what bug?
<seb128> bdmurray, the one Laney just uploaded a SRU for,  https://errors.ubuntu.com/problem/7fe3809ac4806e554174f3ea41f1f31656f91a3a
<bdmurray> phased-updates would have caught that, the support just doesn't fully exist in precise
<smoser> $ ubuntu-distro-info --devel
<smoser> ubuntu-distro-info: Distribution data outdated.
<ScottK> smoser: That happens whenever there is no devel release.
<smoser> i know why :)
<smoser> was wondering if there was going to be a 'T' soon. or if i just missed it.
<ScottK> First sabdfl has to pick a name.
<ScottK> AFAIK, he hasn't.
<lifeless> congrats on the release
<lifeless> I'm plumbing for Taunting Tortoise
<smoser> plumbing ?
<lifeless> bah
 * smoser thinks of lifeless playing super mario
<lifeless> plumping
<Dayofswords> I wanted R to be Radiant Robin....
<sarnold> I think Reliant Robin was a missed opportunity..
<mwhudson> teratogenic texan!
<sarnold> Maybe Turbo Trabant could make up for it.. a bit..
<noskcaj> kirkland, roaksoax: Have either of you got time to help with testdrive now? A new Vbox release is out, i have a merge waiting, plus danChapman and i both have attempts at porting to gtk3 that need finishing.
<xnox> cjwatson: infinity: bdrung_: ScottK: smoser: i fixed ubuntu-distro-info and pull-lp-source: https://code.launchpad.net/~xnox/ubuntu-dev-tools/fix-series-alias-lookups/+merge/191700 and http://paste.ubuntu.com/6252891/
<xnox> the correct answer is "devel"
<slangasek> xnox: erm, cjwatson had specific reasons for not doing that, else it would've been done much sooner; who says this is "correct"?
<xnox> slangasek: i'd like to hear those reasons.
<xnox> slangasek: it did seem "correct" to cjwatson/apw/infinity and I in the pub couple of hours ago =)
<slangasek> xnox: hum, ok then
<slangasek> I remembered cjwatson having objections :)
<xnox> slangasek: well, it's not like there is any point to upload distro-info without new codename and cjwatson will be around to comment before that happens.
<xnox> cjwatson: what's wrong with adding a timeless "devel" entry to ubuntu.csv?
<slangasek> xnox: ack
<slangasek> xnox: oh right, so there's nothing wrong with adding it as an option, but there was a reason we didn't want it to be the default
<seb128> slangasek, hey, I was reading https://launchpad.net/ubuntu/+source/ubuntu-touch-session/0.81 ... do we have anything on the desktop supposed to "clean up pulseaudio on exit"?
<seb128> slangasek, I'm asking because I've issues where
<seb128> $ loginctl user-status ubuntu
<seb128>                   ââc22.session
<seb128>                   â ââ4322 /usr/bin/pulseaudio --start --log-target=syslog
<seb128>                   â ââ4395 /usr/lib/pulseaudio/pulse/gconf-helper
<seb128>  
<xnox> slangasek: oh i see, at the  moment "devel" ends up in "supported" =(
<xnox> slangasek: which is clearly wrong.
<seb128> slangasek, which makes lightdm/indicator-session show the "ubuntu" user as logged in when it's not
<slangasek> seb128: upstart should reap all of its children on exit, and this *was* working earlier in the cycle
<seb128> slangasek, well, I've also some indicator processes still running, those are not upstart managed, so maybe that's what is keeping pulseaudio active there
<xnox> slangasek: hm, but even with "$ faketime 2013-10-10 ubuntu-distro-info --supported" shows saucy as "supported".
<xnox> slangasek: i guess "supported" means stable+devel.
<slangasek> well, all the processes should have been children of upstart, which I would expect to reap all its children on exit, not just the ones directly related to jobs. hmm.
<xnox> slangasek: does our fast showdown/exit do this
<slangasek> xnox: what do you mean?
<xnox> slangasek: well the code fixes for "10s delay on logout"
<slangasek> xnox: which I think have not landed yet, right?
<xnox> i'm not sure i've seen it go into the path of reap all its children on exit.
<slangasek> I may have just been assuming this based on the behavior I'd seen
<xnox> slangasek: oh, right, it didn't. I thought it did....
<slangasek> I know that before we switched to user sessions, pulseaudio would leave processes around all the time
<slangasek> and when user sessions went live, this problem went away
<slangasek> but maybe it's come back again.
<slangasek> how do we launch pulseaudio, if not as a user job? .desktop?
<xnox> slangasek: i don't see a user job, there is a system job.
<xnox> slangasek: there is xdg-autostart .desktop file which calls the /usr/bin/start-pulseaudio-x11
<xnox> which is an interesting shell script...
<slangasek> yeah, but that script doesn't actually start the daemon
<slangasek> except as a side-effect
<slangasek> xnox: so pulseaudio is started ad-hoc on the desktop, and calls setsid(); which means signals don't propagate automatically to it, and I'm not sure session init even has a sane way to know it's there
<stgraber> I tried making it a user job initially then gave up
<stgraber> we'd need to override the pulseaudio dbus activation and then make it a user job. Or we possibly could ship a job that does nothing but has a post-stop which sends a kill signal to pulseaudio through pactl
<robert_ancell> beuno, hey, is there anything else holding up my click apps in developer.ubuntu.com?
<slangasek> stgraber: it seems to be a user job on the phone right now, fwiw... though the job is broken and is in state 'stop/waiting' because of a wrong expect rule
<stgraber> hmm, not sure how that's not racy then, unless the way dbus works on the phone makes dbus activation impossible?
<seb128> stgraber, slangasek: can we get upstart to do dbus activation?
<slangasek> seb128: er, we had patches in the dbus package to do this, and those patches were dropped
<seb128> slangasek, yeah, that's unfortunate, we got stucked with "no dbus maintainer, nobody knowing enough the code to update them"
<slangasek> yes, and yet someone updated the package and dropped the patches
<seb128> right, because it was either that or not updating dbus
<slangasek> instead of leaving the package as-is until somebody could move it forward
<seb128> iirc
<seb128> well, leaving things behind has issues as well
<xnox> slangasek: pkill -u $uid is a good call =)
<xnox> slangasek: or making logind rip kill processes...
<seb128> slangasek, but yeah, I don't disagree with you, it's just where we stand today :/
<stgraber> xnox: I like my LXC containers and screen sessions, so no thanks :)
<xnox> stgraber: if uid not in ['stgraber', 'hallyn', 'ubuntu']:
<slangasek> xnox: not so much :P
<seb128> xnox, seems you need to add slangasek to that list ... ;-)
 * hallyn tries to make sense of backlog
<slangasek> hallyn: xnox is trolling everyone who wants reliable systems
<seb128> hallyn, we are speaking about user processes still running after session closing
<stgraber> xnox: if lp.people[uid] not in lp.people['ubuntu-dev'].participants
<hallyn> if i wanted reliable systems, woudl i have just bricked my arm laptop with non-working kernel?  I DON'T THINK SO
<hallyn> we could do liek the cool systemd kids and use a cgroup :)
<stgraber> no, the cool systemd way is precisely the problem :)
<hallyn> (containers jumping into another cgroup)
<stgraber> yeah, would work for containers
<hallyn> stgraber: i was pretty sure that was the case :)
<hallyn> (saw logind mentioned)
<stgraber> not for screen/byobu :)
<stgraber> so start a screen session, logout, it's gone, doesn't seem ideal ;)
<stgraber> (and giving privileges to byobu/screen to change cgroups seems a bit hackish ;))
<ccope> hey hallyn, what held up setting CONFIG_USER_NS=y in the 13.10 kernel?
<ccope> i thought the last blocker were some xfs changes, which i thought got merged...
<hallyn> ccope: not in 13.10
<hallyn> they'r ein 13.11
<hallyn> but also,
<hallyn> there's an issue being worked on with overmounted directories not being deleteable by root
<hallyn> used to be no big deal as only root could overmount.  but now that anyone can do so, it's a problem
<ccope> ah. is the 13.11 milestone targeting a 14.04 release, or an update to 13.10, or something else?
<ccope> nvm, i see it is for 14.04
<kirkland> stgraber: what's this about byobu and cgroups?
<stgraber> kirkland: tmux/screen/whatever stays in the background get killed on systems using logind with cgroups (so not Ubuntu) when the user logout from the graphical session
<slangasek> kirkland: it's really a screen issue rather than a byobu one; but basically, reiterating that the cgroups model of managing desktop sessions is flawed
<kirkland> stgraber: well, that's not how things are supposed to work :-)
<kirkland> slangasek: ah, okay
<slangasek> "we don't want to use process groups for managing sessions, because things can escape them by calling setpgrp() and then we don't clean up the session properly" "so let's use cgroups instead, so that processes can't escape!" "hey guys, there are processes that actually need to escape and you've broken the existing interfaces for doing that"
<hallyn> slangasek: and then the answer is that you can escape cgroups anyway if you need to.  which means pgroups were just fine.  yes, i've argued that about 5 years ago iirc
<stgraber> hallyn: the way logind works, you can't escape them, well, unless you happen to own a cgroup directory somewhere else in the hierarchy
<hallyn> or you're root...
<slangasek> right
<bdmurray> slangasek: could you have a look at the upgrade failure in bug 1241120 with me?
<ubottu> bug 1241120 in ubuntu-release-upgrader (Ubuntu) "Unable to update to 13.10" [Undecided,New] https://launchpad.net/bugs/1241120
<Logan_> How should I version an SRU if I want it to be pushed up to t-series as well? And are SRUs being accepted right now for saucy?
<hallyn> stgraber: i don't understand the libvirt 0.9.8-2ubuntu17.15 rejection - libvirt 0.9.8-2ubuntu17.14 failed to build, .15 includes the bugs for .14 (which it fixes), but there's no explicity bug for the FTBFSs
<hallyn> anyway nonworking internet has me hulkified.  going outside for a bit
<Logan_> ScottK? Could I rudely bother you for an answer to my question above? :P
<ScottK> Logan_: SRUs are being accepted.  Just use regular SRU versioning.  As of now, the archive hasn't been copied to "T", so whatever gets in will automatically end up there.
<Logan_> Awesome. Thanks!
<slangasek> bdmurray: looking
<slangasek> bdmurray: so can you reproduce it with the apt-clone state?
<bdmurray> slangasek: I haven't tried that.  Do you know of a good way to test the apt clone files?
<slangasek> bdmurray: hum, there's supposed to be "some" way to do it, but I don't know the details - I thought you might :-)
<bdmurray> slangasek: I should probably sort that out then.
<bdmurray> stgraber: did you have a good way for testing release upgrades?
<slangasek> bdmurray: apt-clone itself has a 'restore' option, with a --destination flag; not sure if that tries to install all the packages or if it just restores the metadata
<bdmurray> slangasek: it tries to install the packages from whatever mirror is listed in sources too
<slangasek> ok, so maybe the fast path is to just unpack the tarball and point apt at it for upgrading
<slangasek> bdmurray: d=/tmp/1241120; sed -i -e's/raring/saucy/g' $d/etc/apt/sources.list; rm -f $d/etc/apt/sources.list.d/*.list; mkdir -p $d/var/lib/dpkg $d/var/cache/apt ; cp $d/var/lib/apt-clone/dpkg-status $d/var/lib/dpkg/status; apt-get -oDir::State::status="$d/var/lib/dpkg/status" -oDir::State="$d/var/lib/apt" -oDir::Cache="$d/var/cache/apt/" -oDir::Etc="$d/etc/apt/" update; sudo apt-get -oDir::State::status="$d/var/lib/dpkg/status" ...
<slangasek> ... -oDir::State="$d/var/lib/apt" -oDir::Cache="$d/var/cache/apt/" -oDir::Etc="$d/etc/apt/" dist-upgrade
<slangasek> seems like something we ought to encapsulate in a nice little helper script
<slangasek> unfortunately we can't just use -oRootDir because apt assumes that means it can find its binaries under that tree too
<slangasek> also, that fails miserably if using apt configured for amd64 on an i386 apt-clone ;)
<slangasek> bdmurray: in any case, that doesn't reproduce the reported problem
<bdmurray> bug 1241123 is similar and on amd64
<ubottu> bug 1241123 in ubuntu-release-upgrader (Ubuntu) "upgrade to saucy fails while calculating upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1241123
<bdmurray> however it looks like they have some package versions no longer available
<bdmurray>  xserver-xorg-video-intel  <2:2.21.6-0ubuntu4.1>   <2:2.21.6-0ubuntu4.3>
<slangasek> mm? 2:2.21.6-0ubuntu4.1 seems to be the raring-updates version
<bdmurray> I think 4.3 is current
<slangasek> not according to rmadison
<slangasek> -4.3 is only listed in raring-proposed
<bdmurray> oh, maybe its phasing
<slangasek> ah, rmadison is 6 hours out of date, interesting
<slangasek> bdmurray: tried with the other (amd64) one, can't reproduce the problem there either using apt-get dist-upgrade; maybe we need to simulate the upgrade with ubuntu-release-upgrader itself to reproduce the problem
<bdmurray> Did you look at the problem resolver log?
<slangasek> yeah
<bdmurray> I'm working on using apt-clone restore on an i386 lxc container at the moment
<slangasek> it gets in a loop w/ gdm/libgdm/gnome-shell, but I don't see any root cause for this
<bdmurray> what would I look for if I get this test system squared away?
<slangasek> bdmurray: I do see in https://launchpadlibrarian.net/154017777/VarLogDistupgradeMainlog.txt that it mentions removing gnome-bluetooth by request of lubuntu-desktop... which seems to be specific to u-r-u and could explain not being able to reproduce it with apt-get
<slangasek> bdmurray: well, if it's reproducible with apt-get then I'm not sure what to look at.  If it's not reproducible with apt-get but is reproducible with u-r-u, then that could point to a bug in the u-r-u quirks, like the above which might be a problem
<slangasek> but in theory that's a *post*-upgrade quirk
<slangasek> AIUI
<slangasek> anyway, both raring and saucy versions of gnome-shell depend on gnome-bluetooth, which makes that rule problematic but I'm not sure it's related to this upgrade problem
<slangasek> bdmurray: both of those bug reports have both lubuntu-desktop and gnome-shell installed, and both show gnome-bluetooth in the problem resolver output... different solutions considered in each case, but I'm starting to think that yes this is the cause and u-r-u's labelling these as "post" upgrade removals is misleading
<bdmurray> slangasek: yeah, it looks like an issue of having ubuntu-desktop & lubuntu-desktop installed
<slangasek> so I think just dropping the lubuntu PostUpgradeRemove line should DTRT, since that was added for the oneiric->precise upgrade and is obsolete now
<bdmurray> slangasek: okay, thanks
#ubuntu-devel 2013-10-18
<stgraber> hallyn: oh, sorry, wasn't obvious when I reviewed. I'll make sure to re-review tomorrow and get it in (I'll restore it from Rejected, no need to re-upload)
<pitti> Good morning
<pitti> slangasek, stgraber: I was going to create an UDS blueprint for P â S (and also R â S) upgrade testing, which scenarios we need, how to revive automatic testing, how to make it palatable for CI, etc.
<pitti> AFAICS we don't have one yet; is that ok to put into the foundations track? (we don't have a QA track)
<James_Epp> I do not know whether this was intentional, but for some reason, 12.04 does what 12.04.3 don't. This is in regards to network booting the live disc environment. More here: http://askubuntu.com/questions/359150/what-nfs-export-settings-do-i-need-to-boot-the-ubuntu-live-discs-over-a-network . This was a bit more than frustrating, to say the least.
<stgraber> pitti: foundations sounds appropriate for that, yes.
<stgraber> pitti: can you make sure I'm subscribed to this too?
<pitti> stgraber: yes, absolutely; for your "testing in LXC" experience :)
<stgraber> pitti: yep, I've some of that still running daily without much trouble, so definitely worth mentioning and looking into (now that people are getting used to using LXC for testing and QA)
<pitti> stgraber: last week I did a 12.04.3 to saucy upgrade, and it was ... well, anything but "catastrophe" doesn't accurately describe it
<pitti> that reminded me of that idea :)
<stgraber> I'd have to check the timing again with saucy, but back with Q, I'd get an upgrade test down to 5min or so on LXC with tmpfs vs 30-40min with KVM
<stgraber> pitti: yeah, lts to lts is a pain, it took me and the 12.04.1 team  3 months after the 12.04 release to get stuff back to working order
<stgraber> would be nice if we could avoid getting in the same situation this time around and be proactive
<stgraber> (SRUing all the lts-to-lts fixes wasn't much fun)
<pitti> yeah, with all those different LTS enablement stack backports it's going to be interesting to get back to a clean slate
<pitti> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1311-lts-upgrade-testing
<pitti> slangasek: ^ it went straight in, apparently because I'm in ~uds-organizers
<pitti> stgraber: added a few subscribers (mostly you, plars, jibel)
<stgraber> pitti: cool, thanks
<slangasek> pitti: +1 :)
<slangasek> pitti: fwiw I would expect most upgrade testing to just use chroots, neither containers nor kvm
<pitti> slangasek: I think with all those rather complicated scenarios there should at least be some post-upgrade testing; containers shouldn't add too much overhead?
<slangasek> pitti: I think they also don't add much value.  But I guess we can discuss in the session.
<pitti> tests like "is the current kernel installed and does grub point to it" certainly work in schroot, too
<dholbach> lool, happy birthday! :)
<jibel> pitti, thanks. I talked about upgrade testing to jfunk during our last call, and this is definitely a project QA should work on early this cycle.
<jibel> and it didn't receive lot of attention since Q
<hyperair> does the applications master scope not work for anyone here?
<hyperair> for some reason, super+a doesn't give me any results apart from dash plugins, but super seems to be able to find the results pretty quickly
<RAOF> hyperair: Works for me.
<hyperair> hmmmm weird.
<hyperair> maybe i should just restart my entire session and see if that helps matters.
<hyperair> it seems to work in the guest account.
<erle-> why don't you change your upgrade, that it first upgrades only essential packages (kernel, grub, X, desktop) and cleans up before it upgrades peripheral ones?
<erle-> some error in a latex packages screwed my whole installation again
<hyperair> heh actually you can complete it by just running apt-get dist-upgrade and apt-get install -f until no more upgrades remain
<hyperair> and wherever appropriate, dpkg --configure -a
<erle-> i did this
<erle-> apt think everything is fine
<erle-> but i dont come from lightdm into desktop
<erle-> neither gnome-panel nor gnome-shell nor unitz
<erle-> and cant see what packages to reinstall
<erle-> i reinstalled video drivers manually which gave me at least the chance to see the login screen
<erle-> i get an apport dialogue window btw, but even that does not work
<pitti> erle-: do you perhaps not have the ubuntu-desktop metapacakge installed? that should pull in everything that's required
<hyperair> erle-: did you just get a black screen with a pointer?
<hyperair> erle-: if so, try removing ~/.cache/upstart and ~/.config/upstart
<erle-> i get login screen
<hyperair> for some reason, those two directories were root-owned on my machine
<hyperair> i mean after logging in
<erle-> when i log in i get black screen with pointer and crash-report-dialogs
<hyperair> after logging in, what do you see?
<erle-> ok, i will clean upstart
<erle-> did not fix it hyperair
<hyperair> er okay, different bug then
<erle-> problem is that i cant see what actually is broken in detail
<hyperair> could you log into a tty and run ps -u `whoami`?
<erle-> pitti, it is installed
<erle-> hyperair, looks like a working session, many processes like indicator and unity panel runing
<erle-> i cant even click on the apport dialog, it does not show me the name of the failed process or anything
<hyperair> then it's not an upstart issue i guess
<hyperair> my guess would be that unity crashed somehow
<erle-> i will remove all gnome stuff and reinstall
<erle-> hyperair, bit i have exactly the same with gnome panel and gnome shell
<erle-> in fact i primarily use gnome panel
<erle-> i just use unity now because i guess you can support it better
<erle-> the crash dialogs seem to be update-notification rather than apport
<erle-> *update-notifier
<erle-> the crash seems to be xorg-related
<erle-> i removed crashreports and after loggin in again a xorg crash report appeared
<erle-> maybe it ist just fglrx's fail
<hyperair> probably
<erle-> i installed gdm, which does not even get to the login screen
<erle-> fortunately i have a second computer that does not get any proprietary blobs installed :)
<erle-> i reinstalled fglrx again
<erle-> now it works
<erle-> thank you for your assistence
<erle-> now i have to tell fglrx not to underscan my lcd screen ... :D
<hyperair> underscan?
<erle-> >the crashed program seems to use third party libraries
<erle-> >libgpg
<erle-> what?
<hyperair> where do you see that?
<erle-> hyperair, with hdmi connected, amd thinks it is a tv and scales the screen down
<erle-> hyperair, it was a crash report dialogue
<hyperair> mm i think it means that it's using a library that's not shipped by ubuntu?
<erle-> oh wait, i compiled some gpg stuff myself one day, maybe thats the reason
<hyperair> there we go
<hyperair> bleargh proprietary blobs
<Saviq> hyperair, hey, I managed to get banshee 2.9.0 to build - lp:~saviq/ubuntu/saucy/banshee/new-upstream-290
<hyperair> woot
<hyperair> bleargh bzr
<hyperair> can you give me a patch instead please?
<Saviq> hyperair, diff for debian/ probably enough?
<hyperair> yeah should be
<hyperair> i'd filterdiff it anyway
<hyperair> and shoot you if i spot anything that's not inside debian/patches. ;-)
<Saviq> ;)
<hyperair> Saviq: banshee's maintained in debian git, fyi
<Saviq> hyperair, had to disable meego and soundmenu extensions - they're not ported to gtk3 / something's wrong with notify-sharp
<hyperair> uh that's not good
<Saviq> hyperair, k, will know next time
<hyperair> soundmenu's important.
<Saviq> hyperair, https://bugzilla.gnome.org/show_bug.cgi?id=710423
<ubottu> Gnome bug 710423 in Other Extensions "SoundMenu extension fails to build" [Normal,Unconfirmed]
<hyperair> if you'd like to help out with banshee maintenance on the long term, do come over to #debian-cli on irc.oftc.net
<Saviq> and https://bugzilla.gnome.org/show_bug.cgi?id=710418
<ubottu> Gnome bug 710418 in Other Extensions "MeeGo extension not ported to GTK3" [Normal,Unconfirmed]
<hyperair> hmm.
<hyperair> i'm not sure we use meego these days
<hyperair> maybe i should just toss it
<hyperair> afair it was for UNR
<Saviq> hyperair, I've completely no idea about C# so might be tricky - I was doing this thing blind ;D
<hyperair> and didrocks did the patches.
<hyperair> haha, my C# knowledge is also rather patchy
<Saviq> hyperair, ah btw, the Homepage link in gudev-sharp should probably be updated - points at launchpad which is rather old
<lool> dholbach: thanks!
<hyperair> i mean i know how to get around with the packaging stuff, but the actual C# code i can only handle where it looks like java and C++
 * dholbach hugs lool
<lool> release for my birthday eh!
<Saviq> hyperair, the Vcs links didn't work either, but I assume that will fix itself after NEWing?
<hyperair> Saviq: yeah that's in the new upload of gudev-sharp stuck in incoming.debian.org
<hyperair> (i think)
 * Saviq preps the patch
<hyperair> Saviq: series of patches would be nice too.
<didrocks> Saviq: hyperair: yeah, I think the meego extension is completly abandonned, so feel free to drop it :)
<hyperair> didrocks: yay. that means half the patches we carry can go too
<didrocks> happy birthday lool! (weren't you supposed to not work today? :p)
<hyperair> \o/
<didrocks> hyperair: yeah ;)
<hyperair> \o/
<pitti> hey lool, bonjour ! bon anniversaire !
<lool> didrocks: Indeed!
<lool> didrocks: just sent a message saying I'm not  ;-)
<Saviq> hyperair, there's actually just two small patches to the code, the rest is debian/
<lool> pitti: merci !
<hyperair> Saviq: actually hang on, how did you get 2.9.0 to work without gudev-sharp?
<hyperair> and is this on saucy?
<Saviq> hyperair, built from your NEW
<hyperair> knocte was saying yesterday that banshee 2.9.0 was crashing with the mono in saucy..
<didrocks> lool: don't connect to IRC! ;)
<Saviq> hyperair, and btw, I did not say it *worked* ;D
<hyperair> aha
<hyperair> it built.
<hyperair> got it.
<hyperair> well there's progress i guess
<Saviq> yeah, crashed on startup
<sil2100> Oh, lool has birthday?! lool happy birthday!
<sil2100> I would opt for lool not working more than just today, as I saw him even at 3 AM at night working this week
<lool> thanks!  yeah even *I* have a birthday  ;-)  I thought I would never age
<lool> sil2100: I'm off til thursday with some leave days tacked
<sil2100> lool: awesome! Have a nice rest, this was a great release ;)
<Saviq> hyperair, here's the debian/ diff between my branch (based on ubuntu packaging) and debian git
<Saviq> hyperair, http://paste.ubuntu.com/6255584/
<Saviq> hyperair, there's some crap, but hopefully you'll be able to fish the interesting things out easily
<Saviq> hyperair, if you need me to, I can "rebase" onto the debian version
<hyperair> oh hmm, this is the merged version.
<hyperair> i think i should be able to apply this onto the ubuntu branch and see waht's different from there...
<hyperair> why does paste.ubuntu.com still require launchpad authentication to download as text?
<hyperair> =\
<hyperair> this is dumb. the stuff is public already.
<hyperair> why is dumping a paste as raw text something that requires authentication?
<wgrant> It discourages spammers, from what I recall.
<hyperair> spammers?
<hyperair> seriously?!
<hyperair> i'd understand if you require authentication to *post*
<hyperair> but to *get*?
<pitti> it's to avoid abusing this to store mp3s or videos, etc.
<hyperair> now i can't even wget the damned raw url.
<hyperair> bleargh
<pitti> (AFAIUI)
<hyperair> why is this not a problem with paste.debian.net and other public pastebins?
<pitti> so that you don't have an anonymous online storage space for anything
<pitti> hyperair: in principle it is; but I don't know, I'm just saying why it is like that
<hyperair> what's to stop me from opening the mp3 inside pastebin and ctrl+s'ing in firefox or chrome to get it?
 * hyperair sighs
<pitti> because you need to auth to LP, and thus you can be tracked down
<pitti> s/LP/oauth/, but whatever
<hyperair> ah, right.
<pitti> I agree that it's terribly inconvenient
<cjwatson> My understanding is that it was a real practical problem before .../plain/ started requiring auth
 * hyperair recalls complaining about this some years ago, but not knowing who to complain to.
<hyperair> and then i just configured my pastebinit to use paste.debian.net
<cjwatson> paste.debian.net expires pastes very quickly, which might have the effect of defending against this but is also very annoying in its own way
<hyperair> i see.
<cjwatson> I often run across Debian IRC logs with paste references that are now useless
<Saviq> hyperair, sorry about that :)
<hyperair> nevermind.
<Saviq> hyperair, I just got used to c+p into the terminal ;)
<hyperair> even with patches? =\
<hyperair> okay, i guess i could just use xsel
<fishor> hello devs. i hunt currently crash on empathy-call which seems to be platform specific. May be you can help me here. This crash can be reproduset even with "gst-launch-1.0 -v v4l2src ! x264enc ! fakesink"
<fishor> only on platforms supporting sse4.1
<fishor> last command on which it will crash is __memcmp_sse4_1() at sysdeps/x86_64/multiarch/memcmp-sse4.S
<fishor> is it known issue?
<fishor> i use libx264-123, version 2:0.123.2189+git35cf912-1. same version works on i5-3317U but fail i7-2677M
<jdrab> fishor: is this the same bug ? https://bugzilla.redhat.com/show_bug.cgi?id=957397
<ubottu> bugzilla.redhat.com bug 957397 in empathy "[abrt] empathy-3.8.1-1.fc19: __memcmp_sse4_1: Process /usr/libexec/empathy-call was killed by signal 11 (SIGSEGV)" [Unspecified,New]
<fishor> jdrab, yea... looks like it is
<Dark_light> Empathy can't show facebook accounts I think it's related to: https://bugzilla.gnome.org/show_bug.cgi?id=710363
<ubottu> Gnome bug 710363 in general "Adapt to changes in the redirect URI requested by Facebook" [Normal,Unconfirmed]
<Dark_light> I tested the patches there on gnome and they work fine
<fishor> jdrab, then this bug is probably in libx264-123
<jdrab> fishor: if i was you i would report it to launchpad as a bug and paste the link from redhat bugzilla
<Dark_light> If I wanted to open a bug for that shuld I open it for empathy or something else ?
<fishor> jdrab, ok, i reported it. https://bugs.launchpad.net/x264/+bug/1241486
<ubottu> Ubuntu bug 1241486 in x264 (Ubuntu) "empathy __memcmp_sse4_1: empathy-call was killed by signal 11 (SIGSEGV)" [Undecided,New]
<fishor> most probably this bug will add more troubles, for example with totem and other apps using gstreamer
<fishor> or apps using libx264-123 directly
<jibel> bdmurray, slangasek I suspect a problem with the upgrade of unity between raring and saucy
<jibel> bdmurray, slangasek we receive lot of reports where the upgrader prefers to keep the old libunity-common rather than upgrading libunity-core-6.0-8
<jibel> for example bug 1241485 or bug 1241243
<ubottu> bug 1241420 in ubuntu-release-upgrader (Ubuntu) "duplicate for #1241485 Unable to upgrade to 13.10 ( Could not calculate the upgrade)" [Undecided,Confirmed] https://launchpad.net/bugs/1241420
<ubottu> bug 1241420 in ubuntu-release-upgrader (Ubuntu) "duplicate for #1241243 Unable to upgrade to 13.10 ( Could not calculate the upgrade)" [Undecided,Confirmed] https://launchpad.net/bugs/1241420
<jibel> bdmurray, slangasek could you have a look and see if there is really a problem or it is a false alarm
<jibel> unity-common not libunity-common
<bdmurray> jibel: I'll have a look in a bit
<mdeslaur> welcome trusty tahr
<tvoss> mdeslaur, +1
<ogra_> \o/
<mitya57> http://trusty-tahr.jpg.to/
<smartboyhw> New codename?
<mitya57> yeah, check sabdfl's blog
<jibel> bdmurray, so, it seems that upgrade fails when unity is installed but not ubuntu-desktop ie people who installed unity on a flavor of ubuntu
<smartboyhw> Yay
<smartboyhw> It's too short though-.-
<Cimi> hey kenvandine :)
<Cimi> I'm sure you can help me
<jibel> bdmurray, confirmed, do a minimal install of raring + apt-get install unity => cannot upgrade to saucy
<tumbleweed> bdrung_: around?
<kenvandine> hey Cimi
<jibel> bdmurray, I completed bug 1241420
<ubottu> bug 1241420 in ubuntu-release-upgrader (Ubuntu) "unity held back if ubuntu-desktop is not installed during upgrade from raring to saucy (upgrade fails)" [Critical,Triaged] https://launchpad.net/bugs/1241420
<tumbleweed> xnox: how is your change to distro-info-data supposed to work?
<xnox> tumbleweed: what do you mean? it will start returning "devel" as the in-development release.
<tumbleweed> xnox: so, tools that currently use this information (e.g. dch) should be using devel instead of the codename?
<xnox> tumbleweed: and there is a tweak in lpapi cache in ubuntu-dev-tools for the cases where requested codename != series.name (a one liner extra cache)
<tumbleweed> that seems wrong
<tumbleweed> shoudn't we handle devel specially, like we do for Debian aliases?
<tumbleweed> it isn't a release
<xnox> tumbleweed: uploads to devel work in launchpad and get redirected to the "current_series" in lp-api speak.
<xnox> tumbleweed: no, it's special. In debian "sid" and "unstable" are both special. As sid will never release, and unstable is permament alias.
<xnox> tumbleweed: in ubuntu "trusty" will release and "devel" alias will be moved to next one.
<xnox> so semantics are very different.
<tumbleweed> xnox: right, and devel is an alias, not a release
<tumbleweed> xnox: yes, so this should be handled in distro-info, not distro-info-data
<xnox> i don't see how to specify alias in distro-info-data.
<tumbleweed> you can't
<xnox> tumbleweed: no, i explicitely do not want it to be handled in distro-info, as "devel" is valid series on release date, and even when there is no new codename.
 * xnox says works like a charm here on my machine =)
<tumbleweed> that might be useful to do, but I think tehy way you've done it is rubbish
<tumbleweed> now the order of the CSV entries matters
<xnox> it does in debian.csv case as well.
<xnox> especially sid vs experimental.
<tumbleweed> they are special cased in distro-info
<xnox> tumbleweed: distro-info is broken by definitions, it should never print "release-data out of date" and instead pick the most recent one it knows on the release date, instead of giving a fizzy fit ;-)
<tumbleweed> xnox: that would be broken behavior for a library
<tumbleweed> anyway, I'm reverting your change, and uploading with trusty. Shall we take the discussion of how to add devel to a bug?
<xnox> tumbleweed: why?
<xnox> tumbleweed: bdrung_ liked the change.
<tumbleweed> because I'd like to upload something that works
<tumbleweed> and Ic an't see how to make this work sanely
<xnox> tumbleweed: then don't upload.
<tumbleweed> what sohuld ubuntu-distro-info --devel return?
<xnox> tumbleweed: uploading incomplete behaviour is also wrong imho.
<tumbleweed> it's the status quo
<xnox> tumbleweed: no, it's just your prerogative.
<tumbleweed> EPARSE
<xnox> tumbleweed: given that both ubuntu & debian now have aliases, distro-info should encode them.
<tumbleweed> agreed
<cjwatson> That suggests they should be done in the same way, though, and this isn't
<xnox> tumbleweed: or have a new file-format to encode the rules of the aliases, given that "it's the last N" anyway.
<cjwatson> (sid isn't an alias)
<xnox> cjwatson: i think tumbleweed's argument is that "devel" should be handled the same way as "testing" is.
<xnox> (or well "unstable")(
<cjwatson> Yes - and I agree
<tumbleweed> it should, yes, it's an alias
<xnox> cjwatson: at the moment alias support in distro-info is #ifdef DEBIAN
<cjwatson> Except that we need to ensure that it continues to refer to the last thing in the list if there isn't something after it
<cjwatson> Sure, I know
<xnox> let me look how testing/stable aliases are defined.
<tumbleweed> xnox: special casing distro-info to return "devel" if there's no known development release would be very sensible
<tumbleweed> and yes, in general, ubuntu will need to gain alias support
<xnox> tumbleweed: no it should imho always return devel for development uploads in ubuntu.
<tumbleweed> xnox: it's used for things besides uploads
<xnox> tumbleweed: same way we upload to unstable, and not sid.
<tumbleweed> I don't want my QA databases to suddendly be considuring devel to be a release
<tumbleweed> xnox: has the ubuntu community decided that we want devel in our changelogs? I haven't seen any discussion on that
<cjwatson> xnox: Actually always returning devel is dangerous
<cjwatson> xnox: LP operations (e.g. syncs) require a concrete series name not an alias
<cjwatson> And that was deliberate
<xnox> tumbleweed: devel, is meant for people to track latest development series and use them in their apt sources.
<cjwatson> It's meant for that but it's too early to actually use in apt sources given that apt complains in odd ways when you do and it doesn't work right for all the pockets yet
<xnox> cjwatson: "deliberate" ok, interesting. Because getSeries(name_or_version="devel") returns me a series object in the api.
<cjwatson> xnox: that's different
<cjwatson> xnox: if you copyPackage(to_series="devel") it will fail
<wgrant> cjwatson: Hm, I thought I tried to push back on that, but the aliases ended up working for copyPackages in the end.
<cjwatson> Though admittedly syncpackage gets that directly from the API.  Still, I think distro-info should return concrete series names.
<cjwatson> wgrant: You did and I was fairly sure I'd incorporated your suggestion
<cjwatson> If they work then it's by mistake
<wgrant> _text_to_series seems to follow aliases.
<xnox> cjwatson: then "dch" is broken without updated distro-info, which is imho wrong & it should use "devel".
<xnox> cjwatson: unless we make a way to explicetely request alias.
<cjwatson> xnox: I think dch should be special-cased for Ubuntu as it is for Debian
<xnox> tumbleweed: debian-distro-info --alias --devel -> doesn't work, and i would have expected it to.
<cjwatson> wgrant: Maybe I misremember the discussion ...
<tumbleweed> xnox: wat
<tumbleweed> --alias takes an argument
<tumbleweed> yes, we need a reverse --alias
<xnox> tumbleweed: sure but `debian-distro-info --alias `debian-distro-info --devel`` is ugly UI =)
<tumbleweed> xnox: totally agreed
<xnox> if i want hte "devel" alias, for e.g. dch and stuff _I_ care about =))))
<tumbleweed> right, and I keep telling you that you are doing this in the wrong place
<xnox> tumbleweed: anyway, yeah add trusty to ubuntu.csv and upload without devel in there.
<xnox> tumbleweed: and we'll work out the alias semantics later.
<tumbleweed> if you want devel in dch, then dch doesn't need to use distro-info
<erle-> are logs from /var/crash save to upload from a privacy perspective?
<tumbleweed> devel is forever
<xnox> tumbleweed: but like "update-maintainer" and things like that should learn that "devel" is ubuntu.
<tumbleweed> yes
<xnox> cjwatson: hm.... will DEB_VENDOR trip up on "devel" at all?
<xnox> oh, it's per vendor, nor per vendor release, so shouldn't.
<cjwatson> I don't think there's a great rush to sort out devel; it can be done at leisure
<cjwatson> There are several things to adjust
<xnox> ok.
<tumbleweed> so, does this look right? 14.04 LTS,Trusty Tahr,trusty,2013-10-17,2014-04-17,2019-04-17
<xnox> tumbleweed: it's been created on 2013-10-18.
<xnox> =)))) (me ponders if created date should encode when sabdfl gave us the codename ;-) )
<tumbleweed> xnox: yeah, I'd rather not have the discontinuity
<xnox> tumbleweed: yeah, due to distro-info brokeness. that's fine. I am half joking at this point =)
<tumbleweed> historically, there used to be very long archive opening delays, we don't encode that
<xnox> ah, true true.
<shadeslayer_> I'm using the UbuntuDrivers Python 3 API to write a driver manager for Kubuntu but it seems like the API isn't returning the currently active driver for me
<shadeslayer_> see http://pastebin.kde.org/ppbk8vvv9
<tseliot> shadeslayer_: if you send me an email about that I can probably help
<shadeslayer_> tseliot AT youboontoo dot com ?
<bdmurray> slangasek: do you have any ideas on bug 1241420?
<ubottu> bug 1241420 in ubuntu-release-upgrader (Ubuntu) "unity held back if ubuntu-desktop is not installed during upgrade from raring to saucy (upgrade fails)" [Critical,Triaged] https://launchpad.net/bugs/1241420
<tseliot> shadeslayer_: you'll find my address here: https://launchpad.net/~albertomilone
<shadeslayer_> ack
<bdmurray> I think I ended up with a similar problem after fiddling with the lubuntu-desktop PostUpgradeRemove
<slangasek> bdmurray: in the process of wrapping my brain around it.  unity-common being obsolete means it should get removed, but apparently it hasn't been hinted hard enough
<slangasek> oh?
<bdmurray> Well the PostUpradeRemove change wasn't enough at any rate
<slangasek> hmm
<stgraber> hallyn: libvirt accepted into precise-proposed
<hallyn> stgraber: great, thanks.  i'm a little confused as to why the builds succeeded on arm tbh...  guess the testcases didn't run there or something
<slangasek> bdmurray: so I can certainly reproduce the problem, but I'm not yet seeing why apt gets wedged this way
<bdmurray> slangasek: is it odd that libunity-core-6.0-8 provides and conflicts with unity-common?
<slangasek> bdmurray: nah, Provides/Conflicts/Replaces is a standard method of taking over from another package
<slangasek> bdmurray: reproducible with apt-get dist-upgrade, that's helpful
<slangasek> bdmurray: so the problem may be related to libunity-core-6.0-8 Conflicts: unity-common recursively breaking libunity-core-6.0-5 and unity, and apt not following this all the way around; I guess that having libunity-core-6.0-8 declare Breaks: against the old version of unity and libunity-core-6.0-5 will help here, let me try that locally
<bdmurray> slangasek: ah earlier I see a Holding Back libunity-core-6.0-8:i386 rather than change unity-common:i386
<bdmurray> slangasek: how will you try that locally?
<slangasek> bdmurray: hacking /var/lib/apt/lists/*Packages :)
<slangasek> didn't help
<slangasek> 'apt-get -o Debug::pkgProblemResolver=yes purge unity-common', with raring packages installed and sources pointing to saucy, is instructive
<bdmurray> slangasek: that's a lot to read through.  Have you looked at libwayland-client0 yet?
<slangasek> bdmurray: I haven't; I actually decided that the 'purge unity-common' was probably not going to be the shortest path and am looking at dist-upgrade output again
<slangasek> bdmurray: anyway, I'm permuting the upgrade options by editing the Packages files and running 'sudo apt-get check' to force a cache update
<slangasek> bdmurray: hmm, apt is mocking me, 'apt-get check' isn't actually honoring my changes
<slangasek> bdmurray: oh, because I have multiple sources, whoops
<smoser> hey.. per my apt-cache, swift is universe
<smoser> http://paste.ubuntu.com/6258843/
<smoser> i do not believe that to be the intention
<smoser> and it disagrees with https://launchpad.net/ubuntu/+source/swift
<slangasek> bdmurray: ok, adding libunity9 Breaks: unity-common (<< 7.1.2) is sufficient to get apt to DTRT
<slangasek> smoser: the source package is in main; most of the binaries are in main; the swift binary is not because nobody seeded it or depended on it
<bdmurray> slangasek: great, so what is next?
<slangasek> bdmurray: SRU of libunity
<smoser> slangasek, thanks.
<slangasek> bdmurray: unless you think it would be better to quirk this in ubuntu-release-upgrader, which is also possible but not strictly necessary
<slangasek> well, theoretically possible
<slangasek> I think it'd be easier to address it in libunity, in this case :)
<bdmurray> And also help being using apt to dist upgrade
<bdmurray> s/being/people/
<slangasek> yep
<bdmurray> so you'll upload it?
<slangasek> sure, can do
<bdmurray> How did you arrive at libunity9?
<slangasek> bdmurray: I looked at the set of unity packages in the apt-get dist-upgrade output that were being upgraded instead of removed, and picked one
<slangasek> unity-services might be a better choice conceptually since it's from the same source, but libunity* are more likely to get the right result from apt since they're lower in the stack
<slangasek> bdmurray: ok, uploaded
<infinity> smoser: It's always been in universe.
<smoser> infinity, thats fine.
<infinity> smoser: For future reference, what you probably want here is "rmadison -S swift" to tell the whole story.
<brainwash> it looks like bug 1205384 is still present, can anyone else confirm this?
<ubottu> bug 1205384 in lxsession (Ubuntu) "Lock can be circumvented by switching to console" [Undecided,Confirmed] https://launchpad.net/bugs/1205384
<mdeslaur> brainwash: you need to lock the screensaver before you switch to the greeter lock mode
<brainwash> mdeslaur: yes, I know that, but all the lubuntu 13.10 users don't I guess
<mdeslaur> brainwash: well, not manually, I mean whatever lxsession is doing has to lock the screensaver
<mdeslaur> brainwash: what's calling dm-tool?
<brainwash> it's just switching to the lightdm greeter, didn't see it calling a locker
<brainwash> the lxlock script
<brainwash> part of the lxsession package
<mdeslaur> brainwash: ah, yeah, that script is wrong
<brainwash> mdeslaur: yeah, needs to fixed asap I think
<brainwash> and they already removed xscreensaver
<mdeslaur> brainwash: what's the default screensaver in lxde?
<brainwash> I'm not that familiar with lubuntu/lxde
<brainwash> I was just curious about the lightdm locker mechanism
<mdeslaur> brainwash: lightdm doesn't actually lock the screen, something else has to
<brainwash> yea, I'm informed
<brainwash> there is a working solution, light-locker, but it's not yet available in the official repository
<brainwash> just want to make sure that someone verifies this (security) issue and informs the right people to fix it
<chiluk> yay 64-bit default.... I see pigs flying...
<slangasek> chiluk: duck, those things pack quite a wallop when they hit you
<chiluk> slangasek, see it wasn't that hard.
<bdmurray> slangasek: there is still the lubuntu-desktop postupgraderemove change which I'll upload today.  I want to see if there are any other upgrade issues.
<slangasek> bdmurray: sounds good
<kirkland> I have a strange build failure on 13.10...
<kirkland> cp: cannot stat â/usr/share/automake-1.11/INSTALLâ: No such file or directory
<kirkland> that file does not exist, as it's in â/usr/share/automake-1.13/INSTALLâ:
<kirkland> why on earth does automake use a 1.11 path?
<kirkland> doh
<kirkland> nevermind
<brainwash> mdeslaur: any new information regarding bug 1205384? nothing has been done during the development cycle to fix this, so I'm not sure if anything will happen any time soon
<ubottu> bug 1205384 in lxsession (Ubuntu) "Lock can be circumvented by switching to console" [Undecided,Confirmed] https://launchpad.net/bugs/1205384
<mdeslaur> brainwash: I don't have any information...perhaps contact the lxde team? I'm not sure who's on it
<brainwash> mdeslaur: I'll do that, thanks
<bdmurray> slangasek: bug 1241487 looks like an issue with gdm and libgdm
<ubottu> bug 1241487 in ubuntu-release-upgrader (Ubuntu) "Release upgrade aborts with error message" [Undecided,New] https://launchpad.net/bugs/1241487
#ubuntu-devel 2013-10-19
<mlankhorst> can someone accept all the binaries pending in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= ?
<sicness> Hi. I found a bug during Ubuntu 13.10 installation. Against what package I should file the bug?
<ricotz> doko_, hi :), would it be possible to move https://launchpad.net/ubuntu/+source/base-files/6.12ubuntu5 from proposed to release faster to unbreak launchpad recipe build which rely on it for adding the correct version suffix?
<infinity> ricotz: Normally, I'd flat out say "no", but given the special nature of base-files, I've done it manually until we get proposed running again.
<ricotz> infinity, thanks!
<AbsintheSyringe> when trying to upload new version of package to ppa I keep getting my source.changes rejected due to "Launchpad failed to process the upload path '~<launchpad-id>/ubuntu':/Could not find person or team named '<launchpad-id>'."
<AbsintheSyringe> .dput.cf contents: http://paste.debian.net/plainh/8bc8bf8f
<AbsintheSyringe> any ideas?
<lenios> AbsintheSyringe, i have "incoming = ~%(ppa)s/ubuntu" and upload with dput ppa:<launchpad-id>/ppa
<lenios> are you sure about your launchpad-id?
#ubuntu-devel 2013-10-20
<Heavensrevenge> hello, can anyone point me to how the control flow works in mir?
<Heavensrevenge> the spec page only has 1 way diagrams but doesnt show how an event flows from input->output
<OSIEL> Wich is the channel for developers of drivers for ethernet??
<OrokuSaki> https://github.com/milaq/android_device_hp_tenderloin/commit/4a498d46fce9daa16f32631c8dc9b7ebbf5f15d5 Maybe this will work...
<OrokuSaki> reverting that
<benishor> hi there. after upgrading to 13.10 (from 13.04), indicator-session icon is missing, http://hq.scene.ro/session-indicator-missing-icon.png
<benishor> can anybody help me with a hint into restoring it? already tried to purge session-indicator and reinstall it but to no avail
<benishor> I found the problem: system-devices-panel* icons that are being refered by indicator-session's service.c, are not available in the default icon theme. weird
<akis24> sorry
#ubuntu-devel 2014-10-13
<Logan_> infinity: can you please explain how this is possible? https://buildd.debian.org/status/logs.php?pkg=libquantum&arch=ppc64el
<StevenK> Logan_: It was retried, and built sucessfully?
<Logan_> StevenK: well yes, but why did it work the second time? I thought it would require an autoreconf to build properly on ppc64el
<StevenK> Logan_: It symlinks /usr/share/misc/config.{guess,sub} into the build dir, so perhaps autoconf was changed on ppc64el ?
<Logan_> StevenK: it was a libtool issue the first time, not a config.{sub,guess} issue
<Unit193> pitti: Good morning.
<infinity> Logan_: That's curious, since it seemed to magically fix its libtool macros.
<cjwatson> Logan_,infinity,StevenK: there was something central that improved the chances a good deal for packages that weren't reconfigured; I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760395
<ubottu> Debian bug 760395 in src:binutils "binutils: add powerpc target for ppc64el" [Normal,Fixed]
<cjwatson> but I wonder if it built correctly
<cjwatson> p/usr/lib/libquantum.so.8.0.0: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, BuildID[sha1]=d286f4ec7d9af649b7a26e1b938e6d4f1e65c297, stripped
<cjwatson> looks ok
<cjwatson> doesn't seem to actually end up passing -m elf64ppc to the linker
<infinity> cjwatson: I'm confused as to how that would fix the libtool macro issue...
<cjwatson> because ld -m elf64ppc now magically works I think
<cjwatson> you can see in the build output that it's using ld -m elf64ppc both times
<infinity> cjwatson: So all our libtool mangling is unnecessary now?
<cjwatson> I don't know enough to go that far
<cjwatson> but it seems to have let us get away with more
<infinity> Cause yeah, that should be -m elf64lppc
<cjwatson> I'm still a lot more comfortable with autoreconfing anyway
<infinity> Note the 'l'.
<cjwatson> e.g. because I'm not sure whether that -m elf64ppc might ever leak through into actual build commands
<cjwatson> so I certainly wouldn't go dropping the patches we have
<infinity> I guess I'm scared that it would be misbuilding things as the wrong endian.
<infinity> Anyhow, lunch.
<mlankhorst> ugh..
<mlankhorst> infinity: I don't suppose I could upgrade libgbm1 in trusty once? :P
<infinity> mlankhorst: Upgrade it to what, and why?
<mlankhorst> version in utopic, conversion to dri-loader should hopefully mean no further upgrades needed
<mlankhorst> oh hm. trusty might be recent enough
<mlankhorst> I'll give it a shot, this would simplify things a lot. :)
<rbasak> jpds: as strongswan 5.1.3-0ubuntu1 is unlikely to get fixed this week, perhaps we can just delete it from utopic-proposed and release Utopic with 5.1.2-0ubuntu2 as it is in Trusty. Then there won't be any additional maintenance burden over Trusty, and we can merge Debian's 5.2.0-2 next cycle. Any objection?
<rbasak> (this assumes it rebuilds OK on Utopic, although I don't think we'll actually have to do that)
<Riddell> pitti: is there a tech board meeting tomorrow?
<pitti> Riddell: there is, yes
<pitti> darkxst: FYI, systemd 215 (with all Ubuntu changes) in my PPA: https://plus.google.com/u/0/107564545827215425270/posts/DaDxtzbWWsH
<Riddell> pitti: what time? where?
<pitti> Riddell: 15:30 UTC in #ubuntu-meeting-2
<mvo> Riddell: thanks for the app-install-data reminder, its uploaded now
<Riddell> pitti: golly, that isn't documented anywhere
<pitti> Riddell: ah right, https://wiki.ubuntu.com/TechnicalBoardAgenda is lagging behind
<Riddell> pitti: nor is http://fridge.ubuntu.com/calendars/
<rbasak> pitti: while you're looking at that, it'd be nice if it were easier to find logs or minutes of previous minutes. They aren't all there. Just a link added every week to the irc logs would be useful - I struggled to find that the other week.
<jderose> so i'm trying to get a trace of this https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1366351 with glib, gtk dbg packages installed... but apport isn't letting me because it's already been reported so many times (although i don't think with the dbg packages installed)
<ubottu> Ubuntu bug 1366351 in compiz (Ubuntu) "compiz crashed with SIGSEGV in g_closure_invoke()" [High,Triaged]
<jderose> is there a way for me to force apport to file the bug anyway, or at least attach a new trace to lp:1366351 ?
<sarnold> jderose: try apport-collect 1366351
<jderose> sarnold: just figured that out and did, but thank you!
<jderose> sarnold: so the warnings  from apport-collect didn't make it clear to me what the prefer/most helpful workflow is here. did i make a mess of lp:1366351? should i have done anything differently?
<sarnold> jderose: heh, I was just about to say "probably fine" but I see Logan_ disagrees :) I'll defer to him, sorry for steering you that way..
<jderose> sarnold: yeah, i just saw that. oops :P
<Logan_> infinity: per that discussion, does that mean that an autoreconf should still happen for e.g. libquantum?
<Logan_> doko too ^
<doko> ENOCLUE which discussion
<Logan_> oh, about adding the ppc64el target to binutils
<Logan_> doko: https://www.dropbox.com/s/sixz1k1fnz5elg0/Screenshot%202014-10-13%2015.53.20.png?dl=0
<Logan_> I had noticed that libquantum built successfully after a second try, which confused me: https://buildd.debian.org/status/logs.php?pkg=libquantum&ver=1.1.1-3&arch=ppc64el
<cjwatson> Logan_: I would be inclined to keep it
<cjwatson> Logan_: It's the right thing to do anyway and may help with future ports
<jungle_bg_> There is a problem with the git repo for the saucy kernal source. I have been trying to get the ubuntu kernal source for saucy. This failed for me and someone else in #ubuntu confirmed:  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git
<cjwatson> jungle_bg_: Probably best to ask on #ubuntu-kernel.
<darkxst> pitti, great, I will try it out
<slycheese> Does anyone know if it's possible to present as a USB client on hardware running XUbunu (via OTG)?
<hallyn> slangasek: drat!  somehow the cgmanager in unstable ended up ont having the patch it needed.  (my local copy did, so something sad happened)  I've pushed 0.33-2 to mentors containing the needed patch for debian bug 757348
<ubottu> Debian bug 757348 in cgmanager "systemd: with SysV init, can no longer suspend and shutdown from lightdm" [Grave,Open] http://bugs.debian.org/757348
<hallyn> :(
 * hallyn forces himself to shut down before he misses the whole night's sleep
<xnox> bdmurray: thanks =)
#ubuntu-devel 2014-10-14
<slangasek> hallyn: ok; I wondered why it didn't have mention of the patch in the 0.33-1 changelog fwiw.
<Mirv> any core-dev around? there'd be a packaging ack needed for platform-api dropping protobuf-compiler dependency: https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_2.5.0+14.10.20141013-0ubuntu1.diff
<RAOF> Woo!
<RAOF> No more crazy protobuf hax!
<RAOF> Mirv: Looks sensible, ack.
<Mirv> RAOF: thanks!
<ypwong> cjwatson, bug 1330416 still happens when UEFI mode is set
<ubottu> bug 1330416 in Ubuntu Kylin "In Ubuntu Kylin, default langauge in Ubiquity language chooser is not Simplified Chinese, isolinux/lang not honoured" [Critical,Confirmed] https://launchpad.net/bugs/1330416
<cjwatson> ypwong: I've seen your mail but have no time to investigate at the moment, sorry.  (Incidentally it should probably really have been a new bug)
<ypwong> cjwatson, do you want us to file a new bug?
<ypwong> BTW I haven't sent email to you, perhaps that's from someone else.
<cjwatson> ypwong: well I saw somebody's mail on that bug anyway.  yes, it should be a new bug and 1330416 should be closed again; isolinux/lang is entirely irrelevant on UEFI (because isolinux isn't used) so the subject is now extremely confusing; I suspect that there has simply never been support for defaulting UbuntuKylin to zh_CN on UEFI
<ypwong> cjwatson, that might be the case..
<seb128> bdmurray_, ev, do you know why https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1380278 doesn't appear on the daily/weekly e.u.c charts
<ubottu> Ubuntu bug 1380278 in unity-settings-daemon (Ubuntu) "unity-settings-daemon crashed with SIGSEGV in _gdk_device_xi2_reset_scroll_valuators()" [Medium,Confirmed]
<seb128> it has enough reports that it should be one of the top reports on those views
<seb128> but it's not on the list
<leszek> hi
<leszek> seems like muon cannot be recompiled from .dsc currently in utopic. It complains about Nepomuk/KRatingPainter not found. Any ideas what I did wrong ?
<arges> caribou: salut. can you add an SRU justification to bug 1309679 ?
<ubottu> bug 1309679 in sosreport (Ubuntu Trusty) "collect /var/log/upstart/ directory" [Undecided,New] https://launchpad.net/bugs/1309679
<arges> caribou: and bug 1355279 and bug 1308232
<ubottu> bug 1355279 in sosreport (Ubuntu Trusty) "sosreport fails on openstack-ceilometer" [Undecided,New] https://launchpad.net/bugs/1355279
<ubottu> bug 1308232 in sosreport (Ubuntu Trusty) "sosreport does not collect rabbitmq config files and logs" [Undecided,New] https://launchpad.net/bugs/1308232
<ypwong> cjwatson, bug 1380981 filed, you're right that the bug also exist in trusty
<ubottu> bug 1380981 in Ubuntu Kylin "In UEFI mode, default langauge in Ubiquity language chooser is not Simplified Chinese" [Medium,New] https://launchpad.net/bugs/1380981
<caribou> arges: done for all 3 of them
<cjwatson> ok, so seriously, how do I get the default Ubuntu desktop working in kvm these days so that I can work on ubiquity bugs?
<cjwatson> "qemu-system-i386 -enable-kvm -monitor stdio -m 1024 -cdrom utopic-desktop-i386.iso -hda t.img", press key, select "Try Ubuntu without installing": ends up at a blank screen with the Ubuntu wallpaper and nothing else
<seb128> cjwatson, what's not working?
<seb128> urg
<arges> caribou: thanks
<cjwatson> makes it impossible to work on the installer
<seb128> is there anything useful in .cache/upstart/gnome-session-Ubuntu.log?
<cjwatson> gnome-session-Unity.log?
<seb128> yeah, sorry
<cjwatson> seb128: http://people.canonical.com/~cjwatson/tmp/qemu-desktop.png
<seb128> what about unity7.log ?
<cjwatson> seb128: http://people.canonical.com/~cjwatson/tmp/qemu-desktop-unity7.png (rest of log repeats the same thing)
<seb128> mlankhorst, ^ is there a known issue with llvm/kvm in utopic?
<seb128> cjwatson, the error is similar to https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1360241
<ubottu> Ubuntu bug 1360241 in llvm-toolchain-3.5 (Ubuntu) "[Regression] "LLVM ERROR: Do not know how to split the result of this operator!" in executing Ubuntu UI Toolkit tests on x86" [Undecided,Confirmed]
<seb128> doko, ^ do you know?
<doko> seb128, cjwatson: I thought mlankhorst fixed that in the emulator/qemu setup?
<seb128> cjwatson, sorry, I guess we need mlankhorst to be around/reply about that
<flexiondotorg> slangasek, You'll remember I reported an issue with Plymouth not displaying the splash logo and also not allowing your pass phrase to be entered when using full disk encryption?
<flexiondotorg> slangasek, The number of reports for the not displaying the splash screen are on the rise and Ubuntu GNOME have add a report regarding pass phrase entry.
<flexiondotorg> slangasek, I "fixed" this in Ubuntu MATE by creating a plymouth package based on 0.8.8.
<flexiondotorg> slangasek, https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/ppa/+sourcepub/4462913/+listing-archive-extra
<Laney> cjwatson: FWIW, I can reproduce your problem with i386 images but amd64 ones boot okay
<flexiondotorg> slangasek, Testing shows that both issues are resolved by rolling back Plymouth to 0.8.8. Not the most elegant fix but it works.
<cjwatson> Laney: hm, I guess that'll do, thanks, will try that
<cjwatson> (will take a while to rsync)
<Laney> It's a bit unsatisfying, but might be helpful in the absence of m_lankhorst
<cjwatson> it'll certainly unblock me if I see the same here
<Bluefoxicy> Are there any barriers to packaging the Android SDK in Ubuntu Universe or Multiverse?
<Bluefoxicy> in particular, it would be nice to load a Cyanogenmod environment, onto which I could load Amazon Store or some such
<Bluefoxicy> the PC audible app is garbage
<Bluefoxicy> a range of software suddenly opens up when you have an emulated table, I guess.  idk.
<doko> rbasak, any progress on python-greenlet?
<doko> pitti, proposed-migration (gdb) thinks that the apport autopkg test is still in progress
<rbasak> doko: still working on it (right now).
<rbasak> doko: I have patches that fix it. Writing up for upstream. It's complicated :-/
<rbasak> "fix" it.
<doko> ta
<rbasak> The code makes too many assumptions about what the compiler will do.
<pitti> doko, jibel: hmm, britney thinks "apport 2.14.7-0ubuntu5: Test in progress", but utopic has ubuntu6
<pitti> jibel: some confusion in the state files?
<zbenjamin> sergiusens: ping, is this bug still valid? https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1257689
<ubottu> Ubuntu bug 1257689 in qtcreator-plugin-ubuntu "Confirm that the emulator has enough space" [Medium,Confirmed]
<zbenjamin> sergiusens: is there already a check for enough disk space?
<sergiusens> zbenjamin: I guess it is still valid, and no, no check
<jibel> pitti, looking
<zbenjamin> sergiusens: ok thx
<sergiusens> zbenjamin: just like click chroot has no check
<smoser> anyone know where italics in 'less' matching came from ? and how i can put it back ?
<smoser> ie, 'man ls'. then  i hit '/' then type 'all'.
<smoser> on some systems, that highlights 'all' which i can actually see. on others it uses italics, which i cannot ever actually find on the screen without really looking (which is why i used 'find').
<cjwatson> Sounds like a property of the terminal emulator rather than of less
<cjwatson> Or are you actually sure less is being used?
<cjwatson> Hit 'h' and see if you get "SUMMARY OF LESS COMMANDS"
<smoser> cjwatson, pretty sure less is being used. or if not, then it very well mimics the behavior of 'less <filehere>' .
<smoser> ie, remove 'man' from above and just use less and i see the same behavior.
<cjwatson> OK, I don't think less in itself is even able to force italics; it just sends certain terminal capability sequences
<cjwatson> Up to the terminal emulator to decide how to render them
<rbasak> Any byobu or tmux or screen involved here?
<cjwatson> It might depend on $TERM
<arges> is unity crashing repeatly for anybody else... i've been in a conference and its done it about 5 times already
<arges> [10170.860174] unity-settings-[12658]: segfault at 8 ip 00007f43a4ea23a4 sp 00007fff7ccbed88 error 4 in libgdk-3.s
<arges> o.0.1200.2[7f43a4e5e000+af000]
<arges> [10171.863510] compiz[12710]: segfault at 0 ip           (null) sp 00007fff3697aeb8 error 14 in compiz[400000+3000
<arges> ]
<pitti> arges: yeah, me too
<pitti> arges: just discussed in #u-desktop, larsu has a fix for it
<arges> pitti: oh awesome! whats the bug #?
<pitti> arges: lp:~larsu/unity-settings-daemon/lp1380278 fixes it; if you use amd64, I can also toss you some debs
<arges> pitti: that would be very helpful. trying ot also pay attention to presentations: )
<pitti> arges: the compiz bug is bug 1366351, but that's only fallout from unity-settings-daemon crashing
<ubottu> bug 1366351 in compiz (Ubuntu) "compiz crashed with SIGSEGV in g_closure_invoke()" [High,Triaged] https://launchpad.net/bugs/1366351
<pitti> arges: http://people.canonical.com/~pitti/tmp/usd/
<arges> pitti: thanks
<pitti> arges: works wonders here; before that compiz crashed about once a minute
<arges> pitti: i'll test on my laptop too
<pitti> arges: and like you it started crashing on LinuxCon for me; apparently in a dock with differnet input devices it doesn't
<arges> i just noticed it today after I did my daily dist-upgrade
<shadeslayer> btw this is FindPython from utopic : http://paste.ubuntu.com/8559404/
<shadeslayer> which doesn't seem to have 3.4 in there
<shadeslayer> is that intended?
<shadeslayer> because it breaks a thing for me
<shadeslayer> https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1323559 seems to be right bug
<ubottu> Ubuntu bug 1323559 in cmake (Ubuntu) "cmake doesn't find python3-dev library" [Undecided,Confirmed]
<smoser> rbasak, TERM=screen
<smoser> humm.. but fun, that is inside tmux. (via byobu).
<smoser> but, performs the same just by doing: TERM=screen less /etc/passwd
<cjwatson> even then, depends on the terminal program; for instance gnome-terminal shows italics but pterm doesn't
<bdmurray_> seb128: the retracers have quite a backlog so it may be due to that.
<seb128> bdmurray, how much backlog and do we know why?
<bdmurray> seb128: hundreds of thousands for i386 and amd64. Partially because we were accepting core dumps from things we didn't need to, also because apport-retrace is slower than it used to be, and because we haven't received any more retracers.
<bdmurray> seb128: we are actively removing things from the queue that we can't retrace and things we shouldn't try to
<seb128> bdmurray, do we know how much backlog do we have?
<seb128> does it mean at this point e.u.c doesn't provide us an useful view of the utopic status because the backlog is such that we have no data about what is current?
<seb128> I wish those issues were communicated on ubuntu-devel@
<seb128> it's a major problem for the distro and our ability to target work
<seb128> slangasek, ev, ^ not sure who would be the right list/group of person to have a discussion about that?
<ev> seb128: hm? We're entirely blocked on the IS GSA team for this. It's #14 in the queue, but the items before it are rather important as well: https://portal.admin.canonical.com/ruins?team=gsa
<ev> adding more retracers, that is
<seb128> ev, "hm?" about what part?
<seb128> ev, well, the current e.u.c view doesn't reflect our current issues, it means we are misleaded on what we focus on
<seb128> that seems like something that should be publicly announced so we don't have more teams misguided
<seb128> ev, like we noticed some recent importants issues through lp reports and IRC mentions, they should be on top of e.u.c but there are totally missing because the retracer backlog is such that e.u.c didn't get to retrace anything recent
<bdmurray> we could declare "inbox bankruptcy" but that seemed rather extreme to me
<ev> so non-binary crashes will always be up to date
<ev> bdmurray: we may be at that point, to be honest
<seb128> well, most of our issues are binary ones
<seb128> like u-s-d segfault and compiz as well there
<bdmurray> ev: okay, one thing to keep in mind is that we asked for 14489 coredumps on the 12th (a weekend) and I think the queues will quickly get out of hand again
<ev> yeah, I'm pushing on IS at the same time
<Riddell> pitti: is there a tech board meeting now?
<LocutusOfBorg1> debfx, hi can I push some changes into collab-maint/cmake?
<LocutusOfBorg1> bump std-version, fix lintian copyright issues
<LocutusOfBorg1> maybe fix man errors and try to fix the missing icon
<bdmurray> ev: okay, I'll talk to thedac about clearing the queues
<ev> bdmurray, seb128: I've got the ticket bumped further up
<debfx> LocutusOfBorg1: please open bugs or send git patch mails
<seb128> ev, thanks, do we have any eta on when we are going to catch up on recent issues retracing? release is next week
<ev> seb128: bdmurray is getting the queues cleared, so as soon as that happens
<bdmurray> ev: do you know of a graphite graph that indicates quantity of crashes retraced per day?
<seb128> great
<seb128> ev, bdmurray! thanks
<ev> it will start to fall behind, but hopefully we'll get the scalingstack retracers deployed quickly
<ev> bdmurray: not saved, but the data points should be there
<LocutusOfBorg1> ok debfx will send mail
<shadeslayer> anyone want a patch for bug 1323559 ?
<ubottu> bug 1323559 in cmake (Ubuntu) "cmake doesn't find python3-dev library" [Undecided,Confirmed] https://launchpad.net/bugs/1323559
<debfx> LocutusOfBorg1: though the missing icon issue is easily dealt by getting rid of the menu file
<shadeslayer> My CMake fu isn't good enough tbh
<debfx> shadeslayer: is the patch linked from the bug not working?
<shadeslayer> did not realize there was a patch in there
<shadeslayer> yep looks right
<debfx> although hardcoding python versions makes me wanna scream ;)
<shadeslayer> debfx: :D
<LocutusOfBorg1> debfx, there is almost nothing to fix, I noticed after starting look at the code lol :(
<LocutusOfBorg1> nothing for sure worth an upload
<shadeslayer> debfx: http://paste.ubuntu.com/8559776/
<debfx> LocutusOfBorg1: that sounds like a good thing
<debfx> shadeslayer: I don't think my uploading powers are strong enough for cmake
<slangasek> kees, mdeslaur: looks like we're down half a board for today's meeting; do we want to still meet or should we punt?
<LocutusOfBorg1> shadeslayer, what do we have here?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1357270
<ubottu> Ubuntu bug 1357270 in cmake (Ubuntu) "Merge cmake 2.8.12.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed]
<mdeslaur> slangasek: I don't mind still meeting...I believe some folks are waiting on the io scheduler sru to be discussed
<LocutusOfBorg1> oh yes the python fix cherry-picked from debian
<LocutusOfBorg1> unfortunately it comes too late :(
<slangasek> mdeslaur: ok
<shadeslayer> Riddell: ^^
<slangasek> mdeslaur: are you current wrt the thread on ubuntu-release?
<mdeslaur> I've followed it, but I'll reread it again now
<shadeslayer> LocutusOfBorg1: I reckon one patch is easier to get in than a merge a week before release
<LocutusOfBorg1> shadeslayer, fully agree
<LocutusOfBorg1> the sad thing is that I reported the merge on august
<LocutusOfBorg1>  Reported by LocutusOfBorg on 2014-08-15
<LocutusOfBorg1> rebased a month ago
<LocutusOfBorg1> and rejected by release :)
<LocutusOfBorg1> but not a problem for me, just it's sad that people loose time in merging/rejecting/finding another patch online that actually fixes a problem already fixed in debian and so on
<LocutusOfBorg1> but this is open source ;)
<shadeslayer> I can understand
<shadeslayer> LocutusOfBorg1: debfx Riddell I've uploaded a new cmake with the python fix
<Riddell> shadeslayer: the python fix?
<Riddell> I didn't know it was broken
<shadeslayer> now you do :)
<shadeslayer> "Signer is not permitted to upload to the component 'main'."
<shadeslayer> :O
<shadeslayer> I thought cmake was part of the kubuntu pkg set
<Riddell> shadeslayer for core-dev!
<Riddell> yo no se
<LocutusOfBorg1> lol
<shadeslayer> yes, shadeslayer for core ... wait a second
<shadeslayer> Riddell: https://launchpad.net/~rohangarg/+archive/ubuntu/experimental/+files/cmake_2.8.12.2-0ubuntu6.dsc
<shadeslayer> but then you can't approve
<shadeslayer> drat
<shadeslayer> debfx: ^^
<debfx> shadeslayer: I think I have exactly the same upload permissions as you
<shadeslayer> drat
<mdeslaur> kees: techboard meeting?
<Laney> just get Riddell to upload it, the queue is being reviewed in reasonable order
<shadeslayer> Riddell: plz to upload my cmake :D
<shadeslayer> Riddell: https://launchpad.net/~rohangarg/+archive/ubuntu/experimental/+files/cmake_2.8.12.2-0ubuntu6.dsc
<shadeslayer> brb
<Riddell> shadeslayer: hmm that patch hardly solves the problem long term, what happens when 3.5 comes out?
<Riddell> surprising this came from upstream
<Riddell> shadeslayer: uploaded
<smoser> anyone else seeing this:
<smoser>  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1381149
<ubottu> Error: ubuntu bug 1381149 not found
<smoser> fun.
<smoser>  unity-panel-service crashed with SIGSEGV in strrchr()
#ubuntu-devel 2014-10-15
<dholbach> good morning
<LocutusOfBorg1> dholbach, hi, do you think you can sync lucene++
<LocutusOfBorg1> no rdeps, bugfix only, and should fix two ubuntu bugs
<LocutusOfBorg1> there are spurious build failures with the old release, I never had them in debian with the new one, and I remember I might have fixed some packaging bugs, together with sil2100
<dholbach> LocutusOfBorg1, "1285 files changed, 128753 insertions(+), 144491 deletions(-)"
<dholbach> it's a bit hard for me to see what was changed
<dholbach> it'd be good if somebody could take a look and maybe come up with a changelog or something and have a chat with the release team
<sil2100> It's mostly LocutusOfBorg1 great job, since I'm so busy with other stuff that I was not really much of a help...
<dholbach> we're just a week away from release
<sil2100> :<
<dholbach> some files seem to have a lot of whitespace changes in them
<dholbach> but it's a hard for me to find out what exactly changed
<dholbach> maybe you can file a bug about it and explain what changed
<LocutusOfBorg1> mmm there was a rdep, but it has been removed, so actually no programs should use it
<LocutusOfBorg1> but maybe we can sync after utopic release
<LocutusOfBorg1> BTW can you please remove boinc-app-milkyway? the version is too old to be useful
<LocutusOfBorg1> and I cannot upload the new one because of nvidia license
<LocutusOfBorg1> so please let it go :)
<dholbach> can you file a bug about it and subscribe ubuntu-archive?
<dholbach> it'd be good if there's some explanation why it can be dropped
<LocutusOfBorg1> bug 1381384
<ubottu> bug 1381384 in boinc-app-milkyway (Ubuntu) "please remove milkyway from archive [RoM]" [Undecided,New] https://launchpad.net/bugs/1381384
<LocutusOfBorg1> I quoted the debian bug
<dholbach> great, thanks
<LocutusOfBorg1> thanks to you :)
<Saviq> pitti, hey, any idea if -dbgsyms from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-006/+sourcepub/4473892/+listing-archive-extra are available somewhere?
<pitti> Saviq: they should be in http://ddebs.ubuntu.com/ubuntu-rtm/queue/
<Saviq> pitti, indeed, awesome, thanks!
<Saviq> tvoss, this is gaining severity by the minute bug #1380736
<ubottu> bug 1380736 in unity8 (Ubuntu) "Unlocking sim while dash is not loaded leads to a system lockup" [Critical,New] https://launchpad.net/bugs/1380736
<Saviq> tvoss, could you have a look please, dbus-cpp and media-hub involved
<tvoss> Saviq, sure
<Saviq> Wellark even has some suspects there
<Saviq> tvoss, if you need, got the coredump here
<tvoss> Saviq, ack, got it
<Wellark> Saviq: morning!
<Saviq> Wellark, heyo
<tvoss> Saviq, Wellark why is media-hub involved here? did somebody look at dbus traffic?
<tvoss> Saviq, Wellark so this only happens if the wizard has been run?
<Wellark> tvoss: I looked at the stacktrace and the involved libraries
<tvoss> Wellark, sure, that might be misleading here, though
<Wellark> tvoss: I suspect it's qtubuntu-media
<Saviq> tvoss, no, it just happened to me on boot when unlocking the SIM cards
<Wellark> I just slammed media-hub there before I found out about qtubuntu-media
<Wellark> tvoss: but,
<tvoss> Saviq, did we investigate in this direction: https://bugs.launchpad.net/indicator-network/+bug/1380736/comments/4
<ubottu> Ubuntu bug 1380736 in unity8 (Ubuntu) "Unlocking sim while dash is not loaded leads to a system lockup" [Critical,New]
<Saviq> tvoss, unrelated, it just makes it easier to reproduce, probably due to high CPU load by dash
<Saviq> tvoss, for me it happened regardless of what the dash was doing
<Wellark> tvoss: actually there might be two issues.. the errors.u.c. report that mterry posted seems like the one you get when you forget to disconect()
<tvoss> Wellark, did you try removing the audio source in unity8?
<Wellark> but
<Wellark> the one that I posted
<tvoss> Wellark, a crash is somewhat fine, but why would everything hang?
<Wellark> seems like a uncaught exception
<Saviq> tvoss, no no
<Saviq> tvoss, it's a crash
<Wellark> tvoss: it's crashihng unity8
<Wellark> and as apport runs
<Saviq> tvoss, "hang" is just apport collecting the core
<Wellark> it's seems that the system is hanged
<Saviq> which takes up to a minute
<tvoss> Saviq, ah okay
<tvoss> Wellark, did you try making sure that the respective signal is disconnected?
<tvoss> Saviq, is it an abort or a segfault? I would expect a segfault
<Wellark> tvoss: I just looked at the code last night at 3.30am as I didn't have anything better to do
<tvoss> Wellark, ack, I will look at it
<Saviq> tvoss, segv
<Wellark> :)
<tvoss> Saviq, ack, that makes sens
<tvoss> e
<tvoss> Saviq, could it be that the audio source is destroyed/reinitalized somewhere?
<Saviq> tvoss, it definitely is destroyed
<tvoss> Saviq, ack, then that's the likely issue here
<tvoss> let me see
<tvoss> Saviq, cross-check: channel is rtm, correct?
<Saviq> tvoss, it happens when the SIM unlock dialog (ugh.. notification) is being destroyed, and it does have Audio { } in there
<Saviq> tvoss, either
<tvoss> Saviq, ack
<Saviq> tvoss, at least yesterday it was either, this morning I repro'd in rtm yes
<tvoss> Saviq, branching qtubuntu-media and trying a fix
<tvoss> Saviq, Wellark do we have a silo for the bug, yet?
<Saviq> tvoss, no
<tvoss> Saviq, ack, let me request one
<Wellark> tvoss: thanks!
<dholbach> jodh, can you merge my branch then?
<jodh> dholbach: done, thanks.
<dholbach> jodh, package uploaded, should be sitting in the queue now.
<jodh> dholbach: thanks again!
<Saviq> tvoss, on another topic, I've been unable to get a location on my phone for a while now when dogfooding
<tvoss> Saviq, sorry, can we please postpone that until I have this fix mp'd?
<Saviq> tvoss, let me know if you have some time to try and debug why
<Saviq> tvoss, â
<Saviq> s/if/if\/when/
<tvoss> Saviq, ack
<tvoss> Saviq, Wellark https://code.launchpad.net/~thomas-voss/qtubuntu-media/fix-races-for-access-to-destroyed-controls/+merge/238404
<Saviq> tvoss, thanks
<tvoss> Saviq, requesting silo right now
<tvoss> now if only launchpad would show the diff :)
<Laney> can you fix imminently? :-)
<bdrung_work> yes
<Laney> rocking
<dholbach> jodh, Laney, bdrung_work: I commented on the MP
<jodh> dholbach, bdrung_work: if that date is correct, could we also update http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Ubuntu_14.10_.28Utopic_Unicorn.29 to match?
<jodh> bdrung_work: do you want me to change the MP or are you going to jfdi?
<dholbach> jodh, I don't understand
<pitti> stgraber: oh, I just found out why I was getting an EPERM trying to remove /var/cache/lxc/utopic/rootfs-amd64 -- it's a separate btrfs subvolume
<pitti> stgraber: OOI, why is this done?
<jodh> dholbach: sorry, that wikipedia link was meant to link to the 'Table of versions' entry for utopic that currently just shows "2015-07".
<pitti> stgraber: is that more efficient wrt. mounting in the container?
<dholbach> hum
<dholbach> sorry
<dholbach> let me doublecheck
<dholbach> yes, AFAICS this should be correct:
<dholbach> 14.10,Utopic Unicorn,utopic,2014-04-17,2014-10-23,2015-07-23
<dholbach> ^ can somebody doublecheck?
<dholbach> it matches https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule + the usual 9 months of support
<bdrung_work> Laney, dholbach: just uploaded distro-info-data 0.22 to unstable. please sync it once it's there
<Laney> ty
<bdrung_work> and here is the change: http://anonscm.debian.org/cgit/collab-maint/distro-info-data.git/commit/?id=aaad145d76739cfa41c53cf26265fb6bcaa574ee
<dholbach> thanks bdrung_work
<dholbach> LGTM
<jodh> bdrung_work: thanks.
<bdrung_work> you're welcome
<rbasak> doko_: so I have a fix ready to upload for the FTBFS for armhf in your rebuild test. Only I just want to do a final test before uploading and realised that a newer version has been stuck in utopic-proposed all along.
<rbasak> And this version additionally fails on powerpc.
<stgraber> pitti: it's so containers can be created with a simple subvolume snapshot rather than rync the whole thing
<rbasak> Fixing armhf needed hand-examination of the arm assembly output. If powerpc needs to do the same, I'm not capable of doing it quickly as I don't know powerpc assembly.
<rbasak> Can we keep the version the same as in utopic (not utopic-proposed), but with my cherry-picks to fix armhf? Then we'll have something in the archive that doesn't FTBFS on all architectures.
<rbasak> But I think this would need a 0.4.4-1really0.4.2.1ubuntu1 version number of something.
<doko_> rbasak, yep, sound good. did you test your version on porter-powerpc?
<rbasak> No. I can do that. I only touched armhf-specific code.
<rbasak> doko: does 0.4.4-1really0.4.2.1ubuntu1 sound appropriate to you? I don't know what we do about the second hyphen there, so I changed it to a dot.
<doko> I would use as the upstream part: 0.4.4really0.4.2  and then -0ubuntu1
<rbasak> That sounds better - thanks.
<rbasak> Ah - and that way I don't get a confused upstream tarball. My wouldn't work.
<pitti> stgraber: ah, nice
<cjwatson> rbasak: You don't need a really version here
<cjwatson> rbasak: It sounds like we can remove the package from utopic-proposed and then you can go backwards (which is OK since utopic-proposed isn't expected to have widespread apt clients using it)
<cjwatson> rbasak: What package is this?
<rbasak> cjwatson: python-greenlet
<rbasak> I didn't realise that was acceptable. If you're happy to delete from utopic-proposed, then yes please.
<cjwatson> I think it's nicer than a really version, yeah
<rbasak> OK
<rbasak> I'll prepare a 0.4.2-1build1ubuntu1
<rbasak> Or, 0.4.2-1ubuntu1?
<Laney> yes
<rbasak> I guess that's higher.
<cjwatson> The latter
<rbasak> ack
<cjwatson> Presumably any future version of 0.4.4 would need to be patched to include your change, rather than resurrecting 0.4.4
<cjwatson> er resurrecting 0.4.4-1
<rbasak> Yes. My change has already been accepted upstream. The Debian maintainer asked upstream for a new release to incorporate my fixes.
<cjwatson> rbasak: nuked, you can upload
<rbasak> Thank you!
 * rbasak build tests on armhf and powerpc first.
<rbasak> Uploaded.
<rbasak> Oh great. It failed on amd64 :-/
<rbasak> Someone hit the retry button? It succeeds locally.
<rbasak> As in, did someone hit the retry button? I was just about to do it.
<doko> I did
<rbasak> Thanks
<rbasak> I don't understand the failure. I makes no sense to me.
<rbasak> It
<rbasak> greenlet seems to have turned into a bit of a nemesis for me. I refuse to let it defeat me :)
<rbasak> \o/
<ogra_> jodh, just saw your mail ... i think you should talk to stgraber aboout the "writagble-image" options (i dont know what sync actually does, never used it)
<jodh> ogra_: ack, thanks.
<ogra_> (and i guess yu guys can easily talk in person this week ;) )
<stgraber> ogra_: nope, jodh isn't at Plumbers
<stgraber> and I'm rarely online
<ogra_> oh
<sunweaver> dbarth: long time not seen / talked / chatted.
 * sunweaver is Mike Gabriel from upstream X2Go and also now a DD packaging MATE for Debian.
<sunweaver> I plan to bring my work power to the Ubuntu MATE team and need Ubuntu Developers that maybe would like to write an endorsement statement under my application.
<sunweaver> At least you have seen a bit of my work, even if some time ago.
<sunweaver> dbarth: here is the application page anyway: https://wiki.ubuntu.com/MikeGabriel/DeveloperApplication
<sunweaver> dbarth: maybe you find some time and are willing to add a statement...
<sunweaver> THANKS!
<dbarth> sunweaver: o/ will take a look later (deep inside a debug session w/mardy right now)
<sunweaver> dbarth: o/ THANKS!
<doko> tseliot, there are some MIR's missing for your last nvidia-graphics-drivers-304 upload
<tseliot> doko: MIRs?
<doko> tseliot, https://wiki.ubuntu.com/MainInclusionProcess
<doko> for ocl-icd and khronos-opencl-headers
<doko> and bumblebee
<tseliot> doko: I don't recall requesting that
<tseliot> not bumblebee, at least, only bbswitch
<tseliot> also, do you have a relevant bug report?
<doko> tseliot, the nvidia-graphics-drivers-304 and nvidia-graphics-drivers-331 packages do that.
<doko> tseliot, no, *you* are required to file this bug report with the MIR information
<tseliot> let me check the packaging
<tseliot> doko: maybe the problem with  nvidia-graphics-drivers-304 is that nvidia-opencl-icd-304 depends on ocl-icd-libopencl1 | nvidia-libopencl1-304, and ocl-icd-libopencl1 is in universe
<tseliot> it should be the same for nvidia-graphics-drivers-331
<doko> tseliot, ahh, nvidia-331 recommends nvidia-prime (>= 0.5) | bumblebee, which is correct, and the component-mismatch wrong
<tseliot> doko: yep
<tseliot> doko: do you think I should still file a MIR for the opencl stuff, even though it's just an alternative dependency?
<mlankhorst> do you want opencl? :P
<doko> tseliot, why isn't nvidia-libopencl1-304 listed as the first alternative?
<tseliot> doko: they are interchangeable, and it's best to build against the open one (to avoid missing symbols)
<doko> tseliot, well, then I assume we should have it in main?
<tseliot> doko: yes
<doko> tseliot, then please file the MIR issue
<doko> mlankhorst, I don't want it, but if it is required according to tseliot
<tseliot> doko: ok
<tseliot> we'll also need it for fglrx in utopic+1
<smoser> pitti, i think i saw you were having an issue with a unity-settings-daemon crash ? is that right ?
<smoser> i'm pretty much wrecked by it. launchpad seems unresponsive now, or i'd have a link.
<pitti> smoser: yes, it and compiz were crashing every minute or so
<smoser> yeah. :-(
<pitti> smoser: larsu fixed in a branch yesterday; if you are on amd64 you can install the debs from http://people.canonical.com/~pitti/tmp/usd/
<pitti> (that's a straight build from his branch)
<pitti> smoser: since then, not a single crash any more
<stgraber> I just accepted the fix
<pitti> \o/
<stgraber> after having the same crash happen to me a dozen of times today :)
<smoser> am i the only one that can't load launcpad bugs ?
<stgraber> also, I'm a bit disappointed that the apport retracer didn't duplicate my 4-5 bugs to the right ones, took me a while to figure out exactly what was going on :)
<seb128> pitti, smoser: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008
<smoser> seb128, thank you.
<seb128> pitti, better to recommend ^ so we get testers for the version we want to land
<doko> tvoss, asac, cjwatson, please have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and tell me which of the packages in "Source and binary movements to universe" belong to the phablet, and maybe should be seeded
<pitti> seb128: binaries are now also on https://launchpad.net/ubuntu/+source/unity-settings-daemon/14.04.0+14.10.20141014-0ubuntu1
<seb128> oh, upload got accepted
<seb128> nice
<seb128> lol
<pitti> stgraber: oh? I tried to report it and I already got stopped on the client side due to the bug pattern
<seb128> 3 minutes ago
<seb128> pitti is on top of things ;-)
<pitti> seb128: stgraber | I just accepted the fix
<seb128> stgraber, pitti: thanks
<pitti> it's the "ubuflu" for laptops
<pitti> I never had that crash at home
<pitti> and as soon as you walk to a conference your desktop gets effectivley wrecked
<pitti> but yeah, a day with XFCE was illustrative :)
<stgraber> pitti: here it was letting me report it, grabbing the logs and then compiz was being ignored due to supposedly being out of date (my system was updated about 10s before the crash so that seems unlikely) and u-s-d was duped to aonther bug report which wasn't the same used for the u-s-d fix
<seb128> stgraber, pitti: there are some variants of the bt I think, refcont issues leading to slightly different errors
<stgraber> ok
<stgraber> well, I guess someone will have to do some serious bug cleanup for u-s-d and compiz in the next few days to clear up all the related crashes :)
<seb128> lol
<seb128> I think people stopped fighting launchpad noise
<stgraber> pitti: btw, shouldn't we be flipping some kind of flag about now to get crashes to errors.u.c instead of uploaded to LP?
<pitti> stgraber: ah yes, that shold be on the "release checklist"
<stgraber> pitti: also, are you in a session or are we both chatting from opposite side of the lobby or something? :)
<pitti> stgraber: I'll upload apport, then the release team can accept at their convenience
<stgraber> ok, thanks
<pitti> stgraber: I'm in room 2, for some comfy hacking
<pitti> basically, last chance to get something done for 14.10 and also jessie
<stgraber> yeah, I guess infinity and I will go through the checklist on Friday and upload everything before we leave DÃ¼sseldorf
<smoser> joy. i seem to be in a routing black hole to bugs.launchpad.net
<mlankhorst> doko: sure, if we need it then no choice :P
<pitti> stgraber: apport uploaded for disabling LP crash reports
<stgraber> thanks
<doko> barry, you did it again ... system-image now pulling in pip via nose2 this time ...
<barry> doko: i uploaded nose2 over a month ago.  why is that suddenly happening?
<doko> barry, it has (or got) a build dependency on tox
<barry> yeah, but there's been no new nose2 in a long time
<doko> wine and cheese get better with aging, not software
<infinity> barry: I can't quite sort out why it seems to have popped up on reports today, but it was a known problem for months, wasn't it?
<barry> infinity: first i've heard of it
<infinity> barry: Err, and no one uploaded nose2 "over a month ago", unless you count "over a year ago" as that.
<barry> infinity: oops, yeah i misread the year in the changelog ;)
<infinity> Ahh, and that's what confused the reports.  It was copied to main a month or so ago, then demoted to universe, which makes the reports say slightly different things.
<barry> infinity: it's not an explicit dependency (i.e. not in d/control) but it must be getting pulled in via requires/setup
<infinity> barry: Anyhow, this is absolutely not the first you've heard of it, we had a discussion, at length, about system-image pulling in pip/venv.  I remember, I was there.
<barry> infinity: that was a different issue.  system-image had an explicit b-d on tox, which i fixed
<infinity> barry: Ahh, but it now has an implicit one via nose2 having an explicit one. :)
<barry> infinity: vice versa :)  it has an explicit b-d on nose2 which apparently has an implicit b-d on tox (it's not explicit in the d/control of nose2)
<barry> there's a new nose2 on pypi, which i can look at, although they conveniently forgot to update their changelog :(  however, as i mentioned before, i still think it's a losing battle to keep tox out of main.  but whatever, we can just keep whacking the moles one by one
<barry> infinity: so when's the archive reorg gonna land? :)
<infinity> barry: Not before release.
<barry> infinity: c'mon dude, you have at least 12h before final freeze, how much time do you need?
 * barry will shut up now
<infinity> barry: Erm, implicit build-depends?  How would that work?
<barry> infinity: actually, yeah, that makes no sense.  let me investigate anyway
<infinity> python-tox,
 * barry was thinking implicit Depends
<infinity> It's right there.
<infinity> In d/control
<barry> ah shit, your right.  i was looking at a different repo
<barry> well, let me see if i can get rid of that
 * barry curses udd
<mvo> *grumpf* bug #1381570
<ubottu> bug 1381570 in util-linux (Ubuntu) "libuuid1 uses chsh in postinst which breaks upgrades" [Critical,In progress] https://launchpad.net/bugs/1381570
<ogra_> lol, what ?
<barry> infinity, doko nose2_0.4.7-2ubuntu1
<infinity> barry: So, the build-dep wasn't actually necessary?
<barry> infinity: no
<barry> infinity: tests were never run at build time anyway
<barry> :/
<infinity> barry: Unfortunate, but at least not a regression.
<mvo> ogra_: upgrade explodes in spectacular ways if libuuid has a login shell, I'm fixing it now
<infinity> barry: Could the tests be turned into dep-8 tests, which don't have to have pocket consistency?
<barry> infinity: probably, but as i've said before, as tox becomes more prevalent, this will increase the pressure to delta from debian over time.  this is a band-aid but not a long-term solution.
 * mvo chuckles at version number 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu13
<infinity> barry: Well, the same "run them as dep-8 instead of build-time" solution is perfectly reasonable for Debian too.
<infinity> barry: But perhaps we can revisit the pip/venv-in-main situation, just not this week.
<barry> infinity: right, but because debian doesn't have the same restriction, if a dd uploads a package that runs tox tests at build time, we will have to delta it if it's a main package.  i don't think we can reasonably tell debian devs not to do that because ubuntu.
<bdmurray> seb128: the error tracker retracing queues were reset yesterday
<barry> infinity: oh fer sher.  let's do talk about it for vain vulture
<infinity> barry: vindictive velociraptor.
<barry> infinity: anyway, please review, but i think in this case mole is whacked
<barry> infinity: much better :)
<barry> vulgar vole?
<infinity> barry: Nothing to review, really.  The delta is obvious (and it already built).
<barry> coolio
<infinity> So, we'll see how this settles down component-mismatches once it publishes and migrates.
<barry> infinity: one other thing to think about... later.  that c-m email notification is not super helpful.  it doesn't mention the packages affected afaict
<infinity> barry: The email is literally just the diff between the previous run and the current, it does no analysis.
<infinity> barry: The svg is often the simplest analysis tool.
<infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<barry> yeah.
<rbasak> barry: +1. The email doesn't tell me if I need to act, or if someone else will take care of it. Without investigating each individual email. So I look at the SVG like infinity says. But at that point, the email is just a notification to look at the SVG, and most of the time it doesn't affect me.
<barry> rbasak: and the email doesn't even include a link to the svg, so unless you already know where to look, it still isn't helpful ;)
<infinity> pitti: Is that util-linux upload the same change that was made in Debian for that bug?
<infinity> pitti: I feel like there was more to it, but I haven't been watching closely.  We might actually want to try a merge and see how scary it is.
<infinity> mvo: Oh, the above to pitti was meant to be for you.
<mvo> infinity: yeah, the initial patch was too simple, I upload the debian version of it now
<infinity> hallyn: I intend to approve this slof MIR, can we get a qemu upload where qemu-system-ppc recommends or depends on qemu-slof instead of suggesting it?
<jamespage> mterry, thanks for the MIR reviews....
<mterry> jamespage, yw!  :)
<doko> jamespage, just saw https://launchpad.net/ubuntu/+source/tuskar/0.4.2-2
<jamespage> doko, oh
<jamespage> doko, yeah more openstack sprawl
<jamespage> I'll look
<jamespage> doko, oh zigo epoched novaclient
 * jamespage goes to see why
<Laney> seb128: did you hear from mlankhorst about the i386 vm/llvm issue?
<zigo> jamespage: Ghe Rivero added the first 1: when the version went from 2.6.7 to 2012, which IMO wasn't needed, then we moved to 2: when it went back to 2.x scheme ...
<mlankhorst> Laney: should be fixed I think :P we set a more sane cpu in the autopkgtest now
<seb128> Laney, no
<jamespage> zigo, yeah that was quite a while ago now
<zigo> Yup.
<seb128> Laney, seems you get his attention though ;Ã¨)
<Laney> mlankhorst: not that
<seb128> ;-)
<jamespage> zigo, I'll tweak tuskar for ubuntu versions; we'll talk about epoch alignment next cycle
<infinity> mlankhorst: How does "setting a more sane CPU" make it not a bug anymore?
<infinity> mlankhorst: Not all i386 machines are as new as the one you're now emulating.
<zigo> jamespage: So you need to fix tuskar's depends when importing it because of that epoc?
<zigo> jamespage: FYI, I'm planning on removing Tuskar from Jessie when it gets frozen.
<Laney> The current problem is that booting an i386 vm (with "qemu-system-i386 -enable-kvm -monitor stdio -m 1024 -cdrom utopic-desktop-i386.iso", for example) fails to bring up unity7 and logs have the same 'cannot split operator' message.
<jamespage> zigo, oh - not good then?
<zigo> jamespage: As well as all TripleO stuff, Designate and probably more.
<jamespage> I might just request it removed
<zigo> jamespage: I don't think it's production ready, and I'm sure I wont get upstream support for long enough.
<zigo> jamespage: Yeah, just ask it to get removed.
<zigo> jamespage: Oh, and Ironic too ...
<zigo> jamespage: But that's stuff from Icehouse.
<jamespage> zigo, I have an ironic maintainer
<jamespage> (thanks adam_g)
<zigo> jamespage: The stuff from Icehouse are not production ready (no driver in Nova Icehouse anyway...), though Juno should be good enough.
<jamespage> zigo, yeah - this was for juno
<zigo> jamespage: For Juno, it's only in Experimental, you know that, right?
<jamespage> zigo, oh yes
<zigo> jamespage: You got to get the latest openstack-pkg-tools where I did some fixes to support better systemd & upstart. I generate these now ...
<zigo> (as well as the sysv-rc scripts btw...)
<jamespage> doko, bug 1381601
<ubottu> bug 1381601 in tuskar (Ubuntu) "Please remove tuskar from utopic" [Undecided,New] https://launchpad.net/bugs/1381601
<jamespage> zigo, next cycle :-)
<jamespage> zigo, systemd configs will def be an objective - might be a good opporunity to re-align Debian/Ubuntu a bit
<zigo> jamespage: What I did is *very* basic for systemd. Basically, I just took the init script dependency, and dumped it in the .service file, and then I call "systemd-start" from the init script in the .service file.
<doko> jamespage, it's only in -proposed
<zigo> jamespage: I'd like to do things a way better ...
<zigo> jamespage: It'd be a good idea IMO, if we could work that out together.
<jamespage> doko, does that make a difference? right now its cluttering the proposed break list imho
<Laney> mlankhorst: indeed it boots fully if I pass -cpu core2duo
<infinity> Laney: Right, which means the bug isn't fixed, IMO.  That's a workaround.
<infinity> mlankhorst: ^
<Laney> Yes
<doko> jamespage, removed
<jamespage> doko, thanks!
<doko> bdmurray, any idea about the whoopsie ftbfs?
<doko> jpds, strongswan ping
<jpds> doko: Yep, I've had test builds running this afternoon.
<infinity> Laney: Oh, unless it's a qemu bug.  When you boot without a -cpu, it might be reporting the wrong caps for what it's emulating. :/
<bdmurray> doko: yeah, there are some test failures (due to https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/revision/633) I'm trying to sort out (without much luck)
<jamespage> mvo, I'd quite like to get that cloud-archive:juno fix into software-properties in trusty asap - are you planning any updates or shall I SRU away
<jamespage> ?
<mvo> jamespage: just SRU, I have no plans right now
<jamespage> mvo, ack
<hallyn> infinity: yup, I can push that.  after the partay i suppose
<hallyn> infinity: thanks, that'll cut down on a lot of (frustrating for the user) bug reports :)
<tych0> hi, does anyone know what package gives me /usr/bin/write?
<mlankhorst> infinity: yeah but I have no idea what the fuck the real fix has to be
<tych0> apt-file doesn't shed any light
<rbasak> doko: jpds has a fix for strongswan that I'm happy to sponsor, but it involves the same as we did for python-greenlet - ditch the version in utopic-proposed, and a packaging bump to the version in utopic to fix the FTBFS from the rebuild test.
<rbasak> Is this acceptable
<rbasak> ?
<rbasak> (this would be 5.1.2-0ubuntu3)
<rbasak>  strongswan | 5.1.2-0ubuntu2   | utopic           | source, all
<rbasak>  strongswan | 5.1.3-0ubuntu1   | utopic-proposed  | source, all
<rbasak> He's already prepared 5.2.0 for V, but it looks too invasive for Utopic IMHO.
<rbasak> So I think it's unlikely we'll want 5.1.3-0ubuntu1, which FTBFS on arm64 and ppc64el anyway.
<doko> rbasak, sure, sounds fine
<doko> apw, could you have a look at the keyutils ftbfs, and if that might be a kernel issue on the buildds? I think these are still running precise
<geomyidae_> If checkinstall misses some files (I don't know/understand how) then do I have any recourse to still use checkinstall, or do I have to go the full packaging route?
<geomyidae_> Can someone point me to how ubuntu pkgs are built by the build server? For example, the args passed to ./configure, make, the process for building the DEB etc?
<geomyidae_> Surely this is automated
<cjwatson> geomyidae_: of course, it's controlled from debian/rules in each package
<cjwatson> geomyidae_: the build servers use dpkg-buildpackage to do the work
<cjwatson> by the way, "deb" is not an acronym and should not be capitalised
<geomyidae_> cjwatson: cool. those are probably the keywords I need to get going. Also, didn't know that, will keep in mind. :) Cheers.
<cjwatson> I'm afraid I don't know anything about checkinstall though
<Saviq> sergiusens, hey, could ciborium not notify on almost every boot about a SD card that's permanently in there?
<sergiusens> Saviq: I can remove that for on start or you can do what ogra_ did and disable notifiations from system settings
<sergiusens> Saviq: to be fair, users aren't expected to reboot every 5 minutes and I guess that's where you are getting annoyed
<sergiusens> Saviq: there's a design review next week (finally), so I rather wait to see what happens there if you don't mind
<Saviq> sergiusens, right, point taken
<Saviq> sergiusens, it wasn't a "fix it now!" comment ;)
<sergiusens> Saviq: I know, but it annoys me too, and then I recall I'm not acting as a user :-)
<sage__> Is the 14.10 release candidate ready for download yet?
<cjwatson> sage__: wouldn't expect that for another 36 hours or more
#ubuntu-devel 2014-10-16
<geomyidae_> What initiates the build process though? Like, for mono, there are dozens of individual debs created. Is there a master manifest that instructs for what packages to build?
<tarpman> geomyidae_: http://en.wikipedia.org/wiki/Debian_build_toolchain
<geomyidae_> tarpman: now that looks like what I've been after
<pitti> infinity: I didn't actually upload util-linux, hang on; but yes, hte previous times I merged, which is generally preferable
<pitti> infinity: oh ok, I read on now, seems all settled?
<pitti> infinity: but some of the other debian fixes look worthwhile as well; not sure if we still want to squeeze them into utopic, though
<pitti> (mostly for lack of time to merge and test, not because they look scary)
<dholbach> good morning
<doko> pitti, real issue? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-apport/lastBuild/?
<pitti> doko: nope, apport-kde test flakiness; retried
<doko> pitti: binutils amd64 too please
<pitti> whoa, the world just exploded -- a gazillion adt failures
<pitti> jibel: did you just update teh adt jobs? "adt--amd64-cloud.img" -- that looks wrong
<pitti> this caused the failure flood
<jibel> pitti, no, phone phone phone at the moment
<jibel> pitti, â« distro-info --devel
<jibel> ubuntu-distro-info: Distribution data outdated.
<cjwatson> upgrade to the distro-info-data in utopic
<cjwatson> the dates were corrected
<jibel> pitti, for distro info the release of utopic is today
<cjwatson> jibel: ^-
<jibel> was
<pitti> ah, so that's it -- I thought we would explicitly set the release?
<cjwatson> we should anyway, otherwise the jobs will fail again on release day
<pitti> well no, I don't want to use distro-info at all -- we know that the job is for utopic, we sohuldn't rely on it to assume that we want to run it in the current devel series
<cjwatson> Yeah
<pitti> RELEASE=$(distro-info -d || distro-info -s)
<pitti> oh, seems we just need to fix that in the local config
<pitti> jibel: so ./jenkins/run-autopkgtest is supposed to get called with $RELEASE set -- where does that call distro-info?
<dholbach> a new distro-info-data was uploaded to Debian yesterday IIRC
<dholbach> maybe we still need to sync it?
<dholbach> ah no, it's synced already, 0.22
<pitti> jibel: and the jenkins job has export RELEASE=utopic
<pitti> so I don't understand how distro-info is related here
<jibel> pitti, I'll check, I'm pretty sure we fixed that last release
<pitti> or why it only affects amd64, but not i386
<Laney> dholbach: maybe SRU though
<dholbach> hum, did we do SRUs of it before?
<jibel> pitti, which job failed on amd64 but not i386? apport failed no i386 but not amd64
<Laney> yes, see https://launchpad.net/ubuntu/+source/distro-info-data/0.8ubuntu0.6
<pitti> jibel: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-vtk6/ for example
<pitti> jibel: apport just was a race
<seb128> bdmurray, slangasek, https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1381804/comments/5
<ubottu> Ubuntu bug 1381804 in glib2.0 (Ubuntu) "whoopsie test failure since glib2.0 2.41.2-1 uploaded" [High,New]
<pitti> $ WORKSPACE=`pwd`/workspace ARCH=amd64 RELEASE=utopic PACKAGE=libpng auto-package-testing/jenkins/run-autopkgtest
<jibel> pitti, no apport failed for the same reason
<jibel> pitti, qemu-img: /run/shm/adt--i386-cloud.img.overlay-1413448420.0155885: Could not open '/home/auto-package-testing/cache/disks/adt--i386-cloud.img': Could not open '/home/auto-package-testing/cache/disks/adt--i386-cloud.img': No such file or directory: No such file or directory
<pitti> jibel: ^ if I run that it succeeds
<pitti> jibel: yes, so $RELEASE isn't set; but the jenkins XML config does set it, and it's also in the console log
<jibel> pitti, it should be fine now, only alderamin was affected.
<pitti> jibel: oh, what changed/did you change? I just ran this on alderamin
<pitti> jibel: ok, I'll go through and retry the failures
<jibel> pitti, RELEASE=$(distro-info -d||distro-info -s) in /home/auto-package-testing/.adtrc
<pitti> jibel: oh, I see
<pitti> jibel: cheers!
<pitti> what a trap
<jibel> pitti, actually this line coud be removed completely since RELEASE is defined in the env
<jibel> but .adtrc override it
<pitti> jibel: yeah, this is probably a leftover from the time when devs were still running that locally
<pitti> but in the CI lab we always want to explicitly specify the release, arch, etc.
<pitti> jibel: anyway, thanks for your help! sorry for the distraction
<jibel> pitti, a leftover or the machine has been restored with a not really up-to-date backup.
<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 -> trusty | #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> cjwatson: I'd like to upload jpds' fix for strongswan in the same manner as python-greenlet yesterday. 5.1.2-0ubuntu3 to replace 5.1.2-0ubuntu2 in utopic to fix rebuild FTBFS, but bypassing 5.1.3-0ubuntu1 in utopic-proposed which introduces a new FTBFS.
<rbasak> If this is acceptable, please could you remove 5.1.3-0ubuntu1 from utopic-proposed?
<cjwatson> rbasak: is this a fix cherry-picked from 5.1.3-0ubuntu1, or a further thing?
<rbasak> I'm pretty sure it's cherry-picked, but let me check.
<rbasak> (it's just an additional build dep)
<cjwatson> rbasak: ok
<cjwatson> jpds: heads-up that the above is happening
<rbasak> -  gperf, libcap-dev [linux-any], dh-autoreconf
<rbasak> +  gperf, libcap-dev [linux-any], libgcrypt20-dev | libgcrypt11-dev, dh-autoreconf
<rbasak> That's all
<cjwatson> rbasak: it's gone
<rbasak> 5.1.3-0ubuntu1 has libgcrypt11-dev. So it's not quite exactly the same. I'm not sure why, but both seem acceptable to me.
<rbasak> Thanks!
<cjwatson> Check the linkage of the rest of its dependency chain, I guess.
<cjwatson> Probably a good idea to avoid both libgcrypt versions being linked into the one process.
<rbasak> rmadison says libgcrypt20-dev is in main, but check-mir seems to disagree
<cjwatson> Believe rmadison
<cjwatson> Anyway, I don't care what's in main vs. universe for this, it's the dependency chain of that package that matters
<cjwatson> Since both libgcrypt{11,20}-dev are in main
<rbasak> So I did a grep across all the generated binary Depends and Recommends lines
<rbasak> I only see libgcrypt20 there
<rbasak> Does that sufficiently check what you're after?
<rbasak> strongswan-plugin-gcrypt was built in Trusty against libgcrypt11. This changes it to libgcrypt20.
<rbasak> That's the only change to the binary deps AFAICS.
<cjwatson> rbasak: Check for libgnutls too
<cjwatson> If libgnutls26 is there, that pulls in libgcrypt11
<cjwatson> rbasak: Anyway, sounds reasonable to try building it against libgcrypt20
<cjwatson> Assuming it actually works :)
<rbasak> No mention of gnutls in the dependencies at all, so we're good. Thanks, I'll upload.
<doko> apw, ogasawara: could you have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381973 and see if this can be fixed in the precise kernel?
<ubottu> Ubuntu bug 1381973 in keyutils (Ubuntu) "keyutils ftbfs on the buildds with the 12.04 LTS kernel" [High,Confirmed]
<Laney> ev: I'm already preparing to upload whoopsie, no need to do that
<Laney> just wanted to test build on armhf
<rbasak> barry: if you have time, please could you take a look at bug 1381564? Needs a version bump. Looks like we could do it in Debian and sync over if we're quick.
<ubottu> bug 1381564 in pyparsing (Ubuntu) "pyparsing ParseResults.pop() fails with NameError: global name 'index' is not defined" [Medium,Triaged] https://launchpad.net/bugs/1381564
<rbasak> (I can't upload)
<rbasak> http://sourceforge.net/p/pyparsing/code/commit_browser lists changes between 2.0.2 and 2.0.3 (Javascript required)
<rbasak> Looks like they're all suitable bugfixes.
<rbasak> And the test suite is updated, etc.
<apw> doko, where can i see the FTBFS log
<doko> apw, ohh, not anymore :-/  just upload the 1.5.9-5 to a non-virtualized ppa
<doko> apw, ahh, wait, build logs are here: https://launchpad.net/ubuntu/+source/keyutils/1.5.9-5
<infinity> doko: Worth noting that those didn't *all* fail because of the precise kernel. :/
<infinity> doko: ppc64el was trusty.
<infinity> doko: And so was powerpc.
<doko> infinity, the build succeeded on the powerpc porter boxes
<infinity> doko: Curious...
<apw> bah ... it thinks we've released
<apw> pull-lp-source: Warning: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
<infinity> apw: dist-upgrade, already fixed.
<apw> ta
<infinity> doko: I wonder what's responsible for making /proc/keys exist.
<infinity> doko: If it's on a porter but not a buildd, this may not be a kernel issue.
<infinity> Oh.
<apw> signed kernel perhaps ?
<infinity> No, it just was fixed in 3.13.0-35 (which is what the porter is running), and the buildd was 3.13.0-33
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1344405
<ubottu> Ubuntu bug 1344405 in linux (Ubuntu Utopic) "Kernel missing /proc/keys" [Undecided,Fix released]
<apw> heh, well that was easy
<infinity> apw: Well, that fixed trusty.  Would still be nice to have it in precise too.
<infinity> Assuming CONFIG_KEYS_DEBUG_PROC_KEYS was a thing on 3.2
<infinity> I suspect it was, cause I think this testsuite passes on Debian's 3.2-based buildds.
<apw> infinity, it is a thing back there, and is not on
<apw> debian.master/config/config.common.ubuntu:# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
<apw> i guess i'll open that bug again against precise
<infinity> apw: Yeahp, would be nice to flip it on.  Ta.
<infinity> I have some pretty low opinions of userspace things unconditionally assuming esoteric kernel config options, but this seems like one that a few bits look for now.
<infinity> doko: Thanks for the porter/buildd disparity hint.  Made the real issue pop right out. :)
<sarnold_> .. and it does seem like the reason for keyutils to exist :)
<doko> infinity, cjwatson: gptsync and refit are removed in unstable. superseded by refind. will try to fix the ftbfs for refit
<doko> seb128, Laney: ping on the ido ftbfs ... http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
<dholbach> happyaron, are you taking care of bug 1374949?
<ubottu> bug 1374949 in libkkc (Ubuntu) "FFe: Sync libkkc/ibus-kkc from Debian unstable (main)" [Undecided,Fix committed] https://launchpad.net/bugs/1374949
<bluesabre> good morning dholbach, and thanks for the uploads :)
<dholbach> bluesabre, anytime
<dholbach> *kkc: ok nevermind, looks like they're already synced
<LocutusOfBorg1> dholbach, it is having some troubles, seems that two developers synced it at the same time
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/libkkc/0.3.4-1
<LocutusOfBorg1> look
<dholbach> hum
<dholbach> I'm not sure what that means
<LocutusOfBorg1> discussed in #-release
<LocutusOfBorg1> <cjwatson> Who accepted libkkc an hour or two ago?  It would be slightly helpful to know exactly how you did it
<LocutusOfBorg1> <cjwatson> (Since we ended up with two sets of simultaneous builds for it, which isn't supposed to be able to happen)
<doko> tedg, please could you have a look at https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1382020 ?
<ubottu> Ubuntu bug 1382020 in ido (Ubuntu) "ido ftbfs in utopic" [High,Confirmed]
<ev> Laney: cheers
<happyaron> dholbach: yes I'm on it
<mitya57> dholbach, hi, if you are piloting, can you please look at my metacity MP?
<barry> rbasak: looking!
<tedg> doko, Sure
<barry> rbasak: https://bugs.launchpad.net/ubuntu/+source/pyparsing/+bug/1381564/comments/4
<ubottu> Ubuntu bug 1381564 in pyparsing (Ubuntu) "pyparsing ParseResults.pop() fails with NameError: global name 'index' is not defined" [Medium,Fix released]
<doko> tedg, thanks! are you going to upload?
<rbasak> barry: thank you!
<rbasak> barry: are we actually in final freeze yet?
<barry> rbasak: yw!
<barry> rbasak: according to the topic in #u-release, not yet
<doko> barry, then time to fix bzr ;)
<barry> doko: ah
<doko> barry lacks a bit of enthusiasm ;-P
<barry> doko: yeah, sadly.  if there was a patch already, maybe. but gosh, i have nfc about those failures and i haven't hacked in bzr in a long while.  not sure i could even get a fix for that before ff
 * barry wonders if there are any bzr hackers left
<pitti> mvo: just FYI, I'm looking into the systemd failed test which currently holds back your new util-linux
<mvo> pitti: thanks
<infinity> xnox: Around?
<infinity> pitti: Thanks, that systemd test failure looks pretty bizarrely broken.
<tedg> doko, Another bug popped up after that one with lcov. Going to make sure Jenkins is happy.
<pitti> infinity: yeah, not sure what changed there recently; after rebooting with systemd-sysv, autopkgtest's helper init.d script fails to start
<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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mitya57> dholbach: thanks a lot!
<dholbach> anytime
<pitti> infinity: oh crap, I suck; I found the problem; that'll require another autopkgtest upload into utopic
<pitti> infinity: not to solve it on CI (we use the git checkout for that), but to fix broken local adt VMs
<infinity> pitti: Upload away. :)
<pitti> infinity: I just missed dinstall, so the usual debian -> sync route will mean I can sync tomorrow morning; is that enough?
<pitti> infinity: otherwise I can upload a fake sync to utopic
<infinity> pitti: Nah, tomorrow is fine.
<pitti> *nod*
<doko> barry, please don't close bugs which are not yet fixed (pyparsing)
<bdmurray> seb128: I saw - thanks for getting someone to look at it.
<seb128> bdmurray, hey, yw!
<doko> seb128, ping on https://bugs.launchpad.net/ubuntu/+source/unity-scope-manpages/+bug/1382011  or can you suggest some responsible person/team?
<ubottu> Ubuntu bug 1382011 in unity-scope-manpages (Ubuntu) "unity-scope-manpages ftbfs in utopic" [High,Confirmed]
<seb128> doko, try asking thostr
<doko> ok
<rcrit> I'm new to Ubuntu, mostly working on *cough* Fedora in the past. I'm seeing some different behavior of openssl than what I saw in Fedora, related to system certificates
<rcrit> for example, this is failing to validate the certs for me: openssl s_client -host www.google.com -port 443
<rcrit> the same on Fedora results in a validated connection
<rcrit> I'd like to be able to use a common, shared set of CA certificates. I see a bunch in /etc/ssl/certs but they don't seem to be used automatically
<sarnold_> rcrit: you have to specify the certs you want to trust: openssl s_client -CApath /etc/ssl/certs/ -host www.google.com -port 443
<rcrit> shouldn't that be the default?
<rcrit> well, maybe I"ll open a bug and pursue it there, thanks.
<rcrit> hmm, curl gets this right.
<rbasak> Most stuff does use it IME. I think it's just s_client that doesn't.
<rbasak> (I'm sure there are exceptions though, and in principle I agree with fixing those)
<slangasek> seb128: thanks!  glad it was a straightforward fix, sorry for having to make you guys look at it for us
<seb128> slangasek, no worry, yw!
<pitti> mvo, infinity: adt VM building fixed, rolled out to CI, systemd succeeds again, util-linux blocked; I'll sync autopkgtest 3.6 tomorrow morning
<seb128> bdmurray, pitti, Saviq: I hit some unity8-dash segfaults on the phone but apport fails to collect a dump, so no retrace/gdb possible, is that a known issue? do you have any clue why that might be the case?
<pitti> seb128: what does /var/log/apport.log say?
<pitti> (might not have enough memory for the core dump)
<seb128> pitti, http://paste.ubuntu.com/8574366/
<pitti> seb128: hm, so that doesn't say anything
<pitti> seb128: ah, it doesn't log if the core dump gets too large
<seb128> pitti, what's the limit, is it easy to tweak?
<pitti> seb128: 3/4 of available RAM size (otherwise you'd easily run into OOM)
<pitti> seb128: but might be ok for merely uploading it
<seb128> shrug
<seb128> unity-dash using 637M?!
<seb128> pitti, thanks
<pitti> yeah :(
<pitti> seb128: ask jibel how much fun he has with the OOM killer due to unity taking so much RAM
<pitti> seb128: you can try: /usr/lib/python3/dist-packages/problem_report.py, line 373; change it to
<pitti>                         if False and size > limit:
<pitti> (or delete the entire if)
<pitti> seb128: or, what's probably better: edit /usr/share/apport/apport line 339; that specifies the limit as usable_ram() * 3 / 4
<seb128> pitti, going to try that, danke
<seb128> Saviq, that ^ means we actually get unity-dash segfault issues not showing on e.u.c
<tseliot> doko: I've just filed the two MIRs, as requested: LP: #1382091 and LP: #1382086
<ubottu> Launchpad bug 1382091 in khronos-opencl-headers (Ubuntu) "[MIR] Main inclusion request for khronos-opencl-headers" [High,Triaged] https://launchpad.net/bugs/1382091
<ubottu> Launchpad bug 1382086 in ocl-icd (Ubuntu) "[MIR] Main inclusion request for ocl-icd" [High,Triaged] https://launchpad.net/bugs/1382086
<doko> tseliot, thanks, will try to look at these tomorrow, leaving soonish today
<tseliot> doko: thanks
<doko> tseliot, is a team subscribed to these packages?
<tseliot> doko: yes, ubuntu-mir
<tseliot> doko: wait, to the packages?
<doko> tseliot, yes
<Saviq> seb128, that looks crazy, have you got a lot of music on the phone for example?
<seb128> Saviq, no, I've none
<seb128> no video, no music
<tseliot> doko: the package is synced from debian, so I assume not?
<seb128> Saviq, I just killed it, didn't use the phone, it's using 525M
<Saviq> seb128, what do you use to measure?
<seb128> Saviq, top
<seb128> that might not be right
<Saviq> smemstat -p `pidof unity8-dash`
<seb128> Saviq, bottom line is that apport bails out from collecting the dump, which means no bt/retracing/e.u.c
<doko> tseliot, no, on https://launchpad.net/ubuntu/+source/ocl-icd  "subscribe to ..."
<seb128>  10405     0.0 B    45.0 M    48.9 M    68.9 M phablet    unity8-dash
<seb128> Saviq, ^ hum
<Saviq> seb128, yeah, that's more like it
<Saviq> seb128, and how much free mem you got?
 * Saviq kills dash to see
<doko> tseliot, and here: https://launchpad.net/ubuntu/+source/khronos-opencl-headers
<ogra_> on a freshlyy booted 110 inatsll with G+ and dekko open my dash uses 112M in idle
<tseliot> doko: right, nobody is subscribed
<seb128> Saviq, playing a bit with the click store
<seb128>  10405     0.0 B   117.8 M   122.1 M   143.4 M phablet    unity8-dash
<doko> tseliot, so please subscribe your team you usually use for such things
<seb128> KiB Mem:    983764 total,   752348 used,   231416 free,    20912 buffers
<seb128> Saviq, ^
<Saviq> seb128, that's expected, it doesn't unload all the images
<Saviq> seb128, not straight away, that is
<seb128> k
<seb128> so I don't know if apport measures the memory wrong
<seb128> or if there is some other issues
<seb128> but I got like 5 segfault today, and not had a dump
<Saviq> seb128, it collected fine after SIGABRT here
 * Saviq still got 300MB free
<tseliot> doko: I'll subscribe the ubuntu-x team for now
<seb128> Saviq, let me sig11 it
<Saviq> seb128, huh
<Saviq> seb128, I had a .crash file and whoopsie seems to have deleted it?!
<seb128> Saviq, weird
<seb128> mines are still there
<seb128> they just do 90k and don't include a dump
<Saviq> seb128, right, that does suggest core collection ran out of mem
<mvo> jibel: hi, do we still run precise->trusty->utopic upgrade tests currently? I wonder if bug #1381570 would have been triggered here
<ubottu> bug 1381570 in util-linux (Ubuntu) "libuuid1 uses chsh in postinst which breaks upgrades" [Critical,In progress] https://launchpad.net/bugs/1381570
<jibel> mvo, Hi, no. We are running P->T and T->U but not P->T->U
<Saviq> seb128, but mine seems fine @12M... but HUH, all the crashes seem to go away without being uploaded Â¿?
<seb128> Saviq, well, maybe the way I hammered on the click store earlier to reproduce those segfaults made the number raise a bit, and with some apps running I could have been like unity8 = 170M and not enough free RAM
<Saviq> seb128, yeah, might be, and yeah, we know we need to do better @ mem management
<seb128> Saviq, can't do everything in one cycle, my main concern there was more than if most users hit those cases, then e.u.c doesn't tell us the really story
<mvo> jibel: aha, ok, that explain why this was not found via autotesting, thanks
<GunnarHj> kirkland: ping?
<roadmr> hello folks, the files for utopic netboot are incomplete, after loading pxelinux.0 it complains about some missing .c32 files which I had to go fetch from the syslinux-common package. Would it be reasonable to expect the netboot installer stuff to work out-of-the-box? or is there a document somewhere explaining this procedure?
<goodwill> roadmr: what is utopic?
<roadmr> goodwill: Utopic Unicorn, the development version of Ubuntu, soon to be released as 14.10
<goodwill> ah
<paran> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<bdmurray> paran: where?
<paran> bug #1376966. SRU for ubuntu-drivers-common broke X for me and others.
<ubottu> bug 1376966 in ubuntu-drivers-common (Ubuntu) "gpu-manager treats all files in /etc/modprobe.d as config files" [Undecided,New] https://launchpad.net/bugs/1376966
<paran> Ubuntu wiki said to report SRU regressions here on IRC :-)
<bdmurray> paran: looking, thanks
<paran> bdmurray: very short summary, gpu-manager looks in wrong files with a bad regex, and incorrectly think the nvidia kernel module is blacklisted. I included a patch.
<bdmurray> paran: Yes, I see. Thanks for that.
<bdmurray> paran: I've updated the bug and assigned it to a developer.
<paran> bdmurray: sounds good, thanks.
#ubuntu-devel 2014-10-17
<mwhudson> there must be some way to translate a control file's build-depends line into a command to feed to apt-get?
<mwhudson> actually maybe not
<jtaylor> mk-build-deps -ir
<mwhudson> jtaylor: ah thanks!
<mwhudson> now for my next question
<mwhudson> i have on my laptop some changes that i want to test build on a different machine
<mwhudson> what's the most efficient way to get them onto that machine?
<mwhudson> apt-get source on that machine and then scp a debdiff?
<dholbach> good morning
<pitti> stgraber: related to that, shold we merge criu 1.3.1-1 from sid for utopic, or are we fine with 1.3~rc1 that we have in utopic?
<pitti> infinity: fixed autopkgtest is  waiting in unapproved since this morning; ok to accept this?
<pitti> infinity: (same version that's running in production)
<infinity> pitti: Accept away if you haven't already.
<infinity> pitti: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381968
<ubottu> Ubuntu bug 1381968 in linux (Ubuntu) "Fstrim destroys data on loopback device" [Critical,Confirmed]
<pitti> infinity: opened in tab, will have a look soon; this works differently in utopic (fstrim --all), so hopefully it's not an issue in utopic too
<infinity> pitti: I think it's your dm/md-check-skip feature that's at fault here.
<infinity> pitti: Since that seems to imply that we trim *anything* behind dm/md, which can't be right...?
<pitti> infinity: that was the idea, yes, as we can't run hdparm on a dm device; then if there's something behind it that fstrim can't deal with, fstrim will fail with an error
<pitti> infinity: so for fstrim'ing dm devices we ignore the errors, while on real-iron block devices we do show errors (as we want to know if fstrim fails on devices where it really Should Workâ¢)
<pitti> so apparently fstrim wreaks havoc on loop devices, so we need to explicitly black list them (I haven't looked at the bug in detail yet)
<apw> pitti, i have been attempting to repro that on T and U and so far ... not so much
<apw> pitti, oh i wonder if he has a device behind the loopback that is buggy ...
<infinity> apw: That shouldn't matter, should it?  It's trying to trim the file, not the device?
<infinity> (Or, so I'd assume)
<apw> infinity, i would nope not indeed, then again it works fine for me
<shadeslayer> dholbach: poke, re licensing stuff that was waiting on Canonical Legal, any updates on that
<infinity> apw: I can see, in theory, how trying to trim a sparse file could explode, if you were mistakenly treating it as a real block device.
<pitti> apw: it seems fstrim -v <mount point of my block device> actually does succeed
<dholbach> shadeslayer, I'll send a mail, thanks for the reminder
<shadeslayer> Cheers
<infinity> apw: Were you testing sparse or complete?
<shadeslayer> dholbach: this is going too slowly though :(
<dholbach> shadeslayer, I'm not involved in the discussions and I don't know how complicated they are, so I can't comment
<apw> infinity, i am using the ORs "reproduce it this way" script
<shadeslayer> dholbach: roger
<dholbach> shadeslayer, I'll ask for an update now
<pitti> apw, infinity: so shuld we workaround this in fstrim-all, by either scanning the md to see if there's any loop device behind it and then not trim it? or make fstrim fail on loop devs?
<pitti> I just fstrim'ed a non-sparse 1 GB loop file and that seems to work well, but I guess the issue is only with sparse files
<infinity> pitti: Well, apw can't reproduce with sparse either.
<infinity> pitti: So, I think it would be sane for us to sort out a way to actually reproduce it, so we can hunt down if utopic is also effected, etc.
<infinity> (Or if the problem is local to the submitter's machine, for some reason)
<infinity> pitti: But, yeah, assuming the issue is that fstrim and loop devices don't love each other, refusing it in fstrim itself (not the wrapper) makes more sense.
<pitti> infinity: right, it's just not entirely trivial to determine that; you might have a an LVM where one PV is an MD device out of dm devices built from loop devs, and similarly funny things
<pitti> infinity: if that's a problem, then I think a safer approach would be to stop trimming those "virtual" block devices at all and only trim "direct hardware" block devices like sdXX
<infinity> pitti: I could get behind that solution, too.
<infinity> pitti: But I'd like evidence of what the bug actually *is* first.  The fact that neither you or Andy can reproduce it smells a bit fishy.
<pitti> infinity: yes, of course
<pitti> (NB I'm just here with 1/4 of a brain/attention)
<infinity> Join the club. ;)
<pitti> infinity: I already destroyed my fs once this week, I'd rather do the second try at home when I have my backup USB right next to me :)
<infinity> Not to fear, though, what's left of our brains will be killed off tonight.
<infinity> mvo: Pokity poke poke.
<infinity> mvo: Someone whose name I won't invoke publicly because he's on vacation mentioned that LP: #1381986 might be an apt-cdrom bug fixed in sid.  Do you know more?
<ubottu> Launchpad bug 1381986 in debian-installer (Ubuntu) "base-installer: error: exiting on error base-installer/kernel/no-kernels-found in utopic server installs from 20141011" [Critical,Confirmed] https://launchpad.net/bugs/1381986
<mvo> infinity: right, let me upload the, I'm very sorry for this
<infinity> mvo: Bugs happen, but a quick fix would be nice. :)
<mvo> infinity: already uploaded
<infinity> mvo: My hero.
<dpm> hi cjwatson, I'm told you're the person to ask for this: would it be possible to sync myspell-ca from utopic to the rtm archive? I've got an MP to add a Catalan keyboard + predictive text + spellcheck, which depends on myspell-ca, but it's only available in the ubuntu archives
<roaksoax> /wi/win 3
<doko> pitti, autodep8 MIR missing (pulled in by autopkgtest)
<stgraber> pitti: I think we need 1.3.1 to get things working, so if we care about having the feature in utopic, then a merge would be nice
<stgraber> tych0: ^
* infinity changed the topic of #ubuntu-devel to: 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tych0> stgraber: yes, 1.3.1 is the latest tagged release. whatever we do, we shouldn't include 1.3 :)
<tych0> pitti: a merge would be much appreciated :)
<israel> Hi, I have a question about pkexec.  I am building from a minimal base, how do I force pkexec to use a graphical dialog?
<pitti> doko: ah, needs a MIR; I'll file one
<pitti> doko: bug 1382524
<ubottu> bug 1382524 in autodep8 (Ubuntu) "[MIR] autodep8" [Undecided,New] https://launchpad.net/bugs/1382524
<pitti> stgraber, tych0: I can probably squeeze it in somehow, but as this doesn't really fall into any final freeze category I'd rather have the release team's +1 first
<pitti> or we make infinity do it as he introduced the first delta :)
<rbasak> Somebody probably needs to look at bug 1377813.
<ubottu> bug 1377813 in tzdata (Ubuntu Trusty) "tzdata SRU to 2014f because of law changes in Russia" [Critical,Confirmed] https://launchpad.net/bugs/1377813
<rbasak> Oh
<rbasak> Somebody is.
<rbasak> Never mind.
<pitti> rbasak: socket activation! *cough*
<Jon> greetings all. I'm trying to fix a bug in sssd in trusty; but I can't find where the source is kept. LP seems to be out of date; and trusty tags/branches aren't in the Debian VCS. Anyone any idea what's actually being used?
<rbasak> Jon: https://launchpad.net/ubuntu/+source/sssd
<rbasak> Jon: click on one of the versions there, and you can see the source downloads.
<rbasak> Generally we use a tools "rmadison" and "pull-lp-source" for CLI equivalents of that.
<rbasak> Jon: we appreciate all help in fixing bugs in Ubuntu. But note that a fix can't land in Trusty sssd without having been fixed in Utopic first (or now, Utopic+1 probably)
<rbasak> Jon: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure has the steps you will need to follow once you have a fix ready.
<rbasak> pitti: good point!
<pitti> rbasak: I meant wrt. your bug reply of having to find out the right dependencies in advance
<rbasak> pitti: yeah I get it. I didn't think of socket activation as a way to solve this problem.
<Jon> rbasak: thanks - so if I understand right, they've basically given up on using VCS for changes to sssd in trusty since 1.5.8-0ubuntu3 / 2011?
<Jon> rbasak: re fix in utopic; my priority is to fix the bug for me in trusty, I'll at least report and file a diff, but I may not take it further myself (don't have any utopic systems anyway so I'd have to do quite a lot of work to fix it there)
<rbasak> Jon: we never really used VCS for changes to sssd in the first place. What you see there is the importer importing into VCS for convenience, and that broke in 2011.
<Jon> aah I see. mild-boggle but at least I understand now!
<rbasak> (it's always been somewhat fundamentally broken; there are plenty of other packages that are also stuck like that)
<rbasak> Jon: OK. We can't make you do anything, but if we fix it in Trusty but not in the development release, then users get a regression on upgrade, which is why we don't do it.
<rbasak> Jon: if it helps, VMs and LXC are useful here, to test and reproduce on development releases. You probably want to have a reproducible test case anyway.
<Jon> rbasak: oh no I totally understand why the process is that way; it's just I'm looking at this on salary
<rbasak> Jon: sure, I understand. You still have a case for fixing the development release on salary though; not doing so time-limits your fix. You'll need to upgrade eventually.
<Jon> nod, there is that
<rbasak> And it's easier to deploy and manage if you are running a version published in the archive. Otherwrise you have to maintain your patched version.
<rbasak> And sssd is in main in Trusty, so you get the benefit of Canonical's security team looking at the version in the archive for free, too, as opposed to your patched version.
<rbasak> I'm just trying to give you some reasons for your manager :-P
<Jon> btw which ubuntu version is the move-to-systemd one? (this bug is upstart-specific)
<sarnold_> afaik not yet set in stone
<Jon> sure
<sarnold_> one hopes it'll be in two releases before an LTS release, but we might only get one..
<Jon> sigh at some point I need to vote on the Debian systemd GR stuff... great fun
<stgraber> pitti: +1
<stgraber> pitti: if I don't do the work, I've got no conflict of interest in using my release team hat to +1 this :)
<pitti> stgraber: for merging? I'll have a look in the train
<pitti> stgraber: I haven't touched criu at all, but I was planning to look at it as it sounds awesome
<pitti> stgraber: so I can test it while I'm at it
<stgraber> yeah, and IIRC the current one is just completely broken, so it fits the "can't possibly be worse" category
<pitti> oh, is that so
<pitti> stgraber: thanks for the warning, so I won't scratch my head wondering if I did something wrong :)
<pitti> on that note --- infinity: https://launchpad.net/ubuntu/+source/criu/1.3~rc1-1ubuntu1 -- qoui ?
<pitti> infinity: that was to fix the FTBFS, right? or something else?
<infinity> pitti: Yeah.
<infinity> pitti: It was passing GCC arguments to ld.
<infinity> pitti: ie: -Wl,--foo instead of --foo
<infinity> pitti: My gross hack was the quickest path to sanity, cause fixing the upstream mess wasn't a high priority the day I uploaded that. :P
<infinity> pitti: Obviously, the right answer is to convert the upstream makefiles to link with gcc instead of ld.
<dholbach> happyaron, can you accept Jonas/Jack in the LP team of Ubuntu China User team? thanks
<happyaron> dholbach: that's done already, 
<dholbach> happyaron, excellent!
<happyaron> :)
<bdmurray> mvo__: will you have a look at bug 1380774?
<ubottu> bug 1380774 in apt (Ubuntu Utopic) "debian-installer does not find kernel" [Critical,Triaged] https://launchpad.net/bugs/1380774
<mvo__> bdmurray: is this still reproducable with apt 1.0.9.2ubuntu2 - I *hope* this upload fixes it
<mvo__> (I'm actually pretty sure, but you never know)
<bdmurray> mvo__: ah, I'd missed there was a new upload
<mvo__> bdmurray: I uploaded it some hours ago, I think the bug referes to the 1.0.9.2ubuntu1 version but please let me know if I'm wrong
<pfsmorigo> is there a way to avoid using ipv6 during ubuntu installation? It seems that aptinstall prefers ipv6 and the installation fails because I don't have ipv6 here.
<bdmurray> mvo__: will do, thanks
<pfsmorigo> using daily image from oct 10 for ppc64el
<pitti> infinity: I'm asking as the current debian sid version builds just fine, and also has the b-dep fix
<pitti> IOW, we can sync criu if we need it
<pitti> stgraber: however, I tested the current utopic version and it's far from "completely broken"; it works more or less like advertised
<pitti> stgraber: but I tested plain "criu dump"/"criu restore", not with lxc
<pitti> stgraber: "sudo lxc-checkpoint -v -n systemd-tests -D /tmp/checkpoint" indeed fails, but with both versions (and no helpful output)
<pitti> other than maybe "lxc_container: lxccontainer.c: criu_ok: 3671 lxc.tty must be 0"
<pitti> stgraber: so, the final version works just as well as utopic's for a simple "yes" process, and lxc-checkpoint is broken with either; so I did a sync request which will get us rid of the delta and to the final versoin
<pitti> stgraber: so accept/reject as you see fit :)
<pitti> stgraber: oh, err, auto-accepted; not seeded, no reverse depends and such :) shouldn't lxc at least suggests: it?
<smoser> ok. i have a file /var/crash/_usr_lib_unity_unity-panel-service.1000.crash
<smoser> unity-panel-service is in a crash loop
<smoser> segfaulting
<smoser> given that i have .upload and .uploaded, does that mean those got uploaded ? and is there a bug
<SpamapS> doko: FYI, I'm working on an SRU for python3.4 in trusty
<SpamapS> doko: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1382607
<ubottu> Ubuntu bug 1382607 in python3.4 (Ubuntu Trusty) "[SRU] Backport python3.4 logging module backward incompatibility fix." [High,In progress]
<smoser> ok. so going further on the above unity crash.
<smoser> why doesn't this work:
<doko> SpamapS, ok, but I hope I'll get my 3.4.2 backport approved next week
<smoser>  sudo apport-cli /tmp/_usr_lib_unity_unity-panel-service.1000.crash
<SpamapS> doko: OH
<smoser> i hit 'S' (send report) and it immediately exits.
<SpamapS> doko: but is that to trusty-backports ?
<doko> no, -updates =)
<SpamapS> doko: or trusty-updates ?
<SpamapS> ohh sweeet lets just do that
<doko> SpamapS, are you at the sprint?
<SpamapS> doko: what sprint?
<SpamapS> I am a ghost
 * smoser misses SpamapS too
<doko> SpamapS, if you want to test, see the ubuntu-toolchain-r/ppa PPA. survived a trusty main rebuild
<SpamapS> doko: is there a trusty bug report I can point to?
<SpamapS> smoser: I miss you all very mcuh. :)
<doko> 1348954
<doko> a bit empty
<SpamapS> mcuh being the algonquien word for "some"
<SpamapS> doko: thats fine, just want people to be able to track it.
<SpamapS> doko: ah I didn't see that bug because it isn't linked to trusty series. :-P
<SpamapS> doko: well anyway, I'll leave you be. :)
#ubuntu-devel 2014-10-18
<inder_> Hello ubuntu developers
<inder_> I want to contribute in ubuntu
<inder_> I have a knowledge of c,c++ and python language
<monkeymooski> Is there a resource online that shows the architecture of Ubuntu?
#ubuntu-devel 2014-10-19
<sage__> Does anyone know if 14.10 will use systemd by default?
<rekby> Hello. I want notify about large changes of timezones in Russia. It applies in tzdata 2014f, but ubuntu have tzdata 2014e (previous version).
<rekby> Changes will apply 26.10.2014 (in few days).
<rekby> http://mm.icann.org/pipermail/tz-announce/2014-August/000023.html
<rww> A newer version was uploaded to proposed yesterday.
<rww> lp bug 1377813
<ubottu> Launchpad bug 1377813 in tzdata (Ubuntu Trusty) "tzdata SRU to 2014f because of law changes in Russia" [Critical,Confirmed] https://launchpad.net/bugs/1377813
<rekby> Ok. thanks. I have tried update tzdata few minutes ago and tzdata was old. How many days take publishing fixed package to repositories usually?
<rww> I don't know what Ubuntu's migration delay for proposed is, but I expect that since it's marked critical it won't be too long. (i.e., will be before the 26th)
<infinity> rww: The delay is "as soon as I test it and promote it", there's no automated machinery that does migration for stable releases.
<rww> ah, thanks. I'm too used to Debian ;)
<infinity> rww: Does Debian automate stable releases?  They sure didn't used to.
<rww> s/Debian/Debian testing/. Just ignore me. And thanks for the info :)
<darkxst> xnox, will you be releasing another slideshow package before release? bug 1376452
<ubottu> bug 1376452 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Ubuntu-GNOME slideshow artwork" [Undecided,Confirmed] https://launchpad.net/bugs/1376452
<hjd> When a package is removed from Debian (for instance https://tracker.debian.org/pkg/libjogl-java https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757837) will it be removed from Ubuntu in the next development release, or will it stay until someone requests its removal? (Just curious)
<ubottu> Debian bug 757837 in ftp.debian.org "RM: libjogl-java -- ROM; Superseded by libjogl2-java" [Normal,Open]
<geser> hjd: it's a semi-automatic process, once in a while an archive admin "imports" those removals from Debian
<geser> unless it has an Ubuntu delta in which case someone has to investigate if the delta is needed in the new package and file a removal request for the old package
<hjd> geser: Ok. Thanks :)
#ubuntu-devel 2015-10-12
<pitti> Good morning
<pitti> rbasak: it actually was removed recently: https://launchpad.net/ubuntu/+source/python-unit/+changelog
<pitti> rbasak: so I suppose it needs to be rewritten to use the standard unittest instead?
<dholbach> good morning
<seb128> diwic, TheMuso, can we get the patch mentioned on https://bugs.launchpad.net/fedora/+source/pulseaudio/+bug/1425447 uploaded to wily?
<ubottu> Launchpad bug 1425447 in pulseaudio (Ubuntu) "pulseaudio crashed with SIGABRT in core_free() at login" [High,Confirmed]
<seb128> diwic, I appreciate it might not fix the issue but it might fix some problems and is better than nothing
<TheMuso> seb128: Will take a look first thing tomorrow.
<seb128> TheMuso, thanks
<diwic> TheMuso, ok, thanks, let me know tomorrow if you have any problems with it
<seb128> diwic, TheMuso, thanks
<seb128> hum
<seb128> gvfs doesn't migrate because of
<seb128> autopkgtest for nemo 2.6.7-1: amd64: Pass, armhf: Regression
<seb128> but http://autopkgtest.ubuntu.com/packages/n/nemo/wily/armhf/ is green
<seb128> Laney, thanks
<seb128> (he retried it)
<Laney> secret backchannels
<Laney> he crossed my palm with silver
<seb128> ssssush
<pitti> seb128: argh, that again; fixing
<seb128> pitti, https://errors.ubuntu.com/problem/7f52b91a3a4b716e9d8f59ad80d8681e8479870a seems like it started with your fix to bug #1476010
<ubottu> bug 1476010 in nfs-utils (Ubuntu) "package nfs-common 1:1.2.8-9ubuntu8.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [High,Fix released] https://launchpad.net/bugs/1476010
<seb128> or maybe the fix didn't work
<seb128> the errors just have ubuntu10 records
<seb128> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1504897 is a launchpad report
<ubottu> Launchpad bug 1504897 in nfs-utils (Ubuntu) "package nfs-common 1:1.2.8-9ubuntu10 failed to install/upgrade: Ð¿Ð¾Ð´Ð¿ÑÐ¾ÑÐµÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ ÑÑÐµÐ½Ð°ÑÐ¸Ð¹ post-installation Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ¸Ð» ÐºÐ¾Ð´ Ð¾ÑÐ¸Ð±ÐºÐ¸ 100" [Undecided,New]
<pitti> seb128: that's indeed weird -- we got LP reports for earlier versions (which triggered this bug report in the first place), how come that errors has no single instance of it?
<seb128> unsure :-/
<pitti> (yeah, was a rhetorical question)
<rbasak> pitti: ah, I missed that. Thanks. I'll look into it
<rbasak> .
<seb128> pitti, right, I know, just e.u.c is suboptimal sometimes (like for those reports it also doesn't include useful logs)
<doko> query pitti
<doko> pitti, http://autopkgtest.ubuntu.com/packages/s/s3ql/wily/ppc64el/
<doko> triggered by python-setuptools, but not run?
<doko> same for lava-dispatcher? http://autopkgtest.ubuntu.com/packages/l/lava-dispatcher/wily/amd64/
<pitti> doko: ack, fixing
<pitti> doko: python-pex got broken by either new wheel or by newer python-pex, so I figure I'll force-skiptest for setuptools
<pitti> same for python3.5
<doko> yes, I assume it's wheel. python-setuptools is bug fixing only. yeah for upper version dependencies
<rbasak> pitti: uploaded fixed nut, hopefully. It's interesting to note that now that Python 2 isn't installed by default on Wily cloud images, my test run also broke for that. I had to explicitly add Python 2 as a test dependency.
<rbasak> We're probably going to see many more of these.
<pitti> rbasak: ah, thanks
<dupondje_> stgraber: there? Just notice your https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588 bug
<ubottu> Launchpad bug 1501588 in wpa (Ubuntu) "Wily's wpasupplicant frequently fails on WPA enterprise networks" [Undecided,New]
<dupondje_> seems like I hit the same problem here
<dupondje_> found anything more?
<rbasak> slangasek: FYI, deleting python3.4 3.4.3-1ubuntu1~14.04.1 from trusty-updates caused some knock-on effects regressing Docker images in bug 1505164. It seems to me that uploading a higher reverted version might have avoided that, though I don't know that it wouldn't cause other issues from the rebuild.
<ubottu> bug 1505164 in docker.io (Ubuntu) "Ubuntu Docker images include packages deleted from trusty-updates" [High,In progress] https://launchpad.net/bugs/1505164
<seb128> tyhicks, hey, I noticed there was some discussions on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566 ... do you know what's the status?
<ubottu> Debian bug 786566 in schroot "schroot: Should mark bind mounts in the schroot as private" [Important,Open]
<Odd_Bloke> doko: Regarding https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1500768, Cory Benfield (lukasa on IRC) has just commented on the bug, and let me know that he'd be happy to help with any requests-y/urllib3-y problems that we hit in future.
<ubottu> Launchpad bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged]
<ricotz> doko, hi, fyi https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/5491942/+listing-archive-extra
<stgraber> dupondje_: no, I've been traveling and so couldn't do much more tests since I only have a wpa enterprise network at home
<stgraber> dupondje_: I tried downgrading wpasupplicant and then a whole bunch of different kernels and even a different linux-firmware, without any luck, I'm sure I missed something but won't be able to try again for another couple of weeks :(
<ben___> is it possible to pass arguments to a configure script when building a package via debuild?
<cjwatson> ben___: configure arguments are controlled by debian/rules
<cjwatson> ben___: may be implicit if it's using the short dh rules style, which is usual these days, but there's an example of adding to the default configure arguments in "man dh"
<ben___> cjwatson: thanks
<doko> ricotz, why do you ping *me*?
<doko> tdaitx, do you still plan to update squid3 to the current subminor version release?
<ricotz> doko, sorry, you already merged/updated it in the past so you are likely familiar with it a bit
<doko> mehh, won't replace mvo as apt maintainer ...
<Laney> but then you get to be a deity
<tdaitx> doko, yes, the debdiff is @ https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1502178
<ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New]
<barry> doko: thanks for the urllib3 fix in trusty
<slangasek> rbasak: uploading a higher reverted version would also cause problems because the shlibs for libpython3.4 would be wrong; but we'll hopefully have a fix back in trusty-updates shortly
<mvo> doko: wuut? apt? could you give me some context please?
<mvo> doko: if anything needs fixing/merging in apt, please let me know tomorrow and I will have a look
<tyhicks> seb128: I need to make the last set of changes that Raphael pointed out in message #35 and then we should be able to upload the fix to Ubuntu
<tyhicks> seb128: me finding time to do that and give it the needed amount of testing will be difficult
<seb128> tyhicks, ok, thanks for the reply, I guess it's not going to be fixed for 15.10, hopefully somebody can work on it for the lts though
<tyhicks> seb128: I'm confident that I'll have it fixed for the LTS and SRU'ed accordingly
#ubuntu-devel 2015-10-13
<pitti> Good morning
<hades08> im trying to allow this :  apparmor="DENIED" operation="open" profile="lxd_lxc_0.19-1" name="/dev/ppp" pid=5162 comm="lxc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 what anyone could help me ?
<jjohansen> hades08: you would need to add
<jjohansen>   /dev/ppp r,
<jjohansen> to the lxd_lxc_0.19-1 profile
<hades08> to common.conf ??
<hades08> or the usr.bin file in apparmor.d ?
<hades08> none seems to work , i get the apparmor denied when trying to do : "lxc file push /dev/ppp mycontainer/dev/"
<jjohansen> hades08: possibly or one of the files it includes, it seems I don't have one to look at atm
<hades08> my /dev/ppp is in 666 mode too
<jjohansen> hades08: okay, I will need a few minutes to install something to look at
<hades08> oh ! thx :)
<hades08> jjohansen: are you trying it ?
<jjohansen> hades08: my system is updating so I can install the package
<hades08> i ve also tried this : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1474047 for you to know, not working neither
<ubottu> Launchpad bug 1474047 in lxc (Ubuntu) "pppoe fails inside container" [Undecided,Invalid]
<hades08> ^^
<hades08>  mknod /dev/ppp c 108 0 from the container doesnt work
<hades08> lxc.mount.entry = /dev/ppp dev/ppp none bind,optional,create=file do work but the /dev/ppp has 600 chmod and chown is nobody:nogroup and not working
<hades08> in the container
<hades08> i get a /dev/ppp in the container using that method but its not working then. ppp kernel modules i have loaded are: "pppoe" and "pppox"
<hades08> i have added : "/dev/ppp rw," in /etc/apparmor.d/usr.bin.ubuntu-core-launcher and also "lxc.cgroup.devices.allow = c 108:0 rwm" in /apps/lxd/0.19-1/bin/x86_64/lxc/config/common.conf
<hades08> jjohansen: any idea ?
<dholbach> good morning
<sladen> morning dholbach
<dholbach> hi sladen
<ricotz> dholbach, good morning, would you mind taking a look at https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1505146
<ubottu> Launchpad bug 1505146 in plank (Ubuntu) "Sync plank 0.10.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<dholbach> yep, in a bit - need to finish something else first
<ricotz> dholbach, thanks!
<dupondje_> seems like there are major issues with the wpa_supplicant version in Wily and WPA2 Enterprise :(
<Odd_Bloke> diwic: o/ We were talking at LinuxCon about problems I was having with my sound (namely that, on each boot, I have to set the channels for my card in alsamixer before pulseaudio will recognise them); where should I file a bug for this?
<diwic> Odd_Bloke, so it was about 2ch / 6ch mode, right?
<Odd_Bloke> diwic: Yep.
<diwic> Odd_Bloke, for a start, how about running "ubuntu-bug audio" and point me to the resulting bug?
<Odd_Bloke> diwic: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1505584 (Thanks!)
<ubottu> Launchpad bug 1505584 in alsa-driver (Ubuntu) "[Realtek ALC887-VD] Playback only through 2 channels by default" [Undecided,New]
<diwic> Odd_Bloke, so you have added "model=3stack-6ch-dig" ?
<Odd_Bloke> diwic: Hmm, I must have done that at some point when trying to fix it.
<Odd_Bloke> diwic: Let me remove that to see what difference it makes; will I have to reboot for it to be picked up?
<diwic> Odd_Bloke, yes, reboot necessary
<diwic> Odd_Bloke, but anyhow, you have only three jacks in the rear, which are normally used for mic in + line in + line out?
<diwic> Odd_Bloke, i e, not front + read + clfe
<diwic> by default
<Odd_Bloke> diwic: Yep, only three jacks; that assignment sounds likely (though I've never needed/wanted anything other than output).
<diwic> Odd_Bloke, not sure how well that works, with PulseAudio and all. I suggest you retask your jacks a little harder with hda-jack-retask instead
<diwic> Odd_Bloke, I'd say it's not officially supported at least
<cousteau> who do I have to bug for https://bugs.launchpad.net/trusty-backports/+bug/1368094 to be taken care of?
<ubottu> Launchpad bug 1368094 in trusty-backports "Please backport openjdk-8 8u40~b04-2 (universe) from utopic" [Undecided,In progress]
<rbasak> cousteau: only one of these people: https://launchpad.net/~ubuntu-backporters/+members
<rbasak> cousteau: looks like there's a mailing list - ubuntu-backports@lists.ubuntu.com
<cousteau> do they have a channel I can make noise on?
<rbasak> I'm not aware of an IRC channel specifically for backporters. #ubuntu-devel might be a reasonble fallback but I'm not sure all backporters read that channel
<rbasak> openjdk sounds like a pretty major piece of backporting work to meth though!
<cousteau> well, I already commented on the bug report, I see no point on commenting on the mailing list too
<cousteau> I assumed they'd be here too
<cousteau> well, I'd say it's important to do; as I commented in the bug some third party software may use Java 8 (which is the currently supported Java version) so it won't work on Ubuntu LTS unless you install a PPA
<cousteau> the same will happen when Java (and OpenJDK) 9 is released (Sept 2016).  Whoever's "in charge" will have one year until Java 8 is EOL'd (Sept 2017 approx).
<rbasak> Sorry, I didn't mean to imply that it's not useful or valuable, and I appreciate you driving it.
<rbasak> I'm just saying that it sounds like a considerable piece so getting review and upload may be difficult if that review is a considerable amount of work compared to your average backport.
<cousteau> oh... yeah, I didn't understand that :)
<cousteau> I get that doing that is a huge amount of work
<cousteau> that's why I commented that OpenJDK 9 should be started to be backported ASAP; to have as much time as possible for this task to be completed
<cousteau> it's also a higher priority than the average backport, I think
<cousteau> (...well, for now there's the PPA workaround, so it's not a life or death matter, but I think this should be done anyway)
<Odd_Bloke> diwic: hdajackretask seems to have done the trick; thanks!
<sil2100> barry: hey! In-between stuff I'm looking into https://bugs.launchpad.net/ubuntu/+source/python-glance-store/+bug/1505632 if you don't mind
<ubottu> Launchpad bug 1505632 in python-glance-store (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
<gonzzor> Hi, is it possible to use the same debian/{control,rules} files if I want the package to work with upstart in older Ubuntu and systemd in never ubuntu?
<gonzzor> The configure script requires an option to enable upstart script generation and does a pkg-config call for systemd..
<cjwatson> You could make it work with both init systems in both old and new releases.
<cjwatson> Which has been quite standard for some time ...
<gonzzor> So I would install both a .service and a .conf, or?
<cjwatson> Yeah
<cjwatson> And see dh_installinit(1) for maintainer script logic
<gonzzor> Ah, I see. How about Build-Depends for systemd on systems that doesn't have it?
<cjwatson> You can safely build-depend on dh-systemd back to trusty
<gonzzor> Good, trusty is the oldest I need to support..
<cjwatson> Rather than build-depending on systemd itself, though, you should pass --with-systemdsystemunitdir=/lib/systemd/system to configure
<gonzzor> So users of 15.10 would still get the upstart script but it won't be used unless they are actually running upstart instead of systemd..
<cjwatson> (Assuming the package supports such a flag, but it's fairly standard and you could add it if it doesn't)
<cjwatson> Right
<gonzzor> Yes, it does support that flag, and by default calls pkg-config to ask for path if none is given.. Thanks to systemd developers for providing the autoconf snippet :)
<gonzzor> cjwatson: Thanks for the help :)
<cjwatson> np
<cjwatson> gonzzor: If you need an example, binfmt-support is a reasonably simple package of mine that supports several init systems.
<Odd_Bloke> cjwatson: wgrant: smoser: utlemming_sprint: I'm trying to test new UEFI images (currently for amd64, but soon ppc64el and arm64); what's the best way to confirm that an image is bootable?
<cjwatson> Odd_Bloke: A minimal test would be to install ovmf and do something like   qemu-system-x86_64 -enable-kvm -bios /usr/share/qemu/OVMF.fd -m 1024 -cdrom trusty-server-amd64.iso
<cjwatson> Odd_Bloke: UEFI isn't a thing on ppc64el as far as I know, and I don't know exactly what firmware image you'd need on arm64.
<wgrant> arm64 needs wily's qemu-efi
<wgrant> it boots the cloud images fine, just might need overriding to virtio on the qemu commandline
<wgrant> any qemu-efi older than current wily will either hang or not autoboot a cloud image
<wgrant> for booting ppc64el xloud images, the default firmware (SLOF) works fine
<wgrant> (but ppc64el is not UEFI)
<barry> sil2100: cool
<Odd_Bloke> cjwatson: wgrant: Cool, thanks.
<mterry> jdstrand, so in bug 1267393, a bunch of new components got added.  Is the timeframe for that 15.10 or 16.04?  Are you / the security team going to look at the golang packages there?  I can do the non-go ones, like dh-golang if it helps
<ubottu> bug 1267393 in juju-core (Ubuntu) "[MIR] juju-core, juju-mongodb, gccgo, golang" [High,Confirmed] https://launchpad.net/bugs/1267393
<Odd_Bloke> Yeah, don't know why I thought EFI was a thing on ppc64el.
<pitti> slangasek, mvo: I just tried the proposed apt pinning in bug 1503150; I thought it worked for me a few days ago, but not right now
<ubottu> bug 1503150 in autopkgtest (Ubuntu) "Minimize installed packages from -proposed" [Wishlist,In progress] https://launchpad.net/bugs/1503150
<pitti> am I doing anything wrong there?
<mvo> pitti: what kind of error do you get? or what behavior?
<pitti> mvo: the unmet dependencies, what I just wrote in comment #5
<mvo> pitti: aha, sorry for the noise then, I have a look in the bug (in a bit)
<pitti> mvo: thanks; the idea was that with pin prio 100 it would take required deps from -proposed, but take everything that can be resolved in -release from that
<pitti> slangasek, mvo: did another followup (doesn't solve the problem, but explains what worked before)
<tdaitx> doko, I'm not sure if you saw this yesterday: debdiff for squid 3.8.14 is @ https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1502178
<ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New]
<tdaitx> err... s/3.8.14/3.3.14/ =)
<doko> tdaitx, I can't decide this, you have to ask somebody from the ubuntu-release team ... e.g. Laney, slangasek, bdmurray, infinity, ...
<jdstrand> mterry: there is only one that I thinks actually needs a security review-- golang-go.crypto
<jdstrand> the others just need to follow the Debian go packaging
<tdaitx> Laney, slangasek, bdmurray, infinity: I appreciate if any of you could take a look at LP: #1502178 when you have the time =)
<ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New] https://launchpad.net/bugs/1502178
<bev> A question about packaging...I see a few packages which declare that they break every other version of itself, e.g. libstdc++6=4.9.2.10ubuntu13 says Breaks: libstdc++6 (!= 4.9.2-10ubuntu13). What's the reason for doing this, can't there only be one version of the package be installed at the same time anyways?
<mterry> jdstrand, noted, thanks.  Are they trying to get these in for wily?
<jdstrand> mterry: yes
<mterry> jdstrand, humph ok
<jdstrand> lxd too
<cjwatson> bev: Where are you seeing that?  Not in the raw package metadata, I think.
<cjwatson> But maybe in some frontend?
<bev> cjwatson: It was in the output of 'aptitude show libstdc++6'. Your are right, if I download the .deb it's not in the control file
<cjwatson> bev: Right.  That's for Multi-Arch: same packages; it's possible to have those installed for more than one architecture at the same time
<cjwatson> bev: apt generates that Breaks field automatically in such cases to ensure that you have the same version installed across all architectures
<bev> Ah, I see. Thanks!
<cjwatson> (Also an implicit Replaces: ${self}:other (<< ${binary:Version}) )
<cjwatson> bev: More detail is at https://wiki.ubuntu.com/MultiarchSpec
<tsdgeos> seb128: you may as well SRU the whole poppler and not that individual fix :D
<seb128> tsdgeos, would perhaps do if poppler was not breaking abi compatibility between every version ;-)
<tsdgeos> but we don't :)
<seb128> you do on core
<seb128> which things shouldn't use
<tsdgeos> it's the people using the wrong libs ;)
<seb128> but do....
<tsdgeos> complain to them :D
<tsdgeos> i'm just wondering why this fix is more important than the other N we've done
<seb128> tsdgeos, it might not be, but it has a reproducable test case and users who care about it/are probably going to verify the sru
<tsdgeos> honestly that definition apply to 99% of the bugs we fix
<tsdgeos> we seldom fix bugs without reproduceable tests cases
<seb128> we should maybe SRU more poppler fixes
<tsdgeos> but ok, it's just someone complained loudly i guess :D
<seb128> it's just a manpower issue
<seb128> you would argue that fixing nothing is better than fixing some issues?
<seb128> I do agree that fixing all issues would be best
<tsdgeos> no i was just wondering why *this* one
<seb128> we just don't have somebody active enough on the poppler package to do that
<seb128> just because I saw some user comment asking about it
<seb128> and the description states it's hitting people trying to open boarding pass documents
<tsdgeos> at some point if we're serious about the document viewer on the phone i'd say we should make it so we track poppler more closely
<tsdgeos> also on the phone libreoffice and latex would be minor problems
<tsdgeos> or maybe not :D
<seb128> right
<seb128> except that the document viewer is going to use libreoffice
<seb128> but yeah, I'm going to try to be better at backporting poppler updates/fixes in the next lts
<tsdgeos> not blaming you btw
<tsdgeos> i understand this is a manpower issue
<tsdgeos> but seriously nowadays all the API changes are so corner case that a rebuild should just get us good with the new packages
<tsdgeos> not sure a rebuild is acceptable from the point of view of the policy makers
<seb128> probably not easily in SRUs
<stgraber> infinity, pitti, kees, slangasek: I won't be able to make the TB meeting due to having to be at an in-person meeting, sorry.
<pitti> stgraber: ack; should be a near-zero agenda anyway
<seb128> bdmurray, hey, do you know why https://errors.ubuntu.com/problem/ebd96647ac9cf4ab66948f10e1daa1815c85075c states that it doesn't have g-d-u ddebs when they are on http://ddebs.ubuntu.com/pool/main/g/gnome-disk-utility/
<infinity> stgraber: Slacker. :)
<bdmurray> seb128: looking
<seb128> bdmurray, thanks
<seb128> infinity, hey, do you plan to get the current tzdata uploaded for !wily?
<bdmurray> seb128: they aren't on ddebs - the amd64 version of 3.16.2-0ubuntu1 is missing
<seb128> oh, right
<infinity> seb128: I planned to do that a week ago.  Argh.  I brained incorrectly and it slipped off the stack.  Will do now.
<seb128> infinity, thanks
<seb128> bdmurray, thanks, going to do a no change g-d-u upload then
<bdmurray> having said that apport was recently changed to check launchpad for ddebs in this case
<pitti> infinity, kees, slangasek: TB meeting reminder in 7 mins
<bdmurray> mvo: Could you have a look at bug 1505337? It has to do with the auto_flag changes to aptdaemon / update-manager.
<ubottu> bug 1505337 in update-manager (Ubuntu) "update-manager crashed with aptdaemon.errors.AptDaemonError in commit(): org.debian.apt: kinit#auto isn't a valid package name" [Medium,New] https://launchpad.net/bugs/1505337
<infinity> pitti: Ahh, crap, I'm chairing I guess, since stgraber bowed out.  I have to remind myself how to use the bot every time.
<mvo> bdmurray: I have a look, my guess is that u-m may miss a strict version dependency on aptdaemon or that aptdeamon was running, u-m and aptdaemon got updated but the running aptdaemon was not replaced so u-m tried to drive it with the new flags but the old one was still active that did not understood it
<bdmurray> mvo: the version dependency was added so I'd agree with second idea.
<bdmurray> mvo: is there anyway to prove that?
<mvo> bdmurray: reproducing by intalling a non-proposed system, running u-m, update close u-m and quickly open u-m again, aptdaemon has a timeout of some minutes of inactivity iirc of inactivity
<mvo> bdmurray: tricky to fix if the theory is true
 * mvo needs to think about it
<bdmurray> mvo: Does aptdaemon.txt in the bug contain the process id of aptdaemon?
<bdmurray> mvo: Yes, it does and it didn't change between installing u-m and aptdaemon and the failure.
<dobey> anyone know how to make gccgo-4.9 work on vivid?
<mustafam> Hi,
<mustafam> I think this bug is important, it prevents any user with only DSL/PPPoE from connecting, and we approach release:
<mustafam> [21:04] <mustafam> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1446689
<ubottu> Launchpad bug 1446689 in network-manager (Ubuntu) "network-manager configured to use /usr/sbin/pppoe but does not recommend pppoe" [Undecided,Confirmed]
<mustafam> Its solution is a matter of build flag
<mustafam> Or adding a dependency for pppoe
<rbasak> cyphermox: ^
<chiluk> infinity are you around?  would you like to discuss bug 1432871 real quick?  I see you pinged caribou in the backlog while I was on vaca..
<ubottu> bug 1432871 in coreutils (Ubuntu Wily) "`df` shows bind mounts instead of real mounts." [Low,In progress] https://launchpad.net/bugs/1432871
<chiluk> I guess I'll try tomorrow...
<seb128> bdmurray, your software-properties upload seems buggy and the bug you fixed was already handled by the previous upload from today I think
<seb128> bdmurray, well "buggy", it shouldn't create issue but you special case one error, the reports have different variants, like some user use "ppa:/user/name" but some have "ppa::user/name"
<seb128> bdmurray, also please do merge propose your changes against lp:software-properties so they can get reviewed
<bdmurray> seb128: I tested it and the error I was trying to address didn't seem fixed.
<seb128> bdmurray, weird, in any case there is no reason to bypass merge proposal and reviews
<seb128> (the exception should be handled by the previous commit as well, unsure why it didn't work for you)
<bdmurray> seb128: the previous commit will raise an exception, but does it tell you what the proper format is? My thought was a lot of people seem to be making this mistake so the leading forward slash must be in some documentation somewhere and its easy to fix.
<seb128> bdmurray, looking to the reported errors the leading slash is not the only typo, some users have an extra ":" for example, so handling one case only seems a bit random
<bdmurray> seb128: I would have ignored it but there are about 1800 instances of the leading slash. I guess you could find somebody to reject it if you don't like it.
<seb128> bdmurray, I'm going to try it tomorrow, but the previous upload should handle that error as well as other cases of typos and display an error saying that the format is wrong rather than triggering apport
<seb128> unsure why it's not working for you
<seb128> bdmurray, but please next time go through merge proposal and reviews rather than commiting directly to trunk like that
<bdmurray> seb128: I've tested it again and the ubuntu12 works for me but I think it could be much more helpful. "ERROR: 'ppa:/gottcode/gcppa' is not a valid ppa format" doesn't help.
<bdmurray> seb128: Is software-properties special somehow?
<seb128> bdmurray, well, what happens in your version if add "ppa::gottcode/gcppa'?
<seb128> bdmurray, it's an upstream project maintained in launchpad, like apport, update-manager, software-center, etc
<seb128> we usually go through code review for those
<seb128> or what do you mean?
<bdmurray> I mean I've been commiting directly to update-manager and ubuntu-release-upgrader for years now, and didn't realize I should be using merge proposals and reviews.
<seb128> hum, k, I usually mp fixes and try to nag mvo or somebody for review
<seb128> oh well, no big deal
<seb128> your change is fine, I just think it's incomplete but I guess we can fix the other cases with another upload
<seb128> night
#ubuntu-devel 2015-10-14
<pitti> GOod morning
<roaksoax> pitti: howdy!
<roaksoax> pitti: quick question, any ideas? http://pastebin.ubuntu.com/12778124/
<roaksoax> pitti: running vivid's adt in trusty, against a vivid qemu image
<pitti> roaksoax: if "runlevel" says "unknown" this means that the VM hasn't done early boot yet, presumably some service is failing?
<pitti> roaksoax: you can run "--- qemu --show-boot ..." to watch the VM booting, perhaps you see an error there?
<roaksoax> pitti: systemd seems to bring everything up just fine
<roaksoax> pitti: the only thing:
<roaksoax> [    1.037526] systemd[1]: Set hostname to <ubuntu>.
<roaksoax> [    1.185590] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
<pitti> that should be fine
<pitti> roaksoax: so that smells like a bug in autopkgtest then, apparently there's sometimes still stuff going on after login is ready
<roaksoax> pitti: right, so I'll try to create a new image and see what happens
<pitti> roaksoax: if you boot the VM manually in QEMU, log in, and run "runlevel", what exit code and output do you get?
<pitti> roaksoax: i. e. does it ever flip to exit 0/output "2", or stay in "unknown" forever?
<pitti> roaksoax: i. e. does this just need to become a waiting loop, or is something genuinely broken there?
<pitti> roaksoax: err sorry, should go to "5", but any number will do :)
<roaksoax> pitti: i'll give that a try
<roaksoax> pitti: created a new image, and now see this:
<roaksoax> [FAILED] Failed to start Seed the pseudo random number generator on first boot.
<roaksoax> See "systemctl status pollinate.service" for details.
<pitti> roaksoax: ah, so I suppose "systemctl status" is "degraded", not "running"?
<pitti> roaksoax: what does "runlevel" say then?
<roaksoax> sae:
<roaksoax> adt-virt-qemu: DBG: runlevel: exit 1, out "unknown
<roaksoax> ", err "None"
<roaksoax> haven't run it manually yet
<roaksoax> pitti: weird, it works fine with wily with the same error
<dholbach> good morning
<clobrano> good morning all
<pitti> sarnold: do you need any further security info in bug 1488341?
<ubottu> bug 1488341 in libmicrohttpd (Ubuntu) "MIR: libmicrohttpd" [Undecided,New] https://launchpad.net/bugs/1488341
<ginggs> good morning all
<ginggs> doko: i don't think that fpc 3.0.0 rc1 sitting in proposed is ready for production ( https://launchpad.net/ubuntu/+source/fpc ), is it possible to have it removed?
<flexiondotorg> I've just tried an upgrade from 15.04 to 15.10 which fails because Thunderbird in 15.04 is newer than the one on 15.10.
<ricotz> chrisccoulson, ^
 * xnox got removed from all my channels, *sigh*
<seb128> pitti, are ddebs still relying on the old importer script or did we got them in launchpad now? and if we got them in launchpad when did that landed? (doing a bunch of rebuilds for missing ddebs and I wonder if that's the still supposed ot be an issue)
<pitti> seb128: we switched to Launchpad at the start of wily, so we don't need any rebuilds any more
<pitti> seb128: if they are missing on ddebs, we can fish them out of LP
<seb128> oh ok
<seb128> are the retracers doing that
<pitti> seb128: apport also falls back to direct LP download if it's not on ddebs.u.c. these days
<seb128> I was looking at e.g https://errors.ubuntu.com/problem/11fc82b90619044eaa80c8acd806e58b47cace21
<seb128> that started on september 25
<seb128> and it seems to not find the ddebs on launchpad
<seb128> those listed indeed miss amd64 ddebds on ddebs.u.c
<seb128> e.g atk1.0 clutter-1.0 harfbuzz
<pitti> seb128: right, apport's direct LP download fallback was added on Sep 30, i. e. after that
<seb128> pitti, hum, ok, do you know if retracers can be nudged to fix those retraces?
<seb128> or are the new tries going to success and be batched in a different bucket?
<pitti> seb128: new tries ought to succeed now, yes; but I don't know for sure whether they'll become a new bucket
<seb128> pitti, k, thanks
<pitti> I thought once there was a known address signature already it won't actually retrace
<seb128> k
<seb128> pitti, do you know exactly when ddebs started being in launchpad/how to check if one is there?
<seb128> like libsignon-glib was uploaded on 2015-05-13 unsure it needs a rebuild
<pitti> seb128: you see it as normal build output in LP, e. g. https://launchpad.net/ubuntu/+source/atk1.0/2.16.0-2build1/+build/8115852
<pitti> seb128: and the previous atk was already built with ddebs too: https://launchpad.net/ubuntu/+source/atk1.0/2.16.0-2/+build/7428094
<pitti> seb128: not that it even matters for atk1.0 as that has a -dbg and thus the ddebs are empty
<seb128> pitti, https://launchpadlibrarian.net/203832013/buildlog_ubuntu-vivid-amd64.libsignon-glib_1.12%2B15.04.20150420.1-0ubuntu1_BUILDING.txt.gz doesn't
<seb128> so I guess that needs a rebuild?
<pitti> seb128: start of May somewhere, I can't pinpoint it exactly (cjwatson might); but it's easy enough to check on a per-package basis
<pitti> seb128: correct, 20 April was before enabling that
<pitti> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/7343240 has no ddebs
<seb128> pitti, danke
<cjwatson> seb128,pitti: Mysterious lack of logs of exactly when, but it was between 2015-04-30 and 2015-05-05
<cjwatson> (With a brief period earlier when they were enabled but then backed out as we fixed a problem that arose)
<seb128> cjwatson, pitti, k, I think that's enough information to see what needs a rebuild or not, thanks
<cjwatson> seb128: Right, not much was built in the ambiguous period since it was before wily opened.
<sil2100> barry: hey! Once you're around, I would need sponsoring/review for LP: #1505632 and a sync for LP: #1506007
<ubottu> Launchpad bug 1505632 in python-glance-store (Ubuntu) "FTBFS due to failing unit tests" [High,In progress] https://launchpad.net/bugs/1505632
<ubottu> Launchpad bug 1506007 in python-linecache2 (Ubuntu) "Sync 1.0.0-2 from debian testing, fixes FTBFS due to unit tests failing to run" [Undecided,In progress] https://launchpad.net/bugs/1506007
<sil2100> barry: thanks! :)
<doko> didrocks, LP: #1440549 your comment and the "solution" don't make sense.
<ubottu> Launchpad bug 1440549 in gconf (Ubuntu) "please convert python scripts to python3" [High,Fix released] https://launchpad.net/bugs/1440549
<doko> if you want to use python3 use it.
<dobey> doko: hi. do you have any idea how to get gccgo-4.9 to be usable as /usr/bin/go on vivid? gccgo-5 isn't usable because it requires g++5, so all the binary compatibility issues make it untenable on vivid.
<doko> dobey, why? gccgo-5 doesn't depend on g++-5
<dobey> doko: not directly, but it tries to execute it, which fails
<doko> dobey, ahh, you mean when you have embedded c++ code?
<dobey> yes
<doko> that's somehing we probably can't fix. does the go driver allow to call another CXX?
<dobey> i have no idea.
<dobey> doko: btw, re: that python3 bug above, dh-python does rewrite shebangs, but only /usr/bin/python ones, not /usr/bin/env (because that'e executing env, not python), iirc
<barry> sil2100: cool will look
<doko> dobey, could you try setting CXX=g++-4.9 in the env?
<dobey> doko: seems to work, but now i get /usr/bin/ld.gold: error: cannot find -lstdc++
<seb128> doko, what if you want to use "the default python version"?
<doko> seb128, we don't have a "default python version"
<seb128> we should :-)
<doko> we're not ArchLinux ;p
<dobey> seb128: then you want to use python 2.x. it's what the PEP says, and what we do :)
<doko> dobey, -L$(dirname $(g++-4.9 --print-file-name libstdc++.so))
<seb128> then that "env python" and the depends on python are fine?
<doko> what does the PEP have to do with removing python2 from the images?
<dobey> seb128: as long as gconf2 isn't part of the default install, i guess so. otherwise they conflict with the goal of removing python2 from the images
<dobey> doko: nothing with that, but the PEP has to do with /usr/bin/python vs /usr/bin/python3
<doko> right
<didrocks> doko: so, we hardcode /usr/bin/python3?
 * didrocks backlogs
<doko> didrocks, this, or maybe use env python3 if you like
<dobey> didrocks: or /usr/bin/env python3 if you prefer
<doko> violent agreement
<didrocks> ok, I thought that mutliple time, we required to use env instead of anything
<dobey> and change build-deps and any binary deps, to be python3 things
<didrocks> dobey: if you looked at the package, that's already done for long
<didrocks> so only changing to python3, will do in next upload
<dobey> didrocks: then the package is broken since the script runs against things the package doesn't depend on :)
<dobey> but yeah, just change the shebang then
<dobey> doko: so how do i get that -L passed to gccgo? setting LDFLAGS didn't seem to do it
<doko> dobey, hmm, on second thought, just use $(g++-4.9 --print-file-name libstdc++.so), so that other files are taken from the default gcc lib dir
<doko> no idea
<doko>         cppflags = stringList(envList("CGO_CPPFLAGS", ""), p.CgoCPPFLAGS)
<doko>         cflags = stringList(envList("CGO_CFLAGS", defaults), p.CgoCFLAGS)
<doko>         cxxflags = stringList(envList("CGO_CXXFLAGS", defaults), p.CgoCXXFLAGS)
<doko>         ldflags = stringList(envList("CGO_LDFLAGS", defaults), p.CgoLDFLAGS)
<doko>  
<doko> from go/cmd/go/build.go
<dobey> gccgo-5: error: /usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so\: No such file or directory
<dobey> hrmm
<dobey> wtf cmake/gccgo
<ogra_> cyphermox, did you see bug 1446689 ?
<ubottu> bug 1446689 in network-manager (Ubuntu) "network-manager configured to use /usr/sbin/pppoe but does not recommend pppoe" [Undecided,Confirmed] https://launchpad.net/bugs/1446689
<doko> didrocks, dobey looks like you have to use dh_python3 --shebang=/usr/bin/python3 explicitly
<ogra_> (and the corresponding ubuntu-devel-discuss thread)
<cyphermox> ogra_: yes, I saw
<doko> dobey, the extraneous : ?
<ogra_> cyphermox, i wonder if we can do something about that ... seems rp-pppoe is in universe now for whatever reason
<dobey> doko: for some reason a "\" is being added to the filename soemwhere
<dobey> but afaict it's not cmake doing it, but gccgo
<cyphermox> ogra_: we'll just have to promote it again, if it was ever in main
<ogra_> yeah, well, if it was, that is most likely quite a while ago
<doko> dobey, or -L$(dirname $(gcc-5 --print-file-name libgcc_s.so)) -L$(dirname $(g++-4.9 --print-file-name libstdc++.so))
<dobey> oh maybe it is cmake
<dobey> hmm
<cyphermox> ogra_: ah, I think I see.
<dobey> no idea why that's happening though :(
<didrocks> doko: interesting, that's for the pointer! I'll bundle that in next upload
<ogra_> cyphermox, oh ... the "--with-pppoe=/usr/sbin/pppd" sounds like an interesting workaround :)
<ogra_> probably works without seeding rp-pppoe
<cyphermox> ogra_: right, plus part of that code changed at some point
<ogra_> ah
<ginggs> cyphermox, ogra_ : hi, i'm familiar with that bug
<cyphermox> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6fdfb03107138e96e641d12a7c4df5ecfacb5406
<ogra_> yeah, i see your comment :)
<rbasak> hallyn: it looks like your netcf FTBFS fix in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795328 also came up on the rebuild test and affects 1:0.2.6-1 in Debian experimental which is synced to Wily. I can cherry-pick it but do you want to upload a fix to Debian experimental and sync that instead?
<ubottu> Debian bug 795328 in src:netcf "netcf: FTBFS: error: 'IFF_UP' undeclared (first use in this function)" [Serious,Fixed]
<cyphermox> I'll cherry-pick the fix to wily and prepare a SRU for vivid.
<ogra_> yay
<ogra_> now that was quick ... :)
<cyphermox> ^^ commit is upstream already, it's just a matter of identifying which
<cyphermox> so once I looked at git and saw that the pppoe_binary bits weren't there, and we have them in what's currently in wily, then it's obvious there is some patch to apply
<cyphermox> or
<cyphermox> ogra_: wanna do it?
<cyphermox> or morphis
<ogra_> very busy this week ... sorry
 * ogra_ only saw the mail and wanted it handled if possible :) 
<cyphermox> does that affect you?
<cyphermox> ginggs: me guesses you're directly affected by this, so you could test the SRU?
<ogra_> nope, i dont use NM on my router
<ogra_> (headles ufw/pppoe setup)
<bdmurray> pitti: Where is your retracer code? https://bugs.launchpad.net/ubuntu/+bug/1320700/comments/2 That could use some improvement.
<ginggs> cyphermox: sure i can test an SRU
<ubottu> Error: malone bug 1320700 not found
<cyphermox> yeah
<ogra_> malone !
<dobey> doko: i managed to get it a bit further along, but now it's weirdly complaining about use of undefined name in some of the go code
<ogra_> now i feel old
<ogra_> (remembering what malone is/was)
<bdmurray> ogra_: I hate to tell you this but you are
<ogra_> lol
<ogra_> so true
<pitti> bdmurray: it's not in bzr, these are just some custom scripts that we run every now and then to clean up the unretraceableones
<bdmurray> pitti: ah, okay
<doko> dobey, paste?
<dobey> ../../service-ng/src/github.com/ziutek/glib/value.go:71:3: error: reference to undefined name â_Cfunc_g_value_set_doubleâ
<dobey> lot sof stuff like that
<dobey> i wonder if we can get golang 1.5 backported to the vivid phone overlay PPA instead of trying to make gccgo work
<doko> dobey, wasn't the server team already doing that?
<jrwren> dobey: copy it from ppa:~ubuntu-lxc/lxd-stable ?
<dobey> doko: why would the server team care about go on the phone?
<jrwren> how is go on the phone different from an armhf build of go?
<dobey> or they are backporting as an sru for vivid?
<thebwt> Howdy folks, is there a document out there that details packaging destination directory best practices?  like when to use /sbin vs /usr/sbin ?
<doko> welcome to the wonderful world of inter team communication
<thebwt> (asked in the packaging, but it's been a ghost town for the last week)
<dobey> jrwren: well, armhf isn't the problem. it's arm64 and ppc
<chiluk> infinity, arges, do either of you have a chance to review the debdiff for https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871 with me?
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Wily) "`df` shows bind mounts instead of real mounts." [Low,In progress]
<jrwren> dobey: for phone? oh right, arm64
<doko> dobey, but maybe mwhudson knows about the cfunc stuff ...
<jrwren> dobey: there is a go with builds for all those platforms in that ppa
<arges> chiluk: i can take a look
<dobey> jrwren: well, for phone there is an overlay PPA and QA requirements and such, so for me to use new go on vivid, we need to get new go approved to go in that PPA
<arges> chiluk: oh i remember this one : )
<jrwren> dobey: ah, sorry. I see what you mean.
<chiluk> arges it's a fairly large change... but debdiff is a collection of clean-ish cherry-picks from upstream.
<arges> yea this will require more coffee
<chiluk> lol..
<chiluk> I think I did a good job documenting what I did in the case, and in the patch.
<sil2100> doko, slangasek: hey! So, regarding the mir build-failure from bug LP: #1506045 - could anyone of you guys copy-package the mir version I mentioned there from the overlay PPA to the archive? It has the fix for the build failure
<ubottu> Launchpad bug 1506045 in mir (Ubuntu) "FTBFS on amd64, armhf and i386 due to missing headers" [Undecided,In progress] https://launchpad.net/bugs/1506045
<Laney> sil2100: seb128 has been pinging the team about it
<Laney> maybe find out what they said first
<seb128> I asked them yesterday
<seb128> they said they needed QA verification first
<seb128> kgunn said they would copy over once it's done
<seb128> 0.17
<kgunn> seb128: yep, it just now got QA approval
<kgunn> so needs to at least migrate to overlay first
<seb128> great
<sil2100> QA verification?
<seb128> it's a dual landing
<seb128> you know QA team, touch, phone etc
<sil2100> But it's landed already
<seb128> 0.17?
<sil2100> No, 0.16.1+15.10.20150930.1
<seb128> they want to land 0.17
<sil2100> This is enough to get wily mir building
<seb128> right
<seb128> but 0.17 is ready and has more fixes
<seb128> they wanted to land that directly
<sil2100> Ok, well, I just want to resolve the build failure before the release
<sil2100> Anyway, as long as 0.17 builds on wily as well then sure ;)
<seb128> right and it's being handled
<seb128> don't worry about it
<Saviq> bbl
<ginggs> cyphermox: shouldn't you remove '--with-pppoe=/usr/sbin/pppoe' from debian/rules as well?
<cyphermox> ginggs: yes, you're right, it will need to be changed to /usr/sbin/pppd or the right path for pppd
<ginggs> cyphermox: no i think it should just go
<cyphermox> oh, you're right
<ginggs> doko: it would be great if those FTBFS pages (e.g. http://qa.ubuntuwire.com/ftbfs/ ) had an editable comment field like the merge-o-matic pages (e.g. https://merges.ubuntu.com/universe.html )
<doko> wgrant, ^^^
<doko> ginggs, yeah, but there is not much space on these lines
<doko> mvo, just updated https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/823254
<ubottu> Launchpad bug 823254 in software-center (Ubuntu) "Port to python3" [Medium,Confirmed]
<doko> what is this issue about gmenu?
<mvo> doko: I don't know about a gmenu issue sorry
<doko> mvo, well, you wrote about it in the past?
<mvo> doko: aha, this can be removed, current trunk is using gobject-introspection already for gmenu
<mvo> doko: and python3-dbus exists also, let me update the bug
<doko> mvo, ta
<mvo> yw
<mterry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<seb128> happyaron, cking, do you have a ffe for zfs-linux? https://wiki.ubuntu.com/FeatureFreeze states that's needed for new packages (and those should stop after beta freeze)
<cking> seb128, https://bugs.launchpad.net/zfs/+bug/1505716
<ubottu> Launchpad bug 1505716 in Ubuntu " [FFE]: dkms: add ZFS support in universe" [Undecided,New]
<seb128> thanks
<seb128> cking, happyaron, sorry but the zfs news review is not going to be for today from me, we have team dinner tonight and I need to go
<seb128> maybe somebody in the U.S tz can pick that up
<seb128> otherwise I'm going to try to have a look tomorrow if things are not too crazy at the sprint
<cking> seb128, tomorrow is fine, thanks
<seb128> yw!
<mterry> chiluk, I'm looking at bug 1432871
<ubottu> bug 1432871 in coreutils (Ubuntu Wily) "`df` shows bind mounts instead of real mounts." [Low,In progress] https://launchpad.net/bugs/1432871
<mterry> chiluk, and I see you also patched gnulib
<mterry> chiluk, but don't have a wily patch for it?
<chiluk> mterry are you looking for https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/comments/9
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Wily) "`df` shows bind mounts instead of real mounts." [Low,In progress]
<chiluk> or has the wily version changed in the last few weeks.
<mterry> chiluk, that's a patch for the coreutils package
<mterry> chiluk, does the gnulib package not also need a patch?  You link to upstream gnulib changes
<chiluk> mterry I guess you are correct..
<chiluk> the weird thing is that we package coreutils with a gnulib already sitting in lib
<mterry> chiluk, are they separate changes?  It looks like you mention coreutils needing support in gnulib?
<chiluk> unless I'm missing something.
<chiluk> I didn't notice that we had a separate gnulib package..
<chiluk> I'll work on a debdiff for gnulib this afternoon.
 * mterry looks at code...
<mterry> chiluk, I see what you mean.  It does seem to include its own copy of the code
<chiluk> it's definitely not dynamically linked to gnulib sources.. it's really a very odd project like that.
<chiluk> mterry I think you are right though, if we are going to fix coreutils we should probably have the requisite changes in gnulib as well.
<mterry> chiluk, I think maybe it's OK to ignore gnulib for now...
<mterry> chiluk, it doesn't seem as important -- we can wait for upstream there
<chiluk> alrighty..
<chiluk> mterry if you want to do the initial upload I'll get arges to do the SRU when I meet up with him this afternoon.
<mterry> chiluk, uploaded (with a bugfix merge from Debian included too)
<chiluk> awesome thank you mterry
<mterry> chiluk, thanks for the fix!  :)
<chiluk> yeah.. it was a royal pita.
<mterry> chiluk, whoops.  I was careless.  I uploaded the coreutils change, but it is ftbfs
<mterry> chiluk, have you tested it on wily?
<mterry> chiluk, specifically, the tests/misc/chroot-fail.sh dies on everything from chroot / sh... down
<chiluk> mterry, yeah this is weird.. I know I built it last week....
<chiluk> mterry give me a sec.. I'll get it squared away.
<chiluk> yeah the .m4 changes shouldn't have been in there.
<chiluk> the patches that got included add them, then remove them.
<chiluk> that's where it's failing.
<chiluk> mterry I think I may have just uploaded the wrong debdiff.. this bug has been going on for so long.
<mterry> hah
<chiluk> mterry, no that's the correct patch... I even have the debs that I built with it.
<chiluk> mterry I'm attempting another sbuild now.. mterry .. I know I had issues getting coreutils to build using pbuilder ... are you using pbuilder by chance?
<mterry> chiluk, I am, but I saw the same error that the buildd did when using it (and an extra error when building locally, but I didn't worry about that one)
<mterry> chiluk, I've combined your patch with another change from Debian when uploading... maybe that is screwing something up?
<mterry> chiluk, it was a chroot related change in debian...
<mterry> chiluk, but Debian's package builds fine for me
<arges> chiluk: https://launchpad.net/ubuntu/+source/coreutils/8.23-4ubuntu1/+build/8129763
<chiluk> mterry .. it's ok .. I'll take a closer look at it.
<chiluk> mterry looks like a test failure..
<mterry> chiluk, yup
<chiluk> mterry FAIL: tests/misc/chroot-fail .... my changes should be touching that.
<chiluk> mterry PASS: tests/misc/chroot-fail.sh  ... builds fine with just my patch.
<chiluk> I'll grab the sources and see what's going on.
<mterry> chiluk, sorry  :(  I didn't consider Debian's patch blowing yours up
<chiluk> mterry ... I'll help figure this out.. perhaps we should push my patch back into debian..
<chiluk> I think It's mostly ready for submittal there, but they don't have a related bug open yet.
<Noskcaj> Would someone  be able to sponsor a merge of redshift for me? it's currently non-funtional in wily, and it would be great to fix it
<mterry> Noskcaj, got a bug number?
<arges> chiluk: http://launchpadlibrarian.net/221228821/coreutils_8.23-4ubuntu1.dsc
<Noskcaj> bug 1485153
<ubottu> bug 1485153 in redshift (Ubuntu) "Unable to connect to GeoClue" [High,Triaged] https://launchpad.net/bugs/1485153
<Noskcaj> probably a few dupes too. I'm just merging it now, i've been away for a few months
<mterry> :)
<arges> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #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
<arges> mterry: oh its your patch pilot day too : )
<mterry> arges, :)
<mterry> arges, I'm currently working on "baloo_file_extractor crashed with SIGSEGV in memcpy"
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/wily/redshift/merge2/+merge/274448
<mterry> Just to avoid overlap
<mterry> arges, and Noskcaj's merge ^
<arges> mterry: ok
<chiluk> mterry so I just removed my patch from your upload of coreutils, and chroot-fail.sh still fails.... so it's like the debian patchset that's breaking somethin.
<mterry> chiluk, huh... I had tried that...
 * chiluk is happy it wasn't his fault for once...
<mterry> chiluk, will try again to confirm
<chiluk> I just commented my patch out of 00list.. with a #... not sure if that would do it..
<mterry> chiluk, I think so?  As long as it was not applied at the time
<mterry> I don't believe your patch was anything but a debian/patches patch
 * arges looks at 1314887
<chiluk> mterry that is correct...
<mterry> chiluk, ah.. I know why my test of debian's change worked.  They don't run tests, but the fact that we do wasn't clear from our changelog delta.  OK.  I'll patch out the test due to it being Debian
<chiluk> mterry it looks like you removed -33_chroot_always  .. that's probably the source of the build failure.
<chiluk> mterry give me one sec to check.
<mterry> chiluk, no?  That was added by Debian
<chiluk> yeah but they aren't running tests.
<chiluk> just give me a sec to understand what's going on and what's being tested here.
<mterry> chiluk, right.  But I'm saying I didn't remove 33_chroot_always, I added it.  I think the fix is just patching out the tests in chroot-fail.sh that assume Debian didn't patch out the "chroot /" optimization
<chiluk> yeah I think you may be correct.
<mterry> chiluk, alright will go ahead with that then
<chiluk> mterry  the 33_chroot patch is definitely the source of the test failure.
<mterry> chiluk, cool.  I'm testing a build of coreutils with the tests patched out.  I presume it will work and I'll upload
<mterry> chiluk, sorry to alarm ya
<chiluk> mterry are you patching out all the tests or just the chroot-fail test?
<mterry> chiluk, just the chroot-fail ones that actually fail
<chiluk> mterry ... no worries... just support me when I submit for core dev eventually..
<mterry> chiluk, hah, the standard fee for that is measured in beers  :)
<chiluk> mterry... I'm not above bribery ...
<tyhicks> pitti: hello - is the libmicrohttpd MIR something that can happen towards the start of the 16.04 devel cycle or do you need it in main for 15.10?
<arges> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<chiluk> mterry are you going to be doing a copy of the wily sources to vivid as well?
<mterry> chiluk, wasn't planning to
<mterry> chiluk, didn't want to include the Debian stuff there
<chiluk> mterry they were at the same version.
<chiluk> mterry can I get up to upload my patch for vivid as well then?
<chiluk> I kind of want it to bake a bit in vivid/wily before proceeding with trusty
<mterry> chiluk, I can upload for vivid too sure
<chiluk> thanks.
<mterry> chiluk, that was my thinking for letting it bake in wily.  But sure on vivid
<chiluk> oh ok.
<chiluk> we can wait a few weeks then with wily.
<mterry> chiluk, no I'm fine.  it's just vivid  :)
<chiluk> yeah ... it should be safe... I just figured we'd get more thorough testing there.
<mterry> chiluk, but first let it land in wily
<chiluk> yeah.
<mterry> still hasn't
<doko> slangasek, I think you are wrong writing "will cause the behavior of programs to be inconsistent"
<mterry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mwhudson> dobey: are you still here?
<dobey> hi
<pitti> tyhicks: libmicrohttpd can certainly wait for 16.04; we are deep in FF anyway, I just stumbled across it today and wondered if it was blocked on information or just manpower
<tyhicks> pitti: that's great to hear!
<dobey> mwhudson: i think the best solution is to just try and get golang 1.5 into our phone overlay ppa at this point, to solve the issues we're hitting
<tyhicks> pitti: it is a man power issue - we had several high priority MIRs that trumped many others this cycle
<mwhudson> dobey: ah ok
<pitti> tyhicks: that's ok, thanks
<mwhudson> dobey: let me know if you want me to try to figure out what's going on, but if it's 1.4 or earlier i might not be much help
<dobey> mwhudson: yeah, the problem is vivid has 1.3, and on arm64 and powerpc doesn't use golang-go, but rather uses gccgo, and that isn't working with cgo very nicely
<mwhudson> dobey: aah
<mwhudson> yeah sounds plausible
<mwhudson> fwiw, golang-go on ppc64el is still pretty bad at cgo
<dobey> i'm more worried about arm64 than ppc really at this point
<dobey> aren't many ppc phones on the market :)
<sergio-br2> hi
<sergio-br2> just a quick question: ubuntu packages are synced from sid or testing?
<pitti> sergio-br2: the autosync is from sid usually, but we don't run it right now; manual syncs can happen from anywhere
<sergio-br2> even universe packages are from sid?
<sergio-br2> and main
<pitti> yes
<pitti> we have our own britney instance to keep out the brokenness
<sergio-br2> ok, found something http://askubuntu.com/questions/104287/how-is-ubuntu-more-updated-than-debian
<sergio-br2> so the LTS packages comes from testing
<cjwatson> not any more
<cjwatson> that was true at one point but it proved to be more trouble than it was worth, especially once we introduced our own equivalent of testing migration
<cjwatson> note the date on that answer
<sergio-br2> february 2015
<cjwatson> no
<sergio-br2> nope, it's 2012 right?
<cjwatson> it's a silly American date
<cjwatson> 2012-02-15 in sensible formatting
<sergio-br2> so 14.04 came from sid more or less?
<cjwatson> sergio-br2: yes
<cjwatson> sergio-br2: 12.04 was testing if I'm remembering/reading the history correctly
<sergio-br2> it explain lot's of stuff
<cjwatson> auto-syncing from testing meant that it took longer for regressions to get fixed due to the standard migration delay in Debian, and we ended up frequently spending time chasing down regressions that turned out to be already fixed in unstable
<cjwatson> (and obviously it had some benefits, but our own testing migration provided the bulk of the same benefits)
<sergio-br2> thanks for the explanation
<sergio-br2> another question: why the kernel number is not bumped to 4.2.0 --> 4.2.1 --> 4.2.2 and so ?
#ubuntu-devel 2015-10-15
<Pwnna> does anyone know why my package here says newer version available? I tried dpkg --compare-versions and it says my version is greater? https://launchpad.net/~shuhao/+archive/ubuntu/ppa
<sarnold> Pwnna: a version with an epoch such as 1:0... is going to be higher than any version number without an epoch
<sarnold> Pwnna: did you include the 1: in your --compare-versions test?
<Pwnna> sarnold: no. am i missing a 1:?
<Pwnna> i thought that was optional.. okay i'll change it
<Pwnna> thanks for the tip!
<sarnold> Pwnna: those epochs allow for changing versions when upstreams change from e.g. 20151014 to 1.1. they're annoying but more or less necessary.. and once used, nearly impossible to ever remove.
<Pwnna> sarnold: yeah i understand them. i just thought that epochs by default are 1 if unspecified.
<Pwnna> my mistake
<infinity> Pwnna: Default epoch is 0
<Pwnna> ahh
<Pwnna> is my naming proper for the rest of the version string?
<Pwnna> i'm not quite sure about the 0.4.8-1+1SNAP...
<infinity> Pwnna: I assume the snapshot is from upstream?
<Pwnna> yes
<Pwnna> a snapshot of master
<infinity> Pwnna: If so, I'd say your + is in the wrong place.
<Pwnna> so i want to convey the date of the package and the sha
<Pwnna> infinity: where would it be?
<infinity> ie: Should be 0.4.8+20151014-0shuhao1 or something pleasant like that.
<Pwnna> where would I put the sha?
<infinity> Pwnna: Tail end of the upstream version (the '-' splits upstream and distro) if you care deeply, I prefer to just mention it in the changelog.
<infinity> Since hashes can't sort, they make crappy versions. :P
<Pwnna> yeah
<Pwnna> i was told to tag a date and then a sha
<Pwnna> so it would be 0.4.8+20151014-sha-0shuhao1 or something like that?
<infinity> *shrug* ... Personal preference.  I don't think it adds much useful info to have it in the version, as long as it's also in the changelog, but it also doesn't hurt.
<infinity> Pwnna: 0.4.8+20151014+sha would be your upstream version (as encoded in the orig.tar.gz filename) and -0shuhao1 for the Debian revision.
<Pwnna> hm
<Pwnna> another question
<infinity> Pwnna: If you intend to do more than one release per day, make the timestamp longer, as you did in your current upload, I just didn't feel like typing more digits. :P
<Pwnna> yeah
<Pwnna> i'm okay
<Pwnna> i think i can do monthly
<infinity> Pwnna: But, IMO, long timestamp in version, and sha in debian/changelog entry is just as informative and less gross.  YMMV, etc.
<Pwnna> fair enough
<Pwnna> infinity: how would my orig.tar.gz work? like what's the directory structure inside the tarball?
<infinity> Pwnna: Should look the same (modulo code update, of course) as the orig.tar.gz in the archive for 0.4.8
<infinity> Pwnna: Which is usually just an exported checkout of upstream at a tag, or similar, but sometimes involves some prep scripts.  Not my project, so don't know. :P
<Pwnna> infinity: so like i see the ubuntu package just have xournal-0.4.8 as the directory name inside the orig.tar.gz
<cjwatson> That's usually what upstream build scripts of the "make dist" type produce.
<Pwnna> i don't think there's a make dis
<cjwatson> The exact top-level name doesn't matter, though.
<Pwnna> oh it doesn?t
<infinity> Pwnna: Oh.  The first directory makes zero difference.  YOu can call it "giraffes-are-awesome" if you want.
<Pwnna> i thought it had to match the version
<Pwnna> aaaah
<infinity> Pwnna: dpkg ignores the first part.
<cjwatson> No, dpkg-source sorts it out.
<Pwnna> okay cool cool
<Pwnna> also 0<whatever>1 at the end, what's the 0 supposed to be?
<Pwnna> i read the docs but i think i missed that part..
<infinity> Pwnna: -0ubuntuX implies "Ubuntu revision X with an upstream that's ahead of Debian"
<infinity> Pwnna: So -0userX implies "User revision X with an upstream ahead of Ubuntu", at least in an Ubuntu/PPA context.
<Pwnna> but what's the prefix 0?
<infinity> Pwnna: The prefix 0 in the Ubuntu context is so that if Debian releases 0.5-1, it sorts higher than our 0.5-0ubuntu1
<Pwnna> ah i see
<infinity> Pwnna: In your use case, it's less meanigful to do it that way, but it maps logically and looks consistent. ;)
<infinity> Pwnna: The other logical mapping is -0ubuntu1~user1, but that sort of implies that your stuff is maybe, some day headed to the archive proper.
<Pwnna> ah i see
<infinity> Pwnna: ie: if I were prepping a new glibc version in my PPA, I would call it "2.22-0ubuntu1~adconrad1" (or just ~ppa1, because I'm a lazy typist), but that implies that 2.22-0ubuntu1 is archive-bound once the PPA versions don't suck.
<infinity> Pwnna: If I was doing glibc snapshots in a PPA, I'd do 2.23~20150114-0adconrad1, cause we'll ship a glibc snapshot in the distro over my dead body. ;)
<Pwnna> fair enough
<Pwnna> i want to actually get this package upstreamed
<Pwnna> because a bug is present from vivid and up
<Pwnna> but upstream hasn't do a release because the maintainer is "busy"
<Pwnna> idk where to look for this
<slangasek> doko: "will cause the behavior of programs to be inconsistent"> I don't see why that's controversial; you're explicitly saying that on some systems the software will do certificate verification and on other systems it won't, and it depends on a setting outside the program that's part of the system's python3.4 installation
<infinity> Pwnna: If you want to actually SRU fixes into the distro, finding the right commits and cherrypicking as patches would be more palatable than saying "update to this commit", generally.
<doko> slangasek, no, in all cases it's the same behaviour unless a sysadmin chooses to change the default. that's not different than any other change to a config file
<Pwnna> yeah but all the new commits since the previous verson has been fixes or another.
<Pwnna> there might have been 1 feature
<Pwnna> either way, i might push upstream again
<Pwnna>  how long does uploading build take?
<infinity> Pwnna: That version still has the "-1" in the middle. ;)
<Pwnna> after the version number?
<infinity> Pwnna: As for how long publishing to disk takes after a build, it varies, but give it a hald hour or so (or wait for the icon to change).
<Pwnna> my new version number is 1:0.4.8-1+20151014+f5c777d4e-0shuhao1
<infinity> Pwnna: The old upstream version was 0.4.8, the Debian revision was -1
<infinity> Pwnna: Your upstream should be 0.4.8+20151014+f5c777d4e
<Pwnna> but i thought i have to have that in order for it to be > than the ubuntu version?
<infinity> Pwnna: Upstream and Debian revision are compared separately, so 0.4.8+20151014+f5c777d4e >> 0.4.8
<Pwnna> oh
<Pwnna> i see.
<Pwnna> i suppose i should just get it right and rebuild it again
<Pwnna> but i have to delete this package first, no?
<slangasek> doko: yes, that's exactly the difference in behavior I'm talking about.
<infinity> Pwnna: Nah, the new one would be a higher version, so it'll supersede it.
<infinity> Pwnna: Well, might be.  Things get confusing when there are two dashes in a version number...
<Pwnna> i just did a comparison and it returned 1
<Pwnna> yeah i'll delete it and reupload
<Pwnna> wait so what's debian version?
<Pwnna> it's after the dash, right?
<infinity> Pwnna: The debian revision is everything after the last dash.
<infinity> Pwnna: Which is confusing for humans and poorly-written software alike when there's more than one. ;)
<Pwnna> what's the significance of the debian revision again? if they put in patches?
<Pwnna> and then ubuntu1 for the ubuntu revision
<Pwnna> or user1 for the users' revision
<infinity> The debian revision (-1, -0ubuntu1, -0user1, -3derivative7, whatever) denotes changes made on top of upstream.
<infinity> So, generally, in a 3.0(quilt) style package, at least, everything in debian/*
<infinity> A bare -N is what we inherit from Debian, then -NfooX is the X revision on top of debian's N revisions.
<Pwnna> i see
<Pwnna> also, for the release in the change log, debian has "unstable", ubuntu has things like "wily". how do you automate building for them?
<Pwnna> i'm aware for ppa copy packages
<Pwnna> but
<Pwnna> seems tedious?
<Pwnna> and i want to build from like a common base.
<infinity> For uploads directly to the archive, we put the series in the changelog.
<infinity> For syncs from Debian, we cheat and force the target.
<infinity> Just as copy-package would do.
<infinity> If your goal is a common base, and you know there won't be ABI issues between releases, upload to the oldest release you intend to support and then just copy with binaries to all the newer ones.
<infinity> Test on the newest release, and if it works, you probably didn't mess up. :P
<Pwnna> sorry i mean a common base as in. since i commit things like changelog and debian/ into a repository
<Pwnna> how do i build so that i don't need to manually edit the change log between building for different releases?
<infinity> If you want to build for each release with each release's toolchain, you need 1 upload per release (with a unique version for each), there's no way around that.
<infinity> So if you're already twiddling the version, changing the target isn't extra effort.
<Pwnna> no i mean if i want to have 1 source base and want to generate a package for multiple ubuntu targets, can i do it without fiddling the change log to change wily to vivid and so forth?
<Pwnna> or does it even matter?
<Pwnna> or does it only matter in the context of the ppa?
<infinity> Pwnna: Well, like I said, you need to have a unique version for each of those, so the changelog needs changing regardless.
<Pwnna> do you need an unique version for each ubuntu release?
<Pwnna> even if it is the same upstream version with no changes to the source code?
<infinity> Pwnna: Well, we roll packages forward, so no, but also yes. :P
<infinity> Pwnna: A package uploaded to trusty that hasn't changed since still has the same version in wily.
<infinity> Pwnna: But it also wasn't rebuilt.
<infinity> Pwnna: If you're *building* for each series, they need a unique version, since you have unique builds that can't clash.
<Pwnna> ah
<Pwnna> i see
<Pwnna> my problem stems from the fact that in the ppa there's vivid/wily series
<Pwnna> and if i'm on wily i can't import vivid unless i copy them, right?
<infinity> Pwnna: Right, so your solution is one of two things.  Either upload to vivid and copy (with binaries) to wily, so it's published in both.  If that works, because no ABI transitions have broken you, that's the simplest.
<infinity> Pwnna: Alternately, you need unique versions and two uploads.
<Pwnna> right. i see
<Pwnna> i keep getting Launchpad encountered an error during the following operation: copying a package.  xournal 1:0.4.8+20151014+f5c777d4e-0shuhao1 in vivid (source has no binaries to be copied)
<Pwnna> is this because my thing is still saying Pending publication?
<infinity> Yep.
<Pwnna> when you expand it
<infinity> Patience. :)
<Pwnna> mkay :)
<Pwnna> thanks a lot infinity
<Pwnna> it was very helpful!
<Pwnna> i think i can go on packaging more things..
<Pwnna> except idk how to package things without autoconf yet..
<Pwnna> infinity: after you copy packages (just a binary copy?), how long does it take for it to show up?
<infinity> Pwnna: That same half-hour-or-less that it takes for your builds to publish.  It's the same process.
<Pwnna> even with the copy binary?
<Pwnna> it doesn't say a build is running
<Pwnna> https://launchpad.net/~shuhao/+archive/ubuntu/fixed/+packages
<infinity> Pwnna: Yeah, it still needs to build the Packages.gz indexes for wily, etc.
<Pwnna> ah i see. so there's no status update on launchpad for this, then?
<infinity> Pwnna: Well, it does show the source as "Status: Pending".
<infinity> Pwnna: When that flips to "Published", you should be more or less good to go.
<Pwnna> yeah
<Pwnna> okay. cool. i thought it might have more info with pending or something
<Pwnna> thanks a lot :)
<hallyn_> rbasak: regarding netcf, no i'd rather we get the newer netcf package into debian unstable.  i'd asked xnox to sponsor https://mentors.debian.net/package/netcf .  let me ping him
<hallyn_> xnox: ping :)
<sergio-br2> any hope to see libpng 1.6 in the next LTS repo?
<sergio-br2> I have 2 packages which needs this version
<sergio-br2> it's like people's moving to 1.6
<pitti> Good morning
<zaytsev> laney: hi there! any chance you could sponsor https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1506166 ? i noticed you were the last uploader if i'm not mistaken
<ubottu> Launchpad bug 1506166 in vte3 (Ubuntu) "Bracketed paste should be per-terminal [PATCH]" [Undecided,New]
<Unit193> zaytsev: \o
<zaytsev> unit193: o_O
<zaytsev> unit193: oh, having tilted my head in a normal position, i suddenly realized you were just about to say "hi" :) hi to you sir, then
<pitti> infinity: when do you want the final wily langpacks (fresh build)?
<doko> dobey, which was the package you were touching yesterday (the go issues)?
<doko> pitti, he "doesn't intend to start building "RC" images until Friday night or Saturday morning"
<Laney> hi zaytsev
<pitti> doko: ack, thanks
<Laney> sure I can help
<Laney> can you re-format the bug description to add the sections in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure please?
<pitti> wgrant: I forgot to request a full export on https://translations.launchpad.net/ubuntu/wily/+language-packs early enough, just did it an hour or so ago
<pitti> wgrant: if the job is already running, could you cancel it and re-run a full export?
<pitti> wgrant: if it didn't start yet, then it should just all work by itself I figure
<wgrant> pitti: Checking
<wgrant> pitti: Not scheduled to start for another hour and aib.t
<pitti> wgrant: ah good, then it should be fine; what's "aib.t"?
<wgrant> pitti: "a bit" with hilarious typos.
<pitti> wgrant: :) thanks!
<mwhudson> pitti: did i say thanks for the golang-race-detector-runtime reviews yet?
<mwhudson> pitti: if not, thank you!
<mwhudson> oh reminds me i should make golang-go Recommends: it
<zaytsev> laney: will do in the evening and ping you again, don't have launchpad access from work. thanks!
<pitti> mwhudson: you're welcome!
<mwhudson> hm
<mwhudson> can Recommends be arch-dependent?
<pitti> mwhudson: yes, similar to Depends:
<mwhudson> pitti: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1506393 if you have a moment or two
<ubottu> Launchpad bug 1506393 in golang (Ubuntu) "golang package should recommend golang-race-detector runtime" [Undecided,New]
<pitti> mwhudson: done, bug updated
<mwhudson> pitti: one day i will get a version number right :-)
<mwhudson> pitti: thanks
<pitti> mwhudson: dch -i :)
<mwhudson> heh i did that for some other package and the uploader changed the 2 into 1.1...
<pitti> mwhudson: we only use 0.1 increments for stable updates
<mwhudson> ah ok
<popey> looks like hexchat is broken in wily.
<popey> [M#z9 trying to overwrite '/usr/share/man/man1/hexchat.1.gz', which is also in package hexchat-common 2.10.2-1ubuntu1
 * popey files bug 1506399
<ubottu> bug 1506399 in hexchat (Ubuntu) "Can't update hexchat on wily" [Undecided,New] https://launchpad.net/bugs/1506399
<seb128> popey, oh, likely my fault :-/
 * seb128 fixes
<popey> #blameseb128
<ogra_> itz gtk boog
<seb128> so at least know we know there is an hexchat user, popey
<ogra_> he doesnt really use it, he only installs it to find bugs and nag you ;)
<seb128> guess si
<seb128> so
<seb128> he probably have every deb in the archive installed
<popey> so true
<popey> (I have it because Ubuntu MATE has it)
<doko> pitti, should the freeradius autopkg test be given back?
<pitti>   Removing adt-satdep:amd64 because I can't find python-unit:amd64
<pitti> doko: won't help; python-unit was removed a few days ago, so freeradius' test needs to be changed to not depend on python-unit any more
<pitti> doko: I'll have a look, thanks for pointing out
<doko> ohh
<doko> Riddell, sitter: somebody looking at the cantor autopkg test failure?
<pitti> doko: it's hinted as force-badtest
<doko> ahh, good
<pitti> doko: ah, I bump the version
<pitti> (in the ints)
<pitti> hints too
<ginggs> cyphermox: just confirming nm 1.0.4-0ubuntu5 in wily now works with pppoe (bug 1446689) thanks!
<ubottu> bug 1446689 in network-manager (Debian) "network-manager configured to use /usr/sbin/pppoe but does not recommend pppoe" [Unknown,New] https://launchpad.net/bugs/1446689
<ginggs> tyhicks, sarnold: i've added some info on how nvidia-modprobe works to bug 1421209
<ubottu> bug 1421209 in nvidia-modprobe (Ubuntu) "[MIR] nvidia-modprobe" [Undecided,New] https://launchpad.net/bugs/1421209
<pitti> doko: fixed the tests; doing a local package build as it hasn't built in wily yet
<pitti> doko: uploaded (main, needs RT ack)
<rbasak> cjwatson: looks like a merge for libapache2-mod-perl2 will fix the FTBFS. It's not completely clear to me that there aren't any new features, but the fixes make it seem reasonable to me to pull all of it in. Any opinion?
<rbasak> Or I could just cherry-pick the FTBFS fix which is trivial.
<sitter> doko, Riddell: taking a look at cantor
<tyhicks> thanks ginggs
<cjwatson> rbasak: Feel free to steal my merge if you like; I have no opinions other than that :-)
<rbasak> OK, thanks
<sitter> Riddell: I think something regressed in kf5.15 that makes cantor tests fail
<dobey> doko: pay-service and ubuntu-push are the ones i'm concerned with at the moment
<doko> dobey, did you try the build on wily first?
<dobey> doko: i don't have access to any ppc or arm64 hardware to test on. ubuntu-push at least compiles on arm64 on wily though, but the tests are failing on that arch there. i think the push guys are working on getting those tests fixed though
<doko> dobey, same for ppc64el
<dobey> right
<doko> dpkg-deb: building package 'ubuntu-push-dev-server' in '../ubuntu-push-dev-server_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'.
<doko> dpkg-deb: building package 'ubuntu-push-client' in '../ubuntu-push-client_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'.
<doko> dpkg-deb: building package 'ubuntu-push-autopilot' in '../ubuntu-push-autopilot_0.68+15.10.20150814.1-0ubuntu1_powerpc.deb'.
<doko> dobey, ^^^
<dobey> doko: ok?
<dobey> doko: should the failed builds on https://launchpad.net/ubuntu/+source/ubuntu-push/0.68+15.10.20150814.1-0ubuntu1 be retried perhaps?
<dobey> oh there's a new golang upload in wily?
<doko> dobey, updated https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1431486
<ubottu> Launchpad bug 1431486 in ubuntu-push (Ubuntu) "ubuntu-push fails to build with gccgo" [Undecided,Confirmed]
<ppisati> what's happened to /lib/udev/write_net_rules in wily?
<doko> dobey, so I think with this schema you can fix all the other build failures on powerpc as well
<ppisati> in vivid it was part of udev, while in wily i can't find where it resides
<doko> mwhudson, ^^^
<dobey> ick
<doko> dobey, given back, still ftbfs
<sitter> Riddell, doko: failing cantor tests should pass with this ->   Uploading cantor_15.08.2-0ubuntu2_source.changes: done.
<doko> sitter, ta
<pitti> ppisati: not needed any more as the old 75-persistent-net-generator.rules is gone
<dobey> doko: hmm
<ppisati> pitti: someone pointed me to your old thread 'enable stateless persistant network interface names'
<ppisati> pitti: let me read it
<doko> is there a FFe for parole?
<ppisati> pitti: ok cool, so i should just give up any hope of having my old eth0 back
<ppisati> pitti: and get used to...
<ppisati> pitti: enxb827eb2da1ca
<ppisati> pitti: is that correct?
<pitti> ppisati: that's the current default name for USB devices, yes; admittedly ugly, but at least stable :/
<pitti> ppisati: you can change the policy of course
<pitti> or we might decide that we don't want to support stable names for USB and use the kernel names for those
<ppisati> pitti: with a systemd.link rule, right?
<pitti> ppisati: yes, that or an udev rule (or a link file) which assigns a name to a particular one; see /usr/share/doc/udev/README.Debian
<pitti> ... gz
<ppisati> pitti: uhm, the name is ugly but i can live with that if i can find a way to assign an ip to it via dhcp
<ppisati> pitti: i mean, i guess /etc/network/interfaces is dead too at this point
<pitti> ppisati: that's an independent decision; but I hear snappy/server team etc. are looking at networkd
<pitti> ppisati: for that the interface names don't really matter that much as you can select interfaces by properties (not just by name)
<ppisati> pitti: don't you need to specify the name of the nic in the [Match] section?
<ppisati> pitti: letme explain my problem
<ppisati> pitti: i'm preparing a custom image for an arm board (vanilla ubuntu)
<pitti> ppisati: no, you can match on any property
<ppisati> pitti: and i don't know the MAC nor the name of the interface until the first boot
<pitti> ppisati: e. g. on MAC address, original name, current name, location (path), driver, type, etc.
<pitti> (sorry, not original name, just name)
<pitti> ppisati: how was that done in the old world? hardcoding eth0 and hoping that there's no biosdevname or device drivers which use a different name?
<pitti> and hoping that there would just be one eth?
<pitti> the equivalent of that would be to use [Match]\nName=en*
<pitti> or create an /etc/network/interfaces with the first /sys/class/net/en* that you find
<pitti> which is pretty much exactly what happened with hardcoding "eth0" -- whichever ethernet happened to be detected first got it
<ppisati> pitti: you don't usually have more than one nic on these boards
<ppisati> pitti: anyhow, i'll see what i can do
<pitti> ppisati: you attached an usb ethernet, then you already have two, no?
<ppisati> pitti: no, that's the integrated nic
<ppisati> pitti: arm's nic are usually on the usb bus
<pitti> ah
<ppisati> pitti: beaglebone, rasppi, cubox, etcetc
<ppisati> 99% of them
<ogra_> ppisati, in snappy we use the kernel cmdline option to turn that off
<ppisati> arm64 is different beast thopugh
<ppisati> ogra_: what's that cmdline option?
<ogra_> ppisati, net.ifnames=0
<sinzui> Hi pitti jibel : is it possible to get a retest of juju-core in vivid-proposed? I reran adt tests against proposed and I see it passed (after an lxc fix?) http://autopkgtest.ubuntu.com/packages/j/juju-core/vivid/amd64/
<pitti> sinzui: sure
<ppisati> ogra_: works like a charm, thanks
<ogra_> :D
<ppisati> ogra_: i'll use it until the systemd networkd situaion is sorted out
<ogra_> xeah
<ogra_> *yeah
<ogra_> thats our plan as well
<ppisati> ogra_: +1
<ppisati> pitti: thank you as well :)
<pitti> ppisati: right, you can also disable it entirely (again, see README.Debian); either on kernel command line or via touching a file in the fs, whatever is easier
<ogra_> pitti, btw, did your last systemd upload change anythin wrt network bringp for /e/n/i interfaces  ? https://bugs.launchpad.net/snappy/+bug/1503329 .... seems systemd and udev are among the changed packages between the image that works and the one that fails
<ubottu> Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed]
<pitti> ogra_: no, just a crash fix for "shutdown"
<ogra_> pitti, thats, that rules out systemd
<pitti> ogra_: oh, from ubuntu4 to ubuntu5? that's by far not the latest (from today, that was ubuntu9)
<ogra_> oh, ok
<pitti> https://launchpad.net/ubuntu/+source/systemd/225-1ubuntu5
<pitti> ogra_: yes, that reverted calling if-*.d/ from networkd
<pitti> (as I wrote on u-devel@)
<ogra_> well, still curious why it then works on second boot
<ogra_> there must be something else
<ogra_> i assume that code would affect every boot
<pitti> ogra_: the if-*.d/ calling, yes; and it certainly isn't related to DHCP
<pitti> ogra_: are the images using networkd?
<ogra_> hmm, not sure we use networkd at all ... if they do, most likely unintended
<pitti> ogra_: it doesn't even run by default, you have to explicitly enable and configure it
<ogra_> ah, then it couldnt have slipped in
<ogra_> afaik we still just use ifupdown
<pitti> ogra_: the interface names also look like what you expect, right? that rules out the "udev.postinst: Actually call upgrade_fixes(), so that the "disable
<pitti>     persistent names on upgrades" quirk actually runs."
<pitti> fix
<pitti> and it'll hardly be the micmute keymap fix
<ogra_> pitti, its just eth0 everywhere
<ppisati> pitti: what's the file i need to touch to disable the renaming? /me has read /usr/share/doc/udev/README.Debian.gz but didn't see its name
<pitti> ppisati: sudo touch /etc/udev/rules.d/80-net-setup-link.rules
<Pwnna> does anyone here have experiences with git buildpackage?
<rbasak> !anyone | Pwnna
<rbasak> "A high percentage of the first questions asked in this channel start with "Does anyone/anybody..." Why not ask your next question (the real one) and find out?"
<Pwnna> i don't quite understand the branching process if i'm also upstream
<Pwnna> uh. znc lagging hard.
<rbasak> Usually upstream just stays in its own branch
<rbasak> When you want to update packaging, merge from that upstream branch into the packaging branch
<rbasak> Often the upstream branch is named "upstream" and the packaging branch "master" but that's not required
<Pwnna> rbasak: but if i'm developing a program that i want to package
<Pwnna> and i develop in master
<rbasak> Pwnna: even then it's easier to maintain a separate packaging branch
<Pwnna> right so i develop on master and then i put the debian/ directory in a debian branch
<rbasak> Yeah that would work.
<rbasak> You'll need to configure git-buildpackage to tell it which branch is which
<Pwnna> can i commit the .git/gbp.conf somewhere? does it make sense to do so?
<Pwnna> debian recommends putting things inside a debian/<release> branch. does that make any sense if my program is expected to work on debian/wheezy, debian/jessie, ubuntu/trusty, ubuntu/vivid, ubuntu/wily and so forth?
<tumbleweed> bp also supports debian/gbp.conf (which you'd commit to the repo)
<tumbleweed> *gbp
<tumbleweed> if you want to commit some config, put it in there
<Pwnna> ah cool
<Pwnna> i want to have a reproducible build setup rather than having it all on this one machine.
<Pwnna> so should I just have a debian branch, and then everytime i want to release, i merge from master/tag?
<rbasak> I think that would be fine
<rbasak> If you want, call that branch debian/sid
<rbasak> And then you have space for stable maintenance if needed
<Pwnna> hm. that might be a good idea
<Pwnna> in change log, do i just call it sid, then?
<rbasak> You can always rename things later
<Pwnna> yeah i want to get the process right.
<rbasak> Yeah debian/changelog has no bearing on branch names
<Pwnna> rbasak: but it does for ppa upload, right?
<rbasak> It matters what you put in debian/changelog for uploads
<rbasak> (and because you don't want to be wrong)
<rbasak> But it has nothing to do with what branches you use in git
<Pwnna> yeah i know that, i'm switching topic to what i have to be in debian/changelog
<Pwnna> sorry, should have clarified
<Pwnna> so for the release field, what's the "proper" release if i want to release the same package for a bunch of debian/ubuntu versions?
<rbasak> It's different
<rbasak> So you'll want various branches for that.
<rbasak> Easiest way is to script it. for r in sid wily vivid trusty precise; do dch -r -D $r ''" etc.
<rbasak> I have an example, hold on
<rbasak> https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/functions is what I did for docker.
<sil2100> barry: hey! Can I look into the pylint FTBFS? :)
<barry> sil2100: yes please :)
<sil2100> barry: sorry to steal away from you all the python package fun, but I noticed that the others usually have someone assigned ;)
<barry> sil2100: just the contrary, really appreciate it.  i've been stuck on a "fun" one
<sil2100> Yeah, the configglue one is similar, but I'm waiting for the upstream developer to maybe fix it upstream first
<Pwnna> :\
<doko> apw, please could you test a linux build using the binutils from the ubuntu-toolchain-r/test PPA until release? I'd like to find out if these are good enough for opening the x-series
<apw> doko, in hte W pocket i assume
<apw> doko, and yes
<doko> yes
<doko> apw, still building
<Saviq> morphis, hey, how close are you to landing silo 43?
<Saviq> morphis, also, I've got mako/wily and flo/vivid that don't want to turn bluetooth on, anything I can do to debug? bluetoothctl on wily just hangs, only thing I can do is Ctrl+C out of it
<bdmurray> xnox: Do you remember any context around this apturl change? "Drop libgtk2-perl Recommends to Suggests"
<xnox> bdmurray: i believe this was together with the effort to drop gtk2 out of main images.
<xnox> which is a lost cause, cuase qt5 to date depends on gtk2
<xnox> and also inline with dropping non gobject interspection bindings out of main.
<bdmurray> xnox: I think it is causing an issue with debconf and software-center. bug 1389582
<ubottu> bug 1389582 in software-center (Ubuntu) "software-center misses a dependency on libgtk2-perl" [Undecided,Confirmed] https://launchpad.net/bugs/1389582
<xnox> bdmurray: i did not see it comming like that.
<bdmurray> xnox: pardon?
<xnox> bdmurray: as in, when dropping that to suggests, i did not expect the softwae centre to break like that.
<xnox> bdmurray: so, libgtk2-perl was in main last in precise it seems (maybe later), and in universe from trusty and up.
<xnox> bdmurray: thus either this will need a MIR for libgtk2-perl.
<morphis> Saviq: if bluetoothctl hangs on wily that mostly means your adapter isn't detected by bluez
<morphis> can you send me a paste of hciconfig -a
<Saviq> morphis, sure, sec
<morphis> Saviq: mako/wily is nothing we're looking at at the moment
<morphis> flo/vivid is a different story
<morphis> davmor2 told me recently that there is something wrong and I wanted to look at that
<bdmurray> xnox: was there more to that either?
<Saviq> morphis, flo/vivid worked after all, needed some time it seems...
<morphis> ok
<morphis> Saviq: for mako/wily I can't really give any idea other than that is broken
<morphis> need to get that synced once we did the initial landing
<Saviq> morphis, http://pastebin.ubuntu.com/12792214/
<Saviq> morphis, there's no bluetoothd though
<Saviq> morphis, and restarting the bluetooth upstart job hangs, to
<Saviq> o
<pitti> doko: I just tried to locally rebuild gnutls28 and I don't get that test failure (FTBFS)
<pitti> doko: django-nose builds in unstable and fails in wily (same version); unless someone already does, I can look into it?
<xnox> bdmurray: alternatively, we should fix apturl to use python3 gi based bindings for that, instead of perl.
<xnox> bdmurray: which is probably easier.
<morphis> Saviq: interesting
<morphis> do you have any other bluetooth service running?
<morphis> blueman, whatever
<morphis> Saviq: what is with hciconfig -a from your desktop?
<morphis> Saviq: next thing is running bluetoothd alone
<morphis> sudo bluetoothd -n -d, save the output and paste it
<Saviq> morphis, no, no other services, just plain devel-proposed on mako: http://pastebin.ubuntu.com/12792289/
<morphis> Saviq: with bluez in devel-proposed you currently in a situation where nothing will work
<morphis> you can't even configure it through the settings app
<morphis> Saviq: so lets skip devel-proposed for now
<Saviq> morphis, ack
<morphis> Saviq: so what about your desktop?
<Saviq> morphis, that's fine, only the two devices have trouble
<morphis> ah ok
<morphis> so flo/vivid is the most interesting then
<morphis> when excatly does this problem turn up?
<morphis> you enabled flightmode?
<zaytsev> laney: i've updated the description, hope it helps. let me know if there is something else i'd need to do, sorry i'm going through this for the first time (re. https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1506166)
<ubottu> Launchpad bug 1506166 in vte3 (Ubuntu Trusty) "Bracketed paste should be per-terminal [PATCH]" [Undecided,New]
<barry> sil2100: did you get anywhere with pylint?
<mwhudson> doko, dobey: is that something other than "#cgo pkg-config doesn't work right with gccgo" ?
<mwhudson> oh i see, that's what you commented
<dobey> mwhudson: i think there are more problems than just that, unfortunately
<mwhudson> dobey: oh good, wouldn't want things to be too easy
<mwhudson> dobey: is this a ftbfs crusade, or do you actually want to use ubuntu-push on arm64/ppc64el?
<dobey> mwhudson: we rewrote pay-service in go, and it was previously building/installing fine on arm64/ppc, but now it does not (in vivid anyway)
<sil2100> barry: yes, I think I have a fix
<barry> sil2100: cool
<sil2100> barry: preparing the debdiff now, I was busy with touch and then some house-work ;)
<barry> sil2100: no worries.  i am going to look at flake8
<Pwnna> for apt, is there a way to delete files that existed in a previous version of the package but not in the new version when upgrading? or does that already happen?
<roaksoax> dobey: howdy!
<roaksoax> err
<roaksoax> sorry
<roaksoax> doko: howdy!
<roaksoax> doko: what'sthe status of python3 support for twisted?
<roaksoax> doko: (since i see you as the maintainer)
<Laney> zaytsev: thank you, I will take a look tomorrow morning
<cjwatson> Pwnna: with the exception of conffiles (files in /etc, basically), that happens automatically and you don't need to do anything.  For stuff in /etc, nowadays, the best thing to do is to use the rm_conffile helper in dpkg-maintscript-helper(1) via dh_installdeb(1)
<cjwatson> Pwnna: having to care about this is fairly rare though
#ubuntu-devel 2015-10-16
<Pwnna> cjwatson: yeah this thing i'm working on is all about this.
<Pwnna> cjwatson: so if my file, /a is not in conffile and present in version 1.0, when i update the package to version 1.1, which no longer include the file /a, it will get automatically removed?
<ScottK> Yes.
<Pwnna> and if 1.0 depend on b, which depends on a. and 1.1 don't depend on b anymore, will b and a be removed?
<ScottK> Not without an additional command.
<ScottK> They'll no longer be required to met the dependency, so apt-get autoremove would remove them.
<Pwnna> hm so i should apt-get upgrade and then autoremove if i want this?
<ScottK> Yes.
<sarnold> the deborphan / orphaner programs can be helpful to clean up machines that have gone through a dozen upgrades
<sarnold> they require a careful use, of course, but they're helpful
<Pwnna> wait what's the difference between deborphan and autoremove?
<Unit193> sarnold: Plus  dpkg-query -W -f='${Conffiles}\n' | grep obso  and debsums.
<Pwnna> i'm not quite sure i understand the difference from this description.
<Pwnna> does it show manually installed packages too?
<sarnold> Pwnna: I've used them all for a decade and still don't know the exact differences :)
<Pwnna> lol
<sarnold> Unit193: heh, dpkg-query -W -f='${Conffiles}\n' | grep obso | wc -l  -> 30
<sarnold> Unit193: I hadn't seen that before, thanks.
<Unit193> sarnold: Yeeeeah, can drive you nuts.  Means someone didn't do packaging right. ;)
<pitti> Good morning
<pitti> stgraber: nice work on lxd!
<pitti> barry: yay for fixing pex!
<pitti> what a morning, so little stuff being stuck in -proposed :)
<barry> pitti: that was a fun one :)
<pitti> barry: eww @ bug 1485093, what on earth is that doing??
<ubottu> bug 1485093 in ubuntu-release-upgrader (Ubuntu Wily) "python3-distupgrade contains symlink to externally owned directory" [Undecided,New] https://launchpad.net/bugs/1485093
<barry> pitti: it's madness
 * barry really needs to go to sleep
<pitti> wgrant: hm, didn't get an export on https://translations.launchpad.net/ubuntu/wily/+language-packs -- did it crash or so?
<pitti> infinity: ^ FYI, langpack delay
<wgrant> pitti: Yeah, it died, apparently :/
<wgrant> pitti: Should I kick another one off now?
<pitti> wgrant: please
<infinity> pitti: Right, hopefully we get those soon. :P
<pitti> wgrant: a full export takes how long now? some 6 hours?
<wgrant> pitti: A little under four hours, usually.
<pitti> ah, good
<pitti> OMFG, is scalingstack lcy01 down *again*
<wgrant> Really?
<pitti> ERROR: HTTPConnectionPool(host='10.89.64.69', port=5000): Max retries exceeded with url: /v2.0/tokens (Caused by <class 'httplib.BadStatusLine'>: '')
<wgrant> It keeps running into some very unfortunate situations.
<pitti> it was shaky in the last few days already
<wgrant> haha you have no idea
<pitti> I got all kinds of weird errors
<wgrant> Junien should be around in a bit to sort it out.
<pitti> ah, did you already talk to IS? I was about to raise an RT
<sarnold> pitti: thanks for the postgresql updates
<pitti> sarnold: thanks for publishing them
<dholbach> good morning
<sladen> still a tad dull and wet here
<doko> roaksoax, look at python3-twisted-experimental. it has all the modules which should be supported in python3
<Saviq> morphis, ok so I still have trouble with BT on vivid/flo, it worked fine on first boot after flashing, but is gone after a reboot
<Saviq> morphis, had to run bluetoothd manually to get it back, pointers on which of the bluetooth{,-touch{,-flo}} upstart jobs should work?
<doko> mwhudson, the example was given to me by dobey. I just played around with it until it could be built.
<cking> is it possible for https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1491729, to sponsored, it's been waiting ~6 weeks
<ubottu> Launchpad bug 1491729 in dkms (Ubuntu) "[FFE]: dkms: add module build ordering for ZFS on Linux" [High,In progress]
<pitti> seb128, wgrant: yay, we have a wily export! /me turns the crank
<seb128> pitti, \o/
<Laney> \o/
<morphis> Saviq: I am currently setting up my flo to see if I can reproduce that
<morphis> Saviq: the bluetooth-touch-flo one should work
<morphis> does it fail to start?
<Saviq> morphis, I just rebooted, no BT indicator icon
<Saviq> morphis, but it seems like it actually works
<morphis> what does hciconfig -a say?
<morphis> does it list the hci0 device as up?
<Saviq> morphis, http://pastebin.ubuntu.com/12797827/
<Saviq> morphis, ok, it seems to actually be working
<Saviq> morphis, so the problem seems to be in the bluetooth indicator service that says it's not
<doko> tvoss, is mediascanner2 in -proposed still targeted for wily?
<morphis> Saviq: can you run /usr/bin/bluez-test-adapter ?
<tvoss> doko, need to dispatch, pstolowski is your friend
<Saviq> morphis, what command?
<morphis> Saviq: just /usr/bin/bluez-test-adapter
<Saviq> morphis, that just showed me a list of commands to run
<doko> tvoss, not here, which channel?
<Saviq> morphis, list said http://pastebin.ubuntu.com/12797849/
<morphis> looks good
<Saviq> morphis, but it took ~10s
<morphis> Saviq: so seems to be a problem with the indicator
<tvoss> doko, #ubuntu-touch
<morphis> Saviq: really?
<Saviq> morphis, well, maybe not 10
<Saviq> morphis, ah, it suspended
<Saviq> morphis, it's fine, device was just slow because suspended
<morphis> ok
<Saviq> morphis, ok so yeah, you're off the hook, indicator to blame
<morphis> through settings everything works?
<Saviq> morphis, yeah, and restarting BT indicator seems to fix it, too
<morphis> hm
<Saviq> morphis, will follow up with charles
<morphis> Saviq: can you check in .cache/upstart if there is a log file for the indicator?
<morphis> Saviq: btw. the indicator will change quite a bit with the BlueZ5 upgrade
<Saviq> morphis, there is one, but just one msg about rfkill
<morphis> Saviq: can you paste it?
<Saviq> ** (process:2132): CRITICAL **: rf_kill_switch_real_try_set_blocked: assertion '_tmp1_ != _tmp2_' failed
<Saviq> morphis, .1.gz had http://pastebin.ubuntu.com/12797881/
<Saviq> morphis, on reboot I got ** (process:2128): CRITICAL **: bluez.vala:104: Error calling StartServiceByName for org.bluez: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
<morphis> I saw that one before
<Saviq> and no BT icon
<Saviq> looks like a race maybe
<morphis> yeah
<morphis> and it doesn't find the adapter
<Saviq> indicator starts too early and doesn't try again later
<morphis> right
<Saviq> morphis, ok, that helps a lot, will file bug with i-b
<morphis> Saviq: before you file a bug
<Saviq> try BZ5
<Saviq> will do
<Saviq> later today
<morphis> exactly
<morphis> if that doesn't work too, then we need to file the bug
<Saviq> ack
<morphis> Saviq: if you file please add the tags "bluetooth" and "bluez5"
<Saviq> kk
<doko> apw, cking, zfs-linux on ppc64el is an acute schizophrenic mood about it's endianess ...
<cking> doko, yup, thanks, I'm aware of this bizarre schizomode
<Odd_Bloke> I'm looking at python-taskflow; it Depends on a bunch of things that provide optional behaviour; if I wanted to trim some of these dependencies out, can I just demote them to (Recommends|Suggests) and test core functionality works without them installed, or do I need to do something more complex?
<rbasak> Odd_Bloke: it's pretty normal in Ubuntu to do what you described when the dependencies are in universe.
<rbasak> Odd_Bloke: it's common for python packages to build-depend on most of their dependencies so that tests can be run as part of the package build; you might need to check those too.
<rbasak> This is assuming that there's no other need to keep the functionality you're dropping, of course.
<Odd_Bloke> rbasak: Would having all the packages in Build-Depends but then as (Recommends|Suggests) in the binary package be a problem?
<Odd_Bloke> Oh, it might be a problem for main inclusion down the line.
<Odd_Bloke> I missed the 'build and' in "All build and binary dependencies (including Recommends:) must be satisfyable in main".
<Odd_Bloke> Oh, no, python-taskflow is already in main.
<rbasak> Odd_Bloke: what are you actually trying to do?
<rbasak> Odd_Bloke: fix a component mismatch or something else?
<Odd_Bloke> rbasak: We're considering python-taskflow as a cloud-init 2.0 dependency; as things stand, installing it increases image size by ~50MB.
<rbasak> I see
<rbasak> I think it's an openstack dependency too
<rbasak> Probably worth having a look for other reverse deps
<rbasak> As long as every consumer is happy I see no issue in trying to slim it down
<Odd_Bloke> OK, cool.
<Odd_Bloke> ATM I'm just trying to get a sense of how small a footprint it could have, and work out if we're happy with that.
<Odd_Bloke> But didn't want to do so in a way that couldn't possibly fly in the archive. :)
<doko> pitti, jamespage: looks like you didn't merge the debian packaging for mongodb?  don't see why google-perftools should be an arch-specific b-d
<jdstrand> pitti: hey, curious if otoh you know why if I'm building in a schroot I sometimes, but not always, see http://paste.ubuntu.com/12799014/
<jdstrand> pitti: google didn't help me. if you don't know otoh, don't bother wasting time
<jdstrand> it is weird though. cause I tried to build something, it failed with that. I do nothing else and try again, and it works
<jdstrand> this has been happening for a while now. not a new thing
<pitti> jdstrand: I think I've seen it in some bug report, but no clue I'm afraid
<pitti> jdstrand: stracing dpkg might help, if you can reproduce it
<jdstrand> pitti: normally I just update the schroot so it doesn't have to upgrade that package during a build
<jdstrand> pitti: thanks
<pitti> jdstrand: ah
<pitti> jdstrand: might be an overlayfs bug?
<pitti> jdstrand: I use tarball schroots, but I've never seen this in my sid schroot (which is overlayfs) either
<jdstrand> oh
<jdstrand> why yes: http://paste.ubuntu.com/12799337/
<pitti> jdstrand: go overlayfs :)
<pitti> doko: maybe; I fixed an FTBFS during the g++ migration, but that doesn't mean that I now take over maintenance of this :)
<hallyn_> xnox: ping
<hallyn_> (re https://mentors.debian.net/package/netcf)
<xnox> hallyn_: yes.
<xnox> hallyn_: again, new, or did i not do an old one?
<xnox> ah new upstream release
<seb128> mvo, hey, do you know what app-install-data-partner is used by/for?
<seb128> it didn't get updated since 13.04 it seems
<mvo> seb128: its so that the stuff in the canonical partner archive has icons and can be installed
<seb128> mvo, is there a process to refresh it? should that be done or did the data not change since raring?
<mvo> seb128: I think it should get updated - or we just drop it given that its not well maintained
<seb128> mvo, is the process to update it documented?
<hallyn_> xnox: yeah, you'd looked at it a few days or weeks ago (time flies) but at EOD
<hallyn_> xnox: the experimental version still FTBFS so ideally this version would just repalce it without a need for a separate fix
<roaksoax> doko: yeah I saw that, but that made me ask the question. We were hoping on moving be moving to python3 in MAAS, but the experimental part of twisted makes us wonder whether this is a blocker or not
<doko> roaksoax, just pretend that you don't see it. I introduced that some years ago
<doko> waiting for free to package 15.4, and then build both python packages from the same source
<roaksoax> doko: ok, cool!
<mvo> seb128: its manual unfortunately
<mvo> seb128: no automatic update script or anything, it used to be such a small number of packages that it was not worth automating
<infinity> pitti: Any idea what's up with the systemd and apport failures?
<xnox> hallyn_: is this upload to experimental or unstable then?
<seb128> infinity, he wrote that earlier about the apport one
<seb128> <pitti> seb128: I just saw it failing, no idea yet; appareantly some changes on ddebs.u.c.
<seb128>  seb128: I hinted it for now, will look when it's not release crunch time
<hallyn_> xnox: unstable
<xnox> hallyn_: cool.
<hallyn_> xnox: that'll then automatically supersede the (older) experimental version right?
<xnox> hallyn_: si
<hallyn_> awesome - thanks
<infinity> seb128: Ahh, indeed, he did force apport.  I'll see if a systemd retry clears that one up.
<pitti> infinity: apport> ah, seb128 already quoted
<pitti> infinity: I retried systemd, that looks like a race condition in the test
<pitti> infinity: I already did
<pitti> infinity: the queues are achingly long again; I requeued all regressions already
<pitti> infinity: but with lcy01 down again it's going to take a fair while :/
<infinity> pitti: Oh.  Yeah.  I retried too.  Not helpful, I guess.
<pitti> infinity: so we only have 8 parallel tests now, which sucks :( (on x86)
<infinity> pitti: And two GCC uploads means the queues will explode shortly.
<infinity> Oh, Qt too.
<infinity> Yay.
<pitti> infinity: nope, I tamed gcc
<infinity> pitti: Tamed how?
<pitti> amd64 queue is 288, i386 queue 243
<pitti> infinity: gcc-5 only triggers some 5 key packages now, and stuff like gcc-4.7 doesn't trigger anything at all
<infinity> pitti: libgcc1 rdeps don't trigger anymore?  Doesn't that sort of defeat the purpose of autopkgtest?
<pitti> infinity: the 5 key pakcages includes some libgcc rdepends
<pitti> infinity: but there's actually not that many in main
<infinity> pitti: Sure, but how can we be sure it's good coverage?
<infinity> I mean, libgcc isn't as complex as libc, but there's still a fair bit that can, in theory, go wrong.
<pitti> so, we need to know that libgcc1 isn't totally broken, for that running 10 tests or so is sufficient
<pitti> infinity: well, give me some actual horsepower and we can switch it back on
<infinity> pitti: Did you have more horsies before the scalingstack move?
<pitti> infinity: well, at least two regions, i. e. 2x8
<infinity> pitti: Were any of your build machines suitably new/beefy enough that we could ask for them to be turned into scalingstack compute nodes?
<pitti> infinity: I hope lcy01 comes back up soon; the last time (a month ago or so) it lasted for a full week, which sucked
<pitti> infinity: I got promised a bunch of beefy nodes a while ago, but didn't get them yet
<pitti> anyway, /me -> back to real life, this was just a quick drive-by check if anything completely exploded
<pitti> but http://autopkgtest.ubuntu.com/status/alerts/ looks okay
<pitti> and not too many regressions
<pitti> so, let's let it clear up over night/saturday
 * pitti waves
<luist> what Qt version is coming in 16.04?
<dobey> lol
<dobey> whatever version is ready by the time the freeze happens
<infinity> luist: At least 5.4 :P
<jcastro> If anyone has time to help with: https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498655 and https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498658 that would be swell!
<ubottu> Launchpad bug 1498655 in steam (Ubuntu) "Steam Controller support: need read-write access to Valve-owned input event device nodes." [Undecided,Confirmed]
<ubottu> Launchpad bug 1498658 in steam (Ubuntu) "Steam Controller support: need read-write access to /dev/uinput for controller emulation" [Undecided,Confirmed]
<jcastro> bzr branches are attached
#ubuntu-devel 2015-10-17
<Laibsch> I'd like to fix #1245041 and to do so I need to SRU for trusty.
<Laibsch> When doing that I will introduce a Ubuntu delta.  Should I change the Maintainer to XSBC-Original-Maintainer?
<Laibsch> Would some kind soul please accept nomination for trusty for bug 1245041 and if possible even move along the SRU?
<ubottu> bug 1245041 in mysql-workbench (Ubuntu) "mysql-workbench-bin crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] https://launchpad.net/bugs/1245041
<Laibsch> Sorry, wrong bug number
<Laibsch> bug 1287424
<ubottu> bug 1287424 in mysql-workbench (Ubuntu) "Cannot install mysql-workbench with mysql-server 5.6 or mariadb" [High,Fix released] https://launchpad.net/bugs/1287424
* infinity changed the topic of #ubuntu-devel to: Archive: final freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2015-10-18
<Laibsch> Would some kind soul please accept nomination for trusty for bug 1287424 and if possible even move along the SRU?
<rbanffy> Hi folks. How is the usual process of packages trickling down from source to stable distribution? Every time I make changes to https://github.com/rbanffy/3270font I tell the Debian font team, who, in turn, say they'll reflect them. The package then goes from Debian repo (https://packages.debian.org/sid/fonts/fonts-3270) to all Debian-like distros (Ubuntu, which I use, included)
<hjd> rbanffy: Hi. Ubuntu usually sync new packages from Debian unstable to the current Ubuntu development release. Exceptions are if the package has some ubuntu-specific patches (you can tell if the version number contains "ubuntu") in which case someone need to manually merge it, or when it is late in the development cycle when the automatic import has stopped in order to not have too many changes before release.
<hjd> For instance, for Wily Werewolf, packages were automatically synced up until August 20th (https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule). It is of course possibly to request syncs at a later point though.
<rbanffy> Thanks, hjd.
<rbanffy> hjd, I guess the next sync will be for wily+1 then.
<rbanffy> In any case, byobu users who use mu font (all three of them, me included) will be happy to know I added a â« in late May.
<infinity> rbanffy: If you ask nicely (and assure me it won't break), I can sync it to wily.  There's still time.
<rbanffy> infinity, I am pretty sure it won't. All 1.2.4 fixes (1.2.3 is on Sid) is Windows compatibility.
<infinity> rbanffy: If you're sure the sid/testing version is cool, we can sync it.
<rbanffy> I'm cool with it. My main machine uses it built from "source".
<infinity> rbanffy: Done.
<rbanffy> Maybe it's time to release again. I added a couple glyphs and fixed some hinting issues.
<rbanffy> I'll take it for a spin on Wily. Thanks, infinity.
<nadrimajstor> I'm trying to triage a bug for 14.04 and I found an SRU proposed change that targets Vivid that contain upstream bug fix.
<nadrimajstor> Should I add a comment to the Vivid's SRU bug asking for additional release target to be added?
<hjd> infinity: Hm... I actually didn't know it was still possible to sync packages this close to release.
<tsimonq2> hm, if a package is submitted to Debian, will it make it's way to Ubuntu no matter what?
<cyphermox> No, it needs to be synced or merged manually, from now until release.
<tsimonq2> cyphermox: but if I upload it now, after the release will it filter down?
<cyphermox> Yes
<tsimonq2> cyphermox: so every Debian package is in Ubuntu?
<tsimonq2> or the Ubuntu servers, rather
<cyphermox> You can still have it in Ubuntu for the release if it lands in Debian and you ask for it to be synced
<cyphermox> Pretty much every debian package is in Ubuntu yes
<tsimonq2> pretty much?
<tsimonq2> obsoleted packages maybe?
<tsimonq2> cyphermox: ok, thank you
<cyphermox> There are some few exceptions for things that would be replaced by a package with a different name or things that are just for architectures we don't support, IIRC. You don't need to worry about it for your package, I'd think :-)
<tsimonq2> ok :)
<tsimonq2> cyphermox: and on average, how long does it take to filter downstream? right away if it is not near a release?
<cyphermox> Depends on the schedule, right away if it's during the time we do automatic imports, except if there are changes in Ubuntu's version of the package at the time, otherwise there are some manual steps (merging, or requesting a sync)
<tsimonq2> ok :)
<tsimonq2> thank you
<JanC> there are also Debian packages that have different packaging in Ubuntu, I think, in which case the original Debian package wouldn't be there?  (at least there used to be)
<tsimonq2> JanC: Explain please
<JanC> tsimonq2: there used to be applications that were packaged independently by both (so two developers making a different packaging); but AFAIK Ubuntu policy is not to do that unless it's *really* *really* necessary for some *very* *good* reason  :)
<tsimonq2> ok :)
<cyphermox> Yep
<JanC> and some years ago there was some work done to remove those, but I'm not sure how many are left
<JanC> I guess the kernel is one of them
<hjd> I don't see any patch pilots, but if someone wants to do a small code review for Wily, there's  bug 1507295 :)
<tsimonq2> what Debian version is Ubuntu based off of?
<mitya57> It's unstable.
<tsimonq2> ok, thanks
<jtaylor> 16.04 is going to be testing right?
<mitya57> jtaylor, IIRC we are nowadays using unstable for LTSes too
<mitya57> (as we have smart proposed migration which will catch issues)
<cjwatson> jtaylor: As mitya57 says, no, unstable.  I explained this at more length the other day.
<cjwatson> jtaylor: The last LTS to sync from testing was 12.04.
#ubuntu-devel 2016-10-17
<pitti> Good morning
<sladen> pitti: Morgen
<pitti> happyaron: hey, how are you?
<pitti> happyaron: are you planning on merging NM with Debian? updating to 1.4 should get us rid of our biggest patches, and then we should review the Ubuntu patches to see which we can get rid of in the long term
<pitti> happyaron: I'll forward the "config from /run" ones to upstream today
<cpaelzer> good morning
<xnox> gatwick is stuck cleaning
<happyaron> pitti: yes of course I want to merge with Debian
<happyaron> ty for forwarding it!
<pitti> happyaron: great, thanks
<pitti> happyaron: looking forward to losing the giant ofono patches :)
<happyaron> pitti: yup, :)
<tjaalton> does errors.ubuntu.com force logging in before seeing the trace?
<tjaalton> trying it out on a blank browser profile would suggest so
<tjaalton> makes it useless for upstreams
<pitti> tjaalton: we collect/upload these on a wide scale mostly automatically, they might contain private information
<tjaalton> ok, well pastebin isn't far away.. so nevermind
<tjaalton> hmm, wonder if there could be a way to not send crashes to errors.u.c if ppa's are being used, or mainline kernels
<pavlushka> cpaelzer: ping
<pitti> a
<cpaelzer> pavlushka: Ã¼ong
<cpaelzer> pavlushka: Ã¼ is too close to p when coming back from lunch - should have been pong :-/
<pavlushka> cpaelzer: I have added the details needed to LP bug 1629038, please take a look.
<ubottu> Launchpad bug 1629038 in samba (Ubuntu) "package samba 2:4.3.11+dfsg-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,New] https://launchpad.net/bugs/1629038
<pavlushka> cpaelzer: ok I should have pinged you in #ubuntu-bugs, next time :)
<cpaelzer> pavlushka: fine for me - I have the tab open and will take a look before EOD
<cpaelzer> pavlushka: how long would you be around in case I have further questions?
<pavlushka> cpaelzer: can't assure about power/Internet-link (if it goes down), otherwise I will be available :)
<pitti> happyaron: btw, the two debian/patches/Read-* patches won't apply to 1.4; I have them ported to 1.4 on the upstream patch already, so please don't waste time on those
<happyaron> pitti: wow great!
<BlackJohnny> hi
<BlackJohnny> i have a problem with ubuntu skd after upgrading to 16.10 ... if anyone can help with the following pls let me know
<BlackJohnny> it seems that this command fails usdk-target autosetup -y
<BlackJohnny> with the error rror: open /etc/default/lxd-bridge: no such file or directory
<BlackJohnny> this command is executed when I try to start the IDE
<BlackJohnny> probably some initial configuration scripts
<smoser> are we able to upload to zesty yet ?
<infinity> smoser: No.
<nacc> rbasak: is LP: #1632907 a known mysql issue?
<ubottu> Launchpad bug 1632907 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.15-0ubuntu0.16.04.1 failed to install/upgrade: å­è¿ç¨ å·²å®è£ post-installation èæ¬ è¿åéè¯¯ç¶æ 1" [Undecided,New] https://launchpad.net/bugs/1632907
 * rbasak looks
<nacc> rbasak: thanks
<rbasak> nacc: I think that's a system misconfiguration. The postinst failed because update-rc.d failed, because insserv failed complaining about "insserv: script mysql: service mysql already provided!".
<rbasak> I've certainly never seen that, anyway. Need steps to reproduce to consider it not a misconfiguration, IMHO.
<nacc> rbasak: ack, thanks
<nacc> sarnold: is there a preferred launchpad method to bring a bug to the attention of the security team in case of a regression due to a CVE fix?
<rbasak> yakkety-proposed still contains 1.7~git20160703+dfsg-1 that never migrated for good reasons.
<rbasak> But users may now have -proposed enabled because Yakkety is released.
<rbasak> That sounds like a problem to me, unless I'm mistaken? Should we be clearing out -proposed before release?
<rbasak> (my example is src:heimdal, sorry)
<cjwatson> rbasak: The usual practice is that once we have a usable zesty-proposed (etc.) then we copy everything to that and delete from yakkety-proposed.
<cjwatson> I think just deleting would make it hard to keep track.
<rbasak> cjwatson: thanks, but isn't that a problem with the process then?
<rbasak> Because that then leads to bug 1633653, for example, where a user who has proposed enabled is upgrading from Xenial to Yakkety. And we want to encourage that.
<ubottu> bug 1633653 in heimdal (Ubuntu) "package libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 failed to install/upgrade: package libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 cannot be configured because libhcrypto4-heimdal:i386 is at a different version (1.7~git20150920+dfsg-4ubuntu1)" [Undecided,Confirmed] https://launchpad.net/bugs/1633653
<cjwatson> rbasak: I find it hard to care, given that having -proposed enabled is always for the adventurous.
<cjwatson> Maybe there's some way to improve it, I just don't see it as especially urgent.
<cjwatson> It might be possible to delete, but somebody would have to keep a list ...
<mapreri> a way to improve it would be for sabdfl to announce the new series name before the release, so they can be copied at release time?
<rbasak> I'd like to encourage people to volunteer to test proposed and report bugs in it (for stable releases). That helps us with SRU verification. But in that case, we should ensure (IMHO) that our processes don't leave them broken unnecessarily.
<rbasak> Otherwise we'll put people off testing proposed, and I want the opposite.
<nacc> smb: cpaelzer: any chance you could peek at LP: #1633207? Should that be supported?
<ubottu> Error: Could not gather data from Launchpad for bug #1633207 (https://launchpad.net/bugs/1633207). The error has been logged
<rbasak> I filed bug 1634201
<ubottu> bug 1634201 in Ubuntu "Release process leaves stable -proposed with broken packages, breaking users who volunteer to test stable -proposed for SRU verification purposes" [Undecided,New] https://launchpad.net/bugs/1634201
<rbasak> powersj: do you want to dupe those into this bug?
<powersj> rbasak: shoot I already merged them into the one you called out.
<rbasak> Ah, sorry. That's slightly different possibly, because users shouldn't have proposed enabled in a development release at all, but may have it enabled in a stable release for testing pending SRUs.
<powersj> rbasak: shall I move them to that one?
<rbasak> Please, if they filed after Yakkety was released.
<powersj> all submitted on the 14th, so I will
<rbasak> Thanks!
<cpaelzer> nacc: out of the blue I don't know
<cpaelzer> nacc: would have to check the doc/sources to answer that
<nacc> cpaelzer: thanks
<infinity> rbasak: I think we can improve on this for next time, actually, based on a tool Andy's working on for me.
<infinity> rbasak: Not much I can do about it this time, though. :P
<rbasak> That sounds good. Yeah sure, this time it's clearly easiest to clear out proposed the usual way once the new series is ready. I'm only raising it because it seems like a recurring broken thing, rather than a one-off.
<nacc> smoser: have you seen LP: #1633453 ?
<ubottu> Launchpad bug 1633453 in cloud-init (Ubuntu) "ssh is started before cloud-init completed" [Undecided,New] https://launchpad.net/bugs/1633453
<nacc> rbasak: smoser: https://git.launchpad.net/~nacc/ubuntu/+source/memcached
<nacc> just re-pusehd there, with changelog entries on each import
<nacc> e.g. https://git.launchpad.net/~nacc/ubuntu/+source/memcached/commit/?h=ubuntu/devel
<smoser> nacc, i think that looks good.
<smoser> i responded to that bug
<nacc> smoser: thanks
<smoser> i have a question on importer
<smoser> nacc,
<smoser> so maybe im'just missing something
<smoser> but you seem to really, really want to never change things to break shas
<smoser> (ie, you want to get this change in before "settling")
<smoser> is there a big reason behind that ?
<nacc> reproducible imports
<smoser> i think it inevitable that at some point you'll want to change something and future imports will nto be identical
<smoser> i agree with the goal for sure.
<nacc> smoser: we're discussing move to ubuntu-server-dev
<nacc> smoser: right, and if we do that, we re-import everything
<nacc> smoser: i'm tryign to minimize how often we'd do that :)
<smoser> why would you re-import everything?
<nacc> so that a new user would be able to push if they did a local import
<nacc> the shas need to match for that tow ork
<nacc> *work
<smoser> but what is that use case ?
<smoser> you want to have no access to the previously-imported tree, and run your import and then push over the previously improted tree that others have used for things.
<smoser> i think i'd just not do that.
<nacc> i believe the primary use case was for packages we had not imported
<nacc> it was never in scope to replace UDD fully
<nacc> so this will only ever cover the small set of packages the server team cares about
<nacc> at least officially
<smoser> i'm confused for sure.
<smoser> i suspect i'm just missing something.
<nacc> so let's say you're joe user and want to import locally some package that's not been imported to ubuntu-server-dev
<nacc> i guess we don't need to re-import, necessarily
<nacc> smoser: i'm mostly trying to minimize how often the shas can change
<nacc> smoser: you're right, there may be future cases where they will, we'll need to consider that then
<smoser> and that makes sense
<nacc> smoser: but changing all the import/ commit messages was a pretty obvious broad change, and was a godo fix
<nacc> *good
<smoser> but i just think at the point in which you publish to anywhere (ubuntu-server-dev) then i clone, i make a change locally.... if you re-import at that point, i'm broken.
<nacc> smoser: right, that's why ntohing is publisehd to ubuntu-server-dev yet :)
<smoser> so i'd suggest that in that scenario, we basically continue on with what was originally in ubuntu-server-dev
<nacc> smoser: i'm willing to concede we won't need to rewrite published git trees
<smoser> unless it is deemed more important to fix that tree than to break users.
<nacc> smoser: we use teh tree contents everywhere, and right now, nothing changes those
<nacc> smoser: so the only time we'd need to re-import, i think, is if all the tree hashes were to change, which seems unlikely as they come from the source pacakges
<smoser> yeah.  changing hashes is a pita for sure.
<smoser> ok. i just wanted to make sure i wasn't missing something more intrinsic than i thought.
<nacc> smoser: no, it's nothing intrinsic, afaict -- it was a requirement from the sprint docs, mostly
<nacc> rbasak may be able to speak to it better
<rbasak> smoser: I think it's a nice property that the imports are reproducible. It allows, for example, for a third party to prepare something locally, then submit an MP, and then to official import it, and then it'd just merge in.
<rbasak> smoser: however, I accept that we may need to break it at some point. Then in that scenario you'd have to rebase. That's just something that would be nice to avoid if possible, that's all. Not the end of the world if we can't maintain the property, but everything is cleaner if we can. Sort of like epochs in version numbers.
<smoser> rbasak, right.
<smoser> but in the event that you've published something publicly , it seems more likely that you'd want to keep the published thing than re-import it.
<rbasak> smoser: agreed.
<smoser> good.
<smoser> so since we'r'e here...
<smoser> the goal is to drop the usd-import-team repos ?
<smoser> is that right?
<rbasak> smoser: if we made a note of when this happened though, we might even be able to keep the public trees reproducible by using previous importer revisions from git history
<rbasak> I believe so, yes.
<smoser> ok. cool
<rbasak> If nacc agrees?
<rbasak> That's my understanding, anyway.
 * rbasak needs to go
<nacc> rbasak: smoser: yes, hopefully very soon
<nacc> rbasak: smoser: and import fresh into ubuntu-server-dev
<nacc> jgrimm: fyi, running a test import of the pacakges from your list with the newest importer
<nacc> rbasak: i think, if these imports go through w/o error, i'm ready to mark this as 1.0 and switch to annoted tags?
<jgrimm> nacc, great!
<nacc> smoser: given the importer isn't really running as a real user, it doesn't make sense to sign annotated tags, does it?
<smoser> nacc, well i dont think that "as a real user" indicates "should not sign"
<smoser> as lots of machines sign things.
<smoser> if the importer were running on a system and ahd access to a key we wanted to let it sign things with, it might make sense.
<nacc> smoser: what e-mail address is the key tied to in those cases?
<smoser> well, an example is the ubuntu-cloudimage-keyring
<smoser> http://paste.ubuntu.com/23340540/
<nacc> ah a -noreply address?
<nacc> smoser: so e-mails sent there, in theory, get bounced?
<nacc> smoser: probably not a big deal for us either way, i'm just wondering if we want to direct importer queries always to the server ML or something
<smoser> i think probably jsut dev/null
<smoser> i dont know.
<nacc> smoser: and where did you generate that key, etc?
<smoser> i dont know how that particular key got generated, i think probalby utlemming did it... i might ask slangasek or cjwatson about best practices on such a thing.
<smoser> i believe we could add that later though, right ?
<smoser> (especially given a reproducible hash mechanism :)
<rbasak> What if we sign (as an option) by the user who ran the command?
<nacc> smoser: yeah, but we want to sign tags, i believe, which would change all the tags
<nacc> rbasak: yeah, i was thinking of adding a -k option
<nacc> rbasak: then we can figure out what key to use at runtime (or decide later)
<nacc> rbasak: are we ok with historical tags being unsigned?
<rbasak> Then when pushing to an official place, sign yourself, even if just our individual keys.
<smoser> i think signing does not actually change hashes
<rbasak> Then the only open question is what cron should do
<smoser> does it?
<smoser> you can sign stuff later
<rbasak> Only of the tag itself.
<nacc> smoser: it creates a different tag object, aiui
<smoser> ah. right.
<rbasak> If you replaced a tag (eg. by signing it) then the tag would change, but I don't see how that would break anything for anyone.
<smoser> right.
<nacc> rbasak: that's true, the pointed-to object is the same
<nacc> sorry, i'm being overly cautious about any changes :)
<rbasak> If the annotation said what version importer was used (eg. git describe output), then a tag signed by an Ubuntu uploader would be nice. Other uploaders would perhaps be able to trust that rather than having to check against the archive.
<nacc> that's a good point
<rbasak> I wonder if that needs a chain of signed tags for full trust though, in which case perhaps signed commits would work better.
<utlemming>  smoser: correct, that key was generated by hand and then I got it signed
<utlemming> smoser: I don't really remember all the details other than that is what I was told to do
<nacc> heh
<nacc> rbasak: yeah, i'll admit my key-knowledge is limited, so i'm not sure if there is already a trusted chain we should be using (by default) in the importer to recognize keys, etc
<nacc> rbasak: so i think we're ok with not signing the tags for now, i can add the functionality to pass a key down to git-tag (-u option)?
<nacc> rbasak: as this feels like a policy decision, on some level
<rbasak> nacc: that sounds fine. If we decided that commits should be signed, then we'd need to add support for that separately I think.
<slangasek> smoser, nacc: I don't know about best practices, you'll find that the Ubuntu archive key lists 'ftpmaster@ubuntu.com' but I'm not sure if anyone currently receives/reads that mail
<nacc> rbasak: ack, do we still want to annotate them unsigned?
<nacc> slangasek: ok, thanks!
#ubuntu-devel 2016-10-18
<nacc> smoser: would you happen to have a guide/info on ensuring that when the annotated tag says 'imported using v1.0' where 1.0 is in our source tree, that it actually is 1.0? I mean, I could use a version file generator, but then that's a static file in the git tree. Presuming one is always running from the git tree, I coudl use `git describe`, but that won't work if running from, e.g., the snap. Or if
<nacc> someone (maliciously or accidentally) were to use a released tarball (if we had them) and edited the version file. Or made changes from the released version, and we wouldn't want to indicate it's actually 1.0
<nacc> smoser: or really, i'm looking for advice for how to include the importer's version (which itself would be an annotated tag in the importer's repository) in the tag
<nacc> barry: --^ maybe you'd have some pythonic insight here too
<nacc> smoser: barry: http://paste.ubuntu.com/23341473/ this is what i did locally, and you can see i've tagged (to test) it as 1.0. So then the importer invocation picks up the version from `usd-import`'s git repository. But not sure if that always will work? But I think it might be an appropriate way to feed the version in if we rework the various usd- into usd/ modules
<Bluefoxicy> Does anyone know if this is what's causing the issues with Evolution and Google Calendar on 16.10?  https://bugzilla.redhat.com/show_bug.cgi?id=1373737
<ubottu> bugzilla.redhat.com bug 1373737 in evolution-data-server "Evolution reports quota exeeded for Google calendars every morning" [High,Closed: nextrelease]
<smoser> nacc, i dont know that there is really any ay to do what you're asking.  I think what you're asking equates to drm or trusted computing.
<smoser> wrt getting git-describe into some place where you're running not from git, i ended up giving up in cloud-init.
<smoser> i had a way to do it, but then my source tarballs differed from the git code that they represented (by one having 'git describe' in a file and one not).
<smoser> and gbp didn't like that, and i decided rather than fighting it i'd accept it.
<nacc> smoser: yeah it feels non-trivial all of a sudden; what i have works i think if running from git
<nacc> smoser: and we'd just add something to extract it from a file if that fails for released/snap'd versions?
<smoser> yeah, i just gave up
<smoser> i think its not really worth it.
<smoser> i dont think you can trust anything other than an official importer honestly.
<smoser> or dont think the effort is worth the gain.
<nacc> smoser: ack, it might not be -- so is cloud-init's version hardcoded in the source? and if someone uses a hacked version, you'd not notice?
<nacc> yeah
<smoser> just don't let someone else run.
<smoser> in cloud-init's source, it only now says '0.7.8'
<smoser> the 'make tarball' used to append to that the full git describe version
<smoser> which was nice, and then when running from package, you'd get that
<smoser> you'd get that info in a log
<smoser> but i just gave up.
<nacc> yeah, it seems like most people use release processes to do this
<nacc> and even then, seems like a half-solution
<nacc> ok, i'll stop trying any harder at this, then :)
<nacc> smoser: thanks, have a good night!
<smoser> the thing that i just didn't like... was that the source tarball had different data than the git checkout of the tag.
<smoser> which was just obnoxious both as a "cleanliness" thing and also from other tools like gpb that cried foul.
<rbasak> nacc: yeah I think that's fine
<pitti> Good morning
<cpaelzer> good morning
<Mirv> err, " format '3.0 (quilt)' is not permitted in zesty."? (PPA upload)
<pitti> well, "zesty" does not exist yet in the first place? https://launchpad.net/ubuntu/
<Mirv> oh, right, I didn't check it anymore since bileto enabled zesty :) robert was too fast.
<pitti> not exactly the most obvious error message too :)
<sarnold> nacc: normally I'd say pass the bug number along to whoever did the update, but this week email to security@ubuntu.com is probably more reliable
<Mirv> heh, zesty now created, the next obvious error message on PPA uploads is "Cannot build any of the architectures requested: any all
<Mirv> but 3.0 (quilt) source format is fine now! :)
<pitti> Mirv: haha
<highvoltage> http://community.ubuntu.com/release-widget/ may require some maintenance
<Unit193> highvoltage: You tried py3 speedtest-cli, btw?
<highvoltage> Unit193: funny you should mention that, I spent a few minutes this morning trying to figure out some speedtest-cli performance related problems. I think it might stem from speedtest moving all their primary clients to just using sockets and they don't care about the http clients anymore
<highvoltage> Unit193: speedtest-cli does work in python3 though, and doing some quick tests it seems to be giving me closer results to the official client
<Unit193> highvoltage: Well that's crappy..  Yeah I tested a "port" of the packaging, only noticed a little oddity in the output.
<Unit193> Interesting about being closer though.
<highvoltage> Unit193: yep, ideally there would be a free speedtest community with its own servers and clients, but we're getting firmly into the off-topic zone for this channel :)
<seb128> bdmurray, pitti, rbasak, commented back on bug #1580740 the static version included in the xenial upload is noise, the makefile generates that file at buildtime
<ubottu> bug 1580740 in Snappy "[SRU] Cannot open a browser link from a snap that provides a link" [High,Triaged] https://launchpad.net/bugs/1580740
<seb128> yakkety is fine
<bdmurray> seb128: thanks, I've released it
<seb128> bdmurray, thanks
<smoser> slangasek, you reverted xenial for bug 1621507. i think you should revert yakkety also.
<ubottu> bug 1621507 in initramfs-tools (Ubuntu Yakkety) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<slangasek> cyphermox: ^^
<cyphermox> yes, I am aware, working on it
<smoser> cyphermox, you'll revert it? or you're planning on just adding another fix first
<smoser> i think yakkety should be reverted, and fix should go first to zesty
<tsimonq2> infinity: Are you aware that Lubuntu Xenial Daily is FTBFS due to a kernel dep issue?
<infinity> tsimonq2: It's transient.
<tsimonq2> Whoops, meant to put that in -release.
<tsimonq2> infinity: Ok thanks
<cyphermox> smoser: I'll revert it
<nacc> smoser: would you say if the importer was going to be python3 only (which it is), it's worth going through and putting in type-hinting?
<smoser> i have no experience with type hinting.
<nacc> smoser: ok, i was just looking at it -- might ensure some things get caught earlier, and it seems like good documetnation
<jgrimm> nacc, oh.. i read a good artice on that last week.. apparently some python 2 support for it too via mypy  ->  http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/
<nacc> jgrimm: nice
<nacc> jgrimm: yeah, our code isn't complicated, but i think adding the hints will simplify maintenance
<jgrimm> adn usd-* seems like small enough project to try out even.
<nacc> jgrimm: 100% ack
<nacc> jgrimm: esp. as i'm looking at seeing if we can organize the code a bit better before 1.0, just to make it easier to read :)
<jgrimm> :)
#ubuntu-devel 2016-10-19
<pitti> Good morning
<Mirv> pitti: did you get the "net/http: request canceled while waiting for connection" solved that you had? there's one person who continues to have similar problem.
<Mirv> using snap
<pitti> Mirv: err, what/
<pitti> ?
<pitti> Mirv: that must be a different Martin :)
<Mirv> pitti: https://irclogs.ubuntu.com/2016/08/30/%23snappy.html#t08:41
<pitti> oh, that has been a while ago -- I filed that as bug 1618206
<ubottu> bug 1618206 in snapd (Ubuntu) "snapd.refresh.service fails after installation, missing Requires=snapd.socket" [High,Fix committed] https://launchpad.net/bugs/1618206
<pitti> Mirv: but that was a different error
<mwhudson> is there anyone here i can talk to about wifi/nl80211 arcana?
<shadeslayer> Hi, so I'm trying to write a new python apt template, but I'd like to have multiple base uri's, is that possible?
<mwhudson> is there anyone here i can talk to about wifi/nl80211 arcana?
<pitti> cking: re-running linux locally on my system; if that works, I'll re-run it on the infra (that's still a bit busy right now due to several kernels and zesty)
<cking> pitti, cool, let me know if it breaks!
<LocutusOfBorg> mwenning, you can try ask me, but I doubt I can answer
<sarnold> LocutusOfBorg: mwhudson perhaps?
<mwhudson> LocutusOfBorg: i figured it out i think
<LocutusOfBorg> yes :)
<mwhudson> (you can identify the NL80211_CMD_GET_SCAN reply that corresponds to the AP the interface is associated with by looking for/at the NL80211_BSS_STATUS attribute)
<mwhudson> well not "the" reply, pedantically
<pitti> sil2100: what does the "failed to merge" on https://bileto.ubuntu.com/#/ticket/1710 want to tell me? I see no recent followup to https://code.launchpad.net/~ted/indicator-network/systemd-unit/+merge/300443 , can this be reset somehow?
<pitti> sil2100: oh, nevermind, I see it in https://bileto.ubuntu.com/log/1710/build/latest/ (conflict)
<pitti> robru, sil2100: FYI, all zesty bileto tests fail because the overlay PPA does not have zesty indexes; I am copying a package to zesty (and will remove it again later) to fix
<doko> sil2100: is telepathy-ofono still used by the phone?
<pitti> cking: "ubuntu-regression-suite FAIL non-zero exit status 253" â no time out, so at least back to the "normally" broken state; thanks for the hang fix!
<pitti> cking: I'll retry on the infra, and then update the bug
<sil2100> pitti: oh, thanks!
<sil2100> doko: yes
<pitti> sil2100: ah, http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/dists/zesty/ exists now, great
<doko> sil2100: please forward https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1634869
<ubottu> Launchpad bug 1634869 in telepathy-ofono (Ubuntu) "telepathy-ofono test failures on armhf and arm64" [High,Confirmed]
<sil2100> doko: ACK
<doko> xnox: boost transition, or "just" a new version?
<xnox> doko, new version and then transition.
<xnox> trying to clean up remains of boost1.61 at the moment
<doko> xnox: so just start with it?
<xnox> i think i will be requesting demotion to -proposed / removal of some arch builds for a few packages to kill off boost1.60
<xnox> doko, well i don't know if boost1.62 builds everywhere for us.... if boost1.62 is built and migrates, I could upload boost-defaults as well.
<doko> well, lets build openmpi first ...
<rbasak> dannf: around? I don't see smb here. Please see https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1627926/comments/9
<ubottu> Launchpad bug 1627926 in libvirt (Debian) "Enable NUMA support in arm64 builds" [Unknown,New]
<xnox> doko, right
<kenvandine> pitti, i'm experiencing infra issues with autopkgtests for silo 1994
<kenvandine> RESP BODY: {"overLimit": {"message": "Quota exceeded for ram: Requested 1536, but already used 50176 of 51200 ram", "code": 413, "retryAfter": "0"}}
<kenvandine> pitti, that's the error i see on the running page
<pitti> kenvandine: they will be auto-retried, aren't they?
<pitti> yeah, they sleep for 5 minutes in between failures
<kenvandine> ah
<kenvandine> so this isn't unexpected?
<pitti> no, happens all the time
<kenvandine> i have been waiting for the tests to pass on xenial for like a week
<kenvandine> but haven't had time to look at the error until now
<kenvandine> not sure what's going on otherwise
<pitti> kenvandine: binutils, libreoffice, and several linux tests are running, all of which use an m1.large instead of a small instance; so they take away a lot more resources, thus starving some other workers
<pitti> but it'll sort itself out
<kenvandine> ok, thx
<kenvandine> i'll keep waiting
<dannf> rbasak: done
<nacc> rbasak: around?
<doko> xnox: boost1.62 needs openmpi to migrate first. will you work on that, or is LocutusOfBorg doing that?
<xnox> will try to look into it.
<LocutusOfBorg> thanks, ginggs ^^^
<LocutusOfBorg> ping in case you want help
<Mirv> doko: "/usr/lib/gcc/aarch64-linux-gnu/6/include/arm_neon.h:29223:22: fatal error: arm_fp16.h: No such file or directory" on zesty arm64?
<doko> Mirv: known
<Mirv> thanks
<girish946> hello, I need help for packaging a python module for ubuntu. Am I on the right channel?
<ginggs> girish946: you probably want #debian-python on OFTC
<mitya57> That also depends on your question.
<mitya57> !ask | girish946
<ubottu> girish946: 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. :-) See also !patience
<girish946> hello ubottu, mitya57 my problem is I'm not able to build and install debian packages built with stdeb. I'm getting build failure on the launchpad.
<girish946> I'm unable to figure out what am I doing wrong. perhaps I need some pointers to learn debian packaging for python the right way.
<mitya57> girish946, first, stdeb is quite an outdated tool. For Python packages you would better use something like https://github.com/p1otr/pypi2deb.
<girish946> mitya57: ok I'll go through the link and try it.
<mitya57> (It's also packaged as pypi2deb)
<mitya57> girish946, second, please give us a link to the build log
<girish946> mitya57: ok
<hjd_> I thought reverse-dependencies would prevent a package from being removed from the archive? But it looks like at least one packag has a missing dependency in 16.10, see bug 1631796 for details
<ubottu> bug 1631796 in transcode (Ubuntu) "Yakkety version of transcode needed (removal causes unmet depdendencies)" [Undecided,Confirmed] https://launchpad.net/bugs/1631796
<slangasek> doko: ^^ it seems you processed the transcode removal, but it had reverse-dependencies?
<doko> slangasek: I can't remember removing that one. Are you sure about that?
<slangasek> doko: +publishinghistory says you removed it in April
<slangasek> and I know +publishinghistory works, because I always get random emails from users asking me to restore packages I removed via process-removals ;-)
<doko> slangasek: in y after release of x?
<slangasek> doko: sorry, I was looking at the publish date (4/21, when yakkety opened), the removal date was May 3
<slangasek> https://launchpad.net/ubuntu/+source/transcode/+publishinghistory
<doko> hmm, usually I check using reverse-depends ...
<rharper> hrm, launchpad snap builds used to list the manifest of the snap along with the snap on the build page; (as of yesterday); today I only see the .snap file.
<rharper> https://launchpad.net/~raharper/+snap/ubuntu-core/+build/6319
<rharper> for example
<rharper> aha, different snap builds;
<rharper> https://code.launchpad.net/~raharper/+snap/core/+build/7485 ;
<mwhudson> what's the fix for this:
<mwhudson> (ubuntu-1.7 *)mwhudson@aeglos:/opt/opensource/deb/golang$ mk-sbuild --distro ubuntu zesty
<mwhudson> Specified release (zesty) not known to debootstrap
<mwhudson> oh, update distro-info-data i guess
<Unit193> mwhudson: That's a debootstrap one, needs the symlink in /usr/share/debootstrap/scripts/ from zesty to gutsy.
<mwhudson> ah ok
<cjwatson> rharper: Are you sure that your snap build actually generated a manifest?  LP doesn't generate it, it just picks it up from the build if the build does it.
<rharper> cjwatson: I was mistaken
<cjwatson> OK.
<rharper> I was looking at the wrong snap build; the os-snap doesn't generate a manifest; but the core snap did;  PEBCAC
<rharper> cjwatson: thanks for following up
<nacc> smoser: so the exmaples in the usd-clone usage seem ... empty?
<nacc> http://paste.ubuntu.com/23350669/
#ubuntu-devel 2016-10-20
<pitti> Good morning
<Bluefoxicy> awesome
<Bluefoxicy> vendor incompatibilities and fragmentation
 * Bluefoxicy manually edits /etc/libvirt/qemu/*.xml because 16.10 breaks thanks to a machine type of "pc-i440fx-vivid" instead of just "pc"
<sarnold> Bluefoxicy: please talk with cpaelzer if something feels wrong; he's put a lot of effort into making libvirt nice, including some machine type changes
<sarnold> Bluefoxicy: oh, I'm sorry, it's Christian Ehrhardt
<sarnold> Bluefoxicy: see e.g. https://lists.ubuntu.com/archives/ubuntu-server/2016-September/007411.html
<Bluefoxicy> sarnold: nice
<Bluefoxicy> sarnold:  the problem with all that is eventually they apparently drop support for machine types, so a machine created 5 releases ago suddenly stops working unless you tinker with it.  There's nothing that says, "Oh, it's like 3 releases back; should we change it to -xenial?"
<Bluefoxicy> then you get to -yak and it's dropped -vivid and it goes "OMG WHAT IS THIS?!"
<Bluefoxicy> I'll have to file a bug or raise this on the devel-discuss list for further comment
<rbasak> Bluefoxicy: FYI cpaelzer is out today and tomorrow so I expect he may not reply until Monday.
<rbasak> Bluefoxicy: but please do raise your concerns on the thread. Feedback appreciated.
<Bluefoxicy> rbasak:  I might need to use gmane or something to respond to that thread on ubuntu-server since i'm not subscribed
<Bluefoxicy> "We're going through a complete rebuild, so some things are very broken. Please see our blog at http://home.gmane.org/ for news."  XD
<coreycb> rbasak, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates?  bug 1608934
<ubottu> bug 1608934 in nova (Ubuntu Xenial) "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,Fix committed] https://launchpad.net/bugs/1608934
<Bluefoxicy> anyway, I have to go to what is allegedly "work" now
<Bluefoxicy> so I'll do that later, after I finish reading web comics for 8 hours.
<sarnold> Bluefoxicy: actually it's probably sad news about gmane :( https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/
<rbasak> Bluefoxicy: I moderate the list fairly regularly so that shouldn't be a problem - I can let it through. I can also add you to the whitelist when I do that.
<rbasak> Bluefoxicy: in general, if you don't want to subscribe to a mailman list but post to it, you can subscribe and immediately disable deliveries. Then you don't hit moderation even if it's subscriber-only. No need for ubuntu-server though.
<rbasak> coreycb: I don't have the powers yet. Sorry!
<coreycb> rbasak, np :)
<rbasak> gmane> :-(
<coreycb> pitti, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates?  bug 1608934
<ubottu> bug 1608934 in nova (Ubuntu Xenial) "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,Fix committed] https://launchpad.net/bugs/1608934
<pitti> coreycb: not right now; can do another SRU shift tonight, but if it's urgent please ask around for others
<coreycb> pitti, it's not urgent, later would be fine
<xnox> Laney, http://baturin.org/docs/iproute2/#Delete a link
<smoser> nacc, fixing
<TheMuso> Anybody have any idea why sbuild is slow for me? I'm using directory based chroots with overlay fs and have both tmpfs and disk based overlay chroots set up. Sbuild takes ages to start downloading deps and building... This on yakkety.
<sarnold> 'ages to start' sounds vaguely like dns; there's six second delays if there's failures talking to dns servers in /etc/resolv.conf
<smoser> TheMuso, i've seen similar behavior
<TheMuso> Nope, not that. I have the same problem at home on another box. Sbuild used to be rather quick in processing build deps required and downloading/buidling.
<smoser> not debugged. i suspected kernel upgrade. :-(
<smoser> it seems really slow on yakkety.
<TheMuso> smoser: Hrm possible... I think I saw it ona 4.4 kernel, but don't have that kernel here to test with. Something to test when xenial has 4.8 I suspect.
<smoser> although i can't rule out sarnold's suggestion.
<pitti> TheMuso: archive.u.c. seems quite loaded these days, I also get long hangs tryign to download Pacakges.gz or debs (after DNS resolution)
<TheMuso> pitti: This is before even starting to download deps, and when at home, I use a mirror in Australia.
<smoser> i dont think its archive related.
<smoser> yeah.
<pitti> well, I wrote it off as post-release slowness; maybe it indeed is something else
<smoser> sarnold's suggestion seems plausible to me
<smoser> with addition / usage of systemd-resolvd
<TheMuso> Well, I am here at the sprint using archive.conference... and its still slow.
<pitti> the other day I had three dozen dnsmasq instances spawned by NM which made DNS slow -- can you check?
<TheMuso> i.e I changed my chroots to use archive.conference directly.
<sarnold> 12 packets transmitted, 8 received, 33% packet loss, time 11041ms
<sarnold> ow
<TheMuso> Still one instance.
 * sarnold hugs mosh
<TheMuso> i.e only one instance of dnsmasq.
<TheMuso> I don't *think* its network, unless sbuild does a lot of network stuff at the beginning while its working out deps to download.
<TheMuso> And I think its not even schroot created, because I can update my chroots just as quickly as I have been able to in the past.
<TheMuso> related*
<TheMuso> Anyway, I *may* have a 4.4 kernel on my yakkety install at home, so will check when I get back and test if so.
<pitti> TheMuso: oh right -- when I start sbuild, my load goes up to 50; might be another fallout of bug 1626436
<ubottu> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436
<smoser> pitti, around ?
<smoser>  https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=ifupdown
<smoser> what shal i do about that ? i can just upload it to zesty..
<pitti> smoser: yeah, sounds better now; we have a new gcc, binutils etc, and zesty is fully open
<pitti> so we shouldn't do binary copies any more at this point (just for the 0-day ones)
<smoser> pitti, then go ahead and NACKK that
<pitti> smoser: why that? the fix is good?
<smoser> becuse i would update the ubuntu3 to zesty
<smoser> so the one in yakket-proposed need to have version adjusted
<smoser> no ?
<pitti> smoser: or just upload to zesty as ubuntu4?
<pitti> smoser: I mean, I'm fine with rejecting if you prefer "nicer" version numbers, but I don't think it's a requirement
 * pitti needs to go AFK for a bit
<smoser> pitti, thats fine too.
<smoser> i'll upload as ubuntu4 "no change rebuild" ?
<pitti> smoser: or "* upload to zesty" (and use -v to include the previous record)
<smoser> pitti, i dont understnd that.  i need the new version, right?
<nacc> rbasak: do we want upload/ tags to be annotated to the developer or the uploader?
<sinzui> hallyn: Do you have any sight into this lxc1 error on s390x? https://pastebin.canonical.com/168526/
<rbasak> nacc: the person running the importer, I think.
<rbasak> Since it's both a confirmation of the version but also how it was done.
<sinzui> stgraber: ^ mayeb you have insight into https://pastebin.canonical.com/168526/
<rbasak> Whereas a commit tries to be exactly what the person uploaded.
<stgraber> sinzui: you shouldn't use pastebin.canonical.com for public pastes
<nacc> rbasak: ack, the upload tag itself is created outside the importer, though
<nacc> rbasak: import tags will be annotated to the user running the importer, to be clear
<nacc> rbasak: but upload tags are part of the review process now, in theory
<sinzui> stgraber: sorry, the paste has circulated. I can redo in ubuntu. nothing secret in it
<stgraber> sinzui: if you want hallyn to be able to see it, you'd have to since he's not at Canonical anymore :)
<stgraber> sinzui: anyway, that error usually comes from lack of seccomp support in the kernel
<sinzui> stgraber: well that aligns with the fact we got a new kernel
<sinzui> stgraber: do you recommend I look for a downgrade?
<stgraber> sinzui: I'm looking at something real quick, it could be that this is caused by LXC 2.0.5 now supporting seccomp on s390x
<stgraber> just confirming that it's indeed something that was "fixed" in 2.0.5 (lack of seccomp support on s390x) which could cause this regression
<sinzui> stgraber: 2.0.5-0ubuntu1~ubuntu16.04.1 was installed recently
<stgraber> sinzui: right, confirmed that s390x seccomp support was added to LXC 2.0.5, previous one was skipping seccomp entirely which would explain why it was working
<stgraber> sinzui: checking when s390x seccomp support was added to the kernel, to see if it's just a missing config in our kernel that'd fix that cleanly or if we'd need it backported to 4.4 which would be a bit more annoying
<stgraber> hmm, that was the 3.6 kernel supposedly, so a bit confused as to why we wouldn't have it in our 4.4
<stgraber> sinzui: config-4.4.0-45-generic is what you're running right?
<stgraber> hmm, so I see it enabled in that kernel, not sure what's going on then
<sinzui> stgraber uname-a says 4.4.0-45-generic
<stgraber> ok, let me reboot my s390x system to run on that kernel and LXC and see what's going on
<stgraber> sinzui: reproduced the issue here
<sinzui> I suppose I could cheer
<stgraber> sinzui: you can workaround it by putting a file with lxc.seccomp= in /usr/share/lxc/config/common.conf.d/, that should get you going again
<sinzui> stgraber: I will try
<stgraber> sinzui: got one of my guys looking at it now
<sinzui> thank you stgraber : have a working container. I will let the build scripts try to do the same
<stgraber> obviously once we sort it out, it'll be good to remove that file as seccomp is a useful security feature
<stgraber> but since 2.0.4 didn't support it at all, it's no worse at least :)
<smoser> Subject: [ubuntu/zesty-proposed] ifupdown 0.8.13ubuntu4 (Waiting for approval)
<smoser> is that by design ?
<smoser> "waiting for approval"
<stgraber> smoser: see topic, not open yet
<smoser> fudge.
<smoser> well, i have two waitin for approval.
<stgraber> slangasek: looks like LP is returning those OOPS right now, turned off cron
<stgraber> slangasek: trying to get an LP URL from import-images
<stgraber> slangasek: ok, so LP does return a 500, so someone will need to fix the importer to properly detect and deal with those, since apparently urlretrieve doesn't trigger an exception on those
<stgraber> slangasek: the URL that's failing to import is https://git.launchpad.net/~device-release/turbo/+git/device_tarball/plain/device.tar.xz?h=candidate
<stgraber> sil2100: FYI ^
<stgraber> so current state is cron disabled and sil2100's e-mail address marked as the target for cron mail when re-enabled
 * stgraber gets back to being off
<nacc> slangasek: have a quick q for you re: a package in 16.04 that was technically unmaintained upstream at the time (mkstutil). There is LP: #1568714 for it, and a fix provided. However, that fix is not what upstream did (because upstream removed the feature completely (https://sourceforge.net/p/msktutil/code/ci/19066f9777a19b6fda8c62e7774b4bb2157eb32a/)). I feel like there are three options: 1) SRU the
<ubottu> Launchpad bug 1568714 in msktutil (Ubuntu Xenial) "stack smashing detected ***: msktutil terminated for version 0.5.1+git8158aa2b-1" [Undecided,New] https://launchpad.net/bugs/1568714
<nacc> maintained version from yakkety back to xenial; 2) just take the submitted patch, although it's not identical to upstream's changes, as it has been tested to fix the issue; 3) backport the upstream fix, but that changes the supported features for the package (even if the supported feature was arguably buggy per upstream).
<nacc> slangasek: not urgent to provide input, but any advice you could give on which would be preferred would be appreciate it
<stgraber> sinzui: status update is that it's not a LXC or kernel bug, xenial's libseccomp was patched to add s390x support but apparently incorrectly so, so LXC detects support, uses it but then the library fails to set things up somehow. We're still digging and will most likely send a SRU for libseccomp in xenial
<koike> cjwatson, hey, you are one of the grub2 maintainers right? In debian we need to create a monolithc version of grub in the arquives to be able to sign it with all its modules, is it ok if I change the packages like grub-efi-amd64-bin_2.02~beta3-1_amd64.deb to build a monolithic version of grub? Or maybe to create something like grub-efi-monolithic-amd64-bin_2.02~beta3-1_amd64.deb ?
<koike> cjwatson, so I would like your opinion about the solution before I start working on it
<slangasek> stgraber: AFAICS the HTTP code isn't even returned at all by urlretrieve(), I don't see it as part of the returned headers struct
<slangasek> nacc: was this upstream feature usable at all, or was it completely broken by the above bug?
<nacc> slangasek: it's hard to say; the above bug is a stack smash that makes the tool itself unusable regarldess of the feature (ldaps + tls). It seems like the upstream feature (ldaps + tls) never worked, though.
<slangasek> nacc: I don't object to an SRU that removes a broken and unusable feature in order to leave the package usable for other purposes.  I would object to an SRU removing a feature that might be broken for some people in some circumstances, but usable in others
<nacc> slangasek: ack, that makes sense, i'll do some more examination
<sinzui> stgraber: Is there a bug I can track so that I know when to remove my hack?
<stgraber> sinzui: we'll file one on LP once we're sure where the problem is
<stgraber> slangasek: right, but my (clearly wrong) expectation was that it'd raise an exception as it does for the other error cases (timeouts and such)
<smoser> why does this not work?
<smoser>  
<smoser> # hostnamectl status
<smoser> in a container doesnt work.
<smoser> horay
<stgraber> smoser: looks like a systemd thing
<stgraber> Oct 20 18:49:36 yak systemd[6322]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied
<stgraber> [62189.667647] audit: type=1400 audit(1476989376.082:576): apparmor="DENIED" operation="file_lock" profile="lxd-yak_</var/lib/lxd>" pid=19491 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none
<stgraber> so maybe an apparmor bug actually because I can't think of why our profile would block this
<jgrimm> stgraber, smoser: confirmed xenial container behaves that way.  trusty container worked tho
<stgraber> jgrimm: would make sense since trusty wasn't using systemd
<jgrimm> yep
<stgraber> jgrimm: running hostnamed directly by hand works fine too
<smoser> stgraber, running hostnamed ?
<stgraber> smoser: in a shell, run "/lib/systemd/systemd-hostnamed", in another, run hostnamectl :)
<slangasek> xnox: yay, new jitsi is dep-wait ;)
<smoser> what a pit
<smoser> pita
<pitti> smoser: yes, but use -v...ubuntu2 to include the ubuntu3 revision to
<smoser> pitti, i did. thanks
 * pitti goes for a round of SRU review
<pitti> cyphermox: so your initramfs-tools 0.125ubuntu6.1 in the unapproved queue refers to bug 1631474 which is already closed (fixed by the previous SRU)
<ubottu> bug 1631474 in initramfs-tools (Ubuntu Zesty) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,Fix committed] https://launchpad.net/bugs/1631474
<pitti> cyphermox: typoed the bug #? if the reversion should use the same bug, can you please reopen and adjust the description?
<cjwatson> koike: no, don't do that, I'll be switching on the Ubuntu patch set to implement signed GRUB builds as soon as Debian has the necessary signing implementation in place; you'd be wasting your time working on it since it's already implemented
<koike> cjwatson, but in Ubuntu the grub2 package doesn't publish a monolithic version, does it? To make grub-signed build reproducible we need this available, so grub-signed can depend on it
<cjwatson> koike: yes it does, debian/build-efi-images produces that as a custom upload
<cjwatson> koike: I'm not going to add another binary package, it's already complicated enough!
<cjwatson> koike: we shouldn't need another binary package for reproducibility, we just need grub-mkimage's output to be reproducible given the same inputs
<cjwatson> koike: which if it's not the case today shouldn't be far off
<cjwatson> koike: I'm totally happy to take patches to improve reproducibility BTW, I think that's an excellent goal, just want to make direction clear
<koike> cjwatson, sure, thanks for your feedback, I am checking some other things that I am not entirely sure about, I'll also get some opinion at #debian-efi too
<cjwatson> koike: the other thing I want to do is integrate Mathieu's Ubuntu patches for better MOK integration, which I think can be done in Debian as well now and would make it possible to require signed kernels
<cjwatson> but ETIME
<koike> cjwatson, I see, ETIME is a problem indeed. Could you send me a link to these patches (I am having some trouble finding them)
<cjwatson> koike: I think they're in people/cyphermox/<somethingorother> in the Debian git repository, though not sure if they're up to date; the current Ubuntu source package can be found at https://launchpad.net/ubuntu/+source/grub2
<cjwatson> I'm hoping I can nag cyphermox into submitting them in a form I can easily apply :)
<cjwatson> (possibly simpler after rebasing on 2.02~beta3-1)
<cyphermox> there is that
<cyphermox> you mean the patches for the new shim filenames?
<cjwatson> cyphermox: I meant the whole mokutil workflow with the extra debconf questions and such
<cyphermox> ah, ok
<cyphermox> that's removed from grub, actually. here's hoping there isn't anything left
<cyphermox> all moved to shim-signed
<cjwatson> and obviously anything else that seems relevant, I'd like to get back in sync but of course with cherry-picked patches and such it's a fair bit of source to compare
<cyphermox> if beta3 is ready in the git branch I can get you the other patches ready
<cjwatson> cyphermox: it's in unstable, though indeed in git too
<cyphermox> ok, I hadn't noticed, been busy with other things
<cyphermox> I'll want to get beta3 in zesty anyway though
<nacc> is it a known bug in `apt-get changelog that when a source package lives in main but has binaries published in universe (e.g., qemu), it tries to load a changelog from universe?
<nacc> I noticed just now that there is a 'new' -u option for rmadison to look at the debian new queue. Is the ubuntu new queue exposed similarly?
#ubuntu-devel 2016-10-21
* infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> if i have a package sync'd from debian in xenial that needs to be rebuilt (rebuild fixes a bug in xenial); would i upload that as <version>ubuntu0.1 still? Or is there a way to specify an SRU is arebuild only?
<infinity> nacc: 1.2.3-4build0.1
<infinity> nacc: Or just build1, if there's a higher version in yakkety.
<nacc> infinity: thanks!
<pitti> Good morning
<pitti> stgraber: bonjour ! do you mind setting up zesty container builds on images.linuxcontainers.org? that would unbreak a few tests (like docker.io) which use them
<sil2100> caribou: hey, you said once that you were asked to check the dbus fix for the systemd logind issue, right?
<sil2100> caribou: since we seem to have a working fix now but not approved/reviewed formally by upstream yet (although it's coming from upstream) - want to give that a spin?
<caribou> sil2100: yes, I have what looks like a similar issue, but I'm not able to reproduce using an ssh login loop
<caribou> sil2100: where is it ? in your PPA ?
<sil2100> caribou: I'll be preparing an official release for that soonish for zesty, but would like some more people to give it a spin
<sil2100> caribou: yes, the bug points to which PPA to use
<sil2100> (xenial and yakkety packages IIRC)
<caribou> sil2100: I'll see what I can do
<sil2100> caribou: do you have any experience in dbus code?
<pitti> doko: apparently the new gcc in zesty breaks some stuff (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-022/+packages), yesterday's builds were still okay; but I fail to see the actual error in https://launchpadlibrarian.net/290302168/buildlog_ubuntu-zesty-i386.indicator-network_0.8.0+17.04.20161021-0ubuntu1_BUILDING.txt.gz , do you see it?
<pitti> could also be new cmake, of course
<pitti> LocutusOfBorg: ^ maybe you can have a look at that build log too? it's completely obtuse to me what actually fails
<pitti> (this is architecture independent)
<pitti> CMake Error at CMakeLists.txt:25 (include):
<pitti>   include could not find load file:
<pitti>     EnableCoverageReport
<pitti> oh, that ^ LocutusOfBorg, that's your bug
<pitti> LocutusOfBorg: filed as bug 1635613
<ubottu> Error: Could not gather data from Launchpad for bug #1635613 (https://launchpad.net/bugs/1635613). The error has been logged
<LocutusOfBorg> ok wilco
<LocutusOfBorg> pitti, got it
<LocutusOfBorg> damn damn damn stupid extra package
<LocutusOfBorg> pitti, fixed
<LocutusOfBorg> will comment on the bug too
<LocutusOfBorg> how can I force cmake-extras to not let cmake migrate on new upstream releases?
<LocutusOfBorg> we should force some breaks cmake >= 3.6 or whatever in control file
<LocutusOfBorg> otherwise we will forget this on cmake 3.7 again
<sil2100> 12131
<sil2100> Whoops
<sarnold> that's not a very good password
<sil2100> Darn it
 * sil2100 quickly changes his bank account password
<pitti> LocutusOfBorg: oh, thanks for tracking that down! I'll rebuild those packages once it gets published
<LocutusOfBorg> thanks for notifying me
<LocutusOfBorg> btw next time if you want an even speedier fix, just try to ping me before or after lunch, not during :)
<LocutusOfBorg> I don't read irc while lunching :D
<pitti> LocutusOfBorg: ok, then next time I'll use my crystal ball to anticipate FTBFS before they happen :-P
<pitti> LocutusOfBorg: speedy enough, many thanks!
<LocutusOfBorg> anticipating FTBFS would be awesome, do you have any patch or ETA for the implementation? will it run as a systemd unit?
<LocutusOfBorg> systemd-ftbfsd
<LocutusOfBorg> :D
<pitti> LocutusOfBorg: <sheldon_cooper>I will have had have this written soon :)
<pitti> (tempus when they discussed a time travel movie)
<LocutusOfBorg> :) I remember
<LocutusOfBorg> btw did you watch the last episode? you will finally know why he is always knowking thrice the door
<pitti> LocutusOfBorg: no, 9th season isn't on netflix in Germany yet :(
 * pitti currently spends his lunch breaks on 4th season of House of Cards
<LocutusOfBorg> is thrice a valid word? /me is confused
<sarnold> it is, not common but valid
<pitti> I've seen it often enough
<LocutusOfBorg> thanks sarnold :)
<LocutusOfBorg> hi britney, do you mind doing some work today?
<sil2100> britney was buys
<sil2100> *busy
<sil2100> I uploaded a new dbus package to -proposed earlier today and that triggered a bazillion of autopkgtests
<LocutusOfBorg> oh, now I'll change the topic to "britney is busy? blame sil2100 " :)
<pitti> LocutusOfBorg: works now, thanks!
<LocutusOfBorg> yw :)
<LocutusOfBorg> your britney is faster than mine :/
<coreycb> infinity, bdmurray: hello, would you be able to take a look at these in one of your sru review slots next week?  nova promotion to xenial-updates for bug 1608934 and review of mistral, neutron, nova for the xenial upload queue.
<ubottu> bug 1608934 in nova (Ubuntu Xenial) "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,Fix committed] https://launchpad.net/bugs/1608934
<sinzui> stgraber: regarding bug 1635639. We have lxc working with the have, but lxd still wont work. any clues?
<ubottu> bug 1635639 in lxc (Ubuntu) "Seccomp error with 2.0.5-0ubuntu1~ubuntu16.04.1 on s390x " [Undecided,New] https://launchpad.net/bugs/1635639
<stgraber> pitti: yeah, doing that now
<stgraber> pitti: need to check if xenial's debootstrap know about zesty though
<pitti> stgraber: argh, it doesn't have been SRUed yet
<pitti> ... and yay at my Friday afternoon grammar :)
<pitti> doesn't has not have will had been SRUed
<rbasak> That's interesting. 50unattended-upgrades says ${distro_id}:${distro_codename}. Currently, that's yakkety, even though sources.list points to "devel". So unattended-upgrades won't do a "rolling release" for me on this machine as I wanted.
<pitti> apw, cjwatson, cyphermox, slangasek, infinity: I noticed that we still have grub (1.x) in the archive; do we still actually need it for anything?
<pitti> I noticed that it ships /sbin/update-grub, which would shadow grub2's /usr/sbin/update-grub
<pitti> (same for grub-install)
<pitti> stgraber: btw, I think you can/should stop building wily images
<stgraber> pitti: yeah, I noticed those when adding zesty and removed them from Jenkins, they'll expire soon from the image servers
<slangasek> pitti: cyphermox was doing some final analysis of whether there were still any use cases for grub1; I don't know if he finished that yet
<slangasek> I know there were still references to grub1 in grub-installer udeb that we wanted to remove
<cyphermox> I think I removed the already, but I'd have to look again
<slangasek> cyphermox: once you've looked, please ack the removal request (LP: #1611740)
<ubottu> Launchpad bug 1611740 in grub (Ubuntu) "remove grub, superseded by grub2" [Undecided,New] https://launchpad.net/bugs/1611740
<smoser> TheMuso, hey. wrt 4.4 and 4.8 and sbuild...
<smoser> i grabbed 4.4 from xenial, rebooted into it. built the same trival package that i built yesterday on 4.8
<smoser> $ ( cd /home/smoser/ubuntu/logs/ && grep "^Build needed" smello_0.4~ppa1_amd64-2016-10-2*)
<smoser> smello_0.4~ppa1_amd64-2016-10-20T16:48:33Z.build:Build needed 00:02:34, 120k disc space
<smoser> smello_0.4~ppa1_amd64-2016-10-21T18:31:17Z.build:Build needed 00:00:32, 120k disc space
<tsimonq2> Hello. Can someone please sync the cmst from Testing to Zesty?
<tsimonq2> !info cmst testing
<ubottu> cmst (source: cmst): QT GUI for Connman with system tray icon. In component main, is optional. Version 2016.10.03-1 (testing), package size 2159 kB, installed size 3026 kB (Only available for linux-any)
<tsimonq2> !info cmst zesty
<ubottu> cmst (source: cmst): QT GUI for Connman with system tray icon. In component universe, is optional. Version 2016.04.03-2 (zesty), package size 2162 kB, installed size 2962 kB (Only available for linux-any)
<tsimonq2> ^^
<tsimonq2> I would do it, but I don't have upload access...
<tsimonq2> Nevermind, I found the requestsync tool.
<hjd_> tsimonq2: See also https://wiki.ubuntu.com/SyncRequestProcess :)
<tsimonq2> hjd_: That's where I found it. ;)
<tsimonq2> bug 1635705
<ubottu> bug 1635705 in cmst (Ubuntu) "Sync cmst 2016.10.03-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1635705
<tsimonq2> \o/
<slangasek> xnox: 6 oldest packages in -proposed resolved or in process; max package age cut from 800+ days to 437 days; you're welcome ;)
<hjd_> tsimonq2: Just in case you found it somewhere else.
<hjd_> tsimonq2: Also note that the package will probably be synced automatically now that Zesty seems to have opened for development.
<slangasek> zul: why does monasca-statsd have a 'LICENSE' file in its tree that doesn't match the copyright holder or license listed on any of the source files?
<slangasek> zul: empty Homepage: field in debian/control, not useful?  and lintian reports a warning on debian/copyright because the names in the License: fields don't match up
<zul> slangasek: ill have a look thanks
<slangasek> zul: only the answer to the first question blocks NEW processing (the debian/copyright and LICENSE file don't match, so I need to know why)
<zul> slangasek: im not sure why ill get upstream to look at it
<Unit193> https://packages.qa.debian.org/d/debootstrap/news/20161021T194901Z.html merged-usr is default.
<TheMuso> smoser: Yeah nice to confirm it, thanks.
<nacc> ok, got a somewhat tricky SRU question -- LP: #1577916 works for upgrades/installs from 14.04. But if you're already on 16.04 and thus got php-fpm pulled in by the older ganglia-webfrontend package, how do I forcibly require that libapache2-mod-php be used to satisfy the dependnecy? The issue is (I think) that since php7.0-fpm already satisfies php7.0 (satisfies php), it doesn't matter the order they
<nacc> are expressed in (libapache2-mod-php | php | php-cgi vs. php | php-cgi | libapache2-mod-php) on installation/upgrade *if* php-fpm is already installed. But if it was only installed because of ganglia-webfrontend (broken version), i'm not sure how to automatically detect that and switch the dep
<ubottu> Launchpad bug 1577916 in ganglia-web (Ubuntu Xenial) "Missing dependencies" [Low,Fix committed] https://launchpad.net/bugs/1577916
<infinity> nacc: If it doesn't work with other php implementations, your dependencies are a lie.  If it does work with others, there's no bug.
<infinity> nacc: Not much halfway point here.
<infinity> nacc: But to answer the more complex question, "can I tell what webserver the user has installed, and install the right PHP magically?", the answer is no.
<infinity> nacc: So, there's a certain onus on them to get it right.
<infinity> nacc: If apt supported Enhances, it could probably help guess a bit, but in the end, it's generally going to be the user's responsiblity to pick the right PHP for their setup.  It's always been this way.  Just that, historically, most users used apache, and most php-depending things listed the apache module first, so it JusT Worked for those people.
<infinity> nacc: And for people who did non-Apache things, they knew how to get there.
<infinity> nacc: So, certainly, the path of least surprise is to make sure upgrades continue that trend.
<infinity> nacc: As for people already on 16.04 with the "wrong" deps, you can't fix that, and you shouldn't try, because "fixing" it might not be a fix.
<infinity> nacc: As in, you might "fix" an nginx system by breaking it. :P
<infinity> nacc: If Apache users got the inverted deps, either they've given up by now (no one sits on a broken webapp for 3 months), or they flipped the packages around correctly so it worked.
<nacc> infinity: ack on all that
<nacc> infinity: it *can* work with any of the deps, as described in the control file (afaict), but it requires manual changes to work with fpm in this case, and 'just works' (has apache conf hooks) for the mod-php case
#ubuntu-devel 2016-10-22
<Bluefoxicy> it's really annoying that you have to right-click on the Gnome Image Viewer window and hit "resize" to resize it
<Bluefoxicy> rbasak:  I'd rather not subscribe, but it's more that I'm not subscribed and so replying to the thread means... ...well, I don't have a message here to reply to.
<voidconf> hello
<voidconf> /
<rbasak> Bluefoxicy: for Mailman I use the downloadable mboxes from eg. https://lists.ubuntu.com/archives/ubuntu-server/ and then reply from one of those. Only the email addresses in their are munged, and I use mutt where loading an mbox is trivial.
<rbasak> Others use gmane, but I hear that may be going away :-(
<Bluefoxicy> rbasak:  gmane appears to be up but not actually have anything
<Bluefoxicy> the actual mail archives are gone
<tsimonq2> !info cmst zesty
<ubottu> cmst (source: cmst): QT GUI for Connman with system tray icon. In component universe, is optional. Version 2016.04.03-2 (zesty), package size 2162 kB, installed size 2962 kB (Only available for linux-any)
<tsimonq2> :/
#ubuntu-devel 2016-10-23
<FatSpitfire> and I have a problem ...
<FatSpitfire> what to do if my country doesn`t have a LoCo team ?
<ginggs> FatSpitfire: you can create one, see: https://wiki.ubuntu.com/LoCoTeamHowto for details.
<FatSpitfire> thanks :)
<FatSpitfire> ok may I ask than who contributed the lang files for Bulgarian lang ?
<sea-gull> hello, I'm looking for the source code of `update-manager-core` in dcvs, but I couldn't find any
<sea-gull> and the package itself doesn't contain any patches, as it's purely ubuntu thing
<sea-gull> so not sure how to send a patch to it
<tarpman> sea-gull: https://code.launchpad.net/~ubuntu-core-dev/update-manager/main I think
<sea-gull> tarpman: oh, I see. Thanks a lot
#ubuntu-devel 2017-10-16
<pitti> infinity: whoops :) will look
<pitti> infinity: uploaded autopkgtest 5.0.2 to debian, I'll sync as soon as it gets imported. also, thanks to whoever added the britney "your package is stuck" email notifications!
<LocutusOfBorg> thanks ginggs :)
<ginggs> LocutusOfBorg: r-cran-curl?
<LocutusOfBorg> yep
<ginggs> LocutusOfBorg: np :)
<dupondje> Somebody already working on upgrading wpa? :) seems a hype atm ;)
<rbasak> cpaelzer: I just remembered: https://jira.mariadb.org/browse/MDEV-13412 is possibly relevant to the MariaDB failure too.
<cpaelzer> rbasak: I see an issue more local to mariadb
<cpaelzer> rbasak: the test case only fails with the new mariadb upload
<cpaelzer> rbasak: 10.1.25-1 is good, but 10.1.28-1 is bad
<cpaelzer> rbasak: was 10.1.25-1 built before gcc7 - do you happen to know?
<cpaelzer> let me check dates
<cpaelzer> already pulls in gcc7 on the old build
<cpaelzer> so no new optimization as we assumed before
<rbasak> Interesting
<cpaelzer> also since the .28 is 14 houts old a rebuild won't be much different
<cpaelzer> still I have one ongoing atm
<cpaelzer> just to be sure
<cpaelzer> rbasak: this is fixed in 10.1.29 according to the ticket you linked before
<cpaelzer> rbasak: would need to do a test build with that
<cpaelzer> is that released already?
<rbasak> I don't see it in Debian
<cpaelzer> maybe just the fix of the issue added on .28
<cpaelzer> yeah me neither, can add the change on top (at least for a crappy test build)
<cpaelzer> looking for the actual fix now
<cpaelzer> rbasak: I find no reference to the bug in the mariadb sources, nor on this jira page
<cpaelzer> rbasak: do you know how they usually hide ... umm manage bugs to find it (the commit that fixed it)
<rbasak> cpaelzer: no, I couldn't find it.
<cpaelzer> I foudn it in the 10.0 branch
<cpaelzer> but takes time to consider that for 10.1 or if it is applicable to our case at all
<cpaelzer> rbasak: https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83
<cpaelzer> that is the one I found so far
<rbasak> cpaelzer: I think that's the upstream workaround for the pcre3 bug fixed in my upload.
<rbasak> They patch their embedded version
<cpaelzer> but it is directed at the "new" error message
<cpaelzer> at least according to the logs in the bug tracker
<rbasak> And I think they might try to not use the system version if the bug exists
<cpaelzer> yeah it seems they fix their internal which means this isn't directly applicable for us :-/
<cpaelzer> nor will we get more help as for upstream it is considered fixed
<cpaelzer> rbasak: it seems to me that along the initial fix tests were changed, you picked the pcre fix that was included into the pcre3 package
<cpaelzer> rbasak: but now on the re-patch I linked before where they detect if the lib is broken look at the tests
<cpaelzer> rbasak: they change the counts, but not back to the values we have
<cpaelzer> that means considering that the pcre3 upload you had made the "fix" available  = __attribute__((noinline,noclone))
<cpaelzer> that matches your fix and is from their last commit
<cpaelzer> shouldn't we take the portion that adapts the test to match that change
<cpaelzer> I'll try that in my test env before packaging it all up just to fail
<cpaelzer> rbasak: do you have a pointer to the change you made to pcre to be sure?
<rbasak> cpaelzer: https://launchpad.net/ubuntu/+source/pcre3/2:8.39-5ubuntu1
<rbasak> cpaelzer: the failure we're seeing now seems like an exception happening before the test failure though? Or do I understand that part wrong?
<cpaelzer> rbasak: the failure now mostly is that the test works but is expected to fail
<rbasak> Ah
<cpaelzer> it runs like recurse(133) and expects it to fail
<rbasak> I misunderstood that. Thanks
<cpaelzer> the first fix was to bump 133 to a huge number
<cpaelzer> failing, done
<cpaelzer> but that didn't always work as a constant is so ... constant
<cpaelzer> now the newer fix changes back these values, but not to where they were
<cpaelzer> upstream went 133 -> 400 -> 250
<cpaelzer> we are still at 133
<cpaelzer> but since you ported the pcre3 change I wonder if making these numbers match would be required
<cpaelzer> and OTOH there is a part of the change in pcre which you did not port - was that intentional?
<cpaelzer> around: SET(PCRE_NO_RECURSE "${WIN32}" CACHE BOOL
<cpaelzer> rbasak: ^^ ?
<rbasak> Half intentional - I picked the patch from https://bugs.exim.org/show_bug.cgi?id=2173
<ubottu> bugs.exim.org bug 2173 in Code "stack frame size detection is broken" [Bug,Resolved: wontfix]
<cpaelzer> rbasak: this part is "missing" then in comparison
<cpaelzer> https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83#diff-9a9ad0af0c4fff92c9d7311d8762dd7e
<cpaelzer> which has a great on = off = on logic twist
<cpaelzer> asuuming that ${WIN32} is off for our builds we would set NO_RECURES off now (with the change), which means we would recurse
<rbasak> Is that suitable for the global src:pcre3?
<cpaelzer> it before was on in the mariadb local pcre
<cpaelzer> I don't think so, but am not the expert
<cpaelzer> I would want to check how our pcre3 is
<cpaelzer> it might be off anyway or so
<cpaelzer> we have default off
<cpaelzer> and it is in the build logs
<cpaelzer> ...
<cpaelzer> of course everything is slightly different in that pcre3
<cpaelzer> but I found Use stack recursion ............. : yes on x86
<cpaelzer> s390x as well
<cpaelzer> so our recursion is ON which matches NO_RECURSE Off
<cpaelzer> so we should be on the same level as the internal pcre fix inside mariadb
<cpaelzer> changing the test numbers for a test now
<cpaelzer> I love invert_do_not_skip_not_thing = false code
<cpaelzer> rbasak: it is not as easy as that :-/
<cpaelzer> probably because of the different pcre versions behaving differently the test adaption would need to be different as well
<rbasak> :(
<zyga-ubuntu> ha
<cpaelzer> rbasak: since the try to fix failed I documented the testbed and made it availabel to you
<cpaelzer> rbasak: the last trello card update has all you need
<cpaelzer> rbasak: and as a side note - this is a "regression" because these tests didn't exist before the .28 upload
<cpaelzer> rbasak: so it is in fact much more a new test which just not works on s390x
<cpaelzer> I wonder if in that POV we should mask just that test on just that arch instead of overriding it in a-proposed to migrate
<rbasak> That sounds reasonable
<cpaelzer> the automation for the dep8 already has a skip function
<cpaelzer> we could if arch then add one more
<rbasak> Yes I believe that's possible
<rbasak> And I think the release team are happy to take merge proposals for that
<rbasak> Or just ask them here I guess.
<cpaelzer> oh, you mean in the overrides
<cpaelzer> rbasak: I was talking about encoding that int he dep8 test to retain the coverage of all the other tests
<rbasak> Oh, I see.
<rbasak> That sounds better
<rbasak> As long as we know to lose it in the future I guess, but the presence of a delta will tell us that.
<cpaelzer> rbasak: I'll file a bug as reference, copy over some of our data we have, and provide a fix
<cpaelzer> rbasak: I'd ping you then so you can take a look
<cpaelzer> unfortunately mariadb isn't imported to the version in propsed it seems
<rbasak> I can run an import if you like?
<rbasak> It might take a while
<cpaelzer> rbasak: you likely have the command closer than I have, that would be nice to run that
<rbasak> It should be current in Debian VCS though
<rbasak> OK I'll run it now
<cpaelzer> I could look at my qemu issue until you ping
<rbasak> cpaelzer: it's importing.
<rbasak> (still)
<rbasak> cpaelzer: but also you could use https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git if you like.
<rbasak> Since it's in sync with Debian currently, it should match exactly.
<dupondje> cyphermox: already upgrading WPA ? :)
<cpaelzer> rbasak: yeah, I'd want your eyes/comments and if possible ondreys anyway
<cpaelzer> so doing on the alioth is probably the bets
<cyphermox> dupondje: hum, wat?
<dupondje> cyphermox: https://lists.debian.org/debian-security-announce/2017/msg00261.html guess Ubuntu needs to follow :)
<cpaelzer> rbasak: there is now a bug for the mariadb dep8 issue as well as a fix suggestion linked
<cpaelzer> rbasak: I subscribed you and ondrey for your comments on the suggestion
<cpaelzer> rbasak: never the less the test env still exists if you want to take a look yourself again
<cpaelzer> rbasak: or if any of the discussion needs a check while I'm not around
<seb128> bdmurray, hey, thanks for unblocking bug #1716357, I think the rule doesn't make sense though and I was trying to get a conversation going about it rather than making you do the work :-/
<ubottu> bug 1716357 in evince (Ubuntu Zesty) "a typo in evince-previewer.desktop breaks /etc/mailcap" [Medium,Fix committed] https://launchpad.net/bugs/1716357
<seb128> bdmurray, it's likely that the zesty SRU is just never going to be verified and going to suck in proposed while zesty get deprecated, that feels like a waste of work
<rbasak> cpaelzer: many thanks for your help!
<bdmurray> seb128: In this specific instance it was a regression from a security fix though so think it needs fixing regardless. However, I see your point about it possibly sitting in zesty unverified.
<seb128> bdmurray, k, fair enough, I would have agreed with that more if the update was recent, but it has been half a cycle ago so users either don't mind about the issue or workarounded it or moved to some less buggy system by now
<seb128> anyway, topic closed I guess
<seb128> thanks for unblocked the fix!
<bdmurray> Oh, I didn't notice how old it was.
<cpaelzer> rbasak: I just now pushed the qemu fix I worked on, not sure I can complete the percona today
<cpaelzer> rbasak: more likely start picking off of my triage duty and to that tmrw morning
<cpaelzer> rbasak: ok?
<rbasak> cpaelzer: that's fine.
<rbasak> Thanks again for your time
<dupondje> https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909 strange nobody seems to pick this up ...
<ubottu> Launchpad bug 1723909 in wpa (Ubuntu) "[security] WPA2: Many vulnerabilities discovered" [Undecided,Confirmed]
<sdeziel> dupondje: looks like the security team is aware and already at work, see https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-13077.html
<ubottu> ** <A HREF="https://cve.mitre.org/about/faqs.html#reserved_signify_in_cve_id">RESERVED</A> ** 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-2017-13077)
<mdeslaur> dupondje, sdeziel: I'm publishing updates now
<sdeziel> mdeslaur: thanks
<dupondje> mdeslaur: nice!
<dupondje> who takes care of artful btw?
<jbicha> dupondje: it's already uploaded for artful but it needs to be manually accepted by Release Team because of Final Freeze
<jbicha> https://launchpad.net/ubuntu/artful/+queue?queue_state=1
<dupondje> ah! thx
<jamespage> bdmurray: I know I could land this myself but could you do a quick sanity review for me - https://code.launchpad.net/~james-page/merge-o-matic/ubuntu-opnestack/+merge/332297
<jamespage> pls :-)
<bdmurray> jamespage: approved
<jamespage> bdmurray: ta
<jamespage> bdmurray: you don't happen to know whether that's an automatic deploy? or do I need to go poke someone to get things updated?
<bdmurray> jamespage: I do know and you need to poke someone like me
 * jamespage pokes bdmurray
<jamespage> bdmurray: please could you put my changes live :)
<bdmurray> jamespage: it runs at 05,35 so might appear soon
<jamespage> bdmurray: thanks!
<bdmurray> I've an 17.04 laptop which I upgraded to 17.10 with an external display connected and now I have to login using the laptop display not the external one. Is that a known issue?
<jibel> bdmurray, it's similar to bug 1723025
<ubottu> bug 1723025 in gdm3 (Ubuntu) "no login screen when booting with an external monitor attached" [Undecided,New] https://launchpad.net/bugs/1723025
<jibel> bdmurray, in my case the machine turns the internal display off.
<jibel> so I don't see the login
<bdmurray> Ah, I can see it on the internal display just the behavior is different from the previous release
<jibel> Trevinho, ^
<jibel> bdmurray, can you file a bug against gdm3
<bdmurray> jibel: Of course
<jibel> thanks
<bdmurray> jibel: 1724017
<bdmurray> jibel: bug 1724017
<ubottu> bug 1724017 in gdm3 (Ubuntu) "Cannot login using external display" [Undecided,New] https://launchpad.net/bugs/1724017
<jibel> bdmurray, thanks.
<coreycb> doko: I still can't reproduced the swift FTBFS for artful amd64. I'm not sure what I'm missing.
<codepython777> One of my usb devices has stopped showing up in dmesg/lsusb - it still works - any ideas what might be happening? (Its a FTDI device - which I have a udev rule for)
<nacc> codepython777: do you mean to be asking that in #ubuntu?
<codepython777> nacc: will do, thanks
#ubuntu-devel 2017-10-17
<doko> coreycb: even in a ppa build?
<Unit193> LocutusOfBorg: http://paste.openstack.org/show/XOpqSUDbIMkfMAJHpS7f/ is the min for license update, fyi.
<Unit193> LocutusOfBorg: http://paste.openstack.org/show/hIRIeiSC1CPiach3Sc45 where you no longer have to update the version in d/rules and d/postinst, but since one still has to update the hash in postinst...Not sure it's worth the hack.
<LocutusOfBorg> Unit193, please check with the one I committed
<LocutusOfBorg> I already had done this before getting the message
<Unit193> Better verson?  What makes it better?
<LocutusOfBorg> nothing, just I couldn't apply the patch as-is
<LocutusOfBorg> so I did the job again
<LocutusOfBorg> uploading
<Unit193> (FYI, 'Ukikie' is just another name for me.  I'm still just 'Unit 193' :) )
<LocutusOfBorg> oh lol
<LocutusOfBorg> btw would be nice to get the sha256sum file and sed the value semi-automatically with a rules target
<Unit193> There's no even somewhat decent way to do that, though.  Closest would be during 'tarball', but that's still not great.
<LocutusOfBorg> wget -O - http://download.virtualbox.org/virtualbox/5.1.30/SHA256SUMS |grep extpack
<LocutusOfBorg> the guest-additions already do something like that
<Unit193> Yes, but it also doesn't download the ISO.
<coreycb> doko: i've uploaded swift 2.15.1-0ubuntu3 for the artful FTBFS
<coreycb> doko: ppa worked
<bdmurray> kirkland: Should manpages.ubuntu.com have 17.10 before the release or after?
<kirkland> bdmurray: right around the same time
<kirkland> bdmurray: I've already committed the changes to the bzr repo, just need to file the RT
<kirkland> doing that now...
<kirkland> bdmurray: done.
<bdmurray> kirkland: okay, thanks!
<kirkland> bdmurray: thank you for the reminder ;-)
<jackpot51> Has anyone else seen this? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1724370
<ubottu> Launchpad bug 1724370 in udisks2 (Ubuntu) "NVME model does not show up" [Undecided,Confirmed]
<ignoo> hello, running ubuntu GNOME 16.04, have some issue with ubuntu ArtfulAardvark: https://pastebin.com/W1tBbqpq . Thank you for your support.
<wxl> nice poem, ignoo
<valorie> heh
#ubuntu-devel 2017-10-18
<tsimonq2> rbasak: Could you please look at bug 1710993? It's a high (if not critical) priority regression with known fixes already uploaded to the queues, and it affects anybody running Lubuntu 16.04 LTS. (You probably remember the discussion...)
<ubottu> bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,Fix committed] https://launchpad.net/bugs/1710993
<tsimonq2> rbasak: I vigorously tested all three of the uploads listed before uploading them, on several computers, and poked around a lot. They do not show any signs of regressions for me. But I guess it'll at least be another week because nobody on the SRU Team reviewed indicator-sound-gtk2 that's been sitting in the queue for over a month at this point...
<tsimonq2> (not only do these uploads work fine with the testing I have done, these exact updates are in every stable Lubuntu release from 16.10 and on)
<niceprogrammer> why dont you guys offer onions for updates like debain?
<niceprogrammer> debian
<v3n0m> hey
<v3n0m> Ubuntu 17.10 is having a slow boot time.
<abeato> seb128, hi, I am taking a look at bug #1693756 . I saw you objected to the patch that bumped libqmi version. Alex answered to that comment #14, which is your position on this changes at the moment?
<ubottu> bug 1693756 in OEM Priority Project "[Xenial][ DW5816e] to support qmi over mbim which needed for FCC authentication." [Critical,Triaged] https://launchpad.net/bugs/1693756
<seb128> abeato, hey, there is a long email discussion about that one and it seems a never ending story :-/
<seb128> abeato, my opinion is that somebody should talk to the SRU team, I suggested what I though was needed to have a good chance to see a SRU be accepted but I'm not part of the SRU team so just guessing for them
<seb128> abeato, it's quite a big change for a SRU and we would need regression testing on hardware that works today
<seb128> imho
<abeato> seb128, yeah, agreed
<abeato> seb128, who would be the best person to ask for help to SRU? cyphermox?
<seb128> abeato, he would be a good person to ask about modemmanager but he's not in the SRU team, see https://launchpad.net/~ubuntu-sru/+members#active
<abeato> ah, ok
<jamespage> xnox: morning - are you aware of anything s390x ish in artful that might make STP convergence take longer?  I'm seeing a new test failure on this arch for the 2.8.0 openvswitch packages in archive.
<jamespage> if I increased the time warping in the test by 30 seconds, I get the right result which indicates that the STP convergence is taking 60 vs 30 seconds on other archs...
<jamespage> its a bit of a head scratcher
<xnox> jamespage, hm, in artful we did switch from isc-dhcp/ifupdown to systemd/netplan (for dhclient too) we did have STP code there as well.
<xnox> let me see.
<jamespage> xnox: I would expect that to impact on all architectures
<xnox> right
<jamespage> might not be directly related to STP - ovs is running in dummy mode so its all userspace testing AFAICT
<jamespage> it might be the time/warp function is borked on s390x compared to other archs
<xnox> jamespage, time/warp? it is not possible to change time on s390x
<jamespage> xnox: its a testing hack in ovs itself
<jamespage> it basically fast forwards time for the daemon so that things that take time to converge don't cause long test times
<xnox> jamespage, not sure. looking at the kernel code there is nothing s390x special.
<jamespage> xnox: hmm no
<xnox> there is stuff about spawning userspace /sbin/bridge-stp -> which we don't have at all on any architecture?
<xnox> jamespage, the bit of "daemon fast forwards time" i'm interested to check how that is done, and if that is at all available on s390x / done right on big endian.
<jamespage> xnox: https://github.com/openvswitch/ovs/blob/master/lib/timeval.c
<jamespage> xnox: odd its not 2.8.0 specific - I see the same with 2.7.1 on xenial
 * jamespage thinks some more
<xnox> jamespage, it would be interesting to test, via the ctl/api commands if this timewarping actually works on s390x =/
<xnox> it seems like it should be.
<jamespage> xnox: I can give you a script
<xnox> but on the other hand, it is not allowed/possible to change hardware clocks on s390x.
<jamespage> xnox: http://paste.ubuntu.com/25764879/
<xnox> but i'm not sure about the details as to what exactly is not allowed.
<jamespage> xnox: time/warp is a userspace sim of time change I think
<xnox> true
<rbasak> tsimonq2: around? I commented on the bug.
<rbasak> tsimonq2: since it's possible you might want to put the Breaks in indicator-sound-gtk2, I don't want to accept it as-is without your comment.
<rbasak> tsimonq2: if you do, then it'll want adding to lubuntu-default-settings too I guess?
<rbasak> tsimonq2: aside from that your upload for indicator-sound-gtk2 looks fine. Though I feel that the changelog message should probably mention the reason for the upload (Lubuntu's move to pulseaudio), I won't block on that.
<rbasak> tsimonq2: let me know what you want to do please.
<tsimonq2> rbasak? :)
<tsimonq2> (does not seem to be in the chan...)
<cpaelzer> powersj: smoser: cyphermox: slangasek: can we reboot diamond to be on a kernel with working kvm?
<cpaelzer> kernel team fixed it a while ago, but it needs the reboot to pick it up
<smoser> cpaelzer: its fine with me.
<smoser> i'd do a 'ps' and a'who' and go for it
<smoser> are other people seeing has sum msimatch ?
<smoser> http://paste.ubuntu.com/25765854/
<cpaelzer> smoser: yeah I who'd already which brough cyphermox on this list
<cpaelzer> translating the nic for mario ...
<infinity> smoser: Nope.  Looks like you have an angry proxy.
<infinity> smoser: Or a bitflip in your download.
<cpaelzer> Mmike: ^^ are you ok rebooting diamond as well ?
<cpaelzer> smoser: seen no mismatch in the last ~2 weeks or so
<cjwatson> $ curl -s http://us.archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dbg_2.26-0ubuntu2_amd64.deb | sha256sum
<cjwatson> 62aa80bdb27569a65b85ed19f21663fae456df5dd2d3108c3dd84afd19817b53  -
<cjwatson> Yeah, I'd check for proxies on your network path.
<cpaelzer> same sum as cjwatson here
<Unit193> Same here as well.
<infinity> He's getting the right file length, so a bitflip seems plausible.
<cjwatson> You could try wget --no-cache -O /dev/null http://us.archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dbg_2.26-0ubuntu2_amd64.deb   to see if that clears it.
<Mmike> cpaelzer, ack
<smoser> yeah. proxy ticked off. through the proxy i get different than not through it :-(
<smoser> wonder how that happened.
<cyphermox> cpaelzer: go for it.
<powersj> cpaelzer: go for it as well
<cpaelzer> powersj: cyphermox: slangasek: Mmike: smoser: done and up on 4.4.0-96-generic now
<cpaelzer> kvm guests working again, happy testing
<cpaelzer> I always wonder how "sudo ppc64_cpu  --smt=off" can take 8 seconds - maybe this goes to IBM india for sombody to ack and change a license code in the FW
<Mmike> cpaelzer, thnx!
<smoser> cpaelzer: fwiw, something left dpkg in a bad state
<smoser> i'm running dpkg --configure -a now
<smoser> then apt-get autoremove
<smoser> then i'm going to upgrade
<smoser> 0 upgraded, 0 newly installed, 37 to remove and 70 not upgraded.
<smoser> After this operation, 3,048 MB disk space will be freed.
<smoser> Do you want to continue? [Y/n]
<smoser> y
<smoser> Y
<smoser> :)
<smoser> 3G of old kernels
<cpaelzer> smoser: before I rebooted there was a apt daily hanging
<cpaelzer> maybe that was shutdown by the reboot in just the "right" moment
<smoser> cpaelzer: well, all up to date now.
<cpaelzer> thanks smoser
<tsimonq2> rbasak: Breaks might be a good idea... but if any one lands before the other, as long as they all land within an hour or two it'll be fine
<tsimonq2> (well, within a few hours of each other)
<tsimonq2> rbasak: If you'd prefer Breaks I can upload some new packages in 6 or 7 hours
<tsimonq2> But yeah, good point.
<rbasak> tsimonq2: it can break if you have a user with the security pocket enabled but not updates for example.
<rbasak> Because security will base upon updates.
<rbasak> So if there's a security update for one of those things (say indicator-gtk-whatever), and a user hasn't seen (and won't see) the update to lubuntu-meta, then the indicator will switch to pavucontrol even though pulseaudio isn't installed.
<rbasak> With a Breaks, apt will notice and either want to remove lubuntu-meta or refuse to update indicator-gtk-whatever. I don't know which - I'd need to test.
<rbasak> For security that might be worse of course. But apt is simply maintaining integrity according to what we declared (if we do).
<rbasak> One would hope that the security team would notice, but this would be very unusual so they might well not.
<rbasak> Adjusting and maintaining dependency changes in stable releases is hard :-/
<rbasak> tsimonq2: anyway, that's the potential consequence. I don't have a strong opinion here especially as the potential breakage isn't severe and is recoverable.
<rbasak> tsimonq2: if you want me to accept the current indicator-sound-gtk2 in the queue, I'd be happy to - just give me a +1 after you've considered the above please.
<rbasak> Since I think this should be your decision.
<tsimonq2> rbasak: Since I've been the one doing Lubuntu security updates for Universe packages, I'm willing to deal with the consequences if needed. +1, please accept.
<niedbalski> rbasak, any chance that you can review https://code.launchpad.net/~paelzer/ubuntu/+source/percona-xtradb-cluster-5.6/+git/percona-xtradb-cluster-5.6/+merge/332357 ? LGTM.
<rbasak> niedbalski, cpaelzer: sorry, I don't think I'm going to be able to get to it. cpaelzer is a core dev - please could you sponsor if you're happy, without me?
<niedbalski> rbasak, thank you for all your effort on this bug.
<rbasak> You're welcome.
<rbasak> I have a pile of things blocked on me right now, and the advice is to delegate more. So I'm trying :)
<v3n0m> Ubuntu 17.10 very slow boot time
<nacc> v3n0m: #ubuntu+1
<ignoo> Hello,running ubuntu GNOME 16.04, have some issues with ubuntu Artful Aardvark: https://pastebin.com/BgBHExes ; Thank you for your Support.
<mitya57> Does anyone know if we want to follow Debian and switch to OpenSSL 1.1 for 18.04?
<mitya57> xnox, ^^
<mdeslaur> depends if everything has 1.1 support
<mdeslaur> we don't want to support two different openssl versions for 5 years
<mitya57> I was wondering if we should aim at Qt 5.9 (LTS) or Qt 5.10 (which has OpenSSL 1.1 support)
<tsimonq2> The only downside I can see to doing that is that Qt 5.10 and on is needed and we'd (I wear {L,K}ubuntu hats when I say this) like to ship with Qt 5.9 in the LTS.
<tsimonq2> Yeah.
<mdeslaur> and 1.0.2 will be supported for longer than 1.1 by upstream
<tsimonq2> I'm also curious to see what the decision will be.
<tsimonq2> Another thing to consider (I *think*, could be incorrect) is that Qt 4 might not have OpenSSL 1.1 support. So while I would certainly like to reduce the number of rdeps on src:qt4-x11 over time, I don't know if thast can be done in time for the LTS.
<tsimonq2> Although in a perfect world I wouldn't mind if we could just kill Qt 4 already,,,
<tsimonq2> s/,,,/.../
<mdeslaur> worst case, openssl 1.0.2 can be in universe...but it would be a shame to have a crypto library being used that nobody is maintaining
<tsimonq2> True.
<tsimonq2> Regardless, Clever Cat might be a good cycle to tackle that in.
 * tsimonq2 shrugs
<mitya57> tsimonq2, for Qt 4 there is a patch in Debian BTS, not tested yet
<tsimonq2> mitya57: Hmmm, ok.
<mitya57> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#211
<ubottu> Debian bug 828522 in src:qt4-x11 "qt4-x11: FTBFS with openssl 1.1.0" [Important,Open]
 * mitya57 afk for some time
<tsimonq2> (iirc xnox does that sort of thing, I'm curious to see what he says)
<wxl> tsimonq2: . is a regex metacharacter. you'd need to escape that. ;)
<tsimonq2> wxl: True, but I'm assuming that IRC is somehow intelligent enough to interpret that. :P
<wxl> tsimonq2: remember that you're subtly training people how to use sed and find and replace in vim ;)
<tsimonq2> wxl: :%s/,,.
<tsimonq2> grr
<tsimonq2> :%s/,,,/\.\.\./
<tsimonq2> That should work.
<wxl> ;)
<tsimonq2> :)
<lamont> tsimonq2: on the right hand side, it doesn't need to be escaped.
<sarnold> no need to escape dots on the replacement side. also it's vim, regex stuff doesn't work right there anyway.
<wxl> aw dang, i lose!
<mdeslaur> nerds
<wxl> i resemble that remark
<tsimonq2> hehehehehe
<tsimonq2> lamont: And wait, you're right... I forgot what "." meant for a second there. :P
<tsimonq2> Makes sense.
<infinity0> LocutusOfBorg: as a hint for sagemath, i think it needs cython 0.26
<xnox> mitya57, tsimonq2 - ubuntu ships with openssl 1.0.1 so we are not affected.
<xnox> mitya57, we have not made decisions about that.
<xnox> mitya57, i really really really want to drop qt4 from the archive regardless.
<xnox> failing that, i want it in universe built against libressl but generally off my lawn.
<xnox> mitya57, we are monitoring the situation.....
<tsimonq2> Ok
<tsimonq2> xnox: I'm with you irt Qt 4 :)
<tsimonq2> The next KDE Applications release that Kubuntu puts in the archive finally makes KDE 4 unsupported.
<tsimonq2> So that'll be a major relief.
<tsimonq2> xnox: Otherwise, if you feel inclined: https://wiki.debian.org/Qt4Removal
#ubuntu-devel 2017-10-19
<smoser> bdmurray: sorry to pester you always. blackboxsw and I just uploaded another cloud-init to xenial and zesty.
<smoser>  cloud-init 17.1-18-gd4f70470-0ubuntu1~16.04.2 and cloud-init 17.1-18-gd4f70470-0ubuntu1~17.04.2
<smoser> if you could take a look in your sru time tomorrow we'd appreciate it.  its just one *very* tiny code change compared to what was already in -proposed.
<smoser> bug 1724354
<ubottu> bug 1724354 in cloud-init (Ubuntu Zesty) "WARNING in logs due to missing python-jsonschema" [Medium,Confirmed] https://launchpad.net/bugs/1724354
<mitya57> xnox: ack
<mitya57> tsimonq2: so let's plan Qt 5.9.3 and OpenSSL 1.0 for now
<cpaelzer> hey, if a former proposed upload failed (due to gcc7 now making it an FTBFS) is that one of the cases to buildpackage with -v <version before last> ?
<cpaelzer> to pick up in the changes file all effective changes that will hit the archive?
<cpaelzer> I'm rather sure it is corrct for this case, so uploading like that for now
<cpaelzer> but feel free to let me know if you tihnk otherwise would be better (and why)
<infinity> cpaelzer: Yep.
<test2222> hi all, could someone have a look at this Steam issue and give me a hint where I should raise another issue please? Not sure how to help the Valve guys: https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-337832330
* infinity changed the topic of #ubuntu-devel to: Artful 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:
* Laney changed the topic of #ubuntu-devel to: Artful 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-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<Laney> :-)
<sladen> +1
<sladen> "next please"
 * xnox is betting on Brisk Bustard
<infinity> xnox: What sort of animal is a Bustard?
<xnox> infinity, a bird
<xnox> https://www.google.co.uk/search?q=bustard&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwjm_bPs6PzWAhXLJMAKHXUyCLEQiR4IrwE&biw=1920&bih=990
<xnox> infinity, looks like a heron to me
 * mitya57 hopes 18.04 won't look like 8.04 because of that
<xnox> but i'm not into birds
<jbicha> breezier badger
<jbicha> edgier eft
<jbicha> too bad it doesn't well work for dapperer
 * Laney is going to lobby for Dabbing
<jbicha> the first 2 LTS were birds, I was thinking it was going to be a pattern, but nope
<Faux> Laney: <3
<xnox> Boring Bull?
<roadmr> hello, it looks like the mirrors serving 17.10 images don't support zsync :( https://pastebin.canonical.com/201018/
<cjwatson> I don't think we've ever pushed the zsync files to cloudfront
<cjwatson> it's probably a bug on the IS side that they're redirecting .iso.zsync as well as .iso
<roadmr> cjwatson: ugh - should I report this somewhere?
<cjwatson> roadmr: either IS on IRC or RT, I guess
<roadmr> cjwatson: will do, thanks!
<cjwatson> roadmr: I mean it'll be a short-lived problem, but maybe a process bug somewhere
<roadmr> yep, I guess once the thundering herd dies down things will point where they should
<cjwatson> (for completeness: I totally misread the pastebin, this is probably unfixable at our end)
<Sicnus> Who updates this file?  http://changelogs.ubuntu.com/meta-release  Also,d oes Dean H. (Beret) hang out here anymore?
<nacc> Sicnus: it will get updated
<nacc> Beret --^
<nacc> Sicnus: feels like you could just look at who is in the channel
<Sicnus> Beret: oheya Dean ;)   (Trae)
<acheronuk> now updated
<Sicnus> yeah thanks,  ;)  Just noticed.
<nacc> slangasek: would it be appropriate for me to SRU a MRE for php7.1 to artful, and not fix it in BB, given an intention to update to php7.2 in BB? That is, I could wait for BB to open, and do the fix there, then SRU, but I'm going to be replacing php7.1 with php7.2 in BB evenually anyways
<slangasek> nacc: what do you mean, "and not fix it in BB"?
<slangasek> nacc: if this is just about SRUing before BB is open, it's fine to start an SRU now and have us copy forward to BB when it opens
<nacc> slangasek: well, yeah I guess I meant that -- as in do I need to wait for BB to open
<nacc> slangasek: as my first plan of action for BB is to sync 7.2 and drop 7.1 anyways
<jbicha> nacc: y'all are targeting postgresql-10 for BB, right?
<nacc> jbicha: yeah, i believe so
<nacc> jbicha: it should line up well
<jbicha> Debian completed the transition so hopefully it'll be fairly smooth in BB too
<nacc> jbicha: yep
<nacc> slangasek: general development question; is 'devel' a valid changelog distribution only in ubuntu?
<slangasek> nacc: yes
<nacc> slangasek: thanks
<bdmurray> jbicha: In addition to commenting on bug 1721626, tagging it v-failed would have been helpful.
<ubottu> bug 1721626 in console-setup (Ubuntu Xenial) "Remove obsolete versioned dependency on initramfs-tools Edit" [Undecided,Fix committed] https://launchpad.net/bugs/1721626
<jbicha> ok, not clear whether there is a regression there or not, but probably would have been better to tag it like that until it can be investigated
<bdmurray> jbicha: Yes, because the report shows that SRU as releasable.
<infinity> bdmurray: The bug isn't in console-setup anyway, I'm sure.
<infinity> bdmurray: Pretty sure that's another manifestation of "sometimes plymouth --ping doesn't return".
<bdmurray> infinity: right, I was commeting on the process
<infinity> bdmurray: Oh yes, indeed.  I was going to v-fail it after I sorted out it was to blame.  And it clearly wasn't to blame, from a cursory view of the diff.  So, the real process failure was not removing the regression tags from the other bug.
<infinity> bdmurray: (That said, shouldn't a regression-proposed bug be scraped by sru-report and flagged up?)
<bdmurray> infinity: There is a bot that looks for bugs about packages from -proposed but that filters on ones reported by apport.
<infinity> bdmurray: Ahh, well.  Yay tools.  Another argument to push for britney-driven SRU migrations this cycle.  That block-proposed tag would have actually been useful. :P
<slangasek> infinity: yeah, was discussed at the SRU team meeting in NYC, I think we're ready to push on that this cycle
<tsimonq2> Excuse my ignorance but will all the uploads that have been 0-day SRU'ed into Artful be automatically copied to Bubonic Baboon once it opens or will developers have to do this on a case-by-case basis?
<LocutusOfBorg> I think the former
<LocutusOfBorg> otherwise we will end up with big b00bs being with lower versions than artful-updates
<tsimonq2> True, I just didn't know if Bubonic Baboon when created would copy including -updates and -security.
<tsimonq2> (And what about -proposed?)
<sarnold> I'd expect all but -proposed
<tsimonq2> sarnold: But why not -proposed? Those have the potential to land and might be greater than the one in Big Bat...
<sarnold> tsimonq2: because they might not land.. presumably there's few enough of them for real trouble
<tsimonq2> sarnold: I guess my point is is that once they *do* land, the version will be greater than Big Bat...
<hallyn> note on the artful desktop installer - run from inside a VM, the display always seems wrong, such that the 'continue' button for choosing a keyboard layout is off the screen, so you can't click it, have to tab over to it and guess that it is highlighted.
<nacc> hrm, i'm getting a Hash Sum mismatch on xenial-updates from archive.ubuntu.com in a LXD container
<sarnold> any chance ss or netstat still tells you which IP was used?
<nacc> anyone else seeing that (i'm seing it in autopkgtest)
<nacc> sarnold: let me see if it goes away if i refresh my local build env
<nacc> sarnold: autopkgtest-build-lxd didn't complain, so it must be something in my autopkgtest-lxd env
<sarnold> nacc: apt-cacher-ng? squid-deb-proxy?
<sarnold> everyone's reported one of them corrupts files and the other one works fine..
<nacc> yeah i think it must be acng
<nacc> sarnold: yep, that was it
<nacc> sorry for the noise, and thanks sarnold!
<sarnold> nacc: did you notice if it happened to serve up a different file than the one expected? i gave up on it when I saw that once..
<nacc> sarnold: I did not. Once i reran autopkgtest-build-lxd and used that image, it worked correctly
<sarnold> nacc: well, at least you're moving again :)
<nacc> sarnold: yeah :)
#ubuntu-devel 2017-10-20
* Unit193 changed the topic of #ubuntu-devel to: Artful Released | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<Unit193> (To further ammend Laney's pointing to #ubuntu, precise isn't supported anymore.
<Unit193> )
<dax> Unit193: so you could say you made the topic more precise by making the topic have less precise
<sarnold> *groan*
<Unit193> Hahaha. :D
<ArMedic> Is there a way to display the battery meter with a numerical output in 17.10?
<sarnold> ArMedic: you may have more luck in #ubuntu
<ArMedic> sarnold, Thanks, but thats why I came in here, no luck there.
<sarnold> oh. bummer.
<RAOF> Oh, huh.
<RAOF> I appear to have TIL-status on capnproto. Oops.
<RAOF> Dear lord!
<RAOF> Since when did C++ libraries start downloading code from github as a part of the build?!
<juergh> Trevinho, did you see my gjs_dumpstack() trace  in LP: #1714989
<ubottu> Launchpad bug 1714989 in GNOME Shell "gnome-shell crashed with SIGSEGV in g_type_check_instance_cast() from st_label_set_text() (dash-to-panel specific?)" [Critical,Incomplete] https://launchpad.net/bugs/1714989
<Unit193> "Well golang does it!"
<Trevinho> juergh: yes, and I submitted a fix on the extension for that right now
<Trevinho> juergh: https://github.com/jderose9/dash-to-panel/pull/263
<Trevinho> if you can test that change in your local extension it would be cool
<Trevinho> (just apply that diff to your file should work)
<juergh> Trevinho, sweet!
<juergh> Trevinho, I'll give it a try
<Trevinho> juergh: however I was askinf for other dumps to people having such issues with not that extension
<Trevinho> juergh: thanks
<juergh> Trevinho, I have another dash-to-panel dump. You don't need that, right?
<Trevinho> juergh: oh, why not
<Trevinho> juergh: feel free to send it
<juergh> Trevinho, http://kernel.ubuntu.com/~juergh/1714989/
<Trevinho> juergh: oh, that was the full crash i thought you menat a jhs_dumpstack
<Trevinho> but ok, this should be enough
<juergh> Trevinho, oh. :-P
<Trevinho> juergh: for reference, you were getting the crash ina repeatible way, or just... it happens?
<juergh> Trevinho, not repeatable but very frequent. there were actually two different types of crashes. 'simple' shell resets and real crashes that resulted in a dump.
<juergh> I just had another crash and a new dump file. I'll upload it.
<Trevinho> juergh: ok, using the patch I did or not?
<juergh> This is with your patch. So there might be different issues.
<Trevinho> ok, fair enough, let me know once you've it uploaded
<Trevinho> juergh: you reloaded gnome-shell after updating the file, right?
<juergh> Trevinho, yes
<Trevinho> juergh: [or alt+f2 -> r -> enter if in X]
<Trevinho> ok
<juergh> and it just crashed again. oh boy.
<juergh> Trevinho, http://kernel.ubuntu.com/~juergh/1714989/_usr_bin_gnome-shell.2000.crash-201710200842
<juergh> oh hold on.
<Trevinho> juergh: oh, if you can attach to gdb would probably be helpful
<juergh> I think that dump was replaced while I was uploading
<juergh> Trevinho, ack. let me attach gdb.
<Trevinho> juergh: I'm getting 403 on it though
<Trevinho> in both
<Trevinho> (even the old one)
<Trevinho> +r might be nice :)
<juergh> Trevinho, maeh. sorry about that. fixed now. but I removed the latest one, not sure if it's in a coherent state.
<Trevinho> juergh: well, is that unpacking with apport-unpack?
<juergh> Trevinho, I don't know what apport-unpack is, so I guess the answer is no? :-)
<Trevinho> it just unpacks your crash into usable data
<Trevinho> juergh: i mean you can check if it is valid at elast
<Trevinho> least*
<juergh> btw, I just uploaded a new dumpfile and stacktrace.
<juergh> this seems very unstable now...
<juergh> Trevinho, I reverted your patch. I just had another crash.
<Trevinho> juergh: so, the one I tested that was uploaded had the same issue..
<Trevinho> juergh: http://kernel.ubuntu.com/~juergh/1714989/stacktrace.201710200903 this was referred to the one with my patch or not?
<juergh> Trevinho, yes. with your patch.
<Trevinho> juergh: can you pass me the file too, so I have proper lines?
<Trevinho> home/juergh/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/windowPreview.js
<Trevinho> juergh: oh, i just noticed a typo in my patch
<Trevinho> juergh: so the patch you should actually apply is https://pastebin.ubuntu.com/25777475/
<Trevinho> for your version I mean
<Trevinho> juergh: full file will be https://pastebin.ubuntu.com/25777478/
<Trevinho> as extension stock version is different from master in GH
<juergh> Trevinho, that looks vastly different from github master.
<Trevinho> juergh: that's what is on gnome extension store
<Trevinho> juergh: when you installed the extension you should have got that version (minus the fix) no?
<juergh> Trevinho, at first yes. but when it kept crashing I switched to github master.
<juergh> Trevinho, what do you want me to test?
<Trevinho> juergh: oh, ok then try to use git master again with my patch
<Trevinho> juergh: and see how it goes
<Trevinho> juergh: (new patch, first one had a wrong leftover)
<Trevinho> which didn't cause any fix for sure
<juergh> Trevinho, just to be sure, you want me to test https://pastebin.ubuntu.com/25777475 ?
<doko> rbasak, jamespage: are there any transitions you would like to start with for b?
<Trevinho> juergh: that if you use the gnome-shell extensions website version, otherwise is https://github.com/jderose9/dash-to-panel/commit/1dfcd3e4b9e23fc2cd104be7a1e12c6fd4f18a46.diff
<juergh> Trevinho, this looks promising. I haven't had a single reset/crash since 11am'ish.
<andreas> hi, I want to SRU ubuntu-advantage-tools into trusty, xenial and zesty. The current version in artful is just "10", and t/x/z have "2". What should the version "template" be like for t/x/z? For example, considering x, 10~ubuntu0.16.04.1? Or 10~0ubuntu0.16.04.1? Summary: http://pastebin.ubuntu.com/25780812/
<andreas> slangasek: do you have a tip? ^
<johnnyfive> I am writing an implementation of the dpkg-scanpackages and other tools necessary for creating a full index in Go as a library. I am confused in one area. I can't seem to figure out which category/component (xenial-security/main) a package belongs to by reading the meta data from a .deb file. (
<sarnold> johnnyfive: that information is recorded in the apt lists
<nacc> johnnyfive: it's ot part of the deb
<nacc> you were told this yesterday
<nacc> (or whenever it was you asked the same thinng in #ubuntu)
<johnnyfive> nacc, lol, yes I was, my question has moved on to where that data actually exists, which nobody had an answer for.
<sarnold> johnnyfive: /var/lib/apt/lists/
<nacc> johnnyfive: you were told where then, too
<johnnyfive> ty
<nacc> johnnyfive: it's stored in the package lists
<johnnyfive> nacc, no I was not. sarnold, thanks!
<nacc> johnnyfive: https://irclogs.ubuntu.com/2017/10/18/%23ubuntu.html#t19:43
<nacc> took me a second to find it
<slangasek> andreas: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging as a guide; I think 10~ubuntu0.16.04.1 follows, but either of those numbers would work and I have no strong feeling
<johnnyfive> nacc, I stand corrected. I did not see that. However there has to be something upstream that makes those lists, but it's obvious that information is not available here
<nacc> johnnyfive: aiui, packages in main are seeded (see the seed files) or a dependency of a package in main.
<nacc> johnnyfive: i believe germinate is what figures out that full list
<nacc> universe is basically everything else, multiverse is non-free (from debian) and partner is a separate archive
<sarnold> what's the goal here? if you want to make your own archive mirror but after rebuilding all the packages, you might have more success with https://www.aptly.info/ or the apt-ftparchive package
<nacc> johnnyfive: as i said the other day, i thikn you're still better off workingn with ubuntu rather than forking if you think you are solvig a real security problem
<nacc> sarnold: i believe johnnyfive is doig an archive rebuild internally to do something like source-address-randomization
<nacc> where by source- i mean compile-time
<sarnold> nacc: yeah, thanks for the log link :) quite handy
<nacc> sarnold: aptly is a good reference, though, i forgot about that oe
<johnnyfive> nacc and sarnold, thanks for the answers. Let me try again. My repo serves 100s of variations of the same package, to different customers. At some point, there will be a need for creating indexes of an entire repo on the fly. This is part of my job, to create these repos.
<johnnyfive> and by "create these repos", I mean I'm given an output of /pool/main/<packages>, and I need to then create the appropriate index
<johnnyfive> however, as you stated, there is no meta information on the deb to tell me whether the file should be indexed in /dists/xenial/main or /dists/xenial-updates/main
<johnnyfive> if you run dpkg-scanpackages on /pool/main, it just shoves it all in the same index, without breaking it up into the correct categories
<nacc> the package lists only tell you the components ... you would need to follow the publishing iformation, as i mentioned the other day too
<nacc> or in your mirror + rebuild solution, save off the pocket things are in
<sarnold> johnnyfive: right. the same binary package can be included in lucid, precise, trusty, xenial, zesty, artful, etc.
<johnnyfive> so how does ubuntu/debian handle this? is there a build file when they are recreating an entire repo that tells the indexers which files to add to which pocket?
<johnnyfive> I don't know what you mean by "publishing information", are you talked about the apt sources list data?
<nacc> https://launchpad.net/ubuntu/+source/php7.0/+publishinghistory
<nacc> e.g
<sarnold> johnnyfive: if this were my problem to solve I thnk I'd skip launchpad, skip germinate, etc., and work strictly from the InRelease and Packages files from the mirrors
<sarnold> johnnyfive: stuff in your per-customer md5, sha1, sha256, hashes for all the per-customer rebuilds
<johnnyfive> sarnold, that's a def possibility. We have a few solutions, just really trying to understand how upstream does it.
<nacc> johnnyfive: also, just to be clear, you very clearly indicate to your customers they are not running Ubuntu? :)
<sarnold> heh I'm sure they pay enough to be sure of that :)
<johnnyfive> I assume that during the build process, some database is queried to figure out which indexes it needs to be added to
<nacc> sarnold: :)
<johnnyfive> yes, they know exactly what they are getting
<sarnold> johnnyfive: I think https://git.launchpad.net/germinate/tree/README?id=54c933eecf57cfa10526432740cc27f7b7671446 is the starting point..
<johnnyfive> Thank you both
<johnnyfive> i'll begin more digging. cheers
<sarnold> (germinate -might- only do the .iso images! I've been happy to let others manage this ;)
<cjwatson> johnnyfive: germinate is very probably too far back in the chain of events for your needs; for republishing an archive, you're better off looking at the override files in /ubuntu/indices/
<cjwatson> (germinate is involved, but as the input to human decisions, so you don't want to use it here)
<cjwatson> however, override files will tell you which component (main, restricted, universe, multiverse) things live in, but not which versions go in which suites (xenial, xenial-updates, zesty, etc.)
<cjwatson> for that, I agree with sarnold - if you want to know what suites packages are published in in bulk, you should look at the published Packages etc. files
<sarnold> cjwatson: oh cool, thanks. I've never actually looked in /ubuntu/indices/ before :)
<cjwatson> it is possible to derive this from Launchpad queries, but it will be excruciatingly slow to try it that way via the webservice API when you're doing things in bulk
<cjwatson> I mean, the Launchpad database is the ultimate source of truth on this and that's what we use, but it will be orders of magnitude faster to get that information from the Packages etc. files instead
<cjwatson> because you don't have direct database access
<Trevinho> juergh: cool, is it going smoothly still?
<cjwatson> you don't need the overrides given the Packages files, though it may make life easier to feed them to apt-ftparchive
<johnnyfive> cjwatson, awesome, ty for the info
#ubuntu-devel 2017-10-21
<acheronuk> mardy jbicha: can I believe reverse depends and say that nothing gnome or unity requires signon-ui any more in Artful or upcoming 18.04?
<jbicha> acheronuk: yes, only KDE uses that now
<jbicha> I mentioned that in the description for LP: #1695928
<ubottu> Launchpad bug 1695928 in storage-framework (Ubuntu) "Please remove obsolete UOA packages" [Undecided,Fix released] https://launchpad.net/bugs/1695928
<acheronuk> jbicha: that's what I though but needed to check. it's broken for KDE at the moment, and possible a fix might include rolling back to an earlier version undoing some commits to do with unity etc
<acheronuk> hence my concern
<jbicha> acheronuk: it's yours now, enjoy :)
<acheronuk> lol. yeah
#ubuntu-devel 2017-10-22
<michagogo> So whatâs next? The Abnormal Abalone?
<michagogo> (I guess there are a lot of âabâ adjectives, actually.
<michagogo> )
<juliank> slangasek: I just want to note again (I just sent a comment to the bug) that SuggestsImportant=true was not my idea, I just present the arguments for it. The compromise I just posted seems reasonable, but I'm not strongly opposed to setting it to false (DonKult may be), I just want everyone to have a complete view of the problem.
<mardy> acheronuk: hi! GNOME certainly does not depend on signon-ui, but Unity should, if you want to have the Online Accounts panel in it
<mardy> acheronuk: Unity8 does not require it, though
<juliank> Oh, I see DonKult also replied.
<juliank> Currently, you could basically run autoremove in a cron job and be safe.
<juliank> With SuggestsImportant=false, that's not really the case :D
<acheronuk> mardy: well, it's reverse depends seem to show nothing for unity 7
<mardy> acheronuk: it's required by unity-control-center-signon, IIRC
<acheronuk> mardy: anyway, at the moment it's completely broken for KDE, who are the only ones who will continue to use it
<mardy> acheronuk: do you have links to any bugs?
<acheronuk> mardy: https://gitlab.com/accounts-sso/signon-ui/issues/1
<acheronuk> mardy: unity-control-center-signon was a removed in artful
<acheronuk> mardy: trailing comments on bug #1070873
<ubottu> bug 1070873 in signon-ui (Ubuntu) "kde-telepathy, impossible to connect to gmail accounts" [Undecided,Confirmed] https://launchpad.net/bugs/1070873
<acheronuk> mardy: plus one or 2 others that are marked private at the moment, like #1723230
<mardy> acheronuk: well, AFAIK gmail's chat has long been broken with XMPP, it has very little to do with signon-ui
<acheronuk> mardy: well, at the moment only KDE used it. and it crashes. only solution I have is to re-upload 0.17+17.10.20170606-0ubuntu1
<acheronuk> 0.17+17.10.20160406-0ubuntu1 I mean
<acheronuk> mardy: I will make a new bug if required
<acheronuk> mardy: will be getting kio-gdrive into 18.04 which requires a working version of signon-ui that doesn't crash when invoked by KDE's systemsettings, so need to fix this one way or another
<mardy> acheronuk: let me comment on https://gitlab.com/accounts-sso/signon-ui/issues/1, I'm afraid I know what the problem is
<acheronuk> anyway, will have to come back to this. Sunday lunch calls
<acheronuk> mardy: ok
<mardy> acheronuk:
<mardy> acheronuk: ops, I meant to say: if I provide you with a signon-ui branch, will you be able to test it in KDE?
<acheronuk> mardy: yep. really have to go now. will be around all the coming week
<KeepItInside> !history launchpad test
<ubottu> KeepItInside: I am only a bot, please don't think I'm intelligent :)
<KeepItInside> LP: #1714989
<ubottu> Launchpad bug 1714989 in GNOME Shell "gnome-shell crashed with SIGSEGV in g_type_check_instance_cast() from st_label_set_text() (dash-to-panel specific?)" [Critical,Confirmed] https://launchpad.net/bugs/1714989
<KeepItInside> sorry on my HTC desire :(
<KeepItInside> ikonia hows xubuntu aardvark ?
<slangasek> juliank: yeah; considering our stock Ubuntu package management stack does *not* call autoremove at any point except between release upgrades, and aptitude cli has a pathological resolver, I stand by my position here
<slangasek> juliank: it's clear that we shouldn't change this setting in SRU, but we should get it fixed for 18.04 so that we can get everyone cleaned up on the next upgrade
<juliank> slangasek: What about the compromise I proposed?
<juliank> It would protect the careless users, and it also gives the careful users the control they want
<juliank> Of course, apt autoremove could also ask: Do you also want to remove the packages still Suggested? or something. Then you have two bool prompts
<juliank> kind of odd
<slangasek> juliank: what I care about is what the Ubuntu system does by default; if this has to be implemented upstream by adding yet another knob to apt because no one wants to change the behavior of the existing interfaces, then that's acceptable, I just think it's a waste of effort
<juliank> slangasek: I'd say: Removing packages with reverse suggests on a release upgrade should require confirmation with each package being listed with its reverse suggests. But I think people are already used to release upgrades breaking their system, so it's not that much of an issue there as it is with autoremove.
<slangasek> I have a seriously hard time with any of this being termed "breaking the system"
<slangasek> it's expected that the default behavior is different after a release upgrade and that the user might have to make adjustments
<juliank> slangasek: It's just an overstatement :D
<juliank> More accurate would be: Removing functionality they might be relying on that has been deprecated
<slangasek> I also think that it would be appropriate to change the default behavior of apt autoremove in a new release, while definitely not SRUing it backwards
<slangasek> because then you have gone through a release upgrade and dealt with the autoremoval once
<slangasek> and either manually re-added those removed packages or not
<slangasek> and once upgraded, package dependencies aren't going to change, so you're not going to have new autoremovals suggested as a result of changed deps within the release
<slangasek> only as a result of you specifically removing something and then wanting to clean up
<juliank> Oh, it would be appropriate. But I'd rather have two stages of autoremovals for the apt(-get) usage I think. The release upgrading code is free to run with suggestsimportant set to false
<juliank> Imagine if we could reach a point where we can just do autoremove in unattended-upgrades. that's the goal, but we're not there yet.
<slangasek> juliank: well, as the recent discussion on the other bug wrt auto-marking of metapackage deps, we seem to have moved quite far away from it being safe to run autoremove as part of unattended upgrades :/
<juliank> slangasek: Not sure what you're referring to. The only thing I remember is that the metapackage handling improved so "remove metapackage" also keeps the dependencies auto, but if the metapackage is removed implicitly, then they're not. And that's really the best of both worlds.
<juliank> So, yes, if you do apt remove ubuntu-desktop and then autoremove, ubuntu-desktop is completely gone.
<juliank> But you just asked apt to remove ubuntu-desktop so ...
<slangasek> juliank: well, I don't think it's the best of both worlds that you could 'apt remove ubuntu-desktop' and have it keep running, until the next time unattended upgrades runs :)
<juliank> slangasek: So, let's automatically do autoremovals, like aptitude?
<slangasek> maybe
<slangasek> not sure that would make it SRUable still; and we do need to fix behavior in stable releases wrt lack of autoremoval of kernel packages
<juliank> Well, autoremove removes kernel packages.
<juliank> But unattended-upgrade has its own handling I think
<juliank> slangasek: apt's next release cycle is starting *now*, BTW. Adds seccomp() sandboxing to methods, so I'd expect some breakage outside amd64.
<juliank> I think the compressed index change has to move to 18.10, there's a security issue it would open up (or a regression in file:/ repositories not accessible by _apt)
<slangasek> seccomp itself is well supported on !amd64, provided you don't wrongly encode an x86-specific list of syscalls :)
<juliank> slangasek: I basically took a list of all syscalls on amd64, and a list of all syscalls that differ between architectures, and combined that.
<juliank> libseccomp has some magic in there, so I hope it works out fine
<juliank> And you can turn it off or allow or trap additional syscalls via config options :D
<juliank> so, you could do apt -o APT::Sandbox::Secomp::Trap::=read and the read syscall causes SIGSYS :D
<juliank> So for example, I have whitelisted both fchown and fchown32
#ubuntu-devel 2018-10-15
<xnox> Laney, libcolord:ERROR:../lib/colord/cd-test-daemon.c:1873:colord_device_func: assertion failed (error == NULL): failed to obtain org.freedesktop.color-manager.create-device auth (cd_client_error, 2) how bad is that?
<Laney> RAOF:
<seb128> xnox, what do you do to trigger that?
<Laney> autopkgtests
<seb128> ah
<RAOF> Grumble
<RAOF> <freenode_xno "Laney, libcolord:ERROR:../lib/co"> Looks like it might be failing to get policykit authorisation, which would make sense because the autopkgtest wouldn't run in an at-console environment?
<RAOF> (although I recall it passing on my system, but that would have been either as root or probably at-console)
<tjaalton> ahasenack: hi, samba-common-bin postinst seems to fail, "testparm -d1 --suppress-prompt" gives an error if smb.conf is not available
<ahasenack> tjaalton: you mean, if you install just samba-common-bin?
<tjaalton> ahasenack: something like that. I'm not sure why I have it installed
<ahasenack> tjaalton: cosmic?
<tjaalton> yes
<ahasenack> taking a look
<ahasenack> tjaalton: "sudo apt -f install" is clean?
<tjaalton> yeah
<ahasenack> tjaalton: samba-common-bin pulls in samba-common, which is what creates /etc/samba/smb.conf in postinst
<tjaalton> hm, something deleted it
<tjaalton> ok
<tjaalton> nevermind
<tarzeau> if i rebuild libceres-dev (and re-install the newly built debs), colmap (3.5-1) builds just fine... what should i do aboutthat?
<tarzeau> that'd also fix #908833
<ddstreet> slashd sil2100 rbasak cpaelzer arges chiluk jbicha caribou smoser you have all worked with or sponsored me some time in the past; I'm applying for coredev, if you have time please consider endorsing or commenting on my application https://wiki.ubuntu.com/ddstreet/coredeveloper
<ddstreet> thanks!
<ahasenack> ddstreet: you can use this service for sponsored uploads, it was restored after alioth's decomissioning: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<ahasenack> ddstreet: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=dan+streetman&sponsoree_search=name looks like
<ddstreet> ahasenack cool, thnx
<coreycb> doko: is python 3.8 slated for 18.04?
<ddstreet> tsimonq2 fyi the dmb agenda still lists 'next dmb meetings' as the past ones from sept
<tsimonq2> ddstreet: ack, thanks
<mwhudson> coreycb: yes
<coreycb>  mwhudson: thanks
#ubuntu-devel 2018-10-16
<doko> coreycb: yes, that's what I'm aiming for
<doko> coreycb: ehh, wait, 20.04 ...
<doko> oSoMoN: how was the lo autopkg test failure resolved (the one which failed with OpenJDK 11)?
<oSoMoN> doko, not fully resolved yet, the failing test was apparently ignored to allow the promotion of openjdk 11
<oSoMoN> doko, but I have a decent understanding of the problem and IÂ know how to fix it, just trying to get to a consensus with upstream
<doko> oSoMoN: ta
<coreycb> doko: ok thanks. i'm trying to get 3.7 unit tests enabled upstream and also expressing the need to be more proactive upstream with testing python3.
<rbasak> Somebody in #ubuntu-server has: https://www.irccloud.com/pastebin/2uSLUZYU/
<rbasak> shim from trusty-updates is being installed with only dpkg in the trusty release pocket, which explodes because dpkg in the release pocket doesn't understand xz.
<rbasak> Is there some mechanism that should be making sure that dpkg gets updated first?
<rbasak> Maybe juliank knows? ^
<juliank> rbasak: Pre-Depends on dpkg
<juliank> appropriately versioned of course
<juliank> rbasak: But I think hte problem is that we binary copied the shim down
<juliank> and built it with xz inthe first place
<rbasak> Yeah I need to double check but I don't believe it had a Pre-Depends - I looked for that.
<rbasak> So that's a regression-updates bug then?
<juliank> dpkg in updates does have support for control.tar.xz though
<rbasak> This user is preseeding.
<rbasak> So dpkg doesn't get updated before shim does in this case it seems.
<juliank> yes, which means shim needs either a Pre-Depends on the right dpkg version or compressed without uniform compression
<rbasak> OK I'll ask the user to file a bug.
<juliank> (the problem here is xz compressed control files, not xz in general)
<rbasak> Yep
<juliank> So overrding dh_builddeb to dh_builddeb -- --no-uniform-compression
<juliank> should do the trick
<rbasak> sil2100: looks like you'd copied shim back? ^
<juliank> oh and the other is Pre-Depends: dpkg (>= 1.17.5ubuntu5.8~)
<sam_w> rbasak: re: reporting this... https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1792497
<ubottu> Launchpad bug 1792497 in shim (Ubuntu) "package shim (not installed) failed to install/upgrade: subprocess dpkg-deb --control returned error exit status 2" [Undecided,Confirmed]
<sam_w> us
<juliank> see bug 1730627
<ubottu> bug 1730627 in dpkg (Ubuntu Trusty) "xz compressed control.tar files not supported" [Medium,Fix released] https://launchpad.net/bugs/1730627
<sam_w> *I think this is the same issue?
<juliank> sam_w: seems like it, but logs are broken
<rbasak> Yeah I was just about getting to that conclusion
<rbasak> Seems very likely though
<sam_w> as in logs on the bug report? I can probably provide some
<rbasak> I pasted yours in a comment.
<rbasak> Your pastebin is enough to tell us what's going on.
<sam_w> rbasak: cool
<rbasak> sam_w: thank you for the report! I think what's needed to fix it is understood, but shim is somewhat complicated to handle so I'll wait for the right people to appear to handle it.
<sam_w> rbasak: no worries, will subscribe to updates from that bug...
<sarnold> Trevinho: hello, can you take a look at 1797012 ? :) thanks
<xnox> tsimonq2, i do not provide any support over PM
<xnox> tsimonq2, please always use a public channel
<tsimonq2> xnox: ack :)
<mwhudson> could some kind soul do a git ubuntu import of cargo?
<rbasak> mwhudson: now running
<mwhudson> rbasak: thanks
<mwhudson> rbasak: i would like to talk to you about getting my splitting up of the rustc delta into the import branch so i can use it again at some point but it must be rather late for you...
<rbasak> It's fine, I'm awake.
<rbasak> Have you uploaded anything b ased on your splitting up yet? A new package merge perhaps?
<mwhudson> yes i followed the wiki instructions on pushing i think
<rbasak> To get the importer to adopt rich history it has to be given the rich history before it sees the upload.
<mwhudson> i haven't uploaded anything to ubuntu yet
<mwhudson> yeah i ran git push mwhudson  merge old/debian new/debian old/ubuntu reconstruct/1.28.0+dfsg1+llvm-0ubuntu2 deconstruct/1.28.0+dfsg1+llvm-0ubuntu2 logical/1.28.0+dfsg1+llvm-0ubuntu2
<rbasak> I see
<rbasak> And that merge branch is ready for upload?
<mwhudson> mwhudson being ssh://mwhudson@git.launchpad.net/~mwhudson/ubuntu/+source/rustc
<mwhudson> er, more or less
<mwhudson> there are some subsequent changes
<mwhudson> hmm i guess i'm not actually going to upload 1.28.0+dfsg1+llvm-0ubuntu2, there is going to be an upstream update
<rbasak> The idea is that, eventually, anyone who wants to adopt the workflow will always give (via a wrapper around dput or something) the importer the rich git commits before dput runs.
<rbasak> When the importer sees the upload published in Launchpad, it will use the rich history supplied, if it matches.
#ubuntu-devel 2018-10-17
<mwhudson> ah ok so you need to give it the rich commits at the time of upload, in some sense
<rbasak> Right now this works but you have to go via someone in ~usd-import-team to supply the rich history before you dput (and it must match what you will dput eactly)
<rbasak> If the importer hasn't been given the rich history or if it doesn't match the upload exactly, it will synthesize a commit instead
<mwhudson> makes sense
<rbasak> I have a script here that will do the work for me if you have an MP
<mwhudson> i guess it's those {logical,reconstruct,deconstruct}/$version tags it's looking for?
<rbasak> The importer actually looks only for an "upload" tag currently.
<mwhudson> ok well i'm still not 100% sure what i'm going to upload
<rbasak> And all I need is the branch tip of your proposed upload to tag.
<mwhudson> so when i do, i'll push and see if i can get you to tag it before i upload
<rbasak> When you have it ready, throw it into an MP please. I have a script I can throw an MP at, and it'll create and send the upload tag to the importer.
<mwhudson> ack
<rbasak> This is only temporary. Eventually I hope that we'll have better glue for this missing piece.
<mwhudson> sure
<mwhudson> do you expect to get time to work on this in the next cycle?
<rbasak> I intend to shore up the importer as it stands this coming cycle. The workflow glue I don't expect to do this cycle, sorry.
<mwhudson> ok
<rbasak> Though there is a Launchpad feature coming (ref-based ACLs) which may mean that we can allow uploaders to push their own rich history directly as a better stop-gap.
<mwhudson> are the launchpad changes i've seen go by about per-ref permissions related to this?
<mwhudson> ah haha
<Tecan> was wondering if ubuntu is going to join the OIN openinventionnetwork to gain access to the recently opensourced 60k patents microsoft gave
<Tecan> could make it easier for pc manufacturers to bundle ubuntu with their hardware
<sarnold> Tecan: https://www.openinventionnetwork.com/community-of-licensees/
<Unit193> Gain access to?  Doesn't quite sound entirely 'open source'
<xnox> sarnold, oooh nice. didn't know we are associate member.
<sarnold> now to do something fun with those patents! :)
<sarnold> a buddy who spent a summer at Sun said they got a patent on subtraction once.. maybe that's a good starting point.
<Unit193> Interesting results when one searches that page for 'buntu'
<jbicha> I was contacted once by them a long time. They wanted UGR to join. I explained that I had almost nothing to do with that project and I didn't think it made any sense for them to be trying to target such small new distros
<jbicha> that was https://launchpad.net/ugr which was separate from what later became Ubuntu GNOME
<jbicha> long time ago
<jbicha> they only had 332 licensees then!
<sarnold> heh :)
<sarnold> now they've got *thousands* many of which surely must still exist :) heh
<jbicha> https://distrowatch.com/search.php?status=All only has 895. It's funny that Distrowatch has much higher standardsâ¦
<sarnold> that seems low :)
<jbicha> Distrowatch wouldn't add Ubuntu GNOME until we had a website
<jbicha> it's funny because we were already approved by Ubuntu's Tech Board by that point
<jbicha> oh and they wanted a logo
<mwhudson> urgl
<mwhudson> rbasak: pristine-tar is refusing to checkout one of the orig's from the cargo import you did
<mwhudson> git branch --track pristine-tar pkg/importer/debian/pristine-tar
<mwhudson> pristine-tar checkout cargo_0.30.0.orig-vendor.tar.gz
<mwhudson> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
<mwhudson> it's not important, i can get the file from debian of course, but it's a bit surprising
<rbasak> mwhudson: the pristine-tar stuff sometimes breaks
<rbasak> nacc (not here) better knows the failure cases I think.
<rbasak> I believe there are bugs filed in Debian on it.
<rbasak> So right now the importer is best effort on that only.
<mwhudson> yeah i know some people don't really trust it, maybe i'm about to join the ranks
<mwhudson> fair enough
<rbasak> I'm less focused on it since we don't worry about the pristine-tar hashes being reproducible, since that won't affect anything in practice as it's just used as a file store.
<rbasak> So we can fix it later and force push the pristine-tar branches if needed, once whatever is broken is fixed (somewhere between gbp import-orig and pristine-tar I think)
<mwhudson> true
<rbasak> We have an experimental subcommand "export-orig" that tries to get the orig tarball(s) from all the possible sources (you already have one in parent directory, pristine-tar, Launchpad I think)
<mwhudson> in this case https://launchpad.net/debian/+source/cargo doesn't have the one i want, i want the one from experimental
<mwhudson> oh wait yes it does
<mwhudson> https://launchpad.net/debian/+source/cargo/0.30.0-1~exp1, nice
<rbasak> In theory you should be able to check out pkg/debian/experimental and run git ubuntu export-orig I think. Not sure what'll happen though!
<mwhudson> rbasak: https://paste.ubuntu.com/p/r8m76CRbqG/ oh well!
<rbasak> :(
<ahasenack> Laney: if you have a moment, could you help me troubleshoot two things in autopkgtests please, if there are logs: a) https://bileto.ubuntu.com/excuses/3487/xenial.html stuck for hours
<ahasenack> Laney: b) https://bileto.ubuntu.com/excuses/3486/trusty.html tests didn't run, but the package has them (unless I made a super silly mistake, but I can't see it)
<ahasenack> these would be new tests, this package had none so far
<jbicha> ahasenack: I can't run autopkgtests for packages in my PPA (on autopkgtest.ubuntu.com) if the package in Ubuntu doesn't have autopkgtests yet. I don't know if Bileto is special.
<ahasenack> yeah, there could be some quirk because of that, and also because it's an old release perhaps (trusty, xenial not that old)
<ahasenack> I'm at a loss there. They run locally at least, I might as well just propose it as is and see what happens for real when it's uploaded
<rbasak> Trevinho: around?
<rbasak> I'm quite confused by your nautilus SRU uploads.
<rbasak> "Fix unpaired unref on search engine" - that doesn't seem to be in Cosmic, for example?
<Trevinho> rbasak: yes
<Trevinho> rbasak: this is the upload where it is included in cosmic https://launchpad.net/ubuntu/+source/nautilus/1:3.26.4-0ubuntu7
<Trevinho> rbasak: it's not a bug in bionic though, so I've not mentioned it as the bug
<rbasak> Ah, I see. Sorry, my git-ubuntu view is behind.
<rbasak> Presumably I can reject the previous upload that the latest one supersedes?
<rbasak> Trevinho: the changes file for your latter upload should really include the changes in .2. Or better, squash .3 into .2 as .2 isn't going to end up being used anyway.
<Trevinho> rbasak: yeah, well it was a reupload, after discussing with seb128 we decided to keep as it is not to break our vcs as we already released the version there.
<Trevinho> avoiding force-pushes
<Trevinho> but if you want we can fix and revert that.
<seb128> rbasak, it's the same bug referenced in both entries, but I can reupload with -v if you want
<rbasak> seb128: it will make bionic-changes accurate, so while we're both here you might as well please
<seb128> rbasak, k, currently busy/in a meeting but I look at it after that
<rbasak> FWIW, that workflow in general (avoiding force pushes to VCS, releasing before SRU acceptance) is broken. What if the SRU team reject an upload requesting a material change to the upload? What will you do then?
<seb128> rbasak, well, bumping the version and doing -v is always a valid option
<rbasak> That'll get really confusing if an SRU contains a bunch of versions in the changelog (and changes file) that never actually landed.
<rbasak> Including reverts of previous changes, etc.
<seb128> yeah, not optimal
<seb128> but having things uploaded but not pushed to the vcs isn't either
<seb128> because then others might do conflicting work
<seb128> no perfect solution :/
<rbasak> I suggest pushing to VCS, but don't push tag until the SRU is accepted, and use a "pending" branch or something.
<rbasak> It'd accurately reflect reality then.
<Trevinho> yeah, keepingin UNRELEASED until actually lands on ubuntu in the vcs would be the way
<Trevinho> right... that would be the way. For next times :)
<Trevinho> well, vcs-side
<rbasak> Other developers can choose to develop against the pending branch, but also know that if the SRU is rejected they'll have to rebase, which is the reality anyway.
<seb128> that doesn't solve the "force push" issue
<rbasak> No force push then.
<rbasak> Well, I suppose you'd have to delete the pending branch if the SRU is rejected.
<rbasak> However that is the reality.
<rbasak> It's the same as a work branch for an MP being rejected.
<rbasak> One thing I'd like to see eventually with git-ubuntu is SRU reviews taking place in MPs.
<rbasak> Then at queue unapproved time, it's just "a MP matching this upload was already SRU-reviewed a +1? Accept".
<rbasak> The reason we generally want to avoid force push is because it inconveniences others developing against it. In the case of an SRU reject, that _itself_ forces developers already developing against it to rebase. So the actual mechanical force push itself adds nothing further.
<rbasak> So in this case, I think "force push bad -> shouldn't do it" is inappropriate. It's effectively already happened thanks to our existing SRU process, outside VCS.
<enaut> Hey guys, I'm trying to generate the man pages with help2man which requires to run my python program during package build. It does run on my system but in the ppa builder it fails. I tried adding dependencies but still get an error during build.
<enaut> The logs are here: https://launchpadlibrarian.net/393680409/buildlog_ubuntu-bionic-amd64.ltsp-manager_18.04.2ubuntu5+355~git.f6bfc95~ubuntu18.04.1_BUILDING.txt.gz
<enaut> Also info on how to get more specific error messages would be interesting.
<rbasak> enaut: have you tried building locally in an isolated environment, eg. with sbuild?
<rbasak> Trevinho: I don't follow what the change from search_thread_add_hits_idle to search_add_hits_idle has to do with the SRU bug being fixed.
<Trevinho> rbasak: that was code submitted upstream too, so there was some refactory involved which is not strictly needed. Speaking of that change it's not related to the SRU bug (the patch is, as indicated in the changelog). This was needed for fixing a crash that was not yet in bionic but was a potential one since it appeared upstream (and in cosmic with https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1797851)
<ubottu> Launchpad bug 1797851 in nautilus (Ubuntu) "/usr/bin/nautilus:11:g_type_check_instance_cast:NAUTILUS_SEARCH_PROVIDER:nautilus_search_engine_stop:stop_search:disconnect_model_handlers" [High,Fix released]
<rbasak> Trevinho: SRU policy is that bugfixes must be minimal though?
<Trevinho> rbasak: I think changelog entry is wrong indeed (i think I pasted the same bug number -_-), anyway sure it is; but I don't see the point of not fixing things that you know will be wrong early enough.
<Trevinho> I mean, I don't like the pythonic way of try, catch when I can use an if first :)
<Trevinho> let me fix the changelog though, as I didn't want to mention the bug at all initially, since wasn't there bionic, and at this point stash the changes (<- seb128)
<Trevinho> if you don't want that patch too, is fine, but there was a memleak and a crash on destruction which is documented upstream. So up to you.
<rbasak> Trevinho: it's fine to fix bugs, but I'd rather see them documented properly rather than hiding in some other changes.
<Trevinho> no, it wasn't hidden.. At the countratry I also asked seb before about that. I can be more verbose on changelog if you want.
<rbasak> Otherwise it becomes insanely difficult to review, which is already the case with this upload due to the other messing about with multiple uploads, touching patches multiple times, etc.
<rbasak> Trevinho: I'm not really sure I follow, since I'm not sure what you intend exactly. From my POV, the changelog needs to explain every change made in the upload, and link all the bugs being fixed. So no extra changes that aren't covered by the changelog, and no bugs being fixed for which there is no bug reference in the changelog.
<Trevinho> rbasak: well, if you want a bug then we need to upload first the version without those changes, wait for crashes to be reported (I guess will be one day), and then to resubmit the SRU. Otherwise we don't have a way to verificate something that didn't happen yet.
<Trevinho> Also there was a mem-leak fix in the upload which is a bug, but hard to verify.
<seb128> rbasak, that's the case there, there is one fix, and 2 changelog entries for it, one being "fix issue" and the other one is "fix the same issue harder"
<rbasak> Trevinho: we're flexible in SRU verification requirements based on the individual situation. So if you explain in the SRU paperwork in the bug what the situation is wrt. reproduction, but can show that the bug is real and ought to be fixed in an SRU, then we can consider that and make a decision. But for that to happen, you need to have written up that explanation. In a bug. That you link to from the
<seb128> which imho is not confusing
<rbasak> changelog.
<rbasak> seb128: the search_thread_add_hits_idle change in the upload isn't related to that bug though.
<Trevinho> nope...
<Trevinho> so let me open a bug for that where I explain things, and verification will be just not needed there though
<Trevinho> if that's the way that should be done.
<seb128> well, you need some sort of verification
<seb128> would it be only "test there is no regression in that feature"
<rbasak> I'm happy for it to be done that way. I don't intend to mandate any particular mechanism, but what I am mandating is that a decision on whether to include a particular fix or not is ultimately an SRU team decision, and you can't bypass it by just bundling the change and not mentioning it.
<seb128> right, sorry about that one
<seb128> I was in a meeting and didn't properly follow the details of the discussion, I though you were arguing about having 2 entries rather than 1 merged with the follow up fix
<seb128> we are going to fix that problem
<rbasak> Thanks.
<seb128> rbasak, Trevinho, nautilus reuploaded
#ubuntu-devel 2018-10-18
<rbasak> sil2100: o/ I have a request to review qemu from the SRU queue so I'll look at that now.
<rbasak> (unless you're already on it which seems unlikely given the current size of the queue :-/
<Unit193> rbasak: BTW, any news?
<rbasak> Unit193: on?
<sil2100> rbasak: hey! Thanks for the heads up, I'm on the release sprint today so I essentially had no time for SRU queue reviews
<sil2100> s/today/this week/
<Unit193> PM.
<Laney> AM
<Unit193> Laney: Fixed the factoid, as requested.
<Laney> thx
<coreycb> doko: i imagine that if 20.04 were to have python 3.8 it would be in 19.10 as well to help stabalize things. is that correct?
<coreycb> doko: there's a lot of brainstorming going on with upstream openstack to figure out how to catch up and test better. they currently only test on the latest LTS but i'd like to propose that they test on the latest release (LTS or interim). not a release under development as that's not realistic for a voting gate.
<doko> coreycb: I doubt about 19.10, because it's not yet released at this time. So maybe an alpha or a beta
<coreycb> doko: ok, that'll be harder to get any testing upstream then unfortunately until after 20.04 releases
<coreycb> doko: maybe some non-voting tests but those will likely just get ignored
<doko> coreycb: https://www.python.org/dev/peps/pep-0569/
<doko> so probably a 3.8 release candidate in 19.10
<doko> and updating that later
<coreycb> doko: if we could make a statement like that it would be great. ie. we'll release 19.10 with a beta or rc based on what's available at the time, and update it to the final version after release (reference pep 0569 for schedule)
<coreycb> doko: seem reasonable for me to say that?
<doko> coreycb: sure, but this will be as in 18.04 an "unsupported" version, no extensions built for it yet
<coreycb> doko: i think that's fine. tests are run in a venv. thanks!
* tsimonq2 changed the topic of #ubuntu-devel to: Archive: Closed | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<tsimonq2> infinity, vorlon: That's sane, right? &
<tsimonq2> s/&/^/
<vorlon> tsimonq2: lgtm
<tsimonq2> Cool.
<mwhudson> should i be surprised that libhttp-parser-dev doesn't install a .pc file?
<sarnold> I'm certainly surprised
<sarnold> it's 2018 right? :)
<mwhudson> good i am glad someone else is surprised
#ubuntu-devel 2018-10-19
<mwhudson> Laney: should "gtk, kde: Start installing after ubi-timezone" and "kde, gtk: Wait for both timezone and partman_commit before installing" from ubiquity go to bionic?
<Laney> mwhudson: Pretty sure that bug exists there, so it could do, yeah
<mwhudson> Laney: well they cherry pick cleanly at least...
<Laney> mwhudson: Right, well if you're planning an upload, feel free to toss 'em in (squashing the commit message). If you don't want to verify that it does happen on bionic and SRUify the bug, I could look at that on Monday.
<mwhudson> Laney: https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/357167
<Laney> cheers
<Laney> I'm supposed to be off today though so I'll have to do that on Monday (you could grab sil2100 if you wanted)
<Laney> on that note, /me fades away
<mwhudson> Laney: https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/357167
<mwhudson> ah ok
<seb128> Laney, enjoy the day off :)
<mwhudson> Laney: well i'm at 20:00 on friday and i'm off on monday so i'm sure not going to do it now :)
<tarzeau> will someone update zram-config to latest debhelper,standards versions and systemd? i have suggestion as comments at #1270913
<Shibe> Hi, I just upgraded to ubuntu 18.10, and XDG_RUNTIME_DIR is now unset?
<Shibe> I tried launching weston but it told me there was no XDG_RUNTIME_DIR, and /run/user/1000 is also empty
<Shibe> is this intentional or did i screw something up in the upgrade?
#ubuntu-devel 2019-10-14
<alkisg> infinity: got it, I had to put the path in the "mount source" of the mount command, as a signal so that snap-confine would generate the appropriate apparmor rule
<alkisg> Funny, 10 hours to change 1 word :D https://github.com/ltsp/ltsp/commit/d06c08fae8c00d3ca7f63f080a19ede9500f5b14
<TJ-> Is this a bug in "man 1 sbuild" EXAMPLES section? "distribution is inferred from debian/copyright"
<rbasak> Surely yes if it says that!
<cjwatson> TJ-: Yes.  I can just fix it here - do you want some kind of "reported by" credit and if so what?
<TJ-> cjwatson: no thanks... just remove the confusion it caused me when I was forgetting how to use sbuild :)
<TJ-> I started to doubt my mastery of changelog :)
<cjwatson> TJ-: fixed upstream, thanks.  https://salsa.debian.org/debian/sbuild/commit/fc306f4be0d2c57702c5e234273cd94b1dba094d
<TJ-> cjwatson: looking at some of your comments about how not to do things in mailing list over the years, but I cannot find an explanation of *why* PPA uploader would report "Mismatch in binaryfulness (arch) False != (files) True ... what precisely is it choking on? This after an sbuild of a source package (gvfs) with a small bugfix and dput ... ..._source.changes
<cjwatson> TJ-: That means that the Architecture field in the .changes file lists only "source" (which is correct for a source-only upload) but the part of the .changes file that lists other files being uploaded includes some binary files like .debs
<cjwatson> TJ-: If it isn't clear from that then pastebin the .changes file
<TJ-> cjwatson: thanks... I have scanned them but unsure what I was looking for
<TJ-> cjwatson: hmmm, so "gvfs_1.36.1-0ubuntu1.3.4~tj_amd64.buildinfo" would be the culprit
<cjwatson> Sounds like it
<cjwatson> Information about how the environment for a binary build was set up doesn't belong in a source upload
<cjwatson> If you're building the source package from a clean git tree or similar then you could just use debuild -S -nc (and debdiff old and new source packages to make sure that no extra cruft has crept in)
<TJ-> I'm trying to prevent any build-depends installation on the host with the source, so it is all done from the sbuild schroot ... so I've just 'fixed' it post-build with a "dpkg-genchanges --build=source > .../ X_source.changes"
<cjwatson> TJ-: build-depends> that's why I said -nc
<cjwatson> If you aren't running the clean step then you don't need build-depends
<cjwatson> (but you do need care that the tree is actually clean)
<LocutusOfBorg> somebody once told me this:
<LocutusOfBorg> dpkg-source -b . && dpkg-source --after-build . && dpkg-buildpackage -S -nc
<cjwatson> Somebody was trying too hard IMO, but OK :)
<LocutusOfBorg> this is in my "rebuild" bash script when I don't care about dependencies...
<LocutusOfBorg> if you have a better version I'm happy to listen and apply it :)
<LocutusOfBorg> and mapreri probably too, since he told me that thing :)
<LocutusOfBorg> and we should probably have a "no change rebuild" script in ubuntu-dev-tools
<cjwatson> I don't see why a rebuild script needs any particular effort there.  If you've just fetched and unpacked the source package then it's clean by definition.
<LocutusOfBorg> how do you create the changes after editing debian/changelog?
<cjwatson> Just dpkg-buildpackage -S -nc on its own is nearly always fine; I don't see what the dpkg-source hackery there buys you.
<TJ-> cjwatson: I was referring to needing to do "sbuild --no-clean-source ..." to prevent failures due missing build-depends the Makefile relies on
<cjwatson> There are exceptions where the clean target does something special with substituting the version into other files, but dpkg-source doesn't help with that
<cjwatson> TJ-: I don't think you've understood what I said
<LocutusOfBorg> cjwatson, doesn't in run after-build hooks?
<cjwatson> LocutusOfBorg: But so does dpkg-buildpackage -S -nc.  Running it manually first doesn't seem interesting
<TJ-> cjwatson: Yes, I did ... I was talking about an orothogonal issue as to why I ended up with the binary reference and why I was going around the houses :)
<LocutusOfBorg> oh, got it :)
<cjwatson> It does seem like an sbuild bug if it's including _amd64.buildinfo in an allegedly source build
<TJ-> I was/am doing "sbuild --source-only-changes --no-clean-source" from the source directory
<LocutusOfBorg> tarzeau, sorry I syncd fasrttracker after seeing you changed the blocker bug...
<LocutusOfBorg> can I close it now?
<tarzeau> is 19.10 having 1.00 now? then bug can be closed
<tarzeau> yep looks good, thanks
<LocutusOfBorg> tarzeau, after dinstall yes
<LocutusOfBorg> I don't want it to migrate early
<LocutusOfBorg> but I syncd it before seeing the bug, not the opposite :p
<seb128> I probably ask that in the past, but is there a way to query unattendeed-upgrade to know how many updates it applied and the toal number
<seb128> and also maybe to tell it to exit once it's done with its batch so I can use my machine and I install the dbgsym I need without being blocked for half an hour?
<ricotz> seb128, hey :), I have update the vala sru bug -- https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1803136
<ubottu> Launchpad bug 1803136 in vala (Ubuntu Bionic) "[SRU] Update to vala 0.40.17 in bionic" [Low,Confirmed]
<seb128> ricotz, hey, ack, I will have a look, thx
<ricotz> seb128, thanks
<seb128> bdmurray, hey, do you have any idea why https://errors.ubuntu.com/problem/8432dce420a23f06dbb667734330eb0ef23301a4 and https://errors.ubuntu.com/problem/c01ad6266575bee8065679508008b968593a86fd have no backtrace?
<seb128> well most recent tracker reports in 19.10 it seems
<seb128> we also miss debug symbols/retrace on quite some other projects/reports
<ddstreet> Laney not sure if you're still around, but systemd-upstream CI appears to have stopped updating github with any results...the tests look like they are running on our infrastructure, but their github PR pages show the tests are 'Pending' forever...could you check the autopkgtest-cloud logs?
<Laney> ddstreet: you got me for a few minutes, let me see
<Laney> ddstreet: www-data 27586  0.0  0.0  10552   664 ?        S    Oct09   0:00  |       \_ flock -w 60 /run/lock/update-github-jobs.lock /home/ubuntu/autopkgtest-cloud/webcontrol/update-github-jobs
<Laney> would that timing match up?
<Laney> if it's a stuck process
<ddstreet> yep that seems to be about right, it seems to have been first noticed oct 10 after one had been stuck for 12+ hours
<seb128> bdmurray, https://errors.ubuntu.com/problem/0f924bd29e9d9e01b0b77542ead2c68b36282ad1 also
<Laney> ddstreet: ok, kicked it, should start working again
<bdmurray> seb128: I'll try and have a look at it tonight / tomorrow.
<seb128> bdmurray, no hurry thx, I didn't mean to bother you on a day off just stacked things for once you are back :)
<bdmurray> seb128: I'm actually in London at the release sprint so its not a day off.
<seb128> ah ok
<seb128> oh well, can wait tomorrow in any case
<seb128> thx
<paride5> bdmurray, https://code.launchpad.net/~legovini/auto-upgrade-testing/ramsettings/+merge/374097
<paride5> what's that 5
<ddstreet> thanks Laney! :)
<mwhudson> what does DM_MULTIPATH_DEVICE_PATH="0" mean
<TJ-> mwhudson: from lvm2: lib/device/dev-ext-udev-constants.h:43: * DEV_EXT_UDEV_MPATH_DEVICE_PATH is set by multipath in udev db
<TJ-> lib/device/dev-ext-udev-constants.h:48:#define DEV_EXT_UDEV_MPATH_DEVICE_PATH          "DM_MULTIPATH_DEVICE_PATH"
<mwhudson> TJ-: yeah, i got that far, i'm just want to know what the value means
<TJ-> mwhudson: it's a Boolean ... tells us if the device is multipath connected
<mwhudson> TJ-: there is stuff in udev about checking for values of 0, 1, 2
<TJ-> mwhudson: hmmm, never noticed that... presumably set by dm_multipath according to the path type?
<mwhudson> $ sudo multipath -c /dev/nvme0n1
<mwhudson> DM_MULTIPATH_DEVICE_PATH="0"
<mwhudson> o well use the source luke etc
<mwhudson> DM_MULTIPATH_DEVICE_PATH="2" seems to be "maybe"
<TJ-> I was wondering if it was the queue mode :)
<TJ-> so a tri-state Boolean :)
<mwhudson> ah hah https://www.spinics.net/lists/dm-devel/msg35965.html
<mwhudson> the poster here is complaining about exactly what we are seeing i think
<TJ-> Statement of the week: "That could be better documented by comments, I suppose." :D
<mwhudson> hah yes
#ubuntu-devel 2019-10-15
<jamespage> sil2100: hey can we get https://bugs.launchpad.net/cloud-archive/+bug/1837905 release now? sahid_  has confirmed testing and tagged inline with process now
<ubottu> Launchpad bug 1837905 in horizon (Ubuntu Disco) " [SRU] stein stable releases " [High,Fix committed]
<sil2100> jamespage: hey! Sure, let me do that once we're done with the eoan candidate images - I expect I can tackle that somewhere tomorrow
<jamespage> sil2100: OK - I have some other updates ready for upload once those have cleared proposed
<ahasenack> hi guys, I'm tracking down a dep8 failure in eoan and looks like the i386 test actually was run on a x86_64 host (64bits), is that expected?
<ahasenack> test log is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/p/python-pyeclib/20191014_092849_53aad@/log.gz
<ahasenack> one can see the intention of running on i386, like -image adt/ubuntu-eoan-i386-server
<ahasenack> but at the same time we can also see apt fetching release files from amd64
<ahasenack> and an amd64 kernel seems to be installed: linux-generic:amd64 is already the newest version (5.3.0.18.21).
<sarnold> ahasenack: I believe there's no 32bit x86 kernel on eoan
<sarnold> ahasenack: we're still planning on supporting some of the libraries for 32bit x86 use but the intention is to run them on 64 bit amd64 kernels
<ahasenack> the python code is calling platform.machine() to check the arch
<ahasenack> that seems to be returning x86_64 when the test is supposed to be running on i386
<ahasenack> then the test isn't skipped, and fails
<ahasenack> yeah, last good run was on i386 "native"
<ahasenack> http://autopkgtest.ubuntu.com/packages/p/python-pyeclib/eoan/i386
<ahasenack> just checked the test log from there
<ahasenack> then a sea of red started
<ahasenack> maybe the test should use dpkg-architecture
<cjwatson> dpkg --print-architecture if you want a runtime check of the userspace architecture
<sarnold> dpkg-dev: /usr/bin/dpkg-architecture
<cjwatson> (dpkg-architecture is in dpkg-dev; dpkg --print-architecture doesn't require -dev)
<ahasenack> yeah, that seems to work
<ahasenack> let me just check if that python platform module has nothing else I could use
<ahasenack> platform.architecture() maybe
<cjwatson> Conceivably I guess
<cjwatson> This all triggers my "probably testing for the wrong thing" reflex though
<sarnold> that's an excellent way to describe that feeling I was getting :) thanks
<ahasenack> it's a test that is not meant to be run on i386
<ahasenack> dep8 doesn't have a way to express that, does it?
<cjwatson> Oh, this is in debian/tests/
<cjwatson> You should check the dpkg architecture in that case
<cjwatson> dpkg --print-architecture would be correct
<cjwatson> AFAIK there is indeed no way to specify that in autopkgtest metadata
<cjwatson> Though could you not just put libisal2 in the test's Depends?
<cjwatson> Not certain but that would be the first thing I'd try
<cjwatson> That's what the test is purportedly for, so let's stop using proxy properties like the current architecture?
<ahasenack> not my package, it just got called out in our daily triage. It's blocking python-six
<ahasenack> I never heard of python-pyeclib before today :)
<ahasenack> trying to figure out the best way to unblock it
<ahasenack> looks like that skip was introduced in 1.5.0-1ubuntu2
<ahasenack> cjwatson: so how to run the test in amd64, if then it needs libisal2? Where would the libisal2 dep be declared?
<ahasenack> the other half of the tests run on all arches
<cjwatson> ahasenack: Depends: in debian/tests/control for the particular tests in question
<ahasenack> it is in there, but with the [amd64] flag. You mean it should be there without that flag?
<cjwatson> ahasenack: In fact it already seems to have "libisal2 [amd64]" there.  I wonder whether just making that be "libisal2" and letting it be unresolvable on other architectures would help
<cjwatson> Maybe
<cjwatson> Worth testing (locally)
<cjwatson> But failing that, check dpkg --print-architecture since this test really does care about the dpkg arch not the kernel arch
<cjwatson> Or even test whether the library exists, ctypes.cdll.LoadLibrary or something
<mwhudson> if you put unavailable depends in debian/tests/control the tests just fail, i think
#ubuntu-devel 2019-10-16
<LocutusOfBorg> tjaalton, intel-media-driver-non-free intel-media-driver intel-gmmlib sync post eoan?
<LocutusOfBorg> I'm trying to figure out if the delta can be dropped or not, just as a learning opportunity :)
<tjaalton> LocutusOfBorg: there's no real delta, so yes
<LocutusOfBorg> thanks for confirming, I don't know if they can be syncd before release or not...
<LocutusOfBorg> they look like seeded...
<LocutusOfBorg> so no
<LocutusOfBorg> :D
<Unit193> Maybe for Feisty Fawn.
<cjwatson> Fawning Fist
<cjwatson> Maybe not
<Unit193> Flailing Falcon.
<RikMills> Flacid Frog
<mwhudson> farty fruitbat
<LocutusOfBorg> Millenium Falcon :/
<LocutusOfBorg> oops
<tarzeau> Faboulous Ferryman
<cpaelzer> rbasak: ahasenack: good news for haproxy and openssl
<cpaelzer> there is a patch that works to gain back control of the key size
<rbasak> o/
<rbasak> \o/
<cpaelzer> needs a while to tickle through upstream for sure, but I confirmed it working in an experimental build
<rbasak> ddstreet: how is progress on bug 1847242? Would it be worth releasing this at the same time as your previous autopkgtest SRU, or do you really want to release the current one first?
<ubottu> bug 1847242 in autopkgtest (Ubuntu Xenial) "adt_run test_tree_output_dir always fails on armhf" [Low,In progress] https://launchpad.net/bugs/1847242
<ddstreet> rbasak i can roll that in and reupload if you'd like
<ddstreet> it's hardly the only flaky/failing autopkgtest for systemd on xenial (or other releases) though - i'm working from the top down (upstream, debian, then ubuntu) on correcting all that, so xenial was basically at the bottom of my list
<ddstreet> ah sorry this is for autopkgtest itself
<rbasak> Yeah
<rbasak> Also I just noticed that vorlon marked it block-proposed-disco when he accepted the Disco upload, but sil2100 perhaps didn't notice that when accepting Xenial and Bionic?
<rbasak> AFAICT, there is no reason for the status to be different.
<rbasak> So perhaps we should mark it to hold for all three.
<rbasak> Also I need to document what that tag means.
<ddstreet> yeah, it's actually *more* of a problem in disco, since people get the lxd snap there (which has the new behavior causing failure), while on bionic most people probably have the lxd deb, which is an older version and doesn't cause the failure (yet)
<ddstreet> rbasak so i have the patch ready in my git and i can upload it for x now, but the new upload will have only the test fix (plus the fix that's in -proposed)
<ddstreet> doesn't matter to me either way really, if we wait then i'll include the test fix in my next autopkgtest upload to x whenever that might be
<rbasak> ddstreet: "...but the new upload will have only" -> why do you say "but"? Isn't that a good thing?
<rbasak> Though
<ddstreet> rbasak i just mean the new upload will only fix an autopkgtest; it won't include any new actual bug fix
<rbasak> Perhaps it would be better if I didn't make any decisions here, actually, as I'd be the third SRU team member touching it and maybe that would just confuse things.
<rbasak> ddstreet: understood, thanks.
<rbasak> I think it makes sense for you to upload, for use to add block-proposed-<series> for all outstanding stable series for that bug.
<rbasak> However let's wait for vorlon or sil2100 to confirm.
<rbasak> for *you
<rbasak> or maybe I meant us
<rbasak> Anyway, I hope that makes sense
<sil2100> rbasak: so I only accepted it into -proposed for bionic and xenial, I saw no reason for why not to include there with the block-proposed tag
<sil2100> rbasak: ah, right, but we switched to using per-series ones only afterwards
<sil2100> So the only thing I missed was actually switching the tags, yes
<rbasak> sil2100: thanks. So let's re-add those and get ddstreet to upload his next branch on top now then?
<sil2100> Yes, added those
<Laney> cyphermox: ahoy, I just bounced you an update translation tarball for ubiquity - could you integrate it quickly please?
<Laney> none of us here know how to do that /o\
<Laney> and we're planning an upload
<cyphermox> yup yup
<cyphermox> sil2100 just pinged me about it
<cyphermox> I was just wondering how come I had mail addressed to you
<cyphermox> tbh, it's nothing more than dropping the files on top of the existing ones, and renaming appropriately
<cyphermox> should I look for a newly translated string in particular?
<sil2100> cyphermox: not sure, I think the ZFS ones might have been additionally translated, but we just wanted to refresh the translations anyway since we're uploading a new ubiquity
<cyphermox> at least _Skip is translated in fr.po now
<sil2100> cyphermox: \o/
<cyphermox> updated.
<cyphermox> should I upload too?
<sil2100> cyphermox: yes please
<cyphermox> ack
<rbasak> rafaeldtinoco: reviewing your simplestreams Xenial SRU, I'm not sure I follow why an SRU is necessary for about half of these bugs - relating to v3 support
<rbasak> I'm not aware that we usually backport new features to old LTSes due to new features/deprecations in future OpenStack releases - that's what I thought the cloud archive was for.
<rbasak> Am I wrong, or is this case exceptional somehow?
<rafaeldtinoco> rbasak: it was a seg request
<rafaeldtinoco> because of a charm
<rafaeldtinoco> let me open the lps
<rbasak> So a statement like "The OpenStack Keystone charm supports v3 only since Queens and later" doesn't help me - why doesn't the charm support the older version?
<rafaeldtinoco> ok.. so, with xenial, the keystone charm has to use simplestreams from a ppa in order to make it work whenever updating openstack
<rafaeldtinoco> the upgrade procedure needs v3 support for not to brake
<rafaeldtinoco> because of the ordering (services)
<rafaeldtinoco> but i must confess Im relying mostly on freyes feedback
<rafaeldtinoco> freyes: ^ do you have something else to add for rbasak  ?
<freyes> rbasak, >=Queens OpenStack dropped support for Keystone v2
<rbasak> freyes: and the cloud archive provides Queens against Xenial as a backport, correct?
<freyes> rbasak, correct
<rbasak> OK, so shouldn't this simplestreams v3 support to into the cloud archive, and not the Ubuntu Xenial archive, to solve that problem?
<rbasak> go
<freyes> rbasak, the cloud archive doesn't carry the simplestreams package, and if there is an intention to do it for newer releases it won't help with this bug
<rbasak> I don't think that "doesn't carry the simplestreams package" automatically means that an SRU is justified, though the SRU team might conclude that it's OK if no other solution makes sense.
<rbasak> But I don't understand why the package couldn't just be added to the cloud archive
<rbasak> Just because it's not there right now doesn't mean it can't be added right now.
<rbasak> It'd bump users up, but that's what you'd be doing with the SRU anyway.
<freyes> another reason why we may want to fix the package in distro is because simplestreams being a client, it could be that someone just wants to talk to a cloud that runs keystone v3, so in the case you propose, they would need to add a cloud archive repo (pulling a lot of new packages)
<freyes> I see pros and cons on both ways
<rbasak> That's the same situation for any network protocol client in Xenial though, OpenStack or not.
<rafaeldtinoco> a question that triggers me is..
<rafaeldtinoco> instead of a SRU to cloud archive
<rbasak> We expect such clients to use a newer release, or a snap, or some backport PPA, etc.
<rafaeldtinoco> we would have to have the backport instead
<rafaeldtinoco> so there is a 1:1 relation with newer fixes
<rbasak> (or run in a container of a newer release; the list goes on)
<freyes> rbasak, true, disregard my last thought
<rbasak> rafaeldtinoco: yes - that's a decision for the cloud archive maintainers, but I agree that a backport would make more sense.
<rbasak> However, the downside is that it's quite late to be doing such a backport - it might be more than you want to bump existing stable users (same concern as an SRU backport).
<rafaeldtinoco> jamespage: ^ can we have simplestreams included in cloud-archive ? this way the following SRU is not needed and, instead, the resolution would be to add the cloud-archive in order for xenial glance (>= queens) to support keystone v3 ?
<rafaeldtinoco> i would document that in all those LPs and end user would have a place where to look if ever facing this need.
<freyes> it would be add the simplestreams in bionic to the xenial-queens archive
<jamespage> simplestreams in bionic does not work with keystone in bionic outside of any charm context due to the drop of the v2 API at queens release, which is what's in bionic
<jamespage> tl;dr its broken in distro
<jamespage> rafaeldtinoco, rbasak: ^^
<rbasak> jamespage: that might just mean that we need to fix Bionic in an SRU first though - I don't think it affects my proposal for a resolution in Xenial?
<rafaeldtinoco> fixing simplestreams in Bionic and having it available in cloud-archive for xenial (this is current suggest, right ?)
<rbasak> That's what I'm suggesting, yes
<jamespage> oh right - sorry i missed that context - yeah fix it in bionic, and we will include it in the UCA for xenial/queens
<rafaeldtinoco> good.
 * jamespage needs new glasses (or new eyes)
<rafaeldtinoco> freyes: i can backport same patches to bionic and have u reviewing them if you're ok
<freyes> rafaeldtinoco, I'm cool with that ;-)
<rafaeldtinoco> and then we ask jamespage (tks) to include it in cloud-archive
<rbasak> OK, thanks!
<rafaeldtinoco> tku all!
<freyes> rafaeldtinoco, appreciated for chasing this
<rbasak> xnox: are you aware of bug 1846787, and do you have any opinion on this one please? I'm thinking that your review would be better than mine on this one.
<ubottu> bug 1846787 in systemd (Ubuntu Xenial) "systemd-logind leaves leftover sessions and scope files" [Medium,In progress] https://launchpad.net/bugs/1846787
<Pharaoh_Atem> cyphermox: can you please take a look at this for xenial? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245
<ubottu> Launchpad bug 1824245 in grub2 (Ubuntu Xenial) "Can't create a bootable disk by doing image creation on a loop device" [Medium,Triaged]
<Pharaoh_Atem> I've included an updated patch for the ubuntu grub2 packaging following what cjwatson asked me a month ago...
<cyphermox> Pharaoh_Atem: as soon as I have a bit of time to context switch back to grub2, I will
<Pharaoh_Atem> cyphermox: any idea when that will be?
<cyphermox> sorry, not really. for now I really need to focus on netplan
<cyphermox> there is another SRU to land for xenial, so once I hear from it I'll try to make sure this patch lands alongside it
<tomreyn> did something change about which crashes whoopsie on 18.04 would (not) report, or which of them are shown at https://errors.ubuntu.com/user/$(sudo cat /var/lib/whoopsie/whoopsie-id) ?
<tomreyn> the last report i see listed for this desktop system is from august, but i have certainly subbmitted additional crash reports since.
<tomreyn> s/august/july/
<tomreyn> anyone running 18.04 lts, that is
<tomreyn> scratch (just) the last line, i meant to post this to #ubuntu-discuss
<popey> from an enthusiastic user who just installed 19.10...
<popey> "Tell everyone they are doing amazing work with this release and it's highly appreciated"
<popey> Just thought I'd pass that on.
<Unit193> I shift in the shadows, poking at the things most people don't care about.  It's not meeeeee. :3
<infinity> popey: It's not the guy who emails us every time he downloads a new ISO, is it?
<popey> No :)
#ubuntu-devel 2019-10-17
<Unit193> So it seems 20.04 shouldn't be our focal point, yet?
<xnox> rbasak:  argh =) all of that is fixed with cgroups v2, but yeah, these changes look safe for xenial, to get cgroups agent going.
<sil2100> ahasenack: hey! Just a late heads-up - I unblocked britney in bileto
<sil2100> ahasenack: yesterday
<sil2100> ahasenack: not sure how it broke but I know what broke: the lock file was constantly locked, probably some britney run didn't properly unlock it after some crash or something
<sil2100> Never happened before, but hey
<cpaelzer> thanks sil2100
<dupondje> LocutusOfBorg: Guess its WAY to late to sync iwd a final time from testing? :)
<dupondje> again many improvements in the 0.22 version
<LocutusOfBorg> release is in some minutes
<LocutusOfBorg> the 0.21 was already syncd during freeze IIRC
<LocutusOfBorg> now its *really* too late... specially for the new features
<rbasak> xnox: would you mind doing a code review of the patches please, and +1 them in one of the bugs? Then I'll rely on that for SRU review purposes rather than attempting it myself.
<LocutusOfBorg> dupondje, unless you can explain why you want it... otherwise better SRU or wait for 20.04
<rbasak> xnox: looking for any backporting issues with the patches in particular, such as any interactions introduced in newer upstream that might cause the backport to fail in some edge case.
<dupondje> LocutusOfBorg: well nothing very important. But guess its a very infrequently used package :)
<dupondje> But I'll just push it to my ppa :)
<xnox> rbasak:  ok
<rbasak> Thanks!
<tomreyn> i ran "sudo apt install ubuntu-desktop-minimal^" on a 19.10 minimal install. I expected nothing to change, but a lot of packages were marked as manually installed (meaning they were previously automatically installed). Is this to be expected?
<tomreyn> * previsouly marked as automatically installed
<ahasenack> sil2100: thanks!
<cjwatson> That matches my expectations of what installing a task does with current apt.  We always sort of wanted it to somehow record that you'd manually installed the task rather than every package in it, but it has no way to remember that
<cpaelzer> coreycb: jamespage: do you have balloons defined by default and if so seen any issues migrating those https://bugs.launchpad.net/cloud-archive/+bug/1838569 ?
<ubottu> Launchpad bug 1838569 in qemu (Ubuntu) "virtio-balloon change breaks post 4.0 upgrade" [Undecided,Confirmed]
<coreycb> cpaelzer: I'm not sure I'd guess by that bug it is defined by default
<cpaelzer> coreycb: jamespage: forked from the old bug to its own in https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497
<ubottu> Launchpad bug 1848497 in qemu (Ubuntu) "virtio-balloon change breaks migration from qemu prior to 4.0" [Undecided,New]
<cpaelzer> coreycb: jamespage: could you check if you a) define balloons by default and b) you have tested that for migration from prior to Trains - and then state so on the bug
<jamespage> cpaelzer: looking
<cpaelzer> I'll try to recreate on my own, but not sure I get to it today - so I wondered if maybe this already might be "in" your test matrix
<ubuking> hey
* Laney changed the topic of #ubuntu-devel to: Archive: Open | 19.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Eoan | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
* Laney changed the topic of #ubuntu-devel to: Archive: Closed | 19.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Eoan | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<Laney> :>
<sil2100> <3
<tsimonq2> \o/
<ahasenack> rbasak: question for tomorrow. What do we usually do, or should do, with the standards-version when backporting a package? Specifically, the upcoming certbot sru, which comes from cosmic. It uses a S-V that is not the current one for bionic
<vorlon> S-V is informational only; there's no good reason to do extra work around it
<ahasenack> ok
#ubuntu-devel 2019-10-18
<ddstreet> Laney i notice that recent systemd tests on arm64 always fail during reboots of tests...maybe scalingstack has the same shutdown-on-reboot problem that canonistack had?  possibly you could update autopkgtest-cloud to use my --nova-stop-start to get reboots during autopkgtests actually working on arm64...disco and later systemd have unfortunately appeared to simply skip any rebooting test on arm64 :(
<ddstreet> i could add in the same 'skip rebooting tests on arm64' to bionic/xenial systemd, but it would be nicer if we could actually run them, if possible
#ubuntu-devel 2019-10-19
<teward> powersj: alive?
<tsimonq2> teward: no you?
<infinity> new irc client who dis?
<Unit193> Unit 193!
<valorie> valorie
<sarnold> sarnold
<infinity> You're all so helpful.
<sarnold> <3
<Unit193> ...You all have your gecos set. :3
<sarnold> sure how else would /cgrep work?
<doko> mapreri: the devscripts tests seem to hang
<mapreri> doko: it seems to be stuck _after_ dpkg-buildpackage is completely done?
<mapreri> everything is already built at that pointâ¦
<mapreri> doko: which mean, what could cause sbuild or whatever drives that to be stuck there?
<mapreri> If I have to think about something devscripts is affected by it would be https://bugs.debian.org/933642 - but it has been like that for over a year, I can't see it bothering us now.
<ubottu> Debian bug 933642 in devscripts "devscripts: leaves multiple test/uscan/server.py processes running after build" [Serious,Open]
<doko> mapreri: a hanging process in some test?  did you give back the package again?
<mapreri> doko: yes, I retried amd64 only
<doko> so who is giving back the other builds? ...
<mapreri> no ideaâ¦
<mapreri> in the meantime, I finally managed to figure the reason behind that bug, so guess I may as well just upload and see what happens
<mapreri> (figure out the reason, not yet the fix thoughâ¦)
<mapreri> doko: devscripts uploaded, can you accept?
<doko> mapreri: already built
<mapreri> doko: mh?
<mapreri> ohh good.
<mapreri> guess it was that, even if I have no clue why it would suddenly start bothering launchpad only now.
<mapreri> doko: do you also know why it's taking minutes to upload the artifacts?
<mapreri> well it managed after 4 minutesâ¦
<doko> no, but I already asked about it
<mapreri> I reckon I can know happily go my way o/
<doko> mapreri: better run, if you don't want to get bombed with python 3.8 requests ;p
<dupondje> Hmmmm, just found something minor: https://launchpad.net/ubuntu/+source/openjpeg2
<dupondje> bionic version > disco/eoan version
#ubuntu-devel 2019-10-20
<DarkTrick> hello
<DarkTrick> I'm a little curious about dev and living. Is there any way of making a living from ubuntu "core" development? "core" should include everything that comes shipped by default (e.g. nautilus)
<infinity> DarkTrick: "living"?
<DarkTrick> infinity, Meaning: can ubuntu dev be a job?
<tomreyn> DarkTrick: i think you're looking for https://canonical.com/careers (if you mean development), or a nearby IT services company managing ubuntu servers for their customers.
<jbicha> DarkTrick: yes, you just have to be good at something that someone is willing to pay you for ð
<DarkTrick> tomreyn, thank you for the link! Very interesting!
<DarkTrick> jbicha, you smiley indicates ,that it's difficult (?)
<DarkTrick> I guess though, most of the people working for ubuntu have a job, a family and ubuntu as "hobby". Is that guess correct?
<jbicha> there are lots of people being paid to work on Ubuntu stuff, but I am not one of those people yet
<tomreyn> DarkTrick: you're welcome, but let me also say that it's surprising that you'r einterested in Ubuntu development and you didn't think of checking the website of the comapny driving it (Canonical) beforehand.
<DarkTrick> tomreyn, idd. Perhaps I was more interested in hearing a "user's voice" before judging myself. As I don't know what I don't know, I might not be able to see a "more obvious answer"
<tomreyn> DarkTrick: sorry, i should have held my horses. i wish you good luck finding a suitable engagement!
<DarkTrick> tomreyn, :) I didn't take it as offense(? hope I got the right word here). Every feedback provides important information.
<DarkTrick> Thank you. I'll see how I plan my life :)
<tomreyn> :)
<DarkTrick> jbicha, also a thanks to you, of course
<DarkTrick> and sorry for the OT
<doko> ugh, that doesn't work ...
<doko>         for d in debian/python3-persistent/usr/include/python*; do \
<doko>                 [ "$$d" = *m ] || mv "$$d" "$$d"m; \
<doko>         done
<mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/cracklib2$ dpkg --listfiles libpython3.7-minimal | grep sysconfigdata
<mwhudson> /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py
<mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/cracklib2$ dpkg --listfiles libpython3.8-minimal | grep sysconfigdata
<mwhudson> /usr/lib/python3.8/_sysconfigdata__x86_64-linux-gnu.py
<mwhudson> le sigh
<mwhudson> and also why does the package care
