#ubuntu-devel 2005-09-26
<Keybuk> gah
<Keybuk> can you do me a favour
<Keybuk> move /etc/rcS.d/S20syslog up to something like /etc/rcS.d/S10syslog  (it's fine here, but no earlier)
<Keybuk> and try again
<Keybuk> want to see the point at which udev is starting on your system
<Keybuk> but so far, this is _interesting_
<mdz> Keybuk: I did that the first time you asked
<Keybuk> S10 or S20?
<mdz> ah, 20
<Keybuk> yeah, make it S10 now
<mdz> from 2/10 to S/20
<Keybuk> yeah, now make it S/10
<mdz> I heard you
<mdz> you realize I'm never going to be able to reproduce it again
<mdz> EVAR
<Keybuk> I have faith in you
<mjg59> I have a horrible headache
<mdz> mjg59: try udev debugging
<mdz> Keybuk: why is it that I see SCSI init happening while udevstart is running at S04?
<mjg59> mdz: I'm fixing crack-addled ATI chipset bugs
<mjg59> FOR YOU
<mdz> aw, you shouldn't have
<Keybuk> mdz: initramfs kicked it off
<mjg59> Actually, that's a lie
<mjg59> I've finished that now
<Keybuk> and there's a massive great sleep() in a kernel thread
<mjg59> I'm fixing ndiswrapper on amd64 instead
<mjg59> FEEL MY PAIN
<jbailey> mjg59: The kernel loads 32 bit ndis drivers?
<Keybuk> Sep 20 14:43:05 (none) udevd[5231] : udevd.c: seq 945 queued, devpath '/module/pcspkr'
<Keybuk> Sep 20 14:43:05 (none) udevd[5231] : udevd.c: seq 946 queued, devpath '/class/input/event3'
<Keybuk> ... why is mdz's PC speaker an input device? :p
<mdz> wouldn't you like to know
<mjg59> jbailey: No, 64 bit ones
<jbailey> mjg59: Oh good. =)
<mjg59> (brr)
<mdz> mjg59: why are you going anywhere near ndiswrapper?
<Keybuk> mmm, driver-thunking
<Keybuk> we haven't had that since Win32s
<mjg59> mdz: Because everyone ships amd64 laptops with Broadcom shit
<mdz> Keybuk: have you tried reproducing this by unloading everything and running the m-i-t and hotplug init scripts a lot?
<Keybuk> yup
<Keybuk> I don't quite understand it, but I think it has something to do with whether the event from the kernel comes via /proc/sys/kernel/hotplug or netlink
<Keybuk> I've got more kernel code to read in bed tonight
<mdz> what is it that input does wrong?
<Keybuk> some machines luck out one way more than others
<Keybuk> builds a hotplug event by hand in a big string buffer and pokes things manually
<Keybuk> rather than using things like kobject_add() and kobject_hotplug() and stuff
<Keybuk> (ie doesn't use the new kernel driver core)
<mdz> NICE
<Keybuk> there then appear to be two ways hotplug events happen
<mdz> whycome we never saw this in hoary?
<Nafallo> mjg59: while you get your hands dirty, could you package that modem-daemon-thingie that's only for 32-bit but exist for 64-bit upstream aswell? ;-)
<Keybuk> one is through this evil hack, that udev refuses to take part in
<Keybuk> and thus no input/mice, psaux, js0, js1, etc.
<Keybuk> and the other which works
<Keybuk> and I haven't found the one that works in the kernel yet
<Keybuk> which is worrying me
<mjg59> Nafallo: SA:LKJEAR
<mjg59> Nafallo: (Not today)
<mjg59> Today I finish kernel stuff and am then happy
<Nafallo> mjg59: oki ;-)
<mdz> Keybuk: no joy
<Keybuk> mdz: in hoary, if udev doesn't get everything from the kernel it was expecting, it manually fired up hotplug instead
<ogra> mjg59, what do you fix there ? i ususally just add the arch to the ndiswrapper control file and thats it ... i imagine its not done much different in our packaging...
<mdz> Keybuk: well heck
<Keybuk> which was sufficient, but all that code is stripped out of udev now and slimmed down to "be ultimate"
<mjg59> ogra: In the kernel tree
<Keybuk> mdz: reboot a few more times <g>
<mdz> there are all sorts of niggly race-inducing things in this setup
<mdz> external USB CD writer, finicky NIC/hub combination that sometimes takes twice as long to init
<ogra> mjg59, hrm... 
<sivang> I'm hitting bed, night everyone
<Nafallo> silbs: don't hurt it!
<Nafallo> sivang: ^
<Nafallo> :-)
<Nafallo> gnight :-)
<sivang> Nafallo: lol , sure I wont
<ogra> mjg59, if you need a guinea pig, i have a ndiswrapper based card here on amd64
<mjg59> ogra: So do I :)
<ogra> ah, i forgot, you built your home of laptops
<ogra> :)
<Nafallo> lol
<Keybuk> mdz: we love races
<mdz> Keybuk: reboot-until-mice-goes-missing loop  initiated
<Keybuk> udev is a bit like schumacher, it usually wins except when it doesn't and has to have someone pull over and let it go past
<mdz> I'll unplug and plug the CD writer a few times during the udev storm for good measure
<HrdwrBoB> is there an acpi race on suspend resume when opening the lid, because sometimes it locks... and sometimes it doesn't
* Keybuk added an /etc/rcS.d/S39check script with "[ -e /dev/input/mice ]  && reboot" in it <g>
<jbailey> Can we add 6.04 to the bugzilla milestone list?  It would be nice to send away bugs that won't get fixed for 5.10
<Keybuk> shouldn't that be the Malone milestone list? *ducks*
<zyga> what is the next ubuntu codename?
<tseng> zyga: dapper drake.
<jbailey> zyga: http://www.ubuntuforums.org/showthread.php?p=350378
<jdub> jbailey: one sec
<zyga> hmm
<jbailey> zyga: (For the full announcement)
<Keybuk> tseng: or, as we like to call it, "vera"
<zyga> that's two words, which is used for short form?
<jbailey> Does Anybody Here Remember Vera Lynn?
<mdz> Keybuk: it's been through about 20 cycles with no hint of it ever happening again
<mdz> moving syslog CURSED it
<zyga> ah, dapper it is then
<mjg59> `/win 26
<Keybuk> mjg59: /lose 20
<tseng> Keybuk++
<sladen> jbailey: oh 'Lynn, yeah, remember her
<Keybuk> mdz: I do hope the time between S04 and S20 doesn't have a bearing on it
<mjg59> sladen: Any joy with the Thinkpad recovery partition?
<jdub> jbailey: done
<jbailey> jdub: Merci!
<Keybuk> because I can't see anything interesting in that set that should affect it
<sladen> mjg59: works for me(tm).  I can't get it back into a position where it doesn't boot them
<Keybuk> and S04udev should be "FINISHED" when it exits and not doing shit in the backgroun
<ajmitch> jbailey: trying to get everyone speaking some french before UBZ? :)
<mjg59> sladen: Right. In that case, could you possibly dump a copy of your partition table and grub config and try another install?
<Keybuk> nom de dieu la udev putain
<Keybuk> udev, c'est d'encule de ta mere!
<jbailey> ajmitch: *lol*
<jbailey> ajmitch: The two languages sort of blurr together for me sometimes. =)
<jbailey> Keybuk: REmember you're ordering *poutine* here, not *putain*.
<Keybuk> that's a food isn't it?
<sladen> mjg59: the installer will just read the current copy of the partition table.  A better approach is probably for me to make it look like other people's installed results.  Do you have the bug # agian?
<pitti> good night everybody
<mjg59> sladen: Not off-hand, I'm afraid
<sladen> mjg59: annoying.  I was reading it earlier today..
<Keybuk> mdz: I'm thinking ... you managed it when your filesystem needed checking
<Keybuk> which adds time between S04 and S20 for things to settle
<Keybuk> (as that happens at S10)
<Keybuk> maybe it's _more_ time that causes it, not less
<mdz> Keybuk: my loop includes a reboot -f ;-)
<Keybuk> heh
<mdz> this loop seems pretty hopeless though
<Keybuk> right
<Keybuk> it's no problem, just send me a syslog when it does fail
<mdz> Keybuk: it didn't need checking, just a journal replay
<mdz> so the delay was at the point of mounting the root fs from initramfs
<Keybuk> *nods*
<Keybuk> mdz: could you ... gunzip -c /boot/initrd.img-`uname -r` | cpio -t | grep input
<mdz> Keybuk: just usbhid.ko and etc/udev/scripts/inputdev.sh
<Keybuk> there's something very VERY interesting in your syslog
<Keybuk> more interesting than the error
<mdz> oh?
<Keybuk> all your class/input events have sequence numbers
<Keybuk> EXCEPT the one I'm assuming is for /dev/input/mice
<Keybuk> the kernel doesn't produce sequence numbers for input events
<Keybuk> udevstart does though ...
<Keybuk> maybe on most people's machines, the events that bring up /dev/input/* aren't coming from the kernel
<mrd`> I reported bug #11735 (bswap_32 in /usr/include/bits/byteswap.h isn't optimized on athlon) and it was closed; however, the fix does not appear to have been included in any recent glibc updates.
<Keybuk> #14941 proves the kernel can't generate input hotplug events to save its life
<mdz> is there anything else out there which runs udevstart?
<mdz> *somthing* is poking udev to create those device nodes; what if not the kernel?
<mrd`> I've replied to the bug on bugzilla asking about this and also emailed Jeff Bailey (the one who closed it), but have received no reply.
<mdz> something, even
<Keybuk> yup, it's very spooky
<Keybuk> there's an alien in your box generating udev events <g>
<mdz> Keybuk: so we're back at "this can't possibly work in the first place"?
<Keybuk> ones that are better formed than the kernel
<Keybuk> yes
<Keybuk> we know ANY udev event generated by the kernel doesn't work
<mdz> Keybuk: psmouse still gets loaded after I remove it from /etc/modules; what's doing that?
<Keybuk> you can prove this by leaving your input device unplugged and plugging it after boot
<Keybuk> it does?!  bwaaaaaaah
<Keybuk> maybe /etc/hotplug/input.rc (from S:S40hotplug)
<mdz> not unless it shows up in /proc first, by my reading
<Keybuk> yup, something is starting the input subsystem
<Keybuk> probably kbd <g>
<Keybuk> which we haven't yet managed to get into a module ... but I'm sure it'll happen eventually
* Keybuk wonders what happens if the usb subsystem (with it's usbhid device) has settled by the time udevstart is run
<mdz> Keybuk: psmouse isn't even in modules.inputmap
<mdz> oh, mousedev probably loads it
<Keybuk> *nods*
<mdz> does this mean we can drop this /etc/modules special-casing now?
<mdz> now
<mdz> now ==  post-breezy
<Keybuk> I think so
<Keybuk> mousedev would still need to be there, because X is the suck
<Keybuk> hmm, modprobe mousedev doesn't give me psmouse
<mdz> mousedev gets loaded automatically for me
<mdz> and psmouse
<Keybuk> mousedev should generally get loaded by input.rc
<mdz> this laptop has a trackpoint and a synaptics touchpad
<mdz> yeah, mousedev gets loaded by input.rc here
<mdz> ah
<mdz> isapnp loads psmouse
<mdz> I don't think we need /etc/modules at all anymore
<Keybuk> it amazes me just how many times we try and load all these things during boot, and we still have problems with things not being loaded <g>
<mdz> Keybuk: so is it possible that hotplug's coldplugging is faking an event to udev?
<Keybuk> no, we're way too early in the boot process for this
<Keybuk> and hotplug doesn't fake udev events in breezy, it just does things by hand with grepmap
<wasabi_> Hmmm.
<wasabi_> We don' thave an RDP client that does audio forwarding do we?
<Keybuk> this seqnum thing is bugging me ... why do your events have them, except the one that fails (which is clearly from the kernel)
<Keybuk> where do the other events come from?
<Keybuk> it's not udevstart ... udevstart runs udev directly, not udevd
<Keybuk> something is managing to create udev events, with valid sequence numbers, for the input subsystem
<Keybuk> and it's not the input subsystem
<Keybuk> it's almost as if this thing is generating all these events, and the input subsystem goes "oh, and this" and tosses in the /dev/input/mice event
<Keybuk> where on my log I just see the generated events for everything, _including_ /dev/input/mice
<mdz> Keybuk: what is udev's inputdev.sh supposed to do?
<mdz> oh
<Keybuk> looks for a device of a given name
<Keybuk> you can use it to name things
<mrd`> Should I just report my glibc bug to Debian and hope they fix it?
<mdz> mrd`: if you've read the package changelog and confirmed that there is a mistake, then the correct course of action is to reopen the bug in bugzilla.
<mrd`> mdz: I did.
<mrd`> I have also emailed the bug closer directly to no avail.
<mdz> mrd`: then you did the right thing already, thank you.
<mrd`> mdz: But it's not fixed.
<mdz> mrd`: that's why the bug is open
<mdz> it isn't fixed *yet*
<Keybuk> oh, now that's kinda interesting
<mrd`> The page reads "Resolution: FIXED".  Does that mean something different than I think it does?
<mdz> mrd`: errr
<Keybuk> in a very clean system, I did modprobe mousedev after making sure udevd hadn't started yet
<mdz> mrd`: I just looked at the bug, and it is not reopened
<Keybuk> two different events happened at the same time
<Keybuk> so udevd tried to get started twice
<mdz> mrd`: it has never been reopened
<mdz> mrd`: therefore you did not reopen it
<mrd`> mdz: I never said I reopened it.
<mdz> <mdz> mrd`: if you've read the package changelog and confirmed that there is a mistake, then the correct course of action is to reopen the bug in bugzilla.
<mdz> <mrd`> mdz: I did.
<mrd`> mdz: I said I was trying to figure out what's going on.
<mrd`> Oh.
<mrd`> I'm sorry, I read "reopen" as "reply to".
* mrd` will do that now.
<mrd`> mdz: Reopenned.  Thanks for the help, and sorry for the misunderstanding.
<mdz> elmo: what is with workrave coming up even when you're typing now?  is it only me?
<Keybuk> . o O { do selinux people ever TEST their code ?! }
<elmo> mdz: ah, I'm not sure - I've gotten into the habit of managing to pretend like workrave doesn't exist despite it running and whining at me lots
<mdz> elmo: used to be that the small window would come up, but would eventually go away if you kept typing
<mdz> elmo: now, the actual rest break / micro break window seems to come up and block keystrokes
<stub> Ohh... shiny. The workrave lock-button-doesn't-work bug has been fixed by removing the button? Or is that a side effect from something else?
<mdz> stub: that's gnome-screensaver
<mdz> stub: dist-upgrade
* stub is watching the downloads happen right now
<ajmitch> Keybuk: how bad is it?
<Keybuk> ajmitch: just found a bug where udev won't compile -DDEBUG because of a botched selinux dbg() call :p
<Keybuk> reminded me of when manoj wrote all the code for dpkg selinux, declared it worked perfectly
<elmo> mdz: ah, yeah, I think I've seen that
<Keybuk> and then we noticed he'd written it in a file that's not even linked in
<mdz> elmo: something up with the i386 buildd by any chance?  http://people.ubuntu.com/~lamont/buildLogs/u/ubuntu-meta/0.74/
<mdz> it built everywhere else hours ago
<mdz> stub: it's not going to fix thinsg yet unless you're on amd64, powerpc or ia64 (you need ubuntu-desktop 0.74)
<elmo> mdz: oo2 x 2 and a broken one
<mdz> x2?
<elmo> for like 5 days
<elmo> mdz: oo2 and oo2-l10n at a guess
<elmo> (5 days == broken one)
<mdz> -l10n doesn't actually build the thing, does it?
* mdz peers at doko
<Keybuk> ok, so here's my working hypothesis ... the first module to be loaded is "mousedev", which causes TWO udev events, "/module/mousedev" and "/class/input/mice", both delivered through the /proc/sys/kernel/hotplug interface.
<Keybuk> Both these events cause udevsend to be started, both of which try to start udevd as it's not yet running; both udevd try to bind to the event socket, one succeeds and takes the event, the other fails
<Keybuk> the one that fails will exit with an error code, which will cause the udevsend to fallback and run udev by hand
<elmo> mdz: rothera unblocked; i386 should catch up over the next hour
<mdz> elmo: thanks
<elmo> I mailed lamont/infinity about tracing down the source build that caused the hang; I'm too busy/lazy to do that
<Keybuk> this somehow causes a later event to move from the magic-udev-event-generator-I-haven't-found-yet to the input subsystem
<Keybuk> udev rejects events from the input subsystem as a matter of course
<Keybuk> ergo no /dev/input/mice
<Keybuk> I now need to fill in the hand-waving in the middle, and work out what to fix :p
<sebest> lathiat: around?
<shackan> ouch, firefox randomly dying :\
<sebest> shackan, me too :s
<lathiat> sebest: yeh
<sebest> random segV
<sebest> lathiat, i just wanted to ask you if 855resolution start prio was fixed, and if it now works for suspend/resume, because before it fails because the vga bios wasn't patch on resume so X failed to resume
<lathiat> no idea
<lathiat> did you file a bug?
<sebest> the bug was already filled on malone (except the suspend resume issue)
<sebest> do you know how resume works? does it execute some init.d script, or only use an initrd?
<mjg59> resume from what? RAM or disk?
<sebest> mjg59: from disk
<mjg59> sebest: The initramfs loads modules for the disk controller and then resumes
<mjg59> Execution resumes in the suspend script just after the suspend
<sebest> mjg59: because here the is that 855resolution is not called on resum (seems)
<mjg59> sebest: No, there's no infrastructure for it to be
<sebest> mjg59: would it be possible?
<sebest> or is not necessary?
<mjg59> It's on my todo list
<sebest> great because 855resolution was the only thing missing for full support of the dell X1
<mjg59> But somewhere above there is "Get hold of the code that means we don't need to use 855resolution"
<sebest> this code should be in the i810 driver maybe?
<mjg59> Yes
<mjg59> This code exists
<sebest> it must detect the native screen resolution and patch the vga bios , to make the chipset support this resolution i guess
<mjg59> Yes, that's exactly what it does
<mjg59> If you go to http://www.fairlite.demon.co.uk/intel.html you can get a copy of the driver that includes it
<mjg59> Put that in /usr/X11R6/lib/modules/drivers/
<sebest> talking about chipset and laptop, one great addition for dapper would be have better support for external display, because the i810 driver works really great for this (Lcd, crt, dfp tv), maybe by defining good X layouts
<sebest> but i don't know if it's possible to switch X layouts on the fly?
<mjg59> X is poor in this respect
<mjg59> i810 especially so
<sebest> but everything is functionnal for me: external vga and Tv (s-vhs) with i810
<sebest> just have to restart X to select the good layout :s
<sebest> talking about this: i855-crt and i810 switch doesn't work at all for external display where i810 driver works well for cloning and Xinerama.
<sebest> Maybe a first good speed would be to default the configuration to Clone mode, usefull for doing presentation with video projectors
<Keybuk> mjg59: just this one? :p
<mjg59> Keybuk: Mm?
<Keybuk> X being poor
<mjg59> Ha
<mjg59> It's one of the biggest ones it's poor in
<Keybuk> right, bed; I'm not going to solve this tonight
<sebest> i was also about to start working on this issue, but it's too late :p
<lathiat> you know whatd be ncie
<lathiat> if X fails to start
<lathiat> and the config hasn't been modified
<lathiat> regenerate it and try again
<sebest> what would be really nice, is not having a config file
<sebest> i meann, we only have to store things like default resol/color, keymap and thats all, everything else should be detected like "xorg -configure" is able to do it
<lathiat> sebest: then how would you configure things ;)
<sebest> most of the time when it fail to start, it's because you changed the screen or the video card
<sebest> Btw i thought that X was able to start with no xorg.conf, it was on of the feature of Xfree 4.3/4.4 ?
<sebest> lathiat: this is what i'm talking about:
<sebest> http://www.xfree86.org/4.5.0/RELNOTES2.html#2
<sebest> (i know xorg != xfree86)
<sebest> and this "-appendauto" is that you can let some part autodected on each boot, and freeze some others (like keyboard keymap)
<bob2> fabbione: my hoary router seems to stop routing ipv6 packets after a little while
<lathiat> bob2: mine works fine
<lathiat> altho it is breezy now, worked fine when it was hoary
<bob2> floods of "Sep 21 11:26:55 localhost kernel: icmpv6_send: no reply to icmp error" while ping6'ing www.kame.net
<wasabi> During this freeze is main only frozen or universe too?
<lathiat> ugly
<lathiat> wasabi: well, universe is sloshier than main 
<elmo> doko_: ?
<bddebian> Hey
<wasabi> So what are the criteria? I'd like a new version of nss-updatedb
<bddebian> Oh
<wasabi> It just needs a Debian merge is all.
<crimsun> a merge or a Debian sync?
<wasabi> sync.
<crimsun> just ask for it :)
<wasabi> Is it okay to do?
<crimsun> if you think it's necessary, just ask elmo for it
<wasabi> I could do it myself I suspect, just don't want to get shot. ;)
<wasabi> Or not.
* wasabi tickles elmo
* bddebian has asked for lots of syncs
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : udevd.c: udevd event message received
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_udevd_msg: envbuf_size=124
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'HOME=/' to msg.envp[0] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' to msg.envp[1] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'ACTION=add' to msg.envp[2] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'DEVPATH=/class/input/mice' to msg.envp[3] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'SUBSYSTEM=input' to msg.envp[4] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'SEQNUM=856' to msg.envp[5] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'MAJOR=13' to msg.envp[6] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : get_msg_from_envbuf: add 'MINOR=63' to msg.envp[7] 
<Keybuk> Sep 20 20:13:57 (none) udevd[5027] : main: skip uevent_helper message, netlink is active
<Keybuk> MOTHER FUCKER
<bddebian> Such language :-)
<desrt> everyone, quick!!!
<desrt> check your trash icon
<Keybuk> (translation: "I'm going to ignore this event because I can get better events from elsewhere")
<desrt> i bet it's full even if it's empty
<mjg59> I hear Scott loves life
<desrt> eh.  no more or less than the rest of us?
<mjg59> Well, I no longer need to worry about the kernel
<mjg59> So life is good!
<Keybuk> so, basically, udevd has to receive the input event _before_ any netlink event otherwise it'll ignore it
<Keybuk> and parport_pc generates a netlink event
<Keybuk> so if the time to begin loading mousedev and psmouse is longer than the time it takes to load parport_pc ... you're doomed
<mdz> Keybuk: garrrr
<mjg59> I think udev is the BEST SOFTWARE EVER
<Keybuk> this isn't really udev's fault
<Keybuk> it's the kernel's for not doing input udev/hotplug events properly
<Keybuk> if it did them the same way as everything else, we could get all our events over the netlink socket and not worry about a thing
<mdz> Keybuk: why does it ignore the input event when netlink is active?
<mdz> it looks like it received a complete, valid event and threw it away
<Keybuk> because it ignores all "kernelish" events generated by udevsend once it has a netlink event
<Keybuk> that's exactly what it did
<mdz> but why?
<Keybuk> because it figures the kernel will send the same event over the netlink socket any second
<Keybuk> but this is the input subsystem, so it doesn't
<mdz> oh, the kernel sends both types of events for most devicesL
<mdz> ?
<Keybuk> yup
<mdz> tin cups and string, I tell ye
<Keybuk> right, now I just need to make sure I can replicate this on my machine
<lifeless> eww
<lifeless> tin cups and string are more reliable
* elmo cuts lifeless' string with scissors
* lifeless flops
<bddebian> elmo: Am I on the shitlist?
<Chipzz> I'm not sure if this question is appropriate here, but I was wondering something
<mdz> bddebian: if not, asking pointless questions is a good step toward elmo's shitlist ;-)
<Chipzz> would an environment setup with debootstrap --variant=buildd actually be bootable/usable as a minimal system?
<Keybuk> sweeeeeet
<bddebian> mdz: Well I asked about a sync of sylpheed twice now and I don't want to be more of a PITA than I already am so if I'm on the shitlist for wesnoth, I'll shutup :-)
<Keybuk> init=/bin/sh ... load parport_pc and lp ... wait for settle ... load m
<Keybuk> psmouse
<Keybuk> no /dev/input
<Chipzz> (given optional setup of some extra packages if needed)
<infinity> Chipzz : After you add a kernel, a bootloader, and make sure you have a password, sure.
<Chipzz> I once tried stripping a normal debootstrapped system, but I couldn't get rid of some packages that are not in a --variant=buildd environment
<Chipzz> infinity: thx :)
<Chipzz> maybe I'll try that some time :)
<Chipzz> infinity: I think a --variant=buildd system actually includes a kernel :)
<infinity> Chipzz : I think you're wrong.
<Chipzz> I'll check in a bit (I have dpkg-reconfigure running in it atm)
<infinity> elmo : I'm not sure what build brought down king, BTW, as it wasn't an "instant death" thing.  It started to OOM at one point in the day, and continued to OOM off and on for, like, 12 hours before it finally died.
<elmo> infinity: sweet
<infinity> Chipzz : ("I tihnk you're wreong" was a polite way of saying "I know you're wrong")
<elmo> REJECT
<elmo> Rejected: libpgtcl-dev_1.5-0ubuntu1_powerpc.deb: old version (7.4.7-2ubuntu2) in hoary >= new version (1.5-0ubuntu1) targeted at breezy.
<elmo> bddebian: ^-- is that you?
<infinity> elmo : I've never seen a machine flail around OOMing for that long before.  The log is rather impressive.
<mdz> Keybuk: nice one
<Chipzz> infinity: hehe :)
<Chipzz> infinity: you're right :)
<Chipzz> i was confused with linux-kernel-headers
<bddebian> elmo: Nope, pitti I assume.  I was trying to package it
<elmo> meh
<elmo> bddebian: and no, you're not, I'm just busy is all
<Keybuk> mdz: there's a few races all going on at once here
<elmo> bddebian: but like mdz said, leading questions aren't fun - just ping me
<Keybuk> discarding udevsend events because we expect a netlink event any second is all very well
<Keybuk> but it doesn't take into account that we might have taken so long to get ready, that the netlink event has already been and gone
<bddebian> elmo: Fair enough.  Actually after wesnoth it'd probably be better to hold off until I can test sylpheed a little better :-)
<Keybuk> anyway, that's where the bogosity is here
<elmo> does anyone know any good annotation type software?
<mdz> Keybuk: do they come with matching sequence numbers?
<Keybuk> yes
<Keybuk> and there's even code to un-dupe events with matching sequence numbers
<mdz> ...
<Keybuk> it's a bit "what's this code DOING HERE"
<mdz>  /* don't ask */
<lifeless> elmo: what do youo mean by annotation type ?
<wasabi> elmo, can I get a sync with Debian of nss-updatedb or is it too late?
<Keybuk> I love pressing ^D in init=/bin/sh
<elmo> wasabi: what's your email again?
<wasabi> wasabi@larvalstage.net
<elmo> lifeless: I'm editing a document, and beyond diffs, I want to provide comemntary to the diffs
<lifeless> elmo: ah, so you want markup that is outside the document yeah ?
<elmo> lifeless: yah
<elmo> wasabi: done
<elmo> bddebian: re-mail me whne your happy with slypheed then
<wasabi> super. thanks.
<bddebian> elmo: OK, thx
<lifeless> elmo: I am aware of none opensource
<elmo> lifeless: sux, thx anyway
<infinity> elmo : rothera's problem was a buggy daemon init script.
<elmo> infinity: yeah I figured - in main?
<elmo> either way sucks to lose a buildd for so long and not notice
<infinity> No, caudium.
<elmo> I think I need to nagios a "been building for > 10 hours" check or so
<elmo> well, maybe more for powerpc
<infinity> Nothing should take more than that, except openoffice on a bad day
<elmo> gcc on powerpc does I thought?
<elmo> thanks to the TESTSUITE OF DEATH
* elmo blames lifeless
<bddebian> heh
<infinity> Hrm, maybe it's not a buggy init script.
<elmo> oh, no, not even close
<infinity> How is it that we have priority=required packages that aren't included in our variant=buildd chroots?... Feh.
<elmo> openoffice.org2:        07:00:01 (5 entries, sigma 00:11:21)
<elmo> openoffice.org:         05:47:39 (13 entries, sigma 02:07:32)
<elmo> gcc-4.0:                04:49:30 (12 entries, sigma 01:15:22)
<infinity> Oh, wait, required != essential.
<infinity> Brain fart.
<bddebian> Does openoffice.org2 take longer than glibc?
<infinity> Much.
<elmo> glibc:                  00:49:40 (14 entries, sigma 00:13:27)
<elmo> the first 3 are the top 3
<bddebian> Hmm, maybe I'm just used to glibc taking two days on GNU/Hurd ;-P
* infinity used to think that glibc took a long time to build, too.
<elmo> you have a GNU/Hurd box that can stay up two days?
<infinity> Zing!
<bob2> it's good to see oo2 managed to innovate in the build time department
<bddebian> elmo: http://www.bddebian.com  -- click uptime
<elmo> well, running a buildd I mean
<elmo> last i checked the debian folks couldn't anyway
* infinity wonders how many packages have undeclared dependencies on "procps", assuming it's Essential, when it's not.
<elmo> buildd == kernel killer
<elmo> infinity: not too many
<elmo> well, not that are build-depended on 
<infinity> I htink I may maintain one. :)
<bddebian> elmo: I think the hurdfr guys had one going.  I don't know the latest status
<infinity> procps has 26 reverse deps.  That seems a bnit slim, when I think of all the shell scripts that may invoke it.
<infinity> Oh well.  I'll fix Caudium, since I know it's broken.
<bddebian> elmo: OK, please sync sylpheed 2.1.1-1 from experimental if you get the chance. Thx.
<elmo> done
<bddebian> elmo: Awesome, thx
<infinity> I suppose I should file the other two bugs this exposed upstream.
<infinity> 1. WTF does a package build-dep on caudium rather than caudium-dev?
<infinity> 2. WTF doesn't caudium daemonise properly?
<infinity> (2. is why the buildd was hung)
<bddebian> Why does any package use AC_CHECK_LIB(foo, main,...)??  Isn't that wrong?  I didn't think most libraries provied a main??
<elmo> eh
<elmo> they don't need to
<elmo> infinity: because caudium is some freaky webserver with a userbase of the author and his dad
<bddebian> Well I know of at least two packages that break because of that.  What's a better way to handle it?
<infinity> elmo : <snicker>
<bddebian> Oh, I missed that remark, hehe
<Chipzz> *sigh* :)
<wasabi> how the hell do I turn off this clicking in the terminal/text editor stuff.
<wasabi> How annoying!
<Chipzz> if I'm allowed to make a suggestion... maybe it would be a good idea to have something like #ubuntu-advanced or whatever... questions harder then "how do I become root" usually tend to go unanswered in #ubuntu (take this comment with the necessary grain of salt :)), and the other option is to ask here, which of course the developers here do not like...
<Keybuk> mdz: and that fixes udev
<Keybuk> \o/
<Chipzz> (not that I'm saying to people in #ubuntu are not doing a good job, but there are so much newbies in #ubuntu, that the signal to noise ratio is rather low)
<desrt> Chipzz; the fact is -- if you're sufficiently advanced, you'll eventually reach a point where the correct solution is to figure it out for yourself
<Chipzz> dsert: let me give you an example... I have about 8 years experience with linux, 3 years with debian... I upgraded from hoary beta through breezy. When I read about the boot splash, I tried to install it, following instructions of dpkg-reconfigure ..., which didn't help. I tried using google, to no avail either. Finally I asked here and got helped
<bob2> removing more clueful people from #ubuntu is a bad idea
<bob2> Chipzz: what was the solution?
<Chipzz> bob2: the problem was I was focussing on the wrong thing >> the warning from grub about the image
<bob2> right
<Chipzz> solution was installing usplash
<Keybuk> right, time for me to sleep for 16 hours <g>  that used a lot of brain-time
<bob2> ubuntu-desktop Depends on usplash, tho
<Chipzz> I even straced the dpk-reconfigure, leading me to a file which I searched for in packages.ubuntu.com
<Chipzz> bob2: yes, but I nuked some packages which caused some other metapackages to be removed
<desrt> Chipzz; that's a newbie problem -- definitely not advanced :)
<desrt> rule 1: keep ubuntu-desktop involved or proceed with -extreme- caution :)
<Chipzz> desrt: so how come nobody was able to help me on #ubuntu?
<Chipzz> though bob2 tried to iirc :)
<Chipzz> desrt: yea well but I don't like OOo for one bit, and installed gnumeric/abiword instead
<Chipzz> not sure if that was the removel that caused ubuntu-desktop to be uninstalled though
<Burgundavia> Chipzz, that was likely it
<Chipzz> bob2: btw, I'm not saying we should remove more experienced people from #ubuntu ... just to have an extra option somewhere in between
<Chipzz> anyway, I'll go back to just reading the conversations here and leave you guys to your business :)
<desrt> Chipzz; rule 2: disk is cheap :)
<Chipzz> yea but my personal opinion is that OOo sucks donkey balls ;)
<bddebian> heh
<Chipzz> apart from taking up a lot of space, imho it's also bloated, memory-hungry, poorly integrated and has a bad UI... but then that's my opinion, you don't have to agree
<Burgundavia> Chipzz, unfortunately, Goffice lacks a few pieces, like a presenation creator
<Chipzz> Burgundavia: exactly
<Chipzz> Burgundavia: that's what I got MS ppt-viewer under wine for ;)
<Chipzz> well, for seeing the presentations anyway
<Burgundavia> Chipzz, evince should do ppt?
<wasabi> elmo, can I also get libnss-db synched? It goes hand in hand with nss-updatedb. Didn't realize it was required.
<Chipzz> Burgundavia: it does not on my ubuntu-install
<elmo> wasabi: that's in main
<wasabi> oh is it?
* wasabi checks.
<Chipzz> Burgundavia: does it work for you?
<Burgundavia> Chipzz, never tested it
<elmo> wasabi: and would be a new upstream version
<wasabi> Alas.
<Chipzz> Burgundavia: I read about it on pgo, but it was a bit experimental and incomplete iirc
<wasabi> Don't suppose you can back out nssupdatedb then and we can consider the entire thing a wash? heh
<elmo> wasabi: no
<elmo> please please PLEASE check syncs before you ask for them
<wasabi> "ooops."
<elmo> wasabi: if it needs reverted, you'll have to upload the old package with an artifically higher version
* bddebian can attest to that
<elmo> (but not an epoch ,since that'll be permanent and mess up future merges)
<wasabi> Alas. Well, nss-updatedb is broken either way, so it's not that much of a problem I guess. =(
<Chipzz> Burgundavia: anyway, I can understand why the ubuntu developers would want OOo in ubuntu, and it's obviously the right thing to do, I'm not arguing that
<Burgundavia> ya
<Chipzz> but personally I don't like it, and I'ld love to see goffice mature to a point that it can be included or even used by default
<Burgundavia> Chipzz, once one distro starts shipping it, it will rapidly mature I think
<Chipzz> Burgundavia: there are actually to presentation programs for gnome: criawips and present
<Chipzz> too bad neither is actually usable
<Burgundavia> I think criawips got some love recently
<jdub> Chipzz: if you're keen to help goffice, back them up on their gocollab work - that's going to be a defining force
<Chipzz> (present only views .ppts)
<Chipzz> jdub: gocollab?
<Burgundavia> jdub, ok, pissing myself laughing --> http://lwn.net/images/ns/lca/d-waugh.jpg
<Chipzz> Burgundavia: and criawips doesn't do .ppt's iirc
<jdub> Chipzz: see gnome-journal
<jdub> Burgundavia: dunking?
<Burgundavia> jdub, yes, but the expression on your face is priceless
<wasabi> THe first thing I notice about that pic is the unfortunate lack of pants.
<Chipzz> jdub: oh; I don't read that anymore, since I follow pgo extremely closely
<Chipzz> should read it I guess :)
<bob2> los pantalones
<Chipzz> jdub: pgo is the first page I open when opening firefox ;)
<jdub> heh
<Chipzz> ROFL :)
<jdub> Burgundavia: so funny thing about that day
<Amaranth> i admit, i hit slashdot, gmail, _then_ pgo
<jdub> everyone doing the dunking was very polite
<jdub> sat nicely in their dunking chair
<jdub> waited for the inevitable
<jdub> except for one man
<jdub> keith packard
<Chipzz> pgo, then dgo here
<jdub> who got up in his little hat
<jdub> sat in his dunking chair
<jdub> and proceeded to kick water at the crowd like a little evil pixie
<Amaranth> hehehe
<Amaranth> he got soaked, right?
<jdub> oh, he got dunked, for sure
<wasabi> i so can't wait for this nokia thing
<Amaranth> 770?
<wasabi> Yeah.
<bob2> wow
<bob2> he does look like a pixie
<Chipzz> jdub: I doubt gnome-office will ever be a coherent office suite though... the goals of abiword are quite different from gnumeric for example
<fabbione> bob2: i don't see the problem here at all... it probably depends on your setup
<fabbione> morning
<Chipzz> to mention one thing, I once went through a bunch of gnome apps and compared icons on the menus... filed some bugs, submitted a partial patch for abiword which got accepted, but the other abiword bug ended up WONTFIX in the end
<bddebian> Hello fabbione 
<fabbione> yo
<bob2> fabbione: hm, odd, this is just with tspc
<bob2> which is a shame, since it otherwise magically worked
<fabbione> tspc?
<fabbione> what kind of setup is that?
<bob2> the freenet6 client
<fabbione> i use a pure tunnel
<fabbione> meh ok
<fabbione> it might be a bug in the tspc
<ajmitch> bob2: what issues did you have?
<bob2> a flood of:
<bob2> Sep 21 11:51:44 localhost kernel: icmpv6_send: no reply to icmp error
<bob2> while ping6ing www.kame.net from another host
<ajmitch> ah right
<ajmitch> I think I've seen that a few times
<bob2> meh
<bob2> maybe 2.6.10 is too old to a useful router
<bob2> fabbione: who's your tunnel broker?
<fabbione> bob2: i am my own tunnel broker 
<fabbione> <- AS3263
<bob2> hah
<bob2> hah, bgp seems to think ericcson runs that ;)
<ajmitch> bob2: whois even shows fabbione's name there though :)
<fabbione> bob2: yes.. that's telebit.. where i used to work a few years back, but they never had an "internet department"
<desrt> you have an AS number?
<desrt> crikey
<fabbione> so we always did it together..
<bob2> ajmitch: hm, how do I get the whois client to look up as records?
<desrt> whois AS####
<fabbione> bob2: whois AS3263
<ajmitch> worked for me :)
<fabbione> desrt: well it's not mine, but i am still one of the admins
<bob2> hm, times out for me
<desrt> the linux whois is smart enough to figure out the right server to use
<fabbione> still.. i play bgp from home :)
* desrt has considered playing bgp from home
<desrt> it's not very interesting unless you're multihomed
<fabbione> desrt: i am.. in ipv6
<fabbione> and in ipv4 to some extents.. but i don't play bgp in ipv4
<fabbione> too much ram for no real gain
* desrt has a /48 on 3ffe:: but has never gotten proper addressspace in ipv6
<fabbione> desrt: i have 3ffe:100::/24 and 2001..something
<desrt> showoff :p
<fabbione> yeah :)
<fabbione> but i am cool ;)
* desrt has 3ffe:b00:4012::/48
<fabbione> i should really restart again my ipv6 archive
<fabbione> desrt: debian.fabbione.net.. old time stuff :)
<desrt> peer with me
<desrt> :)
<bob2> haha
<desrt> alternatively, i'm willing to accept a chunk of your 2001 addressspace :)
<fabbione> eheh
* ajmitch remembers that archive now..
<fabbione> i don't delegate 2001..
<desrt> from what i understand 3ffe is supposed to be useless/not used/whatever, right?
<fabbione> i only give out bits of the 3ff3 for playing
<bob2> desrt: 2001 space is free now, too
<fabbione> desrt: it's going to be dismissed
* bob2 is a 2001:blah/48
<fabbione> that's correct
<desrt> bob2; where do i go to get my 2001::/48?
<ajmitch> bob2: as are a lot of us mere users :)
<bob2> desrt: freenet6.net, among other places
<desrt> for a /48?
<ajmitch> yes
<bob2> yes
<desrt> crikey.
<wasabi> I would sure like ipv6. =/
* desrt remembers back in the day when they only gave out single IPs
<wasabi> actually maybe I should set up IPSEC between all my boxes.
<bob2> single ipv6 ips?
<desrt> yes
<desrt> on the 6bone
<fabbione> desrt: do you realize that 3ffe:100::/ was the first 3ffe net ever delegated?
<desrt> no :p
* ajmitch is in channel with a celebrity ;)
<desrt> i realise that 3ffe:b00:4012::/48 was the most awesome 3ffe net ever delegated, though
<desrt> it had *all 3* of my computers on it
<desrt> fabbione; so if i get a netblock can you bgp peer me?
<fabbione> desrt: only if you have an ASNO
<fabbione> i don't accept peers with pvt ASNO
<desrt> hmm
<desrt> AS# costs like $3000, doesn't it?
<fabbione> desrt: i don't know how much it costs, but to have one is not simple
<fabbione> you need to fulfill certain requirements
<desrt> ya.  it's pretty much not worth it
<fabbione> like being multihomed
<bob2> even if it was free it'd be complicated
<fabbione> and so on
<fabbione> it is
<bob2> since you need at least a /24 and two transit providers
<desrt> a /24?
<fabbione> yes
<desrt> nobody carries /24 routes :p
<Lathiat2> a /24? heh i think you'll need more than that
<fabbione> you need at least a /24
<fabbione> (ipv4)
<Lathiat2> is that all?
<fabbione> Lathiat: nope..
<desrt> most people drop anything less than a /22
<fabbione> one class is enough
<fabbione> desrt: no no
<bob2> people carry /24 routes
<Lathiat2> desrt: err no
<fabbione> they are not allowed to
<Lathiat2> there are smaller routes than /24 floating around the place too
<bob2> since small people doing multihoming all have /24's
* desrt has heard a somewhat more pessimistic view of the internet than what he is currently hearing
<Lathiat2> fabbione: so who are you associated with?
<fabbione> Lathiat: a bunch of other ISP
<fabbione> we mostly do peering
<Lathiat2> so your a peering point
<Lathiat2> ?
<desrt> man
<desrt> i totally envy your mad connections
<fabbione> Lathiat: sort of :)
<Lathiat2> heh
<fabbione> see..
<fabbione> this backbone was born as experimental
<fabbione> and for research
<desrt> so a /24 is universally portable?
<fabbione> there is no real traffic going on
<fabbione> desrt: yes
<Lathiat2> desrt: yes and no
<desrt> wow
<desrt> er?
<Lathiat2> yes, in general, no, in most places you can't just randomly advertises /24s
<desrt> yes or no? :)
<Lathiat2> but if your on someone trusted globally you can advertise whatever you like
<desrt> assuming you have BGP access
<Lathiat2> right
<Lathiat2> "trusted"
<Lathiat2> :)
<desrt> i was modifying my original question :p
<Lathiat2> but depending on who you are, your upstream will filter the prefixes you can advertise etc
<desrt> "so a /24 is universally portable, assuming you have bgp access?"
<desrt> gotcha.
<bob2> and assuming it's a PA /24
<Lathiat2> bob2: well you can flat out advertise it, whether you should or not is a different story
<bob2> which you will only get by convincing your RIR that you're multi-homing
<Lathiat2> and people notice when you start doing bad things :)
<desrt> it'll be nice the day that my IPs are allocated by IANA and not some ISP :)
<bob2> ipv6 makes it harder to get PA space
<bob2> ie not at all unless you're an ISP
<lifeless> ipv6 alsmo maskes it easier to get /48s
<lifeless> so I can forgive the not having portable addresses thing
<bob2> hahaha
<Lathiat2> because since we have so much address space
<Lathiat2> we can just go waste it all
* desrt really doesn't get how ipv6 is supposed to work at all
<bob2> the ipv6 multi-homing discussions are scary
<desrt> the global route tables are going to be disgustingly large
<bob2> desrt: which is why you don't have portable space anymore
<desrt> oh.  ow.
<desrt> i suppose that's why multihoming discussions get scary
<fabbione> mdz: ping?
* fabbione goes offline a few minutes to mount a new DVD-burner
<Lathiat2> daniels: whats the deal with ati acceleration, are you turning that on by default in the next release or not (bit confused by your email about it?) [and i mean 2d in 'ati' not 3d in fglrx or whatever] 
<Burgundavia> Lathiat, are you aware of the r300 project?
<Burgundavia> Lathiat2, ^
<Lathiat2> yes
<Lathiat2> im just asking about the 2d acceleartion in ati for breezy.. cus atm performance is horrid and daniels mailed saying some machines crash with it etc but "wait fo rthe next release" and im not sure if he means its being turned on or a problem was fixed or what
* Lathiat2 discovers the xorg changelog
<phlaegel> ok, that last udev update is fairly broken
<phlaegel> it's fun to have no mouse or sound ;-)
<Lathiat2> heh
<infinity> Lathiat2 : With accel turned back on in the latest xorg release, my T43 is fine again (yay, I can move windows!)
<Lathiat2> heh yeh moving windows here sucks without it
<Lathiat2> mjg59: about?
<doko> good morning
* infinity heads out for some lunch before going back to work.
<fabbione> mdz: did you recently try the live session on DVD?
<fabbione> it seems to hang here, but it might as well be a bad burn
<doko> mdz: please promote openoffice.org2-java-common to main
<daniels> Lathiat2: it's on by default, except for a very small class of laptop chipsets (R[CS] 4xx)
<Lathiat2> daniels: ah ok, nifty
<fabbione> daniels: i think i found an interesting bug in xserver
<daniels> do tell
<fabbione> you remember more or less my ws setup?
<fabbione> 3 heads
<fabbione> 2 gfx
<fabbione> when i boot the machine, the gfx that's not primary is initizalized very late
<fabbione> what happens is that the monitor(s) are in power sleep
<fabbione> when x starts up, the monitor turns on
<fabbione> but most of the time the EDID read timesout because the attempt is done before the monitors are fully awake
<fabbione> so X starts up
<fabbione> but all resolutions are borked
<fabbione> a restart of the server fixes it
<fabbione> but the main issue is that EDID read should probably retry 2 times if it fails
<fabbione> that will give time to the monitors to turn on and be able to answer to the request
<fabbione> it is reproducible
<fabbione> and i can do it everytime i boot the machine
<fabbione> it is not driver dependent
<fabbione> it happens with both nv and nvidia
<fabbione> (i don't have other cards atm)
<daniels> edid does retry, and your monitor should return edid in powersave mode; mine do
<fabbione> and it is PCI/AGP independent
<fabbione> it happens in both ways (indipendently if i use PCI or AGP as primary.. the other fails)
<fabbione> daniels: i have 3 different brands of monitors
<fabbione> they all fail the same way
<fabbione> so i doubt it's an issue with them
<daniels> fabbione: dunno man, maybe your card.  mine also happens to cache edid.
<daniels> but trust me that it does retry
<daniels> but to get it to power on, you have to hand it an image -> have to set a mode, which is exactly what you need edid for
<fabbione> daniels: it was working before...
<fabbione> it started to do it recently
<fabbione> wow.. i am impressed..
<fabbione> i got a mobo that can't boot from hd0
<fabbione> it attemps even boot from my wife
<fabbione> but not from hd0
<dholbach> for whom else is X broken?
<dholbach> (after a recent upgrade)
<siretart> morning
<[Chameleon] > dholbach: on PPC or other arch?
<siretart> dholbach: how badly broken is it?
<dholbach> hi siretart 
<dholbach> [Chameleon] , i386
<daniels> define 'broken'
<dholbach> siretart, trying to figure it out
<[Chameleon] > hmm.. I'm not sure that I've rebooted since last update... But I'm on AMD64
<daniels> does it not start?  does it start and hang?  are colours weird?
<dholbach> unable to open /dev/agpgart and can't find a mouse - on an x40
<dholbach> does not start
<daniels> that's udev being crap
<daniels> again
<dholbach> yeah, i just checked the udev changelog
<hunger> dholbach: The mice problem didn't happen for me yesterday for the first time in a while.
<hunger> ARG! Who made the usplash timeout so damn long?!
<hunger> Where can I find the bootup output?
<hunger> How can I turn this stupid usplash off?
<bob2> remove the usplash package
<hunger> I need to provide a password during bootup to unlock my HDDs and usplash keeps me waiting for AGES
<dholbach> i'll try to revert to the last udev version
<hunger> dholbach: Nope... I have the /dev/input/mice issue again:-(
<phlaegel> dholbach: that works
<dholbach> woohoo - party! :)
<phlaegel> dholbach: bug 15932
<hunger> dholbach: I have the /d/i/m issue for weeks now! It is not caused by the latest udev.
<dholbach> hunger, did you file a bug?
<hunger> dholbach: There is one for it.
<dholbach> brb
<dholbach> good morning :)
<magnon> morning
<mdz> fabbione: I have not even downloaded a DVD in some time
<hunger> The three most annoying things with breezy: 1) usplash not accepting input (so cryptdisks needs to wait for a timeout), 2) /d/i/mice not getting created 3) ssh me@localhost not working anymore with passphrases.
<fabbione> mdz: ok.. 
<hunger> Hey! 1 is easy to fix be removing "splash" from menu.lst:-)
<doko> mdz: openoffice.org-debian-files:
<doko> oops, sorry, do we need a separate inclusion report?
<phlaegel> hunger: do you have a bug filed for 1? it's good idea, imo
<hunger> phlaegel: I think there was one when I wanted to do so.
<bob2> hunger: 3) wfm
<hunger> bob3: wfm?
<mdz> doko: only if it's new source, as always
<phlaegel> wfm == works for me
<phlaegel> and it doesn't work for me, it asks for my password
<mdz> hunger: 3) works fine, 2) was just fixed (http://bugzilla.ubuntu.com/show_bug.cgi?id=12915) 
<mdz> hunger: if 1) were the worst thing in breezy, we'd be done
<hunger> phlaegel: Used to here... nowadys sshd complains about /home not having proper permissions.
<hunger> phlaegel: It has permissions that are sensible and I did not change them anyway, so I am somewhat surprised. This happens only when trying to read keys, so loggin with password works.
<mdz> hunger: fix your crypto init script to run usplash_write QUIT and you should be blissful
<doko> mdz: well, we did have it in hoary, moved it to universe, now decided to move it back to main, with a reduced set of files
<hunger> mdz: I said those were the most annoying things;-)
<mdz> hunger: and I say they're just the ones you feel like complaining about at this moment
<mdz> and furthermore,one is already fixed, and two are configuration errors
<hunger> mdz: OK, I'll stop whining.
<jdub> hooray!
<mdz> jdub: good morning
<jdub> yo!
<jdub> good very late evening
<Treenaks> jdub: good early morning :)
<jdub> mdz: so a decision was made and implemented after last night's meeting?
<mdz> jdub: yep
<mdz> jdub: it's in the log
<jdub> i saw your u-m upload
<jdub> "oh!'
<doko> mdz: added an entry on the main inclusion queue page, so the re-inclusion is documented
<jdub> whiprush: ping
<pitti> Hi
<magnon> hey pitti
<magnon> open for testing now ;)
<\sh> morning
<pitti> magnon: I'll take care of pbbuttons today, promised
<magnon> :)
<seb128> hey pitti
<dholbach> morning pitti, hi seb128 :)
<seb128> hey dholbach
<magnon> I hope to get my xkb changes into whateverstream sometime soon
<pitti> darn, I slept too long, but I'm feelin goood :-)
* Lathiat stabs firefox
* magnon stabs Lathiat 
<pitti> magnon: do you have a patch for pbbuttonsd?
<Lathiat> crashed on me :(
<magnon> pitti: nah, I just upgraded :P
<pitti> magnon: if so, today would be a perfect time to send it to me :)
<magnon> but I'm making a keymap that works simultaneously with an Apple external keyboard AND the Aluminum powerbook ;)
<sivang> goooood morning all!
<daniels> magnon: which xkb changes?
<magnon> daniels: no code patches
<daniels> magnon: right ...
<magnon> just... making my powerbook work adequatly.
<daniels> ...
<magnon> feel free to tell me what you're dotting for :)
<Treenaks> daniels: btw, I saw working DRI on my PCIE ati (using fglrx).. coolness!
<daniels> magnon: what exactly are you changing?
<magnon> daniels: key and symbol maps so that my laptop could work as intended out of the box
<daniels> riiight ...
<sivang> bob2: have you sorted out the vmware problem already?
<magnon> daniels: anything wrong with that, or did you expect me to do something else? :P
<daniels> i'm just curious what exactly you're doing and/or changing
<magnon> to be honest, for doing it properly, I'm not sure
<magnon> all I know is that if you install breezy on an aluminum Powerbook, the keyboard works crap
<magnon> and that I found some half-assed work on it, that I'm trying to get to work properly.
<daniels> define 'works crap'
<pitti> seb128: so that "esound does not work" bug was a funny one :-)
<magnon> no localised mapping, the command button isn't mapped to anything, fn-keys have no function (without a kernel patch, but nothing after that either without extra work), numlock doesn't work, @ isn't mapped properly...
<seb128> pitti: yeah :)
<sivang> seb128: I have workaround the cdbs-edit-patch problem in gnome-panel, and created the diffs manually, however when trying to build it I get an error about referencing non existent panel_addto something, any idea?
<seb128> sivang: what cdbs-edit-patch problem?
<Lathiat> sivang: did you update 00list?
<seb128> Lathiat: it uses simple-patchsys with cdbs
<seb128> ie: no 00list
<Lathiat> ah
<seb128> no 01list, no list at all :p
<magnon> if you connect an external keyboard, you have less problems with that by itself since it's close to a pc105, but it still isn't right.
<chmj> ogra: ping 
<sivang> Lathiat: it's simple-patchsys.mk, doesn't use 00list
<sivang> seb128: other then that, I've seen that we have 4 patches there with the same prefixing number, is that ok ?
<bob2> sivang: no
<magnon> daniels: any comments to that?
<seb128> sivang: sure
<sivang> me wonders how I should know which of them comes first if I want to uniquiely number them..
<seb128> sivang: but what are you trying to do/patch ?
<seb128> sivang: alphabetic order ...
<daniels> magnon: not really
<pitti> daniels: ah, I know why the xorg CAN numbers were lost in breezy - breezy's changelog starts with 4.3.0.dfsg.1-6ubuntu1
<pitti> daniels: and these old CANs were fixed earlier
<pitti> daniels: could you copy the old changelog back?
<daniels> pitti: i told you this a while ago :P
<daniels> pitti: um, not really
<pitti> daniels: I wasn't aware of that
<sivang> seb128: get gnome-panels' source, then cdbs-edit-patch 12_autotools
<daniels> -rw-r--r--  1 daniels daniels 127K 2005-09-20 18:35 changelog
<daniels> -rw-r--r--  1 daniels daniels 533K 2005-09-12 12:41 changelog.Debian.old
<sivang> seb128: it won't let me in the editing temp shell
<pitti> daniels: ok, if it's a size issue, I mark them manually
<bob2> yay cdbs
<magnon> daniels: if you mean that it has been done already, by all means, let me know
<seb128> sivang: it's due to the config.guess/sub, not sure if that's a cdbs or a edit-patch issue
<daniels> pitti: i've added them to the bottom of the changelog now
<pitti> daniels: oh, thanks
<daniels> pitti: sorry, I just kept forgetting
<sivang> seb128: how can we fix that? clear config.guess/sub and recreate the source pkg?
<pitti> no worries, godd that it is finally solved
<seb128> sivang: don't list these files with the patch
<seb128> maybe pittit knows about the issue, he wrote cdbs-edit-patch :)
<sivang> pitti: any idea? :)
<pitti> sivang: erm, what? reading scrollback now
<seb128> pitti: cdbs-edit-patch breaks on autocrap patches which ship config.guess/.sub changes
<pitti> sivang: no idea what went wrong without looking at it
<pitti> ouch
<seb128> pitti: debian/rules update them but the patch too
<sivang> yes?
<pitti> seb128: yes, that's natural
<seb128> so it's kind of conflict :)
<pitti> but then the patch is broken in general
<pitti> sivang: ^
<sivang> pitti: k
<pitti> sivang: there should never be a reason to modify config.guess/sub in a patch
<pitti> sivang: just remove that part of the patch from 12_autotools, and it should be fine
<sivang> pitti: k, thanks!
<sivang> I'm on it now
<sivang> seb128: the add_topanel stuff related autcrap gets patched in debian/rules or the autocrap_12 patch?
<seb128> pitti: the reason is that the patch is made by running autogen.sh and it does update them :p
<seb128> sivang: debian/rules update the config.... files
<mvo> ping jdub 
<sivang> seb128: ok, then I'm safe dropping the autocrap stuff for config.sub/guess without breaking panel_addto
<seb128> yep
<seb128> but again, what are you trying to change on the panel?
<sivang> seb128: making it consistent with mpt's recommendation
<seb128> sivang: which is?
<seb128> carlos: hi
<sivang> seb128: dropping lpi from clock and other individual applets, leaving it only for the panel itself
<carlos> morning
<pitti> Hi carlos 
<pitti> carlos: will I get a juicy new tarball today? :-(
<pitti> :-) even
<sivang> seb128: is that ok with you? (we alrady discussed it last week, me and you)
<seb128> sivang: no need to update the autotools patch probably
<seb128> oh, you change the configure.ac for the different applets too ?
<carlos> pitti, sure
<sivang> seb128: I wanted to update it, since I PKG_CHECK_MODULES for an applet so it could use lpi stuff, now I need to drop it if the applets don't use it
<seb128> k
<sivang> seb128: cool, thanks :)
<carlos> pitti, http://mawson.ubuntu.com/~carlos/rosetta-breezy-2005-09-20.tar.gz
<pitti> carlos: yay
<Treenaks> carlos: so that's why rosetta is so slow? :)
<carlos> pitti, I think the wrapping differences you got should also be fixed
<carlos> Treenaks, ?
<Treenaks> carlos: I'm getting timeouts and proxy errors
<pitti> carlos: ok, I do a diff -Nur between the tarballs, and then a normalized one (with merged pots)
<carlos> pitti, yes, please
<carlos> Treenaks, It seems to work here...
<Treenaks> carlos: hmm.. weird
<carlos> could you describe a bit more what are you doing?
<Treenaks> carlos: --> #launchpad :)
<\sh> elmo: please sync efax-gtk 3.0.4 from unstable and overwrite efax-gtk_3.0.2-1ubuntu1 (universe that is) thx
<daniels> this is a public service announcement
<daniels> the default canadian keyboard layout is fucking weird
<daniels> that is all
<infinity> I assume you mean the weird ca_FR keyboard that almost no one in Canada has ever seen, but OS vendors keep assuming we all use?
<infinity> fr_CA, even.
<daniels> i'm talking about what you get from setxkbmap -layout ca at present
<daniels> which appears to have six levels (three levels + two groups)
<infinity> Yeah, which is probably the crazy french canadian thing no one uses.
<daniels> this is what you get on the third level: |@{}}[] ~{ and a couple of deadkeys
<Burgundavia> daniels, the keyboard are stamped it, but most people use the english keyboard layout
<daniels> this is what you get in the second group: 
<Lathiat> egh
<Lathiat> ogra: ?
<Mithrandir> Kamion: can you test whether 15824 affects us?  It seems to be a "perl breaks abi" bug, but it's ppc only (at least, it appears to be)
<Kamion> we haven't synced to that version of perl
<Kamion> I'll test, but it seems unlikely it'll hit us yet
<Mithrandir> it appears to affect us
<\sh> infinity: can u give a short introduction how to read the failed-logfiles files of the testbuilds?
<infinity> \sh : I tend to start at the top.
<\sh> e.g. what means:
<\sh> universe/web/php4-maxdb_7.5.00.30-1 by buildd+ross [optional:uncompiled] 
<\sh>   Reasons for failing:
<\sh>     [Category: none] 
<\sh>     not ours
<\sh> (ppc that is ;))
<infinity> Oh, that.
<infinity> That's autofailed, because it doesn't list powerpc in the architecture field.
<infinity> (which is fine, since maxdb stuff is only on i386 and amd64, I believe)
<Burgundavia> mvo, why did you rip out the darken screen patch?
<\sh> infinity: thx :) 
<\sh> infinity: so "not ours" means...not in the arch field of the package...
<mvo> Burgundavia: it was requested some days ago by jdub. 
<Burgundavia> mvo, ok
<Burgundavia> jdub, ping
<\sh> infinity: http://people.ubuntu.com/~lamont/buildLogs/Test/r/rezound/0.12.0beta-2ubuntu3/rezound_0.12.0beta-2ubuntu3_20050921-0038-powerpc-failed.gz <--- ubuntu5 has to be in the archive
<infinity> \sh : Any autotest logs for older versions can safely be ignored, if you know the newer one builds.  When -autotest gets turned on, the archive is snapshotted, so nothing new makes it in until the next flush/re-run.
<\sh> infinity: ok..understand :) 
<infinity> (It's the only sane way to have a reasonably consistent archive to test against...)
<crispin> hmm, where has my /dev/input/mice gone ? I have the latest udev ....
<Lathiat> oh dear :\
<Lathiat> i upgraded
<Lathiat> and my mouse devices dont come up and my ipw2200 wont load firmware
<infinity> Blame Keybuk.
* Lathiat blames keybuk
<crispin> Lathiat: urgh, yeah my ipw2200 isn't loading the firmware either :-(
<Lathiat> so
<Lathiat> i wont upgrade this laptop
<Lathiat> since i already broke 1
<Lathiat> or maybe i already did :\ perhaps i just wont reboot
<infinity> mvo : Oh, phooey, I liked the gksu screen darken, it really draws your attention to the dialog.  (doubly-so, because of the really irritating delay, so my short-term memory forgets all about having ASKED for a gksu-using app by the time it pops up)
<Lathiat> that did have a bit of a nasty performance hit tho
<Burgundavia> infinity, I think likewise
<infinity> A small performance hit, but I felt it actually added to the usability. Like a big flashing "woot, woot, YOU'RE DOING SOMETHING AS ROOT NOW, woot, woot" siren.
<infinity> (And I didn't forget about/lose the dialog)
<Lathiat> yeh
<Lathiat> i agree
<mvo> infinity: I don't mind either way (with or without darkening). but I lean slightly toward darkening
<infinity> mvo : Hr,, so why the change?... Tech Board decision?
<mvo> infinity: jdub request
<infinity> Bah. :)
<ogra> Lathiat, pong ?
<Lathiat> ogra: xscreensaver borked upgrading, know about that?
<Lathiat> overwriting a file .. i forget what it was now
<ogra> i havent switched back yet, i'll see it soon :)
<Lathiat> ok
<ogra> (abd fix it indeed :) )
<infinity> Upgrade worked for me..
<Lathiat> it might have been a result of not upgrading for 2 days
<Lathiat> like if there were a couple uploads in between
<ogra> especially for the screensaver stuff, yes 
<infinity> {x,gnome-}screensaver have seen a few uploads, and broken in different ways, yes.
* Lathiat nods
<infinity> You may have just been unlucky in when you did your upgrades.
<Lathiat> probably
<infinity> Assuming upgrades work for most breezy users (and ALL hoary users), it's probably fine.
<ogra> at least the switch is prepoared now for dapper :)
<Lathiat> upgrade from hoary and preview would be good
<Lathiat> ogra: heh
* hunger still has the /d/i/mice problem with the new udev.
<hunger> Plus I get lots of failures from alsa now when that starts up.
<fabbione> doko: ping?
<doko> fabbione: pong
<siretart> fabbione: did my email about igor reach you?
<dmk> hi guys, the latest updates that I hae downloaded this morning have made a laptop go from well supported to unable to start X in one fatal swoop
<fabbione> doko: has the oo2 Depends stuff been sorted yet?
<fabbione> siretart: yes! thanks! i still need to try to login
<siretart> fabbione: ok. my evo crashed, so I wasn't sure
<doko> fabbione: what do you mean?
<ogra> dmk, #ubuntu please
<Kamion> dmk: is it complaining about lack of /dev/input/mice, or something else?
<fabbione> doko: today's breezy is not netinstallable due to OO2 Depends: not ok
<dmk> Kamion, yeah and /dev/psaux
<dmk> Kamion, I recall seeing something about this on the mailing list was going to look up the bug number
<dmk> Kamion, i was working perfect all the way through various colony releases and updates until today
<Kamion> dmk: please tell http://bugzilla.ubuntu.com/show_bug.cgi?id=12915 about it; evidently the change made things worse for some people
<dmk> Kamion, ok will do that now - Thanks
<doko> fabbione, Kamion: yes, we need openoffice.org2-java-common and openoffice.org-debian-files in main, openoffice.org2-java-common is approved, openoffice.org-debian-files is trivial, was already in main for hoary
<dmk> has there also been ALSA changes as my sound has went too
<dmk> ?
<Kamion> sound device nodes could potentially have been affected by a udev bug
<fabbione> doko: so it has not been moved yet...
* fabbione sighs
<dmk> Kamion, was thinking that myself.
<dmk> Kamion, thanks.
<infinity> Kamion : Did you get anywhere interesting with MySQL yesterday?
<Kamion> infinity: no, afraid not; it seemed to go away when I added debugging code
<Kamion> (in my_pwrite)
<Kamion> if you're willing to deal with it, I certainly wouldn't object :-/
<infinity> Kamion : I fear it may go away with a rebuild, period.  Or did you manage to get a debug build that still broke?
<Kamion> I rebuilt it without debugging and it still broke
<infinity> Okay, that's something, then.
<Kamion> which was a start, at least
<fabbione> Kamion: did you ever get around to fix choose-mirror -> apt-config in d-i? i still get asked twice what mirror to use on netinstall...
<fabbione> (nothing CRITICAL.. just nice to have)
<pitti> dmk: if it helps you, I currently encounter a similar problem; I have to run udevstart after boot to make things work again
<crispin> heh, the clock on the ubuntu bugzilla it an hour out, it claims that it is 11:08 UTC now, where as it as 10:08
<tseng> crispin: it could bet set to UK local time
<dmk> pitti, cheers for that will give it a shot
<infinity> crispin : It's in London time, not UTC.  Hence why it says "BST"
<crispin> infinity: err, in the "Additional comment..." bit it says UTC
<tseng> ez gtk boog
<crispin> and the "last modified" bit at the top of the bug pages
<sivang> elmo: do you know if it's possible to change one's email alias by changing the launchpad name? (I changed it yesterday, but checking it I see it didn't reflect my changes)
<thesaltydog> what's happening with latest update of dbus?? My Xorg server won't start anymore..
* mvo is away for a bit to get a hdd replaced
<infinity> crispin : Ahh, so it does.  It lies. :)
<daniels> thesaltydog: #ubuntu, please
<Kamion> fabbione: no, haven't yet, sorry
<tseng> http://madpenguin.org/cms/?m=show&id=5145
<tseng> you guys should read what he has to say about our release names
<tseng> his mastery of english is pretty amazing.
<Nafallo> tseng: old news, been on sounder since yesterday :-)
<tseng> ah.
<Treenaks> Could it be that the udev update broke firmware loading/
<Treenaks> I'm getting reports on the Dutch channel
<Nafallo> hmm. I'm not going to reboot for a while then :-P
<Nafallo> seems it broke every possible device ;-)
<crispin> Treenaks: yeah, it broke it for me
<Treenaks> crispin: OK
<seb128> pitti: any opinion on #8037 ?
<pitti> seb128: minute, please
<doko> ogra: schoolbell doesn't belong to edubuntu ?
<seb128> pitti: no hurry, don't worry
<dmk> pitti, just gave that a go. it works fine but just ended up rolling back to previous release of udev for the time being
<pitti> dmk: I will try that as well
<fabbione> mdz: still around by any chance?
<ogra> doko, only libschoolbell
<doko> ogra: ok, and that one isn't needed anymore (was basically zope3)
<sivang> tseng: I don't get it, is this a good or bad review? ;-)
<tseng> sivang: the author is a moron
<tseng> i guess i should be less harsh in public, as him
<ogra> doko, its no dependency of schooltool anymore ? 
<doko> ogra: no
<ogra> great... that saves some diskspace
<doko> Mithrandir, infinity: regarding 15824, did you rebuild libperl _and_ eperl as well?
<Kamion> the review's actually fairly good on the whole
<Kamion> and I don't just say that because he pretty much agrees with me about the installer ;-)
<Mithrandir> doko: read the debian bug report.  It fails if he rebuilds the perl which used to work.
<Mithrandir> doko: which really points to a toolchain bug.
<doko> yes, without saying, which compiler version he did use ...
<daniels> Kamion: i dunno man, our installer needs a lot of work
<daniels> Kamion: we totally need to get rid of this fancy graphical shit to put pretty pictures up
<daniels> Kamion: it's ruining us
<Mithrandir> doko: "But if I recompile perl-base_5.8.7-4_powerpc.deb on a sid box with the"
<Mithrandir> "
<Mithrandir> current toolchain, it segfaults:
<pitti> seb128: looks like a nice upstream bug
<infinity> doko : if both are rebuilt, it works fine (that's how the bug first came to be, a rebuilt libperl broke things, the reporter said a rebuilt eperl fixes it)
<pitti> seb128: is there any reason to keep the fd open in the first place?
<seb128> pitti: no clue, I'll have a look on the code
<seb128> pitti: how is an user supposed to know that the device has been unplugged? polling?
<pitti> seb128: why polling? an user will know that he unplugged a device, because he physically has to do it?
<seb128> pitti: grrra, s/user/software/
<pitti> seb128: if settings-daemon needs to read the mixer levels from time to time, it should close the device in between
<seb128> ie: how is gnome-settings-daemon supposed to know it
<pitti> seb128: open(); read(); close(); sleep() seems safer
<pitti> seb128: I had a similar issue with esd
<pitti> seb128: as long as esd kept the device open, the module could not be removed and you got a hang
<pitti> seb128: so I changed it to close the device ASAP
<doko> infinity: before fiddling with toolchain changes at this point, we can avoid this bug in breezy by recompiling both packages and tightening the dependencies?
<infinity> doko : Probably, yes, but who knows if anything else is broken because of this (and how, or why)
<seb128> pitti: is /dev/mixer used according to lsof for you?
<pitti> seb128: I can look into the bug, yes
<pitti> I never noticed it, though
<seb128> pitti: me neither
<pitti> seb128: I CC'ed me on the bug, I will look into ti
<pitti> it
<seb128> thanks
<HiddenWolf> dholbach, ping
<HiddenWolf> dholbach, Attachment #52453 to Bug #273657 Created <bugzilla.gnome.org
<infinity> Okay, uhm, having gnome-screensaver still running after it got removed was VERY BAD. :)
<infinity> I couldn't unlock my screen without hitting another VT and installing it again.
<Treenaks> infinity: or killing it ?
* ajmitch has X seemingly hanging on lid close (and having the laptop sit for awhile)
<daniels> blame mjg59
<ajmitch> hmm, maybe not hanging
<ajmitch> since ps axu shows no X running anymore
<ogra> infinity, i was thinking about a kill in postinst, but since we normally dont switch back and forth with such stuff i didnt think it was really necessary
<ogra> especially since its hard to start xss in the running user session by apt ;)
<ogra> Keybuk, !
<ajmitch> daniels: great, I've got Xorg.0.log output for you :)
<Keybuk> bugger
<ogra> yup
<daniels> ajmitch: do tell
<Treenaks> Keybuk: "You have (overflow) new messages" ?
<Keybuk> yes, pretty much
<ajmitch> the quick summary is: Fatal server error:
<ajmitch> lockup
<Treenaks> ajmitch: ouch
<ajmitch> preceded by an error, which I'll paste into bugzilla
<daniels> ajmitch: blargh.  which version of -driver-i810 were you running?
<daniels> < elmo> SCOTT.  THE DISTRO TEAM WOULD LIKE A WORD.  OUTSIDE.
<ajmitch> 6.8.2-67 is installed
<Keybuk> that doesn't work now <g>  I'm _in_ the distro team <g>
<daniels> ajmitch: frig
<daniels> Keybuk: yes, and you've already made up for lost time in terms of breaking the world :P
<daniels> Keybuk: now all that's left is for you to rewrite udev
<Keybuk> daniels: wanted to beat your record
* infinity fears rebooting his laptop.
<daniels> Keybuk: *shrug*, X works these days
<ogra> infinity, dont :)
<Keybuk> bet it doesn't work today <g>
<daniels> Keybuk: i saved my breakage for times that weren't between preview and release :P
<daniels> Keybuk: sure it does.  works just fine.
<ajmitch> http://paste.ubuntulinux.nl/2404 for the context
<Keybuk> without /dev/input/mice? :p
<infinity> Well, I could just downgrade udev before my machine crashes and I cry.
* infinity goes to do that.
<Treenaks> Keybuk: AllowMouseOpenFail "true"
<daniels> Keybuk: x is working utterly as documented and expected, given the circumstances
<daniels> ajmitch: yeah, sounds about right
<daniels> ajmitch: oh well
<ajmitch> daniels: do you want it in bugzilla for the record?
<mjg59> Lathiat: Hi
<Lathiat> mjg59: sup
<daniels> ajmitch: not really, unfortunately it's way too vague to reproduce (a lockup just means that the engine hung, hard, and the ErrorF()s above it don't give enough information about the last command to be run)
<daniels> ajmitch: if you can reproduce it though, that'd be interesting
<ajmitch> daniels: so far I've had it 3 times in a row
<mjg59> Lathiat: You were looking for me earlier?
<Lathiat> mjg59: yeh just about my acpi bug
<mjg59> Ah, ok
<Lathiat> mjg59: i think anyway
<daniels> ajmitch: when suspending/resuming?
<ajmitch> daniels: so far just on lid close, which isn't set to suspend
<daniels> ajmitch: hmm, that would be the screensaver, no
<daniels> ?
<ajmitch> well, closing the lid & leaving it for awhile
<ajmitch> quite possibly
<ajmitch> I've seen the screensaver come on ok with the lid open
<ajmitch> and I haven't taken this back to xscreensaver yet
<ajmitch> so still g-s-s
<daniels> i blame g-s-s
<ogra> ajmitch, most likely g-s-s
<ajmitch> it's a popular package to blame
<infinity> I blame it for everything.
<daniels> i blame it for infinity's laptop hanging every day
<sivang> infinity: lol
<infinity> gnome-screesnsaver raped my mom.
<daniels> the only thing I don't blame it for is udev, since blaming scott is far more fun
<ogra> i dont care anymore :-D (at least before dapper)
<mjg59> Lathiat: Ah, ok
<pitti> seb128: ok, STR in gdm logout dialog works fine now :-)
* ajmitch will remove g-s-s & retry
<sivang> not too much voices on the ml thread I started, I guess we are reverting to xss ?
<ajmitch> sivang: that's what the TB decided, pending sabdfl's approval
<sivang> ajmitch: k
<janimo> treenaks, you got the audio bug on your laptop? http://bugzilla.ubuntu.com/show_bug.cgi?id=15351
<Treenaks> janimo: uh, haven't tried
<Treenaks> janimo: I'll try once there's a new ISO (tomorrow?) with fixed udev
<janimo> treenaks, ok
<janimo> thanks
<fabbione> infinity: ping?
<janimo> what should be the default action on lid close?
<fabbione> sudo rm -rf /
<janimo> and where to change it? :)
<fabbione> :
<fabbione> :)
<infinity> Light off (but that's usually done in hardware), and probably screen lock.
<infinity> But that's debatable.
<fabbione> infinity: yo dude
<infinity> fabbione : Yo.
<bob2> janimo: /etc/acpi/events, but it's pretty non-trivial
<infinity> fabbione : I'm running to the grocery store t obuy sugar before they close, care to re-ping me in 30?
<janimo> bob2, ok I just wanted to know that there's no bug to report if it doesn't sleep/hibernate
<fabbione> infinity: ok. i am going off line for a nap
<bob2> janimo: that's normal
<infinity> janimo : We specifically don't set it to sleep, because sleep is broken on enough systems that it's a Very Bad Default.
<janimo> bob2,infinity thanks both I found where to tweak it
<bob2> it'd be annoying enough even it did work; sleep drops all network connections
<janimo> is there anything supposed to be left of mkinitrd now that initramfs is used?
<janimo> I see acpid still installs in etc/mkinitrd
<janimo> just a bit confusing
<pitti> Hi Keybuk 
<Keybuk> and now, for my next trick...
<Robot101> bob2: sleep does not drop network connections if they remain idle on the other end, and you bring your interface back on the same IP
<bob2> Robot101: hmm
<Robot101> bob2: it's only if you sleep for more than the timeout, or recieve data and then fail to reply to it due to being asleep that the connection is dead when you come back
<Lathiat> mjg59: oh
<Lathiat> mj	the other thing i said
<Lathiat> mjg59: rather than brute forcing dbus addresses etc
<Lathiat> mjg59: why dont we run a small daemon as the user that listens on the system bus for events to do things to the screensaver etc (and could have other applications)
<Robot101> bob2: like I've slept, eaten dinner, and come back and re-DHCP'd, via two NATs, and my ssh to mutt has still been open, but the 
<Robot101> bob2: *but the irssi connection dropped
<mjg59> Lathiat: That would be the right thing to do
<Lathiat> irssi dropped because irc servers send pings
<mjg59> I await code :)
<Lathiat> an ssh doing nothing doesn't
<Lathiat> mjg59: well, what else could we do with it
<Lathiat> mjg59: are there any other uses of system wide events
<bob2> Robot101: the NAT hadn't timed you out?
<Lathiat> this really applies to dapper now tho since we're punting gss?
<mjg59> Lathiat: At the moment, I'm not sure there's really anything
<Lathiat> but yeh i'll do something up... for gss if we need it later
<Lathiat> altho
<Lathiat> conveivable gnome-power-manager could do that
<mjg59> Stuff like network-manager and power-manager listen on the system bus already
* Kamion stops oem-config playing silly buggers with /etc/inittab; didn't work so well
<Robot101> bob2: evidently not :)
<bob2> Robot101: I shall test it when sleep works again
<dholbach> HiddenWolf: thank you
<HiddenWolf> dholbach, hope it helps.
<dholbach> HiddenWolf: me too
<HiddenWolf> dholbach, had to pull the mail from thunderbird tho.
<seb128> pitti: STR?
<seb128> pitti: oh, suspend .. cool. What did you change?
<HiddenWolf> doko, can we please please please have a preloading applet for OOO2?
<doko> HiddenWolf: I don't think that's a good idea to assume some specific user behaviour
<mpt> OOo's massive unusable buttons are probably slightly more important than its slowness
<pitti> seb128: #12198, pretty simple reason for the breakage
<doko> mpt: file a bug report, I even don't know, what you mean ...
<HiddenWolf> mpt, is it unusable atm?
<Keybuk> [1] +  Segementation fault      (core dumped) udevd
<\sh> seb128: #15865 closed 
<Keybuk> \o/
<mpt> HiddenWolf: Not quite, but several of its dialogs are larger than 1024*768 in at least one direction
<HiddenWolf> mpt, sloppy
<mpt> HiddenWolf: Not so much sloppy, as getting the gtk font settings wrong, I think
<mpt> everything's bigger than native (and bigger than OOo1)
* mpt looks to see if it's filed
<seb128> pitti: oh, nice catch
<pitti> seb128: after restarting gdm it worked
<pitti> seb128: I hope I fixed the transition correctly, but it worked well for mw
<seb128> \sh: thanks
<Mithrandir> doko: I can't fix ooo2-amd64 until the ooo2-nonamd64 is fixed.
<HiddenWolf> mpt, I read a blog somewhere that suse does pretty neat gnome/ooo integration. Perhaps you could check how they fixed things?
<doko> Mithrandir: all packages are in the archive, aren't they? I can give you a java-common for testing, if you want, that's binary-all
<dholbach> brb
<Mithrandir> doko:   openoffice.org2-base: Depends: openoffice.org2-core (> 1.9.129) but it is not going to be installed
<Mithrandir>                         Depends: openoffice.org2-java-common but it is not installable
<mpt> HiddenWolf: I'll report the bug tonight when I actually have OOo2 in front of me
<azeem> HiddenWolf: suse (or rather ximian) are working on gnome/ooo integration for years now
<Yagisan> G'day - can someone point me to a howto for setting up breezys ltsp ?
<seb128> HiddenWolf: what things? they use ooo-build too no?
<HiddenWolf> seb128, I'm not familiar with the details, but I found this: http://planet.hula-project.org/ - first post
<Treenaks> HiddenWolf: what's this with spayne being on like 10 planets?
<HiddenWolf> Treenaks, no clue, guess he has an ego problem. I don't know him tho.
<HiddenWolf> ew, weird bug in ooo
<doko> Mithrandir: yes, I told you. I've put the java package on chinstrap now.
<seb128> HiddenWolf: maybe the guy didn't install the gnome package for ooo2 on Ubuntu
<Mithrandir> doko: doesn't help, I pull stuff from the archive, not from other places.
<doko> Mithrandir: don't pester me, I don't process NEW
<Kamion> NEW's nearly empty
<Mithrandir> Kamion: is openoffice.org2-java-common there?
<Kamion> openoffice.org2-java-common | 1.9.129-0.1ubuntu1 | breezy/universe | all
<Kamion> it's in the archive
<HiddenWolf> seb128, I have it installed, and I still can't say that OOO feels truely gnomy.
<Lathiat> thats because it isn't
<HiddenWolf> Lathiat, unfortunatly so
<doko> Kamion: please promote it to main, as well as openoffice.org-debian-files
<Kamion> I've done ooo-debian-files; anastacia isn't telling me that I can do the other yet
<seb128> HiddenWolf: I'm not sure it is that way on Suse neither ...
<HiddenWolf> Lathiat, will gnome-office eventually have an -impress, do you know?
<Mithrandir> Kamion: ah, apt-cacher playing evil tricks with me here
<HiddenWolf> seb128, I'd check, but I'd rather not have suse on the system. :)
<seb128> Lathiat: this list is not a place to troll :)
<seb128> :p
<Lathiat> HiddenWolf: yeh criawips i think, i eagerly await it
<Keybuk> I am somewhat disappointed that no changelog on Monday was written like a pirate
<Zomb> Mithrandir: report bugs if there are any
* Lathiat grins at Keybuk 
<Mithrandir> Zomb: it might just be that it didn't pick up the newer Packages.gz
<Zomb> it gets HTTP headers similarly to what apt-get does, by default. Depends on the configuration.
<Keybuk> http://lkml.org/lkml/2005/9/15/59
<Keybuk> OH HAAAAAPPY DAAYY
<Mithrandir> Kamion: ah, it's in the archive, but it's in universe.  I need it to be in main since it's a dependency of ooo2-base.
<Kamion> Mithrandir: I've just promoted it, having re-run anastacia
<Kamion> (you lot are impatient :-))
<balor> The latest breezy updates seem to nuke the /dev/input devices.  Is this a well known problem?
<Kamion> balor: yes, upgrade udev
<Mithrandir> Kamion: yay, thanks.  (It's blocking me, hence impatience. :-)
<Kamion> to 0.060-1ubuntu14
<balor> Kamion, thanks.
<lifeless> win 17
<Keybuk> lifeless: lose 20
<daniels> Kamion: AWTY
<zyga> hello
<Keybuk> ooh, 5 pages on the forums dedicated to me <g>
<daniels> stop WABing
<Lathiat> haha
<Keybuk> "WAB" ?
<daniels> work-avoiding behaviour
<Keybuk> I'm reading my e-mail
<daniels> it's a janew-ism
<Keybuk> that's part of my job :p
<JaneW> daniels: it was a well known IRCism... in the olde days (before your time)
<seb128> Mithrandir: what happened to the gnomemeeting update to 1.2.2?
<daniels> no glx is not slower in my opinion it feels slower !!
<daniels> just liek looking at a car wheel when it spins too fast the human eye can hold on and i t looks much slower!!
<daniels> WHAT DOES THAT EVEN MEAN
<daniels> JaneW: this is my 10th year of IRC
<Keybuk> when they go really fast, they look like they're going backwards
<daniels> Keybuk: not necessarily
<infinity> So, glx is so much faster, it looks like it's going backward?
<daniels> but they *can*
<Mithrandir> seb128: it got lost in a maze in my head, I think
<infinity> daniels : Stop making my X go backward!
<JaneW> daniels: right, well snap then ... I started in 1995
<\sh> Before IRC there was BitNet
<\sh> Relay
<JaneW> daniels: I guess I have started by 11th year now
<seb128> Mithrandir: do you want to do it or should be delay to after 5.10?
<Mithrandir> seb128: I can do it now
<seb128> would be nice
<JaneW> I started on MUD
<seb128> thanks
<seb128> you need a new pwlib too
<JaneW> MUDD
<daniels> JaneW: right, so none of this 'before your time' crap :P
<JaneW> daniels: ok sorry :P
<\sh> I started with IRC in 1993 on my university sun os server :( 
<Keybuk> daniels: ah, and of course, you'd never WAB
<daniels> Keybuk: no
<Keybuk>  Currently Active Users Viewing This Thread: 19 (8 members and 11 guests)
<Keybuk> wixtech, fjleal, Yvonne, daniels, noelferg, MartinG, T-One, jamesford 
<bob2> hahaha
<Keybuk> hmm, bad paste
<bob2> Keybuk: if you're going to WAB, do it somewhere that won't make you dumber
<Keybuk> x-chat has been doing that recently, mucking up bold/italics on paste from firefox
<daniels> that tab is closed now
<Keybuk> suuuuure it is <g>
<daniels> the only two tabs are about people having X problems
<daniels> shockingly, they both seem to be about you breaking udev :P
* Keybuk bows
<Lathiat> hrm
<mxpxpod> pitti: nice work :)
<Lathiat> anyone else noticing show desktop/window list/desktop list crashing on login
<Lathiat> i seem to get it most times on 1 of my machines
<Diziet> Oh, bugger, I grumbled to upstream about the code quality in net-tools and now they want me to join them.
<Lathiat> haha Diziet 
<infinity> Lathiat : I had it when logging out/in after switching screensaver (x for gnome and back again), but after restarting and saving my session, they've been fine.
<Lathiat> infinity: hrm
<Kamion> Diziet: "you touched it last"
<pitti> mxpxpod: on pbbuttonsd?
<pitti> mxpxpod: I'm currently triaging the other bugs
<mxpxpod> pitti: yeah, on pbbuttonsd
<daniels> http://www.ubuntuforums.org/showthread.php?t=67619
<mxpxpod> pitti: hopefully, 0.7.1 doesn't bring in new bugs
* daniels recoils, boggles, goes to obtain food.
<pitti> mxpxpod: I hope that, too :-)
* Keybuk boggles
<Keybuk> a bug from silbs 
<Keybuk> ooh
<silbs> Keybuk: i file lots of bugs
<silbs> well, not lots
<Keybuk> which is the right package to reassign kernel bugs to, I forget?
<sivang> hey silbs :)
<bob2> Keybuk: the "fabio" product
<Kamion> Keybuk: 'linux'
<Keybuk> it's the BenC product now
<Keybuk> ah yes, I was looking for linux-<something> thanks Colin
<daniels> would that be a product, or a project?
<Keybuk> productseries
<daniels> or maybe an infestation
<Keybuk> it's a securesourcepackagepublishinghistory
<daniels> it's a A system error has occurred, please try again later
<Kamion> in bugzilla it's just 'linux'
<Kamion> no idea what it would be in malone
<Keybuk> I must admit, I was playing with the new /people/ bit last night during the TB
<Keybuk> it is actually quite sweet
<Keybuk> Kamion: a pain in the arse
* sivang would like to see we start opening new bugs only on Malone, and leave bugzilla for backward compatibility
<seb128> malone is not ready yet for that
<Kamion> sivang: not pre-breezy.
<Kamion> and not before the Malone folks give the say-so
<Diziet> OMG someone is complaining that keyboard accelerators don't work in firefox in non-Latin locales.  Joy.
<daniels> firefox input handling bites, news at 11
<daniels> i think it still uses core keyboard stuff and attempts to pretend that xkb doesn't exist
<daniels> given that lalt and ralt do entirely different things
<Diziet> I wonder what the odds are of me being able to fix it in less than all week.
<daniels> (lalt+larrow -> back, ralt+larrow -> nothing)
<infinity> daniels : ralt+left works here.
<infinity> daniels : Don't you have ralt remapped as compose?
<Kamion> someday I must attempt to actually understand non-vaguely-Latin keyboard handling
<Kamion> but I need to steal daniels' brain first
<daniels> infinity: shut up.  shut up, and shut up.
<infinity> You're welcome.
<daniels> infinity: (in happier news, you're obviously more qualified than me to assist Kamion with his project.)
<jdub> GOOD MORNING FREEDOM LOVERS!
<Kamion> Sheesh. Evidently nobody ever looks at the list of available tasks after a fresh breezy install, or they'd all be complaining about how mad the list is.
<daniels> Kamion: it's fairly easy.  for latin and non-latin alike, you get keycodes down the wire.  you get a n x n matrix of what that keycode translates to with various groups and shift levels.  you establish what group and shift level you're in, and use that to get a keysym out of there.  you can then see what your modifier state is (e.g. is alt down) with another cal.
<daniels> s/cal/&l/
<bddebian> Morning
<Kamion> see, it's the way you started that with "fairly easy" that disturbs me
<seb128> hey hey hey jdub :)
<infinity> Kamion : Now it's your turn.  Tell us about debbugs.
<seb128> hi bddebian
<bddebian> Hello seb128
<Kamion> infinity: heh
<pitti> seb128: question: to decide whether sleep is supported, does gdm use "pmi query suspend" or "pmi capabilities"?
<seb128> pitti: query sleep and query hibernate
<seb128> pitti: does it make any difference?
<pitti> seb128: yes
<bddebian> pitti: Feeling rejected? ;-)
<pitti> seb128: at least on ppc, "pmi query sleep" will return whether the laptop would go to sleep when closing the lid
<daniels> Kamion: well, once you get the idea that you just get handed down 'alright, you're currently looking at Alt+q' off the wire, it largely makes sense
<pitti> seb128: whereas capabilities (should) return whether the laptop *can* sleep
<daniels> Kamion: it's just the implementation details of XKB (i.e. hidden from external users) that really do one's head in
<pitti> seb128: so even if I configure my laptop to not sleep when I close the lid, it should sleep when I explicitly ask for it in gdm
<seb128> pitti: /usr/sbin/pmi is a bash piece of code
<pitti> seb128: ATM, pmi is utterly broken on ppc anyway (I just saw the code the first time), but I will fix that
<seb128> and capability does
<seb128> capabilities () {
<seb128>         for i in "hibernate" "suspend"; do
<seb128>                 query $i
<seb128>                 [ $result -eq 0 ]  && caps="$caps $i"
<pitti> seb128: right
<seb128> pitti: ie: it calls query ....
<seb128> what you say is weird
<seb128> why should it be different to a call to query ?
<pitti> seb128: but either the semantics of query is wrong, or capabilities should not use query
<pitti> seb128: at least on ppc, query asks the action when closing the lid, it does not query wheter the action is possible
<seb128> pitti: "query asks the action"?
<pitti> seb128: and pmi has no manpage, so I am not sure what the actual semantics of query should be
<pitti> seb128: ok, one example:
<Kamion> seb128: note that the /usr/sbin/pmi in powermanagement-interface_powerpc.deb is not the same as the /usr/sbin/pmi in powermanagement-interface_i386.deb
<Kamion> shell script or not
<pitti> Kamion: right, but that part of the logic is the same
<seb128> oh
<seb128> didn't know about that
<seb128> that's a piece of shell, I supposed it was the same
<seb128> thanks Kamion
<pitti> seb128: so if I configure my laptop to sleep on lid closing, pmi query suspend will return 1
<Kamion> -                [ $result -eq 0 ]  && caps="$caps $i"
<pitti> seb128: but if I say "don't sleep on lid close", pmi query suspend will return 0
<Kamion> +                [ "$result" -eq 0 ]  && caps="$caps $i"
<Kamion> (from the diff)
<seb128> query sleep return 1 if ACPI_SLEEP is defined
<Kamion> at least having synchronised quoting between the two would be nice
<pitti> ok, so it seems that query on powerpc has just the wrong semantics
<pitti> I don't see a reason why it shuold return the configured action instead of the capability 
<pitti> Kamion, seb128: ^ agree?
<Kamion> haven't really been following that closely, sorry
* seb128 reads that again
<seb128> what you describe seems complicated to me
<seb128> it does that
<seb128>                         if [ "$ACPI_SLEEP" = true ] ; then
<seb128>                                 result=0
<seb128>                         else
<seb128>                                 result=1
<mx|gone> pitti: want me to explain it?
<pitti> seb128: ah, ok
<seb128> after sourcing /etc/default/acpi-support
<seb128> 
<pitti> mx|gone: I underrstand the problem
<mx|gone> ok
<pitti> seb128: alright, then the powerpc variant is just plain broken
<seb128> mx|gone: I don't get what you configure and how
<pitti> seb128: I fix it, thanks
<seb128> np
<mx|gone> seb128: pitti is taking care of it
<pitti> mx|gone: ok, I throw out all the ONCOVERACTION mess
* mx|gone dances
<pitti> mx|gone: while I am at it, I can also add suspend to disk support
<pitti> elmo: can you please sync powerprefs?
<ogra> do we have a bug about firefox always wanting to open isos in fileroller ?
<Mithrandir> seb128: I need to clean up, the openh323 builds keeps running me out of disk space.
<mvo> Keybuk: do you think #15899 should be fixed now even though it changes a string (string-freeze etc)?
<seb128> Mithrandir: k, no hurry
<Kamion> ogra: ok, you'll now get Edubuntu DVDs on Wednesday and Saturday afternoons
<ogra> yay
<ogra> where do i find them ? 
<Kamion> they'll land in http://cdimage.ubuntu.com/edubuntu/dvd/current/
<ogra> ah, great :)
<Keybuk> mvo: no, I think it can wait
<ogra> Kamion, that was a real nice surprise, thanks a lot :)
<mvo> Keybuk: thanks
<Kamion> not a problem
<ogra> nope, but a present i didnt expect :)
<Kamion> in general you just need to ask if there's something on cdimage that Ubuntu/Kubuntu have but Edubuntu doesn't
<Kamion> live builds would take a bit more work, since they're not entirely my responsibility; but anything else can generally be done
<ogra> Kamion, i'm very carefull how much of your time i grab, in case i need you later again ;)
<infinity> Live builds are cacke, assuming they'll work.
<ogra> and the DVD was no high prio...
<Kamion> "cacke"?
<infinity> cake, too.
<Kamion> ah :)
<infinity> If someone wants/needs edubuntu livefs builds, they just need to mail me the particulars.
<Kamion> (however, more builds does mean more testing load for you guys)
<HiddenWolf> Lathiat, sorry for dissapearing on you right after asking a question.
<ogra> infinity, i'm planning a liveCD for promotion, but that will be a customized one since i need to make setup changes that cant be done in the default setup (there are lots of servers in edubuntu that would need custom confgs to run froma live CD) ...
<ogra> seb128, what happened to this nautilus extension that enabled users to share dirs via samba ? is that dead ? i havent seen anything anymore...
<ogra> (i thought it could be ready for breezy, it looked so good)
* mvo goes and gets some stuff from the bicycle shop
<Keybuk> I remember one that shared folders via howl
<Keybuk> not via samba
<mvo> ogra: isn't that in breezy already? it's part of gnome-system-tools (share folders via smb/nfs)
<ogra> mvo, nope, thats something else
<mvo> ogra: what's the difference?
<ogra> mvo, you could just right click folders and share them
<infinity> Kamion : What is this "testing" you speak of?
<ogra> i even forgot the name of the tool 
<mvo> ogra: righ-clicking on a folder gives me "share folder" here
<ogra> infinity, DVD testing for the edubuntu DVD
<infinity> ogra : They don't have sarcasm in your country, do they?
<mvo> infinity: we are germans
<infinity> Right, forbidden from smiling and such.  I keep forgetting.
<ogra> mvo, oh, right it gives me "ordner teilen" here what a terrible odd translation 
<mvo> ogra: no, that will split it into half
<mvo> infinity: exactly
<ogra> infinity, we lost the remainings of this ability after the election here
<ogra> mvo, hmm, and it uses gksuod...
<ogra> *gksudo
<mvo> ogra: yes, no way around that, it adds stuff to /etc/samba/smb.conf
<ogra> bah
<ogra> samba needs a redesign to accept configs in the users dir if enabled...
* mvo really is aways now for a bit
<ronalde> OT gnu make question: I try to escape filenames containing parenthesis, ie: file(1) in targets and sources in my Makefile. tried $(subst ...) and substitution references ... any clues
<Kamion> use proper quoting around variable names, i.e. "$(variable)" not $(variable)
<Kamion> when they're being passed to the shell, that is
<ronalde> Kamion: that's it ... great!
<\sh> Diziet: ping...regarding #15916, why can't we integrate it?
<\sh> Diziet: thinking about a nice integrated desktop we should avoid those differences...actually sending those patches upstream is as well good and ok
<Diziet> \sh: `why can't we integrate it' ?  Integrate what ?
<\sh> Diziet: printing to pdf...
<Diziet> *blink*
<\sh> yeah, thats me ;-)
<Diziet> Maybe it's this kind of thing that is in the 50kloc of patch between upstream's and our firefox.
<Diziet> I don't think that this is the kind of work we ought to be trying to carry off in private patches.  Surely !
<Diziet> Or are we trying to maintain a fork of firefox ?
<Diziet> Also, is that bug report a request for someone to write the code to provide PDF as an output option ?
<\sh> Diziet: well...we're working on an integrated, smooth desktop environment..so having print dialogs with the two options (.ps and .pdf) as default, and not in the browser...I think we should think about this
<Diziet> I agree that having a PDF print option would be nice.  But the effort to maintain that ourselves is going to be disproportionate.
<Diziet> Or is there some code already to do this, that you simply failed to give a reference to ?
<\sh> Diziet: the question was, if it's possible, if so, what do we have to change? if it's only a configure option in about:config or somewhere in chrome: then we could do it easily..but if it's somethin to patch the code, then..we have to think to raise it as enhancement to upstream
<azeem> \sh: Why not use GNOME's printing infrastructure?
<Diziet> TBH I haven't looked because I can't think of any bad reason why anyone would disable it if the feature were present.
<\sh> Diziet: well...it could be an option in chrome-configs to add...or to pull in the GNOME defaults
<Diziet> az: If upstream firefox came with the option to do printing via Gnome then of course we'd turn that on (assuming it wasn't horridly broken).
<\sh> azeem: well...the print dialog is quite different from the gnome ones...
<azeem> \sh: oh
* azeem doesn't know as he uses epiphany
<\sh> azeem: and I don't know if there is a compile option to pull the gnomeprint thingies in
<Diziet> Again, I haven't looked at that because I assume that whoever had this package before me would have turned it on if such an option existed.
<Diziet> It's not a simple matter of `pulling in some thingies'.
<Diziet> If it is then I'd be happy to do it, but perhaps not at this stage of Breezy's release.
<daniels> s/perhaps //
<Diziet> If you think this feature is important then I would definitely encourage you to look into making sure it's available in the next upstream.
<Diziet> daniels: Indeed.  I'm trying not to sound too negative here :-).
<\sh> Diziet: I will look into it...if it's only a small change in the default configs, we could bring it in even for breezy (when it gives us a more smooth and integrated desktop)
<daniels> Diziet: arguably encouraging someone to do work for breezy by omission and then having to break it to them *later* that it can't go in is worse.
<Kamion> that would be a small change to use a presumably fairly large untested code path
<Diziet> It'd be a new code path we haven't tested.  I know that firefox's ps generation is pretty flakey anyway; do we have any reason to believe the pdf will not be even worse ?
<Diziet> daniels: Point.
<Kamion> Mithrandir: CDs rebuilding and should have openoffice.org2-java-common on them this time, in case that's how you noticed this morning
<azeem> \sh: IMHO Ubuntu decided against a integrated desktop when choosing Firefox over Epiphany
<\sh> Diziet: as I said, when it's only a runtime configuration option we should have a look and test 
<\sh> actually...I see it more in dapper then in breezy anyways
<Diziet> You're going to have a very hard job to convince me to do anything along these lines for Breezy.  And even then you'd have to convince the release people too.
<Diziet> I haven't looked into it in any detail, but I would expect us to take a new upstream for Dapper.  We'll want to review our patches and try to reduce them as much as possible IMHO.
<Diziet> So do look into it for upstream.  If you convince them within the right timescales then we'll include it automatically.
<zyga> mvo: hey
<zyga> mvo: I've noticed another irregular section in synaptic (the last one was 'translations')
<jbailey> ogra: Hey - Do you know anything about unionfs and ltsp?
<jbailey> ogra: I got a strange email from a guy asking how they worked together, and I haven't a clue.  I can ask him to go to the forums, though.
<ogra> i only heard it being mentioned :)
<zyga> mvo: is it too late for a patch? I know we're in upstream freeze and in string freeze probably but this is a minor and trivial fix *but* it adds to polishing and nice feel IMHO
<jbailey> zyga: If it breaks string freeze, and army of translators will gnaw off your toes.
<ogra> jbailey, i guess mdz can tell you how much (if any) unionfs is being used already in our ltsp
<jbailey> ogra: It's not a customer email, it's a random email, so forums are probably the best place for him.
<ogra> i know there were some serious bugs in the beginning of the release cycle in unionfs
<jbailey> Just that if you knew right now, I'd reply right now with better info =)
<ogra> you could point him to the edubuntu-devel list
<zyga> jbailey: otherwise an army of translators (me included) will bash you for untranslatable string
<\sh> Diziet: /quit laters
<zyga> the section I'm talking about is 'restricted' it contains restricted kernel modules
<jsgotangco> good night
<pitti> mjg59: here?
<nalioth> anybody heard of yesterdays updates killin the networking in ppc breezy?
<HiddenWolf> daniels: ping
<HiddenWolf> Last xorg update broke for me
<mjg59> pitti: Hi
<pitti> seb128: since recently I get a shiny on-screen display if I press the volume keys on my laptop; do you know which Gnome program is responsible for that?
<pitti> seb128: the problem is that both that Gnome program and pbbuttonsd respond to the mute key; the effect is that it does not work since mute is toggled twice
<spayne> will OOo 2 get a GTK file selector?
<mjg59> pitti: gnome-settings-daemon
<mjg59> (I believe)
<shackan> pitti, gnome-settings-daemon
<ogra> pitti, wasnt the selinux team planning to have a patched kernel image for universe ? do you know anything about it ? 
<pitti> mjg59: ah, could be; so I can rely on it running
<pitti> ogra: what for? selinux is built into the standard kernel
<ogra> pitti, ax and grsec ? 
<pitti> mjg59: then I just disable the mute key in pbbuttonsd; that will piss off people who don't use gnome, though
<ogra> pax even
<seb128> pitti: ? you mean the volume popup? it's here since warty ...
<pitti> ogra: no, I had a kernel patch for that a while ago
<spayne> doko: ping
<doko> Mithrandir: do we need the second ubuntu string in the OOo2-amd64 packages?
<pitti> seb128: hm, it didn't interfere with pbbuttonsd in hoary, at least
<seb128> pitti: oh, you never set a key for that before maybe
<doko> spayne: ?
<spayne> doko: will OOo 2 get a GTK file selecto?
<spayne> doko: will OOo 2 get a GTK file selector?
<pitti> seb128: I'm not sure whether to disable it in gnome-settings-daemon or pbbuttonsd
<seb128> pitti: that's the same issue than sleep, etc
<seb128> same piece of code doing the action
<doko> spayne: it does have one, but it's not enabled by default for stability reasons. you can enable it in the preferences
<pitti> seb128: not quite - if I disable it in pbbuttonsd, I will annoy e. g. xfce users; if I disable it in g-s-d, I will annoy users who change pbbuttonsd to pmud, or whatever
<pitti> seb128: and you would not get a fancy picture for muting
<spayne> doko: thanks
<spayne> doko: i also found i could change the icon set :-)
<zyga> what is the status of dbus in breezy, is it likely to change soon?
<Kamion> zyga: it'd better not; it's quite desktop-infrastructural
<seb128> pitti: changing GNOME would piss GNOME users
<pitti> seb128: I disabled it in pbbuttonsd for now
<zyga> Kamion: I'm trying to port a package from hoary to breezy and ran into one undefined constant ...
<seb128> pitti: ie: what would happen for people using g-s-d on a normal keyboard if you hack it?
<seb128> pitti: k
<Kamion> zyga: I don't know anything much about dbus itself; just speaking from a release-management point of view
<zyga> Kamion: okay, thanks
<Curalton> is the ncurses parition manager from the installer available as standalone somewhere? if so what is it called?
<Kamion> Curalton: not as a .deb, no
<Kamion> we may manage to make that happen in dapper, as part of the ubuntu-express project
<elmo> doko: ?
<Kamion> it'll be called partman
<doko> elmo: pong
<elmo> doko: 'sup with rrd uninstallables?  shouldn't they be okay now the new fontforge is in?
<doko> elmo: ttf-dejavu sync and move to main is required before these syncs
<elmo> did you request the sync already?
<Curalton> Kamion: aww, shame since it is the best i have seen so far. i guess same goes for the debian/sarge installer partmanager?
<doko> elmo: yes, and it was confirmed between the lines by mdz as well, same mail where he approved schoolbell and schooltool
<doko> mail from yesterday evening
<Curalton> ah, indeed "http://packages.debian.org/testing/debian-installer/partman" says " Do not install it on a normal Debian system."
<Kamion> Curalton: yeah, it's the same thing
<Kamion> (basically)
<Kamion> partman's been renamed to partman-base post-sarge to free up the name for a future partman.deb
<Curalton> ok, thanks for the info. back to fdisk and a piece of paper :)
<pitti> seb128: bah, this is so annoying; same story for the display brightness
<seb128> pitti: as said before, you will probably get that for a whole bunch of functions
<seb128> pitti: if both want to take actions ...
<pitti> seb128: I don't want to disable everything in pbbuttonsd, this will annoy console users
<seb128> pitti: but what is pbbuttonsd useful for?
<pitti> seb128: pbbuttonsd could check for pidof gnome-settings-daemon and not handle keys if there is one running
<pitti> seb128: it handles power management and CD ejection
<seb128> doesn't fix your console usecase
<pitti> seb128: i. e. suspend to ram, cpu clock frequency, etc.
<pitti> seb128: why not?
<seb128> I mean you can be on a VT with g-s-d running somewhere on the box (other user logged, etc)
<pitti> seb128: right, but g-s-d will react to it
<seb128> no if you have switched to a VT
<pitti> seb128: I meant, pbbuttonsd should stay active if you are not logged into gnome
<pitti> seb128: oh, I just see that the volume keys are not handled when swtiching to a VT; the brightness keys are, though
<seb128> I would say the desktop install is a GNOME desktop, if people have other usecase they can install pbbuttonsd, no ?
<pitti> seb128: I suspect the kernel itself could handle the brightness keys
<pitti> seb128: we can't uninstall it, we would lose power management
<seb128> hum, k
<seb128> so let's do your hack, if g-s-d is running ignore the volume/etc
<pitti> seb128: I can only deactivate brightness and audio keys completely, but that is annoying, too
<pitti> darn
<mx|gone> pitti: here's a thought... is there a way for g-s-d to listen to some signal from pbb and show a status window?
<pitti> mx|gone: no idea; status window?
<mx|gone> pitti: you know, the little window that pops up showing where the brightness is and such
<pitti> mx|gone: ah, that one
<mx|gone> s/where the/the level of the/
<mx|gone> pitti: kind of like how gtkpbbuttons does it?
<mx|gone> of course, then g-s-d would have to depend on pbbuttonsd on ppc
<seb128> you want to change it to catch pbutton signal instead of the keys?
<seb128> that's not an option
<mx|gone> ok, n/m
<seb128> you can change the keys from the GNOME UI 
<mx|gone> seb128: right... and you can unset all the mm keys
<seb128> that would not work with your pbutton/signal stuff
<seb128> change a key here should change the pbutton config
* sjoerd just doesn't use pbbuttonsd, no problems anymore :)
<mx|gone> sjoerd: what do you use?
<seb128> no, no, not a good idea
<pitti> sjoerd: how do you do power management?
* mx|gone guesses pmud
<sjoerd> cpufreqd for freq scaling, pmud to make the laptop sleep in some cases
<pitti> we can't change that for breezy
<sjoerd> and a small deamon for auto display brightness, but that should go in g-p-m ...
<mx|gone> seb128: I agree that changing a key in the GNOME config should change pbbuttonsd config, but how do you get a status update when the level changes from a key press?
<seb128> mx|gone: I say that would be a mess, not a good way to work on
<mx|gone> hrmm
<mx|gone> seb128: so, basically powerpc won't have status updates of brighness and volume changes
<seb128> ?
<seb128> the GNOME dialog doesn't work?
<seb128> nobody bugged about that
<pitti> seb128: it works
<seb128> so you get updates, no?
<mx|gone> well...
<pitti> mx|gone: when I press volume keys, I see the status icon
<pitti> I don't need one for brightness, I see the screen brightness
<mx|gone> pitti: yeah, but both gnome and pbbuttonsd see the key press and change the volume...
<pitti> seb128: so g-s-d detects whether X or the console is currently active, I suppose?
<seb128> mx|gone: pitti said he'll trash the volume part of pbbuttonsd
<mx|gone> seb128: ooooh
<pitti> seb128: since it seems to not react to the keys when I switch to a vt
<pitti> mx|gone: right now I only disabled the mute key
<seb128> pitti: g-s-d grab X events ...
<zyga> arghhh
<zyga> doing /etc/init.d/udev restart just crashed the kernel
<pitti> seb128: ah, I see
<mx|gone> pitti: nice work :)
<mx|gone> pitti: I'm sure you said this earlier, but will this disable the keys on console as well?
<pitti> mx|gone: hm, the only obviouos nonintrusive solution seems to be to deactivate brightness keys in pbbuttonsd for now
<pitti> mx|gone: yes, disabled keys will only work in Gnome then, not in VT, nor in XFCE, not even in gdm
<pitti> and that sucks
<mx|gone> yeah...
<pitti> actually we should disable it in g-s-d, this would be much more consistent
<seb128> pitti: don't touch g-s-d 
<pitti> i. e. g-s-d disables it if pbbuttonsd is running
<mx|gone> if only g-s-d could respond to a dbus signal or something...
<seb128> pitti: that would mean breaking the UI freeze to remove the options from the UI
<pitti> bah
<mx|gone> or if we could block pbbuttonsd from getting the key presses when GNOME is up
<pitti> mx|gone: doesn't fully fix it
<mx|gone> pitti: really?
<seb128> pitti: and that would piss some users who configure these actions from the GNOME UI
<pitti> mx|gone: if pbbuttonsd checks pidof g-s-d, then VT is still broken
<mx|gone> pitti: no no... is there a way to keep the keypresses from propogating to pbbuttonsd when g-s-d handles them?
<Curalton> pitti: ah, while you are at pbbuttonds problems, one problem i noticed was that while mouseemu is running (blocks touchpad while typing) pbbuttonds brighness and volume keys were broken, ftr :)
<Curalton> (ibook2 g3)
<pitti> mx|gone: I doubt it, pbbuttonsd reads directly from the kernel event interface
<zyga> yet another firefox is ot
<zyga> out
<pitti> Curalton: are you sure? please stop pbbuttonsd and try again
<sladen> daniels: I thought the whole point of modular Xorg was so that you didn't have to download the whole lot each time ;-)
<dilinger> spayne: --- Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )
<spayne> dilinger: ping
<spayne> dilinger: this is Seb Payne here :-)
<dilinger> hi
<spayne> dilinger: can we talk about ndiswrapper?
<dilinger> sure
<spayne> dilinger: in #dilseb
<pitti> *sigh* /me cripples pbbuttonsd for the sake of "Gnome, I don't tolerate any other UI besides me"
<seb128> spayne: are you the guy who blogged about openoffice beeing nicer on Suse? What is the difference? Do you have the -gnome package installed?
<spayne> i got it sorted now
<spayne> expect a post reedecing that statement
<seb128> spayne: cool :)
* spayne is an asshole sometimes
<seb128> pitti: hum, I could say the same about pbbuttonsd :p
<pitti> seb128: but it is more generic than g-s-d, it works everywhere
<pitti> :-)
<seb128> pitti: and it's not integrated
<dilinger> (have i mentioned that i hate this network?)
<seb128> pitti: ie: it's not a desktop user stuff
<pitti> seb128: I think we can do a proper solution in g-s-d in Dapper, but it is too intrusive for Breezy; agreed?
<seb128> pitti: yep, BOF about it ?
* jdub nods from the sidelines :-)
<Kamion> seb128: desktop software in "needing to talk to lower level software" shocker
<pitti> seb128: would be nice; it is a mess right now
<Kamion> :-)
<seb128> heh
<jdub> Kamion: strange architecture support software in "can't talk to anything" shocker :)
<jdub> toshutils, anyone? :)
<ogra> make a back and frontend ... and YAY you could put dbus in the middle :) 
<pitti> jdub: pbbcmd is actually nice, you can query and control everything with it; you just have to use it
<jdub> that's just crazy talk
<Kamion> jdub: *shrug* you get to deal with it if you're writing power/settings management software
<jdub> pitti: hopefully we can get g-p-m to support it
<jdub> pitti: via hal
<ogra> jdub, we will
<pitti> let's also add a TCP interface, so that you can control the volume of your neighbor's PC
<mjg59> jdub: And ROBOTS
<jdub> mjg59: with NANOTEETH
<ogra> pitti, bah and that from you ....
<ogra> pitti, it should be encrypted at least :)
<pitti> ogra: sure, we encrypt 1 bit to increase the brightness with 256 bit keys and digitally sign it
<Kamion> what, so that you can't tell how your neighbours are controlling your other neighbours' volume? ;-)
<pitti> Kamion: don't worry, of course we will have a higher level control API for that :-)
<ogra> pitti, yay, thats finally a reason to convince users to use gpg :)
<pitti> JaneW: where can we add BOFs again?
<ogra> https://wiki.ubuntu.com/UbuntuBelowZero/BOFs
<mjg59> Right. I definitely won't be at UDZ
<pitti> thanks
<mjg59> Uh, UBZ
<jdub> mjg59: :-(
<ogra> mjg59, :/
<pitti> seb128: ok, BoF added to the wiki
<Curalton> pitti: mouseemu / pbbuttonsd issue: yes, certainly conflicting. and even if i restart pbbuttonsd after starting mouseemu it still doesnt work
<Curalton> pitti: "it" being brightness, volume, eject cd key
<seb128> pitti: thanks
<Curalton> pitti: versions: mouseemu 0.15-2, pbbuttonsd 0.7.1-1
<pitti> Curalton: hm, that sounds tricky; if it does not even work without pbbuttonsd, there is nothing we can fix in pbbuttonsd...
<Curalton> pitti: err, these keys work with pbbuttonsd alone. only if mouseemu is running in parallel the keys stop working
<pitti> mvo: can you please set me as auto-assignee of pbbuttonsd? after that day I know the guts of it
<Curalton> pitti: ftr, before you scream at me, this is a debian/sid, not breezy
<seb128> pitti: I can do it
<pitti> seb128: oh, you too? nice
<seb128> pitti: yeah, I had to set the QA for quite a bunch of GNOME stuff for the desktop-bugs list ... :)
<Keybuk> *giggle*
<Keybuk> NotVersionedError: <unprintable instance object>
<Keybuk> Python censorship?
<mvo> pitti: yes
<seb128> mvo: I've done it
<mvo> seb128: faster as usual :p
<seb128> :)
<jdub> http://www.flickr.com/photos/linuxman/45331847/
<jdub> since when did wanda return?
<Keybuk> jdub: if you type "free the fish" into the run dialog
<jdub> heh
<jdub> oh man
<jdub> ha ha ha ha
<jdub> okay, so
<dholbach> re
* mvo giggles
<jdub> removing gss while gss has the screen locked
<jdub> not a good idea
<jdub> "Where is the lock dialogue binary?"
<mx|gone> jdub: ouch
<infinity> jdub : Yeah, actually, "removing it while g-s-s is still running in the background" is enough for it to blow up.
<jdub> hrm, didn't blow up for me
<infinity> jdub : After you switch, you need to kill gss, or log out and back in, or the screensaver kicks in later and you can't unlock it.
<jdub> just didn't let me back in :-)
<infinity> Well, by "blow up", I mean "doesn't unlock"
<jdub> yeah, killed it from ssh
<ogra> kill it 
<ogra> ah
<infinity> But yeah, the screensaver doesn't actually have to be on/locked when you swap.
<jdub> yeah
* jdub is back in the loving arms of xscreensaver
<jdub> never anticipated saying that before
<ogra> heh
* jdub can't wait for dapper's feature list: "jwz don't live here no more"
<ogra> YAY
<jdub> ogra: ah, nice bg on xss
<ogra> sabdfl didnt like it
<jdub> ogra: can we, ah, s/Someone else/Switch user/ ? :-)
<mx|gone> jdub: yeah, one thing I like about xss is that when it's locked, you can just type in your password... you don't have to wait for the dialog to pop up
<ogra> thats why we switched
<ogra> jdub, sure, i'll wait for mpt input on it i think there will be more tweakage needed
<mx|gone> ogra: it is?
<jdub> ogra: "Say, instead of switching to software that isn't ready yet, how about I do another iteration of the background image?" :-)
<jdub> ogra: not sure more tweakage is worth it with xss at this stage
<ogra> jdub, i did... 
<ogra> jdub, i also pointed out that gss is lacking configurability
<Kamion> mdz: your casper arch mirror seems to be out of date again; do you not update it in a commit hook?
<infinity> mvo : Erm, when did "Add Applications" migrate out of system tools into the main Applications menu again?
<jdub> hey, if cliff's splash is good, that might be a worth bg for the xss lock dialogue
<seb128> infinity: like 1 week ago
<ogra> infinity, when sabdfl asked for it
<infinity> Wow, I'm observant.
<infinity> The clutter annoys me.  Oh well.
<jdub> infinity: pay close attention! i'll take your brain to another dimension!
<mvo> infinity: what ogra said
<zyga> mvo: hey, did you get my message about synaptic?
<mvo> zyga: which one?
<ogra> jdub, its black... not a good iea for the lock dialogue
<seb128> infinity: edit /etc/xdg/menus/applications.menu if you want to drop it
<ogra> idea even
<jdub> ogra: the gnome splash
<zyga> mvo: about missing 'restricted' section
<ogra> oh, we have a new one ? 
<jdub> we will
<mx|gone> is there a reason that "search & indexing" is in "Accessories" and "Preferences"?
<infinity> seb128 : Yeah, I know how to move it, I just disagree with the default.  Oh well, can't please everyone.
<mvo> zyga: hm, no. when did you send it?
<ogra> jdub, actually the gss discussion started with sabdfl saying that cliff should put the lock pic on his todo list
<zyga> mvo: ah, it was here on #u-d 
<jdub> ah, ok, no one told me :)
<zyga> mvo: the short story: missing 'restricted' section
<zyga> mvo: the long story: string-freeze ;] 
<mvo> zyga: can you /msg me the details?
<ogra> jdub, so we should forward that request to him once sabdfl approved the switch back
<zyga> sure
<jdub> ogra: i'll mention it anyway (mdz switched u-m anyway)
<ogra> yup
<mdz> Kamion: no, I do not update it in a commit hook
<ogra> oh, that reminds me, i need to switch edubuntu-meta...
<mdz> morning all
<ogra> morning mdz 
<WaterSevenUb> mvo, will u be able tu upload the .desktop files I sent you soon? :-)
<mx|gone> is there a "Ubuntu Weekly News"?
<mdz> Kamion: I prefer not to have commits to a local archive be dependent on ssh connections to rookery
<jdub> mx|gone: not atm
<ogra> mx|gone, ubuntu taraffic ... but thats rather monthly and far behind
<ogra> traffic too...
<mvo> WaterSevenUb: I think so :)
<jdub> meanwhile
<jdub> *cough*
<jdub> http://fridge.ubuntu.com/
<jdub> *cough*
<jdub> ssshhh :-)
<ogra> FRIDGE !
<seb128> hi mdz
<jdub> mx|gone: keep your eye on that site :)
<ogra> whaa, how do i get rid of the fish on my desktop now ? 
<mx|gone> jdub: thanks :)
<ogra> jdub, where is the coke logo ? 
<jdub> heh
<ogra> :)
<jdub> that site was so annoying to see :-)
<ogra> yup... they advertise it on tv every night here
<ogra> hahaha, if you click the fish it flees :)
<Kamion> mdz: commit hooks do not have that effect
<mdz> Kamion: can you give me the one-liner?
<Kamion> mdz: I do basically 'case $1 in commit|import|tag) baz archive-mirror -a "$ARCH_ARCHIVE" "$(baz parse-package-name --package-version "$ARCH_REVISION")" ;; esac' in .arch-params/hook, and it just gives me an error when it can't talk to rookery, but otherwise commits fine
<mdz> Kamion: an error, or a timeout followed by an error?
<mdz> I suppose I could fork it into the background
<Kamion> oh, it might timeout. easy enough to ctrl-c though, baz doesn't care at that point
<Kamion> it's already done the actual commit
<mdz> I don't want it to block
<Kamion> hmm, I generally don't care
<pitti> mdz: you could do a ping -c 1 before
<Kamion> I'll ctrl-c it if it bothers me
<mdz> Kamion: anyway, mirror updated now
<mdz> updating, even
<Kamion> ta
<Kamion> I have a quick gnome-screensaver fix for you - not that it matters for breezy now, but it'll matter later
<ogra> Kamion, ?
<Kamion> ogra: for casper. gconftool-2 needs to be run as the ubuntu user not as root
<ogra> yup
<ogra> since its for the session...
<ogra> didnt i mention that ? 
<Kamion> in fact that also applies to gnome-panel-data
<Amaranth> "In addition, some regressions introduced by previous 1.0.x security updates have been resolved."
<Amaranth> 1.0.7 looks useful if anyone is still having problems
<Amaranth> with firefox, that is
<pitti> Amaranth: we will get it soon, I hope
<infinity> pitti : Did I just hear you volunteering?
<pitti> infinity: I hoped to bribe Diziet somehow
<Kamion> mdz: colin.watson@canonical.com--2005/casper--gconftool-as-user--0
<pitti> infinity: I can do it of course, but that will mean another day of updates
<infinity> pitti : Does 1.0.7 have any security updates you haven't already backported?
<mdz> Kamion: what broke this?
<mdz> it used to work
<Kamion> mdz: really? strange, I don't think it's new behaviour on gconftool-2's part, and the behaviour makes perfect sense
<Kamion> I haven't tested the gnome-panel-data change; I have tested the gnome-screensaver change (since today's live CD happens to have gnome-screensaver on it still)
<ogra> Kamion, it depends _where_ you set it...
<Kamion>     su ubuntu 'gconftool-2 -t bool -s /apps/panel/global/disable_lock_screen true'
<ogra> you can set it in a global schema dir as root
<Kamion> hmm
<Kamion> maybe that change was wrong then
<ogra> or set it with no schema dir as the user
<mdz> Kamion: oh, I thought you were talking about the gnome-panel-data bit
<ogra> mdz, same prob
<jdub> it's probably worthwhile doing those as schema changes
<Kamion> ok, gnome-panel-data bit reverted, it's already dealing with a schema change
<Kamion>     su ubuntu 'gconftool-2 -t bool -s /apps/gnome-screensaver/lock false'
<ogra> jdub, and have no loc icon in the menu ? 
<Kamion> so should that be gconftool-2 -t bool -s /apps/gnome-screensaver/global/lock false?
<ogra> lock
<ogra> nope, wait a sec
<ogra> gconftool-2 --direct --config-source xml:readwrite:/usr/share/gconf/local.default --type bool --set /apps/gnome-screensaver/global/lock false > /dev/null
<ogra> err
<ogra> local.defaults
<ogra> run that as root...
<Kamion> ew
<ogra> and kill -HUP `pidof gconfd-2` afterwards if gconfd is alredy running
<jdub> night all :-)
<ogra> nigh jdub 
<Kamion> seems like we might as well just run gconftool-2 as the user and then we can just leave the gconfd around
<Kamion> as well as not having the nasty path hardcoding
<ogra> i'm not sure if you can go without the HUP... seb128 `
<ogra> ?
<Kamion> this is running in casper, gconfd won't be running yet
<ogra> ah, ok
<ogra> then you can ignore it anyway
<ogra> but thats the default location for sysadmin settings
<ogra> so the right place to do such things
<Kamion> gconftool doesn't start gconfd itself, does it?
<ogra> it shouldnt...
<Kamion> ok
<Kamion> so how does 'gconftool-2 -t bool -s /apps/panel/global/disable_lock_screen true' work without the --config-source stuff?
<seb128> ogra: what?
<Kamion> and without --direct for that matter
<ogra> seb128, do you need the -HUP for gconfd as a user ? 
<dholbach> seb128: you wrote me some emails - that's SOOOO nice of you :)
<seb128> SIGHUP reload the base if you change some schema
<seb128> dholbach: yeah :)
<ogra> Kamion, it uses the .gconfd dir in the users home
<Kamion> that being root in this case
<ogra> hmm...
<ogra> so rather set it in the sysadmin schema dir...
<ogra> Kamion, see the contents of /etc/gconf/2/path
<mvo> Keybuk: now that you told us how to get wanda the fish, do you also know how to get rid of it again :P?
<Keybuk> mvo: pkill gnome-panel
<Keybuk> :p
<mvo> Keybuk: lol
<Kamion> hmm, well something broke there, a bunch of stuff died on desktop startup
<Kamion> I give up, don't have time for this
<ogra> Kamion, my first command didnt work for you ? 
<Kamion> ogra: I don't know exactly what broke, and I don't have time to debug it
<Kamion> since it was only for when we're using gnome-screensaver in the future
<ogra> Kamion, the command i gave you should work out of the box, its the way to set gconf keys... you will also need it for the lock entry in the panel menu (thats not gss dependant)
<Kamion> like I say, I don't have time. sorry. if you want to debug it, feel free
<ogra> oki
<jbailey> Is there a reasonable way to ask debuild to wrap all calls in linux32 from a configuration file?
<infinity> Just call debuild with linux32, all subprocesses of linux32 should remain linux32'd (if the kernel is correct and sane)
<jbailey> Right, but I keep forgetting and then having to track down why things suddenly broke on me.
<jbailey> debulid is kind enouhg to call fakeroot for me, I'm hoping I can overload the mechanism to call linux32 as well
<Kamion> that mechanism only applies to gain-root stuff at the moment
<Kamion> I don't think it's there for all external commands
<infinity> alias debuild='linux32 debuild' :)
<jbailey> Ooo, good call.
<infinity> (Might make it hard to linux64 it again later, but whatever)
<jbailey> I use 'db' for my one with ccache, I'll just tweak that one.
<jbailey> much better, thanks. =)
<infinity> You have an alias to use ccache?
<infinity> I just toss gcc* links in ~/bin
<jbailey> I add a -e PATH=
<jbailey> I don't keep ~/bin in my path
<infinity> Which works great, as they're followed in chroots where ccache is installed, ignored in ones where they're dead links.
<infinity> Ahh.
<fabbione> mdz: ping?
<elmo> I just export PATH=/usr/lib/ccache:$PATH
<mdz> fabbione: ?
<infinity> elmo : Oh, neat, I didn't know that link farm existed.
<fabbione> mdz: yo.. out of curiosity,, do you have any plan to uplaod mythplugins to breezy? (0.18)
<fabbione> mdz: as it is now they are not installable
* infinity adjusts his worldview and shell profile.
<infinity> fabbione : I asked the same thing a while ago, and he tried to rope me into comaintenance to fix it. :)
<fabbione> infinity: i am ok with that :)
<fabbione> mdz: i don't mind to spend time to understand how it works
* ogra had also a reques for mythplugins in -motu recently
<fabbione> mdz: i started installing my first mythtv box today :)
<fabbione> ogra: mdz maintains them officially :)
<ogra> yup
<ogra> thats what i told the guy
<fabbione> ogra: why -motu when you can bitch^Wask the real guy :)
<dholbach> fabbione: i'm working on the apt-get.org review - i will simply skip your repository, right? :)
<ogra> fabbione, the guy wanting them came there :)
<fabbione> dholbach: yes skip it 100%
<dholbach> done
<fabbione> dholbach: including mirrors
<fabbione> i hope to get the archive running again for dapper/sid
<mjg59> Keybuk: #15979?
<Keybuk> mjg59: yup?
<Keybuk> probably fixed by 14
<mjg59> Keybuk: Ok
<mjg59> Keybuk: Can you take it off me?
<Keybuk> done
<mjg59> Ta
<fabbione> elmo: ping?
<Mithrandir> doko: no, they second ubuntu is needed too
<elmo> fabbione: ?
<pitti> mjg59: btw, did you get my /msg about the pbbuttonsd patch?
<mjg59> pitti: Yes, but I can't /msg you back because freenode is stupid
<ogra> mjg59, youre not registered ? 
<guerby> jbailey, hi (again :) I can't find the thread about openssh-server install choice on ubuntu-devel, do you remember the subject line?
<jbailey> guerby: Oh, hmm.  Maybe I'm confused and am thinking of the xscreensaver post instead.
* jbailey digs up the minutes from the TB meeting.
<guerby> jbailey, are the minutes of TB meeting somewhere on the web? (I'm new to ubuntu process :)
<jbailey> guerby: The verbatum log from the channel is.  It's held in #ubuntu-meeting every other Tuesday.
<jbailey> I'm just looking for them right now. =)
<jcohen85> does anyone else notice that Breezy takes 10-15 seconds longer than hoary to boot up to a useable gnome screen? Before going to the splash screen there's a 15 second delay v. perhaps 5 seconds in hoary before it continued in the boot process. I'm running on an AMD 3000+ with 512 MB of PC3200 DDR. Hoary took 55 seconds to boot up to a useable state and Breezy takes 1:08 or so
<jbailey> guerby: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2005-09-20.html
<jbailey> Now I just need to find the right part.
<jbailey> jcohen85: 15 seconds before the splash screen comes up seems a bit high.
<ogra> guerby, the meeting was yesterday, the log url is in the topic of #ubunut-meeting
<jbailey> jcohen85: Do you mean from when grub stops counting?
<ogra> oh... to slow :)
<jcohen85> jbailey, no, from the time i select 2.6.12-8-686 in grub to the time the splash screen comes up
<jcohen85> jbailey, i'm running on a AMD 64 3000+
<jbailey> jcohen85: That really seems way high
* ogra didnt notice that on his amd64
<jbailey> On an amd64 here, it's more like 1 second or two tops.
<jcohen85> that's basically why it takes 15 seconds longer to boot up
<dholbach> ogra: you don't restart your box twice in a year
<jbailey> guerby: Hmm. I see mdz mentioning a web poll, I thought that it got posted to ubuntu-devel, but I'm clearly wrong. =)
<guerby> jbailey, "10:30	pitti	maybe default packages in server install? (openssh-server) 10:31	Keybuk	let's wait until jeff's customer turns up to defend that"
<ogra> dholbach, i did this morning :) 
<dholbach> oh wow
<jbailey> guerby: The discussion continues from there, though.
<jcohen85> jbailey, i also can't use 2.6.12-8-386 yet because of the /init 0x kernel panic which i posted as a bug on bugzilla
<jbailey> jcohen85: that bug is fixed now.
<jbailey> jcohen85: Are you still seeing it?
<guerby> jbailey, yes thanks (looks like I'm not alone "sivang	I always get annoyed seeing it was not already installed when installing a new server")
<mjg59> ogra: No
<jcohen85> jbailey, i posted that i ran dpkg-reconfigure linux-image-2.6.12-3-386 TWICE and the problem is still there
<jbailey> Did you mean -8-386 ?
<jcohen85> jbailey, i just tried purging the kernel and re-installing it
<jcohen85> jbailey, yeah, 2.6.12-8-386...and it showed the new .img files being created etc.
<ogra> mjg59, thast your prob then :) freenode had a heavy spambot attack that made IRC lients explode due to opened PM windows...
<jcohen85> jbailey, so, what would cause the long delay?
<jbailey> jcohen85: Can you put your /boot/initrd.img-2.6.12-8-386 somewhere I can find it?
<mjg59> ogra: Yes, I know. Hence "I can't /msg you back because freenode is stupid"
<ogra> mjg59, just register :)
<jcohen85> jbailey, sure- but first let me try to restart and see if the purge & re-install worked
<jbailey> jcohen85: I'd love to work with you on checking out the delay after, too.
<jcohen85> great- i'll be right back
<jbailey> guerby: Right.  So it's in the 'need more info to decide this' phase.
<guerby> jbailey, ok I'll wait for the poll :)
<mjg59> ogra: No
<guerby> jbailey, BTW I don't mind if it's not done in breezy because of freeze issues, etc... as long as it's considered for long term
<guerby> jbailey, thanks for your help :)
<jbailey> guerby: Cool.  The best bet is probably to poke your head in for the TB meeting in a couple weeks (assuming it happens. Sometimes they got dropped around freeze/release times)
<jbailey> jcohen85: and? =)
<jcohen85> jbailey, the purge & re-install worked
<jbailey> 'kay
<jcohen85> so my 386 kernel works fine
<jbailey> \o/
<jcohen85> but i'm still having the 15 sec delay
<jbailey> On both of them? 
<jcohen85> yup
<jbailey> What type of HDD (ide, scsi, sata, usb, etc?)
<jcohen85> IDE seagate 160 GB
<jbailey> locally connected? 
<jcohen85> yes
<jbailey> One harddrive, so no md?
<jcohen85> md?
<infinity> RAID.
<ogra> ... software driven
<jcohen85> yeah- no. it's a locally connected internal IDE drive
<jcohen85> and no RAID or LVM
<jbailey> jcohen85: evms?
<jbailey> (If you don't know what it is, then probably no. *g*)
<jcohen85> no, heh
<jcohen85> enterprise volume management system?
<jbailey> Yup
<infinity> You get a cookie.
<jbailey> Pitty it's an HTTP one...
<jcohen85> just plain ext3 partitions
<jcohen85> one for / and one for /home
<jbailey> Well, there go all the things that usually slow the boot down.
<jbailey> After that the only that that runs is the depmod.
<jcohen85> the rest of the boot process is fast
<jbailey> Is this your only computer?
<jcohen85> no
<jbailey> Or is there another one you can IRC from handy?
<infinity> Some driver/module that's taking forever to insert?
<jbailey> infinity: Do they do that?
<jcohen85> i also turned off bluez-utils, fetchmail, hplip, postfix, ppp, rsync, and webmin
<ogra> did our kernel image grow this much that it takes longer to decompress now ? 
<infinity> I don't know.  Does modprobe block?
<jbailey> I didn't think insmod heald for driver initialisation.
<infinity> Err, insmod, right, you're low-level.
<infinity> (ish)
<jbailey> Well, modprobe I think just calls out to insmod. 
<jbailey> I wind up using both in places.
<jbailey> modprobe is shiny.
<jbailey> It handles deps for me.
<infinity> Indeed. :
<infinity> )
<pitti> mjg59: ah, I suspected something like this; yay IRC
<jcohen85> unfortunately my debian system isn't booting up...problably a hardware issue caused from shipping. it just sits at some point in the boot process with no error
<jbailey> jcohen85: Y'know, we have a solution for other OSs that won't start up here...
<ogra> err, is modprobe run before usplash appears ? i thought thats only the uncompression of the image that happens at this stage
<jbailey> =)
<jbailey> ogra: depmod -a is run.
<ogra> ah, ok
<jbailey> Hmm.
<jbailey> We might actually walk the bus first too, I don't remember.
<jcohen85> jbailey, so, what should i do?
<jbailey> format the debian box^UWell, I need to be able to talk you through walkinmg thruogh the initramfs.
<jbailey> Or you'll be staring at information without me able to get it from you.
<mpt> Does anyone know the status of the new icons scheduled for Breezy, and/or the status of AndyFitz?
<jcohen85> jbailey, i spent days setting up the debian box with mythtv and a 500 GB LVM with 2 tv tuners...i don't want to format it
<jbailey> Ah =)
<jbailey> I keep hearing about mythtv, one day I should spend some time with google to figure out what it is.
<jcohen85> mythtv.org
<infinity> jbailey : It's looking for new comaintainers in Debian/Ubuntu, that's what it is.
<Keybuk> mpt: I think he's available, didn't realise he was your type <g>
<jcohen85> the problem is that i have no way to fix the problem since it silently fails- it just stops after setting up bttv
<carl> is bugzilla.ubuntu.com mia, or did I forget the URL?
<jcohen85> jbailey, would you like to know how long it takes to get by the decompression stage in 2.6.10?
<jbailey> decompression stage?
<Keybuk> carl: wfm
<jbailey> If you're using 2.6.10, there was nothing to decompress.  grub did it for you.
<jcohen85> oh, ok
<carl> Wait a Fine Minute?
<jbailey> Is it pausing on a line that mentions decompression?
<Keybuk> carl: works for me
<Kamion> carl: "works for me"
<ogra> carl, "works for me"
<carl> oh yeah...
<carl> ping: unknown host bugzilla.ubuntu.com
<carl> #@$@#
<ogra> fix your dns :)
<jcohen85> jbailey, i'm saying there's 15 seconds between grub and the splash screen whereas in hoary there was only a very short delay before loading modules & processes...maybe 2-3 seconds
<jbailey> jcohen85: Right, and during those 15 seconds, what's happening on your screen?
<jbailey> Is it sitting on one line?  Walking through them slowly
<jbailey> ?
<jbailey> It is probably best to remove the wrod 'quiet' from the kernel command line for that test.
<jcohen85> jbailey, nothing...it just sits there saying "decompresisng kernel" i think
<jcohen85> i would have to go back and check for sure
<jbailey> If you could please.
<jcohen85> it's sitting on one line..doing nothing
<jcohen85> once the splash screen comes up everything goes by quickly
<jbailey> But do it without the 'quiet' line on the command line.
<jbailey> Then I need the last couple of lines before it pauses.
<jcohen85> oh, and btw- after i install a kernel, it removes my xp grub entry
<jcohen85> ok, i'll brb
<jbailey> jcohen85: Make sure you're not adding it between the lines that say "Don't touch anything between these lines" =)
<ogra> to late
<jbailey> up-arrow, enter is my friend. =)
<ogra> if he comes back ;)
<ogra> mdz, sorry for the flint noise, i told him he'd have no luck :)
<mdz> ogra: he tried to call me 3 times this morning
<mdz> the first time at 0800
<ogra> gah
<ogra> mdz, opinions on 15706 ? 
<jcohen85> it actually only takes about 10.5 seconds to go to the splash screen. in that time it looks like it's detecting hardware
<jcohen85> it doesn't sit anywhere for too long- the longest is on the dvd drive i believe
<jcohen85> and hoary took about 8 seconds doing the same thing- i guess i didnt notice before
<jbailey> Hmm.
<jbailey> Mostly now you just feel it because of how long the splash takes to come up, I guess?
<jcohen85> yeah
<jcohen85> it still does take 2-3 seconds longer for the same step
<jcohen85> but what's noticeable is how long it takes for the splash screen to come up
<jcohen85> actually- let me time the startup once more
<jcohen85> yeah, there's definitely a difference
<doko> Riddell: ping
<Riddell> doko: hi
<jcohen85> this time it took 14 seconds to get to the splash screen
<jbailey> From hitting enter in grub, right?
<jcohen85> jbailey, in 2.6.10 it takes 31 seconds to go from pressing enter on grub to the brown screen that starts when gnome starts loading
<jbailey> I have to run off to a doctors appt in a moment.
<jcohen85> and in total it takes 57 seconds to go from pressing enter in grub to a fully useable gnome desktop with icons and menu/clock loaded
<jcohen85> in 2.6.12 it takes 40 seconds to the brown gnome load screen and 1:06 for gnome to completely finish loading
<jbailey> jcohen85: I will give you a new initramfs-tools tomorrow to test with that should collect information for me.
<jcohen85> ok
<jcohen85> going from 30 to 40 seconds seems pretty substantial especially when most of the delay is in the beginning
<jcohen85> by 15 seconds, 2.6.10 is well into the bootup process
<jbailey> Right, it's probably just modprobe blocking on something for some reason.
<jbailey> I'll be able to tell what it is.
<jcohen85> isn't it strange that no one before me posted a bug report for the kernel panic i was getting
<jbailey> Gotta run, back shortly.
<jcohen85> it affected all kernels and apparently affected amd 64 chips- i just upgraded to breezy on the 17th
<jcohen85> thanks for your help
<smurf> I haven't heard from silbs WRT today's locoteam meeting. Can somebody ping her (SMS?) and find out if she'll be there?
<thesaltydog> is someone working on a graphical bluetooth configuration editor?
<mjg59> thesaltydog: Yes
<mpt> Keybuk: ha ha ... I only want him for his icons
<thesaltydog> mjg59, ok.. is it available? maybe an alpha-release?
<mjg59> thesaltydog: Not that I know of
<mjg59> Bastien Nocera is working on one
<thesaltydog> mjg59, thanks.
<elmo> Riddell: ?
<Riddell> elmo: hi
<elmo> Riddell: you know about kdelibs?
<Riddell> elmo: I should do
<elmo> Riddell: the FTBFS I mean
<Riddell> on i386?  fixing that just now
<mjg59> elmo: Did amd64 ndiswrapper builds get fixed?
<mjg59> Userspace builds, rather - the kernel's been sorted now
<elmo> ndiswrapper-utils | 1.1-4ubuntu1 |        breezy | amd64, i386
<elmo> Riddell: yeah - ok, thanks
<mjg59> elmo: Thanks!
<Mithrandir> elmo: somebody claims it doesn't work, though.
<mjg59> elmo: Also, as of tomorrow's kernel, nx6125 should be pretty decent out of the box
<elmo> Mithrandir: dude talk to the mjg59
<elmo> mjg59: sweet
<Mithrandir> mjg59: somebody claims it doesn't work, though.
<mjg59> Mithrandir: In what way?
<mjg59> Mithrandir: We don't yet ship an amd64 kernel with an ndiswrapper module
<Mithrandir> mjg59: hmm, indeed we don't.
<mjg59> But we will do from tomorrow
<ogra> Mithrandir, and even with selfcompiled ndiswrapper it works fine here...
* sivang --> back
<ogra> i use it since hoary for my linksys pcmcia card
<ogra> Mithrandir, are you sure the guy who complains uses 64bit drivers for his card ?
<Mithrandir> ogra: it appears he had a version mismatch
<Mithrandir> 15052
* fabbione looks at -changes and see... xserver-kdrive!
<ogra> Mithrandir, indeed, we only ship 1.1
<mdke_> anyone got an acx_111 pcmcia card which works ootb with breezy?
<CarlK> im on a Sep something Breezy, trying to file a bug report about fstab.  how can I get the date or something that will identify what version of the installer was used?
<CarlK> uname -a ?
<CarlK> Aug 30... good enough
<smurf> Hmmm... nobody here can ping silbs?? I find that somewhat hard to believe ...
<Kamion> CarlK: /cdrom/.disk/info
<CarlK> thanks
<CarlK> now if I can just remember my bz pw...
<jbailey> smurf: Wha?  She's not online atm acc to /wii
<Kamion> smurf: she more or less works UK working hours
<Kamion> unfortunately my phone is out of credit or I'd try SMSing
<smurf> Kamion: we have some locoteamMeeting topics she's mostly responsible for
<CarlK> wait... I don't have the CD.  I had an ISO but that got overwritten the next morning
<CarlK> I was looking for a someting on the box
<Kamion> you might find it in /var/log/installer/syslog
<Kamion> grep for cdrom-detect
<CarlK> /var/log/installer/syslog
<CarlK> er..
<CarlK> Sep  7 14:15:42 anna[6189] : DEBUG: ask for cdrom-detect, is menu item
<CarlK> is that useful?
<Kamion> CarlK: no, try not just the first match
<CarlK> thats all the matchs
<Kamion> er, one sec
<Kamion> should be something like "Oct 20 00:43:53 (none) user.notice cdrom-detect: Detected CD 'Ubuntu 4.10 "Warty Warthog" - Preview amd64 Binary-1 (20041020)'"
<Kamion> obviously that's ancient but the relevant code hasn't changed
<CarlK> Kamion, pxe booty stuff, so no CDrom... but I think the Aug30/Sep7 will be good enough.  plus I am going to confirm it all once I get back to my crash-n-burn box
<CarlK> and I am having to email my well constructed bug anyway cuz I can't figure out my bz password.... duh.
<Kamion> CarlK: ah, ok, I don't think it's stored anywhere else then
<CarlK> but hey, on the good side, a friends Win98 box got all hosed, so I thew a breezy box in the car and drove it over so her kids could type/print there homeowrk, and it has been running fine
<CarlK> so go breezy.
<CarlK> how come "detect printer" never sees anything I hookup?
<CarlK> shouldn't it at least figure out from lsusb what the printer is and tell me it isn't in the database?
<moyogo> hi, i was wondering if people can contribute to the ubuntu font?
<CarlK> or is this a bug: there is a 812c driver,  "find printer" didn't find it, lsusb shows: ID 03f0:0304 Hewlett-Packard DeskJet 810c/812c
<pablof> hi, whe i raise synaptic i get error  art_render_gradient.c:338: art_render_gradient_linear_render_8: Assertiva `offset_fraction <= stops[ix] .offset'
<pablof> somebody know this problem ?
<spayne> jdub: ping
<mvo> pablof: breezy?
<mvo> pablof: never seen/heard of that error
<pablof> mvo: yes, breezy
* ogra guesses cairo ...
<camilotelles__> pablof: this error was happening before? 
<pablof> no, this starting after dist-upgrade
<camilotelles__> pablof: what is the breezy version?
<pablof> camilotelles__: 20/09
<camilotelles__> if you try this version without the dist-upgrade the error occurs?
<pablof> camilotelles__: one moment... i will test
<camilotelles__> pablof: you have to reinstall...
<pablof> camilotelles__: ok, i reboot the pc. :)
<pablof> camilotelles__: and test
<camilotelles__> pablof: you have to reinstall the 20/09 version, test, do the dist-upgrade - test again.
<pablof> camilotelles__: with live cd
<camilotelles__> pablof: thats ok.
<lamont> pitti: hrm... langpacks and SCC archs...
<lamont> should SCC archs be stripping, and since we do, what about packages that are only built on that architecture?
<lamont> (since I _know_ you're not harvesting the translations...
<lamont> )
<pitti> lamont: as long as these arches export tarballs to your directory, that should be fine
<lamont> pitti: yeah, they don't yet...
<pitti> lamont: of course this means some overhead in the langpacks, but oh well...
<lamont> maybe I'll add at least one of them...
<lamont> pitti: that was really my question...
<pitti> lamont: we import all arches now
<pitti> lamont: so if there is an ia64 specific package, we will get its translations
<camilotelles__> pablof: if the error persists create a minimal python script to submit with the bug
<dholbach> the joy of apt-get.org: another funny debian/copyright file:
<dholbach> And SPICE3f5 (not installer) is distributed under the following licence.
<dholbach> "Free for people friendly to the U.S.A."
<dholbach> :)
<pitti> lol
<bddebian> hehe
<bddebian> Are there any left?? ;-)
<pitti> bddebian: hi
<bddebian> Heya pitti
<pitti> bddebian: enjoyed pctcl and pgaccess? :-)
<pitti> pgtcl, even
<bddebian> pitti: Were you able to get it in?
<pitti> bddebian: it's in breezy, and in Debian's NEW queue
<bddebian> Awesome, good work! :-)
<pitti> bddebian: so in breezy everything is fine
<bddebian> I'll have to try rhdb-admin now :-)
<pablof> camilotelles__: the error persit
<lamont> pitti: 171MB of translations incoming in about 10 minutes....
<pitti> bddebian: that also needs tweaks, at least the dependency
<pitti> lamont: carlos will love you :-)
<lamont> yeah, well, that dates back to jun 30. :-)
<pablof> camilotelles__: and not only with synaptic
<lamont> fabbione: you want sparc translations?
<carlos> pitti, lamont ;-)
* lamont ^5s carlos
<pablof> open a bug ?
* lamont manually runs getTranslations.py to make sure life is good.
* pitti relies on his daily cronjob to process it and can't wait to read the failure email
<CarlK> how do I debug this:  prop sheet says "status: printer not connected" and yet lsusb shows Bus 001 Device 005: ID 03f0:0304 Hewlett-Packard DeskJet 810c/812c
<martinhj> anyone of you knows how I can reach this "j@bootlap" guy who have created this NetworkManager repository for breezy?
<martinhj> I suppose that is not the version which is going to be in breezy?
<camilotelles__> pablof: submit the bug with the minimal script.
<ogra> martinhj, its already in since a week or so
<camilotelles__> pablof: I dont know what package you have to submit.
<martinhj> ogra: the vpnc plugin for nm too?
<ogra> pablof, the function art_render_gradient_linear_render is in libart (dunno if the bug is in libart or caused by something else though)
<ogra> martinhj, not as far as i know
<martinhj> ogra: and it wont be included?
<sladen> ogra / pablof: is synaptic using SVG icons containing gradients
<ogra> martinhj, depends if there is time left to review it for MOTU, we are currently focusing on fixing the remaining bugs
<pablof> ogra: ok, i will open the bug for libart
<martinhj> ogra: ok, thanks
<pablof> sladen: maybe the is librsvg2-2 
<pablof> ??
<ogra> could be
<pablof> ok
<ogra> are the other apps causing the error using svg icons ? 
<sladen> pablof: when exactly do you see this error.  What action in synaptic do you have to perform to see it?
<pablof> yes, but app wiht jpg icons occur
<pablof> sladen: whe i raise synaptic in shell
<pablof> sladen: i just execute synaptic
<sladen> pablof: yes. not error I get
<sladen> not an error
<mvo> pablof: any special theme or something? (sorry if that was asked before)
<pablof> mvo: a custom them for my "distribution ubuntu"
<pablof> ok, i change to original them and the problem solved. 
<pablof> mvo: but, do you have any idea for this problem are happening ?
<mvo> pablof: not right now. is synaptic the only application that dosn't cope with that theme?
* mvo goes to bed now
<bddebian> Dunno if you folks know but synaptics is on the list to be merged
<pablof> mvo: no, but with some applications. i can't identify a common behavior
<mvo> pablof: I'm off to bed now, please ping me about this issue tomorrow or file a bugreport with some more information about the used theme
<pablof> mvo: ok, i meet you here
<pablof> bye
<mvo> pablof: bye :)
<Kamion> bddebian: you mean synaptic or synaptics? they're totally different things
<Kamion> (synaptic is a package management frontend, synaptics is a touchpad driver)
<bddebian> Hmm, let me look, it's probably synaptics :-)
<bddebian> Doh, I am on crack, it's synopsis
<Kamion> synaptic is very definitely in main
* bddebian buries his head in the sand
<Kamion> ah
<Keybuk> mjg59: I don't think #15979 is a udev-related bug after all
<mjg59> Keybuk: Ok
<mjg59> I'm pretty certain it's not a usplash one
<Keybuk> for what reasons does usplash go away and give back the console?
<mjg59> After a VT switch or after 15 seconds of not being esnt a message
<dholbach> seb128: how was soccer? who won?
<seb128> dholbach: was fine, Auxerre won (2-1)
<seb128> mdz: I don't agree with #15372 beeing normal, it makes quite easy to get a crasher g-s-d due to it for a lot of locales, which means error messages, no icon, no theme, etc 
<daniels> sladen: don't get me started
<Riddell> seb128: did you hear back from the gstreamer-misc guy?
<seb128> Riddell: he said that's probably fine to split to create a -gtk, but not sure than that many people have no gtk installed on a desktop
<seb128> Riddell: is that a real issue for some users?
<Riddell> seb128: yes, it takes up space on the CD which we don't have
* Riddell wonders what would happen if ubuntu had to have kdelibs installed
#ubuntu-devel 2005-09-27
<tseng> gross
<seb128> kdelibs would be like libgnome
<seb128> or something GNOMish
<seb128> libgtk is not really GNOMish
<daniels> i thought libgnome was dying
<seb128> daniels: for GNOME 3
<seb128> we are not here yet, don't worry :)
<seb128> pick another GNOME lib if you want
<daniels> libgnomeui32 :P
* seb128 slaps daniels
<dholbach> good night... i'm off to bed
<seb128> 'night dholbach
<dholbach> night seb :)
<daniels> dholbach: night dude
<sivang> dholbach: night
<dholbach> night you two
<tseng> bye dholbach 
<dholbach> bye brandon :)
<sivang> seb128: I tried removing all the config.sub and .guss from the 12_autotools patch of gnome-panel, cdbs-edit-patch let me edit the patch this time, however, still no go at building the package afterwards
<seb128> what happens?
<lamont> j
<lamont> EWIN
<seb128> Riddell: I'll do the split patch tomorrow and send it to the Debian guy to know if he's ok with it
<seb128> sivang: what is the error?
<Riddell> seb128: thanks
<seb128> np
<sivang> seb128: sec, I noticed that I didn't kill all of the config.sub/guess stuff from the patch after all, do you have an automated way to do that? (through gaim maybe)
<sivang> s/gaim/vim/
<seb128> nop
<sivang> seb128: plain manual? :)
<sivang> seb128: ok, trying to other approach, why the panle_addto stuff is missing when I drop autotools patch entirly and recreate it aftere applying all other patches manually?
<seb128> yep
<sivang> seb128: (that's the only error I get when dropping the former 12_autotools and recreating it)
<seb128> how do you create this patch?
<sivang> seb128: I get the src pkg, rm debian/patches/12_autotools , cdbs-edit-patch 12_autotools, autoconf, rm -rf auto4mate/ , exit 0
<seb128> that's not an autoconf patch
<seb128> that's an autotools one
<seb128> the add to panel changes modify the Makefiles
<seb128> aclocal, automake, etc are used
<sivang> ok then, can I readd the 11_lpi_autoconf patch? 
<sivang> (in order to seperate the two and not mess with the 12_ one)
<seb128> no
<seb128> 12_ also update the configure
<seb128> that would be wrong to have 2 patch doing that
<mdz> seb128: it only affects users who choose a very specific combination keyboard layout and options, and it doesn't make the system useless if it breaks
<mdz> ogra: I don't know anything about gcompris; I gave 15706 to you
<seb128> mdz: very specific is english and any layout using a group 3 (ie: most of non-english languages)
<seb128> ie: use a de, fr, da, .. keyboard and try to add a en one
<seb128> but luser probably don't have 2 different layout configured, right
<ogra> mdz, yes, the question is, if i should follow upstreams suggestion to rather upgrade than fix it (the reporter is one of the upstream guys) i know a handfull of missing icons, but i dont know how many hidden bugs are there, apparently he tested the 7.0 version since a while on ubuntu (he's regulary in #edubuntu)
<seb128> still quite an annoy regression imho, and we have got a bunch of bugs about that
<seb128> s/oy/oying/
<daniels> mdz: if 'hoary regression' is critical, as my inbox seems to be telling me, then this is critical
<sivang> seb128: so , again, do I clean config.sub, config.guess, config.guess-cdbs and config.h.in from the patch? which ones should I leave inside?
<seb128> sivang: mail me the lpi patch, I'll update the autotools one and upload
<mdz> daniels: a hoary regression from a functional system to a non-functional system is critical; hoary->breezy upgrade failures are critical
<mdz> daniels: breezy has a bug that hoary doesn't have isn't automatically critical
<daniels> mdz: 'xlib doesn't support my locale' is allegedly neither of those two
<mdz> ogra: new upstream versions at this time are pretty insane
<daniels> mdz: certainly no more than 'xkb doesn't support my layout'
<seb128> daniels: use "french layout with english configured as second" and you get a desktop with no theme, no icon, etc
<daniels> seb128: ouch.  you should totally handle that more robustly.
<mdz> daniels: perhaps I misunderstood the locaale bug.  what is the functional impact on affected programs?
<seb128> daniels: g-s-d "just crash" as specified by the bug
<seb128> and it tries to restart
<seb128> it does that like 10 times and then stop trying
<seb128> and you have a broken desktop
<daniels> mdz: depends on how they're written.  likely just non-localised strings.
<daniels> seb128: nice
<seb128> if you are lucky, sometimes it crashes gnome-session with it
<ogra> mdz, ok :)
<seb128> and you have just a gdm screen :p
<mdz> daniels: broken localization means, for many users, that they become unable to use their computer
<daniels> mdz: (which to me seems no more critical than a keyboard layout which bears utterly no relation to what's on the keycaps.)
<daniels> mdz: broken keyboard means, for many usres, that they become unable to use their computer
<daniels> mdz: ranging from 'i can't do accents', to 'how the fuck do I even type my username on this thing'
<mdz> daniels: "have to use layout foo instead of foo,bar" != "broken keyboard"
<seb128> mdz: it makes GNOME unusable for non-english people setting an extra english layout
<mdz> daniels: how about we stop arguing about it and you fix the bug?
<mdz> daniels: you seem to have only 3 critical bugs at the moment and one of them has a trivial fix
<daniels> mdz: for many users, layout foo vs layout foo,bar, is an unusable keyboard
<daniels> mdz: and if the fix was actually that trivial, it would be uploaded by now.  but it isn't.  so it's not fixed yet.
<mdz> daniels: the fix for bug 15770 is trivial and it's been open for two days
<daniels> mdz: as in, neither of the bugs we've been talking about
<mdz> daniels: <mdz> daniels: you seem to have only 3 critical bugs at the moment and one of them has a trivial fix
<mdz> I didn't claim that the xkb bug was trivial; it's obvious from the bug log that it isn't
<daniels> there we go, 15770 fixed
<daniels> now where were we?
<mdz> we were at the part where you actually upload it
<daniels> no, we're beyond that part
<mdz> thank you
<daniels> i live to give
<mdz> so what's the deal with #13724 (the xlib locale thing)?  is that specific to certain locales?
<mdz> I haven't seen it myself, but it seems to be fairly common for upgraders
<daniels> as the title says, non-UTF-8 locales
<mdz> _all_ non-UTF8 locales?
<daniels> yes
<mdz> seb128: setxkbmap -layout fr,us works fine for me here.  as the title says, it seems to only happen when that option is also in use, and that option doesn't seem to be a default anywhere I've looked. is it?
<seb128> mdz: setxkbmap work, setxkbmap -print | ... doesn't 
<daniels> mdz: welcome to the land of non-obvious failure modes
<mdz> seb128: so -print | xkbcomp is what GNOME does?
<seb128> yep
<daniels> well, ish
<mdz> does that have some other effect beyond what setxkbmap <blah> does?
<daniels> but effectively
<daniels> yes, it's less shit
<mdz> ...
<daniels> i'd rather not explain xkb internals at this point
<seb128> mdz: "setxkbmap -layout 'fr,us' -model pc105 -option '' -option 'grp:alts_toggle'
<seb128> -print | xkbcomp - :0.0" is what GNOME does
<sivang> seb128: with some more bits of concentration I made it. I am now testing the build, if it's nice, I will upload source and you review, and if all fine we upload?
<seb128> k
<sivang> seb128: I appriciate the offer from before, but everytime you are helped, you don't learn things :-)
<mdz> seb128: can we get g-s-d to not crash when this happens?
<seb128> mdz: hum, make it robusts to libxklavier crashers ... I'll give it a try
<seb128> mdz: but that will give a silent keyboard breakage for users
<seb128> ie: they will get a default layout instead of what they configured
<mdz> seb128: they get that anyway; but currently they also get a crash, right?
<seb128> right
<daniels> this is a hillarious intersection of: xkb parser problem (somewhere in libxkbfile), x server problem (not dealing with xkbcomp bombing properly in the setmap request), gnome problem
<seb128> daniels: how GNOME? :)
<daniels> the former is *really* hard to solve properly.  the second I can solve really properly but not without being very invasive.  the latter is SEP so I don't care.
<daniels> seb128: no matter what I feed you, g-s-d should not crash
<daniels> seb128: similarly, the X server shouldn't ever bomb, no matter what sort of weirdo crack it gets from a client
<seb128> I agree
<seb128> but as just said, then you would get a silent (or not) layout breakage
<seb128> ie: user would get default config instead of what they configured
<seb128> which is not really nice neither :/
<mdz> right; we have a bug open about it
<mdz> daniel says that he will add some debugging
<mdz> I'm not sure what else we can do but debug it, unless we can revert to an older libxkbfile or whatever
<daniels> no, that code hasn't changed
<daniels> debugging> for me to work out what the christ is going on
<mdz> the code hasn't changed since hoary?  what did change to trigger the bug?
<daniels> subtleties in xk-c, iirc
<daniels> they did practically rewrite the whole thing
* lamont ->sleep
<seb128> daniels: has "grp:alts_toggle" to be the default?
<seb128> daniels: maybe we can change that to workaround the crasher
<daniels> seb128: it's not the default, no
<seb128> daniels: it is, and that's what makes it crashing
<daniels> er
<seb128> "If you look at 'fr', you'll see the default variant includes
<seb128> 'level3(ralt_switch)'"
<seb128> daniels: http://listserv.bat.ru/xkb/Message/880.html
<daniels> i just grepped for alts_toggle over /etc/X11/xkb and ~/canonical/xorg/monolith/xorg-6.8.2/debian, it's not the default :P
<daniels> level3(ralt_switch) != grp(alts_toggle)
<seb128> graa
<daniels> level3(ralt_switch) -> altgr switches to level 3 (i.e. shift on crack)
<daniels> grp(alts_toggle) -> both alt keys together change groups (think: layouts)
<seb128> hum,yeah, we want altgr for that
<daniels> right
<daniels> so the problem comes when you combine those two -- when you have a layout that uses altgr for third level, and both alts together to change groups
<seb128> daniels: but "-option 'grp:alts_toggle'" is used by default ..
<seb128> maybe we can't ride that of that
<seb128> that would workaround the crasher
<daniels> maybe alts_toggle is used by default in gnome, but not in X
<seb128> s/can't/can/
<seb128> yeah, that's what I'm saying
<daniels> oh
<seb128> "setxkbmap -layout 'fr,us' -model pc105 -option '' -option 'grp:alts_toggle'
<seb128> -print | xkbcomp - :0.0" is what g-s-d calls
<daniels> right
<daniels> but is that by default, or only when you select 'alts together toggle group'?
<seb128> would dropping the "-option 'grp:alts_toggle'" be an issue?
<daniels> well, it would mean that there's no way to switch between french and us layouts :P
<daniels> ctrls_toggle or altshift_toggle (or whatever it is) work also
<daniels> but the problem is matching what people coming from windows and/or os x expect
<seb128> I usually click on the applet to switch :)
<sivang> seb128: http://muse.19inch.net/~sivan/lpint/gnome-panel/ , phew ;)
<sivang> seb128: let me know how it looks and if you upload 
<seb128> k
<daniels> seb128: yeah, but some people hate azerty and would rather get rid of it at the login screen
<daniels> seb128: can't blame them
<sivang> elmo: can you whitelist my @ubuntu.com email address for katey as well ?
<sivang> s/katey/katie/
<Lathiat> sivang: *@ubuntu.com is whitelisted
<sivang> Lathiat: ah cool :)
<Lathiat> i asked the same thing last week ;)
<seb128> daniels: I don't have any option selected to switch groups, that probably the default one
<daniels> seb128: nah, you have to provide your own option to switch groups if you want it
<daniels> seb128: you don't get a default group-switching option
<seb128> -option 'grp:alts_toggle' is specified by g-s-d here
<seb128> and I've not picked any option
<daniels> seb128: that's gnome, then
<daniels> trust me when I say that X isn't setting that per default
<sivang> seb128: ok, hope my pkg passes your review, Bon Nuit :-)
<seb128> later 
<sivang> good night all
<seb128> daniels: I'm not saying X does, but g-d-s put that to its default call
<daniels> seb128: right
<daniels> seb128: probably libxklavier
<sebest> is it me or launchpad.net is really slow?
<zyga> sebest: 1000 people now went to see if launchpad is slow ;] 
<desrt> big plus to non-DMA-enabled CD drives: you can ping the machine and see the latency in the replies to judge if the installer is done copying the files over yet
<Lathiat> haha zyga 
<sebest> zyga: i just got a "proxy error"
<sebest> and i don't use any proxy
<Lathiat> sebest: its the proxy on the side of the launchpad stuff
<sebest> maybe they need a hardware crypto accelerator for ssl traffic ;)
<sebest> Lathiat: too bad i was discovering launchpad and starting to really like it, and it died...
<mxpxpod> is there a GUI option somewhere to put the home folder on the desktop?
<ogra> mxpxpod, i think there is only a gconf key
<mxpxpod> ogra: stink
<seb128> 'night
<tseng> jdub: is gnome-user-share porting to avahi?
<tseng> jdub: arrrrr, i found their CIA
<Lathiat> tseng, jdub: i ported it the other day
<Lathiat> tseng, jdub: i sent the patch to the maintainer, not commited yet but
<tseng> Lathiat: you are my hero, etc.
<tseng> Lathiat: im getting antsy for some webdav/zeroconf lvoe
<tseng> love.
<Lathiat> want the patch?
<tseng> i wont get to it today, would have to rebuild gnomevfs and all that jazz
<tseng> if gvfs even works with avahi now
<Lathiat> nah it doesn't
<tseng> doubt it with freezes and such
<tseng> there you go..
<Lathiat> no ones actually poarted it yet
<tseng> dapper it is
<Lathiat> http://bur.st/~lathiat/gnome-user-share.diff
<tseng> dapper will be a giant zeroconf orgy
<tseng> and hopefully DAAP
<Lathiat> DAAP is in rhythmbox
<Lathiat> with avahi
<Lathiat> and banshee is getting support, as daap-sharp and avahi-sharp are working fairly well now
<Lathiat> and libnss-mdns 0.6 uses avahi if possible
<Lathiat> altho that reminds me
<Lathiat> i need to fix the ubuntu version
<tseng> banshee is getting support when abock fixes the 34242 other bugs
<Lathiat> to compile with avahi support
<tseng> ubuntu version of?
<Lathiat> anand being the silly goose he is decided to disable it, despite it not needing any runtime or build dependencies for avahi
<Lathiat> (nss-mdns)
<tseng> i see
<tseng> i thought that was part of the package
<Lathiat> yeh but he disabled it
<Lathiat> in the debian package
<tseng> when do we get 0.5 in breezy?
<Lathiat> for no reaon
<Lathiat> of avahi?
<Lathiat> soon
<tseng> yes.
<Lathiat> waiting on ross
<Lathiat> sent him the mono patch stuff
<tseng> elite
<Lathiat> said he was getting to it yesterday/today
<tseng> can i see that patch?
<Lathiat> which one?
<Lathiat> oh
<Lathiat> http://ajmitch.dyndns.win.co.nz/debuild/ubuntu/mono/0.4-0.5.debdiff
<tseng> oh did aj review it?
<Lathiat> ajmitch made it
<tseng> haha
* tseng set autoapproval mode
* Lathiat laughs
<tseng> i think he is missing some small stuff
<tseng> but it might work ok.
<tseng> like MONO_SHARED_DIR isnt set
<tseng> the buildd hates that
<tseng> it tries /home/buildd/.wapi
<tseng> = explode
<Lathiat> feel free to fix it ;)
* tseng pokes ajmitch 
<Lathiat> he fscke dup the control patch to
<Lathiat> i fixed that when i sent it to ross
<tseng> what a loser
<Lathiat> haha
<tseng> also we often have to mode -x on .dll files
<tseng> but not that important
<mjg59> How odd. My HP is now behaving strangely.
<tseng> Lathiat: ill look more when its in the archive
<tseng> Lathiat: and i can play around with it.
<Lathiat> tseng: _before_ it hits the archive would be a better time to fix it? ;)
<tseng> well i tried to build it on top of some installed package
<tseng> and its pretty effed up right now
<tseng> hard to test if the avahi# stuff has proper dllimport action
<tseng> hm
<tseng> Lathiat: http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html#s7.3
<tseng> Lathiat: right here is what im talking about
<tseng> do that export at the top
<tseng> and rm it in clean:
<tseng> thats all.
<jdub> GOOD MORNING FREEDOM LOVERS!
<tseng> hi jeff
<tseng> Lathiat: does that make sense, or should i really put a two line patch on my list?
<tseng> Lathiat: ill probably play with avahi again anyway
<ajmitch> tseng: so yeah, the avahi patch was a little broken, but I blame Lathiat for pressuring me
<tseng> oj
<tseng> ok
<ajmitch> Lathiat: and what was wrong with the debian/control? I didn't really look at the patch I made :)
<ajmitch> Lathiat: did you mean just the incomplete description that I asked you to fill in?
<Lathiat> ajmitch: yes :)
<Lathiat> ajmitch: i didn't pressure you i just... pestered you ;)
<ajmitch> Lathiat: meh, that's minor :)
<ajmitch> persistently pestered
<mjg59> mdz: What's the procedure for moving stuff from multiverse to restricted?
<mjg59> Can someone please rectify things so that going to https://launchpad.net/malone doesn't give me " Sorry, you don't have permission to access this page."?
<mjg59> crimsun: Ping?
<jdub> is there a 'boot without gdm' mode on the livecd?
<mjg59> crimsun: slmodem-2.9.10 is *not* a newer version than 2.9.9d, and it has the added "advantage" of not actually being distributable
<carstenh> jdub: single user mode ;)
<jdub> 'single' works on the livecd?
<carstenh> never tried it but it would be the first linux without i know
<carstenh> s/i/it/
* jdub does not trust this perspective
<carstenh> ... aka runlevel 1
<jdub> the livecd dude
<jdub> different kettle of fish
<mjg59> Oh, I see
<mjg59> If I go to "Ubtuntu" first, I can get to Malone
<TheMuso> c/c
<jdub> elmo: ping
<elmo> jdub: ?
<jdub> oh, hey
<jdub> yay
<mdz> mjg59: so far it's sort of ad hoc...what's the package?
<mjg59> mdz: sl-modem
<mjg59> mdz: Though first it needs to be rolled back to a version that we can actually legally distribute
<mdz> right, I didn't think we could
<mjg59> 2.9.9 is under BSD plus two binary blobs
<mjg59> 2.9.10 is under insane crack
<mjg59> 2.9.9d is actually newer than 2.9.10
<mjg59> But is a fork from the 2.9.9 codebase
<sladen> mjg59: I think there's a 2.9.9e
<crimsun> mjg59: err, eek?
<fabbione> lamont-away: well it's a bit too late for them, isn't it?
<fabbione> infinity: ping?
<jcohen85> jbailey, what do i need to do tomorrow to help you fix the delayed bootup issue?
<infinity> fabbione : pong.  Sorry dude, just woke up after mysteriously passing out in front of my computer early this morning.
<fabbione> infinity: ok.. any news for me?
<fabbione> infinity: re #15962
<infinity> (And many other bugs, too)
<infinity> I've made a pact with myself to not look at anything other than lrm until it's fixed, so that's what I'm on right now.
<infinity> Shame about all my other bugs. :)
<infinity> Every time I do a test build, i realise that somewhere in my 600k debdiff, I typoed something.
<infinity> (Yes, yes, I know, "test build, what's that?")
<fabbione> ok :)
<infinity> daniels : Hey, neat, looks like you're not the only person with the "my nForce NIC just spontaneously stops working for no good reason" bug.  (8229)
<fabbione> infinity: what version of the nForce?
<infinity> Completely different (and newer) motherboard in Daniel's machine, but I assume they both use forcedeth for the NIC, which is where I assume the bug is.
<daniels> rockin
<infinity> Not like that's any useful info to go on, so watch it not get fixed until it really irritates someone with way too much spare time.
<infinity> But, hey, "reboot into Windows to reinitialise the firmware with the nVidia driver" is a clever workaround.
<infinity> Right, this is what happens when I search bugzilla for "nvidia".  Sidetrack bad.
* infinity goes back to work.
<doko_> good morning
<crimsun> sladen: hmm, I only see 2.9.9e-pre2?
<crimsun> I'll go ahead and revert that brain-dead upload with some "really" versioning. Beats an epoch, I guess.
<crimsun> mjg59: thanks again
<dholbach> good morning
<fabbione> daniels: when i change something in aclocal.m4, how do i propagate the chage around?
<fabbione> daniels: i can never remember the libtool dance...
<daniels> autoreconf -v --install
<fabbione> thanks
<daniels> np
<pitti> Good morning
<\sh> morning pitti
<dholbach> morning pitti, morning Kamion 
<\sh> pitti: any experience with vpnc? ,-)
<Burgundavia> j #mlug
<pitti> \sh: none, sorry
<\sh> pitti: me neither...but it must be a cool small tool for connecting to cisco vpn concentrators
<pitti> yes, I read your mail on u-d and saw the description
<\sh> grmpf...
<\sh> doing a hoary -> breezy dist-upgrade ... and I see a lot of errors...
<\sh> where are the logfiles again for apts dist-upgrades errors?
<\sh> /var/log/base-config ??
<mvo> \sh: it's a bit embarrasing, but apt does not keep a log
<\sh> damn...
<\sh> because it doesn't upgrade without problems...grrr
<\sh> linux-kernel wasn't updated to breezy
<\sh> dictionaries-common had wrong values didn't pull in the german dictionaries
<\sh> (sorry...but i have to jump between two places here, and I need a scratchpad)
<\sh> mvo: we should implement it ;)
<mvo> \sh: the whishlist bug is only 3,5y old :)
<\sh> mvo: not long enough ;)
<mvo> exactly ;)
<\sh> restarted the laptop in single mode..trying to fix the mess now ;)
<\sh> btw...every employee here at ish running now around with a Hp laptop and ubuntu on it, is poking me now to fix this and that...it's scary...what did I do when I distributed the CDs ,-)
<mvo> hahah
<\sh> mvo: don't laugh..it's not funny...u won't get any issue report on your cable MTA anymore when this is not stopping ;)
<\sh> coffee now..brb
<\sh> ok...update is ok now from hoary to breezy...some entries in the sources.list were corrupt ... error due to problem sitting in front of the keyboard
<Treenaks> \sh: PEBKAC 
<Treenaks> ?
<\sh> Treenaks: well..the guy had some strange repositories in it...removed them, updated and everything was smooth..
<Treenaks> \sh: m.. m.. marillat?
<\sh> Treenaks: no...hoary stuff...no external backports
<\sh> jdub: is this you sitting there with no pants? http://lwn.net/images/ns/lca/d-waugh.jpg
<jsgotangco> hahaha
<Lathiat> haha, whats worse is im in the background
<jdub> over the dunking pool :-)
<\sh> jdub:  I just had a laugh flash when I saw this with luis' statement on p.g.o.
<\sh> Mentioned Ubuntu to him; he told a fairly funny story about 'this Ubuntu guy at OSCON who just wouldn't stop talking'. 'Australian?' 'Yeah, he was an aussie.' 'Yeah, I know him.' :)
<\sh> hehehhe
<\sh> and then this..
<jsgotangco> hehe
<jdub> taking my pants off and pimping the love... these are my vices. :-)
<\sh> now I'm just thinking to leave my trousers at home when I'm going to UBZ...
<Yagisan> G'day - is installing breezy on LVM over RAID working in the installer ? It didn't in hoary.
<mvo> jdub: the fade-effect of gksudo is now gone, but (some) people seem to dislike that (#15997, some irc remarks). do you think we should discuss it in e.g. a TB meeting?
<seb128> mvo: people are never happy with what they get :p
<daniels> tell me about it
<daniels> people get a US keyboard, they complain they want French, I point out that US is better, they just complain
<seb128> hahaha
<Lathiat> haha
<pitti> daniels: I agree that U.S. is really better than French :-)
<pitti> (keyboard-wise)
<daniels> (and German)
<pitti> grrr
<pitti> daniels:  !!!
<daniels> pitti:  !!!
<daniels> pitti: setxkbmap -option compose:ralt
<\sh> come on...kblayout bashing...
<daniels> although to be honest I have no idea how to compose a diaresis as opposed to an umlaut
<Lathiat> UK keyboard sucks
<Lathiat> cutting the left shift in half for the \ is just silly :)
<Treenaks> Lathiat: UK keyboard rocks
<Lathiat> esp since i keep doing ctrl-\ instead of ctrl-shift
<Lathiat> and SIGKILl the process
<crimsun> I'm slowly becoming accustomed to the | being down there
<\sh> Lathiat: depends on the keyboard...
<Lathiat> i kinda like the " being shift-2
<Lathiat> but thats about it
<Lathiat> \sh: dell laptop uk keyboard
<crimsun> (ibm uk here)
<\sh> Lathiat: the r200 keyboard actually is nice..but only the ' next to a small return key is just crap..anyways
<Lathiat> i mostly got used to it
<daniels> ibm us fo'lyf
<Lathiat> put i still never can quite hit the @ key right
<fabbione> elmo, Znarl: ping?
<Lathiat> tend to hit one of the others next to it
* \sh is going to have coffee ...
<daniels> Lathiat: isn't the @ key l3+q?
<\sh> brb
<daniels> or is that german
<pitti> daniels: that's German
<fabbione> who as a ppc and can test build a very small package for me?
<fabbione> s/as/hsa
<fabbione> amen
<fabbione> HAS
<daniels> itym ahem, rather than amen
<fabbione> amen was meant that way :)
* pitti raises hand
<fabbione> pitti: people/~fabbione/
<fabbione> there is the source for dmraid
<fabbione> can you kindly test build it on ppc?
<fabbione> it's no more than 200K to download
<pitti> fabbione: on it
<fabbione> thanks
<pitti> fabbione: ftbfs
<fabbione> pitti: can i see the log please?
<pitti> fabbione: darn, I build again with LANG=C
<pitti> fabbione: minute
<fabbione> it shouldn't make any difference
<pitti> fabbione: you probably can't read the German error messages
<pitti> fabbione: http://people.ubuntu.com/~pitti/shots/dmraid_0.9.9+1.0.0.rc8-0ubuntu1_powerpc.build
<hunger> Lathiat: Nobody stops you from moveing the keys around.
<hunger> Lathiat: I use a dvorakish keyboard layout with some keys shuffled around to meet my needs.
<fabbione> pitti: that error is weird
<jdub> mvo: there are no comments beyond the "this doesn't happen anymore" bit :)
<fabbione> pitti: all right.. endianess crap..
<pitti> fabbione: yay big endian...
<seb128> jbailey: around?
<fabbione> pitti: can you test a simple patch for me?
<fabbione> pitti: line 105 of that file is missing a ]  at end
<fabbione> - disk < &pdc->raid.disk[pdc->raid.total_disks;
<fabbione> +              disk < &pdc->raid.disk[pdc->raid.total_disks] ;
<fabbione> can you kindly check if that makes it?
<doko> ohh noo ... one guy asks to save in M*-Office doc formats by _default_ in OOo ...
<pitti> fabbione: yep, builds fine now
<fabbione> pitti: thanks!
<fabbione> Kamion: ping?
<Yagisan> doko: you are joking right ??
<Kamion> fabbione: yes?
<fabbione> Kamion: are we frozen in universe? if so can i upload dmraid to fix 15897?
<Kamion> ask the motus
<Kamion> it's up to them
<\sh> fabbione: what?
<\sh> fabbione: if it's fixing a bug, please upload
<fabbione> \sh: read the bug first...
<fabbione> the package is NEW
<\sh> one sec
<\sh> fabbione: no dependency issues..so go
<fabbione> ok
<fabbione> brb
<fabbione> gotta do another test first
<\sh> doko: rrdcollect failes to build on all archs yesterday...
<doko> \sh: will succeed, when the buildd's retry
<\sh> doko: k...cause my list of unmet deps is growing again ;)
<Kinnison> Hi all
<pitti> Moin Kinnison 
<Kinnison> I upgraded to breezy and have a few comments
<Kinnison> I spotted: Can't exec "/usr/bin/mkfontdir": No such file or directory at /var/lib/defoma/scripts/x-ttcidfont-conf.defoma line 252.
<Kinnison> during the upgrade of various font packages
<Kinnison> is this a known bug?
<Kinnison> Also: WARNING: Failed to parse default value `{????????????????????????????????}' for schema (/schemas/apps/gtali/PlayerNames)
<daniels> i guess defoma wants a better depends
<Kinnison> during the upgrade of gnome-games
<Kinnison> Also a suspend/resume cycle blows X out of the water but given how often X is being updated right now that might have been fixed already
<Kinnison> Other than that, the upgrade was pretty smooth and everything else seems fine
<daniels> suspend/resume> which chipset are you using, and s3 or s4?
<Kinnison> It's an i8xx (I'll turn it on in a sec) S3
<daniels> hrm, should work okay
<daniels> it's been working for me for ages, but I've had the kernel and udev on hold for quite some time
<Kinnison> Well, once my archive mirror is finished I'll try upgrading and trying again
<chmj> mvo: ping 
<mvo> chmj: pong
<Kinnison> lamont: you there?
<chmj> mvo: http://www.sourcecode.za.net/distupgrade-errors.txt 
<chmj> mvo: I'm not sure what failing there 
<lamont> yep
<zyga> hey everyone :)
<mvo> chmj: that looks pretty bad
<chmj> :/
<mvo> chmj: the error comes straight from dpkg, maybe a corrupted deb? but then, it shouldn't have passed apts md5 checking ...
<Kinnison> lamont: debian-installer-manual
<zyga> chmj: maybe your drive is failing
<Kinnison> lamont: daily builds thereof
<lamont> it's a feature.
<Kinnison> lamont: the Source: line it generates lacks the version number, yet the version of the package is not one for which we have source
<lamont> it comes along for free whenever you do a daily build of debian-installer
<pitti> Hi lamont - nice to see you in a more comfortable time zone :-)
<Kinnison> lamont: which is bad, mmmkay
<chmj> zyga: I doubt it
<lamont> it's a binNMU - the only one in the archive
<Kinnison> lamont: and the Source: line is wrong
<lamont> it's always wrong on binNMU's
<lamont> ==> sbuild bug.  someone should write a patch. :-)
<Kinnison> lamont: someone will have to or it will never make it into launchpad because it won't be able to attach it to a source package release
<mvo> chmj: can you compare the md5sum of the deb in your cache with the md5sum in your packages file (/var/lib/apt/lists/)?
<chmj> mvo: ok 
<chmj> brb, have to restart for d-bus 
<daniels> (so much crack)
<Kamion> Kinnison: can launchpad not do binNMUs?
<Kamion> if not, how's it going to model Debian?
<Kamion> (replay of yesterday's conversation, I guess)
<Kinnison> Kamion: well, unless I can attach the binary to a source package, we can't take it in
<Kinnison> Kamion: so if the binnmu declares its source version then we can take it
<lamont> Kinnison: none of them to today
<lamont> er, s/to/do/
<Kinnison> It's a hurdle we'll have to leap when we start trying to import debian I guess
<Kamion> Kinnison: binNMUs are sort-of-parseable (slight heuristic)
<Kinnison> Kamion: aye, it'll be the slight heuristics we'll need to sort out
<Kamion> Kinnison: if you can't find the source, chop off .0.[0-9] + from the version and see if you can find it now
<Kamion> or actually .[0-9] + first to see if it was a binNMU-of-sourceful-NMU
<Kinnison> so in other words, keep chopping off \.[0-9] + until I find a source or it doesn't chop any more?
<Kamion> only two levels
<Kinnison> okay
<Kinnison> and that'll cover most bin-nmus?
<pitti> mvo: nice patch for gksu! do you think you can add something similar to su?
<Kamion> re_bin_only_nmu_of_mu = re.compile(r"\.\d+\.\d+$");
<Kamion> re_bin_only_nmu_of_nmu = re.compile(r"\.\d+$");
<Kamion> Kinnison: (katie.py)
<Kinnison> Kamion: righty, ta
<Kamion> and yes, that's katie's algorithm
* Kinnison goes to look at the source
<Kamion> you're right, builds should get the Source: line right - but I'm not sure about what lamont said about it being an sbuild bug, historically the opinion's been that it's a dpkg-buildpackage bug
<Kamion> but unpleasantly hard to fix
<mvo> pitti: thanks, which patch exactly :) ? 
<Kamion> well, dpkg-dev somewhere anyway
<Kamion> Kinnison: http://bugs.debian.org/62529
<pitti> mvo: just read it on b-changes, "warn if user is not in sudoers"
<pitti> mvo: oh, wait, that's not what we need
<pitti> mvo: for su we need something like "root account is disabled, use sudo, kthxbye"
<pitti> mvo: it is a common source of confusion
<mvo> pitti: right, I'll have a look
<Kinnison> Kamion: thanks dude
<Kamion> Kinnison: fancy lunch somewhere today?
<lamont> Kinnison: here's what my NIH code does:
<lamont>         if not self.versions.has_key(ver):
<lamont>             dv=ver[ver.find("-")+1:] 
<lamont>             if dv.count('.')>=2 and ver.split(".")[-1] .isdigit() and \
<lamont>                    ver.split(".")[-2] .isdigit():
<lamont>                 x=ver[:ver.rfind('.')] 
<lamont>                 if self.versions.has_key(x):
<lamont>                     ver=x
<lamont>                 elif self.versions.has_key(x[:x.rfind(".")] ):
<lamont>                     ver=x=x[:x.rfind(".")] 
<lamont>                 if x==ver:
<lamont>                     print "#found binNMU of %s_%s" % (self.name,ver)
<lamont> Kamion: of course, part of me wishes that the debian-installer tar.gz was in the archive packed as well, but that's probably kinda silly
<Kamion> lamont: eparse?
<Kamion> oh, you mean debian-installer-images_*.tar.gz?
<Kamion> well, it's byhand, theoretically elmo can do whatever the hell he likes with it :-0
<Kamion> :-)
* Kinnison grins
<Kamion> I can see the argument for not duplicating it though
<Kinnison> Kamion: Is there a useful script yet for looking after those tarballs?
<Kamion> Kinnison: no, sorry
* Kinnison pouts
<Kamion> ask elmo, he's got a file he copies-and-pastes from that might be useful to you
<Kamion> but there's a stage in it where it just runs sh and expects you to clean up older unpacked directories
<fabbione> Kamion: can you kindly NEW dmraid? -> universe is perfect and it will stay there for breezy
<lamont> Kamion: yeah - that's the tarball I meant
<pitti> jordi: humm, the other day you asked me to build an asturian langpack
<pitti> jordi: but there are no asturian translations in the current sorce packages
<fabbione> pitti: dude.. that stuff is so full of crac
<fabbione> k
<fabbione> bella enrico 
<pitti> fabbione: crack *sniff* is goood
<pitti> Hi enrico 
<pitti> jordi: humm, and ast_ES is not in /usr/share/i18n/SUPPORTED
<Kamion> fabbione: I've NEWed dmraid source; surely the binaries can wait until elmo's around :-)
<fabbione> Kamion: sure.. it's more than fine, thanks
<enrico> hi!
<mvo> on one of my machines sudo dosn't print anything when a user who isn't in the sudoers file tries to run a command. has anyone seen this before?
<xerxas> seb128_:  ? 
<xerxas> u there ?
<seb128_> xerxas: pong
<xerxas> ca va ?
<xerxas> :)
<xerxas> want to have xchat-systray depend on xchat OR xchat-gnome 
<xerxas> is it doable ? (need to know if it works first )
<chmj> mvo: the md5sum is the same 
<ajmitch> evening all
<pitti> Hi ajmitch
<seb128_> xerxas: sure, that's on motu stuff ... could you put a malone bug for it?
<seb128_> hi ajmitch
<Kinnison> thanks guys
<xerxas> seb128_:  can I repackage xchat-systray ? 
<Lathiat> :q!
<Lathiat> -ETERM
<xerxas> seb128_:  I want to become a ubuntu contributor , how should I do ? 
<xerxas> where's the start ? 
<Lathiat> xerxas: check out http://wiki.ubuntu.com/MOTU
<mvo> chmj: can you make the broken file available for download?
<Nafallo> <Lathiat> xerxas: check out http://wiki.ubuntu.com/MOTU
<chmj> mvo: sure 
<xerxas> oops, don't understand why I'm cycling 
<xerxas> sorry guys 
<pitti> doko: humm, so what is the exact reason why we need openoffice.org-debian-files in main? to keep a symlink?
<Kamion> smooth upgrades?
<doko> pitti: no, to make sure the symlink is not removed. we can drop the package after release
<pitti> doko: TBH I don't know the details, but if we need it, that's certainly fine
<doko> pitti: we do, the old one did remove a file on purge not belonging to the package. if we don't upgrade it, spellchecking doesn't work in OOo2 when purging the OOo1 packages
<`anthony> So I upgraded my laptop from hoary to breezy just now, and I'm finding nothing mono-ish will run unless I manually set MONO_PATH to /usr/lib/mono/2.0 first. Is this normal?
<ajmitch> no, not really
<ajmitch> what errors were you getting?
<`anthony> can't find Mono.Posix, cant find System, that sort of thing ;)
<ajmitch> right
<ajmitch> reinstalling mono-classlib-1.0 will fix it
<ajmitch> but we're trying to get it so an upgrade works properly
<ajmitch> & the symlinks get in the right places :)
<`anthony> hm. reinstalling without nuking about 45 other installed packages?
<slomo> `anthony: apt-get --reinstall install mono-classlib-1.0
<`anthony> slomo: ta.
<`anthony> Ok, that made it all better. Probably not worth logging a bug, then?
<slomo> `anthony: there are already enoug bugs about that problem ;)
<`anthony> other than that, the only upgrade problem I had was that xfs got moved out of main and not reinstalled, but it was still referenced in my X config.
<`anthony> This meant X wouldn't boot.
<`anthony> easy enough to fix, tho.
<`anthony> Other than that, the upgrade was painless (if a little bit slow ;)
<Mithrandir> anybody know how I get gdb to tell me what the different varargs passed to a function are?
<Kamion> seb128_: the evolution icon's still missing from the top panel in default installs; was that meant to have been fixed?
<seb128_> Kamion: not yet, there is some upstream discussion on how it should be fixed
<Diziet> Weird.  I just had someone come to the door looking for `Stonham Housing', a housing association.
<Kamion> seb128_: ok, thanks. do you think it'll make final?
<seb128_> oh, for sure yep, it's on my list
<seb128_> GNOME 2.12.1 tarballs are due monday
<seb128_> it'll be fixed with the 2.12.1 upload
<ogra> grmpf, doko left ? 
<ogra> does anybody know if ooo is installable again ? my edubuntu CD is totally borked since yesterday
<Kamion> seb128_: great, thanks
<Kamion> ogra: that was temporary breakage yesterday, fixed mid-yesterday
<seb128_> np
<Kamion> ogra: it's fine on your CD from this morning, except on amd64
<ogra> Kamion, hmm, ok, so tomorrows build should be fine
<Kamion> oh, damnit, who broke hplip
<ogra> yup
<ogra> debian ? 
<Kamion> that's no excuse after UVF
<seb128_> hey vuntz
<ogra> Kamion, it wasnt meant as a excuse :)
<ogra> but the changelog is looong
<vuntz> hi seb128_
<Kamion> DOKO
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Uploads to main are flowing again, subject to FeatureFreeze | Colony 5 today sometime, necessary changes t
<Kamion> damn
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 today sometime, only necessary changes to main please
<pitti> ETOPICOVERFLOW
<jdub> mmm, the topic is not so informative as... eye glazing
<ogra> pitti, could i ask for a favor ? 
<pitti> sure :-)
<ogra> pitti, seems like i have some users who urgently want to use mknbi in a non networked install... could you review it
<ogra> ?
<pitti> I thought it was obsolete?
<ogra> its x86 only and should be fine...
<ogra> its used for creating etherboot images ... i would have been fine with it available in universe
<pitti> ogra: why he needs it in main?
<ogra> but if there is a big user demand i'll react if possible... its quite small
<ogra> pitti, without network i cant get it from universe
<pitti> humm
<ogra> pitti, i'm talking about "absolutely no chance for network"
<Kamion> uh, that would imply having it on the CD, which is a no-go at this point
<ogra> hum
<ogra> Kamion, why not ? it will only be on the edubuntu CD it wont affect ubuntu at all
<ogra> (i.e. it will be a dependency of edubuntu-server)
<Kamion> ogra: oh, you didn't say that earlier
<Kamion> whatever then
<ogra> Kamion, i just need main approval for it... which i didnt expect, but there seem to be more people needing etherboot than expected
<ogra> and its trivial small...
* ogra wonders what made the ppc iso explode
<pitti> ogra: approved
<ogra> yay, thanks :)
<ajmitch> sigh, still can't upload nevow to main :)
<ogra> Kamion, 15984  opinions ? 
<ogra> ajmitch, whats nevow ?
<ajmitch> ogra: web app template stuff for twisted
<ogra> ah
<ajmitch> ogra: if you want to sponsor my upload... :)
<ogra> ajmitch, youre a main uploader, arent you ? 
<Kamion> ogra: X preconfiguration doesn't use mdetect any more; just remove it from ltsp/server/ltsp-build-client instead
<ajmitch> ogra: key isn't in keyring yet
<ogra> Kamion, sure that wirks for ltsp-client ? i think mdz uses it in his clinet boot script
<ogra> works even
<ogra> Kamion, i'll wait for mdz to discuss it...
<Kamion> ogra: 'mdetect' doesn't appear anywhere else in ltsp
<ogra> ogra@edubuntu:~$ grep mdetect /usr/sbin/ltsp-build-client
<ogra>     test -z "$EARLY_PACKAGES" && EARLY_PACKAGES="x-window-system-core ltsp-client discover1 mdetect xresprobe udhcpc udev devfsd"
<ogra> test -z "$EARLY_PACKAGES" && EARLY_PACKAGES="x-window-system-core ltsp-client discover1 laptop-detect mdetect xresprobe"
<ogra> its not in any other tool though...
<sivang> hi all
<sivang> seb128: did you review my pkg?
<seb128> sivang: not yet
<sivang> seb128: k, I'll just wait for the mail from katie then :)
<Diziet> Why does breezy main contain two different versions of zope ?
<lifeless> for the love of it
<Diziet> I see.
<Diziet> No, actually, I don't see at all.  ?!
<lifeless> zope2 and zope3 are on vaguely the same
<lifeless> plone and other addins depend on zope2
<Diziet> How many webservers do we think it sensible to ship ?
<lifeless> zope3 is a clean overhaul from basically ground up
<lifeless> Diziet: zope2 is a CMS, zope3 is a web app framework, neither are 'webservers' per se.
<lifeless> besides which, are you counting twisted, python (has a built in one), apache, squid in accel mode, perl's various servers, ...
<jbailey> seb128: Am now
<Robinho_Peixoto> why it is not leaving but the packages with the translations?
<Kamion> Robinho_Peixoto: I couldn't understand that question
<Robinho_Peixoto> Kamion: language-pack-gnome 20050907 stop in this version 
<Kamion> "stop"?
<Robinho_Peixoto> yep
<Kamion> please explain
<Robinho_Peixoto> don't have new packages 
<Kamion> oh, that's in progress
<Kamion> pitti is working on that with the Rosetta team
<Robinho_Peixoto> GDM is leaving without the translations
<pitti> yes, I just reviewed a new tarball today
<pitti> tomorrow's could actually be good
<Robinho_Peixoto> don't has the package update-manager on rosetta
<Robinho_Peixoto> i open the bug in the bugzilla.ubuntu.com 
<mvo> Robinho_Peixoto: it's known and there is already a bug open about it. people are working on it
<Kamion> rosetta imports are a matter for #launchpad
<Robinho_Peixoto> Is correct to open there?
<Kamion> not bugzilla.ubuntu.com
<Robinho_Peixoto> Kamion: sorry
<Kamion> no need for an apology, just saying
<Kamion> I think there's already a bug open anyway
<Robinho_Peixoto> Kamion: OK. The times I espreo badly, because my English is bad!
<mvo> Robinho_Peixoto: it's bugzilla bug #15820 
<Robinho_Peixoto> The times what I speak bad are understood, because I do not know to speak well English.
<mvo> mpt: could you have a look at #16026 please? 
<mpt> mvo: ok
* lamont hateses hplip
<Robinho_Peixoto> mvo: I am open this bug
<mvo> Robinho_Peixoto: oh, ok. thanks
<Kamion> wow, save-logs' web server feature is so sweet
<Kamion> but let's merge a new version from Debian so that it actually works
<Kamion> hmm, maybe just a backport actually
<pitti> tseng: can you please make monodevelop generate a pot file during build?
<pitti> Diziet: do you feel like updating ffox and moz to the new versions?
<pitti> Diziet: unfortunately there are no updated MFSAs yet, and only a few CANs, but some are there
<Xof> are you guys interested in failed installation reports for the Breezy preview?
<Diziet> pitti: Yes, I'll update firefox.  I assume this is cause for an exception ot UVF ?
<pitti> Xof: of course. The best way is to file/follow up to bugs in bugzilla, but an email to ubuntu-devel is also appreciated
<pitti> Diziet: yes, we have a general exception for that even for stable releases (if we test everythign properly, etc.)
<pitti> Diziet: thanks
<Xof> we're fighting with bugzilla now :-)
<Xof> I wanted to know that the fight would be worthwhile
<pitti> Xof: many bugs are already known, so a search might even give you workarounds and solutions, but there are always new bugs
<pitti> Xof: yes, of course :-)
<Xof> pitti: it's possible that this hardware configuration (dual G5) hasn't been tried -- we didn't find many powerpc-specific bugs, anyway
<pitti> Xof: I saw G5 reports already, but I can't remember the details
<pitti> Xof: you might consider trying the latest daily; many bugs have been fixed since the preview
<jbailey> Xof: Is it a case of it not seeing your CDROM?
<jbailey> Xof: If yes, you might want to see: http://bugzilla.ubuntu.com/show_bug.cgi?id=10307
<dholbach> i'll go for an icecream, bbl
<pitti> dholbach: I want one, too!
<jbailey> Germany's small, p'haps we can bring you one ;)
<jbailey> s/we/he/
<dholbach> pitti: may i take your order, then? :)
<pitti> jbailey: :-) but Berlin-Dresden is still 200 km, too far to not melt the ice
<pitti> dholbach: same as always - one ball of each sort :-)
<\sh> pitti: put the liquid ice back in the freezer ,-)
<jbailey> Just need to drive fast, and keep in a covered container outside the window.  The compression of the air against it should keep it cool.
<dholbach> pitti: you should visit me and especially THAT ice cream shop - i'd have to carry 2 buckets of ice cream :)(
<Xof> jbailey: no, it's X not starting
<pitti> 2 buckets? man, you must be hungry
<\sh> one for dholbach one for murphy ,-)
<dholbach> pitti: no... if you'd like to have one of every sort
<ogra> did i hear icecream ??
<mxpxpod> pitti: do you have dri enabled on your ppc?
<pitti> dholbach: ah
<pitti> mxpxpod: it is enabled automatically on the Radeon 9200
<pitti> mxpxpod: I didn't have to do anything for it
<mxpxpod> pitti: could you run glxgears?
<Xof> it gracefully fails to start in framebuffer mode, and locks the computer up with the ati driver
<jbailey> Ah, okay.
<jbailey> I don't know the X bugs well enough to guess.  I know that there are a number of working configurations for X, though.
<pitti> mxpxpod: running, what now?
<mxpxpod> pitti: how fast is it running?
<pitti> mxpxpod: no idea; it used to display the frame rate in the past, but now it doesn't
<mxpxpod> pitti: is it going so fast that you can hardly see the gears?
<pitti> mxpxpod: no, by far not - the blue one is about half a rotation per second
<mxpxpod> pitti: hrmm... it should be going faster... mine goes about that slow too
<mxpxpod> pitti: so obviously dri only works for 2d
<ogra> yeah, lets switch GL benchmarking from fps to "rotation per sec of the blue gear" now that daniles has ripped out the pseudo benckmaring form glxgears *g*
<mxpxpod> ogra: :)
* pitti prefers the planetpenguin-racer benchmark
<pitti> much more fun
<mxpxpod> haha
<ogra> lol
<mxpxpod> pitti: is that something to do with xorg and the driver that ubuntu has chosen to use?
<pitti> mxpxpod: btw, pp-r runs fine, 3d acceleration is definitively there
<mxpxpod> strange... so why is glxgears running so freaking slow
<pitti> mxpxpod: why it should run faster?
<pitti> my penguin should not slide down the whole track in 0.5 seconds either
<mxpxpod> haha
<mxpxpod> why did daniels tear out the fps from glxgears?
<pitti> "glxgears is not a benchmark"
<Lathiat> mxpxpod: strings `which glxgears`
<ogra> mxpxpod, he didnt, he just made it an option ;)
<mxpxpod> ohhh
<mxpxpod> gotcha
<Treenaks> Lathiat: omfglol :)
<Lathiat> i didn't know daniel did it
<Lathiat> but i guessed
<Lathiat> my nvidia glx still doesn't go :(
<Lathiat> and i can't seem to get any info out of it
<Lathiat> fglrx is fixed now with libstdc=+5
<mx|gone> time to go back to work :(
<pitti> Diziet: we also need to update warty's and hoary's firefoxes; do you want to do that as well, or shall I do this?
<pitti> Diziet: ... same for Mozilla *sigh* - maybe I do mozilla and you ffox? would that work for you?
<Keybuk> "NPTL, besides the newly added support for SATA controllers and other hardware, is probably the biggest new feature of Slackware 10.2.
<Keybuk> "
<Keybuk> *boggle*
<Treenaks> Keybuk: that almost sounds like  s/Slackware/Gentoo/
<Treenaks> Keybuk: or they really suck
<jbailey> For a one-person project, the update to a new kernel and all the detection tools as well as a glibc update is a pretty big deal.
<Treenaks> jbailey: slackware is not a one-person project and hasn't been for a long time.. afaik
<Keybuk> Treenaks: yeah, it is
<Keybuk> Patrick is basically the only guy doing anything with it
<Treenaks> Keybuk: it is?
<jbailey> Ah really? I thought it was with all the fuss about him getting sick, and what would happen to slackware then?
<Keybuk> is just odd to think that most of us "newbies" probably started off with Slackware
<Keybuk> certainly it was the only real distro to choose when I started
<jbailey> minilin then slackware.
<jbailey> My first linux setup come on 4 floppies and was in portuguese. =)
<Treenaks> Keybuk: yeah, I started with slackware too :)
<Keybuk> heh, mine was a CD from Walnut Creek
<Treenaks> 30 floppies! :)
<Keybuk> I still remember transitioning to shadow passwords myself by hand, compiling all the bits, etc.
<Keybuk> I so could've almost been a Gentoo user
<Treenaks> I killed my system with the libc5 thing .. then I switched to Debian
<Diziet> pitti: Yes, I'll do the firefoxes.
<Keybuk> does Slackware include PAM yet?
<pitti> Diziet: great, I'll do the mozillas then; please upload the breezy one first, since katie chokes if you upload a new orig.tar.gz in a security upload
<pitti> Diziet: AFAICS, the only security issue is the shell injection, right? we already fixed the hyphen one in all releases
<Diziet> pitti: katie> Noted.
<pitti> Diziet: however, upgrading to the 1.0.7 might still be worthwile if it really brings stabilization fixes
<Diziet> I haven't read the release notes yet.  I got the impression from my email exchanges with them that there were various other things.
<pitti> Diziet: (otherwise the shell injection patch is easy)
<Diziet> Most crashing bugs are security bugs somehow.
<pitti> only if you can trigger them remotely
<Kamion> the bulk of browser bugs are remotely-triggerable though, if only by putting up a web page and waiting
<pitti> right
<pitti> but fixing every ffox crasher would be a pretty big task :-)
<Diziet> We could at least fix the reproduceable ones people seem to have spotted.
<pitti> sure
<Diziet> It's a bit like bailing out the ocean - into a lake.
<Diziet> The redacted security issue list thingum doesn't have the data for 1.0.7.  And I'm not diffing the whole thing if I can help it.
<pitti> Diziet: oh, I know the patch for the shell injection vuln
<pitti> Diziet: https://bugzilla.mozilla.org/show_bug.cgi?id=307185
<Diziet> Well, yes.  I mean, I'm not diffing 1.0.6 against 1.0.7 to look to see if there's anything else we need and to try to decide for each one separately.
<pitti> argh, Thunderbird is vulnerable, too
<pitti> Diziet: oh, no
<pitti> Diziet: we fought with backporting single patches far too long to do that again
<Diziet> I'll apply our 1.0.6 diff to 1.0.7 and see how bad it is.  Ah here comes the tarball.
<pitti> Diziet: the 1.0.6 diff already contains the hyphen patch
<pitti> so that will be rejected
<pitti> (yay missing patch system)
<Diziet> I don't mind dealing with rejected patches if I don't have to deal with a patch system tarpit nightmare of doom.
<pitti> Diziet: ok, it seems we have fundamentally different preferences how to deal with a package :-)
* pitti <3 cdbs+tarball+simple-patchsys
<dholbach> you like using tarball.mk?
<daniels> pitti: HATE
<daniels> dholbach: i'm far more concerned about simple-patchsys
<dholbach> i always tried to like it, but failed abysmally
<jbailey> dholbach: tarball is nice. =)
<pitti> dholbach: yep
<jbailey> dholbach: It means that all I have to do when I'm done is rm -rf the directory. =)
<pitti> dholbach: never ever destroy your sources again, nicely supports multi-build
<Diziet> cdbs ?!
<dholbach> hm, but patching a non-extracted tarball, hm
* Diziet vomits.
<pitti> dholbach: cdbs-edit-patch does that nicely for me
<dholbach> pitti: oh it now does?
<pitti> dholbach: well, my version on my hard disk at least
<ogra> Diziet++ :)
<pitti> not yet the official one
<dholbach> pitti: UPLOAD IT! MAN!
<dholbach> that's what i was waiting for :)
<pitti> nobody asked me to so far
<jbailey> Diziet: if you have specific issues with cdbs, I'm still hacking on cdbs2. =)
<pitti> jbailey: will it ever be ready? :-)
<jbailey> pitti: Who knows? =)
<daniels> pitti: there are patch systems which don't destroy your sources, and also don't require tarball.mk :P
<jbailey> pitti: It's usable now.
<pitti> oh, cool
<jbailey> pitti: It just is missing testsuite stuff.
<daniels> pitti: also, srcdir != objdir works fine for multi-builds
<daniels> pitti: i do that for libx11, e.g.
<jbailey> It's tempting to just deploy it. =)
<dholbach> daniels: it doesnt require tarball.mk :)
<pitti> daniels: right, I'm still waiting for wig&pen support in dpkg-source
<daniels> dholbach: no, no, it does.
<daniels> pitti: dude, dpatch
<dholbach> daniels: which one?
<daniels> dholbach: simple-patchsys
<dholbach> daniels: it doesnt
<daniels> dholbach: it requires one of tarball.mk, or deleting your entire working tree fifty times for every revision
<jbailey> My dislike of dpatch mostly comes from having to twiddle to get -p flags right when it should just autodetect it for me.
<pitti> daniels: dpatch is ugly and it does not prevent source destrucion in any way (unless you use it with a tarball)
<daniels> this is actually a large part of the reason that I ignore simple-patchsys
<jbailey> Is the autodetection?
<daniels> pitti: simple-patchsys does not deal with failure, full stop
<jbailey> simple-patchsys should unwind better, yes.
<daniels> pitti: dump a patch which doesn't quite apply into debian/patches, bam, watch your entire tree now become horribly wedged and not work without hand intervention
<daniels> pitti: otoh, I don't think I've ever managed to wedge a tree with dpatch
<jbailey> I have. =)
<pitti> daniels: that's where tarball will clean up
<jbailey> But mostly with bad -p munging.
<daniels> pitti: my claim is that if your patchsys relies on a dbs-alike system, it's horribly broken
<jbailey> It doesn't rely on it, there's simply a bug.
<pitti> daniels: sure, if you don't like it, nobody stops you from using dpatch or quilt with cdbs
<jbailey> Does dpatch have cdbs integration now?
<pitti> daniels: given that simple-patchsys was more indended to be a demo than something working, it works pretty well for me
<jbailey> I know that quilt does.
<daniels> jbailey: i'm bitching about simple-patchsys, not cdbs
<pitti> /usr/share/cdbs/1/rules/dpatch.mk
<daniels> s/jbailey/pitti/
<pitti> daniels: sure, I know :-)
<jbailey> daniels: Right.  But simple-patchsys' failure to unwind is a bug, not a design flaw.
<jbailey> daniels: It has all the stamp files, it just needs to unwind over those *before* deleting, them not after.
<daniels> jbailey: dpatch's md5summing is well worth looking at, too
<jbailey> daniels: Ah, cool.
<jbailey> daniels: I'll ask you for tips when I get that far with cdbs2.  Mostly I've had trouble wanting to hack on build systems in my evenings, y'know? =)
<jbailey> cdbs was mostly done while I was working at an IT job. =)
<mx|gone> this is probably a stupid question, but is it too late to get the bluetooth hid patch into the kernel for breezy?
<daniels> jbailey: wanting to hack on build systems> i can relate
<jbailey> mx|gone: Probably, yes.
<mx|gone> damn
<jbailey> daniels: Dude, you've had to look at far too make imake setups, for which you have my infinite sympathy.
<daniels> jbailey: yes, and then I unwound by autoconfiscating the tree
<jdub> my sympathy is finite
<jbailey> =)
<jdub> i just don't want to feel like i'm feeling like that
<jbailey> jdub: I'm Canadian.
<jbailey> daniels: Yeah, I was supposed to help with pieces of that and got busy.
<jdub> what, you have maple-powered sympathy engines?
<daniels> jbailey: i'm *so* sorry
<daniels> jbailey: ah, nevermind.  we got it all done.
<jbailey> jdub: I'm from Vancouver.  The trees that we grew weren't maple. ;)
<jdub> :-)
<janimo> jbailey, is there still support for mkinitrd now that initramfs is used?
<janimo> I ask because apcid still installs /etc/mkinitrd
<janimo> acpid
<jbailey> janimo: initrd-tools is dropping to universe, I think.
<dholbach> hi janimo 
<janimo> hi dholbach :)
<Diziet> Dammit, which does patch convert rejected diffs to that lame cdiff format ?
<janimo> dholbach, we'll meet between 18-26 oct sometime ;)
<dholbach> janimo: sounds super, i look forward to that :)
<Sumire> RO Server: irc.yuki.deltaanime.net #SolaceRO
<Sumire> RO Server: irc.yuki.deltaanime.net #SolaceRO
<Sumire> RO Server: irc.yuki.deltaanime.net #SolaceRO
<pitti> daniels: btw, http://people.ubuntu.com/~pitti/scripts/cdbstpatch is there for ages; that one creates/edits patches for cdbs+tarball
<daniels> pitti: meh, I just commit it upstream and take a new CVS snapshot
<pitti> pitti: context?
* ogra thinks pitti asking himself about the context of his own words is quite worrying...
<pitti> darn
<pitti> daniels: in which context?
<ogra> :)
<pitti> thanks, ogra
<pitti> time to get some fresh air, as soon as I finished teaching langpack-o-matic how to import k3b-i18n
<daniels> pitti: i don't patch X stuff, I just commit it to CVS and use that
<pitti> daniels: ah :-)
<tseng> pitti: ping
<pitti> Hi tseng 
<tseng> pitti: hi :)
<tseng> pitti: was there something about privelage dropping in tethereal?
<pitti> tseng: hmm, not recently; however, the current hoary version has wide open holes, if you mean that
<pitti> tseng: why priv dropping?
<tseng>  * debian/patches/04_drop-capabilities.dpatch: preserves CAP_DAC_READ_SEARCH
<tseng>     which seems necessary for sudo usage (closes: #320453)
<tseng> hm
<tseng> pitti: well, i am running it as root (or sudo) and it cant write a wide open dir
<tseng> pitti: touch or rm work in the same context
<tseng> it gets EACCESS
<pitti> tseng: is the dir owned by root?
<janimo> jbailey, if mkinitrd goes to universe would it not be ok to prevent acpid from installing /etc/mkinitrd. on ubuntu-laptop a guy just asked the same thing it confused him too
<tseng> pitti: no.
<pitti> tseng: if not, you also need CAP_DAC_OVERRIDE
<janimo> to have a dir in etc which is not used in the current setup
<jbailey> janimo: Yeah, it'd have to.
<jbailey> I wonder why it does it.
<tseng> pitti: yeah, that fixes EACCESS..
<tseng> pitti: i might revert this patch locally
<janimo> to support both initrd and initramfs? maybe in debian that makes sense if they can have both I don't know
<janimo> jbailey, should I file a bug?
<jbailey> I don't see how it installs it, it's not in the control file.
<jbailey> Just debconf, lsb-base and module-init-tools
<janimo> dpkg -L acpid shows it right?
<jbailey> I generally use apt-cache to look at dependancy lines
<mvo> does anyone has a idea why linux doesn't seems to free the diskspace for munmaped/unlinked files sometimes (#15603)? it is only freed after the applications exists ...
<jbailey> mvo: REquired by posix
<jbailey> As long as something holds a reference to a file, it has to continue to exist.
<jbailey> Even if the directory entry is gone.
<mvo> jbailey: yeah, I know that. but I don't hold a refrence anymore. I mean, mumaped the file
<mvo> no open fd
<jbailey> Did you close the fd as well after?
<jbailey> (Double check that in /proc
<jbailey> )
<mvo> jbailey: the fd is (should be) closed after the mmap was sucessfull
<Kamion> Diziet: context .rejs> yes, it's incredibly irritating - as a side-effect that means 'baz replay' has the same bug
<Kamion> though 'baz merge' doesn't, so I assume it does the patching itself
<mvo> jbailey: no open fd. but /proc/$pid/maps shows:
<mvo> 2aaaafe63000-2aaaafe64000 rw-s 00c00000 08:01 2004246                    /var/cache/apt/pkgcache.bin (deleted)
<janimo> jbailey, I did not mean dependencies, just that acpid.deb contains a /etc/mkinitrd/scripts/acpid which is not used in the default setup but leads to the creation of /etc/mkinitrd
<janimo> which can be/is confusing
<jbailey> mvo: You sure?  Looking at susv3, I see: The mmap() function shall add an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference shall be removed when there are no more mappings to the file.
<jdub> mjg59: ping
<jbailey> mvo: Can you use ltrace to see if the munmap fall failed for some reason?
<mvo> jbailey: thanks, I'll doublecheck if the munmap is really called/sucessfull
<jbailey> janimo: Hmm.  I can see it being nice to keep that in for this release in case someone needs to use  initrd-tools for some reason.
<jbailey> I'd hope that there's no need for it, but if it's only confusing and not harmful to have it in there...
<mjg59> jdub: Hi
<janimo> jbailey,ok, although it could be moved out into mkinitrd-tools but maybe that's just too much work for little gain
<mjg59> Wow. Slashdot have changed to HTML 4.01
<jdub> mjg59: dccalliance.biz has some serious lack of css love
<Kamion> janimo: wrong place - not all architectures want acpid
<mjg59> jdub: It never had any CSS
<jdub> it used to look like the other site
<jdub> argh, they've ruined the text-only mode
<jdub> oh well, no style works
<mjg59> Yes, then Ian rang me up and asked me to change it
<pitti> mjg59: btw, kudos for hibernation - it works perfectly now (for me at least); ethernet and usb are fixed
<janimo> Kamion, I am not advocating that then, but I became curios: does the apcid being put into /etc/mkinitrd/scripts affect archs which don't have acpi?
<janimo> it's a find |xargs so if no acpi drivers are found no harm is done
<Kamion> janimo: no, because those arches don't have an acpid.deb
<Kamion> so they'll never install it in the first place
<sladen> jbailey: what did you do to initramfs(!)  There's now a 15second delay before it does anything useful
<janimo> Kamion, so they would not be harmed if that mkinitrd/acpid script was installed as part of initrd-tools then?
<janimo> it would be a noop.(Or I am missing something bigtime)
<Diziet> mjh: Asked you to change it ?  Ie, they asked you to get rid of the CSS ?
<Diziet> I mean, mjg59:
<Yagisan> jbailey: Having a problem installing edubuntu in vmware 5
<mjg59> Diziet: There never was any CSS
<Yagisan> jbailey: http://eyagi.bpa.nu/~jamie/edubuntu-vmware.png
<mjg59> It's a really crap website
<Yagisan> jbailey: or  http://eyagi.bpa.nu/~jamie/edubuntu-vmware-nolvm.png
<mjg59> But yes, Ian asked me to change the styling to make it clear that it wasn't the same site
<Yagisan> jbailey: known problem ?
<jbailey> sladen: If you could help find that it would be lovely.  I don't see it here, and you're the second person to mention it.
<jbailey> sladen: Do you have multiple machines?
<jbailey> Yagisan: Try adding 'break' to the kernel command line, do a modprobe BusLogic and then vgchange -ay, tell me if /dev/mapper/Ubuntu* appears
<jbailey> Yagisan: If that works, then yes it's a known problem and the next kernel update is supposed to fix it.
<jdub> mjg59: get my /msg?
<jdub> (gar feenode)
<Kamion> janimo: it's fine the way it is; now is not the time to mess about with stuff for cosmetic reasons
<Robot101> yarr
<Yagisan> jbailey: ah - need to reinstall it first (I blew away the lvm one first :-[)
<jbailey> Yagisan: Either way
<jbailey> If you install BusLogic
<jbailey> and then run udevstart, then your /dev/sda1 should appear
<Diziet> mjh: Why did you agree ?
<mjg59> jdub: Yes. Freenode won't let me reply.
<Kamion> janimo: and in any case I don't generally approve of putting things in the wrong place (i.e. wrong layer) just because they're a bit prettier that way ...
<sladen> jbailey: yes.  let me upgrade another one
<jbailey> sladen: Sure.  or IRC from that one. =)
<Diziet> hoary's firefox is based on 1.0.2.
<Kamion> mozilla-firefox | 1.0.2-0ubuntu5 | hoary/universe | source, amd64, i386, ia64, powerpc
<Kamion> mozilla-firefox | 1.0.6-0ubuntu0.2 | hoary-security | source, amd64, i386, ia64, powerpc, sparc
<Kamion> (incidentally, what the HECK is that doing in hoary/universe? confused)
<daniels> Kamion: firefox vs mozilla-firefox?
<Diziet> Oh, I'm looking in the wrong Packages file.
<Kamion> daniels: no, that was a breezy thing
<Kamion> it's in hoary's Packages anyway so I guess it must have been equal-version-but-different-component-in-different-suites hilarity
<Kamion> I suppose I could promote it back now, but err, so not touching hoary
<Kamion> lamont: ok, indeed poxml isn't needed for the Ubuntu debian-installer-manual build, so I'll drop that build-dependency
<bddebian> Howdy
<janimo> Kamion, fair enough, as I said I no longer asked if it could be moved, was only curious if it would work or not
<bddebian> elmo: ping?
<sladen> jbailey: both of these machines.  1 for 10seconds, 1 for 15seconds.  very disconcerting
<lamont> Kamion: thanks muchly
<lamont> although it's still ftbfs - see the other window
<Yagisan> jbailey: modprobe BusLogic & udevstart didn't make /dev/sda appear :( . I'll try an all ide install tommorrow and see if I can reproduce it.
<sladen> jbailey: why exactly are you loading USB, Ethernet and $foo drivers before init/usplash?
<sladen> jbailey: is this something LTSPy ?
<elvirolo> hi all
<Diziet> Someone said something about katie and new .orig.tar.gz's and security fixes.  That's going to be a problem because the old and new .orig.tar.gz's may have the same md5sum, they have different names.
<bddebian> Hello elvirolo
<sladen> jbailey: there's a several second pause enumerating the IDE devices too
<jbailey> Yagisan: Thanks.
<jbailey> sladen: (Lagging just a sec
<elvirolo> using the breezy default configuration, my FPS is very low (for ex in glxgears) whereas everything used to work fine under hoary (with the same card) is this a known problem?
<ogra> elvirolo, how do you get the FPS in glxgears ? 
<jbailey> sladen: IIRC usplash didn't like being loaded early.  I don't remember the why on that.
<jbailey> But several second pause enumerating ide? =(
<elvirolo> ogra: in stdout
<elvirolo> wait, it's not displaying the FPS anymore...
<ogra> exactly
<Yagisan> good night all
<ogra> night Yagisan 
<elvirolo> anyway, the gears spin a lot slower, and my FPS rate in games (like balazar) is about ten times lower than it used to be
<Kamion> Diziet: err, I don't quite understand "may have the same md5sum, they have different names"
<Diziet> kamion: They _do_ have the same md5sum.  {mozilla-,}firefox_1.0.7.orig.tar.gz.
<elvirolo> how do i know whether DRI is enabled or not ?
<Diziet> (Unfortunately upstream ships only a .bz2, so it's not the same md5sum as theirs.)
<sladen> ogra: which glxgears | strings | grep benchmark | xargs glxgears
<Kamion> Diziet: oh, you mean that the hoary-security one unavoidably has a different name and there's no way to get that in through breezy. Hmm.
<Kamion> I think you need help from James Troup on that
<infinity> That's not an issue.
<Diziet> Yes, exactly.
<infinity> And we've already done it once.
<Diziet> Oh, all right.  I'll just go for it then :-).
<infinity> Upload breezy and hoary with -sa, and warty without -sa
<infinity> Wait for hoary to get in before doing warty.
<Diziet> Willdo.
<sladen> ogra: which glxgears | xargs strings | grep benchmark | xargs glxgears   even
<Diziet> Speaking of warty, does anyone have a handy warty system to test my .deb on ?  It would be nice to check that it at least works a bit before having zillions of people install it.
<Diziet> I could install one but it seems like quite a faff.
<infinity> Diziet : Run it from a warty chroot, that's what I did last time.
<Diziet> Yeah, but I don't have a warty chroot atm.
<infinity> debootstrap works. :)
<infinity> (I'd test for you, but I'm off to bed in about 3 minutes..
<infinity> )
<Diziet> :-).
<daniels> elvirolo: -> #ubuntu, please
<elvirolo> sladen: thanks
<elvirolo> daniels: ok
<Diziet> If I don't get a volunteer, sure I'll do it myself.
<ogra> sladen, i know
<ogra> sladen, it was disabled for a reason
<ogra> sladen, i didnt want to make daniels life worse :)
* Kamion scps 3GB of data over wireless. sigh. must fix the server's wireful card
<daniels> your server has working wireless, but broken ethernet?
<Kamion> yes
<daniels> perverse
<ogra> heh
<Kamion> It works. Most of the time, anyway.
* Diziet makes a warty iso.  jigdo++
<ogra> doko !
<doko> hi ogra
<ogra> how is oldenburg ?
* \sh thinks, doko as fun drinking nordic beer with Martin and LaMont ;9
<lamont> doko is here???
<ogra> nordic beer ? in oldenburg ? 
<lamont> woot
<\sh> jever
<ogra> heh
<\sh> whatever u drink in oldenburg
<ogra> north german beer :)
<\sh> ogra: everything north of cologne is nordic ,-)
<\sh> you know the song:" Nordisch By Nature" 
<ogra> yes, and everything south of frankfurt is bayern
<\sh> hehehe...exactly
<siretart> lol
<\sh> and the german capital is bavaria ,-)
<ogra> \sh, ts my personal hymn sice i live in the middle of germany :)
<siretart> fraconia rules ;)
<dholbach> guys, come to berlin and talk again :)
* ogra is a true lower saxony child
<siretart> ETOOMANYGERMANS *g*
<ogra> hehe
<\sh> ogra: when I was in stuttgart, every "schwabe" told me, that I'm a "Muschelschubser und Fischkopp" but this is absolutely OT 
<ogra> yes, we own the channel phear us !
<Kamion> Diziet: wow, the warty jigdos still work. go me.
* dholbach wears the GO! Kamion! T-Shirt
<Kamion> ooookaaaaay
<ogra> dholbach, above or below the "mdz groupie" shirt ? 
<ogra> ;)
<dholbach> i switch according to the timezones
<ogra> hehe
<Diziet> kamion: My mirror seems to be missing the udebs, but luckily they're quite few.
* \sh looks out for the "Kick \sh" Shirt
<ogra> dholbach, can you bring me such a Kamion shirt to UBZ please
<dholbach> sure thing
<ogra> :)
<Diziet> Hmm.  Is it worth the faff to save using my uplink here for 2x2ks to upload that firefox .orig.tar.gz twice ?
<Diziet> Probably not.
<Kamion> Diziet: they're referred to by a separate Packages file, if that makes any difference to you
<Kamion> lamont: um, help. What happened to royal's recent livefs build? The log looks fine, but there are no images.
<Kamion> log> apart from a few "Failed to open terminal" messages somewhere in the middle
<Diziet> kamion: Perhaps that means they're left out of the (apparently badly synthesised) md5sums.
<Kamion> ah, could be
<ogra> Kamion, hmm, looks like the netfg error in the installer is still there ...
<ogra> (sorry for not noticing earlier, i just dicovered in my current install)
<\sh> hmm...
<zyga> this place is too silent...
<ogra> creative silence ;)
<bddebian> zyga: :)
<zyga> creative noise about silence
<zyga> I wonder if managers who spy on their workers prefer creative silence or mystical noise that they don't understand 
<tseng> my connection goes over ssh
<\sh> I'm surprised, what u can find out when u surf over all blog sites of debian and ubuntu people
<tseng> so i hope they refer AES
<tseng> +p
<\sh> really amazing...
<zyga> \sh: what did you find?
<zyga> \sh: I've just discovered a whole network of polish ubuntu people
<zyga> (I do feel lonely, nationality-wise, here)
* \sh too...I  need to start my pbuilder that I'm not alone anymore
<\sh> ;)
<zyga> sh any pbuilder tutorial you can offer?
<ogra> zyga, look at the wiki
<siretart> zyga: the ubuntu wiki is quite nice, imo
<siretart> the one in the ubuntu wiki
<zyga> checking
<zyga> ah :)
<zyga> step by step :-)
<bddebian> Heya pitti
<zyga> pitti: hey :)
<pitti> Hi
<pitti> Hi zyga 
<bddebian> pitti: rhdb-admin is b0rked even with the libpgtcl :(
<bddebian> pitti: Oh and btw, are you the mozilla master?
<mdz> ogra: what's this about mdetect?
<ogra> mdz, apparently it isnt used by xorg anymore
<pitti> Hi mdz
* dholbach recalls reading an xorg changelog entry about that too
<pitti> bddebian: no, I refuse to be :-)
<ogra> i didnt think about ltsp in ubuntu when i added it to the edubuntu-server seed
<mdz> apparently not
<pitti> bddebian: well, I will update mozilla to 1.7.12 tomorrow
<ogra> mdz, so it can go from ltsp-build-client it seems
<mdz> ogra: why did you add it to the edubuntu server seed?
<mdz> ogra: it can, but it's harmless there and I'm going to leave it for breezy unless there's a reason to change it
<ogra> because ltsp-buildclient didnt work without it
<bddebian> pitti: Well I was curious because I wonder if all the mozilla-locale-* on UnmetDeps should be morgued?
<mdz> dholbach: did you receive my mail about gthumb?
<Keybuk> didn't mdetect used to detect mice, and we decided that "/dev/input/mice" was the right thing
<dholbach> mdz: yes, i did
<Keybuk> though how do we detect synaptics pads?
<mdz> ok
<ogra> mdz, then we need toadd it to ship in ubuntu too...
<dholbach> mdz: but i didn't reply yet - will do
<mdz> ogra: hasn't it been in ship since warty?
<ogra> mdz, it seems KAmion removed it when it wasnt needed anymore
<pitti> bddebian: oh, are they out of sync again?
<ogra> and i only added it to edubuntu
<pitti> bddebian: we actually want to drop mozilla support in Breezy
<Kamion> no we don't need to add it to ship in Ubuntu
<zyga> hmm will breezy get the new icon theme?
<bddebian> pitti: Yeah they are built for 1.6.something
<zyga> I've just stumbled upon it
<zyga> it's quite nice
<bddebian> pitti: That's what I thought
<pitti> bddebian: oh, we should have more current ones
<ogra> Kamion, ah, yes, it was pulled in as dependency...
<pitti> bddebian: for the more current ones (1.7.x) it is enough to loose the dependencies to make them installable
<mdz> Kamion: the CD should contain everything ltsp-build-client needs
<mdz> but if it's already gone I suppose I need to  unbreak ltsp-build-client
<Kamion> ogra: no, it shouldn't be on the breezy CDs at all
<pitti> bddebian: but it takes some time to do that (easy, though)
<Kamion> mdz: it's been gone for ages; I would like to fight for every scrap of space I can
<bddebian> pitti: I'll do it but I won't know if they "work", but they will build ;-)
<dholbach> i need do some last-minute-shopping - brb
<Kamion> though I realise it's small
<pitti> bddebian: just relax the version constraint in the mozilla dependency
<pitti> bddebian: the 1.6.x ones should be kicked
<ogra> changing it in ltsp-build-client is trivial
<Kamion> the change is well over a month old though
<pitti> bddebian: or synced from Debian if sid has a recent version
<mdz> Kamion: then we should revisit emacs and thunderbird
<mdz> which in my opinion are entirely out of scope for ship
<bddebian> pitti: No newer versions in Debian :-(
<mdz> that is a seriously non-trivial amount of space
<Kamion> mdz: happy to, but I thought I'd lost the thunderbird argument
<ogra> mdz, ubuntu already has mayn thiderbird users, you'll piss them off...
<pitti> Diziet: 1.0.7-0ubuntu15 -  thanks! any particular reason against -0ubuntu1?
<mdz> mdetect is 16 _k_
<ogra> *many thunderbird
<mdz> ogra: it would if we removed it from main, ure
<mdz> sure
<mdz> but I suggest we move it from ship to supported and keep it in main
<mdz> along with emacs
* ogra is happy that he doesnt need to think about such things for edubuntu... its dropped there since the beginning
<bddebian> pitti: Sorry, you say that the 1.6 ones should be dropped from the archive or just update the dep version to the newer Mozilla?
<pitti> bddebian: the 1.7.x should be dependency-updated to make them installable with any 1.7.x; 1.6.x should either be updated to 1.7.x (with debian syncs, possibly) or kicked
<mdz> pitti: 1.0.7 of what?
<bddebian> kicked == dropped?
<pitti> mdz: firefox
<mdz> pitti: surely you're joking
<pitti> bddebian: yes
<pitti> mdz: hm?
<mdz> pitti: for breezy?
<pitti> mdz: yes, just read it on b-changes
<mdz> who approved it?
<mdz> Kamion?
<pitti> well, we are discussing this since weeks...
<Kamion> no, I assumed it was already approved since nobody asked
<mdz> discussion is one thing and upload is another.  we are in a freeze.
<Kamion> but I wasn't paying attention due to colony release bits
<pitti> mdz: uh, sorry
* jdub pulls out the dry ice.
<mdz> Diziet: ping
<pitti> mdz: I thought we agreed to doing new upstream versions for mozilla foo?
* jdub sprays liberally.
<mdz> pitti: there is only one standing exception for upstreamversionfreeze, and that is GNOME
<Kamion> however the prevailing opinion seemed to be that it was too hard to extract the relevant patches, so I'm not sure what else I could've said had people asked
<mdz> Kamion: you could've referred them to me
<Kamion> mdz: well, I would have done
<mdz> ok :-)
<Kamion> I don't take decisions about firefox :-)
<Keybuk> "firefox, scary, run away!"
<mdz> mjg59: how big is this slmodem stuff, in terms of CD space?
<Kamion> but, sorry, should've been paying attention earlier. I assumed that since there was apparently a standing exception for new upstream versions of firefox in *stable releases*, that it must be OK for breezy
* pitti assumed the same
* Nafallo joins in on this assumption
* ogra was wrong too often with hos assumptions to join here 
<mdz> that would be a fairly reasonable assumption
<ogra> *his
<mdz> if in fact there were such a standing exception
<Kamion> aha
<jdub> and if that were its real name
<mdz> I only recall taking a decision on 1.0.6
<Kamion> hmm. recriminations aside, what now?
<mdz> now we wait and see and hope it isn't a fuckup
<mdz> and if it is, we back it out like in Warty
<pitti> mdz: so in terms of fixing stables, I start to backport tomorrow?
<Kamion> well, Colony 5 is waiting on today's kernel upload, which is pending RSN
<mdz> pitti: I didn't realize you were expecting to push every new firefox release into -security.  is it already impossible to patch 1.0.6?
<pitti> mdz: depends on how much we want to do
<mdz> Kamion: and will take hours to build
<pitti> mdz: I already patched the hyphen vuln some time ago
<mdz> we ought to do kernel uploads on wednesdays
<Kamion> so there's time for firefox 1.0.7 to build and be in the install CD side of that at least, which means it should get good visibility
<pitti> mdz: the other vuln (shell injection) isn't hard to patch, either
<Kamion> mdz: I don't expect to get an early night tonight
<mdz> pitti: but you were going to push 1.0.7 implicitly anyway?
<pitti> mdz: but 1.0.7 contains a whole bunch of undocumented patches to "fix regressions in 1.0.7 and add stability patches", and it's next to impossible to backport them
<pitti> mdz: well, I had started to build 1.0.7 for warty and hoary and test it for a day, yes
<mdz> we don't generally backport random bugfixes
<pitti> mdz: right, but they fixed regressions introduced in other security patches
<Kamion> as Diziet observed, it's hard to tell what crasher bugs fixed in 1.0.7 could also be security bugs
<pitti> that's why I would have liked to test them first before starting to backport
<mdz> Diziet's observations aside, he needs to follow the release guidelines like everyone else
<Kamion> so that would require some analysis
<pitti> but backporting the one outstanding vuln is fine, too
<Kamion> mdz: I'm talking more about what should be done now than about what should have been done earlier
<pitti> mdz: sorry, then I had a totally wrong assumption; /me erases the exception from his mind
<mdz> pitti: it's certainly possible if you feel that it's the best approach, but it does require discussion and approval
<Diziet> Wooah, scrool.
<mdz> on a case-by-case basis
<pitti> mdz: ok, noted
* Kamion goes for dinner
<Kamion> I'll upload debian-installer and leave it to dep-wait on the new kernels
<Diziet> mdz: Are you suggesting that we ought to try to read the diff between 1.0.6 and 1.0.7 to try to decide (a) which changes fix security problems and (b) whether we think the change is correct ?
<pitti> Diziet: no, this way madness lies, unless you truly understand the code
<Diziet> Because I don't think that we can find a sensible and comprehensive list of what security fixes are included and we also will probably not find out if any new bugs in 1.0.6 get discovered later.
<pitti> Diziet: if we backport, then only the critical security patches, which are documented in the changelog
<Diziet> mdz: Of course if there's some release rule that I'm breaking then that's bad and we should talk about it.
<mdz> Diziet: as regards the security update, there's a discussion to be held about it
<Diziet> But I thought Kamion was entitled to authorise updates ?
<mdz> Diziet: as regards the breezy upload, yes, that broke a rule
<Kamion> Diziet: I am generally, but was not aware that this needed authorisation
<mdz> Diziet: https://wiki.ubuntu.com/BreezyReleaseSchedule
<Kamion> 14:30 < Diziet> pitti: Yes, I'll update firefox.  I assume this is cause for an exception ot UVF ?
<Kamion> 14:31 < pitti> Diziet: yes, we have a general exception for that even for stable releases (if we test everythign properly, etc.)
<Kamion> the certainty in pitti's statement led me to assume it had already been approved
<pitti> Diziet: right, I just learned that this rule was not as general as I remembered
<Diziet> kamion: Quite so.  I'm not sure I make a distinction between `person who is authorised to make exception to rule makes exception' and `that person thinks rule does not apply or has standing exception'.
<Kamion> since pitti's not normally in the habit of breaking UVF without checking first
<Diziet> But I'm sorry for any misunderstanding.
<pitti> not for non-mozilla stuff, right
<Diziet> So let's talk about both breezy and the security update.
<Kamion> Diziet: (I think you were acting in good faith)
<Kamion> anyway, got to go
<Diziet> OK, TTFN.
<Diziet> mdz: So, then, obviously my current opinion is that we should take the new upstream into warty, hoary and breezy.
<pitti> at least we have an option this time, unlike the 0.9.3->1.0.6 upgrade, where we were basically forced to do the jump
<mdz> Diziet: yes, Kamion has explained how the misunderstanding happened
<Diziet> Oh, good.
<Diziet> So let's get on to the meat of the question.
<infinity> mdz : Is cron.daily failing and/or running eternally?
<mdz> infinity: dunno
<infinity> mdz : I'm waiting on uploads of 1/2 hours old, respectively, to show up in wanna-build.
<pitti> Diziet, mdz: my proposal: we backport the patch for the single major vuln now for stables, and if more things arise, we can still update stables to 1.0.7; at that time we have better testing of 1.0.7 in breezy
<Diziet> What makes you think there's only this `single major' vuln ?
<mdz> Diziet: because Mozilla has finally acknowledged that they need to tell the community about vulnerabilities
<mdz> pitti: you're on their new list now,  right?
<pitti> mdz: yes, on mozilla-security@ or sth similar
<mdz> pitti: security-announce
<mdz> which is different from security-group, which you may be on
<pitti> mdz: I asked them to grant me access to embargoed bugs, and I have now
<pitti> security-announce@mozilla.org, right
<Diziet> The website is rather short of detail.  You have more information than is in the 1.0.7 release notes ?
<Robot101> and we thought Theo was bad :P
<mdz> pitti: ok, good
<pitti> Diziet: there are not even MFSAs for the things fixed in 1.0.7, let alone bug xrefs
<mdz> rather than using the existing lists shared by all open source projects for this purpose, they decided to create another list of their own
<pitti> (yet)
<Diziet> So do you have a list of the things fixed ?
<mdz> but at least they are going to make announcements
<mdz> pitti: if you don't have a list, please ask the security group for one
<pitti> mdz: I have a list
<mdz> they don't always understand that vendors need this kind of information
<Diziet> And, for all the things on their list, how can you tell whether they're vulnerabilities ?
<pitti> moment, please
<Diziet> Can you show me this list or is that forbidden ?
<Diziet> -anarres:upstream> grep -v '^Only' 1.0.6-1.0.7.diff | wc -l
<Diziet> 2973
<Diziet> I'm reading that diff now.
<Diziet> Looking at it I'm pretty sure it has fixes for other vulns in it but my knowledge of the code is not sufficient to decide for certain for each included patch.
<infinity> mdz : Meh, cron.daily definitely seems confused... A bunch of binaries uploaded by the buildds have never hit "installed" either.
<Diziet> I applied it to warty and hoary and it applies cleanly apart from the fact that it includes our existing security fix.
<Diziet> Which strongly suggests it's full of fixes that we need.
<Diziet> I'm also fairly convinced that some evil person reading the same diff will see it as a rich mine of possibilities.
<pitti> Diziet: http://people.ubuntu.com/~pitti/MFSA2005-57.html
<pitti> Diziet: this is the one we have already fixed
<mdz> infinity: wanna-build is running right now
<pitti> Diziet: http://people.ubuntu.com/~pitti/MFSA2005-58.html
<pitti> Diziet: these are the other issues
<infinity> mdz : As in "just started again", or "is still running"?
<mdz> infinity: started at :10
<pitti> Diziet: this does not include the shell injection, though, which is also fixed in 1.0.7
<infinity> mdz : Hrm.  Curious.  Did you have to nudge it?
<infinity> mdz : Cause it's very obviously not run (well, not COMPLETED) for hours.
<Diziet> pitti: Right, the IDN fix is the one that I saw we'd already applied.
<pitti> Diziet: I'm fairly sure that we want the other fixes in 58 as well
<Diziet> pitt: Um, isn't that secret ?
<Diziet> I mean your draft MFSA.
<pitti> Diziet: what for, 1.0.7 is out
<Diziet> I see.
<mdz> infinity: there's a traceback in the cron.daily output
<pitti> and everybody can access their cvs
<Diziet> OK, up to them what their rules are I suppose.
<infinity> mdz : Huzzah.
<infinity> mdz : Time to page elmo, I guess.
<pitti> Diziet: they might embargo the single patches in some bugs
<Diziet> Yes, right, lots of those things look like the same kind of things as are in that diff.
<pitti> Diziet: https://bugzilla.mozilla.org/show_bug.cgi?id=300936 - see? 
<Diziet> Is this a supposedly complete list of changes between 1.0.6 and 1.0.7 ?
<mdz> infinity: but it seems to have completed successfully anyway
<mdz> looks like it choked on one upload but processed the rest
<Diziet> Access Denied
<infinity> mdz : Nope, it didn't.
<Diziet> You are not authorized to access bug #300936.
<pitti> Diziet: right, I'm not either
<infinity> mdz : Several source uploads haven't been processed, and several binary uploads.
<jdub> elmo: ping
<pitti> Diziet: apparently they only gave me access to the 1.0.6 issues
<Diziet> I'm not sure what you're demonstrating but obviously if you think it's OK to publish it then fine, I'll just take your word for that.  I don't know about their processes.
<mdz> infinity: it claims to have processed the d-i source upload
<mdz> and isdnutils
<mdz> in the last run
<Diziet> So do we know if this is a complete list of changes in 1.0.7 ?
<infinity> mdz : Interesting. Does it claim anything about l-r-m in previous runs? :)
<pitti> Diziet: should be, but they did not state that
<pitti> Diziet: they sent a long a 30K tar.gz with all patches, which is just the cvs diff between 1.0.6 and 1.0.7
<Diziet> Yes, well, I can make that for myself, can't I ?
<pitti> Diziet: right
<Diziet> What are we supposed to do, read it ?
<pitti> Diziet: I remove the HTML again, in case they object to it
<pitti> Diziet: we are supposed to upgrade to 1.0.7, according to them
<infinity> mdz : l-r-m, nvidia-settings (source) are definitely not processed, a random ancient binary upload I looked at (lm-sensors) was also stuck (unless it's in NEW..)
<mdz> infinity: just an hppa l-r-m binary upload in NEW
<mdz> l-r-m is stuck in accepted
<Diziet> pitti: Yes, but it would be nice to be able to decide that for themselves.  What is this, Micro$haft or Free Software ?  They should provide us with the support to help us make that decision.
<Diziet> s/for them/for our/
<infinity> mdz : Right.  That's about what I thought.
<mdz> infinity: it's an elmo situation
<pitti> Diziet: many folks asked them for a very long time, and they won't help us to backport
<pitti> Diziet: we can get the patches they applied, but that will only help us for e. g. 1.0.6->1.0.7
<pitti> Diziet: we totally failed to apply 1#0.5 patches to 1.0.2
<infinity> mdz : Can you page him for me?  I'm off to bed, so don't really want to stay up explaning the breakage when he comes and asks. :)
<pitti> Diziet: and even more so to 0.9.3
<Diziet> There is at least one lot of fixes in that code that look security-related but don't look like one of the ones in that MFSA.
<pitti> Diziet: right, there is the shell injection fix which was not mentioned in the mfsa
<Keybuk> mjg59: about? :p
<infinity> mdz : He's requested to be paged about stuff like this, though (and it's not exactly an oddball, middle-of-the-night time, so I don't feel too guilty)
<mdz> pitti: but 1.0.6 is what we have in both warty and hoary now, right?
<Diziet> There's no point us simply mechanically applying the 1.0.6->1.0.7 patches individually.
<pitti> Diziet: this one is crucial
<pitti> mdz: right
<Diziet> The only reason to do that would be if we thought we might want to leave some of them out.
<pitti> Diziet: only if you choose only some of them
<Diziet> Right.
<Diziet> But if the only way to do that is to read the diffs I might as well read the whole damn diff.
<pitti> Diziet: you can also go though the bug reports, once they become public
<pitti> but that will last for 14 days
<pitti> and we don't want to leave open critical holes like the ones fixed open for so long (again)
<mdz> infinity: yeah, done
<Diziet> I've nearly finished reading this diff now.
<Diziet> There's a change to the startup script.  Do you know what that is ?
<pitti> Diziet: no, at this time I know less than you about the code
<Diziet> Right.  It looks like a fix for shell quoting problems.
<pitti> Diziet: at least it looks like that they did not add new features this time
<pitti> Diziet: https://bugzilla.mozilla.org/attachment.cgi?id=195796 <- this is the quoting patch
<Diziet> pitti: Yep.
<Diziet> Shame there's four copies of that damn script.  Oh well.
<Diziet> OK, I've reviewed the whole diff.
<mdz> pitti: you added openoffice.org-debian-files to the main inclusion wiki page, but it seems to already be in breezy/main
<Diziet> mdz: I've looked at the 1.0.6 to 1.0.7 diff and:
<pitti> Diziet: any new features?
<pitti> mdz: oh, doko asked me to ack it again, but it's a no-ob anyway (it was in hoary)
<pitti> mdz: we apparently need it for smooth upgrades to breezy
<Diziet> I wasn't able to convince myself that all of the changes were correct.  But they all look like security changes and nothing seemed wrong.
<mdz> pitti: there's nothing to ack if it's already in main :-)
<mdz> Diziet: good, thanks for reviewing it
<Diziet> wasn't able to convince> Because of lack of context.
<pitti> mdz: so much the better :-)
<Diziet> I could go and check but that would take quite a bit longer because I'd have to actually understand each bit of code properly.
<Diziet> Certainly nothing resembling a new feature and the biggest changes are the ones which correspond clearly to the descriptions of security fixes in the MFSA.
<Diziet> So on that basis I'm now completely convinced that we should move to 1.0.7 immediately for all releases.
<mdz> Diziet: we don't need to convince ourselves that everything is correct, but that they're meeting our expectation of conservativeness
<Diziet> Right.  We'll, I'm certainly convinced of that.
<mdz> Diziet: because in the past, they have not
<Diziet> I see.
<Diziet> Well they've done what looks like a reasonable job here.
<pitti> Diziet: good, it seems they finally reacted to the complaints about new features in earlier 1.0.x
<Diziet> (It's a shame that there's no coherent and complete list of the changes.  That's the only thing they could have done better.)
<pitti> Diziet: I assume they will publish the MFSAs soon
<pitti> Diziet: these usually contain xrefs to bugs
<Diziet> mdz: So what else do you need to approve it into {warty,hoary}-security and breezy ?
<mdz> Diziet: the reason we're so paranoid about new upstreams is that they are unpredictable
<mdz> most of them are undisciplined when it comes to releases
<pitti> Diziet: the problem at 1.0.2 -> 1.0.5 was that these patches in the bugs caused regressions, and they did not document the patches that fixed these regressions
<mdz> they'll break compatibility, introduce disruptive new features, etc. and call it a bugfix point release
<pitti> Diziet: I applied all the patches manually, wiggled them into the older source and got something totally unstable
<Diziet> mdz: Right.
<mdz> Diziet: it's a bit late for breezy as the source is already in the archive, but for warty and hoary it should get the usual battery of testing from pitti, which I understand he's already started on
<pitti> mdz: I plan to do it tomorrow, I fixed langpacks today
<mdz> pitti: !
<mdz> pitti: fixed as in ready for upload?
<Diziet> Damn, my test build of the warty version has failed too.  And I've got too few machines.
<pitti> mdz: my statement above was in the conjunctive
<pitti> mdz: well, I examined the new tarball
<Diziet> pitti: You've got some testing to do ?
<Diziet> In which case, where should I send my .dsc and .diff.gz ?
<pitti> mdz: it looks almost good; it is just out of date (will be fixed soon) and introduces regressisons (macros in strings are not validated)
<Diziet> They're ready except I haven't been able to do a test build and install yet.
<mdz> pitti: so not ready, then
<pitti> mdz: no, by fixing I meant preparing langpack-o-matic for the import and add workarounds for some Rosetta bugs
<mdz> pitti: oh, fixed langpack-o-matic rather than fixed langpacks ;-)
<pitti> mdz: yes, sorry
<mdz> pitti: speaking of which, you need to train someone else on langpack-o-matic
<pitti> mdz: I just thought about that today
<pitti> mdz: once Rosetta export actually works, I'd like to show the mechanics to somebody
<pitti> mdz: right now it's  much manual hacking when we create the archives ourselves
<pitti> mdz: at UBZ would be a good opportunity
<Keybuk> I smell a BOF ;)
<mdz> pitti: it's on my list for UBZ
<mdz> already
<pitti> that would be nice
<pitti> physical contact is better for training
<pitti> mdz: since mozilla and tbird have the same fixes, I assume the same arguments apply to them?
<Diziet> pitti:  My packages are at  http://www.chiark.greenend.org.uk/~ian/d/
<mdz> pitti: yes
<mdz> argh, this #ubuntu-unregged thing is very irritating
<Diziet> (the hoary version is just arriving now)
<pitti> Diziet: I meant that last time I actualyl used the new hoary and warty packages for a day before I released them
<Diziet> Oh, right.
<pitti> Diziet: I can test tbird and moz, can you test ffox?
<Keybuk> ubuntu-unregged?
<Diziet> I thought mdz meant you had some kind of testing arrangements.
<pitti> Diziet: oh, good that you show them to me - we need to fix this version number mess
<pitti> Diziet: no, just plain dpkg -i and using it :-)
<pitti> Diziet: for moz and tbird we did the right thing and named them 0ubuntu0.4.10 and 0ubuntu0.5.4
<Diziet> Version number mess ?
<pitti> 0.5.04 even
<Diziet> Does it matter ?
<pitti> Diziet: 0.0.1 vs 0.1 and so on
<Diziet> That's somewhat nicer, true.
<pitti> Diziet: it doesn't really matter, but we should aim for consistency
<pitti> Diziet: we found this solution after we updated ffox already
<Diziet> OK.  Well we'll do that next time.  I don't want to faff with repackaging these huge files now.
<pitti> Diziet: oh, it's just a change in the changelog and debuild -S -sa?
<Diziet> pitti: Yes, but it's quite slow on ffox.  Maybe my machine is too slow but I don't want to add faff to a security update.  Faff = delay (while we sort it out) and risk (we are more likely to make some stupid mistake).
<pitti> Diziet: ok
<Diziet> Looks like I won't get this done today at this rate.  I have to stop soon or I won't get any dinner.
<pitti> Diziet: ok, so can you run both versions for half a day to check them?
<Diziet> Well, I can give them a brief test.
<pitti> Diziet: running them in an actual warty and hoary dchroot is necessary
<Diziet> But I can't `use' them like I normally do my browser and if I could it wouldn't be a good test because I'm _so_ weird about how a browser has to behave.
<pitti> Diziet: last time I had trouble with language packs, but I think I fixed them once and for all
<Diziet> pitti: I have a warty install here and I'm going to have a hoary one soon too.
<pitti> Diziet: I run them in dchroots, works fine
<Diziet> Yeah, but what are testbed machines for ? :-)
<pitti> sure, if you have some, even better :-)
<Diziet> I don't like giving the chroot my X display :-).
<pitti> Diziet: no need to release them today, one day of proper testing should be done
<Diziet> Is there an easy way for me to get the build infrastructure to produce .debs for people to test ?
<pitti> Diziet: just build them?
<pitti> Diziet: alternatively you can upload them, and I toss you the debs from the buildds
<Diziet> IWBNI I could generate them in the colo.  Saves on uploading and also my warty install isn't quite ready yet.  I didn't know until just now I'd need it.
<pitti> Diziet: however, if something goes wrong, that requires a reupload
<Diziet> What, if I upload these to warty-security, the buildds will build them but they won't get published ?
<pitti> Diziet: right
<Diziet> That would be just right.
<pitti> Diziet: they will land in my approval queue
<Diziet> And mdz isn't going to object to doing it like that ? :-)
<pitti> Diziet: alternatively you can do one test build on concordia
<pitti> Diziet: oh, as long as I don't release the files, we can always supersede or remove them 
<Diziet> No, I'm pretty confident of these.  I don't think a reupload will be needed unless I patched a wrong patch in the wrong direction or something.
<pitti> Diziet: but you should do at least one successful build
<Diziet> OK.
<pitti> Diziet: concordia's hoary dchroot has the b-deps
<Diziet> I've built it on breezy.  My warty system is currently slurping security updates ...
<pitti> ok
<pitti> Diziet: well, as I said, I will make the debs accessible for you for testing once they built
<Diziet> Right.  OK, I'll set the upload going now then and pick up the .debs in the morning.
<jcohen85> jbailey: hey, is the new version of a inframfs-tools up yet?
<jcohen85> jbailey: Matt Zimmerman says the pause is probably caused by a SCSI controller. I don't think my motherboard has a SCSI controller. 
<Diziet> pitti: the hoary one is on its way; warty will follow after a few kiloseconds.  Have fun, and see you tomorrow.
<ogra> but if you have one he is right... my controller probes drives about 30sec before the booting goes on...
<pitti> Diziet: thanks, enjoy the evening
<ogra> night Diziet 
<Diziet> Goodnight ...
<\sh> elmo: please sync clamav 0.87 from unstable (universe that is), thx
<jbailey> jcohen85: Not yet, just a sec.
<\sh> eeks..https://bugzilla.mozilla.org/show_bug.cgi?id=307185 
<\sh> thunderbird update will come tomorrow? ,-)
<jbailey> jcohen85: What this will do is add a debug option, which will drop a debug feil in your /dev
<pitti> yes, yes
<jbailey> jcohen85: Hopefully we can then see what's happening.
<\sh> pitti: but it's a surprise, that only the linux version is vulnerable strange..
<pitti> \sh: no shell interpolation in Windows
<zyga> \sh: windows had it's share of shell vounurability half a year ago
<\sh> pitti: what about cygwin usage? if you say that the default commandline shell is bash?
<\sh> no 
<ogra> \sh, that will surely affect the masses :)
<Treenaks> ogra: cynic
<ogra> :)
<Treenaks> ogra: ;)
<\sh> ogra: aehm...cygwin is my first thing I install on any windows workstation...ok..I'm not the mass ,-)
<ogra> depends how you define mass...
* ogra looks at his grown belly he brought from sydney
<bddebian> heh
* Treenaks ph33rz UBZ now
<\sh> ogra: EENOTAN00B "See also bug 309551, same bug on Windows (with Cygwin)."
<\sh> Treenaks: I have to run'n'hide now, but think of Thomas Anders from Modern Talking with a nice, well feed, belly *run*
<Treenaks> \sh: who?
<\sh> s/feed/fed/
<Treenaks> \sh: that must be before my time
<\sh> Treenaks: ---> ogra
<ogra> grmpf
<ogra> ;)
<Treenaks> \sh: generation gap etc.
<\sh> Treenaks: http://www.fortunecity.com/lavendar/brazil/108/musikk/moderntalking/moderntalking.jpg -> the right one is thomas anders
<ogra> \sh, i dont wear a nora sign
<\sh> OT
<\sh> ogra: hmm..."suse" is a better sign for you ;)
<ogra> heh
<jdub> *cough*very*quietly*not*announced* http://fridge.ubuntu.com/
<\sh> THEFRIDGE?
<\sh> wooow
<ogra> FRIDGE !
<pitti> jdub: \o/
<\sh> JDUB ROCKS DA HOUSE
<Riddell> where is fridge?
<ogra> yeah 73% pro cool codenames :)
<Riddell> ah, I see
<\sh> maswan / Mithrandir: could one of you please install apt-get build-dep gcc-2.95 in ravel breezy chroot, thx :)
<slomo> \sh: will probably fail because of cpp-2.95 build-dependency... better search the packages really needed by hand ;)
<\sh> slomo: ok
<\sh> maswan / Mithrandir: could one of you please install apt-get install dejagnu gperf  bison-1.35 flex-old texinfo libgc-dev libgmp3-dev help2man in ravel breezy chroot, thx :)
<\sh> slomo: u right..I just changed the control file 
<\sh> jdub: the fonts are too big
<jdub> \sh: in general, i prefer to leave that to your browser instead of trying to force some independently informed measurement of the world on you :)
<ogra> for me the fonst look ok
<ogra> *fonts
<jdub> you must have your browser set so that all the other ubuntu sites don't look like poo with their tiny fonts ;)
<slomo> for me, too
<ogra> heh
<jdub> well "awesome" is definitely winning
<\sh> jdub: i make a screenshot...then you know what i mean ;)
<jdub> :)
<jdub> thanks
<Nafallo> jdub: how public will you want the fridge atm? topic on #ubuntu.se? :-)
<jdub> word of mouth is fine :)
<jdub> i'm just not going to make a big announcement yet
<Nafallo> oki :-)
<\sh> http://linux.blogweb.de/uploads/screenshot-20050922.png <- 14.1" hp nc6000 display, standard started firefox on ubuntu desktop
<Nafallo> topic that is :-P
<jdub> \sh: mm, so your browser default font size is pretty big
<jdub> morning edd
<\sh> jdub: this is what was installed...and it is like this from hoary times ;)
<edd> jdub: :-)
<ogra> it looks the same here, but i dont find it to big
<\sh> jdub: and when I decrease the font size, than I can't read the left part anymore..but then the middle part is ok
<jdub> oh, bizaare
<\sh> jdub: and believe me I'm blind without my glasses
<jdub> those sizes seem to be pretty comparable on my machine
<jdub> yours are obviously quite different
<jdub> strange
<edd> so, don't know if you care, but neither the .debs for skype nor opera will install on breezy, due to libqt3c102-mt version deps
<\sh> jdub: w8...I'll make another screenshot with smaller fontsizes
<Nafallo> edd: and neither on etch I would guess ;-)
<edd> Nafallo: i guess so, but fear heading into another of those 2 year holes where vendors, if they shipped debs at all, built them against ancient stable releases
<edd> i guess i should complain to skype and opera.
<Nafallo> indeed. we can't do anything AFAIK :-)
<Nafallo> or :-(, rather
<edd> No, except listen to every complaint, alas.
<\sh> jdub: http://linux.blogweb.de/uploads/screenshot-20050922-2.png <- this is smallest size before it's really unreadable anymore...and even this is on the left side too small
<\sh> edd: skype is skype..this is an issue to raise towards skype..:( 
<edd> \sh: sure
<jdub> edd: don't worry too much about that 2 year hole
<Nafallo> \sh: what are the odd icons you got there? the wolf and the hanglock.
<jdub> edd: we're very close to bliss in that regard :-)
<jdub> \sh: hmm
<jdub> \sh: thanks
<edd> jdub: awesome. you always make me happy
<edd> jdub: i actually can't say enough how damn happy ubuntu makes me.
<\sh> Nafallo: what?
<jdub> ok, now tell all those oscon osx lubbers :-)
<\sh> what icons?
<edd> jdub: dude, i do. i do.
<edd> jdub: maybe they'll be less scared now there's usplash
<jdub> oh man
<jdub> new spam with list-id headers
<dholbach> :-)
<jdub> bastards
<jdub> dholbach: dude!
<jdub> dholbach: did you see?
<Nafallo> \sh: on the screenshoot, 
<ogra> dholbach, FRIDGE !
<dholbach> MAN
<dholbach> SURE! :)
<ogra> :)
<\sh> Nafallo: hmm...you mean the typewriter? ask jdub ;)
<ogra> \sh, he means your panel
<ogra> the lightbulb with t-shirt ect
<jdub> do you guys have photos of fridges?
<Nafallo> \sh: no, on your panel :-)
<ogra> *etc
<\sh> Nafallo: ah...thats amarok 1.3.x ,-)
<\sh> and kgpg
<\sh> and the rest is gnome ;)
<Nafallo> \sh: baah. kde in gnome? :-P
<Nafallo> so utterly crackfull ;-)
<\sh> Nafallo: and vice versa...I'm a pimp ,-)
<ogra> jdub, not yet... but i'll put some up soon ... where is yours ? 
<jdub> it is not crackful to run amarok on gnome :-)
<jdub> ogra: i posted *the* fridge ;)
<Nafallo> jdub: depends on who you ask, my definition is about qt-deps :-P
<ogra> jdub, but not *your* fridge :)
<jcohen85> jbailey: when will the new package be ready with the debug option? btw, do most mobos have a scsci controller? i thought mine just had IDE and SATA
<jdub> ogra: do you have a png of the edubuntu logo?
<Riddell> which reminds me amarok 1.3.2 for testing http://kubuntu.org/~jr/amarok/
<jdub> Riddell: do you have a png of the kubuntu logo?
<jdub> oh, just the device
<jdub> not the text
<Riddell> jdub: KubuntuArtwork
<ogra> jdub, isnt that on the ubuntu frontpage  ?
<jdub> i don't think it's transparent
<ogra> it is
<jdub> ahr
<Riddell> http://wiki.ubuntu.com/KubuntuArtwork
<jdub> yay kubuntu with a new k
<lamont> Kamion: ouch - still working on royal?
<jbailey> jcohen85: Most do not.  I'm just trying to sort out to make sure that I actually get the information I need.
* dholbach congratulates jdub :)
<jbailey> jcohen85: The problem is that I need to spit out the time for each command at each command.
<jbailey> jcohen85: It's more of a hassle than I expected.
<jdub> dholbach: :)
<Riddell> jdub: I still don't really see the difference
<jdub> heh
<jdub> <- font fascist
<torkel> edd: the old version of skype (1.2.0.11) is still installable on breezy
<edd> torkel: yeah, i got that one still in
<ogra> jdub, not in the usplash logo it seems
<torkel> edd: me too :-)
<ogra> Riddell, i'm no font fascist but i see the difference...
<\sh> torkel: but it doesn't work correctly...It was segfaulting all the time for me
<\sh> re doko 
<\sh> doko: should gcc-2.95 compile on all platforms? ;)
<lamont> \sh: no
<lamont> in fact, I don't think it's existant on any of the 3, is it?
<\sh> lamont: i386 == ok, the rest == not ok
<ogra> do we even have a source packge?
<\sh> ogra: yes
<\sh> apt-get source gcc-2.95
<ogra> nah, i dont want such old cruft
<lamont> \sh: interesting.  I specifically didn't bootstrap it, and ISTR that gcc-2.95 build-depended cpp-2.95
<doko> \sh: no, it doesn't build on ia64 and parisc
<\sh> lamont: I just installed gcc-2.95 in my chroot...so...finally I'm seeing ghosts, or it's there
<ogra> \sh, how much beer did you have today ? 
<\sh> ogra: 0 nil null nada
<ogra> haha, thats what i would say too...
* jdub uploads logos for the edubuntu and kubuntu categories on fridge :-)
<\sh> ogra: the truth
<ogra> yeah
<bddebian> Grrr, I'm not getting shit done today.. :-(
<Riddell> jdub: cool.  how is stuff submitted to the fridge?
<jdub> Riddell: atm, please mail fridge-devel@lists.ubuntu.com
<jdub> we don't have/want normal user logins on the site, so that makes "submit content" a little tricky
<jdub> also, we don't have a strong process yet, being so young
<jdub> we'll have a better process as we learn how to do it well
<Riddell> jdub: would it be possible/sensible to get an RSS kubuntu feed off the fridge so the news on kubuntu.org can just come off that feed?
<jdub> absolutely, and you can do it now :)
<lamont> \sh: it's there, but nfc why
<\sh> ogra: u see..I'm clean ;)
<Riddell> kde dot news doesn't have logins and gets surprisingly little spam
<jdub> http://fridge.ubuntu.com/taxonomy/term/20/0/feed <- the kubuntu feed :-)
<ogra> heh
* Riddell bookmarks
<jdub> Riddell: so when someone random goes to submit content, can they put their name to it? normally with drupal, anon users don't get a name input box
* jdub would turn on a simple submit thing straight away if he could easily deal with that
<\sh> jdub: what about tricking drupal with a little bit of "AuthServer" magic of launchpad?
<Riddell> jdub: yeah, you can put any name in the box.  it's amazing it doesn't get more abuse
<jdub> Riddell: but there's no box on the content submission thingy
<jdub> \sh: might end up doing that, but not committed to it yet
<Riddell> jdub: which content submission thingy?
<jdub> n/m, it doesn't use drupal anyway
<Riddell> no, squishdot
<Riddell> awful thing that has to be restarted every hour
* jdub has horrific memories of squishdot from news.gnome.org days
<jdub> it's main feature was "not slashcode"
<jdub> scared so many gnome people off zope and long-running python processes
<Riddell> what does footnotes use?
<jdub> drupal now
<jdub> it used postnuke for a while
<jdub> erk
* jdub finds serious bug in content
<jdub> i had some random copy-and-paste foo in the 5.10 event description :)
<bddebian> Gah is elmo hiding today? :-)
<\sh> oh well...
<jdong> what is the value behind dpkg's overwrite warnings?
<jdong> other than debugging during beta releases
<jdong> I'd love to see it replaced with a Continue [Y/n]  message
<\sh> jdong: --force-overwrite is your friend?
<jdong> yes, it's my friend... but I get tired of saying it on the forums every day
<jdong> a user-interactive prompt would be much better
<jdong> that'd be awesome to see in Dapper
<ogra> --force-overwrite can also break your system totally....
<ogra> so i would be very careful with it
<ogra> and definately wouldnt put it in a y/n prompt
<ogra> jdong, whats up with the backports server ? did you give it up ? there is a lot about it on -users recently
<ogra> as well as ubuntuguide.org being not reachable
<Keybuk> jdong: you should never see a file overwrite warning, if the package causes one it's buggy and needs either a Replaces, Conflicts, or both added
<Keybuk> two packages can't both own the same file
<Keybuk> consider foo having /some/file, and bar having the same file -- if you try and install bar, you'll get an overwrite warning
<Keybuk> if bar Replaces foo, you won't and the file will be owned by bar
<Keybuk> if bar Conflicts foo, then foo needs to be removed first
<Keybuk> --force-overwrite is like a Replaces
<ogra> but more evil :)
<Keybuk> but this means that when you remove bar again, the file is _removed_ and not left on the disk
<Keybuk> which may not be what was intended
<jdong> ogra: huh? A few packages were removed thanks to legal complaints, but otherwise it's fine AFAIK
<ogra> jdong, ah, ok, i think its all about w32codecs, i just looked again...
<Keybuk> so thought needs to be put into it to decide whether it's a Replaces, a Conflicts or whether the file needs to be renamed
<jdong> keybuk: yeah, but when users install 3rd party packages, it shouldn't completely break APT and need command line intervention. There should be some smarter way built into APT or Synaptic to handle this case
* sivang is back
<Keybuk> *shrug* the third party packages should be built properly
<ogra> jdong, nope, the 3rd party should fix theor package
<ogra> their even
<bddebian> wb sivang
<Keybuk> I've often thought myself that the solution to third party packages is to deter them from trying to participate in /usr and do what Sun do and use /opt
<\sh> actually, the 3rd party package should be in universe
<\sh> Keybuk: ugh.../usr/local ;)
<Keybuk> /usr/local is a duplicate heirachy and should be for user-compiled stuff
<\sh> the bsd way ;)
<ogra> \sh, skype in universe ? 
<Keybuk> I dislike /usr/local/realplayer kind of things
<Keybuk> /opt/realplayer says it just as well
<\sh> ogra: skype should be in multiverse, if we're allowed to distribute it correctly
* ogra hugs BenC for adding the #14967 fix
<shawarma> If I have a patch for a package in main (gstreamer in this case) where can I upload it? I don't suppose there's somehting like REVU for main..
<\sh> the new kernel? I don't see the sk98lin driver
<\sh> the mjg59 version of it :(
<Riddell> shawarma: bugzilla would do
<shawarma> Riddell: so first file a bug report and the add the patch?
<\sh> ah now
<Riddell> shawarma: yep
<\sh> emoved sky2 driver to be replaced by Matthew's sk98lin driver. - Added external-drivers-net-sk98lin.dpatch
<shawarma> Riddell: Ok. Thanks!
<\sh> rock
<lamont> seb128: ping
<seb128> lamont: pong
<lamont> seb128: http://buildd.mmjgroup.com/buildLogs/x/xffm/1:4.2.1-1/
<lamont> wanna tell me what happend that libgsf-1 failed to purge?
<lamont> (we removed libgconf2-4, and then later remove libgsf-1...
<ogra> grrr
<lamont> which then tried to run gconftool-2, and missing shlibs.
<lamont> oh, and broken chroot.
<lamont> grumble
<ogra> why is ports breaking my metapackage again
<Kamion> lamont: no, not working on royal at the moment
<Kamion> mdz: is cron.daily still broken? I can probably investigate if so, might just be broken overrides
<Kamion> (I've fixed that once before, so ...)
<seb128> lamont: gconf is purged before
<Keybuk> ya know what the sarge->breezy upgrade test taught me?
<Keybuk> sarge is a bitch to isntall
* ogra grumbles at sparc
<sivang> seb128: anyw news about the package? (I wasn't here for some time)
<lamont> seb128: gconf2 is purged (or tried) _after_.  libgconf2-4 is purged before.
<seb128> sivang: no, really busy
<lamont> but libgsf-1 doesn't Depend: libgconf2-4
<Keybuk> not only does the basic installer ask too many questions; but then the basic package set also asks too many questions *and* either doesn't install anywhere near enough or if you select the tasks, installs far too much!
<seb128> lamont: yeah, I meant the lib
<sivang> seb128: k, sorry. mail me in event of something to change
<lamont> Keybuk: you're here...
<seb128> sivang: np, sure
<seb128> lamont: I'll get it fixed
<Keybuk> lamont: yes, I have always been here
<seb128> dholbach: ping? :)
<lamont> Keybuk: I was just wondering if the behavior I pointed seb128 at just now is expected behavior...
<lamont> A depends: B depends: C
<lamont> removeing everything and it's mother removes C before A
<Keybuk> define "removes" in this context
<lamont> dpkg --purge
<mdz> Kamion: I haven't heard from elmo, so I assume it is, yes
<Keybuk> show me with log
<lamont> well, apt-get remove --purge, but you get the idea
* Kamion runs cron.daily to have a look
<ogra> ARGH
<mdz> Kamion: I thought roken overrides produced a meaningful error though
<mdz> broken
<ogra> i hate hate hate sparc !
<lamont> Keybuk: http://buildd.mmjgroup.com/buildLogs/x/xffm/1:4.2.1-1/
<lamont> the last hppa log there
<Kamion> mdz: I've had stuff just pile up in accepted before, the one time I broke the overrides
<Keybuk> 22-Sep-2005 10:11
<lamont> buildLogs/x/xffm/1:4.2.1-1/xffm_1:4.2.1-1_20050922-1004-hppa-failed.gz
<lamont> yes
<Keybuk> which three packages?
<lamont> build finishes, remove blows away the chroot.  libgsf-1, gconf2, and libgconf2-4
<lamont> == A, B, C
<sivang> now, time to munch some bugs
<Keybuk> libgsf-1 failed to remove
<tiefox> can rosetta be used for translation of breezy? will all translations in rosetta be used in breezy final ?
<Keybuk> dpkg: error processing libgsf-1 (--purge):
<Keybuk>  subprocess pre-removal script returned error exit status 127
<lamont> Keybuk: becauses it's pre-rm needs the libs in libgconf2-4, which was previously removed/purged
<Keybuk> libgsf-1 doesn't depend on libgconf2-4 ?
<lamont> (I know _why_ it died, just wondering if that's expected... libgsf-1 does not declare it's dep on libgconf2-4)
<lamont> no.  it depends: gconf2, which depends: libgconf2-4
<ogra> gah, hppa isnt better...
<lamont> ogra: how so?
<ogra> ports.ubuntu.com seems broken
<lamont> it's an intermittant thing...
<Keybuk> right, but that means you can safely remove libgconf2-4 as long as you don't remove gconf2
<ogra> i try to update the metapackages and dont want to rip ports out...
<lamont> ogra: see ~lamont/bin/fetchPackages on rookery... :-)
<Keybuk> uh, no it doesn't
<mdz> Kamion: it looks cleared out no
<mdz> Kamion: now
* Keybuk tries to see the forest through the trees
<lamont> ogra: that was my answer to the split world and its issues...
<ogra> hmm, 404
<lamont> ogra: ssh
<ogra> oh, ok
<Keybuk> duh
<Keybuk> it's not A dep B dep C
<Keybuk> it's A dep B dep C dep B dep C dep B...
<lamont> neato!
<Keybuk> libgconf2-4 depends on gconf2 which depends on libgconf2-4
<lamont> so it has to pick one, and picks 'shoot libgsf-1'
<Keybuk> so which one of those gets removed first is so random you can use it for high-level cryptography
<Keybuk> and to answer the question, yes Depends should be installed at the point of prerm
<lamont> Keybuk: OK.  not a dpkg bug.  you may go back to sleep.  seb128 fix libgsf-1 please.  kthxbye
<Keybuk> libgsf-1 needs to depend libgconf2-4
<seb128> yeah
<Keybuk> hmm, yet again I'm considering adding a kettle to my office
<Keybuk> this is bad
<Kamion> mdz: certainly no backtrace or anything in cron.daily's output
<Riddell> mdz: me and \sh would like to propose uploading amarok 1.3.2, it adds back alsasink which a lot of people have been missing
<mdz> Kamion: elmo has unidled since I SMSed
<mdz> perhaps he fixed it
<mdz> Riddell: what else?
<mdz> Riddell: a changelog via email would be best
<Riddell> mdz: ok
<\sh> Riddell: i'll send it to mdz
<\sh> send
<Riddell> \sh: thanks
<\sh> mdz: add to the changelog of upstream -> added patch to make alsa the default gst output (JRiddel) 
<sivang> hmm, where is the device manager gone form the system menu..
<mdz> \sh: er, so the patch and 1.3.2 are orthogonal?
<\sh> mdz: sorry...I declared it not correctly: the patch from riddell is only ubuntu specific ( gst config file patch)
<mdz> \sh: then what is the justification for 1.3.2, since presumably the patch applies just as well to 1.3.1?
<crimsun> 1.3.2 finally fixes the gstreamer engine's alsasink
<\sh> mdz: no...1.3.1 doesn't have alsaink 
<Riddell> mdz: alsalink was removed from 1.3.1 because of instability, it's been fixed up and put back in 1.3.2
<Riddell> alsasink
<lamont> ogra/riddell: thanks for the kdelibs fix
<sivang> pitti: what do you think about workarounding #6224 by making g-c-m listen to hal event of new printer, and then restarting cups like we do it in the IPP browsing patch? (not ideal, but shoudl work)
<ogra> lamont, me ??
<lamont> whoever uploaded kdelis
<lamont> libs even
<pitti> sivang: that sounds hackish - we should not need to restart cups at all
<\sh> can someone fix evolution, so it's responding _every_ time when I need it
<\sh> just removed a search and it's not responding anymore...
<pitti> sivang: and g-c-m is not dbus'ified, that would be intrusive
<\sh> no crash...
<sivang> pitti: noted
<pitti> sivang: if at all, cups itself should be made hal-aware
<pitti> sivang: then cups can call its printer initialization again, or so, without restarting completely
<lamont> ogra: and Riddell was the one who uploaded kdelibs
<Riddell> lamont: does it compile now?
<pitti> sivang: but dbus is too heavy for the breezy version now; merely sending it a signal should be enough
<lamont> yeah - just freed a metric ton of dep-waited stuff
<Riddell> groovy
<lamont> (which is to say, installed.)
<Riddell> lamont: that's metric tonne :)
<ogra> lamont, yup... i only touch kdeedu or scribus, no other QT apps get near me :) 
<lamont> Riddell: well, there are other more colorful terms for it.
<lamont> 429 packages needs-build on hppa now.  thanks
<Riddell> lamont: I'll try and keep an eye on that for what still fails, poke me if I don't
<lamont> Riddell: ok.  remember that hppa isn't exactly release critical... nor does either hppa user use kde, AFAIK
<Riddell> yep
<lamont> Kamion: compressing now, should be semi-soonish for my grumbling
<lamont> checking for gcc... no
<lamont> hrm... gonna have to look at that one
<Kamion> score
<Kamion> PATH=/nonexistent ./configure
<Keybuk> mdz: is debzilla actually working?  I added debXXXXXXX as the alias to a bug and never got the deb comments
<lamont> Kamion: actually, um, apt-get install build-essential should do the trick.
<mdz> Keybuk: no
<mdz> httplib.BadStatusLine
<Keybuk> ahh
<mdz> when trying to talk to Bugzilla
<Keybuk> which does remind me
<Keybuk> elmo: bugzilla cert expires in a week or two
<Keybuk> and $internal has already expired
<mdz> I wonder what it's pissed off about
<mdz> debzilla hasn't changed in ages
<Keybuk> I'll take a look, if you want
<mdz> did macquarie get upgraded or something?
<mdz> Keybuk: if you could
<mdz> I think I'm going to go lay down
<Keybuk> hope you feel better soon
<mdz> thanks
<pitti> mdz: get well soon!
<ogra> mdz, good decision, get well ...
<Kamion> lamont: hey, that worked
<Kamion> (royal)
<Kamion> go figure
<sivang> pitti: you mean sending a singal to cups / g-c-m ?
<lamont> hrm... do we want new kubuntu livecd rootfs for ppc?
<lamont> Kamion: ?
<lamont> or should I kill that?
<pitti> sivang: to cups, like a SIGHUP or so, which causes it to reload
* lamont decides that killed is better...
<sivang> pitti: sure then, but we need to make g-c-m aware of that a new printer was added, and then SIGHUP cupsd
<Kamion> lamont: don't care personally, although Kubuntu's last powerpc livefs was likewise 20050920 which is a bit old
<pitti> sivang: no, that should be done by a hotplug script, which also has the necessary privileges to signal cups (g-c-m can't)
<Kamion> but if you'd rather have royal's cycles doing other things, that's fine too
<Kamion> c'mon, kernel, BUILD
<\sh> hmmm..when are the install cds ready with the new kernel upload? (especially the installer boot kernel)
<lamont> Kamion: it'll do another build in the near future
<sivang> pitti: k, thanks, I'll check it out
<lamont> Kamion: which kernels are you waiting for?
<pitti> sivang: that would rock; I think a hotplug script is relatively safe and unintrusive
<pitti> ok, good night everybody
<Kamion> lamont: 2.6.12-9.14, all arches. I've just newed amd64
<Kamion> unfortunately my ADSL will cut out in a little over three hours, and it's very unlikely I'll be done before then
<Kamion> cannae change the laws of physics
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 tomorrow sometime, only necessary changes to main please
* Kamion sighs
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 due 2005-09-22, only necessary changes to main please
<Keybuk> that's today
<Keybuk> you mean -23
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 due 2005-09-23, only necessary changes to main please
<Kamion> Keybuk: thanks. it's late :-/
<Kamion> ENOBRAIN
<Keybuk> I suggest bed for you too
<mvo> rather ESLEEPY :)
<lamont> yep.  having a compiler definitely helps with building stuff
<Keybuk> lamont: ya think? :p
<\sh> Kamion: so .15 will hit the isos of -24? or late -23?
<Kamion> \sh: .15? eh?
<Kamion> Keybuk: we'll see ... at least I don't feel unwell
<\sh> Kamion: new benc upload from today
<Kamion> \sh: 'tis .14
<sivang> lamont: you can enter OP codes instead no? :-D
<\sh> should be .15?
<lamont> sivang: not for everything.
<Kamion> cjwatson@jackass:~/queue/new$ sudo -u katie ~/katie/lisa linux-source-2.6.12_2.6.12-9.14_amd64.changes
<Kamion> jackass disagrees with you :P
<\sh>  2.6.12-9.14 ????
<lamont> \sh: yes
<Kamion> \sh: I'm not going to get into giving CD image publication schedules for pre-Colony experimentation; it'll be done when it's done
<\sh> oh it's late
<lamont> Kamion: binaries are all in the overrides, yes?
<Kamion> the sooner the better ...
<Kamion> lamont: no
<lamont> ah, ok
<lamont> who's still building, fwiw?
<\sh> so i can get the sk98lin to test .. wow
<Kamion> lamont: I've only seen amd64 uploaded so far
* lamont goes looking
<lamont> i386 is still building docs.
<lamont> ppc is packaging debs
<lamont> ia64 (should anyone care), is ~50 % done
<ogra> lamont, what became of TBone (while you talk about ia64) ?
<Kamion> Keybuk: anyway, I'm in bed, with laptop ;-)
<Keybuk> ...
<Kamion> wireless++
<Kamion> 22:43 < Keybuk> I suggest bed for you too
<Kamion> (in case that seemed overly random)
<Keybuk> I saw a quote on bash.org the other day, "wireless means never having to say 'Going to the loo'"
<Keybuk> and I thought of sabdfl
<ogra> Keybuk, he has a wireless loo ? 
<sivang> \sh: what's that sk98lin ?
<Keybuk> ogra: there's wireless signal in the loo of the Canonical office
<Keybuk> and he uses it to great advantage :-/
<ogra> heh, yes here too :)
<sivang> Keybuk: what;s the loo' ?
<ogra> whats wrong with that, you save a lot of newspaper space in your toilet :)
<\sh> sivang: marvel yukon2 drivers ... (sky2 is the name of original linux drivers, sk98lin are the syskonnect drivers for this NIC)
<sivang> uh ha
<sivang> \sh: wireless NIC?
<\sh> sivang: no..wired
<sivang> ogra: true :)
<\sh> sivang: but it means to me, that I can netboot the portege r200 without tweaking the installer initrd ;)
<sivang> Keybuk: I wouldn't touch his kbd afterwards though :-D
<sivang> \sh: :-)
<sivang> \sh: use it as a thin client or plain net boot for fun?
<\sh> and I can stop tweaking the modules dir of the running system
<\sh> sivang: the r200 is a slim device without a cd/dvd drive ;)
<sivang> \sh: cool
<\sh> sivang: http://linux.blogweb.de/archives/74-Ubuntu-Laptop-Testing.html
<mvo> Kamion: todays daily i386-install looks good (just FYI)
<Kamion> mvo: thanks
<Kamion> sadly lots of testing will be invalidated by the kernel change
<sivang> \sh: nice!
<CarlFK> Kamion - how many hours till the changes are "up"?
<Kamion> CarlFK: not answering questions of that form I'm afraid
<\sh> Kamion: but as a positiv reaction: since august 05 breezy become mature and supports now more small little goddies then I ever expected in this short timeframe..kernel/laptop/installer-devels: your work was/is/will be fantastic
<Kamion> it'll be ready when it's ready :-)
<\sh> s/become/became/
<Kamion> \sh: thanks :)
<Kamion> ah, there's powerpc
<CarlFK> ah - I thought you ment some changes had been made that were waiting for a cron job to post them to daily
<lamont> dbus built.  /me hugs Riddell 
<\sh> Kamion: actually, I was quite surprised to see a running bluetooth stack on this canonical laptop..or that, after all discussions, the sk98lin driver finally made it into the kernel
<\sh> Kamion: rock
<Kamion> CarlFK: nah, they're working their way through build jobs
* mvo goes to bed now
<Kamion> CarlFK: cron.daily runs every 30 minutes, *:03 and *:33
<Kamion> (that's on the archive maintenance machine)
* \sh follows mvo, but in his own bed ;)
<CarlFK> thats not daily at all ;)
<Kamion> indeed - it's daily in Debian, hence the naming
<CarlFK> should be called breezy/asfastaswecan
<Kamion> it'll be a while before stuff makes it to cdimage though, and my ADSL currently cuts out at 1am (two hours' time) so I'm kinda screwed
#ubuntu-devel 2005-09-28
<ogra> CarlFK, we are just ahead of time ;)
<CarlFK> heh
<lamont> Kamion: i386/ppc uploaded
<CarlFK> call it breezy/tomorrow
<lamont> actually ppc is accepted
<lamont> i386 is ~3 minutes from likewise
<lamont> ia64 is... mada.
<Kamion> lamont: ~3 minutes from new
<lamont> doh.  we had that discussion
<Kamion> (i386 newed, btw)
<zyga> hmm
<zyga> is it just me or did nautilus started crashing regulary today?
<sivang> zyga: not for me
<zyga> hmm...
<zyga> I'm using libnautilus-extension
<zyga> maybe it's related
<lamont> CarlFK: it's the script cron.daily from debian's archive, we just have _really_ fast days.
<lamont> (and hours)
<mjg59> mdz: sl-modem-daemon is about a meg
<mjg59> Keybuk: Hi
<Keybuk> 'sup
<crimsun> mjg59: I've reuploaded 2.9.9d-6 from Debian, now just 2.9.10 needs to be dropped from the archive
<crimsun> mjg59: thanks for keeping me on my toes
<mjg59> Keybuk: You wanted me?
<mjg59> crimsun: No problem
<Keybuk> mjg59: yeah, cc'd you on the bug
<Keybuk> someone with a cute network card/dsdt problem where their network card is pretending to be asleep during boot
<mjg59> It's probably some bizarre interrupt issue
<Keybuk> the attached redhat bug shows the card is in D3 sleep during boot
<mjg59> Oh, right
<mjg59> What fun
<mjg59> Ok, BIOS weirdness followed by patch that's been posted to LKML
<mjg59> Probably Dapper at this point
<Keybuk> indeed
<Keybuk> bugzilla should have a "fake close" button
<Keybuk> to drag out of the woodwork the users who have been hiding and get them to wail "but this bug affects me!"
* sivang does some more reading about hotplug, then goes to sleep
<sivang> g'night all
<Keybuk> hotplug is dead
<Keybuk> ...I so love a conffile question for /etc/X11/xkb/symbols/*
<Kamion> d-i accepted *phew*
<Keybuk> \o/
<lamont> Kamion: note that the first of the LiveCD fsbuilds starts in about 2 hours, unless you decide to trump it...
<lamont> and then there's the question of whether you want the script disabled for a day or 2
<Kamion> might as well have it run tonight, but disable after that for a bit, please?
<Kamion> just in case
<lamont> Kamion: ok.  ping me tomorrow to make sure i do/did it.
<lamont> anything else before I sleep?
<Kamion> lamont: nope
<Keybuk> mdz is going to have a heart-attack when he gets out of bed and casually glances at the mail count in ubuntu-bugs
<ajmitch> Keybuk: bugs closed, I hope? 
<Keybuk> ajmitch: comments from Debian
<Keybuk> the script that imports stuff has been broken for about 6 months
<Keybuk> I just fixed it ... and it's now catching up
<lamont> Keybuk: you are a mean man
<lamont> new bugs, or just comments on old ones?
<Keybuk> comments on old ones
<Keybuk> debzilla was still creating new bugs, just never actually filling in the comments
<lamont> Kamion: I wonder if I can combine proxycommand and a control channel,,,
<lamont> ah, ok
<Keybuk> so basically it's now filling in every comment, on every release-critical and "manually related" debian bug since ~April
<Keybuk> and then mailing them individually to ubuntu-bugs, and all the subscribers of that list
<Keybuk> and mailing them individually to the reporter, assigned-to and cc list of each bug
<lamont> and to think that they called _me_ the spaminator
<lamont> (well, different "they"
<Kamion> lamont: yes
<lamont> Kamion: elmo would love for you to teach me how sometime.  But not this week
<Kamion> lamont: seems to break occasionally ... race conditions if two ssh clients try to be master on the same control socket simultaneously
<lamont> I can see that... needs to have mutual exclusion and all that, eh?
* lamont has been asked to do something about the 13 ssh clients that he fires up each time he boots the laptop
<Kamion> lamont: ssh 4.2, mkdir -p ~/.ssh/control, 'ControlMaster auto' and 'ControlPath ~/.ssh/control/%h.%p.%r' in the relevant Host stanzas in ~/.ssh/config (or in a 'Host *' stanza at the end if you're feeling brave)
<lamont> right now, it just sleeps 1.7 seconds after each one, so that the poor machine in the middle doesn't think it's getting DoSed
<Kamion> lamont: you might have to put a small sleep in there to make it work reliably
<Kamion> or leave it in there :-)
<Kamion> if you put it in Host * or in something that covers both chinstrap and the buildds, it'll automatically reuse both ssh connections to chinstrap and tunnelled ssh connections to the buildds
<Kamion> if you just put it in Host chinstrap, that would probably cover your immediate requirement
<lamont> ok.  but I'm asleep now, so I'll have to stare at that next week while I'm waiting for ia64 builds to happen
<lamont> and the goal is to reduce the number of sshd's on chinstrap, not to speed up the setup of same
<lamont> but anyway, time for this one to, um, go to sleep
<Kamion> lamont: yes, it will do that
<Kamion> lamont: the same sshd will handle a number of channels, each with a session
<bddebian> elmo: You around?
<lamont> Kamion: btw, ia64 needs some lrm love....  I'll look at it tomorrow, but it's just another cluebat to the selection critiera that seems to have gone away when nvidia was dropped 1/2 way
<lamont> I'll check with you before uploading same though
<Kamion> ok
<Kamion> about to drop offline, I imagine - night
<lamont> yeah. ditto.  g'night
<Keybuk> why does my update-notifier icon keep blinking ? :-/
<`anthony> is using #!/usr/bin/env python2.4 rather than #!/usr/bin/python2.4 standard practice for Ubuntu? 
<`anthony> i'm talking about for system tools (like update-manager, bug 16087).
<`anthony> It seems very wrong for system tools to do this.
<dholbach> `anthony: i don't think so - i saw #!/usr/bin/env python more often
<bddebian> elmo: If you happen to swing by: Is something up with memaid-pyqt?  I'm trying to clean up the MoM list.  If you want I'd be happy to check it out.
<`anthony> dholbach: that's _slightly_ less bad (in this case) but it really should be an explicit path.
<`anthony> If someone needs to install their own python (in /usr/local/bin) you really don't want the system tools using it.
<spstarr> hmm, powernowd we shouldn't force this on for non-AMD laptop/desktops?
<spstarr> n/m
<spstarr> The name is somewhat misleading, as any processor supported by the kernel cpufreq driver will work, not  just  processors  supporting  AMD
<tseng> yes.
<bob2> tes
<desrt> see bug 7263
<tseng> desrt: dude i think you fixed my battery applet
<tseng> desrt: or something.
<desrt> tseng; i patched hal.  martin merged the patch into ubuntu
<tseng> yeah
<tseng> awesome stuff
* spstarr tries out kde 3.5b1
<spstarr> weeeee
<spstarr> 3.4.91 :)
<spstarr> very nice indeed
<spstarr> aruh? we have no Linus sparse package? ;)
<bob2> someone should package it now the source is actually available
* Keybuk giggles yet again at the FAQ on the QI website
<Keybuk> Q. How are you?
<Keybuk> A. I'm fine thanks
<`anthony> Keybuk: No "Q. Would you like a cheaper mortgage? A. Die, spammer, die!" ?
<Keybuk> spstarr: ya know, for a few brief moments there I thought you were trying to aim for "no linux source package"
<spstarr> nope
<Keybuk> `anthony: I've been replying "YES!" to those for a while now
<`anthony> Keybuk: maybe I should see if I can get a cheap mortgage on this rental property I live in.
<Keybuk> bah
* Keybuk kills the person who moved MTV Hits
<Keybuk> it used to be 441 (MTV itself is 440), but now it's 442 because VH-1 (which used to be 442) has more viewers
<spstarr> actually, where 'is' the source for it, its not on kernel.org ;)
<tseng> id start by searching lkml.org
<spstarr> that should still be relevant
<spstarr> http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
<nomed> from what i'm reading ubuntu will and doesn't use xdebconfigurator ... is there any other script that can generate an xorg.conf file for a livecd?
<dholbach> good night
<bob2> adios
<mitsuhiko> hi all
<mitsuhiko> short question to the thunderbird security hole
<mitsuhiko> why is it not working in the ubuntu version?
<infinity> "it"?
<infinity> The exploit, or thunderbird?
<magnon> Security dept has to do _something_ :)
<mitsuhiko> infinity: the exploit (or i'm to stupid=
<mitsuhiko> mozilla-thunderbird -compose 'mailto:someone@domain`id`'
<magnon> mitsuhiko: isn't that a good thing?
<mitsuhiko> magnon: question. why?
<magnon> mitsuhiko: Why a non-working exploit is good?
<bob2> mitsuhiko: /usr/share/doc/mozilla-thunderbird/changelog.Debian.gz
<mitsuhiko> does this meens this thunderbird is fixed?
<wasabi> it is fairly annoying that Debian bug mail doesn't have a link to the actual bug in it
<bob2> mitsuhiko: why don't you just go check?
<mitsuhiko> hm
<mitsuhiko> no. it's not fixed
<mitsuhiko> [alt] +[f2]  is working
<mitsuhiko> hm. can we expect a fix in the this week?
<wasabi> update-manager should have some option to hold a package
<mitsuhiko> are you planning a workaround?
<jsgotangco> there seems to be no linux-restricted-modules-386 for -9 yet?
<infinity> mitsuhiko : It's being worked on, bugging people in a -devel channel won't make it happen faster though.
<infinity> jsgotangco : On that right now.
<jsgotangco> infinity, ahhh...i was testing atm, it borked nvidia heh
<infinity> jsgotangco : Just refreshing my mirror before I do heavy testing and upload.
<mitsuhiko> infinity: thx. i was only interested if there's something in the make :)
<mdz> morning
<magnon> morning
<mdz> did we get a new d-i with the new kernel done?
* magnon never slept
<mdz> neither did I
<mdz> I always say 'morning'
<infinity> Does d-i use lrm?  If so, then the answer's probably "no", since I'm doing the lrm ABI bump right now.
<elmo> 17's in the archive
<crimsun> mdz: is it possible for us to demote vlc to multiverse in time for Breezy?
<crimsun> mdz: (one of the build-dependencies is in multiverse)
<elmo> crimsun: it's in universe
<elmo> (so mdz probably doesn't care much)
<elmo> but why does it b-d on multiverse?  it doesn't in Debian
<mdz> infinity: the d-i build doesn't, no
<crimsun> elmo: right, but that means that vlc will never build using the default b-d from Debian, so to make it build, we'd have to strip the ffmpeg b-d, which makes it fairly useless
<infinity> mdz : Ahh, good.
<crimsun> elmo: vlc b-ds on libpostproc-dev, which is in multiverse
<elmo> crimsun: for values of fairly useless as in "as useful as it is in Debian" ?
<infinity> ... because libpostproc-dev is built from ffmpeg, which was recently punted to multiverse?
<crimsun> infinity: exactly
<elmo> ffmpeg isn't in multiverse
<infinity> Filename: pool/multiverse/f/ffmpeg/libpostproc-dev_0.cvs20050626-1ubuntu1_i386.deb
<elmo> sigh
<infinity> Well, that binary is, which means the source would almost have to be, no?
<elmo> the source should be
<elmo> well, no
<crimsun> the source is in universe
<elmo> universe shouldn't build multiverse binaries
<elmo> demoting ffmpeg is excessively non-obvious
<infinity> Oh, we have universe source building multiverse binaries?... Neat.
<elmo> as it pulls whole swathes of stuff into multiverse
<infinity> \o/
<elmo> and I don't think we should encourage users to add multiverse to their sources.list without good reason
<infinity> "It's filled with crack; you love crack" is enough reason for most of them.
<lifeless> is there any change in status for teh mac laptotop wifi cards ? the builtin ones
<jk-> lifeless: nope
<lifeless> I've heard rumours they can be made to work. :[
<Amaranth> lifeless: not a chance
<lifeless> ah well.
<Amaranth> lifeless: with some fun mol hackery you can make it work
<jk-> someone's working on building a driver, but it's a long, slow process.
<elmo> Amaranth: that's not true
<elmo> there are people working on reverse engineering the driver
<crimsun> libpostproc-dev is most problematic, because without it, vlc will not build with ffmpeg support without much hacking (e.g., including ffmpeg snapshot in diff.gz, which is much ugliness)
<elmo> crimsun: what IS libpostproc-dev?
<elmo> and why does it need to be in multiverse?
<mdz> infinity: I believe Kamion uploaded d-i before the kernel was built; so perhaps it dep-waited on it and built?
<elmo> mdz: as I said, 17's in the archive
<infinity> postproc is a postprocessing library, I see no reason why it would need to be in multiverse.
<mdz> elmo: ah, missed that
<infinity> I could see how one of it's deps (avcodec) could need to be in multiverse, except that it's not.
<infinity> Oh, wait, it is now.
<mdz> anyone know if Kamion did install CD builds?
<infinity> I was looking at the wrong apt-cache stanza.
<mdz> I dunno an easy way to check the version of d-i on the CDs
<infinity> Or, no it's not.  I just can't read.
<infinity> Right, so postproc (multiverse) doesn't appear to need to be in multiverse, as it's only dep (avcodec) is in universe...
<infinity> And postproc itself shouldn't contain any terribly iffy code.
<crimsun> and libpostproc's license is GPL
<infinity> Unless it infringes an Adobe patent for linear editing or something.
<elmo> breezy's kernel has degraded horribly in terms of xmms stutter :(
<infinity> (Well, I think half the archive probably infringes Adobe patents in some way, I know the GIMP hits several)
<crimsun> elmo: are you using the esd output or the ALSA output?
<elmo> OSS
<mdz> elmo: for me, xmms sucks at playing mp3s.  xmms plays other things fine, and other apps play mp3 fine.
<mdz> didn't matter what xmms output I used
<elmo> mdz: these are oggs
<crimsun> whoa, that shouldn't be messed up
<elmo> and hoary on this box was fine - it's definitely since I upgraded to breezy
<elmo> and I'm even running a "real" breezy kernel too
<elmo> (i wasn't for hoary)
<crimsun> elmo: does it occur regardless of switching to the ALSA output?
<elmo> dunno, trying that
<fabbione> morning
<pitti> Good morning
<ajmitch> morning pitti 
<bob2> shouldn't ia32-libs include libz?
<fabbione> hey pitti
<fabbione> hey pitti
<fabbione> pitti: i am going to do that hoary security thing today
<fabbione> been pretty busy with other stuff yesterda
<fabbione> +y
<infinity> bob2 : No, it depends on lib32z1, which includes it.
<fabbione> mdz: ping?
<pitti> infinity: hi! can you please have a look why mozilla-firefox_1.0.7-0ubuntu0.0.1 did not build?
<pitti> infinity: I did not get a failure log
<infinity> Ugh, why not -0ubuntu04.10?
<infinity> Meh.
<fabbione> who is experienced with ubuntu-meta?
<infinity> pitti : Did you accept hoary and warty at the same time?
<infinity> pitti : Looks like the orig didn't make it in in time for the warty builds, or something.
<infinity> fabbione : Define experienced.  I've updated it a few times, and fiddled with the seeds and such.
<fabbione> infinity: i need to remove powermanagement-interface from sparc desktop
<fabbione> i need to understand if i have to do it via seeds or directly into ubuntu-meta lists
<fabbione> + i would love to understand why totem is trying to pull in totem-xine from universe
<infinity> It depends on -gstreamer | -xine
<infinity> Is -gstreamer uninstallable for you, or otherwise something apt would skip?
<fabbione> oh i see
<fabbione> right
<fabbione> yes they have a very strict version depends
<fabbione> ok.. how do i kill the other package instead?
<infinity> So, you're saying we want pmi on all arches except sparc?
<fabbione> i don't know about the other arches, but pmi depends on acpi-support
<infinity> Is it hideously broken on sparc and shouldn't build there at all, or?...
<fabbione> and sparc has no acpi
<fabbione> and it has been built by mistaker
<fabbione> -r
<infinity> Does sparc have acpi-support?
<fabbione> nope
<fabbione> NFU
<infinity> I mean the package.
<fabbione> nope
<infinity> Hrm.  Then it shouldn't be happening at all.
<infinity> If pmi depends on acpi-support and there is no acpi-support for sparc, then it shouldn't get included, afaik.
<infinity> Or... It's a germinate bug.  Hrm.
<infinity> Or a misfeature.
<fabbione> this is the last glitch to make sparc-desktop installable
<infinity> Yeah, hppa will have the same problem.
<fabbione> i am checking how the update algos work
<infinity> As will powerpc, which is an actual release arch.
<fabbione> perhaps in the first place it is added automatically and you need to remove it manually after
<infinity> <shrug>, I can just make pmi arch-dependant in the seeds, that will fix it.
<fabbione> desktop/sparc: Skipping package acpi-support (unavailable)
<infinity> But this still seems broken.
<pitti> infinity: I did not accept either of them yet
<fabbione> Added powermanagement-interface to desktop-sparc
<fabbione> it gets readded automatically
<pitti> infinity: and the orig was uploaded to breezy first
<infinity> pitti : The orig in breezy is for a different package.
<infinity> pitti : So, if he did hoary with -sa, and warty without -sa (which would be correct), hoary needs to be accepted before warty can build.
<infinity> fabbione : yeah, I'll just make it arch-specific in the seeds and refresh.
<pitti> infinity: ouch, why a different one? that's stupid...
<fabbione> infinity: ok, so are you going to take care of it?
<infinity> fabbione : I'll bug Kamion later about how it's SUPPOSED to work. :)
<fabbione> infinity: ok thanks
<infinity> fabbione : yeah, it affects everything !i386/amd64, so it's not just an "SCC port" problem. :)
<fabbione> from a first shot this seems to be the only glitch left
<infinity> pitti : Uhm.  Huh?
<pitti> infinity: indeed there is an orig.tar.gz in the queue - that means Diziet accidentialyl uploaded with -sa for hoary?
<fabbione> infinity: oh well :)
<infinity> pitti : breezy ships "firefox", not "mozilla-firefox"
<infinity> pitti : Hence -sa is required for hoary.
<pitti> infinity: ah, I see - mozilla-firefox vs. firefix
<fabbione> lol.. firefix :)
<infinity> If only.
<pitti> infinity: bah, that's ugly - we need to test both debs, and we want to release them at the same time
<pitti> infinity: any workaround?
<infinity> pitti : Then do manual builds... Using the upload queue as a testbed is pretty insane.
<infinity> pitti : I mean, what if we find out they're buggy?... New uploads with new version numbers to fix them?.. Ugh.
<pitti> infinity: they should not be buggy, the question was more like if they built at all, and Ian wanted a clean build
<pitti> infinity: anyway, so I can't release them all together, I suppose
<infinity> Clean builds are easy enough to accomplish.
<infinity> Toss me the warty sources, and I'll do a clean chroot build here.
<pitti> infinity: I told him to use local builds, but he was sure that they work
* infinity wonders why this is a concept so difficult to grasp. :)
<pitti> infinity: chinstrap:~pitti (mozilla-firefox_1.0.7-0ubuntu0.0.1)
<infinity> Maybe I need to document "how to make your chroots behave just like buildds, so you don't have to abuse the buildds for test builds"
<lifeless> how do you get middle and right mouse clicks on a powermac ?
<pitti> lifeless: F11 and F12 by default
<infinity> Ew.
<lifeless> pitti: thanks
<infinity> lifeless : Buy an external mouse iwth more buttons.
<pitti> or that :-)
<lifeless> infinity: its my partners laptop
<infinity> lifeless : Or trade in the powerbook for a thinkpad. :)
<lifeless> infinity: I don't see that going down well ;0
<lifeless> infinity: she -loves- mac. enough said
<lifeless> I had a hoary partition
<lifeless> and I'm trying the upgrade on that to breezy
<lifeless> hoary couldn't drive the trackpad :[
<infinity> So, she owns several iPods, and defends Steve Jobs' every move?
<lifeless> nope
<lifeless> just attached to the design
<lifeless> had one ipod, it got driven over by a truck
<infinity> A fitting end.
<lifeless> heh
* pitti starts the mozilla update madness *sigh*
<fabbione> infinity: can you be so kind to debootstrap a buildd chroot on ia64?
<fabbione> infinity: it seems there is a bug in /usr/lib/debootstrap/scripts/breezy that affects only sparc and ia64
<fabbione> but i need to be sure before fixing it
<fabbione> you will get the error almost immediatly
<infinity> What's this bug?
<infinity> (-ENOTIME to play right now)
<fabbione>        add () { if [ "$ARCH" = "$1" ] ; then eval "$2=\"\$$2 $3\""; fi; }
<fabbione> I: Retrieving Release
<fabbione> I: Retrieving Packages
<fabbione> I: Validating Packages
<fabbione>  /usr/lib/debootstrap/scripts/breezy: line 20: libc6-dev-sparc64=-dev-sparc64 : command not found
<fabbione> but that part of the script is called only on sparc/ia64
<infinity> Pretty.
<infinity> Broken the same way in Debian?
<fabbione> dunno..
<infinity> Oh, wait, no it's not.
<infinity> I think I tripped on sometihng like that when trying to debootstrap breezy (variant=buildd) on the sparc here ages ago, and whined to you about it.
<infinity> deboostrapping sid worked fine.
<fabbione> yeah it's only on buildd variant
<infinity> And unless we've not had to rebuild an ia64 chroot for months (which seems unlikely, given that we built new ones for -autotest not that long ago), it's okay too.
<infinity> So, it's sparc/buildd that's broken in special ways.
<infinity> Probably the base package set broke in a way that's confusing the rest of the script in oddly undebuggable ways.
* fabbione sighs
<infinity> (since variant=buildd still uses a slightly static list, compared to the auto-guessed lists for the regular debootstrap)
<infinity> Oh look, it's a Kamion.
<fabbione> ODDD
<infinity> Kamion : It is intentional behaviour for ubuntu-meta/germinate/whoever to pull in packages whose dependencies aren't satifiable?
<fabbione> infinity: you know what.. if i run sh -x deboostrap... it works..
<fabbione> now..
<fabbione> ah no
<fabbione> it still fails
<infinity> Kamion : s/It is/Is it/
<fabbione> infinity: it looks to me that also ia64 is affected...
<fabbione> because it's the shell line that's broken
<infinity> Hrm.  I'll have to test later, then.
<infinity> Oh, wait.  We don't use the current debootstrap on the buildds.
<infinity> We just ship a breezy script for an older backport.
<infinity> That's probably why.
<infinity> It likely broke in the great reorg of debootstrap 3.x
<fabbione> infinity: ihhh
<fabbione> ahhh here it is
<fabbione> infinity:       add () { if [ "$ARCH" = "$1" ] ; then eval "$2=\"\$$2 $3\""; fi; }
<fabbione>  <-
<fabbione> it chokes on pkg names with "-"
<fabbione> it's reproducible on all arches
<fabbione> infinity: if you edit that file and add something like: add $ARCH "dselect" will work
<fabbione> if you do instead: add $ARCH "x-common" will choke
<infinity> Ahh, so it only breaks on sparc, because only sparc has the crazy package in its list.
<infinity> Makes sense.
<infinity> Feh.  How/why did libxp6 get pulled back into main (and into -desktop, no less)?
<fabbione> infinity: debian doesn't choke because it doesn't have that function
<fabbione> infinity: it is required.. mdz told me to seed it
<Chipzz> hmmm
<sivang> Morning all!
<daniels> infinity: groff, I think.
<Chipzz> just wondering... why are debootstrap scripts in /usr/lib ? they are arch:all, and perl has perl-modules in /usr/share too...
<infinity> daniels : No, nothing depends on it, it was seeded to -desktop for the benefit of people installing 3rd-party proprietary apps.
<infinity> Ugh.
<infinity> Oh well.
<infinity> Chipzz : Holdover from when they used to be arch:any, I suspect.
<daniels> fucking christ.
<infinity> Chipzz : debootstrap used to build arch-specific packages for each arch, with static package lists.
<Chipzz> infinity: that would explain
<infinity> fabbione : ubuntu-meta fixed.
<Chipzz> are things that can be executed/"run" allowed to go in /usr/share if they are arch:all? I don't think the FHS says anything about that
<fabbione> infinity: danke
<infinity> Chipzz : If not executed directly, they CAN be, but /usr/lib/package is still the standard place for most "package internal binaries", which includes scripts.
<fabbione> brb
<sivang> mmm, nvidia module missing after last update..knonw?
<infinity> You mean "no matching restricted modules for the new kernel" (That's known, new upload on the way), or "I'm using the old kernel, but something's hideously broken"?
<infinity> If it's the latter, I want details. :)
<sivang> infinity: Seems it's the first one :)
<infinity> Oh, good.  That's an easy fix, then.
<infinity> The only holdup on the upload is that I'm fixing other bugs at the same time as doing the ABI bump.
<infinity> So, give it a bit of time.
<sivang> infinity: it's 2.6.12.9 but the corrosponding modules pkg not installabe yet ;-)
<sivang> infinity: k, there a way to revert back , or shoudl I just boot with the previous kernle?
<infinity> Boot with the -8- kernel, you still have the matching l-r-m package for that installed.
<infinity> Nothing to "revert".
<sivang> infinity: just did :)
<sivang> infinity: I'm curious to know what causes the lrm of a previous kernel to not be availabe anymore, that is I've had times when the new kernel was installed, broken , and I tried to use he previous kernel with it's lrm and it was "removed" ..
<infinity> sivang : It shouldn't get removed automatically, ever.
<infinity> sivang : Unless you're using aptitude, and it's ditching old linux-image and l-r-m packages when linux-foo is upgraded, but that just sounds evil.
<\sh> daniels: #15720 -> dapper
<daniels> yeah
<Kamion> infinity: which uninstallable packages in particular? ubuntu-meta will certainly just take every top-level thing in the seed; germinate will take them, but will print an error
<Kamion> daniels: I stopped groff depending on libxp6 with that vile hack in -10
<daniels> oh
<daniels> so why's it in main still?
<Kamion> 07:54 < infinity> daniels : No, nothing depends on it, it was seeded to -desktop for the benefit of people installing 3rd-party proprietary apps.
<daniels> gnrgh
<daniels> i was hoping infinity was just talking out of his arse
<Kamion> see the seed changelog
<Kamion> it has the relevant bug reference
<daniels> the baz changelog?
<Kamion> yeah
<daniels> Modified-files: desktop
<daniels> New-patches: ubuntu-devel@lists.ubuntu.com/seeds--breezy--0--patch-191
<daniels> Summary: libxp in Desktop
<fabbione> yes i did that commit.. it's going to stay there
<daniels> as long as it never becomes my problem
<Burgundavia> jdub, can I blog about the fridge yet?
<jsgotangco> Burgundavia, it doesn't look like it's finished yet
<infinity> Kamion : See the last seed commit, and the -meta refresh.  Granted, packages that depend on arch-dependant packages should be listed in P-a-s, and never make it to the archive in the first place, but it seems a bit weird/wrong for such uninstallable packages to get included.
<Kamion> infinity: er dude - powerpc has powermanagement-interface
* Treenaks pokes apt
<Kamion> infinity: mmm, yeah, not sure which layer is properly responsible for that. I think the answer is that we should have britney runs for hppa/ia64/sparc so that we can see their uninstallables, then we'd just have fixed them ages ago
<seb128> hi
<infinity> Kamion : It has it, but it depends on acpi-support, which powerpc doesn' thave.
<infinity> Kamion : Oh, the dependency is arch-specific too.  Feh.  Should just fix pmi, then.  Didn't realise it could work without it.
<mvo> hey seb128 
* infinity blames fabbione for leading him down that path.
<seb128> Hi mvo
* fabbione blames infity
* fabbione blames infinity
<infinity> Kamion : If you want to revert the seed/-meta changes, I can just fix pmi...
<infinity> Or, better, have fabbione fix pmi. :)
<infinity> Oh, no, wait.
<infinity> It still will only work on i386/amd64/powerpc anyway.
* infinity just adds powerpc to the seed, then, as the path of least resistance.
<Kamion> and I think ia64 has acpi?
<Kamion> it does indeed. please add ia64 back too
<seb128> pitti: around?
<infinity> Meh. :)
<Kamion> infinity: the pmi script is different on powerpc; it uses pbbuttonsd there
* infinity fixes.
<Kamion> no fixing needed :)
<infinity> Kamion : Yeah, I just noticed that.
<Kamion> infinity: also, http://people.ubuntu.com/~cjwatson/testing-ports/, have a nice day ;)
<Kamion> (just created)
<infinity> I'll attack some of the ia64 stuff later.  The rest is so clearly SEP.
<infinity> :)
<Kamion> I should do universe at some point too, but that's a start
<infinity> Well, until main is in shape for a port, universe is a moot point.
<Kamion> lamont-away,fabbione: you two might want to look at http://people.ubuntu.com/~cjwatson/testing-ports/ too
<Kamion> infinity: I was thinking more for the big-three arches
<\sh> Kamion: will sparc{32/64} become an official arch for ubuntu? 
<infinity> Alright, seeds fixed.  You want to deal with updating -meta again when your seed mirror thingee runs?
<Kamion> \sh: it'll need more interest (both users and developers) first
<Kamion> infinity: sure
<infinity> Kamion : Oh, yes, britney runs for universe for the release arches would be much appreciated.
<Kamion> meh, I guess I'll have to rebuild CDs for that
<Kamion> hope it didn't affect the live CDs
<infinity> The last -meta refresh would have, cause it added libxp6 to all -desktops.
<fabbione> Kamion: cool
<Kamion> hm, I have to wait for new l-r-m anyway
<infinity> Well, it's uploaded now.
<\sh> Kamion: when u know a good (OSS) driver for a wildcat III 3d card for our sun blades 100 then I could test ubuntu on some blades here ,-)
<infinity> Shouldn't be too long to build.
<Kamion> \sh: I know nothing about sparc
<infinity> Sparc is all about the serial console love.
<fabbione> Kamion: does that output include universe?
<Kamion> fabbione: no, as mentioned above ...
<Kamion> I think I know how to do that now though, so I can sort it out later
<fabbione> no that's ok!
<fabbione> main is more than enough
<Kamion> it'll be hyoooooge
<\sh> infinity: not at all...we use the stoopid blades only for some hp openview client stuff and some other nasty things..so running 3 tfts here with three wildcat III 3d accel cards on slowlaris 8
<dholbach> hello!
<mvo> hi dholbach 
<infinity> Hrm.
<dholbach> hey mvo
<fabbione> Kamion: that's why .)
<infinity> Kamion : What's the deal with "everything from xorg is uninstallable, EEK!" in the release arch breezy testing output?
<infinity> Kamion : That seems... Wrong.
<Kamion> infinity: build skew with x-common or something?
<Kamion> there were three X-related uploads this morning
<Kamion> BTW, I need a fairly stable archive starting nowish
<infinity> x-common shouldn't affect it.
<Kamion> britney output's generally light on detail - you need to have a test system you can do 'apt-get install' on to actually see the causes
<infinity> Yeah, and apt-get install works here, hence the confusion..
* infinity cleans a chroot and tries from scratch.
<fabbione> Kamion: that output is weird.. because i get the same using apt-get install ubuntu-desktop (X can't be installed).. but if i do it manaullt.. apt-get install xwindows-core-crack-whatever.. it just works
<fabbione> Kamion:  i wonder if that could be an apt problem
<Kamion> unlikely
<lamont> Kamion: dist-upgrade vs install?
<Kamion> every single time I've seen somebody attempt to blame the packaging toolchain for britney output, it has been the packages' fault ;)
<infinity> No, it means something ubuntu-desktop depends on is breaking X, in that case.
<fabbione> lamont: fresh install
<Kamion> infinity: britney doesn't test co-installability, only installability of single packages
<fabbione> Kamion: oh i am not blaming.., i want to understand :)
<Kamion> if it says xserver-xorg-core is uninstallable, it means on its own
<infinity> Kamion : Yes, I was explaining what fabbione saw, not britney.
<Kamion> ah, right
<Kamion> fabbione: one possibility is that you have packages installed which are no longer in the archive, or which are not in main
<infinity> Kamion : britney's output is just very wrong in this case, probably caught the exact half hour where something was broken.
<fabbione> Kamion: unlikely.. it's a fresh breezy debootstrap + apt-get install ubuntu-desktop
<infinity> Oh, that half hour is NOW. :)
* infinity just updated.
<fabbione> Kamion: there 2 failures.. one related to pmi and one to xorg
<fabbione> but install xorg alone does work..
<fabbione> so i guess i will need to recheck with the new ubuntu-meta
<Kamion> I'm just uploading that
<infinity> Found it.
<Kamion> can I just express general annoyance at an ubuntu-meta upload for unreleased arches at a point when we're trying to do a CD release? :P
<infinity> Kamion : It also pulled in the libxp6 thing, which was for all arches.
<Kamion> well, that's true
* lamont notes that he's been trying to piggy-back his hppa hackery onto other stuff that was happening anyway
<Kamion> yeah, never mind me, I'm just undercoffeed and grumpy
<\sh> what the hell...why is xorg being removed?
<lamont> \sh: because it loves you
<\sh> come on guys, who did that
<Kamion> \sh: read the scrollback
<\sh> Kamion: yeah..got it...but I have to fight now with 2 people here running breezy on their laptops and they did a dist-upgrade
<Kamion> don't do that then
<infinity> Kamion : xorg uninstallibility fixed.  Go britney.  (We need more of her)
<Kamion> what was the problem?
<\sh> Kamion: it's too late..."don't restart/reboot/shutdown your laptop" is my current warning now..but anyways..now I got the blame
<infinity> Granted, I would have seen the bug the next time I tried to upgrade, which is normally nore often than I'd look at testing output. :)
<infinity> Kamion : x-common grew a conflict against xfree86-common.. Which xorg-common provides.
<infinity> TOO MANY COMMON PACKAGES.
<lamont> Kamion: disabling the daily livecd runs now.  you want dailyDI disabled as well?
<Kamion> \sh: sorry, I've little sympathy for people who dist-upgrade on a development branch without checking the list of packages that are going to be removed and making sure they're sane. They should consider it as an educational exercise for next time. :-)
<Kamion> lamont: yeah, although I hope it won't matter
<lamont> Kamion: ++
<Kamion> infinity: hah
<lamont> Kamion: you're in manual mode for the next few days then
<Kamion> that's fine
<\sh> Kamion: don't worry...u know, I'm sitting here in the NOC and have a screensaver on my windows machine which says: "This is the Place of our Ubuntu Supporter -> Please kick him when something's wrong" ... well, to point this out: I don't like SM ;)
<pitti> Mithrandir: here?
<Kamion> hmm. I have a nasty suspicion that universe britney runs will take longer than the cron.daily interregnum
<Kamion> that's kind of annoying - I might have to run them on a mirror instead
<infinity> Kamion : lrm is all uploaded, you can NEW it at will.  You may want the new, not-completely-broken x-common (1.08) before you start building images, though.
<\sh> did I say that I hate skype?
<sivang> \sh: use linphone :)
<sivang> \sh: I use it with sipgate.de ;-)
<sivang> works smoothly
<\sh> sivang: I'm not using skype anyway...but look at #16107 this annoys me...the distro is being blamed for closed source developers mistakes
<sivang> \sh: bah, I see 
<Mithrandir> pitti: pong
<pitti> Mithrandir: do you happen to know about any plans to release a new tbird?
<pitti> Mithrandir: and do you feel like updating tbird for our releases?
<Kamion> lrwxr-xr-x root/root         0 2005-09-23 10:17:20 ./usr/share/isdn/2.6.12-9-amd64-generic -> 2.6.12-8
<Kamion> infinity: what's that about?
<Kamion> hmm, avm-fritz-firmware is still at 2.6.12-8
<Kamion> is that intentional?
<Kamion> I've newed that lot, but it might need further fixing
<pitti> Kamion, seb128: do you see any reason to keep libzvt2 in main? it seems to be useful for gnome 1 only...
<pitti> seb128, Kamion: (gnome-libs source)
<seb128> pitti: why is it a main package?
<Kamion> libzvt-dev's in the supported seed
<Kamion> I have no problem removing that if nothing else uses that (check germinate rdepends!)
<pitti> right, but that seems pretty useless; if it is needed, it should be a dependency IMHO
<Kamion> * Reverse Build-Depends:
<Kamion>  +- libgtk-perl
<pitti> Kamion: I poked in the rdepends, I did not see anything that would hold it - and if there was, we don't need to seed it either, right?
<pitti> Kamion: that's universe
<Kamion> that's true
<Kamion> go ahead and unseed it
<pitti> there's libgtk2-perl
<pitti> (and similar for the other packages, like gtk2-print-perl, and so on)
<Mithrandir> pitti: for the mailto:`command` stuff?
<pitti> Mithrandir: yes, and there are some other vulns as well - http://www.mozilla.org/security/announce/mfsa2005-58.html
<pitti> Mithrandir: the shell injection patch is easy and will apply cleanly to the current package
<pitti> Mithrandir: I have a bulk version of all the other patches (not separated, though)
<Mithrandir> pitti: are you thinking "update to newer upstream version" or trying to backport the changes?
<pitti> Mithrandir: if there is a new upstream, and the diff is similarly sane as Mozilla and ffox, the new upstream would be fine
<pitti> Mithrandir: otherwise, throwing the bulk patch on our current version should work
<Mithrandir> pitti: I can take a look.
<pitti> Mithrandir: but the shell injection is pretty bad and should be fixed asap
<ajmitch> hm, no doko today?
<pitti> Mithrandir: please look in chinstrap:~pitti/{mfsa2005-58-ff10.diff,mfsa2005-58-moz17.diff}
<lamont> he might still be sleeping, or in a room that has no network
<dholbach> ajmitch: he's at DevJam (oldenburg, afaik)
<lamont> ajmitch: ^^
<ajmitch> dholbach: ah, I see
<lamont> dholbach: he arrived yesterday.  haven't seen him yet today
<ajmitch> dholbach: I'm just doing some wx fixing :)
<dholbach> maybe he went on holiday instead
<Mithrandir> pitti: scp: /home/pitti/mfsa2005-58-ff10.diff: Permission denied
<infinity> Kamion : Dang, missed that one, new upload coming. :/
<dholbach> :-p
<lamont> infinity: you're doing a new lrm???
<pitti> Mithrandir: sorry, try again
<Mithrandir> pitti: thanks
<lamont> infinity: if so, please make ia64 stop trying to build/install nvidia, since we dropped it elsewhere in the process....
<infinity> lamont : It's not, is it?
<lamont> see the log: FTBFS
<infinity> lamont : If it was, it would be FTBFS right now, and it isn't.
<infinity> lamont : You're one revision behind, dude.
<lamont> ah, cool.  last looked at -4.4
<pitti> does anybody have a scanner and a powerpc?
<lamont> pitti: I will come monday night...
* lamont is not at home, and getting things happy remotely is not feasible
<lamont> HP-PSC 2400, and a colored G3
<ajmitch> pitti: yes, but running hoary
<ajmitch> similar vintage to lamont's G3, I guess
<pitti> ajmitch: any chance you could try xsane on a current breezy live CD?
<ajmitch> pitti: sure, if I can wget one in time :)
<pitti> ajmitch: I'm asking because of https://bugzilla.ubuntu.com/show_bug.cgi?id=10573
<Mithrandir> pitti: I'm wondering if we should patch in the experimental genesys backend in sane-backends.  It works fine for me at home.
<ajmitch> it's a usb scanner, so I know it works on i386
<mvo> pitti: do you plan a upload of xsane? I have a translation for the desktop file I would like to add
<ajmitch> pitti: wgetting now
<infinity> Kamion : Fixed lrm uploaded; sorry. :/
<infinity> Kamion : You'll need to NEW it again when it builds.
<pitti> Mithrandir: no idea, I am clueless about scanners (I don't have one)
<Kamion> ok, will do
<Kamion> thanks
<pitti> ajmitch: thanks
<pitti> mvo: no, not until I have a patch to apply at least
* ajmitch is happy to see his ISP's bandwidth accounting is still very broken :)
* infinity makes a mental note to automate the ABI changes.. After you're done with the Colony.
<Kamion> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html looking much healthier now
<Mithrandir> pitti: I can try applying the change, I don't know the code base well enough to really have any idea if it works and if it breaks something else in a subtle way..
<Mithrandir> pitti: (the chunderbird change)
<infinity> Kay, and avm-frtiz* should be fixed with that upload, so that just leaves rrdtool and language-support.
<ogra> Kamion, did you get my message yesterday? the netcfg error in the installer is still there, telling me to file a bug if i see it...
<pitti> Mithrandir: oh, I did not understand the patches either - I just rely on testing
<pitti> Mithrandir: for understanding them, looking at the patches is not enough, one needs to read the complete source
<Mithrandir> pitti: I'm not that insane.  Yet, at least.
<pitti> seb128: if you print something, do you get an icon in the tray, like in hoary?
<infinity> Kamion : The rrdtool thing looks like a universe->main promotion of rrdtool is required...
<Diziet> kamion: JOOI, are the installer udebs supposed to be in archive.ubuntu.com ?
<seb128> pitti: lemme try
<pitti> Mithrandir: me neither :-)
<Kamion> Diziet: yes, they most certainly are
<pitti> Hi Diziet 
<Kamion> ogra: oh, ok - please file a bug
<seb128> pitti: yep
<ogra> Kamion, will do :)
<pitti> seb128: ok, thanks
<seb128> pitti: just printing from epiphany-browser a page and I get the icon
<Kamion> ogra: component cdebconf rather than netcfg, I think
<seb128> np
<Kamion> Diziet: e.g. http://archive.ubuntu.com/ubuntu/pool/main/c/cdebconf/
<ogra> oki
<Kamion> ogra: if you could boot with DEBCONF_DEBUG=20 as a kernel parameter and attach /var/log/syslog from the installer, that'd be good too
<ogra> o
<ogra> k
<Kamion> infinity: must be new, it's not showing up in anastacia
<Kamion> oh, an rrdtool *demotion* is showing up
<Kamion>  o librrdp-perl python-rrd python2.3-rrd python2.4-rrd               {rrdtool}
<Kamion> is that ok to do?
<Mithrandir> pitti: this is the patch from mofo for mozsuite and firefox?  They haven't released anything for thunderbird?
<ogra> not on anastacia it seems ...
<pitti> Mithrandir: no, unfortunately not
<Mithrandir> pitti: grrr. :-/
<pitti> Mithrandir: you can look into the referenced bugs, they might have patches, too
<pitti> Mithrandir: but usually the "aviary" patches work for both ffox and tbird
<infinity> Kamion : That would fix the problem just as well, I'm sure.
<Kamion> infinity: done
* infinity , being satisfied that he's done his good deeds for that day, decides it's the weekend.
<pitti> infinity: enjoy
<Mithrandir> pitti: the thunderbird thing seems to just be mailto:`command` and similar trickery?
<pitti> Mithrandir: right
<pitti> Mithrandir: also works from the command line (if called from another program)
<Mithrandir> pitti: I just got confused since there are two bugs for it; I can handle it just fine.  Warty + hoary + breezy, I guess?
<pitti> Mithrandir: yes, the whole fun
<Mithrandir> yay
<pitti> Mithrandir: however, mfsa58 had more critical vulns that apply to tbird
<pitti> Diziet: how is ffox going? moz works quite well here on warty and hoary (just finished building warty)
<Mithrandir> pitti: the bugs seems to be embargoed, so I can't look at them.
<seb128> Mithrandir: gnomemeeting update?
<pitti> Mithrandir: right, that's the problem... that's why we currently use the whole patch
<pitti> Mithrandir: apart from the version number changes (which will fail for tbird), do you get so many rejections?
<Mithrandir> pitti: haven't even tried applying the fix yet.
<pitti> Mithrandir: alternatively, I'm pretty sure that they will do a new upstream release, too
<Mithrandir> seb128: works fine for me
<seb128> Mithrandir: have you planned to upload?
<Mithrandir> seb128: I thought I'd leave that to you?  I just rebuilt the packages from Debian so a sync might be the easiest?
<seb128> Mithrandir: oh, nice
<seb128> pwlib and gnomemeeting are to update, right?
<Mithrandir> you need a newer h323lib too, iirc
<seb128> thanks
<seb128> all stock from Debian are ok? I can ask a sync to elmo ? :)
<Mithrandir> seb128: yes, those worked for me at least.
<seb128> thanks
<seb128> elmo: please sync gnomemeeting (GNOME desktop component) pwlib h323lib (required by the new gnomemeeting) from Debian
<Diziet> pitti: Just checking some things on warty now.  14390.
<pitti> Diziet: btw, we have the problem I talked about yesterday - warty is not built on the buildds since hoary was uploaded with -sa and warty does not see the orig.tar.gz
<pitti> Diziet: however, not your fault, there is nothing you could have done about this
<pitti> Diziet: but I can't toss you the warty debs; the hoary debs are in chinstrap:~pitti
<Diziet> Oh, damn, I've just discovered that the warty debs are missing.
<pitti> Diziet: see above
<Diziet> Mmm.
<pitti> Diziet: please build them yourself
<Diziet> Willdo.
<seb128> is libxp6 useful for firefox?
<seb128> #14882 has a comment saying "people report they solved
<seb128> Firefox instability by installing libxp6."
<ogra> seb128, its needed by that blackdown plugin at lease and i suspec for other third party plugins too... if its not installed ff crashes if you open a site with plugin (at least java stuff, havent tested others)
<pitti> ah, makes sense
<ogra> s/that/the
<ogra> s/lease/least
<pitti> maybe ffox should recommend it then?
<seb128> k, thanks
<ogra> nope, blackdown should
<seb128> pitti: desktop list it now
<mvo> seb128: what do you think about having a fixed gtk in hoary-updates for #14998? I'm considering this atm
<seb128> pitti: cf -changes from this morning
<ogra> and the new java-plugin metapackage depends on it afailk
<pitti> seb128: ah, ok, then it should be good
<ogra> i'm not sure if its really needed for other plugins...
<pitti>      - automatic upgrading from the cd disabled until this is properly
<pitti>        speced
<pitti> *sniff*
<mvo> pitti: :(
<ogra> :/
<ogra> what was wrong with it ? 
<seb128> is that the stuff that want to update my box to hoary when I put an hoary CD? :)
<ogra> oh
<mvo> seb128: yep, but it won't update you to hoary :)
<seb128> mvo: oh, I thought it has some strong pinning to achieve it :)
<seb128> mvo: for the GTK fix seems to be a good idea
<mvo> seb128: no, pinning would be a bit dangerous :)
<seb128> mvo: don't be a sissy :p
<dholbach> that seb... :)
<mvo> seb128: tsss, you never actually _tried_ to "upgrade" you system back to hoary ;)
<mjg59> elmo: Can you sync hotkey-setup?
<zyga> hey
<seb128> no, the nice dialog has a button to reject the proposition :p
<zyga> I've just noticed
<zyga> the screen saver allows for another person to login
<zyga> does that launch another X and gdm
<zyga> ?
* mvo makes a note that the next version will instantly apply if uid == "seb128" :P
<ogra> zyga, gdmflexiserver
<ogra> zyga, the same you get from "new login" in the menu
* seb128 prepares the special GNOME-mvo patches
<zyga> ogra: it crashes on radeon 9000
<zyga> :/
<zyga> ogra: I get another gdm but the screen is corrupted and everything dies
<ogra> zyga, with the "new login" from the menu too ? 
<zyga> ogra: checking (don't mind if I become silent)
<ogra> heh
<mvo> seb128: you mean a patch that makes it crash ;) ?
<zyga> wow :-)
<zyga> okay the result was the same
<zyga> this time I pressed alt+ctrl+backspace
<zyga> and re-logged in
<ogra> then its a bug either in gdmflexiserver or in X
<seb128> mvo: not that's not funny enough, some little screwage all over the place ... just enough to be annoying :p
<zyga> pretty fade in though :)
<seb128> anyway time to grab some food :)
<zyga> ogra: the new login did work in hoary though....
* mvo sometimes suspects seb128 of being evil
* mvo thinks food is a good idea
<ogra> zyga, i'd suspect X, but it could also be a gdm prob...
<zyga> ogra: I have to go now
<ogra> ok
<zyga> talk to you later, okay?
<ogra> sure
<pitti> BenC: do you have any idea about #5049? it affects so many people, and it makes your CDs stuck in the drive without any chance to get it back
<Diziet> Bizarre.  My warty test build has failed.   undefined reference to `operator delete(void*)'
<Diziet> Let me try the 1.0.6 to see if it's something with my machine.
<Kamion> linking with gcc rather than g++ perhaps?
<Diziet> Hmm.  1.0.6 does the same.
<Diziet> Well, yes, linking with gcc rather than g++, but why ?
* Diziet investigates.
<Diziet> Aha, no g++ installed, only g++-3.0
<sivang> ogra: I see the current screensaver is like mpt's design, so the window design and UI changes are already applied?
<ogra> sivang, thats xscreensaver
<pitti> Diziet: btw, can you ping me once you are satisfied with hoary's ffox stability? then I will release the hoary packages, which should make the warty packges able to build
<Mithrandir> pitti: it applies mostly fine, I'll need to futz it a little (for breezy), but it'd be really nice to have a patch against aviary.
<Diziet> pitti: Willdo.
<pitti> Mithrandir: the ffox patch is the aviary patch
<Lathiat> hrm
<Lathiat> new kernel is loading the wrong sata driver on my laptop i think
<Mithrandir> pitti: hmm, it is?  The tags says FIREFOX_* not AVIARY_
<pitti> Mithrandir: right, there is only FFOX_ and TBIRD_
<pitti> Mithrandir: there is no aviary tag in the CVS
<pitti> Mithrandir: both are commonly refered to as "aviary branches" in bugzilla, though
<Mithrandir> pitti: my client.mk seems to disagree with you: MOZ_CO_TAG = AVIARY_1_0_1_20050124_BRANCH
<pitti> Mithrandir: ah, ok, then this is an additional tag; I only saw TBIRD and FFOX_ so far; sorry
<sivang> ogra: ah :)
<ogra> seb128, whats that with #16128 ? i dont think gnome-screensaver will stay in main and we shouldnt encourage users to use the broken gnome-screensaver in breezy yet
<mjg59> Kamion: Do you have a rough timeframe on the Colony release?
<Kamion> mjg59: when I've unbroken everything; currently enduring much frustration as to just how much this morning's uploads broke things
<Kamion> I'm fixing l-r-m at the moment
<Kamion> (please, nobody upload to main without checking with me right now)
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 due 2005-09-23; check with Kamion/mdz before uploading to main
<mjg59> Kamion: Urgh.
<seb128> ogra: 1- why the heck do you want to move it to universe to move it again to main in 2 weeks?
<seb128> 2- how is it broken? It works fine for a lot of people
<ogra> seb128, it gets demoted automatically if nothing depends on it, doesnt it ? 
<seb128> if it's no seeded yep
<ogra> seb128, apt-cache show gnome-screensaver ;)
<Kamion> how many times do we have to say that demotions are not automatic?
<seb128> but it's a good candidate for suported imho
<ogra> Kamion, then it got demoted maunall, its not in main
<ogra> and i dont think we shoudl support it in breezy
<seb128> ubuntu-desktop can have an | with an universe package?
<ogra> either we decide its immature and demote it, or we decide its ready and support it ... where is the rationale for supporting it if we dont think its mature enough ?
<Kamion> seb128: no
<seb128> I think it's mature enough to be used
<Kamion> it can't have a | at all with the current implementation of update
<seb128> it just lacks some polish and feature
<ogra> seb128, then we should use it and support it
<Kamion> people can deinstall ubuntu-desktop if they want to vary from our recommended desktop set; that's fine
<ogra> its lacking a lot of feature
<seb128> Kamion: fine but not optimal, anyway
<seb128> ogra: yeah, lack of feature is not an issue to support a package
<ogra> seb128, there are other issues
<seb128> every single package has bugs
<ogra> i switched back to xscreensaver today, after i had to wait about 15min for the lock screen to how up after the screen was locked overnight
<seb128> there is no huge concern with gnome-screensaver, that's just not the right moment to switch
<ogra> seb128, you cant adjust *any* dpms settings...
<ogra> you cant adjust *and* screensaver settings
<seb128> lack of feature is not an issue to support a package, again
<ogra> any even
<seb128> what we want to support a package is something stable and with a certain QA level
<mjg59> Oh dear. Right, that's going to be another kernel build for Breezy.
<Kamion> due respect, but lack of necessary features is an issue, otherwise lots more of universe would be in main
<Kamion> there's no point supporting lots of alternatives in main when there's one we've selected as the primary one
<fabbione> mjg59: ????
<ogra> seb128, exactly, and we decided its not ready to support t, else we would use it in the default install
<seb128> grrr
<mjg59> fabbione: sk98lin wasn't switched on in the configs
<ogra> seb128, and it simply doesnt match the QA level yet
<seb128> that's plainly wrong
<seb128> stop the FUD
<seb128> there is no QA concern about it
<seb128> it lacks feature and polish
<\sh> mjg59: :(
<seb128> but it's stable and has no security issue
<ogra> seb128, waiting 15mins for a lock screen to show up matches our QA ? 
<Lathiat> seb128++
<seb128> I agree with Kamion on the duplicate feature though
<seb128> ogra: nautilus has crasher too, should we move it to universe?
<fabbione> mjg59: you kidding?
<seb128> gnome-panel too
<ogra> seb128, there are enough bugs to be solved before we can ship it
<mjg59> fabbione: Sadly not
* Lathiat laughs at seb128 
<ogra> seb128, nope, but these bugs get solved...
<seb128> no
<mjg59> tyrosine% find -name sk98lin.ko
<mjg59> tyrosine%
<seb128> want to see the list of bug on nautilus before speaking maybe?
<seb128> ogra: things happening to some users and not to other are quite frequent
<magnon> hm
<ogra> seb128, it locks up certain systems when using GL screensavers, it locks up systems when using unclutter, it doesnt really work with acpi, these are just some errors that are seroius enough to not support it yet
<magnon> kernel-package is the way to go for entering kernel bugs into bugz?
<ogra> magnon, linux
<magnon> ah
<seb128> ogra: lack of feature is not an error, again but let's forget about it we will switch to it right after 5.10 anyway and we will support it, you happy or not with that
<ogra> seb128, i'm absolutely happy with that
<ogra> seb128, just not for breezy... and hadrlocking user systems is quite serious imho
<torkel> ogra: looks like they have solved (for any definition of solved) which themes to run when using random in g-s-s now
<seb128> ogra: let's stop discussing about it, it bugs for some people like a lot of apps
<ogra> torkel, that was solved long ago...our gss already uses it
<seb128> ogra: you should move gamin to universe too with your definition
<ogra> seb128, yep... 
<seb128> and enough talk, that start pissing me to discuss on details
<seb128> I've some work to do
<torkel> ogra: in upstream
<ogra> seb128, probably, but gamin bugs will be looked at before release... gss bugs wont
<ogra> torkel, as i said, we already used that, upstream just tweaks it... its there since a while
<seb128> ogra: we shipped warty with some of those gamin issues, but let's stop discussing about it
<torkel> ogra: k
<ogra> seb128, yup
<ogra> seb128, we'll have a BOF about it anyway :)
<pitti> Diziet: can you receive /msgs? did you get mine?
<mjg59> pitti: It's probably worth giving up on /msg here
<pitti> bah
<ogra>  /msg nickserv set unfiltered off
<ogra> or something like that
<pitti> odd
<ogra> may be "on"
<pitti> I never have problems with receiving messages 
<pitti> from registered users, that is
<ogra> freenode blocks them since the spambot attacs began
<pitti> ogra: you mean it blocks unregistered users?
<ogra> them == unregistered users
<pitti> right
<\sh> pitti: yes
<pitti> so what is hard about registering?
<\sh> pitti: time, seeing no need
<pitti> you can kill ghost nicks, you won't lose your nick, it's easy
<ogra> pitti, it gets hairy if you use multiple nicks ;)
<pitti> \sh: the lack of private communication is a pretty severe need (for me at least)
<ogra> (at the same time)
<\sh> pitti: well..that's why I prefer for fast communition between me and person X the jabber way...:) I know that he will receive my message :)
<Diziet> pitti: I've just finished testing that ffox, and the hoary binary seems fine.  I'm not really sure what's a good test but it works with a variety of sites.
<pitti> Diziet: great, thanks! what about warty?
<Diziet> My test build (which I most recently set off about an hour and a half ago!) is still going.
<pitti> ouch
<Diziet> So I think you should release the hoary one into hoary-security and let the warty one build ASAP.
<pitti> ok
<Diziet> And I thought it was a fast computer !
* Mithrandir is doing the chunderbird warty and breezy builds now, on two machines.
<pitti> Diziet: on my amd64 3000 it needs about 30 minutes
<Diziet> It seems much slower than my main workstation (which has no space left for a warty chroot).
<Mithrandir> I'll just do this on a reasonable machine.
<Mithrandir> (dual dualcore 275)
* ogra wants that !!
<sivang> Mithrandir: amd?
<Mithrandir> sivang: yeah
<sivang> Mithrandir: pheee,  cool
<Mithrandir> actually, that one is down for maintenance so it's the dual 265 instead.
<sivang> Mithrandir: did you ever built cvs GNOME on it?
<Mithrandir> sivang: nah, I could try once.
<Nafallo> "dual dualcore" *fniss*
<Mithrandir> sivang: or my home box, which is a 4400+
<sivang> Mithrandir: nice ;)
<Mithrandir> yup
<sivang> Mithrandir: how many machines do you have?  ;-)
<Mithrandir> sivang: the 275/265s aren't mine; personally I've got two athlon64 and a laptop (and loads of junk)
<sivang> Mithrandir: ah, you told me you have a couple of machines from the uni, including an alpha or something?
* Nafallo saw 10 at Mithrandirs place he thinks ;-)
<Mithrandir> Nafallo: "junk". :-P
<Nafallo> Mithrandir: still machines ;-)
<Mithrandir> sivang: yeah, the computer club has plenty of stuff.
<Mithrandir> Nafallo: just stuff like XP1800 with 256MB of ram and similar slowlyness.
<sivang> Mithrandir: I need to visit you sometime :)
<Nafallo> Mithrandir: baah. that's a lot faster than my server :-P.
<Kamion> 9/wg 24
<Kamion> (sigh)
<zyga> hey :-)
<zyga> I'm getting my key signed finally :D
<ogra> great
<sivang> zyga: cool for you
<zyga> which keyserver would you suggest?
<zyga> to send my keys to?
<bddebian> Morning
<ogra> afternoon 
<bddebian> :-)
<pitti> Hi bdd
<pitti> Hi bddebian 
<bddebian> Heya pitti
<pitti> Mithrandir: I won't manage to release tbird for stables any more today; can we wait until Monday?
<Mithrandir> pitti: sure
<pitti> Mithrandir: maybe there will be a new upstream relase by then
<Mithrandir> pitti: I've got the hoary and warty builds running, testing the breezy one now.
<Nafallo> anyone working on the broken x-common? :-)
<Mithrandir> pitti: ok, breezy works for me, now I need to do the mailto-fix
<Mithrandir> pitti: would you like me to upload to -updates or should I send you the diffs?
<pitti> Mithrandir: if the packages work fine for you, I'd just like to take a look at the new changelog
<pitti> Mithrandir: after that you can directly upload to *-security
<pitti> Mithrandir: Maybe you can take the breezy moz changelog as example?
<Diziet> Come on you worthless piece of junk, built it !
<pitti> Diziet: let's see whether the buildds are faster :-)
<Mithrandir> pitti: sure, can do that.
<Kamion> noooooo, I need the buildds today :P
<Mithrandir> pitti: I haven't written the changelog.
* pitti wants ffox bult
<Mithrandir> Kamion: it's just *mozilla*
<Mithrandir> :-)
* Kamion wants the new kernel
<pitti> Mithrandir: not even that, mozilla is ready
<Kamion> pitti: please don't upload stuff like pbbuttonsd for non-essentials today; see the topic
<Kamion> it's built now, but still
<pitti> Kamion: oops, sorry, I missed that
<Diziet> Wahey!  Finally!
* ogra applauds
<pitti> Diziet: it built?
<Diziet> What's the odds it segfaults on startup ?
* ogra stops applauding
<pitti> Diziet: DON'T tell me! :-)
<sivang> Diziet: ffox ?
<Diziet> Yes, warty's security update.  Well, it at least seems to work a bit.  I'll play with it and see if I can break it.
<pitti> Diziet: so it didn't segfault? *phew*
<Keybuk> b.b.b...but sir, the odds of starting firefox are approximately 3,720 to 1!
<fabbione> pitti: you got the hoary crack
<pitti> fabbione: merci
<fabbione> pitti: det er i orden
<pitti> fabbione: is that dansk?
<pitti> Danish, even?
<fabbione> yup
<fabbione> "it's all right"
* Nafallo understood :-)
<pitti> Nafallo: cheating 
<sivang> Keybuk: LOL
<Nafallo> we should have #ubuntu-nordic or something :-P
* Mithrandir sighs at the suggestion that we should have more channels
* sivang channel list is already out of reach :)
<Nafallo> Mithrandir: well, we _could_ make that a rename of #norsksvenskar ? ;-=
<Nafallo> ;-)
<jdahlin> #ubuntu-nordiska-idioter
<ogra> there is no #ubuntu-no ? 
<Mithrandir> ogra: there is
<ogra> :)
* fabbione has issues with tech terms translated in italian
<Diziet> Well, I didn't manage to break it so I'm obviously just too normal.  We should ship it and let anyone still using warty break it, instead :-).
<Nafallo> hehe
<Diziet> So, pitti, do you want anything else from me ?
<pitti> Diziet: sounds like a plan, thanks! Adam was kind enough to kick the m-f build, so it shuold be all fine now
* Kamion sneaks in a cdebconf bug fix while the kernel's building, that should fix LOTS of minor installer weirdness
<Kamion> like, er, characters being left off the end of multi-paragraph descriptions
<fabbione> Riddell: ping?
<Diziet> pitti: Excellent.
<Riddell> fabbione: hi
<fabbione> Riddell: yo...
<ogra> pitti, m-f build sounds nasty....
<pitti> ogra: why?
<ogra> ...
<ogra> (not apropriate for this channel :) )
<sivang> lol
<pitti> poor Kamion - Herbert and Fabio both uploaded kernel security updates, and Ben uploaded a breezy one...
<pitti> darn, I need these buildds
<infinity> Meh.
<infinity> pitti : Still no orig showing up.
<infinity> pitti : Can't mix ACCEPTED and INSTALLED source bits, maybe?
<pitti> infinity: http://archive.ubuntu.com/ubuntu/pool/main/m/mozilla-firefox/mozilla-firefox_1.0.7.orig.tar.gz
<Diziet> kamion: I'd like to upload a new lsb package to tidy up slightly more some of the non-usplash init.d script output.
<pitti> infinity: not good enough?
<infinity> pitti : Too little, too late?  Not sure.
<pitti> infinity: would a no-change upload help?
<infinity> pitti : Do you have the power to REJECT the warty upload, and then reupload it, so katie does her magic on it?
<pitti> infinity: no :-(
<pitti> elmo: ping
<jcohen85> jbailey: did you get a chance to  create the new initramfs-tools package?
<Kamion> Diziet: fine for after Colony 5 is out, but please leave it until then
<infinity> Diziet : Define "tidy"... Your last upload made my boot significantly less tidy.
<pitti> infinity: can't I just upload a newer version?
<Kamion> I can reject the upload if need be
<Kamion> somebody explain to me in small words why
<infinity> pitti : Should work too.  Assuming this will work at all.  I'm trying to wrap my head around why it has no source.
<Yagisan> jbailey: The vmware error I reported yesterday does not appear on an all ide install. It is the known buslogic issue. Thanks for your help
<infinity> Kamion : Has to do with accepted autobuilding hooks.
<Kamion> oh, except I'm not sure I can reject out of queue/accepted/
<pitti> Kamion: katie can't see the source, so we need a reupload, as it seems 
<Diziet> kamion: OK.
<Diziet> inf: Yes, I think this will fix it.
<Kamion> just upload a new version
<pitti> Kamion: ok
<Diziet> Do you want to try it ?
<pitti> Diziet: do you still have the sources on your box?
<pitti> Diziet: can you increment it by .1 and reupload?
<Diziet> The ffox sources, yes ?
<pitti> Diziet: for warty, yes
<Diziet> For warty.  OK, willdo.  Will take a few ks to go up my local pipe.
<Diziet> Oh, just a mo, again without the .orig.tar.gz ?
<pitti> Diziet: if it's built within 25 minutes, I can release it, otherwise it will have to wait until monday (I hate far away family events at the wrong time)
<pitti> Diziet: yes, without -sa
<pitti> Diziet: the orig is in the archive now
<jbailey> Yagisan: Cool thanks.  The new kernel should apparently fix it.
<infinity> pitti : It won't be built within 25 mins.
<jbailey> Yagisan: If you have time, can you try the colony 5 CD in Vmware when it's released?
<infinity> pitti : You need to wait for cron.daily, plus you may get stuck behind a kernel or two.
<pitti> infinity: ok, so I'm doomed?
* infinity thinks we need another amber wrangler.
<pitti> infinity: alright, then I release the other crack now and do warty/ffox separately
<pitti> infinity: mdz can
<Mithrandir> infinity: you volunteered?
<infinity> mdz has rights to most of our tools, which means he's really not ideal to bug to USE most of them at any given time. :)
* pitti runs out of time and releases
<Yagisan> jbailey: sure
* Diziet watches the disk grind.
<Diziet> infinity: Did you want to try out my now-really-improved lsb ?
<Diziet> This ffox mouse scroll bug seems very odd.  It keeps coming and going.  Of course I don't see it because I have no scroll wheel mice.
<infinity> Which bug?... Where scrolling works until you get halfway down the page, then suddenly stops working, then if you refocus the page, it may or may not start working again?
<Diziet> I don't know if it's one bug or several.  The bugzilla is full of intermittent apparently-hard-to-reproduce bugs where the scroll wheel stops working.
<infinity> Diziet : And nah, I'll test it on Monday, or whenever I'm back to work.  If I still hate it, I'll yell at you directly, or propose patches. :)
<Mithrandir> Diziet: you might want to buy one, then?
<ogra> Diziet, note that scrolling works only in focused frames on frame sites
<Diziet> Sure.  If it still looks wrong, run the offending /etc/init.d by hand from within script(1) and put that in with the bug report.
<Diziet> mith: I suppose I might :-/.
<Diziet> ogra: Sure, I notice that myself with pageup and pagedown.
<ogra> yup
<ogra> so probably the focus changes somehow...
<Diziet> Probably the site's fault.  They're awful for having lots of crap which steals the focus.
<sivang> pitti: ok, it seems that the fds are opened in AcceptClient() defined in client.c , am I on the right spot? (re: cupsd)
<Diziet> But it would be nice to feel confident and close the bugs.
<pitti> sivang: you need to watch out for the network socket that is closed/reopened after sighup, not the select() calls
<infinity> No, it's not about frames or the site being at fault.
<infinity> Build an arbitrarily massive html file (or, say, browse the build logs at buildd.debian.org, again, pick a big one), start scrolling down.  It'll just stop scrolling at some point.
* Diziet 's disk finishes grinding.
<infinity> Refocussing will not always fix it, only sometimes.  Reloading the page will always fix it.
<Diziet> pitti, that ffox is now in the queue.
<pitti> Diziet: thanks
<infinity> It's a longstanding fifrefox bug, and not one I've ever bothered to complain about, but there you have it.
<jbailey> Yagisan: Awesome, thanks
<infinity> And it's a firefox+GTK bug (though, that's pretty obvious, as I don't think scrolling happens at any other level of the code), since firefox+win32 and other GUI toolkits don't have the problem.
<jcohen85> anyone know if the changes in 1.0.7 are in 1.5 beta1?
<jcohen85> *firefox 1.0.7
<infinity> Some of them almost certainly won't be, just purely based on the date it was released.
<joh> BenC: About #16134, did you just update the patches in linux-source, or did you make any prebuilt kernel packages?
<infinity> main/m/mozilla-firefox/mozilla-firefox_1.0.7.orig.tar.gz => main/f/firefox/firefox_1.0.7.orig.tar.gz
* infinity blows kisses to katie hardlinking goodness.
<infinity> s/katie/katie's/
<Kamion> I didn't know it did that
<infinity> Has for ages.
<Kamion> neat
<infinity> I just happened to be tailing my mirror update log, that's all, and had a "hey, katie really doesn't suck" moment.
<infinity> Not sure how many duplicate orig.tar.gzs we really have kicking around, but I like to see some bandwidth savings now and then. :)
<mdke> the x-common problem is known right?
<mdke> E: /var/cache/apt/archives/x-common_1.08_all.deb: trying to overwrite `/usr/lib/X11/fonts', which is also in package xfonts-base
<infinity> Uh.
<infinity> mdke : Which version of xfonts-base do you have installed?
<mdke> 6.8.2.1-3
<mdke> the system is a standard breezy installed from PR
<Nafallo> I can reproduce, and so can a lot of #ubuntu.se ;-)
<infinity> Or, more to the point, why is /usr/lib/X11/fonts a file on your system, not a directory?
<ogra> infinity,  thought there was a bug open ? 
* ogra heard it a lot today
<mdke> infinity, it is a dir
<infinity> ogra : The only x-common problem i heard a lot about today was x-common trying to remove half the system.
<Nafallo> infinity: symlink here :-)
<Kamion> mdke: #16133
<ogra> infinity, and the font stuff showed up afterwards
<mdke> good
<infinity> Ahh.
<mdke> ty Kamion 
<infinity> I must have been at dinner when the font stuff happened. :)
<thesaltydog> don't you think do give the user a choice on using usplash or not? I do prefer reading my boot sequence..
<Robot101> you can escape from it trivially
<ogra> thesaltydog, it shows you everything you'd see on console too...
<Robot101> if you know enough to understand the boot messages, you know how to disable usplash anyway
<sivang> thesaltydog: yes, and also if you need to do a fsck check once in a couple of mounts, it also exits
<thesaltydog> ogra, almost...
* infinity can't figure that bug out...
<infinity> It's a symlink in the package.  It's a directory in some other packages.  That's fine.  dpkg is supposed to "just deal" with that...
<sivang> ogra: I think it dropps on any event of error
<thesaltydog> ogra, ok. Let's say this: how can I have my console screen in small fonts (vga=791) AND usplash..?
<infinity> And, of course, I also can't reproduce it.
<infinity> thesaltydog : You can't.
<mdke> thesaltydog, you can remove usplash by uninstalling it or by removing the word "splash" from the boot options
<ogra> thesaltydog, you rewrite usplash, fix some hundrets of vga bioses to support more than vga16fb ? 
<thesaltydog> infinity, that's why I don't want usplash..
<infinity> thesaltydog : Then use vga=foo, and usplash won't run.
<ogra> infinity, he asks for BOTH :)
<thesaltydog> infinity, ok.. Now the REAL question: from this morning, after update to kernel -9, it doesn't work anymore. I have only a black screen.
<Diziet> If something is a directory in one package but a symlink (to a directory) in another, whether you get the link or the directory depends on the order of installation.
<thesaltydog> ogra, I don't have the booting sequence on screen with vga=791 from today.
<infinity> Diziet : Yes, that's known.  But in no case should it cause a CONFLICT...
<infinity> Diziet : Which is the bug being reported.
<Diziet> That's true.
<thesaltydog> and if I type telinit 1, it goes single-user in a black screen!
<Diziet> Perhaps the link is to a nondirectory.
<magnon> ok, this is REALLY weird. My powerbook's sound driver and event devices just stopped working two days ago, I didn't bother much because I had too much work, and now they all of a sudden came back and work just as before :P
<infinity> Diziet : A link to a link to another directory would be fine, I assume (as long as it eventually gets to a directory)?
<Diziet> I think so but I'd have to check the code.
<Diziet> It's a bug if not.
<infinity> mdke : ping.
<mdke> yo
<infinity> mdke : You said /usr/lib/X11/fonts was a directory on your system, right?
<mdke> infinity, it's a link
<mdke> lrwxrwxrwx  1 root root 21 2005-09-16 12:51 /usr/lib/X11/fonts -> ../../share/X1                                                                                          1/fonts
<sladen> thesaltydog: then remove 'splash' from the kopts line and type 'update-grub'
<infinity> mdke : Ahh, kay.  And does that target exist?
<thesaltydog> sladen, I will try again and be back soon. Tnx
<mdke> infinity, yes
<infinity> mdke : And the target is... A directory?
<mdke> infinity, yes
<mdke> matt@kalliope:/usr/share/X11/fonts$ ls
<mdke> 100dpi  75dpi  encodings  misc  Type1
<infinity> Diziet : Well, there you go.  Any theories? :)
<ogra> the link is there for backwards compatibility afaik
<infinity> Diziet : Note that x-common is trying to unpack a symlink identical to the one already there, even.  Which is even stranger that it should die.
<Nafallo> fwiw, that bug is arch: all ;-)
<infinity> Nafallo : No big shock, so is the package.
<ogra> shouldnt that be in postinst and only link if the link doesnt exist ? 
<Nafallo> I know :-). just tried to change it on the bugreport, but couldn't.
<infinity> ogra : Shipping a link is fine.
<Diziet> Oh, hold on, two packages are trying to unpack the same symlink ?
<sladen> jbailey: interesting.  Does /removal/ of usplash cause an initramfs rebuild?
<infinity> ogra : Trying to forcefully CHANGE a directory to a link requires postinst hackery, but shipping a link (that may or many not match up with a directory) is supposed to work.
<ogra> infinity, not if you probably would overwrite it... then i'd put it in postinst in at least one of the packages
<Diziet> Can I have the bug number, package names and versions, and stuff like that ?
<jbailey> sladen: No.
<infinity> Diziet : No, only one package contains a link, AFAIK.
<infinity> Diziet : #16133
<sladen> jbailey: so, given that retorical question, should it?
<jbailey> sladen: Sure.  A bit late in breezy's cycle for it, though.
<jbailey> sladen: The pieces are all there to do it.
<infinity> Diziet : x-common contains a link.  The rest of the packages with that directory almost certainly have it as a directory. On disk on mdke's system, it's already a link from a previous x-common installation.
<Diziet> What version of xfonts-base is installed ?
<infinity> Diziet : There's sure to be something broken in some attempt at symlink migration in the maintainer scripts (which can and should be fixed), but I'm more curious about dpkg's behavior in this case.
<infinity> Diziet : mdke said it was 6.8.2.1-3
<mdke> do you want a login to this system?
<mdke> ah actually, I can't help :/ the office firewall will get in the way
<Diziet> 6.8.2.1-3 isn't in pool any more.
<mdke> it is latest breezy :/
<Diziet> Oh, hold on, it's changed place in pool.
<infinity> Yeah. :)
<Kamion> ogra: IME it's more reliable to ship the .debs the way you want the system to end up (i.e. ship the link) and clean up the old directory in the preinst.
<ogra> Kamion, but if i have another package that needs the link that i could install separately, i'd do the postinst solution to avoid a clash if they are both installed...
<Diziet> When xfonts-base was installed, /usr/lib/X11/fonts was just a directory.
<Diziet> I assume.
<Kamion> ogra: *shrug* I can only speak from my experience of what actually works
<Diziet> How did it come to be a symlink ?
<Diziet> Oh, hold on, I think I see what's happening.
<Diziet> It notices that usr/lib/X11/fonts is a in xfonts-base, so it asks itself, well, what kind of thing is it in xfonts-base ?  It lstats it and finds it's a symlink.  So it then assumes that xfonts-base must have had it as a symlink.
<Diziet> But it's processing x-common, which contains a symlink.  So that's two symlinks, a conflict.
<infinity> Oh, argh.
<Diziet> Can you grep usr/lib/X11/fonts /var/lib/dpkg/info/x-common.list ?
<Diziet> and .../xfonts-base.list ?
<Diziet> Has something recently changed in the organisation of these X packages ?
<infinity> I doubt it was recent, but maybe.
<infinity> Oh, yes it was.
<mdke> the problem is present on my system since yesterday
<infinity>   * Add /usr/lib/X11/fonts -> /usr/share/X11/fonts symlink (closes:
<infinity>     Ubuntu#11057).
<infinity> That was in the 1.06 upload... On the 29th of August... That's hardly recent.
<mdke> hmm
<mdke> i definitely upgraded successfully yesterday evening
<mdke> this morning there was that "remove all things X", then later this afternoon, this problem
<infinity> Diziet : Anyhow, yes, in the .list, both claim to own that file on my system.  But, on my system, it works fine because it's a directory.
<infinity> mdke : Oh, did you end up removing X stuff, rather than just waiting for fixed packages?
<mdke> no i waited
* infinity bets it's the people reinstalling their accidentally removed X who are seeing the problem, and people who've had it installed all along never saw it.
<infinity> Or... Not.
<mdke> lol
<thesaltydog> sladen, ping
<Diziet> inf: That sounds like a plausible bet.
<infinity> Diziet : Yet already refuted by mdke. :)
<ogra> infinity, it also affects upgrades that didnt suffer from the removal breakage
<Diziet> On my breezy test system (last dist-upgrade a day or two ago) it's a link.
<ogra> i had some people mention it in #edubuntu
<thesaltydog> ogra, this is my /proc/cmdline root=/dev/hdb6 ro vga=791 , and during boot the screen is completely black... until gdm starts.
<infinity> Diziet : So, if it's a link on your system, dpkg should have a hissy if you apt-get --reinstall install x-common...
<Diziet> Right.  My mirror is overnight's so has the dependency problems.
<infinity> Diziet : Or upgrade, or whatever.
<Nafallo> this one is a previewinstall, and I see it :-)
<Diziet> But if I  dpkg --force-conflicts -i x-common_1.07_all.deb  I can reproduce the bug.
<infinity> Check.
<ogra> thesaltydog, i guess removing usplash and running dpkg-reconfigure for your kernel image should help
<Diziet> Oh dear, this is quite bad really.
<infinity> It really is non-obvious behavior.
<Diziet> 1.06 does it too.
<infinity> We can easily work around it in the packages, but dpkg still seems wrong to me.
<Diziet> `non-obvious'> ITYM `wrong'.
<thesaltydog> ogra, by "removing" are you meaning apt-get remove?
<ogra> yup
<thesaltydog> mmh.. let's try
<Diziet> I think for now dpkg should not mind if a package steals a symlink to a directory by replacing it with another symlink to the same directory.
<mdke> thesaltydog, also perhaps filing a major bug against usplash if that is the cause
<ogra> thesaltydog, then regenerate your initrd by running dpkg-reconfigure linux-image-`uname -r`
<thesaltydog> mdke I don't believe usplash is guilty.. maybe kernel -9
<Diziet> I'm going to have to leave early today, in only a few minutes.  I'll think about this problem and propose a fix, perhaps tomorrow.
<mdke> thesaltydog, you'll find out if you remove it
<ogra> neither is guilty...
<mdke> ogra, something is...
<thesaltydog> ogra, removing usplash will remove ubuntu-desktop, don't like..
<Diziet> I think this will be OK if we fix dpkg.  'cos the fixed dpkg and the existing x-common will be installed at the same time, and then the user will never see the bug (unless they've been testing breezy for us, of course).
<mdke> thesaltydog, just remove it to test whether usplash is causing the problem, then put it back
<ogra> mdke, its not usplash...
<infinity> Diziet : Right, and for dist-upgrades, apt always configures dpkg (well, its dependencies, then dpkg) first.
<mdke> ogra, it's you that recommended he remove it, not me :p
<Diziet> It's not a question of configure, it's a question of execute.
<thesaltydog> mdke, it happened this morning after the kernel update
<ogra> you cant run higher resolutions with vga16fb
<Diziet> As in, if you're executing the new dpkg it will work.
<mdke> ogra, but that shouldn't happen without splash on the kernel boot options right?
<Diziet> Shall I reassign 16133 to me ?
<infinity> Diziet : s/configure/unpack/
<ogra> mdke, yes, but only because thesaltydog wants a non default setup
<Diziet> Does it arrange to invoke it again after unpacking the new one ?
<thesaltydog> ogra, let's speak about freedom in a free world..
<ogra> mdke, afaik the splash line is for grub...
<infinity> Diziet : Yes, it does multiple dpkg runs.
<ogra> mdke, which has nothing to do with usplash
<infinity> Diziet : So it will do dpkg -i (dpkg deps), dpkg -i (dpkg), dpkg -i (everything else), for instance.
<mdke> ogra, but without splash in the kernel options, usplash doesn't start
<mdke> right?
<ogra> thesaltydog, yes, you have the freedon to regenerte your initrd after removing a default program :)
<thesaltydog> ogra, I only want back my nice fonts in console as I had until this morning..
<infinity> Diziet : Not at all like that in reality, but that was the fastest way to type it. :)
<Diziet> Right.  I will take this bug and it'll be fixed real soon next week.  I should have a proposal tomorrow.
<mdke> thanks Diziet 
<ogra> hmm, does that mean we wont have a colony then ? 
<mvo> thesaltydog: not sure if that was already mentinoed, but can't you just remove the "splash" from your grub config?
<ogra> i think a broken xorg-common is a quite serious blocker for that
<Kamion> ogra: it's fine on fresh installs, no?
<Diziet> I think you only see this if you upgrade it.
<thesaltydog> mvo, my /proc/cmdline is this: root=/dev/hdb6 ro vga=791
<Diziet> k: Right.
<infinity> ogra : It'll be fine on fresh installs, because x-common will always be installed first.
<ogra> Kamion, no idea, i only had users that upgraded from a daily from this week...
<infinity> (In fact, a mess of stuff pre-depends on x-common, rather anally)
<mvo> thesaltydog: and you get a splash with that?
<thesaltydog> mvo, no, I get a black screen... No boot sequence displayed, until gdm
<infinity> OTOH, that means that upgrades AFTER a fresh install will be bitten by this bug every time, cause it will be a link for sure.
<ogra> mvo, isnt the "splash" in grub not for the grub splash image ? 
<infinity> So, we can't upload a new x-common until the dpkg bug is fixed. :)
<mdke> ogra, we're talking about splash in the kernel boot options dude
<thesaltydog> ogra, I believe so.
<ogra> mdke, me too
<mdke> ah
<mdke> it's for usplash
<Diziet> Right, must go now.
<thesaltydog> mdke, the "splash" in the grub line is not for usplash
<mdke> kernel/vmlinuz-2.6.12-8-386 root=/dev/sda5 ro quiet splash <-- ogra that one?
<ogra> yup
<mvo> ogra: without splash I don't get a usplash here
<mdke> removing it on my system causes it to start withou usplash afaik
<mvo> thesaltydog: so it seems like vga=791 is failing for you?
<thesaltydog> mdke, the only way top get rid of usplash is to set a vga=... on grub. But no more since this morning...
<thesaltydog> mvo, on 2 different PCs
<mdke> thesaltydog, removing splash in the kernel options works for me
<thesaltydog> mdke, do you have a vga= in grub?
<mdke> no
<mvo> thesaltydog: same here
<thesaltydog> ogra, anyway, as things were working yestarday and are no more working starting with the kernel update this morning (on 2 PCs) I'm afraid there is a bug.
<thesaltydog> mvo, confirm?
<ogra> thesaltydog, but you had a usplash after upgrade ? 
<ogra> (when you didnt have vga= in the line ?)
<thesaltydog> ogra, no I haden't even before..
<sladen> thesaltydog: see the bit that says 'splash' on the boot line (which you must have, because you edited it to set vga=)  just *remove* it
<thesaltydog> sladen this is my line: root=/dev/hdb6 ro vga=791
<ogra> sladen, thats not for the grub splash image anymore ? 
<Kamion> ogra: read the usplash initramfs hook
<Kamion>         case $x in
<Kamion>         splash*)
<Kamion>                 SPLASH=true;
<ogra> oh
<ogra> ok
<thesaltydog> anyway, I don't have it.
<thesaltydog> but I don't even have anymore text
<mdke> must be a kernel bug then
<Kamion> it never was for the grub splash image
<Kamion> that happens before kernel parameters are handled
<ogra> hmm
<thesaltydog> Kamion, I said that...agree
<Kamion> thesaltydog: you said the opposite
<ogra> i know i had to set it in my pre warty times in debian to get that grub splash shown
<thesaltydog> Kamion, anyway I am not wuestioning on usplash. I just need my boot text back!
<ogra>  but that was 2.4 most likely 
<Kamion> ogra: not as a kernel parameter. you might have had to set it in menu.lst
<sladen> splashimage=  is for the grub splash
<mdke> ogra, i think you are confused between splash as a grub option and splash as a kernel option
<ogra> ahh
<ogra> ok
<ogra> yes, i mixed it up then
<sladen> maybe the splash option on the kernel command line should be made 'usplash'
<thesaltydog> sladen, ++
<mdke> users will understand splash better than usplash when they see it in boot-admin
<ogra> will we ship boot-admin ? 
<seb128> Keybuk: I did not put this Conflicts, not need to Cc: me on the nice explanation :p
<mvo> ogra: we do right now at least
<ogra> mvo, yes, i meant for final
<Keybuk> seb128: you're one of the worst offenders <g>
<sivang> Keybuk: I'm on for your PackageHeaders BOF :-)
<thesaltydog> ogra, I have re-configured the kernel. I am going to reboot.. back soon
<sladen> thesaltydog: did you run 'update-grub'?
<mdke> heh
<seb128> Keybuk: ah ah, slackers :p
<mdke> sladen, splash wasn't on his boot options
<mdke> the kernel must have a problem with his vga setting
<mvo> ping BenC 
<thesaltydog> ogra, it must definitively be a kernel bug..
<ogra> did you run update-grub ? 
<thesaltydog> ogra, c'mon Oliver...
<ogra> thesaltydog, if you think its a bug, look if its in bugzilla and if not, file one :)
<thesaltydog> ogra, did it. Tnx
<thesaltydog> It is something related to this morning's update.
<sladen> mdke: then why is he complaining about usplash?
<ogra> Keybuk, so with your example, ubuntu-desktop should depend on x-window-system-screensaver ?
<jcohen85> jbailey, 
<jcohen85> jbailey, it looks like the new intramfs-tools package isn't in the repository. I'm leaving this afternoon for New York. If it gets in before 3 PM EST i can still send you the file
<Keybuk> ogra: no.
<Keybuk> ogra: ubuntu-desktop should depend xscreensaver
<Keybuk> as that's the particular package we want
<Keybuk> gnome-screensaver being installed or not should be irrelevant
<ogra> Keybuk, even if they dont share common files they break badly if you got both installed
<ogra> Keybuk, that doesnt work
<Keybuk> ogra: there's no dpkg "Breaks" header I'm afraid
<ogra> Keybuk, that caused me to add the Conflicts...
<Keybuk> Q. If ubuntu-desktop Depends xscreensaver, and gnome-screensaver is installed which Conflicts xscreensaver, does this:
<ogra> you *cant* install them at the same time
<Keybuk> a) upgrade ubuntu-desktop and remove gnome-screensaver
<Keybuk> or
<Keybuk> b) cause ubuntu-desktop to be kept back
<ogra> we did a
<ogra> which is right imho
<seb128> I had both xscreensaver and gnome-screensaver for 2 months
<Keybuk> bzzzt.  Thankyou for playing
<seb128> and no issue
<Keybuk> it will, in most cases, cause b
<jbailey> jcohen85: It wouldn't go into the repository, it'd be something I'd send you directly.
<seb128> stop the FUD
<Keybuk> your Conflict breaks upgrades.
<seb128> they don't break
<sivang> LOL
<jcohen85> jbailey, oh, ok. is it ready now?
<jbailey> jcohen85: Best not to have everyone's initramfs dumping crap into their /dev
* sivang notes this is the second time seb128 mentions the word "FUD"
<ogra> seb128, it crashes either screensaver daemon it even crashed my X several times
<sivang> :-)
<bddebian> Heya sivang
<sivang> hey bddebian 
<sivang> bddebian: 'sup?
<ogra> seb128, and you got two menu entries for screensaver
<seb128> ogra: you know, sending bugs and tracking issues before doing random crappy guess is an option
<seb128> you get 2 entries, right
<bddebian> sivang: Trying to build new axiom from Debian. You?
<seb128> not a reason to use a Conflicts though
<Keybuk> *shrug*  so people who followed breezy get two menu entries
<ogra> seb128, the daemons try to grab the same ressources it cant work
* mvo had the two installed together as well
<Keybuk> if they file a bug, tell them to remove gnome-screensaver
<seb128> what deamon?
<ogra> screensaver
<seb128> g-s-d explicitly uses gnome-screensaver first
<seb128> and start xscreensaver only if this one is not installed
<ogra> run them both and you know what i mean...
<seb128> I had both install for 2 months as said
<seb128> and I accepted the upstream g-s-d patches for that
<Keybuk> ogra: this is all very nice, it still doesn't change the fact that what you've done to the package won't prevent this
<seb128> so I know how it works thanks
<ogra> i.e. gss starts with the session, now open xss config tool, it offers you to run the daemon...
<Keybuk> ogra: and that there's no way to do anything to the package to prevent this either
<seb128> xscreensaver is not used by GNOME is gnome-screensaver is installed
<ogra> seb128, sure, if you open the settings panel
<ogra> (of xss)
<seb128> bah, if the xscreensaver tools are bugged that's not my issue
<sivang> bddebian: working on fixing #6224
<ogra> seb128, thats what we support and ship currently
<seb128> yeah, fix them
<seb128> they are supported :)
<ogra> seb128, they are fine as they are
<jdub> GOOD MORNING FREEDOM LOVERS!
<seb128> hey hey jdub
<bddebian> sivang: Nice
<sivang> yo jdub da MAN :-)
<bddebian> Heya jdub
<Robot101> jdub: moin
<sivang> bddebian: Can I use use as a tester shall I be done in the nxt coupld of hours ?
<bddebian> sivang: Sure, unless you need X :-)
<sivang> bddebian: you're X is broken? ;)
<ogra> Keybuk, btw i never used rpm in my life :)
<ogra> since you refer to it
<sivang> ogra: good for you, you are pure :)
<ogra> but i'll visit your BOF ;)
<Keybuk> ogra: unfortunately it seems that you've never used dpkg either ... :)
<ogra> :p
<Keybuk> now, could you get rid of that Conflict please
<bddebian> sivang: No, I'm ssh'd in from work and I don't have x-forwarding on :-)
<ogra> Keybuk, and let the users break their systems ? 
<ogra> ok
<Keybuk> ogra: *sigh* could you go read my comment again please
<ogra> your call
<Keybuk> that Conflict will not prevent users breaking their systems, and will, instead, prevent users from upgrading their systems
<seb128> ha ha ha
<ogra> Keybuk, i read it... you say there is *no* possibility to prevent them beoing installed together
<Keybuk> yup
<sivang> Keybuk: maybe you can dd ot that BOF of yours also overview of the multitude of packaging "solutions" we currently have, e.g. cdbs, dbs, debhelper, and some specific stuff to cdbs? tarball.mk and gnome.mk ? ;-)
<seb128> and I'll say it again
<Keybuk> sorry, that's just the way it is
<seb128> having both installed is useful
<ogra> Keybuk, which will break their system
<Kamion> sivang: I'd rather people actually learnt about the basics
<seb128> GNOME uses gnome-screensaver by default
<Keybuk> ogra: seb128 disagrees
<seb128> but you may want to uses xscreesanver with KDE on the same box
<Keybuk> ogra: and again, that's a side-argument to the fact there's no way a package maintainer can prevent that anyway
<sivang> Kamion: cdbs is rather, non basic stuff, or am I mistaken?
<Keybuk> dpkg and apt simply don't provide you the headers to stop them doing it
<Kamion> sivang: correct. people should learn about dpkg, because apparently nobody does any more
* ogra sighs deeply...
<Kamion> sivang: and in any case this discussion is unrelated to packaging *helper* tools, which is what you mentioned
<sivang> Kamion: as a user of dpkg, or know it's internals? 
<Kamion> sivang: its semantics
<seb128> cdbs has nothing to do with dpkg
<sivang> Kamion: you're right. I actually was more thinking of "use Y for purpose X, use Z for purpose T etc.." but that could be a BOF by its own regard
<infinity> Drilling the "unpack phase walkthrough" from Debian ploicy into people's heads, as well as a good and solid understanding of what all the control fields actually do is rather valuable.
<infinity> Much moreso than learning the latest whizbang patch system.
<ogra> Keybuk, is filig a enhancement bug for dpkg ok with you then ? i mean, how do other apps solve that if they need to access the same ressource ? 
<seb128> fix the app to not do anything if the ressource is already used
<seb128> do nothing and say why to the user
<Keybuk> ogra: you mean like #15103 ? :)
<Kamion> the fewer Conflicts (and similar) we have in the system, the better
<Keybuk> and cf. http://www.dpkg.org/Breaks
<ogra> Keybuk, in a sidenote i was asked by mdz to add that Conflict, please add him to CC
<Keybuk> that Conflict is wrong
<Keybuk> like I said ^^, it prevents ubuntu-desktop being upgraded
<ogra> yes, i understand now
<Keybuk> rather than forces the removal of gnome-screensaver
<ogra> it shall nor force removal of gnome-screensaver
<Keybuk> which is almost, but not quite, entirely the opposite of what you intended
<ogra> it should prevent both packages being installed at the same time
<seb128> NO
<Keybuk> it would only do that if xscreensaver Conflict/Replace gnome-screensaver, and gnome-screensaver Conflict/Replace xscreensaver
<seb128> again, people maybe want to use one for GNOME and the other for KDE on the same box
<Keybuk> but then that would prevent us changing to gnome-screensaver for dapper
<ogra> seb128, yes
<seb128> Suse does that by default
<ogra> seb128, that was the intention of that cnflicts
<ogra> regardless if you think thats right, it was its intention 
<seb128> which is plainly wrong
<seb128> there is no reason to force that, both can be installed and used on the same box
<ogra> might be
<seb128> sure both can't be used by the same user
<ogra> they can, just not in the same session on the same display
<seb128> but some box have several users
<seb128> right
<seb128> so no reason to force to have only 1 installed
<Keybuk> and this, folks, is why we should be more careful about adding dependencies to ubuntu-desktop
<Keybuk> 'cause when we change our minds (*cough*polypaudio*cough*howl*cough*) later, it's bloody hard to get them off the user's system agai
* ogra doesnt get what ubuntu-deskto has to do with that...
<Keybuk> oh, and *cough*gamin*cough*
<sivang> what's the questioned dependency ?
<Keybuk> I'd almost forgotten about that one <g>
* Keybuk notes with amusement that they all involve jdub's advocacy at some point
<ogra> Keybuk, ubuntu-desktop has the right dependency... 
<seb128> Keybuk: :)
<Keybuk> maybe what we really need to learn is not to listen to jdub <g>
<ogra> it always had...
<seb128> no
<seb128> it has been changed
<Keybuk> ogra: it had gnome-screensaver for a while
<seb128> and changed back
<ogra> Keybuk, yes, and you pointed out a wrong Conflicts in gnoem-secreensaver, which is a gss issue but not a u.d issue
<ogra> dont blame u-d for my errors in gss
<Keybuk> the conflict is there to try and get around the fact that we've installed gnome-screensaver on some boxes and now installed xscreensaver as well, no?
<ogra> Keybuk, nope
<Keybuk> so if seb128 claims it all works fine (and it seems to here too), then why's it there?
<ogra> Keybuk, the conflict was there because they clash in gnome desktop and have two times the same menu entry
<Keybuk> I've just noticed that xscreensaver was never removed from by box
<Keybuk> so they have two preferences icons?
<ogra> yup
<Kamion> using Conflicts is a big deal
<Keybuk> couldn't gss ship a hack to make xscreensaver's invisible?
<Kamion> don't do it for cosmetics reasons
<Kamion> s/cosmetics/cosmetic/
<ogra> and xss tries to start the screensaver daemon if you open its panel
<Keybuk> and what happens if it does?
<Keybuk> I just got a "couldn't start daemon" error here
<ogra> Keybuk, it could, but i already lost 4 days to it and we wont support it in breezy... i wont work on it before dapper
<Keybuk> won't support which in breezy?
<jdub> gnome-session and gnome-settings-daemon kill kittens
<ogra> Keybuk, g-s-s
<jdub> hopefully the new gnome-session will land for 2.14
<Simza> is Broadcom wireless network cards supposed to work automatically in Breezy? (needs ndiswrapper in Hoary)
<seb128> jdub: what do you have g-s-d
<Keybuk> ogra: ok, so if people have it installed, they get a bit of trouble -- it's a universe package
<seb128> jdub: outside NOW
* Keybuk makes a mental note "keep old gnome-session for dapper"
<ogra> Keybuk, yup
<seb128> s/have/have against/
<Kamion> Simza: as far as I know we still have no free drivers for them
<jdub> haha
<jdub> Keybuk: don't be a cock
<jdub> seb128: it's just a painful mess
<Keybuk> jdub: you know I love you, really
<seb128> jdub: what are the plan for gnome-session? replace it? or make it using libgnomeservice?
<jdub> seb128: yeah, libgnomeservice - but that mostly means replacing it in reality anyway
<seb128> right
<seb128> and for g-s-d ?
<seb128> what is the issue with it? it does its job most of the time
<jdub> we just need to start thinking about it instead of throwing crap into it all the time
<jdub> so, example
<jdub> i start random gnome app on my windows xming display
<jdub> looks like poo
<jdub> so i start gnome-settings-daemon
<jdub> which happily goes off and starts the screensaver, does fifteen other pointless things
<jdub> so watch my surprise when xscreensaver kicks in on my windows display
<seb128> you want to make a different daemon for every single feature we start?
<jdub> we just have to think more critically about how these things fit together
<seb128> some people complain about it changing fonts
<seb128> some other about it changing theme
<seb128> some other starting the screensaver
<seb128> the other way is to split to like 15 daemons
<jdub> our ability to work within other XSETTINGS environments seems to be crap, hey? :)
<jdub> no, that's not the only way out
<jdub> for instance, with the screensaver, that could be started by the uber session daemon
<seb128> uber session daemon
<jdub> with XSETTINGS... that requires a lot of other thought
* seb128 runs away
<ogra> jdub, dholbach is not desktop-> main o_O
<ogra> ?
<jdub> ogra: his interest has been universe
<Keybuk> will the new stuff mean that I can shutdown my machine, and when I boot it again all my applications are where I left them, on the right desktop, with the right working directory and web pages loaded, etc. ?
<ogra> jdub, he does a lot in main now :)
<seb128> Keybuk: the current stuff already does that 
<Keybuk> seb128: it doesn't *work* though
<seb128> Keybuk: but apps have to register correctly to the sesison
<seb128> session
<seb128> Keybuk: yeah, app bog
<jdub> Keybuk: half of that is app side (web browser), half of that is wm (right workspace? not atm), etc.
<Keybuk> I've never seen an app start on the right desktop
<dholbach> ogra: desktop -> main?
<jdub> Keybuk: 'workspace'
<dholbach> jdub: my interest?
<dholbach> ogra, jdub: what are you talking about?
<ogra> dholbach, see ubuntu-desktop
<jdub> dholbach: ogra is referring to the desktop team stuff
<jbailey> Is there anyplace where old packages are stored?  morgue.ubuntu.com seems to have stoped some time ago.
<Keybuk> cause I still want my ideal "user session" stuff I talked about at LCA to be a reality <g>  No more logging in and logging out, just switch users and shutdown
<jdub> we
<jdub> we'll be closer to it with a saner codebase
<Keybuk> cool
<dholbach> ogra, jdub: if you have a bit of time later today, feel free to tell me slowly, what you were talking about, thanks
<jdub> dholbach: see the mailing list
<ogra> dholbach, just read your mails
<Kamion> jbailey: that's the only place, apart from jackass (which you don't have access to AFAIK)
<Kamion> jbailey: I don't know why the morgue mirror on rookery is broken
<jbailey> Kamion: 'kay, thanks.
<Kamion> jbailey: stick it in sysadmin's RT?
<jbailey> Kamion: YezBoz.
<jordi> seb128: hey
<jordi> is smeg part of breezy? If so, what's the product name in launchpad?
<seb128> jordi: it is, no clue ... launchpad has hoary packages only no?
<jordi> no, breezy should be there
<seb128> that's a question for launchpad guys
<seb128> you can use bugzilla for bugs
<\sh> phew
<\sh> extreme ubz spec writing is making me sweat 
<ogra> \sh, sweetie :)
<\sh> u read it?
<Keybuk> \sh: you're not supposed to write the specs until UBZ ... :p
<\sh> Keybuk: damn..;) it's already done ;)
<\sh> Keybuk: and it rocks man ;)
<Keybuk> \sh: which spec?
<\sh> ken and barbie are using ubuntu, btw ;) 
<\sh> https://wiki.ubuntu.com/MOTUIM/DesktopIntegrationSIPIM
<\sh> I have to link it to the correct BoF anyways..
<Keybuk> but doesn't that mean there's nothing to talk about at UBZ now? :p
<Kamion> you wish
<\sh> Keybuk: of course someone has to defend this braindead idea ,-)
<Keybuk> Kamion: mmm, ThinClientIntegrationBOF
<Kamion> Keybuk: hmm?
<Keybuk> Kamion: see /Quotes
<ogra> Keybuk, ??
<Kamion> Keybuk: oh, heh
<ogra> Keybuk, you mean the clustering ? thats on the edubuntu roadmap for dapper
<Keybuk> <Kamion (on the way to the loo)> I'm on my way to the ThinClientIntegrationBOF
<Keybuk> UDU
<ogra> lol
<Keybuk> Kamion: how's C5 coming along, btw?
<mdz> Keybuk: aaaiigighhh
<Keybuk> mdz: morning
<mdz> (EE) xf86OpenSerial: Cannot open device /dev/input/mice
<mdz>         No such file or directory.
<Amaranth> Nice.
<Keybuk> whuh ... which udev?
<mdz> ii  udev           0.060-1ubuntu14
<Keybuk> anything in /dev/input at all?
<mdz> er
<mdz> never mind, my fault
<Keybuk> yes, I thought it might be
<Keybuk> what did you do?
<mdz> heh
<Keybuk> said "no" to the conffile prompt when you upgraded?
<mdz> commented out mousedev in /etc/modules and forgot abouti t
<Keybuk> rofl
<bddebian> He pulled a bddebian ;-)
<Keybuk> the alternative to it being your fault was that I was going to have a nervous break down
<mdz> psmouse, to its credit, does load via isapnp just fine on this box
<Kamion> Keybuk: about to build after this cron.daily
<Keybuk> yeah, it's when it doesn't show up on the ISA bridge that we have problems
<Kamion> only NINE HOURS into the day
<Keybuk> it should show up through the kernel's serio stuff, but we, uh, kinda don't hotplug that *eep*
<mdz> why is it that psmouse doesn't pull in mousedev anyway?
<Keybuk> it's kinda not a dependency
<Keybuk> more of a recommends or suggests :p
* mdz glares at Keybuk
<Keybuk> because there are INSANE PEOPLE who don't want /dev/input/mice
<Keybuk> cf. why is unix.ko?
<Keybuk> "if it can be optional, it must be optional!" :D
<Amaranth> a desktop without a mouse is a bit hard to imagine
<Keybuk> one of these days, I'm going to boot a kernel and wonder why "scheduler" is in lsmod output
<BenC> irq.ko
<mdz> Keybuk: looks like the mailstrom scared off several of the CCs on the udev bug ;-)
<Keybuk> yes
<Keybuk> I was worrying for your health when you opened ubuntu-bugs
<Keybuk> HOW MANY NEW MAILS? *cry*
<mdz> Keybuk: unix.ko is loaded if you use unix sockets.  mousedev, being the interface to mice in the input layer, makes sense to load if an input driver for a MOUSE is loaded
<jdub> mdz: do you have any strong opinions on ubuntu-devel/forum mirroring?
<Amaranth> kill it!
<Keybuk> it's not the interface to mice, it's a multiplexer that fakes a ps/2 mouse for any connected mouse
<mdz> Keybuk: how is it that a permissions issue caused that HTTP error?
<Keybuk> you can get to a mouse through /dev/input/mouse0 etc. without loading it
<mdz> jdub: mirroring?
<jdub> mdz: mirroring the list on the forum
<Keybuk> mdz: I've no idea, Bugzilla crap I guess.  debzilla uses the multi-change interface, which needs editbugs permissions, and it seems to spit the "YOU CAN'T DO THAT" before it spat the http header
<mdz> Keybuk: and you can use /dev/kmem to access sysctl values
<Amaranth> jdub: make it die, all we get is a lot of noise from people saying "me too" and people responding to spam
<Keybuk> mdz: I'm entirely agreeing with you, btw; I'm just giving the reasons I've been told why it can't be either a dependency or compiled in <g>
<mdz> jdub: I thought it was supposed to be read-only, but clearly it isn't
<infinity> jdub : If they made it a read-only copy of the list, I'd be fine with it.
<jdub> mdz: would you prefer a policy change in that regard? :)
<infinity> jdub : gating the forums back to the list is just horrible.
<mdz> jdub: I'm wary of discriminating based on user interface
<Keybuk> I guess, in the end, even if we didn't detect a mouse we STILL want to load mousedev
<mdz> jdub: but everything I see coming from the forums to ubuntu-devel is noise
<Keybuk> so it's a non-issue
<infinity> I loved the guy today who posted a followup to himself because he couldn't "edit his post"... These people have no idea they're even BEING gated to a list.
<ogra> infinity, yes, made me laugh too
<mdz> and why should they?
<mdz> jdub: there's plenty of noise which comes in via email, too, mind
<Keybuk> *shrug* I've followed up to my own list posts before
<mdz> S/N on ubuntu-devel is poor now
<ogra> to not reply to spam if the form filter doesnt work
<Kamion> we desperately need to get the signal-to-noise ratio on ubuntu-devel back up so that it's worth reading again, so people should be told that it's the developers' main coordination channel
<jdub> mdz: we're working on fixing that
<jdub> mdz: but forums... harder.
<mdz> Kamion: the only way we're going to maintain that is through moderation
<Kamion> mdz: I wouldn't say no
<mdz> I would; there will always be a flow of new people joining who don't know what's expected of them
<mdz> it's the usenet problem
<Amaranth> i've started just looking for interesting subjects and not reading it all, i don't have time for all that anymore
<Keybuk> "The never-ending September 2004"
<BenC> if the installer could not detect storage and ethernet modules automatically, and they were selected manually, shouldn't the installer add those to initramfs modules list to force them being included?
<Kamion> mdz: moderation offers a number of ways to solve that, such as moderators contacting people to explain what's expected of them
<Kamion> which is often friendlier than 100 people flaming them on the list because they did something wrong that they didn't know about
<mdz> Keybuk: more like 1993
<jdub> moderation is a very expensive solution
<\sh> mdz: btw...made a decision on amarok 1.3.2? 
<Kamion> BenC: hmm, possibly - bit late for breezy but we could do for dapper
<Keybuk> mdz: now you're doing it too, "I've been using Ubuntu since 1993" :p
<BenC> well, it only affected a sparc64 install, so it's not terribly important
<mdz> Kamion: are you agreeing that  moderation is the solution?  I assumed 'no' was a typo for 'so'
<mdz> moderation isn't that expensive if it's shared among a larger group of people
<Kamion> mdz: I am, yes
<Kamion> or at least *a* valid solution
<Kamion> I haven't heard other ways to get the noise down yet
<jdub> mdz: atm, i'm setting up team for moderation, which will help, but that doesn't make it much less expensive
<Kamion> mdz: that explains your earlier comment then, which I took for precisely the reverse of its actual meaning
<jdub> it just distributes the load
<mdz> Kamion: it's also occurred to me that your 'n' and 's' are not adjacent
<mdz> unless you've switched to dvorak
<Kamion> mdz: I have not :-)
<jdub> mdz, Kamion: are you actually suggesting we whitelist participants (rather than all subscribers)? "moderation" doesn't describe a solution
<mdz> jdub: that's not a bad idea
<jdub> ok then, sorry, i disagree. it's a terrible idea
<Kamion> exact forms of whitelisting are an implementation detail; I've seen moderation done all sorts of ways
<Kamion> up to and including weird voting systems
<jdub> right, but that's the significant part of the solution
<jdub> not "let's moderate!"
<Kamion> but fundamentally we need not everything (aside from spam) that people send to ubuntu-devel to get through
<jdub> we already moderate, in a particular way
<dholbach> elmo: ping
<Kamion> I could also agree with holding just thread-starting posts for moderation
<elmo> dholbach: ?
<bddebian> elmo!!
<dholbach> elmo: could you please sync tct and gnokii from debian sid? they should build on amd64 then too
<Kamion> or there's the lkml-style policy of "if a thread gets out of hand, a moderator posts to say that it will be forcibly ended soon if it doesn't get more reasonable"
<bddebian> elmo: Are you waiting to do something with memaid-pyqt?
<dholbach> elmo: ok to override our changes
<Kamion> (which is a bit on the dictatorial side, but hey, look how people still actually use lkml for real work despite its volume)
<jdub> Kamion: lkml is not always a good role model. ;-) you can always just say at the beginning of a meltdown (either start of thread or start of insanity), "hey, let's take this elsewhere".
<elmo> dholbach: done
<elmo> bddebian: I'm just behind
<dholbach> elmo: merci beaucoup
<Kamion> jdub: I know it isn't, and I hope my more recent comment clarified that
<jdub> quiet, reasonable education seems to work well
<bddebian> elmo: No problem, I'm just trying to clean up the lists.  You want me to take a look?
<jdub> we just haven't tried that enough yet
<jdub> and i would prefer to do that before getting into the more serious forms of moderation
<elmo> bddebian: er, what do you mean have a look?
<Kamion> for all its faults, lkml has done a good job of keeping traffic generally reasonable for its size, while generating remarkably few complaints
<bddebian> elmo: Do the merge and upload
<jdub> while scaring away contributors... ;-)
<elmo> bddebian: umm - either it's a sync, in which case I'm involved, or it's not a sync and what's it got to do with me?
<Kamion> jdub: I don't see a shortage of contributors to the Linux kernel
<bddebian> elmo: It's assigned to you on bugzilla
<jdub> Kamion: they scare a lot of people awya
<Kamion> the kernel needs long-term contributors, not drive-bys
<jdub> yeah, and long-term ones are hard to grow without satisfied drive-bys
<Kamion> I'd argue that kernel contributors need to be able to cope with the traffic in order to be able to cope with the kernel development model
<jdub> traffic, yes. behaviour, no.
<mjg59> jdub: I've found lkml to be one of the more reasonable mailing lists I've been on
<mjg59> Technical ones, at least
<jdub> mjg59: i will put that in context of flaming plastic ____ death. ;-)
<Kamion> wow, and people complain about our installer. *How* many times do I have to tell the Windows installer that my locale is "English (United Kingdom)"?
<bddebian> elmo: Never mind then, I'll just look at it. :-)
<mjg59> Kamion: Weirdly, you *don't*
<elmo> bddebian: please do - it shouldn't be assigned to me
<bddebian> OK, sorry
<elmo> mjg59: umm, yeah you do
<Kamion> mjg59: hm? I just had to tell it about five times
<mjg59> Kamion: One of the machines I got defaulted to correct ones after I'd selected my timezone
<mjg59> So it's *possible* for it to be sane
<infinity> OEM installers cut corners, the full Windows install doesn't guess at anything, and so asks you about timezone, language, keyboard, etc.
<infinity> Then again, after poor experience with Windows localisation (long, LONG ago, mind you), I lost all faith, and just always install in en_US anyway now.
<mjg59> Linspire won't let you choose any english keymap except US
<spstarr_work> erm, network-manager build is broken in breezy
<spstarr_work> there's no NetworkManagerInfo binary in the packaging
<spstarr_work> 0.4.1+cvs20050817-0ubuntu4
<ogra> mdz, regarding your ltsp change, i thought to do it by just setting the right environment vars in ldm 
<dholbach> spstarr_work: i suggest taking this to 
<dholbach> spstarr_work: i suggest taking this to  #ubuntu-motu
<tseng> are there recent kernel changes related to capabilities?
<tseng> the most recent changelog doesnt shed light on much
<tseng> before reboot, sudo ethereal = works
<tseng> after, ethereal cant set its capabilities
<tseng> it tries to drop most of them
<mdz> ogra: my change only affected the console
<ogra> oh
<ogra> ok
<mdz> ogra: I would welcome a branch which does the same for X debconf
<mdz> but it is low priority for breezy
<ogra> mdz, i'll do one, also with dhcp.conf generation
<mdz> ogra: first, mark needs to be happy with the xscreensaver dialog ;-)
<ogra> yup
<ogra> but the dhcp.conf stuff is essential, i need to have it solved before release ;)
<tseng> oh wow this is emabarassing
<ogra> ayway, i got a dog waiting, brb
<mdz> Riddell: you have editcomponents now if you want to set default assignees for components in Bugzilla
<tseng> capability module isnt loaded
<jdub> ogra: the hoary dialogue was good, how about going back to that?
<tseng> mdz: id be willing to say thats a pretty serious bug somewhere?
<bddebian> tseng: Is that you that has gtksourceview and the mono* stuff on the bugzilla Merge list?
<ogra> jdub, sabdfl wants me to mimic the g-s-s dialog ... i'll do that as much as i can ...
<tseng> bddebian: probably.
<jdub> ogra: but the g-s-s dialogue is crap ;-)
<bddebian> tseng: Do you know of any holdup with the gtksourceview one?
<Riddell> mdz: ok, thanks
* bddebian won't touch mono*
<ogra> jdub, in fact sabdfl wants: https://wiki.ubuntu.com/ScreenSaver
<tseng> bddebian: is there a problem?
<bddebian> tseng: Nope, just trying to clean up MOTU lists :-)
<jdub> yeah, sure, but that's totally not breezyable
<ogra> but i'm not sure if ui can make it to have a unlock button, that requires heavy code changes
<tseng> bddebian: there is no good reason to touch it at this point imo
<jdub> ogra: this is such a low-impact change, can't we convince him to be less concerneda about it? simple solution would be better than mucking around.
<ogra> jdub, 90% of it are already there its just a matter of moving the pieces to the right place and making the dialog a bit less heigh
<jdub> ok
<jdub> so long as you don't have to do silly things to make it like that
<bddebian> tseng: So reject the merge bug?
<ogra> i dont think i can add the unlock button now
<ogra> and the rest is fine...
<ogra> anyway, dogwalk... brb
<bddebian> elmo: OK, please sync memaid-pyqt 0.2.3-4 from unstable.  Our changes can be overwritten.  Thanks.
<elmo> bddebian: done
<bddebian> elmo: Thanks
<bddebian> elmo: Now hit all my e-mails ;-P
* bddebian ducks
* \sh doesn't bother elmo today...
<bddebian> \sh: You have oo2c to merge on bugzilla ;-P
<\sh> bddebian: it's done already..but I need clamav...;)
<\sh> bddebian: but not toda
<\sh> y
<bddebian> Ahh OK :-)  I should have known :-)
* \sh is done for today..and drinks beer
* mvo yum beer
<\sh> well..beer == klsch here ,-)
<ogra> prost \sh
<Keybuk> mvo: update-notifier's gone grey again ... what's it doing?
<\sh> ogra: cheers friend :)
<ogra> Keybuk, ps ax ? 
<Keybuk> no dpkg or apt running
<mvo> Keybuk: grey? does the tooltip say anything useful?
<Keybuk> I'll tell you next time it does it
<twoSharp> is the gksudo with partially transparent background gone? i lost it after updating...
<mvo> Keybuk: it sometimes lags a bit behind in noticing
<Keybuk> mvo: by days?
<mvo> twoSharp: yes, gone
<mvo> Keybuk: I hope not ;)
<ogra> twoSharp, yes luckily
<Keybuk> I last ran apt yesterday
<mvo> Keybuk: anacron and the automatic apt-get update maybe?
<twoSharp> mvo, is there any way to get it back? or why did it get removed?
<ogra> twoSharp, it look terrible...
<ogra> looks even
<mvo> twoSharp: the UI team decided that it is visually too strong, sorry, no option to get it back
<Keybuk> mvo: at 7:30pm?  nope
<Treenaks> ogra: matter of taste, the terrible-ness
<Keybuk> that was 12 hours ago
<ogra> Treenaks, i dont think so...
* sivang astonished to see yet more discussions about g-s-s :)
<twoSharp> where can i get the source code then?
<Treenaks> ogra: I liked it :)
<mjg59> Keybuk: Any chance of you installing Windows at some point
<ogra> Treenaks, its just implemented wrong... the idea is great though
<Treenaks> is the wiki known slow?
<mvo> twoSharp: apt-get source gksu and remove debian/patches/08_no_fadding.patch and rebuild
<ogra> Treenaks, once we'll use composite all over the X server you can have it back, but fade like xscreensaver
<Keybuk> mjg59: on what?  and for what reason?
<dholbach> Treenaks: for me too
<ogra> the wiki is slow since days
<mjg59> Keybuk: Your laptop, so I can get tbm to stop whining at me to fix suspend
<mvo> Keybuk: you didn't run dpkg by any chance? that triggers it as well (the grey)
<Keybuk> mvo: nope, I didn't
<Keybuk> mjg59: yeah, I can do; do you know how to netinst windows?
<mjg59> Keybuk: Nope
<Keybuk> I don't have a CD drive for this laptop
<Keybuk> I have the driver disk for it somewhere though, if that would help you?
<sivang> ogra: what is the current status wrt xss ? have you started working on gss yet?
<dholbach> Keybuk: somebody explained me how to usb-inst windows, it was horribly complicated and i forgot it again :(
<sivang> why does Keybuk need windows?
<ogra> sivang, as i said yesterday, there wont be much to do on g-s-s, upstream is adopting most of our changes already, by the time we will have to care for it the changes will be minor
<sivang> ogra: I see, so what is all the fuss about? ;-)
<ogra> which fuss ?
<ogra> sivang, you mean the discussion before ? that was more general about packaging...
<\sh> dholbach: use windows pe ,-)
<ogra> \sh, pe ? pendrive edition ? 
<\sh> ogra: it's the version which u can pxe/net/usb boot ,-)
<ogra> heh
* ogra wonders how to integrate that as thin clinet in edubuntu
<\sh> ogra: but regarding the fact, that it costs money and I don't use copied versions of windows, it's no solution for me to reinstall my laptop...cheaper is to borrow the usb dvd rom of dmitry ;)
<mdz> Keybuk: is the joystick issue also resolved now?
<ogra> \sh, heh
<Keybuk> mdz: no, not yet
<Keybuk> I have two different versions of udev which may resolve it
<Keybuk> but I'm going to wait until C5 is done before picking one
<Keybuk> just so I don't make Colin's day worse <g>
<zyga> hmm okay this is not a support question
<zyga> I've just burned a dvd with gnome baker, this is a 30-minutes-before upgraded breezy
<zyga> the burning went fine without any interrutpion
<zyga> afterwards the DVD was automatically ejected so I put it back in to verify the contents
<zyga> first I could not mount the cd at all (bad filesystem)
<zyga> then I could not eject the disk (invalid argument)
<zyga> sudo eject did work though
<zyga> I repeated the eject/mount process but nothing changed
<zyga> the disk works flawlessly on windows xp
<zyga> it still keeps failing here
<zyga> could anyone give a reasonable explanation?
<BenC> is there a way to delete a page from wiki.ubuntu.c?
<Kamion> BenC: bottom of the drop-down starting with "More Actions"
<Kamion> at the right-hand side of the row starting with "Edit"
<hubH> sorry guys, I just submitted a patch to bugzilla for a security fix...
<BenC> Kamion: thanks
<infinity> hubH : Abiword?
<hubH> infinity: yep
<zyga> infinity: bah, you are disclosing security information ;-) now all the hackers can look at abiword
<infinity> Surely, the hackers subscribe to ubuntu-bugs and filter on "security" for just such an occasion. :)
<hubH> MacOS X is vulnerable too :-)
<hubH> I don't describe the problem, I give the fix
<zyga> infinity: isn't a security related bug disclosed only after a patch has been applied?
<infinity> zyga : Not if it's already public.
<hubH> upstream have a patch in CVS
<hubH> I did the patch in CVS
<infinity> hubH : I assume by your public bug filing that this isn't embargoed on vendor-sec, then? ;)
<zyga> infinity: true, true
<hubH> infinity: then notified me
<hubH> s/then/they/
<hubH> CVS is public
<hubH> so the fix is public
<hubH> I send the bug to debian as well
<infinity> hubH : Do you have a CVE CAN as well that you can include in the bug for us to cross-reference?
<hubH> infinity: yeah
<hubH> wait
<hubH> infinity: something like "CESA-2005-004 - rev 1" ?
<infinity> Somethine more like CAN-2005-1234 would be what I'd expect. :)
<hubH> ah
<hubH> I only have that
<infinity> If one's not been assigned yet, no big deal.
<infinity> pitti will have the vendor-sec mails to cross-reference, and I'm sure we'll deal with it on Monday.
<hubH> reporter is "Chris Evans"
<hubH> thru "vendor-sec@lst.de"
<hubH> patch has been posted on the list as well
<infinity> hubH : Do you have a reproducible crash/exploit we can use to test the fix and make sure it works?
<hubH> I have the sample file
<hubH> shall I attach it?
<infinity> hubH : If you consider it a bit too much disclosure to attach an exploit )some pepole do), you can mail it privately to our security officer (martin.pitt@ubuntu.com), if not, attach it.
<infinity> Up to you, you're more aware of the severity of the bug than we are at this point.
<hubH> the document just exhibit the buffer overflow
<mdz> Kamion: is the current install set a colony candidate?
<hubH> but for it you can still find a way to execute code
<hubH> s/for/from/
<hubH> I don't mind attaching it
<Kamion> mdz: the one I just published, yes
<infinity> hubH : Alright, then just attach it, if you figure it's not much risk to do so.
<Kamion> the live CD is building now
<mdz> yeah, noticed the live build
<infinity> hubH : Having something to verify the fix always makes us feel a bit better, so we can actually test the various builds. :)
* Kamion goes for dinner while it rsyncs
<hubH> infinity: done
<infinity> hubH : Note that abiword is in our "universe" repository, which isn't officially supported, but given the reasonable popularity of the product, I'll probably find some spare time in my off-hours to update it if Martin doesn't have the time.
<infinity> hubH : Thanks again for the heads-up.
<\sh> infinity: sounds like you apply for a job in our motu security team ;) 
<bddebian> heh
<infinity> \sh : Nah, I'm too picky about what I will and won't update. :)
<ogra> \sh, i rather think hubH applies...
<infinity> (Okay, I'm not serious about that, I'll do just about anything, if I have some free time)
<hubH> ogra: I just fixed the problem as upstream
* bddebian decides not to comment on that :-)
<ogra> \sh, at least we can paster him about at UBZ i bet ...
<infinity> \sh : Are you guys planning on discussing better Universe security coordination at UBZ?
<hubH> ogra: I sort of apply for MOTU as my first package has been uploaded last night :-)
<\sh> infinity: hmm...good idea :)
<ogra> hubH, i know ;)
<\sh> hubH: wow...we need you :)
<ogra> infinity, i think ajmitch planned a BOF
<hubH> I'll be at UBZ
<infinity> \sh : I tend to update Universe packages that I also maintain in Debian (apache, php, etc), but I wouldn't mind doing more universe security work, if it was reasonably well coordinated with you guys so we weren't stepping on toes.
<hubH> since I'm local
<ogra> hubH, really looking forward to meet you gain :)
<ogra> again even
<slomo> what happened to gtkpbbuttons?
<\sh> infinity: we should discuss this really at UBZ...I think it's important to discuss the matter "3 years support for Ubuntu". Actually I don't really know, if this should apply to universe/multiverse as well...
<elmo> err, it doesn't
<infinity> \sh : {Multi,Uni}verse in dapper will be a whole different kettle of fish from main.  We may even want to discuss allowing limited updates to Universe in dapper's lifecycle, as RedHat does with the "contrib" archive.
<\sh> elmo: why not? we could even tighten the packages we could support (clamav is a good example)
<hubH> ogra: have we met?
<elmo> \sh: the whole point of main/universe is that main is what we support
<ogra> \sh, since universe will be locked down with the distro at release, we should have a possibility to upgrade and sbmit security fixes, but i tink that should somehow be meixed with backports in case of universe
<infinity> \sh : The "18 months support" already doesn't cover universe, why would the "3/5 years"? :)
<ogra> hubH, i sat behind you at guadec while you shot hundrets of pics from mark at his talk... i'm the long haired guy with ubuntu shirt
<hubH> ogra: ah ok
<\sh> elmo: which is officially supported by the Foundation...but there are some packages which are used by server admins...and they're in universe...so we should think about it
<hubH> ogra: I remember
<\sh> infinity: I know ... it's an idea..
<hubH> btw, abiword is in main AFAIK
<elmo> \sh: no, we shouldn't.  either they're supportable, or they're not
<hubH> not in universe
<\sh> elmo: k
<elmo> \sh: if they're supportable and worth supporting, they should be in main
<ogra> hubH, and i really appreciate your work on all the gnome photo suff since a long time
<\sh> elmo: right..yeah...
<hubH> ogra: thanks
<elmo> trying to blur the bounday of "not supported" to some neverneverland of "not supported, but might be on a good day.  depending on the package and strength/direction of the wind" isn't cool
<\sh> oh god...that means more paperwork for me during the next release cycle..and more involvement in the server team
* \sh needs to quit his job
<ogra> yay
* bddebian too
<ogra> \sh, DOIT ! they just abuse you and you know that...
<bddebian> heh
<\sh> ogra: btw...greetings from branislav :) 
<ogra> bddebian, i'm not joking...
<\sh> bddebian: he's right
<bddebian> Isn't that what all employers do? :-)
<ogra> \sh, thanks, say hi from me if you meet him
<ogra> bddebian, not in this way
<\sh> ogra: he's onsite the next week...looks like we will have a drink tomorrow.
<ogra> great
<\sh> bddebian: the only thing which stops me from doing quitting the job, that I have some responsibilities moneywise..and living from the state means "living like robin hood in germany"
<\sh> cause my bank will hunt me down...and even when I'm in the deepest forrest of south america, they will find me ;)
<infinity> hubH : Looks to be in universe to me...
<elmo> infinity: abiwor'ds in main
<elmo> abiword-gnome | 2.2.9-1ubuntu1 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> hubH : Oh, "abiword" is in universe, "abiword-gnome" in main.  Yay, confusion.
<elmo> which means the source is in main
<infinity> I should stop searching on binary packages.
<\sh> elmo: btw...can I send u an email with all syncs i need? (but you can do them next week when u have time)
<elmo> \sh: yes
<\sh> elmo: great..thx
<bddebian> \sh: Ahh :-(
<ogra> \sh, can you put sylpheed-claws in that mail ? its the last on my sync list
<elmo> \sh: just be sure to follow the guidelines on Developer_Resources or whatever the wiki page is
<\sh> una momenta
<\sh> elmo: ??? 
<hubH> sylpheed-claws-gtk2?
<ogra> yup
<\sh> elmo: universe packages...which are checked by me..yes :)
<hubH> the upstream maintainer would love to see it there
<hubH> and replace the gtk1 version :-)
<ogra> \sh, sylpheed-claws-gtk2 is the right name i think
<hubH> it is the name in debian
<\sh> ogra: I'll check...starting tomboy
* hubH has debian here at work
<ogra> hubH, i think if they can exist both we should leave the gtk1 version in... i still knw some users of it
<\sh> elmo: i don't request syncs for main ;)
<hubH> ogra: use using gtk1 in ubuntu should consider upgrading to gtk2 
<hubH> tht is just my opinion
<elmo> \sh: so?
<ogra> hubH, mine too, but ask people with PII/64MB about it ;)
<elmo> sh: https://wiki.ubuntu.com/DeveloperResources is about all syncs
<hubH> ogra: they might not use ubuntu then
<\sh> elmo: yes...but I don't need approval of mdz for universe ;)
<hubH> ogra: my workstation used to be a PPC 240 MHz with 128MB
<ogra> hubH, some do... we'll have a ubuntu-lite version in dapper
<hubH> ogra: and my laptop is a G3/400, so I know about slow machines
<hubH> ogra: ok
<elmo> \sh: ... the guidelines very specifically qualify approval needed for being main only
<\sh> approval...yes there was another thing
<elmo> \sh: in any event, you're missing the point
<hubH> ogra: make sense
<hubH> ogra: but to follow the logic, abiword 1.0 isn't in ubntu
<hubH> :-)
<\sh> elmo: the what, version, where from is obvious :) and I'm checking every package before I request (ok oo2c is one exception, regarding the fact, that changelog says something else)
<\sh> elmo: "I'll follow the rules" short answer :)
<ogra> hubH, i'll ask vedran about it, he made the app selection for ubuntu-lite in his SoC project, i think he said it has a way smaller footprint... for now another package in universe wont do ay harm
<ogra> any even
<hubH> agreed
<jcohen85> since upgrading to firefox 1.0.7 i'm seeing a large grey bar under the status bar (perhaps 4-5x the height of the status bar) with a red arrow on the left side. I can't get rid of it. I've restared firefox, got rid of the status bar, and even purged & reinstalled firefox. Any idea what's causing this? 
<hubH> my GF use Ubuntu on a PII 266/256MB
<hubH> when je does not use Win on the P166 96MB laptop
<hubH> s/je/she/
<ogra> phew
<dholbach> go ubuntu! go! :)
<ogra> :)
<\sh> mdz: I'll nerve u again, but only to get this from my todo... amarok-1.3.2...any decision? (my opinion: let's leave it at 1.3.1, because riddell/I have enough things to work on)
<Riddell> my opinion is for 1.3.2, else people will complain about oss
<hubH> and I must admit Win2k was snappier on this PII 266
<hubH> including Firefox
<hubH> (as to compare the comparable)
<\sh> Riddell: they can use xine to have alsa..then they have as well fading
<bddebian> Man building axiom sucks
<\sh> k...my todo is completly checked for today...going to bed :) cu tomorrow
<slomo> where's pitti? does someone know if he would have something against me fixing gtkpbbuttons?
<tseng>  its in universe?
<ogra> slomo, 
<ogra> fix it if its in universe
<slomo> yes... it's universe
<tseng> hm, i dont see why you shouldnt fix it
<hubH> slomo: waht is the problem?
<hubH> slomo: because I use it too
<slomo> i don't know yet... it's uninstallable ;)
<slomo> i'll take a look
<hubH> ah
<pablof> how i create new project in launcpad ? i'm not find out a link
<ogra> pablof, #launchpad
<pablof> ogra: ok
<spstarr_work> j^: Here? ;)
<j^> spstarr_work no
<mvo> Kamion: I assume no uploads to main right now because of colony?
<ogra> mvo, only with approval ;)
<axl> Hi there! Any problems with udev t the moment?
<axl> My computer wont display any lines during boot
<axl> and x does'nt show up
<spstarr_work> known what version / kernel -> #ubuntu
<axl> at*
<axl> okey
<mvo> hey doko 
<mvo> how is oldenburg?
<bddebian> pamphlet better fscking build this time..
<ogra> mvo, full of chicken farms ;)
<Kamion> mvo: right - although *hopefully* I'm nearly done, but I haven't tested this round of builds yet so I'm not certain I won't have to rebuild for something
<mvo> Kamion: no problem, just asking. so the current stuff should be rsynced, tested?
<doko> mvo: well, interesting. seeing that we are not alone with our java issues ... :-)
<doko> ogra: I'm not visiting your farm house ...
<dholbach> have a nice evening, i'm out for a beer
<sivang> ogra: btw, I'm also going to have a birthday in UBZ ;-)
<Kamion> mvo: yes please
* mvo rsyncs
<ogra> doko, youre way to northern to visit me ;) 
<ogra> doko, but i grew up in hannover, all eggs came from oldenburg in my childhood :)
<ogra> sivang, YAY, lets party ;)
<sivang> ogra: uh ha :) I'm one day or two after jbailey 
<ogra> great
<Keybuk> Kamion: live 20050923.1 is oversized?
<Keybuk> (i386)
<Keybuk> cute new syslinux splash <g>
<dilinger> hm, no pitti :/
<dilinger> anyone here w/ access to vendor-sec?  i'd like to know if a vuln has been made public yet
<ogra> Keybuk, even for the custom distros (edu/kubuntu) ;)
<slomo> elmo: please sync cowbell 0.2.4-1 from debian/unstable... it's the same version as our -0ubuntu1
<sistpoty> ping elmo
<Keybuk> Kamion: 20050923.3 install i386 worked ok for me
<thesaltydog> ogra, the bug concerning blank console with vga=791 has been fixed (#16118) It was a bug in initramfs-tools
<ogra> thesaltydog, ah
<sistpoty> elmo: nevermind, i wrote you a mail ;)
<slomo> infinity, lamont? does someone of you know why gtkpbbuttons only builds the gtkpbbuttons binary package and doesn't build -common and -gnome? works for me in my pbuilder :(
<lamont> slomo: do the logs show any differences?
<slomo> lamont: ah... i lied... only -common isn't built... -gnome is but probably waits in NEW
<slomo> lamont: gtkpbbuttons is ppc only... and the -common package is arch all... maybe that is the problem as the all stuff is built on x86?
<slomo> lamont: i could try with arch ppc for the -common package... but that can't be the solution ;)
<Kamion> Keybuk: live oversized> ngah. it'll have to do for now.
* Kamion begins the 6x burn+test cycle
<Kamion> slomo: NEW's empty.
<Kamion> gtkpbbuttons | 0.6.7-3build1 | breezy/universe | source, powerpc
<Kamion> gtkpbbuttons-gnome | 0.6.7-3build1 | breezy/universe | powerpc
<slomo> Kamion: my mistake... the -gnome package is there...
<Kamion> I don't see a -common package
<slomo> Kamion: -common is arch all... and the arch all stuff is build on x86... but gtkpbbuttons ftbfs on x86 (naturally)
<Kamion> oh, right, hmm
<Kamion> that's probably a packaging bug; if it's arch: all, it should really be buildable on any architecture
<Kamion> is there any actual reason for it to be arch: all? does anything non-arch:powerpc depend on it?
<slomo> it's arch all because it only contains arch independend files
<slomo> but that's the only reason
<Kamion> hmm, I think the answer is to arrange for the binary-indep target not to depend on the build target
<Kamion> since the build target is arch-dep
<slomo> hmm
<slomo> sounds to complicated imho... can i just set it to arch powerpc?
<Kamion> there's an optional build-indep target defined in case binary-indep wants to do any build-like things
<Kamion> it's not complicated
<Kamion> it's correct
<slomo> ok i'll take a look again
<Kamion> however arranging to get the right files installed might be a little tricky
<Kamion> so setting it to arch: powerpc is an acceptable workaround if you can't do that - but in that case please ask the Debian maintainer to sort it out properly
* Keybuk wishes there were a rsync --go-faster
<Keybuk> is sad when you only have 10Mbps wired on your desktop, but 54Mbps wireless on your laptop; so copying between the two takes too long <g>
<slomo> Kamion: sure, i'll send him a mail... it should be too complicated to fix it the right way... configure will fail, so we have no makefiles... and even when we have makefiles it will fail compiling so we would have to install all stuff by hand
<sivang> I;m out all, laterz
* Kamion tries out the auto-resizer with an actual Windows partition for a change
<Keybuk> Kamion: is live not intended to use usplash?
<ogra> sigh...
<ogra> Mez !
<ogra> backports broke a hell lot of systems with their firefox backport
<mvo> Kamion: i386 is fine here
<tseng> so who has ideas on why capability module isnt loaded anymore?
<tseng> it breaks at least ethereal
<Kamion> Keybuk: it's supposed to
<Keybuk> oh, it does, just not until casper has finished
<Kamion> and did the last time I checked
<tseng> and anything else that tries to drop caps
<Kamion> ah, yes
<Kamion> can't really do it earlier at the moment
<Keybuk> cool
<Kamion> was hard enough to get it working this way ;)
<Keybuk> well, 20050923.1 live i386 wfm
<Kamion> hoorah
<Keybuk> my amd64 doesn't come for a few more weeks, and don't yet have ppc hardware, so that's all I can test <g>
<Kamion> install/amd64 and install/i386 are both looking plausible so far
<Kamion> pearpc? ;)
<Kamion> (bloody slow, mind)
<Kamion> and I confess to not having tried an installation in it ...
<Keybuk> I might actually try and find a cheap ppc on ebay or something at some point
<Keybuk> probably after UBZ
<Keybuk> just for testing shit on
<Kamion> having multiple architectures is nice
<Kamion> though it did make me replace the last compiled binary from ~/bin with a perl script in sheer annoyance
<Kamion> never worked out why there's no standard version of that script in coreutils - it's a thing that works a bit like sed -i or perl -i to let you modify a file in-place, but you can use it at the end of a longer pipeline whose commands don't have to support in-place editing like that
<Keybuk> explain?
<Kamion> so you do "sed 's/foo/bar/g' < foo | tr -s ' ' | cut -d: -f2 | sponge foo"
<Keybuk> heh
<Kamion> if you just did "sed 's/foo/bar/g' < foo | tr -s ' ' | cut -d: -f2 > foo", then the output redirection to foo would happen and truncate the file before the first command in the pipeline had a chance to read from it
<Keybuk> indeed
<Kamion> so sponge sucks up all its input, *then* opens the file you give it and squeezes it all out
<BenC> ddd/topic
<Keybuk> Kamion: see, this is why I use zsh
<Kamion> what does it do?
<Kamion> apart from "everything"
<Keybuk> there are various cute redirection tools
<Keybuk> like <>foo
<Keybuk> (open for reading and writing)
<Kamion> ah, right
<Chipzz> Keybuk: does that actually work? :)
#ubuntu-devel 2005-09-29
<Keybuk> and it does implicit pipes if you want it to
<Kamion> adverbio is an interesting idea for this sort of thing too, which helps when you're using sudo
<Kamion> though it's a bit verbose
<Kamion> http://www.greenend.org.uk/rjk/2001/06/adverbio.html
<dobwan> what is the server for the US breezy apt update? I have it as us.archive.ubuntu.com. (I know this is probably not the right place to ask this, please forgive me)
<Kamion> yes, that's the right place. #ubuntu would be a better channel
<Kamion> mdz: do you know if initramfs-tools 0.29 is C5-critical?
<Kamion> frustratingly, I can't quite tell, and jbailey does not seem to be around
<mvo> Kamion: would a synaptic upload now hurt? or should I wait until tomorrow?
<Kamion> I'm starting a new build now just in case
<Kamion> mvo: please don't
<Kamion> tomorrow
<Kamion> the topic has not changed
<mvo> ok then :)
* mvo is impatient sometimes
<Kamion> I'm sorry to keep everybody waiting for uploads, but I'm fourteen hours into an extremely long day here
<Kamion> and I do not want it to continue into tomorrow
<mvo> sure, no problem. I didn't wanted to sound pushy or something
<slomo> elmo: please remove gtk-sharp-gapi-unstable and gtk-sharp-examples-unstable
* mvo hopes that "pushy" is actually a english word
<Kamion> it is
<Kamion> the errors in your sentence were "didn't wanted" => "didn't want" and "or something" => "or anything"
<Kamion> HTH ;-)
<mvo> Kamion: yes, thanks :) 
* mvo grumbles about this foreign languages
<ogra> Kamion, i know initramfs-tools 0.29 fixes a bunch of vmware issues
<ogra> mvo, lets do a german BOF at UBZ to teach all these strange people german
<ogra> ;)
<ogra> mvo, then they have to know what "drngeln" means ;)
<mvo> ogra: that will teach them a lesson ;)
<ogra> hehe
<tseng> elmo: please remove kurush while you are at it, its broken and will be orphaned in debian
<Kamion> ok, powerpc really isn't happy with installing to XFS
<slomo> Kamion: why? works here
<Kamion> slomo: not sure yet
<Kamion> slomo: on powerpc?
<slomo> Kamion: yes... ibook g4
<slomo> Kamion: current breezy install and kernel only fails because of other problems...
<slomo> but older kernel works
<ogra> slomo, he's talking about the current build that shall become a colony release
<Kamion> elaborate on "other problems"?
<slomo> Kamion: http://bugzilla.ubuntu.com/show_bug.cgi?id=14485
<Kamion> hmm, yes, I'm seeing the same thing
<slomo> wonderfull... so we're 3 now ;) did you tried another fs?
<Kamion> if it's only XFS I can errata it
<Kamion> no, but I'm about to
<Kamion> BRB
<slomo> ok
<Burgundavia> Kamion, does apt have a way to build something but avoid pushing it the public archives before another package builds? (Ie, with mozilla/epiphany and linux/l-r-m)
<Burgundavia> Kamion, that would allow seemless upgrades
<Kamion> that's got zero to do with apt
<Burgundavia> ok
<Burgundavia> is that possible?
<Burgundavia> is it worth the effor developing>
<Burgundavia> ?
<Kamion> not without the equivalent of Debian testing, which we've explicitly decided not to use
<Kamion> (for various reasons)
<Kamion> it's not really worth the effort because it only affects development releases
<Burgundavia> my thought was just for a select few packages
<Kamion> s/releases/trees/
<Burgundavia> and I am talking a matter of hours
<Kamion> special-purpose hacks are usually even less worth it
<Kamion> anyway, sorry, I'm extremely busy
<Burgundavia> Kamion, ok, just a thought
<Kamion> it also doesn't work for linux/l-r-m because l-r-m requires linux to be in the archive first before you can build it
<Kamion> and I believe the same goes for mozilla/epiphany
<Burgundavia> ugh
<Kamion> the buildds don't build from anything private, just the public archive
<Kamion> which is good, 'cos you can test things properly before uploading
<ivoks> hi
<ivoks> anyone? i have one suggestion for libdvdread3
<slomo> Kamion: can you add a comment to the bugreport after further testing?
<slomo> ivoks: what suggestion?
<ivoks> slomo: k3b searches for libdvdcss.so
<Kamion> slomo: not tonight, but yes I will later
<Kamion> slomo: works fine with ext3, fyi
<ivoks> slomo: and install-css.sh provides libdvdcss.so
<ogra> ivoks, its illegal
<ivoks> slomo: so, links should be created in that script
<ivoks> illegal?
<slomo> Kamion: ok, i'll talk to jbailey and BenC tomorrow about it... maybe we get this fixed somehow for breezy :/
<ogra> yup
<slomo> ivoks: libdvdcss is nothing for us ;)
<ivoks> ogra: to create link?
<ivoks> slomo: i know, but...
<slomo> ivoks: what link do you want to create?
<ivoks> we provide that script
<ivoks> slomo: ln -s /usr/lib/libdvdcss.so. /usr/lib/libdvdcss.so.2
<ivoks> one . too many :)
<slomo> ivoks: a link to a non-existing file?
<ivoks> slomo: read from begnining
<ivoks> we provide install-css.sh
<ogra> where do you get /usr/lib/libdvdcss.so.2 ?
<ivoks>  /usr/share/doc/libdvdread3/examples/install-css.sh
<ivoks> there
<slomo> ivoks: yes... and...? ;) we don't provide the library itself
<ivoks> that's main package
<ivoks> slomo: but we provided installer for it
<slomo> ivoks: but i would fix k3b or whatevery tries to read libdvdcss.so to look for libdvdcss.so.3
<slomo> ivoks: libdvdcss.so.2 even
<ivoks> right :)
<slomo> ivoks: or change the script to make a link... but everything else is braindead ;)
<ivoks> that's what i'm talking about
<ivoks> just change script
<ivoks> not lib
<slomo> ok... but better do the other fix
<Keybuk> Kamion: tsk, tsk; leaving ,,undo-1 files in source packages
<slomo> let whatever wants to read libdvdcss.so to look for libdvdcss.so.2
<Kamion> Keybuk: which?
<ivoks> slomo: or that :)
<ivoks> slomo: but first one was easier :)
<Keybuk> Kamion: cdrom-detect
<slomo> ivoks: is the better solution imho... .so files should only be in -dev packages
<Kamion> Keybuk: oops; willfix later
<ivoks> slomo: whatever...
<ivoks> :)
<Keybuk> Kamion: I'll do it, if I can understand these bugs mdz has given me
<slomo> ivoks: but while you're at it... tell the libdvdcss hoster to put 1.2.9 packages on his webspace and change the script to use these ;)
<ivoks> slomo: i noticed only k3b requesting libdvdcss.so
<ivoks> slomo: what's libdvdcss? :>
<ogra> i think we should rip out that script completely if it silently installs illegal software on your system
<slomo> ivoks: are you sure it isn't loaded in libdvdread?
<slomo> ogra: it warns about it and must be called by the user
<slomo> ivoks: libdvdread uses libdvdcss when it is installed... so i suspect the problem there
<ivoks> decss isn't illegale everywhere
<ogra> ok, if it warns and explicitly says that you go in jail in the US and various other countries, then its fine
<ogra> ivoks, i only know norway...
<ogra> its illegal in most other countries...
<ivoks> slomo: k3b said it misses libdvdcss
<ivoks> ogra: one is enough, isn't it?
<slomo> ivoks: i looked at libdvdread and it opens libdvdcss.so.2... so fix k3b ;)
<ogra> ivoks, not really, i'd rip out that script
<slomo> ogra: what about cuba? ;)
<ivoks> ogra: no problem, fine with me
<ogra> yes, probably cuba :)
<mjg59> Wow. My cheap random USB wireless thing supports being an access point
<mjg59> (Under Windows, at least)
<ogra> ivoks, its a question if we want to bring users in suspectable legal situations...
<Keybuk> ... I guess now is a good time to learn debconf and d-i :p
<Keybuk> and here was me being proud of being one of the last people in the world to learn debconf
<ivoks> ogra: i understand, i don't object
<ivoks> ogra: i just noticed that we have it and it doesn't work ok in one program
<slomo> ogra: iirc it is also written in the wiki... but it's written there to use marillat's packages which are newer
<ivoks> so, we should fix it or remove it
<ogra> yup
<slomo> ivoks: just fix k3b... and write a mail at -devel whether the script should be removed ;)
<ivoks> i will not do that
<ogra> ivoks, yu brought it up
<ivoks> i know
<ivoks> but...
<ivoks> mailing lists are public
<ogra> yes, as this channel is...
<ivoks> maybe we should come to a solution without ringing with this...
<ivoks> ogra: yes, but less people watch it
<ogra> write a mail
<ivoks> ok
<ogra> lets have it discussed to get a solution
<ogra> the script itself isnt illegal as you said, so we can discuss it as public as we want...
<Kamion> Keybuk: if you're going to hack cdrom-detect, please branch from colin.watson@canonical.com--2005/cdrom-detect--ubuntu--0 so that I can merge it later
<Keybuk> I'm not sure I understand how it works enough to hack it :-/
<Kamion> Keybuk: are many of the alleged cdrom-detect bugs actually cdrom-detect bugs, though? I thought most of them were kernel bugs
<Kamion> I don't understand it all that well
<Keybuk> dunno, #15642 and #15691
<ivoks> now... time for bed
<ivoks> see you
<slomo> ok, good night everybody :)
<ogra> night
<Keybuk> hmm, well, it looks like it just loads all the modules and hopes that /dev/cdroms turns up
<Keybuk> ugh @ how devfs specific that is
<Kamion> yes, cdrom-detect is definitely a repository of devfs assumptions
<Kamion> doesn't it call udevstart though (perhaps via hw-detect)?
<Kamion> hw-detect calls udevstart as the last thing it does, pretty much
<Kamion> anyway, bored now; /me starts the release process
<Kamion> I'm 6 for 6 on testing, apart from the annoying powerpc/xfs bug
<Kamion> grr at cron.daily running on the live CD
<jdub> GOOD MORNING FREEDOM LOVERS
<jdub> Kamion: heh
<jdub> Kamion: "good morning" :-)
* Kamion races against his soon-to-vanish ADSL link
<Kamion> playing it fast-and-loose - I'll send the announcement slightly before it's synced to mirrors. please field any complaints for me, I couldn't do any better with the link about to vanish
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Colony 5 released
<BenC> Kamion: you reproduced the ppc-xfs-init bug?
<Keybuk> can I break udev now? :p
<BenC> Kamion: did it stop at VFS...unknown_block(0,0)?
<zyga> good night everyone
<apokryphos> Kamion: is there a page with the anouncement of Colony 5's release?
<jdub> mjg59: ping
<mjg59> jdub: Hi
<jdub> yo mjg59 
<jdub> mjg59: did your ir autolove get into breezy?
<mjg59> jdub: Yeah
<mjg59> It's not part of ship or desktop though, AFAIK
<jdub> oh, package name?
<mjg59> irda-utils
<jdub> irda-utils?
<jdub> ah
<jdub> thanks
<jdub> a friend blogged about a good experience with bluetooth, not so good experience with ir - wanted to point him to your work :-)
<mjg59> Heh
<jdub> oh, i already have it
* jdub wonders if pilot-link does irc
<jdub> er
<jdub> ir
<jdub> eek.
<jdub> ha ha
<jdub> mjg59: <jaq> is this another "it works in breezy" thing? :)
<mjg59> Heh
<mjg59> Aww. usplash.
* mjg59 feels his heart warmed
<jdub> he did upgrade for 2.6.12, multiple drivers he needed
<Keybuk> jdub speaking like yoda now he is?
* mjg59 is down to about 150 bugs
<Keybuk> so what does irda-utils do?
<Keybuk> doesn't do anything for me :'(
<mjg59> Keybuk: It autoconfigures your irda on startup
<jdub> $ lsmod | grep irda | wc -l
<jdub> 0
<jdub> hrm
<Keybuk> syndicate scott% lsmod | grep irda
<Keybuk> irda                  187612  5 ali_ircc,irtty_sir,sir_dev
<Keybuk> crc_ccitt               1984  1 irda
<Keybuk> but it still does nothing
<mjg59> Keybuk: Who loaded those modules?
<Keybuk> not me
<mjg59> That would appear to imply that it worked, then
<Keybuk> irdadump doesn't see anything when I wave my phone at it
<jdub> hrm
<mjg59> Is irattach running?
<jdub> i have no AUTOMATIC in default/irda-utils
<jdub> but init.d/irda-setup checks for it
<mjg59> jdub: Ah. That would probably be your problem.
<mjg59> That's generated by debconf magic on install - I wonder what it does if you already have a file. Probably the wrong thing.
<Keybuk> mjg59: no
<Keybuk> irda-utils start claims to start it, but doesn't
<mjg59> Keybuk: Do you have a /var/run/irdadev ?
<Keybuk> yes, it contains "irda0 fir"
* jdub does a reinstall
<mjg59> Does /etc/default/irda-utils contain AUTOMATIC="true"?
<Keybuk> it does
<mjg59> Does irattach irda0 -s work?
<Keybuk> it returns immediately with exit 0
<mjg59> Right.
<mjg59> What does dmesg say about ali_ircc?
<jdub> mjg59: --reinstall does not give it love
<Keybuk> the last thing it called was clone()
<Keybuk> [4420999.099000]  ali_ircc_open(), ali-ircc, Found dongle: HP HSDL-3600
<Keybuk> [4421002.582000]  ali-ircc, unable to allocate dma=1
<Keybuk> [4421002.582000]  Trying to free free IRQ3
<Keybuk> [4421214.643000]  ali-ircc, unable to allocate irq=3
<mjg59> Hm. Ok.
<mjg59> Keybuk: What does setserial /dev/ttyS1 say?
<mjg59> Oops.
<mjg59> jdub: Can you try --purging it?
<jdub> hopefully that was a kernel crash you get to debug :)
<jdub> mjg59: yeah, doing now
<jdub> yay, i have automatic
* jdub restarts
<jdub> hrm
<jdub> + . /etc/default/irda-utils
<jdub> ++ ENABLE=false
<jdub> ++ AUTOMATIC=true
<jdub> ++ DISCOVERY=true
<jdub> ++ DEVICE=/dev/ttyS1
<jdub> ++ DONGLE=none
<jdub> ++ SETSERIAL=
<jdub> 
<jdub> that look sensible?
<mjg59> Yup
<jdub> + cd /sys/bus/pnp/devices
<jdub> + IRDA=0
<jdub> + STATEFILE=/var/run/irdadev
<jdub> + case $1 in
<jdub> + for x in '*'
<jdub> + FIR=false
<jdub> + SIR=false
<jdub> + FALLBACK=true
<jdub> + OPTIONS=
<jdub> 
<jdub> then a lot of loops with FIR/SIR=false
<mjg59> jdub: Do you get a /var/run/irdadev ?
<jdub> nup
<mjg59> Is IR enabled in your BIOS?
<Keybuk> mjg59: and after pasting that, my machine decided to hang <g>
<jdub> ah, *believe* so
<mjg59> Dell seem to disable it by default
<jdub> 10:29 -!- Keybuk [n=scott@syndicate.netsplit.com]  has quit [Read error: 104 (Connection reset by peer)] 
<jdub> 10:30 < jdub> hopefully that was a kernel crash you get to debug :)
<mjg59> Keybuk: What does setserial /dev/ttyS1 give you?
<jdub> 10:29 < mjg59> Oops.
<jdub> :-)
<Keybuk> it wasn't even a crash :-/
<Keybuk> /dev/ttyS1, UART: 8250, Port: 0x3440, IRQ: 11
<mjg59> Wow. That's, uh, interesting.
<Keybuk> oh?
<mjg59> Ok. Can you find the directory in /sys/bus/pnp/devices/ that contains an id file that contains a string starting ALI?
<Keybuk> /sys/bus/pnp/devices/00:03/id:ALI5123
<mjg59> Can you cat /sys/bus/pnp/devices/00:03/resources ?
<Keybuk> state = active
<Keybuk> io 0x3e8-0x3ef
<Keybuk> irq 3
<Keybuk> dma 3
<mjg59> And cat /proc/tty/driver/serial | grep 3e8
<mjg59> (Or grep 3e8 /proc/tty/driver/serial - I changed my mind halfway through that)
<Keybuk> none
<mjg59> Interesting.
<Keybuk> ttyS1 doesn't match the ALI5123 resource ... and the ali_ircc is trying the wrong dma? :p
<mjg59> The real problem here is that ali_ircc doesn't give ENODEV if it fails to bind
<mjg59> But it does also seem to be picky about the IRQ
<mjg59> I'll think about that
<mjg59> jdub: Do you have anything in /sys/bus/pnp/devices/ that contains an id file with either PNP0510 or PNP0511?
<jdub> nup
<jdub> looks like i'll have to reboot
<mjg59> Yeah, looks like your BIOS isn't enabling it
<jdub> fascist dell bios!
<bddebian> heh
<jdub> can't kill pipka's session though, so will have to play later
<tiglionabbit> when is the earliest I can request CDs to get the official Breezy Badger release?  And what cover art are they using?
<Lathiat> pkg: error processing /var/cache/apt/archives/x-common_1.08_all.deb (--unpack): trying to overwrite `/usr/lib/X11/fonts', which is also in package xfonts-base
<Lathiat> hrm
<Lathiat> hrm
<Lathiat> its permanant too
<Lathiat> not a disordered upgrade problem
* lamont wonders where libaio comes from, and if he cares enough to work on fixing it for hppa yet.
<`anthony> should the bugzilla package names be updated to include new breezy packages? for instance, I just tried to log a bug against gnome-phone-manager...
<wasabi> It's cool when you can stumble over random software packages that happen to provide Ubuntu Hoary .debs
<elmo> `anthony: gnome-phone-managers in universe; you should bugs in packages in universe in malone (http://launchpad.net) rather than bugzilla
<bddebian> Nooo no more Universe bugs :-)
<elmo> (s/bugs/report bugs/)
<`anthony> elmo: hm. my bad - should the bugzilla bug report page tell you this?
<`anthony> I don't recall seeing it anywhere when logging a bug.
<elmo> "Ubuntu:   The Free operating system for everyone - choose this to report any issues with software in the main and restricted components"
<elmo> it's not very explicit, but it tries
<`anthony> "For bugs in universe or multiverse, please log bugs in <a href="http://launchpad.net">lunchpad</a>" - maybe on the 'enter new bug' page.
<`anthony> I'd suggest putting the text under the 'package' widget.
<`anthony> But then, I'm not the poor bastard who has to work on the bugzilla code to make that change.
<elmo> yeah, I don't know how modifiable that is in bugzilla, or who even would
<`anthony> bugzilla: "down, not across"
<elmo> haha
<`anthony> it's funny cos it's not me ;)
* bddebian flushes gnat-gps and debtags-edit down the toilet
<fabbione> lamont-away: no you don't really care about libaio and no it's not worth fixing it yet
<Amaranth> *groan*
<bddebian> ??
<Amaranth> someone using the forums to post to ubuntu-devel things mandriva is going to buy or merge with ubuntu
<bddebian> Egads, I hope not :-)
<Amaranth> this is an example of why the forums shouldn't be able to post to ubuntu-devel ;)
<ajmitch> Amaranth: I must have missed that one?
<bddebian> Aye
<Amaranth> in the dapper drake thread
<jdub> mjg59: unlikely ping
<jdub> jbailey: unlikely ping
<dhonn> i converted the firefox folder into a compressed iso, mounted it, it loads in 3.1 seconds vs 7.0 seconds uncompressed  and thats under a clean boot conditions
<dhonn> tired it to OOo 9.9 vs 12.8 seconds,  i wonder what we could do with this
<infinity> That's a classic example of "more CPU than I/O", which is likely true of many computer, but certainly not all.
<infinity> s/computer/computers/
<sivang> Good morning all :)
<infinity> But you can run your whole OS on a compressed filesystem, if you find you have more idle CPU than idle I/O. :)
<dhonn> yes on a 700mhz celeron there is no benefit at all
<sivang> infinity: do you know if we are going to offer some support to "legacy" nvidia devices through l-r-m?
<dhonn> im running a 1.5mhz sempron right now
<infinity> sivang : We do.
<dhonn> i then compressed the whole /usr/lib folder lol, ubuntu loaded quickly
<sivang> infinity: ah, how do I enable this? ;)
<infinity> sivang : Install linux-restricted-modules-`uname -r`-nvidia-legacy and nvidia-glx-legacy
<sivang> infinity: ah very very cool. Since when is it there?
<infinity> A few days. :)
<infinity> sivang : Given their shiny newness, more testing of those packages is welcome.
<infinity> sivang : They got off to a bumpy start, but they SHOULD be okay now.
<infinity> (For some value of "should" that means "I'll cry, if they're still broken in some way")
<sivang> infinity: that's exactly what I'm installing now :)
<sivang> infinity: will let you know of any weirdness, hopefully my system won't break to much - Trying to fix #6224 and I don't have time to mangle with X right now ;-)
<infinity> I've only tested them on amd64, so if you're on i386, feedback is welcome. :)
<sivang> infinity: you're on!
<infinity> (Well, feedbackis welcome on amd64, too... But I don't even know if they WORK on i386, so it'd be nice to know)
<infinity> Note that you may want to reboot after install the new lrm stuff, especially if the other 'nvidia' module in the base lrm package wsas alrady loaded (it's notorious for not really unloading terribly well)
<sivang> infinity: it refuses to load on account of FATAL: Error inserting nvidia (/lib/modules/2.6.12-8-686-smp/volatile/nvidia.ko): No such device , this driver won't recognize my "old" gf2 gts, makes you wonder how fast things get deprecated in hardware..
<sivang> infinity: so I hope you're legacy one will do the trick
<ajmitch> sivang: strange
<infinity> sivang : Yeah, they dropped support for (at least) everything pre-GF3.
<ajmitch> infinity: what kernel got that driver?
<infinity> sivang : I need to get a more definitive list at some point, and put it in the package description.
<sivang> infinity: yup. I hope they are sleeping well at night with those direction decisions ;)
<sivang> nonetheless, I'm scared to find out the issues I'll have when I'll have my T43 with ati and reliant on fglrx
<infinity> ajmitch : Which?... The nvidia-legacy driver?.. We've been building it for the last few days, first kernel with avaialable nvidia-legacy stuff built against it was -8-, and now we have it built for -9-
<sivang> infinity: list of supported GPUs ?
<ajmitch> infinity: right, I was just wondering why my gf2 mx was still working with -8 
<sivang> infinity: ah , so I'll need to boot with -9
<ajmitch> without having the legacy driver loaded afaict
<infinity> sivang : My T43 works fine with the open source drivers, but a quick test of the latest fglrx shows it working too.
<sivang> infinity: oh, I recalled some people hjad problem with it, sudden hangups after a day of uptime etc
<infinity> ajmitch : Oh, they may have kept the MX in the supported list.  I think they dropped support based on age, not technology.
<sivang> yep, horray for them 
<infinity> ajmitch : So, despite the gf2gts being "better", it's older than lots of gf2mx boards, so it goes first.
<sivang> infinity: I Know that GTS Is GIga Texel Shader, what's MX  ?
<infinity> sivang : The MX is a (heavily) crippled GTS, that's all.
<infinity> sivang : Same tech, newer cards, slower performance, aimed at cheapskates.
<infinity> sivang : Most of my hanging issues with the T43 seem to have cleared up in more recent breezy... I won't commit to that statement yet, but things are much better than they were.
<infinity> sivang : I never have run fglrx, though (except to test it)
<infinity> Heck, fglrx didn't even work on the T43 until very recently (didn't work on most laptops until recently)
<infinity> s/most/many/
<sivang> hrm
<sivang> that's not enouraging if you want 3D ;)
<infinity> Like I said, should be okay now.
<infinity> It's not like the driver was fundamentally broken or anything, they just didn't have laptop modelines and such in the mainline driver.
<sivang> however, how is the desktop and plain non gamer's hacking activities on there? any performance issue due to a display bottleneck ?
<infinity> ATI finally merged their laptop series and desktop sries upstream into a unified branch, so all hardware seems to be reasonably well supported from one driver.
<sivang> infinity: hmm, it appears they also have it shipped with Intel Extreme Graphics adaptors - what do you think about those?
<infinity> With the open source driver, I'm reasonably satisfied, but the lack of PCIe acceleration does make tihngs a bit jerky at times.
<sivang> infinity: oh that's good. They should have done that from start, like nvidia
<infinity> The Intel stuff should work fine, but if you intend to plug in an external mouse and get your Quake on, forget it.  If you want occasioanl 3D, go with the ATI offering.
<sivang> infinity: in specific functionality where you experience jerky performance?
<infinity> Oh, just stuff like moving windows isn't as smooth as I'd like it, no big deal.  The open source driver and the X300 seem to mostly get along quite well now.
* ajmitch has one of those intel powerhouses for 3d
<infinity> It'll be a lot better in dapper (there's a LOT of work going into the radeon driver in Xorg upstream right now), but such is life.  Can't have everything shiny.
<ajmitch> anything more than ppracer is a challenge for it
<infinity> Yeah, Intel isn't noted for their stellar OpenGL performance. :)
<sivang> ajmitch: heh, someone claimed they're at least as good as the radeons ;)
<sivang> ajmitch: (a local computer shop)
<infinity> sivang : They had no idea what they were talking baout. :)
<pef> hello
<ajmitch> the 8MB shared mem doesn't bode well for performance either
<ajmitch> so I think they might have been exaggerating their claims 
<sivang> infinity: I think that sums it up, and what is better then helping to supprt more hardware with Ubuntu? it can even be fun, if things really get rough I can alwasy revert to my text terminals :)
<infinity> sivang : With the X3000 and fglrx, I can actually fire up doom3 on the T43, and it's playable.  So, yeah, it works.
<sivang> cool
<sivang> do you know fi the support is for all ranmge of the X's ?
<infinity> sivang : But if you don't really NEED fast 3D, the open source drive is quite stable and fine in 2D.
<sivang> or per specific model
<infinity> For fglrx, we should support everything.  For the open source driver, we support everything, but with varying levels of acceleration.
<infinity> Some cards (X850, maybe?) have some accel turned off by default in the open source driver right now, to avoid crashes.
<sivang> infinity: I don't need it;) just to be able to build packages quickly on it, do python stuff , etc. 3D acceleration is nice to havbe but not a must at the moment.
<infinity> But the X300 (which you find in the T43) is happy.
<infinity> sivang : Kay, then I recommend just letting the installer guess it all for you, it'll pick just fine, and the T43 should be happoy out of the box right now.  After buying a T43, that became a personal release goal. :)
<infinity> (Not that I had much to do with it, other than bugging other people to make it suck less, but whatever)
<sivang> infinity: hehe
<sivang> infinity: it's a nice slick machine, eh?
<infinity> I'm quite happy with it.
<infinity> And it's faster than any desktop I've ever owned.
<infinity> (Well, the girlfriend's amd64 is a bit faster, but she never lets me use it..)
<infinity> sivang : Oh, a tip, when you spec it, buy it with as little RAM as you possibly can, and then order 2GB of RAM from somewhere else.  IBM's RAM prices are insanely marked up.
<infinity> sivang : But the 2GB of RAM is very welcome, when you get it cheap. :)
<sivang> infinity: ofcourse. :)
<sivang> infinity: do they give some special brand of RAM?
<infinity> Mine shipped with Crucial/Micron RAM.
<infinity> What I slepped in was something a bit less "brand name", but it's perfectly happy wit hit.
<infinity> s/slepped/slapped/
<infinity> But even if you wanted to buy Crucial RAM for it, it's cheaper from crucial.com (by about half) than from IBM.
* infinity is reminded that he still needs to eBay the 512MB stick he pulled out of the T43 when he got it..
<sivang> infinity: heh
<sivang> infinity: re:amd64, what do you mean she never let's use it?? ;) one proc, dual core?
<sivang> infinity: can you send me your specs so I can base mine on yours?
<sivang> infinity: (email)
<infinity> I'll just find you the link.  That's simpler.
<infinity> Oh, they don't have my exact model displayed anymore.
<infinity> Anyhow, it's pretty much exactly this:
<infinity> http://www-131.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?productId=4611686018425075706&storeId=10000001&langId=-1&categoryId=2049168&dualCurrId=1000073&catalogId=-840
<infinity> But with a 2195 a/b/g wifi adapter, instead of the 2200 b/g one.
<infinity> 2915, even.
<infinity> Go with a 14.1 inch screen instead, if you want it to be a tiny bit smaller and lighter.
<infinity> The 15" is very pretty, though.
<sivang> I'd want only the 14"
<sivang> I had my time with heavy, non protable laptops :)
<sivang> I want this machine to be ultra protalbe for me
<infinity> Well, if you want "ultra-portable", maybe you should be shopping for an X series instead. :)
<infinity> But a T with a 14 inch display is reasonably small.
<infinity> (Spring the extra money for a 1400x1050 display, though, you'll thank me for it)
<sivang> X are much pricier, I'd settle for the T's
<sivang> infinity: thx for the tip, I'll keep that in mind
<infinity> X and T are in pretty much the same price range, it's just the the X are a lot slower for the same prices. :)
<sivang> infinity: then it's a T :)
<sivang> infinity: say, I'm playing with hotplug as per that bug I told you about before, I managed to make a script that runs everytime a usb printer is connected to the system, how can I trap it's disconnectino from it? 
<infinity> No idea.  I'm hotplug illiterate.
<infinity> I just curl up in a ball in the corner and cry when it doesn't work.
<sivang> heheh
<infinity> At a guess, though, this sounds more like a job for udev than hotplug, assuming these printers create/remove udev entries when they're plugged in.
<infinity> I'm told that udev.d hooks are saner.
<sivang> actually, my problem now is not actually the hook, assuming I will find a way to fire up the script when the printer is disconnected, but actually teaching cupsd to come back after a SIGHUP when it's running with an unpriviliged user (cupsys)
<infinity> sivang : A quick jaunt through hotplug.d would lead me to believe that perhaps a hotplug snippet might be called with ACTION=remove, though.
<Treenaks> what was the "canonical" way of rsyncing a daily iso again? (when you already have one, say, yesterday's image)
<sivang> infinity: it does
<sivang> infinity: for some reason, that event doesn't fire up my "usblp*" script which is exactly as the name of the subsystem in which the event occured , but on ="add" it does
<infinity> sivang : Curious.
<infinity>     # sysfs files may already be gone
<infinity>     if [ $ACTION = 'remove' ] ; then
<infinity>         exit 0
<infinity>     fi
<infinity> Just a guess, but you may be thwarted by usb.agent, there.
<sivang> hrm
<infinity> Though, that's only in a specific case.
<infinity> You'd have to trace it and find out if it's biting you.
<infinity> Oh, wait, no, I see it.
<infinity> Yeah, trace through usb.agent, near the bottom.
<infinity> You snippet isn't called to remove it, a specific "REMOVER" is called for your device.
<infinity> So when you create the device, you need to also create its remove script in /var/run/usb
<infinity> See the last 100 lines or so of usb.agent.
<sivang> infinity: k, looking there now
<sivang> infinity: I guessed so, just couldn't find it. When I experiment with replacing /sbin/udevsend from /proc/sys/kernel/hotplug , I saw all events, and was wondering..thanks!
<infinity> sivang : usb.agent declares a $REMOVER and exports it, your add script is supposed to create the remove script at that location, and it gets called (then deleted) on remove.
* infinity feels dirty for just having learned anything about hotplug.
<infinity> And on a weekend, no less.
<infinity> I think I'll go have a shower.
<\sh> morning gentlemen
<sivang> infinity: heh, sorry for that! :)
<sivang> \sh: good morning mr. hermen ;)
<\sh> sivang: ;) 
<sivang> doh, I over looked that...declare -x REMOVER="/var/run/usb/%proc%bus%usb%004%007"
<mdz> Treenaks: rsync --progress <source> <destination>
<Treenaks> mdz: no -c ?
<mdz> Treenaks: just so
<mdz> -a if you like
<Treenaks> ok, thanks
<\sh> g'morning doko :) 
<\sh> 2.6.12-9.15 failed...so I can't reinstall
<crimsun> "...however 9.18, which finally gets sk98lin right, will be uploaded soon after Colony 5 is done"
<\sh> crimsun: did I miss one post?
<crimsun> (from topic of #ubuntu-kernel)
<\sh> crimsun: yay...this chan I missed in my autojoin list ;)
<davyd> I have an interesting bug, and no idea where to look to fix it
<davyd> using the TV out on my video card usplash comes up black and white
<davyd> I _suspect_ it is because it's being outputted in NTSC
<davyd> X is fine because I specified a default in X
<davyd> anyone have any thoughts?
<infinity> davyd : Sure, that early in the boot process, TV out format will be almost completely handled/determined by BIOS settings...
<davyd> infinity: that's what I would expect too
<davyd> since the motherboard logo also has that NTSC look to it
<infinity> davyd : vga16fb certainly has no concept of output display, it just writes to the video car dand hopes.
<infinity> davyd : So, if the BIOS has no way to change the TVout mode, you're pretty muhc out of luck.
<davyd> infinity: mmm, I was hoping at least that I might be able to fix usplash
<davyd> is there any easy way to change fb driver?
<infinity> You'd have to write a LOT of code. Like I said, vga16fb has no concept of different output device types, and probably shouldn't.
<infinity> If the card can't get it right on POST, there's not much we can really do.
<davyd> I was wondering if the nvidia fb driver (rivafb?) might have some concept
<infinity> It might, but you can't use usplash with anything other than vga16fb.
<davyd> how come?
<davyd> I thought they simply chose that as a lowest common denominator
<infinity> Wlel, okay, you could hack your own local copy of usplash that may work with another fb driver (but no guarantees there), but is that effort worth it just to get a prettier usplash on your system, and yours alone? :)
<davyd> that's why I was wondering how hard it would be
<davyd> ie. if there was a config option you could tweak it with
<infinity> Well, if rivafb both a) supports your TV out, and b) supports the features usplash needs, it would be easy to hack it locally.
* davyd nods
<infinity> If either isn't true, you're still screwed, and stuck doing a bunch of devel work. :)
<davyd> to be honest, I would actually be surprised if you can't write something into the cards nvram to solve this issue
<infinity> find /usr/share/initramfs-tools/ -name usplash
<infinity> Hack there.  :)  And you would also probably need to make sure rivafb ends up on your initramfs, if it isn't already.
<infinity> Some cards have a jumper (or, two pade where a jumper should be soldered on but isn't) that can switch between defaulting to PAL or NTSC.
<infinity> s/pade/pads/
* sivang goes to read some more about sockets and signals in his lad book. be back later
<infinity> It's also defaulted in the video card BIOS itself, which is probably a simple binary patch hack ti fix, if you can't download a PAL BIOS to flash to it.
<davyd> mmm, I'll go and find the manual
<davyd> interesting, the last card didn't have this issue
<davyd> but that is a decade old
<infinity> There are 1001 sites out there with hacked up nvidia BIOSes, if you're feeling brave.
<davyd> perhaps I should just buy a new TV ;)
<\sh> hmm...didn't we have established a process for breezy packages backported to hoary? 
<infinity> Hacked for different default clock speeds, etc, but I'm sure people have hacked the PAL/NTSC defaults too.
<bob2> \sh: you throw it at a buildd, and have it uploaded without checking if it works or not, afaict
<infinity> Except for the part where youd don't do that at all.
<infinity> Testing that it builds on hoary+backports first would be nice.
<\sh> bob2: I'm only asking because all world is using this ubuntu-backports.mirrormax.net repos and they're fcked with those stupid mozilla-firefox packages
<infinity> And then you ask elmo (I believe he's still the go-between for this) to copy the sources from breezy to hoary-backports.
<bob2> \sh: yes
<infinity> \sh : yes, no matter how much "official" stuff we do, we can't STOP people from using third party repositories.
<bob2> infinity: dont' confuse the issue with your "facts"!
<infinity> But we can close their bugs with extreme prejudice when we get them.
<infinity> Which is almost as satisfying.
<\sh> infinity: but this repos is jdongs...and I thought we agreed, that he will maintain the official backports and not going any further with the unofficial stuff
<infinity> You'd have to talk to him about it, I guess.
<\sh> infinity: looks like I have to talk to the SPoC of the backports team first...and this is Mez..
<sivang> infinity: testing the legacy driver now
<sivang> removing nvidia-glx, and installng -legacy now
<sivang> (already installed lrm)
<infinity> lrm and lrm-nv-legacy, I assume.
<sivang> yeah
<infinity> (Well, nvidia-glx-legacy depends on lrm-nv-legacy, so as long as it doesn't pull in the wrong one for you, that sorts itself out.. Ish)
<infinity> apt-get is horriby bad at dealing that that dependency resolution, though, and just pulls in the first provider of "nvidia-kernel-7147" that it sees, which is almost always the wrong one (and then pulls in a whole new kernel with it, argh)
<sivang> I instaleld it afterwards,
<sivang> so it had laready have lrm 
<infinity> synaptic, aptitude and dselect would all do it properly.
<sivang> didn't pull a new kernel at all
<infinity> Kay, cool.
<infinity> So, you have a matching linux-image, lrm, lrm-nv-legacy, and nvidia-glx-legacy, then you should be good to go.
<sivang> Suggested packages:
<sivang>   nvidia-glx-legacy avm-fritz-firmware-2.6.12-8
<sivang> The following NEW packages will be installed:
<sivang>   linux-restricted-modules-2.6.12-8-686-smp-nvidia-legacy
<sivang> The following packages will be REMOVED:
<sivang>   nvidia-glx
<sivang> The following NEW packages will be installed:
<sivang>   nvidia-glx-legacy
<sivang> should I "nvidia-glx-enable" or whatever this thingy is called?
<sivang> ok, enabled, rebooting
<sivang> wish me lucj :)
<infinity> I need to fix it to do more.
<infinity>  /usr/sbin/nvidia-glx-config?  You can if you want, but it doesn't really do much except s/nv/nvidia/ in xorg.conf.
<davyd> hmm, I had thought that w32codecs was in multiverse nowadays...
<\sh> davyd: no
<Amaranth> ack no
<Amaranth> that thing is so illegal it screams "SUE ME NOW"
* davyd laughs
<davyd> maybe just a reference to it then
<sivang> infinity: ok, I'm back
* davyd grabs it from the usual place
<infinity> sivang : And...?
<sivang> infinity: didn't see the nvidia splash though, did you disable it by default?
<infinity> sivang : No, but it may be disabled in your xorg.conf...
<sivang> infinity: I see,lsmod | grep "nvidia" gives nothing.
<infinity> sivang : xorg.conf does say "nvidia", not "nv", right? :)
<sivang> bah
<sivang> it doesn't :)
<sivang> last time I'm counting on scripts to do my work
<infinity> sivang : While you're at it, remove 'dri' and 'GLcore' from xorg.conf.
<infinity> sivang : I'll fix up that stupid script soon, but it wasn't hig on my priority list.
<infinity> s/hig/high/
<sivang> sure thing :)
<sivang> it's just that real man don't use such scripts, I should have know :) (daniels said that or something )
<sivang> k, I'm going for another reboo
<sivang> t
<davyd> hmm, is it HashKnownHosts that breaks bash hostname tab completion?
* davyd suspects so
<sivang> infinity: failed to load kenrel module
<sivang> infinity: and it tried to load GDM while it was "Updating NVIDIA TLS links" r something :)
<infinity> Oh, bah.  That init script needs to move?
<infinity> Failed to load kernel module sounds kinda bad, though. :)
<infinity> Can you load it manually?
<sivang> did everybody else bumped on the WEIRD tet console bheavir that when you attempt login wich caps lock on,
<sivang> and manage to,
<infinity> (Note that the init script should be at the same spot as the one for nvidia-glx, so if that worked, so should legacy, but whatever..)
<sivang> everything is outputted in cAPS ?
<infinity> Hah, that happens on my Mac. :)
<sivang> WHAT IS THAT???
<sivang> :)
<infinity> It boots with the caps lock on, and if I forget to turn it off, everything is in caps land.
<sivang> That's like halloween
<sivang> yeah!
<infinity> If you reset(1) the console, it's fine.
<sivang> I am also getting weird kbd behavior,
<sivang> for instance:
<sivang> THIS IS A TeST AND I AM WRITING eVeRYTHING WITH TeH cAPS ON
<sivang> I'm using a M$ multimedia kbd
<infinity> Very... Neat.
<sivang> nice eh?
<sivang> I wonder how it selects the chars that will not get caps love
<infinity> Lottery.
<sivang> LOL
<infinity> sivang : So, back to the nvidia business.  Can you load the kernel module manually, or does it still fail?
<sivang> infinity: just ried
<sivang> tried
<sivang> "error inserting nvidia" no such device :-(
<sivang> doing it with sudo modprobe nvidia
<sivang> infinity: I am going to fetch something to eat, be back in about 30 minutes ok?
<infinity> Hrm.
<infinity> Alright.
<sivang> anything quicky to check?
<infinity> Not unless you want to give me access to that box.
<infinity> I'd need to fiddle a bit, probabl.
<infinity> probably.
<infinity> I may care a lot more on MOnday, though.
<Chipzz> davyd: it is
<infinity> Right now, I'm just killing time while I wait for my sushi to be delivered.
<sivang> what do you eman?
<infinity> sivang : I'll care deeply about bugs when I'm back at work on Monday. :)
<sivang> infinity: oh :)
<\sh> hehe
<sivang> I won't have access to that amchine on mondya 
<Chipzz> (I had some previously unhashed hosts in that file, those complete fine; I just nuked the hashed keys and changed the setting to off)
<sivang> infinity: talk in about 30 if you're still there, maybe I can carry on the fiddely for you
<infinity> sivang : Does it help that my Monday is probably your Sunday?
<infinity> sivang : Also, if you could test the whole mess on a non-smp kernel, that might be helpful too.
<sivang> infinity: We'll see on sunday, how do I go back to my previous cponfig? Just put nv instead of the nvidia ?
<\sh> sivang: yes ;) normally that works
<sivang> \sh: k, be back later then
<Kamion> phew, Colony 5 seems to have published ok
<Kamion> despite it happening 15 seconds before my network went down, and the sync-mirrors bit running as 'sleep 120; sync-mirrors; sleep 120; sync-mirrors' in a screen on little
<mdke_> getting some reports that the italian translations in rosetta have not been updated with the latest language-packs, anyone know anything about that?
<tseng> mdke_: i think youll want to ask pitti 
<tseng> after confirming the issue
<mdke_> sure if no one else knows, I'll post to -devel or something
<mdke_> it's a weekend after all
<zyga> where can one complain about wiki css?
<mdke_> to the webmaster
<zyga> mdke: webmaster@ubuntu.com/
<mdke> zyga, you have to look on the website, but you can get him at henrik@canonical.com
<zyga> thanks
<mdke> zyga, what is your complaint out of interest?
<zyga> links should be more visible, especially in the wiki
<zyga> they use the same font size and style 
<zyga> (as regular text)
<mdke> they are a different colour though
<zyga> hmm? maybe I'm colorblind then
<zyga> my LCD shows the exactly same color 
<mdke> and underlined
<mdke> visited links are black, non visited links are ubuntu brown
<zyga> visited links should never be black
<zyga> regular text is black
<mdke> zyga, better file a bug rather than emailing
<sivang> anyonem seen a problem with a dell's laptop touchpad / mouse hiding on the lower left cornet of the dispaly and not willing to come out, even if you offer it some good cheese and connection and extenral USB mouse ?
<zyga> sivang: did you touch the touchpad with wet fingers?
<zyga> (this is not a joke)
<zyga> my touchpad goes creazy with something as small as a wet smudge on the surface
<sivang> zyga: ok, but when trying with the usb mouse it also won't work
<sivang> zyga: not sure about the wetness, could be
<zyga> sivang: that's because the touchpad constantly detects some movement in the random direction
<zyga> I have the same issue in general, try wiping the touchpad with a dry cloth
<zyga> s/the random/a random/
<karim> hi
<karim> is there a ppc channel ?
<jbailey> karim: I don't think so.  It might be cool if there was one, though.  Are you interested in support or development?
<karim> well that's a lot of time to invest, but if there is an official one I might be around often
<karim> jbailey, so I could help fellow ppc ubuntu users
<karim> and they could help me too :)
<jbailey> I suspect that if you asked in #ubuntu for people interested in powerpc, and if they wanted a less noisy channel to talk in, you'd probably get some takers.
<karim> there is #ubuntu-ppc but we are only three on it
<jbailey> I know I hadn't heard about it, but I miss alot of things.
<mjg59> jdub: Hi
<karim> jbailey, you are welcom on it :)
<jbailey> karim: Probably not right now, but maybe after Breezy releases.
<karim> jbailey, I still have the boot problem with the cmd646 not loading
<karim> I am in the place where the mac is, so I can do some tests
<karim> if you remember
<mirak> I am mirak
<siretart> nice. igor now building sparc packages :)
<lamont> Removing jadetex ...
<lamont> dirname: too few arguments
<lamont> Try `dirname --help' for more information.
<lamont> score!
<bddebian> Uhm
<lamont> was someone fixing libcaca?
<mirak> libcaca ?
<mirak> caca means poo
<bddebian> heh
<mirak> in french
<mirak> libpoo
<Diziet> Ah, hello Keybuk.  Are you really there ?  I'm just having a go at looking into 16133, the x-common file conflict.
<Keybuk> yup, I'm here
<Keybuk> what was the issue there?  file conflict on a directory?
<Diziet> Were you around for the discussion yesterday ?
<Diziet> Yes.
<Keybuk> no, but I did take a brief look at it myself
<Diziet> A contains a directory /foo.
<Diziet> That is, xfonts-base contains /usr/lib/wossname/fonts
<Diziet> But somehow /usr/lib/wossname/fonts has been made a symlink.  So /foo -> /bar.  This is fine.
<Keybuk> I _think_ I fixed that in 1.13.11
<Yagisan> jbailey: Test installs of Breezy Colony 5 in vmware 5 with both buslogic and lsilogic scsi work fine. It seems the bug is fixed
<Diziet> Now if you install B which contains /foo -> /bar (x-common in this case), dpkg looks at /foo and says `it's a symlink'
<Diziet> But it's trying to install a symlink.
<Diziet> So that's two symlinks, a conflict.
<Keybuk> oh, right
<Keybuk> user-replaced-symlink-to-directory conflicting with a real symlink?
<Diziet> I think that the right answer is if on the filesystem /foo -> /bar and /foo.new -> /bar2 where /bar2 and /bar are the same directory according to stat, it should be OK and treat it as a directory.
<Diziet> keybuk: I think so.
<Diziet> Where `user' = maintainer script.
<Diziet> Oh, hold on, looking at the code I seem to be wrong.
<Diziet> Anyway, I'll look at it now for a bit and see whether my hunch was right.
<Keybuk> the odd thing is, if dpkg thinks it's a directory being overwritten by a non-directory, you get a different error
<Keybuk> dpkg: error processing /var/cache/apt/archives/x-common_1.08_all.deb (--unpack):
<Keybuk> trying to overwrite `/usr/lib/X11/fonts', which is also in package xfonts-base
<Keybuk> suggests it doesn't think "/usr/lib/X11/fonts" is a directory or symlink-to-directory
<Keybuk> I'd expect to see, instead
<Keybuk> trying to overwrite directory `/usr/lib/X11/fonts' in package xfonts-base with nondirectory
<Diziet> `existingdirectory' is 0.
<Diziet> See archives.c near line 426.
<Keybuk> should it be 0?
<Diziet> No, I think it should be `.
<Diziet> 1.
<wasabi> great. mysqld is now segfaulting for me =(
<Diziet> It uses lstat, not stat.
<Keybuk> should that if statement under case SymbolicLink be doing a stat() call itself (like the Directory one) rather than re-using the lstat() value
<Diziet> I think it should, yes.  I'm just writing code to do that now.
<Diziet> It has to stat the putative link target, too.
<Keybuk> I think just copying the lower if should do the trick, no?
<Keybuk> do we need to readlink() it?
<Diziet> No.  What we want is to see if the new link target (the one from the package) is the same as the one on the filesystem.
<Keybuk> right
<dholbach> hello
<Keybuk> careful to make sure you don't break ordinary changing of symlink destination within the same package
<eruin> sorry for dragging skeletons out of the closet, but what's happening wrt ubuntuforums mailing list access?
<ogra> i'd vote for making it readonly for -devel....
<\sh> ogra: second that
<\sh> and can somebody explain why the ubuntu-backports.mirrormax.net are not closed? I thought with introducing the official ubuntu backports team it should be closed
<Diziet> keybuk: when this happens, dpkg has lost track of which package has the symlink.  They all have it listed in .list.
<mjg59> Nngh.
<mjg59> People are /msging me, and I can't reply
<Diziet> Should it constantly make the symlink point to whatever the last package wants ?
<mjg59> And they're not on any channels
<\sh> mjg59: not registered? ,-)
<mjg59> No
<mjg59> Well, they're registered
<mjg59> I'm not
<\sh> mjg59: then do it ;) 
<mjg59> \sh: No
<ogra> \sh, hmm, i thought they wanted to keep it for the illegal stuff like w32codecs and decss
<ogra> (hoary-extras)
<\sh> ogra: but not for firefox?
<siretart> ogra: they have taken these out
<ogra> lol
<mjg59> \sh: The solution to spam problems is to deal with the spammers, not reduce the functionality for everyone else
<siretart> for 'legal' issues
<Keybuk> Diziet: I don't think it should change it ... if it would have to change it, surely that _is_ a conflict?
<ogra> yes, then the bakports stuff is pointless
<Diziet> Yes, but if it points to the same place ?
<\sh> mjg59: I know...that's why I'm against cloaking etc. but I registered my nick long ago :(
<\sh> ogra: go and check #ubuntu-de and the forums and ubuntu-users ml 
<Diziet> Replacing an absolute link with a relative one, perhaps, or two equivalent links some of whose components are themselves links.
<Keybuk> leave it, I'd say
<\sh> ogra: everything is full because of update problems from backports to ubuntu and vice versa...it's crap
<ogra> \sh, yes, but thats a older ff backport, its about 2 months old
<ogra> but i thought they wanted to shut down the normal backports...
<\sh> ogra: doesn't matter...it's a main package after all, and they never check the functionality of updates for their packages
<\sh> ogra: our backports are hoary-extras, right? and not ubuntu-backports.mirrormax.net
<ogra> \sh, poke Mez about it :)
<ogra> nope, hoary-extras are things like freenx
<\sh> ogra: sorry..but Mez can't help....I'll get my hands on jdong 
<Diziet> Once you've got A containing /foo/wombat and B containing /foo -> /bar on your system, dpkg has forgotten which of A and B had a directory /foo and which the symlink.  So if you now reinstall B' /foo -> /bar2 then it's probably broken anyway.
<\sh> ogra: which is official backports then?
<ogra> \sh, try that
<ogra> \sh, the ones that Mez does
<Diziet> That means that if you have a symlink/directory muddle which appears in more than one package you have to use maintainer scripts to change the link target.
<\sh> ogra: what was the source name for that? 
<ogra> no idea, i never used them... look at the forums :p
<\sh> eek
<siretart> wow
<ogra> i think he also sent a mail to -users
<siretart> nautilus is using HUUUGE icons
<ogra> siretart, accessibility feature ;)
<\sh> ha...mitsushiko rocks
<\sh> http://www.ubuntuusers.de/viewtopic.php?t=11948&highlight=backports
<Keybuk> hmm, someone needs to fiddle with the TV at Interlagos ... the picture is terrible, lol
<\sh> he posted my statement about backports
<siretart> ogra: tell me, is this accessibility feature or bug: http://siretart.tauware.de/Bildschirmfoto.png
<ogra> siretart, without looking i guess its a bug, i was kidding
<siretart> hm
<ogra> oh, looks like your icon theme is broken or librsvg has a bug
<\sh> ogra: it's hoary-backports on archive.ubuntu.com
<ogra> ah, ok
<desrt> does anyone get the weird bug where the time indicator on battstat doesn't update when you plug your laptop into AC?
* ogra uses gnome-power and hasnt seen such a bug
<desrt> like the gnome-power trayicon for indication?
<ogra> mjg59, kudos btw, since today my str is working again on the acer amd64 lappie (didnt upgrade the last two weeks) it was broken the whole dev cycle :)
<Diziet> keybuk: Did you know that this build system doesn't notice when your code doesn't compile ?
<Keybuk> the debian/rules stuff?
<mjg59> ogra: Cool
<Diziet> ../../src/archives.c:467: error: too few arguments to function 'linktosameexistingdir'
<Diziet> make[3] : *** [archives.o]  Error 1
<Diziet> make[3] : Leaving directory `/slash/ubuntu/work/dpkg-1.13.10ubuntu3/build-tree/src'
<Diziet> Making all in dselect
<Keybuk> odd
<Diziet> Blimey.  Read the toplevel Makefile.in, near line 365.
<Diziet> _Automake_ ignores errors.
<Keybuk> shouldn't do ...
<Diziet> Obviously it _shouldn't_.  It was clearly written by YET MORE PEOPLE WHO CAN'T WRITE SHELL SCRIPTS !
<Diziet> When I am EPDFL you'll have to get a special licence to write shell scripts.
<Keybuk> looks ok to me here ?
<Diziet> list='$(SUBDIRS)'; for subdir in $$list; do 
<Keybuk> processarc.c: In function process_archive:
<Keybuk> processarc.c:138: error: BUG undeclared (first use in this function)
<Keybuk> make[2] : *** [processarc.o]  Error 1
<Keybuk> make[2] : Leaving directory `/home/scott/co/debian/dpkg-1.13/src'
<Keybuk> make[1] : *** [all-recursive]  Error 1
<Keybuk> make[1] : Leaving directory `/home/scott/co/debian/dpkg-1.13'
<Keybuk> make: *** [all]  Error 2
<Keybuk> hmm, the Makefile.in in the ubuntu package is different to mine
<Diziet> Maybe you have a fixed automake.
<Keybuk> in fact ... the one in the Ubuntu package is missing the "|| exit 1" :p
<sabdfl> greetings earthlings
<Diziet> Hello.
<Diziet> Interestingly if I debian/rules build on breezy it DTRT.
<ogra> sabdfl, !
<sabdfl> hey all
<Keybuk> looks like Eric has been playing "apply random patches" again
<sabdfl> i'm doing a breezy update, seems you guys have been busy
<Diziet> We can't let your computer stay not-out-of-date :-).
<\sh> sabdfl: who was the "holiday"? ,-)
<\sh> s/who/how/
<Diziet> OK.  My patch makes the error message go away.
<Diziet> Let me see if a dist-upgrade falls over in a heap.
<sabdfl> \sh: the "holiday" was cute, thanks ;-)
<Keybuk> ah yes, dist-upgrade, the dpkg debugger's friend
<Keybuk> I always make sure I'm a little out of date before hacking too
<Diziet> :-)
<\sh> hmmm..something seems wrong with the update-manager
<Diziet> Seems to be working.
<Diziet> So, should I (a) just upload it, (b) have you eyeball the diff and upload it, (c) post a message to ubuntu-devel and wait until Monday ?
<\sh> working yes..but after downloading the packages and installing the paackages there is this strange changelog window..and it's disappearing to fast somehow
<Diziet> Damn, I forgot LANG=C.
<mjg59> I think we should adopt a strategy of "break early, break often"
<Keybuk> I'll look through the diff if you like
<\sh> so after downloading and before installing the packages i mean ;)
<Keybuk> otherwise you may wish to check with mdz before uploading *shrug*
<Keybuk> I think the Colony restrictions are released now though
<Keybuk> (he says breaking udev again)
<Diziet> keybuk: Yes, there's an announcement about Colony.
<Diziet> I've still got that xscreensaver file conflict.
<Diziet> dpkg: error processing /var/cache/apt/archives/xscreensaver-data_4.21-4ubuntu14_i386.deb (--unpack):
<Diziet>  trying to overwrite `/usr/share/man/man1/xscreensaver-getimage.1.gz', which is also in package xscreensaver
<Diziet> But I don't think that's due to my patch.
<Keybuk> what version of xscreensaver you got installed?
<mjg59> xscreensaver-data probably doesn't declare the right relationships to older xscreensaver packages
<Keybuk> Replaces: xscreensaver (<= 4.21-4ubuntu10)
<Keybuk> oh, ogra's trying to revert the split
<Diziet> Joy :-).
<Diziet> Hmm, error message has gone away.
<Diziet> Fine.
<Diziet> That's why it's called a prerelease, I suppose.
<ogra> Keybuk, i didnt change anything...
<Keybuk> ogra: yeah, just noticed that was Monday
<ogra> and it would be silly to revert the split, we'll split even more for dapper to only ship the screensavers we want
<Keybuk> heh
<Keybuk> xscreensaver (4.21-4ubuntu14) breezy; urgency=low
<Keybuk>   * reverted the split
<Keybuk>  -- Oliver Grawert <ogra@ubuntu.com>  Mon, 19 Sep 2005 19:29:05 +0200
<Keybuk> :p
<ogra> that was anothe split, i had made a xscreensaver-utils package for the 4 tools the hacks need
<Keybuk> I think that Replaces version needs increasing at a guess
<ogra> but Kamion and mdz oppsed that, so i included them in the -data package
<ogra> yup
<ogra> will fix it today
<Diziet> http://www.chiark.greenend.org.uk/~ian/d/dpkg-symlink-to-dir-conflict.diff
* Diziet boggles.  You reverted the other split.  Maybe you need a banana :-).
<Diziet> xscreensaver-fungible.
<ogra> heh
<Keybuk> Diziet: looks ok to me
<Diziet> So do you have an opinion about (b) vs (c) ?
<slomo> lamont / infinity: can someone of you kick a rebuild of ikvm on x86 and ppc? should work now without problems... or shall i upload a build2?
<Keybuk> I'd do b
<Keybuk> if you're sure it's not going to break anything <g>
<Diziet> Pretty sure.  As sure as I'm going to get without doing a whole test upgrade with it.
<Keybuk> can you test a single package with v1 and v2 containing a symlink of the same name, but pointing to different places?
<Keybuk> I'm not sure whether your patch doesn't break that
<lamont> slomo: please don't upload something that has no need.
<lamont> slomo: given back
<slomo> lamont: that's why i ask... so you can give back also packages which built on one architecture and failed on others?
<lamont> if it previously failed, but will build now without changes, then we can give it back
<slomo> lamont: i hope it builds now... it works without problems in my pbuilder and the buildlog looked like a nant problem... new nant was uploaded a few minutes before ikvm
<Diziet> keybuk: Willdo.  Pointing to different directories or different files ?
<Keybuk> both
<Keybuk> or starting pointing to a directory, and ending up pointing at a file
<Keybuk> I think those all work now
<bddebian> elmo: ping?
<slomo> lamont: please remove service-discovery-applet from NEW
<Diziet> keybuk: Yes, it seems to work nicely.
<Diziet> Oh, did you notice that I didn't mark the two error strings as translateable.  Do you agree ?
<Keybuk> meh, I haven't made my mind up on that yet
<Keybuk> I think it's a symptom of lazy translators, I think
<Diziet> I think they do have a point.  If you're going to understand what `failed to stat (dereference) proposed new symlink target `some file' for symlink `some other file': Input/output error   means then you're going to understand it in English too.
<Diziet> And indeed you'd be better off with that than some half-baked mush that a translator is likely to make of it.
<Keybuk> the trouble is, in that example, Input/output error _will_ be translated
<Keybuk> because libc error messages get translated
<Diziet> That's fine - that's the bit you might figure out :-).
<Diziet> `My disk is buggered'.
<Diziet> Or is there some reason why mixed-language messages are considered evil ?
<Keybuk> *shrug*
<lool> Hi, does someone has a debian/rules snipset to specialize a Debian package for Ubuntu?
<bddebian> lool: They are the same
<lool> bddebian: no I really mean what I said :)
<ogra> lool, just make sure the build-deps are right and the changelog contains breezy as distro
<lool> I'm a Debian package maintainer and would like to ifdef a change that I can't include right now in Debian
<lool> ogra: I need to run some code conditionally
<Diziet> Oh, you mean you want to say `if being built for Ubuntu' ?
<lool> yes!
<Diziet> There's no way to do that.
<lool> I've read some things like that in a list; so I thought someone would have a snipset
<lool> such as cat /etc/... release
<ogra> lsb-release -a ?
<lool> is there a /etc/ubuntu_version?
<Diziet> No, because you might compile on Debian for Ubuntu or vice-versa (at least when debugging - of course the Ubuntu and Debian build daemons all use their own distro).
<ogra> lool, we use lsb-release
<lool> ogra: I'd prefer avoiding new build-deps for the test
<ogra> err s/-/_/
<ogra> there is no /etc/ubuntu_version
<Diziet> What's the change that you want to conditionally apply ?
<lool> Diziet: you don't want to know, but trust me :)
<Diziet> Tell us anyway :-).
<Diziet> So we can say `oh, no, you don't want to do that ...', as you seem to be expecting :-).
<Diziet> Sod it, I'm not going through any more of these old dpkg bugs to find any Debian BTS bug that's relevant to this diff.
<lool> ogra: ah found it, lsb_release indeed
<lool> http://lists.debian.org/deity/2005/08/msg00002.html
<lool> Diziet: this is to conditionally build a gstreamer package, and calls a debian/control generation script; the reason I wouldn't tell is because it's rapidly frowned upon to generate the control, but in this particular case, it isn't done in "clean", but in a manual rule, so it's ok
<Diziet> Oh, if it's an a manual rule then it probably doesn't matter if it's flakey.
<lool> exactly, and I'm just thinking that I won't need a build-dep since it's not used during (re)build
<ogra> i'd just do a check if /bin/lsb_release exists and inside that a /bin/lsb_release -a without adding it as build dep. its a reverse dependency of ubuntu-minimal ... 
<Diziet> You should have a build-dep iff the gstreamer needs some extra stuff.
<Diziet> Or do you mean a build-dep on some lsb package ?  No, you don't want that.
<ogra> so you can be pretty sure its there on *every* ubuntu system
<slomo> lamont: can you remove smlnj from dep-wait?
<lool> pff lsb-release pulls pax, lsb*, alien
* \sh needs one hour sleep
<lool> Diziet: the external script replaces the build-deps and adds a package declaration to debian/control in this case
<Diziet> Right.
<lool> it was written to permit building of gstreamer-lame to end-user
* Diziet finishes faffing with dpkg.  Right, I'm off to be a weekend-person again now.
<ogra> Diziet, pfft
<lool> can someone tell me if lsb_release -i -s returns "Ubuntu" or ubuntu?
<Diziet> ogra: :-P
<ogra> :)
<dholbach> Ubuntu
<lool> thanks
<Diziet> TTFN people.  Thanks, Keybuk.
<ogra> Diziet, enjoy your weekend :)
<lool> I can't find gstreamer0.8-mms on packages.ubuntu.com, does someone have it installed?
<jaldhar> is it too late to get any changes into Breezy
<jaldhar> never mind, it seems Breezy already has the right package version.
<Keybuk> if only all requests were so easy :p
<slomo> lool: gstreamer0.8-mms will be added soon afaik
<ogra> does packages.ubuntu.com include multiverse ?
<slomo> ogra: yes
<slomo> lamont / infinity: please remove smlnj from dep-wait for ppc :)
<gouchi> Hi
<gouchi> I was wandering if a project about a Music Video about Ubuntu has been started ?
<dholbach> haha, like the QT one? :)
<dholbach> let's think about the stars featuring in there :)
<gouchi> dunno about QT :)
<gouchi> it would be great I think 
<gouchi> and add it to the distro as goodies
<dholbach> http://ktown.kde.org/~hausmann/qt4dance_medium.ogg
<gouchi> as ubuntu-calendar, ubuntu-sound
<gouchi> a new package will arrive ubuntu-video :)
<dholbach> it's an excellent idea - who do you want to dance on the screen?
<gouchi> maybe a 3D character ? like the one with the mask 
<dholbach> you weren' talking about real people?
<bob2> there are videos of the warty and hoary dances
<gouchi> bob2 : which one ?
<gouchi> dholback : if some want :)
<gouchi> dholback : lol
<ogra> http://www.grawert.net/udu-gallery/img049.jpeg
<ogra> gouchi, ^^^
<gouchi> :)
<dholbach> that was great :)
<gouchi> or clip video that explains the ubuntu philosophy
<shackan_> dholbach, I wish I hadn't opened that url ..
<gouchi> I thing I gonna post on the forum so that people makes some idea
<dholbach> shackan_: what's wrong - the song won't leave you all day?
<shackan_> dholbach, it's just disturbing :D
<dholbach> shackan_: just a bit :)
<ogra> shackan_, dholbach *loves* distrubing songs that dont leave you for 2 weeks ;) 
<dholbach> hahaha
<ogra> *g*
* dholbach hums the girl from ipanema... hmmmhmmhmmhmm
<ogra> grrr
<dholbach> apart from that we had jdub TV! already :)
<Hfuy> Evening all.
<Hfuy> This was given as the "team channel" for the Ubuntu laptop team. Am I in the right place?
<dholbach> i suppose so
<Hfuy> I just discovered that #ubuntu-laptop exists.
<Hfuy> I presume the website -should- point me there.
<dholbach> oh
* dholbach didn't know that channel
* Hfuy either
<Hfuy> Anyway.
<Hfuy> I have here a Toshiba Satellite SP10-304, which has just had a new hard drive.
<Hfuy> I've tried putting Red Hat Enterprise on it, with horrible results.
<Hfuy> Will Ubunto do things like easily support the widescreen LCD, and allow the laptop to suspend when I close the lid?
<Hfuy> Red Hat seems singularly unable to do these things.
<dholbach> was there anything on the wiki?
<Hfuy> which wiki
<dholbach> http://wiki.ubuntu.com
<Hfuy> Cor, a wiki!
<Hfuy> But nothing for Toshiba SP10
<Hfuy> Or "suspend to disk" or "suspend to RAM" or "hibernate"
<Hfuy> It's not looking good, really, is it.
<Hfuy> What's "Hoary"
<dholbach> our last release
<Hfuy> Apparently ACPI with suspend to disk or ram and detection of a laptop's "sleep" button is in Hoary.
<Hfuy> How would I go about getting it, if I wanted it?
<lamont> Hfuy: follow the links from www.ubuntu.com
<Hfuy> What's it like with widescreen displays?
<lamont> Note that this is more of a #ubuntu discussion... this channel is for discussing ongoing development stuff
<Hfuy> Goddammit, any time I get into a useful conversation someone tells me to stop.
<Hfuy> #ubuntu is so busy it's impossible to follow. Please, bear with me?
<Hfuy> It's also a #ubuntu-laptop discussion and I'm happy to take it there.
<zenwhen> hey
<slomo> mjg59: do you have some time to read a license? is this multiverse-compatible? http://revu.tauware.de/revu1-incoming/mosml-0509241220/mosml-2.01/debian/copyright
<mjg59> slomo: Looks fine
<zenwhen> nice
<zenwhen> my sound doesnt work in breezy
<zenwhen> and i cant mount my usb hard drive ine breezy
<zenwhen> in*
<slomo> mjg59: even the "Caml Light, version 0.7" license?
<mjg59> slomo: It's non-free, but should be fine for multiverse
<slomo> mjg59: ok, thanks :)
* xTina peeks back into the # and notices the words "mosml" and "multiverse" mentioned in one message :)
<dholbach> good night everybody, sleep tight
#ubuntu-devel 2005-09-30
<zyga> hello
* lamont fixes linux-meta for ia64/hppa
<zenwhen> what the hell
<zenwhen> why isnt java in any of the repos now
<zenwhen> shit
<zenwhen> the backports java is gone
<zenwhen> i choose to reinstall today and ill be damned if every single thing that amkes ubuntu easier to set up has gone to shit
<spacey> zenwhen, its really easy to build your own java package
<zenwhen> not by these instructions it isnt
<zenwhen> https://wiki.ubuntu.com/JavaPackageBuildNewVersions
<zenwhen> what the fuck is an esac
<zenwhen> Now add between this part and the "esac" following new lines:
<zenwhen> thats not instruction
<mjr> it's "case" backwards
<mjr> don't ask
<zenwhen> whats it telling me to do
<spacey> apt-get install java-package
<zenwhen> ive doen that
<spacey> make-jpkg thejava.binfilefromjava.sun.com
<spacey> thats all for me
<zenwhen> so this article is wrong?
<spacey> it worked for me with just those two commands
<spacey> got it from the wiki
<spacey> but can't find it now
* spacey to sleep
<spacey> goodnight
<zenwhen> spacey, 
<zenwhen> thanks
<zenwhen> that worked
<slomo> zenwhen: or you can use blackdown jdk which is in multiverse... we are simply not allowed to distribute the sun jdk so blame sun for these problems ;)
<zenwhen> I wasnt blaming anyone
<zenwhen> i was pissed in egneral
<zenwhen> general*
<zenwhen> and I just relaized I am in ubuntu devel.
<zenwhen> and am sooo sorry.
<slomo> no need to worry
<crimsun> I fear we're going to have to do something about /var/lib/alsa/asound.state when dist-upgrading Hoary->Breezy
<crimsun> Quite a few people are being bitten by changing mixer element names between major ALSA releases (e.g., 1.0.6 in Hoary to 1.0.9 in Breezy), so their sound mysteriously "doesn't work"
<crimsun> Unloading the ALSA modules, removing /var/lib/alsa/asound.state, and reloading the ALSA modules resolves the issue
<slomo> crimsun: what about converting the names to the new ones in postinst?
<zenwhen> I tried to dist upgrade today and everything exploded. (X wouldt start)Clean installed and my Audigy, though totally configured didn't produce sound.
<zenwhen> I really want to run Breezy soon.
<crimsun> slomo: converting the names can be messy, because the current settings for "Element X" may behave differently in the newer ALSA for "Element newX"
<crimsun> slomo: for instance, the whole External Amplifier conditionally needs to be muted in newer ALSA for certain AC'97-based codecs deal
<slomo> crimsun: sounds problematic... hmm... can you detect whether asound.state is from an old version? removing it while updating from an older version may be a solution but probably not the best :/
<crimsun> zenwhen: and I won't even begin to delve into the Audigy legacy
<zenwhen> Oh?
<zenwhen> Any idea whats breaking it?
<crimsun> slomo: it's possible (we can check amixer's return code), but that seems suboptimal. Going to think about this tonight.
<crimsun> zenwhen: semantics changed between ALSA 1.0.6, 1.0.8, and 1.0.9 fairly majorly.
<zenwhen> Oh
<slomo> hm nice... the python update yesterday broke some stuff :(
<zenwhen> at least its a known bug :)
<jdub> mjg59: ping
* lamont wonders why linux-meta binaries don't seem to have shown up yet.
<tseng> lamont: ive not seen mythmusic, from early this morning, yet
* lamont realizes what happened.
<lamont> added missing packages for ia64/hppa ---> NEW.  sparc hasn't uploaded yet
<dhonn> hey i just noticed i has a new file on my computer its abi-2.6.12-9-k7 what is it?
<dhonn> nvermind
<zenwhen> This question may have been asked a million time, but is there a reason that DMA isnt enabled by default on optical drives?
<zenwhen> times*
<Amaranth> zenwhen: it doesn't work with some drives
<Amaranth> as in, those drives will refuse to work
<robitaille> humm...I'm getting a connection refused when I try to access  http://archive.ubuntu.com/   anyone else can confirm this?
<Aegir> Does the same thing here robitaille
<Aegir> Bollocks, archive.ubuntu.com refusing connections is going to make synaptic real fun, oh well.
<robitaille> Aegir,  maybe switch to another repository from another country?  
<Aegir> Yeah, but thats efffort.
<robitaille> but ca, us, and uk all point to the same broken one...
<Aegir> Hmm
<Aegir> I'm actually on the Australian one atm, and thats refusing aswell by the looks of things
<bob2> which is also the same as ca, us and uk
<robitaille> so is there any country-specific repository left?
<Aegir> Ohwell, I'll just strike installing wine off my list of things to do today. No big deal.
<tseng> there is a list of non-canonical mirrors on the wiki
<tseng> at universities and such
* tseng uses two meanings of canonical in one sentence for bonus cheese
<tseng> https://wiki.ubuntu.com/Archive
<Yagisan> G'day - who do I bother with ltsp questions ?
<robitaille> Yagisan,  have you tried the channel #ltsp ?
<Yagisan> robitaille: yeah - but it was more questions on Ubuntu's implementation
<Yagisan> robitaille: hmm - it seems like I can set up the ltsp server without the ltsp-server package - nevermind
<robitaille> so who can access archive.ubuntu.com?  a lot of question on #ubuntu about the fact that it has been down for the last hour
<robitaille> as in system admin access to the machine...
<jsgotangco> hmm i guess the whole world can't update at the moment then
<robitaille> unless you use a mirror
<tritium> robitaille, there's been a note in the topic, and bob2 added another one
<bob2> hrm, oops, didn't notice that there, sorry
<robitaille> tritium,  but people never read the topics :)
<tritium> bob2, no need to apologize.  robitaille makes a good point :)
<tseng> robitaille: if they cant read the topic, you cant be arsed to go around trying to get them more info
<bob2> when did it stop responding?
<tseng> or something.
<robitaille> bob2,   at least for one hour
<jdub> yo robitaille 
<jdub> GOOD MORNING FREEDOM LOVERS!
<robitaille> hello jdub 
<robitaille> always find strange to be told good morning when I'm about to go to bed :)
<jdub> heh
<tseng> hi jdub 
<zyga> hello
<mdke> any eta on archive.u.c coming back?
<Treenaks> RSN
<siretart> security.ubuntu.com should be even more important..
<Treenaks> what happened then?
<mdke> what is RSN?
<siretart> really soon now
<mdke> ah great
<\sh> morning gentlemen
* OculusAquilae is away: away
<mdke> Treenaks, RSN? :p
<\sh> is someone working to fix the webserver? ,-)
<eruin> anyone have anything to do with aspell here?
<eruin> I'm trying to translate it for breezy, and I'm wondering what this is and how/where it is set/configured: common/config.cpp : consider run-together words legal
<j^> are there plans to work on something like Conary[http://wiki.conary.com/]  but using arch + deb + xyz?
* OculusAquilae is back.
<\sh> hey madduck 
<siretart> hey, archive is back!
<\sh> wow
<Znarl> I restarted archive.
<siretart> thanks, Znarl!
<\sh> Znarl: fantastic :)
<jdub> mjg59: so, i checked my bios, and IR is enabled on COM2
<mjg59> jdub: Hrmph.
<mjg59> jdub: Can you do cat /sys/bus/pnp/devices/*/pnp and stick it up somewhere?
<jdub> you mean */id ?
<mjg59> Yeah
<jdub> pasted
* jdub wonders if it's the same as what his email ages ago had
<jdub> hmm
<mjg59> jdub: Yeah, your IR has vanished for some reason
* mjg59 expresses confusion
<jdub> i wonder if that was when i booted without the dock
<jdub> i will try that :-)
* jdub wonders if the DSDT mucks with the dock
<\sh> whois jdong 
<\sh> kick jdong
<\sh> grmpf
<jdub> hmm.
<jdub> that didn't work.
<zenwhen> hey
<tseng> Robot101: have you considered netdev-random or audioentropyd?
<tseng> Robot101: the first is a kernel patch to supply entropy from network traffic, second from ambient noise on a cheap microphone
<pitti> Hi
<\sh> moins pitti
<bddebian> Heya pitti 
<infinity> Hye pitti.
<ogra> mjg59, around ?
<pitti> Hi ogra
<ogra> hey pitti 
<pitti> anyone from the backports team here? 
<ogra> hahaha
* pitti curses at "firefox" in hoary
<ogra> pitti, seen my discussion on the ubuntu-de ML ?
* ogra is going mad slowly
<pitti> ogra: just replied
<ogra> ah, thanks :)
* ogra clicks send/recieve :)
<pitti> ogra: do you happen to know a contact address for the backports team?
<ogra> jdong
<ogra> i'll look up his mail adress
<pitti> email?
<mdke> you could try the Mailing List?
<ogra> <john.dong@gmail.com>
<pitti> mdke: that would be nice, is there ubuntu-backports@u.c?
<pitti> ogra: thanks
<mdke> pitti, something like that
<ogra> pitti, yup
<mdke> pitti, @lists
<bddebian> elmo: ping?
<mjg59> ogra: Hi
<\sh> grmpfl .. wront my 2cents to -de ML
<\sh> wrote even
<ogra> mjg59, should gnome-screensaver work with acpi or did you postpone the work until dapper ? i have a bug about it and would like to make it a enhancement for dapper
<mjg59> gnome-screensaver should work with acpi.
<mjg59> But, well.
<mjg59> The basic problem is that gnome-screensaver --deactivate unlocks the screen
<mjg59> Whereas xscreensaver-command -deactivate pops up the password dialog
<jdub> good bug
<bddebian> heh
<ogra> mjg59, i wont waste time with it now, and i guess you will neiher... lets make it a enhancement :)
<\sh> hmm..reiserfs s*cks
<ogra> jdub, since i'm working on marks changes for gnome screensaver now, "switch account" or "switch user" ? how shall i call the button
<mdke> so in Breezy is suspend going to come back to a password prompt or just a blank screen (ogra, mjg59)?
<ogra> s/gnome screensaver/xscreensaver/ indeed
<mjg59> mdke: A password prompt (assuming we switch back to xscreensaver)
<ogra> we already did
<mjg59> ogra: When?
<infinity> A week ago?
<ogra> last week
<jdub> ogra: well, i think it makes sense to use the same language everything else does at the moment - "switch user..."
<mjg59> Ah, so we did
<mjg59> I thought we were waiting for Mark to get back?
<ogra> jdub, ok
<mdke> ogra, gnome-screensaver hasn't be removed though, and the current behaviour is a blank screen
<mdke> be/been
<jdub> mjg59: mdz made the change very quickly after the meetnig, i assume he spoke to mark
<ogra> mjg59, he made the final call... its just that i have to rewrite the lock screen completely :)
<mjg59> Ah, ok
<mdke> so gnome-screensaver is going to be removed?
<mdke> at the moment my computer is coming back to a blank screen after suspend
<mjg59> mdke: It'll be fixed
<mdke> great
<mdke> ok it's #16297
<ogra> mdke, gnome-screensaver is in universe :)
* jdub is doing a windows install on his dell laptop to compare.
<mdke> ogra, i don't mind, but it's on my computer after a default breezy install
<jdub> *SO MUCH TEH SUCK*
<mdke> heh
<bddebian> heh
<mjg59> mdke: ubuntu-desktop no longer depends on it
<jdub> the only network device supported by the install out of the box is firewire
<mjg59> jdub: What hardware?
<jdub> no drivers for any of the other major hardware
<jdub> mjg59: Dell X300
<mjg59> jdub: Uhm.
<mjg59> That really shouldn't be the case
<jdub> you have to stick in the other dell CD and go through a smegridden driver install process
<mjg59> Oh, Windows? Ha
* OculusAquilae is away: there :-)
<mdke> yeah windows does that
* OculusAquilae is back.
<mjg59> OculusAquilae: Please don't set your away status publically
<jdub> somehow, they didn't even manage to get the OEM install CD right
<mdke> mjg59, so if ubuntu-desktop no longer depends on it, how does it get removed?
<jdub> that said, at least i'm getting firmware updates and stuff :|
<OculusAquilae> mjg59: ok
<mjg59> mdke: xscreensaver probably ought to conflict with it, but doesn't seem to
<mjg59> ogra: ?
<mjg59> ^
<mdke> i guess people might want both
<ogra> mjg59, Keybuk firbid me to do that, the Conflicts field isnt for such cases he says, see #16128
<ogra> s/firbid/forbid
<mdke> however i think a way should be figured out in order to remove it from people default breezy systems
<mdke> people/people's
<ogra> (brware, its rather a novel than a bug)
<Keybuk> that's right; such a conflict would prevent people who have gss installed from upgrading ubuntu-desktop
<Keybuk> Conflicts != Breaks
<ogra> :)
<tseng> Keybuk: i have a dpkg question, btw
<mdke> Keybuk, so is there any solution to get gss removed from people's systems?
<Keybuk> mdke: no, none
<Keybuk> other than ask them to
<Keybuk> or remove it from the archive and replace it with an empty package
<ogra> mdke, the same as with polypaudio in hoary
<tseng> Keybuk: mono-assemblies-base became mono-classlib-1.0, so m-c-1 Replaces m-a-b
<Keybuk> tseng: sure, any time
<ogra> (manual remove)
<Keybuk> tseng: right?
<tseng> Keybuk: but, symlinks dont get replaced properly
<mdke> ah that sucks
<ogra> yup
<ogra> about time to fix dpkg :)
<Keybuk> tseng: what doesn't get replaced?
<mdke> ogra, ok that seems like a good candidate for releasenotes
<ogra> really ? 
<tseng> Keybuk: it seems like symlinks from m-a-b get removed and not replaced by m-c-1 on hoary->breezy update
<Keybuk> tseng: are the symlinks in both packages, or created by maintainer scripts?
<tseng> Keybuk: created
<mdke> ogra, sure, it is a known issue which is not going to be fixed right?
<Keybuk> tseng: then it's not a dpkg problem -- it's a bug in the maintainer scripts
<ogra> it is fixed for all upgrades after last week and for all new installs
<tseng> Keybuk: i think they are foo.links, looking
<ogra> and for all people that didnt upgrade the week it wasnt in
<mdke> ogra, a lot of people upgraded at PR
<ogra> s/wasnt/was
<Keybuk> I think debian/*.links is a debhelper thing, so they should go into the package
<ogra> it wasnt in pr
<ogra> it entered afterwards
<mdke> ogra, that is the problem
<mdke> ogra, so everyone who dist-upgraded before it came in, has the issue
<ogra> nope
<mdke> assuming they do fairly regular upgrades
<ogra> everyone who upgraded *during* it was in
<tseng> Keybuk: its hard to tell much of anything on a clean breezy install, can i make myself a tracker bug and CC you?
<mdke> *sigh*
<tseng> Keybuk: so that you can hit me with a cluebat.
<bddebian> heh
<Keybuk> tseng: please ... I'll have more time to look when it's not Sunday :p
<mdke> ogra, everyone who upgraded to breezy before it came in, is likely to have upgraded *during* it was in, because most people upgrade their system on a regular basis
<tseng> Keybuk: great, thanks.
<ogra> mdke, anyway, it will affect people that should know what to do, but not the masses that upgrade on release, its a development version... i would put a note anywhere, but not in the official release notes
<tseng> Keybuk: what was your bugs email
<mdke> alright we can think about it
<Keybuk> scott-bugs@ubuntu.com
<Keybuk> if gss is so broken nobody in their right mind would want it, why don't we replace it with an empty package?
<mdke> +1
<mdke> then bring it in for dapper
<ogra> Keybuk, because seb128 instists to have it in immediately in 3 weeks if dappr opens
<ogra> and i tend to agree with him
<ogra> since we want to have it ready for dapper release
* bddebian quits
<jdub> and wjmccann is doing great stuff on it
<mdke> is there a problem with having it in in 3 weeks for dapper and not in Breezy?
<Keybuk> if it's in the archive, people are going to install it
<torkel> and it's not _that_ broken, it is only a bit imature...
<ogra> Keybuk, its in universe
<ogra> universe isnt even enabled in the default sources list
<Keybuk> sure, but people upgrading through breezy got it dragged in because it was in main for a while
<mdke> quite
<mdke> even if they don't have universe enabled
<mdke> they still have it
<ogra> torkel, i think there are some additional breakages we'll have to fix... GL seems not to work right on many systems
<ogra> while the same screensavers work flawless in xss
<torkel> ogra: yeah, there are some work needed to get it in good shape
<ogra> yup
<ogra> nd enhancements (i want the fade code in there before we ship it for example ;) )
<jdub> mmm. fast gamma fading.
<ogra> and the dbus problem needs a clean solution... 
<pitti> Mithrandir: tbird 1.0.7 has been released, yay
<zyga> what has happened to the neet shadow in gksu?
<zyga> now the window (without chrome) looks really bad
<ogra> yes, it should have a border
<zyga> IMHO the shade was better
* ogra is glad the ugly 3 step fading is gone
<zyga> but I guess it was removed due to performace
<ogra> nope, due to ugliness
<ogra> the implementation is wrong
<ogra> it will look cool if it once uses the X servers compose extension 
<tseng> i liked the fading ogra
<tseng> it was at least better than the gnome logout fade
<ogra> yes, thats odd too
<Mithrandir> pitti: excellent
<ogra> pitti, great, is there a backport of it :p
<zyga> I second tseng's opinion
<zyga> hmm guys - how about a pygtk gui with three buttons, install standard ubuntu gnome destktop packages (gnome-desktop), install yada yada kde (kubuntu-desktop) and quit?
<tseng> erm, why?
<Keybuk> it'd look even cooler if we replaced X with something a little less 18th century <g>
<zyga> clueless users could hit one button and get kubuntu 
<\sh> zyga: hu?
<Keybuk> zyga: surely those kind of users are better served by the different CDs ?
<tseng> clueless users can download kubuntu iso in the first place
<\sh> zyga: don't tell me I'm clueless ,-)
<zyga> hmm
<zyga> \sh: I dont ;-)
<zyga> but clicking on one button is better than explaining apt-get or synaptic
<\sh> zyga: what about "http://go-ubuntu.net/" ? have a windows activeX control and is asking: "Do you want to install [ ] Ubuntu [ ] Kubuntu [ ] Xubuntu?"
<Keybuk> is there a user who can't drive synaptic and yet understands the difference between GNOME and KDE?
<zyga> \sh: go-ubuntu? :-)
<zyga> hmm
<zyga> Keybuk: YES!
<Keybuk> zyga: show me one
<Keybuk> understanding the difference between desktop environments to me suggests either
<Keybuk> 1) a level of clue
<Keybuk> 2) advice received from others
<Keybuk> 1 suggests they could handle synaptic
<zyga> Keybuk: I'm promoting ubuntu among my friends and believe me that at leas one does not understand packages or what they are but she prefers kubuntu and an easy way to get it (Apart from second CD) is nice IMHO 
<Keybuk> 2 suggests the fact there's two CD options would be fine
<infinity> 3) Love of screenshot bling.
<Keybuk> zyga: why "apart from second CD" though?
<zyga> Keybuk: I gave them ubuntu cds
<zyga> (they are clueless users type)
<ogra> zyga, give them kubuntu CDs then :)
<Keybuk> I seriously don't think there's any way you could describe this app without relying on clue
<\sh> zyga: yes...something like the ximian people did before they were bought by novell..."go-ximian.org" ,-)
<zyga> one has recently asked me to install 'the windows program, linux program does not handle my boyfriends game'
<zyga> that's a quote ;-)
<zyga> \sh: interesting
<zyga> \sh: err, no such domain
<Keybuk> zyga: hasn't existed since Ximian Desktop got dropped
<zyga> BTW: how can one post at planet.ubuntu.com?
<jdub> zyga: if you're an ubuntu member, send me your rss feed
<jdub> (you/your plural)
<zyga> jdub: I'm not
<zyga> :/
<zyga> working on it though :-)
<ogra> zyga, go ahead ! 
<ogra> zyga, become a MOTU and build such a selection package for universe if you think it helps your users ... and then teach them to use synaptic to install this package ;)
<bddebian> Heh
<zyga> I feel a feedback loop building inside my brain
<zyga> hmm
<ogra> heh
<zyga> nevermind... I'll never work on one cd anyway
<\sh> zyga: it's new and secret ;) no..it was just a joke ;)
<Keybuk> zyga: there's no python-gtk in kubuntu ... you'd have to have a qt version too <g>
<bddebian> ogra: Nice recruiting tactic btw ;-)
<ogra> heh
<\sh> zyga: Keybuk is right, the pygtk there is called pyqt and better pykde ;-)
<zyga> Keybuk: true
<zyga> Keybuk: the package could be called 'this-gui-looks-bad' ;-)
<Keybuk> and would it uninstall ubuntu-desktop if you installed kubuntu-desktop, and vice-versa?
<\sh> Keybuk: no
<zyga> hehe, exactly
<\sh> Keybuk: not as it works now ;)
<Keybuk> so how would the user's session change?  I'm not even sure that the xdm changes either
<\sh> Keybuk: but I can do a "Replaces: ubuntu-desktop\nConflicts:ubuntu-desktop" easily ;)
<Keybuk> \sh: I know where you live.
<\sh> Keybuk: without a session logout? never
<\sh> Keybuk: ah well...wanted to move to peru anyways ;)
<ajmitch> \sh: I've heard it's nice this time of year :)
<zyga> as far as crazy packages go, no-kde or no-gnome could be nice to get rid of all respective stuff 
<\sh> ajmitch: and they want to push linux ;)
<Keybuk> zyga: it could have pretty screenshots of the default desktop environments ... and if it could have "xfce" and stuff added
<Keybuk> could be a cute ap
<zyga> Keybuk: like 'hi user, select how you would like your desktop to look like'
<zyga> an after-install prompt
<zyga> hmm :-)
<Keybuk> it'd have to change the users default session, of course
<zyga> yes
<zyga> hmm :-)
<Keybuk> cute project anyway
<bddebian> Why don't you all just install xpdm and be done with it
* bddebian hides
<zyga> bddebian: I guess a small plugin infrastructure could be added ;)
<Keybuk> bddebian: not come across that one, screenshots?
<zyga> bddebian: you could add anything you want then
<bddebian> Keybuk: http://www.xpde.com
<Keybuk> I actually quite like the XP greeter
<ogra> eek
<Keybuk> MS put a huge amount of user research into it
<bddebian> greeter?
<Keybuk> "welcome" screen
<ogra> but a fake XP environment on top of linux is odd... it generates expectations that the system works like XP
<Treenaks> bddebian: "Please click on your name"
<bob2> haha
<ogra> (crashes filling up memory, getting slow)
<Keybuk> it works well, it's obvious what you have to do, it's used for both login and "unlock" -- it makes no need for the user to understand the difference between starting a new session or resuming an existing one, etc.
<Keybuk> they just click on their name, and enter their password
<Keybuk> it's cute
<ogra> (apart from looking like a bonboniere)
<bddebian> Ahhh
<jdub> Keybuk: hopefully we'll be able to pull that off for gss in dapper
<bob2> that would be pimp
<Keybuk> can I put money now that if we finally get a face browser on the login screen, at least one person copies the face of one of the five-way ? :p
<Keybuk> I want to be the girl with the digitally edited pig-tails
<ogra> digitally edited pig tails ? 
<Keybuk> ogra: you'll see :p
<ogra> heh :)
* ogra looks forward to have a Keybuk pic on every ubuntu greeter :)
<Keybuk> nah, I don't look good in pig-tails
<Keybuk> only jdub can pull that of
<ogra> lol
<ogra> depends how beardy he is... 
<mjg59> Is there a way to get a dump of my current xkb state?
<segfault> how's colony5? :)
<ogra> released
<segfault> going to install it right now, and erase my reiser4 partition
<segfault> too buggy yet
<ogra> good move :)
<segfault> so, the language packs will fit in the 700mb live cd?
<Chipzz> under what product is linux-image in bugzilla?
<pitti> Chipzz: just "linux"
<jdub> mjg59: do you remember which bios version the X300 you tested with had?
<spayne> has anyone managed to get Skype installed on Breezy?
<infinity> It's a QT app, isn't it?
<infinity> And most likely still built for the old C++ ABI.
<infinity> Their "completely static, including its own copy of QT" binary may be the way to go, until the provide one biult with g++-4.0
<infinity> s/the provide/they provide/
<mjg59> jdub: I haven't had an X300 to test
<jdub> oh
<infinity> I have an X300 (on my T43).  No idea what the video BIOS version is.
<mjg59> infinity: Dell X300, rather than ATI one
<infinity> Oh, silly me.
<torkel> spayne: the 1.2.0.11 .deb should be installable. The newer deb (1.2.0.17) depends on libqt3c102-mt which is not available in breezy
<spayne> i used the ubuntuguide one thanks
<torkel> spayne: which one?
<spayne> http://frankandjacq.com/ubuntuguide/skype_1.2.0.11-1_i386.deb
<torkel> yeah found it
<Keybuk> hmm, is ethereal known-busted?
<ogra> not here (but probably not up to date)
<ajmitch> Keybuk: capabilty module issue with latest kernel, iirc
<ajmitch> ie the module stopped getting loaded by default for some reason
* ajmitch could be wrong about it breaking ethereal though
<ajmitch> http://bugzilla.ubuntu.com/show_bug.cgi?id=16178 has the details
<Keybuk> fair enough
* Keybuk just uses tcpdump to capture for now
<ogra> Keybuk, why not modprobe capabilities ? 
<Keybuk> ogra: cause already capturing <g>
<Keybuk> and ethereal can read tcpdump output
<ogra> heh
<Keybuk> once I ruled out SSL (well, openssl went "meh?") I figured I'd just capture the network transmission of this thing
<Keybuk> and then read it later and look for patterns
* netjoined: irc.freenode.net -> zelazny.freenode.net
* netjoined: irc.freenode.net -> zelazny.freenode.net
* netjoined: irc.freenode.net -> zelazny.freenode.net
<Robot101> tseng: it looks like a kernel bug (see a later comment) rather than an excessive entropy user
<Robot101> tseng: it's a 2.4 SMP box
<BenC> anyone know what creates /lib/modules/`uname -r`/volatile?
<jdub> BenC: linux-restricted-modules
<jdub> /etc/init.d/linux-restricted-modules-common / lrm-manager
<BenC> thanks
<dholbach> hi
<tritium> hi dholbach 
<dholbach> tritium: hi michael, how are you?
<tritium> dholbach, fine, thanks.  How are you, Daniel?
<dholbach> tritium: fine, i had a charming weekend :)
<tritium> awesome :)
<jdub> hey dholbach 
<dholbach> jdub: hey jeff, how are YOU?
<jdub> rocking!
<jdub> you?
<Robot101> woot woot woot
<dholbach> as i said, i had a charming weekend, so i'm particularly fine :)
<jdub> :-)
<dholbach> i'm still not used to blog regularly - else you'd all know, how the weekend was ;)
<tritium> dholbach, sounds like a weekend worth blogging about...
<dholbach> hmhmhmhmhm :)
<Chipzz> BenC: if you want additional info on that bug, you can poke me here on irc too
<Chipzz> it's not very severe but it tends to leave a messy trail as you upgrade through kernels :/
* jdub needs better icons for the release categories
* maswan hands jdub better tacos for the release categories
<mxpxpod> does anyone use the quick-lounge applet?
<dholbach> i did... some months ago
<dholbach> anything wrong with it?
<mxpxpod> dholbach: if I install a package like gazpacho while it's in the panel and then I go to use the drop down menu of qla, it sigsev's
<dholbach> oh nice
<mxpxpod> dholbach: could you check this out
<dholbach> you couldn't catch a backtrace or something? the upstream guys would be delighted to hear about it, i'm sure
<mxpxpod> dholbach: I couldn't get one... it kept telling me the backtrace was corrupt
<dholbach> hrm
<mxpxpod> maybe I don't have all the dbg packages I need installed... dunno
<dholbach> the -dbg packages shouldn't be an issue
<dholbach> but my trace seems to be corrupt too
<dholbach> grm
<mxpxpod> dholbach: so, it does it to you as well?
<dholbach> mxpxpod: unfortunately so
<dholbach> mxpxpod: i'll open an upstream bug and tell you the bug number
<mxpxpod> dholbach: thanks
<dholbach> mxpxpod: -> query
<phlaegel> infinity: ping
<jdub> Kamion: http://www.flickr.com/photos/s1mpl3/46534041/
<jdub> Kamion: pr0n! :-)
<zyga> hi
<zyga> should any pygtk methods display gtk warnings?
<dholbach> jdub: pr0n? :)
<Kamion> jdub: heh :)
<Kamion> rather random camera angles
#ubuntu-devel 2005-10-01
<dholbach> good night everybody, i'm off to bed
<unkn0wn2u> hey I can't get alsa to work as a normal non root user and when gnome starts it says something about hal failing
<crimsun> this belongs in #ubuntu, thanks
<unkn0wn2u> crimsun, thanks for all the help
<bddebian> Heya bmonty 
<bmonty> hi bddebian 
<infinity> phlaegel : pong?
<bddebian> infinity: phlaegel was wondering why mythplugins built but wasn't showing in the archive
<infinity> bddebian : Ahh.  I assume someone explained it to him?
<evilryu> ola tem algum brasileiro qui?
<phlaegel> infinity: nope.
<phlaegel> infinity: bddebian pointed me to you or to lamont
<infinity> Well, if I had to guess, I'd say that mythplugins has started generating a new binary package that was never in the archive before.
<infinity> So, that needs to be processed before it can be installed.
<phlaegel> hm. I guess that would be mythplugins, which seems to be a new metapackage
<infinity> Looks that way, yep.
<infinity> No big deal, it'll get processed.
<phlaegel> ok, thanks
<bddebian> infinity: Sorry, I thought that but I wasn't sure.
<infinity> w/ii jorton
<nihi1> hi people. ;-)
<bddebian> Hello nihi1 
<nihi1> hello bddebian!
<nihi1> are you a developer?
<nihi1> obviously in ubuntu
<nihi1> ?
<bddebian> Not exactly no.
<nihi1> oh... why are uhere?
<nihi1> :-(
<bob2> haha
<bddebian> I like to bug people :-)
<nihi1> wow
<nihi1> lol:
<nihi1> bob2: you?
<bob2> not really
<nihi1> ok
<bob2> if you have a question, tho, it's way less annoying if you just ask it
<nihi1> what time is it now?
<nihi1> there!
<bob2> breakfast time
<nihi1> ok... well here 4.27 night!
<nihi1> not yet breakfast time!
<nihi1> i have a Centrino do you know if it works whit latest ubuntu default kernel?
<bob2> it works with every ubuntu default kernel
<bob2> but this is a #ubuntu discussion, not here
<nihi1> i agree!
<nihi1> sorry!
<nihi1> i'm going!
<infinity> Wow, that was some brilliant conversation I missed.
<bddebian> ??
<bddebian> infinity: libsdl-erlang_blah-1ubuntu1 will push out libsdl-erlang_blah-1 even with an existing dep-wait right?
<infinity> -EPARSE
<bddebian> Right now libsdl-erlang_0.95.0630-1 is in Dep-Wait for xlibmesa-gl-dev.  I just uploaded libsdl-erlang_0.95.0630-1ubuntu1.  It should replace that in the queue right?
<bddebian> Though will probably have to have the dep-wait cleared?
<infinity> Right.  The upload will happily go through, but it won't build until the dep-wait is manually whacked.
<infinity> Which I can do for you.
<Lathiat> hrm.. does anyone else have the large style battery applet, for me it shows empty while its 100% full (and the text tag says 100%, so its not seeing it wrong)
<bddebian> infinity: Yeah I knew that, I'm just waiting for my ubuntu1 version to show up. :-)
<bddebian> Lathiat: I don't have that problem currently
<infinity> bddebian : Looks like it's gone in already.
<bddebian> Hmm, I don't see it.
<infinity>   Version             : 0.95.0630-1ubuntu1
<infinity>   State               : Needs-Build
<infinity> (etc)
<infinity> I cleared the dep-wait just now.
<bddebian> Thank you
<Lathiat> why dont old dep-waits clear on new packages?
<infinity> It's an intentionaly feature, though probably outmoded in Ubuntu's use case.
<infinity> s/aly/al/
<infinity> The idea is that you don't want to waste bandwidth and/or CPU on building a new package until all the dep-waits are satisfied.
<bddebian> Aye
<infinity> So, if libfoo is broken on archbar, and I dep-wait packagequux on libfoo (>> 1.2.3-1brokenver), then no matter how many times packagequux is uploaded, I won't bothere trying to rebuild it until libfoo is uploaded with a (presumably) fixed version.
<infinity> (Insert other use cases here)
<bddebian> Kinda like my axiom, which I still don't understand :-(
<infinity> However, we can use it for more clever things too, like intentionally holding back packages so they don't build against known-incorrect dependencies, etc (for fear they they WILL build, WILL be uploaded, and WILL be buggy)
<infinity> Hrm.  What's the deal with axiom/gcl?
<bddebian> infinity: I don't know.  It built/installed locally without ever complaining about the gcl version (and it should have).  I have asked elmo to sync the newer gcl. :-(
<infinity> Oh, libsdl-erlang built fine everywhere, BTW.
<bddebian> Awesome, thx
<infinity> If it doesn't actually need the newer gcl, you could just relax the build-dep.
<bddebian> Yeah but it's just a -6 release update and should sync better next go-round.
<infinity> True.
<infinity> Looks like Camm bumped the build-dep due to his changes in how gcl/axiom and friends pull in binutils-dev and do evil things with it.
<infinity> (Very evil things, for the record)
<bddebian> axiom is fully evil period :-)
<bddebian> Took like 5/6 hours to build after several attempts at getting the X libs crap straightened out :-)
<infinity> Most of the packages Camm maintains are evil.  To be fair, it's the nature of complex math software to be evil, it's not really his fault. :)
<bddebian> Oh aye, I wasn't blaming him.
<bddebian> Gnight folks, thanks again infinity 
<fabbione> morning
<pitti> Good morning
<fabbione> morning pitti
<pitti> Hey fabbione 
<jkrogh> morning.
<jkrogh> I've tried to use the ltsp-setup from breezy.. it seems to work flawless and I got to the 
<jkrogh> gdm login screen of the server in the first shot. 
<jkrogh> But my clients looses the keyboard when X starts.
<fabbione> jkrogh: do you mean they lose the layout, or the keyboard just doesn't work?
<jkrogh> The X-server doesn't respond to the keyboard at all. 
<jkrogh> I can press "disconnect" using the mouse and get a shell on the client if I press alt+F2 before the X-server starts again. 
<fabbione> jkrogh: hmm interesting.. could you please boot up a client, switch to console before login and take a copy of /etc/X11/xorg.conf ?
<fabbione> i wonder if the X config is doomed
<fabbione> but i suggest to collect these info and put them in a bug on bugzilla.ubuntu.com
<fabbione> Component: ltsp
<fabbione> it might not be X at fault here
<fabbione> but some generated config files
<bob2> is ubuntu express happening for breezy?
<fabbione> afaik is there already, isn't it?
<jkrogh> How do I get xorg.conf out of there? 
<fabbione> jkrogh: you should be able to scp it from the workstation to the server
<pitti> siretart: ping
<siretart> pitti: pong
<siretart> did I break something (again)?
<pitti> siretart: no, don't worry :-) Just replied to your tabextensions mail on security-review
<siretart> puh :)
<bob2> win46
<bob2> siretart: thanks for moving so quickly, btw :)
<siretart> bob2: hehe, just 1 borked upload ;)
<siretart> bob2: btw, do you happen to know when debian will switch over to python 2.4? 
<bob2> siretart: not until after the C++ transition is done, I gather
<jkrogh> http://pastebin.com/374405 -> xorg.conf from the client.
<siretart> okay
<bob2> so you'll have to have that diff for a while
<siretart> will do
<siretart> I fear there are still issues with lyx
<fabbione> hey siretart 
<siretart> will look after them
<siretart> hi fabbione!
<bob2> siretart: hm, how so?
<siretart> fabbione: I see igor is building packages :)
<fabbione> siretart: yup :)
<siretart> bob2: there is no /usr/bin/lyx for me. (huh?)
<fabbione> i did set it up saturday
<siretart> :)
<fabbione> siretart: but i had no problems at all to upgrade to 2.6.12-9 and brezzy
<fabbione> breezy even
<fabbione> (yeah sarge was too boring ;))
<bob2> oh, crap
<bob2> maybe I broke the alternative thing
<siretart> fabbione: hehe, I've seen that :) - it did survive the reboot :)
<jkrogh> Can I find the X-servers log anywhere? 
<bob2> jkrogh: /var/log
<fabbione> siretart: yeah.. no problems at all
<siretart> fabbione: just one question, won't the sparc buildlogs show up on p.u.c/~lamont/buildLogs/?
<fabbione> siretart: no, they show here: http://bld-3.mmjgroup.com/buildLogs/
<siretart> aah
<fabbione> we are working on getting them all together
<siretart> aah. okay. I was confused because ia64 is appearing at lamonts site
<fabbione> siretart: that's because ia64 is builded at the DataCenter
<fabbione> hppa and sparc no
<siretart> aah. this explains
<fabbione> we can't use all the infrastructure yet
<fabbione> anyway we got some install test
<siretart> okay, okay. Now I understand
<fabbione> there are 2 glitches in the installer (nothing fancy to fix)
<fabbione> and that's it.. we need a xorg upload to get ubuntu-desktop installable
<fabbione> so we are looking very very good for breezy
<siretart> cool! :)
<fabbione> anyway.. i need to go offline a few minutes
<fabbione> bbl
<siretart> bob2: there really seems to be some foo in the ubuntu package
<siretart> bob2: with that alternatives
<siretart> bob2: shouldn't lyx-qt.postinst install the alternatives?
<bob2> yes
<siretart> there is just the snippet about update-menus in there, no call to install-alternatives
<bob2> guess that's a bug then
<siretart> and in the source package, there is no debian/lyx-qt.postinst even
<jkrogh> Should I be able to login to the console using the standard logins from the terminal server? 
<bob2> siretart: yes, debhelper generates it
<siretart> ah. hm
<bob2> it'd be great if you could file a bug in Debian
<siretart> first I'll see if that bug even exist in debian
<siretart> but will do
<bob2> thanks a lot :)
* bob2 -> dinner
<siretart> bye, bob2 
<fabbione> re
<jkrogh> Seems like a regular X-bug to me. crtl+alt+backspace doesn't work either. 
<sivang> Hhowdy all
<fabbione> jkrogh: yes, you can login on standard console
<fabbione> jkrogh: please file a bug on bugzilla and add the xorg.conf as i asked before
<jkrogh> I've done that. 
<fabbione> jkrogh: ok, bug number?
<jkrogh> 16355
<fabbione> jkrogh: gdm?? our ltsp doesn't use gdm at all
<siretart> bug filed, I'm off to uni. cu
<jkrogh> No.. but it makes an X -query terminalserver
<jkrogh> where I get the gdm/ubuntu prompt over XDMCP
<fabbione> nah
<fabbione> you have something really wrong on your setup
<fabbione> we don't use XDMCP at all
<pitti> Good morning jane_ 
<fabbione> jkrogh: the Xorg.0.log is not complete afaict
<jkrogh> Ok.. then I've accidentially tested the SERVER option of lts.conf
<fabbione> don't use them
<fabbione> there is no need to
<\sh> mdz: please assign all amarok issues via bugzilla to my account, and put riddell as CC, thx
<fabbione> \sh: you can do that yourself i think
<jkrogh> fabbione: Then is the ltsp-setup not a thin but a rather "thick" setup? 
<\sh> fabbione: i did now...but mdz is assigning sometimes the bugs ;)
<fabbione> jkrogh: i dunno all the details of ltsp. i use to test it here once in a while, but i never had the need of that
<jkrogh> Ok, I'm not interrested in running the applications on the client. 
<jkrogh> I need the old-fashined xdmcp-way where all application run on the server. 
<JaneW> hi pitti
<jkrogh> But that should really be a trivial change to the other setup. 
<fabbione> jkrogh: our ltsp executes apps on the server
<jkrogh> Using ssh and X-forwarding? 
<fabbione> jkrogh: you just did something wrong in your setup
<fabbione> jkrogh: yes. 
<fabbione> jkrogh: https://wiki.ubuntu.com/ThinClientHowto
<fabbione> that's all you need
<jkrogh> fabbione: You're right.. Deleting the lts.org changes the setup to the ssh and X thing and now the keyboard works. 
<fabbione> jkrogh: hehe ok, please close the bug than :)
<jkrogh> .. I belive it is a bug anyway. There is no reason in not being able to work within exising xdcmp-setups like LTSP usually does. 
<jkrogh> But that's a feature request. 
<jkrogh> :-)
<fabbione> jkrogh: well whatever :) just adjust the bug to what you think is the right thing..
<jkrogh> KDE isn't available in the menu (probably since KDE isn't installed in the chroot).
<fabbione> the chroot is used only to boot the client and give you a login prompt. i don't even think gnome is installed there
<fabbione> iirc it's the server that offers the list of window managers, since they are executed after you login
<fabbione> but not the chroot itself
<fabbione> also Ubuntu doesn't install KDE by default
<fabbione> (that would be Kubuntu)
<fabbione> so it's unlikely to find such entry in the menu ;)
<jkrogh> I did an apt-get install kubuntu-desktop 
<jkrogh> The users want the choiche :-) 
<fabbione> jkrogh: where? in the chroot or the server?
<jkrogh> On the server. 
<jkrogh> I have not modified the chroot
<fabbione> ok
<fabbione> hold on a sec..
<jkrogh> It is available on the gdm on the "physical" screen. 
<\sh> infinity: ping 
<janimo> Kamion, the installer seems to leave /debootstrap/debootstrap.log on the root fs after done is that intentional?
<fabbione> jkrogh: you will need to file an enanchment bug for that.
<fabbione> jkrogh: the ltsp login manager (ldm) has an hardcoded menu in /opt/ltsp/i386/usr/lib/ltsp/greeters/greeter.glade
<fabbione> jkrogh: at least AFAICS
<jkrogh> Will do.. 
<infinity> \sh : gnop.
<\sh> infinity: I just try to fix enigmail ;) I only have to add an entry for mozilla 1.7.12, right?
<\sh> infinity: in debian/rules and debian/rules.mailnews
<infinity> \sh : It's a bit more irritating than that.
<\sh> infinity: hmm...I think 1.7.12 has the same API version then 1.7.10 && 1.7.11
<fabbione> \sh: don't break enigmail or you will phear the wrath of fabbione
<infinity> \sh : Oh wait, no, that's all it takes.  I have to re-read it every time I do this.
<infinity> \sh : Yo uhave to alter all the OTHER stanzas in debian/rules to exclude 1.7.12 as well.
<infinity> (such an intuitive packaging system..)
<\sh> infinity: yeah..it's really nice to read those rules files...it's too early in the morning for that...and I'm 10 cups of coffee behind
<infinity> \sh : Oh, and regenrate debian/control, when you have the right build-deps installed.
<infinity> \sh : So, install build-deps, make sure they're what you want, then run "debian/rules update_control"
<\sh> fabbione: hmmm...do u want to fix the unmet deps? ,-)
<infinity> \sh : Alternately, just let me upload it.  I did the last couple. :)
<\sh> infinity: that's why I pinged you ... but give me 10 mins to figure out the build system here...;)
<infinity> \sh : I was probably going to hold off until we have a new Thunderbird, but if the new Tbird isn't in sight yet, two uploads makes more sense.
<\sh> hmm..pitti is doing tbird, right?
<infinity> Yeah, but upstream still hasn't released 1.0.7.  They announced it "soon".
<infinity> (Actually, I may end up doing Tbird, I did last time, but... Whatever... No one will do it if it doesn't release)
<\sh> infinity: k..two uploads makes sense then :)
<infinity> Yup.
<infinity> Do test builds before you upload, and check the final debs with "dpkg-deb -c foo.deb" (to make sure the contents look sane) and "dpkg-deb -I foo.deb" (to make sure the control info is sane)
<infinity> The build should fail on the former, but the latter will break if you mess up. :)
<\sh> infinity: I'm testing it anyways..:)
<infinity> (ie: The build won't fail, but you'll make uninstallable binaries and I'll laugha at you)
<\sh> even on amd64...
<infinity> So, test. :0
<\sh> hmm...I think it's a good day to break something ... after my 3rd tft died here :(
<infinity> In other news, enigmail's build system is teh suck, and I keep meaning to talk to asack about making it less so.
<\sh> infinity: after the mess with jdongs backported firefox package...well nothing will shock me anymore
<jsgotangco> mirrormax?
<\sh> yepp
<jsgotangco> *scary thought*
<infinity> Anyone in here have OSX installed and care to carry out an experiment?
<\sh> well...think about this: 10 people who are supporting actively the german ubuntu community, being hit by an uncounted ammount of people complaining...well, it was fun on saturday and sunday
<jsgotangco> \sh, that was nasty, good thing on our side, people are just discovering linux itself...
<sivang> seb128: bon jour :)
<fabbione> hey seb
<seb128> hi sivang fabbione
<fabbione> seb128: you mentioned something about new gnome crack coming in today
<fabbione> is there any specific build sequence we need to care about?
<seb128> fabbione: GNOME 2.12.1 tarballs due today, why ?
<seb128> no
<fabbione> so no new gtk crack or stuff.. right?
<seb128> probably a new GTK and stuff
<seb128> but nothing that require a special change or build order
<fabbione> seb128: well i was asking because sparc is now installable.. and sort of breaking it at 3 weeks from release would be annoying :)
<seb128> just bug fixes tarballs
<fabbione> perfect
<dholbach> good morning
<sivang> dholbach: Moins 
<dholbach> hey sivang 
<sivang> hey vuntz 
<vuntz> hi sivang
<\sh> infinity: hmm...looks ok here
<seb128> hey dholbach
<seb128> hey vuntz
<dholbach> morning seb, how are you?
<vuntz> hey seb128
<seb128> dholbach: great :)
<vuntz> seb128: you're not sleeping? You're waking up early ;-)
<seb128> dholbach: my mailbox is bug flooded to change
<\sh> infinity: only the postinst of enigmail for thunderbird is complaining something about "find"....but it looks like that's thunderbird chrome update util 
<seb128> vuntz: GNOME 2.12.1 ...
<infinity> \sh : Yeah, that's a different bug. :)
<\sh> infinity: ok..so it's not mine :) installation is smooth...so I think I can upload...:)
<vuntz> seb128: 2.12.1 is next week
<\sh> oh damn...it's main ;)
<\sh> I don't upload ;)
<seb128> vuntz: grumpf
<seb128> vuntz: you sure?
<vuntz> http://live.gnome.org/ReleasePlanning_2fTwoPointEleven
<seb128> crap
<seb128> a bug replying borring week again
<vuntz> ahah
<seb128> I'll bother some upstream to get bug fixed
<seb128> let's start with this recent files bug ... vuntz ? :)
<vuntz> seb128: you should add "a bug replying borring week again" to all the comments you make in bugzilla
<dholbach> seb128: you can get the new gtkhtml and rsrv in :)
<dholbach> rsvg
<seb128> dholbach: free to you
<seb128> dholbach: I want to keep my job
<vuntz> seb128: well, I won't look at it before 2 or 3 days
<dholbach> hahahaha
<seb128> the new librsvg breaks the ubuntu bug
<seb128> and gtkhtml is 2.11
<\sh> mdz / Kamion: ok for you to upload enigmail to fix the unmet dep?
<seb128> and it's dobey's tarball
<seb128> s/bug/theme/
<seb128> vuntz: k, I'll mail markmc :)
<dholbach> seb128: won't your patch make it work nicely?
<seb128> dholbach: the purpose of this version is to not need the patch
<dholbach> ah right
<seb128> they changed 100 by 1024 for the tag
<dholbach> that seb... always brilliantly informed :)
<seb128> dholbach: BTW did you track this amd64 crasher?
<dholbach> seb128: in g-s-t?
<dholbach> seb128: there are a couple of amd64 issues in g-s-t, especially the user part of it - none of my tests made it work or showed the actual problem
<seb128> users-admin
<seb128> k
<\sh> infinity: please have a look over the debdiff for enigmail...just need to be sure, that I don't break anything...
<infinity> \sh : Heh, okay..
<dholbach> seb128: it's not improper xml handling, it's not the signedness warnings and not the password generation :-/
<infinity> \sh : Mail?
<zyga> hello :-)
<zyga> we hit slashdot again
<seb128> dholbach: so what is it? BTW if you have cleanup patch fell free to bugzilla them upstream :p
<\sh> infinity: http://linux.blogweb.de/uploads/engimail.diff.gz (please unzip to apply) it's debdiff against ubuntu3 
<\sh> gunzip even
<\sh> argl
<dholbach> seb128: i have no clue what it is
<\sh> infinity: sorry...this is the right url: http://linux.blogweb.de/uploads/enigmail.diff.gz
* \sh should type without coffee 
<infinity> \sh : That should work.
<infinity> \sh : A slightly more verbose changelog entry is always nice, though.
<infinity> \sh : Even if it's just a copy and paste of my previous one with s/11/12/ :)
<jkrogh> fabbione: Have you used the terminal setup or just tested it? 
<fabbione> jkrogh: i only test it. I have no need of such setup on a regular base
<jkrogh> The client has trouble keeping up the nfs-mounted-root-fs here. 
<fabbione> http://bugzilla.ubuntu.com/show_bug.cgi?id=12942 <- is this problem by any chance?
<verwilst> hellow!
<verwilst> anybody having problems with laptop-detect hanging when it's being installed?
<verwilst> during first bootup ( ubuntu breezy preview iso )
<verwilst> it starts to install laptop-detect, but just sits thre
<verwilst> there
<verwilst> on the console i can't see anything strange
<verwilst> it just stops
<fabbione> verwilst: it's quite unlikely that laptop detect can hang...
<verwilst> fabbione: it's not laptop-detect that hangs
<verwilst> it's apt
<verwilst> well, it doesn't really hang
<verwilst> since when i do ctrl - c on the console where apt is shown, it just re-does apt-get install laptop-detect
<verwilst> and hangs at the same place
<verwilst> ( last lines are when it shows NEW pkgs that will be installed
<fabbione> verwilst: that's weird.. did you install from CD?
<verwilst> yip
<verwilst> i installed a system correctly with it too
<verwilst> this is on a Dell PowerEdge 2850
<fabbione> verwilst: i have no idea sorry.. open a bug 
<verwilst> just thought i'd ask here first ;)
<jkrogh> fabbione: Thanks .. i'll investigate. 
<\sh> infinity: ok will do :)
<fabbione> jkrogh: no problem
<\sh> infinity: now I will need the ok of mdz/kamion, or?
<infinity> \sh : No, you're just resolving unmet deps.  Blame it on me if you get yelled at.
<\sh> infinity: your word in gods ear ;)
<\sh> uploaded
<infinity> \sh : Hah, you actually DID copy-n-paste my changelog entry. :)
<infinity> \sh : You owe me a beer at UBZ for taking me too literally.
<\sh> infinity: fck...I missed the mozilla SDK s/1.7.10/1.7.11/ 
<infinity> No, that's correct as it is.
<\sh> infinity: how many beers I owe you now? ,-)
<infinity> It's using the 1.7.10 SDK.
<infinity> There is no .11 or .12 SDK in the orig.
<\sh> elmo - 5 ; infinity - ?? 
<Treenaks> \sh: elmo - 5 = infinity ?!
<infinity> Likely a few dozen.
<infinity> You can stop buying after you get sexy.
<\sh> infinity: I'm not going to get sexy ;)
<infinity> Hey, if I get drunk enough, anything's possible.
<\sh> infinity: I'm already sexy ,-)
<jkrogh> I seem to be hit by the "rsize=32k" bug but the client doesn't seem to respect my changes in pxelinux.cfg/default
<dholbach> i can't change "upstream ubuntu" bugs in malone *cry*
<dholbach> Diziet: ok, if i assign the firefox in malone to you?
<Kamion> janimo: kind of, but that'll be fixed before release anyway (by merging debootstrap 0.3.1.6)
<dholbach> hi janimo :)
<Kamion> verwilst: what kind of install are you doing? I assume it's a server install, to start with
<\sh> dholbach: u r spamming ,-)
<verwilst> Kamion: yep
<verwilst> http://bugzilla.ubuntu.com/show_bug.cgi?id=16365
<verwilst> maybe server installs haven't been tested as much ;)
<Kamion> verwilst: did you skip anything in the first stage of the installer?
<Kamion> like "copy packages to hard disk"?
<verwilst> Kamion: nope
<verwilst> the packages are there
<mvo> can a english native speaker please have a look at #16295?
<dholbach> seb128: ok, if i change the "gnome team" bugs in malone to be sent to ubuntu-desktop@?
<verwilst> in /var/cache/apt/archives
<seb128> dholbach: no
<dholbach> morning mvo :)
<dholbach> seb128: hm, why?
<seb128> dholbach: it's already too much flooded with desktop bugs
<mvo> hey dholbach 
<Kamion> verwilst: then please attach /var/log/installer/syslog, /var/log/base-config.log, and /var/log/base-config-pkgsel.log to the bug
<seb128> dholbach: that's not possible to catch with the universe bugs too
<dholbach> i see
<dholbach> hmhmhmhm
<Kamion> verwilst: it's probably a duplicate of other bugs though - there's a standing problem with apt media-check messages which I know is not resolved yet
<dholbach> i'd like to have them on a list too
<seb128> yeah, but a motu one
<verwilst> Kamion: ah damn, i rebooted and installed packages manually :p
<seb128> we need to keep the desktop one useful
<dholbach> seb128: jdub will cry if i will force him to open a ubuntu-universe-desktop@ list :)
<verwilst> Kamion: but i'll reinstall again tomorrow, and attach those files, oki?
<seb128> dholbach: ha ha
<\sh> elmo: please sync rrdcollect_0.2.3-2 from debian unstable (universe that is) thx
<verwilst> hell, i'll reinstall now, brb
<Kamion> verwilst: that'd be good, thanks
<jdub> dholbach: *CRY*
<Kamion> mvo: #16295 confirmed
* dholbach comforts jdub a bit
<ogra> dholbach, jdub, hey what about a ubuntu-universe-desktop-backports-and-other-crack list
<seb128> hey hey jdub :)
<ogra> morning btw
<dholbach> ogra: do my ears deceive me? you said the b* word?
<dholbach> eyes that is
<ogra> hey, they are official now :)
<dholbach> yeah, but i'd like to keep that on a separate mailing list ;)
<mvo> Kamion: thanks
<ogra> dholbach, see my request ;)
<ogra> (just joking indeed)
<\sh> ogra: please do not start again with this crap...I had enough of it the last weekend...
<\sh> ;)
<ogra> heh
<zyga> mvo: why does running synaptic uses different prompt for password than running any other program?
<dholbach> Riddell: is there a KDE team in malone yet?
<fabbione> Kamion: dunno if you read the scrollback, but there is a bug in the debootstrap script for breezy when using buildd variant...
<\sh> dholbach: I don't think so
<dholbach> \sh, Riddell: there should be one
<Kamion> fabbione: no, what?
<fabbione> Kamion: but i am not sure how to fix it.. hounestly.. line 20 of /usr/lib/debootstrap/scripts/breezy 
<Kamion> well, I did read the scrollback, but may have missed some
<fabbione> Kamion: it chokes on packages with a "-" in the name
<fabbione> i think it's something you did.. because i couldn't find it in any other script
<siretart> libxp6 was moved to main?
<pitti> siretart: yes
<fabbione> and i could reproduce it on any arch..
<Kamion> it's not something I did originally, but it may not be in any of the other scripts *any more*
<fabbione> Kamion: ok.. i didn't track the origin to be hounest.. 
<Kamion> actually yes, it's still in the etch script, look there
<fabbione> Kamion: that's weird.. because it does choke badly
<Kamion> oh, hum, I see the problem
<Kamion> will fix
<Kamion> I got the arguments to add wrong
<fabbione> ok thanks :)
<siretart> pitti: there is a upgrade issue, hoary version 6.8.2-10.1 beats breezy 6.8.2-10ubuntu1
<pitti> siretart: what's that, Xorg?
<pitti>       xorg |   6.8.2-69 | http://archive.ubuntu.com breezy/main Sources
<pitti>       xorg | 6.8.2-10.1 | http://security.ubuntu.com hoary-security/main Sources
<siretart> hoarys libxp6 was build from xorg sources, breezy libxp6 is an own sourcepackage, libxp
<pitti> that looks fine to me
<pitti> ah, libxp
<fabbione> oh
<fabbione> meh
<fabbione> pitti: i can fix that...
<pitti> siretart: right, so we need to bump the version number in breezy
<siretart> and now its in main, so I cannot fix that anymore :)
<fabbione> siretart: no problem.. i will do it
<fabbione> i will bump the epoch
<siretart> okay
<pitti> fabbione: uh, epoch?
<pitti> fabbione: why not just -11ubuntu1?
<dholbach> siretart: you should request upload privileges for main
<siretart> I was quite unsure about upstream version anyway
<fabbione> pitti: yeah that would work too
<Kamion> fabbione: fixed in 0.3.1.6ubuntu1, thanks
<siretart> dholbach: do you really think I deserve it? ;) - seriously, I can do enough work in universe, when I get to my limits I will apply for main, for sure
* pitti tries to avoid epochs whenever possible
<dholbach> siretart: i think you do
<seb128_> pitti: what do you call "double-sided"? page 1 3 5 and then 2 4 6 ?
<seb128_> etc
<seb128_> 7 9 8 10 ... :)
<pitti> seb128_: I rather guess "1 2" on one page, then "3 4" on the next, and so on
<seb128_> oh, k
<fabbione> Kamion: thanks to you :) sparc will appreciate a lot..
<fabbione> Kamion: btw we got jbailey to test the install CD.. it works like a charm except the ramdisk_size option.
<fabbione> Kamion: i think the changes we did for hoary aren't good enough.. 
<fabbione> Kamion: but if we can't fix them for breezy, a release note will do
<siretart> fabbione: install cd for sparc?
<fabbione> siretart: yeps
<siretart> sweeet! :)
<verwilst> Kamion: ok done
<fabbione> Kamion: permission to upload libxp.. no changes.. only a version bump to make it upgradable from hoary
<Kamion> fabbione: approved as long as it isn't an epoch
<fabbione> no epoch
<fabbione> just normal bump
<Kamion> sure
<fabbione> done
<pitti> Kamion: do we need to have all uploads approved now?
<Kamion> 10.1ubuntu1 would do fine
<Kamion> pitti: no, I'm not quite sure why fabbione's asking
<fabbione> Kamion: that would break at the next Xorg security upgrade :)
<pitti> Kamion: no, that would conflict to the next Xorg security update to hoary
<Kamion> or I suppose 11ubuntu1, yes
<fabbione> Kamion: 11ubuntu1 is ok
<pitti> fabbione: :-)
<fabbione> eheh
<verwilst> Kamion: files added
<verwilst> if anything else, let me know ;)
<sivang> seb128_: I guess you've not had time to upload my pkg / review it?
<seb128_> sivang: no, I would have say so
<sivang> seb128_: (I don't want vuntz slapping me for not removing the items from the clock applet ;-) )
<verwilst> Kamion: since ubuntu 5.10 will be installed on 10s of servers, it would be nice to have it fully working ;)
<sivang> seb128_: k
<seb128_> sivang: but you should have send a mail when I asked for it
<seb128_> sivang: without a bugzilla or a mail it's not listed on my stuff to do
<Kamion> verwilst: I've tested my CD releases with server installs as it happens, and they worked fine for me :P
<Kamion> but let's see
<verwilst> hehe
<Kamion> verwilst: that is not the preview release you're using
<Kamion> Sep 26 10:42:23 cdrom-detect: Detected CD 'Ubuntu 5.10 "Breezy Badger" - Alpha i386 (20050831)'
<Kamion> preview was released 20050908
<verwilst> goddamn
<verwilst> i took the wrong cd
<verwilst> ugh
<verwilst> ok, i'll reinstall again :p
<sivang> seb128_: sure, sending now
<Kamion> was fixed before preview, closing the bug
<\sh> pitti: du u have to approve membership to security-review ML?
<Kamion> (archive-copier 0.3.1)
<pitti> \sh: yes
<janimo> Kamion, which is the minimal amount of RAM required by the installer
<Kamion> verwilst: thanks for the logs
<verwilst> Kamion: bbiab ;
<verwilst> ;)
<janimo> I get OOM for debconf with 64M server install
<Kamion> janimo: I thought it was under 64MB; I'll check it out
<verwilst> Kamion: np :d sorry for the stupid mistake ;)
<\sh> pitti: ok...I thought it was an error on my side :)
<Kamion> janimo: at what stage?
<janimo> when trying the network module
<Kamion> "the network module"?
<janimo> I do not have any network
<pitti> \sh: I approved you
<verwilst> Kamion: i'll retry again now, and let you know the outcome
<janimo> ethconfig
<Kamion> oh, netcfg
<janimo> I have no network at all
<janimo> pcmcia NIC but not inserted
<Kamion> that's very surprising; we may have to tweak lowmem
<janimo> that gets it stuck at that pahse
<\sh> pitti: thx ..
<janimo> and if I stick it in it repeatedly displays the progressbar (load linux-kernel...-nic module)
<janimo> and gets killed in a cycle
<Kamion> yes, standard out-of-memory installer symptoms
<janimo> elmo, when you have time theres xubuntu-meta in NEW (universe) pending upload approval,thanks
<Kamion> elmo looks at new packages regularly; I don't believe he needs reminders for each
<Kamion> one of the archive maintenance programs produces a report of them
<janimo> Kamion, ok, the return mail said once a week
<Kamion> xubuntu-meta             | 0.2             | source       | 1 hour old
<Kamion> that's a bit early to be worrying ;)
<janimo> Kamion, I did not know when the week is supposed to start, or if at this stage the standard rules still apply
<janimo> I wasn't worrying though :)
<Kamion> quick rule is "don't nag" ;)
<janimo> ok ;)
<janimo> especially not elmo :)
<Kamion> hmm, I can reproduce that 64M problem here
<Kamion> bah
<sivang> bob2: have you sorted out that vmware issue you had with breezy?
<bob2> sivang: apparently the any2any patch fixes it
<bob2> tho I've not been game to try it again
<sivang> bob2: any2any? kernel patch ?
<bob2> no, vmware "source" patch
<sivang> vm source? LOL
<sivang> s/vm/vmware
<Kamion> god, the installer is using 91MB of memory in lowmem mode before it gets to swapon
<Kamion> that's absurd
<Kamion> it used to be half that
<janimo> hi (belatedly) dholbach :)
<dholbach> :)
<Kamion> doesn't even fit in lowmem mode (77MB footprint). what on *earth* happened?
<ogra> 77MB ? 
<ogra> phew
<verwilst> Kamion: works flawlessy
<Kamion> verwilst: good good :)
<verwilst> Kamion: hehe
<verwilst> Kamion: thanks for the fast response ;)
<Kamion> somebody has utterly hosed the l-r-m udebs
<infinity> If all else fails, blame me.
<infinity> What's hosed about them?
<fabbione> Kamion: they are not hosed
<Kamion> fabbione: they so are
<Kamion> look at their contents
<Kamion> -rw-rw-r--  1 katie katie   139954 2005-04-04 23:50 nic-restricted-modules-2.6.10-5-386-di_2.6.10.5-1_i386.udeb
<Kamion> -rw-rw-r--  1 katie katie  4971190 2005-09-23 13:35 nic-restricted-modules-2.6.12-9-386-di_2.6.12.4-7_i386.udeb
<fabbione> Kamion: yes yes i am looking
<Kamion> they contain lots of stuff that does not belong in the udeb, such as the fglrx and nvidia modules
<fabbione> meh
<pitti> Hi sabdfl 
<fabbione> hey sabdfl 
<sabdfl> greetings all
<sabdfl> good to be back
<sabdfl> jdub, seb128: where's the "About Ubuntu" entry?
<seb128> sabdfl: ask to the docteam, the GNOME part has not changed
<sabdfl> ok
<sabdfl> mdke: ping?
<jsgotangco> sabdfl, think he's out
<jsgotangco> what's up?
<jsgotangco> oh
<jsgotangco> on Yelp?
<sabdfl> jsgotangco: System -> [No About Ubuntu] 
<jsgotangco> i did an email before on how to register the doc in yelp but i guess jbailey hasn't done that yet
<seb128> jsgotangco: seems that /usr/share/gnome/help/about-ubuntu/C/about-ubuntu.xml has been dropped
<jsgotangco> gyahhh
* jsgotangco checks
<infinity> Kamion : Oh joy.  I can fiddle with that after dinner.
<JaneW> infinity: ping
<JaneW> infinity: I see you are now working on LRM
<JaneW> infinity: is everything on track there?
<\sh> pitti: do u think it's worth to updated clamav for hoary as security update? it's a universe package 
<fabbione> \sh: why via security?
<jsgotangco> seb128, the updated file is at https://docteam.ubuntu.com/repos/branches/breezy/gnome/aboutubuntu/C/ on our svn but i believe jbailey hasn't gotten around to uploading it yet at all
<fabbione> if the package really really needs an update, we can propose it as hoary-updates ...
<fabbione> \sh: given that there are enough reasons to do so
<infinity> JaneW : Define "on track".
<infinity> JaneW : It seems to work well enough right now, modulo Kamion's complaint. :)
<\sh> fabbione: well...cause for me it belongs to "security tools" ;) but update is ok, too :)
<fabbione> security tool doesn't mean security repository
<Nafallo> \sh: security tools != security bugs :-P
<JaneW> infinity: ok, sounds ok.
<\sh> fabbione: yeah..I just realized ;)
<seb128> jsgotangco: k, thanks
<fabbione> \sh: plus it is an antivirus.. rarely viruses affect unix machines.
<\sh> fabbione: what is the correct way to propose those updates?
<fabbione> \sh: it depends what kind of update do you need and why...
<fabbione> \sh: usually you ask the release managers..
* infinity heads off for some dinner and family time.
<\sh> fabbione: regarding this anti-virus tool, it's used by <insert your fav. ammount of server installs> and should stay updated as long as hoary e-o-l support lasts..but this is only my opinion :)
<JaneW> infinity: and SoundEvents? I know we are going to tackle this at a UBZ BOF, but the last bit you were going to do was "make sure that all the apps have their default sounds updated to point at common locations" is that done?
<fabbione> \sh: i know what clamav is.. i use it here too ... but than.. the virus list is updated via clamav-fresh service at runtime
<fabbione> \sh: so exactly what kind of problem would you like to address?
<Treenaks> fabbione: sometimes the clamav server gets updated
<\sh> fabbione: https://launchpad.net/malone/bugs/2463
<Treenaks> fabbione: and then you get big warnings when you run freshclam
<\sh> fabbione: e.g.
<fabbione> Treenaks: ok.. so it starts to make more sense...
<\sh> fabbione: and regarding hoary -> breezy package diff is hoary:
<\sh> 0.83-2ubuntu1 vs. breezy: 0.86.2-5 
<fabbione> Treenaks: so the clamav servers are not always backward compatible?
<\sh> and debian unstable has 0.87 something 
<fabbione> \sh: that's called UVF :)
<Treenaks> fabbione: old daemons are not guaranteed to understand the new datafiles after a new engine version is released
<\sh> fabbione: New logcheck line for clamav-daemon (closes: #323132)
<\sh> (from 0.87) 
<JaneW> infinity: If so, I'll update the goals page to reflect this...
<\sh> fabbione: I know :) that's why I ask, if it's worth 
<fabbione> \sh: it's a universe package.. so in theory there is no issue to update it, but be aware of the consequences.
<fabbione> \sh: pushing it to main (as you mention in the bug) will only make it worst.
<\sh> fabbione: breezy universe it's not the problem :) I just requested a sync by elmo yesterday :) 
<fabbione> \sh: because main is close for business or almost
<\sh> fabbione: and pushing to main is dapper wishlist :)
<\sh> fabbione: but I'm only interessted now, if it's worth to update those "universe hoary" packages ;)
<bob2> wtf
<bob2> something blanked X and won't go away
<fabbione> \sh: this is the same problem that volatile.debian.org is trying to address afaik
<fabbione> \sh: it's an endless / chicken-egg problem
<\sh> fabbione: well...if the solution to this problem is, that I eat the egg, so no chicken is born, I'll eat the egg ;-)
<fabbione> \sh: i think a package like clamav can last 6 monhts.. after that we can consider to sugget users to update to the new stable version
<fabbione> \sh: for hoary/breezy i really don't see the big need to address the issue
<fabbione> i would consider instead important to get it right for dapper
<fabbione> (given the longer support)
* fabbione -> food
<fabbione> \sh: we can take the talk in a bit.. ;)
<fabbione> bah horrible english.. but you get the point
<pitti> jdub: here?
<\sh> fabbione: well..we should raise those issues as BoF for UBZ :)
<bob2> ah, my fault, I hit the bios "swap display output button"
<\sh> fabbione: my english is bad enough to understand all sorts of slang ,-)
<pitti> \sh: you mean update to fix the recent vulnerabilities? or to fix signatures?
<\sh> pitti: to avoid those messages to users https://launchpad.net/malone/bugs/2463
<\sh> pitti: and even vulnerabilities in the sources yes
<pitti> \sh: CAN-2005-2919 and -2920 are open
<ajmitch> fabbione: clamav has had a new upstream version a couple of times since UVF, seems to be needed to match new signatures
<\sh> pitti: clamav (0.87-1) unstable; urgency=low
<\sh>   * New upstream version
<\sh>     - Fixes CAN-2005-2920 and CAN-2005-2919 (closes: #328660)
<\sh> pitti: requested sync from unstable yesterday for clamav universe
<pitti> \sh: oh, me too :-)
<ajmitch> heh
<\sh> pitti: hehe :) but what about hoary?
<\sh> pitti: the version from hoary is completly 1) outdated and 2) between hoary and breezy there were some CANs closed, too
<pitti> shawarma: if you insist, prepare a package for hoary-updates; you must test it thoroughly, it must not change and build/install dependencies
<pitti> erm, \sh ^
<pitti> shawarma: sorry, that wasn't for you
<pitti> shawarma: I'd recommend to patch the vulns and just update the data files
<pitti> \sh: ^ (darn)
<\sh> pitti: I don't insist, I only want to know the right way how to deal with this...I mean if it would be in main, there is no issue at all, you'll take care, but universe is not "officially supported" 
<pitti> \sh: or is the hoary version unable to read the current signature files?
<pitti> \sh: as I said, just updating the scan signatures is fine for me (and patching the holes, of course)
<\sh> pitti: let me check the latest packages against hoary...
<\sh> damnit..now my cablemaster ticket is lost
<fabbione> re
<Diziet> Can I prevent people from replying to a bug report ?  I have tried to move the discussion to ubuntu-devel but the lame whiners won't shut up.  Bugzilla is _such_ and _awful_ mailing list system it's untrue and I don't want to use it like that.#
<pvanhoof> ugh
<pvanhoof> when I do groups username as root
<mjg59> Diziet: You can't, no. It's intensely frustrating.
<pvanhoof> I have other groups than when I do groups , as user
<pvanhoof> which is fine, sure
<pvanhoof> however
<pvanhoof> the second command looses the group sbox, (scratchbox group)
<pvanhoof> which makes it impossible for me to use scratchbox
<pvanhoof> since using it as root is also impossible
<Diziet> Maybe I'll just close the report with INVALID and reassign it to an account whose email goes to a black hole.
<mjg59> Diziet: It's even more irritating when you're the original bug filer
<mjg59> Because you *can't* unsubscribe
<pvanhoof> root@lort:/scratchbox # groups freax
<pvanhoof> freax : freax audio video sbox
<pvanhoof> root@lort:/scratchbox # exit
<pvanhoof> logout
<pvanhoof> freax@lort:~ $ groups
<pvanhoof> freax cdrom audio video plugdev
<pvanhoof> freax@lort:~ $
<pvanhoof> so, wtf did you guys do with the group-system of ubuntu breezy?
<pvanhoof> so that I can correct this
<Robot101> pvanhoof: not a pam thingy to give you plugdev if you're local?
<pvanhoof> yes
<Robot101> oh right, missing a group. you know you only gain auxilliary groups at logon, right?
<pvanhoof> oh? :
<pvanhoof> :)
<sivang> can anybody tell me the difference between accept() and socket() ? i.e. they both create a socket and return a file descriptor right?
<Robot101> pvanhoof: aha :)
<Robot101> pvanhoof: log out/in :)
<pvanhoof> so I have to log out?
<Robot101> pvanhoof: or su to yourself
<pvanhoof> and starting a shell?
<Robot101> pvanhoof: no its a function of pam_unix I think
<pvanhoof> aha!
<pvanhoof> freax@lort:~ $ su - freax
<pvanhoof> Password:
<pvanhoof> freax@lort:~ $ groups
<pvanhoof> freax adm dialout fax cdrom floppy tape audio dip video plugdev lpadmin scanner sbox
<pvanhoof> freax@lort:~ $
<pvanhoof> ok
<pvanhoof> thanks :)
<pvanhoof> -- strange pam --
<Robot101> np :)
<tseng> could we please get less pasting of huge blocks
<Robot101> anyway that's in no way an ubuntu development discussion
<pvanhoof> I'll try
<Robot101> so *fwap*
<pvanhoof> *auwch*
<Robot101> sivang: accept is for incoming connections
<Robot101> sivang: incoming: bind -> accept
<Robot101> sivang: outgoing: socket -> connect
<sivang> Robot101: ok, thanks
<Robot101> sivang: sorry, a little misleading, to listen for connections: socket -> bind -> listen, and then to accept one (get a fd for each incoming connection) use accept
<sivang> Robot101: ah! Now I get it :)
<zyga> hello
<pitti> Hi zy
<pitti> Hi zyga
<fabbione> seb128: ping?
<fabbione> seb128: http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.11-0ubuntu4/ <-
<fabbione> seb128: you might be interested to look at it
<mvo> I need a replacement for "The languages are installed now" in language-selector. it should cover both install and removal. does "The languages on the system are changed now" sound ok? suggestions welcome :)
<Znarl>  /changed/updated/ ?
<Kamion> "The languages" at the start of that sentence reads awkwardly
<Kamion> "The set of available languages on the system has been updated." (too mathsy?)
<ogra> looks good from a german POV 
<Treenaks> The list of available languages has been updated." ?
<Diziet> `Your changes to the available languages have been completed.'
<Kamion> Treenaks: works for me
<Kamion> Diziet's version works but seems somehow a bit indirect?
* dholbach <- lunch
<Kamion> makes me think of d(available languages)/dx :-)
<Kamion> (maybe I'm strange)
<mvo> thanks a lot everyone. I personally like ""The list of available languages on the system has been updated." the most. if that's ok I'll go with it 
<infinity> Kamion : Do we want all these fcdsl drivers and such in here, or just madwifi/ath?
<infinity> Kamion : And do you need a copy of lrm-manager in the udeb, or will you do that magic yourself some other way?
<Kamion> infinity: just madwifi/ath
<Kamion> infinity: personally I'd rather desupport those modules for installation than have to have a binutils-static-udeb
<infinity> Well, unsupporting them is even easier, I just comment out all the udeb generation..
<infinity> Not sure how well that'll fly, though, since ath is on a lot of laptops.
<Kamion> easier than that, I just drop the priority on jackass
<Kamion> I'll talk to mdz
<infinity> Though, mostly laptops that should also have wired ethernet.
<Kamion> but for now if you could just do the size fixup, that would be fine for the moment
<infinity> Right, easy enough.  Ish.
<Kamion> what happened to ath, ath_rate, and net80211?
<Kamion> I only see ath_hal in the current udeb
<infinity> Your guess is as good as mine, I don't see them in the fulle-sized .deb either.
<infinity> Either madwifi doeswn't build them anymore, or something's broken.  I don't have an ath to test with, but I've also seen no complaints so far.
<Kamion> at least binutils-static is only about a megabyte, in case we end up going down that road
<infinity> If it's static, why does it depend on binutils? :)
<Kamion> that's so wrong
<Kamion> oh, for the documentation directory
<Kamion> lrwxr-xr-x root/root         0 2005-09-01 02:55:52 ./usr/share/doc/binutils-static -> binutils
<infinity> Oh, that's just retarded.
* infinity doesn't like pulling in binutils on every desktop just to get -static.
<infinity> I think I'll have a chat with jbailey about that. :)
<Mithrandir> doko_: around?
<doko_> Mithrandir: yes
<Mithrandir> doko_: 7916 just disappears with a recompile, any ideas about it from a toolchain perspective?
<Mithrandir> doko_: it looks to me like we've had some silent breakage in the toolchain which gives us icky bugs like that one.
<Mithrandir> doko_: I can of course just close my eyes and upload a new version and go "la, la, la", but it's not a very nice thing to do. :-)
<doko__> Mithrandir: for gstreamer itself, unlikely. the last upload was after the last toolchain update
<Mithrandir> doko__: the problem goes away when recompiling swh-plugins, not gstreamer.
<zyga> hey I think I might have found a bug
<zyga> I modprobe for cloop with the proper file
<zyga> and then mount /dev/cloop0 
<doko__> Mithrandir: swh-plugins was uploaded Sep 13 ...
<zyga> as a result I've got endless stream of hpdaram.dev and hotplug stuff going on and everything hangs hard
<infinity> Kamion : Kay, I need to examine reports of (possibly) missing files (or just drivers that have changed, who knows?) before I mangle this thing any more than it's already been.
<zyga> sorry, udev instead od hal
<infinity> Kamion : If you discuss dropping installer support for ath at the same time, we'll meet in the middle.
<Mithrandir> doko__: doesn't look like that to me, given that it's the same version in breezy and hoary?
<seb128> fabbione: pong
<doko__> Mithrandir: ooh, right, the 0.4.13-1 upload did FTBFS on all archs ...
<fabbione> seb128: yo.. gst-plugins is FTBFS
<seb128> fabbione: that just say "waiting for a ftpmaster to move the accepted packages to the right place"
<Mithrandir> doko__: well, that version was uploaded March 6th in Debian and possibly synced in later?
<Kamion> seb128: hmm? what ftpmaster action needed?
<fabbione> seb128: ok :)
<seb128> Kamion: libcdio-dev and libmms-dev to main 
<seb128> Kamion: gst-plugins0.8 Build-Depends on them now which make it FTBFSing
<Mithrandir> doko__: hm, ok, so it might just be fixed upstream between those versions.  I'll fix the ftbfs rather, then
<Kamion> seb128: done
<seb128> Kamion: thanks
<\sh> seb128: u remember my crash with evolution and this strange mail? (http://bugzilla.gnome.org/show_bug.cgi?id=316777) 
<seb128> \sh: yeah, thanks for sending the bug and the bt upstream :)
<seb128> \sh: have you tried the patch?
<\sh> seb128: they provided a patch...u think it's going to make it into 2.12.1?
<\sh> seb128: not now...I'll do it this evening..
<seb128> \sh: 2.12.1 is due next monday, one week ... should be fine if somebody confirm that the patch works
<\sh> seb128: evolution-data-server or evolution directly?  libical was data-server, right?
<seb128> \sh: evolution-data-server/calendar/libical
<\sh> k...I'm doing it now...lets see :)
<seb128> cool, thanks
<sivang> seb128: got my email?
<seb128> sivang: yep, thanks
* mvo would like "NeedInfo" in malone 
<sivang> seb128: thank you :)
<seb128> thanks to you for the patch
<Mithrandir> seb128: is gst able to change a user's password for you on amd64?
<Mithrandir> seb128: it just crashes for me
<seb128> Mithrandir: https://bugzilla.ubuntu.com/show_bug.cgi?id=15428
<seb128> Mithrandir: I've started debugging it from a liveCD since I've no amd64 install atm and gave it to dholbach ... he did some work on it but with no luck for the moment
<seb128> Mithrandir: I'm sure he would appreciate you giving him a hand with it if you want to track it :)
<Mithrandir> seb128: I could give it a shot, sure.
<mdke> sabdfl, pong, if you're still here
<sabdfl> mdke: hi. just curious as to the status of the "About Ubuntu" icon in the System menu? And the doc?
<mdke> sabdfl, it's being translated
<mdke> sabdfl, it hasn't been uploaded yet to my knowledge, jbailey is dealing with that aspect of the documentation
<mdke> but it looks good
<sabdfl> cool!
<sabdfl> could we get at least the current stuff uploaded for testing and feedback?
<sabdfl> i'd like to avoid a last-minute rush to get it in, and the attendant "oops!" issues
<mdke> better speak to jeff, I think he had intended to do it by now
<mdke> but we've been over the doc and fixed any typos, I hope
<mdke> the translators pointed some things out, which we fixed
<sabdfl> jbailey: ^^ how's it looking? issues? status?
<mdke> i gtg
<sabdfl> thanks mdke
<mdke> np, catch you again
<doko> infinity, lamont-away: eclipse is only built on i386
<Diziet> It's clear to me, now, why everyone in the bugzilla always sounds annoyed - even more than you might expect from them having found a bug.  It's because everyone who's typing into that bugzilla box is ... fighting bugzilla.
<tseng> thats quoteworthy
<Robot101> already saved :P
<jkrogh> Does anyone have a guess at the problem in #12942 - mysterious NFS timeouts.. ? 
<sivang> lol
<sivang> that's why I think we need to switch to malone as soon as it becomes productionable
<tseng> sivang: malone is worse
<tseng> more people need to be pointing out usability problems
<tseng> there is some kind of malone users bof in that vein
<ogra> jkrogh, yes, every edubuntu user
<seb128> Mithrandir: #7916 is fixed by a new version of what package?
<ogra> jkrogh, you write in the bug that it works after 5 minutes ? 
<Mithrandir> seb128: swh-plugins
<Mithrandir> seb128: which is in universe, so I can't reassign it.
<seb128> Mithrandir: so that's not a gst bug? I can close it on bugzilla.gnome?
<Kamion> jkrogh: does mount -onolock help?
<Mithrandir> seb128: yes.
<seb128> k, thanks
<dholbach> YAY for Mithrandir! :)
<Mithrandir> dholbach: what have I done now? :-)
* dholbach hugs Mithrandir :)
<dholbach> swh-plugins :)
<seb128> oh
<Mithrandir> ah, that one.
<seb128> I thought this was about the users-admin crasher
<Mithrandir> it was just fixing the ftbfs. :-P
<Mithrandir> seb128: no, that one isn't fixed by gstreamer stuff. :-)
<seb128> Mithrandir: yeah, but it would make dholbach happy too :p
<ogra> Kamion, can one put that in the bootoptions ? 
<ogra> (its the mounting of / that fails there)
<seb128> sivang: your autotools patch is bugged
<ogra> oh, and apparently jkrogh already tried that...
<Kamion> ogra: no
<ogra> (according to the bug)
<sivang> seb128: bah, does it break on building ?
<seb128> gnome-panel/panel-context-menu.c:289: undefined reference to `launchpad_integration_add_items
<seb128> sivang: I'm fixing it don't worry
<sivang> seb128: ah man, I probably removedd too much PKG_CHECK_MODULES from the patch, I tried to make it cleaner, funny it worked for me
<sivang> seb128: I guess both launchpad-integration and lpint-bonobo are required there
* dholbach <- dogwalk
<bddebian> Morning
<bddebian> doko: ping?
<pitti> Hi bddebian 
<bddebian> Heya pitti
<doko> bddebian: ?
<bddebian> doko: Do you see a problem with brining in a newer zipios++ from Debian?
<doko> bddebian: why? what did the Debian NMU change
<doko> ?
<bddebian> doko: I dunno but there is a bug on Malone about wesnoth that it supposedly fixes
<doko> bddebian: ok, after reading the changelog and #314602, it indeed fixes the problem with wesnoth. requesting the sync now. btw, nothing, what you couldn't have found out yourself ;-)
<jkrogh> ogra: My mistake.. it works at most for 5 minutes then are broken for some time .. and eventually it resumes connection again. 
<bddebian> doko: I know but I saw that you made the ubuntu changes for the current version so I didn't want to just do it.  Sorry.
<jkrogh> Will try "nolock". 
<ogra> jkrogh, thats about booting ? 
<ogra> or about login ? 
<ogra> login == 15244, booting == 12942
<ogra> 15244 is something weird going on with sshd i suspect
<Mithrandir> seb128: the segfault goes away if I disable optimisation. :-/
<jkrogh> it is 12942 but it is about the root-NFS in general not only booting. 
<seb128> Mithrandir: how nice
<ogra> i have no problems at all (except the fisrt boot timeout) neither have other testers in #edubuntu 
<jkrogh> I can get the error about NFS not responding on the shell (crtl+alt+F2)
<Mithrandir> seb128: yeah, and it seems like there's stack corruption shit in the md5 code.
<seb128> dholbach: read that?
<ogra> jkrogh, do you use edubuntu or the ltsp from breezy with a self set up NFS server ? 
<jkrogh> ltsp in breezy
<ogra> hmm, k... i didnt hear about anything like that in #edubuntu yet, even test schools are running it happily... probably your setup is at fault..
<ogra> i wont be able to do much edubuntu testing this week, but i'll check it...
<jkrogh> Yes there is definately something wrong. 
<jkrogh> The setup did run Debian/Sarge + LTSP 4.0 lasts week just fine.. so I dont think it is hardware problems. 
<ogra> debian/sarge's ltsp has zero in common with the breezy ltsp, its a totally new implementation
<ogra> debian/sarge == exported X TCP session, breezy ltsp == ssh tunnel, they both use tftp and nfs though
<jkrogh> Yes. but the core principels are the same. 
<jkrogh> Boot over PXE.. root-on-NFS
<ogra> oh, and debian doesnt use itiramfs at bootime at all i think
<ogra> *initramfs
<jkrogh> No.. those scripts are really nice in Ubuntu .. easy and modifiable :-) 
<ogra> 2.6.10 still is initrd afaik
* jkrogh likes that 
<sabdf1> jbailey: ping
<ogra> jkrogh, but you could join #edubuntu and track the issue with other ltsp users ;)
<bddebian> elmo: ping?
<Mithrandir> seb128: ok, I've found the bug.  Casts are evil.
<Mithrandir>     ((uint32 *) ctx->in)[14]  = ctx->bits[0] ;
<Mithrandir>     ((uint32 *) ctx->in)[15]  = ctx->bits[1] ;
<Mithrandir> Don't do this.
<Mithrandir> at least not without making sure ctx->in is big enough
<seb128> Mithrandir: what are ctx->in and ctx->bits?
<Mithrandir> ctx->in is a char[64] 
<seb128> bad
<Mithrandir> and with sizeof(uint32*) == 8, that goes boom.
<seb128> yeah
<seb128> thanks for tracking it
<Mithrandir> the easy and ugly fix is just to make ctx->in a char[128] 
<Mithrandir> it stops segfaulting, at least.
<Mithrandir> openssl uses a "OPENSSL_LONG" which is minimum 32 bits and can be bigger and does some shit around that.
<Mithrandir> since I don't think we'll be generating the right data just by changing that
<seb128> I'm wondering who is upstream for this code
<seb128> carlos said he copied the md5.c file from somewhere else
<Mithrandir> oh, excellent; "somewhere else" :-P
<Mithrandir> for security-related code, I really don't like that.
<seb128> imho using g-s-t is far from beeing optimal
<seb128> there is a lot of work and upstream is busy
* mvo nods
<seb128> making it working on every distro around is a lot of work too
<seb128> and perl is .. <no comment>
<Mithrandir> it's linuxconf is all over again, really.
<seb128> we should rewrite the tools using pygtk one day
* sivang seconds seb128 
<sivang> seb128: and rewrite the backend in python :)
<Treenaks> perl can be nice.. but the code you're referring to obviously isn't :)
<seb128> Mithrandir: https://bugzilla.ubuntu.com/show_bug.cgi?id=10742 ... users-admin didn't crash but the password was not working neither for hoary
<Mithrandir> seb128: I guess that's because half of the thing it's stuffing into the password field is garbage.
<Mithrandir> seb128: I guess I should just fix md5.c to at least work.
<bddebian> Heya sivang
<seb128> Mithrandir: that would be nice if you want to do it :)
<sivang> hey bddebian  :)
<sivang> bddebian: 'sup?
<bddebian> sivang: UnmetDeps and bugs as usual :-)  You?
<zyga> hmmmm
<jbailey> sabdf1: pong
* jbailey reads.
<jbailey> sabdf1: I was beating on the docs at the end of last week, and realised that my branch didn't keep in mind KDE docs.
<sabdf1> jbailey: ok
<sabdf1> can we get the current snapshot in, even if its broken, so we get bugs filed and can track them to release?
<bddebian> sabdf1: Oh, you are still here.  Mind if I ask a quick question about Universe and apt-get.org packages?
<jbailey> sabdfl: Will do by end of today.
<sabdfl> jbailey: cool, thanks muchly
<sabdfl> bddebian: sure
<Riddell> jbailey: what's all this?
<zyga> could someone help me with strange udev behaviour
<jbailey> Riddell: kubuntu-docs
<zyga> I don't know if this is a bug really
<zyga> I mount a cloop image
<bddebian> sabdfl: I know of at least two packages currently in the archive from Marillat that are depending on other Marillat packages that are not in the archive.  Should I bring in the deps or morgue the packages for now, or do nothing?
<zyga> and unmount it immediatly
<zyga> I also rmmod cloop
<zyga> that spawns couple dozen of udev and hdparm.dev processes
<zyga> that hang indefinitly unless killed -9
<zyga> they also take all available CPU
<sivang> bddebian: stil with that cupsys thingy, it's a bit elusive where the sockets are opened and closed 
<zyga> I can reproduce this easily
<bddebian> sivang: :-(
<zyga> the strange thing is they seem to scan my /dev/hdc which corresponds to the CD drive
<sivang> bddebian: plus, SIGHUPing cupsd appears to just shut it down instead of actually reloading the configuration
<sivang> bddebian: nah, things are cool :) it's all much fun!
<bddebian> Is that what you call it? ;-)
<sabdfl> bddebian: if the deps *can't* be in Ubuntu universe/multiverse, then the packages themselves should also not be here
<sabdfl> if they can, we should sync them in
<sabdfl> so the archive is consistent, either way
<sabdfl> sond good?
<bddebian> Sure but what does *can't* be mean? :-)
<Diziet> Is there anyone here who uses a non-Latin character set ?  It would be nice to have some idea of what the right response is to http://bugzilla.ubuntu.com/show_bug.cgi?id=15942.
<bddebian> elmo: I know you are there!! :-)
<zyga> Dilago: I do
<sivang> lol
<dholbach> sivang: don't you use hebrew locale?
* dholbach wasn't quite sure
<sivang> Diziet: you have bugspam :)
<sabdfl> bddebian: w32codecs, for example, *can't*
<sivang> dholbach: already added comment to that bug :)
<zyga> hmmm
<seb128> pitti: do you have a reference bug to explain why we don't use alsasink? I've an another "A/V sync sucks by default"
<dholbach> ah ok :)
<sabdfl> i think
<Diziet> sivan: Thanks.  Um, do you mind if I quiz you about this ?
<zyga> can anyone assist me with utterly strange udev behaviour?
<sivang> Diziet: feel free, I'm at your service
<sabdfl> bddebian: the process is to ask elmo, who will ask me if he's not sure
<sivang> Diziet: btw, I can that with hoary as well
<elmo> Kamion/benc/fabbione: around?
<bddebian> sabdfl: OK, thx.  I'm trying to catch elmo but I bug the crap out of the poor guy :-)
<zyga> Diziet: I can confirm that bug too
<Kamion> elmo: yo?
<zyga> anyone about udev weirdness?
<elmo> Kamion: oh, nm, it's generic FTBFS, not d-i related as I thought
<pitti> seb128: sounds like a dup of #15438
<seb128> pitti: thanks
<pitti> seb128: there I explain the issue, and it's about a/v desync
<elmo> Kamion: (sorry)
<pitti> Hi elmo 
<bddebian> elmo: I know you're busy as hell but if you get a chance would you mind looking at the licenses for babytrans-common and ffmpeg2 on Marillat? (apt-get.org)
<Kamion> ok
<zyga> hmm I feel helpless
<pitti> elmo: can you please remove mozilla from hoary-backports? it's obsoleted by h-security and vulnerable
<mjg59> bddebian: ffmpeg2 is a patent problem rather than a freedom one
<bddebian> mjg59: I'm sorry, I'm not sure what you mean?  Ohh, you mean because of mpeg?
<elmo> pitti: will people have an upgrade path, assuming they have both in their sources.list?
<mjg59> elmo: Would it be possible to sync hotkey-setup?
<pitti> elmo: yes, hoary-security has the same package name, but a more recent version
<Kamion> Mithrandir: did you ever get anywhere with the x86emu fixes for amd64?
<seb128> elmo: please sync gnomemeeting (GNOME desktop component) pwlib h323lib (required by the new gnomemeeting) from Debian
<pitti> elmo: upgrading to breezy is flawless too (unlike the mozilla-firefox -> firefox name change)
<Mithrandir> Kamion: no, my dvd burner is broken at the moment (or, one of them is, the one at work where I have a POSTable graphics card)
<Mithrandir> Kamion: so I can't really test it more until I get that back.
<\sh> seb128: sorry for the delay, but our digital tv headend is producing problems...but the patch works
<bddebian> Heya \sh
<pitti> elmo: speaking of which, did you read about the trouble with firefox? is it possible to upload a transition package manually to h-backports at all? or do all uploads need to be synced from breezy?
<bddebian> elmo: If ffmpeg2 can't be brought in can you please drop gpac from the archive?
<elmo> pitti: mozilla removed
<seb128> \sh: cool, could you comment to say so on the upstream bug?
<elmo> mjg59: done
<bddebian> mjg59: Do you happen to know about babytrans-common license?
<pitti> elmo: thanks
<\sh> seb128: already done :)
<elmo> seb128: I assume you mean openh323 ?
<mdz> morning
<bddebian> Heya mdz
<elmo> seb128: if so - ok to override ubuntu changes?  same question for gnomemeeting
<\sh> seb128: so u think they will include it in 2.12.1?
<ogra> elmo, while youre at it, mediawiki hit debian today... please sync :)
<mjg59> bddebian: No
<mjg59> bddebian: Let me check
<bddebian> mjg59: Thx
<mdz> \sh: Riddell can set up default assignees for you
<elmo> [NOT Updating - Modified]  mediawiki_1.4.7-2ubuntu2 (vs 1.4.10-1)
<elmo> ogra: ok to override?
<seb128> elmo: pelase sync pwlib and openh323 with overwritting, I'll merge gnomemeeting ... thanks for asking :)
<elmo> pitti: rules of backports are that it's unmodified breezy source only
<mjg59> bddebian: Uh. Babytrans appears to be under the GPL.
<seb128> s/pelase/please/
<ogra> elmo, sure :)
<\sh> mdz: ok thx :)
<elmo> pitti: you'll need mdz or higher to override that
<seb128> \sh: yeah
<pitti> elmo: so it's technically possible? ok, then we can at least discuss that option. thanks!
<mdz> pitti: what's the situation?
<pitti> Hi mdz 
<elmo> seb128: done
<\sh> seb128: cool :)
<pitti> mdz: you know the mozilla-firefox -> firefox renaming in breezy
<tseng> mdz: do you need to approve larger patches for main (mono bug fix backport)?
<tseng> mdz: 12k
<Riddell> \sh: needing an assignee setup?
<seb128> elmo: thanks
<pitti> mdz: problem is, in hoary-backports the package is called firefox as well, although it should be mozilla-firefox
<bddebian> mjg59: Oh *face turns red*
<mjg59> bddebian: Oh, hang on
<mjg59> bddebian: babytans-common is the dictionary file
<ogra> mgji think the wordlists arent
<pitti> mdz: that means that installing hoary (m-f), then h-backports (firefox), then hoary-security (m-f again) breaks since the packages overwrite each other's files without a conflict
<ogra> mjg59, indeed
<pitti> mdz: I did not think about adding a conflict to firefox in the security update, and it would not even completely resolve the situation
* ogra damns tab completion
<mdz> pitti: why not?
<mjg59> bddebian: There appears to be no permission whatsoever to distribute that
<bddebian> Nice
<bddebian> WTF
<pitti> mdz: once you have ffox installed, merely declaring a conflict in m-f to f won't automatically upgrade f to m-f
<pitti> mdz: so we would need an empty firefox transition package in h-backports that depends on m-f
<pitti> mdz: alternatively, folks have to manually purge firefox and reinstall m-f
<pitti> mdz: but since in breezy we have the exactly reverse situation, we can't do this migration in the breezy package
<mdz> pitti: I don't think we want to transition back to m-f
<bddebian> mjg59: So we should drop babytrans too?
<sivang> elmo: if you are too busy , I might wait for the DB2 certification CD to arrive and not bother you anymore with the files, I'm afraid to lack soem of the needed files, as he forgot to upload on one smack...
<mdz> why not keep firefox in backports and sync the latest version from breezy?
<pitti> mdz: the current breezy package does not work on hoary any more (major changes like cairo and stuff)
<ogra> pitti, wasnt it a request from the mozilla foundation to change the name anyway ?
<ogra> iirc
<mjg59> bddebian: babytrans should be fine, you just can't distribute the dictionary
<pitti> ogra: right, but it breaks hoary
<bddebian> mjg59: But babytrans-common is a dep (or build-dep) I don't recall atm
<ogra> pitti, dont tell me, it cluttered my weekends mailbox badly ;)
<mdz> pitti: it should be possible to get it building on hoary again
<mdz> pitti: this is for the backports team to handle though
<pitti> mdz: hmm, release-dependent build deps?
<Mithrandir> seb128: it helps that the md5 implementation is broken and doesn't give out the right answer.  I wonder why this wasn't discovered...
<mjg59> bddebian: It's a dependency. I've no idea why.
<mjg59> That file is plainly not required
<bddebian> mjg59: OK, I'll just drop the dep then.  Thanks for your time!
<pitti> mdz: if they manage to do that, that would be a good solution, of course
<mdz> pitti: usually this can be fixed simply with |-ed build-deps
<pitti> mdz: ok, I tell the bp team to try that
<seb128> Mithrandir: how "wasn't discovered"? There is a bug for some time, the issue is that it's amd64 specific and some people don't run an amd64 install ... :)
<sivang> pitti: what's the bp team?
<sivang> pitti: ah, backports
<pitti> sivang: backporters
* mdz peers at dholbach's changelog entry
<Diziet> sivang: Thanks for your help.  I hope you don't mind that I'm going to punt, given that it's outstanding upstream and looks nontrivial.
<dholbach> mdz: if you talk about gnome-sudoku... elmo already "told" me :)
<sivang> Diziet: on the contrary, please do :)
<mdz> dholbach: yes
<ogra> wow, a novel :) 
<Mithrandir> seb128: gnnnr
<Mithrandir> seb128: *grumble*
<ogra> thanks elmo
<mdz> eek, firefox is crashing on bugzilla for me
<mdz> the certificate dialog (or what I assume is the certificate dialog) flashes up and then the whole thing goes down in flames
<seb128> Mithrandir: carlos says than the md5 stuff comes from pam
<mdz> fun, both an oops and a SCSI bus reset in syslog
<mdz> time to reboot
<jkrogh> ogra: FYI, booting to the LTSP 2.6.9 kernel solves the NFS issues in my setup. 
<jkrogh> There must be something strange with the NFS-client.. 
<ogra> jkrogh, 2.6.9 on the client with a newly generated initramfs ??
<jkrogh> on the client. 
<jbailey> initramfs should fail to generate for anything less than 2.6.12
<jkrogh> with the initramfs from LTSP.org
<jbailey> And beyond that shouldn't boot if you convinced it to build.
<jbailey> Ah.
<ogra> jkrogh, what bothers me is that you seem to be the only person having probs with NFS here
<jkrogh> ogra: That really borthers me too. 
<ogra> jkrogh, (beyond the boot timeout indeed)
<ogra> jkrogh, thats a new plain breezy install ? no foreign packages etc at all ? 
<sivang> jkrogh: do you have nfs-common installed?
<jkrogh> ogra: The boot timeout was rare.. 
<ogra> sivang, yes, else NFS wouldnt work at all for him
<jkrogh> Most of the time it got the NFS mount successfully but then timed out later in the system. 
<ogra> jkrogh, it only occurs on the first boot of the first client...
<jkrogh> approximately 15 seconds later.. 
<ogra> jkrogh, again my question, thats a new plain breezy install ? 
<sivang> ogra: I ad a problem with NFS delay on boot, installing 2 more packages solved it, probably not nfs-common
<jkrogh> Yes. plain breezy install
<jkrogh> Fresh from d. 23
<ogra> and nothing foreign in there, no debian packages etc ? 
<jkrogh> Not at all. 
<ogra> hmm, strange
<j^> could it be portmap? not having poartmap can cause long timeouts
<ogra> it would choke on every boot without portmap
<sivang> ogra: it blocked for half an hour on boot until I installed those pakcages, don't recall which they were
<ogra> you'd see it on the clients...
<sivang> ogra: riught, portnao
<sivang> grr, portmap even
<ogra> sivang, its not possible to install nfs-kernel-server without portmap
<ogra> its a dependency
<sivang> ogra: yes, but I didn't install kernel-server at first, I only wanted to mount remote file systems :)
<ogra> jkrogh, did you use ltsp-server-standalone or only the ltsp-server package
<sivang> ogra: so portmap wasn't pulled in
<jkrogh> -standalone
<ogra> sivang, we talk about ltsp-server/-standalone ... its a dependency
<ogra> there are no missing packages
<ogra> jkrogh, and followed the ThinClientHowto from the wiki ?
<sivang> ogra: ah ok, sorry for the noise
<ogra> sivang, additionally it works for all others who tried ltsp until now...
<jkrogh> ogra: There migt be something here.. nfs statd actually fails. 
<ogra> oh
<jkrogh> Nope.. It just fails to start, when it is started allready. 
<jkrogh> Yes. I followed the ThinClientHowto. 
<ogra> hmm
<ogra> jkrogh, all i can tall you now is that i'll do a edubuntu install later today, but it still may take some hours before i find the time for it... probably its a new but that was introduced last week...
<jdong> hey guys, Breezy firefox needs build depends on libcairo1-dev
<Diziet> Joy.  A bug report about a website that makes firefox crash metacity.  And the site is pretty vile.
<jdong> >=1.1.17, too :)
<jbailey> Diziet: microsoft.com?
<jkrogh> Well, lets stop debugging for now.. I'll be using the LTSP.org kernel/ramdisk/userland  and try out Ubuntu's when 6.04 is about to release again. 
<ogra> Diziet, makes firefox crash metacity ??
<jdong> jbailey: LOL
<hughsie> ogra: is pitti around?
<jkrogh> ogra: Or just poke to me if you want something tested out. 
<ogra> jkrogh, oki
<ogra> jkrogh, lets see what i find tonight :)
<Diziet> 15995.  I've reproduced it.  But the site is not by any means what one would normally consider work-safe - even if it didn't crash your session.
<jbailey> I kills the session manager?
<Diziet> No, just metacity.
<Diziet> You can log out, but you can't regain control.
<j^> i would blame it on the TITLE element 
<j^> its too long
<j^> metacity should not crash if an app tries to set a too long title
<Robot101> it could be duff unicode
<seb128> Diziet: nice bug :)
<j^> Diziet title is 34921 chars long
<jkrogh> Otherwise.. I'd really like to thank you guys for Ubuntu, It is by far the most "friendly" distribution at the moment. 
<ogra> i wonder if a 34921 char long title works in windows
<j^> hehe
<sivang> jkrogh: just spread the word , make many people use it :)
<Diziet> Yep, it's the overly long <title>, all right.
<jdong> would that be a buffer overflow type of thing? ;)
<seb128> Diziet: I can forward it to bugzilla.gnome if you want
<Diziet> seb: Do you want me to try to debug it first ?  We should perhaps check it's not already reported.
<Diziet> I consider this a security bug, although a minor one.  It might also be a major one.
<ogra> hughsie, sorry missed ou... pitti is already gone ... dunno if he'll come back
<seb128> Diziet: do you have a backtrace? That would make easy to figure if it's known upstream
<j^> http://bugzilla.gnome.org/show_bug.cgi?id=315070
<seb128> thanks
<j^> so its cairo-based pango/gtk+ 
<Diziet> That looks like our bug.
<Diziet> I'm not convinced that patch is right.
<Diziet> I don't know what the X limit is that's referred to, but won't it be in bytes and not characters ?
<Mithrandir> seb128: hmm, the bug is something else, but I'm not sure and my head is threatening to fall off, so I'll make dinner and look at it later.
<seb128> Mithrandir: k, thanks for the work on that, enjoy your dinner
<ogra> Mithrandir, and have some pillow around in case your head falls off :)
<jkrogh> Oh.. where do I file stuff about the "planet" (http://planet.ubuntulinux.org) ? 
<jkrogh> http://krogh.cc/~jesper/ubuntu.png
<jkrogh> looks like .... in MSIE. 
<ogra> jkrogh, jdub maintains it... probably there is a product under "website" in bugzills
<ogra> s/s/a
<Diziet> I assume that if someone has errors from the packaging system because of braindamage in ubuntu-backports.mirrormax.net, I can just RESOLVE INVALID ?
<jdong> Diziet: yeah, go ahead -- and I personally apologize for all the trouble it's caused
<ogra> Diziet, please point him to the backports forum for the inofficial backports, we shouldnt just drop it..
<jdong> yes, please try to point them to the forums or ubuntu-backports@lists.ubuntu.com -- we're currently working on fixing the problem
<Diziet> jdong/ogra: Willdo.
<Kamion> Could a French speaker review #16303 for me, please? Note that the actual msgid is "Erase entire disk and use LVM: ${DEVICE}"
<jdong> Diziet: I'm working on a 1.0.7 backport with various team members, so this should be all resolved by mid week
<Diziet> jdong: Right.  FYI, the bug is 16228.
<seb128> Kamion: what po files are to update ?
<seb128> Kamion: one of the string has a small error and I want to update the other installed stuff too
<desrt> what email address does mjg59 use on bugzilla?
<mdke> mjg59 will catch him
<mdke> bugzilla autocompletes
<bob2> yay for 250KB of javascript!
<desrt> hey
<desrt> that's sweet!
* j^ wonders why this was not done using ajax
<ogra> j^, because its in production and development power goes to malone...
<bob2> I'm pretty sure no one from canonical added that feature to bugzilla
<bob2> it certainly had it back in like may last year
<ogra> yup
<j^> ogra malone would also need some ajax love
<bob2> ajax is the most annoying buzzword of the year
<ogra> j^, tell that to #launchpad ;)
<bob2> this conversation has made it overtake "podcast"
<j^> but ubuntus bugzilla is the first with such a large list of products
<Kamion> seb128: the installer po files are all in http://people.ubuntu.com/~cjwatson/installer-po/, http://people.ubuntu.com/~cjwatson/base-config-po/, http://people.ubuntu.com/~cjwatson/shadow-po/
<seb128> Kamion: thanks, I'll send you updated PO for all of those later
<Kamion> seb128: cheers
<Kamion> seb128: I've pulled a few updates from Rosetta, but probably not everything
<seb128> k
<Kamion> if there are particular things already done in Rosetta that I should grab, let me know ...
<seb128> I'll have a look on what rosetta has yep
<Kamion> unfortunately the way the po-export stuff is now "POST to URL, wait for mail, go to URL in mail" makes it a lot less automatable than it used to me
<Kamion> used to be
<Kamion> I used to have a script which could extract translations from Rosetta to stdout
<Kamion> but I suspect it's only me who cares because everyone else can use language packs
<Kamion> seb128: oh, those base-config and shadow directories are very out of date, sorry - I'll update them now
<seb128> let me know when the new version is online, so I grab the correct one :)
<Kamion> seb128: done
<seb128> thanks
<Diziet> Is there anything I need to watch out for if I decide to change the default fonts in Firefox ?
<ogra> webpages mostly define sans-serif or serif in their CSS i dont know if you should change it in firefox...
<ogra> rather the assignment serif -> Nimbus Sans should be changed to serif -> Bitstream Vera Sans
<Diziet> There are two things I want to change, I think: firstly, the default if the site doesn't specify is to use serif, and I want to change that to sans.
<ogra> err s/serif/sans-serif/
<ogra> Diziet++
<Diziet> Secondly, if the site just asks for sans-serif they get a pretty unpleasant font.
<ogra> for sans too...
<ogra> Nimbus looks weird here....
<Diziet> Right.  Nimbus seems to be the default.  I don't know yet where that's controlled.  If no-one knows easily then I will find out for myself :-).
<Diziet> No, I'm wrong, the default is Bitstream Vera Sans.
<ogra> normally in local.conf of fontconfig, but last time i looked there was Bitstream selected already, there must be something inbetween...
<Diziet> FreeSans is much nicer.
<ogra> nope, not here... it looks like Nimbus...
<ogra> blurry character borders
<Diziet> Maybe I should post to ubuntu-devel and let the bikeshedders argue it out :-).
<Diziet> Yes, I think I will do that.
<j^> who would i talk to about changes on packages.ubuntu.com?
<ogra> anyway it hould be Bitstream 
<Diziet> It looks here like it is.
<ogra> j^, see packages.ubuntu.com, there is a address
<ogra> ;)
<Diziet> Bitstream Vera Sans, which is rather spindly.
<ogra> Diziet, nope... something sets it to Nimbus
<ogra> switch explicitly to Bitstream, you'll see te difference
<Diziet> Hmm.  This machine was upgraded from hoary.
<Diziet> Yes, I did and it's just the same.
<ogra> hmm, not on my new installs...
<ogra> and here on my upgraded system neither...
<Diziet> Perhaps it depends whether you tell it you have an LCD 
<ogra> nope, i have both here...
<ogra> it looks crappy with the default on both unless i explicitly select a bitstream font...
<ogra> ... probably a bitstream conspiracy on my side here :)
<Diziet> Is the default font chosen via Firefox or via some other package ?
<Diziet> I mean, the default sans and the default serif.
<ogra> Diziet, it uest to be set by local.conf from fontconfig, but that may have changed with cairo... i guess seb128 can give some insight
<ogra> s/uest/used
<ogra> abarbaccia, sorry, seems jdong is gone already...
<abarbaccia> ogra no worries - i'll get him later
<seb128> that has no changed afaik
<ogra> seb128, hmm, why is the default font in firefox for sans not bitstream vera sans then ? 
<ogra> at least here its either Free Sans or Nimbus ... it only gets readable if i explicitly select Vera Sans
<seb128> ogra: no clue, I don't use firefox
<dholbach> seb128: epiphany love? :)
<ogra> bah, use a *real* browser :)
* dholbach shoves ogra ... somewhere else
<dholbach> :)
<ogra> dholbach, epiphany was the first thing i droppen in edubuntu when i needed space ;)
<ogra> dropped even
<dholbach> ignorant %$"$!&
<dholbach> :)
<seb128> dholbach: https://wiki.ubuntu.com/EpiphanyDefaultBrowser
<dholbach> yeah, i read that :)
<seb128> I would pick it only for the translations
<ogra> dholbach, to be fair, the second thing dropped was thunderbird :)
<Diziet> What can I do to get a bug reporter a telling-off ?  I referred them to `How to Report Bugs Effectively' and they seem to have replied with a rant without having read it.
<Diziet> (And, to be fair, marginally more info.)
<ogra> hmm, just set it to needinfo and tell him you cant do anything without more info...?
<Diziet> I want to be a bit more constructive.  I'll try telling him off myself.
<ogra> but if he already rants, pure bureocracy is probably the best...
<Diziet> Well, if it's a real bug I'd actually like to nail it down.
<ogra> thats hard without the reporter giving all info
<mjg59> Diziet: Which bug?
<dholbach> do we still need the euro-support package for any reason?
<ogra> not really
<Diziet> 16132
<Diziet> (I have to go very soon.)
<ogra> Diziet, ask him if he has libxp installed ...
<Diziet> I'll try that - tomorrow, I have to go now :-).
<Diziet> Thanks.
<ogra> :)
<Diziet> TTFN all
<\sh> ogra: do u have an ipod?
<ogra> heh, nope
<ogra> i have a HIFI without any pod ;)
<\sh> how should I solve this bug then ;)
<ogra> buy an ipod ? 
<ogra> forward it to someone who has one ?
<\sh> ogra: the former: whuahaha ;) the latter: let's see
<thesaltydog> \sh, I have one, but I am not sure to risk the 15 MB of music I have on!! Maybe I should make a DVD backup...
* mvo is away to play hockey
<\sh> thesaltydog: if you have the time...amarok-1.3.1 from breezy and try to confirm http://bugzilla.ubuntu.com/show_bug.cgi?id=16375
<thesaltydog> \sh ok.. I'll have  a look at it.
<\sh> thesaltydog: thx :)
<thesaltydog> \sh np
<thesaltydog> \sh it claims to install a lot of kde shit
<\sh> thesaltydog: yes...it's a kde app...
<\sh> thesaltydog: sry for that ;) 
<thesaltydog> \sh, :-)
<dholbach> jdub: ping
<dholbach> jdub: ready to unveil ubuntu-desktop@ ?
<ogra> thesaltydog, be careful if you help \sh with bugs he'll secretly install more and more KDE stuff on your deskop until he has taken it over wih KDE completely ;)
<\sh> ogra: pscht
<ogra> *g*
<thesaltydog> ogra, Thanks! I will take care..
<ogra> heh
<\sh> ogra: frank installed even on his sony laptop ubuntu ;)
<\sh> ogra: and now  I have to take over your job, to fix it up again ;)
<ogra> zimmermann ? 
<\sh> ogra: sure
<ogra> ithought your boss :)
<\sh> ogra: no..he runs suse on his server at home
<ogra> bah
<ogra> convert him
<\sh> ogra: but saturn has again linksys wrt54g on special for 55 
<ogra> yay
* \sh needs a new job to buy all this nifty toys...
<\sh> s/this/these/
<bddebian> infinity: ping?
<segfault> there's some untranslated strings in the post-install of ubuntu (that screen which starts after it has copied all packages, and reboot). does anyone know which package is that?
<segfault> tried casper, but is unlikely to be it
<ogra> casper is the live CD
<Mithrandir> segfault: base-config, mostly
<ogra> segfault, you mean after reboot ? 
<segfault> yes
<ogra> thats base-config, yes
<segfault> ok, i'll look into that
<segfault> is there any plan to translate the boot messages?
<segfault> that ones which appear when using usplash
<zyga> segfault: hmm interesting 
<zyga> segfault: I'll be glad to assist with that
<\sh> infinity / lamont: can one of you have a look on i486-linux-gnu-gcc -shared  -Wl,--whole-archive data-types/.libs/libdata-types.a low-level/.libs/liblow-level.a driver/.libs/libdriver.a main/.libs/libmain.a engine/.libs/libengine.a -Wl,--no-whole-archive  -llockfile -pthread /usr/lib/libdb-4.2.so /usr/lib/libgnutls.so -lgnutls-openssl /usr/lib/libsasl2.so  -Wl,-soname -Wl,libetpan.so.3 -o .libs/libetpan.so.3.0.0
<zyga> s/ll/d/
<\sh> crap
<segfault> that should be easy to do
<\sh> I hate sometimes this copy&paste
<bddebian> :-)
<\sh> infinity / lamont: sorry, can you have a look at http://people.ubuntu.com/~lamont/buildLogs/libe/libetpan/0.38-2/libetpan_0.38-2_20050926-1616-i386-failed.gz 
<\sh> it build ok in my local pbuilder...
<segfault> like... source /etc/usplash/$LANG.msg... and then, echo $VARs... etc.
<zyga> segfault: the messages are not from usplash itself
<segfault> from the init scripts?
<zyga> segfault: yes
<zyga> that's what I think at least
<segfault> ogra: i think it's not base-config either
<segfault> it's fully translated to pt_BR, and in colony 5 appeared as untranslated
<ogra> then its probably something base-config loads
<segfault> are you sure that the new progress bar (which was all text-mode in hoary) is configured there?
<zyga> mdz: is there any usplash4kubuntu or edubuntu?
<segfault> it has strings like "Unpacking PACKAGENAME", "Configuring PACKAGENAME", "Installed PACKAGENAME"
<mdz> zyga: yes
<ogra> zyga, http://www.grawert.net/edubuntu/edusplash.png
<ogra> as well as http://www.grawert.net/edubuntu/edu_isolinux.png
<mdz> segfault: it's still text mode, but it's a progress bar rather than scrolling inscrutable text
<ogra> i'm just waiting for jbailey to enable the usage of different pic in usplash
<segfault> mdz: yeah, i meant without that dialog stuf... do you know which package holds it?
<zyga> mdz: BTW: how many colours can the image use? less than 16?
<Riddell> zyga: KubuntuArtwork has the kubuntu one
<ogra> the isolinux one is already in
<mdz> segfault: those strings are in apt
<mdz> segfault: base-config runs the progress bar
<mdz> zyga: 16 in total, including the background, progress bar and status messages
<zyga> mdz: could the strings in /etc/init.d/rc be translated? I mean - UTF8 support and such
<mdz> zyga: the boot process isn't internationalized yet, but in theory it's possible
<mdz> it would be a significant amount of work to internationalize it
<zyga> mdz: well, it's trivial to i18n most common messages (unless they are really broken)
<zyga> will usplash handle utf8?
<Keybuk> mdz: aren't those strings in base-config from dpkg ?
<Keybuk> I thought it listened on the status-fd and translated it into messages
<ogra> Keybuk, the progressbar reads apt output
<ogra> and displays it...
<Keybuk> apt doesn't display Unpacking or Configuring though ... those seem to correspond to dpkg events
<ogra> yes, but driven by apt...
<Keybuk> really?
<ogra> it just reads from a pipe
<Keybuk> ah, so apt listens to the dpkg status-fd things and then produces those strings which base-config reads?
<ogra> base-config or rather the progressbar reads stdout from the apt command... iirc
<ogra> its some weeks ago that i dealt with it...
<mdz> Keybuk: yeah, I guess it uses strings from both apt and dpkg
<mdz> Keybuk: hmm, no
<mdz> Keybuk: I think they are all in apt
<zyga> mdz: does the system in general have a locale?
<mdz> zyga: the system-wide default is in /etc/environment
<zyga> mdz: thanks, I'll play with some trivial i18n for usplash :-)
<mdz> Keybuk: the table in dpkgpm.cc maps dpkg status stuff to human-readable strings
<Keybuk> ah, ok
<spayne> jbailey: ping
<spayne> jdub: ping
<ogra> does anyone else think the -devel list should be read only from the forums ? 
<ogra> the noise raises daily
<jbailey> spayne: Are you looking for me in particular, or just anyone named Jeff? =)
<zyga> segfault: do you plan to i18nlize boot messages?
<dilinger> attention all Jeffs: there is black bmw in the parking lot with its lights on.  the license plate says "JEFF".
<jbailey> I'll take it.
<jbailey> Anyone got a screwdriver for the ignition?
<spayne> yes, here you go
<dholbach> dilinger: don't let ddaa hear you about BMWs :)
<segfault> yeah, that would be nice
<dilinger> dholbach: is that a sore topic?
<dholbach> dilinger: he referred to a french saying that included BMWs and hemorrhoids
<segfault> from boot to user interface, everything translated.
<zyga> segfault: actually getting the default install translated would be nice
<zyga> segfault: grep for uslpash in /etc and /lib
<zyga> segfault: the real work needs to be done in /etc/init.d
<dilinger> heh
<zyga> and getting the i18n stuff somewhere
<jkrogh> If the installer framebuffer looks strange.. what should i put at the bootprompt? 
<segfault> i see, and define some place to store the translated strings.
<jkrogh> Nevermind. 
<jkrogh> Oh.. not the first framebuffer, but the only the one the installations starts in. 
<zyga> segfault: yes, I've got a small utility that simplifies i18n of shell scripts
<zyga> segfault: could you locate the messages that get displayed after default install?
<segfault> humm, not right now
<segfault> i left my laptop home
<segfault> can you send me that script? and as soon as i get home i'll send you those strings
<jkrogh> Is it a bug when I need to specify vga=771 on the installer prompt to get a decent installer (readable)
<zyga> segfault: I don't have it packaged as a .deb yet - it's pure bash though
<zyga> if you want it badly I can just give you an export of the CVS archive
<Kamion> jkrogh: if it's a bug, it's in the kernel
<Kamion> jkrogh: I cannot do anything about that in the installer
<Kamion> zyga: what's wrong with /usr/bin/gettext? ;)
<Kamion> (or trivial shell functions on top of that)
* Kamion -> karate
<segfault> zyga: yah, if you can please
<segfault> so i can play with it later
<zyga> segfault: one moment
<zyga> segfault: www.suxx.pl/tools/i18n
<jkrogh> Kamion: Ok.. I filed it on "UNKNOWN". 16387
<jkrogh> How far should I go in the testing of the installer? Is a "Because of an unknown readon it is impossible to resize this partition" .. a bug that should be filed? 
<zyga> readon?
<jkrogh> sorry "reason"
<mdz> jkrogh: check the log; it should contain the reason
<jkrogh> mdz: Where is the log? 
<mdz> jkrogh: alt+f3 or so, and /var/log
<bddebian> Heya slomo
<slomo> hi bddebian :)
<ogra> OMG
<spayne> does this error mean anything to anyone
<spayne> usb 3-3: device not accepting address 3, error -71
<spayne> when i try my WiFi adaptor in BReezy
<slomo> jbailey: ping?
<ogra> why the heck is there a backport of k3b in the unofficial backports ?
<jbailey> slomo: pong
<ogra> it obviously breaks kubuntu-desktop
<ogra> ^^^^ Riddell 
<ogra> Riddell, you should talk to jdong
<slomo> jbailey: ony news on the ppc/xfs bug?
<jkrogh> Am I the only one that gets this strange behaviour from the bugzilla.. when I enter information on one bug and submits it, I end up at a totally different bug. 
<jbailey> slomo: Not beyond a brief conversation that colin and I had.
<Riddell> ogra: how does it break kubuntu-desktop?
<slomo> jbailey: ok :(
<jbailey> slomo: The best gues sis that yaboot might load extra crap onto the end that isn't important with cramfs but is with an cpio.gz
<ogra> Riddell, k3b depends on all the c2 packages which arent in hoary
<jbailey> slomo: So a bug in the XFS reader in yaboot.
<ogra> Riddell, one requirement for giving them the bandwith, server and buildd access was that they shut down the unofficial repos...
<jkrogh> Hm. That seems to be a feature. 
<slomo> jbailey: hmmm... wonderfull ;) maybe i'll just create a ext2 boot partition...
<ogra> pitti i and several others had a hard weekend because of the firefox crap they made already
<jbailey> slomo: That would be the simplest path, but it still needs to be fixed.
<jbailey> slomo: Up to you.
<Riddell> jbailey: what's the status of customisable usplash?
<slomo> jbailey: sure... the ext2 partition would be just to have it really working again... but i'll help you however i could ;)
<jbailey> Riddell: Testing.  Just need to upload the artwork for you.  sladen had said that the one he provided me didn't have the right colours on the right pallettes.  I should poke him for an updated one.
<Riddell> jbailey: he's left my flat so I can't physically poke him any more, but the file is on KubuntuArtwork anyway
<jkrogh> mdz: How do I take a screenshot of the installer? 
<tseng> jkrogh: run it in vmware
<mdz> jkrogh: if you're writing documentation, qemu
<jbailey> Riddell: Cool.  I had given him some pallette numbers that he needed to use for foreground/background/"RED"
<mdz> jkrogh: if you're reporting a bug, a digital camera pointed at the screen
<jkrogh> mdz: It for the bug on the X30 you just commented. 
<jkrogh> Oki.. 
<mdz> jkrogh: a screenshot wouldn't help; we need a photo
<mdz> jkrogh: since you mentioned it, please use a descriptive summary when reporting bugs
<seb128> Kamion: where are the "please press one of these keys" (auto-keymap selection) and "Resize IDE" (partitions modifications) strings from the installer?
<mdz> jkrogh: "Installation using PXE" didn't say anything about the problem you experienced
<jkrogh> mdz: I'll do my best. 
<jcohen85> jbailey, hey, did you get a chance to make a new initramfs-tools package
<Keybuk> hmm... odd explosion noises from outside
<Treenaks> Keybuk: Alien invasion?
<Keybuk> could be
<concept10> did the redhat networkmanager make it into breezy?
<Keybuk> sounds a bit distant to be my mail server's hard disk blowing up again
<Nafallo> Keybuk: your neighboors then? :-)
<Nafallo> concept10: no
<Nafallo> concept10: or rather... it's in universe :-P
<jbailey> jcohen85: This is for debug timing?
<concept10> Nafallo, thanks, what is the pkgname?
<Nafallo> concept10: network-manager ofcourse.
<jkrogh> Should I use a special installation method to be allowed to specify a local "mirror" for installing packages? 
<concept10> Nafallo, okay..heh didnt see it...but thanks
<jcohen85> jbailey, well, i sent you sent me one that created a debug file with timing and it showed that my IDE drives were taking 5
<jbailey> jcohen85: Right, which doesn't explain the 15 seconds you're reporting. =(
<jcohen85> you said you would need to do something more to find out what the problem is
<jcohen85> what would you have to do?
<jbailey> jcohen85: Lace the whole initramfs-tools with "date" commands and output it to a file.
<jcohen85> jbailey, are you planning to do that?
<Keybuk> Nafallo: bit fireworks display in the city centre
* Keybuk wonders what that's all about
<jbailey> jcohen85: Begrudgingly. =)
<jbailey> jcohen85: I had hoped that perhaps I would get some inspiration on how to do this in a non-sucky way.
<lool> mdz: ping?
<mdz> lool: yes?
<lool> mdz: (query)
<jkrogh> There are several "installer" components.. which one should I file feature-requests for the mirror-selection part on? 
<fabbione> elmo: pong?
<elmo> fabbione: nm, sorry - got benc instead
<mjg59> elmo: Hello?
<elmo> mjg59: ?
<fabbione> elmo: perfect, did you get everything sorted?
<elmo> fabbione: yeah, thanks
<fabbione> no problem
<mjg59> elmo: You were looking for me earlier?
<mjg59> Except it turns out that Freenode blocked my reply to you
<Robot101> thfreenode.
<elmo> are you registered now?
<mjg59> Yes, but I can't remember my password
<janimo> is there a simple way to find out recursive depends of a package (something like germinate does I think)
<mjg59> And can't be arsed getting it reissued
<tseng> janimo: apt-cache rdepends foo
<janimo> not reverse, recursive :)
<tseng> umn
<janimo> want to find out why gaim brings in bonobo, even it's not in it's immediate depends
<mvo> janimo:   --recurse
<Robot101> janimo: gaim-evolution plugin?
<janimo> mvo, Robot101 thanks guys
<janimo> Robot101 gaim does not seem to depend on evo plugin, where do you see that?
<Robot101> it suggests evolution-data-server
<Robot101> is it installing new, or just upgrading?
<janimo> I assume Suggested packages are not installed right?
<janimo> new install
<Robot101> if it suggests: foo (>ver), and you have an old foo, it might upgrade it
<janimo> or was there a recent change in apt re suggest: field?hmm
<j^> a52dec prints "No accelerated IMDCT transform found" to stderr, this is of no interest to anyone, would a patch be acccepted?
<j^> looking at the code it will allways print that 
<j^> liba52-0.7.4
<bddebian> infinity or lamont-away: ping?
<zyga> yay - my first SMP box is online :D
<slomo> jbailey: found a similar bug probably... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156488
<Kamion> seb128: the first would be cdebconf except smurfix forgot to actually make it translatable; I'm fixing that now
<janimo> seb128, ping
<Kamion> seb128: I'm not sure exactly what you mean by the second message
<bddebian> infinity: If you come around, can you please clear the dep-wait for bayonne?
<Kamion> jkrogh: if in doubt, use 'debian-installer' as a catch-all for installer bugs. In this particular case, a more accurate component is probably 'choose-mirror'.
<jkrogh> Kamion: Ok.. This one should actualy have been assingen to "go to bed, you're tired".. since I actually just found the feature where it should be. 
<Kamion> fair enough :)
<jbailey> slomo: Ah, interesting.
<slomo> jbailey: but that was the only similar bug i found with google... but yaboot has other problems with xfs it seems ;) when the kernel is a fragmented file everything breaks
<seb128> Kamion: the partionner list of options
<seb128> * Resize IDE
<seb128> * use LVM
<seb128> * ...
<slomo> jbailey: maybe we should forbid installing on xfs in the installer when we can't fix it for the release
<Kamion> seb128: oh, you confused me because that isn't an accurate quote
<jbailey> slomo: I expect it will be fixable.
<Kamion> seb128: the "IDE" there is part of a substitution, so searching for "Resize IDE" won't find anything
<jbailey> slomo: HAving narrowed it down to this makes it easier to hack on at least.
<jbailey> slomo: Also, I know the guy who's been doing xfs for grub2, I can ask him for thoughts.
<seb128> Kamion: sorry, that's what I've noted from my install ... the "Resize" is not translated
<slomo> jbailey: sounds good... did you already talk to the yaboot people?
<Kamion> seb128: it's partman-auto - trying to figure out why it's not showing up in installer-po
<Kamion> _Description: Resize ${PARTITION} and use freed space
<squirrelpimp> anyone knowing, when the dri version mismatch will be fixed in the breezy repos?
<seb128> Kamion: yeah, that's probably this one 
<Kamion> seb128: the .po file's there in the partman-auto source package, anyway
<Kamion> slomo: forbidding it's an option but it's a last resort
* Kamion -> bed
<squirrelpimp> i know theres this workaround... but will it be fixed proberly?
<seb128> Kamion: 'night
* squirrelpimp is no fan of downloading binary modules...
<sabdfl> gnight kamion
<sabdfl> actually, night all ;-)
#ubuntu-devel 2005-10-02
<sedak> is there a irc channel for the gnome project ??
<kent> sedak, #gnome?  (perhaps on some other server though..)
<sedak> thank you !
<sedak> i'll try this one
<mdke> sedak, irc.gnome.org should do it
<sedak> ok
<sedak> seems more appropriate then
<sedak> thanks
<jbailey> slomo: I haven't.  I want to prove that first.
<jbailey> Like, I want to prove that it's likely exactly that.
<mdz> mvo: so it looks like we need to solve this console font problem sooner rather than later
<mvo> mdz: yes, #15102 is a serious issue :/
<dholbach> good night everybody
<tseng> bye dholbach 
<mdz> mvo: please make it your first priority tomorrow
<mvo> mdz: ok
* mvo goes to bed now too
<tseng> good night germany
* netjoined: irc.freenode.net -> zelazny.freenode.net
* netjoined: irc.freenode.net -> zelazny.freenode.net
<Burglaptop> BenC, on linux-source, the maintainer and changed by are two different @ubuntu.com for you
<Keybuk> meh
<Keybuk> I really hate it when you investigate why something doesn't work, and realise it doesn't work because there's nothing to _make_ it work
<Keybuk> so, the reason permission changes aren't made to scanner devices (etc. etc.) on boot is because at the point that happens, the filesystem is still mounted readonly
<Keybuk> in fact, I'm wondering whether in a couple of these cases, the device is made in the initramfs so the real filesystem isn't even around yet <g>
<mjg59> Uh.
<mjg59> The /dev from the initramfs is the same one that we use once / is mounted
<mjg59> And it always ought to be a tmpfs
* lamont-away is home, deals with household chores
<Keybuk> yes, but this script is trying to change the permission of something not-under-/dev
<Keybuk> and I don't think this script is even _on_ the initramfs
<mjg59> Oh
<Keybuk> so we have the situation where /etc/hotplug.d/* is being run by udev once the rules are done
<Keybuk> if that happens at S04, those scripts can't modify anything other than /dev (which is entirely sane)
<mjg59> Yeah
<mjg59> So, uh, what is it trying to alter?
<Keybuk> but if the device gets loaded in the initramfs, those scripts don't happen at all
<Keybuk> something under /proc
<mjg59> But /proc isn't part of /
<mjg59> It's never read-only
<Keybuk> yeah, I'm still trying to work this out
<Keybuk> so far I can't find the .ko that matches any scanner
<Keybuk> actually, I don't understand this at all ... from what I can tell, every single device plugged in should end up root.plugdev because of the libgphoto2.hotplug script
<Keybuk> or, at least, every single usb device
<Keybuk> aha!  thankfully that doesn't happen because it uses an environment variable that doesn't exist anymore, heh
<Keybuk> giggle
<Keybuk> no, it really does
<Keybuk> syndicate scott% ls -l /proc/bus/usb/001/004
<Keybuk> -rw-rw----  1 root plugdev 52 2005-09-27 01:55 /proc/bus/usb/001/004
<Keybuk> Bus 001 Device 004: ID 045e:001e Microsoft Corp. IntelliMouse Explorer
* Keybuk wonders whether he can pmount /dev/input/mice
* mjg59 kicks X
<Keybuk> heh
<elmo> would it be stupid to ask why we go to so much effort to hotplug a mouse when we could just build it in?
<Keybuk> we do pretty much
<Keybuk> I was just using a mouse there as an example for "something that's usb, but not a scanner"
<Keybuk> uh, camera
<Keybuk> I've had "why the fuck isn't this compiled in?" arguments before for many things
<Keybuk> why is the AF_UNIX/AF_LOCAL network protocol a module?
<mjg59> I get a fixed hotkey-setup into the archive, and then everyone bitches that X doesn't work properly
<mjg59> I mean, ungk.
<Keybuk> heh, do you like laptop-detect bugs mjg59 ?
<mjg59> Is this a trick question?
<mjg59> Can you ask him for dmidecode information?
<Keybuk> probably
<Keybuk> will wait until he replies to say laptop-detect say "nah"
<fabbione> morning guys
<bddebian> Morning fabbione 
<fabbione> yo
<blahrus> I assume gst is going to be fixed next time around .9?? audio/video sync issues I mean
<Amaranth> we have a dirty secret?
<Amaranth> "Whether on Distrowatch or on forums, voices whisper that Ubuntu has a dirty secret you may not want to hear: they don't keep the compatibility with Debian, and they want to fork away from their mother distribution."
<ajmitch> Amaranth: sure, and the sky is falling at noon
<Amaranth> cool
<calc> Amaranth: hahahaha
<Amaranth> should i wear sunglasses for that?
<calc> Amaranth: who is the retard that wrote that
<Amaranth> http://www.libervis.com/modules/smartsection/item.php?itemid=28
<jsgotangco> lol
<calc> as someone pointed out with DCC the second you make one change you have forked
<jsgotangco> linspire didn't fork?
<calc> so the only way ubuntu would not be forked is if it changed nothing at all (ie just be a mirror)
<Burglaptop> Amaranth, see the response by Mark to sounder
<Amaranth> i don't read sounder, can you link me?
<azeem> http://lists.ubuntu.com/archives/sounder/attachments/20050926/59b358e2/faq-0001.html
<jsgotangco> it would be nice if sabdfl would have that posted on the homepage
<blahrus> should check out Mark Shuttleworth's speach at debconf, think you might understand his goals and passions a bit more
<blahrus> and forking is ok ;)
<Amaranth> It's a spoon!
<Amaranth> jsgotangco: That would just show the article to people that haven't seen it and make it a bigger issue.
<Amaranth> jsgotangco: It's like how coca-cola was beating pepsi until they started talking about pepsi.
<jsgotangco> there is no spoon...
<jsgotangco> heh
<ajmitch> hm, interesting sounder post there
<jbailey> I think it's funny that people say we want to fork away.  That just means more work.  Why would we do that? =)
<ajmitch> you're right, we're lazy :)
<bddebian> heh
<poningru> its a spoon
<poningru> no need for a knife
<poningru> or a fork
<Amaranth> it's a spork!
<Rotund> anyone know if there's a decent gnome Zeroconf configurator?  If not, I'm thinking of writing one.
<Burglaptop> Rotund, talk to Lathiat 
<Rotund> he seems away
<Rotund> Is he the resident Zeroconf guy or is he working on one?
<Burglaptop> Rotund, he is one of the upstreams for Avahi, the freedesktop implementation of zeroconf
<ajmitch> Rotund: he's the resident zeroconf guy
<Rotund> yeah.  that's what I was gonna base it on
<ajmitch> what sort of configuration were you thinking of?
<Rotund> I haven't found one, but I wouldn't think it would be too difficult
<Burglaptop> Rotund, there has also been some discussion on the desktop-devel list of gnome
<Rotund> setting up the services your computer is sending
<ajmitch> right
<ajmitch> so configuring avahi-daemon's services
<Rotund> right
<ajmitch> you  may want to visit #avahi when people are around
<Rotund> perferably have it "guess" ones by portscanning yourself
<Rotund> preferably that is
<ajmitch> #avahi looks fairly quiet at the moment :)
<Rotund> yes it does
<Rotund> I'm sure someone can tell me how to tell what ports are opened on your own computer via the kernel, right?
<Rotund> or a command-line tool
<rob^> nmap
<Rotund> hmmm.  There should be a way to do it w/o portscanning
<rob^> or just go to grc.com or others
<infinity> bddebian : Bayonne is FTBFS on amd64 and ia64, which isn't surprising, since it seems to fail on almost every Debian arch at buildd.debian.org, except for powerpc.
<bddebian> infinity: OK, thx
<fabbione> mdz: ping?
<jkrogh> Is it a reportable bug, when the network don't work after hibernation? 
<HrdwrBoB> I just hibernated and came back and my network wasn't setup
<fabbione> pkg: acpi-support iirc
<mdz> fabbione: pong
<fabbione> mdz: any objections if i upload a xorg with sparc only changes?
<fabbione> (it's one liner to fix xserver-xorg Depends: on sparc)
<fabbione> no code changes of any kind
<mdz> fabbione: I would prefer that you fix some non-sparc bugs at the same time, actually
<fabbione> mdz: my sparc work is outside working hours.. so i have to follow the rules of a MOTU and such
<mdz> I know it is your favorite package ;-)
<fabbione> mdz: i have no idea if daniels has other stuff in queue.. i did mail him, but got no answer
<fabbione> mdz: yeah right.. and i am santa claus :P
<mdz> ho ho ho
* fabbione watches white beard grwoning on his face
<fabbione> ARGH! my clothes are turning red!
<infinity> mdz : I need an opinion on #14991
<infinity> mdz : (apache2 security update broke svn+ssl+clientcerts)
<infinity> mdz : The reason it broke is because the users were (unintentionally) relying on the very bug we fixed.  The "feature" they were using was one that apache never actually had.
<mdz> does it affect ubuntu?
<infinity> mdz : Yes, it affects us, including the security updates we did for Warty and Hoary.
<jkrogh> Is it possible to get the debuggin-output(stdout/err) from an applet? (The network-monitor reports disconnected, but the network works fine) 
<mdz> infinity: what's the one-line summary of the breakage?
<infinity> mdz : Now, I have a patch to add that feature (thus fixing the regression), which I will upload to breezy.  But should we care about the regression in warty/hoary, or just leave it as-sis?
<infinity> mdz : Having a mixed read-only/read-write SVN repo that uses SSL client certs for authentication used to work, no longer does.
<mdz> infinity: can I see the patch?
<infinity> http://cerberus.0c3.net/~adconrad/047_verify_client_fix
<infinity> It's a no-brainer for includion in breezy, as we DID break something people have relied on for ages, but I want an opinion on if you feel something that large is worth inclusion in hoary, or if we just leave it.
<infinity> mdz : Basically, requests with bodies have never been able to trigger an SSL renegotiation, but that precise feature is required to allow mised read-only/read-write SVN (and several other use-cases, like a <Location> that requires SSL auth for POST, etc).
<infinity> mdz : It stopped working when we noticed the bug where <VirtualHost>SSLClientVerify Optional <Location>SSLClientVerify required </Location></VirtualHost> didn't actually work, and the renegotiatoin wasn't being forced.  Oops.
<infinity> So, fix that, and the bug people relied on for ages suddenly goes away and turns intoa feature request. :)
<ajmitch> hm, why does the (recently synced) libpt-dev have /usr/lib/libpt.so.1.8 symlink? I thought that usually goes in the lib package itself?
<infinity> ajmitch : because someone screwed up?
<ajmitch> infinity: probably, and it affects upgrades from the earlier version :)
<mdz> infinity: has anyone else rolled it into a security update yet?
<mdz> any real-world production environment feedback on the patch?
<infinity> mdz : Not sure, I'll poke Joe at RedHat and see if they've fixed the regression.
<mdz> brb
<mdz> irqpoll strikes again
<infinity> mdz : The bug submitter has tested it for me, as well as several people on the apache lists (and a mess of people who've reported the bug in the apache BTS)
<fabbione> GO FIREFOX!
<fabbione> hoary -> breezy update is no go
<mae> y'know, banshee looks fairly promising for the next ubuntu release if they fix some _very_ annoying bugs.
<infinity> mdz : The bug submitter has tested it for me, as well as several people on the apache lists (and a mess of people who've reported the bug in the apache BTS).  It's also been rolled into apache trunk and apache 2.2 (waiting on enough votes for inclusion to 2.0 still)
<infinity> mdz : TBH, I'm not picky about if we include it in warty/hoary (as no one's reported it in Ubuntu, only in Debian and other dists), and breezy is just around the corner, so in a few weeks, I can tell people who encounter the bug that "it's fixed in breezy"... Just wanted to get your take on it, if perhaps you think it's worth fixing in warty/hoary.
<fabbione> morning sabdfl 
<mdz> infinity: hmm
<sabdfl> moin moin
<ajmitch> hi sabdfl 
<mdz> infinity: I'm inclined to agree; let's leave it for a bit and see if anyone screams
<mdz> the breezy release gives us a good opportunity to offer users a choice of stability or the fix
<infinity> mdz : Alright.  I will fix it in breezy today.  I'm inclined to believe that the intersection of "people running hoary servers" and "people using this apache config" must be pretty close to zero, or we'd have a bug report or two by now.
<infinity> (It's not the sort of bug you can ignore or work around, so people who have complained)
<infinity> s/who have/would have/
* infinity stares at his fingers.
<infinity> (Note that I've had several "me too"s on the Debian bug, and there is a large group of people whining about it upstream)
<infinity> ingi2Gee
* infinity changes the password on that router.
<infinity> <sigh>
<mdz> infinity: it's OK it showed up as ******* ;-)
<infinity> Oh, handy!
<infinity> :)
<pitti> Good morning
<desrt> word up, pitti
<fabbione> hey pitti
<fabbione> mdz: lol
<Mithrandir> mdz: what's a sane way to handle bugs such as 16402 which are "this will bite us later"?  I'm reluctant of closing it, but it would be nice if it didn't show up in the bug lists..
<fabbione> Diziet: your last firefox upload breaks hoary -> breezy upgrades
<mdz> Mithrandir: the only truly sane way is to keep it open
<mdz> Mithrandir: but you could resolve it REMIND and then set an at job to remind you to reopen it ;-)
<Mithrandir> mdz: could we reopen all bug reports resolved LATER or REMIND after breezy releases?  That could work and would make the state sane
<Mithrandir> or useful, or whatever
<infinity> This is what milestones are for...
<pitti> infinity: ah, the CAN is there, I forward it to the Debian bug
<infinity> pitti : Excellent.  Cheers.
<henriquemaia> hello, I have just upgraded to breezy and now my keyboard (pt) is not working right. Does anyone knows how to solve this? (a bug, maybe?)
<mdz> Mithrandir: you can drop the priority if you like
<mdz> Mithrandir: probably best to just keep it open; Debian will hopefully fix it soon, and we can NOTWARTY it then
<Mithrandir> mdz: mhm, I guess so
<infinity> mdz : Did Kamion get a chance to discuss lrm and d-i with you?
<fabbione> hmmmmm
<\sh> morning
<\sh> infinity: ping I just saw your upload of libetpan, why did it compile without complains in my pbuilder then? (looking at gnutls build dep)
<infinity> \sh : Because your pbuilder chose a different libgnutls-dev alternative than sbuild did.
<infinity> \sh : Starting the gnutls12 (which we don't have), libgnutls-dev has become a real package, rather than a virtual, hence why it works in Debian.
<infinity> s/the gnutls12/with gnutls12/
<\sh> infinity: but I don't have any debian repos in it so it uses only our breezy archives
<fabbione> mdz: do you actually export XORG_SYNC_RANGES inside casper?
<infinity> \sh : Yes, and?
<mdz> fabbione: no
<infinity> \sh : We have three packages in breezy that prodive the virtual package "libgnutls-dev"... Only one of them (libgnutls11-dev) will actually work to build that package.
<infinity> \sh : sbuild picks libgnutls7-dev.
<infinity> \sh : Obviously, pbuilder picked 11-dev for you.
<\sh> infinity: ok..so pbuilder pulls in somehow (and this is somehow a bit strange) libgnutls11-dev 
<\sh> remind me to use sbuild for dapper as build env ,)
<bob2> isn't a virtual-only build-dep a bad idea anyway?
<\sh> infinity: thx btw for the upload...and now time go prepare for real life work *yawn*
<\sh> bbl
<infinity> bob2 : "real | virtual
<infinity> Err.
<infinity> bob2 : "real | virtual" is the nice way to go, if you want to guanratee a certain real package for buildd builds, but still allow backports easily.
<infinity> bob2 : That package had a pure virtual build-dep because in Debian, it's not a virtual anymore.
<bob2> ahh
<fabbione> who has a ppc here that can reproduce #16035 ?
<sabdfl> mjg59: ping
<sivang> morning all
<fabbione> mdz: i am checking some of the xorg bug, but i have the feeling that the issue is xresprobe
<fabbione> mdz: specially comparing the bare differences between generated configs
<fabbione> (same with 16035)
<fabbione> the problem is i don't have a ppc to test on...
<infinity> pitti : I still don't have that mail you forwarded to the BTS.  Can you just give me the CAN here, while I'm working on the packages? :)
<sabdfl> ah, i see some xubuntu action coming in
<sabdfl> good work guys
<infinity> xubuntu == xfce?
<fabbione> infinity: yeah
* infinity notes that it took a month or more to get xfce building and installable, so hopes SOMEONE is using it.
<sabdfl> infinity: lots of demand for it in the lightweight desktop community
<sabdfl> so thans for the effort
<infinity> Cool.  I hsould give it a spin sometime.
<Treenaks> sabdfl: does this also mean easy mixing (eduxubuntu?)
<infinity> I've not used anything on my laptop except for a very default ubuntu setup.
<bob2> haha
<infinity> keduxubuntu may be inunstallable due to unavoidable conflicts.  Someone should try. :)
<sabdfl> Treenaks: for some definition of easy, yes
<infinity> uninstallable, too.
<sivang> sabdfl: lol :)
<sabdfl> we won't publish all permutations and combinations as officially supported
<Treenaks> sabdfl: :)
<sabdfl> but it should be easy to arrange
* ajmitch wants se-ubuntu :)
<sivang> sabdfl: would be probably enough and nice to have some default in place, lightweight desktop users can probably tweak their way from there
<sivang> ajmitch: aren't you bringing this to ubuntu ?
<ajmitch> sivang: sure
<ajmitch> sivang: at least I'll try & hack the breezy install into shape for it
<infinity> ajmitch : With the rapid adoption of SELinux in sid/etch, we MAY be ready for it for dapper, but I wouldn't hold my breath.  dapper+1 may be more realistic, unless someone (sabdfl) decides to divert resources to making it happen.
<ajmitch> infinity: considering that there's only been 1 or 2 of us working on it in ubuntu til now, I think dapper's still a realistic goal to have the framework all in place
<ajmitch> infinity: although I don't think dapper would ship with a policy turned on by default
<infinity> ajmitch : Have you been tracking the patches flowing into debian base in the last month or two?
<ajmitch> yes
<sivang> I don't think it should be the highest priority, in enterprise point of view, with what I encounter, SElinux if comes in default install, isn't fully exploited to it's capabilities, and people on FC4 tend to disable it or do nasty hacks to get some software working.
<infinity> ajmitch : Cool.  Does any of it work yet? :)
<ajmitch> infinity: sure, the patches are pretty much what I've been using here to test
<infinity> Yeah, SELinux's complexity is a black mark against it, unfortunately.
<ajmitch> certainly
<ajmitch> writing policy comes close to black magic at times
* infinity nods.
<ajmitch> just because programs can do so many weird & wonderful things
<ajmitch> it's on the BOF list for UBZ, anyway
<infinity> And due to the (correct) "disallow everything unless I let you do stuff" security model, poeple are likely to get furstrated and just turn the whole thing off, which defeats the purpose.
<ajmitch> so I'll try & bring a useful demo :)
<infinity> So it needs to be made a bit more easy to configure, I suspect.
<ajmitch> it's improved a lot in the last year, with modular policy & runtime booleans
<ajmitch> so you can toggle policy in specified areas
<sivang> infinity: should probably have some GUI hooks so that each time this happens, a user is offered the possibilty to allow it, translated automatically to the underlying actions that need be taken for that in SELinux
<ajmitch> sivang: that's possible now
<ajmitch> possible to code, I mean :)
<infinity> sivang : yeah, for a desktop system, that does seem desiarable.
<sivang> ajmitch: ofcourse
<sivang> ajmitch: that's interesting, I should add this to the BOF Ideas?
<infinity> I need to get an SE-enabled server system running and play with it, I guess.
<ajmitch> sivang: sure
<infinity> sivang : I doubt the effort would be made to code it, unless an MOTU wants to take up the torch.
<sivang> ajmitch: if we do that, we rock the enterprise. I don't think any other distro has somethign like that
* ajmitch would probably put in some work for that
<infinity> sivang : But noting it as a "feature we should be on the lookout for" makes sense.
<ajmitch> I'm going to try & commit to a few hours a week at least, if people are open to it
<sivang> infinity: sorry, EPRASEERROR due to ENONNATIVESPEAKER :)
<infinity> sivang : Which part? ;)
<sivang> infinity: the whole sentence :)
<infinity> Right.  Just ignore it, then.  I don't ever say anything worth reading. :)
<ajmitch> heh
* infinity heads out to hunt down some sugar.
<sivang> lol
<jdub> vuntz: ha ha ha
* jdub spanks vuntz 
<vuntz> jdub: is this for your nice quote I sent? :-)
<jdub> yeah
* jdub copies it for pseudo-quoting vuntz, too ;)
<vuntz> ahah
<vuntz> jdub: maybe you can write some other cool stuff for my next mail? :-)
<sivang> vuntz: is it hilarious ? :)
<jdub> vuntz: maybe i should take advertising revenue for your mail ;)
<vuntz> :-)
<\sh> re
<sivang> Moins \sh  :)
<janimo> mvo, do you think launchpad-integration could be easily split as to provide at least the bonoboUI query method separately?
<janimo> rigth now lpi brings in gnome dependencies even if the program does not use gnome libs (gaim)
<janimo> I ask you since seb128 is not around and you worked on lpi too
<janimo> hey seb128 :) read 3 lines above :)
<seb128> hi janimo
<seb128> janimo: that's a joke, right?
<janimo> well if you laugh it is 
<janimo> but I asked seriously
<seb128> ...
<janimo> for xubuntu where we do not want gnome libs if possible
<janimo> gaim is not a gnome app
<seb128> hint: IRC start putting lines when you start your client
<seb128> not when your box is sleeping
<janimo> I thought you guys use scrollback and are always online :)
<janimo> I'll repeat that then
<seb128> you say "hi"
<seb128> why?
<janimo> mvo, do you think launchpad-integration could be easily split as to provide at least the bonoboUI query method separately?
<janimo> 10:50 < janimo> rigth now lpi brings in gnome dependencies even if the program does not use gnome libs (gaim)
<janimo> 10:50 < janimo> I ask you since seb128 is not around and you worked on lpi too
<janimo> seb128, these were the lines I wrote just before you enetered
<janimo> sorry if I confused you
<sivang> janimo: could be done, but currently I wrap the l-p functions with my bonnoboui ones to avoid code duplication
<dholbach> good morning
<janimo> sivang, how easily could it be done?
<janimo> morning daniel :)
<dholbach> hey jani
<seb128> janimo: liblaunchpad-integration0 and liblpint-bonobo0 are already splitted
<seb128> hello dholbach
<dholbach> morning seb
<janimo> seb128, but the integration lib needs the app which in turn needs all of them? I just had a cursory look at the sources
<janimo> seb128, in this case theoretically gaim should not need the gnome depends right?
<sivang> seb128: how do we get by that my wrapper funcs use launchpad-integration itself? 
<seb128> janimo: I don't care
<seb128> janimo: libgnome is quite small
<janimo> seb128, it may be quite small but it brings in other gnome dependencies (almost all )
<seb128> sivang: I don't get your question, what wrapper funcs?
<seb128> janimo: that's far from beeing true
<janimo> seb128, I have bare X installed + xfce
<seb128> raahhh, people are never happy
<seb128> I'll get some coffee
<seb128> later
<sivang> seb128: laterz
<janimo> when I tryp installing gaim it brings in bonobo,gnomeui,gamin,gconf2
<janimo> gnomevfs etc
<sivang> seb128: never mind, stupid quesiton :)
<janimo> sivang, any docs on lpi besides the wiki page and the source?
<sivang> janimo: not that I know of, sorry
<seb128> janimo: it's a trivial lib
<sivang> janimo: it's really simple though
<janimo> I'll read though it see if I can come up with more meaningful questions or even solutiones re my problem
<zyga> morning
<mvo> ping siretart 
<siretart> mvo: pong
<sivang> seb128: as a side note, gaim is not a bonobo app right?
<mvo> siretart: can you still reproduce #14077 on one of your machines? would you be able to test a updated version of u-n?
<janimo> sivang, not or it wouldn't work on windows I guess
<janimo> and before lpi it did only depend on gtk
<zyga> mvo: does language-selector still need hacking?
<siretart> mvo: I'd love to, but I don't have access to the affected machine right now
<seb128> sivang: no, and it doesn't use the bonobo lib neither
<siretart> mvo: and it could take until thursday until I see my dad again :(
<mvo> zyga: good question, did you find a bug :) I had hoped that my latest upload resolved most issue
<seb128> janimo: I'm not that happy with patching the apps for lpi neither, but I've not taken this decision
<sivang> 09:58 < janimo> when I tryp installing gaim it brings in bonobo,gnomeui,gamin,gconf2
<mvo> siretart: ok, thanks. it's a anoying bug because I was never able to reproduce it on one of my machines
<seb128> janimo: if you can come with a better design or code of the lib and send a patch you are welcome
<sivang> seb128: how come it pulls in bonobo when he tried to install gaim?
<seb128> installing the lib install "launchoad-integration" which Depends on libgnome2-0 which grabs gconf, gnomevfs, etc
<zyga> mvo: the UI needed some small changes if you remeber
<siretart> mvo: I was also confused. My dad came to my and was also very confused. I'm very proud of him that he found himself that killing u-n solves the issue for him 
<zyga> mvo: unfortunatly synaptic still has that small issue I've told you about (and patched)
<mvo> zyga: yes, synaptic needs a update 
<sivang> seb128 k
<mvo> zyga: sorry, what was it in language-selector again?
<janimo> sivang, seb128 yes that was my initial question, if lpi can be more granular so gaim can depend only on lpi_gtk not lpi_bonobo
<seb128> it is granular
<seb128> there is 2 libs
<seb128> one gtk and one bonobo
<janimo> I'll go back and dig since this would be nice for xubuntu
<seb128> what grabs libgnome is the part which start the browser
<seb128> it uses gnome-open
<janimo> seb128 oh but that could surely done easier not?
<zyga> buttons were very non-HIG
<janimo> some direct exec or something ?
<sivang> seb128: we could seperate the python scripts from launchapd integration ?
<seb128> gnome-open gets the default browser from your GNOME/gconf config
<mvo> zyga: the buttons are changed to "close/apply", wasn't that what you suggested?
<sivang> seb128: then each lib in turn would have to have it's execing functions, currently liblpint-bonobo uses the fire up function from launchpad-integration
<zyga> mvo: it seems better now - I've just had a look at it again
<mvo> zyga: thanks
<sivang> seb128: so possibly, copying the calling code from liblaunchpad-integration, into liblpint-bonoo, and making a seperate package to ship the python scripts would relieve lpint-bonobo from using launchapd-integration
<sivang> my 2c ..
<sivang> janimo: maybe that's what you meant?
<seb128> sivang: not a good option imho, what do you win by doing 2 different implementation?
<sivang> seb128: I don't win much , I agree. aside from splitting the dependencies 
<sivang> seb128: It's still code duplication which I don't like
<seb128> you don't split any dependency
<seb128> the only dep is libgnome due to gnome-open
<seb128> if you make some code getting the default browser without it you can change this code for everything
<seb128> no need to split
<zyga> mvo: separate l-s issue, the language and country names - are they pulled from the speciall package to avoid multiple translations?
<janimo> could there be a generic open script which checks and if there's a gconf reads from that otherwise uses x-www-browser or something
<crimsun> morning, jani
<janimo> so there would be no direct dep on gnome but would be used if available
<janimo> morning daniel :)
<mvo> zyga: they are copies from the iso-codecs package. They are not translated before
<zyga> mvo: they have to be - countries at least are translated in numerous packages
<zyga> I'm not sure about languages
<sivang> seb128: ah right, I see that now.
<mvo> zyga: then rosetta should be able to deal with that, shouldn't it? I would suggest "this was already translated somewhere else"?
<seb128> janimo: probably yep
<sivang> janimo: still that would be duplicating gnome-open's job, is it that bothering that it pulls those deps in? I reckon the don't take too much space..
<zyga> mvo: hmm true
<janimo> sivang, the disk space is the least of the concerns
<seb128> janimo: that's trivial to do if(gnome-open) gnome-open ... else non-gnome-call
<zyga> mvo: is it possible to get two .pot's (for two domains) from l-s?
<janimo> memory footprint and startup time
<janimo> those matter more for xfce targetted machines
<sivang> janimo: I see
<mvo> zyga: why two domains? one for the package and one for the countires/languages?
<janimo> seb128 but if(gnome-open) does not imply that there needs to be a dep on gnome-open for it to be called?what is that python or pseudocode?
<seb128> pseudo-code
<sivang> janimo: you can silently fail if !gnome-open, without depending on it
<janimo> so how to detect existence of gnome-open?I thought of checking if there exists a gconf dir
<seb128> you can move the libgnome Depends to a Recommend if you do that
<sivang> right
<seb128> janimo: no need to bother with gconf, if the file is on the disk or not works fine
<sivang> janimo: simple file exists checking probably
<zyga> mvo: yes
<sivang> janimo: we do the same with some gnome-cups-manager enhancment
<janimo> I still haven't read the lpi code so where exactly should that check be?
<sivang> janimo: I'll find it for you
<janimo> which files existence needs to be checked
<mvo> zyga: last time I checked rosetta didn't liked two pots in one dir. I would have to create a po and a po-countries dir. pretty ugly :/
<janimo> sivang, thanks do you want to take care of all this (i.e upload) or just point me to the right dir?
<janimo> direction
<sivang> janimo: as you prefer :) (Acutally I use seb128's sponsering for uploads for the moment)
<janimo> well I dont' mind looking myself but I am sure you'd do a better/quicker job
<janimo> so your call actually :)
<mvo> sivang: how is the firefox lp integration done btw? it misses the new icons it seems
<sivang> mvo: that was seb128's work :p :)
<janimo> hmm interesting, as ff did _not_ bring gnome in
<sivang> janimo: I'll email you with the details where to look anyhow. let talk afterwards
<janimo> sivang, thanks
<seb128> mvo: not with lpi, their html/javascript language is nothing like C :/
<sivang> seb128: you used html/javascript for lpi on fifie? 
<infinity> The whole UI is XML/JS.
<mvo> seb128: you hacked it in XUL?
<infinity> (XUL)
<sivang> omg. poor seb128 :-/
<seb128> mvo: dunno if that's XUL, I hack whatever language made the UI for them
<infinity> You could have hooked it in at the C++ level and exported the functions to XUL.
<infinity> (Which would make them available to other skins/themes, too)
<seb128> infinity: I've no clue on how to do that and about the firefox code ... but if somebody wants to do it he's welcome
<infinity> Note: This is not me volunteering for the task.
* mvo thinks infinit just put himself forward
<seb128> yeah
<seb128> it took my 1 day of work/builds to get the menu items here
<infinity> Heh.  File a bug and get Diziet to do it.  He LOVES hacking firefox, I can tell.
<seb128> and I don't intend to spend a week to get how you can use C here and hack XUL
<seb128> haha
<infinity> I have my hands full with non-GUI stuff.
<seb128> nice idea :)
<seb128> and I'm mine busy enough with GNOME
<seb128> I don't even use firefox
<seb128> epiphany-browser use lpi for its part :)
<infinity> Heh.
<infinity> My GUI is just a pretty way to launch a few dozen terminals.
<Mithrandir> infinity: you use GUIs for that?  I just hold down F1 until I have enough.
* mvo has xterm on his thinkpad button
* Mithrandir doesn't run tpb, pending a rewrite, so his thinkpad button doesn't do anything.
<mvo> Mithrandir: is upstream doing the rewrite? 
* mvo used to sponsor tpb
<Mithrandir> mvo: no idea, I've done a 90% job on my system, but it needs a bit more work.
<Mithrandir> I've got nice stuff like dbus integration and so on in there.
<mvo> Mithrandir: *yum*
<Mithrandir> which means that the user doesn't have to access the nvram himself, the process can run as a tpbd user which has rw access to /dev/nvram
<mvo> Mithrandir: nice. looking forward to it
<mvo> seb128: will you hate me if I change the gdm init script and add a special case for usplash (init the console-fonts right before gdm starts)?
<seb128> mvo: if that works, nop. If I get bugged because of you, you better start running now :p
* mvo starts runing (just to have some head-start)
<seb128> :)
<seb128> mvo: BTW do you still have those lpi warning on your todo, or should I put that on my list?
<mvo> seb128: I won't manage to look at it today that's pretty sure. not sure about tomorrow though
<seb128> any day before 5.10 is fine
<seb128> I've still ~170 non-upstream bugs on my list, it's enough to keep me busy for the week :p
<seb128> let me know if you start working on it, so we don't dup work
<mvo> seb128: ok. I have some tricky must-fix-before-breezy stuff as well, but I think I'll manage to put it somewhere in between
<seb128> mvo: thanks
<ajmitch> hi chmj 
* mvo waves to ajmitch 
<ajmitch> hi mvo :)
<mvo> ajmitch: we will see you in UBZ?
<ajmitch> mvo: sure
<mvo> ajmitch: nice!
<ajmitch> mvo: assuming I get my passport sorted out this week :)
<mvo> ajmitch: heh :) good luck!
<ajmitch> it just needs replaced due to some water damage
<ajmitch> easy to do
<ajmitch> just another expense for the trip though :)
<chmj> hey ajmitch 
<crispin> pitti: fyi, I am hoping to get a cf card 'soon', and will then do lots of in-depth debugging on that pmount wierdness
<pitti> crispin: you mean #14495?
<crispin> pitti: indeed
<pitti> crispin: I just replied again, I'm totally confused by the contradictions in the report
<crispin> pitti: yeah, it is getting a bit confusing in there
<pitti> crispin: I asked to restart from scratch
<crispin> yeah, I saw, sadly, I don't have a card at the moment, but when I do I'll work on it night and day till I track down where the problem is :-)
<seb128> mvo, pitti: wanna join #ubuntu-desktop ? :)
<pitti> seb128: in a minute
<fabbione> pitti: did you read my messages?
<pitti> fabbione: erm, email replies?
<sivang> mvo: what are those lpi warnings about? may I help with them?
<fabbione> pitti: also
<dholbach> ogra, Unfrgiven, sebest: want to join #ubuntu-desktop? :)
<mvo> sivang: warnings like: (synaptic:25229): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
<mvo> sivang: sure, go ahead :) you get them in non-bonobo using apps
<seb128> mvo: #ubuntu-destkop !!
<seb128> and non-UIManager apps
<seb128> ie: gucharmap
<sivang> seb128: I'll join #ubuntu-desktop now 
<seb128> feel free
<sivang> seb128: all desktop related bugs and development should go there?
<pitti> fabbione: alright, let's wait until the second patch is a bit more mature
<fabbione> ok
<fabbione> pitti: it looks sane too me
<fabbione> it's not that bad as it seems
<seb128> sivang: by example, but stuff like lpi can go on this chan too ... -desktop is a place to discuss with new people interested by desktop stuff, about bugs not concerning this chan (ie: minor desktop issues), etc
<sivang> seb128: ok, nice to see that. so the desktop team is mainly for attracting new people to the table?
<seb128> yep
<dholbach> sivang: and a place to discuss stuff, to make more cool stuff on the desktop happen
<Aegir> Good. I have a minor desktop issue with Ubuntu and I've been too hesitant to ask about it here :)
<Aegir> ...And I've killed the conversation. Go me...
<sivang> dholbach, seb128 : we should have some publicity about that, it appears that people are unaware of it
<dholbach> seb128: want me to do it? :p
<seb128> dholbach: do what, we mailed lists, I blogged ...
<dholbach> seb128: oh you did
* dholbach hugs seb128 
<seb128> :)
<dholbach> and you have a hackergotchi too :)
* dholbach never saw it
<seb128> some GNOME guys did it
<seb128> I've not asked for anything
* seb128 kicks jdub
<dholbach> oh come on :)
* ajmitch takes a look at planet gnome & spots it :)
<dholbach> sivang: do you have another idea for more publicity?
<dholbach> sivang: i ordered a plane painting #ubuntu-desktop at the sky over berlin, but that's all i could think of
* mvo checks seb128 hackergotchi too
<sivang> dholbach: hehe
<sivang> dholbach: serious?
<sivang> dholbach: we can go over upstream communities and offer them to participate 
<dholbach> sivang: not really :-p  - ask in #gnome* channels?
<seb128> no
<seb128> don't make noise on #gnome* chans :)
<dholbach> yeah, that's what i thought :)
<seb128> mails and planet are enough
<pitti> lifeless: ping
<sivang> seb128: cool then
<zyga_> seb128: okay
<zyga_> seb128: my laptop just died because of that bug
<seb128> what bug?
<zyga_> seb128: the thing is, some udev event launches a horde of scripts that then run another hordrde (>50) of hdparm
<seb128> you have not described it
<zyga_> I tried but the other computer died :-)
<zyga_> I run hoary on this one
<zyga_> it always happens after modprobing for cloop
<zyga_> and mounting cloop a moment later
<zyga_> I can reproduce it and I've got a log of ps aux if you'd like
<zyga_> http://www.suxx.pl/run.log
<zyga_> that's from yesterday
<zyga_> the number of hanging hdparms is not constant
<zyga_> they never die, I cannot kill any of them (all are in 'D' state according to top)
<zyga_> system is locked and hdd led keeps blinking
* infinity goes to get his dinner on.
<zyga_> seb128: if you have any questions/suggestions feel free ask
<seb128> zyga_: I let the udev guys reply to this one
<seb128> why do you think it comes from udev?
<zyga_> seb128: the ps aux shows it pretty clearly
<seb128> right
<zyga_> udev launches some udev_run_parts
<seb128> have you put a bug to bugzilla?
<zyga_> seb128: I tried yesterday when the box died
<zyga_> seb128: bugzilla or malone?
<zyga_> seb128: kernel spits 'hda: timeout waiting for DMA'
<zyga_> and 'drive not ready for command'
<seb128> bugzilla
<seb128> malone is for universe atm
<zyga_> okay
<seb128> hey vuntz
<vuntz> hi seb128
<seb128> dholbach: I've closed http://bugzilla.ubuntu.com/show_bug.cgi?id=16428
<seb128> dholbach: gdm uses the xorg config, GNOME uses the GNOME user config/xrandr ... that's not really a bug
<dholbach> i see, thanks for that
<seb128> np
<seb128> the situation is not ideal, we should have an easy way to reconfigure xorg, but keeping a bug on gdm for that is not really useful
<zyga_> seb128: our bugzilla, right?
<seb128> zyga_: bugzilla.ubuntu.com
<zyga_> seb128: can I change severity to major?
<seb128> zyga_: yep
<zyga_> seb128: #16433
<seb128> thanks
<zyga_> thanks
<hughsie> pitti: ping?
<pitti> Hi hughsie 
<pitti> hughsie: still problems with the hal datatype patch?
<hughsie> pitti, hi, yes!
<hughsie> then mv -f ".deps/probe-hiddev.Tpo" ".deps/probe-hiddev.Po"; else rm -f ".deps/probe-hiddev.Tpo"; exit 1; fi
<hughsie> In file included from probe-hiddev.c:41:
<hughsie> /usr/include/linux/hiddev.h:92: error: syntax error before __s32
<hughsie> /usr/include/linux/hiddev.h:94: error: syntax error before physical_minimum
<hughsie> /usr/include/linux/hiddev.h:95: error: syntax error before physical_maximum
<hughsie> /usr/include/linux/hiddev.h:98: error: syntax error before } token
<hughsie> /usr/include/linux/hiddev.h:119: error: syntax error before __s32
<pitti> hughsie: /msg please, please don't flood
<hughsie> msg pitti sorry...
<pitti> hughsie: hmm, configure, make, make clean worked fine for me
<hughsie> hmm... it worked for me too this morning too
<hughsie> but now it's complaining after a fresh checkout
<hughsie> got any ideas?
<pitti> hughsie: maybe one of the #include <asm/types.h> I removed really needs to be there?
<pitti> hughsie: you might try adding it again in probe-hiddev.c
<pitti> hughsie: maybe sys/types.h is enough, asm/ is really evil for an userspace program
<fabbione> asm should never be used directly
<hughsie> #include <asm/types.h> works....
<fabbione> userland should include sys/ or whatever that will take care of digging into asm if required
<hughsie> #include <sys/types.h> doesn't work
<fabbione> than something else is screwed too
<hughsie> i'm guessing  /usr/include/linux/hiddev.h shouldn't be using __s32
<pitti> hughsie: well, at least it should include asm/types.h on its own
<\sh> hmm...is it possible to grab now an daily ubuntu ISO with latest kernel upload (even for the installer?) ;)
<hughsie> hiddev.h?
<pitti> hughsie: yes, if the include file needs a symbol, it shouldn't rely on external files to include it
<pitti> hughsie: however,  wait: it *does* include asm/types.h already
<pitti> hughsie: are you sure that you properly recreated all autofoo files? so that the configure.in change is really active and the type definitions wiped?
<hughsie> pitti, ahh, let me check
<hughsie> pitti: no, i've just done a fresh autogen.sh, still the same error
<pitti> hughsie: what did you change between this morning and now?
<hughsie> pitti, nothing! thats the thing. I did a make distclean && ./autogen.sh && make
<pitti> odd
<pitti> hughsie: does "grep -r _s32" in your hal tree have any hits?
<Kamion> \sh: you can answer these questions for yourself by looking at the *.list files on cdimage
<pitti> hughsie: erm, "grep -r __s32 ." of course
<hughsie> pitti: no, but it wouldn't...  /usr/include/linux/hiddev.h has the __s32 tho
<zyga_> pitti: hi, who knows udev around here? It's about bugzilla #16433
<pitti> zyga_: please CC me on the bug, I'll have a look
<zyga_> pitti: k, thanks
<zyga_> pitti: adding martin.pitt@canonical.com
* dholbach <- lunch
<hughsie> pitti, should we really be using linux/hiddev.h?
<pitti> hughsie: not if you can avoid it :-) but I can't say off the top of my head if that's really necessary
* sivang just found proof Ubuntu can be used as easily if net easier then windows to do wireless communication.
<hughsie> pitti: shouldn't hiddev.h be using non-kernel type datatypes?
<Treenaks> sivang: unless you run into #14007 or #15080
<sivang> so gf (who's a mostly windows user) takes this edimax card which around most distros you need to compile a module, plugs into the breezy dell lappie, we have no wireless around there, she calls up "I will have network access here, you'll see" I'm telling her no way, you need at least an ESSID. boom. she pings me on IM.
<sivang> Treenaks: obviously she didn't run into them :)
<hughsie> pitti: mind if I fix the HAL build until we sort this mess out?
<hughsie> #include <asm/types.h>
<mjg59> elmo: Are you with cvd at the moment?
<pitti> hughsie: sure, it was there before, it's no regression
<pitti> hughsie: my primary reason for starting this was to make hal build on amdd64
<hughsie> pitti: sure, no problem - it's just my build fix might break the amd64 compile
<hughsie> ogra: just to let you know, I'm installing breezy as I speak... :-)
<ogra> YAY
<hughsie> ogra: want to get some ubuntu love
* ogra throws a big bag with ubuntu love on hughsie
<segfault> why people ignores #16386?
<ogra> :)
<sivang> Treenaks: ah apparently, there's a shared wrieless on the building, no charge :) 
<hughsie> ogra: i'm going to feel like a newbie again... :-)
<ogra> nahh... ubuntu is easy... and you got us around if you need us ;)
<hughsie> ogra: cool :-) thanks. Expect me to be complaining before long...
<Treenaks> sivang: cool :)
<Keybuk> pitti: dude
<zyga_> segfault: I'd love if people send whole urls
<zyga_> it makes lazy people like me more likely to click on the link
<segfault> heh
<segfault> http://bugzilla.ubuntu.com/show_bug.cgi?id=16386
<sebest> there is not a bugzilla bot? :)
<pitti> Keybuk: Hi! do you have a minute for discussing the hotplug mess?
<Keybuk> pitti: yup, that's exactly what I want to discuss
<Keybuk> hang on, let me get my gun
* pitti gets his armory
<Keybuk> anyone got gregkh and kay's addresses?
<Keybuk> so ...
<pitti> Keybuk: Greg KH <greg@kroah.com>
<Keybuk> hotplug
<Keybuk> I meant his real life address, for the killing :p
<pitti> Keybuk: oh, sorry :/
<Keybuk> you have one of the not-working usb cameras?
<pitti> Keybuk: send them a mail bomb instead (will drastically reduce your jail time, too)
<pitti> Keybuk: well, they work
<pitti> Keybuk: they are just controlled by libusb
<Keybuk> right, yours works?
<pitti> Keybuk: it's one of the gphoto2 cams which do not act as mass storage
<Keybuk> right, and those are currently communicated to with /proc/bus/usb/... yes?
<pitti> Keybuk: yes, provided that /proc/bus/usb/003/006 permissions are right
<pitti> Keybuk: yep
<pitti> Keybuk: thanks for pointing out the broken hotplug script, I indeed get *all* proc devices chmodded now
<Keybuk> I wonder what is replacing that
<Keybuk> /proc/bus/* is going away
<zyga_> I've got a non mass-storage digital camera
<zyga_> but it works just fine
<pitti> Keybuk: so it seems that hotplug.d/usb is always executed, instead of being called through the hotplug map
<Keybuk> I bet everyone's forgotten about those devices (I had)
<Keybuk> that's right
<Keybuk> ok, so we have
<pitti> Keybuk: you get a proper /dev/foo for your cam?
<Keybuk> mine's usb storage
<Keybuk> /etc/dev.d/$SUBSYSTEM/*.dev
<pitti> ah, I see
<Keybuk> these are run for every /dev device node created
<Keybuk> including those made at udevstart in S04udev
<pitti> yep, but that doesn't help for many scanners and cams
<Mithrandir> Keybuk: what'll replace /proc/bus/usb?  Proper devices?
<pitti> since they don't have a sysfs node
<Keybuk> though not those in initramfs because we dont copy the scripts there
<Keybuk> Mithrandir: see above, I suspect everyone's forgotten about it ... I'll ask on linux-hotplug-devel later
<Keybuk> right
<pitti> Keybuk: so the initial boot problem is that /proc/bus/usb is already there when initramfs runs, but there is no hotplug script there?
<Keybuk> next there's /etc/hotplug.d/$SUBSYSTEM/*.hotplug
<Keybuk> those are run for every /dev device node created as a result of a kernel uevent
<pitti> Keybuk: apparently they are run for more devices, not just /dev ones
<Keybuk> and last there's /etc/hotplug/$SUBSYSTEM/*.usermap
<pitti> Keybuk: I'd really like to keep the scanner and camera usermaps
<Keybuk> which are run as a result of the hotplug usb agent
<Keybuk> ok, if a usermap is involved, the script should not be in /etc/hotplug.d
<Keybuk> it should be in /etc/hotplug
<Keybuk> then it'll be run by the hotplug input.agent
<pitti> Keybuk: in the past, the usermap assigned a name to a vendor/product id, and then /etc/hotplug/usb/name was executed
<Keybuk> uh, usb.agent
<sivang> Keybuk: under the respective subsystem no?
<Keybuk> yes
<Keybuk> pitti: that's still true, that code didn't go away
<pitti> Keybuk: but /etc/hotplug/usb/ does not work any more...
<sivang> pitti: yep, this is what I do to send SIGHUP to cupsd
<Keybuk> pitti: it should do
<pitti> Keybuk: #14191
<Keybuk> ya know
<Keybuk> it's entirely possible that the scripts aren't run
<Keybuk> I can't find that code anymore
<Keybuk> no, it's there
<Keybuk>         if [ -x $HOTPLUG_DIR/$TYPE/$MODULE ] ; then
<Keybuk>             debug_mesg Module setup $MODULE for $DESCRIPTION
<Keybuk>             $HOTPLUG_DIR/$TYPE/$MODULE
<Keybuk> hmm
<Keybuk> wonder if that's broken by grepmap
<pitti> Keybuk: hmm, then for some reason it is not executed
<pitti> Keybuk: or it is executed, but some parameters are not passed
<Keybuk> right
<pitti> (more likely)
<Keybuk> this is a total mess, isn't it :p
<Keybuk> so how it's _supposed_ to work is:
<Keybuk> all devices are created in userspace as a result of a kernel uevent by udev
<Keybuk> so you'd need a udev.rules for these things that sets the permissions and stuff
<Keybuk> there won't be an /etc/hotplug, ./etc/dev.d or /etc/hotplug.d
<lifeless> pitti: pong
<pitti> lifeless: your cf bug seems to have reappeared in bz, I CC'ed you
<pitti> Keybuk: right, in an ideal world, where insane stuff like using /proc for accessing devices would be nonexistent..
<Keybuk> but, as you've pointed out, we don't get the /proc-fu
<lifeless> pitti: heh
<lifeless> pitti: I see it. I'll try with the live cd
<Keybuk> the trouble is, udev is written by the guys trying to make this non-insane world; so they're a bit low on the backward compatibility
<pitti> Keybuk: so I should revert the path change, put the hotplug file back to /etc/hotplug/usb/libgphoto
<sivang> Keybuk: /etc/hotplug/$SUBSYS/$name will be deprecated in some point?
<pitti> Keybuk: and we instead fix that calling again?
<Keybuk> yeah, the gphoto and libsane things should go back to /etc/hotplug/usb with their usermaps
<Keybuk> then we'll debug why that's stopped working
<Keybuk> sivang: it's already deprecated
<pitti> Keybuk: ok, I try this locally here
<Kamion> segfault: sounds like fabbione's memory of how the xserver-xorg keymap guessing stuff works is rather out of date, and predates it knowing about debian-installer/keymap
<Kamion> fabbione: please see my comment in #16386
<Keybuk> in fact, it's totally unsupported upstream and we're just muddling on
<segfault> yeah, that's what i thought
<segfault> it would be nice to have it fixed and working in breezy final
<pitti> Keybuk: odd, it actually works now
<pitti> Keybuk: did you recently fix something that could have caused that?
<Keybuk> nope
<Keybuk> we're still left with the "plugged in already" or "plugged in later" problem
<pitti> Keybuk: I'm 100% sure that it did not work at the time I fixed #14191
<sivang> Keybuk: where to look to know how to do it the "new" way?
<pitti> Keybuk: right, <pitti> Keybuk: so the initial boot problem is that /proc/bus/usb is already there when initramfs runs, but there is no hotplug script there?
<\sh> hmmm...
<Keybuk> right
<pitti> Keybuk: it seems we need some kind of coldplugging at boot
<Keybuk> /etc/hotplug isn't run by udevstart
<\sh> anybody who tried warty -> hoary -> breezy upgrades?
<zyga_> \sh: me
<pitti> Keybuk: ok, so if /etc/hotplug.d isn't any better or worse than /etc/hotplug, I just revert the #14191 change
<zyga_> \sh: but about 3 weeks ago
<\sh> zyga_: good...any problems with non us/uk keyboard settings in gnome? 
<zyga_> \sh: I was doing server upgrades
<Keybuk> pitti: in theory, /etc/hotplug/usb/* is run by /etc/hotplug/input.agent which is run by /etc/hotplug.d/default/default.hotplug
<\sh> zyga_: oh. I did a laptop upgrade just now :)
<Keybuk> gah, USB.agent USB USB USB
<Keybuk> . o O { guess who's been debugging the input subsystem too much? }
<zyga_> \sh: anything broken?
<mvo> hello mjg59 
<\sh> zyga_: yepp...german keyboard layout :)
<Keybuk> so if /etc/hotplug.d/usb is being run, then /etc/hotplug/usb should also be run -- but with the bonus that the latter lets you have a usermap
<\sh> zyga_: reconfigured xserver-xorg didn't help...
<zyga_> \sh: what's broken with xorg?
<mjg59> mvo: Hello
<pitti> Keybuk: hm, I just wonder why hotplug.d worked and hotplug didn't in the past
<Keybuk> pitti: anyone of a zillion bugs in this mess
<pitti> Keybuk: bah - just change every user to id 0 and forget about this crap :-)
<mvo> mjg59: what should usplash do when no display manager is used? it currently just keeps being displayed
<mvo> pitti++
<sladen> mvo: there should probably be an S99 QUIT
<infinity> mvo : It needs an init script that runs at runlevel2/S99 and tells it to exit, I suspect.
<\sh> zyga_: moment real work life
<mjg59> mvo: It'll wait until it times out
<Keybuk> pitti: so I'll find out what the kernel guys are doing about /proc/bus/usb/*
<infinity> mjg59 : Can you add an init script to explicitely QUIT it?
<mjg59> infinity: Sure
<infinity> mjg59 : Seems a reasonable thing to do.
<mvo> mjg59: do you mind if I add such a script?
<Keybuk> for breezy, I think just pitting those scripts back to /etc/hotplug/usb should be fine -- and asking people not to have them turned on while they boot <g>
<mjg59> mvo: Not at all
<pitti> Keybuk: hopefully scanners and cameras get proper /dev entries in the future
<infinity> mvo : Just make the script silent, since "Killing off usplash" will make no sense if usplash isn't running.
<pitti> Keybuk: there's no way to run the scrits at bootup?
<infinity> mvo : And if mjg59 has done his job right, it should never ever fail or exit non-zero anyway. :)
<Keybuk> pitti: actually, ignore me ... by moving them to /etc/hotplug/usb they _should_ be run on boot
<Keybuk> that should fix that too
<Keybuk> because they'll be run by S:S40hotplug
<mvo> infinity: I'll make it silent and I'll make it run /etc/init.d/console-screen.sh (if usplash was runing) to make sure that the fonts are properly set
<pitti> Keybuk: rock, I'll try that
<Keybuk> the device will already exist by that point, so it'll be just a side-effect of re-hotplugging anything on the usb bus
<zyga_> mvo: what kind of fonts does usplash use?
<infinity> mvo : Ahh, nice.  And I suspect it should be in runlevels 2 through 5.
<mvo> infinity: right. I'll make it S98 because it seems that a lot of display-managers run as S99 (wdm, xdm) and that will make sure that the fonts are set before X starts (once it's up, that seting will not work anymore)
<infinity> mvo : You could put it in 0,1,2 at K01 too, for bonus points, so it will kill usplash instantly on a reboot attempt during boot.
<infinity> mvo : Err, 0,1,6
<infinity> mvo : We run our display manager at S13. :)
<hughsie> ogra: is vmware workstation/gsx server a recognised target for ubuntu?
<mvo> infinity: yes, I fixed that ;)
<infinity> mvo : Erm... "fixed"?
<mvo> infinity: just joking, I added a special case to the init script for usplash. ugly but ...
<infinity> mvo : We run it early on purpose, to provide the illusion of a faster boot-to-login" time.
<mvo> I haven't found a better way yet
<sladen> hughsie: it probably should be;  that's what half the magazine reviewers are going to be using
<Keybuk> pitti: so with your camera, you get insert notification?
<ogra> hughsie, i think so, but i have no clue about vmware probs... didnt use it yet
<hughsie> ogra: it's not working :-(
<pitti> Keybuk: you mean from hotplug? yes
<infinity> mvo : I'm not sure we want to blink through the VTs between usplash and *dm, though..
<infinity> mvo : Right now, we have a very smooth transition from usplash to gdm.
<ogra> hughsie, i know about some probs with the vmware scsi drivers
<Keybuk> pitti: odd, that means there at least is some kind of uevent for it
<ogra> hughsie, try to switch it to ide emu...
<hughsie> ogra: that could be right, i installed on a virtual scsi drive
<infinity> mvo : If you kill usplash, run console-support.sh, then wait for a *dm script to run, we'll see the console for a little bit.  (maybe a long while, if they have lots of S99 scripts)
<pitti> Keybuk: kernel: [19333.611720]  usb 3-5.1: new full speed USB device using ehci_hcd and address 10
<pitti>  - that's the only one
<hughsie> ogra: i'll try with ide
<hughsie> might be worth mentioning in the reease notes or somethign
<mvo> infinity: it isn't noticable on my machine with gdm, but it's a reasonable fast system. the problem is that the console-fonts must be set at some point (or otherwise a lot of people like greek, chinese etc will hate us)
<pitti> Keybuk: in the future, the kernel should create sysfs nodes for these devices, so that udev can handle them
<infinity> mvo : I take it console-screen.sh just doesn't work at all when usplash has the console?
<mvo> infinity: the S98usplash_quit (or whatever it is called) will only be for a) console-users b) people using non-standard display managers
<mvo> infinity: the font setting bit fails, yes
<Keybuk> pitti: could you download http://people.ubuntu.com/~scott/udev_log_event -- put it somewhere and make it executable, then put the full path of that in /proc/sys/kernel/hotplug
<Keybuk> pitti: then try plugging your camera in
<infinity> mvo : Yeah, I guess it's a reasonable compromise then.
<infinity> mvo : And S98usplash seems sane enough on its own.  I hate init scripts that don't match their package names. :)
<mvo> infinity: ok, sounds sensible :)
<infinity> mvo : But, yeah, don't forget to toss it in 0,1,6/K01usplash as well, so a premature reboot kills usplash.
<mvo> infinity: will do, thanks for your suggestions
<pitti> Keybuk: can I /msg you /tmp/udev.log?
<Keybuk> pitti: please
<hughsie> ogra: you def. need a note about vmware and scsi
<ogra> rather a fix for it ;)
<hughsie> ogra: is it a kernel thing or a vmware thing?
<ogra> no idea... but there should be a bug open about it...
<hughsie> ogra: okay, i'll have a search
<pitti> [hoary]  0 martin@donald:/etc/hotplug/usb$ l
<pitti> total 136
<pitti> -rwxr-xr-x  1 root root   220 2005-01-05 00:08 libgphoto2
<pitti> -rw-r--r--  1 root root 78052 2005-09-27 12:41 libgphoto2.usermap
<pitti> -rw-r--r--  1 root root 48961 2005-02-01 09:42 libsane.usermap
<pitti> -rwxr-xr-x  1 root root   885 2005-02-01 09:42 libusbscanner
<pitti> erm, sorry
<pitti> wrong window
<pitti> Keybuk: ^ that was hoary, so we could revert to this scheme in breezy
<Keybuk> yup
<Keybuk> make them look like that now
<Keybuk> and I'll fix any bugs that stops that working
<Keybuk> because we know that worked, and right now I don't want to consider playing silly buggers and trying to implement support for usb devicefs
<pitti> Keybuk: yep
<Keybuk> those are supposed to be run by /etc/hotplug/usb.agent
<Keybuk> it'll call "load_drivers usb /etc/hotplug/usb/libgphoto2.usermap 'Martin Pitt's Camera'"
<Keybuk> where load_drivers is in /etc/hotplug/hotplug.functions
<janimo> sivang, I sent you the mail with the lpi changes
<sivang> janimo: k, thanks :) let's take a look 
<Keybuk> the first field of *.usermap should be the script name to be run (and module to be loaded, if any)
<sivang> Keybuk: if it doesn't find a modules, it will look for a scripts named after the subsystem right?
<Keybuk> right
<sivang> Keybuk: and execute it
<sivang> Keybuk: and that even without listing it in *.usermap
<Keybuk> if it's not listed in *.usermap, then it won't load <g>
<Keybuk> usermap maps product/vendor/class/etc. to scripts
<Keybuk> or modules
<pitti> Keybuk: hah, I'll just convert /etc/sane.d/hotplug/libsane.db to a proper hotplug map :-)
<Keybuk> maps of all kinds are going away for dapper \o/
<Keybuk> including grepmap
<Keybuk> which, I have to say, has been the easiest piece of software to support that I've ever written
<Keybuk> because no bugs have ever been filed agains tit
<Keybuk> I must've been having a good day when I wrote that
<sivang> Keybuk: I added usblp script, didn't add it to *.usermap, it still fire up whenever I plug in a usb printer
<Keybuk> sivang: sure, because usblp is a module that appears in modules.usbmap
<sivang> Keybuk: oh :)
<sivang> Keybuk: <sucker> DOh! </sucker> :)
<segfault> when will the blue and purple strings be merged to the packages?
<Kamion> segfault: they're merged automatically into language packs periodically
<segfault> and then they're changed to green?
<Kamion> don't know about that; you'd have to ask #launchpad
<Kamion> also, installer translations are only merged when somebody tells me I need to do so
<segfault> humm
<seb128> Kamion: thanks for the french translation notes/corrections. BTW did you figure why the "Resize ...." string is not listed by the .po ?
<segfault> i dunno if i already talked with you, but in pt_BR there are untranslated strings in the installer
<segfault> that resize stuff seb128 pointed, and that progress bar after the reboot
<zyga> segfault: hey, did you have a chance to look at my i18n scripts?
<Kamion> seb128: not yet, no :(
<Kamion> segfault: I updated some recently, but there are untranslated strings in nearly every language so that doesn't surprise me
<seb128> Kamion: oh, and what segfault pointed too, the progress bar of the second stage
<Kamion> segfault: I'm happy to take updates
<Kamion> seb128,segfault: that progress bar is mostly apt
<Kamion> look there
<seb128> mvo: do you know why "apt-pkg/deb/dpkgpm.cc:   {"half-configured", _("Configuring %s") }," is not listed by the po files?
<segfault> i can't find the apt for translation in rosetta
<seb128> mvo: apt doesn't use POTFILES files?
<zyga> segfault: rosetta might be broken and still not display packages without translation
<zyga> segfault: without any translation in the given language
<segfault> zyga: i've looked, but didn't test it yet
<zyga> segfault: nag people in #launchpad to fix it or just pull the source and play with the .po file yourself
<segfault> heh
<Kamion> segfault: I see partman-auto (the resize string) has updates in Rosetta, so I'll grab those
<zyga> pitti: hi
<pitti> Hi zyga 
<segfault> kamion: lemme see
<zyga> pitti: how can one get all the .pot files you told me about?
<zyga> pitti: those that get generated now
<pitti> zyga: rosetta tarballs have them now
<Kamion> segfault: it's up-to-date for pt_BR
<zyga> pitti: hmm
<zyga> pitti: okay so I can pull the .pot from any package, right?
<pitti> zyga: moment, please
<segfault> kamion: yeah, it's that one
<zyga> pitti: sure, this is very low priority
<ivoks> Kamion: ping
<segfault> kamion: can you merge it?
<pitti> zyga: http://people.ubuntu.com/~pitti/langpacks/rosetta-breezy-2005-09-23.tar.gz
<pitti> zyga: this is still incomplete and also has all po files, but it is a start
<pitti> zyga: the "templates" directory has the POT files
<ivoks> since we use ALSA, with dmix, shouldn't libsdl1.2debian depend on libsdl1.2debian-alsa?
<pitti> right, it should
<pitti> something we forgot to change
<ivoks> that would kill lots of bugs in malone :)
<zyga> pitti: thanks :-)
<aschildbach> hi pitti, can you hear me?
<pitti> aschildbach: Hi Andreas, yes
<aschildbach> ah cool
<aschildbach> i'm the guy from #14495 (-:
<Kamion> segfault: 14:06 < Kamion> segfault: I see partman-auto (the resize string) has updates in Rosetta, so I'll grab those
<Kamion> segfault: (I already said I would - doing it now)
<ivoks> pitti: will you fix libsdl1.2 then?
<pitti> aschildbach: do you get my /msg?
<segfault> hehe, sorry, didn't saw it
<pitti> ivoks: please file a bug about it
<ivoks> ok
<pitti> ivoks: ENOTIME at the moment, sorry
<mjg59> Kamion: That OQO issue is very odd. Would it be possible to take a look at one at some stage?
<Kamion> mjg59: I'm afraid I don't actually have the hardware any more
<mjg59> Ah
<mjg59> Can you remember if it had a fan?
<Kamion> I know others had the issue, since I found the workaround via google
<Kamion> it had something which went WHIRRRRRRRRRRRRRRRRR very loudly
<Kamion> I'm not sure if it was the fan or the disk or what though :-)
<Kamion> probably the fan
<mjg59> And that would switch on even if it didn't have processor loaded?
<Kamion> processor+thermal meant it was loud and hot
<Kamion> loading neither meant it was quiet (but I think still whirring gently, IIRC), and cool enough to hold
<mjg59> The worry is that it wouldn't cool properly under load without it
<Kamion> I suspect it might well be more hopelessly maladjusted defaults, than that it actually *needs* to have those two modules unloaded
<Kamion> but without the hardware any more, it's tricky to say ...
<Kamion> you could ask the OpenAdvantage guys (Jono Bacon et al); I got it on loan from them
<pitti> aschildbach: did you get my private message?
<Riddell> Kamion: the contents of the kubuntu live CD don't seem to have been updated for the last few days
<Kamion> Riddell: only the last day
<Kamion>   linux-386: Depends: linux-restricted-modules-386 but it is not going to be installed
<segfault> will gnome-app-install be fully translated in breezy preview?
<Kamion> I'm going to assume that's transient ...
<seb128> where is mvo when you need him :)
<sivang> seb128: got my email?
<segfault> it's a critical app, since it stays in the applications menu.
<bob2> segfault: preview was n weeks ago
<segfault> bob2: i mean, the preview one that'll be released one week before breezy final 
<janimo> sivang, what do you think of the change?
<Riddell> Kamion: it seems to be longer than that, there's file that havn't been updated on the live CD that have been on the install CD
<Riddell> from the 24th at least
<seb128> janimo: about what?
<seb128> sivang: no, when did you send it?
<sivang> seb128: I forwarded you en email from janimo to me, it has his patch for dropping libgnome depend
<sivang> seb128: 30 minutes ago I think , I'll resend to @canonical.com? (i sent to ubuntu.com)
<seb128> please guys, the right place for patches is bugzilla
<janimo> seb128, a change to urls.py to call x-www-browser if there's no gnome open
<janimo> ok btw is there a nicer way of seeing if gnome-open exists than os.path.exists('/usr/bin/gnome-open')
<janimo> I did not know how to do it w/o hardcoding the path
<sivang> janimo: you can check if the package which installs it is on the system
<segfault> kamion: thanks for hunting down that keyboard bug. :)
<sivang> janimo: that can be achived through python-apt 
<sivang> janimo: or a simple call to dpkg --get-selection and grep for the package
<janimo> doesn't that complicate the code a lot more?
<seb128> janimo: janimo, that's fine this way, thanks
<janimo> it's not like gnome-open will be installed elsewhere
<janimo> seb128, ok
<janimo> seb128, so I'll file a bug with the diffs I made?(no debdiff since I did not know what the next versionname should be)
<seb128> thanks!
<sivang> janimo: cool :)
<carstenh> jbailey: ping
<jbailey> carstenh: pong
<Kamion> segfault: the term is "release candidate"
<segfault> yeah, sorry
<mvo> seb128: do you have your own gnome-app-install baz archive?
<seb128> mvo: no, why ?
<seb128> mvo: have you read my apt question ? :)
<aschildbach> pitti: have you read my answers in our private channel?
<seb128> mvo: where are listed apt files to translated? There is no POTFILES and "apt-pkg/deb/dpkgpm.cc" is not listed by the pos
<pitti> aschildbach: no, seems that you are not a registered user and I can't hear you
<aschildbach> registered user? irc seems to have changed since 10 years...
<pitti> aschildbach: /join #pmount, please
<jbailey> seb128: Hi! =)
<mvo> seb128: the baz archive to have the patches in a common place. would you mind to CC them to me so that I can put them into my baz archive?
<Kamion> seb128: Rosetta definitely has those partman-auto strings; if you want to translate it there and ping me, I'll update them
<jbailey> seb128: With the "About Ubuntu" I uploaded last night, when I use yelp to get to it, I correctly get " propos d'Ubuntu", but if I go to Sysem,  propos, I get the English "About Ubuntu".  Do you know hohat menu item gets there?
<mvo> seb128: about the POTFILES in apt, that is part of the general makefile in po/ :/
<seb128> Kamion: thanks
<seb128> mvo: I don't have any patch for gnome-app-install ... I don't hack on it ... 
<seb128> mvo: should I?
<mvo> seb128: sorry, I meant launchpad-integration
* mvo should get some coffee or something
<seb128> oh
<seb128> mvo: sure, I'll mirror my baz archive for it on people.ubuntu.com a bit latter
<mvo> seb128: thanks
<seb128> jbailey: the menu entry does "yelp ghelp:about-ubuntu"
<jbailey> seb128: Thanks, I'll fgure out how to localise that.
<jbailey> Fine, love me and leave me, see if I care. ;)
<bddebian> Morning
<seb128> hi bddebian
<seb128> jbailey: what package has the about ubuntu?
<bddebian> Hello seb128
<jbailey> seb128: ubuntu-docs
<seb128> jbailey: 5.10-1?
<seb128> jbailey: it only has HTML files here
<jbailey> -2
<jbailey> Oh, hey
<jbailey> Sujet: ubuntu-docs_5.10-2_powerpc.changes REJECTED
<seb128> $ apt-cache madison ubuntu-docs
<seb128> ubuntu-docs |     5.10-1 | http://fr.archive.ubuntu.com breezy/main Packages
<seb128> ubuntu-docs |     5.10-1 | http://fr.archive.ubuntu.com breezy/main Sources
<jbailey> Rejected: binary uploads are not allowed - please only upload source.
<jbailey> ROAR
<seb128> right
<jbailey> I HATE OUR UPLOAD SYSTEM SOMETIMES
<jbailey> But anyhow.
<seb128> I'll have a look when the package is available
<seb128> mvo: about apt bug, can you fix it?
<mvo> seb128: the problem is that the strings in dpkgpm.cc are missing?
<Kamion> segfault: merged for next partman-auto upload
<seb128> mvo: yep, not listed by the po
<seb128> mvo: which makes that the second phase of the installer is not translated
<segfault> kamion: thanks. do you know anything about gnome-app-install?
<mvo> seb128: yes, I'll reupload a version with correct po/pots 
<seb128> mvo: and that sucks to have "Configuring: ...." during a french install :)
<Kamion> segfault: no, sorry, that's mvo's 
<mvo> segfault: I do
<mvo> seb128: sure :)
<seb128> mvo: what do you change for that?
<segfault> mvo: will it be fully translated in release candidate?
<seb128> carlos: rosetta hates me :'
<seb128> :(
<mvo> segfault: as far as possible. the long description of the applications is unfortunately not translatable. but the rest, yes
<mvo> segfault: assuming that there are enough people working on the translation of course
<carlos> seb128, ?
<seb128> carlos: when clicking on "french" from the 5.10 languages list I got "a system occured" 2 times
<segfault> mvo: yeah, but i mean that it is acctually translated to pt_BR in rosetta, but still not appeared in the binary package. Will it come with the new version of the language-pack?
<seb128> carlos: seems to work now ...
<mvo> segfault: yes, that should be only a problem of a not-yet-up-to-date langpack
<jbailey> seb128: Uploaded, Dunno if it'll make this run or the :30ish one.
<seb128> jbailey: k
<seb128> stripping po files from packages suck
<seb128> that's only confusing for users
<seb128> and that piss translators
<jbailey> Why does it piss of translators?
<jbailey> Don't we use that to seed rosetta?
<seb128> jbailey: because we package GNOME 2.12.n, people update and start wondering "what do I get english strings here, what is not translated upstream, where should I fill bugs", etc
<seb128> jbailey: we usually have days of lag between new versions and language-pack update which make really hard for translators to figure what strings are laggy due to packs or not translated
<elmo> pitti: ?
<seb128> jbailey: not speaking about "new software has changed his translation domain because it's versionned and now I've a 100% english app"
<elmo> dholbach: ?
<Treenaks> seb128: people do that?!
<Amaranth> versioned translation domains are stupid
<aschildbach> pitti: schau nochmal in #pmount
<seb128> Amaranth: not especially, if you design the software to have 2 versions installed together the translations should not conflict
<Amaranth> hmm
<Amaranth> ok, i guess i can see the point there
<pitti> Hi elmo 
<Amaranth> let me say that again: for most apps, versioned translation domains are stupid ;)
<seb128> yeah
<elmo> pitti: l-s-{bs,lt} are uninstallable - are you aware?
<seb128> Amaranth: speaking about translation ... smeg? :)
<pitti> elmo: no, I wasn't; will check, thanks for the hint
<Amaranth> seb128: err... ;)
<seb128> Amaranth: that's quite a shame ...
<Amaranth> seb128: lack of access to any kind of linux machine makes working on it hard
<seb128> Amaranth: pygtk works under windows :)
<Amaranth> seb128: smeg doesn't :)
<Amaranth> plus honestly i have no idea how to do translations
<Amaranth> i had something from slomo that sort of worked but was clunky, i made it a little better than i lost it
<Amaranth> (HD crash)
<Amaranth> i only just recently found out about intltool, but it wants to use automake
<seb128> look on other pygtk apps
<Amaranth> hehe, they either give up or do odd things like write their own gettext
<seb128> I don't think so
<thesaltydog> Amaranth, I have looked for smeg in rosetta to translate it, but it isn't in there..
<Amaranth> thesaltydog: i know, i don't have any infrastructure setup for translations in 0.7.5
<janimo> kamion, what is the status of the OOM in d-i for machines with 64Meg, is there a bug filed on it?
<Amaranth> thesaltydog: is/was an 0.8 feature, which if college hadn't knocked me offline (didn't think it would be this bad) would have been done by now
<seb128> Amaranth: 
<seb128> import gettext
<seb128> _ = gettext.gettext
<thesaltydog> Amaranth, I see.. 
<seb128> Amaranth: that's what gnome-app-install do
<Amaranth> seb128: i know that part
<Amaranth> seb128: but none of this matters anyway because i have no way of testing anything i do
<chmj> dholbach: ping 
<thesaltydog> Amaranth, and put each translatable string this way: _("string")
<Amaranth> unless someone in the US could send me colony 5 and vmware trial CDs by snail mail ;)
<mvo> Amaranth: better look at language-selector than gnome-app-install if you look for example code
<Amaranth> thesaltydog: i know
<thesaltydog> Amaranth, ok. sorry.
<Kamion> janimo: #6136 is the general problem, and in any case infinity is already working on a large chunk of it
<bddebian> elmo: Did you get my mail about morgueing gpac?
<seb128> Kamion: could you change the french translation for "Erase entire disk and use LVM: ${DEVICE}" to "Effacer l'intgralit du disque et utiliser LVM : ${DEVICE}"? I've updated it on pkgconf-partman-auto-lvm/Rosetta if you prefer to grab it from here
<seb128> Kamion: I've updated the partman-auto fr.po too on Rosetta
<janimo> kamion,#6136?that's a tla/bazaar bug
<janimo> or debian not ubuntu bug?
<Kamion> janimo: sorry, #6316
<chmj> seb128: did gnome-bt get moved to main ?
<seb128> mvo: do you know why language-selector is not listed by rosetta?
<Kamion> seb128: partman-auto-lvm done, will do partman-auto once Rosetta mails me it
<seb128> chmj: pool/main/g/gnome-btdownload/gnome-btdownload_0.0.18-1ubuntu6_all.deb ... but that's not new right?
<seb128> Kamion: thanks
<mvo> seb128: it is available, but not found with a normal search :/
<chmj> seb128: sorry, I meant, gnome-bluetooth 
<seb128> mvo: right, thanks
<mvo> seb128: https://launchpad.net/distros/ubuntu/breezy/+sources/language-selector
<seb128> chmj: that's a question for dholbach, he did the work on it
<seb128> mvo: yeah, I've it now, but it's not listed by the packages list
<seb128> mvo: 444 strings?! WTF
<mvo> seb128: language+countires
<chmj> seb128: thought so, will ask him 
<seb128> mvo: you could have used iso-codes or something for that :/
<mvo> seb128: but that dosn't include translations as well
<seb128> mvo: do you know how to automatically merge translations from an another po having them?
<Kamion> mvo: iso-codes has perfectly good translations for those into practically everything
<Kamion> mvo: the installer uses language/country translations from iso-codes
<seb128> epiphany-browser/totem too
<Kamion> (it merges them automatically into .po files)
<mvo> Kamion: thanks, I'll use them 
<Kamion> dpkg -L iso-codes and look at all the stuff in /usr/share/locale/ - pkgstriptranslations ignores iso-codes for just this reason
<Kamion> cool, thanks
<mvo> does anyone knows why xdm dosn't start when it's installed?
<hunger> mvo: IIRC that is expecting a file where the xserver puts a symlink.
<fabbione> mvo: is it the default login manager?
<hunger> mvo: Check /etc/X11/Xserver/* for symlinks... has been a while since I ran into that problem... and I might mix it up with the startx not working I had a while back.
<ogra> mvo, i tried to look into it befor the screensaver havoc broke over me
<mvo> fabbione: yes, I purged gdm (for testing)
<ogra> mvo, it seems it cant start a session... i could always see the grey pattern and the X before it crashed
<fabbione> mvo: no idea.. it did work here when i repackaged..
<mvo> hunger: no /etc/X11/Xserver :/
<fabbione> mvo: i am not sure if something did change in the meanwhile
<fabbione> mvo: can you strace it please?
<mvo> fabbione: sure
<ogra> fabbione, its badly broken... and it seems the other display managers dont work either, i also tried wdm 
<ogra> must be a more general prob... not dm specific
<hunger> mvo: There is a bug open about this issue... I "solved" it by dpkg --purge xdm ;-)
<mvo> fabbione: should I upload the strace?
<\sh> oha..xdm weirdness ;)
<mvo> hunger: heh :) 
<fabbione> mvo: i might take a look to it, but it was working when i uploaded it.. so it's sort of a MOTU issue by now
<\sh> fabbione: bah ;)
<mvo> hunger: do you know the bugnumber?
<jdub> wow, i was just looking at the fridge
<\sh> and someone should fix evolution asap .. download mail headers via imap, remvoing a search in a folder, evolution refuses to answer anymore..no crash nothing
<jdub> and it tells me that the community council meeting is in 5 hours
<jdub> ;-)
<\sh> jdub: u saw the agenda for today? I think I'll need a "gibberish" translator ;)
* jdub checks
<Seveas> Hi folks, I've made a bugzilla/malone bot, which you can query for bug numbers
<Seveas> shall i keep it here too?
<chmj> how does it work ? 
<Seveas> !bug malone 1
<janimo> should launchpad accounts work for fridge too?
<bddebian> Seveas: Does it work better than the Malone search tool? :-)
<Ubugtu> Malone bug #1: Microsoft has a majority market share Fix req. for: upstream ubuntu, Severity: Critical, Assigned to: Mark Shuttleworth, Status: Accepted http://launchpad.net/malone/bugs/1
<Seveas> bddebian, it has no search yet for malone
<Seveas> only for bugzilla
<bddebian> Seveas: Sorry, I was joking :-)
<bddebian> Search on Malone blows :-)
<\sh> Seveas: can u move it to #ubuntu-bugs please ;)
<Seveas> sure
<Seveas> !join #ubuntu-bugs
<Seveas> there :)
<chmj> ahh, yes, thats more appropriate 
<janimo> jdub, when you  make the xubuntu list can you please register it with gmane as well? thanks
<\sh> thx Seveas :)
<\sh> ok...buying some new gadgets today...linksys router, wifi usb dongle ;) etc. pp.
<jdub> janimo: um, i've never done that before :)
<\sh> eventually dvd usb rom ;)
<\sh> cu later :)
<janimo> jdub, me neither I thought only list owners can do that, but I'll try myself then
<Seveas> jdub, did you get my mail with the Oct. 19 details?
<ogra> janimo, thats your job as list admin
<ogra> i had to do the same for edubuntu-devel
<jdub> janimo: you'll be list admin ;-)
<janimo> ogra, am I a list admin :) ?cool
<jdub> Seveas: yep, will reply now
<ogra> ;)
<Seveas> merci beaucoup!
<jdub> janimo: get my /msg?
<janimo> jdub, just got it
<Seveas> jdub, didn't know the fridge was working already
<Seveas> cool!
<jdub> Seveas: been quiet about it before official launch :)
<Seveas> when's that?
<dholbach> chmj: pong
<dholbach> elmo: ?
<fabbione> Diziet: ping?
<janimo> jdub, thanks :)
<jdub> Seveas: probably ~10 days before launch
<Seveas> ok, then I won't be shouting about it too yet ;)
<tseng> http://www.cafepress.com/ubuntushop.14580457
<tseng> the fridge
<jdub> heh
* jdub will make a shuffle to point to that ;-)
<sivang> jdub: what's the fridge?
<tseng> sivang: ^^
<chmj> dholbach: you do realise that libgnomebt0-dev is in universe right? 
<sivang> tseng: a mascot for wearing? :)
<dholbach> chmj: yeah
<dholbach> chmj: why?
<chmj> dholbach: I see you built noatilus against it
<tseng> yes
<dholbach> chmj: ?
<tseng> sivang: also.. http://perkypants.org/misc/the-fridge.jpg < the fridge
<jdub> sivang: see the top story on fridge.ubuntu.com
<chmj> dholbach: noatilus-sendto is in main 
<dholbach> chmj: thanks for the heads up
<chmj> dholbach: you mean you didn't check ?
<dholbach> chmj: i was quite sure it was in universe
* jdub does the pretty-please-can-we-have-nautilus-sendto-built-with-bluetooth-support dance
<ogra> dholbach, just add it to the supported seed ;)
<dholbach> jdub: i managed to get it working, but i'm not sure that we get the dependencies into main before
<chmj> jdub: gnome-bluetooth needs to be prometed to main first 
<jdub> yeah
<jdub> this is why i beg
<jdub> with a dance
<ogra> i think there was a main inclusion report already, should be easy to get in
<chmj> yes 
<sivang> jdub: "present our work" can I put packages and code there?
<jdub> sivang: not really -> that's what launchpad is for :)
<jdub> when we do cool stuff, we talk about it on the fridge
<hunger> mvo: No and I can't check right now... Only managed to sneak one port through the firewall and I need that for IRC:-)
<hunger> mvo: no as in "No I do not remember the bug number for the xdm problem".
<dholbach> chmj: will revert until we have an agreement over the main inclusion
<mvo> hunger: ok, thanks
<chmj> dholbach: ok, thanks 
<slomo> elmo: would you accept mosml when the parts under the evil licence is a seperate binary and not linked to the gpl stuff?
<fabbione> mvo: you do synaptic right?
<ogra> dholbach, its approved
<fabbione> mvo: does it save logs somewhere?
<ogra> dholbach, it just needs a seed change
<fabbione> (like all the dpkg output)
<slomo> elmo: mjg59 said that the license on itself would be multiverse compatible
<ogra> dholbach, https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<sivang> jdub: you mean, soyuz :)
<ogra> the !-dev lib is already in it seems
<dholbach> ogra: merci beaucoup
<sivang> jdub: who runs the fridge ? :)
<jdub> sivang: me, plus the fridge editors (mainly robitaille and whiprush atm)
<sivang> jdub: way cool :)
<dholbach> chmj: you didn't add MainInclusionReportGnomeBluetooth to UbuntuMainInclusionQueue
<dholbach> chmj: at least it wasnt there
<chmj> dholbach: hmm, I'll add it
<dholbach> chmj: i did so
<chmj> dholbach: thanks 
<dholbach> de rien
<chmj> grrr thunderbird just crashed 
<jdub> Seveas: heh, very realistic POV in your latest sounder post ;)
<janimo> ogra got a minute for PM?
<ogra> sure
<Keybuk> where did pitti go?
<jdub> Seveas: when you have the room / cafe details nailed down for the 19th, could you please update the B3T wiki page?
<ogra> Keybuk, home ...
<Keybuk> bah
<Keybuk> half-timers
<ogra> heh
<fabbione> bella scott!
<Keybuk> gnargh, I hate bugzilla's search interface
<Keybuk> and what's worse, I'm going to have Malone for not having it
<seb128> bugzilla search interface works quite fine
<seb128> better than searching for bugs on sf.net, the Debian BTS, malone, etc
<Keybuk> yeah, I now have a saved search that gives me all the open bugs to which I'm Cc'd or have commented on that aren't either reported by me or assigned to me <g>
<jbailey> Saved searches good.
<jbailey> Far nicer than the flood of email. =)
<Keybuk> yup
<Keybuk> oh well
* Keybuk mails the bug instead with the kernel patch to kill usbfs
<BenC> where do I reassign a bug that has to do with general GUI features and improvements?
<Keybuk> BenC: seb128 :p
<BenC> hehe
<fabbione> hey benC
<BenC> hey
<Keybuk> we should have a "iz-gtk-bug" component
<BenC> I'm going to start with hotplug since it's probably more to do with that than anything
<Keybuk> what's the bug/
<Keybuk> and you're just getting your own back for all the "iz linux bug" traffic I've been sending to you, aren't you
<slomo> elmo: ok, sent you a mail about that with some more informations
<seb128> BenC: reassign it to me, I'll close it as NOTABUG probably :) Bugzilla is not a nice place to list new stuff to make, the wiki is better for that
<Keybuk> what is the gui?
<janimo> seb128, what's your bugzilla address? I left the lpi bug assigned to debzilla 
<jdub> janimo: just type seb128 and it'll disambiguate
<Keybuk> if it's something like "would be nice to get desktop notification of hotplug events" that probably belongs somewhere around hal
<seb128> janimo: what jdub said
<jkrogh> Does anyone know where the network-applet gets its connectionstatus from? 
<BenC> spent most of yesterday going through all the kernel bugs, and only got to about 1/5 of them
<BenC> closed a lot though :)
<Riddell> BenC: 5 more days of that and we'll have a bug free linux
<jdub> Driver sata_promise in latest kernel (2.6.13) don't support PDC40719 chip.
<jdub> Some googling and modification sata_promise.c make it working. PDC20319 
<jdub> driver works almost perfect.
<jdub> 
<jdub> ber.
<BenC> "almost perfect"?
<hughsie> Keybuk: I was thinking of a desktop daemon to do somethink like that
<hughsie> something like "you inserted a USB2 Wireless adapter - it will not work until you install firmware"
<Keybuk> hughsie: something that listened to hal events and popped little icons into the notification tray for a few seconds for new hardware?
<hughsie> Keybuk: not so much for new hardware, that should "just work" - but for the stuff that doesn't work, then it should tell the usetr
<hughsie> when it needs updated userspace, a new kernel, or firmware
<Keybuk> seems reasonable
<hughsie> but i wanted to scope out the problm in my head before i started with a PoC
<hughsie> any other use cases?
<Keybuk> I want something that when it can't find a module matching a device's modalias does a GET http://drivers.ubuntu.com/?modalias=$MODALIAS which can return information about a device
<Keybuk> "This device is supported by Breezy Badger, upgrade?"
<Keybuk> "This device is supposed by third-party software, download?"
<hughsie> Keybuk: it's pretty similar to the work i've been doing on gnome power manager
<Keybuk> "This device is unknown, supply information to us?"
<hughsie> yes, exactly
<hughsie> Keybuk: how to store this information? One big XML datafile
<hughsie> ?
<Keybuk> the modalias for a device is a simple string -- that can be wildcard matched to identify the device
<Keybuk> for each device, you may as well xml up the sysfs entry for it
<hughsie> Keybuk, but it gets more complicated surely?
<Keybuk> what more is there?
<sladen> hughsie: matching PCI IDs?
<hughsie> What hardware needs stuff doing to it before use?
<hughsie> sladen: yes, i'm thinking of using hald as a backend : and in that way it's easy
<Keybuk> this becomes useful for collecting information about hardware we don't know about
<Keybuk> hardware that needs firmware issues a firmware request anyway
<Keybuk> so you see a "I need firmware!" event go past
<sladen> hughsie: hook hotplug aswell so that when asked for firmware it can fail but pop up a ''you need illegal firmware:   [ ]  This is legal.  Really.   [ OK ]  ''
<Keybuk> sladen: s/hotplug/udev/
<hughsie> sladen: we need to be careful about the legal side of things
<hughsie> can one of you guys knock up a wiki page and post this info pls...
<hughsie> i have to be at a meeting in 9 mins.
<hughsie> back in a bit
<pabs3> hmm, is it just me or are these patches broken? http://people.ubuntu.com/~scott/patches/fonttools/
<Keybuk> see topic
<Keybuk> snapshot.debian.net threw its disks a while back
<pabs3> ah
<Keybuk> so sometimes (about 10% of cases now) we can't get the original Debian source package both us and Debian are based on
<pabs3> seems to me the same version is the latest in the debian archive
<pabs3> http://packages.qa.debian.org/f/fonttools.html
<Keybuk> yeah, currently mom doesn't ever look in the debian archive <g>
<Keybuk> it's a bit thick
<pabs3> ah :)
<mvo> ping zyga 
<pabs3> also, I noticed, the patches haven't been updated for xchat, which has had 2 new versions in debian
<pabs3> how often are updates?
<Keybuk> daily
<Keybuk> xchat looks like another busted one
<mdz> jbailey: are you on top of this ubuntu-docs file conflict?
<Keybuk> oh no, maybe it's not
<Keybuk>  * Creating xchat_None.patch (2.4.3-0.2 -> 2.4.4-0ubuntu5)
* ..[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://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Colony 5 released: http://cdimage.ubuntu.com/releases/breezy/colony-5/
<Keybuk> (it only updates when there are ubuntu changes, as it's just a DebianBase->Ubuntu diff)
<Keybuk> we froze a couple of months ago, remember
<pabs3> ah, right
* pabs3 coming from #debian, forgets these things
<pabs3> er -#
<jdub> hey pablof 
<jdub> er
<jdub> hey pabs3 
<pabs3> hello
<sivang> rehi all
<bddebian> wb sivang
<ivoks> jdub: ping
<hughsie> Keybuk: what about adding the support for this session daemon in gnome-power-manager?
<hughsie> it's already got all the libnotify, hal stuff that it needs
<Keybuk> hmm, I dislike having daemons that do too much
<Keybuk> if the legwork to adding that support to a new daemon is a lot -- copy the legwork from g-p-m into a library they both use
<jdub> ivoks: pong
<ivoks> jdub: i'm interested in planet.ubuntu.com
<hughsie> Keybuk: thats the thing, it would only be a small addition
<ivoks> jdub: so, if you could tell me what you need, so my blog would showup on planet
<Keybuk> would it though?  it could get quite a large addition doing all sorts of cute things
<hughsie> it's pros and cons of having a new, seporate daemon
<jdub> ivoks: if you're an ubuntu member, send me your rss feed url
<Keybuk> I think the way things are going with the new session stuff is to have lots of very small daemons
<Keybuk> jdub: correct?
<jdub> well, i hope not
<jdub> but there is the potential for it :)
<Keybuk> or is it one big "do everything" daemon?
<hughsie> Keybuk: i don;t think that would be the plan - i thin kwe need middle ground tho
<jdub> gnome-session will activate other stuff via d-bus
<jdub> D-BUS
<ivoks> jdub: i am (i'm motu) url: http://ivoks.blogspot.com/atom.xml
<hughsie> jdub: does this actually work now?
<Keybuk> jdub: no dude, it's about the D-TRAIN
<jdub> hughsie: mostly i believe, check libgnomeservice in gnome cvs
<hughsie> jdub: okay, i'll give it a go
<jdub> ivoks: is there a full content feed?
<ivoks> jdub: yup, that one in 10 seconds :)
<jkrogh> Where can I find a list of all metapackages? (for kickstart)
<jdub> ivoks: my wife loved zagreb, btw. wants to take me there some time - will have to catch up with you. ;)
<ivoks> jdub: sure!
<spayne> jdub: you know you're lugradio interview?
<ivoks> jdub: when was she in zagreb?
<jdub> hmm, couple of years ago maybe
<jdub> spayne: yeah
<ivoks> nice...
<jdub> hrm. must be about three years ago.
* pabs3 wonders how greebo is
<spayne> jdub: why did you join #lugradio, say "I hate you guys" and leav?
<bddebian> heh
<jdub> spayne: haha
<jdub> spayne: that was after i heard their intro to the interview
<spayne> lol
<Kamion> mdz: can we promote palo to main? hppa-only, but I can't build hppa CDs for lamont without it
<spayne> jdub: explains a lot
<Kamion> well, actually it's built for all architectures for no wonderfully good reason
<Kamion> would have to make sure it doesn't end up Priority: required/important, or else just remove it from the other architectures
<lamont> Kamion/mdz: libgcc2 is very much in the same boat
<lamont> only more so: can't debootstrap without that
<elmo> I thought it was made it arch: any so CDs could be made?
<elmo> that was the excuse given at the time in Debian anyway
<lamont> elmo: it's always been arch-any
<elmo> lamont: no it hasn't
<lamont> er, for a good long time anyway
<elmo> I have a good long memory :P
<Kamion> elmo: debian-cd/tools/boot/*/boot-hppa doesn't appear to run palo
<elmo> Kamion: ok, it may not be valid anymore
<Kamion> the d-i build process might, but that runs on hppa
<Kamion> maybe something mad in boot-floppies needed it
<lamont> d-i build almost certainly does
<Kamion> PALODEB="$($BASEDIR/tools/apt-selection cache show palo | \
<Kamion>         sed -n 's/^Filename: \(.*_hppa.deb\)$/\1/p')"
<Kamion> ar p "${MIRROR}/${PALODEB}" data.tar.gz | tar xz ./usr/share/palo/iplboot
<Kamion> mv usr/share/palo/iplboot $CDROOT/install/iplboot
<Kamion> ^-- what debian-cd does
<mdz> Kamion: won't that cause it to show up eternally in anastacia?
<spayne> jdub: they say waugh like war
<Kamion> mdz: not if seeded as 'palo [hppa] '
<Kamion> (if anastacia pays attention to ports-arch seeds, I forget)
<Kamion> but it's in the exact same boat as silo and elilo
* lamont notes that http://buildd.mmjgroup.com/hppa-hacks is a repositiory of all the deps/build-deps that hppa needs for main to be consistant/usable.  palo/libgcc2 are the only deps, everything else is build-dep for the kernel or toolchain
<Kamion> apart from the arch: any thing
<lamont> if it helps, I have no objection to making palo arch:hppa
<jdub> spayne: that is how it's pronounced. the 'whoa-whoa-whoa' stuff comes from a combination of 'war' the song and 'the twelfth man'
<lamont> at lease in ubuntu
<elmo> Kamion: anastacia currently ignores hppa
<mdz> fabbione: now you have an easy X bugfix to upload with your sparc changes ;-)
<elmo> but looks at ia64 and sparc
<spayne> jdub: in the UK, we say "waugh" wauf
<elmo> if hppa is up-to-date enough, we could change that
<mdz> elmo: hppa is eternally behind
<mbreit> lamont: did you have a look at the scons problem on the buildds?
<lamont> elmo: outside of kde being totally &*%), it's at least as current as breezy-autotest
<mdz> lamont: every time I regen -meta it is missing things
<elmo> ok - well the real solution is to get anastacia telling you when promotions come from a certain arch
<jdub> spayne: perhaps in *england* (especially if trying to psyche out the cricketers). :-)
<elmo> but that's less trivial than I first thought
<lamont> or rather, the breakage that it currently has is trackable to things that are no-longer buildable in breezy main
<spayne> jdub: who won again :)
<fabbione> mdz: might do tomorrow.. i didn't upload since you didn't answer my request this morning...
<mdz> fabbione: I fell asleep
<mdz> I had slept about 6 hours total over 2 days
<fabbione> mdz: + the code has been changed so much since last time i checked, that i am bit reluctant to touch it
<lamont> mdz: libgda2 and libcaca are both FTBFS in current main.
<fabbione> mdz: THAT MUCH?!?
<elmo> lamont: err, they are?
<lamont> and, while present on the other architectures, are not present on hppa.
* lamont double checks
<elmo> I thought infinity fixed libgda2
<fabbione> lamont: no.. they have been fixed
<mdz> lamont: broken post-autotest?
<lamont> ah cool
<elmo> has b-at finished yet?
<elmo> we should do a main only run now and catch any stragglers
* lamont still shows libcaca_0.9-5ubuntu1 as current, and failing (unless it's been fixed in the last hour or 2)(
<lamont> libgda2 is fixed
* lamont kicks a few virtual deps
<lamont> breezy-at has nothing in needs-build
<lamont> sounds like time to kick it again
<elmo> ok, I'll start that now
<lamont> mdz/kamion: I'm also going to kick all the current dep-waits, to clear any outstanding waiting-on-virtual-package issues
* lamont wonders if we made a decision on palo/libgcc2, or if he needs to go do the main-inclusion request wiki page thing.
<elmo> libgcc2 I think counts as obvious
<mvo> seb128: apt with updated po/pots uploaded
<jdub> BenC, mdz: so is this "my hard drive is slower" stuff supported by any useful evidence yet?
<elmo> the anastacia output is all messy again
<sivang> jdub: I'm getting weird overall performance since lastest update, may this be related? (GNOME gui responsds also slowly)
<seb128> mvo: rock, thanks
<mjg59> Is anyone here on a desktop with apm?
<lamont> elmo: I know ubuntu-desktop is unininstallable, I'll track down the offending packages
<mdz> jdub: http://bugzilla.ubuntu.com/show_bug.cgi?id=15571
<jdub> wow, stracing gam_server is intense
<jdub> mdz: ta
<Keybuk> jdub: strace X ... for ultimate strace pleasure
<fabbione> the HD performance thing is crap
<segfault> mvo: are those untranslatable strings fixed in apt?
<sivang> mjg59: could it be the cpu scaling not working ? No matter what I do , CPU speed won't jump up to 1.8 as it used to do
<fabbione> i got much higher performance here with .12 than with .10
<sivang> Keybuk: lol
<mvo> segfault: should be with this upload
<jdub> well, i would be expecting X to be busy most of the time (especially when pushing output of strace!) :-)
<segfault> mvo: they will appear in rosetta after some time?
<mjg59> sivang: I've no idea
<mvo> segfault: yes, the import happens daily AFAIK
<mjg59> sivang: What hardware?
<segfault> mvo: nice, thanks.
<sivang> mhsame old dell laptop inspiron 8200 that you fixed the pakcage for, recall the wrong module loaded that you fixed ?
<mjg59> Yeah
<sivang> so it is it. And it was beautifully working before, bumping CPU speed to 1.8 on load, and resting at 1.2 in low load
<lamont> mdz/elmo: gnome-control-center is d-w libcaca-dev, libcaca is ftbfs.
<lamont> that's the root cause of much of the uninstallability for hppa
* lamont goes to double check that libcaca is ftbfs in breezy-at
<mdz> lamont: is it hppa-specific, or is there a bug open?
<sivang> mjg59: never mind, I got it working. I guess I was not stressing the machine enough
<lamont> libcaca_0.9-5ubuntu1_20050914-0029-i386-failed.gz
<lamont> libcaca_0.9-5ubuntu1_20050914-0240-amd64-failed.gz
<lamont> libcaca_0.9-5ubuntu1_20050914-0501-ia64-failed.gz
<lamont> libcaca_0.9-5ubuntu1_20050914-0928-powerpc-failed.gz
<lamont> looks pretty general
* lamont looks for a bug, or will file one
<bddebian> libcaca still cracks me up
* bddebian has childish sense of humor
<lamont> ENOBUG
<lamont> fixing that
<lamont> gcc  -g -O2 -g -O2 ... -o cacaview -> 
<lamont> /usr/lib/libImlib2.so: undefined reference to `XShmDetach'
<lamont> now to figure out if it's imlib2, or libcaca
<lamont> imlib2-config --libs
<lamont> -L/usr/lib -lImlib2 -lfreetype -lz -ldl -lm
<lamont> thanks imlib2
* lamont thinks he'll give this one to imlib2
<Rotund> Lathiat, you here?
<jdub> mvo: update-notifier is polling a lot
<Keybuk> ubuntu-bugs: 0 unread  \o/
<Keybuk> NOBODY BREAK ANYTHING!
<mvo> jdub: yes, I can fix that (if gaim is reliable nowdays)
<lamont> Keybuk: got a minute?
<Keybuk> lamont: sure
<Keybuk> evo just hung on a futex again, so I have to restart the fucker
<mvo> jdub: it used to be a additonal check to work-around problems in gaim
<jdub> gamin? :)
<mvo> jdub: err .. right :)
<jdub> nm-applet is polling a lot
<Rotund> anyone know if a GNOME configuration frontend for Avahi/Zeroconf is being worked on?
<jdub> though that's probably on /proc or whatever
<dholbach> Rotund: service-discovery-applet is in breezy, if you mean that (avahi)
<Rotund> the other end of it.
<Rotund> The avahi-daemon side
<jdub> elmo: can we drop howl from the archive?
<dholbach> Rotund: i have no idea, the avahi source package has around a million binary packages, one of them might be what you're looking for :)
<dholbach> Rotund: i have no clue about it :)
<Rotund> nope.  there's not one there
<dholbach> elmo: and gnome-user-share
<Rotund> I'm thinking of doing an "autodetect" wizard that will generate the services available
<elmo> jdub: done
<jdub> thanks
<elmo> dholbach: reasoning?
<dholbach> elmo: it depends on libhowl0
* fabbione -> cook dinne
<fabbione> +r
<dholbach> fabbione: bon apptit
<fabbione> dholbach: danke
<dholbach> :)
<kent> dholbach, do you meen to drop gnome-user-share from ubuntu?
<elmo> dholbach: ok, done
<dholbach> elmo: merci beaucoup
<dholbach> kent: yes
<Rotund> it would be great to just plug your computer on the network and have it be like "this, this, this, and this are available on your LAN"
<dholbach> kent: it depends on howl which has licensing problems
<Rotund> like Windows Networking/SAMBA but not shit
<mae> y'know, banshee looks fairly promising for the next ubuntu release if they fix some _very_ annoying bugs.
<kent> dholbach, ok. 
<slomo> mae: they will be fixed... i'm just waiting for a new upstream release which will be there soon
<mae> :)
<mae> and also, playlists don't keep their order, they enforce column ordering.
<mae> It crashed when ripping my cd, and the numbers to the playlists don't get updated properly when dragging songs into it
<kent> aah, banshee is in breezy archives. Nice, i didnt think it was there..
<spayne> who do i need to talk to about the ubuntu logo?
<spayne> i'd like to use it in a T-Shirt
<spayne> i have permission for the Mono, Hula logo
<spayne> and my business
<jdub> spayne: http://www.ubuntu.com/ubuntu/TrademarkPolicy/
<spayne> anyone on IRC i can ask?
<jdub> that's not the correct process :)
<spayne> jdub: i'm emailing now
<lamont> mdz: problem located, rest of fix for old bug being tested now
<spayne> generally, is it better to use LVM which installing breezy?
<bddebian> Anyone know of any issues with _X_SENTINEL ?
<bddebian> from Xfuncproto.h ?
<lamont> waz broken xorg-transition fix
<bddebian> ??
<zyga_> hello :-)
<bddebian> Hello zyga_
<dholbach> bddebian: doesn't including the correct header file fix it?
* zyga_ grabs keyboard from the server
<bddebian> dholbach: Not afaict
<zyga_> :-)
<lamont> mdz: new imlib2 uploaded.  now a short break, and then I'll file a bug and close it. 
<lamont> with a tip of the hat to keybuk (auto*), and jbailey (cdbs) for speeding my walk through the painful mazes
<mdz> lamont: the bug filing is superfluous if you're just going to upload the fix immediately thereafter ;-)
<bddebian> heh
<zyga> who is scott james remnat?
<tseng> zyga: Keybuk 
* ogra points at Keybuk 
<lamont> mdz: wasn't sure if we were tracking old dead bugs or not.
<zyga> a wiki page mapping people from IRC to their real names autogenerated from launchpad 
<tseng> im not sure i enjoy that
<elvirolo> hi all
<elvirolo> i am encountering a critical bug : http://bugzilla.ubuntu.com/show_bug.cgi?id=16066
<mdz> dholbach: talk to me about gnome-bluetooth
<bddebian> Which seb* is Seb Payne?
<mdz> elvirolo: the development team receives automated notification of bugs filed in Bugzilla; there is no need to repeat the report here
<jdub> mdz: thought -> gnome-bluetooth binary needn't be in main, just libgnomebt0{,-dev}
<mdz> jdub: isn't that built from gnome-bluetooth?
<jdub> source, yes
<elvirolo> mdz: yeah i know ... I was just wondering if anyone knew whether is was going to be fixed or not
<mdz> jdub: is it ready for an ubuntu release?
<jdub> 0.5 has had quite a bit of testing in the real world
<jdub> 0.6 dramatically less so
<mdz> elvirolo: of the 16,000 bugs filed before it, about 12,000 have since been fixed, so the odds are in your favour
<jdub> i would support the inclusion of libgnomebt0 specifically for the benefit of nautilus-sendto
<elvirolo> ok...
<jdub> but happy to see gnome-bluetooth binary in universe
<mdz> jdub: and a cvs snapshot from early december probably even less so? ;-)
<jdub> mdz: that's 0.6, you see. much drama. :)
<mdz> jdub: I try to avoid mixing binaries that way wherever possible; it creates awkward support situations
<dholbach> jdub: then you'd be able to send files to bluetooth stuff, but not to receive it (gnome-obex-server)
<mdz> jdub: e.g., if someone wants to fix the package in universe, we actually need to touch main
<mdz> dholbach: is nautilus-sendto useful without the bluetooth functionality?
<dholbach> i'd really love to see it available for the masses, and my tests with my 3 devices have been fine so far, but i'm not sure how good that works in main
<jdub> mdz: it is, but it won't do bluetooth.
<dholbach> mdz: yes, i tested it yesterday, it even found a blackberry device in the flat below mine :-p
<mdz> jdub: sounds like a lack-of-feature more than a bug
<bddebian> dholbach: Hey, fix that bluetooth-gnome pixmap bug on Malone!! ;-P
<jdub> mdz: (ok, then i'd revise -> libgnomebt0 in desktop, gnome-bluetooth in supported)
<mdz> dholbach: so it worked well for you?
<dholbach> all i can say is that the test with my 3 devices has been fine and it's a COOL feature
<jdub> mdz: it is a bug for our bluetooth goal :-)
<mdz> very few of us seem to have bluetooth devices; it's quite difficult for us to support that functionality
<dholbach> but i can't tell how broken it is for the world
<jdub> works fine with three different devices i've tested
<jdub> including the treo 650 (pipka has the same phone as sabdfl)
<mdz> dholbach: has pitti reviewed the report?
<jdub> 0.5 has been very widely tested
<ogra> mdz, nobody has put it on the queue :(
<dholbach> mdz: charles wrote it, but it wasn't linked on InclusionQueue
<jdub> s/tested/used/
<mdz> jdub: isn't that inconvenient, for them to share a phone while living on different continents?
<dholbach> i just linked it there
* mvo giggles
<dholbach> mdz: :)
<jdub> mdz: sabdfl seems to enjoy it.
<mdz> one of these days I will call sabdfl and pipka will answer instead
<dholbach> chmj: how good were your tests with gnome-bluetooth?
<dholbach> so we have at least 3 people who tested it :)
* ogra can test it with ris razor and the dongle he has
<jdub> we'd have to include gnome-bluetooth binary if we wanted gnome-obex-server (which lets you send files to your ubuntu machine)
<ogra> *his
<mdz> if we were to add this to desktop and discover in a few weeks that it causes some weird nautilus crash, I would be unhappy about that
<jdub> but i don't think we should bother with that for now
<jdub> mdz: nautilus-sendto only runs when you context-click and choose "send to..."
<mdz> jdub: oh, it's an external program and not a plugin?
<jdub> so it won't crash nautilus :-)
<jdub> yeah, the bt bit is a plugin for a separate nautilus-sendto binary
<dholbach> mdz: until pitti has reviewed it, i'll do some more testing
<ogra> me too
<ogra> dholbach, can you prepare a sendto binary for amd64 and upload it anywhere 
<mdz> dholbach: this is pretty clearly pre-featurefreeze stuff to me
<dholbach> it's much more mature than gnome-phone-manager (which would be cool for the Bluetooth goal, if it worked more instantly)
<dholbach> ogra: yes
<dholbach> mdz: i'm sorry, as you know, i was a bit busy before featurefreeze
<dholbach> (i know you all were)
<jdub> ah, meanwhile, nautilus-sendto is crashing on startup for me (no bt bits involved)
<ogra> dholbach, thanks, even if it probably wont be accepted, testing is alwys fine i think
<mdz> dholbach: I'm not blaming you; it's simply  quite late to consider it
<dholbach> yeah
<mdz> 16 days to final release
<jdub> mdz: "hey sabdfl, you can send files to your palm now"
* ogra whistles while poking at the screensaver code...
<mdz> jdub: don't you dare
<jdub> ha ha
<mdz> dholbach: this doesn't require any seed changes, right?
<mdz> so if it causes problems, it can be reverted by only touching nautilus-sendto?
<dholbach> mdz: we'd at least need libgnomebt*
<mdz> dholbach: right, but those would be pulled in by a dependency and not seeded
<mdz> i.e., no metapackage transition required
<dholbach> yeah, afaik that'd be it
<jdub> yep
<dholbach> *grmbl*
<lamont> mdz: once I get hppa really caught up (thanks libcaca), I may want to see about one last ubuntu-meta upload to flesh out ubuntu-* packages there
<lamont> mdz: and it sounded like once it's semi-clean, anastasia could look at hppa as well as ia64/sparc, yes?
<mdz> lamont: we'll see how it looks first, but yeah
<ogra> jdub, do you remember if gsf-sharp was also for searching MS Word docs with beagle ? 
<tseng> i dont think so dude
<ogra> hmm
<jdub> yeah, you need gsf
<jdub> but you also need an old version of wv
<ogra> not wv2 ?
<jdub> (gsf handles the ole storage format)
<tseng> bongness
<ogra> we're just discussing malone #1859 in -motu
<tseng> like i said in MOTU, i dont care about any of that MS crap
<jdub> not wv2
<ogra> bah
<tseng> as soon as someone else tests it ill include their patch
<bddebian> Does Debian include wv support in beagle?
<jdub> doubt it
<tseng> doubt it also, but looking
<jdub> libwv1 doesn't exist
<bddebian> I know :-(
<tseng> they dont include wv or gsf
<tseng> and neither do we
<bddebian> SO I'm going to just reject the bug?
<tseng> you can do whatever you like with the bug, given that im not fixing it :P
<jdub> tseng: we have libgsf-cil
<tseng> jdub: we do
<jdub> bddebian: no, it should be fixed
<bddebian> OK
<jdub> either by fixing their wv usage or sorting out wv1's needs
<bddebian> And we know libwv2-dev won't fix?
* jdub thinks fixing their wv usage might be easier :)
<jdub> don't believe so
* jdub goes to ask them straight up
<tseng> im not sure who wrote that code
<mdz> aieee
<mdz> I turn my back for a moment and anastacia output explodes again
<mdz> Riddell: this kde-guidance stuff has a load of new deps which have no main reports
<mdz> Riddell: http://people.ubuntu.com/~mdz/anastacia.txt
* robertj discovers module-assistant and cries
* robertj does a dance
* bddebian just plain cries
<tseng> spreadubuntu.org should have had the original warty artwork along with their slogan
<tseng> the toupe is lacking sex appeal
<elmo> lamont: what's my IA64 system type?
<elmo> I guess "HP-zx1/sx1000 (IA64_HP_ZX1)"?
<lamont> elmo: I think so... what's the machine?>
* ogra -> pizza
<lamont> one of the zx2000's?
<lamont> --> zx1
<elmo> rx1600
<lamont> pretty sure that'd be zx1
<elmo> ok, thanks
<lamont> elmo: double checking and all that, but I expect that's right
<lamont> elmo: confirmed.
<elmo> cool, thanks
* lamont wanders in search of some fast ia64 iron to build his test kernels on.
<\sh> hmmm...
<\sh> anybody has experience if a dlink usb wifi dongle works with the actual linux kernel? *surprise*
<lamont> elmo: I want a gnupg patch so I can say 'default key is XX if it exists, otherwise use YY'.  kthxbye
<\sh> Bus 004 Device 004: ID 2001:3c00 D-Link Corp. [hex] 
<\sh> aa
<Seveas> lamont, that should be easy to fix in a wrapper script ;)
<jbailey> mdz: Hey just trying to track down where that ubuntu-faqguide came from.  I don't have it on any of my systems here (new installs and upgrades from Hoary), and people in the #u-docs channel don't seem to know it either.
* jdub had it
<jbailey> mdz: If don't know, no worries.  I'll just conflict/replaces it to clear the problem for now.
<ogra> its a rewrite of ubuntuguide afaik....
<ogra> jsgotangco spoke about it recently
<jbailey> Right, and I include it in ubuntu-docs.
<mdz> ubuntu-docs used to build ubuntu-faqguide, iirc
<jbailey> But Matt filed 16465 about it conflcting with an ubuntu-faqguide package.
<ogra> wasnt that called quickguide before ? 
<jbailey> mdz: Do you know in what release timeframe I should look?
<zyga> hey did anyone read about the new smalish laptop-palmtop-hybrid on ./?
* bddebian doesn't read ./
<zyga> the thing is: the company also semi-supports ubuntu on this thing: it's not officially supported but they have gone to great lenghts to get everything working
<zyga> ftp://ftp.oqo.com/unsupported/linux/OQOLinux.html
<zyga> check this out
<jbailey> OQO...
* jbailey thinks.
<zyga> wifi, sleep, touchscreen everything
<jbailey> I think that's the device Kamion filed a bug on.
<zyga> jbailey: oh, in bugzilla?
<Keybuk> zyga: were you looking for me?
<jdub> yes, openadvantage provided some hardware to test with
<jbailey> zyga: http://bugzilla.ubuntu.com/show_bug.cgi?id=9092
<mdz> jbailey: I don't know that it was ever in a release
<mdz> jbailey: just add a conflicts/replaces please
<zyga> Keybuk: not really, I just wanted to associate the person assigned to that bug to anyone here
<jbailey> mdz: will do, thanks. =)
<Keybuk> zyga: which bug?
<Keybuk> #16433 ?
<zyga> Keybuk: hdparm 
<zyga> yes
<Keybuk> yeah I kinda more mean "why hdparm is trying to do things to a cloop filesystem"
<zyga> Keybuk: what I want to know is why the hell does it touch /dev/hdc when I mount cloop 
<zyga> (that has nothing to do with it)
<Keybuk> indeed
<jdong> \sh: which dongle?
<jdong> \sh: DWL-G122's all work with Ubuntu to some degree with OSS drivers
<zyga> Keybuk: are you 100% sure it's not udev event problem? I still think that hdparm is buggy maybe but it shouldn't get called on /dev/hdc
<\sh> jdong: which driver must be loaded? I can see the dongle in lsusb but no other recognition...so no wifi device is showing up
<zyga> jbailey: call the marketing people to convince OQO to get fully supported device and special kernels in universe
<Keybuk> zyga: reasonably sure, if there were a uevent problem it would show up in all sorts of other ways too
<zyga> Keybuk: does that mean that udev will re-configure all block devices on any mount?
<rebort> can someone lease take a look at ug 16479
<Keybuk> zyga: no, I think what's happening is udev is handling the /dev/loop0 event and the hdparm handler in /etc/dev.d/block is getting things wrong and running hdparm on everything
<rebort> my b, f and p keys do not work (the keyoard shortcuts dialog sees them as
<rebort> X86AudioNext, X86Audiorev and X86Audiolay, resectively)
<zyga> Keybuk: /dev/cloop0 that is
<Keybuk> unless you have any evidence that udev is getting events for each thing?
<tseng> BenM: yo
<BenM> hey guys, i've been trying to customize a pxeboot setup
<zyga> Keybuk: what calls those scripts, they have some environment pre-defined as it seems
<BenM> hey ts
<BenM> i want to install cmu-desktop, rather than ubuntu desktop
<Keybuk> zyga: the kernel
<BenM> but i can't figure out how to get that in the preseed
<zyga> Keybuk: hmm
<jbailey> zyga: I don't have one.  It's just that I came across the bug last  night when I was trolling for initrd/initramfs bugs that hadn't been assigned to me.
<BenM> http://omega.res.cmu.edu/~benm/ubuntu/preseed
<BenM> is that i have so far
<Keybuk> zyga: can you download http://people.ubuntu.com/~scott/udev_log_event -- make it executable then write the full path of it to /proc/sys/kernel/hotplug
<zyga> Keybuk: sure
<BenM> base-config  package-selection string ~tubuntu-standard|~tubuntu-desktop|~tcmu-desktop was my first attempt
<Keybuk> ie sudo sh -c "echo $(pwd)/udev_log_event > /proc/sys/kernel/hotplug"
<BenM> but did not work at all
<dholbach> erm... does anybody know why the test-rebuild got restarted and there are no logs left?
<zyga> Keybuk: done
<zyga> Keybuk: I'll mount the cloop now, one moment - my laptop might die at this
<Keybuk> zyga: ok, now (with the bad bits of your hdparm script commented out so your machine doesn't go bang) can you mount your filesystem
<zyga> Keybuk: I reverted that patch
<zyga> Keybuk: I'll apply it again if that's not relevant 
<Keybuk> yeah, just want to see what udev is doing
<zyga> Keybuk: okay http://www.suxx.pl/udev.log
<zyga> Keybuk: no /dev/hdc that's for sure
<Keybuk> hmm, a whole bunch of loops though
<Keybuk> maybe that's just the module preparing them
<Keybuk> ah
<zyga> Keybuk: note that this is for modprobe cloop && mount && umount && rmmod cloop
<Keybuk> yeah, that'll be the module loading causing the /dev/loopN
<Keybuk> ok, that's what I'd expect to see
<zyga> nice, it shows my nfs mounted webserver :)
<Keybuk> could you attach that log file to the bug with a comment like "what udev is doing"
<zyga> sure
<Keybuk> then edit (as root) /etc/dev.d/block/hdparm.dev
<Keybuk> and at the top (just after the #!/bin/sh) put
<Keybuk> exec 2>/tmp/hdparm.log
<Keybuk> set -x
<Keybuk> echo "$@" 1>&2
<Keybuk> env 1>&2
<Keybuk> (end)
<zyga> Keybuk: one moment, log addeed to bugzilla
<mdz> is anyone with debugging skills able to reproduce this hard drive performance issue? (http://bugzilla.ubuntu.com/show_bug.cgi?id=15571)
<zyga> Keybuk: done, checking again
<rebort> has anyone heard o anyone else with the keyoard issue (#16479)
<zyga> Keybuk: http://www.suxx.pl/hdparm.log
<Keybuk> attach that one to the bug too
<zyga> k
<Keybuk> actually, wait
<Keybuk> you need to boot without "nohdparm" :p
<Keybuk> I actually want to see what it's doing
<zyga> Keybuk: done
<zyga> Keybuk: I did
<Keybuk> + grep -w -q nohdparm /proc/cmdline
<zyga> Keybuk: I was at work and I power cycled my laptop :)
<Keybuk> hmm
<Keybuk> oh, sorry
<zyga> Keybuk: empty line, $? == 1
<Keybuk> can you change that exec 2>/tmp/hdparm.log  line to exec 2>>/tmp/hdparm.log
<zyga> Keybuk: sure
<zyga> done
<Keybuk> (this is totally poor man's debugging, but hey)
* zyga enjoys it :)
<chmj> OTE:	the daemon does not 'daemonize' actually, this makes debug output available on the console
<Keybuk> got the updated file?
<zyga> Keybuk: not yet, one moment
<zyga> Keybuk: now it's longish, check the URL above
<Keybuk> no /dev/hdc in sight
<Keybuk> definitely hdparm playing silly buggers, not udev
<zyga> Keybuk: but wait
<zyga> Keybuk: check the log I attached to the bugzilla
<Keybuk> which one?
<zyga> Keybuk: the first one, hdparm *is* called with -q /dev/hdc
<Keybuk> yup
<zyga> so that's not hdparm on it's own
<Keybuk> I think this hdparm dev.d script is calling hdparm like that
<zyga> $DISK is broken in that script
<Keybuk> it parses hdparm.conf in shell, and I think it just runs hdparm for each thing it finds in that conf file
<Keybuk> yeah
<zyga> for some reason it gets /dev/hdc from my hdparm.conf
* zyga didn't really read the whole script ;-)
<zyga> Keybuk: it seems to be doing that though
<zyga> Keybuk: really dumb, lots of loop stuff being cycled makes this thing go wild
<Keybuk> basically it parses hdparm.conf and does whatever it says
<Keybuk> every single time
<zyga> Keybuk: default hdparm does nothing
<Keybuk> it looks like someone just grabbed the boot-time init script and tried to write it
<Keybuk> of course, why hdparm'ing your existing drive with the same settings crashes your machine is another matter
<zyga> Keybuk: it does not crash immediatly
<zyga> Keybuk: it simply eats the whole cpu in some kernel time... mumbo-jumbo
<Keybuk> ...I wonder whether it's doing multiple hdparm at the same time on the same machine
<Keybuk> on the same drive
<zyga> Keybuk: none of the hdparm processes want to die
<Keybuk> that'd be a bit freaky
<zyga> Keybuk: it does basically
<Keybuk> sweeeet
<zyga> Keybuk: for each loop event it spawns a hdparm -whateve /dev/hda 
<Keybuk> yup
<zyga> and hdparm -whatever /dev/hdc
<zyga> so that's 40 hdparm's at the same time, one after another
<Keybuk> so when you modprobe loop, the 8 block events that get generated all cause that command to be run
<Keybuk> all at the same time
<Keybuk> all on the same drive
<zyga> okay 8*4 not 10
<zyga> yes
<Keybuk> cute
<zyga> could someone patch that mess into oblivion?
<Keybuk> yeah
<zyga> I'd love to help but I'm not really sure what that thing is supposed to do?
<Keybuk> me neither
<Keybuk> like I say, I think someone copied the init script
<Keybuk> hdparm upstream doesn't have a conffile
<Keybuk> and that's trying to make one using shell
<Riddell> mdz: the dependencies are pyqt/pykde which has been in main before, but I can write main reports if that's helpful
<sivang> Keybuk: do you know anything about cupsd ?
<Treenaks> Keybuk: sound scary
<Treenaks> Keybuk: btw, I supplied the PNP ID mess for the Thinkpad 380ED
<zyga> Keybuk: are those udev scripts required to use bash? 
<zyga> Keybuk: I have trivial but working and compleate hdparm.conf parser in a dozen python lines
<Keybuk> hmm, ok, so the Debian package has changed quite a bit
<zyga> s/compleate/complete/
<Keybuk> zyga: I wouldn't want to start python up in a udev event
<Keybuk> that WOULD kill your machine :p
<zyga> Keybuk: hmm, python is faster on startup than bash IMHO, and it is really faster when someone tries to write a parser in it ;-)
* Keybuk would write it in awk :p  but then I'm old-skool
<Keybuk> and dude, Python is _huge_
<Keybuk> and almost certainly not already in memory at that point
<zyga> Keybuk: true
<zyga> Keybuk: shell parser is still insane IMHO
<Keybuk> well, yes, that script is insane
<Keybuk> the "new" version in Debian doesn't look much better *sigh*
<zyga> Keybuk: still - better a bloated python + gtk gui and progress bar that *works* than a sleek, low-footpring while true; updatedb; done in bash
<zyga> s/footpring/footprint/
<Keybuk> right
<Keybuk> I can see what this is trying to do
<Keybuk> and it's just getting it very highly wrong
<zyga> Keybuk: I guess it tries to know what hdparm stuff to call associated with the event
<zyga> Keybuk: but instead it just calls everything, right?
<Keybuk> zyga: could you try replacing it with http://people.ubuntu.com/~scott/hdparm.dev
<Keybuk> remove /tmp/hdparm.log
<Keybuk> and try again
<sivang> does anybody know if pitti should come back ?
<zyga> Keybuk: sure
<zyga> Keybuk: I've noticed - you have leaved hdparm stuff around, are you sure?
<ogra> sivang, i doubt it
<Keybuk> you can comment out the actual call if you like
<Keybuk> stick an "echo woo" in there or something
<Kamion> BenM: drop the ~t before cmu-desktop; ~t installs a task (based on Task: headers in the Packages file) rather than a metapackage
<zyga> Keybuk: an echo $REST_OF_THAT_LINE would be more useful
<Keybuk> true
<Keybuk> and no doubt somebody will name their new toy version control system "woo" and use up yet another metasyntactic variable
* ogra cries... still more gnome-screenaver bugs in my inbox :(
<Keybuk> ogra: serves you right
<ogra> :-'/
<Keybuk> mdz: I've got testing that on my todo list, as I think I've noticed it too
<Keybuk> mdz: but I'm doing something with baz right now, so I don't think it'd be a fair test <g>
<sivang> ogra: ok, was just wondering. I needed him for some cupsd stuff
<zyga> Keybuk: okay, it looks better this time
<Keybuk> zyga: got the log?
<zyga> www.suxx.pl/hdparm.log.1
<zyga> .0 if from previous iterationg
<zyga> s/g$//
<Keybuk> ok, other than my inability to write shell, that looks fixed
<mpt> ogra: Why aren't you just ignoring them until after Breezy?
<ogra> mpt, i do... 
<zyga> Keybuk: hmm, it still gets called multiple times though
<Keybuk> it will only call hdparm for the block device being created
<Keybuk> I can only see once?
<ogra> its just schocking me every time until i figure that its not xcsrensaver the bug is for :)
<Keybuk> that script gets called, but it does nothing
<zyga> Keybuk: + '[' /dev/hdc = '/dev/cloop6] '
<zyga> /etc/dev.d/block/hdparm.dev: line 175: [: missing `] '
<Keybuk> yeah, see my comment about my inability to write shell :p
<Keybuk> but that's ok
<zyga> :-)
<Keybuk> so it'll only run hdparm for the block device being plugged 
<Keybuk> if you were to stick /dev/loop0 in your hdparm.conf, it would run that
<zyga> Keybuk: I've fixed and improved the script
<Keybuk> what did you change?
<zyga> Keybuk: just less [ ]  and more bash
<Keybuk> hmm?
<Keybuk> it's /bin/sh not bash
<Keybuk> -a is not portable, or even remotely reliable
<zyga> Keybuk: hmm
<zyga> Keybuk: that's what I've changed
<zyga> -a is not reliable
<zyga> yet another reason to rewrite this mess in python
<Keybuk> [ ... -a ... ]  is bad, use [ ... ]  && [ ... ] 
<zyga> Keybuk: where does it fail?
<Keybuk> each shell has a different precedence for it
<Keybuk> so you can't actually rely on it
<zyga> ...
<zyga> or in C even
<Keybuk> well, yes, clearly this script is worng
<zyga> Keybuk: I'll try to hack it a little
<Keybuk> but only a few weeks from release, I want to make the minimum change possible to make it work, and then look at it with suspicion for dapper
<Keybuk> what you want to have is a program that can parse the hdparm.conf and run hdparm with the right set of a rules for a single given drive
<zyga> Keybuk: yes, release is really soon now
<zyga> Keybuk: hmm
<zyga> Keybuk: that's more less 15 lines in .py
<Keybuk> and then have SUBSYSTEM=="block", RUN+="/sbin/hdparm_block_device"
<Keybuk> get python out of your head
<Keybuk> 1) python is in /usr
<Keybuk> 2) it's big
<Keybuk> 3) it's slow
<Keybuk> 4) these happen a LOT
<zyga> Keybuk: hmm
<zyga> Keybuk: okay so a C program could be hacked to do just that
<Keybuk> writing something in Python that runs when the block device that _contains_ the Python interpreter is first discovered... bad :p
<zyga> Keybuk: with bison flex it's easy but do you want it for breezy or dapper/
<zyga> :D
<Keybuk> dapper
<Keybuk> very very dapper
<zyga> Keybuk: I'd love to have /bin/mini_python
<zyga> Keybuk: without any external modules
<zyga> Keybuk: only os module and maybe re module built in
<Keybuk> sys? :p
<Keybuk> ugh, no re
<zyga> I'm still confused about python module naming but you get the idea
<zyga> re is usefull and python has separate prce anyway
<zyga> pcre
<Kamion> so stuff would randomly behave differently because the compiler options for /bin/mini_python and /usr/bin/python would get out of sync; yay
<Kamion> (it *would* happen)
<zyga> yay
<zyga> now we know that -a gets interpreted differently and it's even slower than python as it spawsn a sub-process to read a one-line file
<zyga> I do agree with your points
<Kamion> && is simpler anyway
<zyga> I just say that python --- or anything else that is 1) more efficient than bash/sh 2) portable and does not have 10 different implementations 3) a real language
<Keybuk> zyga: Python code that does "import re" should begin "#!/usr/bin/perl"
<zyga> Keybuk: python is chmod -r+w
<zyga> s/python/perl/
<zyga> I know perl but I still think that
<Keybuk> so is some people's Python
<Keybuk> especially when they do anything involving it's evil re system, which isn't even compatible with the rest of the world
<zyga> I used to maitain old invoice database managed by gigantic longish perl script
<zyga> Keybuk: why is re evil?
<Keybuk> it's slow, not actually compatible to any other re engine
<zyga> Keybuk: okay
<Keybuk> if you're thinking in re's, you may as well use the interpreter with the fastest re engine in the known universe
<Keybuk> I've seen Python code that imports re, compiles a regular expression object, then matches it against a string
<Keybuk> to see whether the line contains an "="
<Keybuk> the Pythonic way to to that is just if "=" in line:
<zyga> Keybuk: I don't really thing in re's, but they are usefull nontheless (if that's a word)
<zyga> :-)
<zyga> s/thing/think/
<Kamion> gigantic long perl scripts are unreadable, but so are gigantic long python scripts or gigantic long functions in C
<zyga> geez I'm tired today ;-)
<zyga> Kamion: true 
<Keybuk> also I don't generally find Python a good language for writing *short* scripts in
<zyga> but I'd say that
<zyga> [ `cat *.c | wc -l` -gt `cat *.py *.pl | wc -l`  ] 
<Keybuk> a short script that has to read a file, parse it and do something tends to be more complicated in Python than just about anything else
<Kamion> zyga: your shell quoting habits need work, too ;-)
<zyga> Keybuk: I'm not saying python is perfect
<zyga> Keybuk: sheesh ;] 
<zyga> Keybuk: see what I mean ;-)
<Keybuk> zyga: not to mention that's a contendor for a double-wammy "useless use of cat" award
<zyga> num_lines_in(file_list_from_glob("*.c") < num_lines_in(file_list_from_glob("*.py|*.pl"))
<zyga> ;-))
<zyga> Keybuk: actually cat is needed
<Keybuk> [ $(wc -l *.c) -gt $(wc -l *.py *.pl) ] 
<zyga> Keybuk: so that wc doesn't spit out stats for all the files
<zyga> unless there is --summary or something
<Keybuk> can't remember, tbh
<Keybuk> btw, the shell is winning
<zyga> heheh
<Keybuk> that Python is evil
<zyga> Keybuk: why?
<Keybuk> not to mention missing a few imports ?
<zyga> Keybuk: bah ;-)
<Keybuk> where's num_lines_in and file_list_from_glob defined ?
<Keybuk> c'mon, write the script PROPERLY
<zyga> Keybuk: len(file(pathname))
<Keybuk> right
<zyga> Keybuk: and as for glob that's a diferent story
<zyga> Keybuk: I'd say that 
<zyga> 1) a small API for talking to files and doing simple stuff with them
<Keybuk> http://people.ubuntu.com/~scott/pythonic
<Keybuk> there
<Keybuk> the actual equivalent Python was so long I couldn't paste it and had to put it online somewhere
<zyga> 2) a consistent language, without any quoting problems and stuff that vary from .sh to .sh
<Keybuk> shell has 1
<Keybuk> and provided you stick to portable shell, 2 is true too
<zyga> but does not have 2
<zyga> hmm
<zyga> portable shell has very small 1
<Keybuk> otherwise I'll start picking on Python's incredibly bad compatibility between versions
<zyga> Keybuk: maybe slang or something else then
<Keybuk> "what do you mean, this won't run on Python 2.3?!"
<Kamion> most languages have implementation-defined features; there are a bazillion of those in python
<Kamion> shell is fine as long as you actually know how to write it
<Kamion> (which depressingly few people do, but anyhow)
<zyga> Keybuk: then I don't
<zyga> and I know C - I think that sucks on the shell side IMHO
<Kamion> and python certainly has quoting problems, for example if you pick the wrong way to invoke external processes
<Kamion> you can pick the right way, but you can do that in shell too :-)
<zyga> I think you are biased a little
<Kamion> the lesson is, pick the right tool for the job, rather than clinging desperately to the hammer when trying to drive in screws
<zyga> you seem to know your way around sh compatibility issues
<Kamion> zyga: nope, I write python when it's appropriate
<Keybuk> Kamion++
<bddebian> hehe
<zyga> and that does not frigten you :-)
<Keybuk> Python is my favourite hammer by far
<Kamion> I certainly tend to avoid languages where I'm aware that I don't know how to use them safely; I'd hope that applies to most people
<Kamion> all I'm saying is, shell still has its appropriate niches
<zyga> Kamion: and I agree
<zyga> Kamion: and all I'm saying that is has some issues - especially the learning curve to get things right
<Keybuk> Kamion: python also has encoding problems...  it's unicode strings are like STIs; someone innocently gives you one and suddenly everything's infected and basic things become painful
<zyga> Kamion: I dont want to give you the impression that python has none IMHO, I just think that it has less 
<zyga> Keybuk: yes - that sucks alot
<Kamion> you might find http://www.greenend.org.uk/rjk/2001/04/shell.html a useful article on avoiding common shell mistakes
<Kamion> written by a friend of mine
<zyga> Kamion: interesting
<sivang> Kamion: that's a keeper :)
<zyga> I know most of that stuff really, one interesting thing for me was how to do for I in *.foo; ... done; properly
<zyga> I still think that sh is a minefield
<zyga> I especially like old scripts 
<zyga> mostly written in csh
<Keybuk> csh isn't sh
<sivang> maybe someone can help me, I am SIGHUPing cupsd. now accoridng to the code, it should do a configuration reload in response, all I get is "Termination successful", what am I doing wrong?
<zyga> that come along with old comercial programs 
<zyga> ;)
<Keybuk> they're totally different languages
<zyga> I know :)
<zyga> they have lots of lots of checks to work on many then-popular systems
<Keybuk> sivang: cups doesn't handle SIGHUP
<elmo> infinity: ?
<Keybuk> so it will just terminate
<Keybuk> I came across that one last year
<zyga> sivang: I've seen someone complain recently that cups dies on sighup
<sivang> Keybuk: I see, but it has sighup_handler there , guess it does nothing but shut down
<Keybuk> can't remember, I think that only got enabled for debugging or something
<sivang> Keybuk: hmm, then I will need to teach it, if you've worked with it , do know if it's should be in schduler/main.c or scheduler/server.c or config.c ? :) (they all refel to the NeedReload flag that get's set by the singals)
<sivang> zyga: you have a bug number?
<zyga> sivang: no, sorry - I just overheard this a few days ago
<sivang> zyga: ok
<zyga> sivang: if you know about a place that logs #u-d you might find something about this
<Keybuk> sivang: no idea ... I just discovered that the log rotation script killed cupsd every night by trying to get it to hangup and re-open its log files <g>
<Keybuk> sivang: so we changed it to restart cupsd instead
<Keybuk> that's about as much investigation as I did
<Keybuk> it was something to do with the fact that if it's dropped privileges, it can't actually reload its own configuration
<Keybuk> not without elevating itself back to root, anyway
<Keybuk> and we run cupsd in reduced privilege mode, because pitti saw it
<sivang> Keybuk: yes, I see it now :-/
<sivang>   if (RunAsUser)
<sivang>     sigset(SIGHUP, sigterm_handler);
<sivang>   else
<sivang>     sigset(SIGHUP, sighup_handler);
<elmo> heeeeeelp heeeelp I neeedsss a buildd admin
<zyga> heh
<mae__> m
* zyga for a moment gazed at the C code and though... what are those redundant parenthesis for.... then I was enlightened
<sivang> Keybuk: so now it responsds with a restart when poked with a SIGHUP ?
<Keybuk> sivang: no, cause it can't restart itself either
<sivang> Keybuk: or that just plain unhandled?
<Keybuk> it kills itself
<\sh> elmo: Kamion is busy ;)
<elmo> \sh: he's also not a buildd admin
<Keybuk> "Don't send cupsd SIGHUP" :)
<Kamion> \sh: since when was I a buildd admin?
<\sh> damn...lamont kamion...I need some holidays
<\sh> or new glasses?
<sivang> Keybuk: or just teach it to handle it properly :)
<Keybuk> sivang: if it's running as a user, it won't be able to re-open its socket
<sivang> Keybuk: yep. so we are going to not try reopen the sockets when RunAsUser
<Keybuk> let alone things like its log files
<Keybuk> mehhhh
<Keybuk> a busted HUP handler is worse than none, surely
<Keybuk> HUP (for a daemon) means close all your sockets, file connections, reload your configuration and open them again
<sivang> Keybuk: well, that's what pitti asked me to attempt to do, have it crippled, but then we won't have to restart the cups server every time a usb printer is plugged in
<Keybuk> wouldn't adding some hal love to cups be a better plan
<Keybuk> so rather than have something smack cupsd every time a printer gets added, actually have cupsd listen out for it
<Keybuk> (and I'm not even convinced cupsd runs with enough privilege to access usb printers that it didn't open when it was root)
<sivang> Keybuk: would, but not at that stage of the release. We'd like to have something going for breezy
<Keybuk> fair enough
<sivang> Keybuk: it would just "rediscover" them, so we don't suspect too much problems. I first hacked it to just to a /etc/init.d restart, but then pitti noted that users may have print jobs ongoing and it would kill them
<zyga> am I the only person that feels breezy would be better if it was 5.11?
<Keybuk> zyga: what would you put in .11?
<sivang> zyga: you mena postpone the release with  a month ?
<zyga> yes
<Keybuk> bearing in mind moving it a month wouldn't necessarily remove the restriction on changes
<zyga> I'm just whining though..
<Keybuk> the theory of a 6-monthly release process is that in three weeks, we get to fix everything properly
<zyga> Keybuk: I was thinking about the bugs
<Keybuk> which ones?
<zyga> Keybuk: nothing specific - as I said it's just a feeling
<Keybuk> other than the 236 release critical ones <g>
<Keybuk> I actually think breezy's in a slightly better state than warty was at this point
<Keybuk> we only have 6 critical bugs open
<zyga> but anyway - doing a every-6-months release is better than as-soon-as-everything-works-just-wait-and-use-your-nifty-oldish-package
<Keybuk> dunno how mdz feels though
<Kamion> zyga: one always feels it would be better if it were just a little later for a few more fixes - but after a few releases you realise it's even better to be guaranteed to have another release in six months' time that you can get your fixes into
<zyga> Kamion: you are right
<Keybuk> zyga: install a hoary box, use it for a few days, then install breezy instead
<Keybuk> it's odd, but breezy does feel better
<zyga> in corporate planet I often see a 5 year old distro and everyone refuses to upgrade ;-)
<Keybuk> I reckon someone's lightened the control colours a bit
<zyga> then they ask me to work in this piece of history and fix bugs and other issues
<zyga> Keybuk: breezy has lots of excelent things
<zyga> Keybuk: and breezy does feel better than hoary
<ivoks> breezy is better
<ivoks> period.
<Keybuk> "better" is the goal
<Keybuk> "perfect" is something to aim for, but we can get closer in 6-months
<zyga> Keybuk: maybe I'm biased ... I started using warty, then I upgraded to hoary and got interested in developement, near breezy I see how this thing is working and I know about the bugs and issues still around
<zyga> maybe ignorance is bliss
* zyga misses ubuntu-calendar
<ivoks> free porn? :)
<zyga> no
<ivoks> it was a joke...
<zyga> it would have been equally good with landscapes
<zyga> the fact that it was upgraded every month
<ivoks> yeah, that was great
<zyga> hmm
* sivang misses too
<ivoks> hm...
<zyga> I've just apt-getted it and it's not in the backgrounds menu
<Keybuk> another way of looking at release management is to rather think of extending the release cycle by a month to get more bug fixing in, reducing the development cycle by a month
<Keybuk> that way you've got a month less to break things, and a month more to fix them
<Keybuk> while still holding 6-monthly
<ivoks> yup
<zyga> Keybuk: faster freeze?
<ivoks> and one month older packages :)
<Keybuk> it's all a matter of balance
<zyga> Keybuk: but then again freeze is a double-edged sword
<ivoks> sure
<mdz> Keybuk: about what?
<mdz> the overall bugginess?  we're not in bad shape
<zyga> hey I've found a bug in ubuntu-calendar
<zyga> it's a trivial fix
<Keybuk> mdz: that's my impression, we're actually pretty good
<zyga> the package puts the xml files into /usr/share/gnome-wallpaper-properties
<mdz> I don't think we can usefully compare to warty, and maybe only somewhat to hoary
<zyga> while it should have put them in /usr/share/gnome-background-properties
<zyga> :-)
<mdz> but my gut says "not bad"
<zyga> will anyone accept a patch that fixes this?
<mdz> we have a much higher rate of sustained bug activity now than we ever have before, I'd say
<seb128> mdz: yeah, I would say that too :/
<zyga> anyone :-)
<zyga> It's a one-liner and it works
<seb128> zyga: what?
<zyga> seb128: there's a bug in ubuntu-calendar* packages
<seb128> $ ls -l /usr/share/ | grep properties
<seb128> lrwxrwxrwx     1 root root    26 2005-03-02 23:40 gnome-background-properties -> gnome-wallpaper-properties
<seb128> here
<zyga> hmm
<zyga> okay but it does not work 
<zyga> a manual fix makes it work
<seb128> "manual fix"?
<zyga> maybe it does not like symlinks
<zyga> hmm
<seb128> it works for me
<zyga> hmm I'm dumb
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=13256
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=8721 has some comments on the topic
<zyga> seb128: okay
<seb128> if you want to track the issue that would be appreciate
<seb128> there is probably an issue but that's not obvious which one
<zyga> zyga@falcon:/usr/share$ ls -l /usr/share/ | grep properties
<zyga> drwxr-xr-x     2 root root  4096 2005-09-27 23:12 gnome-background-properties
<zyga> drwxr-xr-x     2 root root  4096 2005-09-27 23:13 gnome-wallpaper-properties
<zyga> they are not symlinks here
<seb128> but you changed that, right?
<zyga> no
<zyga> I've reinstalled the packages to be sure
<zyga> g-w-p is not a symlink
<zyga> I did not touch that
<zyga> I've got the gnome-background package too 
<Kamion> seb128: it causes problems (undefined behaviour, depending on unpack ordering) for one package to install a symlink and another to install a directory in the same location
<zyga> (I'm not sure about the name but you get the idea)
<zyga> Kamion: I'd say it's better to put everything into the proper directory than to put symlinks around
<Kamion> seb128: you're probably going to have to fix up the situation in maintainer scripts
<zyga> hmm anyway it's a real bug not my imagination -- I'm really tired today and I didn't want to look like a fool
<seb128> Kamion: do you know why ubuntu-artwork install them to the wrong directory to start?
<seb128> jdub: around?
<Kamion> seb128: nope
<zyga> seb128: which directory is correct?
<seb128> I guess that jdub knows about that
<seb128> zyga: gnome-background-properties
<zyga> seb128: how about a patch that makes g-b-p just search both directories?
<sivang> Keybuk: weird. I manually executed cupsd as root, SIGHUP'd it, and it still "Terminates normally" 
<seb128> zyga: I want to know why they made this hack first
<Keybuk> sivang: is it actually root when you HUP it, or has it turned into cupsys?
<zyga> seb128: or is there any easier to migrate stuff from one directory to the other
<zyga> seb128: I think upstream changed the directory and packager tried to get upgrade working
<seb128> zyga: no, upstream didn't change this code for pretty sure
<zyga> seb128: maybe just rebuilding calendar packages will work, old packages get removed
<seb128> zyga: I'm one of the upstream for it
<zyga> hmm then I'm out of ideas
<zyga> seb128: I can confirm that rebuidling the package fixes the issue
<zyga> (with the new directory instead of the old one)
<seb128> the changelog of ubuntu-artworks suggest they change it to avoid a conflicts with gnome-desktop-background package
<seb128> rebuilding?
<seb128> or reinstalling?
<seb128> oh, you mean installing them to the other dir?
<zyga> seb128: rebuilding after modifying the directory, then reinstalling
<zyga> yes
<Keybuk> disturbing ... my screensaver just morphed Kinnison into Diziet
<Nafallo> lol
<sivang> LOL
<sivang> Keybuk: how do I check? I su'd to root, /usr/sbin/cupsd -F , then SIHUP'd it with a sudo
<Keybuk> sivang: ps aux | grep cups
<sivang> bah, right
<sivang> Keybuk: damn. it is cupsys , how does it switch to the user so soon?
<Keybuk> setuid ? :p
<Keybuk> generally it's considered wise to drop your privileges quickly if you're going to do so
<zyga> seb128: do you want a patch?
<zyga> seb128: is there any way to i18n-ze the those xml files
<zyga> yes I'm an i18n whore
<sivang> Keybuk: ah right , funnny that support dropping the privileges but didn't care for the realod config as the user appareently . funny upstream ;)
<Keybuk> the problem is what if the config file change the user wants to reload for is a change of listening port?
<Keybuk> you need to be root to listen on ports < 1024
<sivang> right, maybe I can selectivey sense a printer event, and respond only for those...
<Simza> when is string freeze for Breezy?
<zyga> Simza: AFAIK it's already string freeze
<zyga> how to say in debian/control
<mvo> yes, we are deep in string freeze
<zyga> replaces & conflicts with the same package at version smaller than current
<seb128> zyga: patch to https://bugzilla.ubuntu.com/show_bug.cgi?id=8721 if you have one
<zyga> seb128: sure
<seb128> zyga: for the translation:https://bugzilla.ubuntu.com/show_bug.cgi?id=9080
* zyga likes doing packages :D
<zyga> seb128: 13256 is a duplicate of  8721
<zyga> seb128: can you marke it as such
<seb128> zyga: thanks, I've done that like 10 min ago :p
<zyga> seb128: sorry ;)
<seb128> no problem at all
<seb128> thanks for pointing it :)
<zyga> seb128: I'm doing update && upgrade to check that the problem is indeed fixed 
<zyga> seb128: just to clear things up, ubuntu-artwork contains all the translations for calendar and many other artwork-related stuff?
<seb128> zyga: nop, no translation
<zyga> seb128: .pot's -- sorry
<seb128> afaik there is some work to do on it, cf https://bugzilla.ubuntu.com/show_bug.cgi?id=9080
<zyga> do you really remember those bugs?
<seb128> zyga: the number? no. The bugs description, yep ... and I know how to find them with a query
* mvo suspects that seb128 knows _all_ the bugnumbers by heart _and_ can map between ubuntu bz and gnome bz bugs 
<seb128> ah ah :)
<mvo> but I can't prove it ;)
<seb128> :p
<zyga> aww... now it works as expected but with old packages
<zyga> and both directories are in fact directories
<zyga> ah, no it does not :-)
<zyga> everything is okay now :)
#ubuntu-devel 2006-09-25
<AlinuxOS> jordi http://paste.ubuntu-nl.org/i24720
<jordi> ah, but this is at boot stage
<jordi> I don't know then
<AlinuxOS> Kamion, jordi http://paste.ubuntu-nl.org/i24722
<jordi> AlinuxOS: pretty cool
<AlinuxOS> unifont is not installed....and iin terminal mode there is still font support...
<jordi> so what's the problem with this?
<AlinuxOS> so I don't know which one is it
<jordi> aha
<jordi> so I guess there's some console font that has this stuff
<jordi> the fc-list thing I told you won't work, that's for true-type fonts
<AlinuxOS> jordi, some years ago som non-georgian person designet that glypps
<jordi> and they are bad, I guess :)
<AlinuxOS> that have horrible proportions...I with my friens have designet another one...so I would li to test fonts before and than substitute them.
<AlinuxOS> jordi, exactly ;)
<jordi> AlinuxOS: aha
<AlinuxOS> so I'm little bit confused...
<jordi> if the cd is using syslinux, you should be able to try replacing it
<jordi> I don't know what's in use there tho
<AlinuxOS> Kamion, (as I remeber) some time ago said that for debian-installer we need bitmap fonts...and so unifont georgian coverage...
<AlinuxOS> jordi, in terminal mode (non X mode) I see them :)
<AlinuxOS> so they are somewhere here :D
<AlinuxOS> in my hd..without unifont package installed ;)
<jordi> AlinuxOS: was that in dapper too?
<jordi> or is it new in edgy?
<AlinuxOS> Edgy
<AlinuxOS> not dapper :)
<jordi> hrm, I have no edgy cd here
<jordi> I wonder how colin builds cds
<AlinuxOS> I'm working to make Edgy more Rocky :)
<AlinuxOS> ah so you use dapper
<jordi> I just upgraded my laptop, didn't use a CD
<jordi> hmm, according to my "get good sleep plan" I should be in bed already.
<jordi> good night!
<ajmitch> morning
<jono> hey all
<ajmitch> hey jono 
<jono> anything overtly broken in edgy right now? I am on vacation and would like to still be able to access the Internet :P
<jono> hey ajmitch :)
<ajmitch> nothing major that I know of, since it's beta freeze time 
<zul> broken as in how?
<zul> sorry...not really paying attention
<ajmitch> I haven't rebooted yet, but everything seems to be there 
<jono> cool
<jono> zul, just X b0rkage or kernel issues
<zul> ah...just rebooted and havent seen anything on the i386 side
<jono> cool
<jono> will upgrade :)
<crimsun> jono: pong (sorry for the delay)
<jono> crimsun, no worries
<slomo> Fujitsu: thanks for updating soundconverter to a gst0.10 version :)
<slomo> crimsun: ping? (same question as always ;) )
<Fujitsu> No problem, slomo. That eliminates python-gst in Sid.
<Fujitsu> (and thus Ubuntu, I presume)
<slomo> Fujitsu: yes :) unfortunately gst0.8 is still alive... and even one of my packages still needs it :(
<Fujitsu> Noted, goobox, gstreamer-editor, etc.
<Fujitsu> I didn't expect to be maintaining it in Debian, until the previous maintainer orphaned it the second he saw 0.9.1 was using autotools.
<ajmitch> hi mako 
<mako> ajmitch: hey there
<mako> i got there eventually
<slomo> Fujitsu: i would've taken it too ;)
<Fujitsu> slomo, no, mine, gerrof :P
<slomo> Fujitsu: ok, something less to worry about =)
<ajmitch> posessive, isn't he?
<HrdwrBoB> you're possessive.
<HrdwrBoB> your possesive even
* Fujitsu protects his only Debian package.
<Nafallo> hehe
<Fujitsu> Yay, netsplit.
<Nafallo> small one though :-P
<Fujitsu> True.
<jono> is anyone seeing different fonts in Firefox and OpenOffice.org ?
<zul> not me
<jdong> jono: if you mean different hinting, yes
<jono> jdong, right, so this is a known bug?
<jdong> jono: bug 54776, I think you refer to
<Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Untriaged,Confirmed]  http://launchpad.net/bugs/54776
<jono> ok cool :)
<jdong> cool in the irritating way? ;-)
<jdong> the last comment has a workaround
<jono> heh
<jono> cool as in jono doesnt need to submit a bug report :)
<Nafallo> hehe
<jdong> BenC: can I poke you about a puzzling usb-storage problem?
<BenC> jdong: I might be a little lagged in responding, but sure
<jdong> bug 61235
<Ubugtu> Malone bug 61235 in linux-source-2.6.17 "USB mass storage stops working after a while" [Untriaged,Confirmed]  http://launchpad.net/bugs/61235
<jdong> see pastebin link, too
<jdong> BenC: let me know if you need any other output... I've got the device handy
<fabbione> morning guys
<Fujitsu> Hey fabbione.
<Hobbsee> hey fabbione 
<ajmitch> hi fabbione 
<ajmitch> ready to warm up the sparc for the rebuild?
<fabbione> ajmitch: almost
<fabbione> ajmitch: there is a couple of bugs i need to get fixed first otherwise it won't work
<LaserJock> Burgundavia: you pinged me last night? anything important?
<Burgundavia> LaserJock: my desktop was up for you to pbuilder on, but the machines has since died
<LaserJock> hehe, ok
<Burgundavia> LaserJock: and I am in Colorado right now
<minghua> it seems quite a lot of MOTUs are relying on Burgundavia's desktop?
<Fujitsu> I'm surviving on my 64kbps connection now, it's not great, but it'll do.
* ajmitch would open up his box for usage except for the data cap
<ajmitch> this is where I need xen setup on my desktop
<crimsun> oh crap
<Fujitsu> What?
<crimsun> err, I just uploaded boost by mistake (though it's not a new upstream version)
<ajmitch> ah, to main
<crimsun> it does fix a crasher, though. Sorry about that.
<lastnode> is there anyway to link a sf.net svn repo and a bzr account, so they sync?
<lastnode> (id like bzr to sync off the sf.net svn)
<lifeless> lastnode: what do you mean by bzr account ?
<lastnode> sorry
<lastnode> i mean branch
<lastnode> i havent opened a branch yet for https://launchpad.net/products/upstream , we currently coordinate via sf.net svn. i was wondering if i open a bzr branch, is syncing possible?
<lifeless> you can have launchpad sync a branch for you
<lifeless> just set the RCS Details for your release series
* lastnode registers a bazaar branch
<dholbach> good morning
<Seveas> mornin' dholbach 
<dholbach> hey Seveas
<Kagou> morning
* Mithrandir chuckles at Burgundavia's comment on the userful multiplier story in UWN.
<pitti> Good morning
<ajmitch> hey pitti 
<Fujitsu> Mithrandir, hahahaha.
<pitti> moin ajmitch 
* Hobbsee wonders what it is
* Hobbsee wants another laugh
<LaserJock> that is funny
<Hobbsee> haha
<pitti> Kamion: http://cdimage.ubuntu.com/daily/current/edgy-alternate-amd64.jigdo is listed in the directory index, but leads to a 404
<Hobbsee> hey pitti 
<pitti> hey Hobbsee 
<pitti> Kamion: same for ppc, btw; i386 works
<seb128> Kamion, mdz: should the gnome-python split (for xubuntu) should be delayed to after beta or is that ok to upload it today?
* seb128 grumpfs, linux 2.6.17-9 amd64 just crash to agp code on boot
<seb128> bug #62215
<Ubugtu> Malone bug 62215 in linux-source-2.6.17 "2.6.17-9.23 regression: crash at boot (amd64)" [High,Unconfirmed]  http://launchpad.net/bugs/62215
<fabbione> Kamion: ping?
<poningru> quick question does the debian halting of ff name/artwork have impact on ubuntu?
<poningru> or do we not know?
<Lathiat> debian halting?
<Fujitsu> poningru, there's a bug open against Firefox about it...
<Treenaks> Lathiat: Debian is in a conflict with the Mozilla people about the 'firefox' name
<poningru> in launchpad?
<Fujitsu> poningru, yes.
<poningru> thanks
<poningru> Fujitsu: mozilla-firefox? or firefox?
<seb128> pitti: gdb 6.5 segfaults on gaim too
<Fujitsu> poningru, firefox, I think.
<Fujitsu> There's only one of those two in LP..
<poningru> no lp still has m-ff and ff
<Fujitsu> Hm, that's strange.
<sivang> morning
<pitti> seb128: :(
<StevenK> poningru: Which was last updated with Hoary
<StevenK> Hoary will hit OBSELETE next month anyway.
<StevenK> I bet pitti is counting the days.
<Fujitsu> True.
<pitti> StevenK: I do :)
<poningru> thanks
<seb128> pitti: when I spoke about it with doko some time ago he said that could due to ssp maybe
<ajmitch> pitti: going to celebrate? :)
<pitti> seb128: ah, true
<pitti> seb128: well, we could try building gcc without ssp and check again
<pitti> ajmitch: yeah, by happily removing hoary from my mirror and by removing the hoary chroot :)
<seb128> pitti: how do I do that?
<pitti> seb128: add -fno-stack-protector to CFLAGS
<Lathiat> wow thats an awesome mess
* sivang has not had internet access for a week and lost a screen session, if someone msg'd me, re-mg please.
<seb128> pitti: for gcc? or you meant gdb?
<pitti> seb128: gdb
<seb128> k
<seb128> trying
* pitti hugs seb128
* seb128 hugs pitti back ;)
<seb128> pitti: segfaults with -fno-stack-protector too :/
<pitti> seb128: ok, so that's not it
<pitti> seb128: if you are at it, can you please apt-get source pkg-create-dbgsym and ./testsuite?
<pitti> seb128: (with no SSP)
<seb128> ok
<seb128> pitti: all PASS ok
<pitti> seb128: right, but do you see some error messages about frame pointers in between?
<pitti> seb128: I modified the latest version to work around the gdb bug, but you'll still see the messages
<seb128> pitti: http://paste.ubuntu-nl.org/24757
<pitti> seb128: oh, wow, that indeed doesn't seem to have that problem
<pitti> seb128: thanks!
<seb128> np
<seb128> pitti: that's with gdb 6.5 upstream built with -fno-stack-protector
<dholbach> jdub: you could write a Main Inclusion Report for libgalago and libgalago-sharp, then an Upstream Version Freeze exception for beagle - that's the only package using galago (apart from peekaboo applet from gossip)
<ajmitch> beagle may already have UVF exception granted
<ajmitch> I can't recall if it was granted for 0.2.9 or 0.2.10
<jdub> dholbach: wow, the peekaboo applet is surprisingly nothingish
<jdub> oh, i see
<jdub> it saves as favourites
<Kream> hi all. I've looked but I can't find the launchpad.net link to translate ubiquity-frontend-kde or -gtk. Can someone point me to it ?
<dholbach> Kream: better ask in #launchpad - didn't you just write a mail to  launchpad-users@  about that?
<Kream> dholbach:  oh, i'm sorry, I didn't know there's #launchpad
<Kream> my apologies, all
<dholbach> Kream: not to worry :)
<dholbach> can somebody please give back  opal  and  libgnomeuimm2.6 ?
<Kamion> Kream: you should translate debian-installer - the ubiquity translations are merged in there
<Kream> ahhhhhhh
<Kream> Kamion: thanks :)
<cbx33> hi dholbach 
<popey> lo cbx33 
<Kamion> Mithrandir: we need a d-i upload - I'll work on it shortly if you haven't already
<cbx33> hey popey 
<cbx33> howz it going bud?
<popey> tickety boo thanks :)
<cbx33> excellent
* cbx33 is another year older ;(
<popey> you?
<popey> today?
<cbx33> yesterday
<popey> well they say life begins at 40
<popey> :)
<cbx33> heheh
<cbx33> howz the "net"cast going
<Kamion> pitti: it was probably just still syncing to mirrors
<Kamion> seb128: can I see the diff or something?
<Kamion> fabbione: pong
<seb128> Kamion: https://launchpad.net/distros/ubuntu/+source/gnome-python/+bug/60615
<Ubugtu> Malone bug 60615 in gnome-python "split out gconf bindings" [Wishlist,Confirmed]  
<pitti> Kamion: indeed, works now; thanks
<seb128> Kamion: cf "new debdiff"
<Kamion> seb128: ok, I'll look in a bit, still catching up on the weekend's everything
<cbx33> seb128: I'm sorry my pc has been up the shute recently, i'll get that patch for gconf to you for the scp integration as soon as I can
<fabbione> Kamion: hey dude.. regarding that ppc/ruby1.8 bug.. i asked benh to look at it, but he would like to talk to you here in IRC (benh) later today. He can't reproduce the problem on his g5 and he might need some help from you. Also he thinks he might be a kernel bug and i am looking into getting a .17 kernel on davis for testing
<Kamion> fabbione: I'm hardly an expert here ...
<Kamion> relying on me being contactable at the moment is unfortunately not a good plan - moving house is making it very tricky
<fabbione> Kamion: neither am I, but you are the one that did the best up till now
<seb128> Kamion: ok, thank you. That has been discussed on the devel list too ("stuck" thread)
<cbx33> Kamion: i may be doing the very same thing soon
<seb128> yeah, not a nice mail subject :p
<fabbione> Kamion: yes i am aware of that. Perhaps just add info to the bug? or something? he is subbed to it
<fabbione> Kamion: it was not really clear to me what he wants to know from you (neither he really told me)
<pitti> Mithrandir: cprov uploaded the new langpacks last night; can they be approved for the beta?
<pitti> Mithrandir: oh, it seems they are already in, nevermind
<maswan> Mithrandir: heh. even when exploded, thinkpads seems to hold together good enough to be thwappable. also, in other things, is anyone still using ravel for real work?
<sivang> cbx33: hi
<dholbach> Mithrandir: ok to upload deskbar-applet? (just changed recommends and build-deps from python2.4-* to python-*)
<Kamion> Mithrandir: new d-i on its way
<Kamion> new ubiquity needed as well, on its way soon
<cbx33> hi sivang 
<Mithrandir> maswan: not that I know of atm, no.
<Mithrandir> Kamion: ok, thanks.
<Kamion> Mithrandir: oh, I think my fix for a beta-critical bug may have been wrong - occurred to me over the weekend. It's the one about automounting removable devices
<Kamion> I did it in partman-target, but partman-basicfilesystems also sets up default mount points for everything
<Mithrandir> hmm, true.
<Mithrandir> I'm thinking about properly freezing the archive soonish and going into manual-approval mode.  Unless somebody has a complaint?
<cbx33> Mithrandir: is that for main?
<Mithrandir> cbx33: yes.
* ajmitch would think that a proper freeze would be a good thing
<cbx33> I have two minor changes to push through, but they are just that, very minor....I'm getting them ready today.....I hope ogra will be able to approve them
<maswan> Mithrandir: ok, we're thinking of making it do ACC:y thingies, if/when we get a network upgrade for ftp.acc we need more frontends
<cbx33> Mithrandir: how soon is soon?
<Kamion> Mithrandir: could you review http://people.ubuntu.com/~cjwatson/tmp/removable-mountpoints.diff?
<Kamion> it's bug 60552
<Ubugtu> Malone bug 60552 in partman-basicfilesystems "adds removable devices to fstab by default" [Medium,Confirmed]  http://launchpad.net/bugs/60552
* netjoined: irc.freenode.net -> brown.freenode.net
<Mithrandir> Kamion: yeah, I'm just checking for the PATH thingy.  I think it needs to be *-usb-* as well, but I'm checking
<Kamion> Mithrandir: hmm?
<Kamion> no problem with going to frozen
<ogra> argh, who wrote the UWN this time ? 
<ogra> Burgundavia, !
<Mithrandir> Kamion: pci-[^-] *-usb|usb is what casper uses, at least.
<cbx33> ogra: what's up with it?
<carlos> seb128: hi, around?
<ogra> cbx33, this article he links to is totally wrong ... 
<seb128> carlos: hey
<cbx33> oop
<carlos> seb128: hi, about that problem I have with xchat
<carlos> seb128: it's related with locales, but I didn't see anything obvious in the Spanish .po file
<carlos> seb128: do you have any clue about where could I check it?
<ogra> Burgundavia, would have been nice to have the http://wiki.ltsp.org/twiki/bin/view/Ltsp/Ltsp5 article linked there, instead of being blamed for forking code and not giving it back :/
<seb128> carlos: open a xchat-gnome bug on launchpad, some upstream guys read launchpad bugs and are nice and reply usually
<carlos> ok, thanks
<cassidy> carlos: what's the problem ?
<Kamion> Mithrandir: I just nicked the code you wrote in partman-target a while back ;)
<Kamion> Mithrandir: ok, I'll fix that, thanks
<Mithrandir> Kamion: I probably just forgot to update that, then.  Feel free to fix that. ;-)
<Kamion> Mithrandir: that's ID_PAT
<Kamion> H
<Kamion> I'm using ID_BUS ...
<Kamion> (the code in partman-target doesn't exist any more - I resurrected it from bzr)
<carlos> cassidy: my nick is not hilighted when someone pings me
<carlos> cassidy: it works with LC_ALL=C but not with es_ES.UTF-8 so it's not a configuration problem
<cassidy> carlos: rahh, yet another translation problem. GRRR
<Mithrandir> Kamion: hmm; but won't ID_BUS sometimes be PCI for the case above?
* cassidy dreams to use official GNOME translation team to translate x-g
<cassidy> carlos: fill a bug
<carlos> cassidy: I checked the Spanish .po file
<carlos> cassidy: but I didn't find any obvious bug there
<cassidy> we already have this kind of problem with /me messages
<cassidy> but i don't know what's the cause
<Kamion> Mithrandir: oh, hmmmm
<Kamion> you know this crap better than I do, I'll defer
<doko_> thom: hmm, why doesn't apache show files larger than 2GB
<Kamion> Mithrandir: what about IEEE1394?
<Kamion> do you know how that shows up in ID_PATH?
<carlos> cassidy: that bug (/me one) is already fixed in my current version 0.13
<cassidy> it should be fixed, yes
<Mithrandir> Kamion: seems to be pci-$foo-ieee1394-$bar
<Kamion> I think maybe egrep -q 'ID_PATH=(pci-[^-] *-)?(ieee1394|usb)'
<Kamion> Mithrandir: BTW, are you ever going to fix casper to use egrep rather than grep for that? :)
<Mithrandir> Kamion: yeah, I should, I've just forgotten
<thom> doko_: um, because 2.0 isn't LFS64 capable?
<thom> (and nor is 1.3)
<carlos> seb128, cassidy: https://launchpad.net/distros/ubuntu/+source/xchat-gnome/+bug/62282
<Ubugtu> Malone bug 62282 in xchat-gnome "words hilight doesn't work" [Untriaged,Unconfirmed]  
<seb128> carlos: thank you
<cassidy> carlos: i think you should assign it to the spanish translation team
<doko_> thom: thanks
<cassidy> or assign a task to the translation pkg
<Mithrandir> Kamion: bugs.debian.org/374539 seems to have some paths embedded.
<carlos> cassidy: well, I'm a member and have rights to fix that, but I didn't find anything in the .po file that make me feel like I found the problem...
<carlos> If you know the msgid that controls that in the .po file I will fix it right now
<Kamion> Mithrandir: ah yes, thanks
<cassidy> carlos: i don't :\
<carlos> ok
<Mithrandir> ok, main is frozen now
<pitti> Mithrandir: permission to upload a new xorg with a simple patch to fix bug 60448?
<Ubugtu> Malone bug 60448 in xorg ".xsession_errors file grows out of control & saturates disk space" [High,In progress]  http://launchpad.net/bugs/60448
<pitti> Mithrandir: http://librarian.launchpad.net/4376511/Xsession.patch
<pitti> to avoid disk usage DoS
<Mithrandir> pitti: I'd like us to have a max-size for it rather than just blindly truncating it, really.  There's a bit of discussion around this on -devel, iirc and I'd like that to finish before doing something.
<Mithrandir> pitti: feel free to disagree, obviously.
<mvo> Mithrandir: http://people.ubuntu.com/~mvo/tmp/python-central_0.5.5ubuntu3.debdiff <- fix upgrade issue when /usr/share/python/default_versions does not have any "old-versions" in it
<Mithrandir> mvo: ok.
<mvo> Mithrandir: thanks
<pitti> Mithrandir: max-size isn't what we want, really; it would hide the most recent messages, which are usually the more interesting ones
<pitti> a logrotate approach might be better, but sounds like overkill for user's homes
<Mithrandir> pitti: I was thinking about truncating it on login if it's bigger than a set size.
<pitti> ah
<Mithrandir> pitti: or even better, removing lines from the beginning of the file until it's smaller than said size.
<Kamion> Mithrandir: can I upload installation-guide to document (a) Kickstart changes for %packages and keyboard and (b) console-setup preseeding?
<Mithrandir> Kamion: yes
<pitti> Mithrandir: ok, I'm fine with letting it sit until after the beta
<Kamion> thanks
<Mithrandir> pitti: something like f=.xsession-errors; if [ $(wc -c "$f") -gt $((1024*1024)) ] ; then tac $f | perl -lpe '$a += length; exit if $a > 1024*1024;' | tac | sponge $f ; fi
<Mithrandir> but preferably slightly less hacky.
<Kamion> (stat)
<Mithrandir> actually something like f=.xsession-errors; if [ $(wc -c "$f") -gt $((1024*1024)) ] ; then tac $f | head -c $((1024*1024)) | tac | sponge $f ; fi
<Kamion> 'stat -c %s', that's the rune
<pitti> s/sponge/a temporary file/ and tail?
<Mithrandir> Kamion: true, that's probably better, but I started off trying to use shell-builtins.  As you see, I failed. :-)
<Kamion> sponge is in moreutils
<Mithrandir> pitti: sure; the point is the general idea, not my exact implementation. :-9
<Mithrandir> s/9/)/
<pitti> yeah, of course
<ogra> grmbl ... why does my usplash artwork not work ...
<Kamion> resolution?
<cbx33> ogra: what did you alter on it?
<cbx33> did you get my message ogra about the png crushing? - I didn';t manage to get it to work on mine
<cbx33> but then i did have troubles with usplash before if you recall
<ogra> i didnt alter anything
<cbx33> oh :(
<ogra> the thing is that i kept the old name for the binary ... which worked well last week ... but seems to have stopped with a recent usplash upgrade 
<ogra> i'll look into it ... no worries
<cbx33> ok
<cbx33> once I get this new vm machine I can test things out
<ogra> should be the last beta critical thing left on my list 
<cbx33> ogra: you rock dude
<ogra> cbx33, use the qemu script we ship with ltsp ;)
<cbx33> do you have a release critical list?
<ogra> /usr/share/doc/ltsp-server/examples/qemu-ltsp
<cbx33> ogra: is there a distinct advantage?
<ogra> nope, not anymore 
<cbx33> on the latest CD image today...i just got a filure
<cbx33> failure
<cbx33> in select and install software
<ogra> apart from usplash, all should be in shape now ... there was a problem with loading the fuse module in the installer yesterday but that should be solved with the recent d-i upload from Kamion 
<cbx33> configuring pkgsel failed
<ogra> right
<ogra> switch to console 4 
<cbx33> ah is that the fuse thing
<cbx33> ok
<ogra> there should be ltspfs listed
<cbx33> yes indeed
<ogra> moaning about not finding modules.dep
<cbx33> yeh
<ogra> its caused by installing a -9 kernel but the installer only knows -8
<ogra> (i hope :) )
<cbx33> hehe.
<cbx33> anyway to finish the installation?
<ogra> just pick the next point in the menu
<cbx33> ok
<ogra> run dpkg-configure -a afetr your first login ...
<cbx33> installing grub failed
<ogra> luckily its only edubuntu-server and only that one package, so your install still works
<ogra> oh
<cbx33> calling apt-install grub failed
<cbx33> in C4
<ogra> that one worksed for me :/
<Kamion> Mithrandir:    99737 | S- | python-central       | 0.5.5ubuntu3         | 22 minutes
<Kamion> approved?
<cbx33> ogra: do you want anymore information?
<Mithrandir> doko_: I assume ^^ is yours?
<mvo> Kamion, Mithrandir: http://people.ubuntu.com/~mvo/tmp/python-central_0.5.5ubuntu3.debdiff
<ogra> cbx33, i assume you dont have a menu.lst
<ogra> no idea what to do here 
<Mithrandir> doko_: sorry, no.
<Mithrandir> Kamion: yes, approved.
<cbx33> ogra: ok dude, not to worry
<cbx33> I'll have to do those updates at home....I'll install with a knot3 and do the updates
<cbx33> i was just wondering if you wanted more information in case it's a bug
<Mithrandir> Kamion: I'll do an upload of foomatic-db with the linuxprinting.org-ppds demoted to recommends.  Sounds fine?
<cbx33> ogra: it seems to have failed because of ltspfs and edubuntu-server
<cbx33> because they were'n't configuerd
<Kamion> Mithrandir: yeah
<cbx33> It gets to setting up grub......then errors encountered whilst processing ltspfs
<cbx33> and edubutnu-server
<Kamion> mvo: I don't get why that diff is needed
<Kamion> oh, old was None
<Kamion> mvo: if old is None: old = []  would be clearer, wouldn't it?
<Kamion> accepted, anyway
<doko_> Mithrandir, Kamion: not sure, if I need approval, like to upload a new python2.4 before the beta. upstream diff at http://people.ubuntu.com/~doko/p.diff
<Kamion> cbx33: right, the installer will get fairly hopelessly confused once something screws up in pkgsel
<mvo> Kamion: right, probably. I just modeled it after the available code (the one for supported and default)
<Kamion> a
<Kamion> ah
<cbx33> ah ok
<cbx33> anyway I can tel it to skip those 
<mvo> Kamion: but yeah, it would indeed be better :)
<cbx33> just so I can finish the installation?
<cbx33> would enable me to generate those patches I was on about a little quicker?
<Mithrandir> Kamion: re doko's python diff -- I don't know the code base well enough to be able to review the patch properly.  It doesn't _look_ too scary, though.  Ideas?
<Kamion> it should be in place for final, but I'd be inclined to defer it until after the beta unless there's a specific reason (i.e. a consequent beta-critical bug)
<Mithrandir> doko_: is there such a bug?
<Mithrandir> hmm, we seem to need a promotion of libvte2.0-cil to main.
<ogra> Kamion, oh crap, you are right, my install set usplash to 640x480 which i dont have artwork for ... :/
<cbx33> ogra: heh
<cbx33> am I screwed with this install
<cbx33> or can I enter the console and forge a few things?
<Kamion> ogra: IMO all usplash themes should provide a 640x480 version
<doko_> Kamion, Mithrandir: yes, there's another one: the patch for #56633 is included, but not applied
<ogra> Kamion, ok ... i just looked at xubuntu, they dont have one either ...
<cbx33> kubuntu doesn't either
<Kamion> because that bug isn't going to be fixed for beta now, I suspect, so upgraders from the beta willl get 640x480
<cbx33> or didn't
<Kamion> yes, last I checked all themes had this bug
<Kamion> it's still a bug :)
<cbx33> I based mine on kubuntu
<cbx33> ;)
<ogra> is it likely to be fixed in usplash ? 
<Kamion> ogra: it's an installer bug
<Kamion> yes, I have a plan to fix it
<ogra> or do we release with 640x480 
<cbx33> ;)
<Kamion> but upgraders will still get the old configuration file
<ogra> ah, fine then
<cbx33> ogra: that'd push our size up afgain
<Kamion> also I believe it only affects d-i installs
<cbx33> :S
<ogra> ok, i'll scale the image 
<ogra> cbx33, we have one or two meg ... if the kernel doenst grow or something evil happens, we'll be fine
<sladen> ogra: scaling is maybe not important, having usplash pick the largest that will fit and just plonking it in the middle would fix things acrossthe board
<cbx33> no imeant the .so size
<cbx33> you were concerned about size before
<cbx33> we don;t want to make it any bigger
<Kamion> Mithrandir: it's not in anastacia
<Kamion> (libvte2.0-cil)
<Kamion> sladen: that's what it does
<ogra> sladen, right ...
<Kamion> pretty much
<pitti> thom: here by chance?
<thom> pitti: yo
<Mithrandir> Kamion: weird.  It does make gnome-sharp2 uninstallable according to ~cjwatson/testing/edgy_probs, though
<ogra> sladen, but since thats not working yet, a smaller version will be fine as well 
<Kamion> sladen: the problem is that a complicated interaction with the installer means that d-i installs set up usplash.conf for 640x480 by default
<Kamion> sladen: so usplash can't find anything that fits
<Kamion> hmm
<sladen> Kamion: so usplash should go "ooh, 640x400 is <= 640x480", and stick it centred
<Kamion> sladen: I believe it does, but there's no 640x400 entry in the themes
<Kamion> we're not talking about the testcard here
<Mithrandir> dholbach,seb128: industrial-cursor-theme seems to need a MIR to make gtk2-engines-industrial installable again.
<sladen> ah, so the themes are failing to provide a lowest-common-denominator
<Kamion> right
<Kamion> Mithrandir: actually, anastacia wants to demote gnome-sharp2
<Kamion> I can do that now?
<Mithrandir> tseng: around?  Can we demote gnome-sharp2?
<ajmitch> it's not used by anything
<seb128> Mithrandir: we can change the Depends to a Recommends for now if you want?
<ajmitch> all the apps should use the -cil packages
<ajmitch> (about gnome-sharp2)
<Mithrandir> ajmitch: ok, lets demote it then.
<Mithrandir> Kamion: demote away. :-)
<ogra> dholbach, the jimmac cursor moved to human-cursors-theme, right ? 
<Mithrandir> seb128: that is fine with me, yes.
<Mithrandir> seb128: or a MIR; I don't care either way.
<seb128> Mithrandir: is that something that needs to be fixed quickly? the MIR is likely to be slower
<Kamion> demoted
<Mithrandir> seb128: nothing seems to depend on gtk2-engines-industrial, so it's not a blocker per se, but I'd like http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html to be empty for beta.
<Mithrandir> seb128: and it's showing up there..
<seb128> Mithrandir: ok, I will take care of it
<Mithrandir> seb128: thanks. :-9
<Mithrandir> s/9/)/
* Mithrandir should get a new keyboard soon -- this seems to be losing text.
* ajmitch sees mono on the edgy_probs list - I'd guess that we don't want firebird2 in main at this stage
<Mithrandir> dholbach: can you please do a new upload of libgnomeuimm2.6 since the previous version FTBFS-ed and infinity isn't around to give it back?
<dholbach> Mithrandir: same for opal, I suppose
<dholbach> Mithrandir: (and for ekiga some time later)
<Mithrandir> dholbach: yes, please.  And thanks.
<dholbach> Mithrandir: no problem
<ajmitch> sigh, firefox source package doesn't have binaries for the ldap sdk, not that it's a surprise
<ogra> dholbach, ^^^ ?
<ogra> hey sabdfl 
<cbx33> hi sabdfl 
<jsgotangco> hey sabdfl heh
<dholbach> ogra: it was just split out of ubuntu-artwork
<ogra> dholbach, so its in there ? 
<dholbach> ogra: it didn't change
<ogra> i just want to know where it is ;)
<ogra> split-> good :))
<ogra> i can bear the 19k ;)
<dholbach> :)
<_ion>  modified l-r-m to contain nvidia-beta in addition to nvidia and nvidia-legacy. Now it's easy to switch between the new beta driver (with AIGLX goodness) and the stable driver.
<_ion> +"I "
<Mithrandir> pitti: you get to write a MIR for libdbd-pg-perl. :-)  (nagios-pgsql depends on it and is uninstallable)
<pitti> heh, I wonder why we didn't need it earlier
<pitti> sure, no problem
<Mithrandir> yeah, and it's a useful package so I am at least happy to have it in main
<Mithrandir> hmm, rhythmbox-applet/music-applet; should it be in main?  It's not seeded, it seems.
<ogra> isnt RB's internal notification icon enough ? 
<HiddenWolf> ogra: music-applet puts some buttons directly on the panel, play/pause/forward/mute etc
<Mithrandir> well, r-a is in main, but is uninstallable ATM.
<ogra> HiddenWolf, i know
<ogra> HiddenWolf, but i'd still call it duplication
* Kamion has an idea for saving CD space
* ogra listens up :)
<Mithrandir> Kamion: oh?  Let me hear.
<Kamion> there are a bunch of udebs that are shipped on the CD but that are already in the d-i imag
<Kamion> e
<ogra> ohh :)
<Kamion> might not save very much though, so don't get your hopes up just yet
<Kamion> need to do some seed magic to exclude them
<Mithrandir> slomo_: rhythmbox-applet/music-applet; should music-applet be in main or not?  If so, why is it not seeded?
<Kamion> we'd be able to save more if there weren't a requirement established by past bug reports that the alternate install CD should be a repository you can mount on a server and netboot off
<Kamion> hmm, doesn't quite work right
<Kamion> libc6-udeb is resolved wrongly
<pitti> Mithrandir: libdbd-pg-perl looks good, feel free to have it promoted
<pitti> Mithrandir: I'm writing the report now
<Mithrandir> pitti: thanks.
<Mithrandir> Kamion: if you could promote libdbd-pg-perl when you have time, that'd be nice.
<Kamion> Mithrandir: done
<Mithrandir> thanks a lot
<pitti> Mithrandir: done
<pitti> Kamion: I'll move the report to 'approved' section then
<slomo_> Mithrandir: i have no idea about rhythmbox... ask seb128, he cares for it ;)
<Kamion> pitti: ok
<seb128> slomo_: music-applet is not rb specific ;)
<seb128> Mithrandir: any reason it should be to main?
<seb128> Mithrandir: rhythmbox has a notify icon and can be commanded from it
<slomo_> seb128: ah i see... but afaik all music players already have a notification area icon for this kind of stuff anyway
<seb128> right
<Mithrandir> seb128: : tfheen@golem ..0.9.2/aspell6.pt-20060906 > apt-cache show rhythmbox-applet| grep Section
<Mithrandir> Section: gnome
<Mithrandir> seb128: it already _is_ in main; I was wondering why.
<seb128> good question
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.1.23.diff - OK to upload? Most of it's d-i changes. Unfortunately I'm unable to test the ubiquity change at the moment due to my vmware installation being in a different house and off the network, but I know the current situation doesn't work (it was an erratum in a previous Knot)
<Kamion> I'm pretty sure that moving the configuration file aside will "fix" console-setup to make it behave as if it were being configured in d-i
<Kamion> or otherwise from scratch
<Mithrandir> Kamion: ok, feel free to upload
<StevenK> Kamion: You've had to move some of your machines and not others? Bugger.
<Kamion> StevenK: right :(
<Kamion> I'm on a minimal working environment here until the ADSL is installed at the new place
<Kamion> router, server, and laptop
<Kamion> Mithrandir: thanks
<StevenK> Kamion: Ugh.
<Kamion> oh, and no desk
<StevenK> Just to make working more comfortable.
<cbx33> heheh
<cbx33> that sux Kamion 
<cbx33> hope the new place is nice ;)
<cbx33> we're going to look at a new place tonight......
<StevenK> Hrm. I'm trying to remember how long it took me for get ADSL at the new place.
<StevenK> I think it was a matter of 2 days or something.
<Lathiat> in .au it takes anywhere from 1-7 days
<Lathiat> in some cases longer
<cbx33> crikey
<ajmitch> that's pretty quick
<StevenK> I was moving within the same suburb, so I think it just a matter of moving one cable in the same exchange.
<Lathiat> StevenK: thats less of an issue as the fact it takes a while for telstra to get out to an exchange
<Lathiat> + the isps internal rpcoess etc
<Lathiat> it depends theres like a roster
<Lathiat> deends when you apply
<Lathiat> compared to when theyre going there
* StevenK nods.
<Lathiat> sometimes your lucky, sometimes your unlucky
<Lathiat> :)
<tseng> Mithrandir: hi
<Mithrandir> tseng: hiya; I think we resolved the problem (and ended up demoting gnome-sharp2)
<zul> heylo
<tseng> Mithrandir: yes, how does that seem to be a good idea?
<ajmitch> hi zul 
<tseng> Mithrandir: that would demote tomboy, f-spot
<Mithrandir> tseng: uh, don't they depend on the -cil packages?
<Mithrandir> tseng: I'm talking about the binary package, not the source.
<tseng> Mithrandir: OH
<Mithrandir> sorry about that being unclear. :-)
<tseng> Mithrandir: but they all rdepend on libgnome2.0-cil as well
<tseng> one second
<tseng> Mithrandir: you got it.. you can demote that
<Mithrandir> tseng: done already, but it's always nice to get confirmation that you didn't do something stupid. :-)
<slomo_> which problem was solved by demoting it to universe btw? :)
<tseng> Mithrandir: yeah, meta package, sorry for lack of alertness
<slomo_> it's only a metapacakge
<Mithrandir> slomo_: it was uninstallable since libvte2.0-cil is in universe.
<slomo_> ok
<seb128> Mithrandir: I don't get why rhythmbox-applet,music-applet are to main, they are not seeded and nothing Depends on it
<Mithrandir> seb128: maybe something used to depend on it?
<Mithrandir> seb128: anyway, if it shouldn't be in main, we'll just demote it.  It's not like it's hard to promote it later if we want that.
<seb128> right
<seb128> Mithrandir: http://people.ubuntu.com/~seb128/08_uuid_mount.patch ... would it be ok to upload?
<seb128> Mithrandir: that's a gnome-vfs patch to not duplicate devices and drives due to the new UUID format it doesn't understand
<seb128> Mithrandir: patch seems to work fine on my box and looks fine to pitti who had a look on it
<Kamion> music-applet is in universe actually, it's just the source that's in main
<Kamion> er, in fact not even that
<Mithrandir> Kamion: rhythmbox-applet is in main while the source is in universe, yes.
<Mithrandir> (renamed source)
<Kamion> for some reason the rhythmbox-applet binary is in main without its source - I guess it used to come from another source package
<Kamion> yea
<Kamion> yeah
<Mithrandir> seb128: ok, feel free.
<Kamion> demoted
<seb128> Mithrandir: thank you
<Tonio_> pitti: ping ?
<seb128> Tonio_: I think he's taking a break, maybe better to give some ping context so he can reply when he's back
<Tonio_> seb128: hehe yes :)
<Tonio_> seb128: another personn can revue main inclusion reports appart from him ?
<Kamion> pitti: don't you need to upload non-base language packs to match the -base ones?
<Kamion> pitti: all the language packs are uninstallable at the moment
<Tonio_> Kamion: just saw this yes....
<seb128> Tonio_: not sure, pitti does them usually
<Tonio_> seb128: okay I'll wait a bit, thanks for the info
<seb128> np
<pitti> Kamion: sure, they all need to be in sync
<pitti> Kamion: I asked to have all of them uploaded
<Kamion> pitti: where are they? I can upload them for you
<pitti> Kamion: I'll check with Celso
<Kamion> ok
<Mithrandir> Kamion: hmm, can you approve my foomatic-db upload, please?
<Kamion> Mithrandir: just did a few minutes ago
<Mithrandir> ok, thanks
<dholbach> Kamion: can you approve my opal and libgnomeuimm2.6 uploads? (mere rebuilds, that will make them build and installable again) - the deskbar-applet upload is not that important, and if we want the ubiquity-aware gnome-orca on the beta cd, you could approve that too :)
<bddebian> Howdy folks
<jdong__> does the GDM prefetcher thingie actually work in ubuntu?
<jdong__> /etc/X11/gdm/gdmprefetchlist
<jdong__> is that actually prefetched by GDM?
<doko_> Mithrandir, Kamion: we do want a python2.4 upload for the beta. please see chinstrap:~doko/python2.4
<ogra> Mithrandir, edubuntu-artwork uplaod ok with you ? 
<azeem> /W/ 5
<azeem> yay.
* thom blinks at azeem 
<bddebian> heh
* tseng winks at thom 
<bddebian> doko_: Have a sec by any chance?
<doko_> ?
<azeem> thom: sorry
<bddebian> doko_: I'm still trying to understand azureus a little and what your thoughts/concerns are
<jdong__> bddebian: wow, still working on azureus?
<bddebian> jdong__: Never really got a good start :-(
* jdong__ seriously underestimated the amount of work involved then :-/
<jdong__> bddebian: I personally thought taking our azureus package, replacing Azureus2.jar with 2.5.0.0's would've done the trick 
<jdong__> as thatI's what i am doing on my systems
<doko_> bddebian: what don't you understand?
<bddebian> doko_: The issue with the Debian package and using Redhat patches.  Is the major concern with the Debian package just that it uses a non-free compiler?
<doko_> bddebian: "just".
<jdong__> do we really need to compile azureus instead of shipping the jars?
<jdong__> azureus is virtually unusable with GCJ anyway
<jdong__> it's ridiculously slow, and once every 30 minutes it goes on a 3GB memory rampage
<doko_> bddebian: we are about free software; the Debian maintainer didn't look at the Fedora patches
<doko_> jdong__: it works on Fedora, why shouldn't it work on Ubuntu?
<jdong__> doko: have you tried it yourself under fedora? The last time I did, I was not impressed
<doko_> jdong: done with FC6t3. works for me.
<jdong__> ok, they must've fixed something since FC5's initial release then
<jdong__> back then it was terrible
<bddebian> doko_: Part of the problem is that I don't know RedHats package/patch "system" well enough to break it down :-(
<doko_> bddebian: what do you need to know? these are just diffs, already broken down
<tseng> bddebian: there are a gazillion patches in the top level source, and the spec file lists the ones to be applied in order
<bddebian> But the patches from their cvs doesn't have the actual source and I don't know where to get their "source" package from
<tseng> from their mirrors?
<bddebian> I don't freakin' use Redhat :)
<tseng> .srpm
<tseng> neither do it
<tseng> *I
<jdong__> bddebian: go onto a fedora mirror
<tseng> http://mirrors.kernel.org/fedora/core/development/source/SRPMS/
<tseng> you can unpack that with rpm or file-roller
<thom> rpm2cpio foo.srpm | cpio -i 
<jdong__> http://mirrors.kernel.org/fedora/extras/development/SRPMS/azureus-2.5.0.0-6.fc6.src.rpm
<thom> will give you a bunch of crap scattered over your current directory
<jdong__> it's in fedora extras
<jdong__> rpm -ivh it
<tseng> http://mirrors.kernel.org/fedora/extras/development/SRPMS/azureus-2.5.0.0-6.fc6.src.rpm
<realist> azuerus is a bloated pile of *expletives removed*
<jdong__> that splits out everything to /usr/src/redhat
<bddebian> I guess my question is, why the hell should I need to? :)
<jdong__> realist: please, cut that out... not necessary
<tseng> dont' rpm -i it that is the most assinine thing ever
<realist> jdong__: you said so yourself.
<tseng> bddebian: you don't, do what thom said
<jdong__> realist: no, that's a GCJ problem. with sun Java azureus stays well under 50Mb of memory usage for me
<realist> bddebian: there's no guarantee fedora's compile will work with debians jvm, is there?
<tseng> realist: no one is looking at fedoras "compile"
<tseng> realist: its a source package
<doko_> realist: why?
<mjr> jdong__, is that to say that azureus works with gcj nowadays?
<jdong__> mjr: yeah, it's supposed to
<jdong__> mjr: that's how fedora does it
<realist> tseng: someone asked if it "really" needed to be compiled
<jdong__> I asked that....
<mjr> well, nice that it isn't completely in the java trap anymore then, even if there's some memory issues...
<jdong__> mjr: I think the memory issue is resolved
<tseng> realist: i don't see the connection to redhat in that particular line of logic
<jdong__> mjr: I was going by my experience back when FC5 jusr released
<bddebian> Well apparently there is an issue with our monodevelop or something too, I have to get with welshbyte again about his issues
<tseng> bddebian: eh?
<realist> tseng: then why is everyone discussing FC5/6 etc?
<jdong__> tseng: I think he's saying azureus from fedora might not build successfully in a ubuntu build environment?
<tseng> realist: because they are looking for the patches in redhats source
<jdong__> realist: because we're stealing fedora sources?
<tseng> sigh
<bddebian> *SIGH*
<realist> jdong__: only if shipping a working/usable version under debian/ubuntu's GCJ is a _requirement_
<bddebian> tseng: I mean Eclipse, not mono sorry
<tseng> bddebian: oh
<realist> jdong__: not really theft?
<tseng> bddebian: thanks
<jdong__> realist: stealing being used affectionately in the OSS development way ;-)
<tseng> realist: please stop arguing silly things
<Mithrandir> ogra: edubuntu-artwork: fine
<Treenaks> 'Oh shit! Dat gebouw heeft een fundering, DAAR hadden we geen rekening mee gehouden, nu kost het graven 2 miljoen extra
<Treenaks> 'Shit! NOG zo'n gebouw!'
<Treenaks> etc.
<Treenaks> uhr
<ogra> Mithrandir, to late anyway, i'm impatient ;)
<realist> tseng: my intention is not to argue.
<Treenaks> (yay out-of-control building costs of the local metro line ;))
<thom> Treenaks: wrong window maybe? :-)
<tseng> realist: you started with an outright troll, and from there, you have questioned or argued every point. please stop now.
<Treenaks> thom: yes
<tseng> realist: (without reading and understanding completely)
<mvo> Mithrandir: http://people.ubuntu.com/~mvo/tmp/gnome-app-install_0.2.15.debdiff <- I would like to upload these changes + desktop file updates before the beta. is that ok? the most import fix is the one in Menu.py
<Treenaks> thom: related to a broken keyboard config (my right alt broke!)
<ogra> Kamion, i have hand copied some code in usplash-theme-edubuntu.c and added a 640x480 pic ... you probably want to grab that for ubuntu as quick interim for beta
<realist> tseng: perhaps you could correct me then?
<tseng> I have been, its tiring
<tseng> I am putting you on ignore now
<doko_> pitti: python2.4 update for dapper in chinstrap:~doko/python2.4
<realist> tseng: rather than discouraging me from participating.
<Kamion> dholbach: libgnomeuimm2.6 and opal done; gnome-orca is Mithrandir's decision
<dholbach> Kamion: gracias
<Mithrandir> mvo: ok.
<jdong__> bddebian: just for the fun of it I'll see if I can build the fedora sources on edgy :)
<Mithrandir> dholbach: gnome-orca is just a rebuild, right?  Have you tested it?
<dholbach> Mithrandir: I uploaded gnome-orca, which has an added script that enables it to work with ubiquity
<Kamion> ogra: I'd prefer it if somebody who normally does artwork did it
<ogra> ok
<Mithrandir> dholbach: while having that would be nice, I'm tempted to say "after beta".
<Kamion> although I do think that we should grab it
<ogra> i just wanted it "fixed" for edubuntu 
<dholbach> Mithrandir: ok
<ogra> but surely Seveas is the better bet for the code here
<bddebian> jdong__: Enjoy, my head exploded about 30 minutes ago :-)
<Seveas> ?
<Kamion> coo, soyuz queue ids just hit six digits
<ogra> Seveas, we need a 640x480 usplash theme 
<Kamion> Mithrandir: there's a gnome-vfs2 upload here too
<realist> jdong__: that's the spirit!
<Seveas> ogra, I know, have been awfully busy
<ogra> Seveas,  i created one by manually copying the 800x600 struct and adjusting the alues ... but thats surely not the proper way :)
<Seveas> ogra, actually, it is
<ogra> *values
<ogra> oh, ok
<Kamion> presumably you needed a 640x480 pixmap too
<Seveas> yeah
<Mithrandir> Kamion: gnome-vfs> approved, asssuming it's from seb and does UUID handling.
<mvo> thanks Mithrandir
<ogra> right ... i just scaled the indexed 800x600 which looks horrible
<Seveas> I hope mjg59 wakes up one of these days, I want to change something in usplash to save a few MB on live filesystems
* sladen slams head against wall
<Seveas> ogra, scaling while preserving the colormap?
<ogra> sladen, ?
<ogra> Seveas, right
<ogra> you can imagine the uglyness :)
<Mithrandir> Seveas: oh, what?
<Seveas> not really
<sladen> ogra: when a file is already anti-aliased, it's not that ugly
<Kamion> Mithrandir: correct
<ogra> sladen, if its indexed .... 
<Kamion> (bug 57701)
<Ubugtu> Malone bug 57701 in gnome-vfs "[edgy]  gnome shows duplicated mounts" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57701
<sladen> ogra: when a file is already anti-aliased and has an indexed palette, it's not that ugly
<Mithrandir> Kamion: yeah, that's the one.
<Seveas> Mithrandir, storing the artwork.so bzipped and letting usplash_down and the initramfs creation hook extract it. example ubuntu theme goes from 2 mb to 45k
<ogra> sladen, well, i assume our images are anti-aliased ...
<Seveas> when the animations, which the art team worked on, are going to be used, this really becomes neccessary
<sladen> Seveas: the initramfs is already gzip compressed
<ogra> sladen, i would have to convert them back and forth 
<Mithrandir> Seveas: it doesn't really matter, since the livefs is compressed.
<ogra> indexed->RGB->scale->indexed
<sladen> ogra: only ever do the conversion *once*
<Seveas> sladen, that's why I said initramfs creation hook ;) the artwork.so is still uncompressed on the filesystem
<Mithrandir> Seveas: gzip -9 (which isn't too far from what squashfs gives us) reduces usplash-theme-ubuntu to about 59k.
<Seveas> Mithrandir, ah ok, that rules that out
<Mithrandir> Seveas: nice idea, though. :-)
<ogra> sladen, but i was promised to get a proper pic after beta anyway ... as interim its better than a black screen ;)
<Seveas> (this is exactly why I wanted to talk to $someone_with_more_brains before hacking on it ;))
<sladen> ogra: just use the gimp and do a linear scale in indexed-mode
<ogra> didnt work, thats exactly what i did
<sladen> ogra: excellent.  no converstion
<sladen> ogra: s/conversation/conversion/
<ogra> well, the screen looks horrible :)
<ogra> but i dont care ... i'll get proper pics later .... *shrug* 
<jdong__> bddebian: well, first round through, only about 5000 build errors :)
<bddebian> hehe
<jdong__> bddebian: whoo! down to 16 :)
<pygi> jdong: nice ^_^
<jdong__> anyone here know much about SWT?
<jdong__> I'm getting random SWT errors here
<jdong__> i suspect it's because SWT 3.1 is not new enough
<tkamppeter> pitti, mdz, doko_: I am uploading a new foomatic-db currently, with linuxprinting.org-ppds split, so that only the most important pPDs get onto the CD, and OpenOffice.org can stay.
<jdong__> Fedora builds against SWT 3.2
<pygi> jdong: cant we get swt 3.2?
<jdong__> pygi: I'd imagine so?
<doko_> tkamppeter: "OpenOffice.org can stay"? lol ...
<jdong__> SWT.Settings
<jdong__> not defined?
<Mithrandir> tkamppeter: how big is the new -ppds package?
<tkamppeter> foomatic-db: 580KB, linuxprinting.org-ppds: 3577KB, linuxprinting.org-ppds-extra: 10MB.
<jdong__> bddebian: so far the build looks very straightforward... minus these SWT failures
<jdong__> bddebian: the spec file is virtually an instruction book for building :0
<Mithrandir> tkamppeter: let's take a look at this after beta.
<tkamppeter> I have split off all PPDs from Ricoh and partners and all non-english PPDs from Kyocera, Kyocera were the only ones who have delivered translated PPDs.
<bddebian> jdong__: SWT becomes the problem with Eclipse vs swt Debian pacakages iirc
<doko_> Mithrandir: err, currently it's *bigger* 
<jdong__> bddebian: I'm gonna be unholy, and just download azureus.sf.net's bundled jars and see if I can build against them
<jdong__> bddebian: would doing so make the package unsuitable for universe?
<tkamppeter> Download address for everyone interested, as usual: http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
<jdong__> well let's try it as an experiment... see if swt 3.2 is really to blame
<bddebian> jdong__: We can always just blame doko_ ;-P
<jdong__> bddebian: alternate approach: swt-gtk 3.2 is in debian sid... I'll just build a quick deb of it
<jdong__> bddebian: meanwhile, how about a sync of that to edgy? :)
<bddebian> jdong__:  I think you will get conflicts with Eclipse?
<doko_> jdong__: it won't help for an upload.
<bddebian> doko_: Should it be built with Eclipse?
<doko_> bddebian: once eclipse-3.2 is in the archive, yes.
<bddebian> doko_: Well get on it..
* bddebian ducks
<jdong__> lol
<jdong__> so hold azureus until then, I guess
* jdong__ still tries building against prepared swt 3.2 jars, for fun
<Mithrandir> doko_: no, currently it just recommends -ppds
<doko_> Mithrandir, Kamion: you'll get another 8MB on the CD, currently checking ...
<Kamion> and it probably still should - from what I understand, it should be seeded when we want it, not be a depends of foomatic-db
* ogra listens up 8MB ???
<jdong__> doko, bddebian: builds cleanly with azureus's provided swt.jar.... which is just 3.2... so we need swt 3.2 :)
<Kamion> ogra: you really need to relax sometimes ;)
<ogra> Kamion, my CDs are so beautiful in shape atm :) 
<tseng> ogra: rock
<Mithrandir> doko_: 8MB from what?
* jdong|laptop gives up on azureus again
<jdong|laptop> damn plugins fail to build
* jdong|laptop hands job back to bddebian :)
* bddebian runs away
<jdong|laptop> come back you!
<jdong|laptop> but seriously, it doesn't look all that bad
<jdong|laptop> just my java knowledge is virtually zip
<jdong|laptop> especially when it comes to all this swt stuff
<jdong|laptop> maybe we should be starting with like FC5 srpms instead
<jdong|laptop> which I hope are still against swt 3.1.1
<bddebian> jdong|laptop: Well I have none either.  And I still don't know how to/don't know if I want to get source rpms
<jdong|laptop> bddebian: install the rpm package, and file-roller unpacks them just fine
<jdong|laptop> all the patches, sources, and the build script will be in one directory
<bddebian> Install what rpm package?
<jdong|laptop> follow the patching order as specified in the spec file
<jdong|laptop> bddebian: apt-get install rpm
<jdong|laptop> that gets you the rpm2cpio command for extracting rpms
<bddebian> Aye, I'm talking about the rpm itself :)
<jdong|laptop> bddebian: I put a link to the fc6 srpm a while up
<jdong|laptop> http://mirrors.kernel.org/fedora/extras/development/SRPMS/
<jdong|laptop> BenC: poke?
<Trewas> jdong|laptop: btw fedora has some "inside knowledge" on azureus as green_ from redhat did the required work on fixing both azureus and gcj to work together
<jdong|laptop> Trewas: well hopefully all the gcj magic got back upstream and more imprtantly to us :)
<jdong|laptop> right now I'm pretty sure the fact the plugins don't build is a matter of me sucking at getting jars together
<mdz> good morning
<jdong|laptop> morning, mdz :)
<ogra> morning mdeslaur 
<ogra> bah
<ogra> mdz
<mdz> seb128: gnome-python split -> let's wait until after beta
<mdz> tkamppeter: re: foomatic-db, let's talk about it first
<mvo> good morning mdz
<seb128> mdz: ok
<doko_> Mithrandir: OOo dependencies
<seb128> morning mdz ;)
<pitti> hey mdz
<BenC> jdong: hey, haven't had a chance to look at that bug report yet...I need to get this jmicron stuff done
<jdong|laptop> BenC: k, do that first :0
<jdong|laptop> :0
<jdong|laptop> stupid shift key
<seb128> BenC: do you require any debug information for bug #62215?
<Ubugtu> Malone bug 62215 in linux-source-2.6.17 "2.6.17-9.23 regression: crash at boot (amd64)" [High,Unconfirmed]  http://launchpad.net/bugs/62215
<bddebian> Heya mdz
<jdong|laptop> hmm, is it just me or is ff 2.0b2 really crashy?
<jdong|laptop> at least the ubuntu package
<pitti> it works perfectly for me
<pitti> but I only have few extensions
<jdong|laptop> I have a clean profile here, too
<jdong|laptop> I am suspecting nvidia drivers might be a part of the issue
<jdong|laptop> as it works fine on my two other laptops, too
<pitti> jdong|laptop: I use nvidia here, too
<jdong|laptop> weird
<jdong|laptop> heck right now gmail makes it crash
<jdong|laptop> The program 'Gecko' received an X Window System error.
<tkamppeter> mdz, have you looked into my uploaded foomatic-db files? Is the splitting OK, or do I need to split off more?
<BenC> seb128: No, I have that fixed
<Kamion> Riddell: do you know why bug 61710 is assigned to you? it seems a bit odd to assign a GTK frontend bug to you
<Ubugtu> Malone bug 61710 in ubiquity "Selected keyboard layout is not visible on-screen" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61710
<BenC> seb128: Uploading tonight to fix it, but I need to get jmicron working too
<BenC> and ich8
<seb128> BenC: ok, nice
<BenC> jmicron sent me an eval board, and it's not cooperating
<BenC> I may have to beat it into submission
<jdong|laptop> hehe
* jdong|laptop wishes BenC luck
<Riddell> Kamion: no idea
<mdz> tkamppeter: I haven't, no.  I just got to the office
<jdong|laptop> thousands of people with too much money^H^H^H^H core 2 duos are counting on you , benc :)
<iwj> janimo, dholbach: I'll deal with Frank's new theme package, unless one of you is already on the case.
<mdz> tkamppeter: I'm not sure about the idea of shipping fewer drivers; what happens if a user connects a printer which isn't supported by the default set of drivers?
<dholbach> iwj: super, thanks.
<mdz> tkamppeter: I don't think we have the infrastructure to lead them to install the package yet
<Kamion> mdz: hmm, apparently you assigned 61710 to Riddell?
<ogra> iwj, does that induce any work for me i edubuntu ? 
<ogra> *in
<mdz> bug 61710
<Ubugtu> Malone bug 61710 in ubiquity "Selected keyboard layout is not visible on-screen" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61710
<mdz> Kamion: yes, I only noticed it in the KDE frontend
<ogra> doko_, i have a broken alternative in  a fresh install ...
<ogra> doko_, 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 | 6.06.1 released | Beta Freeze in effect
<ogra> ergh
<Riddell> oh, because united states is at the end of the list
* ogra kicks xchat
<ogra> doko_, lrwxrwxrwx 1 root root 43 2006-09-25 04:00 /etc/alternatives/keytool.1.gz -> /usr/lib/jvm/java-gcj/man/man1/keytool.1.gz
<Riddell> so how does gtk get around that?  u will always be near the end
<doko_> ogra: yes, known
<ogra> oki
<Kamion> mdz: oh!
<Kamion> mdz: that was not at all clear from the bug
<mdz> Kamion: yes, I see that now
<Kamion> I've clarified
<mdz> as have I
<Kamion> Riddell: I do scroll_to_cell in the gtk frontend to force it to move to near the selected item
<iwj> ogra: I don't think so.  Why might it ?
<Riddell> Kamion: right, I'll look into that
<ogra> iwj, i mean, does it enable themeing for us via the -artwork package 
<ogra> ?
<ogra> (which would mean i'd try to have a gartoon theme ready after beta
<ogra> )
<iwj> ogra: Err, you mean, does it move the default theme selection into ubuntu-artwork ?
<ogra> well, your last statement was that its hardcoded in ff 
<ogra> so i gave up trying to have a replacement theme for gartoon
<iwj> What is gartoon ?
<kristog> an icon theme
<kristog> afaik
<ogra> iwj, the theme edubuntu uses
<iwj> Aha.
<iwj> It's not hardcoded in ff any more.  The switch was going to be moved to ubuntu-artwork but it seems still to be in firefox-themes-ubuntu.
<ogra> so i could make a firefox-themes-edubuntu package that replaces this one ? 
<ogra> and adds the proper default icons ...
<iwj> Yes.
<iwj> I assume you mean `replaces' rather than `Replaces:'.
<iwj> It might be easier to modify the firefox-themes-ubuntu source to generate the other binary you want.
<iwj> I don't know how the theme generation actually works - there's a bunch of php written by Frank.  You might want to talk to him about what you're trying to do.
<iwj> Or feel free to arrange an ircmeeting with all three of us.
<iwj> ogra: The bzr is http://bazaar.launchpad.net/~ubuntu-art-pkg/firefox-themes-ubuntu/ubuntu if you want to take a look.
<ogra> iwj, ta :)
<Kamion> Riddell: ensureItemVisible() seems to be the QListView equivalent of GTK's scroll_to_cell()
<Kamion> http://doc.trolltech.com/3.3/qlistview.html#ensureItemVisible
<Kamion> so it should be a one-liner to fix
<tkamppeter> mdz, if a user connects a printer whose PPD file we do not ship, the printer is set up with a generic PostScript PPD file if it is in the Foomatic database. If it is not in the Foomatic database, it is shown as unknown.
<tkamppeter> mdz, what do you mean with "I don't think we have the infrastructure to lead them to install the package yet"?
<mdz> tkamppeter: it is worth the extra disk space to have it work out of the box; later on we can consider fetching extra driver packages automatically from the network if we need the space
<Viper550> I saw that Usplash theme on Xubuntu
<tkamppeter> mdz, WDYT what is best:
<tkamppeter> 1. No PPDs on CD, all of them in linuxprinting.org-ppds in Universe?
<tkamppeter> 2. All PPDs in the package linuxprinting.org-ppds on the CD and removing apps to gain space?
<tkamppeter> 3. Splitting linuxprinting.org-ppds (as I did now) and having the PPDs for most common printers on the CD and the less common in universe?
<ogra> s/universe/main/ ?
<tkamppeter> ogra, there are programs in main which are not on the CD?
<ogra> sure, tons
<tkamppeter> Then the PPDs which do not fit onto the CDs should at least be in main.
<ogra> right
<elmo> mvo: can I reboot davis?
<tkamppeter> Someone told that currently linuxprinting.org-ppds is in universe? This is strange, should it not be in main then?
<ogra> nobody wrote a main inclusion report yet i guess
<mdz> tkamppeter: I haven't reviewed the situation with CD space, but drivers are low on the list of things to remove to make space
<mdz> tkamppeter: SeedManagement in the wiki explains some; also UbuntuMainInclusionQueue
<mdz> tkamppeter: if the package is just a split of existing data and doesn't introduce anything new, then it can move into main quickly
<ogra> (but please dont make the CDs grow ... edubuntu is at the edge)
<mvo> elmo: yes
<Kamion> ogra: that's why it should be an explicit entry in the desktop seed, rather than pulled in by a dependency; that way you can just exclude it from edubuntu-desktop if that's the right thing to do
<ogra> i'll wait for the final beta isos and see :)
<tkamppeter> mdz: foomatic-db was always on the CD, linuxprinting.org-ppds was not on the CD, and people complained about missing PPDs.
<ogra> i386 says 699M on the cdimage website ... by experience that can go up to 702M before it breaks ...
<tkamppeter> linuxprinting.org-ppds is generated from the same source package as foomatic-db
<tkamppeter> I do not really know whether linuxprinting.org-ppds is in main or in universe, but for many PostScript printers it ships the manufacturer-supplied PPDs to make all the printer's functionality working. So it could be considered as a driver package.
<mdz> ogra: it's broken when it says .OVERSIZED ;-)
<ogra> haha
<ogra> i'll regard that :)
<mdz> tkamppeter: ok, so it is not a new package, but one which we have never shipped on the CD
<ogra> and if its from foomatic-db source it likely has a MIR already
<Kamion> there's no problem promoting binaries from source that's already in main
<Kamion> I've promoted linuxprinting.org-ppds; it'll appear in main when the next publisher run finishes, in about an hour
<tkamppeter> What is a MIR?
<tkamppeter> Thanks, Kamion, for promoting the PPDs to main.
<ogra> tkamppeter, short for main inclusion report
<Kamion> main inclusion report; see http://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<Kamion> formalisation of the earlier casual process that went "hmm, yeah, I guess we can/should support this one"
<Kamion> tkamppeter: please take care not to restore the dependency of foomatic-db on linuxprinting.org-ppds, though
<Kamion> at the very least, not before beta
<tkamppeter> My proposed foomatic-db with linuxprinting.org-ppds split does not introduce this dependency.
<Kamion> ok, good
<neutrinomass> I hope this isn't offtopic: I've noticed a large number of access() system calls to check for the existence of /etc/ld.nohwcap.so, which doesn't exist. Although these aren't (according to strace anyway) time-consuming, couldn't they be avoided (given that one check is enough, and that it doesn't exist anyway) ? 
<neutrinomass> Um, it's /etc/ld.so.nohwcap actually 
<doko_> Kamion: please really consider the python2.4 changes for the beta
<jdong> BenC: quick question poke
<BenC> jdong: shoot
<jdong> BenC: usb-storage, the max_sectors_128 blacklist, is that what unusual-devs is?
<jdong> I think I got another device here that needs the 128 sector workaround
<jdong> (read: I think I might be solving my bug report)
<BenC> jdong: unusual-devs handles a lot of quirks, like maxsectors_128
<jdong> BenC: what advantage does the default 240 for maxsectors have over 128?
<jdong> I've barely seen a performance difference between the two
<BenC> jdong: usually, not much
<jdong> BenC: why do we go with 240 instead of 128 as the default then?
<BenC> if the device falls into that category, then technically, there's difference :)
<BenC> jdong: for large high-speed USB devices, it gains performance
<jdong> hmm, ok
<jdong> well, I've got a usb device here that needs the max sectors 128 workaround
<jdong> BenC: what info would you need in my bug report to add my device to the unusual-devs list
<BenC> jdong: lsusb -v output
<jdong> BenC: will do, and I'll tack it on to that bug report, and let you get to that when you get your other stuff done :)
<jdong> BenC: and would this kind of bugfix be suitable for backporting to dapper?
<BenC> jdong: yeah
<yveslu> good evening, no news about this very very low hanging performance-fruit: :-) https://launchpad.net/products/fontconfig/+ticket/1773
<thom> yveslu: it's long after upstream version freeze for edgy, fontconfig is right at the bottom of the desktop stack, there's no telling how much time and effort would be needed to integrate a new version
<rodarvus> yveslu: as thom said, unfortunately there is *no* chance fontconfig will be updated to 2.4 on edgy timeframe
<yveslu> thom: ok, I see ur point... I can only mention that in sid the upgrade was seemless, as 2.4 is abi and api compatible to 2.3, thus no rebuilt of other packages which depend of fontconfig was necessary, maybe this information can be useful for edgy+1 for you guys :-)
<jdong> BenC: I've uploaded my lsusb to bug 61235....
<Ubugtu> Malone bug 61235 in linux-source-2.6.17 "USB mass storage stops working after a while" [Untriaged,Confirmed]  http://launchpad.net/bugs/61235
<rodarvus> yveslu: we understand, but fontconfig is a very basic package. thousands (literally) of packages depend on it, directly or indirectly
<yveslu> and... thanks for ubuntu! nice evening!
<rodarvus> *any* regression would be fatal
<rodarvus> but you can rest assured edgy+1 will have it quite quickly  ;)
<yveslu> great :). at this place I have also to express all my respect to the ubuntu devs for their work. the pace of bugfixing and new feature-adding is astonishing!
<mvo> Mithrandir: I just uploaded a new gnome-app-install. mostly desktop file changes and stuff from the CommonCustomizations spec. I showed the actual code changes (~4 lines)  to you this afternoon
<Mithrandir> mvo: 'k.  
<mvo> thanks
<mdz> Mithrandir: the CD health check is pretty lengthy.  how many of those are still issues?
<Mithrandir> mdz: the language packs were downloaded hours ago, I thought.  I think that fixes the kde-i18n ones too which leaves us with a couple of uninstallables.
<mdz> Mithrandir: is the script set up to publish more up-to-date output somewhere?
<mdz> the latest one i have shows a whole slew of uninstallables
<Mithrandir> mdz: the uninstallable is just a dump of http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html, afaik
<Mithrandir> mdz: I think the langpacks are either waiting for approval or something happened to the upload.
<Mithrandir> cprov: you uploaded all the langpacks, didn't you?
<cprov> Mithrandir: i did, this morning
<mdz> there are a couple of language-support uploads waiting for approval, but no langpacks
<Mithrandir> mdz: seems to be in needs-build
<Mithrandir> (at least language-pack-xh)
<mdz> eek, 523 pending builds
<Mithrandir> mdz: uh, the buildds are unhappy. NOT OK : <socket.error instance at 0x2aaab17c7680> (AUTO)
<mdz> and zero in Building
<Mithrandir> cprov: ^^ any idea about that?
<mdz> cprov: help
<elmo> I'll fix them
<cprov> Mithrandir: mdz: I don't have login to the buildds.
<cprov> elmo: ahh, you have, thanks ;)
<elmo> cprov: don't be obtuse, you don't need a login
<elmo> it's administered through the web interface
<cprov> elmo: I'm assuming you already tried to to what you are enable to.
<mdz> Mithrandir: do you have access to check the output from the livefs builds and trigger new ones?
<Mithrandir> mdz: yes.
<Mithrandir> mdz: I can build new ones when *-desktop looks installable again.
<mdz> ok, good
<Mithrandir> assuming we get the right langpacks built before the hour, I can do it in about an hour, I think.
<mdz> language packs are building now
<mdz> thanks elmo, cprov
<Keybuk> mdz: beta-blocker or not?  bug #62189
<Ubugtu> Malone bug 62189 in upstart "Typing Exit at Emergency Root Term does Nothing" [Untriaged,Confirmed]  http://launchpad.net/bugs/62189
<mdz> Keybuk: not a blocker but if it's low-risk to fix, I think it'd be worthwhile
<Keybuk> yeah, it's an easy enough fix
<tseng> Keybuk: do you have buildd powers?
<tseng> Keybuk: i know its a bad time but ive been trying to get infinity to clear beagle chroot problems and he is clearly not around
<Keybuk> tseng: what do you mean by "clear beagle chroot" ?
<tseng> Keybuk: build failure logged as "CHROOT PROBLEM"
<Keybuk> that implies that there's a chroot problem
<Keybuk> E: Some index files failed to download, they have been ignored, or old ones used instead.
<Keybuk> hmm
<tseng> Failed to fetch http://ftpmaster.internal/ubuntu/dists/edgy/main/binary-powerpc/Packages.bz2  MD5Sum mismatch
<Keybuk> Failed to fetch http://ftpmaster.internal/ubuntu/dists/edgy/main/binary-ia64/Packages.bz2  MD5Sum mismatch
<Keybuk> yaeh
<tseng> this was the problem.
<Keybuk> LP bug that this is considered a chroot problem, I suspect
<tseng> but its been stuck for some time
<Keybuk> it may not be clearable
<tseng> new upload?
<Keybuk> I certainly can't
<tseng> ok, thanks for looking
<Keybuk> you may need a rubber duck
<elmo> I don't think you need a rubber duck, just someone with privs to reset builds - I don't know where that is in the web UI thought
<Keybuk> I have the privs to reset builds
<Keybuk> and I don't have a "Reset build" for that case
<elmo> Keybuk: what UI?
<elmo> URL
<Keybuk> https://launchpad.net/+builds/+build/247137
<Keybuk> Normally there's a "+ Reset Build" in the "Build details" portlet
<elmo> I don't have one either
<Keybuk> https://launchpad.net/+builds/+build/247137/+reset sez "Build can not be reset"
<elmo> which means soyuz apparently won't let you in this case, which is pretty special
<Keybuk> it may be that LP just cannot get out of this situation
<ivoks> Keybuk: you needed me? i'm aware of libburn mistakes and sorry for that
<elmo> I don't see why not, giving a build back is the same thing in any case
<Keybuk> new package or chroot upload
<tseng> new package is fine
<elmo> (it deletes the build record [sic] )
<Keybuk> ivoks: if you know the mistakes, and can fix them, then I don't need you ;)
<Keybuk> elmo: indeed
<ivoks> Keybuk: i will, tonight
<elmo> filed as 62335
<tseng> thanks elmo 
<bluefoxicy> Question.
<bluefoxicy> LZO Layer FS has no real license statement, it just says something like "Copyrights reserved blah blah blah"
<bluefoxicy> it uses liblzo2-2, which is licensed under the GPL
<Keybuk> bluefoxicy: then LZO Layer FS has no licence
<Mithrandir> bluefoxicy: then it's undistributable.
<Keybuk> contact the original author to purchase a copyright licence from them
<Keybuk> or prod them gently to include the licence they probably intended in their next tarball
<bluefoxicy> does this thus require LZOlayerFS to be licensed under GPL?  (this is TrollTech's approach-- if you write a Qt app and try to not GPL it they try to sue you; but I think that's unenforcable because I can hypothetically produce a situation in which you would not be using the GPL'd Qt, which should knock this notion over in court)
<Keybuk> bluefoxicy: varies depending on author opinion
<Keybuk> contact authors of liblzo2-2 for their opinion
<Keybuk> a safe option is assuming "yes, it requires that the linking program be GPL"
<bluefoxicy> Keybuk:  Nods.  I'm actually about to send off an e-mail asking for GPL, LGPL, or BSD/MIT, since he doesn't seem to have any particular reason to want to hang onto the code
<bluefoxicy> (I want to make /tmp lzo compressed eventually >:D)
<bluefoxicy> (yes it works, I tried)
<tseng> sounds less than useful
<bluefoxicy> tseng:  I crunched /tmp from 8.4 megs to 3.8 megs *shrug*
<Keybuk> bluefoxicy: freak ;)
<bluefoxicy> oh right, it links with zlib too, which is lgpl last I looked :)
<Keybuk> zlib is not LGPL
<bluefoxicy> it's not?
<Keybuk> no
* bluefoxicy hunts for the copyright.
<Keybuk> it's vaguely BSD
<jdub> bluefoxicy: /tmp is often assumed to be fast disk or ram; compressing it is not the best of ideas
<bluefoxicy> oh right, it has its own license, forgot
<bluefoxicy> jdub:  it's block based and pretty fast.  My /tmp seems to be full of stuff Firefox has downloaded for me; a couple pipe files; packages I'm working on; and the like
<Tonio_> Mithrandir: ping ?
<keescook> wow.  nothing is quite as much fun as hunting down memory corruption bugs in a lisp interpreter.  ;)
<Mithrandir> Tonio_: pong
<micahcowan> keescook, :(   which one?
<keescook> bug 62309
<Ubugtu> Malone bug 62309 in abuse-sdl "abuse segfaults if SIGINT is raised" [Low,Unconfirmed]  http://launchpad.net/bugs/62309
<keescook> abuse has a built-in lisp engine.  yeow
<Tonio_> Mithrandir: just saw kdebase 0ubuntu27 needs approval to get in. the latest version of the patch updated resolves a bunch of critical issues in the media ioslave management
<Tonio_> Mithrandir: any chance you approve it ?
<bluefoxicy> jdub:  (where "pretty fast" ~= "1/6 the speed" but I'm getting 10 megs a second instead of 45 ;)
<micahcowan> keescook, I seem to remember that. Yowza.
<Mithrandir> Tonio_: I need to see a debdiff before I can answer that question.
<doko_> Mithrandir, Kamion: the 8MB can be saved by dropping libgcj7-jar from the CD
<Tonio_> Mithrandir: yes sure
<Mithrandir> doko_: it's not needed any more?
<Mithrandir> doko_: java-gcj-compat seems to still depend on it?
<doko_> Mithrandir: the only java application on the CD is OOo, which works fine without it.
<Mithrandir> doko_: well, we can't drop it as long as java-gcj-compat pulls it back in.
<doko_> yes, therefore my java-gcj-compat upload (which maybe not enough). what I need to do is to remove the java-gcj-compat dependencies from all *-java packages on the CD
<Mithrandir> doko_: oh?  Why shouldn't, say, libhsqldb-java depend on java-gcj-compat any more?
<Mithrandir> (or did I misunderstand you?
<Mithrandir> )
<jdong> uhh, is it just me, or is knot3 alternate i386 a bit oversized?
<jdong> 702MB?
<doko_> Mithrandir: yes, java-gcj-compat is uploaded, dropping the dependency. that's a bit ugly, because we have some dangling symlinks in java-gcj-compat, but works for OOo
<Mithrandir> jdong: 700 MB CDs are slightly bigger than 700 MB.
<jdong> Mithrandir: ok, I'll take your word for it
<doko_> Mithrandir: because it's just a library, not an application. there was a discussion on debian-java to remove all these depencies for packages which just have a library.
<doko_> Mithrandir: if you like it better, I could replace java-gcj-compat with gij-4.1 for these cases
<Mithrandir> doko_: ok; can we wait with this new world order until after beta?  I'm fine with dropping the -jar dependency, but let's not shuffle all the java packages around.
<doko_> Mithrandir: fine with me, just tought in the case for problems with CD size
<doko_> s/tought/thought/
<doko_> Mithrandir: and please, really consider the uploaded python2.4 for the beta
<Mithrandir> doko_: let's see how it works out size-wise first and go from there?
<Mithrandir> doko_: do you have a debdiff somewhere?
<Tonio_> Mithrandir: here is the debdiff http://paste.tonio.homelinux.org/17
<doko_> Mithrandir: yes, already mentioned. chinstrap:~doko/python2.4
<doko_> Mithrandir: the file p.diff are the upstream changes (the diff for the svn-updates diff is a bit unreadable)
<Mithrandir> Tonio_: Riddell is happy with this?  It looks ok to me, but I don't know the kdebase codebase.
<Mithrandir> doko_: are there any of the upstream fixes there we really want?  I don't see a point in the win32 fixes, for instance?
<Tonio_> Mithrandir: yes Riddell asked me to upload this since he can't in dublin...
<Mithrandir> Tonio_: ok; approved then.
<Tonio_> Mithrandir: thanks
<Mithrandir> Keybuk: can you approve kdebase 4:3.5.4-0ubuntu27, please?
<mdz> jdong: the CD building scripts have a check for the appropriate size and output a .OVERSIZED file if it's too big
<doko_> Mithrandir: it's harmless. it's inside "#ifdef MS_WINDOWS", we want all the other patches
<Amaranth> Oh damn, I just missed the deadline to request sponsorship for mountain view. :/
<jdub> Keybuk: *headsmack* http://fedoraproject.org/wiki/FCNewInit
<Amaranth> If I were to add myself to the list now would it be ignored?
<Keybuk> jdub: ?
<Keybuk> oh, distrowatch and their UP TO THE MINUTE reporting
<Keybuk> note the URL of the mail
<Keybuk> https://www.redhat.com/archives/fedora-devel-list/2005-June/msg01390.html
<jdub> ha ha
<jdub> updated last month, too
<jdub> to note upstart
<Keybuk> yeah, the update last month was just adding a link to upstart as a consideration
<jdub> and that's it
<jdub> worth replying on sounder to mention that
<Keybuk> yeah, will do
<Keybuk> Mithrandir: I don't see a kdebase to approve
<ajmitch> morning
<bluefoxicy> /dev/loop0: [f6a0] :-1208031192 () offset -1208141016, xor encryption  <-- what the crap is this?
<Keybuk> sfllaw: which ubuntu-devel-announce post do you want approved?
* Keybuk guesses the one from your ubuntu address
<sfllaw> Keybuk: Yeah.  My e-mail client got confused.
<Tonio_> pitti: just pinging for https://wiki.ubuntu.com/MainInclusionReportDigikam
<Tonio_> pitti: would be nice if beta or RC could be shiped with digikam to get feedback :)
<Keybuk> Tonio_: beta freeze has already passed
<bluefoxicy> holy shit
<bluefoxicy> I can't believe that worked.
* bluefoxicy tries to make it not work.
<Tonio_> Keybuk: okay, so let's focus on it in rc :)
<ajmitch> Keybuk: fwiw, I'm trying to hack in selinux support into upstart - putting it in init/main.c doesn't really feel like the right place for it, where do you suggest?
<Mithrandir> mdz: the uninstallable count seems to be improving at about 200 packages an hour, but it's getting late here, so I'll be off for a bit of sleep for a fresh start tomorrow rather than sitting up all night.
<bluefoxicy> (security/selinux.c and then hook into other places...?)
<ajmitch> bluefoxicy: in upstart..
<Keybuk> ajmitch: what kind of support does selinux need?
<bluefoxicy> ajmitch:  I heard, I was making a suggestion, i.e. keep the support functions separated out and call them from some other code
<ajmitch> just loading the policy
<ajmitch> the sysvinit patch was basically one load_policy function & the makefile hacks to link to the lib
* bluefoxicy shrugs and goes back to doing unuseful but amusing things
<Keybuk> what does the policy do?
<Keybuk> and what effect does loading the policy have?
<ajmitch> loading the policy puts it into the kernel & affects all programs subsequently executed, all file accesses, etc
<ajmitch> it was done in sysvinit so that the programs init spawns run with the right security context
<Keybuk> could it not be loaded by a separate program that init invokves?
<Keybuk> or does it have to be loaded by process #1 ?
<ajmitch> afaik it should be loaded by init, but I'll check whether it's possible to set the context of init separately
<Keybuk> it sounds like it's appropriate to do it in init/main.c; probably after the console has been reset, but before the signals are established?
<Keybuk> if it's more than one function call, create a static function in that file
<ajmitch> it's 1 static function in there at the moment
<ajmitch> porting from the sysvinit patch
<Keybuk> what kind of action does init need to take wrt to processes spawned?
<ajmitch> nothing new, the kernel handles everything after that
<Keybuk> how come the kernel doesn't handle init then?
<ajmitch> if selinux support isn't enabled in the kernel, it should silently skip loading policy
<ajmitch> policy has to be loaded from userspace somehow
<Keybuk> would initramfs not be a suitable place to do that?
<Keybuk> how does the policy get updated when changed?
<ajmitch> when changed, it gets reloaded via the /selinux interface, usually by libselinux
<Keybuk> ok, so it's just an initial "kick the kernel" kind of thing?
<ajmitch> pretty much
<Keybuk> what does one do if loading the policy fails?
<ajmitch> at the moment it throws up warnings, no more
<Keybuk> what should one do?
<crimsun> lwin 20
<crimsun> err, sorry
* Keybuk pushes crimsun's l over
<ajmitch> preferably the system would keep booting, it would be good for that behaviour to be selectable
<ajmitch> if initramfs is a better place than upstart, I'm all for it
<Keybuk> well, initramfs is the kernel/userspace interface
<Keybuk> so it seems logical to do it there
<zul> later
<Keybuk> perhaps in an init-bottom script where the root filesystem is accessible
<ajmitch> bye zul 
<Keybuk> doing it in init itself is a second-best option (as I understand the problem, I may not understand it fully)
<Keybuk> just a thought also, what happens when init is re-exec'd ?
<Keybuk> should the policy be reloaded or not?
<ajmitch> no, policy would usually stay constant, reloading it wouldn't harm anything though
<Keybuk> you'd probably want a if (! restart) in there
<ajmitch> ok
* ajmitch has to run off to work, will come back to it sometime later 
<ajmitch> thanks for that
<BenC> is upload queue for edgy on lockdown?
<BenC> I just uploaded linux-source-2.6.17 10.24, and I need it pushed through (along with lrm and linux-meta behind it for ABI bump)
<pitti> BenC: yes, it's locked; you need an archive master to wave it through
<jdong> BenC: you sure you don't want to help my laziness by sneaking in the unusual-devs entry? ;-)
<BenC> jdong: I'll get it in, but I need this jmicron and amd64-agp fix in asap
<jdong> mmmkay :)
<BenC> pitti: any suggestions on who to ping?
<BenC> jdong: main reason being that amd64-agp fix caused an abi bump, but your stuff wont, so it'll be easier after this
<jdong> k
#ubuntu-devel 2006-09-26
<LaserJock> Is somebody around that feels like helping me debug a networking problem (I'm not sure if it's a bug or just a screwy config)
<zul> hey
<Lathiat> LaserJock: whats the problem?
<LaserJock> Lathiat: -motu
<ajmitch> hey zul 
<mdz> BenC: unless it's a showstopper for the beta, it should wait until after
<mdz> the queue is in manual mode in order to keep the churn down so we can build and test CDs
<bddebian> Howdy
<BenC> mdz: The amd64-agp fix is a showstopper
<BenC> mdz: And I need as many testers for the JMicron as possible too
<BenC> mdz: Do you want me to push the bugs to ubuntu-6.10-beta?
<BenC> mdz: JMicron users (read, most Core 2 Duo users) will get an oops on boot, and not even be able to use the CD's
<BenC> mdz: The changelog is only three items btw, the two I mentioned, and enabling -generic udeb's on i386 (Kamion's request)
<imbrandon> BenC, afaik jdong_ runs a coreduo edgy, might poke him to test
<imbrandon> does it affect the am2 amdx2 proc too or just the intel ones ?
<rodarvus> I run edgy on a core duo T2300, but edgy always worked there for me. (dapper needs 'noacpi', though)
<rodarvus> BenC: this is the laptop I showed you at the developers sprint in Wiesbaden
<mjg59> rodarvus: Core 2, not core duo
<rodarvus> oh, I've read it wrong, disregard that, please
<BenC> not core duo
<BenC> core 2 duo
<BenC> big difference
* BenC gets down to mjg's comment
<bluefoxicy> uh
<bluefoxicy> If I suggested semi-cloning the Windows XP Pro Security tab to replace Permissions, and extending the interface to full POSIX ACL (multiple users, multiple groups) support, would anybody freak and try to burn me as a heathen?
<Fujitsu> bluefoxicy, no, as that's in the GNOME bugtracker as of about 3 years ago.
<Fujitsu> eiciel does a similar thing already, install that package.
<bluefoxicy> Fujitsu:  3 years wow
<bluefoxicy> they're slow as shit :|
<Fujitsu> 2 or 3 years.
<bluefoxicy> I've used eiciel, about 8 months ago; it does no where near the same thing.
<bluefoxicy> well, it lets you do posix acl access; just in ugly mode
<bluefoxicy> (wtf is participants?)
<fabbione> morning
<ajmitch> hi fabbione 
<bluefoxicy> Fujitsu:  got a bug number?
<Fujitsu> bluefoxicy, no, but I saw it ages ago.
<Fujitsu> Gnoem #62817.
<Fujitsu> 5 years.
<Fujitsu> *Gnome #62817
<bluefoxicy> you have an advantage over me I see (I couldn't find the damn thing)
<Fujitsu> I searched for `nautilus eiciel'
<bluefoxicy> ah, that's for posix ACLs
<Ubugtu> Gnome bug 62817 in View as (Icons or List) "Support for POSIX ACLs" [Enhancement,New]  http://bugzilla.gnome.org/show_bug.cgi?id=62817
<Fujitsu> Thanks Ubugtu.... How very slow.
<bluefoxicy> Fujitsu:  I think I can justify opening another bug and using that and 40897 (which is implemented, never closed) as references
<Fujitsu> Malone 40897?
<bluefoxicy> mine is more "Change the interface" than "implement POSIX ACLs" although the two do roll straight together
<bluefoxicy> GNOME 40897
<Fujitsu> Ah, OK.
<bluefoxicy> which describes the current Permissions tab
<bluefoxicy> I remember when i first saw that, I was like, "Holy shit!  They made it take 15 times longer to set permissions!"
<bluefoxicy> (because I could hit all the right check boxes in under a second, versus about 3-5 seconds of dropdowns and figuring out wtf...)
<Ubugtu> Malone bug 40897 in compiz "Gnome-Panel cannot get keyboard-focus" [Medium,Unconfirmed]  http://launchpad.net/bugs/40897
<Fujitsu> bluefoxicy, the new one is more intuitive, I think.
<bluefoxicy> I find that debatable
<bluefoxicy> you have to now hope a user can figure out what "read" "read and write" and this strange "execute" thing do
<Fujitsu> Same as you did befoe.
<bluefoxicy> versus a very symmetric "these three types of people" "these three permissions"
<bluefoxicy> eh.. I dunno. I find isolating the permissions from each other easier to chew ("read and write"?)
<Ubugtu> Gnome bug 40897 in Backgrounds Emblems and Themes "First Time Preferences "Wizard"" [Normal,Verified: fixed]  http://bugzilla.gnome.org/show_bug.cgi?id=40897
<Fujitsu> What is up with Ubugtu at the moment!?
<bluefoxicy> the file dialog is debatable
<bluefoxicy> the folder dialog is confusing as shit, although its original form wasn't much better because users can't intuit what "read" "write" "execute" mean for folders
<bluefoxicy> list files, access files, create and delete files?
<bluefoxicy> and only one at a time
<bluefoxicy> a user's gotta figure out they imply each other... and I've HAD setups where they don't (--x folders, you can traverse but not read or write)
<Fujitsu> That's a little debatable, yes.
<bluefoxicy> http://img246.imageshack.us/img246/5157/mocksecuritydirkn4.png
<bluefoxicy> ACLs and a prettier interface in the same swing?
<bluefoxicy> (will somebody please explain to me what in the heck "participants" are?)
<Fujitsu> Unified term for users and groups, I suppose.
<Fujitsu> Like in Windows, you have security `principals'.
<bluefoxicy> http://img176.imageshack.us/img176/1421/mocksecurityof6.png  Debatable, a little empty...
<bluefoxicy> Eicle has Access Control List ({User/Group}    [X]  [X]  [X] ) and then below it 'Participants" that seem to be me and "nobody"
<bluefoxicy> also system participants, which is every other user on the machine
<bluefoxicy> (yeah, I ripped chunks out of Eicle for the mock-ups)
<Fujitsu> I like the idea of having a separate listbox with non-participating users/groups, so you can quickly and easily see who has permissions.
<bluefoxicy> what are non-participating users/groups
<bluefoxicy> http://blogs.sun.com/alvaro/resource/acl.png  whoa
<bluefoxicy> this is where mainline nautilus is going?  o_o
<Fujitsu> ie. users/groups which have no permissions set.
<bluefoxicy> oh
<Mithrandir> Riddell: kmplayer-doc needs demotion to universe or kmplayer needs promotion to universe.  Which of those is true?
<Fujitsu> Mithrandir, promotion to main, you mean?
<Mithrandir> Fujitsu: yeah.
<Mithrandir> it's a bit early for me still. :-P
* Fujitsu wakes Mithrandir up.
* Fujitsu then goes back to writing his 3-liner.
<Mithrandir> doko__: libgtk-java has dependencies which aren't in main -- should it be demoted?  (It's not seeded and has no reverse deps)
<Mithrandir> Riddell: if you could poke at why koffice is uninstallable on ppc, that'd be good.
<Kagou> morning
<Mithrandir> ajmitch: you're doing mono stuff, aren't you?
<keebler> Does anyone know where I can obtain the new 256bit supporting usplash?
<bluefoxicy> huh wtf.
<bluefoxicy> seahorse starts seahorse-daemon
<bluefoxicy> it then claims a "non-supported" passphrase caching daemon is running.... seahorse-daemon being it.
<imbrandon> keebler, you mean 256 color ? umm its in edgy
<keebler> yeah.. 
<keebler> Would there be a way to adapt it to daper?
<imbrandon> i'm sure one COULD if they had the time and was willing too, along with the artwork ( the old files wont work ) but it would take some doing and frankly there is more important things to be done for release
<imbrandon> it would take alot of backporting afaik for svgalib etc etc etc, its not simple
<keebler> Ok. Thats what I wanted to hear. 
<keebler> joejaxx you read that. :)
<pitti> Good morning
<imbrandon> moins pitti
<keebler> morning
<imbrandon> Mithrandir, ping
<Mithrandir> imbrandon: hi
<imbrandon> heya koffice isnt installable on ppc becouse of ruby
<imbrandon> ruby ftbs on ppc iirc 
<Mithrandir> imbrandon: oh, yeah, I know.
<Mithrandir> that still isn't fixed?
* Hobbsee tickles Mithrandir 
<imbrandon> nope not afaik
* Mithrandir is tickled
<imbrandon> benc was looking at it some days ago ( after the meeting )
<Hobbsee> Riddell: and BenC i think were looking at it
<imbrandon> but i dont think it got fixed
<Mithrandir> grr, ok.
<imbrandon> actualy i think what they came up with is it was something on the buildd's becouse it buildt localy
<imbrandon> for them , if i rember right ( from a log in here )
<imbrandon> Mithrandir, ^^
<Mithrandir> imbrandon: Riddell could reproduce the problem on one of the porter machines, iirc.
<imbrandon> yea it was something like that ( without going back and looking )
<imbrandon> he should be arround shortly ( not sure what the hours at akademy are )
<pitti> hi imbrandon 
* Hobbsee waves to pitti 
<pitti> hey Hobbsee 
* Mithrandir summons a mono person
<imbrandon> heya pitti, when/if you get some time today can you look at the MIR for libmtp ( i'd like to build amarok with it after the freeze )
* Hobbsee runs
<Mithrandir> is libmono-firebirdsql1.7-cil waiting for a MIR for firebird or something else?
<imbrandon> pitti, wow , actualy scratch that , libmtp seems to still be in NEW ( unless you can look at it from there )
<imbrandon> i thought it had gotten past that 
<pitti> imbrandon: no, I cannot see the NEW queue
<imbrandon> pitti, ok disregard then, sorry , i'll have to wait for Kamion or someone to process it
<Mithrandir> pitti: https://launchpad.net/distros/ubuntu/edgy/+queue
<Mithrandir> imbrandon: libmtp is in binary-NEW so it'll be done later today.
<imbrandon> Mithrandir, ahh ok
<pitti> Mithrandir: well, sure, I can see what's in the queue, but I cannot download the packages from there, can I?
<Mithrandir> pitti: no, you can't.  (naturally)
<Mithrandir> pitti: I thought you meant you couldn't see the queue at all
<imbrandon> ;)
<stub> Launchpad will be going down in 15 minutes for a regular code update. Estimated down time is one hour. This is longer than usual to perform some extra database maintenance.
<lastnode> thanks stub 
<Fujitsu> Thanks for the warning.
<bluefoxicy> bluefox@icebox:~$ echo $TMP
<bluefoxicy> /tmp/user/1000
<bluefoxicy> So far so good.
* rideout is listening to Yankee Bayonet (I Will Be Home Then) by The Decemberists [amarok] 
<bluefoxicy> although ssh-* owned by me is in /tmp
<dholbach> good morning
<janimo> can someone let the recent  xubuntu-artwork upload through? thanks
<fabbione> tfheen: http://people.ubuntu.com/~fabbione/lvm-common.debdiff and http://people.ubuntu.com/~fabbione/mdadm.debdiff
<fabbione> tfheen: i need permission to upload.
<fabbione> mdadm is beta stuff..
<fabbione> the lvm is to be consistent
<tfheen> fabbione: 1800 is actually 30 minutes, not 15. :-P
<fabbione> tfheen: it's not in seconds
<fabbione> it's in 1/10 oif secs
<fabbione> sleep 0.1 <-
<fabbione> ;)
<tfheen> then your changelog makes even less sense
<tfheen> since 1800*0.1s = 180s = 3 minutes
<fabbione> yes
<fabbione> but i am using a sleep 0.5 for lvm
<tfheen> or your diff is reversed
<tfheen> ah, ok
<fabbione> pvscan hogs CPU and I/O
<fabbione> taking away time to the kernel to let the device to appear
<fabbione> so i prefer to sacrifice 0.5 seconds
<ajmitch> tfheen: I don't know of anyone using libmono-firebirdsql1.7-cil, it'd require promotion of firebird2 source - I'd say demote, but slomo_ or tseng may have some comments
<fabbione> than waiting perhpas 2 for the kernel
<tfheen> fabbione: have you tested the patch on raid-but-not-lvm systems too?
<fabbione> tfheen: no, but that makes no difference from a raid point of view. The devices still need to show up for raid to run
<fabbione> tfheen: note that the mdadm code has no calls to lvm whatsoever
<tfheen> fabbione: ok, approved.
<fabbione> tfheen: ok thanks.
<fabbione> both of them or just mdadm?
<tfheen> lvm doesn't look beta-critical.
<tfheen> it's nice to have, but not necessary, agreed?
<fabbione> tfheen: no, it's not beta critical. It might be very annoying to wait 15 minutes to get prompted that we can't find lvm volumes tho :)
<fabbione> but it can wait
<tfheen> thanks.
<tfheen> afk for a little bit while I get vawad back up
<janimo> tfheen: can you approve xubuntu-artwork as well? Only usplash images have changed. thanks
<pitti> hi pygi 
<pygi> hello pitti :)
<doko_> pitti: java ping
<pitti> doko_: pong?
<doko_> pitti: your libxml-commons-resolver1.1-java sync
<doko_> pitti b-d's: libjaxp1.3-java are missing completely, xerces-j is in universe
<pitti> doko_: whoops, sorry. Will fix
<doko_> pitti: libjaxp1.3-java is in unstable, maybe a UVF is enough
<doko_> ... exception
<pitti> doko_: I'll revert it to the dependencies as we had in the dapper version, that should be fine?
<doko_> pitti: yes
<sivang> morning
<pitti> hi sivang
* sivang hugs pitti 
<pygi> sivang: !!! morning !!!
<sivang> hi pygi 
<pygi> you back from vacation?
<sivang> pygi: yep
<pygi> nice :)
<sivang> pygi: was great, UK is a very very cool place. (although it was quite hot when we were there)
<pygi> sivang: nice :)
<pygi> sivang: we also have libburn in repos :)
<sivang> pygi: oh goody
<pitti> tfheen: ok to upload a new libxml-commons-resolver1.1-java with b-dep changes to fix FTBFS?
<tfheen> janimo: yeah, that's fine.
<tfheen> pitti: approved
<pitti> tfheen: alright, uploaded
<pitti> doko_: thanks for spotting
<doko_> pitti: just anastacia output wanting to promote classpath & co
<tkamppeter> Now I have worked a lot with Launchpads bug tracker, but one thing I did not find out yet:
<tfheen> Kamion: is there a kernel waiting to be accepted?
<tkamppeter> How does one change the "Importance" of a bug? It is never a changeable field for me.
<tkamppeter> Do I need special permissions for that?
<tfheen> tkamppeter: you're probably not a member of the right group.  IIRC, only ubuntu members can do it.
<dholbach> tkamppeter: I add you to the 'ubuntu-qa' team - just a sec
<dholbach> tkamppeter: done - please reload the page see if it works now.
<Fujitsu> tfheen, it's ubuntu-qa that can do that.
<Fujitsu> (which ubuntu-{,core-}dev is a member of)
<tkamppeter> Thanks, now I can change the importance of bug 49111 ...
<Ubugtu> Malone bug 49111 in gs-gpl "Printing from evolution into an HP Deskjet 3650 completely hang the printer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/49111
<dholbach> tkamppeter: excellent.
<tkamppeter> ... and of the other bugs, too.
<doko_> tfheen: do you know why libgtk-java should be in main? at least it's listed for universe at the moment
<tfheen> doko_: it might have been a dependency of something in the past?
<doko_> tfheen: no, I can't think of anything
<tkamppeter> And I can assign Milestones now, but there is no Edgy.
<tfheen> doko_: strange, then.  Do we want it in main?
<tfheen> tkamppeter: ubuntu-6.10
<tfheen> (or -beta)
<doko_> tfheen: no
<tkamppeter> Thanks.
<doko_> tfheen: please lets followup on python2.4 from yesterday
<tfheen> doko_: as I said yesterday, I'm reluctant to take it, it doesn't seem beta-critical?
<doko_> tfheen: if you consider a build without any patches as fine for the beta, fine; I'd like to see it fixed sooner than later, even in the beta.
<tfheen> doko_: rather than argue, can you point me at any beta-critical bugs it fixes?  If not, I don't think it's appropriate for beta.  We're too close to release to just include patches because they might be useful.
<tfheen> .. or fix bugs or whatever.
<doko_> tfheen: I did point you to the bugs yesterday, here again
<doko_> - Overflow checking code in integer division ran afoul of new gcc
<doko_> - Patch #1541585: fix buffer overrun when performing repr() on
<doko_>    a unicode string in a build with wide unicode (UCS-4) support.
<pitti> ^ (security relevant, FYI)
<dholbach> stub: some weeks ago you added a telepathy project - could you add a galago project too?
<stub> dholbach: You the owner of that too?
<doko_> tfheen: - doesn't look in /usr/share/locale-langpack for translations anymore
<dholbach> stub: sounds good - I'm in contact with the upstream guy, so if he intended to change things, he'll be happy to route it through me
<ogra-thin> Sep 26 11:56:43 in-target: Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
<ogra-thin> Sep 26 11:56:45 in-target: can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
<ogra-thin> Sep 26 11:56:45 in-target: dpkg: error processing cupsys-driver-gutenprint (--configure):
<ogra-thin> Sep 26 11:56:45 in-target:  subprocess post-installation script returned error exit status 1
<ogra-thin> pitti, tkamppeter ^^^^ known ?
<pitti> not to me
<Kamion> tfheen: there's a kernel there, yes. want it waved through?
<ogra-thin> pitti: also i noticed the gstreamer autosink doesnt work if i log in on the server first, log out again and re-login on a thin client 
<tfheen> Kamion: can you pastebin the changelog somewhere?  I think I want it through, but eyeballing changelogs is always good
<ogra-thin> huh ?
<ogra-thin> pitti: i also noticed the gstreamer autosink doesnt work if i log in on the server first, log out again and re-login on a thin client 
<pitti> ogra-thin: can we track down the autosink thing after beta together?
<ogra-thin> yep
<pitti> ogra-thin: twice? :)
<tkamppeter> ogra-thin, No, I could install gutenprint without any problems on my Edgy, and I did not modify anything in the post-inst script.
<ogra-thin> seems its only run on first login and keeps the setting
<ogra-thin> pitti: xchat-gmone is sooo weird :)
<ogra-thin> *gnome too
<ogra-thin> tkamppeter: probably it behaves differntly in the installer ?
<Kamion> tfheen: http://paste.ubuntu-nl.org/24866
<stub> dholbach: https://launchpad.net/projects/galago/
<tkamppeter> pitti, WDYT about patching CUPS to use the Error Policy "Retry Job" by default, to fix bug 41313?
<Ubugtu> Malone bug 41313 in cupsys "printer always goes to pause and cannot be resumed" [Medium,Confirmed]  http://launchpad.net/bugs/41313
<dholbach> stub: thanks a lot!
<ogra-thin> tkamppeter: or i'm missing a dependency in edubuntu either of these two could cause it
<tkamppeter> ogra-thin, yes I did not try during installation
<pitti> tkamppeter: is that fixed upstream?
<pitti> tkamppeter: (btw, I plan to upgrade edgy's cups to 1.2.4 after beta, we are only missing 8 uncritical patches)
<tkamppeter> pitt, CUPS has upstream the old "Stop Queue" error policy, as Mike Sweet is more looking at enterprise environments (who pay him).
<pitti> tkamppeter: for 41313, if there's a safe patch with upstream blessing, sure
<tkamppeter> In Mandriva I have printerdrake as default printer setup tool, there I do not patch CUPS, I simply let printerdrake set an appropriate default.
<tfheen> Kamion: kernel> approved.
<tkamppeter> But here in Ubuntu we have only this unmaintained gnome-cups-manager, should we really do changes, esp. add functionality there?
<fabbione> Kamion: are you uploading a kernel???
<tfheen> fabbione: no, he's approving one.
<fabbione> tfheen: ah ok
<pitti> tkamppeter: BTW, I agree that it is a very annoying bug that we shuold fix
<pitti> tkamppeter: is that simply a matter of a default configuration change?
<tkamppeter> I think, changing a default for making a distro more end-user friendly is not dangerous.
<pitti> tkamppeter: depends on what the change is
<pitti> tkamppeter: I agree
<tfheen> dholbach: you've done ubuntu-docs updates in the past; could you do one now as well?  Make sure it doesn't say 6.06 and dapper, please.
<pitti> tkamppeter: I just don't know what we have to do to fix this - patch or conf change?
<dholbach> tfheen: i did one for doc freeze
<tkamppeter> CUPS must choose a certain error policy internally if the user does not supply any, currently it is "Stop Queue".
<dholbach> tfheen: it shouldn't have changed much
<tkamppeter> Probably this choice is made in a .h file somewhere in CUPS.
<tfheen> dholbach: my system still says "6.06" and "dapper". I hope that's changed.
<pitti> tkamppeter: ah, it must be configured in printers.conf?
<dholbach> tfheen: ok, i'll check
<pitti> tkamppeter: ok; so the default is changed with a patch, and printers.conf could override it, if desired?
<Fujitsu> Oh almighty release manager (aka. tfheen)... At what time on the 28th does universe drop below 0 degrees celsius?
<tkamppeter> Yes, when a queue is created, it gets set in printers.conf.
<dholbach> Fujitsu: it won't drop below 0
<pitti> tkamppeter: I agree that hacking g-c-m would both be much more intrusive and pretty pointless
<tfheen> Fujitsu: heh; I'm aiming for something like 1400 UTC or so, but please don't quote me on that.
<Fujitsu> tfheen, OK.
<dholbach> Fujitsu: there will be still bug fixes, etc
<dholbach> and exceptions of course
<pitti> tkamppeter: if you happen to know the exact know we have to turn, can you please add a comment to the bug?
<Fujitsu> dholbach, of course, but it's UniverseFreeze.
<pitti> tkamppeter: I mark it in a way that I'll fix it post-beta
<tkamppeter> But if you enter "lpadmin -p x -E -v /dev/usb/lp0 -P <my-manufacturers-ppd>" a queue is created with "Stop Queue" policy.
<dholbach> "universe freeze exceptionS" :-p
<tfheen> mvo: update-manager apparently has "edgy" in it; can you get that changed to "6.10 beta", please?
<ogra-thin> Fujitsu: we usually pick the start of teh developer meeting as freeze point
<Fujitsu> ogra-thin, has a meeting been announced this week?
<tfheen> mvo: synaptic seems to say "edgy" as well, please make that "6.10 beta"
<tkamppeter> Thanks, pitti.
<ogra-thin> Fujitsu: its every thursday ...
<Fujitsu> ogra-thin, but it hasn't been announced yet :P
<tkamppeter> ogra-thin, the post-inst script of the Gutenprint CUPS drivers package is only for updating the PPD files of installed print queues.
<tkamppeter> Can the installer do updates? Or does it only install into a virgin partition? Can print queues exist during installation?
<ogra-thin> tkamppeter: then it should probably do a no-op in d-i
<ogra-thin> there are no print queues in a default install, dunno if expert offers something like that, but i doubt it
<tkamppeter> Perhaps it should have some "if" around the updating command or it should simply send error messages to /dev/null and then do "exit 0".
<Kamion> tkamppeter: no, yes, no
<pitti> tkamppeter: definitively not in the alternate install; I'm not sure whether print queues defined in the live system are retained in the ubiquity installed system
<Kamion> updates are the job of the package management system, not the installer
<Kamion> pitti: they aren't
<pitti> Kamion: thanks
<Kamion> they could be, but it seems like a rather exotic thing to preserve
<pitti> no, I don't think they should
<tkamppeter> pitti, on the Mandriva One live CDs all config including print queues is conserved. I do not know but it would be great if Ubuntu live installers would do that, too.
<pitti> well, depends on how we consider the live CD - as throwaway playground or as a means to preconfigure your install
<tfheen> we copy a little bit, but most changes are not copied.
<tfheen> that's by design, really.
<pitti> currently we do the former (no user files, no user configuration, etc.)
<Kamion> we intentionally chose to copy the read-only filesystem on the CD, not the live session, because otherwise the result is difficult to support
<Kamion> I'm pretty set on that; however, it is possible to add individual items of configuration to copy over
<Kamion> please file a wishlist bug on ubiquity with a rationale to get me to do that
<tkamppeter> I think the Mandriva CDs run the live system in UnionFS, the installer then partions the hard disk, mounts the partitions and copies the whole UnionFS, after that it only sets the boot sector and exits.
<Kamion> (and preferably with instructions on what files to grab; I'm not necessarily familiar with every bit of the system)
<ogra-thin> btw apart from that cupsys breakage edubuntu seems beta ready :)
<Kamion> tkamppeter: we considered that option, but we intentionally chose not to do that
<Kamion> (we do run the live system in unionfs - we just don't copy the unionfs)
<tseng> tfheen: ajmitch no worries here over libmono-firebirdsql1.7-cil
<tfheen> tseng: what does that mean?  I want the uninstallable list to be empty on thursday.
<tseng> tfheen: demote
<tfheen> tseng: ok, thanks
<tfheen> tseng: why is it even in main?  Nothing in main depends on it
<Kamion> demoted
<Kamion> I think we may have stuck all of mono in main when it was split out
<Kamion> since I didn't know which bits were needed
<tfheen> ok
<Kamion>  o libmono-bytefx0.7.6.1-cil libmono-bytefx0.7.6.2-cil libmono-c5-1.0-cil libmono-cairo2.0-cil libmono-cscompmgd7.0-cil libmono-cscompmgd8.0-cil libmono-firebirdsql1.7-cil libmono-ldap1.0-cil libmono-ldap2.0-cil libmono-microsoft7.0-cil libmono-microsoft8.0-cil libmono-npgsql1.0-cil libmono-npgsql2.0-cil libmono-oracle1.0-cil libmono-oracle2.0-cil libmono-relaxng2.0-cil libmono-sharpzip2.6-cil libmono-sqlite2.0-cil libm
<Kamion> is there a problem with me demoting all those binaries?
<fabbione> tfheen: can you please let mdadm in too?
<tseng> tfheen: because the entire source was promoted before the split
<tfheen> Kamion: if you'd be so kind as to let Fabio's mdadm upload in?
<tseng> Kamion: i dont see a problem with any of those
* tfheen snickers over the name of libmono-microsoft-cil.  Also note that it's the highest version number in the list.
<tfheen> Kamion: openoffice.org-l10n-sh-yu is NBS, right?
<ajmitch> some will get re-promoted in edgy+1, but that's no real concern now
<Kamion> tseng: ok, thanks, I've dropped the lot
<Kamion> yeah
<Kamion>       but no longer builds:
<Kamion>         o 2.0.2-2ubuntu5: openoffice.org-l10n-as-in openoffice.org-l10n-mr-in openoffice.org-l10n-or-in openoffice.org-l10n-sh-yu openoffice.org-l10n-ur-in
<Kamion>         o 2.0.3-3ubuntu5: openoffice.org-l10n-ti-er
<Kamion> shall I remove all those? I wasn't sure
<tfheen> at least sh-yu is uninstallable.
<tfheen> doko_: ^^ those can be removed?
<Kamion> tfheen: mdadm hasn't landed yet
<Kamion> tfheen: currently in unapproved: deskbar-applet gnome-orca kdebase python2.4 firefox-themes-ubuntu gnome-app-install
<tfheen> fabbione: slacker. :-P
<fabbione> Kamion: i uploaded it a few hours ago!
* fabbione sighs
<tfheen> Kamion: kdebase is ok.
<tfheen> what does the ff-t-u contain?
<fabbione> oh wanna bet LP did eat it during the downtime?
<fabbione> anyway.. reuploading now
<dholbach> tfheen: I fixed the occurrences of dapper, drake, 6.06, etc in the browser startpage (not the other occurences of dapper in the docs, as they require review by the team) - good to go?
<slomo_> tfheen: can be demoted... same as everything else from mono that nothing from main depends on
<mvo> Kamion, tfheen: anything that needs to be discussed about g-a-i? I uploaded it yesterday
<fabbione> Kamion, tfheen: reuploaded...
<dholbach> tfheen: what did you do to "Mithrandir"?
<fabbione> dholbach: Mithrandir was bad and hugly :P
<Fujitsu> dholbach, I was wondering the same.
<simira> dholbach: he took a ride through the city
<dholbach> simira: and never came back? I refuse to believe that - it's Mithrandir! maybe he's on vacation
<Kamion> -kdebase (4:3.5.4-0ubuntu26) edgy; urgency=low
<Kamion> +debase (4:3.5.4-0ubuntu26) edgy; urgency=low
<Kamion> Tonio_: classy
* mvo shakes his head in disbelieve. leaving so close to the beta
<simira> dholbach: he took a ride, I didn't say he's not expected back
<Kamion> accepted anyway
<doko_> tfheen: yes, there's a report open for openoffice.org-l10n-sh-yu
<doko_> Kamion: the other -l10n packages can be removed as well; we durrently cannot build them.
<Tonio_> Kamion: yeah I now I didn't upload the good *.changes, sorry
<tfheen> dholbach: yes, good to go.
<tfheen> dholbach: mithrandir is when vawad is back up again.
<Kamion> doko_: thanks, done
<Tonio_> Kamion: but I reuploaded 0ubuntu27 which mithrandir approved yesterday.....
<dholbach> tfheen: it's up
<Kamion> er, or not, WTF
<Kamion> Tonio_: that was part of the diff from 0ubuntu27
<Kamion> i.e. you accidentally dropped a character from the start of the next changelog entry down
<Tonio_> Kamion: hu ?
<tfheen> dholbach: thanks.
* mvo wonders what vawad is?
<Kamion> doko_: ok, er, sorry, I apparently can't remove packages as lp_archive any more (!)
<tfheen> mvo: my server.  Or, one of them, anyway.
<Tonio_> Kamion: okay, I see this... sorry for the inconvenience... I remember having done this indeed..
<janimo> Kamion: can you accept xubuntu-artwork (uploaded a couple of hours ago, approved by tollef)
<Kamion> janimo: no, it's not there
<Kamion> OH
<fabbione> a bunch of uploads have been lost (THANKS LP!) during their downtime
<Kamion> fabbione: no, they aren't lost
<Kamion> please don't reupload
<fabbione> they aren't?
<fabbione> i already did
<Kamion> somebody forgot to turn the cron job back on, that's all
* fabbione sighs
<Kamion> fabbione: then a random one will be accepted, probably
<fabbione> Kamion: i uploaded the exact same version
<fabbione> so that shouldn't be an issue
<Tonio_> Kamion: in fact I had to rewrite the latest 2 entries of the changelog since due to my broken locales, there was something going wrong with the changelog... I certainly removed the character then... will be more carefull in the future
<Kamion> Tonio_: you can generally avoid this by reading the diff before upload
<Kamion> in my experience anyway :)
<Tonio_> Kamion: hehe, indeed :)
<carlos> pitti: hi, I just moved my scripts to start the lang pack exports 6 hours earlier than usual
<carlos> pitti: just in case you want to move yours too
<pitti> carlos: oh, nice
<pitti> carlos: yes, I'll do that
<carlos> or wait until tomorrow to see when are they exported
<pitti> carlos: ok, changed back; can you ping me tomorrow again?
<carlos> pitti: sure, but you can see it anyway from the website, the timestamp is not changed, I use rsync to push them to rookery
<Kamion> doko_: ok, really removed those binaries now
<fabbione> Kamion: 
<fabbione> Rejected:
<fabbione> mdadm 2.4.1-6ubuntu5 was REJECTED.
<fabbione> 	Component: main Section: admin
<fabbione>  ??
<Kamion> fabbione: that was the duplicate
<fabbione> ah ok
<Kamion> I've just accepted the other one
<fabbione> thanks
<Kamion> janimo: accepted
<Kamion> tfheen: firefox-themes-ubuntu changelog is http://paste.ubuntu-nl.org/24868 - should fix the very wide Go button I think
<fabbione> siretart: ping?
<siretart> fabbione: pont
<fabbione> simira: openal and freealut split mess... 
<fabbione> ops
<fabbione> siretart: ^^
<fabbione> siretart: apparently openal apps expect openal to be linked with freealut
<siretart> fabbione: should have been sorted out in dapper already
<fabbione> siretart: what's the plan for that?
<fabbione> ./X-Plane-i586: symbol lookup error: ./X-Plane-i586: undefined symbol: alutInit
<siretart> fabbione: upstream decided that some parts of openal should go to a separate lib, called alut.
<fabbione> alutInit is referenced by libopenal in other distros
<siretart> fabbione: thats similar to GL and GLUT for graphics
<fabbione> hmm ok
<siretart> fabbione: thats history. since openal 0.0.8, alut sits on its own
<siretart> fabbione: fix the app to link against both -lalut and -lopenal
<fabbione> siretart: ok.. i will need to talk to upstream.. an LD_PRELOAD works, but i hate that stuff
<siretart> fabbione: yes. tell upstream that they must not assume that alut is in libopenal. this isn't true for I think 6 months or even more
<fabbione> siretart: ok thanks a lot
<siretart> fabbione: and btw, this seems to be the same in the other openal implementations like the creative one or the apple one
<siretart> one of the reasons might be that alut has a different release schedule as openal
<fabbione> suse is still using the old openal somehow
<siretart> thats surprising
<fabbione> yeah i understand the reasons. no big deal
<fabbione> <fsck> lele@rivendell:~/X-Plane/X-Plane 8.40> grep alutInit /usr/lib/*
<fabbione> <fsck> Binary file /usr/lib/libopenal.so.0 matches
<fabbione> <fsck> Binary file /usr/lib/libopenal.so.0.0.8 matches
<siretart> there seem to be suse developers at openal upstream
<siretart> yes, openal in breezy also hat alut in libopenal
<siretart> s/hat/had/
<fabbione> that's one of the very latests suse
<siretart> that surprises me
<fabbione> anyway.. thanks for the explanation
<fabbione> i will try to talk to upstream and see what they say
<siretart> no wonder why upstream always tell their users to use a selfcompiled openal
<siretart> fabbione: btw, thats the reason why dapper has the package 'libopenal0a'. other distributions ship libopenal0, with soname libopenal.0.0.8.  so the debian/ubuntu openal is in fact incompatible with them
<siretart> fabbione: I'm waiting for months for upstream to release a new openal, which will have another soname
<siretart> fabbione: maybe thats the reason why suse hasn't updated yet
<fabbione> ok
<mvo> tfheen: I still have no confirmation about the gnome-app-install upload? anything I can do to help ?
<cbx33> ping seb128
<cbx33> I need a big favour ;)
<seb128> cbx33: hi
<cbx33> seb128: can I pm you?
<seb128> cbx33: if you want
<tkamppeter> pitti, the CUPS patch for changing the default error policy is harmless (CUPS seems to be cleanly programmed), I have attached it to bug 41313.
<Ubugtu> Malone bug 41313 in cupsys "printer always goes to pause and cannot be resumed" [Medium,In progress]  http://launchpad.net/bugs/41313
<sivang> mvo: hi, around ?
<mvo> hello sivang! yes
<pitti> tkamppeter: splendid, thanks
<tkamppeter> I have tested it on my Mandriva test box with "lpadmin" and the web interface (not printerdrake), and with both methods I get "Retry Job" as error policy now. And it can be overridden as usual (supply option to "lpadmin" or choose another value on options page of web interface).
<tfheen> Kamion: firefox-theme-ubuntu> approved.
<zul> hey
* pitti waves to zul
<tfheen> Kamion: gnome-app-install > changelog is update .desktop files or similar?  If so, approved.
<zul> hey pitti 
<ajmitch> wb zul
<sivang> mvo: hey :-) I just wanted to ask if you could send me the link to your branch of home user backup that you sent me 2 weeks ago, I've been to a vacation and am now catching up resuming works.
<mvo> sivang: http://people.ubuntu.com/~mvo/bzr/hubackup--mvo/ <- just minor stuff and some tests/. I didn't had a lot of time
<Kamion> tfheen: yeah, also:
<Kamion> +  * hide python-apt future warnings
<Kamion> +  * update available information on refresh()
<Kamion> +  * changed the "applications-proprietary" icon
<Hobbsee> tfheen: are we in an absolute hard freeze, or could i push thru a couple of small fixes?  (havent done them yet)
<Kamion> tfheen: is my finish-install upload to fix serial console handling for upstart ok?
<tfheen> Kamion: yeah, that's the one.
<tfheen> Kamion: yes.
<tfheen> Hobbsee: ice hard.  If your fixes fix beta-critical bugs, they can go in, else not.  Universe is open for business as usual, though.
<Kamion> tfheen: ubuntu-docs ok? it's dapper->edgy
<tfheen> Kamion: yes.
<Kamion> tfheen: shall I take care of base-files and stuff?
<tfheen> Kamion: yes, please.
<Hobbsee> tfheen: okay, i'll wait then.  and it's in main.
<sivang> mvo: everything is appriciated, am now going to work it up to make sure it will hit edgy+1 as early as repos open, thank again. 
<Hobbsee> tfheen: thanks
<tfheen> Kamion: if you'd add "and stuff" to https://wiki.ubuntu.com/CodeNamesToVersionNumbers, that'd be good
* sivang prepares for some conflict resolution work as the branch his been working on is now using the new GUI.
<Kamion> tfheen: what where?
<mvo> sivang: cheers! 
<jdong> hmm, are either Ubuntu installers meant to be able to install to a USB mass storage device?
<tfheen> Kamion: you said'd you'd update base-files.  If there's anything more which needs updating, putting those on the list of apps which needs to be updated.
<tfheen> uh, ".. please put those on the list of apps which need to be updated"
<tfheen> jdong: yes.
<Kamion> tfheen: oh, I see. I said that because I wasn't sure :)
<jdong> tfheen: awesome. That just made my day :) *hug*
<tfheen> jdong: at least it worked last time I tried back (and wrote the support) in February.
<tfheen> unsure about ubiquity, but I don't see why it wouldn't work.
* bluefoxicy finally gets what 'participants' means, it means 'here is a list of every user and group on the system'  :|
<jdong> tfheen: the only glitch I could finally think of is with grub
* bluefoxicy hates this interface, it is dumb :|
<jdong> tfheen: but that's more of a BIOS issue than a ubuntu issue
<Kamion> tfheen: actually, I suppose it could just keep on saying (development branch)
<Kamion> changelog records suggest that we haven't changed it for beta before
<jdong> are USB Mass Storage installs a supported setup? Should I file bugs if it doesn't work?
<tfheen> Kamion: ok.  Care to note it in the list anyway?
<tfheen> jdong: yes
<jdong> k
<tfheen> at least afaik.
* jdong willing to wager money that grub won't work....
<Kamion> tfheen: it's there, under "Files that refer Dapper" [sic] , also in ReleaseChecklist
<tfheen> there's a reason why I spent a day or two writing that support, it wasn't purely for the excercise.
<tfheen> Kamion: true.  I'd like that list to list packages rather than files.
<jdong> tfheen: does the installer properly recognize that when booting from usb, the device is always known as hd0?
<Kamion> tfheen: I think I'll update debian-cd now though
<tfheen> jdong: it should, yes.
* jdong impressed :)
<tfheen> jdong: just try it, if it doesn't work, file bugs, if it works, be happy.
<jdong> lol, ok
<Kamion> tfheen: ok, I've updated it slightly
<Kamion> tfheen: debian-cd bumped to say edgy's beta
<tfheen> thanks
<Hobbsee> tfheen: sorry to be a pain, but when does this freeze end, sorry?
<Hobbsee> eh.  my brain's gone again
<tfheen> Hobbsee: when beta's out.  Thursday.
<Hobbsee> ah
<Hobbsee> thanks
* Hobbsee seems to be looking at fixing main packages.  silly.
<ajmitch> just queue up some fixes to get in after beta release
<Kamion> you can upload them, they'll be queued
<Hobbsee> yeah, well
<Hobbsee> one's for gaim.  i think i must be ill
<ajmitch> yes, quite sick
<ajmitch> hm, 1AM snuck up on me again
<Treenaks> Hobbsee: Step away from the source code!
<Hobbsee> Treenaks: :P
<Treenaks> uh?!
<Hobbsee> my apologies
<pitti> ugh, everything is so brown here... Seeing breezy has become a rare occasion :)
<bluefoxicy> hi pitti
<pitti> hi blue
<pitti> hi bluefoxicy 
* tseng hands pitti a tarball full of SuSE Enterprise Desktop 10 art
<tfheen> pitti: https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62242 ; this seems to be your bug?
<Ubugtu> Malone bug 62242 in apache2 "[Edgy]  No binaries for Apache 2 2.0.55-4ubuntu3 for CVE-2006-3747" [High,Confirmed]  
<pitti> tfheen: yes, I chased and discussed it with thom for one and a half hour yesterday; I'm still pretty clueless unfortunately
<pitti> tfheen: but yes, eventually I'll look into it
<tfheen> pitti: it's beta-targeted
<pitti> yeah, I hoped it would be something trivial
<pitti> however, neither thom nor I actually know the source of the bug
<pitti> (yet)
<thom> pitti: there's no chance i'll have time to look at it today
<thom> sorry
<pitti> thom: oh, wasn't meant to be a blame at all, don't worry 
<thom> i know. i'm just making sure you know :-)
<tkamppeter> I have a problem with the daily Debian morning gymnastics.
<tfheen> pitti: can we reasonably claim it's not beta-critical?
<ogra> tkamppeter, this is not a support channel :P
<tkamppeter> If I enter "sudo apt-get update; sudo apt-get dist-upgrade" it tells me that it cannot find the python-central package:
<tkamppeter> Err http://fr.archive.ubuntu.com edgy/main python-central 0.5.5ubuntu3
<tkamppeter>   404 Not Found
<tkamppeter> Failed to fetch http://fr.archive.ubuntu.com/ubuntu/pool/main/p/python-central/python-central_0.5.5ubuntu3_all.deb  404 Not Found
<tkamppeter> and the update fails.
<ogra> tkamppeter, mirror issue with the fr mirror  ?
<pitti> tfheen: well, it's an FTBFS, but apache2 is not on the CD
<tkamppeter> Adding "--fix-missing" also did not help, it takes ages after the error message, installs the other packages and ready.
<tkamppeter> ogra, can I suppress the fr mirror somehow?
<ogra> tkamppeter, http://archive.ubuntu.com/ubuntu/pool/main/p/python-central/ has it
<tfheen> pitti: it's on the server cd.
<ogra> tkamppeter, http://fr.archive.ubuntu.com/ubuntu/pool/main/p/python-central/ doesnt
<ogra> you can change your /etc/apt/sources.list
<ogra> or use the software preferences gui to do that
<pitti> tfheen: well, I can stop fiddling with the firefox security update and care for apache now if you want me to
<tfheen> pitti: please do fix firefox. :-)
<pitti> tfheen: (... for breezy, not for edgy)
<tkamppeter> Thanks, ogra, I am trying it now.
<Znarl> ogra : I'll contact the admin of fr.archive.ubuntu.com and ask them to look into this issue.
<ogra> Znarl, thanks :)
<terlmann> is the beta release process proceeding as planned?
<tkamppeter> Thanks, ogra, and Znarl, my update has completed now.
<dholbach> could it be that the binaries of telepathy-qt were never liberated from binary new? (libqttelepathy0 and libqttelepathy-dev)
<cbx33> ping popey
<BenC> For anyone that was still wondering. the ruby1.8 build failure is caused by kernel 2.6.15...it builds if you boot to 2.6.17
<dholbach> WOW
<infinity> BenC: Ugh.  Seriously?
<infinity> elmo: ^^^
<mvo> doko, doko_: ping?
<infinity> elmo: Will you hit me if I ask for the PPC buildds to get upgraded to 2.6.17+?
<doko_> infinity: I'll hit you, if you don't check before that OOo still builds
<doko_> mvo: pong
<mvo> doko_: the upgrade from g++-4.1 (4.1.1-13ubuntu2) to 4.1.1-13ubuntu3 broke synaptic build! it FTBFS now
<doko_> mvo: bug number?
<BenC> infinity: Can you tell me why linux-source-2.6.17 10.24 is needs-build for everything?
<dholbach> do universe uploads need "approval by a distro manager" too?
<dholbach> and why is 'Component' for telepathy-python 'main'?
<infinity> BenC: slight soyuz breakage.  Working on it.
<mvo> doko_: not reported yet, I just wanted to ask if you have a idea. the changelog has nothing in it that explains why the build suddenly starts to fall appart
<BenC> infinity: OK, I'm going to upload lrm/linux-meta now and just get them pushed through the queue when linux-source is done
<infinity> BenC: Sounds fair.
<ogra> infinity, ! alive !
<infinity> ogra: Alive, and going to bed.  I'll be back all day tomorrow, though.  For my core hours and yours. :)
* bluefoxicy rejects Malone 62407
<Ubugtu> Malone bug 62407 in seahorse "seahorse-daemon broken" [Undecided,Rejected]  http://launchpad.net/bugs/62407
* dholbach hugs infinity
<ogra> infinity, wb and sleep well :)
<mvo> doko_: interessting side-note. the problem with synaptic seems to appear only on i386)
<elmo> infinity: I have a test kernel installed on davis
<elmo> infinity: if that works out, I'm happy to upgrade the others
<infinity> elmo: Spiffy.
<infinity> doko_: Can you test-build OOo on davis to make sure it still works and let elmo know?
<doko_> infinity: the machine runs 2.6.15
<fabbione> elmo: did you actually reboot davis in .17?
<cbx33> does anyone here actually live in the UK?
<elmo> fabbione: not yet, still needs CMOS battery replaced, which should happen this evening/afternoon
<fabbione> elmo: ok great! thanks
<mvo> doko_: bug #62461
<Ubugtu> Malone bug 62461 in gcc-4.1 "synaptic no longer buils after g++-4.1 (4.1.1-13ubuntu2) to 4.1.1-13ubuntu3 upgradae" [High,Unconfirmed]  http://launchpad.net/bugs/62461
<keescook> okay, I dug around the wiki, and I know I've seen it before, but where do I find the build queue page again?
<pitti> keescook: https://launchpad.net/+builds
<carlos> doko_: OO.org is imported
<carlos> doko_: I'm going to prepare the export and send you the link
<pitti> keescook: or, for builds of a particular source package, https://launchpad.net/distros/ubuntu/+source/bash
<doko_> carlos: thanks!
<pitti> keescook: and then click on the version you want
<keescook> pitti: ahha, thanks!
<bddebian> Heya folks
* keescook waves hi
<dholbach> do universe uploads need "approval by a distro manager" too?
<herzi> does ubuntu provide a tool that can be called from an aplpication if it encounters sigsegv? (something like bug buddy, but for launchpad)
<tseng> herzi: yes
<tseng> herzi: apport
<herzi> thanks
<tseng> the app doesnt need to call it
<tseng> the kernel does
<tseng> I believe
<carlos> pitti: hi, do you have some time?
<pitti> carlos: well, what's up?
<carlos> pitti: I would like to know how are you fixing the packages in the backports pocket to include translations
<carlos> pitti: do you have a list of packages affected?
<pitti> carlos: no, I don't have a list; we can't do anything else than rebuild them, I think
<carlos> right, but I guess you are forcing such rebuild, right?
<pitti> carlos: forcing in the sense of doing a new backport, yes
<carlos> so you should have a list of packages that need a new backport....
<pitti> right
<carlos> pitti: could you send me that list? I need to restore the original dapper template in Rosetta
<Kamion> cbx33: yes, quite a few of us
<pitti> well, I don't have it
<carlos> pitti: ?
<pitti> carlos: I have to check all existing dapper backports and sort out which don't have translations
<Kamion> dholbach: yeah, the frozen state isn't per-component
<Kamion> dholbach: I wave through universe/multiverse uploads whenever I notice them
<carlos> pitti: so you didn't prepare a list but fix them from time to time....
<dholbach> Kamion: oh ok - thanks a lot
* cbx33 is going for ubuntu-dev tonight
<carlos> pitti: is it too difficult for you to get such list?
<cbx33> but my gpg key hasn't been signed
<dholbach> Kamion: I also noticed that 'telepathy-python' had component 'main' - which looked a bit worrying - it was never intended to be there
<pitti> carlos: no, it's easy, but takes time; I just didn't find the time yet
<carlos> pitti: is it something I can do?
<Kamion> dholbach: yeah, it's a mistake, I'll fix it
<dholbach> Kamion: thanks a lot.
<Kamion> only the source is in main
<carlos> without having the rights you have in our servers
<cbx33> no one who lives close to southampton though ;)
<pitti> carlos: sure; all sources in http://archive.ubuntu.com/ubuntu/dists/dapper-backports/main/source/Sources.gz which have translations
<Kamion> not that close, no ...
<carlos> pitti: ok, I will try to do it today or tomorrow and I will send you the list
<elmo> how hard is it to rebuild the liveCD with a simple package added - and/or is the process documented somewhere?
<tseng> elmo: you basically unpack the image, chroot in, apt-get install, recompress the image and rebuild the iso
<tseng> elmo: finding link
<tseng> elmo: https://wiki.ubuntu.com/LiveCDCustomization
<elmo> tseng: sweet, thanks
<elmo> how much space is usually free on the Live CD?
<tseng> about 0mb
<elmo> doh
<elmo> ok
<tseng> after all the apps are in its filled  up with langpacks
<tfheen> elmo: 50MB or so if you remove winfoss, etc.
<bluefoxicy> wow no wonder layerfs is so slow
<bluefoxicy> for open, it generates a file handle
<tfheen> you should be able to just mount the squashfs,  unionfs an empty directory on top, install the stuff, mksquashfs the directory and put that in casper/local.squashfs on the ISO too, but that's not documented anywhere.
<bluefoxicy> for read, it opens the actual file; seeks; reads the requested block; and then closes the file.
<bluefoxicy> Every.  Freakin'.  Time.
<elmo> tfheen: will the instructions on https://help.ubuntu.com/community/LiveCDCustomization/6%2e06 work with edgy?
<tfheen> elmo: yes.
<tfheen> obviously with kernel versions and such replaced.
<elmo> tfheen: cool, thanks
<Riddell> BenC: did you make any progress on ruby?
<BenC> Riddell: ruby needs to build on a .17 kernel machine
<BenC> segv only happens when running 2.6.15
<Riddell> BenC: so we need to grovel to a sysadmin to set up a buildd with .17?
<mvo> tfheen: permission to upload http://people.ubuntu.com/~mvo/tmp/synaptic-segfault-fix.diff (fixes easily triggerable segfault in synaptic)
<BenC> Riddell: yep
<Riddell> elmo: would a ppc buildd with linux .17 be possible?
<fabbione> Riddell: i did ask elmo to upgrade davis for testing first
<fabbione> Riddell: it's in the bug comments
<Riddell> oh, cool
<tfheen> mvo: what about https://launchpad.net/distros/ubuntu/+source/gcc-4.1/+bug/62461 and https://launchpad.net/distros/ubuntu/+source/synaptic/+bug/59673 ?
<Ubugtu> Malone bug 62461 in gcc-4.1 "synaptic no longer builds after g++-4.1 (4.1.1-13ubuntu2) to 4.1.1-13ubuntu3 upgradae" [High,Unconfirmed]  
<tfheen> (they are marked as beta blockers)
<ogra> you and your drugs ... tsk
<tfheen> mvo_: did your connection drop?
<mvo_> tfheen: sorry, network. 
<mvo_> tfheen: I did some debugging with doko and it seems that a rebuild of apt is enough to make synaptic build again
<tfheen> 17:47 < tfheen> mvo: what about https://launchpad.net/distros/ubuntu/+source/gcc-4.1/+bug/62461 and
<Ubugtu> Malone bug 62461 in gcc-4.1 "synaptic no longer builds after g++-4.1 (4.1.1-13ubuntu2) to 4.1.1-13ubuntu3 upgradae" [High,Unconfirmed]  
<tfheen> https://launchpad.net/distros/ubuntu/+source/synaptic/+bug/59673 ?
<Ubugtu> Malone bug 59673 in synaptic "Synaptic shows a description in incorrect language for korean" [High,In progress]  
<tfheen> mvo_: ok, and the other?
<mvo_> so the severity of the bug may be lowered
<tfheen> mvo_: it's marked as a beta blocker.
<tfheen> (both of them are, actually)
<mvo_> tfheen: the language one is not really a blocker but something I want to get fixed for beta. it requires a new ddtp upload for lp
<tfheen> mvo_: ok, so it's not actually a bug in synaptic?
<mvo_> tfheen: its just anoying for the korean people to see russian translations :P
<mvo_> tfheen: no, that one is a incorrectly labeld file on the archive server
<mvo_> tfheen: and the other one is a bug in g++
<tfheen> mvo_: ok,  go ahead with your other fix, then.
<mvo_> tfheen: thanks!
<elmo> are we getting all variants for beta?  particularly server
<tfheen> elmo: yes.
<elmo> tfheen: thanks
<elmo> (sorry for all the questions :)
<tfheen> np.
<fabbione> hey Keybuk 
<Keybuk> fabbione: hey
<fabbione> Keybuk: we solved the raid issue with some black magic
<fabbione> Keybuk: we need to plan a session in MountainView to fix it at udev level
<Keybuk> oh, what did you do?
<Keybuk> I've already registered specs :p
<fabbione> Keybuk: voodoo magic :)
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-evms
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-lvm
<fabbione> Keybuk: there is still one annoying bug in udev but give me 5 minutes and i will explain that to you
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-mdadm
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-device-mapper
<Keybuk> -- 
<fabbione> ehhe
<Keybuk> registered them a few weeks ago :p
<fabbione> Keybuk: basically mdadm on install creates a config with raid(s) uuid(s)
<fabbione> we copy that config in the initramfs and we wait for uuid(s) to show up 
<fabbione> with a timeout of course
<Keybuk> *nods*
<Keybuk> reasonable kludge
<Keybuk> what was the bug?
<fabbione> the problems are 2 left in udev/volume_id
<fabbione> 1) lvm on install are still converted to UUID=
<fabbione> 2) volume_id sets a symlink from disk/by-uuid to the first device that is part of the raid and not on the raid itself...
<fabbione> (or whatever is used to create that symlink)
<fabbione> so basically
<fabbione> i had /boot on /dev/md0 UUID=foo 
<fabbione> md0 being on top of sda2 and sdb2
<fabbione> in disk/by-uuid i saw foo -> sdb2
<fabbione> sometimes sda2
<fabbione> that makes baby jesus cry, because raid will lock sda2 and sdb2 (since it's running) and the mount will fail
<Keybuk> I can well believe that is broken
<fabbione> i am just not sure what approach to use for that
<fabbione> i could hack more in the md script to fix that symlink, but it sounds wrong to me
<Keybuk> it's the upstream "persistant storage" stuff that needs fixing
<fabbione> ok.. considering we don't have time to wait for upstream....
<fabbione> what's your suggestion?
<fabbione> should i hack more in there?
<fabbione> or should we avoid transitioning raid and lvm?
<fabbione> (to UUID that's it)
<Keybuk> for edgy, avoid it
<fabbione> the hack for me it's really easy
<fabbione> it's a 3 lines in shell
<Keybuk> and the persistant storage rules are very complex
<Keybuk> I really don't want to go changing them this close to a release
<fabbione> ok
<fabbione> there is still the issue that the check on install fails and convert lvm to UUID that IIRC it was already fixed
<fabbione> i wonder if it's something to do with /dev being mounted in /target
<Keybuk> shouldn't think so, the postinst is run in the chroot, so wouldn't see /target
<Keybuk> oh
<Keybuk> I bet it's not the conversion
<Keybuk> I bet it's that the installer just writes UUIDs :)
<Keybuk> while we excluded lvm, md, etc. from the convert code, I bet Kamion never changed the installer to not write UUID=* for those!
<Kamion> ah, quite possibly
<Kamion> can somebody file a partman-target bug about that?
<fabbione> Keybuk: can you please take care of that? i am completing a silo test for bet
<Keybuk> fabbione: can you please?  I don't have any detail other than "probably doesn't work" -- you have the example fstab, etc.
<fabbione> o
<fabbione> k
<fabbione> Keybuk: will you take care to disable raid conversion in udev? or do you also need a bug?
<Keybuk> disable raid conversion?
<fabbione> on upgrades?
<fabbione> from dapper -> edgy
<Keybuk> is it not already disabled?
<fabbione> who/what does convert to UUID?
<fabbione> only LVM afaik
<Keybuk> what do raid devices look like?
<fabbione> we did fix the UUID on raid, but now we are hitting this
<fabbione>  /dev/md*
<Keybuk> ok, those aren't converted currently
<fabbione> ok
<Keybuk> uh, I mean, those ARE
<fabbione> thanks
<fabbione> eh ok
<fabbione> so we need to stop converting them
<Keybuk> *nods* please file a bug (on udev)
<Keybuk> you'll also need another on partman-target to stop them being written as UUIDs in the first place
<Keybuk> and probably another on grub, etc. to stop them being converted for root=
<Kamion> tfheen: ^-- is this a pre-beta thing?
<Kamion> my inclination is probably yes
<Kamion> at least the partman-target side
<fabbione> Kamion, Keybuk: #62476
<Kamion> thanks
<Kamion> fabbione: I'd like an example fstab or something
<Kamion> something to get hold of
<fabbione> Kamion: sure thing
<fabbione> Kamion: there.. added
<fabbione> Keybuk: for you too
<fabbione> Kamion, tfheen: if this is beta candidate, all the 3 packages will have to be fixed.. otherwise it won't help too much
<fabbione> at least i think it's best to either get it all in
<fabbione> or all after beta with a releasenote
<BenC> hmm, sorting by status on the milestone page seems broken
<froud> Can anyone tell me the month and year in which LTS ends?
<Kamion> 2009/06 on the desktop, 2011/06 on the server
<Kamion> at least, that was the original announcement
<Amaranth> I'd imagine June 2011
<adolson> hi. if I want to make a derivative of Ubuntu, is Reconstructor the way to go?
<LaserJock> adolson: it's *a* way to go, but not the only way. Depends on what you want to do I suppose, and if you like a GUI tool to do it
<adolson> LaserJock: I don't figure it's the appropriate way to create a distro like kubuntu, correct?
<LaserJock> something as different as Ubuntu->Kubuntu I would probably want to do CLI
<LaserJock> adolson: https://help.ubuntu.com/community/LiveCDCustomization/6.06 seems to be a good resource
<adolson> LaserJock: am I right in thinking that the first step should really be creating a meta-package? in our case, mubuntu-desktop
<LaserJock> I certainly think it's a good idea
<kristo> hello *
<gardengnome> hello adolson. i'd also like to create a derivative distro :). my first step will be understanding the build process of the official CD images so i can add new packages and modify the seeds.
<adolson> gardengnome: I don't even know what a seed is, so you're ahead of me
<LaserJock> are you guys looking at doing LiveCDs?
<gardengnome> adolson: ah well. let me power up my main computer and i'll pass ya some urls.
<gardengnome> LaserJock: no. a derivate distro including all the bells and whistles. at least that's what i'm gonna do :)
<LaserJock> gardengnome: what I mean is, based on the Desktop CD or alternate CD?
<gardengnome> adolson: give me a few minutes please.
<LaserJock> and do you plan to have your own repos or use Ubuntu's?
<adolson> LaserJock: a whole bunch of people wanted to work on a multimedia distro..
<gardengnome> LaserJock: based on ubuntu and its seeds :) hehe. i'd like to create my own seeds so i can have all kinds of CDs i want.
<adolson> I think 3rd-party repositories are from the devil
<gardengnome> LaserJock: both.
<LaserJock> adolson: ;-)
* gardengnome was gonna work on a ubuntu mythtv distro
<LaserJock> I would suggest you talk to raphink (Raphael Pinson)
<gardengnome> thanks!
<LaserJock> we've been working on an Kubuntu-based flavor
<LaserJock> using LP, seeds, etc.
<LaserJock> he can give you a fair amount of advice
<LaserJock> I would encourage you guys to create metapackages and do you packaging work within the Ubuntu repos as much as possible
<adolson> I absolutely agree
<adolson> better would be into debian's repos
<adolson> but they dont' have a nice system like REVU
<adolson> (last I checked)
<LaserJock> debian mentors
<LaserJock> mentors.debian.net
<LaserJock> luckily with our project we have several DDs so we will be pushing packages into Debian as well
<LaserJock> but much of the desktop stuff is pretty Ubuntu specific
<adolson> ah, that looks better than it did before
<adolson> you remember me, right LJ?
<adolson> I remember you... :(
<gardengnome> i've gotten the impression that launchpad can also be used by ubuntu derivates to coordinate their work
<imbrandon> gardengnome, sure see https://launchpad.net/distros
<gardengnome> adolson: it's a lot of URLs. query?
<adolson> sure
<gardengnome> imbrandon: i've already found that. it looks very cool.
<LaserJock> adolson: of course I remember you ;-)
<adolson> LaserJock: I didn't work on anything for Edgy, unfortunately
<LaserJock> launchpad can be used for bug tracking, specs, all kinds of goodnes ;-)
<LaserJock> +s
<mvo_> tfheen: could you please accept my recent synaptic upload?
<gardengnome> LaserJock: i'm already registered there but i didn't want to create a project till i understand how i can build a CD, for example. that would be embarrassing IMHO. ;)
<mvo_> iwj: still here?
<LaserJock> gardengnome: we use https://help.ubuntu.com/community/LiveCDCustomization/6.06 with modification
<gardengnome> LaserJock: thanks, but i'd like to do it from sratch.
<LaserJock> gardengnome: good luck with that ;-)
<LaserJock> It can be done, but it is pretty difficult and if you aren't modifying the packages much it's probably not worth it
<gardengnome> LaserJock: thanks, i'll need it
<LaserJock> but it would be a learning experience for sure
<iwj> mvo: Yes.
<iwj> mvo_: What can I do for you ?
<mvo> iwj: see the last comment on bug #54234
<Ubugtu> Malone bug 54234 in update-manager "update-manager for edgy needs to upgrade dpkg/apt before calculating the upgrade to support the new "breaks" - otherwise the upgrade may fail" [High,In progress]  http://launchpad.net/bugs/54234
<iwj> Yes, from mdz, I saw :-/.
<mvo> iwj: I was going to talk to you about the Plan B. what needs to be done to emulate the brekas for the packages that use it currently ?
<iwj> To _emulate_ it ?
<mvo> iwj: well, to make sure that stuff does not break whitout breaks (sorry for the clumsy way to express it)
<iwj> The workaround is usually to turn the Breaks into Conflicts and hope that this doesn't make things too badly unupgradeable
<gardengnome> LaserJock: you bet.
<iwj> Another option is to leave out the dependency entirely.  Very rarely it's feasible to do some approximation with Depends.
<mvo> iwj: right. if we go without breaks, we should try to get this done for the beta and change the package + the upgrader. what do you think?
<iwj> I don't understand.
<iwj> Get what done for the beta ?  Change which package ?  Change the upgrader in which way ?
<mvo>  iwj: well, if we don't want Breaks in main we need to change the current packages that use them. and the upgrader would not use the backports 
<iwj> Yes.
<iwj> That seems to be the plan now.
<iwj> Do you mean you want to push those changes into the beta ?
<iwj> I'm very tempted to say `for these packages, just leave the Breaks alone'.
<iwj> Because putting back the Conflicts will regress the bugs that were fixed by adding Breaks and probably won't really help anything very much.
<iwj> But everyone else seems to think I'm mad for suggesting that it might be better to have a dependency relationship not actually represented and acted on.
<mvo> iwj: well, with the apt in dapper things will break badly because dpkg is not run with --auto-deconfigure
<mvo> iwj: so we need at least this backported if we leave them in
<iwj> Oh, damn.
<iwj> Well, that's still no good, is it, because that implies the whole arch-any tarball thing.
<mvo> iwj: well, the current solution works, its just ugly and it fails without network. 
* mvo whishes we would have speced that earlier within the breaks spec :/
<mvo> iwj: so its either a) remove the breaks entirely b) keep the things as they are but break non-network installs c) try to implement the full solution
<mdz> I expect that all of the Breaks we currently have can be converted to conflicts without major issues
<mdz> we can hint them in the upgrader if necessary
<rodarvus> Kamion, mdz: I'd like to request beta freeze exception for xorg. The only change is the addition of a 'Replaces: xutils' to x11-common
<iwj> mdz: Yes, but do we mind doing that now, two days before the beta ?
<rodarvus> leaving it as is is harmless, just for reference, but leaves an outdate xutils package on your system
<rodarvus> the (very small) debdiff is available at http://people.ubuntu.com/~rodarvus/patches/xorg-7.0.22ubuntu10-7.0.22ubuntu11.patch
<mvo> iwj: well, the alternatives seems to be equaliy problematic
<mdz> iwj: I mind that a lot less than trying to implement the necessary bits to do it correctly in the same span of time
<mdz> rodarvus: does this affect upgrades from dapper?
<rodarvus> yes.
<mdz> rodarvus: go ahead and upload (it'll be held for manual approval) and set the beta milestone on the bug
<iwj> mdz: OK then.
<rodarvus> mdz, will do, thanks!
<iwj> mvo: Do you want me to deal with these ?
<iwj> I mean, the packages with Breaks ?
<iwj> I'll leave the upgrader to you.
<mvo> iwj: I'm having a look now at the packages
<mdz> Kamion: ping
<tfheen> Kamion: please approve mvo's synaptic upload
<iwj> mvo: Just doing gnumeric now.
<mvo> iwj: thanks! 
<tfheen> Kamion: lvm-raid-uuid-partman-target-crack-thingabob> yes, beta.
<iwj> Do you want the rest or shall I do them ?
<Keybuk> tfheen: accepted
<tfheen> Keybuk: thanks.
<iwj> I should do m-f-l-all as it has a weird template thing.
* Keybuk will upload the udev and grub for the lvm-raid-crack-monkey
<iwj> mvo: hpijs is the one that I didn't breaksify, so if you fancy like looking at one do that one.  Let me know.
<LaserJock> dholbach: ping?
<mdz> mvo: tell me about bug 62461
<Ubugtu> Malone bug 62461 in gcc-4.1 "synaptic no longer builds after g++-4.1 (4.1.1-13ubuntu2) to 4.1.1-13ubuntu3 upgradae" [High,Unconfirmed]  http://launchpad.net/bugs/62461
<mdz> LaserJock: dog walk
<LaserJock> mdz: ah ;-)
<mvo> mdz: well, after the upgrade synaptic does not build anymore. rebuilding/reinstalling apt and rebuild synaptic again fixes it. my suspicion is a abi problem with the latest g++, but I havent investigated further yet
<dholbach> LaserJock: pong
<iwj> mvo: So are you doing hpijs or am I ?
<mvo> iwj: I can do it if you want
<LaserJock> dholbach: you fixed bug 61825 with your lates upload, right?
<Ubugtu> Malone bug 61825 in ubuntu-docs "Firefox start page still says '6.06 Dapper Drake'" [High,Confirmed]  http://launchpad.net/bugs/61825
<dholbach> LaserJock: oh yeah
<dholbach> LaserJock: you can close it, if you like
<LaserJock> dholbach: will do, thanks
<iwj> mvo: I don't mind, I just want not to duplicate the effort.
<mdz> mvo: has doko seen it?
<mvo> mdz: I discussed it earlier with him. I'm not sure if it is release critical because it can be worked around
<mvo> iwj: I just turn it into a conflict and make sure that the upgrader knows about those package to avoid accidental removal
<iwj> Right.  OK, I'll leave it to you.
<iwj> You need to make a similar note in the upgrader about gnumeric.
<iwj> New gnumeric and gnumeric-doc conflict with the old ones.
<mvo> iwj: gnumeric and the various ff-locale packages it seems
<iwj> Yes, but the ff-locale packages are dependencies of language-support-foobar so should be OK anyway, right ?
<mdz> mvo: yes, doesn't it already treat those specially because they're metapackages?
<mvo> iwj: yeah, they should
<mvo> mdz: not strictly, they are section: translations so no special handling (only section metapackages)
<mdz> mvo: it should
<mvo> mdz: *nod* I will fix that
<mdz> Riddell: is the koffice/powerpc issue on edgy_probs the result of the ruby breakage?
* iwj goes for dinner.  Goodnight everyone.
<mvo> bye iwj
<mhb> hello... can someone direct me to a person who's responsible for the files in /lib/firmware/ that get shipped with Edgy?
<LaserJock> mhb: I think most of that (if not all) comes from linux-restricted-modules
<LaserJock> and or linux-image
<LaserJock> anyway, the kernel packages
<zul> mhb: try #ubuntu-kernel
<mhb> ok, thanks
<mhb> I'll try it
<segfault> ho.
<blue-frog> hi can someone help me provide you with necessary info concerning ubiquity problems
<LaserJock> blue-frog: I'm not sure exactly, I'd just look at other ubiquity bug reports
<slomo_> Keybuk: hm, shouldn't cryptsetup work correctly with upstart now? i saw you closed the bug but it's still silently ignored at startup
<Keybuk> "silently ignored" ?
<slomo_> it's just not started and i have to start it by hand later
<Keybuk> "just not started" ?
<Keybuk> do you mean that the init script itself is not run?
<slomo_> yes
<Keybuk> you use cryptsetup ?
<Keybuk> can you confirm taht for me.  put "touch /dev/CRYPTSETUP.WAS.RUN" at the top of the init script for me
<Keybuk> and reboot
<ajmitch> morning
<bddebian> Heya ajmitch
<slomo_> Keybuk: ok, one moment :)
<slomo> Keybuk: ok, it's started but it doesn't ask for a passphrase or something
<Keybuk> right
<Keybuk> you are running 2:1.0.3-3ubuntu3 ?
<slomo> yes
<Keybuk> interesting
<Keybuk> could you put a set -x at the top
<Keybuk> see if you get any output anywhere
<Keybuk> should be on /dev/console (which will be tty8 if usplash is running, under usplash -- so don't boot with "splash")
<elmo> BenC: ping/help?
<slomo> Keybuk: ok, one moment
<BenC> elmo: pong
<mvo> mdz: because of #62461 my latest synaptic bugfix upload is FTBFS. a workaround would be a apt upload with no changes to rebuild it. after that synaptic should build again. is that ok for beta? the synaptic upload fixed a rather frequent segfault (lp: #62298)
<elmo> BenC: edgy's kernel isn't finding the root fs on davis :(
<BenC> elmo: which kernel version?
<Keybuk> elmo: what is the root fs?
<Keybuk> if it's /dev/md[0-9] * then fabbione fixed that a few hours ago
<elmo> Keybuk: this is edgy's kernel on dapper
<elmo> BenC: dunno, let me reboot into dapper
<Keybuk> elmo: ok, I'll shut up and sit in the corner then ;)
<BenC> elmo: needs at least 9.23
<slomo> Keybuk: ok, something more usefull now... it prints some stuff and if i looked fast enough it said "key reading error" while running cryptsetup which would ask for the passphrase then
<Keybuk> ok
<Keybuk> so that's your problem
<Keybuk> errrrrr......
<Keybuk> my soundcard just randomly played some crap
<slomo> Keybuk: caused by? and all the stuff was on tty1, not 8 :/
<Keybuk> which was from an ogg I listened to a few days ago
<Keybuk> creepy
<Keybuk> slomo: tty1 with usplash running or not running?
<mvo> Keybuk: do you run the python testsuit?
<Keybuk> slomo: no idea what it's caused by ... I don't care about cryptsetup, some cryptsetup bug
<Keybuk> mvo: ECONTEXT
<mvo> Keybuk: last time I got random crap from my soundcard it was from it
<mdz> mvo: no reason not to upload it
<elmo> argh, oh my good yaboot is SO MUCH SUCK
<Keybuk> mvo: nope, just sitting on IRC
<mdz> mvo: so long as the bug isn't forgotten
<slomo> Keybuk: without usplash running
<Keybuk> slomo: that's normal
<Keybuk> /dev/console is tty1 when no usplash
<mvo> mdz: I can assure you I will keep naging doko about it ;)
<Keybuk> and tty8 when usplash
<ogra> is theer any reason why my usplash switches to tty1 ?
<ogra> *there
<slomo> Keybuk: ok, but what in cryptsetup could cause this? it works when running the script by hand and doesn't when running from upstart
<ogra> it sits there quite longish ...
<Keybuk> ogra: tty1 ?  you see a getty?
<ogra> i see my login prompt
<Keybuk> slomo: no idea, cryptsetup is something I officially don't know anything about
<Keybuk> ogra: you run gdm?
<ogra> i first thought its a ltsp issue ... but i see it on the server as well
<ogra> gdm and ldm
<Keybuk> ogra: it does it with the gdm box?
<ogra> bot run /etc/init.d/usplash start in their initscripts
<ogra> no, before gdm starts up
<ogra> its sitting on tty1 for 1-2secs
<Keybuk> do both just run usplash start
<Keybuk> or do they run DO_NOT_SWITCH_VT=yes usplash start
<Keybuk> ? :p
<neutrinomass> Kamion: Sorry to ping but there's a person in #ubuntu-bugs with 2 ubiquity issues and for some reason /var/log/installer/syslog doesn't exist (and his /var/log/syslog doesn't contain a traceback) 
<ogra> Keybuk, they only run usplash start
<Keybuk> ogra: that would be why then
<Keybuk> update your gdm :)
<ogra> ok, and i have to add that to ldm too i guess :)
<ogra> thanks !
<Keybuk> yeah
<Keybuk> the switch is done when usplash is terminated on vt8
<Keybuk> obviously if it's being terminated to start a display manager, you don't want it to switch
<ogra> is there any chance we dont need to call start to stop it at some point ?
<ogra> dapper has an evil ltsp bug because i ddint know i had to call start ... :/
<Keybuk> not while we're using sysv-rc
<ogra> ok, so only unitl edgy+1 :)
<Keybuk> we should fix the fact that you can't run setupcon while usplash is running
<Keybuk> then we wouldn't need to stop usplash at all
<Keybuk> it'd die because of the VT flip
<ogra> heh
<AlinuxOS> After CD boot, Edgy shows messages like: Installer in text mode, Install in OEM mode. I woul like to translate them...but I think that these strings are not present in debian-installer...
<slomo> Keybuk: in general it does fd = 0; if(isatty(fd)) { .... foo = getpass("blabla"); if (! foo) explode (); }
<AlinuxOS> so which module is that ?
<Keybuk> slomo: that should be called with </dev/console ...
<Keybuk> which should be a tty
<elmo> BenC: yeah, it is 9.23
<BenC> elmo: What driver is it using for the disks?
<Kamion> mdz: hello
<elmo> BenC: sata_nv I think
<Kamion> (catching up on scrollback, be right with you)
<elmo> BenC: I'm just coming out of rescude mode and into real disk
<Kamion> AlinuxOS: gfxboot-theme-ubuntu
* AlinuxOS *hugs* Kamion 
<AlinuxOS> thank!
<AlinuxOS> you
<BenC> elmo: can you get dmesg and see if it mentions sata_nv?
<Kamion> tfheen: there's no synaptic upload there; do you mean apt?
<Kamion> tfheen: partman-target uploaded
<tfheen> Kamion: Keybuk did it already.
<tfheen> Kamion: is there an apt upload waiting for approval?
<tfheen> if so, could you pastebin the changelog?
<tfheen> (I can't remember having approved it, and mvo usually doesn't upload without asking, but maybe I'm forgetful)
<Kamion> +  * no-changes upload to make apt rebuild against latest g++ and
<Kamion> +    fix synaptic FTBFS (see bug: #62461 for details)
<tfheen> please accept that, yes.
<tfheen> with that, I'm off to bed.  It'll be a long day tomorrow.
<elmo> BenC: from edgy kernel?  it doesn't
<elmo> [   26.790032]  sata_svw 0001:05:0c.0: version 1.07
<elmo> ^-- is dapper
<mvo> Kamion: yeah, no changes, just some g++ oddness
<BenC> elmo: Ok, svw is what I expected
<elmo> BenC: yeah, sorry about the nv thing, that was crack
<BenC> elmo: svw was fixed in 9,23...it was crashing on my G5, and jbailey's
<mvo> tfheen: anything I can do to help with the livefs script? so that it gets useful auto-install information via apt-get install task^?
<BenC> it's working for both of us now
<Kamion> apt accepted
<elmo> BenC: davis' cdrom had come loose, so it was seeing any IDE drives - could that be relevant?
<mvo> thanks Kamion!
<BenC> elmo: Probably not, but who knows what kind of crack those ppc64's are on
<elmo> BenC: ah, yes, it is
<elmo> I put the disks in a machine with a working cdrom and it boots first time
<BenC> so edgy kernel is working now?
<elmo> so.  much.  crack.
<elmo> BenC: yes
<BenC> excellent
<elmo> well, not so much
<elmo> but details
<elmo> BenC: is there any point in filing a bug about that?
<elmo> BenC: (needing IDE for SATA to work)
<BenC> elmo: I'll leave that up to you
<mjg59> Kamion: So I picked UK in ubiquity and it's given me dvorak
<mjg59> Which I can deal with, but I'm sure others would be less happy :)
<Kamion> mjg59: current daily?
<Kamion> didn't happen last time I tried
<mjg59> Kamion: I just booted an old daily and then did apt-get install ubiquity
<Kamion> how old?
<Kamion> you might need to upgrade console-setup too
<mjg59> Ah
<mjg59> What's the easiest way to tell?
<Kamion> dpkg -l console-setup
<mjg59> 1.7ubuntu8
<Kamion> mjg59: hmm, it might be just too old but it might be something else
<Kamion> mjg59: would you mind going through the install again with a bit of debugging for me?
<mjg59> Kamion: I'll let the install complete and then reboot into the CD
<Kamion> ok, just note I'm not here much longer tonight
<mjg59> I'm at 62%
<mjg59> Oh, also, if it lets partitions get mounted, they seem to end up on my desktop twice
<Kamion> known and fixed gnome-vfs2 bug
<mjg59> Cool
<mjg59> I'll ignore that, then
<Kamion> it duplicated anything that was mounted by UUID, I believe
<mjg59> Hm.
<mjg59> Oh, recovery partitions still don't seem to be added to grub automatically
<mjg59> Though I thought I sent patches for several of them
<mjg59> Not sure if that was to Debian or Launchpad
<exarkun> I can't get limits.conf to work.  There doesn't seem to be a manpage, either.  Also the comments in the file seem to be wrong.  Can someone point out the existing documentation that I have overlooked which explains this?
<bddebian> Limits are Evil(tm) and should not be used :-)
<exarkun> I want to change the file limit to unlimited, instead of 1024 :)
<Kamion> mjg59: I think you did, but I also don't think I ever applied them
<Kamion> hassle me next week and I'll check
<bddebian> exarkun: Then don't use the macro
<mjg59> Kamion: Ok, no problem
<mjg59> Kamion: What debugging do you want on the install?
<exarkun> bddebian: You've lost me.
<mjg59> This is about to finish, so I'll restart it
<bddebian> exarkun: You want to globally change MAXPATHLEN or something?
<Kamion> mjg59: edit /var/lib/dpkg/info/console-setup.config and stick 'set -x' near the top; then start the installer using 'sudo env UBIQUITY_DEBUG ubiquity'
<Kamion> bddebian: doesn't sound like you know what limits.conf is ...
<Kamion> /etc/security/limits.conf, to expand a little
<exarkun> bddebian: Sorry, the open file descriptor limit, not the maximum path length.
<Kamion> this is ulimit, not sysconf stuff
<bddebian> Ohh, limits.conf, I thought you said limits.h, sorry
<mjg59> Kamion: With or without updated console-setup?
<exarkun> bddebian: 'ulimit -Hs unlimited'
<exarkun> er
<exarkun> Hn :)
<Kamion> mjg59: exactly the same as you did before
<Kamion> mjg59: er, obviously the command should have been 'sudo env UBIQUITY_DEBUG=1 ubiquity'
<Kamion> mjg59: make sure to use a throwaway password - with debconf debugging turned on, it shows up in syslog
<Kamion> mjg59: then I need /var/log/syslog
<Riddell> mdz: yes, ruby is blocking koffice on ppc
<mjg59> Kamion: No problem
<mjg59> Restarting now
<Kamion> thanks
<Kamion> I *think* 1.7ubuntu8 should be enough, although 1.7ubuntu12 should give better defaults
<Kamion> but that shouldn't matter in this case
<Kamion> mjg59: the syslog from right after you hit next on the keyboard page should be enough, btw
<exarkun> So, any ideas?
<Kamion> exarkun: what limits.conf line are you trying exactly?
<Kamion> and what comments are you taking issue with?
<Kamion> (I'm not quite an expert here, though I can sometimes play one on TV)
<LaserJock> Kamion: really? I don't even get to do that :/
<LaserJock> ;-)
<exarkun> Kamion: "www-data        hard    nofile          8192" (with tabs)
<Kamion> apache probably doesn't start a PAM session
<exarkun> Kamion: the comments seem to indicate this is an appropriate line, my only issue with them is that it does not change my open file limit :)
<Kamion> limits.conf only takes effect so
<Fade> this'd prolly be for twisted
<Kamion> er
<Kamion> for stuff that starts a PAM session
<Fade> :)
<exarkun> Kamion: Login doesn't?  I thought it defined baseline defaults :/
<Kamion> which is typically only things that correspond roughly to user logins
<Kamion> exarkun: your web server surely isn't invoked from login though?
<exarkun> I'm hoping to affect the limits applied to a new login shell, as provided by sshd.
<elmo> can someone try the test ruby program on davis please?
<Kamion> oh, well that should work, but why are you logging in directly as www-data?
<exarkun> Hmm
<elmo> ^benc/riddell/fabbione/whoeverelse was looking at this
<exarkun> Okay, that was not quite true.
<exarkun> I am logging in as my user and then sudo'ing to www-data... I suppose that might be the problem
<zjohnson> hmmm
<exarkun> I shall attempt to log in as www-data directly
<Kamion> yes, sudo doesn't start a PAM session - it only uses PAM for authentication and account management
<mjg59> Kamion: http://www.codon.org.uk/~mjg59/tmp/keyboard_syslog
<exarkun> What do you know, that worked.  Thank you :)
<mjg59> Kamion: Works fine in the test field, breaks on the next page
<Riddell> elmo: I get connection refused sshing to davis
<Kamion> exarkun: pam_limits only provides a session component, so there's probably no easy way to make it work with sudo
<Kamion> The requested URL /~mjg59/tmp/keyboard_syslog was not found on this server.
<mjg59> Kamion: http://www.codon.org.uk/~mjg59/tmp/keyboardvsyslog
<mdz> Kamion: were you able to learn more about the ruby issue?
<mjg59> Kamion: http://www.codon.org.uk/~mjg59/tmp/keyboard.syslog
<Kamion> mdz: I think BenC is already way ahead of me
<mjg59> (Argh, swapping between qwerty and dvorak makes me hurt)
<mdz> BenC says we can work around it by upgrading the kernel, but somehow I don't think elmo will be too thrilled with that suggestion
<Kamion> I just found that it worked if I turned threading support off
<Kamion> but that's not actually viable
<Kamion> mdz: elmo already seems to be on the case though?
<mdz> so he is
<Kamion> but no, I didn't get any further than what I posted to the bug
<Kamion> mjg59: that's a 403
<mjg59> Kamion: Nngh. Hang on...
<mjg59> Kamion: Ok, now
<Kamion> right, better ...
<elmo> Riddell: ah, excellent point
<elmo> Riddell: it'd help if it wasn't fscking, sorry
<zjohnson> ok
<zjohnson> I am trying to add --enable-ssl in the debian/rules of the mutt pkg
<zjohnson> (to the configure command)
<elmo> Riddell: up now
<Kamion> mjg59: ok, I think I see what's happening - console-setup/variant is marked seen (it probably shouldn't be) and then console-setup SUBSTs in a list of choices none of which are the preseeded value, so debconf picks the first one which (incorrectly, probably) is dvorak
<Riddell> thanks elmo, trying now
<mjg59> Kamion: Ok
<Kamion> mjg59: could you do 'mount -o loop -t squashfs /cdrom/casper/filesystem.squashfs /mnt; chroot /mnt debconf-show console-setup | grep variant:; umount /mnt' for me?
<mjg59> * console-setup/variant: U.S. English
<mjg59>   console-setup/variantcode:
<Kamion> right
<Kamion> I think putting this just before the return in /usr/lib/ubiquity/ubiquity/components/console_setup.py:prepare() should do it:
<Kamion>         self.db.fset('console-setup/layout', 'seen', 'false')
<Kamion>         self.db.fset('console-setup/variant', 'seen', 'false')
<elmo> Riddell: that seemed to work?
<Kamion> probably the quickest workaround, anyway
<Riddell> elmo: yep, does indeed
<elmo> ok, well the buildds are on the same kernel now too
<elmo> please have whoever can give back the appropriate builds
<elmo> I'm going home
<Riddell> elmo: great, thanks
<Riddell> Kamion: could you give back ruby1.8 on ppc then
<Kamion> Riddell: no, I'm not in launchpad-buildd-admins
<Riddell> oh, sorry
<Riddell> tfheen or Keybuk or infinity about?
<mjg59> Kamion: Doesn't /seem/ to have made any difference
<mjg59> But I may have screwed up - I don't know python
<mjg59> Would I need to reboot?
<mjg59> Again, it's fine in the keyboard layout window
<mjg59> But breaks after I hit forward there
<Kamion> mjg59: could you update the debug log?
<mjg59> Kamion: Yup, give me a sec
* zjohnson finds out gnutls support already exists..
<zjohnson> blar =)
<mjg59> Kamion: Done - same URL
#ubuntu-devel 2006-09-27
<mdz> Riddell: I can do that
<mdz> Riddell: done
<Kamion> mjg59: right, you'd need to reboot I'm afraid
<Kamion> mjg59: I could fix that, but it would break preseeding
<Kamion> mjg59: alternatively:
<mjg59> Kamion: Ok
<Kamion> mjg59: (echo RESET console-setup/layoutcode; echo RESET console-setup/variantcode) | sudo debconf-communicate
<mjg59> Kamion: I've no problem with rescuing it myself, I just want to make sure it doesn't happen to other people :)
<mdz> Riddell: for future reference: https://launchpad.net/people/launchpad-buildd-admins
<Kamion> ... should kill off console-setup's memory of this
<Kamion> mjg59: if you wouldn't mind then trying it once more, just to confirm before I upload the fix
<mjg59> Kamion: Still seems broken
<mjg59> Want debug log again?
<Kamion> yeah, why not
<Riddell> thanks mdz 
<mjg59> Kamion: Ok, done
<mjg59> Kamion: Oh - is there any hope of us getting a font that means I don't have missing glyph boxes in ubiquity? :)
<Kamion> mjg59: yeah, I've been wondering about that - it's just Dzongkha
<Kamion> advice gratefully appreciated, otherwise I'll probably just exclude the language
<mjg59> If we can't find a font with the glyphs, it's probably the right answer
<mjg59> Otherwise there's no way to complete the install in any case
<Kamion> there's ttf-dzongkha
<sabdfl> if i've mounted a remote server using the Places menu ("Connect to Server...") should those files also be accessible through the Open File dialog?
<Kamion> at 600KB
<mdz> mjg59: does the backtrace in bug 56587 help at all?
<Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Confirmed]  http://launchpad.net/bugs/56587
<Kamion> mdz: any opinions on adding the above?
<mjg59> We should probably find (or write) a tool that can tell us if all the characters in a po file are in the fonts
<Kamion> I believe it's what the d-i team is using
<mjg59> mdz: Not really
<mjg59> sabdfl: If the application understands gnome-vfs and has told the filechooser that, yes
<mjg59> mdz: x86emu blows up with some bioses. We only see it on amd64 because we use vm86 on x86
<mdz> sabdfl: firefox in particular won't
<mjg59> mdz: I've disabled the code that's likely to trigger it, since we don't use it anyway, but I'll want to track it down at some point because it hurts us in vbetool
<mdz> sabdfl: oo.o should, at least when running native
<mdz> mjg59: that's in your bzr?
<mjg59> mdz: Yup
<mjg59> mdz: The bzr needs a trivial fix to compile
<sabdfl> yeah, it's t-bird that i noticed this in
<mdz> gnome-vfs is solving a problem in the desktop which should probably be solved at a lower level
<Kamion> mjg59: ok, that will go away with a newer console-setup - it's because it's sucking the keyboard configuration out of xorg.conf, which I've stopped doing
<Kamion> I'll bump the dependency a bit
<mdz> but the assumptions which would be broken by doing so make my head spin
<mjg59> Kamion: Ah, ok
<mdz> mjg59: how bad is it for affected users?  they see a black screen all the way until X starts?
<mjg59> mdz: The plan is to redevelop gnome-vfs so that it's accessible via FUSE
<mjg59> And then have some mechanism for providing those paths to applications that don't understand gnome-vfs natively
<mdz> mjg59: it seems likely that there are all sorts of filename-handling routines which won't cope with a URL though
<mjg59> mdz: Yeah, that's the likely behaviour
<mjg59> mdz: Right, so they'll never see one
<mdz> and suddenly we're all running plan 9!
<mjg59> The reason not to just do it all in FUSE is because there's no nice way to do async operations via POSIX
<mjg59> And you really want async file i/o when the file store is a random webdav server on a bit of string
<jdub> mdz: firefox has gnome-vfs support, and some of the other distros have native dialogue patches
<mjg59> So gnome-vfs applications get to do things properly, and non-aware ones get to access the files anyway (just with a bit more suck)
<mdz> jdub: oh, so it does.  network servers don't show up in its open dialog though
<mjg59> mdz: I'll try testing the usplash changes here in a bit - I can force x86emu on a 32 bit system
<jdub> mdz: perhaps they don't turn on that smarts in the filechooser because they can't tell if they have gnome-vfs support? not sure.
<jdub> i might be unreliably bad, too, mind
<lifeless> mjg59: aio
<lifeless> mjg59: unpacking that: there is too async file operations via posix. 
<mdz> mjg59: can we notice if usplash segfaults and clean up after it somehow, to be robust against this problem in general?
<Kamion> mdz,tfheen: could you eyeball http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.1.24.diff for me? fixes mjg59's UK keyboard selection issue above, which I think is beta-RC
<mjg59> mdz: We could add a segv handler to it and chvt back to another vt
<mjg59> Keybuk: Ouch. Another reason for blacklisting nvidia is because it takes up *4MB* of kernel memory
<mjg59> Which is unswappable
<Kamion> mdz,tfheen: also, do I want to accept these changes turning Breaks back into Conflicts?
<Kamion> that's gnumeric, mozilla-firefox-locale-all, hplip
<Kamion> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
<Kamion> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
<Kamion> dpkg: error processing cupsys-driver-gutenprint (--configure):
<Kamion> ^-- breaks amd64 livefs build
<Kamion>  subprocess post-installation script returned error exit status 1
<Keybuk> mjg59: I'm not blacklisting it until X loads it
<Keybuk> which it doesn't
<Kamion> somebody else please fix
<Kamion> I need to go home
<Kamion> I've started live CD builds, which will presumably only be useful for amd64 and powerpc
<Kamion> er, for i386 and powerpc, I mean
<mjg59> Keybuk: Yes it does
<mjg59> I've just tested it
<Keybuk> mjg59: it doesn't here
<Keybuk> I also just tested it
<Keybuk> I get three flickers, and then a "X could not start"
<mjg59> Keybuk: Did you blacklist nvidia and nvidia_legacy?
<mjg59> Otherwise nvidia_legacy will get loaded and X will fail because of the ABI mismatch
<Keybuk> I just rmmod'd the running one and started X
<Keybuk> so no module was loaded
<mjg59> Keybuk: I've just tested here with -10. It loaded nvidia.
<mjg59> Does your system use nvidia or -legacy?
<Keybuk> nvidia
<mjg59> Ok
<Keybuk> by what process does it load the module?
<Kamion> I've uploaded that ubiquity change; somebody please accept it if it's ok
<mjg59> Keybuk: I just did sudo rmmod nvidia; X
<mjg59> And got running X
<Keybuk> *tests again*
<Keybuk> nope, still not starting
<mjg59> I assume it uses the same mechanism that other drivers can use to trigger the loading of the DRM module
<mjg59> Keybuk: What's the error?
<Keybuk> Fatal server error:
<Keybuk> Caught signal 11.  Server aborting
<Keybuk> sweeeeeet
<mjg59> Ha
<mjg59> I think you have other problems
<Keybuk> the unusual thing here is that there are two identical graphics cards in the machine
<Keybuk> maybe the auto-loaded can't cope with that
<mjg59> I can't see why it would make a difference
<Keybuk> *shrug*
<Keybuk> anyway I'm not going to blacklist nvidia
<Keybuk> we can consider it for edgy+1
<mjg59> Keybuk: I consider it somewhat less than ideal that we break suspend and resume for people because of a non-free driver that they may not even be using
<Keybuk> suspend and resume are happy features that are nice if they work
<mjg59> Keybuk: How about we blacklist by default and then document how to disable the blacklist in the same place that we document how to enable the nvidia driver?
<Keybuk> X starting is a mandatory feature
<mjg59> X starts out of the box
<Keybuk> no, I'm not going to blacklist this by default this close to the release
<Keybuk> let's consider this for edgy+1
<Keybuk> we're about to make a beta release
<Keybuk> now is not the time to start fiddling with hardware support
<mjg59> Keybuk: This appears to be causing regressions
<Keybuk> it's not causing regressions
<Keybuk> because we loaded it by default in dapper too
<mdz> Kamion: breaks into conflicts -> yes
<mjg59> Keybuk: And the code has changed massively since then
<mdz> Kamion: I looked at your diff but I'm afraid I would need to look at quite a bit more to understand the issue
<mjg59> Code that we can't debug
<mdz> mjg59: is it segfaulting after it has forked, or can we just check its exit code?
<mjg59> mdz: usplash? After it's forked.
<mjg59> Hm. I /think/.
<Keybuk> mjg59: at this point suspend and resume are still mythical features that work if you're lucky
* mjg59 checks
<mjg59> Keybuk: They work on ~80% of laptop hardware
<Keybuk> it seems better to document that blacklisting nvidia may help there, rather than "oh, if you want X to load, you'll need to remove this file"
<mjg59> Keybuk: "If you want X to load after you've already rewritten your config file, you also need to edit this other config file"
<mjg59> (Except that in my case, you don't even need to do that)
<mjg59> mdz: Wait a sec. Usplash doesn't fork.
<mjg59> mdz: So yeah, just check the return code and stick a chvt in the startup script?
<mdz> mjg59: that will clean up even after svgalib borkage?
<mjg59> mdz: Nope
<mjg59> mdz: That's actually slightly difficult. We could hack something with vbetool.
<mjg59> Keybuk: I've just straced my server startup - the driver checks /proc/modules (eww) and then execves modprobe
<Keybuk> ahh
<mjg59> Can you do an strace -f X and see what your one does when nvidia isn't loaded?
<Keybuk> and modprobe will therefore obey the blacklist
<Keybuk> so won't load the nvidia module
<Keybuk> which is why X segfaults
<Keybuk> ?
<mjg59> Keybuk: if modprobe is explicitly called, the blacklist is ignored, no?
<mjg59> I've got it blacklisted, but this still succeeds
<Keybuk> varies
<Keybuk> if an init script leaks MODPROBE_OPTIONS for example
<Keybuk> though of course, I don't have it blacklisted here, so it's not that
<mjg59> Keybuk: if I modprobe eth1394, I get eth1394 loaded
<Keybuk> could be an honest race condition
<mjg59> Mind doing the strace and seeing what happens?
<Keybuk> whoah, that crashed the entire machine
<Keybuk> hard reboot too
<lifeless> bada-boom
<Keybuk> mjg59: I'm *really* not comfortable about relying on this to be auto-loaded
<Keybuk> I'm sorry
<mjg59> Keybuk: And I'm *really* not comfortable with us screwing over people who aren't even using the driver
<Keybuk> then you should have spoken up at the START of the release process
<Keybuk> not this close to the end
<mjg59> I only got the first bug about this last week
<Keybuk> this will break people who upgrade
<mjg59> I hadn't realised it was the default
<Keybuk> it's always been the default
<mjg59> Keybuk: It certainly hasn't. People used to need to add nvidia to /etc/modules
<Keybuk> that was probably simply because we didn't have as reliable hardware detection as we do now
<mjg59> nvidia only added modaliases to their drivers fairly recently
<Keybuk> could be that too
<Keybuk> fairly recently is still before dapper though
<Keybuk> so dapper released like this
<Keybuk> which means if we suddenly blacklist the module, it appears that many people's machines will begin crashing on upgrade
<Keybuk> I'm totally not happy about that
<Keybuk> maybe I'm jaded, but suspend is a "would be nice"
<Keybuk> X is a "must have"
<lifeless> you're jaded
<LaserJock> totally
<Keybuk> ok, just tested again
<Keybuk> first time it actually did load the module
<Keybuk> I rmmod'd, and restarted X
<mjg59> Keybuk: But X works fine unless the user has enabled code we have no practical way to support
<Keybuk> and that time X crashed
<Keybuk> I'm going to try booting with the blacklist to see whether it's an rmmod problem
<mjg59> Keybuk: So in your case, it could actually be that the module doesn't clean up after itself?
<Keybuk> mjg59: so?  a lot of users are enabling this code
<Keybuk> and we're planning on enabling it by default in edgy+1, apparently
<mjg59> Keybuk: We *are*?
<Keybuk> Mark *really* wants bling for edgy+1
<mjg59> Mark can ask nvidia for the source, then
* Keybuk blames you and your shiny compiz of doom
<Keybuk> I believe Mark is
<mjg59> Excellent
<mjg59> When he gets it, I'll remove my objection to turning it on
<Keybuk> no, crashed immediately on that reboot
<Keybuk> checked, and it definitly was blacklisted and not in lsmod
<mjg59> Keybuk: Can you power cycle?
<Keybuk> mjg59: sure
<mjg59> Rather than just warmbooting?
<Keybuk> I'll leave it off for > 3 s :p
<Keybuk> hard-lock up :-/
<mjg59> Are these drivers made out of string, or something?
<mjg59> Jesus
<Keybuk> I'll try something
<Keybuk> I'll lift one of the graphics cards out
<mjg59> Keybuk: Ok
<mjg59> Keybuk: Of course, an alternative would be to add an init script to nvidia-glx
<Keybuk> this feels like a race condition between the module and the X server; which is scary enough in itsself
<mjg59> Keybuk: That checks for the driver in use and then loads the module before X starts
<mjg59> Basically, we just want the module load to be conditional on information that udev doesn't have
<Keybuk> why not use a modprobe install rule?
<mjg59> Sure, that would work
<mjg59> We could do with a small tool that told us which driver was in use
<mjg59> That would actually be useful for suspend/resume in any case
<Keybuk> install nvidia grep 'Driver \"nvidia\"' /etc/X11/xorg.conf && module -Qb nvidia
<Keybuk> or something
<Keybuk> hmm
<Keybuk> worked just fine with just the one in
<Keybuk> let me try another restart
<Keybuk> fine again
<Keybuk> so an SLI-triggered bug
<mjg59> nvidia = gash
<mjg59> Can you give the modprobe rule a go?
<Fade> better than ati. ;/
<Fade> I have hopes that amd will cause ati to open their drivers, though.
<Keybuk> I don't have any particular objection to the modprove rule
<Keybuk> prove?  probe! :p
<mjg59> Keybuk: Ok, that leaves me without any objections
<mjg59> Keybuk: Needs to be done for nvidia_legacy as well
<mjg59> And possibly fglrx
<Keybuk> can you file a bug on module-init-tools to remind me?
<mjg59> Will do
<lifeless> with sli, are you not meant to load the driver just once ?
<Keybuk> right
<Keybuk> it has one Device section
<lifeless> because its one card, honest.
<Keybuk> and the PCIe id of the first card
<Keybuk> it finds the second card because it's joined to the first one
<Keybuk> I actually don't have it enabled on Linux
<Keybuk> so in theory, the second graphics card sits there doing nothing
<ogra> hmm, doesnt look like we'll see final isos tonight ...
<ogra> mdz, do you plan to kick off alternate builds after ubiquity is done ? if so, could you also trigger edubuntu builds, so i can see if anything size wise changed right after i get up ?
<keebler> Which one of you is Colin watson?
<Fujitsu> Kamion.
* keebler Kamion Heya, would it be possible to adapt the new 256color Usplash to Dapper?
<keebler> Crap
<keebler> Damn dentists.
<ogra> he's gone for the day
<keebler> Oh.
<Keybuk> gone for the *night* would be better
<Keybuk> even Colin has to sleep sometimes, to rest that planet-sized brain of his
<ogra> right, and moving while releasing a beta is hard stuff
<Seveas> keebler, you can backport it yourself. There will not be an official 256-color usplash for dapper
<keebler> Seveas: Ok.
<keebler> Heh, I don't suppose there is an FAQ to help me is there? 
<keebler> I've only been using Ubuntu for 5 months. Was a BSD junkie for the last 8 years.
<keebler> Seveas: Or a good start would be where can I aquire the usplash used in edgy?
<Seveas> keebler, add a deb-src line for edgy to your sources.list and apt-get source usplash
<ogra> keebler, there is the ubuntu packaging guide shipped in your docs and use the source Seveas just pointed out to build a backport
<Seveas> or live on the bleeding edge and use the main bzr branch
<mdz> ogra: yes, I do plan to do that
<ogra> mdz, thanks then i'll get some hours of sleep now and check the isos tomorrow :)
<bddebian> Heya
<jdong_> what does nautilus-cd-burner use to burn data DVD projects?
<jdong_> just straight growisofs -Z device <dir>?
<desrt> E: Couldn't configure pre-depend belocs-locales-bin for locales, probably a dependency cycle.
<desrt> nice!
* jdong_ wondering if just dragging a VIDEO_TS folder into nautilus and burning it would generate a working DVD
<Keybuk> jdong_: probably not
<Keybuk> DVDs are quite complex
<Keybuk> the isofs has some odd properties, iirc
<jdong_> hmm
<Keybuk> DVD players actually ignore the filesystem
<Keybuk> instead they begin playing at particular blocks, and need padding for timing, etc.
<jdong_> :-/
* jdong_ hates DVD's with a passion now
<Keybuk> ffmpeg -i $INPUT -target pal-dvd -bf 2 $FILE.mpg
<Keybuk> mplex -f 8 -o /dev/stdout background.m2v background.m2a | spumux -v 2 spumux.xml > background.mpg
<Keybuk> dvdauthor -o $DVD -x dvdauthor.xml
<Keybuk> mkisofs -dvd-video -o $DVD.iso $DVD
<Keybuk> growisofs -Z /dev/hda=$DVD.iso
<Keybuk> -- 
<jdong_> hmm
<Keybuk> is my "make a video DVD" recipie
<jdong_> I've seen it just done with growisofs before
<Keybuk> the -dvd-video switch to mkisofs is *very* important, it doesn't work on non-computers without it
<jdong_> without mkisofs first...
<jdong_> hmm
<jdong_> well, better not to risk it
<Keybuk> growisofs will call mkisofs if you give it a directory instead of a file
<Keybuk> so you could do growisofs -Z /dev/hda -dvd-video $DVD
<Keybuk> but I prefer having the iso to check as an intermediate step
<jdong_> mmkay
* jdong_ leaves the GUI appeal of nautilus
<moco> are there any reasons behind the entry 'evolution-2.2.desktop' still in /usr/share/applications whilst it does nothing but duplicate evolution.desktop? Is that some chance the team forgot to remove it when moving up to higher version of Evo?
<LaserJock> moco: check out the last comment of bug 57628
<Ubugtu> Malone bug 57628 in evolution "there are multiple menu entries for evolution in a new edgy install" [Wishlist,Confirmed]  http://launchpad.net/bugs/57628
<moco> thx
<mdz> Keybuk: oddly enough, growisofs -dvd-compat doesn't imply mkisofs -dvd-video
<zul> wheee...xen from ubuntu-2.6 git works http://70.29.61.171/ubuntu/Screenshot-1.png
<jdong_> mdz / Keybuk: right, -dvd-compat doesn't do the trick... In fact my dvd players don't care much about it, but mkisofs's -dvd-video switch is indeed essential.
<jdong_> and indeed dragging some VIDEO_TS/AUDIO_TS into nautilus-cd-burner does not make a working dvd video disc
<jdong_> zul: do you know if anyone's working on xen wrappers for fglrx or if that'll ever happen?
<zul> jdong_: not sure for fglrx but nvidia yes..
<jdong_> zul: right; I saw the work going into nvidia
<jdong_> oh well....
<fabbione> elmo: i am on it
<fabbione> ok i see it has been done already
<zul> night
<fabbione> zul: night
<fabbione> mdz: can i declassify #61861 as non beta blocker?
<mdz> bug 61861
<fabbione> mdz: it's basically a bug on dapper kernel that's triggered by ruby on ppc
<Ubugtu> Malone bug 61861 in ruby1.8 "ruby1.8: fails to build on ppc under 2.6.15 kernel" [Medium,Confirmed]  http://launchpad.net/bugs/61861
<mdz> fabbione: if it's able to build after elmo's changes, then yes
<mdz> it was only a blocker because of the build failure
<fabbione> it has been fixed upgrading to .17 davis and buildd
<fabbione> yeah exactly
<fabbione> it's not an issue anymore
<fabbione> see RT #16838 too
<fabbione> mdz: demoted
<mdz> thanks
<fabbione> no problem
<fabbione> i guess the 2 sparc kernel bugs will wait after beta..
<fabbione> mdz: bug #62485 is worth a ReleaseNote
<Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  http://launchpad.net/bugs/62485
<fabbione> (beta)
<fabbione> basically they need a new OBP
<fabbione> (BIOS)
<mdz> fabbione: ->Mithrandir
<fabbione> oky
<bluefoxicy> has anyone noticed there's a voice print recognizer for pam (but it's defunct?)
<bluefoxicy> I was thinking, cheap biometric authenticator
<jldugger> "my voice is my passport" ;)
<HrdwrBoB> verify me
<bluefoxicy> it was speaker, password, and password length sensitive
<bluefoxicy> I don't get the last two
<bluefoxicy> you're speaking your password, those aren't secure variables.
<bluefoxicy> The first is, until someone records you.
<jldugger> id just be happy if my fingerprint reader worked
<jldugger> there's a pam module for that too, and its not defunct, but its been sitting in debian's wnpp for over a year i believe
<bluefoxicy> I'd honestly love a secure client-server signature verification mechanism.
<bluefoxicy> handshake would be like
<bluefoxicy> you have a GPG key, the authenticator has your UID, username, GPG key ID and fingerprint
<bluefoxicy> (your username may or may not be an identifier on your gpg key; in general I fancy e-mail address but for most systems where you have to be a user of the system a particular user name is more secure)
<bluefoxicy> authenticator says, "Who are you?  Jakub?  OK here's 1024 bytes of shit, sign it for me."
<bluefoxicy> if it doesn't know who the hell Jakub is it just discards the signature and says "Nope don't think you fit in"
<bluefoxicy> if jakub's signature is wrong it does same
<bluefoxicy> if Jakub is a user; it can locate his key; the finger print matches; and Jakub's signature response is good; it allows Jakub to log in.
<bluefoxicy> the 1024 bytes of junk is RANDOM and the GPG key is established through PKI or PSK depending on need so replay attacks, MiMs, and all kind of other stupid crap don't work
* fabbione patiently waits for his OBP/ALOM to upgrade
<bluefoxicy> jldugger:  there's a GPG key PAM module but I think it works like "Verify my password really unlocks my private key," which to me looks like "open a goatse-wide security hole in the trust model of this system"
<jldugger> i really dont know a lot about pam or gpg
<bluefoxicy> I really need to learn to write pam modules that don't suck
<bluefoxicy> it was my intent to write a pam module that enforced hold timing of log-ins
<bluefoxicy> that is, you log in on TTY1, fail, "wait 3 seconds" no screw that log in on TTY 2 and you're on by the time you time out
<bluefoxicy> same with ssh, 300 concurrent connections and only 1 has to hit, 3 seconds.
<bluefoxicy> what I want is that 3 seconds is applied across the board except for at the console
<bluefoxicy> if you try again, we don't even check your password; we just delay and go "Nope don't know who you are"
<HrdwrBoB> bluefoxicy: that would piss me off no end
<bluefoxicy> (when 3 months YOU spend brute forcing a 3 character long alphanumeric password, look as l33t, you will not)
<bluefoxicy> HrdwrBoB:  in the worst case you could DoS external connections over ssh
<HrdwrBoB> you're erring too far on the security vs ease of use
<bluefoxicy> but you would have to know the username you're attacking
<bluefoxicy> trying to log in as bauoseu is going to lock out... well nothing, that user doesn't exist on any sane system
<bluefoxicy> HrdwrBoB:  I said on the console it would allow it
<HrdwrBoB> yeah, but people often get their passwords wrong
<HrdwrBoB> even via ssh
<bluefoxicy> sit your ass in front of the machine and log into gnome and you're good to go even if you're under attack and the attacker is failing at your user account
<bluefoxicy> yes but on ssh the single ssh connection you make waits 3 seconds now
<bluefoxicy> and then says "failed to authenticate"
<bluefoxicy> if you can type really, really fast you can start another ssh session and get logged in within that 3 seconds
<bluefoxicy> more usefully, an attacker can make 30 ssh connections at once and launch attacks in parallel; and if he can do 30 at once x 10 times a second, that's 300 attacks a second
<HrdwrBoB> 300/s is SFA
<infinity> So, you basically just want PAM locking. That sounds trivial to implement.
<bluefoxicy> it's highly unlikely you're actually going to be dumb and spend hours trying to ssh in
<bluefoxicy> when the solution is "hold on for 3 seconds"
<jdong_> bluefoxicy: I doubt you can do parallel SSH brute forcing with decent efficiency
<bluefoxicy> especially since you have to willfully kill/restart the ssh client or use another terminal to ssh in real fast to make the window (as I said, ssh does make you wait when you get it wrong)
<infinity> jdong_: It gets attempted on my machines several times weekly.
<bluefoxicy> jdong_:  as do I; but I prefer "I can guarantee" to "I doubt"
<infinity> jdong_: To the point of saturating my DSL sometimes.
<jdong_> infinity: wow... that's phenomenal indeed... my ssh has remained relatively unattacked
<bluefoxicy> infinity:  yeah, I tried based on pam-audit and failed hard
<infinity> bluefoxicy: Check for lockfile, spin until lock released.  Stack pam_foreground appropriately to bypass your pam_locking for foreground console users.
<jdong_> umm, why doesn't the linux-server metapackage pull in the latest  kernel?
<bluefoxicy> yeah
<infinity> jdong_: Does for me.
<jdong_> oh hah
<jdong_> silly me
* jdong_ reboots server
<bluefoxicy> ugh. Malone 17297 is annoying.
<Ubugtu> Malone bug 17297 in synaptic "Orphan Search" [Wishlist,Needs info]  http://launchpad.net/bugs/17297
<bluefoxicy> I'm beginning to think I'm actually the only person in the universe that ever actually cleans old packages off his disk
<bluefoxicy> (no, the auto-removable packages stuff is NOT doing it for me, I've cleaned out all its suggestions already)
<LaserJock> bluefoxicy: I just reinstall ;-)
<bluefoxicy> LaserJock:  I try to avoid rebooting
<LaserJock> haha
<bluefoxicy> LaserJock:  speaking of reinstall did I ever file a bug or spec out "Wipe everything on target / except /home during reboot"?
<bluefoxicy> since everyone absolutely refuses to isolate /home from /
<bluefoxicy> and some people have 350 gigabytes of /home
<LaserJock> seems like you did
<LaserJock> can't remember exactly though
<bluefoxicy> "oh just burn it to {CD,DVD}" I HAVE A HUNDRED GIGS.  TWENTY FIVE DVDS.  The stock answers I get are totally annoying.
<LaserJock> hmm, I just back it up since I want to wipe the drive anyway
<lifeless> this machine has been upgraded all the way from debian 3.0
<bluefoxicy> (by the way I filled up / on a system; it stops booting, rescue mode barely works, I had to use a livecd)
<bluefoxicy> I suppose it doesn't help that I have corrupt packages installed
<bluefoxicy> since it filled up WHILE upgrading to edgy
<bluefoxicy> /var/cache/apt/packages was HUGE
<LaserJock> lifeless: my installs usually last a couple months max
<fabbione> tfheen: i assigned bug #62485 to you because it's a BIOS/OBP bug that's triggered by edgy kernel and people must upgrade their OBP. It's worth a release note in that regard.
<Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  http://launchpad.net/bugs/62485
<LaserJock> too much testing to do
<lifeless> LaserJock: just means we're testing things
<bluefoxicy> IIRC the OSDL 1.2 docs for what an enterprise data center requires for package management include rollbacks (RPM has these, debs seem to be "uninstall and reinstall the old version if necessary") and some sort of efficient parallel install?
<bluefoxicy> I'm not sure on the parallel install
<bluefoxicy> but I still want to say
<lifeless> like, how many hours uptime before dapper shits itself again and hangs on resume from sleep ?
<bluefoxicy> download X packages, get started installing while the other packages are downloading, as you finish installing DELETE the downloaded packages
<bluefoxicy> minimal disk usage the whole way
<bluefoxicy> lifeless:  during the breezy development era, I was running breezy-dev
<bluefoxicy> I had started 20 days prior on Hoary
<LaserJock> bluefoxicy: I like keeping them around personally
<bluefoxicy> upgraded to breezy and tracked it every day
<bluefoxicy> gnome broke
<fabbione> bluefoxicy: that doesn't work if one of the X packages Depends on a new version of something you are downloading in parallel
<bluefoxicy> I moved to twm, installed icewm, moved to that
<fabbione> like a postinst script or something along that line
<bluefoxicy> on the 100th day, with a barely functional system, I claimed victory, updated, rebooted, and everything started working again
<bluefoxicy> (gnome had been refusing to work, a reboot fixed it, wtf this isn't windows)
* fabbione reboots in the new kernel
<fabbione> brb
<bluefoxicy> lifeless:  point is, if you have to measure dapper stable uptime before it hirakaris in HOURS, something's wrong
<bluefoxicy> this isn't Windows ME
<lifeless> bluefoxicy: its measurable in number of suspend-resumes rather than hours of runtime
<bluefoxicy> (other point, I'm insane, bored, and abuse my system regularly.  Also I'm playing through Zelda on my modded NES without a sword)
<bluefoxicy> um um um.  I'm out of stuff to talk about help.
<jdong_> now, time to replicate teardown and backport readahead-list to my dapper boxes....
<bluefoxicy> ok so the other day, somebody asked me how to license his software under LGPL.  He wanted to know if he had to register it somewhere or something
<jdong_> and then downgrade my primary laptop to dapper again :-/
<bluefoxicy> teardown and readahead-list?
<infinity> bluefoxicy: You know, when you run out of things to say, it's customary to stop speaking.
<bluefoxicy> they're not getting backported to dapper are they?
<jdong_> bluefoxicy: not in official backports, of course not
<jdong_> but it's handy for my laptop
<bluefoxicy> ah o.o
<jdong_> I've found that edgy's startup/shutdown times are so good I have no reason to use suspend/hibernate anymore
<LaserJock> infinity: heh
<jdong_> it takes around 15 seconds for my modified edgy to get to a login screen
<jdong_> and around the same amount of time to go down
<bluefoxicy> jdong_:  my laptop is being weird
<jdong_> if I can optimize my dapper to that point, then I win :)
<bluefoxicy> edgy is having a hard time booting except for on 2.6.17-9-386 (generic hangs)
<bluefoxicy> when it does boot, it goes from usplash to gdm in under 5 seconds
<bluefoxicy> I don't even see the progress bar start to fill up, it's just like "Loading--oshit nm I guess it's time to log in"
<jdong_> wow, you must have really nice hardware then
<bluefoxicy> it normally takes kind of long, I have an HP zv5405us laptop
<jdong_> the bulk of my 15 seconds is readahead, the rest is waiting for modprobe or switching resolution
<bluefoxicy> nothing spectacular
<bluefoxicy> it just goes
<jdong_> and I can't seem to optimize it much more than that :)
<jdong_> short of doing something silly, of course
<bluefoxicy> Maybe it's all the times I've hard-poweroff'd it, it may have gotten damaged.  Damage causes mutation, favorable mutations cause evolution.  My laptop is evolving?
<jdong_> lol
<bluefoxicy> jdong_:  I want to know if hotplug ever got fixed
<bluefoxicy> daveyj kind of slapped them, cups, X, etc etc etc around with a large trout.
<jdong_> what's wrong with hotplug now?
<bluefoxicy> um.  Doing about 5000 opens, most of them on the same files, on files about hardware that's not in the machine nor will ever be IIRC
<bluefoxicy> opening, reading, and closing the same XML files over and over and over again...
<lifeless> bluefoxicy: sounds like it has evolved
<jdong_> heh
<bluefoxicy> CUPS apparently loads every driver for every printer in existence
<bluefoxicy> as in it actually opens every file and reads them all
<bluefoxicy> and X likes to probe for hardware that "clearly doesn't exist" on ISA ports that "clearly aren't on the system" or something
<bluefoxicy> the devs were in the room when he was giving his presentation, it was lol
<bluefoxicy> why am i still talking
<lifeless> because
<bluefoxicy> is this like OCD or something
<tfheen> fabbione: sure.  Can you write me a blurb?
<jdong_> bluefoxicy: have you taken your medication today?
<fabbione> tfheen: sure... 
<tfheen> bluefoxicy: hotplug was removed from the archive ages ago.
<bluefoxicy> tfheen: ?  how in the...
<bluefoxicy> isn't that kind of required for a functional system?
<tfheen> bluefoxicy: no, it's not.
<bluefoxicy> I thought it governed firmware loading and automagical pmount of USB drives
* bluefoxicy -> mcdonalds
<tfheen> udev for the former, gnome-volume-manager for the latter.
<tfheen> but this is offtopic here.
<bluefoxicy> I know; even when I'm actually contributing something useful I'm offtopic
<jdong_> something useful being additional scrollback for devs to read through?
<jdong_> :)
<fabbione> tfheen: added to the bug.. you might want to check for itaglish/english.. but otherwise that's what i think we should slam there
<tfheen> fabbione: ok, thanks.
<tfheen> sfllaw: around?
<tfheen> mgalvin: hi, does the docteam have any particular place they want release notes in?
<mgalvin> tfheen: hey, not that I know of ATM, i haven't really been active for a little while, it may be best to ask in -doc, someone may know
<tfheen> mgalvin: 'k, thanks.
<mgalvin> np
<tfheen> Burgundavia: yo, do you know the answer to ^^ ?
<bluefoxicy> ugh I'm still banned from #-offtopic
<Burgundavia> tfheen: the release docs are being done on the wiki, but I am currently travelling and thus have not been able to complete them
<Burgundavia> tfheen: if they are done, they can be moved to teh ubuntu website
<Burgundavia> tfheen: somebody else started https://wiki.ubuntu.com/EdgyEft/Beta
<tfheen> Burgundavia: release docs != release notes.  Release notes are typically "this bit is broken", "to work around this issue, upgrade $foo", etc.
<tfheen> Burgundavia: also, whom should I talk to given that you're travelling?
<Burgundavia> tfheen: for the notes, we have been letting the devel team deal with it. I believe the dapper ones were kept on the wiki, but mdz is the better person to ask
<Burgundavia> as for the docs, I have asked but nobody has taken it up
<tfheen> ok..
<mdz> generally they go in the wiki, with contributions from the development team, the doc team and random folk from Canonical and elsewhere
<tfheen> mdz: /Beta/ReleaseNotes would work as an URL, or do we have a scheme already?
<mdz> tfheen: the existing scheme is AdjectiveReleaseNotes
<tfheen> ok
<mdz> tfheen: the current set of ubuntu/kubuntu/edubuntu alternate/desktop should all have the ubiquity update which was the outstanding bit
<tfheen> mdz: should have as in "have already" or "needs rebuild"?
<mdz> tfheen: as in, I triggered them at a time when they ought to have the right bits, but I haven't verified it
<tfheen> ok, thanks.
<tfheen> I'll poke it.  I'm a tad slow today due to headache and such, but I'll cope.
<infinity> Except all the amd64 livefs builds failed.
* infinity looks.
<infinity> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
<infinity> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
<infinity> dpkg: error processing cupsys-driver-gutenprint (--configure):
<infinity>  subprocess post-installation script returned error exit status 1
<infinity> tfheen: Can you reproduce that on a local amd64 box?
<infinity> tfheen: All the amd64 livefs builds failed with that.
<tfheen> infinity: I'll poke it
* infinity wishes his amd64 box hadn't walked off with its primary user.
<infinity> I need to buy a new one.
<tfheen> deboostrap takes a tad of time here
<infinity> Yeah, that's why I always keep clean chroots on my laptop.
<tfheen> you're clearly cleverer than I.
<pitti> Good morning
<pygi> morning pitti 
<Hobbsee> hey pitti 
<sivang> morning
<pygi> hey ho sivang :)
<sivang> yo pygi 
<dholbach> good morning - HAPPY HUG DAY!
<Burgundavia> morning sivang, dholbach
<dholbach> hi Burgundavia
<mvo> infinity: can you please give-back synaptic?
<sivang> hi Burgundavia , dholbach , mvo , pitti 
<sivang> I'm getting Ign on all the translated package info when apt-get update'ing, known or recently dropped ?
<pitti> hi sivang 
<mvo> sivang: maybe your language is not translated yet :)
<sivang> mvo: Ign http://archive.ubuntu.com edgy/main Translation-en_GB <== using en_GB ;-)
<tfheen> mvo: given back
<mvo> tfheen: thanks!
<fabbione> hey sharms 
<fabbione> feh
<fabbione> hey shawarma 
<shawarma> fabbione: Hi, there.
<shawarma> fabbione: Is the wife going to let you go to UDS this time?
<fabbione> shawarma: yeah.. she will try to let me go
<pitti> mvo: can g-a-i or synaptic display a list of all installed packages which are unsupported?
<mvo> pitti: synaptic can, the easiest way is to click on "status", "Installed" and then sort by the Status column of the tree (the little "S")
<mvo> eh
<mvo> pitti: make that the second column
<mvo> the one with the ubuntu logo
<shawarma> fabbione: Coolness. I'm hoping to go this time as well, although it's a quite a bit more expensive trip.
<fabbione> shawarma: yeah i know
<slytherin> Can anyone please tell me how can I apply for a mailing list for a l10n team?
<carlos> slytherin: try mailing to mailman-owner@lists.ubuntu.com
<carlos> LaserJock: ping
<LaserJock> carlos: yeah?
<carlos> LaserJock: hi, I saw the upload of .pot files for Ubuntu documentation
<carlos> LaserJock: but I need to know whether I should just approve the .pot files or if you need any adjustment on what we have already imported since Dapper
<carlos> (template renames/splits/removals)
<LaserJock> ah yes
<carlos> so we don't create new unneeded templates 
<LaserJock> how can I find out what you have now?
<carlos> LaserJock: this is what we have right now:
<carlos> https://launchpad.net/distros/ubuntu/edgy/+source/xubuntu-docs/+translations
<carlos> https://launchpad.net/distros/ubuntu/edgy/+source/ubuntu-docs/+translations
<carlos> https://launchpad.net/distros/ubuntu/edgy/+source/kubuntu-docs/+translations
<carlos> https://launchpad.net/distros/ubuntu/edgy/+source/edubuntu-docs/+translations
<carlos> it comes from Dapper
<LaserJock> k
<carlos> and I think mdke told me that we would need to remove/rename some of them
<mdz> tfheen: any luck with the livefs bulid failures?
<carlos> slytherin: sorry, I gave you the wrong address, send an email with your request to mailman@lists.ubuntu.com
<slytherin> carlos: Is it automated response kind of thing? Or the replies are sent by any person?
<carlos> slytherin: by our admins
<slytherin> carlos: Ok. Thanks.
<carlos> not sure if they have it redirected to a ticket system
<carlos> but anyway, they should answer you
<tfheen> mdz: no, my test failed with a different error, but I suspect that was because I forgot to mount /proc
<mdz> tfheen: it seems likely to be a broken pipe issue
<mdz>         close GENPPD or die "can't close cups-genppd pipe: $!";
<mdz> GENPPD is the read end of a pipe
<mdz> that script hasn't changed in ages of course, and there's no reason it should fail consistently on amd64
<mdz> infinity: only adm64 failed, but all derivatives?
<mdz> tfheen: meanwhile, please get folks started on testing the architectures which are up to date.  sfllaw,
<tfheen> mdz: willdo
<mdz> tfheen: when he wakes, should have testing facilities ready to go
<mdz> in montreal
<tfheen> goodie
<tfheen> mdz: did you build DVD images too?
<mdz> tfheen: no, I didn't
<tfheen> I'll do that, then
<mdz> I didn't build xubuntu either
<mdz> or server
<tfheen> ok, doing those too, then
<mdz> I built alternate and desktop for ubuntu, kubuntu, edubuntu
<Hobbsee> hey sabdfl 
* realist wonders what sabdfl actually stands for
<LaserJock> heh
<LaserJock> self-appointed benevolent dictator for life
<LaserJock> perhaps the spelling is right
<`anthony> self-appointed or south african?
<Hobbsee> self appointed
<realist> Speaking of which, I'm going to Cape Town in Janurary, can't wait!
* Riddell rsyncs
<ogra> was the cupsys breakage fixed ? i see no upload on -changes 
<ogra> pitti, tkamppeter ^^^ ?
<pitti> ogra: cupsys breakage?
<pitti> ogra: I only fixed the dapper update breakage recently
<ogra> pitti, the postinst error we discussed yesterday
<ogra> it breaks the installer
<pitti> ogra: I don't remember a discussion about cupsys postinst 
<ogra> meh
<pitti> well, I do remember a gutenprint discussion vaguely
<ogra> we discussed it for 30 min or so
<ogra> right
<tfheen> pitti: take a look at http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/20060927/livecd-20060927-amd64.out
<ogra> cupsys-driver-gimpprint tris to gnerate ppds
<ogra> *tries
<ogra> and fails
<tfheen> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
<tfheen> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
<tfheen> dpkg: error processing cupsys-driver-gutenprint (--configure): subprocess post-installation script returned error exit status 1
<tfheen> is the error
<ogra> tfheen, yes, that one
<ogra> thanks :)
<pitti> tkamppeter: hm, what was the result of that discussion?
<mvo> Kamion: could you please approve my dist-upgrader upload?
<ogra> pitti, iirc he said we could make it a no-op i the case there are no queues set up (i.e. in a fresh install)
<mdz> mvo: what's in it?
<mdz> (we are in beta freeze)
<mvo> mdz: the dist-upgrader tarball that revert the "Breaks" changes (ie it does not download any backports). it also has a special case handling for the packages with the Breaks field (just ensuring that if they were installed, they will be kept installed)
<mdz> mvo: I just finished building CDs :-/
<mvo> mdz: *argh* :( sorry
<mdz> mvo: we hadn't talked about the latter part
<mvo> mdz: about the special case for the packages that used to use Breaks? I though we did
<mdz> mvo: surely there wouldn't be any packages with Breaks, since we didn't use it in dapper
<ogra> mdz, pkgsel fails anyway unless the cupsys-driver-gutenprint postinst is fixed
<mdz> mvo: oh, the packages that once used breaks, but no longer do
<mvo> mdz: yes. 
<mdz> ogra: not everywhere
<mdz> apparently the livefs build succeeded except on amd64
<ogra> well, alternate (thus edubuntu) fails completely
<Riddell> mdz: could you give back koffice on ppc
<mdz> mvo: please mail me a diff
<tfheen> ogra: for i386 and ppc too?
<mdz> Riddell: done
<ogra> tfheen, pkgsel exits  ... i didnt test ppc yet, but i assume its the same there
<ogra> (which leaves you with an unconfigured grub)
<Bazzi> hi :)
<Bazzi> doko_: ping
<mvo> mdz: send
<ogra> tfheen, mdz, http://people.ubuntu.com/~ogra/cupsys-driver-gutenprint.postinst vs http://people.ubuntu.com/~ogra/cupsys-driver-gutenprint.postinst.quickfix ... would that be ok with you ?
<tfheen> ogra: diff, please?
<mdz> ogra: I don't see the difference
<ogra> (i just added two || true to make it fail less evil)
<tfheen> root@vawad:/# /usr/sbin/cups-genppdconfig.5.0 -u
<tfheen> cups-genppd: Unable to create file "/usr/share/ppd/gutenprint/5.0/en/stp-bjc-30.5.0.ppd.gz" - No such file or directory.
<mdz> ogra: the script is bailing out; it's not at all clear that it has finished doing its work
<tfheen> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
<Kamion> mdz: a dist-upgrader update won't require livefs rebuilds, at least, and those are the slow bits
<ogra> mdz, it cant finish ... it needs a set up printer queue to finish at all according to tkamppeter 
<mdz> ogra: that seems unlikely
<ogra> thats what he said yesterday
<mdz> otherwise it would have failed on upgrade for every user without a printer queue set up
<tfheen> mkdir /usr/share/ppd/gutenprint/5.0/en/ fixes it for me.
<tfheen> can somebody verify that?
<ogra> tfheen, even in a norwegian locale ? 
<tfheen> ogra: in a clean chroot without any locale params set.
<ogra> ah, k
<ogra> seems it only generates them in /en here as well
<fabbione> tfheen: sparc-server CD has kernel module mistmatch...
<fabbione> tfheen: did somebody updated the seeds?
<tfheen> fabbione: gnr.
<fabbione> (for -10- that's it)
<tfheen> fabbione: I don't touch your seeds.
<mdz> mvo: this diff is 22k
<fabbione> tfheen: server is in the normal seed.. i don't touch them either
<mvo> mdz: a lot of it is mo-file change (because the translations were rebuild and the update to the demotions.cfg file). the actual source changes are much much smaller
<fabbione> tfheen: probably Kamion did always fix them in background because i never had to put my hands there
<tfheen> fabbione: if you could just Get It Fixed, I'd appreciate.  I'm trying to fix the gutenprint b0rkage.
<ogra> tfheen, hmm, the /usr/sbin/cups-genppdconfig.5.0 seems to create it at the very top ...
<ogra> hah, no its doesnt :)
<ogra> it needs to be called with -d -u
<ogra> tfheen, could you try that in your chroot ?
<Kamion> I didn't fix them last night ...
<Kamion> let me check
<Kamion> if they aren't done, I'll do them and respin
<mdz> mvo: I can't possibly look at this and say that it's correct
<tfheen> ogra: it won't help.  It doesn't create the subdirs.
<mdz> mvo: which is the level of certainty that we need to have the day before a major release
<fabbione> Kamion: thanks, i would love if you could that
<Kamion> yep, nobody fixed the seeds
<tfheen> Kamion: thanks.
<ogra> ah, crap ...
<Kamion> won't take long to sort out
<fabbione> Kamion: thanks dude
<tfheen> I wonder why the cupsys problem doesn't bit us on i386 though
<ogra> it does here
<ogra> i cant install amd64 or i386 alternate
<mdz> mvo: and there are changes in here not even described in the changelog
<Riddell> Kamion: looks like a couple of errors creating the alternate ppc kubuntu cds, "cat: /srv/cdimage.no-name-yet.com/debian-cd/data/edgy/yaboot/yaboot.conf.server: No such file or directory" and "cp: cannot create directory `powerpc/cdrom': Permission denied"
<Kamion> ok, thanks, I'll check that out
<Kamion> first is definitely my fault
<tfheen> the latter is probably that ppc gets unhappy when you run it as your own user.  The group for the kernels and such is then wrong and the cron scripts become unhappy
<mvo> mdz: let me create a new diff that removes the special handling of the breaks, translations and the fixes in aptsources.py. those are not critical. 
<tfheen> s/ppc/ppc build/
<Kamion> yeah, let me do the alternate builds and I'll clean them up
<mdz> mvo: why is the demoted.cfg update so large?
<Kamion> I must fix that group bug at some point
<mdz> mvo: had it not been updated since dapper?
<Kamion> isn't the Breaks handling the critical bit? or did I misread?
<mvo> mdz: effectively yes, my bad
<mdz> Kamion: the breaks issue is multifaceted
<mvo> Kamion: I did add some code to special case the packages that used to use breaks but now use conflicts. that one can be taken out and we just hope that apt gets it right
<mdz> Kamion: in the last update a bunch of new code was added to use backported packages to handle the breaks
<mdz> Kamion: that's being reverted, which is the important bit
<Kamion> right
<ogra> grmbl ... tfheen it sets the default language several times in /usr/sbin/cups-genppdconfig.5.0, so i wonder why it doesnt work :/
<tkamppeter> ogra, I did not say that the script needs a print queue to work, I said that the script updates existing print queues. So it is only needed to be run when print queues can be there. In situations which can never have print queues, like install on virgin partition, one coukld simply omit running it.
<ogra> tkamppeter, so a check if the directory exists in the packages postinst would suffice ? 
<tfheen> tkamppeter: is there a reason why /usr/share/ppd/gutenprint/5.0/en/ isn't shipped in the .deb?
<ogra> its created dynamically ... you can specify different language dirs ...
<ogra> /usr/sbin/cups-genppd.5.0 does that it seems
<mvo> mdz: does this http://people.ubuntu.com/~mvo/tmp/20060927.1137.diff look more appropriate?
<ogra> (or doesnt in our case, wich i would see as the real bug here)
<tkamppeter> tfheen: This is strange, as the PPDs shipping with gutenprint are exactly in this directory.
<tfheen> tkamppeter: which package?
<ogra> the perl script (cups-genppdconfig.5.0) does everything right and sets the defaults, but cups-genppd.5.0 seems not to pick up these settings 
<mdz> mvo: perfect
<tfheen> tkamppeter: it seems to me there are no included ppds from the build of the gutenprint package
<tkamppeter> tfhenn: cupsys-driver-gutenprint
<ogra> tkamppeter, if i add a test for that dir to avoid running cups-genppdconfig.5.0, would the ppds ever be created after install ? 
<ogra> (is it run if i add a printer or something like that ?)
<tkamppeter> tfhenn: Perhaps they are generated by the postinst script (and this must be done also when there is no print queue)
<tkamppeter> In Mandriva I get the PPDs when the package is built (by make), but in Ubuntu it seems that the PPD building by 'make' is suppressed and postponed to the postinst script.
<tkamppeter> So Mandriva's postinst script only updates queues.
<ogra> hmm, what is gutenprint-locales ??
<tfheen> tkamppeter: (you're consistently spelling my nick incorrectly, so I don't get any highlights.)  Would there be any downside to just shipping /usr/share/ppd/gutenprint/5.0/en/ in the package?  If not, I'll just add that.
<tkamppeter> This means that in Ubuntu we must assure that the postinst script is always executed correctly.
<Kamion> that's true anyway :)
<Kamion> postinst script failures always cause the package to fail to install
<Kamion> rebuilding alternate CDs now, with the right kernel this time
<Fade> has anybody else here noticed serious breakage in xemacs and gnuemacs?
<Fade> I'm on a powerpc box, but it seems like it's probably sort of endemic.
<tkamppeter> tfheen, go ahead and add it (or mkdir ... in the postinst script), there is no problem caused by having that dir.
<Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/58856
<Ubugtu> Malone bug 58856 in xemacs21 "xemacs segfaults on edgy powerpc system" [Undecided,Unconfirmed]  
<fabbione> Kamion: mind to let me know when server CD's will be ready?
<tfheen> Kamion: supposedly, we need new alternate CDs too for the gutenprint thing.
<tfheen> Kamion: can you stop the publisher, please?
<tfheen> I want to test build this before uploading
* infinity stops the publisher.
<mdz> Ubugtu: bug 62590 please
<Ubugtu> Malone bug 62590 in Ubuntu "openoffice.org FTBFS, when built on edgy's kernel" [High,Confirmed]  http://launchpad.net/bugs/62590
<tfheen> tkamppeter: we seem to build all the PPDs in the package build too, but they're never shipped.  Anyway, we can revisit that after beta.
<Fade> I can't believe I'm the only one who values xemacs. lol
<mvo> mdz: dist-upgrader 20060927.1137 is uploaded and wating for approval.
<Kamion> fabbione: maybe about an hour?
<doko_> Bazzi: pong
<fabbione> Kamion: sure that's fine
<Kamion> fabbione: actually I can do them earlier, due to the gutenprint thing
<Kamion> so within the hour
<fabbione> Kamion: that's fine. i just need to know when they are done. doesn't matter when
<fabbione> Kamion: i am testing netinstalls in the meantime
<mdz> mvo: accepted, thanks
<Kamion> oh I see, your grammar confused me then
<Kamion> "when server CDs are ready"
<Bazzi> doko_: I talked with dholbach a bit on Java things in ubuntu. you are the responsible person for java?
<Kamion> quirk of English tenses
<doko_> Bazzi: as long as it's in main, maybe yes
<Bazzi> doko_: I particularly have two interests, (1) fixing eclipse so that it works flawlessly, (2) giving ubuntu some more free java love ;-)
<Bazzi> hm, those things are mostly in universe, though
<tkamppeter> tfheen: Lets leave it this way, it consumes less CD space for the package. Only fix the directory creation in the postinst script and the package is perfect.
<tfheen> Kamion,infinity: please let gutenprint in once you see it.
<doko_> Bazzi: you're welcome. (2) is not a problem, just start. what problems do you have with eclipse?
<tfheen> with that, I'm off for a little bit of rest to avoid my head falling off.
<dholbach> doko_: I said to Bazzi that a java maintenance team might be a good idea - so more than one can chip in fixes for java packages :)
<Bazzi> doko_: it doesn't work for me at all, I get wrong/missing build-deps (I'm all new to hacking packages so I don't know where to fix them) and they're quite complex
<ogra> tfheen, thanks a lot :)
<Kamion> tfheen: done
<Kamion> infinity: want to drive the publisher? or you could just turn the cron jobs back on ...
<Kamion> we're just about in time
<Kamion> actually, maybe not, I think cron needs the jobs to be in place one minute before they run
<Kamion> or at least vixie cron used to be that way
<fabbione> oh grat
<fabbione> i found a glibc6 regression
<doko_> Bazzi: so you did use an upstream version, or the packaged one?
<infinity> Kamion: I'll just drive by hand.
<Bazzi> doko_: since the packaged one didn't work I thought it might be useful to recompile it myself against the current gcj version. but apt-get build-dep eclipse failed
<TheMuso> c
<doko_> Bazzi: just download, start the build with debian/rules build and try to figure out, what goes wrong. it works for me.
<Bazzi> you mean starting or compiling works?
<Riddell> new kubuntu-meta upload if someone could let it through
<infinity> Kamion: Any particular reason why ubuntu-minimal isn't a task?
<doko_> Bazzi: compiling
<infinity> Kamion: See bug #61684 ... This can be fixed for -standard or -desktop by installing tasks instead of metapackages, but not for -minimal
<Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  http://launchpad.net/bugs/61684
<Kamion> infinity: historically, because we didn't have aptitude at the point when we were installing -minimal
<Kamion> and also because debootstrap installs -minimal
<infinity> Oh, debootstrap installs it.  Right.
<Kamion> I think we lose here, TBH. We can cope with occasionally having to fix up stuff in minimal, right?
<infinity> Then it won't matter anyway, cause it won't end up in apt's autoremove DB.
<Bazzi> doko_: that's btw the error I get when trying to start it: http://phpfi.com/157675
<infinity> So, we win.
<Kamion> we should probably mark ubuntu-minimal as manually installed?
<infinity> (In this case)
<Kamion> oh, no, that's the default
<infinity> Yeah, no need to mark it at all.
<Kamion> mark everything else at the end of the debootstrap run as automatically installed?
<infinity> Since it's done by dpkg and black magic, not apt.
<doko_> Bazzi: so that for running eclipse, not building it ...
<infinity> Marked as auto-installed would give us the above bug, which I was trying to avoid. :)
<Kamion> oh, right
<Kamion> ok
<infinity> In other words, the bug isn't there for -minimal, I just didn't think it through.
<mvo> Kamion: if it is not installed by apt, then its all good :)
<Kamion> righto
<Bazzi> doko_: yep that error is for running it
<Kamion> fabbione: server CDs should be up now
* mvo hugs infinity Kamion
<fabbione> Kamion: it appears that finish-install fix for ttySX didn't kick.. just tested on a netinstall
<Kamion> what version of finish-install was on your image?
<Kamion> oh, netinstall
<Kamion> hmm
<fabbione> syslog:Sep 27 10:03:04 finish-install: Configuring /etc/inittab for serial console
<fabbione> hmm
<fabbione> i have 2.3ubuntu1 in my local mirror
<Kamion> yeah, I didn't update the message, that doesn't matter
<fabbione> rsynced no more than one hours ago
<Kamion> oh, I suck
<Kamion>         if [ -f /target/etc/inittab ] ; then
<Kamion>         if [ -f /etc/event.d/tty1 ] ; then
<Kamion> spot the bug
<Bazzi> doko_: do I need anything special to du a debian/rules build? it complains about lack of /usr/share/dpatch/dpatch.make
<pitti> missing /target?
<fabbione> Kamion: yeah.. if we have inittab..
<Kamion> pitti: bingo
<fabbione> ah no
<fabbione>  /target
<fabbione> yeah
<fabbione> ok i guess beta for sparc is going to be doomed.. slightly :)
<doko_> Bazzi: sudo apt-get build-dep eclipse
<Kamion> I can fix this, it's a one-liner
* fabbione hugs a coffee cup and that bag of white pouder...
<Kamion> ... sugar?
<ogra> haha
<Bazzi> doko_: that fails. libjsch-java is in wrong version
<fabbione> Kamion: ahah
<Kamion> I have no kettle at my workplace right now :(
<fabbione> Kamion: btw.. bug #62596
<Ubugtu> Malone bug 62596 in glibc "ld.so.conf disappeared?" [High,Confirmed]  http://launchpad.net/bugs/62596
<fabbione> that will stop some interesting thing to work
<Kamion> score
<Kamion> I guess that's due to /usr/X11R6/lib going away
<fabbione> i dunno..
<fabbione> i still need to dig into it
<ogra> i still have it in my i386 install from yesterday
<fabbione> ogra: it's not on my i386 server installed 20 minutes ago
<ogra> (but indeed that has /usr/X11R6/lib)
<Kamion> fabbione: weird, the code looks correct
<Kamion> in libc6.postinst
<fabbione>     if dpkg --compare-versions $preversion lt 2.3.999.2-4; then
<fabbione>         if [ -e /etc/ld.so.conf ] ; then
<fabbione>             [ -z "$(tail -n 1 /etc/ld.so.conf)" ]  || echo >> /etc/ld.so.conf
<fabbione>         else
<fabbione>             touch /etc/ld.so.conf
<fabbione>         fi
<fabbione>         if ! grep -q '^include /etc/ld.so.conf.d/.*\.conf$' /etc/ld.so.conf ; then
<fabbione>             echo 'include /etc/ld.so.conf.d/*.conf' >> /etc/ld.so.conf
<fabbione>         fi
<fabbione>     fi
<fabbione> no it's not
<fabbione> $preversion doesn't exist on install?
<infinity> preversoin needs ot be quoted.
<Kamion> ah yes, I just came to the same conclusion as infinity
<infinity> Then --compare-versions will be happy.
<fabbione> feh
<infinity> Do I want to upload for that, or not?
<Kamion> finish-install fix is in accepted
<Kamion> how long does glibc take to build everywhere?
<infinity> Too long.
<Kamion> jbailey said the other day that he was concerned about uploading glibc at the moment in case compiler updates broke it
* infinity looks for sometihng more conrete.
<infinity> 6 hours on sparc.
<infinity> That's a no-go.
<Kamion> we could simply bump that version check later, and fix it post-beta
<fabbione> no no
<fabbione> no glibc uploads
<fabbione> Jeff has other fixes pending
<infinity> Yeah, bumping the version check sounds alright to me.
<fabbione> it's not catastrophic
<doko_> Bazzi: right, that was in preparation for eclipse-3.2. if you want to rebuild the current eclipse, please install the libjsch-java from dapper
<Bazzi> doko_: will eclipse-3.2 still come for edgy?
<doko_> Bazzi: probably yes, probably no
<Bazzi> mmmh :( hopefully yes
<Bazzi> doko_: I'll use upstream for now, then and hope eclipse 3.2 slips into edgy in time
<thom> sabdfl: http://www.flickr.com/photos/x180/253623622/in/set-72157594289138343/ <-- practising the ballroom dancing again?
<pygi> sivang: poke? :)
<sivang> pygi: hi
<pygi> sivang: you have time or are you busy once again? :)
<sivang> pygi: doing something but can talk and multitask :-)
<pygi> sivang: ah, won't bug you then, just ping me if you're done in next 10 years :)
<sivang> pygi: heh
<sivang> pygi: no, please, go ahead
* pitti waves to lloydinho 
<lloydinho> hi pitti. I have problems with query stuff.
<pitti> lloydinho: oh, not registered?
<lloydinho> I'll just try and get it working, just a moment'
<pitti> lloydinho: how are your travels and interviews coming along?
<lloydinho> (I'm using KDE...)
<lloydinho> weird business.
<lloydinho> I'm at the aKademy.
<lloydinho> in Dublin.
<lloydinho> So things are going quite well.
* mvo lloydinho
* mvo waves to lloydinho
<lloydinho> hey mvo!
<lloydinho> mvo: busy with the beta release?
<tfheen> infinity: you're running the publisher back-to-back?  Is it done yet?
<mvo> lloydinho: yeah :( otherwise I would have answered your last mail already :)
<lloydinho> mvo: No worries, I've been too busy with the fieldwork stuff anyway. :-)
<infinity> tfheen: No, it's still going (second run)
<sivang> tfheen: you've asked that exact same question some point in time during this release cycle right? 
* sivang has  a De Ja Voo
<Fujitsu> My wireshark builds failed with `Chroot problem' 4 days ago, they haven't been rebuilt yet...
<Fujitsu> Do I have to do something special?
<tfheen> sivang: as in "sometime during edgy", yes, as in "sometime during beta preparations", no.
<tfheen> infinity: ok, please tell me when it's done.
<infinity> tfheen: Hah, it just finished.
<sivang> tfheen: right, the former. good I'm sane still.
<tfheen> infinity: thanks, I'll build amd64 livefs-es now to test.
<infinity> tfheen: Kay, cool.  You'll be testing a quick livefs.sh tweak at the same time, so I'll be watching.
<tfheen> infinity: ok.
<infinity> tfheen: The sooner, the better, mind you. :)
* tfheen also goes to make alternate install CDs.
<ogra> id gutenprint already done ? 
<ogra> *is
<infinity> Yes.
<ogra> wow, that was fast
<infinity> You must have fallen asleep, it wasn't that fast. :)
<ogra> i sat here twiddling thumbs :)
<fabbione> ogra: slaker!
<ogra> heh
<bddebian> Howdy folks
<Kamion> lp_archive@drescher:~$ change-override.py -c universe -S tcsh
<Kamion> woo
<infinity> !
* fabbione grins
<infinity> I thought tcsh was a build-dep of large chunks of weird crap (and OOo)?
<Fujitsu> infinity, doesn't OOo come under weird crap anyway?
<infinity> Well, yes.
<infinity> Would appear that it's not a build-dep, though.  Maybe I'm on crack, or maybe it bootstraps its own csh to use in the build process.
* infinity shrugs.
<infinity> The latter wouldn't surprise me.
<infinity> I suspect they'll ship the GCC source bundled with OOo eventually.
<fabbione> sooner or later they will have obiquity as b-d
<fabbione> ubiquity even
<mantiena-baltix> Hi all
<mantiena-baltix> Kamion, Hi, could you give me some time ? I wanna work on ubiquity bugs (I noticed lots of bugs in dapper's ubiquity), so, maybe it would be better to use ubiquity from edgy on our distro (Baltix, based on Dapper) ?
<Riddell> Kamion: could you let kubuntu-meta 1.14 into the archive?
<infinity> mantiena-baltix: You might want to try bugging him after we've released the Edgy Beta (in the next 24-48 hours)
<infinity> Riddell: Will this require livefs rebuilds for kubuntu?
<Riddell> infinity: yes
<fabbione> Riddell: that's not the right answer
<fabbione> ;)
<infinity> Riddell: Unavoidable? :)
<Riddell> well amd64 live CD is oversized so seems unavoidable to me
<mantiena-baltix> infinity, I just wanna ask if ubiquity from edgy is stable enough and if there are any important reasons do not use ubiquity from Edgy on Dapper-based system
<slomo_> infinity: ping? did you already do something about apache1/2 at the same time? :)
<infinity> Fair enough.
<infinity> slomo_: Not for beta, no.
<infinity> Riddell: Accepting.
<Riddell> thanks infinity 
<doko_> infinity: OOo dropped tcsh in edgy
<infinity> doko_: Nice.
<ogra> to switch to zsh ? 
<ogra> or csh ?
<doko_> infinity, Fujitsu: OOo isn't as evil as Keybuk says ...
<infinity> Switching from tcsh to zsh would be a neat trick...
<Fujitsu> doko_, sure...
<ogra> :)
<ogra> ARGH 
<ogra> what did you do to my isos ?
<ogra> where do these 7M come from ?
<pitti> ogra: straight from hell
<ogra> seems like :((
<ogra> sh*t 
<ogra> how could our kernel and modules grow by 7M ?
<ogra> its the only differenc i see apart from gutenprint and synaptic
<infinity> They don't seem to have grown at all here, from -9 to -10
<ogra> i have no clue where to take that space from ... damn, the iso was perfect 
<ogra> well, i dont think synaptic grew by 7M
<mvo> ogra: I hope not :P
<ogra> and the gutenprint fix was a one liner
<ogra> infinity, l-r-m probably ?
<infinity> Nope.
<infinity> No change there.
<ogra> hmm
<Lathiat> some missing debug stripping or something?
<ogra> ubuntu has the same issue it seems
<sabdfl> thom: it's just a jump to the left...
<ogra> heh
<sivang> hehe
<thom> sabdfl: *g*
<infinity> ogra: Indeed, though only on i386.. The others didn't grow.
<ogra> yep
<ogra> thats why i suspect some part of the linux package ...
<ogra> oh
<ogra> heh
<infinity> Found it?
<ogra> where is the difference between -generic and -i386 ?
<ogra> i have all d-i modules twice in the .list file 
<infinity> Ahh, that wouldbe it.
<ogra> one -generic and one -i386
<ogra> d-i rebuild ? 
<ogra> or onyl a metapackage glitch ?
<infinity> germinate bug, I'd guess.
<infinity> -generic is listed for amd64, and I think it's pulling it in for i386 too.
<ogra> ah
* infinity tests this theory.
<Kamion> mantiena-baltix: use the dapper-updates version of ubiquity; I don't support edgy's ubiquity on a dapper-based distribution
<Kamion> mantiena-baltix: for one thing, edgy's ubiquity uses console-setup, which isn't in dapper; and it needs other bits of infrastructure you don't have
<Kamion> tfheen: just heard about an oem-config bug
<Kamion> +  * Add /usr/lib/oem-config to sys.path in oem-config-dm so that it can
<Kamion> +    import frontend modules.
<Kamion> +sys.path.insert(0, '/usr/lib/oem-config')
<mantiena-baltix> Kamion, I understand, that you don't support edgy's ubiquity on dapper, but if edgy's ubiquity just need some packages to be backported then it
<mantiena-baltix> it's not a problem for me, I can do this ;)
<Kamion> mantiena-baltix: then on your head be it; I don't want to be asked about it
<Kamion> honestly, it's too much work for me to attempt to help
<tfheen> Kamion: without it, it doesn't work, or?
<Kamion> tfheen: I've uploaded the fixed oem-config; if you want to get somebody to push it through, please do
<Kamion> tfheen: yeah, it'll raise an AttributeError on oem-config-dm startup unfortunately
<Kamion> which is kind of fatal
<tfheen> Kamion: ok, thanks
<Kamion> abattoir's tested the fix and it works
<tfheen> infinity: if you'd be so kind as to approve that. ^^ 
<mantiena-baltix> Kamion, thank you very much, you told me exactly what I need - ubiquity from edgy will not work on default dapper system :)
<infinity> tfheen: Will do.
<zul> heylo
<ogra> infinity, any results in proving that theory ? 
<Kamion> mantiena-baltix: I'm willing to backport more individual fixes to dapper-updates if you want to identify them, although I can't fix everything that way
<Kamion> anyway, I really have to run, I need to be five minutes' drive away two minutes ago
<infinity> ogra: Looks like we're committing a hackish fix right now.
<ogra> ok
<mantiena-baltix> Kamion, good luck, I try to help you with version from dapper-updates at first
<infinity> Kamion: germinate tests look good, committing.
<tfheen> Riddell: that seed adjustment you did -- does it affect live cds?
<tfheen> ogra: you probably want new livefs-es too?
<tfheen> ogra: or are those you have too big already?
<ogra> nope, they are fine ... 
<ogra> my liveCD is usually a bit smaller anyway
<ogra> as soon as the germinate fix is in i need new i386 builds though
<tfheen> ogra: you want new livefs-es for  https://launchpad.net/distros/ubuntu/+bug/61684 don't you?
<Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  
<ogra> if thats fixed then yes
<Riddell> tfheen: yes
<Riddell> tfheen: so wait for kubuntu-meta 1.14 is in the archive before rebuilding
<tfheen> Riddell: will do
<seb128> bah, edgy on amd64 is no fun
<Treenaks> seb128: it's fun here!
<seb128> depending of the fun then ;)
<seb128> valgrind is not working
<ogra> seb128, wahts not funny about it ? 
<ogra> ah
<seb128> lot of "DWARF2 CFI reader: unhandled CFI instruction 0:24" to start
<Treenaks> what's a DWARF2 CFI reader?
<seb128> no idea
<seb128> and it exits on "valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed."
<ogra> a little person with glasses and a book ?
<tfheen> dwarf2 is a debugging format.
<tfheen> or debugging symbol format or whatever
<ogra> how boring ... i lkie my idea better :)
<ogra> *like
* seb128 will reinstall an i386 distro when beta CD is ready to test
<ogra> if you use a DVD the current isos should work ...
<ogra> they are just to big for 700MB 
<Kamion> infinity: thanks for testing that
<tfheen> Kamion: new alternate builds running now.  I forgot and ended up doing full builds rather than i386 only.
<Kamion> we'd need everything for oem-config anyway
<mvo> will we see another -live build as well?
<ogra> yep
* pitti grumbles at the 5 kbyte/s bandwith archive.u.c serves him
<pitti> bandwidth even
<ogra> heh, i get 36k (on a 2M line)
<sivang> lines dropping again?
<pitti> ogra: that's not the point, de.archive.u.c. serves me 150 kb
<sivang> pitti: .de never seem to be servig less 
<pitti> but it's always a day out of date
<sivang> it's quite good
<mvo> archive.u.c is pretty slow these days :/
<ogra> yep
<elmo> I can get 8Mbit from the office
<elmo> the machines are fine - if  it's slow for you a) let us know (esp. where you're coming from IP wise),and b) use a mirror - that's why they exist :-P
<Znarl> pitti : What's your IP address?
<sivang> hmm, seems fine. I am now dist-upgrading in 194Kb/s
* pitti is behind a NAT, give me a second to figure out the first public one
<sivang> from a.u.c
<pitti> Znarl: 195.227.105.180 is my ISP's public address
<Znarl> pitti : Ta.
* pygi was upgrading at 105Kb/s
<tfheen> mvo: live iso, not live fs, no
<pitti> sometimes, when I ^C apt-get and start again, I get a better one, though; seems to be pure luck
<mvo> tfheen: no new livefs? oh well, so no fix for #61684 :/
<tfheen> mvo: yes, that's what I'm rebuilding for now.  Not yet another is what I meant.
<mvo> aha, right
* mvo hugs tfheen
<ogra> ergh, why did my rsync just stop ?
<Znarl> pitti : Ah, you're now using easynet transit to get to a.u.c, which seems to be why it's slow for you.
<pitti> Znarl: ah; this is most likely the reason for mvo's slow link, too?
<Znarl> pitti : You use telia.net otherwise, which is faster, to get to the DC.
<pitti> Znarl: thanks for investigating; good that it's not a DC issue then
<ogra> evil german telecom i guess
<mvo> Znarl: oh! anything I can do on my end? I guess not :/ crap provider
<mvo> Znarl: it seems I go over atlas.cogentco.com
<ogra> my rsync just had an evil hiccup via telecom ... now i cant get more than 4k either
<tfheen> i386 is better now, but it's still a tad oversized..
<Kamion> tfheen: you need to rm your .ssh/known_hosts on lithium or something
<Kamion> or just sudo su - cdimage first
<Spads> hello
<Kamion> I do wonder if I should force LANG=C in build-image-set ...
<Spads> I just updated lithium's global known_hosts.  
<Kamion> ah, thanks
<tfheen> Kamion: to fix up builds you mean or something else?
<Kamion> tfheen: look at the end of the last log file
<tfheen> Kamion: done
<ogra> tfheen, it shrunk by 8M ... thats fine for edubuntu you can start builds for it if you like 
<Kamion> tfheen: I think that group warthogs thing for powerpc only happens when the build is interrupted; my attempts at debugging it haven't been useful so far
<tfheen> Kamion: any excellent ideas what we should do to get i386 down?
<Znarl> mvo : What's your source IP?
<tfheen> Spads: is the ssh key for calcium.u.c globally wrong on lithium?
<Spads> let me check
<ogra> Znarl, http://pastebin.ca/184024
<ogra> i have similar issues
<Spads> tfheen: yes it is.  Let me just go and update our known_hosts databases
<tfheen> Spads: I also get some weird errors when pushing to scandium: buffer_get_ret: trying to get more bytes 257 than in buffer 103 (and more)
<Spads> tfheen: I'll look into that once I get calcium sorted out
<mvo> Znarl: 84.166.114.83 (changes daily)
<Kamion> removing kbd-chooser would help a little bit, but probably not much
<Spads> tfheen: try the calcium thing again
<Spads> scandium was just re-IP'd I think.  Znarl would know more
<tfheen> Spads: seems happy now.
<tfheen> lithium tries to contact chlorine, but get no route to host.
<Spads> yes
<Spads> that's known
<Znarl> mvo : You seem to be getting to a.u.c using an busy peering connection.
<Spads> tfheen: is that fatal?
<mvo> Znarl: aha, ok. thanks
<tfheen> Spads: it's fatal for the mirror on chlorine; I have no idea what's running on chlorine and whether whoever uses it or not cares.
<Spads> chlorine and palmer are going to be in motion for a while
<Spads> we'll be sure to kick off a manual trigger for chlorine when we bring it back into the fray
<tfheen> ok
<Spads> likewise palmer once we bring it down and back again
<Spads> but so long as the script keeps trudging on if a trigger doesn't happen, it can be safely ignored
<tfheen> it does, so we're fine
<tfheen> ogra: your installation ISOs are ready.
<ogra> well, even reloading the webpage on cdimage takes a minute here atm :/
<Kamion> tfheen: there are like loads of language packs in there
<Kamion> I'll cut them down a bit
<ogra> yay 698M :)
* ogra cant belive he has less space issues than ubuntu this time 
<Kamion> tfheen: right, give it 20 minutes for seed propagation
<tfheen> Kamion: ok, thanks.
* ogra grumbles at the 4h ETA of his rsync ...
<elmo> mvo/pitti: how long has archive been like this for you?
* Hobbsee tells ogra to PEDAL FASTER
<Hobbsee> ogra: then it migth go quicker :P
<ogra> hahaha
<pitti> elmo: hm, a few weeks maybe
<pitti> thom: HAH! apache2 builds fine with just downgrading autoconf to 2.59 without any other modifications
* pitti does another dash on the ever-growing list of autoconf f**ackes
<thom> pitti: ugh, that sucks
<tfheen> pitti: oh, that interesting bug.  Same as autoconf 372179 ?
<tfheen> s/autoconf/debian/
<pitti> tfheen: most probably
<tfheen> pitti: if so, just patching the layout file is a reasonable workaround.
<tfheen> (instead of passing --foodir=$bar , etc)
<pitti> tfheen: I thought about patching the layout file, but it seems like an ugly hack
<tfheen> pitti: it's what we did in the Debian packages. *shrug*.
<pitti> tfheen: my plan was to review the diff -ur between a successful and a failed build and spot the important difference
<tfheen> pitti: we're already using the layout called "debian", so it makes sense to modify it to be correct, imo.
<pitti> tfheen: you mean you are patching the 'apr' layout for the apr lib to be like 'Debian'?
<pitti> (since apr is built with the 'apr' layout)
<pitti> but with lots of --foo-dir=$debian_specific_dir
<tfheen> pitti: ah, I fixed it for apr, not apache2, iirc, but yeah, just patching the right layout (or patching the debian layout and using --with-layout=debian) seems sensible.
<pitti> tfheen: ok, I'll do that then
<Riddell> tfheen: you can build new kubuntu livefs's now
<tfheen> Riddell: two out of three of them are already done.  And your alternate CDs are done too.
<tfheen> all livefs-es shold be golden now.  kubuntu and edubuntu alternate cds should be golden, ubuntu, edubuntu desktop cds should be golden.  That leaves ubuntu-server, all DVDs, ubuntu alternate and nothing else, I think
<pitti> tfheen: I'm currently test-building the apache2 fix
<pitti> tfheen: do you want to stall -server until I uploaded this, so that we don't ship apache2 with a known security hole?
<tfheen> pitti: hmm, I guess that makes sense.  That is, -server just built, but I can build again
* pitti avoids looking at the apache2 build so that it becomes faster
<thom> heh
<Hobbsee> hehe
<Hobbsee> good luck with that, pitti 
<tfheen> apache2 builds in the time ooo runs debian/clean, so it's not that long.
<pitti> 'a watched build never boils'
<Treenaks> pitti: boils => finishes
<pitti> yes, yes
<tfheen> pitti: please do tell me when you have something
<pitti> it's just that a watched build never FTBFSes
<pitti> tfheen: of course
<tfheen> jay, ubuntu i386 not oversized any more.
<tfheen> and ubuntu alternate done.
<tfheen> everybody: please test the ISOs, those are hopefully the ones which will be the beta images.
<fabbione> tfheen: are -server images ready?
<pitti> rsync is running at a ridiculous 4kB
<tfheen> fabbione: they need a small update for a new apache2 (see above), but should work otherwise, so testing is good.
<fabbione> tfheen: ok thanks
<pitti> but jigdo grinds through with 200kB/s, so I'll test the ppc/alternates first
* tfheen starts building the DVDs
<tfheen> and with that, I'm off for a bit of food and such
<pitti> tfheen: if apache2 works, shall I upload immediately?
<tfheen> pitti: yes.  And poke Colin to approve it
<pitti> yup, willdo
<pitti> SCORE!
<pitti> tfheen: ok, uploading with a nice autoconf macro fix, no evil hacks
<thom> pitti: what was the fix?
<pitti> thom: fix the affected apache2's autoconf macros to not rely on $@, but restore it from $ac_configure_args instead
<pitti> thom: http://bugs.debian.org/cgi-bin/bugreport.cgi/052_restore_prefix_fix?bug=374160;msg=20;att=1
<pitti> thom: (taken from recent Debian NMU)
<thom> ah, d'oh. 
<doko_> pitti: python2.4 for dapper updated on chinstrap:~doko/python2.4, please wait until the version is in edgy
<pitti> doko_: oh, cool, thanks
<pitti> keescook: https://wiki.ubuntu.com/Testing/Current
<keescook> pitti: sure.  I had "reinstall laptop" on my todo list
<pitti> I'll do the ppc/alternate tests today
<pitti> and tomorrow morning ppc/desktop
<pitti> keescook: https://wiki.ubuntu.com/Testing/Short should be fine as a test plan
<keescook> step 2 in the testing/current says "... listed at the top", which isn't listed.  :)
<pitti> keescook: it's in the derivative-specific section
<Kamion> I do finally have a fix for the HFS bootstrap partition mess in ubiquity in the works, BTW
<pitti> keescook: choose ubuntu/kubuntu/edubuntu (whichever you feel most attached to), there are the matrices
<Kamion> won't make the beta though
<keescook> pitti: cool, sounds good.
<pitti> Kamion: can you please approve the apache2 upload?
<pitti> Kamion: (tfheen was fine with it)
<Kamion> pitti: done
<ogra> tfheen, reboot doesnt work (hardlocks the machine)... but apart from that edubuntu i386 install is golden ...
<tfheen> ogra: note it in Testing/Current, please.
<ogra> willdo
<ogra> i have no plain i386 system around, the hardlock might be caused by my turion (even i doubt it)
<tfheen> get some edubuntu users to test it?
<Kamion> tfheen: bit worried about bug 61732 - investigating
<Ubugtu> Malone bug 61732 in ubiquity "edgy knot 3, installer formated a partition I didn't asked for (windows ntfs)" [High,Confirmed]  http://launchpad.net/bugs/61732
<ogra> ugh ... Testing/current links to dapper isos all over the place 
<tfheen> ogra: please fix that. :-)
<ogra> doing ;)
<tfheen> Kamion: ugh. :-(
<pitti> keescook: btw, if you plan to test a range of stuff, please add your nick without a test value to the particular matrix elements, so that we can coordinate testing better
<pitti> ogra: oh, oops, sorry for breaking your lock, I saw it too late
<ogra> argh...
<ogra> i made a lot of changes (dapper/edgy)
<pitti> ogra: feel free to clobber my changes if you changed anything in Ubuntu (I suspect you only touched edubuntu?)
<Kamion> tfheen: I've marked it for beta
<ogra> pitti, i fixed the links at the top
<pitti> ok, there shouldn't be conflicts then
<Kamion> I think it's been there forever actually, but we should really fix it for beta
<ogra> pitti, you added only "pitti:" ?
<keescook> pitti: okay
<pitti> ogra: yes
<ogra> ok
<doko_> tfheen, ogra: do we have a testing wiki page?
<tfheen> doko_: yes, Testing/Current
<ogra> doko_, https://wiki.ubuntu.com/Testing/Current
<doko_> thanks
<ogra> even though the tests i want for edubuntu go a bit further :)
<ogra> grmbl ... powerpc rsync ETA ... 2:40h ...
* ogra goes for a coffee
<Kamion> rsync ETAs are not to be grumbled about until the rsync has finished
<Kamion> they are calculated based on the current average transfer rate, which might change radically
<ogra> right, 2:40 is the shortest i saw in the last 3 hours
<ogra> the average is rather at 16-20h
<ogra> german telekom has routing probs it seems
<pitti> ogra: (here, too)
<ogra> yep ...
<ogra> and i dont have a single live iso thats up to date :(
<ogra> will be a long night ...
<pitti> ogra: well, mine are two days old and the first already syncs for half an hour; annoying...
<ogra> lucky you mine are knot3 
<Kamion> tfheen: please review http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.1.25.diff
<pitti> however, cdimage.ubuntu.com -> chinstrap wget is only 3 K/s, too
<pitti> ah, better now at second attempt
<Kamion> basically just moves the "did partman detect a filesystem" test inside 'if format' and make sure that an undetected filesystem doesn't trigger formatting
<tfheen> Kamion: I don't know the code well enough to review it well, but it looks good to me.
<Kamion> I've always been a little uncomfortable with that code, but that bug convinced me that it has to go
<Kamion> unfortunately, as usual right now, I'm not in a position to be able to test
<Kamion> I may be able to *try* to boot the powerpc image from my hard disk later
<\sh> When do we have oracle certificaton for dapper? ,-)
<Kamion> mvo: do you know whether mdz approved either of these dist-upgrader uploads in unapproved?
<mvo> Kamion: Accepted:
<mvo> dist-upgrader_20060927.1137_all.tar.gz
<mvo> +(http://librarian.launchpad.net/4519037/dist-upgrader_20060927.1137_all.tar.gz)
<mvo> +was ACCEPTED
<mvo> Kamion: that should be fine, that was the latest version
<Kamion> mvo: oh right - can I reject 20060927.1046 and 20060927.1108 then?
<Kamion> tfheen: ubiquity 1.1.25 accepted
<Kamion> I have to go in a moment; can somebody shepherd that through? sorry for the last-minute discovery
<tfheen> Kamion: I'll rebuild livefs-es.
<Kamion> please (please!) call me on my mobile if ubiquity appears to have regressed due to that upload
<mvo> Kamion: yes, all the others can be rejected
<Kamion> mvo: ok, thanks
* Kamion -> gone
<Ng> cool, much love for the new gnome-power-manager graphs stuff :D
<mvo> Kamion: a quick question. I have some apparently randoms hangs here on a amd64 test-install in ubiquity. it looks like the communication with the child somehow stoped. was that reported before? 
<tfheen> Kamion: he's not around more.  If you need an answer, you must call him
<seb128> pitti: bug day today, somebody on #ubuntu-bugs is asking about bug #61834 if you have a min to have a look to it and comment
<Ubugtu> Malone bug 61834 in hal "SD slot on 7-in-1 USB card reader not recognised as SD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61834
<doko_> Kamion: should I be offered a "Resize partition" option, when I install a second time onto the same disk?
<mjg59> seb128: Looks like the right fix
<seb128> mjg59: ok, thank you
<keescook> pitti: Desktop i386 fails "check" similarly to your PPC bug 60395
<Ubugtu> Malone bug 60395 in cdrom-checker "desktop CD-ROM checker hangs forever" [Undecided,Confirmed]  http://launchpad.net/bugs/60395
<mvo> tfheen: thanks, its not that urgent, I will keep testing
<tfheen> mvo: thanks.
<keescook> are boot-time warnings sufficient to open a bug for beta testing?
<keescook> (udev warnings, /var/run over-mount warnings, etc?)
<tfheen> keescook: please do file bugs, if you think they're _urgent_ mark them with the ubuntu-6.10-beta milestone.
<tfheen> they don't sound like blockers, though
<keescook> tfheen: okay, thanks
<jdong_> whose archive day is friday?
<pitti> argh, oem-config has regressed even further
<tfheen> pitti: is that possible?
<tfheen> as in, it used to not start.
<pitti> tfheen: last time it started and got stuck on the third question
<pitti> (in knot-3)
<pitti> now it immediately crashes
<janimo> tfheen: permission to upload a new xfce4-mixer package? not critical for beta, but would be goot to have it tested
* pitti files a bug
<tfheen> janimo: no, please not.
<janimo> tfheen: ok
<tfheen> pitti: hmm, can you check that your version has:
<tfheen> 14:38 < Kamion> tfheen: just heard about an oem-config bug
<tfheen> 14:38 < Kamion> +  * Add /usr/lib/oem-config to sys.path in oem-config-dm so that it can
<tfheen> 14:38 < Kamion> +    import frontend modules.
<tfheen> 14:39 < Kamion> +sys.path.insert(0, '/usr/lib/oem-config')
<pitti> tfheen: it's probably that (see bug 62684)
<pitti> bug 62648 even
<Ubugtu> Malone bug 62648 in oem-config "immediately crashes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62648
<pitti> tfheen: will take me a minute, console is completely broken and there's no user; 
* keescook makes giant list of subtle bugs
<pitti> keescook: please only note the real bad ones on Testing/Current; the less important ones should just be filed
<keescook> pitti: yup, following tfheen's suggestion.
<keescook> if a dialog confirmation (manual partitioning) pops under ubiquity... that's going to confuse a lot of people, but shouldn't really be considered a blocker, correct?
<pitti> tfheen: hm, it already has that path
<pitti> keescook: that one is filed for ages
<pitti> keescook: right
<mdz> Kamion: yes, I accepted the newest one and ignored the other two dist-upgraders
<mdz> tfheen: how goes?
<pitti> tfheen: ah, right, that was it
<fabbione> Kamion: your finish-install fix works like a charm! GOOD WORK!
<fabbione> tfheen: sparc -server CD is go, i386 server + DNS + LAMP netinstall is good, sparc netinstall + raid + lvm in different combos including Niagara is go
<fabbione> tfheen: also tested resize of windows partition on x86 and that was good too
<tfheen> mdz: what I believe are golden alternate images are up now.  Waiting for the fix for http://launchpad.net/bugs/61732 to propagate through soyuz.
<Ubugtu> Malone bug 61732 in ubiquity "edgy knot 3, installer formated a partition I didn't asked for (windows ntfs)" [High,Fix released]  
<tfheen> (and then I can build final livefs-es).
<tfheen> pitti: hmm, that should have been on the CDs then.  Are you sure you have the latest ones?
<pitti> tfheen: yes, pretty sure
<pitti> tfheen: there are more issues, please see the bug trail
<pitti> tfheen: I checked the CD again, I have 20060927.7
<pitti> it has oem-config 1.5 from Sept 25
<pitti> tfheen: so it's indeed missing 1.6
<mdz> sfllaw: ping
<pitti> tfheen: however, it's not the only bug (see bug trail), so it'll require another upload
<tfheen> pitti: yeah..
<tfheen> pitti: wondering if we should drop oem-config for beta
<tfheen> mdz: ^^
<mdz> tfheen: oem-config is busted?
<tfheen> mdz: yes, see https://launchpad.net/distros/ubuntu/+source/oem-config/+bug/62648
* pitti wonders whether he should keep this broken system for further examination or continue with install testing
<Ubugtu> Malone bug 62648 in oem-config "immediately crashes" [Undecided,Unconfirmed]  
<mdz> tfheen: we can document that
<tfheen> the first is something we had an upload for, but it didn't make it in, for some reason.
<tfheen> mdz: my thought exactly.
<tfheen> pitti: did you upload the fixed a2?
<pitti> tfheen: yes, hours ago, Kamion approved it
* pitti checks archive status
<mdz> tfheen: once a fixed daily is available, add a link from the wiki version of the beta announcement so that folks can find it
<tfheen> mdz: s/beta announcement/release notes/?
<mdz> tfheen: yes, same
<pitti> tfheen: yep, a2 is built everywhere and in the archive
<tfheen> pitti: excellent
<pitti> tfheen: I'll ditch my laptop then and continue testing
<pitti> I guess we need the other stuff tested more urgently then
<tfheen> pitti: yes, please do
<mdz> Riddell,ogra: do you have any outstanding issues?
<Riddell> mdz: looking good so far
<tfheen> fabbione: new -server ISOs building.  Those should contain a security-fixed apache.
<keescook> software-prefs doesn't have 6.10 listed as a channel.  ;)
<fabbione> tfheen: ok.. i am not sure how much energy i have left for another round of tests. i am at 14 hours in the day
<fabbione> and i have fixes ready for other release bugs
<mdz> tfheen: is that the only change?
<tfheen> mdz: in the -server ISOs?  Yes, TTBOMK.
<mdz> if so, we don't need the security-fixed version for the beta. better to have the tested version
<tfheen> it's tested in dapper, though.
<mdz> beta users will need to install updates anyway, as will users of the final release
<tfheen> so you'd like me to cancel the -server build?
<mdz> up to you whether you cancel it or just ignore it
<mdz> but we can use the version fabio tested for beta if it passed tests
<tfheen> ok
<mdz> better to spend time testing other isos
<sladen> jono is never online when you want him...
<dholbach> sladen: he'S in holidays
<sladen> dholbach: already!  he's barely started
<dholbach> afaik he even said so in his blog
<nixternal> he is on holiday right now sladen
<nixternal> hehe
<nixternal> ya
<nixternal> LOL
<nixternal> dholbach: and don't forget about the email he sent to the mailing lists ;)
<nixternal> ok..im done beating this one..im gonna hide for a minutes
<keescook> where can I find a list of package versions installed via the beta CD?
<sladen> keescook: dpkg -l
<keescook> sladen: well... this is why I'm confused.  after install, it claims it wants to do 358 updates, so I don't trust my system's view of the versions.
<mdz> keescook: there is no beta CD yet, but in general, look in the .manifest files adjacent to the .isos
<keescook> mdz: ok, thanks (sorry, meant: "daily")
<mdz> keescook: 358 updates relative to what?
<keescook> mdz: that's what I'm trying to figure out.  only dapper channels were selectable in synaptic, so I'm trying to figure out where the confusion is.
<mdz> keescook: you're running Dapper then
<mdz> in which case, 358 updates isn't entirely unbelievable
<keescook> mdz: considering I installed from the edge-desktop-i386.iso, this is why I'm confused.  :)
<ogra> mdz, edubuntu i386 install is golden already, i have some network probs over here that delays my rsyncs 
<ogra> so ppc and amd64 are still oustanding, and i fear my liveCDs wont be up to date before early morning ...
<sladen> keescook: 'edgy' or 'edubuntu'?
<ogra> but i dont expaect any evil stuff
<sfllaw> mdz: Pong.
<keescook> sladen: edgy.
<mdz> sfllaw: are you set up for testing according to plan?
<pitti> keescook: where did you download this from?
<keescook> pitti: http://cdimage.ubuntu.com/daily-live/current/
<pitti> now, that looks ok
<mdz> keescook: there's surely been a mixup somewhere and you don't have the CD you thought you had
<sfllaw> mdz: I talked to cr3 about it and we're ready to do installations.
<keescook> usplash was the test-screen too.  I'm going to start over...
<mdz> sfllaw: tfheen can fill you in on which candidates are ready
<pitti> wow, ppc's usplash loks just terrible after some seconds
<tfheen> sfllaw: all alternates are ready, -desktop needs an update for a possible data loss issue.
<tfheen> sfllaw: please see Testing/Current for the versions we want tested
<pitti> keescook: what does 'lsb_release -a' say?
<ogra> mdz, the links on Testing/Current were wrongly pointing to dapper before, if keescook used one of them he might have gotten a dapper iso
<keescook> pitti: md5sum doesn't match... I'm redownloading
<fabbione> mdz: i did install LAMP and apache2 was working after the reboot. i don't mind to do another test... doesn't take terribly long
<fabbione> tfheen: ^^^
<sfllaw> tfheen: Er...  The daily*/current is Edgy right?
<sfllaw> I should remove the stuff on this page about Dapper?
<mdz> fabbione: if you have time for more testing, I'd prefer that you test things which haven't been tested yet.  it really isn't important to try to roll security updates in at the last minute
<tfheen> sfllaw: yes, please.  It's all edgy.
<keescook> ogra: I think it was an ancient edgy ISO, actually.
<ogra> ah
<keescook> probably happened while URL were out of date... :(
<fabbione> mdz: i did test what i could test already.. but i am pretty much brain dead atm.. if it's just a reinstall i can do it with no problem...
<ogra> well, they were dapper urls until i did the first edit of the page ... i suspect i was the first who touched it after dapper testing :)
<tfheen> ogra: uh, no.  It's been used for all the knots as well, I just haven't noticed.
<ogra> (apart from someone flushing the results from the tables)
<ogra> heno, k
<ogra> err ...
<keescook> ogra: no clue.  The ISO claimed to be 6.10, but the md5sum didn't match the 2006-09-27 build md5sum.  So... redownloading.  :)  I have lots of great notes on the earlier edgy build.  ;)
<mdz> tfheen: jbailey mentioned you'd requested a hardware test from marc; was that completed?
<ogra> keescook, ah :)
<tfheen> mdz: I haven't gotten any feedback from him, nor seen anything in Testing/Current, so I assume not.
<Xnix> is there a doc that explains how to build my own linux-restricted-modules based on a self-compiled kernel
<Xnix> to work with my compiled version
<lfittl> where can I find the blacklist that lists reasons why we kicked out packages? (want to know that for nvidia-cg-toolkit, we removed it, Debian still has it)
<mdz> tfheen: that was for an earlier daily build?
<tfheen> mdz: as I understood it, it wasn't a single-shot thing but more like "we're getting close to release now, please help testing the images".  I haven't given him an exact image to test.
<cr3> any ideas why ubuntu 6.06.1 server boot stalls with the following message on Dual Opteron: io scheduler cfg registered
<keescook> cr3: I've seen that on dapper too.  If I reboot, it usually goes away.  :(
<_ion> 6.06 *is* dapper.
<keescook> _ion: I meant, "I too, have seen it"
<zul> later
<keescook> c'ya zul
<fabbione> Kamion: ping?
<fabbione> how is the check CD supposed to be selected?
<fabbione> (i think we forgot to update the silo text on cd)
<mdz> tfheen: ok, so this test might be the first one on the hardware in the lab
<tfheen> mdz: quite conceivably, yes.
<cr3> keescook: thanks for the suggestion. however, the problem arises after selecting any of the installation options from the server CD. So, I can't really reboot otherwise I'm simply back to square one.
<mvo> tfheen: should #61684 be fixed with the latest livefs build?
<tfheen> mvo: yes
<tfheen> mvo: do you observe otherwise?
<mvo> tfheen: unfortunately yes :/ 
<tfheen> mvo: *sigh*, ok
<pitti> I checked it on latest powerpc livefs
<mvo> tfheen: are there logs somewhere that I can look at ?
<mvo> I checked it with the latest i386 too
<tfheen> mvo: logs of the livefs build?  Yes, http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/
<tfheen> for some reason, there is just an AMD64 build there, not an i386 and ppc build.
<tfheen> I need to rebuild those for ubiquity anyway, so I'll do that now
<mvo> thanks
* fabbione calls it a day and falls off the net
<pitti> bye fa
<pitti> bye fabbione 
<fabbione> tfheen, mdz: i have my mobile phone turned on for disaster recovery or anything slightly blocker/urgent
<pitti> BenC: do you know how to reproduce the kernel oops when killing apport?
<pitti> BenC: I tried it several times now on the old kernel (-8) without success
<BenC> pitti: kill apport before it's done
<BenC> or kill the gdb process
<pitti> BenC: I did the former
<pitti> BenC: I used kill -SEGV firefox-bin to have a reasonably long operation
<pitti> but it's just killed without any oops or other negative impact
<pitti> BenC: has this already been fixed in -8?
<BenC> it was supposed to be
<BenC> glad to see it worked :)
<pitti> BenC: I'm not sure whether I ever killed apport with a pre -8 kernel
<mdz> sfllaw: just heard from Kamion; he'll be doing some testing offline and will report any findings to you by phone
<sfllaw> mdz: Cool.
<mdz> sfllaw: I gave him the 8900 number from the wiki since I didn't know if you had a phone nearby
<mvo> pitti: did you got offered a non-german keylayout by default too (when booting  with german)?
<pitti> mvo: I think I saw that in my last amd64 install
<pitti> mvo: but since ppc has no gfxboot, I can't test it there
<pitti> mvo: btw, an alternate installation has the same ubuntu-desktop removal problem
<mvo> pitti: *sigh*
<sfllaw> mdz: Uhm.  Best number is +1-514-839-4887.
<mdz> sfllaw:  the one I gave him is the office landline.  your mobile says EMERGENCY USE ONLY in big scary letters
<sfllaw> Fair enough.
<sfllaw> It was, until now.
<sfllaw> I'll change it.
* LaserJock wonders how many fan calls sfllaw will get now
<sfllaw> LaserJock: Please don't be #1.
<mdz> pitti,mvo: did someone confirm with infinity that the livefs changes for that were complete?
<mdz> he emailed me saying he would do it
<pitti> mdz: I confirmed that it does not work on /current desktop and alternate
<mdz> about 10 hours ago
<mdz> (this is bug 61684)
<mvo> mdz: I talked to him earlier and he said it should be fixed. but I haven't seen the changes myself
<Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  http://launchpad.net/bugs/61684
<mdz> mvo: how can we work around it?
* pitti just added a comment to this with the current state
<mvo> mdz: there is no really good workaround short of removing /var/lib/apt/extended_states (which is wrong too, but better than the current thing)
<mdz> mvo: removing it under what circumstances?
<mdz> mvo: during the live build?
<mvo> mdz: yeah, after the live build
<mdz> tfheen: do you have access to hack that yet?
<tfheen> mdz: no.
<tfheen> we could sneak it in via the sysadmins.
<mdz> tfheen: please open an RT ticket
<tfheen> for the access or for hacking it once?
<mdz> tfheen: access
<mdz> might as well solve it permanently
<tfheen> mdz: 16833 is about it.  Do you have access to look at it?
<mdz> tfheen: I should, but I don't know the URL
<mdz> ok, found it
<tfheen> yeah, you can see the discussion there.  I didn't want to force anything, but if you want to make it happen, feel free to chime in.
<tfheen> mdz: so, what do we do?
<tfheen> I need to catch a bit of sleep to make my headache go away.
<mjg59> mdz: I agree that we ought to update the bluez package - what we have seems a touch unstable. But that can wait until after beta.
<mvo> mdz: I found the reason why the https://launchpad.net/distros/ubuntu/+bug/61684 is not gone away :(
<Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  
<seb128> Kamion: could you promote industrial-cursor-theme when you have some time (pitti said it's fine)? no hurry, that's just to make gtk2-engines-industrial installable again
<pygi> sivang: you still here by any chance?
<sivang> pygi: I am
<pygi> sivang: may I grab you for just a sec?
<sivang> pygi: sure
<ogra> muhahahaha 
* ogra cant belive it ... jwz switches to ltsp :)
<pygi> ogra: and jwz would be who? :P
<ogra> mr. xscreensaver ... he's since 100 years the screensaver maintainer 
<LaserJock> haha
<Ng> I thought he defected to os x because alsa was annoying? ;)
<ogra> well, he has "kiosks in his nightclub" (his words) and wants to switch them to ltsp ...
* mvo wonders if that means boxes that show films or something
<ogra> haha
<ogra> funny usecase :)
<mjg59> No, they're web browsing things
<mjg59> http://www.dnalounge.com/backstage/src/kiosk/
<Keybuk> mjg59: oh, and URGENT wasn't documented last time I looked <g>
<bioeng> Hello everyone
<bioeng> I am trying to get some experience in electrical and software engineering
<bioeng> now that I've dropped out of college
<mjg59> Keybuk: Tollef added it a couple of weeks ago
<mjg59> It was needed for the CD MD5 checking
<mjg59> But it ought to do what you want, right?
<bioeng> I'm trying to find out how to get that expericne
<bioeng> Any suggestions?
* mjg59 clears out a load of usplash bugs
<Keybuk> mjg59: the only problem there is that the theme appears to be designed by somebody who assumed there would never be any text
<Keybuk> if we did an URGENT to say "Will now check the root filesystem", etc.  there would always be text
<mjg59> Keybuk: Mm?
<mjg59> Oh, yes, it has to be done only in the case of us actually checking the filesystem
<Keybuk> which we don't know
<mjg59> Which is an interesting problem to solve
<Keybuk> not without modifying, or at least driving, fsck
<mjg59> Indeed
<Keybuk> wouldn't usplash just timeout anyway?
<mjg59> It ought to, yeah
<Keybuk> and show them the console messages and fsck output underneath?
<mjg59> Unless something is bumping the timeout and never resetting it
<mjg59> You can flag an fs to require fsck on next boot and test this fairly easily :)
<mjg59> Maybe we should restart usplash after fsck if it exits
<Keybuk> that's a not unresonable short-term solution
<Keybuk> longer term, it'd be sweet if we could detect an fsck needed, and even drive a progress bar on the usplash to show it
<ogra> mjg59, bah, so no tabledance then :)
<Keybuk> I'd vaguely planned to do that for edgy, but never got nearly enough tuits
<mjg59> Keybuk: Spec!
<mjg59> Anyway, I think usplash is pretty much feature complete now
<mjg59> All the known bugs ought to be fixed
<mjg59> (In bzr, not in the archive)
<mjg59> The themes need a bit of love, though
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/usplash-fsck-progress
* jdong heads over to usplash bzr and sees if ati is indeed fixed
<jdong> <insert general wish for faster bzr http performance here>
* ogra cries ... my ppc iso is broken :((
<pygi> ogra: :-/
* jdong goes to console ogra, but suddenly notices that his usplash is done installing, and goes back to being selfish
<ogra> i have a depends line like: syslinux [i386 amd64] , mknbi[i386]  | yaboot[powerpc]  | aboot[alpha]  | sparc-utils[sparc]  ... why does it complain about mknbi ?
<_ion> Is usplash going to get resolution fallback support?
<ogra> it shouldnt care about it on powerpc
<mjg59> _ion: What do you mean by resolution fallback support?
<Keybuk> ogra: you missed a " " there, no?
<ogra> i dont think so ...
<_ion> mjg59: usplash.conf on my machine contains xres=1024 yres=768 (from X config), but usplash just says "screen init failed" (AFAIR) and exits.
<ogra> argh !
<ogra>  EARLY_PACKAGES="xorg ltsp-client discover1 laptop-detect xresprobe esoun
<ogra> d inputattach usplash ldm ltspfsd mknbi"
<mjg59> _ion: It would be nice to know why it's failing :)
<_ion> mjg59: When i manually change it to 800x600, it works.
<ogra> indeed if the script tries to install it after debootstrapping that cant work 
* ogra hangs his head in shame
<_ion> mjg59: Yes, it would. :-) I tried to debug it, but didn't have success.
<ogra> tfheen, still around ? 
<mjg59> _ion: Though I admit that that's not terribly practical given the current code. God I hate you, svgalib.
<mjg59> _ion: I'll see what I can do to make that saner.
<jdong> mjg59: I compiled usplash from bzr, and it just segfaults when I try  to run it
<jdong> do I have to do something special to make usplash happy?
<mjg59> jdong: Did you install it, or just run it from the build directory?
<jdong> mjg59: I built it in a pbuilder and installed it
<jdong> then ran update-initramfs -u
<mjg59> jdong: Ok. Any chance you can give me a backtrace?
<mjg59> Running it from the console should be fine
<jdong> gdb doesn't know any symbols.... would an strace be of any use?
<ajmitch> mdz: what's your policy on new packages going into universe after universe freeze? up to the MOTU team to decide?
<mjg59> jdong: Copy the files out of the build directory before they're stripped
<jdong> mjg59: k, will do
<fschoep> I've got a simple question - is there a devteam meeting tomorrow? It isn't listed on the Fridge it seems
<Burgundavia> fschoep: yes
<fschoep> Burgundavia: at 23:00 UTC?
<ajmitch> it was said that it's cancelled due to beta release
<mvo> there will be no dev-team meeting this week
<Burgundavia> oh
<Burgundavia> hmm
<ajmitch> on u-d-a
<mvo> mdz: would a package descriptions translation upload be ok for beta? it will update only the translated descriptions for universe + remove a incorrect Translations-ko 
<Keybuk> he's at the dentists
<ajmitch> poor guy
<fschoep> OK thanks for the quick answer
<Keybuk> still too many jelly beans
<mvo> oh
<mvo> poor guy
#ubuntu-devel 2006-09-28
<ogra> sigh
<ogra> Keybuk, uploads are queued, right ? 
<mdz> mvo: back
<mdz> ajmitch: yes, I think MOTU should take responsibility for that but I'm happy to advise
<mvo> how did it went?
<mdz> mvo: so what are we doing about 61684?
<mdz> mvo: clean bill of health, my teeth are lovely
<mvo> mdz: great! congrats :)
<ogra> mdz, i found a bug that breaks my ppc and amd64 builds ... do you know if its safe to upload a new ltsp (can tollef cherrypick that package if i do that) to get new isos in the morning ?
<ajmitch> mdz: ok, we have a team of dholbach, slomo & siretart to handle exceptions for universe now
<ogra> i know they are queued ...
<jdong> mjg59: http://pastebin.com/795775
<mvo> mdz: we have two options (well, three): a) empty /var/lib/apt/extended_states b) upload new apt with a single line patch c) ignore the thing [I don't like c)] 
<mdz> ogra: uploads are queued
<mdz> mvo: b)
<ogra> mdz, right, but can he cherrypick it (or does he need to accept all of the queue)
<mdz> ogra: they are processed individually
<ogra> ok, then i'll upload and send him a mail to ask for new isos ...
<ogra> its so silly ... grmbl
<mdz> ogra: what's the bug# for your issue?
<ogra> just filing it ... 
<ogra> i moved mknbi for early packages to ltsp-client arch specific deps (i thought) but missed to remove it from early  packages
<ogra> mdz, bug 62690
<Ubugtu> Malone bug 62690 in ltsp "mknbi dependency breaks powerpc and amd64 installs" [Critical,Confirmed]  http://launchpad.net/bugs/62690
<mdz> ok, 62690 and 61684 are the only issues I am aware of for beta
<mdz> if there's anything further I ought to know about, please yell (and get a bug filed with the beta milestone)
<ogra> sure, i will ... but there should be none ... if i remove mknbi for the early_packages variable it even finishes the install
<mjg59> jdong: Ha. That's the code I just added. Hang on.
<mdz> mvo: is there any way you can confirm whether the livefs build script is doing the right thing?
<mdz> mvo: if it isn't, your fix won't correct the problem
<ogra> i would have catched it this afternoon already if i had the isos ... damn telekom
<mdz> sfllaw: any problems uncovered in the lab?
<mdz> you reference bug 62689 in the wiki...
<Ubugtu> Malone bug 62689 in debian-installer "Hangs at 2% of "Select and install software"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62689
<doko_> think, I found the cause for the OOo build failure. we'll see tomorrow, if the build succeeds
<doko_> good night
<mdz> mvo: you may want to have a look at 62689; it seems to be apt which is stalled
<mvo> mdz: hfsutils is installed on recent live-cds. that is a indicator that the livefs build uses the new apt taskinstall-code (becaue hfsutils is no direct dependency of ubuntu-standard on i386 but has a task header)
<jdub> ha ha ha ha ha
<jdub> ESR -> Freespire Leadership Board
<Fujitsu> ... really?
<jdong> ha crap mjg59, that usplash crash might not be valid... I just realized it built in a dapper pbuilder
<tseng> jdub: can't wait for the cartoon
<Burgundavia> Fujitsu: yep
* jdong smacks himself for pbuilder stupidity AGAIN
<jdub> http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-27-2006/0004440536&EDATE=
<Fujitsu> Ow.
<jdub> so, apparently it's true: they really *don't* have anyone there who knows anything about how the floss world works
<Burgundavia> jdub: did you see the review by the Free Agent of Freespire. He was not impressed and thought that Ubunut (and OpenSUSE) were just as good
<jdub> just reading it
<jdub> but he was an ubuntu fanboy way back
<Fujitsu> Darn.
<mvo> sfllaw: is #62689 reproducable? or do you have the machine with that failure still runing?
<mvo> mdz: I would like to upload a ddtp tarball bug #59673. is that acceptable for the beta? its not critial though
<Ubugtu> Malone bug 59673 in synaptic "Synaptic shows a description in incorrect language for korean" [High,In progress]  http://launchpad.net/bugs/59673
<ijuz> jdub: when you buy freespire consulting from ESR you get a free gun ;)
<jdub> "When you get right down to it, there's really no comparison: Ubuntu's package management is easier and more attractive."
<jdub> ^ on click'n'run
<jdong> that's right, let the egos fly free :)
<jdong> mjg59: false alarm; usplash still segfaults
<mjg59> jdong: Yeah, working on it now
<jdong> cool
<Ng> is it too late to get a wireless driver regression looked at for the beta release? just found it when I booted a beta from earlier today
<mjg59> Ng: Almost certainly, I'm afraid
<mjg59> Ng: What driver?
<Ng> atheros, but only some versions
<Ng> my desktop is fine (upgraded from dapper), my laptop complains of missing symbols from the live cd
<mjg59> jdong: Amusingly, I can't reproduce here
<Ng> it's bug 60938
<Ubugtu> Malone bug 60938 in linux-restricted-modules-2.6.17 "Atheros Chipset Not Detected; Unknown Symbol" [Critical,Confirmed]  http://launchpad.net/bugs/60938
* rideout is listening to And She Was by Talking Heads [amarok] 
<jdong> rideout: please don't do that.... it gives me headaches :)
<mdz> mvo: let's only fix what's needed for the beta at this point
<mvo> *nod*
<jdong> mjg59: hmm interesting.... this time I am confident that I built usplash in an edgy pbuilder....
<mjg59> jdong: But the bug is clearly that the ds passed to gl_getpalette is NULL
<mdz> mvo: great, thanks for confirming that
<mdz> mvo: is the fact that hfsutils has a task header on i386 a bug?
<Ng> actually no I don't know that it works on my desktop machine, that's still on -8 which had previously fixed the bug
<mjg59> jdong: Which shouldn't be possible :)
<jdong> mjg59: yay! that's always good :)
<mjg59> jdong: Can you check that usplash_svga_init contains a call that mallocs initial_palette?
<jdong> mjg59:         initial_palette = malloc(sizeof(char) * 768);
<mdz> ogra,mvo: notify me when your uploads are in the queue
<Ng> mjg59: are there release notes for the beta? it might be worth mentioning that atheros chipsets won't work?
<ogra> mdz, its in, but i also mailed tollef
<mjg59> Ng: That may have been version skew in the linux-restricted-modules used in the daily image
<mvo> mdz: it looks like the generated task headers are not arch-specific - so there is a bug there
<mdz> ogra: tollef has gone to sleep
<mvo> mdz: apt is uploaded
<mjg59> Ng: It's quite possible the beta will work
<mdz> I'll be driving
<ogra> cool, thanks
<mjg59> jdong: can you throw a printf after that to check that the malloc succeeded?
<jdong> mjg59: doing that right now :)
<mdz> ogra,mvo: apt and ltsp accepted, should be in time for this cron.daily
<mjg59> jdong: usplash_init is certainly called before usplash_setpalette ever is...
<Ng> mjg59: if I reboot into -10 on my desktop and it's still doing it, since no edgy cd has been near that machine, that would suggest not, right?
<ogra> nice :)
<mjg59> Ng: Probably, yes
<mvo> thanks mdz!
<Ng> mjg59: phew, the desktop is ok, thanks :)
<mdz> mvo: please file a bug about the task header
<mdz> mvo: subscribe ubuntu-archive
<jdong> mjg59: uhh, is usplash_vga_init() ever called?
<jdong> mjg59: I don't see it in the backtrace
<jdong> and none of my printfs in that function show up :)
<mjg59> jdong: It won't be in the backtrace - it's not in the call chain
<mjg59> usplash_init is called at line 353 of libusplash,c
<mjg59> That returns usplash_operations->usplash_init, which is set to usplash_svga_init earlier on
<mjg59> Oh!
<mjg59> printfs won't show up - stdio has been closed
<mjg59> (sorry)
<mjg59> Hm
<jdong> interesting
<jdong> well, off to file IO then :)
<mjg59> gdb it, break on usplash_svga_init?
<mjg59> Then step through that
<mvo> mdz: bug #62699
<mdz> Ubugtu: bug 62699
<mdz> Ubugtu: scoundrel
<ogra> Seveas, ?? ^^^ 
<mdz> Ng: are you sure you have the new restricted-modules installed?
<Seveas> @whoami
<Ubugtu> I don't recognize you.
<Seveas> hmm
<Seveas> bug 6666
<Ubugtu> Malone bug 6666 in malone "visited links on bug page have insufficient contrast" [Medium,Fix released]  http://launchpad.net/bugs/6666
<Seveas> right....
<Seveas>  bug 62699
<Seveas> -Ubugtu- Error: Error getting Malone bug #62699: Bug does not exist
<Fujitsu> Nice.
<Seveas> so he was working after all ;)
<jdong> mjg59: I set a breakpoint on usplash_svga_init, it segfaults before reaching the breakpoint
<mjg59> jdong: Bongtastic
<Ng> mdz: I have several versions installed on the desktop it would seem, the broken one (laptop) was using whatever was in the .2 live cd from 20060927
<mjg59> jdong: No, I genuinely can't see any way that can happen
<jdong> :(
<mjg59> jdong: And I can't reproduce it here at all
<jdong> hmm
<Ng> mdz: I was just in the middle of putting a comment with some more info on the bug, is there anything I can include to make it more useful? or is it likely not a bug as mjg's suggestion and it working on my desktop suggets?
<mdz> Ng: you could answer the question I asked in the bug
<Ng> mdz: sure. I know the result, which is a weird error about symbol -1 not being found, but I think that was because that module isn't really available, there was a ath_hal.mod.o afair, but I'll check
<mjg59> jdong: Oh, hm.
<mdz> Ng: note that I said ath_hal, not ath_pci
<mjg59> jdong: Ok, now I can reproduce it
<Ng> mdz: yeah, when I noticed ath_pci failing to load I tried it by hand, then ath_hal, but I will double check
<mjg59> Nnngh.
<mvo> sfllaw: please ping me about #62689 as soon as you can, that concerns me somewhat
<mdz> mvo: sfllaw has left the building, call his mobile
<mvo> mdz: right, missed that. will do
<mdz> mvo: that's because he didn't mention it
<neuralis> mdz: i have a confidential matter to discuss. do you prefer irc or mail?
<mjg59> jdong: Oh crap, i see
<mdz> neuralis: if it isn't about the beta release, then email is better
<neuralis> mdz: it's not; i'll mail you.
<slomo_> Remenic: ping? (short question and maybe a bug about clearlooks)
<mjg59> jdong: It's in bzr now, but you may need to wait for http to catch up
<jdong> mjg59: ok, thanks
<mjg59> Oh, hang on, that's not going to work
<mjg59> No, wait, it should do
<mjg59> Meh
<jdong> lol
<jdong> I'll let you know :P
<mjg59> jdong: Move the call to gl_getpalette to just underneath the malloc
<jdong> mjg59: where's that?
<jdong> I'll just wait till launchpad catches up
<mjg59> jdong: In usplash_svga.c
<jdong> mjg59: alright, let's see if thist works... :)
<joejaxx> Kamion: may i pm you?
<Ng> mdz: done
<mdz> joejaxx: colin is not online
<jdong> mjg59: that fixes it
<mjg59> jdong: All works ok?
<joejaxx> mdz: ?
<joejaxx> mdz: colin?
<jdong> mjg59: yeah, finally the logo's not in inverted colors :)
<zul> joejaxx: kamion is not online
<joejaxx> zul: oh alright i was not aware
<jdong> mjg59: fix your bzr whoami on vaio :P
<neuralis> mdz: sent, and rather time-sensitive, though i'm aware of your current preoccupation with the beta.
<mdz> apt and ltsp built successfully
<mdz> publishing
<mjg59> jdong: Mm?
<jdong> mjg59: committer: Matthew Garrett <mjg59@vaio>
<mjg59> Oh
<mjg59> Heh
<jdong> mjg59: set a real e-mail address
<mjg59> I don't usually commit from there
<ogra> mdz, did you already trigger new edubuntu isos ? else i will do that before i go to bed now 
<mdz> ogra: I did
<ogra> (ltsp 0.115 is up )
<ogra> oh, wow
<ogra> thanks 
<mdz> all alternates are building now; I'll do desktop after that
<tseng> are we there yet?
<tseng> :)
<ogra> ok, i'll strt my rsyncs then and will test tomorrow morning ...
<ogra> *start
<Viper550> I have an interesting installer idea for Edgy+1
<mdz> doko_: that's great news, let me know what you find
<Viper550> What the heck just happened?
<tseng> its called a netsplit
<Fade> netsplit
<tseng> one or more servers loose their connection to the network
<Fade> usually caused by routing flaps in transit networks, but also caused by DDoS attacks. :)
<Fade> it almost reminds you of the halcyon days of efnet. 
<ogra> or by mindless server admins that sumble over a power cable ;)
<Lathiat> most of the time its just somethign dying
<Lathiat> ogra: hehe
<Lathiat> or even network rerouting
<tseng> ogra: that would never happen
<ogra> haha
<Lathiat> no ones built redundant paths into an ircd yet :)
<Fade> largely because of the way the irc rfc is layed out.
<Viper550> oh...
<Fade> anyhow, bed for me. 'nite
<Viper550> Well, anyway, here is my idea...You know how the new Desktop CD for Dapper uses that new Casper installer system?
<ogra> tseng, i worked for a cble company in another life where they had the most expensive redundant systems i've ever seen ... one day a colleague of mine worked in the DC and wanted to pick up something ... he touched a switch with his butt in an open server cabinet ... the whole TV for the region was down for some hours
<tseng> ogra: i forgot </sarcasm>
<ogra> right :)
<ogra> he got fired for that btw ... even he wasnt the guy who left the door open
<tseng> ogra: similarly we had a contractor from Siemans lift the glass covering and push the big red emergency power shutoff button
<Viper550> Uhh, did anyone pay attenton to my comment?
<ogra> tseng, haha ...
<neuralis> Viper550: casper is not an installer. do you mean ubiquity?
<LaserJock> and "
<Viper550> Well, whatever, the new system where it copies files instead of packages
<tseng> Viper550: you could finish your thought at least
<LaserJock> "new" WRT to Dapper is a little... old ;-)
<Viper550> Well, why don't we try and make a text-based installer using that system, so we can also use the new faster system on older systems
<LaserJock> Viper550: go for it!
<tseng> because the text-based installer doesnt have the filesystem with all the files on it
<tseng> it has a set of packages
<tseng> and is very tied to this assumption
<tseng> ubiquity, the new installer, was written from scratch with completely different assumptions at its core
<LaserJock> tseng: I'm assuming he was offering to write us a new text installer :-)
<Viper550> I know, I meant make a new installer by scratch, using Ubiquinty's design
<tseng> LaserJock: oh, fantastic
<Viper550> I'm not a coder, but still: A text based Ubiquinty-based installer would be awesome!
<tseng> Viper550: to shave 5 minutes off installs?
<Viper550> Yes.
<jdong> Viper550: honestly... :)
<ogra> wouldnt help me in edubuntu ... nor would it help the xubuntu people 
<ogra> which leaves you with kubuntu and ubuntu ... which both are fine for installing in graphical mode ...
<tseng> saving 5 minutes on "alternate" installs isnt worth the burden of building and maintaining a new installer
<ogra> so where is the advantage ? 
<Viper550> Yes, giving everyone a chance to have a faster install is a great idea. I hate how you need 256 MB ram to use the Desktop CD, not everyone has that powerful of a system!
<LaserJock> Viper550: you are talking about 2 different things
<ogra> right
<tseng> Viper550: please understand the huge ammount of effort
<LaserJock> speed of install isn't the same a lowering install requirements
<tseng> Viper550: that needs to be weighed against any possible gains
<LaserJock> I think the desktop takes much more resources then the installer itself, I think
<ogra> well, or just provide the code :)
<Viper550> Yeah...or maybe a boot option on the desktop CD that only loads a minimal window manager and the installer
<tseng> that sounds a more worthwhile development effort
<tseng> go for it
<Fujitsu> Yes, that's not a bad idea, actually.
<tseng> yeah
<Fujitsu> That's a very very good idea.
<jdub> i think that's already on the plans
<jdub> for edgy+1
<Viper550> Maybe just setup a Openbox desktop with the Ubuntu wallpaper in it...
<ogra> why bother with a window manager and a wallpaper ? 
<ogra> just run the installer fullscreen
<LaserJock> yep
<jdub> ogra: because the installer opens windows, which need managing
<ogra> ah, right 
<ogra> ion
<ogra> :)
<jdub> metacity is small enough
<Fujitsu> ogra, I love ion, but it's not exactly suitable :P
<ogra> jdub, btw, will we see you in mountainview ?
<Fujitsu> jdub, if you remove Gnome from the equation, it is.
<Viper550> Hmm, what does Anaconda use for stuff like that?
<jdong> the casper live system itself uses a lot of RAM on low-ram systems
<tseng> Viper550: do you recall it opening any windows?
<jdong> I don't think even an openbox/fvwm would do it
<jdong> Viper550: suse's installer uses fvwm; I'm not sure what anaconda uses
<Viper550> Yeah, the "Please wait while the install begins, this may take several minutes" and some other screens like in partitioning
<ogra> anyway
* ogra is off to bed
<Fujitsu> Goodnight!
<Viper550> I mean like this: http://shots.osdir.com/slideshows/original.php?release=596&slide=9
<jdub> Fujitsu: that's what the proposal was
<jdub> ogra: not afaik
<ogra> jdub, sad :/
<jdong_> wow, uswsusp has a progress bar
<Seq> i've created my own package repository, and when building packages have the .dsc and .changes file signed (via debuild). I've also imported my public key with apt-key. Does anybody know how to get it to stop warning me about my packages being unverified?
<mdz> infinity: ping
<infinity> mdz: pong
<mdz> infinity: bug 62712
<Ubugtu> Malone bug 62712 in Ubuntu "Language support packages are marked as automatically installed" [Medium,Unconfirmed]  http://launchpad.net/bugs/62712
<infinity> mdz: That's because *-live aren't tasks currently.
<mdz> infinity: tasks don't exist for them at all?
<infinity> Nope.
<mdz> I think we have to live with this for beta then
<infinity> I'd have been more concerned about it, except that the first thing we do on a ubiquity install is to remove all the -live depedencies anyway.
<infinity> Though, we don't remove the langpack stuff (or re-add it in a suboptimal fashion), which would be leading to this.
<infinity> Pain.
<mdz> I don't suppose mvo added a "pretend all the dependencies are manually installed" flag...
<infinity> That would be awfully clever, but I don't think so.
<mdz> we could release beta with this bug, but if we can fix it in the livefs build, I think that's worth it
<mdz> any better idea than hardcoding the lists of *ubuntu-live deps?
<infinity> Well, there are a few ways to fix it, and all seem resonably trivial.  Could be fixed in apt (with a new flag), in the archive (adding tasks), or in ubiquity itself by reordering how it does some things.
<mdz> fixing it in apt is a 4-hour process
<mdz> once the fix is uploaded
<infinity> Fixing it for beta would mean me pulling the seed output and parsing it to manually install the lot.
<infinity> I already do that for the OpenCD builds, so the code exists.
<mdz> oh, interesting
<mdz> I'm also thinking of ways we could correct this with an update
<mdz> unfortunately the extended status doesn't say which package pulled it in, so it's tricky to say
<infinity> I can certainly do the ugly livefs.sh hack for now, and we can discuss with Kamion and mvo the "right" way to fix it later.
<infinity> Should be about 10 minutes of cut-n-waste and another 10-20 mins to test locally and make sure I didn't bugger it up.
<mdz> I don't think anything acts on the autoremove data as yet, so this arguably isn't a very big deal
<mdz> if we can fix it cleanly in an update
<infinity> Well, fixing it cleanly would mean magically marking all that stuff as manually installed later... Which sounds tricky.
<mdz> the marking is easy; it's the test for whether we should mark it which I'm unsure about
<mdz> the livefs approach seems worth a try
<mdz> btw, please disable the cron jobs if you haven't already
<infinity> They've been disabled for a couple of days, since Tollef requested it.
<mdz> ok
<mdz> the cdimage builds weren't for some reason
<infinity> They are now, I assume?
<mdz> I have disabled them now, yes
<infinity> Well, most of them.
<infinity> I assume you left ports and xubuntu enabled for a reason?
<mdz> had no reason to disable them
<mdz> I don't know if they're even succeeding, but they weren't in my way
<infinity> Fair enough.
<mdz> I haven't seen jani and have no idea if there will be a xubuntu beta
* infinity thinks harder about this bug.
<mdz> so I haven't been poking at it
<infinity> I think I must misunderstand how ubiquity works.
<crimsun> mdz: there are plans, yes
<infinity> I assumed it removed all of the *-live stuff, then installed langpacks.
<infinity> But obviously not, or this wouldn't happen.
<mdz> right, it filters the langpack stuff
<infinity> Ahh, pain.
<infinity> Makes more sense for speed, I guess, just exposes this.
<mdz> we could fix this by hacking up /var/lib/apt/extended_status at the end of the livefs build
<infinity> Okay, I'll hack livefs.sh to just install it all manually for now.
<mdz> fixing extended_status is arguably more correct
<mdz> since if they later remove the langpack, it'll DTRT
<mdz> it's pretty easy to parse
<infinity> Hrm, so just make language-support-en be marked manual, but leave the rest auto?
<mdz> a perl one-liner would do the job I expect
<mdz> support and pack
<mdz> let me try it in a live boot
<infinity> Well, if you drop support, you might want to auto-remove pack, no?
<mdz> infinity: they're both explicitly seeded, and selecting the installer language should make them both manual
<mdz> infinity: perl -i.old -nle '$dec=3 if /^Package: language-(pack|support)/; print unless $dec-- > 0;' /var/lib/apt/extended_states
<mdz> infinity: or the more correct perl -i.old -nle 'print unless /^Package: language-(pack|support)/ .. /^$/;' /var/lib/apt/extended_states
<mdz> should do the trick
<infinity> Kay, let me do a test build here.
<mdz> would be nice if "apt-get install <thing it thinks was autoinstalled>" would DTRT
<mdz> but it doesn't
<mdz> nor does --reinstall
<gnomefreak> these jobs for ubuntu, does that mean we are losing these people that do it now or they just dont want to do that project anylonger?
<infinity> gnomefreak: Some of it's increased workload, some is getting specialists on board to take over specific tasks from currently overworked people.
<gnomefreak> ah ok
<gnomefreak> i was like oh crap not ben and keybuk 
<mdz> gnomefreak: "growth" in a word
<gnomefreak> ty 
<gnomefreak> growth is a good word :)
<mdz> infinity: joy?
<infinity> mdz: Yup, tested okay, rolling it out nowish.
<mdz> infinity: ok, please build them all (well, the ones with langpacks) once it's ready
<infinity> Will do.
<nictuku> gnomefreak, so are you applying too?
<gnomefreak> nictuku: i was gonna apply to one of them but i cant move to canada
<nictuku> why not? www.canadianalternative.com
<gnomefreak> nictuku: my son and is mother
<infinity> mdz: I'll just statr pumping out ISOs as the livefs images become available.
<infinity> start, too.
<mdz> infinity: thanks
<infinity> mdz: ubuntu/desktop 20060928.2 is ready, if you want to test the hack.
<mdz> I will
<mdz> hmm, my rsync is stalling
<Hobbsee> yours too? pitti and ogra were complaining about similar things last night
<mdz> worked the second time
<infinity> I wonder if I should donate out-of-pocket to get faster disks on king and royal.
<infinity> I suppose I could file an RT request with my credit card details and see how that goes. :)
<Fujitsu> mdz, may I recommend some/more context in future emails such as the `Beta release status' one to -devel? It's very out of place.
<infinity> kubuntu/desktop 20060928.1 built and mirrored
<mdz> Fujitsu: pardon?
<mdz> it doesn't get much more on-topic than that
<LaserJock> mdz: I was confused as to what you were really saying
<Fujitsu> mdz, not off-topic...
<mdz> it was primarily a brief note to the release team letting them know what happened while they were asleep
<LaserJock> sure, I know
<mdz> but I figured it might be of interest to the development team in general as well, so sent to -devel
<mdz> in crunches like this, I'm not likely to have time to write a detailed progress report, and the situation changes quickly anyway.  however, it's important to keep the development team informed
<mdz> what do you think could be done differently to improve it?
<Fujitsu> I don't know, but it looks very much like it was indeed addressed to just the release team, and is going to confuse people who don't know everything about the current status.
<Fujitsu> I don't know how it could have been improved, though...
<crimsun> it seems a few initial impressions were "huh? Is the beta still scheduled for release [today] ?"
<minghua> mdz: I think saying that it's mainly for the release team, but others on -devel may be interested would be good
<minghua> that way if I don't understand, I know it's not mainly intended to me
<Fujitsu> minghua, yes, as it's obviously very directed to the release team. It's just going to confuse everybody else if they think they should be able to understand it.
<minghua> mdz: but I sure appreciate the update, it's definitely better than nothing
<mdz> Fujitsu: appearances aside, it really is a developer-oriented list and we should be able to have this type of conversation on it
<mdz> I'll try to remember to add a one-liner at the top if I do it again
<Fujitsu> mdz, that'd be good.
<mdz> [warning! actual development content inside, please open carefully]  ;-)
<Fujitsu> It may be a development-oriented list, but a whole lot of people on it aren't developers, and a lot of the discussion isn't as developer oriented...
<Fujitsu> Haha, exactly
<ajmitch> Fujitsu: that's more a problem with how the list has drifted off topic lately
<Fujitsu> ajmitch, of course.
<infinity> I'd like to think that people reading a devel list will apply "If I don't understand it, it's not for me" to each message, as a general rule.
<infinity> I certainly don't understand (or care to understand) half of what I read on lkml, for instance.
<ajmitch> and I appreciated having the release update on -devel
<Burgundavia> mdz: does LP allow anybody to target a spec at Edgy?
<mdz> Burgundavia: I believe it allows anyone to propose a spec for edgy, but only privileged users can approve it
<Burgundavia> https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10 <-- the spec list here looks really odd
<Burgundavia> oh, and deferred should remove a spec from the targetting
<mdz> Burgundavia: oh, a milestone, not a release
<mdz> I have no idea, maybe
<mdz> that might not require any special privileges
<Burgundavia> that is a bit of an issue, because being on that list implies it is being included
<fabbione> morning guys
<mdz> infinity: workaround confirmed in the current build
<fabbione> how are we doing?
<mdz> fabbione: I sent an update to -devel (of all places! ;-) )
<infinity> mdz: Excellent.
<fabbione> mdz: reading.. thanks
* fabbione sips some coffee
<infinity> mdz: edubuntu is almost there.  Do we care about xubuntu for beta?  (I'm building it anyway, out of the kindness of my heart, but if it's not urgent, I can go grab some lunch and pay my rent before I spin the xubuntu ISOs)
<mdz> infinity: crimsun seemed to be in the loop on xubuntu, I know nothing
<infinity> crimsun: ?
<crimsun> infinity: it's not urgent but would be greatly appreciated
<mdz> infinity: I don't think anyone is present who is actively working on xubuntu beta, so I don't think there's any hurry
<infinity> crimsun: Okay, I'll spin the xubuntu ISOs when I get back from lunch/rent, then, since paying rent before my real estate agent closes is somewhat time-sensitive. :/
<crimsun> infinity: many thanks!
<mdz> infinity: the edubuntu desktop build will be 20060928.1?
* infinity twiddles his thumbs, waiting for lithium to finish with edubuntu.
<infinity> mdz: Should be, yeah.
<mdz> infinity: and you're only building desktop/live, right?
<infinity> mdz: Right.
<mdz> I'm posting a list of candidate build numbers 
<fabbione> hmmm
<fabbione> 62712 might affect netinstalls too
<fabbione> mdz: what was the workaround you used?
<infinity> Won't affect netinstalls.
<infinity> Since netinstalls won't install ubuntu-live and then remove it.
<fabbione> ah right
<fabbione> ok
<infinity> mdz: edubuntu/desktop 20060928.1 published.
<infinity> And really, really, really big on powerpc.
<infinity> I can only assume that ogra's already aware of that, mind you, since he's got his finger on the pulse of all things CD-size-related.
<Burgundavia> mdz: https://launchpad.net/products/blueprint/+bug/62717
<Ubugtu> Malone bug 62717 in blueprint "Anybody can target specs at milestones" [Undecided,Unconfirmed]  
<mdz> edubuntu on powerpc is academic
<mdz> literally
<Amaranth> Yeah who has the money to spend on an Apple server?
<infinity> *rimshot*
<Amaranth> Or even an apple machine as a client, seeing how it's targeted at schools
<mdz> Amaranth: server and a bunch of thin clients, even
<LaserJock> I've seen a few ppc thin client questions in #edubuntu
<LaserJock> but ususally with x86 servers
<infinity> An beefy Xserve and a mess of old, used candy-coloured iMacs wouldn't be so bad.
<infinity> s/An/A/
<infinity> Anyhow, off to go pay my rent, since I'm not fond of eviction.  Back in an hour or two, public transit depending.
<solomakhin> is it safe to upgrade to edgy?
<Hobbsee> solomakhin: no.   it could all break.
<jdong> solomakhin: if you're asking that, the answer is probably no.
<solomakhin> Hobbsee: what breaks?
<solomakhin> jdong: ok
<Hobbsee> solomakhin: i'm not quite sure at the moment
<Hobbsee> but i agree with jdong 
<jdong> solomakhin: Almost everything works ok for me right now; a few gnome apps still are a tad unstable...
<solomakhin> alright, thanks guys
<jdong> solomakhin: but with a development release at anytime the situation can drastically change
<jdong> I wouldn't rule out data loss, corruption, etc
<Hobbsee> the world blowing up
<solomakhin> wow, pretty scary
<solomakhin> do you do this to all n00bs? ;)
<jdong> solomakhin: just an example, it was recently discovered that the knot3 live installer goes on formatting rampages
<jdong> solomakhin: there's been at least 2 people reporting complete data loss on their NTFS partitions
<Hobbsee> jdong: so did one of the kubuntu dapper ones.  :D
<jdong> so again, I wouldn't rule out something like that happening
<Hobbsee> jdong: i tried to convince Riddell that this was part of a bugfix for bug 1
* solomakhin 's jaw is dropping
<Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<jdong> hobbsee: hehe :)
<solomakhin> hahaha
<Hobbsee> solomakhin: no - but most of the time they dont come into -devel and ask - they ask in #ubuntu+1, and  usually ask "how do you  upgrade too"
<jdong> solomakhin: so, personally I'd recommend either setting aside a test _computer_ / vmware or wait till edgy's release :)
<Hobbsee> then get really shirty when you answer "if you have to ask that, you shouldnt upgrade to the development release" with "oh, i should be able to make that choice for myself" yada yada yada...
<jdong> hobbsee: ugh, we had a guy on the forums wanting to upgrade to edgy...
<Hobbsee> jdong: only one?  *g*
<jdong> hobbsee: after 22 replies, he was unable to edit his sources.list
* Hobbsee headdesks
<jdong> lol
<solomakhin> hahaha
<LaserJock> ouch
<Hobbsee> yes.  remind me why they stay on the forums, and why the bugtracker is slightly complex
<jdong> that's a pretty good sign you shouldn't use edgy :)
<jdong> hobbsee: we're like your noob filter :)
<Hobbsee> i think i'm going to start saying in edgy+1 "sure, it's fine to upgrade.  try it and see"  and then watch them go back to dapper when it all breaks, and tell their friends
<solomakhin> good job, ``team n00b filter!''
<Hobbsee> with a proper /topic of course, so that those observant people would notice that they shouldnt install it
<Hobbsee> er, then go back to edgy.  or dapper.
<Hobbsee> jdong: *grin*
<Hobbsee> solomakhin: it's safer than usual, due to the beta, but you're still likely to experience lots of breakage, so it's safer to wait
* Hobbsee looks forward to when her X works again.
<solomakhin> Hobbsee: thanks for advice
<Hobbsee> solomakhin: :)
<LaserJock> Hobbsee: your X isn't working?
<Hobbsee> LaserJock: indeed.  i'm still booted to 2.6.17-7-generic, as the later versions dont work
* Hobbsee looks for her bug report
<Hobbsee> https://launchpad.net/bugs/61979
<Ubugtu> Malone bug 61979 in xserver-xorg-video-i810 "[Regression]  2.6.17-8-generic makes X crash if DRI is enabled in xorg.conf" [Undecided,Unconfirmed]  
<jdong> hobbsee: have you tried starting x without kdm?
<jdong> kdm's a bit kooky with how it uses X... fglrx doesn't like it either
<Hobbsee> jdong: of course.  still dies.
<jdong> k
<Hobbsee> i'm not *that* shocking at debugging X crashes
* Hobbsee updates the report
<jdong> btw, not to be naggy/annoying/etc, but where are we on the road to beta iso's? :)
<Hobbsee> jdong: i think we're on the road to testing them, actually
<Hobbsee> ubuntu alternate was oversized
<jdong> are the 928.2 daily-lives the ones?
<Hobbsee> yeah, i would think so
* jdong queues some up for the night
* fabbione reboots
<fabbione> brb
<infinity> crimsun: xubuntu has new images up, and I've disabled the xubuntu cdimage cronjobs so they don't get regenerated out from under you.
<pitti> Good morning
<Hobbsee> hey pitti!
<mempf> hey guys
<infinity> Hey pitti.
<infinity> Someone should email me some food.
<Hobbsee> heh
<Hobbsee> i dont think it'd work very well
<pitti> hey Hobbsee, hello infinity, moin mempf 
<mempf> arrg
<mempf> cant get edgy installed on my pc
<mempf> i want to try that new nvidia driver
<mempf> why would the setup hang at: Retrieving file 819 of 819
<pitti> mempf: wait a bit
<pitti> mempf: look at VT3 or VT4 for what's going on
<mempf> il try that
<pitti> whoa, do today's desktop images really differ from yesterday's?
<pitti> sent 189602 bytes  received 108425 bytes speedup is 2459.11
<tfheen> pitti: not very much, but yeah, a bit
<pitti> tfheen: how does it look so far?
<pitti> I'll continue the powerpc testing now
<mempf> is the beta release soon/
<tfheen> pitti: I woke up 19 minutes ago, I've just skimmed my inbox. :-)
<pitti> tfheen: I'll bump the desktop CD date on T/Current and mark the results as obsolete
<infinity> pitti: mdz sent a list of candidates to -devel, if you need exact numbers.
* pitti would have used the latest available ones, but will check mail before
<infinity> Should be the same, I've not changed them since then. :)
<tfheen> pitti: thanks. :-)
<tfheen> infinity: the -server one isn't the latest, iirc
<infinity> Ahh, we didn't respin -server this morning, we were just doing desktop/live mangling.
<pitti> Riddell: I updated the CD timestamps for Kubuntu on T/Current, but did not obsolete the previous test results since I don't know which ones you tested already
<Hobbsee> pitti: i'm not sure if any official testing notice has gone out for kubuntu based cds yet
<fabbione> pitti: ping?
<geser> could someone please giveback pstngw? it failed to build because of chroot problems. thanks
<pitti> fabbione: pong
<fabbione> pitti: see /msg
<fabbione> i am having some locales issues
<fabbione> perhaps you know what's wrong
* pitti is pleased that the live CD check works great now
<tfheen> pitti: which one of them?  The desktop one or the alternate one?
<pitti> tfheen: desktop (sorry, 'live' is still in my fingers)
<pitti> the one I previously got no feedback for
<tfheen> pitti: oh, sorry, I can't read, you wrote live there.
<geser> infinity: hello. I'm trying to rebuild php4 but it fails to build as the build-deps need both libdb4.3-dev and libdb4.4-dev and both can't be installed at the same time. have you an idea how to resolve it?
<Kagou> morning
<bluefoxthing> well shit.
<bluefoxthing> wine freezes, then crashes X
<bluefoxthing> twice I tried, then I couldn't log in
<HrdwrBoB> er
<bluefoxthing> (gdm just hangs on log-in)
<HrdwrBoB> wrong channel
<bluefoxthing> on Edgy
<Fujitsu> bluefoxthing, so what? This is for development, not complaining about development releases?
<bluefoxthing> Fujitsu: is part of development recognizing potential problems?
<Fujitsu> bluefoxthing, no, that's the bug-tracker's job.
<pitti> arrrrgh
<Fujitsu> pitti, what's up?
<bluefoxthing> i'm waiting for that machine to reboot so I can figure out wtf is breaking it
<infinity> geser: It'll be fixed post-beta.
<pitti> removing ubuntu-desktop *still* kills 983248329 packages
<pitti> I thought mdz said that was fixed now
<Fujitsu> pitti, and I see that bug is marked fixed.
<bluefoxthing> meanwhile, can anyone else run wine without it crashing X?  (i.e. is this a video driver problem?)
<infinity> pitti: Erk.  It was meant to be fixed in the most recent images.  I blame mvo.
<bluefoxthing> (mplayer was doing this to X a while ago too)
<pitti> infinity: I just did 'sudo apt-get remove --auto-remove ubuntu-desktop -s' and it killed everything
<pitti> infinity: ^ in the ppc live session
<infinity> pitti: *sigh*.. Not good.
<infinity> pitti: What version of apt is on that livefs?
<pitti> infinity: 0.6.45ubuntu13
<infinity> pitti: It was meant to be fixed with 0.6.45ubuntu14 ...
<bluefoxicy> system functionality restored, damn.  Now how do I figure out why it's breaking
<infinity> pitti: Err.  D'oh.  I thought 0.6.45ubuntu14 got into the latest images.  Feh.
<pitti> new images?
<infinity> Oh, yeah, it is in the latest..
<infinity> 20060928.2
<bluefoxicy> oh screw it I'll just file a bug and let somebody else figure it out
<infinity> pitti: 20060928.2 has the right apt version, I'm not sure what you're testing..
<pitti> infinity: ugh, seems that this morning's rsync picked the wrong one, sorry
<tfheen> i386 seems good wrt auto-remove.
<crimsun> infinity: thanks!
<sivang> morning
<bluefoxicy> *slight anger*
<bluefoxicy> my hard disk is cranking, nothing intensive is running
<Fujitsu> *slight anger*
<Fujitsu> You're ranting in a development channel, not advisable.
<Fujitsu> Thankyou for uploading those tor fixes, pitti.
<pitti> Fujitsu: oh, the thanks is your's for preparing them :)
<Fujitsu> It didn't take very long :)
<Kagou> shawarma: i open 2 bugs for rastudio Bug #62734 and  Bug #62733 
<Ubugtu> Malone bug 62734 in rawstudio "Close Button don't work in About dialog" [Undecided,Confirmed]  http://launchpad.net/bugs/62734
<Ubugtu> Malone bug 62733 in rawstudio "Can't open a file" [High,Confirmed]  http://launchpad.net/bugs/62733
<Kagou> s/rastudio/rawstudio 0.4.1 released today (one is High)
<ogra> infinity, ?
<ogra> infinity, what did you do to the ppc cds ? 
<poningru> how much longer till beta is released?
<poningru> tommorow
<poningru> err today I guess in some places
<ogra> infinity, they were ~672M for the last *weeks* and i didnt change anything ... there must be something gone wrong
<ogra> mdz, ^^^
<ogra> infinity, the edgy-live-powerpc.list of edubuntu 20060927 and  20060928.1 are identical, there must be something *very* wrong with the builds if there are 70MB difference
<raphink> hmmm
<raphink> hi
<raphink> is it normal that nothing seems to be approved in the NEW queue for 9 days?
<raphink> when universe freeze is tonight :s
<Fujitsu> raphink, this is what happens when the archive admins get busy with other stuff.
<Fujitsu> :(
<raphink> well we're overtaking a lib transition
<raphink> I uploaded the new lib 3 days ago, hoping to have the time to upload the new apps building on it in time
<raphink> but it has been stuck since
<raphink> :(
<pitti> mvo: does the amd64/desktop boot for you? it's totally busted for me
<pitti> mvo: it just sits around with a black screen forever
<mvo> pitti: it did yesterday, let me recheck
<pitti> and since we did a very thorough job ob eliminating all possibilities of debugging, I can't say what's wrong
<mvo> the nvidia problem maybe?
<tfheen> pitti: not even the first boot menu?
<ogra> hmm, seems infinity is asleep ... 
<ogra> after making my ppc live CD explode ... :/
<tfheen> pitti: -desktop seems to boot correctly for me on amd64 (vmware) at least.
<ogra> tfheen, do you have any idea what can cause a 70MB oversizedness between two builds with identical .list files ? i have no clue where to start searching here 
<tfheen> ogra: that sounds.. special.
<ogra> yes
<tfheen> ogra: -live?
<ogra> they have been ~670M for the last weeks
<pitti> tfheen: I get gfxboot
<ogra> and suddenly i get >740M
<ogra> yes, ppc only
<pitti> tfheen: if you have nvidia, maybe you can try a real boot?
<infinity> ogra: I didn't "do" anything to them.
<pitti> tfheen: I don't see anything since uslpash does not work and upstart is absolutely quiet
<mvo> ogra: the list of files is identical you say?
<ogra> mvo, yes
<tfheen> pitti: remove "quiet" from the boot options?
<ogra> infinity, but there must have something changed :)
<tfheen> ogra: rsync is on crack
<mvo> ogra: my suspicion was the new install-task method abecause of bug #62696
<Ubugtu> Malone bug 62696 in soyuz "Task headers in Packages files do not match seeds exactly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62696
<ogra> ah !
<ogra> phew
<pitti> tfheen: ah, in the expert menu, right
* pitti tries that
<tfheen> ogra: hmm, no, actually not.
<ogra> no, the size on lithium is the same
<infinity> Err, the manifests aren't even close to identical.
<dholbach> good morning
<pitti> hey dholbach 
<mvo> dholbach!
<mvo> dholbach!
<dholbach> hey pitti, hey mvo, hey heno!
<tfheen> hi Henrik
<mvo> pitti: blank screen for me too :/ with nvidia 
<pitti> mvo: alternate install still has the desktop removal problem
<mvo> hi heno
<heno> hi all!
<pitti> mvo: does it start anyway?
<dholbach> hi tfheen, infinity, ogra :)
<pitti> mvo: I'm used to the black screen, we have that usplash bug for months, but so far it at least started fine
<mvo> pitti: it is still starting, but I see progress
<pitti> ok, may be hw specific then
<infinity> ogra: gcompris* and tuxpaint* look like good candidates for the extra usage, though other stuff has changed too.
<ogra> infinity, argh, how did all the excluded packages end up there 
<pitti> mvo: do you still know the desktop removal bug number? I need to reopen it for alternate installs
<ogra> yes, i'm just diffing the manifest 
<infinity> mvo: And yes, I suspect ogra's issue is due to the task/metapackage mismatch bug.
<ogra> neither was included on ppc since dapper
<mvo> pitti: #61684
<BringZten> hello
<BringZten> I love fucking ubuntu
<BringZten> I'm concerned about the state of linux
<Hobbsee> BringZten: why are you here?
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<BringZten> Vista is amazing and I hate microsoft
<infinity> ogra: Anyhow, mdz's already stated that he's perfectly happy to ignore edubuntu/powerpc for beta, so it's not the end of the world, as long as we get the archive bug fixed soon.
<Hobbsee> and how were you allowed back in?
<mvo> infinity: I guess its missing support in germinate? the extraoverrides support arch-dependant tags
<ogra> infinity, i'm not yet sure my amd64 install CDs are ok ...
<mvo> pitti: amd64/desktop is up
<ogra> the only thing thats really shiny is i386 ... 
<mvo> pitti: the auto-install problem is fixed on live at least :)
<ogra> infinity, my users will complain a lot ... if i can avoid that that would be nice :)
<infinity> mvo: Well, germinate obviously works right for the metapackages. :)  It's the germinate->archive glue that's obviously lacking smarts, though.
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<infinity> ogra: I doubt we'll fix the archive today.
<infinity> I can look into it, though.
<ogra> right, if its the archive i cant do much
<mvo> infinity: eh, that was what I meant. the soyuz guys told me that the generation of the overrides was part of germinate 
* ogra does another ppc install 
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Hobbsee> BringZten: *eyebrow raise*
<BringZten> Hi
<Hobbsee> are you going to behave, or are you out to create trouble, yet again?
<BringZten> behave.
<Hobbsee> good.
<BringZten> I was serious but this isnt the right channel.
<BringZten> =)
<pitti> mvo: confirmed, works fine on live
<mvo> pitti: so its the way the install installs stuff on the disk :/
<pitti> mvo: yes
<mvo> pitti: I added a comment
<pitti> ok, re-trying to boot this amd64 desktop with some expert options, bbl
<tfheen> so, do we need new alternates due to the apt bug?
<mvo> tfheen: it seems more like a problem the way the installer works right now
<ogra> tfheen, could you wait a while until i tested amd64 ... i have a weird report for it ... and my isos finished only this morning to rsync
<ogra> so if there is a chance for rebuilds i'd like to have some fix in if possible ...
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<tfheen> ogra: 'k
<ogra> i just have to finish the ppc install here to be able to get on IRC if the worls explodes ... 
<pitti> indeed, without 'splash quiet' the amd64/desktop boots for me
<ogra> ok, at least my ltsp bug on ppc install is fixed ....
<pitti> mvo: ugh, no more German translations on the desktop CD :/
<mvo> pitti: yeah, I noticed that too :/
<ogra> pitti, that should only affect the panel 
<pitti> ogra: how do you mean?
<ogra> i never had germany transaltions on edubuntu 
<ogra> but the menu entries etc are usually in german ...
<ogra> its only parts that are missing their translations (usually)
<pitti> mvo: hm, I got U.S. keyboard although I selected German; can you confirm this?
<mvo> pitti: yes
<pitti> mvo: I usually choose U.S. keyboard anyway, but for the sake of testing I had German keyboard this time
<mvo> pitti: and the installer defaults to US keyboard even if you select german as language
<ogra> phew ... ppc install looks fine ... (yet)
<pips1> testing german keyboard is much appreciated :)
<ogra> pips1, arent you a de_CH type  ? 
<pips1> yeah, but even de testing is good in my book :)
<ogra> :)
<pitti> mvo: did you already file bugs about that or shall I?
<mvo> pitti: I haven't yet, I just wanted to confirm this again first (I have seen it last night when I was *very* tired)
<mvo> pitti: but now amd64/live is not booting
<mvo> oh well
<ogra> pips1, did your amd64 get over the base install and did you get that "invalid release file" error in ltsp or even before ? 
<pitti> mvo: bug 62738?
<Ubugtu> Malone bug 62738 in Ubuntu "amd64 desktop does not start" [High,Unconfirmed]  http://launchpad.net/bugs/62738
<pitti> mvo: anyway, when I noticed the keyboard thingy, I was already in ubiquity's keyboard chooser, so it was too late
<mvo> pitti: right, I will report it when I can reproduce it again
<pips1> ogra: erm, how can I tell?
<ogra> well, did it break in "installing ltsp chroot" ?
<pips1> I got it when it was trying to build ltsp chroot
<ogra> or even before
<ogra> ok
<pips1> "half way" through
<ogra> nope... thats only the progressbar
<pips1> righty
<ogra> its lying
<pips1> :)
<ogra> that error you describe must be at the very beginning ... i just wonder why the release file might be considered broken (the "installing base system" step does exactly the same)
<pips1> hmm
<ogra> i'll test soon ... ppc is nearly done ...
<mvo> pitti: bug #62743
<Ubugtu> Malone bug 62743 in Ubuntu "US keyboard on the livecd when selecting german in the boot-menu" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62743
<seb128> tfheen: hum, mono is still broken on the desktop CD :/
<seb128> and I still get a qwerty layout when I pick french
<mvo> seb128: qwerty is probably #62743 too
<ogra> seb128, see mvo's bug :)
* mvo hugs ogra
* ogra hugs mvo
<pitti> mvo: ah, so I wasn't hallucinating (I confirmed the bug)
* mvo hugs pitti
* pitti hugs mvo
<pitti> ok, amd64/ubiquity install finished, let's look into it :)
<ogra> woah, that 640x480 usplash picture looks so bad ...
<ogra> but edubuntu ppc install works :)
<fabbione> bah...
<Kamion> morning
<fabbione> ogra: can you try switching from X to console on ppc?
<mvo> good morning Kamion
<ogra> fabbione, will do ...
<fabbione> morning Kamion
<Kamion> mvo: it's not really part of germinate as such - it's a wrapper script built on top
<ogra> waaahhh ... the sounds is way to loud
<fabbione> X crashes badly here
<fabbione> full machine hangs
<ogra> dont we set it to 80% anymore ?
<ogra> fabbione, works for me ... on the ibook
<fabbione> meh
<mvo> Kamion: in what repository is it? do I need to talk to cprov about it?
<infinity> Kamion: How many minutes/hours of hack time would it take you to make the wrapper generate arch-dependant overrides?
* fabbione curses ati
<Kamion> mvo: it's part of launchhpad
<Kamion> launchpad
<Kamion> infinity: not sure, will investigate
<Kamion> is it beta-urgent?
<infinity> Only if ogra wants ppc/desktop CDs.  Otherwise, not really.
<infinity> But if it's a 5-minute hack, may as well.
<infinity> If not, then it can wait.
<elmo> if you're talking about the tasks, you'd have to change how launchpad writes it's apt.conf for apt-ftparchive
<elmo> and do per architecture sections
<Kamion> yeah, I thought it might be something like that ...
<infinity> Oh, feh.
<elmo> (which doesn't sound 5-minute to me...)
<infinity> I thought it was just cron.germinate to blame here.
<infinity> Yeah, the apt.conf mangling in the publisher is less obvious.
<Kamion> do you happen to know how the file needs to change?
<elmo> infinity: no - both dak and soyuz use one section per distro-release/suite, that covers all architectures -> on extra override file for all arches
<Kamion> I don't know that bit of apt-ftparchive
<ogra> infinity, since the install cd for ppc is ine i can live with broken live ones
<ogra> *fine
<elmo> only way to have per-architecture extra override files without hacking apt-ftparchive would be to write different 'tree' sections for each distro-release+architecture
<Kamion> I thought apt-ftparchive already got hacked to support per-arch fields
<elmo> btw, this is hand-waving speculation based on what I'd do in/for dak if we were still using it.  I am not team soyuz and I do not speak for them
<mvo> elmo: can't we use the pkg/arch syntax? or is the apt-ftparchive too old for this?
<Kamion> of course drescher is still using *hoary*'s apt-ftparchive
<elmo> Kamion: in extra overrides? news to me, and we're still using hoary's apt-ftparchive
<Kamion> can we please upgrade that at some point?
<mvo> yeah apt-ftparchive has it, but not in hoary :/
<infinity> Well, we want edgy's ideally anyway.
<Kamion>   * Support architecture-specific extra overrides
<Kamion>     (closes: #225947). Thanks to  Anthony Towns for idea and
<Kamion>     the patch, thanks to Colin Watson for testing it.
<infinity> For a variety of reasons.
<Kamion> in 0.6.41
<elmo> Kamion: I've had that discussion to death - please feel free to convince them of that
<elmo> they seem more interested in rewriting apt-ftparchive
<elmo> but i would say upgrading from hoary to later is not something you'd want to do before-preview
<mvo> the new version would be much faster as well ..
<infinity> elmo: No, doing it right after beta would be nice though.
<fabbione> also because hoary is close to EOL
<infinity> Kamion: Anyhow, ogra's said he can live with his breakage, so looking at this immediately post-beta would be nice to put on our TODO.
<infinity> Kamion: And edgy's apt would be the ideal one to backport, since mvo's given us some other archive-related fixes recently.
<Kamion> elmo: last I heard they were going to keep using apt-ftparchive for the distro for edgy, and trial the replacement on PPAs
<Kamion> so there's a worthwhile window
<mvo> infinity: when this gets started, please ping me so that I can double check again that we have everything etc
* ogra goes for amd64 testing
<elmo> Kamion: I'd certainly hope so - given the replacement will be generating Packages/Sources for the entire distro including d-u and d-s
<Kamion> indeed
* mvo grumbles because he can't find the no-partman-resize-progress bugnumber 
<Kamion> infinity: I can create *-live tasks fairly easily, but after beta
<infinity> Kamion: I'm unconvinced that *-live as tasks is the correct solution anyway.
<Kamion> why?
<infinity> Kamion: That bug magically goes away completely if I'm allowed to roll out stacked-livefs post-beta.
<Kamion> I thought we discussed that the other week
<Kamion> it would be nice to have *-live as tasks anyway because rolling new metapackages for late changes is time we don't need to waste
<infinity> Though it doesn't *hurt* to have *-live as tasks, I guess, it just feels like unnecessary cruft.
<Kamion> tasks are less cruft than metapackages, honestly
<infinity> Oh, fair point on the "screw metapackages" front.
<infinity> I forgot baout that conversation.
<Kamion> anyway, time to clear up universe syncs
<infinity> I'm losing it in my old age.
<carlos> Riddell: hi, did you imported already new kopete translations from upstream? Could I move it from kdenetwork to kopete in Rosetta?
<Fujitsu> Kamion, yay :)
<infinity> Kamion: Would you object to having -minimal as a task too, then, even if we never actually use it (cause we debootstrap it)?
<infinity> Kamion: I find it moderately handy to check Task headers in the Packages files sometimes.
<Kamion> infinity: I guess not
<ogra2> argh
<ogra2> amd64 is broken :(
<ogra2> creap
<ogra2> THANK YOU DEBIAN for disabling amd64 in ltsp !!!! 
<ogra2> gah, how did i merge that  
<pips1> ogra2: :/
<mvo> Kamion:  would it be possible to change the way packages are installed via the alternate installer? to fix #61684? post-beta, but we should put it into the known-issues section 
<pygi> morning all
<Kamion> mvo: yeah, should be
<Kamion> it'd just be a tasksel change
<mvo> cool, thanks!
<tfheen> seb128: mono> known, didn't make it for beta.
<pygi> sivang: ping?
<dholbach> what do I need to include in a bug report about ubiquity hanging in after the timezone configuration?
<Kamion> dholbach: /var/log/syslog
<seb128> dholbach: there is a g-s-t bug opened, time-admin crash when selecting a timezone if no timezone is set before
<seb128> dholbach: is your issue time-admin crashing?
<dholbach> I can't click 'next'
<dholbach> no, there was not crash message
<Kamion> dholbach: could you cancel ubiquity, and try again with 'sudo env UBIQUITY_DEBUG=1 ubiquity' please?
<dholbach> sure
<Kamion> then (a) there should be debconf debug output on stderr, which I'd like, and (b) /var/log/syslog should be more informative
<Kamion> I must arrange for the debconf debug output to go to syslog
<dholbach> urg, now it worked
<dholbach> i'll do all the installations with UBIQUITY_DEBUG=1 now
<mvo> I'm adding a "Known issues" to the EdgyEft/Beta page. I add mono, nvidia usplash-amd64, apt-auto-install/alternate. anything else?
<seb128> mvo: the keyboard layout thing?
<dholbach> seb128: already there
<dholbach> ah no
<mvo> seb128: right
<dholbach> different page
<ogra2> mvo:  no amd64 install CD for edubuntu
<Kamion> dholbach: might want to reboot and try again, same procedure
<ogra2> and no ppc live
<Kamion> except this time start with UBIQUITY_DEBUG=1
<dholbach> Kamion: right-p
<dholbach> right-o
<mvo> ogra2: do you have a bugnumber?
<ogra2> mvo: not yet ... let me get my grub back on my main machine ... 
<mvo> ok
<heno> Kamion: are the AT casper settings supposed to work now or is it still pending (in beta freeze perhaps)? I doesn't work in my tests
<heno> #58836
<\sh> I know this question is not suitable for this channel, but does anyone know someone who installed an oracle server 10g on dapper?
<Kamion> heno: the casper accessibility script is broken
<Kamion> I found that last night and SMSed it to tfheen
<heno> Kamion: ok, thanks
<heno> you SMSed the script? :)
<Kamion> let me make sure my fixes are committed
<heno> ok, cool
<Kamion> no, it was just an extra "fi" so describable in an SMS
<heno> right
<tfheen> Kamion: it's not set -e, so it doesn't matter, though
<Kamion> tfheen: sh bails out on the syntax error, I believe
<tfheen> Kamion: gnr, ok.
<tfheen> silly sh.
<tfheen> :-P
<Kamion> I'm going to make casper run 'sh -n' over everything on build
<tfheen> thanks
<ogra> mvo, bug #62750
<Ubugtu> Malone bug 62750 in ltsp "merge oversight, not possible to build amd64 chroots anymore" [Critical,Confirmed]  http://launchpad.net/bugs/62750
<dholbach> Kamion: still works - I'll let you know as soon as I dig something up
<Kamion> ok
<Kamion> argh
<Kamion> bzr: ERROR: Lock was broken while still open: LockDir(sftp://bazaar.launchpad.net/%7Eubuntu-core-dev/casper/trunk/.bzr/repository/lock) - check storage consistency!
<Kamion> tfheen: were you committing at the same time?
<tfheen> Kamion: I committed a minute ago, but bzr errored out:
<tfheen> bzr: ERROR: rmdir failed
<Kamion> we obviously clashe
<Kamion> d
<tfheen> try to run bzr update?
<Kamion> this is a known bzr bug; mdz and I ran into it with the seeds
<ogra> does that mean we'll get a rebuild ? 
<mvo> ogra: thanks, added
<Kamion> update works, but I bet the lock is still hanging around. I'll prod via sftp
<Kamion> ogra: does what mean that we'll get a rebuild?
<ogra> Kamion, what you guys are doing there 
<tfheen> ogra: at least my fix isn't beta-critical
<ogra> if so i'll try to fix the amd64 ltsp bug 
<ogra> ok
<ogra> then i'll go without amd64 for beta
<ogra> (i dont want to cause a rebuild, but if you do one anyway, please ping)
<seb128> Kamion: on what package should the "desktopCD set a qwerty keymap instead of the one corresponding to the locale picked" bugs be assigned?
<Kamion> seb128: ubiquity
<Kamion> seb128: same directions as for dholbach
<seb128> Kamion: but ubiquity is not running at that stage, is it?
<Kamion> oh, that
<seb128> Kamion: the issue is on the desktopCD environment
<Kamion> seb128: gfxboot-theme-ubuntu then, please; describe exactly what you did at the boot prompt
<tfheen> possibly casper too
<Riddell> Kamion: trying a netboot I end up with a dapper install, is that likely to be a bug or me having done something stupid?
<tfheen> seb128: please include /proc/cmdline too
<seb128> I pressed F2 and picked french
<Kamion> describe it in the bug, not here :)
<seb128> german guys (mvo, pitti,) have the same issue
<seb128> k ;)
<Kamion> Riddell: where did you get the netboot image from?
<dholbach> ok, Kamion: got the bug again: http://daniel.holba.ch/temp/ubiquity-debug.log  - especially the last line is weird
<Riddell> Kamion: http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images/netboot/
<dholbach> Kamion: any of your ubiquity bug tags you'd like me to use?
<Kamion> Riddell: sounds like a bug - I'd like /var/log/installer/cdebconf/questions.dat
<Kamion> dholbach: er, WTF
<Kamion> I have no idea where that message comes from; do you have any idea?
<Kamion> dholbach: no, none of the tags are suitable
<Kamion> mark it high importance though please
<dholbach> ok
<dholbach> anything I could try to debug?
<Kamion> you could grep your system for bits of that message, I guess ...
<dholbach> ok
<Kamion> or see what processes are running?
<Kamion> also /var/log/syslog would still be helpful
<dholbach> ok, i'll attach that too
<Kamion> thanks
<seb128> Kamion, tfheen: bug #61050
<Ubugtu> Malone bug 61050 in gfxboot-theme-ubuntu "[Edgy]  Knot-3 Live CD sets up keyboard in English instead of Spanish" [Undecided,Confirmed]  http://launchpad.net/bugs/61050
<seb128> updating title too now :p
<dholbach> Kamion: bug 62752 - grep is still running
<Ubugtu> Malone bug 62752 in ubiquity "timezone selection in ubiquity hangs, when just proceeding and clicking next" [High,Unconfirmed]  http://launchpad.net/bugs/62752
<ogra2> eeek ... who translates "install commandline system" to "einen server installieren"
<ogra2> +thats evil
<Kamion> ogra2: I fuzzied that translation when I renamed server to command-line
<Kamion> ogra2: did you actually see it on the boot menu?
<ogra2> yes
<ogra2> right now 
<Kamion> ogra2: please file a gfxboot-theme-ubuntu bug saying that it isn't properly ignoring fuzzy translations, then
<ogra2> the english version is fine ...
<ogra2> willdo
<Kamion> it obviously wasn't deliberately translated that way
<dholbach> Keybuk: do you have any idea, why this could happen on edgy amd64:  http://daniel.holba.ch/temp/edgy-20060927-1.png ?
<dholbach> Kamion: that's something in dbus
<Kamion> what the hell's using dbus anyway
<dholbach> Kamion: dbus-daemon, lidbus-1.so seem to contain that string
<Kamion> gnome-screensaver-command is the only candidate I can think of
<dholbach> how does the timezone-map-thingie work? which piece of code are you re-using there?
<seb128> gnome-system-tools uses dbus too
<Kamion> from evolution via g-s-t
<Kamion> but it doesn't use dbus
<seb128> g-s-t communicates to the backend over dbus
<Kamion> seb128: ubiquity doesn't invoke g-s-t unless you press the "Set Time" button
<seb128> s/to/with
<seb128> ok
<Kamion> the map widget is just gtk drawing code
<dholbach> I added that bit of information to the bug report too, in any case
* dholbach tries another installation
<Keybuk> dholbach: isn't that the nvidia bug?
<Kamion> ubiquity calls gnome-screensaver-command --poke every 30 seconds to stop the screensaver kicking in
<dholbach> Keybuk: oh, does that happen with the 'nv' driver too?
<dholbach> Keybuk: this amd64 box does has an nvidia card
<Keybuk> I don't know, mjg59 would know more
<Keybuk> I think it's a card bug
<dholbach> aha?
<dholbach> it used to work before ;-)
<Keybuk> svgalib not friends, or something
<dholbach> ah right
<dholbach> ok - thanks
<dholbach> Kamion: do we have a bug about choosing to partition  /dev/sdb  manually, then gparted showing  /dev/sda ?
<guyo> Hi all. Should I file a bug with ubuntu to request support for "E_CONTACT_PHONE_HOME_2" and "E_CONTACT_PHONE_BUSINESS_2" in contact-lookup-applet ? if this is not a case, what should i do ? I have a (laughably simple) patch for it already
<dholbach> guyo: could you file a bug with the patch at  http://launchpad.net/distros/ubuntu/+source/contact-lookup-applet/+filebug  ?
<guyo> dholbach: sure, i didn't know if i had to file a "bug" since it was more an enhancement and there were no switches in launchpad to specify what kind of "bug" it was
<dholbach> guyo: bugs with patches are fine
<guyo> dholbach: thanks, will do
<dholbach> guyo: thanks a lot
<Kamion> dholbach: yes, there's a bug about gparted not managing to deal with more than one hard disk at the moment
<Kamion> I can't look at it until I have my vmware setup available again
<dholbach> Kamion: ok, I'll try to find it and follow up on it and attach my ubiquity log
<seb128> tfheen, Kamion: I just uploadaed a new gnome-utils package revisions with a Build-Depends on liblaunchpad-integration-dev, fixing the build issue it has. The previous version which didn't build fixed some patches (lpi, menu changes) dropped and make the "Applications,System Tools" category not been listed by default again
<seb128> dunno if the menu cleanup matters for beta, probably not
<dholbach> and I have a edgy-wallpapery upload pending fixing the "artwork preview" text not to be under the panel - if that is deemed important enough (visible it is :-)), I'd prepare and upload that one too
<mvo> could someone let me know if we rebuild alternate again? I have a trivial patch pending for the cdromupgrade script then
<ogra> i just uploaded a fixed ltsp version ... if we could rebuild that would be cool (at least edubuntu amd64)
<mvo> ogra: if that is fixed, please update https://wiki.ubuntu.com/EdgyEft/Beta (KnownIssues)
<ogra> mvo, well, the beta CD will still be broken ...
<pitti> seb128: ping?
<seb128> pitti: pong
<pitti> seb128: on the powerpc desktop, gnome-settings-daemon consistently fails to start
<pitti> seb128: do you have some hints how to debug that?
<seb128> pitti: is your clock correctly set?
<ogra> mvo, so unless we'll have an alternate rebuild its still true
<tfheen> pitti: can you start i manually?
<seb128> pitti: one frequent cause is 'year is 1904' or something like that
<pitti> seb128: ah, heh, right
<ogra> yes, thats typical
<pitti> seb128: no, date is correct
<seb128> :/
<seb128> pitti: can you try running it from a command line ?
<pitti> (bah, something is DoSing my hard disk, gimme a minute)
<Fujitsu> Thanks Kamion.
<pitti> seb128: yep, I started it, now I get the ubuntu theme instead of the blue one
<seb128> bah
<seb128> so it fails from the session but starts correctly by hand :/
<seb128> anything useful to ~/.xsession-errors?
<pitti> seb128: this does not happen on the ubiquity-installed system either
<dholbach> Kamion: found it: bug 61350
<Ubugtu> Malone bug 61350 in ubiquity "[edgy knot 3]  Manual Partitioning does not allow editing of second drive" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61350
<dholbach> i'll follow up there
<seb128> pitti: that happens on desktopCD boot every time?
<Kamion> dholbach: please look at gparted
<tfheen> pitti: if you get the "could not start" dialog, it's probably dbus activation timeout being too low.
<pitti> seb128: only on powerpc
<tfheen> pitti: I've seen that before, but on amd64.
<pitti> yeah, sounds like a race condition
<pitti> since on the installed system it works
<Kamion> because I'll be marking that ubiquity bug as a duplicate when I get round to it
<pitti> but the CD is slow ion my laptop
<seb128> mdz got a similar issue once
<ogra> seb128, i heard about it on ltsp, but didnt see it myself yet 
<seb128> but with no data and no way to reproduce it that's no fun to debug
<dholbach> Kamion: right - I'll look for upstream patches that might fix that
<ogra> i think sbalneav told me about it, i'll try to get him reproducing it
<tfheen> seb128: it's because we're using dbus activation and the timeout by default is 15s or something.
<pitti> seb128: hm, nothing helpful in .xsession-errors
<tfheen> seb128: I've talked with you about it before. :-P
<seb128> tfheen: right ;)
<pitti> ok
<seb128> workaround: extend the 15s
<pitti> seb128: shall I file a bug?
<seb128> pitti: on dbus? ;)
<pitti> it's not a big deal, live goes on without it
<pitti> seb128: well, if the timeout is in dbus, sure
<seb128> pitti: I'm not sure that's a gnome-settings-daemon issue, it depends on dbus working
<Kamion> dholbach: don't bother, I think it's edgy-specific
<Kamion> dholbach: I'm happy to deal with it, just next week
<tfheen> dbus should really have a longer timeout.
<Kamion> dholbach: somebody already went upstream
<pitti> tfheen: ok, I'll file a dbus bug then
<dholbach> Kamion: Ok - I'll try some more installations then and plug out the other disk. :)
<pitti> seb128: I filed bug 62736, I'll look into it after beta
<Ubugtu> Malone bug 62736 in gnome-volume-manager "Volume Manager unresponsive in Gnome and command line" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62736
<ogra> could someone approve my ltsp upload so that in the unlikely case of an alternate rebuild the binaries are there ?
<pitti> bug 62763 even
<Ubugtu> Malone bug 62763 in dbus "dbus activation timeout too short" [Low,In progress]  http://launchpad.net/bugs/62763
<seb128> pitti: ok, thank you
<infinity> tfheen: You're fine with ogra's ltsp upload?
<infinity> mvo: Is your dist-upgrade upload beta-critical?
<tfheen> ogra: do you have your ltsp diff somewhere?
<ogra> err, tfheen wait a sec ... bzr disagrees with debdiff ...
<mvo> infinity: no, but *if* alternate would be rebuild again it would be a trivial fix that should be in too
<infinity> tfheen: Same for mvo's dist-upgrader, then.
<tfheen> I'm really, really, really hoping we won't rebuild at this point.
<infinity> So am I, but I can push this stuff through quickly, "just in case".
<ogra> tfheen, but *if* it would be nice to have the fixes there :)
<infinity> If that's wanted.
* infinity shrugs.
<ogra> infinity, not for me yet, i need to find out why bzr export didnt export the full patch
<mvo> tfheen: http://people.ubuntu.com/~mvo/tmp/dist-upgrader-20060928.1238.diff <- the diff
<lastnode> infinity, i keep pinging you on the weekend. is it still the weekend over there? ;-)
<infinity> lastnode: Doesn't appear to be.
<lastnode> infinity, got a second? you may not recall but we spoke a little about a project when i first came in here a few months back
<tfheen> mvo: there's no changelog.  What does it fix?
<infinity> lastnode: I have a vague recollection of discussing something or other with you.
<lastnode> infinity, is now a good time? i can always ping you later.
<infinity> lastnode: After beta is out would be better.
<lastnode> sure infinity, cheers
<mvo> tfheen: it fixes the cdromupgrade script. it assumes it gets a absolute path later but mktemp -d bla gives a relative one
<pygi> hello, could somebody please kick libburn 0.2.2-0ubuntu2 from NEW for me, thank you :)
<ogra> ah, silly me ... i have a wrong package around i debdiff against ...
<infinity> pygi: Why is libburn-doc arch:any instead of arch:all?
<pygi> infinity: dunno, I haven't packaged it
<tfheen> mvo: what happens if we don't include it?
<ogra> tfheen, http://people.ubuntu.com/~ogra/ltsp-debdiff.txt
<slomo_> pitti: regarding bug #62763... might this be the bug that seb128 told me about yesterday that's fixable with libxt-dev as dbus build-dependency or the correct fix i have locally (i.e. regenerating the autotools patch with a non-broken autoconf)?
<Ubugtu> Malone bug 62763 in dbus "dbus activation timeout too short" [Low,In progress]  http://launchpad.net/bugs/62763
<infinity> pygi: Care to prod ivoks about it?
<pygi> infinity: uh, then it would take a lot of time, he isn't online much
<infinity> pygi: Or fix it.  Your choice.
<pygi> infinity: ok, I'll fix it
<ajmitch> better chance of getting brasero done that way :)
<pygi> ajmitch: indeed, we don't have much time
<infinity> pygi: Other curious oddities about the package: libisofs and libburn don't have an SOVER in the package name.  That's a bit wrong.
<slomo_> ajmitch: brasero is in NEW currently btw... but the non-libburn version ;)
<infinity> pygi: Oh, wait, that was an old version.  The current one does.
<ajmitch> slomo_: right, I didn't know it was done, I can move onto more important stuff then
<pygi> slomo_: I don't want non-libburn version :)
<dholbach> one of my power cables just died
<infinity> pygi: So, yeah, my only complaint is the doc package.
<dholbach> how weird is that
* dholbach shakes head in disbelief
* dholbach does another install
<infinity> pygi: When you change it to arch:all, make sure the package still builds properly with "dpkg-buildpackage -B" and "dpkg-buildpackage -b"
<ogra> dholbach, get a cable with cooling ;)
<slomo_> pygi, ajmitch: was a "sync" from pkg-gnome svn... but it's the non-libburn version because the one with libburn support is called "unstable development version" or something similar ;)
<ajmitch> slomo_: figures
<pygi> slomo_: it's stable :P
<dholbach> ogra: right - I'll set that on my list next to the new dvd drive
<ogra> dholbach, but avoid water cooled ones ;)
<ajmitch> slomo_: how confusing, your last changelog said sync with pkg-mono svn ;)
<dholbach> ogra: I hope I learnt the lesson about water and computers
<dholbach> and a broken harddisk... nice
<dholbach> this feels like hardware spring cleanup
<ogra> phew .. you had a lot of trouble recently
<slomo_> ajmitch: oops :)
<pygi> slomo_: so even if I package libburn version we cant get it in?
<ogra> infinity, disregard my mumbling about the ltsp package ... what i uploaded is fine ... the local old package i had here was wrong ...
<tfheen> ogra: I'm fine with approving it, but I don't want to rebuild for beta..
<ogra> tfheen, ok 
<tfheen> ogra: so it's kinda irrelevant
<infinity> I'll aprove it and push it through, on a "just in case" basis.
<infinity> Deal?
<ogra> deal :)
<infinity> (But I doubt we'll find any showstoppers at this point)
<tfheen> infinity: please do.
<infinity> tfheen: Same with mvo's dist-upgrader?
<tfheen> infinity: I'm still waiting for an answer to what's broken if it's not approved, so not yet.
<infinity> mvo: ?
<slomo_> dholbach: when exactly does universe freeze start? now, 23:59 or when? :)
<dholbach> slomo_: I doubt it's me deciding that - bug 23:59 UTC would make everybody happy, I guess ;-)
<Ubugtu> Malone bug 23 in baz "baz redo should use merge3 for conflicts like most other commands do." [Medium,Unconfirmed]  http://launchpad.net/bugs/23
<infinity> slomo_: When Kamion's done processing universe syncs. :)
<dholbach> s/bug/but
<slomo_> dholbach: ok ;) 23:59 UTC sounds ok ;)
* dholbach hugs infinity
<ajmitch> and then poor kamion has the backlog of new source packages
* infinity gives mvo 2 more minutes to speak up before he starts a publisher run.
<slomo_> pygi: well, the libburn versions are called development releases... no idea... if you want i can give you the package that's currently in NEW and you update it to the libburn version ;)
<ajmitch> that rate of new uploads has gone up in the last week or so
<mvo> infinity: yes please
<mvo> (within the 2min :)
<infinity> mvo: 05:09 < tfheen> infinity: I'm still waiting for an answer to what's broken if it's not approved
<pitti> tkamppeter: I did some digging for bug 40795; do you have an idea about that?
<Ubugtu> Malone bug 40795 in cupsys "cannot create printers in live system" [High,Needs info]  http://launchpad.net/bugs/40795
<pitti> tkamppeter: (brb for discussion, rebooting)
<mvo> tfheen: if we don't include it, please won't be able to easily test the cdromupgrade. they will require a backport of update-notifier
<ogra> tfheen, oh, wouldnt a edubuntu amd64 install only rebuild be possible ? 
<tfheen> ogra: it would, but do you have time to test it properly?
<ogra> you mentioned something like that yesterday 
<mvo> tfheen: the backport is required anyway so its not that bad. it would be a nice-to-have though
<ogra> tfheen, well, it will take me ~2h to test
<tfheen> mvo: so it doesn't really matter, then?
<tfheen> ogra: including soyuz + cd building time?
<tfheen> and rsync
<ogra> so it depends somewhat on the tsp package build speed
<ogra> *ltsp
<infinity> soyuz turnaround is going to be about 70 mins from when I push the button.
<mvo> tfheen: its not worth a rebuild no (as I said earlier)
<tfheen> mvo: ok.
<ogra> the rsync works fine today, should be done in a minute for that change
<tfheen> mvo: I'll hold it off, then.
* infinity leaves dist-upgrader in unapproved, and pushes the button.
<tfheen> infinity: thanks.
<mvo> ok
<mvo> thanks
<slomo_> pygi: so what do you think? :)
<pygi> slomo_: lemme solve the libburn first :)
<pygi> ok? :)
<slomo_> pygi: ok ;) but only ~12 hours left until universe freeze
<pygi> slomo_: yes, I know that :(
<ogra> slomo_, it would be nice to have something that uses libburn in the archive ... so it gets user testing ... we plan to do some stuff with libburn in edgy+1 with ltsp
<slomo_> ogra: yes, agreed... but on the other hand brasero is a really nice application and i would hate it if it's broken for edgy :(
<ogra> right
<pygi> slomo_: don't see why would it be broken?
<ajmitch> libburn package needs some love before use, I'd say
<slomo_> pygi: imho development release sounds scary and libburn support is rather new and nothing used libburn before so we don't really know how well libburn behaves... one month earlier or something we would've enough testing and time to fix anything that might show up but now it's really late ;)
<pygi> slomo_: actually cdrskin uses libburn :) If you want I can show you how to burn cd using k3b over libburn :)
<ajmitch> slomo_: I'm just looking at the libburn package, it makes me sad
<slomo_> ajmitch: why?
<pygi> slomo_:  a lot of packaging issues
<ajmitch> very loose shlibs, explicit depends on libc6, -dev packages don't require any specific libburn-1 version, etc
<ajmitch> and the SONAME is libburn.so.2, while the package is libburn-1
<slomo_> ajmitch: is this the package in the archive?
<ajmitch> the package in binary NEW
<ajmitch> which infinity hasn't quite let through, afaik
<ajmitch> I haven't looked at 0.2-2 in the archive
<slomo_> probably should be rejected then and fixed before imho
<ajmitch> yeah
<tfheen> ogra: haven't you tested any of your live CDs and only i386 installs?
<infinity> I'm rejecting it anyway.
<slomo_> pygi: ok but how many users are using this already? but i guess for edgy+1 it would make sense to move everything to libburn very early
<infinity> pygi: The SONAME and package name don't match still, apparently.  Fix that too, please. :)
<ajmitch> infinity: thanks, I'll look at overhauling it
<pygi> infinity: obviously I should create a new package :)
<infinity> ajmitch: The SONAME thing and the "doc package is arch:any, not arch:all" things are the two blockers for me.
<infinity> ajmitch: You and pygi can fight over who gets to fix it.
<pygi> slomo_: true, but we don't get edgy audience then
<ogra> tfheen, i tested i386 live ..its fine 
<pygi> infinity: perhaps just that two blockers for you, but there are more issues
<ogra> tfheen, i'm just a bit behind on the wiki, sorry
<pygi> we can't let it in like that
<ajmitch> I've got plenty enough to do, pygi can fix it if he can get everything sorted by freeze :)
<tfheen> ogra: ok.  What about amd64 and powerpcs?
<infinity> pygi: Oh, I'm sure there are lots.  Those are the two obvious "I don't want to ACCEPT this" blockers.
<pygi> right :)
* ajmitch has to split up xen-3.0 some more anyway
<ogra> tfheen, powepc live is exploded due to an archive bug
<ajmitch> tfheen: fyi I've got xen userspace headers, and libvirt built
* infinity rejects those binaries, so no one else is tempted to accept them.
<tfheen> ajmitch: you're aware of the git repo zul and I are using for xen (the kernel bits)?
<ajmitch> tfheen: yep, I've got that checked out
<ajmitch> while zul is off sorting 2.6.17 I'm helping him with the userspace parts
<tfheen> coolie
<dholbach> Kamion: did you already get a bug about gparted showing no partitions and harddisks, but a "next" button, which brings you to a screen where I can choose the 3 existing partitions and assign mountpoints?
<pygi> slomo_: dunno what to do with Brasero. Would be great if we could squeeze it in Edgy, but if you really think it'll break something...
<ogra> ARGH
<ogra> who didnt respect my lock
<ogra> grmbl
<Kamion> dholbach: no
<Kamion> dholbach: well, maybe, but hard to say :)
<slomo_> pygi: yes... but i would prefer no edgy audience over one million bugs that we can't fix anymore for edgy after release... i don't think it _will_ break but it _might_ break and we could get no chance to fix it for edgy
<pitti> hi rodarvus 
<Kamion> dholbach: that's usually because gparted crashed; please attach /var/log/syslog
<dholbach> Kamion: alright - i'll try to find it, then file it on my own
<rodarvus> hi pitti!
<dholbach> Kamion: I'm sorry to pester you like that
<slomo_> pygi: on another topic... are there n-c-b patches to use libburn? :)
<Kamion> dholbach: no, please don't ever attach information to an existing ubiquity bug that somebody else filed
<pygi> slomo_: ah, ok then
<dholbach> Kamion: alright
<pygi> slomo_: translate "n-c-b" for me pls :)
<Kamion> it's much more work to untangle multiple problems from one bug than it is to mark bugs as duplicates
<slomo_> pygi: nautilus-cd-burner
<pygi> slomo_: oh, no, not really
<slomo_> pygi: and please don't get me wrong, i would love to change everything from using cdrecord to something sane... but not now :)
<slomo_> pygi: hmm, did you already talk with n-c-b upstream about this?
<pygi> slomo_: no
<pygi> slomo_: I'm not sure who exactly n-c-b people are as first point, and as second I'd like to approach them once libburn 1.0 is out
<pygi> which at our current development speed with two and a half developers shouldn't take too much really
<pygi> slomo_: is n-c-b based on cdrecord currently?
<slomo_> pygi: ok, that's good :) well, look at /usr/share/doc/nautilus-cd-burner/copyright ;)
<pygi> slomo_: if so, you could easily talk it into using libburn (if it's based on cdrecord)
<slomo_> in edgy, yes... in debian it uses the debian cdrecord fork (forgot it's name)
<tfheen> wodim
<pygi> right, wodim
<pygi> slomo_: well, you can easily change it to use libburn without source code changes :)
<pygi> slomo_: want instructions? :P
<dholbach> Kamion: bug 62772
<Ubugtu> Malone bug 62772 in ubiquity "gparted shows no partitions, but a next button (which brings you to the partition-mountpoint screen)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62772
<Kamion> dholbach: http://librarian.launchpad.net/4536398/syslog gives a 403
<dholbach> uh?
<Kamion> interesting though, that's a gparted bug - gparted is starting up fine, just not displaying anything
<ogra> did you change the premissions before uploading ? 
* Kamion shuffles it over
<dholbach> Kamion: i'll try to add it again
<gnomefreak> what kernel is default in the 386 installer now?
<ogra> -10
<gnomefreak> i meant 386 486 586 -generic?
<slomo_> pygi: sure
<ogra> 386
<gnomefreak> ty
<ajmitch> slomo_: ok, I think I got most of the libburn issues :)
<pygi> slomo_: install cdrskin and just link "cdrecord" binary to "cdrskin" binary
<mvo> Kamion: have you seen something #62644 before? I have seen this yesterday on a friends system
<seb128> bug 62644
<Ubugtu> Malone bug 62644 in ubiquity "Various freezes with ubiquity on AMD64 Edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62644
<dholbach> Kamion: attached a new one
<slomo_> pygi: ok, that's what i expected :) i'll test that later... but i guess when using libburn directly you don't have to exec another app for burning?
<pygi> slomo_: ofcourse not. libburn is a library :P
<infinity> ogra: Will this new ltsp require an amd64/live rebuild too, or just amd64/install?
<pygi> infinity: livecd doesn't have ltsp I think
<pygi> but ogra will tell
<ogra> infinity: only install ... live doesnt ship ltsp
<Kamion> mvo: no, sorry
<pygi> I was even correct :P
<infinity> ogra: Alright.  I'll respin that image for you as soon as the publisher's done.
<ogra> infinity: wowie, thanks a lot !
<infinity> ogra: http://cdimage.ubuntu.com/edubuntu/daily/20060928.2/
<ogra> yay, thanks :)
<bddebian> Howdy folks
<slomo_> Remenic: ping? :)
<Kamion> jdong: could you or one of the other backporters confirm the backport request for xmoto 0.2.1-1 in bug 57754, please?
<Ubugtu> Malone bug 57754 in Baltix "Please backport xmoto" [Undecided,Rejected]  http://launchpad.net/bugs/57754
<bddebian> Hmm, someone is cleaning out the queue this morning
<ogra> oh nooo 
<ogra> there is no linux-image-amd64-generic package anymore ? not even as transitional package ?
<ogra> oh crap ...
<pitti> that will hurt us for dapper upgrades, right?
<ogra> and for my ltsp rebuild 
<ogra> infinity: sorry, it didnt help ....
<ogra> now its failing on teh kernel install ... even the other bug is fixed
<AnAnt> did Ubuntu remove the ability to set hardware clock to GMT while system clock to some timezone ?
<AnAnt> in Edgy that is
<seb128> AnAnt: no, edit /etc/default/rcS, the UTC= option
<AnAnt> seb128: thanks, why can't I find it in time-admin 
<seb128> AnAnt: because there is no option for it, and there was no option for it before neither
<AnAnt> seb128: I remember I configured it somewhere before without having to edit that file
<seb128> where?
<sfllaw> Kamion: Ping?
<ogra> pitti: hmm, that package seems to exists ... its just not on the CDs
<ogra> (the transitional one)
<ogra> so it will probably break on CD upgrades
<infinity> Hrm, yeah, probably needs to be in ship for CD upgrades.  Good point.
<ogra> yep ...
<sfllaw> Kamion: I was wondering if there are any switches to up d-i's verbosity.  Specifically for "in-target".
<ogra> well at least one positive outcome of the rebuild then :)
<ogra> dholbach_: oh, since when are you with alice ? 
<pygi> infinity: ping
<pygi> infinity: kick the libburn if it suits you pls :)
<pitti> can I upload a new openssl? I'm fine with having it stalled until after beta, but I'd like to get it into edgy ASAP
<tfheen> ogra: You're happy (as it goes) with the current state?
<tfheen> Riddell: you too happy with your current ISOs?
<Riddell> tfheen: i am yes
<tfheen> Riddell: ok, thanks.
<infinity> pitti: You can upload whatever you like, I'll just not approve it until after beta.
<Riddell> matthewrevell: your presenkse has reminded me, did the lugradio episode go out?
<ogra> tfheen: well, happy is something else ... but i'm ok with it
<matthewrevell> Riddell: It's due to go out on Monday.
<tfheen> ogra: you have to have something to improve on for release, you know.
<tfheen> ogra: feel free to update http://wiki.ubuntu.com/EdgyReleaseNotes 
<matthewrevell> Riddell: Sorry, that's Monday 9th October
<tfheen> Riddell: if you have problems in your release, feel free to update ^^ too
<ogra> tfheen: i'm more coincerned about people upgrading from dapper on amd64 without the transitional kernel package on teh CD
<tfheen> ogra: add it to the list of release notes, then.
* ogra pokes the ibook keyboard
<tfheen> ogra: I guess telling you "you should have tested upgrades before" doesn't help? :-P
<ogra> tfheen: will do ... fixing it is trivial for me either way
<pygi> infinity: looks nice or?
<ogra> tfheen: did *you* test upgrades, its not edubuntu specific
<Riddell> tfheen: there's no changes to the ISOs I want for the beta.  should I be testing DVDs?
<ogra> tfheen: linux-image-amd64-generic is not on any of teh CDs
<ogra> tfheen: but all dapper users have it ...
<tfheen> Riddell: if you had done so, it would have been useful, yes.
<Riddell> tfheen: should we not make new DVDs to match today's CDs?
<tfheen> Riddell: we could, sure.
<Riddell> tfheen: I'll do that now
<tfheen> thanks
<tfheen> care to do ubuntu and edubuntu ones too?
<Riddell> tfheen: will do
<tfheen> thanks.
<ogra> Riddell: thanks
<sivang> pygi: pong
<maswan> tfheen: you gyus going to want a beta iso push soon:ish? I'm [VAC] :ing, so I won't be online after the conference sessions end
<tfheen> maswan: yes, I'm writing the release announcement now.
<tfheen> I guess I should publish and push to you guys first.
<maswan> tfheen: ah, ok. let me know when I should hit the mirror sync
<Kamion> sfllaw: what sort of verbosity do you mean?
<Kamion> sfllaw: in-target just fiddles about with a bunch of environment variables, fds, and other misc. setup stuff, and then runs a subsidiary command in /target; the stdout and stderr of that command are logged in their entirely
<Kamion> entirety
<azeem> anybody know about the "Headphone jack sense" option (or similar) in gnome-volume-control's Switches panel?
<azeem> it was enabled on my supervisor's X40, which resulted in no sound (neither speakers nor headphones) at all
<azeem> on dapper
<tfheen> maswan: apparently, we trigger you?
<mjg59> azeem: It's not enabled by default
<tfheen> maswan: note that this is releases.u.c, not cdimage.u.c
<azeem> mjg59: ok, so maybe his sound was muted somewhere, he pushed some buttons and then didn't get anywhere
<tfheen> Gloubiboulga: how is xubuntu, release-wise?
<Hobbsee> azeem: i've had that problem too.  with breezy, i think
<elmo> tfheen: yeah, we don't trigger anyone for cdimage
<mjg59> azeem: The Thinkpad mixers are wired up differently to most - the headphone sense stuff is done in hardware outside the sound chip
<elmo> tfheen: and maswan is one of the few people who has a full cdimage (and thus DVD) mirror
<azeem> mjg59: though he claims he never heard any sound at all (not even the login jingle)
<mjg59> azeem: His system was probably muted when he first installed
<azeem> well, problem solved, but with some luck I guess
<azeem> yeah
<azeem> he upgraded from hoary and breezy
<maswan> tfheen: ah, ok. releases you trigger, cdimage is cron:ed (and I usually manually trigger that when you don't want to wait until 09:00 CET)
<mjg59> The fact that we have this "break me" button is irritating, but hard to get right
<ogra> meh, is LP down ? 
<tfheen> maswan: can you set up an at job to trigger cdimage at 2100 CEST?  That should leave us plenty of time.
<maswan> tfheen: sure, I can do that
<Nafallo> maswan: ooh. does that mean you have se.cdimage.ubuntu.com now? :-)
<tfheen> maswan: excellent, thanks.
<maswan> tfheen: now we sync at 09,21
<tfheen> maswan: thanks a bunch
<maswan> Nafallo: well, it's not a _full_ mirror, just the "release" directories. but that's the reason ftp.acc.umu.se is often listed in release anncouncements for knot-Ns and betas etc
<Nafallo> ah, oki :-).
<jdong> Kamion: more recent versions of xmoto no longer backport; wants newer dpkg-dev
<Kamion> jdong: ok; could you reject that bug then?
<Kamion> jdong: since the rest of it should be done
<jdong> Kamion: sure thing
<Kamion> ta
<jdong> so how's the beta release going?
<Kamion> nearly there
<jdong> cool
<Kamion> I've not been much involved, Tollef has been heroic this time
<jdong> well, fixing that nasty NTFS ubiquity bug was a huge contribution in my books :)
<Kamion> yeah, sorry about that, I should have noticed that bug ages ago
<Kamion> I believe it was present in dapper, in fact
<Kamion> if there's another dapper point release, I'll take the fix
<jdong> yeah, hobbsee was telling me that last night... she claims it's a fix for bug 1 :)
<Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<Kamion> it wasn't actually NTFS-specific at all, AFAIK
<azeem> 5
<azeem> uh.
<thom> 6!
<ogra> tfheen: just for your pleasure, TestingCurrent for edubuntu is complete now ... i even retested the i386 install to carch possible regressions ...
* Kamion runs out again for the school run
<Kamion> I feel like lamont
<sivang> Kamion: heh
* tfheen plays with publish-release.
<ogra> Kamion: wearing glasses now ?
<ogra> or a fireman outfit ?
<thom> Kamion: as long as you're not toting a large gun it's fine
<ogra> thom: well, depends if his laughing changed as well ;)
<tfheen> ubuntu-6.10-beta-alternate-amd64.iso
<tfheen> if that don't look good, I wouldn't know
<ogra> just dont call them like that for edubuntu :P
<ogra> we still have -install-
<tfheen> publish-release won't let me, so that's fine
<ogra> do you exclude ppc-live and amd64-install from teh released ones ? 
<ogra> or do i need to warn users ?
<tfheen> I could, sure
<ogra> that would be nice :)
<tfheen> shame I don't take bribes or I could get rich doing this job. :-P
<ogra> well, ask for a beer in california, i'll surelay pay you one :)
<jdong> lol
* jdong extends that offer to the metro detroit area, too
<tfheen> if they have something which isn't like having sex in a canoe, sure.
<ogra> heh
<ogra> i had some nice ones in detroit
* jdong still underage :(
<tfheen> ogra: happy with /srv/cdimage.ubuntu.com/www/simple/edubuntu now?
<ogra> ergh ... i have no ssh id on this machine ...
<ogra> so i cant log in to lithium ...
<ogra> give me 10 mins
<tfheen> you seem to be in getent passwd..
<ogra> but i have no password on any DC machines
<tfheen> oh, in that respect.  Sure
<ogra> i'll just need to reboot teh amd64 ... takes a moment ...
<tfheen> http://rafb.net/paste/results/ugG1EB68.html
<ogra> yep, looks right
<sfllaw> rodarvus: How does Edgy detect monitor resolutions?
<sfllaw> rodarvus: This is regarding bug 49115.
<Ubugtu> Malone bug 49115 in xorg-server "Max resolution not detected properly for IBM G78" [Undecided,Unconfirmed]  http://launchpad.net/bugs/49115
<ogra> sfllaw: dccprobe
<sfllaw> ogra: Thanks.
<mjg59> ogra: Not entirely
<mjg59> sfllaw: xresprobe
<ogra> well, which calls dccprobe internally, no ?
<tfheen> ogra: sometimes.
<sfllaw> mjg59: Found that package.
<mjg59> ogra: Depends on the hardware
<ogra> ah, i thought you made it multiarch in dapper
<mjg59> ogra: No, I mean ddcprobe does nothing useful on laptops
<ogra> hmm, it does for me here ...
<sfllaw> It must depend on the laptop's monitor hardware.
<sfllaw> You know, whether it supports DDC.
<mjg59> ogra: Almost no laptops implement ddc. You have to query the graphics hardware.
<mdz> morning
<mjg59> Which is what xresprobe does
<Nafallo> morning mdeslaur 
<ogra> mjg59: on my amd64 i just tested it ... 
<sfllaw> mdz: Top of the morn.
<mdz> how are we doing?
<ogra> mjg59: worked perfectly
<Nafallo> ehrm... s/mdeslaur/mdz/
<Hobbsee> hi mdz 
<mjg59> ogra: Your laptop may be some weird freaky exception, but in general laptops do not do ddc for the internal panel
<ogra> it even recognizes teh difference between internal (ldc) and external (crt) modes
<tfheen> hi mdz.
<jdong> so does it look like 0928.2 will become beta?
<ogra> mjg59: i tested it on another amd64 lappie for tfheen when he hacked on it in dapper and it worked there as well
<ogra> probably it improved ? 
<tfheen> mdz: I've started running publish-release now.
<mjg59> ogra: Whereas on mine, it just gives a set of modes the video hardware can support - there's no edid block
<mjg59> ogra: Dude. No. Most laptops do not provide any useful ddc content for the internal panel.
<mdz> tfheen: great. do we have an announcement draft?
<seb128> Keybuk: I've uploaded slab to edgy yesterday if you fancy accepting some new crack from NEW ;) (the package comes from Debian so it should be fine)
<ogra> hmm
<dholbach> seb128: don't forget the telepathy packages ;)
<seb128> dholbach: I've not uploaded one of those to NEW yet :p
<Nafallo> dholbach: does that include farsight? :-)
<dholbach> Nafallo: yes
<dholbach> Nafallo: http://wiki.ubuntu.com/Telepathy/Modules
<Nafallo> yay :-)
<Nafallo> oh, everything is ready? :-)
<Kamion> I'm working on NEW
<Nafallo> ah, not sharp and wilde :-)
<pygi> Kamion: ok, I guess you'll kick libburn if it's fine now then? :)
<rodarvus> sfllaw, as mjg59 mentioned, xresprobe is the main responsible
<rodarvus> for resolution detection
<dholbach> Nafallo: wilde was too hard to do - if you fancy java stuff - give it a try
<mdz> Kamion: if you're doing archive stuff, please sync cpio per 59228
<dholbach> Nafallo: and -sharp is too broken
<Kamion> pygi: I guess so, but I haven't got there yet
<pygi> Kamion: ok, no worries
<Kamion> mdz: I thought I should wait until after beta for that one
<Nafallo> hehe, will not start with java now. I
<Kamion> I did all the non-main syncs
<Kamion> well, all the correct ones
<Nafallo> I'll happily dodge is as long as possible :-P
<lfittl> Kamion: I added another bunch of non-main syncs some hours ago, sry ;)
* Nafallo should file one against logcheck, but I
<Nafallo> I'm not main
<Kamion> lfittl: no worries
<Nafallo> damn enter key! doesn't sit there on the other keyboard...
<mdz> Kamion: ah, right, syncs wouldn't stop in unapproved, would they
<Kamion> indeed
<Kamion> they sail through
<mdz> Kamion: that one should be first on the list when the time comes though
<Kamion> yep, it will be
<tfheen> mdz: http://err.no/tmp/beta.txt
<sabdfl> what's the kde equivalent to gksu?
<Riddell> sabdfl: kdesu
<sabdfl> and update-manager?
<joejaxx> Kamion: may i pm you?
<\sh> adept
<Riddell> sabdfl: adept_updater
<tfheen> EVERYBODY: please help fill in the beta release announcement http://err.no/tmp/beta.txt
<sabdfl> Riddell: is there an equivalent to update-manager -c -d ?
<Seveas> (tfheen: put it in a gobby session for real collaborative editing :))
<Riddell> sabdfl: what does that do?
<seb128> tfheen: maybe a "known issues" would be useful?
<tfheen> Seveas: My head feels like it's going to blow up any minute, so I'd prefer not having to fight gobby today.
<carlos> doko_: http://people.ubuntu.com/~carlos/language-packs/ooo-edgy-2006-09-28.tar.bz2
<sivang> hey sabdfl 
<ogra> tfheen, sabdfl,  i wonder if we should annonce that we ship an ltsp5 prerelease ;)
<pygi> tfheen: shouldn't we put "New Init System - Upstart" or something? :)
<\sh> Riddell: -c check dist-upgrades , -d devel-releases
<carlos> doko_: I checked it with md5sum
<crispin__> hmm, ubuntu thong on bbc news ... http://news.bbc.co.uk/1/hi/magazine/5388182.stm
<mdz> tfheen,EVERYBODY: https://wiki.ubuntu.com/EdgyBetaAnnouncement
<mdz> tfheen: do we have release notes from knot 3 to be the basis for the beta release notes?
<doko_> carlos: thanks, will prepare the package
<mdz> tfheen: or better, something newer from the marketing team?
<Kamion> joejaxx: it always helps to say what it's about
<tfheen> mdz: https://wiki.ubuntu.com/EdgyEft/Beta
<sabdfl> Riddell: the upgrade assistant, and includes pre-release upgrades
<sabdfl> so, dapper -> edgy offered
<carlos> Riddell: is there any chance to get https://launchpad.net/distros/ubuntu/+source/kde-i18n/+bug/60049 fixed?
<Ubugtu> Malone bug 60049 in kdebluetooth "Import of translations for KDE's desktop-* failed" [Undecided,Confirmed]  
<tfheen> ogra: please add ltsp 5 to the list.
<mdz> tfheen: great
<sabdfl> ogra: has jammcq made an official announcement of ltsp5?
<joejaxx> Kamion: livecd-alternative install hybrid cd
<sabdfl> if not, please don't mention it here, that's stealing their thunder
<mdz> mvo: what does the -c flag to update-manager do?
<ogra> sabdfl: only the wikipage you saw that says that they'll base on our existing code
<sabdfl> then i don't think we can claim it
<ogra> ok
<ogra> was just an idea :)
<mvo> tfheen:  shouldn't the announcement  mention https://wiki.ubuntu.com/EdgyEft/Beta?
<tfheen> mvo: it should, please change it on the wiki
<Riddell> sabdfl: no, you have to edit the repository in Adept Manager and do a Full Upgrade (i.e. dist-upgrade)
<sivang> mdz: there is no mention of the python version, I would include something about moving to pycentral and stuff
<mvo> mdz: it means "check for upgrades". we decided back in dapper that it shouldn't offer dapper->edgy upgrades by default
<Kamion> joejaxx: sure, I guess so
<Riddell> carlos: yes, I'll look at that after beta
<Riddell> tfheen: are we doing separate announcements?  (my preference)
<sivang> mdz: for "under the hood" section, given python is now a big part of what's under it.
<\sh> is there any reason, why ca-certficates packages installs the whole world of ssl certs into /etc/ssl/certs and updates them, to make ldap clients (e.g. ldap-pam etc.) very slow for user lookup etc. Thing is, the ldap clientlb looks up every cert for authentication with the ldap server
<mvo> tfheen: thanks, done
<sabdfl> Riddell: so there is no smart update, which gets rid of deprecated packages etc?
<carlos> Riddell: thanks
<Kamion> sivang: python-central isn't a user-focused change; it's there to make maintaining the system easier for us
<mdz> mvo: I see, I'll clarify in the announcement
<mvo> mdz: thanks
<sivang> Kamion: okay.
<Riddell> sabdfl: sadly no, a broken embedded console in pykde has been the main blocker for porting the tools from ubuntu but upstream told me it was fixed last week so I want it to be done in edgy+1
<sabdfl> Riddell: ok :-/
<mvo> Riddell: oh? its fixed now? that is good news!
<tfheen> mdz: my head is utterly exploding (second day of flu-ish sickness), so I'm going to get a bit of rest.  Colin knows what I've done wrt publishing and is fixing the .htaccess and HEADER.html files.
<Riddell> mvo: well he sent me an e-mail asking me to check it, which I'll do after beta
<tfheen> mdz: if there's anything urgent, I have my phone, so just call or SMS me.
<mvo> Riddell: sure :) feel free to CC/forward me
<mdz> tfheen: ok, thanks much
<Nafallo> tfheen: take care mate
<joejaxx> sabdfl: it is nice to meet you
<mdz> Kamion: is there a bug open about this mono issue mentioned in the release notes?
<ogra> could someone look over the formulation for the ltsp part, i know my english grammar sucks today
<seb128> mdz: bug #62756
<Ubugtu> Malone bug 62756 in squashfs "mono confused by the desktopCD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62756
<mdz> thanks
<Kamion> sorry, seb beat me to it
<seb128> mdz: I think Tollef said that was a squashfs issue, feel free to reassign if that's not the correct package
<joejaxx> well bbl all
<mdz> seb128: just wanted a bug ref for the release notes
<seb128> ok
<mdz> sabdfl: thoughts about mentioning known issues in the announcement vs. only linking to the release notes?
<ogra> sabdfl: see pm :D
<mdz> seb128: looks like either unionfs or casper; I've cleared the package field for now
<seb128> mdz: ok, thank you
<doko_> dholbach: time for OOo hicontrast icons?
<sabdfl> mdz: very serious known issues in announcement, anything else in the release notes i'd say
<dholbach> doko_: righto
<dholbach> heno: did you ever have a look at the locolor icons that are shipped with openoffice? /usr/share/icons/locolor? which of the themes would they fit to?
<mdz> sabdfl: if they were very serious, we wouldn't release with them ;-)
<dholbach> doko_: might make sense to split them out into a different package
<mdz> sabdfl: https://wiki.ubuntu.com/EdgyEft/Beta#head-5468d6dc677b5eca2e68d93411f74c6135c9de28
<doko_> dholbach: maybe
<infinity> mdz: If we're past the point of no return and pretty much published, shall I thaw edgy again, and clear unapproved?
<dholbach> doko_: we wouldn't want gnome-accessibility-themes to pull in openoffice.org-common :-)
<mdz> infinity: kamion is at the helm
<mdz> Kamion: was that pre-publishing or publishing-publishing?
<infinity> Kamion: Ditto. :)
<Kamion> mdz: the latter
<mdz> elmo: ping
<ogra> mdz: i have jammcq's approval for calling our ltsp ltsp5-prerelease ... how do i formulate that best ? suggestions ?
<Kamion> tfheen decided to just blat it straight through ;-)
<Kamion> we haven't put the DVDs and such anywhere yet
<Kamion> what am I doing with Xubuntu?
<mdz> Kamion: have you or tfheen been in touch with elmo?
<sabdfl> mdz: looks really good! who put that together?
<mdz> sabdfl: marketing team, I believe
<Kamion> mdz: tfheen talked with him earlier since elmo wanted to know if he could steal a machine back from emergency buildd duties
<heno> dholbach: not having seen it in action, I would think they would fit with High Contrast and possibly High Contrast Inverse
<Kamion> so he's aware that beta is nowish
<slomo_> mdz: wasn't LPI affected by the mono problem too?
<heno> dholbach: how can I select them so I can test them with the themes?
<dholbach> heno, doko: ok, maybe it's best to split it out with an added index.theme file, then try it with different themes
<dholbach> heno: we're not able to put it into action yet :-)
<crimsun> Kamion: janimo, Gloubiboulga are testing atm
<dholbach> heno: I'll ping you again at that time, sorry - I thought you had a peek at /usr/share/icons/locolor/ already :)
<Kamion> crimsun: ok, thanks, let me know as soon as there's an answer
<Kamion> if you could
<crimsun> Gloubiboulga: ^^
<Hobbsee> sabdfl: mdz: @ who did that page - marketing or doc team, i suspect
<heno> dholbach: I'm looking at the icons now. I guess I can imagine what they look like on the OOo widgets :)
<Gloubiboulga> hi Kamion, hi crimsun
<Gloubiboulga> Kamion, alternate image failed for me (bug 62770)
<Ubugtu> Malone bug 62770 in debian-installer "debootstrap: cannot execute mount (Xubuntu daily 20060928)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62770
<Gloubiboulga> I've re-burnt the image, and am off for an other test right now...
<dholbach> doko: seems they are not so many
<dholbach> doko: 62? is that about right?
<Kamion> Gloubiboulga: !
<Kamion> Gloubiboulga: definitely smacks of a bad CD
<Gloubiboulga> Kamion, I hope so :)
<mdz> slomo_: LPI and mono -> dunno
<ogra> Gloubiboulga, note that amd64 ltsp is broken due to a missing transitional kernel package on the CD 
<ogra> will hit you too
<Gloubiboulga> ogra, ok
<seb128> slomo_: bug #60071
<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
<slomo_> seb128: thanks
<seb128> slomo_: np
<dholbach> Kamion: thanks a lot for the  green  spots on http://wiki.ubuntu.com/Telepathy/Modules :-)
<Kamion> np
* sivang goes to check what's causing his laptop to slow to almost a mementous halt
<mdz> lifeless: say, what happened to your conflict checker?  did your work in progress get handed off to anyone?
<lfittl> Kamion: any idea why nvidia-cg-toolkit got removed from Ubuntu?
* sivang goes for a reboot after dist-upgrade
<Kamion> lfittl: I can't find any record of it ever having been there
<elmo> can I claim lock on lithium:~cdimage/bin/sync-mirrors ?
<Kamion> elmo: yes
<lfittl> Kamion: huh, interesting, sry for bothering you then
<Kamion> hmm, we never rebuilt kubuntu and edubuntu dvds
* Kamion starts on that
<ogra> well, according to the daily report there are a bunch of uninstallables on the DVDs 
<Kamion> haven't cared about that for the beta
<mdz> elmo: some of the releases mirrors have the files, but don't honor our header or .htaccess
<mdz> elmo: can we make that a requirement for new mirrors, so it looks consistent?
<mdz> elmo: and are we concerned about bandwidth enough to list them anyway, even though they're ugly?
<elmo> mdz: err, we could, but it could cost us mirrors
<elmo> mdz: I've really no way of predicting how much bandwidth we'll end up using, but if you want to drop the ugly ones, I'm sure it won't hurt us too much
<mdz> elmo: as long as the first one listed for each region looks right, I'll keep it
<mdz> we should probably be more strict for final
<mdz> beta users are expected to know more or less what they're doing, but a lot of folks would be lost with a directory listing
<doko_> Riddell: ping
<mdz> ouch, the australian mirror has nothing
<Riddell> hi doko_ 
<elmo> mdz: the trigger hung, I've just fixed that, and the remaining ones should be syncing now
<mdz> elmo: oh, I guess I should wait before trimming the list then?
<mdz> elmo: can you give me a shout when they're as good as they're likely to get for now?
<elmo> mdz: yes pleasse and  will do
<doko_> Riddell: please could you run a strace -f -e trace=file oowriter 2>&1 | grep 'images.*zip'   and tell me which zip file is accessed in KDE?
<Riddell> doko_: /home/jr/.openoffice.org2/user/config/images_crystal.zip
<Riddell> and /usr/lib/openoffice/share/config/images_crystal.zip
<sfllaw> mvo_: I'm attempting to reproduce bug 62689...
<Ubugtu> Malone bug 62689 in Ubuntu "Hangs at 2% of "Select and install software"" [Undecided,Needs info]  http://launchpad.net/bugs/62689
<sfllaw> mvo_: Is there any particular thing I should do to get you a good logfile?
<doko_> Riddell: thanks
<mvo_> hello sfllaw!
<mvo_> sfllaw: if you can reproduce it I would like to know about the ps ax stuff that is going on. I had a similar issue were it appeared to be hanging but it turned out that it was just apt-extracttemplate runing
<sfllaw> Is there an strace udeb somewhere?
<sfllaw> mvo_: Locked up.
<Kamion> sfllaw: you can udpkg -i strace.deb
<sfllaw> On 20060928 alternate amd64.
<Kamion> (not in general, but it works in that case)
<sfllaw> Kamion: Oh.  You mean the _normal_ package.
<mvo_> sfllaw: oh, hard lock up? or can you still switch consoles?
<Kamion> sfllaw: yeah, it's simple enough that you can just slam it into the installer environment without adverse consequences
<sfllaw> mvo_: I can switch consoles.
<Kamion> seb128: slab accepted
<seb128> Kamion: great, thank you!
<seb128> Kamion: will make some users happy ;)
<jdong> out of pure curiousity, why on earth do we have reiser4progs in the default system?
<Kamion> jdong: we don't any more
<sjoerd> pitti: pling
* Kamion scratches his head at a "shared source" licence in NEW
<pitti> sjoerd: hey
<pitti> sjoerd: (busy with talking to three other people, but go ahead :) )
<Kamion> elmo: would you mind eyeballing this quickly? it actually looks ok - there's just a patent termination clause I'd like to check
<jdong> Kamion: hmm, you're right. Now why doesn't autoremove flag it? :D
<sjoerd> pitti: i was wondering, does the current pmount encrypted device mount magic ensure in some way that only the one that unlocked the device can actually mount it ?
<Kamion> jdong: autoremove may not work well for packages that used to be in minimal and aren't any more
<elmo> Kamion: sure?
<Kamion> due to the way minimal is installed
<jdong> hmm
<Kamion> elmo: drescher:/tmp/cjwatson/queue/ironpython-1.0/License.html
<jdong> ooh, ironpython :)
<elmo> Kamion: where's this aimed at?  universe or multiverse?
<pitti> sjoerd: hm, not right now, I think, good point; I think there's a race condition between two simultaneious pmounts, but I have to check
<sjoerd> pitti: i'm looking at moving over to gnome-mount and stuff.. but at least hal doesn't do that yet so..
<Kamion> elmo: don't know yet
<Kamion> elmo: I note that the licence claims to apply to use of the software (not merely distribution)
<elmo> Kamion: I don't think that's a problem per se
<elmo> Kamion: and I think this kind of patent termination is fine, it's the weakest form, and there are plenty of existing examples of stronger ones in main
<Kamion> yeah, I think it's a licence bug in that it goes beyond copyright, but it doesn't seem to impose anything obnoxious on userss
<Kamion> users
<Kamion> it does leave me wondering what patents apply to ironpython
<elmo> yeah :(
<Kamion> and the package could be considered a derivative work, not the original, so per the licence wouldn't acquire patent rights
<jdong> oh, it's not like it's from microsoft or anything </sarcasm>
<sfllaw> mvo_: Sorry, computer died.
<sfllaw> It looks like dpkg-preconfigure --apt is stuck on wait(-1)
<sfllaw> Is there anything I can poke at specifically?
<Tonio_> hum, is that a launchpad bug ? http://tonio.homelinux.org/tmp/capture13.png
<Kamion> elmo: so having thought about it I can see why Keybuk was scared and left it in NEW. OTOH I don't want to leave it there forever
<Tonio_> 84% translated and no untranslated strings ?
<Tonio_> hum, sorry #launchpad is the place for this
<pepsiman> Tonio_: try the "needs review" filter
<Tonio_> pepsiman: yeah seen that too, but that should be indicated somehow. that's a bit confusing, since something that needs review is already tranlated :) should appear as 100% then...
<mvo> sfllaw: hm, not right now. I haven't seen something like this yet, but if you could add your findings to the bugreport that would be cool. I will have to leave soonish for some sports ./
<sfllaw> mvo: Is there some set -x I can do somewhere?
<sfllaw> It looks like there's a bunch of shell here.
<sfllaw> Or Perl.
<Kamion> sfllaw: /var/lib/dpkg/info/pkgsel.postinst and /target/usr/bin/tasksel would probably be places to look
<sfllaw> Kamion: Yes, those are the scripts that are running.
<sfllaw> I will poke at them.
<mvo> sfllaw: is apt runing at all at this point?
<sfllaw> mvo: aptitude is.
<sfllaw> It's STOPped.
<mjg59> http://www.valleywag.com/tech/linux/moments-in-um-bbc-news-snaps-an-ubuntu-thong-203935.php
<mjg59> Excellent
<Gloubiboulga> Kamion, same issue with an other CD
<Kamion> I can't understand why this would only affect Xubuntu
<Gloubiboulga> and the iso md5sum is correct
<Kamion> have you tried in a different drive?
<jdong> whoa, beta dvd's?
<Gloubiboulga> Kamion, nop, I have only 1 drive
<Kamion> you might want to try cleaning the lens ...
<Gloubiboulga> jdong, no, aternate xubuntu image
<jdong> Gloubiboulga: no, I was just noticing how releases/edgy/beta is full of DVD ISO's
<jdong> http://cdimage.ubuntu.com/releases/edgy/beta/
<Gloubiboulga> jdong, oops, sorry 
<Kamion> they're kind of sub-beta quality in that they've not had much testing, but we're throwing them out along with the beta
<jdong> Kamion: oh, ok, cool
* mvo is away for ~2h now
<pips1> mjg59: :-D
* jdong notes he's the first seed to ubuntu-6.10-beta-desktop-i386.iso
<mjg59> Kamion: Thanks for NEWing
* HiddenWolf rsyncs
<jdong> Kamion: I couldn't help but notice the PPC dvd is 1/3 the size of the other DVD's?
<Kamion> jdong: interesting point
<Kamion> I can't say I know what's up there
<Kamion> I think I'll purge it
<Kamion> the build from the previous day was fine
<doko_> Kamion: found anothet 15MB to save on the CD
<doko_> another even
<Kamion> doko_: cool, where?
<doko_> OOo :-)
<Kamion> bonus
* jdong sits in an empty bittorrent swarm, waiting for the onrush of leechers :)
<HiddenWolf> jdong: got a link to the torrent? I can sync 10mbit.
<doko_> so now I'm at about 23MB, for edgy+1 we should check the duplicate files and move huge upstream changelogs into -dev packages
<HiddenWolf> jdong: seed, that is.
<Kamion> doko_: if that's in your next OOo upload, that will be fantastic
<Kamion> thanks for finding that
* Nafallo starts looking for peers
<Nafallo> jdong, HiddenWolf: amd64-desktop? :-)
<doko_> Kamion: I'll split it out in extra packages; if I overlooked something, then we can just add dependencies on these extra packages
<HiddenWolf> Nafallo: is that needed most?
<Nafallo> HiddenWolf: that's where I look for peers ATM ;-)
<HiddenWolf> Nafallo: sorry, I've got an i386 rsynced. :)
<Nafallo> heh
<Spads> jdong: Ng and I are sitting on ubuntu-6.10-beta-alternate-i386.iso and see each other but no seeds
<jdong> HiddenWolf: http://torrent.ubuntu.com:6969/
<jdong> HiddenWolf: the 6.10 ones are towards the bottom
<jdong> Spads: I'm sitting on the livecd, no other seeds/peers
<Spads> ahhh
<jdong> Spads: ah, two leechers now :)
<HiddenWolf> There, seeding i386-desktop
<jdong> :)
* Spads leeches
<Nafallo> jdong: I'm one of them ;-)
<jdong> this should be baptism by fire for my newly patched ktorrent :)
<jdong> 83.227.x.x of sweden is slurping from me right now :)
<Nafallo> haha
<Nafallo> me :-)
<jdong> hehe
<LaserJock> hmm, can you seed torrents without actually downloading the whole thing first?
<HiddenWolf> jdong: heh, Last knot I managed to upload 60g in a weekend
<Nafallo> LaserJock: you seed the parts you have while you download :-)
<jdong> LaserJock: the beta's apparently the most recent daily-live build, which I leeched last night via HTTP
<LaserJock> hmm, what if I already have the .iso? will it seed that ok?
<jdong> LaserJock: yeah, it'll seed fine
<jdong> LaserJock: just coax your torrent client into accepting it
<LaserJock> I was thinking I could rsync a knot3 .iso real quick and seed it
<LaserJock> I don't really use torrent as it is incredibly slow for me, but I'm sure the uni won't mind me contributing to the open source world ;-)
<HiddenWolf> LaserJock: just rename your iso to the torrent-name. IE ubuntu-6.10-desktop/alternate-$arch.iso
<Nafallo> and beta in the middle somewhere ^ :-)
<HiddenWolf> Nafallo: ssht. ;)
<rodarvus> mjg59, ping
<mjg59> rodarvus: Hi
<rodarvus> I noticed you uploaded a package called 'xserver-xorg-video-intel' a few minutes ago - is this package based on the modesetting branch of -intel git repo?
<mjg59> rodarvus: Yup
<rodarvus> oh, nice
<mjg59> It's rather flaky right now
<rodarvus> I considered doing this some time ago but it was not top priority so I just ended postponing this package
<rodarvus> yup, I didn't had much success with this package either, but it was helpful in at least one case (for a guy with a LFP panel which was not working with the standard driver)
<rodarvus> s/package/branch/
<sladen> excellent.  I thought we were too late for that in edgy
<rodarvus> as we would say in Brazil, mjg59 scored this goal at the 49 minutes of the second half
<rodarvus> universe beta freeze starts either at 23:59 UTC, or earlier, at dholbach's discretion >:-)
<dholbach> rodarvus: thanks for upsetting everybody when I refuse to go to bed at 1:59 local time ;-)
<rodarvus> dholbach, so you're actually sleeping at night? tsc tsc.
<LaserJock> haha
<dholbach> :-)
<dholbach> i'll quit working late today, so you have some hours to play still
<dholbach> -> break
<Nafallo> dholbach: good :-)
<LaserJock> anybody know if releases.u.c has rsync?
<LaserJock> server that is
* ..[topic/#ubuntu-devel:mdz] : 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 | 6.10 beta released
<elmo> LaserJock: of course it does
<LaserJock> elmo: ok, I wasn't sure if I was just doing the rsync command right or if on cdimages.u.c was supposed to be rsyncable
<LaserJock> s/right/wrong/
<HiddenWolf> LaserJock: rsync --progress rsync://cdimage.ubuntu.com/cdimage/daily-live/current/beta.iso beta.iso
<LaserJock> HiddenWolf: yeah, I just wanted to get it from releases.u.c to make sure I got the right .iso
<HiddenWolf> LaserJock: this worked for me for live i386
<doko_> iwj: ping
<keescook> working on building an edgy chroot, but I'm getting an error about missing linux-kernel-headers.  Is this my fault or the archive's fault?
<elmo> kamion/tfheen/riddell/ogra/whoever: cdimage.u.c space usage jumped by 130Gb or so ...
<ogra> elmo, i suspect a lot of temporary builds can go ...
<ogra> we usually keep only 3 past builds 
<geser> does somebody know why the Contents file for edgy doesn't get updated since 07-Jun-2006?
<rodarvus> keescook, linux-kernel-headers was replaces by linux-libc-dev some time ago (and should be 'provided' by it)
<rodarvus> but its hard to say whos at fault without more details
<keescook> I just did a straight debootstrap
<keescook> (but I'm on a Dapper system, trying to debootstrap an Edgy...)
<ogra> how ? 
<ogra> using the edgy debootsrap ? 
<ogra> *debootstrap
<rodarvus> might be an outdated mirror (linux-libc-dev was uploaded just a few days ago)
<keescook> I think so, ah...yes, I see what I did
<iwj> doko_: pong
<keescook> ogra: yeah, I think I pulled the edgy debootstrap.
<keescook> so I need to update it.  cool.
<doko_> iwj: if you care about FF, could you have a look at bug 61104? not sure if it's a troll ...
<Ubugtu> Malone bug 61104 in gcc-4.1 "Build process of firefox trunk is broken using gcc 4.1.1 with some "undefined reference" related to gcc bug #26905 ?" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61104
<iwj> doko_: What a pleasant submitter.
<mdz> keescook: sounds like you're using an old debootstrap
* iwj reads it in w3m to make it legible.
<keescook> mdz: yeah, though updating it didn't help.  s'okay, it worked in the past, I was just trying to have both and amd64 and i386 edgy.  I'll still amd64 edgy for the moment, as I have i386 edgy running okay
<keescook> s/still/skip/
<doko_> iwj: yeah, can't pull everything from fc, there must be an option to build without the -fvisibility options?
<iwj> doko_: We're not using some GCC prerelease, are we ?
<doko_> iwj: we do, but from the 4.1 branch; 4.2 isn't released yet.
<iwj> It seems to me that the submitter should get a workaround put into the firefox tree.  I assume that this bug is present in stock gcc 4.1 ?
<_ion> I posted a patch. https://launchpad.net/distros/ubuntu/+source/preload/+bug/62827
<Ubugtu> Malone bug 62827 in preload "parses /proc/N/maps incorrectly, renders whole program nonfunctional" [Undecided,Unconfirmed]  
<doko_> iwj: it's not in 4.1.0, but in 4.1.1
<iwj> doko_: That's lovely then, isn't it.  Will there be a 4.1.2 in time for edgy release ?  I assume not.
<iwj> Seems like just one of those things, really.
<doko_> iwj: no, but it won't be fixed in 4.1.2 at all, as jason explains
<ogra> hey, its edgy ... its supposed to have the latest cracks ... 
<ogra> or was it crack ?
<iwj> doko_: Err, I must have missed that.  As Jason explains where ?  (Jason who?)
<doko_> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
<Ubugtu> gcc.gnu.org bug 26905 in c++ "default-visibility class symbol improperly resolved as hidden-visibility" [Normal,Resolved: fixed]  
<iwj> Oh, yes, comment #6.
<doko_> heh, Ubugtu became more intelligent?
<iwj> Well, I think we should do nothing about this and tell the submitter `sorry'.
<iwj> If they want to go and use Fedora, fine.
<iwj> There seems from these transcripts to be some attempts to workaround this by mozilla people but not successfully.  Clearly their configure script is buggy.
<iwj> I think that's where the effort should go.  Having every distro randomly backport patches isn't the answer.
<iwj> doko_: Did you want anything more concrete out of me ?
<doko_> iwj: just knowing, if there's an option to build without the visibility stuff
<iwj> I don't know, I'm afraid.  I think that's what the configure script is probably trying to do.
<pitti> mdz: do you think bug 62542 is annoying enough to be fixed for edgy final? or rather edgy+1? it could be considered feature work and it would break the UI
<Ubugtu> Malone bug 62542 in apport "Apport should not do its expensive bits without user confirmation" [Low,Confirmed]  http://launchpad.net/bugs/62542
<pitti> mdz: I'm leaning towards edgy+1, but I'd like to collect some opinions
<mdz> pitti: I think that if it notifies the user that it's doing the work, it will be ok
<pitti> mdz: ok, so you want that update-notifier icon for edgy?
<mdz> pitti: also, I noticed ionice in schedutils which might be worth a look
<mdz> pitti: yes, I think we should do something for edgy.  the system gets very sluggish when it's running and the user can't tell why
<_ion> I agree.
<Treenaks> Stuff like firefox might look like it's frozen too... with white pieces on it from where you've moved windows
<pitti> mdz: so we can either move the sluggish parts into the frontend, or change u-n to display an icon/notification/whatever while apport is grinding
<Treenaks> that might look weird..
<pitti> mdz: we cannot do anything while the kernel dumps core, apport isn't yet called at that time (with the current kernel interface, this will get better in edgy+1)
<pitti> mdz: but the gdb and dpkg parts are the major culprits, and they could be done in the frontend, too
<mdz> pitti: firefox dumping core takes a long time
<pitti> (it's just a matter of moving collect_static_information() from apport to apport-gtk
<pitti> mdz: I agre
<pitti> e
<mdz> but if that's before apport is called, we can't do much for edgy
<pitti> mdz: but as I said, ATM the kernel dumps core and then calls apport
<pitti> right
<mdz> gdb and dpkg in the frontend would address bug 62542 as well
<Ubugtu> Malone bug 62542 in apport "Apport should not do its expensive bits without user confirmation" [Low,Confirmed]  http://launchpad.net/bugs/62542
<pitti> In Wiesbaden, BenC and I developed a better approach, but it's fairly different and not really appropriate to change at that time
<mdz> since you could easily only do them if the user wants to make a full report
<pitti> mdz: right, therefore my question whether you want to see it in edgy
<jdong> is gutenprint safe to backport to dapper?
<pitti> mdz: I can work on it today and tomorrow if desired (it's not intrusive, I just want to do a proper test suite check for it)
<mdz> pitti: I'm less concerned about that than about the visibility to the user, but it sounds like they could both be solved at once, so that's fine with me
<pitti> ok, great
* pitti adds an edgy tag
<pitti> ... milestone, rather
<BenC> pitti: So you want me to implement my end?
<pitti> BenC: I'd rather not for edgy
<pitti> BenC: it took enough time to get the current patch right :)
<pitti> BenC: I'll just move stuff within apport
<BenC> ok
<lucas> Riddell: any news on the ruby issue ?
<Riddell> lucas: on ppc?  it should all work now
<lucas> Riddell: was it uploaded ?!
<tkamppeter> Is there an Ubuntu development team meeting today?
<trappist> I'm subscribed to that bug but I don't remember seeing that update
<Riddell> lucas: no, the buildds were changed to have a different linux build on them
<lucas> oh, there are inconsistancies in the build logs
<lucas> Riddell: could you fix ruby1.9 too then ?
<seb128> tkamppeter: no, cf mail from Matt on the list
<lucas> "Checking for sin() in C library m... no" interesting build failure: http://librarian.launchpad.net/4537345/buildlog_ubuntu-edgy-i386.xmms2_0.2DrFeelgood-6_FAILEDTOBUILD.txt.gz
<lucas> (builds fine locally)
<Keybuk> lucas: building on ubuntu christian edition?
<tkamppeter> seb128: Which list, to which lists should I subscribe in general as Ubuntu developer? I have only communicated by IRC and personal e-mail up to now.
<lucas> Keybuk: non :)
<lucas> no
<lucas> why would I do that ?
<lucas> ahh
<lucas> :-)
<Keybuk> lucas: no sin in the C library
<Nafallo> lol
<lucas> I'll have to ask infinity ;)
<seb128> tkamppeter: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
<seb128> tkamppeter: it has been on the ubuntu-devel list too
<Seveas> Keybuk, LOL
<lucas> Keybuk: you should blog it
<seb128> tkamppeter: ubuntu-devel-announce has useful informations usually, discussions happen on ubuntu-devel (a good part of the discussions being user noise though)
<pitti> mdz: argh, that would mean that we would not get gdb and packaging information for system process crashes
<jdong> tkamppeter: do you keep track of gutenprint?
<pitti> mdz: however, it's still a good compromise for edgy then
<mdz> pitti: hmm
<mdz> pitti: if they know enough to file a crash dump without apport-gtk, they can probably choose the right package too ;-)
<pitti> hm, and we need to determine whether the program was packaged nevertheless
<mdz> but losing gdb is unfortunate
<pitti> mdz: it's not that unfortunate
<mdz> pitti: is gdb really that slow? can we continue to do gdb in the backend and dpkg in the frontend?
<tkamppeter> jdong: Yes, I am subscribed to the developer list of Gutenprint, but I have no Epson inkjet printer handy for tests.
<pitti> mdz: we can easily generate our own stacktrace with the core dump
<jdong> tkamppeter: I've got a backport request here for edgy gutenprint to dapper...
<pitti> mdz: in fact, that's what apport-retrace does
<jdong> tkamppeter: I know nothing about gutenprint, so I thought I'd get your expert opinion on whether or not that's a good idea
<pitti> mdz: but yes, I agree for the package
<pitti> mdz: I can also wrap this function into a 10-line CLI tool to add gdb and packaging information
<mdz> pitti: oh, we would still get a stack trace, just not decoded?
<mdz> if so, that would be ok
<pitti> mdz: *if* the user sends us a core, yes
<pitti> mdz: but for non-user processes, there is no apport-gtk offering to remove it anyway :)
<tkamppeter> jdong: It is probably a simple rebuild under Dapper, I have also always rebuilt all printing packages which I made on Mandriva 2007 also on 2006 because of Mandriva's Corporate server, and 2006 is 1 year old.
<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
<pitti> mdz: since non-user apport report submission is pretty much an advanced task for now, I think that's acceptable
<jdong> tkamppeter: it builds in a dapper builder, but I have no idea how to test it :)
<tkamppeter> Gutenprint has rebuilt there straight forward, only in CUPS 1.2.x I had to de-activate D-BUS.
<jdong> tkamppeter: I'll post the rebuilt debs back on the launchpad ticked and have the OP test it
<tkamppeter> Testing is easy: Install it, including the cupsys-driver-gutenprint package.
<slomo_> hm is there any reason why uploads still need manual accepting?
<tkamppeter> Hook an Epson inkjet (best solution) or at least some HP inkjet, older Canon inkjet, or an arbitrary PCL 3/4/5/5e laser.
<jdong> tkamppeter: I've got two printers; not enough data to determine if there are any potential regressions from dapper's version to edgy's
<tkamppeter> Jdong, should we wait for some week then to see how Edgy bug reports on the final Gutenprint develop? I think if a printer prints correctly under Edgy it should print correctly under Dapper with the same driver.
<jdong> tkamppeter: right; I'm considering keeping that bug report open for a bit longer
<tkamppeter> jdong, which model are your two printers?
<jdong> HP deskjet 722C, HP laserjet 5P
<tkamppeter> jdong: DJ 722C tests only pnm2ppa and not Gutenprint (does it print under Edgy?), LJ 5P is a test candidate for Gutenprint, but not for the color-correctness.
<tkamppeter> Anyone here who has a recent photo inkjet from Epson and a Dapper box?
<HiddenWolf> Can someone poke a fridge admin and put Edgy on?
<Seveas> HiddenWolf, #ubuntu-fridge
<HiddenWolf> doh
<zyga> hello
<pradeep> hi zyga 
<jdong> BenC: unusual_dev nudge? ;-)
<BenC> jdong: ok, thanks
<jdong> BenC: also, a while back I asked/filed about tifm21xx for Dapper... have you had a chance to see if there's any hope for that?
<tfheen> mdz: I got the list of mirrors on that announce from James
<BenC> jdong: not yet...probably be after release before I give dapper any love
<jdong> BenC: sounds good. edgy all the way!
<ajmitch> morning
<appelza> I know this isnt a support channel, but my question could possibly be a bug, as I have had no help with it in over a week of googling and #ubuntu chats
<appelza> My amd dual core opteron has ubuntu server 64bit installed, and only 2gb of its 4gb gets detected..its a tyan thunder board, and the smp k8 64bit kernel
<ijuz> appelza: is the memory working with other kernels?
<appelza> ive tried the smp and the normal 64bit-server kernel
<zyga> python2.4-doc is broken
<appelza> neither detect the full 4gb
<ijuz> appelza: can memtest86 see the memory? you may also try a new kernel
<appelza> which other kernels should I try? I havent done the memtest check
<jdong> appelza: try some 32-bit ubuntu's, try some other distro livecd's.... try to see if it's ubuntu-specific or amd64-specific or linux-specfic
<appelza> Ok, makes sense.  Thanks
<mdz> tfheen: right, that was the list of triggered mirrors.  they didn't all get the release in time though
<icecrash> hi
<tfheen> mdz: ok
<mdz> tfheen: how are you feeling?
<tfheen> mdz: I took a painkiller so I no longer feel the need to chop my head off, but I have a bit of a fever and such.
<tfheen> mdz: I suspect I won't be very effective tomorrow, though.  We'll see.
<mdz> tfheen: the only thing I need from you soonish is for you to review those process docs I emailed about; it's important to do that while it's fresh in your mind
<slomo_> mdz: will uploads be auto-accepted later again?
<geser> does somebody know why the Contents file for edgy doesn't get updated since 07-Jun-2006?
<tfheen> mdz: sure, I'll get to that tomorrow
<AlinuxSOS> Hello, mjg59 Ubuntu Edgy Beta is realised but https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 still remains a big problem for us (Georgian users). Sorry if I continue disturbing you...but I hope that you solve this problem before final realise. Thank You!
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]  
<AlinuxSOS> Hello, unifont package has a very crappy Georgian glyphs  https://launchpad.net/distros/ubuntu/+source/unifont/+bug/62849 Here is a bug + solution...maybe somone package it for me so I can test unifont package with georgian fonts ? Thank You.
<Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Fix committed]  
<lifeless> mdz: its still there in hiatus, I didn't have anyone specific to hand it off to, nor have I done more work on it.
<lifeless> mdz: we can hand it off to someone at UDS MV perhaps
<AlinuxSOS> people is there somone who maintains unifont pacakge ?
<AlinuxSOS> mdz, sorry for disturbing...maybe you can help me ?
<LaserJock> AlinuxSOS: I'm guessing that would be the Maintainer
<AlinuxSOS> LaserJock, who is unifont mantainer ?
<doko_> Keybuk, Kamion: wsdl4j and axis ping
<LaserJock> AlinuxSOS: https://launchpad.net/distros/ubuntu/+source/unifont/
<AlinuxSOS> LaserJock, so what do you suggest me ?
<AlinuxSOS> I've a solution for unifont, how can I commit it ?
<LaserJock> AlinuxSOS: is it a bug fix?
<icecrash> short question on configuration settings for apache2 suexec
<AlinuxSOS> yes, practically it's new redesigned glyphs for Georgian (ka) range.
<LaserJock> AlinuxSOS: then attach a patch
<LaserJock> to the bug report
<AlinuxSOS> https://launchpad.net/distros/ubuntu/+source/unifont/+bug/62849 maybe it's enough ?
<Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Fix committed]  
<icecrash> the compiled defaults in ubuntu version don't let reach you any cgi in apache's default cgi-folder /usr/lib/cgi-bin
<AlinuxSOS> but I don't know who the maintainer is...so I don't know to whom assign it.
<LaserJock> AlinuxSOS: don't assign it
<AlinuxSOS> ok
<bluefoxicy> ...
<bluefoxicy> most awesome idea ever.
<bluefoxicy> OK how does this sound, hypothetically
<icecrash> in debian bug #312252
<bluefoxicy> 1:  LiveCD is booted
<Ubugtu> Debian bug 312252 in thus "SuExec FHS compilance" [Normal,Open]  http://bugs.debian.org/312252
<mdz> AlinuxSOS: I'm sure we talked about this around the same time near the Dapper release, but you need to raise these issues earlier in the deveolpment cycle
<mdz> AlinuxSOS: don't wait for beta before testing Georgian
<bluefoxicy> 2:  LiveFS is mounted (compressed squashfs for Live environment)
<LaserJock> AlinuxSOS: on the left side of that bug report the Creator and Maintainer of the package
<mdz> AlinuxSOS: it makes it very difficult for us
<bluefoxicy> 3:  tmpfs is mounted
<LaserJock> AlinuxSOS: if you can attach a patch or debdiff that would also be helpful, I would guess
<bluefoxicy> 4:  LayerFS gets mounted with zlib encryption overtop the tmpfs; files written to the RAM-backed temporary file system will be compressed
<AlinuxSOS> mdz, it another issue, it'f for unifont, not ttf-bpg-georgian-fonts.
<icecrash> Ubugtu: only temp solution AP_DOC_ROOT=/ which makes security settings obsolete?
<mdz> AlinuxSOS: bug 62849
<Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Fix committed]  http://launchpad.net/bugs/62849
<bluefoxicy> 5:  Continue as normal, unionFS compressed tmpfs overtop LiveFS and pivoting root as needed
<mdz> AlinuxSOS: unifont hasn't changed since Dapper
<mdz> AlinuxSOS: neither has ttf-bpg-georgian-fonts
<AlinuxSOS> mdz, it's unifont. but 55966 Bug is not solved too.
<icecrash> ups bot
<AlinuxSOS> mdz, Edgy has for the first time Georgian range for georgian fonts.
<AlinuxSOS> so they are crappy and not proportional. So I provided a new, redesigned fonts.
<AlinuxSOS> 24 September I've mailed Matej Vela, about this... who told me that is better if I mail to: debian-user@lists.debian.org (solution included, I mean georgian glyps hex code), but still no answer or something similar.
<mdz> I don't know who Matej Vela is or why debian-user would be a good place to discuss it
<AlinuxSOS> mdz, mjg59 promised me a solution for ttf-bpg-georgian-fonts too, but there is no changes...Ubuntu Dapper or Edgy still contain an old 0.2 verison of pacakge.
<mdz> AlinuxSOS: I will make a deal with you
<AlinuxSOS> https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]  
<mdz> AlinuxSOS: I will help you to work on these problems
<mjg59> Fontconfig needs work to fix this
<mdz> AlinuxSOS: if you will commit to doing this before feature freeze next time
<AlinuxSOS> Arne Goetje, provided a solution, but it's not enough...
<mdz> AlinuxSOS: do we have a deal?
<mjg59> AlinuxSOS: Arne's config stuff is broken - it doesn't validate
<AlinuxSOS> mdz, you are developer and boss here..Matthew too is boss for me..So I must deal with you guys...
<mdz> AlinuxSOS: I don't think we're understanding each other
<AlinuxSOS> I'm really work a lot for creat Ubuntu's Georgian community...but as I'm not a programmer..I need some help...
<mdz> AlinuxSOS: Ubuntu uses a time-based release schedule, which means that certain work needs to be done on time
<mdz> AlinuxSOS: you can read more about this here: https://wiki.ubuntu.com/TimeBasedReleases
<mdz> AlinuxSOS: we are grateful for your help and would like to work together, but it is essential to consider this
<AlinuxSOS> mdz, I understand you, I'm sorry that all the time I disturbed Matthew too...
<mjg59> mdz: Strictly, this isn't a feature. We've got broken config parsing.
<AlinuxSOS> guys, the situation for Dapper or Edgy for Georgian users is critical... people installs http://packages.debian.org/unstable/x11/ttf-bpg-georgian-fonts 0.3 verison of pacakge...that is provided for Debian and not Ubuntu.
<mdz> mjg59: I agree
<mdz> mjg59: but testing can't wait until after beta
<mjg59> mdz: I discussed this with Keith Packard over the weekend. The correct behaviour is now implemented in fontconfig upstream
<mjg59> I'm looking at the extent of the code change now
<AlinuxSOS> Arne Gotje said to me that it's very difficuld to have something universal...so fontconfig can't be universal configuration...
<mdz> AlinuxSOS: that's why we implemented per-locale settings for fontconfig
<AlinuxSOS> I've searched a lot about this issue...I'm not really last minute this time..
<mjg59> mdz: They don't really work
<mdz> that would be unfortunate
<mjg59> mdz: At lesat, as far as I can tell. Where are they implemented? They're not mentioned in the fontconfig changelog
<mdz> mjg59: language-selector, /etc/fonts/language-selector.conf, all that jazz
<AlinuxSOS> I remmeber Dapper realise verison 0.2 of bpg font...that package was without fonts.config file...and I was really last minute, but now I've worked a lot(Font design, testing, best fontconfig searching,testing again..., bugging Matthew all the time!,searching other similar fonts with similar problem, finding Arnje Gotje...)that's my maximum, I've done a lot... and no results :/ I'm simply sad about it..I'm not angry or something simi
<AlinuxSOS> lar...I'm only a little bit sad.
<mdz> AlinuxSOS: it sounds like mjg59 has already been working on this.  what would you like for me to do?
<mjg59> mdz: Ah, I see. This is all a bit of a hack.
<mdz> mjg59: yes, it is.  but it's *our* hack!
<mjg59> mdz: Fontconfig supports doing this based on user locale
<AlinuxSOS> mdz, nothing just complaining... I'm really adore your job and the way of doing...but you should understand me...I'm simple mortal man :)
<AlinuxSOS> now I'm working with debian-translation :) + GNOME :D
<mdz> mjg59: not quite, that's why we have this hack
<mjg59> mdz: Upstream does. It was broken in the version we have.
<mdz> mjg59: I asked Keith about it at the time and he said that was not what it did, and not what it should do
<AlinuxSOS> I'm really multifuncitonal...and I should care about all :)
<mjg59> mdz: Ah. He appears to have changed his mind.
<mjg59> How irritating :)
<mjg59> Ok, let me see what I can do with this...
<AlinuxSOS> mjg59, if you need a tester for Georgian, I'm ready to help you !(If you need my help of course)
* mjg59 looks at fontconfig config files and loses the will to live. Again.
<mjg59> mdz: I still don't really understand this. language-selector.conf is empty.
* AlinuxSOS knows that he is a bad guy and he thanks Matthew, Matt and Ubuntu :D
<joejaxx> anyone know what the usbstick path is ?
<joejaxx> /media/usbstick?
<mjg59> joejaxx: /media/something
<mjg59> It'll depend on whether there's a label or not
<jdong> joejaxx: is that really a #ubuntu-devel question?
<joejaxx> mjg59: hmm
<joejaxx> jdong: oh sorry
<joejaxx> i though i was in *-offtopic
<joejaxx> sorry to disturb
<jdong> joejaxx: that's ok. I thought you were working your way towards a bug report or something :-)
<joejaxx> jdong: :)
<AlinuxSOS> mdz, https://launchpad.net/distros/ubuntu/+source/unifont/+bug/62849 are we still in time ?
<Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Fix committed]  
<mdz> AlinuxSOS: what do you want from me?
<AlinuxSOS> mdz, accepting a patch for Georgian range in hex for unifont.
<mdz> AlinuxSOS: that patch says that you received some glyphs from someone else and need to test them.
<mdz> AlinuxSOS: they need to be tested *before* being accepted, not after
<AlinuxSOS> mdz, my problem is that I need someone who could package them for me...afterwards I test..If there is errors I correct them and send a patch again.
<AlinuxSOS> but seems that unifont is orphan package :/
<mdz> AlinuxSOS: why do you believe that your bug has to do with unifont?
<mdz> AlinuxSOS: we already have a font for georgian, why not use that instead of unifont?
<AlinuxSOS> mdz, because it contains bitmap fonts, that we need for debian-installer
<AlinuxSOS> for debian-installer ?
<mdz> AlinuxSOS: you already marked your bug fixed
<crimsun> mdz: Hi, does the debdiff linked from bug 62855 look ok for dapper-updates? Jeff and I spoke earlier in -motu about it.
<Ubugtu> Malone bug 62855 in alsa-lib "Stereo line-in capture broken in alsa-lib 1.0.10 for "simple mixer" cards." [High,In progress]  http://launchpad.net/bugs/62855
<mdz> crimsun: please use the guidelines and process at http://wiki.ubuntu.com/StableReleaseUpdates
<crimsun> mdz: ok, thanks
<mjg59> mdz: Do we have docs for the langpack/fontconfig integration anywhere?
<mdz> mjg59: I doubt it; mvo would be the authority on the language-selector bits
<AlinuxSOS> we already have a font for georgian, why not use that instead of unifont? Which one ?You mean bpg font ?
<mjg59> Ahhhhhhhhhhhhhh
<mjg59> I see
<mjg59> Right, I can do this
<AlinuxSOS> mdz, http://img353.imageshack.us/my.php?image=scr3la3.png  I mean this font. And if it's not unifont...so which package provides that horrible glyphs ? (It's not bpg fonts 100% sure)
<mdz> AlinuxSOS: which ones are horrible?  I can't tell
<AlinuxSOS> mdz, :)just trust me, I know how georgian font must be.
<AlinuxSOS>  letter "e" is too long :)
<mdz> AlinuxSOS: that is a screenshot of gfxboot
<AlinuxSOS> 1.  
<mdz> AlinuxSOS: gfxboot gets its fonts from the theme
<mdz> AlinuxSOS: the theme gets them from X
<AlinuxSOS> mdz, yes... so I need to know which font is used for gfxboot ?
<mdz> (usually)
<AlinuxSOS> it's bitmap font, unifont contains bitmap fonts. BPG fonts are .ttf type...so gfxboot dosen't use them.
<mjg59> mdz: Ok, this actually ought to be trivial to fix (at least, to the extent that it's fixed in Chinese, for instance)
<mjg59> mdz: Needs one file adding to language-selector-common
<mdz> AlinuxSOS: the gfxboot theme, when it is built, looks for an X font which matches certain characteristics
<mdz> AlinuxSOS: and converts it into the format it needs
<AlinuxSOS> so I don't really know origin of this font.
<mdz>         getx11font -v -l 18 -p 2,4 \
<mdz>         -c ISO-8859-15 -c ISO-8859-2 -c koi8-r \
<mdz>         `$(KEYMAPCHARS) keytables.inc` \
<mdz>         -t tmp.txt \
<mdz>         -t install/log -t boot/log \
<mdz>         -t langlist -t langnames.inc \
<mdz>         -f -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1 \
<mdz>         --fsize 16,5 \
<mdz> like so
<AlinuxSOS> unifont-medum? 
<AlinuxSOS> gnu-unifont!
<mdz> AlinuxSOS: !
<AlinuxSOS> What because I said It
<AlinuxSOS> <mdz> AlinuxSOS: why do you believe that your bug has to do with unifont?
<mdz> AlinuxSOS: will you answer the question now?
<mdz> AlinuxSOS: someone told you to look at unifont, and it wasn't me
<AlinuxSOS> mdz, which question sorry me ?
<AlinuxSOS> mdz, yes It was Kamion or CollinWatson :) but I'm not sure...
<AlinuxSOS> not you of course :)
<givre> Kamion, others : nobody to accept ntfs-3g ? it's still in new
<mdz> givre: tomorrow is archive day
<mdz> givre: Kamion's day, if I'm not mistaken
<mdz> givre: he does it on Fridays, Keybuk on Tuesdays
<givre> mdz: ok, thanks for the info
<AlinuxSOS> who packages unifont for ubuntu ?
<mdz> AlinuxSOS: no one. we use the unifont package from Debian
<mdz> AlinuxSOS: which, as you've learned, is unmaintained
<AlinuxSOS> mdz, and how can I submit my glyps range for Georgian ?
<AlinuxSOS> test & realise.
<mdz> AlinuxSOS: I think you mean the word "release" when you say "realise"
<AlinuxSOS> I don't know howto build a .deb :( Or howto repackage unifont with new fonts ?
<mdz> AlinuxSOS: there are a couple of things you could do
<AlinuxSOS> mdz, ? what things ? :/
<mdz> AlinuxSOS: one would be to work with the upstream maintainer of unifont, the other would be to work with a Debian or Ubuntu developer
<mdz> AlinuxSOS: you could also learn how to modify and build the package
<AlinuxSOS> mdz, is it difficult to buld a unifont package ?
<mjg59> AlinuxSOS: If I show you a screenshot, can you tell me whether the right fonts are being used?
<mdz> AlinuxSOS: it looks like a pretty simple package
<AlinuxSOS> I can collaborate with people...I need only someone who realises testing verison..and afterwards I confirm a final .deb without errors.
<AlinuxSOS> mdz, simple :) for you! :D
<AlinuxSOS> mjg59, right fonts ?
<mjg59> AlinuxSOS: Does http://www.codon.org.uk/~mjg59/tmp/georgian.png look right to you?
<AlinuxSOS> What do you mean ? (sorry my English is not perfect)
<AlinuxSOS> mjg59, just a moment.
<mdz> AlinuxSOS: what is Gia Shervashidze's email address?
<AlinuxSOS> mdz, yes great.
<mjg59> AlinuxSOS: Was that to me?
<mdz> AlinuxSOS: yes great is not a valid email address
<mjg59> mdz: Mixed up nicks, I think
<AlinuxSOS> mdz, Gia Shervashidze <giasher@telenet.ge>
<mjg59> mdz: Ok. Can I add one file to language-selector-common ?
<AlinuxSOS> mjg59, which file ? BPG font 0.3 ?
<mjg59> It's just a fontconfig fragment that instructs it to use the correct fonts in the ka_GE locale
<mjg59> Like the existing zh_CN and so on
<AlinuxSOS> http://www.codon.org.uk/~mjg59/tmp/georgian.png For me it's super! 
<AlinuxSOS> It's a solution that I so desire...
<mdz> AlinuxSOS: so if I gave you a .deb of unifont, you could test it?
<AlinuxSOS> mdz, yes of course
<mdz> AlinuxSOS: how?  does something other than gfxboot use it?
<AlinuxSOS> mdz, in terminal mode, when I doo ctrl + alt + F1 system goes in terminal mode..I've text file with entire alphabet and text.
<mjg59> AlinuxSOS: That's not likely to be the same font
<mdz> AlinuxSOS: your console uses unifont?
<mdz> that seems unlikely since it is an X font
<AlinuxSOS> mdz, gnome-terminal uses fixed width font,courier like. but in terminal(non X)it uses that crappy georgian font...that you see on gfxboot
<mjg59> mdz: Can you take a look at http://www.codon.org.uk/~mjg59/tmp/language-selector.debdiff ?
<mdz> AlinuxSOS: perhaps it uses a font which looks very similar
<mjg59> AlinuxSOS: It's likely that they're the same glyphs but from different files
<mjg59> The terminal doesn't accept X fonts directly
<mdz> AlinuxSOS: I don't see how you can test this unless someone builds a CD for you, which is a lot of work
<AlinuxSOS> mdz, no I recorgines them because I've worked a lot with BPG font designer.
<AlinuxSOS> mdz I think that I we correct unifont we correct everything..because in terminal mode there is the same font.
<mdz> AlinuxSOS: I am highly confident that if I give you a unifont .deb and you install it, your console font will not change.
<AlinuxSOS> mdz, I can test it right now...
<mdz> AlinuxSOS: if you would like to see who is right: http://people.ubuntu.com/~mdz/temp/unifont_1.0-3ubuntu1_all.deb
<AlinuxSOS> I install unifont and restart system.
<mdz> I will wait with bated breath
<AlinuxSOS> mdz, ;)
<mjg59> mdz: That language-selector change should fix the issue for Georgian, though I may need to add a couple of fonts to the ttf-bpg-georgian-fonts package for full effect
<mjg59> Either way, I think they're correct - it mimics the config that people have been setting up manually and has no effect on non-Georgian setups
<mdz> mjg59: I am not familiar with that stuff to judge at a glance whether it is correct, but it seems perfectly reasonable
<mjg59> mdz: The code will only be used if Georgian is selected by language selector
<mjg59> So the very worst it could do would be to have no effect, and the likely cause is that Georgian users stop complaining that their fonts look bad :)
<mdz> mjg59: I think we have only one georgian user and he is very noisy
<mjg59> mdz: No, I've got reports from at least two more
<mjg59> Any objection to me uploading that, in any case?
<mdz> mjg59: are they any more personable?
<mdz> mjg59: if you tested it and it did what you expected, it's ok with me
<mjg59> mdz: Ok. Doing so now.
<mc44> its harder for people whos first language isnt English :p
* mjg59 looks forward to getting back to fonts that don't suck at 6 points
<mjg59> Right, uploaded
<AlinuxOS> mdz, there is still that crappy font :(
<mdz> AlinuxOS: !
<mjg59> AlinuxOS: As mdz said, it's unlikely that an X font will make any difference on the Linux console
<AlinuxOS> you think that it's some BPG's font bitmap deformation ?
<mdz> AlinuxOS: no, it is exactly as I said before. they are two  different fonts.
<mjg59> mdz: Oh, hm, one problem.
<AlinuxOS> it really looks so crappy.
<mjg59> mdz: The language-selector.conf link doesn't seem to get regenerated on reconfigure.
<mjg59> Argh, fontconfig-voodoo
<mjg59> What could possibly go wrong
<AlinuxOS> mdz, I should investigate about that differen font...In Dapper there was white cubes instead of letters.
<AlinuxOS> I think it somewhere here: /usr/share/fonts/X11/misc
<mjg59> AlinuxOS: No
<mjg59> AlinuxOS: X fonts are not used for the console
<AlinuxOS> and where is console fonts location ?
<AlinuxOS> I'll start remove one-per-one before I get white cubes...
<AlinuxOS> so maybe I can find that crappy thing...
<mdz> AlinuxOS: is your goal to fix the console or to fix the CD boot screen?
<mjg59> mdz: I believe that fontconfig-voodoo has behaviour that is less than optimal
<mjg59> mdz: In that it won't replace a link to /usr/share/language-selector/fontconfig/none even if there's now a locale-specific entry available
<AlinuxOS> mdz, both (because they are the same font). I'l show you debian-installer portion.
<mjg59> AlinuxOS: They are *not* the same font
<mjg59> AlinuxOS: gfxboot comes from an X font. The console comes from a console font.
<AlinuxOS> mjg59, not the same physically...but the same design...
<mjg59> AlinuxOS: They may look the same, but that doesn't mean that they're in the same package
<mjg59> AlinuxOS: Right. The fact that they're the same design is entirely irrelevent
<AlinuxOS> mjg59, exaclty I mean that design is the same..but not package.
<mjg59> AlinuxOS: So they're not the same font
<mdz> AlinuxOS: I've spent over an hour trying to help you, but you won't listen to me
<mdz> AlinuxOS: I'm going to have to get back to my work shortly
<mjg59> crimsun: Uh, did you mean to send that to mdz rather than me?
<mjg59> mdz: The stuff I've uploaded should make this work for new installs, but not for updates. I'll talk to mvo about the best way to deal with that.
<mjg59> It involves Python, so I'm not going to try to fix it myself
<mdz> mjg59: would be a good plan to file a bug for him
<crimsun> mjg59: er?
<mjg59> mdz: Yeah, doing that now
<mjg59> crimsun: Oh, erm. Who did you mail your SRU to?
<mjg59> Oh, it's from Launchpad
<mjg59> Never mind
<mdz> mjg59: will the X server reread its font directories to pick up new fonts, or does it need a restart?
<AlinuxOS> mdz, http://img181.imageshack.us/my.php?image=debianinstalleryk5.png see here
<mjg59> mdz: fontconfig should deal
<AlinuxOS> it's the same:  ...letter "" is the same (other letter too) of gfxboot.
<mjg59> AlinuxOS: They are *not* the same font
<AlinuxOS> mjg59, yes I understand :)
<mjg59> AlinuxOS: So showing us that they're both broken doesn't help
<AlinuxOS> mjg59, yes they are broken in the same way..they have the same design.
<mjg59> AlinuxOS: Yes. We know that. That doesn't help us fix them in any way.
<mdz> mjg59: xset fp rehash is what I want, but it doesn't work
<mdz> it seems to bail out because some of the font path elements don't exist
<mdz> what a piece of junk
<mjg59> mdz: xset fp rehash will only work with X core fonts
<AlinuxOS> mjg59, so I must find both. Console one and Menu font too...cause both fonts need the same correction.
<mjg59> mdz: We don't even get our bitmap fonts from there now, unless you're using a legacy application
<mdz> mjg59: like xterm?
<mjg59> mdz: Yeah
<mdz> mjg59: that's the only way I can see to access this font
<mdz> it doesn't use defoma or any of that jazz
<dholbach> good night
<mjg59> mdz: dpkg-reconfigure -plow fontconfig and enable bitmap fonts
<mdz> it just drops it in an X font dir and runs mkfontdir
#ubuntu-devel 2006-09-29
<jdub> morning boys and girls
<jdub> and mdz
<mjg59> Oh, possibly not fontconfig
* mjg59 tries to figure out which damned package it is
<Nafallo> morning jdub :-)
<dholbach> hey jdub
<AlinuxOS> hm...great xterm shows the same console font :)
<mjg59> AlinuxOS: No, that's the X one
<mjg59> Probably unifont
<mjg59> AlinuxOS: Ok. Once the new language-selector package hits daily CDs, the install should leave the correct font configuration
<AlinuxOS> mjg59, ok so I purge unifont and restart X.
<mjg59> AlinuxOS: It currently won't work for upgrades, but I'll get that fixed before release
<mdz> AlinuxOS: where can I download that text file you use for testing?
<AlinuxOS> mdz just a sec.
<mjg59> mdz: Ah! dpkg-reconfigure -plow fontconfig-config
* Nafallo sees config x3 :-P
<mjg59> That should make unifont available to fontconfig apps
* mjg59 switches his system back to English...
<AlinuxOS> https://launchpad.net/distros/ubuntu/+source/unifont/+bug/62849
<Ubugtu> Malone bug 62849 in unifont "Georgian (ka) letters are very crappy!" [Undecided,Unconfirmed]  
<AlinuxOS> mdz, I've attached that text file.
<jdub> dholbach: you guys totally have to figure out how to get to lca
<dholbach> jdub: i hope you tell me once you know how we get there :)
<mjg59> dput needs an option that checks my distribution line
<AlinuxOS> mjg59, so you've fixed my Georgian issue ? :)
<mjg59> AlinuxOS: For new installs, once the package is on the images
<mdz> AlinuxOS: http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png http://people.ubuntu.com/~mdz/temp/Screenshot-xterm-1.png
<ajmitch> hey jdub 
<mjg59> mdz: The second is 403
<AlinuxOS> so there will be new ttf-bpg-georgian-fonts version 0.3 ?
<mdz> fixed
<mjg59> AlinuxOS: Yes, but that's not what fixed it
<AlinuxOS> http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png THIS ONE IS SUPER!
<jdub> morning ajmitch 
<AlinuxOS> mdz, it's really great.
<zul> hey ajmitch 
<ajmitch> hi zul :)
<AlinuxOS> mjg59, I suppose you will use the same fonts that in 0.3 for Debian right ? http://packages.debian.org/unstable/x11/ttf-bpg-georgian-fonts
<AlinuxOS> because 0.2contains old(some malformed fonts).
<mjg59> AlinuxOS: Yes
<AlinuxOS> great ;)
* AlinuxOS *hugs* strongly mjg59 
<AlinuxOS> ;)
<AlinuxOS> mdz, http://people.ubuntu.com/~mdz/temp/Screenshot-xterm.png fonts on this screenshot are really very smart. 
<AlinuxOS> mdz, some improvements ? Or important decisions for unifont (or maybe for that misterious font)?
* AlinuxOS is very happy that Ubuntu becomes the first Linux distribution with smart Georgian support ;)
<sabdfl> i get asked two questions about keyboard layout on upgrade, is that unavoidable?
<sabdfl> am using aptitude to upgrade dapper to edgy, this was on kubuntu but iirc i saw the same on ubuntu
<sabdfl> just thought back then that it would not happen at beta
<Gman> sabdfl, http://thomas.apestaart.org/log/?p=409 ?
<jdub> Gman: debconf questions
<Gman> ah
<jdub> Gman: not X breakage :)
* desrt always wondered about that dialog
<desrt> isn't the entire purpose of the gnome keyboard settings to allow you to have different settings than the X defaults?
<sabdfl> hey hey jdub
<Nafallo> are there any reason edgy is still frozen? :-)
* Nafallo caught the buildds idling ;-)
<jdub> sabdfl: morning
<bluefoxicy> Mem:    970640k total,   959848k used,    10792k free,      372k buffers
<bluefoxicy> Swap:  2104472k total,   284616k used,  1819856k free,   741836k cached
<bluefoxicy> ok, my kernel is EXTREMELY prefering to devote about 75% of my memory to disk cache and push a lot to swap, wtf?
<bluefoxicy> holy crap, I swapoff -a; swapon -a and it immediately put 36 megs back in swap, with 500 megs of disk cache O_o
<gnomefreak> did the beta get released?
<Nafallo> gnomefreak: yes
<gnomefreak> .me used daily build
<Nafallo> mjg59: hi! reading bug #22336
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  http://launchpad.net/bugs/22336
<Nafallo> mjg59: seems I don't have anything at all in /proc/acpi/thermal_zone/ :-P
<Nafallo> mjg59: is that normal on current edgy, or has something changed somewhere?
<AlinuxOS> mjg59, mdz Thank you and goodnight !
<mjg59> Nafallo: Do you have any reason to believe you /should/ have something in thermal_zone?
<Nafallo> mjg59: the other guys on the bug report has? :-)
<Fujitsu> mjg59, Xorg's i810 is replaced by intel now, is it?
<tseng> Fujitsu: i dont believe that is the case
<Nafallo> mjg59: and since it seems I got that problem (workaround by using cpu_governor powersave) I though I might want to have something in there ;-)
<Fujitsu> It says `X.Org X server -- Intel i8xx, i9xx display driver'
<tseng> there is still the i810 is what video-all depends on
<tseng> for now
<mjg59> Fujitsu: No
<mjg59> Nafallo: Not all machines expose anything
<mjg59> If you did in previous versions and don't now, then maybe
<Nafallo> mjg59: ah, oki. haven't checked before actually :-).
<redcard> Okay.  I'll ask here.  I went Dapper->Edgy Beta , and it held back all the X stuff.  All of it.  X is symlinked to /bin/true.  What I need to do is remove all held packages.  How?
<redcard> Or rather, the held status on all held packages.  
<Nafallo> woha! someone opened up the archive again :-)
<Nafallo> ehm, nm. I think it was just delayed mails finding there way home.
<jdong> Nafallo: not all laptops expose their thermal_zones
<jdong> Nafallo: some are purely bios/hardware-controlled
<jdong> (which frankly I like... less can go wrong in the buggy kernel department)
<Nafallo> hm, maybe turning off powernowd and use only ondemand works for me then...
<jdong> Nafallo: you still running dapper then?
<Nafallo> edgy
<jdong> Nafallo: then you should be using ondemand already...
<Nafallo> seems just removing powernowd might do it :-P
<jdong> Nafallo: if you have a reasonably mobile processor, powernowd passes control over to ondemand automagically
<Nafallo> yea, but if it's not needed I might as well remove it :-)
<jdong> Nafallo: absolutely. it saves an entire 300KB of valuable disk space :)
<Nafallo> :-)
<Nafallo> call me a minimalist if you like ;-). I don't like to have unused stuff installed :-P
* jdong notes that anticipatory IO scheduler is doing better than CFQ on his laptop
<jdong> I guess the slower seek rate makes the difference, as CFQ is a winner on my desktop
<jdong> Kamion: ping
<bluefoxicy> jdong:  did you see my mention of LiveCD magics earlier?
<jdong> bluefoxicy: no, i didn't
<bluefoxicy> jdong:  I'm hoping the layerfs guy will release under LGPL (he's expressed interest in this but didn't know if he had to register somewhere or something) for compressed file systems; but I'm thinking, tmpfs -> layerfs -> compressed ram-backed mount point -> unionfs
<orphennui> hi
<bluefoxicy> jdong:  that would basically make all the changes written into the tmpfs on the LiveCD compressed, saving RAM space; though I'm not entirely sure how much memory that accounts for normally
<jdong> bluefoxicy: that sounds cool
<orphennui> i'm getting a report that Gimmie no longer works on ubuntu for some reason.  I haven't seen a bug about this.  Does anyone know what's up?
<bluefoxicy> It'd be cool yes; if you use 2M of memory, you're suddenly using 0.8-1.2M (zlib compression)
<bluefoxicy> but that's not really that great
<Nafallo> jdong: how do I set which one of them to use? (disc-scheduler)
<jdong> Nafallo: /sys/block/<device>/queue/scheduler
<bluefoxicy> now if we're talking about 10 or 20 megs typically THAT'S interesting... any idea what it takes just to boot and get to desktop?  What it takes to run Ubiquity (does it create temporary files)?
<jdong> Nafallo: or system-wide default with kernel parameter elevator={as,cfq,deadline}
<Nafallo> jdong: cating that gives me four of them, with []  around cfq. I can just echo with one of the others? :-)
<jdong> Nafallo: right, echo one of them to set it
<Nafallo> ah, oki. thanks.
<Nafallo> nice :-)
<jdong> Nafallo: anticipatory will reduce disk seeking, which should increase overall throughput, but could decrease multitasking responsiveness
<jdong> Nafallo: so it's appropriate for when you need to keep up streams of disk IO (i.e. cd/dvd burning, file server), but not appropriate for watching your divx'es while performing backups :D
<Nafallo> jdong: :-)
<jdong> Nafallo: booting a livecd with elevator=as makes it much more responsive while ubiquity grinds away
<Nafallo> I should probably use cfq then ;-)
<jdong> (which was why I was trying to ping mr. ubiquity)
<imbrandon> mdz, ping 
<imbrandon> mdz, unping
<pygi> night all
<ajmitch> night pygi 
<imbrandon> night pygi 
<imbrandon> ugh late
* Nafallo > bed, gnight
<imbrandon> later Nafallo
* bluefoxicy notes on an old spec the availability of FUSE-based UnionFS drivers as possible alternatives to in-kernel unionfs
<jdong|amd64> mjg59: ping
<mjg59> jdong|amd64: Hi
<jdong|amd64> mjg59: just to say I'm on a system where I can reproduce bug 56587; wondering if you need any additional info
<Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Confirmed]  http://launchpad.net/bugs/56587
<jdong|amd64> mjg59: bzr revno 90 still crashes
<mjg59> jdong|amd64: Uh. Last night you said it didn't.
<jdong|amd64> mjg59: this is a new bug; the amd64+nvidia one?
<jdong|amd64> mjg59: ati is all happy :)
<mjg59> Sigh.
<mjg59> Right. Could you get me a backtrace?
<jdong|amd64> mjg59: I got an apport bundle-of-joy attached, with debugging symbols
<jdong|amd64> http://librarian.launchpad.net/4540718/_sbin_usplash.0.crash
<mjg59> Hrmph.
<mjg59> Jesus x86emu is a piece of shit
<mjg59> Ok
<jdong|amd64> I'll bbl; let me know if you need any more info
<jdong|amd64> my amd64 box is now happily edgy :)
<mjg59> I'm going to upload what I have now and then work on this later on
<mdz> slomo_: f-spot spins on me at the import dialog if I try to import a large number of photos at once; ever seen that before?
<ajmitch> mdz: that's known
<mdz> ajmitch: is it an f-spot problem or a mono problem?
<ajmitch> f-spot problem
<ajmitch> it's not doing the import asynchronously
<Fujitsu> Hahah.
<ajmitch> Fujitsu: sorry?
<Fujitsu> It's importing everything synchronously?
<Fujitsu> 'cause that's quite a nasty mistake.
<ajmitch> something I had to track down, I'm sure it used to be better behaved
<sbalneav> Evening all
<ajmitch> hi sbalneav 
<mjg59> Dear apport:
<mjg59> Why does running apt-get source xserver-xorg-core result in apt crashing and you consuming all my CPU?
<mjg59> Ah, apt-get update has made things work
<infinity> I turned off apport for that reason.
<infinity> I was pretty miffed when I was debugging a segv in a 50-line C snippet, and it was taking longer for the thing to segv than it was to compile it.
<infinity> (much longer)
<infinity> I have a feeling this feature was not really aimed at developers. :)
<infinity> Of course, now you get to laugh at me for admitting that I had to look more than once to find the segv in 50 lines of C, but in my defense, it was late and my eyes were crossed.
<imbrandon> lol infinity ;P 
<imbrandon> happens to us all ;)
* imbrandon hopes * lol
<mjg59> Oh, now, wait a second
<mjg59> apport just *killed my gdb*
<mjg59> I am, shall we say, unamused
<Fujitsu> apport seems to like doing nasty things like that.
<nixternal> any ideas on fixing the "creating/updating hplip user" error?
<fabbione> morning guys
<ajmitch> hi fabbione 
<netdur> there is one feature I wanna request, but I don't know who to ask... GNOME's bugzilla or launchpad
<netdur> I want menu (main menu, menu bar) to add "run as administrator" option
<LaserJock> I would guess Gnome would be a good place for it
<netdur> LaserJock, thanks
<|thunder> wassup all.
<|thunder> ive found a bug in gconf
<|thunder> seems to be in both 32 and 64 bit ubuntu's
<|thunder> there are a few settngs that are set to integer, they should be string, yet I cannot change them as the conbobox to do so is grey'd out.
<|thunder> help
<LaserJock> |thunder: please search http://launchpad.net/distros/ubuntu/+bugs for a bug report about it
<LaserJock> |thunder: and if you can't find one please file one
<|thunder> thanks
<pitti> Good morning
<ajmitch> morning pitti :)
<pitti> hey ajmitch
<realist> Good evening :-)
<Burgundavia> hey pitti, ajmitch
<ajmitch> hi Burgundavia, how's it going?
<Burgundavia> not bad
<imbrandon> moins pitti and Burgundavia
<pitti> hey imbrandon
<Keybuk> they should so re-label the left control key to be just "Wake Up"
<imbrandon> lol Keybuk 
<Keybuk> ok
<Keybuk> I am -> <- this close to upgrading my desktop edgy
<Keybuk> the buggy-as-shit e-d-s in dapper is annoying the hell out of me
<Keybuk> admittedly, it may not be better in edgy, but still
<Fujitsu> e-d-s?
<HrdwrBoB> evolution data server
<Fujitsu> Ah.
<Fujitsu> And what is this key dev doing running Dapper, when all the not-so-almight ones are running Edgy? :P
<Fujitsu> *almighty
<HrdwrBoB> because you want a stable platform as a desktop
<Fujitsu> Probably, yeah.
<HrdwrBoB> then you have development environments
* StevenK runs his desktop on Dapper, with two Edgy chroots.
<imbrandon> Keybuk: well beta is as good as time as any to switch
* StevenK is plotting to upgrade his laptop to Edgy in the next few days.
<imbrandon> i kept dapper on this laptop untill the other day, and an edgy dev machine for building etc
<Keybuk> Fujitsu: I always run the stable release on my desktop, so I can always get work done
<Keybuk> I can do builds and testing in a chroot
<Fujitsu> Keybuk, but it's no fun having a working system :P
<Keybuk> and I always run the development release on my laptop, and make sure that any files are backed up, so I can wipe it and reinstall it at any time without remorse
<imbrandon> Keybuk: backport e-d-s ( atleaste for yourself ) ?!?
<realist> Is there an Ubuntu equivalent to debootstrap?
<Fujitsu> realist, debootstrap
<infinity> realist: Yes, debootstrap
<Keybuk> imbrandon: that'd involve backporting evolution, and gnome, etc.
<imbrandon> realist: debootstrap
<Keybuk> and backports are for children
<imbrandon> true
<Keybuk> it always seems to be calendar related
<Keybuk> I can't switch to the calendar in evo, and clicking on the clock makes it hang
<infinity> Keybuk: Those bits seem much-improved in edgy.
<infinity> Keybuk: Much more responsive anyway, I never did have them outright hang on me in dapper.
<Fujitsu> You're right, it's less laggy in Edgy.
<janimo> infinity, Kamion: hi, can either of you push yesterdays xubuntu isos as betas or should I wait for tollef?
<infinity> janimo: I'd prefer not to push the publish-release button, since this was Tollef and Colin's show.  One or both of them should be around soon, though.
<janimo> infinity: ok thanks
<Keybuk> infinity: the only other vaguely useful thing is that sometimes, after killing it, it disables my web calendars
<Keybuk> so I've wondered if it's unable to deal with them not being available sometime
<HrdwrBoB> ah. gg nautilus. 75% icons are HUGE, bigger than 100%
<Keybuk> yay beta
<Keybuk> *sigh*
<Keybuk> "upstart doesn't load fuse module" ... "upstart doesn't display splash screen in correct colours" ... "upstart spilled my coffee"
<Fujitsu> Hehehe.
<Fujitsu> This is what we get when we rejig the world.
<HrdwrBoB> "upstart stole my baby"
<Keybuk> it amuses me that people always file bugs on the one thing they know that changed
<imbrandon> hahah sooo true
<Keybuk> "I upgraded from dapper to edgy beta, and clearly upstart was the ONLY THING THAT CHANGED"
<ajmitch> heh
* ajmitch saw one or two of those bugs yesterday
<pitti> Keybuk: well, that and the splash screen
<Keybuk> "upstart causes my network card to be not listed in network-manager"
<Keybuk> W.T.F.?!
<Fujitsu> Keybuk, that's your fault. Obviously.
* realist blinks.
<HiddenWolf> Doh
<realist> upstart being the init replacement, right?
<Fujitsu> realist, yeah.
<imbrandon> realist, yea
<realist> Ahh well, they're only trying to help *smirk*
<ajmitch> ah yes, bug 62862
<Ubugtu> Malone bug 62862 in network-manager "Atheros w-lan card doesn`t work on edgy live!" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62862
<Keybuk> [Bug 62872]  Upstart doesn't start Avahi
<Ubugtu> Malone bug 62872 in upstart "Upstart doesn't start Avahi" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62872
<Keybuk> yes, could that be that Avahi is DISABLED?
<Fujitsu> Keybuk, upstart (and thus you) is personally responsible for every single regression.
<Fujitsu> hahah
<ajmitch> it makes you wish for a mass-reassign button in launchpad
<Fujitsu> Keybuk, we love our users.
* HiddenWolf gives Keybuk an "techsupport" badge
* imbrandon gives Keybuk a "but-we-love-you-badge" and a big reject button
<Fujitsu> Can't LP grow a tool which allows us to electrocute the person on the other end?
<ajmitch> think of all the karma you can get by rejecting these
* Fujitsu starts whistling:
<Fujitsu> `Always look on the bright side of completely loony bug reports.'
<Keybuk> I don't think you get karma by rejecting bugs?
<Fujitsu> Keybuk, I think you do...
<realist> How is karma accrued?
<imbrandon> i think you do
<Fujitsu> realist, by doing stuff :)
* Keybuk beats his head against the wall
<Keybuk> At some point during Edge development cycle, booting has become
<Keybuk> extremely slow. It takes almost three minutes from grub until X starts.
<imbrandon> realist, clicking stuff on LP
<Keybuk> This is on AMD64 running the latest everything.
<Fujitsu> Keybuk, I'd think you would.
<Keybuk> of course, this is an upstart bug
<ajmitch> Keybuk: very technical description there
<Fujitsu> Keybuk, naturally.
* Keybuk bets lots and lots of money that the guy has an nvidia motherboard, and it's the usplash spinning bug
* Fujitsu steals Keybuk's money.
* Fujitsu runs away.
* ajmitch still hasn't rebooted his amd64 with upstart
* Fujitsu uses it to fund a bug-triager.
<Keybuk> oh look
<Keybuk> he has his dmesg attached
<Keybuk> and oh look
<Keybuk> it's an nvidia motherboard
<imbrandon> haha
<imbrandon> Keybuk, you had some coffee^Wtea^Wmt dew yet today ?
<Fujitsu> Keybuk, have you considered writing a quick script to go through all the upstart bugs, reassign them to some other random package, and wait for people to assign the bugs that are actually upstart's fault back to upstart?
* imbrandon slides a guinness to Keybuk, LP will look much better through the bottom of that mug , promis
<Fujitsu> I think that'd work quite well :P
<infinity> Keybuk: The really curious question is, if he thought it was a bug in init, why did he bother including dmesg? :P
<Keybuk> imbrandon: can't stand guiness
<imbrandon> whoop
<ajmitch> Keybuk: interesting, what is this usplash bug?
<infinity> Keybuk: Sketchy interaction with svgalib and some nvidia chipsets, apparently.
<rideout> So, somehow I borked all of python on my edgy system and have pulled out my hair for an hour trying to fix it
<ajmitch> infinity: great, so I should hit it on reboot if I'm lucky
<infinity> ajmitch: You have a curious definition of the word "luck".
<Keybuk> infinity: so I understand
<Fujitsu> infinity, he /is/ an NZer.
* Fujitsu ducks.
<Keybuk> ajmitch: if you do, make sure you have bootchart intalled
<ajmitch> hence why I don't reboot this box if I can help it
<ajmitch> Keybuk: will do
<Keybuk> rideout: upstart bug <g>
<Keybuk> ajmitch: helps prove the bug
<Fujitsu> Keybuk, no, upstart. I can assure you.
<rideout> Keybuk: seriously or joking?
<Keybuk> rideout: joking
<imbrandon> heh
<rideout> somehow the modules can't be found when any python program uses "import"
<rideout> but there there, and update-python-modules seems to be working
<HiddenWolf> Fujitsu: no, you can't shock people for filing bad bugs, that'd be bad karma.
<Fujitsu> HiddenWolf, electrocuting people vs. gaining karma... Hm...
<HiddenWolf> Fujitsu: you don't want bad karma, you want good karma. ;)
<rideout> any thoughts?
<lastnode> imbrandon, ping
<dholbach> good morning
<ajmitch> morning dholbach :)
<dholbach> hey ajmitch
* sivang has to go again, be back in a bunch
<ajmitch> Keybuk: your upstart branch appears to miss an nih directory that Makefile.am refers to
* ajmitch is trying to get his changes compiled & hopefully tested :)
<Fujitsu> What do these changes do?
<ajmitch> selinux policy loading
<Keybuk> ajmitch: read HACKING
<Keybuk> which tells you where to get that directory from ;)
<ajmitch> ah, figures I'd miss something obvious again
<Keybuk> interesting ... it seems from reading LKML that Linus actually agrees with my interpretation of the GPL wrt GPL'd shared libraries
<Fujitsu> Makes sense.
<Fujitsu> You're right about most things, so's he. Of course you should come to the same conclusion.
<Keybuk> heh, I'm wrong about a great many things too
<Keybuk> Fujitsu: many people are adamant that I'm wrong
* Keybuk notes that Debian still won't ship live-f1
<Fujitsu> Hey sabdfl.
<Fujitsu> Keybuk, is that a surprise? :P
<pygi> morning
<Fujitsu> Hey pygi.
<ajmitch> hi pygi 
<pygi> morning ajmitch, Fujitsu :)
<Keybuk> "When you run adduser and deluser, did you think it modified /etc/passwd? Well, I did, anyway. But I was wrong! It actually creates a whole new copy of the password file, and then renames it over the top of the old one."
<Keybuk> *blink*
<Keybuk> well, err, duh
<Keybuk> is that not the standard way in which all files are modified? :)
<Treenaks> Keybuk: not _all_ files :)
<Keybuk> if you don't do it like that, then you don't get an atomic write
<pitti> adduser *could* do with appending, too, but deluser?
<pitti> hi tkamppeter
<Keybuk> pitti: power goes in the middle => corrupt passwd file
<pitti> Keybuk: (I know)
<Keybuk> at least with fsync();fclose();rename() you know the filesystem will at worst only corrupt the temporary file
<realist> Keybuk: hence using "vipw" to edit the /etc/passwd file
<Treenaks> Keybuk: so, who wrote this?
<Keybuk> Treenaks: gnome dude on their planet
<ogra> Keybuk, bug 62861, fuse does the following now (it used to just add fuse to /etc/modules, but that changed in debian)
<Ubugtu> Malone bug 62861 in fuse "fuse module not loaded" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62861
<ogra>   if invoke-rc.d udev reload 2>/dev/null; then
<ogra>   modprobe --first-time fuse 2>/dev/null ||
<ogra>         echo -n add > /sys/class/misc/fuse/uevent
<ogra>   fi
<ogra> do you think that suffices ?
<Keybuk> ogra: uh, that won't do anything after a reboot
<ogra> ah, k, i'll add the code from ltspfs to it then ...
<Keybuk> he does go on to say an interesting observation about autoconf, etc. though
<ogra> i just read your last comments ... 
* ogra opens the bug
<ogra> oh, that wasnt targeted to me i guess :)
<seb128> could somebody help me to debug gdb?
<seb128> it segfaults on gaim, rhythmbox, ekiga ...
<fabbione> seb128: did you try rebuilding gdb without stack-protector?
<fabbione> seb128: i have seen it going crazy recently with threaded apps...
<fabbione> not sure if that might be related
<seb128> fabbione: I tried stack, I tried 6.5 from upstream too
<seb128> grumpf
<seb128> fabbione: I tried *that*, I tried 6.5 from upstream too
<pitti> dapper's 6.4 was much better, wasn't it?
<fabbione> hmm
<pitti> . o O { maybe we shoud rollback to that stable version instead of our 6.5 beta)
<seb128> pitti: it worked
<fabbione> seb128: can you try to build a very simple test case?
<Keybuk> seb128: I can't even get gdb to work at the moment
<Keybuk> I was going to beat doko or pitti up about it
<fabbione> like hello.c and see if it segfaults there too?
<Keybuk> it just claims "unable to read stack frame" or something
<Keybuk> like, gee, helpful
<seb128> gdb works fine on most of apps
<seb128> not on gaim, rhythmbox, ekiga though
<pitti> Keybuk: of the topmost function? yeah, I noticed that, too, a pretty recent regression
<seb128> an valgrind doesn't work on multithreaded programs neither
<seb128> "valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed."
<seb128> that starts being pretty annoying to do debug on edgy
<pitti> seb128: 'it worked' -> with 6.5 final or no SSP you don't get the crashes?
<seb128> no
<seb128> it worked with dapper
<pitti> ah, right
<seb128> no luck on edgy, with or without ssp, with current edgy or 6.5 upstream
<seb128> I'll try build to install the dapper package
<pitti> an interesting test would be to build 6.4 on edgy
<seb128> I think I tried some time ago, was not working neither
<pitti> I'm not entirely convinced that it is a gdb problem
<pitti> our gdb didn't change in ages, and when I wrote the pkg-create-dbgsym test suite we alread had it
<seb128> I'm pretty convinced it's not
<seb128> I tried the dapper deb some time ago
<pitti> still I only noticed the test suite failure due to gdb regression recently
<seb128> and it was not crashing but not working neither
<pitti> so 6.4.90 built on dapper is likely to work
* seb128 "sudo dpkg -i gdb_6.4-1ubuntu5_amd64.deb"
<seb128> "thread_db_get_info: cannot get thread info: generic error"
<seb128> the dapper version does that
<seb128> that's already what it was doing when I tried some time ago
<seb128> so that's not coming from gdb itself
<seb128> that package works fine on dapper
<seb128> http://sourceware.org/ml/gdb/2006-09/msg00059.html
* seb128 tries the patches pointed
<pitti> nice - apport runtime reduced from 25 s to 0.7 s for a test bash crash
<seb128> waouh
<seb128> how did you do that?
* tfheen guesses "got rid of the dpkg -S calls"
<pitti> seb128: several optimizations and shifting many expensive bits to apport-gtk
<pitti> tfheen: I alread had heuristic optimizations for that before
<pitti> tfheen: if the binary name is a substring of the package name, or vice versa, finding the package is quite fast
<Keybuk> LOL @ http://maps.google.com/maps?hl=en&t=k&q=Germany&ie=UTF8&z=18&ll=48.857699,10.205451&spn=0.002404,0.006738&om=1
<pitti> Keybuk: the bug invasion?
<Keybuk> yeah
<pitti> seb128: well, and for firefox I still get a respectable 3:30 mins -> 30 seconds
<mvo> mjg59: hi! thanks for your language-selector upload. could you send me a debdiff please so that I can put it into my bzr tree? the upload is still in the unapproved queue
<pitti> seb128: (ugh, I should have tested that on my slow laptop much earlier...)
<pitti> ok, changing from laptop to desktop, brb
<mjg59> mvo: http://www.codon.org.uk/~mjg59/tmp/language-selector.debdiff
<mvo> mjg59: thanks!
<ogra> pitti, according to a support request the bug in the autosink was already introduced in a dapper upgrade ...
<ogra> (the one with LTSP)
<mjg59> mvo: Did you get my bug about fontconfig-voodoo?
<mvo> mjg59: I'm behind on bugs currently, let me have a look
<seb128> re
<seb128> I hate whatever DoS my desktop when an app crash
<seb128> either the linux patch or appport
<mvo> mjg59: right, got it and it is indeed a problem
<tfheen> seb128: just fix the bugs (or turn off apport?)
<seb128> I got my amd64 frozon for 10 minuts after gdb crash
<seb128> tfheen: I would be happy to fix bugs, having gdb or valgrind working would help for that :p
<mvo> seb128: apt-get install gdb ;) 
<seb128> mvo: did you read that chan the previous half an hour? :p
<seb128> mvo: gdb segfautls on ekiga, rhythmbox, gaim, etc
<seb128> mvo: you just stepped to help me to fix it apparently, thank you ;)
<mvo> nay, some of the conversation had the words "problem", "error" and "segfault" in it and I blend that out automatically 
* mvo starts to sing "lalalalalaalala" I can't hear you "lalalalalala"
<pitti> seb128: for that I'm afraid I have to sacrifice the 'sort coredump to the end' fix
<tfheen> seb128: works for me on amd64.
<seb128> pitti: why?
<seb128> tfheen: valgrind?
<tfheen> seb128: gdb
<tfheen> valgrind blows up
<pitti> seb128: otherwise apport-gtk had to write the whole report file again; apart from performance issues, this also bears some other difficulties
<seb128> tfheen: do you have a jabber account?
<seb128> tfheen: you are to my list, could you go online, I'll send you a file
<seb128> tfheen: it makes gaim crash, it crashes gdb too for me and dholbach (and pitti IIRC)
<seb128> tfheen: if it works fine for you I'm happy to get the bt for it, other way you can confirm that gdb crashes
<dholbach> tfheen: did you manage to capture the crash in gdb?
<seb128> dholbach: he just said he has no crash
<dholbach> ok, that's why gdb is happy
<tfheen> "gdb valgrind ekiga" seems happy here.
<tfheen> (or rather --args ekiga)
<seb128> tfheen: attach gdb to gaim before accepting ;)
<tfheen> seb128: it probably doesn't work from here because of my nice network setup.
<seb128> ddc, etc don't work usually for me due to masquerading
<seb128> but jabber transferts seem to work
<tfheen> I'm on wireless too, so unless it does in-band, it won't work.
<seb128> hum, k
<tfheen> seb128: ok, try again
<tfheen> Program received signal SIGPIPE, Broken pipe.
<seb128> k
<seb128> and gdb did crash with it?
<tfheen> I guess I should really install the gaim-dbg package too?
<tfheen> no, gdb is happy as can be
<seb128> would be better yep
<tfheen> seb128: ok, doit.
<seb128> tfheen: done
<tfheen> seb128: http://rafb.net/paste/results/XOdBHk29.html
<tfheen> is the backtrace
<tfheen> gdb is happy still
<seb128> k, so it's doesn't happen to everybody
<seb128> thank you for the bt, will update the bug about it with that ;)
<tfheen> np; tell me if there's anything more you need
<seb128> fixing valgrind on amd64 would be nice :p
<tfheen> I'm still not really well, so I'm not really working today.
<seb128> tfheen: don't worry, it's broken for some time and that's not really something useful to average user, no hurry for it
<seb128> tfheen: better to take care of yourself today, you deserve it after the beta rush ;)
* seb128 hugs tfheen
* tfheen hugs seb128 back
<pitti> seb128: apport writes the core dump, and apport-gtk adds packaging/os/gdb information; apport-gtk can only append to the report or completely rewrite it, not insert new stuff in between
<seb128> pitti: maybe we should make "crash file without coredump" the default?
<seb128> pitti: because my browser chockes every time I click on a crash file from a bug
<seb128> and we don't do anything with the coredump atm anyway
<pitti> seb128: well, we need it to get better stack traces
<seb128> pitti: can we get better straces with it atm?
<pitti> seb128: I'll update apport-retrace soon to download ddebs automatically on request
<seb128> right, but that's client side
<pitti> seb128: I'd rather solve that problem by changing the extension or something so that ffox defaults to downloading the file instead of displaying it
<seb128> I mean do we need to coredump on the bug page?
<seb128> usually I want a quick look at the bt
<pitti> seb128: well, it might be useful to debug the problem
<seb128> I don't want to download 10M for that
<pitti> seb128: hm
<seb128> I mean the coredump is useful
<pitti> seb128: apport-retrace offers to remove the core dump from the report
<seb128> but most of the time I quick lock the bt to mark as dup
<pitti> seb128: so as soon as we have automatic processing of these reports, that'll be solved
<seb128> s/lock/look
<Kamion> elmo: cdimage size should be saner now
<seb128> right
<pitti> seb128: but I'm afraid I don't have a truly quick solutino
<pitti> seb128: let's talk about it in 30 mins or so, I need some food
* pitti hugs seb128 
<seb128> sure
* seb128 hugs pitti back
* dholbach looks at glibmm update
<Kamion> sabdfl: the questions on upgrade are a console-setup bug, which I thought I'd fixed
<Kamion> sabdfl: assuming they were asking you for keyboard layout and variant respectively
<Kamion> sabdfl: perhaps you could file a bug on console-setup and attach the output of 'echo GET debian-installer/keymap | sudo debconf-communicate', 'sudo debconf-show console-setup', and the contents of /etc/default/console-setup
<Kamion> you might still get a question if this is a system that has been upgraded continuously from a fresh Debian woody install all the way to edgy, though
<Kamion> (in which case debian-installer/keymap won't be set)
<lfittl> hrmm, something weird happened with compiz-plugins 0.5-0ubuntu4, it is listed on my Packages package as built sucessfully, but nowhere else in launchpad (no buildlogs, ..)
<tfheen> Kamion: that might be why I saw it, since one of my systems is really a slackware '96 installation slightly mangled over the years.
<pitti> seb128: re
<seb128> pitti: wb
<pitti> seb128: and the current sort order helps you for that, and ffox does not choke?
<seb128> pitti: I can click on the "stop" button after a few sec 
<pitti> ok
<seb128> pitti: so it doesn't load the whole crash file
<pitti> seb128: alright, let me think about that problem
<pitti> seb128: I can load, modify, and rewrite the complete report; it takes *much* longer for the user, but so be it
<Kamion> tfheen: ha
<seb128> pitti: no no, nothing taking much longer
<Kamion> lfittl: I only shunted it through unapproved very recently; I'm surprised it built
<doko_> Kamion: the queue remains in manual mode for main?
<seb128> pitti: I can cope with downloading the coredump if that reduces crash generation and makes better user experience
<Kamion> lfittl: although looking more closely there appear to have been two copies of the same version there
<pitti> seb128: (appending one kb of packaging info to a ffox crash report is super-fast, rewriting it isn't)
<seb128> pitti: k, keep it the fast way then
<Kamion> doko_: yes, mdz wants to leave it that way for a while (a day or so) to let the mirrors concentrate on serving the beta
<pitti> seb128: I'll think about it; if I don't find a robust way to rewrite it without unpacking/packing the core dump, I'll just append
<seb128> ok, thank you
<lfittl> Kamion: yep, the version slomo uploaded and mine, but we agreed mine is better (fixes the problem by using shlibs instead of hardcoding it), should I do anything to get this into the archive?
<Kamion> lfittl: check what source package actually landed in the archive; if it's slomo's, you should supersede it with another upload
<Kamion> lfittl: in general you should try to avoid two uploads with the same version number - it's confusing for everyone
<lfittl> Kamion: it wasn't intended, just coincidence ;)
<Kamion> o
<Kamion> ok
<lfittl> Kamion: hmm, the archive has no source package of this version, only the old one
<Kamion> doko_: if there's something that's urgent, I can accept it
<Kamion> lfittl: it will still be publishing; wait about 30 minutes
<lfittl> Kamion: ok, and if I reupload then, I should use a new version number, right?
<Kamion> lfittl: absolutely
<lfittl> Kamion: good, thanks for your help
<Kamion> version numbers are cheap; you don't need to conserve them
<Kamion> at this point, an upload with the same version number would be rejected, anyway
<Kamion> it's a soyuz bug that one of your uploads wasn't rejected earlier
<doko_> Kamion: java-gcj-compat would be nice as a prerequisite of the next OOo; axis and wsdl4j in NEW are required for tomcat5.5, which is then required by eclipse (not sure if Keybuk did look at these two); you could reject the pending python2.4 upload, it will be superseeded by a followup upload anyway
<Keybuk> Kamion: what's the policy on uploads currently, btw?
<Keybuk> I see everything is still getting tipped into unapproved
<Kamion> doko_: java-gcj-compat accepted, python2.4 rejected
<Kamion> Keybuk: 11:12 < Kamion> doko_: yes, mdz wants to leave it that way for a while (a day or so) to let the mirrors concentrate on serving the beta
<Keybuk> ok
<Kamion> we're back to feature freeze though - it's purely an administrative thing at this point
<Keybuk> *nods*
<seb128> re
<seb128> another 15min of DoS after gdb crash, next time I stop apport before :p
<pitti> seb128: yeah, yeah, I'm working on it :-P
<seb128> I don't get why the load goes over 10 though
<pitti> seb128: (I hope 15 min was just a metaphoric overstatement)
<seb128> I've nothing against it working
<seb128> but the mouse cursor jumping every few sec and the box not usuable is no fun
<Kamion> pitti: I'll work on the openssh DoS in edgy if you like
<Kamion> unless you're already on it; I hadn't seen anything
<pitti> Kamion: oh, I appreciate that
<seb128> pitti: no, I went away from the computer for 10min and it was still not responding, and that's an amd64 with 1Go of RAM and a fast disk
<pitti> Kamion: no, I didn't start on it yet
<Kamion> I'm upgrading Debian to 4.4p1 nowish
<Kamion> I think edgy should just be patched though
<pitti> Kamion: yeah, we need the patches anyway for stables
<pitti> Kamion: do you have the three CVEs?
<Kamion> oh, uh, can't do Debian yet because there isn't an updated GSSAPI patch yet
<Kamion> meh, will just have to patch it
<Kamion> pitti: CVE-2006-4924 is the only one I have
<pitti> Kamion: 'unsafe signal hander': CVE-2006-5051, 'authentication abort': CVE-2006-5052
<pitti> Kamion: in the 'security fixes' section of the announcement (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115939141729160&w=2)
<pitti> Kamion: I have a patch for CVE-2006-5051 in my mailbox, if you need it
<Kamion> pitti: I'll grab them from upstream CVS, but if you can forward what you have to me, that would be good
<Kamion> then I can compare them
<seb128> pitti: the DoS doesn't seem to be due to apport itself, that's just a "not enough swap available" issue
<pitti> Kamion: mailed you info about 5051, /msg'ed you cvs links for CVE-2006-4924
<elmo> Kamion: thanks
<janimo> seb128: hi, what is the plan re python-gnome2?
<Kamion> pitti: thanks
<Kamion> janimo: published xubuntu beta
<janimo> Kamion: saw it, thanks
<fabbione> Kamion: i uploaded cpio to dapper-updates, up to you when you want to unleash it for sfllaw 
<fabbione> hem
<fabbione> dapper-proposed i meant
<Riddell> tfheen, Kamion: are uploads to main still blocked?
<tfheen> Riddell: yes, waiting for mirrors to ride off the initial load and such.
<StevenK> tfheen: What's with the non-Mithrandir nick?
<tfheen> StevenK: vawad (my usual machine) is behind a really stupid NAT ATM, so I can IRC off it.  Mith will be back once that's fixed.
<HiddenWolf> tfheen: well, torrent is under hardly any load at all at the moment, how bad can the mirrors be doing. :)
<tfheen> HiddenWolf: *shrug*; mdz wanted it that way, I'm not going to argue
<HiddenWolf> :)
<HiddenWolf> wise policy
<tfheen> it's not like it really matters that much either.
<tkamppeter> hi pitti
* tfheen waves to heno 
<heno> tfheen: hello!
<tfheen> heno: how's the new place coming together?
<heno> tfheen: ok, slowly. Since I started work again this week I haven't done much in the house :)
<heno> Most of my stuff will get here in about 2 weeks
<tfheen> heno: I knew I shouldn't have fixed your DSL, then. ;-)
<heno> heh
<slomo__> tfheen, Kamion: hm are my dbus/libnotify/notification-daemon uploads lost somewhere or just not approved yet?
<tfheen> slomo__: edgy is still frozen, it'll be thawed in a couple of hours
<slomo__> tfheen: oh sorry for uploading them then... i thought with the beta release it was officially unfrozen :(
<tfheen> slomo__: well, it's just frozen in LP, we're past beta release so anything uploaded while it's frozen will be accepted in a bit.
<elmo> Kamion: did you see the  discussion mdz and I had last night about torrents?
* pygi pings sivang
<janimo> seb128: hi
<seb128> janimo: Hi
<janimo> seb128: how do you propose we get on with python-gnome, now we are past beta?
<seb128> janimo: I'm busy with other things atm, I'll do that later when archive is unfrozen
<janimo> seb128: I did not mean that you upload now of course, just pinged as a remainder
<janimo> thanks
<seb128> janimo: np ;)
<bddebian> Howdy folks
<pygi> bddebian: and hi again :P
<bddebian> Sheesh :-)
<heno> doko: when it try to upgrade with the source list entries you sent I end up with a new openoffice.org-java-common and a few other things, but all of openoffice gets held back. Is that as expected or should I force it through?
<heno> *when I try
<heno> eh, nevermind. It seems to be installing now
<sfllaw> fabbione: Just saw my name.
<sandy> i can't input chinese in gaim  ?  why   
<sandy> help
<desrt> sandy; seriously wrong channel.  ask in #ubuntu.
<sandy> #ubuntu ?
<abattoir> sandy: yes, and #ubuntu-cn might be helpful as well
<sandy> thanks
<sandy> bye
<dholbach> doko_, heno: nice that ooo seems fixed wrt a11y
<doko_> dholbach: it is?
<dholbach> doko_: at least heno wasn't able to reproduce it
<doko_> ahh, I see. heno, cool!
<doko_> heno: pulled some FC patches
<dholbach> doko_: how did you fix it?
<dholbach> ahhh nice
<dholbach> heno: now we only need to fix the gnometerminal-tab-weirdness and the evolution crasher (with a11y enabled)
<doko_> heno: btw, you are able to enable the hicontrast icons in OOo, but just manually
<doko_> heno: and with the new packages only, if you have the openoffice.org-style-hicontrast package installed.
<dholbach> doko_: how many icons are in that package?
<doko_> $ unzip -v /usr/lib/openoffice/share/config/images_hicontrast.zip | wc -l
<doko_> 7509
<Riddell> Keybuk: please give back ruby1.9 on ppc
<dholbach> wow
<dholbach> doko_: then I didn't have them all installed
<dholbach> doko_: those are not the usr/share/icons/locolor icons?
<Keybuk> Riddell: is the bug fixed?
<Riddell> Keybuk: yes
<Keybuk> ok
<doko_> dholbach: no, there are no locolor icons
<Kamion> elmo: I've removed knot-3 from torrent.u.c; anything else I need to remove?
<elmo> Kamion: mdz was suggesting we remove hoary, dvd's, source and dailies too *shrug*
<Kamion> hoary should go, the rest will come right back with the next daily build and I'm not keen on removing them because if I do I'll be deluged with people asking me why they're missing
<Kamion> killed hoary
<pitti> seb128: ok, I'm rewriting the full report now; I need to load the core dump anyway for doing the backtraces, so it's not that much overhead
<pitti> seb128: IOW, CoreDump will be at the very end, as usual
<seb128> pitti: cool
<ogra> mjg59, there is a ipw2200 version you have to run with ndiswrapper ? 
<Keybuk> ogra: some people seem to use ndiswrapper for drivers that are better supported under Linux than they are under Windows!
<ogra> (someone just told me his card isnt supported by the driver we ship ?)
<ogra> Keybuk, but i cant imagine that there is a ipw2200 based card that doesnt work at all with our (intels) drive 
<ogra> r
<Treenaks> ogra: there's another chip, called 'ipn2200'
<Treenaks> ogra: that's completely not ipw2200.. the names are just very much alike
<ogra> thast not from intel, is it ? 
<Treenaks> ogra: not intel, indeed
<ogra> i think i have such a card around on a broken lappie here, it was never supported ... not even with ndiswrapper
<janimo> Kamion,  bug 48047 , it seems to be ok for 6.06 but now 6.06.1 has the issue
<Ubugtu> Malone bug 48047 in xubuntu-meta "wrong jigdo files" [Medium,Confirmed]  http://launchpad.net/bugs/48047
<janimo> I don't use jigdo but by the look of the files seems there's something wrong there
<sabdfl> does mercurial 0.9.1 *really* depend on python 2.5?
<_ion> When Malone says someone is the "creator" of a package that has been automatically synced from Debian without changes (e.g. bddebian with preload), exactly what does that mean?
<Kamion> _ion: "creator" is the person who appeared in the Changed-By field in the .changes file
<Kamion> it's a terrible name, should be "uploader" (I filed a bug ages ago)
<Kamion> or "last changed by"
<Kamion> _ion: for syncs, it's the person who requested the sync
<_ion> Ok, thanks.
* bddebian claims innocence
<Kamion> so we do sync-source -b kamion foo, which creates foo_VERSION_source.changes with Changed-By: Colin Watson <cjwatson@ubuntu.com>
<Kamion> (say)
<janimo> sabdfl: unlikely as in debian is deps on python <<2.5
<sabdfl> pls can we fix that package then?
<Kamion> maybe it picks the highest of pyversions or something
<sabdfl> should i file a bug and assign to... was uploaded by motu
<Kamion> sabdfl: it was a sync
<janimo> Kamion: the depends line has both 2.4 and 2.5
<doko_> Kamion, Keybuk: please ack the binary wsdl4j in NEW, and icu4j source
<sabdfl> aptitude wants to pull in 2.5
<doko_> janimo: package?
<Kamion> janimo: it also has python2.5
<janimo> doko_ mercurial
<Kamion> (but not python2.4)
<doko_> janimo: looking
<Kamion> janimo: thanks, checking now
<janimo> doko_: actually not both... just python2.5
<janimo> and also python >=2.4
<heno> doko_, dholbach: yep, ooo seems good now. I'll play with the icons next
<heno> and keep using ooo with at-spi turned on and see if anything pops up
<mhb> hello
<Kamion> janimo: fixed, thanks
<mhb> I've attached a fix to this bug: https://launchpad.net/distros/ubuntu/+source/mozilla-firefox-locale-all/+bug/61875 but someone has to commit it, I guess
<Ubugtu> Malone bug 61875 in mozilla-firefox-locale-all "[edgy]  Keyboard shortcuts for "Add page to bookmarks..." and "Save page as..." are the same" [Undecided,Confirmed]  
<janimo> Kamion: thanks
<mhb> can someone tell me what should I do next, whom should I contact?
<lucas> infinity: there was a lot of ruby-related build failures on powerpc which should be fixed now, but they need to be re-queued.
<tfheen> lucas: do you have a list of packages?
<lucas> tfheen: no. some of them are on https://launchpad.net/people/lucas/+packages, but all packages which aren't arch: all that transitively build-dep on ruby are affected
<lucas> (on ppc only)
<lucas> I mailed infinity three or four times over the last months about those ruby build problems on ppc, but it was only fixed recently by Riddell
<tfheen> given that ruby itself failed to build, that's not very surprising
<Kamion> doko_: wsdl4j/icu4j done
<Kamion> lucas: it was a kernel bug (or at least it was fixed by upgrading the kernel on davis) - it wasn't something that repeatedly mailing somebody was necessarily likely to solve
<elmo> lucas: it wasn't fixed by Riddell, the root cause was diagnosed by BenC (after several others had tried), and it wasn't exactly obvious, there's no point repeatedly complaining about it
<tfheen> lucas: anyway, *ruby* which ftbfs-ed given back.  Please do tell me if there are more packages.
<lucas> I probably mailed him about once a month, never got any answer from him, I wouldn't call that "repeatedly complaining".
<Kamion> lucas: it wasn't something infinity could particularly easily fix; such things often end up sitting in people's queues if they think they *might* be able to figure it out in the futre
<elmo> lucas: the complaining I'm talking about is how you keep banging on about how you've mailed Adam
<mjg59> ogra: No
<lucas> Kamion,elmo: maybe we need another way to track buildd problems then. Is there a way to submit bugs on malone about such problems ?
<doko_> janimo: uploaded
<elmo> lucas: it wasn't a buildd problem
<elmo> it was a kernel problem
<BenC> no, it was a ruby problem
<elmo> (which btw, makes all "I don't have access to the buildds -> I can't debug it" claims bunk)
<elmo> BenC: ok, that works too ;-)
<BenC> it's triggered by differences in the kernels
<Kamion> lucas: "won't build" is a perfectly normal bug report against the package in question
<BenC> benh did a code audit of ruby and called it horrid crud :)
<BenC> or something along those lines
<pitti> Hi BenC 
<Kamion> BenC: out of curiosity, what was the bug in ruby?
<lucas> elmo: not being able to reproduce it myself is still a problem
<BenC> Kamion: you were on the rigth track
<Kamion> I got as far as determining that it was something to do with threading and gave up in despair
<lucas> Kamion: won't build + assign to who ?
<Kamion> lucas: in general you shouldn't be assigning bugs to people unless you're their manager
<BenC> racy locking and such
<elmo> lucas: anyone with access to a powerpc could have reproduced it
<Kamion> or in a similar position of being able to instruct them to fix it
<BenC> pitti: hey
<lucas> Kamion: s/who/which team/ ?
<Kamion> lucas: don't
<Kamion> leave it assigned to nobody unless you know that somebody is actually working on it
<Kamion> fictitious assignments are a pain
<pitti> BenC: I'm a bit puzzled about bug 62972
<Ubugtu> Malone bug 62972 in linux-source-2.6.17 "leaves core files behind after calling crashdump-helper" [High,Unconfirmed]  http://launchpad.net/bugs/62972
<pitti> BenC: IIRC apport should not remove core dumps, or shall it?
<BenC> pitti: is this new?
<pitti> BenC: I noticed core files laying around since only recently
<pitti> BenC: since -8 or -10 (I never used -9 since it didn't boot)
<pitti> BenC: and since my home dir gets an automatic backup, I'll notice unusual size increasing quite fast
<BenC> pitti: damnit...ok, need to check on that
<BenC> pitti: I'll mark this bug for release, and high
<pitti> I already did
<BenC> heh, already done :)
<pitti> BenC: thanks
<mhb> I'll try it again - anyone able to finalize 61875 ?
<mhb> bug 61875
<Ubugtu> Malone bug 61875 in mozilla-firefox-locale-all "[edgy]  Keyboard shortcuts for "Add page to bookmarks..." and "Save page as..." are the same" [Undecided,Confirmed]  http://launchpad.net/bugs/61875
<pitti> mhb: looks easy, I'll take it
<pitti> mhb: thank you!
<mhb> pitti: I fixed it, all it takes is to submit the patch
<pitti> mhb: (btw, I can apply patches to the jar files)
<pitti> mhb: marked accordingly, will be fixed by the final release
<mhb> pitti: thanks
<mhb> pitti: the diff of the only modified file in the jar archive is there as well
<pitti> mhb: yeah, I saw it
<sfllaw> fabbione: What's an "SRU" and where is this policy found?
<jdong> sfllaw: wiki, StableReleaseUpdates
<sfllaw> jdong: Thanks.
<jdong> imbrandon / Tonio_: poke... so what _does_ happen to duplicate uploads?
<Tonio_> jdong Hum, first one will be accepted and second one rejected because of already existing
<janimo> pitti, hi could you look at the printer tool and gxine in your next review session? thanks
<Tonio_> jdong btw main is still locked actually
<jdong> Tonio_: aha, that explains why it wasn't accepted yet
<Tonio_> jdong extactly
<jdong> thx
<pitti> imbrandon, janimo: most probably I have to shift the review session to Monday, sorry
<doko_> infinity, cprov: please requeue axis (edgy)
<pygi> sivang: ping for a sec?
<fabbione> sfllaw: did you find it?
<sfllaw> fabbione: Yes, thanks.
<sabdfl> how can i play the new sounds without rebooting?
<BenC> pitti: working on the crash-helper issue now
<sabdfl> where are they?
<seb128> sabdfl: aplay /usr/share/sounds/login.wav
<fabbione> hey BenC 
<seb128> sabdfl: and aplay /usr/share/sounds/logout.wav
<sabdfl> thanks seb128
<seb128> np
<BenC> fabbione: hey
* jdong feels ashamed for transplanting Edgy login sounds to Dapper
<Hobbsee> jdong: mind emailing them to me or something?  i want to hear them.
<jdong> jdong|amd64: didn't I shut you off last night?
<jdong> jdong|amd64: turn off, I command you... and don't bug me again until you have a working usplash!
<jdong> hobbsee: hehe
<enrico> mvo: hi, around?  I don't seem to be able to link with apt-pkg in debian anymore
<jdong> hobbsee: grab ubuntu-sounds
<enrico> .oO(I actually better /msg him, sorry for the noise)
<mvo> enrico: g++ b0rkage, pleae rebuild apt, that should fix the issue
<Hobbsee> jdong: point.
<Hobbsee> jdong: my head's hurting really badly again, i've already blacked out this morning - forgive my brain being a little screwed.
<sfllaw> Hobbsee: Ouch.
* Hobbsee is going to bed very very soon.
<sfllaw> Hobbsee: Good plan.
<jdong> hobbsee: ouch... hope you feel better
<Hobbsee> hehe
<Hobbsee> yeah
<Hobbsee> i've never quite blacked out before.  rather interesting.
<jdong> now, off to diagnose my hal....
<jdong> *cough* bug 60989 *cough* kthxbye :)
<Ubugtu> Malone bug 60989 in hal "HAL reports incorrect battery percentages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60989
* tfheen tickles Hobbsee carefully.
* Hobbsee glares at tfheen 
<Hobbsee> Hobbsee's cant be tickled while their head hurts.
<tfheen> Hobbsee: dudette, I know how you feel after having fever and headache for the last three days.
<zul> Hobbsee: lop your head off then :)
<tfheen> s/having/& had/
<Hobbsee> tfheen: yeah, true.
* Hobbsee hugs tfheen 
<tfheen> Hobbsee: and I _did_ tickle you carefully with no poking or stomping or anything
<Hobbsee> hehe
<Hobbsee> indeed
<Hobbsee> zul: *g*.  i think a few people will complain if i do that.
<zul> Hobbsee: heh but it would stop your complaining :)
* Hobbsee goes silent
<Hobbsee> there, i've stopped complaining.
<zul> :P
<tfheen> zul: you haven't switched the xen master branch to 2.6.17 yet?
<Hobbsee> nice sounds.
<zul> tfheen: no because amd64 is not quite working yet
<jdong> yep, same problem on livecd
* jdong looks around for a hal expert
<slomo__> pitti: ^--
<pitti> nnnng, I gotta leave soon
<Hobbsee> run :P
* jdong tugs on pitti's shirt
<jdong> pitti: *sniff* *sniff* please....?
<jdong> :)
<Hobbsee> hehe
<Hobbsee> night all
<pitti> jdong: oh, that was since the most recent update?
<jdong> pitti: correct
<jdong> pitti: it fixed my formfactor bug but broke my battery percentages
<pitti> jdong: very unlikely
<slomo__> jdong: your machine seems to be a bit weird... you always have dbus bugs or bugs in software connected to dbus there ;)
<pitti> jdong: it's probably debian/patches/00upstream-02-mWh-conversion.patch:
<jdong> pitti: it worked great in knot2
<pitti> jdong: introduced in 0.5.7.1-0ubuntu10 (Tue, 12 Sep 2006)
<jdong> hmm
<pitti> jdong: can you please try building the hal source without that patch and check if it works again?
<jdong> pitti: will do
<pitti> jdong: the patch looked right, and it fixed stuff for many people
<pitti> jdong: before hal assumed that mAh * mV = mWh instead of Wh
<tfheen> mvo: do we have any docs online which Opera can link to which explains how to install stuff from the commercial repo?
<pitti> jdong: please add your findings to the bug, I'll read it
<jdong> pitti: ok, thanks for your time
<pitti> you're welcome :)
<mvo> tfheen: nothing that I'm aware of. maybe the docteam has created something on the wiki though
<tfheen> mvo: hmm, ok.  I couldn't find anything which talked about using add/remove apps, but just adding the commercial repo by hand and similar.
* jdong recklessly restarts dbus while gnome is running
<mvo> tfheen: well it really should be a matter of clicking on "enable commercial" and then searching for opera
<jdong> pitti: if you're still around, that patch was the culprit... I'm gonna add my findings to the bug ticket
<pitti> jdong: ah, ok; so we now have to decide which fraction of hardware we will break *sigh*
<jdong> :(
<pitti> well, I'll have a closer look; the idea of the patch was right, but perhaps it has a bug
<jdong> pitti: could be my laptop has quirky acpi?
<jdong> pitti: apart from lshal, would any other info help you?
<pitti> I don't know of any off-hand
<jdong> pitti: would /proc/acpi/battery info do any good?
<pitti> jdong: sounds helpful; just attach anything that might be useful :)
<jdong> hehe, ok
* pitti -> off
<elmo> tfheen/kamion: does lithium try to rsync from ports or something?
<elmo> ah, nm, of course it does
<`anthony> in case anyone cares - I was trying to upgrade the python dapper buildbot to edgy, but it fails with E: Couldn't configure pre-depend python-gtk2 for gnome-app-install, probably a dependency cycle.
<`anthony> will try again in a couple of days, I guess...
<Kamion> mvo: why's the Pre-Depends: python-gtk2 that `anthony mentioned in gnome-app-install?
<Kamion> that's going to complicate upgrades a lot, surely, with the python2.4-* -> python-* transition in there as well
<`anthony> if by "complicate" you mean "break", then yes :)
<Kamion> mvo: gnome-app-install doesn't have a preinst, so ...
<Kamion> `anthony: well, possibly changes elsewhere could make it not break, but it would still be very complicated
<`anthony> I want to switch the buildbot to edgy because it acts as both a test for edgy and a test for python.
<`anthony> it also runs with the intel C compiler instead of gcc, just to throw additional fun into the mix :)
<Kamion> bug 59403
<Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Fix released]  http://launchpad.net/bugs/59403
<`anthony> X is running.
<Kamion> not the point
<Kamion> see the bug
<Kamion> mvo: I cannot understand why changing Depends to Pre-Depends has any effect at all on the postinst
<bluefoxicy> bah X usage is regularly maxing out and the system lags
<Kamion> mvo: oh, unless there's a dependency loop in there, in which case postinst ordering would be random
<`anthony> worth logging a lunchpad bug about it, or do people not care at this point about upgrades?
<jdong> I am about to have evolution fetch 6000 messages via POP (400MB).... is this going to work?
<Kamion> `anthony: I've reopened the bug abve
<Kamion> above
<`anthony> ah - just read far enough down in the bug report. yeah, that looks like the problem. wah
<`anthony> well, removing gnome-app-install lets the upgrade proceed, at least. I'll add it back afterwards
<`anthony> now that 2.5 is done, it's time for buildbot maintenance. yay.
<`anthony> don't know if there's any value to having a saved virtual machine of dapper, and an automated test that tries to upgrade it to edgy...
<mdz> morning folks
<mdz> Kamion: I didn't suggest removing dvd torrents, but the existing dailies and source
<Kamion> that will only have any effect for about a day until we turn the dailies back on. Is it really worth it?
<Kamion> it would be much better to improve the torrent.u.c UI
<Kamion> (people do torrent the dailies)
<Kamion> I'll remove the source, I guess - probably not enough people torrent that for it to be worth it
<Kamion> oh, except that it's already gone
<Kamion> I guess that was for old releases or someting
<Kamion> something
<Kamion> elmo: you might need to restart the tracker to pick up the fact that I removed a bunch of stuff?
<Kamion> mdz: when do you want to thaw edgy? I've been letting the odd thing through unapproved that people need, but not everything
<elmo> Kamion: it gets restarted on triggers, I think
<`anthony> should I log other upgrade-blocking bugs?
<Kamion> elmo: I've definitely triggered since removing some of those files
<Kamion> `anthony: yes please
<tfheen> mdz: I've poked *Process a bit and will continue to do so over the next week or so.  The basis looks good to me; I'm sure we need to go through it at least once to check that it's good, though.
<`anthony> e.g. there was an "opera" symlink in /usr/X11R6/bin that blocked xorg-common. 
<`anthony> Ok dokey
<mdz> Kamion: today
<mdz> Kamion: (cf BetaProcess)
<`anthony> x11-common, I meant. sigh
<Kamion> oh, yes, I've been meaning to read that
<Kamion> mdz: so, say, now? :)
<mdz> Kamion: sure
<elmo> Kamion: hmm, ok, kicking
<mdz> tfheen: re: notifying the marketing team, I figured beta wouldn't need much time because of the work done for the milestones
<Kamion> mdz: historically I don't think we've reverted the Beta change to debian-cd/CONF.sh
<mdz> tfheen: but feel free to move it earlier if you or the marketing team feel it's appropriate
<Kamion> I don't necessarily object to doing so, I guess
<Kamion> mdz: needs somebody with a rubber duck to change the status in LP
<tfheen> mdz: the marketing team is fairly small and we have a significant risk of hitting a time when everybody's busy/traveling/whatever.
<mdz> Kamion: yes, at the time I suggested removing the dailies it was to be a temporary fix
<Kamion> mdz: oh, I didn't realise that. bit late now then
<mdz> tfheen: good point, edit as needed
<mdz> Kamion: I'll fix lp
<mdz> Kamion: I think it only needs a driver though
<mdz> done
<Kamion> oh, really? ok
<mdz> Kamion: maybe not revert, but it should probably change at least
<Kamion> no, I think it needs an admin now, I can't see the widget
<mdz> Kamion: or does it still get a build number?
<Kamion> there's always a build number
<mdz> so long as the beta and the dailies are distinguishable, it's ok I guess
<Kamion> I'll flip it back to Alpha, it doesn't seem outrageous
<mdz> it sort of does actually
<Kamion> Post-Beta?
<mdz> the release is still beta-quality, but the CD builds could potentially get flaky since they're automated
<mdz> it's a daily build of a beta tree
<mdz> not sure what to call that
<mdz> probably just a build number
<Kamion> Post-Beta seems to express it pretty well
<Kamion> unless we want to go for Gamma ;-)
<Kamion> I've emptied unapproved
<`anthony> maybe you should have a special "daily" quality tag, to denote that it's an automated build?
<mdz> Kamion: beta daily?
<Kamion> well, firstly, that's normally been "Alpha" up to now; secondly, all releases are merely copies of automated builds
<mdz> we should probably call the dailies daily too
<Kamion> mdz: doesn't make a lot of sense to me
<mdz> Kamion: it doesn't seem right to call something beta which has seen zero testing
<Kamion> well, why don't I just make it say "Daily Build"
<Kamion> and people can deal
<mdz> that's OK with me
<mdz> mvo: have you and infinity worked out the correct fix for the langpack/livefs issue?
<Kamion> right, third commit to CONF.sh :-)
<Kamion> thanks
<mvo> mdz: not yet
<mdz> tfheen: did you intentionally target bug 57084?
<Ubugtu> Malone bug 57084 in xorg-server "Please package Xephyr" [Wishlist,Fix released]  http://launchpad.net/bugs/57084
<mdz> mvo: I can think of a few approaches but am not sure what's most correct
<mdz> mvo: either we should consider the langpacks manually installed, or ubiquity should explicitly mark them manually installed after removing -live
<mdz> it would be pretty silly to remove them and install them again
<tfheen> mdz: yes, and I thought I had that fixed already too.
<tfheen> mdz: not because it's so important, but more because I wanted it in (and get the previous, broken package out of universe)
<mdz> mvo: does the existing API allow ubiquity to fix this?
<tfheen> (I apparently have this fixed already, I just can't read)
<Kamion> mdz: presumably, if a langpack is installed by language-selector, it will be considered manually installed?
<mvo> mdz: yes, there is a apt-mark command that can be used for this
<Kamion> if so, I think the livefs should be in sync with that
<mdz> tfheen: neither can I
<mdz> tfheen: this lack of sorting sucks
<mdz> if they can' fix that easily, perhaps just hiding the fixed bugs would do
<mdz> s/can'/&t/
<mdz> Kamion: I don't follow
<Kamion> mdz: doesn't installing support for a language with language-selector count as manually installing those language packs?
<mdz> Kamion: I would say so, yes
<Kamion> so I sort of feel that the livefs should be constructed as if you had installed that set of languages with language-selector
<tfheen> mdz: I whined in the "sorting is broken" bug today; jamesh offered using advanced search as a workaround.
<mdz> Kamion: I see, I think I agree
<tfheen> (since that doesn't give you colspan=3)
<Kamion> it doesn't have to be, and I can fix it in ubiquity if everyone disagrees, but that just feels cleanest to me
<mdz> there's no point in apt wanting to autoremove them in the live environment depending on the language you booted
<mdz> tfheen: yeah, I saw
<Kamion> it's either code in livefs.sh or pretty much the same code in ubiquity, so whatever
<mdz> tfheen: that actually lets us limit to main, too, which is nice
<tfheen> mdz: true.  It just a workaround, though, and way more work than having it Just Work.
<mdz> Kamion: I'm not sure what the livefs.sh bit would look like...special-case langpacks?
<bluefoxicy> this experiment is over
<bluefoxicy> I switched to evolution for my g-mail account a while back, but I've decided the memory usage is too much, so back to thunderbird.
<bluefoxicy> (if I can figure out htf to get mail migrated BACK to thunderbird)
<Kamion> mdz: sure
<mdz> seb128: bug 3642 is targeted for edgy; can the same fix for suspend be applied to hibernate?
<Ubugtu> Malone bug 3642 in Baltix "hibernate doesn't work from gdm itself" [Undecided,Unconfirmed]  http://launchpad.net/bugs/3642
<mdz> Kamion: ok, I'll update bug 61684
<Ubugtu> Malone bug 61684 in portmap "Removing any u-desktop depdencency marks all other packages for auto-removal (on alternate install)" [Undecided,Rejected]  http://launchpad.net/bugs/61684
<cb_> Tried to upgrade to the latest beta...encountered errors in a duplicate python file that could not be deleted. How to handle this problem?
<tfheen> file a bug?
<mdz> tfheen: I've emailed a forums admin asking about how we should communicate about releases; for your other comments, please just go ahead and edit as necessary
<tfheen> mdz: 'k
<mvo> Kamion: I look into the postinst issue for g-a-i today
<Kamion> mvo: thanks
<rraphink> bug #1
<Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<lastnode> mdz, if i was creating a py package, would i unpack my functions/classes to /usr/local/app ? ive looked through the debian python policy and it doesn't recommend a location. does ubuntu have a preferred place?
<mdz> lastnode: I'm surprised if that's not in the policy
<mdz> lastnode: at any rate, serpentine is a good example
* lastnode checks again
<lastnode> ok, thanks 
<mdz> lastnode: and to answer your question, no, packages should not place files in /usr/local at all
<lastnode> gotcha
<mdz> mvo: g-a-i still doesn't seem to sort by popularity by default
<mdz> mvo: I think that for search results it should
<mvo> mdz: it does a ranking that involves popularity but is not the only criteria
<glatzor> mdz: hi, we use a more "complex" rating for the search. So that if the search term matches the pkg name the application will be on top
<mdz> mvo: ah, interesting
<mdz> mvo: gstreamer0.10-plugins-ugly has a low popularity rating; I wonder if our popcon statistics are useful
<mdz> mvo: would you ensure that in the release notes, there is a section highlighting the knob to turn on popcon so that we get more participation?
<mvo> mdz: yes, I can do this
<mvo> mdz: we could pimp the raking for certain selected apps :)
<mvo> e.g. mp3->gstreamer
<seb128> mdz: re gdm hibernate, I've set an edgy milestone because I thought it maybe was the same fix as the upstream sleep one, but it's not. The sleep option is an upstream, hibernate is a distribution patch and it's lacking some part of code to work from the login screen apparently. How much do we care about having hibernate on the gdm screen? I was pondering dropping the patch since the session dialog use gnome-power-manager now anyway
<seb128> mjg59: thank you for the nice gnome-session patch, that's better than yet another environment variable ;)
<adam0509> hi, got an idea when edgy eft will be realeased ?
<LaserJock> adam0509: wiki.ubuntu.com/EdgyReleaseSchedule
<nixternal> have they even started developing Edgy Eft
* nixternal counts to 3
* nixternal hides
<seb128> nixternal: yeah, better :p
<mdz> seb128: I don't think that hibernation from the login screen is an essential feature, but having sleep and not hibernate is weird
<mdz> seb128: shouldn't it be possible to make them both work in almost exactly the same way?
<nixternal> hehe
<adam0509> 26 october ? exactly the day I wanted to reinstall my Ubuntu ;)
<seb128> mdz: yeah, should not been too much work, maybe 1 hour to do the change, it has just been low on my TODO and I didn't come to do it yet, will do before edgy ;)
<shawarma> I just noticed that popcon@ubuntu.com is not working.. Should I file a bug or is this message sufficient? :-)
<shawarma> "Recipient address rejected: User unknown in vir
<shawarma> tual alias table (in reply to RCPT TO command)"
<BenC> pitti: ping
<BenC> hmm, no pitti
<AlinuxOS> Kamion, ping
<AlinuxOS> Kamion, Hello,so this (Gia Shervashidze's Georgian fonts http://img295.imageshack.us/my.php?image=screenshotxtermgiaqu5.png), may/could replace (this crappy: http://img83.imageshack.us/my.php?image=screenshotxterm1crappyma5.png) fonts in unifont, gfxboot and everywhere in Ubuntu where bitmap (console font) needed ?
<AlinuxOS> Kamion, it will be great if we dissapear this (http://img83.imageshack.us/my.php?image=screenshotxterm1crappyma5.png) crappy/improportional font from Georgian range of glyps...Thank You!
<mdke> AlinuxOS: email will get him, I would think
<AlinuxOS> Ok I'll mail him ;)
<AlinuxOS> mdke, maybe you need new Firefox's start page in Georgian (ka)?
<mdke> AlinuxOS: I have no idea. I've been away for a month and don't know how the start page has been changed
<AlinuxOS> mdke, ok don't worry...if there is something new...just let us know ;)
<AlinuxOS> please ...
<mdke> AlinuxOS: I won't have time. The best thing is if you keep an eye on it and check it is up to date
<mdke> damn
<sfllaw> mdz: Were we going to have a chat this week?
<mdz> sfllaw: absolutely. how's now?
<mdke> sfllaw: you pinged me a couple of times while I was on holiday: I'm off to bed now, but if I can still help, send me an email and I'll look tomorrow!
<sfllaw> mdke: Sent.
<sfllaw> mdz: Yes, I think that's fine.  +1-514-839-4887.
<mdke> sfllaw: ah, that's fine. I'll reply in the morning
<slomo> infinity: please give-back brasero on ppc, should be buildable now that new gtk is in the archive... thanks :)
<tfheen> slomo,infinity: brasero given-back
<tfheen> slomo: it still failed to build
<slomo> tfheen: hrm... ok, let's wait an hour or something, i would've assumed that the gtk binaries are already in the archives for ppc too as they were there for amd64 already
<tfheen> slomo: I'm off to bed, but if you ask me about it tomorrow, I'll give it back unless infinity beats me to it.
<slomo> tfheen: ok, not so urgent anyway... good night :)
#ubuntu-devel 2006-09-30
<keescook> man, I am so glad that ffmpeg isn't internal to xine anymore.  :P
<sfllaw> mdz: The cpio thing will probably be done Sunday.  It looks like the LSB install is taking a while in vmware.
<mdz> sfllaw: ok
<jdong|am164> jdong: ha! you'll never turn me off!
<jdong|am164> jdong: come down to the basement... shut me off... come on... I'm waiting....
<jdong|am164> jdong: what's that? arthritis? can't walk? HA!
<Chipzz> is there a sane way to see why apt would pull in a shitload of packages when upgrading one packages?
<Chipzz> like debug what apt thinks?
<mvo> Chipzz: try "apt-get install -o Debug::pkgDepCache::AutoInstall=true"
<Chipzz> mvo: thx
<mvo> Chipzz: if that does not work try: -o Debug::pkgProblemResolver=true in additon to the other one
* mvo goes to bed now
<martii> hi
<martii> looks like network-admin is broken?
<martii> latest edgy and pre beta are unable to save gateway information
<minghua> martii: have you tried beta yet?
<minghua> martii: and is there a bug opened?
<martii> minghua: I've just updated to beta
<martii> minghua: no change
<martii> minghua: network profiles are useless now
<martii> minghua: I found this bug on launchpad but it seems problem still exists
<minghua> martii: please add a comment to the bug that beta still has the problem, and anything you think useful for fixing the bug
<martii> minghua: I'll do
<AlinuxOS> martii, I agree too...for me it's the same :(
<mc44> hmm was there an email to ubuntu-devel-announce about the beta release I missed?
<ajmitch> mc44: it was on ubuntu-announce
<mc44> ajmitch, aha! not subscribed to that :-/
<Viper550> Noticed no one was responding in ubuntu-artwork, so I thought I'd pimp my new Usplash theme here
<Viper550> https://wiki.ubuntu.com/Artwork/Specs/EdgyArtworkPlan/Produce/Incoming/Viper550
<tseng> does it really need the old theme showing through behind the circle
<Viper550> old theme? No, that's part of the new wallpaper, it's like a portal to the future
<jdong> grr... sorry about the cruft from jdong|amd64 earlier... my friends are such asses....
<AlinuxOS> martii, do you filed this network-admin bug ?
<BenC> who handles the livecd initrd's?
<BenC> anyone know why an ide driver, which is in the ide-modules udeb would not be on the desktop cd's initrd?
<tseng> BenC: tfheen is the cd build master
<tseng> and not likely to be awake
<BenC> tfheen: ping
<BenC> filed a bug on casper, hopefully that takes care of it
<lritter> <minghua> lritter: what is bci hinting?
<lritter> <lritter> byte code interpreted hinting
<lritter> <lritter> some fonts contain information on how to correct pixels on lower resolutions
<lritter> <lritter> such as the ms core fonts
<lritter> minghua: the technique is licenced by apple, but can be turned on
<lritter> minghua: it used to be enabled by default, and it is enabled on the 6.06 live cd
<minghua> lritter: yeah, I know what bytecode hinting is
<minghua> sorry I was checking for something
<lritter> minghua: but with one of the last system updates, autohinting was being turned on, which tries to circumvent the patent by "guessing" correct pixel spots - which makes the fonts look nowhere similar to what they should look like
<minghua> lritter: show your result of "debconf-show fontconfig-config"
<lritter> minghua: wait, i upload a screenshot
<lritter> minghua: it shows the settings and also the font appearance
<lritter> minghua: http://www.leonard-ritter.com/files/images/tahoma_not_native.png
<lritter> minghua: as you see, the font is supposed to be tahoma
<lritter> minghua: i set it to full hinting and no antialiasing to dramatize the effect
<minghua> lritter: that looks like bytecode hinting to me
<lritter> minghua: it isnt
<minghua> what is the result you want?
<lritter> minghua: it is typical autohinting. if it was bytecode, it would look like tahoma
<lritter> minghua: sec, i'll try to find a sample
<minghua> and I would like to see a screenshot with anti-aliasing
<lritter> okay
<minghua> lritter: also please show your gnome font setting (Desktop -> Preferences -> Font)
<lritter> minghua: http://www.leonard-ritter.com/files/images/tahoma_antialiased_autohinting.png
<lritter> minghua: as you can see, distances between letters are messed up
<lritter> minghua: i'm trying to find a screenshot with proper hinting of tahoma
<minghua> lritter: so that's the only thing you don't like?
<lritter> "the only thing"
<minghua> lritter: not the shape of the characters, but the inter-character distances?
<lritter> no, that is one of the features that show most closely how much it diverges from the original
<lritter> the shape is also nowhere what it should be
<theCore> bug 58511
<Ubugtu> Malone bug 58511 in firefox "[edgy Knot-2 CD]  firefox's fonts are uglified (not antialiased)" [Undecided,Confirmed]  http://launchpad.net/bugs/58511
<lritter> the same goes for verdana, segoe ui, consolas, and a lot of other fonts
<lritter> theCore: thats a different issue
<lritter> theCore: i looked it up as well
<theCore> lritter,  I know, but I thought it was relevant to point it out
<lritter> minghua: i could try booting a live cd in the vm and do a few screenshots there, that should make it apparent.
<minghua> lritter: I don't suppose the live CD uses Tahoma font?
<lritter> true, but it uses bitstream sans vera, which also looks entirely different
<lritter> with bci rendering, that is
<lritter> i was thinking about switching back to an earlier version of freetype
<lritter> but that breaks dependencies
<lritter> minghua: i can also quickly copy tahoma on it to show it
<minghua> lritter: I don't know what shape you are looking for, but as for the spacing, it's a know issue, and strictly speaking it's kerning
<minghua> bug #34178
<Ubugtu> Malone bug 34178 in pango "Pango kerning is bad" [Unknown,Unconfirmed]  http://launchpad.net/bugs/34178
<minghua> lritter: that's your bug for spacing
<lritter> yes, that might be an issue with the autohinter, but not with bci
<lritter> as said, with bci, everything is properly done
<lritter> i had these errors before with arch linux and gentoo
<lritter> and managed to sort them out myself
<lritter> this time i'm trying to sort it out without recompiling freetype myself
<minghua> lritter: no, that affects bytecode hinting too, read the upstream bug
<lritter> not all apps use pango, tho.
<minghua> lritter: that's a pango issue, not a freetype one
<minghua> lritter: so you see the same spacing problem in KDE apps?
<lritter> let me see.
<minghua> lritter: and it doesn't happen in live CD because Bitstream Vera doesn't have GPOS tables in their font
<lritter> yep, same problem
<minghua> hmm, that's probably a different thing then
<lritter> as i said, it is exactly what i said. :)
<lritter> my best guess is: latest build of freetype hasn't built in bci rendering at all, which is not uncommon.
<lritter> however i don't know how to check this. i had a look at the build package, and it patches in some defines that should enable it 
<minghua> very uncommon in Debian land, I would say
<lritter> its patented, still
<minghua> Debian freetype has been having bytecode enabled for years
<lritter> however, i think the problems started with the same time that gnome's font setting dialogue got its performance right
<minghua> lritter: open a bug, paste your gnome _and_ kde screenshot
<lritter> after one update, changing smoothing or hinting had an immediate and distinctive effect. it was broken before
<lritter> so perhaps it has got to do with the new fonts.conf
<minghua> lritter: and I would suggest using bitstream vera or dejavu font
<lritter> or the way this is managed
<minghua> lritter: and maybe a live CD screenshot, too
<lritter> minghua: i opened a bug already, i'll just add some more info.
<lritter> minghua: thank you for your help
<minghua> lritter: number please?  I would like to subscribe to that
<lritter> 60760
<minghua> lritter: thanks
<lritter> minghua: i added screenshots
<minghua> lritter: with vera I see what you means now
<minghua> lritter: it seems all the glyphs are squeezed horizontally
<minghua> lritter: but honestly I don't think that's the result of autohinting
<minghua> (unless autohinting has changed a lot)
<lritter> minghua: this is more than squeezing. check the s shapes.
<lritter> minghua: i'm right, please, just believe me :)
<lritter> minghua: bitstream sans vera is a bad example because it looks kind of similar with both modes
<lritter> minghua: with tahoma and similar, the effect is much more dramatic
<minghua> lritter: okay then.  I am just talking from my pre-2.2 freetype experiences
<minghua> lritter: oh, and as I said earlier, you should show something KDE too to show it's not the pango bug
<minghua> lritter: and I agree with you that the glyph shapes are ugly now
<lritter> minghua: i have a lot of experience with fonts, design, pixel graphics and so on... i'm overly sensitive to these things ;)
<lritter> minghua: ok, let's just wait. i'm not willing to kde'ify my machine unless it is really neccessary ;)
<infinity> slomo: brasero/ppc built.
<minghua> lritter: use ft-string then
<minghua> or something similar in freetype2-demos
<lritter> ok
<BHSPitLappy> hi.
<BenC> who should I report boot/install tests for beta to?
<KurtKraut> should appot run with nice -5 ?
<KurtKraut> Here it is running with +5, so, the system absolutely freezes when apport runs.
<infinity> There, 53 queue items processed out of NEW, that should be my good deed for the weekend.
<fabbione> infinity: i was just talking to Etienne about bzr ubuntu2 hanging on a selftest on the buildd. it doesn't happen locally.
<fabbione> i sponsored ubuntu3 for him to disable the test but it would be good to know why it hangs
<fabbione> infinity: if you can get sometime on monday to look at it, it would be good
<fabbione> perhaps save ubuntu2 somewhere
<infinity> LP will save it.
<fabbione> oh right
<infinity> Disabled the whole testsuite, just because of one hanging test?  That seems like overkill...
<fabbione> infinity: yeah well he wants it that way in the meantime
<fabbione> but i told him to contact you to trace the hang
<infinity> Gar, rothera is running that "hey, you don't actually want to know what's running when you type 'ps' do you?" security patch.
<fabbione> he wants to fix it
* infinity grumbles.
<infinity> Makes it a bit tough to trace the hang.
<fabbione> meh
<fabbione> infinity: ask elmo to fix the kernel?
<infinity> Could also be responsible for the hang, given that it's a wait test.. Hrm.
<infinity> It might be trying and failing to walk process trees to wait on something.
<Hobbsee> infinity: nice, thanks :)
<fabbione> dunno
* infinity should look at the source for the test.
<fabbione> infinity: i don't think it needs to be fixed NOW
<fabbione> infinity: monday or so is fine
<infinity> Yeah, I'm just curious now.
<fabbione> ehehe
<infinity> I think it's hanging on test_32_lock_wait_succeed
<infinity> Which does this:
<infinity>         """Succeed when trying to acquire a lock that gets released
<infinity>         One thread holds on a lock and then releases it; another 
<infinity>         tries to lock it.
<infinity>         """
<infinity> Which sounds like the sort of thing this patched kernel could be responsible for blowing up...
<infinity> Hrm, vernadsky doesn't have that sketchy kernel, let's test a theory.
<infinity> Oh, wait, yes it does.
<infinity> Argh.
<fabbione> EtienneG: so according to infinity it might be a kernel bug. does that test rely on ps output? (or similar)
<EtienneG> I would not know, really
<EtienneG> we should ask the bzr guys
<EtienneG> a kernel bug ?  Triggered from userspace ?
<EtienneG> my my
<EtienneG> is this something that would reproducable locally
<EtienneG> ?
<fabbione> EtienneG: no, it's a "bug" due to a security patch being extremely restrictive. It's fixed in recent kernels but not on the buildd
<EtienneG> ok, I see
<EtienneG> infinity, bzr just built successfully
<EtienneG> bzrtools had failed because it build-depend on versionned bzr
<EtienneG> do you know if it will restart automatically, or do I have something special to do ?
<infinity> It'll retry automatically.
<Lathiat> i think that works properrly
<fabbione> EtienneG: shell out some money will help :P
<infinity> It better work properly, I wrote it to do so.
<EtienneG> cha-ching !
<EtienneG> infinity, thanks
<fabbione> infinity, Lathiat : you are both very cheap :P
<infinity> Err, WTF.  It didn't dep-wait.
<infinity> Great.
<infinity> I wonder if I have problems with ~ versions or something.
* infinity puts that in his TODO, and resets the build manually.
<EtienneG> thanks a lot
<EtienneG> infinity, excuse me again
<EtienneG> bzrtools failed to build, build-dep on bzr >= 0.11~rc1
<EtienneG> 0.10 installed
<EtienneG> I guess 0.11~rc2 have to been pushed all the way through yet
<infinity> Yeah, I know.  I was kicking the build to watch the log, not because it would work. :)
<infinity> Trying to find the word-splitting error in my regex that's making it fail on ~ versions.
<EtienneG> ok, I see
<infinity> Oh, hah.  I'm an idiot.
* infinity goes to fix.
<EtienneG> I aspire to that level of idiocy myself !
<infinity> Any python gurus know if ~ is a reserved character in the re module?
<Fujitsu> infinity, if it breaks things, probably yes.
<infinity> I'm wondering if it will, not if it has. :)
<infinity> Oh well, only one good way to find out.
<tfheen> BenC: pong
<infinity> D'oh, was too late to test it. :)
<infinity> EtienneG: It's built now, though. :P
<EtienneG> excellent
<EtienneG> I feel *so* much lighter
<EtienneG> with that being said, I finally head off to sleep
<infinity> 'Night.
<EtienneG> have a nice week-end everybody
<EtienneG> thanks again fabbione and infinity 
<slomo> infinity: thanks :)
<Tonio_> mdz: ping ?
<Tonio_> hi all
<Tonio_> mdz: just replied to your reviews, dont be confused, kmplayer isn't an mplayer frontend (I know...... stupid)
<seb128> gnomefreak: thank you for not pinging me about the desktop-effects meeting yesterday :p
<seb128> I've just be reading the logs on the wiki because I browsed the wiki logs page after catching up with ubuntu-desktop mail and a "MeetingLogs keeping them updated" mention
<gnomefreak> seb128: i figured you were busy
<seb128> I was not aware of the meeting
<gnomefreak> ah
<gnomefreak> sorry
<seb128> and I would like to have attended
<seb128> mjg59: please don't patch libwnck for those changes mentionned
<seb128> I want some words with those guys who don't try to work with us and complain then they have to maintain their version of the package out of Ubuntu first
<gnomefreak> seb128: we didnt get much done. me and dbo are gonna get together when my fever subsides and go over the notes that i took for it. 
<seb128> "reggaemanu      and i'm tired to re-package it everytime"
<ajmitch> seb128: I have spiftacity updated, fwiw
<seb128> grrrr
<gnomefreak> seb128: thats sounds fine 
<seb128> what about contacting the maintainer?
<seb128> instead of "re-package it everytime"
<seb128> ajmitch: cool ;)
<ajmitch> I haven't tested it, of course :)
<seb128> gnomefreak: who is that reggaemanu guy?
<gnomefreak> i dont know him but hes a beryl packager/developer  
<seb128> did somebody spoke to him about how people work with maintainers usually?
<gnomefreak> seb128: i just asked DBO to enter. he knows him
<seb128> like than mailing them is welcome
<seb128> hi DBO
<DBO> hi
<seb128> let's move on #ubuntu-desktop if you are fine with it
<seb128> better than abusing that chan ;)
<DBO> #ubuntu-xgl you mena?
<DBO> mean*
<seb128> right
<DBO> #ubuntu-desktop is already in use for the desktop team
<DBO> and #ubuntu-xgl is a troubleshooting channel for beryl/compiz... its name is a bit... out of date now yes
<DBO> of course you already know all this...
<DBO> you really want to transplant all that troubleshooting in there?
<DBO> or am I confused about whats going on?
<seb128> DBO: I want to speak to whoever fork the package I'm working on without trying to contact me and rant then that he's tired to repackage it everytime
<seb128> DBO: that's not the way to work
<DBO> you mean compiz?
<seb128> DBO: that's making everybody waste efforts, that's suboptimal for users, that's creating extra bugs, etc
<DBO> seb128, Im not getting a full story here
<seb128> DBO: read #ubuntu-xgl :p
<pitti> seb128: did your gdb upload help for the gaim/rhythmbox debugging?
<seb128> pitti: I don't know, it made it stop crashing on my xchat-gnome testcase
<pitti> well, that's something
* pitti hugs seb128 
<seb128> pitti: gaim stopped crashing, it just DoS my box by eating over 2G of memory
<pitti> 'just'
<seb128> yeah :/
<seb128> that was not apport
<pitti> seb128: due to gdb or to gaim itself?
<seb128> that gaim eating all the RAM and swap
<seb128> and the 10min are the time the kernel takes to eject it
<seb128> gaim
<Riddell> ogra: http://cniehaus.livejournal.com/27154.html
<Viper550> Does anyone not like the current Usplash theme?
<Viper550> (on edgy)
<_ion> Did someone claim it's going to be the final theme, instead of just a placeholder?
<Viper550> No, it's a placeholder, but not many people like it
<imbrandon> this isnt the place for that disscussion though
<Viper550> I made a nice candidate for default on my wiki page: https://wiki.ubuntu.com/Artwork/Specs/EdgyArtworkPlan/Produce/Incoming/Viper550
<Viper550> But...no one is in ubuntu-artwork (well, active anyway)
<mjg59> A black background is a better choice than a brown one
<Viper550> Yeah, that's what I made
<Hobbsee> nice candidate
<Viper550> Yeah, it's kinda got a "portal to the future" like look to it
<Viper550> If you wanna discuss it more, I'm in #ubuntu-artwork right now
<tseng> if the future is a brown gradient you can count me out
<tseng> :)
<Viper550> No, the future is what comes AFTER the bootsplash!
<Viper550> I basically cropped in a bit of the new default wallpaper and added a masking effect to it
<shining> Viper550: looks nice
<Viper550> Thank you! I kinda based it off the design of the Xubuntu splash
<_ion> mjg59: Btw, usplash falls back to 800x600 now (great!), but the image is corrupted. It looks like it handles the gfx memory as if the resolution were 1024x768. Unfortunately i don't have a camera. Is it possible to take a screenshot of the usplash?
<Viper550> Not unless you use Vmware
<Viper550> But then, it will work correctly in VMware
<mjg59> _ion: Not really, I'm afraid
<mjg59> _ion: Oh, I bet I know what the problem is. I'll take a look at the source.
<Viper550> So, how do you compile Usplashes for Edgy?
<bddebian> Howdy
<atoponce> are there any plans to create a 50MB or 180MB netist, like debian?
<BenC> I think those are contained in the installer directories
<atoponce> so is it possible to burn such a disc then?
<froud> Looking at http://ubuntu-releases.cs.umn.edu//6.06/ "Alternate install CD" it states installs on systems with less than about 192MB of RAM. Yet when I look at the installer Help it shows a minimal requirement of 32MB. What am I not understand?
<Treenaks> 32 < 192 :P
<ivoks> froud: 32 is needed for install, so you can install system with less than 192, but more than 32
<froud> ivoks: Ah ha, thx
<ivoks> froud: thing is that desktop CD doesn't work with =< 192MB
<ivoks> so alternate CD "fixes" that
<froud> kewl
<froud> got it now
<elmo> ehm, is the fact that the number of virtual desktops I have got downgraded to 2 considered a feature?
<Chipzz> elmo: that's because the default nr of desktops was 4, you left it that way (so no explicit setting in gconf), default changed, your setting changed
<elmo> Chipzz: how do I change it back?
<_ion> Duh. Right-click the workspace switcher and choose preferences.
<elmo> oh, never mind - I was looking in System -> Preferences
<seb128> elmo: what is the question?
<elmo> seb128: I was just thrown by the fact that the number of my desktops got cut in half on upgrade to edgy
<seb128> ah
<seb128> Mark asked to change the default number from 4 to 2
<seb128> if you never changed it the upgrade will pick the new default
<elmo> ok, next stupid question - my network status applet has gone into some widescreen state, it's like, horizontally elongated 
<Chipzz> got bitten by that too
<seb128> other way it respects your user setting
<seb128> elmo: known bug, will be fixed before edgy
<elmo> seb128: cool, thanks
<_ion> I really don't see how anyone could get along with only 2 virtual desktops. But no problem, it can be increased easily.
<seb128> np
<seb128> _ion: most people "get along" with 1 desktop using window
<_ion> seb: That's because they don't know about virtual desktops. As soon as they see two of them and "get it", they'll want more. :-)
<seb128> _ion: right, that's not like changing the number was hard ;)
<seb128> _ion: Mark argued than 2 make the feature easier to notice and take less space on the panel
<Chipzz> seb128: I don't see how you can fix that really
<seb128> Chipzz: fix what?
<Chipzz> since there's no way you can know if the user really wanted 4 desktops, or the default nr of desktops
<Chipzz> oh
<seb128> Chipzz: "known bug, will be fixed before edgy" was about "my network status applet has gone into some widescreen state"
<Chipzz> your were referring to the network...
<Chipzz> yeah
<_ion> Dynamically created virtual desktops would be interesting. The window manager would always have one desktop that doesn't contain any windows. As soon as a window is opened (or moved to) there, a new desktop would be created.
<elmo> usplash is also broken for me, but I think that's a couple of known bugs
<mdz> elmo: if it's the one where the artwork is missing after upgrade, I just fixed that one
<mdz> bug 61313
<Ubugtu> Malone bug 61313 in usplash "Usplash artwork missing on upgrades" [Medium,Fix released]  http://launchpad.net/bugs/61313
<elmo> mdz: ah, excellent, I'll try that once it filters through to the archive
<elmo> thanks
<mdz> oh alternatives, how I despise thee
<LaserJock> heh
<elmo> hmm, the new font/font rendering in gnome-terminal is going to take some getting use to
<max_> How ready is edgy?
<Treenaks> it's in beta
<mdz> elmo: I didn't notice a difference
<mdz> elmo: or you mean relative to xterm?
<Treenaks> elmo: font rendering issue in gnome-term?
<elmo> mdz: nope, relative to dapper gnome-terminal
<elmo> Treenaks: not necessarily an issue, it just looks different - like it's doing AA or subpixel hinting or something and wasn't before
<elmo> f stems look very thin, the horizontal cross of t's very thin too etc.
<Lure> mjg59: ping
<zul> elmo: amd64 xen 2.6.17 built im just putting the finishing touches on now
<keescook> has anyone gotten pbuilder and schroot to work together?
<keescook> I want to use lvn snapshots (which schroot understands) for doing clean builds.
<_ion> keescook: Use sbuild
<_ion> It supports schroot.
<keescook> _ion: ah-ha, cool, thanks.
<Fjodor> BenC: ?
<BenC> Fjodor: ?
<Fjodor> BenC: Hi again. I upgraded to edgy, and am ready to report on that "no frequency scaling problem". So far, I'v found a small something
<Fjodor> BenC: in acpi-cpufreq.
<Fjodor> BenC: Trying to load it complains about unknown symbol cpu_online_map, which is an smp-ism. Problem and patch is reported in http://www.gatago.com/linux/kernel/6121818.html
<Fjodor> Search for +#ifdef CONFIG_SMP
<BenC> Fjodor: ok, thanks
<Fjodor> BenC: However, I'm pretty sure it will complain about "No such device" as does speedstep-centrino, when it does work
#ubuntu-devel 2006-10-01
<rouzic> Hi all
<rouzic> I have a problem with a wifi in the Macbook and Beta Kubuntu Edgy
<mdke_> BenC: still here?
<BenC> mdke_: yeah
<mdke_> BenC: hi. Did Matt Nuzum ask you about a problem with some servers network cards with the dapper kernel?
<BenC> mdke_: Can you be more specific about the problem..I'm not so good with names :)
<mdke_> BenC: sure thing, I guess he hasn't :) Canonical rents some dedicated servers for locoteams and such, Matt manages them. When upgraded to dapper, they don't see the network and can't be reached.
<mdke_> eth is VIA Technologies, Inc. VT6102 [Rhine-II]  (rev 78)
<mdke_> have you heard anything about similar problems?
<jdong> hmm, is that the via quirks thing again?
<zul> no thats something else probably
<mdke_> I don't know anything else about it than that, except that Breezy has no problem
<BenC> no, never heard of that problem before
<mdke_> I guess I don't even know for sure it's a problem with the network card or the kernel, but that sounded to me like a probable cause
<BenC> mdke_: is it using latest dapper-security kernel?
<jdong> hehe, that sounds like a catch-22 to me... upgrading to dapper-security to fix a network card driver... :)
<mdke_> BenC: I can't tell you that, I haven't tried an upgrade away from Breezy on the server I manage. But it is likely that it was only tried with an early dapper kernel, and then people reverted to Breezy kernels
<mdke_> it's a tricky thing to debug :)
<mdke_> BenC: ok, since it hasn't rung any bells, we'll file a bug
* Fade wonders if anybody here is running edgy on a powerpc box
<BloaSE> What is better linux or windows?
<Fade> lol
<Fade> ham? I thought you said grasshopper!
<Fujitsu> BloaSE, please stop trolling. You do this too often.
<BloaSE> what is better lamb or beef Rogan Josh?
* mode/#ubuntu-devel [+o tseng]  by ChanServ
<tseng> please take it somewhere else.
<Fade> 'cause I have a bear of an xemacs bug that's really cramping my style. ;)
<Fade> and I don't know if this is peculiar to my machine, or if it's all over the place.
<tseng> Fade: have you searched launchpad?
<Fade> of course. ;)
<tseng> have you filed a new bug?
<Fade> yes
<tseng> ok then :)
<Fade> it isn't new so much as almost three weeks old, tho. ;)
<tseng> maybe imbrandon is a ppc emacs guy
<Fujitsu> He's more nano, AFAIK :P
* mode/#ubuntu-devel [-o tseng]  by tseng
<tseng> nano, how useful
<Fujitsu> I'm a Vimmer, myself.
<tseng> i have seen people setup syntax hilighting and some decent stuff in nano, though
<BloaSE> The process for install ATI cards under ubuntu is rather long and drawn out, linux need's what windows has in .exe
<tseng> BloaSE: if you don't have anything sensible to say, please leave, you've been asked twice
<tseng> final warning
<BloaSE> ok
<tseng> phew.
<Fujitsu> Yeah.
<Fade> this is the bug:
<Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/58856
<Ubugtu> Malone bug 58856 in xemacs21 "xemacs segfaults on edgy powerpc system" [Undecided,Unconfirmed]  
<Fade> gnuemacs is also bjorked. ;)
<tseng> have you looked at a backtrace?
<Fade> although less so. gnu doesn't segfault, it just displays a frame with little empty squares instead of letters.
<Fade> yeah, they're in the bug report.
<tseng> fun font problems
<Fade> it's interesting. I've built upstream sources all the way up to bleeding edge, and they all fail the same way.
<Fade> but it's a biotch to have to boot OSX to get an XEmacs frame. ;)
<Fade> the gtk/gnome frame comes up, but dies spectacularly if you try to edit any of the faces.
<Fade> ++bummer :)
<Fade> anyhow, just thought I'd mention it; the fact that nobody has really seemed to bother about the report makes me wonder if it's just my system.
<Fade> unless emacs has become spectacularly unpopular in ubuntu circles. 
* Fade chuckles
* tseng hides away his vim window
<LaserJock> hmm xemacs+edgy+ppc might be the problem
<LaserJock> any 2 of those might give you significant amounts of people
<tseng> LaserJock: plain-old-emacs is broken
<tseng> according to Fade 
<Fade> on this platform.
<Fade> there's a screenshot of a gnuemacs frame in that bug report that's pretty amusing.
<Fade> http://librarian.launchpad.net/4132345/bad_emacs.png
<Fade> mithrandir was looking at it, but I think he got sidetracked. it's been sort of nuts around here lately. :)
<tseng> he was building the beta, which is no small task
<Fade> *nod*
<Fade> ah, this is a duplicate:
<Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/57586
<Ubugtu> Malone bug 57586 in xemacs21 "XEmacs segfaults on startup in Edgy" [Undecided,Unconfirmed]  
<fdsd> hey guys, I am trying to modify the usplash on the ubuntu live cd, where do I add the usplash.so file for the shutdown process I just get the usplash edgy test pattern when shutting down, do I stick it in the initrd file in /boot or the root of the cd inside casper? also should both initrd files be the same? thanks
<ZigGaag> Ubuntu rocks your fucking socks off.
<ZigGaag> =)
<_ion> mjg59: I posted a patch, https://launchpad.net/distros/ubuntu/+source/usplash/+bug/62865/comments/1
<Ubugtu> Malone bug 62865 in usplash "1024x768 with nVidia GeForce4 Ti 4800 SE: "screen init failed"" [Undecided,Unconfirmed]  
<ne78> Will the php5.1 version of edgy ship without PDO ? https://launchpad.net/distros/ubuntu/+source/php5/+bug/50353, it quite critical php5.1 is supposed to have pdo, The reason seem to be debian laziness (bug open for 254 days with "it will happpen someday") http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348882
<Ubugtu> Malone bug 50353 in php5 "Cannot install PDO and PDO Drivers in PHP5" [Undecided,Unconfirmed]  
<ne78> i see everybody is sleeping
<_ion> Yes.
<LaserJock> totally sleeping
<zul> very..
<_ion> It's cool how he was able to reach that conclusion within two minutes.
<zul> i think ill be doing what he is thinking...night
<zul> hi/bye ogra
<pascalFR> hello
<pascalFR> i'm trying to rebuild apt with debug but i obvioulsly need some lib
<pascalFR> Building program ../build/bin/methods/file
<pascalFR> ../build/bin/libapt-pkg.so: rfrence indfinie vers  pkgVendorList::end() const
<pascalFR> ../build/bin/libapt-pkg.so: rfrence indfinie vers  pkgVendorList::begin() const
<pascalFR> collect2: ld returned 1 exit status
<NthDegree> what about using apt-get build to download the source of apt-get and needed libs
<NthDegree> or rather apt-get build-dep
<pascalFR> NthDegree: see http://pastebin.com/797690    apt-get build did nothing
<minghua> pascalFR: a stupid question, but do you have build-essential installed?
<pascalFR> minghua:   yep :)
<pascalFR> minghua: I mean  installed :)
<minghua> pascalFR: sounds like a bug to me then.  maybe report it?
<pascalFR> to debian or launchpad ?
<tfheen> pascalFR: what does dpkg-checkbuilddeps return?
<pascalFR> tfheen:  dpkg-checkbuilddeps: error: cannot read control file debian/control: No such file or directory
<tfheen> run it from the apt-$versionnumber directory
<minghua> pascalFR: run "dpkg-source -x apt_0.6.45ubuntu14.dsc" first
<minghua> (then go into apt-0.6.45ubuntu14 and run dpkg-checkbuilddeps)
<pascalFR> ok it returns with rc=0
<minghua> pascalFR: are you building in a Debian system or Ubuntu system?
<pascalFR> ubuntu
<pascalFR> edgy beta1
<minghua> pascalFR: in that case if you want to report a bug I think launchpad is the correct place
<pascalFR> yes bug #57393 is where i updated info
<Ubugtu> Malone bug 57393 in apt "apt segfaults if /var/cache/apt/pkgcache.bin is wrong" [Medium,Confirmed]  http://launchpad.net/bugs/57393
<pascalFR> i wanted to debug apt  but cannot build it :(
<tfheen> pascalFR: how are you trying to build it?
<pascalFR> tfheen:  http://pastebin.com/797690
<tfheen> pascalFR: oh, reproduced here.  Please do file a bug on apt.
<pascalFR> http://groups.google.fr/group/linux.debian.bugs.dist/browse_thread/thread/521e5beaf6be773a/23e931854d46e248?lnk=st&q=pkgVendorList%3A%3Aend&rnum=1&hl=fr#23e931854d46e248 
<pascalFR> seems to be similar 
<ajmitch> excellent, xen got through NEW, thanks to whoever poked that theough
<pascalFR> dated from 2005  seems to be linked to gcc version
<pascalFR> bug #63299 submitted 
<Ubugtu> Malone bug 63299 in apt "apt cannot be rebuild from source" [Undecided,Confirmed]  http://launchpad.net/bugs/63299
<minghua> using "rebuild with noopt option" is probably a better idea
<pascalFR> bug #63299 submitted 
<Ubugtu> Malone bug 63299 in apt "rebuild apt with noopt option fails" [Undecided,Confirmed]  http://launchpad.net/bugs/63299
<shining> hi
<shining> isn't it weird to have different uuid for several partition ? is this known already ?
<shining> same uuid for different partitions
<shining> http://ubuntuforums.org/showthread.php?t=268529
<Burgundavia> shining: please file a bug, this is not the place for bug reports
<Burgundavia> shining: nor are the forums the correct locaiton
<shining> exactly, the guy is asking help for reporting it. so you have to know against which package this bug needs to be reported against, and check it hasn't been reported before / isn't known by the dev yet
<Burgundavia> shining: off the top of my head, no. file it and let the triagers sort it out
<tseng> hello Burgundavia 
<Burgundavia> hey tseng
<ajmitch> hi Burgundavia, tseng 
<tseng> hey
<sivang> hey slomo , Burgundavia  , tseng 
<rouzic> Hi desrt
<herzi> tfheen: ping
<tfheen> herzi: if you'd include content with your pings, that'd be a tad more useful than just "ping".
<herzi> tfheen: can you take a look at https://launchpad.net/distros/ubuntu/+source/casper/+bug/63277
<Ubugtu> Malone bug 63277 in casper "Doesn't work from USB devices" [Undecided,Unconfirmed]  
<tfheen> herzi: no, I'm not working today and have a friend I am going to chat with now.
<pygi> siretart: ping, hopefully you got my message :) I hope I can get a reply some day :P
<Treenaks> pygi: do you want it autographed too?
<pygi> Treenaks: no, not really :) Just wanna know if the patch is fine =)
<pygi> (against dvd+rw tools)
<siretart> pygi: I'm currently on a local LUG event, I'll look at it soon
<slomo> doko, doko_: ping?
<popey> guys.. should i report a kernel bug for an unsupported sound card?
<Treenaks> yes
<popey> i guess it will be a wishlist item?
<Treenaks> yes :)
* popey does so
<Treenaks> popey: what kind of card?
<popey> Creative Labs X-Fi Xtreme Music Sound Card
<popey> 06:06.0 Multimedia audio controller: Creative Labs Unknown device 0005
<Treenaks> sounds horrible :)
<popey> better than the in built nvidia one :S
<minghua> popey: make sure you show the "lspci -n" result in the report too
<popey> wilco
<Treenaks> popey: no I mean the name
<popey> aqhh
<popey> agreed
<popey> lspci -vv any good?
<Treenaks> popey: that gives you the subsystem ID number, also nice to know
<popey> \o/ bug 63352
<Ubugtu> Malone bug 63352 in linux-source-2.6.17 "Creative labs X-Fi sound card unsupported" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63352
<Treenaks> *\o/*
<popey> :)
<Treenaks> popey: you should add those to your ascii-art guy too :P
<popey> :)
<Spads> trigger.pl in irssi rocks: 14:00  4: -publics -regexp ':\)' -replace ''
<popey> \o/ utf-8
<Spads> \/
<giftnudel> popey: please say what card this actually is in the bugreport
<popey> i did
<popey> in the title
<popey> is that not sufficient?
<giftnudel> popey: oh, there is not more to it? Then that's fine, I didn't find it
<popey> :)
<popey> That's all it says on the spec for my pc online, and all the delivery sheet says
<|Danielle|> Nace una nueva red IRC: irc.ubuntuzone.org . Para conectarte: irc.ubuntuzone.org puerto 6668
<ogra> Riddell, thanks for the link ... i'm not affiliated with gallium in any way, even i got around 300 rant mails (some even threatening my health) within the last week ...
<zul> holy crap?
<ogra> Riddell,  that gives me a very disappointing view of the KDE community :(
<zul> ogra: threatening your health you gotta be serious
<ogra> yep
<ogra> "we'll find out where you live"
<zul> uh ok..
<ogra> "i'll hunt you down if you drop kdeedu "
<ogra> etc etc
<ogra> really mean stuff ...
<Lathiat> awesome :\
<Treenaks> ogra: hm.. scary
<lastnode> i missed the link, can someome repaste? (timed out)
<ogra> its not the majority, but there are some really evil ones among them
<zul> thats ridiculus over a piece of software
<ogra> lastnode, http://cniehaus.livejournal.com/27154.html
<ogra> we have constant space constraints on the edubuntu CD due to including kdeedu (it just pulls in to many unused deps) so a community group started to write a new frontend for the kalzium data
<ogra> (in the spirit of ubiquity or hwdb-gui-(kde,gnome))
<zul> still...ridiculous
<ogra> right
<lastnode_> what i find hillarious is that most of these guys probably couldn't hurt a fly
<lastnode_> television has made everyone a gangster, seriously
<lastnode_> :\
<zul> more like the internet
<RicardoPerez> pitti: ping
<RicardoPerez> pitti: ping
<bddebian> Howdy folks
<highvoltage> howdy!
<_ion> howdy-how
<bddebian> Heya highvoltage, _ion
<welshbyte> hey bddebian 
<welshbyte> oops, this isn't -motu
<bddebian> welshbyte: Yeah, don't talk to my lowly arse in here ;-P
<BenC> tfheen: ping
<theCore> I created a team, ubuntu-helpteam. and I would like a mailing list. Who should I contact?
<mc44> theCore, mailman@lists.ubuntu.com
<theCore> mc44: thanks
<tfheen> BenC: yo
<jdong> BenC: can you fix bug 61235 pretty please?
<Ubugtu> Malone bug 61235 in linux-source-2.6.17 "USB mass storage stops working after a while" [Undecided,Confirmed]  http://launchpad.net/bugs/61235
<BenC> tfheen: not sure if we still need admin approval for uploads, but linux-restricted-modules, linux-meta and linux-souce-2.6.17 are on their way (lrm and linux-meta are already there)
<tseng> BenC: things are being accepted
<BenC> fixing ubuntu-6.10 targeted bugs
<BenC> ok
<tseng> without intervention afaik
<BenC> I noticed it didn't say it was awaiting admin approval, but wanted to be sure
<tfheen> BenC: you don't need approvals now.  Things will be announced when they lock down a bit for RC and release.
<BenC> jdong: working on it
<BenC> jdong: Please mark it for ubuntu-6.10 milestone and assing it to me so I don't forget?
<BenC> *assign
<_ion> mjg59: Hi
<RicardoPerez> pitti: ping
<mxpxpod> where do I report bugs with the installer cd?
<ivoks> launchpad.net/malone
<fdsd> hey guys, in Knot3 ubuntu, the powerpc livecd does not power off the machine when you halt nor does it restart the computer, anyone know how I may fix it?
<fdsd> it just hangs at a black screen with a - cursor at the top left
<beuno> fdsd: support for edgy is in: #ubuntu+1
<beuno> this is only for development
<fdsd> beuno, I am developing software for the livecd
<beuno> :X
<tfheen> fdsd: press enter and it should work
<tfheen> fdsd: it's a known bug.
<fdsd> oh really
<fdsd> interesting, it probably is because it says press enter to halt but its not visible
<fdsd> do you know what I can modify to change that?
<Toadstool> hi everybody
<Toadstool> any buildd admin around?
<tfheen> Toadstool: if it's just a simple thing, sure, if not, it's my sunday evening. :-P
<Toadstool> http://librarian.launchpad.net/4565707/buildlog_ubuntu-edgy-i386.xffm-proc_4.5.0-0ubuntu1_FAILEDTOBUILD.txt.gz <-- ./configure could not find ps
<Toadstool> tfheen: oh, right, sorry :)
<tfheen> Toadstool: curious build failure, unsure why that happened.  You probably need infinity, though.
<shawarma> Toadstool: it doesn't build-depend on gs?
<tfheen> shawarma: gs != ps
<Toadstool> tfheen: ok, i'll ask him tomorrow
<shawarma> tfheen: Doh...
<Toadstool> thanks
<geser> how should the update from imake and makedepend (dapper) to xutils-dev (edgy) happen?
<shawarma> tfheen: the buildd's have biuld-essential installed, its dependencies and nothing else, right?
<tfheen> shawarma: they should have essential: yes and priority: required installed too.
<shawarma> tfheen: ah, ok.
<ajmitch> morning
<pygi> hey ajmitch 
<jasper> Hello can someone explain me how to edit a file that has root privileges?
<Mez> !support
<jasper> !support
<Mez> oh, ok - try #ubuntu for support please jasper
<HiddenWolf> jasper: #ubuntu-nl
<jasper> oh oke wrong channel :)
* lamont wonders why he can only run glabels on his laptop as root.
<mdke_> update-manager -d doesn't work anymore for upgrading to the development version?
<_ion> mdke: --help
<mdke_> _ion: yeah. That says it works, but running it on my dapper doesn't see Edgy
<_ion> Um. My point was the "-c" in the --help listing. AFAIR dapper has it, too.
<_ion> I might remember incorrectly, though.
<mdke_> _ion: that appears to be for new stable distributions, whereas -d is for new devel distributions. At least that's my interpretation of the --help dialogue
<mdke_> lemme try -c
<mdke_> no, nothing there either
<fdsd> hey guys, I want to burn two types of livecds to a disc, for example, I have gotten ubuntu powerpc livecd 6.06 and x86 livecd down to 200mb, I want to make one disc that will allow me to boot off both, I can make the x86 iso on the first session so PCs can boot off it, and put the powerpc livecd on the second session so I can hold down option at boot on a mac and boot off it, but my question is how do I burn both Isos to a disc?  I assum
<fdsd> e mkisofs or cdrecord can do it.. Any ideas?
<LaserJock> mdke_: worked just fine for me
<mdke_> LaserJock: hmm.
<_ion> I'd assume you'd need '-c -d'
<mdke_> _ion: yes, that works... although it sounds weird
<mdke_> thanks for getting it working anyhow :)
<_ion> It would be nice if --help told -c is not implied by -d.
#ubuntu-devel 2007-09-24
<TheMuso> c
<TheMuso> argh wrong tab
<RAOF> Heh
* jdong bawks
<jdong> just ran past the /lib/linux-restricted-modules/.nvidia_new_installed snafu....
<jdong> tha'ts a bit ridiculous, isn't it? shouldn't postrm of nvidia-glx-new delete that file?
<jdong> otherwise after install n-g-n and trying to revert to any other n-g will fail
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<ajmitch> hey pitti
<ajmitch> how's it going?
<LucidFox> Would it make sense to request a freeze exception for Theora at this stage?
<pitti> hi ajmitch! pretty well
<jdong> hasn't that been answered a day or two ago?
<jdong> as a no, ABI/API breakage, ffmpeg stack affected, too risky?
<pitti> I only said that there is no chance if it does break abi/api
<pitti> but at this point I don't think that it is a good idea for beta at least
<jdong> LucidFox: what does the new theora provide?
<LucidFox> jdong> a new decoder implementing the complete specification
<LucidFox> given how the Debian package name is still libtheora0, it probably doesn't break ABI - but it could have been Debian's oversight
<tepsipakki> pitti: hey, there are two X driver updates that the X-SWAT would love to see in beta;
<tepsipakki> nv 2.1.5: hasn't changed that much, but LVDS fix for G80 chips on some laptops, also adds support for a number of new chips (only added the pciid's so the driver would load)
<pitti> tepsipakki: that sounds reasonable (I'd like to see a diff, though)
<pitti> tepsipakki: can you please file FF exception bugs, attach diffs, and I'll review them there?
<tepsipakki> ati 6.7.194: upstream says that 6.8 is close. This fixes, for instance, a crasher when you use Xv and change the desktop in compiz
<tepsipakki> pitti: sure, this was just a heads up notice :)
<pitti> oh, yay for more crash fixes :)
<tepsipakki> also, it fixes more blank screen issues
<pitti> tepsipakki: heads-up appreciated (for CD building planning, etc.)
<tepsipakki> pitti: thanks, I'll do those when I get to work
<StevenK> Morning pitti!
<StevenK> pitti: There's a new gnome-build, do you want to rescue it from NEW?
<pitti> StevenK: will do a bit later, when I'm back at my desktop (can't get to the DC from here)
<fabbione> oh interesting bug
<StevenK> pitti: Sounds fine. I'm just looking at the one and only rebuild for it.
<fabbione> pitti: wanna have some fun? bug #144363
<ubotu> Launchpad bug 144363 in sysvinit "/lib/init/mount-functions.sh: domount does not check if a mountpoint is already in use" [Undecided,New]  https://launchpad.net/bugs/144363
<StevenK> Hrm. lamont touched sysvinit last. :-P
<fabbione> StevenK: no change upload.. and this is a very old bug
<fabbione> i just found enough motivation to look at it today
<fabbione> need to understand why NFS mounts are not mounted at boot anylonger
<lamont> StevenK: yeah - I just touched it lightly. :-)
<lamont> pitti: I just filed the sync request for expect
<lamont> (thought I did that earlier... maybe I did.... )
* lamont should sleep soon
* ScottK knows the feeling.
<pitti> fabbione: eek, so many mounts on top of each other? strange, why does that happen only to you?
<fabbione> pitti: i wonder if this is because this machine is a sid install upgraded to warty/hoary/breezy/dapper/edgy/feisty/gutsy?
<fabbione> pitti: it might also be because i have stuff installed that i am sure you don't
<pitti> fabbione: either sounds reasonable
<fabbione> grep domount * -l
<fabbione> mountdevsubfs.sh
<fabbione> mountkernfs.sh
<pitti> fabbione: I reinstall my machines twenty times with every release
* lamont has found that gutsy stock install differs from breezy->dapper->edgy->feisty->gutsy
<fabbione> lamont: way different. yes i noticed too
<lamont> pitti: long range upgrade testing is a _GOOD_ thing... we should do more of it..
<lamont> then we'd find things like interactions between the current stuff and evms, for example...
<lamont> which was stock on dapper? and not stock on gutsy
<lamont> anyway, time for this one to sleep.
* ScottK recently did a Dapper --> Gutsy direct upgrade.  That was "Fun".
<fabbione> pitti: i checked and indeed domount is invoked a bunch of times
<fabbione> pitti: could you show me your fstab?
<fabbione> pitti: that looks like the only tihng that might be deeply different
<pitti> lamont: I agree
<pitti> fabbione: there's nothing particularly worth mentioning about it, except that my 'post-ubuntu-install' setup script overwrites the uuid ones with my ancient /dev/xxx names
<fabbione> pitti: do you have /var/run and /var/lock entries in there?
<fabbione> because mine doesn't
<pitti> fabbione: but I do have uuids on my desktop, and it doesn't happen there either
<pitti> fabbione: nope, and it's not supposed to
<fabbione> pitti: a grep for domount in /etc/init.d.. how many scripts have it and how many are really triggered? for instance I have nfs mounts and mountkernfs.sh is executed
<fabbione> pitti: so perhaps it's conditional
<pitti> fabbione: mountdevsubfs.sh and mountkernfs.sh
<fabbione> same here
<pitti> fabbione: 3 hits in devsub, and 5 in kernfs
<fabbione> yeps
<pitti> StevenK: gnome-build NEWed
<StevenK> pitti: Thanks!
<MacSlow> good morning funky bunch
<pitti> infinity: meh, the previous mbr package built fine in the DC, and I cannot reproduce the current test suite failure locally either; give-back didn't help, hmm
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<StevenK> pitti: anjuta uploaded - 3 libgdf packages should be ready to NBS out soonish
<pitti> StevenK: cool!
<pitti> StevenK: accepted
* pitti tries a test install with encrypted lvm by default; curious if that works :)
<pitti> aah, fresh Ubuntu lives
<Fujitsu> We have partman-crypto by default now?
* pitti calls for a testing sprint
<pitti> Fujitsu: in alternates
<Fujitsu> Yay!
* RAOF dances around the room, shouting Wooo!
<Fujitsu> Is Ubiquity getting LVM/crypto and the like in the next couple of releases?
<pitti> I hope so
<StevenK> pitti: Ah, thanks
<Fujitsu> Still, it'll be nice to not have to set it up manually, even if you do still have to use the alternate.
<StevenK> pitti: I'd forgotten the archive is in lockdown mode. :-)
* netjoined: irc.freenode.net -> kubrick.freenode.net
<pitti> Fujitsu: in expert mode this has worked for quite a while already
<RAOF> pitti: I'll be blowing away my laptop's install to set up LVM/crypto sometime soon, obviously.  Would you prefer testing asap, or with a beta disc? :)
<pitti> https://iso.qa.stgraber.org updated; go wild
<pitti> RAOF: testing ASAP is appreciated, if you can afford it
<Fujitsu> pitti: Wasn't it only promoted a few days ago?
* ..[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 | main frozen for Gutsy Beta release | Please test the Beta candidates at https://iso.qa.stgraber.org
<pitti> Fujitsu: yes
<pitti> Fujitsu: well, not promoted, but enabled in d-i
<RAOF> Hm.  I guess I can do that tomorrow sometime.
<maikmerten> (xiph.org news: Theora beta1 is out - and no, I don't expect that to go into 7.10 ;) )
<TheMuso> pitti, slangasek, I don't see anything on the schedule for Gutsy, so I am wondering if there will be a hard freeze for universe? If so, when might that be?
<pitti> hi maikmerten, thanks for the heads-up
<pitti> hello mvo
<Tonio_> pitti: I uploaded a new knetwork-manager yesterday including a fix for dbus connection
<pitti> mvo: can you start a new round of upgrade testing?
<maikmerten> pitti: you're welcome
<mvo> hello
<mvo> pitti: yes
<pitti> Tonio_: I saw, but it didn't have any bug # in the changelog, so I didn't accept it yet
<pitti> mvo: thank you
* mvo rsyncs images
<Tonio_> pitti: because there is no bug reported for this, and I decided to fix it before reporting and closing myself, lack of time, sorry for this....
<Tonio_> pitti: should I report the bug, then close it and reupload ?
<pitti> Tonio_: if you give me a rationale here, it's good enough for me
<Tonio_> pitti: okay, so the packaging was changed by riddell recently, and the dbus system.d configuration file misses in the package
<pitti> Tonio_: the changelog does not document the code removal in Makefile.in
<Tonio_> pitti: therefore the software is unable to  connect to dbus...
<pitti> Tonio_: agreed to the .install fix, that's fine
<Tonio_> pitti: I just rebuild the makefiles using buildprep, there is no specific change in the makefiles
<Tonio_> pitti: thanks
<pitti> Tonio_: hmkay; you tested this properly, I take it?
<Mirv> maikmerten: it'd be nice to have Theora's beta 1 in gutsy-backports, maybe even feisty-backports, though as soon as possible, even though gutsy main exception is probably not so probable :)
<maikmerten> oh, gutsy backports would certainly be nice
<pitti> and absolutely appropriate, too
* maikmerten is glad we preserved ABI compatability albeit like 50% of the code was rewritten
<cjwatson> pitti: did partman-auto-crypto work for you? pkern reported problems at boot
<pitti> maikmerten: that's indeed great; it's very helpful for distros (avoid rebuilding the dozens of reverse dependencies) and backportability, etc.
<pitti> cjwatson: it's still at the 'erasing data on partition' stage, that takes ages...
<pitti> ah, done now
<maikmerten> pitti: the original plan was to ship beta with a new API, but looking back at like 3 years of productive Theora use it seemed to be unappropriate to suddenly break everything
<Tonio_> pitti: yep I tested widelly on a daily-build install, and I can confirm knetworkmanager won't work at all without the fixing upload, then it works like a charm :)
<pitti> hi doko
<pitti> Tonio_: ok, sounds beta-worthy
<doko> good morning
<ion_> ing
<Tonio_> pitti: great, thanks :)
<MacSlow> mvo, I am strongly considering having "normal effects" and "extra effects" being a fixed set of pluings and only allow a custom list of effects... well on the "custom effects" setting (when ccsm is installed)
<MacSlow> mvo, I am surprised that this isn't in place already
<mvo> MacSlow: this is done with the patch I send you
<AnAnt> Hello, I have opened a couple of bugs on LP that got solved (or turned out not to be bugs), how do I get them closed ?
<seb128> AnAnt: change the status to invalid or fix released
<AnAnt> seb128: how ?
<seb128> AnAnt: click on the dropdown box and pick the option you want
<AnAnt> seb128: oh ok, thanks
<seb128> AnAnt: in the table at the top of the bug, you can click on the expander displayed to have the bug settings
<pitti> hm, when I unplug the power cable from my laptop, trackerd does *not* stop grinding
<pitti> I thought that was be fixed?
<seb128> pitti: to svn, no new version has been rolled since
<dholbach> calc: bug 135086?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<dholbach> Riddell: bug 136425?
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<dholbach> Riddell: also bug 121984
<ubotu> Launchpad bug 121984 in kdepim "kandy: no icon in kubuntu feisty's kde menu" [Wishlist,Confirmed]  https://launchpad.net/bugs/121984
<dholbach> doko: bug 103929?
<ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress]  https://launchpad.net/bugs/103929
<dholbach> Tonio_: do you think you can take a look at bug 73859?
<ubotu> Launchpad bug 73859 in kleansweep "Installation of Kleansweep on Ubuntu (Gnome) fails to install kdesu" [Undecided,Confirmed]  https://launchpad.net/bugs/73859
<doko> dholbach: for beta? maybe not
<dholbach> doko: I'll mark it as 'later' and unsubscribe ubuntu-main-sponsors
<Tonio_> dholbach: will look today, indeed
<Tonio_> dholbach: should use kdesudo btw
<dholbach> it'd be nice if you could all check out and http://daniel.holba.ch/sponsoring
<dholbach> Tonio_: best to mention that in the bug report
<dholbach> Tonio_: gracias :)
<asac> pitti: ola :) .... network-manager 0.6.5-0ubuntu14 waits
<dholbach> so does gnome-user-docs and ubuntu-dev-tools :)
* asac wonders if we will make the ubuntu100 during this release ;)
<pitti> asac: hey
<pitti> asac: how did the wpasupplicant testing go?
<asac> pitti: not as much replies as hoped for ... http://ubuntuforums.org/showthread.php?t=556488
<Tonio_> dholbach: will test \sh_away debdiff, should work
<asac> pitti: if you don't want this on beta cds i am fine ... we have to do it after beta then
<dholbach> Tonio_: rock on :)
<pitti> cjwatson: my lvm/crypto install finished, and indeed it's just stuck at boot; I'll reboot without usplash and quiet
<pitti> cjwatson: hm, that's inconclusive; kernel boots fine, but there's no userspace kicking in, it's just stuck
<cjwatson> pitti: ok, I'd be interested to know if it can be made to boot for beta
<pitti> cjwatson: http://people.ubuntu.com/~pitti/tmp/lvmcrypto.png FYI; no VTs yet, etc.
<pitti> ah, I finally get an initramfs shell
<pitti> cjwatson: /dev/mapper/ only has control, and 'lvm -> vgdisplay' says 'no VGs found'
<soren> pitti: It's LVM on top a crypted block device, right?
<pitti> soren: no, it shouldn't be; it should be an encrypted LV (root) and an unencrpyted LV (/boot) in a VG
<pitti> soren: and an encrypted swap, of course
<pitti> but the installer didn't show me the final partitioning, so I'll need a rescue CD, etc.
<soren> pitti: Oh, I see.
<sladen> pitti: /usr is on / ?
<pitti> sladen: I guess so
<pitti> the 'lvm' tool does not work at all, so I'm not sure
<pitti> vgscan/pvscan doesn't detect anything, etc.
<cjwatson> sladen: AFAIK partman-auto-crypto uses the atomic scheme by default, which doesn't have a separate /usr
<cjwatson> pitti: it does have a separate /boot, though, right?
<pitti> so, for some reason the lvm is not detected at boot
<pitti> cjwatson: it needs to, right
<cjwatson> I assume so otherwise you wouldn't have got that far :)
<pitti> cjwatson: I'm still poking in the initramfs shell, but it doesn't seem to get me very far
<pitti> cjwatson: classical /boot, swap, root-for-everything schema would make most sense
<cjwatson> indeed
<pitti> dm-crypt module wasn't loaded; that's a bug, but not the primary one
<dholbach> pitti: glom rebuild uploaded
<pitti> dholbach: *hug*
<pitti> soren, cjwatson: ah, got it: in this mode, /boot is not on the lvm itself, but a normal separate partition; and indeed my sda5 is a LVM on top of a luks device
<pitti> hm, ubiquity hangs at downloading langpacks, and 'skip' does not work
<soren> pitti: That makes sense.
<pitti> cjwatson: I created bug 144390 with the symptoms and what to do to make it boot
<ubotu> Launchpad bug 144390 in debian-installer "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,New]  https://launchpad.net/bugs/144390
<\sh> hmm...somehow I won't get my dual screen setup back to work...after last updates...:(
<tepsipakki> \sh: ati?
<\sh> neither mergedFB nor xinerama is working (ati radeon RV100)
<\sh> tepsipakki, yepp
<tepsipakki> they are obsoleted, use xrandr
<tepsipakki> it'll be mentioned on the release notes
<\sh> tepsipakki, but you don't mean that I have to setup tghis dual screen via this strange UI on gnome?
<tepsipakki> it should work OOTB for most
<MacSlow> http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-5.png but please comment on the ubuntu-devel ml
<\sh> tepsipakki, not for this machine...
<\sh> tepsipakki, it comes up with the failsafe 640x480 vesa mode :(
<tepsipakki> \sh: generate a new config
<\sh> tepsipakki, dpkg-reconfigure xserver-xorg?
<tepsipakki> right
<tepsipakki> make a backup first if you like
<tepsipakki> of the file..
<\sh> tepsipakki, oh I have a backup since dapper of my xorg.conf ,-)
<tepsipakki> you could also try without
<tepsipakki> and see what happens
<\sh> tepsipakki, doesn't work...I have two tfts one analog and one digital...
<\sh> tepsipakki, it comes up with the right solution but in twinview mode
<tepsipakki> cloned?
<\sh> so screen analog and screen digital are showing the same
<tepsipakki> right
<\sh> tepsipakki, and using the screen and graphics ui....he sees the screens and I set the screen digital to "left of bla" and then failsafe mode after restart ,)
<tepsipakki> \sh: maybe that should be made to work with ranrd-1.2...
<tepsipakki> \sh: anyway, check this out: http://www.intellinuxgraphics.org/dualhead.html
<pitti> siretart: you use crypted lvm, right? any idea about bug 144390? how does your initramfs behave?
<ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,New]  https://launchpad.net/bugs/144390
<tepsipakki> \sh: I haven't tried the randr-1.2 based multihead at all, but that doc should cover it, both static and dynamic
<pitti> cjwatson: on the bright side, hibernate and wakeup does work properly (except for manually calling cryptsetup again, of course)
<cjwatson> pitti: I'm not quite following the bug - what changes need to be made to debian-installer here?
<pitti> cjwatson: I moved it to cryptsetup; I guess something in its initramfs-tools scripts doesn't work (I did not yet debug it)
* pitti currently pokes the unionfs http oops in live, which causes the installer to hang (and any other program wanting to do http)
<cjwatson> pitti: what has HTTP got to do with any filesystem?
<cjwatson> mvo: sorry to preempt you with that apt bug, but I thought it was a good idea to get it fixed sooner rather than later at this point
<mvo> cjwatson: what apt bug is that?
<pitti> cjwatson: if I'd only knew that...
<pitti> cjwatson: I attached everything to bug 144395
<ubotu> Launchpad bug 144395 in linux-ubuntu-modules-2.6.22 "unionfs oopses for http processes" [Undecided,New]  https://launchpad.net/bugs/144395
<cjwatson> mvo: bug 144001
<ubotu> Launchpad bug 144001 in apt "crashes with SystemError: E:Unable to write mmap - msync" [Critical,Fix released]  https://launchpad.net/bugs/144001
<mvo> urgh
<pitti> cjwatson: thanks for fixing that (144001)
<cjwatson> pitti: so you mean apt's http method, at a guess
<mvo> cjwatson: thanks for fixing it!
<pitti> cjwatson: ah, right, that spawns a process with that name
<siretart> pitti: uuh, this looks bad. from the first look, it seems that the udev rules in the cryptsetup-udeb are broken
<pitti> siretart: why the udev?
<pitti> siretart: erm, udeb
<siretart> oh, I missed the part that installation went fine
<siretart> I have to admit that I never installed with crypted / - I need to test that
<stgraber> dholbach: Got my mail (ekiga) ?
<siretart> will do soonisch
<dholbach> stgraber: yes, I'll forward it to fernando though (he's working on the update to the new usptream version) (maybe also to seb128 to let him know about it)
<pitti> siretart: oh, I see; you just use encrypted /home and swap, or so?
<pitti> siretart: ok, nevermind; I just thought you would use that setup
<cjwatson> siretart: broken> how so?
<seb128> dholbach: Debian did update, maybe we can sync?
<siretart> cjwatson: I didn't read the bug carefully enough. the bug seems valid, I need to look more closely into it
<dholbach> seb128: great - I'll ask fernando to check it out (we have some changes in ekiga, for example different icons and LPI)
<dholbach> seb128: also I guess Debian has different compatibility symlinks
<siretart> let me install a current gutsy via pxe and let me try
<dholbach> seb128: maybe siti can help with that also
<pitti> Riddell: hm, did you self-accept your kdebase feisty-proposed upload, or is there a soyuz glitch?
<fabbione> pitti: according to mvo #127849 the verification has been already done about a month ago. we can move that to -updates
<pitti> fabbione: cool
<fabbione> pitti: #133822 feisty is ok. I am testing edgy and dapper now
<Riddell> pitti: I did, is that problematic?
<dholbach> stgraber: I forward it and CCed you in the mail
<pitti> Riddell: no, that's fine; I was just concerned that it wasn't held in unapproved for some reason
<pitti> Riddell: did you mangle the bug accordingly? (fixcommitted/verification-needed)
<pitti> fabbione: hm, over a month ago that bug/upload didn't even exist :)
<fabbione> pitti: the comment from mvo is from the 27th of Oct....
<fabbione> almost a month ago
<fabbione> :)
<fabbione> it's exactly a month old :
<fabbione> :P
<fabbione> (i am talking about 127849...)
<pitti> fabbione: (done)
<fabbione> pitti: thanks
<Riddell> pitti: I have now
<pitti> Riddell: thanks
<mvo> cjwatson: thanks for the patch for apt, I merged it back into the devel line too (so that debian gets it too)
<cjwatson> ok, cool
<fabbione> pitti: #133822 edgy is ok. missing only dapper
<asac> pitti: my final beta bugs are waiting in: network-manager 0.6.5-0ubuntu14, thunderbird 2.0.0.6-0ubuntu4, gnash 0.8.1-0ubuntu1
* pitti turns his attention back to the queue
<fabbione> pitti: #133822 is all good.. it can move to -updates
<pitti> fabbione: grazie; done
<fabbione> pitti: thanks a lot
<pitti> asac: cheers, all done
* asac hugs pitti
<siretart> cjwatson: the installer is taking ages to install on crypted LVM because of '/bin/blockdev-wipe'. Is there some easy way to circumwent that for testing purposes?
<siretart> I'm testing on a 120GB disk :/
<Fujitsu> siretart: VT switch and replace it with a shell script that does nothing?
<siretart> hm
<cjwatson> siretart: I don't know partman-crypto all that well I'm afraid
<pitti> siretart: here, too; I guess the reason is to fill it with random bits to make sure that you cannot reconstruct the previous contents
<siretart> pitti: yes, it makes perfectly sense to do that on a production system
<cjwatson> siretart: there's an "Erase data:" toggle in the manual partitioning UI
<cjwatson> siretart: so just go back to the manual UI from the confirmation screen and flip that
<pitti> siretart: thus it would not be required at all, but for people who care about data confidentiality it might be important
<siretart> pitti: for debugging purposes its just annoying
<pitti> siretart: ack
<siretart> cjwatson: aah, thanks. will do
<pitti> siretart: a 4 GB virtual disk does fine :)
<siretart> it seems that the automatic partitioner for crypto lvm doesn't setup any swap space
<siretart> this might or might not be intended
* ogra pokes bad update-inetd ... why the heck does that run through debconf :/
<cjwatson> apparently because it offers a UI for resolving conflicting service changes
<ogra> hrm
<ogra> it breaks my ltsp-update-image it seems
<ivoks> cjwatson: i've discovered root of the bug 93077, and patch for xkeyboard-config is provided, tested it and it works fine
<ubotu> Launchpad bug 93077 in xkeyboard-config "Non-exsisting layouts" [High,Confirmed]  https://launchpad.net/bugs/93077
<ogra> if i force noninteractive from ltsp-update-image likelyness that the udeb breaks again is big :/
<cjwatson> ivoks: do you know what the "any" symbols were originally supposed to do?
<ivoks> cjwatson: if layout included some other layout (latin(level3)), then, if there's 'any', that key should be taken from latin
<ivoks> cjwatson: that works in X
<ivoks> but, since nobody uses 'any' these days, i figured out that it is obsolete or a bad thing to do
<ivoks> and in ckbcomp, any is replaced with VoidSymbol
<cjwatson> ivoks: OK - it's not easy to see from the patch but I take it that changing "any" to the corresponding real symbols is the only change?
<ivoks> right
<ivoks> cjwatson: i'll send a patch to upstream also, so, hopefully, this is one-time fix
<cjwatson> ivoks: OK, applying now
<cjwatson> thanks
<ivoks> thank you
<pitti> siretart: it did for me
<pitti> siretart: I even tried suspend to disk, and that worked fine (modulo that initramfs bug, of course)
<pitti> siretart: the lvm contains ubuntu-{root,swap_1}
<siretart> pitti: I found out why the cryptroot hook is broken
<siretart> pitti: its the UUID mangling in /etc/fstab
<pitti> siretart: ooh, crypted partitions don't have that, I take it
<siretart> pitti: the cryptsetup initramfs hook is comparing /etc/cryptab and /etc/fstab entries. with the UUID mangling, it fails to detect the root device. that's why it doesn't mount root by default
<pitti> siretart: darn, I don't have that installed system any more; how does fstab look like?
<siretart> sorry?
<pitti> siretart: I wonder how the uuid writing code can do that in the first place, since the encrypted partition should not have any uuid...
<siretart> pitti: both the ext2 filesystem in the crypted container and the container itself have a UUID
<siretart> that's the point of LUKS
<siretart> the question is how to proceed from here
<pitti> ah, right
<pitti> siretart: I mixed that up with the pure dm-crypt install I did a while ago (no luks)
<siretart> since we need to redesign/rewrite the whole cryptsetup/udev integration, I think it might not be that unreasonable to just disable the UUID mangling for cryptoroot installations
<pitti> siretart: so which UUIDs are in crypttab and which are in fstab?
<siretart> pitti: of the inner ext3 fs.
<siretart> pitti: the crypttab file (which we want to get rid of) doesn't know about UUIDs
<pitti> siretart: hm; well, the inner ext3 one does make sense for fstab...
<pitti> siretart: however, would disabling help at all? it seems to me that fstab is the wrong place to denote the 'outer' device (with either /dev/ or UUID)
<pitti> siretart: after all, if UUID were replaced by /dev/mapper/ubuntu-root, the initramfs still cannot find that without actually unlocking the encrypted device
<siretart> pitti: well, that's the way the debian crypt-root hook works
<siretart> it does special magic in the initramfs to detect and open the root volume
<siretart> hmm. I think we'd need to fix the add_device() function in cryptroot-hook
<siretart> pitti: http://paste.debian.net/37868
<siretart> that part horribly breaks with UUID
<pitti> siretart: back in five minutes (need to do some queue review)
<siretart> it is given the first entry of /etc/fstab
<cjwatson> I'm surprised we use UUIDs for crypted devices
<siretart> cjwatson: why?
<cjwatson> hmm, I forgot that udev had been changed to use UUIDs for LVM devices
<cjwatson> ok, in that case I would be inclined to say that it would be easiest to fix cryptsetup to handle UUIDs
<cjwatson> (I was going to say that we could turn them off in the installer, but we'd have to change the volumeid postinst too and it would be fiddly to distinguish them from LVM LVs)
<siretart> needless to say that on my laptop, I don't use UUIDs for my crypted volumes either
<siretart> cjwatson: if we do that, we'd need to change cryptsetup-udeb to create UUIDs in /etc/crypttab as well, I think
<siretart> otherwise things become terrilbly hackish :/
<ogra> ogra@laptop:~$ LANG=C sudo adduser testuser
<ogra> adduser: The group `testuser' already exists.
<ogra> ....
<ogra> seems users-admin doesnt like that case
<ogra> seb128, ^^^ it shows the user being crteated in the gui .... but its not being created
<ogra> no error message or something
<seb128> ogra: known already
<ogra> ah, k
<seb128> ogra: bug #99276
<ubotu> Launchpad bug 99276 in gnome-system-tools ""User and Groups" does not inform user that manual UID already exists and create user groups." [Medium,New]  https://launchpad.net/bugs/99276
<ogra> right, thanks :)
<cjwatson> siretart: makes sense. fortunately it would be only one upload to do both
<pitti> siretart: back, reading scrollback
<pitti> siretart: add_device()> right, I see the problem
<ogra> hrm, compiz stopped working in ltsp :/
<ogra> sad
<pitti> cjwatson: I don't think that we can fix this sensibly for beta; how easy is it to hide that option in d-i? (if it takes too long, we can release-note it, but it'll certainly generate some attraction and complaining)
<siretart> Honestly, I think we should disable cryptsetup-udeb for beta, but enable it again shortly after that again.
<pitti> siretart: I'd only enable it again when this is fixed
<pitti> siretart: it was a feature we hoped to sneak into the beta because it seemed cheap to get, but apparently it isn't :/
<siretart> pitti: good option, however since I don't know (yet) how to build d-i, this would be unconvenient for me ;)
<siretart> well, debian doesn't seem to believe in UUIDs
<pitti> siretart: well, there's still plain dm-crypt in the expert mode
<siretart> something that should change
<siretart> pitti: no, if we disable cryptsetup-udeb. not even that is available
<siretart> pitti: so perhaps we can just disable cryptoroot for now?
<pitti> siretart: hm, and just fixing add_device to check /dev/disk/by-uuid/ wouldn't work?
<siretart> pitti: I'd expect it to work, if you can fix the node_is_in_crypttab() function as well
<ogra> mjg59, is there any way to get working panning on a virtual desktop with the intek driver ? seems i can only get that working with i810 and 915resolution
<ogra> *intel
<cjwatson> pitti: shove partman-auto-crypto to universe and the automatic option will disappear
<cjwatson> pitti: the manual option is partman-crypto
<pitti> cjwatson: ah, great; d-i is about to be rebuilt anyway, that should pick it up, right?
<cjwatson> it's outside the initrd, doesn't need a d-i rebuild
<pitti> cjwatson: I think disabling it for now is the way to go, WDYT?
<pitti> ah
<cjwatson> your call, I'm not clear enough on the difficulty of fixing cryptsetup
<mjg59> ogra: I believe so, but I've never tried
<ogra> well, it ignores the "Virtual" stanza on the classmate with the intel driver
<pitti> cjwatson: I don't think it's too hard to fix the initramfs script, but I don't have time for it right now, and time is getting tight
<ogra> i810 works fine but needs 915resolution (i'm on the classmate atm)
<ccm> hi there, what is the best way to track "could enable desktop effects" issues. I cannot find any log files or verbose output
<StevenK> Poor amd64
<Fujitsu> StevenK: What's wrong with it now?
<StevenK> Fujitsu: One of the buildds is down
<Fujitsu> Ah, as usual.
<StevenK> Fujitsu: Hrm? I haven't noticed that amd64 lost any buildds
<StevenK> Previously, I mean
<Fujitsu> StevenK: I'm sure I saw one down for more than a day a few days back, but it might just have been sparc.
<StevenK> Ah, now sparc on the other hand. :-)
<pitti> StevenK: FYI, it's currently being discussed
<StevenK> pitti: Ah ha
<StevenK> pitti: libgbf NBS'ing is waiting on the amd64 build.
<StevenK> pitti: Increase the priority of the anjuta amd64 build, but I don't mind either way.
* ogra grumbles about diverged seeds 
<StevenK> Whoa. You're not done yet!
<pitti> ogra: hm? I merged them on Friday or so; can't be that bad?
<ogra> well, i forgot to pulll before making my changes
* ogra slaps self
<pitti> ogra: oh; you should maybe consider using a checkout (bzr bind), so that commit will warn you
<gutsy> Hi, do you know which package provides GL/glxint.h
<pitti> ogra: uncommit FTW :)
<StevenK> gutsy: #ubuntu in future, but the package is x11proto-gl-dev
<gutsy> thanks
<ogra> pitti, hmm, noice, i didnt need to uncommit, it moaned my change but accepted the commit
<ogra> *moaned about
<cjwatson> ogra: you'll need to uncommit in order to pull the master seeds though
<cjwatson> you should never merge *from* the master seeds and then push
<ogra> hmm
<cjwatson> (because that will make revision numbers go backward and generally be confusing)
<cjwatson> I second pitti's recommendation to use 'bzr bind'
<ogra> to late now
<ogra> but https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.gutsy seems to be happy
<cjwatson> please set up a checkout now rather than later so that that doesn't happen again
<pitti> yeah, and 'bzr log' will be strange
<ogra> will do
<cjwatson> ogra: it *works*, it's just horribly confusing
<ogra> yeah
<ogra> understood
<StevenK> pitti: In a fun twist of fate, -11 and -12 kernel stuff has landed in NBS
<cjwatson> StevenK: -11 should go away for beta, leave -12 alone since it's probably just unseeded stuff
<cjwatson> I don't see any -12 stuff in /~ubuntu-archive/NBS/
<pitti> StevenK: probably it's just NEEDSBUILD
<cjwatson> I've seeded the *-cell-di udebs
<pitti> StevenK: and I cleaned up all -11 yesterday AFAIK
<cjwatson> pitti: there's linux-ubuntu-modules -11 stuff
<pitti> ah
<pitti> I'll clean up later
<StevenK> pitti: It seems you missed updates-modules-2.6.22-11-*-di
<cjwatson> StevenK: it's from a different source
<StevenK> cjwatson: Yeah, I should learn to hit refresh before poking people about NBS, just in case
<cjwatson> pitti: BTW (just in case) could you please leave palo-installer and partman-palo in main? hppa should be back in shape soon so we can turn it back on properly in anastacia
<ogra> W: http://archive.ubuntu.com/ubuntu/dists/gutsy/main/binary-amd64/Packages.bz2 was corrupt
<ogra> hrm, whats that ?
<cjwatson> usually transient, wait 'til next push
<pitti> cjwatson: right, I was ignoring it anyway for the moment
<ogra> well, does ./update retry in the background ? seems its going on fine
<cjwatson> ogra: no, it ignores the errors and trundles on regardless
<ogra> ah, k
<cjwatson> ogra: you should nuke your tree, re-unpack, and try again later
* ogra stops it then
<ogra> yes, thats what i usually do anyway with wsuch warnings
<cjwatson> it's a germinate bug mind you, it should stop on that sort of thing
<cjwatson> and not bugger up the tree
<ogra> yup
<siretart> asac: heh, you're foisting me the wpasupplicant downgrade?
<siretart> (the changes-file says Changed-By: siretart, but I didn't sign that upload)
<asac> siretart: no ... not that i know of
<pitti> siretart: no, we just asked for your opinion
<pitti> siretart: erm, what??
<asac> siretart: oh ... sorry if that wasn't the idea ... i took your package
<asac> siretart: and didn't change a thing except the version
<siretart> right
<asac> or did i?
<siretart> but this way it looks like a sponsored upload
<cjwatson> Changed-By is taken from the top of debian/changelog, not the signer
<pitti> StevenK: NBS cleaned (kernel -11 stuff, libwine, and libgbf-1-0-dbg)
<siretart> there isn't a problem here, it just looks strange
<asac> siretart: in the end the uploader is responsible i guess ... not the changelog owner (imo)
<StevenK> pitti: Yay, thanks.
<siretart> asac: well, in this particular case, we are both respsonsible anyways. it just looks funny ;)
<cjwatson> could somebody fix the usplash-theme-ubuntu misalignment for beta?
<StevenK> pitti: libgbf-1-0 can go whenever the amd64 build of anjuta sorts itself out
<cjwatson> I think it only affects one of the (widescreen, non-widescreen) versions
<asac> siretart: yeah sorry for the confusion ;)
* sladen goes to look at usplash-theme-ubuntu
* sladen smacks head.  WHY is this stuff hard-coded and not calculated
<pitti> sladen: computers are so bad at maths...
<sladen> pitti: yeah, much worse than the programmers that think 352+380+352=1024
<cjwatson> heh
<pitti> for a very small value of '380' :)
<Hobbsee> sladen: they've redefined the maths system since you went to school.  didnt you get the memo?
<lamont> mvo: you around?
<lamont> mount (current gutsy) Breaks: nfs-common (<<1:1.1.0-7).
<lamont> does that mean that apt will just do the right thing?
<lamont> (and we can therefore close the update-manager bug and not bother with the releasenotes entry?)
* lamont adds a comment to the bug
<Amaranth> lamont: apt will refuse to install the new mount
<lamont> dist-upgrade should cause it to upgrade nfs-mount if present though, yes?
<Amaranth> not sure
<geser> doesn't breaks mean than nfs-common gets unconfigured?
<pitti> but if a higher version is available, apt should certainly prefer that?
<sladen> cjwatson: who's got an affected laptop?
<pitti> sladen: I notice the wrong progress bar on the live CD, but in installed system it is ok
<sladen> pitti: oh, joy.
<StevenK> pitti: lmms hasn't been fixed for s/libwine-dev/wine-dev/, I'm doing so now.
<pitti> StevenK: right, but I'm not worried killing build-dependencies, since on next upload people notice anyway and it doesn't break installability
<ogra> pitti, if e-meta shows up in the queue, please approve ...
* ogra goes for a break now
<pitti> ogra: noted
<StevenK> pitti: Shrug, it gives me something to do. :-)
<pitti> ogra: s/if/when/, I take it? :)
<cjwatson> sladen: any vmware installation shows it when booting the live CD
<pitti> sladen: ^ confirmed
<cjwatson> well, I say any, at least mine does
<ogra> pitti, actually it should be there already :) ....
<ogra> anyway, coffeebreak :)
* lamont updates the bug with a "if I'm right, close the bug.  if I'm wrong, remind me to fix ReleaseNotes" closing.
<lamont> bug #141559
<ubotu> Launchpad bug 141559 in update-manager "update-manager needs to handle mount/nfs-common transition for gutsy" [High,Confirmed]  https://launchpad.net/bugs/141559
<cjwatson> sladen: hence my widescreen vs. non-widescreen thought
<sladen> cjwatson: the (2*a + b != c) was only off for the widescreen. 0.16 uploaded, one line change only on the widescreen theme, shouldn't make the situation any worse
<cjwatson> cool, thanks
<sladen> cjwatson: re: vmware;  640x400 could be selected as "widescreen"
<mjg59> The livecd will never use the widescreen themes
<mjg59> usplash doesn't do its own resolution probing, and nothing has given it a widescreen resolution at that point
<sladen> arse
<mjg59> Also, we don't have a 640x400
<sladen> pitti: you said the error was /only/ on the livecd and not on normal boot?
<mjg59> (Or do we? If we do, it should be shot)
<cjwatson> sladen: that's what I'm seeing, which suggests it's on 640x480 not 1024x768
<cjwatson> (the resolutions in my case)
<Riddell> sladen: when editing usplash themes please mind and tell me and ogra and whoever does xubuntu to sync up
<bddebian> Heya
<Riddell> or for extra points fix it somehow so the code isn't duplicated
<sladen> Riddell: does this progress bar misalignment show up on kubuntu aswell?
<Riddell> sladen: yes
<Riddell> which isn't surprising since its the same code
<StevenK> pitti: lmms builds, would you prefer I left it until after beta?
<sladen> Riddell: nod, I'll do it once somebody confirms whether it's a fix or not
<Riddell> sladen: you uploaded without knowing if it fixes or not?
<pitti> StevenK: no, I'm fine; it's universe
<MacSlow> seb128, .svg don't need to be uuencoded in order to be put in the debian-directory, right?
<StevenK> pitti: Aye, uploading now
<seb128> MacSlow: no they don't
<sladen> Riddell: yes, see note above.
<StevenK> pitti: lmms uploaded, accept at your leisure.
<sladen> Seveas: did you, or mjg59 originally write this usplash theme?
* pitti wonders why apport does not catch ubiquity crashes any more
<seb128> pitti: I'm sometimes wondering if apport works correctly nowadays, we don't get lot of crash bugs
<pitti> seb128: the crash was caught, but update-notifier didn't report it on the live CD
<seb128> right
<seb128> my gutsy does the same
<seb128> it collects crashes but that's about it
<seb128> I'm not sure if I changed the config at some points so I didn't bother
<seb128> but that's weird
<pitti> hm, bash -c 'kill -SEGV $$' still works
<seb128> well it collects crashes as written
<seb128> it just doesn't add an icon in the notification area nor run
<pitti> seb128: hm, it does for me
<seb128> k, so I probably changed something
<pitti> seb128: if you do above bash command, what happens?
<seb128> I just dunno where
<seb128> it adds a crash to /var/crash
<seb128> and that's all
<pitti> python crashes are reported here, too
<pitti> seb128: gconftool -g /apps/update-notifier/show_apport_crashes
<seb128> No value set for `/apps/update-notifier/show_apport_crashes'
<pochu> It doesn't notify here, and I don't think I changed the config...
<pitti> seb128: a-haa
<pochu> same here, btw ^ :)
<pitti> do you have /usr/share/gconf/schemas/update-notifier.schemas ?
<seb128> yes
<seb128> pitti: /var/lib/dpkg/info/update-notifier.postinst doesn't register it though
<pitti> seb128: hm, shouldn't gconf use the default from there?
<seb128> so it's not used
<pitti> hehe
<seb128> pitti: no, the package has to use dh_gconf
<pitti> mvo: you broke my shiny update-notifier gconf key :/
<seb128> pitti: schemas are templates used to file the gconf database at installation time
<pitti> mvo: want me to fix it again?
<pitti> seb128: right, and I'm fairly sure I added dh_gconf back then
<seb128> pitti: anyway that would explain why we don't get lot of crash bugs for some time
<pitti> and also why they are not reported on the live CD
<pitti> apt-get source update-notifier doesn't warn me about bzr either
<pitti> seb128: I'll take a look; we should definitively have this for beta
<seb128> pitti: weird, it has a dh_gconf
<pitti> evand: bug 144460 should be a straightforward fix; I'm not sure how exotic the crash is, though
<pitti> evand: (or, rather, the circumstances when it happens)
<ubotu> Launchpad bug 144460 in ubiquity "ubiquity crashed with NameError in _realpath_root_recurse()" [Undecided,New]  https://launchpad.net/bugs/144460
<seb128> pitti: ah, you added the dh_gconf before dh_install which doesn't work since the schemas is not installed yet
<iwj> kylem: You don't fancy looking into the sl-modem-daemon regression, do you ?  (bug 144468)
<ubotu> Launchpad bug 144468 in linux-source-2.6.22 "sl-modem-daemon does not work on some hardware" [Undecided,New]  https://launchpad.net/bugs/144468
<evand> pitti: thanks, I'll take a look
<seb128> pitti: do you want me to upload a fixed update-notifier?
<evand> ugh, why can't firefox handle gzip like less.  I shouldn't have to open a single compressed file in file-roller.
<pitti> seb128: ah, that was due to Riddell's recent changes for the package split
* pitti pats bzr blame :)
<pitti> seb128: sure, if you have some minutes to actually test it, that'd be appreciated
<cjwatson> evand: looks like I got the mutual recursion syntax wrong
<seb128> pitti: ok, looking at that
* pitti hugs seb128
* seb128 hugs pitti back
<cjwatson> I'm not actually sure how to fix that, so good luck :)
<evand> haha, oh thanks!
<pitti> oh, hmm, just looked like a wrong name
<cjwatson> oh
<cjwatson> yes, you're right
<pitti> evand: it actually installs fine, so the only things that are wrong are the missing 'reboot now' message, and the apport crash report
<kylem> iwj, there's no change that would effect that.
<cjwatson> evand: ignoring my misunderstanding, can you go ahead and commit the obvious fix?
<iwj> kylem: Not even the reversion of snd-intel-hda ?
<iwj> kylem: If you think it's probably not a kernel bug I can try to do binary chop on upgrades.
<evand> cjwatson: will do
<pitti> iwj, kylem: just chiming in, bigjools was complaining about his intel sound card not working any more in gutsy; might that be related?
<evand> pitti: missing reboot now message?  That's been coming up fine for me.  Is there a specific test case for this?
<cjwatson> reboot> ditto
<pitti> evand: well, ubiquity crashed, so it could not display it any more
<pitti> evand: that was just the reasoning for not making it a blocker for beta
<kylem> hmm.
<pitti> installation works by and large, but with a few glitches
<kylem> try reverting the kernel to -11 and seeing if it fixes things.
<evand> pitti: I'm sorry, I don't follow.  How would ubiquity crashing make the 'would you like to reboot now?' message disappear, unless you're saying that such a message should appear despite the install failing?
<cjwatson> pitti: I think we should disable tracker in the live session to save memory. Does that make sense to you?
<pitti> cjwatson: ooh, please
<cjwatson> I'll just check that the world doesn't break if I do that
<pitti> evand: well, because ubiquity crashed before it came to the point when it considered the installation fully finished and thus would display the 'installation done. reboot/continue' dialog
<pitti> cjwatson: that would be a casper change?
<cjwatson> yes
<highvoltage> 5C
<pitti> hi mdz
<cjwatson> pitti: I think the installation not completing is a blocker for beta; there are important things done after the crash you describe beyond just displaying the reboot dialog
<cjwatson> pitti: for example, a system that crashes at that point will still have ubiquity installed in the target, and won't have the installation logs copied to it
<mdz> pitti: hello
<pitti> cjwatson: if we get a fix soon, I'm all for it; right now I'm not sure how corner-case this crash is
<cjwatson> pitti: evand's committed it, and there's something else in bzr that needs an upload anyway
<pitti> ah, great
<cjwatson> but I was waiting for a translation update from Launchpad before uploading, ideally
<wasabi> So... when my kernel dies... the keyboard's caps lock and scroll lock keys blink... and X remains unmoving.
<pitti> cjwatson: heh, I'm waiting for a new gutsy tarball since Saturday :)
<wasabi> Is there an appropiate way to get something useful for submitting in a bug report?
<pitti> cjwatson: we'll still need a new wpasupplicant (most probably), so I think we won't get new images until tomorrow morning
<pitti> wb seb128
<pitti> seb128: btw, I think you didn't commit the update-notifier fix to bzr
<seb128> pitti: re, update-notifier fix confirmed and uploaded
<seb128> where is the bzr?
<pitti> seb128: thanks
<pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/
<seb128> I tried http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu
<pitti> seb128: apt-get source didn't warn me either, but debian/control has it
<seb128> but this one doesn't have the current version
<pitti> hmm
<seb128> it's outdated
<seb128> and mvo didn't reply to my query
<seb128> so I just uploaded for now
<pitti> seb128: ok, *shrug*, something to be cleaned up later
<seb128> right
<cjwatson> seb128: 16:24 <cjwatson> pitti: I think we should disable tracker in the live session to save memory. Does that make sense to you?
<cjwatson> seb128: sound reasonable? it's not like it will be indexing much interesting
<jdong> I think we should disable tracker to not break my hard drive :)
* jdong ducks
<pitti> ah, that might also explain why it is to painfully slow
<mjg59> That makes sense
<jamiemcc> yeah - cant see the point on a live cd
<pitti> hi jamiemcc
<jamiemcc> hi pitti
<pitti> jamiemcc: just noticed that trackerd doesn't stop when pulling out AC, but seb said you already fixed it in svn?
<pitti> jamiemcc: does this happen to be a relatively small patch which we could apply easily?
<jamiemcc> yes we hope to have a release later tonight or tomorrow at latest
<jamiemcc> the patch would be difficult to isolate from release
<pitti> jamiemcc: for the beta I'd prefer a single patch if it is reasonably consistent, and new upstream microrelease later
<pitti> jamiemcc: oh, I see
<pitti> jamiemcc: well, it was worth a try :)
<jamiemcc> pitti: I can do ti for you if you like if its not possible to put a new version in time for beta
<pitti> jamiemcc: well, it's not a beta blocker IMHO; but I consider it very important to fix immediately after that
<pitti> jamiemcc: does your new release tonight have any new features, or is it just bug fixes?
<jamiemcc> bug fixes on the whole - new features like experimental thunderbird extension are configure disable
<pitti> (am I the only one who envisions a sleep medicine when saying "beta blocker"?)
<jamiemcc> the new index merging improves disk io and index speed considerably
<jamiemcc> so would be nice to get it into gutsy asap
<pitti> jamiemcc: hm, sounds like we want that, too, if it has been tested properly?
<jamiemcc> its been tested over the weekend on the tracker ML
<jamiemcc> only major issue is memory leaks atm
<seb128> cjwatson: makes sense
<pitti> with the new indexing or the current one?
<jamiemcc> the new indexing merging
<pitti> jamiemcc: do you have a websvn where I could see the commit to fix 'stop on battery'? (just to have a fallback)
<jamiemcc> http://svn.gnome.org/viewcvs/tracker/trunk/src/trackerd/
<jamiemcc> changes to trackerd.c and tracker-utils.c and tracker-utils.h
<pitti> jamiemcc: ah, revs 846 and 861?
<jamiemcc> yes sounds right
<jamiemcc> would have to fish them out amongst the other changes though
<pitti> hm, those commits seem to amalgate several unrelated changes
<pitti> ah, right
<pitti> Keybuk: now that unionfs works again, by and large, would it make sense to do that mystical ReadaheadListUpdate?
<pitti> doko: expat NEWed, FYI (64 bit libs)
<pitti> bryce: radeonhd binary-NEWed, FYI
<Keybuk> pitti: yeah
<TomaszD> hello, quick question, is the bluez-gnome package installed by default regardless of bluetooth hardware presence?
<TomaszD> I need this for an Ubuntu article, for a real... paper newspaper.
<cjwatson> TomaszD: generally we try not to install packages on a hardware-specific basis, because it makes it less convenient to switch hardware around
<cjwatson> sort of the opposite of Windows activation :-)
<TomaszD> hah, good thinking
<mvo> seb128: let me check it
<TomaszD> so I take it as a yes, it's installed regardless
<cjwatson> TomaszD: yes, in the forthcoming Ubuntu 7.10 (but not in 7.04), bluez-gnome is installed by default across the board. It's only a Recommends of ubuntu-desktop, though, so you can remove it again without problems
<TomaszD> cjwatson, thank you!
<TomaszD> I want to be as accurate as possible
<mjg59> TomaszD: In the absence of bluetooth hardware, it should just sit there and do nothing until a bluetooth device is plugged in
<mjg59> We install it by default because there's no way of knowing whether the user has a bluetooth dongle that isn't connected at install time
<TomaszD> that's my fifth and last article for a special Ubuntu edition of a certain Linux magazine, I'm dead tired and I don't want to make a mistake
<doko> pitti: thanks
<sladen> TomaszD: imagine if you had a bluetooth USB dongle;  wandered up to a machine and plugged it in;  it should "just work".
<TomaszD> indeed, this is a real advantage over the earlier ubuntu editions
<TomaszD> but to be fair, XP SP2 also handles this well
<TomaszD> alright, thanks guys, back to writing
<mjg59> No problem
<pitti> TomaszD: yeah, the BT applet activates itself when I plug in my bluetooth dongle
<sladen> TomaszD: (nb, the the plugging in bit is actually what "happens" with Fn-F5 style toggling of bluetooth radios on laptops)
<mathiaz> keescook: I've pushed a new version of apparmor in my bzr branch.
<keescook> mathiaz: okay, do we have a freeze exception for it?  (i.e. should I merge and publish?)
<mathiaz> keescook: it should fix the audit messages in syslog not being parsed correctly.
<mathiaz> keescook: I don't think we need an UVFe as it's 0ubuntu2.
<mathiaz> keescook: but I think we need to ask pitti about it.
<keescook> mathiaz: beta freeze means no uploads to main (of any kind) unless we get approval.
<keescook> (i.e. not a UVFe, a BFe)
<mathiaz> keescook: ok. So no, I don't have freeze exception.
<keescook> mathiaz: okay, I'll merge and ask
<TomaszD> one more question guys, since the installation of language packs during system installation is broken atm (known and reported bug, don't know about current status), the xdg-user-dirs are now in English in my Polish session (after installing language packs after system installation). I was informed that the folders are created upon user account creation and there is no way to change their names to my locale automatically, because they're created
<TomaszD> just once, is there a workaround for this? Can I now change the names manually without breaking anything?
<evand> TomaszD: lang packs should be installed in the latest daily live CDs
<pitti> evand: thanks for fixing this; it worked in today's test install of mien
<pitti> s/mien/mine/
<TomaszD> evand, I'm subscribed to a bug about this and I haven't received anything about this, but nevermind. What about a scenario in which the network connection cannot be estabilished during installation (problematic drivers, etc), is there a workaround, I mean when I change default locale to Polish afterwards and download all the language packs, is there any way to handle locale changes with xdg-user-dirs?
<TomaszD> I think there isn't anything I can do besides creating another user account :]  but if the langpacks are installed during installation then the problem is more or less covered
<evand> TomaszD: I'm not sure, tbh I'm not as up on i18n as I should be.
<evand> pitti: glad to hear it!
<TomaszD> alright, np
<iwj> ogra: What's the problem with autopkgtest and ltsp-client ?
<MacSlow> although I replace the four icons with lapo's I still see kwwii
<MacSlow>  's icons
<MacSlow> I even did a restart
<MacSlow> also wiping ~/.thumbnails didn't help
<MacSlow> where else does gnome store icons?
<pitti> MacSlow: try gtk-update-icon-cache?
<cjwatson> iwj: re bug 144497, console-setup was deliberately uploaded before xkb-data binaries were ready (in the knowledge that the buildds would wait until that happened) in order to speed up the publication process
<ubotu> Launchpad bug 144497 in console-setup "autopkgtest gutsy console-setup: erroneous package!" [High,New]  https://launchpad.net/bugs/144497
<cjwatson> iwj: perhaps you should have your test harness wait a bit before filing build-depends bugs?
<MacSlow> pitti, yep
<MacSlow> pitti, no change
<iwj> cjwatson: Err, it's difficult to know what "wait a bit" would mean.  That's not really how it works - it picks a package to test and then files a bug if it failed.
<iwj> cjwatson: I could have it put the package to one side with a note to retest soon and file a bug if still broken I suppose.
<iwj> cjwatson: But really the rate of these failures is quite low.  You only get a bug like this if autopkgtest happens to pick your package at a time when it's broken.
<cjwatson> I don't know exactly how it would be implemented
<cjwatson> fair enough
<cjwatson> I've just closed it now
<ogra> [   ]  gutsy-server-i386.OVERSIZED         24-Sep-2007 18:05    0
<ogra> [   ]  gutsy-server-i386.iso               24-Sep-2007 18:02  700M
* ogra laughs
<IntuitiveNipple> Is alternate CD x86 i386 install supposed to be offering x86_64 kernel image updates when Update Manager first runs after booting the installed system?
<pitti> ogra: ugh
<pitti> IntuitiveNipple: erm, no
<jdong> is that even possible?
<IntuitiveNipple> pitti: hmmm!
<ogra> pitti, well, a pngcrush on the new wallpaper and it should be fine i guess
<IntuitiveNipple> I can give you a screenshot if you like lol
<ogra> cant be mush thats over now
<ogra> *much
<ogra> oh, wait, ubuntu is still 4M over i should inherit something of that :)
<ogra> iwj, do you have a blacklist for packages in autopkgtest ? ltsp-client/-core should be excluded
<iwj> ogra: Sorry, I'm afraid my bot has filed another dupe of that bug.
<ogra> ah, thats fine, i can ignore that
<iwj> I was using ltsp-client as a test case and the dupe suppression arrangements didn't work properly.
<iwj> With luck you won't get another dupe.
<ogra> ah, k
<iwj> I don't have a blacklist in the sense that there's a manual blacklist.  But it's supposed to ignore source packages which have open autopkgtest bugs.
<ogra> as i said, i can ignore that, just be aware that its supposed to fail in non ltsp chroots :)
<iwj> I'm afraid I don't have time right now to discuss it in detail.
<iwj> How about we chat tomorrow some time ?
<ogra> sure
<iwj> Thanks.
<iwj> And sorry for the noise.
<ogra> np
<sladen> mjg59: something weird, fan started spinning fast, 20 wake-ups per seconds (libata and firefox), 65% in C0, nothing in top, turned the wireless/BT off and it's still the same.
<sladen> mjg59: oh wait, no:  Wakeups-from-idle per second : 33200.1    and yet the top two items in powertop show only 10 each
<LongPointyStick> evand: ping?
<evand> LongPointyStick: pong
<mvo> lamont: re #141559: having the breaks is good, but it seems like it is not sufficient as it seems to be possible to mount nfs in feisty without nfs-common so a transtion that checks for nfs mounts and adds nfs-common is required
<lamont> ok
<mvo> lamont: I should have the required code in update-manager now, I do a test and then commit
<lamont> mvo: fwiw, I think we waved our hands and said that if you didn't care about locking, then it was OK that you couldn't mount your nfs partitions. :-)  So yeah, forcing the install on nfs-mount-existance is a good thing
<mvo> lamont: haha, ok :) for debian  a debconf note might be appropriate if no nfs-common is installed and nfs-mounts are in used
<sladen> mjg59: puzzling, nothing in /proc/interrupts is catching those 32k interupts, so timers I guess.  utterly puzzled
<lamont> probably
<lamont> then again, I have until lenny freezy to worry about that... :)
<psusi> how should I go about getting corrections made to https://help.ubuntu.com/7.04/installation-guide/i386/apcs03.html ?
<cjwatson> psusi: file a bug on installation-guide
<cjwatson> (it can then be corrected for 7.10, probably not for 7.04)
<psusi> that's a package name?  installation-guide?
<psusi> ok.... it suggests making separate /usr, /var, and /tmp partitions for multi user systems... /tmp definately should not have its own partition since it is mounted as a tmpfs
<cjwatson> psusi: yes, it is a package name
<psusi> k
<cjwatson> and I didn't say to make your bug report here :)
<KaiL> just saw, that gutsy still has fglrx 8.37.6, any plans to add 8.41.7, which supports Radeon HD 2xxx?
<Kopfgeldjaeger> how can i replace one 2 newlines (if they are "together") in a text file? \n\n\n should become \n, and \n\n should become \n
<psusi> what's the difference between confirmed and triaged again?
<psusi> I still don't quite have the hang of the new system
<Kmos> psusi: https://wiki.ubuntu.com/Bugs/Status
<cjwatson> I don't find the distinction particularly valuable, but perhaps others do
<pitti> psusi: confirmed> another user besides the reporter also gets this bug; triaged> a developer looked at it and thinks that the bug has enough information to start working on a fix
<psusi> they both mention having enough information to start working on a fix
<pitti> psusi: that's why only ubuntu-qa people can use 'triaged'
<psusi> hrm... I set this bug to triaged because I confirmed someone else's diagnosis of the problem as being that the documentation just needs updated, is that wrong?
<pitti> psusi: sounds good to me, and I'm with cjwatson here: I wouldn't rely on the precise semantics of those two states anyway
<psusi> so normal users can only set it to confirmed, and because I'm in the right group I am allowed to move it to triaged, which really then should get dev attention?  at least, is that the ideal?
* psusi tries to follow the good old rule of being strict in what you output, loose in what you accept
<pitti> psusi: it's more useful as a way to organize your personal bug list, but yes
<pkern> Does Ubuntu Firefox have some kind of ligature support?
<pkern> (They are drawed incorrectly on my Gutsy machine. The following char is painted over the ligature.)
<pitti> pkern: apparently; 'ffl' renders badly
<pkern> pitti: So I should file a bug against mozilla-firefox? It makes text badly readable, especially because they are even displayed in wrong font weights on some sites (i.e. I observed it on LP where "ff" in a word was rendered differently).
<pitti> pkern: sure (against 'firefox', though)
<pkern> Hm it is already reported and fairly old (LP: #37828).
<pkern> Bah, the workaround is to take a font which does not support ligatures.
<sladen> pkern: freetype, lower level than that
<pkern> It's a firefox bug.
<pkern> Gtk renders them fine, only firefox takes the wrong ligature width.
<pwnguin> is that why they went with a fixed-width font system for lp's comments?
* gnomefreak remembers that bug i could have swore it was fixed a while back.
<gnomefreak> pkern: on feisty or gutsy?
<pkern> gnomefreak: gutsy
<pkern> gnomefreak: Pretty fresh install.
<gnomefreak> pkern: ty talking with asac about it atm
<asac> pkern: do you have a testcase for that?
<asac> e.g. some page i can open to see the issue?
<gnomefreak> asac: how many pages do you want? theres a ton on that bug report ;)
<gnomefreak> ton == >=5
<pkern> asac: http://antigrain.com/research/font_rasterization/index.html :-P
<asac> i have visited too many bugs in the last few days ;)
<pkern> Search for "offset"
<asac> looks good here
<asac> lets see what font i have
<pkern> I have "serif", "sans-serif" and "monospace" in Firefox's font settings.
<asac> ah ok its different in epiphany
<Riddell> mvo: ping
<pkern> So it probably matches to the (Gnome?) default fonts.
<Riddell> mvo: I think I need to upload a revert to distUpgrader
<pkern> asac: It's *fixed* in Epiphany? Then I would switch back. :-P
<Riddell> mvo: can I just commit and you'll do that for me?
<asac> pkern: yeah its fixed in there ... most likely because epiphany chooses a different set of fonts for gecko?
<pkern> asac: So that means you have no ligatures at all in epiphany?
<asac> yes maybe epiphany doesn't use pango?
<pkern> Phew.
<pkern> Argh. Could somebody please kill `epiphany'.
<asac> pkern: yes if i start firefox with MOZ_DISABLE_PANGO=1 its /fixed/ ?
<asac> :)
<lamont> pkern: they don't allow guns at my office.
<gnomefreak> asac: i dont htink it "did" atleast in edgy because that is where most of the firefox bugs about pango slowing fox down people used epiphany to speed it up or they would turn pango off
<asac> pkern: in the same way fixed as in epiphany
<mvo> Riddell: sure, what do you need ?
<Riddell> mvo: remove the killall and go back to using the dcop code to kill adept
<Riddell> mvo: although I'm not sure the best way to test it
<mvo> Riddell: I take that this is urgent and should go in before beta?
<Riddell> mvo: yes
<mvo> Riddell: consider it done
<Riddell> mvo: I've not committed yet
<mvo> Riddell: sure, commit
<Riddell> well, I should test it first, and I don't know how to do that
<Riddell> it needs adept to download a copy and validate the signature etc but I can't sign it
<Riddell> spose I can hack adept not to validate
<lamont> slangasek: would you be annoyed if I marked bug #144364 for beta milestone?
<ubotu> Launchpad bug 144364 in expect "Please sync expect (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/144364
<mvo> Riddell: or just run "./build-tarball" in the DistUpgrade dir and copy the tarball into your testsystem and unpack it
<pkern> asac: Yep, no ligatures in epiphany. \:
<pkern> asac: OTOH if the choice is between ligatures and invalid rendering... ;)
<pkern> But this firefox issue should really be fixed in some way or another before the release.
<slangasek> lamont: I think I might be confused
<asac> pkern: yes
<asac> pkern: remind me after beta
<asac> :)
<lamont> slangasek: it's a question of whether or not ia64 counts for beta... that's all. :-)
<pkern> asac: The problem is that we don't have milestones for >beta?
<lamont> and if I mark it for beta, then it shows up on your reports...
<asac> pkern: most likely we would need to go back to xft then for normal locales ... which i don't like
<asac> pkern: well you can target it for gutsy
<pkern> It's "Nominated for Gutsy".
<slangasek> lamont: well, it doesn't "count" for beta, but if the fix is straightforward and localized I'm happy to accept the fix
<slangasek> which is not to say it should be milestoned, but eh
<pkern> asac: Does that mean that it still needs to be accepted by a RM to be of use?
<asac> pkern: i must admit that i am confused that there is no final milestone as well
<asac> pkern: so what i did when i pushe back was 'just' schedule for gutsy
<mdz> mjg59: who's responsible for turning the backlight back on during resume?  (it doesn't get done on my T61)
<mdz> acpi-support?  X?  something else?
<ion_> Sorry, i forgot to turn it on. Ill do better the next time.
<rohan> jdong: ping, are you around ?
<mjg59> mdz: Are you running 32-bit or 64-bit?
<mjg59> The answer is vbetool, regardless, but the bug is in libx86
<mjg59> I've fixed it for 64-bit, 32-bit is harder
<mdz> mjg59: 32
<rohan> is it too late in the release timeline now to fix a bug in sound drivers which has been fixed upstream ?
<mjg59> rohan: For beta, yes. For final, probably not
<mjg59> mdz: The issue is that the IBM BIOSes try to read from an address just under 4GB
<mjg59> mdz: This doesn't work so well. We need a segfault handler to grab the previous instruction, disassemble it, read the memory, hand it back to the vm86 context and then reenter vm86 mode
<mdz> ick
<mdz> so I should reinstall as 64-bit if that's feasible for me
<rohan> mjg59: ok. i was referring to https://bugs.launchpad.net/bugs/109882 ... would you know what can i do further to help out with this bug ?
<mjg59> In 64-bit mode, we use x86emu and so can just catch the reads directly
<ubotu> Launchpad bug 109882 in fedora "Headphone automute not working" [Unknown,Confirmed] 
<mdz> mjg59: is there a bug open about this, and if not, should I file one?
<mjg59> rohan: If it's fixed upstream, find out which commit fixed it and mention that in the bug
<mjg59> mdz: There is, yes
<mdz> I looked and don't see one which is obviously a match
<mjg59> I suspect that many of the bugs that involve vbetool segfaulting are related to this
<mjg59> But it took me a while to realise what was going on - I didn't know that x86 could directly access >1MB from real mode...
<rohan> mjg59: problem is, it's a kernel bug, but i don't know how to find which commit specifically in alsa fixed it
<mvo> Riddell: I have a update-manager fix pending too, so please let me know when you are ready and I will upload
<rohan> how do i relate the two ?
<mjg59> rohan: Look at the kernel revision history at git.kernel.org
<mdz> mjg59: which vbetool command would it be which is failing?  i can try to confirm it here
<rohan> mjg59: err i mean, i'm not sure if the changes are in kernle yet. it might just be fixed in the alsa's code tree ?
<mjg59> mdz: vbetool post
<mjg59> rohan: Then find the commit in the alsa tree and link to it
<mdz> mjg59: yep, that triggers it
<mdz> Error: something went wrong performing real mode call
<mdz> and no backlight
<mdz> spawning a new X server fixes it
<rohan> mjg59: ah i see.
* rohan opens alsa-project.org
<mjg59> mdz: Hm. Just "Something went wrong", and no segfault?
<mdz> mjg59: correct
<mjg59> Odd.
<mjg59> Maybe lrmi already catches the segfault.
<mdz> exit(1)
<mdz> mjg59: is it worth trying POST_VIDEO=false?
<Amaranth> That reminds me, is there some guide to debugging resume issues?
<mjg59> mdz: No, that's not adequate
<mjg59> mdz: You can work around it for now by booting with acpi_video=s3_bios
<Amaranth> As far as I can tell my resume fails as soon as it starts, I don't even get a working num lock key
<mjg59> mdz: That runs the code in kernel mode, which means the VM limitations are somewhat less, well, limited
<Amaranth> Actually this sounds like the problems I was having with ata_piix awhile back, I should try changing my controller to legacy
<rohan> mjg59: well unfortunately i can't find the specific change in patch_realtek.c but i'm sure it's been fixed :-/ any more pointers ?
<mjg59> rohan: It definitely works with upstream alsa?
<rohan> mjg59: yes, i've tried
<mjg59> Ok, then I think you've done all you can for now
<mdz> mjg59: thanks.  is there anything else I can do to help define the problem, or do you know everything you need to know already?
<rohan> mjg59: because it's working perfectly on arch linux, and on driver i compiled in feisty using code checked out from the alsa hg repo
<mjg59> mdz: I've got the BIOS disassembly and function trace, so I think I'm set :)
<rohan> mjg59: the problem is, arch uses newer alsa than the one in kernel 2.6.22 or 2.6.23-rcX .. so it seems that none of the soon-to-be-released distros have this bug fixed. so there's nothing i can do, atleast for gutsy, before this change of alsa is merged in upstream kernel ?
<mjg59> rohan: It depends whether we pull upstream alsa into our tree or not
<Chipzz> sladen: I'm not sure I agree with the "should just work" assertion
<rohan> mjg59: ok, what if i attach a patch to that bug against kernel 2.6.22.6 which fixes the bug ?
<Chipzz> sladen: a very real concern is companies with confidential data; mounting of USB sticks there is not allowed, and you could circumvent that with plugging in your USB dongle and using your phone as a storage device
<mjg59> rohan: If it does, and if it's not just the entire file backported, sure
<mjg59> Chipzz: Then individual companies can set appropriate policies
<rohan> wow i think i already found the commit which fixes it. but i've got no way to check if my "hunch" is right or no
<rohan> http://hg.alsa-project.org/alsa-kernel/diff/3a300e020eca/pci/hda/patch_realtek.c --> this is what fixed it, i think
<mjg59> rohan: If you make that change to the Ubuntu kernel, does it work?
<rohan> mjg59: you mean, the gutsy kernel 2.6.22.x ?
<mjg59> Yes
<rohan> i have not tried.
<rohan> is there a way to try it without rebuilding the complete kernel /
<mjg59> No
<rohan> then ?
<rohan> oh, sorry. .
<rohan> that means i'll need to install gutsy
<rohan> mjg59: the file patch_realtek.c has changed so much since 2.6.22 that it's not possible to apply it over single diffs of alsa hg repo
<mjg59> rohan: If you can supply a working patch, then that would be helpful - but if not, then we'll still look into backporting the code
<rohan> mjg59: well i've attached a patch but basically it's just a backport of alsa-kernel as on 20070818 to 2.6.22.6
<pitti> new ubuntu alternates up for testing
<Lure_> pitti: btw, was crypt-auto removed or fixed for beta?
* Lure_ has seen some discussion earlier today
<pitti> Lure_: demoted to universe for now (i. e. removed from installer)
<pitti> Lure_: I'd rather not offer a broken feature when it sounds that sexy :)
<Lure_> pitti: ok, so it is planned to be done post-beta or gutsy+1?
<pitti> Lure_: depends; when we can fix the cryptsetup initramfs hook soon, we can add it again for final (since it's not the default option anyway)
<sladen> Chipzz: policy issue, vs. technical issue.
<sladen> Chipzz: technically, things should just work.  If somebody makes a choice ("sets a policy") that is different
<evand> pitti: were you planning on building daily lives anytime soon?  I have to in order to pull in the latest Wubi, and there's no sense in having two CDs separated by a few minutes.
<pitti> evand: hm, I'm currently building new ones
<evand> pitti: when did you start?
<pitti> evand: however, cjwatson mentioned that we'll need another ubiquity anyway? it's not in the queue yet
<pitti> evand: 10 minutes ago or so
<evand> ah, right
<evand> I had forgotten about that bit :)
<pitti> evand: I have no problem with triggering new ones in two hours or so
<evand> I'll wait then
<evand> ok, thanks
<evand> I'll take care of it in 2 hours if ubiquity is built
<pitti> evand: for my planning, do you plan a new ubiquity?
<pitti> evand: ah, you have cd building powers now? great
<pitti> evand: then I don't need to stay awake that long *and* get up early
<evand> pitti: indeed, for quite some time -- I just don't need to use it all that often
<evand> haha, apparently I do :)
<evand> yeah, if you ever need CDs built and want to go to bed, just let me know
<pitti> evand: last time I did a "sleep 7200 && cron.daily.. :)
<evand> haha
<evand> that works as well
<Riddell> mvo: do you know why dist updater needs to start a new X app?
<evand> pitti: re new ubiquity> there's 1.5.18 which is probably what Colin mentioned that has the fix for the OEM issue you mentioned earlier.  That hasn't been released yet, I'll take care of it now.  After that, it's quite hard to say if there will be any/many more ubiquity releases.  We're trying to work around the unionfs issues and get the windows installer work stable enough to be included in the beta.
<rohan> mjg59: as i've commented on the bug, i've found the specific commit upstream and listed it. nothing more i can do, right ?
<MacSlow> http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-6.2.png http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-5.png
<mvo> Riddell: sometimes it does that for the debconf questions
<MacSlow> what icon-set would you prefer?
<mjg59> rohan: I think that's it, yes
<heno> evand: what was fixed in the new wubi upload? I tried a few hours ago and it crashed at the partman step
<rohan> MacSlow: the first one. 6.2
<MacSlow> rohan, yeah me too
<MacSlow> but I better put that on the ml for more people to see
<rohan> MacSlow: assuming that even in the first one Custom appears only if ccsm is installed
<evand> heno: I *think* the partman bit is actually weird unionfs issues, but there might be more there.
<MacSlow> rohan, yes... that is always the case
<evand> heno: the new wubi is to fix the transition from alpha to beta, I believe
<rohan> though i must say compiz looks real strange on the latest live cd. there were 2 cm thick white borders around each menu .. which was not there in the earlier live cds
<heno> evand: ok. any suggestion on how to help debug the unionfs issue, or work around it to test the rest?
<rohan> and the wallpaper is strange, so is the new resolution problem which affects atleast me and jdong
<evand> heno: not entirely sure as Colin wrote the partman loopmounted fs code and I'm not too familiar with it yet.  If the bug you're hitting is in fact a unionfs issue, then unfortunately there's not much we can do at the moment.
<Ng> rohan: I think the white borders thing is known, it has to do with the radius of the shadow or something
<rohan> Ng: ah, i see
<slangasek> the known white border issue is already supposed to be fixed, I'd have thought it would be in the latest live CD by now
<slangasek> but maybe I have my timeline wrong
<rohan> well i was using 22nd september's cd
<evand> pitti or anyone else who can: can you upload and let ubiquity 1.5.18 through, it is a very small diff: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.18.dsc
<Keybuk> I can upload
<evand> thanks Keybuk
<Keybuk> though I wouldn't want to override an ftpmaster to get it through
<evand> ok
<Keybuk> they bite
<evand> hahaha
<Keybuk> my Soyuz powers are for emergencies, like when I upload something foolish and need to delete it out of the queue so nobody knows about it
<Keybuk> <g>
<evand> so often, basically
<Keybuk> :-O
<heno> same reason I always just edit wiki.u.c pages right on the web server, no logs
<heno> (joke)
<bddebian> pitti: Got a sec for a quick, probably dumb, .desktop file question?
<jdstrand> mdz: are you still seeing bug #99288? If not, what did you do to fix/workaround it?
<ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
<rohan> i think the reply of ubotu for "hi" needs to be changed.. it says "hi, welcome to ubotu" .. err, ubotu ? :P
<pitti> evand: looking at ubiquity now
<evand> thanks pitti
<Amaranth> arg, how do i get myself added to the list of people allowed to post to ubuntu-devel?
<_MMA_> Amaranth: If I remember correctly Colin admins it. He should be able to add you to the white list.
<ScottK> Amaranth: Wasn't it automatic?
<Amaranth> apparently not
<elmo> it is automatic, but there's a days lag or so
<elmo> and it only whitelists your addresses in launchpad
<Amaranth> Hrm, alright.
<Amaranth> elmo: Is your problem with switching multiple viewports fixed now?
<elmo> Amaranth: I have to admit I haven't had a chance, I'll boot back into compiz tomorrow when I'm @ the office and check
<Amaranth> elmo: Ah, alright. It should now take the same amount of time to do the animation no matter how many viewports you're changing between
<elmo> Amaranth: ah, hmm, ok
<elmo> Amaranth: seb was suggesting disabling the animation entirely if invoked by a keybinding, you guys didn't want to go with that?
<Amaranth> elmo: the problem is it's a different plugin
<Amaranth> elmo: the one that supports "go to viewport 8" cannot tell the wall plugin that it is the one requesting the change
<elmo> Amaranth: ah, ok
<elmo> Amaranth: well, I'll give it a go - I'd like to stick with compiz if I can :)
<Amaranth> :)
<Amaranth> elmo: I don't get your problem with increasing the text size in gnome-terminal. It does the right thing for me
<elmo> Amaranth: yeah, I think someone fixed that
<elmo> it was broken, I promise ;)
<Amaranth> elmo: ah, good news
<Amaranth> i saw :)
* mvo has seen that it was broken
<elmo> Amaranth: ok, yeah, the workspace switching is much better
<Amaranth> woohoo
* Amaranth closes that bug
<Amaranth> mvo: bug 141543 is fixed, right?
<ubotu> Launchpad bug 141543 in compiz "Gutsy regression - compiz no longer starts with a failed 3d texture size check" [High,Incomplete]  https://launchpad.net/bugs/141543
<mvo> Amaranth: yes
<Amaranth> mvo: did we ever decide what to do with bug 116807?
<ubotu> Launchpad bug 116807 in compiz "Number of rows of desktops forgotten if no switcher on panel" [Critical,Confirmed]  https://launchpad.net/bugs/116807
<Amaranth> mvo: it doesn't work with metacity either...
<mvo> Amaranth: yeah, lets move it down from critical to medium and add a task for metacity/libwnck-applet
<Amaranth> mvo: ok, 5 'High' bugs now and i think we can fix all but one of them
<mvo> Amaranth: which one is the one we can't fix?
<Amaranth> the one where alt-tab doesn't "talk"
<Amaranth> well, maybe
<Amaranth> but since orca kills my computer i haven't been too motivated
<Amaranth> brb
<mvo> Riddell: anything new about the u-m thing?
<mvo> Amaranth: ok
<Riddell> mvo: yes, think I have it sorted now
<Riddell> mvo: committed, ready to upload
<Riddell> mvo: err
<Riddell> the upgrade just asked me via debconf what PAM services to restart, the options included kdm, and it just killed X
<bryce_> I ran into that too
<bryce_> the dialog does suggest removing gdm and kdm, which I did and the install continued
<bryce_> I'm not sure why it would want to restart gdm/kdm in the middle of an upgrade
<Riddell> that really needs fixing before beta
<Riddell> is there a bug number?
<bryce_> don't know
<Riddell> I wish I'd payed some attention to it, don't even know what package it was
<bryce_> hmm, it was one of the daemons iirc
<Riddell> libpam0g/restart-services maybe?
<ScottK> Riddell: I'm pretty sure it's kees PAM update https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024213.html
<Riddell> keescook: could it be?
<keescook> the PAM thing is killing gdm/kdm yeah.  We should blacklist those services
<Riddell> keescook: that really needs fixed toot sweet
<mvo> Riddell: yeah, I reported that already
<keescook> sure, can you make a bug for it?  I'll go fix it up right now (waiting for kernel publications atm)
<keescook> mvo: ah, do you have a #?
<mvo> keescook: it should be on the beta list already :)
<tepsipakki> isn't there just a reload option for kdm too?
<mvo> keescook: bug #141309
<ubotu> Launchpad bug 141309 in pam "asks debconf question during upload" [Undecided,New]  https://launchpad.net/bugs/141309
<mvo> keescook: its not milestoned, but I think it should be
<Riddell> bug 139065 got there first
<ubotu> Launchpad bug 139065 in pam "pam upgrade restarts kdm without warning" [Undecided,Confirmed]  https://launchpad.net/bugs/139065
<keescook> mvo: your bug is slightly different (it's shouldn't ask at all) vs the kdm killer
<mvo> keescook: it definitely should not ask a end user
* Riddell milestones 139065
<keescook> mvo: right, agreed.  but how do maintainer scripts now a feisty->gutsy upgrade is happening?
<keescook> (rather than "just" a gutsy devel upgrade)
<mvo> keescook: you could check against the version you are upgrade from I guess. the dist-upgrader also sets a special environment (testing against that would be a bit messy)
<tepsipakki> seriously, isn't a reload enough.. then it could do that without asking
<keescook> tepsipakki: well, the other services need to be restarted too
<tepsipakki> keescook: hmm, right
<keescook> mvo: how did you handle this when openssl was upgraded (it did the same thing)
<mvo> keescook: I don't remember off-hand, maybe by lowering the debconf question priority (default during the upgrade is high)
<tepsipakki> keescook: there is an exception for gdm in the libpam0g.postinst, which makes it to use reload instead
<keescook> tepsipakki: yeah, using |kdm there will fix it, (building that now)
<tepsipakki> keescook: ah :)
<keescook> mvo: ah, I can drop the question priority then.  that should do it.
<Riddell> keescook: surely it needs an exception for all login managers?
<keescook> Riddell: it does -- what is xfce's?
<Riddell> oh, xubuntu just uses gdm, I didn't know that
<keescook> ah, okay
<keescook> are there any others?
<Riddell> keescook: ldm
<Riddell> wdm
<Riddell> xdm
<Riddell> and maybe sdm
<Riddell> slim too
<keescook> should I just add all of those too, or maybe strengthen the warning?
<Riddell> both?
<Riddell> can't just strengthen the warning, else kdm etc will always reboot
<Riddell> and it doesn't seem like a very interesting question to desktop users
<keescook> is ltsp's ldm's init script called "ldm"?
<nixternal> keescook: thanks for the uploads today
<Riddell> it would seem to follow the pattern :)
<mvo> Riddell: do you want to do the u-m upload or should I do it?
<keescook> nixternal: you bet -- sorry it took me a few days, I wanted to test the builds (I'm paranoid), but it got bumped by high-priority kernel updates.
<nixternal> keescook: paranoia with kdebase is a good thing :)
<nixternal> you weren't the only one
<keescook> nixternal: heh
<Riddell> keescook: it doesn't seem to have one http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=ldm&version=gutsy&arch=i386
<bryce_> Riddell: where are the release notes maintained?  I have a note I need to add to it about Xinerama incompatibilities with xrandr
<Riddell> mvo: probably best if you do it
<Riddell> bryce_: I'm not sure any exist yet
<mvo> I unmarked #141309 as duplicate
<mvo> Riddell: ok, I do that now
<bryce_> slangasek: do you know if anyone has begun compiling release notes for gutsy?
<Riddell> mvo: why isn't it a duplicate?
<mvo> Riddell: your is about killing kdm, mine is about question the question at all
<mvo> Riddell: I don't think that it should be seen at all (the question)
<mvo> it should just do the right thing(tm)
<keescook> e.g. even if we fix mvo's bug, we'd still have the kdm bug.
<Riddell> seems like a strongly related problem since one causes the other as it stands
<Riddell> keescook: I was hoping you'd fix both :)
<keescook> Riddell: I will be.  :)
<mvo> Riddell: right
<Riddell> bryce_: https://wiki.kubuntu.org/GutsyGibbon/Beta would be a place for them
* mvo is very confident in keescook
<keescook> mvo: what is the env variable?  I think it's correct to leave it at "critical" if someone is crazy enough to do an "apt-get dist-upgrade"
<bryce_> aha, https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
<Riddell> hmm, someone should probably have told the release team about that
<cjwatson> Riddell: pam should use '/etc/init.d/* reload' for *dm and (if it doesn't already) kdm should support the same thing that gdm does in that reload should only take effect after all current sessions have ended
<cjwatson> IMO
<cjwatson> ah, I see that some of the discussion above covered that
<slangasek> keescook: if you give me another day, I can have a revised PAM in Debian available for merge that only restarts kdm when it's not in use (and unstable already has a version that doesn't need to kill gdm)
<keescook> cjwatson: since the list of services pam restarts is fixed, I've just added the exception for kdm, wdm, and xdm as well now.
<slangasek> ("restarts kdm without warning", har)
<keescook> slangasek: cool.  are there other changes in there too?
<cirkit> ?
<Riddell> slangasek: I'd rather have this working as soon as possible, upgrades need testing
<mvo> keescook: RELEASE_UPGRADE_IN_PROGRESS
<slangasek> keescook: and kdm reload doesn't do anything useful afaik, so is a wrong fix
<slangasek> bryce_: ah, don't know yet, no
<keescook> slangasek: well, the init script thinks it does something (though it may not re-exec -- i.e. wrong fix), but it certainly shouldn't just kill it :)
<bryce_> slangasek: I found one someone started at https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
<bryce_> s/someone/Fabio/
<elmo> gah, abiword for the lose
<slangasek> mvo: I'm not sure "cause service interruptions for all PAM-based services without warning" is "dtrt"?
<elmo> helpfully exports to text, complete with deleted parts of a word document under ""revision control""
<slangasek> keescook: there are other PAM changes pending, but I don't think I'll have them all ready so soon (ari wants me to add some auto-twiddling for xscreensaver, but that needs some further debconf template rewrites)
<keescook> mvo: perhaps if there are "non-default" services running, we can set the question priority at critical?
<keescook> i.e. restarting cron, cupsys, and gdm automatically isn't a problem... but other things might be surprising.
<slangasek> (and ssh)
<mvo> ok, fair enough
<mathiaz> keescook: did you get a BFe for apparmor ?
<keescook> slangasek: right, though ssh isn't install by default.
<mvo> I really do not want it in a upgrade from a desktop system as it does not mean anything to the user
<keescook> mathiaz: haven't asked yet, sorry, my morning was eaten by kernel updates.
<mathiaz> keescook: did you merge my branch ?
<slangasek> keescook: yes, but I exclude ssh explicitly from the list to be confirmed because ssh can be safely restarted without interrupting current sessions :)
<mathiaz> keescook: I'm going to push more changes related to profiles.
<keescook> slangasek: ah, good point.
<mathiaz> keescook: it may not qualify for BFe.
<keescook> mathiaz: the new changes may not, you mean?
<slangasek> hmm, maybe I exclude it;  now I don't remember
<mathiaz> keescook: yes. The changes to the profiles.
<keescook> mathiaz: let me make sure I'm up to date ...
<keescook> mathiaz: okay, go ahead
<keescook> slangasek: I don't even see ssh in your list?
<slangasek> keescook: oh, that's right; ssh doesn't even need a restart because it seems to magically reexec itself on every connection
<keescook> hunh.
#ubuntu-devel 2007-09-25
<slangasek> keescook: so the comments in the kdm init script say only that "reload" reloads the configuration (the standard behavior, anyway).  It would be great if kdm did support the same re-exec behavior as gdm, but I don't currently see any evidence of that.
<slangasek> also, the other *dm's folks mentioned don't depend on libpam0g; the only ones that do are xdm, wdm, kdm, and gdm
<Riddell> keescook: how's that pam fix doing?  worth me staying up to let it passed unapproved?
<keescook> Riddell: I've got it ready -- I was going to do an upgrade test and am waiting for my feisty vm to finish doing regular updates.
<keescook> Riddell: while we're at it, can I get a beta-freeze exception for apparmor?  there are some fixes we'd like to get into beta so people have a usable logging system.
<Riddell> keescook: could do, although I'd need to see a proper changelog and be sure it was well tested
<Riddell> this is on the CDs?
<keescook> Riddell: it is on the CDs, yes.
* mvo will wait for his test-compile of gnome-control-center and then go to bed too
<wasabi> So, I'm trying to reply to this guy who is talking about installing newer upstream versions of .deb files. He seems to run some repository of backports.
<wasabi> He's trying to make a case that installing newer versions of packages which also exist in Ubuntu's repositories is a good idea, and something users should be assisted in doing.
<Burgundavia> wasabi: is that the guys that runs getdebs?
<wasabi> Yes. ;0
<Burgundavia> right
<Burgundavia> the answer for that is to point him at dholbach
<Burgundavia> that is now his job
<wasabi> I personally don't think users should be assisted in doing this. I don't think it's a "good idea". I think a repository like that would be better served by distributing a renamed version of the package.
<wasabi> Oh?
<Burgundavia> dholbach is all about growing MOTU
<slangasek> oh, I thought you were saying dholbach's job was to control the getdebs guy
<Burgundavia> the real answer to get these people helping MOTU
<wasabi> MOTU provides new versions to old releases?
<wasabi> -backports being the answer, correct?
<Burgundavia> a lot of getdebs stuff is completely new
<Burgundavia> lots of games
<wasabi> Also how did you know I was talking about getdebs?
<Burgundavia> the debs are utter crack as per policy, but they appear to install/reinstall fine, in my limited experience
<cjwatson> if you want something in backports, getting it through MOTU is the first step
<ajmitch> slangasek: we wouldn't wish that on him
<Burgundavia> wasabi: it was the biggest source I can think of
<wasabi> Yeah, so my answer appears to be the same a) new versions of existing packages outside of Ubuntu repositories is silly. If you have a reason for it, it means MOTU is too hard or your packages are crack.
<ajmitch> wasabi: we've talked with him before, he just wants newer stuff for stable releases
<wasabi> b) if you have no intention of distributing said packages in ubuntu at all, perhaps because they are closed source, then they should not be named the same as packages in the repository.
<wasabi> ajmitch: Which is the definition of -backports, no?
<ajmitch> you'd think so
<wasabi> (this arises because he has asked me to add pinning support to gapti)
<ajmitch> but we don't backport everything
* ajmitch had someone asking when gnome 2.20 would be backported to feisty 
<wasabi> My person opinion is pinning doesn't solve any of the actual issues with this.
<ajmitch> certainly not
<ajmitch> then you can end up pulling half of the development release in
<wasabi> And if you really want to distribute your own duplicates, just rename them, and install them in another directory, so as not to step on toes.
<Fujitsu> Hm, no. Asking them to make changes is going to just kill more stuff. Better to just have them upgrading things than moving and breaking things more.
<wasabi> And then add Conflicts so the dependency graph can be intelligent about not allowing you to do stupid stuff.
<cjwatson> is anyone here suffering from unionfs problems on a current live CD, who'd be willing to try an updated .ko from me to see if it fixes stuff?
<cjwatson> (basically just applying unionfs 2.1.4)
<wasabi> My main concern is new upstream versions of packages which are depended upon by official packages. Where an official version is released with an updated local version and updated dependencies, which is incorrectly fulfilled by the backport.
<Fujitsu> Firefox FTW.
<ScottK> wasabi: He's been talked to repeatedly about working within the Ubuntu process and declines.
<wasabi> Does he have a reason?
<ScottK> It's to hard.
<_MMA_> wasabi: Lack of time and difficulty.
<ajmitch> and that we focus on development releases
<ScottK> He does hang out in #ubuntu-motu and we 'discuss' it now and then.
<wasabi> Is that a genuine complaint?
<KaiL> eeks, something in todays gutsy-updates kills grub :/
<ScottK> wasabi: Which?
<cjwatson> evand: could you try http://people.ubuntu.com/~cjwatson/tmp/unionfs.ko for me, please?
<cjwatson> evand: easiest way to try it is:
<wasabi> His MOTU complaint.
<cjwatson> evand: boot without 'splash' and with 'break=mount'
<evand> cjwatson: will do, let me just confirm that I can reproduce the unionfs errors first
<ScottK> The hardest part of packaging is understanding policy/licensing stuff.  That's the part he gets to skip if he works in his own repository.
<cjwatson> evand: at the initramfs prompt, wait a few seconds, then 'ipconfig eth0' (or whatever your most convenient network interface is)
<ScottK> wasabi: I don't think it's significantly harder than it needs to be.
<evand> shouldn't that be ifconfig eth0 up
<elmo> cjwatson: is that a typo you keep making, or is there really an ipconfig command in that enviroment?
<evand> I think you've been in Windows too much lately
<cjwatson> evand: wget http://91.189.90.132/~cjwatson/tmp/unionfs.ko
<cjwatson> evand: mv unionfs.ko /lib/modules/*/ubuntu/fs/unionfs/unionfs.ko
<cjwatson> evand: no, it really is ipconfig
<cjwatson> and no 'up'
<evand> oh
<evand> ok
<cjwatson> it's a busybox dhcp client
<cjwatson> and yes, you need to use people.u.c's IP address too - no resolver in the initramfs
<cjwatson> when you've done the above and checked it all worked, 'exit 0' to resume the boot
<cjwatson> it's behaving for me so far ...
<cjwatson> (you should confirm that that's really rookery's IP address and that I'm not evil-cjwatson trying to trick you, of course)
<evand> hahah
<elmo> (because you know, evil-cjwatson couldn't possily MITM a http connection)
<cjwatson> elmo: details
<cjwatson> scping it from rookery to somewhere local first might be a good plan
<evand> of course I can't get unionfs to die when I want it to
<wasabi> Our -backports suffers from this problem too, though.
<wasabi> Oh well.
<Amaranth> wasabi: Suffers from what problem?
<cjwatson> KaiL: kills in what way?
<Amaranth> wasabi: oh
<KaiL> cjwatson, doesn't start (and says nothing)
<Riddell> keescook: I'm off to sleep, poke early risers Mithrandir or pitti to let through pam (or cjwatson if he's still awake when you upload)
<wasabi> Amaranth: Example: foo (1-1ubuntu1) and bar (1-1ubuntu1) bar depends on foo (>= 1-1ubuntu1). Very typical. foo is upgraded to (1-1ubuntu2), which adds some sort of local patch which bar now depends on. bar's dependency is updated. Backport of foo (2) was installed. foo now satisfies bar's dependency even though it doesn't.
<keescook> Riddell: (dang, just missed you) okay, it's uploaded.
<KaiL> booting rescue system, chroot, 'update-grub' and 'grub-install /dev/hda' fixes it - so either the conf brokes or something with the MBR
<mjg59> wasabi: Isn't the version numbering for backports supposed to prevent that?
<Riddell> keescook: oh, well
<wasabi> Does it?
<keescook> Riddell: ah! you're still here.  :)
<mjg59> Oh, no, not in that case
<Riddell> I'll wait a bit then
<mjg59> wasabi: No, wait, I don't get that. If bar depends on foo, it should now be foo (>= 1-1ubuntu2), right?
<wasabi> Yes.
<wasabi> foo (2) satisfies that.
<cjwatson> KaiL: shame that you tried both update-grub and grub-install in the same rescue run, since that means we can't tell which fixed it
<mjg59> Why does foo (2) satisfy that?
<wasabi> (a backport of foo was installed, new upstream version)
<mjg59> Oh
<wasabi> because 2 > 1?
<KaiL> cjwatson, that's what I thought after rebooting too ;)
<mjg59> Because it's a new numbering
<keescook> KaiL: I had this happen a few weeks ago.  when was the last time you updated?  (I thought my problem was related to other things I was doing at the time, but I could never prove it)
<KaiL> but as there's no new grub, but a new kernel-image, I guess, it's the conf
<mjg59> Hm. Yes. Trying to describe a branch with a set of numbering like this is less than ideal
<wasabi> Yeah.
<KaiL> keescook, yesterday
<cjwatson> wasabi: backports are always of official versions, and if both 1-1ubuntu2 and 2 are official I don't expect features to go missing in general
<mjg59> wasabi: I suspect that the backport versions need to be glued into the release version
<keescook> KaiL: okay, so mine was probably not the same cause.
<mjg59> Oh. Yes, also what Colin says
<wasabi> cjwatson: Well, it's more about new features being added.
<cjwatson> wasabi: we did vaguely spec out an idea for feature dependencies rather than versioned dependencies eons ago (hoary or so), but it's a Hard Problem
<wasabi> Yes. It's very hard. I don't really think it's worth solving either. The backport for foo should have been renamed.
<cjwatson> wasabi: but you're talking about a new feature in 1-1ubuntu2 which isn't in 2. I claim that this is rare and should normally be considered a bug
<wasabi> And conflicted or become parallel installable with the official foo.
<wasabi> cjwatson: Oh? I'd suspect it happens all the time.
<cjwatson> wasabi: bugs happen all the time, yes
<wasabi> Heh.
<wasabi> How is that a bug?
<cjwatson> wasabi: but how is this different from the same thing happening within (say) gutsy?
<wasabi> We add features all the time. :)
<Riddell> keescook: accepted
* Riddell snoozes
<wasabi> cjwatson: Because it can't, as far as I can tell.
<cjwatson> you're talking about a feature being removed within a versioned line
<keescook> Riddell: \o/  thanks for pinging me about it :)
<cjwatson> wasabi: completely and utterly false, I'm afraid
<KaiL> keescook, I guess something with the new kernel-images...
<Riddell> thanks for the fast fix
<wasabi> No, I'm talking about a feature being ADDED
<cjwatson> wasabi: in an *earlier* version
<cjwatson> and not added in a later version
<cjwatson> that's equivalent to the feature being removed in the later version
<wasabi> Yes, an ubuntu local feature. We have tons of those.
<wasabi> Alternatives come and go. The names of things change.
<cjwatson> yes, and any official (i.e. from Ubuntu) version should preserve those features
<wasabi> update-scripts change calling convention.
<wasabi> Wait let me wrap my head around that.
<cjwatson> that's why we have a merge process rather than blindly sucking in new upstreams and throwing away all our patches
<wasabi> We should preserve features that do not yet exist?
<cjwatson> I give up
<wasabi> =(
<mjg59> wasabi: Ubuntu backports are based on Ubuntu packages.
<cjwatson> I need a whiteboard to explain this adequates
<cjwatson> adequately
<mjg59> wasabi: Therefore, before you can get foo (2) as a backport, it must already be in a later version of the distribution
<mjg59> wasabi: All the functionality that any packages depend upon should be forward ported from the version 1 package to the version 2 package
<wasabi> I see. So the person releasing foo (2) as a backport must know to release bar (2) also?
<mjg59> What? No.
<wasabi> No, wait I get you.
<wasabi> Don't worry about it. It clicked.
<mjg59> If foo (2) satisfies the dependencies of bar (1) but it doesn't work, foo (2) is broken
<cjwatson> right, if it actually has a reason to break bar (1), then it should use Breaks: to declare that
<cjwatson> or maybe Conflicts:, depending on the exact situation
<cjwatson> but it's not allowed to just break it without declaring that
<Nafallo> mjg59: this laptop is great :-)
<wasabi> Okay, I see what you're saying then.
<wasabi> The problem obviously still exists for external repositories. Which is why getdebs sucks.
<Nafallo> mjg59: you dont happen to know if the fingerprint reader is easy to make do something? ;-)
<cjwatson> so far, this unionfs is being a good boy
* cjwatson runs through a ubiquity installation
<evand> it looks like there's only one way to reproduce the unionfs bug here -- wubi
<mjg59> Nafallo: Thinkfinger
<evand> haven't tested that theory yet
<cjwatson> evand: you might need to regen the CD based on that .ko
<Nafallo> mjg59: kewl. thanks.
<evand> cjwatson: can you elaborate?  Do you mean run a CD build with the new unionfs (whenever it gets uploaded), or remaster a CD with the ko?
<cjwatson> evand: I meant the latter
<cjwatson> I think giving this a decent test is a prereq for uploading it
<evand> that would make sense, I suppose
<nemik> is anyone running compiz willing to try a quick thing for me please?
<nemik> run terminal from Applications -> Accessories -> Terminal. then maximise it with the little top-right box icon
<nemik> is it totally maximised or are sides and top kinda cut off?
<mneptok> "With the 'My Trojans And Malware' subscription service, Vista users can be assured that the malicious software they use has been provided by authentic Russian identity thieves and Afghani opium cartels."
<Fujitsu> mneptok: Haven't they ever heard of cross-platform compatibility? I'm feeling left out :(
<mneptok> Fujitsu: SuSE and Ximian will be implementing it
<mneptok> </obligatory_jab>
<Fujitsu> Heheh
<zul> mneptok, how?
<mneptok> zul: don't worry about it. finish eating your Dana and you can have ice cream.
<zul> nice..
<nemik> anyone running compiz?
<zul> not here
<pipegeek> Howdy, all.
<pipegeek> Just tried to do an online ext2-resize on feisty, and was told that online resizing for ext2 wasn't enabled in the kernel.  I'll go ahead and enable/recompile when I have time..... but why should this be?  And wasn't it enabled as recently as this Summer?
<pipegeek> this is IA32, btw
<cjwatson> pipegeek: it's an ext3 feature, I believe
<pipegeek> What is?
<pipegeek> resizing?
<cjwatson> online resizing
<pipegeek> That's odd.  OK, let me try something then
<cjwatson> the feature definition in the kernel is called EXT3_FEATURE_COMPAT_RESIZE_INODE
<pipegeek> I feel like a big fat doofus.
<pipegeek> Thank you, cjwatson.
<cjwatson> no worries
<nemik> is anyone running compiz?
<bddebian> nemik: No one that's sane :-)
<nemik> lol, makes a lot of sense
<nemik> it's frustrating as all hell
<nemik> making it default is gonna be lols
<mneptok> if you use the word "lols" in seriousness, Conpiz is not ready for you. ;)
<mneptok> *Compiz
<mneptok> i wonder if we can have a "You must be this tall to ride this ride," dialog for the Desktop Effects syspref
<StevenK> lamont: It looks like kohnen and primero hate the world.
<bddebian> heh
<nemik> haha, nice
<mneptok> nemik: sorry, couldn't resist. and yes, i'm already aware i'm an ass, TYVM. ;)
<nemik> mneptok: nah, it's cool. i just use it casually
<mneptok> nemik: doesn't negate the fact i'm an idiot :)
<Fujitsu> Has anybody seen complete screen corruption early in alternate installation on i915?
<Fujitsu> (tried yesterday's nightly, worked OK with Feisty and earlier)
<fen> nemik, i run compiz for two reasons alone, 1 im a very visual person and the desktop cube gives my the ability to visually map out my workspace, 2 proper translucency(sp?) in terminals, when you run as many terminals and use them as much as i do black and white becomes an eye strain.
<fen> that and theres nothing wrong with eye candly as long as it doesn't get in the way.
<_MMA_> Fujitsu:
<_MMA_> I have
<Fujitsu> Bah, running compiz was a mistake, it seems... My  maximised terminal is now all bouncy :(
<Fujitsu> _MMA_: Is there a bug on it, or should I file one?
<fen> Fujitsu: bouncy?
<Fujitsu> fen: Yeah, there's a small gap on either side of the window, so it's trying to snap to both edges, but can't.
<_MMA_> I saw it with the Ubuntu Studio dailies. Colin knows about it.
<Fujitsu> _MMA_: Great. Thanks.
<fen> Fujitsu: using compiz from the gutsy repo?
<Fujitsu> fen: Yes.
<mneptok> Fujitsu: not using the new "intel" driver?
<Fujitsu> gnome-terminal has a resizing limitation, so doesn't quite fit.
<Fujitsu> mneptok: I am.
<mneptok> k
<cjwatson> _MMA_: (but it's not something I can do anything about myself)
<fen> Fujitsu: open ccsm and disable inverted snap in the wobbly plugin.
<cjwatson> _MMA_: Fujitsu said "early" though, so it may not be the same thing. Yours is most of the way through installation.
<mneptok> cjwatson: are you not at home ATM?
<Fujitsu> cjwatson: Well, soon after the base installation finishes.
<cjwatson> mneptok: I am
<cjwatson> Fujitsu: ah, yeah, same thing then
<mneptok> cjwatson: if you are, you arce hereby commanded to bed.
<mneptok> *are
<_MMA_> cjwatson: Hmm... Yeah. Mine happens when xorg gets setup.
<Fujitsu> I have photos, if it helps.
<_MMA_> cjwatson: Man. Not getting much sleep are ya? :)
<cjwatson> mneptok: I wish. I'm not up for fun
<Fujitsu> fen: Ah, thanks, turning that off fixed it.
<fen> np.
<mneptok> cjwatson: anything i can do from a slightly less late tz?
<fen> setting up xgl & fglrx for dual screen compositing was an utter bitch.
<fen> on the brightside i now know a good deal of fglrx driver options and the fundamentals of mesa
<cjwatson> mneptok: not a lot unfortunately, I'm trying to beat wubi into shape
<cjwatson> but thanks for the offer
* jamesh gets ubuntulooks working with firefox on AMD64 again
<_MMA_> cjwatson: Should I look at installer bugs to make sure the Intel issue I have has been reported?
* _MMA_ hopes Colin actually went to sleep.
<cjwatson> _MMA_: it's been reported a zillion times on xresprobe / xorg / xorg-server / blah
<cjwatson> it isn't an installer bug
<nemik> fen, Fujitsu: gvim has the same problem
<Fujitsu> nemik: Not surprising.
<nemik> but firefox, calculator, etc are fine
<_MMA_> cjwatson: Ok. I figured but wasnt sure. :) Please try to get some rest.
<nemik> Fujitsu: inverted snap is disabled already for me...
* netjoined: irc.freenode.net -> kubrick.freenode.net
<nemik> Fujitsu: does negative plugin work for you? the Super+N ? I get black windows
<Fujitsu> nemik: Negative works for me.
<nemik> gutsy repo compiz? what driver/card?
<Fujitsu> Latest gutsy compiz, intel on i915.
<cjwatson> _MMA_: I appreciate your concern, but I would find it easier if everyone stopped nagging me to go to sleep. :)
<nemik> ah. i got a i965, this thing is all messed up. xv doesn't work either. or negative. no wonder it was blacklisted i guess
<_MMA_> cjwatson: Yeah. I did think that after I posted. :)
<stdin> hmm, isn't there some old archive repo for horay somewhere?
<StevenK> old-releases.ubuntu.com
<stdin> ahh, thanks
<pitti> Good morning
<evand> morning pitti
<StevenK> Morning pitti
<StevenK> pitti: libgbf-1-0 and libgdamm-3.0-7 can be NBS'd out when you're ready.
<StevenK> pitti: And openoffice.org-l10n-common (blink) is on the list.
<pitti> StevenK: yeah, both oo.o and oo.o-l10n FTBFSed
<pitti> calc: still here?
<StevenK> Neat.
<stgraber> pitti: Morning, yesterday you added a 20070924.1 ubuntu desktop ISO set that didn't exist on cdimage, I renamed it to 20070924.3 which is I think what you wanted to add
<pitti> stgraber: hm, weird; I did start a new live build .1, but evand started another one
<evand> cjwatson ended up doing it, but I think the resulting image was 20070925.
<stgraber> pitti: there was .1 for alternate but .3 for desktop (built at ~21:00 UTC)
<pitti> stgraber: ah, I see; weird
<stgraber> oh, OOo build failed
<stgraber> checking for curl-config... no
<stgraber> configure: error: install curl to run this script
<stgraber> make[1] : *** [stamp/build]  Error 1
<pitti> stgraber: known
<pitti> stgraber: fixed version is in the queue, but too late to take chances now
<StevenK> pitti: Missing Build-Depends?
<stgraber> indeed, 12hours to build a new OOo is uhm, long :)
<dholbach> good morning
<stgraber> hi dholbach
<dholbach> hey stgraber
<ajmitch> hi dholbach
<dholbach> hey ajmitch
<stgraber> pitti: are we going to have a new build in the next two hours or can I test the current one (20070925) ?
<pitti> stgraber: currently building new ubuntu-meta, so we should have final candidate images in ~ 4 hours
<stgraber> ok
<pitti> stgraber: testing the current ones would be helpful for verifying the new wpasupplicant
<stgraber> ok, I'm running the new wpa_supplicant on my laptop and it seems to work correctly (but I should test its behaviour on suspend/resume a bit more)
<ScottK> pitti: Are we back to asking you archive admins to process syncs or am I authorized to use the magic script?
<pitti> ScottK: I'd prefer using sync-source for packages where it works with, but in general I don't have much of a problem with the script
<ScottK> pitti: If the orig.tar.gz is newer than we have and someone uploaded it to a PPA is a case where sync-source won't work, right?
<ScottK> Or did that get fixed?
<pitti> right
<ScottK> OK.  I'll do that one with by hand then.
<kagou> good morning
<stgraber> pitti: default wallpaper is missing on 20070925
<pitti> stgraber: known, dholbach is on it
<pitti> stgraber: once this is in, I'll start two publishers for ubuntu-meta and wallpapers and build new CDs
<stgraber> ok
<rohan> the wallpaper remains that dark brown one ?
<dholbach> pitti, stgraber: doing a test build and then will upload
<dholbach> pitti, stgraber: uploaded
* pitti hugs dholbach 
* dholbach hugs pitti back
<kagou> it's beautiful :)
<pitti> dholbach: why version .17?
<dholbach> pitti: I did not want to mangle the changelog - do you want me to change it?
<pitti> dholbach: it's a bit strange, but *shrug*, debdiff looks good enough
<dholbach> ok great
<pitti> dholbach: so, your desktop wallpaper is back on upgrade?
<dholbach> pitti: yes
<stgraber> pitti: should I have fixed unionfs on 20070925 ?
<pitti> stgraber: not sure, please check the version of linux-ubuntu-modules
<stgraber> only 12.31 so I don't think so
<stgraber> ok, I'll wait till next ISO as this one is getting stuck while scanning disks (and looking at dmesg it seems to be an unionfs bug)
<pitti> stgraber: just try booting it again? that helped for me yesterday
<\sh> hmmm...xrandr dual head mode is completly broken..or vmware doesn't honor new xorg features...
<\sh> setting up dualhead works on my desktop here...starting vmware, switching to fullscreen and switching back but brings the monitors back to clone mode
<rohan> any kernel packager around here ?
<stgraber> pitti: indeed, second try worked :)
<rohan> just wanted to draw attention to https://bugs.launchpad.net/bugs/automute
<kagou> dholbach, "dropped Elephant pic, no space for that" -> lol
<dholbach> kagou: it's a very nice pic, it's a shame to drop it
<pitti> but, but, this is gutsy gibbon, not electric elephant...
<dholbach> check it out at http://daniel.holba.ch/temp
<rohan> dholbach: elephant-skin.jpg going to be the default gutsy wallpaper ?
<rohan> it'd be beautiful
<dholbach> rohan: unfortunately not; you'll need to talk to kwwii about that
<rohan> awww ok
<rohan> so the default wallpaper remains the dark one ? that's nice too, just a bit too dark ;)
* minghua wonders which part of elephant skin that is.
<pitti> minghua: almost the entire side, it looks like
<dholbach> maybe we should save it for 'eclectic elephant'
<minghua> pitti: To be honest, I can't really tell that's an elephant.  I would believe if someone say it's from a hippo, too. :-)
* netjoined: irc.freenode.net -> kubrick.freenode.net
<kagou> is pm-utils planed to be included in default configuration ?
<kagou> it's very usefull for notebook.
<kagou> after trying to put my notebook on sleep, an applet invit me to visit http://people.freedesktop.org/~hughsient/quirk/ here i find an script http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-debug.html that ask me to put a line on /etc/pm/config.d/unload_modules and now all is working
<seb128> kagou: that looks like a debug feature for unstable cycle
<seb128> kagou: shouldn't those quirk updates rather pushed in gutsy if required?
<kagou> don't know
<DamienCassou> hi
<DamienCassou> Can someone tell me what is the status of https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/144207
<ubotu> Launchpad bug 144207 in debian-installer "gusty installation failed with "Hash Sum mismatch"" [Undecided,New] 
<DamienCassou> is there anybody out there?
<pitti> hm, no idea about that, it doesn't seem to happen generally
<pitti> Sep 23 12:37:29 in-target: Failed to fetch cdrom:[Kubuntu 7.10 _Gutsy Gibbon_ - Alpha i386 (20070923)] /pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb Hash Sum mismatch
<pitti> mvo: ^ any idea?
<DamienCassou> someone told me yesterday (on #ubuntu+1) that a discussion about that problem happened here yesterday
<mvo> pitti: uh, bad burn? but let me read the bugreport first
<DamienCassou> it was gnomefreak if I remember correctly. He told me two people here discussed about that
<DamienCassou> ok
<DamienCassou> mvo: has you can see, it can't be a burning problem
<mvo> DamienCassou, pitti: I think I overheard some squashfs issue on the livecd yesterday, maybe its releated?
<DamienCassou> I used only alternate
<pitti> it's alternate/
<pitti> ?
<pitti> right
<mvo> og
<mvo> ok
<DamienCassou> and differerent versions (not from yesterday)
<mvo> DamienCassou: but only kubuntu? I will sync a image then
<DamienCassou> no, not only
<DamienCassou> in the bug report, I say it also happens on Ubuntu daily from 2007-09-23
<pitti> FYI: Rebuilding all CD images (the final beta ones, hopefully)
<DamienCassou> pitti: tell me when I can test something
<DamienCassou> pitti: thank you
<pitti> DamienCassou: nothing on that image has a particular bug fix in that direction, though
<pitti> DamienCassou: new Ubuntu alternates ETA: 15 minutes
<liw> pitti, you're building images that are going to appear on cdimage.ubuntu.com?
<pitti> liw: right
<DamienCassou> I was trying to burn a mini image, but today I can't get access to my cdburner. I always have a message saying it's busy. lsof /dev/cdrw returns nothing
<liw> pitti, so I shouldn't waste my time spending the current ones, I guess, if new ones are about to appear
<pitti> liw: is your 'work boostrapping' far enough to help with CD testing? did you already talk to heno about that?
<pitti> liw: right; alternates are quick to build, we shuold start with those
<liw> pitti, I did talk and I've done some initial testing yesterday (gutsy-desktop-i386 from "current" as of about 20 hours ago), and will try to do some actual testing and reporting today
<pitti> liw: great, thanks; you have your iso-testing account etc.?
<liw> pitti, er, um, maybe?
<pitti> liw: on https://iso.qa.stgraber.org, I mean
<liw> pitti, ah, I made one yesterday
<pitti> for reporting results
<pitti> good
<liw> I even cliced "ok" on "cd check"
<liw> but I think I need to figure out a clever way of making sure I am testing the version in the tracker
<pitti> liw: if you mount it, then you can look into .disk/info
<pitti> liw: or you md5sum the image and compare it to the md5 file on cdimage
<liw> pitti, thanks, that'll do for now; with "clever" I meant "automated so that I never, ever need to do any manual work every again, like, not once more" :)
<pitti> liw: add the loop-mounting, cat, and umount to your scripts which jigdo/rsync CD images? :)
<Riddell> sladen: how did that usplash change go?
<liw> but I'll figure something out for if and when I'll automate the whole testing process
<pitti> crud, amd64 alternate is within limits now, but i386 is still oversized
<Mithrandir> or use isoinfo to extract the .disk/info file
<Mithrandir> and make that tie into iso.qa.stgraber.org
<pitti> ah, the i386 one still has ooo-base
<norsetto> who is taking care of mirrors, for issues like those in bug 144511? mirrors@ubuntu.com?
<ubotu> Launchpad bug 144511 in ubuntu "default korean mirror has been dead for one month" [Undecided,New]  https://launchpad.net/bugs/144511
<Mirv> could people with non-english gutsy check bug 139370, I think it's really important if it's not just me
<ubotu> Launchpad bug 139370 in nautilus "[gutsy]  "Home Folder" not translated, even though translation exists" [Low,Confirmed]  https://launchpad.net/bugs/139370
<sladen> Riddell: nobody has complained and none of the people with broken systems have jumped up in praise of the lord either with cries of it being sorted for them
<Mirv> too bad most developers seem to use English, while majority of ordinary users not :(
<sladen> Riddell: I'm going to try with a vmware/qemu when I get back to real bandwidth
<pitti> so, 20070925 alternate will not be the final image, but shuold be good to test
<Mithrandir> Mirv: it's confirmed, yes.
<Mirv> Mithrandir: yep, seb128 just now asked there if anyone else is still seeing it
<Mirv> and I don't think it's low if it affects every non-English user, that's why more testing would be nice
<seb128> Mirv: I'm using french and it's correctly translated
<Mirv> seb128: hmm, that's weird then. the translation is there also for Finnish, in nautilus, and it was confirmed by a Spanish user
<seb128> Mirv: do you mean that you still get the bug?
<Mirv> seb128: yes, my gutsy is up to date, both a clean installation from two weeks and this feisty I upgraded last Thursday
<seb128> Mirv: maybe you can try to debug it? I don't get the issue here
<Mirv> seb128: ok, I'll try. can you say if the string is anyway coming from Nautilus, and from Nautilus's strings?
<seb128> Mirv: it's coming from rosetta's language pack
<Mirv> seb128: yeah, but if the string is represented by nautilus (the program) and translated from nautilus mo files
<Mirv> or some other package
<seb128> Mirv: are you speaking about the icon on the desktop or in the places menu?
<Mirv> since the same string is translated eg. in Nautilus file browser's "Go" menu
<Mirv> Places
<seb128> places is gnome-panel
<seb128> that's not the same translation file than nautilus
<seb128> strings are not shared between component, that doesn't work this way
<Mirv> ah, yes that's what I meant, thanks
<DamienCassou> pitti: can you tell me when the image is ready please?
<pitti> DamienCassou: they are
<DamienCassou> pitti: where can I download them please?
<DamienCassou> pitti: I can't find them neither on cdimages* nor on iso.qa*
<pitti> DamienCassou: cdimage.ubuntu.com, as usual
<DamienCassou> pitti: ok. I download http://cdimage.ubuntu.com/daily/20070925/gutsy-alternate-i386.iso
<pitti> DamienCassou: NB that it's still too big, I'm fixing that
<sladen> Riddell: what's the exact name of the other kubuntu/xubuntu/foobuntu packages that need revving for usplash artwork;  the naming isn't consistent
<DamienCassou> pitti: I'm currently trying the mini image. Will update the bug report when this is done. After that, I will try your new image
<TheMuso> sladen: There is one for ubuntustudio, but we have other fixes coming for that, so if you would mind just telling me what needs changing, I'll encorporate it into the upload.
<gnomefreak> DamienCassou: i told hobbsee not you ;)
<Riddell> sladen: kubuntu-artwork-usplash gobuntu-artwork-usplash edubuntu-artwork-usplash xubuntu-artwork-usplash
<Riddell> looks consistent to me :)
<DamienCassou> gnomefreak: I don't understand
<TheMuso> Riddell: Except for usplash-theme-ubuntu and usplash-theme-debian and usplash-theme-ubuntustudio :p
<Riddell> seems the -artwork packages win on numbers
<TheMuso> oh well.
<Riddell> sladen: going by kubuntu they need the .c file copied to the appropriate place, then all the colours changed throughout the file
<gnomefreak> DamienCassou: i told hobsee that they were talking about it. i only told you that i saw the conversation because she asked me about it
<Riddell> that really should be fixed to be easier to change, it would be trivial
<DamienCassou> gnomefreak: does that change anything?
<TheMuso> Riddell: I've done it for ubuntustudio, so the art folks can do it themselves. Just a matter of breaking them out into a header, and commenting/documenting appropriately.
<Riddell> yep
<TheMuso> sladen: nm, I see the only thing you changef ro usplash-theme-ubuntu was the x pos of the progress bar, which will need to be different for the ubuntustudio theme anyway.
<sladen> TheMuso: that was the only value I found that didn't satisfy two times A plus B equals C.  Has the misalignment even been reported on studio?
<TheMuso> sladen: No, but I thought it was a change somewhere else in the code. The ubuntustudio usplash screen is somewhat different to ubuntu's, but I'll keep that change you made in mind should we need it, thanks.
<tepsipakki> pitti: I'll update the new ati & nv to the queue so they are ready for post-beta
<pitti> tepsipakki: please
<tepsipakki> done
<sladen> TheMuso: I suspect it's the symptom of blinding copying and pasting hard-coded values.  One fat-fingered mistake gets spread everywhere
<sladen> TheMuso: ironically, you might be the only person that didn't "blindly" copy that across ;-)
<TheMuso> sladen: As I said earlier, I've broken out the settings for progressbar etc into a separate header, and thats now in the hands of the art guys to position it where they want it.
<dholbach> Tonio_: thanks for uploading that patch
<ogra> pitti, hmm, seems i didnt get any fresh livefs the last three days
<pitti> ogra: oh? can you please check edubuntu livefs logs?
<ogra> the isos are nearly the same, but there should be a lot gone from -desktop actually
<pitti> ogra: nothing on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<pitti> ogra: so it might be an uninstallability due to seed blacklists, or so?
<ogra> when did the publisher run last ?
<ogra> dia-gnome and scribus should be off the cd since yesterday
<ogra> they show up in manifest
<pitti> ogra: it's running all the time
<pitti> ogra: dia-gnome> Task: edubuntu-desktop-kde, edubuntu-ship-addon
<pitti> ogra: likewise for scribus
<pitti> hmm
<mvo> DamienCassou: I'm just trying to reproduce #144207 here and so far I'm not lucky I assume you did not do anything special to trigger the bug?
<DamienCassou> nothing
<ogra> pitti, yeah, but neither -live nor -desktop
<DamienCassou> I'm trying to reproduce it with the daily alternate ubuntu currently
<ogra> it shouldnt get picked up
<DamienCassou> DamienCassou: I'm trying to reproduce it with the daily alternate ubuntu currently
<DamienCassou> mvo: I'm trying to reproduce it with the daily alternate ubuntu currently :-)
<DamienCassou> mvo: will tell you when I have a result
<pitti> ogra: your latest livefs was built successfully?
<ogra> i thought so
<pitti> seems like it
<ogra> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/edubuntu/latest/livecd-20070924-i386.out looks fine to me
<ogra> Get:740 http://ftpmaster.internal gutsy/main edubuntu-desktop 1.44 [16.4kB] 
<ogra> aha+
<ogra> that should be 1.45
<pitti> too old?
<ogra> yeah
<pitti> hm, that's in the archive
<ogra> weird
<pitti> ogra: was it current at the live fs build time yesterday?
<ogra> livecd-20070924-i386.out                           24-Sep-2007 01:17  8.5M
<ogra> is that UTC ?
<ogra> if that 1am it wasnt there indeed :)
<DamienCassou> pitti: mvo: the bug appeared again with the current daily iso
<ogra> pitti, sorry, i was to blind to notice the time difference ... can you trigger another live for me ?
<mvo> DamienCassou: strange, I can not reproduce it here, let me try again on a different machine
<DamienCassou> pitti: mvo: I didn't rebooted my computer so that you can ask me to try things
<mvo> DamienCassou: sha256 of /cdrom/pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb
* dholbach hugs Michael 'sponsoring mvo' Vogt (for more publicity and to remind people to upload/reply to the bugs on http://daniel.holba.ch/sponsoring)
<mvo> sha256sum that is
<pitti> ogra: of course
<ogra> thanks :)
<pitti> ogra: but I just triggered new builds about 1.5 hours ago, they should be good for you
<DamienCassou> mvo: sha256sum not found
<ogra> ah, great
<pitti> ogra: it's building xubuntu now, your images shuold be ready
<ogra> what happened to alternate ? it grew by 1M for me
<pitti> http://cdimage.ubuntu.com/edubuntu/daily-live/20070925/
<pitti> \o/ well within the limits
<ogra> gutsy-desktop-i386.iso          25-Sep-2007 11:41  695M
* ogra dances
<mvo> DamienCassou: right, minimal environment. hm, does "python -c 'import apt_pkg' " work?
<pitti> ogra: so now we just need to fix your alternate/i386, then we are good
<DamienCassou> python not found
<DamienCassou> maybe I need to chroot?
<ogra> pitti, what changed in ubuntu ? i didnt do any changes yesterday and it was 700M (still 200k oversized or so)
<ogra> now iots 701
<pitti> ogra: unsure
<DamienCassou> mvo: python not found. Do I need to chroot?
<ogra> pitti, i was counting that i inherit some of the 4M you have to kill from your alternate and was hoping it would be enough to get my i386 ready
<mvo> DamienCassou: its worth a try, also if it failed in acpi unpack, then there is going to be little in the chroot
<pitti> ogra: OO.o failed to build
<mvo> DamienCassou: but checking is certanly a good idea
<ogra> s/counting/counting on the fact/
<pitti> ogra: so what I did now was to remove openoffice.org-base from ubuntu-desktop
<ogra> argh
<DamienCassou> mvo: chroot /target
<ogra> so you will have a majorly oversized CD sooon ?
<pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.gutsy/revision/1092
<pitti> ogra: I'll put it back in after beta, when we'll get the slightly downsized OOo
<ogra> yup
<ogra> should i do the same ?
<pitti> ogra: not sure, your call
<ogra> i mean 1M isnt the world ...
<pitti> ogra: depends on whether you have anything else to kick off ship
<ogra> i can get that by pngcrushing some more images soemwhere i bet :)
<DamienCassou> mvo: sha256sum /cdrom/pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb
<ogra> btw did someone look into gnome-users-guide if we can do anything there ?
<DamienCassou> mvo: 7d38f61b51...
<pitti> ogra: if you need to rebuild e-meta, it'll take 2 hours, so fiddling -ship might be better
<pitti> ogra: not yet
<ogra> 14M feels a bit big, there are not *that* many screenshots
<DamienCassou> mvo: what do you think?
<mvo> DamienCassou: could you please put the full checksum to paste.ubuntu.com?
<ogra> pitti, well, there are some uncertainities in my installer part that might need a meta rebuild anyway
<DamienCassou> let me try
<ogra> so i'm not to worried about that one :)
<pitti> ogra: well, it has per-language screenshots, that's it
<ogra> argh
<ogra> sounds like a good candidate for a langpack-screenshots-<$lang> package
<mvo> DamienCassou: lets move this to a private chat, I will have more questions for you and I don't want to spam the channel too much :)
<DamienCassou> mvo: http://paste.ubuntu.com/430/
<cirkit> is it possible to remove my ban from #ubuntu and #ubuntu+1? those niggers banned me for no reason
<twinoatl> mvo, it's me
<mvo> hello twinoatl
<DamienCassou> mvo, I'm now trying to install ubuntu on the other computer
<Chipzz> cirkit: "those niggers" probably did not ban you for no reason. The fact that you call them "those niggers" rather proves that they most likely HAD a reason. And this is not the place to come whine about your ban there, kthxbye
<mvo> thanks DamienCassou
<cirkit> Chipzz, I demand an apology letter immediately. I am Mark Shuttleworth's uncle and do not appreciate this kind of service.
<Chipzz> omg, this is hilarious :)
<ogra> heh
<DamienCassou> mvo, what about the part of the bug report which deals with apd.html ?
<cirkit> well then, I will just go ahead and format my Ubuntu install and use Gentoo instead ... Ubuntu has lost another user ;)
<mvo> DamienCassou: I wonder if its bad hardware in some form, but the fact that it always fails on the same file is puzzling
<Chipzz> mark shuttleworths uncle using gentoo... rrrrrrright :)
<mvo> any ops in here?
<Pici> cirkit: If you wish to contest your ban, you can join #ubuntu-ops and wait for an operator.
<DamienCassou> mvo, during install, the problematic file is acpi*.deb. But during the CD check, it is apd.html
<DamienCassou> mvo, and always these files. Whatever the ISO I burn
<DamienCassou> mvo, I think the installation of acpi happened and it worked. I'm continuing to be sure
<mvo> DamienCassou: ok, so it looks like there is something special about this particular machine
<DamienCassou> mvo, I think so. What can I do?
<pitti> ogra: any plan yet?
* pitti rebuilds Ubuntu images
<ogra> pitti, nope, looking into ship
<ogra> hm, there is not much in ship-live
<pitti> ogra: live is good
<ogra> build-essential would probably work
<pitti> ogra: you need to downsize ship, right/
<pitti> ?
<TeTeT> iwj: I tested the slmodemd on my T40p yesterday, no change - still reports NO CONNECT
<ogra> oh, right
<ogra> sorry, confused atm
* pitti hugs ogra
<pitti> heno, stgraber: FYI, xubuntu and kubuntu builds should be good now, tracker updated
<mvo> DamienCassou: not sure, let me think about it over lunch
<ogra> hah !
<Riddell> pitti: alternate and desktop?
<pitti> heno: will you coordinate testing or shall I pingsomewhere else?
<pitti> Riddell: yep, both
<Riddell> thanks
<pitti> Riddell: at least from my side (size-wise, etc.)
* ogra foud apache2-mpm-worker .... moodle already brings in apache2-mpm-prefork :D
<Riddell> kubuntu never was overweight :)
<ogra> meh
<pitti> ogra: ah, php
<pitti> ogra: but only .5 MB
<DamienCassou> mvo, ok, thank you
<ogra> 400k only :/
<ogra> well, thats half of what i need :)
<ogra> hmm, can i drop postfix ... ?
* ogra wonders what would be unhappy then
<pitti> ogra: if nothing else helps, drop bzr?
<DamienCassou> mvo, do you know if I can install ubuntu using the manual approach for acpi as we did previously?
<ogra> well, i'd prefer dropping postfix, but i'm not sure thats a good idea
<mvo> DamienCassou: out of curiosty, does the same (or a similar) error happen on the desktop cd install? it uses a different method for instlaling
<DamienCassou> mvo, I never tried desktop installation
<mvo> ok
* mvo -> lunch (for real now)
<DamienCassou> mvo, do you want me to try?
<DamienCassou> mvo, ok, see you
<mvo> yes :)
<stgraber> pitti: ok, cool
* pitti dances
<pitti> http://cdimage.ubuntu.com/daily/20070925.1/
<pitti> 700 MB i386
<pitti> stgraber, heno: ^ good for testing
<liw> pitti, so I should test that, too?
<pitti> liw: if you can, sure; I'm testing amd64 alternate+desktop
<liw> I have an amd64 (= also i386) machine that is not being used for anything right now, so I'm happy to test whatever works on it
<pitti> liw: i386 would be good
<pitti> liw: if you have time afterwards to test some more amd64, so much the better :)
<pitti> mvo: do you have time to do new upgrade tests? the previous one had a serious bug, which should now be fixed
<pitti> ogra: please tell me when you finished mangling seeds, since this requires some publisher mangling
<ogra> 10 mins
<ogra> i'm on it
<pitti> ogra: right, I'm not hurrying; just coordinating
<ogra> yeah, already pushing
<ogra> i'D like to have edubuntu ready asap for various raisins :)
<pitti> ogra: oh, don't talk as if we had a release in two days or so
<ogra> (and currants :) )
<ogra> nah, i wouldnt dare :)
<ogra> push done
<pitti> ogra: publisher started
<\sh> well, anyone in here who needs a good sysadmin with debian packaging knowledge, rpm packaging knowledge, etc.?
<pitti> ogra: so what did you remove?
<ogra> postfix and the second apache
<pitti> ogra: I'd like to check the Task: headers after the first and second publisher run before building CDs
<pitti> ah
<ogra> if we get at leats 1M from oo.o i'll add it back
<sladen> ogra / pitti: bzr is all python text-files, bz2'ing it saves about a 1/4. (0.3MB)
<heno> pitti: thanks I will coordinate
<sladen> if it gets that close
<pitti> ogra: should drop by some 4.5 MB
<ogra> and i highly hope for that one M :)
<pitti> ogra: erm, not Task: of course (it's only ship)
<heno> pitti: though poking people from different directions doesn't hurt :)
<ogra> well, that should suffice for even another small language :)
<pitti> ogra: so your edubuntu lives are good for testing, right?
<ogra> yep
<ogra> and server should be fine with the next build
<ogra> i should have learned now that we'll manage somehow, but i still think we'll never get them down to the right size ... every release again :P
<mvo> pitti: yes, after lunch
<pitti> mvo: supi, danke
<pitti> heno, stgraber: just for the records, tracker is up to date with CD versions and disabled selections now
<heno> pitti: great, thanks!
<pitti> http://cdimage.ubuntu.com/daily-live/20070925.2/ - the One True Ubuntu Gutsy Desktop images; get them while they're hot
<pitti> heno, stgraber, liw: ^ (tracker updated as well)
<liw> pitti, ack, I'll get to that after testing gutsy-alternate-i386
<iwj> TeTeT: Yes, that's expected.
<geser> doko: Hi, are the ddebs useful when one want to get a backtrace for a crash inside a python extension
<pitti> geser: wasn't that what python-*-dbg was supposed to be for?
<geser> will try that
<geser> as my test with the -dbsym packages wasn't successful
<doko> geser, pitti: the python-*-dbg packages usually contain two things: the debug symbols for the normal extension, the unstripped extension for the python-dbg interpreter. -dbgsym packages should not be needed
<pitti> doko: thanks
<geser> doko: thanks
<Kopfgeldjaeger> hi
<TeTeT> iwj: any chance of fixing the modems before release?
<iwj> TeTeT: I don't know.  I'm trying various tests to try to pin down the problem.
<iwj> TeTeT: while I've got you here, can you try   /etc/init.d/sl-modem-daemon stop  and then a few moments later   start   and see if that helps ?
<TeTeT> iwj: no change
<iwj> Harmf.
<iwj> Do you still have the 2.6.22-10 kernel installed ?  Can you try booting that ?
<soren> iwj: Did you want the debug output from slmodemd ?
<TeTeT> iwj: nope, I only have -12 on the system
<geser> doko: when I try to import gtkspell in python-dbg I get: ImportError: /var/lib/python-support/python2.5/gtk-2.0/gtkspell_d.so: undefined symbol: Py_InitModule4_64
<soren> iwj: I have -10. I'll test it.
<iwj> soren: Err, yes, please.  Email it to me, or attach it to some suitable bug ?
<iwj> soren: Thanks.
<AnAnt> Hello, I'm creating a package which includes a python module, this module is for use with apache, where should this module be installed ?
<doko> geser: then gtkspell probably is not correctly built
<doko> ask the packager ...
<soren> iwj: If that works, I'll grab the logs from that too for comparison.
<soren> iwj: I've actually got -6, -7, -8, -10, -11, and -12. It's -10 you want?
<iwj> Err, I think -10.  From tribe 5.
<soren> alright.
<seb128> geser: it's likely the dbg build not using python-dbg
<soren> iwj: -10 is the same here.
<soren> iwj: I've got to run now. I'll test with the older ones when I get back.
<heno> FYI: ISO testing subscriptions can be seen here: https://iso.qa.stgraber.org/qatracker/subscriptions
<Hobbsee> heno: sky fallen in yet?
<heno> Hobbsee: no I'm just running around warning that it's imminent
<Hobbsee> heno: ah, good, good.
<lamont> given an extant bug in bugs.debian.org, what's the easiest way to get that imported into launchpad?
<ogra> pitti, do you build the edubuntu-server isos or should i ?
<Hobbsee> lamont: perhaps ask on #launchpad ?
<pitti> ogra: publisher is on germinate
<pitti> ogra: I can do it
<lamont> Hobbsee: doh.  thanks
<ogra> pitti, thanks :)
<pitti> ogra: I build them right after publisher is finished
<ogra> oki
<ogra> just noticed they are not there yet ... didnt want to appear pushy :)
<pitti> ogra: running
<ogra> thanks
<ogra> my last rsync is just done :)
<pitti> heno: Ubuntu DVDs built, and added to iso-tracker; Kubuntu DVDs coming
<heno> pitti: oh, you've managed to shrink them?
<pitti> heno: thank Colin
<pitti> heno: he dropped *-dbg
* heno thanks Colin :)
<pitti> heno: hm, do you think I could rebuild the Ubuntu desktop CDs once more? when I rebuilt them last, the germinate overrides weren't up to date
<pitti> heno: it just affects a couple of langpacks, but so far there aren't any tests reported except mine
<pitti> heno: oh, nevermind, that just affects amd64, so it's not that important
<pitti> sladen: hm, usplash progress bar on live CD boot is still misaligned
<sladen> pitti: joy.
<Riddell> mvo: another fix needed for dist upgrader I'm afraid
<Riddell> mvo: is there anything fancy I need to do for upload except change the version in DistUpgrade/DistUpgradeVersion.py
<sladen> pitti: livecd under vmware, or real hardware?  Widescreen/not widescreen?
<pitti> sladen: vmware, will try real iron soon (but I think it happens there, too); standard 4 by 3 screen (not wide)
<StevenK> ... Ubuntu runs on your iron?
* StevenK ducks
<sladen> StevenK: Ubuntu Is Hot
<StevenK> sladen: Boo, hiss. :-P
<jdong> Ubuntu will get rusty soon though ;-)
<jdong> boo hiss yea yeah
* Hobbsee irons jdong, with the Ubuntu Iron.
<mvo> Riddell: not really, I usually use "debian/rules arch-build" to make it build
<mvo> Riddell: but that is probably overkill
<mvo> Riddell:  bzr-buildpackage should be fine
<mvo> Riddell: arch-build runs embedded tests etc
<sladen> pitti: can you screenshot the vmware box so I can measure pixels off
<pitti> sladen: http://people.ubuntu.com/~pitti/tmp/livecd-progress.png
<iwj> soren: 2.6.22-10 wfm so you must have some different problem, or something else is going on.
<pitti> ogra: http://cdimage.ubuntu.com/edubuntu/daily/20070925.1/ :(
<ogra> lol
<ogra> that can only be some bytes
<sladen> pitti: okay, at least I under stand /why/ now.  On the low-resolution it's still using a 320px wide image (rather than 216px)
<ogra> pitti, i think i'll drop the whole "Development" section from ship o be on the safe side it can come back after beta
<pitti> ogra: or just drop bzr
<ogra> pushing
<ogra> pushed .... should be up
<pitti> ogra: then let's hope that publishing an universe package is enough for publisher/germinate to make that active
<ogra> i'll likely have changes to the ltsp udeb still so its not that bad yet
<ogra> for testing 701M are fine atm
<pitti> ogra: ok, publisher is running; I'll rebuild alternates after that?
<Luke> asac: is there a -dbg package for nm in gutsy or are they in -dev?
<ogra> pitti, yup
<asac> Luke: there are dbgsym packages available
<asac> pitti: where can I find those ^^ now?
<pitti> heno, Riddell: up-to-date Kubuntu DVDs available and added to tracker
<pitti> asac: deb http://people.ubuntu.com/~ubuntu-archive/ddebs gutsy main
<liw> is "tribe" ubuntu-speak for "alpha" or "beta" version?
<pitti> liw: 'alpha'
<pitti> liw: and we recently agreed to not use the per-release codenames any more, but go with 'alpha'
<Luke> asac: what is that package called?
<cjwatson> pitti: for the next release
<pitti> liw: so far we used the noun for a group of the animal of the current release
<cjwatson> we should stick with what we have for gutsy
<pitti> oh, absolutely
<Luke> asac: pkg-create-dbgsym?
<liw> pitti, er, the release after gutsy is only going to be named by its version number?
<pitti> Luke: <original package name>-dbgsym
<pitti> Luke: i. e. network-manager-dbgsym
<cjwatson> liw: no, it'll still be called Hardy, but the alpha CD releases will just be called "Alpha"
<cjwatson> as opposed to whatever the collective noun for herons is
<pitti> liw: no, but it will be "alpha 1" instead of "<group of herons> 1"
<cjwatson> (siege)
<ogra> sad move ...
<ogra> even though i understand the need
<Luke> pitti: that package doesn't exist
<pitti> ah, I finally looked in a dictionary what "hardy" and "heron" mean :)
<pitti> Luke: do you have above apt source?
<StevenK> Heh
* ogra found such things always as part of the soul of ubuntu
<StevenK> Personally, I'd prefer the collective noun
<Luke> pitti: oh no. wasn't aware of that
<pitti> but it causes too much confusion for outsiders
<Luke> pitti: I was just looking in packages.ubuntu.com
<sladen> also helps when you got numpties furiously testing the Nth alpha of the previous version...
<pitti> Luke: Soyuz does not support debug symbol packages yet, so they have to live on people for the time being
<Luke> pitti: is it the repo you sent to asac?
<pitti> Luke: right
<Luke> alrighty - thanks
<Luke> I have to download the package from mac os x and then move it over to linux because... well it's a network problem
<Luke> so how do I get the package via http or something?
<pitti> Luke: sure, just browse the URL
<Luke> ah
<Luke> ty
<ogra> hmm, that virtualbx install seems stuck :/
<pitti> http://people.ubuntu.com/~ubuntu-archive/ddebs/pool/main/n/network-manager/
<pitti> ogra: where?
<Chipzz> Luke: apt-get has a --print-uris option
<ogra> pitti, still frist stage of DI in the HW detection, i blame Vbox for now
<pitti> Chipzz: doesn't help you without apt-get update...
<pitti> oh
<Chipzz> pitti: then do apt-get --print-uris update first? :)
<ogra> might be my vbox install i didnt use it for a while
<pitti> ogra: it gets stuck at 86% progress for me when it doesn't have internet connection, but your's is something else then
<Chipzz> pitti: and you can at least deduce the directory where to get them from ;)
<ogra> yeah, its stuck at 2% already
<pitti> Chipzz: he said he had a network problem
<Chipzz> pitti: you can dl the packages files and drop those in /var/lib/apt/lists if you'ld want to
<pitti> rigt
<pitti> +h
* Chipzz actually has done that in the past :P
<DamienCassou> mvo, still there?
<mvo> DamienCassou: yes
<DamienCassou> mvo, after installation from the Desktop CD, the application disappears and nothing happens
<mvo> DamienCassou: could you please run a memtester? it sounds like there is something fishy with the hardware
<DamienCassou> mvo, there were no problem with acpi
<DamienCassou> mvo, from where do I launch memtester?
<mvo> DamienCassou: its in the boot menu
<ogra> oh, whee, i already have a gdm screen on the -desktop cd ....
* ogra wonders why that is so speedy suddenly
<DamienCassou> mvo, started
<mvo> good luck
<DamienCassou> mvo, see you in some hours
<DamienCassou> mvo, when can I stop?
<ogra> pitti, edubuntu-desktop i386 looks really good on a first glance in VirtualBox
<ogra> gobby works ... ;)
<Riddell> mvo: I think I messed up the update-manager upload, would you mind doing it (will need to be 0.78)
<sladen> pitti: in some places the width of the pixmap is used;  in others the requested width from the theme.  Do you value the bar being centred more, or value the bar being less than the width of the logo more?
<pitti> sladen: 'visually appealing' :)
<pitti> sladen: so, centered is important I think; the particular size less so
<sladen> fg
<ogra> pitti, can you check on ubuntu if you have sudpend/hibernate in your logout menu ?
<ogra> i see it on edubuntu :/
<pitti> yes, it's there on my desktop
<ogra> (we have an initramfs caseper-bottom script that cares for disabling it
<ogra> gah
<pitti> ogra: oh, you mena in the live system?
<ogra> that needs to be fixed for final
<pitti> ogra: not sure, I'll check in a minute
<ogra> oki
<ogra> the script unsets the gconf keys for suspend/hibernate
<ogra> scripts/casper-bottom/32disable_hibernation ...
* ogra wonders whats wrong with it ... looks ok
<seb128> bah
<seb128> the screen resolution is wrong on my laptop (intel card)
<ogra> which driver does Xorg use ?
<seb128> gnome-power-manager estimates an unknow time for the battery discharge
<ogra> intel or i810
<ogra> thats hals fault
<jdong> seb128: is it Intel?
<jdong> oh lol you said it
<jdong> I can confirm on my macbook too; res 1024x768 is probed rather than 1280x800
<cjwatson> I have an ATI that refuses to go above 800x600 at the moment, haven't figured it out yet
<seb128> ogra: "intel"
<seb128> ogra: and do you know why gpm can't estimate the battery discharge?
<ogra> not really, no, but t gets the info from hal
<jdong> the Intels go beyind 1024x768 fine; displayconfig-gtk can set the right res
<jdong> but somehow the default probed res is 1024
<jdong> is that an xresprobe bug?
<ogra> oh crap ! can_hibernate and can_suspend were dropped from gpm gconf keys
<seb128> the informations dialog has the correct information
<ogra> ah, only moved
<seb128> ogra: only the systray icon has "unknown"
<mjg59> jdong: Yes
<seb128> looks like a gpm bug
<ogra> hmm
<jdong> yay bugs :)
<seb128> ogra: they changed location rather, that's /apps/gnome-power-manager/general/can_hibernate now
<sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/usplash-theme-ubuntu_0.16sladen1.debdiff  but the whole thing is broken by design
<Hobbsee> mmm...bugs...
* Hobbsee munches
<pitti> slangasek: ah, sweet
<ogra> seb128, bug #144790 filed ...
<ubotu> Launchpad bug 144790 in casper "hibernate and suspend are not disabled on gutsy liveCD" [Undecided,New]  https://launchpad.net/bugs/144790
<seb128> ogra: thanks
<ogra> hmm, there is no gutsy-final in the milestone list ?
* ogra would have milestoned it
<pitti> ogra: 'nominate for release' -> 'gutsy'
<ogra> ah
<ogra> hidden in the obvious place on the left :)
<Hobbsee> pitti: it seems there is no final milestone, though
<pitti> Hobbsee: it's not supposed to be
<Hobbsee> pitti: oh.  yet there are for previous releases.
<cjwatson> I had been meaning to add that actually
<pitti> we were asked not to do that any more
<cjwatson> I must have misunderstood ...
<cjwatson> are you sure?
<Hobbsee> cjwatson: i think i misunderstood that too
<Hobbsee> pitti: was that from the original phonecall?
<pitti> cjwatson: I thought we were supposed to use gutsy tasks for that?
<cjwatson> sigh
<cjwatson> I give up, I always get confused by this
<Hobbsee> pitti: the gutsy tasks means "this needs fixing in gutsy"
<cjwatson> ask Keybuk, he generally understands Mark's mind :)
<pitti> well, not that I would claim complete understanding of the LP designer's brains
<Hobbsee> pitti: the milestones are for "it needs to be fixed by this point"
<ogra> seb128, what does your gpm tooltip say exactly ?
<pitti> Hobbsee: right
<Hobbsee> cjwatson: no, this one does make logical sense - at least, i understood it.
<evand> while we're on the subject, is there a finer granularity than "later"?  That is, can we milestone things for Hardy?
<Hobbsee> pitti: does that make more sense?
<pitti> Hobbsee: but we use tasks rather than milestones for SRUs, etc., so it's sort of consistent
<cjwatson> how about we just add a release candidate milestone?
<cjwatson> that doesn't seem too wrong
<ogra> my battery is full so indeed it says "charge time: unknown)
<cjwatson> ubuntu-7.10-rc
<seb128> ogra: it's working now, it took it some time to get the estimation
<cjwatson> that gives us somewhere to move deferred -beta milestones
<cjwatson> evand: not at the moment
<Hobbsee> pitti: the SRU's were done before the plan change, i thought.  whichever.
<ogra> seb128, phew :)
<seb128> ogra: unplug, it should update for the discharge
<evand> ok
<Hobbsee> cjwatson: either - it'd be purely cosmetic, really.
<cjwatson> evand: we can't do that until the hardy distrorelease is created, basically - that's why we had the "later" hack
<cjwatson> pitti: is an ubuntu-7.10-rc milestone OK with you?
<ogra> seb128, well, i wouldnt have even expected to see a battery :) its a VirtualBox system ... even though it runs on my lappie it shouldnt have a batt
<pitti> cjwatson: oh, absolutely; I'm not picky about it at all :)
<cjwatson> done
<evand> ah, that's understandable then
<seb128> what are we supposed to use?
<seb128> milestones or gutsy tasks?
<cjwatson> for deferring things from beta, move to the ubuntu-7.10-rc milestone
<seb128> cool
<DamienCassou> mvo, no memory problem
<Hobbsee> seb128: i think hte plan is "both".  but in practice, i'm not sure taht's sane.
<seb128> I was missing a milestone to defer some bugs, thanks for adding it
<DamienCassou> mvo, all test passed
<Hobbsee> seb128: i'm presuming the use case is where it affects feisty and gutsy, which is done by nominations, and needs to be fixed by gutsy beta (the milestone).
<Hobbsee> at least, that's how i understand it
<ogra> sladen, i always wondered why its not possible for it to find the center of the screen itself buy checking the size and just compute the values
<ogra> hmm, yelp doesnt seem happy on the liveCD
* ogra tries running it from a terminal
<soren> iwj: eh? You have hardware for testing this yourself?
<iwj> soren: Yes.
<iwj> soren: Although my symptoms don't agree exactly with yours.
<soren> iwj: Oh?
<iwj> So I don't need you for primary testing, so to speak, but as additional data.
<iwj> Well, in tribe 5 + new kernel, sl-modem-daemon doesn't work when started at boot time but if I restart it it works.
<iwj> strace is unilluminating so far.
<soren> slmodemd provides a lot of debug info with "-d 5" added to its options.
<iwj> soren: Yes.
<iwj> I take it the error you see is
<iwj> err: modem:1: modem start = -1: cannot start device.
<soren> iwj: Sounds right, yes.
<dholbach> "The software source for the package  nvidia-glx-new  is not enabled."
<dholbach> couldn't that fire up the software-properties-gtk thing?
<dholbach> hum
<dholbach> main/restricted/universe/multiverse are enabled
<ogra> didnt we drop nvidia from ship anyway ?
<DamienCassou> mvo, still there?
<dholbach> ah, I had to refresh the apt cache
<dholbach> now, I can install it
<mvo> DamienCassou: yes, but I ran out of ideas
<mvo> dholbach: that sounds like the bug that it only works after the first apt-get update
<dholbach> mvo: right-o
<mvo> dholbach: is that alternate or desktop?
<dholbach> mvo: desktop
<davmor2> mvo: Have you remember that bug from yestsrday :)
<mvo> dholbach: I want to debug it, please
<mvo> davmor2: indeed, I'm still puzzled about it
<dholbach> mvo: fresh install from amd64 desktop cd
<mvo> dholbach: ok, please do nothing
<davmor2> mvo: I can do a fresh set of lists as I retesting the tests I did twice already ;)
<DamienCassou> mvo, can I continue the installation after having installed acpi manually (though apt-get) ?
<DamienCassou> mvo, ?
<mvo> DamienCassou: sorry, I'm not familar enough with the debian-installer to give you a good answer here. but I think its very difficult :/
<mvo> DamienCassou: what you could do is to copy the content of the CD into /target/var/cache/apt/archives before the install starts, that *might* work
<DamienCassou> mvo, ok
<Riddell> doko: I need to revert the change you did in bug 84689, it has broken packages which use libpythonize
<ubotu> Launchpad bug 84689 in pykdeextensions "libpythonize0-0.4.0-3ubuntu1 depends on python2.5-dev" [Undecided,Fix released]  https://launchpad.net/bugs/84689
<doko> Riddell: what exactly do you need to revert?
<Riddell> doko: I need to add back the dependency of libpythonize0 on python2.5-dev
<Riddell> it needs to load libpython2.5.so
<doko> IMO a library package depending on a -dev package is just so wrong ...
<doko> Riddell: fix it
<Riddell> sure, it's wrong
<Riddell> but my elite python/C skills do have limits
<doko> so you think I should look at it ...
<Riddell> doko: I think I should make a quick and hacky fix and add back the python2.5-dev dependency
<seb128> Riddell: make it dlopen libpython2.5.so.1
<doko> Riddell: please no:
<doko> $ fgrep -r libpython src
<doko> src/kdedistutils.py:#define LIB_PYTHON "libpython%(python_version)s.so"
<doko> src/kdedistutils.py:    // Reload libpython, but this time tell the runtime linker to make the
<doko> Riddell: improve your grep skills ;-p
<Riddell> hmm, adding .1 to that doesn't seem to help
<elmo> cjwatson, tfheen, whoever: could we please look at cleaning up cdimage.u.c?  it's up to 435Gb again
<pitti> ogra: ugh, sorry, forgot your CDs; did you already trigger them, or shall I now?
<ogra> feel free, i'm watching ubiquity while ubiquiting in the vbox :)
<pitti> ogra: apparently not, cranking
<DamienCassou> mvo, thank you for your help
<DamienCassou> mvo, I will try your suggestions
<DamienCassou> mvo, bye
<mvo> good luck DamienCassou
<asac> Luke: did you manage to get a backtrace?
<pitti> ogra: 20070925.2 server there, looking good, added to trackre
<ogra> yeap
<ogra> monitored it since 2min :)
* ogra waits for addon i386
<ogra> ah, there we go
<iwj> OK, freaky.  The sl-modem-daemon problem is due to _malloc failing_.
<iwj> (with EAGAIN)
<mjg59> iwj: How much space is it trying to malloc?
<iwj> 5479  mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
<iwj> As a result of calling  malloc(16384)
<mjg59> That's... very odd.
<iwj> Strangely, it does a successful brk right beforehand.
<slangasek> that's not in a unionfs context, is it?
<iwj> slangasek: Err, no.  Userland.
<iwj> And from an install, not a livecd.
<iwj> With plenty of swap.
<mjg59> iwj: Hm. The only terribly plausible thing from the manpage is that it's hit a resource limit?
<slangasek> okie
<pitti> evand, dholbach: ah, we are racing with amd64 tests :) I'm currently doing OEM/desktop and manual partitioning/alternate/CLI
<iwj> mjg59: I can check that.  Bear with me - it only does it when the daemon is started at bootup and my own shell has a sane ulimit setup.
<evand> pitti: I saw that but I figured it's probably a good thing in the event I miss something serious while testing.
<pitti> right
<pitti> evand: more tests -> always good :)
<evand> ah, indeed :)
<dholbach> calc: bug 5462?
<ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
<ogra> wohoo
<dholbach> everybody else, please check out  http://daniel.holba.ch/sponsoring/  too
<ogra> pitti, edubuntu-desktop-i386 seems food
<ogra> err
<ogra> good
<pitti> lol :)
<ogra> :)
<dholbach> please just at least comment on those bugs
<pitti> ogra: can you please put your results into the tracker?
<ogra> indeed
<ogra> hmm, should usplash use the screensize i selected in the isolinux menu ?
<ogra> it uses 1024x768 instead of the 800x600 i picked
<iwj> 5448  mlockall(MCL_CURRENT|MCL_FUTURE)  = 0
<iwj> mjg59: ^   thanks!
<mjg59> Ha
<iwj> And, of course:   locked memory(kbytes) 32
<mathiaz> dendrobates: can you update the link to the testcase in the tracker ?
<mathiaz> dendrobates: all the links are no longer valid since heno updated the wiki pages.
<dendrobates> mathiaz: I don't know.  I'll get back with you.
<pitti> did anyone experience unionfs crashes with today's images? I didn't (kudos!)
<ogra> me neither
<ogra> and ltsp works fine as well since the weekend
<heno> mathiaz: sorry :)
<ogra> (we use unionfs there ae well)
<ogra> pitti, its quite noisy in the logs i noticed, but thats all, no oopses anymore
<pitti> yeah, lots of debugging output
<heno> mathiaz: I moved your content here https://wiki.ubuntu.com/Testing/Cases/ServerInstall
<pitti> wow, I already prepared for release-noting that :)
<mathiaz> heno: yop. I noticed and updated the wiki page with anchors for each test.
<pitti> so now I'm running out of options what to write into "Caveats"
<ogra> lets add some ?
<mathiaz> heno: now we just need to update the links in the tracker.
<iwj> soren: Are you up for a test ?
<pitti> ogra: don't worry, there are some red bugs in the tracker already :)
<ogra> ah, good, so we dont run out of work :P
<iwj> TeTeT: Fancy testing what I think may be a fix ?
<evand> indeed, I haven't run into a single unionfs issue since the new version was released.
<iwj> ogra: Did you want to chat about ltsp-client and autopkgtest ?
<iwj> IIRC you were going to explain to me why it should be blacklisted.
<ogra> well, by design it needs a a chroot thats build with ltsp-build-client
<ogra> which autopkgtest wont do i guess :)
<iwj> Err, so it won't just work if you install it ?  Normally packages are supposed to work if you install them.  Why won't it make the chroot ?
<ogra> it has an explicit debconf error set if /etc/ltsp_chroot doesnt exist (ltsp-build-client touches that before installing ltsp-client/-core)
<iwj> OIC
<ogra> so one option is to blacklist it, the other is to create that file
<iwj> So they're weird packages which shouldn't be installed on normal systems at all ?
<ogra> right
<ogra> thats what the description says as well :)
<iwj> My autopkgtest can't understand descriptions :-).
<ogra> teach it ;)
<iwj> I'm trying to think if there could be a way for you to tell autopkgtest not to bother.
<ogra> wwell, just touch /etc/ltsp_chroot ?
<ogra> by default for all your chroots ?
<ogra> it wont do any harm to other stuff
<iwj> Surely that would be dangerous and anyway I don't think I want to add weirdo hacks like that.
<ogra> well, then ignore ltsp-client
<iwj> Obviously I can maintain a blacklist but if this kind of thing is going to happen a lot IWBNI it didn't have to go through me manually.
<pitti> evand: \o/ full test coverage of amd64/desktop with no bugs reported :)
<iwj> Would there be any point test-installing ltsp-client ?
<ogra> i doubt thats happening a lot
<ogra> not really
<ogra> all it has are deps and two initscripts
<ogra> you wont be able to test the initscripts without netbooting a client with them
<iwj> -core, too, though, which has more stuff ?
<evand> pitti: awesome!
<mathiaz> heno: is it possible to update the links to testcases from the admin interface or does it still need a direct database query ?
<ogra> yeah, we split ltsp-client into -core (initscripts and essential deps) and ltsp-client
<ogra> ltsp-client has the distro specifics ...
* calc will be testing the amd64 alternate cd as soon as it finishes downloading
<ogra> -core is identical in ubuntu and debian
<iwj> ogra: So really I mean, is there any point doing test-installs of -core.
<ogra> no
<ogra> and -client depends on -core
<iwj> ogra: OK, so just those two binary packages.
<ogra> so no there isnt any use for a test
<iwj> Any others ?
<ogra> ltspfsd
<heno> mathiaz: do you just mean the link at the top of the main page?
<ogra> it depends on ltsp-client-core so people can not accidentially install it
<iwj> ogra: Surely that might reasonably be installed on a non-ltsp system ?
<ogra> (in a non ltsp system)
<iwj> ogra: OIC
<iwj> Does it do something freaky that no-one else wants ?
<heno> mathiaz: or links to individual cases?
<ogra> it adds some udev rules that likely would break g-v-m on normal desktops
<mathiaz> heno: links to individual test cases
<iwj> OK, I think I should probably blacklist that too then.
<iwj> Another question is:
<ogra> but if you blacklist ltsp-client-core and your tool resolves deps that should suffice
<iwj> Are these things that mean they shouldn't be tested best thought of as bugs (even wishlist bugs) or just as a peculiarity that means the test is inapplicable ?
<iwj> ogra: I won't have the tool propagate blacklisting via deps.  That would mean it would fail to spot erroneous new dependencies for packages that ought to be tested.
<ogra> well, in an ideal world we'd have an ltsp-build-client autobuilder or something like that to test explicitly
<heno> mathiaz: looks like a DB change is needed. I don't see an admin option for changing anything about the test cases
<iwj> ogra: Right, but that would be separate.
<ogra> right
<heno> I'll ask stgraber to to poke at it
<ogra> since ltsp-clients are practically their own mini distro ... just using ubuntu packages
<mathiaz> heno: ok.
<iwj> ogra: So is the lack of usefulness of testing by just installing on a normal system a bug (or a thing we would like to change if we had time, or ...); or is it inherent and part of the package's definition IYSWIM.
<mathiaz> heno: last time I sent the new links to stgraber
<iwj> distro> Yes, I suppose I might argue you ought to count as your own derivative but I don't really want to go there.
<ogra> we're in two fractions upstream about ltspfs at least :) debian would like to be able to install it on a normal system, the ubuntuids dont like that idea :)
<keescook> pitti: is the x86 retracer dead?
<ogra> i'm personally in the "its a special package for a special purpose in a special env" so why should we make it installable on systems that have no use for it ?
<iwj> ogra: OK.  So we should let autopkgtest file its bug about ltspfs being uninstallable.
<iwj> ogra: And then set it to wishlist or some such.
<ogra> right
<iwj> I mean, if Debian think that then they probably have a bug for it already anyway.
<ogra> and leave it to debian to work out how to manage udev differentl P
<ogra> :P
<iwj> Right :-).
<pitti> keescook: hm, it hung on a bug; restarted, thanks
<TeTeT> iwj: absolutely
<iwj> And for the others they're just inherently weird and I should blacklist them at my end ?
<Mithrandir> as long as the description says "this might break your system in the following way", I think having it installable is fine
<ogra> yeah
<keescook> pitti: ah, okay.  thanks for checking.  :)
<iwj> TeTeT: OK, edit /etc/init.d/sl-modem-daemon.  In the shell function start() near line 108, add just before the call to  start-stop-daemon --start  this line:
<ogra> Mithrandir, i was tired of the broken systems and having to support them just because people dont read it :)
<iwj>     ulimit -lH unlimited; ulimit -lS unlimited
<iwj> TeTeT: And then restart the daemon or reboot or whatever you normally do.
<keescook> pitti: I would like to request a beta freeze exception for apparmor.  it fixes 141128 and 140508, which currently stop the profile-building tools from working.  debdiff is: http://paste.ubuntu-nl.org/38562/
<TeTeT> iwj: rock'n'roll, give me your number and my modem will call you know
<ogra> phew
<TeTeT> s/know/now
<ogra> keescook, that means a ull rebuild of all isos, doesnt it ?
<ogra> *full
<keescook> ogra: icgk.
<keescook> I was hoping they weren't final yet.
<pitti> keescook: hm, at that point it has to wait, I'm afraid
<keescook> I guess this can wait, then.
<pitti> keescook: I consider the current images as pretty much final, barring disasters
<keescook> pitti: okay, no problem.  they're understood bugs, we can live without it.
<pitti> keescook: something for the release notes, maybe?
<keescook> sure
<pitti> keescook: please do get it uploaded, though, so that it'll be available as updates ASAP
<iwj> TeTeT: You mean it's working ?  I usually test with http://www.freeukisp.co.uk/ (0844 711 0059, freeisp@internet, pw: internet).  I'm not affiliated with them and "free" ISPs are a bit flaky but they normally work.
<keescook> pitti: having it sit in the queue won't get in your way?
<TeTeT> iwj: I called my cellphone, it rang
<ogra> keescook, nit final but all in a very good shape for teh first time  since weeks
<iwj> TeTeT: Great.,
<ogra> *not
<iwj> TeTeT: I think I can call that a fix.
<iwj> TeTeT: I'll just wait for Soren to get back to me.
<pitti> keescook: no, there's plenty already
<TeTeT> iwj: I'll update the TOshiba and see if this works as well
<iwj> pitti: You don't want a new sl-modem-daemon at this point, do you ?  Looking at what you've just told Kees I take it the answer is no.
<jdstrand> mdz: are you still seeing bug #99288? If not, what did you do to fix/workaround it?  (it's driving me nuts)
<ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
<pitti> iwj: that's not in -desktop, so the case is a bit different
<ogra> iwj, queuing is always fine :)
<pitti> iwj: i. e. it doesn't matter if it is outdated on the CD (only in alternate ship, I think), unlike the apparmor fix
<iwj> Oh, not in the squashfs then.
<iwj> pitti: On the CD it's not installed by default but it's available for installation from the CD.
<iwj> ogra: Yes, I'll do that of course but I wanted to offer it to the RMs.
<iwj> And if can get it on the CD but only if I hurry I'll upload now rather than waiting for more "that fixes it" confirmations.
<mdz> jdstrand: I'm pretty sure that was fixed for me ages ago
<mdz> jdstrand: I think bryce knows what the issue was
<pitti> iwj: I won't rebuild CDs just for that, but I don't think that hurts
<pitti> iwj: unless, of course, someone needs sl-modem-daemon to actually get to the internet, but *shrug*
<jdstrand> mdz: ok thanks.
<mdz> jdstrand: it's possible that it regressed; I haven't been using that laptop since before the last -ati update
<iwj> pitti: Well, that was kind of the point of having it on the CD but we can say "it's only the beta".
<pitti> iwj: but having it in the archive is fine, just in case we do have to rebuild for another reason
<jdstrand> mdz: it just popped up for me recently
<jdstrand> mdz: there was a driver update, but I also tried compiz for the first time around the same time (since disabled it)
<jdstrand> mdz: don't know what caused it for sure
<mdz> jdstrand: you should follow up with bryce
<jdstrand> mdz: was is only in a gnome-terminal where you saw the issue?
<mdz> jdstrand: no, I saw it in gnome-panel most prominently
<jdstrand> mdz: will follow up with bryce
<jdstrand> mdz: thanks again
<mdz> jdstrand: note in Screenshot-1 the corruption across the System menu and firefox launcher
<jdstrand> mdz: I see that now
<mdz> jdstrand: your corruption looks different to me though
<mdz> jdstrand: do you ever get data from other windows, or only from redrawing within the window?
<jdstrand> mdz: both
<jdstrand> mdz: seems to mostly be the latter though
<jdstrand> bryce: mdz indicated you are familiar with bug #99288.  I have added some comments to that report, and am seeing it with the lastest gutsy.  Do you know what might be causing this, or a possible workaround?
<ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
<tepsipakki> jdstrand: try the latest driver from http://wiki.ubuntu.com/XorgOnTheEdge
<ant30> are there problems with gnome-appearance-properties ?
<ant30> It eat all cpu that he can
<bryce_> hi jdstrand
<gnomefreak> ant30: #ubuntu+1 for gutsy help (hint disable compiz)
<jdstrand> bryce: hi
<jdstrand> tepsipakki: I'll look at it
<ant30> yes, without compiz , only metacity
<ant30> well, I hava a Gtk-CRITICAL message with Blubuntu theme of repositories
<gnomefreak> ant30: i had that same issue except mine locked up
<jdstrand> tepsipakki: I am running latest gutsy
<gnomefreak> ant30: uninstall blubuntu packages and restart should clear it up some (once again #ubuntu+1 for support)
<ant30> If I try to close, it close, but run in background
<ant30> yes, I am doing that on this moment
<iwj> kylem: Sorry for imputing your flawless kernel.  You were right.  It was just coincidence that seemed to make it related to the kernel.
<kylem> iwj, all good.
<tepsipakki> jdstrand: but that version is not in gutsy, yet
<kylem> it just didn't seem likely since it's an older chipset.
<kylem> ich6 should be well debugged. :)
<jdstrand> tepsipakki: ah I see
<bryce_> jstrand, can you attach your xorg.conf and Xorg.0.log to that bug, just so we have it for comparison?
<ScottK> I'd appreciate it if an archive admin would please push gramps 2.2.8-1ubuntu2 out the door.
<pitti> ScottK: done three minutes ago
<iwj> pitti: sl-modem now in the approval queue, FYI
<ScottK> pitti: Thanks.
<pitti> iwj: it'll get to kubuntu, at least (due to CD rebuilds)
<LaserJock> pitti: do you know if new Edubuntu disks will be rebuilt before Beta?
<pitti> LaserJock: ogra's call
<pitti> LaserJock: nothing on my radar ATM
<iwj> pitti: Right.  Thanks for your time.
<LaserJock> pitti: k, thanks
<lamont> Error: Package: and Architecture: do not alternate in debian/control
<lamont> wth does that mean?
<pitti> lamont: ah, that's from pkg-create-dbgsym
<lamont> ok.  libast for motu.  neato
<pitti> lamont: probably a Package: record has two Architecture: fields (or none at all)
<jdstrand> bryce, tepsipakki: installed latest driver, will keep ou posted (sometimes it takes a while to show up)
<lamont> is pklg-create-dbgsym ours, or debian?
<pitti> lamont: mine
<lamont> ah, ok
<tepsipakki> jdstrand: does it show up when you change back from another desktop?
<jdstrand> tepsipakki: you mean via the the panel's workspace switcher?
<pitti> iwj: aah, so that's why it suddenly stopped working - new PAM with default ulimits
<tepsipakki> jdstrand: since this bug actually looks a lot like bug 120858
<ubotu> Launchpad bug 120858 in xserver-xorg-video-ati "Graphical corruption in gnome-terminal" [Undecided,New]  https://launchpad.net/bugs/120858
<iwj> pitti: I'm not convinced that that's it.
<iwj> pitti: Because I was able to make it fail in tribe 5.
<iwj> But only some of the time.
* jdstrand is reading 120858
<tepsipakki> jdstrand: well, I'm seeing that on feisty with nvidia binary driver
<pitti> iwj: hm, and we didn't have new pam at that time yet?
<iwj> I don't think so but I haven't checked.
<tepsipakki> jdstrand: and the window that suffers from that is runnig screen on another machine
<iwj> I think there's just been too much confusion because if you run it from sudo it works fine.
<iwj> So if you upgrade or restart it from a terminal, it starts working.
<iwj> And I don't have notes which say exactly what shape my tests were.
<pitti> iwj: right, 0.79-4ubuntu2 in tribe 5
<tepsipakki> jdstrand: right, from the switcher or ctrl-alt-arrow
<pitti> iwj: and the various MODEM_DBG patches are supposed to stay for a while, I take it
<iwj> I think the best thing is really just to have this fix in as many places as possible and hope that it deals with "enough" of the bugs.
<iwj> pitti: Uh ?
<pitti> +MODEM_DBG("modem_start.. %d %d\n",__LINE__,ret);
<pitti> stuff like that
<iwj> Gads, I built it from the wrong tree.
<iwj> Sorry.
<iwj> They're harmless but I'll upload an ubuntu4 anyway.
<pitti> there's also some other code changes
<pitti> iwj: nevermind, reuse the version number and I reject this one
<jdstrand> tepsipakki: that definitely looks like my bug
<iwj> pitti: OK, thanks.
<iwj> Sorry!
<tepsipakki> jdstrand: cool
<pitti> iwj: so the only change should be in the init script, not in modem_comp.c (it has functional changes ATM)?
<jdstrand> tepsipakki: and not the one I originally posted to (as I only see it in gnome-terminal, and not the panel)
<jdstrand> tepsipakki: that said, I can't reproduce it atm
<iwj> pitti: No, there are no functional changes in modem_comp.c.  Just the init script.
<iwj> I've made you a new one and debdiffed it myself this time.
<geser> keescook: if you've time, can you sponsor bug #144883 (contains a fix for CVE-2007-5034)?. Thanks
<ubotu> Launchpad bug 144883 in elinks "[Merge]  elinks 0.11.1-1.5ubuntu1" [Undecided,New]  https://launchpad.net/bugs/144883
<ubotu> ELinks before 0.11.3, when sending a POST request for an https URL, appends the body and content headers of the POST request to the CONNECT request in cleartext, which allows remote attackers to sniff sensitive data that would have been protected by TLS.  NOTE: this issue only occurs when a proxy is defined for https. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5034)
<tepsipakki> jdstrand: hmm, don't see the panel mentioned there
<pitti> iwj: ah, much better, thanks; accepting
<jdstrand> geser: this is already in the works
<iwj> pitti: Thanks.
<geser> jdstrand: ok
<jdstrand> geser: I actually gave that patch to debian yesterday, and our update hasn't happened yet because of issues on jackass
<pitti> liw: are you recording your tests in the iso tracker? there are very few for i386 so far
<tepsipakki> bryce_: I'll mark bug 99288 as dupe of 120858, since that already had a dupe
<ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,New]  https://launchpad.net/bugs/99288
<bryce_> tepsipakki: yeah sounds good
<tepsipakki> and it was already marked as a vte bug
<jdstrand> tepsipakki, bryce: 99288 probably is not a duplicate as mdz's screenshots show corruption outside of gnome-terminal
<tepsipakki> jdstrand: where?
<jdstrand> tepsipakki: in gnome-panel.  See Screenshot-1 of his
<tepsipakki> jdstrand: you should open the pic in full size :)
<jdstrand> tepsipakki: I did.  'System' has a red line through it
<tepsipakki> ah
<tepsipakki> that could have been due to something else
<jdstrand> tepsipakki: I did comment in 99288 that my problems were most likely 120858
<jdstrand> tepsipakki: and set the status back to New, as I can't confirm it anymore
* pitti laughs at the typo in https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/144771/comments/7 and hugs mvo
<ubotu> Launchpad bug 144771 in fontconfig "package ttf-opensymbol 1:2.3.0~rc1-1ubuntu2 failed to install/upgrade: " [Undecided,New] 
<pitti> mvo: didn't it crow in the morning? :)
<liw> pitti, I got one image done and reported (gutsy-alternative-i386), that took all day, since I'm a newbie and every step requires learning three other things (and registering for five accounts :)
<pitti> liw: heh, that's fine; scrutiny is appreciated
<pitti> liw: did you see any catastrophes yet?
<pitti> liw: I was lazy and tested them in parallel in vmware; a real-hw test is still outstanding, when I ever manage to be able to get offline for an hour
<liw> pitti, on my test machine, NetworkManager doesn't always choose the right network card (out of two)
<liw> pitti, https://bugs.launchpad.net/ubuntu/+bug/134496 that is
<ubotu> Launchpad bug 134496 in network-manager "After initial reboot, wrong ethernet card is used" [Medium,Incomplete] 
<pitti> liw: ah, that's well below the OMGbetaisdoomed bug threshold :)
<liw> yep
<Treenaks> liw: at least it doesn't die and bring down interfaces on upgrade 8)#
<Treenaks> (but that might have been my own fault..)
<pitti> liw: hm, you have two ethernets with DHCP? wow
<liw> pitti, no, I have two cards in one machine, only one of which is hooked up
<liw> (since the other crashes and burns on big transfers)
<liw> (or did, last year, the driver might have improved)
<pitti> liw: hm, I have two cards as well; seems I urgently need to do a real-hw installation
<pitti> liw: one is internet, one a dangling cable which I commonly use to connect my laptop to
<soren> Is anyone else experiencing trouble with multiple scsi disks in Gutsy in vmware server? It seems to only detect one disk :(
<pitti> dendrobates: any idea who could test server/sparc?
<pitti> dendrobates: and more generally, can the server team do the i386/amd64 server tests?
<dendrobates> pitti: we will handle all the server tests, and are looking for someone to help with sparc.
<pitti> dendrobates: not sure whether we can bribe fabbione again :/
<dendrobates> pitti: I am going to try on my old sparc.
<dendrobates> the kernel team is shipping me a newer sparc, but I don't expect it to arrive in time.
<pitti> yay new toys :)
<dendrobates> pitti: so fabbione and the kernel guys have the most appropriate equipment.
<fabbione> also doko does
<fabbione> he has a T2000 or T1000
<fabbione> pitti: unlikely.. my sparc gear is in production now
<pitti> fabbione: it was worth a try :)
<pitti> I'm off for ~ 10 minutes for some live CD tests on my desktop, brb
<desertc> Hello - I would like to offer this suggestion.  When applying kernel patches, there should be some clean-up of old patches.  I assigned 50 MB for my /boot partition, and this was filled up with the most current software update.  The upgrade did not fail gracefully, either.
<desertc> Regardless of the /boot size, if the kernel upgrades do not clean up after themselves, then they grow without bounds and will fill up any sized space.
<mvo> thanks desertc, we do cleanup of old kernels on system upgrades
<desertc> I guess 50 MB was insufficient for that cleanup process.
<desertc> I had three versions of the kernel in there.  Do you think that is the normal cleanup process?
<desertc> Anyway, when it errored that it was out of space, there was not any way to re-apply the patch, nor did the update manager catch the problem.
<desertc> Thanks for your efforts with Ubuntu, all.
<gnomefreak> bryce_: i updated bug #139726 it looks like i may lose any more data due to testing beta desktop cd so let me know if that is enough info on there
<ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
<bdmurray> mvo: heno pointed me to a CompizFeedback wiki page and there is a 3d app test listed there.  Should a bug when running glxgears be filed about compiz?
<soren> mdz, mjg59, sabdfl: tb meeting, anyone? :)
<mvo> bdmurray: if that fails under compiz but works fine under metacity then yes
<ogra> mjg59, while youre around, and we have bug 144790 around ... do you think it makes sense to enable suspend on the liveCD ? bdmurray suggested that
<ubotu> Launchpad bug 144790 in casper "hibernate and suspend are not disabled on gutsy liveCD" [High,Confirmed]  https://launchpad.net/bugs/144790
<mjg59> Suspend should be fine
<mjg59> In most cases
<mjg59> People with USB CD drives will lose, but, well
<ogra> yeah indeed
<ogra> ok, i'll only disable hibernate then ... my concern was that we didnt explicitly test that
<bryce_> gnomefreak: yeah see if it occurs with the beta cd (I'm guessing it will, but who knows).  Sorry I can't give more useful troubleshooting directions; I don't have a good understanding of gdm internals so am not sure why it's selecting a different resolution from X
<pitti> MacSlow, mvo: ah, I just noticed a small regression in the appearance applet: it defaults to 'normal' even when metacity is running (because the video driver does not support composite)
<mjg59> bryce_: gdm does nothing to set the resolution, to the best of my knowledge
<ogra> meh
<ogra> vbox doesnt like alternate today :/
<pitti> MacSlow, mvo: changing it to ZOMGmoreeffects doesn't do anything, and changing to 'off' and back looks weird
<mjg59> bryce_: The session itself may have a resolution set
<bryce_> mjg59: does gdm use the xorg.conf to get the resolution?  I've noticed it often ends up with different settings from what's in the xorg.conf
<pitti> MacSlow, mvo: is this known and in the works already, or do you want a bug report?
<mjg59> bryce_: I don't understand the question
<mjg59> bryce_: gdm is just an X client
<seb128> bryce_: gdm only starts a x server
<gnomefreak> bryce_: ok ill try it, me and seb128 went over this trying older versions of gdm and it worked the same way thats what made me think X for most part. but i will test beta now and let you know when i get back on (or wait and see what is coming of this topic first
<mvo> pitti: I'm not aware of this, so a bugreport is appreciated
<bryce_> mjg59: what determines what driver and resolution it uses in that case?
<mvo> pitti: please also milestone it
<mjg59> Well, it's also something that starts X, but it doesn't pass any configuration to it
<MacSlow> pitti, hm... better file a bug and assign it to me
<mjg59> bryce_: xorg.conf
<pitti> MacSlow: alright, doing
<bryce_> gnomefreak: ok
<MacSlow> mvo, we'll get back to the explicit plugin-list I bet :)
<gnomefreak> xorg is default other than using restricted/manager to enable nvidia other than that the monitor buttons is what caused this
<MacSlow> mvo, I'll look into that tomorrow
<gnomefreak> anyway ill be back my xorg.conf is attached to bug report along with a bunch of other things. see you tonight
<MacSlow> still working on the wnck-applet properties-dialog for the compiz-case
<bryce_> gnomefreak: great, good luck
<gnomefreak> back up first :)
<mvo> MacSlow: what would be explicit plugin list have to do with that?
<MacSlow> not that alone
<pitti> MacSlow: done, bug 144913; thank you
<ubotu> Launchpad bug 144913 in gnome-control-center "defaults to 'normal effects' even when the driver does not support compositing" [Medium,New]  https://launchpad.net/bugs/144913
<pitti> iwj, Riddell: new sl-modem/pykdeext will be available in ~ 5 minutes; can you give this a quick test before I start building new KDE CDs?
<bdmurray> mvo: I submitted a bug about what I saw when running glxgears
<mvo> bdmurray: what bugnumber?
<bdmurray> bug 144914
<ubotu> Launchpad bug 144914 in compiz "putting glxgears below another window when running compiz looks funny" [Undecided,New]  https://launchpad.net/bugs/144914
<mvo> bdmurray: right, that is a sort-of known issue, very hard to fix with the current drivers
<pitti> Riddell, iwj: there now
<pitti> Riddell: libpythonize0 looks good at least
* pitti creates new CDs
<pitti> ^ (Kubuntu only)
<gnomefreak> bryce_: would not having hoz and vert. refresh rates in xorg.conf cause my issue when changing screen from monitor buttons? i noticed xorg doesnt put them there anymore (atleast i thought it did at one time)
<bryce_> no it shouldn't matter
<mjg59> bryce_: No
<mjg59> Erm.
<gnomefreak> k
<mjg59> gnomefreak: No
<gnomefreak> passing thought figured id ask
<slangasek> pitti: ETA on those Kubuntu CDs then? (waiting to be able to file a proper test report)
<bdmurray> mvo: what is the issue?
<mvo> bdmurray: basicly its a driver issue
<mvo> bdmurray: direct rending draws directly to the font buffer and compiz does not know about this
<slangasek> jamiemcc, seb128: bug #130935 is milestoned and "in progress", but unassigned; are either of you working on this bug?
<ubotu> Launchpad bug 130935 in tracker "Tracker takes very long time to index system, provides no obvious status information" [High,In progress]  https://launchpad.net/bugs/130935
<jamiemcc> slangasek: I am
<slangasek> jamiemcc: great, shall I assign it to you?
<jamiemcc> yes pls
<slangasek> thx
<ogra> pitti, did you test an alternate install in vbox ? do you get a resolution question there ?
<ogra> i get it reproducable here but would really prefer it to be a virtualbox issue :)
<pitti> ogra: yes
<ogra> phew
<pitti> ogra: erm, not in vbox, in vmware
<pitti> ogra: I also get that when I install on my real system
<ogra> oh, thats bad
<rohan> crimsun: ping, are you around ?
<mathiaz> pedro_: are you testing the ubuntu-server i386 iso ?
<pitti> ogra: X's package detection scripts don't detect my monitor resolution
<ogra> that should be autodetected
<pitti> ogra: X itself does, though
<pitti> ogra: that has always been like this, though
<pedro_> mathiaz: yep doing it right now
<rohan> crimsun: i remember you had once given me instructions on how to compile snd_hda_intel using code from hg repo of alsa. can you please give me those instructions once again ?
<pitti> ogra: not necessary to give an answer, btw, just leave it empty
<mathiaz> pedro_: ok. I'm doing the lvm test case right now.
<bryce_> pitti, is this the same bug seb128 is seeing?
<mathiaz> pedro_: can you test amd64 ?
<ogra> pitti, well, its a question ...
<pitti> bryce_: not sure?
<bryce_> pitti, we tracked his down to xserver 12ubuntu3
<ogra> we should preseed it then
<seb128> bryce_: 12ubuntu4 rather ;)
<pitti> ogra: *shrug* only on alternate and only if the package scripts fail
<bryce_> oops, right
<rohan> jdong: ping, did you find any updates on that resolution bug ?
<pedro_> mathiaz: no sorry, i don't have an amd64 machine :-(
<mathiaz> pedro_: ok.
<pitti> bryce_: what I see (if you want to call it 'bug') exists since hoary or so
<rohan> jdong: where the latest cd was not able to detect 1280x800 and instead defaulted to 1024x768 ?
<bryce_> pitti, if it's been mis-detecting since before tribe5, then it's a separate bug
<mathiaz> pedro_: I'm gonna add some more test for the new tasks we've added.
<jdong> rohan: I haven't had a chance to do much but confirm that bug
<bryce_> pitti: ah
<mathiaz> pedro_: could you test installing a print server ?
<rohan> jdong: oh, it's been filed on launchpad ?
<pedro_> mathiaz: sure, just give me the test case
<pitti> bryce_: NB that X itself detects it fine, just the Debian scripts fail
<jdong> rohan: I am unsure, but enough developers have heard us talk about it, and seb128 even experiences the bug
<bryce_> pitti: ok
<pitti> bryce_: (one day those should all disappear and be replaced with something small and sensible...) :)
<rohan> jdong: ah ok, so no need to report it ;)
<bryce_> pitti, plan is that those scripts are going to get gutted and replaced, probably by hardy
<mathiaz> pedro_: https://wiki.ubuntu.com/Testing/Cases/ServerInstall#print-server
<pedro_> mathiaz: already saw it in the wiki
<pedro_> jeje yep
<bryce_> pitti: I'd been planning on doing that myself, however tepsipakki says debian is also planning on similar, so probably instead I'll just lend a hand (or cheers) to debian
<pitti> bryce_: yay; they were great in warty and hoary to get auto-X-config working in the first place, but I guess they are horribly obsolete with today's X
<mathiaz> pedro_: yeah.. I've just added it.
<mathiaz> pedro_: but it's not in the qa tracker yet.
<bryce_> pitti: yeah there's a lot of logic in them which looks like it'd get dated quick.  lots of heuristics and hardware-specific guessing
<jdong> rohan: woudl be nice to search on lp package xresprobe for the bug, if it isn't there (doubt it!) report it
<bryce_> pitti, for Gutsy, the solution to focus on is being able to fix it post-install via Screens and Graphics
<rohan> jdong: ok, i'll do that when possible
<pitti> bryce_: right, and this should be kept in any case
<pitti> calc: good morning
<calc> pitti: hi, just rebooted my box hoping vmware would start working, still doesn't :\
<pitti> calc: oh? works fine here
<calc> its giving me an error that supposedly means libXrender isn't installed... but it is :\
<calc> http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1979&sliceId=2&docTypeID=DT_KB_1_1&dialogID=23132511&stateId=0%200%2023130478
<calc> i went ahead and even installed all the ubuntu versions of any library it used that it was using a private copy of which still didn't help :\
<pitti> calc: hm, wait -- do you use compiz?
<pitti> calc: maybe it's missing in ia32-libs?
<pitti> hm, weird
<calc> not that i know of
* calc could go verify he has compiz turned off
<pitti> ogra: how do things look so far?
<calc> yea compiz appears to be disabled
<calc> it is set to "no effects"
<ogra> my vbox crashed several times with the server install
<ogra> this one seems to get throught though, i'm at 82% in pkgsel
<ogra> (the worst part (ltsp) still to come though)
<stgraber> `23meg: ping
<`23meg> pong
<`23meg> stgraber, pong
<stgraber> You tried to register to the Ubuntu QA Tracker with an invalid mail
<stgraber> can you give me one so I forward the activation mail
<`23meg> hmm, I registered with my ubuntu.com address
<stgraber> <muratgunes@ubuntu.com>: host mx.canonical.com[91.189.94.145]  said: 550 <muratgunes@ubuntu.com>: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command)
<`23meg> ah, sorry; mgunes@ubuntu.com please
<`23meg> stgraber, are accounts from the old tracker no longer active?
<stgraber> `23meg: the ones from isotesting.stgraber.org are, the ones from www.stgraber.org/ubuntu aren't
<`23meg> I see; mine was on the latter
<smallfoot-> What is Ubuntu doing to prevent the problem of license profileration?
<sistpoty> smallfoot-: what do you meant with license profileration?
<smallfoot-> http://en.wikipedia.org/wiki/License_proliferation
<smallfoot-> oh, i meant proliferation not profileration
<smallfoot-> it makes it harder to re-use source code, harder to integrate software, harder to borrow source code, etc
* sistpoty looks
<smallfoot-> Mark Shuttleworth has also spoken about the problem of license proliferation on this blog -- http://www.markshuttleworth.com/archives/67
<pedro_> mathiaz: just tested (print server case) it works fine
<mathiaz> pedro_: great ! thanks.
<pedro_> mathiaz: i'll go for the LVM now
<mathiaz> pedro_: I'm currently adding new test cases for the tasks we've added to the ubuntu-server cd.
<mathiaz> pedro_: are you using vmware ?
<pedro_> mathiaz: nop, a spare machine i have
<mathiaz> pedro_: hum... When it comes to LVM, there is a small bug that the installer won't wipe the LVM physical extent.
<mathiaz> pedro_: so the second time you try to install an LVM partition, the installer will complain that it already has LVM PE.
<pedro_> mathiaz: ok will remember that
<sistpoty> smallfoot-: ubuntu doesn't in the first place, though when packaging new software we always try to convince upstream to change the license statement in order to not suffer from proliferation
<smallfoot-> sistpoty, oh thanks... thats awesome, great work guys, i wish the other distros would do the same
<sistpoty> smallfoot-: I guess many are (e.g. debian and its debian free software guidelines)
<slangasek> sistpoty: I rather doubt that's accurate on the whole, I expect that most Ubuntu packagers only look at whether the license is ok for universe rather than whether it's a common license?
<sistpoty> slangasek: that may be true, but I try my best to encourage aforementioned behaviour
<ScottK> My favorite license I've hit recently is "If you think you need a license for anything you might think of this as beeing unter a "BSD Style License"
<smallfoot-> unfortunately, we have Apache, Perl, Berkeley DB, LaTeX, GNAT, Vim, zlib, xinetd, OpenLDAP, OpenSSL, PHP, Python, Ruby, libwww, Zope who all have custom licenses :(
<ScottK> That's the "license" for python-ipy.
<sistpoty> smallfoot-: well, I guess that won't go away too soon, and (considering ion3, or rather more majors putting stuff under their own OSS licenses) that won't go away too soon
<sistpoty> yay, bad sentence... and this might get worse I wanted to add
<smallfoot-> :(
<smallfoot-> hope it dont get worse
<sistpoty> smallfoot-: /me neither... even worse is if you know some piece of SW got relicensed later as LGPL, but you're bound to some non-commercial license because you forked earlier. /me is still trying to figure whom to contact, since most email addresses from our version aren't valid any longer
<smallfoot-> oh
<smallfoot-> maybe should refuse to ship Ubuntu with software that has custom licenses
<smallfoot-> or have a delay before new releases of software is put into the repository as punishment
<sistpoty> (our as in university project, nothing directly to do with ubuntu -- yet)
<ScottK> smallfoot-: Who does that really punish?
<smallfoot-> ScottK, it makes software with custom license become second-tier, worth less, less prioritized
* ScottK sees that as along the lines of, "If you don't do what I want, I'll shoot myself in the head."
<smallfoot-> lol
<smallfoot-> well, true kinda
<ScottK> To which the standard response is, "Go ahead, make my day."
<smallfoot-> hehe
<pochu> seb128: tracker 0.6.3 is out, which fixes a ton of bugs (some of them critical and tagged for gutsy-beta). Is it ok if I do package it, providing you haven't done it yet?
<seb128> pochu: I didn't do the update yet, you are welcome to work on it
<pochu> seb128: cool :) will you be able to review/sponsor it?
<seb128> pochu: yes
<seb128> pochu: tomorrow likely, the archive is frozen for beta anyway
<pochu> great!
<pochu> seb128: yeah I know
<seb128> pochu: don't enable the thunderbird experimental indexer
<seb128> just in case you wanted to do the change ;)
<pochu> I'd love to, but I guess it's not ready :(
<seb128> pochu: right
<jamiemcc> pochuL it aint called experimental for nothing :)
<pochu> jamiemcc: hehe, true that
<gnomefreak> bryce: looks like X detected everything correct so i dont need to use monitor buttons nor change resolution i guess this bug is fixed ty :)
<bryce_> awesome
<gnomefreak> cjwatson: was i supposed to see cryptset(or whatever it is that D-I uses to encrypt for install (sorry im drawing a blank)
<bryce_> gnomefreak: if you can mention that you're no longer seeing the issue on bug 139726, I'll go ahead and close it
<ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
<gnomefreak> i am atm
<gnomefreak> bryce_: i closed both tasks with explaintions
<bryce_> excellent, thanks
<gnomefreak> np thanks for your help on it
<mjg59> MacSlow: I enabled desktop effects, they failed to enable because I'm on 965, but my workspace configuration has changed anyway
<cjwatson> gnomefreak: it was taken back out again for beta, too many problems
<gnomefreak> cjwatson: ah ok
<gnomefreak> cjwatson: only other question is why are all repos enabled except the canonical ones? the cdrom repo is enabled along with the ubuntu.com repos (was this always this way and i forgot)
<cjwatson> gnomefreak: because something went wrong in your installation such as the network not being enabled
<cjwatson> or not being able to talk to the archive
<gnomefreak> ah ok
<cjwatson> you can safely uncomment them
<gnomefreak> cjwatson: i commented out the cdrom, the canonical repos are not working atm
<cjwatson> it's not switched on yet, should be for gutsy
<cjwatson> (expected)
<gnomefreak> cjwatson: yeah thats what ive been telling users complaining that it doesnt work i tell them wait till release
<cjwatson> seems a rather odd thing to complain about
<ogra> cjwatson, i uploaded a new edubuntu-meta, could you let that throuhg please ?
<cjwatson> ogra: slangasek/pitti's call
<gnomefreak> cjwatson: they want all those extras that we cant legally ship i guess
<ogra> slangasek, ping ^^^ ?
<cjwatson> gnomefreak: the partner repository is not a repository for illegal distribution
<cjwatson> so please pick a better word than "legally" there
<ogra> cjwatson, i didnt know steve drives the publisher already
<gnomefreak> what is it? i thought it was the non-free stuff like opera
<cjwatson> ogra: he doesn't, but it's his decision, I'd just need to implement it
<ogra> ah
<cjwatson> gnomefreak: if opera is in the commercial (now renamed to partner) repository (I don't remember whether it is or not), it would be because Canonical had a commercial relationship with Opera in which they asked us to ship it
<cjwatson> gnomefreak: so it would in no way be illegal
<gnomefreak> ah ok
<gnomefreak> yeah iirc it was in the commercial repo
<cjwatson> gnomefreak: it probably wouldn't conform to Ubuntu's licensing policies, which is why it's in the canonical.com namespace not ubuntu.com, but that's very different
<gnomefreak> ok yeah my wording was very wrong on that
<slangasek> ogra: this is a change to try to get the CD size down?
<ogra> slangasek, nope, moving moodle out of the default install into ship ... it's still missing d-i integration (mainly presseding but proably even more) it was a laet addition and i discovered its not ready for default
<ogra> *late
<slangasek> ok
<ogra> thanks :)
<slangasek> but it still requires an edubuntu CD rebuild for it to be reflected in the beta, yes?
<ogra> yep
<ogra> i'll do that tomorrow morning
<slangasek> ok
<slangasek> accepted, I think
<ogra> cjwatson, would you flip the switch please ?
<slangasek> I think I just did that
<ogra> oh
<ogra> great :)
<ogra> thanks :)
<slangasek> cjwatson: website-based accept seems to have worked this time
<cjwatson> so it did
<cjwatson> ok, let's hope it was just transient badness yesterday
<pwnguin> Is there a written ubuntu udev policy I can look at?
<pwnguin> because it seems different than debian's
<cjwatson> pwnguin: /etc/udev/rules.d/README is the closest I'm aware of
<pwnguin> heh
<pwnguin> thats... insufficient
<pwnguin> reading that, you might think you can ship udev rules in a package
<cjwatson> and yet it describes the main differences from Debian
<cjwatson> of course you can and many do
<ogra> according to Keybuk we use the upstream policy (at least thats waht he always says)
<cjwatson> $ dpkg -L pcmciautils | grep udev/rules.d/
<cjwatson> /etc/udev/rules.d/85-pcmcia.rules
<cjwatson> for example
<RAOF> Upstream policy appears to be "udev rules are in the udev package, unless they're just RUN rules"
<pwnguin> and even then, I'd appreciate guidance on security implications
<ogra> mode 0660 and group kvm should be safe enough, no ?
<RAOF> Yes.
<ogra> i think thats whats mentioned in the bug
<RAOF> That's right, and that's what the previous behaviour was.
<ogra> right
<ogra> the change likely came in with a debian merge
<ogra> simple oversight
#ubuntu-devel 2007-09-26
<slangasek> anyone interested in taking bug #136534? I've just added some analysis of the failure to the bug log
<ubotu> Launchpad bug 136534 in keepalived "autopkgtest gutsy keepalived: erroneous package!" [High,Confirmed]  https://launchpad.net/bugs/136534
<alex-weej> is there any chance of https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/145004 getting in for gutsy or is it too late now?
<ubotu> Launchpad bug 145004 in ubuntulooks "Implement GtkExpander styling (Code, Screenshot)" [Undecided,New] 
<bigon> damm ekiga crashes (see bug #145006)
<ubotu> Launchpad bug 145006 in ekiga "ekiga: symbol lookup error: /usr/lib/libopal.so.2.2: undefined symbol: _ZN11PSafeObjectC2Ev" [High,New]  https://launchpad.net/bugs/145006
<slangasek> alex-weej: the UI is supposed to be frozen at this point; at minimum it would need a freeze exception, and the prereqs for that would seem to be sign-off by the doc team and the
<slangasek> ... and the desktop team
<alex-weej> ah ok
<terlmann> is this where packaging maintainers are ?
<MacSlow> mjg59, oh... noted will be fixed
<mjg59> No problem
<MacSlow> mjg59, and thanks for the heads up
<RAOF> I'm looking at bug #127704, and I'd just like to check that dh_installudev is safe to use in Ubuntu - Debian bug #414331 suggests that it isn't in Debian at least.
<ubotu> Launchpad bug 127704 in kvm "kvm: access to /dev/kvm should have a different group-ownership" [Low,In progress]  https://launchpad.net/bugs/127704
<ubotu> Debian bug 414331 in kvm "must not install udev rules files" [Normal,Fixed]  http://bugs.debian.org/414331
<MacSlow> mjg59, btw filed a bug on that already?
<mjg59> MacSlow: Nope
<MacSlow> mjg59, ok I'll do that then
<mjg59> Thanks!
<MacSlow> mjg59, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/145020
<ubotu> Launchpad bug 145020 in gnome-control-center "failed visual/desktop effects still change workspace layout " [Undecided,Confirmed] 
<MacSlow> mjg59, should I (or would you like) add you as the inital reporter?
<mjg59> MacSlow: Sure, thanks
<bddebian> Heya
<RAOF> bddebian: Hey.
<RAOF> bddebian: You're a udev god, right? :P
<bddebian> Heya RAOF
<bddebian> No, I'm pretty much an idiot about everything
<RAOF> :)
<RAOF> Eh, not yet an hour.  Probably too early to reping the udev question
<bddebian> What's the question?
<RAOF> Whether dh_installudev is safe on ubuntu.
<bddebian> What would make it not safe?
<RAOF> I'm looking at bug #127704, and I'd just like to check that dh_installudev is safe to use in Ubuntu - Debian bug #414331 suggests that it isn't in Debian at least.
<ubotu> Launchpad bug 127704 in kvm "kvm: access to /dev/kvm should have a different group-ownership" [Low,In progress]  https://launchpad.net/bugs/127704
<ubotu> Debian bug 414331 in kvm "must not install udev rules files" [Normal,Fixed]  http://bugs.debian.org/414331
<RAOF> "dh_installudev is badly broken"
<bddebian> Ah, hrm
<pwnguin> heh
<bddebian> Dunno, sorry
<pwnguin> i just went shopping, and that's still going on?
<RAOF> pwnguin: Not so much going on, as a slightly different question that hasn't been answered.
<pwnguin> what was the answer to the question about keybuk's comment?
<pwnguin> do packages provide permissions or does udev?
<RAOF> Yes, other packages provide it.
<pwnguin> unfortunately, im not sure about what permissions to set. world readable would be easier than setting up a group
<RAOF> pwnguin: There are a bunch of groups already set up, and if you want an example of creating a new one, kvm is one such :)
<pwnguin> fuse seems like another
<RAOF> Yup.
<pwnguin> thats the one i was working from, and it uses dh_installudev
<pwnguin> err
<pwnguin> no it doesnt. someone else in motu told me to use installudev
<pwnguin> instead of plain "install"
<RAOF> pcmciautils also doesn't use dh_installudev
<RAOF> And dmsetup *does* use it, and is in main.
<pwnguin> I think all you've proven is that nobody's thought about it recently
<RAOF> That's entirely possible.  However, the fact that a main package uses it makes me more confident it's not utterly broken.
<bddebian> Well there's your first mistake ;-)
<pwnguin> dmsetup?
<RAOF> Hm.  Of all the packages that own files in /etc/udev/rules.d, watcom-tools, lvm2, and devmapper are the only packages using installudev
<pwnguin> well, if debian's decided not to use installudev, then it's not like anyone's gonna go and put it back in
<RAOF> But it may be useful in for us, since we seem to have a different udev policy.
<pwnguin> amusingly
<pwnguin> theres a bug in evms about it's udev rules not running
<pwnguin> is there a written description of the meaning of various unix groups anywhere?
<pwnguin> (in ubuntu)
<mpt> pwnguin, what do you mean by "unix groups"?
<pwnguin> like, fuse, wheel
<pwnguin> admin
<pwnguin> plugdev
<pwnguin> /etc/groups
<mpt> ah
<pwnguin> not lugs
<mpt> pwnguin, you could report a bug at https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs that it should be explained in the help
<pwnguin> so the answer's no
<pwnguin> ok
<pwnguin> i looked through debian-policy and didnt come up with anything
<calc> wow, i didn't really know the history caldera until reading its wikipedia entry, they were impressive before they became psychotic
<asisak> they were creating Caldera DOS that was beer-free and quite good, esp. compared to the MS hell
<asisak> IIRC
<calc> they did a whole lot more than that according to the article founded blackdown, LPI, etc
<asisak> Sure, it was the only thing I knew :)
<calc> :)
<pitti> Good morning
<Hobbsee> pitti!
<ajmitch> hey pitti
<asisak> Good morning pitti, $TIME_OF_DAY ajmitch, Hobbsee
<calc> pitti: good morning
<soren> Good morning, everyone!
<calc> good morning
* calc is still testing beta cd, so hasn't gone to bed yet
* keescook waves "hi" to everyone before heading to bed
<ajmitch> hi & bye, keescook :)
<Hobbsee> hi keescook!
<keescook> say, is the method that firefox and the kernel packages use to trigger the "you need to Xyz" update-notifier stuff documented anywhere, or is this a case of me needing to go code-dive their postinsts?
<StevenK> Morning pitti
<keescook> hiya ajmitch, Hobbsee.  :)
<ajmitch> check out the postinsts, it's fairly basic iirc
<RAOF> Yeah.  It's "copy a file which looks similar to a .desktop file to /var/lib/update-notifier/user.d, IIRC
<pitti> hey keescook
<keescook> ajmitch, RAOF: ah, yeah.  /usr/share/firefox/firefox-restart-required.update-notifier
<keescook> hi pitit!
<keescook> er
<keescook> pitti!  :)
<RAOF> Is anyone here running the fglrx drivers?  Could you contribute the output of glxinfo to help make xgl's acceleration detection better?
<superm1> after beta is released later this week the archive goes back into automatic mode for a bit right?
<superm1> RAOF, sure, but i'm not running an official release of fglrx
<superm1> if that's ok
<RAOF> That's fine.
<RAOF> I just want to see which GL extensions it advertises.
<superm1> RAOF, here you go: http://paste.ubuntu-nl.org/38614/
<Mithrandir> superm1: yes, it will be put on auto again.
<superm1> Mithrandir, okay cool thanks
<RAOF> superm1: Damnit.  That's a modern card/driver combination, right?  As such, it should be capable of pbuffers?
<superm1> RAOF, well depends on your definition of modern.  It's a 2-3 year old card.  It's around the 8.41 series of drivers
<superm1> it should be capable of pbuffers though yes
<RAOF> So why doesn't it advertise that fact? :(
<calc> looks like is based on rv350 (if i remember my numbering right?)
<superm1> RAOF, its possible pbuffers are broken in this driver
<sladen> RAOF: btw, one thing that bugs me about the attempt at GL acceleration detection is of the software trying to be too cleve
<superm1> RAOF, because the 'official' release of 8.41 has a lot broken on my card
* calc scares himself for remembering that
<RAOF> Right.  Interestingly, it advertises fbo's
<RAOF> sladen: Basically, I want to know: (1) does it support pbuffers? (2) does it support fbos.  I can make the detection user-overridable, if that mollifies you :)
<sladen> RAOF: too clever---IMHO software should always work (if the right primitives are;  the user can choose if they like that or not)---though I /do/ agree with auto-detection for automatic enabling on install
<sladen> RAOF: yeah, it bugs me the way all the window borders disappear, and /then/ it says "no, can't do"
<RAOF> sladen: Oh, it works.  I'm just trying to hunt down why it's dog slow.
<sladen> RAOF: if it's going to back out, could that be done before killing the existing window manager;  and/or just even show the enable button if it is fact going to back out
<RAOF> sladen: You're thinking of Compiz, not Xgl, and we already do that.
<RAOF> sladen: Unless compiz *crashes*, and it's a bit difficult to tell that beforehand :)
<sladen> RAOF: ouch, is that the abort mechanism, see if it crashes...
<sladen> RAOF: I have an ATI laptop at work, I'll try when I get there.  poke me in an hour
<RAOF> sladen: No, we do a whole bunch of tests first.  If it passes those, then compiz *should* work.  But if it crashes, it crashes back to metacity.
<RAOF> sladen: Thanks.
<soren> Anyone else using VMWare server? Could you try adding more than one scsi hard drive and try booting a recent gutsy CD and see if it detects more than the first disk?
<pitti> soren: I could try it on vmware ws
<stgraber> morning
<soren> pitti: That could work, too.
<pitti> soren: ah, let me install vmware; I reinstalled my desktop last night :)
<soren> pitti: Any particular reason why you're using ws?
<pitti> soren: we have licenses, and well, it was just the most logical pick from their website
<soren> pitti: server is free (as in beer, of course).
<pitti> soren: what's the key difference?
<soren> pitti: WS has a few features that server doesn't yet, but the killer feature for server (for me, anyway) is that you can deetach from the server instance and the vm's keep on running.
<soren> ...and you can connect to it remotely.
<pitti> soren: right, like on -- a server :)
<soren> :)
<soren> WS is better for testing multi-machine setups.
<kagou> Good morning
<soren> ..since you can more easily create these shared virtual networks between your vm's. This is not quite as easy in server.
<pitti> yeah, those are really cool for testing edubuntu, etc.
<soren> Right.
<pitti> soren: confirmed, second scsi disk is not detected
<soren> "great", thanks.
<pitti> soren: hm, that's bad, isn't it?
<pitti> soren: anyway, ubuntu does not have a problem with detecting my two IDE disks
<soren> pitti: No, it works fine in Feisty, too.
<soren> pitti: Yes, it's a bit bad :)
<pitti> but I hope that vmware bug doesn't imply that it is true for all scsi disks
<soren> pitti: You wouldn't happen to have a physical box with an lsilogic controller in it, would you? :)
<pitti> nope
<pitti> soren: my hardware is ancient in that regard: just plain IDE disks everywhere
<soren> Ah, already reported:
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/140761
<ubotu> Launchpad bug 140761 in linux-source-2.6.22 "Ubuntu 7.10 Alpha Gust OS does not recognize a lun with non zero target id on Vmware ESX Server" [Undecided,Incomplete] 
<StevenK> pitti: No SATA at all?
<pitti> StevenK: no, both my boxes are about 3 years old
<pitti> StevenK: however, new Dell Latitude is ordered now, so this might have :)
<StevenK> Heh
<pitti> (not that I'm particularly interested in it - it has to have a damn working HD, that's all)
<soren> Yeah. I feel that way about most hardware, actually.  I like it fast, though.
<pitti> lightweight, long-running, good display, sane keyboard, working guts, that's my laptop :)
<pitti> anyway, no catastrophes so far, what's wrong?
<stgraber> working suspend to ram is also one of the things I want my laptops to have
<pitti> stgraber: right
<stgraber> do we have new Edubuntu server ISOs ?
<pitti> stgraber: noone told/mailed me about why they were disabled
<pitti> and what to do to get new ones
<pitti> and neither ogra nor LaserJock are online
<pitti> slangasek doesn't seem to know either
<stgraber> I disabled them yesterday as they didn't install due to moodle
<pitti> why do we have a 24/7 release team available if noone tells them??
<pitti> stgraber: ah, just dropping moodle? ok
<stgraber> ogra or Laserjock should have uploaded a new meta I think
<pitti> stgraber: a new serveraddon-meta
<torkel> 0016 (slangasek) but it still requires an edubuntu CD rebuild for it to be reflected in the beta, yes?
<pitti> stgraber: but I didn't accept it since this looks a bit fishy
<torkel> 0017 (ogra) yep
<torkel> 0017 (ogra) i'll do that tomorrow morning
<pitti> stgraber: they added lots of new apps, but the CD is almost full
<torkel> sometimes it is good to keep a long scrollback :-)
<pitti> torkel: thanks
<pitti> stgraber: anyway, moodle appears in component-mismatches, so it's unseeded now
<pitti> stgraber: I guess it was only in ship
* pitti looks
<pitti> message:
<pitti>   move moodle to ship until it has better d-i inetgration and a proper preseed file
<slangasek> yep
<pitti> https://edge.launchpad.net/ubuntu/+source/edubuntu-meta/1.46 ah, cool
<pitti> stgraber: ok, so only thing for me to do is trigger new images, it seems
<stgraber> Do you think we'll have bug 134918 and bug 144956 for beta ?
<ubotu> Launchpad bug 134918 in restricted-manager "Misleading error message - software source for package is not enabled" [High,Confirmed]  https://launchpad.net/bugs/134918
<ubotu> Launchpad bug 144956 in xorg-server "incorrect screen resolution on gutsy beta using intel" [High,In progress]  https://launchpad.net/bugs/144956
<pitti> stgraber: yes, we will have them in beta :)
<pitti> stgraber: (i. e. no time to fix them and roll new CDs)
<pitti> stgraber: I'll fix the two r-m bugs right after beta, though
<stgraber> ok :(
<Hobbsee> ergh.  when does edgy EOL?
<Hobbsee> oh, must be another 6 months or something.
<fabbione> Hobbsee: when hardy is out
<fabbione> this release no EOL :)
<fabbione> power of LTS ;)
<Hobbsee> fabbione: damn.
<Hobbsee> kdebase has too many bugs.
<stgraber> Hobbsee: some bugs you don't want to fix ? :)
<Hobbsee> stgraber: most are likely outdated
<Hobbsee> stgraber: and by now, most of them wont be fixed, due to kde4.
<pitti> hello slomo, good morning
<slangasek> soren: hi, what are the neat new server features in 7.10 that should be emphasized in the beta announcement?
<fabbione> slangasek: that it might actually work :P
* pitti slaps fabbione 
<StevenK> I should make DKMS work for virtualbox
<slangasek> fabbione: you can't fool me, I've met the kernel team
<fabbione> slangasek: which kernel team?
<slangasek> fabbione: yes
<fabbione> slangasek: whatever..
* fabbione calls principessa ..
<slangasek> at midnight? tsk
<dholbach> good morning
<Hobbsee> morning dholbach
<dholbach> hey slangasek
<fabbione> slangasek: i can be very charming :P
<dholbach> hey Hobbsee
<slangasek> dholbach: hiya
<dholbach> how's it going?
<soren> slangasek: Um... I think there's a list of stuff we usually brag about somewhere.
<slangasek> dholbach: I'm up way past my bedtime, how are you? :)
<dholbach> slangasek: very good, had breakfast in the sun and am just about to dive into heaps of mails I got over the night :)
<pitti> stgraber: new edubuntu server CDs up
<pitti> slangasek: ^ FYI
<stgraber> pitti: got the e-mail notification, davmor2 will test them
<pitti> cool
<stgraber> I'm doing xubuntu alternate i386 and edubuntu desktop i386 at the moment
<pitti> https://iso.qa.stgraber.org/qatracker/build/All looks a bit like space invaders...
<stgraber> :)
<moyogo> hi
<moyogo> there are many keyboard layouts that are missing or arent in sync with whats on freedesktop.org
<moyogo> could xkeyboard-config be updated?
<moyogo> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/135509
<ubotu> Launchpad bug 135509 in xkeyboard-config "update xkb-data to include latest keyboard layouts" [Undecided,New] 
<stgraber> pitti: any idea why we're still having unionfs issue with Edubuntu desktop ?
<pitti> stgraber: I saw a non-reproducible hang on ubuntu yesterday, too
<pitti> stgraber: seems like not all bugs are fixed yet
<pitti> hey seb128
<pitti> seb128: did you see jamie's tracker mail? I am fine with updating and testing the package today (not for beta, of course), unless you want to?
<pitti> seb128: but I guess you have tons of other release-candidate bugs on your plate
<stgraber> pitti: I'll reboot and retry but that's weird because the two testers of both Edubuntu desktop i386 and amd64 have reported the bug (bdmurray and me)
<seb128> hello pitti
<stgraber> but l-u-m is .32 so we should have the fix :(
<seb128> pitti: pochu is working on the update already
<pitti> seb128: ah, nice
<stgraber> pitti: second try didn't help (it crashed at partitioning this time)
<pitti> stgraber: uh, bad
<pitti> stgraber: "the fix" -> I saw lots of different kind of unionfs crashes
<carlos> pitti: who should I contact about apparmor package management?
<pitti> carlos: keescook and mathiaz
<carlos> pitti: ok, thanks
<carlos> keescook: ping
<pitti> carlos: (he went to bed an hour ago)
<carlos> oh, ok
<carlos> I'm a bit confused with the list of po files included in that package so I just wanted some input from him
<seb128> carlos, pitti: are we getting a language pack update today?
<pitti> carlos: ah, did the export succeed?
<carlos> seb128: no, we had a problem with the production server and broke the export
<carlos> and we didn't have time to prepare a new one
<seb128> carlos: any estimation of the delay to get one?
<carlos> pitti: it's being quite slow on production, so it's still in progress...
<pitti> carlos: oh, the one from last night failed,  too?
<carlos> seb128: we are preparing one for tomorrow
<pitti> ah, still ongoing, I see
<carlos> right
* seb128 wonders if we will get an Ubuntu cycle without blocking on rosetta
<carlos> seb128: well, in first place, there was no planned language pack update for the beta release... i asked pitti to do it
<seb128> carlos: I though we were supposed to have weekly updates this cycle?
<pitti> good morning ogra
<pitti> seb128: we had semiweekly ones in fact
<carlos> seb128: yeah, but that was stopped due to problems with PPA changes
<carlos> and as pitti just said, move to semiweekly ones
<seb128> just stopped before 2.20.0
<pitti> no, the updates were uploaded straight into gutsy on Wednesdays and Sundays
<seb128> which makes that we sucks again for upstream guys
<seb128> they can't test their translations on Ubuntu
<pitti> yeah, the 'current' symlink was not updated, and we didn't notice for a while
<carlos> also, we recently moved to production, so the exports must be more reliable
<carlos> and not depending on a mirror anymore
<dholbach> pitti: is it ok if I assign bug 134712 to you? you replied on it already
<ubotu> Launchpad bug 134712 in gparted "gparted didn't exit cleanly, no automount anymore" [High,Confirmed]  https://launchpad.net/bugs/134712
<carlos> seb128: btw, I just found this while approving pending templates for Gutsy https://bugs.edge.launchpad.net/ubuntu/+source/fast-user-switch-applet/+bug/139793
<ubotu> Launchpad bug 139793 in fast-user-switch-applet "fast-user-switch-applet does not contain any translations" [Undecided,Confirmed] 
* carlos wants longer days  to get some time to produce a report with all packages with that problem...
<pitti> dholbach: yes, absolutely
<seb128> carlos: I'll fix it, but ideally rosetta should automatically file bugs about that
<pitti> dholbach: done
<carlos> seb128: see what I just said
<pitti> dholbach: (i. e. assigned, not yet uploaded)
<carlos> seb128: that's indeed what I would really like, well, maybe not file bugs automatically but render a page with such detected problems
<seb128> carlos: I understand that as you did want to review all the template yourself
<carlos> seb128: indeed
<pitti> ogra: hm, so no more moodle?
<seb128> carlos: get danilo to do it? ;)
<carlos> seb128: he's fighting with our database to get searching working...
<seb128> ah ok
<carlos> Maybe we could move to Mars to get longer days.. who knows... :-P
<seb128> that would also be nice
<dholbach> pitti:hum... I might not have got your reply
<pitti> dholbach: nothing fancy, just saying that I assinged the bug to me and set it to 'in progress'; will tend to it today, probably
<dholbach> pitti: you ROCK
* dholbach hugs super-pitti
<dholbach> keescook, bryce_: how's bug 96586 coming along?
<ubotu> Launchpad bug 96586 in inkscape "Correct multiple inkscape issues in Feisty (SRU and Backport)" [Medium,Fix committed]  https://launchpad.net/bugs/96586
<cjwatson> pwnguin: /usr/share/doc/base-passwd/users-and-groups.html
<pwnguin> excellent
<dholbach> Riddell: bug 136425, bug 121984? bug 121872? can either you or somebody of the kubuntu-main people at least comment on them?
* Hobbsee pokes ubotu
<ubotu> Launchpad bug 121984 in kdepim "kandy: no icon in kubuntu feisty's kde menu" [Wishlist,Confirmed]  https://launchpad.net/bugs/121984
<Hobbsee> bug 136425
<ubotu> Launchpad bug 121872 in qt4-x11 "*-qt4 tools should be present in $QTDIR/bin" [Undecided,In progress]  https://launchpad.net/bugs/121872
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<dholbach> Riddell: if you decide to not have them in gutsy, that's fine with me, but it'd be nice to at least get back to the patch authors
<Hobbsee> bug 121984 bug 121872
<cjwatson> pwnguin: I maintain that and am happy to document more users and groups in it, at least to some reasonable extent :)
<dholbach> calc: bug 135086?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<Hobbsee> oh, those ones
<cjwatson> pwnguin: BTW, the only reason pcmciautils doesn't use dh_installudev is because I haven't got around to it. As far as I know dh_installudev is safe to use on Ubuntu (we've certainly put some effort into making it so).
<pwnguin> cjwatson: cool
<dholbach> keescook, soren: if anybody'd have the time to check out bug 134346, that'd be cool
<ubotu> Launchpad bug 134346 in traceroute "Please sync traceroute (main) from Debian unstable (main)" [Medium,Confirmed]  https://launchpad.net/bugs/134346
<pwnguin> there was certianly some confusion on the issue in #-motu
<soren> dholbach: /me looks
<dholbach> soren: you ROCK
* soren hugs dholbach 
<dholbach> pitti: maybe you could factor in bug 114648 too?
<ubotu> Launchpad bug 114648 in gparted "gparted menu entry is not HIG compliant" [Wishlist,In progress]  https://launchpad.net/bugs/114648
<pitti> dholbach: no problem
<dholbach> pitti: assigning
* dholbach hugs pitti
<seb128> dholbach: I deferred other "menu entry is not HIG compliant" to next cycle because it's late now to break translations
<Hobbsee> dholbach: stolen 121984
<pwnguin> cjwatson: cwiid wants a udev rule for a kernel module to make it user readable, similar to fuse. i wonder about the long term viability of adding yet another group for it
<seb128> pitti: ^
<pitti> seb128: if it does that, I'll defer it
<seb128> pitti: thanks
<cjwatson> pwnguin: I don't know what cwiid is or what the purpose of the kernel module is
<cjwatson> I should probably document the fuse group
<pwnguin> cjwatson: cwiid is a wiimote library. one of the packages connects to the wiimote and somehow presents a mouse device to X
<dholbach> seb128: ok, thanks
<cjwatson> fuse is really nothing like anything else that existed, which is why it has its own group - not really because it is a kernel module
<pwnguin> well, the kernel module it wants is similar
<pwnguin> uinput
<pwnguin> fuse exposed filesystems to userspace, uinput is similar in nature
<cjwatson> pwnguin: /dev/input/* is root:root 0660
<dholbach> Hobbsee: thanks a lot
<cjwatson> pwnguin: any reason this shouldn't be the same?
<cjwatson> pwnguin: X starts as root so we don't need a special group here
<pwnguin> cjwatson: i dont defend the architecture of wmpinut, but it doesn't work if the user doesnt have read access
<pwnguin> or write access, probably
<cjwatson> err, if it's presenting a mouse device to X, shouldn't it just need X to have read/write access?
<pwnguin> im guessing it connects to a wiimote via bluetooth, and writes events to a uinput device
<cjwatson> I am familiar with how uinput works
<pwnguin> i am not
<pwnguin> currently, wminput is run by the user. that seems suboptimal
<cjwatson> I'd change that if I were you :)
<cjwatson> or make it escalate privileges with sudo or something
<pwnguin> i think the whole thing may need more design from upstream
<cjwatson> mouseemu is a similar precedent
<cjwatson> you just run it as root
<pwnguin> heh
<pwnguin> one caution
<pwnguin> bluetooth
<pwnguin> presents a slightly higher vulnerability threat
<pwnguin> but you're probably right, this is little more than an experiment that needs rethinking
<cjwatson> well, what's hard about just adjusting it in Ubuntu to run as root?
<Treenaks> is anyone looking at bug 119266? It's annoying to have to reload snd-hda-intel every reboot :)
<ubotu> Launchpad bug 119266 in linux-source-2.6.22 "Intel HDA Sound device doesn't work in gutsy" [Low,Confirmed]  https://launchpad.net/bugs/119266
<pwnguin> setuid? that sounds worse to me
<cjwatson> no, "as root" doesn't mean set-id
<cjwatson> I meant "you need to use sudo kthxbye"
<pwnguin> heh
<cjwatson> how is it invoked?
<cjwatson> is it an init script, a menu item, a random command you run from a terminal ...?
<pwnguin> just a random terminal command
<soren> seb128: Can we sync a package from Debian that's no longer in testing or unstable?
<pwnguin> sudo wminput might work, i need to remove the rule I wrote and try first though
<cjwatson> soren: technically speaking, we have the ability to sync from anything
<seb128> soren: we need the dsc
<seb128> soren: I mean if you give an url to the dsc so we can dget the orig, diff, dsc we can sync it
<soren> It's on snapshot.debian.org, so it's definitely available.
<soren> Rock.
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/+bug/144355/comments/9
<cjwatson> pwnguin: it seems to me that it's convenient to be able to run it as an ordinary user, but other than that there's little benefit to the device being read/write by anyone other than root
<ubotu> Launchpad bug 144355 in gcalctool "Incorrect Math in version 5.9.14" [Low,Invalid] 
<seb128> hum, this guy is not correct
<cjwatson> pwnguin: so it's a little awkward
<pwnguin> cjwatson: mainly im just going off the manpage / readme
<cjwatson> pwnguin: but I tend to think that having to add the user to more random groups is getting inconvenient in itself
<pwnguin> cjwatson: exactly why i was looking for a better way
<cjwatson> pwnguin: I suppose you could hook it off plugdev if absolutely necessary
<pwnguin> sudo works
<cjwatson> but my original response is my gut response :)
<pwnguin> i'll just change the documentation
<pwnguin> and bug upstream
<cjwatson> plugdev isn't really ideal, it's described as mounting removable devices
<cjwatson> pwnguin: TBH, I'd leave upstream alone
<cjwatson> pwnguin: this seems like a straight distro integration matter
<cjwatson> there are *some* things where it just doesn't make sense ...
<cjwatson> though it would be polite to keep upstream informed
<pwnguin> at some point it would be neat if it worked as well as say using a bluetooth mouse
<pwnguin> cjwatson: actually, upstream's recently published a new version that sounds like it solves this whole mess a bit more sanely. but its way too late for 7.10
* soren -> coffee
<cjwatson> pwnguin: ok
* dholbach likes the look of http://daniel.holba.ch/sponsoring very much - it's much cleaner now :-)
* pitti kicks another item off that list by moving plr to -updates
* dholbach hugs pitti
<pitti> dholbach: nice page!
<Mez_> where can I find ubuntu's linux.config (I need to add a modules to my kernel - which needs to build it)
<pwnguin> /boot?
<Mez> where can I find ubuntu's linux.config (I need to add a modules to my kernel - which needs to build it)ls /boot
<pwnguin> classic
<asac> Mez: /boot/config-2.6.22-12-generic
<Mez> nope (sorry, need a "focus follows eyes"
<pwnguin> out of curiousity, which modules are you after?
<Mez> dazuko
<pitti> mvo (CC: slangasek): does a feisty->gutsy upgrade display a particular 'upgrade notes' page?
<Mez> where should I put the linux.config now ...?
<pwnguin> why is that a kernel module and not a wrapper around libc?
<Mez> pwnguin, no idea
<Mez> asac, where should I be storing this to put it in the right place
<pwnguin> huh
<pwnguin> !info dazuko-source
<ubotu> dazuko-source: source for the Dazuko driver. In component universe, is optional. Version 2.2.0-1 (feisty), package size 178 kB, installed size 228 kB
<pwnguin> Mez: http://www.dazuko.de/tgen.shtml#DEBIAN . beyond that, ive no clue
<asac> Mez: use module-assistant and follow the steps
<Mez> asac, I'm using m-a - but it's failing on
<asac> Mez: should be straight forward .... but its not a #debian-devel topic after all
<Mez> acquiring Linux kernel code configuration... ok                            
<Mez>                                                                           .: 1565: linux.config: not found
<asac> s/debian-/ubuntu-/ obviously
<pwnguin> heh
<pitti> mvo: wb
<pitti> mvo does a feisty->gutsy upgrade display a particular 'upgrade notes' page?
<mvo> pitti: yes
<pitti> mvo: any idea what to put on it? "It just works, kthxbye."
<Mez> asac, mind if I /query you about this then - it's being a right PITA - and m-a isnt working
<pitti> mvo: bug 144771 does not generally happen and does not have a workaround anyway
<ubotu> Launchpad bug 144771 in fontconfig "package ttf-opensymbol 1:2.3.0~rc1-1ubuntu2 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/144771
<mvo> pitti: http://archive.ubuntu.com/ubuntu/dists/gutsy/main/dist-upgrader-all/current/ReleaseAnnouncement <- that is what is currently displayed
<asac> Mez: no please don't ... i have no clue about that as well ... its probably a bug in dazuko-source package which you should file then
<mvo> pitti:  144771> I think I can reproduce it, but only if the clock (notice the right spelling this time ;) is incorrect
<Mez> asac, cheers
<pitti> mvo: hm, shouldn't this say s/dev snapshot/Beta release/?
<pitti> mvo: how does that file get there?
<mvo> pitti: its part of the release-upgrader upload, but I can make it point to a different location as well via http://changelogs.ubuntu.com/meta-release-development
<mvo> pitti: it should say beta, I fix this now
<MacSlow> pitti, the format for indicating a fixed bug in the changelog is: (LP: #123456), right?
<TheMuso> MacSlow: Yes.
<pitti> MacSlow: right (the parentheses are not part of the syntax, but common practice)
<MacSlow> ok
<pitti> MacSlow: i. e. "* debian/control: Foobarize (LP: #123" and "* Do magic to fix LP: #1234" are both valid and common
<pitti> hi sabdfl, how are you?
<sabdfl> hey pitti, super thanks. you?
<sabdfl> http://news.zdnet.co.uk/itmanagement/0,1000000308,39289643,00.htm
<sabdfl> LinuxMCE is Ubuntu based?
<Mez> I saw something bout LinuxMCE in LXF today
<MacSlow> hi sabdfl
<MacSlow> pitti, in debian/control? I thought I was meant to add that to changelog when I do "dch -i"
<pitti> MacSlow: right
<pitti> MacSlow: that was a demo changelog for changing something in debian/control
<pitti> MacSlow: I usually note while files were touched by a change
<StevenK> sabdfl: The LinuxMCE wiki confirms it is.
<StevenK> sabdfl: I can paste the quote, or link if you like
<sabdfl> cool
<pitti> http://cdimage.ubuntu.com/edubuntu/dvd/20070926/ - ROCK
<pitti> stgraber, ogra, heno: ^
<pitti> within size
<pitti> oops, it claims not
<pitti> aren't DVDs 4.7 GB?
<StevenK> pitti: Single layer is around 4.7GB, yes
<pitti> mine are, at least
<pitti> heno, ogra: ok for using those? (4.5/4.7 GB)
<ogra> pitti, yeah
<cjwatson> pitti: the limit is 4700372992
<ogra> yup, totally
<cjwatson> per http://en.wikipedia.org/wiki/DVD_plus_RW
<pitti> ah, million bytes
<ogra> my progressbar for ltsp doesnt work :/
<pitti> the error margin becomes larger for GBs
* ogra reopens the bug ... grmbl ...
<cjwatson> those images are 4867667968 (amd64) and 4894072832 (i386)
<pitti> cjwatson: just four -dbg packages which want to go to universe now, not too bad
<ogra> at least the install doesnt stop it seems ...
<pitti> ok, back to the drawing board, then
<dholbach> wow... top 10 uploaders: http://ubuntu.joejaxx.org/
<ion_> Heh, neat.
<MacSlow> re
<ogra> ARGH !
<TomaszD> seb128, hi. in https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/144707 you said you've uploaded a new version of f-spot, but it's nowhere to be found, it's been a day now
<ubotu> Launchpad bug 144707 in f-spot "[gutsy]  f-spot build doesn't generate the .pot file" [Low,Fix committed] 
<TomaszD> am I missing something or have you forgotten something? :] 
<seb128> TomaszD: you missed than the archive is frozen for gutsy beta
<seb128> ;)
<TomaszD> oh shucks
<TomaszD> seb128, what now? :] 
<seb128> wait for after beta?
<TomaszD> will it get unfrozen before the release?
<seb128> sure
<seb128> it's only frozen until beta which is tomorrow
<TomaszD> ah, so it's going to be done sort of automatically just after the unfreeze
<seb128> yes
<TomaszD> alright
<TomaszD> thank you
<seb128> TomaszD: https://wiki.ubuntu.com/GutsyReleaseSchedule
<ogra> pitti, bad news ... :/
<pitti> ogra: ?
<ogra> ltsp failed
<ogra> i need another build (and one upload, luckily i only need to remove one module)
<pitti> ogra: hm, after throwing out all -dbg packages from edubuntu/supported, I'm afraid I might need to throw out all the -dev pacakges, too to get the DVD within size
<ogra> hmm
<ogra> if ltsp s building i'll take a look
<pitti> ogra: I can care for that, I just would like to have your 'ack'
<ogra> (having installable -server is higher prio atm :))
<pitti> ogra: absolutely
<ogra> yeah, feel free, whatever helps
<pitti> ogra: I move the publisher to manual, please tell me when you have a fixed upload
<ogra> yep
<soren> iwj: You wanted me for something yesterday afternoon?
<soren> iwj: ...or evening. I forget.
<iwj> soren: I was wondering if you'd have a chance to test sl-modem-daemon ...ubuntu3.  I think (hope!) it will fix your problem ...
<soren> iwj: Um.. The init script fails at line 111.
<iwj> !
<soren> iwj: It doesn't like umlimit -lH very much.
<iwj> You're running it as root, right ?
<soren> ulimit -lH, even.
<soren> Sure. -H just isn't valid.
<soren> or so it says..
<pitti> WTH?
<soren> Gah.
<soren> -S, I mean.
<pitti> maybe it doesn't use gnu style parsing and needs -l -H?
<pitti> iwj: oh, I see. bashism
<ogra> does dash have a builtin ulimit ?
<iwj> ogra: Yes.
<iwj> I tested that.
<iwj> This dash here is happy with ulimit -lH
<cjwatson> man dash /ulimit
<pitti> dash(1) says so
<soren> + ulimit -lH unlimited
<soren> /etc/init.d/sl-modem-daemon: line 111: ulimit: H: invalid number
<cjwatson> it's easy to check these things :)
<soren> I think I know what's going on.
<soren> It's probably my fault.
<pitti> works here, though
<cjwatson> soren: bash is unhappy with that, but dash gets it right
<cjwatson> this is actually a dashism not a bashism :)
<ogra> heh
<cjwatson> I bet soren has /bin/sh -> bash
<soren> Yes, I've been a naughty boy. I've ln -s'ed sh to bash :(
<iwj> root@anarres:~ # bash -c 'ulimit -lH 32'
<iwj> bash: line 0: ulimit: H: invalid number
<iwj> Oh, you've just got there.
<iwj> WTF
<soren> So an inverse bashism.
<pitti> ulimit -H -l unlimited
<cjwatson> -Hl works with both dash and bash
<soren> That's a first :)
<pitti> works with both
<soren> cjwatson: Not bash if you invoke it as sh.
<cjwatson> clearly its parsing goes [-H|-S]  [-<letter> <limit>] ...
<cjwatson> except not ...
<pitti> hi jamiecc
<ogra> ergh, pitti please reject the current ltsp upload there is another issue
<jamiemcc> hi pitti
<cjwatson> <cjwatson@sarantium ~>$ ln -s /bin/bash sh
<soren> iwj: Yes, this works. What did you do?
<cjwatson> <cjwatson@sarantium ~>$ ./sh
<cjwatson> sh-3.2$ ulimit -lH unlimited
<cjwatson> sh: ulimit: H: invalid number
<cjwatson> soren: ^--
<pitti> ogra: done
<soren> cjwatson: Exactly.
<ogra> thanks
<cjwatson> but -Hl is still fine
<iwj> I added   ulimit -lH unlimited; ulimit -lS unlimited
<pitti> iwj: but that's wrong?
<iwj> Well, it's a dashism.
<iwj> I think we don't need to panic about it.
<iwj> Well fix it after beta.
<iwj> s/We/We'
<soren> Sure.
<iwj> soren: Try http://www.chiark.greenend.org.uk/~ian/d/sl-modem/
<StevenK> pitti: If you aren't too busy with beta stuff, [ps] pu-testsuite can be NBS'd out.
<pitti> StevenK: done already
<StevenK> pitti: Okay, cool.
<soren> iwj: uh... The changelog says you changed it.. but you didn't?
<ogra> pitti, this one's better
<iwj> soren: Gah, I'm doing too many things at once.  I forgot to save the file.
* soren hands iwj a penalty cards
<soren> lying
<soren> lieing(sp?), even.
<iwj> Try now.
<cjwatson> soren: "lying" is correct
<soren> cjwatson: Ok, thanks.
<soren> iwj: \o/
<iwj> soren: Thanks.
<soren> iwj: Thank *you*. I don't even have a cable so I could actually test it :(
* soren picks up a penalty card for lying
<soren> iwj: I don't, however, have a phone number I can test against.
<iwj> soren: No, that's fine.
<iwj> If it fixes the regression then that's fine.  I've done an end-to-end test myself.
<soren> iwj: Ok, cool.
<\sh> thekorn, ping BugLIst example... if I set the url to https://bugs.edge.launchpad.net/ubuntu/+bugs is the method reading all 31k bugs in ? (not the bugs but the important infos?)
<pitti> ogra: ok, looks good; beating through publisher/buildds now
<ogra> thanks
<ogra> i hope thats all :(
<pitti> ogra: does that require new desktops/live fses, too?
<ogra> nope
<ogra> only server
<pitti> ogra: ok, I'll rebuild server and DVDs for that then
<ogra> ok
<cjwatson> pitti: I might need a new parted for cell, though it can be powerpc-only and doesn't need released CDs to be rebuilt
<cjwatson> still trying to work out exactly what its partition table format is
<pitti> cjwatson: ack
<cjwatson> it looks sort of like DOS (and has the signature and everything) but then goes:
<cjwatson> 000200 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
<cjwatson> and then all zeroes
<pitti> yay octal counting
<cjwatson> given that that's supposed to be stuff like CHS offsets, I'm a bit confused
<thekorn> \sh: yes, it will parse all pages
<\sh> thekorn, and what's the best way to say "start=1 and end=30"?
<ogra> pitti, oh, if you rebuild server i just remembered, LaserJock uploaded a fix for the icons on the addon CD, could you let that through as well, would make sense to have it if we rebuild anyway
<cjwatson> oh, whoops, I'm crazy, the partition table is only there for PC98
<ogra> cjwatson, does in-target actually steal any output of its child ? my udeb script works fine with chroot, but in-target seems to not let anything through (writes fine to the logs etc and the backgrounded process also finishes)
<thekorn> \sh: hmm, I think py-lp-bugs can't do this currently,
<\sh> thekorn, do you implemented something like a progress callback e.g. to show somehow some "progress" in loading the bugs? ;) I'm just lurking in the sources
<cjwatson> ogra: in-target logs all output from its child; it doesn't pass it to stdout
<ogra> cjwatson, something like "in-target command > /tmp/command.log &" doesnt create /tmp/command.log
<ogra> yeah
<ogra> so my best bet is chroot then i guess
<cjwatson> if you need that, copy in-target (you can still use the chroot-setup library) and use log-output --pass-stdout
<ogra> ah, i'll look into that after beta
<thekorn> \sh: no, we thought about this some time ago, but did no further work on this, but having something like 'start=' 'end=' or 'count=' would be usefull,
<\sh> thekorn, I want to work on a UI for py-lp-bugs and something like a progress would be nice ...
<thekorn> \sh, wow cool,
<thekorn> \sh: some time ago I found http://conseil.fritalk.com/
<thekorn> \sh: and started working an py-lp-bugs protocol
<thekorn> but did not finish it
<ogra> pitti, i uploaded another ltsp that switches off all output in d-i for now, so i dont run into further probs
<pitti> erk
* ogra thinks its better to be on the safe side
<pitti> ogra: I am halfway into publishing this one
<ogra> meh, sorry
<pitti> ogra: ok, will cost another 50 minutes
<ogra> but it guarantees that it will finish properly at least
<pitti> alright
<\sh> thekorn, oh...I didn't know that someone wrote this..will have a look this evening
<thekorn> \sh: ok, will post my changes later today
<cjwatson> doko: isn't bug 138638 just incorrect code? the array it's indexing is [8] 
<cjwatson> it should be using dir_entry->extension instead ...
<cjwatson> (post-beta though)
<ubotu> Launchpad bug 138638 in parted "ftbfs with g++-4.3/-snapshot" [Medium,Fix released]  https://launchpad.net/bugs/138638
<doko> cjwatson: well, undefined. using dir_entry->extension would be more correct
<cjwatson> doko: yes, "undefined" is incorrect in my book :-)
<thekorn> \sh: my diff against this svn repo: http://conseil.fritalk.com/svn/conseil is http://paste.ubuntu-nl.org/38628/
<pitti> ogra: do you want to keep moodle in main for gutsy?
<ogra> its in ship
<ogra> i just dont instal it by default ....
<pitti> ogra: it's in component-mismatches
<ogra> huh ?
<ogra> i moved it to ship
* ogra checks
<pitti> hm, indeed
<pitti> seems that anastacia does not look there
<pitti> ogra: I'll add it to supported if you don't mind
<ogra> intresting
<ogra> yeah
<pitti> ogra: ah, I bet I know
<pitti> ogra: STRUCTURE does not have 'ship' in the supported: line
<ogra> hmm, its not on the CD either
<pitti> that needs to be there, I think
* pitti fixes
<cjwatson> pitti: ? it does
<ogra> err
<cjwatson> at least in my seed branch
<ogra> there is something really weird going on
<pitti> oh, hm, right
<pitti> sorry
<ogra> pool/main/p/postfix/postfix-cdb_2.4.5-3_i386.deb
<ogra> there are tons of other postfix packages
<ogra> (i dropped postfix and ut surely wasnt on yesterdays CD)
<cjwatson> please wait and I'll look
<ogra> yeah
<ogra> openoffice has pulled *all* langs on the CD ...
<cjwatson> ogra: you broke the seed syntax
<cjwatson> it has to be " * " at the start of the line not "  * "
<cjwatson> one space
<cjwatson> server-ship: * %postfix
<tts> hi! may i ask who's behind hr@canonical.com? i would be most pleased to have a name to adress ;)
<ogra> argh
<ogra> cjwatson, i kept them in line with the line above (which indeed is commented)
* ogra headdesk
<cjwatson> ogra: well, don't :)
<pitti> ah, ltsp built; publishing
<ogra> thats a weird effect though
<ogra> pushing seeds
<ogra> mjg59, ping
<ogra> mjg59, looking at bug 140839, could it be that the gpm-brightness-lcd.c has another return function giving back UINT =
<ubotu> Launchpad bug 140839 in gnome-power-manager "Cannot increase display brightness with hotkeys" [Undecided,Confirmed]  https://launchpad.net/bugs/140839
<lamont> ogra: did you drop exim when you dropped postfix? or are you biggoted?
<ogra> ?
<Kopfgeldjaeger> hi
<ogra> lamont, i needed 1M for beta, postfix will come back if openoffice is fixed ... dont worry :)
<ogra> we dont install postifi in edubuntu ....
<ogra> *postfix
<lamont> s/if/when/ :)
<ogra> heh
<pitti> mvo: before we release the beta, we should really move the pending feisty-proposed update-manager to -updates
<mvo> pitti: yes, that would be good. i can currently not reproduce why it does not show up the "upgrade" button but I know that my update fixes it for the people who do not see it
<pitti> mvo, bdmurray: in particular, we need bug 127263 verified
<ubotu> Launchpad bug 127263 in update-manager "update-manager cannot find meta-release info" [Medium,In progress]  https://launchpad.net/bugs/127263
<pitti> the other is already
<pitti> mvo: "sudo update-manager -d" should DTRT with that?
<mjg59> ogra: No, it's more likely to be the kernel being stupid
<ogra> [gpm_brightness_lcd_set_hw]  gpm-brightness-lcd.c:155 (10:48:53):         Setting 95 of 100
<ogra> (gnome-power-manager:8525): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
<ogra> [gpm_brightness_lcd_down]  gpm-brightness-lcd.c:392 (10:48:53):   emitting brightness-changed (95)
<ogra> mjg59, hmm ^^^
<mjg59> Hm.
<ogra> thats from one of the logs
<mjg59> I suspect he's got an old hal
<mjg59> Anyway, I'll look into it
<ogra> oki
<mvo> pitti: yes, I got positive reports that 0.59.25 worked for peope who had problems with .23 (bjornT for example)
<mvo> pitti: I will try to reproduce it nevertheless
<mvo> pitti: and if I manage I add instructions, it maybe releated to proxy/transparent proxies
<pitti> mvo: can you mention the feedback in the bug report? reproducing would be good as well
<mvo> pitti: sure
<pitti> mvo: since this is a bit urgent, we need to bend the rules a bit
<mvo> yep
<siretart> does anyone know a start-stop-daemon(8) version in perl?
<iwj> siretart: It used to be in Perl; try old versions of dpkg.  Why ?
<jdstrand> asac: the new wpasupplicant seems to be working fine.  I didn't give any feedback because there weren't any problems here
<asac> jdstrand: ok thanks for the info
<ogra> mvo, do you still have many gl screensaver probs with compiz ?
<mvo> ogra: I'm not aware of any
<ogra> ok
<agoliveira> Talking about wpasupplicant, is anyone using wpa/wpa2 with ipw3945? I tried last night but wasn't able to connect to my AP, the network manager just kept trying. Don't have any details yet.
<ogra> i thought there was one you pointed out in a meeting recently
<siretart> iwj: I'm porting a shellscript using start-stop-daemon(8) to perl, and hope there is a better solution than to use system or something
<ogra> mjg59, oh, in case you do changes, note that there is anoter g-p-m version sitting in the queue waiting for defrosting ...
<pitti> ogra: edubuntu server and dvd rebuilding
<ogra> thanks
<jdstrand> tepsipakki: I made a comment on bug #120858
<ubotu> Launchpad bug 120858 in vte "Graphical corruption in gnome-terminal" [Medium,Confirmed]  https://launchpad.net/bugs/120858
<iwj> siretart: There's nothing wrong with calling start-stop-daemon via system.  Perl is good at that kind of thing.
<jdstrand> tepsipakki: basically the new driver did improve things (so far), but there are still some font rendering problems
<siretart> hm. ok
<iwj> siretart: You should definitely do that rather than cloning and hacking some ancient version and bodging it into your program.
<iwj> Calling external programs is not a wrong thing to do, dammit!
<siretart> hehe. okay okay :)
<tepsipakki> jdstrand: I don't think it's a driver issue
<jdstrand> tepsipakki: perhaps the updated driver is better masking the underlying problem then
<jdstrand> tepsipakki: like I said, I am still seeing font rendering problems
<ogra> hmm, is that just me or is anything *.ubuntu.com and *.canonical.com gone atm ?
<seb128> ogra: not only you
<mvo> confirmed
<pitti> me three
<ogra> pitti, did my CD rebuild kill the DC ?
<cjwatson> ogra: of course not :P
<ogra> :)
<seb128> ok, it's back
<cjwatson> only partly
<cjwatson> routing via Telia is still broken
<pitti> not here
* ogra doesnt get a.u.c yet
<seb128> launchpad is back rather
<soren> Where'd the dc go?
<ogra> lunch ?
<ogra> well, late lunch :)
<fabbione> did somebody remembered to pay the electricity bill?
<cjwatson> IS are investigating
<ogra> my traceroutes all end at byrd
<soren> Yay!
<ogra> hmm, gone again ?
<mvo> not the best time to try to verify a problem where update-manager sometimes does not find changelogs.ubuntu.com ;)
* mvo waits patiently
<ogra> heh
<ogra> not the best time to try to rsync the latest iso either
<zul> gopher ate the cable?
<ScottK> Something like that, although it was back for a minute there.
<ScottK> soren says it was racoons.
<ogra> racoons dont eat cable
<TomaszD> wretched racoons
<seb128> ogra: why not? ;)
<zul> ogra: racoons will eat anything
<soren> ogra: Not anymore. It's all gone.
<ogra> heh
<ogra> seb128, well, ours at least :)
<\sh> ogra, looks like a typical ISH problem with a catapillar ,-)
<ogra> yeah
<ogra> caterpillar, power outage or london was nuked and we dont know yet ...
<Keybuk> racoons aren't native to the UK
<ogra> "Raccoons are omnivorous, consuming a varied diet that includes berries, insects, fruit and small mammals."
<Keybuk> they could have escaped from London zoo I guessed
<ogra> from: http://en.wikipedia.org/wiki/Common_Raccoon
<ogra> but i probably should have looked at http://en.wikipedia.org/wiki/Cable_eating_Raccoon
<ogra> :)
<Keybuk> it could be Squirrels
<ogra> we really sholdnt have taken the nut coated fiber for the DC
<cjwatson> Keybuk: it could be bunnies
<soren> Or elmos?
* soren hides
<ion_> Squirrels ftw. Giraffes ftw. Giraffes licking squirrels ftw. http://www.kuvaton.com/kuvei/kurre5.jpg
<agoliveira> cjwatson: Rabbit of Caerbannog for sure :)
<\sh> "And I told our cleaning lady not to push the red button...and what she did? pushed the red button"
<mvo> bdmurray: I added verficiation instructions for feisty update-manager in  https://bugs.edge.launchpad.net/update-manager/+bug/127263/comments/44  now, I hope they are good enough
<pitti> ogra: edubuntu server is ready
* ogra wonders if he can risk to fire up an rsync now
<pitti> ogra: however, DVDs are still oversized; I wonder why my removal of -dev wasn't effective
<ogra> pitti, yup, saw that when the DC was online for a min
<pitti> ogra: added to the tracker, please test
<mvo> pitti: where should I add notes that the update-manager 0.59.25 is required for the update? https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
<mvo> ?
<pitti> mvo: give me some more minutes, I'm writing https://wiki.ubuntu.com/GutsyGibbon/Beta
<pitti> mvo: and I already mentioned that
<mvo> pitti: aha, great. thanks for this
<pitti> asac: can you please add some comprehensible explanation to the 'firefox plugins' part of https://wiki.ubuntu.com/GutsyGibbon/Beta ?
* asac_ looking
<asac_> pitti: either my connection is down or the wiki
<ogra> works fine here
<pitti> asac_: it started working again some minutes ago for me
<dendrobates> asac_: still down here
<asac_> for me too
<asac_> same for canonical irc
<manchicken> mvo: ping
<pitti> asac: does it work again for you?
<pitti> mvo: the first TODO on https://wiki.ubuntu.com/GutsyGibbon/Beta is a question for you
<Lure> tepsipakki: does your 194 ati packages contain any additional patches (see FD bug 12474
<ubotu> Launchpad bug 12474 in control-center "gnome-theme-manager crashes" [Medium,Fix released]  https://launchpad.net/bugs/12474
<Lure> tepsipakki: http://bugs.freedesktop.org/show_bug.cgi?id=12474
<ubotu> Freedesktop bug 12474 in Server/general "DisplaySize overridden and DPI miscalculated by the driver" [Normal,New] 
<tepsipakki> Lure: no, it's vanilla upstream
<Lure> tepsipakki: thanks
<tepsipakki> and tormod built that one ("tv" suffix :)
<bddebian> Heya
<Lure> tepsipakki: sorry, I am confusing you two ;-)
<tepsipakki> heh
<tepsipakki> np
<tepsipakki> hmm, it really would be useful to be able to submit bugs upstream more easily.. as it was suggested a while back
<lamont> pitti: fyi the libast upload fixes the 'package/arch do not alternate' error.
<pitti> lamont: ah, splendid
<lamont> although that's certainly _NOT_ a beta requirement. :0)
<pitti> it's universe *shrug*
<lamont> pitti: and a bug filed against debian would be on the "to do for bonus points" list
<lamont> as in I doubt that I care enough to remember/expend the effort.
<bddebian> pitti: Hey, what does that mean? :-)
<lamont> bddebian: it means "freeze, schmeeze"
<pitti> bddebian: as in "universe is not subject to the freeze"
<bddebian> w00t
* bddebian starts uploading
<lamont> bddebian: just nothing important, 'mk?
<lamont> :-)
<bddebian> I'm kidding
<lamont> lol
<mvo> pitti: reading
<mvo> manchicken: pong
<bddebian> Though I did think about an apache2 upstream update for libapache-mod-something or other
<mvo> asac: are yuo editing the page currently?
<manchicken> mvo: Did you get that message I sent ya?
<pitti> mvo: I'm not either; Gerry might
<pitti> ah, no, it's asac
<mvo> manchicken: mail or irc?
<mvo> asac_: your lock timed out, I steal it now if you don't mind?
<pitti> mvo: Gerry just finished with his edits; please go ahead
<pitti> mvo: you won't edit the same section anyway
<lamont> pitti: I do plan to do a glibc upload once jbailey packages it.  I rather expect you won't approve it until post-beta
<lamont> (hppa ftbfs)
<mvo> pitti: will the server version have its own Beta announcement page? I would like to add instructions for those upgrades as well
<pitti> lamont: right :)
<pitti> mvo: I hope so, there's nothing server specific so far
<pitti> dendrobates: ^ is there?
<mvo> pitti: do you think we should mention https://wiki.ubuntu.com/CompizFeedback in the page under 3d effects?
<pitti> mvo: sure; please add it to the "Testing" section
<pitti> mvo: I don't want to be pushy, but since we need the new u-m on all mirrors tomorrow, do you think it's safe to copy over?
<mvo> pitti: yes, I added verification instructions now too. but i think it will be fine
<mvo> pitti: Testing updated
<seb128> iwj: bug #145235, do you try to add a podcast or something else?
<ubotu> Launchpad bug 145235 in rhythmbox "add feed is not discoverable" [Undecided,New]  https://launchpad.net/bugs/145235
<seb128> iwj: because there is a toolbar and a menu item to add one
<iwj> seb128: I was going through Testing/Cases and it told me to right click.
<iwj> I don't have a rhythmbox open right here; it's currently doing another install.  I'll have a look when that's finished.
<seb128> iwj: ok thanks
<pitti> mvo: thanks; I added some `...` for formatting love
<mvo> pitti: aha, thanks
<iwj> seb128: I can see the menu item:  Muziek / New Podcast Feed ...
<seb128> iwj: there is also a toolbar icon
<iwj> seb128: But no toolbar item.
<iwj> Where would it be ?
<seb128> when you select podcast
<seb128> the one which looks like a bubble
<seb128> the tooltip says something like "subscribe to a podcast"
<iwj> Ah!
<iwj> If I resize the window to be larger, it appears.
<iwj> It was hidden in an obscure kind of leftover toolbar thingumy.
<seb128> do you have small screen resolution?
<iwj> xdpyinfo says 96dpi.
<iwj> 1280x1024.
<iwj> It seems like a perfectly normal screen to me.
<seb128> right
<seb128> let me try with a stock config
<seb128> because on my desktop the toolbar doesn't even take half of the rhythmbox window size
<seb128> using 1280x1024
<iwj> Various other things were wrong sizes too.
<iwj> I have to say this dpi dependency is really excessively fragile.
<seb128> iwj: anyway do you consider the menu item and the toolbar icon enough?
<iwj> Yes, if the toolbar icon were actually to appear :-).
<iwj> I think it's a bug that if there isn't enough space, it hides important stuff.
<seb128> ok, bug confirmed on my laptop
<iwj> Feel free to hack away at the description and so on of my bug report(s).
<seb128> ok, will do
<seb128> thanks for testing
<iwj> seb128: NP
<leleobhz> someone can helpme with packages an menu entryes?
<ogra> leleobhz, #ubuntu for support
<ogra> or #ubuntu-motu
<leleobhz> isnt support
<ogra> (for packaging stuff)
<leleobhz> im making a package
<leleobhz> and i need to change the entry on it
<leleobhz> i tryed to change the menu.in on debian/
<leleobhz> but dont make effect
<leleobhz> it create a appname.desktop on debian/
<leleobhz> but change it have no effect because appear to be dynamically created
<leleobhz> ogra: understand?
<bddebian> leleobhz: We don't use menu files in Ubuntu, only the .desktop files
<bdmurray> mvo: Those instructions worked well thanks.
<mvo> bdmurray: great, thanks!
* pitti hugs bdmurray
* ogra prays ... watiching the ltsp udeb run ...
* mvo hugs bdmurray and pi'hawk-eye'ti
<bdmurray> mvo: by the way every once in a while when using the touchpad on my laptop the workspace switcher pops up when compiz is on
<mvo> bdmurray: oh? and it switches workspace then I assume?
<cjwatson> bdmurray: are you using tap-to-click or one of the scrolling options?
<cjwatson> system -> preferences -> mouse -> touchpad
<ogra> grmbl ... grub-install failed
<bdmurray> cjwatson: Tap to click and vertical scrolling
<pitti> ogra: *whine*
<bdmurray> Ah, it seems to be the vertical scroll then.
<pitti> ogra: does that mean that the current images are still broken, or is it something that can be worked around?
<ogra> i'm checking whats wrong
<ogra> hmm, backgrounding something but removing the part of the UI that waits for it to finish isnt really clever ... crap !
<ogra> pitti, ltsp-update-image stil runs in the bg ... there is one & to much in the udeb :/ i'm waiting for ltsp-update-image to finish, if grub-install works then i'll just add a bug with "wait until the disk stops rattling and select grub-install from the menu" to the notes :/
<ogra> even though thats pretty ugly
<pitti> ogra: that happens during the initial installation already? or after a manual action from the user?
<pitti> ogra: if the latter, we might get away with documenting it, i. e. ask them to upgrade their system before creating the ltsp chroot
<ogra> the install apperas to be finishing with a grub error
<ogra> *appears
<ogra> i assume thats because d-i cant unmount the disk due to the running backgrounded process
<ogra> the user will see the disk rattling thought
<pitti> ogra: hm, if that happens during the initial installation, that pretty much sounds like a blocker, though
<ogra> meh
<ogra> ok, i'll upload a fix
<pitti> darn, publisher just started
<pitti> I should have left it on manual
<pitti> ogra: you have 30 minutes for free to test it, no need to upload right now
<mathiaz> heno: what's the status with the individual testcase link in the qatracker ?
<heno> mathiaz: stgraber will need to update the DB manually for that. I suggest we do them all just after beta is out
<heno> it's not just adding links, we should also restructure how some test cases are listed
<heno> mathiaz: do you want install to be one long test with all those components, or do you want mail, LAMP etc, to be separate test cases?
<mathiaz> heno: the current page works for me now.
<mathiaz> heno: could we update the links before beta ? Because now they're pointing to a dead link.
<heno> mathiaz: oh, not dead, they're actually pointing to a wrong live link now, which is worse :)
<heno> stgraber: could you please point the server test case links at https://wiki.ubuntu.com/Testing/Cases/ServerInstall when you get a chance?
<mathiaz> heno: yes.
<mathiaz> heno: I was also looking into server iso tester in ubuntuforums.
<heno> I agree that should be changed soonish
<mathiaz> heno: what would be the best forum to post such an annoucement ?
<heno> mathiaz: Dev Link http://ubuntuforums.org/forumdisplay.php?f=265
<mathiaz> heno: ok. Thanks. What about   Development CD/DVD Image Testing forum ?
<heno> mathiaz: that would work also
<heno> not sure which has more traffic ATM
<mathiaz> heno: ok. Thanks.
<pitti> ogra: current publisher is about to finish, so the window is open for uploads
<ogra1> pitti, the test still needs 10-12min
<ogra1> but ooks ok so far
<ogra1> just didnt finish yet
<ogra1> (mksquashfs isnt really fast in a VM :/)
<pitti> ogra1: that's fine, please finish your test
<ogra1> 31% :)
<pitti> evand: have the gobuntu CDs been tested at all? should we release them with the beta?
<evand> hrmm, no they haven't, I'll do that now
<pitti> evand: do you feel that they are generally mature enough to be called 'beta'?
<evand> indeed, they're just ubuntu - restricted, so they should be as mature as the regular release is.
<ogra1> pitti, ok, looked good in my test install here, grub finished as well now with that fix
* ogra1 waits for the VM to reboot
<pitti> ogra1: \o/ *hug*
<ogra1> thats the worst edubuntu release every
<ogra1> *ever
<ogra1> :/
<ogra1> pitti, thanks, thats needed
<ogra> pitti, uploade
<ogra> d
<pitti> yay, processing
<pitti> ogra: btw, what's edubuntu-addon-meta all about? It adds lots of new apps to your already full addon CDs
<ogra> lots ?
<ogra> it shouldnt add any apps
<pitti> +  * Added new apps: atomix, gpaint, xaos, kino, scribus, dia-gnome, and denemo
<ogra> hmm
<ogra> they should have been added long ago with a seed change i did
<pitti> those are new dependencies of edubuntu-addon-{young,legacy}
<pitti> ogra: if they are already on the CD and thus just installed by the metapackage, that's fine, but I didn't check that
<ogra> which should be fine since the apps are in ship-addon
<pitti> so you want that?
<ogra> the metapackages are just for easier installation
<ogra> let me check the .list file for addon
<pitti> ogra: ltsp> the & went away; the changed ordering is ok?
<ogra> yes
<pitti> -in-target ltsp-update-image >$COMPRESS_LOG 2>&1 &
<pitti>  db_progress START 0 100 ltsp-client-builder/compress
<pitti> +in-target ltsp-update-image >$COMPRESS_LOG 2>&1
<ogra> yup
<ogra> else the user will see the first progress at 0% for 20 min
<ogra> this way at least the text changes after 10 min
<pitti> ogra: ok, please give me the yay or nay for addon-meta, I need to shove it in with this publisher
<ogra> they are all there
<ogra> so go for it
* pitti accepts and cranks the soyuz machinery
<ogra> yay
<ogra> thanks :)
<ogra> pitti, i'm fine triggereing the CD builds myself if you want to call it a day
<pitti> ogra: don't worry, my day is not quite over yet :)
<ogra> mine neither :) 3h to the edubuntu meeting
<pitti> and another round of testing, I guess
<pitti> ogra: can LaserJock and davmor help you with edubuntu testing? heno, anyone else?
<ogra> i doubt LJ has the time
<heno> pitti, ogra: what needs testing exactly?
<ogra> the next server build
<heno> ok
<ogra> -desktop has two tests already and i havent added my three yet
<ogra> so -desktop should be good
<heno> ogra: I can test (without thin clients) and stgraber says he will test later today
<ogra> oki
<ogra> thin clients are not the top of the list atm .. installability counts more :)
<ogra> so a plain install test helps a lot :)
<heno> the little things, as Colin says :)
<heno> oki, will do
<ogra> :)
<ogra> asac, the partch isnt tested or something i just grabbed a line in the nm-applet code that looked like it would be responsible for starting it ...  i'm fine to develop a proper patch for you though
<asac> ogra: let me know ;) ... i can provide test packages as well, but i think its easier for you because you can test that properly
<MadMan2k> hi, is there some documentation for apturl?
<MadMan2k> I mean the syntax and especially adding new repositories with it?
<MadMan2k> ok, got it by looking at the tests source
<evand> yikes, the gobuntu install is broken
<geser> does somebody know if the xserver-xorg-video-radeonhd driver is usable?
<jdong> geser: phoroniz folks claim it's usable on the 2000 series
<jdong> geser: though they also in the same article warned about stability issues with it
<geser> my graphic card broke and I need now a new one :(
<jdong> geser: ATI cards are looking very promising right now
<geser> any specific chipset which works currently the best with a free driver?
<mjg59> "Usable" is pushing it
<geser> and is still buyable
<mjg59> It's still at the point where nvidia cards will work better with free drivers than recent ATI ones
<jdong> I don't think there's any cards that match that IMO
<jdong> if you want 3D support
<ogra> get intel to finally produce standalone boards
<geser> 3d would be nice but not a must have under linux, but it should have a decent 3d performance under xp for games
<geser> does nvidia run better than ati with a free driver?
<mjg59> Yes
<mjg59> Currently
<jdong> no 3D at all, but otherwise good currently
<jdong> binary drivers have SMP race conditions with compiz-stuff
<pwnguin> the open source 3d drivers for radeon 3d do okay
<mjg59> pwnguin: If you can still find an X800 or older, yes
<pwnguin> heh
<pwnguin> yes
<pwnguin> i wasnt aware they were that old
<jdong> mjg59: do you think the future looks good for modern ATI cards though?
<jdong> it seems like the right thing is happening
<geser> I have currently an ati radeon 9800 (r300) and 3d with the free driver but it's broken now
<mjg59> The right thing is happening. It's not clear how long it'll take.
<pwnguin> the docs on ati that ive seen dont touch 3d
<mjg59> They don't
<mjg59> Nor 2d acceleration
<jdong> that's too bad :(
<mjg59> They're expected to appear
<geser> does the nv driver support all available nvidia chipsets?
<pwnguin> on the other hand, neither nv or nouveou support rotate 180
<pwnguin> =/
<pitti> ogra, heno: http://cdimage.ubuntu.com/edubuntu/daily/20070926.2/ -> those, nor none
<ogra> nor none :)
<pitti> erm, 'or'
<bdmurray> are?
<ogra> beta ?
<bdmurray> mvo: Where would a bug about video playback and compiz belong?  Would it be a driver issue?
<mjg59> bdmurray: What's the bug?
<bdmurray> mjg59: watching a video with compiz on then use the super+e and the video doesn't get resized it just zooms out
<mjg59> Yes, that won't work
<mjg59> The video is scanned out after the rest of the screen
<mjg59> You can't apply any sort of transformation to it
<bdmurray> Is there a list of things that won't work then so we can avoid bug reports or deal with them?
<ion_> I wish it did that on my computer, because video playback would be insanely smoother if it didnt go through a texture.
<mjg59> bdmurray: Any effects won't work when applied to video
<mjg59> The same is true for rendered 3D
<bdmurray> mjg59: okay and that is true regardless of the hardware or driver?
<ion_> mjg59: Is there a way to get that behavior with the proprietary nvidia driver?
<mjg59> bdmurray: Oh, I expect a bunch of stuff will work with nvidia. It's broken on every other driver, though
<pitti> ogra: f**k, the DVDs are still oversized
<pitti> ogra: so it wasn't just a 'germinate didn't catch up' problem last time
<ogra> hmm
<ogra> anything duplicated on them ?
<ogra> hmm, is there a way to drop linux-image-debug from them ?
<ogra> there are 4 of them
<pitti> should do that, right
<pitti> I'll look into that
<ogra> i think its only about 100M you need
<pitti> 180
<ogra> for i386 ?
<ogra> meh
<ogra> ogra@laptop:~$ /home/ogra2/getpkgsize linux-image-debug-2.6.22-12-386 linux-image-debug-2.6.22-12-generic linux-image-debug-2.6.22-12-virtual linux-image-debug-2.6.22-12-server
<ogra> linux-image-debug-2.6.22-12-386:  22981k
<ogra> linux-image-debug-2.6.22-12-generic:  23603k
<ogra> linux-image-debug-2.6.22-12-virtual:  22418k
<ogra> linux-image-debug-2.6.22-12-server:  23870k
<ogra> total: 90M
<ogra> so thats only half of it
<mvo> bdmurray: what mjg59 video and 3d are known not working with any effects
<lamont> Rebuilding the database. This may take some time.
<lamont> /usr/share/omf/windows/windows-C.omf:8: parser error : Entity 'rsquo' not defind
<lamont>     <title>If you&rsquo;ve been using Windows</title>
<lamont>                         ^
<lamont> neato
<pitti> cjwatson: do changes to the 'supported' seed need a publisher run to get effective for CD builds?
<pitti> cjwatson: s/CD/DVD/
* lamont wonders who he should poke to cause an ia64/livecd for ubuntu to get created
<lamont> (livefs is waiting)
<pitti> can do
<pitti> ah, livefs ok already? cool
<lamont> livefs is waiting
<Pici> I know that https://wiki.ubuntu.com/GutsyGibbon/Beta isn't finished yet, but the image for the deskbar is a bit misleading, since its not really a bar anymore.
<Pici> Either that or theres something wrong with my version.
<lamont> pitti: and starting the livefs builds for the others now (since ubuntu worked..)
<pitti> lamont: running
<lamont> pitti: thanks.  will it just show up on cdimage/ports? or do we have to do something more?
<pitti> lamont: should turn up there, yes
<lamont> thanks.  I'll look for it in a bit then
<lamont> the squashfs image is only 663113728... I wonder if this one stands a chance of fitting on a CD
<lamont> wow.  maybe
<pitti> http://cdimage.ubuntu.com/ports/daily-live/current/
<pitti> there
<lamont> (663830528 for the current i386 bits)
<pitti> lamont: i386 and amd64 have the winfoss stuff, so ia64 should be good
<pitti> lamont: size looks fine
* lamont syncs and burns
<lamont> (alternate is just a tad big for ia64 atm)
* lamont notes that installing gutsy/ia64 from -alternate works
<lamont> hrm... the rsync is gonna take a whiel.
<lamont> pitti: dunno if gutsy-server-ia64 ever got set up or not, but we're missing that one, too.
<lamont> I think...
<pitti> lamont: build started for ia64 and powerpc
<lamont> thanks
<cjwatson> pitti: supported> shouldn't
<pitti> cjwatson: ah, thanks; that helps
<cjwatson> it's not a task or anything
<pitti> lamont: http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/, have at it :)
* lamont prepares to upload livecd-rootfs_0.36
<lamont> pitti: livecd-rootfs_0.36 has two changes from 0.35: (1) fix the ia64 kernel package names, and (2) make it non-fatal if dpkg -l livecd-rootfs fails
<pitti> lamont: ok
<pitti> lamont: I'll look at the debdiff before approving it anyway, so please go ahead and upload
<lamont> I'd rather not say how I came to that second change...
<lamont> it's inbound now
<keescook> ew  [143202.649187]  device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
<pitti> ogra: I pre-publish the edubuntu servers now; stgraber saw that thin client booting is pretty much screwed, but I think that can be handled with a post-beta upgrade, right?
<pitti> ogra: and we are just out of time to push out new ones
<ogra> pitti, yeah, seems udev des some strange things with network cards
<ogra> wrt naming them
<pitti> ogra: it's either udev, or there's a possiblity that it is due to the recently changed ifupdown/network-manager /e/n/i rewriting
<ogra> they seem to have different names in d-i than they have in the installed system
<ogra> sh, right
<ogra> that could be it as well
<pitti> ogra: *moan* http://cdimage.ubuntu.com/edubuntu/dvd/20070926.4/
<pitti> ogra: that's without -dev, -dbg, and -debug
<pitti> ogra: do you insist on DVDs for the beta?
<liw> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/134496 is what I see: udev/NM/something doesn't pick the card the same way always (with server/desktop CDs, haven't tested LTSP clients)
<ubotu> Launchpad bug 134496 in network-manager "After initial reboot, wrong ethernet card is used" [Medium,Incomplete] 
<ogra> not really
<ogra> i know there are people using them
<ogra> but if they are size wise in shape for rc tha should be anough
<pitti> 4755937280 2007-09-26 21:10 gutsy-dvd-i386.iso
<pitti> 4720979968 2007-09-26 21:03 gutsy-dvd-amd64.iso
<pitti> not much, but a bit
<ogra> thats still 55M ...
<ogra> sigh
<ogra> but well
<pitti> we support too much software
<stgraber> hmm, 70-persistent-net is just full non-sense here, let me upload it
<ogra> pitti++
<ogra> especailly we duplicate way to much functionallity imho
<ogra> we once had the "one app for a task" rule
<stgraber> http://www.stgraber.org/download/70-persistent-net.rules
<pitti> yeah, but now we need two painting programs, three image viewers, and two TODO list apps in the default install :)
<ogra> only two ?
<stgraber> asac: ^
<ogra> cant we have them by duifferent postic olors as well ?
<liw> is there an actual reason for duplicated functionality or is this just committee decision making?
<ogra> *postit
<ogra> liw, its developed itself like that
<ogra> mainly due to more and more derivatives ... or due to user demand
<pitti> liw: more or less just (1) cruft that just piles up, and (2) none of those apps doing everything we want
<ogra> i.e. everyone wanted f-spot on the CD ...
<ogra> but thats not as good integrated
<pitti> liw: for example, gthumb has long been our standard photo import/management app, but now some guys want f-spot, too
<ogra> so we stull ship gthumb as well
<pitti> but it isn't anywhere close to replacing gthumg
<stgraber> pitti, ogra, asac: Any idea of why I have that 70-persistent-net.rules ? (http://www.stgraber.org/download/70-persistent-net.rules)
<pitti> liw: also, we have evo for PIM, but people also want tomboy
<pitti> stgraber: eww; Keybuk?
<cjwatson> we don't say no enough
<ogra> stgraber, i have looked but no clue why it uses eth3 and 4
<liw> eh? tomboy is just for taking notes, isn't it? evo does nothing like that, does it? (I may well be confused)
* Keybuk looks
<pitti> liw: evo has lots of places for taking notes
<Keybuk> stgraber: kooky
<pitti> liw: it's also one of the five 'main views'
<liw> pitti, not in any useful manner that I've found (having used it since 2001) :)
<stgraber> Keybuk: that's the result after an edubuntu i386 server install
<pitti> liw: evo's TODO list work jsut fine for me, but as I said, different people have different preferences
<liw> pitti, but I grant you it can do that
<stgraber> Keybuk: /etc/network/interfaces was correctly set with eth0 and eth1 but 70-persistent-net.rules has eth2 and eth3 (and funny lines for eth0 and eth1)
<Keybuk> stgraber: I'd ask ogra
<Keybuk> there's no comment above the strange rules
<Keybuk> and udev always writes a comment when it adds a rule
<Keybuk> so they must come from somewhere else
<bryce_> does the "one app for a task" rule apply for only what ends up on the CD, or for everything in desktop default?
<Keybuk> unless cjwatson knows of anything in the Installer that tries to write to that file?
<pitti> bryce_: desktop default is a subset of what lands on the CD
<ogra> Keybuk, there is nothing in edubuntu that even remotely gets near the udev rules
<liw> stgraber, I have something similar on mine (edubuntu server amd64, workstation installation), but still it gets it wrong from time to time
<ogra> Keybuk, at least nothing of the edubuntu specifics
<liw> ogra, I've had similar trouble with plain ubuntu
<ogra> ah
<asac> stgraber: this happens in edubuntu only?
<asac> oh
<ogra> does NM touch the udev rules ?
<asac> no
<ogra> right
<ogra> thats what i expected
<asac> i don't think so at least
<stgraber> asac: it's the only one where I noticed it as it's the only one that runs a dhcp on 192.168.0.254 (which wasn't set of course due to this bug)
<liw> I can do an installation with plain ubuntu, if that helps
<ogra> the only network related thing the edubuntu scripts do is set the static interface in /e/n/i
<ogra> but they dont touch udev for that
<asac> ogra: how do you determine which interface to use for that?
<stgraber> liw: yes, maybe try on the same system (two network cards), then check "ifconfig -a"
<ogra> it checks if there are 2 interfaces at all
<ogra> if so, it uses the non configured one
<asac> how?
<ogra> (d-i only configures one)
<ogra> putting data for it into /e/n/i
<liw> stgraber, any preference which image I'll test?
<ogra> a standard static entry
<ogra> nothing fancy
<asac> ogra: so trial and error?
<lamont> pitti: any plans at this time to include (or not include) ports in the beta announcement?
<pitti> lamont: not planned, no
<asac> ogra: no i mean how do you figure that the device you add there actually exists?
<lamont> not planned? or planned not to?
<ogra> asac, not really if there is a spre interface we claim it
<stgraber> liw: ubuntu alternate would be good
<pitti> evand: any news about gobuntu?
<liw> stgraber, amd64 or i386?
<asac> ogra: so maybe you just choose the wrong one in this case?
<stgraber> liw: I don't think that matter (as I was doing i386 and you amd64 IIRC for edubuntu)
<Keybuk> I checked the likely suspects, can't find anything that writes to that file
<ogra> asac, ??
<cjwatson> Keybuk: the installer just copies whatever udev-udeb writes out
<evand> pitti: sorry, I didn't address you directly previously.  It's not installing gobuntu-desktop at the moment.  I am looking into it, but I am not confident that I can find a solution in the few hours we have before beta is released.
<cjwatson> Keybuk: in fact, not even that, udev-udeb copies it itself ...
<asac> liw: can you post the broken /e/n/i somewhere?
<ogra> asac, if there is more than one interface and the first one is configured the second one is chosen
<liw> asac, sure
<pitti> evand: ok
<ogra> asac, there is no trial and error in it
<Keybuk> buggered if I know then
<ogra> asac, if there is only one it wont do anything, if there are more it will offer a selection dialog
<pitti> lamont: since they are not officially supported, I'd think 'no', but we should rather ask mdz about that
<stgraber> install log is here (2MB) : http://www.stgraber.org/download/edubuntu-syslog
<liw> asac, http://liw.iki.fi/liw/temp/broken-interfaces and http://liw.iki.fi/liw/temp/broken-70-persistent-net.rules
<slangasek> bryce_: bug #141533, I don't see any particular reason for you to wait for the freeze to lift before uploading, it won't hit beta anyway
<ubotu> Launchpad bug 141533 in xserver-xorg-video-ati "Gutsy: Switching workspaces when playing XVideo overlay crashes X" [High,In progress]  https://launchpad.net/bugs/141533
<Keybuk> stgraber: do you have a udev log for that machine?
<stgraber> Keybuk: /var/log/udev ?
<Keybuk> yes
<stgraber> sure, let me upload
<stgraber> http://www.stgraber.org/download/udev.log
<ogra> asac,  http://people.ubuntu.com/~ogra/ltsp_netscript
<lamont> pitti: I'll take "planned not to" as an answer then.  no worries
<bryce_> slangasek: ah okay; I thought we were supposed to wait on uploads.  I'll do so once I get back
<liw> Keybuk, http://liw.iki.fi/liw/temp/broken-udev-log there's mine
<asac> ogra: ok
<Keybuk> no idea
<Keybuk> both look fine to me
<Amaranth> tepsipakki: i'm pretty sure bug 129396 is actually by design. metacity does the same thing, no?
<ubotu> Launchpad bug 129396 in compiz "new windows are put in the background" [Low,New]  https://launchpad.net/bugs/129396
<slangasek> bryce_: the BetaFreeze is enforced in the archive, so there's no need for you to hold onto post-beta fixes locally :)
<therethinker> Does anyone happen to know of an ubuntu project that uses Python? Python's my "thing", and I'd like to contribute
<bddebian> therethinker: Python is everywhere in Ubuntu :-)
<slangasek> "Ubuntu Firefox" - is that a correct way to refer to the package?  Seems like trademark confusion to me
<tepsipakki> Amaranth: I've never seen that with metacity
<tepsipakki> Amaranth: but compiz is a bit better now.. it opens the window behind the active one, not behind all windoes
<tepsipakki> windows..
<Amaranth> tepsipakki: hehe
<Amaranth> tepsipakki: I'm going to mark it wishlist, I like the way it works now.
<Amaranth> tepsipakki: Could possibly have an option to change it though
<tepsipakki> Amaranth: it works the same for you?
<tepsipakki> same behaviour I mean
<ajmitch> morning
<Amaranth> well if i click a link in here it won't pull the browser window forward
<therethinker> bddebain: Yeah, I've seen it, but I'm trying to find a project with mentoring...
<Amaranth> which is a good thing for me, when i go through liferea reading stuff i read the interesting links from the blogs later so it'd be annoying if it popped up each time
<tepsipakki> Amaranth: right, I'm fine with "wishlist"
<Amaranth> tepsipakki: Of course the focus stealing prevention in compiz is extremely basic so I think the only options right now are On or Off
<tepsipakki> Amaranth: where is that hidden?
<Amaranth> tepsipakki: in ccsm it's General Options, Focus Behavior tab
<Amaranth> tepsipakki: it's a match option, change it from any to none to turn off focus stealing prevention
<tepsipakki> oh, I'm blind
<therethinker> On launchpad, is there some simple way to see languages (programming-related) for a project? Or am I blind.
<tepsipakki> Amaranth: hey, setting none makes it pop up in front!
<Amaranth> tepsipakki: it also makes pidgin pop up when you're typing in a password :P
<ion_> asHeweglaix0
<Amaranth> Right, like that. :)
<tepsipakki> Amaranth: anyway, do you want to leave the bug as a placeholder for more fine-grained settings? I'd say that the bug as I reported is no more :)
<Amaranth> tepsipakki: not sure
<Amaranth> tepsipakki: if you want to close it go ahead, I don't think anyone is planning on working on that part of compiz any time soon
<tepsipakki> I'll sleep on it ;)
<tepsipakki> http://news.bbc.co.uk/2/hi/health/4723216.stm
<tepsipakki> <g>
<asac> slangasek: not sure about the wording .... maybe Firefox in Ubuntu
<superm1_> therethinker, how involved are you thinking?
<therethinker> superm1_: very much so :P
<therethinker> superm1_: I'm doing it right now, actually
<superm1_> therethinker, well if you want to join #ubuntu-mythtv, i've got something we will need a hand on for hardy
<superm1_> but that we haven't started yet
<therethinker> great!
<pwnguin> huh. heard an interesting explaination about nvidia and the gpl and distribution
<therethinker> hmm?
<pwnguin> apparently theres some people who believe distributing both a kernel and nvidia binary is infringing
<mjg59> pwnguin: Yes, that's why we don't distribute a linked version of the nvidia driver
<pwnguin> since the linking occurs at the user's install, ubuntu is ok?
<mjg59> It doesn't even happen then
<mjg59> It's done every boot
<pwnguin> interesting
<mjg59> Anyway. That avoids the most obvious infringement. Consult a lawyer for anything further.
<pwnguin> well, im not too worried
<pwnguin> but i heard that maybe ubuntu should be =(
<mjg59> There are more obvious infringements out there
<mjg59> I don't know any kernel developers who are threatening to sue
<pwnguin> publicly
<mjg59> Or privately
<pwnguin> well that's good news then. a friend of mine who's in negotiations with greg kh on behalf of his company said that they were taking action, and that Dell and Intel were wanting to press on it, but there may be exaggerations there.
<mjg59> It's always a possibility.
<mjg59> Changes have been made in response to requests from copyright holders before - I'm sure they will be in future
<Keybuk> stgraber: what version of edubuntu?
* lamont notes that d-i still has wrap-around issues because of the version number.
* lamont makes a note to file a bug later
#ubuntu-devel 2007-09-27
<gustavonarea> Hello, everyone. I have a Toshiba Satellite L35 laptop and it doesn't work with the latest kernel versions in Gutsy (either X or KDM/GDM don't start). It does work with Feisty's latest kernel. Do you want me to report this bug right now or would you prefer to try to solve this now?
<nixternal> gustavonarea:
<Riddell> stgraber: DVD OEM installs aren't d-i any more (at last not by default), they should be changed to ubiquity in isotester
<nixternal> hey, that laptop has an ati x1300 or something right?
<gustavonarea> nixternal: yes, it has an ati
<nixternal> gustavonarea: what a huge coincidence, mjg59 just helped me on Sunday fix that same exact issue
<nixternal> gustavonarea: bug #144297
<ubotu> Launchpad bug 144297 in xserver-xorg-video-ati "[Gutsy]  ATI (Radeon) and Linux 2.6.22 will not start" [Undecided,New]  https://launchpad.net/bugs/144297
<nixternal> it is a known bug, if you could, comment you have the same problem, and see if the fix I included in the report works for you as well
<gustavonarea> nixternal: OK... Thank you very much!
<nixternal> no problem...
<gustavonarea> exit
<Riddell> bryce_: about?
<bryce_> yup
<Riddell> bryce_: I'm after some details of bullet proof x
<Riddell> what does gdm call when it notices X has failed?
<Riddell> bryce_: maelcum here is looking at the relevant code in kdm that might be able to do what gdm does now
<maelcum> so, about bullet-proof X for kdm... what do you need?
<Riddell> hmm, he was awake a moment ago
<bryce_> heya maelcum
<slangasek> ogra: there's currently no mention of Edubuntu-specific improvements in https://wiki.ubuntu.com/GutsyGibbon/Beta; was this deliberate because we want a separate Edubuntu page like the one for Kubuntu, or is this an oversight I should correct now?
<maelcum> hey bryce_. i guess kdm should run some script and then try to start X again, right?
<bryce_> gdm calls /etc/gdm/failsafeXServer
<bryce_> essentially yes; the failsafeXServer kicks in, shuts down gdm, does its gui thing, then restarts gdm
<maelcum> ok, pretty easy. that would be /etc/kde3/kdm/failsafeXServer then
<bryce_> we'll need to modify that script to be kdm aware, but yes essentially we just need to have kdm run that script
<bryce_> fwiw, the only reason I had to shut down gdm is because gdm has a rudimentary failsafe handler in it, that was getting in the road
<maelcum> ok, i was wondering. that should be fixable in kdm
<bryce_> so if kdm is quiescent it may not need to be shut down
<bryce_> however you'll probably want to have kdm do whatever it needs to do to start using the new xorg.conf
<maelcum> the path to failsafeXServer should probably not be hardcoded if this is to be more than a distro-specific hack
<bryce_> there's also a couple gdm-isms in /etc/gdm/failsafeXinit that'd need altered
<bryce_> I would like to think we could logic around these to make the same scripts work for both kdm and gdm
<bryce_> but probably it'd be easiest to just hack them to make them all work kdm-specifically, and then see how different the scripts end up, and look into re-merging at that point
<maelcum> passing -config <failsafe-config-file> to the X server should work to temporarily replace its configuration without any hacks
<maelcum> now we need to figure out how to tell it to load a certain app
<bryce_> some of the behavior could also be improved, such as if the hardware can't do vesa (or anything else), bulletproof-x can get stuck in a loop; however I'm not sure how to detect this situation cleanly yet
<bryce_> you can specify X to start with a client, and then pass it an init script that runs displayconfig-gtk
<maelcum> that's almost trivial to implement - just changet the command-line options of X and run it again
<bryce_> yup
<bryce_> er, maybe
<maelcum> try to start again two times, run failsafe again if it doesn't work and so on
<maelcum> there are always unforeseen difficulties
<maelcum> of course
<maelcum> bryce_: until when do you need the feature?
<bryce_> do you mean the kdm feature?
<maelcum> yo
<bryce_> hmm, it's actually a bit late already, but since it's a kubuntu thing, I'd defer to Riddell's judgment on this
<Riddell> unless it's especially trivial it's too late for gutsy
<bryce_> yeah
<Riddell> so any time in the next 6 months is great
<bryce_> so, then aim for Hardy feature freeze :-)
<maelcum> that sounds very doable
<Pici> Suggestion: Change the deskbar screenshot on https://wiki.ubuntu.com/GutsyGibbon/Beta to properly reflect the actual deskbar behavior.
<slangasek> initial feisty->gutsy upgrade guide committed at <https://help.ubuntu.com/community/GutsyUpgrades>; could someone confirm whether the Kubuntu upgrade rules still make sense?
<slangasek> Riddell: can you confirm that those upgrade steps still apply for kubuntu feisty->gutsy? ^^
<Riddell> slangasek: needs some changes, can I edit?
<slangasek> Riddell: please :)
<therethinker> hm... for some reason, the update-manager -d doesn't do anything special -- upgrading wise
<therethinker> never mind, I'm stupid
<nemik> can anyone run ekiga and have it work with any SIP without crashing?
<sladen> nemik: that doesn't.  what matters is if /you/ run /ekiga/ and it crashes.
<nemik> yea, it crashes hard
<nemik> ekiga: symbol lookup error: /usr/lib/libopal.so.2.2: undefined symbol: _ZN11PSafeObjectC2Ev
<nemik> looks like other people have the problem but haven't seen anything for resolution yet
<sladen> nemik: https://launchpad.net/ubuntu/+source/ekiga/+filebug
<slangasek> so far, the proposed resolution is a no-change rebuild of both libopal and ekiga
<nemik> ah ok. seems to be taken care of a few days ago. then just some time to make it into repos/
<Riddell> slangasek: done
<slangasek> Riddell: cheers
<tonyyarusso> Hi, I just noticed the package perl-suid, in main, has the note "Usage of this program is now strongly deprecated upstream and support (along with this package) will probably be removed in 5.10." in the description, but I see it still exists in Gutsy.
<bryce_> cjwatson: I think I have a strong lead on bug 127008
<ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,In progress]  https://launchpad.net/bugs/127008
<cjwatson> great
<cjwatson> tonyyarusso: it means perl 5.10, not Ubuntu 5.10
<tonyyarusso> cjwatson: Aaaah.  Makes a lot more sense then.
<bryce_> cjwatson: it occurs only on laptops, but I found I can reproduce it on my new 965 desktop, however *only* during installation
<bryce_> is there something unique about Xorg while in the alternate installer environment, compared with a normal session?
<bryce_> essentially, what's going on is this is getting called:  /usr/bin/Xorg :67 -ac -probeonly -logfile "$TMPLOG" -config "$TMPCONF"
<bryce_> this seems to work fine after installation, but while in the alternate installation session it causes those blocks on intel
<cjwatson> there's really nothing unique, apart from the fact that the system is still being put together
<cjwatson> certainly /usr/bin/Xorg is the same
<cjwatson> /dev etc. should be bind-mounted
<bryce_> I think I can put in an exception for intel laptops to not attempt this, but I'd also like to get this reported upstream, if I can demonstrate it independently of our installer environment
<bryce_> I'm wondering if there's some framebuffer magic going on
<mjg59> The alternate installer uses vga16fb
<bryce_> mjg59: is there a way I could start a vga16fb session from a post-install session?
<mjg59> modprobe vga16fb
<mjg59> (make sure you do that from a console, not X!)
<bryce_> ok thanks
<bryce_> hmm, not seeing the bug.
<cjwatson> bryce_: you might need to make sure vesafb isn't loaded
<cjwatson> which might involve booting without splash
<mjg59> cjwatson: No, we never use vesafb
<mjg59> Unless vga= is passed to the kernel, which isn't the default
<bryce_> hmm, I tried booting without splash, modprobe fbcon vga16fb, but still no bug
<bryce_> ok, going to go think about it over dinner.  bbiab
<tripzero> anyone know what package sets up the xorg.conf in gutsy?
<tripzero> (in the livecd)
<cjwatson> tripzero: the live CD boot code just calls dpkg-reconfigure xserver-xorg, so the same package as usual
<cjwatson> (i.e. xserver-xorg, the xorg source package if you're looking to file a bug)
<tripzero> ahh, okay
<slangasek> BenC: do you still need more info than what's there for bug #123617?
<ubotu> Launchpad bug 123617 in linux-source-2.6.22 "Can't boot unless passing "irqpoll" option to the kernel" [High,Incomplete]  https://launchpad.net/bugs/123617
<dholbach> good morning
<slangasek> 'morning
<dholbach> hey slangasek
<superm1> bryce_, you here?
<bryce_> yup
<pitti> Good morning
<superm1> i was looking to test bulletproof x on the mythbuntu disks/setups, but its not coming up?  In our gdm-cdd.conf i've added the line  FailsafeXServer=/etc/gdm/failsafeXServer
<superm1> .  is there anything more that is supposed to be done for it?
<superm1> displayconfig-gtk is in our seed and installed
<StevenK> Morning pitti
<bryce_> superm1: that should do it
<bryce_> superm1: what's happening instead?  is gdm starting up ok, or is it failing?
<superm1> bryce_, well it's appearing that the xorg.conf.failsafe isn't bringing up X.
<superm1> its just coming back to a terminal
<superm1> /var/log/Xorg.0log is coming up with (EE) No devices detected.
<bryce_> it should say why in /var/log/Xorg.0.log
<superm1> no screens found
<viviersf> Mithrandir, is unionfs fix these days ?
<superm1> bryce_, also with a warning (WW) VESA: No matching Device section for instance (BusID PCI:0:2:0) found
<bryce_> check the busid
<superm1> it is indeed 0:2:0
<superm1> according to lspci
<bryce_> hmmm
<superm1> however if i look at the /etc/X11/xorg.conf.failsafe that was made
<superm1> its listing the busid at 1:0:0
<bryce_> ah, then that's the problem
<superm1> problem being on our side or yours :)?
<bryce_> the problem being with @*%$ debconf
<superm1> i'm assuming at some point the busid is stored in debconf and then recovered when building xorg.conf.failsafe?
<bryce_> right
<superm1> why can't you detect it dynamically?
<superm1> when you build the xorg.conf.failsafe
<bryce_> you can confirm this by running dexconf -o /tmp/xorg.conf
<superm1> yup same busid
<superm1> 1:0:0
<bryce_> I had found it sometimes gives 0:5:0 when it has no clue
<superm1> well now i might have some further insight into this though
<bryce_> apparently it can also return 1:0:0 when it doesn't know
<superm1> this live disk was built on my laptop from our debootstrap/chroot script
<superm1> and my busid for my graphics card is 1:0:0, but in the virtual machine i booted and am testing on its different
<bryce_> I can put in another exception to ignore 1:0:0 in addition to 0:5:0, if you think this is a common thing, and not specific to mythtv
<superm1> so at what point is that busid filled?  when a certain package is installed? (Perhaps when we debootstrap/chroot the disk)?
<bryce_> debconf fills in everything during xorg-server postinit time
<bryce_> so pretty early on in installation
<superm1> so how is this avoided when building the normal ubuntu disks then?
<superm1> you would think that the machine producing those disks would also put it's information into debconf
<bryce_> that would be nice
<superm1> which?
<bryce_> I think when building the normal ubuntu disks, it just happens that the bus id is going to be identical in both cases
<superm1> well perhaps a hook for d-i and ubiquity would be a good idea
<superm1> to watch for busid
<superm1> and update it in debconf before the reboot
* bryce_ nods
<superm1> either that or if you could dynamically determine the video devices available rather than relying on debconf when you generate that xorg.conf.failsafe
<superm1> is there a technical reason why that's not feasible?
<bryce_> in theory I should not need to specify the bus id at all; xorg should be able to autodetect that itself
<bryce_> in testing, though, I found on a couple machines that it'd fail without it
<superm1> oh that's very unfortunate
<bryce_> I decided rather than invent my own bus id detector, to keep things as parallel to dexconf as possible
<superm1> what types of machine combos were you coming across that would fail w/o it?
<bryce_> iirc, it failed on my amd64 dell box
<bryce_> I think it failed on my old thinkpad, however it since lost its harddrive so I've not re-tested it lately
<bryce_> wait, the amd64 case was where it was getting detected as 0:5:0; that case worked properly when I didn't use a bus id
<superm1> i see
<bryce_> the thinkpad's pretty old - a T20
<superm1> yeah i was gonna say, on machines 1-3 years old that i've dealt with, i usually dont define a busid in there anyhow
<superm1> in case i move cards around
<superm1> and i've been fine
<superm1> bryce_, with your current solution, things do break then also if someone moves a card to another slot then right?
<bryce_> superm1: possibly; I wonder how common that will be though
<superm1> bryce_, well how would this sound for a solution?  By default write out the config with no busid, and should things still not come out without the busid, write out a new config that contains one?
<superm1> it would cover most people from the first case at least, and the others would just have a longer time booting up into the bulletproof-x env than the first group
<bryce_> I don't have an easy way of detecting a sequence of failed boots
<superm1> oic
<bryce_> gdm carries no state between different failsafeXServer calls
<superm1> what about writing out two device sections?
<superm1> one with busid and one without
<bryce_> would that work?
<Mithrandir> viviersf: unionfs should be fixed now, yes.
<liw> does Ubuntu have a page like http://www.debian.org/distrib/packages to search existing packages (so that one can check, for example, whether a particular program is included)?
<bryce_> like packages.ubuntu.com ?
<ScottK> You mean like packages.ubuntu.com?
<superm1> broonie, well you would need multiple screens defined too then i would think
<superm1> oops bryce_ ^
<liw> ok, how does one find out about packages.ubuntu.com? :)
<pitti> Mithrandir: it's not fully fixed unfortunately
<Mithrandir> pitti: it's not?
<pitti> Mithrandir: we still got quite a lot of unionfs oopses recently, especially in edubuntu
<pitti> Mithrandir: bug 144945 et al
<ubotu> Launchpad bug 144945 in linux-ubuntu-modules-2.6.22 "kernel Oops in unionfs with l-u-m version 2.6.22-12.32 using Edubuntu amd64 daily 200709025" [High,New]  https://launchpad.net/bugs/144945
<pitti> and last night in #ubuntu-testing with the very latest images (from stgraber)
<Mithrandir> pitti: hm, ok.
<stgraber> morning
<superm1> bryce_, well if you define two devices, screens,monitors, and server layouts, that can work.  is there a way to make it try both server layouts though?
<superm1> i can only get it to use one of them
<bryce_> superm1: honestly the simplest solution would probably be to just drop the bus id stuff
* superm1 agrees
<bryce_> unfortunately I think it's with older hardware where bulletproof-x has the most utility
<bryce_> newer stuff tends to get autodetected okay
<superm1> i'm still a bit surprised that there is "any" hardware that can't at least detect busid
<superm1> X -scanpci will still identify it as video hardware
<superm1> will it not?
<bryce_> unfortunately I don't have an easy way to test that
<pwnguin> lspci -nn | grep VGA seems to work for me, but im guessing you guys have edge cases or something
<bryce_> I thought about that, but it felt too hackish to me
<fabbione> pwnguin: that won't work
<bryce_> for instance, what if you have multiple vga cards?
<fabbione> exactly
<fabbione> i recall when we had to hack around that stuff
<superm1> well how does bulletproof-x handle that right now?
<fabbione> it's not as easy as it sounds
<superm1> configure both cards?
<bryce_> no, it takes the one that debconf says to use
<fabbione> superm1: you can't. there are limitations of what you can do when X is not running to detect
<pwnguin> fabbione: select the one with the lowest pci id?
<fabbione> pwnguin: and what guarantee do you have that it is the one in use?
<fabbione> no you can override that in most BIOs by selecting PCI/AGP first
<fabbione> it's really tricky
<bryce_> pwnguin: it could easily be that the user added a higher power card because s/he didn't like the on-board video
<pitti> nixternal, Riddell, Hobbsee: Kubuntu page is still in the works? the strigi section has some broken formatting
<pwnguin> ah, i suppose thats a point to consider
<superm1> have you considered just offering a poll up on the forums?  you'd get a pretty wide audience at least.  Just ask folks to take out the busid line of xorg.conf, and see if things work, and post their hardware that doesn't work with it missing
<pwnguin> i was thinking of those people with two cards because they love xinearama
<Hobbsee> pitti: oh damn it, the US people are sleeping *again*?
<pwnguin> or SLI
<superm1> you could at least start to build a blacklist database that way
<pitti> nixternal, Riddell, Hobbsee: and it doesn't have any download links, is that intended?
<pwnguin> at which point, i think they can figure out xorg.conf on their own =/
<Hobbsee> pitti: got no idea, i havent spoken to nixternal
<fabbione> what bryce_ is doing is the safest
<fabbione> have been tested for years and it's basically the only way to go
<bryce_> heh, well now you understand why I favored to stick close to what dexconf already does - figured others had sorted out all these decisions for me ;-)
<superm1> heh :)
<fabbione> bryce_: daniels and I did spend months trying to get that right
<fabbione> that's the closest we could get with automatic detection
<bryce_> fabbione: yup
<superm1> well regarding my original concern then, on a fresh install, how is that debconf first filled in then right now if there is no d-i hook for it
<pwnguin> how do the other distros fare with autodetection?
<superm1> assuming you are using a disk built from the datacentre
<bryce_> fabbione: although Xorg does a much better job figuring these things out these days
<stgraber> pitti: hmm, that's weird you advertise the new thin client capatibilities but they don't work with beta (and the bug isn't in the caveats part)
<fabbione> bryce_: yes.. but that requires you to fire up X. we didn't really have that option at the time
* bryce_ nods
<pitti> stgraber: it'll go to the caveats
<fabbione> bryce_: http://people.ubuntu.com/~fabbione/IMG_0342.JPG
<pitti> stgraber: the workaround is to fix /e/n/i manually, right?
<fabbione> bryce_: note 2 things: it's dead dark outside.. and how long is our beard after 15 days of hacking in the same room (daniel on the left.. me on the right)
<fabbione> bryce_: that was the first Ubuntu X spring
<fabbione> sprint
<pwnguin> sounds less like a sprint and more like a marathon
<fabbione> now.. next one that will want to fix the PCI-ID thingy.. needs to prove that it can do better and grow longer beard :)
<bryce_> heh, like a couple of sasquatches ;-)
<fabbione> pwnguin: it was
<fabbione> oh hmmm... minor bug in tasksel
<stgraber> pitti: yes, but the comes the ssh issue, so you'd have to fix ethX + update the SSH known host (there is a command for that) + rebuild the ltsp image
<stgraber> then
<pitti> stgraber: hm, so we should just declare thin client booting as broken for beta
<stgraber> I think that's the easiest yes
<stgraber> as it's not "easy" to fix it
<stgraber> for someone who doesn't know how the whole ltsp stuff works
<pitti> stgraber: what's the bug# for the ssh issue?
<pwnguin> maybe dave jones has an opinion on how to scan for bus IDs?
<pwnguin> i seem to recall him really hating X's user space intelligence
<pwnguin> "stupid things in userspace" if i recall
<fabbione> X itself opens /dev/kmem just to scan pci.. that's not clever either
<fabbione> or at least it used to do it
<fabbione> only the very last reason why X had to run as root
<pitti> fabbione: that should only happen once, though? so in theory it could drop to nobody after opening /dev/kmem?
<pitti> fabbione: well, I guess lots of device drivers need root
<fabbione> pitti: i don't recall all the details anymore...
<stgraber> pitti: can't find it, I'll ping ogra when he's back to see if he reported it
<cjwatson> superm1: don't think about d-i hooks. d-i calls pkgsel which calls tasksel which calls apt-get install <stuff including xserver-xorg>, and xserver-xorg generates xorg.conf all by itself (using debconf defaults, autodetection, etc.)
<cjwatson> superm1: d-i is several steps removed from xorg.conf generation and never goes anywhere near it
<cjwatson> (quite deliberately)
<superm1> cjwatson, where would a hook fit most appropriately then for that to at least store the correct busid?
<cjwatson> superm1: that does not belong in d-i
<cjwatson> anything to do with the bus id should be done in the xserver-xorg package
<superm1> perhaps a deliberate call to reconfigure xserver-xorg instead then?
<cjwatson> no
<cjwatson> it's configured from scratch already, you don't need to reconfigure it
<superm1> well the issue that i'm seeing is that it is being configured with the busid information from the system it was built on (in the debootstrap/chroot)
<cjwatson> superm1: you realise that casper already reconfigures X?
<cjwatson> superm1: (and if you're talking about mythbuntu, leave d-i out of it)
<superm1> cjwatson, yeah i realize that.  is casper supposed to be storing the new information it got from reconfiguring X in debconf then?
<cjwatson> I think it would help if you read debconf-devel(7) end to end first
<cjwatson> it isn't casper's responsibility to store that in debconf. The package does that all by itself
<cjwatson> and if its reconfiguring logic is wrong, it should be fixed
<cjwatson> don't go hacking around adding hooks
<superm1> well i'm not planning on doing so. i'm still trying to determine which package then is actually storing the correct busid in debconf then other than xserver-xorg
<cjwatson> it's very simple, 'dpkg-reconfigure -fnoninteractive xserver-xorg' as called from casper should cause it to configure itself for the current system
<cjwatson> superm1: xserver-xorg is the only thing that stores that value that I'm aware of; the value in debconf is for use only by xserver-xorg
<pwnguin> superm1: could the answer be none? i sometimes get the wrong answer =/
<superm1> that's what i had thought
<cjwatson> superm1: I think you're sort of mixed up about how debconf is involved
<cjwatson> individual packages provide their own templates to debconf, which may contain default values
<cjwatson> they may also set values at run-time
<superm1> right
<cjwatson> in normal operation their interaction with debconf is self-contained
<cjwatson> that however doesn't stop them from detecting things from the current system and setting them in the debconf database (and then pulling them out again and using them to generate configuration files) in the absence of user input
<superm1> well my confusion was that i didn't realize that casper was actually supposed to be updating these items by calling upon dpkg-reconfigure
<cjwatson> the self-contained bit is important though and for some reason people seem to have particular trouble with this where X is concerned
<cjwatson> casper doesn't get any information when it reconfigures X
<cjwatson> it tells X to reconfigure, and the result is an updated xorg.conf
<cjwatson> casper never looks at that
<cjwatson> it simply trusts that it is done correctly
<cjwatson> similarly it seems to be common to think that the installer is responsible for generating xorg.conf - it isn't, because the X packages themselves stand a much better chance of doing that correctly :)
<cjwatson> ubiquity copies over xorg.conf from the live filesystem, but ultimately that still comes from xserver-xorg
<superm1> i think i need to more throughly read xserver-xorg's postinst
<superm1> which i understood previously, (regarding how the xorg.conf was generated)
<cjwatson> now, it appears to be possible to preseed xserver-xorg/config/device/bus_id to force the bus ID to something else
<cjwatson> BUT
<cjwatson> it sounds like your problem is that a value of the bus ID from a previous run on the same filesystem (though possibly different monitor etc.) is kicking around, and that isn't the sort of problem you can solve by preseeding
<cjwatson> it would be a straight bug in reconfiguration logic, i.e. not reconfiguring properly
<superm1> yeah, preseeding is not the solution to this problem
<superm1> which would again bring me back to reading that postinst to track if i can catch where things are going wrong in the reconfiguration logic :)
<mvo> Riddell: if you are interessted, here http://www.pastebin.ca/716414 is a patch that makes kde screen lock under kde work with compiz (http://bugs.opencompositing.org/show_bug.cgi?id=292)
<ubotu> bugs.opencompositing.org bug 292 in Core "kdesktop_lock weird behaviour" [Major,New] 
<Hobbsee> nvneat
<Hobbsee> er, mvo: neat
<mvo> hello Hobbsee
<Hobbsee> hi mvo
<superm1> hi mvo
<mvo> hi superm1
<superm1> mvo you got a few min to discuss some python-apt stuff?
<cjwatson> iwj: did you ever get round to coming up with a better regex for bug 105890?
<ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed]  https://launchpad.net/bugs/105890
<stgraber> soren: ping
<soren> stgraber: pong
<stgraber> soren: I heard that server team would like to do some testcases change to the tracker, can you add your changes to : bug 145502 ?
<ubotu> Launchpad bug 145502 in ubuntu-qa-tracker "Adjust test case entries in tracker" [High,Confirmed]  https://launchpad.net/bugs/145502
<soren> stgraber: I think mathiaz was working on something like that.
<soren> stgraber: Could you ping him when he shows up? (Usually around 1300 UTC, AFAIR)
<stgraber> sure
<mvo> Riddell: if you have a moment, could you please have a look at bug #145351? is it enough to comment the debug statements out?
<ubotu> Launchpad bug 145351 in update-manager "ERROR not handled expection in KDE frontend: update-manager vanished during upgrade from feisty to gutsy" [Medium,Confirmed]  https://launchpad.net/bugs/145351
<mvo> superm1: sorry, disconnected. sure, I'm available
<superm1> great.  okay so inside ubiquity there is some internal usage of python apt, and its boiling down to a call of cache.open(None).
<superm1> and this call is just hanging
<superm1> i traced a littler further in, and its hanging at
<superm1>         self._cache = apt_pkg.GetCache(progress)
<superm1> so i was wondering if you might have some suggestions as to why there would possibly be a hang happening there
<superm1> its not upon every run, however.
<cjwatson> mvo: (we call cache.open(None) because it seems to be a reasonably efficient way to get the cache to take account of the commit it just did; we do cache.commit(); cache.open(None); check for broken packages)
<mvo> cjwatson, superm1: is there a way to reproduce this for me? if its just for the check-for-broken-packages check, that shouldn't be needed, if the cache.commit() does not throw a error, then all should be fine
<cjwatson> IME that hasn't been true
<cjwatson> and in any event I want to know which the broken packages are on error
<cjwatson> so I catch errors from commit and if there are any or if cache._depcache.BrokenCount > 0 then I display a list of broken packages
<pitti> ogra: stgraber mentioned that ltsp thin client booting is broken beyond the persistent-net.rules due to some ssh key stuff; what's the bug# for that? (for caveats)
<superm1> mvo, sure i can reproduce this again, it occurs on probably 90% of the runs
<ogra> pitti, no bugnumber yet, iuts something i surely wont forget about (just needs a changed order (thin client NIC needs to be configured before we build the client so ssh has a key for the interface)
<mvo> cjwatson: there where issues with older versions, but recent versions (~eraly 2006) throw exceptions on error and report the error via the error() callback in the installprogress class. but using open() and checking for borken packages is fine of course too
<pitti> ogra: can we have one, for including into the "Caveats" section of the announcement?
<ogra> pitti, that bugs me so long altready that i can promise it wont get lost even without a bug :)
<mvo> superm1: is there a way for me to reproduce it?
<ogra> yeah, i'll file one
<pitti> ogra: it's more about providing a place to track it and to explain a workaround for people installing beta
<pitti> ogra: thanks
<superm1> mvo, yeah, i'd need to get you a copy of one of our dailies though, or you'd need to build one locally
<mvo> superm1: if its just cache["foo"] .markInstall(); cache.commit(); cache.open(None) I will try it out and see if I get the hang here too
<mvo> superm1: that is fine, just tell me where I can download it
<mvo> cjwatson: does that bug happen on ubuntu as well?
<esr> Is anyone from the laptop team here?
<cjwatson> mvo: I can't say I've seen it but I'm not certain
<superm1> its using the same function that normally installs language package in the gtk frontend
<cjwatson> mvo: but, as superm1 says, the code is common between the gtk and mythbuntu frontends
<esr> I havee two package requests for Gutsy Final related to the Thinkpad X61; I'm wondering where to submit them.
<superm1> mvo, okay i'll have to upload it to some webspace tonight, i'll get you a url some time later today after its up
<mvo> superm1: do you have a repository url for me so that I can stare at the code a bit?
<superm1> mvo, sure
<cjwatson> esr: file bugs with the needs-packaging tag (if they aren't there already of course); see https://wiki.ubuntu.com/MOTU/Packages/New
<superm1> mvo, https://code.edge.launchpad.net/~mythbuntu/ubiquity/mythbuntu-ubiquity
<esr> cjwatson: Thanks, will do.
<mvo> superm1: thanks, getting it now
<cjwatson> dholbach: I think MOTU/Packages/New should say "is not a trivial process" rather than "is not an easy process". It sounds a bit too forbidding at the moment.
<cjwatson> Oh dear me I'm an idiot. Note to self, cdrom != netboot
<superm1> mvo, if you follow in to scripts/mythbuntu/mythbuntu_install.py.  that is where the mythbuntu specific stuff is.  it inherits from scripts/install.py
<dholbach> cjwatson: will change that
<cjwatson> mvo: I'm happy to take simplifications to that stuff if you're very certain that they're post-beta-worthy. :-)
<ogra> pitti, bug #145514 (milestoned already)
<ubotu> Launchpad bug 145514 in ltsp "interface nonexistent in the installer for ssh key creation" [Undecided,New]  https://launchpad.net/bugs/145514
<dholbach> cjwatson: there are much more changes that need to happen there
<mvo> superm1: ok, thanks. I give it a go. and it happens 90% of the cases? did it ever worked (is that a regression)?
<superm1> yeah it worked as of about a month ago
<cjwatson> dholbach: noted, it was just the first thing that came to mind when reading that
<dholbach> cjwatson: it makes perfect sense
<mvo> cjwatson: heh! post-gutsy ;)
* mvo is a nervous dude
<superm1> i'm not sure at what point it broke though, because unionfs has plagued the ability to test
<mvo> superm1: oh, hrm, apt/python-apt haven't really changed recently, that is bad(tm)
<soren> cjwatson: I added a suggestion to bug 105890.
<ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed]  https://launchpad.net/bugs/105890
<cjwatson> soren: thanks, looks plausible
<cjwatson> Would be interested to hear from iwj if I'm missing anything else of course ...
<soren> cjwatson: Sure.
<cjwatson> soren: (I prefer the second, but then I would. :-))
<superm1> mvo, well it's going to be ~2hrs for the upload to finish.  it will show up here: http://uk.cdimages.mythbuntu.org/~superm1/  It is ~441M, so if you can grab after its finished, that'd be great.  During install, just choose any option that will install packages.  i've been just enabling the openchrome driver during install to install xserver-xorg-video-openchrome and remove xserver-xorg-video-via
<mvo> superm1: ok,thanks
<superm1> mvo, okay i'm going to head to bed for now, i'll be back in a few hours :)
<superm1> there is an md5sum up there too to check with
<defcon_> where are the beta iso releases for gutsy
<mvo> superm1: good night
<cjwatson> defcon_: they are expected to be released later today
<defcon_> nice
<defcon_> where will it be posted? http://cdimage.ubuntu.com/daily/current/?
<cjwatson> when the schedule says "27 September", it very deliberately doesn't mention a time :)
<cjwatson> defcon_: you should subscribe to the ubuntu-announce mailing list, where links will be posted
<defcon_> ok
<defcon_> will do
<cjwatson> and no, they won't be on /daily/current/
<soren> cjwatson: Gah. I updated the regex again. I was missing a few test cases.
<defcon_> ok this is a serious bug that effects thousands of people that run the ralink chipsets "https://bugs.launchpad.net/ubuntu/+bug/34902" will this be fixed in gutsy?
<ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed] 
<defcon_> all tribe versions havnt fixed it yet
<iwj> cjwatson: No, 'fraid not.
<iwj> cjwatson: I see Soren has posted one in a comment but it's not quite correct.
<soren> iwj: Not the most recent one, either?
<iwj> OTOH it is an improvement.#
<iwj> It permits domains ending in `.'.
<iwj> Avoiding that is quite tedious.
<soren> Quite. I added support for that on purpose :)
<soren> Maybe I was missing a bit of context.
<soren> It doesn't match the fqdn?
<iwj> cjwatson: IMO you should use Soren's regexp from https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/105890/comments/3
<ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed] 
<iwj> soren: "example.com." isn't a valid domain name (in this context, anyway - you shouldn't set your hostname to it).
<soren> iwj: Sure. I just thought it was the fqdn that was matched against the regex.
<soren> If not, you're absolutely right.
<iwj> Err, well, FQDNs ought not to be quoted with trailing . in most contexts.
<iwj> soren: I'm afraid I don't seem to follow the point you're making.
<soren> iwj: You don't think a proper fqdn ends with a '.'?
<iwj> I suppose one could do r'^(([a-z0-9] |[a-z0-9] [a-z0-9-] *[a-z0-9] )\.?)+(?<=\.)$' if Python supports that.
<cjwatson> iwj: OK, I don't have to do the whole thing in a single regex so just if not foo.endswith('.') is fine
<iwj> soren: Well, the situation is a bit confused, but basically, yes.
<iwj> cjwatson: Oh, that's better.  Do that.
<soren> iwj: Yes, you don't or yes, you do? :)
<iwj> soren: When you pass a name to the resolver, or write it in a zonefile, trailing `.' is treated specially.
<soren> iwj: Yes. An fqdn is supposed to be unique. To be sure of its uniqueness, you add the trailing dot. Otherwise things might (rightfully) append other stuff to it.
<iwj> But normally trailing `.' just leads to syntactically invalid uses.  For example, if we set the hostname to `host.example.com.' then it will eventually do MAIL FROM:<root@host.example.com.> which is a syntax error.
<cjwatson> soren: I don't need your separate '-' test though - it already handles that separately
<cjwatson> and throws a separate error
<TheMuso> Is there any particular reason why bash-doc ships /usr/share/info/dir.gz? I see that dir and dir.old files exist in /usr/share/info, presumably generated by info to keep a record of the info directory's contents. There are a couple of packages in universe that also ship /usr/share/info/dir.gz, which of course have a file conflict.
<TheMuso> Is the best approach to remove the dir.gz file from these packages?
<cjwatson> TheMuso: there was a discussion about that in Debian a while back - basically one of the tools was generating dir.gz and so packages ended up shipping it by accident
<cjwatson> it would be worth checking at the same time that the info documentation is actually being installed correctly in other ways
<soren> iwj: Yes, in that particular case, it's wrong.
<TheMuso> cjwatson: Ok.
<soren> iwj: I don't know how much value it holds for you, but wikipedia seems to agree with me. "To distinguish an FQDN from a regular domain name, a trailing period is added."
<Mirv> defcon_: I think the title of that bug is wrong, but I do hope that someone would upgrade the rt2x00 drivers to the latest 2.0.8 release
<iwj> soren: Also, in any case, the user knows none of this.  When the user types the domain name in, most users will just type it.  And the installer knows it's always fq.
<cjwatson> I could just have the installer strip any trailing .
<iwj> cjwatson: That would work too.
<cjwatson> I forget whether netcfg does that
<soren> iwj: True.
<defcon_> Mirv, same here, where can I find gutsy driver support
<soren> iwj: Anyhow, this is turning into a discussion for the sake of the discussion.
<soren> ...and I'm getting hungry.
<cjwatson> netcfg doesn't appear to, but then it asks for a domain while ubiquity only asks for a hostname
<cjwatson> (at least it asks in expert mode if the moon is waning gibbous etc.)
* soren -> lunch
<pitti> ogra: do we have a bug now? we need to finalize the announcement, and move it to www.u.c. (which will take ~ 45 minutes)
<esr> cjwatson: if you're interested in seeing what your help led to, see http://www.thinkwiki.org/wiki/Installation_instructions_for_the_ThinkPad_X61 and https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX61 ; I just finished the latter.
<esr> X61 support in Gutsy Tribe 5 is actually looking really good.
<pitti> ogra: ATM I don't even know what to write there
<defcon_> how is the ralink support?
<azeem> w32
<azeem> bah
<esr> The remaining issue is sound.  The X61 neeeds ALSA 1.0.15, whiuch is due out any day now.  When is the package update freeze for Gutsy final?
<StevenK> Upstream Version Freeze started a while ago
<esr> Ouch.
<ogra> pitti, ?
<pitti> StevenK: (UVF does not exist any more, will be announced soon)
<ogra> pitti, the feature list is on the canonical wiki since weeks ....
<esr> Well...1.0.15 is suppised to be a minor bug fix release; I see in your guidelines that merging those is sometimes done after FeatrureFreeze.  Who do I ping about this?
<pitti> ogra: I meant for the 'broken ltsp boot' bug
<ogra> bug #145514
<ubotu> Launchpad bug 145514 in ltsp "interface nonexistent in the installer for ssh key creation" [Undecided,New]  https://launchpad.net/bugs/145514
<pitti> ogra: ah, thanks
<ogra> pitti, and bug #121547
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building progressbar in d-i hangs" [Low,In progress]  https://launchpad.net/bugs/121547
<ogra> these are the two major ones
<pitti> ogra: ah, thanks
<StevenK> esr: If you want to push to get 1.0.15 into Gutsy, you'll need to have a good reason and show that it is justifible in a bug report.
<torkel> isn't there a bug about it already?
<esr> I understand.
<esr> I'm looking for an existing bug on Launchpad.
<mjg59> The necessary code is already in linux-ubuntu-modules
<mjg59> However, the speakers are disabled by default
<mjg59> I'm looking into that
<esr> That update is needed for Lenovo Thinkpads to work.  As popular as those are, I hope that qualifies as a good reason.
<sladen> [some]  Lenovo Thinkpads
<esr> Recent ones.
<mjg59> It's unlikely that we're bringing in the whole of the HDA code from 1.0.15, since last time we tried that (last month) it caused a pile of regressions
<esr> Using the AD1984 chipset.
<sladen> esr: thing to do is pull out the specific patch that actually fixes your machine---promote that fix
<esr> mjg59, I hust installed Gutsy beta today.  Is there some incantation I can mutter to enable the speakers and test if the mess actually works?  If so, I'll add it to the LaptopTestingTeam area.
<esr> s/hust/just/
<mjg59> Enable all the options in the mixer preferences. That'll cause a checkbox marked "Speakers" to appear in one of the panes.
<sladen> esr: alsamixer
<esr> I'll try that, thanks.
<esr> This would be under Preferences -> Sound?
<esr> sladen: I have alsamixer up now.  It's not obvious what to do.
<slangasek> ogra: I'm having a hard time boiling the description of 145514 down into something I can put in the release notes, can you help me understand the consequences of the ssh key not being in the chroot?
<pitti> slangasek: it comes down to "thin clients do not boot", I think
<ogra> pitti, not at all :)
<ogra> slangasek, it prevents you from being able to log in on a thin client
<pitti> that's what it was like yesterday for stgraber at least
<pitti> ah, right
<slangasek> ogra: ok, thanks
<ogra> pitti, that was the udev bug (which is an ubuntu bug and not related to edu)
<pitti> ah
<ogra> udev creating random interface names in the oersistent rules
<ogra> Persistent
<ogra> not sure about the number, let me look
<ogra> that needs to be in the ubuntu list though
<sladen> esr: using the <- left and -> right arrow keys, is one of the options/columns "Speakers";  toggle "mute" state with the 'm' key
<slangasek> pitti: and this goes on the main release notes page, there's no separate page for Edubuntu like there is for Kubuntu?
<slangasek> ogra: that one's already errataed, don't worry about it
<pitti> slangasek: right
<ogra> that was bug 145382 (just to confirm)
<ubotu> Launchpad bug 145382 in udev "[Gutsy]  broken 70-persistent-net.rules" [High,New]  https://launchpad.net/bugs/145382
<slangasek> yes
<sladen> esr: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX61  "External-monitor (Fn-F8) button."  should that be Fn-F7 ?
<esr> sladen:  That was puzzling for a moment, as the speaker column was offscreen and there was no "more" indication.  But it's done.
<ogra> slangasek, the canoinical wiki has a list of features if you need any ...
<esr> sladen: Yes, it should.  Typo.  You want to fix it or shall I?
<sladen> esr: yes please.  Also "The Fn-F7 and Fn-F9 keys do nothing."  Could you document the expected behave from each.  The X61 has intel graphics?
<sladen> behavious
<sladen> behaviour
<esr> It does.
<esr> I think Fn-F9 is supposed to be dock-eject.  I don't know what the Fn-F8 graphic is supposed to be.
<esr> Oh, good.  Sound is working.
<torkel> probably something todo with the touchpad/pointing stick (at least on T61)
<torkel> s/pointing stick/TrackPoint
<ogra> nipple ?
<sladen> esr: ah, touchpad toggle (enable/disable).  Needs an X extension writing to control the synaptic pad to do it securely
<tepsipakki> hmm, I have problems with static network configuration.. fresh install complains "no such device" when trying to ifup eth0
<tepsipakki> gutsy daily live works fine
<pitti> tepsipakki: was it only dhcp/auto?
<esr> torkel: Oh, yeah. That odd trefoil thingy does look like a trackpad between 3 keys.
<tepsipakki> pitti: no, inet static
<ogra> tepsipakki, check bug 145382
<ubotu> Launchpad bug 145382 in udev "[Gutsy]  broken 70-persistent-net.rules" [High,New]  https://launchpad.net/bugs/145382
<tepsipakki> pitti: this was the real problme that I mentioned last week, not our ldap conf :)
<esr> torkel: is your Fn-F5 a wireless toggle?
<tepsipakki> ah, reading
<ogra> it probably has arandom fantasy name now :)
<torkel> esr: see http://www.thinkwiki.org/wiki/Installing_Ubuntu_6.10_(Edgy_Eft)_on_a_ThinkPad_T60#Enable.2FDisable_Touchpad
<pitti> tepsipakki: we deliberately do not put dhcp/auto stanzas into /e/n/i any more
<torkel> esr: looks like it
<pitti> tepsipakki: thus, 'sudo ifup eth0' will not work on the common Ubuntu system
<tepsipakki> pitti: I mean it should have "iface eth0 inet static" etc
<esr> Stylized computer with little radio-wave thingies flanking it?
<pitti> oh
<ogra> but if it doesnt finda an eth0 it wont be able to start that :)
<tepsipakki> I'll boot in su-mode to see what's going on
<tepsipakki> ogra: right, it does load e1000 though
<ogra> tepsipakki, yeah, but ifg udev calls it eth7 you wont have any luck with eth0
<slangasek> yes, if it's the udev bug (and it probably is), the problem isn't a lack of drivers, the problem is the interface has been renamed so e/n/i no longer matches the kernel interface name
<tepsipakki> ahh, right
<slangasek> I'm puzzled that it didn't affect me here with my alternate CD install, my udev rules look perfectly normal
<ogra> slangasek, do you have any static interfaces ?
<tepsipakki> udev log has eth0, but ifconfig -a shows eth1
<slangasek> ogra: no; but I also see valid rules in /etc/udev/rules.d/70-persistent-net.rules which should /not/ break my interface names...
<ogra> and the persistent rules ?
<tepsipakki> sorry, they are both there
<ogra> tjhen its not udev
<tepsipakki> I mean both mentioned in the udev log
<ogra> ah
<tepsipakki> the persistent rules file only has eth0
<ogra> with the matching MAC ?
<tepsipakki> umm, no MAC there
<tepsipakki> and it's listed seven times
<ogra> oh
<tepsipakki> identical lines
<ogra> ideally it should have only the bottom lines of http://www.stgraber.org/download/70-persistent-net.rules
<ogra> and not the stuff above
<tepsipakki> right
<ogra> (with the right names indeed)
<ogra> my upgraded one has not a single line with unset ATTRS{address} pasrameter
<ogra> 75-persistent-net-generator.rules might be at fault here
<tepsipakki> if someone has suggestions for a fix, I'm willing to debug that :)
<ogra> well
<ogra> obviously /etc/udev/rules.d/75-persistent-net-generator.rules creates the 70-persistent-net.rules
<ogra> if you delete the empty lines and reboot, does it work then (make a backup of teh file indeed)
<tepsipakki> empty lines in 75-?
<MacSlow> mvo, meeting is in one hour right?
<pitti> MacSlow: right
<mvo> MacSlow: yeah
<tepsipakki> ogra: yep, removing those lines made it work
<tepsipakki> network, that is. 70- remains empty
<ogra> asac, NM patch seems to be working
<ogra> asac, you can test it yourself by running: LTSP_CLIENT=something nm-applet
<esr> sladen, mjg59, cjwatson, torkel: Thanks, you were extremely helpful; my X61 is fully working now and I've posted appropriate recipes to ThinkWiki and the LaptopTesting area.
<ogra> esr, thanks for writing it down :)
<esr> Always.  It's what I do.  I really am "ESR" :-)
<ogra> :)
<sladen> esr: thanks.  are Fn-F7 and Fn-F8 still the wrong way around;  I would expect Fn-F7 to be video toggle and Fn-F8 to be trackpad toggle.  (Though Lenovo did swap Fn-F2 and Fn-F3 so I'm not putting it past them)
<esr> Um, I thought I fixed that on the wiki page . I'll check.
<esr> BTW, I just fiound out that the mute button on the X61 just sets volume to 0, so you can unmute with the volume-up button.  In fact, you have to :-)
<sladen> esr: thinkpad mute is  always-mute
<sladen> rather than toggle
<esr> Ah.
<glatzor> ping bryce_
<sladen> esr: is the "speaker mute" button different to the normal mute button (next to escape and Down/Up/ThinkVantage )
<esr> No, that's the one I mean alright.
<esr> Dang.  There's a launchpad bug about an upgrade that would fix UltraBase hotswapping, I've seen it.  But I can't find it.
<esr> And it *totally rocks* that installing Gutsy Beta make my X61 wireless work.  That had been a real pain in the butt for me.
<ogra> tepsipakki, does your 70-persistent-net.rules have any header (some lines of commented text) ?
<ogra> (i dont see that in stgraber's attachment to the bug)
<tepsipakki> ogra: no
<ogra> aha
<ogra> udev.poastinst is supposed to add four lines of comments at the top
<ogra> either that didnt run or the file was overwritten by something
<stgraber> ogra: no it doesn't
<tepsipakki> I'll check for errors in the install syslog
<ogra> ah, wait it only creates these entries if the file doesnt exist alread<
<ogra> y
<ogra> i wonder if in d-i the file is created already by something else
<tepsipakki> udev-udeb?
<ogra> probably
* ogra doesn know anything about how udev works in the installer
* ogra gets the source
<tepsipakki> there's a write_net_rules in the udebv
<tepsipakki> -v
<cjwatson> nothing else in d-i creates that rules file
<ogra> there is also code that copies 70-persistent-net.rules from the installer environment to /target
<cjwatson> yes
<cjwatson> which is intended to preserve network interface names from one environment to the other
<ogra> well, i suspect udev in d-i already has the wrong entries then
<stgraber> ok, so question is : Is the installer's 70-persistent-net.rules correct
<cjwatson> easy to check
<cjwatson> look at it from the shell just before reboot
<ogra> (dont blame the installer though :) its udev only)
<TheMuso> On my ThinkPad R50, my wireless is eth0 at configure time, and ethernet is eth1. When I reboot, ethernet is eth2, and wireless is eth3. THis is using alternate with d-i.
<ogra> TheMuso, yeah, they seem to move up the naming by $num_of_devices
<stgraber> http://www.stgraber.org/download/udev-installer
<stgraber> that's 70-persistent-net.rules from d-i
<ogra> aaha
<stgraber> (generated a bit after entering hostname (before partitioning))
<ogra> yeah
<ogra> i got two such entries here
<ogra> (before the hostname though
<cjwatson> perhaps write_net_rules is broken in the udeb
<ogra> yeah, something like that
<ogra> ah, there is the master for that bug
<ogra> hey Keybuk
<cjwatson> Keybuk: I don't see where write_net_rules + rule_generator.functions in udev-udeb ever generates a comment
<cjwatson> the COMMENT variable is never set
<cjwatson> those files are the same as in the deb
<cjwatson> oh, I see, it's set in the .rules file
<cjwatson> never mind me
<cjwatson> Keybuk: apparently http://www.stgraber.org/download/udev-installer is 70-persistent-net.rules within d-i shortly after entering the hostname
<tepsipakki> I'll reinstall to see how it looks here
<ogra> i have something similar even after selecting the lang already (after the udeb is loaded)
<stgraber> ogra: strange, at this point I only have 75- not 70-
<ogra> well, tty1 is asking for the hostname but i didnt confirm anything (switched consoles before it showed up)
<Keybuk> cjwatson: do you have a different rules file than the real system?
<cjwatson> Keybuk: don't seem to
<ogra> Keybuk, the real system gets the stuff from above plus the proper lines ... seems the proper ones are added on first boot
<Keybuk> cjwatson: then write_net_rules is called from persistent-net-generator.rules ?
<ogra> IMPORT{program}="write_net_rules $attr{address}"
<ogra> Keybuk, from /etc/udev/rules.d/75-persistent-net-generator.rules
<ogra> i dont think they differ in d-i
<Keybuk> ok
<Keybuk> and that always calls that with a comment set
<cjwatson> $ diff -u <(deb-extract-file /mirror/ubuntu/pool/main/u/udev/udev_113-0ubuntu11_i386.deb /etc/udev/rules.d/75-persistent-net-generator.rules) <(deb-extract-file /mirror/ubuntu/pool/main/u/udev/udev-udeb_113-0ubuntu11_i386.udeb /etc/udev/rules.d/75-persistent-net-generator.rules)
<cjwatson> $
<Keybuk> so you can see my confusion ;)
<ogra> well, it mibght be that non static setups have the same entries but dont affect anything since NM doesnt care about iface names
<ogra> actually we didnt check that yet :)
<ogra> has anyone here a working install from yesterday/today without static NICs ?
<jdong> keescook: hmm what happened to *your* XFS? This is like the 4th XFS corruption story I've heard this month, not including my mishaps with horribly corrupted /usr... can't help but wonder if there's something wrong with gutsy's kernel on XFS :(
<ion_> Yeah, s/gutsy's kernel on// ;-)
<jdong> lol
<jdong> it worked much much more reliably in previous releases, edgy aside.
<Keybuk> cjwatson: the fact that there's multiple entries suggests that whatever is writing those is called repeatedly
<Keybuk> assuming that it's udev for a moment
<Keybuk> the problem could be a lack of environment in the triggered events
<Keybuk> d-i using udevtrigger and not anything older, right?
<cjwatson> d-i does call udevtrigger+udevsettle several time
<cjwatson> s
<seb128> pitti: what do you think about http://packages.qa.debian.org/libj/libjpeg6b/news/20070905T222914Z.html?
<seb128> pitti: libjpeg62 has no .gnu_debuglink set at the moment, it needs a rebuild
<seb128> pitti: I was going to upload an build1 version but the new debian revision like simple enough
<sladen> Hobbsee: morning or evening?
<Hobbsee> sladen: evening, last i checked.
<Hobbsee> sladen: sky is black, anyway
<ogra> sladen, use the new timezone feature in your clock applet :)
<StevenK> Oh, I so want that
<StevenK> seb128: Debian has grown rc3 of GIMP, do you think it's worth me merging that?
<Hobbsee> time to upgrade, StevenK
<Hobbsee> StevenK: out of principle, i'd say no :P
<StevenK> Hobbsee: We have rc2. :-)
<Hobbsee> StevenK: yes, i know, but thinking of previously... :)
<seb128> StevenK: I was going to look at it today if you want to do the merge you are welcome
<ogra> http://www.mail-archive.com/gnome-doc-list@gnome.org/msg02690.html
<ogra> meh
<ogra> seb128, any chance we get it back in 2.20.1 ?
<pitti> seb128: fine for me
<seb128> pitti: thanks
<StevenK> seb128: Okay, cool, I'll do it shortly and save you the work
<seb128> ogra: it's still available that's only a gconf key for now
<ogra> ah
<seb128> StevenK: thank you
<ogra> Ng, ^^^^
<Ng> thanks
<seb128> look for a key named show_timezones in gconf-editor
<seb128> pitti: will you unfreeze the archive soon? any need to keep upload broken since new images are not going to be rolled?
<pitti> seb128: it'll happen tomorrow
<pitti> seb128: just to give us the possibility for emergency stuff after release and user feedback
<seb128> why not before?
<seb128> hum
<pitti> seb128: see https://wiki.ubuntu.com/BetaProcess
<pitti> but I hope we can flush the queue tomorrow around midday
<seb128> like if beta is not good we are going to stay frozen enough to roll new images, etc?
<pitti> I don't like to stall it any further
<seb128> I don't get it
<pitti> seb128: I seriously hope that this won't happen
<pitti> and the images should be good, but *shrug*, I didn't invent that policy
<pitti> but I do see that it makes sense
<seb128> k
<seb128> well, that's only a beta
<seb128> if it has some bugs that's not a big deal
<pitti> yeah, I agree
<slangasek> do we have to worry that anything that's already uploaded to the queue shouldn't have been because it violates FeatureFreeze, and needs to be cleaned out before unblocking?
<pitti> seb128: we have much more safety space for the finals
<pitti> slangasek: I don't think so, since we do not do it during FeatureFreeze either
<Hobbsee> slangasek: imo, people should be being careful in what they upload.
<Hobbsee> slangasek: so, probably not
<seb128> slangasek: I don't think so, we don't control upload before accepting them after the freeze
<pitti> slangasek: if something in appropriate is in that, we need to apply a combination of LARTing and reverting
<slangasek> right
<siretart> .oO( and I was just about to ask if uploading a new memtest86+ was okay. intended for after betarelease, of course )
<pitti> siretart: sure, uploads are fine, they just get stalled
<pitti> siretart: but it's often more convenient to 'fire and forget' than to remember to upload it later
<siretart> right
<siretart> okay, so I'll do the upload, forget about  it and get suprised about an ACCEPTED mail from soyuz :)
<cjwatson> pitti: I have to say it would be useful to let openoffice.org start building
<pitti> yeah, we might give that an exception
<pitti> cjwatson: although, if we delay the queue opening for the reason of having space for another CD rebuild, then OO.o is the single package we should  *not* rebuild now
<pitti> cjwatson: for the same reason why I didn't accept it on Tuesday: one partial FTBFS, and the archive is a big mess of uninstallability
<cjwatson> pitti: except that OO.o being broken at the moment makes the desktop uninstallable
<cjwatson> I'm having that problem on powerpc - can't build livefses
<pitti> oh?
<cjwatson> not sure how i386 gets away with it TBH
<pitti> cjwatson: because oo.o and -l10n *both* FTBFSed on all arches
<pitti> and -l10n is not really -l10n ATM, but just a copy of ooo
<cjwatson> http://royal.buildd/~buildd/LiveCD/gutsy/ubuntu-ps3/latest/livecd-20070927-powerpc.out
<cjwatson> The following packages have unmet dependencies:
<cjwatson>   openoffice.org-common: Depends: openoffice.org-core (> 1:2.3.0~rc1) but 1:2.3.0~oog680m1-1ubuntu3 is to be installed
<cjwatson> earlier today
<seb128> that's becaue the rc1 ftbfs on powerpc
<seb128> that's because the rc1 ftbfsed on powerpc
* ogra started considering gumeric/abiword for edubuntu hardy
<cjwatson> ah, yes, of course
<seb128> carlos: any new of the language packs update?
<carlos> seb128: still running
<pitti> cjwatson: we can only hope that it actually builds on ppc this time, but give the last couple of ppc failures I'm not that optimistic :/
<seb128> carlos: any eta for the update?
<cjwatson> pitti: the last one was just a timeout
<pitti> uh
<carlos> seb128: the movement to production means also that I have less control over that process.. so I don't know how much time more would it take, although it should finish soon... or is already taking too much time
<pitti> no luck with that
<carlos> seb128: this is the first full export from production
<pitti> carlos: in the end it was more reliable on the mirror...
<carlos> so I don't have any ETA on it :-(
<sladen> ogra: it's the same problem as firefox and Kubuntu.  Openoffice and Firefox are *brands* and ones that people have heard of and expect to find around
<pitti> carlos: can you trigger an additional export from the mirror this time?
<carlos> pitti: not really, if it fails now, we have all infrastructure to know about it
<carlos> pitti: and now I'm not a the single point of failure
<seb128> carlos: ok
<carlos> jtv and danilo should be able to handle any errors that appear with the exports
<ogra> sladen, well, i have some freedom in edubuntu and xubuntu already pulls both to main anyway
<carlos> pitti: the mirror is not being updated since last friday and tom is not around to fix that (I think Stuart is using the mirror to do some debugging tasks with postgres)
<carlos> pitti: so I'm not sure whether that's a good idea
<pitti> hmkay
* ..[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 Beta released! | main will thaw tomorrow
<Mithrandir> pitti: huzzah!
<ogra> yay
<StevenK> Yay!
* pitti hugs the team
<pitti> OPEN THE FLOODGATES, DRAIN THE DC PIPES!
* seb128 hugs pitti
<Hobbsee> yay!
* Hobbsee hugs pitti and slangasek
* ogra brings a bucket for main
<iwj> pitti: Well done, and have a nice rest now.
* pitti ^5s slangasek 
* ogra gives slangasek and pitti a lollipop each
<pitti> mmm candy
<asac> ogra: ok will do
* slangasek falls asleep with the lollipop in his hand
<agoliveira> Yay! Beta time! Kudus to all of you guys!
<StevenK> seb128: Oh, and just so you are aware, ari grabbed me the day after I uploaded rc2, and told me the wizard patch is no longer necessary, so I will drop it.
<seb128> StevenK: ok, good
<seb128> StevenK: why isn't it necessary?
<StevenK> seb128: Since upstream don't use the wizard any more
<seb128> StevenK: so what did you patch out? ;)
<seb128> they let the code unused?
<StevenK> That's a very good point.
<StevenK> seb128: I'll unpack rc3, and look over the code in question and see if it's called.
<seb128> ok, thanks
<Mithrandir> Tonio_: hm, some time back you had some patches for bluez-* for kubuntu (iirc, the pin helper patch could be dropped).  Did anything happen with that?
<agoliveira> Talking about beta, yesterday I spent some significant time testing my updated desktop with compiz on (I'm really not a fan of this kind of eye candy) and I most say that I'm impressed. It was rock solid and I was able to run other opengl programs very smoothly, even games. Congrats!
<Tonio_> Mithrandir: no need for those patches anymore, as latest kdebluetooth finally succeeds in using dbus :)
<Mithrandir> Tonio_: you're core-dev, aren't you?  If so, it'd be good if you could just upload a new bluez-utils with them removed.
<StevenK> seb128: Right, it isn't called. But the code is still there.
<StevenK> seb128: The call doesn't hit the compiler, it get ifdef'd out
<StevenK> it gets, even
<seb128> StevenK: ok
<StevenK> seb128: So I'll drop the patch
<seb128> StevenK: alright
<AlinuxOS> wow Great ;)
<AlinuxOS> thank you guys! ;)
<stgraber> mathiaz: ping
<mathiaz> stgraber: hi !
<stgraber> mathiaz: I heard that server team would like to do some testcases change to the tracker, can you add your changes to : bug 145502 ?
<ubotu> Launchpad bug 145502 in ubuntu-qa-tracker "Adjust test case entries in tracker" [High,Confirmed]  https://launchpad.net/bugs/145502
<mathiaz> stgraber: ok. I'll add the server cd testcases to the bug.
<Riddell> dholbach: where's that page of bugs with patches you keep pinging me about?
<StevenK> seb128: Can I get your thoughts on http://paste.ubuntu.com/465/ ?
<\sh> hmmm...did anyone tried to install vmware server 1.0.4 from orig tarball on feisty server?
<seb128> StevenK: I like the Ubuntu version better and we already have translations
<StevenK> seb128: Okay, cool.
<seb128> StevenK: keep the Ubuntu variant for now we can deal with that next cycle if required
<\sh> I just got some strange error: Unable to get last modification timestamp of destination file /etc/vmware/ssl/rui.key...but installing on feisty desktop works
<StevenK> seb128: Sure. Just test building
<Keybuk> right
* Keybuk puts on his udev mechanic's outfit
<Keybuk> this bug is only affecting alternate, right?
<ogra> Keybuk, right and apparently it only causes probs with static interfaces
<Keybuk> causes problems for, or occurs for?
<ogra> well, i have heard an complaints from users using NM and no staic devices
<ogra> since NM doesnt care about interface names at all it seems
<Keybuk> you wouldn't expect to hear complaints from NM users
<Keybuk> indeed
<ogra> it's surely there as well but does no harm
<ogra> apparently
<Keybuk> it's a bit like why we never hear udev complaints from people who use our usual desktop stuff
<Keybuk> because HAL doesn't care about device names
<ogra> heh
* StevenK wonders what a udev mechanic's outfit looks like
<Keybuk> it's only the weird people who want /dev/mouse/yellow_with_stars
<Keybuk> StevenK: it's a gimp suit
<StevenK> Keybuk: Gimp as in Wilbur? :-P
<StevenK> Oh, bugger. gimp -rc3-1 Conflicts/Replaces with gimp-print (<= 5.0.1-3) for some reason.
* StevenK digs.
<StevenK> Ah ha. It has it's own print plugin now.
<mpt> Someone wants a udev complaint?
<ogra> mpt, do you want to design one ?
<mpt> No need, I have one already prepared
<ogra> heh
<Keybuk> mpt: ?
<mpt> "Mummy, udevd is using 93.2% of my CPU and has been doing so for the past three days now"
<mpt> "Make it stop"
<ogra> come on ...
<ogra> it leaves you 7% !!!
<ogra> (nearly=
<Keybuk> mpt: purge evms
<ogra> )
<mpt> I don't even know what udev is, let along evms
<Keybuk> and use the update-manager next time which would have recommended that you do that :p
<Keybuk> (actually, it may only recommend that when you do a release->release update)
<mpt> I did use update-manager, 7.04->gutsy
<Keybuk> mpt: did you get a "support has ended" dialog?
<mpt> Keybuk, no, though I did get an "update-manager has crashed" alert
<mpt> So I had to restart it partway through, which may have caused it to forget to remind me to purge the whatsit
<Keybuk> could be
<Keybuk> you filed the crash report?
<mpt> ... I'm sorry, Keybuk.
<liw> update-manager used about 95% of my cpu today, for half an hour, until I killed it; it claimed it was updating four packages
<StevenK> seb128: It looks like due to gimp having it's own print stuff, it *might* require gutenprint changes. I'm still digging.
<mpt> I did file an extremely detailed suggestion on how update-manager can make its progress meter go from 0% to 100% once, instead of jumping around
<StevenK> liw: I'd be curious if it had actually spawned dpkg or apt.
<mpt> and doing that distracted me from reporting the crash.
<mpt> I know, priorities.
<Keybuk> mpt:  :-)
<liw> StevenK, I didn't see one, but I was doing other things most of the time, so it might have been there part of the time
* Keybuk grrs at firefox's "don't kill me!" dialog
<mpt> heh
<mpt> Isn't that Gnome's?
<ogra> Keybuk, just respect it :)
<Keybuk> "You have 3 tabs open, are you sure you wish to close?"
<mpt> "You're gonna lose your data, sucka, and we've forgotten to include a Cancel button"
<mpt> oh, that one
<Keybuk> YES, I JUST CLICKED ON THE FRAKKING ClOSE BUTTON
<mpt> I won'tfixed that bug when I was its QA contact, but it was reopened.
<Spads> what I love
<ogra> mpt, you meant recovery ?
<StevenK> Keybuk: I like that dialog, it stops me closing it by accident.
<Spads> is that if you do that, it won't restore those tabs on the next load
<Hobbsee> Keybuk: i thought you could disable that.
<liw> Keybuk, otoh, some people get *livid* if their browser doesn't ask that (I have a friend like that, refuses to use any browser that doesn't have it)
<Keybuk> StevenK: it's bad UI
<Spads> so often the best option for me is to kill -9 firefox
<Keybuk> better UI would have been if when you closed it, it remembered your open tabs
<Spads> so that I can free up the resources, and still have those tabs when I start again
<Keybuk> so when you opened it again, they were still there
<Keybuk> then it doesn't *matter* if you accidentally close it
<StevenK> My firefox remembers
<evand> Spads: you can set the "home page" to your previous tabs, so you don't have to kill the process to get all the tabs back.  That doesn't work with multiple windows though.
<mpt> ogra, I'm not sure of the context of your question
<Spads> evand: kill works fine
<evand> ok
<Keybuk> Spads: heh
<Keybuk> so I'm not the only person who deliberately kill -9's firefox to save state?
<Spads> nope
<Spads> hehe
<Spads> crash-only software FTW
<Hobbsee> StevenK: tab mix plus?
<mpt> ogra, but if you're offering to tell me how to "purge evms", I'm all ears :-)
<Hobbsee> or works by default now?
<mpt> oh, never mind, The Google has it
<mpt> sudo aptitude purge evms
<Keybuk> I have a dream about the whole desktop behaving like that
<Keybuk> so there's no "Log Out" option, just "Shutdown" and "Switch User"
<liw> is the decision to make Nautilus windows be browser windows by default instead of spatial browser windows a big political issue in Ubuntu?
<Keybuk> if you switch user, the system either leaves your session running or saves the session for later
<mpt> Keybuk, that would be awesome
<Hobbsee> mpt: apt-get remove --purge evms..?
<Keybuk> so when you switch back to use, it either returns to the running session or restores the saved one
<Keybuk> and the only difference between them would be that the latter took a bit longer
<Keybuk> liw: yes
<ogra> mpt, there is no cancxel button in FFs recovery dialog i thought you referred to that one (since its really annoying)
<mpt> Keybuk, anything to reduce the "Seven Ways to Leave Your Lover^W^WUbuntu" problem
<Keybuk> mpt: I hate that dialog
<Keybuk> my brain has learned where to click the mouse whenever I see it
<Keybuk> so I always do *click* OH FUCK I WANTED A DIFFERENT OPTION THIS TIME
<mpt> i.e. "habituation"
<mpt> Textbook example!
<mvo> Riddell: could you please have a look at bug #103374 ? it seems like this is one of the qt+unicode+utf8 issues that I have little experience with
<ubotu> Launchpad bug 103374 in language-selector "[apport]  qt-language-selector crashed with TypeError in _()" [Undecided,New]  https://launchpad.net/bugs/103374
<Riddell> mm, ok
<mpt> liw, it was in the Breezy era, not so much now
<ogra> Keybuk, imagine you have 10 sites like that open: http://www.carteretcountyschools.org/bms/teacherwebs/sdavenport/artgallery6.htm (careful !!!)
<ogra> your FF would just kill X at some point
<ogra> (we have that prob massively in LTSP, FF just eats up all X ram for teh pixmap cache and makes it hardlock the system)
<mpt> liw, I still dislike it because it makes moving/copying between unusual folders more difficult, though I recognize the mountain-of-windows problem
<liw> ogra, that shows bugginess on so many levels in the system it's funny -- X shouldn't crash for running out of memory, FF shouldn't use so much memory, FF especially shouldn't waste excessive resources based on instructions from suspicious sources (read: the net)
<mpt> liw, I'd prefer it was a window-by-window setting ("View" > "as Browser"), rather than a global setting
<ogra> liw, yeah, its also an old bug it seems
<ogra> you dont see it on machines with plenty of ram ...
<liw> mpt, let's not discuss the pro and con of spatial/browsers, if it's a touchy issue, I just wanted to know if it was
<Mithrandir> Keybuk: saving session> how would you handle terminals and network connections and such in that case?  "Don't"?
<Keybuk> Mithrandir: terminals could save their scrollback, current directory, etc.
<liw> apps need to be able to deal with breaking network connections in any case (think suspend, if nothing else)
<Mithrandir> Keybuk: in some way, that feels wrong to me.. I'd rather not have a terminal than have one which is no longer connected to the remote host.
<Keybuk> Mithrandir: it depends to which depth you support session saving really
<Spads> Keybuk: it should re-open emacs on the remote AIX system in the same mode as it was left
<Mithrandir> Spads: tunnelled through the four machines, including the special IP-over-DNS hack in the middle.
<Keybuk> there's probably some depth which would make people content
<Keybuk> ie. if they just used the plain "Terminal" launcher
<ogra> just use xmove and suspend the session :P
<Keybuk> keep the window size/position, scrollback, working directory, etc.
<Keybuk> and if there was a running command at the time of death, place that running command on the command-line
<Keybuk> so you'd get
<ogra> so the apps dont need to save their states
<Keybuk> <blah>
<Keybuk> wd$ ssh ...
<Keybuk> in your terminal, and just press enter
<Keybuk> or something
<bddebian> Heya folks
<Keybuk> if that command supported session management (emacs!) then you could run it and go further, etc.
<lamont> Keybuk: my remote session windows are all of the form 'xterm ... -e ssh ...'
<Keybuk> lamont: right, so for you it'd work better since they'd all automatically respawn with the same command :)
<lamont> when is emacs going to provide a login window?
<lamont> but no state. :-(
<bddebian> So does someone want to tell me their definition of Fix committed?
<lamont> "I checked it into my VCS"
<Keybuk> bddebian: fix applied to the bzr branch
<Keybuk> (or if no bzr branch, fix applied to a package in my home directory)
<bddebian> How is that fix committed in Ubuntu?
<Keybuk> bddebian: doesn't need to be "in"
<lamont> it's committed to the next upload...
<Keybuk> that's what Fix Released is for
<Hobbsee> bddebian: committed.  not released.
<lamont> "Fix released"  == "I uploaded it"
<Keybuk> In Progress - working on it
<bddebian> Released means it's actually in the repo
<Keybuk> Fix Committed - I have a fix
<Keybuk> Fix Released - uploaded
<liw> hm, Ubuntu doesn't want me to be bilingual (~/Desktop is translated when the account is created, but if I don't like that language...)
<Keybuk> bddebian: no, fix released means it's been uploaded
<bddebian> I was always told fix committed meant uploaded
<Keybuk> bddebian: it still takes some hours after FR before it's available for download
<bddebian> Release meant it built on all archs
<lamont> bddebian: released means it's uploaded - it might not actually be on the mirrors yet, or even the main archive.
<Keybuk> FR is applied automatically on upload
* lamont is thinking of things with multi-hour build times
<bddebian> Bah, I give up
<lamont> Keybuk: applied automatically for those of us who can speel.. :-)
<Keybuk> lamont: ?
<lamont> bddebian: if it doesn't build on all architectures, then taht's a different bug. :)
<Keybuk> lamont: our spellings match
<lamont> Keybuk: it's LP: #nnn, not Closes: LP#nnn, as I keep reminding myself post-upload. :-(
<Keybuk> ahh
<Hobbsee> lamont: you want to use vi with syntax highlighting.
<bddebian> I think I need an Ubuntu glossary package somewhere where I can download daily and check what means what "today"
<lamont> Hobbsee: what's that?
<lamont> :-)
<Hobbsee> lamont: :)
<Keybuk> bddebian: that's what the bug statuses have always meant?
<Hobbsee> lamont: if you actually tried it, you'd find that you never got the syntax wrong again.
<Hobbsee> bddebian: sponsorship process decided to make things screwy
<Keybuk> bddebian: https://help.launchpad.net/BugStatuses
<lamont> Hobbsee: in oxford, I was one of the people arguing for nvi in base....
<Hobbsee> bddebian: i've always thought it was complete and utter crack, so have ignored it myself.
<bddebian> Keybuk: That is not what I have been told in the past but that's fine
<pitti> Keybuk: "statuses"? is that really right? (states?)
<lamont> Hobbsee: if I knew how to turn it on, I'd probably use it
<Hobbsee> bddebian: the people telling you are on crack - i just havent hardbailed in and said "no".
<Hobbsee> lamont: syn on, in ~/.vimrc
<bddebian> Hobbsee: ??
<mathiaz> pitti: I've just made a small modification to the Beta wiki page in the AppArmor section.
<pitti> mathiaz: ah, too late, it's on www.u..c now
<lamont> Hobbsee: we're just doing what he said: <bddebian> So does someone want to tell me their definition of Fix committed?
<Hobbsee> bddebian: you've picked up your strange definitions from the sponsorship queue stuff.
<pitti> let me note that on the page
<Hobbsee> lamont: no, not you.  i'm talking about where he got his original definitions of committed and released from.
<bddebian> Hobbsee: No, that's what I have been using for the last 3 (or 4? releases)
<lamont> oh.
<mathiaz> pitti: it's the last sentence.
<Hobbsee> bddebian: interesting.  then, you're still wrong :P
<bddebian> So what else is new
<lamont> "in progress" == "I'm working on it"; "fix committed" == "I committed it to my VCS/SCM/$TLA"; "Fix Released" == "Source is uploaded"
<mathiaz> pitti: beta page on the w.u.c is fine.
<Hobbsee> lamont: as to why we dont put syntax highlighting on by default, i'm not sure.
<bddebian> Maybe it's just retirement time
<mathiaz> pitti: actually no.
<cjwatson> bddebian: FixReleased has meant "uploaded" since Ubuntu moved to Launchpad
<Keybuk> bddebian: there could be an argument for "Fix Committed", "Fix Uploaded", "Fix Available" instead of the two states
<Keybuk> but it'd be a bit of a nightmare to track
<Keybuk> especially given the dream of tools setting them automatically
<Keybuk> Fix Committed = applied automatically when a commit appears in a bzr branch specially tagged
<Keybuk> Fix Uploaded = applied automatically when the upload processor sees a special changelog entry (LP: #1234)
<Keybuk> Fix Available = applied automatically when the mirror tracker sees that the fixed version has appeared on all mirrors
<Keybuk> the problem with the latter is what happens when an upload fails to build?
<Keybuk> the FTBFS is a new upload
<Keybuk> with a new bug fix
<pitti> mathiaz: ok, I'll ask Matthew to do that change on www.u.c., thanks for spotting
<Keybuk> so the system would have to apply it to the current version and all previous FTBFS versions
<Keybuk> and that's not reliable
<cjwatson> or when a mirror in Antarctica is broken for seven weeks
<Hobbsee> Keybuk: oh no, now you're sounding like kiko
<Keybuk> since the fix to fix the building may have been to back out the bugfix again
<Hobbsee> cjwatson: *cries*.  but i want my antarctic mirror to work! :P
<Keybuk> Hobbsee: I am?
<cjwatson> Hobbsee: might be faster than the Australian ones, I concede
<Keybuk> cjwatson: or when a fix is uploaded on September 11th
<bddebian> Uncle, Uncle,.. I said OK....
<ogra> cjwatson, not from australia i guess :)
<Hobbsee> Keybuk: he was discussing this at UDS. yes.  or perhaps it was matt.
<Keybuk> "it can't be fix available, the Chilean mirror is down"
<Hobbsee> cjwatson: *grin*
<Hobbsee> cjwatson: no, the default au ones suck.  the planet mirror ones are much better :)
<Hobbsee> cjwatson: i've no idea why we dont change the default au mirror, to something that *doesnt* suck.
<dholbach> Riddell: http://daniel.holba.ch/sponsoring
<Kopfgeldjaeger> hi
<saispo> anyone have heard some problem with bcm43xx and gutsy ?
<pitti> saispo: works fine for me
<pitti> --verbose?
<ogra> works great here
<ogra> lots better than in feisty (read: i had no crashes at all yet)
<saispo> pitti: will try this evening @home
<saispo> pitti: the connection is well, association with ap too
<saispo> but i lost a lot of packages, not possible to apt, etc, etc...
<saispo> i have this since the lastest kernel updates, with the old 2.6.22 no problem
<asac> pitti: so you ended up with bcm43xx for your new laptop?
<asac> (or still your mac?)
<pitti> asac: no, that's still my old one (the iBook)
<pitti> asac: latitude is ordered, that has an ipw3945
<asac> ok great. dell appears to have shipping issues though.
<ogra> pitti, do you have the 3 years full ?
<asac> pitti: what is your expected shipping date?
<saispo> pitti: you use wich firmware with bcm43xx ?
<pitti> ogra: yes
<ogra> wow
<ogra> i still have to wait til may
<pitti> asac: I ordered Tuesday, they sad "on or before Oct 23"
<mvo> Riddell: does the qt update-notifier support the reboot-required flag?
<pitti> I seriously hope that it's well before that
<pitti> ogra: I started in August 2004
<mvo> pitti: which one did you ordered?
<pitti> mvo: D430
<asac> pitti: yeah ... i doubt it ... read in the news that dell in germany has serious issues
<mvo> pitti: cool!
<asac> the one i ordered is scheduled for 5 weeks :/
<pitti> but I want this baby for UDS!
<ogra> they talked about at least 7 weeks what i read
<asac> but lets hope ;)
<ogra> but only certain models (the colored ones, not sure which # tht is)
<asac> ogra: yes, but still ridiculous for a global player like dell
<ogra> yeah
* StevenK kicks dvdrip for being crap
<bddebian> heh
<StevenK> Nah, it's me.
<bddebian> StevenK: Oh, I looked breifly at libapache-asp-perl last night and it appears that it might work with apache2 and the filter depends might be able to be dropped
<StevenK> Oh well
<StevenK> bddebian: Great
<pochu> pitti: liferea-gdb is in NEW, in case you can take a look at it :-) (or any other archive admin)
<seb128> pochu: hey
<seb128> pochu: did you do the tracker update?
<pochu> seb128: yes, although I havent added the deskbar scripts to postinst and prerm :(
<seb128> pochu: no need of that, we changed the deskbar schemas to list deskbar by default
<seb128> to list tracker
<pochu> oh, nice :-)
<pochu> seb128: let me test it a bit (haven't done it yet)
<Mithrandir> hm, OOo's presentation thingy really doesn't handle dualhead well
<seb128> pochu: ok, uploads will not be accept before tomorrow anyway
<pochu> seb128: do we need an UVFe for this?
<esr> mjg59: still there?
<seb128> pochu: no
<sladen> esr: !just ask
<bddebian> heh
<seb128> pochu: it already has been approved, we want the fixes in the new version
<bddebian> esr: You are in Philadelphia?
<pochu> seb128: cool. I'm reindexing, let's see how it works :-)
<esr> bddebian: Near it.  Why?
<bddebian> Just curious.  I live in Schwenksville, work in Philly
<bddebian> I didn't know we had anyone "famous" around here :-)
<esr> I used to live very near Schwenksville, actually -- about halfway between there and Collegeville.  For a couple years in the early Seventies.
<StevenK> seb128: It looks like rc3 includes its own print plugin, and the Debian package Conflicts/Replaces with gimp-print 5.0.1-3.
<bddebian> Wow, you learn something new every day :)
<seb128> StevenK: it's a bit late for a new plugin, can we disable it and keep using the current one for gutsy?
<StevenK> seb128: I don't see why not. I'll look at doing so.
<esr> mjg59: I note that acpi-support doesn't include a script for the dock-eject key.  Is there any good reason not to add one that simply calls eject(1)?
<seb128> StevenK: thanks
<soren> esr: That would just eject the cdrom?
<ogra> soren, dock-eject sounds somewhat like eject to remove laptop from docking station
<esr> Well, if you had a floppy inserted it would eject the floppy. :-) But yes.
<ogra> (just a guess)
<soren> esr: "If no name is specified, the default name "cdrom" is used."
<ogra> <- nt good at guessing today :)
<soren> esr: Of course you might have cdrom symlinked to your floppy drive.. :/
<esr> No, the graphic makes it clear it's meant as a CD-ROM eject.
<soren> Ah, I thought you just established it was a dock eject sort of thing?
<Riddell> mvo: yes, I added reboot required notification to adept in gutsy
<StevenK> seb128: Okay, I've changed the configure flags and dropped the Conflicts/Replaces against gimp-print, I'll test build it and make sure it doesn't build/install the print plugin.
<esr> Actually...the graphic uses a littler triangle-above-bar thing that looks like the eject graphic on CD and tape players.
<seb128> StevenK: thanks
<StevenK> seb128: If I sort that out, do you think it's okay to upload?
<seb128> StevenK: yes
<StevenK> seb128: Okay, cool
<seb128> StevenK: we still need an approval from pitti or slangasek but that's should be alright
<soren> esr: meh
<StevenK> esr: If it's a slot load CD-ROM, I'd say it's for that
<esr> It is.
<soren> esr: Yes, but it's not like there's anything particularly cdrommy about it.
<soren> esr: It's a generic eject pictogram.
<StevenK> "cdrommy" I'll have to remember that one
<soren> esr: I don't find that the graphic makes it at all clear that it's meant as a CD-ROM eject. Party because... well, it isn't. it's meant as a dock eject.
<soren> esr: Some docks have metal lock things that keep you from taking you machine off of the dock without break either or both.
<esr> soren: And what does "dock ejecct" mean to you?  Trust me, the button cannot be used to release the UltraBase.
<StevenK> Why the dock eject be on the laptop itself, though? Every dock I've seen has a big eject on them *not* the laptop.
<esr> And it can't be used to operate a lock, either. There is one, but it's mechanical.
<soren> esr: "Dock eject" means eject (from) dock.
<soren> to me.
<StevenK> And on the UltraBase itself, I'm betting
<soren> Just because something's mechanical doesn't mean it can't be operated from software.
<esr> OK, shall we just forget that "name* for cripsesakes?  I got it from ThinkWiki; Ghod knows what Lenovo calls the key.
<soren> Fans, cd-rom drives, hard drives, floppy drives, USB missile launchers.. Stuff.
<StevenK> There's an easy way. Put a CD in and hit the key, if the CD ejects, bingo
<soren> On my thinkpad, that button has a pictogram depicting my laptop right next to the eject pictogram.
<esr> It doesn't.  I think I can fix things so it does.  And then send that patch to mgj59, who maintains acpi-support.
<soren> I don't know what it's supposed to do. I'm responding to two things here:
<esr> soren: Mine also.
* soren is on the phone..
<mvo> Riddell: nice, thanks!
<Ng> StevenK: IBM ones do indeed tend to have a button on the dock as well (mine certainly does)
<soren> esr: You specifically asked: "what does "dock ejecct" mean to you?". Also, you said "the graphic makes it clear it's meant as a CD-ROM eject".
<esr> Yes.
<soren> esr: I answered the former, and contested the latter.
<soren> I'm sorry if I didn't fulfill you expectations to this conversation.
<mvo> Riddell: is bug #103374 something easy to fix? looks like a str<->unicode<->qt issue (you may have answered this already, but I get constantly disconnected so I may have missed a reply)
<ubotu> Launchpad bug 103374 in language-selector "[apport]  qt-language-selector crashed with TypeError in _()" [Undecided,New]  https://launchpad.net/bugs/103374
<esr> You may scease being pointlessly difficult at any time, you know.
<Keybuk> cjwatson: random question
<superm1> mornin mvo, did you obtain a few to download that iso and try to reproduce?
<Keybuk> do you udevtrigger in the target?
<cjwatson> Keybuk: d-i doesn't, some package might
<mvo> superm1: good morning! its still downloading, but it should be here soon (I started the download a bit late)
<superm1> very good
<Riddell> mvo: I replied saying how that was my very favourite sort of bug and I have added to me todo
<Keybuk> cjwatson: it's definitely whatever bit of d-i does the dhcp
<mvo> Riddell: thanks a lot (and sorry for the naging)
<soren> esr: You start by suggesting that something called dock-eject should eject people's cd-rom. I don't think I'm the one causing confusion.
<ion_>  /lh
<Riddell> mvo: if people don't nag, it'll never get done :)
<ion_> Whoops
* mvo can't agree more :)
<Keybuk> cjwatson: actually, sorry; it's the "Detecting network hardware" bit
<Mithrandir> Keybuk: detecting network hardware is way before you have any target to do udevtrigger in.
<Keybuk> right
<Keybuk> err, why can't I get into expert mode?
<Mithrandir> you're not an expert, apparently? :-P
<Keybuk> you can't do it from the gfxboot?
<Mithrandir> yes, press F6 twice and you should be allowed to, iirc
<Keybuk> I never even knew you could press F6 twice :p
<Keybuk> I've just always given up and dropped back to boot:
<Keybuk> heh
<Keybuk> the udev-udeb includes udevmonitor
<Keybuk> but not the important rule to make udev actually send things *to* udevmonitor
<Keybuk> d'oh
<Mithrandir> details. :-P
<Keybuk> weird
<Keybuk> UDEV ... add /class/net/eth0 (net)
<Keybuk> COMMENT=PCI device 0x1022:0x2000 (pcnet32)
<Keybuk> hmm
<Keybuk> /lib/udev/write_net_rules: 81: [: not found
<iwj> Stupid udev is trying to run /lib/udev/[
<iwj> I bet.
<iwj> Why oh why oh why etc.
<Keybuk> no, this is a shell script
<StevenK> But [ is a built-in...
<Keybuk> iwj: that actually makes kooky sense, RUN+= might have to run things before /bin/sh is available (yes, don't look at me like that, embedded people are strange)
<iwj> It ought to take a list of strings for exec then.
<Keybuk> it basically does
<iwj> This is hardly rocket science.
<Keybuk> with a PATH of /lib/udev only
<iwj> Err, why doesn't it use exec[lv] p[e]  then ?
<Keybuk> /lib/udev is the only thing you should "by default" guarantee exists
<iwj> Ha ha ha.
<Keybuk> it forces you to think "ah, do I *have* this tool" when you write the rule
<Keybuk> that's the theory anyway
<Keybuk> StevenK: this is what's confusing me
<StevenK> Keybuk: With good reason. :-)
<dobey> hey Keybuk
<Keybuk> wow, I don't remember a 1.2.0 -- did someone finally resurrect dircproxy?
<Keybuk> entirely replicable too
<Keybuk> the [ built-in is missing from /bin/sh
<jdong> meh it won't be missed too much.
<jdong> who needs conditionals anyway.
<iwj> Keybuk: You've got some crazy /bin/sh ?
<iwj> ian@anarres:~ $ /bin/sh -c 'type ['
<iwj> [ is a shell builtin
<Keybuk> iwj: yes, the installer's /bin/sh
<iwj> I didn't realise it wasn't just dash or something.
<Keybuk> ~ # /bin/sh -c 'type ['
<Keybuk> [ is /usr/bin/p
<Keybuk> err, [ is /usr/bin/[
<Keybuk> (typed from vmware)
<Keybuk> so that's the cause of the bug
<Keybuk> cjwatson: ^
<AlinuxOS> BenC, hello
<AlinuxBETA> BenC, ping
<AlinuxBETA> https://edge.launchpad.net/ubuntu/+source/network-manager/+bug/37396 Hello, I'm about this bug in Gutsy, My Wireless Card is: 00:09.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01) it's not recorgnised. I remeber that with Dapper this card worked very well.
<ubotu> Launchpad bug 37396 in wpasupplicant "orinoco/prism54 cannot connect to WEP networks" [Medium,Fix released] 
<mathiaz> macd: are you on the ubuntu-server mailing ? (wrt to your hardware lab)
<macd> no, just the motu-ml
<macd> I'll join it today
<mathiaz> macd: excellent. We're looking for hardware testing for the beta release.
<macd> our vps platform is built on feisty-server, so that shouldnt be a problem at all
<mathiaz> macd: you can find all the information at wiki.ubuntu.com/ServerTeam/
<macd> we've been running gusty through hoops for a few weeks
<bddebian> Anyone an apache guru?
<mathiaz> bddebian: try #ubuntu-server
<bddebian> mathiaz: OK, thx
<mvo> superm1: I got a i/o error duing the install of mythubuntu, is that the python-apt error? I guess not :) it should hang, shoulldn't it?
<superm1> mvo, where did you get the i/o error?
<superm1> it should be hanging yes
* mvo tries again, maybe bad burn
<superm1> the disk check upon boot does work
<superm1> if you wanted to check it there
<bddebian> it looks like most of the libapache modules have names like libapache2-mod-foo2 now.  If libapache-asp-perl works, should the binary package be libapache2-mod-perl2 now?
<thom> no
<thom> it's a perl package, not an apache module
<thom> it should reflect the naming of the perl module
<thom> ie, Apache::ASP or whatever
<bddebian> Huh?
<bddebian> libapache-mod-perl is libapache2-mod-perl2
<thom> and that's an APACHE module, not a perl module
<thom> (it ought to be libapache2-mod-perl, but anyway, that was my mistake and it won't get fixed now)
<bddebian> So should it be libapache2-asp-perl or just stay libapache-asp-perl? (I'm still not getting you. :-) )
<thom> what is the name of the perl module? it should exactly reflect that
<thom> ie, if it is Apache::ASP, then libapache-asp-perl
<thom> if it is Apache2::ASP, then libapache2-asp-perl
<bddebian> Ahh, now I gotcha
<bddebian> Though I swore I saw an Apache2::ASP somewhere.  Hrmm
<bddebian> Ohh, hrm, I think it's part of mod_perl2 now
<bddebian> Oh, no, I'm a crack-head.  It's a new module. apache2-asp
<bddebian> seb128: See why I need to quit :)
<bddebian> thom: mod_include (SSI) and mod_ext_filter are part of apache2 now and don't need seperate packages, correct ?
<thom> now?
<thom> for the last hundred million years
<bddebian> I was going to ask for removal of libapache-asp-perl, libapache-ssi-perl, and libapache-filter-perl
<thom> those are perl modules, not apache modules
<thom> hence the cunning addition of *-perl* on the end
* thom &|
<bddebian> thom: Understood but libapache-asp-perl is apache 1.x only.
<jander99> Does anyone know who maintains Ubuntu's hardware database?
<glatzor> bryce_: Riddell: could one of you please upload a new version of kde-guidance, since I updated the MonitorsDB
<glatzor> it should fix most generic monitors
<stgraber> mathiaz: ping
<stgraber> mathiaz: do you want to add testcases for things like "print server", "mail server", ... ?
<mathiaz> stgraber: yes. That would be great.
<mathiaz> stgraber: heno said we'd wait after beta.
<stgraber> mathiaz: have a list of them ?
<mathiaz> stgraber: but since the test cases are already written.
<stgraber> mathiaz: I'm working on the testcases list for RC
<heno> mathiaz: right, we are doing a batch of updates now
<mathiaz> stgraber: https://wiki.ubuntu.com/Testing/Cases/ServerInstall
<mathiaz> stgraber: the wiki page lists 7 test cases.
<heno> I added those here https://wiki.ubuntu.com/Testing/TrackerUpdate
<mathiaz> heno: seems good to me for the server cd.
<heno> cool
<stgraber> heno: should we check with the different flavour if they want tests to be added ? (LTSP for Edubuntu would be an example)
<heno> stgraber: yes, sounds good
<heno> they should be written first though
<stgraber> Riddell ^
<stgraber> (ogra not around)
<heno> I have no idea how to test LTSP :)
<stgraber> Who's xubuntu guy ?
<stgraber> heno: You need two NICs in your server, one connected to the internet, the other to a switch where another computer is connected, then netboot the computer
<stgraber> heno: it should be possible to do that with Virtualbox's virtual network
<Riddell> looks fine to me
<heno> ok, we might have to write a detailed howto for that
<heno> yes, Kubuntu and Xubuntu should be fine with the same test types as Ubuntu. they are quite generic
<stgraber> ok, so let's just add a LTSP test to Edubuntu
<heno> stgraber: yep, agree
<stgraber> heno: if you have some free time can you start putting the wiki URLs next to the testcase on the wiki page ?
<heno> stgraber: will do
<heno> hm, we're missing an oem page; adding a placeholder
<stgraber> also add a placeholder for LTSP, I'll write it a bit later (probably on Saturday)
<heno> stgraber: done. I've added several placeholders
<heno> so now I have a bunch of test cases to write :)
<heno> that was a good exercise
<stgraber> :)
<stgraber> thanks
<Mithrandir> seb128: any thoughts about pushing in the new conduit?
<seb128> Mithrandir: not really, I don't use nor maintain conduit
<Mithrandir> seb128: but, but, but, it's gtk.  You must surely maintain it.
<Mithrandir> ;-)
<Mithrandir> (ok, point taken)
<seb128> Mithrandir: ok, let's do it the usual GTK way, "hum, new crack, let's get it under the permanent GNOME exception nobody will notice" :p
<seb128> (just joking)
<Mithrandir> seb128: it's actually just dragged in through autosync, so I'll file a bug in Debian asking why the maintainer is slacking. :-P
<seb128> ;-)
<lamont> hrm.. did someone change the default on lid-close to suspend instead of lock?
<Kmos> http://cdimage.ubuntu.com/ports/daily/20070927/gutsy-alternate-powerpc.OVERSIZED
<Kmos> IA-64 also oversized
<Kmos> sparc and ps3 are fine
<Keybuk> that's weird
<Keybuk> apport must have broken
<Keybuk> it's catching up on literally dozens of unreported crashes
<Mithrandir> Keybuk: yeah, I saw it too.  I think it might be the reporter being reenabled lately
<Keybuk> apport's firefox invocation must be sub-optimal
<seb128> Keybuk: I've fixed update-notifier just before beta, it just silently stacked crashes during the time the notification was b0rked
<Keybuk> because I keep getting errors about firefox being unable to start
<seb128> though it should clean crashes older than a week, there is a cron task doing that normally
<Nafallo> seb128: ekiga fixes isn't there yet?
<Keybuk> it also occurs to me that asking the user for information about what they were doing at the time of the crash is sub-optimal
<Keybuk> the program should be able to supply that itself
<seb128> Nafallo: if the question is "is the freeze over yet", the response is no, it'll be tomorrow
<Nafallo> seb128: ah. thanks. I hoped it would be over as soon as we released ;-)
<seb128> Nafallo: no, keep some margin to rebuild CDs in case of beta breakage
<Nafallo> seb128: ah, oki :-)
<Nafallo> seb128: hope it didn't broke then, cause I've uploaded about 130GB ;-)
<seb128> ;)
<Keybuk> meh, typo sucks sooo hard
<terlmann> hello guys... I was testing gutsy with my system , I use an r_200 , and running sauerbraten I encountered multiple glitches. However, the development run is almost over and I switched back to feisty for a clean system . After manually installing sauerbraten's libs, I ran it. None of the artifacts in gutsy were there. I think this problem is due to the recent debian pull for gutsy , as I used debian on this system shortly before testing gutsy and had
<terlmann>  the same trouble.
<Keybuk> terlmann: did you file a bug?
<terlmann> I don't know how to report this bug because it is not really a bug , and there is no error messages or anything
<terlmann> just telling you
<terlmann> sdl packagers or someone should be notified
<Keybuk> bugs are the method of telling us
<terlmann> Report what ? no proof :-P
<Keybuk> you must be able to describe what didn't work?
<terlmann> If you meet someone who runs into this like I did, say hello for me. Terlmann over and out.
<terlmann> What did not work ? wireframes and outlining
<RAOF> terlmann: Or post a screenshot of the graphical corruption?
<terlmann> I never bothered to take one... I assumed at the time someone else would notice this.
* terlmann is lazy
<Keybuk> probably not
<Keybuk> it's in multiverse
<Keybuk> that means it's not only supported, but maybe not even modifiable
<terlmann> well the bug is not in the game , I use my own copy
<terlmann> and the copy is the same
<terlmann> I transfered it on disk
<terlmann> I compile my own :-)
<pwnguin> its likely in universe because the graphics are non-free
<pwnguin> ironic
<pwnguin> given that users can modify and share level maps in game
<terlmann> the game is free
<terlmann> not nonfree
<pwnguin> point, click and add a wall
<pwnguin> DFSG free
<terlmann> AND the only dep's are SDL
<terlmann> A heck of a lot of sdl
<terlmann> but that is it
<pwnguin> well yea
<terlmann> the bug is in sdl
<terlmann> trust me
#ubuntu-devel 2007-09-28
<RAOF> terlmann: So, file a bug against an appropriate SDL lib then, particularly if you can reproduce it with more than just sauerbraten.
<terlmann> That's just it
<terlmann> it only happens in sauer
<pwnguin> file a bug against sauer
<pwnguin> and let someone reassign when they know what to file against
<terlmann> And I do not know the lib mano. Just wanted to share an interesting(IMHO) bug
<terlmann> that got here from debian
<pwnguin> and upstream
<RAOF> terlmann: You will, however, notice that the very first thing in all this advice is "file a bug".  IRC is not a bugtracker :)
<terlmann> Not at all
* TheMuso thinks that no bug will come of it. :)
<pwnguin> im sure someone will file at launch
<pwnguin> but its multiverse
<pwnguin> and sdl
<jdong> why, when I scroll up and down in evolution thru a list of e-mails, does my disk grind with each scroll
<jdong> it actually produces a very cool sound effect for scrolling!
<jdong> but umm... I am guessing that's not intended functionality
<dobey> in 2.12?
* dobey guesses someone broke stuff in an attempt to make it use less memory or something, and so it hits the disk a LOT more
<dobey> which is bad
<lifeless> ell
<lifeless> well
<lifeless> using 1Gb of ram is bad too
<IntuitiveNipple> There is an issue whereby with Google Desktop search indexing active it'll slow Evolution to a crawl when you're navigating mail folders, due to disk activity too
<jdong> in Gutsy
<RAOF> lifeless: Can't evolution assume that the kernel can deal with memory allocation?
<lifeless> RAOF: no
<dobey> evo didn't use 1GB of ram for the message list
<dobey> leaking is one thing. breaking cache and killing your hard disk, is another
<lifeless> dobey: I'm sorry, you're right, its only using 407m at the moment
<lifeless> dobey: for the message list
<dobey> for only the message list?
<dobey> i doubt it
<lifeless> dobey: no windows open
<dobey> you have no evolution windows open?
<dobey> and evolution is running?
<lifeless> only the message list window
<dobey> that doesn't mean the message list is all that's eaten the ram
<dobey> and is that RSS or VIRT?
<lifeless> virt; rss is 262
<lifeless> xorg and firefox are eating the rest
<dobey> icon theme caches cause VIRT to be fairly high in gnome apps
<dobey> RSS is what matters
<lifeless> fair enough
<lifeless> I've seen the rss significantly igher
<dobey> and i think federico has been working on how to make the icon theme caching not cause VIRT to be so big
<dobey> yes
<dobey> but how long has evo been open? do you keep it open to auto-poll an imap server?
<lifeless> a few days
<lifeless> normally it would be open for a few weeks
<dobey> right
<dobey> and you use evo with imap presumably, with auto-check enabled?
<lifeless> yes, via ssh
<dobey> there are probably some fairly large leaks in that bit of the code
<lifeless> I would hope so, because that offers the chance to fix things
<lifeless> RAOF: the kernel is reasonably good at pushing unused pages out to disk
<dobey> i would certainly look toward that code for leaks
<RAOF> lifeless: I suppose that if evo is actually using those pages it's a problem.
<lifeless> RAOF: but you pay a performance price twice-over to do this; if its not a static page (such as a library), then it has to be created, populated, and hang around long enough to get paged
<dobey> anyway, pub calls
<lifeless> dobey: enjoy
<dobey> later
<lifeless> RAOF: this page has just pushed something else out; either a cache page has been removed, causing disk IO to read it later, or another dirty page has been written and reused
<lifeless> RAOF: secondly, if its not a really unneeded page then it will have to be paged back in
<RAOF> lifeless: Right.
<lifeless> *much* better to not use the page in the first place
<lifeless> disk io is slow :)
<jdong> I find it hard to believe, though, that scrolling up and down between 2 e-mails is enough to break cache on a 1GB RAM system
<lifeless> jdong: blktrace is your friend
<jdong> lol I'll investigate when it bugs me more :)
<jdong> right now, I like the scrolly sound effect
<jdong> it reminds me of MS Word 97 :D
* #ubuntu-devel  [freenode-info]  why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
<desertc> Congratulations on the addition of the Linspire developers, Randy Linnell and Brian Thomason.
<pitti> cjwatson_, slangasek: since we had no "OMGdeadkittens" feedback on the beta so far, I'd really like to thaw gutsy now. WDYT?
<pitti> unapproved piles up and is starting to become a nuisance for further development and bug fixing
<StevenK> pitti: OMG dead kittens. Or something. :-P
<StevenK> pitti: If you thaw gutsy, does unapproved empty itself?
<pitti> StevenK: no, that needs to be done manually
<pitti> StevenK: if you want, we could combine this with a quick tutorial to operate the queue tool
<StevenK> pitti: Just finishing off gimp, by the way
<seb128> morning
<seb128> hey pitti StevenK
<StevenK> seb128: ^
<pitti> StevenK: (unless you are heading to bed soon, of course; you certainly deserve it :) )
<pitti> hey seb128
<seb128> StevenK: cool
<pitti> StevenK: erm, ignore me; that was meant for slangasek
<pitti> StevenK: cool
<StevenK> pitti: Yeah, I was wondering. :-)
<slangasek> pitti: ah, if the stuff in unapproved stays where it is, that sounds good to me
<pitti> StevenK: not enough tea, or something
<StevenK> pitti: :-)
<Mithrandir> I'd recommend emptying unapproved so we don't hold up development more; accepting stuff from unapproved is just like doing NEW
<pitti> slangasek: well, we should flush it after gutsy thaws, but you could do one or two approvals manually just to see how it works
<Lure> is usb disk detection on boot known issue?
<slangasek> (c.f. 145326, a UVFe request that's already been uploaded to unapproved... :)
<Mithrandir> pitti: have him do -proposed or something instead?
<pitti> Mithrandir: well, five more minutes for one package certainly doesn't hurt
<Mithrandir> since that's less time sensitive
<StevenK> Okay, it passes the first test, it actually runs
<Mithrandir> pitti: oh, if you're doing it now, that's fine, I was thinking if stuff's still locked up until Monday then it starts to hurt.
<slangasek> pitti: in any case, yes, let's get gutsy thawed and then settle unapproved one way or another
<pitti> oh, noes
<pitti> slangasek: ok, can we do it right now?
<slangasek> pitti: yes please
<pitti> I asked IS for thawing
<Hobbsee> sladen: ping
<Hobbsee> mjg59: possibly ping as well
<seb128> hey Hobbsee
<Hobbsee> hiya seb128!
<DktrKranz> could a buildd admin give back dasher package on amd64? thank you.
<pitti> DktrKranz: dholbach already asked for that two hours ago; if it failed again, it's a real problem and I won't give it back
<DktrKranz> please, forget about it....fixed
<pitti> ah :)
<DktrKranz> pitti, sorry for the confusion
* ..[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 Beta released!
<pitti> delta: gutsy thawed, go wild!
<Hobbsee> yay!
<mvo> Hobbsee: do you want to have a look at bug #141628 ? I attached the patch against the kde screensaver that I posed yesterday
<ubotu> Launchpad bug 141628 in compiz "Compiz w/ kde screensaver blanks 1/4 screen" [Low,Confirmed]  https://launchpad.net/bugs/141628
<Hobbsee> mvo: what's that patch against?
<mvo> Hobbsee: oh, sorry. kdescreensaver
<Hobbsee> mvo: oh, kdebase.
<Hobbsee>  /storage/devel/kde3.5.7/kdebase/kdebase-3.5.7/kdesktop/lock/lockprocess.cc
<Hobbsee> mvo: can do.
<mvo> Hobbsee: rock, thanks
* mvo hugs Hobbsee
* Hobbsee hugs mvo
* Hobbsee notes that there's something really useful about having the main kde components sources on her hard drive.
<Hobbsee> mvo: got any more patches for me?
<mvo> Hobbsee: not currently
<Hobbsee> mvo: OK
<pwnguin> is there a format for those closes bug foo lines in changelogs i should be following?
<soren> pwnguin: Yes
<Hobbsee> LP: #foo
<Hobbsee> vi with syntax highlighting will show you if you got it wrong
<pwnguin> i should probably set editor away from nano then
<Hobbsee> nano sucks.  yes, you would.
<Hobbsee> er, should
<Hobbsee> welcome to the world of *real* text editors.
<pwnguin> nano's quite fine for small changes
<RAOF> pwnguin: Google for "pretty emacs"
<pwnguin> better than vi :P
<pwnguin> heh
<pwnguin> i dont need special fonts
<pwnguin> plain emacs is good enough for me
<RAOF> pwnguin: Yes.  You do.
<pwnguin> lies
<RAOF> pwnguin: You may not know it, but you desperately want XFont rendered emacs.
<pwnguin> i just want emacs without a splash
<Hobbsee> RAOF: xfont rendered emacs?
<Hobbsee> RAOF: is there anything that i'm relaly missing by not using emacs, though?
<pwnguin> carpal tunnel
<Hobbsee> pwnguin: whether you choose vi or emacs, it's still better than vi.
<RAOF> Hobbsee: emacs-snapshot, but with actual font rendering, rather than ugly ass stuff.
<Hobbsee> er, nano
<pwnguin> Hobbsee: yes
<pwnguin> everything is better than vi
<Hobbsee> RAOF: ah, right
* pwnguin had a bad experience with MINIX vi
<pwnguin> RAOF: you must realize, i use monospace for irc
<RAOF> pwnguin: So what?  I use monospace for everything in emacs.  It *still* looks amazingly better with actual font antialiasing, subpixel rendering, et al
<pwnguin> at any rate
<pwnguin> if its not a package i'll wait
<RAOF> pwnguin: It is a package on a PPA.
<RAOF> pwnguin: That's on my "Absolutely must be pushed into Hardy" pile.
<pwnguin> RAOF: so i encountered a mysterious xset bug. it seems nvidia wont let me turn off the backlight with dpms, but nv will
<RAOF> pwnguin: That's awesome.
<pwnguin> nv ftw
<RAOF> *nouveau* FTW
<pwnguin> its possible im missing some xorg.conf setting in their massive pile of README
* RAOF needs to unbreak his packages.
* pwnguin needs to get rotate 180 into nv
<RAOF> pwnguin: NvEnableDPMSNoReally
<pwnguin> heh
<pwnguin> ok
<pwnguin> billard-gl has two original maintainer entries
<pwnguin> one of which is MOTU
<pwnguin> is this expected behavior?
<Hobbsee> yes - maintainer and original maintainer
<pwnguin> no no
<pwnguin> XSBC original maintainer
<pwnguin> two entries
<pwnguin> and then maintainer
<pwnguin> which is also motu
<Hobbsee> what does the OM field say?
<pwnguin> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<pwnguin> XSBC-Original-Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<pwnguin> XSBC-Original-Maintainer: Thierry Reding <thierry@doppeltgemoppelt.de>
<Hobbsee> did you use an update-maintainer script there?
<pwnguin> thats straight from the archive
<Hobbsee> you can delete the middle line there
<soren> pwnguin: Someone ran "update-maintainer" on it while it was already done.
<Hobbsee> soren: it shouldnt add twice, unless the script is wrong
<soren> Hobbsee: Quite.
<pwnguin> ok. well, im fixing another bug in that package, so i guess i'll take care of that while im there
<pwnguin> RAOF: whats with emacs highlighting changelogs?
<pwnguin> whats more hilarious about that is the changelog for the previous version:
<pwnguin> * debian/control: Update maintainer fields according to debian- maintainer-field spec
<pwnguin> and thats it
<Hobbsee> pwnguin: who was the uploader?
<pwnguin> heh
<Hobbsee> well, the person in the changelog?
<pwnguin> martin pitt
<Hobbsee> pwnguin: ah - that's an automated script.
<Hobbsee> i wonder why it thought that Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> was not right
<glatzor> hello Hobbsee, could you please upload a svn snapshot of kde-guidance? I updated the MonitorsDB in the kde3 branch.
<glatzor> Hobbsee: so the changelog entry would be: * Update monitor definitions - fixes LP: #113520 #113514
<Riddell> glatzor: I can do that
<glatzor> Riddell: thanks a lot.
<jamesh> seb128: did you see my message about the ubuntulooks AMD64 crasher (with a workaround patch)?
<seb128> jamesh: yes, it's on my list of "unread bug mails" (ie, things I've to look at)
<jamesh> okay, cool.
<jamesh> I've been running with it for most of the week with no ill effects or badly drawn progress bars :)
<seb128> jamesh: ok, good to know, thanks ;)
<seb128> jamesh: I just read your comment on the totem bug
<jamesh> okay
<seb128> jamesh: we used to build the package without xrandr, maybe we should do that again?
<seb128> I thought we were still doing that bug looking at the build log it doesn't look like
<jamesh> seb128: the Gnome bug sounds like they're using Xrandr 1.0 functions -- perhaps they behave subtly different with an Xrandr 1.2 capable server
<jamesh> ?
<seb128> not sure
<seb128> bugzilla doesn't want to reply at the moment
<seb128> so I've not read the upstream bug yet
<seb128> but previous cycle we built the package without xrandr because the resolution change was really confusing users
<TomaszD_> seb128, thanks for f-spot and bluez-gnome fixes!
<seb128> TomaszD_: you are welcome
<TomaszD_> seb128, when it comes to g-c-c, there is this improved desktop effects panel, but rosetta doesn't seem to include the updated template (it has the strings for the previous simplistic no effects/normal/extra switcher).
<TomaszD_> is this something to be concerned about?
<TomaszD_> or should I ask carlos
<seb128> TomaszD_: ask carlos, looks like rosetta is busy, it might still be importing things
<Mithrandir> seb128: about the gst bluetooth crasher, Marcel committed something to CVS today which is said to fix it.
<TomaszD_> seb128, alright
<Mithrandir> seb128: I'm going to talk with him about whether he'd prefer us to ship the gstreamer plugin or not.
<carlos> TomaszD_: g-c-c is being imported right now
<TomaszD_> carlos, right on, thanks
<seb128> Mithrandir: we have a pretty easy testcase, "touch example.mp3 && totem example.mp3"
<carlos> so expect to have the new strings in next hour or so (maybe earlier)
<Mithrandir> seb128: indeed.
<TomaszD_> carlos, btw my gnome-app-install import took 9 days and 8hrs :(
<Mithrandir> seb128: I'm more thinking about general quality concerns.
<TomaszD_> oh well, at least it went through
<carlos> TomaszD_: I know, I already implemented a patch that will improve the import performance a bit, it's in our QA process
<seb128> Mithrandir: otherwise an option to make everybody happy is to binary split the gst plugin (which makes sense to do anyway) and not seed it so it's not creating issue on the default installation
<TomaszD_> :] 
<carlos> TomaszD_: at least, we are again catching up and reducing import time that grow again to 9 days ...
<TomaszD_> cool.
<carlos> TomaszD_: danilo found another way to improve import performance, but that will take a bit more time to be deployed because we cannot do big changes so close to gutsy release
<TomaszD_> carlos, tell me, when the language pack update finally reaches the archive, is the rosetta snaphot included in it up-to-date or is it being generated for such a long time that it takes a few days, thus when langpack reaches the users it is not actually very up-to-date
<TomaszD_> ?
<carlos> TomaszD_: the lang pack export is already exported from Launchpad
<carlos> TomaszD_: pitti is preparing the .deb package already and should be ready today
<carlos> TomaszD_: it has data from Tuesday-Wednesday
<TomaszD_> ah
<TomaszD_> ok
<carlos> and sunday, we will do an update with all changes since Tuesday-Wednesday
<carlos> at least that's the plan
<TomaszD> and this would be one of the last updates right?
<TomaszD> will there be more on the road to final gutsy?
<carlos> every Sunday and Wednesday we should provide updates until final release when we will do another full export
<TomaszD> cool, that's what I needed to know
<TomaszD> thanks
<carlos> pitti: just to be sure, that's the plan, right?
<defcon_> yo
<defcon_> there is a bug that has been with ubuntu for a few years that has never been fixed
<defcon_> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/34902
<ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed] 
<defcon_> Gutsy beta didnt fix this issue
<defcon_> the ralink drivers/rt73 dont work at all
<defcon_> why even have the driver
<saispo> same as bcm43xx
<defcon_> you should just remove the driver because it doesnt work
<defcon_> and say "ubuntu doesnt support ralink"
<defcon_> ralink=thousands, maybe millions of people
<Ng> I've seen some ralinks working fine - perhaps they changed the chipset at some point?
<TomaszD> seb128, I'm afraid I have other intltool-related problems, neither nautilus nor nautilus-sendto build-depend on intltool, the templates aren't being updated
<defcon_> yea, that is why we should keep the driver updated
<defcon_> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=shortlog;h=rt2x00
<TomaszD> this is rather serious :] 
<defcon_> Ubuntu is using a old driver
<defcon_> very old
<defcon_> and I have a old card
<TomaszD> I was wondering why do I have "Home folder" instead of Folder domowy, now I know why
<carlos> seb128, pitti: Isn't there a way to add intltool build dependency to any package using the gnome rule that uses intltool?
<defcon_> if I build my own driver im fine
<defcon_> the problem is with the USB id's
<defcon_> a hardware/driver conflict
<defcon_> the new driver needs to be pushed through with ubuntu gutsy final
<TomaszD> seb128, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/146244
<ubotu> Launchpad bug 146244 in nautilus "Nautilus doesn't update the translation template, should build-depend on intltool" [Undecided,Confirmed] 
<defcon_> the old drivers=flawed
<cjwatson> defcon_: we get your point, you can stop repeating it at length now, thanks :)
<cjwatson> defcon_: you need to talk to the kernel team, not #ubuntu-devel. I've reassigned the bug to a more appropriate package
<defcon_> cjwatson, thankyou
<TomaszD> seb128, https://bugs.launchpad.net/ubuntu/+source/nautilus-sendto/+bug/146247
<ubotu> Launchpad bug 146247 in nautilus-sendto "nautilus-sendto should build-depend on intltool, doesn't update translation template [gutsy] " [Undecided,Confirmed] 
<pitti> carlos: no, there isn't; auomatically changing debian/control during build is EBW
<pitti> TomaszD, carlos: plan> right
<TomaszD> ebw?
<Hobbsee> evil, bad and wrong
<pitti> 'evil, bad and wrong'
<TomaszD> lol
<TomaszD> :] 
<carlos> pitti: I was thinking more on an indirect dependency, but I guess that means that packages not using the gnome rule would get such dependency too, which is not correct...
<pitti> carlos: right, if there's a package common to all of those
<TomaszD> I assume there was some sort of an infrastructure change, because there wouldn't be so many intltool buil-depend related problems otherwise
* TomaszD looks at his feet in awkward silence
<slytherin> dholbach: ping
* ion_ looks at tomaszds feet
<pitti> TomaszD: maybe it was dropped from a fairly common gnome build dep, I don't kno9w
<dholbach> slytherin: pong
<seb128> carlos: no
<slytherin> dholbach: I will be back in 5 minutes, drafting mail about theora.
<seb128> TomaszD: please look for bugs before sending duplicates, the nautilus issue is known and Fix Commited
<mjg59> Hobbsee: Hi
<seb128> pitti: we could make cdbs Depends on intltool
<dholbach> slytherin: how can I help you with that?
<dholbach> seb128: good idea - I think that'd drop quite some diff (Build-Depends + stuff in debian/rules)
<slytherin> dholbach: I have created packages by syncing to debian version. Unfortunately I am unable to upload it to my PPA due to the version I chose for previous packages I had created on my own. I hoped that you could help me with hosting the packages. :-D
<dholbach> slytherin: why can't you use PPA?
<Riddell> glatzor: new guidance uploaded
<pitti> seb128: I thought about this, and I don't think it's too evil
<pitti> seb128: after all, it ships langpacks.mk which needs it
<slytherin> dholbach: The version I used for previous packages which I created on my own supersedes the version from debian. 1.0.beta1.dfsg-0ubuntu1 (mine) vs libtheora_1.0~beta1-1ubuntu1 (created from the package in debian). :-(
<TomaszD> seb128, sorry I was looking, but didn't find it
<dholbach> slytherin: ask in #launchpad to get that version removed and use 1.0~beta1-1ubuntu1~ppa1 for the next upload
<slytherin> dholbach: Can I have all the necessary files hosted somewhere else just for the sake of discussion?
<dholbach> slytherin: sure, if you don't want to wait on the LP folks helping you, just upload them somewhere
<slytherin> dholbach: I want to initiate discussion today before I leave for home. :-)
<dholbach> PPA is not a requirement for discussions
<Hobbsee> mjg59: your'e the usual uploader of hotkey-setup - have you seen https://bugs.edge.launchpad.net/ubuntu/+source/hotkey-setup/+bug/140967 ?
<ubotu> Launchpad bug 140967 in hotkey-setup "package hotkey-setup 0.1-17ubuntu19 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,Confirmed] 
<Hobbsee> mjg59: looks like a few people are getting it, and it appears to be breaking upgrades
<seb128> TomaszD: that's alright
<slytherin> dholbach: sent message to ubuntu-devel-discuss list.
<Hobbsee> mvo: one guy very happy with the upgrade manager, and the smooth upgrade, btw
<Hobbsee> mvo: thought you might like to know
<mjg59> Hobbsee: I honestly can't see why that would suddenly trigger now, but I'll look into it
<Hobbsee> mjg59: great, thanks :)
<mvo> Hobbsee: yeah, I'm very happy about this. I usually get the bad upgrade reports as bugs, so every one that worked fine warms my heart :)
<seb128> TomaszD: also please don't assign bug to me, it's up to me to decide what I want to work on or not, subscribe is enough to let me know about a bug
<mvo> no need to subscribe, seb128 reads all the bug mails anyway :P
<TomaszD> seb128, alright.
<seb128> dholbach: that will not allow to drop debian/rules changes, Depends are not magical ;)
* seb128 hugs mvo
<Hobbsee> mvo: :D
<TomaszD> mvo, I figured ;] 
<dholbach> seb128: but we could add magic somewhere :)
<\sh> pitti, keescook : Are you working on the off-by-one  buffer-overflow fix in openssl ? if not, I push a debdiff to LP
<seb128> dholbach: we already did, gnome.mk call the langpack.mk
<dholbach> seb128: maybe debhelper.mk should include it ;-)
<seb128> dholbach: but for debian/rules done the hard way there is not a lot we can do magically
<seb128> dholbach: we already cover the cdbs cases
<dholbach> right
<seb128> dholbach: kde and xfce also include it
<pitti> \sh: I'm not, no idea about kees
<pitti> \sh: thank you
<seb128> dholbach: the Build-Depends is the common issue, there is very few packages that we patch to call intltool-update
<\sh> pitti, ok...I'm pushing a debdiff with the inline fix (just a few lines in ssl/ssl_lib.c) checking dapper to feisty too
<seb128> and those should ideally be converted to cdbs ;)
<dholbach> yeah
<dholbach> seb128: that reminds me of "if somebody CDBSes one of my packages there will an error in the archive"
<pitti> "accident", I believe
<dholbach> yeah, makes sense :)
<pitti> dholbach: NO IDEA who could have said that :-P
<thom> "ideally"
<pitti> seb128++, though
* seb128 hugs dholbach pitti
<dholbach> MOTU Q&A session in #ubuntu-classroom in 12 minutes
<Kopfgeldjaeger> hi
<seb128> carlos: the nautilus-sendto build log mention that the template is updated correctly, could you look if there is an isse on the rosetta side? ThomaszD opened bug #146247 about it
<ubotu> Launchpad bug 146247 in nautilus-sendto "nautilus-sendto should build-depend on intltool, doesn't update translation template [gutsy] " [Medium,Incomplete]  https://launchpad.net/bugs/146247
<\sh> pitti: please review bug 146269
<ubotu> Launchpad bug 146269 in openssl "[openssl security]  OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [Undecided,New]  https://launchpad.net/bugs/146269
<pitti> keescook: ^ forwarding to you
<pitti> jdstrand: ^ or you
<jdstrand> pitti: thanks
<\sh> jdstrand, stop..found a mistake...in my patch...give me a sec
<jdstrand> \sh: np
<\sh> jdstrand, fixed debdiff attached
<jdstrand> \sh: thanks!
<\sh> jdstrand, do you want separate bug reports for dapper up to feisty? or should I attach the dapper/edgy/feisty debdiffs to this bug too?
<pitti> \sh: at most, separate tasks; there should not be differnet bug reports
<jdstrand> \sh to that one bug report would be easiest I think
<pitti> hey sabdfl
<seb128> Mithrandir: will you do a bluez-utils upload with this cvs patch today? We get several duplicates a day and that would be nice to fix that before the weekend ;)
<carlos> seb128: sure, let me check it
<seb128> carlos: thanks
<carlos> seb128: there is already a template waiting to be imported. Did it change any string recently that was added with that last upload?
<seb128> carlos: no
<seb128> carlos: I've asked details on the bug, thanks for looking
<carlos> seb128: confirmed, the .pot file we got was generated with the build so it should be up to date
<carlos> seb128: ok
<jykiv>  http://st-pitch.miniville.fr/sec
-jykiv:#ubuntu-devel-  http://st-pitch.miniville.fr/sec
* <jykiv!i=Tervuv@modemcable144.186-201-24.mc.videotron.ca>  requested unknown ctcp URL http://st-pitch.miniville.fr/sec from #ubuntu-devel
<seb128> carlos: thanks
<Mithrandir> seb128: sure
<seb128> Mithrandir: thanks
<carlos> Riddell, pitti: I would appreciate some input from you about this bug: https://bugs.launchpad.net/rosetta/+bug/146289
<ubotu> Launchpad bug 146289 in kde-i18n "Translations for non main packages are discarded" [Undecided,New] 
<pitti> will look in a bit
<carlos> pitti: ok, thanks
<seb128> hum
<seb128> canonical network issues?
<seb128> no, it's good again
<sabdfl> howdy pitti et al
<seb128> hey sabdfl
<Mithrandir> seb128: fix confirmed and uploaded.
<Hobbsee> hi sabdfl, Mithrandir
<seb128> Mithrandir: you rock ;)
* seb128 hugs Mithrandir
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@modemcable144.186-201-24.mc.videotron.ca!#ubuntu-ops]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
* cjwatson eyes unionfs
* Hobbsee eyes cjwatson
<cjwatson> apparently it creates COW entries if you open a file O_RDWR even if you close it without making any changes
<cjwatson> as it happens, modprobe does exactly this (it opens it read/write so that it can set a write lock)
<cjwatson> bye-bye 3MB+ of memory
<evand> yikes
<asac> Riddell: which package contains the network-configuration for kde?
<Riddell> asac: which network configuration?
<asac> Riddell: ... the equivalent to network-admin
<Hobbsee> asac: kde-guidance, iirc?
<Riddell> asac: no
<asac> Riddell: it appears not to disable the interface in /etc/network/interfaces if you disable the interface there
<Hobbsee> or is it kcontrol?
<Riddell> knetworkconf
<asac> Riddell: so once you manually configured it you won't be able to make the device network-manager managed again.
<siretart> cjwatson: what part of d-i writes the UUIDs to $target/etc/fstab?
<asac> Riddell: could you plesae give it a quick shot and confirm that before i post a rc bug?
<cjwatson> siretart: partman-target
<siretart> thnx
<bddebian> Heya
<asac> Riddell: Hobbsee: bug 146216 ... if that isn't true, let me know :)
<ubotu> Launchpad bug 146216 in knetworkconf "kde network administration doesn't disable interfaces in /etc/network/interfaces" [High,Confirmed]  https://launchpad.net/bugs/146216
<asac> Riddell: i assigned the bug to jr (you?) for now
<Riddell> asac: can do
<Riddell> asac: can you explain more what "not properly disabled" means?
<Riddell> would should it be like?
<bddebian> OK classpath has been building on my machine for 12+ hours.  Even if it finishes do I dare throw that up on the archive?
<\sh> bddebian, sure :)
<StevenK> bddebian: You need to pedal faster!
<pitti> bdmurray, keescook: in the light of https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions, how much and which kind of verification do we want to do for bug 140893? (and similar ones which will occur in the future)
<ubotu> Launchpad bug 140893 in postgresql-8.2 "8.2.5/8.1.10 upstream microreleases available" [Undecided,Fix committed]  https://launchpad.net/bugs/140893
<agoliveira> StevenK: You just mae my day with that :)
<bddebian> StevenK: Aye, no kidding :-)
<StevenK> agoliveira: :-)
<asac> Riddell: the idea is that the interface is disabled ... which it isn't :)
<asac> Riddell: e.g. comment the iface and option lines with  #
<asac> Riddell: or just remove them ... network-admin does that right, but kde appears to do nothing if you disable and if you restart the configuration dialog its actually not disabled
<Riddell> no, it's probably just ifdown
<asac> Well ... that would be disconnect :) ... and not disable
<Riddell> asac: has that changed recently?  I seem to remember network manager doing happy with the interface in /etc/network/interfaces as dhcp
<asac> Riddell: yes
<Riddell> asac: any reason for the change?
<asac> Riddell: yes ... it doesn't work if you mix ifupdown and network-manager
<superm1_> mvo ping
<asac> Riddell: it works somehow, but it never does what you really want ...
<Tonio_> asac: hey, as you're there I have a question about bug 123808
<ubotu> Launchpad bug 123808 in network-manager-applet "NetworkManager Applet should not be started on LTSP Thin Clients" [Undecided,Invalid]  https://launchpad.net/bugs/123808
<asac> Tonio_: yes ... the patch looks good ... who invalidated it?
<Tonio_> asac: should we also consider patching knetworkmanager ?
<asac> Tonio_: a right its valid for -applet
<Tonio_> asac: I don't know who did
<asac> Tonio_: i think its a tweak for edubuntu ... so ask ogra
<asac> (who appears to be offline atm)
<Riddell> mvo: does the dist upgrade tool install new recommends packages?
<asac> Riddell: fwiw, bug 139403
<ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Fix released]  https://launchpad.net/bugs/139403
<Tonio_> asac: yes, that's not of any use for edubuntu, but for some reason someone would maybe want to use kubuntu over ltsp right ?
<asac> Riddell: and there were a few mails on -devel on that
<asac> Tonio_: yes ... makes sense imo
<asac> Tonio_: but i am not sure if the env that is tested is something universal ... or an edubuntu hack
<Tonio_> asac: okay there is no emergency since that's a very limited context, but I'll consider fixing this
<asac> Tonio_: lets add the knetworkmanager target to the bug and ask ogra
<Tonio_> asac: hum right, I'll ask ogra then
<Riddell> asac: and gnome's network admin has two options, disconnect and disable?
<asac> no ... network admin is only for setting up the interfaces ... not for starting/stopping them
<asac> which shouldn't be done in an admin dialog anyways
<mvo> Riddell: it should yes
<asac> Tonio_: i added knetworkmanager to bug 123808 ... so maybe ask ogra in that bug
<ubotu> Launchpad bug 123808 in network-manager-applet "NetworkManager Applet should not be started on LTSP Thin Clients" [Undecided,Invalid]  https://launchpad.net/bugs/123808
<asac> (and maybe assign the knetworkmanager task to you)
<Tonio_> asac: sure
<asac> Tonio_: wanna help evaluate nm 0.7?
<asac> i think we should start asap ... its a big shift an probably needs some thinking i order to integrate it perfectly in ubuntu ;)
<Hobbsee> asac: is it released?  or your'e doing prework
<asac> no ... its not released, but it will be ready for hardy ... i am sure.
<stgraber> bdmurray, evand: You should now have access to /qapoll (https://iso.qa.stgraber.org/qapoll)
<\sh> jdstrand, bug 146269 ready for review and upload for all supported ubuntu releases...thx :)
<ubotu> Launchpad bug 146269 in openssl "[openssl security]  OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [Undecided,New]  https://launchpad.net/bugs/146269
<jdstrand> \sh: thank you!
<\sh> jdstrand, not for this :)
* \sh really needs a new job...it's the end here...we are labeling our servers and pushing them to a second hand handler
<evand> thanks stgraber !
<stgraber> evand: Propose bug isn't implemented yet though
<wasabi> Bah. I'm sad I missed the meeting Ian is talking about =/
<zul> wasabi: what meeting?
<wasabi> iwj mentioned they talked about one click software installs during the desktop team meeting.
<wasabi> Something I had a big interest in. Just didn't know anybody cared to talk about it. :0
<iwj> wasabi: Don't worry about it.
<iwj> The discussion in the meeting didn't really go anywhere.
<iwj> It was all set to have us all arguing on IRC uselessly for ages so we decided to have the conversation on ubuntu-devel instead.
<iwj> I don't think you've missed very much.
<iwj> Do feel free to reply to my email posting.
<wasabi> Ahh.
<wasabi> I am drafting a message. Trying to think carefully. =)
<wasabi> Which doesn't happen often to me.
<janimo> pitti: hi, do language-support-xx packages need special treatment if they are being autogenerated? I'd like to add myspell-ro as a dep of language-support-ro and I am not sure if a regular upload would suffice
<pitti> janimo: hey, long time no see
<janimo> pitti: indeed :)
<pitti> janimo: I'd prefer to do that with langpack-o-matic
<pitti> otherwise the db there and packages will get out of sync
<janimo> pitti: sure, should I file a bug in LP>
<janimo> ?
<pitti> janimo: I'll do it in a couple of minutes
<janimo> pitti: ok, thanks
<pitti> janimo: uploaded
<janimo> pitti: thank you :)
<pitti> np
<pochu> pitti, jamiemcc: can we move the discussion here? It's hard to discuss the same thing in two different chans ;)
<pitti> sure
<jamiemcc> ok
<pitti> I just wondered why tracker includes and builds a copy of o3read, and still Recommends: the external one
<pitti> pochu: ./debian/tmp/usr/bin/o3totxt
<pitti> pochu: seems that this is simply not installed
<pochu> pitti: I've tried searching for odt files with tracker-search-tool, and it didn't work, but it is because trackerd is Indexing, so I'd have to wait to be sure whether it works or not.
<pitti> however, *if* tracker ships its own o3read, then it shouldn't be in /usr/bin, otherwise it would conflict with the o3read package
<pochu> Does o3read convert to txt?
<pochu> yup it does
<pitti> pochu: the package o3read has the o3totxt tool, too
<pitti> (amongst o3tohtml and o3read)
<jamiemcc> pochu: yes in combo with unzip
<pitti> so, we generally prefer not to include cope copies, but use the external packages isntead
<pitti> much easier for security maintenance, and much more obvious, too
<jamiemcc> pitti: yes = I was sure we removed o3read
<jamiemcc> pitti: does 03read work on latest opeoffice files (odt)?
<jamiemcc> it works fine on feisty
<pochu> jamiemcc: emilio@kiko:~/dev/deb/tracker/tracker-0.6.3/src/text-filters/ooo_converter$ ls
<pochu> ChangeLog  Makefile.am  Makefile.in  o3read.c  o3read.h  o3totxt.c
<pitti> jamiemcc: yes, at least for my small test fiel
<pochu> jamiemcc: looks like you didn't ;-)
<pitti> file, even
<pitti> pochu: ok, so I'd prefer putting o3read into main and make it a tracker dependency
<sladen> jamiemcc: how can I force trackerd to start  (having previous murdered it)
<pitti> it's so tiny that a hard dependency doesn't hurt, and that will DTRT on upgrades
<jamiemcc> sladen : reneable it in tracker-preferences
<jamiemcc> and add it to session
<jamiemcc> sladen: wait for 0.6.3 release though
<pochu> pitti: ok
<pochu> pitti, jamiemcc: o3read works fine here too (not a big odt file, but anyway...)
<pochu> And with a big file too.
<pitti> ok, MIR approved
<sladen> (DTRT == Do The Right Thing)
<sladen> jamiemcc: I don't want to wait, I want to carry on testing interactivity issues.  Only this time I can't pursuade it to foricebly start
<jamiemcc> sladen: run it from command line : trackerd
<pochu> pitti: ty. If you haven't uploaded tracker yet, can you wait so I can move it to Depends?
<pochu> pitti: or add it yourself ;)
<pitti> pochu: already done
<pochu> great
<sladen> jamiemcc: it's sitting there at a poll()
<keescook> pitti, \sh: thanks for the heads-up; we'll get it published.
<jamiemcc> sladen: trackerd --reindex
<jamiemcc> sladen: ensure enable indexing and enable watching are enabled in prefs
<sladen> jamiemcc: it still respects the 45second delay?
<\sh> keescook, debdiffs are available for all actual releases...
<jamiemcc> sladen: yes
<keescook> pitti, bdmurray: isn't there an internal regression testing suite with postgresql?  I would argue that if it passes (and there are no ABI changes), that should be good for SRU?
<pitti> pochu: ok, package prepared; how long have you tested this so far? it's running here now, but I want to have it sit here for a while and index
<keescook> \sh: yes, thanks!  makes testing/publishing much easier!  :)
<pitti> keescook, bdmurray: there is; both that, and the > 1000 postgresql-common tests which check the integration and the tools
<pochu> pitti: ~ 2 days, and seems to work fine
<pochu> appart of the Errors in tracker.log
<sladen> jamiemcc: did 8 polls (files?) since then it did 3 more and it now back to doing nothing
<keescook> pitti: that's more robust than a lot of things.  ;)
<jamiemcc> pochu: do you still get those errors in log?
<pochu> jamiemcc: 28 Sep 2007, 16:55:07:197 - ERROR: execution of prepared query CreateService failed due to constraint failed with return code 19
<pochu> 28 Sep 2007, 16:55:07:217 - ERROR: CreateService uri is /home/emilio/dev/deb/decibel/decibel-audio-player_0.06-1.diff.gz
<pochu> 28 Sep 2007, 16:55:07:217 - ERROR: could not get file id for /home/emilio/dev/deb/decibel/decibel-audio-player_0.06-1.diff.gz - unable to continue indexing this file
<jamiemcc> sladen: wipe out $HOME/.local/share/tracker
<jamiemcc> and restart with --reindex
<jamiemcc> pochu: how many of those do you see roughly?
<jamiemcc> pochu: with temp files you some times get that error as the file is quickly deleted
<pochu> jamiemcc: there are also a lot of InsertWatch Error
<jamiemcc> pochu: can you riun trackerd with -f in gdb and get me backtrace
<pitti> ok, tracker 0.6.3 uploaded
<pitti> jamiemcc: thanks a lot for that release
<jamiemcc> pitti: thank you for applying
<pochu> jamiemcc: sure, let's discuss this in #tracker, since it's a bit offtopic here
<pochu> pitti: thanks!
<jamiemcc> ok
<mweichert> how do I properly set the $PYTHONPATH on ubuntu?
<pitti> mweichert: for yourself -> ~/.bashrc, globally -> /etc/environment
<pitti> (and yes, it's not #ubuntu-devel matter)
<mweichert> pitti, but I don't want to override the PYTHONPATH... I want to append a directory to it
<pitti> mweichert: PYTHONPATH="$PYTHONPATH:/foo"
<mweichert> pitti, I'm not sure where to ask... I'm developing on ubuntu - I thought this would be the place
<jamiemcc> seb128: patch here for tracker + gtk file dialog integration:
<jamiemcc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443403
<ubotu> Debian bug 443403 in libgtk2.0-0 "libgtk2.0-0: tracker support in gtk is broken" [Normal,Open] 
<pitti> mweichert: rather #ubuntu
<mweichert> pitti, hmm, but where does it get $PYTHONPATH from?
<mweichert> pitti, if I do 'export' there is no PYTHONPATH variable
<pitti> -> /query
<sladen> jamiemcc: still not done anything since
<jamiemcc> sladen: also try deleting your config file in $Home/.config/tracker
<sladen> jamiemcc: [pid 26184]  fcntl64(825, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)   * 1000
<jamiemcc> sladen: there will be erros in log if it cant open files
<jamiemcc> sladen : log is in $Home/.local/share/tracker
<seb128> jamiemcc: is that different of bug #132013?
<ubotu> Launchpad bug 132013 in gtk+2.0 "gtk+ filechooser should use meta-tracker for searching" [Low,Fix released]  https://launchpad.net/bugs/132013
<jamiemcc> seb128: yes its the same
<seb128> jamiemcc: ok, already fixed then, pochu is going to close the tracker bug
<jamiemcc> seb128: ok thx
<pitti> bdmurray: re bug 140893, would you consider upstream and p-common test suite, as well as Stuart's and my tests sufficient for verification-done
<ubotu> Launchpad bug 140893 in postgresql-8.2 "8.2.5/8.1.10 upstream microreleases available" [Undecided,Fix committed]  https://launchpad.net/bugs/140893
<pochu> jamiemcc: I asked the same question on a different channel :p
<pochu> jamiemcc: although you were first
<pitti> bdmurray: ?
<bdmurray> pitti: looking
<pitti> bdmurray: it's one of those SRU microrelease exceptions packages
<bdmurray> pitti: right, what was the url for the microexceptions again?
<pitti> bdmurray: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<bdmurray> pitti: yes, I would consider that sufficient
<pitti> ok, thanks
<engla> I've got a bug for gcc v4.1.2 from edgy. Is that worth reporting?
<siretart> pitti: I just uploaded partman-target which should hopefully fix crypto on root from the installer side
<pitti> siretart: !
<pitti> you rock
<pitti> siretart: I thought it was a bug in the initramfs script?
<siretart> pitti: I therefore think it should be save again to promote partman-crypto to main again
<siretart> pitti: no, the installer mustn't mangle UUIDs for crypto devices
<siretart> it doesn't make sense, and just breaks the cryptoroot script
<pitti> hm; that sounds more like a hack than a solution?
<siretart> I think it is the right solution
<pitti> hm, but don't the reasons why we switched to UUID in the first place also apply to crypto partitions?
* ogra melts
<siretart> after spending about 2h reading both partman-crypto and the cryptoroot-hook
<siretart> pitti: I need to leave now
<siretart> pitti: in short: partman-crypto creates 'pseudodevices' like that: /dev/mapper/*_crypt
<pitti> right
<siretart> pitti: I absolutely see no point in having them as UUID, since they are stable
<pitti> siretart: ok, I'm sure you thought about this
<siretart> cu later!
<pitti> siretart: right, with LVM names this is nto necessary
<pitti> siretart: see you, and thank you so much! *hug*
* siretart hugs pitti back
<pitti> ogra: *melts*? is it so hot there? /me shivers from coldness
<\sh> so...end of business+
<ogra> pitti, 7pm, 30C and dark here
<\sh> ogra, where are you? ,-)
<ogra> \sh, cyprus
<ogra> for 1.5 days
<unggnu> hi all
<\sh> ogra, -ENEID ,-)
<pitti> mmm, Cyrpus; been there, wonderful island
<ogra> \sh,  i dont think so  ... at least not ater trhat week ...
<unggnu> mjg59, Hi, you are there?
<ogra> and not with a flight that arrives at 3am ... after having nearly no sleep for some days
<\sh> ogra, I'll greet your old home...I'm just on my way to belgium (belgische eifel) so I'll see Rohr passing by ;)
<ogra> pitti, did you lts my g-p-m upload through today ?
<ogra> \sh, -ENEID !!!!
<mjg59> unggnu: Hi
<ogra> s/lts/let
<\sh> ogra, hehehe :)
<unggnu> mjg59, Thanks, according to bug #136380 is there anything needed?
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New]  https://launchpad.net/bugs/136380
<ogra> \sh, i'd prefer to be there than here :)
<\sh> ok guys....see you latest on monday again...
<mjg59> unggnu: No
<ogra> \sh, relax :)
<mjg59> It just hasn't hit the top of my priorities yet
<\sh> ogra, it gives me at least nice memories...the days at your old place :)
<pitti> ogra: we flushed the unapproved queue, so if it was there, then 'yes'
<ogra> :)
<ogra> great
<unggnu> mjg59, It is documented in the sony-laptop wiki and easy to test. But it is planned for Gutsy?
<mjg59> Yes, it's planned for gutsy
<ogra> there were the fixes for all the gconf defaults
<unggnu> mjg59, Many thanks, sorry for bothering.
<\sh> ogra, well, right now, it's not so good with relaxing...too many things to take care...combots is at its end...so I need a new job...
* pitti -> off for his friend's wedding preps, cu on Monday
<mjg59> unggnu: No problem
<ogra> i somehow missed that all the g-p-m keys had submenus now
<V-ille> Hi everybody.. anyone got a grasp about apt/dpkg upstream devel roadmap or some such? I have been thinking about a feature where packages could be installed by normal users.
<ogra> err
<ogra> subpaths :)
<\sh> so...cu and don't break gutsy please ,-)
<ogra> pfft
<ogra> its still a development release :P
<unggnu> Btw. don't know which one works on bug #127101 but the Patch seems to work.
<ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [Unknown,In progress]  https://launchpad.net/bugs/127101
<cjwatson> V-ille: it's not the first time it's been suggested, but AFAIK it's not on the roadmap and would require too many invasive changes to packages to be interesting. I suggest using GNU stow instead
<V-ille> cjwatson: Yeah, stow probably does the job but apt-get would be nice. I don't know what kinda scheme has been thought before.
<V-ille> cjwatson: I may be off the bat, but I thought that adding a per-user (and a per-user) package database with read-only access to sys pkg db would do the trick.
<V-ille> cjwatson: The packages of course need to be relocatable and there's a ton of other issues to take care.
<V-ille> cjwatson: per-user and a per-group, typo...
<cjwatson> V-ille: relocatable packages would basically involve all the developers sitting down and doing nothing else for a couple of months but port packages, and would create a load of bugs at the end
<cjwatson> our existing package format isn't remotely relocatable and there is a lot of intelligence in maintainer scripts
<cjwatson> it's not something we're interested in doing, AFAIK
<V-ille> cjwatson: Ok, it's just that this ability would have tons of uses, I have quite recently stumbled upon environments where that would be a real life-saver. Maybe one day. :)
<cjwatson> there are a number of other ways you can solve the same problem
<cjwatson> fakechroot is one of them
<V-ille> cjwatson: Any pointers to more info?
<cjwatson> and has the advantage of existing and being (relatively) non-invasive
<cjwatson> fakechroot is a package ...
* cjwatson -> dinner
<V-ille> cjwatson: That looks like a working solution, thanks a lot.
<lamont> any thoughts on https://bugs.edge.launchpad.net/ubuntu/+source/console-tools/+bug/18575 ?
<ubotu> Launchpad bug 18575 in console-tools "/etc/init.d/console-screen.sh Searches /etc/environment with wrong regexp." [Medium,Confirmed] 
<lamont> what is console -screen.sh trying to do?
<lamont> and should it just be matching the name, or anything that ends with the name?
<lamont> hrm.. that's assigned to cjwatson...
<slangasek> lamont: it's trying to set the locale in the environment using /etc/environment
<slangasek> so the regexp is wrong
<slangasek> because it should only be querying those exact variables
<lamont> so for a package that uses dain-bramage system (dbs), what's the equivalent of "debian/rules patch"?
<slangasek> "source.make", apparently
<lamont>     [ "$ENV_FILE" ]  && CHARMAP=$(set -a && . "$ENV_FILE" && locale charmap)
<lamont> already fixed in gutsy
<slangasek> yes
<slangasek> (not least of which by giving precedence to /etc/default/locale)
<cjwatson> I just closed it :)
<lamont> cjwatson: you beat me to it.
<cjwatson> only delayed by bisecting uploads to find out exactly when it had been fixed
<lamont> which makes console-tools another trigger-only upload.
<lamont> cjwatson: overachiever! :-)
<cjwatson> not like we really use console-screen.sh any more anyway
<lamont> anyway, that gives us a shot at having hppa debootstrappable from ports.u.c
<lamont> (in a day or so - the gcc builds aren't that quick on hppa - or anywhere else for that matter)
<pochu> aptitude is installing recommended packages by default, but apt-get and gnome-app-install don't seem to. Aren't they doing it, or is there a setting anywhere I have disabled?
<liw> pochu, apt-get got that feature in Debian just recently, I don't know (since I'm new to Ubuntu) whether it's incorporated into Ubuntu yet
<Vegar> pochu: put APT::Install-Recommends "true"; in /etc/apt/apt.conf
<Vegar> APT::Install-Recommends "true";
<pochu> Vegar: the question is, is that enabled by default now?
<Vegar> ah
<slangasek> liw: well, ISTR mvo wrote it anyway. :)
<liw> slangasek, yeah, but what with gutsy freezes and stuff it might still not be included :)
<sladen> I thought that had already gone in
<sladen> as part of moving lots of stuff from Depends: to Recommends:
<sladen> so that things could be uninstalled without cause  *-desktop  to be uninstalled
<mvo> pochu: its only enabled by default for metapackages (like ubuntu-desktop) currenty
<mvo> pochu: the goal is to enable it by default globally, but that requires close coordination with debian
<lamont> mvo: which, since sid now has that by default, means for hardy?
<mvo> lamont: presumably, hardy is a lts so things may be different :)
<lamont> right
<lamont> I was thinking more since hardy would open up autosync with sid again (presumably - dapper did...), that we'd get that default change as well..
<pochu> mvo: ok. I just thought it was already there, and it surprised me when it didn't work
* mvo nods
<stgraber> evand: the Propose my own part of qapoll is done, you can test it if you want
<evand> stgraber: thanks, testing it now
<bigon> hi, i'm trying to use pbuilder-dist to create a pbuilder chroot
<bigon> pbuilder-dist gutsy create
<bigon> and I get E: Type 'deb http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse' is not known on line 1 in source list /etc/apt/sources.list
<bigon> at the end of the process
<bigon> is it known
<bigon> ?
<stdin> bigon: take a look at https://wiki.ubuntu.com/PbuilderHowto
<bigon> stdin: I have already a pbuilder running, I just want to test the pbuilder-dist ship with the ubuntu-dev-tools package
<stdin> bigon: not sure if it's a bug or not, try looking on launchpad
<ebrahim> Hi there! Why #kubuntu-devel is empty?!?!?!?
<norsetto> ebrahim: don't know, ask in kubuntu-devel
<ebrahim> lol
<ebrahim> norsetto, thanks a lot!
<norsetto> ebrahim: de nada
<ebrahim> norsetto, no one is there!
<norsetto> ebrahim: the buggers, no wonder we are still waiting for kde 4.0
<ebrahim> norsetto, please explain more. What do you mean?
<norsetto> ebrahim: don't mind me, I'm in bad-joke mode
<ebrahim> norsetto, :D
<cellofellow> hi
<ebrahim> I was wondering if it is better to become an Ubuntu developer or a Debian one?!?
<stgraber> evand: I have added a top-5 block
<Riddell> ebrahim: you have not been on #kubuntu-devel
<Riddell> you must have joined the wrong channel or on a wrong network
<ebrahim> Riddell, right! I think it was my mistake! Thanks.
<pwnguin> oh this is beautiful
<pwnguin> http://www.getautomatix.com/forum/index.php?showtopic=1558&hl=gutsy
<pwnguin> ""
<pwnguin> "Automatix for Gutsy will NOT be backwards compatible with the previous versions. This will require the user to do a clean install for Gutsy or to run Automatix on Feisty and uninstall everything that Automatix has installed before the upgrade"
<ion_> Hehe
<pwnguin> it might be worthwhile for the dist-upgrader people (if they already havent) to contact automatix about doing this automatically
<ion_> Im not sure anyone should spend any precious development time with anything regarding automatix. :-)
<pwnguin> im not sure what purpose automatix has left
<pwnguin> add/remove does quite well i think
<Nafallo> could someone give back ekiga? it has it's damn opal now ;-)
* Nafallo wants to phone his parents tomorrow :-P
<pwnguin> cute
#ubuntu-devel 2007-09-29
<pwnguin> if a build fails on ia64 because debhelper wasn't installed, does lp automatically resubmit?
<soren> Nafallo: Opal?
<soren> Nafallo: Ah, nm.
* lamont rescores perl/i386 so that it'll get built sooner and make things installable again.  sigh
<lamont> and perl is building
<lamont> it'll be nice when the buildds can install debhelper again.
<lamont> slangasek: sorry
<lamont> well, partially
<lamont> poor timing on having oo.o, gcc-4.2, and perl all hit together
<calc> whee that was fun... ate dinner out got bad enough 'gas' that it caused me to vomit when i got home :-\
<bryce_> TMI
<calc> heh
<zzxc> Are there any plans to implement a binary diff system (eg. debiff) in the apt interface for a future release?
<zzxc> For something like that to work with the Ubuntu live cd, the binary diff program would have to patch individual binaries, instead of entire .deb archives, to create the new .deb archive to install.  This would require considerable installation effort, and I am not near familiar with apt to do it, but it would make updating Firefox go from a 7MB download to a 200KB download.
<RAOF> zzxc: Debian have such a system rolled out already, I think.
<_MMA_> There's also Conary.
<RAOF> zzxc: They certainly do for repository information, I'm not sure about actual packages though.
<zzxc> RAOF: It works with entire .deb archives, though, if I recall correctly.
<zzxc> Yes, repository information is of course synced intelligently, but package syncing is much harder - especially if no .deb files are on the system to begin with.
<johanbr> For the mirrors, processing power is often more scarce a resource than bandwidth.
<RAOF> There's also at least one project to make apt use zsync, a server-processor-friendly version of rsync.
<zzxc> The processing would be done only once; the servers would simply store a binary diff from the last version of the package.
<johanbr> And how would that work if your own version is not the latest one?
<zzxc> Then you would need an entire download.
<zzxc> Alternatively, the versions could be installed one-at-a-time until the latest version is achieved.
<johanbr> I'm not sure that going from version N to version N+1 is the most common case for updates.
<zzxc> Right now, it's not the most common case.  But for security, it should be.
<zzxc> Existing .deb diff software would have to be reworked for this to happen.  For example, the binary diff might be a modified .deb file.  Instead of containing entire binaries, it would contain binary diffs from the last version.  Apt would then have to be modified to require the previous package to be installed, and to properly apply the binary diffs.  If an error occured during package extraction (for example, one of the files that needs
<Nafallo> god damn. keescook: any way to check which processes are using openssl and therefor needs a restart?
<ajmitch> lsof?
<Nafallo> hmm. might actually work...
<Nafallo> kewl
<RAOF> zzxc: https://blueprints.edge.launchpad.net/ubuntu/+spec/apt-sync might interest you.
<Nafallo> thanks aj
<Nafallo> ajmitch
<Nafallo> ajmitch: hmm... everything :-(
<ajmitch> heh
<zzxc> RAOF: How close is that to an implementation?
<zzxc> RAOF: Actually, it seems that it requires the package file be on the remote system - which is not the case for most end-users.
<Nafallo> done :-)
<Nafallo> the one affected mostly is probably my ntp :-/
<Nafallo> hmm.
<Nafallo> I seeded 547GB for the beta. that should be enough damnit :-)
<zzxc> I think I might try to investigate the feasibility of a "partial .deb file", and post something to one of the debian mailing lists.  It would be trivial to have a folder on each mirror called "partial" to host partial packages.  This is how Mozilla does it.
<zzxc> It's definately a turn-off to a user with a slow connection to realize that 100MB of updates required for security.
<desrt> zzxc; best bet, i think, is to have some sort of [something]  that modifies the user's system in-place
<desrt> zzxc; including performing the actual changes and modifying the dpkg state to pretend that the new version has been installed
<zzxc> desrt: That would seem to be risky, to 'pretend' to install packages while avoiding apt entirely.
<desrt> zzxc; in many cases all you'd be doing is bumping the version number of the installed package
<desrt> since when security updates occur you have to install all of the binary packages from that given source package and probably only one of them has actually changed
<zzxc> desrt: Implementing something like that would seem to be 'reinventing the wheel' with Apt.  In addition, it would have to stay up-to-date with the current apt version to avoid major problems.
<desrt> it's actually completely orthogonal to apt
<zzxc> I suppose for security updates, where the only change is changes to existing binaries, such a solution would work.
<desrt> if you wanted to get really fancy you could do all sorts of neat binary-patching techniques
<zzxc> desrt: It would seem to be difficult, however, to have a general tool that would generate these "update instructions" from deb files in the general case.
<desrt> this is the fun part :D
<desrt> seriously, though: why not just extract the two debs and run diff?
<zzxc> Tools for that exist.  However, the old version's .deb doesn't exist on the remote computer.
<desrt> who the hell is david portwood?
<desrt> i report a problem with the livecd and my bug gets "New => Invalid" with "Compiz package is not from the official Ubuntu repositories, and as such is not supported here."
<desrt> have i missed something?
<zzxc> A 'partial .deb', on the other hand, would be able to be extracted into a 'full .deb' using existing binaries (such as soffice.bin) on the remote machine.
<zzxc> Thus, OOo 2.3.0->2.3.0.1 might be 5MB instead of 100MB.
<Burgundavia> zzxc: are you talking about binary diffs?
<Burgundavia> google deb binary diffs
<zzxc> Burgundavia: Sort of.  I'm talking about a partial deb that *contains* binary diffs being used to update software on a computer in which no existing .deb to patch exists.
<mneptok> FWIW, dm-crypt as part of d-i greatly excites my wriggly bits.
<mneptok> as well as my full head latex Bruce Schneier mask
<realist> zzxc: you can rebuild the .deb from already installed packages, then binary patching that package, you mean?
<realist> zzxc: where the archive cache has been previously cleaned?
<zzxc> With live cd installs, there never is an archive cache.
<realist> I hadn't noticed that, strange.
<zzxc> Such a technique would probably not try to rebuild the existing .deb archive.  Rather, it would download a new .deb archive from a mirror that would contain binary diffs instead of entire binaries.  New binaries would be in the .deb file in their entirety, and files that may be edited (such as configuration files) would not be diff'ed either.
<zzxc> Some program would then convert the binary diffs inside the .deb file into full binaries, by patching binaries on the user's system.  The user would then have a full .deb file that could be normally installed as normal.
<realist> I see, so download binary patches as a .deb, then patch existing installed binaries, _then_ build the new .deb?
<pavan> ubuntu (almost) no functional after attempted upgrade to gutsy 7.10 .. can i please get some help.. thanks
<RAOF> pavan: Help in #ubuntu+1
<RAOF> pavan: Which also has the advantage of having more people in it :)
<pavan> thx
<minghua> Is there any words about mass build failures on all buildds of different arches?
<realist> realist: I think it might be cheaper calculating the binary diffs client side, than storing diffs between every package release on the server
<realist> zzxc rather.
<realist> Talking to myself again :-)
<realist> Then again, Canonical might have the funds for such a trade-off.
<zzxc> realist: How could the diff be calculated on the client side?
<realist> zzxc: by storing checksums of the package, rather than diffs between releases
<zzxc> I'm not sure what you mean.
<zzxc> To compute the diff, the computer would need access to both the old and new versions.  Thus, the client computer would be unable to do it.
<zzxc> Storing and pushing binary diffs stored as "partial .deb files", as I described earlier, could be done with the exsting mirrors.  There would just be two .deb files for each update, rather than one.
<realist> You would need to rsync/zsync the blocks with different checksums
<realist> So it's not so much patching, as syncing, the packages
<realist> If the original .deb doesn't exist, you could regenerate it from the installed binaries
<minghua> realist: Generally speaking you aren't guaranteed to reconstruct a .deb from installed binaries.
<realist> minghua: you could just sync the binaries listed in the package meta-data then
<minghua> realist: True.  I was not arguing against your "rsync-like update" idea, just pointing out some inaccuracy in your statement.
<realist> minghua: fair call.
<realist> What would be interesting to see, is this type of patch or sync capability, combined with debtorrent
<dongthao> hello
<zzxc> realist: Are there not enough ubuntu package mirrors for your liking :)
<dongthao> I want to join ubuntu developers, how can I begin?
<dongthao> please help me :(
<realist> zzxc: I just like the idea of distributed networks, fewer points of failure, etc
<RAOF> dongthao: #ubuntu-motu is a better place to start.
<RAOF> dongthao: wiki.ubuntu.com/MOTU
<RAOF> dongthao: There's all sorts of stuff to do :)
<dongthao> I've create launch-pad account
<dongthao> but there're too many teams
<dongthao> I don't know where to begin
<realist> Find something that interests you, for a start
<RAOF> dongthao: How do you want to help?  What do you want to do?  Translation, packaging, programming, etc.
<dongthao> I want programming :)
<pwnguin> excellent
<dongthao> I'm learning and working with python
<pwnguin> dongthao: do you know what a diff is?
<dongthao> I think a little :)
<dongthao> I often use it in compare files
<dongthao> sometimes in patching
<pwnguin> yup
<pwnguin> check out that wiki page
<pwnguin> and
<pwnguin> the MOTU just had a blog about how to get started
<RAOF> dongthao: What sort of project might you be interested in?  There are a bunch of Ubuntu python projects, or you could write a gnome-screensaver hack configurator :)
<dongthao> ye
<dongthao> oh
<dongthao> gnome-screensaver
<dongthao> it sounds interesting
<minghua> RAOF: gnome-screensaver's configuration indeed sucks.
<dongthao> I have some hacks in gnome-app-install
<pwnguin> http://daniel.holba.ch/blog/?p=54
<dongthao> but just for fun in free time
<RAOF> dongthao: What that would entail is being able to write .desktop files, it'd be pretty simple.
<dongthao> yep
<RAOF> dongthao: http://ubuntuforums.org/showthread.php?t=418759 is a forum thread containing some information about that.
<dongthao> I modify some source from it
<dongthao> mostly in translating and rearrange the columns
* RAOF was going to look into it at *some* point, but I'm exceptionally bad at time-management, so...
<pwnguin> if you really want to hack gnome-screensaver
<pwnguin> make it accept pam
<RAOF> pwnguin: Not hack *on* gnome-screensaver, write a GUI for configuring xscreensaver hacks.
<RAOF> pwnguin: Of course, pamifying could be good, too.
<fabbione> siretart: next time you modify a postinst please make sure it actually runs.. or at least sh -n it
<pwnguin> RAOF: it'd be handy for my fingerprint reader ;)
<dongthao> yep
<dongthao> I think it's neccesary
<dongthao> anyone like that task?
<pwnguin> im not sure what task you're thinking of, but it's all yours
<RAOF> dongthao: I'll join you in it if you want to start it up.  You'd probably want to create a gnome-screensaver-config project on launchpad, use LP for bzr hosting, and write it in python :)
<realist> pamifying gnome-screensaver
<dongthao> i'm a very new in ubuntu development
<dongthao> event dun know clearly about lauchpad
<dongthao> i'm studying on it
<RAOF> dongthao: This wouldn't strictly be ubuntu development, but it *would* be very useful :)
<dongthao> yep
<dongthao> i like it
<pwnguin> dongthao: joing #ubuntu-motu, and check out https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<dongthao> so anyone start it
<dongthao> i'll join with you
<pwnguin> dongthao: those are supposed to be good "learning" bugs
<dongthao> yep
<dongthao> i'll check it now
<RAOF> That's if you want to help by packaging, of course :)
<dongthao> i'll training experence :D
<pwnguin> packaging and dev'ing go hand in hand really
<RAOF> pwnguin: No, not really.
<dongthao> :)
* RAOF eyes his "write a 'How to be a good upstream' wiki page" todo item
<dongthao> i also think they go hand in hand
<pwnguin> i mean, if you want changes into ubuntu, you at least need to know how to get the current source, modify it, and pass it back
<RAOF> pwnguin: You may notice that almost all the software we package isn't packaged by the developer(s).
<minghua> pwnguin, realist: What exactly does "pam-ifying gnome-screensaver" mean?  Doesn't gnome-screensaver ship /etc/pam.d/gnome-screensaver in Ubuntu?
<RAOF> Oh, that.  Yes.
<pwnguin> im not saying that upstream should be providing a debian dir
<pwnguin> though its handy as a reference
<realist> minghua: I don't even use gnome :-)
<pwnguin> minghua: it doesn't work with pam_thinkfinger
<pwnguin> i havent yet dug into why
<RAOF> pwnguin: Added pam_thinkfinger to /etc/pam.d/common-auth ?
<minghua> pwnguin: Okay.  Then you should have said "pam_thinkfinger-ifying". ;-)
<pwnguin> RAOF: ages ago
<RAOF> Fair enough :)
* RAOF 's pam knowledge is thus exhausted
<pwnguin> RAOF: skimming some stuff suggested an ACL
<pwnguin> i wasnt even aware ext3 had acls
<pwnguin> but apparently FC ships with em
<RAOF> Yeah. What doesn't?
<realist> Even ffs has acls.
<pwnguin> ffs?
<realist> bsd-ffs
<pwnguin> huh
<pwnguin> i figured it was just unix permissions
* mneptok drips onto Hobbsee 
* Hobbsee takes a very hot shower
* Hobbsee beats mneptok off
<Hobbsee> (in the opposite order0
<pwnguin> uh
<LaserJock> hi Hobbsee
<mneptok> i ...
<mneptok> i need to walk away
<mneptok> just ... walk away
<Hobbsee> hi LaserJock
<Hobbsee> mneptok: yes, you do.  go drown yourself in some beer.
<pwnguin> mneptok: maybe a first class ticket to Australia is in order :D
<LaserJock> anybody here got any experience with vcs imports?
<Burgundavia> Hobbsee: ouch, all I can say is ouch
<Hobbsee> Burgundavia: heh.
<kylem> mneptok, pfft, quoting yourself on /Quotes is discouraged. ;-)
<mneptok> kylem: dude. i know the pressure i just absorbed. i get a back-pat.
<mneptok> you know it, too.
<kylem> ha.
<mneptok> you know how difficult that was yor me.
<mneptok> *for
<mneptok> i'm still kinda shaking.
* Hobbsee sighs at words that have too many slang meanings.
<pwnguin> heh
* Hobbsee thinks you all have very dirty minds.
* desrt throws soil at Hobbsee 
* Hobbsee throws the soil back at desrt, first adding water.
* ogra ducks to not get hit
<ajmitch> hello Hobbsee
<Hobbsee> hi ajmitch
<ajmitch> nice to see you
<Hobbsee> hi ogra
<ogra> hey he
<ogra> y
<Hobbsee> hm
* desrt is muddied
* Treenaks quickly Ctrl+C's his upgrade
<ajmitch> Treenaks: some breakage ahead?
<Treenaks> ajmitch: tip of the day: don't run apt-get -y dist-upgrade
<pwnguin> heh
<Treenaks> it tried to deinstall perl.. and everything depending on it
<ajmitch> oh, noone would be silly enough to do that
<pwnguin> yes
<Treenaks> which is pretty much everything
<LaserJock> yeah, it seems like perl is important for some reason
<pwnguin> perl seems to have broken most of the buildqueues as well
<ajmitch> can we punt perl to universe?
<LaserJock> sounds sane ;-)
<Treenaks> well, only ntp and console-setup seem to depend on it :)
<ajmitch> it shouldn't take long to rewrite debhelper in python
<Treenaks> yay for remove vs purge.. system fixed :)
<calc> anyone else notice apt-get being buggy on dist-upgrade lately?
<calc> bug 146614
<ubotu> Launchpad bug 146614 in apt "apt-get dist-upgrade fails due to bogus(?) unmet dependencies" [Undecided,New]  https://launchpad.net/bugs/146614
<slangasek> sorry, I've only noticed that you broke ooo installability. :)
<ogra> lol
<calc> heh it installed fine for me :)
<calc> wrt apt-get issue apt-get upgrade works fine for me but apt-get dist-upgrade complains of installed packages not being installed and that they won't be installed since obviously they already are
<frostburn> mines complaining about perl and a dep that isn't in the repo
<calc> frostburn: hmm shouldn't that just cause it to hold perl?
<calc> apt-get upgrade held several packages on my system
<calc> The following packages have been kept back: gnome-cards-data gnome-games-data libperl5.8 perl perl-base tracker tracker-search-tool
<calc> 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
<frostburn> you can install the rest of them
<frostburn> individually
<frostburn> except perl stuff
<calc> ok
<calc> i guess dselect upgrade calls the same code as apt-get dist-upgrade because it doesn't work either with the same output
<frostburn> calc you on amd64?
<calc> frostburn: yes
<frostburn> luckyone, you, and me all have the same prob =] 
<calc> frostburn: follow up to 146614 noting you have the same problem ;)
<luckyone> interesting
<calc> cjwatson: you were the last to touch apt, any idea if what you changed could have caused the issue?
<calc> idle 10hr, he'll be back soon maybe ;)
<slangasek> why do you suppose it's a bug in apt, rather than simply a normal side-effect of uninstallable packages in the archive?
<calc> slangasek: er shouldn't it tell us what is uninstallable then?
<slangasek> never has before
<frostburn> apt is fine
<calc> slangasek: i thought it used to complain about the packages that were actually uninstallable
<slangasek> you only get told about which packages are uninstallable if you request packages to be installed by name
<calc> so it is normal for apt to complain about packages that are perfectly fine and installed when it can't install some other random package, and not mention that package at all?
<calc> i haven't had dselect->upgrade break me in so long i can't remember the last time it did
<calc> er for me
<calc> eg in this case it complains about xbase-client, xclock, xfd, xlogo, xorg, xterm all of which are installed and don't have new versions
* calc notes if it is normal for that to happen apt is a big stinking pile
<TheMuso> calc: have you managed to look at bug 140673 yet? I know its not a priority for you, but if you could look into it, it would be great for helping us get deacent accessibility for screen reader users for the final release.
<ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
<calc> TheMuso: looking
<calc> TheMuso: i can drop portaudio dep from ooo completely if that is agreeable, esp since it seems to cause problems in this case
<calc> TheMuso: i just recently added it anyway so its not a big deal
<TheMuso> calc: I'm convinced, but I'm probably not the one needing convincing.
<TheMuso> calc: If you could leave a comment, and I think pitti should be good with it/. I can then get an upload for espeak done. Thanks a lot.
<calc> yea i added a comment just now
<TheMuso> calc: Thanks again.
<calc> no problem :)
<luckyone> anything I can help with to fix the dependencies issue with xorg and xbase-clients
<calc> luckyone: it appears it may just be apt is a pos issue and complains about the wrong thing
<calc> luckyone: apt-get upgrade should work for you, it is probably perl being broken that caused the weird apt error message
<nb-au> any idea when perl-modules will be updated anyone?
<luckyone> huh, is there a link I can follow up with this on?
<luckyone> I *need* to head to bed
<luckyone> but *need* to fix this... tomorrow
<calc> luckyone: just run apt-get upgrade and go to bed, perl will probably be fixed tomorrow
<Hobbsee> calc: or monday.  it is a saturday todya.
<calc> luckyone: apt-get dist-upgrade will probably be broken until perl is fixed
<calc> luckyone: see what Hobbsee said
<luckyone> yeah, doesn't work
<calc> luckyone: er apt-get upgrade worked for me
<calc> luckyone: it was apt-get dist-upgrade that failed on my box
<luckyone> I concur
<luckyone> good to know that upgrade still works
<luckyone> I was afraid I wouldn't be able to install packages
<calc> ok, so just don't use dist-upgrade until perl is fixed :)
<luckyone> wahoo
<calc> and hopefully someone can beat apt up enough that it complains about the actual broken packages in the future
* luckyone thanks his merciful heros
<calc> oh i know what is different about the perl thing wrt dselect->upgrade
<luckyone> I also have a stupid question about media players that can leverage dual core processors
<Hobbsee> oh yay, breakage.
<calc> usually dselect determines something is fubar and doesn't try to upgrade it, but didn't figure out how to do it correctly in this case
<luckyone> does such a program exist?
<calc> so it passed it on to apt which choked on perl
* Hobbsee blames calc
<calc> Hobbsee: 8-P
<frostburn> luckyone, what do you mean?
<Hobbsee> calc: http://rafb.net/p/Brxzd428.html
<calc> Hobbsee: how recently did you try that?
<Hobbsee> calc: just now
<calc> Hobbsee: it may be that your openoffice.org-l10n-* is out of date still
<calc> Hobbsee: check to see if you see 1:2.3.0-1ubuntu2 versions available for them as well
<Hobbsee> calc: *eyebrow raise*
<calc> Hobbsee: they are on the main mirror already but maybe not in au
<calc> the output you showed there showed that openoffice.org-common had not been updated but wasn't in the list to up date either afaict
<Hobbsee> calc: dude, did you even *look* at the error log?
<Hobbsee> oh wait,
<calc> Hobbsee: yea :P
<Hobbsee> why do i have openoffice.org-l10n-en-za:installed?
<calc> because its pulled in by language-support-en probably
<Hobbsee> oh, langsupporten
<calc> and if the mirror you are using doesn't have up to date version of that it might be holding back ooo
<calc> though its already on some of the mirrors at least
* Hobbsee uses two sets of mirrors.
<nb-au> calc, for me i had to force  OO then lang support would install
<Hobbsee> whether i missed a mirror pulse in the last ~15 mins is an interesting question, though
<Hobbsee> calc: i don tleave myself only on the au mirror.  in fact, i use a different au mirror, and a.u.c
<Hobbsee> because it's not worth having the packages ~12+ hours out of date
<calc> it finished building 5 hours ago, not sure when it hit the mirrors
<calc> nb-au: oh
<Hobbsee> oh, so this one built :P
<calc> of course ;)
<calc> it builds at least some of the time ;)
<ajmitch> Hobbsee: you sound like a born sceptic
<Hobbsee> oh, here we are
<Hobbsee> yes, force installing it works.
<Hobbsee> ajmitch: i must have done too much RM stuff.
<nb-au> hehe
<nb-au> you should be able to slowly work your way down to the perl files by messing around in apt
* calc notes it just worked for him but he is pointed at the main a.u.c site
<calc> if you use dselect you can just put the perl files on hold and it will automatically get the rest
<nb-au> hehe, ive already manually half installed them :/
* Hobbsee doesnt have perl installed anyway
<nb-au> Hobbsee, its default
* pwnguin wonders how you get rid of perl
<calc> nb-au: alternatively you can use dpkg --set-selections to put them on hold if you don't like dselect ;)
<Hobbsee> oh, yes i do.
<Hobbsee> i didnt get perl falling over and dying, though
<nb-au> calc, i mean i somehow got perl to half upgrade to 7ubuntu3
<nb-au> before i realised it was mssing packages
<nb-au> lol
<Hobbsee> oh, only ubuntu2 on my mirror
<calc> nb-au: oh ok
<Hobbsee> and a.u.c, it looks like
<nb-au> im on main
<calc> Hobbsee: 1ubuntu2 is the current ooo packages
<calc> Hobbsee: they should install fine if they are all there, it worked for me off of a.u.c
<Hobbsee> calc: i meant of perl
<calc> Hobbsee: oh ok, nm
<calc> time for me to go to bed, 2am
<Kstrings> Hrm...  What am I doing wrong here.  apt-get source <package> pbuilder build <package> dpkg -i <package>  then synaptic tells me that I need to update <package> to the same version.
<nb-au> so i ihave perl and perlbase as u3, with lib-perl as u2 but with upgrade avail, and perl-modules at u2 with no upgrade available, and im waiting for that upgrade
<calc> Kstrings: you probably should set it to hold after installing the manual version unless you want the one from the archive
<nb-au> looks like some stuff have been updated (namedly perl)
<nb-au> give it a go :)
<nb-au> hmm seems not, have to go manual
<nb-au> HOLY CRAP
<nb-au> FIXED
<nb-au> woot
<frostburn> do i have to recompile kaffeine/totem to get dvd playback
<siretart> fabbione: oooops - sorry. willdo next time :(
* siretart hides in the corner
<nb-au> frostburn, shouldnt
<nb-au> should work with dvdcss
<frostburn> aye, it's installed already
<nb-au> strange
<nb-au> i watched 2 dvds back in tribe 3
<frostburn> yeah it was working in 7.04
<frostburn> i'll keep plugging at it
<nb-au> tried mplayer?
<nb-au> if it doesnt play it that something is badly amiss
<nb-au> or maybe u dont have codecs
<frostburn> yeah
<Kstrings> Does anyone know why aptitude thinks you need to update packages compiled from source (pbuilder) when they are the same version?
<Hobbsee> sounds like a #ubuntu+1 type question
<Hobbsee> but, it's because you probably compiled the same version as what's in the repos - and iirc, it will usually try to use the repo version, not your own.
<Hobbsee> due to apt priorities
<Treenaks> it will
<Treenaks> but I usually fix that either by setting the package status to 'hold', or setting the version a bit higher (but not as high as an update would set it)
<ajmitch> which is where ~ in versions comes in handy
<Kstrings> The ~ is?
<Hobbsee> hm, will keybuk eat me for uploading udev?
<ajmitch> Hobbsee: yes, fabbione already uploaded a new version
<Treenaks> Hobbsee: he might, depends on how buggy you made it ;)
<Hobbsee> ajmitch: awesome.  that was the one.
<ajmitch> Kstrings: it's used to denote that a version is less than another, eg 1.2.3-1ubuntu1~ppa1
<ajmitch> Hobbsee: yeah, good thing fabbione uploaded it first, otherwise I would have done uploaded my fix :)
<Hobbsee> :)
<ajmitch> the only problem is that it failed to build on !i386, and is in the build queue for i386
<Hobbsee> oh dear
<ajmitch> yeah
<ajmitch> one of those days...
* Mez sighs
<Mez> and now my DVD drive / HDD#'s show as s * not h* meaning I cant watch DVDs on my PC (shdparm -d wont work)
<ajmitch> Mithrandir: I think that there'll be a large number of packages uploaded recently that will need given back on !i386 due to a perl upload - perl was made uninstallable by perl-modules on !i386 until it was built on i386
<pwnguin> heh
<ajmitch> one important one to give back is udev, for a typo fix
<Mithrandir> ajmitch,Hobbsee : I'll give-back what's failed.
<ajmitch> thanks :)
<Hobbsee> thanks Mithrandir
* Hobbsee hugs Mithrandir
<Kopfgeldjaeger> hey
<Mithrandir> there, stuff given back.
<Hobbsee> thanks Mithrandir
* Hobbsee uploads kdebase
<slytherin> I had sent a mail to ubuntu-devel-discuss team about theora beta 1 poackages. Should I wait for some testing feedback or just go ahead and file a freeze exception bug?
<RAOF> slytherin: If you're prepared to follow the freeze exception process, there's a compelling reason for theora beta 1, and it doesn't break anything, I'd say file a freeze exception bug.  There's been someone looking at this in here before.  Was that you?
<slytherin> RAOF: If that was yesterday then it was me.
<RAOF> There was someone before yesterday, too, but I can't remember who it was.
<slytherin> RAOF: Till now I have tested totem, mplayer, and ffmpeg2theora and no breakage found. But there are too many rdepends, so dholbach suggested me to send mail.
<Kmos> bug 146666
<ubotu> Launchpad bug 146666 in ubuntu "Installation Break on ASUS P5K SE" [Undecided,New]  https://launchpad.net/bugs/146666
<Kmos> i think this is kernel related
<RAOF> slytherin: Ah, fair enough.  Then maybe wait for replies on -devel-discuss.  It is the weekend, after all.
<Whoopie> mjg59: Hi, could you have a look at bug 109151? I re-added usplash support to uswsusp. but the acpi-support package also needs a change.
<ubotu> Launchpad bug 109151 in uswsusp "no hibernate with uswsusp installed" [Undecided,Confirmed]  https://launchpad.net/bugs/109151
<mjg59> Whoopie: How did you handle the resolution information?
<Whoopie> mjg59: I added a -x and -y command line parameter to suspend.c and resume.c
<Whoopie> and these values are read from /etc/usplash.conf in /etc/acpi/hibernate.sh
<mjg59> Whoopie: Ah, ok. And the swap device is auto-chosen?
<Whoopie> mjg59: it's in /etc/uswsusp.conf. And this was added during install. debconf??
<mjg59> Hm. Not entirely ideal, but fair enough.
<mjg59> Ok, I'll try to upload that later
<bluekuja> mjg59: I was following Whoopie on it, if that patch is ok, I can move to upload that
<bluekuja> mjg59: just wanted to hear your opinion about it
<Whoopie> mjg59: problem for me is that it hangs on resume. It doesn't switch back to X, but the laptop is still responsive so that I can poweroff it by pressing the power button.
<Whoopie> really don't know if it's usplash or my laptop.
<Whoopie> mjg59: and if you are on the acpi-support package, could you add the 0 to /etc/acpi/events/asus-brightness-{up,down}? it's bug 76593. thanks!
<ubotu> Launchpad bug 76593 in acpi-support "asus brightness hotkeys" [Wishlist,Confirmed]  https://launchpad.net/bugs/76593
<salty-horse> hi. is there a way to hurry up a build? there was a small bug in udev that prevented it from being installed, and I fear to restart my machine after a gutsy upgrade without it working: https://launchpad.net/ubuntu/+source/udev/113-0ubuntu14
<Hobbsee> if there are buildd admins around, yes
<Hobbsee> otherwise, no
<salty-horse> Hobbsee, I'm installing an older version: https://launchpad.net/ubuntu/+source/udev/113-0ubuntu12/+build/398871
<Hobbsee> you could just fix the script, so it installs - the bug tells you how to, iirc.
<salty-horse> I'm not an expert at .deb packaging -- rather not mess with it
* salty-horse is restarting his system, hoping everything goes well after the upgrade
<glatzor_> hello Riddell, the latest ati drivers in Ubuntu do no longer support xinerama. So I prepared a patch to disable dualhead in guidance for ati cards.
<AnAnt> Hello, a latex package (package here means set of macros, not debian package) has this file in the fonts/ directory 'Uqnskh.fd', does anyone know where the *.fd files should be installed in latex system ?
<attunix> Where can I download the new "Elephant" wallpaper available in Gutsy? I'm on Feisty.
<ryu> attunix, here are some: https://wiki.ubuntu.com/Artwork/Incoming/GutsyIdeas
<ryu> or you could fetch the gutsy packe from packages.ubuntu.com and extract it
<attunix> ryu: without the logo? ;)
<ryu> then you should pick the second way i mentioned...
<attunix> ryu: how do I do that? :)
<ryu> attunix, http://mirrors.kernel.org/ubuntu/pool/main/g/gutsy-wallpapers/gutsy-wallpapers_0.16_all.deb
<attunix> cool; thanks :)
<ryu> you can take a file-roller oder similar programms to extract it...
<cjwatson_> calc: certainly nothing to do with my change; have a look at the diff, it's trivial
<Hobbsee> greetings, cjwatson
<cjwatson> hello, briefly
<cjwatson> must walk dog, do laundry, do washing up, do everything else. argh.
<Hobbsee> hehe
<Hobbsee> find a robot.
<cjwatson> on the upside I think I nearly have oem-config i18nised
<kylem> tollef's too busy.
<keescook> mornin'
<Hobbsee> hiya keescook!
<keescook> hi!
<keescook> thanks for the kdebase upload.  There are a few more CVE fixes still to go into it, though.  Got any time for that?
<Hobbsee> keescook: for main packages?
<keescook> yup. konqueror.
<Hobbsee> urgle.
<keescook> let me find the bug #
<Hobbsee> keescook: btw, do you know if that csh shell thing was correct?  i saw you un-securified it
<keescook> hurm?  where?
<Hobbsee> i'ts in kdebase buglist
<keescook> checking
<keescook> afaik, the xsession is running as the user (not root), so if csh blows up, it is certainly a bug, but not a security issue.
<keescook> (137946)
<Hobbsee> keescook: i'm  more wondering fi the fix is correct
<keescook> Hobbsee: hmm, yeah, it looks okay.  It feels like there would be a cleaner way to handle it though.
<Hobbsee> keescook: right
<keescook> I'd almost be tempted to try things like   $SHELL -c "(if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login) >/dev/null; /bin/sh -c export" > $xsess_tmp
<Hobbsee> hm
<keescook> (or whatever the csh redirection looks like)
<keescook> Hobbsee: bugs #140707 and #146870   are the qt-x11-free, qt4-x11, kdebase, and kdelibs CVE issues.
<ubotu> Launchpad bug 140707 in qt-x11-free "[Qt 3, Qt 4]  Potential vulnerability in QUtf8Decoder" [High,Fix released]  https://launchpad.net/bugs/140707
<ubotu> Launchpad bug 146870 in kdelibs "konqueror URL bar spoofing" [Medium,Triaged]  https://launchpad.net/bugs/146870
<keescook> since those are bzr'd what's the best way for me to prepare patches for kde uploaders to take/upload ?
<keescook> Hobbsee: also, do you have archive powers to take-back a build?  Something broke in openssl for amd64 (that I can't reproduce locally) and was hoping it was just a temp failure.
<Hobbsee> keescook: i dont have any archive powers at all.  i dont work for canonical.
<Hobbsee> keescook: sometimes i wish i did
* keescook nods
<keescook> oh, ow
<keescook> Setting up linux-restricted-modules-2.6.22-12-generic (2.6.22.4-12.4) ...
<keescook> Segmentation fault (core dumped)
<Hobbsee> keescook: can you email me about those bugs?  i'm really tired
<Hobbsee> urgh.
<keescook> Hobbsee: sure, sending.
<Hobbsee> (it's after 3am)
<Hobbsee> thanks a million
<mjg59> keescook: Sweet.
<keescook> yeow, yeah, I thought it was late for you.  :)
<mjg59> keescook: Got an oops in dmesg?
<keescook> mjg59: seems depmod faulted.  but then my computer has hated me lately, so I bet it's my filesystem or something stupid.
<ion_> jamiemcc: Btw, is it intentional that tracker returns zero results until everything has been indexed? Id rather already get results for the already indexed entries, with perhaps a warning that the initial indexing is still going on.
<jamiemcc> ion_: 0.6.3 caches more in RAM so search results may not be avilable til its finished - we will amend the UI to warn about that
<ion_> jamiemcc: file-meta.db already contains some of the files im testing with, but tracker-search doesnt return any results for them.
<jamiemcc> ion_ index is stored in file-index.db
<ion_> jamiemcc: Ah, ok. It doesnt contain any data about files. Couldnt it be updated every once in a while *during* the indexing?
<jamiemcc> ion_: it is when 16mb cache is full - it flushes to index
<ion_> jamiemcc: Would it perhaps be better to mmap files and let the kernel do all the RAM caching and flushing?
<jamiemcc> ion_ no can do - mmap is not supported in qdbm or sqlite
<jamiemcc> ion_: mmap does not work on fuse as well
<ion_> I see.
<jamiemcc> ion_: also mmap takes memeory away from disk cache
<jamiemcc> if you have 1gb index it would eat 1g ram from disk cacje
<lamont> pool/universe/o/openoffice.org-l10n/openoffice.org-help-km_2.3.0-1ubuntu2_all.deb
<lamont> do we not love Comoros then?
<ion_> The whole mmapped area is kept in RAM? If that is the case, id say the kernels implementation is faulty. Id expect the kernel to flush pages that have been unused for a while to the disk and free the memory when RAM is needed for something else.
<lamont> pool/universe/o/openoffice.org-l10n/openoffice.org-l10n-uz_2.3.0-1ubuntu2_all.deb
<lamont> and lets not forget Uzbekistan
<ion_> Of course, i could be missing something important. :-)
<jamiemcc> ion_ it gets flushed when memory is low or you call unmap
<ion_> So, someone should implement a way to tell the kernel in this mmapped file, pages that have been unused for a while are not as important as disk cache? :-)
<jamiemcc> ion_: dunno - mmap is used for either sharing memory pages or agressive read pages into ram
<desrt> ion_; madvise()
<desrt> specifically, MADV_DONTNEED
<jamiemcc> desrt: we use posix_fadvise all over tarcker
<desrt> jamiemcc; tracker _destroys_ my laptop
<ion_> desrt: 0.8.3?
<desrt> i had to kill it off.  no offense to you or anything
<jamiemcc> desrt: latest 0.6.3 version?
<desrt> gutsy beta as of last night
<ion_> Whoops, typo.
<jamiemcc> its not in beta
<jamiemcc> its post beta
<desrt> well.. right... updated as of last night :p
<desrt> i was downloading and tracker was doing its think on the downloading file
<desrt> and every time vim went to save its .swp file the editor would hang for a good 10 seconds
<jamiemcc> desrt: that sounds like o.6.2 version
<desrt> when the update comes i'll try again
<jamiemcc> desrt: what file were you downloading?
<desrt> openoffice
<desrt> it's a biggie :)
<jamiemcc> desrt: I will try and replicate to be sure
<desrt> it may interest you that i'm not running ubuntu kernels these days
<jamiemcc> desrt: lol
* desrt is trying his hand as a l33t kernel hacker and upstream likes their patches to apply cleanly :p
<jamiemcc> desrt: anyway latest tracker 0.6.3 updates in chunks with intermittent fsync to prevent disk hogging for more than a sec or two
<desrt> why do you call fsync()?
<jamiemcc> cause pdflush will hog disk if I dont
<desrt> it must be fun to fight the kernel's cleverness
<desrt> why is it that the kernel is (more or less) ok with every other workload on earth but things like beagle and tracker always bring it to its knees?
<jamiemcc> pdflush!
<jamiemcc> its a high priority kernel thread
<jamiemcc> and can starve other apps of disk
<jamiemcc> desrt: its really bad on ext3 causeits write performance is terrible
<desrt> i'd expect that a download does more disk writing than tracker should during a download
<desrt> and yet doing two downloads doesn't wedge my system
<jamiemcc> tracker does seek read seek write for each word
<desrt> what do you mean "word"?
<jamiemcc> an indexed word
<mjg59> jamiemcc: The write depends on the read?
<jamiemcc> mjg59: of course its a has - you have to read where to write it
<mjg59> Yeah. There's no way the kernel can reorder that, then.
<desrt> not true
<desrt> you could read a bunch of offsets in one go
<jamiemcc> desrt: right
<desrt> so you're only consulting the index once
<jamiemcc> the reads should all be cache hits
<jamiemcc> if index is small
<desrt> fair enough
<mjg59> jamiemcc: Yeah.
<desrt> unless the index is being continuously pushed out by the insane amount of writing
<mjg59> With a small index file, it's fine (and I guess the index merging fixes this to a large extent)
<jamiemcc> with 30mb index is slows to crawl which means i suspect kernel
<jamiemcc> mjg59: yes index merging eliminates it untuil merge process
<desrt> jamiemcc; i have a suggestion
<jamiemcc> shoot
<desrt> jamiemcc; write a root-run helper program that opens the user's index and locks it into memory
<desrt> see if it impacts performance
<desrt> just as a test
<jamiemcc> how?
<desrt> mmap() the entire file
<desrt> and then run mlock() on that address you get
<jamiemcc> qdbm does not use mmap though
<desrt> doesn't matter.  this will keep it in the kernel's page cache
<desrt> make sure you do a shared mapping
<jamiemcc> ok will it be able to write it?
<desrt> yes
<Nafallo> hmm
<jamiemcc> I will have to do that with 0.6.2 version
<desrt> i guess it either writes with pwrite() or lseek()/write()?
<Nafallo> my brightness changed by itself...
<jamiemcc> lseek/write i think
<desrt> this is just a cute little test utility
<desrt> it's a 10-liner in C
<jamiemcc> yeah
<desrt> where is the tracker index, btw?  i wonder how big mine is.
<jamiemcc> home/.cache/tracker/ index*
<jamiemcc> meta is the metadata
<desrt> hmm
<desrt> email stuff is a few KB
<jamiemcc> you dont use evolution then
<desrt> file-content is 54M, file-index 73MB, file-index-journal 15M, file-meta 19M
<desrt> i do use evo
<desrt> just with imap
<jamiemcc> thats 0.6.2 version!
<jamiemcc> in 0.6.3 its file-contents.db
<desrt> i probably just didn't turn it back on after i upgraded :p
<jamiemcc> yes - it will auto reindex when you do
<jamiemcc> 0.6.2 really sux!
<desrt> totally awesome that you shipped it with the beta :p
<mjg59> desrt: Released after beta freeze
<jamiemcc> well i had 0.6.3 ready on monday
<jamiemcc> but they waitied til now
<desrt> nod.
<ion_> jamiemcc: Btw, are there plans to have a local tracker process indexing shared directories on a networked drive and having clients trackerds proxy queries to it over the network?
<jamiemcc> 0.6.3 indexes 250mb of linux source in 8 minutes and no slow downs
<desrt> jamiemcc; "8 minutes" on a good harddrive or on my laptop? :p
<jamiemcc> ion_: network searches are on the long term todo
<jamiemcc> desrt: a reasonable hard disk
<jamiemcc> a slow one might take a few minutes more
<jamiemcc> 0.6.2 would take hours to indesx that due to IO choking
<mjg59> So far, 0.6.3 seems a great deal better at avoiding IO issues
* desrt finds slow harddrives to be really slow
<desrt> there is a really really big difference between compiling a kernel on my laptop and on my desktop
<jamiemcc> mjg59: yeah its as good as we can make it
<desrt> jamiemcc; lies :)
<ion_> 0.6.3 is indexing my entire ~ on a 500 MHz P3 box right now, and i dont notice it at all, except for the HDD led blinking steadily.
<mjg59> jamiemcc: It's a great improvement. Thanks very much for working on this.
<jamiemcc> mjg59: no problem - we want to be the best :)
<desrt> jamiemcc; i'm sure you'll find something more to tweak for 0.6.4 :)
<jamiemcc> desrt: thats due on monday
<desrt> oh
<desrt> maybe 0.6.5 then
<jamiemcc> 0.7 more like we are branching to do xesam next
* mjg59 wonders why g-p-m is suddenly unenthusiastic about spotting power state changes
<desrt> mjg59; it has this new policy timeout feature
<pwnguin> as long as it isn't dimming the screen after like 20 seconds
<mjg59> Ok, restarting hal seems to have made it happer
<desrt> if events occur too soon after the event that preceeded them then it assumes that you have a buggy acpi and ignores them
<mjg59> Tch. Only seems to be autochanging brightness when I open the preferences.
<desrt> are you using non-g-p-m methods of changing brightness?
<mjg59> jamiemcc: tracker isn't obviously pausing when I switch to battery, but it's possible that things are just generally broken right now
<mjg59> desrt: No
<desrt> mjg59; that's odd indeed, then
<desrt> my gutsy bitchlist is rapidly shrinking
<jamiemcc> mjg59: yeah - battery pausing was well tested
<jamiemcc> it uses hal so hal must be working
<desrt> now all i gotta do is find out why networkmanager randomly crashes coming back from suspend
<ion_> jamiemcc: Perhaps the index should be updated after either the 16 MiB cache has been filled *or* e.g. 5 minutes have passed since the last update.
<jamiemcc> ion_: we dont work like that anymore - each flushis to a sepoarate mini index (approx 16mb)
<jamiemcc> once indexing is finished we stuch them all up into one index
<ion_> jamiemcc: Tracker has been running for 45 minutes and still returns no results. That is slightly annoying.
<desrt> does tracker do the filesystem or just ~?
<jamiemcc> by default just home
* desrt tells it to stay out of his source code
<jamiemcc> desrt: it plays nice wth source - tracker puases itself when compiling or checking out source
<desrt> cute.
<desrt> in any case, my homedir on my laptop is about 1GB
<desrt> 900MB of that is source
<desrt> so i'm just making tracker's job easier :)
<jamiemcc> desrt:  :)
<jamiemcc> desrt: tracker only pauses if it detects writes on its inotify watches
<jamiemcc> so if excluded from watching it wont pause
<desrt> jamiemcc; tracker wakes up once every 2 seconds to read /proc/acpi/ac_adapter/ADP1/state
<desrt> jamiemcc; you're better to watch the system dbus for state change notifications
<jamiemcc> desrt: yeah -  I have to figure out how to use hal dbus
<calc> cjwatson_: ok np
<desrt> you just dbus_add_match on the signals
<desrt> *bus_add_match, rather
<jamiemcc> I know that but I dont know hal api
<jamiemcc> hal is not very friendly in that regard
<desrt> about 5 seconds with dbus-monitor --system and a yank of a laptop power cord will tell you that :)
<jamiemcc> desrt: good idea!
<desrt> i think for something like this it would be better to just use dbus directly
<jamiemcc> yeah we are tivkless everywhere else
<desrt> i recently ported some code of mine from using libhal to using libdbus.  it was just easier.
<jamiemcc> tickless
<desrt> signal sender=:1.3 -> dest=(null destination) path=/org/freedesktop/Hal/devices/acpi_ADP1; interface=org.freedesktop.Hal.Device; member=PropertyModified
<desrt>          string "ac_adapter.present"
<desrt>          boolean false
<desrt>          boolean false
<jamiemcc> desrt: that acpi_ADP1 is hardware specific though
<desrt> seems pretty straight-forward
<desrt> it is true.
<desrt> "ac_adapter.present" is not :)
<jamiemcc> so I need to discover ac_adaptors first
<desrt> ...or watch for PropertyModified on all devices... :/
<desrt> the format of this signal is obnoxious....
<desrt> if it sent "ac_adaptor.present" as a toplevel argument of the signal you could even match on that
<jamiemcc> yeah I had a peek at api - it sux big time
<desrt> there is code in the gnome applets for this
<desrt> i wrote it.. you're free to use it under whatever license tracker is
<jamiemcc> tracke ris gpl
<desrt> oh.  that's fine then :p
<desrt> anyway.. it uses libhal to maintain a list of all of the batteries and AC adaptors in the system
<jamiemcc> desrt: I will have a hunt
<ion_> defcon: Good choice for username. :-)
<defcon> hehe
<defcon> ion, ive used that nick for yrs as well
<defcon> ionstorm
<defcon> thnx
<desrt> http://svn.gnome.org/viewcvs/gnome-applets/trunk/battstat/battstat-hal.c?revision=9981&view=markup
<desrt> see the adaptor_update_property() function... this is the thing that will get called when you get an ac_adaptor.present change event
<jamiemcc> desrt: thx
<defcon> who handles xorg drivers
<defcon> new bug for i810
<defcon> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-driver-i810/+bug/146728
<ubotu> Launchpad bug 146728 in xorg "[Gutsy Beta]  Dots on 16bit Video i810" [Undecided,New] 
<fabbione> hmmm
<fabbione> interesting FTBFS on udev... not my fault
<defcon> i have a problem with my video since butsy beta on 16bit, I have little "dots" all over my video on my intel i810 82865G
<defcon> what could be doing this?
<Nafallo> change to gutsy ;-)
<sivang> hi all
<sivang> congrets for the beta, pretty impressive list of improvements
* sivang wonders if the fast user switching is built into GNOME 2.20 or is specific to this ubuntu release
<lameiro_> hi. Straw 0.27 is released since May, but Debian maintainer still didn't package it.  is it possible to have it packaged for Gutsy?
<_MMA_> lameiro_: This late in the game I would think not.
<lameiro_> _MMA_: alright, thank you. maybe I should ask this in #ubuntu-motu? right?
<_MMA_> lameiro_: If its a Universe packages yes but its the same situation.
<_MMA_> Its very close to release and we are past our freeze dates.
<lameiro_> _MMA_: ouch. alright... thank you.
<_MMA_> np
<Riddell> keescook: I did say I'd take care of the kde/qt security issues :)
<Riddell> but let me know the current status please
<Riddell> (there's no way to revert an upload once it's in the archives)
<pochu> lameiro: although if it's a bug fix release, an exception for it might be approved...
<lameiro> pochu: unfortunately no, it is a new version with new functionality, new strings... :(
<geser> does it fix some important bugs found it the current version in gutsy?
<geser> (if they exist)
<pochu> Then I guess not.
<pochu> You can backport bug fixes, though.
<asisak> Hey geser, pochu
<geser> Hi asisak
<lameiro> geser: no, just little fixes here and there and some new features, no critical bug fixes. thank you :)
<pochu> heya asisak
<geser> then you only chance it to bribe two motu-uvf members :)
<keescook> Riddell: I saw that Hobbsee uploaded one of the fixes, so I wanted to point out the others to her in case she was still working on them.
<keescook> Riddell: afaik, 140707 and 146870 contain all the missing issues.
<ion_> A script i use to handle integration between keychain and libpam-ssh. http://johan.kiviniemi.name/software/keychain.shellrc
#ubuntu-devel 2007-09-30
<tripzero> is ubiquity's text ui usable?
<Fujitsu> Does Ubiquity have a text UI?
<tripzero> according to the source it does... or what is the point of text.py?
<Burgundavia> tripzero: if you want a text UI, use the alternate UI and d-i
<Fujitsu> tripzero: I see no text.py..
<tripzero> ubiquity/ubiquity/frontend/text.py
<Fujitsu> Doesn't exist in 1.6.0 (the latest)
<tripzero> hmmm, lemme check
<tripzero> Burgundavia, what do you mean alternate UI? alternate cd?
<Burgundavia> tripzero: the alternate cd, yes
<Burgundavia> what do you need a text UI for?
<tripzero> fujitsu, you're right, it isn't in the latest
<tripzero> the gtk frontend is blowing up on me
<Burgundavia> are you running gutsy beta or 7.04?
<tripzero> 7.04
<tripzero> fujitsu, there is a non-interactive.py?
<Burgundavia> tripzero: the scripting stuff has only landed in gutsy, afaik
<Burgundavia> tripzero: if you are having issues installing 7.04, I would suggest you try the forums or the mailing list
<tripzero> thanks Burundavia
<Burgundavia> tripzero: if you want to, we need people to help test the beta release
<Burgundavia> are you able to help out with that?
<tripzero> yeah
<tripzero> what do you need?
<Burgundavia> basically, download the cd and test the install
<Burgundavia> given you are having install issues
<tripzero> okay
<tripzero> will do
<tripzero> btw, shouldn't gconf2 be a dependency of ubiquity?
<lamont> looks like maybe ports mirroring is b0rked again
* jdong thinks o3read needs a wrapper like o3less or o3cat
<jdong> unzip -p foo.odt content.xml | o3totxt | less is a RIDICULOUS workflow, no?
<LaserJock> jdong: that'd be cool
<ion_> I read my man pages with zcat /usr/share/man/man1/ls.1.gz | nroff -man | less, you insensitive clod!
<bddebian> heh
<jdong> ion_: lol
<jdong> LaserJock: where do we get o3read from? I am guessing it's the wrong part of the release cycle to add new commands?
<defcon> can someone assign this bug to gutsy or the correct place https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-driver-i810/+bug/146728
<ubotu> Launchpad bug 146728 in xorg "[Gutsy Beta]  Dots on 16bit Video i810" [Undecided,New] 
<minghua> defcon: Isn't it already assigned to too many different packages?
<defcon> minghua, i dont know which package it should be assigned
<minghua> defcon: But blindly assigning them to half a dozen packages doesn't help.
<minghua> defcon: If you want to help, go to #ubuntu+1 and #ubuntu-bugs, ask people there to figure out exactly which package it should be assigned to.
<TomaszD> Restricted-manager is still in English despite being fully translated for a long long time :(
<mdke> TomaszD: did you file a bug?
<siretart> perhaps the latest language pack hasn't been installed yet
<TomaszD> mdke, no, I subscribed to an existing one
<TomaszD> no no, I have all the latest and greatest :] 
<TomaszD> r-m moved to the restricted section and there is some kind of an infrastructural problem
<TomaszD> is that even a word... infrastructural
<TomaszD> ;] 
<siretart> TomaszD: installed to the archive ;)
<mdke> TomaszD: even better
<nrdb> with the LiveCD when is the unionfs started ?  I have looked in the initrd file but cant find it there, or in the init.d scripts once its booted
<stgraber> bryce: Can I milestone bug 145843 and increase priority a bit, it's very annoying for terminal users
<ubotu> Launchpad bug 145843 in compiz "Compiz maximizing unreliable" [Low,Incomplete]  https://launchpad.net/bugs/145843
<Kopfgeldjaeger> hi
<bryce> stgraber: since it's a compiz bug, you may want to talk with mvo and/or travis about it
<stgraber> ok, will ping them tomorrow
<bryce> I'm not sure what the rules are for compiz regarding priority and milestoning, but I wouldn't expect it to be controversial to increase the priority to medium
<stgraber> bryce: ok, I have set priority to medium and confirmed it
<bryce> for X bugs, one thing I know that can often help a lot more than setting the priority, is to do some upstream research and try identifying potential patches to test
<pwnguin> it seems simple enough to fix
<pwnguin> turn off hinting on maximize
<bryce> heya pitti
<pitti> hi
<pitti> bryce: wow, what are you doing online that late on a Saturday night? :)
<pwnguin> gnome-term is hinting that it should be a certain size since it's a fixed width terminal =/
<bryce> heh, I've been majorly reorganizing my office; it's been keeping me up
<bryce> Game Day is tomorrow, so it's my goal to have all the reorganizing done so I can show it off.  ;-)
<pwnguin> stgraber: if you want to fix gnometerm, bring up ccsm and set "ignore hints on maximize"
<stgraber> pwnguin: worked, thanks. Anyway, this should be fixed (or set by default) for Gutsy
<StevenK> pitti: If you want to kick opal-2.2.0 out for NBS in a little while, NEW the new opal, and then everything should sort itself out
<pitti> wow, so many NEW packages -- we are in FF and everything..
<Kmos> pitti: the apport-gtk was having problems on gutsy beta
<nrdb> with the LiveCD when is the unionfs started ?  I have looked in the initrd file but cant find it there, or in the init.d scripts once its booted
<cjwatson> nrdb: /scripts/casper in the initramfs
<cjwatson> nrdb: (please just ask once, BTW - I saw the first question)
<nrdb> cjwatson: found it thanks.
<xerakko> cjwatson, is possible to use more than one repository in germinate?
<cjwatson> xerakko: not at the moment, it's on the wishlist
<xerakko> :/ Thanks
* StevenK sighs at himself, and uploads a gimp that will actually build.
<asisak> Go StevenK! :D
<Whoopie> mjg59: could you explain me the difference between /sys/class/backlight/*/brightness and actual_brightness? because on my Samsung laptop, brightness = 4 but actual_brightness = 11.
<Whoopie> shouldn't they be the same?
<MacSlow> Greetings everybody!
<stgraber> hi MacSlow
<MacSlow> hi stgraber
<moyogo> hi
<mjg59> Whoopie: Brightness is what's been set, actual_brightness is what the backlight is running at
<attunix> I installed ubuntustudio-desktop and I decided I didn't like it so I removed it. Now the boot/load screen is still there. How can I get my old Ubuntu load screen back?
<sladen> attunix: sudo update-usplash-theme
<sits> I have a very long powersaving email that I was planning on sending to the ubuntu-devel-discuss list - http://sucs.org/~sits/test/powerusage
<sits> does anyone have any thoughts on it?
<Hobbsee> !weekend
<Hobbsee> gah, no ubotu
<sits> Hobbsee: heh
<sits> Hobbsee: any thoughts on my powerusage email?
<Hobbsee> none at all, havent read it
<Hobbsee> as it's a sunday night and all
<sits> ah fair enough
<ubunt1> pfuuu
<Cyrix> exit
<ubunt1> hey make something like daemon tools for gutsy
<Hobbsee> ubunt1: please see the /topic, then read man mount.
<ubunt1> i see it
<Hobbsee> then you'd know that this is an inappropriate place for your question?
<ubunt1> hehe
<MagnusR> http://www.flickr.com/photos/cloughridge/478583038/
<DaSkreech> ogra: ping
<TomaszD> easy fix if you happen to have time, add build-depend on intltool to gnome-screensaver https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/147337
<ubotu> Launchpad bug 147337 in gnome-screensaver "[gutsy]  gnome-screensaver doesn't build-depend on intltool, template not updated" [Undecided,Confirmed] 
<bddebian> heya
<bethko> Ok, I would like to talk to someone about https://blueprints.launchpad.net/ubuntu/+spec/webcam
<LaserJock> email would probably work best
<bethko> We need plug and play for webcams
<mjg59> What's currently lacking in that respect?
<mjg59> (Other than working drivers)
<bethko> I am not a devolper I just want this to be move to proirity for 8.04
<mjg59> Uhm.
<mjg59> We already supply the driver from http://mxhaard.free.fr/spca5xx.html
<mjg59> So if it's not working, it would be nice to figure out why :)
<bethko> your it would
<bethko> yeah it waould
<bethko> I hate this keyboard
<mjg59> As long as you have linux-ubuntu-modules installed, the gspca module should be automatically loaded for any of those cameras
<hunger> Any idea what is breaking bluetooth?
<bethko> Any way , we also need a way to make video files.
<bethko> Is that package installed by defualt?
<mjg59> bethko: Yes
<bethko> ok
<bethko> so the problem seems to be making vedios and using the video phone.
<mjg59> ekiga should work fine with them
<bethko> should being the key word
<mjg59> Well, how does it fail?
<mjg59> It was happy with the gspca device I tried it with last month
<bethko> odd
<bethko> I have never been able to get the video phone to work
<mjg59> How does it fail?
<bethko> Well theres the issue of the cam feed not going through in self preview. and then I can never get it to connect to another person
<bethko> skype works fine for voice so I asume my hareware is ok.
<bethko> I work with the deaf and blind
<mjg59> If you hit alt+f2 and type gstreamer-properties, then click video and make sure the "Default Input" line is set to "Video for Linux", what happens when you click "Test"?
<bethko> Deaf people like to use their webcams to talk to each other
<bethko> Don't know. It's Sunday, I'm not in the office
<mjg59> Ok. If you could do that and let me know what happens, that would be helpful
<mjg59> It makes it clear whether it's a kernel issue or an application issue
<bethko> Video for Linux (v4l): Device "/dev/video0" does not exist.
<bethko> I don't have any webcams here though
<mjg59> Right, sorry, I meant with your work machine
<bethko> oh, yeah that would probalay be more usefull
<bethko> The webcam issues are keeping a lot of deaf people from switching
<bethko> to Ubutu
<bethko> I need a new keyboard too
<mjg59> We'd love to fix them, but as I said everything works here, so it's hard to know what the problem is
<bethko> Do you know of any way to recoerd the webcam feed to a video file?
<mjg59> cheese can do it
<bethko> cheese?
<mjg59> Yeah
<mjg59> Should show up in synaptic
<bethko> Not to mention make me hungry
<bethko> Didn't find it
<mjg59> It's in universe in gutsy
<bethko> I'm using 7.04
<mjg59> Yeah, it's new
<bethko> Last time I upgraded to beta firefox got lost for a month
<mjg59> Final will be out on the 18th
<bethko> I have to wait 18 more days, how unfair
<Whoopie> mjg59: btw, did you find the time to look at uswsusp?
<mjg59> Not yet
* hunger hopes that bluetooth will work again by then.
<mjg59> hunger: What's up?
<hunger> mjg59: Doesn't work in either kubuntu or ubuntu.
<mjg59> Works for me
<hunger> mjg59: kubuntu complains about there being no bluez running, ubuntu says nothing.
<mjg59> Hm. I'll take a look.
<hunger> and that is after i removed the junk from the start of the kblueplugd.
<hunger> mjg59: There are several bugs open about bluetooth, so I did not open yet another one.
<hunger> Toggeling BT on/off does no longer work on my thinkpad either... have to set the stuff via /proc/acpi/ibm/bluetooth:-(
* hunger thinks that feature was lost somewhere before feisty...
<Whoopie> mjg59: your latest hotkey-setup changed the hotkey mask for thinkpads to 0xffffff. doesn't this turn on bluetooth control in userspace?
<mjg59> Whoopie: Hm, yes. That really ought to be fffeff
<mjg59> Thinko on my part. I'll rectify.
<Whoopie> mjg59: /etc/modprobe.d/thinkpad_acpi.modprobe has 0xffff8f.
<mjg59> Nf. Yes, sorry, ffffef
<Whoopie> mjg59: why do you change the mask?
<sladen> Whoopie: so we can get bits  0xffxxxx  which are the special thinkpad/volume/zoom/brightness/light keys
<Whoopie> sladen: hi
<superm1> well that's odd, an update appears to have made my thinkpad display+/- keys not show correctly in the gnome display for brightness
<Whoopie> sladen: why do you change 0xffff8f to 0xffffef?
<sladen> Whoopie: to try and leave the vga switching in hardware
<mjg59> Whoopie: To let the video handling be done in software on drivers that support it
<Whoopie> ok, thanks
<Whoopie> mjg59: I never understood this mask ;) It's not well documented.
<poningru> anyone able to install codeanalyst?
#ubuntu-devel 2008-09-22
<RAOF> I've recieved some FTBFS mail from xserver-xorg-video-intel on {hppa,ia64,sparc,powerpc}.  But these archs aren't specified in the -intel Arch: list; why have the builds been queued at all?
<TheMuso> RAOF: Very good question.
<Hobbsee> RAOF: because soyuz doesn't use it?
<Hobbsee> RAOF: it needs to be put in p-a-s, afaik
<jcristau> it is in p-a-s
<RAOF> Another question would be why these archs _aren't_ on the arch list, because it appears to build fine.
<RAOF> Until the binary-arch target gets called with DH_OPTIONS-
<RAOF> Until the binary-arch target gets called with DH_OPTIONS=-s, and dh_* complains that $ARCH isn't on the arch list.
<jcristau> RAOF: if you have an intel graphics chip on powerpc, i want to see it
<RAOF> Ah.  _That's_ why it's not on the arch list? :)
<jcristau> yes
<RAOF> Fair crack o' the whip
<Hobbsee> drat.  merges.ubuntu.com isn't working.
<Hobbsee> cjwatson: can you poke it into working, please?  :)
<cjwatson> no (as in no access to do so). Ask Keybuk when he gets back from travelling or doko when he gets back from sick leave
<Hobbsee> okay, will do, thanks.
<dholbach> good morning
<dholbach> bryce: do you think you could comment on bug 272145 and subscribe ubuntu-archive if that's OK?
<didrocks> dholbach: hi \o/
<dholbach> hi didrocks :)
<didrocks> dholbach: do you know when the next EMEA membership meeting will be attending as the previous one has been canceled (https://wiki.ubuntu.com/Membership/RegionalBoards/EMEA)
<dholbach> didrocks: no, no idea - it might be worth mailing the regional board about it
<didrocks> dholbach: I wasn't aware of a dedicated ML for that. Thanks, I will look for it :)
<dholbach> I think there is, if there isn't mail the members of the board :)
<didrocks> found it, LP was my friend. Thanks Daniel :)
<stefanlsd> didrocks: let me know if u have any luck from that, i was also sheduled to attend..
 * soren wuold like to request some archive admin love for ec2-init (source NEW in Intrepid)
<dholbach> hiya soren
<highvoltage> hiya soren
<soren> hi, guys. :)
 * ogra wonders why he just read "Totem BBQ plugin" in cjwatson's last mail ... its not even lunchtime 
<jussi01> ogra: nice one :P
<thekorn> exit
<didrocks> stefanlsd: ok. I will keep you in touch
<ogra> cjwatson, is there any special code thats not in the livecd-rootfs package on cdimage that prevents recommends from being processed for the squashfs ? i'm getting weird errors trying to build a local ubuntu-mobile image with the livecd-rootfs from the archive (mono-common installing binfmt-support which prevents proc from unmounting)
<cjwatson> ogra: I think it just relies on apt for that
<ogra> but uses recommends ?
<cjwatson> ogra: cdimage doesn't have a separate livecd-rootfs package - it just uses what's in the archive
<ogra> weird
<cjwatson> it should use recommends, but it may depend on the base system you use
<ogra> why do we get proper livecds then ? it should expose the same issue
<cjwatson> because it relies on the base system's apt
<cjwatson> if you're building on a hardy system then it won't work
<ogra> aaah !!!
<ogra> indeed
<cjwatson> our live filesystem builds use a chroot-in-chroot approach; intrepid live filesystems are built starting from an intrepid chroot
<cjwatson> so you'll need to do the same
<ogra> you mean from a hardy chroot ?
<cjwatson> intrepid live filesystems are not built from a hardy chroot, no ...
<cjwatson> though if you're building a hardy filesystem, sure, use a hardy chroot
<ogra> no, i'm building intrepid on an intrepid system
<ogra> which makes it indeed install recommends ...
<cjwatson> well, that's as designed. However, we should make livecd-rootfs cope with binfmt-support being installed
<ogra> and in turn pulls binfmt-support in from mono-common ... which prevents unmounting proc ... if we use an intrepid chroot on cdimage that should happen there as well, no ?
<cjwatson> that's easy and I'll fix it now
<ogra> yeah, indeed
<ogra> but i wonder why we get proper livefs'es
<cjwatson> binfmt-support is installed in our live filesystems
<ogra> that recommends exists since ages ... and should apply there as well
<ogra> oh
<ogra> why does it block here then ?
 * ogra scratches head
<cjwatson> however, because the livefs buildds are running on a hardy kernel without the binfmt_misc module loaded, binfmt-support fails to mount /proc/sys/fs/binfmt_misc
<ogra> aha !
<ogra> ok, thats clear
 * ogra hacks around that for his local testbuilds for now ... 
<cjwatson> I've committed a fix to livecd-rootfs bzr
<ogra> thanks
<ogra> hmm, doesnt that need to go into "cleanup" as well ?
<cjwatson> no, cleanup looks at the MOUNTS variable set out there
<ogra> ah, k
<cjwatson> in fact it's the only thing MOUNTS is used for ...
<cjwatson> I'll move that up to cleanup for clarity
<lool> cjwatson: Ah thanks for the explanation and the quick fix
<lool> Didn't think of the kernel not allowing binfmt
 * ogra sighs ... if i now would get uncorrupt packages files from the archive i could actally make use of the fix ... 
<cjwatson> I uploaded livecd-rootfs with that, btw
 * ogra saw that, thanks
<ogra> but somehow i always get corrupt Packages files atm
 * ogra goes to make a coffee hoping the issue resolves itself inbetween
<ogra> ah, better :)
 * ogra grumbles ... its all seb128's fault ...
<ogra> The following packages have unmet dependencies:
<ogra>   ubuntu-mobile: Depends: nautilus but it is not going to be installed
<ogra> seems i have to spend my day with twiddling thumbs ....
<lool> ogra: Can't we fix this with some rebuilds?
<ogra> lool, i think i just have to wait until all nautilus builds are there
<ogra> nautilus-cd-burner, nautilus-share and nautilus have to be there together ... likely only one has built yet
<lool> nautilus is only missing on hppa
<lool> ncb is at 2.23.90 on all arches
<ogra> nautilus-cd-burner ainst uploaded ...
<ogra> *isnt
<lool> ogra: We can fix that too  :-P
<ogra> i'm not sure i want to fiddle in sebs area and break stuff
<torkel> lool: by cloning seb128, so he uploads stuff faster?
<lool> ogra: Actually we're up-to-date in terms of ncb; latest is 2.23.90
<seb128> what is broken on what architecture?
<seb128> there is no update breaking nautilus
<ogra> seb128,
<ogra> The following packages have unmet dependencies:
<ogra>   ubuntu-mobile: Depends: nautilus but it is not going to be installed
<ogra>                  Depends: nautilus-cd-burner but it is not going to be installed
<ogra>                  Recommends: nautilus-share but it is not going to be installed
<seb128> I mean it's not waiting on other updates
<lool> ogra: What's the reason for the uninstallability?
<ogra> trying to build a livefs here
<seb128> sudo apt-get install nautilus
<ogra> seb128, lpia
<lool> ogra: Try apt-get install nautilus nautilus-cd-burner nautilus-share
<seb128> I guess it's an arch all any mismatch during the time between the i386 and lpia builds
<seb128> should be autosolved in the next run
<ogra> yeah, thats what i expected
<ogra> lool, btw: nautilus: Depends: nautilus-data (>= 1:2.24) but 1:2.23.92-0ubuntu1 is to be installed
<ogra> just a sync prob
<seb128> it built on i386 and lpia so next published run should fix the issue
<seb128> try updating that might already be fixed now
<pochu> cjwatson: hi. do you know if the "Generating server key" dialog in totem is from the new BBC plugin?
<cjwatson> pochu: it's not
<cjwatson> I don't see that string anywhere in the totem source
<ogra> seb128, trying every 10 mins anyway ... i have a looping script :)
<lool> Hmm lots of DEBUG output in my .xsession-errors; don't think it's my doing to turn this on
<pochu> same here
<lool> x session manager stuff
<james_w> lool: I believe the last gnome-session upload turned that off
<lool> ah just need to re-login, thanks
<lool> i was trying to find out what's happening to the totem bbc plugin
<ogra> yippie, finally all in sync
 * ogra watches his livefs build going on
<siretart> any reason why we call halt on shutdown with -i? This causes the network interfaces to be shut down with the consequence that this breaks wol and iscsi (at least this was just reported to me)
<siretart> cf. bug #71418
<ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed] https://launchpad.net/bugs/71418
<ogra> we dot want iscsi and wol users ... they just file new bugs :P
<liw> what is wol?
<ogra> wake on laugh
<liw> ah, wake-on-lan?
<siretart> ogra: I take that as a joke, yes?
<siretart> liw: right
<ogra> siretart, indeed
<siretart> TBH, I see no reason to do that, and I'm inclined to just change the default in sysvinit.
<ogra> i'd agree, but probably ask Keybuk ...
<siretart> keyb<tab><tab>: ^^
<siretart> damn..
<ogra> yeah
<ogra> he is likely jetlagged
<liw> Keybuk is likely to just replace shutdown with a new program, called downstop
<TheMuso> o/c
<pitti> hello everyone
<geser> Hi pitti
<ogra> welcome back pitti
<TheMuso_> i/c
<rgreening> hey all. I was going to work on packaging compiz 0.7.8. Anyone willing to take my diff and build/upload once done? :) (Assuming we can put 0.7.8 in Intrepid).
 * ogra scratches head why evolution and epiphany get installed in ubuntu-mobile
<rom1v> hi
<rom1v> will flash player 10 in default repositories in intrepid?
<rom1v> I know it's a RC, but it supported pulseaudio and should avoir some crashes of firefox
<rom1v> s/supported/supports natively/
<ogra> hrm
<ogra> seems totem-mozilla pulls in epiphany instead of using the "Provides: www-browser" entry from midbrowser
<ogra> at least thats my only idea ...
<seb128> ogra: Recommends: epiphany-browser | www-browser
<ogra> seb128, yeah
<ogra> but thats the only connection i see to epiphany at all in the seed
<ogra> midbrowser should fulfll www-browser"
<seb128> well, try to apt-get install using -o Debug::something
<seb128> mvo can tell you the something to use ;-)
<ogra> i need a clean chroot first i guess
<mvo> ogra: apt-get install -o debug::pkgdepcache::autoinstall=true
<mvo> ogra: (or dist-upgrade of course)
<rom1v> will flash player 10 integrated in intrepid (medibuntu)?
<kirkland> I'm hoping someone can provide me some background that I'm missing... I've heard multiple times now that there's efforts and hope inside of Ubuntu to do away with group-based permissions for devices.  pitti and mdz said as much in Bug #156085 ...  What's the reasoning and rationale for this?  Is it documented somewhere in the wiki?
<ubottu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Medium,Confirmed] https://launchpad.net/bugs/156085
<ogra> mvo, hmm, no epiphany-borwser in there
<ogra> how the heck does it get into the image ...
<mvo> ogra: if you give me instructions what to look for (or how to reproduce etc) I can investigate
<ogra> mvo, well, i just test the ubuntu-mobile liveimage (locally built using a modified livecd-rootfs)
<ogra> and somehow epi shows up in there
<ogra> the only thing i see in the seed that could even remotely cause that is totem-mozilla that has  Recommends: epiphany-browser | www-browser ... though midbrowser is in the seed and provides www-browser
 * ogra waits for the publisher run to build a new image 
<mvo> ogra: is it possible that install ordering plays a role here? i.e. that before midbrowser gets "markedInstall()" totem-mozilla is processed?
<ogra> it might be
<ogra> i have moved totem-mozilla to the very bottom of the seed file, but according to cjwatson that cant happen
<ogra> we discussed such cases before
<cjwatson> seeds shouldn't significantly influence the order in which apt does the marking
<ogra> i just noticed there was still a task header in the seed file pointing to ubuntu-desktop ...
<ogra> though i dont see how that could pull in epi either
<cjwatson> the only way in which they could influence it would be by way of making the Packages file look different (e.g. the list of dependencies of a metapackage)
<cjwatson> seed *ordering* has absolutely no effect on apt, either way
<ogra> right
<ogra> could the leftover task stuff have any influence ?
<ogra> -Task-Key: ubuntu-desktop
<ogra> -Task-Seeds: desktop-common
<ogra> i just dropped this now
<cjwatson> I can't imagine how
<cjwatson> that affects tasksel, and the Task-Seeds has some effect on germinate's resolution algorithm, but that's all; neither of those are seen by apt
<ogra> right
<cjwatson> can I see the build log?
<ogra> no, i dont have one
<ogra> i wait for the publisher to promote the last ubuntu-mobile-default-settings, then i can do a new build and will log it
<ogra> that should reveal something i hope
<cjwatson> this is the sort of situation that has revealed bugs in apt in the past; unfortunately they tend to be very very subtle bugs in the sort of area where if you change it you break the rest of the distro
<ogra> well, i wouldnt have a prob to apply a hack that removes epi if ubuntu-mobile is used in livecd-rootfs for the moment
<ogra> if the above would be the actul case
<ogra> *actual
<ogra> but first lets see whats going on
 * ogra pokes the publisher ... go ... copy to archive ... 
<yao_ziyuan> intrepid's pidgin 2.5.1 has a bug related to "smooth scrolling"
<yao_ziyuan> when it is enabled (it is, by default), the scrolling may not catch up with text flows in an irc channel
<_Zeus_> really?
<_Zeus_> can't confirm
<yao_ziyuan> use intrepid alpha 6's pidgin to watch #wikipedia
<yao_ziyuan> it's very hot right now
<seb128> bugs should go on launchpad
<yao_ziyuan> just disable smooth scrolling and the bug is gone
<_Zeus_> im in #ubuntu
<_Zeus_> yeah, sorry, i can't duplicate it
<ogra> yay, finally the publisher has run
 * ogra starts a new build
<ldp> hello
<cjwatson> today is one of those days when I wish I *really* understood termios
<cjwatson> (bug 273189)
<ubottu> Launchpad bug 273189 in console-setup "non-ascii layout/encoding problems at "login" line" [High,Confirmed] https://launchpad.net/bugs/273189
<cjwatson> ah, this is what Stevens is for
<ogra> cjwatson, hrm, looks like me removing the Task stuff from the seed http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid/revision/1307 results in the metapackage to fall apart http://paste.ubuntu.com/49371/
<cjwatson> err, yeah, you probably ought to talk to me *before* removing Task headers from seeds ;-)
 * ogra doesnt get why ... the mid seed doest have that section either
<ogra> well, its bzr ... easily reverted
<ogra> but i wonder why that didnt happen with mid
<cjwatson> well, it depends what you want to happen
<cjwatson> the stuff you had in the seeds said "please include everything in the desktop-common seed in this task"
<ogra> i just found it not appropriate ... sine most of mobile duplicates desktop
<cjwatson> by removing it, you have said that you no longer want that to happen, and germinate-update-metapackage is acting accordingly
<cjwatson> it's not removing the entirety of your seed by any means
<cjwatson> but if you want the stuff in desktop-common (NOTE THIS IS NOT DESKTOP) then you should leave it in; if you don't, you should remove it
<ogra> no, just the stuff from desktop-common, i see
<ogra> so i leave that one line ?
<ogra> or the whole stuff from the top ?
<cjwatson> the Task-Key: ubuntu-desktop was probably wrong, but you should replace it with a different key package, not remove it
<ogra> ok
 * ogra fixes
<cjwatson> the point of Task-Key is to say that the task should only be displayed by tasksel if that package is present
<cjwatson> if you remove it, then your task will appear on all installation media, which you don't want ;)
<ogra> right
<ogra> i'll change it to ubuntu-mobile instead
<cjwatson> yes, that's reasonable
<tkamppeter> pitti, hi
<mathiaz> slangasek: hi - is the daily -server iso creation enabled again ? The last daily iso available on cdimage is 20080917.
<mathiaz> radix: hi - I'm looking at bug 268765 - I'm not sure that an hourly cron job is necessary. Would a daily cron job be enough ?
<ubottu> Launchpad bug 268765 in landscape-client "landscape-client must have a cron job for updating smart package data" [Critical,In progress] https://launchpad.net/bugs/268765
<mvo> hourly would certainly be more friendly to the servers and mirrors
<mvo> eh, I mean, "daily would ..."
<mathiaz> mvo: how often is update-notifier run ?
<mvo> mathiaz: daily
<slangasek> mathiaz: mmm, re-enabled now
<slangasek> mathiaz: sorry, I think that was overlooked because I was waiting to hear back from mythbuntu
<slangasek> superm1: ping
<superm1> slangasek, yup disks looked good
<slangasek> superm1: "disks" - 20080921?  I should push these as alpha-6 alternates?
<superm1> yeah
<superm1> that's the one i used
<slangasek> superm1: published, cheers
<superm1> thank slangasek
<slytherin> Hi all. Can anyone please tell me whet is the reason daily builds are not done post alpha6?
<slangasek> a delay in turning the cronjob back on, while waiting for one of the flavors to catch up
<slytherin> slangasek: which flavor? lpia?
<slangasek> flavor, not architecture; it was mythbuntu.
<slytherin> oops
<slytherin> slangasek: so when can I expect new daily build?
<slangasek> within 24h
<slytherin> cool. Thanks
<slytherin> By the way, any idea why OOo is failing to build again for powerpc?
<slangasek> well apparently, because it doesn't build on anything but x86 now
<slytherin> :-(
<slangasek> ERROR: error 65280 occurred while making /build/buildd/openoffice.org-2.4.1/ooo-build/build/OOH680_m17/bean/native/unix
<slangasek> that's the ppc failure
<slangasek> /usr/bin/ld: cannot find -ljawt
<slangasek> and that's the root error
<slytherin> looks something related to java, but have no idea why it is not failing on 386 for same reason.
<slytherin> slangasek: just a hint, probably doko has more clue. The failure might be related to the fact that default-jdk on powerpc points to cacao and not openjdk.
<mathiaz> slangasek: what do you think about asking openldap administrators if they want to convert slapd.d/ (as suggested in https://lists.ubuntu.com/archives/motu-council/2008-September/001528.html) ?
<slangasek> mathiaz: what's the alternative to converting, if they say no?  I didn't think the code was still present to manage the package elsewise?
<mathiaz> slangasek: right - if they say no, slapd/no_configuration could be set to no
<slangasek> well, ok
<mathiaz> slangasek: and basically none of the maintainers script would run
<slangasek> in that case, this should be made very clear in the prompt
<slangasek> but for my part, I don't think a question is /needed/
<mathiaz> slangasek: considering that there is slapd/no_configuration, the advanced sysadmin could set it to no before doing the upgrade
<slangasek> yes
<slangasek> I certainly disagree that the config file format is an "essential decision" to be left in admins hands
<mathiaz> slangasek: ok - so I'll make sure that slapd/no_configuration won't run any maintainer script.
<slangasek> isn't that already the case?
<mathiaz> slangasek: I think so.
<slangasek> jdstrand: I think we need to put our heads together on bug #270328 at some point; it looks like we have some very bad interaction between auth-client-config and pam-auth-update, and I think auth-client-config probably needs to be commenting out more than it currently does
<ubottu> Launchpad bug 270328 in pam "libpam-runtime uninitialized values" [Undecided,Fix committed] https://launchpad.net/bugs/270328
<jdstrand> slangasek: what do you think needs to be commented out? it corrently comments out non-comments in a distinctive way
<slangasek> jdstrand: it needs to comment out the comments :-)
<jdstrand> slangasek: well, that is quite a change I think...
<slangasek> jdstrand: there are certain comment lines that pam-auth-update uses as sentinels, and if they're not commented out, pam-auth-update will obliviously continue to update
<jdstrand> slangasek: wouldn't it be easier to just check for pre_auth-client-config?
<slangasek> the user in the bug report did: upgrade to new pam and get the pam-auth-update setup; run auth-client-config (somehow, even though he didn't know it); then upgrade something that triggered pam-auth-update again and broke the world
<slangasek> well, currently pam-auth-update treats any of those lines verbatim
<slangasek> I guess we could argue about which tool's responsibility it is to parse comments ;)
<jdstrand> slangasek: I am not totally up on the pam-auth-update mechanism, but it seems the problem was the 3rd step
<slangasek> sure
<jdstrand> slangasek: it didn't honor changes made by the user via auth-client-config
<jdstrand> (side-stepping the fact that the user didn't know he did that)
<jdstrand> slangasek: but, maybe I don't see the whole picture...
<jdstrand> s/user/user claims he/
<slangasek> well, I'm arguing that auth-client-config should be the tool that stops the third step from destructively munging stuff, rather than asking pam-auth-update to recognize auth-client-config specifically
<jdstrand> slangasek: I can see that, but I can also see that it the user uses a tool to update his pam config, then it is conceptually the same as the user doing it without the tool
<jdstrand> slangasek: and pam-auth-update should detect that, no?
<mathiaz> slangasek: hm - manual_configuration_wanted is only called with a new install is made - not in postinst_upgrade_configuration.
<slangasek> can you propose a method for detecting it reliably?
<jdstrand> slangasek: yes-- grep for pre_auth-client-config
<slangasek> jdstrand: er, no
<slangasek> jdstrand: a method for detecting reliably /that a user has updated his config without the tool/ that will break things
<jdstrand> slangasek: no-- like I said I don't know the pam-auth-update system
<jdstrand> slangasek: but I was talking conceptually
<slangasek> jdstrand: the assumption that pam-auth-update makes is that if the magic comments are present, everything between them is to be managed by pam-auth-update
<jdstrand> ie, the admin actively did it as opposed to packaging, etc
<slangasek> right; and conceptually, pam-auth-update currently treats the two cases the same - if you comment out these lines, using auth-client-config or by hand, things will break ;)
<jdstrand> slangasek: so you look for the sentinel, if it is there, you (effectively do a) sed?
<slangasek> effectively
<jdstrand> slangasek: so non-matching 'sed' lines are ignored?
<jdstrand> (left in)
<slangasek> well, it's not exactly line-based so the analogy breaks down somewhat; but yes
<slangasek> there's actually a whole block that's left untouched, with the expectation that it's provided by the template and doesn't require management
<jdstrand> slangasek: so if a user is reckless and doesn't remove the sentinels but adjusts by hand, is there detection for that?
<slangasek> and then there's a block which is parsed and then overwritten
<slangasek> no; if there were detection for that, we shouldn't need sentinels...
<jdstrand> slangasek: so you are asking if I could also comment out the sentinels?
<slangasek> yes
 * ogra cries
<jdstrand> slangasek: this is likely not something I can do well before beta
<jdstrand> slangasek: it will likely require quite a bit of testing
<slangasek> jdstrand: do you agree with it in principle, or should I find a different approach?
<jdstrand> slangasek: I'm not sure I agree-- cause it only fixes part of the problem-- a reckless user still gets in trouble
<jdstrand> slangasek: is it possible to compare what you expect to be there with what is there?
<slangasek> only by encoding the information about that block in places I didn't want to have it
<slangasek> the intention was to have this section managed entirely via the template
 * jdstrand thinks
<jdstrand> slangasek: is there some sort of a hook you use to call the pam-auth-update mechanism?
<slangasek> it's called from maintainer scripts of packages which provide PAM modules
<jdstrand> slangasek: btw, a quick way to fix this for beta is to scan for that string I mentioned, until a proper solution is found
<slangasek> and may end up in the System->Administration menu for intrepid if all goes well
<slangasek> jdstrand: I'm not sure why having pam-auth-update scan for that string is any quicker or less error-prone than having auth-client-config modify the sentinel comments :-)
<jdstrand> slangasek: I was just thinking maybe something could be done in preinst-- before anything is unpacked, to try to capture the current state of things
<slangasek> the preinst of what?
<jdstrand> the packages being updated. but this is more 'thinking out loud' to fix the 'reckless user' scenario
<slangasek> there shouldn't be any need to resort to a preinst
<slangasek> since the only thing touching the config is pam-auth-update itself, which could save the state; but I don't think that's the issue, we want to keep the config from getting broken, not just save a copy of the good config :-)
<jdstrand> slangasek: right-- but if the saved state is not what you expect it to be, then you've caught your reckless user, haven't you?
<slangasek> oh, you're asking to save the template block
<jdstrand> I'm not suggesting anything, other than thinking of a way to detect user changes
<jdstrand> :)
<jdstrand> trying to think of a way...
<slangasek> I think I'd almost rather have pam-auth-update know directly what pam modules are supposed to be in that block, hmm
<slangasek> which isn't a good idea, for $handwavy_reason
<jdstrand> slangasek: is it fair to say that auth-client-config cannot be used with the new pam framework?
<slangasek> jdstrand: the config needs to be controlled by one or the other; they don't play well together
<jdstrand> slangasek: meaning, a user prefers to use auth-client-config
<jdstrand> ok
<slangasek> given that a-c-c comments out key bits of the pam-auth-update stack :-)
<jdstrand> but a user can't really choose to use auth-client-config anymore-- as pam-auth-update is in packaging
<slangasek> but, /if/ pam-auth-update detects "manual" editing of the file (like, the sentinel comments have gone away), the next pam-auth-update call will ask a one-time question of whether the user wants to overwrite
<slangasek> (defaulting to 'no')
<jdstrand> slangasek: yes, and I see that I can make auth-client-config work by doing that. I just wonder about other tools, homegrown scripts, admins, etc
<slangasek> anything that overwrites the PAM config completely will be detected by pam-auth-update
 * jdstrand nods
<jdstrand> basically, the sentinel has to be gone
<slangasek> and editing the options passed to the managed PAM modules will be handled transparently, with no need to choose
<slangasek> it's just the case of leaving those sentinels in place, but commenting out other bits of the framework, yes
<jdstrand> slangasek: are these sentinels expected to change, be added to, etc?
<slangasek> the sentinels themselves should never change
<jdstrand> slangasek: I didn't realize beta freeze is on the 25th-- there is really no way I can do this before then
<jdstrand> slangasek: I can try to get a fix going-- but auth-client-config might need to be removed if I can't
<slangasek> well, if we agree on the solution, I think I could get some time in on implementing it?
<jdstrand> slangasek: I'd really prefer some way to detect user changes, as people are still going to shoot themselves in the foot regardless of what happens with a-c-c
<slangasek> detecting user changes reliably in all cases would have to come at the expense of some of the smoother management features, I fear
<jdstrand> slangasek: is it unreasonable to grep for pre_auth-client-config and prompt the user saying there were user changes? or does the fact that the sentinels are there, regardless of detecting the a-c-c string, cause other issues?
<kirkland> bryce: hiya, i was wondering if you had any thoughts on: https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/218105
<ubottu> Ubuntu bug 218105 in kvm "fullscreen mode a bit broken in dual-head setups" [Undecided,New]
<slangasek> jdstrand: the only issue I have with grepping for pre_auth-client-config is that it means pam-auth-update will treat a-c-c-altered config files different from those edited directly by the user
<jdstrand> slangasek: that might be where there is a disconnect-- I don't see a difference between user changes via a-c-c and a text editor. can you explain?
<slangasek> jdstrand: er, a-c-c will have added a "pre_auth-client-config" line, and a user would not?
<jdstrand> (conceptually)
<slangasek> so at that point, we're special-casing a-c-c :)
<jdstrand> slangasek: well, obviously :)
<jdstrand> slangasek: I guess my point is that you are able to capture one class of user changes fairly easily in this manner. another class is those who do remove the sentinals. (a-c-c is obviously a subclass of those who don't remove them, but at least you can catch some)
 * slangasek happens, in a timely fashion, across a post on pam-list@ about LDAP authentication problems on a Red Hat system, fixed by typing: "authconfig --enablemd5 --enableldap --enableldapauth --ldapserver=10.100.223.63 --ldapbasedn="dc=ldaptest,dc=local" --enableldaptls --enablecache --enablelocauthorize --enablesysnetauth"
<jdstrand> slangasek: I also recognize that you don't want to be special casing all kinds of stuff
<slangasek> gee, I'm glad we don't have authconfig
<slangasek> jdstrand: right; I still think it'd be better if a-c-c commented out the sentinel lines, but if you're not convinced of this, I'll look for them in pam-auth-update
<jdstrand> slangasek: hmm... seems that if there isn't a way to check for these things, then I have to change a-c-c
<slangasek> hmm?
<slangasek> there is a way, 1) I write code to check for a-c-c comments, 2) I upload it :)
<jdstrand> slangasek: well, yes-- but you didn't seem to like that
<slangasek> I don't
<jdstrand> slangasek: really I care about wasted effort
<slangasek> just like you don't like the alternative :-)
<jdstrand> whether it's yours or mine is no matter
<jdstrand> slangasek: I was hoping to be able to detect the class of problems of users not removing the sentinels-- in which case a-c-c is covered
<jdstrand> slangasek: if that is not possible, I acquiesce that a-c-c should be changed-- as it seems to be the only other program to modify pam configuration in Ubuntu, and the alternative is it breaks things
<jdstrand> and by 'it' I of course mean pam-auth-update :P
<slangasek> in the future we might be able to detect the class of problems; but I think that's subtle enough that it's not likely to be done before beta, either
<jdstrand> slangasek: I'll give it a go
<slangasek> ok
<ogra> cjwatson, still here ?
<bryce> kirkland, taking a look
<slangasek> jdstrand: thanks for your patience :)
<ogra> cjwatson, i tried mvo's suggestion to use apt-get install -o debug::pkgdepcache::autoinstall=true ubuntu-mobile, there is a ton of stuff that doesnt belong into the seed http://people.ubuntu.com/~ogra/log
<kirkland> bryce: thx!
<jdstrand> slangasek: sure. I just updated the bug accordingly
<ogra> Installing epiphany-browser as dep of totem-mozilla ...
<ogra> Installing xscreensaver as dep of xscreensaver-gl
<ogra> recommends are definately not resolved correctly
<slangasek> ogra: what's not correct with the above?
<ogra> totme-mozzilla: Recommends: epiphany-browser | www-browser
<ogra> the metapackage depends on midbrowser which provides www-browser
<slangasek> and it's not correct because another www-browser is already installed?
<slangasek> ah
<slangasek> the package is ubuntu-mobile?
<ogra> xscreensaver-gl should be fulfilled with gnome-screensaver but pulls in xscreensaver additionally
<ogra> right
<ogra> using livecd.sh
<ogra> so only apt is involved
<ogra> no germinate or something
<slangasek> looks like totem-mozilla and midbrowser are both recommends rather than depends
<slangasek> but the ordering should still be correct
<ogra> right
<ogra> there shouldnt be any depends
<slangasek> i.e., Recommends: midbrowser should be resolved first, such that it's satisfied before reaching totemz-mozilla
<slangasek> sounds like an apt bug, then
<ogra> strange
<ogra> it should show up on the ubuntu-desktop cds as well then
<ogra> or i have a newer apt than the build chroot
<bryce> kirkland, yeah sounds like kvm needs to learn about libXrandr ;-)
<kirkland> bryce: okay, can you drop a note to that effect in the bug?  any pointers would be hot ;-)
<bryce> kirkland, I see similar such weird behaviors with most apps that take over full screen - games, mplayer, etc.
<bryce> alright
<ogra> mvo, can we look into that tomorrow ? ^^^
<kirkland> bryce: cool, maybe just reference another source package i could look at for proper behavior
<mvo> ogra: sure
<mvo> ogra: if you mail the full log I'm happy to check it out
<ogra> mvo, http://people.ubuntu.com/~ogra/log
<bryce> kirkland, ok I filled in some info on bug #218105
<ubottu> Launchpad bug 218105 in kvm "fullscreen mode a bit broken in dual-head setups" [Undecided,New] https://launchpad.net/bugs/218105
<kirkland> bryce: big thanks
<bryce> kirkland, if you do get that fixed up, I'd be interested in seeing the patch.  I suspect there's a lot of client apps that'll need similar fixing up (games particularly)
<kirkland> bryce: do you think this is doable for intrepid, or too invasive given FF?
<bryce> too invasive
<kirkland> bryce: k, thanks.
 * bryce ponders
<kirkland> bryce: i'll keep you in the loop
<bryce> there's actually several different bugs there, maybe one could be addressed
<mdke> andrew_sayers: around?
<andrew_sayers> mdke: yeah.
<mdke> andrew_sayers: could we move to #ubuntu-doc?
<andrew_sayers> Sure.
<bryce> kirkland, nope, I think you're going to need to code up something to hook into libXrandr, and that'll be a non-trivial bit of code, and will take a good bit of testing
<bryce> kirkland, depends a lot on how your fullscreen routine is implemented - if it already knows xrandr but is just incomplete, that might be workable, but I'll bet it's completely xrandr-ignorant so is going to take a couple week's work to code something up
<kirkland> bryce: okay, no problem.  we'll try to address that upstream with kvm between intrepid/jaunty then
<ion_> If i start a guest session, it doesnât seem to receive any keyboard/mouse events.
<ion_> I donât even have to ctrl-alt-Fx away from it, alt-Fx is enough.
<kirkland> bryce: grep -r xrandr on kvm sources = 0 hits
<bryce> hah
<bryce> well, try grep -ir randr
<geser> bryce: do you know if xserver-xorg-video-radeonhd is still actively developed? I ask because I see RV6xx sometimes mentioned in the changes for the -ati driver and wonder now if I still have the preferred driver for a RV670 based card installed (I use currently -radeonhd)
<bryce> geser, afaik there's still development on it, but -ati is the one getting most of the focus now
<bryce> geser: have you tried -ati with that card?
<geser> not yet, when I bought the card I installed -radeonhd as the description mentioned the used chipset
<geser> will try -ati the next days
<jcristau> geser: yes, it's still being actively developped by novell
<bryce> geser: fwiw, I have a rv635 that works with -ati, and I see RV670 mentioned in the source code so presumably it's supported
<geser> bryce: I've done a quick check with -ati and it works (I guess it's using the radeon module)
<geser> do you know which one it better? -radeon or -radeonhd?
<cjwatson> ogra: I have a suspicion that installing it as a task rather than as a metapackage will help
<bryce> geser: -radeon should pretty much have everything -radeonhd has, plus has support for older cards going back quite a ways.  I'd suggest using -radeon over -radeonhd
<ogra> cjwatson, well, but livecd-rootfs doesnt do tasks
<cjwatson> ogra: that ought to mark all the packages in the task for install *first*, and *then* go through resolving missing dependencies/recommendations
<cjwatson> ogra: sure it does!
<bryce> geser: in Ubuntu we really only officially QA -radeon, not -radeonhd, so if there are bugs with the former we'll help troubleshoot, but with the latter you're more on your own
<geser> bryce: thanks
<cjwatson> ogra: that's what those "^" symbols are for
<ogra> cjwatson, oh ? how ?
<ogra> ah
<cjwatson> ogra: however, ubuntu-mobile doesn't have a task yet; we'd need to get that fixed
<cjwatson> which requires a Launchpad code change ...
<cjwatson> can you mail me a reminder to take that up with Team Soyuz?
<ogra> cjwatson, meh, mid neither, i just copied the mid stuff and renamed s/mid/mobile/
<cjwatson> ogra: (this may be why we don't have this problem in the desktop, because we use tasks there)
<ogra> cjwatson, will do, thanks
<ogra> yeah
<ogra> indeed
<cjwatson> we just need to have Soyuz pay attention to the mobile seeds when doing task generation
<ogra> seems mid is the only metapackage without using ^
<ogra> in the code ...
<cjwatson> the mid seed doesn't even have any Task-* headers
<ogra> wasting my day on a missing ^ ... yay
<ogra> yeah
<ogra> thats what made me drop mine first
<ogra> it might even be fine for mid, not sure
<cjwatson> by luck, perhaps
<ogra> well, most hildon pkgs are native and have hard deps
<ogra> i doubt you'll find many recommends there anyway
<cjwatson> this has nothing to do with recommends AFAICS
<cjwatson> it's purely about the order in which broken dependencies are resolved
<ogra> but they all come from recommends here
<ogra> at least for me
<cjwatson> (er, sorry, perhaps that was confusing - by "broken" I mean "temporarily broken while apt has installed the top-level stuff but not resolved the dependencies yet")
<cjwatson> ogra: understood, but I think you'd see precisely the same effect if they were dependencies
<cjwatson> that's what I mean
<ogra> which appear to be resolved in a backwards order
<ogra> ah
<cjwatson> it's an ordering problem, not a dependency vs. recommendation problem
<ogra> yeah
<ogra> understood
<cjwatson> the problem (I think) is that apt is resolving the dependencies depth-first rather than breadth-first
<cjwatson> so it goes:
<cjwatson>  ubuntu-mobile
<cjwatson>   -> totem-mozilla
<ogra> yeah, i had something similar with java
<cjwatson>    -> epiphany-browser | www-browser (pick epiphany-browser)
<cjwatson>   -> midbrowser (oh dear, never mind)
<ogra> right
<cjwatson> germinate actually does the same kind of thing, but (like apt with task installation) it starts by installing all the seed entries, and then iterates through resolving their dependencies one by one (depth-first)
<cjwatson> whereas here you're starting with a single package and going depth-first
<ion_> Does aptitude have equivalent behavior?
<cjwatson> I suspect that finding the optimal set to install is computationally hard (not wanting to throw around terms like NP-complete casually but it wouldn't surprise me) and that there is no particularly easy simplification
<cjwatson> I haven't checked aptitude, but it's a perfectly natural way for a dependency resolver to work
<cjwatson> you don't skip around between nodes of the tree because that makes backtracking a complete pain in the arse
<cjwatson> so I am very reluctant to claim it as an apt bug as such
<cjwatson> it's certainly not optimal, but other similar simplifications of the global hard problem probably also have their drawbacks
<ogra> reminder mailed
<cjwatson> thanks
 * ogra seees apt-proxy hanging the 10th time on python-gtkglext1 and decides its time to find a stable apt proxy implementation
<ogra> so someone said i should try approx ... lets see
<mathiaz> ogra: I've been using apt-cacher-ng
<mathiaz> ogra: and it works well for me.
<ogra> well, apt-proxy used to work well for me the last years ...
<ogra> but i'm getting tired of the hangs
<mathiaz> ogra: right - I used apt-proxy for a while but also found that it would hang often.
<stgraber> ogra: I'm also using apt-cache-ng on some servers, work fine.
<stgraber> at home I usually have a transparent squid proxy so I don't need it
<ogra> well, i like the fact that i can carry my archive with me on the laptop
<ogra> so i prefer local proxies for that stuff
<stgraber> ok, so apt-cacher-ng is what you need
<slangasek> mathiaz: hum, are you going through the u-m-s list at the same time as me? :)
<mathiaz> slangasek: nope
<slangasek> oh, ok
<slangasek> just the one bug then :)
<mathiaz> slangasek: I've already been working on the landscape-client bug
<slangasek> ah
#ubuntu-devel 2008-09-23
<mathiaz> slangasek: is there a reason why the openldap group is not allowed to read the content of /var/lib/ldap ?
<mathiaz> slangasek: in intrepid, the openldap group is allowed to read /etc/ldap/slapd.d/
<slangasek> mathiaz: I'm gonna say "bug"
<slangasek> well, "oversight"
<slangasek> since the only user in the openldap group is normally the 'openldap' user, and that user /owns/ the dir, it's not an issue anyone's noticed before
<mathiaz> slangasek: ok - so the permissions on /etc/ldap/slapd.d/ and /var/lib/ldap/ should be 0750 ?
<slangasek> whereas openldap did specifically have read rights on /etc/ldap/slapd.conf before, because the config was owned by root and read-only by the openldap user
<slangasek> yes, that sounds appropriate to me
<mathiaz> slangasek: ok - however /var/run/slapd/ needs to be rx for other too
<mathiaz> slangasek: since the ldapi socket is located in there.
<slangasek> true
<mathiaz> slangasek: ok - I'm going to fix all of this then.
<cjwatson> hmm, strace of bash reading a pound sign (U+00A3 POUND SIGN, not #) typed at a prompt:
<cjwatson> 18:11:14.527910 read(0, "\302", 1)      = 1
<cjwatson> 18:11:16.898828 write(2, "\302", 1)     = 1
<cjwatson> 18:11:16.899325 read(0, "\243", 1)      = 1
<cjwatson> 18:11:16.899872 read(0, "\r", 1)        = 1
<cjwatson> 18:11:19.818306 write(2, "\n", 1)       = 1
<cjwatson> so where did \243 go, eh?
<mathiaz> slangasek: while trying to fix dpkg-reconfigure slapd, I've run into the issue of backups. dpkg-reconfigure slapd works the first time, but fails the second time since there is already a backup directory in /var/backups/.
<slangasek> mathiaz: hrm, interesting
<mathiaz> slangasek: should the backup directory be erased ? or create another one ?
<mathiaz> slangasek: the naming scheme of backup directory allow for one backup per package version.
<mathiaz> slangasek: could a timestampt be added to the directory name ?
<slangasek> right; I don't think we want to overwrite in all cases, because in some of those cases that means overwriting a good backup with a bad
<slangasek> timestamp could be ok, I suppose
<mathiaz> slangasek: if so what about proliferation of backup directories ?
<mathiaz> slangasek: It's a corner case though.
<slangasek> <punt> :)
<hikenboot> can anyone tell me if the python provided in ubuntu has been packaged so one could select a minimum for use with xen and xen tools currently I am building a distro with  something called T2 which is based on  slackware and it has a 40 MB install of python that I would like to minimize and am looking for a distro that might have already done this work
<mathiaz> slangasek: hm - the issue comes from the database backup from /var/lib/ldap. Adding a timestamp is implemented in the script but it won't work as expected.
<slangasek> mathiaz: because we need to be able to read from it again in a different script?
<mathiaz> slangasek: dumping a database and loading a database happened at different times
<mathiaz> slangasek: yes
 * slangasek nods
<mathiaz> slangasek: however the use of a timestamp is conditional
<mathiaz> slangasek: if OLD_VERSION is not set then a timestamp is used
<slangasek> ok
<mathiaz> slangasek: so that's not a problem on upgrades.
<slangasek> in this case, I guess $OLD_VERSION is set to the current version?
<mathiaz> slangasek: right
<mathiaz> slangasek: so the timestamp is never used IIUC.
<mathiaz> slangasek: and when you run dpkg-reconfigure slapd the second time, it fails.
<slangasek> I guess it would be used if /var/lib/ldap somehow existed, but the package wasn't previously installed
<slangasek> but having it be used when $OLD_VERSION == $current_version sounds like it might be a good idea
<mathiaz> slangasek: may be - I'd have to look into that.
<mathiaz> slangasek: I've also read some code that checks for reconfigure as the mode
<mathiaz> slangasek: or checks for DEBCONF_RECONFIGURE
<slangasek> reconfigure as the mode doesn't actually work today
<slangasek> I'm not sure if DEBCONF_RECONFIGURE is something that gets set
<slangasek> but that could be a good option, yes
<mathiaz> slangasek: I think that DEBCONF_RECONFIGURE works.
<slangasek> lool: was elisa-plugins-ugly meant to have an 0.5.9 version in Debian? (bug #262805)
<ubottu> Launchpad bug 262805 in elisa-plugins-ugly "Please sync elisa and plugin packages from Debian experimental" [Undecided,Confirmed] https://launchpad.net/bugs/262805
<slangasek> superm1|away: what's "the ogre mdel"?
<slangasek> model
<wgrant> slangasek: ogre-model is Soyuz's mangling of sources.list.
<wgrant> slangasek: Particularly the set of components that a component is allowed to build against.
<wgrant> (or other archives in the case of non-primary)
<slangasek> ah.  where does the "ogre" fit in? :)
<ajmitch> the ogre chews stuff up & spits it out?
<wgrant> Same way gina, kate, britney, Soyuz, etc. do, I guess.
<wgrant> *katie
<wgrant> But I don't know.
<wgrant> Nobody ever said that archive manager component names had to be sensible.
<slangasek> hmm, all those others I know the etymology of. :)
<wgrant> I guess you'll have to poke cprov. I'd be interested to know too.
<wgrant> Aha, it's a cprov.
<cprov> wgrant: yes, can I help you ?
<wgrant> cprov: slangasek and I were wondering what the ogre in ogre-model meant.
<cprov> wgrant: see http://en.wikipedia.org/wiki/Shrek_(character)
<cprov> wgrant: "...similarities between ogres and onions, observing both have *layers*..."
<wgrant> cprov: Aha, nice.
<cprov> wgrant: ubuntu components too ;)
<wgrant> Good choice.
<cprov> dsilvers idea ;)
<wgrant> Any other strange etymologies to be aware of?
<apachelogger> slangasek: hi, I attached a revised patch to bug 272383
<ubottu> Launchpad bug 272383 in kdebase-runtime "package kdebase-runtime 4:4.1.1-0ubuntu1~hardy1~ppa1 [modified: usr/lib/kde4/lib/kde4/libexec/kdesu] failed to install/upgrade: tentative de remplacement de ??/usr/bin/ksvgtopng??, qui appartient aussi au paquet kdelibs4-dev" [High,In progress] https://launchpad.net/bugs/272383
<dholbach> good morning
<persia> TheMuso: There's been a rash of requests from ~teresadd1-0 to be unsubscribed from bugs.  Would you mind deactivating the user from ~ubuntu-audio?
<TheMuso> persia: Sure.
<persia> TheMuso: Thanks.  Sorry for the confusion.  Please feel free to direct them my way if there are questions about the deactivation.
<TheMuso> persia: is that possible?
<TheMuso> hang on, getting used to the new interface.
<persia> TheMuso: When you deactivate someone, there is a text entry box for a comment.
<TheMuso> persia: Right.
<persia> So, since you might not be tracking all the "Please unsubscribe" bugs, if you want to blame me, that's fine :)
<TheMuso> Done.
<TheMuso> no I have seen a few of them, and thought they were only subscribed to the bugs themselves. Obviously they didn't know what they were getting themselves into. Many a time someone adds themselves to ubuntu-audio, only to leave a short time later due to the massive amounts of bug mail.
<anilg> how do I regenerate release and release.gpg using debarchiver?
<anilg> I have a .conf in my incoming directoty
<anilg> which specifies the gpg key, repository, etc
<persia> heh.  Yeah.  I remember hearing that the audio bugmail had reached a million messages around feisty :)
<TheMuso> persia: Wouldn't surprise me. I think I was a member then, but can't remember.
 * TheMuso uploads the last of several packages to tie some loose ends with audio, at least for the beta.
<Treenaks> *\o/*
<RAOF> Woo!
<RAOF> TheMuso: Incidentally, should I be upstreaming my pulseaudio 0.9.12 bugs or leaving them to you to do? :)
<TheMuso> RAOF: If you are still using pa 0.9.12, you ya not see some of these changes immediately. I need to port them to the package in my PPA.
<TheMuso> RAOF: Feel free to leave them with me, as I have a few other things to deal with upstream about.
<RAOF> TheMuso: Cool.  I'll leave them with you then.
<pitti> Good morning
<dholbach> hi pitti
<pitti> kirkland: https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/DevicePermissions describes our current efforts
<TheMuso> Anybody got any idea whats going on with scrollkeeper here? http://www.pastebin.ca/1209060
<TheMuso> This is a local build on my machine.
<nxvl> TheMuso: it's not calling sudo or something like that?
<dholbach> TheMuso: I'd not run scrollkeeper-update during the build (is there a --disable-scrollkeeper?)
<nxvl> TheMuso: or you are running it as normal user and it's not that inteligent to ask for root privileges
<slangasek> that doesn't really explain the "/luke" directory; but yeah, running scrollkeeper-update in a build is pointless
<dholbach> makes no sense to update the scrollkeeper index stuff on a build machine - dh_scrollkeeper should generate the maintainer script snippets
<dholbach> when are we using rarian fully instead of scrollkeeper? :)
<nxvl> well
<nxvl> time to sleep
<nxvl> have a nice day!
<dholbach> sleep tight nxvl
<nxvl> thank you!
<slangasek> dholbach: afaik we already are?
<TheMuso> dholbach: Gotcha there probably is, I'll have a look, thanks.
<dholbach> slangasek: OK, good :)
<dholbach> slangasek: seems it's still in main though
<slangasek> I still parse the name "rarian" as "a Debian derivative using rar as the archive format", though
<dholbach> hehe
<dholbach> I had some time getting used to the name, I packaged it when it was still called spoon and then went for rarian :)
<lool> slangasek: Yes, I'll still work on elisa-plugins-ugly; I didn't have time before going to Berlin, and it's just a set of additional plugins which don't prevent the player from working
<slangasek> lool: ok - I was just noticing the task was still open
<lool> Yup
<lool> slangasek: (Did you see the python-dateutil MIR?)
<lool> I need to do the python-cssutil one as well
<slangasek> MIR team is --> that way
<slangasek> (i.e., in Germany)
<persia> slangasek: on bug #271627: it's really a release-manager call.  If you're happier to wait and hope someone uploads linux-ports-meta and fixes everything, we may want to keep the arch-specific NBS stuff.  If you'd rather expose the problem now, and point out that the current model isn't supportable for updates or security, it may be good to push it sooner.
<ubottu> Launchpad bug 271627 in linux-meta "Please remove outdates ports binaries for linux-meta" [Undecided,New] https://launchpad.net/bugs/271627
<Koon> slangasek: could you please have a look at bug 272134 ? It's the likewise-open microrelease I told you about last week
<ubottu> Launchpad bug 272134 in likewise-open "[FFe] Update to 4.1.2982 bugfix microrelease" [Undecided,New] https://launchpad.net/bugs/272134
<davmor2> I got a memory leak in an app that I use all day but I don't know which what's the best tool to use to find out?
<wgrant> top
<wgrant> M
<seb128> valgrind
<RicardoPerez> hi! anybody knows who's the xdg-user-dirs package maintainer?
<seb128> RicardoPerez: there is none
<seb128> RicardoPerez: I do the update but that's about it
<RicardoPerez> seb128: thanks for the answer. I opened a bugreport (bug #271466) about the translations update. Is it what you're talking about?
<ubottu> Launchpad bug 271466 in xdg-user-dirs "Please, update the xdg-user-dirs translations before Intrepid release" [Undecided,New] https://launchpad.net/bugs/271466
<tjaalton> pitti: are you available to discuss about the hal/acpi-support/keymap-mess?
<seb128> RicardoPerez: there is no need to open bugs every cycle about xdg-user-dirs, yelp, etc
<seb128> RicardoPerez: we do update those translations before beta and before stable usually
<seb128> we should probably get a list of packages that need translations update before beta and stable somewhere
<Mirv> seb128: is there some process written down so all those are remembered and not depending on some developer's own memory?
<seb128> Mirv: read what I just wrote? ;-)
<RicardoPerez> seb128: ok, sorry about that. I opened that bug because the xdg-user-dirs was not updated on hardy & intrepid, and I didn't knew if it was normal. but again, sorry for that
<Mirv> seb128: right :) so, not yet. but a really good idea to have something like that.
<pitti> tjaalton: hi
<seb128> RicardoPerez: no problem
<liw> is there a wiki page that lists the members of the ubuntu release team?
<pitti> tjaalton: it's indeed a mess; I wasn't too surprised that uninstalling acpi-support actually fixed it for one reporter
<seb128> RicardoPerez: the translations should be in the language packs though no?
<seb128> RicardoPerez: language-pack-gnome-en-base: /usr/share/locale-langpack/en_GB/LC_MESSAGES/xdg-user-dirs.mo
<RicardoPerez> seb128: the xdg-user-dirs translations are in the xdg-user-dirs package, as I can see
<Mirv> RicardoPerez: the source package should be updated so that live cd has all languages with up-to-date translations for xdg-user-dirs so that correct directories are created
<RicardoPerez> $ dpkg -L xdg-user-dirs | grep "/es/LC_MESSAGES/xdg-user-dirs.mo"
<RicardoPerez> /usr/share/locale/es/LC_MESSAGES/xdg-user-dirs.mo
<davmor2> wgrant: top doesn't show it up it's only a small amount that I think simply isn't closing once used and all the apps I use all day bounce position valgrind one app at a time is more tempting though.  Thanks for the info
<seb128> RicardoPerez: right, read the changelog about that
<Mirv> to seb128, that is.
 * liw finds https://launchpad.net/~ubuntu-release/+members
<tjaalton> pitti: yeah.. I'd like to understand the role that hal plays with it, and how it all _used_ to work together in hardy
<seb128> Mirv: right, I said before I'll update those before beta
<RicardoPerez> seb128: oh, great. I just read it, I now know what you say
<tjaalton> pitti: but if you are here in, say, 20min, I'll go and grab some lunch first?
<pitti> tjaalton: yes, I will be
<RicardoPerez> seb128: so, are the xdg-user-dirs.mo file in both xdg-user-dirs package and the langpacks?
<tjaalton> pitti: ok cool, later
<liw> pitti, other release team members: I'd like to upload a new system-cleaner to fix #271234 and #271390, but they change the UI (command line and GTK both); would that be acceptable?
<seb128> RicardoPerez: right, and in such case the system one is used first so we need to update the package
<seb128> RicardoPerez: I'll do that before beta
<RicardoPerez> seb128: great, I understand now!
<RicardoPerez> seb128: thanks for the explanation
<seb128> no problem
<RicardoPerez> thanks again to everybody, cheers :)
<Mirv> seb128: what would be a good wiki page name for the "translation stuff that needs manual intervention for a release". though it's partially the same as https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
<Mirv> for example debian installer translations have to be manually exported and imported (not done for intrepid)
<pitti> liw: if the doc team is ok with that, fine for me; I don't expect that ubuntu-docs mentions the system cleaner yet, but it would be worth pinging them
<Mirv> and ddtp needs manual syncinc from Debian and upload to repos
<liw> pitti, ack, thanks
 * liw now needs to find the doc team
<murdok> Hey pitti , could you mark my bug 270335 as wishlist? Someone told me to ask it to you
<ubottu> Launchpad bug 270335 in apport "Feature: Support saving bug reports" [Undecided,New] https://launchpad.net/bugs/270335
<pitti> murdok: done, thanks
<murdok> pitti: thank you
<bigon> does anybody know where the perl function Dpkg::Changelog::find_launchpad_closes is defined?
<jcristau> bigon: /usr/share/perl5/Dpkg/Changelog/mumble.pm?
<jcristau> or just Changelog.pm actually...
<bigon> jcristau, thx
<pitti> didrocks: there?
<didrocks> pitti: yes, hi :)
<pitti> didrocks: just doing your g-v-m sponsoring
<pitti> didrocks: you kept 02_fix_autokeyboard_gconf.patch, but upstream already applied a fix
<didrocks> pitti: thx, is everything ok?
<pitti> didrocks: did you test this without the patch, is it really not working still?
<TheMuso> asac: FYI if you hadn't noticed already, I uploaded changes earlier so that all alsa apps will use pulse if pulse is running. If pulse is not running/not installed, there will be no change, apps will still use alsa/dmix.
<didrocks> pitti: let me check
<pitti> didrocks: if not, it should be reported to gnome bug 525345 and reopened
<ubottu> Gnome bug 525345 in general "AUTOKEYBOARD missing in gconf enum" [Major,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=525345
<asac> TheMuso: rock!
<asac> TheMuso: which package and version am i looking for (to test)?
<pitti> didrocks: also, your patch includes it in ENABLE_AUTOMOUNT, it shouldn't
<TheMuso> asac: alsa-lib 1.0.17a-0ubuntu2, alsa-plugins 1.0.17-0ubuntu2, and pulseaudio 0.9.10-2ubuntu4. Alsa-plugins is not so important, but its useful as I updated the code for the pulse plugin to the latest code, which performs much better.
<didrocks> pitti: yes, that's the reason, I was waiting it for found it in ENABLE_AUTOMOUNT
<TheMuso> asac: binary packagse for alsa are libasound2 and libasound2-plugins
<didrocks> strange that I didn't see it in searching over it with vi
<didrocks> pitti: so, the patch can be removed
<pitti> didrocks: ok, thanks for checking
<didrocks> pitti: sorry for the mistake
<pitti> didrocks: no problem
<didrocks> pitti: do you want me to redo a new diff.gz?
<pitti> didrocks: don't worry, already on it
<didrocks> pitti: thx :)
<pitti> didrocks: uploaded
<didrocks> pitti: thanks a lot!
<tkamppeter> pitti, I tried the new Jockey yesterday but it FTBFS, both on my box and on buildds, Have you fixed it?
<pitti> tkamppeter: locally, I'll do an upload today
<ogra> cjwatson, i copied the task headers into the mid seed as well, can you do the soyuz stuff for ubuntu-mid as well please ?
<ogra> (tell me if you need another reminder mail :) )
<cjwatson> ogra: it's done at a seed collection (or branch) level, not an individual seed level
<cjwatson> ogra: so we just need to get the whole mobile.intrepid seeds honoured, and then individual seeds within that will happen automatically
<ogra> ah, k so it happens automatically, great
<asac> cjwatson: pitti: bug 273514
<ubottu> Launchpad bug 273514 in libmbca "MIR - include libmbca and mobile-broadband-provider-info in main" [Undecided,Confirmed] https://launchpad.net/bugs/273514
<pitti> asac: ack
<tjaalton> pitti: back. Booted hardy livecd, and confirmed that xev does not show any of the hotkeys, which is not that surprising. but they do work though
<pitti> tjaalton: oh, it doesn't? so in hardy they were consumed directly by acpid or hal?
<tjaalton> pitti: yes
<pitti> tjaalton: it almost seems to me that acpi-support scripts and hal/hal-infoquirks/pm-utils are working/racing against each other
<tjaalton> pitti: now evdev grabs the input device created by thinkpad_acpi, so they are not passed on
<pitti> but that shouldn't have changed since hardy
<tjaalton> not all of them anyway
<kwwii> mvo, pitti: just wondering about the packages that I discussed per email...did they all make it in?yet?
<pitti> kwwii: haven't caught up with that yet; I sent you a reply with some change requests over the weekend
<kwwii> pitti: right, I was waiting to make sure that mvo didn't do it already :-)
<kwwii> pitti: I will fix up that stuff and add another package with a wallpaper, finished later today
<ogra> in which order do i have to do the bzr tagging ? changelog entry first an then bzr tag or the other way round ?
<pitti> ogra: "use debcommit -r, Luke"
<ogra> hmm
<kwwii> no doubt...debcommit is the way to go
<ogra> i have done dch already, will that mess up anything ?
<kwwii> then just do debcommit
<ogra> (i.e. do i need to revert that before =
<pitti> ogra: dch -r will do the UNRELEASED -> intrepid bit
<pitti> ogra: and debcommit -r will commt that change and tag it
<ogra> i always do -i :)
<pitti> ogra: no, dch is fine
<ogra> ok
<ogra> pffft
<pitti> ogra: but in general, I think it's "commit, then tag"
<ogra> yeah
<pitti> that's what I use anyway
<ogra> i already commited :/
 * ogra uncommits 
<ogra> ah, that looks better
<ogra> grrr
 * ogra curses ... 
 * soren pats ogra on the head
<ogra> setting DEBEMAIL helps :/
<ogra> sigh, and teher is no bzr untag
<Keybuk> ogra: bzr tag --delete
<ogra> ah
<ogra> gracias
<siretart> Keybuk: if you have a minute, could you have a look and give your opinion on bug #71418 please?
<ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed] https://launchpad.net/bugs/71418
<ogra> grmbl ... doesnt work for pushed changes indeed :/
<Keybuk> siretart: my opinion can be found at https://bugs.edge.launchpad.net/upstart/+bug/92685 already ;)
<ubottu> Ubuntu bug 92685 in upstart "noisy halt if /proc/ide doesn't exist" [Wishlist,Invalid]
<Keybuk> "both downing drives and interfaces should be things the kernel does these days"
<siretart> Keybuk: I read this as agreement that the NETDOWN variable should default to 'no'. right?
<Keybuk> siretart: no, I'll just take the -i option out of reboot one day so it won't matter what the NETDOWN variable is :p
<Keybuk> it's too late to change that variable for intrepid anyway
<siretart> Keybuk: I still don't get how removing the '-i' can potentially harmful. could you elaborate a bit?
<Keybuk> siretart: the fact you don't understand why it is yes is precisely the reason it shouldn't be changed this late in a cycle
<Keybuk> *I* don't understand why it is yes either
<Keybuk> but clearly someone felt it was important
<Keybuk> and since it has always been yes, that means by changing it, you may turn up new bugs
<siretart> so lets set it to yes after jaunty opens and see what breaks?
<Keybuk> siretart: that would be my choice
<siretart> ok. I'll copy that to the bug
<pitti> cjwatson, slangasek: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt -> that's just too good to be true, so I guess something went wrong?
<cjwatson> pitti: I'll fix it, thanks
<cjwatson> IOError: [Errno 2] No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu-germinate//all_edubuntu_intrepid_i386'
<pitti> ah :)
<pitti> cjwatson: cheers
<StevenK> Is component-mismatches-mobile.txt now dead, too?
<StevenK> I remember pitti raising that, but didn't see if it was resolved.
<cjwatson> yes
<cjwatson> cron.germinate is failing, that's the real problem
<cjwatson> RuntimeError: maximum recursion depth exceeded
<cjwatson> oopsie
 * cjwatson may have, err, slightly broken germinate
<ogra> infinity1, (oh, are there multiple ?) ... ping ... i added ubuntu-mobile to livecd-rootfs can you update teh build server to 0.69 so i can get a squashfs, looking at how the livecd imges are built though you seem to rename te resultig files though, tat might be something to talk about (as mine would also be called i386.*)
<cjwatson> ogra: it's updated from a daily cron job, IIRC
<ogra> ah, cool
<cjwatson> oh, well, not sure if the mobile one is
<cjwatson> the livefs buildds are
<ogra> though that still doesnt solve the file naming
<StevenK> The mid one is, but that's for lpia only
<cjwatson> our livefses are renamed too
<cjwatson> can't you just deal with it? :)
<StevenK> I think it's keyed off $PROJECT, though
<ogra> i just fear we use the same names
 * ogra goes to take a look
<ogra> aahhh ... its done in a per rpject subdir anyway ... ok
<ogra> *project
<StevenK> Like I said, keyed off $PROJECT
<ogra> right
<ogra> well, i have to see code to understand sometimes :)
<ulaas> hi! 2.6.27-4-generic missing nvidia kernel module. correct?
<pitti> ulaas: no, they aren't in the kernel any more
<pitti> ulaas: nvidia and fglrx are packaged separately now, independently from the kernel and its abi
<ulaas> pitti: very good. are packages rolled out already?
<pitti> ulaas: nivida-glx-{71,96,173,177}
<pitti> ulaas: jockey handles them quite nicely nowadays, so maybe just use the hardware drivers app
<pitti> ulaas: yes, they've been in intrepid for months
<stefanlsd> is the jockey* stuff the preferred way?
<pitti> stefanlsd: it's the most GUI friendly way, anyway; and I appreciate feedback whether it works :)
<stefanlsd> k. is it the default or something we should install?
<ulaas> pitti: it does not for me.
<ulaas> pitti: when i click install and turn on nothing happens.
<pitti> stefanlsd: we ship jockey by default, and nvidia detection and driver installation sohuld work out of the box
<pitti> ulaas: hm, interested in debugging it?
<ulaas> pitti: thats why i use intrepid :)
<ulaas> hmm just clicked the older one on the list which was 173
<ulaas> now it downloads
<ulaas> lemme get back with the results
<pitti> ulaas: which versions does it offer to you?
<ulaas> 177 and 173
<ulaas> 177 was already looked installed in synaptic
<pitti> and both are disabled, and clicking on 177 doesn't do anything?
<pitti> oh
<ulaas> so thats why clicking that one did not do anything but also did not report
<pitti> ulaas: so it was shown as disabled, the package is installed, and enabling it didn't work? (i. e. it was still shown as disabled afterwards)
<ulaas> pitti: exactly
<pitti> ok, I'd like to debug this, it should certainly at least give you an error message
<ulaas> pitti: i am your man... jockey just died on me now. i was trying to switch to 177 after a succesfull enable to 173
<pitti> ulaas: ok, let's do that in /query
<asac> pitti: i assume you still have too much backlog from plumbers to do MIRs today?
<asac> err MIRs == this MIR ;)
<pitti> asac: I can do high urgency stuff
<pitti> rest on Friday on archive day
<asac> pitti: yeah its high urgency ;) ... needs to be in for BETA and i need some broader testing before that
<pitti> asac: ok
<asac> pitti: but i think cjwatson also offered to help out
<pitti> tseliot, superm1|away: hm, seems that ulaas installed two nvidia driver versions at the same time; shouldn't they conflict to each other?
<tseliot> pitti: yes, they Conflct/Replace each other
<pitti> tseliot: oh, indeed, sorry; "rc" != "ii: :)
<tseliot> pitti: ???
<pitti> tseliot: (dpkg -l output)
<tseliot> aaah
<tseliot> ok
<pitti> hey warp10
<warp10> hi pitti
<digistyl3> hi everyone, does your gnome session remember the last used applications?
<digistyl3> i mean the running applications
<jerone> digistyl3: it can if you check the option "Automatically remember running applications when logging out" under the Session options
<digistyl3> jerone: i did
<seb128> digistyl3: no, it's not working in gnome-session 2.24
<digistyl3> seb128: so it's a gnome bug and we should wait for upstream to release a fix?
<seb128> digistyl3: right, bug or feature not implemented in the gnome-session rewrite
<digistyl3> ok, thanks :)
<digistyl3> anyone tried running vmware with intrepid as host?
<jerone> digistyl3: shouldn't you be using KVM ;-) ... havn't tried it but I can imagine that vmware modules don't compile with 2.6.27
<pitti> digistyl3: on my amd64 machine, but it has a pretty old install (alpha2 or so)
<digistyl3> jerone: i've got some new module sources, it compiles and runs but keyboard doesn't work in the VM
<digistyl3> i think i'll give virtualbox a shot, although i had some problems with it in kubuntu intrepid
<siretart> seb128: I hope you don't mind that I cc'ed you ;)
<seb128> siretart: not at all, thanks for sending this email!
<tseliot> seb128: I have noticed that stable releases of some gnome packages are available in Intrepid. Does this mean that I'll have to rewrite my patch for the gnome-control-center to be Ubuntu specific?
<seb128> tseliot: yes
<tseliot> seb128: ok, I'll do it, thanks
<seb128> thank to you for working on those changes ;-)
<tjaalton> is SJC the closest airport to Mountain View?
<TheMuso> ./c
<lool> seb128: Something really weird is happening to glib2.0's builds
<lool> http://launchpadlibrarian.net/17838229/buildlog_ubuntu-intrepid-amd64.glib2.0_2.18.1-1_CHROOTWAIT.txt.gz
<seb128> lool: that was an is issue, I'll retry everything which failed due to that yesterday
<seb128> lool: how did you notice? ;-)
<lool> libglib-data uninstallable since multiple runs
<lool> seb128: Who's supposed to reschedule the glib builds?  (I understand the issue has been fixed)
<seb128> lool: I just did
<lool> Ah thanks
<seb128> no problem, thanks for pointing it, I was not sure if the soyuz guys were going to kick everything which failed due to that or not and apparently they didn't
<dholbach> pitti: what does RoQA in removals.txt mean?
<cjwatson> dholbach: "request of QA", i.e. Debian QA team
<dholbach> ah ok - thanks a lot
<Keybuk> ScottK-vacation: if you change a 3 year old bug from Fix Released to Incomplete ... it helps to offer an explanation
<Hobbsee> Keybuk: surely not!  He's testing your skill of mindreading!
<jdong> heh, what's up with this whole e1000e fiasco?
<ogra> tjaalton, are there plans for fixing the psb driver ? seems it doesnt work for many people on i386
<ogra> (teh 2D one)
<tjaalton> ogra: the mobile guys have a newer version "somewhere"
<ogra> tjaalton, i am a "mobile guy" :)
<ogra> lool, ^^ do we have anything newer than whats in current xorg for 2D ?
<tjaalton> ogra: a simple rebuild should make it work again, I think
<ogra> yeah, thats what i thought
<tjaalton> oh sorry, no it wouldn't
<tjaalton> I'll try
<tjaalton> ogra: see bug 235288 about the "new" driver..
<ubottu> Launchpad bug 235288 in xserver-xorg-video-psb "X doesn't autodetect PSB driver" [Undecided,New] https://launchpad.net/bugs/235288
<tjaalton> should be hidden in the PPA ;)
<lool> ogra: Well the psb driver doesn't come from xorg, but I'm happy if the xorg people can help us
<lool> ogra: There are many components involved
<lool> ogra: One being drm
<ogra> well, i'd like at least 2D
<ogra> which shouldnt need drm
<lool> ogra: psb needs the psb drm for modesetting I think
<ogra> hrm
<lool> 3D is yet another beast, but I can tell you for sure the kernel bits are in use even if you don't do 3D; and I think the psb drm is part of them
<ogra> damned
<ogra> thats the one that wont be ready before release, right ?
<lool> Now the psb drm has been tentatively ported over by amitk for intrepid
<ogra> but only to lpia i guess
<lool> It's in linux-lpia, which we could build for i386
<lool> (which is why I suggested it should really be linux-intel-mid)
<ogra> it would be great to have in i386
<lool> (or similar)
<lool> Now, another bit which needs porting from hardy is ... libdrm
<lool> And finally, xserver-xorg-video-psb might need an update in intrepid for xserver 1.5; not sure how things break there, but it's likely to take some little fixing at least
<amitk> lool: no it isn't in lpia yet. I was away all of last week in Portland.
<lool> amitk: Hope you're not too much jetlagged
<ogra> bah, kernel guys always on holiday ...
 * ogra hides
<lool> amitk: persia mentionned that missing linux-meta for lpia prevent completing the install and subsequent boot of the lpia images   :-/
<ogra> amitk, if you put it in, can you do it in a way that its built for i386 as well, or is that much effort ?
<amitk> ogra: kernel sprint + plumbers conf
<ogra> amitk, i know, i was just joking badly :)
<amitk> lool: over the jet lag and back in action today. working on aufs and meta today
<ogra> was hard to miss the plumbers conf ... thanks to greg
<lool> amitk: Perfect, these are the ones I care about
<lool> psb is the responsability of Intel to provide, so it's nice if we get it from you, but many things seem to be required to get it to work   :-/
<lool> I think it's unlikely we get it for intrepid
<lool> smarter, that's a good acronym
<Treenaks> c
<ogra> bah, mobile-default-settings-0.4 missed the publisher by a minute
<ogra> grmbl
<ogra> so if i get it right a first step is to have the psb.ids file in the package, right ?
 * ogra adds that to xserver-xorg-video-psb
<tjaalton> it still won't build
<tjaalton> I gues..
<tjaalton> +s
<ogra> oh, right, the last build is from gutsy
<ogra> sigh
<tjaalton> right, won't build with the libdrm intrepid has, and it's not even ported to use libpciaccess
<ogra> yeah, i had that issue with Xorg -configure ...
 * ogra remembers
<seb128> ogra: btw did you fix you epiphany-browser being triggered by something issue?
<ogra> seb128, yep, the ubuntu-mobile metepackage did use tasks ... so it forcefully fulfilled the first recommends before looking at the second
<ogra> seb128, btw, is teher a way o get the show desktop button tranparent without much hacking ? (see http://people.ubuntu.com/~ogra/mobile/) ... not urgent for intrepid though, but if it would be a small thing i'd love to have it
<seb128> ok, so not a buggy recommends on the GNOME side, good ;-)
<ogra> yeah
<ogra> i'm waiting for soyuz and the metapackage should be fine
<seb128> ogra: the button is transparent, that's the icon which is not, and I don't think so
<ogra> ah
<ogra> i'll try with a differet icon
<Keybuk> wonder whether the reporter of bug #272744 is just complaining that we name wireless cards eth*, or am I missing a real issue?
<ubottu> Launchpad bug 272744 in udev "Intrepid: Wireless card shows up as eth1" [Undecided,New] https://launchpad.net/bugs/272744
<broonie> Keybuk: Is he not complaining that he can't work out how to rename it?
<asac> Keybuk: yes, invalid i would say
<asac> or wontfix :)
<asac> Keybuk: but maybe he really has issues connecting now (given that its broadcom) and just doesnt get it right in the description ;)
<Keybuk> broonie: right, if he changes it (why?!) and it gets unchanged, that would be a bug
<Keybuk> asac: yeah, could be a bug caused by another problem
<broonie> Some people like plain text names (I use them on big boxes since it was easier than remembering WTF eth0 is plugged into).
<ogra> kwwii, heh, just editing the gtkrc of NewHuman for ubuntu-mobile ... i didnt know you changed your last name :)
<ogra> # Authors:
<ogra> # Kenneth Wimar <kwwii@ubuntu.com>
<cjwatson> he's in the transition process to become a republic; one letter at a time
<ogra> lol
<jdong> ok I'm a total idiot
<jdong> I forgot I VMWare suspended a physical partition from VMWare and booted it natively.
<jdong> e2fsck is done ravaging through and I've got a lot of presents in /lost+found
<jdong> which seems to include most of /var/lib/dpkg because I ran a dist-upgrade
 * jdong wonders if we have a "stupidest thing done to an Ubuntu install" wiki page
<jdong> now I could just restore from a 1-month-old full backup, but before that it's time for more idiocy... building a hashtable of md5's to filenames based on the backup, seeing if I can find what this stuff in lost+found is :D
<geser> jdstrand: have you time to look on bug 271020? From a quick look at the jhead source it looks to me as this bug might have be also a security issue
<ubottu> Launchpad bug 271020 in jhead "jhead static string for -cmd too small" [Undecided,New] https://launchpad.net/bugs/271020
<geser> jhead tries to strcpy() FileName (comes from argv[]) into a 400 byte large array on the stack
<geser> so if one manages to construct the "correct" filename one might smash the stack
<munckfish> Which package owns/creates /etc/modules? I presumed it would be the kernel but I can't find ref to it in the maintainer scripts there. Also dpkg -S /etc/modules returns nothing.
<jdong> *** stack smashing detected ***: jhead terminated
<jdong> geser: confirmed; it is asking for a stack smashing attack
<geser> munckfish: see the postinst for module-init-tools
<fbond> Hi.  The apt configuration on Hardy has some Install-Recommends-Sections that I'd really like to override on the command-line (read: not by modifying a configuration file).  Is there *any* reasonable way to do this?
<munckfish> geser: thx
<fbond> In other words, I want to do an apt-get run that doesn't install any recommends at all, even if from these sections.
<fbond> It is apparently not sufficient to use --no-install-recommends, I assume that is due to this configuration option (which overrides APT::Install-Recommends).
<fbond> (Where "this configuration option" means APT::Install-Recommends-Sections)
<fbond> Anybody have any advice?
<psyke83> TheMuso, good work on the PA/ALSA updates, just want to ping you on a small patch that I recommend: attached to bug #258581
<ubottu> Launchpad bug 258581 in alsa-utils "Please expand {set|unset}-pulseaudio macros (debdiff attached)" [Wishlist,Triaged] https://launchpad.net/bugs/258581
<jdstrand> geser: looking...
 * MacSlow almost cannot believe it
<jdong> MacSlow: it is quite shocking to see code like that :D
<jdstrand> geser: without looking at the code, the patch is just a bandaid, no? we really need to check the length of the copy to the static buffer
<cjwatson> fbond: -o APT::Install-Recommends-Sections=#clear, I think
<MacSlow> jdong, no... I just successfully logged in using the face-browser for the first time
<fbond> cjwatson: thanks, I'll try it.
<cjwatson> fbond: see apt.conf(5)
<jdong> jdstrand: as I commented yeah, the patch is insufficient and probably a bad idea
<jdong> jdstrand: should probably be malloc'ed instead at runtime
<MacSlow> if I would drink (alcohol) I would do that now ... but being me I just celebrate it using a kiba
<jdstrand> jdong: sorry, I didn't see your comment
<pitti> MacSlow: congrats!
<jdstrand> jdong: I see it now-- I just skipped to the bt
<pitti> MacSlow: so you tamed it after all? :-)
<jdong> jdstrand: how has this not been noticed for the past 5 years :-/
<jdstrand> jdong: heh
<jdong>     char TempName[200];
<jdong>     strcpy(TempName, FileName);
<jdong> *smack*....
<MacSlow> pitti, well let's say I got around the biggest shortcoming of all ... no docs ... and Jon being on vacation/away (not sure)
<jdstrand> jdong: this does not run with privileges, correct?
<jdong> jdstrand: correct
<pitti> MacSlow: McCann you mean?
<pitti> MacSlow: he was at the Plumbers Conf, I spoke with him
<jdong> jdstrand: most probably this will just lead to stack-protector tripping
<MacSlow> pitti, now that I know what works how I can finally start giving the code shape, style and then focus on blinging it up as intended (and maybe give it a few MacSlow-twist)
<MacSlow> pitti, ah he was there *sigh*
<jdstrand> jdong: ok, then it isn't particularly serious-- user can much more easily destroy his system than via this overflow
<jdstrand> jdong: but it obviously needs to be fixed
<MacSlow> pitti, anyhow I feel like a mountain of rocks fell of my shoulders
<MacSlow> off
<jdong> jdstrand: right; the risk factor will be if it's used in some sort of CGI script
<jdong> (which I hope nobody does...)
<jdstrand> jdong: re stack-protector-- yes, but we didn't have that in dapper
<jdstrand> jdong: oh, is jhead common in CGI?
<jdong> jdstrand: I'm not sure; it is the most obvious way of parsing out EXIF tags from JPEG files so I wouldn't be surprised if various thumbnailersand photo gallery apps might use it
<jdstrand> jdong: makes sense. I'll get a CVE for it
<jdong>     // Make a temporary file in the destination directory by changing last char.
<jdong>     TempName[a] = (char)(TempName[a] == 't' ? 'z' : 't');
<jdong> for god's sake!
<jdong> want a CVE for unsafe tempfile creation too? :D
<pitti> lol
<pitti> jdong: and that's in /tmp, of course, right?
<jdong> pitti: it's in the destination directory of the jhead command
<pitti> what is jhead?
<pitti> oh, nevermind
<pitti> found the package
<jdong> jdstrand: add shell escape to the list too
<jdong>                 e += sprintf(ExecString+e, "\"%s\"",TempName);
<jdong>     a = system(ExecString);
<jdong> ok can we just call this entire DoCommand function broken? :)
<jdstrand> note to self, do not promote jhead to main...
<pitti> jdstrand: yeah, not that an accident in the archive happens and it disappears entirely, or so
<jdstrand> heh
<Riddell> doko: is python3 for main or universe?
<cjwatson> Riddell: universe
<jdong> jdstrand / pitti: yeah looking through jhead.c it's just broken everywhere. For auto-resizing and other actions it builds unchecked lenght strings to send to DoCommand too
<fbond> cjwatson: Eh, #clear doesn't work with -o (and the correct syntax is #clear APT::Install-Recommends-Sections;).
<fbond> -o only expects to set values, from what I can tell.
<cjwatson> fbond: oh, ok. just trying to be helpful
<fbond> cjwatson: Yeah, thanks.
<cjwatson> if it doesn't work I'm not sure, sorry
<fbond> cjwatson: #clear works fine as part of a config, so I guess I'll just create a temporary config file and use that with -c.
<fbond> cjwatson: Thanks for your help.
<cjwatson> fbond: yeah, temporary configuration files work well enough even if they are a hassle
<doko> Riddell: universe
<jdstrand> jdong: perhaps the best course of action would be to contact upstream with all your concerns, then coordinate on oss-security (http://oss-security.openwall.org/wiki/mailing-lists)
<jdstrand> jdong: that way you can get the nifty 'Discovered by' :)
<ldp> ...
<jdong> jdstrand: what is the general procedure for doing this? First contact upstream, correct?
<jdstrand> jdong: the is the responsible thing, yes
<jdong> jdstrand: ok, will do
<jdstrand> jdong: if they are unresponsive, go straight to oss-security
<jdstrand> (give 'em a little time though ;)
<jdstrand> jdong: cool, thanks!
<jdstrand> pitti, tkamppeter: gotta tell you-- over the weekend my wife got an off-the-shelf HP J4580 All-in-One printer from Target. It was *very* impressive to turn on the ptinter and plug it in (usb) to my laptop and have printing just work a few seconds later
<pitti> \o/
<pitti> jdstrand: file a bug
<jdstrand> pitti: a 'pat on the back' bug?
<pitti> "current Ubuntu makes support center earn no $$$"
<jdstrand> heh
<jdstrand> well-- the scanner I had to tinker with, slightly-- but nothing the wiki couldn't solve
<jdstrand> ;)
<pitti> oh, what, out of interest?
<jdstrand> pitti: needed to add hpaio to dll.conf
<pitti> jdstrand: that might be worth a bug report then
<jdstrand> pitti: that and I didn't have xsane or sane-utils installed
<pitti> jdstrand: hm, xsane is in ubuntu-desktop
<pitti> actually, sane-utils should be as well now, it's a recommends of libsane
<jdstrand> pitti: well, there is slightly more to the story
<jdstrand> pitti: my laptop runs intrepid, so perhaps it was just hpaio and sane-utils (would need to check)
<jdstrand> pitti: my wife's laptop, which is where I spent most of the time, is hardy
<jdong> jdstrand: ugh the rdepends show that gallery/gallery2 and dvd-slideshow both use it :(
<jdong> jdstrand: the former two I'm MOST worried about
<jdong> jdstrand: those are PHP photo galleries that allow user uploads
<pitti> jdong: right, hardy did install xsane, but not sane-utils
<jdstrand> pitti: so I just backported hplip to hardy, which is where I remember needing sane-utils and xsane
<jdong> pitti: sorry for talking and ruining your jd<tab> workflow :D
<pitti> jdong: argh, 'zcuse me, sir
<kwwii> ogra: yeah, that is typo :-(
<pitti> jdong: yay for history sensitive tab expansion
<jdstrand> jdong: nice work-- now it really depends on if gallery[2] and dvd-slideshow give jhead unfiltered input
<ogra> kwwii, so cjwatson isnt right ? phew :)
<kwwii> lol
<jdstrand> pitti: I needed 1.8.7 for the printer (well, at least not 1.8.2)
<jdong> jdstrand: well right now I'm reasonably certain that char[500] in editing the description tags means big JPEG metadata does bad stuff too.
<jdong> jdstrand: I wouldn't expect these limitations of jhead to be obvious enough for the gallery folks to foresee
<jdstrand> jdong: yeah, crafted images
<jdstrand> jdong: that's certainly true
<pitti> jdstrand: hm, so it wasn't just plug'n'play after all :(
<jdstrand> pitti: well, baring hpaio for the scanner bit, on intrepid, it was
<jdstrand> the printer was too new for hardy
<jdstrand> (but I knew that when buying it)
<pitti> jdstrand: that sounds like an easy fix in intrepid, unless it breaks other HP printers
<jdstrand> pitti: I found that by using hp-check-- and it recommended it
<jdstrand> pitti: I don't know if you do any hp-check foo in your magic configuration...
<pitti> tkamppeter: ^
<geser> jdong: sounds like you have fun with the jhead :)
<jdong> geser: lol. worst part is i used gallery a lot in the past
<geser> I hope without jhead installed
<kirkland> pitti: thanks for the link ... very informative
<pitti> kirkland: so the goal is to stop using groups and controlling privileges through PolicyKit
<kirkland> pitti: gotcha, seems noble
<pitti> kirkland: sensible "by default just works" settings, and using the PK GUI where neceary
<pitti> necessary
<pitti> kirkland: primarily because (1) to avoid the overloading of groups with assigning permissions, and (2) to allow programs to allow things to the user which he couldn't have in the default install
<pitti> kirkland: e. g. postinsts can't just put existing users into 'kvm' or so
<dholbach> jdstrand: unsubscribed ubuntu-universe-sponsors from the jhead bug too
<kirkland> pitti: right, that one is a PITA
<kirkland> pitti: what would it take to solve the kvm/libvirt group problem in Intrepid?
<jdstrand> dholbach: oh! thanks :)
<kirkland> pitti: is that doable?
<pitti> kirkland: so if we say "a local console user can use kvm" there isn't much to loose in terms of security
<kirkland> right
<kirkland> pitti: i'm picking up kvm for soren while he's out on paternity leave
<pitti> kirkland: e. g. audio, usb, and firewire devices (/dev/bus/usb/..., for example) are accessible as root:plugdev/root:audio, and *additionally* for the current foreground session, via a dynamic ACL
<pitti> kirkland: we can say "foreground only", or for kvm "local session" (which would make more sense in this case, IMHO)
<jcastro> kirkland: are you watching virt-manager while he's away too?
<kirkland> jcastro: yeah, sort-of ;-)
<kirkland> jcastro: more focus on kvm, but virt-manager too
<pitti> kirkland: so remote users can still be put into kvm (as now), or they get the relevant polkit privilege assigned in the PK GUI
<kirkland> pitti: what can be done legally in the postinst?
<kirkland> pitti: so that kvm works out of the box?
<pitti> kirkland: first, do you think such a semantics would make sense?
<kirkland> pitti: i think "local users" does make sense
<kirkland> pitti: and i think we can document that remote users would need kvm groupage
<kirkland> pitti: we can add that to the Server Guide documentation
<jcastro> kirkland: virt-manager currently has 75 open bugs, of which 0 are marked upstreamable, if you've got someone interested in at least determining if they're upstream that would really help.
<pitti> kirkland: (or using the PK GUI to assign the privilege)
<lucas> is there a server with binary packages from (very) old ubuntu releases?
<kirkland> jcastro: i'll go through virt-manager next...  i reduced the kvm queue from 63 to 43 yesterday, marking some duplicates, fixed, wont-fix; and getting a couple of minor patches sponsored
<lucas> like edgy?
<kirkland> lucas: edgy is going to be tough to find...  it's unsupported
<jcastro> lucas: http://old-releases.ubuntu.com/releases/
<kirkland> lucas: dapper is still supported (and older than edgy) though
<jcastro> oh, you mean packages.
<pitti> kirkland: did you ever see a hal fdi?
<lucas> jcastro: that's ISO images, but apparently http://o-r.u.c/ubuntu/ has the source packages?
<kirkland> pitti: negative
<pitti> kirkland: anyway, take a look at /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
<cjwatson> lucas: should have the binaries too
<lucas> ah binary too. perfect.
<pitti> kirkland: that's an XML file which matches on hal devices and puts access_control.{file,type} attributes to it
<lucas> thanks a lot to everybody ;)
<kirkland> pitti: interesting
<cjwatson> Launchpad used to have some of them but they had to clear up some space on the librarian recently. still has the old sources though
<jcastro> kirkland: all that's needed to get started is at least opening an upstream task for it if it's determined to be upstream - even if you don't have a link to the upstream bugzilla bug.
<pitti> kirkland: there you see how hal adds e. g. access_control.type.sound to alsa devices
<pitti> kirkland: every hal device with the access_control will be considered for dynamic ACL management
<kirkland> pitti: where are the possible values of these fields documented?
<kirkland> jcastro: cool, i'll see what I can do
<kirkland> jcastro: unfortunately, virt-manager kinda sucks, so most of us core kvm users tend to use the kvm command line :-/
<kirkland> jcastro: i'll throw some attention at it this week, though
<pitti> kirkland: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#spec-device-info describes the structure and syntax
<pitti> kirkland: hm, one problem is that current hal doesn't actually know about /dev/kvm, so we need to teach it about it
<pitti> kirkland: but that should be simple
<jcastro> kirkland: if you can make a determination of what is upstream and what isn't I can find someone who cares about virt-manager enough to make the linkages.
<kirkland> pitti: is that done in HAL, or in KVM?
<kirkland> jcastro: sounds like a plan
<jcastro> kirkland: if in bugs you find someone that cares about virt-manager send them my way and I'll convince them to help. :p
<kirkland> pitti: so hal provides /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi ...  is that changed in the source package itself, or generated?
<pitti> kirkland: kvm should ship an FDI file which assings access_control.file=/dev/kvm and access_control.type=kvm, and an "access_control" capability
<jcastro> right now it sticks out as "we're not even trying" wrt. forwarding bugs upstream.
<kirkland> jcastro: well, i have some buddies that care about virt-manager, but they work for Red Hat :-P
<pitti> kirkland: hm, maybe .type=virtual_machine, or so (slightly more generic)
<pitti> kirkland: there's a second piece of the puzzle
<kirkland> pitti: that makes sense
<pitti> kirkland: so the fdi says which devices are which type and declares it for ACL management
<pitti> kirkland: and /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy assingns those types to a description and default values
<cjwatson> kirkland: virt-manager> my sentiments exactly
<pitti> kirkland: the existing one for cdrom looks fairly good for this use cases
 * kirkland snorts :-)
<pitti> kirkland: in principle kvm could ship its own .policy and .fdi, but if you prefer we can also patch hal for that
<kirkland> cjwatson: <aside>I did get to play with Ubuntu inside Parallels on a Mac OSX machine...frigging great VM management interface</aside>
<kirkland> pitti: i think it would make more sense inside of kvm
<kirkland> pitti: or, there's one other option....
<kirkland> pitti: we have two meta packages, ubuntu-virt-server, and ubuntu-virt-mgmt
<kirkland> pitti: right now, they just depend on a couple of packages necessary to make virtualization 'useful'
<kirkland> pitti: we intend on putting some tools there to simplify bridged networking setup, etc.
<pitti> kirkland: as for teaching hal about the device, you can call "sudo hal-device --add /some/sensible/UDI" for creating it, and "sudo hal-set-property" to add the access_control capability and access_control.file=/dev/kvm and access_control.type=cdrom
<kirkland> pitti: i *think* what you're talking about makes more sense in kvm itself, but i just thought i'd throw that out there
<pitti> kirkland: then, after logging out and back in, you should get an ACL on /dev/kvm
<pitti> kirkland: yes, it would avoid centralizing knowledge about /dev/kvm in hal, shipping its own snippet is perfectly reasonable
<kirkland> pitti: okay, so the hal-device && hal-set-property commands are what would need to be called in kvm's postinst?
<pitti> kirkland: and an FDI for /dev/kvm should be in kvm, not in a metapacakge
<pitti> kirkland: no, that's just for playing around
<kirkland> pitti: understood on the kvm vs. metapackage bit
<pitti> kirkland: hal-device --add is not persistent
<cjwatson> gar, why does germinate work when run manually on drescher but not when run from cron.germinate?
<pitti> kirkland: but you can use it from the shell without recompiling anything
<jdstrand> 'virt-manager sucks' is kinda strong-- I use it daily...
<pitti> cjwatson: $PATH or so?
<kirkland> pitti: okay, so the work item is 1) add .policy and .fdi to kvm
<kirkland> pitti: 2) (do something in postinst)
<cjwatson> pitti: don't believe so, we consistently just use the germinate from /usr/bin
<cjwatson> I don't think there are any other installations kicking around
<pitti> kirkland: if you got it working with a manual hal-device add (working fdi/policy), I'll help you with getting the device into hal permanently
<cjwatson> pitti: and it's not broken as in "completely fails to work" anyway, it's hitting some kind of infinite recursion in the dependency resolver
<kirkland> jdstrand: hold on now...  quote me correctly
<kirkland> jdstrand: "virt-manager kinda sucks"
<jdstrand> heh, true enough
<kirkland> pitti: awesome, sounds like a deal
<kirkland> pitti: let me try this out
<pitti> kirkland: btw, that's chapter 3 in the link I gave you
<pitti> (directly after the fdi spec)
<kirkland> pitti: cool, i'll dig there
<kirkland> pitti: how much longer are you around today?
<pitti> kirkland: probably some 2 hours at least (my wife just left for meeting with a friend, so I'll have some time this evening :) )
<pitti> kirkland: i just don't feel very well, so I'll call it a day in 2 hours or so
<kirkland> pitti: understood
<kirkland> pitti: i'm updating my test hardware right now to latest intrepid
<kirkland> pitti: i never do this sort of testing on my primary laptop :-P
<pitti> kirkland: hal-device --add is purely temporary, don't worry
<pitti> kirkland: oh, hold on, you need --disable-purge-rootfs --really-dont-zap
<kirkland> pitti: great options
<kirkland> pitti: is there a --please-dont-fry-my-disk option too?
<kirkland> :-P
<pitti> kirkland: uh, forgot that, sorry
<kirkland> pitti: when you say "you should get an ACL on /dev/kvm", do you mean an extended attribute that I can view with getfacl?  or something else?
<pitti> kirkland: yes, I mean a file system ACL (getfacl, and little + in ls -l)
<kirkland> pitti: thx
<zul> slangasek: ping I know you are busy but did you have a chance to look at Christian Perrier's email from pkg-samba ml?
<slangasek> zul: about the patch that doesn't apply cleanly to 3.2.4?
<slangasek> zul: sure, I've looked at the email ;)
<zul> slangasek: yeah is it still necessary?
<slangasek> I don't know, I've not looked at samba 3.2.4
<zul> slangasek: k
<ahasenack> pitti: I'm seeing a bunch of tickets opened by apport that report conflicting package names
<ahasenack> pitti: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/273655 for example,
<ubottu> Ubuntu bug 273655 in landscape-client "package landscape-common 1.0.21-0ubuntu1 failed to install/upgrade: Versuche, ?/usr/lib/python2.5/site-packages/landscape/patch.py? zu ?berschreiben, welches auch in Paket landscape-client ist" [Undecided,New]
<ahasenack> it says the package is landscape-client-1.0.21-0ubuntu1
<ahasenack> but the dpkg logs show the failure while installing some 1.0.18 version
<kirkland> pitti: should `hal-device --add /org/freedesktop/Hal/devices/kvm` return, or just run in the foreground?
<pitti> kirkland: no, it's an one-shoot thing, afterwards you should see it in lshal
<kirkland> pitti: I get:
<kirkland> root@ubuntu:~#  hal-device --add /org/freedesktop/Hal/devices/kvm
<kirkland> tmp udi: /org/freedesktop/Hal/devices/tmp198ee
<kirkland> and it just sits there
<kirkland> pitti: oh, sorry
<kirkland> pitti: kvm installed, module loaded, /dev/kvm exists
<tkamppeter> pitti, I do not do any hp-check foo for HPLIP
<pitti> kirkland: hm, weird
<pitti> kirkland: oh, forgot that bit
<kirkland> pitti: is there a "verbose"
<pitti>   Reads property list in 'lshal' syntax from stdin.
<pitti> ^ from --help
<tkamppeter> jdstrand, pitti:
<pitti> kirkland: so you can give it some initial properties even
<tkamppeter> till@till-laptop:~/ubuntu/pxljr/pxljr-1.1$ dpkg -S /etc/sane.d/dll.d/hplip
<tkamppeter> hplip: /etc/sane.d/dll.d/hplip
<tkamppeter> till@till-laptop:~/ubuntu/pxljr/pxljr-1.1$
<tkamppeter> This file is part of HPLIP and makes our SANE finding hpaio.
<tkamppeter> You do not need to edit dll.conf
<kirkland> pitti: vvv
<kirkland> #  hal-device --add kvm < /dev/null
<kirkland> tmp udi: /org/freedesktop/Hal/devices/tmp0a4ae
<kirkland> created: /org/freedesktop/Hal/devices/kvm
<tkamppeter> But note that it is a conffile, so if you accidentally remove it, an update will not recover the file.
<tkamppeter> jdstrand, pitti: HPLIP depends only on libsane, not on any SANE frontends. Should I let it depend on xsane | kooka and/or sane-utils?
<jdstrand> tkamppeter: so it sounds like hp-check complaining about hpaio was a false negative
<jdstrand> tkamppeter: sounds like it just checks dll.conf and nothing else
<jdstrand> tkamppeter: note that I only used hp-check at all because the wiki told me too, and there was no feedback that the (awesome btw) auto0-configuration of the printer also setup the scanner
<jdstrand> pitti: ^
<kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key info.capabilities --strlist-post access_control
<kirkland> pitti: that look right?
<cjwatson> pitti: so, I just worked out why cron.germinate is crashing
<sebner> DktrKranz: \o/
<kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key access_control.file --string /dev/kvm
<cjwatson> pitti: it's trying to follow the following dependency chain (note that this includes build-dependencies and recommendations):
<cjwatson> anna -> libc6-udeb -> autoconf -> perl -> perl-base -> libc6 -> libgcc1 -> gcc-4.3-base -> dpkg-dev -> dpkg -> coreutils -> libacl1 -> libattr1 -> debhelper -> file -> libmagic1 -> zlib1g -> quilt -> patch -> ed -> dpatch -> fakeroot -> libacl1-dev -> libattr1-dev -> libc6-dev -> linux-libc-dev -> module-init-tools -> lsb-base -> sed -> texinfo -> gettext -> gettext-base -> libexpat1-dev -> libexpat1 -> docbook-to-man -> ...
<cjwatson> ... sp -> libsp1c2 -> dh-buildinfo -> build-essential -> g++ -> cpp -> cpp-4.3 -> libgmp3c2 -> automake1.9 -> cdbs -> intltool -> libxml-parser-perl -> liburi-perl -> perl-modules -> gcc -> gcc-4.3 -> binutils -> bash -> libncurses5 -> libgpmg1-dev -> libgpm-dev -> libgpm2 -> texlive-base -> texlive-doc-base -> texlive-common -> tex-common -> debconf -> debconf-i18n -> po-debconf -> libmail-box-perl -> netbase -> ifupdown ...
<kirkland> pitti: # hal-set-property --udi /org/freedesktop/Hal/devices/kvm --key access_control.type --string cdrom
<cjwatson> ... -> nowebm -> noweb -> iconx -> libx11-6 -> libxcb-xlib0 -> libxcb1 -> libxau6 -> pkg-config -> libglib2.0-0 -> libselinux1 -> python-all-dev -> python-all -> python -> python2.5 -> python2.5-minimal -> blt-dev -> blt -> tk8.5 -> libfontconfig1 -> libfreetype6 -> libx11-dev -> libxcb-xlib0-dev -> libxcb1-dev -> xcb-proto -> libxml2-utils -> libreadline5 -> readline-common -> lsb-release -> apt -> ubuntu-keyring -> ...
<cjwatson> ... gnupg -> libcurl3-gnutls -> libgnutls13 -> libgcrypt11 -> texlive-latex-base -> texlive-latex-base-doc -> findutils -> dejagnu -> expect -> tk8.4-dev -> tk8.4 -> xterm -> libxft2 -> libfontconfig1-dev -> defoma -> whiptail -> libnewt0.52 -> libslang2 -> libpng12-0 -> libtool -> libltdl7-dev -> libltdl7 -> gfortran -> gfortran-4.3 -> libmpfr1ldbl -> libgmp3-dev -> libstdc++6-4.2-dev -> gcc-4.2-base -> autogen -> ...
<cjwatson> ... base-files -> base-passwd -> sgmltools-lite -> docbook-dsssl -> openjade -> libosp5 -> jadetex -> texlive-fonts-recommended -> tipa -> texlive-base-bin -> libkpathsea4 -> libgd2-xpm-dev -> libgd2-xpm -> devscripts -> at -> libpam0g -> libpam-runtime -> libcrack2-dev -> libcrack2 -> cracklib-runtime -> miscfiles -> dictionaries-common -> elinks -> libgnutls26 -> libtasn1-3 -> gtk-doc-tools -> gnome-common -> ...
<cjwatson> ... gnome-pkg-tools -> svn-buildpackage -> libsvn-perl -> libapr1 -> libuuid1 -> passwd -> libpam-modules -> libdb4.7 -> default-jdk-builddep -> default-jdk -> default-jre -> default-jre-headless -> openjdk-6-jre-headless -> openjdk-6-jre-lib -> wget -> groff -> groff-base -> gs -> ghostscript -> libgs8 -> libcups2 -> libkrb53 -> libldap2-dev -> libldap-2.4-2 -> libsasl2-2 -> libsasl2-modules -> libpq-dev -> libpq5 -> ...
<cjwatson> ... libxml2-dev -> libxml2 -> python-all-dbg -> python-dbg -> debiandoc-sgml -> texlive-latex-extra -> preview-latex-style -> emacs22 -> emacs22-bin-common -> emacs22-common -> libgtk2.0-dev -> libgtk2.0-0 -> libgtk2.0-common -> libpango1.0-dev -> libpango1.0-0 -> libpango1.0-common -> libthai-dev -> libthai0 -> libdatrie0 -> doxygen -> libqt3-mt-dev -> libcupsys2-dev -> libcups2-dev -> libavahi-compat-libdnssd-dev -> ...
<cjwatson> ... libavahi-compat-libdnssd1 -> libavahi-client3 -> libavahi-common3 -> libavahi-common-data -> python-dbus -> python-epydoc -> graphviz -> libgraphviz4 -> swig -> gcj -> gij -> libgcj-bc -> libgcj9-0 -> gcj-4.3-base -> libecj-java -> libecj-java-gcj -> ant -> ant-optional -> ant-optional-gcj -> libbsf-java -> jython -> jython-gcj -> java-gcj-compat -> java-gcj-compat-headless -> gjdoc -> antlr -> nant -> mono-runtime -> ...
<cjwatson> ... mono-jit -> mono-common -> librsvg2-dev -> librsvg2-2 -> libgsf-1-114 -> libgsf-1-common -> libgnomevfs2-dev -> libgnomevfs2-0 -> gnome-mount -> hal -> udev -> initramfs-tools -> klibc-utils -> libklibc
<cjwatson> hmm, oops, I didn't expect it to spill over quite so many lines!
<cjwatson> sorry :)
<cjwatson> I love the way there are a couple of places where it wanders through a succession of library packages, then through some minimally-related stuff, then through the corresponding development packages; and goes through tex several times
<kirkland> pitti: i'm still not seeing the extended ACLs on /dev/kvm... at what point shouldthose take place?
<sebner> cjwatson: you paid freenode stuff a beer to avoid the kick? ^ ^
<jdong> sebner: I gotta say without the paste the comedic effect would not be the same.
<sebner> jdong: hrhr ^^
<calc> wow e1000e thing is a mess :\
<kirkland> calc: agreed...  the least they could have done was switch on character and make it a palindrome
 * sebner is just wondering that the crisis came up *now* with rc6 and not earlier
<directhex> pitti, ping
<mathiaz> ahasenack: I'm going to look into the landscape-client bugs.
<ahasenack> mathiaz: I don't understand those apport reports, it's the third or fourth one which reports one package in the summary but the logs show a different one
<mathiaz> ahasenack: radix: did you get a chance to comment on my suggestion to run a daily cron job to update smart package data instead of hourly ?
<mathiaz> ahasenack: right - I haven't looked at the log yet - but apport is not an issue here.
<radix> mathiaz: I didn't, sorry, I have been off the computer for being sick
<ahasenack> I just commented on the cronjob itself
<radix> mathiaz: niemeyer probably has a comment about the frequency of the job
<mathiaz> ahasenack: right - slangasek suggestion should also be implemented.
<ahasenack> mathiaz: having the daemon run smart update?
<radix> I'm stepping away again
<mathiaz> ahasenack: just checking if landscape-client is running is enough for now
<ahasenack> right, so I pasted something for that
<mathiaz> ahasenack: great.
<mathiaz> ahasenack: I think your suggestion for the cronjob works well.
<mathiaz> ahasenack: I'd like to have feedback on the frequency of the cron job.
<ahasenack> mathiaz: so, I don't know the origin of that frequency or why it's hourly. I guess there is an expectation of things to work "faster" with landscape, since there is someone sitting in front of a web ui
<ahasenack> mathiaz: also considering it's a paid service
<slangasek> the frequency doesn't seem unusual at all to me
<niemeyer> There's also an important distinction between Smart updates and APT updates
<slangasek> oh?
<niemeyer> When smart update is run, it will download the Release file
<niemeyer> If the Release file has the same digest of the one previously downloaded, nothing else is downloaded
<slangasek> ah
<slangasek> I'm not sure that's actually different than apt?
<ahasenack> I thought apt did that too
<niemeyer> So the actual operation is quite lightweight when there are no changes
<niemeyer> I don't think so
<niemeyer> But maybe it changed since I last looked at it
<mathiaz> niemeyer: apt and update-notifier are run on a daily basis
<slangasek> I'm pretty sure apt is smart enough to not re-download unchanged files
<niemeyer> If it does, even better :-)
<liw> slangasek, it is
<niemeyer> slangasek: I think it does that based on file timing only
<niemeyer> Anyway.. I'm sure APT is great. :-)
<niemeyer> So..
<niemeyer> What's the actual problem we're trying to prevent?
<mathiaz> niemeyer: I've asked about that yesterday -> http://paste.ubuntu.com/49783/
<mathiaz> niemeyer: the concern is to put too much load on the servers and mirrors
<slangasek> mathiaz: I agree that if you're managing a bunch of workstations centrally, you want the average latency to be much lower than 12h
<niemeyer> mathiaz: Well, I agree.. it would consume less resources from the server
<niemeyer> mathiaz: The question, though, is if it makes an important difference or not
<niemeyer> mathiaz: It does make a difference for Landscape usability
<mathiaz> niemeyer: the main raise I'm asking is that the default ubuntu install (with apt) doesn't update on a hourly basis.
<niemeyer> mathiaz: If you're concerned about it, we can ask elmo about it
<niemeyer> mathiaz: It's a slightly different use case I guess
<mathiaz> niemeyer: right - if it makes a difference for landscape usability than a hourly cron job is the best option
<niemeyer> mathiaz: We can always fire APT/Synaptic/whatever and get the current infomration
<niemeyer> mathiaz: For a server-side solution that's not so practical
<slangasek> hmm, on-demand triggering of an update check isn't possible?
<niemeyer> slangasek: It is definitely possible, but it's a bad UI
<slangasek> ok.  I imagine it would be a suboptimal user experience regardless, due to the latency of checking
<niemeyer> slangasek: Try to imagine something like "The information you're looking at is 20h old.  If you want to know the current updates, click on Update All Systems and come back in a few minutes."
<slangasek> right :)
<pitti> re (sorry, got some spontaneous guests)
<slangasek> anyway, I'm certainly not arguing against the 1h cronjob
<pitti> cjwatson: dep chain> oof! so it's actually just a livelock, not a crash or so?
<pitti> kirkland: did you set access_control.type, too? (to 'cdrom' should work)
<pitti> directhex: contentless pong
<kirkland> pitti: i did
<pitti> kirkland: and restarted your session?
<kirkland> pitti:
<kirkland> # hal-device  | grep kvm0: udi = '/org/freedesktop/Hal/devices/kvm'
<kirkland>   info.udi = '/org/freedesktop/Hal/devices/kvm'  (string)
<kirkland>   access_control.file = '/dev/kvm'  (string)
<mathiaz> ahasenack: it seems that most of the apport bugs are due to the fact they're not using the latest package.
<kirkland> pitti: well, i'd expect the extended acl would show up before I restart a session, no?
<kirkland> pitti: i'd think that change should be immediate
<pitti> kirkland: no, they aren't ATM; the acl helper just reacts to ConsoleKit changes
<pitti> kirkland: but you can fake it
<pitti> kirkland: run 'ck-launch-session'
<ahasenack> mathiaz: you mean latest landscape-c* package or latest apport package?
<directhex> pitti, you've sponsored a couple of my mono-related merges in the past, is there any chance you could work your magic on one? it's the last obsolete package in intrepid's core mono stack
<mathiaz> ahasenack: oh right - I see what you mean now :D
<pitti> kirkland: that creates another COnsoleKit session for you and launches a sub-shell in it
<slangasek> mathiaz: I think the only confusion was that apport will list the currently-installed package version in the report, but the log shows the problem for a previous failed upgrade attempt
<pitti> directhex: please assign the sponsor bug to me, can do
<slangasek> apport's analysis of upgrade failures seems to be a bit suboptimal
<ahasenack> slangasek: that's what I thought
<pitti> slangasek: yes, it is unfortunately; planned to improve on next UDS
<directhex> pitti, fantastic. thanks for your help!
<kirkland> pitti: hmm, still no ext'd acl
<geser> doko: is it save to disable building libgcj-doc in gcj-4.2? libgcj-doc gets also build from gcj-4.3
<pitti> directhex: ah, got the bug mail
<ahasenack> mathiaz: about other landscape-client bugs, I'm puzzled by #270007. I don't know how or what triggers landscape-client (or any of its components) to be run by non-root
<ahasenack> oh, wait, wrong bug number
<ahasenack> #268879
<ahasenack> mathiaz: some people said they didn't try to run landscape-client as a regular user: the crash was just there
<ahasenack> we have 5 duplicates of that one already
<kirkland> pitti: dude, i think its working!!!!
<pitti> james_w, seb128: so, is there any better rationale than "it's the newest version" for consolekit which I could give in the FF exception request?
<pitti> kirkland: yay!
<seb128> pitti: being close of upstream makes easier to send them bugs which is nice especially when everybody is busy on the ubuntu side to backport interesting changes
<kirkland> pitti: yup, it's working, launched a kvm as "dustin", full acceleration
<kirkland> pitti: ext acl's present
<kirkland> pitti: now what?  :-)
<pitti> kirkland: so, next step is to use a real "type", such as "kvm" or maybe something more generic; maybe "vm_host" or "virtual_machine" or so?
<seb128> pitti: and that also reduces upstream rants about ubuntu shipping outdated versions ;-)
<kirkland> pitti: okay, what's the advantage of going generic here, with something like "virtual_machine" rather than specific, like "kvm"?
<directhex> pitti, sorry to single you out for it, but the thought of intrepid shipping with a doc package documenting something 20,000 revisions older than the actual software fills me with bile and rage. and strangely it seems a mono-related package isn't the top of anyone's sponsorship lists
<pitti> kirkland: as for creating the device, there's two options: patch hal to create it, or add the hal-device --add call to the init script (and thus introduce a hal dependency to the init script)
<kirkland> pitti: kvm init script sounds most appropriate, no?
<kirkland> pitti: or do you prefer them to be concentrated?
<kirkland> pitti: uh-oh.... this might be a sticking point
<kirkland> pitti: i seem to recall some resistance of hal on the server :-/
<pitti> kirkland: and you e. g. couldn't restart hal after kvm is running
<pitti> (sorry if that came through twice, my network just had yet another glitch)
<mathiaz> kirkland: correct - that's the main reason for the split of landscape-client
<mathiaz> kirkland: landscape-common is installed by default on the server, but doesn't pull in hal
<mathiaz> kirkland: while landscape-client pulls in hal (and dbus, etc...)
<mathiaz> ahasenack: yes - that's because they
<mathiaz> ahasenack: yes - that's because they're running intrepid and got upgraded during the dev cycle
<pitti> kirkland: there's a third way which is even cleaner IMHO, but slightly more effort
<kirkland> mathiaz: i've worked a solution with pitti to handle the requirement we have for group membership in kvm
<kirkland> mathiaz: but it depends on hal to handle the perms
<mathiaz> ahasenack: they got 18-0ubuntu2 which fails to install
<kirkland> pitti: i'm listening......
<ahasenack> mathiaz: right, but it's a different bug. See https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/268879
<ubottu> Ubuntu bug 268879 in landscape-client "Shouldn't crash when run as user instead of root" [Low,Confirmed]
<mathiaz> ahasenack: and then upgraded to 21
<ahasenack> mathiaz: that error is about running landscape-c* as non-root
<ahasenack> mathiaz: and I have no idea how that could happen other than a user directly invoking the program
<geser> I see you are discussing how to add acls on a device for the user. Is there some good guide how to do it? I want finally fix bug 57755 that way but I'm missing some starting point on how to do it.
<ubottu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755
<mathiaz> ahasenack: hm - I'll have a look at it.
<mathiaz> kirkland: right - I read the conversation - I think it makes sense for a desktop environment
<pitti> kirkland: so, you could write the hal-device --add into a shell script which is installed as a hal addon (/usr/lib/hal/kvm-device or so)
<mathiaz> kirkland: however for a server environment it may not work well :/
<kirkland> mathiaz: good point
<kirkland> pitti: that sounds much better
<pitti> kirkland: and in your fdi, add the addon to the computer hal entry
<pitti> kirkland: then the addon will be called on hal startup
<pitti> kirkland: and you can ship all parts of it in the kvm package, completely independent of hal
<pitti> kirkland: and it's just text files
<pitti> kirkland: yes, in fact I think that's how it should be done
<kirkland> pitti: given what mathiaz has mentioned, we can add a "Suggests hal" to kvm, but we don't want to necessarily bring it in
<kirkland> pitti: so i think this enablement should go into hal rather than kvm
<pitti> kirkland: right; if you don't have hal installed, you'd use the group method
<kirkland> pitti: thus, if a user has "hal", we use this, otherwise, what you just said :-)
<liw> mvo, ping?
<pitti> kirkland: why? it's just shipping three text files
<pitti> kirkland: (fdi, .policy, shell script)
<kirkland> pitti: okay, and nothing that actually does anything with them
<pitti> they are like 100 bytes each, but they leave the knowledge and policy in the package they belong to
<pitti> kirkland: so, if you really don't like them being there, we can add it to our hal package, too
<kirkland> pitti: the code that codes them will be in hal
<pitti> I'm not too fussed abou tit
<pitti> but I think we should maintain policy together with the packages, that seems cleaner to me
<kirkland> pitti: i think those 3 files would be fine in kvm, as long as we avoid a dependency on hal
<kirkland> pitti: fair enough
<pitti> kirkland: yes, if you don't have hal installed, you'd just have an extra 3 text files laying around
<kirkland> pitti: okay, can i somehow "export" those files from my working setup?
<pitti> no dependency needed (well, a suggests dounds fine)
<kirkland> pitti: that sounds perfectly reasonable
<kirkland> pitti: agree on the Suggests
<pitti> kirkland: copy the hal-device call into a shell script (/usr/lib/hal/debian-setup-keyboard might be a good template)
<pitti> kirkland: and once you wrote a .policy and .fdi file that work, just copy them into the package and install them, yes
<mvo> liw: pong
<pitti> kirkland: for bonus points, create a .policy.in and intltoolize it, for translation love, but don't worry too much about that
<liw> mvo, would you be willing to sponsor an upload of system-cleaner tonight or tomorrow?
<kirkland> :-)
<mvo> liw: sure, is the bzr current, can I upload from it?
<pitti> kirkland: use the existing .fdi/.policy files as a template, that should be easy then
<pitti> kirkland: hardest part is probably to invent a sensible name for "type" :)
<kirkland> :-P
<liw> mvo, not yet -- I'm still pondering on how to deal with having a single apt.Cache instance (after being side tracked by my real estate agent showing my apartment to a potential buyer)
<kirkland> pitti: i'm inclined to use "kvm" for the same reasons that "cdrom" is "cdrom" and not "optical_drive"
<kirkland> pitti: but I really don't care
<mvo> liw: sure, no problem
<pitti> kirkland: they are sticky in the sense that you could manually assign the privilege to somebody, thus it's hard to change it later
<pitti> kirkland: but kvm sounds fine
<mvo> liw: just give me a shout when its ready
<liw> mvo, I'll do that, thank you
<superm1> kirkland, perhaps a dumb question, but why would there be opposition to including hal in server installs in the first place?
<kirkland> pitti: i'm trying to think of what kind of virtualization device might pop up in the future, that would work along side kvm?
<pitti> kirkland: virtualbox?
 * kirkland points superm1 to mathiaz 
<kirkland> pitti: does that have a device or something associated with it?
<pitti> kirkland: vmware has them as well, but I think it's installed as something insane, like 777 or so
<liw> superm1, hal is a moving part, and the more you have, the more likely it is that one of them breaks
<kirkland> pitti: okay, that's perfectly reasonable to me
<pitti> kirkland: it's been a while, but IIRC yes
<kirkland> pitti: it would be advantageous to do this in a way that other virt solutoins can leverage
<pitti> anyone using virtualbox here?
<pitti> kirkland: they could use the same .policy file, which is beneficial for shaing translations
<pitti> kirkland: they'd need a separate fdi, but those are cheap (no user visible strings)
<superm1> liw, but what about HAL brings up the potential for breakage is what i'm getting at?
<kirkland> pitti: "virt-hw"
<kirkland> pitti: "virtualization" or "virtualisation" :-)
<liw> superm1, everything -- it's code in the box, and that means there's a risk it will break
<kirkland> pitti: "virtual-machine"
<liw> superm1, it's not hal in particular
<pitti> kirkland: (not that it doesn't need to be overly short; nobody ever types this)
<kirkland> grep access_control.type /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
<pitti> kirkland: well, virtual-machine in particular sounds a bit misleading to me
<kirkland> pitti: those look like the others in use
<kirkland> pitti: sound, cdrom, camera, scanner, pda
<siretart> pitti: I used to use virtual box. why do you ask?
<pitti> kirkland: vm-host or virtualization WFM
<kirkland> pitti: "vm-acceleration"
<pitti> siretart: there's something like /dev/virtualbox, right?
<pitti> kirkland: well, it's really vm-make-bearable-in-the-first-place :)
<kirkland> pitti: ;-)
<superm1> pitti, yeah /dev/vboxdrv
<pitti> kirkland: (I *told* you it'd be the hardest part!)
<siretart> pitti: yes, I think it was called /dev/vboxdrv and /dev/vboxnet or something
<pitti> superm1: cheers
<kirkland> pitti: no kidding ;-)
<superm1> pitti, it used to need permissions management, but no longer does
<pitti> superm1: how does it now? ConsoleKit magic or 777?
<pitti> superm1: I still remember adding myself to a vbox group, but that might be half a year ago already
<superm1> pitti, upstream requires that you use their hardening system on the package and run the VirtualBox binary suid
<kirkland> pitti: "virtual-machine-extensions"
<superm1> pitti, its as of the last release or two that they added these requirements
<pitti> superm1: eww; I thought being able to run a vm as user would be a great thing
<superm1> pitti, yeah wishful thinking
<pitti> seb128, james_w: sorry, repeated network outage; did I miss a reply from you wrt. ck 0.3 justification?
<james_w> <seb128> pitti: being close of upstream makes easier to send them bugs which is nice especially when everybody is busy on the ubuntu side to backport interesting changes
<james_w> seb128> pitti: and that also reduces upstream rants about ubuntu shipping outdated versions ;-)
<james_w> I don't really have anything to add
<pitti> james_w: wel,l the latter doesn't count, that's always the case :)
<pitti> james_w: thanks for the quoting
<seb128> pitti: I closed IRC since but I said basically that "since nobody is actively working on it in ubuntu and backporting change we would benefit of having the current version to be able to send bugs upstream without getting a "could you try a recent version" reply"
<james_w> we have a bunch of crashers that are beyond me, and I would like to ask them, and so having them reproduced on the latest version would help me there
<seb128> ditto
<seb128> imho consolekit crash too often for something which is a base infrastructure component
<seb128> ie when it crashes you can't get credentials since you have no session
<seb128> and since we have nobody working actively on it having something we can send upstream would be better
<slangasek> cjwatson, pitti, mathiaz: is landscape sorted now to the point where it should be re-added to desktop-common?
<kirkland> pitti: do you think i need the /etc/default/kvm conffile?
<pitti> slangasek: landscape-common should be fine, except that I seriously question it's Pre-Depends
<pitti> mathiaz: ^ any idea why it has those pre-depends? that looks just wrong
<pitti> slangasek: s/it's/its/, duh
<slangasek> mm, indeed
<pitti> same for -client
<mvo> oh, is the plan to re-add it to -desktop? then I need to update update-manager, it is removing it on desktop installs (the sub that is)
<slangasek> mvo: it was removed from desktop due to a transient installability issue during a key testing window; AFAIK it's supposed to go back in
<pitti> slangasek: hm, indeed, I thought we just want to ship it on servers? or has that changed again?
<pitti> cjwatson: halp plz
<mvo> I read the last mail exchange that way (that its for the servers)
<slangasek> pitti: you thought that based on what?  That had never been my understanding, and I thought mdz's last email confirmed that it had always been intended to be included on the desktop
<slangasek> it was in the desktop-common seed, after all
<pitti> slangasek: based on that phone confcall, but ICBW
<slangasek> ah, well, I wasn't on that phone call, so it didn't happen ;)
<kirkland> pitti: what about "virt-technology"
<kirkland> pitti: which is inline with AMD-V and Intel-VT
<pitti> kirkland: well, virt-hw is a bit less marketingish (or what about "awesome-virt")
<tkamppeter> jdstrand, pitti, hp-check does not know about the Debianism(?)/Ubuntuism /etc/sane.d/dll.d/. It only knows about /etc/sane.d/dll.conf.
<kirkland> pitti: i'm good with "virt-hw" if you ware
<slangasek> pitti: who all was on that call, then?
<pitti> kirkland: sure; btw, I don't have an /etc/default/kvm
<kirkland> pitti: no, it doesn't exist
<pitti> slangasek: hm, niemeyer, cjwatson, me, someone else I forgot
<kirkland> pitti: http://pastebin.ubuntu.com/49804/
<slangasek> frankly, I find it very strange that we would give desktop farms less landscape support out-of-the-box than servers, particularly given the push-back on landscape deps has been from the server team
<tkamppeter> If the Ubuntu Wiki tells about hp-check you should modify it telling that hp-check does not know about our SANE changes.
<pitti> slangasek: ok, let's add back -common then; that might have been my misunderstanding (-common is at least useful to some degree, while -client doesn't give you anything in the default install)
<tkamppeter> HP's MF devices on USB are fulkl Plug'n'Print (and Plug'n'Scan) under Ubuntu.
<pitti> kirkland: you need the hal-device --add call; and in that you can feed the properties to stdin
<pitti> kirkland: (more efficient than calling hal-set-p three times)
<kirkland> pitti: good point, let me rework
<pitti> kirkland: feed it "foo.bar = 'baz'" lines
<slangasek> pitti: hmm, what's the net size difference if we include -client as well, and are certain that we don't want it included by default?  I didn't think -common gave you anything by default either, unless you were a landscape customer
<pitti> slangasek: I was told that "common" has a "sysinfo" component which works everywhere
<jdstrand> tkamppeter (and pitti): when I get a chance, I set this up again on my Intrepid laptop, and update the wiki accordingly
<slangasek> I would rather put in -client for the moment if there's any question at all, so that we see what the size constraints are
<pitti> slangasek: and I'm not certain (that's why I called cjwatson for help)
<slangasek> ok :-)
<pitti> slangasek: right
<slangasek> ok, so until we get a clarification from cjwatson, I'm going to add -client back into the seed so we can see what it does to sizes
<pitti> slangasek: well, it pulls in smart and twisted, another 500 KB or so; not too bad, but if we can avoid it, I'd like to do it
<slangasek> then if we replace it with -common later, the worst case is that we have free space that we have to fill
<mvo> ok, then I remove the update-manager rule on it again
<kirkland> pitti: do I need to append to info.capabilities, or is overwrite okay?
<pitti> kirkland: overwriting should be ok, it's entirely under your control
<kirkland> pitti: http://pastebin.ubuntu.com/49806/
<pitti> slangasek: what a luxury problem :)
<kirkland> pitti: http://pastebin.ubuntu.com/49808/
<pitti> kirkland: (isn't it <<EOF? )
<slangasek> pitti: exactly :)
<kirkland> pitti: ah yes ;-)
<pitti> kirkland: restart hal, and sudo execute it, to test
<kirkland> pitti: hmm, no luck yet
<pitti> kirkland: property setting doesn't work?
<pitti> brb
<kirkland> pitti: the script executed correctly
<kirkland> pitti: and # hal-device  | grep kvm
<kirkland> 0: udi = '/org/freedesktop/Hal/devices/kvm'
<kirkland>   info.udi = '/org/freedesktop/Hal/devices/kvm'  (string)
<kirkland>   access_control.file = '/dev/kvm'  (string)
<kirkland> looks right
<kirkland> but I don't have access to the kvm as 'dustin'
<kirkland> and i did restart my session
<superm1> pitti, will bumping these extra bluez packages that were introduced in intrepid require a MIR?  the same functionality got split out into plugins, so they were split into extra binary packages that ended up in universe
<pitti> kirkland: hm, where's the control.type?
<superm1> *bumping = moving them into main
<pitti> superm1: no, they don't need an MIR, just dependencies to them
<pitti> superm1: I already moved them to main
<superm1> pitti, ah okay.  well i'm sorting out a different bug on bluez so i'll get the dependencies added for them too at the same time. thanks
<pitti> kirkland: and did you set access_control.type to cdrom or virt-whatever? (in the latter case you need a matching FDI and a .policy)
<kirkland> pitti: i thought it was "access_control.type"
<pitti> kirkland: yes, I'm just lazy
<pitti> kirkland: actually...
<kirkland> pitti: ah, that's probably it
<pitti> kirkland: hang on
<pitti> kirkland: if you set the correct properties right away, you don't need a separate .fdi file
<kirkland> that sounds like a good plan
<pitti> kirkland: i. e. everything that the .fdi file would merge to that devices can be set right at the hal-device --add call
<kirkland> pitti: sounds simpler
<pitti> kirkland: but you still need to add the "access_control" capability
<pitti> kirkland: (the one which the fdi merged)
<pitti> kirkland: so it should work with type == cdrom, and adding the capability
<pitti> kirkland: if that works, change crdom to virt-awesome and add a corresponding .policy
<mathiaz> pitti: slangasek: about the pre-depends in landscape: the reason is outlined in bug 268838
<ubottu> Launchpad bug 268838 in landscape-client "registrating clients doesn't work when installing the package" [High,Fix released] https://launchpad.net/bugs/268838
<pitti> seb128, james_w: argh, 0.3 seems to break hal (the ACL management)
<mathiaz> pitti: slangasek: I should file a bug about using a pre-depends and fix it later once the python-support/python-gobject packages are fixed.
<seb128> pitti: I told you about it this afternoon, the patch has been discussed on the upstream mailing list I think?
<james_w> pitti, seb128: is it http://lists.freedesktop.org/archives/hal/2008-August/012124.html?
<kirkland> pitti: where can i find the policy templates?
<seb128> pitti: at least the mandriva packager complain to jon on IRC about sending those patches on the list next time, but I think that has been discussed there too
<pitti> james_w: seems to be it, thanks
<slangasek> mathiaz: I don't think that explains landscape-client Pre-Depends: debconf
<james_w> pitti: a later message refers to a policykit patch as well, we will probably want that
<slangasek> mathiaz: likewise the landscape-common pre-dep
<pitti> this is not just a simple update any more
<pitti> james_w: lots of things are using CK nowadays, not sure what else could break
<james_w> pitti: http://cvs.fedoraproject.org/viewvc/rpms/PolicyKit/devel/pk-ck-api-change.patch?view=markup
<mathiaz> slangasek: hm - debconf must be added by ${misc:Depends} then
<seb128> pitti: there is at least fedora and mandriva using it for a while now
<pitti> seb128, james_w: keeping track of it in bug 273711; I didn't subscribe slangasek yet, I want to see this working first
<ubottu> Launchpad bug 273711 in policykit "New upstream release 0.3" [Undecided,In progress] https://launchpad.net/bugs/273711
<slangasek> mathiaz: um... putting the ${misc:Depends} token in the Pre-Depends: line is... strange?
<pitti> but not today any more, need some sleep to cure my fever and cold :(
<seb128> pitti: feel free to use a ppa, I'll upgrade and confirm if it works for me or not
<james_w> pitti: sure, I'm happy to test tomorrow
<seb128> pitti: take care!
<pitti> seb128: 0.3 is in my PPA
<james_w> pitti: get well soon
<seb128> pitti: ok, I'll try and comment then!
<kirkland> pitti: okay, this script does work: http://pastebin.ubuntu.com/49822/
<pitti> well, at least I uploaded it
<mathiaz> slangasek: correct.
<pitti> seems it didn' thit yet?
<kirkland> pitti: i think the problem is in info.capabilities = 'access_control'
<kirkland> pitti: that needs to be an "append", rather than an "overwrite" as I mentioned before
<kirkland> pitti: is there a += ?
<pitti> kirkland: well, it needs to be an array, not a string
<kirkland> pitti: how does that look in the heredoc ?
<pitti> kirkland: I don't know; hal-device claims it's using lshal syntax, so maybe "info.capabilities = {'access_control'}" works?
<pitti> kirkland: if not, just use hal-set-property, it's not a problem
<pitti> seb128: argh, got rejected; "Could not find person '<your-launchpad-id>'" WTH?
<pitti> ah, -ENODPUTRC, sorry
<seb128> ah ;-)
<kirkland> pitti: bingo!
<kirkland> pitti: success with: http://pastebin.ubuntu.com/49825/
<pitti> kirkland: rocking
<jdstrand> slangasek: so your sentinels are what you match on in create_from_template (in pam-auth-update)
<jdstrand> ?
<slangasek> jdstrand: yes
<kirkland> pitti: okay, so i put that in the kvm package as debian/setup-kvm-hal ?
<jdstrand> slangasek: I see 4 of them-- if I comment those out via a-c-c, it should all work again-- correct?
<pitti> kirkland: yep, install it to /usr/lib/hal/, and have a .fdi file to add that addon to startup (like in /usr/share/hal/fdi/policy/10osvendor/10-cpufreq.fdi)
<pitti> kirkland: but remember to change s/cdrom/virt-awesome/ and provide a .policy file
<slangasek> jdstrand: correct
<kirkland> pitti: sample policy file?
<slangasek> jdstrand: if they're commented out, pam-auth-update will know this is an externally-modified config, and will prompt before overwriting
<kirkland> pitti: /usr/lib/hal/hal-system-kvm ?
<pitti> kirkland: /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy
<pitti> kirkland: sounds good
<pitti> sorry, really need to crash now, I feel terrible, and it's late
<kirkland> pitti: cool
<pitti> kirkland: feel free to mail/leave backscroll; good luck!
<kirkland> pitti: i'll drop you some patches
<kirkland> pitti: thanks soooooooooooooo much
<pitti> kirkland: you're welcome! glad to get rid of another system group (for desktops, anyway)
<kirkland> ;-)
<pitti> of course we still need the group, but not the hassle to add people to it normally
 * kirkland wonders if superm1 might kill off the mythtv group next :-P
<superm1> haha kirkland
<kirkland> heh
<geser> kirkland: as you know now how to do it, can I bug you to teach me how to do it for usb smart card readers (used e.g. by gnupg)?
<kirkland> geser: :-)  let me prove i know how to do it by finishing off kvm, and then, sure!
<Keybuk> siretart: after some thought, I've reverted your udev change
<Keybuk> (for the reasons we discussed - I just don't like ignoring genuine errors to work around vserver's brokenness)
<norsetto> siretart: its bug 237830 (was in my email)
<ubottu> Launchpad bug 237830 in extremetuxracer "package planetpenguin-racer-gimp-dev None [modified: /var/lib/dpkg/info/planetpenguin-racer-gimp-dev.list] failed to install/upgrade: trying to overwrite `/usr/share/gimp/2.0/palettes/PPRacer---Default.gpl', which is also in package extremetuxracer-gimp-dev" [High,Fix released] https://launchpad.net/bugs/237830
<sebner> aloha norsetto btw ;)
<sebner> tseliot: alberto \o/
<norsetto> aloha aloha sebner
<tseliot> sebner: hi
<sebner> tseliot: you broke again my 3D (nvidia) xD
<tseliot> sebner: can you file a bugreport? I'll have a look at it tomorrow
<sebner> tseliot: sure. just wanted to blame you ^^ (don't take it seriously) ;)
<tseliot> sebner: ;)
<siretart> Keybuk: I disagree that vserver is being broken in this regard. the vserver instances don't have the mknod capability on purpose and udev's postinst is the only package in the archive insisting to have that capability
<Keybuk> that's fair enough
<Keybuk> in which case your patch should have either
<norsetto> doko: when you have time, could you look at bug 273677? I'm not 100% sure that that fix would be correct
<ubottu> Launchpad bug 273677 in wxwidgets2.6 "bitpim closeing unexpectedly" [Undecided,Confirmed] https://launchpad.net/bugs/273677
<Keybuk> 1) skipped device creation on vserver
<Keybuk> or even better
<seb128> hey norsetto
<Keybuk> 2) attempted it, and ignored *only* EPERM *if* on vserver
<norsetto> seb128: hi seb, any task for me ;-)?
<seb128> norsetto: thanks for your work on the desktop team organisation, I've been really busy on the GNOME 2.24 updates but I'll reply on the list tomorrow
<Keybuk> instead your patch ignores utterly genuine failures
<seb128> norsetto: how do you get the list of packages and versions now? I think we should have a collection of watch files in bzr
<norsetto> seb128: well, there is still a lot to be done on the wiki pages I'm afraid
<siretart> Keybuk: can udev.postinst safely assume that /proc is being mounted?
<seb128> norsetto: this way we could easily update packages list and the series numbers
<norsetto> seb128: for most packages I just use ftp.gnome.org, for the depends I have some sort of "watch" files
<Keybuk> siretart: I suspect many packages already assume that, yes ;)
<Keybuk> it seems like a valid assumption to me
<seb128> norsetto: we need to figure a way to claim updates though, we want something which allow to list packages which have usual updaters and those which can be claimed by the first to start working on the update
<norsetto> seb128: I can look at adding a tick box to say "this update is being worked on, but then I would have to save the results locally since the page is regenerated daily
<norsetto> seb128: dunno if I can do that with just javascript, have to check it out
<siretart> Keybuk: okay, in that case I'd like to add a check to grep for ^VxId in /proc/self/status and skip the device creation if found. is that acceptable to you?
<Keybuk> siretart: yup, entirely
<siretart> Keybuk: VxId contains the "Context Id" of vservers
<seb128> norsetto: let me think about that and comment the list tomorrow, what do you think about using a directory of watch files to describe the packages and versions to list?
<norsetto> seb128: if we have a list of usual updaters I can add those very easily to the page
<siretart> Keybuk: okay, I'll implement then that change
<seb128> norsetto: can easily do, we just need to figure where to store it, probably bzr, not sure if we should use the ubuntu-desktop or the desktop-bugs team though
<norsetto> seb128: it won't hurt, mind you that not all have a watch file right now
<norsetto> seb128: ubuntu-desktop looks reasonable to me
<seb128> right, but having the watch in the sources is annoying
<seb128> it requires changing the source, which doesn't work when we sync on debian which tracks only stable version
<seb128> and also require uploads to do changes
<seb128> it would be easier to have the watch in bzr somewhere, we could do changes easily there
<seb128> ubuntu-desktop has limited commit access where desktop-bugs is rather open to contributors
<seb128> so it depends if we want some moderation or let contributors do changes
<norsetto> seb128: for watch files there is not much they can screw up I guess
<Keybuk> siretart: of course, I'm not even sure how you expect a vserver to boot with that change <g>
<Keybuk> since it won't have /lib/udev/devices/null
<seb128> norsetto: right, but on another side there is no so many changes and it's not really up to contributors to decide what packages the team is working on or the series to use
<siretart> Keybuk: vservers have a rather special boot procedure. they don't use sysvinit nor upstart, but a custom "fakeinit" process.
<Keybuk> but they use udev?
<siretart> no. why should they?
<Keybuk> err, if they're not using udev
<Keybuk> why is a failure to install udev a problem? :p
<siretart> think of vservers like 'chroot on steriods'
<slangasek> pitti: well, looks like the latest GNOME drop already ate up any space we would use for landscape-client on the liveCD, hmm
<norsetto> seb128: hmmm, having warnings in the wiki (and other appropriate places) and reminding at desktop meeting won't be enough you mean?
<siretart> udev is installed by debootstrap, no? and has a rather large amount of reverse dependencies. (*sigh*)
<Keybuk> siretart: well, yes, it's a required part of our system ;)
<Keybuk> sounds like vservers aren't even Ubuntu
<siretart> chicken&egg problem, eh?
<Keybuk> "DSA keys not accepted anymore" oh, fd.o
<siretart> I maintain a (small) vserver farm running hardy here just fine, btw.
<siretart> since warty!
<seb128> norsetto: no, I mean the watch updates are not often and it's probably better to have some moderation than let any bug triager to be able to do changes
<Keybuk> but it can't be Ubuntu if it doesn't use things like sysvinit/upstart and udev <g>
<siretart> it can be
<norsetto> seb128: ah yes, if its bug triager please, don't :-)
<seb128> desktop-bugs is the team for triagers
<seb128> rather ubuntu-desktop then ;-)
<norsetto> seb128: agreed!
<Nafallo> siretart: they've been running hardy since warty? :-P
<slangasek> Nafallo: f33r the power of vservers
<Nafallo> servers from the future! :-P
<Nafallo> see.. there are reasons I like bare-metal the best ;-)
<norsetto> seb128: I was thinking maybe about another possibility, I could scan the TODO list and if we agree that all updates have to be loggen there, I can use that info when making the packages page
<Keybuk> bare metal makes the best restraints
<siretart> Keybuk: just to make sure we don't play ping pong here longer, I'm going to upload this: http://paste.ubuntu.com/49839/ (unless you object now, that is)
<siretart> I expect this to be fairly safe, and even create the devices if /proc is not mounted
<Hydrant> how do I regenerate ld.so.conf after putting an entry into ld.so.conf.d ?
<mathiaz> ahasenack: is there a reason why in the cronjob you 2> /dev/null ?
<mathiaz> ahasenack: I refer the landscape-client cronjob
<ahasenack> mathiaz: well
<ahasenack> mathiaz: not really now that I think of it
<ahasenack> mathiaz: fear probably
<mathiaz> ahasenack: if there is an error I'd rather have it printed
<ahasenack> emailed, in this case
<mathiaz> ahasenack: right
<ahasenack> mathiaz: the worst case would be a bug or some other condition which would happen every time. In this case, this would mean an email every hour
<niemeyer> mathiaz,andreas: I think there was some kind of issue that actually lead us to do it
<siretart> how are (former) e1000e users supposed to get their nic working if e1000 doesn't work for them? is there a (non-obvious) workaround somehow?
<niemeyer> About buffer size, IIRC
<niemeyer> mathiaz: If possible, I recommend not changing this script too much at this point
<niemeyer> mathiaz: We can perhaps review this for the next release, if you'd like to, but we won't have time to figure out issues at this point
<slangasek> siretart: downgrade the kernel
<mathiaz> niemeyer: hm. It's just a cron job.
<mathiaz> niemeyer: right - I get what you mean.
<niemeyer> mathiaz: Yes, it is, and I do remember that the 2>/dev/null was added to prevent the process from locking up.
<mathiaz> niemeyer: ok
<niemeyer> mathiaz: We can look for the bug and try to recall what was the problem, and fix it in a different way if you'd like to
<mathiaz> niemeyer: well - it's a bug in smart
<niemeyer> mathiaz: But we've been changing landscape-client in a different way every day in the last several weeks, so I'd like to try to walk towards stabilization as much as possible
<niemeyer> mathiaz: It may be, and it may not be
<niemeyer> mathiaz: It may also be about the way in which stderr and stdout are read by the parent process
<mathiaz> niemeyer: right - in that case it's a bug in crond.
<mathiaz> niemeyer: I don't see how this is related to landscape-client though.
<niemeyer> mathiaz: All I want is to keep the cronjob working.  If you promise it will work, you can do anything you want with it.  If we get locked up processes that'll be *really* *really* bad.
<siretart> slangasek: to 2.6.24?
<mathiaz> niemeyer: right.
<ogra> dont forget that we dont have any mailserver on desktop ... in case landscape-client is installed there ,,,
<kirkland> any other hal experts here, in pitti's absence?
<norsetto> does anyone know where pycentral installs pth files!?
<superm1> kirkland, maybe post your question to pitti and if someone else knows the answer before pitti gets back they'll speak up?
<kirkland> superm1: ;-)
<kirkland> superm1: i'm trying to figure out what runs the stuff in /usr/lib/hal/*
<superm1> kirkland, as in what executes it directly, or as in how to get hal to execute it?
<kirkland> superm1: if i run my script in there by hand, i get exactly what i want
<kirkland> superm1: now, i'm trying to figure out how to make that happen automagically on boot
<superm1> okay so more so the latter then
<kirkland> superm1: perhaps it just goes in the kvm init script?
<superm1> kirkland, you'll need to set an info.addons key i believe
<superm1> kirkland, and for the udi
<kirkland> superm1: oh, maybe that's it
<kirkland> i had info.callouts.add
<superm1> if I look at lshal output for say my lcd_panel, i get a key that looks like this http://paste.ubuntu.com/49845/
<superm1> where the addon in /usr/lib/hal is hald-addon-dell-backlight
<kirkland> k, let me try that
<kirkland> superm1: that's not quite it...  http://paste.ubuntu.com/49847/
<superm1> kirkland, well is there actually a device that is showing up to identify that you are running kvm though?
<kirkland> superm1: do you mean, does /dev/kvm exist?  it does.
<kirkland> superm1: but `hal-device | grep kvm` doesn't show any matches
<kirkland> superm1: it's still not running /usr/lib/hal/hal-system-kvm
<kirkland> superm1: on boot
<superm1> kirkland, okay so you are missing something that spawns the udi then i believe
<superm1> kirkland, by matching another hal key when booted from KVM.  are there any other things identifiable in lshal that can indicate that you are booted into kvm?
<kirkland> superm1: http://paste.ubuntu.com/49848/
<superm1> kirkland, oh is this for within the VM or outside the VM then?
<kirkland> superm1: i'm running this on real hardware, not in a kvm
<superm1> it looks like for outside the VM, i see...
<kirkland> superm1: right
<kirkland> superm1: generally, you have to be in the kvm group to actually use /dev/kvm
<kirkland> superm1: i'm trying to solve that ;-)
<kirkland> superm1: maybe this bit is wrong?  +    <match key="info.udi" string="/org/freedesktop/Hal/devices/kvm">
<kirkland> superm1: i'm not entirely sure what belongs in the fdi
<superm1> kirkland, well so if this fdi is only shipped w/ the kvm package, I believe that what you want to do is unconditionally spawn the new hal udi, and then have that match go into it
<superm1> kirkland, grep through /usr/share/hal for some examples about how udi's are spawned
<superm1> information/10freedesktop/10-dell-rfkill-switch-wlan.fdi is an example i'm looking at
<kirkland> superm1: that's what I do in /usr/lib/hal/hal-system-kvm
<superm1> kirkland, so what i'm thinking is that you wouldn't have any of those match keys in the first section, but ou would have the spawn udi key in the first device section
<superm1> and the second one you would do the matching that adds in your hal-system-kvm
<superm1> and I want to say it should spawn the binary all on its own after that
<kirkland> superm1: where is information/10freedesktop/10-dell-rfkill-switch-wlan.fdi ?
<superm1> /usr/share/hal
<superm1> I still might be a little off on this solution though
<cjwatson> pitti: not a livelock - python has a recursion limit, and because germinate 1.9 added an extra level of function calls for each package in the recursive dependency resolver, we ended up overflowing it and python raised an exception
<superm1> at that point you wouldn't necessarily even need that info.addons i suppose, but instead you would just put in your two keys that were added in that binary
<cjwatson> pitti: I was out, but retroactively, slangasek's plan for landscape-client is reasonable
<cjwatson> Keybuk: of course, not accepting DSA keys makes them non-spec-compliant ;-)
<kirkland> superm1: i'm thorough confused...  if i did that, what would actually call my binary?
<superm1> kirkland, nothing would, i'm not sure the binary would even be needed
<superm1> kirkland, because all the binary is doing is registering keys in the UDI right?
<kirkland> superm1: right
<superm1> kirkland, so you can just explicitly define those keys directly in the FDI
<superm1> and you should have the same result
<Keybuk> cjwatson: would that be the "oops, where did that go?" plan :)
<nxvl> Keybuk: that plan always work :P
<Keybuk> cjwatson: we clearly can't add any more packages to the CD!
<Keybuk> We've exceeded germinate's limits! :p
<cjwatson> not any more ;-)
<kirkland> superm1: http://paste.ubuntu.com/49851/ ?
<cjwatson> though I did notice several transitional packages in that dep chain that clearly shouldn't be there :)
<kirkland> superm1: actually, i dropped the addons
<kirkland> http://paste.ubuntu.com/49852/
<superm1> kirkland, yeah that's the sort of thing I had in mind
<kirkland> superm1: lemme build that
<kirkland> superm1: that might have worked ;-)
<kirkland> superm1: i'm rebooting to make sure
<mathiaz> niemeyer: http://paste.ubuntu.com/49853/ <- this is the hourly cronjob I'm about to upload
<kirkland> superm1: success!!!
<superm1> kirkland, awesome :)
<superm1> kirkland, you'll have to make sure that's within policy to do that in the FDI file like  that, but I think since it's opt-in only when you install the KVM package, I dont see why it wouldn't be
<kirkland> superm1: sure, i'm going to leave a debdiff in pitti's inbox
<kirkland> superm1: if it's okay, he can sponsor it
<kirkland> superm1: if not, he can modify it appropriately, or punt it back to me
<superm1> kirkland, right
<superm1> kirkland, i'm curious on the second half of that I didn't see, what controls someone's rights exactly?
<superm1> is there a GUI tool to figure this kind of stuff?
<kirkland> superm1: huh?
<kirkland> superm1: no idea
<nxvl> superm1: someone's rights as in permissions?
<superm1> nxvl, yeah in this particular case where you aren't actually settings permissions on the device file
<kirkland> superm1: i think that's the "policy" file
<superm1> does hal end up owning the device file and then handling permissions itself then?
<kirkland> superm1: not, it's still owned root:kvm
<kirkland> superm1: but there's an extended attribute on it
<kirkland> superm1: http://pastebin.ubuntu.com/49860/
<superm1> kirkland, ah interesting
<superm1> kirkland, well that's pretty neat
<cjwatson> doesn't that rely on extended attributes being enabled in the filesystem?
<kirkland> cjwatson: on /dev ?
<cjwatson> oh, it's a tmpfs I suppose
<superm1>  /dev should be tmpfs, I had assumed tmpfs had them enabled
<kirkland> i assumed it was given
<superm1> kirkland, so when you run kvm, does some sort of PolicyKit type of thing go off to ack you into the policy?
<superm1> or is that a separate piece that will still need to be developed?
<kirkland> superm1: i think that's still tbd
<cjwatson> right, sorry, I was thinking of / where I don't think xattrs are reliably available
<slangasek> siretart: 2.6.24> if that's what you have available, yeah
<kirkland> superm1: in case you're interested ... https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/273764
<slangasek> cjwatson: s/reasonable/desired/? :)
<ubottu> Ubuntu bug 273764 in kvm "add hal/PolicyKit support to kvm" [Wishlist,In progress]
<kirkland> superm1: that has the debdiff that's working for me for kvm
<cjwatson> slangasek: I was carefully not specifying :)
<kirkland> geser: you asked as well, see the debdiff for https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/273764
<kirkland> geser: that's "working" for me for kvm
<cjwatson> slangasek: I think probably desired, though
<kirkland> geser: but I'm awaiting pitti's review and blessing there of
<calc> hmm my power company claims they completely fixed power for my zipcode but my neighbor tells me the power is still out just as badly as before
 * calc considers making the 1.5hr drive to see how what is up
#ubuntu-devel 2008-09-24
<apetrescu> I'm trying to build the latest Anjuta that was released recently, but I'm running into a problem caused by the fact that ubuntu's copy of gnome-build is severely, severely outdated
<apetrescu> The latest version is 2.24, Ubuntu stocks 0.2.4.
<apetrescu> Does anyone know if any deb packages exist for a more recent gnome-build, or should I file a launchpad ticket about this?
<acoc> hey guys, I am interested in getting a checkout of the ubuntu-seeds, but https://launchpad.net/ubuntu-seeds says it does not use launchpad for development, where are the seeds located?
<TheMuso> acoc: The seeds for ubuntu intrepid for example can be checked ot with this URL: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.intrepid
<acoc> TheMuso: thank you, why does that website say it is not developed through launchpad?
<TheMuso> acoc: Because the ubuntu-seeds project is only used for bzr branch hosting. There are no tarballs/websites/docs etc associated with it,.
<TheMuso> acoc: As far as I understand anyway.
<TheMuso> acoc: You can view all bzr branches associated with that project by going to https://launchpad.net/ubuntu-seeds/+branches
<acoc> TheMuso, ok thanks, very helpful
<TheMuso> acoc: You're welcome.
 * maswan looks around, hunting a USN-645-1. :)
<asac> maswan: will be published quite soon i guess
<asac> maswan: its basically what was announced here: http://www.mozilla.org/security/announce/
<pitti> Good morning
<pitti> kirkland: yes, I told you; you need to add the addon to the computer device, like in ./policy/10osvendor/10-cpufreq.fdi
<pitti> kirkland: the computer device is always initialized, so you can use it as a kind of "startup hook" to trigger the calling of addons (scripts in /usr/lib/hal/)
<maswan> asac: Ah, ok. I was just a bit confused when the changelog I got mailed to me just said "oh, see usn-645-1 for whatever critical stuff we're updating now" :)
<asac> maswan: yes. we dont include the detailed advisory titles/CVEs in changelog anymore; otherwise we wont be able to deliver in-sync security updates with mozilla
<torkel> asac: It is intentional that I have to select which certificate to use multiple times (again) in intrepid? The "remember" checkbox is missing.
<asac> torkel: what kind of certificates are those? client or server side?
<torkel> asac: client
<asac> torkel: ok. but thats not a regression right?
<asac> (regression in the last upload)
<dholbach> good morning
<asac> good morning dholbach
<torkel> asac: well, before the last upload I was only asked once (for each site), now I am asked multiple times
<dholbach> hiya asac
<torkel> asac: I think it changed with the upload of xulrunner, not ff
<asac> torkel: what update was that. build3 -> build6? or was it 1.9.0.1 -> 1.9.0.2
<asac> ?
<torkel> build3->build6
<torkel> i.e the upload that was done yesterday
<asac> interesting. anyway. the next nss upload should fix it for you
<torkel> asac: great. thanks!
<asac> i am currently trying to find out if we already have a test build somewhere
<asac> torkel: but client certs still work at least right?
<asac> torkel: ohj ... you said "again" above. does it mean that you had the same problem in 1.9.0.1?
<torkel> asac: somewhere in the hardy timeframe I switched FF to automatically choose a cert, and I just turned it off again a week ago. So I really don't know when it was fixed.
<tjaalton> asac: hey, is it a known bug that after a firefox update the current running instance can't be shutdown from File-Quit (or with ctrl-q)?
<asac> tjaalton: well. there are plenty of bugs surrounding upgrades while still running
<asac> tjaalton: do you have ubufox installed?
<tjaalton> asac: yes, it's a normal ubuntu system
<asac> i think the latest version should offer you a restart button ... which might help a bit
<tjaalton> the notification bubble?
<asac> tjaalton: are you currently in such a state?
<tjaalton> erm, popup
<tjaalton> yep
<tjaalton> this is hardy
<asac> tjaalton: within firefox ... there should be a yellow notification bar
<asac> tjaalton: ah
<tjaalton> I'll try it on intrepid
<asac> tjaalton: on intrepid there should be a restart button in a notification area (like remember password) after upgrading firefox ... which might still have issues :)
<tjaalton> asac: heh, ok. will see how it works
<asac> tjaalton: http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
<tjaalton> asac: oh, looks nice
<alex_mayorga> hi, is there a chance of bluez-gnome-1.4 making it into intrepid?
<tjaalton> asac: hum, nothing happened :) I got the light bulb on the notification area, but no restart button on the browser
<alex_mayorga> tjaalton, you mean in FF .2 update?
<tjaalton> alex_mayorga: right, the latest one
<alex_mayorga> I got a reset button on FF, similar to the save password one, after the latest safe-upgrade on Intrepid
<alex_mayorga> I also got a button to "my rights" or something similar after the restart, that contained bits of the Mozilla license
<alex_mayorga> oddly, the light bulb notification didn't go away even after the FF restart
<asac> alex_mayorga: light bulb notification == the thing in the system tray?
<alex_mayorga> asac, exactly
<asac> tjaalton: strange.
<asac> tjaalton: sudo touch /var/lib/update-notifier/user.d/firefox-3.0-restart-required
<asac> alex_mayorga: you also got the restart button in-browser?
<asac> like /var/lib/update-notifier/user.d/firefox-3.0-restart-required ?
<alex_mayorga> I clicked Close button and it went away now
<asac> err
<asac> http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
<alex_mayorga> asac, yes I did, but looks like the notification didn't detected I've restarted already, not that it should IMHO
<tjaalton> asac: the file was already there? touching it didn't help
<alex_mayorga> asac, yes exactly like that screencap
<asac> tjaalton: is there any error in tools -> error console?
<asac> tjaalton: also, double check that you have no (old) ubufox instlaled in your profile (if tools -> addons offers you to "uninstall" then go for it)
<asac> alex_mayorga: yeah notification area isnt the smartes thing in the world. the in-browser restart button is supposed to replace that at some point completely
<alex_mayorga> anyone that might have decision power on the bluez-gnome thingie?
<tjaalton> asac: lots. are the new ones in the bottom?
<asac> tjaalton: you can filter for "errors" at the top of the error console
<davmor2> asac: why won't FF run under valgrind?
<asac> tjaalton: if there are still plenty of errors on the console its probably the reason ... would be cool if you could paste a few of those errors
<asac> davmor2: it should work
<asac> davmor2: i start like: valgrind /usr/lib/firefox-3.0.2/firefox
<davmor2> asac: okay ta
<tjaalton> asac: yeah, I keep getting more and more of the same error.. one sec
<tjaalton> asac: http://pastebin.ubuntu.com/49976
<asac> tjaalton: oh.
<asac> tjaalton: you are not having latest ubufox version?
<asac> tjaalton: that was an intermediate issue. thought i didnt upload that version :/
<tjaalton> asac: well I just upgraded, so was the latest one the first with this feature?-)
<asac> tjaalton: no. there were more before
<asac> at least the one before had that
<tjaalton> asac: ok, I'll restart and test the behaviour by hand
<davmor2> asac: ta that worked :)
<asac> tjaalton: ok 0.6~b1-0ubuntu1 had that issue
<asac> tjaalton: i then uploaded 0.6~b1-0ubuntu2 with just that fix
<asac> and ubuntu3 is the upgrade you should have received now
<asac> tjaalton: thanks
<asac> maybe you still had ubuntu1
<asac> davmor2: welcome
<tjaalton> asac: 0ubuntu1 installed on 16th, 0ubuntu2 on 18th and 0ubuntu3 today :)
<asac> tjaalton: maybe you didnt restart firefox ;)
<asac> (unlikely i know)
<tjaalton> asac: I did, started it right before the latest upgrade :)
<tjaalton> anyway, will try with the latest stuf
<tjaalton> +f
<asac> tjaalton: ok. lets see.
<tjaalton> asac: duh, still the same errors
<asac> *sigh*
<asac> tjaalton: what do you have as LANG?
<tjaalton> I wonder if I'm missing something
<asac> running plain en_US install?
<tjaalton> fi_FI
<asac> tjaalton: try to start firefox as LANG=en_US firefox please
<asac> tjaalton: btw, is firefox translated at all for you ?
<tjaalton> no.. langpack got removed at some point
<tjaalton> I'll try reinstalling that
<asac> tjaalton: no better not ;)
<asac> tjaalton: try LANG=en_US anyway
<asac> and then touch the file ;)
<alex_mayorga> Bug #273865 anyone?
<tjaalton> asac: yeah, that works
<ubottu> Launchpad bug 273865 in bluez-gnome "[needs-packaging] bluez-gnome-1.4" [Undecided,New] https://launchpad.net/bugs/273865
<asac> tjaalton: ok. thanks. i know what to do then :/
<asac> tjaalton: btw, the langpacks are now usually shipped in language-pack-XX
<asac> so no need to install the mozilla-firefox-locale-XX packages anymore
<asac> its just that they are most likely disabled atm
<asac> (in langpack-o-matic)
<tjaalton> asac: ok, I reinstalled -fi and the same problem. seems that FF isn't that well translated anyway
<asac> tjaalton: yeah. i think the ffox translations have been disabled :)
<asac> ArneGoetje: btw, i never received any complain about that from you ^^ ;)
<tjaalton> asac: heh, ok. I see some xulrunner-files there
<StevenK> bryce: The point of my mail was xterm might then start to show up. :-)
<tjaalton> pitti: do you think that shipping a simple fdi file to disable evdev from grabbing the thinkpad_acpi input device would be enough to fix bug 267682 for intrepid?
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Triaged] https://launchpad.net/bugs/267682
<slangasek> huh, how does stopping evdev from grabbing the input device fix it?
<slangasek> (in theory, or otherwise)
<tjaalton> works just fine here
<tjaalton> after that even battery and hibernate work
<slangasek> my question is "how" :)
<tjaalton> aha, well, to answer that I'd need to know a bit more about the underlying mess ;)
<tjaalton> but I guess one reason why evdev can't handle the battery hotkey is because it's not specified in symbols/inet
<tjaalton> commented out.. I don't think there is XF86Battery or equivalent..
<slangasek> pitti, ArneGoetje: language-support-extra-de grew a dep on hunspell-de-med, which is in universe and has no MIR?
<alex_mayorga> what package would the shutdown window belong to?
<dholbach> alex_mayorga: gnome-session AFAIK
<alex_mayorga> is it just me or the restart icon is smaller and the text miss aligned?
<alex_mayorga> dholbach: thanks, wonder if that should be filed or has already spotted, launchpad won't tell me or I'm queryu
<alex_mayorga> ing incorrectly
<dholbach> alex_mayorga: try asking in #ubuntu-desktop - somebody might know
<alex_mayorga> dholbach, thanks, turns out there a number of reports on that
<dholbach> alex_mayorga: ah, great
<alex_mayorga> you saved me of yet another dupe :)
<tjaalton> what component opens the popup about battery statistics when you hit the hotkey?
<sbeattie> pitti: did something happen to the kernel update in dapper-proposed? I can't seem to find it: http://paste.ubuntu.com/50006/
<geser> kirkland: thanks for pointing me to your debdiff, it helped a lot to write a similar file for my smart card reader
<geser> but now I'm stuck at assigning the device_file. http://paste.ubuntu.com/50012/ contans lshal output for my smart card reader, my current fdi file and the policy file
<geser> it works when I use the hard-coded device file name
<torkel> tjaalton: gnome-power-manager
<tseliot> seb128: as regards my patches for gnome-desktop and gnome-control-panel, shall I add an "ubuntu_" prefix only to the functions which I put in the header file gnome_rr_config.h or shall I add it to any function I added in gnome_rr_config.c and xrandr-capplet.c (even though such functions cannot be accessed externally)? The former makes more sense to me but I'll do as you wish
<seb128> tseliot: only for what is public api
<tseliot> seb128: ok, agreed
<slangasek> raphink: ping
<raphink> slangasek: pong
<slangasek> raphink: hi, ichthux seeds seem to need updates to not depend on khelpcenter and kghostview, which are both NBS packages; is that something you can take care of?
<raphink> slangasek: I could try to find some time
<tjaalton> torkel: ok, do you know about it's inner workings?-)
<raphink> lately, it's been txwinkinger doing that
<ara> hello, i have a question, which package provides system-config-printer-applet? system-config-printer-gnome? or another?
<seb128> ara: dpkg -S system-config-printer-applet if it's installed on your box
<ara> seb128: ta!
<seb128> ara: otherwise you can use packages.ubuntu.com
<seb128> you're welcome ;-)
<slangasek> raphink: should I contact txwinkinger about it instead?  (if so, how?  no such nick on IRC)
<TheMuso> ?C
<slangasek> raphink: since kghostview and khelpcenter are NBS packages, they should be removed before the intrepid release, which would make ichthux uninstallable if the seeds aren't fixed
<dholbach> slangasek: https://launchpad.net/~txwikinger
<raphink> slangasek: he's just not online right now, but he often is
<slangasek> dholbach: ah, those letter sare different :-)
<cjwatson> pitti: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt is healthy again
<cjwatson> in the "oh my god, it's full of packages" sense
<pitti> cjwatson: thanks
<pitti> tjaalton: it's certainly a valid workaround
<pitti> sbeattie: uh, that looks strange, it still appears on the SRU page
<liw> cjwatson, you suggest promoting the schrodinger implementation of dirac, not the dirac-research one? I've heard the latter is of higher quality, do you have other information?
<cjwatson> liw: is the latter in Ubuntu?
<cjwatson> liw: oh, also, I believe that the schroedinger implementation is the only one that is implemented as a gstreamer plugin
<cjwatson> so I was under the impression we only really had one choice
<liw> cjwatson, you may be right about gstreamer, at least
<liw> cjwatson, "dirac" and related packages should be dirac-research, as far as I can see
<cjwatson> ah, I see that the other implementation is in Ubuntu
<cjwatson> the BBC didn't object to schroedinger when I spoke to them, though
<liw> actually, now that I think about it, the quality difference was probably in encoding
<liw> yeah: http://www.schleef.org/blog/2008/09/20/dirac-in-the-news/ -- speaks specifically about encoding
<pitti> sbeattie: oh, it's still in NEW, fixing
<cjwatson> ah, right
<pitti> slangasek: ugh, landscape updates package info *hourly* now? isn't that a bit exaggerated?
<pitti> slangasek: I made a followup comment to bug 268765, FYI
<ubottu> Launchpad bug 268765 in landscape-client "landscape-client must have a cron job for updating smart package data" [Critical,In progress] https://launchpad.net/bugs/268765
<tkamppeter> pitti, can you fix bug 269311 today? Then I can upload an s-c-p with updated API today and the driver download can be tested in the beta
<ubottu> Launchpad bug 269311 in jockey "Session D-BUS call search_driver() should return list of files" [Critical,In progress] https://launchpad.net/bugs/269311
<pitti> tkamppeter: that's my intent, I just keep getting distracted
<gAri-> hello there, where should I report that the kernel traced out while using apparmor?
<gAri-> I have the log actually I would like to give to someone who knows what to do with :)
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<tkamppeter> pitti, can you tell me as soon as possible when you have uploaded the new version, so that I can download it and adapt s-c-p? Thanks.
<ogra> so what the heck makes my laptop hardlock on boot at the wine sysctl stuff :/
<gAri-> cjwatson: I submitted the bug, will I get information to my email address about the status of the bug?
<cjwatson> yes
<gAri-> okay I hope some intelligent guys will found out what is happening :)
<munckfish> cjwatson: I'm looking at some of the issues that stop the PS3 installer cd working.
<munckfish> cjwatson: re lp #251593. I'm working to find out why the spufs module isn't getting loaded auto
<ubottu> Launchpad bug 251593 in ubuntu-ps3-port "unknown filesytem type: spufs" [Critical,In progress] https://launchpad.net/bugs/251593
<munckfish> but I'm just starting out with this.
<munckfish> cjwatson: is it worth trying to patch sysvinit to add an extra clause which checks whether spufs module is loaded first?
<tjaalton> what time does the beta freeze start?
<munckfish> cjwatson: Or at least not fail configuration if mounting /spu fails
<cjwatson> sheesh, have people not learned not to ask "what time" questions about freezes yet? :)
<TheMuso> munckfish: You might also want to look at the initramfs-tools package.
<cjwatson> munckfish: yes, I think so
<TheMuso> munckfish: If I get a minute, I will have a look for you.
<munckfish> TheMuso: I'm not too familiar with initramfs yet. I'll take a look
<munckfish> cjwatson: also re LP #261490. Last cmt you mention probs with nvidia stuff - do you happen to know if those issues were addressed?
<ubottu> Launchpad bug 261490 in ubuntu-ps3-port "Intrepid installation fails (debootstrap warning)" [Critical,Confirmed] https://launchpad.net/bugs/261490
<cjwatson> munckfish: yes, I believe that got fixed
<cjwatson> (though I forget the details)
<cjwatson> munckfish: ah yes, https://launchpad.net/ubuntu/+source/nvidia-common version 0.2.2
<munckfish> cjwatson: thx
<TheMuso> munckfish: Well I can tell you for a fact that the spufs module is not loaded by the initramfs.
<munckfish> TheMuso: ok I see
<munckfish> Would it have to be loaded explicitly?
<munckfish> Apparently is should auto load I believe
<munckfish> just like any other filesystem type
<TheMuso> munckfish: I think so, since there is no modalias line that could cause it to be loaded by particular hardware being present.
<TheMuso> Let me check the module source to be sure though.
<munckfish> Hmmmm
<munckfish> ok cool
<pitti> tkamppeter: will do
<TheMuso> munckfish: Yeah I don't think there is any aliases as I said earlier.
<munckfish> TheMuso: thx I'll look into it further
<pitti> james_w: hm, I patched hal and policykit, and they still not work with CK 0.3; this is becoming a real time sink
<munckfish> Would  ...
<munckfish> if grep -q '^spufs' /proc/modules 2>/dev/null; then echo "Mount /spu!"; fi
<munckfish> ... be a decent way to check for this module?
<cjwatson> should use lsmod rather than /proc/modules I feel
<cjwatson> interfaces and all that
<TheMuso> munckfish: Where does spufs get mounted? I personally think you should actually check for a file in the spufs filesystem.
<cjwatson> I don't think it contains any files by default
<TheMuso> cjwatson: Oh ok.
<cjwatson> why not just mount the filesystem and ignore failures?
<cjwatson> if it doesn't work, big deal
<cjwatson> i.e. domount spufs "" /spu -ogid=spu || true
<broonie> munckfish: There's also /proc/filesystems you could check.
<pitti> kirkland: works great now, congrats! uploaded, I simplified the patch a bit and attached it to the bug FYI
<geser> pitti: based on kirkland debdiff I've started to write a fdi and a policy file to handle access to smart card readers to finally close bug 57755
<ubottu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755
<geser> pitti: I got it nearly working already but have problems with getting the acls set for the device, see http://paste.ubuntu.com/50012/ to see how far I got already
<geser> have you time to help me finalise it?
<pitti> not right now, sorry
<pitti> I *finally* need to take some time of my own to fix some beta bugs, I kept getting distracted :(
<geser> ok
<pitti> geser: I'll help you Friday/Monday, is that ok?
<geser> yes
<geser> the bug is already over two years old so some more days don't matter
<munckfish> cjwatson: yeah I prefer  just ignoring the mount if it fails, but still log it.
<mvo> cjwatson: could you please check (and merge) https://code.edge.launchpad.net/~mvo/debian-cd/mvo - a small fix that makes apt-cdrom add happy again
<james_w> pitti: sorry, was at lunch. That sucks, is there an error, or do they just not work?
<pitti> james_w: haven't debugged it yet, I need to find some time to work on my beta bugs
<pitti> james_w: I updated the bug, if you are interested
<james_w> pitti: sure
<cjwatson> mvo: surely that needs some kind of quoting :)
<cjwatson> mvo: also I didn't think + worked in sed without special options to support extended regexes
<cjwatson> -r I think
<cjwatson> mvo: I'll fix it up and merge, thanks
<cjwatson> mvo: err, actually, doesn't that break debootstrap? see the comment above
<mvo> cjwatson: quoting> right, thanks for fixing that
<mvo> cjwatson: debootstrap> not sure, if its needed there, then may we need to remove it later? is there a way for me to test this without building a full cd :) ?
<asac> tjaalton: i opened bug 273948 for you :)
<ubottu> Launchpad bug 273948 in ubufox "restart notification broken for locales that lack restart notification string translation" [High,Triaged] https://launchpad.net/bugs/273948
<mvo> cjwatson: I thought the comment means that its ok to remove them at this point, but I may be wrong of course
<kirkland> pitti: cool, thanks :-)
<kirkland> pitti: I forgot to add the "Suggests: hal"
<kirkland> pitti: did you add that, per chance?
<pitti> kirkland: no, forgot about it as well; but *shrug*, no big deal IMHO
<kirkland> pitti: it's okay, i'm fixing a bunch of kvm bugs
<kirkland> pitti: i'll put it in the next one
<kirkland> pitti: thanks for your help, btw ;-)
<pitti> kirkland: you're welcome; thanks for teaching me about <spawn> :)
<pitti> I already thougt yesterday "gee, why the heck can't FDI files create devices?" :)
 * Hobbsee clones pitti, and spawns new copies of him.
<pitti> Hobbsee: aww, I'll never finish argueing with those guys
<Hobbsee> pitti: oh dear.  that might be a problem.
<TheMuso> 5~/c
<Hobbsee> pitti: but you could fix bugs quicker!
<pitti> and keep up with my mail!
<Hobbsee> that too!
 * tseliot solves the problem with a simple "sudo /etc/init.d/pitti start"
 * pitti clones tseliot as well, and suddenly sees all jockey bugs fixed and all drivers out there packaged for ubuntu
<TheMuso> Ah... What I'd wish for a clone of myself. It would help me address accessibility related bugs/features quicker...
<Hobbsee> maybe the next UDS needs to focus on people cloning.
 * tseliot nods
<tjaalton> asac: ooh, thanks
<munckfish> cjwatson: I've attached a patch to that bug. I believe it's the postinst that's the problem as it runs with set -e. The normal mountkernfs init script does actually seem to fail.
<munckfish> it just shows a message on boot
<munckfish> http://launchpadlibrarian.net/17920729/0001-Prevent-postinst-configuration-failure-on-PS3-Cell-i.patch
<kirkland> pitti: that was superm1's idea! (spawn)
<james_w> I'm looking at bug 263888. SIGUSR1 used to re-open the log files, now it's not trapped. The logrotate file isn't installed by the current package though, as there are no longer any logs to rotate
<ubottu> Launchpad bug 263888 in acpid "acpid killed by default logrotate script" [Medium,Triaged] https://launchpad.net/bugs/263888
<lool> Hmm I'm looking at a set -e init script and the "status" action; it's implemented as status_of_proc "$ACPID" acpid && exit 0 || exit $?
<lool> I wonder why not simply status_of_proc "$ACPID" acpid; exit $?
<james_w> is the correct way to fix this to assemble a list of the logrotate md5sums from the old packages and remove the file on upgrade if it matches a known one?
<lool> james_w: haha you're touching acpid as well :)
<james_w> lool: heh :-)
<cjwatson> munckfish: looks fine, thanks; uploaded
<lool> james_w: If these were conffiles, I think you should try to remove them chekcing their md5 during upgrades, yes
<cjwatson> lool: under set -e, the script will fall over before the exit $?
<cjwatson> lool: so 'exit 0' would be clearer
<ogra> grmbl, why does evtouch use quilt
<cjwatson> lool: but yes, the code you quote is somewhat redundant. That sort of thing makes more sense when you need to do something non-trivial before exiting non-zero, like log_end_msg
<ogra> applying the patch to the package takes longer than developing it :P
<cjwatson> lool: my usual idiom is: CODE=0; action || CODE=$?; log_end_msg $?; exit 0
<jcristau> ogra: because quilt is <3
<TheMuso> ogra: We need quilt-edit-patch. :p
<cjwatson> err log_end_msg $CODE
<lool> cjwatson: Yeah, I wrote exit $? because I thought that it would work for set +e scripts as well
<ion_> Why not just action; CODE=$?
<cjwatson> ah
<ogra> TheMuso, well, the packager could just use simple-patchsy.mk ...
<cjwatson> ion_: set -e
<ion_> Ah
<TheMuso> ogra: oh yeah if it uses cdbs, I agree.
<cjwatson> ion_: under set -e, if action returns non-zero, you don't get an opportunity to go further unless you guard it with a conditional
<ogra> jcristau, quilt is in descriptor 3, yes :P
<ion_> cjwatson: Yes, i was thinking slow. :-P
<MacSlow_> tedg, the fusa uses dbus to communicate with gdm I assume.
<lool> Thanks all for discussion
<lool> In my particular I don't need anything in fact
<lool> I can just status_of_proc "$ACPID" acpid  :)
 * ogra has evtouch calibration work properly again ... and has it write to /etc/default/evtouch ... so now only fdi inclusion is needed ...
<ogra> sillyness of the day, the binary had the fixed font hardcoded without encoding ... which makes the font default to japanese
<tedg> MacSlow_: Not in the current incarnation -- the old GDM didn't support DBus.
 * ogra shakes head
<tedg> MacSlow_: Uses DBus for a bunch of other stuff, but sockets for GDM.
<MacSlow> tedg, ah ok... I assumed you intrepid fusa was using dbus with the newer gdm ... but since we don't ship the new gdm yet ... well my bad :)
<tedg> MacSlow: I'm hoping it'll use DBus in the Jackalope :)
<kirkland> pitti: thanks for the patch clean, i just reviewed it
<kirkland> pitti: i'm sorry about that, i'm glad you showed me that
<pitti> kirkland: no need to be sorry, I'm just a "clean rules file" fetishist
<kirkland> pitti: well, that's something I've been confused about, actually
<kirkland> pitti: now it's clear
<james_w> does this look ok for a prerm to remove the unneeded conffile? http://paste.ubuntu.com/50129/
<kirkland> geser: how did yours come along?
<kirkland> geser: this is the debdiff pitti eventually blessed with holy penguin pee: http://launchpadlibrarian.net/17919758/kvm.273764.simplified.debdiff
<cjwatson> mvo: I'm pretty sure that debootstrap looks for the md5sum of Packages in the Release file in order to verify that it decompressed properly
<cjwatson> mvo: and that therefore removing it will break
<cjwatson> mvo: don't see how we could remove it later - the CD is read-only!
<cjwatson> mvo: apt-cdrom never used to mind this
<geser> kirkland: http://paste.ubuntu.com/50012/ is how far I got, it works when I hardcode the path to the device but I don't manage to get it from hal
<kirkland> geser: oh, right, you might have a variable path, huh?
<mvo> cjwatson: ok, I will investigate this further
<cjwatson> thanks
<geser> kirkland: yes, it's a usb device, so the device name depends on the used usb port
<kirkland> geser: hrm, that does add a layer of complexity that I was immune to
<geser> kirkland: lshal lists it, but I didn't figure out how to access this info in the fdi file
<tseliot> seb128: ok, I have those patches. Shall I simply attach the patches in a FFE report or shall put the links to the new source code (i.e. the patched tarball, .changes, etc.)?
<seb128> tseliot: can you attach debdiff to some bugs?
<mvo> cjwatson: I added #273979 and milestoned it
<tseliot> seb128: sure, I can do that
<geser> kirkland: but your debdiff was really helpful to help me get to this point at all
 * tseliot reboots
<kirkland> geser: cool, thanks
<kirkland> geser: as soon as I get a smart card, i'll look forward to trying it out ;-)
<TheMuso> ?C
<MacSlow> gee ... Xorg just blanked and doesn't come back
<ion_> Meh, video playback is still broken with the radeon driver. /me downgrades to 1:6.9.0+git20080802.1f3eee36-1ubuntu1 again.
<slangasek> pitti: "mirrors only update daily" - says who?
<pitti> slangasek: ok, that might be a bit too general; at least that was true for the mirrors I used so far (de, us, es, uk, IIRC)
<pitti> are there actually mirrors which update more often?
<slangasek> I know the mirror that I pull from is updated more often than that
<slangasek> I don't know how often, but - several times a day for sure
<pitti> ah, that's news to me; sorry for being imprecise then
<cjwatson> the push mirrors update hourly
<TheMuso> My ISP's mirror often has new updates at best 3 hours after they get uploaded.
<tseliot> seb128: can I use this bugreport for the FFE?
<tkamppeter> pitti, it seems that the new pdftoraster filter in CUPS has a bug and causes blank pages to be produced in some cases, see bug 267903 and bug 269691
<ubottu> Launchpad bug 267903 in splix "rastertoqpdl segfaults or produces black printouts" [High,Incomplete] https://launchpad.net/bugs/267903
<ubottu> Launchpad bug 269691 in splix "[intrepid] Samsung ML-2010 Printer prints entirely black pages" [High,Incomplete] https://launchpad.net/bugs/269691
<tseliot> seb128: this one: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/220563
<ubottu> Ubuntu bug 220563 in gnome-control-center "Useful dual-head configuration requires manual editing of xorg.conf to set Virtual" [Low,Fix released]
<seb128> tseliot: ok
<tkamppeter> pitti, I asked the reporters for testing with a replacement filter for pdftoraster, a scriptonly containing '/usr/lib/cups/filter/cpdftocps "$@" | /usr/lib/cups/filter/pstoraster "$@"' and this one works. Should we replace pstoraster in CUPS for the beta?
<pitti> tkamppeter: I'm afraid I don't know these filters well enough for a qualified answer; but I thought the idea was to not convert pdf to postscript?
<tkamppeter> pitti, yes, we do not want to do too many conversions and Ghostscript can take PDF as input.
<tkamppeter> pitti, this filter is an interim workaround for the time being until we get a fixed pdftoraster.
<tkamppeter> pitti, Ghostscript needs very many parameters to generate CUPS raster. These parameters are set by PostScript commands in the PPD file. The new pdftoraster and also imagetoraster parse the parameters out of the PPD and create the raster data then. The pstoraster of CUPS takes these parameters embedded in the PostScript stream (by pstops).
<pitti> tkamppeter: it's not possible to reproduce the crash?
<tkamppeter> pitti, rewriting the parsing process would be awkward and very complicated if one wants to take into account all option types, including custom options.
<pitti> tkamppeter: well, your call I think, but it would basically revert 90% of the pdf workflow, wouldn't it?
<tkamppeter> pitti, the important core part of page management on PDF (pdftopdf) stays conserved.
<tseliot> bryce, seb128: I have attached the 3 debdiffs and the diffstat for the FFE here: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/220563
<ubottu> Ubuntu bug 220563 in gnome-control-center "Useful dual-head configuration requires manual editing of xorg.conf to set Virtual" [Low,Fix released]
<pitti> tkamppeter: but it'd seem better to me to just fix the segfault instead?
<tkamppeter> The best would perhaps be a C program derived from the current pdftoraster (or imagetoraster) which does the ugly parsing but instead of producing raster by itself it calls Ghostscript
<tkamppeter> pitti, this is less for the segfault, but because of the black pages.
<pitti> hm, I thought it said "crash"
<tkamppeter> pitti, Both bugs also complain about black pages.
<tkamppeter> pitti, the little script which I have written solved the black page problem.
<tkamppeter> pitti, and the reporter of the bug with the crash has even the crash solved. Seems that the crash was caused by broken CUPS raster data fed into the driver (but then the driver should also not crash).
<TheMuso> slangasek: I'm about to file a bug that I would like to be milestoned for beta, as I'm probably not going to get it fixed before beta freezre. I feel its important due to the fact that its currently not possible to install ubuntu onto a dmraid array, and successfully detect and make use of other operating systems, i.e no dual boot.
<TheMuso> slangasek: Does this sound ok for a milestone?
<slangasek> TheMuso: milestoning should be separate from requesting a freeze exception; in cases where the milestone state is relevant to the release team, it's used for tracking bugs that should be blockers for the milestone
<slangasek> TheMuso: that doesn't sound to me like a bug that should be a blocker since we're already ahead of where we were before on dmraid support - but I would certainly consider an update for it depending on how intrusive the fix is
<TheMuso> slangasek: RIght, I'll just file for a freeze exception once I have it sorted out, probably tomorrow or Friday at the latest.
<TheMuso> thanks
<calc> i am trying to do a bzr merge and it tells me there is nothing to do :(
<calc> is it possible to get it to be more verbose about why? -v doesn't seem to help
<slangasek> Riddell: what's the reason for adding openbabel in main, that it should be a blocker for beta? (bug #236051)
<ubottu> Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete] https://launchpad.net/bugs/236051
<jdong> calc: bzr missing other_branch
<jdong> calc: shows what you have that they don't, and vice versa. (i.e. commits)
<Riddell> slangasek: it was supposed to have a security review, but that never seemed to happen
<slangasek> Riddell: well, but I'm wondering if there's a strong reason that this should be a blocker
<Riddell> slangasek: I don't know, you'd need to ask security people
<slangasek> er
<slangasek> I mean, if there's a strong reason that having openbabel in main should be a blocker for beta
<slangasek> it should certainly be subject to security review before we let it in...
<Riddell> I don't know
<Riddell> I'm not a security person
<slangasek> if it really needs to be included, then I would lean on the security team more to get the review done; but it doesn't look to me like this is critical to have for intrepid
<jdstrand> if I recall, kees did the intial review, said 'fix this', it got fixed
<slangasek> but the question I asked you wasn't about security, it was "why do you want openbabel in main?" :)
<Riddell> slangasek: because it adds nice features which our user and edubuntu want
<Riddell> it's in main
<slangasek> oh, it's already promoted and only the security review is missing?
<Riddell> only the security re-review
<slangasek> kees: can you confirm that openbabel is ok for main now (bug #236051), given that it already is?
<ubottu> Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete] https://launchpad.net/bugs/236051
<cjwatson> calc: which are the two branches involved?
<jdstrand> slangasek, Riddell: to pre-emptively answer a perceived to be forthcoming question-- I plan to finish the libzip review today
<slangasek> jdstrand: thanks :-)
<slangasek> jdstrand: I wasn't going to pester you yet, I know you've had your hands full :)
 * jdstrand nods
<jdstrand> slangasek: btw, that issue should now be fixed
<calc> cjwatson: bzr+ssh://ccheney@bzr.debian.org/srv/bzr.debian.org/bzr/pkg-openoffice/packages/openofficeorg/3.0/experimental/ and bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/
<slangasek> jdstrand: the issue of having your hands full? :)
<jdstrand> ha!
<jdstrand> slangasek: no-- the one we discussed that made my hands more full (a-c-c) ;)
<slangasek> oh, if you mean the pam interaction one, I saw the bug closure :)
<slangasek> thanks :)
<jdstrand> np
<kees> slangasek: yeah, I'm happy with babel.
 * calc brb son threw up everywhere
<slangasek> kees: please close the bug?
<kees> slangasek: one sec
<kees> slangasek: done
<slangasek> kees: thanks :)
<calc> back
<calc> so yea it won't let me merge the debian into the ubuntu branch it says nothing to be done
<calc> and bzr missing incorrectly claims only 1255 to current is missing from the debian tree which is why it won't let me merge an older set (1244) to it
<calc> oh nevermind i am nutty
<calc> or i think i screwed up something myself without realizing it
<calc> the changelog entries threw me off
<calc> cjwatson: never mind
<calc> he deleted a changelog entry in his set so i was trying to merge something old that i didn't realize i had already merged
<calc> doh
 * calc notes deleting changelog entries is bad
<cjwatson> 1255-current certainly looks right based on logs
<calc> cjwatson: yes it is, after more thorough examination i found he deleted changelog entries which caused my basing off of looking at annotate to come up with a number i had already merged without realizing it :\
<calc> so i merged head and it works fine :)
<cjwatson> oh, yeah, a much better way to check is bzr log of both sides
<cjwatson> bzr log --show-ids if you really want to be certain
<calc> ok
<cjwatson> note that bzr simply doesn't record non-contiguous merges - i.e. if you'd merged up to 1244 and then just revision 1255, it would only remember that you'd merged up to 1244
<calc> yea, i try to always merge to a released debian version to base off of
<calc> so don't pull individual changesets
<calc> unfortunately OOo 3.0 is now pushed back to Oct 7, that seems to be the final date, but is very unlikely to be stable enough in the short window available
<calc> they are still finding bugs now but are marking them for 3.0.1
<doko> calc: please upload to the ppa. still better than the beta ;)
<calc> doko: yes i will be
<calc> just making note that it definitely doesn't look like a good idea to replace 2.4.1 anymore
<calc> since its pushed back so far
<calc> my neighbor just called, we have POWER :)
<calc> yipee
<calc> so now i will have access to my desktop in a few hours
<liw> calc, congratulations
<calc> only took them 2 weeks to restore my power, lol
<calc> there wasn't even any real damage in the area, apparently the underground power in our neighborhood was feed by an above ground pole at some point
<calc> ok i am going offline for a bit, packing up and then heading back to my house :)
<cjwatson> good luck
<Awsoonn> ping mvo
<james_w> lool: updated patch in bug 263888, thanks
<ubottu> Launchpad bug 263888 in acpid "acpid killed by default logrotate script" [Medium,Triaged] https://launchpad.net/bugs/263888
<tkamppeter> pitti, I will do the following with CUPS: I will put in my script as an interim solution only for the beta, after the beta I will provide something written in C (to use CUPS libraries) which calls Ghostscript feeding in PDF directly.
<tkamppeter> pitti, WDYT about that?
<Keybuk> http://people.ubuntu.com/~scott/u6y-fail.png
<cjwatson> yeah, there's a bug about the ... err ... interesting colour choice
<cjwatson> bug 273271
<ubottu> Launchpad bug 273271 in ubiquity "Don't use gray as a partition color in the new partitioner" [Medium,Triaged] https://launchpad.net/bugs/273271
<Keybuk> evan's gay genes were clearly trying to co-ordinate colours ;)
 * evand hides
<davmor2> Keybuk: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/271512
<ubottu> Ubuntu bug 271512 in ubiquity "Intrepid: Partition reports incorrect sizing" [Undecided,New]
<evand> Keybuk: You'd figure my inability to coordinate color would be evidence to the contrary.
<cjwatson> davmor2: that's a different bug
<davmor2> Ah yeah sorry :)
<Riddell> slangasek: if you're looking for release critical bugs, here's one https://bugs.launchpad.net/rosetta/+bug/273489
<ubottu> Ubuntu bug 273489 in rosetta "Remaining Intrepid template approvals" [Critical,In progress]
<pitti> tkamppeter: you are the expert :) but ok for me to rescue printing in the beta; you'll get less feedback, though
<tkamppeter> pitti, feedback about known bugs which could mask other bugs is bad.
<mathiaz> ahasenack: meh - landscape-client doesn't register when the package is installed from the installer.
<mathiaz> ahasenack: that's because landscape-client is not started and dbus is not running
<ahasenack> mathiaz: any idea why?
<ahasenack> hmm
<ahasenack> mathiaz: it may register later when the machine is booted, it tries in the background IIRC
<ahasenack> mathiaz: but I suppose there is an ugly error message during the installation
<mathiaz> ahasenack: well - in the syslog yes.
<jkakar> Is DBUS ever expected to run in the installer?  Is this just an ordering issue?
<mathiaz> ahasenack: this is the backtrace: http://paste.ubuntu.com/50203/
<ahasenack> mathiaz: "fake start-stop-daemon"?
<mathiaz> ahasenack: right - daemons are not started during the install by default
<cjwatson> jkakar: dbus is intentionally not started in the installer
<mathiaz> ahasenack: well - the registration is retried in the background
<cjwatson> landscape-client should cope somehow, perhaps by registering at boot
<cjwatson> should as in "needs to"
<mathiaz> cjwatson: correct - that's the case
<cjwatson> starting daemons in the installer is a real can of worms
<niemeyer> Hmm
<niemeyer> It can actually already do that, we just need the right flags in place
<niemeyer> We just won't be able to tell immediately if there's something wrong (e.g. the registration password, or account name)
<mathiaz> well - AFAICT the computer was registered after the first boot - it just doesn't show up right away
<ahasenack> mathiaz: what account did you use?
<niemeyer> Or it could, anyway..
 * niemeyer checks
<mathiaz> ahasenack: my own account -
<mathiaz> ahasenack: I think it works
<mathiaz> ahasenack: it's just that you have to wait for the first reboot and little bit afterwards until the registration process is retried by landscape-client
<niemeyer> Oops.. no, apparently the ladnscape-config option was removed at some point
<ahasenack> mathiaz: did you reject the registration request on the server?
<mathiaz> ahasenack: I think I accepted it
<mathiaz> ahasenack: but I've already deleted the computer from my account
<ahasenack> ok
<niemeyer> mathiaz: Yes, you're right.  Even with that failure, I think that should be the case indeed.
<niemeyer> mathiaz: The computer should continue to try connecting.. nowadays the dbus connection in landscape-config is just to make the process faster and to provide live feedback to the user.
<mathiaz> ahasenack: I'll redo a test install.
<ahasenack> mathiaz: where can we get this iso?
<mathiaz> ahasenack: http://cdimage.ubuntu.com/ubuntu-server/daily/
<niemeyer> mathiaz: I wonder what would be the best way to handle this
<niemeyer> mathiaz: We could support a --no-registration option somewhat easily
<niemeyer> mathiaz: But the registration behavior is actually nice, when it does work
<ahasenack> hmm, that will take some time to download
<ahasenack> like, tomorrow
<niemeyer> Maybe we should just prettify the error message
<niemeyer> "Connection to the landscape broker failed." or something
<cjwatson> it shouldn't cause a visible error in the installer at all
<cjwatson> and it needs to not cause the package to fail to configure
<cjwatson> that's very important - the installer by design doesn't recover easily from that
<mathiaz> cjwatson: ok - as of now that's what happen (the pkg fails to configure)
<cjwatson> I know
<cjwatson> I read the log
<niemeyer> cjwatson: Hopefully neither of these ideas conflict with the suggestion above
<cjwatson> they don't, but simply changing the error message isn't enough :)
<cjwatson> that's all I'm emphasising
<niemeyer> cjwatson: Yeah, I was mostly thinking about landscape-config..
<ahasenack> well, seems we can't register during installation
<mathiaz> niemeyer: IIUC we could get rid of landscape-config in the postinst if we don't want register at all
<ahasenack> but that wizard also prepares the client.conf file
<niemeyer> mathiaz: Why does configure fail exactly?
<ahasenack> so maybe have an option for it to not attempt the registration, just prepare the conf file
<mathiaz> niemeyer: because of the registration with dbus
<niemeyer> mathiaz: We want to set it up, and that's the way in which we setup the landscape-client
<niemeyer> mathiaz: That's why landscape-client fails.. what exactly is causing the configuration of the package to fail?
<niemeyer> Sorry.. s/landscape-client/landscape-config/
<mathiaz> niemeyer: landscape-config returns a non 0 value
<mathiaz> niemeyer: http://paste.ubuntu.com/50203/
<mathiaz> niemeyer: how does landscape-client checks if it should register ?
<mathiaz> niemeyer: if there is a retry in the background, landscape-client has a way to figure out that it has all the information to do the registration on its own
<niemeyer> mathiaz: How is the script run?
<niemeyer> mathiaz: I mean, normally a command in the middle of a script which return s non-zero value won't cause the whole script to return non-zero
<niemeyer> mathiaz: I guess it's using some flag to enforce that?
<mathiaz> niemeyer: maintainer scripts are run with set -e
<niemeyer> mathiaz: Cool, thanks
<niemeyer> mathiaz: As I explained above, this is already the case
<niemeyer> mathiaz: The whole procedure will work fine, besides this error
<niemeyer> mathiaz: The point is that the immediate registration is a good thing, when possible
<niemeyer> mathiaz: It informs the user about errors in the information entered, and turns the process into something immediate, rather than on the next restart
<niemeyer> mathiaz: So we should just ensure that landscape-config doesn't blow up, so that we don't screw the rest of the installation procedure
<mathiaz> niemeyer: right - so I could a || true to the landscape-config command line
<niemeyer> mathiaz: But trying to keep the current behavior
<niemeyer> mathiaz: Yes, that would be a good immediate solution
<niemeyer> mathiaz: We should prevent the traceback too ASAP
<mathiaz> niemeyer: could landscape-config be modified to prevent to traceback ?
<niemeyer> mathiaz: Definitely
<mathiaz> niemeyer: I'd rather have that than adding || true to the maintainer script
<mathiaz> niemeyer: there is a legitimate use case to not have the registration working.
<niemeyer> mathiaz: Cool, let's do that then
<mathiaz> niemeyer: adding a || true would just catch all the other potential errors
<niemeyer> mathiaz: True
<mathiaz> niemeyer: how fast could this be implemted ?
<niemeyer> mathiaz: Quite quickly I believe
<tkamppeter> pitti, CUPS package with interim pdftoraster is uploaded
<niemeyer> mathiaz: It's just an option and a conditional.. the unittests are a bit boring on that area, though
<niemeyer> Well, not an optional
<pitti> tkamppeter: ah, ok; did you create an ubuntu bzr branch for cups?
<niemeyer> Erm.. not an option.. we'll just catch the exception
<mathiaz> niemeyer: could you get something ready today ?
<tkamppeter> pitti, no. It is only an interim, the final solution I will put into the Debian BZR.
<tkamppeter> pitti, it is only to get more chances to fix printer driver bugs with the beta.
<pitti> tkamppeter: ok, noted; we just must be careful to not overwrite it accidentally
<niemeyer> mathiaz: It depends on what else is going on.. I'm personally trying to address other important issues ATM.. I'll check if radix or someone else might have some time for it
<radix> yo
<radix> I can help
<tkamppeter> pitti, in principle we should have Ubuntu and Debian CUPS synced. Deviations we do only if needed, for example if we have deadlines ahead or if you are on vacation.
<mathiaz> radix: great - could you branch from lp:~ubuntu-core-dev/landscape-client/ubuntu ?
<tkamppeter> pitti, I got another note from a bug reporter now, that the interim script did not only fix the black pages but also the crash. The original filter from OP Japan seems to produce really broken CUPS raster.
<mathiaz> radix: this is the bzr branch that has the code that is uploaded to the archive.
<radix> mathiaz: sure thing
<radix> mathiaz: will you upload this as an ubuntu* bump, or should we release a new version number?
<mathiaz> radix: what's easier for you
<mathiaz> radix: if rolling a new tarball is too complicated we can bump the revision.
<mathiaz> radix: The main factor here is time.
<pitti> tkamppeter: just posted a followup question to bug 269454
<ubottu> Launchpad bug 269454 in jockey "Poor user interface when printer setup tool asks Jockey for a driver" [Undecided,In progress] https://launchpad.net/bugs/269454
<pitti> tkamppeter: I fixed the search_driver() bug, and would like to get this one settled as well, then I'll do a 0.5beta1 release and upload to intrpeid (it's the last bug on https://edge.launchpad.net/jockey/+milestone/0.5)
<radix> mathiaz: ok, well, I'll start on the change now :)
<mathiaz> radix: thanks
<radix> hopefully in the next release we'll be able to have much nicer installer integration
<niemeyer> mathiaz: What's the deadline for getting important fixes in?
<niemeyer> mathiaz: In general.. I know the sooner the better
<mathiaz> niemeyer: well - we're entering BetaFreeze tomorrow
<mathiaz> niemeyer: so starting from tomorrow until Beta is released (ie in one week) all the uploads have to be approved by the release team
<doko> help, how do I revert the effect of the magnifying glass?
<niemeyer> mathiaz: Cool, thanks
<mathiaz> niemeyer: we should be able to get Freeze Exception has this issue has a direct impact on the installer.
<mathiaz> niemeyer: we should be able to get a Freeze Exception *as* this issue has a direct impact on the installer.
<niemeyer> mathiaz: That's cool.  Hopefully we'll be able to get the fix in before the freeze
<Riddell> james_w: how come bzr-buildpackage doesn't run debsign?
<Keybuk> ok
<Keybuk> which smart-arse moved mountkernfs.sh to S02 from S01?
<geser> doko: is it save to disable building libgcj-doc in gcj-4.2? libgcj-doc gets also build from gcj-4.3 and this prevents the upload of the i386 build of gcj-4.2 to get accepted
<pitti> tseliot, superm1: wrt. bug 262819, do you think the fglrx driver is working well enough to lift it to restricted and add the fglrx-modaliases recommends to jockey-common?
<ubottu> Launchpad bug 262819 in jockey "Jockey doesn't offer fglrx" [Critical,Triaged] https://launchpad.net/bugs/262819
<superm1> pitti, i wouldn't do that until we have one that works with the x server in intrepid
<Keybuk> pitti: it looks like it was you, so I retract the rudeness ;)
<superm1> pitti, it works if you pin the x server to hardy only at this point
<pitti> Keybuk: oh, fallout from the debian merge? I don't think I deliberately changed that?
<Keybuk> but err, next time you merge sysvinit, please don't rearrange the boot ordering :p
<tseliot> pitti: no, we shouldn't do it yet
<pitti> superm1, tseliot: ack
<Keybuk> pitti: possibly not, a 1 changing to a 2 is hard to spot in a postinst
<pitti> Keybuk: there were only three differences in Ubuntu, which I kept (and asked you about)
<Keybuk> the fact you didn't include any migration code for upgrades suggests it was simply an accident
<superm1> pitti, there is still the problem regarding gcc-3.3 and fglrx too that would be needed to be sorted out before repromoting to restricted
<pitti> Keybuk: ok, sorry if that screwed up something
<Keybuk> pitti: was breaking readahead
<pitti> Keybuk: 02hostname needs it?
<Keybuk> no /var/run, /proc, etc. :)
<pitti> ah, readahead
<doko> geser: I'd say its safe to remove gcj-4.2 in intrepid
<superm1> (bug 271794)
<ubottu> Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794
<doko> pitti: wa this reaaly necessary? please could somebody talk with these guys?
<bryce> doko: are you referring to bug 271794?  I talked with those guys about it
<ubottu> Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794
<bryce> doko: or, I mentioned it to them; no response from them so far
<doko> bryce: exactly
<bryce> doko: don't bank on seeing a fix to that for intrepid though; they're scrambling just to get caught up to xserver 1.5, and I'm doubtful many other issues are going to get attention
<bryce> doko: I have a phone call with them next week, and am planning on re-raising it then and try to get a response
<doko> bryce: nice
<geser> doko: pdftk still needs libgcj8-1 (from gcj-4.2) and it FTBFS with gcj-4.3
<doko> geser: pdftk should better be fixrd
<geser> doko: I tried, the problem is that gcj-4.3 doesn't like mixing c++ and java exceptions in one translation unit anymore
<geser> it looks like all the code using c++ iostream and fstream needs to be moved into an own file
<pitti> doko: erm, I didn't promote gcc-3.3 ... over my dead body... or did I?
<pitti> doko: oh, I didn't *phew*
 * calc is back in his own his with power finally after two weeks :)
<calc> er house
<calc> no television though for a while, directv is swamped with realigning the dishes
<calc> they couldn't even make an appointment for me since it is too far out in the future for their systems
<tedg> calc: You can probably realign it yourself, it isn't hard.
<calc> tedg: it looked substantially harder for the hd dish than the old regular one
<calc> plus i don't have a > 24' that can reach my roof :-\
<tedg> calc: It is, but it's still not that difficult.
<calc> grr dropping words, ladder
<tedg> Okay, it would be hard if you were trying to throw baseballs at it to align it. ;)
<calc> tedg: how do you do it? it completely bent it over, i can't see it up close but its knocked over in at least a 45 degree angle
<_Zeus_> calc: is this all from ike?
<calc> _Zeus_: yea
<tedg> calc: Well, if it's broken, that's another story.
<calc> tedg: i'm not sure if its broken or not, but its at least been bent over quite a bit
<calc> it might have worked the bolts loose, not really sure though
<tedg> calc: But, your STB has meters to show your signal.  Basically you can use those.  But, also, if you go through the full setup (reset everything) it'll tell you the angle to put it at.
<calc> ok
<calc> well i might see if my dad can help me with it this weekend if he isn't still working on ike stuff (works for a telco)
<calc> he access to a better ladder as well
<tedg> The latter is key.
<tedg> ladder that is.
<calc> _Zeus_: ike is why we don't have OOo 3.0 yet ;-)
<calc> but now i have internet and access to my desktop pc so i can get it working
<tedg> Note, you probably don't want to do "Reset All" to your HD DVR if you have one.  It'll remove all your recordings.  Do it to a non-DVR if you can.
<calc> tedg: yea
<radix> mathiaz: just to keep you updated, I have a potential fix that's unit tested, and I'm about to do some manual tests on my intrepid box
<radix> mathiaz: (for the landscape-config thing)
<mathiaz> radix: awesome ! thanks for your help !
<acoc> hey guys, could you direct me to your documentation on the cd-build process (ie germinate to livecd)
<ahasenack> when a package that was in universe is moved to main after a certain version, what happens to the previous versions? Are they also moved into main? Are they deleted? Do they stay in universe?
<slangasek> Riddell: who is he waiting for approval from to run this SQL script?
<slangasek> ahasenack: a change in the package's component is done on a per-distro basis; by default only the current development release is affected
<jdstrand> slangasek, Riddell: I am comfortable with libzip in main. I hope it's ok I marked the bug 'Fix Released' (since you seemed to only be waiting on me)
<slangasek> jdstrand: ok, thanks
<ahasenack> slangasek: this package only existed in the development distro (update-motd is the package)
<ahasenack> slangasek: I can't seem to find other versions other than the current one in the archive (1.7)
<mathiaz> ahasenack: right - update-motd has been added to intrepid.
<Riddell> slangasek: I've no idea
<ahasenack> mathiaz: so the older versions are gone?
<Riddell> jdstrand: great, thanks
<ahasenack> I checked main and universe
<ahasenack> inside pool
<jdstrand> Riddell: sorry for the delay, but it's finally done :)
<slangasek> ahasenack: older versions always go away from the archive; that's not related to whether it moves components
<ahasenack> slangasek: ah, ok, so the older versions I see in the package directories are from other distros, that's why they are still there
<mathiaz> ahasenack: you can find the publishing history in lp - https://launchpad.net/ubuntu/+source/update-motd
<slangasek> ahasenack: yes, from previous Ubuntu releases
<ahasenack> slangasek: right, thanks
<Riddell> siretart: don't suppose you know what's up with this compile?  xine issue https://edge.launchpad.net/ubuntu/intrepid/+source/kdebase-runtime/4:4.1.1-0ubuntu5
<jcastro> can someone with a minute please moderate my mail to ubuntu-devel please?
<evand> sure
<evand> dear lord, 1543 new messages to ubuntu-devel.
<evand> jcastro: approved
<nxvl> jcastro: around?
<jcastro> evand: thanks!
<jcastro> nxvl: yep!
<calc> fridge take a long time to cool down when they haven't been used for a while
<siretart> Riddell: it seems that this part of kdebase is redifining the keyword 'inline' to something funky.
<siretart> Riddell: it doesn't look like an issue in xine to me, TBH
<tkamppeter> pitti, can you upload a Jockey package ASAP with the fixed API (search_driver() to return result+list of installed packages) so that I can make an s-c-p package? Thanks.
<pitti> tkamppeter: still waiting for your input in bug 269454, but I could do an upload without that if needed
<tkamppeter> pitti, I have answered your questions now. bug mail notification is always delayed some time.
<ubottu> Launchpad bug 269454 in jockey "Poor user interface when printer setup tool asks Jockey for a driver" [Undecided,In progress] https://launchpad.net/bugs/269454
<pitti> tkamppeter: ah, thanks
<pitti> tkamppeter: anyway, I'm about to go to bed, so I'll do a quick upload now and a better one tomorrow
<pitti> tkamppeter: I documented the search_driver() result structure in README.txt, FYI
<tkamppeter> pitti, which hour tomorrow will the beta freeze be.
<pitti> tkamppeter: depends on slangasek, I don't know
<tkamppeter> pitti, thanks in advance for the quick upload.
<pitti> tkamppeter: uploaded
<NCommander> good $TIME all
<cjwatson> evand: it hasn't even been that long since I processed the queue. I suspect it's getting joe-jobbed
<evand> cjwatson: indeed, that's exactly what it was
<slangasek> yes, u-d-a is also getting joe-jobbed
<andrew_sayers> mdke: are you available to talk about IE6?
<mdke> andrew_sayers: sure thing
<andrew_sayers> mdke: ubuntu-doc better?
<mdke> yeah
<apachelogger> pitti: apport retracing marks a bug as duplicate of a private bug, but doesn't mention/explain the private state, which apparently confuses users (at least the one who just mentioned that) :/
<kirkland> bryce: ping
<kirkland> bryce: i'm nearly done fixing the kvm/keycode mapping bug
<kirkland> bryce: i have an X11 question, though
<kirkland> bryce: in the configure, I need a check to conditionally add the -lX11
<kirkland> bryce: for now, i just stubbed -lX11 onto the beginning of the SDL_LIBS
<kirkland> bryce: which "works", but it seems like that might be brittle
<kirkland> bryce: i'm hoping you might point me at some source with a more appropriate check that I can clone
<slangasek> eew, you're doing something that requires linking against libX11 directly? :)
<kirkland> slangasek: as opposed to... ?
<slangasek> I don't know - what are you doing that requires linking to libX11?
<kirkland> slangasek: detecting evdev or not in kvm's internal qemu
<kirkland> slangasek: http://pastebin.ubuntu.com/50278/
<kirkland> slangasek: keycodes = XGetAtomName(info.info.x11.display, desc->names->keycodes);
<slangasek> ah, yum
<cjwatson> kvm/keycode> hooray!
<kirkland> cjwatson: i'm 99% of the way there ;-)
<cjwatson> you make me so happy
<kirkland> cjwatson: it works, just trying to clean up one (possibly messy) aspect of the build
<slangasek> kirkland: you're, uh... not really editing configure directly, are you? :)
<kirkland> slangasek: this is debian/patches/evdev_keycode_map.patch
<kirkland> slangasek: what do you suggest?
<slangasek> kirkland: editing configure.{in,ac} and/or acinclude.m4, then regenerating configure
<slangasek> editing configure directly tends to lead to confusing errors down the line
<kirkland> slangasek: none of those exist
<cjwatson> just be careful to look at the resulting diff to make sure there isn't a vast amount of junk due to configure last having been generated with a prehistoric autoconf
<cjwatson> ... oh
<slangasek> <blink>
<kirkland> slangasek: apt-get source kvm
<cjwatson> you do sometimes get configure with no configure.ac, due to an INSANE UPSTREAM
<slangasek> looking :)
<kirkland> cjwatson: slangasek: aliguori is upstream for qemu, been helping me with this in #ubuntu-virt
<cjwatson> upstream isn't Fabrice any more?
<kirkland> cjwatson: him too :-)
 * slangasek scratches his head.  Tony is upstream for qemu?
<slangasek> right, so qemu/configure is a hand-written script
<slangasek> only 1572 lines long, though, so I guess that's ok ;P
<kirkland> slangasek: my reasoning was that if you have SDL, then you have X11
<kirkland> slangasek: so I just chunked it on the front of there
<slangasek> kirkland: I don't object to the reasoning; it might not fly with upstream, but it works fine for us :)
<kirkland> cjwatson: any objections from you?
<kirkland> that was my only reservation ....
<cjwatson> not at all, just that it's unconventional for "configure" not to be autoconf-generated, that's all
<kirkland> i'm going to post a debdiff and look for a sponsor
<cjwatson> but I can't see a libX11 dependency being a problem here
<kirkland> cjwatson: right libsdl depends on libx11
<kirkland> (fuzz up those names correctly ^)
<cjwatson> libsdl1.2debian doesn't seem to unconditionally depend on libx11-6
<kirkland> cjwatson: need an explicit build dep, then?
<cjwatson> the primary alternative seems to depend on libdirectfb
<cjwatson> kirkland: you should always use an explicit build-dependency when using something directly, rather than relying on transitive build-deps
<bryce> kirkland: no that's probably the right approach.  All the examples I could point to have the X11 libs as prereqs
<kirkland> bryce: thx
<cjwatson> kirkland: dpkg-shlibdeps should find the runtime dependency for itself, though
<cjwatson> the test for "do I need to build-depend on this even though one of my other build-deps depends on it" is "would I still need to build-depend on it if space aliens replaced that other build-dep with libhello?"
<kirkland> cjwatson: shall I add libx11-dev to kvm's control file as a build-depends?
<cjwatson> yes
<kirkland> kewl
<bryce> :-)
<bryce> cjwatson: btw all the bugs mentioned at this morning's meeting have been reviewed and resolved
 * NCommander flicks on the StevenK 
<NCommander> ^light
<bryce> cjwatson: also closed a couple others, all of which should be fine in current Intrepid.  there's just one intrepid targeted X bug - that we don't have -fglrx yet.
<cjwatson> thanks; I've been noticing lots of bugs from the meeting in the dist-upgrade I'm doing at the moment
<cjwatson> asac cleared out a bunch too
<cjwatson> bryce: do you think the acpi-support upload closed the hotkey bug? (I haven't had a chance to look yet, sorry, browser closed in preparation for reboot)
<bryce> I don't think so.  We didn't get mdz's test but several others tested it and did not find it fixed their issue
<bryce> but all the changes included in it fixed specific bugs in debian so I think they're good.  At least, no signs of regressions
<kirkland> cjwatson: patch attached to https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/258389
<ubottu> Launchpad bug 258389 in kvm "Keyboard acting strangely on Intrepid hosts" [Undecided,Confirmed]
<kirkland> cjwatson: zul offered to sponsor later tonight
<kirkland> cjwatson: but it's there if you want it ;-)
<cjwatson> oh, I'm not in *that* much of a rush, have to go out in a few minutes to pick up a friend from the station anyway
<kirkland> cjwatson: np ;-)  should be waiting for you in an update tomorrow
<cjwatson> kirkland: beer[kirkland] += 1 if it works
<james_w> Riddell: because I didn't and still don't have real upload rights anywhere, so I very rarely sign packages
<kirkland> cjwatson: i just noticed your comments about virt*[s|z]*
<james_w> Riddell: I don't think it should stay that way, but I haven't found a good way to suit both users that way
<cjwatson> Riddell: oh yes, I meant to answer that; FWIW I have debuild configured not to sign anything either so I don't notice the difference :-) I prefer the model commit, build, test, sign
<cjwatson> but it's easy to configure debuild either way, of course
<aliguori> slangasek, fabrice doesn't really work on qemu anymore.  he still has commit access but he's doesn't want to be maintainer anymore
<slangasek> ah, well then :)
 * pochu waves good night
#ubuntu-devel 2008-09-25
<Riddell> siretart: how does this patch look to you? http://www.kubuntu.org/~jriddell/tmp/xine-lib-1.1.15-cpp-compilation.diff
<kirkland> slangasek: any known tool chain issues at the moment?
<kirkland> slangasek: i can't compile qemu from sources right now on an up-to-date intrepid; same problem in my ppa
<kirkland> http://launchpadlibrarian.net/17939088/buildlog_ubuntu-intrepid-amd64.qemu_0.9.1-5ubuntu3_FAILEDTOBUILD.txt.gz
<slangasek> kirkland: nope, this is the first I've heard of a possible toolchain issue
<aliguori> kirkland, you don't have a <linux/dirent.h>?
<aliguori> fwiw, 0.9.1 is ancient
<aliguori> svn no longer depends on linux/dirent.h
<kirkland> aliguori: it's kind of late in Intrepid to do a merge
<kirkland> aliguori: we're almost up against Beta Freeze
<kirkland> looks like it's missing a build dependency on linux-headers
<aliguori> is linux-headers /usr/include/linux?
<aliguori> or /lib/modules/$(uname -r)/build/include?
<aliguori> b/c qemu uses /usr/include/linux
<kirkland> aliguori: ah
<aliguori> that should come with glibc i would think
<slangasek> dirent.h doesn't appear to be part of linux-libc-dev, i.e., not part of the headers linux exports for userspace
<kirkland> libc6-dev: /usr/include/dirent.h
<aliguori> kirkland, well svn now uses <dirent.h> and not <linux/dirent.h> so you may be able to get away with just changing it like that
<kirkland> aliguori: in linux-user/syscall.c:#include <linux/dirent.h>
<aliguori> yeah, i know
<kirkland> aliguori: okay, i'll try that
<kirkland> aliguori: we'll merge up qemu as soon as Jaunty opens
<kirkland> slangasek: am i correct in assuming that it's too late for a merge?
<slangasek> um it's a bit late without a pretty good justification :)
<kirkland> slangasek: yeah, i'm not willing to fight this one
<kirkland> aliguori: btw, debian has 0.9.1-6
<kirkland> aliguori: what's upstream at?
<hikenboot> no one in #ubuntu seems to know...anyone in here know if the python libaries (any of them in ubuntu) have been minimized to include just the libraries used in xen?
<ogra> slangasek, i have a bug i'd like to nominate for beta so it gets on you radar, but obviously i cant nominate bug 67366 since it was initially filed wrongly for baltix, now the balitx RM would have to approve a nomination ... can you put it on your radar somehow nontheless ?
<ubottu> Launchpad bug 67366 in ltsp "LDM does not warn when a user is already logged in" [Medium,In progress] https://launchpad.net/bugs/67366
<slangasek> ogra: try https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/67366?
<ubottu> Launchpad bug 67366 in ltsp "LDM does not warn when a user is already logged in" [Medium,In progress]
<ogra> lol
<ogra> silly ...
<ogra> i just clicked the link in the mail
<aliguori> kirkland, we have a problem with releases..  i think 0.9.1 is about a year old (but it's the latest)
<kirkland> aliguori: okay
<kirkland> aliguori: comparitively few people use qemu itself in ubuntu (it's in universe)
<kirkland> aliguori: i'd say most people use the bits built into the kvm package
<davismj> hello
<kirkland> aliguori: looks like that solved the build issue, thanks
<davismj> np
<kirkland> aliguori: i'm going to apply that patch (evdev one) to qemu in Ubuntu Universe
 * ion_ chuckles at Keybukâs module-init-tools changelog entry.
<kirkland> slangasek: is it too late to get that kvm patch sponsored?
<kirkland> slangasek: mathiaz has reminded me that beta freeze has started :-/
<slangasek> kirkland: do you have a debdiff somewhere?
<slangasek> (I haven't technically pushed the button yet for the freeze, anyway :)
<kirkland> slangasek:  https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/258389
<ubottu> Launchpad bug 258389 in qemu "Keyboard acting strangely on Intrepid hosts" [Undecided,Confirmed]
<slangasek> TheMuso: libcanberra-gnome added to desktop> was this discussed somewhere, and do you know how much space it'll cost us on the CDs?
<TheMuso> slangasek: It wasn't discussed, however sound events are somewhat broken without it. As for size, I'm just double checking, but its about 6/8KB.
<TheMuso> slangasek: yep 8KB.
<slangasek> ok
<TheMuso> slangasek: If need be, I can squash the ubuntu sounds down even further to get another 400/500KB space freed up.
<slangasek> TheMuso: I think 8KB will be ok :)
<TheMuso> slangasek: I was thinking of space for other things.
<slangasek> TheMuso: given that we're not currently oversized, I'd rather not have us twiddling that this late in the cycle
<TheMuso> slangasek: Ok.
<slangasek> kirkland: why are so many of these keys mapped to 0x0, and is that a regression?
<kirkland> slangasek: i duplicated the aliguori's code from gtk-vnc
<kirkland> aliguori: can you answer that?
<kirkland> slangasek: i tested all of the keys on my thinkpad
<slangasek> sure
<slangasek> but your thinkpad probably doesn't have any of these Japanese keys :-)
<slangasek> is there any other lib linkage needed for Xkb functions?
<slangasek> that's certainly not core libX11
<kirkland> slangasek: guilty on the no Japanese keys
<kirkland> slangasek: not sure about other libX11 linkage, that -lX11 was what i needed to get it to build
<slangasek> I fear that the xkb symbols are being resolved incidentally only
<slangasek> ah, no - they are in libX11
<slangasek> (surprising, to me)
<kirkland> slangasek: why's that/
<slangasek> ok, will upload shortly
<kirkland> slangasek: i found what i needed in /usr/lib/X11/*
<slangasek> why is it surprising?  Because X11 is much, much older than Xkb :)
<kirkland> slangasek: okay, and what did you do to verify?
<slangasek> objdump -T /usr/lib/libX11.so | grep .text.*Xkb
<slangasek> (should be grep \\.text.*Xkb, but)
<kirkland> slangasek: cool, thanks.
<slangasek> uploading
<ykphuah> asac: you there?
<ogra> ykphuah, that would be a lot of luck ... 3am here
<ykphuah> ogra: ah, do you know what time he is usually online?
<ogra> CEST office time and later
<ykphuah> CEST office time will be like, 5 hours from now?
<ogra> yeah, 5-7 ... depending if he's up early :)
<ykphuah> alright, thanks ogra
<Burgundavia> ogra: isn't evtouch usable in kde as well?
<NCommander> StevenK, yo?
<NCommander> slangasek, ping
<NCommander> pitti, ping?
<Hobbsee> NCommander: too late / too early
<NCommander> Hobbsee, know anyone of ubuntu-sru who lives?
<NCommander> at this time
<jdong> for i in /ircfs/freenode/#ubuntu-devel/nicks/*; do sleep 1m; echo "$i: (yo|ping)"; done
<jdong> :)
<NCommander> s/-devel/-sri/g
<NCommander> :-)
<NCommander> er
<NCommander> s/-sri/-sru/g
<Hobbsee> NCommander: not currently
 * NCommander notes that its kinda pathetic he has a full set of Ubuntu port machines
<NCommander> or access to them at the very least
<bdmurray> NCommander: maybe sbeattie
<sbeattie> NCommander: I'm around, but do not have archive privs. What do you need?
<NCommander> sbeattie, I have a PowerPC SRU fix that's been sitting for awhile
<NCommander> Its got three verifications, I need someone who can push it through
<sbeattie> NCommander: which one is that?
<NCommander> miro (source gnome-python-extras)
<NCommander> Let me find it
<NCommander> sbeattie, https://bugs.edge.launchpad.net/ubuntu/hardy/+source/gnome-python-extras/+bug/181068
<ubottu> Launchpad bug 181068 in gnome-python-extras "miro.real crashed with SystemError in MozillaBrowser() on PPC" [Low,Fix committed]
<siretart> Riddell: excellent!
<dholbach> good morning
<NCommander> hey dholbach
<NCommander> does anyone know who admins packages.ubuntu.com?
<dholbach> hi NCommander
<dholbach> NCommander: I'd say the IS team
<NCommander> It looks like one single person
<NCommander> I wanted to see if its possible to get the Ubuntu ports listed
<nxvl> NCommander: Keybuk
<NCommander> Keybuk, I've been looking at the packages scripts, I'd like to talk to you on getting the Ubuntu ports listed :-)
<mvo> pitti: on my intrepid system jockey offer me to install fglrx, however that breaks the system very badly (no xserver 1.5 support, diverts libdri.so that misses symbols). should I file a bug that it does not offer this driver or is that a known issue already
<tseliot> mvo: maybe we should make jockey conflict with fglrx-modaliases then
<tseliot> mvo, pitti: or maybe I can make jockey blacklist certain drivers
<mvo> tseliot: blacklist sounds like a good and flexible solution to me
<tseliot> mvo: good. If pitti agrees, I will implement this.
<Chipzz> not sure exactly how provides work
<Chipzz> but wouldn't a provide on the xserver api
<Chipzz> and then a conflicts from the xserver on previous apis be a nicer solution?
<RAOF> That's already implemented; xserver-xorg(-core ?) provides something like xserver-video-abi-2.1.  And so the fglrx package could indeed conflict with that.
<tseliot> ah, so you suggest that we hardcode the abi, hmm...
<RAOF> But that sounds like a less-friendly solution than blacklists.
<RAOF> Because that'll make jockey say "hey, you've got a driver you could install!", except it'd be lying, because it's uninstallable.
<cjwatson> NCommander: Keybuk maintains patches.ubuntu.com, not packages.ubuntu.com - nxvl was mistaken
<cjwatson> NCommander: AFAIK it's still Frank Lichtenheld (djpig on IRC though he's probably not on Ubuntu channels)
<RAOF> tseliot: The open drivers already depend on the exported abi, so making nvidia & fglrx depend on it to wouldn't be a bad thing.
<tjaalton> RAOF: they already do
<RAOF> But I'd think you'd probably want a blacklist as well, so you don't present impossible to install options.
<tseliot> RAOF: they already do
<RAOF> So why can you install fglrx?
<tseliot> we rebuild them every time the ABI changes
<tseliot> RAOF: because it was rebuilt
<slangasek> NCommander: ehm, how do you have three verifications on an sru fix if ubuntu-sru has only just now been subscribed to the bug?
<tjaalton> RAOF: actually, fglrx doesn't, nvidia does
<slangasek> NCommander: verifications are done on packages that have been uploaded to hardy-proposed...
<RAOF> tjaalton: Yeah.  I was just looking at xorg-driver-fglrx and there's no mention of the abi :)
<cjwatson> slangasek: for 181068? according to the bug, pitti accepted it into -proposed on the 12th
<tseliot> tjaalton: ah, didn't superm1|away do the same thing for fglrx?
<tjaalton> tseliot: doesn't seem like it
<cjwatson> as it happens I only see two verifications
<tseliot> we even talked about it
<cjwatson> but anyway
<slangasek> cjwatson: hrm, then who forgot to subscribe ubuntu-sru? :)
<tjaalton> that's why it is left installed on upgrade
<tjaalton> when it should be purged instead
<slangasek> ah, 'miro' was a red herring, I do see an SRU pending for gnome-python-extras
<tseliot> tjaalton: ok, understood
<Chipzz> RAOF: well I was actually thinking the other way around
<Chipzz> have fglrx provide xserver-video-abi-2.1, and have the xserver conflict with all versions below what it "provides"
<Chipzz> that way you don't have to upgrade the fglrx package to conflict on the xserver package when a new ABI is released
<RAOF> Chipzz: Right.  I've just reminded myself; that _is_ the way the drivers do it - nvidia appears to provide xserver-video-4, for example.
<tjaalton> I'll add it
<Chipzz> OTOH you could have the fglrx package Depend on a specific abi version too
<Chipzz> which I guess is probably the nicer solution, as your list of conflicts won't keep growing as more ABI versions are released
<tjaalton> the server doesn't Provide the ABI, so that doesn't work
<tjaalton> hm, the server also doesn't conflict -2.1 or -2.9
<Chipzz> tjaalton: I was not saying that's the way it's done; just pointing out a possible way of doing it
<pitti> Good morning
<tjaalton> Chipzz: sure, and I think it has been discussed at some point
<pitti> apachelogger: hm, that's indeed a known problem; we could do something about "explaining the reason", but not much else, I'm afraid
<pitti> NCommander: hi
<pitti> mvo: there are plenty of bug reports about it, so no new bug necessary
<mvo> ok, thanks pitti
<pitti> tseliot, mvo: no problem, we can just not ship the fglrx handler for a while
<pitti> tseliot, mvo: a related question is what to do on upgrades
<seb128> hello pitti mvo
 * pitti hugs seb128
<mvo> pitti: the current plan (discussed via mail last week) is to warn about it on upgrades and if the user still continues, transition him from fglrx to ati
<mvo> hey seb128
 * seb128 hugs pitti
<pitti> mvo: with update-manager and python-xkit?
<mvo> pitti: the same for nvidia-glx-71 and -96 (unless we get updates here that make those work)
<pitti> mvo: or shall we proxy that in jockey itself?
<mvo> pitti: yes, that is the current plan
<tkamppeter> pitti, have you seen my mail, about bug 269311?
<ubottu> Launchpad bug 269311 in jockey "Session D-BUS call search_driver() should return list of files" [Critical,Fix committed] https://launchpad.net/bugs/269311
<mvo> pitti: I don't mind either way, it seems like at least the warning stuff needs to go into u-m
<pitti> tkamppeter: haven't read mail yet (sorry, slept in, still a bit ill)
<mvo> pitti: and for the removal probably as well, because fglrx needs to be purged
<pitti> mvo: right
<Koon> pitti: did you see nijaba's email about the nagios2/3 in main mess ? Filed bug 273871 to fix it for intrepid
<ubottu> Launchpad bug 273871 in nagios3 "main inclusion for nagios3" [Undecided,New] https://launchpad.net/bugs/273871
<pitti> tkamppeter: btw, in case you plan to upload an s-c-p which uses search_driver(), that needs a FF exception
<pitti> Koon: yep, saw it
<pitti> Koon: everything is a bit slow, I seem to be a bottleneck for a thousand things, sorry
<pitti> Koon: I'll get to it today
<Koon> pitti: great, thx
<tkamppeter> pitti, I have already uploaded it, as I was assuming that the Feature of driver download was already accepted, due to your Jockey uploads.
<tseliot> pitti: but if we did that wouldn't we have to port the new code to older releases of Ubuntu (since they don't have the new jockey)
<tkamppeter> pitti, the patch to fix Jockey's search_driver() API change (reopened bug 269311) I have already applied to Jockey. It is a 2-byte patch, only the output signature which you have forgotten. Should I upload it (I only need to debsign and dput)?
<ubottu> Launchpad bug 269311 in jockey "Session D-BUS call search_driver() should return list of files" [Critical,Fix committed] https://launchpad.net/bugs/269311
<pitti> tkamppeter: oh, crap, I forgot that indeed
<pitti> tkamppeter: please do, and send me the patch, so that I can incorporate it into bzr
<tkamppeter> pitti, jockey_0.5~alpha1-0ubuntu6 uploaded
<tkamppeter> pitti, patch sent by mail.
<pitti> tkamppeter: thanks
<Tonio_> hi there
<Tonio_> can someone drop current kdesudo upload in the intrepid pipe ?
<Tonio_> it'll ftbfs due to stupid zsh script that corrupted main.cpp...
<cjwatson> Tonio_: the archive isn't frozen, so no, we can't
<cjwatson> just upload a fix following it
<Tonio_> cjwatson: oki but with a orig.tar.gz that changes it'll be rejected right ?
<Tonio_> I have to make a patch, probably...
<cjwatson> correct. you'll have to patch it
<Tonio_> hum ok
<cjwatson> (or bump the upstream version number, but you might not want to do that for the usual reasons)
<Tonio_> cjwatson: exactly ;)
<Tonio_> okay thanks
<wgrant> How precisely does an Ubuntu developer break the orig.tar.gz?
<Tonio_> wgrant: cause I'm also upstream :)
<wgrant> Tonio_: Ah, that would help.
<Tonio_> hehe
<pitti> tseliot: can bug 251107 be considered as the "reference" bug for "71 and 96 don't work in intrepid"?
<ubottu> Launchpad bug 251107 in nvidia-graphics-drivers-96 "[Intrepid] nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex" [Medium,Confirmed] https://launchpad.net/bugs/251107
<tseliot> pitti: yes, that's the one
<mdz> sbeattie: regression_tracker.html is very slow to render in Firefox for some reason; do you know why?
<mdz> asac: my firefox keeps resizing so that the window title bar and status bar are behind the panels. have you ever seen that happen?
<asac> mdz: i have never seen that on my own. i think two days ago someone complained about that though.
<asac> mdz: maybe related to compiz?
<mdz> asac: certainly possible.  I'm not sure how to debug it though
<asac> mdz: are you using firefox in "maximized" window state?
<mdz> asac: yes
<mdz> asac: of course, I have several other windows maximized (including this one) which behave normally
<mdz> so something is different about firefox
<mdz> what's better? istanbul or gtk-recordmydesktop?
<asac> mdz: ok. but firefox always is that way when maximized? or only sometimes?
<mdz> asac: it starts out correct, but then (usually when switching desktops/focus) it suddenly goes behind the panels
<mdz> asac: I'll capture a video and file a bug on compiz
<asac> mdz: please subscribe me to that bug so i get the mails
<mdz> asac: bug 240736 matches my symptoms
<ubottu> Launchpad bug 240736 in compiz "Firefox can't be unmaximized/resized after un-docking" [Undecided,New] https://launchpad.net/bugs/240736
<mdz> except I don't have a docking station
<mdz> I did connect an external VGA on Tuesday, though I don't remember if that's when this started happening or not
<asac> mdz: hmm. thats a hardy report even
<kwwii> seb128: I was asked to clean out the unecessary/ugly themes from the gnome-themes package. Thought I should ask you first how best to do it
<asac> hmm. cant reproduce on hardy with compiz :/
<seb128> kwwii: do we real need to do this? that's one of those things which breaks upgrade for people using those themes
<seb128> kwwii: the best way is to create a new binary containing those themes, I can do that if you open a bug listing the themes to drop, but that will break upgrades
<mdz> asac: see my comment
<mdz> asac: I think it's related to xrandr somehow
 * asac looking
<seb128> kwwii: btw since you are on IRC, could you change the folder-copy and folder-move icons in human-icon-theme to stock_folder-copy and stock_folder-move which are the name evolution is using since hardy (that makes some icons look ugly)?
<seb128> kwwii: and did you read the gnome-session bugs? we need icons for the actions there
<asac> mdz: is the window really in "maximized" state when you switch back or just maximized, but in normal state (where you can resize it)
<mdz> asac: I restarted compiz and can't reproduce, I'm going to try to find a recipe to get it back into the bad state
<kwwii> seb128: sabdfl asked me to remove the extra gnome themes, I'll mention the upgrade issue and see what he says
<seb128> we already had this discussion before dapper
<kwwii> seb128: should I move the icons to those names or just make a symlink to those names?
<seb128> as you want, would just be nice to have the stock_ variants available
<mdz> asac: I can't get it to happen anymore :-/
<seb128> kwwii: renaming should be already, gnome-icon-theme use the stock_ naming
<mdz> asac: when I switched back to it, it would be in a strange state.  if I would press F11 twice (as in the bug) it would get it back in the right place, but the window would not be focused
<seb128> lunch time, bbl
<mdz> asac: and clicking on the title bar would not focus it
<kwwii> seb128: ok, I can take care of that
<seb128> thanks
<kwwii> and I will look into the session bug later today as well
<ogra> mdz, in case you want to try something on your Q1 http://www.umpcportal.com/2008/09/ubuntu-mobile-edition-news-and-first-boot-video/ :)
<mdz> ogra: I don't have one anymore
<ogra> oh
<ogra> thats sad ...
<amitk> soren: seen any bugs about kvm not giving back the mouse lately?
<cjwatson> ogra: looks like an excellent review
<ogra> yeah
<ogra> i'm drowning in feedback mail :)
<mdz> asac: I have got it in the broken state again, can I collect some info for you?
<asac> yes. copy localstore.rdf from your profile
<asac> mdz: then check whether the window is really in a "maximized" state or if its just maximized, but in resizable state
<mdz> asac: I don't know how to tell whether it's truly maximized, because there's no window border
<asac> mdz: let me check something
<mdz> asac: alt+f10 does nothing
<asac> mdz: alt+f8?
<mdz> asac: nothing
<asac> also try alt + space  and see if the "resize" is greyed out
<asac> hmm
<mdz> asac: alt+f9 minimizes
<mdz> but restoring it puts it back in the same place
<mdz> asac: alt+space shows 'unmaximize' option
<mdz> but "resize" is not grayed out
<asac> mdz: urgh
<asac> mdz: so the window is somewhere in the limbo between being "normal" and "maximized" ... strange
<asac> localstore.rdf might have some info on what firefox thinks the window is
<mdz> asac: emailed
<soren> amitk: Doesn't ring a bell, no.
<soren> amitk: SDL frontend?
<soren> amitk: And when did it start?
<asac> mdz: in localstore.rdf the window is correctly in "maximized" state
<asac> mdz: howver it still has the dimensions ... which most likely are the dimensions remembered for "normal" mode
<mdz> asac: I can't figure out how to get it into this state, though I have succeeded once
<asac> mdz: question is why its in a hybrid state for the window manager
<mdz> asac: resize is not greyed out for me even when it is in a correctly maximised state
<asac> mdz: yeah. my bet is that ffox sets "maximized" and then sets dimensions and compiz gets confused and puts the window in this confusing state
<asac> mvo: ^^
<asac> mvo: window in compize in "maximized" state still has "resize" enabled in window menu
<asac> mvo: but also has the "unmaximize" option
<asac> mvo: any idea what might confuse compiz here?
<Peaker> hey, what process is required for some python libraries to go into Ubuntu?
<kwwii> seb128: that session icon problem is not an icon problem but a code problem (there are two open bugs about it)
<kwwii> seb128: the apps/gnome-session-* icons exist (although I found a bug in the spelling of the hibernate icon in the human theme)
<seb128> kwwii: not really
<kwwii> the arrow which is too small is the actions/refresh* icon
<seb128> kwwii: looks like we don't want to use the previous non standard naming square icons
<seb128> kwwii: icons used now
<seb128> #define GSM_ICON_LOGOUT    "system-log-out"
<seb128> #define GSM_ICON_SWITCH    "system-users"
<seb128> #define GSM_ICON_SHUTDOWN  "system-shutdown"
<seb128> #define GSM_ICON_REBOOT    "view-refresh"
<seb128> #define GSM_ICON_HIBERNATE "drive-harddisk"
<seb128> #define GSM_ICON_SLEEP     "sleep"
<seb128> kwwii: it would be nice to keep those standard names and do symlinks in the icon theme if required
<amitk> soren: since Monday I think. I use it through the Virtual Machine Manager UI running an XP in KVM.
<kwwii> seb128: yeah, I can make links to the right names...I just did not want to start trying to redraw icons in larger sizes :-)
<seb128> kwwii: because gnome-session-* are ubuntu specific naming and that would break other icon theme (the dialog work correctly using clearlooks now)
<amitk> soren: and I have kvm-source installed
<soren> amitk: Is it possible that it started happening a couple of weeks ago?
<soren> amitk: There was a new gtk-vnc upload on the 11th.
<kwwii> seb128: cool, I will add the links in the human icon theme package, along with the other stuff you mentioned and a couple of things I just noticed
<cjwatson> bryce: apparently http://people.ubuntu.com/~bryce/Milestones/milestones_current.html hasn't been updated for ages - there's a bug listed there that was closed on 27 August
<seb128> kwwii: not sure if the old dialog icons will look great in the new dialogs though, the squares for shutdown for example was good in the grid dialog but might not be as good in the new one, I'll let you decide about that though
<seb128> kwwii: thanks
<amitk> soren: it is possible, I was away in Portland last week.
<seb128> kwwii: oh and sorry about the lack of reply on sponsoring, I've been crawling under a montains of GNOME 2.24 update this week and when I wanted to ping you were not on IRC
<amitk> soren: so it was part of a huge set of updates
<kwwii> seb128: no worries, I found other victims :-)
<seb128> TheMuso: are you around to speak about sound themes?
<TheMuso> seb128: Certainly am.
<seb128> TheMuso: I was wondering if somebody is working on the freedesktop-sound-theme
<TheMuso> seb128: In what way exactly? Because it wasn't packaged, I have put it into the ubuntu-sounds package for now. We can split it out in Jaunty.
<seb128> oh, that's why it conflicts
<seb128> I've it packaged locally using the debian packaging
<seb128> and ubuntu-sounds conflict on /usr/share/sounds/freedesktop/index.theme
<TheMuso> Oh there is debian packaging? I didn't find it when I originally tried looking for it.
<seb128> TheMuso: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486559
<ubottu> Debian bug 486559 in wnpp "ITP: freedesktop-sound-theme -- default fallback theme for freedesktop.org sound themes" [Wishlist,Open]
<seb128> TheMuso: http://git.debian.org/?p=collab-maint/freedesktop-sound-theme.git;a=summary
<TheMuso> Oh ok. If you want to bring that into Ubuntu, I can remove it from the ubuntu-sounds package if thats any help.
<seb128> I didn't upload because I've been busy and the tarball doesn't ship the licenses which are used which I think will be an issue to get it through NEW
<TheMuso> Right.
 * TheMuso hecks the upstrea tarball again.
<seb128> TheMuso: well, I've to admit I've been too busy to continue on that, if somebody wants to take over the task that would be welcome
<seb128> I think it would be nice to have in intrepid
<seb128> and I'm not sure adding to ubuntu-sounds is really a thing to do
<seb128> did you update the copyright to reflect all that, does it have all the required licenses, etc?
<TheMuso> seb128: Nor do I really, but I couldn't think of something better at the time.
<seb128> I would much prefer having the freedesktop and ubuntu sound themes as different binaries
<TheMuso> This is what I am about to go and chase up.
<TheMuso> so would I.
<TheMuso> There is a README file in the freedesktop tarball that outlines the origins of the sounds and their licenses, but it doesn't appear there is much more than that.
<seb128> right
<seb128> TheMuso: do you think you could have a look at getting that upload? or are you too busy right now?
<seb128> now not being today but before intrepid
<TheMuso> seb128: Yes I could have a look at getting that uploaded, just got to track down copyright/licensing, which may not be easy.
<seb128> I think the copyright are ok, as you said they are listed in the readme
<seb128> the issue is probably having the corresponding licenses in the tarball
<seb128> maybe we should ping lennart about that
<TheMuso> Yeah.
<TheMuso> I'll jump on the ml for it and ask.
<seb128> thanks
<seb128> another quick question, are you going to update pulseaudio in intrepid? any reason to not do it? you seem to be backporting patches rather
<TheMuso> seb128: Too many users with playback/stream switching issues with 0.9.11/0.9.12. For one, a USB sound card I have completely crashes pulseaudio with newer versions, and another user had issues trying to switch a stream between onboard audio and US speakers. There needs a fair bit of stuff fixed in pulse, as well as alsa for these.
<seb128> alright
<PecisDarbs> hi people, Intrepid won't have Vinagre 2.24, will it? as I understand, it was released too late. Sad.
<cjwatson> PecisDarbs:    vinagre | 2.24.0-0ubuntu1 |      intrepid | source, amd64, i386
<cjwatson> i.e. it's already there
<PecisDarbs> hmmmmm
<PecisDarbs> ok, I updated this morning, maybe it rolled during day
<seb128> no, it has been rolled on monday
<Burgundavia> PecisDarbs: gnome has a standing upstream freeze exception
<seb128> try changing mirror
<PecisDarbs> ok
<PecisDarbs> thanks for info
<Burgundavia> likely it was just that poor seb128 was overworked getting all of .24 in on time
<cjwatson> Burgundavia: or read what seb128 wrote ;-)
<Burgundavia> cjwatson: is 6am for me, am allowed to be slow
<jcastro> evand: has anyone shown interest in backporting usb-creator to hardy? Might be a good way to expand the testing audience.
<seb128> jcastro: at this stage intrepid already has quite an audience, usually enough to keep us busy
<seb128> jcastro: I'm speaking for desktop at least, not sure about your specific case ;-)
<jcastro> seb128: I was just referring to his call for testing, people in the forums were asking if they can test on hardy as well
<evand> jcastro: there was a bug filed about a requirement for it and it's something that's been requested more than once.
<jcastro> ah, okey
<evand> I'll try to find time for a backport of it, though I'm very much focused on bug fixing at the moment.
<jcastro> evand: I was hoping to get contribution from someone in the group of people asking.
<evand> ah
<evocallaghan> Maybe this place will not be full of n00bs
<evocallaghan> Hi lads
<evocallaghan> What is the LiveCD compressed with ? bzip, gunzip, LZMA ?
<ldp> umm
<pitti> evocallaghan: gzip
<evocallaghan> Someone said to me squashfs
<cjwatson> evocallaghan: squashfs uses zlib, which is what gzip is based on
<evocallaghan> ok
<evocallaghan> Thank you
<cjwatson> there is an lzma variant of squashfs, but we don't use that at present (it has even less chance of making it upstream at the moment ...)
<ogra> pitti, is there a way to tell hal to re-read a device deliberately ?
<pitti> ogra: re-read? you mean re-probe the hardware?
<ogra> i have fixed up the touchscreen calibration tool in evtouch ... works fine but you have to restart your session to make xorg accept the change
<evocallaghan> LZMA has a bit more overhead
<pitti> ogra: haven't tried, but maybe udevadm trigger [some mixture of --subsystem-match and --attr-match]
<ogra> so i wonder if there is a way to make that apply on the fly
<evocallaghan> I have a working version here
<pitti> ogra: well, at worst you could restart hal
<ogra> nope
<cjwatson> yes, we use it in certain limited contexts (limited exactly because the memory overhead for decompression is high)
<ogra> ignored by xorg
<pitti> ogra: if restarting hal doesn't help to update the xorg evdev driver, then udevadm trigger won't either
<cjwatson> I'd be pretty concerned about the memory overhead for the whole live CD; we only just got the requirements back down inside 256MB, and there's not a whole lot of headroom there
<ogra> pitti, evtouch :)
<ogra> not dev
<cjwatson> requirements for installation from live CD, that is
<evocallaghan> Gezz, this place is far more sane then #ubuntu O_o
<evocallaghan> Well I am building my own Live opensolaris CD
<StevenK> cjwatson: It's back down from the 300 odd it was for Hardy?
<ldp> evocallaghan: does that surprise you?
<evocallaghan> Just wondering what you guys where using
<evocallaghan> ldp:No idea, I don't hang around these parts of the _inter_web :p
<ldp> :D
<cjwatson> StevenK: yeah, due to compcache
<StevenK> \o/
<Lazy> Hi, I don't know if this is the right channel but this bug report seems important to me and nobody has commented it. https://bugs.launchpad.net/ubuntu/+source/tor/+bug/261693
<ubottu> Launchpad bug 261693 in tor "version bump to 0.2.X" [Undecided,New]
<jdong> Lazy: well we are well past feature freeze and bordering into beta freeze; is there an extremely important reason why this version is needed over the current shipping version? (i.e. is tor going to stop working for the older client?)
<jdong> Lazy: i have to leave pretty soon, but if this is the case then state so on the bug report
<apachelogger> pitti: I guess explaining it would be a good improvement already.
<ldp> brb people Badminton practice time
<Lazy> I'm not sure if it will break but Debian has already included it and it contains several fixes to security
<cjwatson> the bug says "major feature enhancements", which is normally a reason for the package *not* to be included after feature freeze
<cjwatson> therefore, somebody needs to be more explicit in the bug about the exact nature and importance of the bug fixes
<Lazy> cjwatson: Thanks for the clarification. When I get home from work I will write about the bug fixes and new features to the bug report so you guys can decide wether to include the new version or not.
<evand> pitti: doko: If you have a free moment, could you please look at MIR bug 268137
<ubottu> Launchpad bug 268137 in usb-creator "main inclusion report for usb-creator" [Undecided,New] https://launchpad.net/bugs/268137
<kirkland> \sh: hey, saw your blog post, if you add your question to the bottom of https://wiki.ubuntu.com/EncryptedPrivateDirectory, i'll answer it inline there
<ykphuah> asac: you there?
<MacSlow> kwwii, just wondering ... wasn't initially the white color in NewHuman (used for list-views, icon-views & co) meant to be a bit more greyish?
<kwwii> MacSlow: yes, it was
<kwwii> but that made default office documents in OOo the same color
<liw> kwwii, I've been thinking lately that it would be handy if the dark theme could make the focused window a bit more prominent (and perhaps the current tab in an unfocused gnome-terminal window less prominent)
<ykphuah1> asac: you there
<asac> ykphuah1: whats up?
<ykphuah1> asac: about the patch for NetworkManager
<asac> ykphuah1: which?
<ogra> Riddell, whats the KDE equivalent of xdialog/zenity ?
<ykphuah1> asac: bug 191889
<ubottu> Launchpad bug 191889 in pidgin "[MASTER] [WORKAROUND] "Offline Mode" feature fails to detect proper online state for networks that are managed outside of network manager." [Undecided,Confirmed] https://launchpad.net/bugs/191889
<Riddell> ogra: you'd never guess it, kdialog!
<ogra> hum
<ogra> that doesnt have its own package it seems
<ogra> i want to make the touchscreen calibration work on KDE as well ...
<ogra> so i need to know the Recommands line
<Riddell> it's part of kdebase-bin
<ogra> ah
<asac> ykphuah1: ah. yeah. thanks for working on that
<ogra> sigh
<ogra> that gets me 80M
<asac> ykphuah: you think you can make a patch that looks for IP being set on unmanaged devices?
<radix> mathiaz: Hi, so I made some changes to landscape-config, but it still returns non-0 exit codes
<radix> mathiaz: because that makes the most sense for other reasons. are you still happy to add a "|| true" to the command?
<mathiaz> radix: how is the "unable to register because d-bus isn't running" scenario handled now ?
<radix> mathiaz: a nice message is printed and exit code 2 is returned
<radix> instead of a giant traceback
<radix> (it still maintains the behavior to record the registration details and will register when the client starts)
<james_w> is "#!/bin/sh -e" equivalent to "#!/bin/sh\nset -e" ?
<mathiaz> radix: could it be possible to add an option --ok-no-registration so that it returns 0 if the registration isn't successful ?
<radix> mathiaz: hmm, thinking
<radix> mathiaz: I guess a "--no-register" option is no good because you can't tell whether you're running from the installer or from a regular environment?
<mathiaz> radix: right
<radix> mathiaz: I can definitely add an --ok-no-register
<mathiaz> radix: look at the oknodo option from start-stop-daemon
<radix> ok cool
<mathiaz> radix: that option as the same purpose for starting daemons in init script
<sbeattie> mdz_: I'm unable to reproduce the slow rendering here (3.0.1,hardy) but it's quite likely I'm doing something bogus. I'll poke at it a bit.
<mdz_> sbeattie: this is on current intrepid
<kwwii> liw: yeah, they might get darker or lighter...or more transparent
<superm1> pitti, "not" shipping the handler doesn't have to be the solution right now.  jockey doesn't depend on the modaliases yet, so simply leaving it like that would prevent it from being offered via jockey
<pitti> superm1: right that
<radix> mathiaz: Ok, I implemented --ok-no-register with unit tests, going to do some more manual testing
<mathiaz> radix: awesome ! Thanks for working on this :)
<mathiaz> radix: are you going to roll a new release ?
 * evocallaghan steps back out to his solaris box.
<evocallaghan> Thanks all.
<radix> mathiaz: probably, but it's getting tricky
<radix> mathiaz: I may have to call it 1.0.21.1 or something
<radix> since our trunk has diverged to get some new features
<mathiaz> radix: if that's too complicated we can just release a new ubuntu revision of the package.
<radix> mathiaz: well, actually, I could just give you a branch with version number changed to 1.0.21.1
<radix> mathiaz: the main thing is we want to be able to know what version users are using... we track version numbers in the server
<radix> the client uploads its version number, and it'd suck to have two different codebases sending the same version number
<mathiaz> radix: ok - then 1.0.21.1 is the way to go
<radix> mathiaz: ok, I'll have this branch ready for you as soon as we do a bit oftesting - I need to get into a dbus-less environment
<mathiaz> radix: great
<pitti> cjwatson: do you know any reason (installer-wise) why the first user should be put into group "fuse"? (I just locally fixed fuse to use our usual "current foreground console" policy for /dev/fuse)
<pitti> cjwatson: if not, I'd like to just throw that out again
<cjwatson> there's nothing in the installer itself that needs it
<pitti> cjwatson: right, I mean I almost fell into some trap with removing cdrom/plugdev
<cjwatson> feel free to change it in lp:~ubuntu-core-dev/user-setup/ubuntu
<pitti> cjwatson: with the fstab issue for cdroms
<pitti> cjwatson: ok, thank you
<cjwatson> right, that one is hard
<mathiaz> radix: another option to track versions is to integrate the ubuntu revision number in the number reported by landscape-client.
<cjwatson> ntfs-3g is the only thing in the installer that needs fuse, and in an installer context it's run as root
<pitti> cjwatson: I'm not going to stab cdrom again for intrepid, but this "fuse" thing annoys me
<cjwatson> so I think it'll be OK
<pitti> \o/
<mathiaz> radix: on way to do that is to provide it at build time.
<pitti> âª another one bites the dust â«
<pitti> cjwatson: we cannot really rely on the user being in that group, but we need to to resolve the mess of libgphoto camera handling in gnome
<StevenK> cjwatson: Can you commit and push your changes of livecd-rootfs to the bzr tree?
<StevenK> ogra: You too, after cjwatson.
<ogra> didnt i push ? oh, sorry
<StevenK> Wait, it could be me being idiotic
<StevenK> bzr update is a no-op for non-bound branches
<ogra> i think i pushed
<cjwatson> I use a bound branch for livecd-rootfs, so it's always current
<ogra> i remember messing up the tags
<StevenK> bzr: ERROR: Tags not supported by BzrBranch5
<StevenK> Whee
<cjwatson> ogra: so should r207 have tag 0.69 rather than r206?
<ogra> i usually dont set DEBEMAIL to force me to look at the changelog before doing dpkg-buildpackage ... so yes, 206 has the right address in the changelog
<ogra> errr 207
<jdong> StevenK: oh quit whining about that error. It used to be far less intuitive :D
<StevenK> jdong: :-P
<StevenK> Then bzr was complaining that it couldn't add tags and died.
<StevenK> bzr upgrade followed by bzr pull was insisting the tree was up-to-date.
<cjwatson> ogra: I've moved the tag
<ogra> gracias
<ogra> i couldnt anymore after i had pushed i found
<StevenK> cjwatson: How did you move it?
<ogra> locally i bet :)
<cjwatson> bzr tag -r207 --force 0.69
<ogra> oh
<ogra> meh
<ogra> *that easy*
<StevenK> I don't get that change here, though
<ogra> well, you have a tag anyway
<ogra> it just moved places
<StevenK> After bzr pull was insisting wrong things, I took a leaf from cjwatson's book and bound it
<cjwatson> $ bzr tags -d sftp://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk
<cjwatson> 0.68                 204
<cjwatson> 0.69                 207
<cjwatson> (or bzr+ssh://)
<StevenK> bzr update isn't updating that metadata, though
<cjwatson> you have two choices: (1) it sounds like a bug, and #bzr might be able to help (2) move your branch aside for future analysis and check it out from scratch
<StevenK> Heh, yay. bzr update does nothing, but bzr pull says there are conflicting tags
<cjwatson> if you've mucked about with it locally but not pushed, well, you're now diverged; I don't know if merging helps
<cjwatson> oh
<cjwatson> bzr pull --overwrite (assuming no local changes)
<cjwatson> the bzr 0.91rc1 NEWS file says:
<cjwatson>    * Overwrite conflicting tags by ``push`` and ``pull`` if the
<cjwatson>      ``--overwrite`` option is specified.  (LukÃ¡Å¡ LalinskÃ½, #93947)
<StevenK> There are local changes, but it's one line
<cjwatson> but if you're now bound, 'bzr unbind' first
<cjwatson> then bind again after pulling
<pitti> seb128: unfuse-ification complete \o/
<seb128> pitti: ;-)
<ogra> pitti, erm, were these changes tested in environments without polkit and friends (i.e. ltspfs) ?
<ogra> there are no fgconsoles for ltsp users ...
<pitti> ogra: the fuse group still exists
<pitti> ogra: if you are in it, you don't need pk
<ogra> ok
<pitti> ogra: ah, so you need the installer to put users into fuse?
<pitti> s/users/the first user/
<ogra> well, users admin
<ogra> but that has a patch unless that was dropped
<pitti> ogra: if so, I need to revert the installer bit (I woudln't like it, but so be it)
<pitti> ogra: I didn't touch users-admin
<ogra> right, then its fine ... i can just tell the admin to check the box
<pitti> ogra: what I did is (1) create the auto-acl magic for /dev/fuse (it's still root:fuse 660) and (2) change user-setup to not put the initial user into 'fuse'
<ogra> err, no i cant since polkit doesnt allow access to users-admin for ltsp users ... hmmm
<pitti> ogra: I don't think we can actually get rid of the system group anytime soon, just not put the first user into it/rely on users being in fuse
<ogra> does that work for ntfs from initramfs ? afaik there is no ACL applied yet
<ogra> (yet as in at that point of booting)
<pitti> ogra: the ACL just applies to /dev/
<ogra> even in intramfs ?
<pitti> the ACL is set by hal once an user starts a session
<ogra> (i thounght it requires hal)
<pitti> that's way after initramfs
<pitti> ogra: unless you actually keep your runtime /dev/ on ntfs all the time?
<ogra> but ntfs3g as cjwatson implemented it fires in initrmfs iirc
<pitti> *confused*
<pitti> ogra: what does ntfs3g have to do with it?
<ogra> it uses fuse
<pitti> users being in the "fuse" group -> not at all related to things happening in initramfs?
<ogra> not sure why or what for, but that was the reason why fuse got pulled into initramfs
<pitti> yeah, that's fine
<pitti> if your / lives on ntfs, for example
<pitti> but that all happens as root
<ogra> cjwatson might be able to comment, he made that change iirc
<ogra> ah, right
<Keybuk> cjwatson: so, err, I just booted the current daily-live
<Keybuk> http://people.ubuntu.com/~scott/retro-live-cd.png
<ogra> should that also show cu and ram usage ?  :)
<ogra> *cpu
<ogra> *shouldnt
<Keybuk> ogra: I was thinking it should show a big ubuntu logo, and look a bit more like gdm :p
<ogra> well ... you cant have everything ...
<ogra> :)
<Keybuk> there's no Xorg.log, so it doesn't look like it even started
<ogra> gdm works on tuesdays build of ubuntu-mobile
<ogra> might be X's fault then
<tjaalton> can't be if there's no log
<ogra> weird
<jcristau> it's never X's fault anyway
<ogra> lol
<ogra> right :)
<Hew> Keybuk: Why was bug 189406 changed to wishlist? It is not a cosmetic request, but a regression of a key feature.
<ubottu> Launchpad bug 189406 in update-manager "Update Manager doesn't display package versions anymore" [Wishlist,Triaged] https://launchpad.net/bugs/189406
<ogra> Keybuk, tried startx ?
<mvo> Hew: but the version information is certainly still available in the changelog, no?
<Hew> mvo: No, it's not. Often (especially in development), the changelog is not available. Also, the current version is not shown. It is very useful to have "version x to version y" displayed for each item. Currently I have to do with with synaptic, so I haven't used update-manager in ages.
<mvo> Hew: would you be ok with a gconf key to enable it?
<Hew> mvo: I would, as I mentioned in a comment a while ago, but I still think it should be enabled by default.
<mvo> Hew: ok, thanks. I will bring it up with our usability person again
<Hew> mvo: Thank you. I feel it's important to get this fixed before Intrepid release.
<tedg> Keybuk: See, I told you the FUSA applet got moved in more recent live CDs ;)
<cjwatson> Keybuk: yeah, we decided that X is for losers
<cjwatson> (I'll have a look once I've rsynced to current)
<geser> is the beta freeze already in effect?
<mathiaz> geser: yes
<seb128> mathiaz: since when?
<mathiaz> seb128: according to the ReleaseSchedule, it's at 00:00 UTC on the day.
<mathiaz> seb128: but may be slangasek hasn't pushed the button yet.
<seb128> mathiaz: he hasn't ;-)
<cjwatson> https://launchpad.net/ubuntu/intrepid -> "Status: Active Development"
<cjwatson> when that's changed, it will say "Pre-Release Freeze"
<pitti> tkamppeter: please commit the changes of your cups upload to bzr
<NCommander> \o/ - my HPPA intrepid install works
<ogra> heh hppa
<NCommander> Yes, yes I know
<NCommander> I had to ask HP for access to a developers box
<NCommander> But now I have root on an Ubuntu intrepid hppa install
<NCommander> that's wrong in many ways :-/
<tkamppeter> pitti, sorry, forgot the "bzr push"
<pitti> tkamppeter: FYI, I just fixed the progress dialog and d-bus timeout if you do a d-bus call
<pitti> tkamppeter: (in jockey)
<pitti> I guess you stumbled upon that (there was no progress dialog, etc.)
<slangasek> cjwatson: it looks like I still don't have access to the button to start the freeze in LP; could you do that now?
<tkamppeter> pitti, "bzr push --remember bzr+ssh://till-guest@bzr.debian.org/bzr/pkg-cups/cups/debian-trunk" does not work for me.
<tkamppeter> I get
<tkamppeter> Format <RepositoryFormatKnit3> for file:///home/till/ubuntu/cups/bzr/debian-trunk/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<pitti> tkamppeter: that's just a warning, I get it, too
<tkamppeter> and then it hangs infinitely.
<tkamppeter> Now I got a
<tkamppeter> ssh: connect to host bzr.debian.org port 22: Connection timed out
<tkamppeter> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<pitti> tkamppeter: does "ssh till-guest@bzr.debian.org" work for you?
<pitti> (apparently that's the problem)
<pitti> (WFM)
<tkamppeter> ssh till-guest@bzr.debian.org
<tkamppeter> and nothing happens, probably until the timeout.
<cjwatson> slangasek: let me see if I have it ...
<pitti> tkamppeter: try with -vv
<pitti> slangasek: I always asked in #is
<cjwatson> slangasek: nope, I don't seem to have it. You need an LP admin (#launchpad or #is)
<slangasek> ah
<tkamppeter> OpenSSH_5.1p1 Debian-1ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
<tkamppeter> debug1: Reading configuration data /etc/ssh/ssh_config
<tkamppeter> debug1: Applying options for *
<tkamppeter> debug2: ssh_connect: needpriv 0
<tkamppeter> debug1: Connecting to bzr.debian.org [217.196.43.134] port 22.
<tkamppeter> and then nothing.
<pitti> tkamppeter: ah, please don't quote the entire output, pastebin
<pitti> tkamppeter: it works for me; problem with your ISP?
<tkamppeter> Can it be that the SSH daemon on bzr.debian.org has crashed?
<cjwatson> tkamppeter: no, since it works for others (including me).
* slangasek changed the topic of #ubuntu-devel to: archive: beta freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/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> here we go :)
<ogra> oh
<ogra> that wasnt in effect yet ?
<mvo> weeeh
 * ogra thought it was since 00:00 UTC
<cjwatson> you should know that advertised times != actual times :)
<ogra> as usual
<ogra> i just thought i make my generic freeze comment :P
<slangasek> :-)
<ogra> herdware enablement has a rolling exception, right ? i'm expecting a bunch of fdi files for touchscreen devices after the success of ubuntu-mobile that i'd like to add to the touchscreen driver
<tkamppeter> pitti, I can ssh to OpenPrinting
<tkamppeter> I can ping bzr.debian.org
<pitti> tkamppeter: can you ssh from openprinting to bzr.d.o?
 * ogra reboots after dist upgrade
<tkamppeter> When I traceroute it, the traceroute ends at trent.core.telegraaf.net (217.196.40.15) and no at 217.196.43.134. But it exits with status 0.
<tkamppeter> Doing ssh from OpenPrinting ssh gets much further, it hangs after saying "debug2: we sent a publickey packet, wait for reply", probably because I do not have my private key on OP.
<tedg> slangasek: So... I just got told that GIMP is expecting to release 2.6.0 on Monday.
<ion_> tedg: Was it the one with GEGL support?
<tedg> ion_: I believe so.
<pitti> tkamppeter: ssh foo2bzr.d.o asks me for a password, though
<ion_> AwesomeÂ²
<tedg> slangasek: Considering we don't have any of the 2.5.x snapshots in Intrepid -- what's the chance of a miracle?
<tedg> :)
<tkamppeter> pitti, did a second try on OpenPrinting and now I got to the password prompt. After entering my password I arrived on Alioth.
<bdmurray> tkamppeter: we now have cupsys and cups packages receiving bugs in Launchpad.  Is there a need to consolidate these?
<tkamppeter> bdmurray, I think so. Many users did not perceive that cupsys was renamed to cups and continue reporting on cupsys.
<slangasek> tedg: I'm sure there's a good epistemological answer to that question, somewhere; but as for gimp 2.6 being accepted for intrepid, there'd probably need to be a pretty compelling reason
<tkamppeter> It would be a great Launchpad feature to auto-redirect such reports.
<pitti> tkamppeter: well, it's still "cupsys" in all stable releases
<ogra> yay, my login sound is back
<tedg> slangasek: I think the compelling reason would be that every reporter reviewing the release would fixate on it if we didn't have it :-/
<tedg> slangasek: Especially if Fedora does.
<geser> slangasek: has the beta freeze any effect on packages in universe? like needed exceptions
<bdmurray> pitti: I can see it being confusing to have 2 places for bugs though
<pitti> right, it is
<tkamppeter> pitti, bzr.debian.org returned to work I have uploaded the bzr now.
<pitti> tkamppeter: nice, thanks
<slangasek> tedg: ah, yes, because those reporters are always disappointed when they can't use the newest gimp features to write their articles, are they :)
<slangasek> anyway, it's not like they won't find something else even more trivial to fixate on, that we've overlooke :)
<slangasek> geser: nope, see u-d-a
<tedg> slangasek: No, more because they're looking for _something_ to say that Fedora is better at ;)
<slangasek> heh
<tkamppeter> pitti, you told that you "just fixed the progress dialog and d-bus timeout if you do a d-bus call". Did you upload it to somewhere?
<pitti> tkamppeter: not yet
<slangasek> +test -f /usr/share/acpi-support/state-funcs || exit 0
<slangasek> bryce: that's an interesting addition, considering that file is shipped in the very same package :)
<bryce> slangasek: it seems that xubuntu replaces the acpi system, but many of these scripts stay in place for some reason
<bryce> slangasek: so debian added those checks so the scripts don't trigger if acpi-support has been replaced
<slangasek> bryce: ... um.
<slangasek> well, I guess these are all conffiles, so they're still present when the package is removde
<slangasek> so remove acpi-support + leave acpid installed --> failing scripts <shrug>
<bryce> yeah
<bryce> it comprised the most #lines in the diff between us and debian, so since it was a trivial change, I figured it was a harmless change that'd at least minimize the size of the diff between us and them
<bryce> plus if it helps xubuntu, why not
<bryce> although I'd guess by now they must have gotten some other way to work around it
<ogra> slangasek, please let xf86-input-evtouch through ...
<ogra> (universe)
<didrocks> norsetto: I really think that vuntz can really be a great help on the update page :-)
<superm1> why does xubuntu not use acpi-support in the first place though?
<superm1> bryce, and looking at the rdepends, acpi-support is still part of xubuntu-desktop in the first place?
<slangasek> I think the rationale given there is a bit mangled, really
<slangasek> the real issue is that you can remove acpi-support and it will leave behind the conffiles, which should play as nicely as possible
 * bryce nods
<pitti> slangasek: I fixed the spawning of the "searching driver" progress dialog in jockey, and updated translations; is that still ok for beta, or do you just accept beta-milestoned fixes now?
<slangasek> pitti: I'll take that one, at least today
<bryce> sorry I misrembered it as "xubuntu", it was for eeepc-acpi-scripts
<bryce> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469556
<ubottu> Debian bug 469556 in acpi-support "all scripts in /etc/acpi should do nothing when the package is removed" [Normal,Closed]
 * ogra goes out for dinner
<superm1> they couldn't just adapt the existing acpi-scripts for eee support?  yick..
<slangasek> that's a bit dodgy, yes :)
<pitti> slangasek: ok, uploaded; shall I ack it myself, or do you want to review it?
<slangasek> if it's not urgent, I can review it later today
<pitti> ok, thanks
<slangasek> pitti: are you able to confirm the comment in bug #274085 that ekiga is part of gnome (i.e., standing exception)?
<ubottu> Launchpad bug 274085 in ekiga "Please update Ekiga to 3.00" [Wishlist,Triaged] https://launchpad.net/bugs/274085
<tedg> slangasek: I don't believe that Ekiga is part of GNOME.
<slangasek> tedg: hmm, it's featured prominently at http://library.gnome.org/misc/release-notes/2.24/#rnusers.ekiga
<tedg> And it's in GNOME SVN...
<Treenaks> but its version is a bit off
<tedg> It's not on this list: http://www.gnome.org/projects/
 * NCommander pokes landscape with a stick
<tedg> But, well, Sodipodi is :)
<slangasek> tedg: right, and so is xmms... :)
<slangasek> actually, GNOME meeting is listed there too :)
<pochu> tedg: it's in the desktop set: ftp://ftp.gnome.org/pub/gnome/desktop/2.24/2.24.0/sources/
<Treenaks> that _is_ a limited set..
<pochu> but it's part of GNOME
<pochu> and ekiga is part of the Desktop set
<pochu> so ekiga is part of GNOME ;-)
<slangasek> right, so I guess the only real question is whether the desktop team is going to take responsibility for updating it for beta :)
<Treenaks> slangasek: all we need is a milestoned bug ;)
<Treenaks> Should I report it as a bug that the ati driver has probed my display 1168 times in 1 session?
<Treenaks> and continues to do so, every few minutes?
<norsetto> didrocks: well, what I need now is somebody that can design a decent html page ;-)
<pitti> re
<terminator_> tseliot  When will the 96.43.07 drivers for nvidia cards be ready
<pitti> slangasek: hm, so far I didn't think it was
<pitti> slangasek: hm, http://ftp.acc.umu.se/pub/gnome/sources/ekiga/3.0/, interesting
<tseliot> terminator_: I wish I knew it...
<pitti> slangasek: but ok, its presence in ftp://ftp.gnome.org/pub/gnome/desktop/2.24/2.24.0/sources/ convinces me
<terminator_> tseliot I can't wait to try them out with my old machine.
<pitti> slangasek: I just find it worrying that we didn't get 3.0 alpha/beta releases, as with all the other gnome components (that worries me more than being/not being part of official gnome)
<elmo> O  [  26: Damien Sandras      ] Ekiga branched for GNOME 2.24
<pochu> pitti: and whether they will release point updates with the rest of GNOME ;)
<elmo> from desktop-devel-list@gnome.org, cc'ed release-team@gnome.org, for whatever that's worth
<terminator_> tseliot thanks
<tkamppeter> pitti, I have added a patch for python-cupshelpers to 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
<alex-weej> i accidentally the Guest user
<alex-weej> is that bad?
<alex-weej> *deleted* :P
<alex-weej> did it via the users-admin
<pitti> alex-weej: it will be recreated automatically
<alex-weej> i actually thought i had created it myself
<alex-weej> because my guest session wasn't working - it would load the wallpaper and that was it
<alex-weej> but when i deleted the user it started working
<alex-weej> though gnome-settings-daemon seems to fail. i get the inbuilt GTK theme
<alex-weej> and also when i switched back to my normal user
<alex-weej> it locked the guest session
<pitti> alex-weej: did you have a real (uid >= 1000) "guest" user before?
<alex-weej> and wanted a password to unlock ....
<pitti> alex-weej: locked> known bug
<alex-weej> ok
<slangasek> pitti: yes, it worries me as well; but are we better off holding back ekiga than updating it for beta?
<alex-weej> guest:x:121:1001:Guest,,,:/tmp/guest-home.m12816:/bin/bash
<pitti> slangasek: if we want to have it in intrepid, I'd rather have it now than post-beta
<slangasek> yes, by "holding back ekiga" I meant "holding back ekiga for release" :)
<pitti> is there a PPA we can test?
<pitti> oh
<slangasek> a ppa of ekiga? not AFAIK :/
<infinity> pitti: I would argue that 2.9.xx was "3.0 beta", given the version scheme.
<pitti> slangasek: it would violate just about every freeze we have, plus require a lot of work which we better spend on other things now, so I lean towards "no" tbh
<alex-weej> pitti: i have a /home/guest folder --- so i guess i created that user myself?
<pitti> infinity: yes, it would be, if only it was in intrepid---we have 2.0.12
<slangasek> pitti: well, GNOME also routinely violates the freeze, the difference being that it violates it incrementally via the betas :)
<pitti> alex-weej: yes, the gdm guest session uses /tmp/
<infinity> pitti: Yeah, I see that.  :/
<alex-weej> ekiga should get on gnome release cycle...
<slangasek> s/GNOME/the rest of &/
<infinity> pitti: I was just responding to the "I never saw any betas" comment.
<seb128> what is the discussion about?
<alex-weej> ekiga 3 in intrepid
<pitti> infinity: yeah, I meant "in intrepid"
<slangasek> seb128: bug #274085
<ubottu> Launchpad bug 274085 in ekiga "Please update Ekiga to 3.00" [Wishlist,Triaged] https://launchpad.net/bugs/274085
<seb128> ubuntu lacks somebody interested in maintaining ekiga
<seb128> especiall the broken libs it depends on
<slangasek> seb128: ekiga is apparently part of GNOME 2.24, but there haven't been any updates to the pre-releases ... ah :/
<seb128> but updating to ekiga3 would be a good idea
<seb128> slangasek: right, I think technically it's in the GNOME desktop set, they just suck at rolling tarballs and have broken libs and nobody seems to be interest in working on updating it for debian or ubuntu
<slangasek> hrm, what are the broken libs?
<seb128> dholbach was doing it for a while but nobody else picked since
<seb128> slangasek: apparently ptlib is doing weird things, ask dholbach when he's around, he complained a lot while he was doing the update
<slangasek> oh, just ptlib then :)
<elmo> I remember their packaging from debian as being, err junichi inspired
<seb128> libopal could be in the same case
<seb128> elmo: hey, any way to have python-apt it the hardy environment on ronne? I would like to have a go at restarting the hardy retracers now
<infinity> seb128: I can do that.
<seb128> elmo: I'll file a r-t and give it a try later otherwise, there is no real hurry
<seb128> infinity: that would be nice thanks, the i386 and amd64 hardy chroots on ronne
<slangasek> seb128: the libraries don't concern me, then, so much as the lack of anybody keeping an eye on it and the absence of pre-release testing in Ubuntu
<slangasek> if we do update it to 3.0, will someone from desktop keep an eye on it?
<slangasek> (and for that matter, who will do the update?)
<seb128> slangasek: I know upstream is unhappy about us shipping outdated version and we already had some explanations rounds about that
<infinity> seb128: Done.
<seb128> slangasek: I was talking about that to lool today, upstream has snapshot for ubuntu, would be nice to have whoever is doing those working directly in ubuntu
<slangasek> pitti: oh, it appears there is a ppa: https://launchpad.net/~sevmek/+archive
<seb128> slangasek: really try to talk to lool about it, he has been testing the recent snapshot for mobile apparently
<slangasek> ok
<slangasek> lool: ping (but I'm out to lunch now, so take your time responding :)
<seb128> I think he's the best placed to give you an opinion on the new version
<seb128> infinity: thanks for the ronne install ;-)
<norsetto> hi seb128
<seb128> hey norsetto
<radix> mathiaz: hi
<radix> mathiaz: I think I have a branch ready for you
<radix> mathiaz: with the caveat that it seems a traceback will still be printed :(
<mathiaz> radix: ok - I'll have a look at it then
<radix> it's awkward, because a traceback is actually being printed by landscape-client itself
<radix> when landscape-config tries to start it
<mathiaz> radix: the traceback is not such a big issue.
<mathiaz> radix: the main point is that the postinst script doesn't fail if the registration cannot be completed.
<radix> right ok
<radix> that is definitely the case now
<mathiaz> radix: and I'd try to avoid adding || true to the script
<radix> mathiaz: the branch is lp:~radix/landscape-client/minor-intrepid-fixes
<radix> mathiaz: it has one minor change unrelated to landscape-config: a lowering of a timeout related to package management in landscape
<radix> it doesn't actually change any functionality, just makes it so errors about package management are reported much more quickly (~1h instead of ~1d)
<sbeh> hi, "localedef --no-archive --magic=20051014 -i en_US -c -f UTF-8 en_US.UTF-8" hangs at 100% cpu reproducable and "strace -p `pidof localedef`" gives no output, what can i do to determine whats causing this problem?
<james_w> is http://paste.ubuntu.com/50619/ an abomination that should never see the light of day?
<lool> slangasek: pong
<lool> james_w: That looks clean to me, but what does it fix?  Was it run by upstream?
<james_w> lool: no, it wasn't yet
<james_w> the configure script sets HAVE_DECL_GETPWNAM, and then the code checks for HAVE_GETPWNAM
<james_w> that patch makes it set both
<james_w> I think perhaps just having the code check for HAVE_DECL_GETPWNAM might be cleaner
<james_w> it's fixed in the new upstream, but the patch seems a little larger than necessary
<lool> james_w: I guess the HAVE_DECL_GETPWNAM stuff should be dropped -- unless it has special per-arch handling, in which case you want to fix this part rather than piggy-backing on the AC_CHECK_FUNC
<lool> or FUNCS
<james_w> I don't think there's any special handling, comments indicate it's for migw32
<lool> james_w: Ah it's fixed in a new upstream which renames the ifdef and all?  Then I don't think it matters either way, but it's perhaps clearer to use their fix
<james_w> the new upstream still sets the _DECL_ one, but also sets HAVE_GETPWNAM and only uses that
<lool> james_w: Ok; if the DECL one isn't used in the source anymore, feel free to only grab the fix for the HAVE_GETPWNAM ifdef only for now; sounds good
<radix> mathiaz: I bumped the version number to 1.0.21.1 in that branch but haven't touched anything in debian/
<mathiaz> radix: right - I'm looking at it now.
<mathiaz> radix: I guess you'll publish it a new tarball soon.
<radix> mathiaz: yeah I'll put one up on launchpad
<pitti> hm, https://wiki.ubuntu.com/UbuntuWorldWide is pretty emtpy ...
<pitti> kwwii: any chance you could mail me your jockey icon svgs soon?
<pitti> kwwii: (I think you have them ready already, and just forgot to send them)
<IntuitiveNipple> Keybuk: ping
<tkamppeter> pitti, I have upstreamized the s-c-p Jockey client patch now.
<tkamppeter> pitti, and s-c-p is now ready for your driver descriptions as in bug 269454
<ubottu> Launchpad bug 269454 in system-config-printer "show printer driver support contacts, status, and unsupported color mode warning" [Undecided,In progress] https://launchpad.net/bugs/269454
<pitti> tkamppeter: rock, thanks! you can upload s-c-p, btw, it'll just undergo review
<tkamppeter> pitti, on the two screenshots of your Jockey release announcements I have seen a small UI flaw: You explain to dumb GNOME users what "proprietary" means but assume that KDE users are the absolute experts and do not explain it.
<pitti> tkamppeter: good point, you just found a bug in the KDE UI
<pitti> tkamppeter: something to fix tomorrow, though, I'll go to bed now
<tkamppeter> pitti, s-c-p uploaded, do I have to report a bug and subscribe someone to it?
<pitti> tkamppeter: just filing a bug about the missing window subtitle myself
<pitti> tkamppeter: for s-c-p? the changelog should refer to #269454
<tkamppeter> pitti, I mean for a beta freeze exception
<pitti> tkamppeter: no, that's fine
<pitti> tkamppeter: bug 274558, FYI
<ubottu> Launchpad bug 274558 in jockey "KDE UI does not show window subtitle" [Medium,In progress] https://launchpad.net/bugs/274558
<pitti> good night everyone!
<slangasek> lool: hi, did you see the discussion above about ekiga?
<lool> slangasek: Not the above one, I had one with seb128 earlier on #ubuntu-desktop; scrolling back now
<slangasek> ok
<lool> slangasek: Right, so what I was saying was that the architectural, UI, and general changes in the new ekiga are really worthwhile to try to get; I mentionned UI as one point where we'd need some doc team ack first though
<lool> My testing showed a very broken ekiga back then, but most issues I raised were either already fixed or fixed subsequently
<lool> It would need some retesting now
<slangasek> lool: well, the UI freeze as currently structured doesn't require doc team ack, just notification
<slangasek> the bigger issue is that we're now all the way into beta freeze, and there doesn't seem to have been any activity on getting the new version into intrepid (until now)
<lool> I know opal/ptlib have historically been a pain to deal with, but the upstream changes should make them less painful hopefully
<slangasek> upstream changes in opal/ptlib?
<slangasek> or in ekiga?
<lool> In opal/ptlib
<lool> They worked on the build system somewhat
<slangasek> does that mean we need to pull new upstream versions of those libs for this ekiga drop, or does it mean there are already upstream fixes in intrepid for those problems?
<lool> Hmm usually you need to update ptlib, opal, and ekiga to the latest versions as a chunk
<ogra> lool, hmm, yeah, i think the desktop-common task is what pulls in the stuff to mid
<lool> Concerning the build changes, I don't know their substance but I do know that I had many issues with the build of these libs in the past and would welcome progress on the build scripts :)
<lool> ogra: See!  :)
<ogra> so let me drop that from the seeds for you
<lool> ogra: So we use some lower level seed for hardy's mid/mobile and for intrepid's seeds (until now)
<lool> ogra: Perhaps you should use the same thing as structure?  I don't know what the field is used for, but we should look it up
<ogra> right, but you will likely run into the same probs i had if you add packages that have recommends
<ogra> i know the mobile seed is fine now, colin fixed it, i trues him in that regard :)
<ogra> *trust
<lool> slangasek: I need to grab all this stuff if you want a more in depth look at it; I agree with prior comments here that we need someone caring more about this GNOME substack, it didn't see enough love
<lool> (and that's true in Debian as well BTW)
<ogra> oh, mid uses minimal in STRUCTURE :)
<lool> ogra: Yeah
 * ogra adjusts
<ogra> sorry, that was my fault ... i just copied the task headers from mobile without checking
<slangasek> lool: do you know if ekiga works right with alsa bluetooth yet? :)
<ogra> slangasek, btw, i think uswsusp breaks with usplash or something like that, i remember i discussed it before with matthew
<lool> slangasek: I should have all the hardware to test now, but never tried that yet
<slangasek> ogra: right, that sounds familiar
<slangasek> lool: hmm, perhaps I should test here; last time I tested that was with hardy
<lool> slangasek: I think this ekiga and libs update deserves some formal ppa preparation and mini testing
<lool> despite being GNOME stuff
<slangasek> agreed
<lool> The only open question would be whom lalala
 * lool looks around
<lool> Ah crap, I just walked over this bluetooth headset
<ogra> heh
<ogra> hmm, so ubuntu.mobile doesnt seem to install grub
<ogra> according to my users the install works flawless ... but they end up with error 15 after reboot
<ogra> was that the same issue persia had ?
<lool> ogra: THat's the meta kernel image missing I think
<ogra> with mid ...
<lool> ogra: But are you building wiht lpia?
<ogra> nope
<lool> I thought your image was i386
<ogra> generic
<lool> Ah
<ogra> but the error seems the same ...
<lool> ogra: Blah then it's likely we have an unrelated issue from the meta
<ogra> i'm not sure but we might need the grub-.install thingie from d-i in pool on the image ...
 * ogra thinks he remembers something similar being on the livecd
<ogra> hmm, no
<ogra> only oem-config there
<lool> Could you frobble with this thingie and see if it helps?
<ogra> i will, but not tnight anymore
<lool> Oh sure
<ogra> i'll donate my workday to it tomorrow ... i want an installable ubuntu.mobile now that the seed is fixed
<lool> ogra: Did you push the new mobile-meta?
<ogra> the task fix, i'm still running update
<lool> pedal harder
<ogra> oh, great ... the fdi i got for evtouch for fijitsu was taken with a device where the touchscreen was switched to wacom mode in the BIOS
 * ogra headdesks
<ogra> the user just sent me a fixed lshal
 * ogra sees slangasek hasnt approved xf86-input-evtouch yet ....
<ogra> slangasek, can you reject it so i save a version number ?
<slangasek> hum, ok
<slangasek> yes, rejecting
<ogra> thanks :)
<ogra> i'll upload a new one before going to bed
<slangasek> ok
 * ogra hates to add HW info for devices he doesnt have the HW for to check ...
<ogra> i wouldnt be a good hal maintainer ... i truest what people mail me :o)
<ogra> lool, didnt fix it :/
<ogra> lool, http://paste.ubuntu.com/50629/
<ogra> though its less now
<ogra> oh, well, and it has such unimportant stuff like udev in it ...
<ogra> i guess its right
<ogra> please check that list, if you agree i'll upload
<lool> ogra: Might be the result of other seed updates in the minimal set
<ogra> it all looks reasonable
<lool> It really looks like it comes from that task header though
<ogra> well, you surely want things like lsb-release or module-init-tools
<lool> ogra: I don't quite see why these should be pulled by ubuntu-mobile; they are pulled by ubuntu-minimal already
<ogra> Added ubuntu-minimal to mid
<ogra> i guess thats why
 * lool wonders what netcat does in minimal
<ogra> i use it in ltsp ... but i think it was there before
<lool> Sounds like standard
 * ogra cant remember writing a MIR at least
<lool> "eject" blah
<ogra> well, gnupg and initramfstoold make sense :)
<lool> ogra: Anyway, I don't understand enough what the headers do at the top of the seed and these new deps sound bogus to me
<lool> ogra: Other meta packages don't depend on this stuff
<ogra> *initramfs-tools
<ogra> its the deps of minimal
<lool> ogra: I wonder whether you should rather use mid / mobile in this task header
<lool> ogra: But we don't want to have the deps of minimal, we only want minimal to be installed and do its job I think
<lool> ubuntu-desktop doesn't depend on these, nor even on ubuntu-minimal
<ogra> desktop definately pulls in minimal
<lool> The seed, but not the package?
<ogra> yeah
<ogra> the task :)
<lool> Exactly, so I don't see why we should add his list of deps to ubuntu-mid or mobile meta
<ogra> well, i can drop the task header from mid
<ogra> shall i ?
<lool> Well shouldn't it read "mid"?  I don't know what it does, so I really can't tell
<lool> ogra: Shall I grab some doc and read up what it's for?
<ogra> lool, if you know where thats documented
<lool> It replaces the seed_map/seed thing
<lool> man/germinate-update-metapackage.1
<ogra> lool, doesnt talk abotu tasks in seed headers
<lool> It's used in update-metapackage.py, seed_packages() to select mapped seeds
<lool> Perhaps it's used in other software as well too
<lool> ogra: Anyway, it looks like for desktop this allows pulling the desktop-common packages as additional direct deps of the desktop meta
<lool> ogra: And we don't need that
<ogra> not in mid
<lool> ogra: So either not having the header or listing the seed name in the header is the correct thing to do here I think
<lool> ogra: Unless we want some mobile-common or mid-common
<ogra> nah, i want mobile to be the same as desktop with slight modifications
<lool> I think we don't need the header as the header in desktop only lists common
<ogra> but mid is indeed a different thing
<lool> Grmpf, someone decided to remove "unused" seeds
<ogra> so i'll keep it in desktop and drop it completely from mid ... but dont shout at me if you end up with recomends you didnt want
<ogra> i think that was persia
<ogra> though StevenK merged it
<lool> Yeah, read that
<lool> ogra: Why would we end up with recommends we didn't want?
<ogra> becaue you have no task handling anymore without the headers
<lool> ogra: I don't quite know what pushed you into adding the headers, perhaps you want to double check with cjwatson tomorrow what they are for, and which ones to drop?
<ogra> the task makes sure that seed deps are fulfilled first
<lool> ogra: We don't need to remove all headers, just the last one...
<lool> Task-Seeds
<ogra> ah, k
<ogra> pushed
<lool> ogra:  mid -> MID sounds (Mobile Internet Devices, it's spelled MID on wikipedia as well)
<lool> +better
<ogra> pushed too
<lool> ogra: Check e.g. the server seed, it doesn't have this Task-Seed header
<ogra> lets see ...
<ogra> update is running
<lool> ogra: Hmm you didn't fix the mobile seed
<lool> (I did)
<ogra> huh ?
<ogra> the mobile seed is fine as colin set it up
<lool> It was using Task-Seeds desktop-common
<lool> Oh that's actually what you want
<ogra> right
<ogra> desktop-common != ubuntu-desktop
<lool> ogra: As I was saying above, you might want to reconsider that choice
<lool> Yeah, I know how desktop-common is used right now
<ogra> ok
<lool> pushed the readdition, sorry
<ogra> well, i wonder how that affects my currently running update of meta
<ogra> ../mobile-meta-1.116
<ogra> Added landscape-common to mobile-recommends
<ogra> Added linux-headers-lpia to mobile-recommends [lpia]
<ogra> Added powernowd to mid-recommends
<ogra> looks better :)
<ogra> shall i upload ?
<lool> Sure
<ogra> okidokie
<lool> ogra: What I was saying earlier is that desktop-common is higher level and pulls in lots of stuff
<lool> So you will end up running syslog, or having tools that you don't care about etc.
<ogra> lets see what i get
<ogra> i dont think syslog is wong ...
<lool> And one of the targets was to shrink the image size to a minimum
<ogra> well, i actually want ubuntu-desktop with different setup and themeing for mobile
<ogra> and dropping some toplevel apps
<lool> I think it depends, but I tend to agree with people not running syslog on their phone, I'd be inclined not to install in on mids, and probably wouldn't be sure of the point in netbooks
<ogra> but benefit from the work the distro team does on the rest of the seeds, so i dont have to care
<ogra> you dont want ubuntu.mobile on a phone :)
<kwwii> pitti: yes, I can send them to you once I clean them up...still not happy with the open source icon but I have the svg's...do you need png files for different sizes?
<lool> What I'm trying to say is that the two end of the scales exist: phones and laptops, and there's a point where you definitely don't want things like syslog
<ogra> i know the oem team has patches to syslog to log a lot less
<ogra> and for jaunty i want to review these patches and include tehm where they are suitable
<ogra> i dont even run syslog here on my lappie ... for startup speed reasons ...
<ogra> on SSD netbooks/MIDs you definately want a special policy that makes them write less frequently
<ogra> lool, we need someone to approve the upload btw (beta freeze)
<lool> yup
<ogra> slangasek, ^^^ one mobile-meta approval waiting for your powers ... btw is there anyone else beyond you i can bug ... feels odd to put everything on your sholders (or do you prefer to have total control ?)
 * lool pictures the "Total Control" keyboard in slangasek's basement
<ogra> the two key kbd with fist sized buttons "yay" "nay"
<sleepster> how can I add a package to the ubuntu repositories?
<ogra> sleepster, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<sleepster> thanks
<kwwii> pitti: I just sent you the svgs per email
<slangasek> ogra: anyone else in ubuntu-release can also approve things :)
<slangasek> (but this time of day, I think that's just me, for all intents and purposes)
<ogra> ok
<ogra> i think that question is as generic as my traditional freeze comment :)
<bryce> cjwatson: btw, the milestones page moved here:  http://bryceharrington.org/X/Milestones/
<bryce> cjwatson: elmo had asked that scripts not scp stuff to people.ubuntu.com anymore, so I've had to migrate all my scripts onto my own HW now
<bryce> I've stuck a redirect in
<IntuitiveNipple> bryce: ping
<slangasek> pitti: do you have any idea about this console-kit crasher bug?
<mathiaz> slangasek: could you have a look at bug 274573 and let me know if that suits a BetaFreeze Exception ?
<ubottu> Launchpad bug 274573 in landscape-client "landscape-client package fails to install when run from the installer" [High,New] https://launchpad.net/bugs/274573
<slangasek> mathiaz: rather large set of changes to test_configuration.py, no changelog explaining why they're needed?
<fta> I have a problem with python-gnome2-extras-dev (not installable) http://launchpadlibrarian.net/17965516/buildlog_ubuntu-intrepid-i386.miro_2.0~svn20080925r8059-0ubuntu1~fta1_FAILEDTOBUILD.txt.gz
<mathiaz> slangasek: they're test cases for the option that has been added.
<slangasek> mathiaz: I meant the 'filename' stuff, but it looks like this has just been refactored
<slangasek> mathiaz: yes, looks ok
<radix> sorry yeah, I was getting really annoyed by the duplication in those tests
<slangasek> :)
<radix> I probably should have delayed the refactoring
<mathiaz> slangasek: ok - uploading.
<bryce> IntuitiveNipple: yeah?
<bryce> IntuitiveNipple: fwiw, it's better to just ask a question rather than pinging.  If I'm around I can answer it immediately without waiting for another roundtrip with you.  If I'm not around, then others can have a shot at answering it.
<IntuitiveNipple> bryce: do you have 5 mins to give me an insight into libxft2, re bug #145244 - I've got a user in south-africa I'm doing remote support for. Hardy updated to 2.1.12-2ubuntu5 and since then gdmgreeter goes mad and they can't log-in. (this is on i386)
<ubottu> Launchpad bug 145244 in xft "[gutsy] libXft library - undefined symbol FT_Library_SetLcdFilter" [Undecided,New] https://launchpad.net/bugs/145244
<IntuitiveNipple> bryce: I suspect it is specific to your knowledge of the latest patch, from the changelog
 * bryce looks
<IntuitiveNipple> bryce: I've been back-tracing the source-code after capturing the symbol-not-found issue with strace, and one thing I did notice was it looks like the liXft... patch doesn't actually do anything since it depends on #ifdef FC_LCD_FILTER which isn't set anyplace
<IntuitiveNipple> s/liXft.../libXft.../
<bryce> which patch is this?
<IntuitiveNipple> bryce: I'm just pinning the package back to the previous version to test
<IntuitiveNipple> the patch that doesn't seem to actually get used is libXft-2.1.10-lcd-filter-3.patch
<IntuitiveNipple> bryce: it is applied... but what's in it doesn't look to be #ifdef-ed in - i've not gone as far as capturing the preprocessor output yet though
<IntuitiveNipple> but that patch is instrumental in the symbol_not_found FT_Library_SetLcdFilter that causes gdmgreeter to endlessly spin and fail without drawing the log-in dialog
<bryce> Intuitive, hmm looks like you're right.  I didn't author the patch though; I just did a merge to debian and kept it in.  Keybuk is probably the better one to ask about it
<IntuitiveNipple> bryce: no, I realise that, but I just wondered if you might save me some brain-frying with any insight
<IntuitiveNipple> I pinged Keybuk earlier but no reply so far
<IntuitiveNipple> I'm pinning the user's packages back to the previous version now, see if that solves it
<IntuitiveNipple> I'll also update that bug report
<bryce> well, probably the easiest thing would be to just slap more #ifdef's around the use of that symbol
<IntuitiveNipple> My solution here was to add to CFLAGS += -DFT_LCD_FILTER so that code is added
 * bryce looks some more
<bryce> does that make the issue go away?
<IntuitiveNipple> and strangely that builds for me on my amd64, but *not* on the user's i386 :)
<IntuitiveNipple> well,it would make sense, because with that defined, the code in the patch is included, which causes libXft to be dyn-linked to libfreetype6 which contains the missing symbol
<bryce> hmm, from what I can see, that define shouldn't make a difference
<bryce> ah, dynamic linking.  hmm
<IntuitiveNipple> yeah, it's a minefield!
<IntuitiveNipple> my brain is fried trying to get up to speed on it
<slangasek> pff, dynamic linking is a piece of cake, you just have to remember these 17 simple rules:
 * IntuitiveNipple laughs
<IntuitiveNipple> Bryce: don't stress on it - I'll sort the user for now, and update the bug and produce a fixed package debdiff
<bryce> ok cool
<IntuitiveNipple> I was just hoping someone already knew the answer :0
<bryce> yeah I'd suggest getting Keybuk's input on it, this isn't a patch I'm terribly familiar with
<IntuitiveNipple> It looks like its been added in and out several times in a tug of war, too
<bryce> it's a bit complicated; it'd be nice to see this go upstream or something
<IntuitiveNipple> yeah :)
#ubuntu-devel 2008-09-26
<IntuitiveNipple> To do this remote support, I've got the user in S.A. on a Windows box with putty, ssh to my laptop here in the U.K, then a screen Multiuser session joining us, then ssh back to the user's site and port-forwarded to the faulty machine :)
<digistyl3> hi everyone, i think there's a problem with todays acpi-support update
<digistyl3> it's changelog mentiones adding 90-hdparm.sh to the ac.d folder
<digistyl3> while it is added to battery.d, resume.d, start.d and suspend.d (which isn't mentioned in the changelog), i can't find it in ac.d
<digistyl3> eventhough it states it in the changelog
<digistyl3> and so it didn't change hdparm-s B parameter to 254 as it is described in the changelog
<digistyl3> i'm using version 0.111
<slangasek> bryce: ^^
<bryce> slangasek: ok I'll take a look
<bryce> $ ls */90-hdparm.sh
<bryce> ac.d/90-hdparm.sh  battery.d/90-hdparm.sh  resume.d/90-hdparm.sh  start.d/90-hdparm.sh
<bryce> hmm, appears to be there for me
<slangasek> I don't see ac.d/90-hdparm.sh in the binary package, perhaps there's an install rule that needs updated
<digistyl3> ls */90-hdparm.sh
 * bryce tests install
<digistyl3> resume.d/90-hdparm.sh  start.d/90-hdparm.sh
<digistyl3> wierd :|
<cjwatson> bryce: milestones> ah, thanks
<wgrant> william@irranat:/etc/acpi$ ls */90-hdparm.sh
<wgrant> resume.d/90-hdparm.sh  start.d/90-hdparm.sh
<wgrant> I upgraded about 5 minutes ago.
<bryce> yeah debian has their own completely replaced debian/ dir, and I may have missed tweaks to .install files
<wgrant> Hmm, why are they not symlinks?
<bryce> dunno
<bryce> feel free to send me a patch
<bryce> aha, ok so rules installs stuff in suspend.d, start.d, resume.d, events, and lib, but no other dirs.  Should be easy to fix.
<wgrant> Hmm, is that script meant to actually do anything in the default installation?
<wgrant> laptop-mode seems to default to controlling it, but it isn't doing a very good job.
<digistyl3> before this i used laptop-mode
<digistyl3> and it did it's job for me
<digistyl3> setting hdparm -B to 254 while on AC and to 128 while on battery (as i told him to do)
<digistyl3> but before i installed the update i disabled laptop-mode, as it is disabled in a default instalation
<wgrant> What triggers laptop-mode? I can hear my disk slowly killing itself a couple of times a minute on AC.
<digistyl3> wgrant: i had to enable laptop-mode in /etc/default/acpi-support
<wgrant> Umm, that's bad.
<digistyl3> then in /etc/laptop-mode/laptop-mode.conf i changed some values (255 to 254 when on ac, and 1 to 128 when on battery)
<wgrant> But true.
<slangasek> I thought that was supposed to be fixed at a different level now, so that -B 254 was the default
<wgrant> 90-hdparm.sh checks if laptop-mode is installed, and if so it checks its config file. If laptop-mode's config file says that it will manage HDD power settings, 90-hdparm.sh does nothing.
<wgrant> Even if laptop-mode is disabled in /etc/default/acpi-support.
<slangasek> i.e., without any intervention from laptop-mode or acpi-support
<bryce> digistyl3, wgrant: is there a LP# for this missing 90-hdparm.sh issue?
<bryce> digistyl3, wgrant: also, I'm curious if the 90-hdparm.sh is useful for you?
<wgrant> bryce: I haven't looked, and only discovered it 10 minutes ago.
<digistyl3> bryce: i'll check, if there isn't one, should i create one?
<wgrant> bryce: I was previously running hdparm manually after resume after I noticed things going bad... it would be useful if it worked, yes.
<wgrant> But in the default installation it doesn't do anything.
<ogra> acpi-support isnt used at all anymore on suspend/resume (at least its not supposed to as it interferes with the new default now)
<bryce> digistyl3: I'm sure slangasek would appreciate having the change associated with a bug number
<ogra> look in pm-utils for stuff being executed
<slangasek> bryce: at all times, yes :-)
<wgrant> How is laptop-mode meant to be run now?
<slangasek> I thought it was meant to be obsolete
<wgrant> Right.
<ogra>  /usr/lib/pm-utils/sleep.d/96laptop-mode
<ogra> from there
<wgrant> But 90-hdparm.sh is a noop if it's installed and meant to be managing your HD power settings.
<slangasek> well, acpi-support is also meant to be obsolete
<ogra> right
<ogra> its only there for backwards compatibility with user written scripts
<slangasek> which one? :)
<ogra> no idea, but that was the reason to keep it in hardy
<ogra> :)
<slangasek> I mean: which one, laptop-mode or acpi-support?
<ogra> acpi-support
 * cjwatson unbreaks the mobile seeds a bit to avoid breaking the publisher
<ogra> cjwatson, what did i break ?
<cjwatson> hopefully that's all that's needed
<cjwatson> you didn't, persia and StevenK did ;-)
<ogra> the meta upload wasnt approved yet
<cjwatson> the blacklist file is still needed
<ogra> phew
<cjwatson> doesn't affect mobile-meta
<ogra> yeah lool wondered as well about all that dropping
<cjwatson> clearly nobody tried running germinate on it as a test case
<cjwatson> * Downloading http://people.ubuntu.com/~ubuntu-archive/seeds/mobile.intrepid/blacklist
<cjwatson> ! Could not open (any of):
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<cjwatson> !   http://people.ubuntu.com/~ubuntu-archive/seeds/mobile.intrepid/blacklist
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<digistyl3> bryce: i reported it: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/274599
<ubottu> Launchpad bug 274599 in acpi-support "Some 90-hdparm.sh files missing from acpi-support" [Undecided,New]
<bryce> thanks
<digistyl3> yw
<wgrant> If laptop-mode-tools is obsolete, why is it recommended by ubuntu-desktop?
<bryce> digistyl3: btw it doesn't install into suspend.d
<digistyl3> what the... i have no sound after the latest updates :D
<slangasek> perhaps I'm wrong about that part; but I thought g-p-m was taking over most of the duties of laptop-mode
<ogra> well, pm-utils
<ogra> g-p-m is a dumb frontend :)
<slangasek> sure
<digistyl3> bryce: sorry, my bad :)
<ogra> wgrant, see /usr/lib/pm-utils/sleep.d/96laptop-mode
<bryce> slangasek:  btw it was brought to my attention that while I'd indicated in the changelog that thinkpad.modprobe was reenabled, that was not actually the case.  I'll drop mention of that in the previous changelog entry.
<slangasek> ok
<wgrant> ogra: So it still respects /etc/default/acpi-support?
<ogra> it only reads the ENABLE_LAPTOP_MODE value from either there or /etc/default/laptop-mode
<ogra> to then call /usr/sbin/laptop_mode auto
<wgrant> The latter of which doesn't exist.
<wgrant> So by default it's all pretty broken.
<bryce> any other acpi-support changes to put in while I'm at it?
<ogra> why is it broken ?
 * slangasek glares at python-wxgtk2.6
<slangasek> >>> import wx
<slangasek> Traceback (most recent call last):
<slangasek>   File "<stdin>", line 1, in <module>
<slangasek> ImportError: No module named wx
<wgrant> ogra: Because laptop-mode-tools is installed, its CONTROL_HD_POWERMGMT defaults to 1, and /etc/default/acpi-support defaults to disabling laptop-mode. Thus 90-hdparm.sh does nothing.
<digistyl3> wgrant: have you restarted your computer? do you have sound? :\
<wgrant> digistyl3: I do. There are lots of sound drivers.
<ogra> wgrant, right, on purpose .. please read the various mailthreads on -devel and -devel-discuss that piled up over the last yeras about that :) we never enabled it by default
<TheMuso> digistyl3: WHat problem are you seeing exactly?
<digistyl3> no sound at all, amarok won't play mp3s
<digistyl3> when i hit test sound in gnome
<digistyl3> i get this
<digistyl3> audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Failed to connect stream: Invalid argument
<wgrant> ogra: So how is Joe User meant to know how to avoid killing his HDD?
<ogra> he isnt ... its not an OS problem
<digistyl3> TheMuso: it worked a few minutes ago, i just rebooted after the updates
<TheMuso> digistyl3: Right. Can you please try the package for your architecture located here: http://www.themuso.id.au/ubuntu/alsa-plugins and tell me if anything has changed.
<ogra> (as you can see from the mail threads i mentioned)
<TheMuso> digistyl3: What updates did you download?
<wgrant> ogra: In Intrepid's default configuration, my laptop's HDD parks multiple times a minute. This is a probably, and an easily fixable on.
<wgrant> Er, this is a *problem*.
<digistyl3> TheMuso: the ones from update manager, yes, it contained the respective package
<digistyl3> TheMuso: can i restart only the alsa server or do i need a full reboot?
<TheMuso> digistyl3: ok please try the package for your architecture at the url I gave above and tell me if anything has changed.
<ogra> wgrant, really i'm not after discussing that issue every three months, there are mails and explanations of the issue a bug and even a lwn.net article
<TheMuso> digistyl3: You shouldn't need to reboot.
<bryce> fwiw, debian dropped the ENABLE_LAPTOP_MODE=false  bit in their version of acpi-support
<wgrant> ogra: What are people recommended to do?
<ogra> please read up about it ...
<wgrant> Do you happen to recall the subject line of one of the threads?
<wgrant> There's an awful lot of mail on -devel and -devel-discuss.
<JontheEchidna> pitti: ahoy, wanna picture of jockey-kde from a native kde environment for your blog?
<digistyl3> TheMuso: i installed the package, but i get the same error
<digistyl3> maybe i do need a reboot?
<TheMuso> digistyl3: yes please try a reboot.
<ogra> wgrant, bug 59695 .... enjoy ...
<ubottu> Launchpad bug 59695 in dell "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Undecided,Confirmed] https://launchpad.net/bugs/59695
<wgrant> ogra: I was hoping for something with a slightly higher signal-to-noise ratio, but thanks.
<slangasek> ogra: so how do we fix that bug, once for all?
<ogra> wgrant, http://lwn.net/Articles/257426/
<ogra> slangasek, teach HW vendors ?
<wgrant> AFAICT this is a regression in Intrepid, at least for me.
<ogra> that might be something else then
<slangasek> ogra: er, TTBOMK all hardware DTRT with -B 254 and the problem has been that we weren't consistently using -B 254 in software
<slangasek> if we /are/ doing -B254 everywhere now, then the bug should be closed
<ogra> slangasek, well, then we should fix it elsewhere
<ogra> but surely not in acpi-support
<wgrant> The code that sets -B254 doesn't run in the default installation, AFAICT.
<wgrant> Or is there another place that does it?
<ogra> /etc/hdparm.conf
<digistyl3> TheMuso: i'm back
<digistyl3> i heard sound when starting gnome
<TheMuso> digistyl3: how did it go?
<digistyl3> but after that
<digistyl3> it just dies
<digistyl3> i get the same problems
<wgrant> ogra: 'quiet' is set, and that's all.
<TheMuso> digistyl3: so if you run the test you ran earlier, you get the same error?
<wgrant> ogra: I installed this laptop with alpha 5, FWIW.
<ogra> right, i was just pointing out a more proper place to add the fix
<JontheEchidna> pitti: http://i31.photobucket.com/albums/c355/Woremar/jockey_05beta1.png
<wgrant> ogra: Ah, right.
<digistyl3> TheMuso: yes, exactly the same error
<ogra> acpi-support is considered obsolete since a while ... doesnt appear right to me to add fixes there we want to persist if its dropped completely one day
<TheMuso> digistyl3: Ok, thanks. I think that rules out the package I got you to test.
<wgrant> ogra: One cannot actually remove laptop-mode-tools - is this deliberate?
<TheMuso> digistyl3: Now I suggest running the following command to revert back to the originally stalled version: "sudo apt-get --reinstall install libasound2-plugins=1.0.17-0ubuntu3"
<ogra> wgrant, i can remove it here
<wgrant> ogra: It takes acpi-support and thus ubuntu-desktop with it here.
<digistyl3> TheMuso: ok, i downgraded
<ogra> and ?
<wgrant> ogra: ... removing ubuntu-desktop isn't a solution.
<slangasek> heh
<bryce> should I add a Suggests for laptop-mode-tools?
<wgrant> It isn't a solution to removing something that is meant to be obsolete and is turned off.
<slangasek> bryce: I don't imagine it matters
<bryce> ok; I see debian added it in their version
<slangasek> I wouldn't balk at seeing it added in a freeze diff :)
<ogra> wgrant, why do you *want* to remove it ?
<wgrant> ogra: So 90-hdparm.sh does something.
<bryce> slangasek: okies
<TheMuso> digistyl3: and you said amarok doesn't work? Could you possibly try running a sound applicatino from the terminal, and pastebinning the terminal output?
<wgrant> ogra: And while I have no problems with hacking the script or strange config files to get it working, users shouldn't have to.
<ogra> wgrant, laptop-mode-tools isnt obsolete, acpi-support is
<ogra> as well as pmi
<digistyl3> TheMuso: ok
<wgrant> ogra: Oh, I took your statement earlier as meaning that laptop-mode-tools was being replaced by pmutils and g-p-m. You meant acpi-support?
<ogra> laptop-mode-tools is executed by pm-utils if its enabled
<ogra> as i showed you before
<wgrant> Right.
<wgrant> So is 90-hdparm.sh's behaviour a bug? (it doesn't care if laptop-mode-tools is switched on or not)
<ogra> anyway, 2am here .... bed time ... if -B254 is needed we should fix it in hdparm.conf and make it a default ... or even patch the hdparm binary to use that value by default
<wgrant> Night ogra.
<ogra> but honestly i dont think your disk access is realted to that, i would look for apps that do this or a kernel change
<slangasek> eh, the issue was that things were using -B255 instead of -B254
<slangasek> but that may have only been the acpi-support angle
<digistyl3> TheMuso: only mplayer was able to produce sound
<wgrant> Setting -B254 manually works fine.
<digistyl3> i opened it with totem too
<wgrant> So something isn't setting it.
<digistyl3> here's the pastebin: http://pastebin.com/m79255621
<slangasek> I would say that everything isn't setting it :)
<ogra> wgrant, and you are 100% sure it was set in i.e. hardy ?
<wgrant> slangasek: Probably, but I'd hope that only a subset of those were meant to be setting it.
<wgrant> ogra: I'm not 100% sure, but I think it was.
<TheMuso> digistyl3: thanks, looking.
<wgrant> It's quite noticable when it does it.
<slangasek> I'm not sure that -B254 was getting set in hardy; if it was, somebody forgot to close that darned bug
<wgrant> I suppose it's possible that I tweaked a config file somewhere years back.
<TheMuso> digistyl3: ah thats because it switched over to OSS output.
<TheMuso> digistyl3: mplayer that is. Alsa still borked.
<ogra> sladen, right, so wgrant's constant disk accesses that didnt happen in hardy are very unlikely related to hdparm at all
<ogra> err
<ogra> slangasek, ^^^
<slangasek> seems that way
<wgrant> ogra: DIsk accesses? Head parkings, you mean?
<calc> cough, i just noticed i need to update a package and the beta freeze is started, if i get it updated in the next couple hours would it be acceptable?
<TheMuso> digistyl3: thanks, I will have to do some further digging. Whats annoying is that I can't yet reproduce it here.
<calc> its lucene2
<TheMuso> digistyl3: What sound card are you using BTW?
<slangasek> calc: if it's freeze-appropriate, yes...
<digistyl3> TheMuso: yw, i'm using hda-intel on a dell studio 15
<digistyl3> TheMuso: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
<calc> slangasek: ok
<TheMuso> digistyl3: Ok thanks. I don't think it is card related, but its goot to know.
<bryce> slangasek: ha, I found this for thinkpad sleep issues (X60) - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407188
<ubottu> Debian bug 407188 in acpi-support "Laptop gets stuck after sleep" [Grave,Closed]
<digistyl3> TheMuso: if i can debug it somehow, i'll help :)
<bryce> slangasek: I wonder if that might help your sleep issue?
<TheMuso> digistyl3: Thanks but I am not sure where to go from here, still trying to gather data.
<slangasek> bryce: I don't have a reproducible sleep issue
<slangasek> just the sleep key issue
<TheMuso> digistyl3: what version of pulseaudio are you running BTW?
<bryce> slangasek: hmm ok
<ogra> wgrant, feel free to repoen bug 250938 ... seems thats related to your prob
<digistyl3> TheMuso: 0.9.10-2ubuntu6
<ubottu> Launchpad bug 250938 in acpi-support "acpi-support should let laptop-mode-tools run properly" [Undecided,Fix released] https://launchpad.net/bugs/250938
<TheMuso> digistyl3: Right, thanks.
<ogra> anyway, really bed time now
<wgrant> ogra: Thanks, I'll have a look.
<digistyl3> TheMuso: the funy part of this is that i hear those drums on the login window and also the login theme (the new one)
<digistyl3> is that OSS too?
<digistyl3> or alsa jams later?
<TheMuso> digistyl3: I am not sure yet, but I don't think it is anything specifically related to pulseaudio or alsa, but I don't know any more than that yet.
 * slangasek squints at libvlc2 Conflicts: libvlc1
<digistyl3> TheMuso: if you need me, just say my name, i'll be watching a film
<TheMuso> digistyl3: Sure. I can reproduce the problem with the sound test in the sound properties window, but not with mplayer.
<crimsun> TheMuso: it's an alsa-lib issue.
<TheMuso> crimsun: argh!
<crimsun> TheMuso: you should be able to reproduce using the following test cases:
<crimsun> 1) aplay -Dplughw:0 /usr/share/sounds/purple/send.wav
<crimsun> 2) aplay -Dhw:0 /usr/share/sounds/purple/send.wav
<crimsun> 3) aplay /usr/share/sounds/purple/send.wav
<TheMuso> crimsun: 1 works for me
<crimsun> I have pulse pcm+ctl active
<TheMuso> crimsun: 2 works for me
<TheMuso> crimsun: 3 eworks.
<crimsun> digistyl3: can you test the above 3 cases?
<TheMuso> in the case of 3, it is going through pulse
<crimsun> TheMuso: for me, (1) results in nondeterministic clipping, (2) results in no clipping but wrong sampling rate, (3) results in expected (no clipping, correct sampling rate)
<digistyl3> TheMuso: only case 3 isn't working for me
<crimsun> wow, ok, so it's not /just/ alsa-lib
<TheMuso> crimsun: oh right, yes the second gave me a sample rate warning
<digistyl3> but the ouput of 1 and 2 are different
<crimsun> digistyl3: (1) should be correct sampling rate, at least
<digistyl3> crimsun: yes, (1) works correctly without errors
<TheMuso> crimsun: yeah 1` is fine for me
<TheMuso> crimsun: confirmed on two machines to be the same for #1
<digistyl3> TheMuso: do you need the output of (3)?
<TheMuso> digistyl3: it may be useful
<crimsun> ok, away for dinner, but will be back in 10-15 minutes
<digistyl3> TheMuso: here it is http://pastebin.com/d8cf747
<ArneGoetje> Someone here familiar with libtool? libtoolize in intrepid seems to delete config.sub and config.guess from the working directory... a following ./configure can't find them anymore and the package FTBFS... libtoolize in hardy seems to leave them in place... regression?
<TheMuso> digistyl3: thanks
<digistyl3> np
<TheMuso> Ok to deepen the mystery, setting to alsa in gnome-sound-properties fails to play a test sound, but totem works no problems.
<bryce> slangasek: ok, fixed acpi-support is ready for upload
<bryce> slangasek: I went through the dozen or so patches listed for it in launchpad, and found a couple that looked safe enough to include
<slangasek> "looks safe, ship it"
<slangasek> upload, please :)
<bryce> okie doke
<bryce> its up
<digistyl3> bryce: can i test it? or will it be in the updates?
<StevenK> slangasek: So, I'd like to upload a new xterm that contains a .desktop file for Ubuntu MID. Would you like to see a debdiff?
<slangasek> StevenK: I'd like my eyes to uncross after having read the words "xterm" and ".desktop file" in the same sentence
<bryce> digistyl3: it'll be in the updates once slangasek is done reviewing it and scolding me for including too many whitespace changes ;-)
<slangasek> StevenK: are you serious?  A .desktop file for xterm?
<bryce> slangasek: fwiw I've reviewed StevenK's change and it looks ok to me
<calc> slangasek: it claims to be waiting for approval for lucene2
<StevenK> slangasek: Okay, so we use xterm as the terminal application for Ubuntu MID. mobile-basic-flash included a .desktop file for it which is the wrong place, and it went away after we dropped m-b-f for kourou.
<slangasek> calc: yep, I'll grab it in a bit, thanks
<calc> slangasek: thanks :)
<bryce> digistyl3: what sort of acpi stuff would you be interested in testing?
<bryce> there's more changes in the debian acpi-support package, but that I wouldn't want to include without some additional testing/review, so if you're keen to test acpi-support, I could roll a package with those specific things in for you to play with
<bryce> ooh, this fills one with confidence:
<bryce> <daniels> ...
<bryce>  hal is fucked.
<digistyl3> bryce: i wanted to see if those 90-hdparm.sh files work, but i could help testing other things as long as they don't damage my new laptop :D
<slangasek> bryce: this is... recent?
<bryce> slangasek: just now on #xorg-devel ;-)
<slangasek> awesome
<bryce> digistyl3: ok no worries.  I think we aim to eliminate acpi-support anyway in jaunty.
<digistyl3> bryce: why? is it old?
<digistyl3> what would replace it?
<bryce> digistyl3: yeah it's a ubuntu/debian specific thingee
<bryce> digistyl3: well that's the big question.  We'll have to get that answered in jaunty, hopefully at the next UDS
<bryce> probably some combination of pm-utils + hal + ??
<bryce> I'm thinking that maybe we start by just focusing on sleep/hibernate functionality, get any relevant quirks migrated to pm-utils/hal, but leave the remainder of acpi-support in place until we find better homes for them
<slangasek> sadly, I think this is the third release cycle now that I've heard that was supposed to be happening
<bryce> mm
<slangasek> i.e., sleep/hibernate was supposed to have been taken over long ago
<bryce> slangasek: well if we can come up with a plan, I don't mind putting a little time into it for jaunty.
<slangasek> yes; I understand this is an item on the UDS Jaunty agenda
<bryce> I seem to get tasked with fixing sleep and hotkey problems now and then, and I would love to get things cleaned up enough that the responsibility gets more appropriately targeted elsewhere ;-)
<slangasek> pitti: why does pykdeuic4 generate python files with a blank line ahead of the interpreter line? :)
<slangasek> pitti: (kdeui/ui_ManagerWindowKDE4.py in jockey)
<slangasek> james_w: bug #263888> <giggle>
<ubottu> Launchpad bug 263888 in acpid "acpid killed by default logrotate script" [Medium,Fix committed] https://launchpad.net/bugs/263888
<StevenK> slangasek: I've just uploaded a new linux-lpia-meta, this will give lpia installable kernels via the meta-packages.
<NCommander> hey StevenK
 * StevenK waves
<NCommander> How goes it StevenK
<StevenK> NCommander: Trying to get stuff sorted out for beta
<NCommander> StevenK, anything I can do to help?
<StevenK> NCommander: Not really, you're not a core-dev
<NCommander> :-/
<TheMuso> crimsun: I'm playing with alsa-lib, and gone so far back as alsa-lib 1.0.17 with no patches from git, and still get the same issue, so its nothing that has been introduced in the last little while, unless there is something in the pulse plugin thats causing issues.
<crimsun> TheMuso: are you using intrepid's pulseaudio?  I'm using your ppa's.
<TheMuso> crimsun: yes I am using pulse 0.9.10.
<TheMuso> crimsun: just tried alsa-plugins 1.0.17 without any of Lennart's fixes, and the gstreamer audio test in sound properties works again. Just going to try rhythmbox through pulse again, but it seems that one of Lennart's fixes breaks it somehow.
<TheMuso> crimsun: ok rhythmbox is fine, so gstreamer is behaving now, at least for me.
<TheMuso> git bisect time.
<Hobbsee> TheMuso: ping?
<Hobbsee> TheMuso: are my audio settings supposed to be set as alsa, now, and not pulse?
<TheMuso> Hobbsee: No, leave as pulse.
<TheMuso> Hobbsee: the issue that is being debugged is to do with the alsa pulse plugin, which happens to cause gstreamer apps to die. I'm looking into it. The gstreamer pulse plugin is fine though, but nevertheless this needs to be sorted.
<Hobbsee> TheMuso: well, they were magically set as alsa yesterday.  Maybe the gnome update, i'm not usre.  Have you had similar issues reported?
<TheMuso> Hobbsee: Yes, look at the backscroll for one, and a private message as well as a bug report comment, so I'm on it.
<TheMuso> Hobbsee: as for changing to alsa thats weird.
<TheMuso> it should be set to autodetect.
<Hobbsee> TheMuso: right.
 * Hobbsee hasn't checked backscroll adn such yet, sorry.
<TheMuso> thats ok.
<Hobbsee> ah, we are frozen now.
 * beuno stays very still
<Hobbsee> just when my thunderbird explodes.
<persia> Hobbsee: freeze doesn't mean "Don't fix anything", it means "only fix *really* broken stuff, and test *lots*".
<Hobbsee> persia: well, it means accepting uploads, too.
<Hobbsee> persia: but that's true.
<Hobbsee> persia: id' have been interesting in seeing what the freeze mail says, but it seems that'll take longer :)
<persia> Hobbsee: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-September/000491.html
<Hobbsee> ah, rihgt, cool.
<crimsun> TheMuso: I still can't reproduce that symptom
 * Hobbsee was going with the lazyness option.
<Hobbsee> (ie, not looking up webmail)
<TheMuso> crimsun: Hrm.
<TheMuso> crimsun: Bisecting Lennart's tree is giving me some unusual behavior, compared to the actual alsa-=plugins ackage in the archive as well. I think I need to start with a clean slate and go from there.
<crimsun> TheMuso: I noticed yesterday that there seemed to be missing commits between intrepid's base alsa-plugins and what lennart's tree has
<crimsun> I didn't chase it, because it was getting late
<TheMuso> crimsun: I think he may have merged them in.
<TheMuso> as of yesterrday.
<TheMuso> crimsun: I think I have found the commit that breaks things. The reason why you can't reproduce is because you are using 0.9.12, which supports S32 sample types. 0.9.10 doesn't, and the latest code for the pulse plugin allows using S32 sample types. For some reason, this is breaking gstreamer's access to alsa via the pulse plugin.
<TheMuso> So I've tested the reversion of that commit, and all seems to work again.
<crimsun> TheMuso: I'm using 0.9.10 now, though.
<TheMuso> crimsun: ah.
<crimsun> however, I certainly agree with reverting that commit
<TheMuso> crimsun: so you are able to get a test sound when attempting to test audio inside gnome-sound-properties when the setting is set to the alsa sink
<TheMuso> ?
<crimsun> let me test that.
<TheMuso> crimsun: For me the problem manifests itself in different ways depending on the machine. On one machine with intel8x0, rhythmbox and the sound test in gnome-sound-properties both don't work. On a machine with hda-intel, only the sound test doesn't work.
<crimsun> no, I get a GSt pipeline error on an HDA Conexant
<TheMuso> In my above tests, with intel8x0, totem also works.
<TheMuso> and with hda-intel
<TheMuso> digistyl3: Do you happen to still be around?
<TheMuso> crimsun: Going to get some further feedback from others who experienced this before settling for that as the problem, but I am confident the issue has been found.
<wgrant> What's the issue being debugged here?
<wgrant> I just downgraded to PA 0.9.10, and things hang...
<TheMuso> wgrant: Basically when gstreamer apps tried to use pulseaudio via the alsa pulseaudio polugin, they would bomb with an error.
<TheMuso> wgrant: try this package here: http://www.themuso.id.au/ubuntu/alsa-plugins
<wgrant> (0.9.12 seemed to work fine apart from some SDL strangeness)
 * wgrant tries.
<crimsun> TheMuso: confirmed to fix the GSt pipeline error in sound properties testing when set to ALSA w/ pulse pcm+ctl plugin active
<TheMuso> crimsun: Ok thats good. Does that solve any of those aplay test cases you mentioned earlier?
<wgrant> TheMuso: gnome-sound-properties and Rhythmbox still hang, not sure about the others.
<crimsun> TheMuso: no, but they shouldn't be considered regressions here, as they're fragment-specific for HDA
<TheMuso> crimsun: Right.
<TheMuso> wgrant: Did you log out/back in after you downgraded? I think you might still have to do that for some reason.
<wgrant> TheMuso: I did, but that didn't work so I rebooted.
<TheMuso> Hrm. What do you have set as your sink in gnome-sound-properties?
<wgrant> TheMuso: When testing in g-s-p: OSS works, ALSA makes a click and then aborts, PulseAudio looks like it's working but doesn't play anything, and hangs when you click OK.
<wgrant> Hm, bad stuff in syslog.
<wgrant> Sep 26 14:10:05 irranat pulseaudio[6655]: shm.c: Invalid shared memory segment size
<wgrant> Sep 26 14:10:05 irranat pulseaudio[6655]: pstream.c: Failed to import memory block.
<TheMuso> hrm.
<TheMuso> wgrant: Try killing pulse, clearing any .pulse* files from your home dir, and restarting pulse. Easiest way to restart pulse is "pulseaudio -D --log-target=syslog"
<TheMuso> There are differences between 0.9.11/12 and 0.9.10 in terms of what gets put in the home dir.
<wgrant> TheMuso: Same thing...
<TheMuso> crimsun: any ideas?
<TheMuso> because I'm fresh out currently.
<crimsun> wgrant: with 0.9.10-2ubuntu6?
<crimsun> of pulseaudio* and libpulse*, sorry
<wgrant> crimsun: Looks that way.
<wgrant> Hmm. paplay works.
 * wgrant restarts pulseaudio a few more times for good measure.
<crimsun> in g-s-p, what behaviour when you set playback to Autodetect?
<wgrant> It... works.
<wgrant> Hrnnnng. ALSA and Pulse work directly too.
<TheMuso> The only thing I can think of is that a pulse package is out of version sync, maybe one of the modules, or one of the libs.
<wgrant> So something has unbroken itself.
<wgrant> Maybe there was some lib loaded that still knew about the 0.9.12 ~/.pulse* stuff.
<digistyl3> TheMuso: yes i am
<TheMuso> digistyl3: Could you please try http://www.themuso.id.au/ubuntu/alsa-plugins again and let me know if mplayer and gstreamer stuff works again?
<digistyl3> sure
<digistyl3> TheMuso: do i need a reboot? because it isn't working yet
<crimsun> you shouldn't need to reboot; closing all audio apps should suffice.  However, rebooting tends to be a "safer bet".
<digistyl3> ok, i'll brb
 * Hobbsee declares victory over evil email.
<Hobbsee> bah.  or not
<TheMuso> heh
<digistyl3> TheMuso: it isn't workinh
<TheMuso> digistyl3: Are you trying mplayer, or a gstreamer app? What do you have set as your output in gnome-sound-properties?
<digistyl3> TheMuso: audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Failed to connect stream: Invalid argument
<digistyl3> mplayer works as it falls back to oss
<digistyl3> totem doesn't
<TheMuso> digistyl3: Did you download the package for your arch from that URL?
<digistyl3> TheMuso: yes i did
<digistyl3> the one last modified on: 26-Sep-2008 11:52
<TheMuso> digistyl3: And that is with alsa as the output?
<digistyl3> TheMuso: yes, i get the same errors
<TheMuso> digistyl3: What about set to pulse?
<digistyl3> the same
<TheMuso> ok.
<digistyl3> totem sais:
<digistyl3> ** Message: Error: Failed to connect stream: Invalid argument
<digistyl3> pulsesink.c(487): gst_pulsesink_prepare (): /play/visbin/abin/audiosinkbin/audio-sink/bin6/autoaudiosink1/autoaudiosink1-actual-sink-pulse
<digistyl3> isn't this related to the pulseaudio plugin?
<TheMuso> yse it is so its something else.
<TheMuso> digistyl3: go to a terminal, and kill pulseaudio, "pulseaudio -i"
<TheMuso> them delete .pulse* from your home directory.
<TheMuso> re-run pulseaudio with "pulseaudio -D --log-target=syslog"
<TheMuso> then try again.
<digistyl3> TheMuso: pulseaudio: invalid option -- 'i'
<TheMuso> sorry meant -k
<digistyl3> TheMuso: it's working now :)
<TheMuso> Great.
<TheMuso> Tr with alsa in gnome-sound-properties, just to be sure.
<TheMuso> try
<TheMuso> goodness my typing is bad this afternoon.
<digistyl3> yep, it's working alright :)
<TheMuso> Ok great, thanks for your help. I'll get that fix into intrepid as soon as I have a bit more feedback.
<TheMuso> digistyl3: Oh if you could pastebin mplayer output again, that would be appreciated, just want to make sure it works as it should.
<digistyl3> i'm glad i could help :)
<digistyl3> TheMuso: the output with the fixed version installed?
<TheMuso> digistyl3: Yes please.
<digistyl3> TheMuso: here it is http://pastebin.com/d38e61579
<TheMuso> digistyl3: Great, thats all. Thanks again.
<digistyl3> np :)
 * digistyl3 back to watching movies :)
<dholbach> good morning
<elmo> bryce/cjwatson: for the record, that's not what I asked.  I asked that you not give automated processes full access to your canonical accounts.  I suggested several alternatives; there was no need for you to migrate scripts off, it was your choice
<dholbach> slangasek (or any other release team member): I uploaded gnome-system-tools (new upstream release, new translations, added a patch we carried in our old version before) - can you accept it?
<digistyl3> dholbach: does it contain a fix for remembering the current session in gnome?
<dholbach> digistyl3: not AFAIK
<bryce> elmo, sorry I didn't mean to misrepresent what you'd told me...
<bryce> elmo: but the alternative you suggested was to not use scp, but rather to fetch from rookery via http
<bryce> so I took that to mean that you do not want automated scripts scp'ing stuff to people.ubuntu.com
<bryce> elmo: also, fetching stuff via http implies I have a webserver up on my end with the files already hosted there, so it ends up being simpler to just move the whole kit there
<bryce> elmo: if you offered other alternatives, sorry, I must have missed them
<slangasek> Riddell: hmm, your upload of kdebase-workspace is rather opaque to review; no bug referenced in the changelog, and the only diff is to disable a patch, but it's not obvious what that patch does :)
<slangasek> bryce: scp isn't really possible to restrict, IIRC; but there are ways to push files up not using scp, e.g., streaming tar + a helper script on the remote side + a restricted ssh key
<slangasek> dholbach: will get it, but it's first-come, first-served :)
<dholbach> no problem
<dholbach> I'm going to be around a little bit longer ;-)
<bryce> slangasek: streaming in what way?
<slangasek> bryce: tar zcvf - | ssh host [...]
<slangasek> well, probably without the v, sorry for my reflex :)
<bryce> hmm, I dunno, it sounds a bit hackish
<bryce> slangasek: however thanks, I didn't realize you could copy files across like that
 * StevenK throws more packages at unapproved
<slangasek> it's not as simple as just doing scp, no, but it's e.g., what I use to avoid giving unsupervised scripts access to Debian servers for doing debian-installe daily builds
<siretart> morning
<siretart> pitti: tjaalton: I remember you've been talking about hotkey cleanups the last days. since yesterday some hotkeys on my X60s have stopped working. are you aware of a bug or issue that might cause this?
<sbeattie> slangasek: is there some problem with the live cd builds? The newest on cdimages is 3 days old/
 * persia broke it.  It was fixed earlier today
<persia> (or last night, depending on your current longitude)
<tjaalton> siretart: only thing that might have something to do with it is the new acpi-support
<tjaalton> siretart: what laptop?
<siretart> tjaalton: thinkpad X60s
<bryce> tjaalton: any reason other than the timing of the update?
<tjaalton> bryce: right, it's the only component that has been updated recently
<tjaalton> but i'm still sceptical about how much a-s matters on thinkpads
<bryce> siretart: well you can try downgrading to 0.110 or earlier and see if it makes any difference
<tjaalton> bbiab ->
<pitti> Good morning
<pitti> kwwii: thanks
<pitti> slangasek: consolekit crasher bug? any #?
<pitti> Jonbo: sure, if you have one
<slangasek> pitti: bug #263245
<ubottu> Launchpad bug 263245 in consolekit "console-kit-daemon crashed with SIGSEGV in fclose()" [Medium,Confirmed] https://launchpad.net/bugs/263245
<pitti> slangasek: pykdeuic4> no idea TBH; I mean, for those .py files a shebang line doesn't even make sense...
<pitti> siretart: I think the cause might be the recent acpi-support merge
<pitti> siretart: for reference maybe you could downgrade this again and test again?
<bryce> pitti, any particular reason you think it might be acip-support, aside from the timing of the upload?
<pitti> siretart: there is another proposed fix in bug 267682 (the .fdi file)
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,In progress] https://launchpad.net/bugs/267682
<pitti> bryce: no, just by the time of the upload; I don't think that tjaalton uploaded the -evdev fdi file yet? at least not yesterday?
<pitti> slangasek: haven't seen it so far, but I'll take this one; CK crashes are eww
<sbeh> hi, "localedef --no-archive --magic=20051014 -i en_US -c -f UTF-8  en_US.UTF-8" hangs at 100% cpu reproducable and "strace -p `pidof  localedef`" gives no output, what can i do to determine whats  causing this problem?
<mdke> dholbach: thanks for the gnome-user-docs upload yesterday, I've merged your branch. Could you perhaps do another one at some stage? I've merged from upstream this morning: some new material and translations
<tjaalton> pitti: what about adding/merging the fdi file to hal-info?
<dholbach> mdke: sure
<pitti> tjaalton: we can do that as well, but if it's a workaround and not something to be committed upstream, and the knowledge about changing it is mostly in -evdev, why not ship it in -evdev?
<dholbach> hi mvo, hi pitti!
<mdke> dholbach: thanks!
<tjaalton> pitti: evdev has no fdi file
<tjaalton> pitti: the magic is in hal
<pitti> tjaalton: if you don't want it there, I'd rather put it into hal; hal-info is the wrong place fo rit
<tjaalton> pitti: ok, hal it is then :)
<siretart> pitti: I have a meeting now, can only test this afternoon. besides, is there an deb version 110 somewhere available or shall I rebuild the package myself?
<tjaalton> siretart: I have an X61 and things work like before even with all the updates
<siretart> tjaalton: on my x60s, xev doesn't show my anything when I press fn-f4 e.g.
<pitti> tjaalton: "has no fdi file"> yes, it could just ship it; but as I said, if you don't like that for some reason, we can put it into hal, too
<tjaalton> siretart: that's normal
<pitti> tjaalton: my concern about this is that it would break backportability of the hal package
<siretart> well, gnome hotkey settings dialog doesn't detect the keystroke either
<mvo> hey dholbach!
<tjaalton> pitti: oh, ok
<pitti> tjaalton: (same reason for hal-info, which is why I really don't like it there)
<tjaalton> siretart: same thing, it shouldn't (and never has) :)
<mdke> hi mvo: I sent you an email a while about whether there were any disadvantage to using apturl instructions in the Ubuntu help wiki, have you had a chance to consider it?
<pitti> siretart: 0.109 is in hardy, that should work well enough, too
<pitti> siretart: otherwise 0.110 should be a quick build (but it only fixes laptop-mode, no keys)
<siretart> kk
<mvo> mdke: oh, right. sorry that I have not ansered yet. the only disadvantage that I can see is a the "do not teach people to install software from the web" argument. but apturl itself is fine (as it just uses the stuff from the repository)
<mdke> mvo: is it possible to use it to give an instruction to install a non-repository package (like a ppa, or external repository)?
<mvo> mdke: not eaisly, the feature to add repos is disabled because it seems to risky
<mvo> mdke: so the user needs to add the repository first in some way, than apturl will work with the packages in that repo too
<mdke> mvo: ok, good. So it seems pretty safe to use it on a user-editable wiki
<mvo> yes
<mdke> I'd really like to use it in yelp too, I have to see if that works
<mdke> mvo: ok, thanks for your help
<mvo> I added a gnome url handler for it, let me know if there are issues, then I have a second look
<mvo> thank you!
<mdke> ah, cool
<StevenK> pitti, slangasek: Could either one of you be tempted to prod through my uploads? :-)
<pitti> StevenK: slangasek will regularly do that, or ask me for assistance; don't worry, they won't go ignored :)
<StevenK> pitti: I could probably do it, but I didn't want to get my hand slapped :-)
<dholbach> mdke: uploading, it will sit in the queue for a bit
<mvo> Riddell: thanks for your test with kubuntu-kde4-desktop, I look into it
<amitk> asac: do you already know about the erratic scrolling behaviour in firefox?
<asac> erratic?
<asac> amitk: ?
 * directhex finds it ironic that he experienced erratic scrolling behaviour in xchat when reading the last 3 lines
<asac> amitk: ah yeah. thats cairo but also boils down - at least a good part of it - to the driver situation we have
<PecisDarbs> I am sorry to say that, but NM is still terribly broken when doing manual configuration of *anything*
<amitk> asac: driver?
<asac> PecisDarbs: what exactly do you mean by manual configuration? static ips?
<mvo> Riddell: do we have a open bug about the kde->kde4 upgrade behavior?
<asac> amitk: i think X driver is the better description
<PecisDarbs> asac: yep
<asac> amitk: at least there appear to be quite a substantial performance difference depending on what kind of driver and accellmethod you are using
<asac> PecisDarbs: i never had problems witht hat
<PecisDarbs> asac: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/256054
<ubottu> Launchpad bug 256054 in network-manager "[intrepid] new 0.7 branch ignores /etc/network/interfaces" [Unknown,Confirmed]
<PecisDarbs> when I do manual configuration via NM, it doesn't activate interface
<asac> PecisDarbs: what has that to do with that bug?
<PecisDarbs> ok, maybe not directly
<asac> (sorry i should get a copy ;))
<asac> err coffee
<PecisDarbs> :)
<amitk> asac: PgDn scrolling not working is also part of this problem?
<asac> amitk: not working completely?
<PecisDarbs> asac: problem is that leaving NM as only opinion to configure net on Ibex is huge regression so far. I hope situation will improve.
<asac> amitk: or slow?
<mvo> tkamppeter: I just got this here in a hardy chroot: http://paste.ubuntu.com/50774/ <- (line 6 is the ps output that seem to have triggered it). why is it doing that?
<StevenK> Mithrandir: Launchpad keeps bugging me about my memership in bluetooth and telepathy expiring, can you fix it or make me an admin?
<StevenK> s/memership/membership/
<asac> PecisDarbs: please describe me the exact steps you take
<asac> PecisDarbs: most likely you right click on applet and select "connection editor ..." ... what next?
<PecisDarbs> asac: 1) boot Ibex (fresh install, sunday/monday) 2) login 3) click on nm-applet icon with right button 4) Edit Connections...
<amitk> asac: it works for 1 page down and then doesn't work at all. Sometimes it goes back and forth on current and next page producing a cool effect but no scrolling :-/
<asac> amitk: that started with latest update?
<Mithrandir> StevenK: I'll fix it.
<PecisDarbs> asac: 5) Wired tab 6) Auto eth0, Edit 7) put in manual mode, provide IP and press OK 8) open Terminal and ifconfig - nothing has changed
<asac> PecisDarbs: yes. dont do that ;) ...
<asac> PecisDarbs: create a "new" connection for now
<PecisDarbs> asac: wtf?
<asac> PecisDarbs: editing auto eth0 isnt workding
<PecisDarbs> why?
<amitk> asac: No, with 3.0.2+build6+nobinonly-0ubuntu2. I have to upgrade to 3.0.3 now.
<asac> amitk: ok. but it started with 3.0.1?
<PecisDarbs> NM configuration is very lame so far, and is step backwards from network-admin. I tried to love it. We need new network-admin, for sure, but NM so far is no cut.
<asac> err .2
<tkamppeter> mvo, this is really strange. A package install process always runs as root, so lpadmin always should be able to create print queues without asking for a password. It even recognizes that it runs as root, as it asks for the root password.
<asac> PecisDarbs: i didnt hear productive suggestions from you so far. only that nothing works
<amitk> asac: yes
<asac> PecisDarbs: try how it works with "new" connection
<tkamppeter> mvo, pitti, what is the state of cups-pdf, did we not drop it from the seeds?
<pitti> tkamppeter: we did, it's in universe now
<mvo> tkamppeter: it happens in a hardy chroot, I was just pretty puzzled when I saw the prompt
<mvo> (with kubuntu-kde4)
<asac> PecisDarbs: and comment based on that experience. there are still bugs, yes. but most should be sorted for final
<PecisDarbs> asac: productive suggestion would be to put network-admin back in default, but you guys already have decided on that. No offense, but this really have ticked me off a little bit off.
<tkamppeter> mvo, the lpadmin in post-install worked for me all the time without problems (but I have tested only on the GNOMEy standard edition)
<Gast_314_> http://www.meine-privaten-nacktvideos.net?id=4812552
<asac> PecisDarbs: network-admin never worked together with NM ... it just pretended that it did
<PecisDarbs> asac: thanks for a tip
<PecisDarbs> asac: and? that is not a reason to drop one app or another.
<asac> PecisDarbs: those applciations conflict.
<PecisDarbs> asac: NM configuration is a very different is very anti-GNOME-ish
<tkamppeter> Who does not understand german, the URL posted by the guest is spam
<PecisDarbs> asac: yes, then someone should make them work together :)
<PecisDarbs> ok
<asac> PecisDarbs: no. NM should be improved
<mvo> tkamppeter: ok, might be some fluke on my local system or something
<asac> PecisDarbs: but btw, in some way we are working on making that happen (by implementing the ifupdown plugin)
<Mithrandir> StevenK: you're an admin on both teams already AFAICT?
<asac> PecisDarbs: but its not the primary motivation for that to get network-admin back
<PecisDarbs> asac: another reason why I want network-admin because it was so much easier to use. Simple as that.
<PecisDarbs> ok
<StevenK> Mithrandir: Then why is LP telling me to bug you? It's odd ...
<asac> PecisDarbs: i would appreciate if you could give detailed info on what aspects dont work as you want
<asac> PecisDarbs: easier to use -> make suggestions how to improve that in NM
<PecisDarbs> asac: there is no profiles
<Mithrandir> StevenK: no idea.  Can you edit yourself in the list?  I
<Mithrandir> 'm happy to extend your membership, obviously
<asac> PecisDarbs: the idea is that you dont need profiles anymore
<StevenK> Mithrandir: I'll fiddle in a sec
<PecisDarbs> asac: really, what do you use then? :)
<asac> PecisDarbs: we probably cannot introduce profiles, but we could look into what exact use-cases you previously covered with profiles and see if we can make those coevered
 * PecisDarbs sights
<asac> PecisDarbs: what use-cases did you covere with profiles?
<PecisDarbs> asac: it is reason why people hate changing functionality - if it works, don't fix!
<PecisDarbs> asac: laptop, changing networks three times a day
<PecisDarbs> everytime totally different configuration
<PecisDarbs> network-admin did it with ease
<PecisDarbs> three clicks and I was set
<asac> PecisDarbs: in which sense?
<asac> PecisDarbs: what is network config 1 and what is network config 2?
<asac> give me an example ;)
<PecisDarbs> ok
<PecisDarbs> dhcp and manual with different DNS settings
<asac> PecisDarbs: that should be at least as simple as with network-admin. you create two connections: one with dhcp the other with manual
<asac> when you are at place with dhcp you click on that connection in the applet ... otherwise on the other place
<PecisDarbs> asac: and then?
<asac> there is even some magic going on if you have both set to "connect automatically"
<asac> PecisDarbs: how is that worse than network-admin?
<PecisDarbs> asac: ok, I will evaluate that. This is very different, I must say, but ok, maybe I am too harsh without knowing it better
<mvo> Riddell: update-manager (in bzr) should be fixed for kubuntu-kde4-desktop
<asac> PecisDarbs: well. i think with some luck and the magic you might not even need to click anything anymore.
<asac> PecisDarbs: so in best case everything will happen automatically when you plugin your system at different places. in worst case you have to do one click
<PecisDarbs> ok :)
<PecisDarbs> asac: anyway, this change from network-admin to NM should be noted, because user will expect old app to be in tradional place.
<asac> PecisDarbs: we could put "connection editor" in the system -> administration menu
<PecisDarbs> asac: that would do the trick
<asac> would that help?
<asac> ok. noted.
<PecisDarbs> asac: definitely
<asac> amitk: sorry. i forgot about you ;) ... do you have any extensions installed?
<PecisDarbs> asac: thanks for listening, I will give NM another shot, maybe it is really good as you tell. Maybe there only should be way for users to avoid editing "Auto eth0" profile as I did. And is there any way to configure simple modem or bluetooth modem on NM? I couldn't find it.
<amitk> asac: np. Yes I have extensions - Adblock plus, Google notebook, firegpg, ubuntu firefox modifications
<asac> amitk: please try to disable a bunch and see if things improve
<asac> PecisDarbs: yeah. nm-applet didnt have any UI mean to present read-only connections. this has been fixed on trunk from what i can tell
<PecisDarbs> ok, it is being worked on. Nice.
<PecisDarbs> asac: about modem connections?
<tjaalton> pitti: I've got a new xorg-server waiting which fixes bug 261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [High,Confirmed] https://launchpad.net/bugs/261977
<asac> PecisDarbs: you are actually the first asking that.
<asac> PecisDarbs: which is strange when thinking about it ;)
<asac> PecisDarbs: NM supports Mobile Broadband modems and PPPOE/DSL
<directhex> will intrepid's kernel contain any of the latest git stuff to support the latest intel wifi cards?
<asac> PecisDarbs: i cannot tell out of the head why modems dont work. but there probably is a good (even though technical) reason
<asac> PecisDarbs: i will find out
<PecisDarbs> asac: thanks in advance
 * mvo is supprised that python3.0 is priority required
<mvo> well, python3.0-minimal
<lool> Sounds a bit early for that
<lool> mvo: Do you know what the python3 meta is for?
<mvo> no
<lool> It's to point at the latest python3.x when python it's a python3?
<mvo> update-manager will pull in python3.0-minimal on upgrades because of the priority
<DktrKranz> pitti, when you have time to put your ubuntu-sru hat on, mind reviewing bug 207406? It causes a couple of segfaults in xvidcap in Hardy, I tested it and it no longer fails with that patch applied.
<ubottu> Launchpad bug 207406 in ffmpeg "xvidcap crashed with SIGSEGV in avcodec_open()" [High,Fix released] https://launchpad.net/bugs/207406
<cjwatson> mvo: I'll fix that
<mvo> thanks Chipzz
<mvo> thanks cjwatson
<cjwatson> done for next publisher run
<Chipzz> mvo: typo? :)
<mvo> Chipzz: yes :) tab-completion to quick
<Chipzz> hehe :)
<Chipzz> happens :)
<cjwatson> persia: I don't think you broke the live CD builds - that's a separate problem
<persia> cjwatson: Oh.  I thought me breaking germinate was what broke the live CD builds.  Thanks for easing my guilt.
<ogra> eeek, whats up with vitrualbox ?
<ogra> it asks me for registration ... and now hangs
<ogra> oh, doesnt hang
<ogra> fun
<ogra> a popunder behind the registration window
<seb128> slangasek: I've uploaded a bug-buddy update which make bug-buddy not run by default so apport can catch the gtk applications crashes again if you want to accept the upload (not sure if you look through the queue or want to be pinged on IRC)
<shingara> Hi
<shingara> I search a guide where the policy of package nomming is write ?
<mpt> nomming?
 * wgrant takes a bite out of mpt.
<mpt> nom nom nom
<mpt> oh, naming?
<wgrant> Ahh, maybe.
<shingara> namming
<shingara> sorry for my english
<wgrant> It really depends on the type of package.
<shingara> yes, but there are a policy
<shingara> a guide about that ?
 * mpt finds http://oreilly.com/catalog/debian/chapter/book/appc_01.html#DAPPC-PGFID-945614
<shingara> because I want separate the package name, original version name and the ubuntu specific name
<wgrant> Oh.
<wgrant> Not the kind of naming that I was thinking of, but mpt has it right.
<shingara> yes mpt but I have example like rdesktop : rdesktop-1.5.0-3+cvs20071006ubuntu0.1
<wgrant> That's a very strange (and likely incorrect) version string.
<shingara> yes but exist
<wgrant> rdesktop_1.5.0+cvs20071006-3ubuntu0.1, perhaps.
<wgrant> Where?
<wgrant> Erm.
<wgrant> Indeed.
<wgrant> Ummm.
<shingara> USN 646-1
<shingara> Ubuntu 8.04
<wgrant> Right, I see it.
<wgrant> Now to work out how such an abomination came about.
<shingara> So I suppose that all origin version and patchlevel ubuntu are separate by -
<shingara> but I don't know if there are - in patchlevel too :(
<shingara> /^.+-(.+)-(.+)/
<shingara> send me $1 original version and $2 patchlevel specific unbutu ?
<wgrant> Versions generally only have one -
<shingara> /^.+-(.+)-(.+)$/
<wgrant> Anything before the final - is the original upstream version number.
<wgrant> Anything after is the Debian/Ubuntu bit.
<shingara> ok, thanks :)
<Riddell> mvo: dist upgrade tool seems to do the job now for kubuntu-kde4-desktop
<Riddell> mvo: are you going to upload?
<mvo> Riddell: I'm in the middle of adding the fglrx detection/removal code currently, but after that I will
<Riddell> groovy
<mvo> Riddell: if you want it in asap, then just upload the current version with my fixes, but I should get a new version uploaded before the weekend
<asac> hmmm ... anyone has a interfaces configuration with _mutliple_ _wep_ keys?
<Riddell> that's fine
<directhex> asac, can you do that?
<asac> directhex: i think you can do everything that iwconfig key ... offers: http://paste.ubuntu.com/50819/
<asac> wonder if a) thats really the case and b) if anyone uses such kind of setup
 * directhex deploys double-rot13 encryption
 * Spads deploys quadruple-rot13 encryption
<directhex> damn, beaten by Spads
<shingara> I found another exception :(
<shingara> ia32-sun-java5-bin-1.5.0-15-0ubuntu1
<shingara> there are no really convention :(
<persia> shingara: the exact regex used can be found in the dpkg source.  Generally it's of the form (.*)-([^-]*)
<cjwatson> shingara: I'm struggling to work out what your point is, or what you're actually trying to find out
<cjwatson> shingara: version numbers are to some extent arbitrary, but there *are* rules that govern their use
<cjwatson> however you aren't going to work them out just by staring at several examples
<directhex> fail. ia32-sun-java5-bin_1.5.0-15-0ubuntu1 - note the all-important underscore
<directhex> package name ia32-sun-java5-bin, version 1.5.0-15, debian version 0 (i.e. non-existent), ubuntu version 1
<directhex> blame sun for the unhelpful version number for update15
<persia> A question about seeding: in ubuntu-mid there's a recommends chain that is unwanted, but it is sensible to keep the package recommends (in this case, ubuntu-mid is the exceptional case mentioned in policy).  Would adding a blacklist for the recommended package starting the chain be the correct way to resolve this?
<cjwatson> never use blacklists, to a first approximation
<cjwatson> I have only ever seen one legitimate use
<cjwatson> persia: what's the package in question?
<persia> OK.  Here's the specifics.  ubuntu-mid wants to use thunar.  thunar recommends xfce4-panel.  The thunar trash applet needs xfce4-panel, but isn't displayed in the hildon environment.
<persia> So, while thunar *should* recommend xfce4-panel (until some future time when the package is split), ubuntu-mid doesn't want xfce4-panel.
<cjwatson> we really don't have a particularly good way to express that
<cjwatson> a blacklist isn't *correct*, although in this case it wouldn't be too harmful
<persia> That's what I thought from the documentation.
<cjwatson> you see, the problem with blacklists is that if something depends on that package in the future, then germinate will just leave it uninstallable rather than doing anything sensible
<cjwatson> the correct solution here sounds like splitting the package, but go ahead and use a blacklist if that isn't an option
<persia> Ah, right, because it generates an unresolved conflict.
<cjwatson> and add a comment about why it's there
<persia> At this point in the cycle, I'm not tempted to ask Xubuntu to split such a critical package, but it may be possible for jaunty.
<persia> cjwatson: Thank you.
<pitti> tjaalton: ah, I'll have a look at the queue again soon
<pitti> DktrKranz: looks good to me
<pitti> mvo: did you see the verification-failed in bug 220890?
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,In progress] https://launchpad.net/bugs/220890
<mvo> pitti: yes, I haven't looked deeper into it though (no time yet)
<mvo> pitti: do you happen to know if we have a porters team or something that I can get quick feedback from for patches?
<pitti> mvo: ok, I'm just not sure whether it is a regression which should block -updates propagation, or just "not fixed yet" and thus just keeping open
<pitti> mvo: lamont perhaps?
<mvo> pitti: the upload was mainly about the powerpc regression (but it fixes another crash too) so I would say keep out of -updates for now and get a new version for -proposed
<pitti> bryce, tjaalton: argh, it did it again; since Tuesday or so I suddently get a completely white or black screen (X and apps keep running, though), which can only be fixed with a reboot; happens about three times a day; I never had that before, did you get similar reports about that?
<tjaalton> pitti: no.. what hardware?
<pitti> bryce, tjaalton: Xorg.0.log has tons of "pipe A underflow" messages, could that be relevant? I didn't see anything other log-ish
<pitti> tjaalton: Intel GMA945
<tjaalton> pitti: and that's with compiz?
<pitti> tjaalton: yes, it is
<pitti> but I have run compiz for some weeks again now
<tjaalton> sounds mesa-ish
<tjaalton> damn stable releases ;)
<Treenaks> tjaalton: At least it's not logging a DDC probe every few minutes, like my radeon driver :)
<pitti> tjaalton: hm, last mesa was uploaded Wednesday evening; the problems started before that
<tjaalton> Treenaks: that shouldn't happen anymore with a recent libgtk ;)
<tjaalton> pitti: oh, phew
<Treenaks> tjaalton: ah, so that's the problem :)
<pitti> tjaalton: latest -intel changelog looks unrelated to my hardware, too, but I could try downgrading
<tjaalton> pitti: nah, that can't be it.. the newer compiz maybe?
<pitti> tjaalton: well, hm, maaaybe it was Wednesday, too, I'm not really sure TBH
<pitti> tjaalton: last upload was last week, I extensively used that box with that version
<pitti> tjaalton: ^ compiz
<pitti> tjaalton: I think I'll try to downgrade mesa and test
<tjaalton> pitti: maybe a good idea
<tjaalton> lunch->
<pitti> tjaalton: do you know if the pipe-A log could be related?
<pitti> tjaalton: ah, enjoy
<tjaalton> damn Friday.. forgot that restaurants close at 1500
<tjaalton> pitti: it might. if you can monitor the log remotely (via ssh) and check if the messages correlate with the crash
<pitti> tjaalton: VT1 still works, so I can look at it
<pitti> tjaalton: I have it tail -f'ed right now
<pitti> tjaalton: wow, they *close* at 15:00? I mean, if people go out to restaurants, then certainly on Fri/Sat evenings?
<Koon> pitti: it's evening at 15:00 in Finland in winter :)
<liw> I suspect tjaalton is talking about lunch restaurants, 11-14 is the official lunchtime in Finland
<pitti> tjaalton: is there a way to enable timestamps in Xorg.0.log, btw?
<tjaalton> pitti: well, "restaurant" was maybe an exxageration, "canteen" might be more accurate :)
<tjaalton> s/exxa/exag/
<tjaalton> liw: right, Alvari ftl
<mvo> Riddell: I think the current bzr is good for upload of update-manager, if its not too much hazzle for you, I would appricate if you could give it a test-run. I'm running tests here as well and if all is well I upload in a bit
<liw> tjaalton, indeed; I don't have fond memories of it from my time in Otaniemi :)
<tjaalton> pitti: ok, so it doesn't really crash? you can shut down X from the VT?
<pitti> tjaalton: yes, apps keep running, X keeps running; the screen just goes black (I still see the cursor) or completely white (nothing visible any more)
<tjaalton> liw: heh, well it has become quite decent actually, but can't understand why they (too) close so early. mon-thu they are open ->1700
<pitti> tjaalton: it's not the screensaver, I already killed that; and killing everything and restarting X doesn't help, I need to reboot
<pitti> tjaalton: it seems like it puts and leaves the graphics card in a bad state?
<tjaalton> pitti: ok then.. try an older kernel :)
<tjaalton> although the changelog doesn't seem to contain anything related..
<pitti> tjaalton: I could try -3, yes
<pitti> tjaalton: I'll watch this step by step, watching the log for pipe-A, trying older mesa, trying older kernel; thanks so far!
<pitti> I guess each step takes a day or two :/
<tjaalton> pitti: great, np
<pitti> seb128: do the system monitor panel applets still work for you? I just restarted my session, and now I just have a thin horizontal bar instead of the gauges
<seb128> pitti: that's happens every now and then, the bug is not new
<seb128> pitti: bug #24243
<ubottu> Launchpad bug 24243 in gnome-system-monitor "System Monitor collapsed into a line" [Unknown,Confirmed] https://launchpad.net/bugs/24243
<pitti> ugh, 5 digit bug :)
<seb128> yeah ;-)
<pitti> seb128: ok, nevermind then, thanks :)
<seb128> np
<seb128> pitti: btw all the pending hardy bugs have been retraced, many dups closed and the intrepid retracers have been restarted using the intrepid python-launchpad-bugs so daily dist-upgrade work again
<pitti> rocking
<seb128> pitti: and there is a bug-buddy waiting for approval which don't hijack apport, dunno if you do beta approvals
<seb128> s/don't/doesn't
<pitti> seb128: I'm not sure whether I'm supposed to; ATM I "just do" them if they fix a beta-RC bug
<seb128> pitti: well, that's a gconf default value change to not have bug-buddy running, would be nice to have but no hurry either
<pitti> seb128: oh, indeed; that was accidentally enabled again?
<pitti> (I thought it was supposed to be off for ages)
<kwwii> seb128: the only folder_copy and oflder_move we have are at 16x16 and already have a stock_ prefix
<seb128> pitti: yes, new gnome-session changed the way bug-buddy is started, that was broken for the whole cycle, they fixed in for the stable tarball so bug-buddy is running again now
<pitti> seb128: ok, I'll ack that and take the bullets
<seb128> pitti: thanks
<kwwii> seb128: if you know which size is missing I can make them
<exarkun> How can I learn of proposed package removals (eg, much of python-xml from Hardy) before they are actually part of a release?
<seb128> pitti: I'll ping slangasek for the next uploads, he should be around soon
<kwwii> pitti: sent those icons off as well as a new sounds package last night
<pitti> kwwii: saw it, thanks
<kwwii> excellent :-)
<seb128> kwwii: there is something wrong there, let me have a look to those
<liw> kwwii, you might know this: if a program written for Ubuntu requires an icon, is there a process for getting one?
<kwwii> seb128: they are in Human/16x16/stock/generic/ in case you are looking for them
<seb128> kwwii: ok, that's the other way around, evolution uses folder-copy and folder-move
<seb128> kwwii: do you use evolution?
<pitti> seb128: do you happen to know if there's a reference bug for the broken libgphoto camera handling already?
<pitti> seb128: if not, I'd like to create one, to track it for beta/final
<pitti> seb128: (release team meeting prep)
<pitti> \o/ hardy SRU queue empty again
<seb128> pitti: bug #258083
<ubottu> Launchpad bug 258083 in f-spot "F-Spot - Error connecting to camera.  "Could not lock the device"" [Medium,Confirmed] https://launchpad.net/bugs/258083
<pitti> seb128: merci
<seb128> pitti: thanks for approving my uploads there ;-)
<seb128> pitti: btw alex just fixed gnome bug #530654
<pitti> seb128: I added a comment to 258083, which I think is the current state and approach
<ubottu> Gnome bug 530654 in client module "Map FUSE paths to uri's" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=530654
<kwwii> seb128: nope, I do not use evolution
<seb128> pitti: that should fix the issue we were speaking about yesterday
<pitti> seb128: oh, that sounds related
<kwwii> seb128: ok, I will take care of the renaming and then give you a new human-icon-theme package with those fixes and the new icons for the logout stuff
<seb128> kwwii: ok, anyway if you could just do symlinks folder-copy -> stock_folder-copy and folder-move->stock_folder-move in the 16x16 variants that would be nice
<seb128> kwwii: thanks!
<pitti> seb128: ah, and f-spot would accept that converted URL?
<seb128> pitti: gvfs should automatically convert those to the correct url, so that should solve the cases where you try to open a recent files on a fuse which not yet mounted for example
<tedg> kwwii: We should probably add some way to set a list of symbolic links in the Breathe script.
<kwwii> tedg: I would just do it in the debian/links file as we currently do
<kwwii> keep that stuff away from artists, they will just bork things
<tedg> kwwii: Well, while I don't want to discourage your dislike of artists, I figured there were some things that they may know better.  Like if an icon covers several mimetypes or something.
<kwwii> they need the information, sure
<pitti> hey tedg
<pitti> tedg: can you please give me a quick status update of the f-u-s-a "wrong suspend/hibernate" options bug? (for our release meeting today)
<pitti> tedg: bug 274140 I mean
<ubottu> Launchpad bug 274140 in fast-user-switch-applet "Visability of Suspend and Hibernate doesn't match gnome-session's dialogs" [High,New] https://launchpad.net/bugs/274140
<pitti> kwwii: and I guess bug 269504 is underway, as far as I understood it?
<ubottu> Launchpad bug 269504 in human-icon-theme ""Suspend" icon is black rectangle in "Shut Down" dialog" [High,Confirmed] https://launchpad.net/bugs/269504
<tedg> pitti: I'm working on it, I hope to have it done this morning, but definitely before I finish work today.
<pitti> tedg: right, shouldn't be a rush; I'm primarily interested in whether the bug is understood, our you need help (from me with hal, or from upstream, etc.)
<pitti> tedg: it seems that fusa and g-p-m currently use differnet methods to determine available options then?
<tedg> pitti: No, it's that FUSA is not asking GPM currently.
<tedg> pitti: GPM provides a DBus command to query what it's thinking, so it'll use that so that they are assured to agree.
<kwwii> seb128: just sent an email with the package details, let me know if there is a problem
<seb128> kwwii: ok, I'll have a look, thank you
<pitti> tedg: that sounds good, thanks; so this can be chalked off as "in progress"?
<tedg> pitti: Yes.
<pitti> tedg: thanks, I updated the bug (for the records)
<pitti> seb128: the f-spot bug: my or your plate?
<seb128> pitti: we both have lot on our plates, the first to have some free slot to look at it?
<seb128> pitti: I'll not do it today for sure but I can have a look next week
<pitti> seb128: right, same here
<kwwii> seb128: wait on that update, I found a bug
<pitti> kwwii: human-theme uploaded; I'll upload ubuntu-sounds as well, but they won't make beta (unless you can convince slangasek to approve it with a good reason why we need them)
<seb128> pitti: what version did you upload?
<pitti> kwwii: oh, it seems -sounds is already it
<pitti> in
<seb128> pitti: I think -sounds is a conflicting update, themuso did some updates too
<shingara> How I can know the number of patchlevel of ubuntu specific in a package ?
<pitti> seb128: ah, indeed
<kwwii> pitti: excellent, thanks!
<pitti> sending mail back
<seb128> ok, trying some changes, be back in a bit
<directhex> shingara, sorry, the question isn't 100% clear. you don't just want the number after the word "ubuntu" in a package version?
<shingara> no
<shingara> ubuntu create a package specific
<shingara> maybe several time on only one version upstream
<Hobbsee> Hm, linux identity wants an article on the 8.10 release.  I wonder who to ask about doing that
<shingara> I want separate the twice information
<shingara> the version upstream and the version ubuntu specific
<Hobbsee> shingara: the left and right hand sides of the - will tell you that
<RainCT> (Does someone here have -or had- a Samsung SGH-ZV60?)
<directhex> Hobbsee, "the nice brown ubuntu you know and love, but moar new!". there, that was easy
<kwwii> TheMuso: dude, you uploaded an ubuntu-sounds_0.9?
<Hobbsee> directhex: heh
<shingara> in case of 0.5.2~alpha+svn-r248-1
<shingara> it's -1 the ubuntu specific version ?
<directhex> shingara, that's a debian version
<shingara> package rest2web-doc
<Hobbsee> !info rest2web-doc
<directhex> shingara, there is no ubuntu specific patching to that
<ubottu> rest2web-doc (source: rest2web): documentation for rest2web. In component universe, is extra. Version 0.5.2~alpha+svn-r248-1 (hardy), package size 2580 kB, installed size 5528 kB
<Hobbsee> 0.5.2~alpha+svn-r248 <-- upstream version.  -1 <-- debian version (no 'ubuntu' in it)
<shingara> ok, so ubuntu add an ubuntu version to debian
<Hobbsee> shingara: when we change it, yes
<directhex> unless the number after the last - is 0, in which case it's an ubuntu original
<directhex> -1 is a debian package, -1ubuntu1 is an ubuntu package based on debian -1, -0ubuntu1 is an ubuntu package with no debian basis
<shingara> ok
<shingara> gnome-dbg version  Version: 1:2.20.2.2
<shingara> what is the 1: ?
<shingara> because it's the version 2.20.2.2 no ?
<dholbach> shingara: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<shingara> tahnks
<shingara> I searched this doc
<Ng> pitti: re your comments on bug 258083, has the fix been uploaded? Should I be testing anything?
<ubottu> Launchpad bug 258083 in f-spot "F-Spot - Error connecting to camera.  "Could not lock the device"" [Medium,Confirmed] https://launchpad.net/bugs/258083
<seb128> pitti: could you also accept gnome-python-extras?
<seb128> pitti: it fixes the package not being installable due to gdl changes (which leads to all applications depending on it not being installable too)
<pitti> Ng: no, nothing uploaded to intrepid yet
<seb128> pitti: it's basically a small tweak to build using the new gdl and a rebuild
<pitti> seb128: ah, I already noticed that, dist-upgrade wants to remove some packages due to that; accepted
<seb128> pitti: thanks!
<seb128> ok, I've away for around an hour, will catch back on other things after that
<seb128> I'm away rather ;-)
<Ng> pitti: ok. I'll keep my eyes open for something then. thanks :)
<pitti> asac, Riddell: on whose plate is bug 259278? it's marked for beta, but doesn't have an assignee; also, any idea whether we can actually expect a fix in time for beta?
<ubottu> Launchpad bug 259278 in knetworkmanager "knetworkmanager will no longer connect" [High,Confirmed] https://launchpad.net/bugs/259278
<pitti> mvo: what's the status of bug 274303? you were working on that yesterday, right?
<ubottu> Launchpad bug 274303 in update-manager "Needs to transition users of fglrx to a free driver" [High,Triaged] https://launchpad.net/bugs/274303
<asac> pitti: i will ping the upstream guy who claimed to have something last week
<pitti> it sounds like it'd entirely break networking on Kubuntu?
<Hobbsee> pitti: based on #kubuntu-devel, it looks like Riddell has a fix, and that will be coming thru soon.
<pitti> nice
<Riddell> yes, give me a bit and I'll have something for people to test
<pitti> Riddell: so it's not entirely hopeless then? :-)
<pitti> Riddell: thanks
<superm1> TheMuso, i just saw a ping from you many days ago regarding BCM4328.  have you tried it yet?
<superm1> w.r.g to airport
<pitti> seb128: you said that consolidate-spell-checkers was pretty much done, right? can we set it to implemented, or is tere still something to do for it?
<Riddell> asac: please try http://www.kubuntu.org/~jriddell/tmp/knetworkmanager/network-manager-kde_0.7svn864988-0ubuntu1_i386.deb
<asac> Riddell: is that the latest svn?
<Riddell> asac: yes
<asac> Riddell: i think you can just uploade to network-manager PPA :) ... current state is broken and it cant get worse :)
<asac> Riddell: could you upload there? i will get feedback from all the folks waiting for knetworkmanager over the weekend then
<Riddell> ok
<Hobbsee> seb128: were you planning to deal with python-gnome2-extras?  it's not installable again
<pitti> Riddell: do you think bug 270423 is important enough to milestone it for beta? seems mostly cosmetic to me, but it might hide a bigger problem
<ubottu> Launchpad bug 270423 in ubiquity "[kde] doesn't show dialog after installation" [Undecided,New] https://launchpad.net/bugs/270423
<Riddell> pitti: I don't especially mind, although it should be fixed for final.  evand or cjwatson might be able to say if it's more important than just cosmetic
<pitti> Riddell: right, since it might be a crash near to the end, or so
<cjwatson> it's just very confusing; I don't think it's beta-critical
<slangasek> seb128: pinging on IRC is fine, though so far I haven't gotten the queue back down to zero which puts it up on my todo list :)
<StevenK> slangasek: Us nasty developers keep uploading stuff? :-)
<slangasek> pretty much
<mathiaz> cjwatson: now that partman-auto-raid has been promoted, can it be added to the installer seed or should it wait for after Beta ?
<slangasek> argh, desktop CDs oversized at 711MB, and not even a previous daily to compare with :/
<Hobbsee> ouch.  Try throwing the All New and Shiny We Love Pitti (tm) merchandise off.
<pitti> slangasek: just alpha 6 for comparison? cronjobs were disabled for quite some time, right?
<pitti> Hobbsee++
<Hobbsee> pitti: :
<Hobbsee> * :)
<slangasek> they weren't disabled for that long, I don't know why there's not a daily from yesterday on here
<directhex> how much does that make in excessive on-disk package use inside the image, roughly?
<Hobbsee> pitti: you have 40404 karma.  I find that disturbing.
<pitti> nice!
<directhex> how exactly is LP karma earnt?
<geser> directhex: with bugs, answers, branches, translations, specs and I guess some more
<mvo> pitti: re 274303> that is fixed in bzr, I was doing final testing and then I will upload
<directhex> so my stuff on altioth earns me no respect. *sniff*
<StevenK> By doing stuff on LP
<StevenK> Answering questions, fiddling with bugs, ...
<directhex> closing 30 mono bugs probably helped.
<geser> directhex: do that every day and your LP karma will go up (and mono get bug free :)
<mvo> pitti: I added flglrx and the two old nvidia drivers to the current code
<directhex> geser, i have my eye on all open mono bugs. half are incomplete, half are upstream bugs, 1 is fixed in debian NEW, one i can't reproduce but seems to affect old user accounts (but not fresh user accounts)
<directhex> and by fixed in debian NEW i mean by me, of course ;)
<cjwatson> mathiaz: I think it's OK to add it
<directhex> geser, now, if i wasn't terrified of going near it, beagle is a treasure trove of bug merging opportunities.
<cjwatson> slangasek: the livefs build got stuck on a lock
<cjwatson> slangasek: I fixed it with #is's help this morning
<slangasek> grr, not again
<pitti> mvo: nice, thanks
<seb128> Hobbsee: what is the issue? what version are you speaking about?
<sbeattie> cjwatson: I'd hoped to see if the modprobe -Os changes helped with bug 258432, but lack of live cds prevented that.
<ubottu> Launchpad bug 258432 in casper "Intrepid 4 live cd drops to busybox, needs more time to  find CD livefs" [High,Confirmed] https://launchpad.net/bugs/258432
<cjwatson> sbeattie: I think we probably should just crank up the timeout; that should be straightforward given a few spare minutes
<sbeattie> cjwatson: yeah, that's pretty simple to do and will hopefully paper over issues for most problematic hardware.
<IntuitiveNipple> Can someone remind me of the security team name for bug reports? I just accidentally submitted a bug without ticking the security warning box, and searching for subscribers with "security" in the name gives me ten's of pages.
<seb128> grrrr
<jdstrand> IntuitiveNipple: ubuntu-security
<seb128> pitti: python-gnome-extras failed to build, "Xvfb failed to start"
<IntuitiveNipple> jdong: many thanks
<IntuitiveNipple> oops...
<IntuitiveNipple> jdstrand: many thanks
<jdstrand> :)
<pitti> seb128: I think my pygtk sponsored upload FTBFSed for exactly the same problem, but didn't have time yet to look at it
<seb128> let me ask on #ubuntu-x
<seb128> kwwii: looking at your icon theme update, there is no sleep icon, is that expected?
<kwwii> seb128: you mean suspend?
<seb128> kwwii:
<seb128> +#define GSM_ICON_HIBERNATE "drive-harddisk"
<seb128> +#define GSM_ICON_SLEEP     "sleep"
<kwwii> seb128: I made one for that...lol, I named it wrong
<seb128> kwwii: I mean "sleep" which is the icon for the suspend action
<kwwii> I looked at the wrong line in the #define
<seb128> kwwii: the update adds system-shutdown.svg and view-refresh.svg and computer.svg
<seb128> kwwii: none of that seems to be suspend or sleep icons?
<kwwii> seb128: yes, system-shutdown should be sleep
<seb128> oh
<seb128> the name is misleading ;-)
<kwwii> it is a monitor with a moon on it
<kwwii> because I screwed up the naming :-)
<seb128> system-shutdown is what is used for halt action
<kwwii> I will move it and make another package
<seb128> kwwii: ok, can you fix that? no need to update the debian/changelog version again
<kwwii> sorry, thanks for noticing
<kwwii> yes, I'll get that to you in a minute
<seb128> kwwii: no problem, just use the same version, fix the name, upload and ping me again ;-)
<Riddell> Keybuk: you have ops in #ubuntu-meeting, hokmen needs a +q
<Riddell> oh, sorted
<Keybuk> Riddell: he's not in the channel
<Keybuk> #ubuntu-meeting is owned by the irc council cabal
<Keybuk> so I have no authoritah there
<digistyl3> TheMuso: hi, are you around?
<kwwii> seb128: I updated the packages on my server, so the links in that email now point to the new stuff
<cjwatson> Keybuk: access #ubuntu-meeting list says you do, FWIW
<Keybuk> cjwatson: chanserv says I don't ;)
<Keybuk> -ChanServ- You are not authorized to perform this operation.
<seb128> kwwii: your update doesn't fix the "switch user" issue right?
<seb128> kwwii: #define GSM_ICON_SWITCH    "system-users"
<cjwatson> Keybuk: oh, oh well
<kwwii> seb128: I did not realize that there was a problem with that :-)
<seb128> kwwii: open the logout dialog ;-)
<kwwii> seb128: I am not running intrepid yet :-)
<seb128> oh
<seb128> kwwii: ok, so "system-users" has a similar issue
<kwwii> all I have is my thinkpad and the disk is full
<kwwii> can someone make a screenshot of the problem so I understand that context?
<kwwii> or is there a bug about this?
<seb128> kwwii: https://bugs.edge.launchpad.net/ubuntu/+source/human-icon-theme/+bug/269500
<ubottu> Launchpad bug 269500 in human-icon-theme ""Log Out" and "Switch User" are misaligned" [High,Fix committed]
<seb128> kwwii: the first screenshot
<seb128> kwwii: what icon did you change to fix this one?
<seb128> kwwii: is that your computer.svg change?
<kwwii> seb128: erm, I think I marked the wrong bug as fixed :-)
<seb128> kwwii: ok, is that something you can, want fix today too?
<kwwii> seb128: yes, that I will make an icon for logout and then it will be fixed :-) I'll make another package after that and let you know
<seb128> kwwii: ok, still no need to update the changelog, just add the icon that will be good enough ;-)
<kwwii> seb128: ok, I'll ping you later when done..thanks for the help
<seb128> ok, no problem, I didn't do a lot ;-)
<mdz> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467374#34 hints that perhaps the change is due to the ibm-acpi module
<ubottu> Debian bug 467374 in acpi-support "acpi-support: acpi_fakekey does not reach sleep.sh" [Normal,Closed]
<mdz> pitti: remember, the kernel started printing that warning, saying we shouldn't set the mask anymore, and we changed it?
<pitti> mdz: I just wonder why it breaks my dell as well then? I don't even have that module
<pitti> but again, that could be yet another bug, of course
<mdz> pitti: I bet acpi-fakekey is doing the job on 8.04
<mdz> pitti: does acpi_fakekey 142 do anything for you?
<pitti> mdz: it might be interesting to compare the output of acpi-fakekey and the one from -evdev
<mdz> pitti: it would be if acpi_fakekey produced any output ;-)
<pitti> mdz: yes, it suspends
<mdz> pitti: oh, interesting
<mdz> pitti: that doesn't work on my thinkpad
<mdz> pitti: perhaps yours is a different bug indeed
<pitti> mdz: I think so, too, most of hte bug is pretty thinkpad specific
<pitti> mdz: I guess I'll try to bisect that a bit; run with just acpid, run with just hal, run with hardy kernel, etc.
<kirkland> mdz: just saw your post to 267682...  i have a thinkpad x61 running hardy, and a thinkpad t61p running intrepid, i can probably gather the required lshal info
<pitti> mdz: so acpi_fakekey converts something like the HKEY/whatever_for_Fn_F3 to XF86Standby? or what is it used for?
<mdz> kirkland: that would be fabulous; mine is at home so I can't to it right now
<mdz> kirkland: could you also try sudo acpi_fakekey 142 ?
<pitti> mdz: (xev shows XF86StandBy when I press Fn+F3)
<mdz> kirkland: on both systems?
<kirkland> sure...  let me power up the wife's x61
<mdz> pitti: acpi_fakekey takes an ACPI event and converts it into a simulated keypress
<mdz> pitti: this makes it possible to convert non-standard ACPI events to standard keycodes which can then be heard by programs which care about the events
<mdz> pitti: (like hal)
<pitti> mdz: that sounds pretty close to what evdev now does as well?
<lukehasnoname> Do you guys know of an error with installing LVM on encryption in alternate install?
<mdz> pitti: where does evdev get acpi events from?
<pitti> mdz: quantum flux phase inverter? sorry, no idea
<pitti> mdz: but I don't think there's a lot in between it and the kernel
<pitti> and, after all, the XEvents it generates don't actually look bad, they just have no effect
<mdz> pitti: unless the kernel emits acpi events through evdev, we would still need something to hear them
<mdz> though it certainly would be nice if everything just came through as input events
<mdz> from the kernel
<kirkland> mdz: okay, both systems up...
<mdz> kirkland: first check whether the suspend key works on both
<mdz> kirkland: should work on 8.04, should be ignored on intrepid
<kirkland> mdz: fn-F4 (little moon?)
<mdz> kirkland: y
<kirkland> mdz: hmm, sadly, no effect on either
<pitti> mdz: well, that might very well be a red herring for me, of course; the XF86Standby I see might actually come from acpi_fakekey istead of directly from kernel->evdev
<kirkland> mdz: the obvious ones work on the hardy machine
<kirkland> mdz: sound up/down, etc.
<mdz> kirkland: check your power management preferences
<kirkland> mdz: battery, screen lock
<kirkland> mdz: k
<mdz> kirkland: if battery works, that's a useful data point, it doesn't work for me
<mdz> kirkland: (on intrepid)
<kirkland> mdz: ah, that was it
<kirkland> mdz: suspended fine, once configured
<kirkland> mdz: i had it set to "do nothing"
<kirkland> mdz: i'll try on my intrepid laptop (might be gone for a moment)
<kirkland> mdz: nope, doesn't work on intrepid (confirming bug)
<kwwii> seb128: ok, same links as before
<kwwii> seb128: I added a system-users vector and 48x48 icon
<mdz> kirkland: ok, good
<mdz> kirkland: on the hardy one, can you try sudo acpi_fakekey 142 ?
<kirkland> mdz: okay, it's asleep
<mdz> kirkland: and on intrepid?
<seb128> kwwii: looking
<kirkland> mdz: on intrepid, nada
<pitti> mdz: ok, that confirms that the thinkpad and dell issues are in fact different
<mdz> kirkland: ok, please post your findings to the bug and I'll think about what to do from here
<kirkland> mdz: did you want some lshal info?
<kirkland> mdz: shall i post that to the bug?
<mdz> kirkland: ->bug please
<kirkland> mdz: k, no problem
<cjwatson> mathiaz: BTW, I was talking to Ian Jackson last night about the python-gobject triggers problem, and he reckoned it's fixed in current Debian dpkg
<cjwatson> mathiaz: so I'll have a look at that post-beta
<mathiaz> cjwatson: great - thanks !
<pitti> that would get us rid of those nasty pre-depends?
<cjwatson> so I'm told
<cjwatson> we think, anyway. Basically any package in triggers-awaited shouldn't be allowed to satisfy a dependency
<mdz> kirkland: does sudo acpi_fakekey 236 work on the intrepid one?
<seb128> kwwii: there is no 48x48 icon in this update and you included the .bzr directory in the source (I can clean that), is the scalable icon enough?
<kirkland> mdz: doesn't look like it did anything....
<kirkland> mdz: what would that do?
<mdz> kirkland: pop up a battery status dialog (try it on the hardy system)
<kwwii> seb128: yes, there should be 48x48/apps/system-users.png
<mdz> s/dialog/notification/
<mdz> kirkland: same as fn+f2
<seb128> kwwii: oh, there is one
<kwwii> :-)
<kwwii> sorry about the .bzr dir, it was a mistake
<seb128> kwwii: debdiff is not listing it, weird
<kirkland> mdz: ironically, on hardy, fn+F2 works (battery pops up), but not 236
<mdz> kirkland: :-?
<mdz> kirkland: fn+f2 should be running /etc/acpi/sleepbtn.sh which runs acpi_fakekey 236 as root
<mdz> kirkland: can you watch xev on both sides when doing acpi_fakekey 142 and see what's different?
<mdz> (both hardy and intrepid)
<Riddell> mvo: upgrade with current dist upgrade tool seems to be going well
<slangasek> mvo: does the compiz FFe fix the gconf backend issue? :)
<mvo> Riddell: excellent, thanks. I run it over the auto tester now and then it ready to go (just fixed a issue with the nvidia stuff)
<mdz> kirkland: I'd hoped 236 would be a simpler test case since it doesn't suspend the machine, but whatever you can get to work...
<kirkland> mdz: right
<kirkland> mdz: i'm on the phone with IBM, at the moment (regular server call)
<kirkland> mdz: let me ping you in a few
<mdz> kirkland: once you've done that, please check whether the brightness keys work
<mdz> kirkland: ok, I'll queue up some more questions if that's OK
<kees> Keybuk: what did the modprobe delay turn out to be?
<mdz> kees: it turns out it's a billion times faster when compiled with -Os
<mvo> slangasek: sort of, it certainly will work with gconf and has it as default. now the issue that if gconf is not wroking for some reason and compiz switch to flat file but never back is more problematic to fix, I look into it after bug 274303 is done
<mdz> rather than -O2
<ubottu> Launchpad bug 274303 in update-manager "Needs to transition users of fglrx to a free driver" [High,Triaged] https://launchpad.net/bugs/274303
<kees> asac: any news on why n-m still keeps thinking it should manage my eth0 when it's configured "static" in my interfaces file?
<slangasek> mvo: ok
<kees> mdz: wild.
<Treenaks> mdz: it makes that much difference? impressive..
<slangasek> \sh: ping
<mdz> kees: 256054
<kees> mdz: how did that get uncovered?
<kees> mdz: thanks
<mdz> kees: arjan's presentation showed that fedora's was running faster, and scott narrowed it down from there
<kees> mdz: so it's just a long-standing debian glitch?
<cjwatson> bzr: ERROR: Pack '56b441f9b0f40b61da5873827fa4f86b' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x9649d0c>
<cjwatson> 'bzr get bzr+ssh://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.intrepid /tmp/tasksel-Lf9QGJ/checkout-ubuntustudio' failed with exit status 768
<cjwatson> blink, what's up with ubuntustudio?
<mdz> kees: it's a freak optimization side effect I think
<kees> mdz: heh
<mdz> kees: probably -O2 causes the code size to blow up somewhere, and it's overflowing cache
 * kees imagines "freak optimization"
<_MMA_> cjwatson: Hmm... I'll have to have TheMuso take a look.
<seb128> kwwii: so, none of those new icons are installed in the deb
<mdz> kirkland: what we need to do is map out the path that the event is taking on hardy and intrepid and where they differ
<cjwatson> _MMA_: needs help from #bzr probably
<cjwatson> note that I fetch all the seeds into a single repository in order to save time
<mdz> kirkland: on hardy, what I think happens is kernel -> acpid -> /etc/acpi/*.sh -> acpi_fakekey -> ??? (maybe hal)
<seb128> kwwii: you didn't touch the makefiles to install those apparently
<_MMA_> cjwatson: Ok. I'll let him know as he would know best.
<mdz> kirkland: on intrepid we've confirmed that acpi_fakekey doesn't get heard properly, so we need to see where it diverges
<cjwatson> so in order to reproduce this: bzr get bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/ubuntu tasksel; cd tasksel; rm -rf ubuntu-tasks; make ubuntu-tasks
<mdz> kirkland: apparently, changing the X keyboard driver to evdev impacts it
<seb128> kwwii: scalable/actions/Makefile.am scalable/apps/Makefile.am scalable/devices/Makefile.am need to be updated to list the new icons
<cjwatson> make that 'bzr get -r1373 ...', since I'm probably going to work around this
<kwwii> seb128: ouch, I'm used to doing the python build stuff
<seb128> kwwii: do you know what changes are required and how to do those?
<seb128> kwwii: debdiff is useful to compare deb contents between versions btw
<seb128> kwwii: basically edit the files I just listed, add the icons to install, run autogen.sh and that should it
<seb128> "should be it"
<_MMA_> cjwatson: noted.
<mdz> kirkland: also check what hal-addon-input is doing on both systems. is it listening to the same event devices?  is it listening to the one where the event from acpi_fakekey comes out?
<kwwii> seb128: yes, I am adding the files to the makefiles now
<mdz> kirkland: the most bizarre thing is that it seems to work if the user logs in on a guest session, so there's something at the session level which is impacting this
<mdz> kirkland: which I wouldn't expect since hal listens to the /dev/input/event* directly
<Treenaks> mdz: can't you replace acpi_fakekey with something that logs getppid() (and possibly the name of that process) before doing the actual key insert?
<kirkland> mdz: off the phone now, okay.
<kirkland> mdz: do you want me to try the evdev driver next, or the guest session?
<mdz> kirkland: I want you to find out what's listening to the event that acpi_fakekey generates on hardy
<mdz> kirkland: I think it's hal-addon-input
<kwwii> seb128: ok, same place as before :-)
<seb128> kwwii: looking
<seb128> kwwii: do you try to build your updates? ;-)
<seb128> kwwii: you added a system-users.svg in 32x32/actions/Makefile.am but there is no such icon in the 32x32/actions directory
<mdz> kirkland: you may find input-utils useful
<mdz> kirkland: (lsinput and input-events)
<mdz> kirkland: can I call you?
<kirkland> mdz: confirmed: suspend does work from an intrepid guest session
<kirkland> mdz: what's the lock-screen key code?
<mdz> grep LOCK /usr/share/acpi-support/key-constants
<mdz> KEY_CAPSLOCK=58
<mdz> KEY_NUMLOCK=69
<mdz> KEY_SCROLLLOCK=70
<mdz> KEY_LOCK=$KEY_COFFEE
<superm1> kirkland, you mean the password? there's a bug open about that
<mdz> KEY_COFFEE=152
<mdz> superm1: no, we're working on bug 267682
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,In progress] https://launchpad.net/bugs/267682
<cjwatson> that inversion of KEY_LOCK and KEY_COFFEE is suspicion
<cjwatson> suspicious
<superm1> ah okay
<mdz> cjwatson: not to me, that's expected (same in the kernel)
<cjwatson> oh, you pasted them in the opposite order from how they are in the file
<mdz> cjwatson: two separate commands, sorry
<kirkland> mdz: http://pastebin.ubuntu.com/50933/
<kirkland> mdz: http://pastebin.ubuntu.com/50934/  > intrepid
 * mdz discovers pastebinit
<kirkland> mdz: http://pastebin.ubuntu.com/50934/
<kirkland> mdz: http://pastebin.com/f6db34582
<kirkland> mdz: ^ intrepid lsinput
<mdz> kirkland: once you have the lsinput output from both, I'm interested in strace -p on hald-addon-input when you run acpi_fakekey on both hardy and intrepid
<kirkland> mdz: lsinput from hardy: http://pastebin.com/f5b8f062c
<mdz> so on intrepid, it's writing to event1, which is "AT Translated Set 2 keyboard"
<mdz> same on hardy
<mdz> so that part is the same
<mdz> kirkland: how about hald-addon-input?
<seb128> slangasek: ok, gnome-python-extras creates some un-installability issues in intrepid, a fixed version has been uploaded but doesn't build due to xvfb-run being broken, I've discussed it on #ubuntu-x but it's not likely it'll be fixed before monday on their side, what do you think we should do? upload a gnome-python-extras which doesn't call xvfb-run to workaround the bug? wait on monday? get somebody to fix xvfb today?
<mdz> kirkland: root      5125  0.0  0.0   3436  1048 ?        S    Sep24   0:08 hald-addon-input: Listening on /dev/input/event1 /dev/input/event2 /dev/input/event3 /dev/input/event4 /dev/input/event5
<slangasek> seb128: hrm, is xvfb-run needed for anything besides testing?
<kirkland> root      6005  5883  0 12:04 ?        00:00:00 hald-addon-input: Listening on /dev/input/event1 /dev/input/event2 /dev/input/event3 /dev/input/event4 /dev/input/event5 /dev/input/event6 /dev/input/event7 /dev/input/event9
<jcristau> mdz: presumably, since xf86-input-evdev grabs the devices, hald-addon-input won't get anything..
<mdz> jcristau: oh?  can only one process listen to them at once?
<munckfish> Please excuse my naive question: but do kernel filesystem modules autoload? I am trying to work out why spufs seems to need explicit mention in /etc/modules to get it to load.
<persia> Indeed.  /dev/input/event* streams are single-access.
<mdz> that would explain a lot
<jcristau> persia: not necessarily
<cjwatson> slangasek: can you approve grub-installer if it's OK by you? (and tasksel too)
<jcristau> but xf86-input-evdev does ioctl(EVIOCGRAB)
<mdz> jcristau: why does it do that?
<cjwatson> slangasek: xvfb-run is fairly often used in build processes
<slangasek> cjwatson: right, I mean in the case of gnome-python-extras - to understand what an upload which doesn't call it will do
<cjwatson> oh, sorry, I misread
<jcristau> mdz: to prevent key presses to go to the console, and mouse stuff to /dev/input/mice
<jcristau> s/to go/from going/
<seb128> slangasek: in gnome-python-extras? no, it's just used to run the testsuite
<slangasek> seb128: right, let's go for option a) then, please
<kirkland> mdz: hald on hardy strace: http://pastebin.com/f45596ef0
<seb128> slangasek: alright, doing that in a minute
<mdz> kirkland: thanks
<lukehasnoname> I don't know if the fact the partition is encrypted makes a differeence on the write speed
<lukehasnoname> ack wrong window, sorry.
<mdz> kirkland,cjwatson,pitti,slangasek: new analysis in bug 267682
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,In progress] https://launchpad.net/bugs/267682
<mdz> kirkland: thanks for your help
<kirkland> mdz: no problem, shall I drop off of hold?
<kirkland> mdz: this music is morose
<pitti> mdz: ah, got the mail
<mdz> kirkland: could you tell us, from the strace output, which device is receiving the event from acpi_fakekey on hardy?
<mdz> kirkland: is it the 'thinkpad extra buttons' device?
<Keybuk> kees: I've yet to fully tell whether this makes our modprobe go away entirely
<Keybuk> it just certainly makes it faster
<pitti> bye everyone, have a nice weekend!
<seb128> pitti: thanks, you too
<kees> pitti: cya pitti!
<kees> Keybuk: ah, no bootchart for it yet?
<seb128> slangasek: I uploaded a gnome-python-extra adding a build-depends on libgl1-mesa-dri to workaround the xvfb issue, that was the faster way and I've to run now
<Keybuk> kees: not on the Q1 where it's most notable
<kirkland> mdz: how might i determine that?
<mdz> kirkland: match up the file descriptor number with what's in /proc/pid/fd
<mdz> kirkland: I'm pretty confident though, if you have other things to do, don't worry about it
<bryce> mdz, I read your analysis on the bug.  Do you have a course of action in mind we should take?
<pochu> slangasek: hi. Is debian/patches/01_gettext_not_xmal.patch in libgweather something that upstream could use? It looks to me like the answer is yes, but I want to be sure
<pochu> slangasek: third entry in https://edge.launchpad.net/ubuntu/+source/libgweather
<bryce> mdz, I recall in fedora 9 they ended up disabling evdev for keyboard handling entirely; perhaps that would be something to consider?
<kirkland> mdz: i was just about to step out to lunch
<liw> does there exist a library for taking a number+unit (say, size of a file in bytes) and returning a user-friendly number+unit (size of file in kB or KiB)?
<lool> cjwatson: Hey, we were discussing enablement of automatic mode in mid images with persia; I was wondering whether it would make sense to permit enabling the automatic mode by preseeding ubiquity itself in someway (perhaps separately)?
<cjwatson> lool: sorry, I need to finish up for today and don't have time to discuss this now; maybe mail ubuntu-installer@?
<lool> cjwatson: Ok; this was future stuff anyway; will either mail or regrab another day
<lool> cjwatson: Have a good evening and WE
<seb128> pochu: I talked to vuntz about it and he was not really interested, he said we should rather ship the .xml in the language packs in ubuntu
<liw> https://wiki.ubuntu.com/FreezeExceptionProcess says "Requests for freeze exceptions for main should be filed as bugs in launchpad against the relevant package", but then does not say that that should happen also for packages in universe -- should it? it mentions that motu-release should be subscribed for such bugs for packages in universe/multiverse, so I guess the bugs should be filed, but it'd be nice to be explicit
<tjaalton> bryce: that was because of gnome vs. xkb deathmatch, and it's been fixed since (xkb won :)
<slangasek> pochu: yes, it is; though I'm not sure that it's upstream-ready, I was hoping seb128 would assess that
<pochu> slangasek: read his comment from 8 minutes ago
<slangasek> right, I see it
<pochu> ok
<slangasek> that's a big "wtf" to me
<pochu> (vuntz maintains the package upstream)
<slangasek> someone has an unhealthy relationship with xml, it seems
<pochu> heh
<pochu> so I'll just fix the patch to apply cleanly again
<\sh> slangasek: pong...from long time ago
<slangasek> \sh: ah, I was just about to write to LP instead :)
<slangasek> \sh: bug #271550 - this is a regression vs. hardy, and you seem to have handled the only two uploads to intrepid
<ubottu> Launchpad bug 271550 in ia32-libs "ia32-libs missing libQtDBus, others?" [Critical,Confirmed] https://launchpad.net/bugs/271550
<\sh> slangasek: lemme check
<\sh> but while I'm checking this...where did sun-java*-plugin went?
<\sh> s/went/go/ ... my brain is on less power today somehow
<slangasek> I see sun-java6-plugin in intrepid, so... "Nowhere"? :)
<\sh> hmm...not me...anmd I have multiverse enabled
<slangasek> it's present on i386 and lpia
<slangasek> hmmmm, but I only see it when I look on drescher, not in my own apt cache
<\sh> hmm...and on amd64 ?
<\sh> ah
<slangasek> oh, of course, because my own apt cache is amd64, so nevermind :P
<\sh> I can see it on the archives too...but not in my apt-cache
<slangasek> anyway, AFAIK it's never been available for amd64?
<\sh> ia32-sun-java6-plugin ? because sun-java6-jre suggests it ;)
<\sh> but even this is not there
<\sh> slangasek: libqt4-dbus was never in ia32-libs
<\sh> latest hardy update/security version ubuntu11 had only libqt4-core and libqt4-gui
<slangasek> \sh: well, perhaps, but the intrepid version has /no/ qt libs :)
<fabbione> slangasek: are we in "strong" freeze now?
<slangasek> -rw-r--r-- root/root    323068 2008-04-09 18:39 ./usr/lib32/libQtDBus.so.4.3.4
<fabbione> hard.. that was the word
<slangasek> \sh: that's from the hardy version
<slangasek> fabbione: yes
<\sh> WTF!
<\sh> they are in fetch-and-build
<fabbione> slangasek: i'd like to give intrepid a bit more cluster love.. there is a new corosync upstream official release (3 svn commits more than what's in the archive now). openais similar situation and I'd like to push the last redhat-clsuter release i did yesterday
<slangasek> "cluster love", how euphemistic
<fabbione> slangasek: ehehe i know you could handle that :)
<fabbione> slangasek: you are rm.. unless you have objections i'll upload eitehr tonight or tomorrow
<slangasek> fabbione: well, I don't object to you uploading, but if you want them to be let out of the queue, please follow the feature freeze guidelines :-)
<slangasek> fabbione: i.e., submit a bug documenting why these are appropriate exceptions to the feature freeze
<\sh> slangasek: trying to bring them back...and adding libqt4-dbus
<fabbione> slangasek: i just don't have time for all this burocracy. I could just uplaod saying that i added a patch and nobody will notice. I am asking to keep packages clean.
<fabbione> slangasek: and i understand you have procedures.. just not enough time to follow all of them
<fabbione> slangasek: anyway... thanks.
<slangasek> fabbione: uploads that don't follow the freeze procedures push the bureaucracy onto the release team, who don't have gobs of spare time either; I can promise that I'll look at them if they're uploaded, but I can't promise that I'll have time to review it all myself
<fabbione> slangasek: no worries.
<\sh> ok...libqt4 and friends are coming back...
<\sh> do I need a special "ack" for it nowadays?
<\sh> but we really need a sun java plugin somehow for amd64...if we don't get it , all lovely admins with HP hardware and ilo2 are fcked
<\sh> doko: any idea why it's missing somehow? :) it's referenced, but no installation candidate on amd64
<slangasek> \sh: no acks needed for bugfix uploads to universe, no
<\sh> slangasek: ok..it will land on the archives in less then 5 mins
<\sh> s/archives/incoming/
<directhex> \sh, i can't admin my lovely Enterprise-Grade, um, netgear
<\sh> directhex: oh :)
<directhex> y'know, i miss cuba. i might violate my "never return to the scene of the crime" hoiday policy
<directhex> eep, wrong channel for such triviality. sorry.
<_MMA_> If I have 2 licenses, that all allow derivatives, can they be combined? LGPL+CC-BY-SA for instance. This is for an image/art btw. (Im helping to get a package strait)
<mvo> pitti: what should I check if the guest session does not work for me? is there debug output written somewhere?
<directhex> _MMA_, the SA clause means the derivative needs to be SA too
<mvo> pitti: I suspect its a nvidia problem, not the session itself
<liw> mvo, I made a new system-cleaner version to fix bugs reported today... (I may have unit tests but I still let bugs get through *sigh')
<\sh> slangasek: uploaded
<mvo> pitti: nevermind, found it (bad nvidia bad)
<mvo> liw: ok, on revu?
<liw> mvo, in my PPA, and please don't upload yet, I would like confirmation from the users that the bugs are fixed
<slangasek> \sh: thanks
<mvo> liw: ok, thanks
<\sh> now for something really interesting...ha nfs cluster with drbd storage failover time
<calc> checking out the OOo human icons from bzr takes a very long time :\
<slangasek> --lightweight?
<calc> slangasek: seeing how that does, thanks
<calc> still fairly slow, 2m so far for 4mb of data
<calc> 4m 8mb
<calc> at least its consistent in its slowness
<\sh> crimsun: did you file a wishlist bug for leonov of integration of 5-a-day ? ,-)
<calc> if this bzr bar is accurate i'll be getting the repo for another hour or so
<digistyl3> TheMuso: ? :)
<cody-somerville> slangasek, There doesn't seem to have been a livecd for Xubuntu in three days.
<slangasek> yes, livefs builds were wedged
<cody-somerville> Okay, thanks.
<slangasek> respinning now
#ubuntu-devel 2008-09-27
<mcasadevall> Are we at the point where -release has to ack every bugfix upload?
<mcasadevall> Or is that next week?
<slangasek> the archive is frozen, all uploads require a manual ack.
<slangasek> (see /topic)
<slangasek> oh, I guess that just says "beta freeze", so I guess that doesn't explain much after all :P
 * mcasadevall thanks slangasek :-)
<mcasadevall> I have one last fix for KDE to fix a rather nasty issue on amd64, just need to make sure my fix doesn't miserably break i386
<directhex> pfft, as if anyone uses fringe architectures like i386 anymore
 * mcasadevall uses the hammer of unjustified pain on directhex 
<mcasadevall> hrm
<pochu> slangasek: enjoy the gnuradio rebuild ;-)
<slangasek> pochu: ah, is wxwidgets fixed? :)
<pochu> slangasek: just uploaded it :)
<slangasek> cool
<slangasek> <yoink>
<Riddell> mcasadevall: what part of KDE do you have a fix for?
<mcasadevall> Riddell, well, Qt, but I mentally assiocate Qt with KDE. the qtjambi
<mcasadevall> ^patch from last night
 * Riddell suspects mcasadevall of secretly being NCommander
<Riddell> mcasadevall: I uploaded the main fix and (amazingly) it's compiled everywhere but sparc and hppa
<superm1> Mithrandir, can you also activate ~bluetooth's PPA?
<Mithrandir> superm1: done
<superm1> thanks Mithrandir
<pochu> slangasek: wxwidgets2.6 2.6.3.2.2-2ubuntu5 (Waiting forapproval)
<slangasek> superm1|away: ok, what channel did this IRC discussion about bluetooth happen on? :)
<slangasek> superm1|away: and when/how did this regress, if we shipped bluez-utils 3 in hardy without problems?
<wgrant> Are we able to sync from testing-security?
<slangasek> with enough force, we can sync from anywhere
<wgrant> Well, yes, but will I be told to sync it myself if I file a sync request?
<slangasek> if I suggest /before/ you file the sync request that it would be more efficient to sync it yourself, does that help? :)
<wgrant> It does. Are you going to suggest that?
<slangasek> I am
<wgrant> Thanks.
<jdong> and the most interesting indirect conversation of the day award goes to...
 * wgrant indirectly swats jdong.
<slangasek> pochu: hmm, I don't think this for loop does the right thing - it uses the same value of symlink for each invocation, which means they collide in /etc/alternatives...
<james_w> slangasek: is that advice for syncing from !unstable, or syncing in general at this time? I'd like to pull a fix in from unstable, but already have a patch for Intrepid if needed.
<slangasek> pochu: given that this will be hairy to undo, I think I'm going to sit on this upload rather than approving it, and wait for your comments given that it /happens/ to be in front of me in the unapproved queue right now :)
<slangasek> james_w: !unstable
<james_w> slangasek: cool, thanks
<slangasek> it's !unstable && !experimental, really; those two are tracked by default by the sync tools
<wgrant> Is pitti's syncpackage still the most official unofficial sync method?
<Hobbsee> wgrant: i think so
<wgrant> Hobbsee: Thanks.
<NCommander> hey Hobbsee and wgrant
<wgrant> Hi NCommander.
<NCommander> how goes it?
<pochu> slangasek: bah, right
<Hobbsee> hey NCommander!
<pochu> slangasek: it worked in my test as it was created for 2.5, but not for 2.4
<pochu> slangasek: is the right solution to use --slave for the second link?
 * NCommander can't feels his legs :-)
<NCommander> I might be getting a free RS/6000 :-)
 * NCommander would have liked a AlphaStation server, but I'll take what I can get
<slangasek> pochu: I think ideally you want to create a separate alternative for each pyver; if you use slaves, it's a lot more complicated to remove them when a python version is deprecated
<pochu> slangasek: makes sense
<slangasek> NCommander: I suggest not resting the RS/6000 on your legs
<pochu> slangasek: please reject the previous upload, I'll fix this properly tomorrow and reupload (it's 3am here)
<slangasek> pochu: rejecting, thanks
<pochu> good night!
<NCommander> slangasek, well, this is a really old 7605 RS/6000. I think there are lighter s390 mainframes
<slangasek> NCommander: this is why resting it on your legs is not a good idea
<NCommander> Well, if I find I can't install Ubuntu on it, I plan to send it out in style
<bddebian> Send it to me, I've always wanted an RS/6000 :)
<NCommander> Sure, just pay shipping and handling
<NCommander> Something like 70-100 dollars alone
<NCommander> Er, bddebian, where do you live in the world?
 * NCommander wonders if the Hurd PowerPC port works on it ;-)
<NCommander> bddebian, I should warn you, its dual boot AIX/Windows NT
<NCommander> Or so I'm told
<bddebian> Near Philadelphia.
<bddebian> And the Hurd PPC port doesn't work
<NCommander> Hrm
<bddebian> It was never finished
<NCommander> If I get it (should have it tommorow if I do), what do you have to trade for it ;-)
<bddebian> 700 Billion dollars. ;-P
<NCommander> Well, I was hoping for either an alphaserver or an SGI Irix box but ...
<ion_> Cool, www.w3.org made it into Finlandâs child pornography blacklist.
<wgrant> slangasek: Thanks (I presume it was you).
<NCommander> o_ol
 * NCommander sighs
<NCommander> Can someone do me a favor?
<NCommander> (if you run intrepid, and i386?
<NCommander> I'm having trouble test building something due to the fact that I'm stuck on equivelent of dial up
 * NCommander pokes apachelogger 
<Hobbsee> Keybuk: you may want to go and ask in -ops why you have no authority.  You certainly should do, by the flags.
<Hobbsee> Keybuk: you're not using out of date scripts or something, are you?
<bddebian> NCommander: I almost got some Irix boxes for free once and I was bummed when it never panned out :9
 * wgrant is content with having only i386 hardware.
<NCommander> ahhhhhhhhh
<wgrant> Although amd64 might be nice.
<ion_> I have a 68060 box.
<Darklock> I have a 8088 box
<ion_> I have a 6510 box.
<Darklock> damn
<apachelogger> NCommander: sup?
 * NCommander has two sticks
<NCommander> apachelogger, can you test build something for me?
<ion_> I have two drumsticks.
<NCommander> ion_, with our stick together, we have four bites
<apachelogger> NCommander: sure
<NCommander> apachelogger, I'm stuck on dial up so I can't download the dependencies for i386 ;.;
<ion_> ncommander: Perhaps Hobbsee could borrow her pointy stick.
 * Hobbsee has no need to borrow her own Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<Hobbsee> ion_: did you mean 'lend'?
<ion_> Heh, me no good on English speaky-things.
<Hobbsee> :)
<NCommander> ion_, there is no point in borrowing her stick
<NCommander> Its metric, and completely incompable with everything else
<apachelogger> a sonic screwdriver is way better anyway
<NCommander> I perfer a laser screwdriver
<NCommander> more lethal
 * wgrant prefers to avoid such hardwary things.
 * NCommander notes that wgrant doesn't watch Dr Who
 * Hobbsee tasers NCommander
 * NCommander is turned on
<Hobbsee> oh dear.
 * wgrant confirms NCommander's suspicions.
 * NCommander tackles Hobbsee and throws her in the COMFY CHAIR
<NCommander> apachelogger, http://pastebin.ca/1211969
<Hobbsee> mmm...comfy
 * wgrant gets out the soft cushions.
<ion_> Ah, darn. I was under the impression it was a 2.5 furlong stick weighing 4 zentners.
<Hobbsee> ion_: it's both imperial and metric.
<Hobbsee> it's a future stick
<ion_> Itâs in a quantum superposition, collapsing to either only when observed?
<Hobbsee> sounds about right
 * NCommander feels so geeky that he understands that
<StevenK> Anything can be both imperial and metric, since that's only a form of meaursement, not a defining part of it.
 * NCommander gives StevenK a metric bolt and only imperial wrenches
<NCommander> :-)
<NCommander> that's how you have metric-imperial compability
<wgrant> Metric and imperial screws often have different threads too.
<StevenK> Sure, but you can meaurse either with either system, its just that one "works out" in one
<StevenK> Like a 10mm screw isn't going to come out to anything sensible in inches
<apachelogger> NCommander: you noticed ubuntu4 is already @ lp?
<NCommander> What, someone updated it since I started working on it?
<NCommander> ;.;
<apachelogger> NCommander: no, it is your ubuntu4 :P
<NCommander> o_O;
<NCommander> uhhhh
 * NCommander blinks
 * NCommander blinks some more
<NCommander> I don't remember asking anyone to upload it
<StevenK> Certain developers may have access to your machine ...
 * StevenK chuckles
<apachelogger> Oo
<NCommander> Well
<NCommander> This is interesting
<NCommander> Since if my patch was done wrong
<apachelogger> More like frightening.
<NCommander> I just broke ever QT Java user on i386 :-)
<apachelogger> NCommander: Qt
<apachelogger> and there are only about 3, so... :P
<NCommander> I really wish there were only i386 users
<NCommander> We could justify dropping the port
<StevenK> You want to drop i386?
<NCommander> Someday
<NCommander> Simply because the x86 infrastructure is a poorly decided POS :-)
<NCommander> er, designing
<NCommander> Looking at the build log, my patch did the right thing :-)
 * NCommander notes it will break if qtjambi was ever built on a 128 or 16 bit architecture but I don't think we need to worry about that)
<NCommander> YOu know, I think I have a problem if ninja's are uploading my patches without me fully testing them >.>;
<NCommander> StevenK, so what are you up to?
<blaine00__> hello!
<blaine00__> why does it seem like no one is ever actuall chatting in these rooms
<ion_> Wow, four minutes of patience.
<jdong> ion_: better than average.
<jdong> ion_: I've seen someone enter, say nothing, then "why don't you answer me" then leave
<jdong> *shrug* guess it's kinda like forgetting to put your name on a homework :)
 * Hobbsee is not chatting, as she's considering writing a warning mail to the list.
 * jdong cowers in his corner
<Hobbsee> jdong: do you file sync requests,  when the resulting packages do not install?
<jdong> Hobbsee: usually I don't get people more important than me involved until I'm confident I'm not wasting their time :)
<jdong> Hobbsee: are people just treating sync request as some magical buzzword for getting shiny crack, or are they deliberately implying something works when they've not done the testing necessary?
<Hobbsee> jdong: not sure, but i was just alerted to https://bugs.edge.launchpad.net/ubuntu/+source/meta-gnome2/+bug/273015
<ubottu> Launchpad bug 273015 in meta-gnome2 "cannot install gnome & gnome-office packages" [High,Confirmed]
<Hobbsee> jdong: the guy usually has more clue.  So should the sponsor.
<jdong> Hobbsee: ouch, that should've been caught even by a simple build-and-install test
<Hobbsee> jdong: my thoughts exactly.
<Hobbsee> jdong: there's even pbuilder hooks for this!
<jdong> indeed
<jdong> Hobbsee: the warning e-mail should also remind sponsors to scrutinize contributions a bit more, too
<jdong> IMO the sponsor should've seen this too
<Hobbsee> jdong: tha'ts what i'm thinking.
<Hobbsee> jdong: this slipped through 2 people.  Now, i know the queue is long, and we're trying to encourage people to sponsor stuff - but not at the expense of getting crap that doesn't install, into the archive.
<jdong> Hobbsee: particularly at this point in our release cycle
<Hobbsee> jdong: exactly.
<jdong> Hobbsee: whoa... looking at the sync request the contributor even had to make debian/control changes for the merge.... now it really blows my mind how this slipped through
<jdong> I would expect the most important test of metapackages to be their *installability*
<Hobbsee> jdong: the "it built, lets ship it?" philosophy?
<jdong> they should trivially build without errors
<Hobbsee> well, yeah...
<Hobbsee> i mean, pbuilder hooks make this stuff *very* simple.
<Hobbsee> and automated on the end of a build.
<jdong> perhaps whatever pbuilder helper is in ubuntu-dev-tools should incorporate such hooks by default
<jdong> I have a feeling people may be too lazy to bother setting it up
<Hobbsee> jdong: that might be interesting - but which ones?
<Hobbsee> there's a help section on the end of the pbuilder howto, iirc.
<calc> gar openoffice.org-l10n failed after 6 hours build on my machine :\
 * calc ponders guessing he fixed it and just upload it
<superm1> slangasek, it appears the combination of bluez-utils 3.36 and btusb causes the regression
<superm1> slangasek, persia and i were discussing it in #ubuntu-motu
<superm1> btusb - which is part of 2.6.27 appears to work properly w/ bluez 4.x however
<superm1> which is the new API for bluez
<superm1> slangasek, i'll try to add these details to the bug
<Hobbsee> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<fargiolas> does anybody know how can I install debug infos for libselinux?
<fargiolas> I looked for the -dbg package but couldn't find any
<persia> fargiolas: Maybe at ddebs.ubuntu.com ?
<fargiolas> persia: thank you, I wasn't aware of that repo
<StevenK> cjwatson: Adding a blacklist of xfce4-panel to the mobile seeds ends up with germinate saying "No changes found" which strikes me as odd.
<cjwatson> germinate-update-metapackage doesn't do anything with blacklists
<cjwatson> I suppose you'd have to manually add a conflicts or something
<StevenK> cjwatson: That strikes me as a little nasty :-)
<cjwatson> StevenK: it's more or less precisely equivalent to a blacklist entry ...
<cjwatson> so no more or less nasty
<cjwatson> if you're happy to use a blacklist entry, logically you should also be happy to use a conflicts
<cjwatson> anyway, off to ante-natal class
<fargiolas> persia: I added ddebs repos to sources.list but still I have no -dbg package for libselinux in intrepid
<geser> fargiolas: try libselinux1-dbgsym
<geser> fargiolas: the dbg packages on ddebs end all in -dbgsym and not -dbg
<fargiolas> geser: I see, but there is no package -dbgsym for selinux :(
<geser> fargiolas: the selinux package contains only some scripts
<geser> for which binary/library do you need dbg info?
<fargiolas> geser: I have a segfault with gst-inspect on a plugin I'm developing and the backtrace says it crash on a libselinux function
<fargiolas> geser: but doesn't say which because there are no dbg symbols
<geser> fargiolas: does it tell you in which lib that function is?
<fargiolas> geser: nope, 0xb66b8974 in ?? () from /lib/libselinux.so.1
<geser> fargiolas: /lib/libselinux.so.1 is the lib containing the function, which is packaged in libselinux1 and the debug symbols are in libselinux1-dbgsym
<geser> try installing that and you should get some more info in your traceback
<fargiolas> geser: probably in hardy.. no -dbgsym in intrepid
<geser> true
<geser> fargiolas|afk: unfortunately there aren't any debug symbols for libselinux1 as the package doesn't use the common dh_strip call to strip the debug symbols so it also doesn't trigger the creating of the -dbgsym packages :(
<fargiolas|afk> geser: is it a bug? will it be solved before intrepid stable release?
<geser> more a wishlist but and I doubt it will be fixed before the release, but please file a bug nonetheless, so it's a least known
<fargiolas|afk> geser: going away now, I'll file it later
<fargiolas|afk> geser: thanks
 * \sh should get some sleep...uploading to hardy pocket will not work :(
<Adri2000> do main srus need to be approved *prior* to upload? or is it possible to upload and get the ack later like it is for universe srus?
<wgrant> lool: Why did you close bug #275158? You should really let Soyuz close it, particularly when things have a chance of rejection.
<ubottu> Launchpad bug 275158 in xfree86-driver-synaptics "Please enable a build for lpia" [Medium,Fix released] https://launchpad.net/bugs/275158
<persia> wgrant: source built on Debian
<wgrant> persia: Ahh.
<ramvi> How is the daily intrepid image made? I'm making a fork of ubuntu and would like to utilize the same system
<persia> ramvi: At least the filesystem.squashfs comes from livecd-rootfs.  I'm not entirely sure how that turns into an iso, but there's a BuildCD script in the livecd-rootfs source.
<ramvi> persia: must be some kind of application which does the whole thing. should be open source :/
<persia> ramvi: It may be, I just don't happen to know which application.
<persia> There's some documentation on the wiki about working on this sort of thing, which may help.
 * persia doesn't tend to work with .iso images
<ramvi> persia: there is? Great - do you have the url ?
<ramvi> So can I do some reading and not bother you guys
<persia> Not offhand.  I think it's linked under the Derivatives Team.
<Mithrandir> ramvi: https://help.ubuntu.com/community/LiveCDCustomization
<StevenK> [1067796.457016] nautilus[19240]: segfault at 7fffcdb08ff8 rip 7fb8c26a87db rsp 7fffcdb09000 error 6
 * StevenK sighs
<ramvi> Mithrandir: not quite what I was looking for. But thanks :)
<StevenK> Mithrandir: I had a look at telepathy and bluetooth, and I can't extend my own membership, please fix. :-)
<Mithrandir> StevenK: fixed
<StevenK> Mithrandir: Danke
<Robot101> telepathy? :)
<Mithrandir> Robot101: yeah, you know this communication thingie developed by a bunch of crazy hippies based around cambridge.
<Robot101> yeah, but what about it? can I extole its virtues somehow? :)
<Mithrandir> Robot101: oh, it was just StevenK's membership in the launchpad team that was about to expire, and he couldn't extend it himself, so I did it for him.
<Robot101> aha, ok :)
<pochu> Mithrandir: could you please reject meta-gnome2 from the unapproved queue? I want to reuploaded it with a last minute improvement.
<pochu> s/reuploaded/reupload/
<lool> wgrant: Cause I built the .changes files from a Debian host
<lool> wgrant: Oh sorry, persia already forwarded the info
<lool> Will update the bug if it gets rejected; I'm sure persia will notice though :)
<persia> Yeah.
 * persia is currently anxiously awaiting the approval of 75% of the unapproved queue, as it directly affects making the new toy work better.
<Silicium> hi there
<Mithrandir> pochu: no, the web ui doesn't allow me to.
<Silicium> is there a bug on 8.04 with cpu freqscaling
<Silicium> ?
<Silicium> my kernel is Linux Earth 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
<Mithrandir> pochu: also, I'm no longer in ubuntu-archive.
<pochu> Mithrandir: but you are on -release. I thought it was -release who approved/rejected things during freezes
<pochu> Mithrandir: thanks anyway
<Mithrandir> pochu: I don't have the relevant buttons in my web UI at least.
<pochu> ok, fair enough
<pochu> slangasek: so, I've changed python-wxgtk.postinst to install one different alternative for each python version (http://pastebin.com/f602f101d). The problem is that python-wxgtk2.8 doesn't use alternatives anymore, but installs a file directly, which seems to break update-alternatives (install 2.6, symlinks are there and working, install 2.8, files are there and working, remove 2.8, and 2.6 symlinks aren't there anymore). I can switch python-gtk2.8
<pochu> slangasek: 2.8 was changed back to use files instead of alternatives in bug 211553, but I think that broke python-wxgtk2.6
<ubottu> Launchpad bug 211553 in wxwidgets2.8 "wxPython isn't on path in hardy beta" [Medium,Fix released] https://launchpad.net/bugs/211553
<pwnguin> is /var/log/acpid still supposed to be written to?
<lool> No
<lool> It's syslog now
<pwnguin> i wish the laptop team wasn't dead =(
<pwnguin> lool: i'd like to monitor for lid events, is that in syslog?
<persia> pwnguin: You ought get an input event for it, from evdev.
<pwnguin> persia: is that exposed to scripting somewhere simple?
<persia> pwnguin: It's an X event.
<persia> I suspect there's probably something that calls a hook script, but I'll admit to not knowing the details.
<pwnguin> tabletPCs have a convertable lid and im hoping the information is sophisticated enough to handle differing between closing the laptop and converting it
<persia> pwnguin: For that, I'd recommend installing input-utils, and reviewing what events are available from the /dev/input/eventN device.
<persia> pwnguin: If you can differentiate, I'd like that: I've a device for which I'd like to do a screen rotation on close, but haven't any clue how to make it work.
<persia> (so please subscribe me to the bug you use to track the fix)
<pwnguin> okies
<pwnguin> do you have a script working currently to rotate automatically?
<pwnguin> err
<pwnguin> not automatically
<persia> No.  I just got the device a couple days ago, and just make the touchpad work today.  It's still a work-in-progress.
<pwnguin> there's a few rotate scripts out there
<persia> Yeah, and I do have one working on my Zaurus, so I'm sure it's not too hard.
<pwnguin> the trouble is that they mostly rely on querying xrandr which relies in part on the driver
<pwnguin> so nv has different output than nvidia
<persia> Oh, that's unfortunate.
<pwnguin> theres an xrandr library one could presumably use
<pwnguin> that should be smarter than text output
<pwnguin> when you suggested input-utils, what exactly did you have in mind with it?
<pwnguin> ah, i think ive figured it out
<ykphuah1> asac: for bug 191889, I do not have the intrepid environment to create a fix for NM0.7... how do you suggest I go around this?
<ubottu> Launchpad bug 191889 in pidgin "[MASTER] [WORKAROUND] "Offline Mode" feature fails to detect proper online state for networks that are managed outside of network manager." [Undecided,Confirmed] https://launchpad.net/bugs/191889
<crimsun> ykphuah1: are you working off hardy as a base?
<crimsun> ykphuah1: if so, try working with the network-manager PPA, then, which has a hardy version (# deb http://ppa.launchpad.net/network-manager/ubuntu hardy main)
<ykphuah1> crimsun: yeah, I am working on hardy, its just scratching my own itch on the stable ubuntu version, for now.
<ykphuah1> crimsun: the last time I install the NM0.7 over PPA, its very hard to downgrade back to 0.6, with all the dependancies.
<ykphuah1> crimsun: so it seems like either I have to maintain 0.6 or 0.7, or install both hardy and intrepid.
<ykphuah1> crimsun: I am just a normal user who do not have the bandwidth to download intrepid just to develop a patch for NM 0.7
<RainCT> Can someone tell me where the strings "Install Media Plug-ins" and "Buy Licensed Plug-ins..." are used in gnome-app-install?
<RainCT> (I'm translating some new strings, like those, but don't have the version from Intrepid so I can't see where they are used)
<RainCT> basically what I want to know is if they are directed to the computer or to the user
<Chipzz> RainCT: strings directed to the computer should not be translated; if those show up in the list of strings to be translated, that would be a bug and you should file one
<RainCT> Chipzz: that's not what I mean by "directed to the computer"
<pochu> RainCT: they are shown when gnome-app-install pops up to install media codecs iirc
<RainCT> Chipzz: there are two sorts of strings, those directed to the computer, by which I mean strings like "Save", "Print", etc., and those directed to the user "Couldn't do something", etc.
<RainCT> and both types are translated in a different way in Catalan (to the computer in imperative and to the user in a more formal way)
<RainCT> pochu: as buttons or what?
<pochu> RainCT: https://wiki.ubuntu.com/CodecInstallationIntrepid
<pochu> RainCT: I haven't seen IRL yet
<Chipzz> RainCT: ah k. but you probably should have been clearer about that then ;)
<RainCT> thanks :)
<Chipzz> (RainCT: the distinction lies in the target language, not the source of the translation)
<RainCT> I guess "playback plug-ins" is the same as "codecs"?
<Chipzz> http://www.ralentz.com/old/mac/humor/mpw-c-errors.html
<Chipzz> ROFL
<Chipzz> "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
<Chipzz> a compiler with an attitude :)
<Chipzz> "Too many errors on one line (make fewer)"
<Chipzz> :P
<slytherin> Can any of the archive admins please fix the bug #272866
<ubottu> Launchpad bug 272866 in javassist "Please move package to universe" [Undecided,Confirmed] https://launchpad.net/bugs/272866
<lool> pwnguin: You can add your own event handler to /etc/acpi; there's an example for the powerbtn already, it's mildly documented in README.Debian
#ubuntu-devel 2008-09-28
<cjwatson> pochu: I've rejected meta-gnome2 at your request
<pochu> cjwatson: thanks
<pochu> cjwatson: reuploaded, in case you can approve it
 * pochu waves good night
<cjwatson> pochu: approved - in future you probably should credit changes you make to yourself rather than listing them under somebody else's changes though!
<pochu> cjwatson: they are not my changes, I noticed Pedro had added a new debdiff just after uploading the previous one
<pochu> but it's Pedro's debdiff without any change
<pochu> https://bugs.edge.launchpad.net/ubuntu/+source/meta-gnome2/+bug/273015 ftr
<ubottu> Launchpad bug 273015 in meta-gnome2 "cannot install gnome & gnome-office packages" [High,Fix released]
<cjwatson> pochu: ok
<sistpoty> hi, can any archive-admin please reject my upload of gnome-iconedit? (my mirror is outdated, and I've only found out right now that it was removed a few hours ago :()
<wgrant> Hmm, the new default background reminds of Hoary, I think.
<slangasek> pochu: I'm thinking that the alternative is still the right way to do it, and that python-wxgtk2.8 has a separate bug, so I would argue for fixing both to use alternatives right
<emgent> gmoin
<calc> yipee OOo 3.0 rc2 finally finished building
<Hobbsee> Mithrandir: why doesn't hte web UI allow you to reject packages?
<Hobbsee> oh, lack of u-a.  right
 * Hobbsee rejects gnome-iconedit
<fargiolas> geser: I opened that bug (libselinux) we were talking about yesterday -> LP #275082
<ubottu> Launchpad bug 275082 in libselinux "no debug symbols package in intrepid" [Undecided,New] https://launchpad.net/bugs/275082
<emgent> tseliot: o/
<tseliot> emgent: hi
<fargiolas> geser: thanks
<Hobbsee> tseliot: ping?
<tseliot> Hobbsee: hi
<tseliot> anything I can help you with?
<Hobbsee> tseliot: i was looking through unmet deps recently, and it seems that there's still a fair chunk of nvidia-type stuff on there.  Were you planning to examine it, and hopefully make some of the stuff installable again?
<Hobbsee> Presumably you're one of the better people to do it
<tseliot> Hobbsee: unmet deps? Any examples I can have a look at?
<Hobbsee> tseliot: apt-cache unmet -i
<Hobbsee> tseliot: grep as appropriate
<tseliot> Hobbsee: aah, the -envy flavours. I thought we removed them
<Hobbsee> tseliot: unsure.  it appears not.
<tseliot> I'll make sure they are removed from Intrepid
<Hobbsee> tseliot: cool, thanks :)
<tseliot> Hobbsee: thanks a lot for reporting the problem :-)
<Hobbsee> tseliot: thanks in advance for fixing it :)
<tseliot> ;)
<persia> tseliot: Do you not need them to ensure safe upgrades from hardy?
<persia> (obviously, being installable is good, but in terms of packages names: are dummy packages required)
<tseliot> persia: I'm working with mvo on this. Nvidia-common and Update manager should help users with the transition.
<tseliot> even if users dist-upgrade from the command line they will be warned by nvidia-common's debconf dialog
<tseliot> otherwise Update Manager will install the new drivers automatically
<persia> Hrm.  OK.  Personally, I generally believe the need for hints in update-manager represents a bug, and we ought try to do it with dummy packages, but given the complexity of this particular transition, debconf may work.
<tseliot> persia: unfortunately Nvidia dropped the support for a few cards and 2 out 4 driver flavours don't work in Intrepid
<tseliot> therefore some users will have to be migrated to the open source driver while others will use the new proprietary drivers
<tseliot> but yes, I see your point
<persia> tseliot: Ah, so there not really a package -> package mapping, but more a new and different card -> driver mapping.  Yeah, that requires hints.
<tseliot> persia: yes, exactly
<ion_> Provides-Driver: pci:v00001002d00004150*, ...
<ion_> :-)
<tseliot> hehe
<persia> ion_: Surely you don't actually want to fill *everyone's* apt cache with that sort of thing (also see http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/ )
<ion_> I donât. :-) It wasnât a very serious suggestion.
<Hobbsee> persia: someone has *far* too much time on their hands ;)
<persia> Hobbsee: Or a deep understanding of package management, and a desire for more complex test cases to improve performance.  Depends on how you want to look at it.
<Hobbsee> persia: in that case, i'm surprised he hasn't expressed aptitude and/or apt in brainfuck, or something.
<persia> The idea is to *improve* performance
<ion_> hobbsee: I wanted to keep track of my circadian rhythm. So i wrote a program to keep track of my computer usage. It figures out when iâm sleeping more or less automatically. And i wrote a program that creates a graph of the data. :-P
 * persia doesn't generally participate in language wars, but that's an exceptional language
<Hobbsee> ion_: heh.  That sounds vaguely useful - although, do you only sleep and use a computer?
<ion_> I tend to use it to print all intervals i have been idle for more than an hour (ruby -I~/src/own/idlemeter/ruby -ridlemeter -e 'puts IdleMeter::Analyze.intervals.find_all {|i| i.mode == :idle and i.length >= 3600 }') and pick the ones during which i was obviously sleeping. It can be made a bit more intelligent, though, see http://heh.fi/tmp/idlemeter.
<ion_> One could always implement some kind of a self-learning network. ;-)
<ompaul> juliux, had to restart gnome - big fail
<ompaul> juliux, now for massive lag ping me a lot for the next minute or two
<psyke83> \sh: hey, it seems that ia32-libs is still causing problems for the latest flash plugin, do you have any idea what's wrong?
<Cheery> I've realised this weird keyboard I have has bunch of buttons that have stuff like screen brightness and such
<Cheery> and 7 F-buttons than usual
<Cheery> 7 more*
<Treenaks> Cheery: do they work?
<Cheery> some of them do!
<Cheery> this is apple's flat keyboard
<Cheery> but I realise the desktop does not perhaps even recognise two of the buttons on this keyboard
<Cheery> the F-buttons appear to be function buttons, and have fn-buttons under them
<Cheery> which can be used through fn-button that's on the place of insert
<Cheery> the two unrecognised buttons are those special buttons, that become F3 and F4 through fn-button
<ion_> Darn. No MPX support in intrepidâs xorg, it seems. Oh well, weâll have intrepid+1 soon.
#ubuntu-devel 2009-09-21
<wamty> Shortly after starting the install I get "Call Trace:" and then "Code: e6 01 00 90 etc"
<wamty> any ideas?
<TheMuso> wamty: I suggest you file a bug against ubiquity in launchpad.
<wamty> ?
<TheMuso> As the people who are most likely to be able to help you are not likely to be around at the moment.
<wamty> what do u mean
<wamty> why not
<TheMuso> Well for one thing, its almost midnight where the installer maintainers live.
<wgrant> Because it was Sunday for them until 7 minutes ago.
<TheMuso> wamty: /c
<wamty> what does that mean?
<TheMuso> wamty: sorry that was a typo
<TheMuso> wamty: To file a bug, I suggest you have a read here. https://help.ubuntu.com/community/ReportingBugs
<wamty> maybe its not a bug
<wamty> i dont know wha it is
<wamty> s
<TheMuso> wamty: A call trace sounds like a bug to me.
<Chipzz> call trace sounds like a kernel oops to me
<Chipzz> especially with teh "Code: ..." after it
<superm1> pitti, ping.  i wanted to ask you about letting users report bugs for packages from PPAs that are very close to upstream code, so that apport doesn't complain about them being non-genuine packages.  we recently (today) switched one of the mythtv trunk PPAs to build in debug mode, so between the dropping of optimizations and the dh_strip not doing any stripping for PPA builds, I think these should be pretty useful to upstream
<apw> anyone know what injects dbus messages for new devices ?
<lifeless> udev?
<Amaranth> lifeless: I thought udev had its own protocol
<ScottK> superm1: Where would they be filed?
<apw> lifeless, maybe, maybe, or do you _know_ its that
<lifeless> Amaranth: so udev listens to the kernel; the get-rid-of-hal work consists of udev events that translate and broadcast to dbus
<lifeless> apw: I'm 95% sure
<superm1> ScottK, against the same source package in the archive
 * Amaranth checks code
<apw> in jaunty it looks like its hal
<superm1> i think for some projects it makes a lot of sense still
<ScottK> superm1: I think that's horribly inappropriate.
<lifeless> apw: in jaunty it is hal
<apw> in karmic it is _noone_ for me
<superm1> ScottK, i'd be fine with a whitelist, or drop a file in place to make it activated for any particular blessed package
<lifeless> there was a massive thread on d-d recently about this in the context of systems with /usr on separate fs's.
<Amaranth> apw: hal should still be around to do that, it is used for xorg still
<superm1> ScottK, but i'm sure that other projects with daily builds can get the same kind of benefits like this too then
<ScottK> superm1: I think what it needs is a different place to land non-ubuntu bugs.
<apw> hal is seeing the new devices i insert, just nolonger am i seeing dbus events, therefore gnome doesn't do it
<ScottK> superm1: I think it's great, just not against Ubuntu.
<Amaranth> apw: gnome uses udev
<apw> Amaranth, 'used' udev .. how is it plumbed in?  do you know?
<apw> uses even
<Amaranth> lifeless: it looks like udev doesn't have a dbus dependency
<Amaranth> apw: via libgudev?
<apw> Amaranth, hrm, thanks will look at that
<Amaranth> apw: yeah, gvfs depends on libgudev
<lifeless> Amaranth: I likely have the fine detail wrong; I do recall the transition and that its udev's problem now ;)
<Amaranth> so nautilus uses gio which uses gvfs which uses libgudev which is actually a wrapper around libudev which uses udevd
<Amaranth> Wow I would hate to debug that
<apw> so we might not expect to see dbus events now then
<apw> i do have udev events for the new devices
<Amaranth> apw: Well like I said we still have hal around for xorg so hal should still be reporting device connections
<apw> it maybe meant to be, but its not
<Amaranth> maybe it was crippled somehow *shrug*
<apw> i have the problem that i know whats not happening, but not whats normal
<apw> yeah half finished sometrhing i expect
<james_w> apw: devicekit-disks
<james_w> for disks
<james_w> other things for other types of hardware
<james_w> there's no single thing like hal anymore
<james_w> if there is a daemon corresponding to what you are trying to do then using the DBus connection to that works
<Amaranth> ah, right, forgot devicekit-disks is still around
<james_w> otherwise libgudev or similar to listen to udev events would work
<james_w> if it has to be DBus then a devicekit-* for the class of hardware that translates from udev to DBus would be needed
<Amaranth> devicekit-disks and devicekit-power are the only ones
<james_w> yep
<apw> james_w, thanks for the info
<apw> it appears that /usr/lib/gvfs/gvfs-gdu-volume-monitor is finding out about it directly from udev
<apw> i wonder what that actually does
<apw> but gvfs itself does not appear to get told
<sladen> fatal: I had/have the ultimate blackness too
<sladen> fatal: if fsck is running, it could be 10 minutes+ of blackness before xsplash+gdm start
<sladen> fatal: and (recovery mode) doesn't do anything
<jdong> directhex: heh just noticed the nspluginwrapper bug too
<the_dark_warrio> What are the kernel modules that control webcams?
<jdong> many.... uvcvideo is one of the more common ones
<the_dark_warrio> I was wondering if it is possible to control exposure time
<jdong> I thought typically that's something automatically controlled by the camera
<the_dark_warrio> indeed it is
<jdong> typically exposure time increases with the decrease of ambient light :)
<the_dark_warrio> but I'm doing some science experiments, and the autoexposure is screwing everything ;)
<jdong> probably a webcam isn't your best tool in that case
<the_dark_warrio> I see
<jdong> here in our MIT intro biophysics classes we use a firewire fancy module
<jdong> which does allow every capture parameter to be controlled by software
<the_dark_warrio> nice
<the_dark_warrio> you mean a firewire camera?
<jdong> yeah, some sort of firewire connected camera
<jdong> interfacing with a Ubuntu UI
<jdong> I'm only a customer of the setup so to speak, though :)
<the_dark_warrio> ;)
<the_dark_warrio> thanks for the hints! I will research more
<the_dark_warrio> cya
<jdong> sure thing
<TheMuso> c
<Vantrax> anyone here have experience with kerberos and capaths?
<glicks> excuse me, im trying to compile a vanilla kernel in ubuntu, whats the command to make a .config file from the current running kernel?
<pitti> Good morning
<pitti> superm1: you can ship a small code snippet which makes them being reported against the product (see /usr/share/doc/apport/crashdb-conf.txt); is that what you need?
<superm1> pitti, interesting, that looks like it would do the trick
<superm1> just need to find a way to integrate it without disturbing standard packages (they use the same bzr branch)
<pitti> superm1: perhaps like this:
<pitti> superm1: ship a crashdb.conf.d/mythtv.conf with a "mythtv" db (use launchpad_impl and set 'product': 'mythtv')
<pitti> superm1: and then ship a package hook which checks the version (ppa or not) and sets report['CrashDB'] = 'mythtv' for PPA packages
<superm1> pitti, ah yeah, that sounds like the perfect way to do it. thanks!
<pitti> superm1: please let me know about troubles; crashdb-conf.txt and package-hooks.txt.gz aren't very verbose about this yet
<superm1> pitti, will do.  i'll try'n sort out the details for it this week
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<wgrant> pitti: Do you have a few minutes to talk about the archive administration side of Soyuz ddeb support?
<pitti> wgrant: sure
<wgrant> pitti: So, ddebs are represented in Soyuz just like normal debs. This means that at the moment they don't follow their debs around, so removals/overrides/copies of a binary will not drag along the ddeb. This seems like it could get pretty tedious.
<wgrant> So I'm going to implement some improvements which will cause overrides/removals of a deb to also detect and operate on the deb.
<wgrant> Sounds sane?
<pitti> absolutely
<pitti> I don't see why we should have the ddeb in a different component
<wgrant> Right. It'll also need some tricks to automatically inherit the deb's overrides at upload-time, to avoid pushing *every* binary through new once we hit the button.
<wgrant> Now, ddebs will be removed from the archive indices as soon as they're superseded. That's not a good thing for the retracers, is it?
<pitti> wgrant: it's what we currently have
<pitti> wgrant: I think it's fine for the Packages.gz files
<pitti> wgrant: they don't disappear from LP, I recently learned how to retrieve all files from any build through launchpadlib
<pitti> so if we wanted to make the retracers more clever about older versions, we could still do it
<wgrant> pitti: OK. They'll be removed from the archive disk immediately, but will still be available from the librarian.
<pitti> *nod*
<wgrant> You'll probably need to manually NBS out ddebs, unfortunately.
<pitti> wgrant: that sounds scriptable, though
<wgrant> I can't think of a way around that, so I hope it's OK.
<pitti> wgrant: where will they land? not on archive.u.c., I hope?
<wgrant> pitti: No. They will exist in an entirely separate archive.
<pitti> wgrant: it would be great if we could just move ddebs.u.c. to point to that archive
<wgrant> Otherwise it would be really easy.
<wgrant> pitti: That would be good, although there is the slight problem that none of the old ddebs will be in the new archive.
<pitti> ah, bummer; we can't 'seed' them?
<wgrant> Not exactly. While it's probably technically possible, it seems like a pretty awful thing to do (inject binaries into builds).
<wgrant> You might just have to leave the retraces also pointing at the old archive for a while. Or convince somebody that the evil required to do the import is justified.
<pitti> wgrant: ok, so I propose we keep ddebs.ubuntu.com/old/ around on macaroni, and point the main ddebs.u.c. to the new archive
<pitti> so for a while we use both
<wgrant> pitti: Sounds sane.
<wgrant> I think that's probably it. Let me think....
<tseliot> pitti: where's the jockey handler for bcmwl?
<tseliot> pitti: aah, it's only in the ubuntu branch. Never mind
<ManDay> Hello have been told to come here as I ve got a problem with glibc. Upon fatal runtime errors the backtrace is written to the tty directly rather than stderr, which renders it impossible to redirect the error to something like less in order to read it. Is that a well known problem with the runtime of glibc or just my specific problem?
<tseliot> pitti: if I (successfully) install the broadcom driver in Jockey, Jockey's interface doesn't refresh and it looks like it wasn't installed: http://paste.ubuntu.com/275109
<tseliot> (the module is loaded)
<pitti> tseliot: "unbind/rebind on driver /sys/module/wl/drivers/pci:wl: device 0000:03:00.0", nice so that actually works?
<pitti> tseliot: the handler doesn't rmmod b43 and friends, do you still have any of those loaded?
<pitti> tseliot: oh, wait, it does
<tseliot> pitti: no b43, etc. module is loaded
<pitti> tseliot: does 'lsmod | egrep '43|ssb' still show anything?
<pitti> tseliot: ah, I think I know what's going on; could you test something for me?
<tseliot> pitti: http://paste.ubuntu.com/275115
<tseliot> pitti: sure
<pitti> tseliot: in broadcom_wl.py, enable(), after KernelModuleHandler.enable(self) (i. e. very last line)
<pitti> OSLib.__load_module_blacklist()
<pitti> append this
<pitti> KMH.enable() will install the package, which installs the blacklist
<pitti> but jockey doesn't update its blacklist cache
<tseliot> pitti: wouldn't it be something to add to enabled() instead (which I assume you call after enable() to make sure that it worked)?
<tseliot> just asking
<pitti> tseliot: I think enable() is better, enabled() is called much more often, and is only a read operation
<tseliot> pitti: ok, let me try
<tseliot> pitti: it complains that class OSLib has no attribute '_BroadcomWLHandler__load_module_blacklist or, if I remove the 1st underscore, TypeError: unbound method _load_module_blacklist() must be called with OSLib instance as a first argument (got nothing instead)
<pitti> tseliot: oops, sorry; it's just a single _, not two __
<tseliot> pitti: which gives me the 2nd part of my previous message
<pitti> tseliot: so, it's correctly:
<pitti> OSLib.inst._load_module_blacklist()
<pitti> (forgot the .inst as well)
<tseliot> ok, let me try again
<tseliot> pitti: that seems to work
<evand> pitti: any further thoughts on bug 432542?
<ubottu> Launchpad bug 432542 in usb-creator "UI freeze exception for usb-creator 0.2.7" [Undecided,Incomplete] https://launchpad.net/bugs/432542
<evand> also, do you think a new upload of devicekit-disks is warranted for 007, or should we just cherry pick the crucial patches from it?
<pitti> evand: hi
<pitti> tseliot: great, will commit
<evand> hi pitti
<tseliot> pitti: thanks
<pitti> tseliot: in fact, I should commit that to trunk to the generic Handler, since other packages could install blacklist files as well
<pitti> evand: DK-disks 007 is in karmic, needed by new gnome
<pitti> evand: usb-creator> I'll do a quick review of the PK backend, still on my todo list
<evand> ah, I didn't think to check this morning
<evand> good deal
<evand> thanks a bunch!
<tseliot> pitti: right, even better
<wgrant> cjwatson: Can you try newComponentUploader again and get an OOPS ID at some point, please?
<cjwatson> wgrant: remind me how I get the OOPS ID out of the API?
<wgrant> cjwatson: Try catching the exception and check the 'content' attribute.
<pitti_> tkamppeter: hi! did you recently reorganize openprinting.org? my jockey test suite fails now, it doesn't find the "openprinting-ppds-postscript-hp" package for 'MFG:Hewlett-Packard;MDL:HP LaserJet 3020' any more
<cjwatson> wgrant: confused; e.content is (<Archive at 0xbd1f490>, 'newComponentUploader', 'launchpad.Edit')
<cjwatson> wgrant: and the HTTP code is 401 unauthorized
<cjwatson> so no longer an internal server error, which IIRC it was over the erweekend
<pitti_> tkamppeter: I change the tests to "DesignJet 3500CP" now, according to http://www.openprinting.org/show_printer.cgi?recnum=HP-DesignJet_3500CP
<wgrant> cjwatson: You gave launchpadlib full write access? Because... you own the archive.
<cjwatson> I *think* so, but I'll try again
<pitti_> DrPepperKid: hey Mirco :)
<MacSlow> pitti_, I'm here in my "alter ego" form just for debugging :)
<ogra> cjwatson, whats up with your locales today ? its the second time i see weirtd cahrs from you
<ogra> *weird
<soren> ogra: I don't see anything weird?
 * pitti_ doesn't either
<ogra> the erweekend
 * wgrant neither.
<ogra> i see er, then two squares and then weekend attached to it
<pitti_> just a normal '.' here
<soren> I don't see the two squares.
<ogra> strange
<cjwatson> it's not locales, it's that my network is ridiculously laggy and so irssi/ssh is exhibiting some weird knock-on effects from typeahead
<ogra> well, but i see stuf interpreted others dont, must be me then
<ogra> *stuff
 * sistpoty|work sees it two (running debian/stable here at work)
<pitti_> weechat might just filter it out
<cjwatson> wgrant: my bad - that seems to have worked fine now. I think I had two oauth tokens with the same identifier but different privilege levels and was therefore confused. :(
<sistpoty|work> too
<cjwatson> the squares were probably raw backspace characters or something
<wgrant> cjwatson: So it didn't even 500 this time?
<cjwatson> wgrant: apparently all good now ...
<wgrant> cjwatson: Strange, but great!
<cjwatson> ubuntu-dev should have give-back access to that archive now, then
<wgrant> cjwatson: Thanks.
<zul> morning
<doko> asac: time to fix the xulrunner-1.9.1 build on sparc, powerpc, ia64?
<sistpoty|work> doko: mind to take a look at bug #433368? (if you want, I can try to provide a minimal test case)
<ubottu> Launchpad bug 433368 in gcc-4.4 "[regression] lensfun 0.2.3-0ubuntu4 freezes UFRaw." [Undecided,Confirmed] https://launchpad.net/bugs/433368
<doko> sistpoty|work: gcc-snapshot results?
<sistpoty|work> doko: haven't checked with gcc-snapshot yet
<sistpoty|work> doko: will do (but only an half an hour or so... must leave for a meeting in 5 minutes)
<doko> sistpoty|work: hmm, we had something similiar, 4.4 only reserves storage so that all values of the enum fit. does adding an UINTMAX value in the enum type help?
<sistpoty|work> doko: I haven't checked that yet, but I'd think so.
<asac> doko: ia64:
<asac> The following packages have unmet dependencies: cdbs: Depends: intltool but it is not going to be installed mozilla-devscripts: Depends: libxml-xpath-perl but it is not going to be installed
<asac> xpidl crashes on ppc
<asac> sparc i have a fix for
<cjwatson> asac: retry ia64
<cjwatson> it was broken, it should be somewhat better now
<cjwatson> in fact, I'm on the page anyway, I've retried it
<doko> sistpoty|work: then it's a bug in the code ... see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
<ubottu> gcc.gnu.org bug 36917 in tree-optimization "[4.3 regression] miscompilation with -O2 and r136501" [Normal,Resolved: invalid]
<asac> thx
<sianis> mpt_: hi! at bug #433838 only Get Free Software menu item needs the icon on the location bar?
<ubottu> Launchpad bug 433838 in software-store "Use an icon in the location bar" [Low,In progress] https://launchpad.net/bugs/433838
<sianis> or Installed, etc, etc?
<mpt> sianis, *if* we did it, we should do it for all sections that have a path button, i.e. currently both "Get Free Software" and "Installed Software".
<sianis> mpt: right, I am posting a patch ...
<doko> asac: would you mind uploading the fix? you did tell me having the fix weeks ago ;p
 * asac checks powerpc porter machine
<sianis> mpt: patch's attached
<mpt> Thanks sianis. I'll put it on the list of things to user-test. :-)
<sistpoty|work> doko: ah thanks, that 36917 matches my observations. Just wasn't sure if it's legal to reduce the size of an enum. Thanks for looking!
<asac> doko: http://paste.ubuntu.com/275224/
<asac> doko: maybe libidl needs to be rebuild?
<asac> or any idea why something might crash in _savegpr_14 ?
<doko> asac: ENOCLUE. but why not check it on the porter box?
<asac> doko: I am on the porter box
<asac> doko: i cannot install libidl i locally built
<asac> at least not easily
<doko> and LD_LIBRARY_PATH doesn't work?
<asac> probably would
<asac> trying something else now
<asac> gcc-4.3 works
<tkamppeter> pitti, yes I did a change on OpenPrinting.org. I removed most HP PPDs, as they are maintained by HP in HPLIP but not any more on OpenPrinting.
<pitti> tkamppeter: ah, ok; thanks
<tkamppeter> The recommended driver for the LJ 3020 is HPLIP now as the appropriate PostScript PPD is part of HPLIP.\
<asac> doko: seems to a compiler bug or something further down. -Os makes it crash like the paste above ... -O2 and -O0 seem to work
<asac> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg17189.html
<doko> asac: and -Os is turned on by default?
<asac> yes
<asac> gcc 4.3 works
<doko> why do people turn it on on archs they don't use/test ...
<asac> at best we would just disable whatever feature triggers this
<asac> it worked before and noone complained. we can use -O2 on ppc, but that hides the problem imho
<hdon> hi everyone. i18n question. i have written a very basic gettext(3) test program. it calls setlocale(), bindtextdomain(), textdomain(), and then gettext() on commandline arguments, and prints the results to stdout. i have straced my program, and i see glibc looking in /usr/lib/locale and /usr/share/locale-langpack, but *not* in the directory i have specified to bindtextdomain(). is this some kind of ubuntu gettext caveat?
<doko> asac: yes, but extracting a test case takes time ...
<hdon> please help! i have spent way too much time on this already... :(
<mattn> hdon: is the path relative?
<cjwatson> hdon: I can't reproduce this with a trivial test program. Can you post your source code?
<hdon> mattn: it may be in the future, but at the moment i am specifying a relative path. are absolute paths not allowed?
<hdon> sure, one sec..
<pitti> hdon: it's supposed to work; it will fallback looking into .../locale-langpack/, but it's supposed to respect bindtextdomain
<cjwatson> http://paste.ubuntu.com/275270/ is my test
<mattn> it works here, too
<hdon> http://paste.ubuntu.com/275272/
<cjwatson> relative paths work for me too
<cjwatson> although I don't know that I'd expect them to be reliable
<hdon> cjwatson: thank you for experimenting with me. i wonder why i can't get this to work..
<cjwatson> calling setlocale on both LC_ALL and LC_MESSAGES is weird
<hdon> cjwatson: i know, i was just a little exasperated and added LC_ALL even though i am trying to use an LC_MESSAGES file
<mattn> hdon: what is the output of "locale"
<mattn> do you have that locale installed on your system?
<hdon> mattn: all en_US.UTF-8
<mattn> and you have fr_WHATEVER.UTF-8 installed on your system, too?
<hdon> mattn: see this:
<hdon> donny@pacemates:~/gpsee/gt$ dpkg -S /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo
<hdon> python-django: /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo
<mattn> nono, the system locale
<seb128> locale -a | grep fr
<mattn> i had to install e.g. russian to text our game with a russion translation
<mattn> s/text/test
<cjwatson> that's odd, your program is only triviallly different from mine but doesn't work
<hdon> nonetheless, i should be able to load this .mo file
<mattn> maybe - but it won't do anything with it if you don't have that locale
<cjwatson> mattn: I don't think this is relevant - it's failing for me even if I ditch the fr
<mattn> that's indeed strange
<hdon> mattn: hmm, ok, which package(s) do you think i should install to make my test program work?
<hdon> if your theory seems to work, then that will at least give me a direction to go
<hdon> cjwatson: have you tried watching in strace?
<mattn> hdon: language-pack-fr
<james_w> ttx: any reason for libgnumail-java-doc to be in main? It's trying to pull in classpath for just classpath-doc, and that pulls in a lot of other things
<mattn> not sure whether it's all needed - maybe there is a separate locale package, too
<hdon> cjwatson: here are the locations my glibc on Jaunty searches for the "fr" locale:
<hdon> /usr/lib/locale/fr/LC_IDENTIFICATION /usr/share/locale-langpack/fr/LC_IDENTIFICATION /usr/lib/locale/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES/SYS_LC_MESSAGES
<james_w> ttx: though I'm having a bit of trouble even finding what is keeping the -doc package in main.
<hdon> i generated that list with this command: donny@pacemates:~/gpsee/gt$ strace ./a.out Yes 2> log && echo `grep -o '[^"]*fr[^"]*' log`
<cjwatson> forget that, it doesn't matter
<hdon> mattn: incidentally i did install that package for kicks
<cjwatson> so the problem is that there is no such locale as "fr" *at all*, no matter what package you install
<cjwatson> it's not a valid locale name
<cjwatson> instead, you should just do setlocale(LC_MESSAGES, "") up top, and that will use the current locale
<cjwatson> (actually most internationalised programs just do setlocale(LC_ALL, "") up top)
<mattn> and maybe add LANG=fr ./yourApp
<cjwatson> no, LANG=fr is an invalid locale
<cjwatson> LANG=fr_FR>UTF-8
<cjwatson> err, LANG=fr_FR.UTF-8
<hdon> but i *do* have an fr locale. in fact i don't have an fr_FR locale. not in /usr/share/locale, nor in /usr/share/python-support/python-django/django/conf/locale
<cjwatson> no, you don't
<cjwatson> valid locales are those listed in the first column of /usr/share/i18n/SUPPORTED
<hdon> ah, hmm
<cjwatson> not subdirectories of /usr/lib/locale or whatever
<pitti> hdon: you have "fr" translations
<hdon> that is not mentioned in the gettext(3) manual
<hdon> pitti: ah, thanks. i was using the wrong term entirely then :)
<cjwatson> it's mentioned in locale(1)
<cjwatson> in the FILES section
<pitti> hdon: a translation is done for a language in most cases ("fr"); exceptions are countries with similar, but sufficiently differing languages such as Portugese and Brazilian Portugese, or British and American English
<hdon> cjwatson: thanks, i'll read that now
<james_w> checkrdepends knows about seeds doesn't it?
<james_w> is a "Suggests:" enough to stop something showing up on component-mismatches?
<rgreening> mpt, mvo: can we chat about software-store and kde frontend? evand suggested I chat with one or both on this...
<mpt> rgreening, sure, though I don't know how much help I would be. I are just the designer.
<cjwatson> james_w: no
<hdon> ok, if my program only calls setlocale() with setlocale(LC_ALL, ""), then it appears i can control where libintl/glibc looks for translation files with the LANG environment variable. however, it still does not look in the path that i provide to bindtextdomain() :(
 * hdon sighs
<hdon> thanks for the help btw. i realize this is probably not really a developer support channel
<cjwatson> hdon: it worked for me as long as I actually had a valid LANG
<rgreening> mpt: well, I am interested in eith developing the KDE front-end or assisting in developing it.
<hdon> cjwatson: where did you get your translation file?
<hdon> cjwatson: i would like to try to duplicate your success
<cjwatson> who cares, it was looking in the right places as seen by strace
<rgreening> mpt: I recently developed the kde front-end to usb-creator, so I figured I could help with the new software-store.
<hdon> cjwatson: oh, ok, fair enough
<cjwatson> try it with LC_ALL=en_US.UTF-8 or something like that that's guaranteed to exist
<ttx> james_w: no, no reason.
<cjwatson> open("/usr/share/python-support/python-django/django/conf/locale/en_GB.UTF-8/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
<james_w> ttx: do you know what is keeping it in?
<cjwatson> ...
<cjwatson> open("/usr/share/python-support/python-django/django/conf/locale/en/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
<ttx> james_w: no, I'm going to have a look.
<rgreening> mpt: basically, if we develop it correctly, it should be a backend with one or more frontends. Untying GTK from the backend so any interface could be written on top of it.
<james_w> ttx: the only rdepend I can find is libgnumail-java suggesting it
<cjwatson> actually, I stand corrected, mattn did have a point - the locale does actually need to be installed, but if you installed language-pack-fr already then LC_ALL=fr_FR.UTF-8 should make it work
<mpt> rgreening, there already is a back end, it's called Aptdaemon. <http://launchpad.net/aptdaemon>
<rgreening> mpt: there was a packagekit spec I helped write to cover some of what would need to be done with packagekit for a backend
<rgreening> cool
<mattn> why is libg3d in ubuntu repos but not g3dviewer and the thumbnailer? are there even any other applications that are using libg3d?
<mattn> strange
<rgreening> mpt: awesome, then presumably, writing a frontend should be trivial...
<rgreening> mpt: is there a spec for UDS-L for this? If so, I'll write a KDE frontend spec and link to the other...
<ttx> james_w: same here
<james_w> ttx: ok, I'll demote it as we probably don't want it, and we can see if anything complains?
<ttx> james_w: nothing should :)
<mpt> rgreening, writing a good front end is always the hard part.
<mpt> rgreening, I'm not aware of a spec for it. This is the first time I've heard of the possibility of a Kubuntu equivalent.
<rgreening> mpt: I'm the kubuntu ninja concerned with making the Ubuntu-->Kubuntu transistions when everyone else has forgotten ;) haha
<mpt> rgreening, good for you. What do Kubuntu users think of KPackageKit, do you know?
<rgreening> kpackagekit is good and bad... some missing bits and not having an Applications VIew is bad (IMO), as packagekit shows all packages/debs and cannot filter to show just applications like from within app-install-data. Though I helped write the spec to make that work in packagekit.. we can probably work on the spec and implementing it...
<nh2> mpt: hi, tseliot told me I could ask you to take a short look at https://bugs.launchpad.net/hundredpapercuts/+bug/386017 - I created two checkboxes for enabling/disabling corner tapping
<ubottu> Launchpad bug 386017 in hundredpapercuts "Brushing right-edge of trackpad causes clipboard to paste text" [Undecided,Confirmed]
<pitti> jdstrand: good morning! do I need to do anything further on bug 430544?
<ubottu> Launchpad bug 430544 in postgresql-8.3 "New security/bug fix microreleases: 8.1.18, 8.3.8" [High,Fix committed] https://launchpad.net/bugs/430544
<rgreening> mpt: http://cgit.freedesktop.org/packagekit/plain/docs/app-install-v1.draft
<jdstrand> pitti: hi! (reading)
<maxb> Where was the LL codename announcement? I can't find it in ubuntu-devel-announce archives.
<jdstrand> pitti: nothing further required, I'll publish this. thanks for your work on it!
<soren> maxb: Yeah, that's the thing... The announcement e-mail hasn't gone out yet. Mark revealed it at Atlanta Linux Fest.
<maxb> ohhhh right
<maxb> Good old verbal communication :-)
<mpt> nh2, hi
<mpt> nh2, the first thing to learn is that any checkbox label that starts with "Enable" probably isn't direct enough.
<pitti> jdstrand: thanks
<mpt> nh2, for example, "Enable right clicks with the bottom right corner of the touchpad" could be shortened to "Rght-click by tapping the bottom right corner of the touchpad"
<mpt> nh2, and similar for the other new checkbox.
<mpt> nh2, another thing to consider is that if someone sets up all the mice they ever use with left-handed orientation, secondary click is left click, not "right-click". So you may be better referring to "secondary click" rather than "right click".
<nh2> mpt: ah ok, I just saw "Enable mouse clicks with touchpad" and so also used "enable"
<mpt> nh2, yes, that will be fixed in my large-scale redesign of the touchpad settings :-)
<cjwatson> will people understand secondary click?
<nh2> mpt, cjwatson: I'm not sure a regular user can imagine that
<davmor2> mdz: did the additions I put into bug 43706 cover what you needed?
<nh2> s/imagine/understand
<ubottu> Launchpad bug 43706 in casper "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706
<nh2> mpt, cjwatson: perhaps "clicks" and "context menu clicks" as the secondary click is often a context menu click?
<glatzor> mpt, rgreening: richard is no longer working on app-install
<glatzor> the infrastructure changes have not been accepted by Fedora
<glatzor> but see you
<mpt> cjwatson, I haven't been able to find a screenshot of what Windows calls it -- the interface seems to be up to the device <http://farm4.static.flickr.com/3154/2879987137_4ca67c9133_o.jpg>. Mac OS X calls it secondary click, though. <http://www.winandmac.com/wp-content/uploads/2009/08/snowleopard-final08.png>
<mpt> (up to the device vendor, I mean)
<mpt> Though that might just be because Mac mice don't often have buttons with visible sides
<cjwatson> I was just about to say
<cjwatson> Mac hardware users seem less likely to talk casually about left/right clicks
<cjwatson> another option would be to have the dialog text conditional on which way round the mouse buttons are configured, though I'm not sure how confusing that would be
<mpt> That Windows screenshot does specifically mention "Left Button Action" and "Right Button Action", but I suspect that's referring to the actual hardware orientation rather than colloquial use.
<mpt> glatzor, sorry, what infrastructure changes?
<soren> Now that lucid has been announced, is there any reason to not update vim, devscripts, and lintian to recognise it?
<soren> And is there anything else that needs updating? I had a list at some point, but I think it's on another laptop.
<ogra> soren, do you read -changes?
<soren> ogra: I don't, but I'm guessing that I should?
<ogra> soren, lool uploaded vim hours ago ;)
<soren> ogra: Ah. devscripts and lintian as well?
<ogra> i think only vim syntax scripts
<jono> seb128, btw, the gnome panels and compiz bugs have gone away in my recent dist-upgrade - thanks!
<seb128> jono, oh, good to know, not sure it's due to me but you're welcome ;-)
<lool> there's devscripts and pbuilder too
<lool> I'm working on both to have them use `lsb_release -cs`
<jono> seb128, you deserve more thanks anyway for your Ubuntu work, so it seems fitting :)
<lool> soren: Ah lintian is a good one too
<seb128> jon;-)
<seb128> jono, ;-)
<soren> lool: right, pbuilder is the one I always forget :)
<soren> lool: vim, devscripts, lintian, and pbuilder.
<soren> That's my list. :)
<mpt> nh2, <https://wiki.ubuntu.com/TouchpadSettings> is my work-in-progress for the big redesign, if you're interested.
<mpt> nh2, though at the moment I don't have anything for simulating middle-click.
<nh2> mpt: yes, tseliot told me there was work in progress
<nh2> mpt: my suggestion was, just in case the redesign is not going into karmic, we could add those checkboxes so the user has an option to at least turn tapping on/off it it annoys him in karmic (I'm very open for any labelling suggestions ;-) )
<mpt> nh2, that's fine, I've put suggested labelling into the bug report.
<tseliot> superm1: is changelog.in meant to be used in fglrx-install or can I just modify the changelog?
<tseliot> fglrx-installer
<superm1> tseliot, you can just modify changelog.  changelog.in is intended to be modified if you are committing to the git tree
<superm1> it's used when building debs or dsc's directly from the .run file
<tseliot> superm1: ah, ok, thanks. I only need to make a trivial change to fix bug #429153
<ubottu> Launchpad bug 429153 in nvidia-graphics-drivers-96 "modaliases package is free/trivial, but shipped in restricted" [Low,Triaged] https://launchpad.net/bugs/429153
<superm1> isn't that an archive administration problem?
<tseliot> which affects fglrx-installer too
<hdon> cjwatson: thanks for your help earlier, i think i have everything i need now. do you think libintl's behavior of bailing out if it decides the requested locale is not provided by the system is the appropriate behavior? do you think there's any chance to persuade GNU that gettext should trust that an application knows what translations it provides and not assume it can't translate what the application asks just because the system ma
<hdon> intainer hasn't made a locale available for the entire system?
<tseliot> superm1: no, just a matter of specifying the section for the modalias package
<tseliot> superm1: in debian/control
<superm1> tseliot, I thought that stuff gets overridden by soyuz though anyway?
<tseliot> pitti ^^
<cjwatson> hdon: I think the current behaviour is appropriate
<pitti> superm1: yes, the overrides and components in soyuz are correct
<pitti> superm1: but mdz pointed out that some other packages doesn't check the actual values in apt, but the values in debian/control
<cjwatson> hdon: the system is responsible for defining the meaning of locales; there are lots of things relevant there besides translations
<pitti> superm1: and thus it would be nice to change debian/control to reflect actual reality
<superm1> pitti, ah i see
<cjwatson> hdon: for example, unless the system has defined what the locale means, you cannot know the appropriate character encoding for printed messages
<cjwatson> hdon: and again, this is not a matter of libc lagging behind somehow, this is just a matter of using a mistaken locale name, easily corrected by using the correct one instead
<hdon> cjwatson: hmm, i think i can see what you mean. my perspective on it is a little different because i'm working with web-based systems, so whereas most programs want their messages displayed by the system on which they run, we display our messages on a remote piece of software (web browser)
<cjwatson> then I think it's reasonable to ask that your application does a little bit more work to find the right locale name, to be honest
<cjwatson> or else that your application uses localedef to define its own locales (I wouldn't recommend that, but it's possible)
<cjwatson> the gettext library function does need to know the encoding somehow, though
<hdon> cjwatson: yeah, it's silly of me to assume that my application will need a locale that hasn't already been defined for us
<cjwatson> I don't know that I said it was silly
<cjwatson> but I do think you can declare it to be the system's problem
<lool> soren: there's debootstrap too of course
<cjwatson> and if that's really unacceptable, localedef is avaialble
<cjwatson> available
<hdon> cjwatson: ok, thanks. i'll evaluate localedef if we need to support any locales that won't or can't be installed on our target systems.
<lool> cjwatson: BTW I think we had a chat about preparing for karmic+1 in karmic a while ago and ISTR you indicated there was no particular issue in doing that, just that we didn't think of doing that before release; do you think you'd have time to prepare a debian upload of debootstrap with a new symlink for lucid?
<lool> We often tell people to install the debootstrap from the devel release; that's probably more solid and it's usually easy to do but perhaps we can avoid that most of the time
<cjwatson> lool: sure
<lool> cjwatson: thanks
<ogra> urgh
<ogra> the new xsplash graphics look horrid on 16bpp displays
<ogra> way worse than the former
<ebroder> Has anybody seen a segfault like this before: http://paste.ubuntu.com/275342/ ?
<lool> james_w, slangasek: Would be cool to get linux-mvl-dove binaries NEWed if you have some time (mostly adds udebs)
<slangasek> lool: yep, will be working through NEW this morning
<lool> slangasek: Cool thanks
<lool> slangasek: Did you have any concern on the UNR seed changes?  (apart of us being oversize again)
<slangasek> lool: no, being oversized was my main concern :)
<lool> Eh ok  :-)
<pitti> they looked fine to me
<lool> I just seeded usb-creator at the req of the dux team too
<lool> pitti: thanks
<hdon> hi all. what package contains the debugging symbols needed to peek at the arguments given to glibc functions using gdb?
<hdon> ah, lib6-dbg i guess
<smoser> slangasek, did you do an MIR for libc6-xen ?
<cjwatson> smoser: MIRs are needed when moving source packages to main, not when moving binary packages generated by source packages that are already in main
<smoser> ah. ok. so what needs to be done for that? anything ?
<cjwatson> smoser: no paperwork is needed. I've promoted it - it'll be visible in main in an hour or two
<smoser> thank you.
<slangasek> smoser: right, what cjwatson said :)
<jdstrand> jpds: When I click the link to the PDF you provided in your description with firefox, evince opens in its own window and does not seem to load from cache. Are there other steps I should take to reproduce the bug?
<jdstrand> jpds: bug #433316
<ubottu> Launchpad bug 433316 in evince "Apparmor profile denies PDFs opened through Firefox" [Medium,Incomplete] https://launchpad.net/bugs/433316
<jpds> jdstrand: No... that's the problem, PDFs just don't load.
<jdstrand> jpds: what I'm saying is they *do* load fine here. I'd like to know what I need to do differently to reproduce the bug
<jpds> Hmm, not sure what I could of done to change the apparmor profiles, I reinstalled Karmic last week.
<jdstrand> ps auxww|grep evince
<jdstrand> jamie    27573 14.0  0.6 385680 26180 ?        Sl   12:14   0:03 evince file:///tmp/eu_map-3.pdf
<jdstrand> jpds: ie, it isn't loading from cache
<jdstrand> jpds: let me rephrase
<jpds> jdstrand: I see.
<jpds> jdstrand: I'll go and check what's wrong with my config.
<jdstrand> jpds: the file seems to be copied from cache, into /tmp, and then loaded
<jdstrand> jpds: yeah, I just removed all the pdfs in /tmp, then clicked on the link, it opened instantly (ie, I didn't have to redownload it) and it worked fine
<slangasek> kenvandine: why does xsplash need > 500k of images?  shouldn't xsplash be able to scale these backgrounds at runtime, particularly given that the 3 largest all have the same aspect ratio?
<kenvandine> slangasek, i would think so
<kenvandine> slangasek, i will talk to cody about that
<slangasek> kenvandine: ok, thanks
<superm1> kenvandine, if you do make such a change can you try to remember to file a bug against mythbuntu-gdm-theme so that we can make adjustments relative to that?
<kenvandine> superm1, sure
<superm1> thanks
<kenvandine> np
 * kenvandine makes a tomboy note
<kenvandine> :)
<kenvandine> slangasek, the DX guys say it would look bad... or at least not as good as our requirements
<slangasek> kenvandine: er, what's wrong with xsplash's scaling support then? :P
<kenvandine> hehe...
<slangasek> same aspect ratio + downscaling shouldn't give any noticeable degradation in the appearance
<slangasek> and we don't *have* 500K+ to spare on the CDs
<slangasek> (i.e., this change has pushed amd64 alternate oversized in the dailies)
<smoser> how can I get list build dependencies for a package ?
<smoser> i can *get* them with apt-get build-dep, but how can i list ?
<slangasek> smoser: 'apt-cache showsrc <package>' | grep Build-Depends
<smoser> thanks
<ltrager> I would like to create an init script which will be interactive. I'm using the read command but its not working, how can I get this to work?
<slangasek> ltrager: "don't"
<slangasek> ltrager: init scripts *must* run noninteractively at boot
<ltrager> slacker_nl: then how would you suggest to run a script at boot-up?
<ltrager> in my case it asks the user if they would like to image a machine
<ltrager> and which image to use
<slangasek> you cannot assume that the user is anywhere near the console at a reboot, and you shouldn't block the booting waiting for your answer
<ltrager> slacker_nl: I can this is for a custom usb key that I'm giving out to people that I know will have a console
<dashua> Amaranth, http://www.ubuntu-pics.de/bild/25364/screenshot_001_59EQJ2.png
<ltrager> slacker_nl: so I guess I should just tell getty to auto login and for roots .bash file set to run a script?
<dashua> Is this a known bug when closing clock?
<Amaranth> dashua: Known, pretty sure my patch to change dock shadows caused it
<Amaranth> since that is technically a dock shadow
<dashua> Amaranth, Ok cool.
<Amaranth> dashua: please tell me you're seeing bug 430981 too :)
<ubottu> Launchpad bug 430981 in compiz "keybindings not remembered on reboot" [High,Confirmed] https://launchpad.net/bugs/430981
<slangasek> ltrager: oh; then your question is off-topic here, since it's not about Ubuntu development. :)  Anyway, you would probably have to manually attach to the tty to be able to prompt the user.
<Rasteiro> can anybody help me with partner program??
<Rasteiro> sds...
<slangasek> ltrager: an autologin would be another option, yes
<dashua> Amaranth, All of my keyboard short cuts seem to work.
<Amaranth> dang
<Amaranth> everyone who has the bug is doing the workaround
<dashua> I just did a clean install yesterday, but did not notice it prior.
<kees> zul: erlang is in main, so does the MIR wiki need to be updated?  I think all the deps are in main now?
<zul> kees: it wasnt when I did the MIR do you want me to update the MIR now?
<kees> zul: nah, just wanted to check
<zul> k
<mangr3n> Anyone know where I can find a discussion of groups/users/permissions for the Jaunty standard install?
<mangr3n> trying to find the groups needed to run the update manager, seems like the admin and root groups aren't all that's necessary
<davmor2> mangr3n: check they user is a member of sudoers
<mangr3n> I did that already, that was the first problem
<mangr3n> Is apt-get upgrade the same as the update install?
<mangr3n> sudoers points at root
<nh2> mpt: great. Should I create a new patch or will the one who patches the package just change those strings?
<mangr3n> and %admin, which my user is a member of
<mangr3n> I'll do this in the #ubuntu room, I was just wondering if there was documentation on the default/standard groups that were added to ubuntu and what they were associated with, I'm missing some groups, and I don't know what they were
<mangr3n> found it missing group mlocate...
<mpt> nh2, I don't know, sorry.
<nh2> mpt: ok
<kees> zul: what would it take to enable to testsuite in rabbitmq?
<kees> there is a "run-tests" makefile target
<zul> kees: i would have to see
<jcastro> are the moblin images on cdimage supposed to work?
<Martyn> Alpha-6 using grub2 still total fail on the Precision T7400/T7500 series from dell
<Martyn> no boot .. had to install then upgrade
<Martyn> Is there a gcc 3.6 toolchain available for karmic koala somewhere?  I have a lot of software that has it as a build dependency.
<Martyn> I noticed all the gcc-3.6 packages were dropped from being built, and there's no mention on launchpad as to why
<danage> kirkland: sorry for bugging you, but i have a very bad and i think thus very serious bug to report. i'm not sure what package to attach it to. it has to do with home folder encryption, you seem to be part in the project (i saw your blog post)?
<soren> I know that for udev, it's rather well documented what sort of things you can expect to have available in rules files numbered in the 20's, the 30's, etc.. Do we have something similar for rc2.d/S?? scripts (other than looking at the directory on a reasonably rich system)?
<ScottK> Martyn: gcc3.6 is pretty ancient.  We try to get rid of old gcc versions when nothing in the archive requires them.
<Martyn> ScootK : That's the funny thing .. there is a LOT of g++ software in the archive that just won't compile under 4.4
<Martyn> (or 4.3)
<Martyn> because of the new template library enforcement of something that USED to be a warning, is now an error
<Martyn> and not all the libraries are editable.  It's a quandry
<Martyn> ScottK : What is the probability I can convince someone to bring the 3.6 package over from Jaunty to Karmic?
<Martyn> and at least keep one creaky compiler running?
<ScottK> Martyn: Probably close to zero.  You'd need to make a really good case why it's essential.
<ScottK> I don't think "My non-free software that I can't modify won't work with a newer gcc" will work.
<Martyn> ScottK : That becomes a philosophy problem then .. the main packages that I need it for, in any case, are ThirdParty commercial software (nonfree) that use gcc 3.6 as the compiler for the environments
<Martyn> yes, but ubuntu != debian in the server market
<Martyn> and I hate to get stuck with Redhat's pile of fail
<Martyn> because they are one of the only linux companies that at least acknowledge that commercial software exists and is useful to the business sector using linux for development
<Martyn> but centOS and RedHat are so hopelessly mired right now.  What a mess.
<ScottK> Martyn: I understand the problem, but there's really no will for community support of such old things.
<ScottK> If there were an active Ubuntu developer that were interested to support it, it might be different.
<NCommander> Martyn, GCC 3.6?!
<Martyn> NCommander: Yep
<Martyn> NCommander: I hate to say it, but ARM's FastModel tools, and RealView -depend- on fucking gcc-3.6
<NCommander> Martyn, I didn't even realize GCC 3 went that long
<NCommander> *twiches*
<Martyn> it's hitting the wall for development on ARM dude.
<Martyn> that's why I need it.
<Martyn> What can you do, when the MANUFACTURER of the architecture we're trying to port to .. has tools that depend on old buildchains?
<Martyn> Arm RealView 5.0 / FastModel 5.0 both depend on 3.6, and 32 bit at that
<NCommander> Martyn, well, you can get 32-bit compat easily enough
<NCommander> Martyn, but I don't remember ever seeing GCC 3.6 in the archive
<Martyn> so if you do development on a 64 bit platform (which of course I am using) .. I need to use the 32bit compiler or multilib
<Martyn> NCommander: jaunty
<Martyn> Sorry .. gcc 3.4.6
<NCommander> Martyn, packages.u.c doesn't turn it up
<NCommander> Martyn, oh, 3.4.6!
<NCommander> :-P
<Martyn> I transposed the numbers
<Martyn> Good call on the version number
<Martyn> but yeah, I need 3.4.6 in order to use those tools .. and it gets WORSE with the RTL validation tools
<Martyn> some of those need older binutils
<NCommander> Martyn, hrm, i didn't realize we dropped it completely
<ScottK> Martyn: Run in it a chroot of an older release that has it is my advice.
<NCommander> Martyn, talk to doko, he's the one who would know the most on this situation.
<NCommander> Martyn, otherwise, what ScottK said :-)
<Martyn> yeah *grump*
<Martyn> I really don't want to try running in a mixed condition
<NCommander> Martyn, the other choice is grab the old source packages, and try building GCC 3.4 under karmic
<ScottK> Convince Canonical they want it in the partner repo might be another option.  It wouldn't be the first time they'd put obsolete stuff back in there.
<LIB53> alpha 6 is supposed to have a brownish xsplash right?
<LIB53> i was just asking because i don't get that xsplash, but i can't stick around forever for a reply so nvm
<ion> Wow, almost five minutes of patience.
<Madkiss>  miaow
#ubuntu-devel 2009-09-22
<Darxus> Is this an appropriate place to ask for help on azureus from karmic giving me an error on "debuild -S" of: "You must specify a valid JAVA_HOME or JAVACMD!"?  Google hasn't helped.
<tormod> Darxus, try #ubuntu-motu (did you install all build-deps?)
<Darxus> I tried #ubuntu-motu first.  They took 7 minutes to respond.  And it looks like the answer here was better.
<cjwatson> seven minutes is a quick answer on IRC
<Darxus> Wow, you typed out "seven".  And didn't capitalize it.  Weird.
<slangasek> yes, that also happens on IRC
<Darxus> Heh.
<james_w> read(2) states that EAGAIN means that a non-blocking descriptor doesn't have any data for reading right now
<slangasek> james_w: ?
<james_w> damn, you noticed!
<james_w> I was going to slink away quietly as I realised the stupidity of my question
<slangasek> oh :)
<james_w> it was how that could happen after poll said the fd was ready
<james_w> I forgot about the successful read() in the middle
<jono> just tried running
<jono> ubuntu-bug  xsplash
<jono> but I get:
<jono> (gnome-open:5110): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
<jono> Error showing url: Failed to execute child process "https://bugs.launchpad.net/ubuntu/+source/xsplash/+filebug/mqbjc344L61q7b3EzVB5nHO0IIs?" (No such file or directory)
<jono> does that mean xsplash is not set up to work with ubuntu-bug?
<seb128> jono, does it work on other sources?
<jono> trying seb128 nope
<jono> just tried with empathy
<seb128> ok, what it looked like from the error
<jono> jono@forge:~$ ubuntu-bug empathy
<jono> (gnome-open:5225): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
<jono> Error showing url: Failed to execute child process "https://bugs.launchpad.net/ubuntu/+source/empathy/+filebug/lBjafLHE35UK0YZyKBUrzd8xqDj?" (No such file or directory)
<james_w> jono: System->Preferences->Preferred Applications
<seb128> do you have a prefer browser configured and set to working binary?
<james_w> what do you have as web-browser there?
<jono> interesting
<jono> it was custom
<jono> let me try with firefox
<jono> jono@forge:~$
<jono> Gdk-ERROR **: The program 'firefox' received an X Window System error.
<jono> This probably reflects a bug in the program.
<jono> The error was 'BadWindow (invalid Window parameter)'.
<jono>   (Details: serial 680 error_code 3 request_code 20 minor_code 0)
<jono>   (Note to programmers: normally, X errors are reported asynchronously;
<jono>    that is, you will receive the error a while after causing it.
<jono>    To debug your program, run it with the --sync command line
<jono>    option to change this behavior. You can then get a meaningful
<seb128> that's a known firefox bug
<jono>    backtrace from your debugger if you break on the gdk_x_error() function.)
<jono> aborting...
<jono> intereting
<jono> interesting
<seb128> try again ;-)
<jono> ok will try chromium
<maco> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at  http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<seb128> well it doesn't do it every time
<seb128> jono, when they say that filing bugs will be harder they mean it ;-)
<jono> maco, I know, it was short enough of a paste
<jono> seb128, lol
<jono> ok works in chromium :)
<Darxus> The build-deps fixed my problem.
<Darxus> Uploaded my first debdiff and subscribed ubuntu-universe-sponsors!
<bluefoxicy> ã
<bluefoxicy> this glyph... the curve at the bottom should not connect with the leftward serif off the top segment
<bluefoxicy> http://dic.academic.ru/pictures/enwiki/74/Japanese_Hiragana_kyokashotai_KI.png
<Darxus> bluefoxicy: Submit a bug at https://bugs.launchpad.net/ubuntu/
<TheMuso> cd
<TheMuso> woops wrong tab
<poningru> heh
<glick> has anyone here heard/use MPC to build software?
<dholbach> good morning
<nixternal> good morning to you dholbach
<nixternal> you've got mail btw
<nixternal> I left MOTU :/
<dholbach> hiya nixternal
<dholbach> err
<nixternal> it wasn't my fault though, GMail ate up the email about me expiring :)
<dholbach> bah
<nixternal> haha
 * dholbach slaps nixternal around with a BIG trout
<dholbach> man
<dholbach> !
<dholbach> not so early in the morning
<nixternal> gotcha!
<highvoltage> heh
<nixternal> big trout? that is some mIRC there man
<dholbach> you know what...
<dholbach> find somebody else to re-add you to the team
<nixternal> I can't unexpire myself
<nixternal> I already asked the others :)
<TheMuso> hehehehe
<nixternal> I can't add myself, but I can remove you ;p
<nixternal> so you will be in this same boat as well :)
<nixternal> I expired in June too, just found out about it :)
<nixternal> gotta keep an eye on it, cuz my ubuntu membership expired last month and ate up a weeks worth of email before I figured out what was wrong
<dholbach> :)
<nixternal> it was cool, because instead of 1,000 emails a day, I was getting about 5 a week :)
<glick> hey does anyone here use SCONS or MPC as a build system?
<glick> and which one is better/easier
<dholbach> robert_ancell: could you hop into #ubuntu-reviews ?
<TheMuso> glick: Never used mpc, but I've had to deal with projects usinc scons, and I would personally stay away from scons at all costs.
<pitti> Good morning
<glick> why TheMuso it looks pretty decent from reading about it on the website
<glick> whats so horrible about it
<TheMuso> glick: For one, scons has caused issues when package have been building on the Ubuntu  ubild servers for Ubuntu. Then there is the difficulty in passing CFLAGS etc to a project when the SConstruct files haven't been written properly.
<TheMuso> glick: Granted autoconf is the same, but I have had too many bad experiences to recommend it to anyone. I also know that other devs around here stear well clear of it.
<glick> can you recommend anything else? i have a project that needs to compile on windows, linux/unix, and vxworks, and integrity
<glick> maintaining 5 build files is a nightmare, and MPC the current system is a pain
<TheMuso> glick: I know that people manage to use autoconf/automake on windows using cygwin/mingw, but I am not sure how much more work that is. Since I have no experience with realy cross platform projects like that, I can't really suggest anything. My personal choice for a linux project is autoconf/automake.
<wrapster> apt-sastisfydepends --> command not found
<wrapster> devscripts have been installed
<wrapster> can anyone help me?
<wrapster> Im a newbie to packaging
<pitti> wrapster: command-not-found doesn't know it either; what do you want to do?
<pitti> wrapster: perhaps sudo apt-get build-dep <srcpackage> ?
<wrapster> pitti: ive described everything here http://pastie.org/625614
<dholbach> sudo apt-get build-dep gcc-4.4 (or gcc-4.3 if you want to modify that one) will be a good start
<dholbach> you need gcc to compile gcc, there's no way around that
<wrapster> dholbach: but wont it generate errors complaining that its already installed?
<dholbach> no, because if you build the package using debuild or dpkg-buildpackage, it uses fakeroot(1)
<ogra> pitti, bug 434210 ... you might want to close it if you feel like
<ubottu> Launchpad bug 434210 in gdm "'text' mode boots into X" [Undecided,Fix committed] https://launchpad.net/bugs/434210
<pitti> ogra: oh, indeed; thanks
<wrapster> dholbach: ok thanks will do it and see
<dholbach> rock on!
<wrapster> dholbach: cooool built it.. But i have an issue here.. i had already downloaded the gcc source so I used it as well.. But there are other pkgs (like gcc-4.3, gcc-4.3-dev and so on) how do i know in which pkg i should modify the rules file
<dholbach> gcc (from gcc-defaults source package) is just a meta-package
<dholbach> the actual gcc, comes from gcc-4.3 and gcc-4.4
<dholbach> I don't know what you want to change, so I can't tell you which source package you should be modifying :)
<dholbach> and for gcc, I'm really not the best person to talk to :)
<wrapster> dholbach: i want to add a few symlinks to /usr/bin/gcc pointing to /usr/sfw/bin/gcc
<Appiah> http://packages.ubuntu.com/ <- anyone else having problems reaching this page atm?
<wrapster> i added that in the source of gcc. and it worked..
<wrapster> i now have a symlink but not very sure if i am adderssing the right pkg
<dholbach> wrapster: I'm not sure that's a good fix, but unfortunately I can't help you there
<nubae|work> hi there... I work for Guadalinex-edu, and we are looking for a way to add the exit (logout options) button to the top panel via gconf... but cannot seem to find that option anywhere... can someone guide me as to where/how to do that (has to be done on a large scale, so can't do it via right click, etc)?
<lool> pitti: Around?
<lool> pitti: I'd like to discuss apport's hookutils with you
<lool> pitti: I'd like to use the attach_gconf() utility for various packages but the settings are overwritten by each run since the section has a static name
<lool> pitti: Would it be possible to use a dict in report['GConfNonDefault'] instead of a string?
<lool> Otherwise I'm thinking of passing the section name as argument (name = 'GConfNonDefault') by default but can be overriden, or of moving the section around in the caller
<pitti> hi
<pitti> lool: the latter will work
<pitti> lool: dictionaries as values aren't supported right now
<lool> pitti: What about passing the name of the section as argument?
<pitti> that would require writing marshalling and unmarshalling for the various file formats (RFC822, multipart-mime)
<pitti> lool: right, that would be fine
<lool> (Ok wasn't sure which "latter" you meant)
<lool> pitti: Ok; another option is to always append to report['GConfNonDefault'] if it exists
<lool> pitti: I can do any of these two (variable section or always appending)
<pitti> lool: that sounds fine as well
<lool> pitti: Ok I have a preference for always appending because in desktop-switcher I'd like to call other packages' hooks
<pitti> seb128: ^ what would you prefer in bug reports?
<lool> And I dont want to rename GConfNonDefault in each package
 * ccheney can't sleep :-\
<pitti> seb128: GconfNonDefaults having all changed settings from all packages in one field?
 * ccheney so he is working instead, heh
 * pitti counts sheep for ccheney
<pitti> seb128: or separate fields per package?
<seb128> pitti, I think I missed part of the discussion to understand the question
<lool> pitti: I dont think it touches any package right now though
<seb128> oh, apport
<seb128> I was thinking gconf schemas
<lool> seb128: So if apports utility to collect gconf non-default settings is called on two different packages, the last one wins; the question is whether you'd like the various settings to go in different sections or can they be aggregated in the same setting
<seb128> I've no strong opinion either way, whatever is the easiest
<seb128> as far as the datas are there
<seb128> as long as
<seb128> brb another quick session restart
<lool> sebner: Ok thanks
<lool> err sorry sebner
<seb128> re
<seb128> pitti, yeah, so no strong opinion there for the gconf dump as long as we have the datas
<seb128> I think it's a corner case anyway
<pitti> seb128: *nod*
<lool> ok thanks
<pitti> lool: so, same field and append seems most robust to me
<pitti> then hooks don't need to care
<lool> pitti: Yes exactly
<seb128> +1
<lool> that's what I was implementing
<sladen> what's the deal with this ~60 seconds of ultimate pure blackness on boot now, with not even the black light turned on?
<pitti> sladen: bug 431812
<ubottu> Launchpad bug 431812 in sysvinit "fbcon loading a mystery (screen powers off)" [High,Confirmed] https://launchpad.net/bugs/431812
<sladen> pitti: wondering whether to bump it to critical, it kills (recovery mode)
<pitti> done
<geser> pitti: Hi, I've looked at the cause of http://launchpadlibrarian.net/31948454/buildlog_ubuntu-karmic-i386.kde-l10n-sr_4%3A4.3.0-0ubuntu1_FAILEDTOBUILD.txt.gz (from the rebuild test) and it failed because both the sed expression in pkgstriptranslations and the locale name use an @:
<geser> sed -i 's@^[[:alnum:]]\+  usr/share/locale/sr@latin/entry.desktop$@c7ff2ad283d1914db2c7797ce8789719  usr/share/locale/sr@latin/entry.desktop@' DEBIAN/md5sums
<geser> I've replaced the @ in the sed expression with an # but wonder if there is a better delimiter
<dholbach> ttx is doing patch/package reviews in #ubuntu-reviews
<pitti> geser: hi
<pitti> geser: oh, good catch; # should be fine, it's not a valid part of a locale
<ogra> hrm, no Keybuk ...
<pitti> ogra: he's on a conference
<ogra> does anyone know how i'm supposed to start services if i boot with init=/bin/bash
<ogra> now that we dont have any initscripts anymore
<geser> have you tried: service - run a System V init script
<ogra> it needs upstart :)
<ogra> afaik
<ogra> i'll try it
<directhex> okay, mono 2.4.2.3+dfsg-2 has definitely evaporated. i know it was "fix released"ed
<directhex> Bug 426759, synced by seb128 weeks ago
<ubottu> Launchpad bug 426759 in mono "Sync mono 2.4.2.3+dfsg-2 (main) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/426759
<seb128> directhex, you might have opened the sync request when the new revision was not on mirrors yet
<geser> pitti: bug 434544 when you have some time for review and sponsoring
<ubottu> Launchpad bug 434544 in pkgbinarymangler "pkgstripstranslations fails if the locale contains an @" [Undecided,New] https://launchpad.net/bugs/434544
<seb128> directhex, and I've overlooked the revision in the title
<directhex>  - <mono_2.4.2.3+dfsg-2.dsc: downloading from http://ftp.debian.org/debian/>
<sebner> directhex: pitti acked my sync request. seb128 mind syncing again?
<sebner> seb128: bug #433070
<ubottu> Launchpad bug 433070 in mono "Sync mono 2.4.2.3+dfsg-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/433070
<pitti> geser: thanks! I'm currently doing sponsoring anyway, will grab this
<seb128> directhex, dunno what happened
<directhex> sebner, i wish i knew what had happened to it. eaten by gremlins!
<sebner> directhex: lost in the nirvana :\
<directhex> seb128, uploaded to debian 2 days before you ran the sync, so it can't be a timing issue :/
<directhex> seb128, launchpad be eatin' packages!
<seb128> I might have forgotten to flush and somebody cleaned the cache dir
<seb128> doing that now
<cjwatson> maybe we should invent an upstart mode that starts upstart but then just drops into a shell task and blocks everything else until you explicitly ask for them
<cjwatson> like init=/bin/bash except you get to use initctl
<ogra> yeah
<ogra> well, that doesnt help me either though ...
<bdrung> do i need a ffe for bug 430658?
<ubottu> Launchpad bug 430658 in lintian "Please merge lintian 2.2.16 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/430658
<ogra> in rootstock i use debootstrap first stage on an image, put a setup script in place (called /sbin/installer), then fire up a vm and call that with init=/sbin7installer
<directhex> cjwatson, was i imagining over the weekend that fsck happens after modesetting but before any splashing, so you just get a black screen for an unknown and scary length of time?
<cjwatson> directhex: there are known bugs getting fbcon up at the right time
<cjwatson> directhex: bug 431812
<ubottu> Launchpad bug 431812 in sysvinit "i915: black screen on boot---fbcon loading (screen powers off); breaks (recovery mode), fsck, usplash, crypt password" [Critical,Confirmed] https://launchpad.net/bugs/431812
<ogra>  /sbin/installer being a shellscript, upstart would have to act like an interpreter here
<directhex> just checking
<cjwatson> ogra: the kernel is perfectly good at spawning interpreters where necessary, even for init=
<cjwatson> or for anything started via execve in any way
<ogra> oh, wait, /sbin/installer could be an upstart job i assume :) ... a little more work for me but likely a lot more elegant
<ogra> and i wouldnt need init= at all
<seb128> pitti, any idea on bug #430494?
<ubottu> Launchpad bug 430494 in gdm "gdm upstart script fails to start gdm" [Medium,New] https://launchpad.net/bugs/430494
<seb128> I'm not sure how to debug upstart scripts
<cjwatson> ogra: that is certainly a better replacement
<ogra> cjwatson, yeah, i just fear the amount of changes i have to do that late in the cycle
<ogra> seems more risky than having something that already is proven to work fine since a while
<cjwatson> *shrug* goes for the whole boot sequence
<ogra> heh, yeah
<lool> pitti: Mind reviewing/merging lp:~lool/apport/gconf-non-defaults-append ?
<lool> Didn't send a merge request yet
<pitti> lool: sure
<lool> This worked in my trivial testing
<lool> With a nice split between the settings when reading the report
<ogra> hmm, no, that wouldnt work, in debootstrap's second stage upstart isnt available, is it ?
<pitti> lool: hm, why does your branch also contain kees' changes to parse_segv?
<lool> pitti: I branched lp:apport
<pitti> oops, forgot to pull first, my bad
<pitti> lool: but now you added attach_conffiles(), which doesn't belong into trunk
<pitti> lool: without that, it looks fine
<lool> pitti: Oh crap
 * pitti drops it and merges
<pitti> lool: don't worry
<lool> pitti: I'm stupid I started on the wrong branch and copied the file over instead of the diff
<pitti> lool: conffiles aren't an upstream concept, so I can't have that in trunk
<lool> pitti: So I didn't quite get how the stacks were layered; I saw the ubuntu branch but though that was packaging
<lool> but actually it's not
<pitti> done
<pitti> thanks!
<bdrung> pitti: do i need a ffe for bug 430658?
<ubottu> Launchpad bug 430658 in lintian "Please merge lintian 2.2.16 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/430658
<lool> pitti: So I just pull upstream into ubuntu branch?
<lool> pitti: I mean do you mind the changes going to the .diff?
<pitti> lool: I do that now; there's a fair share of trunk changes, I do a new upstream release and then upload
<lool> pitti: Thanks
<pitti> lool: I don't mind changes in the diff, but it's time for a new usptream relelase
<pitti> bah, my typing sucks today
<pitti> bdrung: I'll have a look, but lintian shouldn't cause problems
<bdrung> pitti: thanks
<bdrung> TheMuso: ping
<bdrung> pitti: can you add "discuss UnitsPolicy" to the TB agenda?
<pitti> bdrung: feel free to add it yourself; do you want to be present?
<bdrung> yes
<bdrung> pitti: according to the wiki: "in which case they will add it to this page. " so i thought i should ask
<pitti> bdrung: right, I'm fine with discussing it
<lool> pitti: Ah I might have found a bug in the gconf handling in apport with gnome-panel
<Appiah> is there no openvz kernel in karmic?
<lool> pitti: hook is http://paste.ubuntu.com/275760/
<lool> pitti: traceback http://paste.ubuntu.com/275761/
<soren> Appiah: Not since Intrepid.
<soren> Appiah: Last one to have it was hardy.
<pitti> lool: hm, I thought I fixed that a while ago
<pitti> lool: but it might have been a similar crash (also in the xml parser)
<lool> pitti: If you copy that hook in source_gnome-panel.py in /usr/share/apport/package-hooks and run ubuntu-bug gnome-panel, can you trigger it?
<pitti> lool: hm, no, I can't
<pitti> lool: ah, I fixed the crash for the "default" tag
<pitti> but not for <applyto>
<lool> pitti: I have the issue with /usr/share/gconf/schemas/panel-compatibility.schemas
<lool> Which has no applyto
<pitti> right, no applyto here
<lool> pitti: but I dont get why you dont reproduce
<pitti> lool: ah, I do actually; sorry, it scrolled off due to some firefox spewage
<pitti> hm, without an <applyto>, how does gconf behave?
<lool> I have no idea
<pitti> I think I just fall back to the <key> value
<pitti> it will have the /schemas/ prefix, but it should be clear enough
<lool> pitti: Hey did you consider creating a dh_apport?
<lool> I'm adding a debian/source_foo.py to a bunch of packages and realize it's not ideal
<pitti> I didn't so far
<pitti> I usually put them into debian/local and just add them to .install
<lool> pitti: I also wonder whether it wouldn't make sense to simply collect gconf settings systematically
<pitti> lool: I'm a bit hesitant of that
<pitti> lool: for example, ekiga stores passwords unencrypted in gconf
<lool> pitti: I add them to debian/ and add them to .install; it's trivial but it's also the perfect usage for dh_  :-)
<lool> pitti: Aha good point
<pitti> arguably that's an ekiga bug (it should use gnome-keyring)
<lool> It's probably a bug in ekiga but there might be a bunch
<pitti> but I don't know what other bits also store sensitive bits in gconf
<lool> Yeah we're n the same page
<pitti> heh
<lool> pitti: I've added the hook to gnome-panel now (in bzr only) and wont upload; I understand you'll likely fix this apport issue soon and upload, or should I explicitely disable the hook for now and wait for the actual apport upload?
<pitti> lool: http://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/revision/1605
<pitti> lool: please go ahead and upload; a crashing hook doesn't crash apport, it's just ignored
<pitti> lool: yes, I'll put that into the 1.9.1 release and upload
<lool> Cool thanks
<lool> pitti: Bah I dont want to cause people to be wondering about the ubuntu-bug stracktrace in terminal or reports to miss dependencies etc.
<lool> Or pedro is going to come and beat me
<pitti> lool: it's just for two hours or so :)
<lool> that's what I wanted to confirm; thanks
<doko> pitti: would you mind a python-tz sync from unstable?
<pitti> doko: 2009l-1 ?
<doko> pitti: yes
<pitti> doko: done
<dholbach> pitti, seb128: what do you think we should with bug 63412? it's been on the sponsoring list for a while and set upstream
<ubottu> Launchpad bug 63412 in tsclient "Few resolution options" [Wishlist,New] https://launchpad.net/bugs/63412
<dholbach> sent
<seb128> dholbach, +do?
<cjwatson> does it need to be uploaded, or should it just be taken off the sponsorship list since it's been upstreamed
<seb128> dholbach, I've been looking at it, the patch is some hundred lines and not trivial to review I don't want to upload it
<seb128> well let's say I didn't find the time to review it properly
<cjwatson> so shall we unsubscribe the sponsors team so we don't have to keep on looking at it, in that case?
<seb128> and I'm not wanting to spend half an hour on that, I've higher todo items on my list
<dholbach> it looks a bit like tsclient is dead upstream?`:)
<seb128> well, there is a patch so it would be nice to have somebody to review it
<pitti> hm, the patch hasn't even been sent to upstream
<seb128> it has if that's the bug I'm thinking about
<james_w> dholbach: 'tis not
<seb128> oh, there is 2 tsclient sponsoring requests
<seb128> right that's the other one who got sent upstream
<seb128> I think debian pkg-gnome guys were discussing replacing tsclient with something active upstream recently
<dholbach> http://sourceforge.net/tracker/index.php?func=detail&aid=1689142&group_id=192483&atid=941574 links to http://sourceforge.net/tracker/?func=detail&aid=2799711&group_id=192483&atid=941576
<seb128> and maybe vinagre will have the features next cycle
<dholbach> james_w, pitti: ^
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0xe789e0> bug 1689142 not found
<dholbach> sf's tracker is a pain in the arse
<seb128> meanwhile I'm not sure what to do with the "should be reviewed but everybody is too busy or doesn't care about the software" bugs
<pitti> seb128: there's an upstream bug with about zero details, and no patch attached
<seb128> they sit there for ages right now
<seb128> pitti, the patch is there IIRC they ui just sucks
<pitti> "No attachments", hm
<dholbach> aha: "Launchpad couldn't import bug #1689142 from SourceForge.net Tracker."
<ubottu> Error: Launchpad bug 1689142 could not be found
<pitti> ah, it has a link to the patch in a comment
<dholbach> pitti: try the second link I gave above
<dholbach> *nod*
<pitti> seb128: it's mainly "I don't want to take responsibility for the patch"
<pitti> it's a major patch, and I don't use tsclient, and it's not a major bug
<pitti> and there's no upstream feedback
<seb128> right, same here
<pitti> and I guess it's the same for everyone else
<seb128> that's why I've been ignoring it and waiting that somebody who cares to spend the efforts take it
<pitti> so, anyone objects if we are honest and I just unsub sponsors with a comment that it should go upstream first?
<seb128> it's upstream, they don't reply
<seb128> I can understand how it's frustrating for the user
<dholbach> pitti: no, I'll also ping Efrain to ping upstream again
<seb128> I don't have a good reply though
<pitti> done
 * pitti sees the bullets come
<mvo> davmor2: could you please file a bug about the missing entires in software-store on the live-cd?
<davmor2> mvo: will do I'm just double checking that it works as expected once the system is installed
<mvo> davmor2: cool, thanks
<cjwatson> ogra: bug 129769: the patch provided there is correct, but do you think xscreensaver (or xscreensaver-data?) should recommend screensaver-default-images as well?
<ubottu> Launchpad bug 129769 in xscreensaver "newly installed xscreensaver errors without /usr/share/backgrounds" [Low,Confirmed] https://launchpad.net/bugs/129769
<ogra> screensaver-default-images should simply go away imho
<cjwatson> maybe that would be over the top, I'm not sure
<cjwatson> oh
<cjwatson> huh, ok - in that case I'll just sponsor the patch provided to fix the error
<ogra> its marks personal image collection
<ogra> was supposed to be taken over by the art team with new and shiny images for each release
<cjwatson> right
<ogra> that never happened, so we could as well save the CD space
<seb128> cjwatson, developer-membership-board invitation to join ubuntu-desktop pending now
<seb128> cjwatson, ie somebody needs to accept it
<cjwatson> seb128: done
<seb128> cjwatson, thanks, set as admin too now
<ogra> does anyone know if upstart is supposed to work without initramfs ?
<lool> ogra: yes it should
<ogra> thanks
<lool> ogra: I have that from an email of scott from this morning or yesterday evening
<ogra> i dont get why my VM gets quiet then
<lool> s/of/from
<ogra> i dont get any boot messages at all
<lool> ogra: How can I easily reproduce?
<ogra> i can put my rootstock script on people.u.c and you need to install qemu-arm-static
<lool> Ok
<ogra> gimme one sec until the next test finishes
<ogra> i dropped all serial redirection, lets see if i see output in grapical mode of qemu-system-arm
<ogra> hmm, no, doesnt look like
<ogra> and the VM doesnt even use any CPU
<ogra> just sits there
<ogra> lool, http://people.canonical.com/~ogra/rootstock
<wrapster> how to i use the debchange -i to change the version number?
<pitti> wrapster: dch -v <version number>
<wrapster> pitti: what Im doing is actually modifying an existing pkg and i need to change the version number thats all..
<wrapster> pitti: i should use -v aye?
<pitti> wrapster: you shouldn't change an existing version number
<pitti> usually you add a new changelog entry with a new one?
<wrapster> pitti: yes thats what  I want to do
<ogra> dch -i ... in the tree of your unpacked source package
<ogra> that should fire up an editor with the changelog and incremented version number
<wrapster> yeah it did.. then
<wrapster> im a newbie so pls help
<ogra> well, you add your changelog entry after * (usually thats where your cirsor stands too at that point)
<ogra> *cursor
<ogra> soren, do you have to jump through any hoops to make upstart work in VMs ?
 * ogra doesnt seem to get qemu starting a basic deboostrapped image
<soren> ogra: Not really.
<ogra> weird
<ogra> i get zero output ... VM just sits there ... upstart doesnt seem to exec any jobs
<lool> ogra: Which package is the static qemu in?!?
<ogra> qemu-arm-static
<ogra> only i386 though
<lool> Why?
<lool> (I'm running amd64)
<ogra> because i had reports that people had additional syscall probs there ... i386 runs reliable
<ogra> though that wasnt actually with qemu-arm-static but with my former version
<ogra> i should enable amd64 again
<lool> As in it cant work due to a technical impossibility or really hard to fix problem, or it's a bit buggy?
<ogra> my former version surely was buggy
<ogra> the one in the package might not, i went the safe path and didnt enable amd64
<ogra> i probably should swithc it on again
<lool> ogra: uploadin
<lool> g
<ogra> what ?
<lool> With amd64 and lpia enabled
<ogra> ugh, lpia ?
<lool> yeah do you care?
<ogra> remember its all syscall translations :)
<ogra> not really
<ogra> apart from the bugreports i might get
<lool> on lpia?
<ogra> well, who knows
<lool> ogra: I just changed control; I think that's all what was needed
<ogra> yep
<ogra> but i dont know if it will work :)
<ogra> we'll see
<lool> Did you see qemu ftbfs on armel?
<lool> and ia64 and powerpc, for three different reasons
<ogra> yes, we talked about it before
<ogra> to be honest i dont really care
<ogra> hmm
<ogra> so: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel qemu-vmlinuz -hda qemu-armel-200909221415.img -m 256M -append "root=/dev/sda rw"
<ogra> gets me buffer I/O errors on sda
<ogra> thats new
<lool> that's what I was getting all the time when used as a buildd
<ogra> oh, because i just stopped the VM before
<lool> and infinity too
<ogra> i didnt
<ogra> and it works if i start with init=/bin/bash
<ogra> but then i'm missing the handfull of services i need
<lool> then it's something else
<ogra> its pretty clearly upstart
<lool> I'm speaking of the sda errors
<ogra> which i would be fine living without ...
<ogra> but there is no chance to exec initscripts without it anymore
<wrapster> ogra: and just write the version no there? like say * 1.6.2
<ogra> no
<wrapster> ogra: http://pastie.org/625551 have a look at this.. is it a makefile issue or because i've not updated the changelog properly?
<ogra> the version should already be in the top line
<ogra> that has nothing to do with dch -i
<wrapster> hmm a broken makefile you say?
<ogra> no, probably a codepiece that generates changelog from another file that hasnt been run or something
<ogra> in any case debian/cpp/usr/share/doc/cpp/changelog doesnt exist
<ogra> try to find out why
<ogra> shouldnt be caused by you using dch -i
<wrapster> yeah its been written in the rules...
<wrapster> anyway http://pastie.org/625551 i landed up with this.. is it normal to have warnings?
<james_w> yay pitti!
<pitti> james_w: what did I break?
<james_w> do you have bzr branches you would like me to push to bzr.debian.org?
<james_w> nothing (I hope) :-)
<james_w> you uploaded bzr et. al.
<pitti> james_w: no, I didn't; those were two syncs and two trivial package updates
<pitti> most of the time was testing and running "make check", etc.
<pitti> well, bzr itself has some path changes
<james_w> well, I was pulling my hair out on Friday about the bzr.install change
<pitti> james_w: for the doc translations?
<james_w> yeah
<pitti> I just updated it in the .install file
<james_w> I changed the paths in that file and it FTBFS
<james_w> I was blaming CDBS
<james_w> it wasn't running "setup.py install" before dh_install
<james_w> but at least it is done now
<pitti> weird, built fine here
<pitti> and on the buildds too
<james_w> yeah
<james_w> ah, that was it, I was doing the PPA packages first, which have a -doc package split
<pitti> james_w: ah, perhaps it's not run on -B ?
<wrapster> pitti: are you referring to me?
<james_w> it was running "setup.py install" after dh_install for arch-all packages but before arch-any
<james_w> no, I'd only got as far as my local pbuilder
<pitti> wrapster: no, I wasn't actually; what do you mean?
<james_w> I should have focused on the Debian/Ubuntu packages first
<james_w> anyway, thanks again
<pitti> my pleasure
<wrapster> pitti: anyway.. so did you go through the pastie?
<pitti> well, it was a mail in my ubuntu folder, and they are pestering me :)
<pitti> wrapster: http://pastie.org/625551 ? that looks very complicated; you usually don't call -genchanges manually
<pitti> just do debuild or dpkg-buildpackage
<wrapster> hmm
<pitti> seb128: FYI, current retracer crash is due to chroot upgrade failure; fixing
<seb128> pitti, thanks
<wrapster> pitti: its all about understanding makefiles.. but im not very good at it.. i only know a little basics.. do you happen to know any links that i can refer?
<wrapster> for understanding makefiles
<pitti> wrapster: I think there should be plenty of tutorials on the web
<StevenK> The info page for make has a good overview, but that means reading info pages. :-/
<dholbach> seb128: hum... got any reports that gdm is not starting properly?
<seb128> dholbach, no
<seb128> or some
<seb128> but usually those are xorg driver issues or the xorg server crashing or upstart
<dholbach> seb128: I just started the machine and just had the black login screen (up-to-date from around 10 UTC), then dist-upgraded to the newest versions, rebooted, same resulted
<dholbach> sudo restart gdm    started gdm
<dholbach> now I'll try booting it again
<seb128> I didn't update today yet
<seb128> and didn't read about those
<seb128> but you might be an earlier upgrader, I will keep an eye for bugs about that
<dholbach> ah... ctrl-alt-f7 gets me to gdm too
<dholbach> just the regular boot doesn't get me there
<dholbach> *shrug*
<ogra> buy more consoles ...
<seb128> maybe pitti knows better about those sort of issues
<ogra> we sell them cheap in the ubuntu shop ;)
<dholbach> ogra: I need to wait for my pay cheque, I guess :)
<ogra> heh
<dholbach> ogra: do you have an idea about bug 129769?
<ubottu> Launchpad bug 129769 in xscreensaver "newly installed xscreensaver errors without /usr/share/backgrounds" [Low,Fix released] https://launchpad.net/bugs/129769
<ogra> dholbach, i think cjwatson just uploaded/sponsored a fix
<dholbach> oh ok
<dholbach> nm
<dholbach> lalala :)
<ogra> :)
<uni4dfx> hello, my karmic doesn't wanna boot anymore
<uni4dfx> dmesg complains about some "Firmware Bug"
<tormod> uni4dfx: like not fatal. how far does it boot?
<tormod> likely not fatal
<uni4dfx> i can login
<uni4dfx> but there's no X
<uni4dfx> and most of the modules aren't loaded
<tormod> uni4dfx: fully updated?
<uni4dfx> probably not, last time i updated was 2 days ago
<uni4dfx> and it didn't wanna update anyway since it got into some errors
<tormod> uni4dfx: ubuntu+1 is a better channel for this
<sandy|lurk> Hi, there appears to be some ancient automatic import from Tomboy SVN (we moved to git six months ago) to Launchpad here: https://code.launchpad.net/~vcs-imports/tomboy/head
<uni4dfx> good point
<sandy|lurk> I'm not sure if I should file a bug or what
<sandy|lurk> but what I'd like is to either get rid of it (it's misleading) or have it pull from git master
<Laney> sandy|lurk: you should talk to someone in #launchpad about it
<sandy|lurk> Laney: will do, thanks
<cjwatson> sandy|lurk: https://answers.launchpad.net/launchpad-bazaar is the way we ask for changes there
<jelmer> pitti: thanks for updating bzr-svn for karmic!
<pitti> jelmer: no problem; it was mainly testing that the Debian experimental package works :)
<sandy|lurk> cjwatson: ok, take care folks
<uni4dfx> any idea what module the ULi 1689,1573 integrated ethernet device uses?
<jjardon> pitti, good news, evolution doesn't depends on HAL now: http://git.gnome.org/cgit/evolution/commit/?id=5a80f92d37e7e8a814f70f826b7b33f5d21b0f72 :)
<pitti> jjardon: cool!
<pitti> jjardon: did that land in 2.28.x still? or just trunk?
<jjardon> I think only trunk, 2.28 will be released in few days ;). Also in  https://bugzilla.gnome.org/show_bug.cgi?id=594006 said 2.29
<ubottu> Gnome bug 594006 in Plugins "[regression] ipod-sync plugin build fails" [Normal,Resolved: fixed]
<jjardon> but maybe could be backported to 2.28
<pitti> jjardon: right; should be fine then, there's no real hurry; we need hal for X in karmic anyway
<jjardon> pitti, Xorg devels added the bug I reported to the xorg 7.6 blocker list: http://bugs.freedesktop.org/show_bug.cgi?id=23462
<ubottu> Freedesktop bug 23462 in Input/Core "Remove HAL dependency" [Normal,New]
<pitti> jjardon: oh, *phew*; the upstream bug didn't move very far recently
<jjardon> nope :(, I'd like to help but I'm not a xorg expert ;)
<lool> kirkland: Hey do you mind if I do some relatively large cleanups to qemu-kvm's rules?
<ttx> slangasek: what's the status on publication of ec2-version-query to a more appropriate place ?
<LaserJock> james_w: what'd the difference between the DMB and MC?
<maco> dmb?
<james_w> as I understand it the DMB and the MC are likely to merge under archive-reorg
<james_w> maco: developer membership board
<maco> ah
<james_w> the TB is splitting off their developer approval role from their technical oversight role
<james_w> much as the CC did
<LaserJock> james_w: ah, OK, I wondered with the reorg what the difference would be, makes sense that they'd merge
<james_w> I don't think it's decided, but to many people I believe it is the logical step
<pitti> cjwatson, dholbach, james_w: also, DMB would only approve "core" developers and other generalists (what MOTU are today), but many contributors will probably just stay in one particular team like mythbuntu, right?
<pitti> IOW, the number of applicants should actually go down?
<james_w> that's my understanding
<pitti> for DMB?
<james_w> well, the absolute number might go up :-)
<LaserJock> is "core" developer defined under the new scheme?
<maco> james_w: and that might be a good thing
<LaserJock> my understanding was more along the lines of Core Dev getting split up into team upload rights and MOTU largely becoming generalists
<maco> i thought there could be per-package-uploaders that werent also motu in the new thing.  but then, im rather confused by the archive reorg stuff
<cjwatson> LaserJock: generalist is just a new word (which personally I don't like) for core-dev
<cjwatson> (I can't see people going around proudly wearing a badge saying "Ubuntu Generalist Developer")
<cjwatson> (well, not sure I can see that for core either, but it seems a bit more likely :-) )
<maco> haha
<LaserJock> yes
<LaserJock> so then MOTU either get "promoted" or get upload-access through a specific team?
<maco> cjwatson: i think a core dev badge would just make random people off the street yelling at you about their pet bug more likely :P
<highvoltage> hi LaserJock
<cjwatson> LaserJock: something like that, over time, yes
<cjwatson> LaserJock: we've started mail conversations with all current MOTU already
<cjwatson> though need to do a bit more with the results :)
<LaserJock> right
<LaserJock> although not a lot has been said to Core Devs
<LaserJock> presumably the status doesn't change much
<LaserJock> although our available set of packages we have upload access gets smaller?
 * LaserJock never remembers if "generalist" access is lower or higher "priority" than team access
<geser> LaserJock: only if you're interested in some special packages, like kernel or eglibc (don't know which packages end in the restricted set)
<soren> pitti: Hey. About https://bugs.edge.launchpad.net/ubuntu/+source/redhat-cluster/+bug/429834
<ubottu> Launchpad bug 429834 in redhat-cluster "FFE: Please sync redhat-cluster 3.0.2-2ubuntu1 (main) from PPA" [Undecided,New]
<soren> pitti: I'm wondering why you approved it, but didn't sync it?
<pitti> soren: it needs manual uploading, didn't get to it
<pitti> i just acked the FFE
<soren> pitti: Oh, ok. should I subscribe ubuntu-archive?
<soren> Or can't it be synced?
<pitti> oh, I don't know
<soren> I thought we could sync from anywhere.
<pitti> I'd just upload it
<geser> LaserJock: the current core-dev keep upload right to everything (modulo the restricted set), some MOTU get "promoted" to generalist, which give them the same upload rights as core-dev, team upload rights are completely new
<soren> pitti: Alright. I'll do so.
<soren> pitti:  Thanks.
<pitti> soren: copy-package.py might be able to do it, didn't check
<cjwatson> hmm, so the new initramfs-tools means that we expose an X bug again, where it sits munching CPU unless intel_agp was loaded first
<cjwatson> or possibly unless KMS was brought up first
<soren> pitti: I wouldn't know. The powers of ubuntu-archive have not been bestowed upon me, so I know little of the syntax copy-package would accept.
<cjwatson> weird, though, I thought that had been fixed a while back
<pitti> soren: I was just thinking aloud :)
<soren> pitti: :)
<sebner> geser: I have good news and bad news regarding libjgraph0.6-java. What do you want to hear first? ^^
<cjwatson> LaserJock: not sure what priority mean
<cjwatson> s
<cjwatson> LaserJock: core-dev's available set should remain (very nearly) the entire archive
<LaserJock> cjwatson: right, that's what I was getting at
<cjwatson> LaserJock: while we've talked about "restricted sets", I expect their use to be very limited
<LaserJock> I was wondering if generalists were going to be sort of in-between where they uploaded to everything *but* seeded packages
<cjwatson> LaserJock: there's a restricted set for language packs, on the grounds that if you upload them then your upload will get automatically overwritten later anyway, and this has always been the case
<Laney> is the switch on this going to be thrown soonish?
<cjwatson> people talk about making the kernel and libc restricted, but personally I don't see the need
<cjwatson> LaserJock: #define generalist ubuntu-core-dev
<cjwatson> Laney: it actually sort of has been and nobody noticed ;-)
<Laney> heh
<cjwatson> Laney: Launchpad now has package set data and can grant upload access to packages in those sets
<Laney> I mean the dissolving of universe
<cjwatson> Laney: we're gradually talking about the basics like getting ~ubuntu-desktop upload rights to the desktop set, which is mostly a process thing
<cjwatson> Laney: changing the component structure of the archive is still some way off
<cjwatson> and there are still some design things to solve there
<mdz> cjwatson, the server seed is part of ubuntu, while most other derivatives are separate, no?
<mdz> is that still the right setup?
<wrapster> supposing the rule file contains only the include directive and no command set.. how do i make changes to the existing pkg?
<wrapster> http://pastie.org/626056
<wrapster> have a look at that..its the rule file of grep.. I need some mods to be done there.. How should i approach it now?
<mdz> soren, the current manifests are machine parseable
<cjwatson> mdz: I've thought about splitting it out a few times, which probably ought to happen, but I don't think it's all that important or urgent
<soren> mdz: That's exactly why I'm not sure how to include this information in there.
<soren> mdz: The command line to build the image doesn't naturally fit into a "packagename version" sort of format :)
<cjwatson> wrapster: you'll have to look at what is laughingly referred to as CDBS's documentation
<soren> mdz: I'll work something out..
<soren> Hahah!
<cjwatson> wrapster: there's some stuff in /usr/share/doc/cdbs/
<mdz> cjwatson, soren is looking for a sensible way to record which version of vmbuilder was used to create each UEC image
<cjwatson> wrapster: you should familiarise yourself with debhelper first ('man debhelper', and chase references), since in many cases changes can be made by editing debhelper files
<wrapster> cjwatson: ok.. but i dont have cdbs under the dir you specified
<geser> sebner: start with the bad news
<soren> Well... Not just the VMBuilder version. That's reasonably easy (although slightly misleading if put in the manifest next to everything else), but more the command line used to build the image.
<cjwatson> wrapster: how do you normally install packages? :-)
<sebner> geser: ok, the bad news are now strange news xD
<wrapster> dpkg -i <pkg>
<cjwatson> wrapster: consider installing cdbs ... ;-)
<cjwatson> wrapster: that would normally be a prerequisite for reading its documentation
<wrapster> ok
<james_w> soren: just "# vmbuilder ..." ?
<cjwatson> soren: how parseable does it need to be?
<soren> cjwatson: You tell me.
<cjwatson> soren: could you just spit it out in the log, and save that somewhere?
<geser> sebner: then start with the strange news before they change again
<soren> cjwatson: I've never really used these manifests for much.
<cjwatson> soren: *shrug* *I* won't be using it
<cjwatson> what manifests are these?
<cjwatson> (url)
<sebner> geser: synced new package, removed old one. Replace b-d and cdk FTBFS. Then I used libjgraph0.6-java-link as b-d and this works now. And it also pulls in libjgraph-java but version 5.12.2.1.dfsg-1 , seems to be a different package xD
<soren> cjwatson: http://uec-images.ubuntu.com/karmic/20090922/ubuntu-uec-karmic-i386.manifest [+]
<soren> -[+]
<cjwatson> so that's a derivative of the live filesystem manifest
<cjwatson> which is automatically parsed in a way that may or may not handle comments, I don't remember
<cjwatson> although the UEC one is not automatically parsed, it's purely informational
<cjwatson> if it's useful to put comments in the manifest, I don't see a reason not to
<cjwatson> ah yes, the only code that parses manifests (ubiquity) handles comments, so *shrug*
<soren> automatically parsed by what?
<geser> sebner: you didn't miss the 't'? there is libgraph-java and libjgraph*t*-java
<soren> Oh, ubiquity.
<cjwatson> yeah, not that it parses UEC manifests, as I say
<soren> Right, right.
<soren> Obviously :)
<sebner> geser: ah, just noticed! xD I'm sorry. But anyways. Replace libjgrapht-java with libjgrapht0.6-java didn't work. I had to use the -link package (which pulls in 0.6-java also)
<cjwatson> but if you're borrowing its format anyway ...
<soren> cjwatson: Alright, I'll use a comment. That makes sense.
<cjwatson> the only real alternative would be to put it in a file inside the image somehow
<cjwatson> that sounds harder to inspect though
<geser> sebner: and what are the good news then?
<soren> It's already there, actually.
<soren> I put the build log inside the images.
<soren> Well, as much as I can, since part of the magic happens after the filesystem is finalised, but still.
<sebner> geser: New package sycned over and old one finally removed ^^
<sebner> geser: I'm sorry, this all sounds a little bit stupid xD , As I said cdk built locally but I uploaded to my PPA (start time 1 hour :( ) to be really sure the problem is solved now
<mdz> smoser, what's the EC2_URL used for EC2 itself (with euca2ools)?
<smoser> EC2_URL=https://ec2.amazonaws.com
<smoser> the environment you have to set for amazon use is:
<smoser> EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com
<mdz> smoser, thanks
<smoser> one thingto note, i could be under-informed on this, is that euca2ools require exporting your aws access key and aws secret key
<mdz> smoser, I think I have everything set up correctly now, but euca-describe-instances is hanging for a long time
<smoser> the ec2 tools require exporting a path to certificate file and path to private key.
<mdz> smoser, yes, I noticed that, but I don't understand why
<mdz> smoser, could you ask nurmi_ to join here so we can discuss?
<smoser> just did
<smoser> there is nurmi_ .
<smoser> above, i had said
<smoser> the environment you have to set for amazon use is: EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com
<smoser> one thingto note, i could be under-informed on this, is that euca2ools require exporting your aws access key and aws secret key
<smoser> mdz, i just verified that
<smoser> EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com euca-describe-instances
<smoser> is working for me.
<smoser> nurmi_, do you know why that difference ?
<soren> Sorry, what's the difference?
<smoser> between environment for euca- versus ec2-
<smoser> euca2ools require exporting aws access key and secret key. the ec2 tools require exporting a path to certificate file and path to private key.
<nurmi_> smoser: the ec2 tools use the SOAP interface (x509 credentials)
<nurmi_> smoser; the eucatools use the REST interface (secret/query key)
<soren> So they're not CLI compatible?
<soren> People who've set their environment variables according to ec2-api-tools will not be able to use euca-tools without changing stuff.
<soren> Right?
<smoser> so choice of rest over soap dictated the difference in credentials being needed.
<kirkland> cjwatson: so vmbuilder doesn't really support preseeding
<nurmi_> soren: it depends on how you use the tools
<soren> nurmi_: How so?
<nurmi_> soren: for example, the AMI tools from amazon use the REST stuff
<soren> nurmi_: Ok..
<nurmi_> soren: so, if you have your environment set up to use both EC2 API and EC2 AMI tools, then there is no change to use eucatools
<nurmi_> if you ONLY use EC2 tools, then you environment might not be sufficient for eucatools, as we need the REST crednetials (as does AMI tools)
<soren> I see.
<Laney> I think I am stuck in a redirect loop after submitting my UDS sponsorship
<Laney> can someone check if it worked?
<cjwatson> kirkland: ...
<kirkland> cjwatson: sorry, too many pots on the stove right now
<kirkland> cjwatson: the moodle package has a series of "critical" debconf questions in its config
<kirkland> cjwatson: i'd like to create a PPA package that set these values to something "sane", and depend on moodle, such that it gets installed
<kirkland> cjwatson: call it "moodle-appliance" or something
<kirkland> cjwatson: but "depends" means that moodle would get installed first
<cjwatson> I would recommend against attempting to do preseeding from a package
<cjwatson> everyone I've ever seen trying to do this ran up against lots of roadblocks and ended up wasting lots of time
<kirkland> cjwatson: yes, that's where i am
<cjwatson> preseeding is intended for admins and as such it doesn't work well when you try to do it from a package
<kirkland> cjwatson: i've wasted several days on this
<cjwatson> why not just have vmbuilder preseed stuff itself?
<kirkland> cjwatson: feature request for vmbuilder
<LaserJock> kirkland: you're just stuck on moodle or are there others?
<kirkland> cjwatson: i think there's a bug alreay
<cjwatson> understood, but it's the only sane approach
<kirkland> cjwatson: okay, thanks for the feedback
<soren> Laney: url?
<Laney> soren: url to what? http://summit.ubuntu.com/
<soren> Laney: Oh, never mind. I don't have access to that, i think.
<lool> kirkland: Heym I need to butcher the qemu-kvm rules heavily to fix the static build
<lool> kirkland: Hope you dont mind
<kirkland> lool: please, and thank you!
<lool> kirkland: Do you mind if I do further cleanups after that?
<kirkland> lool: go for it
<lool> Ok thanks
<ion> !summon Keybuk
<ubottu> Sorry, I don't know anything about summon Keybuk
<kirkland> lool: i'll review all of them afterward
<lool> Ok
<ogra> ion ++
<mdz> smoser, nurmi_, I'm trying to set everything up from scratch for EC2 using only euca2ools
<mdz> basically following the starter's guide with s/ec2/euca/
<smoser> mdz, http://wiki.debian.org/euca2ools got me going on euca2ools.
<mdz> smoser, I'm able to create an instance, but I'm not able to login
<soren> mdz: You've created a keypair and specified it on the euca-run-instances command line?
<mdz> soren,    83  euca-run-instances ami-fa658593 --key ${EC2_KEYPAIR} --instance-type m1.small
<mdz> atomicity:[~/ec2] euca-describe-instances |grep keypair
<mdz> INSTANCE	i-ef0fdb87	ami-fa658593	ec2-174-129-129-26.compute-1.amazonaws.com	domU-12-31-39-04-35-05.compute-1.internal	running 	ec2-keypair 	0 	m1.small 	2009-09-22T16:20:38.000Z 	us-east-1a 	aki-841efeed 	ari-9a1efef3
<soren> mdz: Looks accurate enough to me. And you're connecting as "ubuntu"?
<smoser> mdz, and EC2_KEYPAIR is the name associated ?
<mdz> smoser, EC2_KEYPAIR=ec2-keypair
<mdz> atomicity:[~/ec2] ssh -i ec2-keypair.pem ec2-174-129-129-26.compute-1.amazonaws.com
<mdz> Received disconnect from 174.129.129.26: 2: Too many authentication failures for mdz
<smoser> well, you can't get in as mdz
<mdz> (which is trying all keys from my ssh-agent)
<mdz> smoser, ah, of course, heh
<mdz> it would be nice if keypairs had a username associated
<smoser> hm... can you do that in a .ssh/config ?
<smoser> obviously you could set up all connections to *.compute.amazonaws.com to be ubuntu@
<mdz> smoser, that's a good idea
<jpds> Laney: It worked, and that's a known problem.
<jpds> Laney: Check http://summit.ubuntu.com/uds-l/sponsorship/ - or chase jcastro.
<jcastro> Laney: you're in the system
<lool> smoser: Sure, username
<lool> e.g. I have:
<lool> Host git.videolan.org User git
<lool> Argh, on two lines but you get hte idea
<smoser> lool, i knew you could do it by host. i was wondering if you could tie a key to a username
<smoser> but i dont think so. it'd be strange.
<mdz> smoser, I'm still seeing bug 427288 in the alpha 6 AMI
<ubottu> Launchpad bug 427288 in vm-builder "Karmic i386 EC2 kernel emulating unsupported memory accesses" [High,Fix committed] https://launchpad.net/bugs/427288
<mdz> smoser, judging by the comments, I thought it was fixed
<smoser> mdz, you're seeing (i think) bug 432718
<ubottu> Launchpad bug 432718 in dbus "dbus programs will not use nosegneg libraries" [Undecided,Confirmed] https://launchpad.net/bugs/432718
<cjwatson> smoser: you can't, because ssh can present several keys or none, and it doesn't start presenting them - and therefore know which one will work - until after it's already made the initial auth request including the username
<smoser> and soren was going to upload vmbuilder so i could make the emulation bug fixed-released.
<smoser> cjwatson, yeah, i didn't think so. it didn't make a lot of sense.
<smoser> mdz, does that look right ? ie you're seeing complaint about dbus ?
<mdz> pitti, is it possible to have apport-cli print out the URL rather than launching w3m in server installs?
<pitti> mdz: there's a wishlist bug for that; for now it is only possible to save the report and copy it to another machine
<cjwatson> does it follow the BROWSER environment variable spec?
<cjwatson> (or use sensible-browser)
<pitti> cjwatson: xdg-open, it should
<cjwatson> BROWSER=echo apport-cli? :-)
<mvo> dear network-manager, please keep your hands off my /etc/resolv.conf
<pitti> cjwatson: hm, doesn't seem to work :-(
<Amaranth> mvo: agreed
<Amaranth> Or at least don't add these stupid search lines
<mvo> yeah
<mdz> cjwatson, heh, that's probably worth a try
<mdz> oh, pitti tried
<mdz> I end up just suspending w3m and copy/pasting the URL from ps
<cjwatson> or hit u in w3m?
<mdz> if we want to strongly encourage ubuntu-bug for servers (and we do), I think we should do something about this
<cjwatson> or do you need to get it before redirection?
<mdz> cjwatson, screen size defeats me often when doing that
<cjwatson> = then
<mdz> the url is the correct one, but doesn't fit
<mdz> didn't know about =
<mdz> smoser, FYI I filed bug 434755 about some kernel dependency changes which are needed for ec2
<ubottu> Launchpad bug 434755 in linux-ec2 "ec2 kernel has unnecessary dependencies" [Undecided,New] https://launchpad.net/bugs/434755
<smoser> grub ?
<smoser> thanks mdz.
<sebner> Who has archive admins duties currently?
<ScottK> Today is Riddell's day.
<Riddelll> it's my very special day
<sebner> Riddell: you remember libjgraph0.6-java right?
<mdz> smoser, maybe a better solution, rather than trying to provide ec2-* names for euca2ools, would be to add those higher level CLI tools we've been talking about
<mdz> e.g. "start an instance using the current stable Ubuntu AMI"
<Riddelll> sebner: mm hmm
<mdz> those would wrap euca2ools and wouldn't need to worry about CLI compatibility
<mdz> nurmi_, ^^
<smoser> which would still require setting up *some* environment that could then provide other tools with the needed data.
<mdz> smoser, I'd like to work on minimizing the environment setup as well
<mdz> there are a lot of steps
<sebner> Riddelll: The synced source (by jdstrand) went to multiverse (again) which is the reason why we removed the old libjgraph-java package. Will move it to universe. Something went totally wrong
<smoser> erichammond's largest issue is with existing code that already works.
<mdz> a standardized configuration file would be much friendlier than a bunch of environment variable settings
<smoser> mdz, i agree.
<mdz> sane defaults would be even better
<Riddelll> sebner: what do you want me to do?
<smoser> the xc2 that i've pointed you at has a config file that it reads
<sebner> Riddell: move it from multiverse to universe
<smoser> i dont really know how you'd come up with a sane default for your amazon secret key... :)
<Riddelll> sebner: move libjgrapht-java?  I just deleted it
<smoser> but some of the others could be done
<sebner> Riddelll: no, you missunderstood. move libjgrapht0.6-java
<sebner> Riddell: libjgrapht-java was the old package (split over multiverse and universe) so I synced the new package and let you remove the old one. But the new one moved to multiverse instead of universe (don't know what went wrong)
<Riddelll> sebner: done
<ScottK> Riddelll: I just accepted moodbar back into the archive (the reason it was removed is no longer applicable).  I expect it's on the sync blacklist and should be removed.  Would you mind looking into it?
<sebner> Riddelll: Thank you very much =)
<pitti> ScottK, Riddelll: moodbar unblacklisted
<ScottK> pitti: Thanks.
<Riddelll> that explains why I can't see it in there :)
<ogra> could someone sync ltsp-docs from debian ?
<ogra> its new and holds the upstream documentation, no deps afaik
<Riddelll> ogra: ok
<ogra> thanks :)
<Riddelll> ogra: all done
 * ogra hugs Riddelll 
<ogra> when did you earn the third l btw ?
<Riddelll> when the server I used got moved but then the old one came back to life, so there are two of me now :(
<ogra> meh
 * Riddelll eyes up sladen 
<LaserJock> everybody always knew that more Riddell's would be a good thing :-)
<ogra> if he only could delegate more work to the others ;)
<asomething> ScottK: Thanks accepting moodbar
<ScottK> asomething: No problem.  We only had it removed because it didn't appear useful anymore.
<ogra> "udevd[392]: specified group 'fuse' unknown" ... why do i see that in a VM installing ubuntu-desktop but not in a chroot doing the exact same
<tormod> what is running hdparm (twice?) at boot (I have disabled acpi-support)
<kees> james_w: I've attached a patch to bug 307019 for gnome-about-me; should be easy to call that now.
<ubottu> Launchpad bug 307019 in gnome-control-center "ecryptfs Private directory not mounted after changing password in users-admin" [High,In progress] https://launchpad.net/bugs/307019
<james_w> kees: neat, thanks
<seb128> kees, his, feel free to commit and upload your gnome-control-center change
<ian_brasil> just got a django debug output from an error on http://summit.ubuntu.com/uds-l
<ian_brasil> change DEBUG = False in settings.py ..that info should not be available to all
#ubuntu-devel 2009-09-23
<seb128> slangasek, hum, assigning the bug to robert is a weird reply to my question ;-)
<slangasek> seb128: uh... it was a reply to rickspencer sitting next to me and telling me to do that :)
<slangasek> not sure I saw the question
<seb128> oh ok
<seb128> slangasek, I asked what you suggest changing
<seb128> to be honest I don't think that's the higher priority we have with gdm now too
<seb128> but I will not start discussing settings there ;-)
<slangasek> seb128: my initial suggestion to Rick was:  put an inactive 'login' button in the lower right-hand corner, so that the "default" button position is occupied by something safe
<slangasek> seb128: alternatively, don't highlight the first user in the list
<slangasek> seb128: I'm not arguing it's the highest priority... I do think it's something that significantly impacts usability and should be fixed before release
<seb128> you are concern by people clicking on shutdown by mistake?
<slangasek> seb128: I have done it *repeatedly*
<slangasek> so yes, it concerns me :)
<seb128> hum, ok ;-)
<seb128> you are the first one to mention that but one is enough
<seb128> adding an unactive button seems fine to me
<slangasek> seb128: sorry, it's a bug I should have filed a long time ago, but every time I run into it, my reboot takes long enough that I forget about it by the time I get to my browser ;-)
<seb128> just curious, I don't want to shutdown my box now, but it doesn't ask you before shuting down the box?
<slangasek> nope!
<seb128> that would be an another bug
<james_w> oh, and that's reminded me of one I found last night
<james_w> something just changed on my system so that hitting the power button shuts down with no prompt
<Keybuk> superm1: around?
<ion> keybuk: o hai
<Keybuk> hello
<ion> I rebased the mountall patches against 0.1.6 a few days ago for easy applying. :-)
<Keybuk> if you put them in bzr, it would be even easier
<NCommander> doko, it looks like migrating silo to GCC 4.4 broke it
<NCommander> doko, my SPARC won't boot with the newer SILO binary, I'll continue to debug but :-/
<NCommander> doko, (I also have confirmation of it occuring on another persons machine, same extact issue)
<ScottK> NCommander: gcc-4.3 is still in Main ....
<lifeless> anyone in ubuntu-release around? https://bugs.edge.launchpad.net/ubuntu/+source/bicyclerepair/+bug/434991
<ubottu> Launchpad bug 434991 in bicyclerepair "Sync bicyclerepair 0.9-6 (main) from Debian unstable (main)" [Wishlist,New]
<Darxus> There's a bicyclerepair package??
<ScottK> It's unlikely to be what you are guessing it is.
<[reed]> Darxus: http://bicyclerepair.sourceforge.net/
<Darxus> I checked aptitude show bicyclerepair.
<Darxus> So any opinions on removing azureus's popup that asks for money?  It's GPLed.
<ScottK> Remove it.
<Darxus> ScottK: Remove the popup?
<ScottK> Yes.
<Darxus> Excellent, thanks.
<Darxus> (I realize this won't make karmic.)
<ScottK> Why not?
<ScottK> Sounds like a bug fix to me.
<Darxus> ScottK: And you believe it will be accepted into universe?
<ScottK> Yep.
<Darxus> Thanks.
<Darxus> Looks like I can just insert a return() at the top of checkForDonationPopup() in azureus2/org/gudy/azureus2/ui/swt/donations/DonationWindow.java
<Darxus> Wonder what this thing is like to build :/
<glick> hey has anyone here used MPC as a build system?
<glick> or Scons or cmake?
<TheMuso> dtchen: Do you have any more pulse stuff lined up, or should I go ahead and push your changes?
<Darxus> That azureus stuff was intended for -motd.
<mase_wk> Hi guys, I have to make some kernel packages which need to be deployed for use on Xen guests using the latest kernel from kernel.org. Where is the best place to learn to package this ?
<LLStarks> ArneGoetje
<LLStarks> you there?
<ArneGoetje> LLStarks: yep
<LLStarks> about the ttf-tahoma bug
<ArneGoetje> LLStarks: yes
<LLStarks> you said that ubuntu tries to accommodate everyone
<ArneGoetje> LLStarks: no.
<LLStarks> but as i just commented, the current behavior is a regression
<ArneGoetje> LLStarks: I said, we try to provide sensible default settings that work for most users.
<LLStarks> that default has been ruined in karmic
<LLStarks> it was fine in jaunty.
<ArneGoetje> LLStarks: therefor it's not a regression. And hinting issues are definetely user specific configuration issues.
<LLStarks> this is a fresh install
<LLStarks> with upgrades
<ArneGoetje> LLStarks: the hinting settings were the same in Jaunty
<LLStarks> bad rendering is replicated on other hardware
<ArneGoetje> LLStarks: whether you prefer slight, medium or full hinting is your personal preference
<LLStarks> it's only on certain sites
<LLStarks> i don't want system-wide changes
<LLStarks> you saw my attachment, right?
<ArneGoetje> LLStarks: you are talking about websites, right?
<LLStarks> yes
<LLStarks> http://launchpadlibrarian.net/32285454/wrong.png
<ArneGoetje> LLStarks: if the same website renders differently on a fresh Jaunty and fresh Karmic with the exact same fontconfig configuration in /etc/fonts/conf.d/, then it's a bug in firefox.
<LLStarks> if that was the case, then firefox 3.0 wouldn't be affected.
<LLStarks> but it is
<ArneGoetje> LLStarks: IIRC there had been changes to the rendering settings in firefox3.0
<LLStarks> chromium and opera are affected
<ArneGoetje> LLStarks: can you replicate the same behavior in other applications, like gedit?
<LLStarks> no. only websites afaik.
<LLStarks> across many browsers
<ArneGoetje> LLStarks: then it's an issue with those browsers, IMHO
<LLStarks> or this: https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/412195/comments/27
<ubottu> Launchpad bug 412195 in wine1.2 "ttf-tahoma-replacement makes some web-sites look ugly" [Undecided,Fix released]
<ArneGoetje> LLStarks: no, it's definetely not a font issue, if the same font is rendered fine in other applications.
<ArneGoetje> LLStarks: you said yourself, that only browsers are affected...
<LLStarks> afaik
<ArneGoetje> LLStarks: does it happen only with some websites, or are all websites which use Tahoma affected?
<LLStarks> i'm not sure.
<LLStarks> only some websites though
<LLStarks> not sure about tahoma
<LLStarks> view source doesn't list fonts.
<ArneGoetje> LLStarks: you can test by creating a custom HTML file, set the font to use explicitely and lod it into the browser to see if you can reproduce the issue.
<ArneGoetje> LLStarks: if you are not sure that it's because of Tahoma, how come you insist on that bug report?
<LLStarks> i honestly don't know. what i do know is that fixing this issue made things worse for certain sites.
<LLStarks> it's ugly.
<LLStarks> yes, calling tahoma produces the error.
<LLStarks> just tested.
<ArneGoetje> LLStarks: LLStarks does it also happen in other non-browser applications?
<LLStarks> how could i test that?
<LLStarks> one sec.
<ArneGoetje> LLStarks: open gedit, set the font to Tahoma and type some text
<LLStarks> lemme screenshot
<LLStarks> arne. http://img132.imageshack.us/img132/6543/tahomatest.png
 * ArneGoetje is looking
<ArneGoetje> LLStarks: where is the error?
<LLStarks> it looks fine there. but it strains my eyes in the browser.
<LLStarks> it's as if the wrong font is being called.
<ArneGoetje> LLStarks: then the rendering in the browser and in gedit are different. can you try to open the file in oowriter?
<LLStarks> http://img89.imageshack.us/img89/3212/test2l.png
<LLStarks> a font shouldn't look that bad at size 10
<ArneGoetje> LLStarks: if you go to System->Preferences->Appearance->Fonts and click on Details..., what settings do you have there?
<LLStarks> subpixel, slight, rgb
<LLStarks> default.
<ArneGoetje> LLStarks: ok, can you please post the output of 'ls /etc/fonts/conf.d/' into a pastebin?
<LLStarks> http://pastebin.com/m6e479aac
<LLStarks> is it possible my home partition is interfering?
<ArneGoetje> LLStarks: ok, please paste the output of 'fc-match -v Tahoma' into a pastebin
<Benja> alguien que able espaÃ±ol
<Benja> por favor
<LLStarks> http://pastebin.com/m3ddf65c9
<mase_wk> Benja: #ubuntu-es might help
<ArneGoetje> LLStarks: please try the following: sudo ln -s /etc/fonts/conf.avail/10-autohint.conf /etc/fonts/conf.d/ and then compare again
<LLStarks> compare what?
<ArneGoetje> LLStarks: how it looks
 * mase_wk sighs
<Benja> alguien que able espaÃ±ol
<Benja> por fa
<mase_wk> Benja: no ables espaÃ±ol. #ubuntu-es
<Benja>  :|
<Benja> vaya sos mujer
<LLStarks> looks more or less the same
<Benja> que coÃ±o
<Benja> decis
<LLStarks> arnegoetje. it's not exclusively tahoma.
<LLStarks> can i pm you a picture to better demonstrate.
<ArneGoetje> LLStarks: sure
<mase_wk> Benja: Sea cortÃ©s. Hay un canal espaÃ±ol dedicado
<glick> hey can anyone recommend any good cmake tutorials/resources?
<glick> im having a hard time finding anything decent online
<mase_wk> glick: can you let me know if you find one  :)
<maco> the cmake book?
<mase_wk> i think he said good :)
<glick> grrr its so frustrating that there is not good documentation on this popular tool
<mase_wk> glick: i sat down to try and learn it but got nowhere in an hour
<lifeless> its not that popular ;)
<mase_wk> it is less popular than it should be.
<glick> i guess they dont want people to use their stuff
<lifeless> I think its about as popular as it should be :)
<mase_wk> the kde guys make good use of it
<mase_wk> lifeless: do you know of a better tool?
<glick> i guess they purposefully have crappy documentation cause they want you to buy courses from them on how to use it
<glick> guess ill fiddle around with it for another half hour, then i have to read for class :(
<glick> has anyone here heard of the MPC build system?
<dyek2> Hi! Is there a way to assemble an URL from sources.list and web sites specified by the URLs contained within it? Lets say I found in Packages.gz that udev package Filename is: pool/main/u/udev/udev_141-1_i386.deb. What is the exact URL to this package so that I can use wget to fetch it?
<dholbach> good morning
<dholbach> ArneGoetje: do you think you could take a look at bug 434054?
<ubottu> Launchpad bug 434054 in thaifonts-scalable "Waree font too high compared to Tahoma" [Undecided,New] https://launchpad.net/bugs/434054
<dholbach> also I'm not sure if I understand bug 434176 correctly... is it good enough to replace ttf-bitstream-vera with ttf-dejavu?
<ubottu> Launchpad bug 434176 in vdr-plugin-burn "Package uninstallable due to dependency on removed ttf-bitstream-vera" [Undecided,New] https://launchpad.net/bugs/434176
<dholbach> (replace it as a depends)
<dholbach> asac: if you could take a look at bug 424727 at some stage, that'd be great
<ubottu> Launchpad bug 424727 in tuxguitar "Please build tuxguitar with xulrunner 1.9.1 for karmic" [Undecided,Confirmed] https://launchpad.net/bugs/424727
<ScottK> Looks like something crashing in Soyuz.  It's been a coupld of hourse since any newly uploaded build started....
<dholbach> hum... there's just a OOo build that's been running for 2 days on armel
<wrapster> what type of package should ss12 be ? (single binary, multiple binary, library, kernel module or cdbs?)
<wrapster> im trying to build it ..so can you please help
<ScottK> dholbach: Yes and look how many builds are waiting.
<ScottK> wrapster: If you are working on a package you hope to eventually get into Ubuntu, #ubuntu-motu is a better channel to ask packaging questions.
<wrapster> scottk
<wrapster> ok thanks
<dholbach> what does "failed to upload" mean in LP speak?
<porthose> ScottK, would you set bug #435015 to won't fix?  It sounds like the reporter is describing the expected behavior of python2.6.  I asked in #ubuntu-bugs and they sent me here :)
<ubottu> Launchpad bug 435015 in python2.6 "python2.6 fails to create or use site-packages" [Undecided,New] https://launchpad.net/bugs/435015
<ScottK> porthose: I don't think they are.
<porthose> ok ty
<ScottK> The point of moving packaged stuff to dist-packages was so that unpackaged stuff could use site-packages without conflict.
<lool> Did someone raise this to IS already?
<ScottK> lool: Not that I know of
<ScottK> porthose: I'm sure doko_ will look at it and give us the answer at some point.
<porthose> I'm sure he will so I will leave it for him :)
<lool> ScottK: sample package?
<lool> I checked pango1.0 and libgnome uploaded overnight and they were fine
<ScottK> lool: https://launchpad.net/ubuntu/karmic/+source/quassel/0.5.0~rc1+vcshead090922-0ubuntu1
<lool> thanks
<ScottK> That was upload an hour ago.
<lool> So I raised the /builders beings idle with builds in queue and quassel not starting anywhere
<lool> probably the daemon process on the buildds hung again
<lool> ScottK: The high number of builds on i386 might be a mass archive rebuild in some special archive
<lool> I dont remember its URL but there's a rebuild of ubuntu going on since some days
<ScottK> lool: Yes, that's on the PPA buildds.
<ScottK> But they should run only when no regular PPA builds are waiting.
<ScottK> No idea why the distro buildds would be stuck
<pitti> Good morning
<glick> excuse me, is anyone here familier with cmake?
<glick> i have a structure question
<lifeless> #cmake
<glick> yeah no one is there thats awake
<jussi01> glick: you might be better asking in #kubuntu-devel or #cmake
<glick> thanks
<ArneGoetje> dholbach: what is missing on bug 434176?
<ubottu> Launchpad bug 434176 in vdr-plugin-burn "Package uninstallable due to dependency on removed ttf-bitstream-vera" [Undecided,New] https://launchpad.net/bugs/434176
<soreau> What would be the best way to check whether or not a given package is installed from a script?
<liw> soreau, by querying dpkg I guess
<soreau> liw: dpkg I just shows dpkg: need an action option
<ArneGoetje> dholbach: bug 434054 looks also good to me...
<ubottu> Launchpad bug 434054 in thaifonts-scalable "Waree font too high compared to Tahoma" [Undecided,New] https://launchpad.net/bugs/434054
<glick> hey the include_directories() option in cmake, is that just for header files or for implementation files as well?
<liw> soreau, the manpage should give you the options you need, depending on what you need to do
<dholbach> ArneGoetje: I was more wondering if dejavu was a drop-in replacement of vera-bitstream
<dholbach> or if there was anything else required
<soreau> liw: I read the dpkg man page and not really coming up with anything useful. The best I can come up with is maybe dpkg -l|grep <package>|grep ii
<soreau> liw: I would like to know the syntax to use 'I' though
<liw> soreau, have you looked at --status ?
<lool> soreau: dpkg -l <package> | grep ^ii; or if you want to be more robust use dpkg-query -s <package> and look for "Status:"
<soreau> liw: Well that works to but I guess I was just looking for a 'cleaner' way of doing it. Can you tell me what you were talking about with your original suggestion dpkg I? I could get that to work at all
<liw> soreau, er, what?
<soreau> [01:25:28] <liw> soreau, by querying dpkg I guess <- how do I do that
<liw> soreau, I am not understanding your confusion
<liw> soreau, you just told me that running dpkg --status works for you, what is the problem?
<soreau> liw: Well I remember one time someone showed me a dpkg command to list all installed packages with no additional info. Just a list of strictly package names
<soreau> But I can't figure out for the life of me what it was
<ArneGoetje> dholbach: dejavu is based on bitstream vera with greater coverage, so yes, it is a drop-in replacement
<soreau> Now I am wishing I had made a note of it
<dholbach> ArneGoetje: so no changes are necessary - the font will just be "picked up"?
<soreau> liw: I found it now.. it was --get-selections
<soreau> liw: Thanks for your help
<ArneGoetje> dholbach: that, I don't know. It depends on if the application explicitely queries the font file or not. It should not do that of course...
<dholbach> hrm
<ArneGoetje> dholbach: but if it's only about the metrics, it should work
<doko_> ScottK: hmm, please ask pitti or somebody who merged cdbs
<dholbach> pitti: regarding bug 431823 (freeflying pinged me about the patch of lidaobing): do we still need pre-depends of some kind?
<ubottu> Launchpad bug 431823 in ibus-table-wubi "the dependent packages are too large" [Undecided,Confirmed] https://launchpad.net/bugs/431823
<cdE|Woozy> is the patch from bug 372874 going to be included in karmic?
<ubottu> Launchpad bug 372874 in hal "[ThinkPads] No brightness-notification - Bug in generic get_brightness function" [Unknown,Fix released] https://launchpad.net/bugs/372874
<pitti> james_w: I just noticed bzr bd during fetching orig tarball:
<pitti> tar -xjf transmission-1.75.tar.bz2
<pitti> tar -cf - transmission-1.75 | gzip -9 > transmission_1.75.orig.tar.gz
<pitti> james_w: wouldn't a mere bunzip2/gzip9 be better (keeping the tar as it is)?
<dholbach> pitti: I just fell out of the internet... did you reply? if not... take your time :)
<pitti> dholbach: didn't yet, sorry
<dholbach> as I said... take it easy - it's still only 10:07
<lool> cjwatson: thanks for new debootstrap
<dholbach> cjwatson, slangasek: do you have an opinion about moving bicyclerepair to universe? (bug 434991)
<ubottu> Launchpad bug 434991 in bicyclerepair "Sync bicyclerepair 0.9-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/434991
<lifeless> ohhh sponsors!
 * lifeless seeks more +1s
<pitti> dholbach: yes, we still need that for lzma, let me check
<pitti> dholbach: Pre-Depends: dpkg (>= 1.10.27ubuntu1)
<dholbach> lidaobing, freeflying: you will need a pre-depends too ^
<lidaobing> dholbach, lintian æ²¡ææ¥éï¼æä»¥ä¸ºå·²ç»ä¸éè¦äº
<lidaobing> dholbach, lintian does not warning on this, so I thought it no longer needed in karmic
<freeflying> lidaobing: haha, you're speacking chinese :)
<lidaobing> freeflying, sorry, i thought here is #ubuntu-zh
<dholbach> lidaobing: it'll be necessary for upgrades
<lidaobing> dholbach, OK, i'll fix it and reupload in today
<dholbach> super
<dholbach> gracias
<lifeless> pitti: I want your +1. https://bugs.edge.launchpad.net/ubuntu/+source/libgetopt++/+bug/434927 https://bugs.edge.launchpad.net/ubuntu/+source/config-manager/+bug/434943
<ubottu> Launchpad bug 434927 in libgetopt++ "FFe: Sync libgetopt++ 0.0.2-p22-3 (universe) from Debian unstable (main)" [Wishlist,New]
<glick> hey how do i send compiler options to the compiler using cmake?
<soren> Errr... Can't I file bugs directly on Launchpad anymore? Seriously?
<soren> ah. I need to add ?no-redirect to the URL. That's really annoying.
<dholbach> asac: gracias
<asac> welcome
<dholbach> soren:    alt-f2 "ubuntu-bug <package>"
<soren> dholbach: "directly on Launchpad"
<dholbach> it will directly open a launchpad bug ;-)
<asac> soren: yes. its a bit annoying that you get redirected ... so you cannot even just append it afterwards ;)
<soren> asac: Exactly. *grumble*
<seb128> dholbach, when firefox doesn't crash or when your proxy doesn't block apport and when you are wanting to send details on the box you are using which might be not the one having the issue
<dholbach> if firefox crashes, you need to mail
<seb128> to mail what?
<dholbach> the bug report
<dholbach> apport could give you instructions for that, but it'd be tough as you can't add your GPG key to LP without a browser :)
<seb128> there is an open bug about not redirecting bugcontrol
<seb128> that's what we need ;-)
<dholbach> I think it'd be better if we fixed all the issues with ubuntu-bug first :)
<cjwatson> dholbach: bicyclerepair> I have no opinion on it
<dholbach> and make use of it
<cjwatson> dholbach: ubuntu-bug clearly isn't always appropriate, though
<cjwatson> dholbach: consider: "I can't install Ubuntu, here's why"
<soren> Or "I have this problem on one of my servers, and want to report it from my laptop".
<dholbach> right, I'm just saying that before we say "ok, just drop the redirect for us" is not going to help us fix the biggest issues with it
<james_w> pitti: are you sure that's not a get-orig-source rule?
<pitti> james_w: whoops, indeed it is; thanks
<seb128> dholbach, my issue with ubuntu-bug is not bugs, is that it's slower for me than using the web ui and not required to open for example workflow bugs for desktop upgrades
<dholbach> seb128: AIUI it's an experiment now to find issues like the ones we talked about above
<seb128> yes, not discussing that
<harobed> hi, what do you use to make your UI mockup like at https://wiki.ubuntu.com/NotifyOSD#software-sources ?
<harobed> inkscape ?
<seb128> you seem to argue that I'm wrong wanting to not use it though
<dholbach> no
<dholbach> I just say "let a few of us not be redirected" won't help us fix issues that a lot of users are going to have soon
<seb128> gotcha
 * seb128 hugs dholbach
 * dholbach hugs seb128 back :)
<seb128> the main issue out of the firefox crash asac should fix soon is people having valid reason to not use apport
<cjwatson> as long as the experiment doesn't have a predetermined outcome. What is required to consider it a failure and drop the redirect?
<seb128> we probably need to get a middle way, it having a button to open a bug anyway on the redirect page for example
<cjwatson> yes, it takes you to a wiki page that tells you how to do it by URL hacking if you read really carefully, buried about half-way down
<cjwatson> that's definitely nowhere near good enough
 * lifeless hugs file-by-mail
<Daviey> No, greacemonkey cuts the mustard on an individual level
<cjwatson> it needs to be right up top - at which point I wonder if it will make any difference at all, since people will just press the big button
<Daviey> err greasemonkey
<cjwatson> individual's not a problem
<lifeless> what about a url handler
<cjwatson> my thought experiment is this:
<lifeless> in fireforx
<lifeless> like filebug:
<cjwatson> lifeless: worthless if you can't file from Ubuntu
<Ng> harobed: I think mpt draws them by hand ;)
<cjwatson>  * a user is having problems installing Ubuntu, and goes to file a bug from another machine
<cjwatson>  * we redirect them to a big wiki page preaching about how they should use tools they don't have
<cjwatson>  * they think "sod this, they obviously don't want my help" and give up
<lifeless> cjwatson: I was thinking it could be a little smart, and show the bug filing form if that handler didn't get run
<harobed> Ng: ok and scanned
<mpt> harobed, yes, I drew that by hand and scanned it. Contrast increased using the Curves function in Gimp.
<Ng> I still think someone there should be an mpt gtk theme ;)
<Ng> -someone
<harobed> mpt: ok, your mockup are very nice
<lifeless> cjwatson: I agree with your gedanken. A similar run I ran into a little while back was a upstream developer who gets their package packaged in Debian via -mentors; faced with the hurdles that sync bugs want they had given up.
<lifeless> cjwatson: I pointed them at request sync, and now they are happy
 * Daviey edits h.u.c/community/ReportingBugs to include a paypal link to "get your bug fixed faster" :).
<virtuald> that's not a bad idea
<virtuald> alt-f2 doesn't work in karmic :/
<lifeless> virtuald: ztrl-alt-F2
<virtuald> hehe
<lifeless> alt-f2 is help, or something
<virtuald> it's run application
<lifeless> oh, well it works for me
<virtuald> in karmic?
<lifeless> something approximating it
<lifeless> cjwatson: could I interest you in three sync requests; one (bicyclerepair) that needs discussion about whether to demote it to universe or promote vim-addon-manager
<lifeless> cjwatson: and two trivial ones
<cjwatson> lifeless: sure?
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bicyclerepair/+bug/434991
<ubottu> Launchpad bug 434991 in bicyclerepair "Sync bicyclerepair 0.9-6 (main) from Debian unstable (main)" [Wishlist,New]
<lifeless> thats the problem one
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/libgetopt++/+bug/434927   https://bugs.edge.launchpad.net/ubuntu/+source/config-manager/+bug/434943 are trivial seeking a second +1
<ubottu> Launchpad bug 434927 in libgetopt++ "FFe: Sync libgetopt++ 0.0.2-p22-3 (universe) from Debian unstable (main)" [Wishlist,New]
<Dyllan> Hi all. Is there a file that I can view/access where Synaptic keeps its proxy settings?
<mvo_> Dyllan: yes, but its kept in /root/.synaptic by default
<mvo_> Dyllan: it will use the gconf proxy settings though in ubuntu
<Dyllan> mvo_, thanks ill look into that.
<cjwatson> lifeless: I can't say I have any problem moving brm to universe
<pitti> lifeless: hi
<lifeless> I'm pretty sure its in main cause 'its python'
<lifeless> pitti: hi, I snagged cjwatson :)
<cjwatson> vim-addon-manager is useful enough of course, if you install other things that need it
<mvo_> Dyllan: what do you need it for (out of curisosity)
<cjwatson> but I think this is the first time it's come up so I guess it's not otherwise required yet
<cjwatson> yes, it is in main because it's python
<pitti> lifeless: right, seems ScottK beat me to it; sorry for delay
<lifeless> pitti: two +1's are needed :P
<lifeless> pitti: ScottK was the first
<lifeless> pitti: we'll need two on the bicyclerepair one
<lifeless> cjwatson: I'm happy either way; I have not particular suggestions to offer
<lifeless> rdepends on vim-addon-manager isn't hugely enlightening
<Dyllan> mvo_, Well I have +-10 mobile ubuntu users, basically staff who have ubuntu installed on their laptop and move to different locations, each location requiring different proxy settings for Thunderbird/Firefox, and changes to the /etc/hosts file.
<Dyllan> mvo_, So i created a program that changes this for them very easily by then selecting their location, it applies all setting to TB/FF and the /etc/hosts file.
<lifeless> Dyllan: proxy.pac is your friend, if you can use that approach.
<pitti> lifeless: ok, done these two (getopt and config-mgr)
<lifeless> pitti: thank you!
<Dyllan> mvo_, the only change i am missing now is the Synaptic proxy settings, depending on whether they are in the office our out of the office, so i wanted to know what file to edit to be able to achieve this.
<pitti> lifeless: I don't mind having bicyclerepair in universe either; it's equally useful there, and we don't _really_ maintain it anyway
<Dyllan> lifeless, yes for sure, although I have preferred to write my own from scratch and customize it to our company's needs, but thanks for the info.
<lifeless> pitti: no, clearly ;P - it was broken in vim for two releases till I got a round TUIT
<sebner> cjwatson: as you are archive admin today, might looking what happned to mono 2.4.2.3+dfsg-2? 3 weeks ago we synced, got lost. Yesterday synced again and still missing :\
<pitti> lifeless: I move it to universe and ack the sync
<lifeless> cjwatson: ^ if you could do the second +1 I'd be much obliged
<glick> how do you know what name to put for the package?  and what do they mean by package?
<glick> in cmake
<glick> for the option find_package
<lifeless> glick: #cmake please
<glick> yaeh cmake is dead
<lifeless> or #kde-devel or whatever its called
<glick> thoght someone in here might know
<lifeless> glick: its not particularly ontopic here
<glick> sorry, i figured, being in a devel channel, someone in here might know
<glick> sorry
<mvo_> Dyllan: ok, using gconf (via gcooltool --set) should work I think
<lifeless> glick: they may, but you've had no indication of that over an 8 hour or so window of questions. I think that if someone here does know, they are keeping it very quiet :)
<Dyllan> mvo_, excellent thank you.
<glick> lifeless, someone coulda come in that knows :P
<cjwatson> pitti: you know, I'm being archive admin this morning, you can do something else rather than preempting me when I'm already looking into something ... ;-)
<lifeless> cjwatson: that was my fault I suspect; sorry.
<cjwatson> pitti can read scrollback :)
<lifeless> :)
<cjwatson> I'm waiting for my browser to reboot
<lifeless> do you have many tabs?
<pitti> cjwatson: sorry, it wasn't clear to me that you were going to
<cjwatson> lifeless: yes
<lifeless> me too. I find that 'network down, start browser, network up' works rather well.
<cjwatson> I just hit escape to stop all the tabs loading after a while. firefox-3.5 is better at remembering the URLs even if I do that before it had managed to load any of the page at all
<lifeless> cjwatson: thank you!
<cjwatson> YokoZar: the wine1.2-dbg package is empty - intentional? (accepted anyway)
<lool> ScottK: buildds building again
<sebner> seb128: mono vanished again :\
<YokoZar> cjwatson: err, no, that would be a bug with the rules file
<YokoZar> cjwatson: found it, misspelling with --dbg-package=
<unggnu> hi all
<unggnu> What are the plans for Karmic and Rhythmbox. Should it still be replaced because in current Karmic it is still the default
<pitti> unggnu: it will stay the default
<unggnu> pitti: thx
<bdrung_> who is responsible for copying packages from -proposed to -updates?
<cody-somerville> bdrung_, archive admins
<bdrung_> cody-somerville: so i can unsubscribe the sponsors
<bdrung_> thanks
<seb128> sebner, I blame it on soyuz then, I've pinged them about it
<sebner> seb128: thx
<MacSlow> seb128, hey there
<seb128> hey MacSlow
<pitti> bdrung_: usually that's me
<bdrung_> pitti: ?
<seb128> <bdrung_> who is responsible for copying packages from -proposed to -updates?
<bdrung_> k
<bdrung_> pitti: i was cleaning up the sponsors list
<smoser> wonder if anyone can help.  I'm trying to get a refreshed version of the hardy ec2 image.  I'm building an chroot of hardy on a karmic system.
<smoser> a 'chroot <target> apt-get install .... x11-common' is dying with segfault in x11-common's post install
<smoser> anyone have a clue as to how to work around or fix ?
<smoser> http://paste.ubuntu.com/276384/ is the full vmbuilder log
<smoser> it ends in
<smoser> dpkg: error processing x11-common (--configure):
<smoser>  subprocess post-installation script returned error exit status 139
<zul> smoser: thats probably not a godo thing
<pitti> tkamppeter: hi! got a minute?
<pitti> tkamppeter: I would like to discuss the cupsctl call with you
<pitti> tkamppeter: I'll throw it out of the init script again; it causes conffile questions, and overwrites the admin's settings
<pitti> tkamppeter: instead, I'll change the default value in the code from "8m" to MemTotal/4
<mbiebl> pitti: hi
<mbiebl> have you noticed that Keybuk had uploaded a cups version with native upstart jobs
<pitti> hey mbiebl
<pitti> oh, he did?
<pitti> I'll merge that into the bzr branch then
<mbiebl> well, at least it in the ubuntu-boot ppa
<pitti> ah
<mbiebl> pitti: btw, I'm going to move the libatasmart libs to /lib as apparently dk-disks uses it in it's udev helpers
<pitti> mbiebl: right, makes sense
<pitti> same happened for glib in Debian, I think
<pitti> one of the tree callouts uses glib
<mbiebl> yeah, I asked Np237 for that
<mbiebl> as new enough glib/gtk are now in unstable, I'll start uploading newer DK/CK/PK versions soonish
<pitti> oooh
<mbiebl> which should (mostly) sync with the current Ubuntu versions
<pitti> mbiebl: I wanted to ask you about PK, and whether I should just upload it to experimental
<pitti> I wasn't aware that it was waiting for glib
<mbiebl> The other one is libgudev, will have to prod Md when he plans to upload it to unstable
<pitti> mbiebl: I'm fine with helping to commit the recent versions/packageing changes to git
<mbiebl> cool
<pitti> looking forward to getting in sync again
<pitti> and doing packaging in VCS
<pitti> not using any vcs really feels strange nowadays..
<seb128> pitti, speaking about glib did you review the debian update?
<mbiebl> pitti: I made a few changes to PK 0.94 so I can use symbols files proper
<mbiebl> fortunately the patch has been accepted upstream already
<pitti> mbiebl: still on my list
<pitti> mbiebl: right, I remember that this one was a beast
<pitti> there was one package where I used .shlibs, because there were too many foreign symbols in it
<pitti> erm, I meant: seb128: still on my list
<seb128> pitti, ok no hurry, thanks
<mbiebl> pitti: regarding PK 1.0
<mbiebl> had a brief chat on #gnome-debian
<mbiebl> afaics hal is the only main package which is (and won't be) ported to PK 1
<mbiebl> what do you think about disabling PK/CK support in hal and using static groups resp. at_console in the dbus security policy
<mbiebl> this way we could get rid of the PK 0.9 stack for squeeze/karmic
<asac> can i teach gdb to automatically run backtrace when it breaks?
<pitti> mbiebl: re (sorry, got a call)
<pitti> mbiebl: I actually thought about that
<pitti> mbiebl: Fedora did that as well
<pitti> mbiebl: it wouldn't make a difference in GNOME
<pitti> mbiebl: but KDE still uses it
<mbiebl> right
<pitti> mbiebl: so what it would change is that there would be a way to mount internal storage devices without authorization
<pitti> or, if we don't allow that, there wouldn't be any way for KDE to mount internal drives
<pitti> Fedora did the former
<pitti> but I don't really like that
<mbiebl> are you sure about that?
<pitti> yes
<pitti> mbiebl: check http://cvs.fedoraproject.org/viewvc/devel/hal/hal-use-at-console.patch?revision=1.1&view=markup
<mbiebl> no, I mean that KDE handles internal storage correctly
<pitti> ah
<pitti> well, Solid uses hal ATM
<pitti> I think a port to udev/DK is in the beginnings, but far from being releasable
<mbiebl> well, if you click on a internal storage device in say dolphin
<pitti> mbiebl: it's really a sting in my eye as well, but I rather hope that X can be fixed to not use hal any more
<pitti> and then we can drop hal and PK 0.9 at the same time
<mbiebl> you will only get the hal PermissionDeniedByPolicy error message
<pitti> mbiebl: (right, I didn't actually _try_ it in KDE admittedly)
<mbiebl> KDE will not try to authenticate you via PK
<pitti> Riddell: ^ does that work for you?
<pitti> I thought for reasons like this we still have the old PK in the first place
<mbiebl> and the PK support in system-settings (via libpolkit-qt) is not used
<pecisk> hi people, is gnome-shell broken in Karmic or I just got unlucky in running it? :)
<mbiebl> I asked the kde guys on #debian-qt-kde and they were fine with dropping PK 0.9 support (via libpolkit-qt)
<pitti> yay
<pitti> mbiebl: sure, then let's use at_console, but not allow internal storage?
<mbiebl> fine with me
<pitti> I'll still confirm with Riddell, though
<mbiebl> that is basically what we have in lenny
<Riddelll> pitti: what's the question?
<pitti> Riddelll: can you mount internal partitions in KDE? does it ask you for PK auth using the old (0.9) policykit-qt?
<Riddelll> pitti: yes you can, it's a Kubuntu patch, and it uses kdesudo not policykit
<pitti> ah, sweet
<pitti> Riddelll: so if hal would restrict that only to root, it would actually work fine?
<Riddelll> pitti: I expect so yes
<pitti> rock
<pitti> Riddelll: I'll upload a hal with that then, and test it on tomorrow's kubuntu live
<pitti> if it doesn't work, I can still roll back before beta
<pitti> thanks
<Riddelll> ok
<pitti> mbiebl: so, seems fine :)
<mbiebl> pitti: so, remaining PK 0.9 packages are argyll, connman, gksu-polkit, packagekit and libvirt
<mbiebl> for libvirt, I know there are patches
<mbiebl> I think connman has a configure switch which allows to disable PK support for now (until ported)
<mbiebl> And I'm pretty sure PackageKit has PK 1.0 patches too (given that fedora uses it)
<pecisk> mbiebl: just curious, you getting rid of PolicyKit? :)
<mbiebl> PK 0.9
<mbiebl> pecisk: it would be a pain to ship with two PK stacks
<tkamppeter> pitti, hi
<pecisk> mbiebl: I see :)
<al-maisan> Hello there! In order to test a pristine-tar extension of mine (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545457) I'd like to get my hands on the debian tar balls for sid. What's the best way to achieve this?
<ubottu> Debian bug 545457 in pristine-tar "gendelta should abort when files are missing in local tree" [Normal,Open]
<cjwatson> al-maisan: they're supposed to be imported into LP, https://launchpad.net/debian etc.
<al-maisan> cjwatson: sure .. I hoped there would be source CDs that I could download in one fell swoop.
<ScottK> lool: Thanks for minding getting things started again.
<pitti> mbiebl: btw, I tracked that on https://wiki.ubuntu.com/DesktopTeam/PolicyKitOneMigration
<mbiebl> pitti: nice, thanks
<pitti> mbiebl: yes, PackageKit 0.5 uses PK 1.0, just not the 0.4 branch which we are carrying
<pitti> mbiebl: we'll switch to packagekit 0.5 once polkit-1-kde exists
<mbiebl> ok
<tkamppeter> pitti, I have seen your CUPS change, how will you set MemTotal/4 as system default at build time?
<pitti> tkamppeter: I'll still get to that
<pitti> tkamppeter: not at build time, as an internal default in the code (which currenlty sets "8m")
<tkamppeter> pitti, now I understand.
<mbiebl> pitti: updated the wiki a bit
<seb128> sebner, directhex: the mono syncs is done now, it required manual tweaking to the .changes soyuz explode on the new line chars in the binaries list there
<directhex> seb128, really? that's a bit weird. any idea what could cause that?
<seb128> directhex, the new line chars or soyuz to explode?
<directhex> both, perhaps
<seb128> directhex, dunno for the .changes
<directhex> the only case i know of where newlines are funny is msdos line endings... which wouldn't be the case here
<seb128> but that's not rfc-822 coompliant and a case which didn't happen before apparently and that soyuz doesn't handle
<seb128> lack of feature or bug as you want
<seb128> I will open a bug now
<cjwatson> al-maisan: oh, there should be those yes, try http://www.debian.org/CD/jigdo-cd/
<al-maisan> cjwatson: thanks!
<jjardon> hello all, libusb-1.0 is in the repositories, but the installed version is still 0.1-4 in current karmic. Does anyone know why?
<highvoltage> cjwatson: for the alternate CD, there's a preseed for installing an LTSP server and a F4 menu option in gfxboot, is there a way we can get that for the Edubuntu DVD?
<sebner> seb128: thanks for your work and letting us know!
<pitti> mbiebl: http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/revision/355
<pitti> mbiebl: works fine here
<mbiebl> pitti: I'm wondering what the CK support in HAL now is doing
<mbiebl> given that we no longer user PK and the ACL handling
<pitti> hm, good question
<pitti> I disabled ACL support in our hal long ago
<mbiebl> pitti: hald/access-check.c
<mbiebl> 223ff
<mbiebl> If I read it correctly, you could just as well disable CK support, as your dbus policy file basically provides the same level of access control
<kees> pitti: ah... we disable apparmor's init script on the liveCD don't we?  so by me moving it into the initramfs, we've bypassed that again.  erk.
<kees> pitti: I will take a look at this today.
<pitti> kees: ah, so it might have been the recent upload indeed
<pitti> kees: I wasn't quite sure whether AA was disabled in earlier live systems
<pitti> mbiebl: re (sorry, phone); I quickly grepped for HAVE_CONKIT, and there's quite a bunch of it
<highvoltage> I see some people used the /specs namespace on the wiki for karmic
<highvoltage> wouldn't that be a good convention for all specs?
<highvoltage> perhaps even /specs/karmic /specs/lucid, etc?
<pitti> highvoltage: we started using TeamName/Specs/Release
<pitti> e. g. DesktopTeam/Specs/Karmic/
<highvoltage> pitti: ah I see it's a well established convention. cool.
<ogra> highvoltage, one i told ace several times now :P
<ogra> (though only for new specs)
<LaserJock> ogra: you mean all specs ever written should be move to conform?
<LaserJock> *shouldn't
<ogra> no,
<ogra> my god
<LaserJock> ;-)
<ogra> right, shouldnt :)
<ogra> all new ones should be created like that
<LaserJock> ogra: it doesn't seem as if meeting logs have quite as an estabilished a convention
<ogra> well, the scribes team made one up
<ogra> many teams stick to that
<LaserJock> some logs are still in MeetingLogs/ , some are in <team>/Meetings, etc.
<LaserJock> I still have 64 wiki edit emails from that one :/
<ogra> https://wiki.ubuntu.com/MobileTeam/Meeting/2009/
<ogra> thats what we use in my team
<bdmurray> pitti: does apport-collect work with a symptom (like storage)?
<pitti> bdmurray: not right now; I'm a bit unsure about what the semantics of that would be, since it's kind of backwards
<pitti> a symptom determines the affected package
<pitti> but apport-collect works on already existing bugs
<pitti> so far I worked around that by asking the reporter  to run apport-bug and file a new one, and tell me the number
<pitti> we could perhaps make it to change the affected package?
<bdmurray> That's what I was doing too but being able to use collect and having it change the package would make sense to me
<Riddelll> pitti: the jockey-kde issue I wanted to investigate turned out to be that it doesn't show any drivers if you start it when there's no network
<Riddelll> which is confusing but not unreasonable
<pitti> Riddelll: oh the live system?
<pitti> Riddelll: it needs a package index from restricted
<Riddelll> pitti: installed
<pitti> ah, so it never apt-get update'd?
<Riddelll> right, and it didn't have that
<pitti> ah
<pitti> that's intended, yes
<pitti> we don't ship the drivers on CD any more
<Riddelll> and it's nothing frontend specific so I can relax :)
<pitti> so if they aren't on the CD source, you need network to get the packages
<pitti> *phew* :-)
<doko> asac: is the fixed xulrunner-1.9.1 in karmic?
<phreestyle-work> have a question...I don't even know if this is the right room to ask, so please point me in the right direction if this is the wrong room: I'm a Windows developer (C#) during the day, but I like Ubuntu and I find and report bugs on a regular basis, but the bugs almost never get fixed. I'd like to learn how to fix them myself. I'm learning Python and have already have a good handle on programming concepts, so is there a place I can get help for
<ccheney> phreestyle-work: well you need to know the language for the program you are trying to fix bugs for at minimum so you could probably help with c# or python related programs
<phreestyle-work> ccheney: any suggestions on python projects to contact?
<ccheney> phreestyle-work: to get the source to a package you can run apt-get source (foo) then to build you can use something like pbuilder or debuild
<ccheney> phreestyle-work: no, sorry i don't work on python stuff myself so don't know much about them
<phreestyle-work> ccheney: is there a page somewhere that details the process of getting the source and building + testing?
<ccheney> phreestyle-work: probably under development on this page: http://www.ubuntu.com/community/participate
<ccheney> phreestyle-work: which redirects here basically https://wiki.ubuntu.com/UbuntuDevelopment
<phreestyle-work> ccheney: yea, all it takes about is packaging
<ccheney> phreestyle-work: there is a section that tells what to do to build
<ccheney> phreestyle-work: testing is just running the program to see if it works, unless it happens to have unit tests, etc
<phreestyle-work> ccheney: ok, thanks...I'll try to find some more information about building and testing
<ccheney> you might have better luck asking someone on #ubuntu-motu
<phreestyle-work> ccheney: ok, thanks...I'll try there
<mdz> smoser, hi
<smoser> hi.
<mdz> smoser, I'm at linux plumbers and intermittently offline, but wanted to check in with you regarding the ec2-images bugs and see how things are going
<Turl> hello, can anyone set this bug some importance? https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/393008
<ubottu> Launchpad bug 393008 in gnome-power-manager "[Karmic] power management icon says laptop is connected to power when it isn't" [Undecided,Confirmed]
<smoser> making reasonable progress. i think i have bug 429169 and bug 423497 mostly done. i was working on bug 429106.
<ubottu> Launchpad bug 429169 in vm-builder "ec2: Include kernel modules in AMIs" [Medium,Triaged] https://launchpad.net/bugs/429169
<ubottu> Launchpad bug 423497 in vm-builder "Sudoers file is misconfigured in AMI ami-5059be39" [Medium,In progress] https://launchpad.net/bugs/423497
<ubottu> Launchpad bug 429106 in vm-builder "kernel and initramfs should be available for uec" [Medium,Triaged] https://launchpad.net/bugs/429106
<smoser> zul, has been poking at bug 431103 a bit.
<ubottu> Launchpad bug 431103 in ec2-init "ssh host key fingerprint no longer available in the console log" [High,Triaged] https://launchpad.net/bugs/431103
<smoser> that really just leaves bug 431255 as something i wanted to get done. and getting those all pulled together cleanly.
<ubottu> Launchpad bug 431255 in ec2-init "ec2-init: Move ec2-run-user-data to startup priority S99" [Medium,Confirmed] https://launchpad.net/bugs/431255
<mdz> smoser, I noticed that linux-ec2 wasn't in main yet; presumably that needs to be done as well in order to fix 429169?
<mdz> zul, how are the MIRs going?
<zul> mdz: like the rabbitmq ones they are done
<mdz> smoser, will you be pushing those fixes into Karmic today?
<mdz> zul, "done" in this case means the packages have been moved to main, and I don't think that's the case yet
<smoser> i'll get them all together, and ask soren to take a read. might try to get the changes into vmbuilder trunk and automated builds for tonights builds.
<zul> mdz: i seeded rabbitmq yesterday Im not sure whats going on with it
<zul> mdz: ill bug pitti about it
<mdz> zul, please find out.  I'm particularly interesetd in the ones on this list: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
<mdz> smoser, AIUI soren is out sick, and may not be back tomorrow if he doesn't feel better, so be careful not to block on him
<zul> mdz: ok
<smoser> regarding MIR that i filed, ec2-init had some comments on it. i responded to pitti out of bug. most of the comments were regarding rightscale-init. i think we might be able to ditch that script, i've had some discussion with the rightcsale folks today.
<dyek> Hi! I need to receive ALSA device (appearing/disappearing) notification in my app. The notification needs to be working on Ubuntu 9.04 Jaunty. The same executable also needs to be made to run on older distributions but the notification can be just studs. I read that libgudev/ GUdevClient is awesome, but any advice on the best way to be ready for the future, but be able to function on Jaunty and not prevented from running on older distributions?
<mbiebl> pitti: you might also remove the polkit-auth call from hal.postinst
<pitti> re
<pitti> mbiebl: right, good call
<pitti> zul: but me about what?
<pitti> oh, /query
<pitti> smoser: please feel free to respond in the bug, to keep a record of the discussion
<pitti> smoser: I'll follow up to your mail soon; sorry, bit crazy today
<smoser> pitti, so just forward my mail to you to the bug ?
<dyek> I read that libudev required root privilege, unless for the latest kernel. Was the root privilege required for netlink socket? What is the kernel version where root privilege was no longer required for libudev?
<smoser> i understand crazy
<pitti> smoser: didn't look at it yet, if it's okay to publish
<smoser> i just didn't want to confuse the bug. fairly long winded.
<smoser> i'll put it there.
<pitti> smoser: thanks; then it's easier to reply/quote, etc.
<mdke> pitti: stripping out the translated xml from ubuntu-docs has worked a treat, 450kb instead of 3.8mb after the latest upload. Thanks again for working on that
<seb128> mdke, hi, do you work on ubuntu-docs changes?
<mdke> seb128: yes
<seb128> mdke, do you think it would make sense to have the about ubuntu desktop file there?
<seb128> mdke, also do you know if somebody is working on updating gnome-user-docs?
<mdke> seb128: on the first one, I'm not sure I'm best placed to judge. My initial reaction would be that if you think it's a good idea, no problem here. How do translations work for that file? Would we need to import them manually?
<mdke> seb128: on the second one, it's bug 434434
<ubottu> Launchpad bug 434434 in gnome-user-docs "Update to 2.28.0" [Wishlist,New] https://launchpad.net/bugs/434434
<seb128> mdke, thanks
<seb128> mdke, we often get issues for about ubuntu like derivative having the item bug it's not working since the documentation is not there
<mdke> I saw that in xubuntu, but I assumed it's an issue with the xubuntu menu showing the item
<mdke> I don't know how panels work, really :(
<seb128> but right we would need to move translations or translators would need to catch up on it
<seb128> well the place where it is is not a standard one
<seb128> you can easily add things to categories but not there
<mdke> ideally there would be some way to get the string from the about-ubuntu document itself
<seb128> so we hardcode the desktop adding conditionally on the omf presence there
<seb128> but that's a gnome-panel change which means other menus might list it wrongly if they are not modified
<mdke> ok
<mdke> do you think this is something that we should consider for karmic? Or shall we try and spec it up for lucid?
<mdke> dunno if some consultation with derivatives is in order
<seb128> it should be easy enough to change
<seb128> I doubt it
<mdke> if there are no drawbacks then I'm sure derivatives will be ok with it
<seb128> ok
<seb128> I will have a look again and ping you back about that
<mdke> I'm just trying to think if there is any way to use the existing translation templates we use for the document
<mdke> it uses gettext/xml2po
<mdke> obviously it already contains the string "About Ubuntu" :)
<mdke> I don't really have a good understanding of gettext to figure that out though
<seb128> do you have a po dir and a POTFILES.in in ubunt-docs?
<mdke> we have a po dir for each document, but not POTFILES.in
<mdke> the packaging is quite simplistic, I think
<seb128> ok, I will have a look
<mdke> let me know if anything is confusing
<seb128> usually it's easy when you have a POTFILES.in but documentation is different
<mdke> it's kinda evolved over time so it might not be very coherent... but it works :)
* Chex changed the topic of #ubuntu-devel to: Karmic Alpha-6 released, please help find boot bugs | Archive: FeatureFreeze, UIFreeze | 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 | Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a
<mdke> seb128: it's in bzr in lp:ubuntu-docs btw
<seb128> mdke, ok, I will let you know if I take a look
<seb128> thanks for working on that and the gnome-user-docs update ;-)
<mdke> no problem - i still need to do it
* Chex changed the topic of #ubuntu-devel to: Karmic Alpha-6 released, please help find boot bugs | Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a code update | Archive: FeatureFreeze, UIFreeze | 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/Help
<smoser> slangasek, ping
<Kent> hi, im working on a install script for a program and would like to know a little about the folder structure, in arch i use this http://pastebin.ca/1577042 what is the equialent for ubuntu
<Darxus> Kent: I think you're looking for debian policy.
<Kent> Darxus: is it the same for all debian system
<Darxus> File system structure: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
<Darxus> Which points at:
<Darxus> http://www.pathname.com/fhs/pub/fhs-2.3.html
<Darxus> Kent: I believe so.
<Kent> Darxus Tnx
<Darxus> Kent: You're welcome.
<seb_kuzminsky> i'm trying to compile a subset of Hardy from source, then debootstrap the result
<seb_kuzminsky> it's working pretty well, but...
<seb_kuzminsky> i'm confused by Priorities
<seb_kuzminsky> anyone care about Hardy still?
<Darxus> Heh.
<seb_kuzminsky> in the official ubuntu repo, many binary packages have Priorities that differ from the Priorities of their source packages
<Darxus> I'm running hardy on my server.
<seb_kuzminsky> when i compile a source package (in a hardy pbuilder), the resulting .debs have Priorities that differ from the Priority of the official .debs
<seb_kuzminsky> for example, ubuntu-minimal.deb has "Priority: important" in the ubuntu.com repo
<Darxus> Hardy is the most recent LTS, so I would say people care about it.
<seb_kuzminsky> but the control file in the matching ubuntu-meta source package has "Priority: optional", and so do the .debs i build from it
<seb_kuzminsky> so debootstrap doesnt pull it in by default :-(
<seb_kuzminsky> what am i doing wrong?
<LaserJock> seb_kuzminsky: the archive administrators have a separate list of the priorities
<seb_kuzminsky> aha!
<LaserJock> seb_kuzminsky: which allows them to override the packages listed priority
<Darxus> Hardy still has another four years before EOL.
 * seb_kuzminsky pokes around the archive looking for the *real* priorities
<seb_kuzminsky> hm, where is this "higher-priority priority list" kept?
<cjwatson> it's in indices/ on any mirror
<cjwatson> override.hardy.main or some such, I forget the exact name
<seb_kuzminsky> oh right
<seb_kuzminsky> thanks
<Keybuk> slangasek: you didn't commit your util-linux changes ;-)
<slangasek> Keybuk: to lamont's git repo?  No, no I didn't :-P
<Keybuk> slangasek: or to the one on kernel.ubuntu.com :p
<Keybuk> and you didn't even send a git format-patch output
<Keybuk> tsk
<slangasek> which is not in the Vcs field
<Keybuk> (or writable by you :p)
<Keybuk> you could have branched it ;P
<porcofino> good evening
<porcofino> does any of you devs actively use bash?
<porcofino> I'm having issues with my ubuntu's bash
<ion> releasing version 0.1.8
<slangasek> Keybuk: pass
<ion> Without merging my branch? :-P
<porcofino> it doesn't recognize let expressions
 * lamont tsks at slangasek 
<slangasek> lamont: put it in bzr, then I'll be happy to branch it :)
<cjwatson> porcofino: I think it's safe to say pretty much every developer actively uses bash to some extent, though personally I never use let expressions since they're bash-specific
<cjwatson> porcofino: what exactly is failing?
<lamont> slangasek: sure.  once upstream does
 * lamont is reminded today just how much work debian-installer does
<porcofino> cjwatson: it doesn't recognize let expressions
<porcofino> I'll post a pastebin link in a moment
<cjwatson> porcofino: I bet you have #! /bin/sh at the top of your script
<porcofino> cjwatson... yes!
<cjwatson> porcofino: #! /bin/sh means "run this script using some POSIX-compatible shell"
<lamont> porcofino: and that is now /bin/dash, not /bin/bash
<porcofino> wth
<cjwatson> porcofino: if you want to use bash-specific features, you'd better say #! /bin/bash
<porcofino> 0_o?
<slangasek> lamont: better get cracking on converting them!
<cjwatson> https://wiki.ubuntu.com/DashAsBinSh
<porcofino> cjwatson: how do I check what my current sheel?
<pochu> ls -l /bin/sh
<cjwatson> porcofino: just declare bash if you're using it
<cjwatson> porcofino: it's good practice anyway
<lamont> slangasek: I'm pretty sure upstream is under company edict to use git, though... could be rough
<lamont> postfix: fatal: could not find any active network interfaces <-- meh
<porcofino> cjwatson: god. so If I want to use bash, I have to declare explicitly that I want to use that?
<cjwatson> yes, of course
<cjwatson> this is perfectly reasonable
<porcofino> crap :P
<porcofino> #! /bin/bash , then?
<cjwatson> yep
<cjwatson> of course you can usually replace let by portable constructs that also work in smaller, faster shells; there's an example in the wiki page
<cjwatson> whether you want to bother is up to you
<porcofino> cjwatson: we're learning bash at school
<porcofino> so I guess I have to force it :P
<cjwatson> if you like you can tell your teacher that I write shell scripts professionally most days of my working life and have never once used let ;-)
<cjwatson> (note: this may not actually be good for your academic career)
<porcofino> cjwatson: we're more into... java.
<cjwatson> anyway, if your school is saying that bash scripts should start with #! /bin/sh, it's definitely wrong
<cjwatson> there are lots of systems in the wild other than Ubuntu where that will fail
<porcofino> cjwatson: I could also follow what says in that guide and use stuff that are common for all the shells
<rgs__> guys can the .cache directory be (safely) removed?
<porcofino> cjwatson: thanks mate!
#ubuntu-devel 2009-09-24
<NoReflex> Hello guys! I'm looking for some information on how I could compile a source to be installed just as a version from ubuntu's repo. If I compile it using the default options it will use other folders for binaries, libraries and won't make menu shortcuts
<ion> #ubuntu-motu should help with packaging.
<NoReflex> ok
<NoReflex> will try, thanks
<lamont> http://www.klikradio.org/listen.asx <-- the 17 yr old highschooler daughter is live on the air.  She even sometimes plays songs I like
<ion> The radio compression is painful.
* Chex changed the topic of #ubuntu-devel to: Karmic Alpha-6 released, please help find boot bugs | Launchpad will be down/in read-only from 22:00 UTC until 24:00 UTC for a code update | Archive: FeatureFreeze, UIFreeze | 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/Help
<mdz> smoser, around?
<smoser> here
<smoser> but i might have to go at a moments notice.
<mdz> smoser, just wanted to show you this
<mdz> smoser, I hacked up a first cut of the apport patch for ec2
<mdz> https://bugs.staging.launchpad.net/ubuntu/+source/coreutils/+bug/433845
<ubottu> Error: This bug is private
<mdz> (no it isn't)
<mdz> smoser, is there any other information which might be useful to add for bug reports from ec2 instances?
<smoser> everything in the metadata service is useful.
<smoser> with the possible explicit exception of ignoring user-data
<smoser> (for privacy reasons)
<mdz> smoser, is any of it potentially privacy-sensitive?
<smoser> i can go through and get a list of what might be private and what not
<smoser> at very least, things in there we'd want are image/ramdisk/kernel id
<smoser> zone
<smoser> stuff like that
<mdz> smoser, I'm already getting image/ramdisk/kernel, I can get zone
<mdz> smoser, thanks for the feedback
* Chex changed the topic of #ubuntu-devel to: Karmic Alpha-6 released, please help find boot bugs | Archive: FeatureFreeze, UIFreeze | 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
<Kano> hi, i tested current daily live 64 bit, then i installed htop on my quad core
<Kano> and one cpu is permanently at 100%
<Kano> X needs it, Intel onboard Q45 btw
<Kano> thats definitely not normal
<Kano> booted with toram option via network, but should not matter
<smoser> mdz, sorry for being dense before. i didn't realize what i was looking at. i thought you were pointing me at code that did the collection, and i couldn't find where it was.
<Kano> just tested it on nvidia hardware, same problem, one core running wild of 4
<Kano> also vts are blocked why on earth would somebody do that
<LaserJock> Kano: what do you mean by blocked?
<Kano> ctrl-alt+f1 or chvt 1 does not work
<Kano> btw. when i install nvidia binary drivers in live mode then cpu usage is 1%
<LaserJock> my guess is the vts are just dead
<LaserJock> which seems to happen not very infrequently when X crashes or is not working properly, in my experience
<Kano> on 2 testsystems with different hardware?
<LaserJock> in terms of not getting to the vts I wouldn't be surprised
<mdz> smoser, I hadn't noticed you being dense :-)
<LaserJock> I rarely had working vts for a few releases, although Jaunty and Karmic seemed to do good for me
<mason> Enter text here...hello
<mdz> smoser, now that you saw it for what it was, do you have further thoughts on how we could make it more useful?
<mason> ok i m having troubles with grub
 * LaserJock stabs apport for freezing up his laptop
<hyperair> is there a way to force redetection of headphone jack status?
<TheMuso> hyperair: unless there is a mixer control for it, not that I know of.
<hyperair> hmm
<hyperair> my headphone jack is acting strangely when resuming from suspend
<hyperair> as in, my speakers won't mute unless i plug in headphones pull them out and plug them back in
<hyperair> and if i leave my headphones in before suspending, and pull them out before resuming, the speakers remain muted
<hyperair> i'd like to write a pm-utils script for it
<TheMuso> hyperair: I think that problem needs solving at the kernel level.
<hyperair> ah damn =\
<hyperair> i should go file a bug then
<TheMuso> argh! gnome-terminal constantly segfaults, yes bug filing has been done.
<pitti> Good morning
<pitti> mdz: ah, great
<\sh> good morning pitti :)
<pitti> mdke: I just don't know whether we'll get another full langpack export until beta, so that people actually have translated docs; but we will definitively coordinate this for the RC/final
<pitti> ArneGoetje: do you still plan new langpacks between now and Monday?
<StevenK> Hey pitti!
<pitti> hey \sh
<pitti> hey StevenK!
 * \sh had a nice accident yesterday release-upgrading from a fresh jaunty install to yesterdays karmic .. after do-release-upgrade -d and reboot the machine couldn't find any kernel anymore...
<\sh> I wonder if it's a machine problem (ibm thinkpad t43 with a new HD) or if something happend during upgrade
<ArneGoetje> pitti: one update today, and one on sunday... according to crontab... but if it's not wanted, we can drop those
<\sh> looks like that I have to re-test this way this evening again
<pitti> ArneGoetje: oh, that's fine; I actually meant a full export
<pitti> ArneGoetje: so that the delta packs get empty, and we don't overflow CDs
<pitti> ArneGoetje: actually, hang on
<ArneGoetje> pitti: I can make one on Sunday
<pitti> ArneGoetje: can we skip the one on Sunday
<ArneGoetje> pitti: ?
<pitti> ArneGoetje: ok, full one on Sunday is possible? that would be good
<pitti> ArneGoetje: didn't finish typing my original thought yet :)
<ArneGoetje> pitti: yes, because I juse produced full ones last Sunday
<ArneGoetje> just
<pitti> ArneGoetje: the alternative would be to skip the sunday one and fake a full export today by merging the last full and current delta tarball before building packs
<cjwatson> how long will the export on Sunday take?
<ArneGoetje> cjwatson: let me check
<ArneGoetje> cjwatson: the LP export starts at 21:00 UTC on Saturday and takes 9 hours
<cjwatson> ok
<pitti> hm, that means we could build final CDs only on Tuesday morning
<pitti> sounds doable, but we shoulnd't build them much later
<ArneGoetje> cjwatson: means, it will be available around Sunday 6:00 UTC. I can then kick of the lp-o-matic run, which takes about 4 hours
<pitti> well, if some langpacks aren't built yet, it's not a catastrophe
<mdke> pitti: I haven't imported any translations from rosetta yet for ubuntu-docs, the translations included are still those from Jaunty. I tend to import translations after translation freeze because it takes quite a long time to do it and fix the various errors
<dholbach> good morning
<ArneGoetje> cjwatson, pitti: BTW: when to you want to have the final langpacks ready?
<pitti> three days before RC would be great
<ArneGoetje> pitti: date?
<pitti> ArneGoetje: October 19
<pitti> I'm not sure whether we should do another one for final (we used to in previous releases sometimes), but I'm inclined not to
<ArneGoetje> pitti: ok, that means the export on 17/18 would be too late?
<mdke> the LanguagePackTranslationDeadline is October 22
<pitti> mdke: for that we'd need an upload after RC, since the RC is due on October 22
<mdke> so translators will think (unless corrected) that their translations up until that date will be included in Ubuntu
<pitti> mdke: I'm not firmly opposed to do another upload after RC
<mdke> pitti: yeah, I'm not saying that the deadline is appropriate, just that this is how it is at the moment
<pitti> ArneGoetje: can we move that a day earlier?
<ArneGoetje> pitti: the export? need to ask the rosetta team to kick off a manual export
<pitti> right, the export and the build; so export on oct 16/17, upload on 17, build finishes until oct 19
<ArneGoetje> pitti: then we can also make the export on 14/15 the final one...
<ArneGoetje> pitti: when is release day? 29?
<pitti> ArneGoetje: yes
<pitti> ArneGoetje: I think we should at least do another full export on Oct 22
<pitti> (on the deadline)
<pitti> so that we have the possiblity of another update post-RC for final
<pitti> we can still not upload it if the situation doesn't allow us to for some reason, but at least we'll be prepared
<ArneGoetje> pitti: ok, according to LP cron schedule we have the foolowing export dates: 14, 17, 21, 24 before release. which ones to take and which ones to skip?
<pitti> ArneGoetje: that's for deltas, right?
<ArneGoetje> pitti: that's for full or deltas, depending on how I request it to be
<mdke> pitti: probably a good idea to let the translators know the plan so that they don't get bitten if there is no post-RC upload
<pitti> ArneGoetje: I'd skip them all, and request a manual full export on 16 and 22
<pitti> mdke: *nod*
<ArneGoetje> mdke: that's why we are discussing this now. ;)
<ArneGoetje> pitti: ok, so the last one according to schedule would be on 10. Then two manual ones on 16 and 22.
<mdke> ArneGoetje: ok
<mdke> pitti: how does the xml export work? Is there a date I need to have the ubuntu-docs translations uploaded by to ensure that they are shipped?
<pitti> ArneGoetje: sounds like a plan
<pitti> mdke: xml export?
<pitti> mdke: for being caught by the Oct 22 export, I think you need to have it uploaded by Oct 19 or so, to give LP some spare time for importing them all
<pitti> ArneGoetje: ^ sounds sane?
<ArneGoetje> pitti: ok, I will announce this to the translators
<mdke> pitti: the thing where xml from /usr/share/gnome/help is moved from ubuntu-docs to langpacks
<mdke> obviously when I upload ubuntu-docs, it gets stripped out during the build, and then where does it go back in?
<ArneGoetje> pitti: yes, I guess so
<pitti> mdke: oh, ignore me for the import
<pitti> it's not really "imported"
<pitti> mdke: langpack-o-matic grabs the stripped files produced on build, and merges them into the langpacks
<mdke> right, I didn't use the right word there I guess
<pitti> mdke: no, I was just confused; I thought it used po files
 * pitti still needs to wake up
<mdke> me too :)
<mdke> so the langpack-o-matic trick happens on every upload of an affected package?
<pitti> mdke: so, from a pure import POV, it needs to be built a about two hours before I start langpack-o-matic
<mdke> aha
<pitti> still needs to be earlier due to RC freeze and CD building, of course
<pitti> mdke: so I think "oct 19" still stands
<mdke> ok. that sounds ok, we have the translation deadline on Oct 15 so I can do it over that weekend
<mdke> thanks pitti
<pitti> great
<ArneGoetje> pitti: have you seen my post to ubuntu-devel mailing list?
<pitti> ArneGoetje: yes, I did, will followup today
<mdke> pitti: on my jaunty system the help button for jockey is broken because it points at "ghelp:hardware#restricted-manager" instead of "ghelp:hardware#jockey" (fixed in karmic). Have you had many bug reports about that? if not I presume it's not worth an SRU?
<pitti> tseliot: is screen-resolutions-extra still required? We don't need to set VirtualSize any more, and dontzap has gone from xorg.conf as well, no?
<pitti> tseliot: it's one of the last two packages which still uses the old policykit API (without depending on it, so it won't even work)
<tseliot> pitti: screen-resolutions-extra is still required for -ati (which AFAIK doesn't have dynamic front buffer reallocation)
<tseliot> dontzap (the package) was removed from the archive
<pitti> tseliot: does it check that it doesn't fiddle xorg.conf for intel?
<pitti> tseliot: s-r-e also has dontzap code AFAICS
<pitti> ah, it calls /usr/bin/dontzap
<tseliot> pitti: yes, it has dontzap code but doesn't use it
<pitti> tseliot: ok, so I file a bug for getting it ported to polkit-1 (and the missing dependencies)
<tseliot> pitti: and no, it won't be used for intel cards as the framebuffer size should be bug enough now that -intel uses UXA
<pitti> tseliot: I know; I wondered whether that's actually checked somewhere
<robert_ancell> Does anyone know how to run a panel applet in the foreground? Or look at it's stdout/stderr?
<seb128> robert_ancell, run it on a command line before adding it to gnome-panel
<seb128> robert_ancell, it will sit there until added and the adding will use the running instance
<tseliot> pitti: the gnome randr applet checks the framebuffer size and calls s-r-e if necessary
<pitti> ah, I see
<pitti> thanks
<tseliot> pitti: I'll file a bug report about polkit-1
<pitti> you? ok, thanks
<tseliot> in s-r-e
<robert_ancell> seb128, I did that for gnome-pilot but gdm-user-switch-applet quits immediately
<pitti> tseliot: https://wiki.ubuntu.com/DesktopTeam/PolicyKitOneMigration has some links to API and porting guide
<tseliot> pitti: aah, you said you would do it. Sorry, I misread your message
<tseliot> pitti: please do it and I'll have a look at it later
<pitti> tseliot: *nod*
<seb128> robert_ancell, do you already have the applet on the panel?
<robert_ancell> seb128, no
<seb128> robert_ancell, running /usr/lib/gdm/gdm-user-switch-applet sits on a command line waiting there
<seb128> $ /usr/lib/gdm/gdm-user-switch-applet
<seb128> ** (gdm-user-switch-applet:3979): DEBUG: GdmUserManager: Found current seat: /org/freedesktop/ConsoleKit/Seat1
<seb128> ** (gdm-user-switch-applet:3979): DEBUG: Creating new user
<seb128> etc
<seb128> when adding the applet to the gnome-panel config
<seb128> robert_ancell, you are sure there is no gdm-user-switch-applet already running?
<robert_ancell> seb128, ah, thanks. It must be my local build that is quitting early
<seb128> robert_ancell, does it work for the system one?
<robert_ancell> seb128, yes, thanks
<seb128> you're welcome
<seb128> robert_ancell, note that we don't use this applet in ubuntu
<seb128> robert_ancell, btw do you know why gdm lists the sabayon user on the login banner?
<robert_ancell> seb128, yeah, but I need to patch all of GDM for them to accept the UserManager patch.  This is the easiest bit to fix first
<ArneGoetje> mvo, cjwatson: could you please take a look at my post on ubuntu-devel@ ("Getting translation packages installed automagically") and follow up? Thanks a lot.
<robert_ancell> seb128, what uid is sabayon?
<seb128> robert_ancell, > 1000 I guess it's a sabayon bug
<robert_ancell> seb128, if the UID is greater than 500 and it has a valid shell it gets shown.  There is a blacklist of ~20 users that are filtered out (e.g. mysql)
<robert_ancell> seb128, the good news is the blacklist is now a gconf key so much easier to fix these sorts of problems
<seb128> ok, thanks
<pitti> tseliot: done, bug 435709
<ubottu> Launchpad bug 435709 in screen-resolution-extra "Needs porting to policykit-1" [Undecided,New] https://launchpad.net/bugs/435709
<tseliot> pitti: thanks
<pitti> tseliot: do you think you'll have time for this after beta?
<pitti> tseliot: if not, please tell me, and I'll try to make some time for it
<seb128> robert_ancell, do you plan to land gdm changes before your end of day?
<mvo> ArneGoetje: thanks, I just read over it, I think we can do something in u-m for karmic, but not add support to software-store at this point
<seb128> robert_ancell, did you put the failsafe session part there too?
<tseliot> pitti: I doubt I will. There's a new mesa, a new intel driver and some other X stuff that need my attention
<pitti> tseliot: ok, keeping on my radar then
<tseliot> pitti: thanks
<mvo> ArneGoetje: did the language-pack names change, i.e. if someone has a full translated jaunty and does a dist-upgrade, will he miss some translations this way in karmic?
<robert_ancell> seb128, no changes today
<seb128> robert_ancell, ok, not even the failsafe gdm counterpart? ;-)
<seb128> robert_ancell, I will test the patch on the bug then and see if I can get that uploaded before the freeze
<robert_ancell> seb128, Amaranth has done all the work. I just updated one patch to the current version
<seb128> robert_ancell, right I was checking in case you had a bzr ready to upload for this one like gnome-session
<robert_ancell> seb128, ok.  Nope, I'm winding up now so don't have anything pending
<seb128> ok, good
<seb128> thanks robert_ancell
<ArneGoetje> mvo: no. the language-pack names stayed. it's just that language-support-translations and language-support-extra metapackages went away. Those dependencies are now installed by language selector (and can be checked with the script I mentioned), based on which applications (thunderbird, oo.o, etc.) the user has already installed or is going to install
<seb128> cjwatson_, hi
<seb128> cjwatson_, about bug #434769
<ubottu> Launchpad bug 434769 in gdm "Login Prompt on Live CD Text Mode" [Undecided,New] https://launchpad.net/bugs/434769
<ArneGoetje> mvo: so, an update will most likely remove those extra translations from the system, since the metapackages are gone which pulled them.
<seb128> cjwatson_, /etc/init/gdm.conf has logic for the text argument, isn't that enough?
<seb128> "    for ARG in $(cat /proc/cmdline)
<seb128>     do
<seb128>         case "${ARG}" in
<seb128>             text|-s|s|S|single)
<seb128>                 exit 0
<seb128> "
<mvo> ArneGoetje: urgh, ok. that is definitely something we need to add to the release notes (if it has not been added already)
<dpm> ArneGoetje: I've just read your e-mail as well, I'll forward it to ubuntu-translators, since they might be interested (especially Timo Jyrinki, who started the related discussion)
<seb128> cjwatson_, oh, the change has been uploaded later that I though the cd images probably didn't have it yet
<mvo> ArneGoetje: I do a test run with the upgraer now, it has some cleverness when it comes to translations already, I check if it keeps its hands off them or if it needs extra tweaking
<ArneGoetje> mvo: ok. Please also have a look at my branch and commit it, so that we have the script ready to be used. :)
<mvo> ArneGoetje: I put it on my todo list
<ArneGoetje> mvo: thanks
<ArneGoetje> mvo: FYI a script run on my machine with multiple language-packs installed takes about 4 seconds to run and produces accurate output in terms of missing packages.
<asac> doko_: checkout http://paste.ubuntu.com/276885/ ... feel free to suggest a fix in xulrunner. the other instruction thing is supposed to be fixed.
<asac> doko_: also i tried -O2 on powerpc
<asac> doesnt help much ... posted the error in the bug. seems a assembler regression somewhere
<asac> doko_: patches welcome :-P (435560 has the new assembler problem when building with -O2)
<doko_> ohh joy
<doko_> asac: but the powerpc package currently is installable ... so it would help to upload to get an installable one on sparc
<doko_> hmm, this is the sparc build ...
<asac> doko_: i worked around the solaris symbol for nanojut by disabling "jit" ... but it doesnt work either. .. seems like gcc header bug on sparc: http://paste.ubuntu.com/276891/
<asac> yes
<doko_> asac: no, xulrunner is soooooooo wrong, redefining 'inline'
<doko_> namespace std
<doko_> {
<doko_>   inline namespace __gnu_cxx_ldbl128 { }
<doko_> }
<asac> doko_: redefining inline?
<asac> doko_: thats from the /usr/include/c++/4.4/sparc-linux-gnu/bits/c++config.h:214: error: expected unqualified-id before 'namespace'
<doko_> asac: yes, please look at the preprocessed source
<asac> doko_: did you already look at the preprocessed source or are you speculating that its a xulrunner bug just on sparc?
<doko_> asac: *you* speculate that it is a sparc bug, but apparently it only happens when including xulrunner's headers
<asac> doko_: look on faure in /tmp/ns*.ii
<asac> /tmp/nsWifiScannerUnix.ii
<asac> doko_: ^^
<doko_> asac: yes, as I said: this is expanded to:
<doko_> # 212 "/usr/include/c++/4.4/sparc-linux-gnu/bits/c++config.h" 3
<doko_> namespace std
<doko_> {
<doko_>   inline __attribute__((always_inline)) namespace __gnu_cxx_ldbl128 { }
<doko_> }
<doko_> asac: maybe try to reproduce on x86 with -D_GLIBCXX_LONG_DOUBLE_COMPAT -D__LONG_DOUBLE_128__
<hoerup> has anybody experienced a breakage in karmic netwrok inst
<hoerup> i tried last night and again this morning (CEST timezone), but base installation fails
<mvo> ArneGoetje: I just checked, u-m will not auto-remove the translations on upgrade, it shoud still mark them manual instlal I think, so we should add a quirk to u-m (and add it to the release notes)
 * ogra hopes the new usplash artwork was tested on 16pbb displays and doesnt look as awful as xsplash
<sebner> pitti: aren't you afraid that you'll need to blacklist more and more stuff? ^^
<pitti> sebner: well, there's just one left now :)
<pitti> it only supports four jmicron bridges
<sebner> heh, lucky you
<dpm> mvo: could you have a look at bug 378075 when you've got some time? There is a patch for it as well
<ubottu> Launchpad bug 378075 in ddtp-ubuntu "Typos in package summaries" [High,Fix committed] https://launchpad.net/bugs/378075
<mvo> dpm: that is for jaunty? or karmic?
<mvo> dpm: nevermind
<dpm> yep, jaunty :)
<james_w> is there supposed to be an upstart "reload" command?
<james_w> ah, mterry is already on it :-)
<doko> asac: filed bug #435793
<ubottu> Launchpad bug 435793 in xulrunner-1.9.1 "redefinition of 'inline namespace' in installed headers" [High,New] https://launchpad.net/bugs/435793
<asac> doko: do you see the "definition" in th .ii file?
<asac> both definitions only refer to the linux headers
<asac> shouldnt .ii files give hints where the defines used for expansion come from?
 * asac logs on faure again
<doko> asac: you me want to run -E -dD
<asac> doko: are those compiler flags?
<doko> asac: yes, see gcc(1)
<asac> ok one sec
<asac> somewhat that doesnt dump anything to stdout
<doko> asac: for powerpc, there's now a gcc patch fixing wrong code gen with -Os -fstack-protector. will ask slangasek for a freeze exception (432222)
<asac> which is what i understand it should do on -E
<asac> doko: great. any idea about the assembler parsing (?) bug?
<asac> doko: -E -dD doesnt spit out anything (no clue) ... is -save-temps with -dD doing the same?
<asac> if so i put it to /tmp/nsWifiScannerUnix.ii.dD now
<asac> but doesnt show any xulrunner headers surrounding that inline thing
<asac> so i assume that flag didnt work :/
<doko> asac: have a look at the other -d* options
<asac> dont see anything that would show more headers in the .ii
<doko> asac: -dM ?
<asac> doesnt work with g++
<doko> asac: powerpc assembler: again, the preprocessed source would help
<asac> doko: i can get that
<asac> doko: would be precious if you can tell me exactly the command i should run to get _all_ include/expand info into the ii ... the command (with -save-temps) is here: http://paste.ubuntu.com/276972/plain/
<doko> asac: working dir?
<doko> asac: run the preprocessor only
<hoerup> karmic network inst: debootstrap program exited with error 127
<asac> doko: on davis: xptcstubs_ppc64_linux.ii
<asac> in my home
<asac> the compile rerror is in the bug
<asac> also put the original .cpp file there so you can directly fix it if its an official real assembler syntax you understand
<doko> asac: same command line as in the bug report?
<Whoopie> pitti: Hi, you know that you broke tuxonice-userui package with latest usplash-theme-ubuntu change? ;)
<asac> doko: yes if oyu want to be sure i can paste you the command
<pitti> Whoopie: uh?
<asac> doko: http://paste.ubuntu.com/276978/plain/ thats the command line (with -save-temps)
<doko> asac: attaching the files to the bug report would help
<asac> doko: cant i just tell g++ to just run preprocessor rather than tweaking that command line until cpp is happy?
<doko> asac: there's no nsWifiScannerUnix.cpp in your home
<asac> doko: well. you are here ... i am here
<Whoopie> pitti: tuxoniceui_usplash uses the progressbar functions to draw a progressbar during hibernate?
<Whoopie> pitti: s/?/.
<asac> doko: if you say you cannot find it i will attach them
<cjwatson> hoerup: need full logs
<pitti> Whoopie: how does that break hibernation, though?
<Whoopie> pitti: no, the progressbar is not shown anymore.
<pitti> right
<asac> doko: i talked about powerpc ...
<pitti> the new theme doesn't have a progress bar, by design team
<Whoopie> pitti: that's one benefit of tuxonice instead of vanilla-hibernate.
<asac> doko: now it is on faure
<Kano> hi, does anybody else have got 100% load on Xorg with (h)top?
<Kano> at least with nv driver (not nvidia binary) with daily iso
<doko> asac: nsWifiScannerUnix.cpp:44:23: error: nsAutoPtr.h: No such file or directory
<doko> nsWifiScannerUnix.cpp:45:27: error: nsWifiMonitor.h: No such file or directory
<doko> nsWifiScannerUnix.cpp:46:31: error: nsWifiAccessPoint.h: No such file or directory
<asac> doko: are you in karmic chroot?
<doko> I don't want the files in your home, but just know the *working directory* (pwd) for calling the compiler
<doko> yes
<asac> doko: sure isnt that even in the paste?
<asac> one second
<asac> on powerpc its: ~/build-area/xulrunner-1.9.1-1.9.1.3+build1+nobinonly/build-tree/mozilla/xpcom/reflect/xptcall/src/md/unix
<doko> no
<doko> thanks
<asac> alls builddeps are installed in karmic chroot
<asac> doko: the hot spot on sparc is in: ~/build/build-area/xulrunner-1.9.1-1.9.1.3+build1+nobinonly/build-tree/mozilla/netwerk/wifi/src
<doko> asac: there is no ~asac/build-area on faure
<doko> ahh
<asac> doko: faure == sparc ... davis == powerpc ;)
<asac> maybe we should focus on one issue to avoid confusion ;)
<cjwatson> hoerup: (ideally, the installer syslog)
<hoerup> cjwatson: already working on it
<doko> asac: it does work. just use -E -dD as I suggested. so it looks to be a problem in iwlib:
<asac> doko: cool ... can you paste the full -E -dD command you used so i can "learn"
<doko> # 72 "/usr/include/iwlib.h" 3 4
<doko> #undef IW_GCC_HAS_BROKEN_INLINE
<doko> # 83 "/usr/include/iwlib.h" 3 4
<doko> #define IW_GCC_HAS_BROKEN_INLINE 1
<doko> #define inline inline __attribute__((always_inline))
<doko> g++ -E -dD -fvisibility=hidden -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -DIMPL_NS_NET  -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include   -I../../../dist/incl
<doko> ude/necko -I/usr/include/nspr   -I/usr/include -I/home/asac/build/build-area/xulrunner-1.9.1-1.9.1.3+build1+nobinonly/build-tree/mozilla/dist/sdk/include    -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno
<doko> -reorder-functions    -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsWifiScannerUnix.cpp -save-temps
<asac> ok makes sense ... didnt find any redefinition of inline in xul code
<asac> odd ... i used the same approach (just putting to the front)
<asac> IW_GCC_HAS_BROKEN_INLINE ... let me check
<asac> doko: http://paste.ubuntu.com/276994/
<asac>  /* However, gcc 4.0 has introduce a new "feature", when compiling with * '-Os', it does not want to inline iw_ether_cmp() and friends. * So, we need to fix inline again !
<doko> gah ...
<doko>  * I really hate when the compiler is trying to be more clever than me,
<doko>  * because in this case gcc is not able to figure out functions with a
<doko>  * single call site, so not only I have to tag those functions inline
<doko>  * by hand, but then it refuse to inline them properly.
<doko>  * Total saving for iwevent : 150B = 0.7%.
<doko>  * Fortunately, in gcc 3.4, they now automatically inline static functions
<doko>  * with a single call site. Hurrah !
<doko>  * Jean II */
<doko> when people try to be more clever than a compiler
<cjwatson> obviously 150 bytes is more valuable than several man-hours of time several years later trying to figure out what on earth is wrong :P
<asac> 0.7% ;)
<cjwatson> hoerup: could just be the bug fixed in debootstrap 1.0.18 which I just synced, of course ...
<cjwatson>    * Only use dpkg from the chroot, as there is no guarantee dpkg is
<cjwatson>      available outside of the chroot (d-i installation for example).
<cjwatson> (which was my muppet error)
<hoerup> ok
 * asac off for a while doing some NM testing
<hoerup> cjwatson: last line from syslog "dpkg: not found"
<Laney> Does anyone know if it's possible to migrate normal users to be system users on a package upgrade?
 * Laney is touting this question around
<cjwatson> hoerup: right. that's fixed in debootstrap 1.0.18 which you should get shortly. Sorry about that
<directhex> Laney, "system users"?
<Laney> directhex: --system
<Laney> chooses a different uid, doesn't make a home directory and other things
<pitti> hm, since upstart is required now, sysvinit can't ever be installable; should we just drop it?
<pitti> cjwatson_: ^ opinion?
<pitti> it keeps nagging us in the uninstallable report
<pitti> Riddell: khelpcenter got demoted to universe in jaunty, but now koffice-data reverse-recommends it and wants to pull it back; promote or fix dependency?
<pitti> soren:
<pitti>  o kvm: kvm
<pitti>    [Reverse-Depends: Ubuntu.Karmic virt-host seed]
<pitti> sommer: I think some seed needs to be fixed to qemu-kvm?
<doko> asac: independently of build the file on ppc with -O2 or -Os, I always get these errors
<asac> yes
<doko> asac: is it correct that the file name has an `ppc64' in it?
<asac> i didnt say that assembler is Os
<doko> and not just ppc?
<asac> i wondered about that too, but uname -a showed 64-bit at least
<asac> 2.6.15-54-powerpc64-smp
<doko> asac: please rebuild, prefixing the build with linux32 ...
<doko> opening an rt ticket ...
<asac> doko: so our ppc isnt 64-bit?
<asac> ok
<asac> let me try
<asac> ok build is running with linux32
<cjwatson_> pitti: inclined to leave such decisions to Keybuk
<cjwatson_> pitti: we clearly can't drop the whole source package
<squirrelpimp> hi. If i prepend a command in a desktop-starter with ~ (e.g. ~/path/binary) to indicate it's in my home-folder, then the starter opens in a text-editor on double-click instead of launching the application
<squirrelpimp> this happens on xfce, but i'm not sure which package to file the bug against
<cjwatson> ~ is only parsed by certain things; try /home/yourusername/...
<squirrelpimp> removing the ~ fixes it of course, but still it shouldn't open as a textfile
<squirrelpimp> wouldn't it be intuitive to support ~ there as well?
<cjwatson> technically you can really only assume that ~ is parsed by shells that do tilde expansion
<cjwatson> I'm sure it would be *nice* to have it handled elsewhere but do be clear that it's only a wishlist bug
<squirrelpimp> ok, i accept that
<squirrelpimp> would it be of any benefit to file it? against what package? xubuntu-desktop?
<cjwatson> I don't know what package, though; don't know XFCE
<pitti> cjwatson: no, just the binary; ok, will ignore for now
<pitti> sommer: sorry, that was supposed to go to soren
<asac> doko: looks good so far. at least it built the 32-bit stub successfully now ... once the build finishes i will upload with sparc and powerpc fixes. not sure what to do with iwlib ... maybe just drop the whole define business (just on sparc?)?
<doko> asac: already uploaded
<asac> doko: did you drop it completely?
<doko> asac: no, see https://edge.launchpad.net/ubuntu/+archive/primary/+files/wireless-tools_29-2ubuntu4_29-2ubuntu5.diff.gz
<doko> hmm, diff not yet in lp
<unhappyaron> could somebody have a look at this: https://bugs.edge.launchpad.net/ubuntu/+source/ibus-pinyin/+bug/431823
<ubottu> Launchpad bug 431823 in ibus-table-wubi "the dependent packages are too large" [Undecided,Confirmed]
<asac> ok will check in a few minutes what you did :-P
<asac> doko: ok fails the same way on ppc now: http://paste.ubuntu.com/277032/
<asac> i assume its the same at least
<doko> yep
<soren> pitti: Huh?
<soren> pitti: Oh.
 * hyperair notes that ibus appears to hang urxvt
<asac> doko: pushed /me crosses fingers
<unhappyaron> hyperair: you could talk with lidaobing, he sumbitted the fix on the bug
<hyperair> ooh is that so?
<hyperair> that's cool
<lidaobing> hyperair, hi
<doko> asac: with a b-d on the new libiw-dev?
<asac> doko: yes. but only on sparc/powerpc because we daily buld from that branch on old releases ... i hope i got it right
<asac> otherwise ... retry ;)
<asac> oh darn ;)
<asac> i uploaded from wrong bzr branch ... moving the powerpc hacks further down
<lidaobing> unhappyaron, I have no problem when I use ibus and urxvt
<unhappyaron> lidaobing: it's hyperair said that "notes that ibus appears to hang urxvt", :)
<unhappyaron> lidaobing: asac said he would have a look at that bug, that is what you need a sponser
<hyperair> lidaobing: it happens with irssi in byobu, and holding down alt-`
<hyperair> where alt-` is active_window
<asac> ok reupped xul
<asac> unhappyaron: ?
<asac> id?
<unhappyaron> asac: https://bugs.edge.launchpad.net/ubuntu/+source/ibus-pinyin/+bug/431823
<ubottu> Launchpad bug 431823 in ibus-table-wubi "the dependent packages are too large" [Undecided,Confirmed]
<asac> thx
<Riddelll> pitti: I'll fix the khelpcentre dependency
<lidb> hyperair: I am lidaobing, and I still can't reproduce your bug
<unhappyaron> asac: if there is any problem, talk to lidb, :)
<hyperair> need enough active channels =\
<lidb> unhappyaron:test Chinese, æµè¯ä¸­æ
<unhappyaron> lidb: no problem
<asac> unhappyaron: that bug is marked fix released
<asac> plesae update me
<asac> (what issues are left)
<unhappyaron> asac: need some to have an upload to main
<lidaobing> hyperair, sorry, can
<lidaobing> hyperair, sorry, can't reproduce your bug
<asac> unhappyaron: what package needs to be updated? and why?
<unhappyaron> asac: ibus-pinyin, ibus-wubi-table
<asac> why is that still needed?
<asac> we dropped the overly strong depends
<asac> so it should be fine without using lzma compression
<lidaobing> unhappyaron, these two packages still have bugs, I'll fix soon
<unhappyaron> lidaobing: okay
<lidaobing> unhappyaron, leak version depends on dpkg
<unhappyaron> lidaobing: so, okay
<unhappyaron> asac: but using lzma there will have a 15M decrease on size
<hyperair> lidaobing: nevermind. i can't reproduce it most of the time anyway
<asac> unhappyaron: but it comes with performance decrease ... not really sure under what circumstances we go for lzma
<asac> unhappyaron: whats the total size?
<unhappyaron> asac: with no-lzma compress, there will be over 110MB to download when installing language support for zh_CN
<unhappyaron> asac: with lzma compress, it will be just less that 100MB
 * unhappyaron though that is still not a small volumn
<asac> hmm
<asac> dont we need to pre-depend on lzma or something?
<unhappyaron> asac: I think you need to talk to lidb then, he is the fix-maker
<unhappyaron> asac: he said there might be some problem there, but only he no the detail
<unhappyaron> lidaobing: ^^^
<asac> lidb: ?
<asac> pitti: any rule of thumb when (what deb size) it makes sense to use lzma compression? ... also is it just adding lzma to dh_builddeb or do we need to tweak some depends for that?
<arand> Bug #418135 << Should the SRU team be subscribed here? Seems like not much is happening with it atm... Kees ?
<ubottu> Launchpad bug 418135 in glib2.0 "Permissions of symlinked source file/folder set to 777 if symlink is copied via nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/418135
<asac> arand: ask kees ... who probably would be best to decide/guide this bug
<doko> asac: libwi-dev, not libiw-dev?
<lidaobing> asac, hi
<asac> doko: huh?
<asac> doko: i dont see libwi-dev
<doko> asac: you mention the wrong one in the changelog
<asac> ok changelog ;)
<lidaobing> asac, these two packages in widely used in China, but my people in China has a very low network speed
<asac> control should be right
<lidaobing> asac, that's why I recompress it with lzma
<asac> lidaobing: yes. i am fine with it. just want to know if the change you did is enough
<asac> waiting for answer atm
<lidaobing> asac, currently it should be OK, and I am uploading it to ppa (for a build log)
<asac> lidaobing: the building i sdefinitly ok. just wondere if we need a pre-depends on lzma
<lidaobing> asac, pre-depends on verioned dpkg  is enough
<lidaobing> asac, because dpkg is pre-depends on lzma
<lidaobing> and asac ttf-arphic-uming use a smilar resolution
<pitti> ugh, I still need to get used to the new brown
<pitti> Riddelll: ok, so it's meant to stay in universe?
<Riddelll> pitti: yes
<pitti> asac: lzma> my gut feeling is that it's worth it if it saves 0.5 MB or more
<pitti> asac: you need that, and Pre-Depends: dpkg (>= 1.10.27ubuntu1)
<jdub> asac: about?
<asac> lidaobing: ok can you add that to the debdiffs?
<jdub> caught! 8)
<lidaobing> asac, add what?
<asac> lidaobing: if not i can do that
<asac> the pre-depends like above
<asac> if its already in the package its ok
<jdub> asac: you know about nm-applet missing libnm-glib-vpn?
<lidaobing> asac, already done, check the new debdiff
<lidaobing> asac, I have to go home, see you
<seb128> hey jdub, it has been a while, how are you?
<jdub> hey seb128
<jdub> good
<jdub> seb128: really enjoying karmic :-)
<jdub> feels like it's going to be as good as breezy was in its day!
<seb128> good ;-)
<jdub> seb128: how have you been?
<seb128> jdub, busy as usual but otherwise pretty good, thanks
<jdub> seb128: http://www.flickr.com/photos/jdubflickr/3942767533/ <- moved to the country, have a growing family ;-)
<seb128> jdub, nice! ;-)
<ogra> jdub, what, even more dogs ? :)
<asac> jdub: we dont have that as a separate package
<asac> jdub: is that a problem for you?
<jdub> only when this happens... :-)
<jdub> jdub@fehung:~$ ldd /usr/bin/nm-applet | grep vpn libnm-glib-vpn.so.0 => not found
<jdub>  
<jdub> perhaps a missing glob in a .install file?
<pitti> geser: Packaging Help> well said!
<jdub> (means nm-applet won't run, which might be alarming/inconvenient for some testers)
<jdub> oh no, there is a .so there, but so.1
<jdub> shlibdeps issue?
<hyperair> hmm something's wrong. why is it taking a whole 50 seconds to reach gdm now? it used to be only 25 seconds.
<LaserJock> pitti: +1 on the +1 to geser :-)
<pitti> hyperair: rotary disks? sreadahead is pretty broken on those right now
<jdub> hyperair: it appears to be quite a bit slower when sreadahead is running; reboot again (without upgrading packages) and it'll be nice'n'fast
<ArneGoetje> mvo: ok. Should u-m also check for missing packages and install them automatically? For example, if the user installed his system without internet connection and the first time he connects to the net, u-m could suggest to install the missing translation packages together with the other updates.
<hyperair> jdub: this is my third reboot.
<hyperair> without upgrading
<hyperair> pitti: yeah it's rotary. i thought someone told me theo ther day that sreadahead is supposed to be on par with readahead even on rotary disks
<pitti> hyperair: it is, but for me it just sits there idling for several minutes, and not fetching a single byte
<pitti> http://people.canonical.com/~pitti/tmp/tick-karmic-20090916-2.png
<hyperair> pitti: meh. when does sreadahead run anyawy?
<pitti> well, admittedly that's pretty old already, I should check again on current karmic
<pitti> hyperair: well, it's _supposed_ to pre-fetch, of course :)
<pitti> and it did work in the past
<hyperair> sigh
<hyperair> what runs in init-bottom?
<hyperair> that itself takes a 10 seconds
<pitti> well, I wouldn't start worrying just yet
<hyperair> or was it 20
<hyperair> yeah i think it was 20
<pitti> Keybuk is killing boot bugs by the dozens, and it got tremendously better this week already
<hyperair> hmm i see
<pitti> I guess when he comes back from the conference next week, he'll tackle that as well
<hyperair> cool
<pitti> but there were far worse bugs so far, which actually broke booting completely
<jdub> boot improvements have been amazing. exciting stuff :-)
<sebner> pitti: haha, I just noticed my boot up needed 1.35 min. Instead of dirty karmic 48 secs
<jdub> (and not just speed)
<ogra> jdub, you mean like http://launchpadlibrarian.net/32366612/dsc_3982.jpg ? :P
<pitti> jdub: upstart FTW :)
 * hyperair off to reboot again
<ogra> yeah, upstart rules
<hyperair> ..or not.
<pitti> ogra: you seem to have a very bad camera :-)
<hyperair> i meant for reboot, not upstart
<ogra> pitti, lol
<asac> jdub: can you file a quick bug about that?
<jdub> asac: fo'sho
<ogra> pitti, just a 16bpp framebuffer (usplash, gdm, desktop wallpaper, all display fine, just xsplash freaks out)
<jdub> ogra: well, yes, i love the new xsplash artwork on decent screens ;)
<ogra> heh
<ogra> i love it on my lappie ... but it looks creepy on all my arm boards
<hyperair> jdub: decent screens?
<jdub> hyperair: cf. ogra's image
<hyperair> ah
<hyperair> somebody mentioned something about xsplash looking like a cylon licking its lips
<ogra> hehe
<asac> jdub: thats a -applet bug ... basically a respin now that i look at it. for one moment you scared me ;)
<jdub> asac: ah, ok
<jdub> asac: at least you'll have the satisfaction of closing that bug :-)
<jdub> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/435888
<ubottu> Launchpad bug 435888 in network-manager-applet "nm-applet can't find libnm-glib-vpn.so.0" [Undecided,New]
<pitti> hyperair: yep, still by and large looks the smae to me; a fractional second of I/O, and then long time nothing, and boot takes 85 seconds
<hyperair> pitti: that sucks.
<pitti> oh, presumably it regenerated the pack this time
<hyperair> meh.
 * pitti boots again
<tseliot> kees: did you file an MIR about execstack?
<dholbach> pitti: I'll have a look at the ibus stuff
<dholbach> arneGoetje, pitti: is ibus-pinyin supposed to be in main? it build-deps on python-pysqlite2 which is in universe at least according to my updated pbuilder
<pitti> I guess it's supposed to be in main, but deferring to ArneGoetje
<pitti> hyperair: right, it wasn't just the pack creation; the large 20 second CPU block is gone now, but it still takes 85 seconds now (was 50 in alpha-5)
<pitti> sreadahead is not doing anything
<hyperair> @_@
<hyperair> what a waste
<pitti> hyperair: so, it doesn't seem to be specific to your system
<hyperair> after i added the patch and recompiled too =\
<hyperair> well that's good to know
<hyperair> that it's not specific, i mean
<ArneGoetje> dholbach: yes, ibus-pinyin is supposed to be in main
<dholbach> pitti: ^ python-pysqlite2 is a build-depends of it and currently in universe - not sure what needs to happen there :/
<Amaranth> yeah, sreadahead is broken here too
<asac> dholbach: i am currently doing the ibus stuff
<asac> if thats the lzma thing
<dholbach> asac: uploaded already
<Amaranth> I can see it in bootchart doing a lot of CPU when it needs to generate a pack file but it never seems to use it
<asac> sigh
<asac> who is double checking here?
<dholbach> asac: what do you mean?
<asac> dholbach: i mean: i think i said i was doing it, but then you suddenly popped up and did it
 * pitti suggests to assign sponsoring bugs before starting on them
<asac> dholbach: so i assume someone asked you after that
<asac> or before or whatever ;)
<dholbach> sorry, that was 2h ago and I wasn't around at the time and didn't read the backlog
<asac> ok
<dholbach> no, I just thought that the list of stuff on the list is very long
<dholbach> and some of it should make it in for beta
<asac> that was my idea
<asac> i was explicitly pinged ;)
<dholbach> I didn't see it
<dholbach> sorry
<dholbach> I have a look at thaifonts-scalable now
<asac> all fine
<dholbach> ArneGoetje: it could be that we need python-pysqlite2 in main (mir)
<asac> i assume i shouldnt sponsor stuff when buried in other work so i dont loos time between preparing and uploading ;)
<asac> or assign bug ;)
<ArneGoetje> dholbach: IOW, I should create the MIR for it?
<ScottK> Isn't sqlite natively supported in python now?
<dholbach> I don't know if there's a way around it
<pitti> ScottK: it is, sqlite3
<ScottK> Ah.
<dholbach> it imports sqlite3 and pysqlitedb or something
<pitti> eww old version duplication
<dholbach> but I don't understand too much of what's going on there
<ScottK> Looks like we got that out of main two releases ago.
<ArneGoetje> does that mean ibus-pinyin needs to be changed to work with the sqlite3 support from python instead? Or is it just an unnesessary dependency in the package?
<al-maisan> hmm .. just did an 'sudo apt-get upgrade' and restarted, outcome: no wlan on either karmic box
<al-maisan> there's also no network-manager applet in the upper right corner
<al-maisan> is this a known issue?
<al-maisan> any work-arounds? fixes?
<jdub> al-maisan: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/435888
<ubottu> Launchpad bug 435888 in network-manager-applet "nm-applet can't find libnm-glib-vpn.so.0" [Undecided,New]
<jdub> al-maisan: i suspect asac will get to it soon
<asac> yes
<al-maisan> jdub: thanks for the info!
<al-maisan> asac: :)
<dholbach> hiya jdub
<asac> al-maisan: jdub: uploaded
<al-maisan> asac: great, thanks!
<jdub> yo dholbach
<jdub> asac: rock!
<dholbach> how's life down under?
<jdub> asac: just needed a sync?
<jdub> dholbach: lovely
<jdub> dholbach: moved to the country, got a dog, etc. ;-)
<jdub> dholbach: still in berlin? how are you?
<dholbach> jdub: when is a new planet release going to come up? ;-)
<dholbach> jdub: good - Berlin is still great, dog is still around :-)
<jdub> dholbach: "just use venus" 8)
<jdub> dholbach: venus ~= planet 3.0 (and the ~ will go away soon)
<dholbach> ah good - that will probably stop the python2.6 deprecation warning on my server ;-)
 * dholbach hugs jdub
<dholbach> jdub: you should hang around more often again
<ogra> ++
<ogra> ++++ actually :)
<jdub> dholbach: yeah, that was fixed fairly recently
<dholbach> jdub: rock and roll
<jdub> oh, that reminds me, i need to contact mr. nuzum
<jdub> about giving puc some love
<pitti> asac: oh, using uuencode? wouldn't it be simpler to not have an orig.tar.gz for those snapshot?
<soren> asac: I'm getting an XML error about an undefined entity when I access a site with self-signed cert. If I run firefox with LANG=C, it works. Does this sound familiar?
<pitti> I have that, too; error in German translattions
<soren> pitti: How do you work around it?
<pitti> soren: LANG=C :-)
<soren> thought so :)
<soren> Ok, thanks.
<pitti> I don't often have such pages, so it's not bothering me too much
<asac> pitti: thats an exception because the file didnt land upstream
<asac> pitti: did i forget the uudecode depend?
<pitti> asac: no, it's probably fine, it just seems cumbersome to me
<asac> yeah its temporary
<asac> its not because of snapshot, but because of prepatch ... didnt want to wait for the final code cleanups to get this up
<pitti> asac: I meant, if you don't use an orig.tar.gz, but a native tarball, you can just add them, instead of having to write extra debian/rules magic for this
<pitti> nevermind, though
<asac> pitti: ah ok. its fine for me. i like origs ;)
<asac> also we have dailies etc.
<asac> would have to teach them the difference too i guess
<ogra> woah, asac !
<ogra> i just got a mail to approve someone in the alioth ltsp team ... clicking the link in the mail makes FF explode in XML errors
<liw> hm, gnome-terminal on karmic is now using Alt-B to move to the next tab -- is this intentional? true for everyone? (I'm rather fond of using alt-B using emacs keybindings in bash...)
<pitti> liw: I have had alt-b backgrounding a window for ages, and it still works
<liw> pitti, in the wm? wouldn't that override anything the app does?
<pitti> liw: probably, yes
<mvo> Riddell: in bug #349066 there is a update-manager task - is there anything that u-m can do here? that looks like its purely a user thing
<ubottu> Launchpad bug 349066 in ubuntu-release-notes "Release notes need to tell upgrade users how to add new network-manager widget" [Undecided,Fix released] https://launchpad.net/bugs/349066
<jdub> E: Couldn't configure pre-depend sysvinit-utils for upstart, probably a dependency cycle.
<Riddelll> mvo: we can close that for now, the plasma widget is back to being a simple binary started with the normal autostart mechanism
<mvo> Riddell: thanks
<Riddelll> mvo: however kbluetooth is crashing during upgrade, could we have the release upgrade tool killall kblueplugd and killall kbluetooth  ?
<mvo> Riddell: sure, on full upgrades?
<mvo> Riddell: there is no other way? I would prefer if it would be done without killing
<Riddelll> mvo: there's no other way, kblueplugd doesn't have any way of quitting it
<mvo> Riddell: ok, adding that now
<mvo> Riddell: will we also need it for the 8.04 -> 10.04 lts upgrade?
<Company> pitti: you gotta know this: what's the best way to enable system-wide core dumps?
<kees> tseliot: I did, yes
<Riddelll> mvo: I don't know, but it wouldn't hurt
<tseliot> kees: where is it? Was it approved?
<kees> arand: I intend to get it pushed but I've been caught up with higher priority stuff.
<kees> tseliot: not sure if it was approved.  did you want to use it too?
<tseliot> kees: yes for nvidia and fglrx
<kees> tseliot: bug 418456
<ubottu> Launchpad bug 418456 in prelink "MIR for prelink" [Undecided,Fix committed] https://launchpad.net/bugs/418456
<bddebian> doko: You around?  Do you see an issue with removing sun-java6 from Debian?  The only remaining build-dep is tijmp
<kees> tseliot: ah, yes, approved.
<tseliot> kees: ok, good. I'll fix both drivers then
<mvo> Riddell: commited
<doko> bddebian: see the minutes of the tech board
<bddebian> doko: Sorry, which is where?
<kees> tseliot: ok, thanks.  my problem has been with having hardware to test the results.
<doko> I think, on the wiki, but maybe ask kees. looks like it's kept
<kees> tseliot: also, I noticed that I needed to run execstack on each file separately since it would sometimes fail if I put multiple binaries on the same execstack command line.
<tseliot> kees: ah, thanks for mentioning this problem
<kees> bddebian: a whole mess of stuff got put on my blog post about it: http://www.outflux.net/blog/archives/2009/09/12/uninstall-sun-java6/
<kees> bddebian: I was able to disprove some of the claims, but it seems like a lot of commercial products aren't "certified" on openjdk-6.
<kees> tseliot: yeah, np.  you can see my results here: http://launchpadlibrarian.net/30916852/nvidia-graphics-drivers-180_185.18.36-0ubuntu2~kees2_185.18.36-0ubuntu2~kees3.diff.gz
<tseliot> kees: ah, nice
<kees> tseliot: even though sometimes it would work on one cmdline (though I'd change this to use multiple): http://launchpadlibrarian.net/30883714/fglrx-installer_2%3A8.632-0ubuntu1_2%3A8.632-0ubuntu2~kees1.diff.gz
<tseliot> kees: ok, I'll do call execstack multiple times
<tseliot> s/do//
<newproggie> hello everybody
<newproggie> I have a question concerning packaging
<bddebian> kees: Yeah I see that thanks, but I don't see a lot of "proof", much of it seems to be speculation.  "Oh I tried it a year ago and it didn't work.."
<kees> tseliot: great, thanks for snagging this.  do you have hardware to test it with?
<kees> bddebian: yeah.  I was trying to get people to give specific technical details...
<newproggie> I'm trying to build a deb-package from source and there a two dependencies for this program
<tseliot> kees: yes, and I also discussed this with upstream(s)
<Riddelll> evand: what's the deal with the slideshow in ubiquity kde?
<kees> tseliot: oh! what'd they have to say?
<newproggie> where do I have to describe/name/put those two dependencies, please?
<tseliot> kees: let's continue in a private chat
<newproggie> or does dpkg-buildpackage do all the job for me?
<cjwatson> newproggie: Build-Depends
<cjwatson> newproggie: or Depends, depending on whether they're build-time or run-time dependencies. See the policy manual
<newproggie> cjwatson: thanks, this is my first deb-package. I deleted the changelog file, because there was nothing to mention and now dpkg-buildpackage complains about it?
<cjwatson> newproggie: debian/changelog is mandatory; again, it's probably best to start out by reading some documentation :)
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment#Packaging has a bunch of reference links
<newproggie> cjwatson: understand. The tutorial I was going through advised me to delete it..
<cjwatson> newproggie: complain to its author!
<directhex> the tutorial is bad at best, then
<cjwatson> and use a different tutorial, I'd probably guess :)
<newproggie> cjwatson: directhex: Guess so. I will read the packaging-Link, thanks guys
<agutierr> hi
<lamont> so if I'm running on some slightly strange hardware, and getty logins on ttyS0 exiting results in init not respawning the getty, what would be causing that?
<doko> asac: at least the xulrunner build on powerpc suceeded
<asac> doko: sparc still dep wait?
<asac> building
<doko> no, building
<agutierr> I would like write a bash script to make unnatended installations of debian packages... I would like to know how I can know if apt is locked (/var/lib/dpkg/lock)
<ion> It would be nice if dpkg, apt et al. would just wait for the lock.
<agutierr> ion, How I can know in a bash script if apt is locked?
<evand> Riddelll: there's a thread on ubuntu-installer about it.  Waiting to hear back from shytlman and picklesworth.
<DnaX> NetworkManager applet broken (unable to connect): #435999
<DnaX> bug #435999
<ubottu> Launchpad bug 435999 in network-manager "network manager applet broken by upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/435999
<jdub> DnaX: dupe of https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/435888
<ubottu> Launchpad bug 435888 in network-manager-applet "nm-applet can't find libnm-glib-vpn.so.0" [Undecided,Fix released]
<DnaX> sorry for flood
<DnaX> asac: ping
<asac> ?
<jdub> DnaX1: dupe of https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/435888
<ubottu> Launchpad bug 435888 in network-manager-applet "nm-applet can't find libnm-glib-vpn.so.0" [Undecided,Fix released]
<DnaX1> ok
<DnaX1> jdub: thanks
<DnaX1> jdub: marked as duplicate
<cypherbios> hi mvo, mpt: Do you guys have a channel to discuss software-store -related topics?
<mpt> cypherbios, we use #ubuntu-desktop for that at the moment
<bdmurray> pitti: looking at cups bug reports bug 420968 seems to have quite a few unmarked duplicates.  Why might the retracer not have marked them?
<ubottu> Bug 420968 on http://launchpad.net/bugs/420968 is private
<mdz> soren, are you taking care of the vmbuilder changes necessary to use the uec task instead of the hardcoded list for karmic?
<mdz> soren, cjwatson sent you a patch
<kirkland> any idea why my network manager disappeared from my toolbar after this mornings updates?
<pitti> erm, indeed
<pitti> I just rebooted, and it's gone for me as well
<pitti> asac: halp!
<pitti>  nm-applet
<pitti> nm-applet: error while loading shared libraries: libnm-glib-vpn.so.0: cannot open shared object file: No such file or directory
<pitti> ah, that rings a bell
<pitti> the n-m changelog spoke of a mini-abi transition
<kirkland> pitti: ack, same here
<pitti> bdmurray: indeed, and in fact we shouldn't get those kinds of reports in the first place (assertion errors without assertion messages), hmm
<pitti> will have a deeper look at this
<Martyn> Yep, dissapeared for me as well
<Martyn> Oh well, there goes the manager until someone fixes it :)
<pitti> Martyn, kirkland: it's most likely fixed already with  0.8~a~git.20090923t220421.1ac8ffd-0ubuntu2
<pitti> should get published in about an ohur
<kirkland> pitti: thanks
<Martyn> okay
<Martyn> I'
<Martyn> I'll wait for publication :)
<bdmurray> pitti: great, thanks
<bdmurray> pitti: in the mean time is safe to consolidate those?
<pitti> bdmurray: yes, absolutely
<mdz> soren, cjwatson, there was a 20090924.1 server build for a little while, but it seems to have vanished?
<cjwatson> cdimage is a rotation, one might be behind
<cjwatson> or a cache or something - it's there on antimony
<mdz> it was there for me, and then not there, in the same browser session on the same network, and no matter how many times I reload, I can't get it back
<nxvl> asac: nm is broken, know issue or should i report it?
<nxvl> asac: it's looking for libnm-glib-vpn.so.0, while there is libnm-glib-vpn.so.1 or libnm_glib_vpn.so.0
<ion> to195628 < pitti> Martyn, kirkland: it's most likely fixed already with  0.8~a~git.20090923t220421.1ac8ffd-0ubuntu2
<evand> gah, filing bugs on source packages is broken on edge.
<ion> Is it just me, or does the software store icon look like a trashcan (with a recycle symbol and everything â only by looking closer youâll notice itâs actually the Ubuntu logo)? :-P
* slangasek changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
<Keybuk> I'm guessing that /+reportbug isn't supposed to OOPS! ? :p
<beuno> Keybuk, correct. It will be fixed soon  :)
<beuno> it should redirect you to a wiki telling you to use ubuntu-bugs
<pitti> hey Keybuk
<pitti> Keybuk: kudos for this week, awesome work!
<Keybuk> pitti: hey
<Keybuk> slangasek: should I upload further bug fixes to the ubuntu-boot PPA for now?
<pitti> Keybuk: in between the conference and boot bugs, did you get sleep and food at all?
<Keybuk> pitti: I'm avoiding food, food makes you fat
<liw> a friend of mine has a new t-shirt which says: "SLEEP IS SO LAST NIGHT"
<pitti> just living off the metropolian air? :-)
<ion> liw: Hah
<liw> Keybuk, http://en.wikipedia.org/wiki/Inedia ? :)
<pitti> wow, I just got a whole slew of merge requests, some of them a month old
<Keybuk> I'm at a conference
<jcastro> post-freeze announcement "uh oh"s?
<Keybuk> and it's Thursday
<Keybuk> this means that my Internet line has gone down at home
<LaserJock> pitti: yeah, did somebody clean out the mailing list moderation queue?
<pitti> jcastro: no, more like LP emptying an old queue
<jcastro> oh
<cjwatson> Keybuk: I eventually got bored of that sort of thing and set up cron jobs at home to periodically kick the network
<cjwatson> which did involve driving the router's web interface scriptably, which was kind of ugh
<Keybuk> ah, my router doesn't have a web interface to speak of
<Keybuk> I could drive some kind of robot chicken to press the reset button on it
<cjwatson> ISAGN
<Keybuk> hmm, fail
<Keybuk> nm-applet: error while loading shared libraries: libnm-glib-vpn.so.0: cannot open shared object file: No such file or directory
<cjwatson> yeah, there's a bug filed
<cjwatson> bug 435888
<ubottu> Launchpad bug 435888 in network-manager-applet "nm-applet can't find libnm-glib-vpn.so.0" [Undecided,Fix released] https://launchpad.net/bugs/435888
<Keybuk> thankfully this wireless network does not need WPA
<pitti> slangasek: ok to upload a pkg-create-dbgsym to fix the current glib2.0 FTBFS? I reproduced the failure in the test suite, and it's fixed now (one-liner, was grep catching "kfreebsd-i386" as "i386")
<asac> nxvl: should be fixed in latest applet
<pitti> slangasek: there are also some pending packaging cleanups from lool in the branch, but they don't affect the .deb (just some lintian stuff)
<lool> Ah right intended to push after A6
<lool> they are safe but we were too close to the previous milestone
<pitti> slangasek: the essential changes are r138 (test suite) and r139 (fix) on http://bazaar.launchpad.net/~ubuntu-core-dev/pkg-create-dbgsym/ubuntu/changes
<nxvl> asac: so, fix has been commited, just need to wait for the archive to propagate?
<asac> nxvl: what applet version are you running?
<pitti> slangasek: since karmic is frozen, I uploaded it now (so you can reject it if you have doubts)
<asac> nxvl: network-manager-gnome
 * pitti -> dinner
<nxvl> asac: 0.8~a~git.20090913t161448.cc2f6be-0ubuntu1
<asac> nxvl: get 0.8~a~git.20090923t220421.1ac8ffd-0ubuntu2 or 3
<nxvl> asac: apt isn't still downloading it :(
<arand> kees: ping
<kees> arand: hi!
<slangasek> Keybuk: you should upload them to the queue so the release team can review them and shove them in? :)
<slangasek> pitti: yes, please upload and I'll review as LPC bandwidth permits
<arand> kees: Hia, I was wondering what's happening with Bug #418135 ?
<Keybuk> slangasek: ok, sure
<ubottu> Launchpad bug 418135 in glib2.0 "Permissions of symlinked source file/folder set to 777 if symlink is copied via nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/418135
<Keybuk> I've just been going through the bugs and making sure they're all targeted and milestoned as appropriate
<Keybuk> obviously I won't fix all of them for beta
<Keybuk> so if I don't, the target should help with the release notes generation
<Keybuk> and then retarget to release
<Keybuk> a couple a targeted directly to the release instead
<slangasek> great, thanks
<kees> arand: yeah, I intend to get it published, but I have been distracted by higher priority stuff.  I'm hoping to nail it down early next week while we are in beta freeze for karmic
<arand> kees: ok, cool. I was just wondering since I hadn't heard anything.
<kees> arand: yeah, getting it tested in each release is the time-consuming part.  :)
<cjwatson> gah, debootstrap is still failing
<mterry> persia, can you please make me a member of ubuntu-universe-sponsors?
<james_w> congratulations mterry
<mterry> james_w, thanks!
<evand> congratulations mterry!
<mterry> evand, :)
<cjwatson> wonder how this code ever worked
<mvo> congrats mterry
<mterry> mvo, thanks!
<Keybuk> cjwatson: I still see "GRUB Loading"
<cjwatson> correct
<cjwatson> some things we can get rid of without particularly compromising debuggability. That one can't be got rid of without making it totally impossible to tell what's going wrong if something does
<cjwatson> I've already explained this to robbiew and dbarth and they didn't object
<robbiew> ack
<robbiew> cjwatson: doesn't this also involve nasty assembly code?
<cjwatson> it does, though that's mostly relevant in that the obvious workarounds (e.g. display the messages only if you hold down a certain key, or something) are extremely difficult; part of that message is in boot sector code limited to 512 bytes, indeed
<slytherin> Now that we recomment use of ubuntu-bug to report the bug, how relevant is the LP integration patch for an app?
<Amaranth> slytherin: Doesn't it do the same thing?
<Amaranth> It's easier from the menu
<slytherin> Amaranth: does menu use apport?
<cjwatson> it *used* to go to +filebug directly, although it's ages since I looked at that code
<cjwatson> if it still does, I'm sure it would be easy and worthwhile to make it use apport
<cjwatson> since a menu item doesn't involve a terminal, or looking up the file name, etc.
<slytherin> hmm, I will have to take a look.
<slytherin> what could be possible reasons that a /dev/dvd1 node is created sometimes and sometimes not.
<Keybuk> slytherin: there's a bug report open about that
<Keybuk> (I don't know why it doesn't work sometimes for some people)
<sebner> mighty Keybuk, what just happned there? O_o .. http://img441.imageshack.us/i/ubuntukarmic200909241m.png/
<slytherin> Keybuk: can you please point me to that bug?
<al-maisan> hmm .. metacity crashing after the latest upgrade and system generally per
<al-maisan> s/per/feeling somewhat sluggish/
<al-maisan_> the laptop in question was upgraded from jaunty, I guess it's time for a fresh install ..
<smoser> anyone have thoughts on this...
<smoser> i want to put a marker file (or config file) in some location under /etc/ec2-init that indicates whether ec2-init should be active or not active (it would not be active by default)
<smoser> simplist thing would be to just decide based on the presence of 'active' in /etc/ec2-init/active
<smoser> or should i put/require "active=1" or some other syntax / config there
<smoser> mathiaz, i'll pick you to bother by name
<jono> what are these heart things in NM?
<slangasek> Legend of Zelda: 802.11n Association
<tormod> can I have a pony instead of a heart?
<slangasek> you can have a pony's heart
<mdz> cjwatson, is euca_conf part of eucalyptus or something we added?
<cjwatson> mdz: part of eucalyptus, although we added the --discover-nodes option
<mdz> cjwatson, do you mind if I reply to your email on ubuntu-devel?
<cjwatson> not at all
<cjwatson> hmm, does avahi's service resolver only return the first address it finds?
<mdz> kirkland, do you know ^^?
<kirkland> mdz: cjwatson: that has been my operating assumption
<slangasek> Keybuk: there's a util-linux change in here to remove the adjtime file unconditionally on upgrade from pre-jaunty?  that doesn't seem to line up with any of the changelog entries
<seb128> re
 * slangasek waves to seb128 
<seb128> slangasek, did you get my question before?
<slangasek> seb128: seems not, sorry
<slangasek> seb128: repeat?
<seb128> <seb128> slangasek, hello
<seb128>  slangasek, do you want to be pinged on IRC about uploads?
<seb128>  or do you just poll on the queue every now and then and decide from the diff and changelog?
<kirkland> mdz: cjwatson: i'm taking a quick look at the source code now
<slangasek> seb128: ah, definitely the latter
<mdz> smoser, how are the UEC images looking for beta?
<slangasek> seb128: especially this week, while I'm on conference bandwidth
<cjwatson> kirkland: I'm not convinced, I'm only getting it to give me one back here (the IPv6 one, most of the time)
<seb128> slangasek, ok, I did upload a papyon (msn provider for telepathy) one liner to fix an incorrect number of arguments in a function
<slangasek> Keybuk: NB, you shouldn't need "update-rc.d -f" because you're removing the files in the preinst so there should no longer be any overriding needed
<seb128> slangasek, there is a new indicator-messages version from dx guys
<slangasek> seb128: yep, I'm in the queue right now working on these
<seb128> slangasek, and I did upload a one liner bluez change to change the ranking on the gstreamer sink there so it stops hijacking easy codec install
<slangasek> well - working on util-linux currently, will be working on the others in the queue soon
<jono> cjwatson, around?
<cjwatson> jono: kind ofm but focusing, is it urgent?
<cjwatson> jono: (if it is, you have to fight with mdz)
<jono> cjwatson, mdz has asked me to get people together for testing eucalyptus, and says it is urgent, but I need to know what to ask them to test and he said you are best to ask
<jono> can you mail me with a list of what needs testing?
<cjwatson> ok, I'll try
<cjwatson> mdz: note I can't do much more tonight
<jono> thanks, I am trying to source people now
<jono> mdz, it seems we are going to need a new ISO built
<kirkland> cjwatson: so i don't mind modifying that one liner in the iso to do my testing
<kirkland> cjwatson: but to ask anyone else to do testing on our behalf, i think we'd want to spin a new iso
<cjwatson> yes yes
<cjwatson> I want to upload eucalyptus with my bits from tonight too
<cjwatson> but my laptop is a bit loaded so give me a few minutes
<seb128> slangasek, http://bazaar.launchpad.net/~ubuntu-desktop/evolution-indicator/ubuntu/annotate/head%3A/debian/preinst seems correct to you?
<jono> ok, so I will wait for the ISO and simple test plan from cjwatson before I ask the testers to kick off
 * cjwatson shuts down the VMs for now
<seb128> slangasek, I ask before uploading since we have 3 of those to upload
<jono> in the meantime I will continue to source some more testers
<slangasek> seb128: checking
<seb128> slangasek, those are not conffile, that's file with one line listing a desktop file and have been added a few days ago in karmic
<seb128> slangasek, not sure while kenvandine put "" too I will probably clean those before uploading
<slangasek> seb128: if not a conffile, what is it?
<seb128> slangasek, what I just said, a one liner listing a .desktop launcher for the indicator message applet
<slangasek> seb128: created how?
<Laney> no need for -release to be on bug 436082, please unsubscribe
<seb128> slangasek, they are being moved to usr now, which explain why we clean those on upgrade
<ubottu> Launchpad bug 436082 in minicom "Fix FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/436082
<seb128> slangasek, http://bazaar.launchpad.net/~ubuntu-desktop/evolution-indicator/ubuntu/annotate/head%3A/debian/rules
<seb128> slangasek, echo ... > in rules
<slangasek> seb128: so... it should automatically have been made a conffile
<seb128> slangasek, well, I meant they are not real conffile in the sense they will not have user changes
<seb128> slangasek, ie no need to check md5sum for changes and backup those
<jono> cjwatson, btw, kirkland is going to take care of putting together a screencast showing what needs testing so you can get to bed
<slangasek> seb128: ok - not completely correct policy-wise, then, but I'll accept it through the queue if you upload it :)
<slangasek> (i.e., I won't make you do extra work here if you're confident)
<seb128> slangasek, ok thanks
<seb128> slangasek, well I'm always happy to take constructive comments for next time ;-)
<cjwatson> jono: ah, good
<jono> cjwatson, I will ask Jorge to transcribe the video when it is done
<seb128> slangasek, you would have use the standard debian wiki snippet for those?
<cjwatson> kirkland: do you need anything from me for that? my mail should be of some help with workarounds for known problems and the like, so that people can get to the point of uploading images which I assume is the thing we really want tested
<slangasek> seb128: my method is: am I removing something marked as a conffile by dpkg?  Yes -> steal the snippet from dpkg.org :)
<slangasek> seb128: yeah
<cjwatson> (there's no point in repeatedly testing the stuff I just tested ...)
<slangasek> seb128: that way, I don't have to even /consider/ the question of whether the conffiles would have relevant user changes :)
<seb128> ;-)
<kenvandine> seb128, slangasek: noted :)
<Martyn> Last update killed the network monitor
<seb128> kenvandine, I've added a --ignore-fail-on-non-empty to rmdir too
<seb128> kenvandine, that avoids having the warning displayed
<Martyn> is nm going to be updated again in a little bit?
<Martyn> Hmmm .. this last update turned a lot of the UI soooo brown
<Martyn> not sure how I feel about karmic being so .. brown
<kenvandine> seb128, thx
<tormod> Martyn, #ubuntu+1 is the place to discuss karmic (and nm-applet is fixed now)
<Martyn> Meep
<mdz> cjwatson, can kirkland and I take care of any remaining tasks for you so you can quit for the day?
<kirkland> jono: http://www.youtube.com/watch?v=gcx8HZWSYB8
<smoser> mdz, i'll put a status together tomorrow. but all in all pretty good. bug 431255 and then kernel bugs 431103 and bug 428692
<ubottu> Launchpad bug 431255 in ec2-init "ec2-init: Move ec2-run-user-data to startup priority S99" [Medium,Confirmed] https://launchpad.net/bugs/431255
<ubottu> Launchpad bug 431103 in ec2-init "ssh host key fingerprint no longer available in the console log" [High,Triaged] https://launchpad.net/bugs/431103
<ubottu> Launchpad bug 428692 in ubuntu "ec2 kernel needs CONFIG_BLK_DEV_LOOP=y and other config changes" [Medium,Confirmed] https://launchpad.net/bugs/428692
<cjwatson> mdz: I've uploaded eucalyptus 1.6~bzr854-0ubuntu3; it would be most helpful if somebody could take care of respinning server images once binaries for that in the archive
<cjwatson> s/in the/are in the/
<cjwatson> mdz: 'for-project ubuntu-server cron.daily' as the cdimage user on antimony
<seb128> slangasek, evolution-indicator empathy pidgin uploading for those etc cleaning
<slangasek> seb128: ack, will grab them soon, thanks
<seb128> thanks ;-)
<cjwatson> mdz: oh, my eucalyptus upload is waiting for RM approval
<cjwatson> mdz: anyway, need to crash now - night
<mdz> cjwatson, thank you, good night
<seb128> slangasek, new libdbusmenu from dxteam uploaded, there is a small abi breakage without soname change but ted says the function should no be in the abi and nothing use it (the lib is new in karmic and still only used by what ted writes)
<slangasek> tedg: when are you taking this function out of the ABI then? :)
<slangasek> doko_: you said you fixed OOo on armel; is that fix included in 1:3.1.1-2ubuntu1, and should bug #417009 be closed?
<ubottu> Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] https://launchpad.net/bugs/417009
<slangasek> lool, ogra: ^^ can you confirm whether OOo is fixed on armel now?
<doko_> slangasek: no, that's another thing while debugging this one. I have a roadmap now, will follow up tomorrow
<slangasek> ah :(
<ebroder> Does lilo-installer/skip not work in Hardy?
<seb128> slangasek, indicator-session update upload for dx guys too
<seb128> uploaded
#ubuntu-devel 2009-09-25
<seb128> slangasek, I've uploaded a new gdm revision with a 2 liners bug fix from brastche
<seb128> bratsche
<ebroder> Does anybody know why preseeding the Hardy installer with lilo-installer/skip=true isn't working?
<tedg> slangasek: Next release :)
<kees> pitti: what's the state of apport in Fedora?  I was approached today by a SUSE dev who was interested in it for them as well.
<dtchen> jdstrand: / ajmitch: ping, please update your jack-sense bugs when you have a chance. the upstream merge window is very quickly closing.
<ajmitch> dtchen: sorry to not catch up with you, I've had problems getting it built
<dtchen> ajmitch: where is it ftbfs?
<ajmitch> at one point it was in that patch, but subsequent updates from the tree had it failing in other places
<ajmitch> I expect that I'm not building the kernel properly
<dtchen> ok, i'll take a look at it this weekend
<dtchen> in the meantime, can you try with just enable_msi=1?
<dtchen> (with whichever Karmic kernel you have access to)
<ajmitch> I'll give that a try
<dtchen> ajmitch: e.g., sudo /sbin/alsa force-unload && sudo modprobe snd-hda-intel enable_msi=1
<ajmitch> dtchen: bad news is that doesn't change anything
<dtchen> only in way.
<dtchen> good news is that it's already fixed, but you likely need an msi whitelist addition in addition to the model quirk
<ajmitch> ok
<dtchen> more hacking on the plane, i suppose
<ajmitch> do you need anything added to the bug report?
<dtchen> not currently, thanks
<mdz> slangasek, do you have buildd super powers?
<slangasek> mdz: no, sorry
<mdz> anyone around who does?
<slangasek> kees: do you? ^^
<kees> slangasek, mdz: no, sorry.  only the GSAs can get to the buildds, I think.
<kees> mdz: check with lamont or pjdc
<slangasek> there's the buildd group that lets people manage the build queues, I supposed that's what mdz was asking after
<mdz> yes
<mdz> I have a PPA build I'm urgently waiting on
<kirkland> jono: http://www.youtube.com/watch?v=-0wc4LCSqHI
<slangasek> mdz: btw, euca just finished publishing and the server ISO build is starting now
<kees> mdz: I do have a non-virtual PPA, if you don't get your build priority sorted out; I could push a karmic PPA build through those if you need.
<mdz> slangasek, thanks
<maxb> kees: You could rescore the build for mdz too
<maxb> :-)
<kees> maxb: I don't think I have that ability.
<kees> maxb: but if I do, please show me how.  :)
<maxb> ~techboard is a member of ~launchpad-buildd-admins
 * kees didn't realize he had new super powers, and goes looking
<mdz> slangasek, FYI I have the next eucalyptus rev in a PPA right now and plan to hack up a server ISO to test it locally before uploading
<maxb> Not that I've ever seen the UI myself, but I'd imagine if you find mdz's build there should be a link to allow you to edit its score
<slangasek> mdz: ok
<mdz> maxb, there used to be an obvious link for rescoring the build (I'm in techboard as well), but no longer
<mdz> anyway, it's started now
<slangasek> mdz, kirkland: http://cdimage.ubuntu.com/ubuntu-server/daily/20090925/
<kirkland> slangasek: cool, thanks
<kirkland> mdz: this is what i'm working with: https://help.ubuntu.com/community/Eucalyptus
<kirkland> mdz: but it's very dated (jaunty era)
<kirkland> mdz: update -> http://open.eucalyptus.com/wiki/EucalyptusAdministratorGuide_v1.6
<mdz> slangasek, can you give me the magic mkisofs options for the official isos?
<slangasek> mdz: hrm, digging through the debian-cd config
<slangasek> mdz: eh, easier to get it by grepping the log file... pastebinning
<slangasek> mdz: http://paste.ubuntu.com/277507/
<mdz> slangasek, thanks
<mdz> slangasek, sorry, I should have specified amd64
<slangasek> mdz: ah, grabbing
<slangasek> mdz: here: http://paste.ubuntu.com/277509/
<mdz> slangasek, what is boot1?
<slangasek> mdz: directory containing the bits that debian-cd puts together for the bootloader...
<mdz> slangasek, hmm, I don't remember needing that in the past
<mdz> I assume the contents end up in the iso and the ones there will work fine
<slangasek> mdz: correct - it's the contents of the isolinux subdir
<mdz> slangasek, hmm, it's not cooperating
<mdz> genisoimage -r -V Ubuntu-Server\ 9.10\ amd64 -o karmic-server-amd64+plumbers.raw -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /media/cdrom
<mdz> I: -input-charset not specified, using utf-8 (detected in locale settings)
<mdz> genisoimage: Uh oh, I cant find the boot catalog directory 'isolinux'!
<mdz>  /media/cdrom/isolinux exists and contains the usual assortment
<slangasek> mdz: mm - really don't know :(
<slangasek> mdz: I trust debian-cd to get this right for me
<slangasek> mdz: I guess the first thing I would try would be to split the boot stuff out into a separate parent directory and build it the same way debian-cd does (boot1/ CD1/ )
<mdz> slangasek, I'm pretty sure it just reads each pathspec in turn, that the first one isn't special
<mdz> I'm also using genisoimage rather than mkisofs, because it's what I have here
<mdz> and I'm using the karmic version
<mdz> strace doesn't even show it reading in the directory
<mdz> I wonder if it's simply broken
<mdz> slangasek, arrgh, it chokes if the pathspec is a symlink
<jono_> jcastro, so Bill has VT capable hardware to test?
<jcastro> he's joining in a sec
<jcastro> WildBill: ok so you have kvm-capable hardware right?
<WildBill> a couple of pieces of gear, yeah
<WildBill> laptops mostly LOL
<WildBill> but yeah
<WildBill> dual core, 2GB RAM
<jcastro> jono_: ^
<jono_> awesome
<jono_> thanks WildBill
<WildBill> thank me when we're done LOL
<WildBill> it'll be fun tho :)
<jono_> WildBill, keep an eye on http://testcases.qa.ubuntu.com/System/Eucalyptus for updates
<jono_> WildBill, kirkland is going to add further test instructions there when he is done
<WildBill> oh damn, that looks easier than the other stuff I was reading :)
<jcastro> WildBill: oh don't worry, this is in addition to
<kirkland> WildBill: oh, that's the easy part
<WildBill> haha yeah
<WildBill> so when does this testing start?
<jono> WildBill, they are still working on the ISOs
<TheMuso> WildBill: The testing won't start till next week, at least for the beta isos that is.
<ScislaC> This is related to development, and just a curiosity... Why does it seem to take substantially longer for the changelogs to be available compared to the packages? (I'm always running a +1 version of Ubuntu, so I've noticed this for a long time)
<wgrant> ScislaC: The changelogs are only extracted every few hours, by a process completely separate from the package publishing.
<ScislaC> wgrant: ahhh! Is the any reason why they are pulled like that as opposed to being pushed when the builds complete successfully? (not trying to say I know better, just wondering)
<wgrant> ScislaC: Not really. They should eventually be extracted by Launchpad once the build completes and made available immediately, but that's not done yet.
<ScislaC> wgrant: gotcha... thanks for the info! :)
<trip0> so starting jaunty from startx in tty1, the 90consolekit script runs, but my session active = FALSE
<trip0> will this still be a problem in karmic?
<TheMuso> c
<trip0> :(
<Keybuk> one day, I'd like to travel *without* either my home DSL, mail server or laptop hard drive dying
<liw> should be possible to manage that for one day, perhaps two, but that's not enough time to get very far
<Keybuk> yup
<Keybuk> my laptop has the unmistakable "click of death"
<lifeless> :(
<Keybuk> it's all evan's fault
<pitti> Good morning
<pitti> kees: I didn't hear from Fedora about Apport for a long time; seems they don't like it
<jussi01> jcastro: is there some way to confirm UDS applications have gone through?
<Keybuk> pitti: aren't they NIHing it?
<pitti> Keybuk: Lennart once wrote a script which intercepts core dumps, yes
<pitti> but I have no idea how far that got; I just commented on his blog post
<pitti> clarifying that apport is FOSS (there were rumours that it's some proprietary code on Canonical's server..)
<Keybuk> whose blog post?
<pitti> Keybuk: http://0pointer.de/blog/projects/automatic-backtrace.html
<Keybuk> right, that was quite a while ago now
<pitti> therefore "didn't hear something for a while"
<Keybuk> http://fedoraproject.org/wiki/Features/CrashHandling
<Keybuk> yes
<Keybuk> Fedora plan to NIH apport
<Keybuk> also http://fedoraproject.org/wiki/Features/CrashCatcher
<TheMuso> nih?
<ttx> TheMuso: not-invented-here. In this context I suppose they want to reinvent it just because we wrote it
<Keybuk> kinda
<Keybuk> more because they *didn't* write it
<TheMuso> Right.
<Keybuk> RH/Fedora have a real problem with that
<TheMuso> Don't they just.
<Keybuk> like the time they included screenshots of an Ubuntu tool in their Features/ wiki page, with the comments "make it look and work like this tool in Ubuntu":
<pitti> ooh, apparmor in the queue -- I can haz network in live system again?
<dpm> pitti: hi, good morning! we currently don't have a way in LP translations of tracking which packages are promoted to main or demoted, and we often find out quite late in the cycle that e.g. we have to disable templates of demoted packages. Do you know if there is a place where MIR or demotions can be tracked, so we can have a look at it?
<pitti> dpm: hm, tricky; there's no log of demotions, since they by and large "just happen" when some archve admin cleans up component-mismatches
<pitti> dpm: for promotions most packages go through the MIR process, so the ~ubuntu-mir bugs tell them
<pitti> dpm: but I think it'd be easier to periodically run a script which compares the packages which Rosetta thinks are in main, and which are actually in main
<dpm> pitti: sounds like a good idea, thanks. Which do you think would be the best way to find out which packages are in main?
<pitti> dpm: how about
<pitti> wget -O - http://archive.ubuntu.com/ubuntu/dists/karmic/main/source/Sources.gz | zgrep ^Package: | cut -f2 -d' '
<pitti> dpm: That's the fastest way I know of if you have network
<dpm> fantastic, thanks a lot, pitti
<cjwatson> ebroder: there's a changelog entry in lilo-installer after hardy indicating that it was fixed; you might want to look at the changelog and chase the bug reference there
<cjwatson> TheMuso: testing (your reply to WildBill): this is a special effort to get eucalyptus testing earlier than the beta ISOs
<cjwatson> dpm: FWIW if you're doing anything more complicated with Packages or Sources files than that zgrep | cut of pitti's, you'd be well-advised to look at grep-dctrl
<dpm> cjwatson: thanks a lot for the info, I didn't know about it and I'm sure it'll be very useful
<tseliot> pitti: I think bug #428662 is really a duplicate of bug #364508 however the former seems more specific to karmic while the latter is also about jaunty
<ubottu> Launchpad bug 428662 in xserver-xorg-video-intel "kdm crashes system on logout" [High,Confirmed] https://launchpad.net/bugs/428662
<ubottu> Launchpad bug 364508 in xserver-xorg-video-intel "[i965gm kms ] X crash on kde 4 logout" [High,Confirmed] https://launchpad.net/bugs/364508
<pitti> tseliot: oh, it sounded as if it was a recent regression
<tseliot> pitti: the upstream report is recent
<tseliot> hmm
<tseliot> pitti: either way a fix is available :-)
<pitti> oooh!
<Riddelll> ooh?
<lool> pitti: Would you mind kicking moblin-remix-meta out of NEW please?  It was ETARGET   :-(
<tseliot> :-)
<pitti> lool: you mean "reject"?
<lool> Yeah
<lool> delete, burn, whatever  :-)
 * pitti makes a flush noise
<lool> pitti: thanks
<lool> pitti: wash your hands
<pitti> tseliot: fix to intel, or a workaround in kdm?
<tseliot> pitti: a proper fix in the -intel driver
<pitti> lool: soyuz is sterile!
<pitti> it has no bugz
<pitti> tseliot: rockin'
<tseliot> :-)
<pitti> tseliot: does the fix look harmless enough for beta? or very intrusive?
<tseliot> pitti: either we upgrade to the latest driver (we're discussing this with upstream) or I could backport the fix (if possible)
<tseliot> pitti: it looks like the fix is trivial to port
<pitti> great
<geser> metacity --replace
<pitti> geser.fix_focus()
<geser> pitti: it's hard to type into the right window when you can't see anything (was trying out gnome-shell)
<chrisccoulson> geser - so gnome-shell is working well for you then? ;)
<geser> chrisccoulson: if you count a black distorted screen to it, then yes
<chrisccoulson> heh. i tried it a few days ago as well. i think i probably had a bit more success than that, but it is unbearably slow on my factory-overclocked nvidia 8800gt, which is somewhat surprising
<sebner> geser: gnome-shell ftw!
<geser> chrisccoulson: does it need 3d acceleration? because I only use the 2d radeon driver and not fglrx
<sebner> chrisccoulson: I think that's a driver issue. I can use it (no games though) without problems. glxgears shows me 3-4 times less frames
<sebner> geser: imho yes
<chrisccoulson> geser - yes, it needs 3d
<chrisccoulson> there is no fallback with clutter unfortunately
<chrisccoulson> there's been a lot of discussion about this upstream, as a few people disagree with the decision not to include a fallback
<chrisccoulson> apparently, the "fallback" will be gnome-panel and metacity;)
<sebner> chrisccoulson: haha, how long is the question
<geser> at least there will be a fallback for those without 3d or with old hardware (perhaps it's time I switch to fglrx finally)
<sebner> geser: FLOSS ftw! but yes, change
<sebner> ^^
<cjwatson> ArneGoetje: sorry for the delay, replied to you on -devel now
<chrisccoulson> sebner / geser - if you're interested in reading about the discussion, it is here: http://www.mail-archive.com/desktop-devel-list@gnome.org/msg15609.html
<sebner> chrisccoulson: cool, thx
<geser> lool: it should be safe now to give-back cheetah on ia64 to resolve the upload error (as the source in now published in main (and not pending anymore))
<lool> geser: thanks
<lool> geser: Did you confirm this with bigjools?
<geser> lool: no, but I've seen this error several times already and it was always because the source package got promoted at the same time
<wgrant> That's right.
<wgrant> A give-back after the subsequent publisher run will work fine.
<wgrant> The important bit is that the old one is Superseded, not that the new one is Published, although those generally happen at the same time.
<lool> geser, wgrant: thanks given back
<YokoZar> If I still have audio problems in karmic should I ubuntu-bug alsa-base or pulseaudio?
<sladen> welcome to emo-os
<highvoltage> hmm, GDM only starts now if you have a working Internet connection when it starts :)
<Riddelll> mvo: "AttributeError: 'DistUpgradeQuirks' object has no attribute '_killKBluetooth'
<Riddelll> crash in DistUpgrade tool
<Riddelll> http://paste.ubuntu.com:80/277786/
<mvo> Riddell: thanks, fixing now (and sorry)
<sgallagh> mathiaz: I just wanted to give you a heads-up that some major changes are going to be rolling into the SSSD today, in time for our 0.6.0 release. They change the format of the configuration file, but we're also shipping an upgrade script in the tarball, so you may want to roll that into whatever .deb has as a post-install section.
<YokoZar> Have most of the games been removed by default?
<jdstrand> dtchen: hi. I (finally) tested the patches you asked me to test in bug #400682
<ubottu> Launchpad bug 400682 in linux "[Karmic stac9227 regression] No sound after upgrade from Jaunty to Karmic" [Medium,Fix committed] https://launchpad.net/bugs/400682
<jdstrand> dtchen: I updated the bug, but in summary, it FTBFS
<MacSlow> tseliot, was there an update to some nvidia-glx-185 (or related package) between yesterday or today?
<MacSlow> kenvandine, seb128: Was there an update to libwnck between yesterday and today?
<Amaranth> MacSlow: What exploded? :)
<MacSlow> Amaranth, hey Travis
<Amaranth> howdy
<MacSlow> Amaranth, notify-osd causes libwnck assertions and thus failing to display any notification bubbles if I run my setup with two LCDs... yesterday everything was smooth as silk
<Amaranth> there was a compiz update
<Amaranth> shouldn't have affected anything like that though
<MacSlow> Amaranth, not compiz-related I think.. the issue also occurs under metacity (without compositor)
<Amaranth> MacSlow: libwnck hasn't been updated since the 22nd and nvidia-glx-185 hasn't been updated since august
<MacSlow> gee... what bloody side-effect is hitting me here then I wonder
<seb128> MacSlow, no
<seb128> it didn't change for weeks
<seb128> the recent update was translations only
<MacSlow> seb128, somehow a bug was triggered between yesterday and today on my nvidia-based system causing bubbles to no longer appear in a dual-LCD setup
<MacSlow> seb128, disabling the second lcd got the rendering back in order again
<MacSlow> seb128, dual-LCDs on my nvidia-box worked with notify-osd for months before (even under karmic until this morning)
<soren> bubbles?
<seb128> soren, how do you call notification rectangles with text?
<seb128> soren, it's usually called bubble
<soren> Oh, those!
<soren> :)
<seb128> soren, yes ;-)
<soren> I thought this was some sort of compiz effect like the wobbly windows or whatnot :)
<MacSlow> soren, the term "bubble" is not official though
<MacSlow> soren, just wanted something to differentiate from notifications rendered by notification-daemon
<soren> MacSlow: Sure, sure, I follow you now. My mind was elsewhere :)
<MacSlow> soren, that's why sometime during the jaunty cycle I refered to them as bubbles
<MacSlow> notification-rendition would be the more fitting term I guess
<Ng> empathy calls them "bubble notifications", gwibber calls them bubbles ;)
<MacSlow> but such long terms are very inconvenient
<MacSlow> hey ng
<Ng> hey :)
<jcastro> jussi01: pm me your name and i can check the system
<cjwatson> anyone happen to know why today's desktop CD doesn't automatically switch to vt7?
<james_w> anybody else seen anything like bug 436590?
<ubottu> Launchpad bug 436590 in update-manager "Hang up upgrade with aptdaemon" [Undecided,New] https://launchpad.net/bugs/436590
<james_w> I guess it would be high priority if it affected more than just me
<mvo> james_w: absolutely
<mvo> james_w: is it still running?
<james_w> yes
<james_w> I can gather any information that you need
<mvo> james_w: could you mail me the output of ps afx (or attach if it does not contain anything private)
<james_w> mvo: mailed
<mvo> james_w: thanks, I see if I can reproduce it here
<james_w> mvo: great, thanks. I'm going to grab some lunch
<james_w> mvo: when was the switch to aptd done?
<james_w> oh, I forgot one thing
<james_w> added to the bug
<pitti> cjwatson: uh, confirmed here
<mvo> james_w: was there debconf involved at any time (other than the message printed there)?
<glatzor> Hello mvo and james_w, it seems that richard is now open to a conf file conflict and debconf integration into packagekit
<james_w> mvo: no prompts, no conffile prompts, nothing
<james_w> hello glatzor, I saw, nice work
<pitti> cjwatson: the current CD has various problems due to Apparmor being active on the live system; but it seems a weird thing to be triggered by AppArmor..
<seb128> pitti, the vt thing is not liveCD specific
<james_w> pitti: does "ubuntu-bug <packagename>" do the version checks too?
<seb128> I've read comments going on on bugs for some days
<pitti> james_w: yes, same mechanics
<seb128> but I've no clue about those and Keybuk seems to refuse looking at those and just point it's gdm issues without any clue of why
<james_w> pitti: ok. Not ideal for reporting problems with upgrading, but I guess we don't need everyone to do that
<mvo> glatzor: yeah, good stuff
<pitti> james_w: don't you get automatic reports for that from apt?
<james_w> pitti: well, not in this case, there aren't upgrade failures or crashes, I've got a hang in update-manager/aptdaemon
<james_w> anyhow, we can manage
<tseliot> pitti: are you affected by bug #428662 ?
<ubottu> Launchpad bug 428662 in xserver-xorg-video-intel "kdm crashes system on logout" [High,Confirmed] https://launchpad.net/bugs/428662
<seb128> pitti, any clue about bug #436515?
<ubottu> Launchpad bug 436515 in gdm "GDM doesn't start when DNS lookups aren't available" [Medium,New] https://launchpad.net/bugs/436515
<pitti> tseliot: no, it only seems to affect kdm
<pitti> seb128: looking; missing lo?
<seb128> pitti, I'm not sure, I was just wondering
<tseliot> ok
<hyperair> meh. what does one do when dpkg gets corrupted?
<hyperair> is there a way to regenerate the metadata?
<hyperair> hmm.. what's in /var/lib/dpkg/updates anyway?
<huats> cjwatson: hi
<cjwatson> hello?
<huats> I've just seen the bug you report on the python webkit binding
<huats> (I am the current debian maintener)
<cjwatson> that was quick!
<huats> :)
<huats> I am subscribed to it :)
<huats> what can I do to help out ?
<hyperair> Kmos: thanks.
<cjwatson> well, there's a test case on the bug
<cjwatson> the package with the data in it is Ubuntu-specific, but it has no dependencies so it should be easy to install
<huats> ok
<huats> cjwatson: I know that it is ubuntu specific (I am also a motu :))
<cjwatson> I got it to the point where as far as I could see it wasn't a bug in the calling script
<cjwatson> but if that's a mistake, obviously feel free to reassign back with my apologies; I'd like to know what we're doing wrong if so, though
<huats> I might be good to ask the upstream author about it
<huats> he is usually very quick to aswer
<huats> answer
<smoser> james_w, i think i understand why this is the case, but just wanted to let you know its at least annoying.  http://paste.ubuntu.com/277965/
<huats> cjwatson: it might be great also to test that against the new upstream release
<huats> I'll try to do that this weekend
<huats> I'll let you know before monday
<directhex> hmph. i still get funny messages about init on shutdown. i heard rumours of a shutdown splash screen! :(
<james_w> smoser: more than a little annoying as well
<smoser> james_w, anything can be done ?
<smoser> i can open a bug if need be
<james_w> smoser: you either have to upgrade/downgrade one of the branches so that they match
<james_w> or go through some painful machinations to avoid the default stacking
<james_w> I think there is a bug already
<smoser> well i can't change the ubuntu/ec2-init, right ?
<smoser> so the only option is upgrading the other
<james_w> smoser: you could ask soren to change that one, but it's probably easier to change yours
<smoser> ah.. you mean downgrade mine ? how would i do that ?
<james_w> you can do it using the upgrade command
<james_w> "bzr upgrade --format"
<james_w> --rich-root-pack is what you would want in this case it seems
<smoser> thanks. i was just going to ask you how i de-coded KnitPackRepository to something that --format would like
<smoser> james_w, :-( it tells me i can't do that.
<smoser> bzr: ERROR: Cannot convert from format Branch format 7 to format <class 'bzrlib.branch.BzrBranchFormat6'>.    No converter
<james_w> really?
<james_w> man
<smoser> well i didn't just make up that error :)
<james_w> ok, let's try and trick it
<smoser> or if i did, it was convincing wasn't it
<james_w> well, it's pretty convincing if you did :-)
<james_w> bzr init-repo --rich-root-pack /tmp/testrepo
<james_w> bzr init  /tmp/testrepo/trunk
<james_w> bzr pull -d /tmp/testrepo/trunk .
<james_w> that will create a repository in the desired format, and then try and pull all the data in to it
<smoser> hm.. i think i'm missing something.
<smoser> what dir should i be in to start that?
<james_w> the branch you are trying to push
<james_w> "bzr pull -d /tmp/testrepo/trunk ." means pull . from /tmp/testrepo...
<james_w> you can cd and bzr pull the path to your current branch instead if you like
<smoser> hm... i think it worked.
<james_w> who promoted libgnumail-java-doc?
<pitti> james_w: me, on error; I put it back to universe
<pitti> since it sucks in classpath
<james_w> thanks
<pitti> we should instead blacklist it in the seeds or so
<james_w> I thought I was going crazy
<cjwatson> (extra-exclude is what you want)
<james_w> that's twice I demoted and it came back
<james_w> pitti: what tries to pull it in?
<pitti> james_w: it seemed like a simple thing at first (like the other -doc and -dbg that turn up all the time), I checked classpath too late; sorry
<pitti> james_w: there's a general seed rule to "rescue" *-dbg and *-doc
<james_w> ah
<pitti> so that we dno't have to explicitly seed the million -dev/-doc packages for main sources
<james_w> clever
<pitti> cjwatson: in "supported" for all derivatives, right?
<cjwatson> yes :-/
<soren> smoser: So you managed to push it in a format I can merge frm?
<smoser> james_w, thanks for your help... i dont think it all worked perfectly, as i tried to reproduce but failed.
<smoser> soren, i think so.
<soren> smoser: Where?
<smoser> soren, if not, i'll just manually cherry pick
<pitti> james_w: doing the seed changes now
 * james_w hugs pitti 
<smoser> soren, oh. wait. i hadn't done that yet. let me try
<soren> smoser: Where did you push it to?
<soren> smoser: Cool, thanks.
<pitti> cjwatson: out of interest, why doesn't that work in platform.karmic/supported-common?
<soren> smoser: Oh, did you base this on the ubuntu package branch of the ec2-init trunk?
<smoser> right
<smoser> wait
<cjwatson> pitti: it probably could be made to but I haven't tried. check it with germinate if you do
<smoser> i started from lp:ubuntu/ec2-init
<soren> smoser: Ah, ok.
<smoser> is that ok ?
<soren> I'm.... not sure.
<soren> james_w: Ok, here's the thing..
<soren> james_w: I maintain ec2-init in bzr.
<soren> james_w: smoser wanted to patch a few things, grabbed the lp:ubuntu/ec2-init branch and made some changes.
<soren> james_w: I like the changes, so I want them in the ec2-init trunk.
<soren> james_w: What's the magic incantation here?
<soren> james_w: If I just try to merge it, it tells me there are no common ancestors.
<james_w> soren: yeah, there aren't. It's one of the unfortunate things about the lp:ubuntu/* branches.
<james_w> making each of them mergeable with their respective upstream branches is a lot of work, so we deferred that part until later
<soren> james_w: There aren't common ancestors or there aren't a way to do this?
<soren> I understand the former, fwiw.
<mdz> soren, you can't merge them, but you can certainly get the changes from one place to the other. it is just extra work
<james_w> if you cherrypick it should work
<james_w> oh, no it won't
<james_w> the file-ids differ
<soren> mdz: Like "bzr log -c revno -p" or some such?
<james_w> it's diff and patch I'm afraid
<soren> mdz: Or do you have something more clever up your sleeve?
<mdz> soren, bzr diff -c revno | patch
<soren> Right, exactly.
<soren> That's about the same. :)
<soren> Only my way gives me the original changelog entry, but meh.
<soren> Ok.
<mdz> the changelog will probably conflict
<soren> mdz: Completely. The "upstream" branch has no debian/ dir.
<soren> smoser: I guess the lesson is: If it is expected to be pushed upstream, branch off of the upstream branch and then work downwards from that.
<soren> (/me hopes his directional metaphors make sense to other people)
<soren> mdz: I see we have a namespace collision :) My "original changelog entry" referred to the bzr one. I presumed you were talking about the debian changelgo?
<mdz> soren, I uploaded some (slightly sloppy) changes to eucalyptus overnight, and pushed them to what I guessed was the right branch
<mdz> soren, (yes, I was talking about the debian changelog)
<smoser> i'm somewhat bringing this up in #bzr... i started there with "how can i do what git-format-patch" and "git-am" do
<mdz> soren, have you looked at the changes?
<smoser> but of course, i was asked why i want to do that.
<soren> mdz: I have not, no. I noticed a new upload, and assumed the changes in bzr were just those, but I guess not.
<mdz> soren, the changes in bzr were just those, yes
<mdz> soren, or intended to be
<mdz> soren, I didn't have time to figure out whatever cdbs patch system variant was in use and just patched directly in the diff
<soren> mdz: You're not alone in doing so, fwiw.
<ttx> mdz: are you representing the server team in the release meeting or should I ?
<cjwatson> mdz: I uploaded a package including your change to the main archive a moment ago
<ttx> soren: I've been wondering about the rule to follow, then abandoned and did like the others
<cjwatson> mdz: I have to say I was unconvinced about your change, though. I was told that the component name given to --register-* was advertised to remote machines, and thus that "localhost" would actually break
<cjwatson> mdz: did you observe this not to be the case?
<cjwatson> mdz: (fwiw, "what-patch" is really handy to determine the patch system in use"
<cjwatson> )
<mathiaz> sgallagh: hi! Thanks for the notice
<mdz> cjwatson, in this particular case, we are registering walrus to the CC, and they are both running on the same system, which is why we are using "localhost"
<mathiaz> sgallagh: We won't upgrade sssd to 0.6.0 for karmic - this is probably work for lucid (the next version)
<mdz> cjwatson, the code forbade using "localhost" in all cases, even that one (which was working fine)
 * ttx scrambles to update ServerTeam/ReleaseStatus
<cjwatson> mdz,ttx: do we need to address bug 430841 for beta? I haven't noticed it being a problem in recent test passes
<ubottu> Launchpad bug 430841 in eucalyptus "after package install of eucalyptus-cloud, walrus, sc, only cloud service is loaded" [Medium,In progress] https://launchpad.net/bugs/430841
<ttx> cjwatson: I didn't walk into that one either
<ttx> but it's not targeted to beta (as of 30 minutes ago)
<ion> mterry: Hi. Please see bug #436323.
<ubottu> Launchpad bug 436323 in rsyslog "The kmsg dd job should use obs=1 to avoid delaying kernel messages" [Undecided,New] https://launchpad.net/bugs/436323
<ion> mterry: Hi. Please see bug #436323.
<ion> Ah, no ubottu link this time. https://launchpad.net/bugs/436323 :-)
<ubottu> Launchpad bug 436323 in rsyslog "The kmsg dd job should use obs=1 to avoid delaying kernel messages" [Undecided,New]
<YokoZar> ok so nm-applet just crashed, taking my internet connection with it (or possibly the other way around) -- apport was unable to upload the report, but is there a way I can get it again now that I'm back online?
<ion> apport-bug /var/crash/reportfile, or sudo touch /var/crash/reportfile
<ion> Make sure you have the latest network-manager-gnome package.
<YokoZar> ion: hmm it didn't like either of those commands
<YokoZar> wait nevermind
<YokoZar> mistyped
<YokoZar> apport will check for the latest version of that stuff and won't let you submit if you're outdated
<YokoZar> which is nice
<mdz> pitti, I can't figure out how to request merging of https://code.edge.launchpad.net/~mdz/apport/ec2-uec into the apport ubuntu branch
<pitti> mdz: "Propose for merging into another branch" doesn't work for you?
<pitti> it does here
<mdz> pitti, I don't know what to put in the box
<mdz> searching for "apport" finds too many matches, and searching for "apport ubuntu" or "apport karmic" finds nothing
<pitti> ah
<pitti> interesting problem
<mathiaz> slangasek: hi!
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<mathiaz> slangasek: image-store-proxy failed to build
<pitti> mdz: does lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ work?
<mathiaz> slangasek: https://launchpad.net/ubuntu/+source/image-store-proxy/1.0-0ubuntu1/+build/1258941
<dtchen> jdstrand: yes, i've got a fix for that ftbfs; just need to commit it
<pitti> mdz: (_everyone_ can type that by heart without errors, right?)
<dtchen> jdstrand: i'll ping sunday/monday for more testing
<mathiaz> slangasek: I've got fix here (add gnupg to the build dependencies)
<cjwatson> mdz: it may be (I'm not sure) that you can't request merge proposals from upstream branches to source package branches? in which case you'd need to push to ~mdz/ubuntu/karmic/apport/ec2-uec
<slangasek> mathiaz: then I think you should upload it? :)
<tkamppeter> pitti, I have done some fixes on s-c-p this week and they introduced bug 435740 and bug 436218. I have fixed these bug with very simple patches. Should these fixes go into the beta?
<ubottu> Launchpad bug 435740 in system-config-printer "system-config-printer.py crashed with UnboundLocalError in on_tvNPDevices_cursor_changed()" [Undecided,In progress] https://launchpad.net/bugs/435740
<cjwatson> probably best to stay in the same namespace if possible anyway ...
<ubottu> Launchpad bug 436218 in system-config-printer "system-config-printer.py crashed with AttributeError in fillMakeList()" [Undecided,In progress] https://launchpad.net/bugs/436218
<mathiaz> slangasek: right - just warning you since the archive is frozen
<mdz> pitti, that seemed to work, thank you
<pitti> mdz: IMHO, "ubuntu" should just work; it should just look for apport branches with that name, not branches of all projects..
<jdstrand> dtchen: ok
<jdstrand> dtchen: thanks
<pitti> mdz: btw, get_version() throws a ValueError for uninstalled packages
<seb128> slangasek, the locking issue is bug #428115?
<pitti> or, at least, it's supposed to
<ubottu> Launchpad bug 428115 in gnome-power-manager "Computer no longer locks on suspend or lid close" [High,Confirmed] https://launchpad.net/bugs/428115
<pitti> mdz: but I can fix that when merging
<seb128> slangasek, can you get specifics? gnome-session and indicator-session should be fixed in current karmic
<mdz> pitti, oh, sorry about that
<seb128> slangasek, if you still get the issue
<mdz> pitti, a simple is_installed check would be handy I think, maybe I should add that to hookutils?
<pitti> mdz: it could just go to apport/packaging.py, as a convenience method, indeed
<jml> cjwatson, hmmm.
<jml> cjwatson, I thought you could do that. I could be wrong though.
<jml> sometimes I think really loudly about a thing like that and believe that I did it.
<cjwatson> it was wild speculation based on mdz's reported problem :)
<cjwatson> but it sounds like he could make the merge proposal after all, it just didn't show up in the search ...
<mdz> jml, figuring out how to submit that merge request was really hard :-/
<jml> mdz, I'm sorry to hear that!
<jml> cjwatson, oh yeah, the "select a branch" widget is terrible.
<jml> beuno & I are advocating that we do less features in order to start cleaning up crap like that.
<pitti> tkamppeter: pleasea just upload it, we'll review it from the queue; if they are safe patches, they are fine to get into the beta
<cjwatson> jml: do less features> amen, in both our projects
* Cut-R changed the topic of #ubuntu-devel to: BANDES DE PEDOPHILES VIOLEURS MANIPULATEURS MENTEURS FILS DE PUTES ENCULÃS TROUS DU CUL MAGOUILLEURS ABUSEURS D'ENFANTS !!!
* Kmos changed the topic of #ubuntu-devel to: .
* elmo changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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"
<YokoZar> Does this https://bugzilla.gnome.org/show_bug.cgi?id=588733  count as a UI freeze nono ?
<ubottu> Gnome bug 588733 in Bookmarks "Please add a bookmark for Wine C:\ Drive (hidden unless Wine installed and configured)" [Minor,Unconfirmed]
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine/+bug/223989  rather
<ubottu> Launchpad bug 223989 in wine "wine: incorrect "Browse C:\ Drive" launcher" [Medium,Triaged]
<cjwatson> (better late than never)
<smoser> generic launchpad question
<smoser> a general launchpad/bug question
<smoser> bug 423497
<ubottu> Launchpad bug 423497 in vm-builder "Sudoers file is misconfigured in AMI ami-5059be39" [Medium,In progress] https://launchpad.net/bugs/423497
<smoser> it has vmbuilder task and ubuntu/vm-builder task
<smoser> it is fixed in vmbuilder upstream (the vmbuilder task), but that fix has not made it into a bundled release (only in bzr)
<smoser> so i think fix-commited is the right state for it
<smoser> what state should the ubuntu/vm-builder task be in ?
<pitti> smoser: usually, if a suitable fix is available, I set my bugs to "fix committed"
<sistpoty|work> it *should* be fix released :P
<pitti> it's a bit overloaded with "actually pushed the fix to my packaging branch", though
<smoser> pitti, thanks. sistpoty|work i'll work on that
<sistpoty|work> :)
<tkamppeter> pitti, new s-c-p uploaded, bug 435740 and bug 436218 updated.
<ubottu> Launchpad bug 435740 in system-config-printer "system-config-printer.py crashed with UnboundLocalError in on_tvNPDevices_cursor_changed()" [Critical,Fix committed] https://launchpad.net/bugs/435740
<ubottu> Launchpad bug 436218 in system-config-printer "system-config-printer.py crashed with AttributeError in fillMakeList()" [Critical,Fix committed] https://launchpad.net/bugs/436218
<zul> can someone approve the ec2-init I just uploaded? thanks
<slangasek> seb128: 428115> I wasn't running into it myself, I was setting the correct target based on the description of the bug and the fact that someone else referenced it.  Obviously if it's fixed, the bug should be closed
<seb128> slangasek, I've duplicated from the other one for now
<seb128> slangasek, if people still get the issue they can comment or reopen
<mdz> mathiaz, are you back home now?
<pitti> mdz: merged, fixed, uploaded to queue
<mdz> pitti, thank you
<mdz> pitti, it would be helpful to get that in for beta so that the bug reports are more useful
<pitti> right
<pitti> but I don't want to approve myself, I'll wait for slangasek to do that
<mdz> it only needs to go in the uec images, so it shouldn't cause anything else to be unnecessarily rebuilt
<mathiaz> mdz: yop!
<pitti> mdz: don't worry, it's not in the critical path; we just NEWed a kernel, still need to accept linux-meta, get a new d-i, etc.
<mdz> pitti, ok
<cjwatson> kernel NEWing is still in process
<cjwatson> d-i change is committed
<cjwatson> if somebody wants to do that while I'm out, they can upload what's in bzr, and then change the platform seeds to match
<cjwatson> but if nobody does, I'll be back in around four or five hours and will do it then
<pitti> I'll be off as soon as the meeting stops, too, sorry
<cjwatson> (Friday evening, what's that?)
<pitti> lool: why does liblauncher drop gtk-doc build stuff? no docs any more?
<sgallagh> mathiaz: ping
<mathiaz> sgallagh: hi
<lool> pitti: Yeah
<lool> pitti: 12:32 < lool> njpatel: dropping doc?
<lool> 12:32 < njpatel> lool: we didn't build docs for karmic anyway
<sgallagh> mathiaz: Just wanted to give you a heads-up. We're planning to take the current master of the SSSD repository as 0.6.0. I wanted to see if you would be willing to do a test build to make sure we didn't break anything obvious for you guys
<pitti> lool: ah, thanks
<mathiaz> sgallagh: I can give it a try
<mdz> smoser, do you have the ability to push a new version of vmbuilder into the place where it's used for the daily builds?
<mdz> or do we need to get you that permission?
<sgallagh> mathiaz: I can throw a tarball your way if you want (we fixed the autoreconf issue for you)
<mathiaz> sgallagh: although it's low priority for ubuntu as we won't update to 0.6.0 in Karmic
<mdz> mathiaz, glad you made it back
<smoser> mdz, i do
<mathiaz> sgallagh: I have a build infrastructure to build from master
<mathiaz> sgallagh: as I don't plan to push 0.6.0 into Karmic I don't need a tarball
<mdz> mathiaz, do you have the necessary hardware to install and test eucalyptus?
<mdz> mathiaz, and do you have a list of beta-critical issues you're working on, if any?
<mathiaz> sgallagh: I'll do a test with the released tarball
<smoser> i also recently disabled the nightly builds that were running as soren. now they run as the 'vmbuilder' user.
<sgallagh> mathiaz: Ok, if you're not planning on pulling it in (even post-release?), then there's no urgency
<mathiaz> mdz: I don't have the hardware at home - but I could ask cr3 if I can get some from the certification lab
<mathiaz> sgallagh: nope - we're in FeatureFreeze for now - so we won't update to new upstream releases that have new features
<mathiaz> mdz: I'm following up on the image-store-proxy package
<sgallagh> mathiaz: Fair enough. Good luck to you :)
<cr3> mathiaz: sorry, I wasn't listening, what hardware do you need?
<mathiaz> mdz: other than that I can help out with eucalyptus testing
<mathiaz> cr3: I'm looking for extra hardware to setup a cloud
<cr3> mathiaz: you want to drop by the office to test across a few laptops?
<cr3> mathiaz: I could have them imaged with ubuntu-server Karmic within 20 minutes
<mathiaz> sgallagh: thanks  - we'll look into the next version of sssd once we talk about the  plans for lucid (we should happen around november)
<mathiaz> cr3: how long can I borrowed them?
<mdz> cr3, the minimum requirement in two machines, one of which must have VT extensions
<sgallagh> mathiaz: When do you expect feature-freeze for Lucid?
<mathiaz> sgallagh: Feb 25th 2010 - https://wiki.ubuntu.com/LucidReleaseSchedule
<sgallagh> mathiaz: We're aiming for a 1.0.0 release sometime around February (hopefully) that will include FreeIPA client support as well. (There will be a 0.7.0 and 0.8.0 release at least between then and now)
<mathiaz> sgallagh: noted.
<cr3> mathiaz: how long would you need 'em?
<mathiaz> cr3: probably until beta
<cr3> mathiaz: I'll have to ask marjo for that
<mathiaz> cr3: actually what I really need is a laptop with vt extensions
<mathiaz> cr3: ie *one* laptop with VT extensions
<cr3> mathiaz: I think marjo will be alright with that, but I'll inform him for good measure
<mathiaz> cr3: great - I'll stop by later today and get one of them
<mathiaz> mdz: so I should be able to setup a cloud today
<cr3> mathiaz: coolio, it'll be imaged by then with a nice bow tie around it
<mathiaz> cr3: chocolates and champagne is also very much appreciated
<cr3> mathiaz: I think TeTeT brought some chocolates from Germany, so all we're missing is the bubbly
<cr3> mathiaz: I didn't realize testing eucalyptus had so many requirements, maybe I should've volunteered for that testing instead of davmor2
<pitti> # Automatically added by dh_installinit
<pitti> update-rc.d -f gdm remove >/dev/null || exit $?
<pitti> oops, sorry
<lool> slangasek: bjf told me that kernel team was working on the kernel trees and that ARM kernels had been rebased and probalby three uploads would happen today
<ogra> wohoo
<lool> slangasek: On EC2 he told me people are currently locked in a room until everything works or death
<lool> But not clear on a kernel upload
<asomething> hey all, got a couple questions/requests for the archive-admins
<asomething> First, could someone explain why lua-gtk_0.9+20090719-1ubuntu2 was rejected.
<sladen> asomething: rejected, or just held?
<sladen> asomething: universe is in manual mode, but it should get done
<asomething> sladen, actually rejected
<asomething> only reason given was "Rejected by archive administrator."
<asomething> http://paste.ubuntu.com/278110/
<pitti> I'm innocent of that
<pitti> smoser, soren, zul: just as a heads-up, ec2-init promoted now; due to some soyuz itch it _might_ be possible that the build will become "failed to upload"; in this case, please wait an hour and retry the build (on https://launchpad.net/ubuntu/+source/ec2-init/0.4.999-0ubuntu2/+build/1261482)
<zul> pitti: thanks for the heads up
<pitti> (details: it sometimes doesn't like when a package gets promoted while it's being built)
<pitti> so it thinks the packages should go to universe, but underneath it moved to main
<pitti> but the next build will succeed
<pitti> zul: I'm about to go out, can you watch this, please? You'll get soyuz mail if it fails
<zul> pitti: of course
<pitti> thanks
<pitti> so, over & out
<asomething> it already build-depends on libclutter-1.0-dev not 0.8, so the upload only changes the binary depends from libclutter-0.8-0 to libclutter-1.0-0 (see: (LP: #364630)
<smoser> i have a debhelper question.  i have an init script 'ec2-init-user-data'. it is one of 2 in the package. the other is installed by install into /etc/init.d and is recognized by cdbs as an init script, and uses DEB_UPDATE_RCD_PARAMS appropriately
<smoser> is it possible for me to have a second init script that is not in debian/ ? and use dh_installinit to install it ?
<smoser> ideally i'd add it to the package install system to install into /etc/init.d (like the "main" init script is), and then tell dh_installinit to pick it up there.
<lool> Not in debian/?  Dont think dh_installinit can do that
<smoser> thats how it appeard to me
<smoser> but i thought, maybe since the main script was not there, and was "found" i could use something like that
<lool> smoser: I'm not sure of which cdbs feature you mean here
<lool> smoser: DEB_UPDATE_RCD_PARAMS is passed to dh_installinit by CDBS
<smoser> right
<smoser> so right now my package has 1 install script. 'ec2-init'. it is installed by the setup.py into /etc/init.d/ec2-init
<lool> Ok
<smoser> *something* recognizes that as an init script and magically installs it, using the DEB_UPDATE_RCD_PARAMS
<smoser> i want to add a script
<smoser> i can add it to debian/my-script and use dh_installinit
<Keybuk> NCommander: sorry, but SPARC is quite high on the list of "things I don't care about"
<smoser> but i would rather keep it like the first script (installed by setup.py) and then use dh_installinit for it
<lool> smoser: Hmm dh_installinit should only do stuff if you pass an init script to install to it
<lool> smoser: Do you have a .dsc somewhere?
<smoser> (since it would run at different order, i figure i would have to tell dh_installinit of that new order explicitly for it)
<ogra> Keybuk, wow, you priorize on that list ?
<lool> smoser: Gah it's getting late here -- bath and dinner
 * ogra doesnt
<ogra> would mean i need to care to much for things i dont actually care for :)
<lool> smoser: Do you ming switching to slangasek for sponsoring if I dont get back to you on your next ping?
 * lool &
<smoser> sure.
<smoser> lool, bzr branch lp:ubuntu/ec2-init
<NCommander> Keybuk, I realize that, but I filed the bug so at least its a known issue. If I had time, I'd track it down and give you the patch on a silver platter
<Keybuk> NCommander: yes, but "High" is not a priority I would have picked ;)
<NCommander> Keybuk, I use priority on the impact of the bug; I think preventing systems from booting is High (I almost went to Critical, but I decided that SPARC isn't a large enough userbase to warrant it)
<smoser> lool, you're certainly entitled to not paying complete attention to me
<Keybuk> that's not what priority is intended for
<Keybuk> priority is actually really well defined
<ogra> Keybuk, did he milestone it too *grin*
<Keybuk> and is based on such factors as how many users are affected
<Keybuk> after all, every bug is critical for the user affected by it
<Keybuk> or every upstart bug in *some way* affects booting
<Keybuk> ogra: he did, yes
<ogra> heh
<asomething> Request two for an archive-admin is could someone accept exaile in binary NEW? As it's the default music player for Xubuntu, it would be good to get that version on the beta CDs.
<NCommander> Keybuk, I'll bump it down to Medium then if you feel High is too High.
<ogra> Keybuk, btw, do you have a wikipage or something for people using init=/bin/bash that want to start basic services by hand now that initscripts are gone ?
<Keybuk> NCommander: I've set it to Low.  Please leave it there
<ogra> its hard to debug things if you cant start the services anymore
<sladen> ogra: service foobar moo
<ogra> sladen, nope
<ogra> requires upstart to run
<Keybuk> ogra: you can't do that
<sladen> ogra: only I haven't worked out how you're supposed to start upstart, in order for 'service' to work
<ogra> right
<ogra> that was my prob this week :)
<sladen> I meant to file the cyclic loop (hit it during the ultimate black boot of doom)
<smoser> mdz, i verified the build of vmbuilder with the seeds patch outputs the same packages as it previously did
<Keybuk> sladen: cyclic loop?
<sladen> Keybuk: something like  'service upstart start' suggesting you start upstart
<Keybuk> sladen: that's already fxied
<sladen> Keybuk: or maybe it was  /etc/init.d/upstart start  suggesting to use 'service'
<smoser> the only difference is we lost 'curl'.  this is probably due to it being previously only present as a dependency of ec2-ami-tools (which was dropped).  but i think we probably want it. so we need to add that to the seeds.
<smoser> err, seed.
<ogra> Keybuk, oh, so you can start upstart from init=/bin/bash ?
<ogra> good to know
<Keybuk> ogra: exec /sbin/init
<ogra> ok
<Keybuk> ogra: usually I do init=/bin/bash
<Keybuk> stick something like
<Keybuk>   start on startup
<sladen> Keybuk: and then what happens to my console?
<Keybuk>   console owner
<Keybuk>   exec /bin/bash
<Keybuk> and then exec init
<Keybuk> so I get a shell
<ogra> well, my prob was that upstart hung in my armel VM
<ogra> so i couldnt use an upstart job :)
<Keybuk> then --debug is your friend
<ogra> exec /sbin/init is indeed brilliant :)
<sladen> Keybuk: so upstart abolutely, positvely, must be pid=1
<Keybuk> sladen: yes
<Keybuk> ogra: you can also do
<Keybuk> init=/bin/bash
<Keybuk> then openvt sulogin
<Keybuk> exec /sbin/init --debug
<ogra> ok, noted down
<Keybuk> you get a bash on vt2 with init as pid 1 and debug on tty1
<sladen> Keybuk: so if upstart sees itself being execed (eg. argv[0] == /bin/bash) it should just "do the right thing", start itself and give a kernel back
<Keybuk> sladen: I don't follow
<Keybuk> if you're saying what I think you're saying, there's reason you can't do that ;
<sladen> Keybuk: and if upstart is run from pid != 1 it should print some useful message about "running 'exec $argv[0]'"
<Keybuk> :)
<sladen> Keybuk: when I have a system that is *so* in a knot that I'm doing /bin/bash, having to cat six lines accurately from memory just to get a shell again seems .. unavoidable
<sladen> Keybuk: upstart could just internally know if run that job if I'm running it from init=/bin/bash
<sladen> s/if run/to run/
<lool> smoser: FYI
<lool> E: ec2-init: init.d-script-does-not-implement-required-option /etc/init.d/rightscale-init restart
<lool> E: ec2-init: init.d-script-does-not-implement-required-option /etc/init.d/rightscale-init force-reload
<Keybuk> if you do init=/bin/bash and exec /sbin/init, both the original bash and init are pid 1
<Keybuk> if you run init in a way that means it's *not* pid 1, it behaves as if you ran telinit
<Keybuk> for lynx, "init 3" will start outputting a "STOP THAT!" error message but still call telinit
<Keybuk> post-lynx, I'll drop support for init-pretends-to-be-telinit
<Keybuk> (at least, maybe - I may not be able to ever drop support for that)
<Keybuk> now
<lool> smoser: and W: ec2-init: script-calls-init-script-directly ./etc/init.d/rightscale-init:74
<Keybuk> if init is pid 1
<Keybuk> and argv[0] was bash
<Keybuk> you might think that you could say "ah, we're being debugged"
<Keybuk> and give them a shell back
<sladen> eg. with fairly simple heuristics, upstart can tell and/or do what I probably(tm) want to do
<lool> smoser: and others  :-/
<Keybuk> but that doesn't work
<Keybuk> because init is *always* exec'd by /bin/bash
<Keybuk> because the initramfs is a shell script
<Keybuk> and init is exec'd by the initramfs, not by the kernel
<Keybuk> sladen: I'd rather spend the effort making sure that you can't get the system into such a hole
<Keybuk> than coming up with creative debugging strategies
<smoser> lool, well many of those have been addressed
<smoser> for one, rightscale-init is gone
<smoser> so that covers all those you listed.
<lool> smoser: Ok, just looking at the branch you pointed at
<sladen> Keybuk: I'm hopefully that upstart can at least offer a --help to say how to get it up and running (eg. the   start on startup ... owner console  lines above)
<lool> smoser: Ok so what's your goal?
<Keybuk> sladen: again, I'm uninterested in that
<smoser> yeah, it will be updated shortly.
<lool> smoser: Or issue?
<smoser> i want to add a script 'ec2-add-user-data'
<smoser> that runs at init
<Keybuk> if upstart itself is so broken that it can't start a single job, it is out of the ability to document for most people to work out how to fix it
<smoser> and ideally, not have it in the debian/ directory
<Keybuk> if upstart *can* start a single job, then there are better solutions
<sladen> Keybuk: right, but the fact that other (reasonably competant) people are asking about it demonstrates the use-case
<lool> smoser: Ok; can you do the same thing as the rightscale-init dh_installinit call, but with -o?
<Keybuk> e.g. the proposal that kernel command-line options are jobs to be started
<smoser> handled just like ec2-init is (installed by setup.py)
<Keybuk> so if you booted with "emergency" on the command-line, the /etc/init/emergency.conf job would be started automatically
<Keybuk> and that could be shipped by all distributions to give a shell on the console
<smoser> lool, yes.
<smoser> thank you
<smoser> i think thats right
<sladen> Keybuk: the probably (eg. black screen of doom) was that jobs *were* being started
<lool> smoser: Oh eh np
<smoser> sorry for missing that.
<sladen> problem
<Keybuk> sladen: indeed, so init=/bin/bash wasn't necessary
<lool> smoser: I'm going for dinner; good luck on vmbuilder!
<lool> slangasek: ^  sorry that I only hanged around for that long
 * lool &
<ogra> Keybuk, what about initramfs, is that needed for upstart to function ? my VM didnt have one and i thought that might be an issue
<sladen> Keybuk: maybe ... but it was the expected low-level debugging approach
<ogra> though i couldnt really debug due to lkacking knowledge
<sladen> (and I didn't have net access to go googling at that point)
<Keybuk> ogra: no
<Keybuk> ogra: I test upstart without an initramfs
<ogra> ok
<Keybuk> (indeed, I have it as a GRUB option on this mini)
<ogra> good to know, i wasnt sure it requires anything thats mounted or created in initramfs
<Keybuk> it shouldn't do
<ogra> Keybuk, thanks for the insight ... :)
 * ogra goes to dinner as well now
<Keybuk> Upstart does use a few devices in /dev though
<Keybuk> so if you're missing those, it gets a bit grumpy
<ogra> ah, my VM had only a basic debootstrap run
<Keybuk> that should still have /dev/console, /dev/null, /dev/fd, etc. in /dev ;)
<directhex> argh. my audio's disappeared
<ion> keybuk: This might be a regression with the conversion from an init script to an Upstart job. https://bugs.edge.launchpad.net/ubuntu/+source/rsyslog/+bug/436323
<ubottu> Launchpad bug 436323 in rsyslog "The kmsg dd job should use obs=1 to avoid delaying kernel messages (dup-of: 430220)" [Undecided,New]
<ubottu> Launchpad bug 430220 in rsyslog "[karmic] Upstart fixups" [Undecided,New]
<ogra> indeed
<directhex> which means either the motherboard's gone haywire, or karmic
<Keybuk> ubottu: I think that mterry was already fixing that
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Keybuk> ion: I think that mterry was already fixing that
<ogra> anyway ... i'm off
<Keybuk> ogra: the /dev/fd -> /proc/self/fd is optional though
<Keybuk> it can just pass the script to bash directly
<Keybuk> likewise accesing /proc is optional
<ogra> ok
<Keybuk> unless the service has oom_adj set
<Keybuk> basically it should be possible to start a job taht mounts /proc and /dev
<ogra> right
<jdong> hmph, looks like debian bug 540786 afects us too (unsurprisingly)
<ubottu> Debian bug 540786 in grub-common "[grub-common] update-grub/grub-mkconfig doesnt work with btrfs as rootfs" [Normal,Open] http://bugs.debian.org/540786
<mterry> Keybuk: i fixed it.  i've been waiting for you(someone) to push it
<Keybuk> mterry: oh, I didn't know that
<Keybuk> are you not a core-dev?
<mterry> Keybuk: sorry.  that's why i brought it up in that meeting.  no you fool.  I just got motu yesterday.  :)
<Keybuk> heh
<Keybuk> I can't upload anything until next week though
<mterry> Keybuk: k, no rush (on my end)
 * robbiew finds it funny that mterry was on the MIR team BEFORE making MOTU
<mterry> yeah, i got some questions about that during the motu meeting....
<NCommander> Keybuk, just as a random sidenote, do you know what in upstart could cause the system to automatically restart after its configured?
<Keybuk> NCommander: what system?
<Keybuk> after what is configured?
<NCommander> Keybuk, my SPARC box restarts automatically when I upgrade or downgrade upstart on SPARC
<NCommander> (the behavior been seen on other sparcs in karmic as well)
<Keybuk> NCommander: neat
<Keybuk> no ida
<Keybuk> kernel panic maybe?
<NCommander> Keybuk, no, it says "Sending SIGKILL to all processes", which suggests the runlevel was changed to 6
<NCommander> (or SIGTERM)
<Keybuk> no idea
<Keybuk> initctl log-priority debug
<NCommander> Keybuk, thanks anyway. If I crack it, I'll fire a patch your way
<Keybuk> NCommander: have you tried running "make check" on SPARC?
<NCommander> Keybuk, isn't the test suite run at build time? (I remember upstart/sparc was FTBFSing for a long time on that)
<Keybuk> NCommander: no, because the buildd environment is quite broken
<NCommander> ah
<NCommander> I'll do that in a moment then
<Keybuk> I run the suite, but it won't fail the build
<Keybuk> ===============================================
<Keybuk> 4 of 17 tests failed
<Keybuk> Please report to upstart-devel@lists.ubuntu.com
<Keybuk> ===============================================
<Keybuk> and that's just in libnih
<sladen> Keybuk: can you fill in the missing "Technobable" sections on  http://upstart.ubuntu.com/wiki/OMGBroken  and check I've got the rest correct
<Keybuk> lots of "Bus error"
<NCommander> Keybuk, that suggests a compiler or alignment error :-/
<Keybuk> sladen: I don't recommend "service"
<Keybuk> the canon way to start an Upstart job is using "start"
<sladen> Keybuk: groovy
<sladen> Keybuk: done
<Keybuk> looks like the tests that failed were
<Keybuk>  timers
<Keybuk>  file reading
<Keybuk>  inotify
<Keybuk>  main loop handling
<Keybuk> they seem pretty critical ;)
<mterry> Keybuk: you don't recommend service?  cjwatson was saying we were converging on service and to avoid start...
<Keybuk> mterry: I absolutely don't recommend using service
<mterry> Keybuk: sigh
<sladen> bike-shedding.
<Keybuk> what's the point of using a wrapper shell script for our own init daemon?
<sladen> Keybuk: an argument might be discoverability
<sladen> Keybuk: if you know the word 'service', you can work through the help
<Keybuk> if you know the word 'start' you can work through the help
<sladen> service has been around longer...
<Keybuk> not in Ubuntu
<Keybuk> start has been in Ubuntu longer than service
<Keybuk> it's fine to *have* service for users that are used to it
<Keybuk> but our own documentation, maintainer scripts, etc. that are written knowing that something is an Upstart job should just use the Upstart-native commands
<Chipzz> if anyone wants my 2c: start has a heavily overloaded meaning, and I don't think it makes sense to monopolize it for upstart...
<Chipzz> but then, that's just my 2c
<Keybuk> it's the init daemon
<sladen> an implemtnation of
<Keybuk> it's the only one we support
<Chipzz> Keybuk: but... start what? start a service? start a program? ... ?
<Keybuk> in fact, it's the only one that even *works* in Ubuntu
<Keybuk> Chipzz: yes, all of the above
<Keybuk> case in point
<Chipzz> Keybuk: ./someprog is not the same as starting a service :)
<sladen> I think we need to do some PR if 'start' is still the preferred;  I had indirectly presumed it was being phased out
<Keybuk>  /etc/init/hwclock.conf is a *task* not a service
<Keybuk> "start hwclock" will start the task and wait for it to compelte
<Keybuk> sladen: I utterly reject that notion; if people are telling you that, tell them to talk to me
<mterry> Keybuk: do we care much if things are calling (compatibility) init scripts?  when do we see those going away?
<mterry> Keybuk: (i meant init.d scripts)  :)
<sladen> Keybuk: nobody had, had just presumed it from seeing emails/documentation etc.  I'll be on the look-out now to correct people who are WRONG, just as vermantly as on Wikipedia!
<Keybuk> mterry: sure, you can use service for init scripts
<Keybuk> that's certainly more correct than using invoke-rc.d ;)
<Keybuk> which is just WRONG
<sladen> Keybuk: now, back to http://upstart.ubuntu.com/wiki/OMGBroken  where should this console job snippet be catt'ed to
<Keybuk> sladen: /etc/init/somewhere.conf ?
<mterry> Keybuk: naw, i meant, something directly calling /etc/init.d/blarg.  when do we see that going away?  when we can do a grep and nothing calls it? :)
<mterry> Keybuk: (for something that has been converted to an upstart task)
<sladen> Keybuk: /etc/init/bash.conf
<Keybuk> mterry: I figure post-lynx for the current set
<Keybuk> sladen: I'd use exec openvt sulogin rather than bash
<mterry> Keybuk: k
<Keybuk> then you don't need the console owner
<Keybuk> than you won't break if someone uses (e.g.) cryptsetup
<mathiaz> kees: hi!
<kees> mathiaz: heya :)
<mathiaz> kees: how do you debug build failure that occurs on the buildd but not in your local sbuild?
<mathiaz> kees: https://launchpad.net/ubuntu/+source/image-store-proxy/1.0-0ubuntu2/+build/1261481
<mathiaz> kees: ^^ this builds correclty in my schroot+sbuild environement
<kees> mathiaz: I make my local sbuild as close to the buildd as possible, and compare buildlog output for clues.
<kees> mathiaz: you can also try it on the porter machines
<mathiaz> kees: ah the porter machines
<mathiaz> kees: I was trying to use PPA, but the turn around is a bit... long
<kees> heh, yeah
<sladen> Keybuk: how to start upstart such that it starts *just* the daemon, but then doesn't bring up any (eg. framebuffer trashing) deafult jobs?
<kees> I would also check the specific test failure:
<kees>     testCheckImageSignatureWithBadSignature ...                         [ERROR]
<mathiaz> kees: right - I know what my be wrong
<kees> if that requires external network connectivity, for example, it will fail on buildds but not for your sbuild
<mathiaz> kees: but I'd need more output
 * kees nods
<kees> see if you can make it fail on the porter machine; that's usually one way to get it.
<Keybuk> sladen: currently can't, it's on the TODO
<sladen> Keybuk: what's a good work-around?
<sladen> Keybuk: grep the 'exec' lines out of the job files and then run those in the background?
<sladen> Keybuk: but thne upstart won't be running and won't need to be
<mathiaz> kees: can you use sbuild on the porter machines?
<kees> mathiaz: no, one just builds it manually with debuild inside the chroot
<sladen> ogra: append anything you come across to http://upstart.ubuntu.com/wiki/OMGBroken
<sladen> Keybuk: http://upstart.ubuntu.com/wiki/Stanzas?highlight=%28%28onalso%29%29  is that intentional?
<sladen> Keybuk: http://upstart.ubuntu.com/wiki/Stanzas?highlight=onalso  is that intentional?
<slangasek> lool: no worries
<slangasek> kirkland: please don't triage freeze exception bugs
<kirkland> slangasek: whoops...
<slangasek> kirkland: we use the status fields differently for process bugs
<kirkland> slangasek: which one is it?
<slangasek> kirkland: the eucalyptus UI freeze exception one... I'll fix this one up myself, just letting you know for future reference :)
<kirkland> slangasek: thanks, sorry, was inadvertent
<kirkland> slangasek: mdz asked me to triage some 60+ eucalyptus bugs
<kirkland> slangasek: i got trigger happy
<slangasek> kirkland: yep, was aware of that, so if you already know the rules ignore me :-)
<kirkland> slangasek: perhaps these should have another task, just associated with Ubuntu
<kirkland> slangasek: such that i can triage the bug against the package appropriately
<kirkland> slangasek: and you release team guys can have your own status line associated with ubuntu to do what you want with
<slangasek> kirkland: I disagree, because a) the bug report exists solely for processing the exception, b) we do often have multiple packages related to a single freeze exception that may need to be reviewed separately
<slangasek> kirkland: but if we need to discuss that further, let's please take it to ubuntu-devel (where there've been threads about this recently)
<kirkland> slangasek: fair enough; i don't care enough to discuss further, particularly if you've already thought about this :-)
<kirkland> slangasek: i'll take my smackdown and get back to work :-)
<zul> can someone push through m2crypto as well? Thanks
<kees> mvo: uhm "Third party sources disabled" in update-manager seems to remove my local mirror.  In past releases it would just rename rel-1 to rel...
<mvo> kees: do you have local-mirror + normal sources.list entires? could you mail me the /var/log/dist-upgrade/main.log when that happend?
<kees> mvo: ah, yeah, I did have local + normal (to catch stuff newer than my local mirror)
<kees> mvo: I manually worked around it, but I can send logs
<mvo> kees: I think that is the problem, if you disable "normal" it will assume you are on a local mirror
<mvo> kees: but if its mixed it does not known what is a mirror and what is a third party source. I think this should be made cleverer (but it has not changed in a while)
<mvo> (IIRC at least ;)
<kees> mvo: okay, well in this case, I will blame it on my crackful sources.list.  :)  sorry for the noise!  sounds like the existing logic is just fine.
<mvo> kees: thanks
<kirkland> slangasek: uh, oh, i did it again, https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/424368
<ubottu> Launchpad bug 424368 in eucalyptus "[FFE] local node discovery, debconf improvements" [Critical,Triaged]
<kirkland> slangasek: moving back to confirmed.  sorry.
<sistpoty> anyone got an idea why i get this from pbuilder (when trying to extract the source with dpkg-source): gzip: stdout: Broken pipe
<sebner> sistpoty: b0rken archive?
<sistpoty> huhu sebner
<sistpoty> sebner: I somehow doubt that (or hope that its not true *g*)
<mdz> smoser, ping
<smoser> here
<mdz> smoser, how current is the current uec image on uec-images?
<mdz> (20090925)
<mdz> does it include the kernel modules, was it built with the seed-using version of vmbuilder, etc.?
<sistpoty> sebner: interesting, seems that I just had a broken chroot... works fine now :)
<smoser> midnightish utc
<smoser> mdz, it does contain kernel modules, but was built without seeds
<mdz> smoser, is it worth rolling a new one with the latest vmbuilder + the latest bits from the archive right now?
<mdz> slangasek, I would like to get an additional person set up to be able to trigger server ISO builds if that's OK
<smoser> i built with the seed changes prior to checking them in. that would have been probably 16:00 UTC. i have a diff of the manifests
<smoser> if you want to see them.
<smoser> i'm fine to re-spin it if you want, but it'll build automatically at midnight or so utc
<mdz> smoser, anything alarming in the diff?
<smoser> i sent in mail on UEC images thread.
<smoser> shoot
<smoser> i realize i didn't hit send
<smoser> just now did. i dont know why i postponed it
<smoser> but anyway, the only difference that wasn't to be expected was curl and libcurl dropped
<mdz> smoser, great, let's spin a new daily
<smoser> as in now? or in 4 hours?
<smoser> mdz^
<sebner> sistpoty: this would have been my next guess :) Glad that it's fine now =)
<slangasek> mdz: that means getting them access on antimony; I don't have any objections
<mdz> slangasek, so the first step is to file an RT asking for them to get access to antimony?
<slangasek> mdz: yes
<mdz> smoser, any reason to wait?
<mdz> smoser, we could start downloading it right away and use it in our tests here
<mdz> smoser, by the way, is it rsyncable?
<smoser> it shoudl be, yes.
<mdz> slangasek, filed
<smoser> and its building now
<mdz> slangasek, meanwhile, is our new ISO ready with this morning's eucalyptus?
<mdz> smoser, can you give me the URL for the branch of vmbuilder which is used for the daily builds?
 * cjwatson returns
<smoser> https://wiki.ubuntu.com/UEC/Images/Testing indicates rysncable and as i recall it worked well
<smoser> mdz, its trunk. bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/trunk/
<mdz> smoser, thanks
<smoser> or lp:~ubuntu-virt/vmbuilder/trunk vmbuilder
<slangasek> mdz: yes: http://cdimage.ubuntu.com/ubuntu-server/daily/20090925.2/
<mdz> slangasek, thanks
<cjwatson> mdz: is there anything I can do that isn't going to cause me to be up into the wee small hours? :)
<mdz> smoser, I still don't see that email from you
<mdz> cjwatson, we're rsyncing the latest image to test and verify your fixes from earlier today
<mdz> cjwatson, dustin has triaged the eucalyptus bug list; I'd appreciate it if you could eyeball it and see if there's anything which jumps out at you
<kirkland> cjwatson: sorry to bother, could you take a look at bug #424368, and update accordingly?
<ubottu> Launchpad bug 424368 in eucalyptus "[FFE] local node discovery, debconf improvements" [Critical,Confirmed] https://launchpad.net/bugs/424368
<smoser> mdz,
<smoser> Subject: Re: New seeds for UEC images
<smoser> Date: Fri, 25 Sep 2009 16:39:31 -0400 (EDT)
<smoser> i have to run. I'll check back in later tonight.
<smoser> mdz, build should appear http://uec-images.ubuntu.com/karmic/20090925.1 very soon
<mdz> smoser, I don't see it on https://lists.ubuntu.com/archives/ubuntu-devel/2009-September/thread.html
<mdz> smoser, are you sure you sent it to ubuntu-devel?
<smoser> it did not
<mdz> oh, you sent it privately. nm.
<smoser> none of that thread did. ijust responded to it.
<smoser> mdz, url above is populating now
<smoser> i'm out for the night
<smoser> will check back in ~ 01:00 utc
<cjwatson> kirkland: I suspect that can be closed, unless you're aware of anything more that needs to be added
<cjwatson> it's more effectively tracked in separate bugs at this point anyway
<mdz> smoser, thanks
<mathiaz> slangasek: I've uploaded a new version image-store-proxy that disables the failing tests
<mathiaz> slangasek: I've filed bug 436896 as well to fix them later
<ubottu> Launchpad bug 436896 in image-store-proxy "Signature tests are disabled" [High,Confirmed] https://launchpad.net/bugs/436896
<cjwatson> kirkland: I've closed it now
<kirkland> cjwatson: thanks a lot
<mdz> smoser, I'd like to get this image tested on EC2 before the weekend
<smoser> mdz, i can try to push and register tonight.
<smoser> i really, really would like to get that stuff automated from the data center :-(
<cjwatson> mdz,kirkland: there's a heck of a lot of unreleased stuff in eucalyptus bzr now due to kirkland being a machine. do we want to get that in for the next CD build, or is it too risky? I haven't looked at all (or even most of) the changes
<kirkland> cjwatson: i'm going to build it locally here and test
<mdz> cjwatson, it's not tested yet but we do want it in an image as soon as that's done
<cjwatson> ok - I committed another minor bug fix since your updates, so update
<cjwatson> ok
<kirkland> cjwatson: yeah, i just merged/resolved the conflict on that one :-)
<mdz> smoser, is there anything you need in order to make that happen (automating) other than time?
<kirkland> cjwatson: i also added a Conflicts: apache2-mpm-itk
<cjwatson> hah
<cjwatson> no harm in both, as the bug says
<mdz> cjwatson, I assume there will be a new build once linux-meta is ready?
<kirkland> cjwatson: oh, i did have a question for you about Bug #436199
<ubottu> Launchpad bug 436199 in eucalyptus "display admin URL on boot" [Wishlist,Fix committed] https://launchpad.net/bugs/436199
<kirkland> cjwatson: i solved that with an update-motd script putting a url in the MOTD
<kirkland> cjwatson: i'm using the ip address for the url rather than the hostname
<kirkland> cjwatson: i was wondering if you had suggestions on a better way of doing that
<kirkland> cjwatson: see debian/80-eucalyptus-url in lp:~ubuntu-core-dev/eucalyptus/ubuntu/
<cjwatson> meh, just use IP for now, no time for cosmetics
<cjwatson> mdz: I'll be asleep by then, I should think
<mterry> cjwatson: dh7 question: let's say I have a simple package for a program.  It used to use cdbs/debhelper.  It has one main package and a -dbg package, didn't use .install files.  cdbs did the -dbg work magically.  Does dh7 have a toggle to allow it?  I tried naively porting the package to dh7, but the dbg stuff wasn't happening.
<cjwatson> I think you just need something like:
<cjwatson> override_dh_strip:
<cjwatson>         dh_strip --dbg-package=foo-dbg
<mterry> cjwatson: yup, did that.  But I have to make my own install file then?
<slangasek> shouldn't, no
<cjwatson> no, that should cause dh_strip to put the files in the appropriate build directory all by itself
<mterry> hm
<cjwatson> you don't generally need dh_install to act on the results of other debhelper commands
<mterry> Maybe I'm doing something stupid then.   But the theory is just the strip override should be enough, it sounds like
<cjwatson> DH_VERBOSE=1 is a good general debugging tool
<mterry> k
<cjwatson> mdz: also waiting for new d-i, if we're having new linux-meta in the next build
<hikenboot> can anyone tell me how large the ubuntu 9.04 repositories are i am using apt-mirror to download them
<jpds> IIRC, less than 400GB
<hikenboot> gee wiz....that might be too much to download comcast might shut me off
<jpds> Oh, wait, just 9.04, not sure.
<jpds> That was the whole archive.
<slangasek> Riddelll: your kdebase-workspace conversion doesn't remove the old conffile in the preinst
<wgrant> lamont: I have a smallish launchpad-buildd change that needs to happen at some point soonish. I believe you're the person to which I must talk.
#ubuntu-devel 2009-09-26
<uni4dfx> why is launchpad broken? are bug reports no longer appreciated?
<tormod> uni4dfx, file them using "ubuntu-bug"
<uni4dfx> and if i wanna do a needs-packaging bugreport?
<slangasek> Riddelll: the new upstart job also still sets the 'HEED_DEFAULT_DISPLAY_MANAGER' variable, but doesn't honor it
<slangasek> nixternal: ^^ this script has your name on it, maybe you can have a look at these?
<sladen> hikenboot: you should be able to avoid getting cut-off by comcast if you download and mirror it via your cell-phone provider package
<nixternal> throw it out
<nixternal> ;p
<slangasek> nixternal: hum?
<cjwatson> uni4dfx: several of us have complained about this. In the meantime, you can use +filebug?no-redirect instead of +filebug in your URL
<nixternal> ya, it shouldn't have my name in it, but upstart didn't like a "" there
<cjwatson> uni4dfx: (there are instructions in the page it redirects you to - they're just a bit buried)
<wgrant> Alternatively, just use production.
<wgrant> That doesn't have the redirect turned on.
<nixternal> slangasek: right, I am pretty positive that can be removed, as it was magic candy "back in the day"
<wgrant> Unless they turned it on in the re-rollout a few hours ago.
<slangasek> nixternal: right; I'm more interested in finding someone with a Kubuntu hat to take responsibility for making such changes :)
<cjwatson> uni4dfx: wgrant may countermand this, but I'd recommend filing a bug so that your use case is recorded as another problem with this redirect
<uni4dfx> and if i'm trying to report a bug that is related to a plugin - ergo it doesn't have its own PID
<slangasek> (I could throw it out, but I have 20 more packages in the freeze queue to get through today...)
<nixternal> slangasek: I can do it, but will throw it at Riddelll right now since he was the last one messing with it...if he yells at me to do it then I shall :)
<wgrant> cjwatson: I would have thought that Keybuk's all-caps rant would be enough, but apparently not.
<cjwatson> wgrant: which was apparently dealt with by "let's identify some of the people who complain and special-case a team"
<cjwatson> I wasn't going to object to that since it made some of the problem go away, but it *was* rather missing the point
<cjwatson> uni4dfx: the other case close to my heart is a bug saying "I had the following problems that made me unable to install Ubuntu"
<cjwatson> uni4dfx: anyway, you have a workaround now
<wgrant> cjwatson: Or 'ubuntu will not boot any more'
<uni4dfx> yeah but i wanna do it properly :P
<cjwatson> complying with an arbitrary edict isn't necessarily quite the same as "properly" :-)
<cjwatson> well, ok, experiment not edict
<wgrant> cjwatson: Yesterday the bug supervisor exclusion was very nearly removed from source packages, but I fortunately noticed that and had it fixed.
<wgrant> Anyway, hopefully this experiment will terminate soon.
<uni4dfx> btw, something like this should be added to the wiki: "Yes, you've just been redirected from launchpad and you will have to read our wall of text before reporting a bug! No, seriously!"
<slangasek> zul: I don't understand why you're uploading m2crypto with the only changes to add rules to support running the testsuite, without actually running it
<slangasek> zul: and I'm unlikely to accept this during beta freeze
<slangasek> (I would rather reject it entirely, and hold out for a build that actually *runs* the testsuite)
<zul> slangasek: thats fine ill get the testsuite working properly
<uni4dfx> joke aside, i understand that you're trying to eliminate all the "mah abanto don't werk, plz fixx it" reports, i just think this new process should be made entirely useful before putting it in action :P
<slangasek> zul: ok
<cjwatson> uni4dfx: well, bearing in mind that I'm attempting to defend an action I don't agree with here: to be fair, this was intended as an (temporary?) experiment rather than as a definite change, and announced as such
<cjwatson> partly in order to try to kick-start improved coverage of ubuntu-bug
<bdmurray> wgrant: it was rolled out on production
<cjwatson> my objection to it is the assumption, sometimes hidden and sometimes less so, that it's actually *possible* to have ubuntu-bug handle all legitimate bug reports
<cjwatson> which it isn't
<bdmurray> uni4dfx: how could the process be made more useful? you mentioned something about a plugin?
<uni4dfx> bdmurray: yes, i wanna report a bug in a plugin... i have no clue what package it is in
<bdmurray> uni4dfx: a plugin for what?
<uni4dfx> bdmurray: gnome-panel
<uni4dfx> an applet actually
<bdmurray> which one?
<uni4dfx> the systray thing
<uni4dfx> "notification area" is what it's called i believe
<hikenboot> sladen, they have a 250 Gig limit per month
<wgrant> bdmurray: They fixed the production config in the last 24 hours?
<hikenboot> since its for desktop use perhaps I can limit it to only a select few of the repos any recommendation which ones?
<bdmurray> wgrant: yes, as I understand it
<wgrant> How unfortunate.
<uni4dfx> bdmurray: so what package do i report it as?
<bdmurray> uni4dfx: I believe gnome-panel is the correct package
<uni4dfx> bdmurray: and if it's not the right one it's just going to be rejected isn't it?
<ScottK> bdmurray: I've explained the new policy to several people in #launchpad where they are showing up because they think LP is broken.  It might be nice if someone from Ubuntu Bugs hung out there to catch the queries.
<bdmurray> uni4dfx: no, it shouldn't its possible to move bug reports between packages
<lifeless> bdmurray: why not?
<wgrant> bdmurray: But then the information uploaded by apport is almost useless.
<bdmurray> ScottK: okay, thanks for letting me know
<lifeless> bdmurray: marking invalid on one and then adding a new task just causes bug noise to the first package
<bdmurray> wgrant: it has the release and package version I don't think those are useless
<wgrant> bdmurray: Wrong package.
<lifeless> bdmurray: oh sorry, double negatives
<hikenboot> can anyone tell me which repos for 9.04 Powerpc for offline use of the mirror just whats needed for desktops? 400 Gig is too much i am afraid to mirror the whole thing
<slangasek> hikenboot: well, for one thing you need to use ports.ubuntu.com for powerpc.  but for minimal use you could mirror only the 'main' section, which will be much smaller
<hikenboot> slangasek, how large is the ports.ubuntu.com powerpc section? is there a way for me to tell myself so i wont keep asking these anoying questions?
<slangasek> hikenboot: the reliable way to measure the size is to download the Packages files, pull the 'Size' fields of all the packages listed in those files and add them up
<hikenboot> is there a doc on this procedure?
 * wgrant just uses debmirror to calculate that.
<wgrant> it says 'Need to download 12345678MiB'
<jpds> 1, 2, 3, 4, 5, 6, 7, 8 - is that thing serious?
<wgrant> jpds: 'twas just an example!
<jpds> wgrant: Oh, right.
<wgrant> The archive isn't actually 12TB
<Amaranth> Not yet, anyway
<wgrant> Does anybody else find the new default background to be unusably bright on the right?
<sistpoty> wgrant: fluxbox didn't change?
<sistpoty> :)
<hikenboot> wgrant, jpds so your saying it is inaccurate to calculate... if i download just the powerpc parts of ports.ubuntu.com what am i looking at? anyone know? does that include things like games that are available?
<wgrant> hikenboot: Mirroring applications will usually tell you how much they will download.
<hikenboot> ah ok debmirror instead of apt-mirror which i have been using
<lamont> wgrant: is there a bug filed?
<lamont> wgrant: and what do you need it to do?
<wgrant> lamont: It's part of the whole ddebs-in-Soyuz thing. I don't believe there's a bug for this particular bit, although there are a few around so I may be wrong.
<wgrant> lamont: https://code.edge.launchpad.net/~wgrant/launchpad/lp-buildd-build-debug-symbols-flag
<wgrant> lamont: That is for the use of some pkg-create-dbgsym changes which are yet to be merged.
<lamont> wgrant: the ideal way would be to drop a bug on https://launchpad.net/launchpad-buildd and then pester me to do the merge - I'll be spending some quality time with launchpad-buildd next week
<wgrant> lamont: Great, thanks.
<wgrant> lamont: Bug #391050
<ubottu> Launchpad bug 391050 in launchpad-buildd "Buildds need to upload ddebs in PPA builds" [High,Triaged] https://launchpad.net/bugs/391050
<lamont> oh.  ah.  I see
<lamont> wgrant: so if I grab that branch, how many megabytes will I be downloading?
<wgrant> lamont: About 200 if you don't already have LP locally.
<lamont> right.  I'll grab it next week from town then
<LaserJock> wgrant: is that mostly .bzr ?
<wgrant> lamont: http://bazaar.launchpad.net/~wgrant/launchpad/lp-buildd-build-debug-symbols-flag/revision/9442
<lamont> historically, lp-buildd has been 'grab it from the archive, hack on it, commit to LP"
<wgrant> LaserJock: The download is all .bzr.
<wgrant> lamont: Well, I have no access to that archive.
<LaserJock> oh right
<lamont> LaserJock: .bzr, in all its history
<wgrant> Very nearly 70000 revisions of history.
<lamont> right.  and I'm _SO_ renaming it to lp-sbuild
<wgrant> lamont: Is it going to use a less ancient sbuild at some point?
<wgrant> The current one is broken on Karmic.
<lamont> wgrant: and totally not the one we use, either
<wgrant> lamont: Hm?
<lamont> the version string for the sbuild package is YYYY.MM.DDubuntuXX
<lamont> though with the new dpkg format coming down the pipe, we're gonna have to do some switching at some point
<wgrant> lamont: Which sbuild package are you talking about?
<rockstar> Anyone know why `python -c "import twisted"` on a base karmic install even though python-twisted is not installed?
<rockstar> Er, why that command works.
<wgrant> rockstar: ubuntuone-client probably brings in some other twisted stuff, I guess.
<lamont> there was an ancient schism in debian, and debian many (most? all?) of the buildds didn't use the sbuild in the debian archive, on account of "it was crack"...
<wgrant> rockstar: Yeah, python-ubuntuone-client brings in python-twisted-web.
<rockstar> wgrant, ah, you're right!
<hikenboot> getting Failed to download some Release or Release.gpg files! trying to download with debmirror anyone know how to fix or know where to go and ask
<wgrant> lamont: Right, but don't the Ubuntu buildds use the one in lp-buildd, which isn't in its own package, so doesn't have the version number that you say?
<rockstar> wgrant, but if I install python-twisted it brings in the rest of the meta packages.
<wgrant> rockstar: Are you sure you mean meta packages?
<rockstar> Er, python-twisted is a meta package that brings in the rest of twisted.
<wgrant> Right.
<wgrant> Why is this a problem?
<rockstar> So ubuntuone only brings in a subset of what python-twisted brings in.
<wgrant> Right
<lamont> wgrant: right.  lp-buildd delivers its own sbuild
<rockstar> wgrant, it really isn't but I was damn convinced that my virtualenv was leaking into system python, which had me fuming for a day and half.
<lamont> which is derived from the one that debian was using in 2004
<wgrant> lamont: Which appears to be a fork from 2005.
<wgrant> 2004! Even better.
<rockstar> wgrant, just confusing.
<wgrant> Ah.
<wgrant> The one that was in use, not the one that was in the archive?
<wgrant> I attempted to determine its ancestry a few weeks ago, but couldn't find any sane original Debian archive version.
<lamont> wgrant: a fork from code that is completely unrelated to the sbuild that lives in the archive
<wgrant> lamont: Ahh.
<lamont> which reminds me, I need to work with the debian guys to get my debian buildds converted over to the new world order.  not sure if the sbuild in sid is actually the new-world-order debian buildd sbuild either
<lamont> though I think it might be
<lamont> dunno
<wgrant> It's a pretty different beast now.
<wgrant> I think it is.
<lamont> I think it might be
<lamont> anyway, afk with family
<wgrant> Night.
<mdz> slangasek, ping?
<freenose> Are there going to be disruptive or big changes in karmic before release? want to install ubuntu in this laptop but don't want to reinstall in a month
<ScottK> freenose: Not on purpose.
<xuser> ScottK: :)
<dtchen> jdstrand: / ajmitch: fixed, please pull commit 80abe54
<ajmitch> dtchen: ok, I'll pull it & try & compile
<AnAnt> why's pidgin added again ?
<AnAnt> Hello, when I did apt-get dist-upgrade today, it attempted to install pidgin
<AnAnt> the reason is that libpurple0 recommends pidgin-libnotify, which in turn depends on pidgin
<ttx> mdz, kirkland: still up ?
<kirkland> ttx: i am
<kirkland> ttx: i'm about to upload another eucalyptus
<kirkland> ttx: i'm testing it now
<ttx> kirkland: I forgot "dch --release" in my instructions from yesterday
<confrey> hi everybody
<ttx> to get the right distro in the changelog, before doing debcommit --release
<kirkland> ttx: heh, i figured it out ;-)
<ttx> kirkland: I'll read the email pile... anything special I should test this week-end except taking the latest dailies for a UEC install spin to validate the fixes ?
<confrey> hi everybody
<confrey> I've installed karmic alpha6, but after upgrading, it do an infinite loop during fschk at boot, it seems each superbloock time is in future, but it continues to check it, without stopping,
<hrickards> If there's a bug with my package that's also present in upstream (Debian), shall I file the bug in Launchpad, bugs.d.o or both? Sorry for such a newbish question.
* Cut-R changed the topic of #ubuntu-devel to: FREENODE BANDES DE PEDOPHILES VIOLEURS D'ENFANTS ABUSEURS D'INNOCENTS FILS DE PUTES D'ENCULÃS !!!
<Laney> don't do that
* lifeless changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
* Cut-R changed the topic of #ubuntu-devel to: FREENODE BANDES DE PEDOPHILES VIOLEURS D'ENFANTS ABUSEURS D'INNOCENTS FILS DE PUTES D'ENCULÃS !!!
* lifeless changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
* Cut-R changed the topic of #ubuntu-devel to: FREENODE BANDES DE PEDOPHILES VIOLEURS D'ENFANTS ABUSEURS D'INNOCENTS FILS DE PUTES D'ENCULÃS !!!
<Laney> lifeless: are you an op?
<lifeless> nope
<hrickards> Someone kick Cut-R
<lifeless> we need one
<Laney> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<lifeless> Hobbsee: around ?
<Tm_T> hmh, not hat for me his time
* lifeless changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
* Cut-R changed the topic of #ubuntu-devel to: FREENODE BANDES DE PEDOPHILES VIOLEURS D'ENFANTS ABUSEURS D'INNOCENTS FILS DE PUTES D'ENCULÃS !!!
<Tm_T> Cut-R: stop trolling with topic
<Amaranth> jayne: Can you change it back too? :)
<Amaranth> (the topic)
<Laney> we dont need +t
<Laney> cant you just kick/ban?
* jayne changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
<lifeless> jayne: we don't want +t in fact
<jayne> getting there, Amaranth
<Cut-R> for what kick ban me if i can change topic in liberty ?
<ErrantEgo> lifeless: please stay calm
<lifeless> ErrantEgo: I am?
<Amaranth> Cut-R: Because we don't want you to
<Tm_T> Cut-R: sure, by libe ty to kickban?
<lifeless> Cut-R: this isn't liberty, its humanity towards others, and its a linux distribution development channel.
<elky> jayne, are you discussing with him the finer points of respectful behaviour, or are you waiting for some directive from a GC?
<Tm_T> elky (:
<lifeless> Cut-R: this isn't liberty, its humanity towards others, and its a linux distribution development channel.
<lifeless> bah mistype
<jayne> elky: discussing... feel free to -t or whatever if you want
<lifeless> jayne: -t when you're confident they won't toggle it back :)
<lifeless> jayne: we need it -t though for community announcements done by a variety of folk
<elky> jayne, whilst i am GC, i don't actually have the ubuntuirccouncil nick password at hand
<lifeless> thank you
<cjwatson> kirkland,ttx: still around? this eucalyptus upload looks wrong
<ErrantEgo> just wanted to make you folks aware, that he's been k-lined
<cjwatson> ErrantEgo: thanks
<lifeless> ErrantEgo: thanks
<cjwatson> kirkland,ttx: mdz's change from installer-cc.conf to eucalyptus-cc.conf (why?) wasn't reflected in a couple of other files. Any reason this isn't needed? http://paste.ubuntu.com/278606/
<lifeless> [bah, latency]
<cjwatson> mdz: (I'm assuming you're asleep by now)
<ErrantEgo> heads up
<ErrantEgo> he has just evaded a ban
<cjwatson> I'll be around for a bit
<ErrantEgo> cjwatson: are you an op?
<cjwatson> in this channel, yes
<ErrantEgo> oops, nm
<ErrantEgo> i just noticed you were opped
<ErrantEgo> fine business
<cjwatson> do you want notified somewhere if he shows up here again?
<ErrantEgo> hes using the nick Standley
<ErrantEgo> I'm just a normal user, but I do try to do a little "undercover" work if i can
<ErrantEgo> seeing what takes place, and pass it along to the staff
<ErrantEgo> ok, he was once again k-lined
<ErrantEgo> cjwatson: ^
<cjwatson> ErrantEgo: ok, I don't really care as long as he isn't trolling here :)
<cjwatson> if he does, we'll throw him out again
<ErrantEgo> ok
<ErrantEgo> dont mean to be an annoyance, just trying to look 'behind the scenes', per-se
<cjwatson> that's fine, thanks
<cjwatson> let's not let a troll take up too much attention though, as that's just what they want
 * ErrantEgo nods in agreement
<ErrantEgo> thats what they strive to do :)
<ErrantEgo> or, should that be a :( ?? lol..
<ErrantEgo> ok im done
<ErrantEgo> im gonna depart...now that i see an op is around
<kirkland> cjwatson: i'm around
<kirkland> cjwatson: mdz was trying to get rid of /etc/eucalyptus/installer-cc.conf
<kirkland> cjwatson: he's putting the CC_NAME in /etc/eucalyptus/eucalyptus-cc.conf
<kirkland> cjwatson: and sourcing that instead
<kirkland> cjwatson: this is just the tip of the iceberg in trying to fix eucalyptus' horrible conffile handling
<kirkland> cjwatson: i see you pushed an upload too
<cjwatson> right, it's a shame he didn't grep for installer-cc.conf in the rest of the code, that's all :) anyway, fixed
<cjwatson> I don't see how eucalyptus-cc.conf is any better than installer-cc.conf, but I assume there's some plan in mind here
<kirkland> cjwatson: i'm too tired to explain right now
<kirkland> cjwatson: but it's part of a multi-step scheme to improve the conffile handling
<cjwatson> kirkland: I see - well, let's try not to regress the beta in the cause of a longer-term plan :)
<kirkland> cjwatson: heh, agreed.
<pecisk> does Karmic goes back to Pidgin?
<cjwatson> pecisk: not as far as I can see? empathy is still seeded in desktop and pidgin isn't
<kirkland> cjwatson: okay, i'm calling it a night/day
<pecisk> allright, then it is just a glich
<cjwatson> kirkland: *nod*, sleep well
<kirkland> ack
<kirkland> thx
<pecisk> cjwatson: hmmm, interesting, today's dist-upgrade pulls in pidgin
<cjwatson> well, I don't know why that is, but it doesn't appear to be due to the default switching back
<cjwatson> not for ubuntu-desktop, anyway
<cjwatson> other metapackages still pull it in
<pecisk> for example? :) I have only ubuntu-desktop as far as I know. Fresh install.
<cjwatson> the following packages mention pidgin somewhere in their pre-depends/depends/recommends fields: brdesktop-gnome finch gaim-extendedprefs gaim-guifications gaim-hotkeys gaim-irchelper gaim-themes gaim-thinklight gfire gnome libpurple0 lubuntu-desktop pidgin pidgin-audacious pidgin-awayonlock pidgin-blinklight pidgin-bot-sentry pidgin-dbg pidgin-dev pidgin-encryption pidgin-extprefs pidgin-festival pidgin-guifications ...
<cjwatson> ... pidgin-hotkeys pidgin-lastfm pidgin-libnotify pidgin-mpris pidgin-nateon pidgin-nateon-dbg pidgin-otr pidgin-plugin-pack pidgin-privacy-please pidgin-sipe pidgin-themes ubuntu-mid xubuntu-desktop
<cjwatson> (that's just a quick grep, may be inaccurate)
<pecisk> well, seemingly ubuntu-desktop doesn't have it, but afaik libpurple0 is used my empathy
<pecisk> my/by/s
<cjwatson> not as far as I can see. Of course you may happen to still have it installed
<cjwatson> nautilus-sendto depends on it
<cjwatson> which is in desktop
<pecisk> sounds like a bug
<cjwatson> so it does look as if pidgin is being transitively pulled into desktop; I agree, that's a bug *somewhere*
<cjwatson> the most relevant change seems to be the addition of pidgin-libnotify to libpurple0's Recommends, though I don't know if that's the proper place to fix it
<cjwatson> please do report it
<Laney> yes
<hile> that was reported earlier here
<Laney> it should have been a recommends of pidgin and not libpurple0
<hile> oh already said, ignore
<Laney> should be a quick fix for any free core-dev...
 * Laney runs
<pecisk> damn, it might be stupid thing to ask, but how can I report bug in new LP interface?
 * pecisk is confused :)
<cjwatson> bug 437109
<ubottu> Launchpad bug 437109 in pidgin "[karmic] libpurple0 depends on Pidgin" [Undecided,New] https://launchpad.net/bugs/437109
<pecisk> cjwatson: thanks
<pecisk> so there is recommendation to do this trough ubuntu-bug tool right?
<pecisk> to report bugs
<Laney> patch is up on that bug
<pecisk> great
<pecisk> thanks guys :)
<pecisk> It seems that epiphany webkit is kinda broken for lot of pages. It is known bug?
<AnAnt> can someone look at LP 416949 ?
<ubottu> Launchpad bug 416949 in console-setup "Keyboard layout toggle does not work anymore in karmic" [Undecided,New] https://launchpad.net/bugs/416949
<tormod> oh the acpi-support/pm-utils/laptop-mode-tools mess... can somebody please sponsor bug #384875
<ubottu> Launchpad bug 384875 in laptop-mode-tools "ships two different sleep.d hooks" [Low,Fix released] https://launchpad.net/bugs/384875
<lool> smoser: Did you get vmbuilder sponsored?  Can't see it in karmic-changes
<mdke> anyone in ~ubuntu-release - I've uploaded ubuntu-docs 9.10.7, no invasive changes from .6. We'll probably try and do one more before the beta so that we can get any last new strings in before the string freeze
<happyaron> jcastro: ping
<senthil> hello guys
* Standley changed the topic of #ubuntu-devel to: FREENODE PEDOPHILE VIOLEURS ABUSEURS D'ENFANTS INNOCENTS FILS DE PUTES D'ENCULÃS !!!
<arand> Is the ability to configure the sound theme gone in karmic? if so, why is it gone? what would one do to get it back?
<nalioth> any ops around?
<ScottK> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ScottK> Shoot.  He's gone already.  Sorry.
* ScottK changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | 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
<nalioth> ScottK: is there a reason the topic is open?
<ScottK> Because it's more trouble to limit it and then need to find that special someone than to fix it after this happens every once and a while.
<ScottK> That's the theory anyway.
<ScottK> Generally it works out OK.
<YokoZar> Does the new software store icon look like a grocery bag to anyone else?
<freenose> Linux karmic 2.6.31-11-generic-pae #36-Ubuntu SMP Fri Sep 25 07:50:01 UTC 2009 i686 GNU/Linux
<freenose> I installed the virtual mode, shouldn't it say 'virtual' in the kernel name?
<mdz> cjwatson_, I did grep the rest of the code for installer-cc.conf, and did notice those two instances. I deliberately left those init scripts alone because dustin was modifying them at the same time and I wanted to avoid conflicts
<mdz> he and I discussed the necessary changes to the scripts; it got very late and must have been forgotten
<freenose> is that a bug maybe? since aptitude shows that linux-image-2.6.31-11-virtual is installed and shows linux-image-generic-pae as not installed, uname is showing the wrong version?
<arand> Is the ability to configure the sound theme gone in karmic? if so, why is it gone? what would one do to get it back?
<ScottK> arand: Karmic help is in #ubuntu+1.
<arand> ScottK: I'm aware, I've been fishing for an answer to this there for a couple of weeks already. Do you know where I would be more likely to get answers?
<ScottK> Not really.  That's really the appropriate channel though.  Not this one.
<mdz> kirkland, around?
<rgs__> hey guys, do you know how i could get python-hulahop for Py 2.6
<rgs__> this is on Jaunty where the module is only packaged for python 2.5
<ScottK> Looks like it's fixed in Karmic, so you might be able to grab the Karmic source package and build it for Jaunty
<hikenboot> how do i import keys meant for ubuntu on centos so i can do a debmirror
<Hellow> Netsplits \o/
<bluefoxicy> so
<bluefoxicy> did sabdfl actually stand up at a conference a couple days ago and tell everyone they need to shut the fuck up?
<highvoltage> heh
<bluefoxicy> okay
<bluefoxicy> stop.
<bluefoxicy> look.
<bluefoxicy> This thing just asked for services to restart for PAM upgrade to Karmic alpha.
<bluefoxicy> it suggested GDM in the default options.
<bluefoxicy> Do you see a problem?
<highvoltage> It shouldn't kill your GDM session. (at least it didn't mine)
<highvoltage> did it kill yours?
<bluefoxicy> no, I took GDM out of the list
<bluefoxicy> it didn't ask me to dff check pam and I didn't let it update it (I use pam tmpdir...)
<bluefoxicy> how do I do this?
<highvoltage> (brb)
<bluefoxicy> istill don't understand the install procedures
<bluefoxicy> I've generated the initrd for 2.6.31-11-generic 6 times in the past apt instance
<mdke> slangasek: I'm working on a gnome-user-docs upload atm. You recall that last release you set it up so that it splits into various lang packages. I'm getting quite a few build errors because of the absence of /usr/share/iso-codes/iso_639.tab (referred to in debian/rules)
<cjwatson> use isoquery
<mdke> cjwatson: I'm just wondering whether we can get rid of the whole thing now that pitti has worked it so that translated xml is already stripped out of binary packages during the build process
<cjwatson> that I don't know, would recommend not experimenting overmuch with that sort of thing five days before beta though
<mdke> cjwatson: that sounds sensible too :)
<mdke> I'll look into adding isoquery as a build-dep and seeing if I can figure out how it works
<cjwatson> usually fairly easy, you can generally just build-depend on isoquery in addition to iso-codes and substitute $(isoquery --iso=639) for references to iso_639.tab
<mdke> hmm. I'm not going to even get close to understanding the line in debian/rules which is concerned here
<bluefoxicy> Canonical has been criticized for abuse of the Ubuntu trademark for commercial exploitation [1][2], and for launching a proprietary service [3][4].
<bluefoxicy> 1)  WTF Ubuntu One
<bluefoxicy> 2)  WTF criticism, it's their trademark and what are these RMS hippies "OMG MAKING MONIES ARE EVIL" coming from?!
<ScottK> bluefoxicy: It's been debated to death already.
<bluefoxicy> scottK: I don't like the idea of storing your files on someone else's server... that whole "cloud drive" thing
<mdke> quite off-topic for this channel
<ScottK> Right, so don't use it.
<bluefoxicy> scottK:  That being said, every time Canonical tries to make money doing anything but sell call-in support for things you can get 100% free (i.e. the apps work if you want to waive support), people bitch
<bluefoxicy> I don't get this.
<bluefoxicy> scottK:  Exactly
<ScottK> Right, but I don't think it's much to do with the purpose of this channel to try to figure it out.
<mdke> or anything
<bluefoxicy> I've already figured it out.  People are stupid.
<podman99> hey all when programming (compiling really) its moaning about not being able to find ServerSocket.h ... am i missing a pakckage ... cant find it with `find / -name ServerSocket.h` noob to C programming my first real includes
<bluefoxicy> podman99: yeah ask that in #ubuntu but that's a -dev package, figure out what library it's from(google) and install fubar-dev
<podman99> bluefoxicy -- thanks... thourhgt it best to ask developers about a developer problem?? ne way ... there is no listed package on google or aptitude spent 2 hours looking before i came to irc
<bluefoxicy> no this is specifically for ubuntu development, not developing ON ubuntu
<podman99> is there a file/package search on ubuntu sites anywhere
<bluefoxicy> search for the file name
<cjwatson> podman99: while it does exist in our archive, I can only find it in some fairly arcane places (java/net/ServerSocket.h in libgcj*-dev, that kind of thing). You may well find that the person who wrote the program you're compiling is using some proprietary interface that we simply don't have
<cjwatson> podman99: packages.ubuntu.com
<podman99> great one .. thanks
<cjwatson> and bluefoxicy is right, this channel is for developing Ubuntu itself rather than for help compiling applications on Ubuntu, sorry
<podman99> librudiments-dev ... ubuntu rules xxx netbook dont boot on my tx2 USB Stick... comes up with busybox ... however this is a laptop not netbook so that may explain it
<mdke> slangasek: I wonder if you could take a look at it. Where I have got to is at ~ubuntu-core-doc/gnome-user-docs/ubuntu-karmic - we may want to think about whether the separate packages can now be dropped given that pkgbinarymangler strips out localised xml from binaries anyway now, but as cjwatson points out, it may be the wrong time to look at that
#ubuntu-devel 2009-09-27
<hikenboot> can anyone tell me for ports.ubuntu.com what the location of the gpg keys so i can import them with the gpg command instead of apt-key since apt-key isnt available on centos?
<happyaron> jcastro, ping
<pwnguin> who updates the md5sums for the installation wiki pages?
<pwnguin> ie https://help.ubuntu.com/community/Installation/MinimalCD/
<pwnguin> someone pointed out to me that the hardy x86 (32bit) iso doesn't match it's published md5
<tgpraveen> any chance we might have this ?
<tgpraveen> https://bugs.launchpad.net/ubuntu/+source/libtheora/+bug/436726
<ubottu> Launchpad bug 436726 in libtheora "Theora 1.1 "Thusnelda" has been released" [Wishlist,New]
<napsy> Hello. What's the package name for the debug version of the Linux kernel?
<pochu> pitti: hey, udev is finally in unstable! when you have five minutes I'd appreciate an upload of media-player-info to unstable :)
<happyaron> anyone maintains software center (aka software store before ) here?
<sebner> happyaron: it would be mvo (Michael Vogt) but it's sunday so try again tomorrow, bugs -> launchpad
<happyaron> sebner, thx
<bluespace> I have this problem: https://bugzilla.gnome.org/show_bug.cgi?id=596498 - is there a workaround?
<ubottu> Gnome bug 596498 in gtk "Print Dialog Window Size on netbooks" [Normal,Unconfirmed]
<unimatrix> [needs-packaging] mupen64
<unimatrix> i'd report a bug but i don't know how
<sebner> unimatrix: FFe for mupen64plus is approved. The archive admins just need to sync so it will be in karmic
<unimatrix> sebner: oh, that's nice to hear
<directhex> hm
<directhex> libvirt seems broken
<Chipzz> unimatrix: is mupen64 actually stable enough yet?
<unimatrix> Chipzz: apparently it's a dead project, that's why mupen64plus was created
<unimatrix> didn't know this up until a a few minutes ago
<Chipzz> anyway mupen sounds like sth for universe, not for main
<Chipzz> and you may want to look into possible legal issues first
<Chipzz> although I suppose snes9x is packaged too
<doko_> ubuntu-archive: if somebody is listening, please promote binutils-source
<cjwatson> doko_: done
<darkham> are you on time, with a working network manager for the 29 October?
<YokoZar> cjwatson: is R all up to date now?
<cjwatson> the only thing I did was that r-base upload
<cjwatson> haven't checked anything else
<cjwatson> that was just 'cos it was on the karmic bug list
<YokoZar> cjwatson: Ahh ok it doesn't seem that revolution needs an update either.  Ok thanks that took care of things.
 * cjwatson is slightly baffled by http://launchpadlibrarian.net/32523015/buildlog_ubuntu-karmic-armel.eucalyptus_1.6~bzr854-0ubuntu8_FAILEDTOBUILD.txt.gz
<cjwatson> it's just doing dpkg-architecture -qDEB_HOST_ARCH; why would that fail so late in the build when I'm pretty sure it had already been called several times? dh_installudev doesn't do anything special
<cjwatson> I'm quite tempted to just bang the retry button
<YokoZar> cjwatson: yeah that is really weird
<YokoZar> it doesn't specify why dpkg-architecture failed either -- that command just outputs some very simple things too
<YokoZar> maybe the build daemon started dying around that time
<cjwatson> yeah, that's arguably a debhelper buglet
<cjwatson>         my $value=`dpkg-architecture -q$var 2>/dev/null` || error("dpkg-architecture failed");
<cjwatson> throwing away error messages perhaps not entirely helpful there
<YokoZar> well, upload a fixed debhelper to a ppa then upload the breaking eucalyptus ;)
<ttx> cjwatson: hey -- could you trigger a server CD respin so that the just-accepted eucalyptus can find its way to the server CD asap ?
<cjwatson> ttx: the binaries aren't actually in the archive yet
<ttx> cjwatson: ah, too early :)
 * ttx will check it out later
<unimatrix> oh i see why they haven't added mupen64plus to ubuntu yet... it doesn't work with pulseaudio
<mdke> /win 12
<ion> lose 13
<mdke> I lose :(
<darkham> network manager will work the 29 october?
<joaopinto> darkham, if it doesn't work, it will work during beta, and you probably should ask on #ubuntu+1
<darkham> i hope, i like the work until now
<darkham> but looking it noworking is a little bit sad
<sebner> unimatrix: that's nonsense. It's just not synced yet
<unimatrix> sebner: the sound is all jittery, i've been testing it
<sebner> unimatrix: and I've tested it without problems ;)
<unimatrix> sebner: which ubuntu & PA version?
<sebner> unimatrix: 9.10, PA? actual mupen64plus version which will be synced
<unimatrix> sebner: where can i find it, i used the binary from google code
<sebner> unimatrix: I rebuild the Debian source with ubuntu toolchain (pbuilder) but as a quick try you can use the deb from packages.debian.org
<cjwatson> darkham: (I have nothing to do with network-manager myself, but) you should be more specific, and file specific bugs about your problems; because it *is* working fine for at least some people (me at least)
<cjwatson> darkham: just saying "it's not working" is almost always very unhelpful
<darkham> cjwatson: i try to set manual
<darkham> but nothing
<darkham> it don't take the changes
<darkham> i delete the connection , i create a new one , i insert mac address, ip , default gateway, dns, i "apply"
<darkham> it don't works, i edit , and i whatch the connection in "automatic (dhcp)" settings
<darkham> this is what nm do in the karmic daily live of today 27
<darkham> sometimes it crash after changes
<cjwatson> yeah, you probably ought to tell a bug report rather than me though :-)
<cjwatson> like I say, I don't work on n-m myself
<cjwatson> IRC is usually not a great way to report problems, 'cos they get lost very easily
<unimatrix> sebner: well, now i've got no sound at all
<unimatrix> sebner: nvm, wrong sound card in PA... ok it's still jittery and sluggish
<lamalex> Does anyone know where I can get intltool help? It's crashing with some weird message about a regexp
<mdz> kirkland, around?
<lamalex> Hey all, been trying to figure this out for days- anyone know where I can get intltool help? It's crashing with some weird message about a regexp
<lamalex> https://bugs.launchpad.net/intltool/+bug/436671
<ubottu> Launchpad bug 436671 in intltool "intltool fails on reportedly bad regexp" [Undecided,New]
<cjwatson> lamalex: why do you have [encoding: UTF-8] in your POTFILES.in?
<cjwatson> lamalex: you would put that in .desktop files (say) but not ordinarily in POTFILES.in
<sebner> cjwatson: naahh, encoding key is deprecated
<cjwatson> sebner: missing the point :)
<cjwatson> sebner: the point is that it's not something that goes in POTFILES.in
<sebner> cjwatson: yeah, sorry, was just a sidenote
<lamalex> cjwatson: ah, it's not needed? Every other one ive ever seen has had it
<cjwatson> lamalex: I've never, ever put it there
<cjwatson> I'm surprised you managed to find any POTFILES.in that included it
<lamalex> lemme try without
<cjwatson> that said, you're right, I do see some POTFILES.in on my system that include it
<cjwatson> so maybe that isn't the problem
<cjwatson> maybe you should ignore me :)
<lamalex> :P
<lamalex> cjwatson: well removing it makes it run..
<lamalex> so I'm just gonna go ahead and remove it
<cjwatson> mm, you may indeed not need it, but I'm not sure that that closes the bug
<lamalex> right
<lamalex> but it at least gets my package building
<cjwatson> looking at the source, it's definitely meant to support that
<mdz> cjwatson, thanks for the server respin
<bluefoxicy> please check invest-applet for security holes and vanilla input validation bugs.
<bluefoxicy> I use an ISP with a captive portal, and when it logs me out everything gets redirected
<bluefoxicy> at which point, invest-applet crashes.  Repeatedly.  Likely from getting garbage data from Web sites.
<bluefoxicy> Maybe just a bug somewhere, maybe something expecting specifically formatted data and loading a buffer wrong or otherwise causing memory corruption.
<dupondje> is it already to late to get new version of software into Karmic ?
<jdong> dupondje: very late
<cjwatson> it can be done of course, but there has to be a good reason
<cjwatson> beyond "we'd like these new features"
<dupondje> well would like new version of SynCE
<dupondje> kinda fixes lotsa bugs in SynCE
<dupondje> like non working synce-gnomevfs etc
<cjwatson> you need to follow https://wiki.ubuntu.com/FreezeExceptionProcess (or, if you're not a developer, find a developer to make the necessary changes and follow that)
<cjwatson> feature freeze is the relevant thing (we're currently in a deeper freeze for beta, but that will lift again once the beta's out)
<dupondje> think that find a developper is the most difficult part ;)
<mdz> what is the difference between /etc/init and /etc/event.d?
<mdz> I seem to have both in current karmic
<mdz> (upgraded)
<ion> event.d was used by the old Upstart release, init by the new one.
<mdz> ah, bug 402759
<ubottu> Launchpad bug 402759 in upstart "Scripts need to be migrated from /etc/event.d to /etc/init" [Medium,Triaged] https://launchpad.net/bugs/402759
<lifeless> slangasek: hai
<lifeless> slangasek: bzrtools in karmic is borked; I'm requesting a sync. Are your powers enough, or doth it still need colin etc
<james_w> lifeless: I can take care of that tomorrow morning
<lifeless> james_w: thanks
<lifeless> bug 437869
<ubottu> Launchpad bug 437869 in bzrtools "Sync bzrtools 2.0.1-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/437869
<james_w> lifeless: I don't think the bug report needs an upstream task does it?
<lifeless> nope
<lifeless> its just ubuntu
#ubuntu-devel 2010-09-27
<ScottK> RAOF: Which browser?
<RAOF> ScottK: Chromium is what's set up, and if it's running then the URL goes to the right place.
<ScottK> OK.  I was curious since I haven't seen that.  I may just not have been looking.
<cjwatson> Sarvatt,RAOF: hm, so if mesa no longer provides the mesa-utils binary package, what are things like gnome-shell supposed to do which use glxinfo?  there are a couple of other reverse dependencies listed in http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils
<cjwatson> ogasawara: could we have an upload of linux-meta-mvl-dove to match the 410 ABI?
<RAOF> cjwatson: Yeah, I just got reminded about that with bug #648401.
<ubottu> Launchpad bug 648401 in mesa (Ubuntu Maverick) "mesa-utils still referenced by packages" [High,Confirmed] https://launchpad.net/bugs/648401
<cjwatson> RAOF: ah, doko beat me to it - thanks
<cjwatson> (I don't agree with his "option for maverick-updates", though - the archive needs to be consistent for release)
<RAOF> mesa-demos got split out of the main mesa source tree and put into a separate repository.  I knew about this a couple of months ago, and just plain forgot when the 7.9 FFe came through :/
<RAOF> I'm not sure whether re-munging the mesa-demos tarball into our mesa tarball is the way to go, or whether to go with the separate packaging I've got lying around.
<cjwatson> I don't think it matters too much from the archive point of view (FWIW)
<RAOF> It's probably easier from a review standpoint to re-munge the tarballs.
<RAOF> That does seem a bit like cheating, though.
<cjwatson> RAOF: sounds like a pain to compare either way actually
<cjwatson> so go with what makes most sense to you
<RAOF> Separate packging it is, then.
<TheMuso> 8/c
<RAOF> Good morning :)
<TheMuso> Hey RAOF.
<RAOF> Howdie TheMuso.  How's Sydney's springtime treating you?
<TheMuso> RAOF: Not too bad, unseasonally warm unfortunately, but cooler weather is on its way, at least temporarily.
 * RAOF wouldn't mind just a *little* bit of unseasonable warmth :)
<RAOF> It's decided to be really really windy, instead.
<TheMuso> heh
<RAOF> I'm not yet sure what sounds from the roof to be alarmed at, either.
<ogasawara> cjwatson: just uploaded linux-meta-mvl-dove 2.6.32.410.2
<amitk> ogasawara: why are you up at this hour?
<ogasawara> amitk: am actually just going to go to bed now.
<amitk> ogasawara: good night, take care :)
<pitti> Good morning
<micahg> good morning pitti
<micahg> pitti: would it be possible to accept gjs into lucid-proposed
<\sh> pitti: stupid question who is responsible for the partner archive of C.?
<pitti> micahg: I'll have a round of SRUs next
<micahg> pitti: awesome thank you
<pitti> micahg: Brian Thomason (iamfuzz)
<micahg> pitti: ?
<StevenK> pitti: \sh asked that :_)
<pitti> oops, sorry ;)
<ogra> RAOF, hey
<\sh> pitti: thx :)
<\sh> and btw...cdbs is broken, eventually doing some black magic to DEB_MAKE_INVOKE settting -C without setting $(DEB_BUILDDIR_$(cdbs_curpkg)) that's why libapache-mod-fastcgi is FTBSing in maverick...I wonder how to fix cdbs for that...
<\sh> without declaring DEB_MAKE_INVOKE = $(MAKE) inside the package rules file, there is no other way to fix it...and I'm not a cdbs specialist...
<\sh> I think makefile-vars.mk:DEB_MAKE_INVOKE = $(DEB_MAKE_ENVVARS) $(MAKE) $(if $(DEB_MAKE_MAKEFILE), -f $(DEB_MAKE_MAKEFILE),) -C $(DEB_BUILDDIR) $(DEB_MAKE_EXTRA_ARGS) is the bugger in makefile-vars.mk
<\sh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596950 <- debian bug report
<ubottu> Debian bug 596950 in cdbs "makefile-vars.mk need $(cdbs_make_curbuilddir) from makefile.mk" [Serious,Fixed]
<RAOF> ogra: Howdie.
<ogra> RAOF, i have a weird X input problem with a weird setup i run here
<RAOF> Good, good.  Do go on :)
<ogra> i run an ubuntu chroot on top of an android kernel on unsupported HW and cant get keyboard input to work under X
<RAOF> Iiiiiiinteresting.
<ogra> (i cant tell if it would work in console though since the kernel has no framebuffer console builtin)
<RAOF> Does the android kernel provide evdev devices?
<ogra> i see garbage if i cat /dev/input/event0 and type on the keyboard
<ogra> i'm not sure
<RAOF> That looks quite likely to be an evdev device.
<ogra> i also cant run udev on the system since i cant start upstart
<RAOF> Ok.  Well, that will certainly freak X's input autodetection out.
<ogra> so i have to live with xorg.conf for input devices ... for the touchpad that works fine
<ogra> and i see the kbd being detected too in the log
<ogra> but ...
<ogra> there are queue overrun errors all the time
<ogra> i was wondering if you have any idea if there is a achnce to make it work
<ogra> *chance
<RAOF> That would be queue overruns in dmesg?
<ogra> (note thats only my private toy project, not work related or something ...)
<ogra> no, in Xorg.0.log
<RAOF> EQ overflows?
<ogra> let me get the device (i dont have it near me ...) gimme 10min
<RAOF> I'm not confident that I'll be particularly helpful, but sure :)
<ogra> RAOF, [ 18128.824] Generic KBD: dropping event due to full queue!
<ogra> thats the error i see
<RAOF> Hm.  And you've set up your keyboard to be driven by evdev, or kbd?
<ogra> evdev
<ogra> since we dont have kbd in maverick
<ogra> do we have a package of the old kbd driver anywhere =
<ogra> ?
<ogra> i'd happily recompile it for arm and try if that fixes it
<RAOF> You could probably grab one from Debian; they still need it, because it's useful on !linux
<ogra> ah
<ogra> yes, it apparantly is :) (/me considers android to be !linux) :)
<RAOF> I'm not _sure_ whether âubuntu chroot on android kernelâ is sufficiently not-linux to qualify :)
<ogra> well, there runs a minimal android so ubuntu is effectively run as a chroot in a java VM :)
<ogra> its more than the kernel
<ogra> (as i said, really odd setup)
<RAOF> Heh.
<directhex> i'd say android is !linux if one defines linux as "os with linux kernel and gnu userland". chroots are getting into a grey area
<ogra> directhex, well, the java vm runs partitally inside the kernel
<directhex> dalvik is a monstrous creation
<ogra> there is a lot of GNU userland still
<ogra> like busybox :)
<kklimonda> a lot?
<pitti> RAOF: ugh, that mesa upload looks scary at this point
<cjwatson> ogasawara: thanks
<\sh> pitti: there are two more ftbfs fixes mgltools-{support,volume}, can you approve them?
<pitti> \sh: currently looking at the queue, yes
<\sh> pitti: thx :) I'll try to push more ftbfs fixes today...working down the list from lucas
<pitti> \sh: many thanks!
<pitti> so, I processed the queue, all except mesa
 * pitti re-reads the diff again; there seems to be a lot of noise due to the renaming of a backend
<pitti> RAOF: the solution for bug 633406 isn't clear yet according to the bug trail, and that mesa upload changes a lot of other things; has this verrsion been tested at a larger scale?
<ubottu> Launchpad bug 633406 in mesa (Ubuntu Maverick) "Display freeze when changing kwin effects settings if effects are active" [High,Confirmed] https://launchpad.net/bugs/633406
<\sh> hmm..what happend to pkg sablotron in maverick?
<pitti> smb: how do you feel about the current lucid-proposed kernel?
<smb> pitti, Another day another try. What do you think of the current Lucid proposed? Beside the no-op ALSA updates that failed verification there are now some more successful verifications and it has been in proposed for more than three weeks now without people screaming. Beside it has some very nice to have IO performance enhancements.
<smb> pitti, Hehe
<smb> I was just thinking on that
<pitti> smb: right, that was my impression, too
<smb> pitti, Cool. Yeah, I think it should be good to move
<pitti> smb: good, will do; thanks
<smb> pitti, \o/ Thanks you :)
<pitti> I'll reopen the failed bugs then
<\sh> micahg: sablotron is deleted, regarding LP you requested this...(LP #636333)
<ubottu> Launchpad bug 636333 in sablotron (Ubuntu) "Please remove sablotron from archive" [Wishlist,Fix released] https://launchpad.net/bugs/636333
<\sh> micahg: what about caudium, which needs libsablot0*, should we remove it before release as well?
<happyaron> pitti: ping
<pitti> smb: hm, there's only the main kernell, no -ec2 and armel friends; what happened to them?
<micahg> \sh: yes, oh..let's see
<pitti> happyaron: pong
<happyaron> pitti: excuse me, have you read my email about language packs in kubuntu/xbuntu live cd?
<pitti> happyaron: I got it, yes; I didn't have time yet to respond
<happyaron> pitti: thanks
<smb> pitti, Pending in transfer. I am currently transferring stable things over to Steve and Brad and they got delayed for re-upload for various reasons
<pitti> ok
<micahg> \sh: yes, it's been removed from Debian
<smb> pitti, We upload them soon and then could go over to updates as well
<micahg> \sh: do you want me to file the bug?
<\sh> micahg: yes please
<micahg> \sh: k, thanks for catching that
<\sh> micahg: np...just working down lucas ftbfs list
<micahg> \sh: fabrice_sp already beat us to it
<\sh> ah yes :)
<lifeless> cjwatson: hi; https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/648638 may be of interest (or may not)
<ubottu> Launchpad bug 648638 in grub2 (Ubuntu) "grub_xputs not found after answering question as recommended during upgrade to maverick" [Undecided,New]
<smb> cjwatson, Hi Colin, it seems sconklin has only be given upload rights for the Maverick package set but would need the same for Dapper, Hardy, Jaunty, Karmic and Lucid
<pitti> jibel: do you know if anyone tested fglrx on jaunty? I didn't see feedback there
<pitti> jibel: I'm inclined to just push it, since it's rather urgent, and the same patch worked everywhere else
<jibel> pitti, no. I can give it a try.
<lifeless> anyone else with an x201s had a jumpy cursor, edge scrolling not working, that sort of thing?
<pitti> not on my x201 (non-s)
<pitti> lifeless: sounds like the touchpad is picked up by the wrong x input driver?
<lifeless> I'd assume so
<pitti> there has been some bugs in the utouchification
<pitti> lifeless: is that with the touchpad?
<pitti> I'm usually running this machine docked (with usb mouse)
<lifeless> I'm half way through an ubuntu-bug ginput-device-settings report for this
<lifeless> pitti: yeah trackpad
<lifeless> pitti: the nipple is fine
<lifeless> s/trackpad/touchpad/
<pitti> lifeless: nope, touchpad works fine here
<lifeless> pitti: its finding it as SynPS/2 Synaptics TouchPad
<lifeless> which sounds right
<pitti> *nod*
<pitti> [    16.085] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event10)
<pitti> [    16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
<pitti> [    16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall"
 * pitti redirects you to RAOF then
<lifeless> thanks
<lifeless> hah, details...
<lifeless> (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0)
<lifeless> (**) SynPS/2 Synaptics TouchPad: always reports core events
<lifeless> (**) SynPS/2 Synaptics TouchPad: Device: "/dev/input/mouse0"
<lifeless> (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
<lifeless> (II) UnloadModule: "evdev"
<lifeless> (EE) PreInit returned NULL for "SynPS/2 Synaptics TouchPad"
<pitti> lifeless: oh, interesting
<pitti> [    16.583] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse1)
<pitti> [    16.583] (II) No input driver/identifier specified (ignoring)
<pitti> lifeless: so on mine it tries to pick up both, but mouse1 is blacklisted somewhre
<pitti> lifeless: do you have a synaptics stanza for the corresponding evdev device, too?
<lifeless> mouse1 in the nipple for me; I have no input devices in xorg.conf
<cjwatson> lifeless: your boot loader is incorrectly installed
<cjwatson> lifeless: (I haven't looked at the bug yet but that's what that error basically means.  see my blog for details)
<lifeless> cjwatson: I'll look at your blog; the concerning thing for me was that following the advice resulted in both no-error and no-boot.
<cjwatson> lifeless: as far as I can see you read the help text precisely backwards
<cjwatson>  Note: It is possible to install GRUB to partition boot records as well, and
<cjwatson>  some appropriate partitions are offered here.  However, this forces GRUB to
<cjwatson>  use the blocklist mechanism, which makes it less reliable, and therefore is
<cjwatson>  not recommended.
<pitti> smb: oh argh, l-b-m is still in the unapproved queue, with the fix to make the gobi_loader rules ABI specific
<cjwatson> and yet you interpreted this as saying that installing to sda was a bad idea?
<pitti> smb: would you mind reuploading this with just the top changelog, and we'll try to push that to -updates fast?
<cjwatson> what it actually says is that installing to sda1 may be a bad idea ...
<lifeless> cjwatson: *blink*
<lifeless> cjwatson: Perhaps it would be clearer to provide the good-idea bad-idea hint in the list - either as two lists [recommended] and [not recommended], or as a marker in the list ?
<smb> pitti, I could, but compared to what is in updates for that package all the changes in the log are in. So why only the last one?
<cjwatson> can't provide two lists, debconf doesn't support it
<lifeless> cjwatson: (yes, clearly I did read it backwards, for which I have no excuse)
<cjwatson> I'll transform your bug into a recommendation to put a marker in the list
<pitti> smb: http://launchpadlibrarian.net/56311364/linux-backports-modules-2.6.32_2.6.32-25.24_source.changes -> 25.23 is in -updates now
<pitti> smb: so now it's just -25.24 which is new
<smb> pitti, Ah ok, got it
<pitti> smb: (rejected the current upload)
<smb> pitti, Ok, will do a quick repackaging. Just a second
<pitti> smb: sorry, we probably should have accepted and tested this one first, and then moved to -updates
<pitti> but as long as we don't get a new ABI, it should be fine
<pitti> oh, and the new ABI will have the custom path anyway
<cjwatson> lifeless: interesting that you saw the dialog at all; I suspect you previously had removable devices plugged in and perhaps had asked for grub to be installed to one of them (maybe without noticing)?
<smb> pitti, Probably would have been more convenient for the gobi_loader users. But the update from that won't clash and the abi doesn't change as well. So maybe its not that bad after all
<lifeless> cjwatson: I don't think so; this is my x201s (last machine to be upgraded)
<cjwatson> lifeless: do you need repair assistance?
<lifeless> cjwatson: it was a fresh install 6 months ago
<smb> pitti, Just the current update may require people to remove the old package...
<pitti> smb: right, it shouldn't cause problems, but I'd still like to have this change in, just in case
<lifeless> cjwatson: no, I'm good now; live-cd;chroot;reconfigure grub-pc and select both options on the theory that it was probably user error of some sort.
<lifeless> pitti: appears that update-manager didn't update the evdev package correctly.
<cjwatson> lifeless: you can/should just select sda
<cjwatson> (selecting sda1 as well is technically harmless but may cause confusion later)
<lifeless> ok, I'll reconfigure again next time I'm about to reboot
<cjwatson> the partition options are there for the minority (but not negligible minority) who have some other custom boot loader in the MBR
<lifeless> cjwatson: yeah, I can certainly understand the need and tradeoffs
<lifeless> I did a good job of foot-shooting
<directhex> cjwatson: tri-booting my imac also needed a partition install of grub
<cjwatson> right, weird hardware another reason :)
<smb> pitti, lucid-lbm re-uploaded (will probably take one or two more minutes to show up in lp)
<pitti> smb: cheers
<\sh> hmmm...I'm stucked ...
<\sh> libmed-dev : Depends: libmed1 (= 2.3.6-2) but it is not going to be installed
<\sh>  libmedc-dev : Depends: libmedc1 (= 2.3.6-2) but it is not going to be installed
<\sh> but apt-get install those files on a standard maverick, works as expected, only sbuild chroots means "no this doesn't work"
<lifeless> pitti: appears the xorg stack is mid transition or something; xserver-xorg-input-7 conflits with xserver-xorg-core ><
<\sh> oh wow...ecs is broken
<jibel> tkamppeter, mvo, another package blocking the upgrade because of the change to foomatic-db-compressed-ppds: bug 647460
<ubottu> Launchpad bug 647460 in update-manager (Ubuntu) "Upgrade from 10.04 to 10.10: printconf is blocking the upgrade." [High,Triaged] https://launchpad.net/bugs/647460
<mvo> jibel: thanks
<cjwatson> smb: sconklin> fixed
<pitti> cjwatson: I want to do some no-change rebuilds for NBS cleanup; do you prefer to review them, or can I just accept them myself?
<cjwatson> no-change rebuilds should be fine as long as they aren't packages with giant buildd times
<cjwatson> (I meant to type "build" but that's good enough ...)
<cjwatson> pitti: which packages?
<pitti> cjwatson: I didn't start yet
<cjwatson> note that libopensync-plugin-gnokii needs a non-trivial source change
<cjwatson> I'm not sure if anyone is looking at the opensync cluster
<lifeless> I ran screaming
<cjwatson> it wasn't obvious to me that there were huge numbers of no-change uploads available from NBS any more (doko has been cleaning a lot of stuff up), but absolutely go ahead if you find some
<cjwatson> my suspicion is that most of the rest require source work
<lifeless> I think my name is still on part of it simply because it hasn't been uploaded outside of experimental, or some such.
<pitti> I'll see how far I'll get
<lifeless> night all
<pitti> cjwatson: but I guess stuff like libavutil49, libindicator0, libvala0 should be triviall
<pitti> I'll just start from the top
<cjwatson> libvala0 is just libvala-dev and those are all build-deps
<cjwatson> libindicator0 is just ubiquity which is already in progress
<cjwatson> libavutil49 not sure, it's different between architectures so will require some analysis
<pitti> libvala-dev is NBS itself; I'll check the rdepends for having alternatives to libvala-0.10-dev
<cjwatson> right
<cjwatson> pitti: BTW, I rewrote checkrdepends over the weekend - it has a slightly different argument syntax now
<pitti> I noticed
<cjwatson> though that wasn't the point, the point was to get cron.NBS runtime down to a minute
<pitti> it's using launchpadlib now?
<cjwatson> no
<hemanth> ImportError: No module named nautilus, even after installing python-nautilus, any suggestions?
<pitti> perhaps we should add this to ubuntu-archive-tools bzr
<cjwatson> it's still analysing Packages/Sources directly, but it's a lot faster to do that inline in python rather than repeatedly calling grep-dctrl
<cjwatson> sure, if you like, though we don't have that checked out anywhere on cocoplum right now
<pitti> nice
<cjwatson> faster> well, at least if you're asking about large numbers of packages at once
<cjwatson> also, I just made it look at main/installer-*/current/images/udeb.list, so it can now spot when d-i is still using a given kernel ABI and create an artificial dependency
<cjwatson> which should save us from future accidents
<pitti> ah, right, we use /srv/archive-scripts/bin bzr right now
<pitti> hm, it would be easier if libvala0.10-dev would Provides: libvala-dev..
<pitti> didrocks: ^ WDYT?
<didrocks> pitti: I think it's safe to do that, right
<didrocks> I don't see any reason that people want to build with previous buggy vala version
<pitti> didrocks: I mean it's easier than adding alternative build-deps to http://people.canonical.com/~ubuntu-archive/NBS/libvala-dev
<didrocks> pitti: yeah, I agree, do you want to do the change? I'll report it to debian then.
<pitti> didrocks: would be nice; thanks!
<didrocks> pitti: thank to you :)
<pitti> didrocks: actually, no
<pitti> didrocks: Debian didn't rename them that way
<pitti> they just use unversioned packages
<pitti> I'm not quite sure why we went through the hassle of versioning them
<cjwatson> could somebody look at bug 648469 and check what the right fix is?  then we can remove python-gnome2-desktop and python-gnomeprint
<ubottu> Launchpad bug 648469 in labyrinth (Ubuntu Maverick) "depends on NBS python-gnome2-desktop" [High,New] https://launchpad.net/bugs/648469
<pitti> I'll just add the provides:, and NBS libvala{0,-dev}
<pitti> cjwatson: for powerpc specific FTBFSes which block NBS removal, I guess we'll just remove them anyway and say "*shrug*"?
<cjwatson> if they're leaf packages we can do that
<didrocks> pitti: debian did it in 0.9.5-1 IIRC
<cjwatson> is dpm on holiday or something?
<pitti> didrocks: no, see http://packages.qa.debian.org/v/vala.html
<cjwatson> pitti: one thing only you can do, since dpm doesn't seem to be around; there are several uninstallable language packs
<pitti> cjwatson: will look at those
<cjwatson> thanks
<pitti> vala uploaded with the new provides:; it's not a no-change upload, so I'll let someone else review it
<pitti> didrocks: ^
<didrocks> pitti: I think I don't understand :) I didn't do the merge (was in vacation) but it seems nevertheless, they have a libvala-0.10-dev package shown in http://packages.debian.org/source/experimental/vala or is there something I'm missing?
<pitti> didrocks: ah, in experimental only; I see
<pitti> didrocks: ok, thanks for forwarding
 * didrocks is not crazy (yet!) :p
<pitti> cjwatson: did dpm happen to talk to you about the final maverick langpack set?
<\sh> pitti: could you approve ecs pls, thx :)
<cjwatson> pitti: no
<cjwatson> (I don't think so)
<pitti> cjwatson: ok, thanks; we'll need a fresh -base rebuild and thus a full export
<pitti> it's too late to squeeze it into the RC for Thursday, but I'll request one now and build them locally, so that we can upload them right after RC
<pitti> cjwatson: ^ sounds okay to you?
<pitti> current langpacks cause an extra 7 MB on the alternates, and make them overflow, but we can just drop a langpack there for the RC
<cjwatson> OK for after RC, yes
<Riddell> pitti: the LanguagePackTranslationDeadline is Sep 30th
<cjwatson> what about the current uninstallables?  do those need that fresh rebuild?
<pitti> that, too
<cjwatson> they're causing some livefs build failures
<cjwatson> so we'll need to work around that
<pitti> the -kde variant for those is newer than the main one
<cjwatson> at least edubuntu-dvd
<pitti> we could drop the strict dependency from -kde-base to -base
<pitti> in fact, I think I can make this change in the langpack-o-matic templaltes
<pitti> but that will only get effective at the next upload, of course
<cjwatson> or we could exclude those language packs from the build
<cjwatson> I think that's preferable for RC
<pitti> for RC, yes
<pitti> and after that it'll fix itself
<cjwatson> right, we won't need the langpack-o-matic hack
<cjwatson> \sh: accepted
<pitti> didrocks: so you'll do the yelp update for bug 605577? I'll manually fix the -gnome-en langpack now, then
<ubottu> Launchpad bug 605577 in language-pack-gnome-en-base (Ubuntu Maverick) "Help contents title bar shows cubes with numbers instead of a proper title" [High,In progress] https://launchpad.net/bugs/605577
<didrocks> pitti: oh, as you wish. I've assigned to me before you told you wanted to handle it, but if you want to do both, please do :)
<pitti> didrocks: ok, I'll have a look
<didrocks> pitti: thanks :)
<\sh> cjwatson: thx
<pitti> seb128: why do we carry a manual patch 07_rosetta_translations_update.patch in yelp?
<pitti> seb128: especially because this patch isn't in the series?
<didrocks> pitti: the patch isn't in the series during unstable update IIRC to avoid having to refresh it at each new ustream version. It should be added back in final upload
<didrocks> (just using my memory, not 100% sure about it but that should be that :))
<pitti> didrocks: ok; I fixed the patch, but I won't upload it right now, since it's not currently cuasing trouble
<pitti> bug updated as well; so we just need to accept the new -gnome-en-base, and everything is well again
<cjwatson> pitti: accepted
<pitti> cheers
<jibel> latest python-virtkey is broken in maverick. bug 648695
<ubottu> Launchpad bug 648695 in virtkey (Ubuntu) "package python-virtkey (not installed) failed to install/upgrade: file does not exist: /usr/lib/python2.6/dist-packages/python_virtkey-0.60.0.egg-info" [Critical,Triaged] https://launchpad.net/bugs/648695
<seb128> pitti, sorry I was at lunch
<seb128> pitti, what didrocks say on the serie
<pitti> seb128: ok, thank you
<seb128> pitti, we carry the patch because translated xml are generated on build
<seb128> so they don't work with langpacks
<pitti> ah, I see
<RAOF> pitti: Re: mesa - it's been tested by me, Sarvatt, ScottK, and mvo thus far, and is now actually from the 7.9 release branch.
<doko> RAOF: btw, what is the replacement for the dropped mesa-utils?
<RAOF> doko: The split-out mesa-demos on revu http://revu.ubuntuwire.com/p/mesa-demos
<RAOF> Upstream dropped the code we shipped in mesa-utils from the main mesa tree between 7.8 & 7.9
<RAOF> mesa-demos is exactly that code, now released as a separate project.
<doko> RAOF: somebody reviewing this currently?
<RAOF> No.
<doko> ok, looking at it
<RAOF> Thanks.
<\sh> doko: could you push sun-java6 6.21dlj to c. partner repo? you could use the package from https://edge.launchpad.net/~sun-java-community-team/+archive/sun-java6
<\sh> for maverick that is...dunno if someone else can do this
<doko> \sh: I'll have a look
<\sh> doko: thx a lot :)
<doko> RAOF: is the complete 11MB source really needed?
<RAOF> doko: I could repack the tarball and strip everything we don't ship out, for Maverick.
<RAOF> For Natty I want to ship *all* the demos in a separate package, as they're useful for users to pinpoint problems in mesa.
<doko> ok, then it makes sense
<doko> RAOF: uploaded, waiting in NEW
<RAOF> doko: Awesome, thanks.
<doko> RAOF: needed for http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils (openened a bug for mesa, although bryce2 did tag it as ppc, don't know why)
<RAOF> That'd be an arsenal script, probably grabbing from the powerpc in the text of the bug.
<RAOF> I closed that mesa bug in the changelog, right?
<RAOF> Yes, there it is.  Good :).
<RAOF> I'm off to bed now.  If you want to discuss mesa with someone pitti I'll point you at Sarvatt for the next 10 hours or so :).
<pitti> RAOF: ok, thanks
<jibel> pitti, fglrx-installer verified in jaunty too.
<pitti> jibel: nice, thanks
 * pitti moves to -updats
<\sh> hmm...can someone translate this buildlog for me? It says, FTBFS but everything is ok it seams
<\sh> seems even: http://launchpadlibrarian.net/56574998/buildlog_ubuntu-maverick-amd64.emerald_0.7.2-0ubuntu5_FAILEDTOBUILD.txt.gz
<wgrant> \sh: Look at the end of the log.
<wgrant> The implicit pointer conversion thing.
<\sh> wgrant: yeah I saw it, but the reason seems to be a bit misleading..the package builds perfectly, eventually LP needs to be trained to give another reason for arch problems
<cjwatson> \sh: it's a recognised hack
<\sh> cjwatson: I mean the subject of the mail , that was irritating me :)
<cjwatson> sure, like I say, it's not a particularly clean hack and everyone involved in creating it knew this :-)
<corecode> hey
<corecode> the last gnome-terminal update on lucid changes some useful defaults
<jibel> pitti, I've added a bugpattern for the current virtkey issue but it's not pushed to http://people.canonical.com/~pitti/bugpatterns/ . Are commits to the lp branch still rolled out every 15mn ?
<pitti> jibel: they should, yes
<pitti> */15 * * * * env LC_ALL=C bzr pull -q -d ~/public_html/bugpatterns >/dev/null
<pitti> should have happened 4 mins ago, let me check
<pitti> jibel: it's at r147 for bug 642518
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu Karmic) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Fix released] https://launchpad.net/bugs/642518
<pitti> jibel: a manual pull doesn't bring anything new; did you push?
<jibel> pitti, yes I've pushed it, but can't find it anywhere and I'm still at r147 :/ probably another pebkac, retrying. sorry
<pitti> jibel: worked now
<jibel> pitti, yes, thank you. I really don't know where my previous push is gone.
<tkamppeter> pitti, hi
<pitti> jibel: to the place whe all the lost socks and pens go?
<pitti> hey tkamppeter
<jibel> pitti, very likely :)
<tkamppeter> pitti, last week I got a patch from Japan for the pdftopdf filter so that it builds with Poppler 0.15.x without loosing compatibility with older Poppler versions. I have applied it only to the upstream CUPS add-on package but not (yet) to the BZR at Debian.
<tkamppeter> pitti, now I want to ask whether I can already apply it to the BZR (withoutbeing packaged for Maverick) or whether I should wait for Maverick being released.
<pitti> tkamppeter: is that important for maverick? we already have the new poppler, after all?
<pitti> tkamppeter: oh, please push it; it's the Debian unstable development tree, after all
<pitti> tkamppeter: if we need another maverick change, we'll branch it
<tkamppeter> pitti, thanks, I wll push it.
<tkamppeter> pitti, done.
<pitti> Riddell: does the dbus you just uploaded differ in any way to the one from 2 hours ago?
<tkamppeter> pitti, can you have a look at bug 647369? It is probably a problem caused by the upstartification of CUPS?
<ubottu> Launchpad bug 647369 in gutenprint (Ubuntu) "gutenprint: postinst: lpstat: no such file or directory" [Undecided,Incomplete] https://launchpad.net/bugs/647369
<pitti> tkamppeter: very unlikely -- it seems it can't find /usr/bin/lpstat, but I wouldn't know why
<pitti> it's in cups-client, which is installed
<\sh> ttx: will you give libspring-2.5-java a new punch to actually build on maverick? ;)
<tkamppeter> pitti, the "lpstat: no such file or directory" is caused by lpstat being called to quickly after CUPS being started. In that moment CUPS has not yet created the socket file /var/run/cups/cups.sock
<pitti> ah
<tkamppeter> pitti, if lpstat is not found, one would get "Command not found".
<ttx> \sh: *sigh*
<tkamppeter> pitti, simply try "sudo stop cups; sudo start cups; ls -l /var/run/cups/cups.sock"
<\sh> ttx: there are some packages which are in need of it ;)
<pitti> right, that'd start in the background
<Riddell> pitti: fixed .symbols file
<pitti> Riddell: ah, so I'll reject the previous upload
<pitti> Riddell: (done)
<tkamppeter> pitti, formerly, the "invoke-rc.d cups force-reload" exited only after CUPS was ready and so the next line in the script could already use CUPS.
 * ttx punches
<\sh> ttx: rocking :)
<tkamppeter> pitti, so the backward compatibility commands, like "invoke-rc.d", "service", "/etc/initd.*" should wait for the service getting ready before exiting.
<pitti> yes, indeed
<tkamppeter> pitti, should I move the bug to upstart and target it for Maverick?
<pitti> so this would require a rather ugly while status cups | grep -q start/running loop
<tkamppeter> pitti, in the gutenprint postinst script works adding
<tkamppeter>  for i in 1 2 3 4 5; do if [ -r /var/run/cups/cups.sock ]; then break; fi; sleep 1; echo -n "."; done; echo;
<pitti> ah, I see; but 5 seconds wasn't enough there?
<tkamppeter> but this fixes only the reported problem with Gutenprint, there are probably many more.
<pitti> Keybuk: ^ would it be realistic to have invoke-rc.d (on an upstart job) wait until the servie is "start/running"?
<tkamppeter> pitti, the loop breaks as soon as the file appears, for me always after one second, but there can be slower systems.
<pitti> that might break tasks, though?
<Keybuk> pitti: a better question would be to ask why invoke-rc.d doesn't wait for that right now
<tkamppeter> pitti, "start/running" is perhaps not even enough, as I get
<tkamppeter> till@till:~/ubuntu/gutenprint$ sudo stop cups; sudo start cups; ll /var/run/cups/cups.sock
<tkamppeter> cups stop/waiting
<tkamppeter> cups start/running, process 23356
<tkamppeter> ls: cannot access /var/run/cups/cups.sock: No such file or directory
<tkamppeter> till@till:~/ubuntu/gutenprint$
<tkamppeter> pitti, so a start/running is reported but the file is still not there.
<pitti> tkamppeter: hm, but that's something that the original init script didn't do either
<Keybuk> pitti: blocking is the default behaviour for "start"
<Keybuk> to *avoid* start blocking until its start/running, you'd need --no-wait
<pitti> Keybuk: ah, thanks; so it's probably unrelated (see above, we need to wait on the socket to appear)
<Keybuk> right
<Keybuk> you can use a post-start script for that
<Keybuk> e.g.
<Keybuk> post-start script
<Keybuk>    while [ ! -e /var/run/cups/cups.sock ]
<pitti> cups has one already for the coldplugging
<Keybuk>   do
<Keybuk>     :
<Keybuk>   done
<Keybuk> end script
<Keybuk> right
<pitti> (perhaps a sleep .5)
<Keybuk> well, yes, a sleep in there would be less "my cpu! mine!"
<pitti> Keybuk: and actually giving the CPU to cupsd to start :)
<tkamppeter> pitti, with
<tkamppeter> sudo killall cupsd; sudo /usr/sbin/cupsd; ll /var/run/cups/cups.sock
<pitti> tkamppeter: this indeed seems conceptually unrelated to the upstartification, but the different timing behaviour might have made it more probable
<pitti> tkamppeter: so, I'm fine with cups' upstart script waiting until the daemon is ready
<tkamppeter> one never gets "no such file or directory". And this is what the old init script did.
<pitti> ah, right; previously we had cupsd take care of the forking
<pitti> now we call it with -f and have upstart do the fork
<cjwatson> \sh,ttx: libspring-2.5-java needs a manual build; we have a sysadmin ticket open for it and they will do it this week
<tkamppeter> "cupsd -f" should only be used for debugging not for regular use.
<ttx> cjwatson: arh, ok
<ttx> cjwatson: looked like a transient error
<pitti> tkamppeter: hang on
<Riddell> sladen: how's that font package doing?
<pitti> tkamppeter: pushed to r906
<pitti> tkamppeter: I'll create a maverick branch (which we will also use for SRUs) and cherrypick it there
<pitti> tkamppeter: lp:~ubuntu-printing/cups/maverick
<sladen> Riddell: sabdfl is working on licencing at the moment, or was until robbiew filed a higher-priority interupt
<tkamppeter> pitti, thanks.
<sladen> Riddell: so whenever that's finalised plus some number of hours to implement
<Riddell> sladen: are you doing the implementing?
<pitti> tkamppeter: uploaded; needs someone else to review now
<tkamppeter> pitti,
<tkamppeter> sudo stop cups; sudo start cups; ll /var/run/cups/cups.sock
<tkamppeter> works for me now, but
<pitti> tkamppeter: I ran that in a loop for about 10 minutes
<tkamppeter> sudo /var/lib/dpkg/info/cups-driver-gutenprint.postinst  configure
<tkamppeter> still does not work.
<pitti> tkamppeter: I just get a complaint about invoke-rc.d being out of date, and
<pitti> lpstat: No destinations added.
<pitti> tkamppeter: what do you see?
<tkamppeter> pitti, I get the originally reported
<tkamppeter> lpstat: No such file or directory
<pitti> # while true; do stop cups; sleep 0.5; start cups; lpstat -p; done
<pitti> that's what I'm running
 * pitti refines to # while true; do stop cups; start cups; lpstat -p 2>&1|grep -q "No destinations" || exit 1; done
<pitti> tkamppeter: you are using my updated upstart script now?
<tkamppeter> pitti, can it be that this post-install script does a "reload" of CUPS instead of stopping and starting it?
<tkamppeter> pitti, in which way does upstart this "reload" of CUPS?
<pitti> perhaps; I'm not sure what reload does, hang on
<pitti> so, above loop works fine for me
<cjwatson> 'man reload' tells you what upstart's reload does
<sladen> Riddell: yes
<pitti> tkamppeter: ah, right, it SIGHUPs the daemon
<Riddell> sladen: ok let me know when you're starting that.  and robbiew stop distracting Mark :)
<tkamppeter> pitti, try it with "reload cups" instead of "stop cups; sleep 0.5; start cups;".
<pitti> tkamppeter: right, I can reproduce it there
<tkamppeter> pitti, the "reload" does not stop and start CUPS it simply HUPs at it.
<pitti> tkamppeter: but that's what the init.d script did as well
<pitti> tkamppeter: so in this regard the upstartification should make no differernce
<pitti> Riddell: erm, upgrading dbus from 1.2 to 1.4 at this time? this is an awfully big diff for a such a critical service
<Riddell> pitti: yes, I realise it's a long shot
<Riddell> but it does stop random crashes happening in threaded apps which use dbus
<tkamppeter> pitti, so you have fixed an independent problem which also had to get fixed and I should add a wait loop to the postinstall script of Gutenprint?
<pitti> can't we backport the race condition fix?
<pitti> tkamppeter: yes, I think so; can you please add back a gutenprint task then?
<Riddell> pitti: I'm told we can't, the patch isn't reliable in the 1.2 version
<pitti> I remember that we discussed that earlier on around beta time, and back then we thought it was too intrusive
<Riddell> pitti: well at least I can tell upstream I tried :)
<pitti> bjf: you uploaded linux-mvl-dove to maverick-proposed instead of final, was that intended?
<bjf> pitti, no
<pitti> bjf: ok, I guess I should reject it then, and you'll reupload to maverick?
<bjf> pitti, yes, please reject it
<tkamppeter> pitti, new gutenprint package uploaded.
<pitti> tkamppeter: thanks, will review in a bit
<smb> pitti, That upload of mvl-dove should have been made by Tim. But please reject the fsl-imx51 in Karmic
<pitti> smb: done
<smb> thanks
<sladen> Riddell: realistically, tomorrow at the earliest
<Riddell> sladen: we'll be frozen for RC by then
<Riddell> it'll need to wait until Thursday
<maco> cjwatson: these quality status emails keep making me go "must buy cjwatson a $beverage"
 * cjwatson wonders how he's managing that; perhaps sync processing
<bdrung_> doko_: why did you close bug #640732?
<ubottu> Launchpad bug 640732 in audacious-plugins (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Invalid] https://launchpad.net/bugs/640732
<doko_> bdrung_: glibc patch not accepted upstream?
<bdrung_> doko_: according to audacious upstream it's fixed in gcc-4.5, but not in gcc-4.4
<doko_> bdrung_: and why do thy send a pointer to a glibc patch? and what needed fixing in gcc?
<bdrung_> doko_: quote: "This is a duplicate of AUDPLUG-241. It was ruled to be a bug in the STL shipped by GCC 4.4, which has been fixed by GCC 4.5."
<doko> bdrung_: sorry, do *you* understand the reasons for "It was ruled to be a bug" ?
<dapal> doko: (OT: care to reply to DBTS #573745 ?)
<bdrung_> doko: i don't understand the bug.
<bdrung_> doko: let's make the test if it works with gcc-4.5
<didrocks> urgh, seems amd64 builders have some issues, known?
<bdrung_> doko: it works if i am using CXX=g++-4.5, but it fails if g++-4.4 is used
<didrocks> seems there are really an issue, second fail: https://launchpad.net/ubuntu/+source/unity-place-files/0.5.30-0ubuntu1/+build/1977028/+files/buildlog_ubuntu-maverick-amd64.unity-place-files_0.5.30-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> didrocks, those are an arch all,any mistmatch issue
<seb128> libunity-dev : Depends: libunity0 (= 0.2.44-0ubuntu1)
<seb128> didrocks, it seems you just need to have unity published on amd64 and retry
<didrocks> seb128: urgh, I stopped too early, just stucked at sh: gcc: not found
<didrocks> sorry, yeah
<didrocks> well, new unity release upladed soonâ¦
<doko> chrisccoulson_: please use dh_python2 for future python packaging (instead of python-central)
<dapal> doko: re-ping?
<doko> dapal: ?
<dapal> [20:35:47] <dapal> doko: (OT: care to reply to DBTS #573745 ?)
<doko> how does the affect ubuntu?
<dapal> doko: I prefixed that with OT, and I see you're active here, and never replied to any mail directly sent to you
<dapal> doko: so I just caught the chance to ping you here. I could've also done that privately.
<doko> not today, sorry
<dapal> doko: can I have an ETA?
<dapal> doko: also, that bug is open since March, I would expect much more consideration from a fellow DD
<lifeless> is there a blessed way to check if a process is running ?
<ogra_ac> pgrep ?
<lifeless> mmm, api wise I meant - its in python
<ogra_ac> oh, k
<ogra_ac> :)
<soren> lifeless: os.kill(pid, 0)
<soren> lifeless: I suppose.
<soren> lifeless: Whether it's the process you're expecting it to be... That's a different story.
<lifeless> yeah
<soren> lifeless: ..but kill(2) with a signal 0 checks if there's such a process.
<lifeless> there is some dodgy code in lp's test runner
<lifeless> to delete it entirely is the long term goal, but its going to be an iterative thing; gotta get it into a nicer layout, then build on that to get better isolation, then the old cruft can go
<soren> lifeless: If you start the process yourself, you can keep track of its cmdline and check /proc/blah/cmdline (assuming the process doesn't alter that).
<ebroder> If it's a child process you could wait4() on it with WNOHANG
<lifeless> it wouldn't be, but thanks
<mar> my ubuntu clock freezed at 00:01. What do I do? :)
<ogra_ac> wind it up
<mar> in ubuntu even clock doesn't work right :/
<sladen> mar: please take a screenshot
<sladen> mar: please file it at  http://launchpad.net/ubuntu/+source/gnome-panel/+filebug
<sladen> mar: including information about your timezone
<micahg> mar: actually, running 'ubuntu-bug gnome-panel' will probably be better
<mar> i changed settings a little and seems that it's running now
<mar> it happened a lot to me for a few days so i'll try to catch it later
#ubuntu-devel 2010-09-28
<YokoZar> cjwatson: I would really appreciate the new upstream icoutils in Debian (and working its way to Ubuntu), since I need the new version to show Vista-era embedded icons with gnome-exe-thumbnailer
<Riddell> RAOF: is mesa-demos for main or universe?
<RAOF> Universe.
<SpamapS> mathiaz: you were asking before about the drizzle stuff...
<mathiaz> SpamapS: yeah - I've read your update on teh bug
<mathiaz> SpamapS: IIUC we'll wait for debian
<SpamapS> mathiaz: right.. going through licenses now
<SpamapS> mathiaz: there are a few bash scripts and such in drizzle that have unclear licensing.. I'm contacting authors asking them to send in patches adding license headers ... is that overkill?
<mathiaz> SpamapS: not necessarly
<mathiaz> SpamapS: how critical are the scripts?
<mathiaz> SpamapS: would it be easier to just replace the scripts?
<mathiaz> SpamapS: rather than chasing down proper licensing?
<SpamapS> most are examples or config/contrib helper bits
<SpamapS> mathiaz: some yes thats already been done.. a few of them are super tedious scripts.. the kind you're super thankful somebody did so you don't have to. ;)
<ebroder> tseliot: ping?
<mathiaz> SpamapS: agreed - contact the author then
<mathiaz> SpamapS: and get in touch with the drizzle team to make sure it doesn't happen again ;)
<SpamapS> mathiaz: they're discussing a hudson trigger to flag file adds that don't have the word 'copyright' or 'license' in them
<mathiaz> SpamapS: nice :)
<SpamapS> mathiaz: I'm a little confused as to how to get started submitting blueprints for uds-n
<SpamapS> mathiaz: do I just create one, fill in the blurb, and pray? ;)
<mathiaz> SpamapS: let me check my email
<mathiaz> SpamapS: there was a message that outlines the process
<pitti> Good morning
<pitti> Riddell: FYI, if the current images are oversized, please just remove a langpack; we'll get fresh ones right after RC and can then put them back
<Riddell> pitti: done
<Riddell> "ask MartinPitt to disable apport via update-notifier (for RC)"
<Riddell> pitti: how's that doing? ^^
<pitti> oh, good call
<pitti> Riddell: I'll upload it right now, together with kerneloops
<pitti> Riddell: there's an additional script change to debian/local/ubuntu-fat-chroot which I had in bzr; it's not used on clients at all, but just for generating chroots for the retracers
<Riddell> fine with me
<pitti> both uploaded
<pitti> I added kerneloops to the checklist
<pitti> Riddell: traditionally we disabled them right after the RC, so they could stay in the queue until Thursday
<pitti> but if you prefer getting them in now, no objections from my side
<Riddell> if that's what tradition dictates that's what we should do
<cjwatson> YokoZar: somebody was supposed to be adopting icoutils from me, but then went quiet :-/
<YokoZar> cjwatson: mind if I do it then?
<cjwatson> YokoZar: go ahead
<jibel> can somebody moderate my email to ubuntu-devel ?
<cjwatson> jibel: done
<jibel> cjwatson, thank you.
<maxb> With release more and more impending, who can I ask to find out whether someone is planning to handle sun-java6 upload to the partner archive before release?
<maxb> NB that this is an odd package, because it is synced from Debian non-free to the partner archive
<cjwatson> if it's just a sync, file an archive bug for it and we'll figure it out
<cjwatson> I seem to remember syncing into partner was fiddly, but nevertheless
<cjwatson> (I have an e-mail trail somewhere which I can dig out)
<\sh> maxb: doko is on it, i think, as I was asking the same yesterday
<maxb> Ah. Provided someone's visual that it really needs to happen in time for release, that's good
<apw> pitti, i was wondering about natty work items (again :) and wondered if that is something i could help with, looks like the automation is per series at the cron level
<pitti> apw: in principle, it shoudl be sufficient to add a config/natty.cfg to the WI tracker
<pitti> the rest should Just Work (tm)
<apw> pitti, won't that put them under maverick though?
<apw> pitti, ahh no perhaps not i thought lenaro etc was mixed in there but perhaps not
<apw> pitti, shall i put one together ?
<pitti> apw: not if it says release = 'natty'
<pitti> apw: but there is no natty release in LP yet, so it wouldn't work
<apw> (i assume you are snowed under right now0
<pitti> and likewise, there can't be natty-targetted specs in LP
<apw> doh ... i'll shut up then
<Chipzz> dapal: why do you think bringing up a *debian* bug full of ad hominem attacks on #ubuntu-devel is appropriate? especially during final freeze?
<mr_pouit> Chipzz: and why do you care? especially during final freeze? (they can probably handle that themselves without you)
<dapal> Chipzz: apologies for bringing that here.
<Chipzz> dapal: maybe my reaction was a bit harsh, but I just don't think #ubuntu-devel is the right place to talk about contraversial issues (dare I say flamewars?) concerning only the debian project
<Chipzz> anyway no need to apologize to me; I'm not an ops or whatever here; I just thought it didn't belong here and there are other avenues of resolving it
<dapal> Chipzz: I don't want to continue it here; but seeing a person ignoring all pings from one side, and being very active on the other one is.. sad.
<dapal> just IMVHO
<dapal> anyways, I'm off, bbl
<zul> pitti: hi when you get a chance can you let the landscape-client SRU to go into proposed?
<smb> pitti, And if you have a little more time, there are rebases for the current lucid master of fsl-imx51 and mvl-dove. Can we get them into proposed as well? ec2 will hopefully follow shortly.
<pitti> zul: ah, thanks for the reupload; will do
<zul> pitti: thanks
<pitti> smb: yup
<smb> pitti, cool
<YokoZar> what is the correct way to give a file in a package a linux capability?  setcap requires root but packages don't build as root, and I'm hesitant to add setcap to the maintainer script...
<pitti> YokoZar: there's no packaging mechanism for that
<YokoZar> pitti: for some reason I thought ping had cap_net_raw rather than run suid 0
<pitti> YokoZar: usually you'd start the program as root and then call capset()
<pitti> and then setuid()
<YokoZar> pitti: so I'd need some sort of wrapper?
<pitti> YokoZar: not really, just some startup code (prctrl, setcap, and setuid), and making the program suid root
<persia> pitti, Presume that upstream didn't provide any of that :)
<pitti> YokoZar, persia: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch
<persia> Oh, cool!
<persia> Thanks.
<pitti> that's a convenience function that I wrote about a million years ago
<pitti> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch shows how to use it
<pitti> but it boils down to
<pitti> cap_value_t capsneeded[] = { CAP_NET_RAW, CAP_NET_BIND_SERVICE };
<pitti> drop_privileges( "dhcp", "dhcp", 2, capsneeded, -1 );
<pitti> the first two are user and group name
 * pitti yays at bzr archeology
<YokoZar> pitti: thanks, that seems useful
 * YokoZar thinks a debhelper extension for filesystem capabilities support at the packaging layer would be best...
<pitti> YokoZar: are we really talking about the same thing here?
<pitti> fs capabilities != kernel capabilities
<pitti> I suppose you mean capabilities(7), since Linux has fs ACLs, not capabilities
<YokoZar> pitti: kernel caps can be made permanent with extended attributes on a file, yes?
<pitti> YokoZar: alternatively you can ship an apparmor profile
<YokoZar> (ie, what setcap from libcap-bin does)
<pitti> YokoZar: I don't know; I just know extended ACLs, which are unrelated to kernel caps
<YokoZar> pitti: I think when you wrote the linked code the kernel didn't support file-based capabilities lists and it all had to be done at runtime, so dropping them was the only option
<pitti> YokoZar: right, but I still wouldn't bet on fs support
<pitti> not as long as we still get bugs with /usr on NFS, or using about five different file systems
<pitti> I'd rather prefer apparmor profiles then; they can specify caps, too
<YokoZar> pitti: fair enough...I take it NFS doesn't support extended attributes at all then?
<pitti> I can't say for sure -- just that I wouldn't bet on it :)
<pitti> it might do
 * YokoZar wonders if one of the columns on http://en.wikipedia.org/wiki/Comparison_of_file_systems#Metadata  is helpful here
<hyperair> http://apachelog.wordpress.com/2010/09/21/an-inconvenient-truth/ <-- this sure says something about the GNOME environment in ubuntu, doesn't it?
<cjwatson> page not found
<cjwatson> s/21/28/ apparently
<hyperair> cjwatson: i dunno, i picked it out of my rss feed.
<shadeslayer> hyperair: :>
 * shadeslayer has secret link to that page
<hyperair> lol
<shadeslayer> it works only in Kubuntu :P
<hyperair> bull. i read it on liferea
<hyperair> ;-)
<shadeslayer> http://apachelog.wordpress.com/2010/09/28/an-inconvenient-truth/
<shadeslayer> :D
<shadeslayer> but i seriously had super secret link to that post :P
<jcastro> skaet, when you ping people for the TechnicalOverview can you remind them that linking to upstream project webpages and changelogs is very useful!
<jcastro> I just went in there and linked a bunch up
<jcastro> It's an opportunity for us to get attention to whatever upstream project we're talking about
<skaet> jcastro,  cool.
<skaet> jcastro,   sounds like a good idea.   Thanks for adding the links, and I'll add the reminder to the process checklist.
<james_w> jibel: hi, are you able to help debug the policykit/software-center bug you reported?
<james_w> unfortunately I have forgotten what I wanted to know next from someone that could see it
<jibel> james_w, of course, let me have dinner and deal with the kids and I can help in approximately 1 hour
<james_w> jibel: great, tomorrow if fine by me if it is your evening
<jibel> james_w, okay.
<SpamapS> apw: bump.. WI tracker looks a bit broken
<apw> SpamapS, hrm, how so
<SpamapS> apw: http://people.canonical.com/~platform/workitems/maverick/canonical-server-ubuntu-10.10.html
<apw> hrm, i wonder how i managed that
<apw> thanks for the heads up
<SpamapS> apw: I see the 'assignee' added to info, but never used.
<SpamapS> maybe you forgot a commit?
<apw> SpamapS, it gets used elsewhere, but that shouldn't matter as its a []
<SpamapS> Maybe something does a foreach on that hash
<apw> SpamapS, no, think i see it, a miss merge
<apw> just regen it here to confirm
<SpamapS> actually the DB might be borked
<apw> now that isn't meant to happen, its meant to protect that
<SpamapS> or not.. hrm
<apw> i think its the reporting thats bust
<SpamapS> yeah
<SpamapS> I had a cached local svg that confused me. ;)
<apw> ok i've pushed what i hope is the fix, but will have to wait till it re-gens to be sure
<SpamapS> I'm regenning locally now
<apw> SpamapS, cool ... let me know if it looks ok to you
<SpamapS> so far no, it looks very broken still
<apw> SpamapS, the error is gone yes ?
<SpamapS> ./burndown-chart -d ../maverick.db -t canonical-server -m ubuntu-10.10
<SpamapS> produces a flat chart
<apw> SpamapS, looks ok here to me
<apw> did you update ?
<SpamapS> apw: yeah I did a bzr pull
<apw> SpamapS, what version do you have
<SpamapS> 231
<apw> hrm
<SpamapS> and the latest maverick.db
<SpamapS> damnit
<apw> ?
<SpamapS> the bash completion on sqlite3 is *useless*
 * apw regets the DB to check
<apw> its still LARGE
<SpamapS> apw: we're looking at it over here, btw. ;)
<SpamapS> err
<SpamapS> ttx: ^^ we're looking at it over here
<SpamapS> sorry My brain is a little off right now.. :-P
<apw> if my internet connection was faster i'd have tested it by now
<apw> SpamapS, its possible the DB is sick then
<apw> not sure how that would be affected though
<SpamapS> it doesn't look sick.. hmm
<apw> i used an older DB i have here and get a sensible shaped output
<apw> trying yesterdays now to get a control
<apw> (by which i mean wiating for it to download
<apw> SpamapS, looks ok on yesterdays DB
<apw> SpamapS, could you confirm same for you?
 * apw pokes SpamapS 
<SpamapS> apw: in a meeting now.. but I'm downloading yesterday's db
<apw> SpamapS, i am at a loss to understand how yesterday can be broken
<apw> pitti, you about ?
<apw> SpamapS, if you find that db is ok ... then i suspect we'll want that copied over the current.  things ought to sort self out from there ... do you have acess to ~platform ?
<SpamapS> ok, so definitely the current .db is broken somehow
<SpamapS> no I've never logged into the box
<apw> it is beyond me to understand how anything other than todays data could be wrong, and it should get cleaned up by a respin
<apw> we'll see if that occurs i guess at the end of this run, but is suspect not
<SpamapS> I'm wondering if maybe the schema is munged
<apw> SpamapS, that would be even more unexpected
<SpamapS> no, schema is the same
<apw> it appears to run around the :05 mark, but i don't see a run at 19 yes
<apw> yet
 * apw runs the collector here to confirm its now ok
<apw> SpamapS, ok i took the broken DB from today, and ran the collector against it, and it seems to have sorted out that server report again
<apw> so i presume when the collector runs again it will clean up the db and fix the reports
<SpamapS> apw: interesting!
<SpamapS> apw: I'll keep an eye on it. You're definitely off the hook for your commits though. ;) thanks for taking a look.
<SpamapS> apw: its possible somethign on lillypilly was changed that broke the collector too.. lets hope not though
<apw> SpamapS, the only possibility that makes any sense is the breakage made 'today' empty and that broke the reports, but till we hit the collector cron again its hard to kwno if its ok now
<SpamapS> apw: it broke all of them.. I ran alpha-3 and it was flat
<SpamapS> probably a null somewhere confusing things
<apw> SpamapS, whats your line from that one
<SpamapS> ./burndown-chart -t canonical-server -m maverick-alpha-3 -o bork.svg
<SpamapS> -d maverick.db
<SpamapS> I should say
<apw> on my ./collect'ed update on the current borked one, i get a reasonable graph on that one too
<apw> SpamapS, i think we are good, but i wish i knew when the thing is mean to run
<pitti> hey apw
<SpamapS> I wonder if there's something wrong on lillypilly.. the collector just ran 1 hour ago.. and the graphs have been regenerated, and are still borked
<SpamapS> pitti: something's wonk with maverick.db
<pitti> SpamapS: oh, what's wrong?
<apw> SpamapS, i am not sure they did run actually
<apw> pitti, the run time is nearly two hours ago and wondering what happened to the 19:00 run
<apw> pitti, from my testing the fix i pushed should fix up the db
<pitti> it should start in 1 min
<apw> pitti, is there a logfile when it does i can watch ?
<pitti> no log; stderr gets sent to work-items-tracker-hackers@lists.launchpad.net, though
<pitti> running now
<pitti> we also have daily backups, in case we need to restore
 * SpamapS is confused by timezones I guess
<SpamapS> it runs in +0100 ?
<apw> pitti, cool ... i think it should recover .... i copied the db here and ran collect and it seemed to sort out the db
<pitti> 05 */2
<apw> pitti, oh its bi-hourly how is it?  thats my confusion
<pitti> it used to run every hour, but since the per-user charts it regularly overran
<pitti> so I bumped it to bi-hourly
<apw> now it makes sense
<apw> pitti, any idea how long it normally runs for on average these days ?
<pitti> apw: not really, I haven't looked since SpamapS's "don't process past milestones" change
<pitti> since most milestones are in the past now, it ought to be pretty quick
<SpamapS> pitti: the collect step just takes a few minutes, right?
<pitti> maybe 15
<lifeless> hi
<lifeless> I would love to know what API calls you spend lots of time on / call a lot
<pitti> lifeless: urlopen() :)
<lifeless> hah
<SpamapS> lifeless: you're like a junkie who needs his fix ;)
<pitti> there is no blueprint API
<pitti> SpamapS: don't stop him! don't stop him!
<lifeless> pitti: oh yeah, blocked on security in the model.
<lifeless> pitti: so, you're screen scraping ?
<SpamapS> pitti: wild horses couldn't keep him away!
<pitti> lifeless: we do use launchpadlib for WIs as bugs, but screenscraping for blueprints
<lifeless> pitti: We've been adding batching into some LP pages, I hope that didn't impact you.
<lifeless> SpamapS: Nick Kershaw +1
<pitti> lifeless: I think the lists have always been batched
<pitti> lifeless: it copes by calling with &batch=200 (or so)
<lifeless> pitti: some weren't. e.g. ubuntu/+assigments
<SpamapS> pitti: https://lists.launchpad.net/work-items-tracker-hackers/ is empty.. is archiving turned off?
<pitti> lifeless: we are just parsing ubuntu/$release/+specs
<pitti> SpamapS: I didn't know there was an archive
<pitti> I don't see how to turn it on
<lifeless> there's always an archive.
<lifeless> its populated a little slowly and lazily.
<jibel> james_w, ping
<james_w> hi
<SpamapS> pitti: I don't recall getting a message .. so maybe it hasn't received any yet?
<pitti> I didn't get any from the list either
<jibel> james_w, what do you want me to debug/test with the policykit/s-c bug ?
<SpamapS> pitti: I suppose that means its working and not spitting out errors. :)
<pitti> SpamapS: I just sent a test mail to the lst
<pitti> SpamapS: I just got it back, did you?
<lifeless> pitti: a small request
<lifeless> pitti: could you change the work item stuff to not claim to be noreply@launchpad.net ?
<pitti> I could actually set it to the ML now, I suppose
<lifeless> Two angles: firstly, approximately noone in the lp dev group knows about it :P, and secondly its horrible to get mail that you cannot contact the sender.
<pitti> lifeless: done
<lifeless> thanks!
<james_w> jibel: sorry, the phone rang
<jibel> james_w, np
<james_w> jibel: I'm just grepping my logs to find the last time I looked at this, so that I can find the commands to run
<apw> SpamapS, that looks a lot better to me  ... think we are good
<james_w> jibel: so, I have a patch which may fix it, but it was last built in karmic, I'm just going to update it
<jibel> james_w, attach the patch to the report when it's ready. I'll give it a try.
<james_w> jibel: I just uploaded a patched package to https://edge.launchpad.net/~james-w/+archive/polkit/+packages
<james_w> jibel: if you could test that it would be great. After installing it you need to kill polkit-gnome-authentication-agent-1
<james_w> jibel: if you can still reproduce then killing polkit-gnome-authentication-agent-1 again, and stracing it would be valuable
<james_w> jibel: in order to strace it properly you will temporarily make strace setuid
<SpamapS> apw: agreed.. :)
<jibel> james_w, there's no version for maverick, the version to test is policykit-1 - 0.96-2ubuntu1 for lucid  ?
<james_w> jibel: oh, uploaded to the wrong distroseries
<james_w> jibel: yes, that's the version
<highvoltage> is it just me, or should the "i386" architecture as we call it in Ubuntu actually be called "i686" these days?
<azeem> where "these days" == "since warty" or so
<highvoltage> heh :)
<cjwatson> highvoltage: the architecture name is an identifier assumed constant all over the place, and excruciatingly painful to change
<cjwatson> there are so many other useful things that could be done with the effort involved in a rename
<cjwatson> so, let's not
<elmo> (see also 'amd64')
<lifeless> 'emt64'
<lifeless> :P
<cjwatson> it's EM64T actually
<cjwatson> ("Extended Memory 64 Technology".  Catchy Intel names 'r' us)
<elmo> they don't have enough  money for a very big marketing dept is the problem
<lifeless> cjwatson: hah, woops.
<Keybuk> err
<Keybuk> I'm pretty sure Intel dropped EM64t
<Keybuk> and now just call it Intel 64
<cjwatson> renamed to ia-32e, renamed to intel 64
<cjwatson> oh, ia-32e was before em64t according to wp
<cjwatson> though their cpu reference manual still says ia-32e
<azeem> ia32 2.0
<Keybuk> ia33
<cjwatson> (in places; it describes the architecture as a whole as Intel 64, but for instance there's "IA-32e paging"
<cjwatson> )
<Keybuk> heh, different parts written by different engineers at different times
<Keybuk> some parts could have been written by people who hadn't been told about the change of name
<Keybuk> I mean, it's not like companies haven't changed platform names when the CEO has dicked around with the slides 10 minutes before going on stage for his Keynote
 * ogra_cmpc wonders what will happen if he pins udev at 0.125 and upgrades
<ogra_cmpc> s/upgrades/cross grades from lenny to ubuntu/
#ubuntu-devel 2010-09-29
<ogra_cmpc> evil udev :(
<Chipzz> ogra_cmpc: I guess the experiment failed?
<ogra_cmpc> Chipzz, no, i didnt start it yet
<ogra_cmpc> i cant get wlan to work on the device i want to try it
<ogra_cmpc> and the kernel is to old for newer udev
<ogra_cmpc> i'll try it as soon as i can
<SpamapS> hm.
<SpamapS> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<ogra_cmpc> but udev and upstart are the ones that prevent me from using maverick on that machine
<SpamapS> I have seen this in several bug reports over the past 2 months
<cjwatson> SpamapS: "some other package manager is running"
<cjwatson> please don't reassign such bugs to debconf in any event.  I can't do anything with them there
<highvoltage> cjwatson: regarding the installer name rename, I understand and agree :)
<ogra_cmpc> cjwatson, well, you could dump the processlist somewhere from debconf with that error :)
<highvoltage> elmo: are there any actual real differences (from an ubuntu perspective) between amd64 and em64t?
<SpamapS> cjwatson: yes I think its doing its job.
<SpamapS> cjwatson: I just wonder if we shouldn't add a feature to *list* the lock holder.
<SpamapS> cjwatson: my guess is somebody is running apt-get while update manager is running in the background already.
<SpamapS> btw, the latest i386 mini.iso works great. ;)
<highvoltage> p'tahk
<highvoltage> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/650729
<ubottu> Launchpad bug 650729 in ubuntu-font-family-sources (Ubuntu) "Ubuntu Font should support (at least some) Klingon" [Wishlist,New]
<RAOF> Has lifeless been at the ubuntu-font bugtracker? :)
<lifeless> RAOF: no
<lifeless> RAOF: I added klingon for pitti/keybuk etc.
<lifeless> RAOF: I don't speak/read it at all
<RAOF> Aaah.
<lifeless> RAOF: I just happen to be (sadly) familiar with the black hole that is i18n
<lifeless> having found the skeletons
<RAOF> Heh.
<wgrant> Why does the source package have '-sources' on the end?
<IDWMaster> I'm working on porting some networking stuff for my business from windows to Ubuntu. It was originally written in .NET, so I was considering MonoDevelop; then I heard of KDevelop (C++), which also worked amazingly well. So I was wondering if anything is 'better' about using KDevelop or MonoDevelop as an IDE.
<IDWMaster> Is there anything better about one or the other?
<psusi> is there a channel specific to theme issues?  the new default theme in maverick apparently uses a dark color for the default window foreground color.... the gnome cpu frequency monitor applet seems to use this for its font when displaying on the pannel, which also has a dark background, making it impossible to read.  Is the applet using the wrong theme attribute, or is the theme broken?
<maxb> Hi, for a new upstream version update, if there are no Ubuntu specific changes, and it would normally be a Debian sync, except Debian's frozen, is it still appropriate to use -0ubuntu1 ?
<maxb> Or, is this a case where it's reasonable to use -0build1, so the autosync happens automatically in natty?
<micahg> maxb: can it go into experimental?
<micahg> you can sync from there
<Sarvatt> maxb: we just stick that stuff in experimental and sync from that for X stuff
<maxb> experimental is already occupied with an upstream beta
<Sarvatt> too slow! :)
<maxb> package is bzr, ftr
 * micahg would think to use -0ubuntu1 and then file a sync bug when natty opens or the first version becomes available
<micahg> maxb: sid and squeeze have different versions, you can't upload to sid?
<RAOF> No.  Sid's reserved for things which should end up in Squeeze, and that's frozen.
<micahg> RAOF: well, the package isn't migrating anyways and the versions are different
<maxb> Jelmer says sid and squeeze only have different versions because of a particularly unfortunate freeze timing, and doesn't want to compound the difference
<micahg> sid has 2.2.0-1 and squeeze had 2.1.2-1
 * micahg doesn't see the difference between 2.2.0 and 2.2.1 in sid at this point...
<hagabaka> anyone op in #ubuntu? why am I banned?
<TheMuso> hagabaka: You should ask your questino in #ubuntu-ops I think.
<hagabaka> thanks
<ScottK> maxb: Use -0ubuntu1 if it's not in Debian yet.
<pathogen> hello, is anyone awake?
<pathogen> Well, I guess I'll wait until later
<micahg> !ask | pathogen
<ubottu> pathogen: 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. :-)
<pathogen> I'm just curious, but how will client side window handling affect things like kwin window tabbing?
<RAOF> They won't, unless kwin claims to support CSD.
<pathogen> Hmm
<pathogen> So, what's the benefit of client side windows then? Other than being bale to skin themselves
<pathogen> *being able
<RAOF> You mean âclient side *decorations* â, here.
<pathogen> right
<RAOF> Both GTK and Qt use client-side-windows already :)
<pathogen> lol
<pathogen> Yes, so what's the benefit of using a client handled window decoration?
<RAOF> One benefit is that apps can skin themselves *consistently*
<pathogen> it'll make window management a mess...
<RAOF> Why?
<RAOF> Apps are already able to skin themselves.  It's just a lot of effort to both skin yourself *and* be consistent with the rest of the desktop.
<pathogen> Well, you say that apps will be able to skin themselves consistently, but in turn, there won't be a consistent theme of window decoration for all apps
<RAOF> Why not?
<RAOF> Apps can do this *right now* - Chromium does it, for example.
<pathogen> If you use emerald for example to skin your windows, the client side skinned ones will stand out
<RAOF> Right.
<pathogen> my point exactly
<pathogen> chromium sticks out like a sore thumb
<RAOF> So, emerald doesn't set the âI support CSDâ bit, and nothing uses it.
<pathogen> hmm
<RAOF> (One of) the idea(s) of CSD is to allow apps to do something like Chromium but *without* sticking out like a sore thumb.
<pathogen> So, if using a window manager without the CSD bit, the application will still have full functionality?
<pathogen> or will that be the app's developer's choice?
<RAOF> Part of the app developer's choice.
<pathogen> hm
<RAOF> It will mean that the *toolkit* (ie: GTK and Qt) won't draw the decorations.
<pathogen> Is CSD being developed in qt right now?
<pathogen> or is it just a gtk thing for the most part?
<RAOF> I believe that Qt's been able to draw its own decorations forever.
<RAOF> (essentially)
<pathogen> I see
<pathogen> I guess there's not much of hope of consistency between qt's window drawing style and gtk's window drawing style
<RAOF> Actually, probably more so if GTK goes CSD - after all, Qt currently sets a QtGtkStyle, so GTK apps fit in nicely.
<pathogen> I've tested that out for a while on my machine, but it was a bit buggy at times
<pathogen> I've had a lot of success with qtcurve themes though
<hyperair> those are themes designed to look the same
<hyperair> as in reimplemented using different engines
<pathogen> right
<pathogen> but it works very well
<hyperair> of course it does.
<hyperair> if you wish to reimplement every nice looking theme you have in both gtk+ and qt, i think you'll find that they all will work very well too.
<pathogen> hmm
<hyperair> what's needed is the reverse of the gtk style in qt
<hyperair> which makes qt apps look at home in GNOME.
<hyperair> afaik there was an engine for gtk that rendered using qt3
<hyperair> and it worked pretty good
<pathogen> ah I see what you mean
<hyperair> then qt4 arrived, and the reverse happened
<pathogen> For a second I thought you were talking about making qt4 look like gtk
<hyperair> not that i'm complaining though, i'm a GNOME user.
<pathogen> instead of gtk look like qt4
<pathogen> I agree completely
<hyperair> qt4 already looks like gtk with that engine =)
<hyperair> now gtk needs to look like at4.
<pathogen> yeah
<hyperair> qt4*
<pathogen> I have a lot of qt apps, more than gtk
<hyperair> i have a lot of gtk apps, more than qt.
<pathogen> my gtk ones always look out of place
<hyperair> it annoys me that kde themes are completely different, though
<pathogen> hmm
<hyperair> as in i can't use KDE applications without some kind of hack to make them use the gtk theme
<pathogen> Yeah, I wish there was a universal theme engine
 * hyperair nods
<pathogen> The closest I can get so far is qtcurve
<hyperair> either way i've tried switching to KDE a few times in the past, and could never figure out where all the settings were
<hyperair> at least GNOME's settings are in intuitive places
<pathogen> all in one place
<hyperair> even if they're missing.
<pathogen> systemsettigns in the terminal will give you all of the settings for kde
<hyperair> yes i know
<pathogen> *systemsettings
<hyperair> the problem is hunting for the setting you want *inside* systemsettings
<hyperair> they're all over the place
<pathogen> Have you used any of the more recent kde builds?
<hyperair> in fact, i haven't been able to find the kwin settings for ages
<hyperair> no, i don't think so
<hyperair> i use what's in lucid
<hyperair> when maverick arrives i might give it another go
<pathogen> They've cleaned it up a LOT in the newest 4.5 release
<hyperair> but i hate amarok.
<pathogen> meh
<hyperair> amarok 1.4 was good
<hyperair> amarok 2 was Â¬_Â¬
<pathogen> ^ this
<pathogen> Yeah, I disliked amarok 2 for a long time
<hyperair> but banshee 1.x beats amarok 1.4 flat =p
<pathogen> I still thing it has far too much bloat
<pathogen> hmm
<hyperair> the interface is weird.
<pathogen> never used banshee
<hyperair> you should give it a go.
<hyperair> it's a GNOME app though
<pathogen> you should try out clementine
<hyperair> doesn't look like it's in the ubuntu repository
<pathogen> http://code.google.com/p/clementine-player/
<micahg> debian 579859
<ubottu> Debian bug 579859 in wnpp "ITP: clementine -- Music player and library organizer" [Wishlist,Open] http://bugs.debian.org/579859
<hyperair> lol
<pathogen> I think it's already got debian packages ready to roll
<pathogen> It's basically a clone of amarok 1.4 written for qt4
<hyperair> ah
<hyperair> i see
<pathogen> it's not up to feature parity yet, but it's still pretty nice
<pathogen> very light, integrated with the new projectM, and quick database searches
<hyperair> now here's one thing i really don't like about amarok 1.4: there isn't really a specific playlists view
<hyperair> i mean there isn't any proper separation between "entire library" and "playlist"
<hyperair> so i had to maintain them separately
<pathogen> what do you mean?
<hyperair> and every time i changed the playlist, it took a long time to repopulate.
<hyperair> try using banshee, you'll get what i mean.
<pathogen> Wait, I think I know what you mean
<hyperair> haha
<pathogen> hmm
<hyperair> apart from that, amarok's searching was #1 at that time.
<pathogen> I never really had a problem with that
<hyperair> until banshee appeared
<pathogen> Yeah, I'm not wuite sure what the amarok devs were thinking when they made amarok 2
<pathogen> Pretty much everyone aknowledged that amarok 1.x was the best linux music player
<hyperair> until banshee 1.x came along
<hyperair> i jumped ship at 0.98.1
<pathogen> well, just installed it and it froze...
<hyperair> banshee 0.1x was nowhere near amarok 1.4, but banshee 1.x is great
<hyperair> which version?
<hyperair> froze, i mean.
<pathogen> 1.7.6
<hyperair> right, that one has a bug regarding a race condition with dbus
<hyperair> between some dbus and network thing
<hyperair> 1.7.5 is fine
<hyperair> and 1.8.0 will be fine.
<hyperair> in fact, 1.8.0 is due today
<pathogen> hm
<pathogen> well, I'm running updates now so it should get fixed (I hope)
<pathogen> have you tried clementine yet?
<hyperair> nope.
<hyperair> i might give it a go the next time i try kde4
<hyperair> which will be when i upgrade to maverick.
<pathogen> do you not have any qt dependancies installed or something?
<hyperair> i have.
<hyperair> but none of the -dev
<hyperair> and i'm lazy to get those at the moment.
<pathogen> you don't have to build it
<pathogen> it's already pre-built
<pathogen> even in a .deb
<hyperair> besieds, i have to get to packaging pdfmod, followed by libgpod and then banshee.
<hyperair> it's more of a time constraints thing
<pathogen> *facepalm*
<hyperair> i've got a crapton of things to do, or i'll be spending time trying out compiz++ and posting backtraces
<pathogen> I thought you really liked banshee?
<hyperair> yes, i'm banshee's maintainer.
<pathogen> why wouldn't you have it already XD
<hyperair> because 1.8.0 hasn't been released?
<pathogen> ah
<hyperair> and it's due for release today?
<hyperair> i think i mentioned this earlier Â¬_Â¬
<pathogen> I see
<hyperair> banshee 1.8.0 will require libgpod from git.
<pathogen> hmm
<hyperair> but libgpod is also getting released today
<pathogen> on git?
<hyperair> so i'll have to wait for that first
<hyperair> no, it'll be released, as in 0.7.95
<pathogen> oh I see
<pathogen> So is maintaining banshee something you do as a hobby, or is it your job?
<pathogen> I'm just curious because I've always wanted to get involved in the FOSS scene, but didn't see how I could
<hyperair> it's a hobby
<hyperair> and also my starting point towards becoming an ubuntu developer
<pathogen> So, what does maintaining a project like banshee entail?
<TheMuso> hyperair: I assume at this point banshee 1.8 is not going into maverick, given main frozen, libgpod in main, etc.
<hyperair> more like maintaining the package.
<hyperair> TheMuso: err oh crap, i forgot that.
<micahg> hyperair: banshee is still in universe
<pathogen> So you download the releases, compile them for various architectures, and then submit them to the repository?
<hyperair> micahg: but libgpod needs tobe updated.
<hyperair> pathogen: no, i download the release, prepare the source package, and upload to ubuntu. it gets built for different architectures there
<pathogen> Oh, I see
<pathogen> What usually has to be done to prepare the source?
<hyperair> TheMuso: could we get a freeze exception for that, i wonder.
<TheMuso> hyperair: Given libgpod is on the Ubuntu CD, and given we are frozen for RC, and given that the absolute minimum amount of changes are generally made between RC and final, doubtful.
<TheMuso> I could be wrong though.
<hyperair> =\
<RAOF> Another option would be to 0-day SRU it.
 * hyperair sighs. it's always a rush during finalfreeze
<TheMuso> Yeah there is that...
<pathogen> what is a 0-day SRU?
<RAOF> An update that's ready to go on release day.
<pathogen> Oh, I see
<RAOF> Because respinning/retesting the CDs is a significant effort.
<hyperair> maybe i could take that path.
<pathogen> So instead of adding it to the cd, you just make it a zero day update
<hyperair> Laney, directhex: what do you think?
 * RAOF wishes mesa also had a âabsolute minimum changes after RCâ policy.
<TheMuso> RAOF: heh
<ajmitch> RAOF: that takes all the fun out of life
<RAOF> It was looking so good, too!
<RAOF> There were just a couple of commits since our very-nearly-RC1 snapshot.
<TheMuso> RAOF: But is mesa on a timed release schedule?
<RAOF> It's expected to release on December 4.
<TheMuso> Right.
<RAOF> Oh.
<RAOF> Whoops.
<RAOF> *October* 4
<TheMuso> lol
<ajmitch> I was going to say... :)
<pathogen> mesa is a graphics library for X?
<hyperair> it's where all our 3d drivers are
<RAOF> And, of course, the best thing to do post RC1 is to pull in the Sandybridge driver.
<pathogen> I see
<TheMuso> ahem, lovely.
<RAOF> Because practically *nobody* has hardware driven by i965_dri.so :(
<ajmitch> new driver, or major changes to the existing driver?
<pathogen> I do
<RAOF> Changes to the existing driver.
<micahg> o/ as well
<ajmitch> RAOF: that don't sound very RC-worthy :P
<hyperair> RAOF: what! i do!
<pathogen> wow
<TheMuso> I can't stop laughing about it hear actually, its certainly not RC worthy in my book.
<pathogen> basically everyone here has that hardware
<RAOF> micahg, ajmitch: Hush.  Everyone knows that intel's GPUs are only aimed at a tiny niche audience :
<hyperair> those who want battery life?
<pathogen> I can feel the sarcasm oozing from your text
<ajmitch> of course, I don't have any current hardware with intel drivers, so they can't be that important :)
<TheMuso> Afaik sandybridge is not really out in the wild yet.
<RAOF> Indeed it is not.
<TheMuso> So it could have waited.
<ajmitch> but in 6 months time it may be
<StevenK> Those who only want static images on their screens. :-P
<pathogen> Beleive it or not, my intel architecture and gpu has lasted very well through the years
<ajmitch> i915 is a little underpowered for gaming though :)
<pathogen> Will a little elbow grease, I can make it play even the newest games
 * micahg is guessing the new GPU support is making Flash better on Maverick even in powersave mode
<pathogen> at fairly acceptable framerates too :D
<hyperair> ajmitch: hey i play games with my intel chip.
<StevenK> pathogen: No fair if you're doing the GL transforms on paper
<ajmitch> hyperair: nethack doesn't count
<TheMuso> ROFL
<pathogen> Portal!
<TheMuso> to both comments
<hyperair> ajmitch: lol. i play touhou =p
<hyperair> ajmitch: but my intel chip has a tendency to send my machine into spurious hangs that eventually result in hanging the ethernet chip
<hyperair> i have no idea what connection there is between a graphics and ethernet chip, but somehow it succeeds.
<pathogen> lol
<hyperair> rmmod and modprobe again won't work. the only thing that works is suspending and resuming
 * ajmitch has the joys of using fglrx still
<hyperair> or of course, a complete shutdown
<StevenK> ajmitch: Ewwww
<TheMuso> hyperair: I am surprised even that works.
<pathogen> using the compiz cube would randomly lock up my desktop 3 years ago
<hyperair> TheMuso: which one?
 * StevenK hugs his GeForce, and then treats the burn
<ajmitch> StevenK: yeah, it's not exactly easy to figure out why resuming often makes everything dog slow :)
<TheMuso> Suspending and resuming.
<RAOF> StevenK: Sizzle!
<hyperair> TheMuso: yeah i was pretty surprised too.
 * TheMuso thought a shutdown would be the only way to clear it.
 * hyperair shrugs
<hyperair> if i suspend and resume, then wait, say 15 minutes, i can game for another hour
<RAOF> The GPU does get fully shut down on suspend then reinitialised on resume, so it's possible.
<pathogen> Has anyone got a compaq presario cq60 laptop?
<TheMuso> RAOF: ah ok, makes more sense.
<RAOF> Perhaps more surprising is that you can actually suspend at all ;)
 * micahg is guessing that's why apport shows 127 apport GPU crashes on resume :)
<hyperair> RAOF: but what about the ethernet chip?
<pathogen> The laptop always hangs when suspending to the hard drive...
<RAOF> hyperair: The GPU can scribble on arbitrary memory!
<hyperair> RAOF: ...oh crap.
<hyperair> pathogen: that's a feature.
<RAOF> Doesn't _that_ make you feel safer with WebGL? :)
<pathogen> hyperair: riiiiiiiight....
<hyperair> RAOF: wtf is webgl? D=
<ajmitch> RAOF: who needs their data anyway?
<pathogen> webgl is fairly cool
<ajmitch> hyperair: the ability to play quake in the browser
<pathogen> it allows a webpage to run script in opengl using your gpu
<RAOF> hyperair: Pretty much what it says on the box: OpenGL for web clients.
<hyperair> pathogen: yep, it's meant to spread the word that suspend-to-disk is a dumb concept and people should focus their efforts on making suspend-to-ram better.
<hyperair> RAOF: heh lol =p
<pathogen> My old acer sapire could run for days while suspended
<hyperair> so if the gpu can scribble on arbitrary memory, how come my apps aren't segfaulting?
<pathogen> I was inpressed
<hyperair> and only the transmission portion of my tg3 card hangs?
<hyperair> receiving still works
<RAOF> hyperair: Probably because that's not the issue.  Or because your GPU has a bug which deterministically scribbles on a specific part of your ethernet card's MMIO space?
 * hyperair groans
<hyperair> =(
<hyperair> then shouldn't rmmod and modprobe reinitialize the card?
<RAOF> Not if the state is broken.
<pathogen> they reinitialize the kernel drivers
<RAOF> I guess it could be possible for the GPU to be in a state the driver doesn't know how to recover from, but doesn't break suspend.
<pathogen> but, the problem prolly exists on the hardware level
<pathogen> in that case, power cycling fixes it
<hyperair> or suspend/resume =p
<pathogen> perhaps, perhaps depending on the architecture of the computer
<hyperair> in my case, graphics works, it's just the ethernet portion that hangs
<pathogen> pretty strange
<pathogen> Well, I'm off to bed
<hyperair> happy sleeping
<pathogen> I shall!
<pitti> Good morning
<pitti> highvoltage: heh
<TheMuso> Morning pitti.
<pitti> hey TheMuso
<RAOF> Howdie pitti.
<dholbach> good morning
<poolie> pitti: i'm seeking your further advice on bug 636930
<ubottu> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] https://launchpad.net/bugs/636930
<poolie> can we kick off an SRU from the 2.2.1 microrelease there?
<pitti> poolie: we can, yes
<pitti> poolie: a few days ago we were still open for last-minute changes, but now it needs to become an SRU, I'm afraid
<poolie> that's ok
<poolie> will it be on hold until after 10/10, or can that happen in parallel with the release?
<pitti> poolie: it can be uploaded before
<pitti> poolie: the queue is open, but we won't accept it until very near the release
<poolie> ok
<poolie> bit of a shame we didn't hit that, but it's better not to rush
<poolie> so what do we need to do now to get it into that queue?
<pitti> poolie: just uploading it, with making sure that the changelog refers to all bugs, etc.
<pitti> ttx: wrt bug 650893, I suppose you don't have dbus installed on server, right?
<ubottu> Launchpad bug 650893 in cups (Ubuntu Maverick) "[maverick] cups does not start at boot time" [High,New] https://launchpad.net/bugs/650893
<pitti> so I guess I'll again hit the wall of how to specify weak dependencies in "start on" clauses
<pitti> slangasek: would something like this work for "start after dbus if present"?
<pitti> ... and (started dbus or runlevel [2345]) and ..
<smb> cjwatson, Its not really a big issue but has the option to set an apt proxy at installation time to be used for the downloads been dropped consciously or was it more a side effect. Or should I have read some installation notes which would have explained it to me where things have gone?
<seb128> bdrung_, hi
<pitti> ttx: I sent a proposed upstart script to the bug, would be awesome if you could test it
<seb128> bdrung_, why did you start the discussion about the sponsoring process on -discuss? It's probably a list that most concerned people don't read if they are busy
<ttx> pitti: I'll reinstall one "print server" now
<bdrung_> seb128: because 'discuss' was in the name. where should i have send the mail?
<poolie> pitti: i'm not sure if maxb can upload it to proposed(?), could you do it if he can't?
<seb128> bdrung_, not sure, it might be right for getting opinions but u-d might be better to get the process changed or replies from people doing sponsoring
<pitti> poolie: upload permissions aren't pocket specific; so anyone who can upload to devel can upload to proposed as well
<poolie> ok
<bdrung_> seb128: or ubuntu-motu?
<seb128> bdrung_, it's likely not everybody is reading the motu list
<seb128> bdrung_, I guess busy people only read u-d, not sure if you want feedback from everybody though
<persia> bdrung_, u-d is likely best.  u-m is mostly interesting only when there's something that only affects MOTU.  u-d-d is for coordination between developers and users (this would be mostly between developers)
<soren> Wow. Looking at https://edge.launchpad.net/builders makes me feel like uploading something :)
<pitti> before they get too bored
<pitti> open natty! open natty!
<Hobbsee> "is natty open yet?"
<persia> So, I know we have a more streamlined process, but I believe we still have to complete each release before we can open the next one.
<StevenK> It was going to be opened in 2 hours, but now that you've asked, it's 3.
<\sh> sed -i "s/maverick/natty/" /etc/apt/sources.list ; apt-get update ; apt-get dist-upgrade
<persia> But there's lots of other stuff that needs building.  Anyone run `apt-cache -i unmet` recently?
<persia> StevenK, You already fixed Soyuz so we can start asking this early, and only pay a 1-hour delay?
<\sh> persia: and as scottk proposed: http://qa.ubuntuwire.com/bugs/rcbugs/
<pitti> StevenK: oh, I thought it wouldn't even be possible as long as maverick is still open?
<StevenK> persia: No, I was trying to make a joke that references the releaseparty deley
<StevenK> *delay
<persia> StevenK, It was a good joke.  Please fix Soyuz so that you can tease us like that.
<Hobbsee> hah.  now you've been told!
 * StevenK goes back to writing bugs
<\sh> persia: and not forgetting the list of FTBFS packages...still in bad shape
<cjwatson> smb: text or graphical installer?
<smb> cjwatson, Personally I only saw the Kubuntu graphical and the alternate text installer, but cking said he did not remember seeing that option in the Ubuntu graphical installer either.
<cjwatson> smb: I was kind of hoping for a single answer
<smb> cjwatson, "all" ?
<ttx> pitti: tested, works, commented on the bug
 * ttx is about to leave to catch a train
<pitti> ttx: yippie
 * pitti commits
<cjwatson> smb: nothing has changed regarding the proxy option in the text installer, as far as I know
<cjwatson> smb: for the graphical installer, you would have to ask ev
<ttx> pitti: for post-RC, or do you think we should trigger a respin for that ?
<ttx> Daviey: about to leave, any question ?
<pitti> ttx: that's a question for you really, but my gut feeling is that post RC is sufficient, with a  release note
<ttx> pitti: that's my feeling too.
<smb> cjwatson, ok, let me pay closer attention on it for the text installer, maybe I just missed it. Will have a look at the graphical again as well and talk to ev
<ev> smb: it's not exposed in the UI anymore.
<ev> for the graphical installer
<ttx> if anything else comes up that warrants a respin, then we can catch that one in it
<smb> ev, Ah ok, so its a grub commandline I could test?
<ttx> Daviey ^
<smb> ttx, sorry
<cjwatson> can't possibly be a grub command line
<cjwatson> given that the live CD doesn't boot using grub
<cjwatson> (yet)
<ev> I think he means kernel command line preseeding
<smb> right, just that grub happens the place you enter it most of the time.
<cjwatson> indeed, I'm just nitpicking :)
<ev> smb: mirror/http/proxy=true
<ev> should do it
<ev> err
<ev> mirror/http/proxy=whatever.your.proxy.is
<cjwatson> uh
<cjwatson> oh, yes, indeed :)
<ev> clearly not enough coffee in my et
<ev> yet
<cjwatson> not that form though
<cjwatson> mirror/http/proxy=http://whatever.your.proxy.is/
<cjwatson>  The proxy information should be given in the standard form of
<cjwatson>  "http://[[user][:pass]@]host[:port]/".
<ev> right-o
<smb> simple and clear. :-P
<Daviey> ttx: nope!
<Daviey> ttx: Have fun :)
<smb> ev, Do we mention option in the release notes? (asked by the person notoriously forgetting to read them)
<ttx> Daviey: ok, back in ~4hours
<ev> smb: yeah, definitely
<bdrung_> dholbach: you are back?
<dholbach> bdrung_, yes
<dholbach> bdrung_, got back yesterday afternoon
<bdrung_> welcome back dholbach
<dholbach> thanks bdrung_
<corecode> hey
<corecode> how do i use bzr correctly with the packages?
<corecode> should i always commit before i build?
<corecode> because now i have a lot of changes that were caused by debuild
<cjwatson> if you have a package that applies patches during the build, you can always 'debuild clean' before committing
<cjwatson> whether to commit before building is mostly a matter of taste - it does mean that you're committing something you haven't tested yet
<tumbleweed> but you can always uncommit. I've run into some issues where if you don't commit, bzr bd builds with files that should have been deleted (bzr rm)
<cjwatson> that's only bzr bd
<cjwatson> (and should be filed as a bug on bzr-builddeb, IMO)
<tumbleweed> cjwatson: yeah, I need to do that
<YokoZar> micahg: were you able to do anything with Profile-Guided Firefox this cycle?
<chrisccoulson> YokoZar, no, but i'm working on that for next cycle
<YokoZar> chrisccoulson: does firefox build with a .mozconfig yet or is it still a bunch of command switches in the build script?
<YokoZar> chrisccoulson: sorry for not doing it myself this cycle I know I hinted I would at UDS
<chrisccoulson> YokoZar, no mozconfig
<YokoZar> chrisccoulson: That should be the path forward then, as once you use the mozconfig file building with PGO is a switch
<chrisccoulson> YokoZar, yeah, i know ;)
<chrisccoulson> but it's not just a straight switch to a mozconfig, as we have lots of logic to determine our build flags
 * YokoZar is a bit amazed Firefox performance wasn't a major priority for us years ago...
<YokoZar> chrisccoulson: Yeah, I got about half way going into UDS-maverick before I got distracted with real life ;)
<chrisccoulson> well, mozilla are working hard to make PGO work, but it's not straightforward.
<chrisccoulson> it doesn't work well at all with GCC < 4.5
<YokoZar> Fair enough
<chrisccoulson> so, unless we use that version next cycle, PGO is a non-starter ;)
<YokoZar> Well we ship GCC 4.5 in maverick, nothing wrong with building Firefox against it ;)
<chrisccoulson> well, the version we ship will be using the standard toolchain ;)
<pitti> chrisccoulson: I don't see anything wrong with building with 4.5?
<chrisccoulson> pitti - oh, well, if that's the case ;)
<pitti> ... in natty (not proposing to switch now in maverick :) )
<chrisccoulson> pitti - anyway, there are some bugs in GCC4.5 which break optimisation in firefox
<chrisccoulson> eg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
<ubottu> gcc.gnu.org bug 45623 in tree-optimization "[4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?" [Normal,Resolved: fixed]
<YokoZar> chrisccoulson: you mean fixed in 4.5 yes?
<chrisccoulson> i don't think it's fixed in the version we have, but i'd need to check
<chrisccoulson> seeing as it was only fixed a few days ago
<YokoZar> oh so a newer point release of 4.5
<chrisccoulson> i really need another machine to do builds on :(
<davmor2> mvo, pitti:  I'm using Hardware Drivers to install the B43 Driver and I got SystemError: installArchives() failed.
<mvo> davmor2: anything that looks like a error  in /var/log/apt/term.log  (the last few lines)?
<davmor2> pitti: also the STA driver seems to of mysteriously stopped connecting on maverick but lucids does connect correctly :(
<davmor2> mvo: all I got is Log started: date time and Log ended: Date time
<pitti> davmor2: anything in /var/log/jockey.log?
<pitti> davmor2: I just installed UNE on my mini 10, which auto-installed wl
<pitti> (which works fine)
<davmor2> pitti: mine is a compaq mini 110 and on network-manager said there were no firmware drivers.  I installed the STA like I normally do and it sees the router it just won't connect.
<davmor2> pitti: apport has just woken up and given me an error so I'll send that report
<davmor2> pitti: bug 651010
<ubottu> Launchpad bug 651010 in b43-fwcutter (Ubuntu) "package firmware-b43-installer 4.150.10.5-4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/651010
<pitti> davmor2: hm, what an useless dpkg log :( http://launchpadlibrarian.net/56733878/DpkgTerminalLog.txt
<pitti> davmor2: if you do sudo dpkg --configure -a, what do you see?
<davmor2> pitti: Not support low-power chip with PCI id 14e3:4315!   that could be the clincher :)
<pitti> hm, and yet the modalias claims to support it? bad b43
<pitti> I seriously consider to just drop the b43 handler for good
<pitti> it seems to cause nothing but trouble, and STA is generally better
<davmor2> pitti: I've added the full info to the bug.   I'll try the sta driver again is there anyway I can get the debug info from N-M to get some decent info for you guys?
<pitti> probably a quetion for Mathieu
<pitti> davmor2: but /var/log/daemon.log should already get quite far
<davmor2> pitti: thanks :)
<dpm> hey pitti. Do we have to discuss when the final full language export should be requested in LP? Arne tended to do it around 22:00 UTC on the day of the translation deadline, so I was thinking of just doing that.
<pitti> dpm: I already requested the full export; it shoudl be produced today, right?
<pitti> dpm: I'd like to prepare and test them tomorrow, so that they can build right after RC
<dpm> pitti, no, the translations deadline is tomorrow
<pitti> dpm: but then the next export would only be on Sunday
<\sh> hmmm...a question to our famous gtk specialist: should libgdk-pixbuf-2.0 ship an .la file or not?
<dpm> pitti, I guess we should have discussed that before. Translators look at the schedule and think they can still translate until tomorrow
<\sh> (which should normally be in the -dev package of the lib)
<pitti> dpm: "until today" would be better, I think, otherwise we have zero margin for a rebuild
<pitti> \sh: we try to get rid of those beasties as much as we can
<\sh> pitti: so I have to further patch ginspector to not use it
<pitti> \sh: how does it use a .la file?
<dpm> pitti, ok, that would be a good compromise, but next cycle we should look at putting the LanguagePackDeadline on the schedule on a day we can actually request the export with enough time
<\sh> http://paste.ubuntu.com/502566/
<pitti> dpm: *nod*; on a Wed or Sun would make sense, to align with the days when the exports actually happen
<pitti> \sh: but usually the .la files need to be cleaned up from top to bottom, i. e. I'd expect GTK to be one of the last packages to drop it
<\sh> pitti: I just wonder, because libgtk2.0-dev ships as well an .la
<pitti> top/bottom in the dependency tree, I mea
<pitti> n
 * pitti defers to seb128
<\sh> pitti: I'm just trying to fight the ftbfs of ginspector...
<dpm> pitti, ah, just a question. Why is it a problem that the next export is on Sunday? When requesting a full export, the export is produced straight away, isn't it? (well, not straight away, but just the time it takes to create the tarball)
<dpm> so that does not have anything to do with the Sunday's export
<pitti> dpm: oh, I understood that differently
<pitti> dpm: I thought marking this checkbox means "the next time you create a langapck", not "do an extracurricular export NOW NOW NOW"
<pitti> I flipped it on two days ago, and https://translations.edge.launchpad.net/ubuntu/maverick/+language-packs has a full export from today
<pitti> so I guess the export starts very early on Wed/Sun, not late
<pitti> and the langpacks are then built late in a day, to allow some slack
<dpm> pitti, let me check with danilo
<ScottK> dpm: If you look at http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html there are a number of -kde- language packs listed as uninstallable.  I checked and they are all missing updates to the underlying language-pack-foo  in the last export.  Are those going to be OK this last time around?
<cjwatson> ScottK: yes
<ScottK> cjwatson: Thanks.
<cjwatson> (checked this a few days ago)
<ScottK> Excellent.
<cjwatson> lool: qemu-kvm is currently listed in Packages-arch-specific as amd64 and i386 only.  Apparently nobody noticed since it built fine on armel and powerpc in lucid.  A test-build on kakadu shows that it currently fails to build on armel (http://paste.ubuntu.com/502586/).  Do you care?
<cjwatson> ogra: ^- ditto
<cjwatson> that failure is apparently in arm-specific assembly code
<ogra> cjwatson, well, no clue if it runs, feel free to remove it from PAS
<ogra> then we could actually try :)
<cjwatson> well, as I say it certainly doesn't build
<cjwatson> build on powerpc is still going but looking healthier
<ogra> oh, sorry i misread
 * ogra is in 10 conversations simultaneously
<ogra> then better leave it in PAS until natty :) unless linaro wants to do some last minute debugging here
<cjwatson> well, it's NBS.  If I leave it in P-a-s, then I have to remove the stale binary since there's no matching source for it
 * cjwatson grabs a vaguely current ARM ARM to see what the constraints on rndd and friends should be
<lool> cjwatson: I did bring this up with the server team a while ago; Debian has qemu / qemu-kvm and added qemu-kvm to Pas recently
<lool> cjwatson: I do care just a bit, but it's not terribly important really
<lool> I just hate that we have no qemu builds on armel, while Debian builds "qemu" on all arches
<cjwatson> what would the consequences of removing the arm binaries be?
<cjwatson> it might not be that hard to fix this code ..
<lool> cjwatson: Pretty much no consequence I would think
<cjwatson> I guess I'm worried about lurking build-deps and the like
<lool> I really can't think of any, but I didn't grep
<lool> In the future, kvm will be used on armel, but that's still far off
<seb128> does anybody know what translation file has the ubiquity string "retrieving files n of n (<time> remaining)"
<seb128> ?
<cjwatson> there are several deps/build-deps
<cjwatson> even on armel
<cjwatson> they might not work - I guess I'm reluctant to make those uninstallable at this point
<cjwatson> seb128: apt
<seb128> cjwatson, thanks
<cjwatson> msgid "Retrieving file %li of %li (%s remaining)"
<cjwatson> msgstr "TÃ©lÃ©chargement du fichier %li sur %li (%s restant)"
<seb128> hum
<seb128> I'm wondering why the RC image doesn't have those in french
<cjwatson> if you're not seeing it translated, I don't know why ...
<seb128> well the french langpacks are not on the iso
<cjwatson> locale not copied to target at the point when it's running or something?
<cjwatson> langpack shouldn't matter
<cjwatson> apt is excluded from langpacks since it's needed before they're installed
<lool> cjwatson: I poked the rdepends of qemu, kvm, and qemu-kvm, and I see nothing critical for armel in there; most of the time, the packages are used on x86 desktops
<lool> hmm grub build-deps on qemu
<cjwatson> lool: right, but since my aim is archive consistency I'm a bit scared of something that would make things worse in some sense
<cjwatson> grub doesn't build on armel
<cjwatson> well, I'll look into this constraints error and see if it's easy to fix
<cjwatson> if it is then I'll just fix it
<cjwatson> if it isn't, I'll drop the binaries
<lool> cjwatson: I tihkn I remember this
<lool> cjwatson: It's very old code
<lool> cjwatson: I think this is for an older FPU than VFP
<cjwatson> it's particularly odd since I don't see the code in upstream git
<lool> cjwatson: I definitely remember patching out this code in the past already
<cjwatson> assuming I'm using the right git repository since there are millions of the things
<cjwatson> "rndd" is not mentioned in the current ARM ARM
<dpm> seb128, this seems to have been fixed in bug 644736 (see the strings in the duplicate). Perhaps the translations have not yet been exported from LP?
<ubottu> Launchpad bug 644736 in Ubuntu Translations "Untranslatable messages in the installer (dup-of: 646109)" [Medium,Triaged] https://launchpad.net/bugs/644736
<ubottu> Launchpad bug 646109 in Ubuntu Translations "Translations not loaded for some messages during installation in Ubiquity" [Medium,Triaged] https://launchpad.net/bugs/646109
<lool> shit, the fact that the fpu is called maverick doesn't help google it
<Riddell> dholbach: steven kelly moved his slot from friday to tomorrow in https://wiki.kubuntu.org/UbuntuAppDeveloperWeek
<dholbach> akgraner, ^
<lool> cjwatson: But if you just patch out the arm specific code, that part will definitely build with the C implementation
<cjwatson> qemu-kvm builds fine on powerpc, so we can deal with that at least
<dholbach> thanks Riddell
<cjwatson> lool: ok, I'll give it a try, thanks
<akgraner> dholbach, Riddell I'll make that change - thanks for the heads up :-)
<seb128> dpm, I doubt those translations are new they should be in the current export
<cjwatson> lool: would anyone be able to test that it's not completely broken if I did this?
<seb128> dpm, apt didn't get an upload for a week
<seb128> dpm, did you notice the same issue in spanish?
<bilalakhtar> dholbach: Welcome back!
<jibel> dpm, seb128, I'm testing a wubi upgrade from 10.04.1 and the problem also exists during installation of 10.04.1
<dpm> seb128, I use Catalan, but yes, I noticed it too :). If they come from apt, could it be that they need to be exported and put in the package?
<dpm> during install translations are not in language packs
<seb128> dpm, cf what cjwatson said before, apt is not in langpacks because it's used before those are installed
<seb128> in fact apt-all.mo is in langpacks
<seb128> but the string is translated in the mo according to msgunfmt
<dpm> seb128, does the string come perhaps from somewhere else? libapt-pkg or such?
<seb128> dpm, it's in apt-all.mo on the disk and translated
<cjwatson> the whole apt source package is supposed to be blacklisted from langpack stripping
<cjwatson> I think it's more likely that the locale isn't set up properly ...
<cjwatson> (could be wrong, it would just be my first hypothesis)
<fta> pitti, what makes apport create a crash file or not? i just had milter-greylist crashing in all my ubuntu boxes at the same time, but no crash file in any of them :(
<seb128> dpm, I guess it's worth reopening that ubiquity bug or opening a new one
<seb128> cjwatson, thanks
<lool> cjwatson: qemu-kvm 0.12.3-0ubuntu2:
<lool>   * New patch, arm-host-fix-compiler-warning, drops __arm__ specific code
<lool>     which was probably FPA specific (certainly not ARM/VFP) and was dropped
<lool>     upstream in bc4347b883e8175dadef77ed9e02ccaa5e8eba94; helps build on
<lool>     armel.
<YokoZar> Anyone with main upload rights feel like sponsoring a pretty trivial change?
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/351429
<ubottu> Launchpad bug 351429 in file-roller (Ubuntu) "file-roller associates itself with windows executables that it can't handle" [Low,Triaged]
<dpm> seb128, ok, I've unduplicated bug 644736 and added a comment.
<ubottu> Launchpad bug 644736 in Ubuntu Translations "Untranslatable messages in the installer" [Medium,Triaged] https://launchpad.net/bugs/644736
<seb128> dpm, thanks
<dpm> np
<cjwatson> lool: aha!  thanks, will resurrect
<cjwatson> just waiting for the testbuild
<hyperair> is it possible to ship in a new upstream release of libgpod at this point?
<hyperair> seb128: ^
<seb128> not really
<seb128> depends of the change I guess, if that's a one liner fix for a blocker issue
<hyperair> unfortunately it's a lot more than a one-liner
<seb128> otherwise better to SRU it
<hyperair> http://paste.debian.net/92350/
<seb128> no way for that diffstat
<seb128> it will be a SRU in best case for this cycle
<hyperair> okay.
<hyperair> has ubuntu-sru opened up for SRU applications yet?
<seb128> usually uploads work already yes
<seb128> but nothing stop you to do the update and the bug work, add the debdiff etc
<seb128> then try to upload and if that doesn't work just keep the update to upload later
<hyperair> oh okay
<lool> cjwatson: I was expecting to find the problematic code in qemu-kvm.git, at least in the 0.12 branch, but I did not; not sure why really
<hyperair> seb128: don't SRUs need to be already fixed in ubuntu+1, though?
<seb128> hyperair, no
<hyperair> okay then.
 * hyperair remembers reading something of taht sort in a wiki page
<seb128> when the version are the same the sru is pocket copied
<hyperair> ah okay.
<seb128> well sometime it help to have testing on the unstable version
<seb128> but you should rather make sure it lands in the next unstable as well
<hyperair> right.
<seb128> in practice when the version didn't change yet we pocket copy the sru to it
<seb128> it's less work for everybody
<hyperair> okay.
<dpm> pitti, re: when the full export happens you were right - ticking the box in LP marks them to be exported on the next scheduled day
<dpm> I've updated the exports schedule to include info on when the language pack builds happen:
<dpm>     https://dev.launchpad.net/Translations/LanguagePackSchedule
<pitti> dpm: nice, thank you
<dpm> np :)
<dpm> pitti, Considering that RCs are on Thursdays (the other milestones I guess are not that critical for language packs), I think the schedule is ok -> language pack exports on Tuesdays (and ready on Wed)
<dpm> I think the only thing that we should consider next cycle is to move the LanguagePackDeadline 2 days before to match the exports schedule.
<dpm> What do you think?
<pitti> dpm: so I'm currently considering using today's export (0929) for the final langpacks
<pitti> next Sunday gets pretty tight
<pitti> if they will work well, we have enough time, but if they fail, we are screwed
<dpm> pitti, yeah, that's fine. I understand that there is no other way for this cycle
<dpm> I'll let translators know.
<pitti> dpm: as usual we can do a first SRU a few weeks after release, whenever it's suitable
<dpm> pitti, sure, that sounds good, my question is also what you think about moving the LanguagePackDeadline day in future releases to an earlier date ^
<pitti> dpm: I agree; Tuesday before the RC sounds appropriate
<dpm> ok thanks pitti
<pitti> thanks dpm!
<pitti> dpm: I'll start the langpack builds now
<Riddell> pitti: why can't an export be done tomorrow?
<pitti> Riddell: because the Great Gods of Launchpad's third commandment says "Maverick language packs are creates on Tuesdays and Saturdays"
<pitti> Riddell: well, it can probably be done, but with some extra manual effort
<pitti> s/creates/created/
<Riddell> well seems the extra effort, launchpad are ment to do what we need them to do after all
<pitti> Riddell: we can locally build the Saturday export and use it if they work, but I'd like to have today's export as a fallback at least
<Riddell> as it is the translations I imported today because I was following the schedule won't get in and that'll annoy upstream lots
<pitti> dpm: do you know if/how it's possible to schedule an exra run?
<Riddell> akgraner: are there any edited logs for app developer week?
<JFo> asac, mind taking a look at https://bugs.launchpad.net/bugs/649357 ?
<ubottu> Launchpad bug 649357 in network-manager (Ubuntu) "network-manager on une will not connect" [Undecided,New]
<dpm> pitti, it's a cron job in LP, so I can ask the LP devs to ask LOSAs to schedule a one-off run I guess. Let me ask danilo. I'll be back in a few mins
<dpm> Riddell, ^
<asac> JFo: not time this week. talk to cyphermox or ask seb128 who is looking into those this cycle
<dpm> pitti, Riddell, if that were possible, when should this next one-off export be started?
<pitti> dpm: from my POV, tonight would be good
<Riddell> dpm: whenever you told the translators the deadline was
<cyphermox> JFo, already noticed it this morning; I was hoping to get my hands on a similar system to test it (I definitely didn't see this on my netbook)
<pitti> that was today, no?
<Riddell> dpm: but mostly after the .pos I uploaded are imported :)
<cyphermox> asac, ^^
<asac> cyphermox: what chipset?
<JFo> cyphermox, cool
<JFo> :)
<cjwatson> lool: qemu> apparently applied upstream as bc4347b883e8175dadef77ed9e02ccaa5e8eba94.  no idea why it's not in our package.
<cyphermox> asac: may be specific to Broadcom, or even STA :/
<cjwatson> (test-build still running but looks a lot better)
<cyphermox> asac, mine is an aspire one ZG5, so atheros, iirc.
<persia> cjwatson, Dunno about armel, but I have an interest in KVM/powerpc (and have added a few patches here and there for it), so I'd rather it wasn't P-a-s'd
<cjwatson> persia: right, I'll definitely be un-P-a-s-ing it on powerpc at least
<persia> Thanks.  Still a little shaky in maverick, but I'm fairly confident we'll have everything but the bootloader working in natty (still need to find a way around not being able to build arch:all packages on powerpc)
<cjwatson> you could use grub2
<cjwatson> it probably needs minor fixes but we'd welcome them
<persia> heh.  I'll take a look.  If that's easier than convincing Soyuz to build openfirmware, it may be the way to go.
<cjwatson> I have heard that it works on Debian, modulo some glitches with prefix (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597538)
<ubottu> Debian bug 597538 in grub-ieee1275 "grub-ieee1275: grub-install needs to pass a --prefix option to grub-mkimage" [Important,Open]
<cjwatson> and grub-installer would need to be taught about it
<slangasek> pitti: why would you OR the dbus with 'runlevel'?  dbus is not guaranteed to be started before entering the runlevel, it races in parallel
<cjwatson> but those are relatively superficial things
<persia> That's very promising.  I'll definitely take a deeper look at that, rather than fussing with openfirmware (especially since dropping sparc means there is only one package left that would need the Soyuz hack)
<asac> cyphermox: ok... bc is still painful i guess :/
<lool> cjwatson: It's simply not fixed in the stable-0.12 branch; only in qemu-kvm master
<pitti> slangasek: I understood that "runlevel 2345" is started later in the game, so to push it out a little bit
<cjwatson> persia: why was openfirmware needed anyway?  I don't remember that being needed for yaboot
<cjwatson> persia: which powerpc subarch are we talking about here?
<cjwatson> lool: ah, ok
<lool> (I was looking at the wrong file when I checked stable-0.12 earlier; I checked softfloat.c instead of softfloat-native.c)
<slangasek> pitti: a) it's racy, b) you've or'ed it so the only effect it could have is to start your job sooner rather than later...?
<pitti> slangasek: but I'm open to other suggestions; just the smbd story has taught me that weak dependencies aren't really working with current upstart methods
<lool> cjwatson: Were you able to build with that bugfix alone?
<lool> s/bugfix/patch
<cjwatson> lool: I'll tell you when kakadu finishes with it ...
<cjwatson> it's certainly got well past that failure
<pitti> slangasek: the effect is to start it at all on servers
<lool> Poor kakadu
<pitti> slangasek: since we don't have dbus on servers
<dpm> Riddell, pitti. I've just spoken to danilo. A one-off full langpack export can be arranged, we just have to decide on the date, which should probably be today or tomorrow. I'd be up for tomorrow, as that was the date on the maverick schedule, but you guys know best if that would be too tight or not. Riddell, as per checking whether the files you uploaded have been imported, you can do it here: https://translations.edge.launchpad.net/~jr/+imports?field.f
<dpm> ilter_status=all&field.filter_extension=po - they don't seem to have been yet. So what date should I tell danilo to start the export?
<cjwatson> persia: (oh, wait, is openfirmware not a package name?  I mean I know it's what the firmware implementation is called, but I don't know quite which particular Soyuz hack you mean ...)
<slangasek> pitti: er, if it starts fine w/o dbus, why 'start on dbus' at all then?
<pitti> slangasek: well, it starts without dbus, but then jobs aren't broadcast
<slangasek> hmm
<pitti> slangasek: i. e. if dbus is installed, I want cups to start after it
<cjwatson> so do the same thing as with samba?
<pitti> so the "or runlevel" was the best hack I could come up with
<cjwatson> SIGHUP dbus, or whatever makes it deal
<pitti> cjwatson: that would mean to sighup cups when dbus starts
<slangasek> pitti: it's not a very reliable hack
<pitti> slangasek: I know
<cjwatson> ok, the other way round.  isn't that fine too?
<cjwatson> conditional start is not something you can do in upstart
<cjwatson> all the available hacks, as far as I know, make things worse
<cjwatson> sending signals doesn't generally make things worse, if it's supported
<pitti> but at least not worse than in lucid
<pitti> init.d scripts were also started on runlevel [2345] in essence
<cjwatson> if we're changing it in maverick then IMO we should do it right
<cjwatson> we're just storing up future really really confusing bugs for ourselves otherwise
<pitti> cjwatson: right, but so far I don't know what "right" is
<persia> cjwatson, last I looked, we had OF implementations for both PPC and Sparc, but they have to be built on their target architectures, and the binaries are arch:all (for use with qemu), so...
<pitti> we need a weak dependency like "should-start:" or "on starting" (which doesn't work for practical scenarios)
<cjwatson> persia: oh, I thought you were still talking about the boot loader
<cjwatson> pitti: what's wrong with notifying cups when dbus starts?
<persia> Soyuz hack would be to add some way to hint to Soyuz that a certain source needs to be built on a certain arch, and still allow it to produce arch:all binaries.
<cjwatson> persia: right, I just wasn't sure of the particular package name.  now I know that you're talking about qemu not about the boot loader, it makes more sense
<pitti> cjwatson: telling dbus about all services that can support dbus and should be restarted doesn't sound like the "right" solution to me
<persia> OF *is* a bootloader (among other things).  As you indicate, switching to grub2 would make everything easier.
<pitti> that's just backwards
<cjwatson> grub2 on powerpc needs open firmware
<persia> cjwatson, I'm talking about a bootloader to use with qemu :)
<cjwatson> pitti: well, you *don't have* weak dependencies
<persia> Oh :(
<cjwatson> looking for them is going to make things worse
<persia> So for KVM, I still need a first-stage bootloader (as grub2 will only handle second stage).  Well, might be natty.  might be natty+1.  Anyway, the binaries from Debian work.
<persia> Current source packages seem to be "openbios-sparc" and "openbios-ppc" ("openhackware" was an old one, as well as some using "openfirmware" in their names)
<cjwatson> I'd still like to switch to grub2 for actual powerpc installations
<cjwatson> but not having a working powerpc right now makes it hard to drive that
<YokoZar> cjwatson: new icoutils uploaded (in queue atm)
<cjwatson> ok, thanks
<persia> cjwatson, Would you find yourself more productive with a working powerpc?
<pitti> cjwatson: we can certainly formulate the conditions in a strong dependency, but then we need an additional state property "service foo exists"
<cjwatson> pitti: this is all a next-version-of-upstart thing
<pitti> cjwatson: oh, good to hear
<cjwatson> but right now, you don't have it
<pitti> so, "dbus or runlevel" should be what we had in lucid
<cjwatson> persia: differently productive.  I would probably get less of the work I'm supposed to do done ...
<pitti> and we hacked around the problem with cups and smbd, so for maverick it should be okay
<persia> cjwatson, heh.  OK.  I'll keep that in mind :)
<cjwatson> mvo: is bug 650525 happening due to the RT ticket you filed?
<ubottu> Launchpad bug 650525 in ubuntu-extras-keyring (Ubuntu) "Failed to fetch http://extras.ubuntu.com/ubuntu/dists/maverick/Release ; missing key" [Undecided,New] https://launchpad.net/bugs/650525
<cjwatson> mvo: I thought we shipped the key text so that we didn't have to rely on fetching the key from the network, though, so not quite getting it
<mvo> cjwatson: the RT is for the software-center, this one is different, let me look
<YokoZar> mvo: btw, now that software center does its initial apt-get update on first open, the number of incidences of valid apt:// links not working due to "package not found" should reduce (though still possible if someone clicks an apturl link before opening software center or running update manager on a fresh install)
<mvo> YokoZar: yep
<YokoZar> mvo: I have a suspicion gnome-codec-install might be affected similarly (I think it breaks when no apt-get update was yet run)
<YokoZar> hopefully someone runs software center before they poke around their movie files or look up howtos ;)
<YokoZar> part of me wonders if it would be reasonable to ship a (even slightly out of date) universe packages list on the install
<mvo> YokoZar: there is a open bug about it iirc, but the additional disk space on the live cd has been a problem
<mvo> YokoZar: the first apt-get update cron job will heal it
<mvo> YokoZar: in the case of gnome-codec-install I vaguely remember there was code that detects misisng universe and offers to update, but I may mis remember
<persia> Isn't there some stuff that gnome-codec-install requests that isn't suitable for being on images?
<YokoZar> mvo: missing universe is different from never having run update (I think that code is way back when universe was unticked by default)
<YokoZar> persia: err yeah I guess multiverse package list too
<YokoZar> persia: but a package list is different from a package ;)
<persia> Ah, true.  Although I still have reservations about multiverse :)
<mvo> YokoZar: right, I just tested and its clever enough to notice that there is stuff in sources.list but the data in /var/lib/apt/liss is not there
<mvo> YokoZar: I vaguely remember I added that code at some point
<YokoZar> ahh
<YokoZar> so maybe it's just apt-url that's the problem then
<mvo> yeah
<mvo> very possible
<james_w> jibel: very useful, thanks
<james_w> jibel: I now have a much better idea of where the problem is, but no idea for a fix yet
<jibel> james_w, you're welcome. If you had an idea for the fix but no idea where the problem is, that would be a problem.
<jibel> :)
<james_w> jibel: well, that's what I was trying before :-)
<jibel> james_w, don't hesitate if you need to try something else.
<micahg> YokoZar: no, but it's scheduled for next cycle
<dpm> [15:38] <dpm> Riddell, pitti. I've just spoken to danilo. A one-off full langpack export can be arranged, we just have to decide on the date, which should probably be today or tomorrow. I'd be up for tomorrow, as that was the date on the maverick schedule, but you guys know best if that would be too tight or not. Riddell, as per checking whether the files you uploaded have been imported, you can do it here: https://translations.edge.launchpad.net/~jr/+i
<dpm> mports?field.f
<dpm>  ilter_status=all&field.filter_extension=po - they don't seem to have been yet. So what date should I tell danilo to start the export?
<dpm> Riddell, pitti, in case you haven't seen the question earlier on: if you could look at the question whenever you've got time, I can then ask Danilo to schedule the export ^^
<dpm> thanks!
<pitti> dpm: whenever the KDE translations are finished, I guess
<dpm> pitti, but in case they take really long to import and we cannot wait for them to finish, what would be the latest date for the full export request and to make sure there is room for a rebuild if there are any issues with the langpacks. Tomorrow?
<pitti> dpm: tomorrow evening, I think
<pitti> the buildds will be crammed with "OMGrightafterRC" builds, put the langpacks on top of that, and we'll have a large enough backlog already
<dpm> pitti, ok thanks. I'll watch the KDE translations and make the request for tomorrow evening the latest if they are not imported yet - Riddell it would really help me if you could tell me which translations you uploaded, or if you could keep an eye on them yourself as well
<Riddell> dpm: I uploaded the ones I e-mailed you about last night
<ogra> grrr upstart
<Guest23154> hi all im probably in the wrong channel but i guessed someone in here would be bale to tell me whats needed to build 32 efls for linux on a 64 bit ubuntu. thanks
<cjwatson> mvo: the timestamp on /etc/apt/trusted.gpg is the time when ubuntu-keyring was installed (11:01) rather than the time when ubuntu-extras-keyring was installed (11:11)
<cjwatson> suggests that the ubuntu-extras-keyring package isn't doing what it claims to do
<cjwatson> no obvious reason why it shouldn't, though, from looking at apt-key
<james_w> jibel: http://paste.ubuntu.com/502692/ is my latest guess, I've just pushed it to my PPA. If you could test that would be great
<jibel> james_w, this test machine is currently ... testing isos. I'll be able to try that this evening or tomorrow morning.
<james_w> jibel: ok, thanks
<james_w> if anyone else sees the bug where the policykit password dialog loses the textbox and then hangs, I would appreciate your feedback
<james_w> bug 649939 has the details
<ubottu> Launchpad bug 649939 in software-center (Ubuntu) "authentication popup does nothing when installating new software" [High,Confirmed] https://launchpad.net/bugs/649939
<mvo> cjwatson: indeed, what is odd is that the "OK" comes from apt-key, I will see if I can run the build livefs image script and reproduce it wit hthat
<cjwatson> mvo: I'm trying that now
<cjwatson> I have a local mirror so it shouldn't take forever
<cjwatson> mvo: (I'm shoving 'set -x' into apt-key after debootstrap)
<mvo> excellent, that should solve the puzzle
<jjardon> Hello, is there any possiblity to ship pygobject 2.26 in maverick? It's the only supported python bindings supported upstream
<jjardon> PyGTK apps are recommended to switch to PyGObject
<SpamapS> should iso's from 20100928 still say "development branch" in the issue/motd/etc ?
<persia> SpamapS, Most certainly.
<SpamapS> just verifying that while doing iso testing.
<persia> That usually changes just before the final candidates, when the name is removed, and the number added.
<doko> bdrung_: ping
<bdrung_> doko: pong
<doko> a lot of the audacious plugins fail to build
<doko> hmm, no all that I did give back
<doko> audacious-dumb g15daemon-audacious imms upse xmp
<bdrung_> not again...
<bdrung_> i start disliking audacious...
<doko> bdrung_: all but one is missing/moved header file
<kees> barry: can I pick your brain (or other python superstars) on a quick "how to I make this shorter?" puzzle: http://paste.ubuntu.com/502757/
<kees> if it we C I'd use an inline conditional
<kees> *were
<kklimonda> kees: http://paste.ubuntu.com/502763/ - you save over 20 characters! ;)
<kklimonda> almost 30.. ;)
<kees> oh, I didn't know you could do a conditional like that. nice!
<mterry> jcastro, is there some wiki documentation on how to run a good ubuntu-classroom session?  Like how to use ClassBot, how to get Lernid to see a session's slides(?), that sort of thing.
<mterry> jcastro, ah, just found it.  Classroom on the wiki
<jcastro> yep
<jcastro> I find that reading logs of other people's sessions are useful
<jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek <-- top right there are years of session logs
<uni4dfx> can someone patch the Radiance theme? there's a very simple mistake in metacity-theme-1.xml
<uni4dfx> anyone? it's a 1-character mistake
<mterry> uni4dfx, file a bug?  "ubuntu-bug light-themes"
<uni4dfx> mterry you know nothing is going to happen if i file a bug
<uni4dfx> they're gonna dump the theme before they get to it
<uni4dfx> and it's 3 seconds of work to fix it
<uni4dfx> even if i submit a patch, they won't even look at it
<mterry> uni4dfx, that's a depressing attitude.  :)  Bugs are how ubuntu developers track and fix things, even trivial ones.  Doesn't mean it will get fixed faster, but it helps it get fixed at all
<micahg> uni4dfx: we have a patch review team now that tries to get to the patches
<uni4dfx> So if I submit a patch can it be applied before Maverick is out?
<mterry> uni4dfx, it's pretty tight schedule wise.  depends on how severe the bug is.  If it doesn't make it, it can be released as an update
<uni4dfx> mterry it's a bug that can be fixed by changing 1 character in an xml file
<mterry> uni4dfx, right, but that doesn't mean it's a severe bug.  Like a bug that crashes everyone's desktop will probably be squeezed in, but a bug that just means the wrong color of purple was used somewhere will probably just be released as an update
<micahg> the why examples are appropriate now as well: https://wiki.ubuntu.com/StableReleaseUpdates#Why
<uni4dfx> well that's like saying we're going to spend 6 months fixing 2 bugs and screw the rest that actually have patches committed
<doko> siretart: ping
<siretart> doko: hi
<doko> siretart: https://edge.launchpad.net/ubuntu/+source/odin/1.8.1-2build1/+build/1921597
<doko> is ffmpeg/altivec built with -fPIC?
<doko> I love builds which don't show compiler flags ...
<mterry> uni4dfx, my advice is still to file a bug with the patch
<siretart> does powerpc accept shared library builds without -fPIC at all?
<uni4dfx> mterry on it
<siretart> oh, yeah, I see what you mean
<siretart> doko: I'm pretty sure that it is, and I need to switch off this obfuscation for natty, right
<doko> siretart: how do you turn it on? VERBOSE=1 doesn't work too well
<siretart> V=1
<lex79> slangasek: can you look at this bug 262679 please? it's there since jaunty
<ubottu> Launchpad bug 262679 in EasyPeasy Overview "eeepc-acpi-scripts is not installable" [Low,Confirmed] https://launchpad.net/bugs/262679
<lex79> basically eeepc-acpi-scripts depends on acpi-support-base which is not in archive
<pnt> anyone running 10.04 that can help me confirm a bug in scanf?
<persia> pnt, We typically coordinate that sort of thing on #ubuntu-bugs
<pnt> thanks
 * ogra_ac found the right kernel tree for the ac100 to build modules \o/
<ogra_ac> and its still usable even with running make -j2 in the background
<izzytemp> Where is the information stored in the panel. When it becomes customized, where do the customizations go?
<izzytemp> I put some stuff there and I would like to be able to transfer it to other machines
<slangasek> lex79: frankly, that package needs a lot more help to be properly integrated in Ubuntu than just fixing a dependency
<lex79> slangasek: but that package shouldn't be in archive imho
<lex79> for now I mean
<slangasek> well, we can remove it and blacklist it from being synced from Debian, sure
<lex79> it just make confusion on users
<slangasek> lex79: subscribed ubuntu-archive to bug #328989; I don't have time to process it just this moment
<ubottu> Launchpad bug 328989 in eeepc-acpi-scripts (Ubuntu) "eeepc-acpi-scripts package should be removed" [Undecided,New] https://launchpad.net/bugs/328989
<lex79> slangasek: ok
<yofel> pitti: can you merge https://code.edge.launchpad.net/~yofel/apport/lp-590521/+merge/37069 ? typo fix
<ogra_ac> does anyone else have a weird experience going to people.c.c ?
<ogra_ac> i get an advertisement
<ogra_ac> This domain may be for sale. Buy this Domain
 * ajmitch doesn't
<ogra_ac> http://people.canoncial.com/~ogra/
<ogra_ac> lol
<ajmitch> heh
<ajmitch> nice typo? :)
<ogra_ac> i should learn to type
<asac> bug 642792 feels really nasty. anyone knows if there was an explicit decision made this cycle to change that?
<ubottu> Launchpad bug 642792 in metacity (Ubuntu) "ALT+PrtSc not recognised" [Undecided,Confirmed] https://launchpad.net/bugs/642792
<persia> asac, That's an extra-hard one: it's about contention between kernel and GNOME.
<asac> well
<asac> persia: what i want to understand where the change resulting in this regression was decided ;)
<asac> and ensure that that discussion involved all the right parties
<persia> I don't believe there was such an explicit decision.
<asac> then it needs to be changed back
<asac> or fixed
<asac> ;)
<asac> alt-print cannot be changed without an explicit decision imo ... at least not from the kernel side
<persia> asac, So, which bit needs to be "changed back"?  the kernel, or GNOME?
<asac> persia: i assume the kernel changed this cycle
<asac> gnome didnt change
<asac> whatever changed this cycle needs to be changed back ;) ... at least the default setting of gnome was not touched
<ogra_ac> asac, just use your digital camera
<asac> lol
<hallyn> cjwatson: kirkland suggested i should be talking to you...  i've got two cases where lucid will do the right thing with external disks, and maverick won't (last tested last weekend).  the first, using cryptsetup, i opened a bug for a long time ago
<asac> ogra_ac: actually i tried changing it to something else in keybindings preference and now i cannot change it back because its not recognized as any key-combo at all; in short: i am all set :-P
<hallyn> cjwatson: the other, is an iomega drive, not encrypted, 1 partition, which automounts under lucid, but (same laptop) in maverick fdisk -l says something about bogus sectors
<hallyn> cjwatson: alas the drives and laptop are at home, and i'm out for the week, so i can't give details right now
<asac> ogra_ac: so according to that bug if you disable sysrq the key combo is recognized as "Alt-SysRq" rather than "Alt-Print" in gnome
<ogra_ac> wow
<asac> ogra_ac: what do you think changed that would cause this?
<persia> Depends on the keyboard, really.
<asac> kernel? gtk? keymaps?
<ogra_ac> kernely or keymaps i'd say
<asac> persia: does it work for you? ;)
<persia> asac, "work" how?
<asac> persia: press alt+print ... and see if you get a screenshot of current window
<persia> The answer is "sometimes".
<asac> are you running maverick?
<persia> Depends whether I use my German or Japanese keyboard (both are connected)
<persia> Yep.
<asac> so its german keyboard only?
<persia> German keyboard works.  Japanese keyboard works only if I press Alt+SysRq twice in a row quickly enough
<hallyn> jjohansen: kees: cjwatson: btw, bug #622762 was the one i originally openedd for the first issue
<ubottu> Launchpad bug 622762 in cryptsetup "encrypted partition works in lucid, not maverick" [Undecided,New] https://launchpad.net/bugs/622762
<asac> hmm. my german keyboard does not work
<persia> (where "works" means I get the screenshot popup)
<asac> persia: and a screenshot of window rather than full root window?
<asac> ogra_ac: does it work for you?
<persia> asac, I don't think it's the layout of the keyboards, but rather how they encode SysRq.  the Japanese keyboard is Logitech and the German keyboard is Cherry
<ogra_ac> asac, i cant find the print key
<asac> omg :-P
<asac> ogra_ac: its often somewhere at the top ;)
<ogra_ac> i know :P
<ogra_ac> this thing has an android adjusted kbd
<persia> asac, Strangely, when I tried to reproduce, I ended up with a stuck ALT key until reseting *both* keyboards simultaneously (plug events)
 * persia concludes Alt*SysRq behaviour is determinisitic in far too complicated a manner
<ogra_ac> asac, i dont use an ubuntu kernel, but nothing happens if i hit alt+print
<ogra_ac> (german keymap though)
<ogra_ac> print alone gets me a desktop shot
<asac> interesting
<asac> does not really help us much ;)
 * asac out
#ubuntu-devel 2010-09-30
<Riddell> davidm: ok to release images for RC?
<ogra_ac> Riddell, what does the isotracker say (and better ask GrueMaster, he is testing atm)
<ogra_ac> Riddell, theoretically they should all be fine
<Riddell> ogra_ac: if I read it right it says there's a couple of serious bugs and no failures
<ogra_ac> Riddell, great
<ogra_ac> so we are not jobless after RC :)
<ogra_ac> Riddell, looking at the treacker they seem to all be known bugs ... fine to release
<ogra_ac> Riddell, netbook preinstalled for armel omap and omap4 ... netbook live for armel dove are the images we release
<ogra_ac> ... and with that statement i'm off to bed
<jjardon> Hello, is there any possiblity to ship pygobject 2.26 in maverick? They are the only supported python bindings upstream
<jjardon> Also, PyGTK apps are recommended to switch to PyGObject ASAP
<persia> You mentioned this before.  You might want to file a bug.  IRC is notoriously bad at maintaining state.
<persia> At this point, it would require significant coordination push, and be considered release-critical by a number of people.
<persia> It's most especially concerning because it is known that all the apps that use the PyGTK and PyGObject implementations currently in maverick work (at least to the extent each application has been tested).
<persia> It is most certainly unknown whether they would work with the latest PyGObject (And many likely remain to be ported)
<poolie> hi, will someone please sponsor maxb's upload from https://bugs.launchpad.net/bugs/636930
<ubottu> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged]
<ScottK> poolie: Are you asking for a 2.2.1 upload or just a fix for this?
<ScottK> (I think I see both in the bug)
<poolie> ScottK: the whole bugfix update
<poolie> ie all of 2.2.1
<poolie> ScottK: we have a microreleaseupdate exception
<persia> poolie, That's only a guarantee that the upstream can be processed, not that a given packaging of it happens to be suitable for sponsoring (not meaning anything either positive or negative towards this specific packaging)
<maxb> I can't
<maxb> oops, I just responded ot something hours ago in scrollback
<poolie> persia, scottk, ok so what can we actually do with this specific package?
<maxb> First things first, we need an official ubuntu-release verdict on whether to go release pocket or SRU
<maxb> As informal IRC opinions have been inconclusive
<persia> poolie, Wait for someone who can upload it (not me) to review and either upload or comment on why they aren't uploading.  It's exceedingly unlikely to be sponsored pre-RC release, and even if it is so sponsored, isn't going to be accepted by the Release Team until post-RC.
<poolie> how could we get in touch with such a person?
<poolie> historically just subscribing the team to the bug and commenting has not got much of a response
<persia> maxb, If you're seeking that, then yes, you want to have had a different request.
<maxb> Exactly - thus, the first thing being getting the release team's verdict on whether they want this in release or proposed pocket
<persia> poolie, It's supposed to work that way.  When it doesn't, you can ask here or in #ubuntu-release.
<poolie> ScottK: i see you're in ~ubuntu-release, what do you think?
<poolie> running the tests now
<ScottK> poolie: My view is that successfully completing the tests that would be mandated for an SRU is a precondition.  If it can do that (and from the bug, I have the impression that you aren't quite there yet), then I would tend to be in favor, but I'd want to discuss it with pitti, since he seemed to lean against.  If there's a focused patch for that particular issue, I'd recommend uploading that while it's decided.
<ScottK> poolie: It would also be useful to know if bzr is in fact on an ISO or just in Main for other reasons.  I don't know and I'm too tired to look it up at the moment.
<james_w> I'm pretty sure it's just in main
<ScottK> That would make it less scary from my POV since it gives us almost another week to deal with regressions.
<persia> If fails to show in any of the manifest files I mirror (which is an incomplete set, but wide).
<ScottK> Of course if I sponsor it, then I can't accept it and the final decision becomes "not my problem".  That has a certain appeal too.
<persia> heh
<sladen> ScottK++
<poolie> ScottK: i ran the tests and posted the outcome; not sure if you saw that yet
<poolie> oh i see
<poolie> ok, i'll work out what's up with that ssl error
<poolie> james_w: your bug 646979 logic seems plausible to me on a brief read through
<ubottu> Launchpad bug 646979 in bzr-builddeb "merge-package should maybe vary which branch it merges the combined upstream to" [Undecided,New] https://launchpad.net/bugs/646979
<james_w> good
<poolie> i stress only brief for the moment
<james_w> yeah, I'm not going to take snap action after thinking about it for this long :-)
<dholbach> good morning
<jibel> didrocks, could you have a look at bug 651325. it was during a test upgrade from a fresh wubi 10.04.1 to 10.10
<ubottu> Launchpad bug 651325 in update-manager (Ubuntu) "package gnome-keyring 2.92.92.is.2.30.3-0ubuntu1.1 failed to install/upgrade: /var/lib/dpkg/tmp.ci/preinst: 31: dpkg-maintscript-helper: not found" [Undecided,New] https://launchpad.net/bugs/651325
<didrocks> jibel: oh, let me check, I have an idea why we can have that :)
<didrocks> jibel: yeah, dpkg doesn't have dpkg-maintscript-helper in list, I get trapped :)
<didrocks> jibel: I'll fix that then, thanks for the info :)
<jibel> didrocks, thank you
<mvo> didrocks: I have a fix ready, its just a missing pre-depends on dpkg
<didrocks> mvo: oh good, thanks :)
<mvo> didrocks: commited, I can upload if nothing else is pedning
<didrocks> mvo: anything else as far as I know of, please do :)
<didrocks> (that's maybe something to list until next LTS, if we use dpkg-maintscript-helper, for handling upgrade from lucid, we need the pre-depends on dpkg)
<didrocks> not sure where to list that however
<persia> debian/README.source might be a handy innocuous place for that sort of thing.
<didrocks> persia: for dpkg? do you think people using dpkg-maintscript-helper will look at dpkg README file? :)
<persia> didrocks, I was thinking for that which needs it.  If you want something more general, then it probably belongs in the dpkg-maintscript-helper manpage.
<didrocks> yeah, that was my guess, I'll patch it for natty
<YokoZar> Can someone reject my (pitti-sponsored) icoutils upload, I need to make a new one (the license has changed and debian/copyright needs to be fixed)
<StevenK> YokoZar: To maverick?
<YokoZar> StevenK: Yeah
<StevenK> YokoZar: 0.29.1-0ubuntu1 ?
<YokoZar> StevenK: yup
<StevenK> YokoZar: Right, cool. Rejected.
<twb> Does Ubuntu have something like cdn.debian.net, which resolves to a "nearby" mirror?
<twb> I realize ubuntu's d-i has some cleverness to pick a nearby mirror at install time, but a one-shot detection is suboptimal for roaming laptops.
<persia> twb, I don't believe so.  There's some mirror stuff in python-apt, and I think update-manager can use it (but I don't believe it does more than verify the sources.list only contains mirrors in the list)
<twb> I guess the other way to do it is to just get everyone onto ipv6 and use anycast :-P
<persia> Heh, indeed.
<pitti> Good morning
<pitti> yofel: will do, thanks for the MP
<pitti> ScottK: I guess bzr is at least on the DVDs
<twb> Actually, while we're discussing it, what is the *CLI* equivalent of apt-spy in Ubuntu?
<twb> I see synaptic can do it, but that's no use on a server.
<twb> (That is, go get the mirror list from ubuntu.com, count the hops to each one, then return the mirror with the fewest hops.)
<persia> twb, I'm not sure we have one: there's a local mirror list from python-apt which would be a sensible place to start.
<twb> okey dokey
<twb> For my own means I usually know out-of-band, but it comes up on #ubuntu-server occasionally
<persia> Probably easy enough to toss one together.
<mvo> twb: there is a "mirror" protocol in apt
<mvo> twb: you can use "deb mirror://mirrors.ubuntu.com/mirrors.txt maverick main universe"
<twb> Oh neat
<persia> Oh, cool!
<mvo> its not perfect yet, that is why we have no done it by default (yet)
<mvo> but it should work pretty well 99% of the time
<twb> There was also that guy working on a bittorrent apt method, but I don't think he got it production-ready
<mvo> twb: yeah, apt-transport-debtorrent - we have it in the archive
<twb> Do you happen to know what the Debian equivalent of mirrors.ubuntu.com/mirrors.txt is?  README.mirrors.txt has a different format
<mvo> twb: where is README.mirrors.txt located?
<twb> http://ftp.au.debian.org/debian/README.mirrors.txt
<poolie> hi pitti,
<twb> I *think* that's the file apt-spy uses
<pitti> hey poolie
<poolie> given our test results that there are no new test failures from the installed bzr, in bug 636930
<ubottu> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] https://launchpad.net/bugs/636930
<poolie> what's next?
<twb> method/mirror.cc doesn't offer much explanation, except it implies that mirrors.txt would need to be dynamically generated by the server (based on geo-ip or such) to be useful
<mvo> twb: aha, thanks. the mirror method in apt depends on a server that uses geoip so it will not be able to use this file
<persia> The fastest server is often not the nearest one geographically, depending on network topology.
<twb> persia: I was impressed that it even listed my ISP's tertiary mirror, though
<twb> It wasn't the first one in the list, though
<twb> I get http://paste.debian.net/92510/ from within the internode network, but I am originating from a portable IP so it probably doesn't get very well.
<twb> s/get/guess/
<twb> Hmm, same result when coming from an ISP-assigned IP.
<poolie> pitti: ?
<mvo> twb: yes, it relies on the server, the long term goal is to provide stats (opt-in of course) so that the server can build a optimal list for most people
<mvo> tkamppeter_: hi, around? is foomatic-db-compressed-ppds a drop-in replacement for foomatic-db or are there apps that breaks if foomatic-db-compressed-ppds are installed instead of foomatic-db ?
<pitti> poolie: as I said, it can be uploaded to maverick-proposed
<poolie> maxb: so i think now you should ask someone to sponsor your upload to maverick-
<poolie> proposed?
<persia> Common procedure is to prepare a candidate upload with maverick-proposed in the changelog, and either propose a merge in LP or file a bug and subscribe the sponsors team with a debdiff.
<maxb> poolie: well, hmm. only if the decision has been finally taken to handle this as a SRU, not a late-breaking release pocket upload
<maxb> I am tempted to just arbitrarily decide it's a SRU, given that's what we were intending to do at first, before the idea of a late-breaking release pocket upload was ever mentioned
<poolie> maxb, i don't know if that's optimal but it's pretty good
<poolie> i suspect everybody running this will get -updates
<poolie> and it'd be nice to just get it resolved and do other things
<mvo> tkamppeter_: if you have time I would like to talk about #647460, what we can do about it
<persia> maxb, The statement at :12 by a member of ~ubuntu-release seemed fairly definitive that it ought be considered for SRU.  Feel free to copy & paste to a bug comment if you want it tracked there.
<maxb> persia: yes, I think we shall aim for SRU. The confusion has been that we've had different thoughts on the matter from pitti and ScottK
<pitti> a week ago we weren't frozen for RC yet, so back then my suggestion was to just upload it if it was ready
<persia> maxb, The key is to take the first answer you get from any member of the release team, make sure it's documented somewhere, and run with it.  If you wait for RT consensus, you'll end up in next cycle :)
<persia> (and all the members of the release team tend to tell you to ask someone else if they aren't prepared to take a decision)
<poolie> yeah, or take the answer you like best :)
<pitti> it didn't really differ, though
<pitti> it makes a difference whether you ask before or after a freeze :)
<persia> poolie, Please don't do that.  The first answer should be correct (there was a long discussion about one answer vs. two answers in agreement in the past with the conclusion that one was the right way to proceed)
<mvo> cjwatson: I think I found the bug in the livefs script (just fyi so that we don't duplicate work)
<doko> I'd like to understand why https://edge.launchpad.net/ubuntu/+source/lash/0.6.0~rc2-1 ended up in maverick. there's no sync request about it
<persia> I thought I requested that.
<doko> persia: being aware of the armel and powerpc build failures in experimental? :-/
<persia> From experimental?  I didn't request that.
<persia> (and I can't find the bug either :/ )
<doko> there is none ...
<persia> There was one.  NCommander, I, ogra, and seb128 all touched it, and Riddell closed it, unless I'm thinking of a different lash
<persia> But that was for a sync from *unstable*
<seb128> I don't even know what that source is I doubt I touched it
 * ogra neither
<persia> seb128, There was an associated issue with d-shlibs and you told NCommander to fix it with hinting, rather than a hardcoded patch.
<ogra> oh, that one
<persia> Right.  I requested the sync of 0.5.4.0-2 (https://launchpad.net/ubuntu/maverick/+source/lash/0.5.4.0-2 )
<persia> doko, Sorry for the confusion.
<doko> persia, and we ended up with 0.6rc2?
<persia> I don't know how that happened.  0.5.4.0-2 was FTBFS on armel because of some other stuff related to d-shlibs, but 0.6rc2 is broken for much more annoying reasons.
<seb128> doko, ask quadrispro
<seb128> he did the upload it seems
<seb128> he apprently synced it manually himself
<Laney> looks like a syncpackage upload
<doko> seb128: it's a sync ...
<seb128> doko, it's a fake sync
<seb128> ie one done manually
<Laney> override distro in changesfile, sign, upload
<seb128> otherwise it would be an Ubuntu Installer upload
<doko> seb128: yes, from experimental, so there should be a bug report?
<Laney> that's not enforced
<Laney> any developer can just upload as normal
<seb128> doko, no, it's an upload by somebody with upload rights
<doko> ahh, that could be. but quadrispro is the debian maintainer too, and uploading something which is broken on three archs is ... unfriendly
<seb128> doko, talk to him I guess, I don't know why he uploaded
<persia> It's rather unfortunate, really.  Lots uses lash.
<doko> anyway, fixed
<ogra> i asked him to apply the same patch to d-shlibs we used in all former releases
<ogra> which back then fixed 0.5.4.0-2
<doko> seb128: still wondering why a fake sync is required for an .orig.tar.gz not yet in ubuntu
<Laney> doko: People do it because it means your upload happens immediately rather than waiting for an archive admin
<doko> Laney: fine, imnsho this maybe should be restricted
<seb128> doko, it's not required, it's somebody who decided to not wait on archive admins and file a proper sync request and did it manually itself
<seb128> doko, there is no way to restrict that, it's like restricting upload to somebody having upload rights
<doko> seb128: policy?
<seb128> he could as well have taken the debian version changed the number to 0ubuntu1 or 1~ubuntu and uploaded
<Laney> I've tried to convince individuals that it's usually not required.
<Laney> having said that though, I have used such scripts myself
<Laney> for example when running a transition with long dep chains
<seb128> doko, the last time that was discussed on the list nobody objected strongly to people doing their sync themself
<persia> Laney, Most archive-admins will happily run a sequence of lists for those over a few hours, if given a prepared list.
<seb128> ideally we would not need archive admin to do syncs
<seb128> whoever has upload right should be able to sync
<pitti> I do that all the time; I fix somethign, and then upload to Debian and Ubuntu at the same time
<seb128> there is no reason to review syncs over uploads
<persia> We all agree that developers should be able to do syncs, but we should be doing them *IN LP*, not with hacked .changes files.
<ajmitch> seb128: that requires a bit more work on soyuz though
<seb128> right
<pitti> persia: what do you think sync-source.py does? :-)
<seb128> but that would not have solved the issue doko has there
<persia> ajmitch, Not that much: mostly currently blocked on running the changelog import job.
<doko> seb128, Laney: yes, but please not from experimental, and not, if you know as debian maintainer, that the package builds on everything non ix86
<ajmitch> pitti: I've seen the code, it's evil :)
<pitti> at some point we'll have native source syncing, like copy-packages.py
<seb128> doko, you have an issue with the maintainer decision there not with the policy or workflow
<persia> pitti, I know precisely what it does: I've used it.  The key bit is that we track it nicely when we use the AA-based process.
<Laney> doko: Really it's just an instance of general care when uploading. In this case the fact that it's an emulated sync is immaterial
<pitti> when we have a complete and current Debian import
<pitti> persia: oh, you are an archive admin now?
<seb128> doko, we would have synced it the same way if it was an official sync request
<pitti> persia: (sync-source.py is the launchpad script)
<persia> pitti, No, but I used your script back in the hardy-release-rush because you gave it to me to run out-of-archive because you didn't have time for my syncs :)
<doko> seb128: without looking for build failures first? sorry that a thing at least I do check
<seb128> doko, we can check debian builds etc for the hundred of sync request every week, we just trust the maintainer who do requests
<persia> Oh, I'm thinking of something different then.
<pitti> persia: ah, that's something else; but in essence it does teh same as the launchpad script: craft a .changes for an existing .dsc
<seb128> doko, it's the job of whoever has upload rights and been asking for the sync or acking it
<persia> Right.  There's a better way to do it mostly ready on LP, but pending some job execution time.
<seb128> doko, and not archive admin doesn't have the time to do the submitter work and check everything for hundred of syncs
<persia> Maybe sometime during natty, if we're lucky.
<Laney> persia: Yes, indeed I could have, and have done in the past for haskell transitions. In this instance I had quite limited slots to work on the rebuilds so didn't want to block on anyone else, but I take your point.
<pitti> FTR, archive admins can't check Debian FTBFS when doing sync processing either
<doko> no, but it should be policy for the uploader
<persia> And they oughtn't be expected to.  archive-admins ought perform the syncs nearly blindly, if it has the right ACK.
<Laney> you have to assume that the uploader knows what they are doing
<pitti> doko: I agree
<seb128> doko, right
<persia> doko, Yes.  Complain to quadrispro
<pitti> i. e. on the uploader's or sync requestor's side
<Laney> anyway, maybe a mail to the uploader CCed to some ML would work here
<seb128> as said before the issue there is the maintainer, no how it was synced
<ajmitch> now if it was fine in debian & only failed to build on those archs in ubuntu, that's harder to catch for a maintainer
<bdrung_> yes, the uploader has to make sure that the package builds
<pitti> persia: I mainly use my syncpackage script because it simplifies my workflow; I don't need to wait for a day after the Debian upload and then remember to do the sync, etc.
<ajmitch> bdrung_: right, but it's hard to test on hardware we don't have unless it's uploaded to PPAs
<Laney> It's easy to catch, because you get a mail for the FTBFS.
<bdrung_> ajmitch: it needs to build at least on your architecture
<persia> pitti, I almost always wait, just to check for odd build issues, etc. (although less now that I can test-compile on all remaining architectures in Ubuntu)
<Laney> fixing with a subsequent upload isn't a problem
<Laney> ignoring porting problems is
<quadrispro> ehy, I'm here, hi all. Sorry for the {delay,mistake}, I need just some minutes and I'm working on the patch
<pitti> persia: hm; I just build on amd64; I don't think that a lot of people test-build on more than one arch
<persia> Laney, Ideally, I'd prefer that it wasn't like that, just because sometimes it interferes with images at milestone times.
<pitti> and frankly, I think they shouldn't
<persia> Why not?
<pitti> sudden arch specific FTBFS don't happen often enough to warrant slowing down every developer to test build on arm
<doko> quadrispro: it's now fixed
<pitti> you'd kill a lot of productivity for a very unlikely cause
<pitti> and if it FTBFSes on the arm buildds, you'll get a mail and can still deal with it
<persia> pitti, most packages don't take *that* long on armel, but yeah, until there's lots more fast HW...
<quadrispro> oh, I get there late
<pitti> persia: well, but few people have an armel box at home :)
<doko> yes, three month
<persia> pitti, Yeah, well, ones capable of running what Ubuntu appears to have stabilized upon have only been on the market ~1 year.
<pitti> persia: and even if they do, I still consider test-rebuilding every package update locally on three arches before upload a massive waste of developer time/power
<doko> pitti: in this case: https://buildd.debian.org/status/package.php?p=lash&suite=experimental
 * persia needs to clean up and publish some scripts.
<pitti> doko: oh, I wasn't arguing against checking the Debian buildds before requesting/doing a sync
<pitti> doko: just that I don't want people to test-build every upload on three arches
<persia> pitti, I think everyone should test-build on every arch *as long as it doesn't slow them down*.
<persia> I agree that waiting around for builds to finish is a waste of time.
<pitti> persia: but it will slow you down..
<persia> Why?
<pitti> persia: I don't think our buildds are a bottleneck enough to consider the odd arch specific FTBFS as too much of a resource waste
<pitti> developer time >> buildd time
<quadrispro> the ftbfs mail was put in spam by gmail... I'm very very sorry of that
<quadrispro> 25 september
<pitti> persia: how many devs do you know who have a fully automated kees-style sbuild system which will do automatic builds on three arches for a pacakge?
<persia> Maybe 10.
<pitti> wow
<pitti> that's about 9 more than I know, so I'm honestly surprised
<pitti> persia: well, let's just agree to disagree then
<doko> pitti: but it adds work load for people then having to clear up things
<persia> I might be over-estimating, but I know there's been quite a few of us who have been discussing the multi-arch simultaneous sbuild dispatch stuff over the past 3-4 cycles.
<pitti> doko: no, why?
<doko> pitti: http://people.canonical.com/~ubuntu-archive/NBS/
<pitti> doko: if I upload a new package which suddenly FTBFSes on armel because of, say, a toolchain change, I get notified and can fix it afterwards
<pitti> how does that slow down anyone else?
<doko> so the soname upload have to be done again
<pitti> but 90% of the FTBFSes that I get are either random buildd congestion or bad timing with library transitions, etc.; and they don't happen on local rebuilds anyway, so they wouldn't help me at all
<pitti> doko: soname upload?
<pitti> "same"?
<persia> pitti, The difference might be that folks who chase build failures get the worst of things, for packages that aren't watched so closely, and you take care of healthy packages that just work.
<pitti> persia: presumably
<doko> liblash soname change
<pitti> persia: but I'm specifically not talking about trying to fix an existing FTBFS
<persia> Because I wish things worked the way you describe, but sympathise with doko's experience.
<pitti> I'm not arguing about the lash example here
<pitti> I agree that one should at least check Debian buildd status before requesting a sync
<doko> but while I have all your attention ...
<pitti> I'm just aguing against your "every dev shoudl test-buid every upload on every arch"
<persia> doko, ?
<doko>    ... there are still three powerpc build failures we should care about: performous-tools, mrpt and odin
<doko> and: http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev
<azeem> what's with libopensync0-dev?
<pitti> it's NBS
<doko> azeem: not anymore in the archive
<azeem> ah
<pitti> azeem: the reverse dependencies need to be rebuilt against libopensync1exp7
<azeem> good luck
<pitti> cjwatson mentioned that these are nontrivial, i. e. require sourceful changes
<\sh> pitti: how should someone do sbuild setups for arm archs on an amd64 which can do i386 and amd64 for me? If that's needed, I'm happy to setup my machine for that...
<persia> doko, performous looks reasonably easy.  I'll try my quick solution on a build (but am planning to sleep, so won't upload for some hours)
<azeem> pitti: if you dropped libopensync0-dev, I advise to just pull opensync altogether
<pitti> \sh: that's what I'm saying -- I don't think you should, unless you are working on an arm specific issue
<azeem> we dropped libopensync1exp7 for squeeze, or never really considered it
<pitti> azeem: well, "you" -- Debian did
<pitti> I guess someone asked for an experimental sync
<persia> \sh, `mk-sbuild --arch=armel maverick` :)  (It's a bit buggy, and better to use real HW)
<azeem> ok, I don't know what the reason was to remove opensync-0.22
<\sh> pitti: well, but I would like to know if the packages are building on all supported platforms, even if arm is nothing I'm involved in the first place
<persia> --arch=powerpc is supposed to work, but it doens't very well :(
<pitti> \sh: if only we had machines which would automatically build your upload on all supported architectures :)
<\sh> persia: yeah...that's one of the problem...it's not reliable then real hw...but I'm one of the happy guys, who don't own any arm devices, and I wouldn't know for what I would need such devices ;)
<persia> I like them for really small laptops :)
<\sh> pitti: well, if ARM ARCH vendors are interested in support ubuntu development they could sponsor a build farm or at least the access to those devices for building purposes
<pitti> \sh: we do have armel buildds
<pitti> \sh: and you'll get a mail if it fails to build there
<persia> \sh, Both Genesi and TI have currently open public board offerings for open source developers.
<\sh> pitti: yes...but we could testbuild them before occupying needed resources on those buildds...I mean, before I upload anything, I have at least two automatic arch builds on my local sbuild server
<\sh> persia: for what purpose? more desktop agnostic, or as well server agnostic? for server things I could even occupy resources in our DC to eventually provide cheap and energy efficient alternatives for having Tomcat apps servers or Mono app servers...;)
<persia> I believe TI is looking for folks to do exciting and cool things with their just announced new board.  Genesi seems to be looking for folks to generally improve a number of use cases so they can push follow-on products.
<persia> But I'm just guessing.
<Riddell> ogra: where can I download the ubuntu netbook ARM images for beta?
<ogra> Riddell, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/
<Riddell> ogra: oh aye, duh
<geser> doko: I just saw on the recent FTBFS rebuild results that python3-stdlib-extensions 3.1.2-1 FTBFS and that you fixed it already in Debian. Should we try to get the fix into maverick?
<doko> geser: on my radar, main is currently frozen
<cjwatson> hallyn: I really don't know very much about cryptsetup, I'm afraid ...
<cjwatson> mvo: oh good, I hadn't analysed the output of my run yet.  what was the problem?
<cjwatson> azeem: I'd be a bit concerned about dropping opensync given that we've had people turning up to UDS before telling us how important opensync is
<cjwatson> (and yes, I know they haven't contributed the developer effort to get it all in sync for maverick, but still ...)
<azeem> cjwatson: right
<azeem> cjwatson: it's just a pretty sad situation
<azeem> upstream development picked up again, but 0.3x isn't even encouraged to be *packaged* by upstream
<azeem> let alone shipped
<mvo> cjwatson: there is a little part in the script that copy the build-hosts keys, creates a backup of the trusted.gpg file and then restores it when the livefs build finished
<mvo> cjwatson: I have a fix in bzr that I'm testing currently
<cjwatson> mvo: I must be blind, I swear I looked for such a thing - but now you mention it I do see it
<cjwatson> mvo: your fix looks sensible to me
<mvo> cjwatson: fix is in r403, double checking  the diff is welcome of course
<mvo> cjwatson: great, I inspect hte image now, if that is good I will upload
<mvo> cjwatson: do I need to talk to IS to get it deployed or is that done automatically (i guess the later)?
<cjwatson> the latter
<mvo> thanks
<cjwatson> BuildLiveCD changes require an RT ticket; livecd.sh is upgraded at the start of every build run
<mvo> ok
<mvo> could some native speaker have a quick look at http://paste.ubuntu.com/503196/ please? the "To see whats new in this release visit" is new text that is displayed right before a lucid->maverick upgrade.
<cjwatson> mvo: http://paste.ubuntu.com/503200/
<mvo> thanks cjwatson
<elmo> 'desktop or server' seems a little outmoded
<rgreening> doko: ping
<james_w> jibel: \o/ systematically refused is what I wanted :-)
<james_w> jibel: it means I diagnosed the problem correctly at least. It's clearly not a fix though
<james_w> jibel: thanks for testing
<jibel> james_w, that's completely user unfriendly, that's cool then.
<jibel> james_w, tell me when you want to test something else.
<james_w> oh yeah, it's not a proposed fix, just a way of verifying I had the right idea of the problem
<james_w> I'll look at a way of fixing it now
<jibel> james_w, no problem, just ping me.
<james_w> thanks
<Riddell> akgraner: could you tell steveire what he has to do for his talk, he's not done one before
<pitti> mvo: is there an apt branch for lucid-updates?
<pitti> mvo: (I mean a real one derived from ~ubuntu-core-dev/apt/ubuntu)
<mvo> pitti: not currently, why?
<pitti> mvo: I'm about to merge our apt in the OEM common PPA with lucid-updates
<pitti> mvo: so I'll just grab the diffs from Launchpad and apply them
<mvo> pitti: aha, ok. that will be best
<akgraner> Riddell, sure I emailed all the session leaders for today and I'll touch base with him as well him on IRC as well....
<quadrispro> doko__, I've left a patch on #646824, please let me know
<quadrispro> see you soon, bye!
<pitti> Riddell: oh, maverick unapproved flushed? the RC images are good then?
<Riddell> pitti: they got approved by their various teams, I don't know if what's quite what you were asking :)
<doko__> quadrispro: loos fine, will you upload?
<pitti> Riddell: great to hear
<Riddell> pitti: ubuntu announcement is just waiting on various americans to wake up
<pitti> yippie
<JontheEchidna> silly west coasters
<cjwatson> mvo: should bug 645436 be reclosed given your livecd-rootfs upload?  (though it does mention some typos)
<ubottu> Launchpad bug 645436 in ubuntu-meta (Ubuntu Maverick) "source NEW ubuntu-extras-keyring and upload new ubuntu-meta" [High,Fix committed] https://launchpad.net/bugs/645436
<meh2> hey guys.. is there a developemrnt for ubuntu to support touchscreen laptops?
<mvo> cjwatson: let me have a look
<mvo> cjwatson: I close it now, but fix the typos (they are harmless but confusing)
<cjwatson> mvo: thanks
<jcastro> can someone moderate my post to -devel from yesterday? (or it might have been the day before)
<jcastro> also, it's been 5 years, maybe I can get whitelisted now? :)
<paissad_> guys, i'm prompted during my packaging by this
<paissad_> out-of-date-standards-version 3.8.4 (current is 3.9.1)
<paissad_> but "apt-cache policy debian-policy" shows me 3.8.4 at most !
<ScottK> paissad_: Please don't ask the same question on multiple channels.
<paissad_> not upgradable from apt-get or aptitude then
<paissad_> ScottK, oh sorry ^^ ...
<cjwatson> jcastro: done and done
<jcastro> thanks!
<seb128> jcastro, so nothing is stopping you from spamming us now? ;-)
<highvoltage> cjwatson: could you approve my message to the ubuntu-devel list?
<cjwatson> uh, I just did a moderation pass - when did you send it?
<jcastro> seb128: don't worry, I will stay out of the default aps one. Since I know you already know what to do. :)
<highvoltage> cjwatson: about 2 minutes ago
<seb128> jcastro, ;-)
<highvoltage> (perhaps it's just slow to get there)
<cjwatson> not in the moderation queue yet.  be slightly more patient :-)
<highvoltage> ok :)
<doko> siretart: ping
<tkamppeter_> mvo, I have tested printconf and it is not compatible with Ubuntu any more. It lost track with the development of CUPS. I suggest removing it from Ubuntu.
<OdyX> tkamppeter_: we might want to discuss this with Chris in order to get it removed from Debian tooâ¦
<tkamppeter> mvo, OdyX, printconf's upstream ChangeLog ends on 2003-05-27 so it is discontinued upstream. What did hold it so long in the distros.
<mvo> tkamppeter: thanks
<OdyX> tkamppeter: afaik, it was a project of Chris Lawrence, who happens to be DD, soâ¦
<mvo> tkamppeter: what about foomatic-db-gutenprint ? it depends on foomatic-db, can it also depend on foomatic-db-compressed-ppds?
<mvo> tkamppeter: same for ebox-printers?
<mvo> tkamppeter: those are the three that have no "foomatic-db-compressed-ppds|foomatic-db" in the dependencies
<tkamppeter> mvo, the problem is the following:
<mvo> tkamppeter: I wrote a request for removal for printconf
<tkamppeter> foomatic-db and foomatic-db-gutenprint contain XML files in /usr/share/foomatic. This consumes a lot of space and it is slow to generate PPDs from the XMLs.
<tkamppeter> CUPS never reads these XMLs and by default we use system-config-printer which talks only with CUPS via IPP.
<tkamppeter> CUPS uses ready-made PPDs in /usr/share/ppd and PPD generators in /user/lib/cups/driver and /usr/share/cups/drv/.
<OdyX> tkamppeter: Chris did an update to printconf /which is foomatic-gui/ in 2010 though.
<tkamppeter> Foomatic XMLs are accessible to CUPS via /usr/lib/cups/driver/foomatic, but see the disadvantages I mentioned above. Therefore I migrated the Foomatic XML data to the smaller and faster compressed PPD archives, which are also CUPS PPD generators. This makes obtaining the PPDs much faster. Doing this step I was assuming that the printer setup tools currently in use support this by polling the available PPDs from CUPS.
<tkamppeter> mvo, OdyX ^^
<mvo> OdyX: oh ? hm, so its worth keeping it?
<tkamppeter> mvo, OdyX, foomatic-gui also does not start without foomatic-db installed but it has no package dependency on foomatic-db. I will check whether it also works without foomatic-db by removing the foomatic-db check from it.
<OdyX> mvo: for Debian, I don't figure myself asking for removal of a package maintained and developped by a DD: it's his call.
<tkamppeter> OdyX, you could report a Debian bug suggesting the removal.
<OdyX> you could too :p
<mvo> tkamppeter: I have not much knowledge about those packages, I leave it to you to decide if they shoudl stay or go, but I can add quirks code to ensure that the get removed on upgrade to not block the 10.10 upgrade from 10.04
<mvo> tkamppeter: what about foomatic-db-gutenprint, can that grow a "foomatic-db-compressed-ppds|foomatic-db" dpeendency?
<tkamppeter> mvo, OdyX, foomatic-gui is better but still unusable. It finds the local printers with the URIs of current CUPS, but for network printers it falls into an infinite loop (-> bug) and for the PPD choice it only offers PPDs to be generated from the currently installed XML files, no ready-made PPDs and no PPD generators (it does not ask CUPS for available drivers/PPDs).
<tkamppeter> mvo, so I ask you to make the update from Lucid to Maverick uninstall printconf and foomatic-gui and install system-config-printer if it is missing.
<tkamppeter> foomatic-db-gutenprint needs foomatic-db, as it is an add-on to foomatic-db. Users of foomatic-db-compressed-ppds who want to use ijsgutenprint have to install ijsgutenprint-ppds instead of foomatic-db-gutenprint.
<tkamppeter> mvo, for Ubuntu I recommend removing the foomatic-gui source package altogether, as in current Ubuntu it is totally unusable.
<OdyX> tkamppeter: could you send an argumented bugreport to the Debian foomatic-gui package with high severity ? That'd be great to track that issue.
<tkamppeter> OdyX, OK.
<OdyX> nice. Thanks.
<tkamppeter> mvo, which other packages require foomatic-db? ebox-printer and which was the other?
<siretart> doko: hi
<mvo> tkamppeter: those theree, ebox-print, printconf and foomatic-db-gutenprint
<tkamppeter> mvo, bug 647460 updated.
<ubottu> Launchpad bug 647460 in update-manager (Ubuntu) "10.04 -> 10.10: printconf is blocking the upgrade" [High,Triaged] https://launchpad.net/bugs/647460
<tkamppeter> foomatic-db-gutenprint really needs foomatic-db as I told, but we have ijsgutenprint-ppds to replace it.
<tkamppeter> mvo ^^
<tkamppeter> mvo, ebox-print I do not know what it is good for and who is supposed to use it. I will have a look into it.
<tkamppeter> mvo, I cannot find ebox-print or ebox-printer. What is the exact package name?
<mvo> tkamppeter: its ebox-printers
<tkamppeter> mvo, found it, it is ebox-printers, but I could not test it due to dependency problems. The system refuses to install all this ebox stuff.
<mvo> tkamppeter: thanks, if you can figure out more let me know, in the meantime I add the handling to update-manager
<tkamppeter> mvo, OK.
<doko_> siretart: how to make ffmpeg more verbose?
<ricotz> mvo, i hope you are updating gnome-keyring to 2.32 to solve the annoying ssh-key-unlock bug which is fixed since 2.31.92 https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/631980
<ubottu> Launchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed]
<mvo> ricotz: that is probably more something for didrocks or seb128
<ricotz> mvo, ok, i just saw your upload
<didrocks> ricotz: no we won't
<didrocks> ricotz: it's quite late and we got some issues with it
<mvo> ricotz: yeah, it was just a drive-by-upload :)
<tkamppeter> mvo the ebox stuff is a server infrastructure, probably generally not working on desktop systems. ebox-printers is written in Perl and directly using the Perl module of foomatic-db-engine. I do not know whether it asks also CUPS for PPDs or whether it requires the Foomatic XML database. Basing printer support exclusively on Foomatic is a bug in nowaday's life.
<mvo> ricotz: the real exports are didrocks and seb
<ricotz> didrocks, could you aleast add this http://git.gnome.org/browse/gnome-keyring/commit/?id=d9ef94455d115d8fed29a3071b5b19ca632fb932
<didrocks> ricotz: yeah, this commit seems safe :)
<ricotz> didrocks, this is the commit which is supposed to have fixed it
<seb128> ricotz, do you have an upstream or launchpad bug for it?
<didrocks> ricotz: the gsettings transition was quite late in the process, hence the fact we don't update
<ricotz> https://bugzilla.gnome.org/show_bug.cgi?id=627815#c1
<ubottu> Gnome bug 627815 in general "gnome-keyring ssh agent doesn't unlock ssh keys anymore" [Normal,Resolved: fixed]
<seb128> didrocks, I can do it
<didrocks> seb128: thanks :)
<ricotz> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/631980
<seb128> didrocks, you have quite some items on your todo already
<ubottu> Launchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed]
<seb128> ricotz, ok
<didrocks> seb128: yeah, I keep seeing items appending :p
<ricotz> seb128, thanks
<seb128> ricotz, you're welcome
<mvo> is there someone with a dell mini9 who can tell me if sata is set to "compat" or "ahci" mode by default?
<tkamppeter> mvo, bug 647460 updated.
<ubottu> Launchpad bug 647460 in update-manager (Ubuntu) "foomatic-gui: Request for removal" [High,Triaged] https://launchpad.net/bugs/647460
<mvo> thanks tkamppeter
<siretart> in case doku pings me again. the answer is 'make V=1'
 * samiz is away: Away
<tkamppeter> mvo, I have reported Debian bug 598639 now.
<ubottu> Debian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/598639
<achiang> hm, i thought [[ expression ]] was legal posix shell
<achiang> but i'm getting [[: not found when using #!/bin/sh
<tkamppeter> OdyX, see Debian bug 598639.
<ubottu> Debian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/598639
<james_w> jibel: new package in my PPA if you could test it (I still can't reproduce)
<james_w> hopefully this one fixes it
<mvo> thanks tkamppeter, I just uploaded the new update-manager with the workaround as well
<jibel> james_w, I'm testing the new package
<james_w> thanks
<tkamppeter> mvo, does your workaround on update-manager also solve the foomatic-db-gutenprint problem, by replacing foomatic-db-gutenprint with ijfgutenprint-ppds?
<jibel> james_w, \o/ I've tried many different ways to reproduce the bug and failed. That seems to be fixed!
<jibel> james_w, any idea how I could test potential regressions ?
<james_w> jibel: not really beyond using it
<james_w> I'm not sure if we should try and get this in to final
<jibel> james_w, I would be better to do an SRU just after the release
<james_w> yeah
<jibel> james_w, I'm the only tester and only 20 minutes that's not enough to guarantee against the risk of regression.
<james_w> yeah, I meant more whether we should scramble for more testing now, or take the time and do an SRU
<james_w> I'm fine with the latter, it's just that if it affects a lot of people then it will be a stain on the software-center experience
<jibel> james_w, have you seen lot users complaining about this bug ? You should raise it to the release team.
<james_w> a fair number, but not hundreds
<james_w> plus it's always been in lucid
<mvo> tkamppeter: thanks, I can add that too, its not there yet foomatic-db-gutenprint->ijfgutenprint-ppds?
<tkamppeter> mvo, yes, that's it.
<mvo> tkamppeter: I made a note and will add it tomorow
<tkamppeter> mvo, only for ebox-printers I do not know what is best. The ebox series of packages seems to be a server environment, so it is not very probable that someone installs it together with ubuntu-desktop. And ubuntu-desktop initiates the migration from foomatic-db to foomatic-db-compressed-ppds.
<kaizoku> Hi, I'm looking to enable ttys on a installation livecd. Anyone know how I can go about this?
<SpamapS> can somebody explain to me how openssh-server can both Replace and Depend on openssh-client ?
<ajmitch> SpamapS: versioned Replaces & Depends
<ajmitch> the Replaces: version is << something quite old
<soren> ajmitch: Yeah, 1:3.8.1p1-11 is timestamped October 2004 :)
<soren> Even Debian has had a few releases out since then :)
<ajmitch> soren: right, I was only checking launchpad, and even dapper had 4.2p1 :)
<soren> ajmitch: warty was 1:3.8.1p1-11ubuntu3.
<ajmitch> so this goes back to the pre-history of ubuntu :)
<SpamapS> oh the apt-cache command didn't show the versions
<SpamapS> show does though
<soren> ajmitch: But sure, if someone has a woody box they want to upgrade directly to maverick..
 * soren coughs
<soren> Ah, no, even sarge, actually.
<soren> But still, that's hardly relevant.
<ajmitch> then they should be hung, drawn & quartered?
<ajmitch> even a minimal chroot would hardly be able to upgrade
<soren> They at the very least deserve the pain of the sshd_config man page moving to openssh-server and dpkg shouting about it.
 * soren is happy he's very tired, otherwise he'd be attempting such an upgrade, just for giggles.
#ubuntu-devel 2010-10-01
<SpamapS> I have an old hard drive in storage that is running woody
<SpamapS> Shut down my old home server and never turned it back on..
<nh2> hi, I'd like to develop new features for rosetta (launchpad translations), but there are quite a lot of branches. Which one should I use as a base?
<ajmitch> nh2: you'll want to talk to people in #launchpad-dev about that
<nh2> ajmitch: thanks
<achiang> hm, is there something else i need to do while testing X clients inside a chroot? i've exported my DISPLAY=localhost:0.0, and issued an xhost + in the host as well
 * achiang decides to re-ask in #ubuntu-x
<dholbach> good morning
<kirkland> slangasek: what were those two packages?  for windows compilation?
<kirkland> slangasek: mingw32 and nsis or something?
<kirkland> slangasek: found them ...
<pitti> Good morning
<dholbach> hi pitti
<pitti> hey dholbach, how are you?
<dholbach> pitti, great - and you?
<pitti> pretty well, thanks
<pitti> Riddell: can you please review my apport, kerneloops, and cups uploads?
<pitti> I'll take a look at the others
<pitti> james_w: heh, seems we both uploaded a kerneloops for disabling for final
<Riddell> pitti: ok
<yao_ziyuan> when you release an alpha or beta, you're supposed to build apps with more debugging information, and therefore they would run slower than a final release, right?
<pitti> yao_ziyuan: no, optimization/compiler settings don't change between alphas and release
<pitti> yao_ziyuan: we strip off debugging information and publish them as separate pacakges on http://ddebs.ubuntu.com
<yao_ziyuan> pitti: and this is since when?
<pitti> yao_ziyuan: compiler switches -> always; ddebs> since 7.04 I believe
<yao_ziyuan> thanks
<YokoZar> cjwatson: new icoutils is now in the archive, if you want to utnubu that back to Debian that'd be fantastic
<YokoZar> yao_ziyuan: individual packages can still tweak them though
<tkamppeter_> mvo, hi
<mvo> hey tkamppeter_
<tkamppeter> mvo, in your update-manager fix for bug 647460, when you remove foomatic-db-gutenprint, do you replace it with ijsgutenprint-ppds?
<ubottu> Launchpad bug 647460 in update-manager (Ubuntu) "10.04 -> 10.10: printconf/ebox-printers/foomatic-db-gutenprint block the upgrade" [High,Fix released] https://launchpad.net/bugs/647460
<mvo> tkamppeter: not yet, I prepare a update for this
<tkamppeter> mvo, OK.
 * samiz is away: Away
<persia> !away > samiz
<ubottu> samiz, please see my private message
<persia> Hobbsee, Your ideas are stronger than launchpad: ~ubuntu-universe-sponsors refuses to be deleted :)
<Hobbsee> persia: hah
<Hobbsee> take that, launchpad!
<cjwatson> achiang: [[ isn't POSIX sh, no.  See https://wiki.ubuntu.com/DashAsBinSh which lists it.
<cjwatson> YokoZar: thanks, will look after the maverick release
<apw> cjwatson, have we done anything in our CD images to support EFI for maverick ?
<Riddell> pitti: did you do two kerneloops uploads?  I accepted one but I don't know if it's the same one I looked at
<pitti> Riddell: the other is from james_w; we can reject one
<cjwatson> apw: yes, supported on amd64 only
<cjwatson> apw: (sadly can't really test it on my test machine since am awaiting fixed firmware)
<apw> cjwatson, there are reports that this is breaking mac's on boot (amd64 only, which now makes sense).  presumably this is something to do with how the CD ismade
<apw> bug #633983
<ubottu> Launchpad bug 633983 in linux (Ubuntu Maverick) "Can't boot Maverick beta amd64 live cd on macbook (EFI)" [High,Confirmed] https://launchpad.net/bugs/633983
<apw> so i presume this isn't going to be a kernel issue ?
<cjwatson> apw: it's hard to say
<cjwatson> apw: but, you know, there are reasons I left the i386 CD BIOS-only ...
<cjwatson> apw: the only way to prove that it's specifically due to EFI support would be to remaster the CD without that
<cjwatson> and there's very little we can do about this without removing EFI support, it's a catch-22
<apw> cjwatson, and indeed they indicate the 32bit one does boot ok
<cjwatson> but that's not really proof
<cjwatson> would need to remaster the amd64 CD
<apw> no indeed not anything more than indicative a test is appropriate
<apw> is that someting one can do anywhere other than on the cdmaster machine?
<cjwatson> sure.  loop-mount image on PATH.  genisoimage -r -V 'Ubuntu 10.10 amd64' -o maverick-desktop-amd64-remastered.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table PATH
<cjwatson> actually you might need to loop-mount and then copy the whole thing
<cjwatson> so: mount -o loop maverick-desktop-amd64.iso old-amd64; cp -a old-amd64 new-amd64; genisoimage -r -V 'Ubuntu 10.10 amd64' -o maverick-desktop-amd64-remastered.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
<apw> cjwatson, ok so that sounds like something i can try and do ... people are targetting the kernel on this one and blaming me :/
<apw> thanks
<cjwatson> we could release-note "you have to use i386 on Macs"
<cjwatson> not exactly ideal but ... dear Apple, please fix your EFI implementation
<apw> cjwatson, well indeed, from the pointeres in the bug it seems even M$ cannot make ISOs which boot correctly on them
<apw> cjwatson, so i suspect its going to be that in the end, i wonder if we could have ports cds
<cjwatson> the eternal disk space pain
<cjwatson> it's possible
<cjwatson> probably, just about
<bobba> Hi - I'm wondering where I should go to ask how I'd customise the installer? In particular, I'd like to know how I could remove EXT4 as an option for installations as I only wish to support installations on EXT3
<cjwatson> 'rm /lib/partman/valid_filesystems/ext4' should be sufficient
<cjwatson> (I think)
<cjwatson> #ubuntu-installer is generally a better place to ask though
<bobba> and then it should default to a different FS? because EXT4 is the default at the moment
<bobba> ahhhh fantastic :)
<cjwatson> er, yeah, you would need to change the default that's true
<cjwatson> are you happy to rebuild packages to achieve this (more work, but more flexible), or do you want to just fiddle about with the live filesystem?
<bobba> *nod* Well that's getting part way there which is further than I've got by myself ;)
<cjwatson> the default filesystem is in debconf, as the default for the partman/default_filesystem question
<bobba> Ideally I'd prefer to fiddle with the live system (of course...) but since I'll be building a fresh ISO then I'm happy to consider anything that's needed
<cjwatson> well in that case you can edit /var/cache/debconf/config.dat and look for partman/default_filesystem
<cjwatson> alternatively, add partman/default_filesystem=ext3 to the boot options
<bobba> ahhh that sounds good - but I'd still have to change the life system to remove it from the valid list
<bobba> fantastic though - I'm going to try that right away
<cjwatson> right
 * samiz is away: Away
<nigelb> !away | samiz
<ubottu> samiz: You should avoid noisy away messages and -nicks in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
<Daviey> cjwatson: Can I ask you review a debdiff for bug #651027, please?  I just want to make sure i understood your suggestion.
<ubottu> Launchpad bug 651027 in dovecot (Ubuntu Maverick) "dovecot-postfix claimed as built in debian/control but not actually built" [High,New] https://launchpad.net/bugs/651027
<Daviey> cjwatson: http://pb.daviey.com/vZXO/raw/
<didrocks> hey, is there a release team member having some time to look at sync request in bug #651266 ? current plugin is broken as the feed change. I can do a fakesync if required
<ubottu> Launchpad bug 651266 in totem-plugin-arte (Ubuntu) "Sync totem-plugin-arte 0.9.2-1 (universe) from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/651266
<pitti> didrocks: looking
<bobba> cjwatson, I've found the 05ext4 file to delete, but I was trying to change config.dat for the partman/default_filesystem setting to set it to ext3 - however, the config.dat doesn't seem to have the setting in? It just says "Name: partman/default_filesystem" "Template: partman/default_filesystem" "Owners: ubiquity".  I'm therefore clearly missing something :)
<didrocks> thanks pitti ;)
<OdyX> Hrm . How is it that pyside is in "pending publication" state for 3 days ?
<bobba> cjwatson, sorry - I've figured it out!
<bobba> thanks
<pitti> didrocks: done; off to lunch now
<didrocks> pitti: thanks a lot! enjoy your lunch :)
<cjwatson> bobba: maybe templates.dat, I forget exactly
<bobba> it is templates.dat - sorry for asking before actually looking deeply enough
<cjwatson> Daviey: looks like what I meant, except that you removed "ChangeLog" from the dh_installchangelogs line which I don't think was intentional?
<cjwatson> Daviey: I would have provided a diff but I hadn't test-built it and debdiffed the binaries to make sure they were coming out right
<cjwatson> OdyX: because it's in the NEW queue
<Daviey> cjwatson: Yeah, that wasn't intentional... My next step was to build and see - but i just wanted to make sure that is what you were thinking before i moved on.
<OdyX> cjwatson: oh. "just wait" is the remedy to that, right ? :)
<cjwatson> OdyX: correct
<Daviey> cjwatson: Unless, you want to carry on with it?
<cjwatson> Daviey: no, please go ahead
<Daviey> ok, great.
<ogra> i'm looking for an archive admin to review powervr-omap3, opengles-sgx-omap3 and devmem2
<Daviey> cjwatson: For info - certainly looks like that debdiff (with ChangeLog added) fixed the issue - http://pb.daviey.com/1uDq/raw/
 * Daviey hmmmmmmm's
<cjwatson> Daviey: looks good, just check that the new dovecot-postfix's contents look sane and that none of the other packages have changed contents unexpectedly
<Daviey> cjwatson: Yes, fair comment.
<Daviey> cjwatson: Well there is another issue i'm fixing now with the depends of the transitional package.
<ogra> doko_, the java buildd is ready for you, got instructions for lamont ?
<doko_> Ng: is working on it
<ogra> oh, ok
<lamont> the instructions had better consist of "schedule the build on that box"
<Chipzz> java buildd? ^^
<cjwatson> Chipzz: bug 642344
<ubottu> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) "libspring-2.5-java needs an initial manual build" [High,Confirmed] https://launchpad.net/bugs/642344
<lamont> Chipzz: newer hardware than what we have had
<lamont> cjwatson: no
<lamont> openjdk-6
<lamont> at least I think so
<ogra> right, bug 605042
<ubottu> Launchpad bug 605042 in eglibc (Ubuntu Maverick) "[armel] java fails to start with eglibc-2.12-0ubuntu4" [High,Triaged] https://launchpad.net/bugs/605042
<Chipzz> lamont: when I saw java buildd, I was thinking along the same lines as "i386 buildd"
<lamont> Chipzz: well, java is totally like its own architecture. that much is true
<cjwatson> oh ok
<Chipzz> lamont: well, yeah... when is ubuntu on java scheduled to be released? ;)
<lamont> cjwatson: libspring was last seen waiting for RC to happen
<lamont> Chipzz: hopefully not before I'm dead
<cjwatson> lamont: RC has happened :-)
<Chipzz> *grin*
<Chipzz> lamont: my initial reaction to myself was: who has been smoking what kind of crack, and more importantly, where can I get some of that? ;)
<lamont> cjwatson: yeah - I'm out of the loop on the ticket today
<lamont> s/the/that/
<apw> cjwatson, fyi i've built tested (it boots) and posted that remastered CD image for testing on the bug ...
<cjwatson> ta
<cjwatson> be sure to make it clear that this is not a fix we can simply roll into the distribution (because it breaks other things) but simply an attempt to narrow things down
<apw> cjwatson, added a rider to it ... that is why i wondered if we might be wanting 'ports' style cd-image.  ones which arn't mirrored etc for the smaller corner cases like this
<cjwatson> as I say, yes it's possible if there's no alternative
<apw> probabally something that needs discussing in a more formal setting, to see what alternatives we have
<cjwatson> we had an i386+mac port in the past for other reasons; the same kind of thing could be resurrected as amd64+mac
<cjwatson> it's not even all that difficult
<apw> apple sort out your firmware being the prefered option
<cjwatson> quite, but Fedora have had the same problem for a while and obviously neither they nor MS have got anywhere
<cjwatson> I shouldn't think "fails to boot non-Apple OS" is very high on Apple's priority list
<apw> i would think "make sure it fails to boot non-apple OS" is high on their priority list
<cjwatson> ultimately ... your hardware is hostile to other OSes, should have bought different hardware
<apw> yep ... sadly
<cjwatson> we can certainly try workarounds as long as they don't break other things
<apw> not 'damn i can sell this sh*t to people who'll pay for an OS and not use it, sweet'
<apw> cjwatson, anyway thanks for your help, i learned more than i wanted to about mastering CDs
<apw> though one day when we arn't busy [sic] it might be nice to have the fulll incantations for the EFI ones too
<cjwatson> same as before but add '-eltorito-alt-boot -efi-boot boot/grub/efi.img -no-emul-boot' before the path at the end
<cjwatson> (ordering matters)
<apw> yeeks thats an incation and 3/4
<Riddell> mvo: any more uploads of update-manager planned?  I just made a small change
<mvo> Riddell: yes, one for ebox-printers
<ScottK> mvo: I noticed in http://www.mythbuntu.org/10.10/rc that they are telling people to remove the mythstream package.  Since it's not in the archive anymore, if they upgrade using u-m, then that's done automatically, right?
<mvo> ScottK: yes, it will be suggested for removal at the end, if it causes problems during the upgrade I can make it go away earalier too
<ScottK> mvo: I guess we should ask superm1 if it needs that.
<ScottK> (hopefully he's an early riser and we'll know soon).
<mvo> superm1: I can make mythstream go away earlier in the upgrade if it has the potential to cause trouble
<mvo> ScottK: yeah, there is one other issues releated to gutenprint that I need to fix today too
<Goodi> Hi! Would anyone know when/if the sun-java6-* packages will be available for Maverick?
<diwic> Goodi, yeah, I've also been looking for them
<Goodi> diwic-  I grabbed the lucid java, but that's not a real solution... There seems to very little info about it.
<Goodi> I hope they keep it somewhere (partner repo is not optimal, but definetly better than nothing) so we don't need to start rebuilding it
<ScottK> Goodi and diwic: It will be available in Partner
<Goodi> great :)
<Goodi> scottk - any deadlines/schedules (ie quesses) when it will appear there?
<diwic> ScottK, good, do you know when?
<Goodi> in stereo... where available :)
<ScottK> No, you'd have to ask a Canonical person for details.  Partner is controlled by them and not part of Ubuntu development.
<Goodi> ok. Hopefully they'll get it out before the 10.10 release :)
<diwic> pitti, do you know who I should give a gentle push to make him/her put sun-java-* into the partner archive?
<cjwatson> it's in NEW, I'll process it today
<cjwatson> no need to push
<diwic> \o/
<diwic> finally
<pitti> ah, ok; I thought archive admins aren't supposed to touch partner packages
<diwic> pitti, who is supposed to touch partner packages? :-)
 * cjwatson has no compunctions about doing so
<cjwatson> anyway, nobody else other than archive admins can process partner packages through NEW :-P
<pitti> diwic: I'm not sure, I think the other day there was some discussion between iamfuzz, bdmurray, and the archive admins that there needs to be some QA step before the AAs should accept it
<cjwatson> it's gone through source NEW already ...
<pitti> diwic: sorry, since I'm not an active archive admin, I'd rather trust cjwatson here
<diwic> ok :-)
 * diwic thought pitti was all-knowing :-)
 * pitti ponders for a snappy answer about that being a contradiction to itself
<pitti> "I don't know a puzzle which is so hard that I can't solve it" or something like that
<diwic> pitti, then you can't be all-knowing, because then you would have known the snappy answer! Hah! :-)
<pitti> diwic: q. e. d.
<diwic> all right, let's get back to work
<mvo> could someone eyeball http://paste.ubuntu.com/503887/ please?
<pitti> mvo: I think you should also export LC_MESSAGES and LC_ALL
<pitti> oh, and $LANGUAGES
<seb128> pitti, LANGUAGE?
<pitti> mvo: right, sorry; $LANGUAGE
<pitti>        export LANG LANGUAGE LC_MESSAGES LC_ALL
 * pitti sees this snippet being replicated all over the system
<cjwatson> I'm surprised that /etc/pam.d/cron doesn't handle this
<cjwatson> session       required   pam_env.so envfile=/etc/default/locale
<cjwatson> perhaps only user cron jobs have a PAM session?
<cjwatson> (if so, crontab(5) doesn't say that)
<mvo> cjwatson: I was suprised as well TBH, but I did test and LANG was not set without that
<mvo> pitti: thanks!
<doko_> fluidsynth is another "nice" sync from experimental :-/
<diwic> doko_, hmm?
<doko_> diwic: look at the recent build failures of seq24, muse, fluidsynth, zynaddsubfx, xjadeo, lashwrap, ... on armel and powerpc
<diwic> doko_, seems like you have a new one in queue?
<doko_> diwic: are you involved with these multimedia updates?
<pitti> Riddell: can we have daily CD builds again, to test the new langpacks, oversizedness, etc?
<diwic> doko_, I've been developing fluidsynth for a year or two
<diwic> doko_, and we don't have anybody upstream (or in Debian, IIRC) which tests armel
<diwic> so armel is not supported by upstream (i e the FluidSynth community)
<diwic> as for packaging of it, quadrispro did most of it but I helped some
<doko_> diwic: maybe, but is this a reason to upload packages two weeks before the release which already fail to build in experimental, or show up as build failures in maverick? had this discussion yesterday with quadrispro ...
<doko_> diwic: are the feature freeze exceptions for lash and fluidsync documented?
<diwic> doko_, depends on which standpoint you have. Knowing what we did to improve stability (for supported platforms) in 1.1.2, I support having 1.1.2 in Maverick,
<diwic> doko_, I don't know if quadrispro made any formal FFe:s.
<doko_> diwic: fluidsync did build before, now it's not. see https://launchpad.net/ubuntu/+source/fluidsynth/1.1.2-2/+build/1982399
<diwic> doko_, I'll see what I can do about it
<doko_> diwic: one problem seems to be a missing b-d on libxml2-dev according to the build log
<doko_> diwic: liblash-dev doesn't depend on libxml2-dev. don't know if devlibs:Depends is supposed to have this dependency. fixing it now directly
<diwic> doko_, I was just about to come to the same conclusion, but I don't know much about those ${devlibs:Depends} variables to know if it should be listed there or not
<pitti> cjwatson, dpm, Riddell: new langpacks built, they look fine to me; ready for the flood?
<dholbach> pitti, dpm is travelling
<cjwatson> it's ok by me
<pitti> I'll accept them as they flow in
<ogra_ac> gah, i'm screwed
 * ogra_ac just noticed that tar xzvf arm-rootfs.tgz /mnt/> is not such a good idea 
<pitti> ogra_ac: ? wouldn't that just try to extract "/mnt" from arm-rootfs.tgz?
<ogra_ac> no, it in fact extracted the tgz to /
<pitti> "oops"
<amitk> ogra_ac: main devbox? ;)
<pitti> weird that the "/mnt" parameter does that
<rsalveti> ogra_ac: ouch
<ogra_ac> hmpf
<apw> anyone know if it is possible to tell apt-get to not check for or worry about disk space ?
<cjwatson> apw: doesn't appear to be, from a glance at the code.  LD_PRELOAD statvfs? ;-)
<apw> cjwatson, damn ... t
<apw> thanks :)
<ogra_ac> oh, i thought i'm screwed by killing my system disk and only being left with armel HW (and no cdrom) running ....
<ogra_ac> but i'm screwed even more
<ogra_ac> The following packages have unmet dependencies:
<ogra_ac>  usb-creator-common : Depends: syslinux but it is not installable
<ogra_ac> E: Broken packages
<ogra_ac> gah
<apw> ogra_ac, do i want to ask how you killed your system disk?
<ogra_ac> i said how ... above
<ogra_ac> i typoed a tar command
<ogra_ac> tar xzvf arm-rootfs.tgz /mnt/>
<ogra_ac> note the last char
 * apw is supprised that is not an error in the shell
<apw> ogra_ac, oh hmmm do you have network ?
<ogra_ac> the tar ended with an error after extractinbg the whole think if that makes you happy :P
<cjwatson> error in the shell> so am I.  perhaps you wewren't using bash
<apw> http://kernel.ubuntu.com/~kernel-ppa/testing/
<ogra_ac> i do have network
<cjwatson> busybox sh doesn't like it either
<ogra_ac> i surely was just using a gnome-terminal
<cjwatson> -bash: syntax error near unexpected token `newline'
<cjwatson> dash: Syntax error: newline unexpected
<apw> http://kernel.ubuntu.com/~kernel-ppa/testing/ <-- there are .img files there which are bootable images which are DD able onto a stick
<cjwatson> sh: syntax error: unexpected newline
<ogra_ac> strange
<cjwatson> all the shells I've tried fail
<apw> not sure if they have any interactive mode thought, but i suspect you can init=/bin/bash them
<ogra_ac> probably there was a special char behind it, thats all i got from shell history
<xax200> Excuse me, what information should I know if I want to help implement client side decoration support in a window manager?
<ogra_ac> apw, well, someone said i should be able to just dd the iso to usb key nowadays
<sivang> hi all
<ogra_ac> and given the download is done in 2min i'll know for sure by then
<sivang> Is KDar not in the repositories anymore?
<apw> usb-creator does do something using stuff on your system, whether its needed ... i don't know
<ogra_ac> yes, i know
<sivang> AFAIR it was in universe.
<ogra_ac> but there was a mail thread recently about the possibility to dd
 * sivang asks in -motu
<apw> ogra_ac, well if it fails i know the .img files have been made such that they are bootable after a dd, some magic using a VM i am told to make them
<ogra_ac> ok
<ogra_ac> i'll fall back to them, thanks
<apw> but they are special case images, so probabally need to hack them
<ogra_ac> apw, so dd didnt work (indeed) ...
<apw> pup
<xax200> I don't usually find that dd'ing iso images to usb works
<ogra_ac> well, the new syslinux is supposed to make that work
<ogra_ac> but i guess my BIOS cant read iso9660 from usb
<ogra_ac> or something like that
<cjwatson> ogra_ac: bug
<cjwatson> er
<cjwatson> bug 524803
<ubottu> Launchpad bug 524803 in Ubuntu CD Images "isolinux hybrid mode should be used - all other major distributions do so since last year" [Undecided,New] https://launchpad.net/bugs/524803
<ogra_ac> ah, right
<ogra_ac> i even know that one
 * ogra_ac is totally off track after that disaster 
<ogra_ac> erm
<ogra_ac> why dont i use a netboot image
<ogra_ac> heh
 * ogra_ac hugs d-i
<jibel> mvo, cjwatson, I reported bug 651325 against gnome-keyring during a wubi upgrade, the gnome-keyring is fixed but the unbootable problem still remains and can be reproduce.
<ubottu> Launchpad bug 651325 in update-manager (Ubuntu) "package gnome-keyring 2.92.92.is.2.30.3-0ubuntu1.1 failed to install/upgrade: /var/lib/dpkg/tmp.ci/preinst: 31: dpkg-maintscript-helper: not found" [Undecided,New] https://launchpad.net/bugs/651325
<jibel> I'll file a new report.
<cjwatson> was your wubi install on a drive other than C:?
<jibel> cjwatson, no
<cjwatson> dunno then, my wubi upgrade recently worked fine
<jibel> A few lines are displayed very quickly when I select the Ubuntu entry at the ntloader boot menu then there is a soft reset.
<cjwatson> video them if you can
<jibel> cjwatson, that's what I'm currently doing
<cjwatson> did you 'dpkg --configure -a; apt-get -f install' etc. to get all the packages back into a sane state?
<cjwatson> not that it *should* be needed but ...
<jibel> fresh 10.04.1, update/upgrade, restart, update-manager -d, restart
<cjwatson> jibel: well, I can give it a try here
<cjwatson> jibel: nothing special beyond that?
<jibel> cjwatson, error: unknown command 'loadfont'
<jibel> error: file not found. (5 times)
<jibel> error: unknown terminal 'gfxterm'
<jibel> error: file not found
<jibel> then the system restarts
<jibel> that's all
<cjwatson> hm, those are a bit crap but shouldn't really be fatal
<jibel> cjwatson, a fresh install of 10.10 on the exact same system is working correctly.
<cjwatson> I wonder what changed since my successful test
<cjwatson> admittedly I didn't use update-manager because I wanted to force my local mirror, but that shouldn't have mattered
<jibel> cjwatson, I can get the upgrade logs and see if I find something interesting.
<cjwatson> well, I can just rerun here and see what happens
<cjwatson> always optimal if a developer can reproduce locally
<shtylman> sladen: I have already signed the agreement per my work with ubiquity
<shtylman> that may ease some things
<pitti> Riddell: since we now get new langpacks with empty update packs, ok if I add back some langpacks to the seeds?
<Riddell> pitti: yes please
<sladen> shtylman: do you now consider the Kubuntu logo  Author: Existing + Roman Shtylman   Copyright Holder: Canonical Ltd  ?
<pitti> Riddell: I'll watch the dailies then; (are they re-enabled?)
<shtylman> sladen: if that is what is needed then sure :)
<shtylman> sladen: like I mentioned... I don't need to maintain copyright and it would make sense for canonical to have the copyright anyhow imho
<sladen> shtylman: sooo, "yes" ?
<shtylman> sladen: yes
<jibel> cjwatson, I can't even mount the disk image, the file system is not recognized :/
<cjwatson> uh
<cjwatson> that's fairly spectacular failure
<cjwatson> you didn't run out of disk space or something?
<cjwatson> does Windows still boot?
<Riddell> pitti: yes I re-enabled them about midday today
<superm1> mvo, it won't cause problems earlier in the upgrade, it just will cause mythtv-frontend to not execute properly later on
<superm1> mvo, so as long as it's removed later when update-manager recommends it to be gone, people should be fine
<jibel> cjwatson, bug 653134
<ubottu> Launchpad bug 653134 in Wubi "Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10" [Undecided,New] https://launchpad.net/bugs/653134
<jibel> cjwatson, windows still boot
<Lahtex> DEATH TO BAZHANG .. FUCKED UP MORON!
<Lahtex> Freenode ....
<jibel> cjwatson, and there's 43GB free (and I didn't ask wubi to create a root disk larger than than 43GB)
<Lahtex> cjohnston: Do something or never come back....
<Seeker`> !ops | Lahtex
<ubottu> Lahtex: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<cjwatson> jibel: ok, I'll see what it does for me
<jibel> cjwatson, thank you
<shtylman> hahaha
<ogra_ac> cjwatson, any idea why the dd that zeroes the swap in user-setup-apply uses a blocksize of 16M ?
 * ogra_ac wonders if thats mandatory
<ScottK> mvo: Apparently extras.ubuntu.com is added to sources.list of servers too, but the keyring isn't seeded there, so one gets errors when updating.
<cjwatson> ogra_ac: I don't know, but I'm guessing it's for speed
<cjwatson> ScottK: ouch!  It's not meant to be
<cjwatson> mvo: do you remember whether we decided to have apt-setup/extras default to false and be preseeded on for desktops, or default to true and be preseeded off for servers?
<cjwatson> mvo: I think the former might make more sense since it should only be included when ubuntu-extras-keyring is
* You're now known as ubuntulog
<ScottK> cjwatson: I suppose I should file a bug report too.  What should I file it against?
<cjwatson> ScottK: apt-setup (Ubuntu), and the ubuntu-cdimage project
<ScottK> OK.
<ScottK> cjwatson: Bug #653200
<ubottu> Launchpad bug 653200 in apt-setup (Ubuntu Maverick) "extras.ubuntu.com added to server installs" [High,New] https://launchpad.net/bugs/653200
<cjwatson> ta
<sladen> shtylman: thanks, updated, process and forwarded!
<mvo> cjwatson: I think the initial idea was exclude on server, but in the light of the seeding it makes more sense to set it to true on desktop only and default to false. will that be a problem for derivatives? or do they just inheritc from the generic "desktop"
<ogra_ac> jdstrand, around ? i'm looking for an archive admin
<paissad_> guys, i received this lintian warning 'missing-debian-source-format' ....  i don't know anything about quilt, i don't use it in my package ...i did not use it in the previous versions of my package & here is what i did --> echo '3.0 (native)' > debian/source/format ... do you think this good ?
<paissad_> thanks in advance for helping
<cyphermox> geser, I noticed you did a rebuild of gtkmathview because of libgdk_pixbuf2.0.la, could you review https://code.edge.launchpad.net/~mathieu-tl/ubuntu/maverick/aiksaurus/lp653217-rebuild or do the same rebuild for aiksaurus?
<paissad_> btw, i have this other warning:
<paissad_> W: pms-linux: executable-not-elf-or-script ./usr/share/pms-linux/resources/images/clients/musicpal.png
<paissad_> i did in my debian/rules --> dh_fixperms /usr/share/pms-linux/resources/images/
<paissad_> but i don't understand the reason why nothing changed !
<cyphermox> paissad_, afaik, that's good for debian/source/format / missing-debian-source-format.
<paissad_> i even did dh_fixperms only, but that did not change anything
<paissad_> weird
<cyphermox> paissad_, as far as executable-not-elf-or-script, did you copy these files from a ntfs or fat partition? this just means that file is marked executable and should not be
<jdstrand> ogra_ac: sure, what do you need?
<ogra_ac> jdstrand, three packages from NEW
<ScottK> paissad_: The source format one is safe to ignore.
<paissad_> cyphermox, those files are retreive (svn export) from a subversion server .. my system is ext3 ....
<ogra_ac> jdstrand, powervr-omap3, opengles-sgx.omap3 (multiverse) and devmem2
<paissad_> ScottK, you mean 1.0 instead of 3.0 ?
<ScottK> paissad_: You can use whichever you prefer.  Nothing explicitly defined is 1.0, so if you want 1.0, it's not needed to add anything.
<jdstrand> ogra_ac: these all have FFes?
<ogra_ac> the bugs are mentioned in the changelog and ScottK looked over the FFes afaik
<jdstrand> ogra_ac: k. I'll take care of it
<ogra_ac> thanks !!!
<ScottK> jdstrand: I gave him the "If you can find an archive admin to New it" sort of FFe.
<ogra_ac> ubuntu ARM loves you :)
<jdstrand> hehe
<ogra_ac> (and asac too i guess)
<ogra_ac> linaro is eagerly waiting for that stuff ... more than us actually
<jdstrand> so linaro loves me too?
<jdstrand> turning into a rather nice day :)
<ogra_ac> jdstrand, yeah, the whole arm developer community will love you, these are the GL drivers for beagleboards, nobody ever shipped them in a painless way :)
<jdstrand> \o/
<jdstrand> sounds cool
<ogra_ac> and TI managed to release them in a redistributable way just in time to make maverick the last minute
<ogra_ac> yeah
<geser> cyphermox: will do
<cyphermox> geser, thanks!
<paissad_> debian-watch-file-in-native-package
<paissad_> what's a native package .. i don't really understand this ^^
<kklimonda> paissad_: native packages are packages that debian/ubuntu is an upstream for.
<paissad_> kklimonda, so created by debian ubuntu developers ?
<kklimonda> paissad_: if you are packaging an upstream project you have to append a debian revision to it's version.
<kklimonda> paissad_: yeah
<kklimonda> its*
<paissad_> kklimonda, i'm confused because, when i did not have the debian/source/format file, i had this warning
<paissad_> 'missing-debian-source-format
<paissad_> and now i created this file, i have this lintian warning
<paissad_> debian-watch-file-in-native-package
<paissad_> ^^
<paissad_> well, i will remove the watch file then
<paissad_> and this too -> native-package-with-dash-version
<paissad_> really complicated & confusing the 'debian rules for packaging' .. that changes too often
<kklimonda> what is the version of your package?
<kklimonda> you can also run lintian with --info for a long description of this errors/warnings
<paissad_> kklimonda, pms-linux-1.20.409+svn411
<paissad_> kklimonda, in the changelog , i have -> 1.20.409+svn411-1
<paissad_> kklimonda, i did lintian -iIEmv --color always --pedantic
<paissad_> so i have explanations
<kklimonda> paissad_: you should have 3.0 (quilt) in debian/source/format and an .orig.tar.gz in the parent directory.
<paissad_> kklimonda, actually, i did (native) instead of (quilt) ...
<paissad_> i will try quilt then
<jdstrand> ogra_ac: I'm not keen on this udev rule in opengles-sgx-omap3: KERNEL=="pvrsrvkm", GROUP="users", MODE="0666"
<ogra_ac> rsalveti, ^^^^
<ogra_ac> jdstrand, what would you like 0660 ?
<jdstrand> rsalveti, ogra_ac: is that required? wouldn't KERNEL=="pvrsrvkm", GROUP="video", MODE="0660" be better?
<ogra_ac> do we actually still have a video group ?
<jdstrand> ogra_ac: I would, yes, and a group that makes sense
<rsalveti> if the video group is still working, np to use it
<jdstrand> video:x:44:
<ogra_ac> i guess ricardo took rthat over from an upstream doc or from openembedded
<jdstrand> well, I am not up to date on the proper group
<jdstrand> users seemed weird
<rsalveti> I couldn't find a proper group to allow a normal user to use the 3d acceleration
<ogra_ac> but that means tinkering with groups
<rsalveti> didn't think that video would fit that
<ogra_ac> yeah, video is rather for video devices
<kirkland> slangasek: hey, upstart question for you ....
<jdstrand> hmm
<jdstrand> kees: ^
<jdstrand> we should probably look at what nvidia does
<kirkland> slangasek: so asking upstart for the "status" on a given process really just checks if the process is still running, right?
<ogra_ac> yeah
<rsalveti> do we have a /dev for nvidia?
<jdstrand> I thought we did
 * jdstrand doesn't have nvidia hardware
 * rsalveti neither
<kklimonda> yes, we do
<kirkland> slangasek: i need to add some additional smarts, beyond whether the process is running, i need to check if it's actually doing something
<kirkland> slangasek: ie, that it's not wedged in a while-true loop
<kirkland> slangasek: what's the best way to do that?
<jdstrand> I'll try to pull the sources and find it
 * kees reads
<kirkland> slangasek: in sysvinit script, the status action can be anything, in its own stanza in the case statement
<kirkland> slangasek: how could i get something similar out of upstart?
<jdstrand> kees: looking for the proper group for a udev rule for 3d graphics
<ogra_ac> sigh
<jdstrand> kees: it was 0666 with group 'users', I thought 0660 with something else, but am not up on groups for 3d
<ogra_ac> the nvidia source is 50 meg
<kees> jdstrand: the regular dri uses "video"
 * ogra_ac twiddles thumbs
<jdstrand> ah
<jdstrand> I thought it did
<kees> jdstrand: but gdm start-up set facls on console users too
<ogra_ac> ah
<kees> crw-rw----+ 1 root video 226, 0 2010-09-30 22:28 /dev/dri/card0
<kenvandine> ev, ping
<ogra_ac> then 0660 video it is
<rsalveti> hm, then video it is
<rsalveti> :-)
<jdstrand> kees: thanks
<kees> jdstrand: sure thing
<jdstrand> $ ls -l /dev | grep video
<jdstrand> crw-rw----  1 root video    10, 175 2010-10-01 10:35 agpgart
<kees> it still might need facl-style stuff though
<jdstrand> too easy
<ogra_ac> lol
<kees> $ getfacl /dev/dri/card0 | grep kees
<kees> user:kees:rw-
<kees> gdm or somebody does that, since I don't think the default users is in "video" any more...
<kees> *user
<ogra_ac> right
<jdstrand> ah, seems not
<jdstrand> (I am not)
<ogra_ac> thats why i said above it would require tinkering with groups
<kees> probably best to ask RAOF about it
<kees> <unhelpful>"users" 0666 is certainly wrong though. :P
<jdstrand> 0666 makes me pretty uncomfortable though
<trijntje> is there a way to see in LP who imported a package (and translations) from upstream into LP?
<slangasek> kirkland: 'status' returns the information upstart has about the status of the job; if you need some other kind of status check, I would recommend a standalone tool similar to apachectl
<ogra_ac> jdstrand, uploading ubuntu2
<kirkland> slangasek: :-/
<slangasek> kirkland: not in an init script, because that will collide with all of the auto-mapping support between sysvinit and upstart
<slangasek> kirkland: why do you have a server that can get wedged? :)
<kirkland> slangasek: hmm, well, hard to answer that question in a politically correct manner
<slangasek> kirkland: does this status check need to be integrated with something like heartbeat, though?
<kirkland> slangasek: in any case, is it safe to say that moving a sysvinit script to upstart loses the ability to do a "smart" status check?
<kirkland> slangasek: yes, something like heartbeat/pacemaker/etc
<kirkland> slangasek: okay, so let's say I add something to service(8)
<kirkland> slangasek: perhaps, "status+"
<slangasek> kirkland: "safe to say" - I wouldn't say it that way because it casts it as an init system problem instead of a service problem, which is what I think bears the responsibility for not getting itself wedged
<kirkland> slangasek: service <FOO> status+
<jdstrand> ogra_ac: accepted
<jdstrand> kees: thanks again
<kees> jdstrand: np
<ogra_ac> jdstrand, awesome
<ogra_ac> thzanks !
<andreserl> kirkland, just for clarification, but prolly you already know this, pacemaker has various ways of monitoring a service. One, would be by the use of sysvinit scripts, using the return codes of the scripts. Second, using upstart status output, which was recently added by Ante, Third, using OCF scripts, that what they basically do, is to monitor the application itself, however this is customizable  as long as you follow the standard for creating
<andreserl> such scripts :)
<jdstrand> hehe
<rsalveti> jdstrand: cool, thanks :-)
<jdstrand> rsalveti: sure :)
<paissad_> guys, here is my debian/rules http://pastebin.com/LCb0Ggb9, there is dh_fixperms into it ... but i don't understand the reason why i get this warning with lintian -->executable-not-elf-or-script <-- AND indeed those files have their permissions not changed in the package
<paissad_> where am i wrong ?
<paissad_> i'm really confused .. i even added 'dh_fixperms' in other targets of the debian/rules file ... but nothing changed
<paissad_> the build finished successfully ... but i have 3 warnings about executable files in /usr/share/pms-linux/ ....
<cjwatson> dh_fixperms isn't entirely magic - if something is making the file executable, shove chmod -x in there
<paissad_> cjwatson, i'm quite sure that dh_fixperms failed ^^
<paissad_> i even can say i'm certain of this !
<cjwatson> no
<paissad_> cjohnston, it did not change the perms
<cjwatson> read its documentation
<cjwatson> it's not supposed to change *everything* - it fixes *certain problems*
<paissad_> cjohnston, i did read the manpage already (before posting)
<paissad_> it's a minimum :)
<cjwatson> I am not cjohnston
<paissad_> oh sorry !
<cjwatson> the manual page does not say anywhere that it makes files under /usr/share non-executable
<cjwatson> except doc
<cjwatson> it's very specific
<cjwatson> just insert chmod -x commands
<cjwatson> you can also run with DH_VERBOSE=1 set in the environment to see exactly what debhelper commands are doing
<paissad_> cjwatson, i thought about the chmod -x command ... but i just wanted to know the reason why dh_fixperms did not work in my case
<cjwatson> because it can't realistically guess everything - files in /usr/share/PACKAGE are often meant to be executable
<paissad_> cjwatson, ok
<ari-tczew> cjwatson: are you a Debian Developer?
<cjwatson> ari-tczew: yes, have been for ten years, why?
<cjwatson> (well, thinking about it, that's exaggerating by a few months)
 * maco rolls eyes
<ari-tczew> cjwatson: I think whether you can apply this patch in Debian: debian bug 506083
<ubottu> Debian bug 506083 in palo "palo: open(O_CREAT) needs a mode argument" [Normal,Open] http://bugs.debian.org/506083
<cjwatson> Debian doesn't normally work like that.  You need to ask its package maintainer
<cjwatson> oh, it's QA
<cjwatson> yeah, guess I could, not tonight though
<ari-tczew> cjwatson: would be nice if you add this one to your to-do ;)
<cjwatson> it had a proper maintainer when I filed that bug
<kirkland> RoAkSoAx: are you here?
<RoAkSoAx> kirkland: yes
<kirkland> RoAkSoAx: i know about those 3 methods...  there's just a "deficiency" we perceive in upstart's ability to test the real actual status of a service
<kirkland> slangasek: okay, here's what I'm thinking ...  adding something to the service(8) command;  perhaps call it "status+", which first runs the status from sysvinit or upstart, but then executes (if available) something in /etc/status/$NAME, which is able to do "smarter" or "deeper" testing of the practical status of the service
<kirkland> slangasek: for something like lighttpd, it's great that there's a pid for the process, but can wget retrieve a webpage from it
<kirkland> slangasek: thus, you can define the real status+ of a service with something in /etc/status/lighttpd (as an example)
<slangasek> kirkland: why under /etc/status instead of, say, /usr/lib/service/status/ ?
<slangasek> putting it under /etc implies packaging overhead that seems avoidable here
<kirkland> slangasek: sure -- that's fine
<RoAkSoAx> kirkland: "pid for the process, but can wget retrieve a webpage from it" > that's exactly how the "monitor" option in a cluster would work, instead of just verifying if the service is running or not, which doesn't mean that it is receiving request in your example
<kirkland> slangasek: i was thinking of symlinks in /etc, to stuff in /usr/lib, actually
<kirkland> slangasek: that someone could break, or modify to their liking, if necessary
<slangasek> kirkland: I wouldn't introduce the complexity of /etc/status until there was a demonstrable demand for it
<kirkland> slangasek: ack, understood
<kirkland> slangasek: what do you think of the nomenclature?  "service <FOO> status+" ?
<slangasek> kirkland: otherwise, that seems ok - it'd be nice if this wasn't needed, using something like what RoAkSoAx suggests in its place, but I don't feel strongly about this
<slangasek> kirkland: sees ok
<slangasek> seems
<kirkland> RoAkSoAx: okay, so how is your way done generically, for anything started by upstart or sysvinit?
<RoAkSoAx> kirkland: from the cluster point, generically, it is just monitoring the return codes of sysvvinit, for start, stop, and status, and something similar is done for upstart
<RoAkSoAx> but for examplke, if using OCF resource agents, we could monitor if the webserver is respoding to request
<RoAkSoAx> for ex, from the apache OCF resource agent: " monitor:  return TRUE if the web server appears to be working. For this to be supported you must configure mod_status and give it a server-status URL.  You have to have installed either curl or wget for this to work."
<kirkland> RoAkSoAx: right... okay;  here's the problem -- upstart's "status" is NOT sufficient (ie, it's not "smart" enough) for the test we need to perform
<ebroder> Hmm...how do I make mountall interact nicely with encrypted swap? Right now I have a line in /etc/crypttab, and a line in /etc/fstab, but cryptsetup hasn't run before mountall does, so I get the "unable to find <my swap device>" error
<RoAkSoAx> kirkland: if you need it for monitoring within an HA cluster, I'd suggest creating OCF resource agents
<RoAkSoAx> kirkland: or providing the ability to upstart to do something similar, or either a tool that could do just that, monitor something specific
<ebroder> Oh wait...maybe I screwed up my fstab
<kirkland> RoAkSoAx: okay
<RoAkSoAx> kirkland: is this for HA clustering?
<slangasek> ebroder: yes, sounds like a busticated fstab; for encrypted swap, cryptsetup should run /well/ before mountall, i.e., in the initramfs
<ebroder> slangasek: Yeah, I left out the second column in my swap line. My bad. Although I thought cryptsetup only ran for the root device in the initrd
<RoAkSoAx> kirkland: if you need to take a look to some OCF resource agents, they are in "cluster-agents", inside heartbeat folder. Pacemaker also provides other ocf resource agents I believe
<slangasek> ebroder: root device and swap, because you might hibernate/resume to swap
<slangasek> to encrypted swap, I mean
<ebroder> slangasek: Huh. That's clever
<paissad_> damn it, i have to build a package for amd64 and for i386 archs, but i don't have currently an i386
<paissad_> ^^
<paissad_> is there a way to build a package for i386 from an amd64 arch ?
<Daviey> paissad_: yes.. you can use amd64 to build i386, but tricky to do the other way around
<Daviey> paissad_:  if you use pbuilder-dist.....  $ pbuilder-dist maverick i386 create   -> then $ pbuilder-dist maverick i386 foo.dsc
<YokoZar> ArneGoetje: ttf-baekmuk and xfonts-baekmuk look like they contain the same thing -- should the latter package be dropped?
#ubuntu-devel 2010-10-02
<ogra_ac> kirkland, ping
<paissad_> Daviey, ok
<kirkland> ogra_ac: hi
<ogra_ac> kirkland, your change to user-setup isnt the the bzr tree
<ogra_ac> kirkland, was that only the bs=16M in user-setup-apply ?
 * ogra_ac tires to get the branch fixed since he committed his fix already
<ogra_ac> (before looking at the package indeed)
<kirkland> ogra_ac: yes, that's all
<ogra_ac> ok
<kirkland> ogra_ac: sorry about that
<kirkland> not sure how that happened
<ogra_ac> well, dont worry, i'm sorting
<kees> slangasek: erm, seems like a "status" stanza is needed in upstart. it's a regression that arbitrary checks can't be added.
<slangasek> kees: I'm of the view that this doesn't belong in upstart because upstart itself has no use for such a thing and it would be provided solely for external consumers, so there's no reason to involve upstart at all in the design; but Keybuk might take a different view if you ask him
<kees> slangasek: hm, as a sysvinit replacement, there is sense to "is my service operational?" beyond "is there a pid for it?" seems to me like that overlaps with upstart. I'll ask him.
<slangasek> kees: I agree that there's a need for querying such information, I just don't see any reason for pid 1 to mediate it
<slangasek> in fact, I can see that introducing some nice security holes ;)
<kees> slangasek: fair enough.
<kees> slangasek: right, the shift in who is doing what does pose a risk
<kees> if Keybuk agrees, I guess it should just live in the "service" command.
<kees> though "status" from upstart should be renamed.
<ArneGoetje> YokoZar: xfonts-baekmuk is an alias package. I don't think it's necesary any more.
<werew433> hellow I want to create driver for my Radeon X700 for full 3D on 10.04, where I can find radeon developers?
<ion> You can program a 3D accelerated driver but you canât find the project contact info on the web? :-)
<werew433> ok I find them
<paissad_> i try to build a package for lucid i386 , i did first (pbuilder-dist lucid i386 create) .... i did a chroot in that environnement .. installed needed packages and so  on ... but here is the error i get when i run the debian/rules
<paissad_> http://dpaste.com/251926/
<paissad_> here is the debian/rules file -> http://pastebin.com/4KnnLvPj
<paissad_> i did run debian/rules get-orig-source
<paissad_> this works in a normal environnement (no chroot)
<jellington> hey everyone, I was just wondering after upgrading my netbook to meerkat, how do I add items to the unity launcher?
<ScottK> jellington: Support is in #ubuntu+1 for Maverick.
<jellington> alright
<paissad_> guys, when run 'debuild -us -uc',  i don't get the *diff file ... i don't know why
<paissad_> here is the files i have http://pastebin.com/t3HDUm6S
<paissad_> may someone explain or help me ?
<paissad_> sorry, here is a better pastebin ;) http://pastebin.com/YiceNGFb
<paissad_> thanks in advance
<ScottK> paissad_: You're using Debian source format version 3.  It has debian.tar.gz instead of diff.gz that version 1 uses.
<paissad_> ScottK, ahhh, yeah that's it ! of course ... so knowing that i have a debian repository, i put the debian.tar.gz instead of the diff.gz ?
<paissad_> no no
<ScottK> paissad_: Are you working on a package that you hope to get into Ubuntu?
<paissad_> ScottK, no .. that will no go for Ubuntu, not for the moment .. but i maintain a repository that contains packages that many people use ... so i have to do a good job
<ScottK> paissad_: #ubuntu-packaging is probably a better channel for you.
<paissad_> ScottK, the package is already created ... but knowing that there's no more diff.gz file, ... i just wonder what to put in the repository instead ^^
<paissad_> btw, the package is also in PPA, so ...
<ScottK> paissad_: This channel is for development of Ubuntu.  What you're asking about is really off topic.
<paissad_> oh sorry
<paissad_> #ubuntu-motu is also for development of Ubuntu ?
<ScottK> Yes.
<ScottK> paissad_: #ubuntu-packaging (I think that's it's name) is for packaging help outside of Ubuntu (like PPAs)
<hyperair> is anyone processing SRUs for maverick yet?
<ScottK> None have been uploaded yet.
<hyperair> ScottK: would you mind uploading one for me please? =)
<hyperair> it's libgpod.
<ScottK> I'm a bit tied up at the moment.  Maybe later today.
<hyperair> ScottK: https://bugs.launchpad.net/ubuntu/+source/libgpod/+bug/652855
<hyperair> sure
<ubottu> Launchpad bug 652855 in libgpod (Ubuntu) "Please fakesync libgpod 0.7.95-1 from Debian experimental to maverick-updates" [Undecided,New]
<ScottK> If it's an SRU it won't get accepted until after release anyway, so there's no rush.
 * hyperair nods
<hyperair> ScottK: do i have to wait until libgpod is accepted before uploading banshee and banshee-community-extensions (bce depends on banshee which depends on libgpod) to -proposed?
<hyperair> or can i just upload those two already?
<ScottK> hyperair: No, they can all be uploaded, but if you're thinking of getting new releases in through updates, you ought to pre-coordinate with ubuntu-sru if you haven't.
<hyperair> ScottK: pre-coordinate how?
<ScottK> hyperair: Usually we don't accept new versions in -updates (except for the few packages that have micro-version update exceptions).
<ScottK> So if you upload new versions to updates without talking to them, I think they are likely to just reject it.
 * ScottK isn't on ubuntu-sru, so can't say for sure.
<hyperair> ScottK: so who in ubuntu-sru can i talk to about this?
<ScottK> Normally pitti would be best, but he hasn't been around much.  Not sure.
<hyperair> i see.
<hyperair> what about seb128?
<ricotz> hyperair, https://launchpad.net/~ubuntu-sru/+members#active
<hyperair> well, why didn't i think about that? =)
<paissad_> is  there another alternative to dput ? ... i know there's one .. but i've forgotten it
<happyaron> dupload?
<paissad_> hmm, maybe
<jonrafkind> i uploaded a file to my ppa ftp account using dput, am I supposed to take action after that?
<jonrafkind> i was expecting the ubuntu servers to attempt to build my package and send me an email or something
<cjwatson> jonrafkind: you should get an e-mail when the system accepts your upload, although you won't get an e-mail after the build unless the build fails.  If you don't get an e-mail on accept, then see https://help.launchpad.net/Packaging/UploadErrors
<jonrafkind> oh oops ok I got an email about upload failure. i forgot the tilda in front of the path
<jonrafkind> is this the right path to use? ~rafkind/ppa/ubuntu
<ebroder> If you're using dput, then just upload to ppa:rafkind/ubuntu
<jonrafkind> isnt that only in 9.10? i have 9.04
<happyaron> jonrafkind: then you'd change your ~/dput.cf
<jonrafkind> yes..
<happyaron> .dput.cf
<jonrafkind> but is my path right?
<happyaron> yes it is
<jonrafkind> ok
<jonrafkind> are you sure thats the right path? i got this error: Could not find a PPA named 'ppa' for 'rafkind'.
<jonrafkind> should i use the name of my ppa instead of the characters 'ppa' ?
<happyaron> jonrafkind: what's your launchpad username
<jonrafkind> rafkind
<happyaron> jonrafkind: well, you didn't use the default name, ppa
<happyaron> instead, you named it after "paintown"
<jonrafkind> yea
<happyaron> so ~rafkind/paintown/ppa and try again
<jonrafkind> the directions are sort of ambiguous about this
<happyaron> so ~rafkind/paintown/ubuntu, sorry
<jonrafkind> ok
<jonrafkind> this is pretty stupid how i get the path error after i upload the entire file
<jonrafkind> it takes me 20 minutes to upload this file, and then i get an error about the wrong file path
<happyaron> :(
<jonrafkind> if the default name was ppa then why do the dput directions on the launchpad page say 'dput ppa:rafkind/paintown <source.changes> '
<jonrafkind> so if i changed my package name from 'ppa' to 'paintown' that should affect the 'ubuntu' in that path
<jonrafkind> are you sure its not ~rafkind/ppa/paintown ?
<jonrafkind> sorry i mean, 'that should not affect the ubuntu in the path'
<happyaron> jonrafkind: 'ubuntu' is always the finishing thing in your path of launchpad ppa
<jonrafkind> https://launchpad.net/~rafkind/+archive/paintown
<jonrafkind> can you see the contents of this page?
<jonrafkind> it says dput ppa:rafkind/paintown
<happyaron> jonrafkind: yes, that's correct
<jonrafkind> so.. that doesnt end with /ubuntu
<jonrafkind> or you're saying the 9.10 version of dput is different from the ftp version?
<jonrafkind> if i had just used 'ppa' as the name then it would be 'dput ppa:rafkind/ppa' ?
<happyaron> jonrafkind: yes, if you have 9.10 or higher, just do that
<jonrafkind> right, but i dont
<jonrafkind> im just wondering about the naming convnetions
<happyaron> jonrafkind: if not, you should use ~username/ppaname/ubuntu
<ebroder> jonrafkind: Just add this block to your ~/.dput.cf: http://pastebin.ubuntu.com/504628/
<ebroder> Then you can do dput ppa:rafkind/paintown or whatever
<jonrafkind> ok. the directions were confusing because they say 'probably you should use the default name ppa'
<ebroder> the ppa: URLs were a configuration, not a code, change
<jonrafkind> but thats sort of ridiculous because when i created the ppa i wanted to give it a name
<jonrafkind> it seems most likely that people will name their ppa something other than 'ppa'
<jonrafkind> so the directions should say 'use the name that you chose when you created the ppa'
<happyaron> jonrafkind: you may want to discuss these things at #launchpad, :)
<jonrafkind> whats %(ppas)s ?
<jonrafkind> is that a meta comment?
<ebroder> jonrafkind: It doesn't matter. It's the magic that makes ppa: URLs work
<jonrafkind> so if i use that and then do 'dput ppa:rafkind/paintown' it would work?
<ebroder> Yes
<jonrafkind> oh ok, and this is the only change between 9.04 and 9.10?
<ebroder> It's the only one relevant to dput ppa: working
<jonrafkind> ok, thanks
#ubuntu-devel 2010-10-03
<hallyn> i'm not thinking right about something.  i have some source in a bzr tree.  i want to build a package from it.  bzr bd insists i need a .orig.tgz, but it's all in (and only in) the bzr tree!  should i just build a bogus .orig.tgz and .changes and debuild -S by hand with that?
<hallyn> clearly i'm not thinking right about something
<jonrafkind> i screwed up my source package but when I rebuild the package with debuild -S (which builds the same filename as before) I get a rejection saying the file already exists
<jonrafkind> so is the solution to make a new filename (bump the version)? which means I have to bump the version in all the control/changelog/whatever files?
<jonrafkind> sorry i meant after i rebuild the package with debuild -S and upload it with dput
<ebroder> That's right. You can only upload a particular version of a particular package to a particular repository once
<ebroder> Did something replace gdebi as the default .deb file type handler in maverick?
<kklimonda> ebroder: software-center
<ebroder> Huh. Thanks
<sladen> ebroder: xdg-open somefile.deb
<jonrafkind> how do I get dh-make not to run 'make test' ?
<jonrafkind> or maybe its just 'dh' that i want
<ion> jonrafkind: See dh(1), look for âCommands not to runâ and âoverride_dh_auto_testâ.
<jonrafkind> neither of those are in dh or debhelper
<jonrafkind> man pages
<ion> debhelper: /usr/share/man/man1/dh.1.gz
<jonrafkind> can you send me that file or something? i guess i have an older version than you
<jonrafkind> actually ill try to find it online i guess
<jonrafkind> can someone show me an example of overriding dhauto test ? I tried adding rules to my makefile 'override_dh_auto_test: echo nothing' but it doesnt take
<jonrafkind> i also tried override-dh-auto-test
<james_w> jonrafkind: "override_dh_auto_test:\n\techo foo" is correct
<jonrafkind> does it have to be before the %: dh $@ rule?
<james_w> nope
<jonrafkind> hm.. i wonder why its not working
<james_w> jonrafkind: did you literally write "override_dh_auto_test: echo nothing"?
<jonrafkind> well i used the newline and tab stuff
<james_w> ok
<jonrafkind> i know makefile syntax
<james_w> http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/annotate/head:/debian/rules
<james_w> that's one I wrote just the other day that works
<jonrafkind> ok
<jonrafkind> ok it didnt work becuase somehow pbuilder installed an old version of dh that didn't recognize the override stuff
<jonrafkind> which is strange considering my local dh does recognize override, so i wonder what pbuild is installing
<pk4r> Hello, is this the right place to ask a few packaging related questions ? I'm currently trying to package a few PHP web applications, while following the official Ubuntu Packaging Guide I feel there're more things to know when it comes to web apps (supporting different servers, post-install configuration etc.).. I downloaded source of phpmyadmin to explore a little bit.. just starting with it. Can anybody give some pointers on that ?
<micahg> pk4r: if it's for a PPA, #ubuntu-packaging is the place, if it's for the archive, #ubuntu-motu would be the place
<hyperair> hmm this is interesting. openoffice's orig.tar.gz was 300+M, but libreoffice's is only 13M
<hyperair> i wonder what's been left out of libreoffice's
<slomo> hyperair: maybe they don't include copies of every single dependency, including python and other large things ;)
<hyperair> slomo: oh lol
<hyperair> slomo: i remember openoffice taking over 2 days to build on a pentium 4 system. i wonder if libreoffice would do the same
<hyperair> it's kinda hard to imagine 13M of source code taking that long to build.
<hyperair> i mean hey the kernel was 700M or so...
<Riddell> hyperair: the source is actually the go-oo build source, which is just patches for applying to the openoffice.org source
<hyperair> Riddell: and so.. there's 300M of patches?
<Riddell> there's 13M of patches
<alex88> hi..i've 2 questions, why after installing the nvidia drivers plymouth gives me low-res splash screen? also, is possible to unlock keyring on login? If i install libpam-keyring and add to /etc/pam.d/gmd i can't login..
<Laney> ssh
<steve|m> hi, can anyone confirm that if pressing a multimedia hotkey on the keyboard the left mousebutton doesn't work anymore in the current session in maverick?
<steve|m> I tried it on 2 different machines, xev even doesn't show the left mouse button click anymore (multimedia keys being Play/Pause, calculator, email and the like)
<zyga> hi
<steve|m> can anyone confirm this one? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/654201
<ubottu> Launchpad bug 654201 in xserver-xorg-input-evdev (Ubuntu) "pressing multimedia hotkeys disables left mousebutton" [Undecided,New]
<maxb> james_w: Hi. That bug you just edited - is there another one to track the rest of the NoSuchTag UDD failures?
<jonrafkind> im making a source package for my ppa, what is my make install target supposed to do? i tried doing 'mkdir /usr/bin/games; cp my-game /usr/bin/games' but I get a build error that says the mkdir failed because of permission errors
<jonrafkind> does the launchpad builder not run with root permissions?
<ebroder> jonrafkind: http://www.gnu.org/prep/standards/html_node/DESTDIR.html
<jonrafkind> ah ok
<lifeless> jonrafkind: #ubuntu-packaging is probably a better channel for this question; packages install into a staging area not into /usr
<jonrafkind> so maybe $(DESTDIR)/bin/games
<jonrafkind> omg, how many different channels are there? so far ive found 3
<ebroder> Lots. https://wiki.ubuntu.com/IRC/ChannelList
<ebroder> And I don't think that list is exhaustive
<jonrafkind> ubuntu loves beauracracy eh?
<sladen> jonrafkind: you don't install it directly, you install your stuff into some directory where told (DESTDIR in this case), and then the packaging build system will bundle that up
<lifeless> no, ubuntu is dealing with thousands of people doing stuff at the same time.
<sladen> jonrafkind: it's more that Ubuntu is quite big.  If would get very noisy if everyone was in the same place
<jonrafkind> $DESTDIR is not set in the debian/rules file
<zyga> jonrafkind, is your software written in C?
<jonrafkind> hm, dh_auto_install sets DESTDIR, but I have my own install target that acts differently
<jonrafkind> c++
<zyga> jonrafkind, if so you'd save everyone lots of hassle by using autotools
<jonrafkind> i use scons
<zyga> jonrafkind, that will work too
<zyga> jonrafkind, oh
<zyga> jonrafkind, does scons suport DESTDIR?
<jonrafkind> the point is i have my own makefile that when you do 'make install' it runs  another script that asks you some questions about where to install
<jonrafkind> i could have a separate install target for this dh stuff that used DESTDIR I guess
<zyga> jonrafkind, in packaging that is always a bad idea
<jonrafkind> well.. thats debateable
<jonrafkind> is it possible to get dh_auto_install to use a different target?
<zyga> jonrafkind, you should install to $(DESTDIR)$(something)
<zyga> jonrafkind, you miss the point - the installer is just building the image of the stuff that gets installed by the end user from a package, things have well defined locations, if you want to configure something do that _before_ building you package (configure step in autotools)
<zyga> jonrafkind, I'm not sure I don't do a lot of packaging
<jonrafkind> i understand how it all works and I know thats what most people do
<jonrafkind> but i have decided to do it a different way
<zyga> jonrafkind, it seems that you built an user-friently installer, is that correct?
<jonrafkind> yes
<zyga> jonrafkind, that should be a separate script IMHO, you should use it to trigger the normal build script/makefile/whatever with arguments
<jonrafkind> it is a separate script, but so far i have 'make install' just execute that script
<zyga> jonrafkind, well changing it to be exactly opposite is the quickest way to solve your problem
<zyga> jonrafkind, you can still keep the custom installer script
<jonrafkind> only to satisfy ubuntu's process
<jonrafkind> other systems (arch, gentoo) don't have this issue
<zyga> jonrafkind, honestly if your software is open source it's not related to ubuntu, nobody expects a talking installer
<jonrafkind> well they are gonna get one!
<zyga> jonrafkind, arch has binary packages correct?
<jonrafkind> yea
<zyga> jonrafkind, I don't know too much about it but your problem is trying to use interactive steps in an environment that requires none (automated builds)
<cjwatson> could you please take this elsewhere?  I think there was already conversation above indicating that it's more relevant to #ubuntu-packaging than here - we try to reserve this channel for development of Ubuntu itself, so that our developers can focus on that
<zyga> I understand your desire to use user friendly installer but IMHO you used the wrong place to put your interactivity bits
<jonrafkind> well that assumes the way dh works cannot be changed
<jonrafkind> i asked in #ubuntu-packacing and no one responded, and b) there is no one else talking
<zyga> jonrafkind, cjwatson is right, this is not the right place
<cjwatson> b) irrelevant, developers read scrollback
<cjwatson> and the fact that another channel is quiet doesn't mean this is the right place for it
<jonrafkind> zyga, do you wish to join #ubuntu-packaging?
<zyga> why not
<cjwatson> thanks
#ubuntu-devel 2011-09-26
<poolie> tjaalton, hi? bug 745112 seems to have regressed, can i do anything to help?
<ubottu> Launchpad bug 745112 in linux (Ubuntu) "[arrandale] desktop is messed up with external monitors (x86_64)" [Critical,Triaged] https://launchpad.net/bugs/745112
<mwhudson> poolie: are you on oneiric?
<poolie> yeah
<poolie> it's intermittently very good
<mwhudson> heh
<poolie> i guess i should have asked in +1
<mwhudson> i guess i should upgrade soon
<poolie> however lack of reliable external monitor and suspend support is kind of annoying on a laptop
<poolie> unity is getting distinctly useful
<mwhudson> does unity itself work well with multiple monitors yet?
<mwhudson> some times i would like not to have the laptop display off when using another monitor
<poolie> i think tolerably well
<poolie> i mostly find it too distracting and turn the internal one off
<poolie> however it seems to be lacking a way to control where the dock/menubar go
<pitti> Good morning
<pitti> slangasek: yes, I recently demoted ubuntuone-couch/mocker because nothing kept it in main any more; but both have MIRs, so I re-promoted them
<pitti> cnd: pkg-create-dbgsym itself can do it, but for regular PPAs there is no archive to publish them to
<pitti> cnd: it's primarily an option for the OEM PPAs, which are non-virtualized and they have their own archive
<slangasek> pitti: actually I repromoted them before you got to it ;)  (morning!)
<ScottK> pitti: Getting dbgsym packages into a proper archive would be a good UDS topic I think.
<pitti> doko_: yes, g-shell was uploaded, but dep-waiting on caribou; both are built now, and the remaining cogl2 rdepends are now fixed
<pitti> slangasek: gdm/lightdm fix> no, go ahead; I guess you already did
<slangasek> pitti: more or less... gdm is in, lightdm was caught up because robert_ancell has changes committed to trunk - I've branched around that now, needs someone to approve it in the queue :)
<pitti> ScottK: not sure what's left to do there; LP supports it, IIRC the main thing there is that it is hard for LP to "forget" the obsolete ones
<ScottK> If it was easy, you'd have done it already.....
<pitti> but I'd be really happy to finally drop this nasty and brittle ddeb-retriever hack
<superm1> when are the daily images going to be resumed again?
<superm1> i had wanted to check and make sure that the changes I made post b2 didn't push mythbuntu back oversized again
<pitti> superm1: they are on now
<pitti> but no idea whether they were enabled ten minutes ago or on Friday
<superm1> probably today, i haven't seen any livefs attempts from the weekend (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/)
<superm1> i'll check tomorrow then, thanks pitti
<ScottK> It was Sunday, FSVO Sunday.
<tjaalton> poolie: hmm, maybe open a new bug for it, with a reference to the old one? also, please try 3.1rc mainline kernel if it's fixed there
<poolie> ok tjaalton
<poolie> tjaalton, is there a packaged 3.1rc?
<tjaalton> poolie: sure, http://kernel.ubuntu.com/~kernel-ppa/mainline/
<dholbach> good morning
<micahg> pitti: does it make any sense to use dh --with apport and then override it later?
<pitti> micahg: I think it does if you want to supply extra options
<micahg> ok, great, that's what I want to do (needs a package name :))
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<pitti> micahg: then you don't need to care about which other dh_* command to append it to, i. e. --with will take care of the correct ordering already
<pitti> micahg: (not a biggie for dh_apport, but in general)
<micahg> pitti: oh,  so I could toss it under override_dh_auto_install?
<tkamppeter> pitti, it is about bug 787067, a GS crash on Apple-generated EPS files. Fix would be to not use the system-supplied liblcms1 any more but the Ghostscript-built-in one. Should I switch to that one then?
<pitti> micahg: no, that's too early
<ubottu> Launchpad bug 787067 in ghostscript (Ubuntu) "Apple-generated EPS figures in LaTeX-generated PS file cause Ghostscript to segfault" [High,Confirmed] https://launchpad.net/bugs/787067
<pitti> micahg: override_dh_install perhaps
<micahg> pitti: I just did override_dh_apport?
<pitti> micahg: yes, that plus --with is correct
<micahg> ok, great
<pitti> tkamppeter: I'd rather avoid it; library duplication is EBW
<pitti> tkamppeter: can't the fix be applied to liblcms1?
<dholbach> lucas, bon anniversaire! :)
<tkamppeter> pitti, the fix suggested here is downgrading to liblcms1_1.16-7ubuntu1
<tkamppeter> pitti, we currently use 1.19.dfsg-1ubuntu1
<tkamppeter> pitti, perhaps one can advance GS to liblcms2.
<pitti> tkamppeter: it seems it's rather easy to reproduce the bug with a command line, so bisecting liblcms changes between 1.16 and 1.19 should be feasible; woudl be better to fix the regression for 1.19 than downgrading, IMHO
<tkamppeter> pitti, quick check shows that building GS against lcms2 fixes the segfault, but GS upstream developers tell that lcms2 is too buggy and not recommended to be used with GS ...
<brendand> does anyone know if there's been a change in glade (or gtk) such that the __init__ function of custom components written in python wouldn't get called? i've been hit by this since just a few days ago (friday)
<pitti> brendand: bug 856669
<ubottu> Launchpad bug 856669 in pygobject (Ubuntu Oneiric) "pygobject 3.0.0-0svn1 does not work with custom python GTK widgets" [Critical,In progress] https://launchpad.net/bugs/856669
<pitti> brendand: I'm working on it right now
<brendand> pitti - brilliant! great to know it's a known issue
<lucas> dholbach: thanks :)
<pitti> brendand: fix uploaded, FYI
<brendand> pitti - cool. thanks
<AlanBell> ev: can we discuss bug 781385
<ubottu> Launchpad bug 781385 in ubiquity (Ubuntu) "Ubiquity GTK should have useful accessible names set in the Glade .ui files instead of using the variable names" [Medium,Confirmed] https://launchpad.net/bugs/781385
<Sweetshark> Moin desktoppers!
<jibel> mvo, morning, could you look at 854090 ?
<mvo> jibel: sure!
<jibel> bug 854090
<ubottu> Launchpad bug 854090 in aptdaemon (Ubuntu Oneiric) "aptd crashed with SIGSEGV in debListParser::LoadReleaseInfo()" [High,Confirmed] https://launchpad.net/bugs/854090
<mvo> jibel: did you (or someone else) actually managed to reproduce this one?
<jibel> jibel, not yet, I just saw the high number of recent duplicates.
<ev> AlanBell: sure can, though I've followed up on the bug.
<didrocks> mvo: I didn't manage to reproduce it, just seeing a lot of people getting it using oneconf for instance (which just get the list of installed package)
<mvo> didrocks: oh, thats interessting
<didrocks> mvo: the only part using apt is http://paste.ubuntu.com/697154/ FYI
<didrocks> not sure if this can help
<mvo> ok
<SrPiojos> good morning
<AlanBell> thanks ev
<ev> sure thing
<SrPiojos> I am in the process of designing a forum for Ubuntu Developers in Mexico
<SrPiojos> and I need advice as to which of these four logos on this montage
<SrPiojos> would look that best
<SrPiojos> http://i.imgur.com/Usqtb.jpg
<ochosi> chrisccoulson: ping
<tkamppeter> pitti, I am trying to get a stack trace from liblcms, I have rebuilt the package locally and then manually copied the unstripped version of the lib into its place in the system, bug gdb says warning: Can't read pathname for load map: Input/output error. and does not load the symbols of liblcms. Is there a special trick for multiarch?
<pitti> tkamppeter: the warning happens everytime, that's normal
<tkamppeter> pitti, any idea why I do not get the symbols? I have checked the lib with "file" and it is really unstripped.
<pitti> tkamppeter: did you copy it to the same place as the original package?
<pitti> tkamppeter: if so, then I have no idea
<OdyX> pitti, tkamppeter: do you have opinions about http://bugs.debian.org/641687 ? (aka "impossible to setup a printing driver without colord installed" )?
<ubottu> Debian bug 641687 in cups "cups: Failed to automaticly configure a printer when no color manager is available" [Normal,Open]
<tkamppeter> pitti, I did, /usr/lib/x86_64-linux-gnu/
<AlanBell> ev: is there a way to run ubiquity from trunk, I only know how to start it from the live CD
<lag> My desktop just randomly shut itself down
<ev> AlanBell: you can build it using debuild then copy the resulting ubiquity-frontend-gtk, ubiquity, and ubiquity-ubuntu-artwork debs into a live CD
<tkamppeter> pitti, on #ghostscript I got told that libcms1 is not maintained upstream any more and therefore the GS deveklopers have applied fixes to their own version and did not report them upstream. They also tell that therefore in GS 9.05 they want to remove the possibility to use the system liblcms(1). Seems that for P we need to switch GS to liblcms2 and use the time of the cycle to test and find bugs. WDYT is best for Oneiric then?
<lag> I've looked in /var/log/[kernel.log&syslog], but there's no clues in there as to what went wrong
<AlanBell> ok, not much easier than just booting the CD and poking at the files there
<ev> AlanBell:  indeed, that
<ev> s generally much quicker
<AlanBell> lag: probably temperature
<tkamppeter> pitti, Upstream GS suggests to use GS' own lcms1 for the current Ubuntu release.
<lag> AlanBell: Does Ubuntu log such things?
<pitti> tkamppeter: could we at least bisect the changes and check which one caused the regression?
<lag> AlanBell: Surely there would be something in the logs "over-temp warning, shutting down..."
<pitti> tkamppeter: duplicating libraries is a pain, and downgrading gs' one to a previous version will presumably re-open color management bugs again which were fixed since then?
<AlanBell> lag: yes, in syslog normally I think. It is the main thing I know of that causes a controlled suicide shutdown -h now
<lag> AlanBell: I don't see anything
 * lag installs sensors-applet 
<tkamppeter> pitti upstream suggests duplicating the lcms1. They want to stabilize the lcms2 shared library use for the next cycle (9.05).
<tkamppeter> pitti, I have diffed the upstram source of liblcms1 with the source coming with GS and the diff of the src/*.c is huge.
<tkamppeter> pitti, bisecting does not work, there is VCS for libcms1.
<pitti> "no VCS"?
<tkamppeter> pitti, seems that we have to duplicate the lcms1 to overcome the time until getting the real solution in GS 9.05.
<pitti> tkamppeter: can we disable color management support in gs for oneiric, if it's not ready yet and crashy?
<tkamppeter> pitti, the VCS on LittleCMS.com is a GIT started in 2010 with only libcms2.
<cjwatson> lots of upstreams suggest duplicating libraries; if they were all correct then distributions would be considerably larger and considerably less secure :-)
<tkamppeter> pitti, I do not really know whether it is possible in GS 9.0x, as CMS is deeply integrated there. It can perhaps cause more crashes at other places.
<tkamppeter> pitti, only crash point in GS for now are these Apple-generated EPS files, so most of CMS is stable. Switching to the GS-internal lcms1 would make also this point stable and we would ship a GS without known crashes.
<tkamppeter> pitti, security responsability of this code piece will be taken by GS upstream.
<pitti> tkamppeter: it might fix this bug, but how many others would it reopen?
<tkamppeter> pitti, and it is also only for one non-LTS cycle.
<pitti> all the changes between 1.16 and 1.19 weren't made in vain, I suppose :)
<tkamppeter> pitti, the one in GS is the new one, not 1.16.
<pitti> tkamppeter: I thought you said it only worked with 1.16, so I thought that's the version gs ships with
<pitti> if it also ships with 1.19, then the diff can't possibly be so large?
<pitti> or did they do so heavy modifications to the internal copy?
<pitti> (if so, it's all the more reason to disable it completely -- this kind of behaviour is simply unacceptable)
<tkamppeter> pitti, the diff is really big: 15 files changed, 1050 insertions(+), 905 deletions(-)
<pitti> tkamppeter: so I suppose the included version isn't 1.19?
<tkamppeter> pitti, I have diffed the included version against 1.18 and 1.19. The diffstats look nearly equal. This means that the changes the GS developers did are much, much bigger than the changes between 1.18 and 1.19
<tkamppeter> pitti, 1.18 -> 1.19: 4 files changed, 10 insertions(+), 7 deletions(-)
<tkamppeter> pitti, additional remark: I tried also to install 1.16 (originally suggested workaround) but GS crashes with it for me, too.
<pitti> so that also means gs' internal copy is a totally homebrew one, and hasn't been tested at all so far with other printing related things
<pitti> that makes me even less confident that switching to the internal version is a good idea at this point ..
<directhex> mvo, how does apt's new netrc support deal with passwords containing spaces?
<tkamppeter> pitti, the internal lcms was tested by the regression tests of GS upstream which they do after every GIT commit and these tests run 1000s of files through GS, there are even tests with the CUPS Raster output device.
<pitti> tkamppeter: and we know that their version works with our packaged version of colord, gnome-color-manager, etc? we never tested it in any real "print this document" test case in oneiric
<tkamppeter> pitti, perhaps leaving this bug unfixed and providing a personal solution (PPA), for example a GS build using libcms2 to this one user who complained, and putting O and P tasks to the bug, marking O "Won't fix", as it is too close to release and the available fixes are too big changes.
<pitti> tkamppeter: works for me
<tkamppeter> pitti, I will also use this LCMS2-based GS on my systems to keep it under observation and also upload it to P as soon as P opens, so that it gets tested. If it turns out to be stable I will propose it as SRU in 2 months or so.
<janimo> ScottK, hi, around? Why is the build log necessary for the glmark2 FFE? Also the detailed description of testing? The one requesting the FFE and the packager is the upstream author as well
<ScottK> Because those are normal things required for an FFe.
<janimo> build log? hmm, never saw that asked for honestly.
<tkamppeter> pitti, OdyX wants an opinion about debian bug 641687, should we make cups depend on colord here?
<ubottu> Debian bug 641687 in cups "cups: Failed to automaticly configure a printer when no color manager is available" [Normal,Open] http://bugs.debian.org/641687
<pitti> tkamppeter: that sounds unsuitable for Debian at least; we can't easily make it work without colord support?
<pitti> OdyX: ^ cups is also used in embedded environments, so adding a hard dependency on colord seems a bit exaggerated?
<OdyX> pitti: I would tend to agree, yes. colord doesn't sound essential to cups' core task, so wouldn't justify a hard depends. IMHO, eh.
<mvo> directhex: space should work fine, the tokenizer uses \n\t as tokens
<mvo> directhex: eh, as delimit
<directhex> netrc(5) says spaces as well. which is the issue
<directhex> the python netrc library implies you can't use spaces in netrc, too
<tkamppeter> pitti, so the colord patch of CUPS needs a fix to fall back to non-CMS if colord is absent. Is this only relevant for Debian or should we do this fix also for Oneiric?
<tkamppeter> OdyX, ^
<OdyX> If colord is also a recommends of cups in oneiric, I'd say it should be done in both.
<mvo> directhex: hm, I don't know about the python one, but at least from looking ah the apt code (and curl) it should work, but I did not actually test it, so I may be wrong
<pitti> tkamppeter: seems relevant for both
<tkamppeter> pitti, next problem: bug 850680, some packages' postinstall scripts return error status 10. Do you have any idea? The treminal logs do not show anything useful.
<ubottu> Launchpad bug 850680 in foomatic-filters (Ubuntu) "package cups 1.4.6-5ubuntu1.4 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 10 zurÃ¼ck" [Undecided,New] https://launchpad.net/bugs/850680
<cjwatson> tkamppeter: DEBCONF_DEBUG=developer
<Daviey> Can an archive admin reject cobbler-enrol (source) NEW package please, been superseeded with cobbler-enlist.  Thanks :)
<cjwatson> tkamppeter: error 10 is typically debconf's "bad parameters" error, indicating incorrect use of debconf
<cjwatson> tkamppeter: the above environment variable should let you track it down
<cjwatson> it's generally, though not exclusively, an attempt to use a question name that doesn't exist
<tkamppeter> cjwatson, strange is that I never changed this debconf stuff and that only one user complained and not 100s.
<cjwatson> tkamppeter: it could easily be conditional code or similar.  It needs investigation rather than either of us guessing ...
<tkamppeter> cjwatson, perhaps I have to ask the user to run the scripts manually with DEBCONF_DEBUG=developer.
<tkamppeter> pitti, I have a problem with upload to my PPA. Half an hour ago it worked, now I get
<tkamppeter> Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
<tkamppeter> Note: This error might indicate a problem with your passive_ftp setting.
<tkamppeter>       Please consult dput.cf(5) for details on this configuration option.
<cjwatson> tkamppeter: yes, that is roughly what I'm suggesting.  But don't ask them to run the scripts manually, as it's too easy to get the arguments wrong; try 'DEBCONF_DEBUG=developer dpkg --configure -a' instead
<cjwatson> (assuming they haven't already destroyed the evidence, which is quite possible)
<cjwatson> tkamppeter: upload> wait a bit and check whether the upload actually succeeded anyway.  This is a known problem
<tkamppeter> cjwatson, in that case I will close the bug as invalid. Thanks.
<cjwatson> tkamppeter: well, not until after investigation :)
<tkamppeter> cjwatson, Upload actually arrived and is happily building.
<pitti> tkamppeter: sorry, was at lunch; but seems cjwatson already answered, thanks
<tkamppeter> cjwatson, piiti, bug 850680 updated.
<ubottu> Launchpad bug 850680 in man-db (Ubuntu) "package cups 1.4.6-5ubuntu1.4 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 10 zurÃ¼ck" [Undecided,Incomplete] https://launchpad.net/bugs/850680
<cjwatson> tkamppeter: I know man-db is correct here (audited carefully multiple times); anything like that biting it is a problem in whichever higher-level package manager is in use - so it's worth also finding out which package management frontend they're using
<tkamppeter> cjwatson, for me it also looks like that this is not a bug of the individual packages as ate least on cups and foomatic-filters the debconf stuff did not get touched for longer time. The package manager frontend seems to be a good candidate here.
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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
<tkamppeter> pitti, I am trying to build GS with liblcms2 on my PPA, all builds fine but d-shlibmove fails: http://paste.ubuntu.com/697232/ How can I fix this?
<tkamppeter> pitti, build-depends is liblcms2-dev, I wonder why this debhelper wants to have liblcms2-2-dev.
<pitti> tkamppeter: I'm afraid I never used or even heard of d-shlibmove :/
<pitti> tkamppeter: perhaps there's an option to tell it that liblcms2-dev is the correct one?
<tkamppeter> pitti, it already uses --ignorelibdep
<tkamppeter> pitti, seems that only solution ius that I also make a PPA version of libcms2, providing liblcms2-2-dev in addition, as liblcms2-dev is a non-standard.
<pitti> tkamppeter: liblcms2-dev is a standard name
<tkamppeter> pitti, so the bug is in d-shlibmove and/or using d-shlibmove is a non-standard.
<pitti> right, or the invocation of d-shlibmove needs to be updated for lcms2
<didrocks> mvo: thanks for the apt fix!
<xranby> hi i would like to package a Upstart script that enables zram swap on bootup  for low ram systems such as the ac100 laptop. any pointers where to begin?  create a package and upload it to a private ppa?
<xranby> i have currently only uploaded the script to https://wiki.ubuntu.com/ARM/TEGRA/AC100?action=AttachFile&do=view&target=zramswap.conf
<xranby> it are based on the script provided from http://weirdfellow.wordpress.com/2011/05/04/compressed-ram-with-zram/   and altered to only allicate half of available ram for zram http://weirdfellow.wordpress.com/2011/05/04/compressed-ram-with-zram/
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: mterry, mvo
<mterry> mvo, hi!  we're both pilots, which stuff are you doing, so I can avoid it?
<mvo> mterry: I can take a pilot break now, I just got a s-c bug assigned so that should be fine
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: mterry
<mterry> mvo, OK, happy bug squashing!
<mvo> thnx
<stgraber> SpamapS: hey! can you have a look at bug 856810? I doubt it's related to netcfg of lightdm but looks like related to these upstart network jobs changing recently
<ubottu> Launchpad bug 856810 in netcfg (Ubuntu) "Boot hangs at "Booting system without full network configuration..."" [Undecided,Confirmed] https://launchpad.net/bugs/856810
<pitti> doko: eglibc> where does the huge delta in locale/C-translit.h come from? (not from a patch, inline change)
<doko> pitti, it's a generated file, does get built for every build. you can ignore it
<pitti> ok
<jdstrand> mvo: hey, fyi - it seems that we have another 'apt-get source' bug (859665)
<dobey> cjwatson: ping; can you actually upload lp:ubuntu/ubuntuone-control-panel to the archive? seems you merged a fix in a couple weeks ago, but it hasn't actually been uploaded to archive?
<cjwatson> dobey: I did (as patch pilot), but it was typographical, so there was no reason to upload right away; it was fine for it to wait until somebody had a better reason for an upload
<cjwatson> part of the point of using branches is that we don't need to upload on every change :-)
<dobey> oh ok
<mvo> thanks jdstrand - I check it out
<hunger> Are you guys still in the plan wrt. the oneiric release?
<cjwatson> hunger: I'm not sure what your question means - could you elaborate?
<hunger> cjwatson: Just wondering whether the release might be post-poned.
<ogra_> up to beta2 we were in the plan at least :)
<cjwatson> hunger: I know of no reason why it would be, at the moment.  Why do you ask?
<hunger> Just tried the beta 2 and that made me wonder. Never have seen such a buggy beta release of you guys yet.
<cjwatson> Thankss.
<ogra_> hunger, you just test the wrong architecture ... use arm... compared to natty the beta is 33.2% less buggy :)
<hunger> cjwatson: Sorry. All the betas of previous releases were rather solid. Oneiric is the first I had to remove again since it is plain unusable.
<cjwatson> Well, it's not the most productive way to put it.  It's a rather big distribution and you provide no particular indication of which bits are problematic.
<cjwatson> (And in any case this is not the right forum for that, unless you have fixes)
<hunger> cjwatson: Shutdown not working anymore, random screen freezes, menu not showing up for some apps at all, that gear thing on the far left vanishing randomly.
<hunger> cjwatson: ... window manager having to restart, unity dash not opening after a while, ...
<ogra_> did you file bugs for all these issues ?
<hunger> cjwatson: And all that on a run-of-the-mill netbook HW.
<hunger> ogra_: Not yet.
<seb128> half of those are known and being worked
<hunger> seb128: Good:-)
<seb128> bug #854292
<ubottu> Launchpad bug 854292 in Unity Foundations "indicator-session power menu disappears after running update-manager or apt-get" [Critical,Confirmed] https://launchpad.net/bugs/854292
<seb128> that's the "gear" one
 * cjwatson has nothing to do with any of those.  I guess I'll go back to introducing^Wfixing bugs somewhere else.
<seb128> is shutdown not working from the login screen?
<hunger> seb128: Not even shutdown -h now works:-(
<seb128> ok, dunno then
 * hunger should probably just file bug reports and shut up to not keep you guys from fixing bugs.
<hunger> seb128: bug #854292 is not the one I am seeing. I did not run apt-get or anything.
<ubottu> Launchpad bug 854292 in Unity Foundations "indicator-session power menu disappears after running update-manager or apt-get" [Critical,Confirmed] https://launchpad.net/bugs/854292
<seb128> hunger, you didn't use update-manager?
<seb128> hunger, well it's most likely the same issue but maybe triggered a different way
<hunger> seb128: I got the CD and installed that. Logged in and played a bit, starting apps, etc.
<hunger> seb128: I did not update... did not notice any updater poping up either.
<seb128> hunger, well maybe it has nothing to do with updates, updates seemed something that come often close from the issue
<seb128> hunger, but anyway likely the same bug as I said, it might just happen under different conditions
<hunger> seb128: Great. One bug less for me to file:-)
<cjwatson> hunger: it's not so much keeping us from fixing bugs, but that "your work sucks" is pretty demotivating.
<cjwatson> Constructive contributions are way better, and welcomed
<hunger> cjwatson: Sorry.
<hunger> cjwatson: unity is turning out rather nice in oneiric.
 * cjwatson has nothing to do with unity, for the avoidance of doubt
<hunger> cjwatson: Just wanted to say something positive, too:-)
<cjwatson> I'm not asking for praise either; by constructive I mean helping out with the problems
<tkamppeter> pitti, I have a solution for the GS/lcms2 problem: I am removing d-shlibmove. d-shlibmove seems to be rarely used. Only GS and jbig2dec are the d-shlibmove-using packages from the ones whose source I have on my laptop.
<hunger> cjwatson: I understand that position, but it is rather hard to debug all this stuff. I can file bug reports, but that is where it ends for me.
<OdyX> hunger: filing useful bugs (with as much information as possible, reproducing-steps, precise description of what fails for you) _is_ important.
<hunger> OdyX: I know. But I don't think I can provide reproducing steps, etc. :-(
<tseliot> pitti: did you see my message about bug #855396 (which is not fixed yet, despite our work)?
<ubottu> Launchpad bug 855396 in jockey (Ubuntu) "Jockey doesn't provide fglrx-updates" [High,Triaged] https://launchpad.net/bugs/855396
<jono> seb128, didrocks quick q: have you come across a bug where USB devices (e.g. webcams, headsets) don't appear in the sound settings capplet seemingly after a suspend?
<seb128> jono, I didn't
<jono> seb128, ok I will file a bug
<seb128> jono, seems like a pulseaudio issue
<jono> seb128, yup, lsusb sees the devices
<jono> I will file it against pulse
<didrocks> jono: I didn't as well
<jono> thanks guys
<jono> will file it soon, on a call now
<didrocks> sure, thanks :)
<seb128> jono, try asking diwic about it
<jono> seb128, will do
<pitti> tseliot: ah, thanks; reopening then
<pitti> will have a look
<tseliot> pitti: thanks (I've also added a log)
<SpamapS> stgraber: ack, looking now
<SpamapS> stgraber: at the point where that message is displayed, the system is pretty much guaranteed to enter runlevel 2.. so its a bit of a red herring that this message is showing when other things fail to come up.
<SpamapS> Hmm... lightdm stop son runlevel [016] , but also starts on runlevel [!06]
<jdstrand> bdmurray: fyi, mvo said he was looking at 859665
<jdstrand> bdmurray: but I still responded to your question
<bdmurray> jdstrand: okay thanks
<slangasek> apw: does bug #855764 make sense to you at this point?  Is there anything you would like me to test to help narrow this down?
<ubottu> Launchpad bug 855764 in linux (Ubuntu) "text console between grub and plymouth in oneiric, with current grub" [Undecided,Confirmed] https://launchpad.net/bugs/855764
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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> smoser: hah, so the udevadm settle had *no* effect on finding /dev/console?
<smoser> well, 0/329 for control
<smoser> 0/500+ for udevadm settle
<smoser> so unable to get any real data.
<slangasek> smoser: but then 1/1 on each when you ran it on a different cloud?
<smoser> but its all just racy. depends on cpu to disk speed ratio.
<smoser> right.
<smoser> i can setup tests on the cloud where we get hits and try again.
<slangasek> smoser: in that case, can I ask you to modify /init in the initramfs to check for ${rootmnt}/dev/console existence right before calling run-init, and if it's missing, to dump /dev/.udev.log to the terminal?
<slangasek> I'd like to see what it is udev is doing
<smoser> yeah. i can do that. just modify that intiramfs a little more.
<smoser> what i did previously was just take the one image and publish a "pure beta-2"
<smoser> then i mounted fs loopback and just re-packed the existing initramfs and put it back into the image and published the modified
<smoser> so the only file different in the 2 images was the initramfs
<smoser> so... i will try to get some runs with that. on the reproducing cloud.
<SpamapS> Hrm, so I'm having trouble with dh_python2 ..
<SpamapS> When there's only one package in debian/control .. it automatically just shoves all of debian/tmp into the package..
<SpamapS> but when there are two.. its not putting the python modules anywhere..
<tumbleweed> that's not dh_python2's job
<SpamapS> oh, it scans the packages after?
<SpamapS> that makes sense actually.. good point
<tumbleweed> yes
<tumbleweed> also normally when there's only one package, there is no debian/tmp
<SpamapS> right, there isn't.. it all makes sense now
<SpamapS> was over thinking the problem entirely
<tumbleweed> :)
<crass> what's the right channel for getting help with a packaging issue for my personal ppa?
<nigelb> Probably #ubuntu-packaging
<crass> ok, thanks
<lynxman> SpamapS: ping
<SpamapS> lynxman: pong, sup?
<lynxman> SpamapS: hey sorry to bother you, any idea what we're doing about rabbitmq for oneiric? Are we pushing to 2.6.0? Just wondering because I'm maintaining rabbitmq-stomp and rabbitmq-erlang-client and they'll need updating too
<SpamapS> lynxman: its way too late for that I'm afraid. :-/
<SpamapS> lynxman: if I had been able to jump on it right away it might have gotten done, but that was a month ago. :(
<lynxman> SpamapS: cool, no problem at all, was just wondering
<lynxman> SpamapS: since there was a bit of conclicting info in the sprint :)
<lynxman> SpamapS: thanks for the clarification ;)
<lynxman> SpamapS: also if you want I can do 2.6.0 myself and push it in a ppa or something, got used to it
<SpamapS> lynxman: have the debian maintainers shown any movement on it?
<lynxman> SpamapS: fraid not
<lynxman> SpamapS: I can do it and push it back to them though
<lynxman> SpamapS: since I'm already trying to push rabbitmq-stomp and rabbitmq-erlang-client back to debian anyway
<SpamapS> lynxman: ok, thats fine.. sounds like we should move forward with 2.6.0 in a PPA and maybe help them out if they get stuck with it.
<SpamapS> lynxman: ideally you'd maintain them in Debian.. :)
<lynxman> SpamapS: heh, I'm trying for mcollective but since I'm unknown in Debian... :)
<SpamapS> lynxman: this is precisely how you get known in Debian.
<lynxman> SpamapS: I'll ask for some guidance for that then, let me try first to iron out the 2.6.0 properly :)
<smoser> slangasek, i was reading back above
<smoser>  "can I ask you to modify /init in the initramfs to check for ${rootmnt}/dev/console existence right before calling run-init, and if it's missing, to dump /dev/.udev.log"
<smoser> i'm guessing you want to back out the udevadm settle,t hen, right ?
<smoser> and basically just panic with more debug
<slangasek> smoser: I'd like to see it with both bits present
<smoser> hm... but you're very much less likely to see the udev debug if we add the udevadm settle, no ?
<smoser> and possibly that would "fix" our issue, meaning you'd *never* see that debug output
<slangasek> smoser: I was assuming you'd run this on the system where you got 1 for 1 on failures
<smoser> well, its not completely 1x1, but its closer.
<smoser> but my argument is still that the udev.initramfs-bottom change will make us not hit the udev debug stuff.
<slangasek> smoser: oh, I misread your last comment in bug #833783 - I thought you had said running on CanoniStack, you saw the error both with *and* without the udevadm settle change
<ubottu> Launchpad bug 833783 in udev (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Incomplete] https://launchpad.net/bugs/833783
<smoser> i was not able to add the image on canonistack. i've only ever seen it on the control there.
<slangasek> smoser: ok, so testing this fix on CanoniStack is impractical?
<smoser> no i think its reasonable. we can test it there.
<smoser> the only reason i did not is that ther eis a bug that means i have to tap someone in IS's shoulder every time i upload an image
<smoser> (bug 845788 bug 851059 are fixed now, but they're on older version)
<ubottu> Launchpad bug 845788 in Glance "update_image in glance.client doesn't add content-length so the swift backend can't chunk" [High,Fix released] https://launchpad.net/bugs/845788
<ubottu> Launchpad bug 845788 in Glance "duplicate for #851059 update_image in glance.client doesn't add content-length so the swift backend can't chunk" [High,Fix released] https://launchpad.net/bugs/845788
<smoser> and fwiw, i'm pretty sure that the change that made me *not* see it on my developer system was bug 837100 being fixed.
<ubottu> Launchpad bug 837100 in OpenStack Compute (nova) "nova does not uncompress qcow compressed images" [Wishlist,Fix released] https://launchpad.net/bugs/837100
<slangasek> smoser: I would appreciate it if you could test the proposed fix on CanoniStack; I don't want to push the change without some evidence that it makes things better, and so far we don't have any evidence of that
<smoser> ok. i'll test there.
<kirkland> cjwatson: howdy!  how do we actually take advantage of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605614 ?
<ubottu> Debian bug 605614 in busybox "debian-installer: Ability to configure remote syslog" [Wishlist,Fixed]
<kirkland> cjwatson: ie, how/where do we pass the installing guest the hostname of the rsyslog server?
<kirkland> cjwatson: in a preseed or a kernel cmdline?
<cjwatson> kirkland: it's been in Ubuntu for years ...
<cjwatson> kirkland: log_host= and log_port= on the kernel command line
<kirkland> cjwatson: perfect, thanks!
<cjwatson> log_port is optional, it defaults to whatever the default syslog port is (I forget)
<kirkland> cjwatson: np
<micahg> I assume Bug #859223  should be won't fix?
<ubottu> Launchpad bug 859223 in libnotify (Ubuntu) "libnotify1 missing from oneiric" [Undecided,New] https://launchpad.net/bugs/859223
<slangasek> micahg: definitely
<cnd> I upgraded a natty machine to oneiric, and I no longer have a "classic" mode option at login
<cnd> how do I get that back?
<jtaylor> there is no classic anymore, only gnome3 unity xfce and lubuntu (openbox + something)
<cnd> ok
<bryceh> cnd, install gnome-panel
<seb128> or gnome-session-fallback
<cnd> bryceh, gnome-panel worked
<cnd> thanks!
<Sweetshark> jasoncwarner_: ping?
<jasoncwarner_> Sweetshark: hey!
<Sweetshark> Ho!
#ubuntu-devel 2011-09-27
<RAOF> Ahem.  "if (unity_running () && (width < max_texture_size || height < max_texture_size)) throw_error;".  Spot the *tiny* thinko. :)
<ajmitch> heh
<ajmitch> just a small < vs >? :)
<broder> i was going to go with the lack of multiplication
 * ajmitch guesses that the check was meant to be for width or height being larger than the max texture size
<RAOF> ajmitch wins a cookie.
<RAOF> broder: What multiplication would be needed there?
<slangasek> if max_texture_size measured area rather than linear size, I guess
<broder> oh, is it a restriction on each dimension? i thought it was area
<ajmitch> isn't the texture usually square, like 2048*2048?
<mwhudson> the texture is usually the same size as your monitor
<mwhudson> i think?
<mwhudson> well, the smallest rectangle that covers all your displays
<ajmitch> right, I mean the max size is usually square from what little I know
<mwhudson> ah yeah
<mwhudson> ah memories of not being able to run my laptop display and my external monitor at the same time
<RAOF> Yeah, it's a restriction on max linear dimension.
<RAOF> So my netbook + 24" monitor stacked vertically works fine, but breaks stacked horizontally.
<ajmitch> that would be a pain :)
<RAOF> Well, fortunately I only ever use my netbook for testing this sort of breakage :)
<tjaalton> is there a way to avoid using a static dependency on a library, if the package needs to strictly depend on the version it was built against?
<tjaalton> looks like ${shlibs:Depends} doesn't use the version that build-dep has set
<infinity> tjaalton: Why would you need that?
<infinity> tjaalton: If the library isn't ABI compatible with the version in shlibdeps, that's a bug.
<tjaalton> infinity: yes, libldb is such a piece, breaks sssd every time it's updated
<tjaalton> so sssd needs to depend on the version it was built against
<infinity> Erm.
<tjaalton> but the problem is that the libldb upstream don't think that way
<infinity> Is it really changing symbols but not revving the SOVER?
<tjaalton> see bug 746981
<ubottu> Launchpad bug 746981 in sssd (Ubuntu Oneiric) "sssd fails to find memberof.so" [High,In progress] https://launchpad.net/bugs/746981
<infinity> If so, then it either (A) shouldn't be a shared library, (B) we should be revving the SOVER ourselves or, (C) as a hackish and gross workaround, we should be revving the shlibs at the very least.
<tjaalton> sssd in fedora depends on the version it was built against, but yes it would be better to fix in libldb instead :)
<tjaalton> jelmer: ^ ?
<tjaalton> infinity: would an acceptable band-aid for oneiric be to just rebuild sssd, and postpone the real fix for later? I have a couple of other fixes pending for it too
<infinity> tjaalton: I guess I'd like to understand what's really going on here.  Is sssd relying on internal symbols in the unversioned modules?
<infinity> tjaalton: But yeah, a reasonable bandaid would be just recompiling all of the libldb1 revdeps after new versions are built and installed on all arches. :/
<infinity> tjaalton: Not an ideal long-term solution.  I suspect one or more upstreams need a smack.
<pitti> Good morning
<tjaalton> infinity: from chatting with upstream my understanding is this; libldb provides a plugin interface that sssd uses, but the ldb upstream (=samba) thinks all the plugins should be built in-tree
<tjaalton> so the one that sssd provides for its own use breaks every time ldb is updated
<infinity> Oh, the plugin is shipped by sssd.  I see.
<tjaalton> right
<infinity> I used to deal with plugin ABI messes like this with PHP by offering a virtual package as a dependency.
<infinity> libldb could do something similar.  libldb-plugin-abi-20110902, or whatever.
<infinity> And have packages that compile plugins depend on that.
<tjaalton> yeah, good idea
<StevenK> infinity: Ew, PHP.
<infinity> StevenK: Shush.
<infinity> StevenK: linda.
<StevenK> What was wrong with Linda?
<infinity> It was a gateway drug to Launchpad.
<infinity> And don't deny it.
<StevenK> But they were *years* apart ...
<infinity> Shows how deeply it affected you.
<infinity> tjaalton: Anyhow, if the library ABI is stable, but the plugin interface isn't (which is icky, but whatever), that seems like a vaguely sensible approach.
<infinity> tjaalton: If those are the only two packages affected, I can help you whip something like that up.  If it's a larger set, I say go for the rebuild bandaid and do it better later.
<tjaalton> infinity: yeah, maybe I'll just open a bug about it and go for the bandaid for now
<tjaalton> openchange, samba4 and sssd are the only ones build-depending on libldb-dev
<infinity> But how many build plugins?
<tjaalton> maybe just sssd :)
<infinity> Since I suspect that's all that breaks.
<infinity> If the library ABI breaks too, upstream just needs some extreme violence.
<infinity> But samba.org tends to be slightly more sane than that.
<tjaalton> well the shlibs suggests that it's been stable since 0.9.21
<infinity> Unless the Debian maintainer is wrong. :P
<tjaalton> hah, right
<infinity> If he's using a symbol checker though, then yeah.
<infinity> Which I believe dh* now does by default if you include a .symbols file.
<infinity> Which makes it dirt easy, even if you don't really understand how it all works.
<tjaalton> yep, it's there
<infinity> Yeah, band-aid rebuild away then for now, but I'd work with the Debian maintainer to add a libldb-plugin-abi-$uniquestring Provides to libldb1, ideally a string yanked from the headers somewhere, so that people who build-dep on libldb-dev can pull the same string and Depends: on it.
<infinity> (And only people building plugins should need to worry about that black magic, from the looks of it)
<infinity> Which might just be sssd, as you say. :P
<tjaalton> yep :)
<didrocks> good morning
<dholbach> good morning
<jamespage> morning all
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: jamespage
<apw> slangasek, that looks like a mode switch flash to me, feels very much that the panel goes properly black a common sign of one
<slangasek> apw: ok.  any ideas why I'd be getting a mode switch there, given the information gathered so far?  any recommendations on how to further track it down?
<apw> slangasek, well that is where i'd expect there to be one, pretty much always
<slangasek> apw: eh? why should there be any mode switching?
<slangasek> grub already hands it off in the preferred mode
<slangasek> and plymouth is supposed to pick it up and run with it in the same mode
<apw> slangasek, generally we have to reprogram from BIOS planar mode into a performant *missingword* mode
<slangasek> apw: oh, blah
<slangasek> it works on radeon without that, though
<apw> slangasek, hmm i wonder how it is rejigging the layout without you seeing
<apw> slangasek, perhaps you could get a boot with drm.debug=0x4 for me, which should tell us what the mode switch is
<slangasek> apw: sure, happy to
<apw> slangasek, TILED ... thought i was going mad, from planar to tiled framebuffer
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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:
<jamespage> biab
<slangasek> apw: what bits of this drm.debug=0x4 output do you need?  should I just grep drm /var/log/kern.log and send it on?
<apw> slangasek, or attache a dmesg from the boot with it on
<slangasek> apw: sent
<slangasek> (to the bug)
<hrw> I have a new version of package to upload to universe. but it has new binary packages so normally it would end in NEW queue. But will it be accepted at all once we passed Beta?
<janimo> hrw, FFE is not  needed for new binaries from a source that was already accepted
<janimo> so I think you're ok
<hrw> janimo: but this is multilib capable cross compiler so it is new feature too - ffe or not?
<janimo> hrw, hmm, the you'd need to ask some of the toolchain people. It is a new feature but probably worthy of a FFE
<hrw> ok, will then wait for doko
<janimo> so file a bug with FFE in the subject, say why it is needed and subscriobe the ubuntu-release team to it
<hrw> thx
<janimo> and then maybe ping people to review/discuss it with you
<Daviey> jhunt: Good morning!  Have you had a chance to look at the udev woes (race)?
<Daviey> (bug 818177)
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
<jhunt> Daviey: been away for a week but looking @ that today.
<Daviey> jhunt: The world has been failing apart with you gone, glad you are back :)
<linuxboy> can I ask questions about PPAs and thing here?
<linuxboy> I'm struggling to get a package built correctly because of some backports I need
<linuxboy> ppa dependencies is what I need!
<linuxboy> thanks guys!
<apw> slangasek, from what i can see what you have is "state of the art" for intel graphics, am discussing with upstream but KMS current mode pickup and mapping is hard (apparently) cause we have little idea where the framebuffer actually is
<apw> slangasek, was it radeon you said did pickup correctly ?
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: jamespage
<linuxboy> can I get the PPA build script to install an older version of a package?
<pitti> linuxboy: you mean to remove a PPA and restore packages to the standard Ubuntu version?
<pitti> linuxboy: that's "ppa-purge" (the package name and command)
<hrw> bug 860432 - ideas?
<ubottu> Launchpad bug 860432 in multistrap (Ubuntu) "tried to grab repository for wrong architecture " [Undecided,New] https://launchpad.net/bugs/860432
<linuxboy> pitti: I'm building a package against another PPA. But that PPA has lower versions numbers then the packages in lucid, so its installing the new packages and I want the old ones
<jamespage> bdrung: hows eclipse 3.7 looking? do you want me to chase through the asm3 sync yet?
<pitti> linuxboy: that's not easily possible, I'm afraid, as apt always installs the latest version (unless you use pinning)
<linuxboy> pitti: or specify the version with = I assume I can't get the build script to do this?
<pitti> linuxboy: you could try setting the build deps that way, but I still doubt it would work at install time
<linuxboy> pitti: I did, didn't work
<pitti> you should just update the other PPA to newer versions
<linuxboy> pitti: I want older versions :/
<bdrung> jamespage: it works: https://launchpad.net/~eclipse-team/+archive/debian-package and yes :)
<jamespage> bdrung: ack
<tjaalton> uh, so how does one run the traditional su-mode on oneiric?
<tjaalton> ..by adding 'single' to the cmdline
<xranby> tjaalton: try sudo su
<tjaalton> xranby: can't even log in, so need to fix that first ;)
<xranby> tjaalton: i would try boot up from a live cd and chroot into the system you want to fix
<tjaalton> xranby: i replied to my question already and got it working, thanks
<xranby> tjaalton: i am mostly running on arm sytems where we do not have as good interactive  bootloaders like on x86
<jamespage> bdrung: asm3 upgrade ACK'ed and synced from debian
<bdrung> jamespage: now we need a freeze exception for eclipse
<Daviey> barry: Hey, bug 785706.. do you know what the plan is?
<ubottu> Launchpad bug 785706 in cython (Ubuntu) "[MIR] needed (b-d of bzr)" [Undecided,Incomplete] https://launchpad.net/bugs/785706
<cjwatson> Daviey: um, I think that was a false positive of some kind
<cjwatson> hm, bzr build-depends: cython-dbg | python-pyrex, python-pyrex is in main
<cjwatson> oh yes, now I reread the comments
<cjwatson> Daviey: I'll fiddle with the seeds and sort this out
<Daviey> super
<doko> for the p-series we should think about getting cython into main. it's the active project afaik
<janimo> ScottK, shall I reupload glmark2 (or any other rejected package for that matter) after FFe is granted?
 * janimo secretly hopes rejected means - put in a queue serverside where it can be released from with no further intervention from the uploader
<cjwatson> it's certainly possible to accept a previously-rejected package, as long as there weren't subsequently-accepted changes
<janimo> cjwatson, no, no further uploads happened
<cjwatson> Daviey,doko,barry: seeds changed, feel free to revisit cython in P though
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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:
<cjwatson> where do I find the source code that generates http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html ?
<cjwatson> bjf: ^- do you know maybe?
<cjwatson> hmm, looks like lp:ubuntu-reports maybe
<Daviey> cjwatson: try ~ubuntu-defect-analysts/+junk/reports-trunk
<cjwatson> except ... ah
<Daviey> oh wait, that hasn't been touched for a while.
<Daviey> cjwatson: Is it fair to say, bug 776701 should be re-targeted for P?
<ubottu> Launchpad bug 776701 in kickseed (Ubuntu Oneiric) "firewall command not implemented" [Wishlist,Triaged] https://launchpad.net/bugs/776701
<Daviey> and bug 759545 ?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Oneiric) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<alkisg_kubuntu> Hi, it looks like the greek translation for keyboard-configuration debconf dialogs uses the wrong encoding, I only get '???'.
<alkisg_kubuntu> ps aux => whiptail --backtitle Î¡ÏÎ¸Î¼Î¹ÏÎ· ÏÎ¿Ï ÏÎ±ÎºÎ­ÏÎ¿Ï --title Î¡ÏÎ¸Î¼Î¹ÏÎ· ÏÎ¿Ï keyboard-configuration --output-fd 12 --msgbox ???? ?????????????????????? (a very long line with question marks)
<alkisg_kubuntu> Is it a known problem, or should I file a bug about it?
<cjwatson> Daviey: yes
<cjwatson> alkisg: mm, something has gone wrong there, let me look
<cjwatson> not so much wrong encoding as entirely ? (i.e. ASCII 63)
<cjwatson> Persian, Hebrew, Punjabi, and Traditional Chinese all have the same problem
<alkisg> Does it use a .mo file to get the translations? Or is it in a debconf file?
<alkisg> Ah
<cjwatson> alkisg: could you please file a bug?
<cjwatson> debconf
<alkisg> Against keyboard-configuration? Sure, thanks
<cjwatson> yes (well, console-setup)
<cjwatson> assign it to me
<alkisg> Will do, ty
<cjwatson> it was fixed in console-setup 1.68 in Debian
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609624
<ubottu> Debian bug 609624 in console-setup "console-setup: Broken Greek translation" [Serious,Fixed]
<seif> dholbach, there?
<seif> u got mail from me
<cjwatson> it would be good if "you've got mail from me" type things were in private messages rather than on channels, I think
<pitti> apw, ogasawara: cool, today's kernel (-12) gave me a free battery (/sys/class/power_supply/BAT0/); could -13 make it so that it doesn't just have 0 Wh capacity? :-)
<pitti> [    0.865598] ACPI: Battery Slot [BAT0] (battery absent)
<pitti> ah, seems it now parses the ACPI data differently
<pitti> I took out the battery while it's docked
<pitti> but we probably ought to teach upower about this
<apw> pitti, does your doc have the possibility of a battery, also is your lappy one of those which can take a battery in the CD rom space
<pitti> apw: neither
<apw> that does seem odd then
<pitti> apw: it's not a real biggie, I just noticed that because I'm currently doing a fix for control-center's power applet and wondered why it shows the battery settings
<ogasawara> apw: even more odd in the fact that I don't recall any of the patches we applied to -13 being related to power
<pitti> ogasawara: -13? I just got upgraded to -12 today
<ogasawara> pitti: sorry, meant -12
<apw> ogasawara, no me either, i wonder if its just to do with being docked without the battery on reboot or somthing
<pitti> apw: I don't think so; I haven't changed this for ages
<apw> but yeah -11 -> -12 was a small set of changes ...
<smoser> Daviey, bug 810019 also affected pastedeploy.
<ubottu> Launchpad bug 810019 in distribute (Debian) "UserWarning printed on import pkg_resources'" [Unknown,New] https://launchpad.net/bugs/810019
<smoser> if we don't get that fixed, we'll see the same issue
<smoser> iirc
<Daviey> crap
<Daviey> smoser: it's fixed in Debian
<alkisg> cjwatson: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/860562 => thanks again
<ubottu> Ubuntu bug 860562 in console-setup (Ubuntu) "Wrong encoding in keyboard-configuration debconf dialogs" [Undecided,New]
<smoser> right. we need request sync for 1.6.0-2 from unstable
<smoser> er... 1.5.0
<cjwatson> alkisg: ta, will get that sorted
* tahnok changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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:
<ogra_> gar, why does dh_autoreconf pull git onto my disk now
<juliank> ogra_: You installed with recommends enabled. dh-autoreconf recommends autopoint which depends on git
<ogra_> bah, PEBCAK
<ogra_> thanks
<juliank> ogra_: Apparently, autopoint may checkout a specific git version of gettext if requested in configure.ac and copy that into your package tree
<juliank> It's totally insane and if it happens at build-time, breaks things
<ogra_> grmbl ... i really hate if packages run autoreconf in the clean target
<smoser> Daviey, are you going to request sync of pastedeploy 1.5.0-2 ? or should i.
<Laney> and pastewebkit
<pitti> cjwatson: with the new ubuntu-defaults-zh-cn, we can actually build the chinese images out of main now, BTW
<pitti> cjwatson: not sure whether this would give us any extra space savings? (we already remove the apt indexes)
<pitti> erm, except for the defaults package itself; I guess that'd be a trivial MIR, though
<cjwatson> oh, cool.  hm, requires a BuildLiveCD change which requires an RT
<cjwatson> so maybe let's not bother if it's not required
<pitti> right, as component-mismatches already ought to point out main->universe depends, it shouldn't actually pull in anything from universe now
<Daviey> smoser: i already had...
<Daviey> i haven't done pastewebkit... has anyone else?
 * Daviey JFDI
<jelmer> barry: ping
<barry> jelmer: pong
<dholbach> seif, yep, investigating
<dholbach> kenvandine, happy birthday
<kenvandine> dholbach, thx!
<bjf> cjwatson: git://kernel.ubuntu.com/bradf/ubuntu-bug-report-kit
<bjf> cjwatson, any particular reason ?
<cjwatson> bjf: want to fix a bug in it, there's a task showing up that shouldn't
<bjf> cjwatson, which?
<cjwatson> bjf: bug 790240, all of whose oneiric tasks are either Won't Fix or Fix Released
<ubottu> Launchpad bug 790240 in java-access-bridge (Ubuntu) "at-spi needs demotion for oneiric (at-spi2-core in main)" [High,Triaged] https://launchpad.net/bugs/790240
<bjf> cjwatson, i'll fix it
<cjwatson> bjf: cool, thanks!
<pitti> apw, ogasawara: ah, might not actually be the -12 upgrade; my machine just suspended itself over lunch break, and after resuming there's often some battery confusion (bug 852406)
<ubottu> Launchpad bug 852406 in linux (Ubuntu) "Phantom battery appears after resume from suspend" [Undecided,Confirmed] https://launchpad.net/bugs/852406
<pitti> apw, ogasawara: so I don't think it's new after all, sorry for the confusion
<apw> pitti, ahh the "coool" random changing of your user options without asking effect
<pitti> apw: it's being fixed
<pitti> apw: we didn't notice the bad default until yesterday, when gnome was actually fixed to exercise that default
<ogra_> does gnome actually keep it that way ?
<pitti> yes, seems they are quite eager to impose suspend everywhere
<ogra_> oh my
<ogra_> evil
<pitti> in gnome upstream, you can't configure lid action, suspend on idle is 30 min regardless of AC state, you can't configure the power button, power button always suspends, etc.
<ogra_> sigh
<pitti> takes some catching up on our side :)
<apw> (and suspend if you hit return ?)
<pitti> no, the S key
<apw> that'd work there is no S in gnome
<ogra_> the e key would have been more effective though
<bdmurray> pitti: I've an apport merge proposal https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/bug-856826/+merge/77022
<ubottu> Ubuntu bug 77022 in linux-restricted-modules-2.6.20 (Ubuntu) "having nvidia-glx installed messes up i810 dri" [Undecided,Won't fix]
<tahnok> is it safe to run apt-get upgrade on the beta releases?
<astraljava> Interesting question from someone running a beta release in the first place.
<pitti> bdmurray: saw it, will get to it ASAP
<ScottK> janimo: I can accept the upload from Sept 23.  Where's the FFe?
<ScottK> (I just woke up, so I don't yet have any recollection of past decisions, including most especially ones I made)
<cjwatson> I might as well be a stateless automaton shortly after waking up
<cjwatson> I often have entire conversations I don't recall later
<ogra_> heh
<cyphermox> cjwatson: do you know much about libnl? I'm trying to figure out why it won't list the routes I'm expecting it to (which is really the cause for bug 856333)
<ubottu> Launchpad bug 856333 in network-manager (Ubuntu) "(oneiric) wired connection unnaturally slow" [Medium,In progress] https://launchpad.net/bugs/856333
<cjwatson> cyphermox: really nothing at all
<cyphermox> d'oh
<cjwatson> I think I poked it for libnl3 or something, but that was all superficial
<cyphermox> it's why I was asking, hoping you had tricks or something :)
<cyphermox> thanks anyway
<doko> bdrung, is there an eclipse 3.7 FFe report?
<slangasek> apw: yeah, a radeom is doing this right, in comparison
<janimo> ScottK, it is a FFe you acked yesteday but I can dig it up I guess. The only one on glmark2
<doko> slomo, ping
<ScottK> janimo: Found it.
<ScottK> janimo: Done.
<tkamppeter> agateau, one question: Will the fix for the hp-systray icon not appearing on login be completely in sni-qt or will you also need to supply another patch for HPLIP?
<agateau> tkamppeter: it's going to be in Qt itself actually
 * agateau fears didrocks will hate him for that
<tkamppeter> agateau, so I will upload HPLIP now so that tomorrow there will not be such a big package approval traffic jam.
<tkamppeter> agateau, what takes care that sni-qt is installed on a system. Is it seeded?
<agateau> tkamppeter: I am not sure about this, didrocks knows better
<tkamppeter> didrocks, do you know about what takes sni-qt into an installed system?
<janimo> ScottK, thanks
 * agateau needs to go
<hallyn> GAH!  why do package upgrades keep resetting my 'suspend on lid close' setting?
<pitti> hallyn: they are not supposed to..
<pitti> gsettings list-recursively org.gnome.settings-daemon.plugins.power  | grep lid
<pitti> hallyn: a package upgrade has little influence on that actually; does this happen when you restart your session rather?
<seb128> hallyn, what does it change from to?
<pitti> good night everyone
<pitti> hallyn: (will read backscroll tomorrow morning)
<ScottK> agateau: We have a planned Qt upload tomorrow.  Please coordinate with didrocks about what you need in it.
<tkamppeter> agateau, HPLIP is uploaded (pitti, can you approve?)
<hallyn> pitti: seb128: I just reset them again, but will check gsettings list-recursively org.gnome.settings-daemon.plugins.power  | grep lid after i log out+back in to see if that' sit
<hallyn> pitti: seb128: it might be worth noting that during the package upgrades last night, it also un-set my keyboard preference for caps-lock as another control (in the middle of the upgrade).  So maybe something went awry with gnome settings altogether
<hallyn> (but that didn't make me lose data :)
<didrocks> tkamppeter: it's seeded directly
<didrocks> agateau: what ScottK told ^
<didrocks> ScottK: I won't upload before we are in sync about it, no worry (I was tracking this small french guy, I was sure he had something to hide! ;))
<tkamppeter> didrocks, thanks.
<didrocks> tkamppeter: yw
<bdrung> doko: not yet
<doko> bdrung, jamespage did bring the required asm3 into oneiric
<bdrung> yes
<bdrung> let me file the freeze exception request
<bdrung> doko: bug #860723 - did i forget something?
<ubottu> Launchpad bug 860723 in eclipse (Ubuntu) "[FFe] Upgrade eclipse to 3.7.0" [Undecided,New] https://launchpad.net/bugs/860723
<doko> it's enough for me, now maybe pester pitti?
<doko> bdrung, ^^^
<bdrung> pitti: ^^ :)
<doko> https://launchpadlibrarian.net/81207327/buildlog_ubuntu-oneiric-armel.xzgv_0.9%2Bsvn40-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> seb128, pitti: which gtk/gnome libary causes these build failures?
<doko> it's not the only one, and I think it's too late for such changes. please could you consider reverting this?
<seb128> doko, no idea
<mdeslaur> slangasek: heh, thanks for the flashplugin-nonfree mess cleanup
<mdeslaur> slangasek: oh, hrm, except I think you've broken flashplugin-installer on i386 since it doesn't pull in nspluginwrapper
<mdeslaur> slangasek: I suspect people are running the stupid "flash fixer" firefox plugin that does a rm  /var/lib/flashplugin-installer/*, but added the versioned dependency on flashplugin-downloader as you did should take care of that
<mdeslaur> s/added/adding/
 * micahg wonders how a firefox plugin can rm anything in /var/lib
<mdeslaur> micahg: it spawns a sudo script and asks the user to authenticate
<micahg> mdeslaur: we shouldn't allow that
<mdeslaur> micahg: not sure what you mean by that
<micahg> mdeslaur: we shouldn't allow addons to spawn a sudo anything
<SpamapS> micahg: people shouldn't blindly type their password in either. :)
<mdeslaur> micahg: I'm not sure how you can restrict that
<SpamapS> apparmor?
<micahg> mdeslaur: apparmor in by default in 12.04? :)
<micahg> s/in/on/
<mdeslaur> micahg: lol
<mdeslaur> micahg: we should just block browser plugins :)
<micahg> mdeslaur: we dropped them from the archive already :D
<slangasek> mdeslaur: oh blast, I missed that the nspluginwrapper dep was arch-dependent
<mdeslaur> slangasek: heh, it's a can of worms :)
<slangasek> mdeslaur: yeah, I guess that should be made conditional again on nspluginwrapper presence, at least on x86
<slangasek> er, i386
<slangasek> mdeslaur: are you re-fixing that then, or shall I?
<mdeslaur> slangasek: please go ahead
<mdeslaur> slangasek: moving the nspluginwrapper alternative to flashplugin-installer is a good idea, btw
<micahg> hmm, flashplugin-installer I thought was i386 only
<micahg> oh, sorry, that's the downloader
<mdeslaur> micahg: no, flashplugin-downloader is i386 only
<mdeslaur> and thankfully this all gets rewritten and simplified in a month when flash 11 comes out
<slangasek> mdeslaur: while I'm at it, I'm going to clean up this use of update-alternatives --set, which should never be called from a package
<slangasek> and do a bit of resetting with --auto
<mdeslaur> slangasek: I think you can get rid of the "if readlink /etc/alternatives/"$p-flashplugin" | grep -c flashplugin-nonfree" part too...I think flashplugin-nonfree is way past our supported releases
<slangasek> mdeslaur: yes, that'll get cleaned up as a side-effect
<mdeslaur> oh, that's the --set part you meant, got it
<doko> persia, do you know about the history of foo-plugins?
<slomo> doko: pong?
<doko> slomo, \o/
<doko> slomo, any idea about bug https://launchpad.net/bugs/749262
<ubottu> Ubuntu bug 749262 in gst-buzztard (Ubuntu Oneiric) "gst-buzztard version 0.5.0-2 failed to build on i386" [High,Confirmed]
<slomo> doko: unfortunately not, it only happens on ubuntu for some reason. i tried to debug it but didn't get any useful results
<doko> slomo, did you try to build without hardening?
<slomo> doko: nope
<stgraber> bdmurray: hey! any plan on making the QA bot aware of people's upload rights? I don't think it makes sense to subscribe sponsors/review team when a coredev (or whoever has upload rights) attaches a patch to a bug (in this case so that others can review it)
<bdmurray> stgraber: that'd require using that tool from the archive admins bzr branch? or the same api calls right?
<stgraber> bdmurray: yeah, you'd need an extra API call to check that. I can probably get you a LP API example of that, I've been poking at that part of the API quite a bit this week
<micahg> bdmurray: can you just make your query exclude where the patch author is a member of ubuntu-dev?
<bdmurray> micahg: that sounds like a reasonable short term solution
<micahg> bdmurray: I think it's a reasonable expectation that if someone is an ubuntu-dev, they should know how to get a patch into the distro
<bdmurray> micahg: would "how to" mean sometimes subscribing the sponsors team so why not ensure mistakes aren't made
<micahg> bdmurray: more noise?  some people make special arrangements for patch review
<Daviey> stgraber: I have a code example for getting upload access for a set..
<Daviey> i use it to generate our team report.
<Daviey> mostly stolen code.
<micahg> bdmurray: sponsors isn't even appropriate in all circumstances, especially this close to release where -release review needs to come first
<stgraber> bdmurray: http://paste.ubuntu.com/698110/
<bdmurray> stgraber: it returns a 403? that seems kind of lame
<Daviey> stgraber / bdmurray: i think it was all stolen, actually - http://pb.daviey.com/EoGw/
<stgraber> Daviey: yep, that looks like a copy/paste of edit_acl.py :)
<stgraber> bdmurray: yeah, I'd have expected "False" instead of a 403
<ajmitch> micahg: it could be good to filter stuff out before inundating the release team
<micahg> ajmitch: that's what the review team was for :P
<micahg> ajmitch: I wasn't suggesting that the bot subscribe the release team
<ajmitch> oh good :)
<bdmurray> okay I've opened a bug regarding this and will work on it sometime
<micahg> I was just saying that an ubuntu-dev should know who to subscribe when
<ajmitch> right, I thought you might have been suggesting that the QA bot do so
<stgraber> Daviey: btw, I also published http://people.canonical.com/~stgraber/package_sets yesterday which likely contains the same thing as your script :)
<ajmitch> which would be a bit painful
<Daviey> stgraber  / Laney : is it a bug that ~developer-membership-board has upload access to sets?
<Daviey> stgraber: that is neat
<Laney> yes, but a small one
<Laney> micahg is fixing it
<stgraber> it's an implementation bug actually. The DMB should just be the owner of the teams and not a member of them
<micahg> yes, I just need to verify with the current owners that the change is ok, and have them make it
<micahg> will try to do that early next week
<bdmurray> micahg: and just because they should doesn't mean they will and having the bug bot act as a safety net seems reasonable to me
<stgraber> in the past the owner would also get the access rights but that got fixed recently in LP, so we can actually have that implemented properly now :)
<Daviey> Talking of which, how did the discussion on fast tracking core-dev's into package sets they already have access to go?
<micahg> bdmurray: I prefer not to get spammed by a bot trying to "help" me, but c'est la vie (sp?)
<Daviey> Laney: ^^ i raised that with you.
<Laney> we have a position statement in the works
<Daviey> micahg: You have procmail, right? ;)
<Daviey> Laney: super
<Laney> it's more general than core-devs and package sets though
<micahg> Daviey: no, I suppose I can filter the bot, but I'd rather see it when someone else attaches a patch so I know something needs to be done
<Daviey> micahg: I'm just glad i've been able to remove my special-case entry for bdmurray
<micahg> heh
<Daviey> He has a maildir just for him, until recently.
 * ajmitch wonders if he can just get procmail to mark those messages as read, while keeping them in the same folder
 * Laney thought "Kryten" was how you spelt that name, if that is indeed who the QA bot is supposed to be ;-)
<Daviey> ajmitch: it's easy to do with mbox, not sure about maildir.
<ajmitch> yeah, I moved away from mbox, a search shows that it's possible with maildir but takes a bit of .procmailrc hackery
<infinity> procmail for maildir and mbox are pretty much identical...
<Daviey> infinity: This doesn't work with maildir iirc ...
<Daviey> :0Wfh
<Daviey> * ^X-Spam-Level: \*\*\*
<Daviey> | formail -I"Status: RO"
<infinity> Oh, indeed, I didn't notice the request was about status changing.
<infinity> Google leads me to this cleverly hackish recipe: http://raamdev.com/using-procmail-to-mark-as-read
<ajmitch> http://blog.freethemallocs.com/wordpress/2008/06/09/procmail-maildir-and-marking-as-read/ implies it has issues
<seb128> does anybody know what updates around 1 or 2 weeks ago could have broken screen output on a dvi monitor for a docked laptop config?
<seb128> it used to work fine, booting with the laptop docked (lid closed or not), now nothing get displayed on screen either the laptop or the external monitor one
<seb128> booting undocked and docking the laptop once it's on lightdm works fine
<seb128> during the boot I see a purple background when I get the bug and the monitor stay on but no image (plymouth or lightdm) is displayed
<seb128> switching to a vt doesn't update the screens either
<infinity> ajmitch: The race on IDLE seems easily worked around.
<seb128> but seems to work since the num lock change
<infinity> ajmitch: But still good to know, should I ever be silly enough to try to do this. :P
<seb128> slangasek, ^ do you know if that could have to do with plymouth?
<stgraber> seb128: what laptop? works fine here on my x201s with a DVI monitor plugged in the docking
<seb128> stgraber, dell e6410
<slangasek> seb128: plymouth can't do anything to your video outputs without the kernel's consent... is this with kms?
<slangasek> binary/free drivers, what video, etc?
<seb128> slangasek, intel i5 card
<seb128> the one integrated to the i5 cpu I mean
<seb128> I've tried to boot the previous kernel without success
<allee> vpnc stopped working in oneiric.  Work before without problems since karmic.  oneiric broken: http://paste.ubuntu.com/698128/   natty working: http://paste.ubuntu.com/698129
<allee> slangasek: ScottK suggested to ask you ^^
 * ScottK thought to blame multi-arch
<slangasek> man
<slangasek> no love
<slangasek> nothing in that log suggests a multiarch problem to me
<slangasek> doesn't mean it isn't, of course
<Laney> one love
<seb128> slangasek, sorry to ping you on that but any suggestion on what I could try reverting for that boot bug out of plymouth and the kernel?
<slangasek> seb128: plymouth has had no code changes at all this cycle... if plymouth itself isn't rendering, I guess you should try an earlier kernel
<seb128> did that
<seb128> did grub changed what it does with video modes?
<slangasek> seb128: hmm.  grub has also changed recently, to properly hand off video to the kernel where it *wasn't* doing so before
<slangasek> seb128: so you could try forcing gfxpayload=text (instead of gfxpayload=$linux_gfx_mode, which tries to autodetect)
<slangasek> seb128: (in your grub boot option)
<seb128> slangasek, thanks, will do that!
<slangasek> seb128: if that fixes it, please file a bug on the kernel
<seb128> slangasek, btw I wonder if my "plymouth hangs for 5 seconds" bug isn't the same issue that bug #854986
<ubottu> Launchpad bug 854986 in xserver-xorg-video-intel (Ubuntu) "[eDP1] 5 second delay between Xorg starting and the greeter starting (Dell Latitude E6410)" [High,Triaged] https://launchpad.net/bugs/854986
<slangasek> seb128: is your netbook using eDP?
<seb128> it's a laptop ... how do I know? ;-)
<slangasek> seb128: is it a Sony?
<seb128> slangasek, no, it's a dell latitude e6 serie as well
<seb128> i.e same as the bug I pointed
<slangasek> seb128: oh.  The last I heard, only Sony and Apple were doing eDP... I guess Dell is now too, hmm
<slangasek> how new is this laptop?
<seb128> 1 year
<slangasek> hrm, ok
<seb128> kern.log.1:Sep 21 10:00:49 localhost kernel: [    3.623298] [drm] failed to retrieve link info, disabling eDP
<slangasek> ah right
<slangasek> so it's lag caused by eDP being present but not used
<slangasek> if you actually *had* eDP, you'd get things like bug #835128 instead ;)
<ubottu> Launchpad bug 835128 in linux (Ubuntu) "Blank display on Vaio Z (VPCZ2) unless I use nomodeset or attach an external monitor" [High,Incomplete] https://launchpad.net/bugs/835128
<seb128> ok, so it does seem a duplicate of the other bug
<seb128> i.e https://bugs.freedesktop.org/show_bug.cgi?id=41057
<ubottu> Freedesktop bug 41057 in Driver/intel "[eDP] 5 second delay between Xorg starting and the greeter starting (Dell Latitude E6410)" [Major,New]
<seb128> it just happens earlier in the boot for me because of the crypted swap I guess
<slangasek> yep, makes sense
<slangasek> seb128: I wonder what vbeinfo from a grub prompt reports when you have the DVI plugged in
<seb128> is that a command I can run from grub in some way?
<slangasek> seb128: hold shift to get a menu, press 'c' to get a prompt, run 'vbeinfo'
<seb128> ok
<seb128> will try the gfxpayload=text when I reboot and get a vbeinfo log
<slangasek> great :)
<seb128> thanks for helping me to debug those issues ;-)
<slangasek> sure thing
<slangasek> (I figure if I help other people debug theirs... maybe apw will find a fix for mine ;D)
<infinity> slangasek: Some misguised sense of karma, or does apw just like it when you're nice?
<slangasek> infinity: apw has more time to work on my bug instead when I'm nice? :)
<slangasek> (maybe?)
<slangasek> anyway, I'm sure he knows I'm good for the beer
<infinity> I'd argue that you're pretty bad for beer.
<infinity> If it had legs and a mouth, the beer would run screaming from you.
 * infinity lunches.
<infinity> (unrelated the screaming beer)
<infinity> s/the/to the/
<slangasek> allee: please try running /usr/lib/NetworkManager/nm-vpnc-service from the commandline and paste the output
<Zack> im having a wlan0 problem
<micahg> slangasek: gnash uses the flashplugin-alternative
<slangasek> micahg: this is a good thing, yes?
<micahg> slangasek: yes, but I got the impression that wasn't considered in your last upload
<cjwatson> sigh, grub/maverick-proposed verification-failed, now I get to debug that again
<Zack> could some one help me fix my wlan0 problem, it wont connect and modprobe does nothing
<slangasek> micahg: ah, the changelog comment, yes
<slangasek> micahg: so there is some possibility that the user had both gnash and flashplugin-nonfree installed, and had manually changed the alternative target away from the default; in that case this upload clobbers that setting
<charlie-tca> Zack: Usually better to ask in #ubuntu for support
<Zack> i did and was sent here
<micahg> slangasek: yep, just wanted to make sure that was considered :)
<slangasek> micahg: however, I don't see any way out of the current broken state that doesn't have *some* casualties, because update-alternatives --set is not meant to ever be called by maintainer scripts and when it is, there's information loss
 * slangasek considers patching u-a to bail if --set is called and DPKG_MAINTSCRIPT_PACKAGE is set
<micahg> slangasek: I'm actually considering dropping the gnash priority back to 10 like Debian has since generally, if someone installs flash, they just want it to work
<slangasek> what's the prio set to currently?
<micahg> slangasek: 50, same as adobe flash
<slangasek> right... I would think gnash should take a lower pro
<slangasek> prio
<micahg> slangasek: ok, I'm planning one more upload before release (there's a crash that should be fixed), so will make the change
<slangasek> cool
<allee> slangasek: /usr/sbin/vpnc: IKE DH Group "1" unsupported.   I've tried the 3 possibilies  1 "2 default" and 5  and  always the same -> unsupported.    I've compared with natty nm-plasmoid and this  combobox with these 3 settings is the only addition in the  UI
<mdeslaur> slangasek: I'm curious, what's the information loss with --set?
<slangasek> allee: ok... that definitely doesn't sound like it's related to multiarch then, I think you'll have to find someone who's actually familiar with vpnc instead
<slangasek> mdeslaur: the information about whether it's a user-selected preference vs. an automatic system-populated default
<mdeslaur> slangasek: ah, I see
<allee> slangasek: okay.  Nevertheless thx for you helping hand so far.  I'll #nm ...  Night
<infinity> siretart: That libav upload seems a bit heavyweight for two days before Final Freeze.
<infinity> siretart: I'm going to reject it for now.  Is there a chance we can get an upload that just had the security fix?
<cjwatson> smoser,smb: do you think it might be remotely feasible for bug 684875 to be fixed in maverick as well?  I'm pretty sure that this is the cause of the maverick verification failure in bug 720558
<ubottu> Launchpad bug 684875 in linux (Ubuntu Natty) "Patch to Natty 2.6.37-virtual breaks non-EC2 users" [High,Fix released] https://launchpad.net/bugs/684875
<ubottu> Launchpad bug 720558 in grub (Ubuntu Natty) "Ubuntu 10.04 currently requires groot= workaround with pvgrub" [High,Fix committed] https://launchpad.net/bugs/720558
<smoser> cjwatson, would you really think it acceptable to change someone's device names on a stable relase kernel upgrade?
<cjwatson> smoser: well, it depends whether it can possibly be working for them at all right now, which I'm not clear on
<cjwatson> if it can only work in EC2, and that deals with it, then ...
<smoser> we don't need it in ec2 any more. and i'm happy we bit that bullet when we did.
<cjwatson> installation of maverick using d-i was very badly broken, which seems like it should limit the set of people who were using the old names
<smoser> but i'm just afraid of changing someone's device names after a reboot and having them hang.
<cjwatson> I agree it's not a trivial change, that's why I asked :)
<cjwatson> I don't see any other safe way to fix the installation problems, though
<smoser> the likely point of failure i think is just in people having '/dev/sdb' in /etc/fstab
<smoser> and no 'nobootwait' option.
<cjwatson> how will people have got maverick on there?
<smoser> ec2
<cjwatson> doesn't that use labels?
<smoser> for root
<cjwatson> or uuids or something?
<smoser> for root it does, but for other disks, those are most likely added by the user.
<smoser> who never expected to have a drive named /dev/xvdX.
<smoser> the other big pain on EC2 at least is that amazon exposes an interface that is ill designed.
<cjwatson> well, they're screwed on upgrade from maverick to natty anyway
<smoser> one where you can say "attach this at /dev/sdg" and the xen guest kernel obliges.  pepole are used to that.
<smoser> yeah, i agree those people are foobarred :-(
<cjwatson> but yeah, in that case we ought to be a bit more careful in the stable release
<cjwatson> gar
<cjwatson> hmm, maverick xen-blkfront /dev/sd* devices have a different major number, according to that bug
<cjwatson> maybe I can abuse that
<cjwatson> since all I think I actually need to do here is say "it's xen-blkfront, don't convert the grub drive to uuids"
<cjwatson> smoser: OK, thanks for the discussion, I think I have a passable workaround in grub
#ubuntu-devel 2011-09-28
<Viper550> Okay, I'm trying to build something with GRUB2 based off a mockup I made, but grub-mkfont spat back at me a whole bunch of gsub errors, and a completely broken font when I get to the grub screen
<infinity> Viper550: You know, the further from 1999 we get, the more obscure your nick gets.
<Viper550> lol
<Viper550> infinity, yeah. I'm trying to construct this. http://i.imgur.com/TgxQv.png
<Viper550> however, grub-mkfont is not cooperating
<infinity> Beer calls.  But I wish you luck.
<pitti> Good morning
<pitti> bdrung, doko: you mean the xzgv FTBFS? looks like a missing -lm?
<pitti> bdrung: looks like eclipse was uploaded and accepted, anything else that needs to be done there?
<soreau> How can I tell what configure options were used when building a certain package?
<sladen> soreau: apt-get source name-of-package
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: pitti
<soreau> sladen: Sorry, it was my understanding that only downloads the source of the package, including ubuntu patches
<pitti> doko: ah, was this the gdk-pixbuf one? seems seb128 reverted the libs.private thing there
<slangasek> soreau: the "source of the package" includes all scripts used to control compilation and installation of the package contents
<soreau> slangasek: Ah ok.. I did not know that
<soreau> slangasek: Specifically, where would I find the configure line though?
<slangasek> soreau: if you want to know the precise configure line used, it's easiest to check the build log
<soreau> slangasek: Which is also included I'm assuming
<slangasek> otherwise, it's somewhere in debian/rules and friends
<soreau> slangasek: The build log isn't jumping out at me from what I can see
<soreau> Where can I find it?
<slangasek> soreau: under the package page on launchpad
<soreau> :P
<slangasek> (it's not part of the source, that would be a bootstrapping paradox)
<slangasek> https://launchpad.net/ubuntu/+source/$pkg, -> click on the version, click on the architecture name, click on the build log
<soreau> ah ha
<soreau> slangasek: thanks
<soreau> found the configure shebang and what I needed to know
<didrocks> good morning
<ScottK> didrocks: Good morning.
<didrocks> hey ScottK
<ScottK> didrocks: Qt did finish on armel, so your way is clear to upload it again.
 * ScottK is off to bed.
<didrocks> ScottK: ok, just waiting some minutes to have some feedback from agateau and then pushing both patches. Thanks for the notice!
<didrocks> ScottK: have a good night
<ScottK> Thanks.
<pitti> sladen: did you see https://launchpadlibrarian.net/81266457/buildlog_ubuntu-oneiric-i386.ubuntu-mono_0.0.35_FAILEDTOBUILD.txt.gz ?
<siretart> infinity: that's a bit sad, because there are a number of IMO quite important issue fixed by this upload. I think I could do a new upload with something like less than 6 patches
<infinity> siretart: Even the crazy 63 upstream cherrypicks, I can deal with, I'm not sure that multi-arching a library without SERIOUS revdep testing when we're this cose to release is safe, though.
<dholbach> good morning
<infinity> siretart: Any chance for an upload with all the upstream fixes, but none of the multiarch scary?  vorlon, doko, and I were all on the same page there.  It's just too late to test if it'll break.
<poolie> hi dholbach
<dholbach> hey poolie
<poolie> doko, congratulations, you are officially affected by more bugs than anyone else in lp
<poolie> (per bug 858618)
<ubottu> Launchpad bug 858618 in Launchpad itself "hard to find bugs that affect you in a project" [Low,In progress] https://launchpad.net/bugs/858618
<infinity> Maybe he's just drawn to green text?
<poolie> or bugs
<infinity> Well, reporters are automagically "affected", right?
<infinity> So, mass FTBFS filings would do it. :P
<poolie> maybe not for api filing
<siretart> infinity: oh, sure, I'll just revert the multiarch commit then
<infinity> siretart: That would be lovely.  Make sure it wasn't several commits (ie: don't let it linger half-baked) :)
<siretart> no, it was implemented in single commit by ceros
<infinity> Shiny.
<dholbach> hey infinity
<infinity> Then give us a non-ma version of the last upload, I'll cringe at the 63 cherrypicks, and let it through.
<dholbach> hey siretart
<dholbach> how are you all doing?
<infinity> Hey Daniel.
<infinity> Sleepy.  You? :)
<dholbach> sleepy too :-P
<dholbach> I hope the coffee is going to fix it :)
<infinity> I've heard claims that it does.
<siretart> dholbach: hey! thanks, I've just returned home on monday from my trip to california (where, among others, I've met infinity at LPC) :-)
<dholbach> nice :)
<infinity> Turns out that siretart's still German.
<infinity> He should really fix that.
<siretart> do we already know the name for the ubuntu p-series?
<siretart> infinity: working on it, but probably requires a job for me in the us
<infinity> siretart: Prepubescent Pterodactyl.
<infinity> siretart: Just to make sure no one can spell it.
<siretart> perfect
<soreau> infinity: Is that a joke or the real name?
<infinity> soreau: A joke. :P
<soreau> infinity: That's a pretty good one in any event
<soreau> how long did it take you to come up with that? :)
<infinity> soreau: A few seconds?
<soreau> infinity: Twas rhetorical but touchÃ©
<doko> poolie, filed by a script, but the fixes are unfortunately non-scriptable ;-P
<infinity> doko: I wouldn't call that unfortunate.  We'd all be out of jobs if we could script things like that. :P
<micahg> infinity: we could do bug fixes instead of build fixes :)
<infinity> micahg: If we can script one, we can script the other. :)
<micahg> infinity: build fixes especially DSO ones seem scriptable in theory
<doko> pitti: new glibmm needed :-/
<pitti> doko: new in what regard?
<pitti> it built fine everywhere?
<pitti> and matching gtkmm3.0 uploaded as well
<doko> pitti, it's stalled everywhere
<pitti> "stalled"?
<doko> according to http://qa.ubuntuwire.org/ftbfs/
<pitti> I don't see glibmm there
<pitti> what do you mean by "stalled"?
<doko> dep-wait
 * pitti is still confused what you mean -- https://launchpad.net/ubuntu/+source/glibmm2.4/2.30.0-0ubuntu1 looks just fine
<jamespage> morning all
<pitti> doko: oh, do you mean the orange gtkmm3.0 there?
<doko> yes
<pitti> doko: it's building on armel, and built on all others
<doko> pitti: re 749159, you're fighting a bot. have fun
<pitti> heh
<seb128> slangasek, hey
<seb128> slangasek, ok, so booting with gfx...=text "fixes" my monitors being screwed when booting docked
<pitti> doko: FYI, retrying ubiquity; looks like the g-i fix that I uploaded a few days ago
<doko> seb128, pitti: please care about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640450, seen in oneiric too
<ubottu> Debian bug 640450 in src:libgnomeprintui "libgnomeprintui: FTBFS: gnome-print-layout-selector.c:528: undefined reference to `ceil'" [Serious,Open]
<pitti> ah, ubiquity builds now
 * pitti throws gobject-introspection FTBFS fix queue-wards
<bdrung> pitti: no
<pitti> ogra, asac: should linux-linaro-vexpress get seeded somewhere? (see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt)
<pitti> kirkland, Daviey: also from component-mismatches, powernap wants to go to universe again; I thought this was meant to be in main/default server instasll?
<Daviey> hmm, i thought i fixed that
<infinity> pitti: It should be pulled in by d-i, I believe, once Colin re-enables that target.
<infinity> pitti: I think.
<Daviey> pitti: should now be fixed
<pitti> Daviey: cheers
<infinity> pitti: I pinged Colin about the d-i/vexpress thing, but I'm heading to bed soon.  Might want to follow up with him and make sure I'm not full of it.
<cjwatson> pitti: yeah, I'm sorting that out now, please leave it in main or it'll make d-i FTBFS
<pitti> cjwatson: oh, I didn't want to demote it; just asking how we want to keep it in main; thanks!
<pitti> cjwatson: ah, seems we missed merging live-build from Debian again; do you mind if I upload a targetted one-line patch to fix bug 857494?
<ubottu> Launchpad bug 857494 in live-build (Ubuntu) "package in config/chroot_packages/ isn't installed in the chroot" [Undecided,Triaged] https://launchpad.net/bugs/857494
<pitti> this is mainly to make ubuntu-defaults-image's --package option work with a local .deb
<cjwatson> pitti: go ahead
<cjwatson> the merge was big and complicated
<pitti> (want to test it again, so still need an hour or so)
<didrocks> pitti: if you want using the french packageâ¦ :-)
<pitti> yeah, a merge at this point would be way too intrusive now
<seb128> cjwatson, hey
<pitti> didrocks: I have a local -ch-zh here, for downsizing; I'll use that for testing
<didrocks> pitti: I noticed that there is no way to add search engines as well (we did that for the french documentation). I think I'll work on that for P.
<didrocks> great :)
<pitti> didrocks: ah, I think we removed that because firefox doesn't allow us to
<didrocks> not sure if I forgot on the list of things we did in the french respin
<tjaalton> could a member of the release team ack/nack the ffe for sssd I filed, bug 860297
<ubottu> Launchpad bug 860297 in sssd (Ubuntu) "FFE: sssd 1.5.8 -> 1.5.13" [Wishlist,New] https://launchpad.net/bugs/860297
<pitti> didrocks: I discussed that with Chris, and there was something which prevented us from adding them
<didrocks> pitti: hum, we have an agreement with mozilla europe as the french loco team, so we will maybe retweak it (the head of mozilla europe is french, it helps)
<pitti> ah
<seb128> cjwatson, grub gfxpayload=... option is breaking my screen outputs when docked
<seb128> cjwatson, it was when setting it to =text (slangasek suggestion from yesterday)
<seb128> cjwatson, do you know what info would be useful in a bug and where to file it?
<seb128> where ... is $linux_gfx_mode (or whatever is the default, not sure of the name now)
<seb128> ups
<seb128> "it works when setting it to =text"
<cjwatson> seb128: not on grub, sounds like a kernel bug
<seb128> ok
<cjwatson> I mean, unless grub2 is leaving the registers in some kind of invalid state which is possible, but grub2 isn't the place to start analysing that I think
<seb128> cjwatson, ok thanks
<seb128> I will open a kernel bug
<sladen> pitti: ta
<apw> seb128, does your machine work ok on natty, and does it have seemless boot there ?
<sladen> pitti: (hadn't seen it, was asleep)
<seb128> apw, yes and yes
<seb128> apw, it's a dell latitude e6410
<apw> oh god not those heaps
<seb128> apw, oneiric works when I boot undocked, if I boot docked I get the external monitor to turn purple (grub background like) and then never get anything else on screen
<seb128> no plymouth, no lightdm, not vts
<seb128> I can switch to vts, the num lock status change
<seb128> so I think it boots and work, the screen just stay purple (and on)
<seb128> same on the laptop and external screens
<apw> so the machine boots then ... well thats something.  means we can get register dumps off it ... sigh
<seb128> if I boot undocked, wait for lightdm to show up and dock the laptop it works fine
<seb128> if I boot docked with gfxpayload=text it works fine
<apw> where does grub show up when its docked, the same place ?
<seb128> seems so
<apw> what sort of graphics does it have ?
<seb128> well I usually boot docked with lid closed, i.e only external monitor
<seb128> apw, the i5 integrated card
<seb128> i.e intel
<apw> so sounds like unpicking bios setup is still broken, *cries*
 * apw HATES BIOS
<seb128> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/857434 might have some details about my config
<ubottu> Ubuntu bug 857434 in linux (Ubuntu) "creates a 5 seconds delay in the boot" [Undecided,Confirmed]
<seb128> apw, it's a bug I opened recently on plymouth, which seems to be a duplicate of bug #854986
<ubottu> Launchpad bug 854986 in xserver-xorg-video-intel (Ubuntu) "[eDP1] 5 second delay between Xorg starting and the greeter starting (Dell Latitude E6410)" [High,Triaged] https://launchpad.net/bugs/854986
<apw> seb128, that title is missing a 'what'
<seb128> apw, oh, I use ecryptfs which means plymouth is loaded in the initramfs
<seb128> apw, "what" was the component I opened the bug against, i.e plymouth
<seb128> apw, i.e see the plymouth bar on https://launchpadlibrarian.net/80738739/oneiric-20110923-1.png
<seb128> apw, but I think it's the same as the other bug, edp probbing being slow, it just happens in the initramfs there due to ecryptfs use
<apw> its curtainly stupid that cryptsetup ends up doing things even when you don't have root encrypted, but hey
<seb128> yeah, it's another bug...
<apw> 5s added to the boot won't show up against the myriad of other delays
<seb128> apw, heh, that chart shows that unity is loaded at 10s, it means it double the boot time to greeter for me ;-)
<seb128> ups, unity->unity-greeter (lightdm)
<sladen> pitti: weird.  It's building here without 'rsvg' installed;  imagemagick must have some other way of doing .svg rasterisation
<apw> but its ok, you get a nice 20s to look at a blank desktop after that, so its just getting you used to it
<seb128> lol
 * apw notes that the "google" command line tool just stopped working for natty ... seems its using the wrong URLs
<seb128> apw, still, what info would be useful in a bug about the "booting docked with gfxpayload=$linux_gfx_mode screws screen outputs"
<seb128> ?
<apw> if you filed it against linux,t hen i'd expect we have whats needed in basic.  if its intel i am going to ask you for an intel_reg_dump from a good boot and a bad boot, which means you'll need to get ssh working i suspect
<MacSlow> RAOF, ping
<seb128> apw, ok
<RAOF> MacSlow: Pong.
<MacSlow> RAOF, hey there... what's the source-package of libgl1-mesa-dri? Just "mesa3d"?
<RAOF> MacSlow: mesa
<MacSlow> ah ok thanks
<RAOF> (apt-cache show libgl1-mesa-dri will show "Source: mesa" for future reference)
<MacSlow> RAOF, I'm not sure I'll remember this a week from now :)
<RAOF> :P
<MacSlow> RAOF, and grepping through my megs of xchatlogs-data isn't usually my typical way to search for info ;)
<RAOF> Just remember "apt-cache show".  It's the font of all knowledge!
<Laney> http://www.guardian.co.uk/travel/2011/sep/28/orlando-florida-cultural-top-10 :-)
<pitti> didrocks: live-build fix uploaded
<didrocks> pitti: thanks! :)
<pitti> micahg: eww @ autom4te.cache/ in the blueman upload
<pitti> micahg: (not a blocker, but would be nice to clean up in the next upload)
<micahg> pitti: sorry, where was that
<pitti> micahg: blueman
<micahg> pitti: right, but I don't see it anywhere
<pitti> micahg: hm, it was in the diff
<micahg> pitti: ah, I didn't look that hard at the 1.21 -> 1.22 part of the diff
<micahg> pitti: it's really weird, I don't have that in my local copy of the blueman source...
<micahg> pitti: I'll look at the diff a little later, nap time now :)
<pitti> micahg: perhaps debian/rules clean calls autoreconf or so (dh_autoreconf DTRT)
<pitti> micahg: but not a biggie, sleep well!
<micahg> pitti: thanks
<alfmatos> hi
<alfmatos> oneiric beta 2 is not downladable, atm...
<alfmatos> HTTP 403
<alfmatos> http://releases.ubuntu.com/oneiric/ubuntu-11.10-beta2-desktop-amd64.iso
<pitti> hm, works here
<alfmatos> really?
<alfmatos> :/
<sagaci> works here
<sagaci> via wget :)
<ion> alfmatos: Try without a proxy.
<alfmatos> no proxy here
<alfmatos> (or transparent)
<alfmatos> so it works for everyone
<alfmatos> uhmm
<alfmatos> weird
<alfmatos> i'm in europe, what ip do you guys get?
<alfmatos> host releases.ubuntu.com releases.ubuntu.com has address 91.189.92.160
<alfmatos> the same?
<ogra_> thats a round robin DNS entry i think, will return varying IP adresses
<pitti> 91.189.92.157 here, but what ogra said
<pitti> alfmatos: do you use a proxy?
<ogra_> or a provider that secretly puts one in the loop :)
<alfmatos> pitti: don't think so
<alfmatos> pitti: not explicit
<Amaranth> I don't think that one is round-robin DNS actually
<alfmatos> uhmm, i can't seem to wget directly from the ip
<alfmatos> 91.189.92.157/11.10/ubuntu-11.10-beta2-desktop-amd64.iso
<alfmatos> i get redirected
<alfmatos> but the weird thing is that i can download the .torrent or zsync
<ogra_> Amaranth, well, in any case it returns different IPs for different requests
<ogra_> i get a 403 here with wget ... now thats weird
<Amaranth> ogra_: I guess something is caching it for me, I always get the same thing
<ogra_> i get .157 pitti does
<alfmatos> so, it is 403
<ogra_> though the 403 is bothering
<alfmatos> uhmm
<pitti> ogra_: #is then?
<ogra_> yes
<alfmatos> is that just something someone can chmod ?
<pitti> no idea
<ogra_> alfmatos, seems to be a issue with the machine that resolves to .160
<ogra_> retrying it several times here, if i get a different IP it seems to work
<alfmatos> ogra_: so possibly someone should fix that
<alfmatos> i'll try to flush my dns cache
<alfmatos> and retry
<alfmatos> got it now
<alfmatos> 157
<ogra_> the datacenter troops are on it
<alfmatos> downloading
<alfmatos> 160, sucked again =)
<alfmatos> cool, hope i helped. :)
<ogra_> they will fix it :)
<ogra_> thanks for reporting !
<pitti> tseliot: hey Alberto!
<pitti> tseliot: any chance I could debug bug 855396 on your machine with ssh?
<tseliot> pitti: hi Marin
<ubottu> Launchpad bug 855396 in jockey (Ubuntu) "Jockey doesn't provide fglrx-updates" [High,In progress] https://launchpad.net/bugs/855396
<tseliot> pitti: I don't have a static ip
<pitti> tseliot: just tell me the current one :) usually you just need to enable port forwarding in the router
<pitti> tseliot: but you could also do ssh port forwarding to e. g. chinstrap
<pitti> seems easier
<tseliot> pitti: I think I did ssh port forwarding to chinstrap, let me check
<pitti> tseliot: ssh -R 2222:localhost:22 chinstrap...
<stgraber> slangasek: ping
<stgraber> mvo_: ping
<stgraber> mvo_: just talked with wendar about getting a staging PPA for the ARB. Could you create one? (you're the owner and administrator of the ARB team on LP)
<mvo_> stgraber: done https://launchpad.net/~app-review-board/+archive/staging
<stgraber> mvo_: thanks
<mvo_> stgraber: y
<mvo_> yw
<wendar> mvo_: thanks!
<tjaalton> stgraber: hey, do you remember why the libpam-sss pam-config priority was bumped? upstream says pam_sss.so should always be after pam_unix.so, and the change "broke" pam_ecryptfs.so in that you had to enter the password twice
<stgraber> tjaalton: "- Bump pam-auth-update priority to 960 (512 + 256 + 128 + 64)" if that's what you're referring to, that was done based on pam-auth-update's documentation
<stgraber> tjaalton: 512 = central network service, 256 = local authentication (through the cache), 128 = crypto, 64 = delegation of credentials for SSO
<tjaalton> stgraber: ok, where's that documentation?-)
<ion> 512 + 256 + 128 + 64? I didnât know it was a bit field. I thought it was just a value for linear ordering.
<smoser> cjwatson, you have a minute?
<cjwatson> smoser: ye
<cjwatson> s
<smoser> i add http://paste.ubuntu.com/698522/
<smoser> to /etc/default/grub.conf
<smoser> and then 'update-grub'
<tjaalton> stgraber: ok it's on the spec
<smoser> but i still dont see a prompt
<cjwatson> show me the resulting grub.cfg please
<cjwatson> and do you mean you don't see a menu?
<smoser> http://paste.ubuntu.com/698526/
<cjwatson> also I hope you mean /etc/default/grub
<smoser> i want to see the grub dialog/timeout.
<smoser> yes, i meant /etc/default/grub
<smoser> soryr.
<smoser> wait
<smoser> sorry
<cjwatson> you probably need GRUB_HIDDEN_TIMEOUT_QUIET=false too
<cjwatson> oh, you have that, confusingly written
<smoser> http://paste.ubuntu.com/698528/ is the /etc/default/grub
<cjwatson> could I have grub.cfg please?  you've pasted /etc/default/grub twice :)
<smoser> sorry.
<smoser> http://paste.ubuntu.com/698531/
<ScottK> barry: Would you be able to look at https://launchpadlibrarian.net/81310249/buildlog_ubuntu-oneiric-i386.unbound_1.4.13-0ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz
<smoser> its possible that the gfx mode is screwing up, and/or just switching too quickly.
<barry> ScottK: i'll try.  i'll keep the browser window open
<ScottK> Thanks.
<cjwatson> smoser: sorry, I'm not entirely sure right now.  You could try GRUB_TIMEOUT=-1 as a workaround which I think will probably force it.
<slangasek> stgraber: pong
<Tanguy> Hello.
<Tanguy> I am the maintainer of the Debian packages itstool and latexila.
<Tanguy> Both of which have been diverging from Debian for release needs.
<Tanguy> Now that the last versions are in Debian testing, they may be integrated back, if it is relevant.
<stgraber> slangasek: that was about bug 854967 and whether blacklisting nvidia in gfxpayload would be a problem for flickerless boot. Though you already answered that flickerless isn't working with binary drivers at the moment anyway.
<ubottu> Launchpad bug 854967 in nvidia-graphics-drivers-updates (Ubuntu) "boot to rescue mode in Oneiric" [Undecided,New] https://launchpad.net/bugs/854967
<Riddell> barry: ping
<slangasek> stgraber: right - true flickerless boot requires an in-kernel handoff without modeswitching, and we don't get that with binary drivers
<barry> Riddell: pong
<stgraber> tseliot: ping (bug 854967). Anything against blacklisting all the nvidia chips in gfxpayload? that'd need an upload of each of the nvidia binary drivers.
<ubottu> Launchpad bug 854967 in nvidia-graphics-drivers-updates (Ubuntu) "boot to rescue mode in Oneiric" [Undecided,New] https://launchpad.net/bugs/854967
<Riddell> barry: for UDD I'm thinking there should be a get-tar command.  my use case is  bzr co ubuntu:foo; make a change; bzr get-tar; debuild.  is that a common workflow?
<cjwatson> Tanguy: we're almost at our final freeze for 11.10; can it wait for the next release cycle?
<barry> Riddell: it's not typically how i work.  usually after the checkout, `bzr bd -S` does the trick for me
<Tanguy> cjwatson: I guess it can, I was just mentionning the possibility in case it wuold have been useful.
<Tanguy> Personally I do not care.
<tseliot> stgraber: no objection at all, and I have to re-upload them all because of another change anyway
<Riddell> barry: well that just gives you a source build, I'm wanting to see if I get a successful build and make changes based on that
<Tanguy> Riddell, barry, I have just arrived in the middle of your description, but are you talking of storing an upstream tarball in a package's version repository?
<Riddell> Tanguy: no, I'm talking about the full ubuntu package branches
<tseliot> stgraber: therefore I'll take care of it this week
<barry> Riddell: right, i always switch to sbuild or pbuilder to get the binary built.
<stgraber> tseliot: thanks
<tseliot> yw
<Riddell> barry: mm, I don't so I guess our workflows differ
<barry> Riddell: yep.  i gravitate toward sbuild because it gives me all the control of the build environ i need, and a good environ for debugging build problems
<seb128> slangasek, apw: I opened bug #861477 about my no screen when docked issue
<ubottu> Launchpad bug 861477 in linux (Ubuntu) "Oneiric's grub gfxpayload=$linux_gfx_mode breaks display output (intel)" [Undecided,New] https://launchpad.net/bugs/861477
<apw> seb128, asked you for the intel_reg_dumps in the bug
<seb128> apw, ok, getting that
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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:
 * dholbach hugs pitti
<smoser> mvo, does do-release-upgrade address entries in /etc/fstab at all ? for devices that will have changed names ?
<smoser> ie, when we upgrade from 10.10 to 11.04 in EC2, the kernel will start changing the name from 'sda' to 'xvda'.  if there are entries like /dev/sdb in /etc/fstab (espeically without 'nobootwait') a reboot is going to result in a unavailable system.
<mvo> smoser: it does that in the quirks handler if we tell it to, we did that in the past. but I don't think we do anything currently (natty->oneiric)
<cjwatson> this is for maverick->later
<mvo> smoser: that sounds like something we ought to fix in a quirks handler
<mvo> smoser: I don't think we did this one
<cjwatson> note that lucid used xvd*
<smoser> cjwatson, lucid-ec2 used sda
<cjwatson> fair enough, plain lucid in Xen didn't though
 * smoser apologizes for all the crap that he/ec2 has brought upon ubuntu 
<wookey> mvo: does anything guarantee the sources at http://ports.ubuntu.com/ and http://archive.ubuntu.com/ubuntu to be the same?
<wookey> or does one have to carefully use the sources from the correct repo to be sure of not getting strageness?
<ogra_> wookey, there might be minimal mirroring delays, bit thats about it
<ogra_> *but
<wookey> and another question: apt-get source gets the source for the highest-priority/newest binary in the cache
<wookey> it does _not_ get the highest-priority/newest source package in the cache
<wookey> I assume that's how it's intended to work?
<wookey> so is there a way to tell it to get the newest source avaialble?
<wookey> (this behaviour confused me immensely for hours last night...)
<seb128> apw, ok, I updated the bug and the description, it seems to be happening only when booting with the lid closed, I'm pretty sure it was buggy lid open and docked as well before but maybe an update fixed it
<seb128> apw, I got the intel_reg_dump logs for broken and working boots, I can't try without the station since the laptop has no dvi-d output, I can try with a vga cable later
<apw> seb128, sound good ta
<seb128> apw, thank you for looking at it ;-)
<smoser> mvo bug 861535
<ubottu> Launchpad bug 861535 in update-manager (Ubuntu P-series) "release-upgrade needs to address fstab entries for devices that will change names (sda -> xvda)" [Undecided,New] https://launchpad.net/bugs/861535
<mvo> thanks smoser - is this P or do we need it for oneiric too?
<mvo> smoser: nevermind, I just see that we should actually SRU it
<smoser> mvo, for this case, it would actually only affect 10.04 -> 12.04 or 10.10 -> 11.04
<smoser> yeah.
<mvo> ok
<mvo> should be simple to do
<wookey> mvo: did you see query re apt-get source behaviour above?
<mvo> wookey: yeah, I need to look at the source, but IIRC it should select the higest one. you can pass a version number too. do you see different behavior?
<wookey> yes. I have a pastebin with some detail in...
<wookey> http://pastebin.ubuntu.com/698582/
<wookey> the version that apt-cache policy shows is the one that is downloaded, but that only the newest binary available, not the newest source available
<wookey> if I change the config so that the PPA binary arch (amd64) is listed in apt sources, instead of armel (which currently isn;t built) then is find the newer source package
<wookey> s/is find/it finds/
<wookey> I could use the showsrc to find the version number and then pass that as a workaround.
<wookey> but I really wanted preferences to do this for me (because sometimes the PPA version won't be newest)
<mvo> wookey: thanks, I check it after dinner, but I'm unfortunately a bit overloaded with $stuff at this point
<wookey> yeah sure - me too :-)
<wookey> shoudl I file a proper bugrep with that info in it?
<wookey> Now I've understood what's going on it no longer urgent
<wookey> I also found that pinning doesn't work unless the archive key has been installed, which seems a bit odd.
<Daviey> jhunt: Hello sir, how is udev looking?
<hallyn> pitti: seb128: Just did an apt-get dist-upgrade on two oneiric laptops, and again, I now see
<hallyn> gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
<hallyn> 'suspend'
<hallyn> those were 'nothing' before the upgrade
<hallyn> then I set it back to 'nothing', logged out and back in, it's still 'nothing'
<hallyn> (and, again, my capslock-as-control preference got lost during the upgrade which is why i thought to check)
<ogra_> hallyn, if you touch a keys, it gets stored in your home and wouldnt get touched by an upgrade of the system key
<ogra_> at least thats how gconf operated, i suspect the same is true for dconf
<ogra_> you need to wipe the key from your personal config to make it use the system default again
<ogra_> (i think there is a  reset key option in dconf-editor)
<hallyn> ogra_: what does 'touch a keys' mean?
<ogra_> you changed a value
<hallyn> ogra_: yesterday i opened the power settings manager, and set the values to 'do nothing'
<hallyn> then i did apt-get dist-upgrade, and they got unset
<ogra_> by i.e. selecting something in the control center
<hallyn> and since suspend is broken, i'm afraid that could cost others beside me some data
<ogra_> oh, that actually sounds like it wiped your personal setting
<ogra_> i dont think thats supposed to happen ... unless the key name changed or some such
<hallyn> i didn't pay enough attention to the packages being upgraded, whic his hwy i've not filed a bug yet.
<hallyn> (was in a hurry, did '-y dist-upgrade)
<ogra_> well, there was a change in gnome-power-manager for the "suspend after 30min regardless" issue
<ogra_> and that actually touched the default settings
<seb128> hallyn, ok
<Daviey> Is removing ureadahead a viable workaround to bug #523484?  (/var being on a seperate parition)  The use case is a server enviroment, where i don't think the boot perf matters so much.
<ubottu> Launchpad bug 523484 in ureadahead (Ubuntu) "ureadahead requires /var on root filesystem" [Medium,Triaged] https://launchpad.net/bugs/523484
<jbicha> sladen: the new ubuntu-mono breaks the user-desktop icon
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | 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: robert_ancell
#ubuntu-devel 2011-09-29
<mpiechotka> Hello. Sorry for dropping in but by accident I noticed that Ubuntu (in all version but Oneiric Ocelot) contains versions of libgee with known bugs. I don't know the Ubuntu policy but I'd highly recommend to upgrade to 0.6.2.1 [which contains bugfixes to 0.6.1, 0.5.3 and 0.5.0 which are in Natty Narwhal, Maverick Meerkat and Lucid Lynx respectively].
<RAOF> slangasek: Re: bug #851947 - the multiarch mesa DRI drivers aren't installable as libdrm-intel1 grew a dependency on libpciaccess0, which I multiarched and is in Sid now, but I didn't notice that it wasn't in Ubuntu.
<ubottu> Launchpad bug 851947 in ia32-libs (Ubuntu Oneiric) "/usr/lib32/libGL.so.1 prevents Doom 3 from starting" [High,Confirmed] https://launchpad.net/bugs/851947
<RAOF> slangasek: If we're going to remove mesa from ia32-libs (which seems reasonable) that might mean we want to sync libpciaccess from Sid.
<mbiebl> RAOF: heya
<RAOF> mbiebl: Yo.
<mbiebl> got my colord bug report?
<mbiebl> would be cool if you can update it, I'm currently working on g-c-m 3.2.0
<mbiebl> I can send you a debdiff for colord 0.1.12 if that helps
<RAOF> It's ready and waiting in collab-maint git; I just haven't done the sponsor dance yet.
<mbiebl> ah, great.
 * RAOF needs to go for DM
<mbiebl> let me take a look
<mbiebl> I'll sponsor it for you, if you don't mind
<RAOF> I don't mind at all!
<mbiebl> ok, will take a closer look tomorrow
 * mbiebl â bed
<mbiebl> RAOF: a few quick comments:
<RAOF> Shoot.
<mbiebl> the if ! getent group scanner >/dev/null; then
<mbiebl> checks are unnecessary
<mbiebl> adduser already does the right thing
<mbiebl> and adduser --system already creates the corresponding group
<mbiebl> so no need to split that
<infinity> Since when does adduser exit 0 if a group exists?
<infinity> I've always done "getent blah || adduser", because it choked if you didn't.
<mbiebl> I don't know the version number
<mbiebl> http://wiki.debian.org/AccountHandlingInMaintainerScripts
<mbiebl> RAOF: forgot to add adduser --system *--group colord*
<mbiebl> will create the corresponding group
<RAOF> :)
<RAOF> I'm happy to make those changes if you like.
<mbiebl> regarding the dependencies of libcolord-dev
<mbiebl> does pkg-config still choke on missing requires.private deps?
<mbiebl> I thought that was fixed and only required for static linking
<RAOF> It does, or at least did.
<RAOF> The gnome-control-centre / g-s-d plugins failed to build without those extra dependencies.\
<slangasek> RAOF: I've not proposed removing mesa from ia32-libs, only putting it back where it's not on the default path (because the way it was put there was broken)
<RAOF> slangasek: Ah, ok.  Good.
<mbiebl> RAOF: hm, with PK support disable and instead using at_console, isn't there a problem with everyone being able to install profiles system wide?
<mbiebl> and at_console is something we actually want to get rid of
<mbiebl> not use instead of PK
<RAOF> That's the existing PK behaviour; they're all <allow_active>yes</allow_active>.
<mbiebl> <allow_active>auth_admin_keep</allow_active>
<mbiebl> is for org.freedesktop.color-manager.install-system-wide
<RAOF> *facepalm*
 * RAOF missed that.
<RAOF> I've got a PolicyKit patch that removes the limitation which makes it unusable for unprivileged daemons, so polkit 0.103 should support this.
<mbiebl> argh, polkit 0.103 has dropped libpolkit-gtk
<mbiebl> so I can't upload it to Debian just yet
<RAOF> I don't see that in the git log?
<RAOF> Are we talking about the same thing?
<mbiebl> meh, was looking at pk-gnome
<RAOF> In fact, I see exactly one non-version-bump commit between 0.102 to master :)
<mbiebl> definitely bed time for me
<mbiebl> can I catch you on irc tomorrow?
<RAOF> Yes.
<RAOF> I'll be here from ~7:30 UTC+10
<mbiebl> ok, cu then
<Laibsch> Hey guys, I maintain the scim package in Debian and I'm trying to get it to support multi-arch.  Is there a way to get the equivalent of $(dpkg-architecture -qDEB_HOST_MULTIARCH) on a user system without having dpkg-dev installed?
<Laibsch> #multiarch is quiet so I hope somebody can enlighten me here?
<clahey> I would like to create an updated lilypond deb.  How do I do so?
<clahey> Is there a tutorial somewhere?
<Laibsch> clahey: "pull-lp-source lilypond && cd lilypond-* && echo "make changes here && pdebuild"
<Laibsch> that's the really short version.  a more elaborate version depends on what you already know ;-)
<Laibsch> in essence, get the source, hack away, build, test, repeat
<clahey> pdebuild?
<RAOF> Laibsch: I don't believe so, although you could maintain your own set of arch ? multiarch tuple mappings I guess.  What do you want it for?
<clahey> Is there a maintainer for lilypond?
<Laibsch> RAOF: thank you for your reply.  I recently updated scim because the multi-arch stuff caused a FTBFS.  But now I get a regression because the program looks for plugins in the non-multiarch location.
<Laibsch> http://paste.debian.net/132934 is what I supposed for a fix but jwilk correctly pointed out that this could lead to another regression in certain situations.
<Laibsch> assume an AMD64 host which has i686 input methods installed.  Those will be valid candidates due to the wide-ranging asterisk condition in that patch.
<RAOF> Laibsch: Oh, super fun.
<Laibsch> I want to replace /*/ in that patch with /$DEB_HOST_MULTIARCH/ as in http://paste.debian.net/132936
<RAOF> Laibsch: This is an arch: any package, right?
<Laibsch> but http://paste.debian.net/132934 would introduce a dependency on dpkg-dev
<RAOF> Laibsch: Can you not just generate that script (or reference DEB_HOST_MULTIARCH at those points, and set it at the top of the script) at package build time?
<Laibsch> I don't maintain the other packages
<Laibsch> jwilk also suggested to deal with the problem at build time
<Laibsch> but then I was the one to object ;-)
<Laibsch> scim binary package is MA:foreign (as per slangasek's suggestion), so that AMD64 host could have an i686 package of it installed.
<Laibsch> I'm sure I'm not going to be the only one with this issue in the future, so I assume there will be a general solution eventually
<RAOF> Well, I think yours is a pretty special case; most plugin systems will hardcode the directory at build time.
<Laibsch> which was what we did so far
<RAOF> There may be other cases like it, but I wouldn't expect too many.
<Laibsch> but I think multi-arch breaks that
<RAOF> No?
<Laibsch> I think this issue will arise for any binary that has a) plugins and is b) MA:foreign
<Laibsch> plugins as separate packages
<RAOF> MA: foreign means that it can *satisfy* dependencies, right?
<Laibsch> MA:foreign means that the build host's arch is irrelevant
<Laibsch> My understanding is that foreign means that an AMD64 host can install an i686 version of the scim binary package
<Laibsch> => build host and user host have no relation at all
<RAOF> Well, an AMD64 host can *always* install an i686 version of scim.
<Laibsch> take another arch
<Laibsch> it's the only two I can come up with now ;-)
<RAOF> An AMD64 host can *always* install an armel version of scim.
<Laibsch> Update My understanding is that foreign means that a sparc host can install an i686 version of the scim binary package
<RAOF> What MA:foreign means (IIUC) is that an i386 scim package can satisfy *dependencies* for an amd64 package.
<Laibsch> yes
<RAOF> See what python's doing with this; they're in essentially the same boat.
<Laibsch> enlighten me, please
<Laibsch> am I completely wrong in assuming that build host arch doesn't necessarily equal user host arch in case of MA:foreign?
<Laibsch> s/assuming/deducing/
<RAOF> If scim is built on amd64 (and contains native code) then there's no point in looking anywhere but /usr/lib/x86_64-linux-gnu; it won't be able to load i386 plugins.  Similarly, for i386.
<RAOF> Python is in the same boat; I'm not familiar with exactly what they do, but that's what I'd look to.
<Laibsch> I'm wondering about the MA:foreign setting for the scim binary package.  I guess what slangasek meant is that for compile-time purposes and armel binary on an amd64 host is OK.  But I cannot think the same is true for running any binary inside the scim package.
<Laibsch> the amd64 host would need the amd64 binary package, right
<RAOF> Laibsch: https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships might be what you're after.
<YokoZar> slangasek: RAOF: uploading an ia32-libs that reverts the libGL links right now, which should break mesa
<Laibsch> RAOF: multi-arch is mostly concerned about compile-time, not necessarily run-time right?  I don't think the scim-binary package is a compile-time dependency for just about anything, there's libscim-dev for that.
<RAOF> No, multiarch is runtime.
<RAOF> As in: install $FOREIGN_ARCH packages on $NATIVE_ARCH, and have them work at runtime.
<RAOF> (Compile time is a nice side-benefit)
<Laibsch> but if anybody were indeed to ever install the scim binary package on a host that differs from the build-host the binaries inside the package would not run, right?
<Laibsch> OK
<YokoZar> Speaking of multiarch: https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/852101
<ubottu> Ubuntu bug 852101 in wine1.3 (Ubuntu Oneiric) "32-bit applications do not start on 64" [High,Confirmed]
<YokoZar> apparently not having any multiarch libs causes problems now
<Laibsch> RAOF: I see.  Then I think the issue I raised will eventually come up.  And I don't think it's the same as the python case.  But this stuff gets my head spinning.
<Laibsch> YokoZar: multi-arch is new.  There's going to be lots of wrinkles iron out.  I suppose by 12.04 things should look much better.
<RAOF> Laibsch: I guess I'm not entirely sure why you'd set MA: foreign for scim.
<Laibsch> because the master himself AKA slangasek told me so ;-)
<infinity> Laibsch: Multi-arch has nothing to do with build-time (except for the part where we have to mangle toolchains and packages to deal with things moving), it's all about run-time
<infinity> Laibsch: What "MA: foreign" means is that it can be installed on a foreign arch (say, i386 on amd64, or arm on i386, thanks to binfmt_misc emulation), but can't be installed with itself.
<infinity> Laibsch: As opposed to MA: same (which multi-arched libs have), which can be installed on foreign arches, but don't conflict with themselves.
<RAOF> infinity: *And* that it'll satisfy cross-architecture dependencies, right?
<infinity> Laibsch: (And same can only be used to satisfy deps from the same arch, foreign can stisfy deps from another arch)
<infinity> RAOF: Yeah, I was getting there. :)
<infinity> RAOF: The names relate more to the dependency issues, but most people understand the other concept better, so I start there. :P
<RAOF> And MA: foreign doesn't actually allow you to install on a foreign arch; you can do that anyway.
<RAOF> At least, I'm pretty sure you can, as long as the dependency chain is either (a) disjoint from any native dependency chain, or (b) multiarched.
<infinity> Well, fair point.
<infinity> YokoZar: Sounds like wine's messed up its deps, then. :/
<Laibsch> infinity: I'd be lying if I claimed that this is easy for me to understand.  Let me try to summarize.
<Laibsch> scim binary package is MA:foreign and thus only one version of the package can be installed at any one time.
<Laibsch> but it can be a foreign or the native arch.
<Laibsch> if foreign arch, will the binaries run correctly or not?
<infinity> slangasek: Painfully late in the game for this, but probably low impact.  How would you feel about an ia32-libs-multiarched metapackage (i386-only) that depends on everything that's been removed from ia32-libs since the MA adventure started, and ia32-libs can depend on it?  So, no surprises for upgrades.
<infinity> Laibsch: Whether they can run or not is up to the sysadmin, not you.  They could be i386 on amd64 (which will work), they could be emulated (which might work)...
<infinity> Laibsch: I can run several architectures on my laptop emulated, and two natively.
<infinity> Laibsch: Packaging tools will not satisfy a dependency with an "MA: foreign" package from another arch if one is available for the native arch, and even then, you nominate your foreign arches in a config file, so it's not like apt will just run off and grab a Sparc binary for you and then laugh when it doesn't work. ;)
<infinity> slangasek: Seeing "solutions" thrown around like "install skype:i386, it will restore all your missing 32-bit libraries!" makes me think an ia32-libs -> ia32-libs-multiarched hack is slightly less icky than it sounds, as a migration path anyway.
<Laibsch> infinity: I understand that obviously the native arch version will be preferred.  But for the sake of understanding, I was wondering for example what happens if for whatever reason a foreign arch gets installed.
<Laibsch> Whether or not the binary actually runs depends on the support for the foreign arch on the host?  Support for the foreign arch can either be native or emulated?
<Laibsch> Man, this is heavy stuff, gets my head spinning.  (But it did for jwilk as well, so I don't feel bad ;-))
<infinity> Laibsch: Yeah, if you nominate a foreign arch in your dpkg configs, it's up to you to make sure it works.
<infinity> Laibsch: We turn on i386 on amd64 by default because we make that work, other whacky combinations are left to users to work out.
<Laibsch> I see
<Laibsch> I didn't know that an arch has to be specifically turned on to become installable
<infinity> Aye.
<infinity> adconrad@cthulhu:~$ cat /etc/dpkg/dpkg.cfg.d/multiarch
<infinity> foreign-architecture i386
<infinity> ^-- For instance.
<infinity> That one is set up on install or upgrade to oneiric on amd64 machines.
<Laibsch> OK.  Let me log into a Debian unstable pbuilder to see what I find there.  RAOF mentioned this earlier, but I wonder what happens if I mix an i386 plugin package with an amd64 scim package on an amd64 host, for example?
<Laibsch> infinity: can you tell me more about the laptop you mentioned earlier and the arches it supports?
<infinity> Laibsch: Assuming the plugins are DSOs, that sort of mixing and matching isn't going to work.
<infinity> Laibsch: As for the laptop, it supports (in theory) amd64 and i386 natively, and everything that qemu-user-static supports for virtualisation.  Due to some issues with some architectures having overlapping loader locations, that's not actually completely true yet, though.
<infinity> Laibsch: But I run ARM binaries on it with no issues, for instance.
<infinity> s/virtualisation/emulation/
<infinity> It's late, I can't brain anymore.
<Laibsch> infinity: what is preventing the user from attempting to install a mix and match even in case of DSOs?
<infinity> Sane dependencies of some sort, I suppose.
<infinity> Not sure how most DSO maintainers deal with it so far, TBH.
<infinity> In the usual "applications and libraries" sort of scenarios, the applications are MA: foreign, and the libraries are MA: same, so any app->lib (or lib->lib) deps will be met by same-arch libs.
<infinity> In a DSO situation, you may well need to look at it a bit backward, and treat the application that allows plugins as a library.  I'm not sure if we have any good examples of this just yet.
<infinity> Or actually, no.
<infinity> Or, yes. ;)
<Laibsch> I'm still trying to figure out if it's completely impossible that a user will install (and attempt to run) for example: amd64 host, scim is i386 and input method plugin is amd64
<infinity> Yeah.  Since the dep only goes one way (DSO->app), it gets messy. :/
<infinity> Do the DSOs depend on scim, or on libscim?
<Laibsch> If I hardcode the build-host into the path were scim will look for plugins (suggestion jwilk) that would be i386 one, and not find a valid plugin in this case.
<infinity> Depending on libscim would solve it, since the library should be MA: same when multiarched.
<infinity> Laibsch: And, a random one (scim-hangul) seems to depend on the library.
<infinity> Laibsch: So, yeah.  If all DSOs depend on libscim, then if libscim is multiarched with "MA: same" (as a multiarch lib should be), your whole stack will be forced to match by the packaging system.
<infinity> Or.  I guess you could still have both libscims installed, an i386 scim, and a few amd64 DSOs, eh? :P
<infinity> Maybe a perfectly valid reason to not multiarch the package at all. :P
 * infinity ponders this more.
<Laibsch> this is way over my head :-P
<Laibsch> I am not maintainer of the plugins, so I can never be sure on what they depend on
<Laibsch> and I thought I remembered that most of them depend on scim directly
<Laibsch> scim-bridge-agent is one of them (although a bad example)
<infinity> Well, it also depends on the library too.
<Laibsch> scim-modules-socket depends on the lib
<infinity> But yeah, that still doesn't resolve your concern.  One could have a bunch of DSOs installed for the wrong arch and they'd just not be found.
<Laibsch> this seems to be such corner case, one which may never materialize
<Laibsch> and which may even be impossible
<infinity> Well, the real answer may be that it doesn't matter.  If the user chooses to install mismatched IMEs, maybe they have some weird reason to do so.
<Laibsch> I only want to understand a bit more before consciously taking the plunge
<Laibsch> if things go wrong I can always point fingers at jwilk
<Laibsch> and you :-p
<infinity> But having your DSOs in an arch-specific path would help to at least have them not even found, rather than attempt to load and fail.
<Laibsch> yes
<Laibsch> I think assuming build host for whatever scim package is installed determines lookup path for the modules should be a valid approach
<Laibsch> thank you for your time and insight, infinity
<infinity> Yeah.  Now you have me trying to think of a foolproof way around this, though.
<infinity> When I should be relaxing and/or sleeping. :)
<Laibsch> hehe
<infinity> So, thanks for that. :P
<Laibsch> I'm glad you can't touch me
<Laibsch> and over here it would not be a concern, bright daylight!
<YokoZar> infinity: I agree with your suggestion to slangasek about a transitional package btw, or at least some sort of intelligence in update-manager/software center
<infinity> Laibsch: Pretty much the most evil thing I can think of would be for scim to provide scim-$arch, and have the DSOs depend on scim-$ARCH, but I still feel like I'm missing sometihng.  (of course, just as simple is to not multiarch it at all, but I assume someone wants the library multiarched, at least, to allow for a dependency chain to be MA)
<infinity> YokoZar: A packaged solution is always better than an installer hack.
<infinity> YokoZar: Since the latter only works for people who use the one upgrade method.
<YokoZar> infinity: but I'm not sure why Wine is breaking in this regard because it shouldn't be linking anything from the i386 multiarch folders in its configure/build (indeed they aren't even available at build time)
<infinity> YokoZar: Yeah, I'm not sure why wine breaks either.  It doesn't break here, but I have a ton of :i386 stuff installed.  I could yank it all out, I guess. :/
<infinity> YokoZar: Either way, I think ia32-libs just randomly dropping libraries on the floor is non-obvious.
<Laibsch> infinity: the reason I got started with multiarch on this package was an FTBFS.  The fix for it introduced a regression. My concern is now to fix the regression the best and most robust way possible.
<infinity> YokoZar: Do you have a concise list of libraries dropped from ia32-libs sine MA began?
<infinity> s/sine/since/
<YokoZar> infinity: I suspect that's the reason we missed this particular bug as well, cause all of us concerned HAD multi-arch packages enabled
<YokoZar> infinity: they should all be enumerated in the ia32-libs changelog
<YokoZar> Speaking of which, Oneiric Wine actually builds with a couple less features than Natty Wine because those packages were dropped from ia32-libs :/
<YokoZar> Nothing too important though
<infinity> YokoZar: I'd love you forever if you could make the aforementioned ia32-libs-multiarched metapackaga and a matching ia32-libs upload to depend on it.  I'd review it in the morning and rubber-stamp it if Steve doesn't threaten to kill me.
<infinity> YokoZar: I assume the ultimate solution here is to drop wine from amd64 entirely, right?
<YokoZar> infinity: I assume I avoid stepping on cross-architecture-dependency-nono by making ia32-libs-multiarched i386 only, MA:foreign, and having ia32-libs depend on it yes?
<infinity> YokoZar: (In fact, why haven't we?)
<infinity> YokoZar: Yeah, same trick we pull with flash-*
<infinity> YokoZar: amd64 package depending on something that only lives in i386.
<infinity> YokoZar: Which is also how I assume you'd do a smooth transition to "oops, wine doesn't exist on amd64 anymore".
<YokoZar> infinity: 64-bit Wine complicates this
<infinity> Oh, derp.  64-bit Windows.  Right.
<infinity> Somehow, that didn't even cross my mind.
<YokoZar> infinity: There was going to be this weird transitional state this cycle where Wine needed to be split into two separate packages and it didn't happen
<YokoZar> infinity: But more importantly, not all of Wine's deps are multiarch enabled
<infinity> Check.
<YokoZar> So next cycle :P
<infinity> Early next cycle, I hope.
<YokoZar> Yeah me too
<infinity> I'm not okay with wine being even remotely broken and/or a joke in an LTS.
<infinity> People downplay its important a lore more than I'd like.
<infinity> (And this is from someone who runs no win32 software)
<infinity> s/important/importance/
<YokoZar> This UDS Steve and I are gonna play a hand of poker to decide who gets to be the one to make the final "ia32-libs removed forever" upload
<infinity> While you're fighting for the honor, I'll upload.
<infinity> <3
<StevenK> Haha. Just one?
<YokoZar> Perhaps we should have a lottery...
<StevenK> Sure, but which archive admin gets to lp-remove-package it? :-)
<infinity> I'll have a loop running on ftpmaster.
<StevenK> Poor cocoplum.
<infinity> Check for (conditions); remove ia32-libs
<pitti> Good morning
<infinity> [ "$ANYTHING_GOOD_ON_TV" = "false" ] && CONDITIONS=perfect
<infinity> pitti: Evening.
<infinity> StevenK: Please rename lp-remove-package to business-time, thanks.
<StevenK> infinity: File a bug.
<StevenK> So I can laugh at you, and close it.
<infinity> Those don't end well.
<infinity> And that's crazy talk, my LP bugs never get closed.
<YokoZar> CLOSED: OPINION
<infinity> They stay open for about 6 years, bounce between medium and critical, get lots of comments, and get reassigned about 12 times.
<StevenK> infinity: Lies!
<StevenK> infinity: You have *30* closed Launchpad bugs
<StevenK> Sorry, 28. 30 is the id for Fix Released
<YokoZar> infinity: if I make ia32-libs-multiarch and depend on it with ia32-libs, won't that be a problem when packages like wine build-depend on ia32-libs?
<YokoZar> (or did you mean recommends?)
<infinity> YokoZar: Oh, I forgot that things build-dep on it.  That's trickier. :/
<YokoZar> infinity: Well recommends would be an improvement yes? (Builds unaffected, upgrade case works)
<didrocks> good morning
<slangasek> RAOF: eh?  what's python doing with MA: foreign? (It shouldn't be!)
<RAOF> slangasek: It isn't - that was before I refreshed my memory.
<slangasek> RAOF: ok :)
<RAOF> slangasek: Why did you suggest that Laibsch MA: foreign scim?
<qH> hello
<qH> Since upgrading to Ubuntu 11.10 I am having problems connecting to my wireless network. The connection is made, and after about 30 seconds the connection is lost. This has never happened with any of the previous versions of Ubuntu. IT COMPLETELY LOCKS UP MY ROUTER. The only solution after attempting a connection is to reset the router.
<qH> Since upgrading to Ubuntu 11.10 I am having problems connecting to my wireless network
<qH> The connection is made, and after about 30 seconds the connection is lost.
<qH> This has never happened with any of the previous versions of Ubuntu.
<qH> IT COMPLETELY LOCKS UP MY ROUTER. The only solution after attempting a connection is to reset the router.
<qH> i need help
<qH> my wireless card is wifi link 5100
<Laibsch> qH: you're in the wrong channel, try #ubuntu instead, please
<slangasek> RAOF: while it's possible I did, I in fact don't remember making such a recommendation for scim, and looking at the reverse-deps now I don't see why I would have either.  Several of the revdeps ship binary modules that are meant to be loaded by scim, so that doesn't really seem like a sensible thing for me to recommend
<RAOF> slangasek: That was what I was thinking; at *best* it's a MA: allowed, same as Python.
<slangasek> Laibsch: do *you* remember why I said MA: foreign for scim? :)
 * Laibsch checks the logs
<slangasek> ah, here we are
<slangasek> <vorlon> scim should almost certainly be multi-arch: foreign, as I don't believe anything outside of the scim package itself should be loading the plugins from /usr/lib/scim-1.0/1.4.0
<infinity> Yeah, we were trying to come up with clever ways to make DSOs work with an MA:foreign loader, and the concept broke my brain, so I'm curious why too.
<slangasek> but I overlooked the existence of revdeps that ship plugins for it and declare a dependency on it - so it was an oversight at the time
<Laibsch> slangasek: (00:38:46) vorlon: I'm 99.97% certain nothing will break by treating the scim binary package as Multi-Arch: foreign and assuming that nothing outside scim itself loads those modules
<Laibsch> (00:34:31) vorlon: scim should almost certainly be multi-arch: foreign, as I don't believe anything outside of the scim package itself should be loading the plugins from /usr/lib/scim-1.0/1.4.0
<slangasek> YokoZar: eh - "bash: /usr/bin/wine: No such file or directory" is the error you get if the ELF interpreter is missing from the system.
<Laibsch> (00:29:54) vorlon: if they're loaded by the scim package itself, then this is conceptually a Multi-Arch: foreign package (only one instance of the package needs to be installed at a time, and it can satisfy dependencies of packages of other architectures because the only interface it provides is via exec() )
<slangasek> YokoZar: I think that means they installed libc6-i386, installed libc6:i386, and removed libc6:i386, taking the interpreter with it.
<Laibsch> slangasek: did that refresh your memory?
<infinity> slangasek: Is that bug still there?
<slangasek> infinity: ia32-libs-multiarched - only for the ones that are *actually* Multiarch: same, right, not the ones that were pruned this cycle because I couldn't find anything that would need them?
<infinity> slangasek: Yeah, only for MA:same stuff that was removed.
<slangasek> infinity: given that an "apt-get install --reinstall libc6-i386" would have also fixed it here, or just, y'know, not removing the multiarch libs that they had installed, I'm pretty indifferent to the idea.  If you want to pick up the pieces if it breaks, though, I have no objections. :)
<infinity> slangasek: Though, as YokoZar points out, it can only be Recommended from ia32-libs, because things build-dep on it.  Does apt pull in new Recommends on upgrade by default?
<slangasek> infinity: yes, it does pull new recommends by default on upgrade
<infinity> slangasek: Oh, I agree that the wine bug appears to just be the loader problem.  I thought that bug was fixed.
<slangasek> unless you use 'apt-get upgrade' instead of 'apt-get dist-upgrade' or equivalent.  So, y'know.  Don't do that.
<infinity> slangasek: But it's still surprising, to say the least, to have a bunch of libs go missing on upgrade if, say, a 3rd party app in /opt was relying on them.
<slangasek> infinity: "fixed" how?  libc6-i386 has to ship the file for biarch; libc6:i386 has to ship it for multiarch (and for the real thing); one package has to replace the other; don't remove that package mmkay
<infinity> slangasek: Can't one just divert the other?
<infinity> slangasek: Overwriting is meant for upgrades, not co-existing packages. :P
<slangasek> infinity: at the cost of an eleventh-hour eglibc upload, and a diverting-shared-libraries-is-pain-and-suffering tango, I guess so?
<slangasek> yes, well, when this was written the hope was that they *wouldn't* coexist for very long... and indeed they won't for much longer, ia32-libs is dead in p
<infinity> slangasek: It's not that bad.  But yes, something before today would have been nice.  Had I known it was still an issue, I might have spoken up.
<infinity> ia32-libs is dead, but is biarch?
<infinity> If biarch lives on, this bug does too.
<slangasek> yeah, I didn't realize it was causing problems in practice
<infinity> And currently, -m32 relies on biarch.  Are there plans to fix that?
<slangasek> infinity: as far as missing something wrt DSOs... did you miss Multi-Arch: allowed?
<slangasek> Laibsch: so the bug in my reasoning before was "it can satisfy dependencies of packages of other architectures because the only interface it provides is via exec()".  This isn't true, there are also package which treat it as "the thing that can load this module".  So it's logically Multi-Arch: allowed, not Multi-Arch: foreign.
<infinity> slangasek: Ahh, yeah, I was operating on the assumption that you had reason to recommend foreign, though, so had some tunnel vision going on. :P
<slangasek> -m32> no plans to fix it, just aspirations
<Laibsch> slangasek: OK, thank you.  I'll adjust things and make sure the path is adjusted at build-time.  I'll ping you in a few hours to ask for a sync to oneiric.
<slangasek> Laibsch: better to ping infinity, I hope to be asleep in a few hours :)
 * infinity passes the buck to pitti.
<slangasek> WFM
<YokoZar> iirc infinity intended to be asleep a few hours AGO ;)
<YokoZar> I gotta fly to wineconf tomorrow night so I intend to be up irrationally late testing out the ia32-libs-multiarch idea.
<infinity> Sounds like a stellar way to spend an evening.
<ubuntu-baltix> Hi all
<ubuntu-baltix> AFAIK today is Non Language pack translations freeze (look at https://wiki.ubuntu.com/OneiricReleaseSchedule), how many hours I have to fix ubiquity-slideshow and ubiquity translations?
<infinity> ubuntu-baltix: Very few.
<ubuntu-baltix> infinity: but how many? Two, three or four?
<infinity> ubuntu-baltix: I always forget what timezone we use for the cutoff. :P
<infinity> ubuntu-baltix: But assume "a lot less than 24" and just get it done.
<TheMuso> 21:00UTC is the cut-off for final freeze.
<TheMuso> On Thursday.
<infinity> ubuntu-baltix: It's not like we'll say no if you're 2 hours "late".  We will if you're 2 days late.
<ubuntu-baltix> infinity: you will do the export from translations.launchpad.net ?
<infinity> Nope.  I believe pitti's the man you probably want to talk to about translations.  And if he's not, he'll know who is. :)
<ubuntu-baltix> pitti: are you alive?
<pitti> unI certainly hope so :)
<pitti> s/un/uhm/ :)
<infinity> Are you sure that wasn't meant to be ub<tab>?
<pitti> ubuntu-baltix: if it can land today, it would be good, but if the changes are small and reviewable, I'd also accept it tomorrow
<ubuntu-baltix> pitti: I think I will finish ubiquity-slideshow and ubiquity translations afer 4 or 5 hours, it's ok?
<pitti> ubuntu-baltix: sounds great, thanks for working on that
<ubuntu-baltix> thanks you for coding free software :)
 * cjwatson remembers to vote in the TB election
<cjwatson> (mentioning this in case anyone else is similarly scatterbrained)
<pitti> getting close, yes :)
<pitti> speaking of getting close, does Perky Penguin have a name yet?
<pitti> we need to upload lintian, vim, devscripts, and the like
<SpamapS> Perfect Piranha you mean?
<slangasek> Pastel Protoceratops
<SpamapS> Penultimate Pterydactyl
<cjwatson> I'd've thought Perky Penguin was a shoe-in given that that name has been held in reserve for about seven years
<dholbach> good morning
<cjwatson> but sabdfl looked nervous last time I asked about the name for P and backed away to consult a dictionary
<infinity> Pastafarian Puffin?
<pitti> infinity: if we ever devote a release to you, I think we call it "incurable insomnia"
<infinity> Insomniac, surely.
 * AlanBell wonders if it will be a more surprising -p name than we expect
<SpamapS> no, insomnia is a beast that feeds on all our brains
<slangasek> Prehensile Platypus
 * RAOF 'd like a Puffin.
<RAOF> Puffins are cool.
<RAOF> Kinda like bow-ties.
<infinity> Puffy Puffin!
<slangasek> and on that note, I'll turn in ;)
<infinity> For once, people could spell the release name.
<slangasek> 'night, folks
<Daviey> Perfect Phuckit
<nigelb> I like the Pterydactyl
<diwic> Planus Pancake
<nigelb> pitti: That would devoted to all Ubuntu and Free software developers :)
<nigelb> (Incurable insomaniac that is)
<pitti> nigelb: but only infinity claims to go to bed at least four times before he finally does :)
<pitti> I think I did at most three, and only once
<nigelb> pitti: hahaha
<SpamapS> Sep 29 03:19:59 mabolo kernel: [124785.393627] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
<SpamapS> Hmm.. thats bad
<janimo> Pining PaRROT
<Daviey> SpamapS: Hmm, so jamespage saw something similar with arm+ext4, and we put it down to a bad disk.  I'm not sure i'm so confident now.
<Daviey> SpamapS: Have you checked SMART or any funky RAID messages that mabolo would likely throw out?
<SpamapS> [124785.015731] hpsa 0000:04:00.0: cp ffff880036d00000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 0e 00 00 00 01 00 00 00 00 00 00 40 ec 00]
<infinity> Looks like hardware to me.
<SpamapS> Daviey: this is mabolo
<SpamapS> Daviey: been pushing it pretty hard
<infinity> pitti: I resent that!
<infinity> pitti: I'll have you know I slept more than 3 hours last night!
<infinity> So there.
<pitti> *boggle*
<infinity> (About 3.5, but still... More than 3!)
<pitti> how can you make-do with that? If I get less than 7, I'm totally useless
<infinity> pitti: Decades of practice, I guess.  I've never slept much.  Every once in a while, it does me in, and I'll pass out for a weekend.
<nigelb> My suspicions that infinity is a bot increases.
<infinity> pitti: But it's not like it's by choice.  I've been like this since I was a small child.
<beta0x64> caffeine?
<infinity> beta0x64: I wasn't on caffeine as a baby, no.  Nor much until I was an adult, really.
<infinity> And not much now either, for that matter.
<beta0x64> :( I was on caffeine as a baby
<infinity> My parents took me to doctors who had all sorts of opinions and ideas until they finally just settled on "whatever, he'll sleep when he's tired and eat when he's hungry".
<beta0x64> you stopped eating too?
<infinity> When I was a kid, I'd go for days without food.  I've managed to more or less fix that.
<infinity> But the sleep thing hasn't changed.
<Daviey> jhunt: Good morning!
<Daviey> jhunt: Do you have any news on bug 818177?
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
<jhunt> Daviey: Not since I updated it last night :)
<Daviey> pah, you english - taking 12 hours off a day.
<tkamppeter> I have tried an upgrade to Oneiric and now the installation is totally locked up
<tkamppeter> On update of Samba it tells that one of the maintainer scripts exited with an error. When I run "apt-get install -f" I get the same and if I run "dpkg -P samba" i tells I should re-install samba, but this does not work.
<tkamppeter> Seems that now only hand-editing the dpkg databse or reformating the system helps.
<tkamppeter> The problem leading to this is bug 862129.
<ubottu> Launchpad bug 862129 in samba (Ubuntu) "package samba 2:3.5.8~dfsg-1ubuntu2.3 failed to install/upgrade: subprocess new post-removal script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/862129
<tkamppeter> Solved, looked into the terminal log attached to the samba crash report and saw that it needed perl-modules. Installed the already downloaded new perl packages from /var/cache/apt/archive/ and upgrade continues ...
<doko> didrocks, compiz ping. is there a new emerald version compatible with compiz 0.9.x? or can it be removed?
<didrocks> doko: I guess emerald is unmaintained now, I would go for removing it if it doesn't work with 0.9
<doko> didrocks, done
<YokoZar> infinity: ok, I have a preliminary package built, uploading to a launchpad PPA to make sure it builds, as this is the first time ia32-libs is "built" on i386
<YokoZar> infinity: (even though the only binary is the dummy package I just made) -- speaking of which, am I going to run into packages-arch-specific trouble?
<doko> pitti: still planning to address avidemux?
<doko> apw, still planning to address uns?
<pitti> doko: yes, just kept pushing it out as there has always been some RC bug or release stuff to attend to
<YokoZar> pitti: any comment on the ia32-libs-multiarch discussion above (I believe infinity/slangasek passed the buck to you due to sleep issues) ;)
<doko> soren, still planning to address user-mode-linux?
<pitti> YokoZar: didn't read, reading backscroll
<apw> doko, i spent some time on it, but i don't think we will get the current version in there working in short order.  there is a more up to date version which we might sub in, but it a big jump and i don't have any obvious way to test it
<infinity> YokoZar / pitti: I passed something to pitti, but it wasn't the above.  I intend to review/test/mangle it when I wake up.  Unless Martin really wants to put in the effort. :P
<pitti> I'm still trying to find out what this is all about
<infinity> pitti: Don't worry about it, I'll get to it in the morning. :)
<pitti> but if it's more complicated than a two-line explanation, it's very probably out of scope for oneiric :)
 * pitti takes infinity's word and stops worrying
<YokoZar> pitti: executive summary is a dummy i386 multiarch:foreign package depending on all the libs removed from ia32-libs
<YokoZar> *removed = removed because they are multiarch
<debfx> pitti: could you remove kipi-plugins from the archive, bug #857689
<ubottu> Launchpad bug 857689 in kipi-plugins (Ubuntu) "Please remove kipi-plugins source package" [Wishlist,Confirmed] https://launchpad.net/bugs/857689
<pitti> debfx: done
<doko> apw, ok, I'll just remove the binary packages, and keep the source for now
<debfx> thanks!
<apw> doko, seems like a plan, we'll revisit it for P and see what we can do there
<apw> doko, got the bug number to hand, seem to have lost it
<doko> apw, 756096. if it's definitely for P only, then I'll remove the source too
<apw> doko, as its something vendors are likely to ask for i suspect it'd be good to keep the option to reinject it there
<doko> ok, binaries only
<apw> would we be able to bump the version agressivly at this stage ?
<doko> apw, why not, there are no rdepends
<apw> ok thanks
<tseliot> cjwatson: I'm trying to blacklist all nvidia cards so that grub doesn't set an fb (which breaks things in recovery mode) but I can't seem to do it. Here's the file that I'm using (10DE means Nvidia). I also tried using lowercase (10de). Any ideas as to how I can debug this? http://pastebin.ubuntu.com/699033/Ã¹
<tseliot> cjwatson: http://pastebin.ubuntu.com/699033/
<apw> tseliot, maybe needing a * at the front ?  isn't there a vga: or something on the frnt
<tseliot> apw: maybe something like this (which I can see in modinfo)? pci:v000010DEd*
<apw> worth a try
<apw> i just have the feeling there is something at the front
<apw> i'd test with a * there and see what happens
<tseliot> right, let's try that
<tseliot> apw: I tried with both a ".*" and with an "*" but it doesn't seem to work
<tseliot> apw: I can see other blacklisted devices though in the file, such as v15add0710.*
<cjwatson> tseliot: it should definitely be .* not *
<cjwatson> it's a regex
<tseliot> right
<apw> v000010ded*sv*sd*bc03sc*i*
<apw> so all the *'s need to be .* then yes
<cjwatson> the hexits should be lower-case
<tseliot> ok
<cjwatson> then try 'hwmatch ${prefix}/gfxblacklist.txt 3' by hand to see what it says
<tseliot> cjwatson: is hwmatch somewhere in grub?
<apw> grub command line
<cjwatson> I've uploaded a new grub-gfxpayload-lists that says that explicitly
<cjwatson> yes, what apw said
<tseliot> ok
<tseliot> cjwatson: nothing seems to happen when I enter that command
<apw> $? and $match tell you things
<apw> echo those
<tseliot> apw: yes, I've already tried $? and it's 0
<tseliot> apw: and so is $match
<cjwatson> that means "command succeeded but no match"
<tseliot> I should probably try some greedy matching
 * tseliot -> lunch
<cjwatson> the output of grub's lspci command might not hurt
<tseliot> apw, cjwatson: 02:00.0 10de:0ca3 [0300] VGA Controller
<cjwatson> tseliot: what's the i at the end meant to match?
<cjwatson> the format is vVENDORdDEVICEsvSUBVENDORsdSUBDEVICEbcBASECLASSscSUBCLASS; SUBCLASS can't contain i
<cjwatson> it's matched against v%04xd%04xsv%04xsd%04xbc%02xsc%02x
<cjwatson> ah, so that also wants to be v10de... not v000010de...
<cjwatson> so I think you want: v10ded.*sv.*sd.*bc03sc.*
<tseliot> cjwatson: I suspected that the first 4 zero were the problem. Let me try..
<tseliot> apw, cjwatson: it works now. Thanks for your help
<cjwatson> excellent
<YokoZar> infinity: I'm off to bed but my computer is still uploading ia32-libs-multiarch to this PPA: https://launchpad.net/~scottritchie/+archive/build-tests
<penguin42> I don't suppose it includes freeglut does it?  I noticed freeglut doesn't like installing 32 and 64bit versions together
<YokoZar> penguin42: freeglut was removed from ia32-libs cause only wine was using it and wine no longer uses it...did you have another app that needed it?
<penguin42> YokoZar: fold.it
<penguin42> YokoZar: It's not packaged
<penguin42> (see http://fold.it )
<YokoZar> ahh, that game :D
<penguin42> YokoZar: Yeh, I thought I'd give it a go since they'd been nice enough to provide a linux version
<YokoZar> penguin42: does it work on natty (with natty freeglut)?
<penguin42> YokoZar: I don't have any natty boxes any more
<penguin42> YokoZar: I reported it as bug 859038
<ubottu> Launchpad bug 859038 in freeglut (Ubuntu) "[Oneiric] 32bit freeglut won't install with 64bit" [Undecided,New] https://launchpad.net/bugs/859038
<YokoZar> penguin42: Yup, freeglut isn't multiarch ready.  I suppose adding it back to ia32-libs would be the correct thing to do...earlier in the cycle...
<penguin42> YokoZar: Well if you remover a library there will always be some madman who wanted it!
<YokoZar> penguin42: so you'd think, except that wasn't the case with most the other libraries removed :D
<YokoZar> (To be fair, I was usually the madman demanding stuff in for Wine purposes)
<hrw> does someone has pbuilder hook which installs all built packages in chroot (to check installability)?
<ScottK> hrw: I don't, but it sounds like it ought to be easy enough to do.
 * ogra_ bets persia would have such a hook 
<ogra_> but i doubt he is online
 * Daviey just went on a blueprint status binge, i'm expecting to see a decent drop in the burndown chart when it next updates \o/
<hallyn> Daviey: yeah, your comment on 828785 makes me laugh and cry at the same time :)
<Daviey> bug 828785
<ubottu> Launchpad bug 828785 in Ubuntu Oneiric "[FFE] Please sync spice-gtk (0.7-2) from debian unstable (main)" [Undecided,Incomplete] https://launchpad.net/bugs/828785
<Daviey> hallyn: Yeah, it's been like a zombie process that will not die...
<mvo> pitti: a question about bug #834403 and the way apport marked dupes. the issue itself is pretty straightforward and I have a fix, but I wonder if the StackTrace that is used for the duplication finding is always only the top (which is always _XError, _XReply) or will it look further? the bug is a bit concerning, it has 76 me-toos already
<ubottu> Launchpad bug 834403 in software-center (Ubuntu) "software-center crashed with signal 5 in _XError()" [Medium,Confirmed] https://launchpad.net/bugs/834403
<Daviey> There seemed to have been much interaction between you and Boris, which made me wonder if a plan was reached.
<pitti> mvo: it only uses the top 5 items
<pitti> mvo: s/items/function names/
<pitti> mvo: that's bad in these cases indeed; there are similar cases with glibc's and glib's assert() stuff, but apport has some code to unwind the stack to the first "interesting" one
<Laney> sladen: Err, am I doing something wrong? I just updated ttf-ubuntu-font-family to 0.80~rc-0ubuntu1+arabic and now my terminal looks like http://orangesquash.org.uk/~laney/tasty.png (full disclosure: on a sid system)
<pitti> mvo: I suppose we need to add something similar for XError(), same problem in bug 848808
<ubottu> Launchpad bug 848808 in overlay-scrollbar (Ubuntu Oneiric) "metacity crashed with SIGABRT in __kernel_vsyscall() with overlay-scrollbars" [High,Triaged] https://launchpad.net/bugs/848808
<mvo> pitti: is there a way to get to the data of the duplicates? I would like to investigate the data myself
<pitti> mvo: I. e. the duplicate finder looks at StacktraceTop
 * ScottK filed a bug about this yesterday.
<pitti> mvo: I'm afraid there isn't; the core dumps are removed after the retracer looks at them
<pitti> ScottK: ah, was just about to do that -- which one?
<ScottK> It wasn't Xerror exactly.  Let me find it.
<pitti> so, it unwound the g_logv() stuff, but not until XError
<ScottK> pitti: Bug 861645 is the one I found.
<ubottu> Launchpad bug 861645 in apport (Ubuntu) "Apport retracer dupes bugs that aren't dupes" [Undecided,New] https://launchpad.net/bugs/861645
<ScottK> It's a similar question of not digging far enough into the traceback.
<mvo> pitti: hm, thanks. would it be possible to get a quick fix in for this so that the duplication detection is disabled if there is  a XError ? I would love to know if its all the libcanberra issue that I diagnosed or if there is more to it
<hrw> ScottK, ogra: will write one ;)
<ScottK> Nice.
<pitti> ScottK: actually, it's not a problem of depth there
<pitti> ScottK: just that it's two different KeyError bugs in the same function
<pitti> so it's a different "class" of failure
<ScottK> I see.
<yofel> hrw: works for me: http://paste.kde.org/128749 (as ~/.pbuilder-hooks/B11installbuilt)
<pitti> mvo: I don't think we should disable it; it should just unwind the stack enough, just looking at how much exactly
<ScottK> I took it as depth in needing to look at the actual key and not just the error class.
<yofel> could be improved I guess
<pitti> mvo: yes, I'll work on this right now
<mvo> pitti: thanks a lot!
<hrw> yofel: thx
<sladen> Laney: try choosing 'Ubuntu Mono' instead of 'Ubuntu' as your terminal font
<Laney> sladen: I just noticed I had another update pending, 1s
<Laney> it was on Ubuntu mono btw; but now looks fine again :-)
<sladen> Laney: probably it was on 'UbuntuBeta Monospaced'
<Laney> ah, possibly
<sladen> Laney: although sometime in the next 8 hours we'll probably change the default monospace font anyway
<Laney> have you got a bug about the unicode arrow characters being spaced wrongly? (xây)
<sladen> Laney: http://launchpad.net/ubuntu-font-family/+filebug?field.title=Mono:+please+add+left/right+arrows
<nigelb> hahahaha
<nigelb> I didn't understand what happened there for a full minute
<Laney> Dear JAnet, please resume working. No love, Iain.
<ahasenack> I guys, I believe landscape-client can be moved from -proposed to -updates? It's been a week if my calculations are correct, and all bugs have been verified: https://bugs.launchpad.net/bugs/813477
<ubottu> Ubuntu bug 813477 in landscape-client (Ubuntu Natty) "Update landscape-client to 11.07.1.1" [Undecided,New]
<ahasenack> s/I/Hi/
<pitti> mvo: ok, have a patch
<mvo> pitti: \o/
<pitti> on https://launchpadlibrarian.net/79769114/Stacktrace.txt the topmost one is now #11 meta_display_get_current_time_roundtrip
<pitti> mvo: on https://launchpadlibrarian.net/78125841/Stacktrace.txt it is #8 XGetWindowProperty
<pitti> on https://launchpadlibrarian.net/81397067/sync-stacktrace.txt it is #12 XCreatePixmap
<pitti> mvo: that should cut off just enough _X* common goo to be useful again
<mvo> pitti: nice
<kirkland> didrocks: ping
<didrocks> kirkland: pong
<kirkland> didrocks: can you help me triage https://bugs.launchpad.net/ubuntu/+source/unity/+bug/861726 ?
<ubottu> Ubuntu bug 861726 in unity (Ubuntu Oneiric) "[regression] byobu application not launching from panel" [High,Incomplete]
<seb128> kirkland, you want to talk to kamstrup rather than didrocks I guess ;-)
<kirkland> seb128: thanks
<didrocks> seb128: kamstrup for panel?
<didrocks> or is it the dash
<kirkland> seb128: i don't see a kamstrup online?
<didrocks> (launchpad is timeouting)
<didrocks> ah dash
<didrocks> yeah, kamstrup :)
<seb128> kirkland, he timeouted just a bit before
<kirkland> seb128: k
<seb128> kirkland, I guess he will be back
<pitti> mvo: ok, committed and rolled out into the retracer bots
<pitti> bring'em on!
<pitti> mvo: (no real need to upload that to oneiric)
<alexbligh> If I have a package with a trivial rules file, what is the proper way to change the PRIORITY of an init script installed from debian/packagename.init
<mbiebl> RAOF: I talked to davidz about your patch
<mbiebl> I'd like to see this fixed in PK proper instead of using the at_console approach
<YokoZar> Can I put libqtwebkit4 back in ia32-libs?  It's multiarched but depends on libgstreamer which isn't (but is in ia32-libs)
<pitti> doko: avidemux FTBFS is a pain; we already removed the binaries, so fixing this is not really release critical, right?
<intgr> pitti: Hi. If you're not too busy: I just upgraded from PostgreSQL 9.0 to 9.1.1 on Ubuntu 10.04 and now every time I run psql I get "DEB_HOST_MULTIARCH is not a supported variable name at /usr/bin/dpkg-architecture"
<intgr> Using your PPA
<intgr> I couldn't find anything relevant on Google
<pitti> intgr: oh, I know
<pitti> intgr: is that actually breaking psql, or just an extra warning message?
<pitti> intgr: can you please file a bug against postgresql-common about it and assign to me? sorry, need to run now
<pitti> good night everyone
<intgr> Just a message. Which is kinda annoying because I run it every minute from cron :)
<intgr> Ok
<doko> pitti, sure, didn't notice that the binaries were removed
<Sweetshark> it there any easy way to check which packages are on the install CD
<Sweetshark> ?
<janimo> Sweetshark, loooking at the manifest files near the ISOs on the site?
<alexbligh> OK, let me ask again more precisely. dh_installinit --update-rcd-params='defaults 98 02' fails, as does any combination of --, quotes no quotes etc. I try, with the arcane error "Duplicate specification "O=s" for option "O"
<alexbligh> " what does that mean?
<janimo> Sweetshark, ex http://cdimage.ubuntu.com/daily-live/20110929/oneiric-desktop-amd64.manifest
<Sweetshark> janimo: thanks.
<Daviey> jhunt: Can i be an ass, and ask how bug 818177 is looking?
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
<Daviey> (causing me great concern)
<janimo> Sweetshark, can LibO be crossbuilt now for linux targets (ex:ARM)?
<Sweetshark> janimo: there is general work done on crosscompiling, but mostly to get minGW builds on windows and some Android/iOS work. Even if we could finish a crosscompile like that, I wouldnt trust the result yet.
<Sweetshark> (a armel crosscompile that is)
<janimo> Sweetshark, ok thanks.
<pitti> Sweetshark: apt-cache show <pkgname>, look at Tasks:
<pitti> Sweetshark: that will also show packages which are only on ubuntustudio or xubuntu
<intgr> The problem cannot be reported: This is not a genuine Ubuntu package
<intgr> Does anyone know how to use this Launchpad thing to report bugs?
<intgr> Oops, wrong channel, sorry
<pitti> intgr: ah, because it's a backport
<pitti> intgr: https://launchpad.net/ubuntu/+source/postgresql-common/+filebug
<intgr> Thanks :)
<YokoZar> infinity: slangasek: ok, after a whole night of poking at it I think I have a workable version of the ia32-libs-multiarch.  Uploading for review now, should finish in an hour or so (better than the two versions that were in my PPAs)
<infinity> YokoZar: If the upload will take more than a few seconds, there's something wrong..
<jtaylor> doko: did xdotool fail to build on all architectures now? bug 823704
<ubottu> Launchpad bug 823704 in xdotool (Ubuntu Oneiric) "xdotool version 1:2.20110530.1-3 failed to build" [High,Confirmed] https://launchpad.net/bugs/823704
<jtaylor> I'd rather not have it removed, I use it daily ._.
<slangasek> infinity: uploading ia32-libs in a few seconds?
<doko> jtaylor, see my pending upload
<infinity> slangasek: Oh, right, ia32-libs control change.  I didn't infer that from his comment. :)
<jtaylor> doko: where can I see that?
<slangasek> infinity: :)  I in fact assumed ia32-libs-multiarch would also be built from the same source package, since -multiarch should normally be updated in tandem
<infinity> slangasek: Stop making sense, I haven't had enough coffee.
<jtaylor> hm indeed it fails for me on amd64 now too ... but its working fine, probably better to just disable the testsuite as it was before the last upload anyway
<jtaylor> doko: please don't remove it, I'll have a look this weekend, and if that is not successful I'll disable the testsuite, the package is useful to remove it just because of one unreproducable testcase
<Sweetshark> pitti: thanks
<slangasek> YokoZar: it might behoove you to post a diff somewhere, so we can review and give feedback a bit more nimbly?
<slangasek> rather than having an hour+ round trip between each iteration :)
<cr3> cyphermox: hola senor, we have a checkbox candidate that we would appreciate merged before final freeze. see bug #862579, the branch is about to be attached
<ubottu> Launchpad bug 862579 in checkbox (Ubuntu) "Candidate revision checkbox_0.12.8" [Undecided,New] https://launchpad.net/bugs/862579
<cr3> cyphermox: could you handle that and, if not, could you recommend someone perhaps?
<ScottK> slangasek: Noting the "dpkg predependency against tar >= 1.23, objections?" discussion on debian-devel, assuming we merge that change in for "P" it will complicate Lucid -> "P" upgrades.
<ScottK> FYI in case you think it ought to be discussed.
<cyphermox> cr3: I was going to point you to the current patch pilot because I'm a little busy, but I don't think robert_ancell is available to do it now :)
<cyphermox> cr3: so, sure, I'll look at it now :)
<cr3> cyphermox: thanks man! here's the merge proposal: https://code.launchpad.net/~roadmr/ubuntu/oneiric/checkbox/0.12.8/+merge/77574
<soren> doko: Yes.
<cyphermox> cr3: I'm concerned by the string change for the intro prompt, the translations don't seem to be matching this or translating the added warning.
<cyphermox> cr3: indeed, the extra string appended to the intro_prompt for warning isn't being translated.
<cyphermox> cr3: and so I feel checkbox should have an UI Freeze bug; see https://wiki.ubuntu.com/UserInterfaceFreeze
<mdeslaur> mvo: fyi I just got hit with bug 848676 on an up-to-date machine
<ubottu> Launchpad bug 848676 in software-center (Ubuntu) "[MASTER] software-center crashed with DBusException in _convert_dbus_exception(): org.freedesktop.DBus.Error.UnknownMethod: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist" [High,Confirmed] https://launchpad.net/bugs/848676
<mdeslaur> mvo: although it's supposedly fixed already
<Laney> did something change in gconf to make these crashes happen?
<Keybuk> W: Failed to fetch http://ppa.launchpad.net/pidgin-developers/ppa/ubuntu/dists/lucid/main/binary-amd64/Packages.gz  403  Forbidden [IP: ::ffff:172.16.255.22 3129]
<Keybuk> ... wait, what?!
<Laney> banshee has something similar too
<mvo> mdeslaur: indeed it is â¦ what happend, did you get a apport window? did the app itself crash?
<mvo> mdeslaur: I have a look at the code
<mvo> mdeslaur: same backtrace, line   File "/usr/share/software-center/softwarecenter/ui/gtk3/models/pendingstore.py", line 75, in _on_lowlevel_transactions_changed
<mdeslaur> mvo: I opened software center for the first time, typed "skype" in the search box, clicked on skype, clicked on "enable partner repo", and got an apport window
<mvo> ?
<mdeslaur> mvo: uh, let me check...LP just told me it was a dupe
<mdeslaur> mvo: nope, completely different backtrace
<mvo> mdeslaur: could you pastebin it please?
<Daviey> jdstrand: If you are happy with bug #862567, can you Confirm bug 860492 please?
<ubottu> Launchpad bug 862567 in cobbler-enlist (Ubuntu Oneiric) "debconf and documentation should mention lack of SSL" [High,Fix released] https://launchpad.net/bugs/862567
<ubottu> Launchpad bug 860492 in cobbler-enlist (Ubuntu Oneiric) "[MIR] cobbler-enlist src, cobbler-enlist-udeb bin" [High,In progress] https://launchpad.net/bugs/860492
<mdeslaur> mvo: paste.ubuntu.com/699251
<mvo> mdeslaur: thanks, fixed in trunk now
<mdeslaur> mvo: wow, that didn't take long :)
<mvo> mdeslaur: no, the same class of error that got fixed before, I just overlooked one call
<mdeslaur> mvo: ah, I see...cool. thanks!
<mvo> thank you for the backtrace, that made it realy easy
<mdeslaur> mvo: you're welcome
<cr3> cyphermox: we already have an accepted UI freeze exception bug which has been approved, see bug #855328. do we need another bug?
<ubottu> Launchpad bug 855328 in checkbox "String Freeze Exception: The welcome screen should warn the user from possible data loss" [Critical,Fix committed] https://launchpad.net/bugs/855328
<cr3> roadmr: hi there, I just asked cyphermox if we need another bug
<roadmr> cr3, cyphermox : re!
<cyphermox> sorry, no, that's good
<cyphermox> sorry, I just didn't see it
<roadmr> cyphermox: thanks!
<cr3> cyphermox: nor did I, all good :)
<jdstrand> Daviey: done
<roadmr> cyphermox: oops, I didn't set ubuntu-sponsors as reviewer for the checkbox merge request :-/ is there a problem if I do it now?
<cyphermox> well, no need to since I'm already reviewing it, but next time it would be best if you did
<cyphermox> also, I think it's no longer an issue with the sponsoring queue
<roadmr> cyphermox: ok, I'll leave it as it is then, best not to frob the bug :) thanks
<cyphermox> roadmr: it shows up here: http://reqorts.qa.ubuntu.com/reports/sponsoring/ which is what you want :)
<Daviey> jdstrand: thanks!
<slangasek> ScottK: commented on the dpkg thread, thanks
<ScottK> Great.
<ogra_> Laney, hmm, in your last mono upload, did you include all the ubuntu arm hacks/patches ? i dont see them in the changelog (and apparently banshee stopped working)
<Laney> ogra_: I thought they were supposed to be included in Debian / upstream or something
<Laney> directhex might know
<directhex> snuh?
* infinity changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | 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: robert_ancell
<hallyn> is anyone here very familiar with grantpt and ptsname in glibc?
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | 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: TheMuso, robert_ancell
<robert_ancell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | 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: TheMuso
* leguin.freenode.net changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | 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: TheMuso, robert_ancell
#ubuntu-devel 2011-09-30
<slangasek> smoser: to be clear, I'm stalled on this udev console bug until I get some more data from a system that reproduces it
<TheMuso> Does anybody else think this update is more than just bug fixes? https://code.launchpad.net/~cairo-dock-team/ubuntu/oneiric/cairo-dock/2.4.0-1/+merge/77045
<TheMuso> Code has been re-organised/erwritten according to that changelog, and this late in the cycle, that doesn't sit well with me...
<slangasek> TheMuso: I wouldn't merge it.  Object lesson in feature freeze?
<TheMuso> Thats what I'm thinking.
<TheMuso> I'd already started writing a feature freeze response, but thought a second opinion would be useful. Thanks.
<smoser> slangasek, yeah. i'll get you some more debug output tomorrow.
<slangasek> smoser: ok, cheers :)
<smoser> slangasek, one thing i fear is that the recent upgrade in canonistack improves performance of guests, and that i'm not going to see the issue any more.
<slangasek> heh
<happyaron> ev: would you sync translations of the slideshow from Launchpad again before final release?
<happyaron> ev: it would be great if you can sync it again, I found some last minute changes from translators wasn't included into version 48. thank you.
<TheMuso> `/c
<Bijanbina> Hi does any body know how can i add a package to official ubuntu packages i mean for install a software not need to add repository
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | 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: robert_ancell
<pitti> Good morning
<TheMuso> Morning pitti.
<YokoZar> slangasek: infinity: Not sure what to do about https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/862925  since I had the symlinks removed.  I do think it appropriate to add libllvm2.9:i386 to ia32-libs-multiarch however.
<ubottu> Ubuntu bug 862925 in wine1.3 (Ubuntu) "latest ia32 changes breaks 3d support in wine" [Undecided,New]
<Sarvatt> Yokozar: personally I think it's crazy to not sync multiarch libpciaccess from debian unstable so libgl1-mesa-dri:i386 is installable and then add that to ia32-libs-multiarch, as it is now we have no accelerated 32 bit GL on amd64
<Sarvatt> unless you use proprietary drivers
<pitti> cnd: still online by any chance?
<pitti> cnd: ah, was going to ask about bug 744911 and the diverged bzr branch, followed up in the bug now
<ubottu> Launchpad bug 744911 in libgrip (Ubuntu) "Libgrip needs developer documentation" [Undecided,Triaged] https://launchpad.net/bugs/744911
<cnd> pitti, I'll take a look in a minute
<cnd> while I know you're up :), I wanted to ask about ppas and dbgsym packages
<cnd> someone said earlier this week that there's no where to publish them too
<cnd> is that in the works?
<pitti> cnd: dpm requested this for developer.u.c.; I can ignore the inconsistent bzr and just upload this if you say the word; otherwise I'll let you bring real world and bzr into agreement again and apply the doc patch
<pitti> cnd: I don't think there's any actual work on this happening right now
<cnd> hmmmâ¦ that's a shame
<cnd> ok
<pitti> cnd: from what wgrant told me last time, the soyuz side is pretty much ready, but there are no archives to publish them to
<cnd> that doesn't seem like an overly complex task to me :)
<pitti> and that's again blocked by not being able to clean up old ddebs, IIRC
<cnd> but I don't really know
<cnd> ahh
<wgrant> PPA changelogs in update-manager are blocked by issues cleaning them up. ddebs are blocked by there being far too many edge cases to track down and fix.
<wgrant> However, the bug has been escalated. So a maintenance squad may pick it up eventually.
<wgrant> But it's unlikely to happen until I'm back on maintenance, which will probably be March-May next year.
<cnd> wgrant: ok
<cnd> wgrant: is there a way I can help make add my vote for the feature?
<cnd> like a bug I can click the me too button on?
<cnd> pitti: lp:libgrip/ubuntu is ahead of the archive
<cnd> when you said it's out of date, did you mean that it's just different?
<pitti> cnd: no, not ahead
<slangasek> YokoZar: 862925 is a duplicate of bug #821100, this is the expected result
<ubottu> Launchpad bug 821100 in ia32-libs (Ubuntu) "ia32-libs does not install /usr/lib32/libGL.so.1" [High,Fix released] https://launchpad.net/bugs/821100
<pitti> cnd: "besides"
<pitti> cnd: https://launchpad.net/ubuntu/+source/libgrip/0.3.2-0ubuntu2
<pitti> cnd: that upload isn't in bzr+ssh://bazaar.launchpad.net/%2Bbranch/libgrip/ubuntu/
<slangasek> YokoZar: trying to fix it "better" for this cycle will just make it worse
<wgrant> cnd: Bug #747558
<ubottu> Launchpad bug 747558 in Launchpad itself "PPAs should create backtracable packages" [Critical,Triaged] https://launchpad.net/bugs/747558
<cnd> pitti: oh, I see
<pitti> cnd: that bzr has an unreleased 0.3.2-0ubuntu2 with a different change
<cnd> pitti: we branched it at 0.3.2-0ubuntu1
<cnd> so your patch is against lp:libgrip/oneiric
<pitti> cnd: ah, should I use that?
<cnd> but should also go into lp:libgrip/ubuntu
<cnd> yeah
<pitti> cnd: btw, Vcs-Bzr: is invalid
<pitti> debcheckout -a libgrip
<pitti> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/libgrip/ubuntu/".
<cnd> hrmmmâ¦ ok, I'll look into it
<pitti> cnd: want me to fix up Vcs-Bzr and apply the doc patch to ubuntu and oneiric and upload, or do you want to?
<cnd> pitti: you can do it
<cnd> I'm going to go to bed :)
<pitti> cnd: ack
<cnd> if you're not overworked that is
<cnd> I can get to it tomorrow if you have better things to do
<cnd> hmmâ¦ I wonder what the libgrip documention looks like...
<cnd> gah, why does oneiric keep suspending my laptop...
<pitti> cnd: after 30 minutes of being idle?
<cnd> yeah
<pitti> that's a known bug, being worked on
<cnd> ok
<pitti> (and yeah, it's really annoying)
<cnd> I just upgraded my netbook today
<cnd> it *always* decides to do stupid things when I upgrade it
<cnd> I don't think I've ever gotten through an entire upgrade on it
<cnd> and it was installed with lucid IIRC
<pitti> cnd: ok, trunk branch updated, now doing /oneiric
<cnd> this time, intel graphics decided to "lose" the framebuffer
<cnd> awesome
<cnd> pitti: ahh, the link I had in Vcs-Bzr works in a browser
<cnd> so I assumed it would work for bzr
<pitti> cnd: right, but it's not pointing to a branch
<pitti> it's more like a project page
<cnd> pitti: so to get around the missing dbgsyms in our daily ppas, I committed revision 34 in the ubuntu branch
<cnd> does that seem reasonable to you?
<pitti> cnd: sure
<cnd> ok
<pitti> cnd: that, or just build a -dbg package
<pitti> but unstripped in PPA sounds fine
<cnd> pitti: is it possible to conditionally build a package?
<cnd> I don't want to pollute the ubuntu archive with unnecessary -dbg packages
<pitti> cnd: yes, it is
<cnd> but if I can conditionally build a -dbg package when it's a native daily build, then that would work
<infinity> grep /CurrentlyBuilding for "Purpose: PPA"
<pitti> cnd: you can do something like dh_builddeb -Nlibgrip-dbg
<pitti> (if you are doing a PPA build)
<pitti> (untested)
<wgrant> infinity: EVIL
<infinity> wgrant: Yup.
<infinity> wgrant: The kernel packages have been doing it for years. :P
<wgrant> Yeah :(
<pitti> infinity: cnd has an "autogen.sh exists" test, which is good enough for daily build recipes
<infinity> pitti: Sure. ;)
<infinity> Version checks can work too, if you're sane about how you version.
<infinity> Also, I seem to have just killed an external hard drive.
<infinity> Bother.
<pitti> eek
<StevenK> That's what you get for propagating evil.
<pitti> infinity: all your pr0n^Wclassic music collection gone?
<StevenK> Haha
<infinity> pitti: A bunch of media and full Debian and Ubuntu mirrors.
<infinity> It's not a small hard drive.
<cnd> pitti: I was worried the documentation would be invalid, but it seems to be reasonable
<cnd> thanks for the patch!
<maum> infinity: are you the one who developed wxpython toolkit?
<pitti> cnd: looks fine in devhelp to me
<infinity> maum: Nope.  Should I be?
<maum> infinity: no, I just ask you because your nick is same
<diwic> anyone in the mood for sponsoring bug 862553?
<ubottu> Launchpad bug 862553 in libcanberra (Ubuntu) "Latest libcanberra update causes Firefox and Thunderbird to crash on startup" [Critical,Triaged] https://launchpad.net/bugs/862553
<infinity> maum: I've been this same infinity for a couple of decades, but I assure you I had nothing to do with wxpython.
<maum> infinity: ok nervermind, I am just curious about it.
<didrocks> good morning
<maum> morning didrocks
<didrocks> hey maum
<maum> hello
<infinity> Friggin' hardware.
<infinity> "Flip the power switch a few hundred times, and it'll spin up".  That needs to be in the owner's manual.
<StevenK> Hit it with a hammer. That will help.
<StevenK> ... your blood pressure.
<pitti> diwic: much appreciated, will do
<diwic> pitti, thanks
<dholbach> good morning
<ubuntu-baltix> hello all
<ubuntu-baltix> Maybe someone can update http://people.ubuntu.com/~dylanmccall/ubiquity-slideshow-ubuntu/preview/ ?
<ubuntu-baltix> Yesterday evening I've finished translations of ubiquity-slideshow-ubuntu and wanna see slides with new translation ;)
<ubuntu-baltix> pitti: Maybe you know someone, who can update http://people.ubuntu.com/~dylanmccall/ubiquity-slideshow-ubuntu/preview/ ? ;)
<pitti> dylanmccall presumably :)
<ubuntu-baltix> pitti: Yea, I was afraid of this answer...
<infinity> Dearest udev, no it's not cool to spin my CPU to 100%.  No love, Adam.
<RAOF> Lies.
<RAOF> It's always cool to spin!
<infinity> Oh, look at that, restarting it made its 17 children go away.
<infinity> Imagine that.
<infinity> wgrant: Does the response to #276629 mean "... and we'll be fixing cruft in a better way RSN", or is it just "Ha ha ha, we removed the tool, so no more bugs"?
<infinity> wgrant: Actually, I guess ubuntu-archive already has better NBS tools anyway. :P
<wgrant> infinity: It's cjwatson's problem now. He deleted it from LP yesterday :)
<wgrant> I believe it's now maintained exterally.
<infinity> wgrant: Yeah.  Makes sense for us to claim ownership of all those tools as they become decoupled from the source itself.
<diwic> mvo, I can take care of upstreaming bug 862553 and keep you in cc, if you like?
<ubottu> Launchpad bug 862553 in libcanberra (Ubuntu) "Latest libcanberra update causes Firefox and Thunderbird to crash on startup" [Critical,Fix released] https://launchpad.net/bugs/862553
<mvo> diwic: that would be nice
<diwic> mvo, ok will do!
<mvo> diwic: well, the fix is pretty simple, gdk_flush(); gdk_error_trap_pop() - I don't get it still, isn't that a gtk3 module?
<diwic> mvo, the same code is compiled for both gtk3 and gtk2
<diwic> mvo, and _pop_ignore is not present in gtk2
<mvo> diwic: ohhhh, ok, thanks, that explains it
<mvo> diwic: yeah, I knew that, I just did not know that it was build for gtk2 and that the build wouldn't fail. thanks a bunch for taking care of this!
<diwic> mvo, btw, you agree that _pop would be the gtk2 equivalent of _pop_ignore in gtk3?
<mvo> diwic: gdk_flush(); _pop() should be the same, but the flush() is important
<mvo> diwic: in gtk3 this is done automatically by the pop_ignored(), but in gtk2 its not done automatically
<diwic> mvo, yeah, it's a little confusing that the gtk2 module doesn't give a compile error imo
<mvo> diwic: absolutely!
<tumbleweed> cyphermox (and bhavi, who isn't around): Have you ever considered doing occasional backports of mobile-broadband-provider-info? It strikes me as something that'd be useful to occasionally update in older releases
<pitti> tumbleweed, cyphermox: FYI, that even got an approved standing SRU exception: https://wiki.ubuntu.com/StableReleaseUpdates#mobile-broadband-provider-info
<tumbleweed> I'm asking because someone was asking on a lug list, saying "obviously" it doesn't have $relatively-new-provider
<tumbleweed> (err, asking what athe settings where)
<infinity> Whenever I need a pick-me-up, https://bugs.freedesktop.org/show_bug.cgi?id=39752 never ceases to make me smile.
<ubottu> Freedesktop bug 39752 in Administration "Large areas of human life not covered by any category!" [Major,Resolved: notourbug]
<pitti> infinity: -08-02, is that April 1st times two?
<infinity> pitti: Sadly, no.  I think the dude really was a nutter.
<infinity> Almost as awesome as the guy who couldn't figure out how to attach his xorg.conf, so he printed it.  Scanned it.  And sent Daniel an image.
<pitti> via fax?
<infinity> Nope.  He attached the image to an email.  He knew how to do that!
<infinity> (And I scoffed at that until I had that same conversation with my mother very recently.. "Oh, I didn't realise that word documents were like pictures, I can attach them the same way?!")
<pitti> files are hrad
<pitti> ... so is typing
<dholbach> bug 10673, bug 13436 and bug 21507 will always be part of my favourites
<ubottu> Launchpad bug 10673 in dpkg (Ubuntu) "dpkg interface is confusing" [Wishlist,Invalid] https://launchpad.net/bugs/10673
<ubottu> Launchpad bug 13436 in xscreensaver (Ubuntu) "Bouncing Cow Must Go!" [Medium,Fix released] https://launchpad.net/bugs/13436
<ubottu> Launchpad bug 21507 in rss-glx (Ubuntu) "Disturbing sounds in Skyrocket screensaver" [Medium,Fix released] https://launchpad.net/bugs/21507
<ogra_> yay
<cjwatson> wgrant: feel free to reassign such things to ubuntu-archive-tools (I've done that now for this one)
<cjwatson> wgrant: er, "this one" being #276629
<Daviey> cjwatson: Would you be able to look at https://code.launchpad.net/~davewalker/debian-cd/server-add-enlist/+merge/77143 today, pretty please? :)
<bigjools> cyphermox: ping for when you are around please
<cjwatson> Daviey: done and deployed
<Daviey> cjwatson: Thanks!
<wgrant> cjwatson: Ah, so that's where it lives. Thanks!
<cyphermox> bigjools: pong.
<cjwatson> bjf: could http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html be generated more often?  it seems to be daily at the moment, which is awfully long when one is working on the list
<Daviey> Is Desktop taking ~4 mins to boot to lightdm for anyone else?  /me notes he needs to look at his bootchart.
<Daviey> Recent frequent mouse/touchpad lockups aswell?
<hrw> is there a way to mark bug (against ubuntu package) as 'do not spam it with qa bot'?
<ogra_> Daviey, its taking very long, but i'm on arm so that doesnt mean much
<ogra_> its definitely a lot slower than nattys gdm was (havent tried oneirics gdm)
<Daviey> :/
<Daviey> My hunch is udev.. :)
<jdstrand> mvo: hi! so, aiui if I have something like this in my sources.list
<jdstrand> deb http://debmirror/...
<jdstrand> deb http://security.ubuntu.com/...
<jdstrand> mvo: then apt will pull from the first one, unless there is something newer in the 2nd. is that accurate? are deb-src lines supposed to work the same?
<infinity> jdstrand: The only caveat to that is that apt will prefer signed repos first.
<mvo> jdstrand: thats accurate, yes. I need to double check for deb-src, to  be certain but I think that is the case as well. plus what infinity said
<infinity> (Even if they both contain the same packages with the same hashes, which I consider a bug, but whatever)
<jdstrand> well, my debmirror is an rsync, so that should be fine
<jdstrand> mvo: don't bother double-chcking the deb-src bit-- my debmirror seems out of date. I'm testing
<jdstrand> mvo: yep, deb-src works the same
<jdstrand> mvo, infinity: thanks
<mvo> jdstrand: aha, cool. thanks
<tgardner> is debian/files (which is created by dh_control) used for anything ?
<cjwatson> tgardner: yes, dpkg-genchanges
<cjwatson> it's absolutely essential
<tgardner> cjwatson, but for what? I can't see that it has any impact.
<cjwatson> it tells dpkg-genchanges which output files it needs to include in the .changes file
<cjwatson> please leave it alone :-)
<cjwatson> (binary .changes file that is)
<tgardner> cjwatson, it doesn't exist when I package the kernel.
<cjwatson> it's generated at run-time
<tjaalton> uh, so are we auto-sleeping desktops too?
<tgardner> cjwatson, well, I'm having periodic build failures when attempting to parallelize the kernel build due to occasional conflicts with competing dh_gencontrol statements.
<cjwatson> don't parallelise dh_gencontrol
<tgardner> cjwatson, I think I can work around it for developer builds. The archive build will continue to be single threaded.
<cjwatson> dh_gencontrol (well, actually dpkg-gencontrol, which it calls) can't be parallelised unless somebody submits patches to dpkg to make it have some kind of lock around writing the files list
<cjwatson> at least; I haven't looked at the rest of it
<cjwatson> I'm guessing most of the rest is OK since it'd be under debian/foo/DEBIAN/
<tgardner> cjwatson, yeah, I looked at the code.
<infinity> tgardner: Why would the archive builds be single-threaded?
<infinity> tgardner: We have multi-core buildds for a reason. :P
<tgardner> infinity, perhaps a better way to put it is that the makefiles are single threaded
<tgardner> CONCURRENCY_LEVEL=1
<infinity> tgardner: Well, yes.  But if you're working on parallelising them for developers, I'm curious why you'd not do that on the buildds.
<tgardner> infinity, I would except that I keep braking things.
<infinity> tgardner: The buildds pass you DEB_BUILD_OPTIONS=parallel=$(nr_cores) just for that reason. :)
<tgardner> break*
<tgardner> infinity, the race in dh_gencontrol to update debian/files is currently an issue when running multiple packaging targets in parallel.
<infinity> tgardner: I don't tend to parallelise binary-* rules, only build-* rules, but I know others are more daring.
<tgardner> infinity,  the packaging phase is one of the slowest parts of the kernel build. I can get significant speedups by doing them in parallel (on a honking big machine like tangerine)
<cjwatson> I expect you can parallelise lots of it, just not things like dpkg-gencontrol that write to shared resources
<infinity> Fair point.  And, as Colin says, if it's all in isolated subdirectories, it shouldbe fine except for gencontrol.
<tgardner> an therein lies the problem.
<cjwatson> (Though I'm surprised to learn that it isn't all blocked on I/O)
<tgardner> cjwatson, it likely is I/O bound on the puny buildds
<infinity> The easy fix to that is to pull gencontrol out of binary-$(image), and have binary-arch depend on binary-image-* and run gencontrol once for each stamp serially.
<infinity> Or something like that.
<infinity> Did I really start that sentence with "easy"?
<tgardner> infinity, I've got something like 12 kernel source packages to maintain. I'm thinking about taking a stab at patching dpkg-gencontrol
<cjwatson> (if you do, send the patch to Debian rather than Ubuntu please - this isn't something where we should have a delta)
<tgardner> oh, I agree
<infinity> Implement locking for debian/files?
<tgardner> infinity, something like that. there ought to be some kind of exclusion
<infinity> Well, file locking in Perl shouldn't be particularly hard.
<cjwatson> use Fcntl;
<tgardner> I'm not exactly a perl wizard, but I used to know it once upon a time
<infinity> I suppose that is the sane solution, given the number of people out there who just MAKEFLAGS := 16 willy-nilly without thinking about how it might affect dh
<cjwatson> (actually 'use Fcntl qw(:flock);' probably)
<infinity> There should be a -j in there somewhere.  Okay, it's nap time. :P
<infinity> Clearly.
<tgardner> infinity, nap time already? its 7:26 where you are, isn't tit ?
<infinity> tgardner: I failed to sleep.
<infinity> Not for lack of trying.
<tgardner> ah, bummer
<tseliot> cjwatson, pitti: can you reject my upload of fglrx-installer and fglrx-installer-updates, please?
<ubuntu-baltix> hello all
<infinity> tseliot: Done.
<tseliot> infinity: thanks a lot
<infinity> tseliot: (Best to ask those questions in #ubuntu-release, where people are idling for that specific purpose)
<tseliot> infinity: good point
<didrocks> barry: hey, small python question, from the last month (maybe a little bit more, I don't know), mvo and I started to experience a lot of bugs like bug #831652 with gettext, even with code that didn't change at all, any idea?
<ubottu> Launchpad bug 831652 in software-properties (Ubuntu Oneiric) "software-properties-gtk crashed with UnicodeEncodeError in ToggleSourceUse(): 'ascii' codec can't encode character u'\xe9' in position 72: ordinal not in range(128)" [Medium,Triaged] https://launchpad.net/bugs/831652
 * roadmr is interested in the answer to this ^^ 
<mvo> barry: or bug #859009, I'm pretty sure that worked for ages
<ubottu> Launchpad bug 859009 in update-manager (Ubuntu) "do-release-upgrade crashed with UnicodeEncodeError in __main__: 'ascii' codec can't encode character u'\xe1' in position 16: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/859009
<roadmr> we had to change our code to explicitly specify encodings, even though it worked fine before
<cjwatson> When I just fixed a bug like that in ubiquity it was because of a .encode vs. .decode mixup.
<barry> mvo, didrocks, cjwatson yeah, that would definitely do it
<cr3> roadmr: my favorite code relating to encoding is to expand escaped characters in a unicode string: mystring.encode('utf-8').decode('string-escape').decode('utf-8')... you need to encode and then decode the unicode string just to escape it, and this is actually the recommended way! :)
<roadmr> cr3: well at least it's just one line, but yes, it looks weird
<stgraber> tseliot: just saw the uploads, thanks!
<barry> well, of course ideally, *all* your strings are unicode as early as possible.  e.g. i put this in all my python (>= 2.6) code:
<tseliot> stgraber: thanks for bringing the bug to my attention
<cr3> barry: do you think I should extreme negative comment that line? :)
<barry> from __future__ import absolute_import, unicode_literals
<barry>  
<barry> no need to u'' your strings
<didrocks> oh nice trick :)
<barry> and with 2.6 you can b'' your specific byte strings
<barry> so it will make conversion to py3 *much* easier
<cr3> barry: I like how you slipped absolute_import in there, relative imports should be punishable by spanking :)
<barry> cr3: when i read that subject line i thought "extremely negative" mean stuff like "i really suck for having to write this line" and that kind of thing
<didrocks> well, a little bit late for this cycle, but definitively something to add for next cycle if projects aren't ported to 3
<barry> cr3: *exactly* :)
<barry> cr3: also this:
<barry> __metaclass__ = type
<barry>  
<cr3> barry: same here
<barry> now all your classes are new-style without having to inherit from object
<pitti> ev: just reviewing lupin
<barry> didrocks: yep, that's a big plan of mine so being very deliberate about strings vs. bytes is a huge part of that
<cr3> barry: most of my classes use __metaclass__ = type, but I only import absolute_import when there's a relative name conflict
<pitti> -       cp "/root/usr/share/language-support/incomplete-language-support-*.note" \
<pitti> +       cp -af "/root/usr/share/language-support/incomplete-language-support-*.note" \
<barry> cr3: the metaclass trick can go at module global level so it doesn't need to be put in the classes
<pitti> ev: how does that help?
<pitti> ev: I thought the issue was that the glob isn't resolved, for that you need to drop the quotes?
<cr3> barry: err, I meant module... the launchpad way
<pitti> ev: or am I misunderstanding this?
<barry> cr3: right!
<didrocks> barry: yeah, that's the only thing (unicode strings by default) that I feel really missing from 3 TBH, I'm not enough in 3 to see what else I miss right now, but I'm probably blind and uninformed :)
<ev> pitti: the quotes are dropped
<ev> oh interesting
<pitti> ev: not in the debdiff
<pitti> it just adds -af
<ev> indeed, that's my mistake entirely
<ev> apols, please reject
<pitti> ev: no problem, thakns
<ev> it was a bad copy of his patch
<ev> manual copy*
<ev> big thanks for that catch!
<barry> didrocks: strings *are* unicode by default, by which i mean, unadorned quotes.  bytes are the oddball in py3 and need b'' prefixes for literals.  the trick is in converting from 2to3 if things aren't well defined
<cr3> didrocks: I thought 3 was unicode by default. if not, I share the same feeling as you
<pitti> ev: well, it's good to know that at least occasionally all this queue review actually helps :)
<ev> most certainly :)
<barry> actually, you can drop the "by default" :).  strings just *are* unicodes in 3
<didrocks> barry: cr3: sorry, bad wording, the only thing I miss in my current python 2 programs compared to switch to python 3 is the unicode by default. Is that more clear? :)
<cr3> barry: unicode as in 4 bytes per character, right? not utf-8 encoded internally
<barry> of course, if you read a stream of stuff from a file, you need to be explicit about whether your reading bytes, or some text with a particular encoding.  that doesn't change, but i'm mostly talking about literals
<pitti> ev: do we actually want the -f here? it might make errors less obvious
<ev> indeed not
<barry> didrocks: yep!  if you can target >= 2.6, definitely use the future import and that will help a lot
<ev> I'll just drop the quotes in the new version
<didrocks> barry: thanks for the info
<barry> np!
<cr3> didrocks: yes, more clear :) I share the pain but I think it's worth it, thinking in unicode eventually makes more sense
<barry> cr3: http://docs.python.org/dev/reference/lexical_analysis.html#literals
<mvo> barry: sorry if I missed that, but did you mention what actually changed that things are currently breaking that used to work? or is it somehting outside of python that is different now than it was before?
<barry> mvo: i can't think of something that changed recently in python that would have started causing this.  i have another high priority bug i'm looking at atm, but can probably help with this if i get lucky with that one
<mvo> barry: thanks, the would be much appreciated!
<barry> mvo: np!
<maco> ev: before i spend forever digging, why would ubi-partman.py read out both the templatey-generated-text and the filler text?
<ev> maco: entirely not sure, sorry
<ev> assuming that set_label/text and all that stuff gets fed back up to ATK
<pitti> ev: lupin accepted; you didn't use -v to include previous changelog, so you need to close the bug manually
<pitti> ev: thanks!
<ev> pitti: sure thing, cheers
<Daviey> slangasek: are you tracking boot speeds?
<cnd> pitti, I'm online now
<Sweetshark> infinity: Did I get that right, you would jump in for pitti for an upload if he is already off for the weekend?
<slangasek> Daviey: QA is tracking them; we don't have a very streamlined reporting process for boot speed regressions yet however, so we generally fix things when someone notices
<slangasek> Daviey: and in the case of server, everything suggests we need to slow boot down to let udev catch up ;P  why do you ask?
<Daviey> slangasek: no, desktop is taking 4 mins to boot for me.  Seemed to be a concern :)
<slangasek> Daviey: bootchart please
<Daviey> Server boot speed, i don't much care for :)
<slangasek> apt-get install bootchart, double-reboot, post /var/log/bootchart/$newest.png
<Daviey> slangasek: let me reboot, to get a fresh one.. just need to finsh something.
<Daviey> (i've done the first reboot)
<Daviey> slangasek: http://bootie.daviey.com/~dave/voodoo-oneiric-20110930-3.png
<nemo> So, I was curious...  Trying to do a build against box2d.  Path in app is Box2D/Box2D.h since that's where Box2D puts its main include
<nemo> ubuntu though moves it one dir down
<nemo> any particular reason for that?
<nemo> like some ubuntu policy?
<cjwatson> nemo: There are no Ubuntu-specific modifications to that package; we sync it unmodified from Debian, where it's had only one upload
<cjwatson> nemo: box2d upstream doesn't appear to provide a 'make install' target, so there's precious little guidance as to how packages are meant to lay it out
<cjwatson> nemo: so I don't think it's the result of any particular policy, just an arbitrary choice
<nemo> ah
<nemo> cjwatson: was just wondering.  make install for the box2d project puts it inside the box2d dir.  sooo when we run FindBox2d.cmake, we specify Box2D/Box2D.h in the cmake, and reference it as such in the #include - but that fails on the ubuntu version.
<pitti> Sweetshark: checking in now
<nemo> I guess the point is moot since I couldn't find any ubuntu version of 2.2.x anyway
<SpamapS> whoa.. whats up with LP's builders?
<SpamapS> 12 hours?
<slangasek> Daviey: what the hell, man
<slangasek> Daviey: loading your bootchart in my browser *consistently* makes my desktop crash!
<cjwatson> nemo: ah, well, perhaps 'make install' was added after Debian packaged it
<cjwatson> nemo: perhaps you'll need to detect where the include file is at configure time
<cjwatson> slangasek: and he isn't even on the security team
<nemo> cjwatson: yeah, I'll probably try that eventually, but since I can't even find a 2.2.1 ppa... :)
<slangasek> cjwatson: no kidding
<slangasek> Daviey: DUDE
<slangasek> Daviey: it makes X crash even when I *don't* use my browser to load it
<slangasek> Daviey: I think I see why your boot is so slow, bootchart is having to calculate an attack vector
<slangasek> very CPU-intensive
<stgraber> slangasek: bug confirmed ;)
<stgraber> though I managed to see the bootchart for a few seconds before X crashed
<slangasek> stgraber: it never loads all the way for me
<slangasek> or it does, but my X server has better crash-speed :P
<slangasek> anyway, it's a sigbus in the intel driver, according to logs
<slangasek> RAOF_: how do I report an X server crash these days, given that apport seems to not be triggering (again/still)?
<Daviey> slangasek: Ah, the png loaded trojan worked.
<slangasek> Daviey: does it work for you? ;)
<Daviey> yeah :/
 * Daviey tries firefox
<stgraber> http://paste.ubuntu.com/699998/
<Daviey> wow, firefox is slow rendering it
<slangasek> Daviey: what video chipset?
<Daviey> nvidia non-free :(
<slangasek> right
<slangasek> this is an intel driver bug
<slangasek> Daviey hates our freedom, all is explained
<Daviey> I try to make my sysrtem as little free as possible.
<Daviey> It makes me feel warm inside.  If i knew how to use OSX, i would so switch.
<nemo> Daviey: Windows 8?
<slangasek> fortunately the new compiz window switching model will help you get up to speed on that ;)
<Daviey> nemo: i'm scared of change.
<nemo> Daviey: well you're kinda screwed w/ Unity/Gnome shell then :)
<Daviey> nemo: true :)
<nemo> Speaking of horror of non-free, I think it is pretty darn cool that you guys added World of Goo.  I haven't gotten around to buying it yet, but I keep meaning to.   I'm a little concerned that I wouldn't be able to use the .deb on both my machines
<Daviey> Image loads ok on ATI/AMD
<slangasek> Daviey: yes, the crash is in the intel driver... you can stop taunting :)
<nemo> Daviey: Also, you might enjoy this dude, who made our lives on the Hedgewars dev team unpleasant for a little while w/ his FOSS purity.  http://www.hedgewars.org/node/2480
<slangasek> nemo: oh, is World of Goo in partner now?  Fun
<slangasek> er, s/partner/app store/
<nemo> yeps! nice to see more gaming under linux
<Daviey> It took me 6 months of pondering to stump up ~$15 for minecraft.
<slangasek> I keep missing out on the Humble Bundles because I take too long pondering them
<slangasek> so instead I wound up shelling out the money for World of Goo on its own, ohwell
<slangasek> (for a good cause - multiarch testing ;)
<slangasek> ok, let's see if I can reproduce this intel crasher on my spare laptop :P
<nemo> slangasek: oh. so. just curious. if I buy it from the App Store - is it tied to my UbuntuOne, to the computer, or is non-DRM, so I could put it on both home machines?
<slangasek> nemo: you are certainly asking the wrong person :)
<nemo> oh. thought you bought it
<stgraber> nemo: it's linked to your ubuntu SSO account
<slangasek> nemo: I bought it through the upstream website, before it was in the repo
<stgraber> nemo: you can login on another machine with the same account in software center and install it there
<stgraber> nemo: using the "Reinstall Previous Purchases" option from the menu
<nemo> stgraber: nifty. I'll have to pick a better ubuntuone password and do that
<slangasek> stgraber: but if you grab the raw .deb, that's still DRM-free, isn't it?
<stgraber> slangasek: yep
<slangasek> i.e., you can shuffle it around from system to system directly if you choose
 * slangasek nods
<nemo> slangasek: same for iphone I think. if you jailbreak the iphone you can just copy apps off
<stgraber> you can also copy/paste the private PPA from /etc/apt/sources.list.d
<nemo> slangasek: the signing just controls standard install
<stgraber> and then just apt-get install it
<nemo> they don't hash it on load or anything
<slangasek> nemo: well, this isn't jailbreaking, this is endorsed by the authors :)
<nemo> slangasek: yeah, but I was talking more about loose store controls :)
<slangasek> AIUI
<nemo> slangasek: usually such things are just to keep out the general riff-raff
<nemo> slangasek: is why Apple gave up on DRM music.  Just annoyed people and drove more to piracy.  99% of purchasers are honest and fine w/ reasonable prices for convenience
 * slangasek nods
 * slangasek observes that the Humble Bundles continue to make more money from Linux users than anyone else
<Keybuk> nemo: I don't think Apple "gave up"; I think Apple didn't like it either, but capitulated and waited until they had the music industry by the throat before taking action on it
<Keybuk> a bit like Ubuntu's historical strategy with binary drivers, really
<nemo> Keybuk: well, they aren't exactly into open interfaces anywhere else :-/
<Keybuk> likewise, there wasn't a giant library of media content available from sources that did not demand DRM :)
<mdeslaur> Apple started offering drm-free music because Amazon started selling drm-free music
<Keybuk> mdeslaur: I don't think Apple genuinely care what Amazon do
<Keybuk> Apple historically don't chase a minority userbase, like those who know what DRM is
<mdeslaur> the labels wanted variable pricing from itunes, apple didn't want to give in, they started selling drm-free music to everyone else, including amazon, apple gave in to variable priced songs in exchange for drm-free music
<slangasek> when will Amazon start selling drm-free books?
<mdeslaur> slangasek: amazon sells drm-free books, the publisher decides when he uploads the file
<slangasek> mdeslaur: that is not the answer to the question I was actually asking :)
<mdeslaur> slangasek: all the kindle oreilly books are drm-free...what are you asking? when will amazon ask publishers to stop checking the drm box?
<Daviey>  /j #ubuntu-discuss-apple-strategy
<Daviey> Keybuk: I thought Apple DID chase a minority userbase?
<slangasek> mdeslaur: when will Amazon stop conspiring with publishers to jerk us around wrt their ebooks being a worse value proposition than the paper ones
<mdeslaur> heh, rathole..sorry
<slangasek> mdeslaur: also, how do we fix the publishing industry so that places like Powell's Books can continue to exist as physical meeting / browsing spaces without the inconvenient paper inventory :)
<Daviey> mdeslaur: and when will amazon start selling ponies?
<ScottK> You mean they don't?
<mdeslaur> slangasek: alas, Powell's is doomed to go the way of the record store. We've got starbucks (*$) now for that :)
<slangasek> mdeslaur: ok, eew
<mdeslaur> heeh
<slangasek> starbucks does not fulfill the same function
<Keybuk> slangasek: Books Inc in SF have an interesting gimmick, they have QR codes next to every book
<Keybuk> scanning the QR takes you to a "buy the book" page
<slangasek> Keybuk: that doesn't really go far enough to address the inventory problem
<slangasek> you still have to stock the physical book to put a QR code next to it :)
<Keybuk> only one
<Keybuk> after all, a big part of book stores is that people come in, sit down, and read a chapter
<Keybuk> then decide whether or not to buy
<Daviey> i'd feel damn rude doing that.
<slangasek> Daviey: they sell you expensive coffee drinks to assuage your conscience
<Daviey> ah, good o
<Keybuk> and sell you expensive books if you decide you like them :p
<slangasek> Daviey: what is 'iwatch'?
<nemo> Keybuk: was actually pretty amusing. last time we were in a bookstore, my SO whipped out Google Goggles to scan the barcode of the book she was interested in to add it to her amazon queue.
<slangasek> Daviey: you have iwatch, cobblerd, smbd, and mythbackend services starting on boot, all taking up a lot of the boot time; this is not the "fast boot" target case
<nemo> Keybuk: and here she was bemoaning the death of the bookstore she used to work at (Borders)
<slangasek> Daviey: you also have either some unusual remote mounts (iscsi?) that cause the filesystem event to be delayed, or you have a kernel bug causing your video to be slow to init, *or* you have contention keeping dbus from starting up early, because lightdm doesn't start until 158 seconds into the boot
<Daviey> slangasek: they didn't look to add *that* much time
<Daviey> slangasek: I'll happily remove those things, i'm willing to bet it's still > 3.5 mins.
<slangasek> Daviey: what does /etc/network/interfaces have in it?
<slangasek> and do you have any remote filesystems configured?
<Daviey> slangasek: not on that boot, i didn't
<slangasek> iwatch is occupying your system for 30s... that's not insignificant
<Daviey> i do have a funky bridge setup, http://pb.daviey.com/kjHS/
<Daviey> crikey
<slangasek> the bridge network does seem to be taking a long time to init
<slangasek> udev rule for the interface triggers at 28s, takes 2s just to run ifconfig (!), then there's a 6s sleep... dhcp comes up fairly quickly, just 4s after that.  But somehow the ifup command doesn't return forever...
<linuxnewb_> how can i find the ip address of a p2p (another person's notebook connected to my notebook) in linux' terminal?
<stgraber> I've seen ifup take up to 30s per bridge on some machines (when it does, it usually prints the reason)
<slangasek> Daviey: which probably means you're hitting the failsafe network timeout at boot, because the ifup hasn't succeeded
<cjwatson> I think the problem is that I LD_PRELOADed gettimeofday() to sleep 200ms the last time I was near Daviey's laptop
 * cjwatson watches Daviey go off to hunt for that
<stgraber> ;)
<slangasek> stgraber: yes, this is something else; the bridge initialization finishes, dhcp is up, and the ifup call hangs around for another 200s+
<slangasek> and there's no indication on the chart of what child process it might be waiting for
<slangasek> Daviey: is 'ifup' still running? :P
<Daviey> slangasek: no
<Daviey> cjwatson: hah
<slangasek> Daviey: ok.  can you paste /run/network/ifstate, and ls -l /etc/network/if-up.d/ ?
<siretart> infinity: I've just released Libav 0.7.2, which is pretty much what is in oneiric right now (~6 upstream patches similar to those you've already seen). Do you think it's worth uploading to oneric-proposed? I guess it makes things a bit easier for the sec-team, but YMMV of course
<Daviey> hah, /run/network/ifstate http://pb.daviey.com/gada/
<Daviey> *why* i pastebinted 1 line, i don't know.
<Daviey>  ls -l /etc/network/if-up.d/ - http://pb.daviey.com/tbKF/
<slangasek> Daviey: right; somehow the interface was never brought up, which I think means dhclient never returned success to ifup
<Daviey> slangasek: Okay, if you think it's a configuration issue, i won't waste your time anymore.  I'll dig through it at some point, and see if i can work it out.
<slangasek> Daviey: I *don't* think it's a configuration issue, dhcp is clearly succeeding (because it runs dhclient-script), but ifup doesn't return... that's a bug :)
<Daviey> oh goody.
<slangasek> Daviey: you have isc-dhcp-client installed, right?
<Daviey> slangasek: Installed: 4.1.1-P1-17ubuntu10
<slangasek> Daviey: ok, just checkin'
<SpamapS> Hmm my latest dist-upgrade is stuck running this
<SpamapS> root     26177  0.0  0.0   4264   580 pts/6    D+   12:19   0:00 /bin/sh -e /usr/lib/os-probes/mounted/20macosx /dev/sda2 /mac hfsplus
<slangasek> SpamapS: subprocesses? dmesg?
<SpamapS> slangasek: subprocesses were tr and paste..
<SpamapS> slangasek: killed them both
<slangasek> ... paste?
<soren> Darn it. man dpkg-genchanges(1) lies. :(
<SpamapS> hmm.. not sure what the D+ is for ..
<slangasek> SpamapS: I can't see how that script should ever hang, barring disk problems
<slangasek> SpamapS: does accessing the /mac mountpoint hang?
<cjwatson> or bug in hfsplus.ko perhaps
<cjwatson> I'm sure it's not the best-tested fs implementation
<slangasek> ah, I mentally included that in "disk problems" :)
<SpamapS> actually yes its hanging.. doh
<soren> "There's no distinction between -b, -B and -A, the produced .changes file will include whatever files were created by the binary-* target(s) of the package being built." <--- Except it won't include Arch: all packages if run with -B. :(
<slangasek> soren: you have an Arch: all package being built when running with -B?
<SpamapS> GPF in hfsplus
<soren> slangasek: Yeah. I was having fun :)
<slangasek> soren: heh
<slangasek> soren: well, don't expect launchpad to accomodate fun of that nature either... :)
<soren> slangasek: That's exactly what I was trying to find out.
<Daviey> SpamapS: Does it have a journal?  hfsPLUS does AIUI, and can only be mounted read-only, that might be it.
<SpamapS> http://paste.ubuntu.com/700076/
<SpamapS> yeah I only want it readonly
<SpamapS> just so I can get at any old docs I have on the os x drive
<soren> slangasek: I really just wanted to get some stuff built on amd64 to bypass the insane build queue on i386, but then I realised I might be able to use it to fix  e.g. 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
<Daviey> SpamapS: It would be interesting to see if you see the same behaviour with the journal dropped.
<SpamapS> this could also be corruption/hardware related
<SpamapS> can't say I can remember the last GPF I saw in anything
<slangasek> soren: it *might* happen to work right now, but a) I doubt it because launchpad has *very* strict sanity-checking at accept time, and b) you certainly aren't going to get any guarantees that it'll continue working
<soren> slangasek: AFAIR, dpkg-genchanges is run by sbuild so I'm stuck anyway.
<slangasek> yeah, could be
<soren> Err..
<soren> Well by dpkg-buildpackage.
<soren> Something I don't control at least.
<soren> Every 6 months or so I have a new "great" idea of how to fix that one. It never works out :)
<Daviey> soren: build it arch any, build-dep on qemu-system-sparc, produce the binary within that :)
<cjwatson> SpamapS: actually, what's weird is that that should be using grub-mount
<Daviey> s/any/all
<SpamapS> At this point my fonts are all doinked and nothing works right, time to reboot..
<soren> Daviey: I think I actually tried that.
<soren> Daviey: I think I got stuck because I needed access to ports.
<cjwatson> SpamapS: ... oh, I guess you already had that fs mounted so os-prober used the existing mount
<soren> Daviey: ...which I couldn't depend on either.
<SpamapS> cjwatson: right
<Daviey> soren: hah
 * SpamapS reboots.. bbiab
<soren> Daviey: The best guess right now is some sort of ia32-libs-ish thing.
<soren> Daviey: So build it on sparc, and have another package pull that deb.
<cjwatson> maybe we should give grub-mount priority over even existing mounts
<soren> Daviey: and shove its contents into an arch: all package.
<Daviey> soren: Surely that has the same issue, of the sparc built package being in ports?
<soren> Daviey: But I always lose my will to live before I finish that.
<soren> Daviey: ia32-libs is sticted together at source package build time.
<soren> stitched.
<Daviey> ah
<soren> Daviey: Not at binary package build time.
<soren> Daviey: That's why the source package is half a gig :)
<Daviey> soren: I understood Debian were considering blocking bin uploads, will be interesting to see how they resolve that.
<soren> Daviey: Good question.
<infinity> siretart: Not living in patch hell might be pleasant.  You have a diff?
<cjwatson> Daviey: I mentioned this example to the Debian ftpmasters at DebConf; they're aware of it and will ensure it doesn't get broken by throwaway-binary uploads
<infinity> Sweetshark: ACK on the being around for an upload thing.
<cjwatson> I think by having a mechanism for certain arch-all packages to be forced onto certain architectures
<Sweetshark> infinity: https://launchpad.net/ubuntu/+source/libreoffice/1:3.4.3-3ubuntu2 too late ;)
<Sweetshark> infinity: but still: thank you very much!
<Daviey> cjwatson: a Please-build-this-any-on-this-arch: commodore64 , _changes option?
<infinity> Sweetshark: So I saw. :)
<cjwatson> Daviey: something like that
<cjwatson> I'm not sure if it'd be Packages-arch-specific or .changes or manual-db-hacking (given that there are like three of them) or what
<Daviey> Interesting
<infinity> cjwatson: P-a-s seems like a reasonable way to go.
<siretart> infinity: you mean sth like http://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/0.7 or rather http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog?
<SpamapS> ahh lovely console
 * SpamapS waits for dpkg --configure -a to finish :P
<SpamapS> wow that was pretty painful..
<infinity> siretart: Or something like a libav_0.7.2-0ubuntu1 package? :)
<SpamapS> I feel like we should have a check at boot time, if your system has unconfigured packages, it should offer to run dpkg --configure -a for you.
<ScottK> Because boot speed hasn't regressed enough already?
<Daviey> cjwatson: By Jove, cobbler-enlist works from the ISO.
<cjwatson> Awesome.
<cjwatson> A last-minute update that went right!
<infinity> Don't jinx it.
<Daviey> exit non-zero also allows you to try again \o/
<Daviey> infinity: I'll juju it
 * cjwatson touches his desk for luck
<siretart> infinity: well, it would be a pretty minimal libav_0.7.2-1ubuntu1 (compared to libav_0.7.2-1)
<infinity> jamespage: What creates the nova group?
<SpamapS> ScottK: one more grain of sand in the hourglass. :)
<infinity> jamespage: (hint: "adduser --ingroup foo" doesn't create groups)
<slangasek> SpamapS: and do all interaction via plymouth? :)
<infinity> siretart: I was sort of driving at "I'd like no packaging changes, just the upstream version bump to drop the 63 cherrypicks".
<SpamapS> We could actually make it pretty fast.. have dpkg put an upstart job in /etc/init that does the recovery, and remove it when its done.
<infinity> siretart: Hence -0ubuntu1 seeming more appropriate than -1ubuntu1 (since it's not based on -1, which has multiarch)
<infinity> siretart: But whatever. :)
<SpamapS> slangasek: well now you're talking crazy. :)
<slangasek> yes, yes I am
<ScottK> slangasek: Didn't you hear.  That's just for a pretty boot and everyone should just remove it anyway.
<slangasek> ScottK: that's why I replaced it with a job that just runs fsck -pyf /dev/*
<SpamapS> slangasek: thats masterclass right there
<infinity> jamespage: Ahh, nevermind, you already had the group before, just fixing up some old users, I guess.
<siretart> infinity: right
 * infinity wants more context in his diffs.
<slangasek> reeses context diffs
<slangasek> is it friday?  I think it's friday
<infinity> I dunno, does that mean I get more diffs in my context?
<slangasek> yes
<cjwatson> slangasek: s/fsck -pyf/shred/
<slangasek> :)
<infinity> siretart: (I'd even entertain the idea of such an upload say... Nowish)
<infinity> siretart: From the security headache standpoint, that seems much nicer than 0.7.1+63cherrypicks. ;)
<bdmurray> is there someone familiar with perl who can look at 678060?  this person has reported dozens of perl crashes
<slangasek> bdmurray: the backtrace is pretty nondescript. I think it probably needs to be debugged in situ
<slangasek> it's also probably not a perl bug at all, but would take a lot of work to confirm this
<infinity> bdmurray: A reproduction script would be nice.
<slangasek> maco: would you be interested in helping with bug #837042?  I'm concerned that this Kubuntu-specific ubiquity bug is going to wind up remaining unfixed when there are still so many general ubiquity bugs still being worked on
<ubottu> Launchpad bug 837042 in ubiquity (Ubuntu Oneiric) "[kubuntu] wrong encoding for input in oem-config" [High,Confirmed] https://launchpad.net/bugs/837042
<slangasek> infinity: the submitter has filed bugs reporting large numbers of random perl scripts crashing
<infinity> slangasek: So, he's reporting that he has bad RAM?
<cjwatson> slangasek,maco: hah, I'd just started looking at that :)
<slangasek> cjwatson: oh, carry on ;)
<slangasek> infinity: maybe?
<cjwatson> just setting up a test environment
<maco> slangasek, cjwatson: i've got a bit of a11y almost-there-ness to dig into on ubiquity
<slangasek> infinity: or maybe a bad CPU implementation...
<maco> it reads pretty much all the stuff it needs to!  ....and then some
<maco> "Replace $OS with Ubuntu. Replace Windows with Ubuntu. Checkbox not checked"  the second sentence needs to go away :-/
<slangasek> heh
<bdmurray> not the first one?
<slangasek> infinity: what's particularly odd is how all of the crashes he reports are segfaults in memory-management-related functions... across multiple programs
<infinity> I prefer losing both sentences.  Translation is so much easier when the UI is just checkboxes and radio buttons with no explanation.
<slangasek> well, no, I guess the perl crashers are more varied than that
<infinity> slangasek: Does he have any perl crashes that couldn't be readily explained by a bit-flip in bad RAM?
<infinity> slangasek: Cause I'm having a hard time believing Perl hate him, and only him, when most of us rely on it working 24/7.
<cjwatson> I'd definitely rather maco were looking at a11y bugs, since I've already tried to investigate those and got absolutely nowhere
<slangasek> bdmurray: I would suggest picking one of the bugs in question, setting it incomplete and asking him for hardware details, with the comment that things are crashing for him that don't crash for anybody else and it looks like a broken system; and if no explanation is forthcoming, mass-close any bugs he's filed that haven't been confirmed by others
<slangasek> infinity: the one bdmurray pointed to has a crash at 0x04000008... that ain't no bit flip
<bdmurray> slangasek: I was thinking of incompleting all of them in case I forget or he never replies.
<maco> bdmurray:  it doesnt say "dollar sign oh ess" :P but it could end up saying "Replace Mac OS with Ubuntu. Replace Windows with Ubuntu." when you havent got windows
<slangasek> bdmurray: should we be collecting /proc/cpuinfo in all reports? it might have been helpful here
<slangasek> bdmurray: incomplete> sure, sounds good
<infinity> slangasek: Hrm?  Any attempts to read to/from the wrong regions can easily be because the pointer got garbled when it mistakenly took a vacation in RAM.
<infinity> The solution to this is clearly more registers.
<infinity> A lot more.
<cjwatson> perl mm crashes can often be broken extensions
<slangasek> infinity: what single-bit error accounts for trying to read from an address of 0x04000008?
<slangasek> I think cjwatson's explanation the more likely
<cjwatson> even if they don't show up in a backtrace, given the spooky-action-at-a-distance nature of a lot of memory corruption
 * slangasek nods
<cjwatson> I must admit that I find it unproductive to investigate perl crashes - it takes so long and it's so rare that it's actually a real problem
<slangasek> exactly
<cjwatson> if we want to do something about them we should sic a real perl core hacker on them
<cjwatson> (who will tell us we should be on 5.14)
<tjaalton> forgive my question, but has authconfig (from fedora) ever been evaluated for handling the configuration of network logins in the installer. I know it doesn't fit as-is, the pam config backend should just be disabled, the config backend should use debconf etc, but otherwise..
<cjwatson> no, I don't believe so
<tjaalton> uh, too long a line
<slangasek> I think "point out nobody else's perl is broken, and incomplete the bugs" would be a more appropriate course of action :)
<cjwatson> it's not clear to me that the installer is a good place to configure network logins at all
<slangasek> tjaalton: sure, I evaluated authconfig; that's why I wrote pam-auth-update :)
<tjaalton> slangasek: hehe, but it only does a part of it
<slangasek> yes
<slangasek> someone else gets to write the other parts
<slangasek> :)
<tjaalton> yes
<slangasek> but, in general authconfig fails Debian Policy, which is why I started from the other end
<tjaalton> cjwatson: how so? every time ubuntu is reviewed here they complain why you can't configure it from the installer, but go through various loops instead
<cjwatson> my view is that the installer should get the OS on there and get out of the way
<cjwatson> I must admit it's news to me that installer reviews are complaining about the lack of network login; that's not one I'd heard before (though perhaps I'm amnesiac)
<cjwatson> bit-flip> a machine I use once developed a bit-flip in /bin/cat; it was amazing how much kept working
<cjwatson> network logins are about on the edge of what I can see being reasonable in the installer; I could probably argue it either way
<slangasek> bug #856290 is a fun bitflip bug
<ubottu> Launchpad bug 856290 in freetype (Ubuntu) "package libfreetype6-dev 2.4.4-1ubuntu2.1 failed to install/upgrade: unable to create `/usr/share/doc/libfreetype6/fesign/library-model.png.dpkg-new' (while processing `./usr/share/doc/libfreetype6/design/library-model.png'): No such file or directory" [Undecided,Invalid] https://launchpad.net/bugs/856290
<cjwatson> but, like slangasek, I find it unlikely that authconfig would be a good place to start
<cjwatson> except for requirements gathering maybe
<infinity> cjwatson: Given that our installer creates a user, network logins sort of seem to fit with that.
<slangasek> cjwatson: right; with pam-auth-update I partly aimed to reduce this to a package selection question
<tjaalton> cjwatson: usually people who need them use preseeding etc, but it would help demoing a new release
<cjwatson> infinity: that would be the other side of the argument, yes
<tjaalton> ok, so what I had in mind would be a way to configure sssd the way fedora does
<tjaalton> it has a python api, which authconfig supports
<cjwatson> I would expect you'd want a couple more steps in user-setup
<infinity> cjwatson: So, stop creating user 1000, and we're good. ;)
<tjaalton> of course it doesn't have to be authconfig to poke it..
<Daviey> I'm not sure those that care about network logins are the same people that care to use ubiquity.
<cjwatson> a python api is not very useful here
<cjwatson> Daviey: d-i
<tjaalton> still
<slangasek> tjaalton: but if what you want is to configure sssd, just... make sssd configurable
<tjaalton> slangasek: well, got a point there
<slangasek> authconfig doesn't help with that, you just need to debconfiscate it
<stgraber> tjaalton: btw, I plan to have a ubiquity plugin in Edubuntu 12.04 doing just that ;)
<tjaalton> right
<tjaalton> stgraber: oh?
<Daviey> This does sound like a reasonable target for Orchestra foo.
<SpamapS> agreed
<stgraber> tjaalton: with "easy" integration for AD, openldap and edirectory (the most common in education)
<cjwatson> user-setup goes before package selection, so you could have it have network login options in expert mode
<cjwatson> (priority=medium) which would make it preseedable and accessible by kickstart too
<infinity> slangasek: Hah.  "fesign".  I like it.
<slangasek> personally, I'm not thrilled with sssd's model of "route all pam and nss calls here and add another layer", but ah well
<infinity> slangasek: I wish all "dying storage" bugs were that obvious.
<slangasek> infinity: :)
<stgraber> tjaalton: so they can just enter some AD credentials and have it working next time they reboot (won't deal with tricky things like network shares though and will need them to have the POSIX extensions in AD as I don't want to use winbind)
<tjaalton> slangasek: the point is having one connection to the servers, and not all clients doing their own stuff
<tjaalton> slangasek: also the same what osx does, i'm told
<stgraber> anyway, got to run :)
<tjaalton> but you probably knew that
<slangasek> tjaalton: there were other implementations of this already... sssd wants to be one connection to *all* servers :)
<tjaalton> slangasek: oh you mean likewise etc?
<slangasek> there's an ldap-only proxy thing
<tjaalton> stgraber: yeah winbind is baad
<Daviey> likewise-open has with tradition been pretty well supported by us and upstream.
<tjaalton> it has it's limitations though
<slangasek> and credentials-caching stuff for kerberos
<Daviey> tjaalton: are those documented?
<slangasek> but if people are happy with sssd, so be it :)
<tjaalton> Daviey: yes, supported only in the enterprise version
<tjaalton> slangasek: well, pam_krb5/pam_ccreds et al are not that robust
<tjaalton> sorry
<tjaalton> pam_krb5 is
<tjaalton> but if you need offline creds, pam_ccreds never worked for me
<tjaalton> and the same for nss data
<tjaalton> ..which basically needed you to dump the whole directory locally
<SpamapS> ccreds worked for me "back in the day" ...
<SpamapS> been a long long time since I mucked with it..
<tjaalton> it's the directory side that's harder to get working offline
<tjaalton> reliably anyway
<SpamapS> heh.. thats kind of a weird notion anyway
<SpamapS> letting your whole directory flow out of your organization onto laptops seems a bit daft
<SpamapS> A small subset of it to be cached by the apps that use it.. for email/names/etc. works fine.
<tjaalton> yeah you don't need whole of it, but that's what the silly modules did. maybe the ldap-proxy would work better
<infinity> SpamapS: You don't need to export full directories to systems to make them work.
<tjaalton> nss-updatedb, that's the name
<infinity> SpamapS: ud-ldap (I know, not a solution anyone outside of Debian/Freedesktop/Canonical likes) is smart about making sure hosts only get the users and groups they need, etc.
<infinity> Ugh.  I really hate how /+filebug from an apport crash report still requires me to type descriptions.  "It broke, apport told me so."  99% of the time, that's about all any user will know.
<sbeattie> which is what oh so many of the bug reports filed that have for a description.
<sbeattie> s/that/that way/
<infinity> sbeattie: Yeah.  It also prompts me half the time to just close the window in annoyance, though.  I can only imagine that users, when faced with "you must enter a description" don't do well.
<SpamapS> is it just me or is there something screwy with terminator making the fonts blurry?
<SpamapS> seems to be only on my DVI connection. Hrm.
<SpamapS> ah
<SpamapS> unplug, replug.. instant happy
<SpamapS> weird
<slangasek> your cable must have been in analog mode
<SpamapS> anything used in postinst that is not part of the base system needs to be Pre-Depends right?
<slangasek> noooooooooo
<SpamapS> ok good
<slangasek> PRE depends for PRE inst
<SpamapS> right right ok
<slangasek> :-)
<slangasek> postinst == depends
<yofel> hey, does someone know how to tell the archive builders not to run optipng on the icon files of a package?
<yofel> it breaks the kile symbol table (kde latex editor)
<yofel> looking at pkgbinarymangler, is adding 'export NO_PNG_PKG_MANGLE=1' in debian/rules all I need to do?
<slangasek> yofel: yes
<yofel> ok, thanks
#ubuntu-devel 2011-10-01
<cjwatson> slangasek: ok, fixed 837042 now, taking an order of magnitude longer than I expected :-/
<infinity> zul: Regarding that glance upload.  If there's a glance group (and there is), and you're chowning everything glance:glance (you are), why 0700 for the permissions instead of, say, 0750, so people in the glance group can read logs, or 0770, if you want the group to have admin privs?
<slangasek> cjwatson: woot
<SpamapS> anybody know the exact place to report bugs in packages.ubuntu.com ?
<slangasek> cjwatson: is there any commandline tool for switching a VT into KD_TEXT mode? (bug #854967)
<ubottu> Launchpad bug 854967 in nvidia-graphics-drivers-updates (Ubuntu) "boot to rescue mode in Oneiric" [High,Triaged] https://launchpad.net/bugs/854967
<Daviey> slangasek: chvt doesn't cut it?
<slangasek> Daviey: chvt never calls the right ioctl, no
<slangasek> apparently there is a 'totextmode' command available in the kbd upstream source, but it's not built by default...
<Daviey> :(
<slangasek> it's also not very good, it requires an argument and then ignores it :)
<cjwatson> slangasek: I don't know of one
<koud> hello, has there been some work integrating ibus-xkb with unity and ubuntu?
<koud> http://desktopi18n.wordpress.com/2010/10/06/ibus-xkb/
<ScottK> SpamapS: Talk to Rhonda
<theuser51_> Anyone know a good book to learn pygtk or glade? Couldn't find any on Amazon
<marsfligth> How to resume from 'hibernation' or 'suspend' status pressing the keyboard instead to press the computer power button?
 * penguin42 worries if bug 862813 would trigger during an installation
<ubottu> Launchpad bug 862813 in gnome-power-manager (Ubuntu) "Power Managment settings are being ignored" [High,Confirmed] https://launchpad.net/bugs/862813
#ubuntu-devel 2011-10-02
<slangasek> someone here have a recent system with an SSD and Intel video?
<ScottK> Define recent?
<ScottK> I have a Dell Mini 10v with SSD.
<ScottK> slangasek: Act fast if you need something.  My pillow calls.
<slangasek> ScottK: can you test lp:ubuntu/initramfs-tools?
<ScottK> What do I need to do?
<slangasek> download, build, install, echo FRAMEBUFFER=y > /etc/initramfs-tools/conf.d/framebuffer, update-initramfs -u, reboot
<slangasek> confirm that you get the right splash screen and that X comes up after
<ScottK> Sounds doable.
<ScottK> It's been a bit since I messed with the sacrificial lamb, so 220 packages to update first.
<slangasek> ok :)
<slangasek> in theory this branch fixes cryptsetup+binary video drivers, but it does carry an increased risk of a race condition causing vesafb to be loaded instead of the free drm driver for some users... want to get an idea of whether that's really a problem in practice
<slangasek> actually, come to think of it, this is all in the initramfs so SSD *shouldn't* make a difference at all
<slangasek> but more data points are still welcome
<ScottK> OK
<ScottK> Seems fine.
<ScottK> Rebooted a couple of times without issue.
<slangasek> cool
<slangasek> want to accept initramfs-tools from the queue then? :-)
<slangasek> (if not, no worries)
<ScottK> Done.
<slangasek> cheers
 * slangasek uploads an nvidia-graphics-drivers to go with that
<Laibsch> Can somebody help me identify what fixed bug 460616 in natty?  I'd like to see if it's possible to backport this to lucid.  bryceh?
<ubottu> Launchpad bug 460616 in xserver-xorg-video-intel (Ubuntu) "[i915] [i945gm] Black video playback with dual screen enabled" [Medium,Fix released] https://launchpad.net/bugs/460616
<Laibsch> I had a look through the upstream ticket and upstream git, but was unable to precisely identify what fixed this
<slangasek> cjwatson: writing it all down while it's fresh in my mind; would you care to cast an eye over https://wiki.ubuntu.com/BootGraphicsArchitecture ?
<hrw> I am going to hate LP build failures. my packages (armel-cross-toolchain-base and armhf-cross-toolchain-base) both ftfbs on launchpad. but when I built them locally in pbuilder or in LP chroot they got built fine. arghhhhhh
<marsfligth> Please, how to resume from 'hibernation' or 'suspend' status pressing the 'usb keyboard' instead of press the computer power button?
<siretart> infinity: uploaded. if accepted, it'll need another upload of libav-extra (though that's in multiverse)
<infinity> Hrm.  This would probably be easier to review if I unpack it and compare patched sources...
<infinity> siretart: Go ahead with the -extra upload, this looks quite reasonable, letting it in.
<infinity> The security team will thank you, I'm sure. :P
<cjwatson> slangasek: I've corrected Q-FUNK's misconception in bug 864803, but he says that that misconception came from you, so I thought I'd check whether that was an accurate representation or whether he misunderstood something
<ubottu> Launchpad bug 864803 in linux (Ubuntu) "GRUB_GFXMODE not passed to the kernel" [Undecided,Confirmed] https://launchpad.net/bugs/864803
<slangasek> cjwatson: yes, I know it was an imprecise statement but we're doing =keep by default so it seemed negligible
<slangasek> cjwatson: speaking of my misconceptions though, any thoughts on https://wiki.ubuntu.com/BootGraphicsArchitecture ?
<stgraber> slangasek: btw, reading through that wiki page reminded me of an issue I notice on that box I just reinstalled with Oneiric server. At boot time I get stuck on vt7 so I have to manually switch to vt1 to have a login screen. Any idea where that bug would be coming from? (I'd expect "something" to do a chvt 1)
<cjwatson> slangasek: yeah, have started looking at it but won't have a full review for you until tomorrow
<cjwatson> slangasek: some of the statements about GRUB are a bit inaccurate - how much do you care about when such and such a feature was introducd?
<cjwatson> I'm pretty certain that gfxmode=auto was introduced well after gfxpayload=keep
<slangasek> cjwatson: I care that we not include false statements, but probably can't be bothered to track down when the features were *actually* introduced where it's wrong.  So we can just omit the references to the timeline :)
<slangasek> stgraber: I guess plymouth-stop.conf should handle the vt switch?
<slangasek> how was this handled previously?  did it stop working when we started using vt.handoff=7?
<slangasek> cjwatson: when I wrote that, I was thinking in terms of when features entered into the default usage in Ubuntu, btw, rather than when they became available upstream; not that this necessarily means I'm any more accurate
<stgraber> slangasek: I don't remember seeing that pre-Oneiric but I'm going to do a minimal install of natty and oneiric in a VM to make sure.
<bookpage> can i connect vnc output to the $DISPLAY var in ubuntu?
<cjwatson> slangasek: can't quite remember; gfxpayload=keep was on and off for a while; I wrote gfxmode=auto support so that it would be easier to consistently make gfxpayload=keep the default and get a consistent video mode
<cjwatson> or rather I wrote the VBE mode detection for gfxmode=auto
<stgraber> slangasek: reproduced the missing vt switch on natty too (netinstalled so it may have been introduced in an SRU)
<infinity> A shiny nickel to the first person who proposed a clean, regression-free, and vaguely elegant way to make cron.daily not run for a day after installation, so new user experience isn't horribly awful within the first 5 seconds. :P
<micahg> infinity: is install time recorded anywhere?
<lifeless> micahg: yes
<nigelb> That's probably the least dirty solution.
<nigelb> I was dreaming up checking if a certain file exists, if not touch filename, and exit the cron. If it does, execute the cron.
<nigelb> But that's probably not clean.
<lifeless> I think infinity was using irony ;)
<lifeless> or something like it
<nigelb> Hah.
<infinity> It was born of grumpy, whether there was also ironic sarcasm involved is an exercise to the reader.
 * micahg + IRC sarcasm = syntax error
<infinity> I think I might be able to blame anacron, though.
<infinity> In which case, the most elegant solution might be to smack some stamp files with a stick on install.
<infinity> Pretend that cron has run recently, instead of, like, never.
<nigelb> Its 4 am and my neck hurts like crazy. I've temporarily lost the ability to spot sarcasm.
<lifeless> nigelb: can I suggest going to bed?
<nigelb> lifeless: I'm taking that suggestion right about now. :)
#ubuntu-devel 2012-09-24
<|Anthony|> what is happening regarding consolekit and udev having been merged into systemd?
<jbicha> man, staring at the Dash for too long trying to document it, I see these minor inconsistencies
<jbicha> I guess it gives us something to do for 13.04
<pitti> Good morning
<dholbach> good morning
<bkerensa> oh submittodebian Y U crash
<alexbligh> If I publish package foo-1.deb that contains /etc/foo/bar and it is installed, then publish and install a new version foo-2.deb which does not contain /etc/foo/bar, should I expect /etc/foo/bar to be deleted? If not, how to I achieve this? (in this particular example it's a file in a run-parts-like directory)
<alexbligh> (obviously an rm in postinst will look like a local change, and an rm in preinst isn't good if the installation fails)
<pitti> alexbligh: no, it shouldn't be deleted; you need to add a debian/foo.maintscripts for that, see man dpkg-maintscript-helper
<pitti> alexbligh: that'll create proper preinst/postinst snippets for you very conveniently and robustly
<cjwatson> s/maintscripts/maintscript/
<pitti> alexbligh: I mean it shoudln't be deleted by dpkg itself
<cjwatson> (and also see 'man dh_installdeb')
<pitti> right, thanks cjwatson (see man dh_installdeb)
<ogra_> and on a nitpicker sidenote it should be -0ubuntu1.deb .... -0ubuntu2.deb, not -1.deb or -2.deb :)
<ogra_> (unless you plan to push to debian first)
<alexbligh> hmm, lucid does know of anything with 'maintscript' in, unless I'm missing something
<pitti> right, this needs dpkg (>= 1.15.7.2)
<pitti> alexbligh: for older releases you need to write the stuff manually, see http://wiki.debian.org/DpkgConffileHandling
<pitti> alexbligh: may I ask what you plan to do? changing conffiles in lucid doesn't sound like an obviously right thing to do at this point
<alexbligh> pitti, thanks - not such a trivial question.
<pitti> if you have leftover conffiles, it's usually easier to clean them up with a precise/quantal upgrade than doing SRUs for leftover conffiles
<alexbligh> pitti, oh this is partly down to my complete stupidity in putting something in /etc/ which should have been a symlink to stuff in /var.
<doko> ogra_, should we keep the dri2-utils in restricted, or move these to multiverse?
<ogra_> doko, does that come out of the libdri2 source package ?
<doko> yes
<ogra_> i can ask robclark once he is up ...
<doko> thanks
<ogra_> but given the rest of libdri2 is in restricted ....
<ogra_> (and has to stay there)
<doko> ok, I'll seed it then
<doko> Laney, debfx: about qt4-x11 and webkit ...
<doko> in 4:4.7.3-1
<doko>   * Drop 91_s390_use_gstabs.diff patch. It's no longer needed as webkit is not
<doko>     built from Qt sources anymore.
<brendand> anyone here have inside info about pep8 (the tool)?
<doko> so this issue did pop up before. but why is qt4-x11 building webkit internally again?
<brendand> i'm trying to get the --diff option to work. seems futile atm. using v1.3.3
<brendand> i'm piping a bzr diff and it's not really doing what i'd expect
<brendand> --help says it needs a unified diff (which is what bzr diff gives, right?)
<Laney> doko: interesting
<debfx> doko: it always has built qtwebkit in ubuntu
<debfx> do you think building with -gstabs instead of -g would help?
<doko> debfx, I'll wait on Laney's build with -gstabs, and then we'll know
<Laney> doko: I think the patched make will still end up being necessary, btw
<doko> and currently timing the link step
<cjwatson> My pep8(1) doesn't document a --diff option at all
<cjwatson> But that's the version in quantal which is older than the one you're talking about
<brendand> cjwatson, hmm. new feature i guess
<ahasenack> hi, can someone please sponsor/upload this SRU? https://bugs.launchpad.net/landscape-client/+bug/1053057 I believe I subscribed the right teams
<ubottu> Launchpad bug 1053057 in landscape-client (Ubuntu Precise) "Client queues up lshw calls if talking to old server" [Undecided,New]
<brendand> cjwatson, i believe mine is from pypi
<doko> pitti, just noticing https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3833224 ... 10h in the png optimizer :-/
<smb> cjwatson, Is it possible that the 12.04 ubuntu-keyring package also needs to be updated to contain the new signing key? Seems I run into problems when trying to pull recent quantal netboot images into my provisioning server
<cjwatson> yes and I opened a bug foro it
<cjwatson> but the message you get should be harmless
<smb> cjwatson, Well the script aborts in that case :/
 * xnox mostly harmless =)
<cjwatson> smb: -v
<cjwatson> it was entirely harmless in my tests
<smb> cobbler-ubuntu-import -u quantal-x86_64
<smb> failed to verify MD5SUMS via /usr/share/keyrings/ubuntu-archive-keyring.gpg (http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/current/images/MD5SUMS)
<smb> I can fetch the key manually, though
<smb> I guess I should change to use MaaS, too. But it is (was) working well enough to want to touch it
<smb> cjwatson, Ok, manually added the keys gets me going for now
<zul> doko: ping can you have a look at https://bugs.launchpad.net/ubuntu/+source/pyudev/+bug/1055482 (pyudev MIR)
<ubottu> Launchpad bug 1055482 in pyudev (Ubuntu) "[MIR] pyudev" [Critical,New]
<cjwatson> smb: Hmm, apt has no problem
<cjwatson> smb: I suspect (no surprise) a cobbler bug
<cjwatson> smb: But yeah, I'll get going on that SRU today then
<smb> cjwatson, Sort of hard relies on the keys to be there. Ok, thanks, should hopefully be a little risk change to have additional keys in that ring.
<cjwatson> smb: The bug is that it isn't happy with just one of the multiple signatures being valid and the other one having a missing key
<cjwatson> Sure, if it sees a single BADSIG it should kick it out, but one GOODSIG and one missing should be just fine
<cjwatson> Which it should have
<soren> IIRC, that script just relies on gpg to do the right thing. "gpg --verify --keyring=/path/to/ubuntu-archive-keryring.gpg [...]"
<soren> fwiw
<smb> soren, Yes, it looks like doing that...
<cjwatson> You have to be pretty careful about parsing output then
<soren> It relies on return code
<soren> I think.
<cjwatson> Yeah, but it needs to be cleverer
<smb> soren, yes
<smb> cjwatson, just did a quick test
<cjwatson> Yes, so did I
<cjwatson> You get return code 2, and detailed explanations on stdout of what's happening
<cjwatson> But that doesn't mean cobbler isn't buggy :-)
<smb> cjwatson, I would not dare to say that. :)
<cjwatson> Anyway, we clearly have to SRU ubuntu-keyring in any event - this is just exposing previously-unnoticed bugs
<cjwatson> I would
<smb> I meant I would never say cobbler is not buggy
<cjwatson> Hah
<soren> To be fair, cobbler-ubuntu-import isn't a Cobbler thing. It's an Ubuntu addition.
<xnox> cjwatson: SRU or -security, the latter seems better.
<soren> Also, that does not mean cobbler isn't buggy :)
<cjwatson> xnox: -security isn't up to me
<doko> zul, done
<doko> zul, what about yui3? I know you did downgrade these recommends to suggests for another package, but maybe that's not the best thing as these pop up again
<zul> doko: what about yui3?
<doko> zul: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<doko> zul: and a MIR for python-babel is missing
<zul> doko:  yeah i dropped python-babel for nova its pending right now
<zul> doko: javascript-common has nothing to do with me
<doko> zul: and yui3? or would that be desktop?
<Daviey> doko: that is a MAAS thing.  It is us.
<doko> mterry, didrocks: ^^^
<doko> ahh, ok
<Daviey> (not zul, but yes, server)
<zul> doko/Daviey: ah
<doko> better call it mess ...
<ogra_> mess on aargh64 in R ?
<Daviey> doko: You've managed to bring comedy to my otherwise sarcasm less Monday.
<Laney> doko: collect2: error: ld returned 1 exit status
<Laney> libtool: install: error: relink `libwebkitgtk-1.0.la' with the above command before installing it
<zul> doko:  wait you just duplicated the pyudev MIR?
<doko> zul, no, just made it a duplicate
<doko> Laney, just to double check, there's no -g overwriting -gstable on the command line for the build of the object files?
<zul> doko: ah you are going to promote it right? :)
<doko> zul: as I did say. it's done :)
<zul> doko: cool thanks
<stokachu> stupid question,is verification-done-precise needed in order to have the job process it or is just verification-done all thats needed
<Laney> doko: no, not that I can see
<Laney> it's a different error anyhow
<doko> ok
<doko> Laney, could you try the link with -B/usr/lib/gold-ld/
<smb> stokachu, If it was verification-needed-precise (or so) then it needs ...-done-precise to match it to that release (usually replace the needed by done in the tags)
<stokachu> ah ok, so for future just mimick whatever the verification-needed* is
<smb> yes
<stokachu> and any idea how long it takes bug watcher to process those bugs?
<didrocks> doko: ok, thanks for keeping us in touch :)
<smb> stokachu, Not for generic packages. For the kernel I believe the bot runs every hour
<stokachu> smb: ok thanks, according to one bug it seems to be longer than 12 hours
<Laney> doko: looking more promising
<Laney> oh, wait what
<Laney> *exactly* when I said that it failed collect2: error: ld returned 1 exit status
<doko> heh
 * Laney gives both pieces back to seb128 :P
<doko> Laney, ok, I'll look at it. first trying without the make patch, but using ulimit -s 16384
<seb128> Laney, nah, you touched it, it's all yours :p
<seb128> ev, hey
<seb128> ev, is there known issue with e.u.c? I'm wondering why bug #1053670 is not showing up on the daily or monthly view seeing the list of duplicates from the retracers, whoopsie should at least have the same number and that should be enough to make it displayed on the main page
<ubottu> Launchpad bug 1053670 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance_cast()" [High,Confirmed] https://launchpad.net/bugs/1053670
<dholbach> chrisccoulson, micahg: do you think one of you could reply to https://twitter.com/lmukadam/statuses/249471182510882816?
<fginther> infinity, ping
<micahg> dholbach: I think I'll leave that to chrisccoulson
<dholbach> ok cool
<seb128> dholbach, what did they announce?
<dholbach> seb128, I guess it's about thunderbird having less of a focus on new features
<seb128> dholbach, is that something we can do something about?
 * micahg doesn't think it should impact us at all
<seb128> well, I don't even see what we can say or reply to that
<seb128> "good for them?"
<seb128> ;-)
<dholbach> I just wanted somebody with more of an idea of what's going on to answer the question.
<micahg> aside from most of the updates having less regression potential :)
<dholbach> @ubuntudev catches all kinds of questions
<udevbot> Error: "ubuntudev" is not a valid command.
 * micahg isn't even on twitter
<xnox> dholbach: wasn't there a blog post on ubuntu-planet after thunderbird announcement from jono or someone like that explain the FUD and effects on ubuntu?!
<dholbach> I'm not quite sure
<dholbach> ah, this one: http://www.jonobacon.org/2012/07/11/thunderbird-and-ubuntu/?
<xnox> dholbach: yeap. gosh my memory is good =)
<Daviey> doko: Hey, would you be able to look at python-tx-tftp please?
<doko> Daviey, look at what?
<Daviey> doko: your recent rebuild uncovered a rebuild-FTBFS.  I wondered if you had capacity to look at it?
<doko> Daviey, not today, didrocks is on +1 maintenance too. maybe barry could look at this one too?
<barry> Daviey: url?
<Daviey> barry: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3837059
<Daviey> barry: I reproduced it... Not sure what would have introduced that... ideas?
<barry> Daviey: it's pretty clearly a bug in the code causing the exception during error logging.  my guess is that the error being logged is not expected, otherwise upstream would have surely encountered that bug during the test suite.  unless of course one of our patches introduced the bug.  let me grab the package and take a look
<infinity> fginther: G'morning.
<fginther> infinity, I sent some private messages, please let me know if you didn't receive
<sil2100> slangasek: hi!
<sil2100> slangasek: we were able to verify all unity/nux/unity-2d related SRU bug fixes from the pending SRU task queue
<sil2100> slangasek: all is green ;)
<ogra_> sil2100, properly tested on arm ?
<ogra_> :)
<sil2100> ogra_: erm ;)
<ogra_> and patches updated etc ...
<Daviey> barry: it built when last uploaded, so something in the environment has changed.. not the package.
<Laney> if only that meant it wasn't a bug in the package
<barry> Daviey: doko thinks it may be a twisted update
<Daviey> certainly possible :)
<barry> Daviey: my suspicion is that, while the test failures are obvious bugs, they aren't the root cause.  i am going to fix the obvious bugs and try another local build.
 * xnox twisted update or update to twisted package....
<Daviey> barry: thanks
<barry> Daviey, doko: well, maybe we got lucky with it.  fixing those obvious bugs fixes the ftbfs, and that's all we care about, right? :)
<barry> anyway, i'll upload the fix
<Daviey> barry: thanks muchly!!
 * zyga has brief connection issues on the regular machine
<hrw> doko: iptraf ftfbs fixed by new upload to Ubuntu. patch sent to Debian
<hrw> shit. its main not universe
<hrw> doko: http://people.linaro.org/~hrw/ubuntu/to-sponsor/ has fixed iptraf
<sil2100> ogra_: we don't really have the tools to test unity 3d on arm ;(
<sil2100> ogra_: but it builds!
<hrw> sil2100: how do you test unity 3d on x86?
<ogra_> sil2100, *every* team in the company has pandaboards, if you dont have any yet, please talk to your manager (which will likely have to ask rickspencer3 )
<sil2100> hrw: we run it, we run autopilot on it, we run manual tests
<ogra_> s/which/who/
<sil2100> ogra_: popey !
<sil2100> ^
<ogra_> sil2100, beyond that you can ask QA for SRU test help
<sil2100> ogra_: anyway, thanks for the reminder - when I'm doing typical desktop stuff, I tend to forget the important stuff
<sil2100> Like arm!
<ogra_> well, its just that someone has to fix it if its brokebn in the end ... the last times we did that it burned a lot of workhours
<hrw> I would love to forget about pandaboard (and other cheap boards) existance ;)
<ogra_> so pretty please test before uploading if any possible
<popey> thanks ogra_
<ogra_> hrw, any expesive boards that are better ?
<xnox> hrw: actually pandaboards are not that cheap =) it's not like it's raspberry pi.
<ogra_> lol
<ogra_> you cant compare the two
<hrw> xnox: I do not bother with <armv7a boards
<ogra_> RPi is as powerful as the beaglebone
<ogra_> and costs about the same
<hrw> ogra_: problem is that no one wants to produce serious boards
<ogra_> (but the bone is an open HW platform, RPi is completely closed)
<hrw> ogra_: beaglebone >>>> r/pi ;D
<ogra_> yeah
<ogra_> but the hype factor is so much lower ;)
<hrw> I have to write 2012 edition of 'whats wrong with those cheap developer boards'
<hrw> s/developer// anyway
<infinity> doko: Ouch, those test-rebuild results aren't comforting.
<hrw> anyway so far I do not bother with <armv8a - things may change if popey will request me to care about armv7a again
<popey> heh
<smoser> anyone around familiar with initramfs?
<ogra_> smoser, just ask ?
<smoser> i'm looking at open-iscsi, which runs a module at local-top
<smoser> init (http://paste.ubuntu.com/1224803/)
<smoser> i dont see how it can assume that any modules have been loaded, and thus 'configure_networking' is going to have network devices to configure
<smoser> (i know it seems to work for me, but i'm not sure i understand how)
<hrw> popey: do not heh :) I am now working on aarch64 for most of my time
<infinity> hrw: You forgot update-maintainer(1) on that uptraf upload.
<infinity> hrw: (Fixing and sponsoring)
<ogra_> smoser, udev should load the module
<sarnold> smoser: line 237 runs load_modules, fwiw
<hrw> infinity: ops, it was 3-4 iteration of change... one of them had it done ;)
<ogra_> sarnold, that only loads from /etc/modules
<smoser> sarnold, right. but that is after init-top ran
<smoser> ogra_, is correct about udev
<smoser> i suppose ther emust be some udevadm settle
<smoser> somewhere.
<ogra_> smoser, the open-iscsi script should have a PREREQ var at the top
<smoser> it does not
<smoser> http://paste.ubuntu.com/1224813/
<hrw> infinity: tomorrow I hope to find some time to take a look at other ftfbs entries
<infinity> hrw: Cool, thanks.
<smoser> so, the fact that udev is run at init-top was the bit  i was missing. but it would sure seem that modules should be loaded even before udev.
<ogra_> smoser, then you are just lucky that udev ran before (if it actually lives in init-top too)
<smoser> udev runs in init-top, openiscsi runs at local-top
<smoser> but i think its still lucky
<ogra_> no
<ogra_> then its fine
<smoser> where would a 'settle' be run?
<ogra_> local-top runs after init
<ogra_> in the udev script i think
<smoser> i dont see it there.
<ogra_> smoser, /usr/share/initramfs-tools/scripts/functions
<smoser> where do you tihnk that gets called from ?
<smoser> just curious
<hrw> infinity: for most of my foss life I was kind of Build Engineer ;)
<infinity> hrw: Sounds familiar. ;)
<ogra_> smoser, not from open-iscsi, but you could if you dont want to count on pure luck
<ogra_> smoser, see the nfs scripts ...
<smoser> right. so its luck.
<smoser> realistically, configure_networking should do it.
<Laney> barry: do you fancy forwarding the python-tx-tftp fix upstream?
<barry> Laney: sure
<Laney> cheers
<tumbleweed> naughty barry? :)
<Laney> Forwarded: no make laney sad
<barry> mostly just timing :)
<smoser> anyone know what creates the 'netdev' group ?
<stgraber> smoser: at least avahi-daemon and wpasupplicant, likely some others
<barry> Laney: https://github.com/shylent/python-tx-tftp/issues/8
<cjwatson> smoser: user-setup used to, in feisty and gutsy
<smoser> cjwatson, i was just trying to figure out why it was there. its been presnt in the cloud-images for all releases i've been involved with (came from vmbuilder and behavior was moved forward).
<smoser> hanks.
<Laney> barry: thanks muchly
<micahg> trism: what's this npapi-sdk.pc you speak of?
<trism> micahg: one of the checks in gecko-mediaplayer configure.in is for npapi-sdk (for https://wiki.mozilla.org/NPAPI I imagine), my thought was firefox-dev could just provide npapi-sdk instead of mozilla-plugin since it only has the npapi headers now
<trism> micahg: and mozilla-plugin.pc includes stuff we don't have in firefox-dev anymore (like /usr/lib/firefox-devel)
<micahg> trism: that would be nice, but it doesn't exist in mozilla-central AFAICT
<micahg> mozilla-plugin.pc just includes paths
<trism> micahg: yeah it was just a thought, the workaround in gecko-mediaplayer should be fine
<trism> micahg: yes paths that don't exist
<micahg> trism: both of those directories exist on my sytem
<micahg> *sysyem
<micahg> *system
<trism> micahg: precise? because /usr/lib/firefox-devel isn't in quantal
<micahg> ah, right
<micahg> yeah, that's a bug
<micahg> oops, need to install the package first...
<micahg> chrisccoulson: ^^ shouldn't we patch sdkdir out of the mozilla-plugin.pc file since we're not providing it?
<SpamapS> hallyn: having trouble with lxc on quantal.. I see a lot of this..
<SpamapS> [19878.384552] unregister_netdevice: waiting for lo to become free. Usage count = 1
<SpamapS> stgraber: ^^
<stgraber> yep, it's known, it's the second time you're affected btw, I already got you to comment on the bug last time ;)
<SpamapS> Yes I recall
<SpamapS> just wasn't SURE it was the same thing
<SpamapS> stgraber: upstream is fixed right? so its just a matter of figuring out how and backporting?
<stgraber> ogasawara: any progress on that one? ^ I'm really not looking forward to releasing with that regression
<SpamapS> its pretty serious for the juju local dev story :(
<stgraber> SpamapS: upstream is apparently fixed (that or the kernel was somehow different) but nobody figured out what to cherrypick yet
<stgraber> SpamapS: the kernel team is supposedly on it but doesn't seem to be making a lot of progress lately (based on the comments)
<ogasawara> stgraber: I've pinged cooloney for a status update today
<stgraber> ogasawara: ok, thanks
<ogasawara> stgraber: I won't be fixed for Beta-2, but I want it figured out by kernel freeze.
<ogasawara> s/I/It/
<stgraber> ogasawara: yeah, wasn't expecting it to be fixed for beta-2 but it's not something I'd like to see miss the release. We had to go through something similar last time with some apparmor issues and I'm still getting e-mails from people running a buggy kernel (original 12.04 release kernel)
<stgraber> (apparently you can't assume that people apply updates on their machine...)
<hallyn> ogasawara: i don't want to step on coolonely's toes, but if he's short on time should i be changing some other priorities to look into that one (netns refcount bug)?
<SpamapS> stgraber: kernels are especially prone to that because some people reboot so seldom.
<SpamapS> the bad part about this one is that once it happens, lxc just seems hosed
<ogasawara> hallyn: I'll be pulling in smb as backup if cooloney hasn't already got the fix isolated.  I should hear more by morning.
<SpamapS> have to reboot :-P
<SpamapS> root     29866  0.0  0.0  27532  1028 ?        Ds   12:01   0:00 lxc-start --daemon -n clint-local-ci-u2-0 -l DEBUG -o /home/clint/.juju/data/clint-loc
<SpamapS> lxc-starts just go into diskwait (presumably on some cgroup operation)
<hallyn> ogasawara: great, thanks
<jP_wanN> hello :)
<jP_wanN> I recently found a bug in gtkmm ( at least I think so :D ). For which package do I create a bug report?
<jP_wanN> libgtkmm-3.0-dev or libgtkmm-3.0.1
<sarnold> jP_wanN1: the -dev is really there for compiling other packages against libgtkmm; if you found the problem that way, then the -dev would make more sense to me, lacking any further direction...
<jP_wanN1> sarnold: no, I've got a problem using gtkmm in a program I'm programming. so i should file a bug for libgtkmm-3.0.1 ?
<jP_wanN1> by the way, why did thunderbird add a "1" to my nick / how to change that? some time before, the authorization worked fine.
<sarnold> jP_wanN1: I'd probably file against the -dev package. (Since it's liable to be the same source package in the end, it might not even matter)
<jP_wanN1> okay thanks
<jP_wanN1> i'll try to reconnect now ^^
<jP_wanN> okay now I searched to avoid filing a duplicate of an existing bug
<jP_wanN> seems I should have done that before :D
<jP_wanN> now that bug report is for gtkmm 2.4 (ubuntu 7.10)
<jP_wanN> it's marked as incomplete
<jP_wanN> should i file a new bug?
<sarnold> jP_wanN: hah, good question :) that's an _old_ bug for a distro that's probably long unsupported...
<cjwatson> bugs don't in general go away when the release they were filed on stops being supported ...
<jP_wanN> sarnold: Yes I know, Ubuntu 7.10 is quite old :D I'll just open another bug and add a link to the other one I've found.
<cjwatson> (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html)
<sarnold> thanks cjwatson :)
<jP_wanN> cjwatson: I also found out that there was some issue like this (_could_ be the same) that was (should have been) fixed with gtkmm 2.8
<stgraber> cjwatson: it's been a while since I last saw you point to that link ;)
<jP_wanN> btw, here is the bug report i dounf https://bugs.launchpad.net/ubuntu/+source/gtkmm2.4/+bug/30345
<ubottu> Launchpad bug 30345 in gtkmm2.4 (Ubuntu) "ScrolledWindow doesn't properly remove widget from Viewport parent when calling ->remove()" [Medium,Incomplete]
<jP_wanN> so here is the new bug report if anyone cares ^^
<jP_wanN> https://bugs.launchpad.net/ubuntu/+source/gtkmm3.0/+bug/1055744
<ubottu> Launchpad bug 1055744 in gtkmm3.0 (Ubuntu) "can't remove a widget correctly from a Gtk::ScrolledWindow" [Undecided,New]
<jP_wanN> now, can somebody tell me how I can (try to) debug gtkmm myself? :)
<jP_wanN> I've already read and completed the tutorial
<jP_wanN> http://developer.ubuntu.com/packaging/html/getting-set-up.html
<seb128> cyphermox, still around? if you see robert_ancell around later could one of you reupload evolution to quantal-proposed with a build-depends on libgtkhtml4.... > 3.6? the current version built with 3.5 and the shlibs in gtkhtml4 is using a >> << that breaks installability
<cyphermox> oops
<cyphermox> sure
<cyphermox> I wish I could fix the webkit plugin stuff first, then it would be fixing two bugs with one stone
<bkerensa> seb128: what day of week are patch pilots done?
<seb128> bkerensa, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<bkerensa> seb128:  grazi
<seb128> yw ;-)
<seb128> cyphermox, thanks
<james_w> any ideas as to why a build in sbuild wouldn't have a debian dir?
<james_w> no, that's not it
<james_w> make: dpkg-architecture: command not found
<mlankhorst> needs dpkg-dev?
<james_w> mlankhorst, I'm pretty sure it's installed
<mwhudson> james_w: architecture mismatch?
<james_w> mwhudson, possibly
<james_w> mwhudson, I'm not sure how though, as I'm not seeing it outside the chroot
<mwhudson> just because that can lead to arbitrarily confusing error messages ime
<mlankhorst> oh right
<james_w> I'm starting to think that message doesn't mean "dpkg-architecture command not found"
<mlankhorst> try to ldd it? maybe one of the libraries it depends on is missing
<mwhudson> james_w: as in running $chroot/usr/bin/dpkg-architecture works?
<james_w> mwhudson, as in "dpkg-architecture" works, but "$(shell dpkg-architecture)" in debian/rules doesn't
<james_w> just on my base system
<mwhudson> oh
<slangasek> james_w: that error /should/ mean that the dpkg-architecture command isn't found.  $PATH issue?
<slangasek> (strace to debug?)
<james_w> oh
<james_w> /usr/bin/dpkgâarchitecture
<slangasek> hahaha
 * slangasek waves at the emdash
<mwhudson> lol
<mwhudson> how did you do _that_?
<sarnold> cjwatson: re: bug triage, you mention, "Check whether the package is being actively worked on." -- what's the best way to tell if a package is actively being worked on? MOTU vs a developer name in apt-cache output?
<james_w> mwhudson, copied from a web page
<cjwatson> sarnold: changelog is a reasonable guide
<sarnold> cjwatson: say, if it shows more than just "import from debian" entries?
<cjwatson> That's one option, though sometimes that means a REALLY active Ubuntu developer who's just also active enough in Debian to push everything there.
<cjwatson> You do have to use judgement.
<sarnold> cjwatson: aha. :) good point. Thanks!
<lamont> why is it that when I lock my screen and go away and come back, I'm thankful that I told it to let ctl-alt-backspace kill X, since I can't get the opportunity to type in my password and unlock the screen?
<sarnold> lamont: I wonder if you've hit https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1054198 or similar bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744  (probably too polluted)
<ubottu> Launchpad bug 1054198 in xserver-xorg-video-intel (Ubuntu) "Thinkpad T510 doesn't come out of screensaver" [High,Incomplete]
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed]
<doko> cjwatson, is the regexp syntax in the seeds regexp or extended regexp?
<lamont> 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18)
<lamont> sarnold: ^^
<lamont> I get a black screen, and a mouse cursor
<lamont> s/mouse//
<sarnold> lamont: we may have a winner :)
<lamont>         Kernel driver in use: i915
<cjwatson> doko: python re
<cjwatson> doko: which is closer to extended iirc
#ubuntu-devel 2012-09-25
<kees> well that was fun. installed precise on top of a machine that had lucid on it. alternative install decided it was an EFI machine (BIOS yes, drive layout no), and installed grub-efi which happily ignored the old grub on the sda, which became highly confused about drives moving.
<kees> seems like partman needs to learn about GPT and offer that on EFI machines.
<cjwatson> Err
<cjwatson> partman learned about GPT years ago and it's the EFI default
<cjwatson> This is a bug, not a missing feature
<cjwatson> But
<cjwatson> If you already have a partition table, it isn't sane to offer a different partition table type
<cjwatson> Rewriting the partition table would be very scary and very likely to break whatever's already on there
<cjwatson> Dual-booting BIOS and UEFI installs on the same disk is not likely to work desperately well in general, really; you lose either way round
<cjwatson> A BIOS boot loader can't boot a UEFI install, so leaving the existing GRUB on there wasn't an option, and as you say there are confusion issues with using a UEFI boot loader
<cjwatson> Probably the right thing to do was to boot the installer in legacy mode (there's generally an option for this in the firmware boot menu) and then it would have proceeded in BIOS mode
<cjwatson> If the installer is booted using UEFI, it assumes that it should install using UEFI too
<cjwatson> Though if you weren't preserving the old partition table (it's not clear?), then perhaps we should zero out the old boot sector when doing a UEFI install
<cjwatson> I dunno, doing that kind of thing scares me a bit
<cjwatson> Maybe do it at the time the old partition table is wiped instead
<pitti> Good morning
<em> good morning
<pitti> infinity, RAOF: I'd be grateful if you could process the postgresql-9.1 SRUs for bug 1055944
<ubottu> Launchpad bug 1055944 in postgresql-9.1 (Ubuntu Precise) "New bug fix releases: 9.1.6, 8.4.14, 8.3.21" [Undecided,In progress] https://launchpad.net/bugs/1055944
<pitti> infinity, RAOF: standard microrelease exception, but the -9.1 update is rather urgent and people are nagging for it
<RAOF> pitti: Sure.
<pitti> I'll do the verification as soon as the packages are built in -proposed
<pitti> RAOF: merci beaucoup
<RAOF> Bitte
<RAOF> pitti: Done.
<pitti> RAOF: cheers! I uploaded the 8.4/8.3 updates as well, but they are a bit less urgent
<RAOF> I might do them tomorrow on my regular processing day if infinity doesn't get to them first.
<pitti> sounds fine
<infinity> RAOF: Thanks for catching those, I was out all evening.
<infinity> pitti: Many thanks for the fixed glib.
<pitti> infinity: well, here's hoping it'll build at last..
<pitti> I have no idea what changed on the arm builders that they suddenly became so slow/loaded/whatever
<pitti> infinity: btw, if/when that builds, do you want them copied to quantal? there's no source changes compared to the one in quantal, just the arm ftbfs fix
<pitti> infinity: but that would need coordination with image respins, of course
<pitti> well, only source changes in tests, that is
<dholbach> good morning
<pitti> hey dholbach, how are you?
<freyja_> can this https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1055766 bug just be deleted? It is a waste of everyone's time and immature. It's posted on /r/linux and will contribute to FUD. It's a waste of time and burden on the community.
<ubottu> Launchpad bug 1055766 in command-not-found (Ubuntu) "grep -R doesn't automatically search amazon" [Undecided,Confirmed]
<dholbach> hey hey pitti - doing well, I'm almost over my cold :)
<dholbach> how are you?
<pitti> dholbach: je vais tres bien, merci :)
<dholbach> excellent :)
<bryceh> infinity (or another archive admin), mind bumping the nvidia packages from NEW?  https://launchpad.net/ubuntu/precise/+queue
<bkerensa> bryceh: I did the fix you had for task
<bryceh> bkerensa, awesome thanks.  Yes I did spot that today.
<bkerensa> bryceh: do you think it will land quantal?
<bryceh> bkerensa, one thing I noticed was that the fix was applied to source, rather than as a patch in debian/patches/, so I wanted to take a look at that.
<bkerensa> k
<bryceh> bkerensa, yes I am certain it will.  Even if it has to be SRU'd in post release, I'll help you make sure it happens.  :-)
<bryceh> bkerensa, would you like to take a shot at adding the patch in debian/patches/ ?
<bkerensa> hmm
<bkerensa> I dont think I have done that before
<bkerensa> let me go rtfm for a bit and have a try
<bryceh> it looks like I already set up quilt for this package.  I think all you need to do is create a "debian/patches/<something>.patch" file, and then also add that filename to debian/patches/series and a changelog entry
<bkerensa> hmm
<bkerensa> ok
<bkerensa> and revert the source back to what it was?
<bryceh> yep
<bkerensa> k
<bryceh> bkerensa, cool, it's a good thing to learn to do.   If you get stuck or have questions just drop me a PM or email and I'll help.
<Daviey> RAOF: hey, the precise unapproved SRU queue is looking pretty huge.. is iot being attacked?
<Daviey> (The reason i noticed, is that we are being nagged for openvswitch which has been there since the 8th.)
<bkerensa> bryceh: ok I made the changes I understand need to be made can you check and let me know if it looks sane or just comment needs fixing with suggestions
<bkerensa> thx
<bryceh> bkerensa, ok will do
<bryceh> bkerensa, ok this looks good!  But a couple suggestions
<bkerensa> bryceh: sure
<bryceh> bkerensa, the patch should be named to mention what it's solving, not just a bug number since that can just be looked up easy enough
<bkerensa> ok
<bryceh> so in this case maybe let's see...
<bryceh> only_stack_size_1.patch
<bryceh> or whatever... something like that
<bryceh> bkerensa, second, if the changelog make sure to answer three questions:  1.  Where did the  patch come from (e.g. upstream bug number or url), 2.  What does the patch do, and 3. What is the problem it fixes.
<bkerensa> ok
<bryceh> s/if the/in the/
<bryceh> so 3 is "Fixes a crash when ...."
<bryceh> 2 is something like "Check that the stack size is exactly 1 rather than just some value lower than 2" (or look at the upstream bug report if they give a better explanation)
<bryceh> and 1 is just "Fixes upstream crash bug #xyz"
<bryceh> as part of #1 I usually like to indicate if the patch was taken directly from upstream or if I've had to modify it in some fashion to get it to apply.  But that's probably irrelevant here.
<bkerensa> bryceh: how do we list bug #'s for projects like task?
<bkerensa> bryceh: "Cherrypick patch from upstream bug 1048 to fix a segfault when modify"
<ubottu> Launchpad bug 1048 in HCT "hct doesn't automatically register archive" [Undecided,Invalid] https://launchpad.net/bugs/1048
<bryceh> bkerensa, "upstream bug 1048" would be sufficient.  Anyone looking at the package could be expected to figure out where their bug tracker is.  But if you want to be super clear you could just paste the full URL.
<ubottu> Launchpad bug 1048 in HCT "hct doesn't automatically register archive" [Undecided,Invalid] https://launchpad.net/bugs/1048
<bkerensa> bryceh: ok and do I need to still mention our bug?
<bryceh> bkerensa, yep always.  Just like you did, (LP: #1032861) appended to the description is perfect
<bryceh> btw you don't have to mention that you updated the series
<bkerensa> bryceh: ok all done
<bryceh> bkerensa, good work!  Oh one last thing.  In this case instead of "* debian/patches:" can you make the changelog read "* debian/patches/only_stack_size_1.patch:"
<bkerensa> surely
<bryceh> it's nitpicky in this case since there's just the one patch, but in packages with a lot of patches it is helpful since then other devs can search for the patch name to see when it got added and why
<bkerensa> bryceh: done and pushed
<bryceh> bkerensa, excellent, looks good.
<bryceh> bkerensa, upload sponsored for quantal. thanks again!
<bkerensa> bryceh: :) thx
<ev> mpt_: well, we could have done worse: http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-09-25%20at%2010.21.16.png
<seb128> ev, hey, did you see my ping yesterday?
<ev> seb128: no - I guess that was past my irc bouncer scrollback buffer
<ev> what's up?
<ev> (I was on holiday friday and monday)
<seb128> ev, is there known issue with e.u.c? I'm wondering why bug #1053670 is not showing up on the daily or monthly view seeing the list of duplicates from the retracers, whoopsie should at least have the same number and that should be enough to make it displayed on the main page
<ubottu> Launchpad bug 1053670 in DBus Menu "nautilus crashed with SIGSEGV in g_type_check_instance_cast(), from settings_notify_cb(), in dbusmenu's parser.c" [High,Fix committed] https://launchpad.net/bugs/1053670
<ev> seb128: it may have failed to retrace on the daisy retracers (but not the crash-digger ones): https://bugs.launchpad.net/daisy/+bug/1044418
<ubottu> Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New]
<ev> I'll try hunt it down on errors.u.c in a bit
<ev> thanks for bringing that to my attention
<seb128> ev, thanks
<dpm> xnox, are you now maintaining ubiquity? And if so, could you look at bug 1040438 if you've got some time? thanks!
<ubottu> Launchpad bug 1040438 in Ubuntu Translations "[l10n] Indicator menus of "Accessibility" should be localized for installer" [High,Triaged] https://launchpad.net/bugs/1040438
<xnox> dpm: i'm not the only maintainer =) there are a few in the installer team taking. Well I saw the bug mail & there are a couple of other l10n issues, I may look at them in bulk sometime.
<dpm> xnox, thanks. Yeah, I just wanted to know the best person to poke. I used to ping Evan, but I wasn't sure if he still maintained it
<xnox> dpm: the best way is to simply add a tag 'rls-q-incoming'
<dpm> xnox, cool, thanks.
<xnox> and then appropriate teams will triange the bug and either nominate it for a release, assign to correct 'maintainer' etc.
<xnox> dpm: that tag works on any supported package ;-)
<xnox> not just ubiquity.
<cjwatson> it's not a guarantee; we do elect not to commit to fixing some rls-q-incoming bugs
<cjwatson> if the number of people using it rises, I expect we will commit to a lower percentage :)
<pitti> ev: hey Evan, how are you?
<pitti> ev: If you have a minute, I'd appreciate your opinion in bug 1039220 before I merge that branch
<ubottu> Launchpad bug 1039220 in apport (Ubuntu Quantal) "don't report crashes for programs that don't match the file on disk (like for kernel crashes)" [Medium,In progress] https://launchpad.net/bugs/1039220
<ev> hi pitti! I'm excellent, thanks.
<ev> how are you?
<ev> will do!
<pitti> ev: I'm great, thanks! (when I'm not headdesking on glib FTBFS, that is :) )
<ev> :)
<doko> pitti, please see the pkgbinarymangler ftbfs
<doko> directhex, gnome related ftbfs: libgtk2-perl, (main), gcompris, glade-3, gestreamermm, launchpad-integration, libgnomecups (package sets)
<doko> forgot gtk2-engines
<doko> tkamppeter, please have a look at the hplip ftbfs, https://launchpadlibrarian.net/117005844/buildlog_ubuntu-quantal-i386.hplip_3.12.6-3ubuntu1_FAILEDTOBUILD.txt.gz
<directhex> doko, hm?
<doko> seb128, please could you add the ubuntu-toolchain-r ppa as a dep to the webkit ppa, and give back webkit?
<seb128> doko, can do
<doko> directhex, should have been didrocks
<seb128> didrocks, doko: I will look at those desktop ftfbses, didrocks is already under heavy pinging and todo ;-)
<didrocks> doko: right, so you are quite lucky to not be under this load
<doko> seb128, and any desktopish ftbfs ;)
<seb128> doko, will do
<davmor2> Hey guys I see a launcher for amazon after todays updates however if I click on it, it opens FF and then removes the launcher
<doko> pitti: ubuntu-defaults-builder ftbfs
<Laney> doko: the make patch is not needed?
<seb128> Laney, I guess it is, binutils should fix the ar issue, not the argument list one
<Laney> that's what I think
<pitti> doko: yes, will do
<doko> Laney, I didn't see it in the ppa
<Laney> doko: https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages
<Laney> doko: and do you mean ubuntu-toolchain-r/test, staging or ppa?
<doko> Laney, ppa
<Laney> I'll try without make first
<Laney> doko: https://launchpad.net/~laney/+archive/webkit/+build/3853350
<doko> looks like we were not good with merging this cycle ...
<cjwatson> doko: I'm looking at klibc
<pitti> doko: u-defaults-builder test failure points out a config file format change in unity, so that's great to catch \o/
<doko> Laney, pitti: libproxy looks like your pet
<doko> ftbfs ...
 * pitti bounces to Laney
<Laney> ta
<Laney> probably just a missing include
<pitti> doko: defaults-builder FTBFS fix uploaded to unapproved
<pitti> I cannot reproduce the pkgbinarymangler FTBFS here, all tests work; trying in my PPA; looks like pkgbinarymangler is installed in the rebuild test environment, but in some special way
<doko> it shouldn't be anything special, nothing preseeded
<pitti> oh hang on
<pitti> ok, lunch, then fix :)
 * doko is staring at the ppp ftbfs
<Laney> libproxy uploaded
<alexbligh1> Does this quantal->precise backport request have a snowball's chance in hell of succeeding? (allows Precise to mount Windows 2012 server exported SMB drives). Not trying to persuade anyone, just get an idea of the height of the hurdle for backport requests.
<alexbligh1> https://bugs.launchpad.net/precise-backports/+bug/1056137
<ubottu> Launchpad bug 1056137 in Precise Backports "Please backport samba 2:3.6.6-3ubuntu4 (main) from quantal" [Undecided,New]
<tumbleweed> alexbligh1: it sounds like a big enough issue that it should be dealt with by an SRU rather than a backport (backports don't exist to fix bugs)
<tumbleweed> but I have no idea how big the patches to bring win 2012 support to the version in precise would be
<tumbleweed> in general, for a backport to have a snowball's chance in hell of succeeding: you should do all the testing requestbackport asks for
<alexbligh1> tumbleweed, the issue (both with an SRU and the testing) is that updating the samba source package means the SMB /server/ gets updated too. I have no idea how to test that fully as I haven't got any Windows clients, printers, blah blah blah. I've not much idea what has changed server side. All I really want to update is the client, so Precise can mount Windows 2012 servers. Windows 2012 clients will (I believe) mount older servers an
<alexbligh1> ywhere.
<alexbligh1> s/anywhere/anyway/
<alexbligh1> I'd be nervous about changing the default *server* (by upgrading samba). If it were possible to break out just the library from Samba, that would I think be far safer.
<tumbleweed> alexbligh1: we apply minimal patches in SRUs - so it would only be SRUable if there was something fairly minimal that could be applied
<tumbleweed> anyway, chat to the #ubuntu-server people
<tkamppeter> doko, I am looking currently into that. The starnge thing which happemns here is that formaerly HPLIP built perfectly and suddenly, all "->" raises the error "dereferencing pointer to incomplete type".
<tkamppeter> doko, do you have any idea what that means? The CUPS API did not change with respect to these data structures, and HPLIP built some weeks ago.
<doko> tkamppeter, I assume some reorganization did change. glib, gtk?
<doko> header reorg, I mean
<alexbligh1> tumbleweed, thanks
<tkamppeter> doko, the data structures are defined in CUPS but they did not change, they still match. Strange is also that EVERY "->" raises the error.
<tkamppeter> cupsext
<cjwatson> tkamppeter: That indicates that at the point when the compiler encounters the thing before the ->, it doesn't have a full definition of its type
<cjwatson> i.e. usually missing header or similar
<tkamppeter> cjwatson, earlier in the code there is a line "ipp_t *request = NULL;", which clearly assigns the correct type to the variable "request", and assuming that the header would be missing, the compiler should already complain at "ipp_t" which it does not do.
<doko> tkamppeter, but at this point, it doesn't need to know the struct
<dholbach> I'm doing an ubuntu development hangout in ~30m - would anyone like to co-host it with me? :)
<cjwatson> tkamppeter: not true
<cjwatson> tkamppeter: the compiler has enough information for "ipp_t *request = NULL;", because the size of a pointer is the same no matter what it points to.
<cjwatson> tkamppeter: that doesn't mean it has enough information to dereference the point
<cjwatson> *pointer
<stgraber> dpm: a broken html file was preventing the generation of updated pot templates...
<stgraber> dpm: I'll do a manual import of the new .pot in launchpad for now and will do a full translation update before release.
<dpm> stgraber, excellent. Could you just ping me when you've done the manual import, so that I can give a heads up to translators?
<tkamppeter> cjwatson, thank you very much. I have found the cause of the problem now, in the CUPS *.h files new conditionals to hide the private data structure from non-CUPS builds were added. Now I succeeded to rebuild the package by overriding the conditionals via "-D..." in CFLAGS.
<stgraber> dpm: done
<stgraber> dpm: LP correctly reports the "Welcome to Ubuntu 12.10" string as needs translation now
<cjwatson> tkamppeter: Right.  Though be careful as that kind of thing often indicates that the relevant structures are now considered private and won't be ABI-stable
<sconklin_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: sconklin_
<cjwatson> Sometimes it goes along with better alternative ways to do the same things (e.g. accessor functions)
<cjwatson> Not that I know anything about CUPS, this is just standard practice for libraries
<diwic> doko, I believe I have fixed the quantal ftbfs for libffado (by cherrypicking a patch from upstream), where do I put it so that someone finds and uploads it?
<dpm> stgraber, excellent, thanks!
<doko> diwic, please open a bug report
<doko> or just put the diff.gz and .dsc somewhere where I can fetch it
<diwic> doko, ok, will ping you once I have a debdiff ready
<doko> can't explain the noweb build failure on armhf, giving it back
<tkamppeter> cjwatson, I have reported the problem upstream to the HPLIP guys now: bug 1056214. Feel free to comment.
<ubottu> Launchpad bug 1056214 in HPLIP "HPLIP does not build with CUPS 1.6.1 or newer" [Undecided,New] https://launchpad.net/bugs/1056214
<Laney> Subject: [Build #3853350] amd64 build of webkit 1.9.91-0ubuntu1~build1 in ubuntu quantal RELEASE (laney-webkit PPA) :(
<tkamppeter> doko, cjwatson, fixed HPLIP uploaded.
<Laney> ok, so I'll take the new make-dfsg now
<ev> mpt: http://poppy-dev.local/ - is that dot pattern what you're after, or should we go a blank background or something else?
<doko> Laney, is the new webkit a requirement for q?
<Laney> we can't really stay on a dev release
<Laney> https://bugs.webkit.org/show_bug.cgi?id=94435 if that gets fixed we'll be ok
<ubottu> bugs.webkit.org bug 94435 in WebKit Gtk "[GTK] Split WebCore/platform into a separate library" [Normal,Reopened]
<diwic> doko, ok, bug 1056193, debdiff in comment 4, diff.gz/.dsc in 5 and 6
<ubottu> Launchpad bug 1056193 in libffado (Ubuntu) "FTBFS on quantal (undefined reference to pthread_create)" [Undecided,New] https://launchpad.net/bugs/1056193
<cjwatson> mvo: Do you know whether there's a sensible way in python-apt to reset the entirety of apt_pkg.config to what you'd get from apt_pkg.init_config()?
<cjwatson> I'm trying to make sure tests I'm writing are correctly isolated, and would like to avoid having to use a subprocess if possible.
<cjwatson> Taking a copy of the whole apt_pkg.config object doesn't work, presumably because the actual configuration lives in libapt_pkg itself; apt_pkg.init_config() uses CndSet under the covers so ignores anything already set; and there's no obvious "clear everything" method
<cjwatson> I feel I must be missing something
<mvo> cjwatson: there is none right now, but that should be (re)added really, I'm in a meeting right now, but I'm happy to talk about it in a bit
<cjwatson> OK.  These are Launchpad tests so they have to run on lucid (at least at the moment), so I'll have to come up with a workaround that doesn't involve changing {python-,}apt.  Thanks.
<cjwatson> Maybe apt_pkg.config.clear("APT"); apt_pkg.config.clear("Dir"); apt_pkg.init_config() would be sufficient in practice
<cjwatson> A nice interface might involve making apt_pkg.config.clear() work ...
<mvo> cjwatson: yeah, I think that is the key, adding libapt clear() and exposing that to python-apt
<mvo> cjwatson: let me try to build something for you, will be a bit slow due to the call but
<mpt> ev, pretty good. :-) The values on the axis need tick marks, and the dots should subdivide them sensibly. 7 days for X is good, but 0.00333 for Y is a bit weird.
<mvo> cjwatson: does http://paste.ubuntu.com/1226696/ look reasonable?
<ev> mpt: yes - I'm working on lining them up, but I wanted to make sure the dot pattern worked as an idea first
<mpt> ok
<ev> might work backwards and figure out what the tick interval should be to get the same spacing between the dots on the x and y axis
<seb128> ev, did you figure out why the nautilus issue is not showing up on e.u.c?
<ev> still working onit
<ev> on it
<seb128> ok
<cjwatson> mvo: oh, yeah, duh, that would work wouldn't it
<cjwatson> Slightly inclined to take a copy of .keys() first to defend against problems with modifying something while iterating over it
<mvo> cjwatson: yeah, good idea, it seems to be ok, but +1 for safety
 * cjwatson sticks that in tearDown() then, thanks a lot
<doko> Sweetsha1k, seb128: libreoffice b-d's on libvigraimpex-dev, however there is no libreoffice binary depending on the library. what's the reason for this b-d? it's the last user of vigra in main, would like to demote it
<Sweetsha1k> doko: vigra is mostly a header-only lib, so we are using the headers only (like most of e.g. boost)
<Sweetsha1k> doko: thus build time only, nothing needed at runtime.
<doko> Sweetsha1k, which cannot be avoided?
<Sweetsha1k> doko: As you say its the only user left in main, I can use the interal LibreOffice copy of vigra -- shouldnt be much of an change. Its likely different for debian because they have no main/universe split and thus have more users for vigra anyway.
<bdmurray> ev: could you look comment on bug 1039220 again?  I think we should not send bugs with an unreportable reason to the crash database at this point in time.
<ubottu> Launchpad bug 1039220 in apport (Ubuntu Quantal) "don't report crashes for programs that don't match the file on disk (like for kernel crashes)" [Medium,In progress] https://launchpad.net/bugs/1039220
<ev> bdmurray: yeah, pitti asked me this morning
<ev> it's on the list :)
<bdmurray> ev: ah, okay then!
<mitya57> didrocks/Mirv: will there be one more libunity upload before the release?
<Mirv> mitya57: yes, and the changes should be gotten in this week
<mitya57> Mirv: ah thanks. So I want you to merge lp:~mitya57/ubuntu/quantal/libunity/lp1055019 now :)
<needhelp1> Hello
<needhelp1> I wanted to share the link to the Ubuntu Beta Users Survey, http://nathanheafner.com/home/2012/09/11/ubuntu-beta-users-survey/   . This survey ends tomorrow.
<sladen> needhelp1: were you the person I helped before?
<needhelp1> sladen: im not sure
<sladen> needhelp1: on 12 September 2012 I spent a large amount of time discussing with you
<needhelp1> nice to talk again
<needhelp1> sladen: you been doing ok?
<sladen> needhelp1: about how to improve the chance of getting survey data;  by eg. making questions such 'sex' optional, and moving them to the end;  and working with  OMG!Ubuntu, rather than trying to find users on a developer channel
<needhelp1> sladen: yeah, thanks. I have had a lot of success with the survey.
<sladen> needhelp1: IIRC, you were going to make the questions optional, and get in touch with OMG!Ubuntu by email
<sladen> needhelp1: did you actually do either of these things?
<Mirv> mitya57: please do a merge request so it shows here https://code.launchpad.net/~unity-team/libunity/trunk/+activereviews :) then we should hunt for someone to review it
<Mirv> merge proposal, that is
<needhelp1> yeah, i was asked by some ubuntu groups to leave the sex question as required
<needhelp1> the stats for the sex question are in line with other ubuntu surveys , and a large effort was made to ensure equal access
<mitya57> Mirv: that affects only packaging, so I've proposed a merge to lp:ubuntu/libunity
<mitya57> https://code.launchpad.net/~mitya57/ubuntu/quantal/libunity/lp1055019/+merge/125881
<mitya57> (I thought the right branch should be lp:~ubuntu-desktop/libunity/ubuntu, but that one seems quite outdated...)
<Mirv> mitya57: ah, right, I didn't check it since I'm in a free software evening event atm. that's indeed the correct place.
<sladen> needhelp1: who?
<bdmurray> doko: could you look at bug 938869 again?  there are some new duplicates of it coming in in bug 1045726.
<ubottu> Launchpad bug 938869 in python3.2 (Ubuntu) "lsb_release crashed with SIGABRT in Py_FatalError()" [High,Triaged] https://launchpad.net/bugs/938869
<ubottu> Launchpad bug 1045726 in lsb (Ubuntu) "lsb_release crashed with SIGABRT in Py_FatalError()" [Medium,Confirmed] https://launchpad.net/bugs/1045726
<doko> bdmurray, the last time I tried, I couldn't reproduce it here. I'm sure I left a comment in a duplicate issue, or closed another one
<bdmurray> doko: is there some additional information we need?
<doko> bdmurray, ahh, see my comment in #12
<user82> hi. can i report a bug via launchpad webinterface?
<user82> or does this question go to #ubuntu-bugs?
<ogra_> you shouldnt, but you can indeed
<ogra_> better use the ubuntu-bug tool
<user82> okay thanks. it is totally simple i am 100% sure no detailed report is needed
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: sconklin_, xnox
<doko> getting nearer to the ocaml ftbfs
<Laney> tkamppeter: your hplip diff is a bit crazy, what happened there?
<Laney> https://launchpadlibrarian.net/117287697/hplip_3.12.6-3ubuntu1_3.12.6-3ubuntu2.diff.gz
<bryceh> could someone accept the two nvidia-* packages in NEW?  https://launchpad.net/ubuntu/precise/+queue
<infinity> bryceh: I'll look at them laterish.
<bryceh> infinity, thanks
<ev> pitti, bdmurray: replied to the merge proposal
<ev> sorry that took so long
<ev> was caught up in tasks I started before I went on holiday and wanted to finish them before they completely left my brain
<Laney> tkamppeter: I'll reject it. There's an autogenerated debian-changes patch that you almost certainly don't want.
<doko> bryceh, didrocks: is libtxc-dxtn-s2tc-bin needed in main too? if yes, please seed it
<ev> seb128: still investigating, but it will have to go into tomorrow as I'm nearly done for the day. Just wanted to let you know that I haven't forgotten :)
<seb128> ev, ok, thanks ;-)
<seb128> ev, have a good evening!
<ev> thanks! you too
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: sconklin_
<bryceh> doko, I have a Recommends on it from mesa, do I also need to include it in seeds as well?
<cjwatson> No
<doko> hmm, still shows up in component mismatches
<cjwatson> Assuming that the binary package with the Recommends is itself either directly seeded or included by way of transitive Depends/Recommends
<bryceh> doko, the Recommends has been in for several days, so if you're still seeing it in component mismatches something is wrong
<cjwatson> Which binary has the Recommends?
<bryceh> libgl1-mesa-glx
<cjwatson> No, that Recommends: libtxc-dxtn-s2tc0
<cjwatson> At least in my apt cache
<bryceh> doko, oh rats sorry I didn't actually read
<bryceh> no, libtxc-dxtn-s2tc-bin is just some utilities, we don't care about that
<doko> ok, demoting
<ahasenack> SpamapS: hi, just a ping to say that I have updated my application at https://wiki.ubuntu.com/AndreasHasenack/LandscapeClientPerPackageUploadApplication, it probably has some things that weren't there when you endorsed it first
<SpamapS> ahasenack: added some of your dark seedy past? ;)
<doko> Daviey, I promoted the python-tornado binaries as well
<ahasenack> SpamapS: ;)
<doko> infinity, you did look at mksh in main this cycle, please could you have a look at the ftbfs?
<infinity> doko: Yeahp, can do.
<doko> hmm, ruby1.9.1 builds locally here. trying another buildd
<Laney> doko: https://launchpadlibrarian.net/117310167/buildlog_ubuntu-quantal-amd64.webkit_1.9.91-0ubuntu1~build1_FAILEDTOBUILD.txt.gz
<doko> bah ... will try again with a fresh chroot later
 * doko curses gophers
<doko> zul, Daviey: having a look at the nova and python-babel dependency
<highvoltage> in the old days, people used to gopher curses.
<doko> in the upstream ChangeLog I find: Adds Distutils.Extra support, removes Babel support, which is half-baked at best
<doko> but: $ grep Babel nova.egg-info/*
<doko> nova.egg-info/requires.txt:Babel>=0.9.6
<doko> and dh_python2 adds this to the dependencies
<doko> so to remove this, add Babel to debian/pydist-overrides
<doko> are you ok with this change?
<zul> doko:  which i did this morning
<zul> in rc2 which is sitting in pending
<doko> ahh, ok
<tkamppeter> Laney, I don't knowm, I will try to do a clean rebuild.
<tkamppeter> Laney, the problem is the build system, the original tarball seems to contain machine-generated build system files which get remade by "make clean", so I need to backup the build system to restore in the end of "make clean".
<tkamppeter> popd
<doko> the binutils fix did allow the ocaml build to succeed, and ruby given back on another buildd builds fine as well. time to finish for today ...
<tkamppeter> Laney, still around
<tkamppeter> Laney, still around?
<Laney> tkamppeter: kind of, not to review/accept though
<tkamppeter> Laney, I have some problem with HPLIP, I do not succeed to keep the build system files conserved.
<tkamppeter> Laney, I save them in the "configure" rule, right after "dh_testdir" and restore them in the "clean" rule, AFTER dh_clean.
<Laney> what do you mean save and restore?
<Laney> are you using dh_autoreconf?
<tkamppeter> Laney, the problem is that only running the "clean" rule (which runs the "configure" rule as dependency) the build system files get changed and so the change gets recorded as "debian/patches/debian-changes" in the source file.
<kees> anyone around that knows efi booting? I'm trying to debug why my system won't... :P I can't figure out if I'm even loading the grub .efi file or not
<tkamppeter> Laney, yes, I use "dh_autoreconf debian/autogen.sh" in the "configure" rule.
<Laney> clean runs configure?
<Laney> that sounds less than ideal
<tkamppeter> Laney, I do not know why, the Debian maintainer must have added that. I will try to remove it.
<Laney> tkamppeter: OK. Let's revisit it tomorrow if you want
<infinity> pitti: This pkgbinarymangler diff looks curious.
<tkamppeter> Laney, that's it, the "configure" dependency was wrong, I have removed it and now all works well. Thanks.
<Laney> tkamppeter: ah, nice. I wonder why it was there. How curious.
<tkamppeter> Laney, fixed package uploaded.
<Laney> tkamppeter: if you want to close bugs, you need to upload with -v
<tkamppeter> Laney, perhaps the debian/patches/debian-changes file was already there for longer time only that no one has taken note of it. Especially all these changes get overwritten on each package build, so that they do not break the software provided by the package.
<Laney> alternatively, since they were never in the archive, you don't need to use a new version number
<tkamppeter> Laney, now it is already uploaded, I will close the one bug report manually.
<Laney> up to you. It's no problem to reupload multiple copies to the queue.
<tkamppeter> Laney, does this mean that as the last upload is not yet approved I can do another upload with a lower version number?
<doko> Laney, where was this fixed make version?
<Laney> doko: https://launchpad.net/~laney/+archive/webkit/+packages
<tkamppeter> Laney, now I have uploaded a new -3ubuntu2 with all the changes. So you can reject -3ubuntu4 and accept -3ubuntu2.
<Laney> ack
<doko> bdmurray, could you find out about the env vars which are set?
<Laney>  7 files changed, 18 insertions(+), 11135 deletions(-)
<Laney> tkamppeter: nice!
<bdmurray> doko: what do you mean exactly?
<doko> bdmurray, so what do you suggest to do? dear vmware, please fix your broken installer?
<doko> bdmurray, I assume they ship a python2.x environment, and then calling everything else with this environment
<bdmurray> doko: no, if its vmware's fault that's fine. I'd just like to be able to have that information in the bug and write a bug pattern for the crash if possible.  Also modifying apport so we know if python was modified seems like a good idea too.
<doko> ok, so the bug pattern would be to look for something vmware'ish in PYTHONHOME and PYTHONPATH. I assume they only see this on Ubuntu, because other distros ship a lsb_release implemenation not written in python
<bdmurray> and it doesn't look like apport gathers either of those
<bkerensa> sconklin_: your PP today?
<sconklin_> yes, what's up?
<sconklin_> I'm only looking at kernel issues, fwiw
<doko> bdmurray, even ProcMaps.txt doesn't show any references, because the error happens that early
<smoser> pretty sure i just time traveled.
<smoser> my clock now says 4 hours in the future
<smoser> hm.. no, it just lost my timezone.
<smoser> strange
<Daviey> smoser: no, you fell asleep.. check for the key imprints on your face
<bkerensa> sconklin_: oh nvm then :) just have a line of MP's waiting for review
<sconklin_> bkerensa: as luck would have it, both PPs who were assigned today were kernel people
<bkerensa> peh
<bkerensa> :D
<sconklin_> I'm almost EOD anyway
<doko> Laney, so I was bad with testing. webkit ar failure still reproducible. maybe you could work around it by configureing with --disable-static?
<Laney> maybe
<cjwatson> kees: with GRUB 2.00, you can 'echo $grub_platform' to see which platform you're running (at least assuming GRUB has got out of rescue mode)
<Sweetshark> doko: so, do you want that vigra drop still? If so, I would assume so for quantal+1, which is a bit of: could you drop a minibug on me for that then?
<doko> Sweetshark, no, your are free to fix the ftbfs of libvigraimpex in q, as the only user of this package ;-P
<Sweetshark> doko: hah!
<Sweetshark> jasoncwarner_: ping?
<doko> barry, ^^^ you did touch libvigraimpex before, maybe give it a try?
<barry> doko: tbh, i've never actually used libvigraimpex
<doko> ok
<kees> cjwatson: after more debugging and running the efi shell from a usb stick, it seems like my ami firmware is refusing to notice my efisys partition, and I don't understand why.
<kees> cjwatson: the HDD shows up under "devices" in the efi shell, but it doesn't see any partitions listed under "map", which only shows the usb stick.
<kees> oddly, I created the partitions with the same tools: gdisk and mkfs.vfat
<Laney> doko: --disable-static is the default
<Laney> and we don't enable it
<bryceh> infinity, chance you could peek at the nvidia NEW?  I'm hoping it should be an easy wave-thru for you since we got TB approval on it (http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html)
<infinity> bryceh: It's on my TODO today, don't worry.
<TheLordOfTime> where can i report a possible issue with the retracer for a crash bug on a Quantal system?
<TheLordOfTime> or am i asking in the wrong location
<SpamapS> TheLordOfTime: here is probably a good place. Whats up?
<TheLordOfTime> SpamapS, https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1056419  <-- should the retracer be expecting proposed repo packages to be used for testing?
<ubottu> Launchpad bug 1056419 in pidgin (Ubuntu) "pidgin crashed with SIGSEGV in g_type_check_instance_cast()" [Undecided,Invalid]
<SpamapS> TheLordOfTime: its entirely possible the retracer does not know how to deal with proposed.
<TheLordOfTime> SpamapS, that might be something to look into, unless i'm misreading the retracer's whining
<TheLordOfTime> libgtk2.0-0 version 2.24.13-0ubuntu1 required, but 2.24.13-0ubuntu2 is available  <-- that one caught my attention since -0ubuntu2 is only in proposed
<TheLordOfTime> and unless you're an idiot, or a hardcore tester of everything, you don't run stuff from proposed very often.
<TheLordOfTime> if at all.
 * micahg would think it's more likely that the ddebs are removed before stuff in moved to the release pocket
<cjwatson> find pitti when he's around and ask him; not sure anyone else really knows how the ddeb publisher works
<cjwatson> but I could well imagine that it fails to handle the -proposed workflow somehow
<TheLordOfTime> cjwatson, that was my thought
<Laney> I've definitely had apport refuse to let me file a bug because of -proposed
<TheLordOfTime> cjwatson, the main reason i saw that is it  was a quantal bug, and it was invalid'd pretty much when it got on the feed the announce bot in #ubuntu-bugs-announce posted it, and I dont usually see that.  'Tis why I was curious, then i saw that
<TheLordOfTime> cjwatson, if the retracer's processing -proposed as if it is an approved, uploaded package to the standard repos, then the retracer needs an overhaul
<TheLordOfTime> since that's a possibility of legitimate crash bugs being invalid'd because of -proposed
<micahg> well, what we need is ddeb support in soyuz
<cjwatson> we know the retracer needs an overhaul; in this case though it should be a relatively small fix
<TheLordOfTime> cjwatson, then a targetted code stabbing session should work :P  but my original point stands: at least with $currentDevRelease it can result in legit crash bugs being marked invalid and thereby being completely ignored by devs, which can definitely lead to reported-but-not-fixed issues at release
<Laney> Nobody is disagreeing with you
<TheLordOfTime> :)
<TheLordOfTime> Laney, indeed.  i'm just reiterating my point :)
<TheLordOfTime> as a triager, i don't like broken stuff, esp. if the retracer is doing othe breaking :p
 * TheLordOfTime returns to lurkmode
#ubuntu-devel 2012-09-26
<pitti> Good morning
<pitti> infinity: pkgbinarymangler> yeah, catching up with a recent debhelper change
<pitti> TheLordOfTime, SpamapS: the apport retracer does not use -proposed for quantal; we do not expect anyone to run quantal-proposed
<lifeless> ev: https://bugs.launchpad.net/daisy/+bug/1052954/comments/2 - my thoughts
<ubottu> Launchpad bug 1052954 in Daisy "top-k for arbitrary ranges is complex" [Undecided,New]
<pitti> TheLordOfTime: it cannot currently handle multiple different versions within the same distro
<pitti> infinity: do you know whether our arm builders changed in any way in the last couple of weeks? running stuff in parallel, or running several builds at once, or anything which would make them have a higher load?
<pitti> infinity: I'm still stunned at how many timing tests in glib's test suite suddenly fail (I'm disabling most of them now on arm, it's hopeless)
<infinity> pitti: Well, they all got upgraded to precise and, perhaps that's causing issues, but it shouldn't be...
<pitti> infinity: ah, so at least there was _some_ change, and it's not totally inexplicable
 * pitti now watches the umpteen version build
<pitti> yesterday evening's crashed with an internal compiler error, but that seemed to be spurious
<pitti> and this morning's managed to fail yet another timing test which hasn't before; I wish they could all fail at the same time instead of serially :)
<infinity> pitti: It could be more related to differing aggressiveness of swappiness or something mostly unrelated.  Machines with low RAM and swap over USB are never going to play nicely when you're expecting to have 100% CPU to yourself.
<pitti> right, but they weren't that unstable until a few weeks or so ago, and Debian's work rather fine as well; that's what made me wonder what changed
<pitti> anyway, once this manages to build two or three times in a row, it should be fine again
<pitti> it's enough to test the timing properties on the other arches
<infinity> pitti: With any luck, we can back most/all of this mess out when we have "real server hardware".
<infinity> pitti: Debian's buildds may be in better shape for two reasons: their armel buildds all have 2.5G of RAM, and their armhf ones, while only have 1G (and being slower in every other respect than the Pandas) are swapping over SATA, so don't waste a ton of CPU time on that.
<pitti> ah, thanks; so yes, swapping and random I/O could indeed explain the ridiculously high times that some tests need
<YokoZar> Will my upload of opus 1.0.1 turn heads due to its timing?  (opus is a new package in quantal and our current synced version is prerelease.  1.0.1 has been standardized as the reference implementation by RFC)
<RAOF> YokoZar: It's unseeded and is bugfix?
<YokoZar> RAOF: Yeah pretty much.
<YokoZar> I think it's unseeded at least, it would be surprising if it were
<RAOF> Should be fine
<SpamapS> opus's binaries are not seeded.
<SpamapS> YokoZar: I concur with RAOF. sync/upload away
<YokoZar> SpamapS: We're jumping ahead of Debian actually.  I'm sending patches though :D
<mlankhorst> heya
<RAOF> Yo!
<dholbach> good morning
<doko> Laney, see http://sourceware.org/bugzilla/show_bug.cgi?id=14625
<ubottu> sourceware.org bug 14625 in binutils "[2.23/2.24 regression] ar: File truncated" [Normal,Resolved: invalid]
<doko> Laney, seb128: see http://sourceware.org/bugzilla/show_bug.cgi?id=14625 looks like the webkit developers need to find another solution for their mega archive, maybe splitting it into smaller ones
<ubottu> sourceware.org bug 14625 in binutils "[2.23/2.24 regression] ar: File truncated" [Normal,Resolved: invalid]
<Laney> doko: indeed, https://bugs.webkit.org/show_bug.cgi?id=94435
<ubottu> bugs.webkit.org bug 94435 in WebKit Gtk "[GTK] Split WebCore/platform into a separate library" [Normal,Reopened]
<doko> and if it did work before, it was buggy ...
<Laney> :-)
<doko> Laney, and likely you won't need the make patch either ...
<Laney> yes, indeed, same cause
<doko> for bonus points, please backport to qt4-x11, so that we can get the thing built on arm too ...
<Laney> when there's a working patch
<doko> ahh, there's not?
<Laney> look at the linked bug, the fix they added broke some other parts of the build so it was reverted
<doko> looks like implicit template instantiations ...
<doko> Laney, maybe http://gcc.gnu.org/PR54145
<toabctl> is it possible to generate input events from the command line? but without the tools from the package xautomation. I need this for an embedded system without X. I tried "echo 60 > /dev/input/event0" but that does not work
<doko> jodh, please could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843612 ?
<jodh> doko: looking...
<doko> pitti, is ubuntu-drivers-common supposed to ftbfs on arm*?
<pitti> doko: no, certainly not
<doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843190
<pitti> https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.69 looks fine, though
<pitti> doko: ah, race condition again
<pitti> utterly slow arm builders FTW
<jodh> doko: looks like the failing test has hit the issue seen in the follow-on test: occasionally, the test fails to see the trailing '\n' or '\r', but only if the process is forcibly killed. Its either a very obscure Upstart logger bug or an even more obscure pty/tty layer kernel bug. In summary - I suspect re-running that build will pass, but ping me if this is repeatable as it might allow us to hone in on the root cause.
<doko> jodh, given back
<joeljacobson> when will postgresql 9.1.6 be released in -updates for ubuntu 12.04?
<ev> lifeless: thank you!
<obounaim> I need sponsoring here, can anybody review my branch?
<joeljacobson> when are packages moved from -proposed to -updates, does it occur on certain days?
<diwic> joeljacobson, I don't think so - it rather happens when there is positive verification on the relevant bug(s).
<joeljacobson> diwic: ok, thanks, so I just have to wait
<cjwatson> joeljacobson: is there a particular package you're interested in?
<joeljacobson> cjwatson: postgresql 9.1.6
<joeljacobson> maintained my Martin Pitt, https://launchpad.net/~pitti
<joeljacobson> it's in -proposed now
<cjwatson> joeljacobson: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that as still being much too recent (1 day)
<geser> joeljacobson: you can also monitor bug #1055944
<ubottu> Launchpad bug 1055944 in postgresql-8.4 (Ubuntu Natty) "New bug fix releases: 9.1.6, 8.4.14, 8.3.21" [Undecided,In progress] https://launchpad.net/bugs/1055944
<cjwatson> joeljacobson: the usual rule is that updates age for 7 days in -proposed to allow time for people to point out regressions
<cjwatson> occasionally we waive that, but the circumstances have to be abnormal
<diwic> 7 days, didn't know that, thanks
<doko> stgraber, https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3822117
<joeljacobson> ok, sounds like a reasonable time to wait, noone wanna be the first to upgrade :)
<doko> jodh, rebuild did succeed
<ev> seb128: it seems like it's a failed retrace, but I can't conclusively narrow it down to one in particular. I'm going to give more attention to https://bugs.launchpad.net/daisy/+bug/1044418 after (or maybe during) we sort out https://bugs.launchpad.net/daisy/+bug/1052954. There's a lot to consider though, so it wont be something that gets done this week. I will, however, keep you posted on the progress.
<ubottu> Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New]
<ubottu> Launchpad bug 1052954 in Daisy "top-k for arbitrary ranges is complex" [Undecided,New]
<seb128> ev, ok, thanks
<ev> sure thing
<seb128> ev, do you know why the launchpad retracers work on that one but not the e.u.c ones?
<seb128> ev, they should have access to the same binaries,
<ev> yes, but the launchpad retracers deal a bit better with transient failure at the moment. I need to balance failing hard like the launchpad retracers do when they hit a problem in apport-retrace against webops' pagers going off
<ev> I do have some improvements here that we had to back out about two weeks ago
<ev> I'll revisit them this week
<seb128> ok
<seb128> ev, I'm just surprised because that bug got successfull retracing on launchpad for a timeframe higher than a week
<seb128> so it shouldn't be a "transient" thing
<seb128> we are in a somewhat established state
<seb128> ev, do we have an estimation of what % of reports fail retracing atm?
<ev> seb128: once we have a successful or failed retrace on daisy.ubuntu.com, we don't accept any more core dumps and don't do any more retracing on that particular signature
<seb128> oh, ok, I see
<seb128> that's unfortunate
<ev> seb128: I can run a query for the percentage, sure
<ev> seb128: yeah, it prevents us from continually asking for a core dump that will fail to retrace
<ev> like when the ddebs needed are out of date
<seb128> right, ideally we would have a line on e.u.c about the issue and the associated count at least
<seb128> I'm concerned that we might miss quite a lot during unstable cycle
<seb128> especially due to the dbgsym server nature
<seb128> it updates every few hours
<ev> we do
<seb128> so the first retrace is likely to fail (and often does) because the dbgsym are not there yet
<ev> any problem that's failed to retrace shows up on the main page (if it has a high enough count)
<seb128> ok
<ev> their identifiers start with "failed:"
<seb128> I'm surprised that nautilus bug doesn't show there then
<ev> way way way back when the website was first launched, we hid them
<seb128> it got over 60 dups on the launchpad side
<ev> but I was equally concerned about brushing the problem under the carpet
<seb128> which by itself should be enough to make it one the top nautilus list of the month
<seb128> one->on
<ev> right, which is why I think it might be this:
<ev> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B424%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2
<ev> B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec
<ev> or this:
<ev> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B416%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2
<ev> B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec
<ev> heh, need to come up with shorter URLs
<seb128> ;-)
<seb128> ev, I doubt it's any of those
<ev> oh?
<seb128> it should have dbusmenu-gtk4.so in the top of the stacktrace
<ev> what should I be looking for?
<ev> ah, okay
<ev> I'll see if I can dig one up that matches
<ev> mpt: when you have a moment
<seb128> sorry
<seb128>  g_type_check_instance_cast () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
<seb128>  ?? () from /usr/lib/x86_64-linux-gnu/libdbusmenu-gtk3.so.4
<seb128>  g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
<ev> unrelated :)
<seb128> ev, ^ that's the top of the libs
<ev> seb128: cheers
<infinity> pitti: glib on ARM really seems to dislike you. :P
 * pitti pulls his hair out
 * pitti retries and prepares another upload
<infinity> pitti: Check both logs, they failed different tests. :/
<pitti> yes, I saw
<joeljacobson> cjwatson: postgresql 9.1.6 is a quite serious bug fix, so perhaps the 7 days could be somewhat reduced, due to the urgency of the update?
<infinity> pitti: Is it all really just timing stuff?  I didn't read mainloop/recursive_child_sources, but that could be a genuine bug?
<pitti> it succeeded all the time since we had test failures FTBFS, and it doesn't happen every time either
<infinity> Maybe I should start writing nice letters to everyone who makes ARM kit with 4G of RAM and begin begging.
<infinity> Getting so very sick of all of this swap death.
<seb128> glib 4 - 0 pitti
<seb128> go pitti go ;-)
<pitti> 4? it's 7 now!
<seb128> crazy...
<pitti> maybe until we have proper arm builders we should make the tests non-fatal again on arm, and keep them "on" on debian only
<Laney> how come Debian's are better?
<ogra_> infinity, we just need a properl beowulf hack to the kernel and can then use a battery of USB hubs to build clusters with these http://store.cstick.com/business/cotton-candy.html ;)
<doko> infinity, it was better before ... and the not so nice thing is that the local builds do work
<infinity> Laney: Debian's armel builders are ancient Marvell armv5 boards with 2.5G of RAM, and Debian's armhf buildds suffer similar swap pain, but swap to SATA, which might be mildly less CPU load.
<doko> Sweetshark, packaged libvigraimpex 1.8.0 in doko/toolchain. please could you test build lo against it?
<infinity> doko: Yeah, it's also possible that the precise kernels swap more aggressively or something, I haven't had the time to throw much science at it yet.
<doko> do you know how to throw science?
 * doko ducks
<infinity> doko: Sadly, we need the precise kernels for OTHER reasons, but if they really have regressed from natty in this case, we should be able to sort it out with some fiddling.
<cjwatson> joeljacobson: most SRUs are serious for one reason or another, but regressions are even worse
<cjwatson> the test is "emergency" rather than "serious", really
<cjwatson> pitti: ^- what do you think?
<joeljacobson> well, it's not emergency, they advise "REINDEX at a convenient time"
<joeljacobson> but feels a bit shaky to run a production database with potential index corruption, I would really like to upgrade yesterday
<pitti> cjwatson: I do think that we shouldn't wait the full 7 days for this, but 1 day seems too rushed for me
<joeljacobson> no new features in the minor postgres releases, so regressions shouldn't be a problem
<infinity> I agree that it's urgent enough to waive the 7d wait, from my examination of it, but I do want to know it's well-tested first.
<pitti> while regressions are rare, they did happen
<amitk> infinity: fiddling with /proc/sys/vm/swappiness should allow you to confirm if it the swapping
<pitti> I have quite a lot of people who use my PPA, and I'm watching the upstream bug list
<cjwatson> joeljacobson: we're a little more paranoid than default since at scale you get regressions from all kinds of things; we've had regressions in other packages from no-change rebuilds before
<cjwatson> hence the testing process
<infinity> amitk: Indeed, and when I find some round tuits, I'll try to do some fiddling.  Sadly, reproducing the issues the buildds see isn't a particularly exact science to start with.
<joeljacobson> I would say 3 days is accetpable, but 7 days will cause people like me to start considering compiling from source or adding -proposed to the apt sources
<cjwatson> I'm fine to defer to pitti/infinity on waiving it down a bit, but yeah, 1 day is too quick
<doko> joeljacobson, that would be one more tester ;)
<infinity> joeljacobson: If you want/need it right now, please *do* install it from proposed and followup to the bug to let us know if it's working well (or not!), which helps us decide if it's ready to release to the world at large.
<joeljacobson> doko: perhaps someone else who doesn't process millions of physical bank transactions can test first? :)
<cjwatson> grr, d-i lowmem mode gives a black screen on amd64.  that's unhelpful
<cjwatson> (in kvm)
<infinity> joeljacobson: I'm going to assume that if you're in such an environment, you also perhaps have mirrors of production data that you can test with before blindly upgrading production machines? ;)
<joeljacobson> infinity: the bug in 9.1.5 caused the hot-standby machines to fail swallowing the WAL-files, so no, I don't, well actually I do now since I've made a new pg_basebackup, and yes, of course I'll upgrade the slave first, that's standard procedure
<joeljacobson> infinity: OK, I'll upgrade from -proposed, sounds good. How can I upgrade just postgresql from proposed? Adding it to apt sources will upgrade a lot of other stuff, won't it?
<diwic> joeljacobson, out of curiousity, what company are you working for?
<joeljacobson> diwic: Trustly Group AB in Sweden, we handle all bank payments for almost all gambling companies in the world
<infinity> joeljacobson: You can either enable proposed, apt-get update, and then selectively "apt-get install foo libfoo foo-common libfoo-bin etc" or just grab the appropriate debs from https://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.6-0ubuntu12.04/+build/3852858 and "dpkg -i foo.deb libfoo.deb etc"
<diwic> joeljacobson, what are the current odds for your upgrade failing, I wanna bet ;-)
<pitti> joeljacobson: I already ran the upstream and the p-common test suites against it, which have a fairly good coverage
<joeljacobson> diwic: I'll give you 1000 times the money, but I would prefer to bet myself instead of laying a bet, to hedge against the consequences if something would go wrong
<joeljacobson> pitti: ok, thanks, that's good to hear
<diwic> joeljacobson, just kidding. Lycka till :-)
<joeljacobson> diwic: hahah, are you Swedish?
<doko> Sweetshark, see bug #1056759
<ubottu> Launchpad bug 1056759 in libvigraimpex (Ubuntu Quantal) "libvigraimpex ftbfs from source (core dump running the tests), 1.8 prepared" [High,Confirmed] https://launchpad.net/bugs/1056759
<Andy80> hi
<Andy80> I was reading this http://benjaminkerensa.com/2012/09/25/technical-diagram-of-how-unity-shopping-lens-likely-works - do you confirm me that everything I enter in my dash is trasmitted to productsearch.ubuntu.com O_o ?!
<cjwatson> #ubuntu-unity more likely to have accurate details
<Andy80> cjwatson: ok thanks, I will ask there
<cjwatson> barry,doko: heh, I just noticed that python (i.e. 2) is explicitly listed in the minimal seed
<cjwatson> do we want that to be python3 now?
<doko> sure, however I think we will still install python for a minimal/buildd install?
<joeljacobson> apt-get install libpq5 postgresql-9.1 postgresql-client-9.1 postgresql-contrib-9.1 postgresql-plperl-9.1
<joeljacobson> .... so far so good ... holding my thumbs :)
<Laney> haha, is that the Swedish expression?
<Laney> here we'd say "crossing my fingers" :-)
<hrw> Laney: it sounds like direct translation of Polish phrase
<hrw> (holding my thumbs one)
<Laney> funny
<cjwatson> doko: Well, we do right now, but should we?  Anything that needs it to build should build-depend on it, surely
<cjwatson> Likewise I wonder if we should seed python3-minimal in required, not python-minimal
<doko> the only thing I can think of are python scripts, without having a python dependency, which did escape dh_python2, or when dh_python2 wasn't used
<doko> but probably uncommon
<cjwatson> This would shrink debootstrap output by 9%, so not to be sneezed at
<cjwatson> I dunno, if you think it's too risky we could do it first thing in R instead
<cjwatson> I just hadn't read germinate output in a while and it stood out immediately
<doko> cjwatson, no, I think it's fine. debian needs it as a dep in any case, so for the majority of packages it's no issue
<doko> do we have any git experts?
<cjwatson> doko: I think I'll do it after b2 then
<quadrispro> hi all
<mvo> xnox: do you mind if I have a look at #1015567?
<xnox> bug 1015567
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [Critical,Triaged] https://launchpad.net/bugs/1015567
<xnox> mvo: yes please. I had some pokes at it, but not much.
<xnox> mvo: with recent/current dpkg I couldn't reproduce the state to trigger the bug, unless I did rm in dpkg/info.
<mvo> xnox: it just happened to me on upgrade on of my boxes from precise->quanal and the system is in the broken state
<xnox> mvo: nice.
<mvo> xnox: and it seems like the only way to get out of this is to manually vi /var/lib/dpkg/status :)
<mvo> xnox: so thats a good excuse for me to look at it a bit
<Sweetshark> doko: thanks for the bug, will switch to internal for the next upload.
<xnox> mvo: the infinity's idea is to make dpkg treat RC packages as multi-arched if needed. E.g. equivalent of adding Multi-arch: same headers to status.
<doko> Sweetshark, always for the least effort, not the best solution?
<xnox> mvo: except that dpkg's parsing and enumerating status is very interesting for an uninitiated developer like me.
<mvo> xnox: yeah, I think that idea of infinity is a good one
<mvo> xnox: *cough* s/an uninitiated/any/ ;)
 * mvo makes more tea
<Sweetshark> doko: gimme a team and I will start caring for vanities.
<xnox> mvo: i was not sure you can safely do such substitution, without locking-> read/rewrite/fix status -> re-read the status -> continue. Since the counts of multiarch/non-multiarch packages was order depended in the status file as far as I could read it.
<mvo> xnox: right, I need to look at it a bit, I have no real idea just yet
<doko> Daviey, zul: is feedparser a server package?
<zul> Daviey:  i believe so
<zul> python-feedparser?
<doko> yes
<zul> i believe so
<zul> why?
<doko> test failures, see the test rebuild
<zul> doko: cool ill have a look
<doko> same errors in 5.1.2
<TJ-> k3b on Quantal, Precise, Oneiric; the k3b i386 package is depending on libc6 >= 2.4 but libc6 is v2.15, so k3b cannot be installed. I've been looking at the build logs to confirm it. Am I missing something obvious here about the libc6 versions?
<geser> TJ-: yes, 15 > 4 so 2.15 > 2.4 (the . is a delimiter not a decimal point)
<cjwatson> Might be easier to post the full error messages rather than an interpretation of them
<cjwatson> And remember that apt often doesn't follow the full chain when something goes wrong and has to be helped to produce the real error
<TJ-> geser: Thanks. My brain must not have woken up yet! I totally confused myself over that :s
<TJ-> geser: I think I transliterated 2.4 to 2.40
<doko> zul: found out that the tests pass with libxml 2.9 from experimental
<zul> doko:  thats not good..ill see if i can find a fix
<stgraber> doko: hmm, yeah, I guess I'm touched-it-last on that one, though the real fix would be to kill it completely as it shouldn't be needed anymore...
<stgraber> seb128, didrocks: is it still the plan to get rid of launchpad-integration completely this cycle? I see that the only rdepends remaining is quickly-ubuntu-template
<stgraber> then we should be able to remove it from the archive completely
<seb128> stgraber, quickly was fixed yesterday
<doko> stgraber, do it!
<seb128> there is also a ftbfs fixed version in the unapproved queue
<seb128> of launchpad-integration
<stgraber> seb128: oh, cool, then I guess we can unseed it and kill it for good then
<seb128> it's in universe?
<seb128> what do you mean unseed?
<doko> zul: just rebuilt the libxml2 version in quantal. same errors, so it should be something in the upstream changes
<zul> doko: gotcha
<stgraber> seb128: seeded-in-ubuntu was telling me it was still seeded somehow, but it's just because we haven't rebuilt a dvd image in a long time, so all good to remove then
<seb128> well, the reason I kept it is appdev
<seb128> quickly was promoting it for a while
<seb128> so I don't know if we should keep the binaries available for an extra cycle
<seb128> e.g I don't know if out of the archive stuff still depends on it
<stgraber> hmm, yeah, I guess that'd be reasonable
<seb128> there is a version which fix the ftfbs in unapproved as said
<seb128> I think it doesn't cost lot to keep it in universe for quantal
<stgraber> right, let me accept the fixed version for now so doko is happy and I'll re-target bug 999413 to R
<ubottu> Launchpad bug 999413 in launchpad-integration (Ubuntu) "Remove launchpad-integration from the archive" [Medium,Triaged] https://launchpad.net/bugs/999413
<seb128> thanks
<doko> stgraber, I'm only happy when http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120922-quantal.html is empty
<seb128> there is a fixed gtk2-engines as well in unapproved
<stgraber> doko: you must be a pretty sad man then ;)
<seb128> that package is not going to get cleaned a lot until we unfreeze I guess
<seb128> I just hope people check unapproved before duplicating work
 * doko loves colored non-verbose build logs ... elinks
<doko> Riddell, ScottK: I'll leave the kubuntu ftbfs for you ...
<ScottK> doko: What happened with https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3837464 - There's no log.
<Laney> probably broke the buildd
<Laney> that seems to be the failure mode
<ScottK> Riddell or debfx: No idea how to troubleshoot that one.
<Laney> doko has been complaining about that build for some time
<ScottK> Any ideas why sudo do-release-upgrade -d says no new release found even though /etc/update-manager/release-upgrades is set to normal?
<doko> ScottK, buildd issue. please don't give back. kills the cats
<ScottK> OK.
<ScottK> What if I don't like cats?
<mvo> ScottK: no, that is unexpected, you can run "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d" to see if that outputs something useful
<ScottK> Sure.
<doko> didrocks, seb128: is there an easy work around for #warning "Including <librsvg/rsvg-cairo.h> directly is deprecated." ?
<ScottK> mvo: http://paste.ubuntu.com/1228511/
<mvo> ScottK: confusing, a 404 - is there anything between you and changelogs.ubuntu.com? like a proxy (transparent) or somesuch that might cause this?
<ScottK> No.  Let me try it in a browser
<ScottK> mvo: My fault.  I had redirected that url to a different IP address when we were doing testing and forgotten.  Sorry for the bother.
<ScottK> Works fine once that's removed.
 * ScottK shakes fist at Riddell.
<mvo> ScottK: no worries
<mvo> ScottK: happy to hear that it works now
<Riddell> ScottK: what what?
<ScottK> About the fact that I couldn't upgrade because I had changelogs.ubuntu.com redirected to your server for the precise upgrade test we did ...
<ScottK> Not really you fault ...
<Riddell> ScottK: oh I see :)
<Riddell> doko: which kubuntu ftbfs?  in the build tests?
<doko> Riddell, yes
<Riddell> doko: yeah those are on my radar
<doko> thanks
<mvo> smoser: meh, I just ran into https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/1015692 - this is more than just priority low to me :/
<ubottu> Launchpad bug 1015692 in offlineimap (Ubuntu) "offlineimap and ssl requires configuration of fingerprint" [Low,Confirmed]
<smoser> mvo...
<Laney> that's an xnox package :P
<smoser> mvo, i dont have a really good solution. as i said in that bug. its really upstream created issue.
<xnox> mvo: I was considering to make system-wide ssl certs as defautl.
<smoser> but now they're just causing failure when previously they just did not check certificates.
<smoser> so in some sense its a feature
<xnox> cause than it just works with gmail =)
<mvo> xnox: what is stopping us? that sounds like the right thing to do
<xnox> and is secure, cause if the system-wise ssl certs in /etc/ are busted.... then there are bigger problems than offlineimap.
<xnox> mvo: nothing. Just need to find time to change that default and push it: upstream, debian & ubuntu as I have commit access everywhere.
<mvo> xnox: cool
<mvo> xnox: when I find a bit of time I will give it a go too, but keep an eye on it to ensure we don't duplicate work
<xnox> mvo: ok.
<xnox> mvo: I like your dpkg patch by the way. I will run against my fake test cases that I have in pbuilder somewhere to trigger it.
<xnox> mvo: and the upload. It just seems like we will have to keep that fix..... forever.....
<mvo> xnox: cool, let me know, I got no feedback from #debian-dpkg yet
<mvo> xnox: yeah, we could make the count count single, multiple, conf, total, that would be a bit less hacky
<xnox> mvo: you wouldn't, because it doesn't effect debian at all.
<mvo> xnox: well, sometimes I still get feedbck for ubuntu only stuff because they are nice people
<smoser> hm..
<xnox> mvo: "broken multiarch was never part of debian" (tm)
<smoser> are there not net-device-up events for bridge interfaces?
<smoser> i configured a bridge in libvirt
<smoser> and i was expecting to be able to
<smoser> start on net-device-up INTERFACE=maasbr0
<smoser> but i do not have evidence that that ran
<smoser> slangasek, ^ ?
<cjwatson> xnox: while you might be right, let's not assume failure in advance :)
<slangasek> tjaalton: hi, bug #966744 is assigned to you and targeted to beta-2; despite being an old bug number, this has started becoming a huge problem for me just in the past couple of days.  Is this in progress?
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
<cjwatson> and besides, "forever" is at most until the next LTS
<cjwatson> *after the ...
<xnox> cjwatson: ok. =)
<xnox> cjwatson: as far as I understood that patch, it was changing the check to ignore rc state packages. So if there is an rc package that is not upgraded for more than one LTS, then you can still hit it.
<slangasek> smoser: there are net-device-up events for those devices on whose behalf /etc/network/if-up.d/upstart is called, which should be all of them managed either in /etc/network/interfaces or by NM
<xnox> mvo: or does that actually update status db?
<tjaalton> slangasek: yes, I'm testing crack-o-day intel drm code (requested by upstream), also trying to figure out why it fails to boot
<smoser> slangasek, ah. yeah. i koind of realized that.
<smoser> do you have a suggestion on how i can start on that network device ?
<smoser> (which is not managed by /etc/network/interfaces)
<tjaalton> slangasek: not going to get fixed for beta2, that's for sure :/
<slangasek> tjaalton: ok, thanks for the info
<slangasek> smoser: fix libvirt to emit the event for you? :)
<slangasek> smoser: or maybe it should be 'start on started libvirt-bin' or something?
<smoser> i tried that, but it seemed racy.
<slangasek> well, sounds like a bug in libvirt-bin startup
<slangasek> because it shouldn't be racy
<tjaalton> slangasek: btw, have you reviewed the acpi-support patch(es)?-)
<mvo> xnox: no, just "fixes" the counting
<slangasek> tjaalton: got about halfway into it before vacation hit... will revisit this week
<tjaalton> slangasek: ok, thanks
<smoser> slangasek, possibly. but the daemon is sstarted, just not all networks  up i think.
<mvo> xnox: this is why it would be nice to "upstream" it
<xnox> mvo: well the correct way is to actually rewrite the status db on lts upgrade and correct those. as the new dpkg will not generate inconsistent status db (well if it does it will be upstream bug as well).
<xnox> mvo: that way it would really be just a patch to carry until lts.
<xnox> mvo: I think we should apply your patch for quantal, and fix it with status db re-writing by 14.04. And then drop it after 14.04.
<mvo> xnox: sounds good to me
<smoser> slangasek, so you would think that 'started libvirt-bin' would mean that all of its 'auto' networks are up ?
<slangasek> smoser: I would think that it would mean all the setup for libvirt is done, so that other services can start using those facilities, yes
<slangasek> smoser: libvirt-bin even uses 'expect daemon', so there's no excuse not to - it's just a startup ordering question AFAICS
<smoser> do you think the comment about 'net-device-up' is valid ?
<smoser> ie, would it be reasonable for libvirt to emit those ?
<ScottK> Laney: Did you intend Bug #1054746 to be about excluding online results or excluding commercial results (title says one and the body says the other).  I'd like to make sure we're solving the right bug.
<ubottu> Launchpad bug 1054746 in Google Documents Lens "[FFe] [UIFe] No easy way to disable online results in lenses" [High,In progress] https://launchpad.net/bugs/1054746
<seb128> ScottK, the bug is about stopping sending queries to Canonical servers
<Laney> ScottK: I originally intended it to be a narrow fix for just that lens (and wrote a patch for that)
<Laney> but then it got extended to cover all queries sent to C servers
<ScottK> seb128: That's what I thought, but the U/I that's proposed talks about commercial/non-commercial.
<Laney> which I think is nicer.
<ScottK> Since there's been discussion of non-commercial online search support, I think that is not completely aligned with not doing online searches.
<Laney> it's not about online services
<Laney> you'll still have (for example) wikipedia and gwibber working
<ScottK> Is that different than what seb128 just said?
<ScottK> (or do those not go through Canonical servers?)
<didrocks> ScottK: you have the gwibber lens fetching content from tweeter
<Laney> It's not, but your response came after his.
<didrocks> ScottK: or the excellent radio lens grabbing the available radio info from an online service ;)
<ScottK> Right, but those are clearly online.
<didrocks> indeed
<ScottK> This issue, AIUI was automatically going online for searches when there was no indication that was the case.
<Laney> So the bug isn't about disabling all online results. Commercial suggestions from partners was the wording that design came up with to describe what we're turning off.
<Laney> which is intended to be the items causing concern
<Laney> I understand it's supposed to be finessed more for the next cycle
<ScottK> OK.  You might want to retitle the bug then.
<ScottK> Because that's what got me started being confused.
<Laney> there. how's that?
 * ScottK notes for the record how much more convenient conversations like this are when they happen before feature freeze.
 * ScottK looks.
<ScottK> Sure.  Thanks.
<Laney> yes, we know. We're trying to work within the constraints of our governance structure ...
<ScottK> Well, something seems to come up every cycle.
<ScottK> If someone bases their plans on "we'll get an exception", I don't think that's really working within the structure.  I understand that stuff happens, but when it's consistent, that's not what FFes are for.
<ScottK> Strictly from a technical perspective, I think it'd be better to revert the whole thing and land it with a good design early in "R", but I get that's not going to happen.
<tumbleweed> ScottK: I assume most of us agree
<Laney> ScottK: I'm saying that getting the exception wasn't at issue, given the way the feature was driven.
<ScottK> Laney: Yes.  I know.  I'm aware of how it was driven.  It's unfortunate that at this point we can't just focus on producing a quality release.
<Laney> I'm hoping that I can turn this experience and other similar but less visible ones into some useful lessons
<xnox> ScottK: ubiquity & datetime widgets send lookups to geoname-lookup.ubuntu.com
<xnox> are those a concern as well?
<ScottK> xnox: Yes.  That's completely beside the point.
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: sconklin_, xnox
<ScottK> I'm not arguing about what should be done, I just found the bug report inconsistent and wanted to make sure we were fixing the right thing.
<ev> seb128: I've written the first part of retrying failed retraces and have an outstanding RT for it. It wont fix the counts for days that have already past yet, but it will queue up the problems that it has successfully managed to retrace so we can process those once I've finished that part of the code
<seb128> ev, great, thanks
<ev> in the immediate term it will allow us to manually trigger daisy to ask for the core files for specific failed-to-retrace problems and bucket them appropriately
<ev> sure thing
<ev> I'll keep you posted
<mitya57> xnox: lp:unity-mail is terribly outdated, so the diff is not what actually changed in this upload.
<xnox> mitya57: I noticed, once the diff got generated, checked the package-import, realised it.... now reviewing by hand and deleted the merge proposal ;-)
<mitya57> xnox: the actual diff is http://bazaar.launchpad.net/~mitya57/ubuntu/quantal/unity-mail/1.2/revision/11
<xnox> mitya57: it's interesting that there are multiple templates successfully translated by launchpad...... I need to set this up for my project.
<mitya57> xnox: in case you'll be looking at lp:~mitya57/ubuntu/quantal/libunity/lp1055019 â don't upload it, just merge
<mitya57> thanks for unity-mail btw
<mlankhorst> ogasawara: ping?
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: sconklin_
<xnox> sconklin_: piloting for the second day now? =))))
<sconklin_> xnox: thanks
<sconklin_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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:
<ogasawara> mlankhorst: pong, sorry for the delay, was in a meeting
<cr3> bryceh: hi there, might you happen to know where I should get piglit for precise? I thought it should be under ppa:ubuntu-x-swat/q-lts-backport but apt-cache search doesn't return anything for "piglit"
<cr3> bryceh: tried to apt-file update, but got Ignoring source without Contents File: http://ppa.launchpad.net/ubuntu-x-swat/q-lts-backport/ubuntu/dists/precise/Contents-amd64.gz :(
<iamfuzz> anybody here a debian-installer expert?  Trying to figure out how to run a command just after partman does its thing but while partman/early_command exists partman/late_command does not :-(
<bryceh> cr3, presently it seems most effective to just check it out from upstream's git tree.  They don't do formal releases, and we are lax at packaging it.
<bryceh> cr3, I'm hoping as more of us use piglit, we'll do better at packaging, but at the moment there aren't packages worth pointing you at.
<|Anthony|> what is the plan regarding consolekit and udev considering they have been merged into systemd?
<cr3> bryceh: is it packaged somewhere though? was I looking in the right place under ubuntu-x-swat?
<|Anthony|> i see that they are both included in quantal
<cr3> bryceh: would the package depend on anything else?
<bryceh> cr3, there should be a ppa around, but it's an old version. lemme check
<bryceh> https://launchpad.net/~xorg-edgers/+archive/piglit
<bryceh> so, maybe not so old, that looks quite current
<cr3> bryceh: awesome, thanks!
<bryceh> cr3, also see https://launchpad.net/~sarvatt/+ppa-packages which has current packages; not sure how those two differ
<Sarvatt> bryceh: https://launchpad.net/~canonical-hwe-team/+archive/piglit is the one checkbox is using because it needs rendercheck also, but yeah its in https://launchpad.net/~xorg-edgers/+archive/piglit also
<Sarvatt> err, cr3: ^^
<cr3> Sarvatt: thanks! it's really hard to search all ppas for a desired package :(
<doko> pitti : glibc2.0 => 1 : 4
<cr3> just learned something new, I can search launchpad ppas: https://launchpad.net/ubuntu/+ppas
<|Anthony|> what is the plan regarding consolekit and udev considering they have been merged into systemd?
<|Anthony|> i see that they are both included in quantal
<slangasek> consolekit has not been merged into systemd
<|Anthony|> slangasek, what does it say here: http://www.freedesktop.org/wiki/Software/ConsoleKit
<|Anthony|> you're right, it doesn't say merged...
<slangasek> outdated propaganda
<|Anthony|> lol
<|Anthony|> ok, so where is the current documentation. cause i just did a sdiff comparing 0.4.1 (from that site) and 0.4.5 (from /usr/share/doc) and they're the same
<|Anthony|> :)
<slangasek> current documentation of what?
<|Anthony|> of consolekit
<bryceh> can someone approve the two nvidia experimental packages in the New queue?  We're trying to get those out as SRUs for a game publisher, and their deadline is looming...
<slangasek> |Anthony|: what exactly are you looking for documentation of?
<|Anthony|> how to configure .seat files
<|Anthony|> and if it is even possible yet as it has been in the works for idk how long
<slangasek> |Anthony|: ah, I'm not aware of any progress on that feature
<|Anthony|> argh
<|Anthony|> sitting here trying to get a sane multiseat setup and pulseaudio can only be active on one seat at a time. something about an acl...
<|Anthony|> but that is starting to get above my pay grade
<infinity> bryceh: Looking at it right now.
<infinity> bryceh: (literally)
<bryceh> infinity, \o/ yay thanks
<infinity> bryceh: The changelogs reference the wrong bug, so there will have to be some manual tracking. :/
<infinity> bryceh: Also, the diff to debian/control between quantal and precise seems curious: http://paste.ubuntu.com/1229290/
<infinity> bryceh: Not sure which version is "wrong" here (possibly both), since an nvidia driver claiming to "Provide" fglrx seems a bit fishy but, on the other hand, are those conflicts not required?
<bryceh> infinity, looking at git logs, the fglrx additions look deliberate, although alberto didn't indicate why.  Guessing something to do with alternatives; both drivers provide their own glx library which would conflict if they're both installed I guess?
<infinity> bryceh: Sure, it makes sense for conflicts, not for provides.
<infinity> bryceh: Anyhow, the precise packaging, as you see, has none of that at all.
<infinity> bryceh: So, if the Quantal one is verging on "correct", then the precise one really isn't.
<infinity> bryceh: And if someone does want to re-upload to resolve that, referencing the correct bug (1047681) in the changelogs would be nice. :)
<infinity> bryceh: Other than those two issues, it looks fine, so if you can push me a saner package (or explain why this one appears insane), I'm good to go to let it in.
<bryceh> infinity, sure will do.  (I agree the diff looks odd, I'm not sure why that change was made but will track it down.)
<infinity> bryceh: Thanks.  You guys can re-use the same version number, since stuff in NEW doesn't "exist" yet.
<infinity> bryceh: Fixing the incorrect bug number in both packages would be nice, just so the SRU tracking is less annoying, but mostly, it's the debian/control thing I want either explained or fixed. ;)
<bryceh> ok
<bryceh> infinity, and then any issues with nvidia-settings-experimental?
<infinity> bryceh: nvidia-settings was identical to the quantal upload, so I'm happy to let it in, but it does have the same "incorrect bug in the changelog" issue, so if -driver- is being reuploaded, may as well fix -settings- too.
<bryceh> ok
<infinity> bryceh: I'll just reject them both for now.  Pester me mercilessly when something new lands, since I have the context now to process this in a matter of seconds/minutes.
<bryceh> infinity, I think I've figured out the debian/control file diff.  Looks like he modeled the precise-proposed control file off the one currently in precise rather than the one in quantal.
<bryceh> infinity, but I'll get a definitive answer before I re-ping you.  Thanks again.
<infinity> bryceh: Ahh, if this is what all the other nvidia drivers in precise look like, that may well be acceptable for now.
<infinity> bryceh: (correct bugs in changelogs still would be nice, but any monkey with a text editor and upload rights can fix that) ;)
<cjwatson> iamfuzz: Indeed, there's no partman/late_command.  Exactly what are you trying to do?
<iamfuzz> cjwatson, trying to modify taskman tasks.  Found the section on hooks which seems to be the trick
<cjwatson> iamfuzz: YM tasksel?  Not sure why partman/late_command would be any more useful than partman/early_command for that
<iamfuzz> cjwatson, partman/early_command runs before /target has been populated with the base-install, no?
<cjwatson> Sure, but so would a hypothetical partman/late_command.
<cjwatson> A post-base-installer.d hook written out by a preseed/early_command script is probably indeed the right approach.
<iamfuzz> cjwatson, testing just that now
<cjwatson> (Or partman/early_command.  It makes little difference which.)
<bryceh> infinity, I've added explanations of all the diffs to the Fix section of bug #1047681.
<ubottu> Launchpad bug 1047681 in jockey (Ubuntu Quantal) "Add package nvidia-experimental for tracking nvidia beta drivers" [Wishlist,In progress] https://launchpad.net/bugs/1047681
<infinity> bryceh: Good enough for me.  Want to reupload both packages with the changelog bug references fixed, and I'll eyeball 'em and push them through?
<infinity> bryceh: Or, I suppose I could just fix those two oversights and reupload, since I have the sources sitting here.
<bryceh> infinity, yep uploading now
<infinity> bryceh: Ahh, fantastic.
<bryceh> infinity, both should be in now.  only thing changed should be the bug #
<infinity> bryceh: I'm guessing we need nvidia-common and jockey for this to all work, too.  Anything else?
<infinity> bryceh: Both of which also have issues.
<infinity> bryceh: jockey references the wrong bug too.
<infinity> bryceh: And nvidia-common includes a patch that patches debian/* (eek)
<bryceh> infinity, the nvidia-common and jockey changes clean up the UI a bit.  The drivers  don't depend on those changes, so it's safe to put them in the unapproved queue independently.
<infinity> bryceh: Well, I've already accepted the drivers, yes.  Would be nice to get the above issues sorted with those uploads too, so I can accept them as well, though.
<bryceh> infinity, sure thing, will do
 * bryceh waves to rickspencer3 
#ubuntu-devel 2012-09-27
<cjwatson> bdmurray: I hope my comments in bug 1039484 and the rationale for why I don't think this should be done in python-apt make sense
<ubottu> Launchpad bug 1039484 in ubuntu-release-upgrader (Ubuntu Quantal) "Accents in sources.list breaks do-release-upgrade" [High,In progress] https://launchpad.net/bugs/1039484
<cjwatson> bdmurray: You mention "two places" in the MP - what's the other?
<mfisch> robert_ancell: I responded to your question on gnome-icon-theme-symbolic
<robert_ancell> mfisch, my point is neither the gnome-icon theme git log (http://git.gnome.org/browse/gnome-icon-theme/log/) or tarball show any of these changes for gnome-icon-theme
<bryceh> infinity, jockey and nvidia-common fixed and re-uploaded
<bryceh> infinity, I renumbered nvidia-common to 0.2.44.1 which I suspect is more correct since it's an SRU of a native package; the previous upload was 0.2.46... I'm assuming it's not too late to redo the number but if so I can redo it as .46.
<rickspencer3> hi bryceh
 * rickspencer3 waves back
<mfisch> robert_ancell: sorry, I had it backwards, updating the bug
<mfisch> robert_ancell: looks like this is only a version change
<infinity> bryceh: That should be fine, lemme give them a once-over right now.
<bdmurray> cjwatson: yes, it makes sense that merge proposal was a bit stale.  I believe it was also crashing in logging.debug() although it isn't happening with my test now
<cjwatson> It'll depend on the other arguments.  In general, in Python 2, attempting to do unicode_value % utf8_byte_string_value will fail.
<cjwatson> (Which logging.debug may do under the covers.)
<infinity> bryceh: The fix for #976779 ... Shouldn't the package ship the /var/lib/nvidia-common directory?
<infinity> bryceh: Or does hybrid-detect write the directory as well as the file?
<bryceh> lemme doublecheck
<infinity> bryceh: Yeah, looks like it just does an fopen() on the filename, so that's going to fail without the directory being present.
<infinity> bryceh: Probably needs fixing in quantal too, if this was a straight backport.
<bryceh> in setup.py is:                ("/var/lib/nvidia-common/", glob.glob("share/last_gfx_boot")),
<bryceh> infinity, let me check the deb but I think it establishes the dir at package install time
<infinity> bryceh: Ahh, I didn't notice that setup.py was creating the path.  That'd do it.
<bryceh> -rw-r--r-- root/root         5 2012-09-20 07:04 ./var/lib/nvidia-common/last_gfx_boot
<bryceh> yep, it's in the .deb
<infinity> Shiny.
<infinity> Accepting both, then.
<bryceh> thanks :-)
<infinity> bryceh: Thanks for fixing all the nit-picking. ;)
<mfisch> robert_ancell: someone registered the wrong upstream project for sonic, I'm going to fix it
<robert_ancell> mfisch, yeah, there's a suprising number of those - I don't know if that was people or a script that linked them
<mfisch> it caused me some confusion, but it's fixed now
<mfisch> robert_ancell: what's the fix for this?  dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<mfisch> robert_ancell: there's a control field I think I can use, can't remember what it is
<robert_ancell> mfisch, it's just the maintainer field
<robert_ancell> we just set them to Ubuntu Desktop if they're maintained by the desktop team
<mfisch> the last upload was NMU as well
<mfisch> so it somehow worked
<mfisch> I did talk to the maintainer BTW
<jetsaredim> is there an easy way to unpack the source of a given package to see how it's built?
<jetsaredim> without having to setup a whole development environment?
<mfisch> jetsaredim: apt-get source <package>
<jetsaredim> where does it get deposited?
<mfisch> in your current directory
<mfisch> and you don't need to use sudo
<infinity> mfisch: That warning is implying that you should run "update-maintainer(1)"
<mfisch> infinity: so that just un-made Bill Cox the maintainer
<infinity> mfisch: Bill Cox being the Debian maintainer?
<mfisch> I assume so
<mfisch> he's the upstream maintainer
<infinity> Yes, well.  That's correct.
<infinity> Ubuntu-modified packages are maintained by ubuntu-devel.
<mfisch> I'm still curious how the last upload worked, but I'll make this change
<mfisch> thanks infinity
<infinity> And the original maintainer is set as Original-Maintainer in the control info.
<infinity> The last upload may have worked if you didn't have DEBEMAIL set when you built it.
<mfisch> must have been (it wasn't me who did it)
<infinity> Which makes the hard error turn into a warning, for reasons the devscripts maintainer has never convinced me make sense.
<mfisch> that script set "XSBC-Original-Maintainer", I assume that's right
<infinity> Either way, it's Ubuntu policy to change maintainer when we change packages, so the Debian maintainers don't get hassled about things we change/break in Ubuntu.
<infinity> mfisch: It does it right, yes.
<jetsaredim> its been a while since I wrote/reviewed Makefiles but where would the configure script be called?
<mfisch> thanks, I was worried that changing it was a rude thing to do maybe ;)
<mfisch> jetsaredim: usually in ./configure?
<infinity> mfisch: No, not changing it tends to be the rude thing.  This policy was at the request of Debian. :)
<infinity> (Or, rather, many many Debian developers)
<jetsaredim> mfisch: no i mean where is that called from
<jetsaredim> like where are the options defined for calling configure
<infinity> jetsaredim: If you're talking about packaging, in debian/rules
<mfisch> ah, well it's done durin...
<mfisch> what he said
<infinity> jetsaredim: If you're building by hand, nothing calls configure, you do.
<jetsaredim> infinity: i'm trying to figure out what is causing an issue I'm seeing with a given package
<jetsaredim> tcdecode which is part of transcode is complaining about not being able to handle mpeg2
<jetsaredim> (in quantal)
<jetsaredim> was just trying to see if the configure option had been set to include the --enable-libmpeg2
<jetsaredim> which is seems to have - so now i'm a bit baffled
<mfisch> jetsaredim: sounds like you'll want to setup a build environment and see how it was built
<jetsaredim> mfisch: i'm a little over my depth at this point
<mfisch> jetsaredim: how did you figure out if that flag was enabled?
<jetsaredim> its listed in the rules file
<pitti> doko_: more like 0:8 :(
<jetsaredim> confflags += --enable-libmpeg2
<pitti> Good morning
<jetsaredim> mfisch: ldd seems to think that none of the transcode utils are linked to libmpeg2
<mfisch> pitti: thanks for the talk this morning
<mfisch> jetsaredim: I'm not familiar with that package unfortunately and it's my bedtime, did you file a bug and attach what you figured out?
<jetsaredim> mfisch: only thing I can think of is that the configure needs both --enable-libmpeg2 AND --enable-libmpeg2convert
<mfisch> jetsaredim: that should be easy for you to test
<jetsaredim> mfisch: i'm in the process of re-opening an old bug for the same issue
<mfisch> jetsaredim: do you know how to build it and install build-deps?
<mfisch> jetsaredim: actually I can build it for you for quantal real quick
<jetsaredim> i was hoping to not turn this system into a build box
<jetsaredim> if you don't mind that would be awesome
<mfisch> jetsaredim: whats the package again?
<jetsaredim> transcode
<mfisch> i386 or amd64?
<jetsaredim> i think just adding a line to debian/rules to add the --enable-libmpeg2convert might do it
<jetsaredim> i'm amd64
<mfisch>  transcode 3:1.1.7-2build1 is what I'm seeing
<jetsaredim> yep - that's the current 12.10 version
<mfisch> okay, pulling build-deps
<jetsaredim> i suppose if i'm going to play around with this stuff i should probably learn more about packaging
<jetsaredim> been a while since i messed with any debs
<pitti> doko_, infinity: OK, after 8 or 9 tries I give up, and make tests non-fatal on armel/hf
<mfisch> jetsaredim: you want a binary or package?
<mfisch> let me upload the package
<jetsaredim> mfisch: package works
<mfisch> jetsaredim: glad that option worked for you
<jetsaredim> yea - now i can make my perfectly legal backups of my dvds
<jetsaredim> :D
<ScottK> doko_: Would you please retry ktorrent on armhf in the rebuild.  I think it will work now.
<pitti> infinity: meh, now glib2.0 failed on armhf during compilation; shall I disable that part as well? :-)
 * pitti just sticks fingers in ears, sings "lalala" and hits "retry"
<dholbach> good morning
<pitti> hey dholbach, guten Morgen
<dholbach> hey pitti
<earthling_> What do you guys think of the Amazon Ubuntu Search feature?  Should it be included in 12.10?
<pitti> I think it should be in the dash search, but not in the launcher as an icon
<pitti> sabdfl: good morning, how are you?
<pitti> sabdfl: amazon icon in the launcher certainly stirred some "discussion"?
<earthling_> pitti, that is reasonable
 * pitti mubmles "billboard"
<RAOF> My amazon icon disappeared as soon as I clicked on it.
<RAOF> Which was odd.
<penreturns>  yup its call unity lens shopping
<RAOF> I wonder if the U1music icon will do the same.
<earthling_> I'm actually still using 10.04 , works well enough for me
<pitti> RAOF: amazon icon does the same here, u1 ms WFM
<earthling_> I am interested in all the new changes
<RAOF> Hm. Nope. Apparently the U1music icon doesn't do anything, though.
<pitti> RAOF: for me it opens firefox with the u1 music page
<pitti> (shop)
<RAOF> Doesn't seem to want to do that here.
<pitti> I tried it in a guest session
<earthling_> penreturns, is there a way to turn it off?
<penreturns> yup u can remove the package
<pitti> my user doesn't have any of the default launchers except nautilus
<penreturns> sudo apt-get remove unity-lens-shopping
<RAOF> penreturns, earthling_: Or twiddle the setting in Privacy
<RAOF> (That'll exist once didrocks' package lands after B2)
<earthling_> I've never seen so much press about a development issue
<earthling_> other than Unity, heh
<RAOF> Or... what was the other one?
<RAOF> Oh, Banshee-amazon-referral.
<RAOF> There seems to be roughly one per release :)
<earthling_> Shuttleworth's discussion on the Amazon Dash issue   http://www.markshuttleworth.com/archives/1182
<sabdfl> pitti, sure, not unexpectedly
<sabdfl> we need to do a good job of giving people privacy options, and security
<sabdfl> but i think 12.10 will have all that
<pitti> right, I specifically asked about the launcher icon
<sabdfl> then the tin foil hat crowd can go somewhere else, where they will be disappointed by their new overlords i'm sure :)
<sabdfl> pitti, oh, is there an issue with the icon?
<pitti> sabdfl: I think the dash search is fine (modulo privacy options blabla, but we have that), I just don't particularly like the icon in the launcher which looks like an "Amazon" billboard
<pitti> the u1 music store is still closely related to Ubuntu, but I have a feeling that adding the amazon icon there breaks a dam
<pitti> but anyway, I guess that was discussed over and over, so perhaps I STFU to not open up old wounds again
<sladen> pitti: I believe we ship  http://start.ubuntu.com  containing a Google logo
<pitti> sladen: that doesn't clutter up the default desktop, though; not only do we already have too many starters by default, they now also contain non-ubuntu ads
<jussi> Is the amazon thing in the default (super only) dash?
<pitti> sladen: I hope we at least get some good dimes from amazon for that :)
<Laney> there's a webapp icon in the launcher too
<sladen> jussi: the Amazon lens, is "just" the Amazon lens---however all lens get combined sourced to the default <Super> action
<sladen> jussi: eg. a bit like Google searching everything by default; or you can select just images, just usenet, just patents
<jussi> aye.
<sladen> jussi: and it seems to be this aspect that people maybe concerned about.  However, pitti's point is seemingly(?) about the icon being there in-your-face
<sladen> pitti: ^^can you clarify?
<pitti> sladen: yes, that and that we already abuse the launcher too much and put too many default icons there
<jussi> you might calm the flames a bit if you introduce a bunch of others, not just amazon, and do what browsers do - a first run service selection for your dash
<jussi> ie. when I install chrome, it asks me which search engine I want
<seb128> pitti, oh, fighting this battle again? ;-)
<pitti> seb128: I didn't really see the previous ones; I just raised my eyebrow when I saw the new icon yesterday
<Laney> I clicked it once to see what would happen and then it disappeared on its own and never came back :P
<pitti> seb128: the "overfull launcher", yes, that comes up all over again and nobody seems to care
<Laney> pitti: design argued that the concertina effect is there for just this purpose, so it's not a problem
<sladen> the one positive suggestion, is that below the installer MP3 tick box we have another default-ticked "enable handy online stuff [you probably want this too]"
<sladen> (the one positive suggestion that I've heard)
<Laney> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1054167 that's this
<ubottu> Launchpad bug 1054167 in unity (Ubuntu R-series) "Unity launcher for Quantal Beta 2 has too many items, scrolls off the screen on 1366x768" [Undecided,Confirmed]
<jussi> sladen: yeah, I like that suggestion
<Laney> doko_: https://launchpad.net/~laney/+archive/webkit2/+packages
<cjwatson> sladen: while it might work out to be a nice approach, it's punting a UIFE off onto foundations and it's a fair number of moving parts to get settled down in time for final freeze ...
<cjwatson> so, well, if that turns out to be the answer I just hope it occurs to somebody that we need actual notice of this kind of thing and some time
<cjwatson> this is exactly why this should have landed before FF, to allow time for consequential changes elsewhere *grump*
<ev> mpt: what are your thoughts on including a projection line on the graph? Something akin to this http://baykeeper.org/data_viz/official-sea-level-rise-projection
<mpt> ev, look at the Quantal graph. Imagine a projection line on that. It would be slowly accelerating upwards, hitting about 0.15 on release day.
<ev> call me pessimistic, but that's what I expect will happen
<mpt> heh
<mpt> ev, we know that's not going to happen because we humans know stuff about the release process that a projection line does not.
<ev> :) fair enough
<cjwatson> ev: Do you have any idea why https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fsoftware-properties-gtk%3AKeyError%3A%3Cmodule%3E%3A__init__%3Ashow_drivers is showing up in 0.92.6?  That line of code was changed in 0.92.4
<cjwatson> (and should have fixed that bug)
<cjwatson> I could understand that versions might be out of sync if it were a daemon process or something, but I wouldn't have expected software-properties to be long-running
<ev> cjwatson: it's still a pretty low count, so it could be the "they upgraded while the program was still running" problem
<ev> we filter those out for crashes sent to Launchpad, but we're still working through the solution for daisy:
<cjwatson> mm, right
<ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1039220
<cjwatson> possible I suppose
<ubottu> Launchpad bug 1039220 in apport (Ubuntu Quantal) "don't report crashes for programs that don't match the file on disk (like for kernel crashes)" [Medium,In progress]
<ev> and https://code.launchpad.net/~brian-murray/apport/no-unreportable/+merge/126082
<mpt> ev, do you know when the next rollout will be?
<cjwatson> ev: that bug appears to be waiting for you to follow up :-)
<ev> mpt: of what feature? :)
<mpt> ev, the graph mainly
<cjwatson> (or maybe I'm misreading)
<ev> cjwatson: I followed up in the merge proposal, but I'll note that in the bug
<ev> mpt: I'll file and RT and ask for a rollout today
<ev> an RT*
<cjwatson> ok
<mpt> ev, btw did you realize the legend has disappeared?
<ev> mpt: I made it do so, per your mockup
<ev> I need to implement moving it to the bottom
<ev> mpt: since we will soon be able to show graph and table data for just packages in -proposed, I'm questioning the need for being able to filter to arbitrary versions of specific packages
<ev> well, questioning it a bit more
<ev> and of course we already split out release by release data
<ev> I guess it helps because we haven't quite solved updates
<ev> err never mind, you'd see what's important in the normal view there
<earthling_> Off switch being made for the shopping lens   http://www.omgubuntu.co.uk/2012/09/is-an-off-switch-for-the-shopping-lens-in-the-works
<pitti> jdstrand, infinity: how are we supposed to get lpia builds for hardy updates these days? our only buildd seems disabled
<pitti> can I temporarily recruit an i386 or amd64 builder to build https://launchpad.net/ubuntu/+source/postgresql-8.3/8.3.21-0ubuntu8.04/+build/3857919 ?
<cjwatson> Yeah, I think that should work - feel free to try
<pitti> ok, trying on aatxe
<pitti> cjwatson: nice, that seems to work; it's past the tests in the debhelper stage
<cjwatson> oddly reassigning a PPA builder didn't seem to work
<cjwatson> (I asked on #launchpad-ops)
 * pitti reassigns aatxe back to i386 duty
<cjwatson> did you have to set it to manual and back or anything like that, or did you just change the processor type?
<pitti> cjwatson: I did set it to manual first, but more out of a habit
<pitti> to set it back I just changed the arch (it was idle then)
<pitti> cjwatson: you can tell a PPA builder to build ubuntu packages?
<cjwatson> No, to ppa/lpia
<cjwatson> I'll try manual/auto
<pitti> cjwatson: ah; we do have a working lpia PPA builder, though
<cjwatson> we do?  gold is disabled
<pitti> cjwatson: so, it worked without manual in one direction
<cjwatson> gumiho is the one I'm trying to reassign
<pitti> aah, I see; that's the one I was seeing
<cjwatson> it says lpia but is persistently idle
<cjwatson> I guess I don't care that much; I'll reassign it back in a bit if it doesn't do anything
<pitti> aatxe picked up the waiting job within seconds
<cjwatson> yeah, I saw
<pitti> so, no idea what's wrong here :(
 * cjwatson is looking forward to b2 being out so that he can stress-test the new queue-accept-should-never-time-out thing
<pitti> is there a target time when we unfreeze today?
<cjwatson> not that I know of
<pitti> i. e. the point of no return^H^H^H^Hspin
<pitti> that reminds me, christmas wish #23: a queue tool option to accept a "quantal" upload into "quantal-proposed" instead, so that stuff can already build and get autopkgtest-ed
<cjwatson> once we have britney operational we'll just redirect everything from devel to devel-proposed
<pitti> but that'll soon fix itself anyway when all uploads get built in -proposed
<pitti> right :)
<pitti> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/ tests -proposed now
 * cjwatson wonders how hard changing the suite in the queue would actually be
<cjwatson> It *might* just be a matter of making PackageUpload.pocket (and PU.distroseries?) writable
<cjwatson> tests would be an absolute git to write though
<pitti> probably not worth the effort; it just came to my mind again
<Laney> doko_: do you plan to do any build log analysis / bug filing from the rebuild test?
<MohamedAlaa98> Hello, please help me, I want to update a package to new version for quantal, can I do this or that is incompatible with feature freeze?
<tumbleweed> MohamedAlaa98: there needs to be a good reason for it, and it should be thoroughly tested, etc.
<MohamedAlaa98> thumbleweed: please explain it for me, what do you mean by "a good reason"?
<MohamedAlaa98> tumbleweed: *
<tumbleweed> MohamedAlaa98: it needs to be worth the risk
<l3on> Hi.. do you think it's still possibile add youtube-dl 2012-09-27 in quantal?
<tumbleweed> l3on: any particular reason?
<MohamedAlaa98> tumbleweed: okay thanks :D
<l3on> tumbleweed, first reason I found: there's a bug downloading playlist .. something in youtube has changed in last months
<tumbleweed> l3on: sounds good. file an ffe
<l3on> tumbleweed, great!.
<jdstrand> pitti, cjwatson: so afaik, you need to do what you did. I don't have the perms to do it, so I don't know the exact steps
<cjwatson> jdstrand: yeah, it's all right, sorted now
<jdstrand> didrocks: hi! do you know if there is a bug already for 'ctrl+lt+t' not opening a terminal. if not, what package should that be filed against?
<jdstrand> didrocks: google is not helping me... :\
<didrocks> jdstrand: yeah, it's because of duplicated keys on compiz and g-s-d
<didrocks> jdstrand: there is a fix coming with next compiz
<didrocks> jdstrand: but you can workaround it for now
<didrocks> open gnome-control-center -> keyboards -> keybindings
<didrocks> section Launcher
<didrocks> IIRC, "Launch a terminal" is the one which is bound to the actual compiz code, ensure it's set to ctrl + alt + t
<didrocks> "Launch a Terminal" should be unset
<didrocks> jdstrand: once the next compiz will be here, be aware that "Launch a terminal" will disappear and you will have to set "Launch a Terminal" then to ctrl + alt + t (as you would have unset it)
<jdstrand> didrocks: thanks! after the compiz update, will I have to set that back?
<jdstrand> oh, heh
<jdstrand> cool
<jdstrand> didrocks: thanks again, this was mildly annoying :)
<didrocks> jdstrand: sorry for the trouble :)
<jdstrand> didrocks: not a big deal, I just wanted to make sure it was filed/fixed
<Kano> hi cjwatson
<didrocks> jdstrand: it's a typical case where 2 > 1 isn't a real advantage :)
<jdstrand> :)
<Kano> cjwatson: when grub-pc is installed + grub-efi-amd64-bin then grub is installed only for efi but with config for mbr
<Kano> cjohnston: thats wrong, tested with debian exp -7
<Kano> cjohnston: you definitely have to modify grub-install
<Kano> err cjwatson always ;), the efivars check is not optimal alone, when you use a different bootloader like gummiboot or direct uefi boot but you want to use grub for selection of other legacy systems like win
<l3on> tumbleweed, these are changes in youtube-dl.. what you think about it? is it better apply only patch rather than bump a new version of package ?
<l3on> tumbleweed, sorry - these are the changes -> http://paste.ubuntu.com/1230335/ ^
<doko> Laney, the analysis for main and package sets was done. asked amoog for filing the universe bug reports. however the universe rebuild will take time until after the weekend
<doko> didrocks, seb128: ping about the gnome/gtk header include fixes ...
<seb128> doko, what about those?
<doko> see backlog
<doko> didrocks, seb128: is there an easy work around for #warning "Including <librsvg/rsvg-cairo.h> directly is deprecated." ?
<seb128> don't include it directly?
<doko> there are a lot of these in universe
<doko> seb128, please fix
<seb128> what? universe buggy apps?
<seb128> sorry I've enough work on the default installation issue and that's higher priority than universe random packages
<doko> darktable, gstreamermm, subtitleeditor are those in package sets
<seb128> well, whoever is owning one of those set can look at them I guess
<geser> darktable is already fixed (waiting in queue)
<geser> I'm trying to through the rebuild results and fix them when I see them
<seb128> geser, thanks
<doko> honestly such changes should told once new gtk/gnome changes get uploaded
<doko> be told
<seb128> it's hard to know what has an impact or not, they did similar change to lot of libs over time, I don't want to spam lists with every change GNOME does to its libs
<doko> yeah, so better leave it to other to detect and fix
<seb128> it's not like you were emailing the list about every single toolchain change either...
<seb128> see the stl abi issue that didrocks has to track down earlier in the cycle
<Kano> cjwatson: next bug: get rid of -w for efibootmgr, it just overwrote my hd uuid, that means my win install does not boot (mbr), my hd is mbr with efi as primary partition. -w kills win
<doko> seb128, bullshit. the known toolchain changes were announced, with hints how to fix. the abi issue was not known
<seb128> doko, the include issue was not known either
<doko> you call yourself a tech "lead", so please be proactive
<seb128> doko, I didn't call myself that
<doko> seb128, I doubt it, it did pop up for precise as well, and afairc it was reverted
<seb128> doko, that was in glib
<seb128> no librsvg
<seb128> which has another scale and was handled properly
<doko> right, see subtitleeditor
<doko> and gstreamermm
<seb128> right, you come with like 5 rdepends
<seb128> can't we just fix them and move on?
<seb128> it doesn't seem worth the discussion
<doko> no, I can't fix hundreds
<seb128> is it really hundreds?
<seb128> we should probably revert the librsvg change if that's the case
<doko> start with glib if you really do care
<seb128> $ grep-available -s Package -F Build-Depends librsvg2-dev /var/lib/apt/lists/*quantal*Sources | sort | wc -l
<seb128> 67
<seb128> I don't see how it can be "hundreds"
<seb128> when there is less than 100 sources using librsvg
<seb128> what about glib?
<doko> there are hundreds of build failures. if you address those which you introduce with new upstream versions yourself, ... it would help a lot
<doko> again see subtitleeditor and gestreamermm
<seb128> I've no time for universe sorry
<seb128> I can file bugs asking those to be removed from quantal if that helps
<doko> being productive today?
<seb128> I was until you started that IRC discussion
<seb128> I'm sorry but it's just not realistic to expect me or whoever upload glib and gtk to be responsive for ever years old unmaintained universe source
<seb128> I'm happy to get those dropped from the archive if nobody has time,motiviation to fix them though
<seb128> that's the best I can offer you today
<seb128> that said, going back to what I was working on
<smoser> slangasek, wonder if you have a thoughts
<smoser> if an interface is brought up in the kernel (ipconfig)
<smoser> then when network-device-added comes through, it is 'ifup' will fail, and not call the upstart hooks for ifup
<smoser> so static-networking wont fire. even though it already is set.
<smoser> open-iscsi has some "helper" stuff to get this fired for the device that its iscsi root is on. but i'm wondering if there should be a more general solution.
<geser> seb128, doko: a fixed gstreamermm and subtitleeditor are waiting in the queue
<seb128> geser, thanks a lot
<stgraber> smoser: that sounds like bug 1010439
<ubottu> Launchpad bug 1010439 in ifupdown (Ubuntu) "ifup fails prematurely if the same static IPv4 address was configured per kernel command line" [Undecided,Incomplete] https://launchpad.net/bugs/1010439
<stgraber> smoser: any such interface really ought to be marked as "inet manual" though, that way ifupdown should do the right thing
<smoser> stgraber, yes, yes it does.
<seb128> dpm, hey
<seb128> dpm, do you know why https://translations.launchpad.net/ubuntu/quantal/+source/unity-lens-shopping/ is empty ?
<smoser> stgraber, the issue with 'inet manual' is that it wont apply to static-networking
<smoser> when imo, it should
<smoser> (ie, if that nic is up from the kernel, and its the only one in /etc/network/interfaces as 'auto', then static-networking should fire)
<dpm> seb128, hm, it seems there hasn't been any .pot file imported, I was wondering about this the other day, but at that point there wasn't a source package uploaded yet. Maybe the uploaded package didn't create a .pot file? https://translations.launchpad.net/ubuntu/quantal/+source/unity-lens-shopping/+imports
<seb128> dpm, the build log https://launchpadlibrarian.net/116724481/buildlog_ubuntu-quantal-i386.unity-lens-shopping_6.0.0-0ubuntu1_BUILDING.txt.gz has
<seb128> "Running xgettext --add-comments --directory=. --default-domain=unity-lens-shopping --flag=g_strdup_printf:1:c-format --flag=g_string_printf:2:c-format --flag=g_string_append_printf:2:c-format --flag=g_error_new:3:c-format --flag=g_set_error:4:c-format --flag=g_markup_printf_escaped:1:c-format --flag=g_log:3:c-format --flag=g_print:1:c-format --flag=g_printerr:1:c-format --flag=g_printf:1:c-format --flag=g_fprintf:2:c-format --flag=g_sprintf:2:
<seb128> c-format --flag=g_snprintf:3:c-format --flag=g_scanner_error:2:c-format --flag=g_scanner_warn:2:c-format --output=unity-lens-shopping.pot --files-from=./POTFILES.in.temp --keyword=_ --keyword=N_ --keyword=C_:1c,2 --keyword=NC_:1c,2 --keyword=Q_ --keyword=g_dgettext:2 --keyword=g_dngettext:2,3 --keyword=g_dpgettext:2 --keyword=g_dpgettext2=2c,3 --from-code=UTF-8
<seb128> Removing generated header (.h) files...done.
<seb128> Wrote unity-lens-shopping.pot"
<seb128> ups
<seb128> sorry, didn't realize the xgettext line was a long one
<dpm> seb128, I see it was in universe and then went to main. Could that have affected it?
<seb128> dpm, it could I guess
 * dpm builds package locally to see what translations look like
<stgraber> smoser: hmm, my understanding is that if you configure network from the initramfs and have the interface marked as "inet manual", then when network-device-added is received, the ifup <interface> will succeed and statis-network-up will be emitted (assuming it's the only interface)
<seb128> didrocks, ^ do you plan an upload soon for unity-lens-shopping?
<didrocks> seb128: there is one start of next week
<didrocks> I can make a dummy upload if needed
<didrocks> to have it rebuilt
<seb128> didrocks, see other channel
<stgraber> smoser: anyway, an alternative would be for the initramfs script to do: "mkdir -p /run/network/ && touch /run/network/ifup.$INTERFACE"
<seb128> didrocks, ignore that ... do you want me to do the dummy upload?
<stgraber> smoser: oh, and you'd also likely want "echo $INTERFACE=$INTERFACE > /run/network/ifstate" so that ifupdown doesn't try to bring it up again
<didrocks> seb128: fine with me :)
<seb128> didrocks, ok, doing it
<stgraber> but that sounds like a hack to me, having the interface configured as inet manual should do the trick...
<didrocks> seb128: the packaging branch in lp:ubuntu/unity-lens-shopping :)
<seb128> didrocks, thanks
<didrocks> thanks to you :
<didrocks> :)
<dpm> seb128, hm, I can't seem to be able to build the local package, I'll leave it to you guys and the new upload
<smoser> stgraber, i'll see if manual works.
<smoser> you think it will get bounced?
<seb128> dpm, sure
<smoser> stgraber, i think you're right. manual should work.
<stgraber> smoser: with manual, the interface shouldn't be touched but the if-up scripts should be run, which is what I think we want
<seb128> dpm, thanks
<stgraber> IIRC that's what I implemented in casper for netboot installs and what we have in LTSP, so if that doesn't work, we need to figure out why and fix it :)
<smoser> stgraber, shoot. the one other thing is that i want resolvconfhooks to fire.
<smoser> they will, right?
<stgraber> yep
<stgraber> they are if-up hooks, so they should still be called
<smoser> stgraber, http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/view/head:/dyn-netconf/scripts/init-bottom/cloud-initramfs-dyn-netconf
<smoser> that is what i'm working on.
<smoser> i'll just write manual instead of auto on line 68 then.
<smoser> and hopefully magic will occur
<smoser> (basically, this writes a /etc/network/interfaces style file in /run/network/dynamic-interfaces. the filesystem that i'm using will have /etc/network/interfaces as a symlink to ../../run/network/dynamic-interfaces)
<stgraber> do you actually need networking later on in the initramfs?
<smoser> later on?
<stgraber> otherwise you could flush all IPs from the devices and let ifupdown do the work
<smoser> well, for this, its iscsi-root
<smoser> so yes
<stgraber> right :)
<smoser> but i think in general leave it
 * ogra_ wonder why we still dont have a generic networking function in the initramfs functions we could just source
<ogra_> *wonders
<ogra_> casper uses it, nfs, ltsp and iscsi ... and there are likely more
<stgraber> iscsi-root will need "inet manual", if not booting from iscsi you can probably do an "ip addr flush" at the end of your script and stick with "inet static"
<stgraber> ogra_: yeah, extending the networking function a bit would be nice, though so far I haven't seen two identical use cases for it ;)
<stgraber> ogra_: for example, LTSP doesn't use ipconfig, it uses udhcp with a separate hook that overrides ipconfig :)
<ogra_> stgraber, well, all of then do the same thing somehow
<ogra_> (make you end up with properly configured network)
<ogra_> its just a matter of making the function generic enough so i can be used in all contexts
 * ogra_ thinks that would probably make a good UDS topic, though it might clash with event nased initranfs which will require rewriting these bits anyway
<ogra_> *based
<Laney> doko: Actually my question about filing bugs was related to that
<Laney> if you have the facility to detect patterns like those #errors from including the wrong headers directly and can, say, tag the bug reports as such
<Laney> then it might be a good thing to do and get some fixed as part of dholbach's bug fixing initiatives
<dholbach> yeehaw
<doko> Laney, svammel could certainly extended for that
<tumbleweed> if geser hasn't fixed them all first
<geser> I only fixed 10 so far
<tumbleweed> don't stop now
<debfx> doko: what's the result of the qt build with -gstabs? did it change anything?
<slangasek> smoser, stgraber: seems hard to generalize from this; I can see cases when you might do ipconfig but subsequently want to reconfigure the interface with ifupdown post-initramfs
<smoser> slangasek, i think in that case you should bring the interface down in initramfs.
<smoser> (or perhaps even on network-device-added)
<slangasek> hmm, perhaps
<stgraber> yeah, my recommendation would really be to flush all addresses after ipconfig has run if you're using static config and don't need networking for your rootfs
<doko> debfx, Laney tried. I think it didn't help
<Laney> doko: actually it did
<Laney> in PPA, but not locally for some reason
<Laney> https://launchpad.net/~laney/+archive/webkit2/+packages
<Laney> s/2// has the almost final build I'm testing ATM
<micahg> cjwatson: are deb-src lines sufficient for the test on Bug #1053896 ?
<ubottu> Launchpad bug 1053896 in ubuntu-keyring (Ubuntu Precise) "Add new archive key to precise" [Medium,Fix committed] https://launchpad.net/bugs/1053896
<cjwatson> micahg: I'd like to test with deb lines as well
<cjwatson> micahg: I'll do it in a chroot now
<cjwatson> easy enough
<micahg> ok
<cjwatson> sbuild chroots> best thing ever for this kind of thing
<micahg> yep
 * micahg just noticed the warning on apt-get update this morning due to the deb-src lines
<cjwatson> I seriously used to copy chroots around.
<cjwatson> micahg: v-done now
<Kano> cjwatson: did you see my query
<brendand> can anyone recommend a good strategy for managing debian/changelog so that conflicts aren't so frequent?
<Laney> brendand: Tell your VCS to merge them using dpkg-mergechangelogs
<brendand> Laney, aha. i notice some projects like unity don't keep changelog with the source - what's that about?
<Laney> Keeping packaging and development separate is quite usual, is that what you're talking about?
<brendand> Laney, yeah
<brendand> Laney, how is it usually gone about?
<xnox> brendand: separate branch... one just upstream the other one just debian/ folder added.
<brendand> Laney, xnox - i was also curious about policy around trivial changes. what if i have just added some tests for code written a long time ago. should i always have a changelog entry for that, or is there some rule of thumb?
<xnox> brendand: two changelogs: one upstream the other one debian/changelog.
<xnox> for native packages both collapse into debian/changelog
<Laney> also a NEWS file listing important changes is common
<Laney> whereas ChangeLog contains all of them
<Laney> I often copy from NEWS into the debian changelog
<cjwatson> brendand: You certainly don't need to list everything in debian/changelog
 * ogra_ also likes if upstreams have TODO 
<cjwatson> brendand: It's at the packager's discretion what to list
<ogra_> so you know about known issues
<cjwatson> brendand: Personally, I generally list (a) upstream changes that have some kind of major user-visible impact or compatibility issues or whatever (b) anything that's known to fix distro bugs
<cjwatson> But there are varying opinions
<Laney> what's a pink background on the error tracker?
<cjwatson> Laney: "regression" - i.e. supposed to be fixed but shows up in >= the fixed version.  (in practice this is often because the program hasn't been restarted since the upgrade.)
<cjwatson> Daviey,smoser: bug 901600 - once that's fix released, quantal cloud images should be able to apply overrides in /etc/default/grub.d/*.cfg.  Do you want to try to do that for 12.10?
<ubottu> Launchpad bug 901600 in grub2 (Ubuntu Precise) "Allow /etc/default/grub overriding via /etc/default/grub.d/" [High,Triaged] https://launchpad.net/bugs/901600
<cjwatson> I've milestoned that for 12.04.2 as well
<smoser> YES!
<smoser> utlemming, ^
<cjwatson> Thought you might
<utlemming> very nice
<barry> zul: still looking at bug 1056820 or should i take a look at it?
<ubottu> Launchpad bug 1056820 in feedparser (Ubuntu Quantal) "feedparser ftbfs in quantal, test suite failures" [High,Confirmed] https://launchpad.net/bugs/1056820
<zul> barry: no still looking
<barry> zul: okay, i'll work on something else.  cheers.
<infinity> pitti: Not sure if anyone answered, but when I notice a build in the lpia queue, I just flip an i386 buildd to lpia, let it pick up the build, then flip it back.
<didrocks> scott-work: hey, FYI, bug #1054746 changed its intent. Jono's blog post reflect the latest design change (I've update the bug 10 hours ago to reflect it as well, when I was telling jono about the change)
<ubottu> Launchpad bug 1054746 in Gwibber "[FFe] [UIFe] No easy way to disable online-fetched results in lenses" [Undecided,In progress] https://launchpad.net/bugs/1054746
<ubottu> Launchpad bug 10 in Launchpad itself "It says "displaying matching bugs 1 to 8 of 8", but there is 9" [Medium,Invalid] https://launchpad.net/bugs/10
<cjwatson> infinity: Yep, that's what he did
<ScottK> didrocks: Wrong Scott
<didrocks> ScottK: misleading :)
<ScottK> didrocks: Could you update it with the new screen shot too.
<didrocks> ScottK: oh sure, I've given it to the translation team, but I can reupload it (again and again ;)) on the bug, one sec.
<mpt> ev, https://wiki.ubuntu.com/ErrorTracker#errors.ubuntu.com
<ScottK> That FFe is not, AFAICT, approved.  Once it gets the correct final, final screen shot in the bug, I'll approve it.
<didrocks> ScottK: updated, we talked about it this morning with Laney, I thought it was enough
<didrocks> (changed the description to point to latest screenshot)
<ScottK> It was clear that one was going to get approved at some point.  It just need the approval in the bug.
<ev> mpt: excellent, thanks!
 * mpt wtfs at the switch
<utlemming> cjwatson: do you know what would cause a grub2 error of "couldn't find a suitable memory target"?
<utlemming> cjwatson: is that an error while loading the kernel or grub itself? I can't find much on that particular error.
<cjwatson> You mean "couldn't find suitable memory target"?
<cjwatson> ./grub-core/lib/relocator.c:1420:      return grub_error (GRUB_ERR_BAD_OS, "couldn't find suitable memory target");
<utlemming> yup, that would be the one
<utlemming> we're seeing this on a Windows Server 2012 install
<cjwatson> That appears to be an internal GRUB error indicating that it has failed to allocate memory to load the kernel into
<cjwatson> Probably best to bring it upstream if you're seeing this on 2.00
<utlemming> cjwatson: what information do we need to bring that upstream? This is being seen on 12.10 B-2.
<cjwatson> utlemming: not sure, output from 'set debug=all' might help but hard to be certain
<cjwatson> this is a bit of a weak spot of mine
<cjwatson> you could ask on #grub
<ScottK> didrocks: Marked it approved, but I'm out of time to set all the tasks to triaged and set the milestone to 12.10.  Would you please do that or find someone who will.  I need to run off and get some $work done.
<utlemming> sure....going the...thank you kindly for the direction :)
<didrocks> ScottK: no worry, I'll do that :)
<ScottK> Thanks.
<didrocks> ScottK: maybe not this evening (launchpad is timing out a lot), but I'll do it
<didrocks> ScottK: thanks :)
<ScottK> OK.
<ev> if I'm moving a file from one binary package to another, both produced by the same source package, do I need to do breaks and replaces? I'm pretty sure I don't, but best to ask these things :)
<cjwatson> Yes, you do
<ev> oh, good thing I asked
<ev> cheers cjwatson
<cjwatson> np
<cjwatson> dpkg at runtime doesn't distinguish between binaries from the same source package and ones that aren't
<ev> cjwatson: if you have a moment - does this look reasonable? http://paste.ubuntu.com/1230715/
<cjwatson> ev: you only needs Breaks/Replaces from the new location to the old, not vice versa
<cjwatson> ev: and as a matter of style I usually use (<< first-version-with-new-location) rather than (<= last-version-with-old-location), just in case people have +ppa1 versions or whatever
<ev> cjwatson: so http://paste.ubuntu.com/1230725/
<cjwatson> ev: s/0ubuntu3/0ubuntu4/ there.  Otherwise LGTM
<ev> whoops!
<ev> sorry, blasted through that
<ev> thank you muchly
<cjwatson> easy to go cross-eyed with versions
<ev> :)
<dpb___> pitti: Hi, ahasenack and I hit an unusual problem.  When upgrading lucid -> precise, postgres 8.4 doesn't work after the upgrade.  Only after a (another) service restart, or a system boot.  This makes any package upgrade after that does anything with a postgres database fail.  Known issue?  Is there a way to workaround?
<ahasenack> dpb___: nice nick ;)
<ahasenack> dpb___: paste the error in pastebin
<dpb___> ahasenack: ya, good plan
<dpb___> pitti: http://pastebin.ubuntu.com/1230779/
<tjaalton> if you're seeing bug 966744, check the ppa and ping me here if it works/still breaks on quantal
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Precise) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
<stgraber> tjaalton: cool. Installed here, will see if that helps next time I logout
<tjaalton> stgraber: thanks
* ChanServ 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 general discussion for 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> barry: hi! is there an easy way to run a specific test for python? eg, let's assume I ran 'fakeroot debian/rules patch ; ./configure && make'
<jdstrand> barry: so I am now prepared to run 'make TESTOPTS="-j 50" testall', but instead of testall, I just want to run test_urllib2. how do I do that?
<barry> jdstrand: just run ./python Lib/tests/test_urllib2.py should do it
<jdstrand> oh, well, sheesh
<barry> :)
<jdstrand> barry: yeah, that works great. thanks! :)
<barry> jdstrand: np!
<barry> slangasek, doko: re: bug 1056820.  to fix the ftbfs, i did two things: merge from sid version 5.1.2, then remove some build-deps we added previously (python-chardet, python-libxml2, and python-utidylib).  those three cause the test suite to fail, and note that we had *already* disabled those for py3, so now our py2 build env matches.  upgrading to 5.1.2 allows us to drop two patches (including the CVE) which have been applied upstream
<barry> as of 5.1.2.  now the question is, how do we feel about doing that upgrade, and do we need an FFe?  it's a point release (we have 5.1 in quantal now) with what look like only bug fixes from the NEWS file.  of course, rdeps could be working around those problems.
<ubottu> Launchpad bug 1056820 in feedparser (Ubuntu Quantal) "feedparser ftbfs in quantal, test suite failures" [High,Confirmed] https://launchpad.net/bugs/1056820
<slangasek> barry: hmm,
<slangasek> barry: hmm, let's see if I understand correctly - does this mean we're going from having testing of one version of the bindings, to having testing of no versions of the bindings?
<slangasek> barry: as for the FFe question: provided that you're satisfied that the point release is bugfix-only, there shouldn't be any need for an FFe
<barry> slangasek: no.  we test both versions of the bindings, and still do.  it's just that chardet and friends totally f*cks up the tests.  it just that we realized this with py3 months ago and now realize it w/py2
<barry> slangasek: upstream confirmed that for py3, chardet is generally not useful for feedparser any more.  my assumption is that this has led them to basically obsoleting it for py2 as well
<slangasek> ah, k
<barry> slangasek: yeah, i think the point release is essentially bugfix-only, from my reading of the NEWS entries.  i'll go ahead and upload it
<slangasek> sounds good!
<zyga> pitti: there won't be any udisks in checkbox next week! :)
<doko> xnox, please don't disable the tests in git, I'm working with jonathan nieder on a backport
<doko> barry, in libxml2 2.9, it's the udeb which ftbfs
<xnox> doko: feel free to reject it from the queue, if it didn't land yet. Or superseed it.
<xnox> doko: please open a FFe though. it's two major releases jump.
<xnox> doko: or are you cherry picking?
<xnox> doko: what's best course of action for resolving bug 1048036 which is result of my merge as per bug 763457
<ubottu> Launchpad bug 1048036 in pyopencl (Ubuntu) "Python OpenCL cannot be installed in 12.10 due to unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/1048036
<ubottu> Launchpad bug 763457 in nvidia-graphics-drivers (Ubuntu Quantal) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
<xnox> I did ping tseliot about it early in the cycle..... but it's still open.
<doko> xnox, backport, not new upstream
<xnox> doko: ok. (In my mind backport is stuff that lands in backports pocket aka new upstream releases and stuff. I guess cherry-picking is a trendy term of the decade)
<ScottK> doko: Would you please retry kbruch on armhf in the test rebuild.  A local build worked.
<barry> doko: i'm going to unlink libxml2 from bug 1056820.  i don't need to upgrade that to fix the ftbfs for feedparser
<ubottu> Launchpad bug 1056820 in feedparser (Ubuntu Quantal) "feedparser ftbfs in quantal, test suite failures" [High,Confirmed] https://launchpad.net/bugs/1056820
<ScottK> doko: Looks like ktorrent on armhf is still waiting for a retry too.
<doko> ScottK, done
<ScottK> doko: Thanks.
<ScottK> Once the queue is flushed, all the Kubuntu ones that can be fixed (with the exception of Qt and I believe that's in progress) will be done.
<SpamapS> smb`: any luck on the network namespace issue in quantal's kernel?
<SpamapS> [65599.932030] unregister_netdevice: waiting for lo to become free. Usage count = 1
<SpamapS> smb`: pretty much can't use lxc on any quantal machine
<xnox> USN-1586-1 is funny: "arbitrary Lisp code execution"
 * xnox goes to check if it affects emacs24
<slangasek> robert_ancell: the glibmm2.4 in the quantal queue appears to introduce new interfaces, but does not bump the shlibs dependency, which means partial upgrades are broken for anything that depends on the new interfaces
<robert_ancell> slangasek, ah, ok. I should set SHVER in debian/rules to 2.32.0 right?
<robert_ancell> 2.33.13 rather
#ubuntu-devel 2012-09-28
<slangasek> robert_ancell: right and thanks :)
<infinity> robert_ancell: (And accepted, BTW)
<pitti> Good morning
<ion> hi
<pitti> infinity: lpia> that's what I did, thanks
<pitti> dpb___: postgresql> no, not known to me; I saw you mailed me, will answer via email
<pitti> zyga: udisks> yay you!
<pitti> hm, quantal is still frozen?
<micahg> pitti: yep, until release, so saith the release manager :)
<pitti> but we did release
<micahg> until final release
<micahg> pitti: https://lists.ubuntu.com/archives/ubuntu-release/2012-September/001981.html
<pitti> uh?
<pitti> *shrug* okaya
<micahg> a little backscroll in -release about it as well
<pitti> micahg: ah, it's the third-next email in my "to read" list; thanks for pointing out!
<micahg> sure, I miss working at this hour :)
<dpb___> pitti: thx for the follow up.   I'll file a bug tomorrow.
<joeljacobson> pitti: your 9.1.6 packages works great in my 12.04 LTS production environment
<dholbach> good morning
<pitti> joeljacobson: thanks for the additional testing!
<didrocks> speaking of whichâ¦
<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 general discussion for 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: didrocks
<dholbach> EVERYBODY: PLEASE HELP OUT SPONSORING!
 * dholbach hugs didrocks
 * didrocks hugs dholbach back :) (told you I couldn't last week and that I'll do my shift in a quieter time)
<didrocks> Mirv: hey, around?
<dholbach> didrocks, sure, that's totally fine
<dholbach> it's just that some folks seem to have moved their piloting sessions to "somewhere in the next five years", which seems to have become a problem
<didrocks> dholbach: maybe there is a bug in the FHS symlinking to /dev/null :)
<dholbach> something like that :)
<pitti> dholbach: many missing patch pilot shifts?
<dholbach> unfortunately yes
<dholbach> and what's most depressing is that there are lots of requests in there which are very easy to deal with, so somebody putting in an hour could clear out many of them
<micahg> dholbach: some of us are still slowed by merge proposals
<dholbach> micahg, can you explain?
<micahg> dholbach: any simple thing that has a merge proposal vs debdiff for me multiplies the time needed to handle it
<dholbach> really?
<micahg> yeah
<dholbach> bzr branch A; cd A; bzr merge B; bzr bd -- -S
<dholbach> in a lot of cases that's all you need to do
<micahg> yeah, and then push back up (and possibly a commit or 2 for fixing stuff up)
<dholbach> ah, I often don't push it but let the importer do it :)
<Pelam> I'm at a loss for the best way to offer a patch to mod_auth_mysql package in Ubuntu. Suggestions?
<micahg> dholbach: that kinda defeats the whole purpose of using a VCS IMHO
<dholbach> in any case it gets the patch into Ubuntu - if I do the commit or the importer does it - I'm not sure where the difference is
<dholbach> for me it's a step less
<Pelam> Is this the correct channel for my question?
<Mirv> didrocks: hey
<didrocks> Mirv: hey, look at my question on the font MR
<sladen> Pelam: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+filebug
<sladen> Pelam: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+filebug-advanced
<dholbach> Pelam, yes - either here or #ubuntu-motu
<dholbach> Pelam, you can file a bug, as sladen suggested, then attach your patch and subscribe the 'ubuntu-sponsors' team which will get somebody to take a look at it
<dholbach> alright, I need to rush off to the doctor - see you in a bit
<Pelam> Thanks guys! It's more like a feature so I was hesitant to submit it as a bug :)
<Pelam> Here is a small writeup about the thing: http://stackoverflow.com/questions/12543883/apache-mod-auth-mysql-with-phpass-encrypted-password-wordpress/12543884#12543884
<Pelam> If you are interested ;)
<Pelam> sladen: Sorry, what did dholbach mean with "subscribe the 'ubuntu-sponsors' team"?
<Pelam> Hum... launchpad gave timeout error :(
<didrocks> same here
<didrocks> fixed now
<Pelam> col
<Pelam> cool
<obounaim> Hello everybody
<Pelam> Ah. Now I see, A "subscribe someone else" feature :)
<Pelam> My first patch submitted to Ubuntu project, suggestions welcome: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+bug/1057946
<ubottu> Launchpad bug 1057946 in libapache-mod-auth-mysql (Ubuntu) "A patch to support Phpass hash (Used by Wordpress, phpBB3, etc)" [Undecided,New]
<didrocks> pitti: hey, would you mind rejecting https://code.launchpad.net/~thor-peter/ubuntu/quantal/ftpcopy/bug-305831/+merge/126112 please?
<pitti> done
<didrocks> thanks :)
<Pelam> Hello. Thanks for feedback! I was just in fact looking at submitting the patch to Debian.
<Pelam> Ignore my last message... thought someone was talking about my bug (my name happens to be Peter)
<smb> SpamapS, Not in solving it yet. Seems something with the route cache. But it is slightly complicated.
<didrocks> Mirv: please don't remove the merge proposal :/
<didrocks> Mirv: I had a followup on it
<didrocks> Mirv: you need the Qt version from -proposed
<didrocks> Mirv: can you please repropose it and get the changelog targetting -proposed?
<Mirv> didrocks: ah, sorry, the proposal was not very useful since the libreoffice bug filed is only a part of the larger, old bug
<Mirv> didrocks: and I don't think it's very sensible to change the font without editing the sources, and the sources cannot be edited with free tools alas
<didrocks> Mirv: ok, keep me posted if anything changed in that front
<Mirv> I will, there is some recent action at least now on the old bug
<Laney> is LO still broken with just the qt4-x11 patch?
<didrocks> Mirv: ^ as you tested it (only tested your patched font with qt4-x11 patch and was looking fine in LO)
<Mirv> I didn't test the qt patch at all, only LO with a modified font
<bkerensa> Laney: Sorry about all my trivial MP's
<bkerensa> ;p
<bkerensa> all 22 of them
<didrocks> Laney: you are sponsoring some work from bkerensa? we should maybe coordinate to not overlap :)
<Laney> didrocks: nah, he's responding to my mail on -devel
 * Laney hugs bkerensa :P
<didrocks> ah ok :)
<Laney> will do some sponsoring in a bit though
<Laney> dholbach: cz<tab> tells me you can edit the fridge calendar. Can you update it to reflect our temporary DMB meeting changes please? (8th â 15th and 22nd â 29th, and delete 5th Nov)
<Laney> tumbleweed: ^ is that right?
<dholbach> errrrr
<dholbach> fridge calendar
<dholbach> fridge, yes
<dholbach> but calendar
<dholbach> let me see
<Laney> 28/09 09:46:28 <Laney> who can?
<Laney> 28/09 09:46:46 <czajkowski> dholbach
<Laney> Blame Lauraâ¢
<dholbach> Laney, I'm afraid I can't
<dholbach> I added it to my calendar (j5q85mmi6ujvjtii5s1n3li5io@group.calendar.google.com), but can't edit it
<Laney> ok
<dholbach> you could try asking in #ubuntu-news
<Laney> will do
<dholbach> somebody in there should have the necessary powers, I can only edit the fridge blog
<didrocks> pitti: https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-ubuntu/fix-for-control/+merge/125938 <- reject please :)
<pitti> didrocks: aye sir!
<didrocks> thanks :)
<bkerensa> didrocks: ahh on that one its marked as need brace removed
<bkerensa> my understand if braces are supposed to be removed?
<didrocks> bkerensa: you meant, on https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-partner/fix-for-brace-lists/+merge/125946 ?
<bkerensa> didrocks: correct its on the todo to remove shell braces since they are not supported
<bkerensa> http://lintian.ubuntuwire.org/quantal/tags/brace-expansion-in-debhelper-config-file.html
<bkerensa> ^
<didrocks> bkerensa: oh interesting, i didn't know about this lintian tag :)
<didrocks> bkerensa: ok, so the only issue is that you didn't target the right Vcs-Bzr, please submit on the correct branch :)
<bkerensa> didrocks: it is now re-targeted
<didrocks> bkerensa: hum, I doubt the branch has the same base, did you check?
<bkerensa> didrocks: it will not allow me to MP to the other branch
<didrocks> bkerensa: that happens when the base of the branch isn't the same AFAIK
<didrocks> bkerensa: so you need to branch from the real target branch
<didrocks> put your change in
<bkerensa> >.<
<didrocks> commit
<bkerensa> kk
<didrocks> bkerensa: well, makes sense, it's not a patched file :)
<didrocks> bkerensa: look at Vcs-Bzr always (there are other MR in the same case) ;)
<bkerensa> kk
<bkerensa> didrocks: upstream does not have the issue
<didrocks> bkerensa: Vcs-Bzr is not targetting upstream, it's where the packaging lives officially
<didrocks> if it doesn't have the issue, it means that it's either been fixed recently or that the next upload will fix it :)
<didrocks> (if you are speaking about that above MR ^)
<bkerensa> didrocks: yeah it appears to be fixed recently
<didrocks> excellent! :)
<cousteau> aptitude 0.6.8.1 seems to fix the multiarch bug (I think).  Would it be possible to merge it to quantal and backport it to precise and other versions?
<didrocks> cousteau: if it's a bug fix only release, should be possible for quantal. Care to work on that? :)
<didrocks> cousteau: I don't know the diff between 0.6.6 (precise) and 0.6.8, I think the safest for precise would be to cherry-pick the commit
<Laney> so it turned out the reason the yubikey didn't work with my PC is that I was inserting it the wrong way around ...
<cousteau> bug #831768
<ubottu> Launchpad bug 831768 in aptitude (Ubuntu Oneiric) "aptitude cannot handle conflicts with multiarch enabled" [High,Triaged] https://launchpad.net/bugs/831768
<cousteau> I'm not actually sure 0.6.8.1 does fix the multiarch problem, but it seems so for what I read
<didrocks> cousteau: please try to get the patch in shape and follow https://wiki.ubuntu.com/SponsorshipProcess to get it sponsored
<cousteau> http://packages.debian.org/changelogs/pool/main/a/aptitude/aptitude_0.6.8.1-2/changelog   aptitude (0.6.8.1-1) unstable; urgency=low   * Multi-arch update for the problem resolver:   - handle conflicts without removing all foreign-arch packages (Closes: #672340) (LP: #831768)
<didrocks> (in shape == tested ;)
<ubottu> Launchpad bug 831768 in aptitude (Ubuntu Oneiric) "aptitude cannot handle conflicts with multiarch enabled" [High,Triaged] https://launchpad.net/bugs/831768
<tumbleweed> Laney: can we not find who added the event to the calendar? They can edit it
<cousteau> (p.s. I'm not a developer, but I'll see what I can do)
<Laney> tumbleweed: dunno
<Laney> delegated now
<didrocks> cousteau: thanks :)
<tumbleweed> Laney: :)
<cjwatson> aptitude sponsorship> sponsoring a merge for that package will be way more effort than doing it
<cjwatson> IME
<Laney> apparently it was Cody though
<cousteau> didrocks, anyway I don't think patching/testing is needed since that has already done in debian
<cjwatson> cousteau: I'll have a look at it
<mvo> cjwatson: hi, someone told me about issues with the upgrade and https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1053896/comments/2 is the root cause. any thoughts what we should do ? push the update for ubuntu-keyring into -update real quick? or fix the update-manager in precise to be robust about missing keys (as long as there is a single valid sig)?
<ubottu> Launchpad bug 1053896 in ubuntu-keyring (Ubuntu Precise) "Add new archive key to precise" [Medium,Fix committed]
<cousteau> (0.6.8.1 is already in debian testing)
<hrw> one day I will grep to hunt and kill "Rather than invoking init scripts through /etc/init.d, use the service(8)" message
<cjwatson> mvo: Oh seriously?  Argh
<cousteau> and since aptitude in oneiric/precise is in "Don't use it" state, I think backporting would be a good idea
<cjwatson> cousteau: unfortunately the patch will probably be unSRUably huge
<cjwatson> from previous experience
<cjwatson> so leave that 'til later 'cos thinking about it is just going to slow me down getting it into quantal
<cjwatson> pitti: ^- would you be happy to rubber-stamp a waiver of the usual waiting period for ubuntu-keyring/precise, to unbreak upgrades?
<cjwatson> mvo: and once we do that, will do-release-upgrade force the ubuntu-keyring upgrade first, or do we need some kind of special measures?
<cousteau> ok, I've got to go now, see you
<pitti> cjwatson: I don't have any formal authority about this any more, but this looks fine to me to release now
<pitti> well, TB hat I guess
<pitti> even on a Friday
<cjwatson> TB hat was what I was aiming for :)
<cjwatson> right, it's a serious enough issue that I'm going to do it and apologise later if it bothers somebody, then
<cjwatson> mvo: copied
<pitti> risk/benefit is sufficiently small here IMHO
<cjwatson> we may end up having to revert to a single-signed Release if the problem is still gnarly, although I'd hope not to
<mvo> cjwatson: we should probably add a dependency and do a SRU for update-manager, but there is no trivial way to enforce this I think because it happens before the release upgrader itself is run
<mvo> (or update-manager-core)
<mvo> but let me think a little bit about it
<cjwatson> Wait, this is just for the signature on the upgrade tool itself, right, not the signature on Release?
<mvo> cjwatson: just on the upgrade tool itself
<cjwatson> I could easily change ubuntu-archive-publishing to single-sign the upgrade tool
<mvo> cjwatson: would be a reasonable short term I think
<mvo> cjwatson: what do you think long(er) term? make the release upgrader accept a single sig if another one is missing?
<cjwatson> Yeah, I think it should behave like apt
<mvo> cjwatson: ok, I will work on a fix
<didrocks> cjwatson: python-defaults was uploaded as a native package it seems, was it wanted?
<cjwatson> didrocks: I just matched the previous version
<didrocks> cjwatson: sorry, not sure to get you, you mean that the previous version was also treated as a native package, right?
<cjwatson> yes
<cjwatson> didrocks: looking at http://archive.ubuntu.com/ubuntu/pool/main/p/python-defaults/, it seems to have been consistently native for a long time
<didrocks> cjwatson: ok, continuing that path then until next upstream version I guess :) just checking, thanks!
<didrocks> pitti: https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-ubuntu/fix-for-control/+merge/126892 -> rejected please as it's the branch without the same base we discussed above.
<chrisccoulson> can anyone think why gcc-4.6 in precise would silently ignore the "section" attribute on a global variable, when it works fine with gcc-4.7 in quantal?
<chrisccoulson> oh, never mind, i figured it out
<pitti> didrocks: that URL doesn't exist; I suppose someone already deleted the MP?
<didrocks> seems so
<Laney> tseliot: you might like dh_fixperms for fglrx-installer-*
<tseliot> Laney: nice, thanks, I didn't know it
<doko> zul: test failures in the nova build
<didrocks> dholbach: http://reports.qa.ubuntu.com/reports/sponsoring/ < 100 now (95) ;)
<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 general discussion for 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> mlankhorst, hi
<mlankhorst> heya
<tkamppeter> mlankhorst, can you have a look at bug 1029865? You told in comment #6 that the bug is temporary, but it is still there. Is there any chance for a fix?
<ubottu> Launchpad bug 1029865 in linux (Ubuntu) "Intel HD graphics: Starts always with 1024x768 resolution on a 1920x1080 monitor (HDMI and DisplayPort)" [High,Confirmed] https://launchpad.net/bugs/1029865
<ogra_> didrocks, ergh, patching a conffile from casper and not reverting the patch will cause issues
<mlankhorst> tkamppeter: daniel said it was a hardware quirk and nothing can be done about it
<mlankhorst> if it was a pure sw bug it would have been easy
<cjwatson> ogra_: Why?
<ogra_> cjwatson, it will cause questions on upgrades, no ?
<dholbach> didrocks, YES :)
<cjwatson> ogra_: What upgrades?
<ogra_> +if [ -d /root/etc/gdm ]; then
<ogra_> +    sed -i '/^[UG]ID_MIN/s/\<1000$/ 999/' /root/etc/login.defs
<ogra_> +fi
<cjwatson> ogra_: What upgrades?
<ogra_> cjwatson, release upgrades
<cjwatson> ogra_: In a live session?
<ogra_> erm
<cjwatson> ogra_: Remember that ubiquity copies the squashfs
 * ogra_ blushes and hides somewhere
<cjwatson> ogra_: It doesn't copy the results of casper patching stuff
<cjwatson> Quite deliberately :-)
<ogra_> yeah
<mlankhorst> tkamppeter: there was a different bug that also affected that hardware rthat owuld have been fixable, but in this case it just reports that some connector on vga-1 is found without edid
<tkamppeter> mlankhorst, I have also another new X problem, which appeared after an update some days ago. Sometimes, when I stay away from my PC for longer time and the screen power saving kicks in, I cannot return to my desktop, I get a black screen with only the mouse cursor.
<mlankhorst> which is, sadly, valid
<mlankhorst> tkamppeter: sigh, I'll run a valgrind over it again..
<didrocks> ogra_: you put me in doubt for a sec :-)
<ogra_> sorry
<didrocks> no worry :)
<mlankhorst> tkamppeter: do you know if X is still alive at that point?
<tkamppeter> mlankhorst, you mean the valgrind for the black screen problem?
<mlankhorst> tkamppeter: maybe, do you know if X still runs at that point or not?
<tkamppeter> mlankhorst, is there a way to "blacklist" VGA1? The GPU is part of the CPU and probably there arte motherboards with different plug configurations. Perhaps mine has some kind of "dead circuit" telling to the on-CPU GPU that there is a VGA screen.
<tkamppeter> mlankhorst, unfortunately, I do not have another i5 board here.
<mlankhorst> you had a workaround for blacklisting it..
<mlankhorst> but unfortunately there are a lot of broken displays out there that may not have a valid edid
<tkamppeter> mlankhorst, I tried a workaround, adding video=VGA1:d to the kernel command line, but this did not change anything.
<tkamppeter> For the black screen, X was probably still running, as the mouse cursor was there and I could move it with the mouse.
<mlankhorst> can you file a bug after that happens so all the relevant logs are attached?
<tkamppeter> mlankhorst, according to the display part of GNOME settings my monitor is discovered with its correct product name and native resolution.
<mlankhorst> yeah but if it's mirrored to VGA-1 that would explain it
<tkamppeter> mlankhorst, I get no crash pop-up after restarting the system afterwards. How do I report a bug which automatically attaches the correct files?
<ogra_> stgraber, i was just pointed at bug 50093 (yeah, 6 years old) ... shouldnt bridge-utils just call sysctl from an if-up.d script ?
<ubottu> Launchpad bug 50093 in procps (Ubuntu) "Some sysctl's are ignored on boot" [Low,Confirmed] https://launchpad.net/bugs/50093
<mlankhorst> tkamppeter: apport-bug in command line
<tkamppeter> mlankhorst, can that mirroring be suppressed?
<tkamppeter> mlankhorst, apport-bug with which package name?
<mlankhorst> if you want a fix in Xorg, xrandr --output VGA1 --off; xrandr --output whatever --mode 1920x1080
<mlankhorst> tkamppeter: just xorg
<ev> mpt: http://poppy-dev.local/ - how does the legend look to you?
<ev> hm, not sure why Firefox puts such a massive gap between the groups in the legend
<mpt> ev, "all collected", not "all selected" :-)
<mpt> ev, other than that it looks good
<ev> hah, that's what I get for looking at the d3 api for too long
<ev> thanks
 * pitti hugs didrocks after his piloting shift
<tkamppeter> mlankhorst, and where do I put this command line so that it is used by lightdm?
 * didrocks hugs pitti back
<mlankhorst> erm I tend to override it
<tkamppeter> mlankhorst, what do you mean with that?
<mlankhorst> make /etc/X11/X2, executable
<mlankhorst> put this in:
<mlankhorst> #!/bin/bash
<mlankhorst> exec /usr/bin/valgrind --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -verbose 10 &>> /home/mlankhorst/nfs/vg.$(hostname)
<mlankhorst> then do a symlink from /etc/X11/X to X2
<mlankhorst> the usr/bin/X wrapper hates if /etc/X11/X is not a symlink, or if it's a symlink to a symlink
<mlankhorst> change path and it should be good to go :-)
<mlankhorst> install the -dbg packages too for synaptics, evdev, i915, xserver-xorg-core
<mlankhorst> but it's probably unneeded at this point
<mlankhorst> just something I should do now
<mlankhorst> as verification there are no random crashing bugs in quantal
<tkamppeter> mlankhorst, there are no -dbg packages of synaptics, evdev, i915.
<tkamppeter> mlankhorst, I have followed your instructions. X is now running under valgrind.
<tkamppeter> till@till:~$ ps auxwww | grep valg
<tkamppeter> root      5426 40.3 10.7 998192 870236 tty7    Ss+  13:31   1:07 /usr/bin/valgrind.bin --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg :0 -core -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -verbose 10
<mlankhorst> tkamppeter: you should have -dbg for those
<mlankhorst> at least on quantal
<mlankhorst> I added them to the most common quantal xorg server packages to make debugging a lot easier :-)
<tkamppeter> mlankhorst, I found the dpg packages now.
<tkamppeter> mlankhorst, but there are no packages with i915 in their name in Quantal, probably replaced by xserver-xorg-video-intel.
<mlankhorst> oh right
<tkamppeter> mlankhorst, now I have everything installed, I will do a system update now and then restart the session.
<doko> pitti, ubuntu-drivers-common ping
<pitti> doko: what's up?
<doko> pitti, ftbfs
<pitti> just retry it; slow armel builders FTL
<doko> ScottK, Riddell: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3807395
<pitti> ogra_: oh, so you guys are having fun with the current arm builders as well?
<pitti> ogra_: (just reading platform release report)
<pitti> err, "Foundations"
<ogra_> pitti, you mean webkit ?
<pitti> ogra_: no, qt
<ogra_> pitti, ah, that one, yeah, thats from doko
<doko> pitti, webkit and qt4-x11 are upstream made issues, but yes, there are otheres too.
<doko> e.g. abiword on armhf
<doko> bryceh, https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3844164 could you have a look? it's a package set
<tkamppeter> mlankhorst, now I have everything together, all -dbg packages and valgrinding X.
<mlankhorst> tkamppeter: might be a bit slower but as long as you don't use sw fallbacks you shouldn't notice it much :-)
<tkamppeter> mlankhorst, so now I only need to wait for the black screen appearing again and then attach the log to a bug report?
<mlankhorst> tkamppeter: if something suspicious shows up :-)
<mlankhorst> I need to run valgrind once too, there were a lot of bugs in quantal that could have been caught with it
<mlankhorst> precise*
<doko> pitti, re-opening ubuntu-drivers-common. needs to be addressed for the release, in one way or another
<tkamppeter> mlankhorst, I can see in the log already that my monitor reports a correct EDID, but VGA1 is without EDID at all (no pseudo EDIDE from mobo), perhaps one should dropm interfaces without EDID.
<mlankhorst> tkamppeter: and that is valid too, only windows 7 certified monitors require a valid edid
<mlankhorst> :p
<mlankhorst> iirc
<tkamppeter> mlankhorst, all of display discovery/selection is here: http://paste.ubuntu.com/1247443/
<mlankhorst> tkamppeter: I know but upstream marked it resolved/wontfix so not much i can do about it :(
<ScottK> doko: re avogadro - tons of direct GL calls that aren't going to work on our armhf (it last built on arm* in natty), so that's not happening.
<mlankhorst> unless you can convince upstream it's not a problem on windows i think nothing will happen :\
<doko> ScottK, looked like a float/double/q_float thing again
<ScottK> No, it's GL.
<ScottK> Even if it weren't, fixing whatever it is wouldn't help since the GL issues are still there.
<pitti> doko: well, *shrug*, if that proves anything, it's that our arm builders have a problem
<pitti> doko: I really don't want to disable tests for umpteen packages just because they occasionally fail
<pitti> can't we just retry the build?
<doko> pitti, I can understand it. had retried now three times. let's keep it open until we can address it in some form
<pitti> hm, I guess at last upload we still had the armel builders running on natty's kernel
<ogra_> that must have been long ago then
<ogra_> buildds switched to hf quite a while ago i think
<pitti> well, if "long ago" means "two weeks", then sure
<pitti> 1:0.2.69 was uploaded on September 6
<ogra_> (one or two releases)
<pitti> ogra_: but until recently they were running natty kernels; now they are running precise's and are swapping themselves to death
<ogra_> the kernel should be the same for hf and el
<cjwatson> not that long
<cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=51115
<ogra_> it should just use different chroots
<pitti> ogra_: yes, it is
<pitti> ogra_: and armel and -hf also have the same problems in e. g. glib
<ogra_> hmm
<pitti> it's pure luck that u-d-common failed on one and succeeded on the other
<cjwatson> in fact that indicates nihal is still on a natty kernel (as of that last update anyway)
<cjwatson> though the referenced ticket number is wrong
<ogra_> i know ppisati's last merge fixed a ton of issues with power management (or rather cpufreq), i wonder if we could switch to a quantal kernel for them
<ogra_> pitti, did you do a testbuild on a quantal panda locally by chance ?
<pitti> ogra_: no, but I can try one
 * pitti powers up his board
<Daviey> pitti: you know you have access to porter boxes? Are they no good?
<pitti> oh, scheat is back?
<pitti> indeed
<ogra_> Daviey, they will very likely use the same kernel as the buildds
<pitti> still, time to update my panda board
<ogra_> wont help much for checking if its a kernel issue :)
<pitti> scheat is running 2.6.38
<pitti> i. e. natty kernel
<ogra_> ugh !
<pitti> so I'll test build on my panda with the quantal one
 * pitti dist-upgrades first, that'll take a bit
<stgraber> ogra_: I think we need to get sysctl to run whenever we get network-device-added, though it's something we need to think about carefully and not rush into a release...
<stgraber> jodh might have an opinion on that as IIRC he's touched-it-last on procps :)
<ogra_> stgraber, yeah, i didnt mean to rush or anything it just made me feel bad that such a bug is open since 2006
<ogra_> and it would be easy to work around it from bridge-utils until a proper fix is in upstart/procps
<ogra_> for a proper fix upstart shoudl just emit a bridged-network-up event or some such that could be added to porcps.conf
 * ogra_ glares at his fingers
<stgraber> ogra_: udev will send a network-device-added even, so "start on ... or network-device-added" and have it run in "instance" mode would do the trick
<ogra_> ah, procps already has network device event code, but restricts that to static i think
<stgraber> well, procps start condition would work with bridges if it wasn't for the "or virtual-filesystems" part
<ogra_> yeah
<stgraber> as virtual-filesystems is usually emitted before static-network-up
<stgraber> if it was just "start on static-network-up", it'd most likely work fine with bridges, though it may break other things as it'd likely be starting much later on most systems
<stgraber> one of those things is the ipv6 privext key that we usually like to have set as early as possible (before bringing up the network)
<stgraber> so I think the way forward is going to be to apply sysctl once very early (start on virtual-filesystems), then once per interface (using instance + start on network-device-added) and possibly also once per kernel module load (if we can get an event for that somehow)
<stgraber> that should cover all the cases I can think of
<cjwatson> Daviey,jamespage: so, update on bug 1050595: I've successfully done a 128M install by forcing lowmem mode; but I also had to delete vga=788 from the command line, otherwise lowmem mode just booted to a blank screen.  I've uploaded a tweak to lowmem to avoid that problem by leaving the framebuffer enabled with vga=*, but an enabled framebuffer uses more memory, so I'm going to have to wait until I get that fix landed and in ...
<ubottu> Launchpad bug 1050595 in lowmem (Ubuntu Quantal) "Ubuntu Server installation with 128M ram hangs" [High,In progress] https://launchpad.net/bugs/1050595
<ogra_> having 2 upstart jobs ?
<cjwatson> ... images before I can get true memory measurements
<stgraber> ogra_: that or a single job using the "instance" feature of upstart (like we do in network-interface.conf)
<ogra_> ah
<stgraber> @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 general discussion for 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: stgraber
<jodh> stgraber/ogra_: kernel modules + network interface should cover it. That said, potentially running sysctl every time a module gets loaded seems pretty extreme. Ideally, we'd have a way to calculate the optimal number of invocations and the point at which we need to make the calls. See https://bugs.launchpad.net/ubuntu/+source/procps/+bug/771372/comments/4 suggestion point (4) for some thoughts.
<ubottu> Launchpad bug 771372 in procps (Ubuntu Oneiric) "procps runs too early in the boot process" [Medium,Fix committed]
<ogra_> jodh, how about making bug 50093 a dup of that one ? ;)
<ubottu> Launchpad bug 50093 in procps (Ubuntu) "Some sysctl's are ignored on boot" [Low,Confirmed] https://launchpad.net/bugs/50093
<ogra_> its confirmed since 2006
<stgraber> tkamppeter: hey there. I'm reviewing http://launchpadlibrarian.net/117644201/brother-lpr-drivers-common_1.0.0-4-0ubuntu2_1.0.0-4-0ubuntu3.diff.gz in the queue for quantal. That one isn't linked to a bug and I don't know the uploader so I'd just like to check with you that this change should indeed work and won't somehow break the resulting binaries.
<tkamppeter> stgraber, there was nothing done on these Brother driver packages for years as the volunteer who originally made them went away/
<jodh> ogra_: done.
<doko> jamespage, is there still something to do about the java byte code format in main?
<ogra_> jodh, i bet you have made a bunch of waiting people happy now :)
<jamespage> doko, one thing I think - apport
<tkamppeter> stgraber, the debdiff is harmless, only assuring to build under Quantal, you can let it pass. By the way, the author of the patch is not the original author of these packages.
<doko> pitti, ^^^ apport & java byte code format
<pitti> doko: sorry, what?
<stgraber> tkamppeter: ok, thanks
<doko> pitti: when compiling java files, use -source 1.5 explicitly
<pitti> oh, can do; just add that as an option?
<pitti>         subprocess.check_call(['javac'] + glob('com/ubuntu/apport/*.java'))
<pitti> i. e. ['javac', '-source', '1.5'] ?
<doko> yes, should work
<pitti> doko: ok, builds and java tests succeed; committing to trunk, thanks
<pitti> doko: OOI, does something break right now?
<pitti> I wasn't even aware that anyone used those
<doko> pitti: only if somebody tries to run these files using openjdk-6
<doko> pitti: ubuntu-drivers-common fails for me locally too in the testsuite, but in other places
<pitti> doko: dist-upgrade still running for me, I'll try on my panda after that
<pitti> doko: are you running on precise or quantal?
<doko> pitti, precise kernel, quantal chroot
<doko> pitti: http://paste.ubuntu.com/1247527/
<ogra_> that looks like missing b-deps
<ogra_> at least the first two
<pitti> right, missing aptdaemon and m-i-t?
<ogra_> yeah
<doko> m-i-t?
<ogra_> module-init-tools
<pitti> apt-get build-dep ubuntu-drivers-common should help?
<ogra_> (modinfo)
<doko> hmm, both are installed ...
<hallyn> can anyone tell me why https://code.launchpad.net/~kampka/ubuntu/quantal/lxc/upstart-instance/+merge/123995 shows up in sponsor report?  id ont' see ubuntu-sponsor subscribed...
<doko> urgh, /usr/sbin not in the path in the chroot
<ogra_> lovely
<stgraber> hallyn: all branches proposed for merging show up on it
<doko> pitti: ok, builds here locally
<hallyn> stgraber: so how does one take it off that report?
<stgraber> hallyn: its status needs to be changed
<jamespage> pitti, needs a "-target 1.5" as well - sorry was OTP
<pitti> jamespage: oh, why do we need both?
<stgraber> hallyn: though in this case I think its status is still fine as it hasn't been uploaded yet
<jamespage> pitti, technically for apport you only need -target
<doko> jamespage, wasn't -source implying -target?
<jamespage> doko, nope - the other way around
<pitti> jamespage: right, I was just going to ask -- the source is compatible with earlier releases anyway
<doko> ahh, my bad
<jamespage> at least I think so
<pitti> so, changing to -target
<pitti> yeah, -target implying -source makes more sense
<jamespage> pitti, there is an experiemtnal lintian check which detects bad bytecode versions
<pitti> jamespage, doko: pushed to trunk
<doko> jamespage, can we make this check the default for quantal?
<jamespage> doko, I guess we probably can - lintian is not a package that we normally delta
<jamespage> but this is a key difference between ubuntu and debian
<doko> I'll have a look
<tumbleweed> then it can go into the ubuntu profile?
<doko> ?
<tumbleweed> lintian knows about distro-specific checks these days
<jamespage> tumbleweed, that would be great
<doko> tumbleweed, how do I disable the experimental tag there?
<SpamapS> smb: thanks for the response. If you need any help reproducing or testing a fix, I'm happy to help
<smb> SpamapS, np. Oh reproduction is not really the issue with Stephane's little program. Just understanding around which of the many corners of the network stack things might be wrong.
<SpamapS> smb: I wonder if precise's kernel works on quantal...
<smb> SpamapS, To a certain degree, yes. Though you can end up in a bad state when a driver needs firmware from the firmware package which has been dropped in Q
<mpt> ev, pitti: apport is using ~98% CPU on my machine, and has been for several minutes, though it didn't present me any errors. Anything I can do to report the problem usefully?
<ev> mpt: be right over
<Laney> doko: qt4-x11 configures with -no-webkit
<Laney> does it still somehow use it or?
<doko> looking at the build log ...
<Laney> seems not from what I can see
<doko> at least I see -I../include/QtWebKit all over the place
<doko> but there is long running link step in the build. wondering which one this is
<doko> the biggest shared lib is libQtGui
<tumbleweed> doko: no idea. It may be possible to override Experimental: no in the profile
<doko> tumbleweed, well, I'll let this for others, just uploading what works for me, and maybe can be reverted later
<tumbleweed> :)
<mpt> ev, reported bug 1058158 and bug 1058160
<Laney> doko: well, I can do an upload with -gstabs on armel armhf to canonical-arm-dev PPA and we can see, if you like?
<ubottu> Launchpad bug 1058158 in apport (Ubuntu) "Apport can peg CPU for minutes while processing crash report" [Undecided,New] https://launchpad.net/bugs/1058158
<ubottu> Launchpad bug 1058160 in apport (Ubuntu) "May be several minutes between crash and error message" [Undecided,New] https://launchpad.net/bugs/1058160
<mpt> please correct my mistakes
<doko> Laney, sure. are there other packages in the PPA, which would prevent copying the binaries to the main archive?
<Laney> no idea
<Laney> if you have some other devirt ppa we can put it there instead
<doko> I could use the ubuntu-toolchain-r ppa. could you prepare the upload?
<Laney> actually it looks OK
<Laney> there's only been 4 Quantal uploads and they're all superseded by the main archive
<micahg> doko: is a 5hr timeout enough on arm*?  it used to be 12+
<ogra_> 12h ?
<ogra_> when
<ogra_> iirc it was always something like 150min (2.5h)
<doko> micahg, I ran the webkit link step, and it was 2.5h. however larger timeouts apparently hurt the virtualized buildds, so launchpad-ops don't want to increase it even more
<ogra_> well, lookin at Laney'S issue the virtualized buildds are not really reliable anyway
<micahg> ogra_: it was 2.5hr on x86, 800 min (12hr+) on arm*
<ogra_> oh, wow, when was that set so high ? i definitely remember giving back packages in precise that failed with a 150min message
<micahg> before the pandas I guess
<ogra_> nah
<micahg> yeah :)
 * ogra_ would like to hear lamont for that ... i'm 100 positive we had several 150min issues in precise
<ogra_> *100%
<seb128> it's crazy how you get 300 updates the day after beta2
 * seb128 upgrade 
<smoser> is there some more correct way to copy something from quantal to a ppa for precise other than building source package?
<smoser> ideally i'd like to copy binaries from quantal to my ppa
<micahg> smoser: I would think it depends if the binary dependencies are met in precise or not (usually stuff is copied forward though)
<cjwatson> You can use copy-package to do that
<cjwatson> lp:ubuntu-archive-tools
<smoser> micahg, well launchpad in ui for ppa copy alows you to copy binaries. i'm just asking to do the same thing ,but from official-archive -> ppa rather than ppa -> ppa
<cjwatson> copy-package -s quantal --to-ppa=smoser --to-ppa-name=blah --to-suite=precise <package name>
<smoser> cjwatson, thanks. that is exactly what i wanted.
<cjwatson> (source package name, that is)
<micahg> smoser: right, but what I'm saying is it might not work (the binaries that is):)
<cjwatson> smoser: oh
<cjwatson> smoser: add -b
<smoser> micahg, well of course.
<cjwatson> otherwise it will rebuild the binaries in your PPA
<smoser> but copying forward doesn't necessarily work either
<smoser> (i cna't have it rebuild because i need arm binaries)
<smoser> so, yeah, thanks.
<cjwatson> I don't know whether it will copy binaries for an architecture not enabled in your PPA ...
 * Laney blinks at qt4-x11
<smoser> hm..
<Laney> *how* long to build a source package?
<smoser> well, i'll see.
<smoser> cjwatson, that did coyp binaries.
<smoser> thanks. that is wonderful.
<doko> didrocks, any bogofilter news?
<cjwatson> smoser: Good stuff.
<didrocks> doko: cyphermox is looking at it AFAIK, was waiting for his feedback
<cyphermox> oh, oops
<cjwatson> smoser: FWIW, if you do find yourself using the web UI, it'll be improved by joining launchpad-beta-testers.  See https://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies
<cyphermox> doko: didrocks: I have no opinion really on which is better, but if the issue is that we'd like to avoid having two filters in main I can just flip the alternate  Recommends to have spamassassin first
<cyphermox> I'm going to have to do an upload of evo again soon for some fixes
<doko> ok, then demoting bogofilter
<stgraber> fabo: ping
<stgraber> fabo: I'm trying to understand bug 1030588 and the matching merge proposals. My understanding is that quantal got a new qemu-linaro which includes that bugfix and it simply wasn't closed, is that correct?
<ubottu> Launchpad bug 1030588 in qemu-linaro (Ubuntu Quantal) "[FFE] support emulated systems w/ > 2G of memory" [Undecided,Triaged] https://launchpad.net/bugs/1030588
 * fabo looks
<ogra_> looks like its highbank only
<fabo> stgraber: that's correct, 1.2.0-2012.09-0ubuntu1 has been uploaded. it closes 1030588 and 1030594
<cyphermox> doko: ok; I'll upload evo with the change in a few hours at most, just finishing up and cleaning up a patch
<stgraber> fabo: ok, I'll clean them up then. thanks for checking
<fabo> stgraber: thanks
<dholbach> can somebody please reject https://code.launchpad.net/~obounaim/ubuntu/quantal/z3c.form/adding-homepage/+merge/125318?
<mvo> stgraber: heh, was just looking at that too :)
<mvo> fabo: should this go to precise-proposed as well?
<bdmurray> doko: apport will now gather pythonhome and pythonpath
<doko> Laney, so this make fix looks fine for me, even if the solution is not the preferred one by upstream. we can assume that we use compliant shells (dash, bash, zsh) in main at least
<stgraber> dholbach: done
<dholbach> thanks
<doko> bdmurray, in quantal?
<Laney> doko: OK then
<Laney> I'll see if I get armel building locally then we can upload them both at once
<bdmurray> doko: yes, it'd be easy to SRU if you think its a good idea
<doko> bdmurray, maybe not yet. so it is now used to collect the duplicates? there was one more comment I did see, that even after replacing the lsb_release implementation, this kind of error was still seen with the vmware installers
<fabo> mvo: it will be nice, yes.
<mvo> fabo: ok, uploaded
<bdmurray> doko: no its not used in duplicate detection, just gathered in the bug details
<lamont> ogra_: the extreme timeout for armel was bbg3 timeframe
<lamont> ogra_: it should be set to something more sane these days, IMO
<ogra_> lamont, weird
<fabo> mvo: thanks!
<cjwatson> dholbach: I think it would be a good time to stop encouraging people to upload trivial changes to quantal, FWIW, if you haven't already
<cjwatson> dholbach: We're now frozen until release, and release team bandwidth for reviews is limited
<dholbach> gotcha
<dpb___> I have a package this is being removed by dist-upgrade.  Is there a way to have it tell me *why* it wants to remove it?
<cjwatson> -o Debug::pkgProblemResolver=1 may help
<cjwatson> the output can be ... novel to read
<dpb___> cjwatson: excellent, now to translate into human
<dpb___> cjwatson: thx!
<doko> mterry, I had already done the review for pam-xdg. just wanted to have the ack from the security team
<mterry> doko, oh missed that in the comments.  Awesome
<doko> mterry, yeah sorry, just in the release meeting
<micahg> Laney: re webkit, if 1.10 doesn't work out, 1.8.3 builds fine on quantal :)
 * micahg will even help with rebuilds...
<Laney> heh
<Laney> el panda is installing the BDs now
<Laney> I suspect this will be a full weekend build, or close enough
<micahg> oh, is it just the pandas now, hrm, haven't tested that yet
<Laney> we have all builds except armel
<Laney> but the suspicion there is that it was busted because virt
<stgraber> xnox: any progress on: https://code.launchpad.net/~abone/ubuntu/precise/console-setup/fix-433897/+merge/118886 ?
<cjwatson> bug 1057485 - "QString is latin-1 by default" - seriously?  what decade is it again?
<ubottu> Launchpad bug 1057485 in ubiquity (Ubuntu Quantal) "ubiquity-kde codepage problem in Timezone map (Timezone.py)" [High,Triaged] https://launchpad.net/bugs/1057485
<cjwatson> stgraber,xnox: I'd like to review that, please
<cjwatson> I haven't had time to think about it yet
<stgraber> cjwatson: ok, added you as reviewer
<cjwatson> right, I commented too
<stgraber> infinity: any chance you can look at bug 1000498 for quantal?
<ubottu> Launchpad bug 1000498 in eglibc (Ubuntu Quantal) "fmod() incorrectly returns NaN for (some?) denormalized inputs" [Medium,In progress] https://launchpad.net/bugs/1000498
<xnox> stgraber: I did initial review of the branch, but cjwatson has the bug assigned and voice disagreement with the proposed solution.
<cjwatson> Not so much disagreement as wariness born of past pain
<cjwatson> It took me at least a week to work out all the constraints on that code
<doko> afk now, back later tonight
<infinity> stgraber: Looking.
<infinity> stgraber: Grr, I wish I'd noticed that when I did the last eglibc SRU.  Oh well.
<stgraber> infinity: it's been on the sponsoring report for quite a long time apparently (I'm trying to clear as many "red" entries as possible)
<infinity> stgraber: Yeah, I might just be blind. :P
<infinity> stgraber: I'll cross-reference with upstream commits (I remember carlos bitching about something related to this, so there may be more fixes), and upload something backporty.
<stgraber> infinity: cool, thanks
<toabctl> pitti, one memleak I recognized with the d-feet port is documented here: https://bugs.launchpad.net/ubuntu/+source/overlay-scrollbar/+bug/1058205
<ubottu> Launchpad bug 1058205 in overlay-scrollbar (Ubuntu) "Memory leak" [Undecided,New]
<roaksoax> Howdy! I was wondering how can we avoid asking user input to replace a config file, when dist-upgrading a package?
<infinity> roaksoax: By not changing conffiles.
<infinity> roaksoax: If a user changed a conffile, you *want* the prompt, overwriting their changes is bad.
<infinity> roaksoax: If a package/script changed a conffile, that's a bug.
<sarnold> infinity: .. the other option is leaving their conf in place without a prompt..
<infinity> sarnold: If the user wants that behaviour, they can set that up.
<cjwatson> sarnold: That can easily create bugs if the package side of the change to the conffile is necessary.
<cjwatson> Never-overwrite is just as wrong as always-overwrite - it just fails in different situations.
<sarnold> cjwatson: indeed ;) but most developers try to provide some modicum of backwards-compat most of the time
<cjwatson> This is why Debian policy is painfully explicit that packages must never edit conffiles.
<roaksoax> infinity: right, in this particular case we need to change the conffile (in packaging, I know, it is not pretty), so on every upgrade, if upstream conffile has changed, we need to not ask the question and do as required
<cjwatson> (I mean, other than by changing the shipped version.)
<cjwatson> roaksoax: There isn't a workaround for this other than having it not be a conffile.
<sarnold> roaksoax: see 'confold' in dpkg(1)
<infinity> roaksoax: Erm, either you're wildly violating policy, or I'm misunderestanding what you're doing.
<cjwatson> This is a bit of Debian policy that is there for a very very very good reason.
<roaksoax> sarnold: thanks.
<cjwatson> sarnold: There's no way for a package to set that just for itself.  You can only control it for the entire upgrade.
<cjwatson> Which may be fine in some special cases, but you can't mandate its use.
<sarnold> cjwatson: that's perfectly fine :)
<infinity> ...?
<infinity> Fine in what sense?
<cjwatson> If this is a cloud image or something where you control the upgrade process, you may be able to get away with it.
<roaksoax> cjwatson: uhmm right, I think that treating those those files as conffig files for packaging would be a better idea then
<cjwatson> But otherwise it definitey isn't fine, indeed.
<cjwatson> *definitely
<sarnold> infinity: I mean 'fine' in the sense that if a user is tired of being prompted, they can tell the upgrade process to leave them alone and clean up the breakage later, if they please.
<roaksoax> infinity: again, this is a very special case
<roaksoax> Daviey: ^^
<cjwatson> sarnold: Debian regards mishandling of conffiles in this way as a release-critical bug, and we should too.
<infinity> roaksoax: What's exactly happening here?  Are you shipping conffiles that change from time to time (common thing to do), and users are also constantly changing them?
<infinity> sarnold: Yes, true, but not something one should recommend to a user either, and roaksoax was looking for a solution for his package, not a solution as a user.
<roaksoax> infinity: the particular case is that on installation, MAAS needs to atomatically do things (such as create passwords) and modify config files in order for this to work out of the box
<cjwatson> You need to fight really very hard for it not to need to change conffiles.
<roaksoax> infinity: so whenever upstream changes the config file in some way, it prompts for user action in upgrade (becuase the config file has been modified by the .postinst file)
<cjwatson> Otherwise it will absolutely bite you later and you will regret it.
<infinity> roaksoax: Right, okay.  So the scripts themselves are mangling the files.  Then yes, those should NOT be conffiles, or you need non-conffile conf.d mechanisms or something for the bits that change.
<sarnold> infinity: "looking for a solution for his package" is an important piece of the puzzle :)
<infinity> roaksoax: It's a blatant policy violation to have non-users editing conffiles, which is where your problem lies.
<roaksoax> infinity: right, so given the lack of conf.d/ I guess that the best approach is not treat them as conffiles.
<cjwatson> Or add .d support to the relevant packages.
<roaksoax> infinity: I agree, but in this particular case was a must do to make things "just" work as required
<cjwatson> That's not likely to be harder than treating them as non-conffiles.  It will depend on the situation.
<roaksoax> cjwatson: i'll raise that upstream!
<cjwatson> roaksoax: Not mishandling conffiles is a "must do".
<cjwatson> I realise this is frequently misunderstood, probably because it only bites people six months later.  But it is a false economy to skimp on this.
<infinity> roaksoax: Treating them as non-conffiles ends up with a whole new set of issues, such that you need to either employ fancy things like ucf, or be VERY CAREFUL about how you update the files to not overwrite user changes.
<infinity> roaksoax: So, yes, conf.d type stuff tends to be a cleaner and easier way to do things like "include 3 small config snippets".
<roaksoax> i agree
<stgraber> slangasek: you have a few changes in ubuntu:nfs-utils that haven't been uploaded yet. Are you planning an upload? I'm looking at bug 794112 and wondering if I should upload or just stack add it to what you have in the branch and let you upload
<ubottu> Launchpad bug 794112 in linux (Ubuntu Precise) "Kerberos + LDAP + NFSv4 - Unable to recover unattended client" [High,In progress] https://launchpad.net/bugs/794112
<cjwatson> .d support is usually easy to patch in even if upstream is uninterested
<cjwatson> Depending on the exact configuration semantics I suppose
<roaksoax> cjwatson: the problme is that some of those "conffiles" are .py as they are django config files
<cjwatson> That should be pretty easy to support, then, given the long tradition of monkey-patching in Python.
<infinity> Even doing something sketchy like 'run-parts --list | xargs cat' can give you a ghetto .d implementation, if you're not up for doing it in a shiny way.
<Daviey> we can do .d for that... I have a specific example that should help.
<infinity> Oh, and while I said that, you mentioned python, so yeah, better ways to do that. :P
<roaksoax> awesome then
<roaksoax> can anyone please link me to examples?
<infinity> roaksoax: It's also entirely possible that some of them shouldn't be conffiles (or config files) at all, don't belong in /etc, and should be in /usr/share, with a simple fopen() to /etc/package/passwordfile.
<infinity> (I don't know this to be true, but it may well be)
<xnox> roaksoax: Daviey: wasn't there even package created `dotdee` that does this conffile handling despite upstream not supporting .d dirs. And as far as remember juju doesn't something along the lines like that for e.g. hadoop charm.
<Daviey> roaksoax: I didn't actually ever upload this.. but i created a .d named settings_override. https://launchpad.net/~davewalker/+archive/cobbler-testing/+packages
<Daviey> roaksoax: The deal was, that if you had an extra package installed, it added to the settings_override, and it was picked up at run time.
<xnox> and the situation is not dissimilar. juju tries to make hadoop to work out of the box, by modifying conffiles yet managing the whole process to make it automatic on upgrades.
<roaksoax> infinity: yeah that's other approach I considered (sourcing /etc/package/passwordfile)
<roaksoax> Daviey: cool I'll take a look
<Daviey> roaksoax: anything in the .d is considering a django settings file to append... via __init__.py loading.
<roaksoax> Daviey: cool
<roaksoax> infinity: cjwatson sarnold thank you for the enlightment :)
<slangasek> stgraber: those nfs-utils changes were dependent on mountall 2.41, which just went in post-beta; they should all be ok to upload now
<stgraber> slangasek: ok, I'll apply the fix from bug 794112, test build and upload it to the archive then
<ubottu> Launchpad bug 794112 in linux (Ubuntu Precise) "Kerberos + LDAP + NFSv4 - Unable to recover unattended client" [High,In progress] https://launchpad.net/bugs/794112
<barry> tumbleweed: do you have any other information on bug 1031882?  i need to get a vm up and running to test upgrades in en_ZA, but i thought i'd take a look at that today
<ubottu> Launchpad bug 1031882 in ubuntu-release-upgrader (Ubuntu Quantal) "precise->quantal upgrade fails, with a UnicodeDecodeError" [High,Confirmed] https://launchpad.net/bugs/1031882
 * cjwatson discovers that, if you generate a new locale, you can't load it from any process that has previously called setlocale
<cjwatson> I wonder how inconvenient that's going to be here ...
<barry> cjwatson: do you mean wrt bug 1031882?
<ubottu> Launchpad bug 1031882 in ubuntu-release-upgrader (Ubuntu Quantal) "precise->quantal upgrade fails, with a UnicodeDecodeError" [High,Confirmed] https://launchpad.net/bugs/1031882
<cjwatson> No, wrt bug 644736
<ubottu> Launchpad bug 644736 in ubiquity (Ubuntu Quantal) "Messages from apt in install_progress_text are not localised" [Medium,Triaged] https://launchpad.net/bugs/644736
<cjwatson> It should work OK if you don't try to put them in the locale-archive
<cjwatson> So I think I'll have to do some fiddling to arrange for that
<hallyn> @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 general discussion for 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: stgraber, h
<stgraber> hallyn: looks like you'll be called "h" today, not enough characters for you :)
<hallyn> yoyoyo, i be down wit dat
* infinity 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: stgraber, hallyn
<smoser> any python smarties want to help
<smoser> http://paste.ubuntu.com/1248087/ , when run results in http://paste.ubuntu.com/1248086/
<mitya57> we can remove one more character
<smoser> basically, yaml.safe_load() wont let me load python_unicode types , but i kind of need to.
* mitya57 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: stgraber, hallyn
<hallyn> oh - mvo are you working on the SRU for bug 1030594 ?
<ubottu> Launchpad bug 1030594 in qemu-linaro (Ubuntu Precise) "[FFE] enable flat device tree support" [Medium,In progress] https://launchpad.net/bugs/1030594
<hallyn> (i notice you changed the status for precise, but didn't take ownership)
<hallyn> hm.
<stgraber> hallyn: yeah, it's been uploaded. I thought I remove -sponsors from it, maybe not...
<stgraber> fixed
<hallyn> stgraber: that was for q though?  or p?
<hallyn> hm ok.  cool  :)  thx
<stgraber> it was pushed to Q a few weeks ago and mvo uploaded to P 2 hours ago
<trism> smoser: http://stackoverflow.com/questions/9169025/how-can-i-add-a-python-tuple-to-a-yaml-file-using-pyyaml (first answer looks about right)
<smoser> trism, awesome.
<smoser> thank you.
<ppetraki> hi all, I'm prepping a submission for per package uploaders rights for multipath-tools and was wondering if it made sense to also propose a delegated team for low level storage packages that have  dependencies?
<micahg> ppetraki: hrm, well, I would guess that most of those packages are in core, depending on how sufficiently different the packaging between them are, it might just warrant being core-dev
<hallyn> micahg: core-dev brings to mind all the x packaging and such too, though.
<hallyn> nothig really wrong with getting PPU to each of the packages ppetraki listed, but a package set does seem to make sense  <shrug>
<slangasek> what are "each of the packages"?
<ppetraki> yeah, they're all in main now, mp used to be in universe
<micahg> hallyn: yeah, well, the idea with core-dev is you know what you do and don't know and are sufficently trusted to ask when you're not in your comfort zone
<ppetraki> once you start touching device mapper, the skills start to cross-over quick
<hallyn> ppetraki: can you spell out thep ackage list?
<micahg> aside from select individuals most core-devs have an area of specialty
<hallyn> makes sense,
<hallyn> still i for one have been afraid to ask for core-dev, it's still intimidating...
<ppetraki> hallyn, multipath-tools, lvm2, dmsetup at a minimum, kpartx can effect them
<hallyn> ppetraki: that *is* smaller than the first set of packages i asked for PPU for.  (but still a package set seems to make sense)
<ppetraki> hallyn, which is why I bring up the delegated team concept, akin to the Debian LVM team
<micahg> ppetraki: I also only see one round of uploads for you with multipath-tools which didn't include any interaction with the package from Debian
<slangasek> lvm2 gets deep into udev, initramfs, has a massive delta to manage from Debian; I would hope the DMB would not grant PPU/packageset upload rights to lvm2 to someone that they weren't also comfortable making a core-dev
<ppetraki> micahg, there's at least one for mp, some of my initial work went through hallyn iirc
<micahg> right, hence my previous comment :)
<slangasek> (oh, touches the installer too)
<ppetraki> I could stay out of lvm2 then, simply would need to stay in touch
<micahg> ppetraki: you're free to contribute to anything through sponsors :)
<ppetraki> micahg, that's thing, I've taxed hallyn alot for that for multipath-tools and would like to pull my own weight there
<hallyn> tjaalton: bug 1054095, just curious, you marked it fix committed - where is it committed?
<ubottu> Launchpad bug 1054095 in terminator (Ubuntu) "Sync terminator 0.96-2 (universe) from Debian unstable (main)" [Undecided,Fix committed] https://launchpad.net/bugs/1054095
<ppetraki> I suppose just multipath-tools rights is fine "Per-package Uploaders"
<micahg> ppetraki: well, I don't see anything aside from 3 changelog entries, not sure why hallyn didn't credit you in some way in the changelog (even if not having a signature)
<ppetraki> micahg, I really don't focus on credit :)
<micahg> ppetraki: of course, but we need some type of trail to evaluate your work :)
<hallyn> jinkeys, big apologies if i did that
<ppetraki> I'm essentially the defaco expert on SAN and low level kernel storage
<ppetraki> micahg, I have character witnesses :)
<micahg> ppetraki: have you ever merged the package from Debian?
<ppetraki> micahg, no
<hallyn> ppetraki: i think a PPU for multiptah-tools would be a nobrainer for you.
<hallyn> maybe when r opens you do the sponsored merge , and then apply for PPU?
<ppetraki> micahg, we actually moved away from even trying to stay synced with them as it was so far out of date that it just did more harm than good, thats why we migrated from 0.4.8 to 0.4.9
<micahg> hallyn: ppetraki: well, if you two can construct a paper trail, the next meeting with available slots for applications is at UDS
<ppetraki> micahg, I can take that action
<micahg> ppetraki: Debian is on 0.4.9 now as well
<hallyn> ppetraki: if there are specific commits you need to get sponsored in the meantime, it's good to discuss them here and get some varied sponsors so they can also +1 you at the PPU discussion
<micahg> hallyn: +1 :)
<ppetraki> micahg, iirc at the time we leap forward they were still on 0.4.8
<ppetraki> micahg, I agree though, we could do better in working together for sure
<micahg> ppetraki: it happens
<micahg> ppetraki: well, from the community side of things, we prefer work to be done in Debian as that means less duplicated efforts which allows all parties involved to accomplish more
<ppetraki> micahg, agreed
<tjaalton> hallyn: i synced it, still on the queue i think
<hallyn> tjaalton: ok, thanks.
<micahg> hallyn: zul: 0.10.0-1fakesync1ubuntu1 would've been fine as 0.10.0-1ubuntu1 :)
<stgraber> micahg: oh indeed, well too late, I accepted it already :)
<hallyn> micahg: oh, i see.  that makes sense, since it's no longer a sync
<hallyn> thanks
 * hallyn feels silly
<stgraber> hallyn: that's fine, the changelog entry will disappear with the next sync anyway ;)
<hallyn> stgraber: so if there is another one, should i call it 0.10.0-1ubuntu2?  or ubuntu1?
<stgraber> good question ;) I think you should go with ubuntu2 to make it clearer that it's the second ubuntu change
<stgraber> technically ubuntu1 would be fine (as it's higher than the current version) but it'd look confusing
<hallyn> (would have been my guess :)  thanks
<stgraber> @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: hallyn
<BenC> Is there some problem I'm unaware of with blueprints? When I try to create one it keeps telling me that the "Information Type" is required when I clearly have it set as Public
<BenC> Nevermind, I had to select as private and then back to public and it let it go
<stgraber> SpamapS: speaking of juju and lxc, any change you can get bug 996358 on the roadmap?
<ubottu> Launchpad bug 996358 in juju (Ubuntu) "juju probably should be using lxcbr0 instead of depending on libvirt-bin and using virbr0" [Low,Confirmed] https://launchpad.net/bugs/996358
<hallyn> stgraber: smb: so the netns refcoutn bug, ...  outlook not so good?
<hallyn> Could someone who is motu consider sponsoring the debdiff on bug 1054274 ?  it fixes systemtap in quantal.
<ubottu> Launchpad bug 1054274 in systemtap (Ubuntu Quantal) " stap fails with "error: âcpu_possible_mapâ undeclared" in function â_stp_stat_getâ" [High,In progress] https://launchpad.net/bugs/1054274
<hallyn> kees: ^ you <3 systemtap right? :)
<micahg> hallyn: that's a little more than I want to parse on 2.5 hours of sleep
<micahg> hrm, if there were no reverse dependencies, I'd suggest an FFe for 1.8...
<nfirvine> Hi all, I'm packaging MATLAB for internal distribution for my organization.  Is this a good channel for help?
<xnox> slangasek: you have rdeps =) bug 1058211
<ubottu> Launchpad bug 1058211 in weston (Ubuntu) "Add "recommends" for libpam-xdg-support" [Undecided,In progress] https://launchpad.net/bugs/1058211
<slangasek> xnox: well, preferably not; this should be seeded as part of ubuntu-desktop, and weston itself should fall back to $something_sensible if te path isn't set.
<hallyn> micahg: though debian doesn't have 1.8 :(
<xnox> slangasek: that's my though as well. Can you please comment on the bug and/or reject merge proposal?
<kees> hallyn: I love it, yes, but don't use it much.
<slangasek> xnox: sure
<xnox> slangasek: will libpam-xdg-support be seeded in quantal?
<hallyn> kees: drat - ok, thx
<slangasek> xnox: that's the intent, but there's a licensing tweak to be sorted first
<kees> hallyn: reading the bug, it looks like it's a kernel change that is needed?
<xnox> slangasek: licensing? /me thought this has nothing to do with secure boot signatures....
<kees> hallyn: if so, did you ask a kernel team person to pull that patch in?
 * xnox *giggles*
<slangasek> xnox: it's currently licensed GPLv3 per company default; that's fine for a PAM module as long as we're not turning it on by default. :)
<xnox> slangasek: ok.
<hallyn> kees: no, it's a kernel change that changed symbol naming, and systemtap is updated to handle that
<kees> hallyn: ah, is https://launchpadlibrarian.net/116856894/systemtap_lp1054274_quantal_fix2.debdiff the right fix?
<hallyn> kees: yup that's what i was looking at
<kees> hallyn: we're frozen, yes? I think you need a freeze exception for it first, then it should be trivial to fix.
<stgraber> kees, hallyn: looks like a bugfix to me, so shouldn't need a FFe
<SpamapS> stgraber: re juju using lxcbr0, its under review now actually :)
<kees> stgraber: oh, right, durr
<hallyn> kees: it's listed in http://pad.ubuntu.com/ubuntu-release as an 'opportunity target'
<kees> hallyn: you want me to upload it?
<stgraber> SpamapS: yay! I'm looking forward to being able to run it inside an lxc container! I'll actually need that feature for edubuntu-server in 13.04 :)
<hallyn> SpamapS: let us nkow if there's anything you'd like us to look over for that!
<SpamapS> stgraber: cool. I'm looking forward to being able to actually use lxc in quantal ;)
<stgraber> hallyn: information on that pad tends to be out of date when not in a milestone week
<SpamapS> have had to resort to testing in a 12.04 VM
<hallyn> kees: that'd be great, thanks.  (The one comment in teh bug asked about mentioning the kernel version where it changed in changelog;  that seems overkill to me but i listed the commit id in the bug at any rate)
<hallyn> stgraber: ah :)
<hallyn> @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:
<stgraber> SpamapS: yeah, I hear you, I'd also like to be able to run containers on my laptop instead of running them on a 12.04 server...
<kees> hallyn: okay, I'll add it.
<hallyn> kees: thanks!
<kees> hallyn: np, thanks for pointing it out :)
<Xgates> hi guys
<Xgates> Besides Ubuntu I run some other distros that I compile apps from source and I noticed that in Ubuntu it has libreoffice broken up into packages, like; libreoffice-writer, libreoffice-calc... and I wanted to find out if anyone knows how this was done, like it seems you can just compile this with only the writer if that's all you want?
<xnox> Xgates: we compile once with everything enabled, and just split the installed tree into bits.
<xnox> Xgates: you can't actually compile debian package with "just writer" enabled. Plus there is little point, as most of the libreoffice core bits are common across major components.
<Xgates> ok, so if someone only installed libreoffice-writer on Ubuntu do you know what other pkgs are going to get pulled in with it?
<xnox> Xgates: yes. see the debian/control file in the source package.
<xnox> Xgates: a single source package (first paragraph) can build one or more binary packages (all other paragraphs)
<sarnold> Xgates: apt-cache show libreoffice-writer will show you a "Depends: " line that has packages that will also be installed (those packages may also pull in dependencies..)
<Xgates> yep deps on deps on deps hehe
<Xgates> I wish they'd make it so you can build only what you wanted and not the whole thing...
<xnox> Xgates: libreoffice is special. on buildd's it takes 4.5 hours to build =(
<xnox> Xgates: and by building just -writer, you will end up building most of libreoffice anyway
<xnox> Xgates: on armhf - 21 hours.
<Xgates> only took me 2 hours to build it
<sarnold> Xgates: do you also build all the translations? :)
<xnox> Xgates: depends how much of it you build, and whether you do languages stripping for language packs, compressions and debug symbols packages.... like launchpad does
<Xgates> I don't think you can just build only certain parts like just writer
<Xgates> I built the languages as well all only 2 hours
<sarnold> Xgates: nice build box :)
<xnox> well somone build libreoffice in 40minutes all in 32 GB RAM and 16 cores.
<infinity> I need a new laptop.  My 16G of RAM isn't cool anymore.
<sarnold> infinity: ooh, what make/model? :)
<Xgates> I just built it on a Sony Vaio lap i3 core 4gb ram is all nothing fancy
<infinity> sarnold: Just an old T420s.
<sarnold> xnox: do the buildds build the tests as well?
<xnox> sarnold: check for yourself. https://launchpad.net/ubuntu/+source/libreoffice/1:3.6.1~rc2-1ubuntu5
 * penguin42 hopes the libreoffice guys efforts to remove cruft from the LO code base will keep removing stuff
<sarnold> hehe, "add $1060..."
<xnox> sarnold: click on the arch under the build section
<sarnold> xnox: ooh, thanks :)
<Xgates> what an idiot this guy is in the Lbo-dev channel;
<infinity> sarnold: No one buys RAM from Lenovo, that's madness. :P
<Xgates> <moggi> Xgates: if you plan to help implementing it we may give you some code pointers, otherwise you're in the wrong channel
<Xgates> oh gee may give me some pointers LOL
<infinity> sarnold: You spec the system with as little RAM as possible, and then go to the local computer parts store. :P
<sarnold> infinity: that's been my approach in the past, but of course now they're taking to the solder gun for ram :/
<xnox> what do you do when people email you for support, simply because you commented on a bug report
<xnox> ????
<infinity> sarnold: If by "they", you mean "Apple", that's one of the many reasons I don't buy their stuff.
<sarnold> xnox: you can aim users at http://www.ubuntu.com/support/community
<infinity> sarnold: I've not noticed Thinkpads suffering this problem.
<sarnold> infinity: I think the new lenovo x1 has soldered memory :(
<infinity> Oh, the X1 is junk anyway.
<sarnold> oh :)
<infinity> The T420s was lighter, thinner, faster, and cheaper.
<infinity> The X1 really didn't live up to the "X" series name. :P
<sarnold> infinity: thanks :) (I'm in the market for a laptop in the next week or so, good advice.)
<tumbleweed> barry: I was vaguely intending to look at it this weekend. But basically, running update-manager in the en_ZA.UTF-8 locale should fail fairly before it does any upgrading
<barry> tumbleweed: i only got so far as installing a precise vm and i *think* switching it over to en_ZA.  post anything you find out to bug issue and i can pick it up again on monday.  if you don't solve it of course :)
<tumbleweed> barry: because the locale was modified in precise to use a non-breaking space as a thousands separator, and we are treating it as ascii
<infinity> sarnold: Generally, if you feel the pricepoints are reasonable, you should just still with the X200 series and T400 series, IMO.
<xnox> tumbleweed: use proper english. -> wontfix.
 * xnox hides =)
<tumbleweed> xnox: we use proper english. Not that en_US nonsense
 * xnox meh
<infinity> sarnold: Some of the cheaper Thinkpads are decent machines, but the X2xx and T4xx tend to never disappoint, and it then just comes down to size/screen/battery tradeoffs between the two.
<barry> tumbleweed, xnox what colour is your authorisation?
<tumbleweed> :)
<sarnold> infinity: thanks! I'd been looking only in the T* range, but felt way out of my league; last time around (eight years ago?) it felt simpler than this. :)
<tumbleweed> barry: it's pretty much solved - need to write a patch for python-apt and the release upgrader
<barry> tumbleweed: cool
<soniah> I'm looking for sponsorship of lp:~sonia/ubuntu/quantal/vim-scripts/fix-for-31204
<xnox> soniah: it's in the queue http://reports.qa.ubuntu.com/reports/sponsoring/
<xnox> soniah: i'm sure vim lovers will sponsor that quickly though.
 * xnox is emacs user =)
<soniah> thanks xnox. I use both; I thought I'd start with something small :-)
<ScottK> soniah: For changes inside the debian dir, you don't use a patch.  Just make the change directly.  Also you added exuberant-ctags, aspell, and ispell to Suggests, but don't mention it in debian/changelog (which should be a record of all changes and particularly why).
#ubuntu-devel 2012-09-29
<soniah> thanks ScottK
<ScottK> soniah: You're welcome.  Thank you for contributing.
<xnox> ScottK: about bug 1040900
<ubottu> Launchpad bug 1040900 in busybox (Ubuntu Precise) "syslog messages truncated to 256 chars during debian-installer run" [High,In progress] https://launchpad.net/bugs/1040900
<ScottK> xnox: Yes?
<xnox> ScottK: I think the intention is to get it into precise as soon as possible.
<xnox> ScottK: and to me 2xSRU + upload in R is more expensive than 1xSRU and upload in Q
<ScottK> xnox: As long as all goes well, yes.  This isn't about efficiency, it's about risk reduction.
<ScottK> The bug's been there since August, so I think we're past it being something critical that needed immediate response.
<xnox> ScottK: well yeah, there was load issue for stockachu, as he was not getting all his other uploads SRU'ed quickly enough.
<xnox> ScottK: that is sponsored and/or accepted into -proposed.
<ScottK> Right, but it's been a month and a half already, so I am highly skeptical that a bug that has existed for four years can wait a couple of weeks.
<ScottK> Please spend time fixing serious problems before release.  There's no shortage of those.
<xnox> ok.
<xnox> bcmwl (source) 5.100.82.38+bdcom-0ubuntu4.1	restricted	admin	low	kubuntu netbook ubuntu-desktop	Proposed	2012-05-31
<xnox> oneiric-proposed unapproved
<xnox> *heh* nobody cares about oneiric....
<xnox> is there a report for *all* queue?
<doko_> Laney, how did your -gstabs experiments end up?
<infinity> Laney: Your -gstabs test would probably work a lot better if you'd also exported CXXFLAGS.
<Laney> infinity: better than what? It worked where it failed before and the remaining armel failure is unrelated
<Laney> doko_: still building
<Laney> infinity: (because we build with CXXFLAGS="$(CFLAGS)")
<infinity> Laney: Erm, I was watching the log go by, and it sure didn't look like CXXFLAG=CFLAGS (as in, there was plenty of "-g -O2 ...")
<infinity> Laney: If it succeeded where previous builds failed, I suspect that was because of something entirely unrelated, like it was building on a different kernel.
<cjwatson> tumbleweed,barry: for that apt_pkg.size_to_str thing with the release upgrader - I'm very wary of changing python-apt, because that's an API change
<cjwatson> tumbleweed,barry: also, I couldn't get size_to_str to actually emit a string that required the thousands separator, because it just changed units instead - any suggestions on a specific value that exposes the problem at that level?
<cjwatson> oh, there we go, enormous values do it
<cjwatson> ... but no.  sufficiently enormous values produce data corruption, not anything containing the thousands separator
<cjwatson> >>> apt_pkg.size_to_str(99000000000000000000000000000)
<cjwatson> '`tE\xf7\t\xbf\xf57\x8c'
<cjwatson> >>> apt_pkg.size_to_str(99000000000000000000000000000)
<cjwatson> '`tE\xf7\t\xbf\xf57\x8c'
<cjwatson> oops, sorry
<tumbleweed> cjwatson: the easy option is droppnig the non-breaking space from the locale
<tumbleweed> it seems to be a fairly unusual thing to have as a thousands separator
<tumbleweed> (and is an ubuntu-only patch, because the locale maintainer hasn't signed off on it yet)
<cjwatson> tumbleweed: No, I'd rather not do that.  There are quite a few locales with NBSP in the thousands separator.  Besides, it indicates a type problem, which we should certainly fix.
<cjwatson> I would really like a smaller reproduction case at the python-apt level than "run an upgrade", though.
<infinity> Is there a bug for this that shows the problem?
<cjwatson> It's on the -tracking list.
<cjwatson> Bug 1031882.
<ubottu> Launchpad bug 1031882 in ubuntu-release-upgrader (Ubuntu Quantal) "precise->quantal upgrade fails, with a UnicodeDecodeError" [High,Confirmed] https://launchpad.net/bugs/1031882
<cjwatson> But it doesn't say what downloadSize is.
<tumbleweed> when I first ran into it, I assumed it was something that would hit other people, so just filed it and moved on
<cjwatson> Anyway, I suspect that apt_pkg.size_to_str returns str regardless of Python version - that is, bytes for Python 2 and text for Python 3.  We shouldn't go changing that now.  Instead, the upgrader code should deal with it.
<cjwatson> I just wanted to be able to actually reproduce it in a smallish test before changing anything.
<tumbleweed> decoding it as utf-8 when in utf-8 locales seems straightforward enough
<cjwatson> Eh, you have to be careful though because this code is polyglot 2/3.
<cjwatson> It's probably if isinstance(foo, bytes): foo = foo.decode() territory.
<cjwatson> I'll probably hit it with that stick on Monday if nobody's beaten me to it.
<cjwatson> Hm, in Python 3 for enormous values you get "OverflowError: Python int too large to convert to C long", which I think may be the subject of another -tracking bug ...
<cjwatson> *that*'s probably a python-apt bug
<tumbleweed> are sizes larger than a C long likely to be an issue?
<TheLordOfTime> if there's a bug about the images for 12.10 and the beta and what not, are those supposed to go here?
<TheLordOfTime> or questions thereof...]
<xclaesse> are there known issues with jack detection in quantal ?
<xclaesse> I often cannot ear anything from the speakers but connecting headset in the jack works
#ubuntu-devel 2012-09-30
<xnox> Please reject https://code.launchpad.net/~cosmos-door/ubuntu/quantal/libproxy/fix-ftbfs-1057613/+merge/126724 as Laney already applied the same fix.
<micahg> infinity: I've got a problem with webkit in precise now on arm*, it seems to be abort happy...do I need the gstabs fix there as well or is there some other thing I can do to get a complete build, these builds worked back in July...
<infinity> micahg: *sigh*... It's not that webkit or the toolchain have changed, it's that we need to revert the abort timeout to what it was.
<micahg> infinity: please? :)
<mih1406> I have submitted my feature request for Ubuntu One, I believe it is a great addition to Ubuntu One's future!! https://bugs.launchpad.net/ubuntuone-client/+bug/1058900
<ubottu> Launchpad bug 1058900 in Ubuntu One Client "Sync application preferences and/or data" [Undecided,New]
<geser> doko_: I see that you removed ldc and added it to the sync blacklist. Should the same happen to libtango too as it build-depends on ldc? (see also bug #935267)
<ubottu> Launchpad bug 935267 in libtango (Ubuntu Precise) "libtango version 0.99.9.dfsg-1 FTBFS on i386 in precise" [High,Confirmed] https://launchpad.net/bugs/935267
<cjwatson> doko_: I'd actually prefer that you didn't add such things to the sync-blacklist any more, please
<cjwatson> doko_: Only use the sync-blacklist when we never want the package in Ubuntu again even after it's been fixed in Debian
<cjwatson> doko_: The auto-sync is interactive nowadays when packages have been previously published in Ubuntu, so it shouldn't cause any accidents, and it's much easier to maintain things if you don't use the sync-blacklist for this kind of thing
<cjwatson> (And in particular the auto-syncer will just ignore versions that were previously published and removed)
<geser> cjwatson: Rhonda asked in #ubuntu-motu how go get a package never synced to Ubuntu. Is getting it on the sync-blacklist the right thing?
<cjwatson> Yes
<cjwatson> Subscribe ~ubuntu-archive to an appropriate bug
<geser> not branch, patch, propose a merge?
<cjwatson> Waste of time
<cjwatson> I mean you can if you *really* want I suppose but it's pointless
<cjwatson> And I suspect merge proposals won't work anyway because it's a +junk branch
<jtaylor> why is python3.3 not in python-all?
<cjwatson> jtaylor: Too late for 12.10
<jtaylor> why have python3.3 then at all?
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python33
<jtaylor> no extensions, apport going crazy about every traceback etc
<xnox> jtaylor: such that it's possible to do a rebuild against it?
<cjwatson> You can at least do basic experiments with it
 * xnox after patching things up....
<ogra_> and you can forward port for R while being on Q
<jtaylor> it will confuse users
<ogra_> how ?
<jtaylor> e.g. bug 1059017 confused me until I figured out its not in -all
<ubottu> Launchpad bug 1059017 in apport (Ubuntu) "python3.3 throws apport exception on each traceback" [Undecided,New] https://launchpad.net/bugs/1059017
<jtaylor> granted its not too bad, but some people might expect a fully functioning python3.3 when they install the package
<jtaylor> and understanding these types of issues is not trivial
<ogra_> not hard to switch off apport orjust ignore it though
<ogra_> indeed its a bug but really not that fatal
<kenalex> hello
<IDWMaster> Hi
<IDWMaster> I'm having a really annoying problem when I use GTK in a library
<IDWMaster> I'm trying to write a utilities library that uses GTK+, and I've followed the instructions on the website for compiling with pkg-config, but whenever I call a GTK function the program just terminates.
<IDWMaster> Does GTK also have to be linked with the program I'm embedding the library into?
<IDWMaster> I thought that wasn't required for .so libraries.
<tumbleweed> IDWMaster: yes, .so = shared library, you link to it, it isn't embedded
<IDWMaster> I'm using dlopen to link to my library
<IDWMaster> and then my library is linked to GTK+ using compile-time pkgconfig
<IDWMaster> However; when I call a gtk+ function from my library; it crashes
<tumbleweed> btw, this is faily off topic for this channel, which is about development of Ubuntu, not support
<IDWMaster> Isn't this development-related?
<tumbleweed> development *of* Ubuntu, not development on Ubuntu
<IDWMaster> Where's the appropriate development on Ubuntu channel?
<stgraber> IDWMaster: #ubuntu-app-devel according to this channel's topic
<JHOSMAN> Hello for all!
<JHOSMAN> I have Ubuntu Quantal problem but still do not know if you report it as bug.
<JHOSMAN> =( hello
<jtaylor> JHOSMAN: #ubuntu+1 is for quantal support
<JHOSMAN> THanks! go to!
<doko> cjwatson, will look at these tomorrow
<trism> doko: if you get a chance could you retry the gecko-mediaplayer build on amd64,armhf, I think they just hit the archive at a bad time (firefox-dev was uninstallable)
<jtaylor> trism: done on amd64
<trism> jtaylor: thanks
<jtaylor> looks like it worked, started armhf
<trism> jtaylor: looks good on armhf too, excellent thanks much
#ubuntu-devel 2013-09-23
<pitti> Good morning
<smartboyhw> Can someone please upload https://launchpad.net/bugs/1228635 and https://launchpad.net/bugs/1228657 (final fixes for Ubuntu Studio before Beta 2)
<ubottu> Ubuntu bug 1228635 in ubuntustudio-default-settings (Ubuntu) "Background for screen 1 is different from screen 0" [Undecided,Fix committed]
<ubottu> Ubuntu bug 1228657 in ubuntustudio-lightdm-theme (Ubuntu) "Lightdm has the wrong backdrop, it is from 13.04" [Undecided,Fix committed]
<smartboyhw> dholbach, heyas, you love sponsoring uploads I know, care to deal with Bug 1228657 and Bug 1228635?
<ubottu> bug 1228657 in ubuntustudio-lightdm-theme (Ubuntu) "Lightdm has the wrong backdrop, it is from 13.04" [Undecided,Fix committed] https://launchpad.net/bugs/1228657
<ubottu> bug 1228635 in ubuntustudio-default-settings (Ubuntu) "Background for screen 1 is different from screen 0" [Undecided,Fix committed] https://launchpad.net/bugs/1228635
<dholbach> good morning
<dholbach> hi smartboyhw
<pitti> hey dholbach
<smartboyhw> dholbach, good afternoon!
<dholbach> smartboyhw, one thing at a time - I just started work and will need to go through a bunch of mails first - if you subscribed 'ubuntu-sponsors' it should be in the sponsoring queue though
<dholbach> hi pitti
<smartboyhw> dholbach, sure
<smartboyhw> Hmm, I didn't realize that Len didn't subscribe
<pitti> hey smb, wie gehts? made it back in one piece?
<smb> pitti, Yeah and with less incidents than the other way round. You seemed to have more "fun". Only my sunglasses did not make it with me. Ok, I had to get new ones anyway sooner or later.
<pitti> smb: forgot them in the hotel, or did they look too suspicious during security check? :-)
<smb> pitti, Nah, just had them stashed externally on my backpack and somewhere they must have escaped
<smb> Not that anybody could use then... well except that someone has -10 on both eyes
<smb> pitti, Did you get delayed a lot by that "obstacle" on the tracks?
<pitti> smb: not that much any more, I was home around 13:00
<smb> Ah, not too bad indeed, I just got back one hour earlier
<smb> Then made my two crosses and crashed
<cff> How can I install GDB 4.6.1 in Ubuntu 13.04 ?
<cff> err
<cff> GDB 7.6.1
<cff> The repos don't have it : https://launchpad.net/~ubuntu-toolchain-r/+archive/test?field.series_filter=raring
<infinity> cff: Is there a reason 7.6 isn't good enough for you?
<cff> infinity: the package in the repos reports version 7.5.91.20130417-cvs-ubuntu
<cff> infinity: although the package seems to be labeled with gdb 7.6
<infinity> cff: Sure, it's a pre-release right before 7.6 shipped.
<infinity> cff: Again, is there something fundamentally wrong with that, or are we just suffering versionitis?
<infinity> cff: Anyhow, as a general rule, we don't update upstream versions in stable releases.  That's what makes them stable releases.
<cff> KDevelop reports all my breakpoints as "Your debugger is too old"
<infinity> I'd argue that's a bug in kdevelop that someone should fix, then.
<infinity> Ubuntu's version, or your own build?
<infinity> Anyhow, if the Ubuntu kdevelop fails to work with the Ubuntu gdb, I'd suggest filing a bug at: https://bugs.launchpad.net/ubuntu/+source/kdevelop/+filebug
<infinity> If it's an upstream/PPA/who-knows-what build of kdevelop, you're likely on your own, or you might want to sort out how to build a new gdb, or try installing the "real" 7.6 from saucy on raring and see if that's good enough.
<infinity> cff: ^
<cff> infinity: okay, thanks for the information
<JackYu> infinity, hi, would you please  review the binary NEW of fcitx-qimpanel?
<JackYu> infinity, done just now:), thanks.
<smartboyhw> dholbach, you finished through the mails? :P
<diwic> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<dholbach> smartboyhw, there are lots of other folks who have upload rights
<smartboyhw> dholbach, sure, but the Beta 2 block is dropping:( (It is of course OK to be uploaded after the block, but)
<dholbach> smartboyhw, understood, but don't block on me
<smartboyhw> dholbach, sure
<smartboyhw> diwic, since you are on patch pilot duty, look at Bug 1228635 and Bug 1228657 please:) I want that be uploaded so we can respin images.
<ubottu> bug 1228635 in ubuntustudio-default-settings (Ubuntu) "Background for screen 1 is different from screen 0" [Undecided,Fix committed] https://launchpad.net/bugs/1228635
<ubottu> bug 1228657 in ubuntustudio-lightdm-theme (Ubuntu) "Lightdm has the wrong backdrop, it is from 13.04" [Undecided,Fix committed] https://launchpad.net/bugs/1228657
<smartboyhw> (For Beta 2 effectively)
<diwic> smartboyhw, thanks, I saw those, but I don't have upload rights unfortunately
<diwic> smartboyhw, (except for pulseaudio)
<smartboyhw> -.-
<smartboyhw> What the....
<diwic> smartboyhw, ask dholbach why he thinks I should be a patch pilot anyway, to me it does not really make sense, but...
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<smartboyhw> LOL
<diwic> oops, there goes the beta freeze
<sladen> there /arrives/ the beta freeze
<diwic> sladen, yeah, that's a better way to put it
<Laney> The idea of being a patch pilot is to help things along, not necessarily to upload them
<Laney> So you might for example review these uploads and see if they look OK to you, which will make it easier for someone who can to sponsor it
<Laney> Or if you know there is a developer with expertise in this area you could ask them to take a look
<diwic> Laney, dholbach, well, for me I feel that the actual upload is what most items actually need help with
<diwic> reviewing is already done
<dholbach> the actual upload is what takes the least amount of work
<dholbach> and I for one would completely trust your judgement if said: "I looked at X, Y and Z - can you please upload/sync them?"
<diwic> Laney, dholbach how about that a person with upload should always accompany somebody without, would that make sense?
<diwic> then I'd at least know who to ask for upload
<dholbach> you're a great engineer, you've worked in Ubuntu and with Debian and Upstream for ages now and you know what you're talking about
<dholbach> diwic, if you're suggesting one-on-one mentoring then we tried that for quite a while and it didn't scale very well :-/
<diwic> dholbach, no, not at all - I'm suggesting that when patch pilot schedule is set up, one should always work in pairs where at least one has upload rights
<dholbach> ah ok
<dholbach> if you have a look at https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&gsessionid=OK - there's always 2 or 3 patch pilots at the same day
<dholbach> so that might be one option
<dholbach> but you could also just try to ask in here for somebody who can sponsor/sync once you reviewed something
<smartboyhw> But uptimes can be different .
<smartboyhw> Like, one patch pilot comes up on duty at 12:00 UTC - 16:00 UTC and the another comes up 16:30 UTC - 20:30 UTC
<diwic> dholbach, it would feel better if there was a designated uploader rather than just "hey can somebody in here upload"
<diwic> dholbach, and also I feel like people expect a patch pilot to have upload rights, like smartboyhw just did
<dholbach> smartboyhw, I just set up this schedule as a reminder for everyone - they are free to move things around as it works best for them - I wouldn't like to specify times for everybody (sometimes people work from different timezones or need to get some other work out of the way first, etc.)
 * smartboyhw does, actually
<dholbach> smartboyhw, well, you'd still need somebody to review and test-build your suggested changes
<smartboyhw> dholbach, what I expect from a patch pilot is review + test-build + upload (in my point of view)
<dholbach> sure, "it's uploaded" is what everybody's after, but that's just the "end product" of a proper review including reading the changes, test-building them, checking if they should better go upstream first, if all the processes are followed, etc.
<smartboyhw> dholbach, maybe we make it like us: diwic reviews and you upload?
<dholbach> smartboyhw, and that's all documented here: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
<smartboyhw> :P
<smartboyhw> (Since you said that upload takes the least time)
<dholbach> smartboyhw, can you please stop that? I understood your nudge the first time you asked me
<dholbach> smartboyhw, I have a couple of other things I need to get out of the way first
<smartboyhw> dholbach, sure....
 * diwic goes for lunch, will continue piloting after lunch
<diwic> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mpt> mvo, hi! What do you think of the patch that just got attached to bug 617397?
<ubottu> bug 617397 in software-center (Ubuntu) ""Fonts" department is empty on new Ubuntu installation" [Undecided,Fix released] https://launchpad.net/bugs/617397
<slickymaster> good morning all
<mvo> mpt: hello! this patch should be fine
<mpt> cool
<mvo> mpt: updated to include a additinal piece of information how it could be improved
<mpt> Thanks mvo!
<dholbach> smartboyhw, uploaded
<smartboyhw> dholbach, MANY THANKS!
 * smartboyhw hugs dholbach with tears:)
<dholbach> anytime
<dholbach> haha
<dholbach> it's all good
<smartboyhw> dholbach, sorry for being rude:P
<dholbach> no, it's fine - I could see that you just wanted to make sure those fixes go in, you just didn't seem to believe them when I said "yeah, later" :)
<diwic> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<doko> cjwatson, apw: who should subscribe to this package? lp: #1196958
<ubottu> Launchpad bug 1196958 in libmnl (Ubuntu) "[MIR] libmnl (b-d of libnetfilter-conntrack)" [Undecided,In progress] https://launchpad.net/bugs/1196958
<doko> foundations or kernel?
<cjwatson> doko: neither seems to be subscribed to libnetfilter-conntrack; what's the first thing in the rdep chain with a useful subscriber?
<doko> cjwatson, ahh, dnsmasq and squid3, so probably server team
<doko> jamespage, ^^^
<apw> seems like you have things under control
<doko> apw, but while you are here ... any news on running the trinity tests?
<jamespage> doko, done
<doko> jamespage, thanks, promoted
<jamespage> doko, thanks
<doko> TheMuso, ping on #1196967
<OrokuSaki> I have this bug.. and I don't know what to do.. it involves delta max and a touchscreen. swipes get mistaken for double touches on certain boots.. like 1 out of 5.. put the ts_srv.c in debug mode, everything seems fine with it..
<OrokuSaki> maybe its udev.. hmmm
<diwic> dholbach, so, I've done some work on bug 1155575 and submitted a MP. You don't have to upload anything, I'll prefer to wait for the review for a few days first
<ubottu> bug 1155575 in rhythmbox (Ubuntu) "Rhythmbox not reading 'year' tag" [Undecided,In progress] https://launchpad.net/bugs/1155575
<diwic> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> diwic, gotcha
<diwic> (and the two other bugs I worked on turned out to be already fixed)
<OrokuSaki> How can I test my graphics acceleration settings on my gpu? To detect what is working? vainfo?
<OrokuSaki> Sorry to bug you guys
<pitti> OrokuSaki: glxinfo might be a good start
<geser> OrokuSaki: "/usr/lib/nux/unity_support_test -p" might be helpful too
<zul> mterry:  wsme should be good now
<mterry> zul, wsme?
<zul> https://bugs.launchpad.net/ubuntu/+source/python-wsme/+bug/1207030
<ubottu> Ubuntu bug 1207030 in python-wsme (Ubuntu) "[MIR] python-wsme" [Undecided,Incomplete]
<mterry> zul, why not run the python3 tests too?
<zul> mterry:  dang
<mterry> zul, does "setup.py test" do anything?  Or do we need to run each test manually?
<mterry> zul, does "setup.py test" do anything?  Or do we need to run each test manually?
<zul> mterry:  it doesnt do anything it looks like the other ones need turbogears installed
<zul> and there doesnt look like there is a python3 package for flask
<mterry> zul, turbogears isn't even in the archive anymore....
<zul> exactly
<mterry> zul, approved, thanks!
<zul> mterry:  cool
<slickymaster> \quit
<didrocks> jasoncwarner: slangasek: barry: just update the request on the spreadsheet for getting download manager on track for landing
<slangasek> didrocks: sorry, do you mean that you have just updated it?
<didrocks> slangasek: I don't have all context but it was re: 19:29:42    jasoncwarner | didrocks slangasek says the download service should land tomorrow. can you get with him and barry etc to know what we would need to do to update the updater?
<slangasek> didrocks: ok, so this is a reminder to us to update the spreadsheet?
<barry> didrocks: i'm told the updated d/l service with everything i need should land tomorrow.  if so, i'm hoping to finish my branch by tomorrow too
<didrocks> slangasek: right, as an answer to "what's needed"
<slangasek> didrocks: ok.  fyi I don't have edit rights on the spreadsheet
<didrocks> asac: I'm fixing that ^
<asac> didrocks: if you can thats good
<didrocks> slangasek: should be good now
<asac> thx
<lamont> the default ipv6-enabled config is both a good and a bad thing
<lamont> slangasek: who is our favorite ipv6 maven these days?
<slangasek> lamont: stgraber, who's off today
<slangasek> lamont: but there are others about who have some experience :)
<lamont> it would seem that the nifty "too many unreachable, advertised NS hosts causes intermittent resolution falures" bug
<lamont> seems to show up well if you have BIND running on a host that has no ipv6 connectivity
<slangasek> didrocks: ok, added at the bottom of the first sheet.  but, what are these unlabelled columns that are filled out?  is there more information I should be providing?
<lamont> slangasek: specifically, see the output of dig ns salesforce.com
<didrocks> slangasek: it's if questions arisent
<slangasek> didrocks: ok
<didrocks> slangasek: you should have added to the second list I think, but that's fine anyway
<slangasek> didrocks: I understood the second page to be for quick'n'easy bugfixes... this is not that
<slangasek> lamont: erm?  but each of those nameservers has both an A and a AAAA record
<didrocks> slangasek: no, all request on second normally
<didrocks> then, we move it to the first one
<didrocks> I'll ack something to get it cleaner I guess
<slangasek> lamont: so this doesn't seem to be something you need an IPv6 expert for, you just need someone to fix a bug in the bind code ;)
<lamont> slangasek: yeah - I'm not sure whether it's doing the RTT weighting on IP or host, tbf
<slangasek> didrocks: ah, that's not what I took away from that email
<lamont> slangasek: yeah
<didrocks> slangasek: that's my understanding of it, but maybe I'm really wrong, I didn't design this process ;)
<lamont> slangasek: specifically, when there are multiple unreachable hosts, the unreachables tend to clump together and make life suck when they all win together
<alberts> Is there anyone who is familiar with unity-greeter? With time to review merge proposals attached to this bug -  https://bugs.launchpad.net/unity-greeter/+bug/1201127
<ubottu> Ubuntu bug 1201127 in Unity Greeter "support logging in on any screen when using separate x screens" [Medium,Triaged]
<shadeslayer> pitti: ping
<shadeslayer> since you last uploaded automake 1.13, it kind of breaks virtuoso-opensource because of a shell script test-driver not being available
<shadeslayer> I've worked around the issue by symlinking /usr/share/automake-1.13/test-driver to where autotools try to find the file
<shadeslayer> is that an appropriate solution?
<barry> #py-dev
<mterry> pitti, what creates the /run/user/$UID directories when you log in?
<slangasek> mterry: logind
<mterry> slangasek, ah thanks.  hm
<slangasek> mterry: (triggered via pam_systemd.so in /etc/pam.d/common-session)
<cjwatson> shadeslayer: virtuoso-opensource probably isn't using automake -f
<cjwatson> shadeslayer: TBH, I've had consistently bad experiences with cdbs' auto-update rules; you might be best served by migrating to dh-autoreconf (which includes cdbs integration)
<cjwatson> basically delete DEB_AUTO_UPDATE_* and include wherever it is that autoreconf.mk lives
<cjwatson> and build-dep on dh-autoreconf
<cjwatson> doko,wookey: Debian's infrastructure is now coping with :any in both Build-Depends and Depends, so it should be fine to merge such things; the caveat for Depends is that wheezy's apt makes the wrong decisions, so if you use :any in runtime Depends the current consensus appears to be that you need to make sure that there's also a version relationship forcing upgrade to the :any-supporting version, to avoid wheezy->jessie ...
<cjwatson> ... upgrade hilarity
<wookey> cjwatson: excellent
#ubuntu-devel 2013-09-24
<pitti> Good morning
<pitti> shadeslayer: sorry, no idea about the automake test driver; I merely fixed the broken autopkgtest
<pitti> shadeslayer: yes, what cjwatson says; don't use cdbs' auto-update
<dholbach> good morning
<ion> that
<pitti> builds fail with "Unable to connect to archive-team.internal:http:
<pitti> infinity: ^ known?
<cjwatson> pitti: known, we're working on it
<pitti> cjwatson: thanks
<cjwatson> pitti: fallout from the lillypilly->snakefruit switchover
<shadeslayer> cjwatson: there is a multiarch'd virtuoso which uses debhelper in debian experimental, however that will break soprano, which is why I haven't requested a sync
<shadeslayer> and thought it'd be a better idea to fix our own package
<apw> pitti, hey ... whats the ramifications of adding a source pacakge which does not yet exist into apport in precise, specifically i am adding linux-lts-raring and it seems appropraite to add linux-lts-saucy at the saem time if that isn't going to explode
<apw> pitti, as in adding a new link to debian/apport.links
<pitti> apw: that seems rather straightforward
<pitti> apw: i. e. if we already decide to SRU a new kernel, this should be part of that exception
<apw> pitti, yeah agreed.  in this case i am fixing raring cause it was missed (and i'll send you a merge request to look at in a bit) and thinking we might want to do saucy in advance to save doing an additional SRU
<apw> though as it is so easy, perhaps we don't care
<pitti> apw: if we already know that we are going to backport the saucy kernel, it seems fine to do it in one go
<apw> pitti, ok, will just get this tested, and then get it up for review.  I think it needs that cause i am ripping out a hack which you added for before these packages hit the actual archive; and now is redundant
<pitti> apw: ah, we added some PPA lookup?
<apw> pitti, we added some PPA 'ok' which is fine i guess, but we also mapped the names over to linux else you couldn't file the bugs either
<apw> and that doesn't seem appropriate any more
<apw> and we only did it for quantal, not all lts kernels
<apw> so it was a bit of an old hack
<shadeslayer> cjwatson: well, I can also pass --add-missing which fixes the issue
<apw> pitti, ok here is my proposed changes, they seem to work on a VM ok: lp:~apw/ubuntu/precise/apport/lts-backport-kernels
<apw> pitti, if you could cast your weathered eye over them, then perhaps i can try the release process
<pitti> apw: so the meta packages are named linux-meta-raring (or something such), not linux-raring-meta?
<apw> linux-meta-lts-raring | 3.8.0.31.31 | precise-proposed | source
<pitti> ah, so it says in the second hunk, nevermind
<apw> yeah after a shakey start we have standarised on the 'base name' (linux, linux-meta, linux-signed etc) followed by the variant
<pitti> apw: LGTM then, thanks!
<doko> didrocks, are you aware of the unity-* and friends build failures in the test rebuild?
<doko> seb128, has libburn ubuntu specific patches, or is it just the new upstream?
<seb128> doko, just new upstream version
<doko> barry, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5014145 ?
<barry> doko: i'll put it in a tab for later ;)
<mlankhorst> mdeslaur: poke :)
<mdeslaur> mlankhorst: hi
<mlankhorst> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/glamor-egl/+bug/1227919 ?
<ubottu> Ubuntu bug 1227919 in glamor-egl (Ubuntu) "[MIR] glamor-egl" [Undecided,Incomplete]
<mdeslaur> sarnold: what's the status on mlankhorst's MIR? ^
<mdeslaur> mlankhorst: sarnold will be here in 3-4 hours, I'll see what the status is then
<mlankhorst> ok thanks
<doko> infinity, I see you touched corosync last weekend. could you have a look at openais (ftbfs) too?
<bloopletech> I have just reported a bug in libgl1-mesa-glx, and I'd like to do what I can to avoid the bug being ignored/unnoticed. The issue revolves around the x86_64-linux-gnu_gl_conf alternative, and two packages that provide it, libgl1-mesa-glx, and nvidia-304. I am able to help troubleshoot the issue right now; if this is the wrong venue for discussing the issue, a pointer would be super helpful
<bloopletech> The bug url is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1229734
<ubottu> Ubuntu bug 1229734 in xorg (Ubuntu) "libgl1-mesa-glx conflicts with nvidia-current (nvidia-304)" [Undecided,New]
<bloopletech> If I could work out _what_ is calling update-alternatives, that would probably be enough, because at least then I can add the fix as described in the bug *after* that in the boot
<pitti> stgraber: what's the status of these "mount partitions on top of /etc/ files" hack? is that only going to last until we get a proper aufs/overlayfs working?
<pitti> stgraber: it's certainly not something which we could ever use in a converged ubuntu
<stgraber> pitti: getting upstream aufs/overlayfs is I think the biggest blocker there, the Android kernels can be heavily patch and be rather ancient, so having reliable overlays was out of the question
<pitti> stgraber: right, but is that still the eventual plan?
<stgraber> pitti: it's one of the options we started discussing with slangasek when looking at the converged story, yes
<stgraber> pitti: the biggest concern I have there so that if we choose to use aufs or overlayfs, we basically say no to community ports
<stgraber> pitti: as no existing Android kernels support it by default and most ports maintainer lack the knowledge required to merge those rather massive patches
<pitti> stgraber: oh, why? you think that the block API will change so often that these modules don't port well across kernel versions/
<pitti> ?
<pitti> stgraber: if that isn't an option, then I guess we'll have to re-think having a writable /etc/, or using some other overlay solution
<stgraber> pitti: well, I always noticed that those patches take a couple of weeks to get re-applied whenever we switch to a new Ubuntu kernel, so I assume they are a bit of a pain to apply
<stgraber> apw would surely know more about that :)
<cjwatson> IIRC aufs is worse than overlayfs for that
<Laney> pitti: do you think you'd be able to work on the timedated hack to tide us over?
<pitti> Laney: if we actually find a solution how to do it, yes
<pitti> Laney: I really don't want my name on a patch which does in-place file updating
<Laney> I guess we can add a writeable directory to /etc to store the intermediate stuff in
<Laney> like you suggested for /data
<cjwatson> That was my suggestion
<pitti> right
<cjwatson> Make /etc/localtime and /etc/timezone a symlink into that, so localtime ends up being a two-level symlink
<Laney> yeah
<pitti> so a two-level symlink, or copying the file content to /data
<Laney> Should be able to do it all within /etc
<pitti> Laney: this needs to be changed in at least tzdata and systemd then, and possibly also in other tools which adjust the time
<stgraber> doing that stuff within /etc would mean we have the original file in that sub-directory so factory reset will work properly
<stgraber> having the symlink point to /userdata would be more of a problem (as I mentioned in the bug)
<apw> stgraber, they are a mare to apply and forward port often yes as they dig right into the vfs, the bit which has no stable ABI
<stgraber> and having the tools change /userdata/system-data/etc/... instead of /etc would work but won't give you much since bind-mounts work on the inode and th atomic replace currently done will switch inode too (with the bind-mount pointing to the old file rather than the new one)
<stgraber> apw: thanks for confirming my fears! so definitely not something we'd want our community porters to do for all of their weird and old kernels (I had a few trying to run Ubuntu Touch saucy on 2.6.32...)
<Laney> Can't we bind mount the whole of /etc? :-)
<doko> jamespage, zul: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg shows some missing MIR's for the dependencies
<stgraber> Laney: you deal with crazy people adding stuff to /etc then ;)
<Laney> ?!
<stgraber> Laney: (the usual, how do you distinguish a new file being added to /etc from an old file being removed by the user locally)
<Laney> don't you have to care for that currently?
<stgraber> nope
<Laney> some of the whitelisted things are conffiles
<stgraber> transition is a one time thing done on first boot
<zul> doko:  python-wsme (#1207030), msg-pack (#1207003) and (#1207034) have the MIR compete and waiting for promotion
<stgraber> so any file (or directory) listed in writable-paths will be copied to /userdata and bind-mounted on first boot, if the content changes in the rootfs after that, you won't see it until you do a factory reset (which will trigger another copy from the rootfs to /userdata)
<jdstrand> tkamppeter: hi! in your next cups upload, can you fix bug #1229766? I added the apparmor rule to the description
<ubottu> bug 1229766 in cups (Ubuntu) "noisy apparmor denials" [Undecided,New] https://launchpad.net/bugs/1229766
<doko> zul, python-wsme needs MIR's for it's dependencies
<zul> doko:  gotcha
<doko> zul, promoted msgpack-python
<zul> doko:  thanks
<doko> will wait with python-thrift until the others are complete
<zul> doko:  thrift (#1207034) btw
<stgraber> tedg: ping
<stgraber> tedg: so I have a bit of a problem with edubuntu where we appear to ship ubuntu-system-settings and a bunch of other touch related packages by default...
<stgraber> tedg: apparently that's because indicator-sound recommends ubuntu-system-settings | gnome-control-center
<mterry> zul, I see the new MIR
<ogra_> thats overly poitless on touch
<ogra_> *pointless
<zul> mterry:  cool one more coming down
<stgraber> tedg: edubuntu ships gnome-control-center, but since ubuntu-system-settings is preferred, if we're unlucky at image build time, we'll end up pulling ubuntu-system-settings...
<ogra_> tedg, drop the recommends, it isnt used on touch ... and since it breaks desktop ...
<ogra_> stgraber, ^^^
<stgraber> tedg: can you either drop the recommend or switch the order to be more reasonable?
<stgraber> ogra_: that'd work for me
<ogra_> needs to be a hard dep or just carefully seeded
<stgraber> tedg: please do it in the next two hours or I'll have to cowboy it myself into the archive. I consider this a critical bug for Beta 2 and as such want it resolved ASAP. Thanks
<ogra_> else touch wont consider it anyway
<stgraber> ogra_: ah right, you guys still use no-install-recommends
<ogra_> stgraber, please coordinate cowboying with #ubuntu-ci-eng ...
<xnox> tedg: it seems like your interpretation of "Recommends" is what the "Enhances" stanza is http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
<tedg> stgraber, K, will change.
<tedg> xnox, The problem is that a menu item breaks if it's not there.
<tedg> xnox, So it's not a crash, but it's not really an "additional feature"
<xnox> tedg: menu item breaks where? on ubuntu-touch panel, desktop panel, ubuntu-system-settings, gnome-control-center?
<tedg> stgraber, Only concern is that I don't know if I can get it released... releasing is... tricky.
<tedg> xnox, ubuntu touch for one, desktop panel for the other.
<xnox> tedg: i'm sure a few people can dput it, e.g. stgraber and myself included.
<stgraber> tedg: so it's currently a blocker for an image we need to release on Thursday and needs to be tested today. So I know we've got the fancy CI process now and I'm fine waiting 2-3 hours for you to go through that.
<stgraber> tedg: but if that's not done by then, I'll just dput it straight to the archive and add a manual unblock in britney to bypass the touch block
<xnox> tedg: right - recommends has no affect on the touch image, so indicator-sound must be seeded. Thus Recommends should be dropped, as one doesn't want gnome-control-center on touch.
<stgraber> right, the way touch works means the change is guaranteed no-op there, so I don't buy the "affects touch" part :)
<tedg> xnox, Well we've done all the other indicators with the recommends the other way.  So I'd prefer to keep them the same.  Or I guess change all.
<tedg> Not sure why indicator-sound ended up backwards.
<xnox> tedg: instead seeds need to be correct for the menu-item to be correct in the indicator-sound. And probably indicator-sound should hide the menu-item if it can't find neither ubuntu-system-settings nor gnome-system-settings.
<xnox> tedg: recommends are _not_ installed on touch images. So recommends really has no effect on touch images. Not sure how the rest of them were done.
<xnox> tedg: i see explicit seeds on touch.
<tedg> xnox, Sure, but that's additional test code for an invalid scenario, I'd rather fix it in packaging than write more tests :-)
<stgraber> tedg: I think dropping the recommend from all of them would make more sense since recommends are ignored on touch. Having the recommend there just makes it that much more confusing when people are trying to figure out why a package is or isn't installed on a particular image.
<xnox> tedg: you can do "Recommends: gnome-control-center" as it will not be installed on touch, but will be installed on normal "fat" desktops.... until we converge that is.
<tedg> I guess the difference for me is "can do" vs. "communicates what we're trying to say"
<tedg> Sure, it would *work*.  But "Recommends: gnome-control-center | ubuntu-system-settings," will work and describes the relationships.
<stgraber> anyway, with my Edubuntu hat on, I don't really care what you end up doint, so long as we get an unbloated image soon, I currently have system-image-* + ubuntu-system-settings + gsettings-ubuntu-touch-schemas + ... so I effectively have no idea whether the bug I'm seeing in the image are a result of that or more important things I need to get solved by tomorrow
<xnox> tedg: it should be valid to install without recommends, yet for you one of them is a hard dependency.
<xnox> tedg: thus above usage of recommends is contradictory to the packaging definition of Recommends, as per http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
<tedg> xnox, "Recommends:  This declares a strong, but not absolute, dependency. "  which is what I think we have.
<stgraber> tedg: accept that as far as touch is concerned you could just as well have put that in the description field since dpkg on those images cares as much about the description field as it does about the recommends one :)
<xnox> tedg: but you say indicator-sound is buggy, if your single recommends  is not present. (single, but can be satisfied by one of the two or both packages)
<tedg> stgraber, Sure, but isn't that something we'll fix on touch eventually?
<xnox> tedg: not in 13.10.
<xnox> tedg: and we need to release working 13.10 images for both touch & edubuntu
<tedg> xnox, Sure, but I can't express "one of these depending on which frontend you're using" :-)
<stgraber> tedg: I hope we'll be consistent in that regard for 14.04, yes
<stgraber> tedg: anyway, I'll get back to doing some work. I'll get back to Edubuntu stuff at 2pm here (in 3 hours), would be nice if you could get that thing fixed and landed by then. If it's not at that point, let me know how far you got and I'll cowboy the rest.
<tedg> stgraber, K.  https://code.launchpad.net/~ted/indicator-sound/recommends-reorder/+merge/187265
<xnox> tedg: but when recommends will be enabled on both touch & desktop, "Recommends: gnome-control-center | ubuntu-system-settings" will still be wrong, as it will then instead pull in gnome-system-settings into touch images.
<xnox> And e.g. desktop starting to use ubuntu-system-settings while edubuntu continues with gnome-system-settings for example.
<stgraber> tedg: that trailing comma is confusing
<tedg> xnox, Not if ubuntu-system-settings is seeded, no?
<tedg> stgraber, I thought that was supposed to be to make diff's clearer?
<stgraber> tedg: hmm, I suppose it does when it's a vertical list
<stgraber> tedg: I'm just surprised dpkg isn't picky about this, but yeah, if that works, fine :)
<xnox> tedg: we have seeds exactly because there is no way to correctly order recommends for all packages. And at the moment, despite correct seeding, edubuntu seed is pulling the first recommends (ubuntu-system-settings).
<tedg> xnox, I guess, are you sure edubuntu seed gnome-system-settings?
<xnox> tedg: yes.
<tedg> Hmm.  That's weird.
<tedg> xnox, I think it's a foundations bug then.  /me closes
<tedg> :-)
<Laney> gnome-control-center!
<xnox> tedg: two members of foundation are asking you to remove the buggy recommends and use seeds instead.
<xnox> (stgraber and I)
<xnox> tedg: your move ;-)
<Laney> it does sound like a bug in the image process though, to be fair
<tedg> xnox, So you're saying foundations is lazy and won't fix its bugs?
<Laney> even if I agree with you guys that the quick fix is fine
<xnox> tedg: I'm saying your usage of recommends is broken, and not what it is intended to be used for.
<stgraber> Laney: well, kinda, I didn't look at an apt debug output, but my guess is that based on ordering, both end up having the same weight (as uninstalled, recommended packages) and so whichever is first wins.
<tedg> Anyway, yes.  That fix short term.  But it things like seeded things should always satisfy first.
<Laney> But you get both, right?
<tedg> Seems like I should be able to put something at the end of "infinite |s" and if it's seeded, that's the one that is taken.
<stgraber> Laney: I do indeed, as I said, would need to look at an apt debug output to figure it out, chances is it's doing it in multiple run and Edubuntu is getting unlucky where Ubuntu is being lucky
 * Laney nods
<xnox> tedg: the correct way to do this is for you to do Recommends on a virtual package "system-settings" and then have both types of settings-mangers provide that virtual package. then the seeds will work correctly.
<stgraber> Laney: ah, no, much simpler than that actually :)
<stgraber> Laney: ubuntu-system-settings is in universe
<xnox> tedg: not on an " bar | baz" alternative.
<stgraber> Laney: so it'd have been used in Ubuntu as well if it was in main
<stgraber> Laney: Ubuntu builds without universe, Edubuntu builds with it
<Laney> haha
<stgraber> Laney: so an Ubuntu netboot install would currently get you ubuntu-system-settings too
<tedg> xnox, In the dependency resolution I can't see what the difference is there.  Effectively it's creating a temporary "tmp32" that both provide and then resolving to that.
<stgraber> (one more reason to fix this ASAP as that means we probably have a bunch of users who have it on their Ubuntu desktop too...)
<Laney> Yeah, I think it should be fixed now but it'd also be interesting to find out if the reason it showed up is fixable
<cjwatson> if you explicitly seed something that should take precedence, both in germinate and apt
<cjwatson> but it has to be seeded in the same or an interior seed, not something exterior
<cjwatson> xnox: that won't help, germinate and apt would both produce nondeterministic results for a bare virtual
<xnox> oh. ok.
<cjwatson> tedg,stgraber: I can look into the seed resolution point soon but not now
<xnox> cjwatson: what's the difference between interior vs exterior seeds? is include platform.saucy exterior?
<xnox> cjwatson: why would the result for a bare virtual be nondeterministic, if a package that provides it is already seeded?
<Laney> I guess it means that edubuntu's seed just has a dependency on the ubuntu-desktop package
<xnox> Laney: but e.g. gnome-control-settings is listing Task: edubuntu-desktop
<ogra_> ubuntu toucxh doesnt (and probably will never) respect recommends
<ogra_> that recommends is totally bogus
<xnox> Laney: s/settings/center/
<ogra_> just drop it altogether
<cjwatson> xnox: no I mean desktop is outside desktop-common but desktop is inside live
<cjwatson> xnox: It shouldn't be nondeterministic if a provider is already seeded, but nor should foo | bar
<cjwatson> xnox: So no gain
<tkamppeter> jdstrand, OK.
<tumbleweed> hpodder fetch
<tumbleweed> grr
<pitti> awe_: wrt. the phone call stack, does this look about right? dialer-app â telephony-service-handler â telepathy-ofono â ofono ?
<awe_> yes
<pitti> awe_: does anythign except telepathy-ofono talk to ofonod?
<awe_> pitti, in mid-stand-up
<pitti> awe_: thanks; I was wondering what I have to restart in order for recording ofonod (my approach from a few weeks ago doesn't work any more)
<pitti> awe_: nevermind, can talk later
<didrocks> jamespage: doko: we have an issue with latest libunwind: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz
<jdstrand> tkamppeter: thanks!
<awe_> pitti, I just finished the stand-up
<lool> (thanks didrocks)
<lool> RAOF: ^
<didrocks> jamespage: doko: downgrading to 1.1-1ubuntu2 works
<awe_> pitti, yes.. there are multiple processes that can/do talk to ofonod
<didrocks> any of you can help figuring this out?
<didrocks> (this is blocking Mir landing)
<didrocks> asac: FYI, now that we have for sure the culpurit component ;) ^
<awe_> telepathy-ofono, system-settings and NM are the top three...
<awe_> pitti, fyi... we have a new guy in PES who I asked to do some work with umockdev/ofono last week
<awe_> I was planning on emailing a few folks ( you, Jualian, ... ) to discuss
<jamespage> didrocks, does your build use pkg-config files?
<awe_> as Alfonso ( abeato ) has run into some of the same kind of issues you may now be seeing
<jamespage> that was introduced in 1.1-2
<pitti> awe_: ah, maybe; it was working quite well a few weeks ago, but now it seems there is a lot of chatter from all different places towards ofonod, which makes predictable communications hard
<awe_> exactly
<awe_> that said, there's also some issues with ofono's protocol stream not being deterministic
<RAOF> jamespage: Yes
<pitti> awe_: so I guess for testing dialer-app we should rather provide a dbus-mock of the ubuntu phone service; and test that against a mock of telepathy-phone, and so on
<didrocks> jamespage: it's xorg-server failing to build FYI
<jamespage> didrocks, yeah - I see
<pitti> awe_: testing ofonod itself against a mock rild seems easier, as you can test that in isolation (right now this involves some 5 processes)
<awe_> pitti, let's get the terminology straight, there's telephony-service and telepathy-ofono
<awe_> so you're saying that we should mock telephony-service?
<seb128> tedg, stgraber, hey, why "Recommends: ubuntu-system-settings | gnome-control-center," isn't right if edubuntu has g-c-c installed, shouldn't that be enough for the recommends?
<awe_> for the dialer app tests?
<pitti> awe_: that would be the logical thing (mock the direct layer below you)
<awe_> ( below the dialer app, you mean )?  ;)-
<pitti> awe_: or perhaps telepathy-ofonod, as dialer-app seems to talk to both telephony-service AND telepathy
<pitti> i. e. there doesn't seem to be a clear layer separation
<awe_> right
<RAOF> jamespage: Ah. So the problem was probably always there, just that 1.1-2 actually made the configure check pass.
<pitti> awe_: "ofono's protocol stream not being deterministic" -> did that change recentlY/
<pitti> ?
<stgraber> seb128: if we'd install the indicator after the rest of the system is installed, yes
<awe_> pitti, no, I think you just got lucky
<jamespage> RAOF, might be
<cjwatson> seb128,tedg,stgraber: this is certainly odd - Edubuntu livefs builds install everything by tasks, so germinate's view of the world ought to win
<stgraber> seb128: but we're talking about a rootfs build at which point neither is installed, both come from recommends so they probably end up having the same weight at some point
<RAOF> We've had a timebomb patch in the xserver since March :)
<seb128> stgraber, isn't that going to create the reverse issue for touch then?
<stgraber> seb128: nope, touch doesn't use recommends
<cjwatson> stgraber: it still ought to be controlled by germinate's expansion, via Task field
<cjwatson> s
<RAOF> jamespage: Confirmed that building with unwind 1.1-1ubuntu2 works, but also doesn't actually use libunwind
<awe_> pitti, as mentioned we've done some analysis, and abeato has also come up with some ideas on how we could address these issues..  I'd like to review his notes, and then will share them with you, and others later today
<seb128> stgraber, is that going to stay that way or are we up to get the same issue when we start using them?
<cjwatson> Hmm, gnome-control-center is in Task: edubuntu-desktop, not Task: edubuntu-desktop-gnome
 * ogra_ still votes for just dropping the recommends
<ogra_> add it back in 14.04
<cjwatson> ogra_: I still want to investigate the underlying issue here
<ogra_> and have the headdache then
<pitti> awe_: ack; I currently got an assignment to create some autopilot tests for dialer-app and messaging-app
<pitti> awe_: (some nontrivial ones, that is)
<pitti> awe_: so I guess I'll investigate providing dbus mocks for telepathy next, WDYT?
<awe_> ah, OK I was wondering who the DRI was for that task
<awe_> ;D
<stgraber> seb128: at some point it may be a problem, though if touch ever switches to installing recommends, the fact that ubuntu-system-settings is directly seeded by its main seed should make germinate do the right thing
<pitti> awe_: "DRI"?
<jamespage> RAOF, OK
<awe_> designated responsible individual
<cjwatson> Hm, so Task: edubuntu-desktop is a weird thing
<awe_> sorry, too many acronyms floating around in my head
<jamespage> RAOF, I guess an immediate fix is to drop the libunwind dependency from xord
<jamespage> xorg rather
<awe_> jamespage, what does RAOF mean?
<cjwatson> $ diff -u <(grep-aptavail -nsPackage -wFTask ubuntu-desktop | sort -u) <(grep-aptavail -nsPackage -wFTask edubuntu-desktop | sort -u)
<cjwatson> $
<cjwatson> It really only exists because seeds/ubuntu.saucy/desktop doesn't force a task name
<jamespage> awe_, RAOF is a person - no idea what his/her nick stands for tho
<RAOF> Wow. The build logs for xorg-server on the buildds are rubbish.
<seb128> stgraber, ok, I will trust you and cjwatson to do the right thing here... seems like it should be working still without that change from what cjwatson said?
<RAOF> jamespage: Running Around On Fire
<cjwatson> seb128: continue to follow my stream of consciousness, I'm getting there :)
<jamespage> RAOF, lol - sounds familiar ;-)
<RAOF> I *think* we're not building with LIBUNWIND, but the actual configuration message is âchecking for LIBUNWIND... __threadâ âº
<cjwatson> Task: edubuntu-desktop-gnome includes the ubuntu-desktop metapackage, which normally covers this up because it recursively includes all the same things
<cjwatson> However, this is NOT enough to force the correct expansion in this kind of case
<awe_> hahaha
<RAOF> (This makes more sense in context, as the surrounding checks are about TLS)
<stgraber> seb128: yes, doing that change was the easiest way to get the image back to normal and as the change makes sense anyway (even if only for consistency with the other indicators), it seemed like the right thing to do for now.
<cjwatson> The way apt works, it installs all the packages it's been explicitly told to install (which includes every package that a task expands to), and then it tries to resolve any of those that are broken
<cjwatson> But that means that if you have this kind of ambiguity then it can only reliably be solved by top-level entries
<cjwatson> In the case of Edubuntu, gnome-control-center isn't a top-level thing apt's been told to install - it's "just" a dependency of ubuntu-desktop
<cjwatson> So it depends whether apt happens to follow the dependency chain leading to whatever tedg's package is first, or the dependency chain of ubuntu-desktop
<cjwatson> Which is nondeterministic
<cjwatson> stgraber: I am reasonably confident that the correct fix for this is http://paste.ubuntu.com/6150689/
<cjwatson> We should also kill Task: edubuntu-desktop - it does nothing useful except bloat the Packages file
<cjwatson> But that's less safe, so I'd probably prefer to do that at the start of next cycle
<cjwatson> (Because we have to make sure nothing is using it)
<stgraber> cjwatson: yep, that live-build change makes sense since edubuntu-desktop-gnome always include ubuntu-desktop anyway
<cjwatson> stgraber: Want me to upload it?  Is there a bug number?
<stgraber> cjwatson: no bug number, feel free to upload
<cjwatson> stgraber: done
<cjwatson> tedg: see, Foundations fixes its bugs :-P
<cjwatson> tedg: (which is independent of whether your use of Recommends is correct - I don't much care either way on that)
<tedg> Heh
<tedg> Not sure if I prefer a fix to to give xnox a hard time ;-)
<tedg> or to
<stgraber> tedg: so with cjwatson's change, our next image should be good regardless of the indicator change, so I still think it's worth fixing just for consistency's sake (and also to make the netboot installs less broken) but it's certainly less critical now
<xnox> =)))))))))))))))))
<cjwatson> stgraber: I think you're mistaken that an Ubuntu netboot install would get ubuntu-system-settings - it uses Task: ubuntu-desktop which should solve the ambiguity
<xnox> tedg: well.... =)
<asac> didrocks: whats the culprit component?
 * asac tries reading backlog
<didrocks> asac: libunwind, RAOF and jamespage are working on a fix
<tedg> stgraber, Okay, so I won't push for a release for just that.  But it'll be fixed in trunk and get out in the next release set.
<stgraber> cjwatson: ah yeah, but it'll still be wrong for Edubuntu then, right?
<cjwatson> stgraber: Edubuntu netboot I'm not sure of, it might still need a tweak
<mterry> zul, how come python-wsme doesn't Depend on python-pycherry3?
<RAOF> didrocks: Shiny new Xserver in your inbox.
<cjwatson> Let me check
<didrocks> RAOF: directly delivered at home? I hope there is no extra charge ;)
<jamespage> RAOF, are you trying the drop the dependency hammer?
<asac> didrocks: good news.  thanks
<RAOF> jamespage: Indeed
<cjwatson> stgraber: No, Edubuntu netboot is fine - it so happens that it's been explicitly including the ubuntu-desktop task since intrepid
<RAOF> jamespage: That seems like the most sensible course at this point.
<zul> mterry:  not sure
<stgraber> cjwatson: nice!
<cjwatson> stgraber: See bug 276317
<ubottu> bug 276317 in tasksel (Ubuntu) "Intrepid: Netboot. Edubuntu meta doesn't include things like OO.o or FF" [Low,Fix released] https://launchpad.net/bugs/276317
<Laney> pitti: writable directories work
<didrocks> RAOF: I think you saw the new failures
<didrocks> maybe it's my fault, but I didn't touch anything from your dsc
 * didrocks looks
<RAOF> ...
<RAOF> Oh, whoops.
<didrocks> quilt push -a is happy
<gcds> Hello, maybe someone could recommend data protocol to communicate between processes using unix domain sockets?
<RAOF> Shouldn't be.
<didrocks> but I don't see it ;)
<didrocks> weird
<didrocks> why doesn't it yell here?
<didrocks> Applying patch os-use-libunwind-to-generate-backtraces.patch
<didrocks> didrocks@tidus:/tmp/xorg-server-1.14.2.901$
<didrocks> RAOF: weird, isn't it? ;)
<didrocks> anyway, your patch would interest me ;)
<RAOF> didrocks: Drop the patch from debian/patches/series :)
 * RAOF forgot to do that
<didrocks> RAOF: ah ok
<doko> seb128, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/4993076 (gtk2-engines)
<seb128> doko, ok
<didrocks> and built on armhf, thanks RAOF!
<doko> didrocks, did you see my message about the unity-* and friends ftbfs?
<RAOF> Hurray!
<didrocks> doko: yeah, it's building in the ppa, so I think next landing will fix those
<didrocks> doko: don't have time to investigate in why the tests results don't fetch the right ones
<infinity> doko: Re: corosync, looks like the new version doesn't include coroipcc.
<didrocks> (it seems you didn't see the ping about libunwind though, but we got that fixed thanks to RAOF)
<infinity> roaksoax: Can you check out https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5010725 ?
<doko> infinity, yes found out the same
<infinity> doko: Oh, hrm.  Did you only drop the SPU stuff from gcc-4.8 and gcc-snapshot, but not older releases?
<infinity> doko: Looks like 4.4/4.6/4.7 are still holding newlib in main.
<doko> shouldn't be there on it's own
<infinity> (base)adconrad@cthulhu:~$ reverse-depends src:newlib
<infinity> Reverse-Depends
<infinity> ===============
<infinity> * gcc-4.4-spu                   (for newlib-spu)
<infinity> * gcc-4.6-spu                   (for newlib-spu)
<infinity> * gcc-4.7-spu                   (for newlib-spu)
<infinity> (base)adconrad@cthulhu:~$ reverse-depends -b src:newlib
<infinity> Reverse-Build-Depends
<infinity> =====================
<infinity> * gcc-4.4                       (for newlib-spu)
<infinity> * gcc-4.6                       (for newlib-spu)
<infinity> * gcc-4.7                       (for newlib-spu)
<doko> but why are these versions in main?
<infinity> Because things {Build-,}Depend on them, I suppose.
<doko> infinity, gmime and libunistring have test failures for locking cases
<infinity> doko: Oh, only 4.7 is in main, the other two are in universe.
<doko> test cases
<infinity> (4.7 in main is, at least, my fault...)
<roaksoax> infinity: sure!
<infinity> And grub2, and u-boot, and a few others.
<doko> even the kernel still uses gcc-4.7 on armhf
<infinity> Yeah.
<doko> we'll have to keep 4.7 for the whole android compat stuff, I assume
<bdmurray> slangasek: the other week we'd decided to let the fix for bug 1058884 be superceded by a security upload correct?
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
<cjwatson> doko,infinity: mm, I can maybe see about switching grub2 to 4.8
<sarnold> mlankhorst: I'll start glamor-egl audit today, once I'm caught up on the outstanding pings left over from my long weekend; I expect to finish it today (if it's really nice code :) or tomorrow (more likely)
<roaksoax> infinity: i think we can actually drop it from the archives, but i'll need to look into reverse deps
<roaksoax> infinity: http://pastebin.ubuntu.com/6151010/
<infinity> cjwatson: I wouldn't stress it too much, I'm not moving eglibc to 4.8 in this cycle.  Shows testsuite regressions I don't have the time to fix before release.
<infinity> roaksoax: http://paste.ubuntu.com/6151025/
<roaksoax> infinity: os in fedora asterisk-ais related stuff has been dropped
<roaksoax> and fedora doesn't ship ocfs2-tools
<roaksoax> but we can drop it
<infinity> roaksoax: pacemaker-mgmt needs transitioning to the corosync new world order too (or also removal?)
<cjwatson> Yeah, I tried to rebuild that but it failed
<roaksoax> infinity: i'm gonna look at it now
<infinity> roaksoax: If you could figure out the remaining corosync rdeps and finish the transition and file a removal bug against all the packages you think need to go, that would be helpful.
<roaksoax> infinity: will do, thanks for finding this out!
<slangasek> bdmurray: bug #1058884> yes
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
<bdmurray> mdeslaur: ^
<mdeslaur> thanks bdmurray, slangasek
<infinity> slangasek: Is that still a thing?  I thought barry had hacked around that?
<infinity> slangasek: Oh, it never got out of proposed.  Sadness.
<slangasek> infinity: the fix is nearly impossible to do an SRU verification on and we have at least one possible regression report, so it's not published, yeah
<infinity> sarnold: Oh hey, good timing.  I was just about to bug you about glamor-egl and noticed you'd assigned the bug to yourself.  Does that mean the audit is underway and I should shut up and leave you alone?
<sarnold> infinity: indeed, it's just sitting behind the morning's email and triage run..
<infinity> sarnold: \o/
<sarnold> :D
<sarnold> down to only FOUR MIR audits, it feels good :)
<infinity> sarnold: Want me to get you some more?
<sarnold> infinity: it -is- kinda fun :) I just wish I weren't blocking co-workers ...
<mterry> xnox, you work with cherrypy3, right?
<infinity> sarnold: Well, I try to only poke you when I think something really should be audited (like this case, library linked by X driver running in ring 0, WCPGW), but I can certainly give you more work. :P
<sarnold> infinity: lol
<barry> slangasek, infinity yeah
<mterry> zul, cherrypy3 has tests that aren't being run.  They seem to require cherryp3 to be installed first.  Any chance we can dep8-ify them?
<zul> mterry:  sure
<gcds> Hello, maybe someone knows how to add library dependency to configure file /
<gcds> I have modified c app to use one library but would like to add it to the configuration file
<slangasek> stgraber: so you moved the milestone on bug #1206872, but ... is that bug still an issue?
<ubottu> bug 1206872 in samba (Ubuntu Saucy) "samba fails to unpack (behavior change in patch) and ftbfs on aarch64" [High,Incomplete] https://launchpad.net/bugs/1206872
<slangasek> doko: ^^ can you tell me whether samba still needs config.* updates for aarch64?  If so I can certainly poke at it
<stgraber> slangasek: I don't know, I just ran move-milestoned-bugs on all past milestones
<slangasek> stgraber: ah :)
<doko> slangasek, I don't know, wanted to wait for a build on real hardware
<slangasek> doko: what's the first version of config.sub that supports aarch64?
<slangasek> I can just check the source quickly
<doko> slangasek, just grep for aarch64, that should be fine
<doko> xnox, could you have a look at the libvigraimpex ftbfs? multiarch'd boost?
<ari-tczew> every bug has to be ACKed until is sponsored by release team since yesterday?
<slangasek> doko: hah, so the current samba in unstable has config.sub from 2009... yeah, guess that'll need an update
<infinity> slangasek: dh_autotools-dev or dh_autoreconf to the rescue?
<slangasek> infinity: eventually
<infinity> slangasek: dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig can be nicely hooked into old skool rules files that aren't dh(1) friendly.
<infinity> slangasek: And still much cleaner than shipping a big config.* diff.
<infinity> slangasek: (and the added bonus of Just Working for new ports)
<doko> infinity, libidn has another locking test failure
<infinity> doko: Fun. :/
<infinity> doko: Worse, it works on Debian.
 * infinity grabs the source to test on current Debian and see if that's still true.
<smoser> dpkg-query --show | grep zlib
<smoser> zlib1g:amd64	1:1.2.8.dfsg-1ubuntu1
<smoser> why does that say ':amd64'
<infinity> doko: Bah.  It builds fine on my kernel.  Might only break on precise's...
<smoser> when none of the other packages ('zlib' say :amd64).
<infinity> smoser: Because it's a multi-arch:same library.
<infinity> (base)adconrad@cthulhu:~$ dpkg -l libc6 | awk '/^i/ {print $2}'
<infinity> libc6:amd64
<infinity> libc6:i386
<infinity> smoser: ^-- For example.
<infinity> smoser: MA:same stuff shows the arch, because you can have more than one.
<infinity> doko: Oh, wait.  That was on sid where it worked.  I'm not awake.  *tries saucy locally now*
<smoser> infinity, thanks.
<infinity> doko: Okay, yeah, libidn failure reproduced locally.  Can I blame your toolchain?  Seems more likely than my 3 glibc patches. :P
<smoser> so if you debconf-set-selections libc6 values without ':arch', which do they apply to ?
<infinity> smoser: Without an arch qualifier, you get the native arch.
<infinity> smoser: Though, in the case of debconf, the templates are probably shared between all of them anyway.
<cjwatson> Yeah, debconf doesn't use the arch qualifier for its owner fields.
<infinity> Well, it COULD.  It's up to the maintainer to do so, though.
<infinity> (base)adconrad@cthulhu:~$ debconf-show libc6
<infinity>   glibc/upgrade: true
<infinity> * glibc/restart-services: ssh exim4 cups cron atd
<infinity> * libraries/restart-without-asking: false
<infinity>   glibc/disable-screensaver:
<infinity>   glibc/restart-failed:
<cjwatson> Owner, not namespace.
<cjwatson> Actually I wonder if my previous statement is true.
<infinity> ^-- I could be generating those with arch qualfiers during build, and naming them explicitly in maintainer scripts.
<infinity> But why would I?
<cjwatson> elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst|postrm|prerm)$!) {
<cjwatson>         $package=$1;
<cjwatson> infinity: The owner is used for garbage-collection on purge.  It's not part of the question name.
<infinity> cjwatson: Oh, right.  I always forget that owner and namespace are two things for reasons I don't grasp.
<cjwatson> But it is mentioned as the first field in debconf-set-selections input.
<cjwatson> $ debconf-get-selections | grep libc6: | head -n2
<cjwatson> libc6:amd64     glibc/upgrade   boolean true
<cjwatson> libc6:i386      glibc/upgrade   boolean true
<cjwatson> That probably actually makes sense, since they want to be GCed independently on purge.
<infinity> Perhaps, yeah.
<cjwatson> In practice, getting the wrong owner at worst means that your preseeded answer is immortal and never gets purged.
<infinity> Or it could be (but isn't, apparently) done the way dpkg file ownership is done, via refcounting.
<cjwatson> And for libc6, it really doesn't matter.  It's going to stick around forever anyway.  Likewise zlib1g, not that that has any debconf templates.
#ubuntu-devel 2013-09-25
<cjwatson> (It's still got the vestigial 'g' from the ELF transition.  A SONAME transition doesn't seem likely.)
<infinity> cjwatson: An SONAME transition seems incredibly unlikely, but I've been itching to rename it "libz1" for a decade.
<infinity> cjwatson: It just rubs me the wrong way that a library in the base system flies in the face of proper package naming policy. :P
<infinity> (Though, entertainingly, it Provides: libz1)
<smoser> ok. its that time again... smoser questions
<smoser> previously i used debconf to prsed some data to cloud-init.
<smoser> that allowed you to drive cloud-init configuration via preseeding
<smoser> then http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709773 bug was opened, claiming i was using debconf as a registry
<ubottu> Debian bug 709773 in cloud-init "Wrong handling of debconf" [Serious,Fixed]
<smoser> which, i guess iw as.
<smoser> so i reverted that behavior.
<smoser> but how, i can't do: chroot some-root < some-preseed && chroot some-root dpkg-reconfigure cloud-init
<smoser> as the configured values get read over the ones in debconf.
<smoser> which is i ugess the point.
<cjwatson> Yes, the defined intention of debconf is that the filesystem wins
<cjwatson> You'll have to adjust the configuration files, or clear the configuration such that the questions get reasked by cloud-init's postinst
<smoser> ok. i can do that. thanks, cjwatson.
<smoser> cjwatson, is there a standard way for "clear the configuration"?
<smoser> what does ubilquity do for any thing that it collects that would change values of an already installed package?
<smoser> or are there just no such things.
<smoser> basically i'm wanting to let someone spit debconf-selections into a cloud-image and then re-set the settings of installed packages from those settings.
<smoser> and let anything to-be-installed just happen at that point
<cjwatson> ubiquity has a few "nuke config file from orbit and reconfigure" bits.
<cjwatson> It's not standardised.
<cjwatson> http://paste.ubuntu.com/6152484/
<cjwatson> that kind of thing
<smoser> you rock. thanks.
<cjwatson> usually it's nice if removing the config file does the trick
<leo_33> in your opinion are the jews responsible for most of the evil in the world?
<infinity> That was a quick response.
<mwhudson> um
<mwhudson> warning: the debug information found in "/usr/lib/debug//usr/bin/memcached" does not match "/usr/bin/memcached" (CRC mismatch).
<mwhudson> i have memcached and memcached-dbgsym (of the same versions) installed
<mwhudson> and get that ^
<mwhudson> (on armhf)
<mwhudson> problem at my end or in the archive?
<sarnold> mwhudson: my pandaboard rarely gives me the same data off disk twice. heh. can you check debsums?
<int_ua> 1. The link to channels is kind-of wrong on http://www.ubuntu.com/support/community/chat It should lead to https://wiki.ubuntu.com/IRC/ChannelList
<int_ua> 2. https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1170487 Is fixed upstream but needs a release. It prevents _all_hooks from running and the resulting bug reports end up missing crucial files.
<ubottu> Ubuntu bug 1170487 in apport (Ubuntu) "TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [Medium,Fix committed]
<int_ua> anyone home?
<sarnold> int_ua: probably "fix committed" is the wrong status; that means the fixed _package_ has been checked in and waiting to be released ...
<int_ua> sarnold, changed
<sarnold> int_ua: aha, here we go, the best place to report #1: https://bugs.launchpad.net/ubuntu-website-content/+filebug
<int_ua> sarnold, thanks, In Progress :)
<sarnold> int_ua: woot, thanks :)
<int_ua> sarnold, https://bugs.launchpad.net/ubuntu-website-content/+bug/1230072
<ubottu> Ubuntu bug 1230072 in ubuntu-website-content "Link to the list of IRC channels is wrong on /support/community/chat" [Undecided,New]
<sarnold> int_ua: very nice, thanks
<pitti> Good morning
<pitti> Laney: so we need to modify whatever builds those images to include the directory, and declare it writable?
<pitti> wgrant, StevenK: hmm, still no new -base export at https://translations.launchpad.net/ubuntu/saucy/+language-packs ?
<pitti> I requested one last week for final beta, but I guess it's too late now
<wgrant> pitti: Might have failed during some of the DB maintenance last week.
<dholbach> good morning
<xnox> doko_: re: libvigraimpex, ok will look at it.
<Laney> pitti: Yeah, I guess livecd-rootfs for the former (as stgraber said; ogra_ is the master of that package) and lxc-android-config etc/system-image/writable-paths for the latter
<Laney> for testing you can edit writable-paths on your system
<ogra_> LOL
<ogra_> i'm surely not the master :)
 * Laney looks at the changelog :P
<ogra_> i just change it more often than others i guess
 * ogra_ tries to find out what this is about after all :)
<ogra_> pitti, make merge proposals for both packages /or bugs with debdiff or whatever) ... then ping me so i can add a request to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 (unless you can edit yourself, then just add it on "landing asks" and assign me)
<alberts> xnox: hi! could you please look at these merge proposals - https://code.launchpad.net/~attente/ubuntu-themes/lp1228809/+merge/186967 and https://code.launchpad.net/~attente/ubuntu-themes/lp1228814/+merge/187024?
<xnox> alberts: approved. They should get auto-merged, if not I'll merge them myself.
<alberts> xnox: thanks!
<pmjdebru1jn> hi folks
<pmjdebru1jn> I noticed saucy's libc is built with gcc 4.7.x while most of the rest is built with 4.8.x, anybody a clue why?
<pmjdebru1jn> I aware it shouldn't matter much technically... but I found it rather peculiar
<pitti> Laney, ogra_, stgraber: I tried to understand the details and followed up on bug 1227520; there's one thing which isn't clear to me yet
<ubottu> bug 1227520 in systemd (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,Incomplete] https://launchpad.net/bugs/1227520
<cjwatson> pmjdebru1jn: 18:24 <infinity> cjwatson: I wouldn't stress it too much, I'm not moving eglibc to 4.8 in this cycle.  Shows testsuite regressions I don't have the time to fix before release.
<cjwatson> pmjdebru1jn: A few particularly sensitive packages need to be upgraded to new compiler versions rather carefully.  Boot loaders are often in that category too.
<Laney> pitti: replied
<pitti> Laney: thanks; and yes, /etc/writable/zoneinfo == /etc/writable/localtime
 * Laney nods
<pmjdebru1jn> cjwatson: ok fair enough
<pmjdebru1jn> cjwatson: so I guess saucy will be half-way to the next LTS can be full 4.8 I guess?
<pmjdebru1jn> /to/so/
<cjwatson> pmjdebru1jn: I don't know that I'd put it that way.  Firstly, we're a lot more than halfway; secondly, we're in a more or less continual process of upgrading to newer versions of things like this.
<pmjdebru1jn> oh? there no attempt to get this stuff in a consistent state?
<pmjdebru1jn> it's not the end of the world of course, particularly for C
<cjwatson> pmjdebru1jn: We try to avoid having to support more compiler versions than we need to, but consistency in itself isn't always the highest goal
<pmjdebru1jn> right
<pmjdebru1jn> just out of curiousity are there thing in gcc 4.8, that make it important to move to it as quickly as possible?
<pmjdebru1jn> besides getting stuff done ahead of the next LTS
<cjwatson> There are always improvements, but I don't think there was anything earth-shatteringly out of the ordinary
<cjwatson> http://gcc.gnu.org/gcc-4.8/changes.html if you're interested
<cjwatson> Of course, most packages just use the default compiler version to build.
<pmjdebru1jn> ah I see lots of C++ related improvements
<pmjdebru1jn> right
<pmjdebru1jn> ok, thanks
<ogra_> pitti, hmm, i'll better leave that to stgraber, thats actully his domain
<alberts> xnox: that two merge proposals for ubuntu-themes still shows status - needs review
<xnox> alberts: yeah, I'm expecting for the upstream bot to merge. If that doesn't happen by the end of the day, I'll merge them by hand.
<Laney> they won't merge if they're at needs review
<Laney> you need to change the top status
<Laney> xnox:
<xnox> ... to what?
<Laney> Approved
<xnox> hm, ok. let me do that.
<pitti> ogra_, Laney: hm, seems once /etc/timezone and friends ever went into writable-paths, they stay writable even if I drop them and reboot (with r/o)
<ogra_> pitti, yeah, there should be bind mounts into the writable space
<pitti> so I guess to truly test this we need to get these two changes into a new image so that /etc/timezone really stays r/o
<pitti> ogra_: that's the thing, there aren't any more
<pitti> actually, it's more general
<pitti> I can even create /foo now
<pitti> so it seems even after removing /userdata/.writable_image and rebooting, the image still stays writable
<Laney> hm, that worked to make it ro for me
<ogra_> pitti, if you made any changes it will
<ogra_> (in the readonly space)
<pitti> ogra_: ah, is there a trick to make it r/o again?
<ogra_> afaik it is  not possible
<pitti> ogra_: ok, then I suggest we get these two changes in ASAP?
<ogra_> pitti, so the last changes dont help because ?
<pitti> in the meantime I'll work on timedated and just watch strace to make sure it doesn't try and touch /etc/* directly
 * ogra_ just uploaded a change for exactly these files on mon or tue
<pitti> ogra_: they do help, it just seems hard to apply them manually
<pitti> ogra_: I meant the changes I just psuhed to the branches, but not uploaded yet (see bug)
<ogra_> well, i think cwayne had a plan to work around debconf and stuff
<pitti> ogra_: nope, making /etc/timezone and friends bind mounts doesn't work
<ogra_> from the timezone settings
<ogra_> well, he tested it before requesting inclusion
<ogra_> at least he claimed to
<pitti> ogra_: well, they become writable, but that's not the point
<pitti> the point is with mounts it's impossible to atomically change a file
<ogra_> they become writable and get contet changes via the new settings app is what i was told
<pitti> and hence that "mount points over files" approach is an utter hack which we shouldn't use for many files
<ogra_> by copying the timzone data in
<pitti> ogra_: yes, but I am not going to do that in timedated
<pitti> ogra_: Laney and stgraber discussed a better approach in the bug with symlinks
<ogra_> could you coordinate with cwayne ?
<ogra_> i kknow there are people tryning to implement it differently atm
<pitti> ogra_: system-settings is fine, it just talks to timedated; and I got the task assigned from Laney to update that
<Laney> I was talking with cwayne when we discovered the problem
<pitti> ogra_: but yes, I can ping him this afternoon about this
<pitti> subscribed him to bug 1227520, too
<ubottu> bug 1227520 in systemd (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,Triaged] https://launchpad.net/bugs/1227520
<ogra_> pitti, https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone was merged for it already ...
<ogra_> there was a second one i'm just trying to find
<pitti> ogra_: yes, I reverted that and pushed the new approach
<ogra_> how did you revert it ? i dont see it on the landing requests
<pitti> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/revision/102
<pitti> goes together with http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/848
<ogra_> https://code.launchpad.net/~cwayne18/phablet-tools/phablet-timezone-setup/+merge/186891 is the second one
<pitti> (I didn't upload these yet, as I asked for eyeballing on the bug)
<ogra_> pitti, please coordinate through the spreadsheet else we have a mess ...
<cjwatson> ogra_: https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone isn't recorded as merged, and my comments on it weren't entirely addressed so it shouldn't have been ...
<ogra_> we cant land anything without asac approval though the new process
<cjwatson> (my comments line up with what pitti is working on)
<pitti> ogra_: I can't change the spreadsheet
<ogra_> cjwatson, it says Merged at the top ... and i'm sure there is an entry for it on the spreadsheet
<pitti> ogra_: from my POV, I got that bug assigned, and all info is there now
<ogra_> (line 81 on landing asks)
<cjwatson> ogra_: No, https://code.launchpad.net/~cwayne18/ubuntu/saucy/lxc-android-config/timezone/+merge/186953 says "Needs review" at the top
<Laney> it sure did get merged
<cjwatson> Sigh
<ogra_> pitti, right, either reqest write access from asac in #ubuntu-ci-eng or go through your manager
<cjwatson> Why do I bother with review comments, I wonder
<Laney> not uploaded though? does it need to be?
<cjwatson> Since one of my review comments was explicitly that this was a bad idea to merge because it would create upgrade trouble
<Laney> oh, no, it was uploaded :(
<ogra_> cjwatson, it landed (with typo fix) on tuesday i think, no reason we cant roll it back indeed
<cjwatson> ogra_: My understanding is that persistent mounts can't be undone without wiping user data
<ogra_> cjwatson, yeah ... we dont really have transitioning of that yet on upgrades
<cjwatson> But I am pretty annoyed if this was landed despite our comments saying it shouldn't be
<cjwatson> If all our tremendous complexity around touch landings doesn't avoid landings that have had negative reviews, what good is it?
<ogra_> there was no such comment  when i reviewed it, and the people asking for it claimed they had run all tests with the new implementation which was the merge criteria
<ogra_> cjwatson, it all only revolves around the tests ...
<pitti> well, obviously they didn't, as timedated (which system-settings seems to use) is unable to atomically update these files
<cjwatson> ogra_: I commented on that MP almost as soon as cwayne posted it, and he made the typo correction in response to my review
<cjwatson> ogra_: So I don't believe you :-)
<ogra_> pitti, they use it at flashing time, see the second commit to phablet-tools above
<Laney> pitti: I guess cwayne was thinking in terms of his script and not u-s-s
<cjwatson> If the upload includes the typo correction, as you said above that it did, then it was strictly after my review
<pitti> well, as long as adb push resolves symlinks on write, so that it will actualy write /etc/writable/timezone (and friends), it should be okay
<ogra_> cjwatson, there were no comments at all when i merged it ... whats intresting though is that the MP was never set to Merged even though the branch landed
<ogra_> (i probably didnt reload the MP before merging though)
<cjwatson> ogra_: There was also extensive and noisy discussion on #ubuntu-touch at the time :-(
<cjwatson> I'm sorry, I think our merge criteria aren't fit for purpose if they don't notice this kind of thing.
<ogra_> "at that time" can you specify that ?
<ogra_> https://launchpad.net/ubuntu/saucy/+source/lxc-android-config/0.101
<ogra_> the upload happened on monday
<ogra_> and i think the discussions happened a lot later
<Laney> it was Monday late afternoon UK time
<cjwatson> ogra_: It was strictly before that upload
<cjwatson> http://irclogs.ubuntu.com/2013/09/23/%23ubuntu-touch.html#t15:32 e.g.
 * ogra_ must have missed it then
<Laney> I think that I told cwayne during the discussion to make that change though, before my understanding had fully developed
<Laney> And then never explicitly revisited it
<ogra_> well, it is in and we will just roll it back ...
<ogra_> its a three line change
<ogra_> (or uppdate it to something else)
<pitti> the update I pushed removes those and adds /etc/writable/
<pitti> which is supposed to be that place where we can do double symlinks or just files which we need to atomically rename
<pitti> (probably won't work with conffiles, so we sohuldn't use it for those)
<ogra_> right, i would like to hear from stgraber about that first though
<ogra_> (and its not on the landing plan at all)
<pitti> ogra_: stgraber responded yesterday in teh bug how to do these changes
<ogra_> pitti, conffiles ? why to dou care ?
<ogra_> we dont officially support apt updates
<pitti> ogra_: I'm not sure dpkg would DTRT with conffiles which have been set up as symlinks
<pitti> still, I would ban conffiles from that approach for now
<ogra_> at image build time you mean ?
<pitti> ogra_: for symlinking/moving to /etc/writable/
<pitti> I'm fairly sure that dpkg will update conffiles atomically as well, so we cannot currently handle them anyway
<ogra_> ??
<cjwatson> Yes, best avoided since many of our testing tools still use apt even on writable images
<ogra_> we dont allow dpkg
<cjwatson> Er, even on RO images
<pitti> but my hope is still that all those hackery will go away with a proper overlayfs
<cjwatson> (after mounting RW, obviously)
<ogra_> pitti, wonr happen
<ogra_> *wont
<pitti> ogra_: well, like this a converged image won't happen :)
<ogra_> yeah, converged might be different
<ogra_> but converged isnt on topic before 14.10 i was told
<pitti> sure, I didn't say "tomorrow"
<ogra_> and i dont think we want to maintian tons of patches for tons of different android kernels
<pitti> anyway, so what are the next steps now?
<ogra_> adding it to the spreadsheet
<pitti> so apparently someone needs to update that gdocs to include these two commits, and ack getting them in?
<pitti> I'll work on timedated in the meantime
<ogra_> both changes should be fine for bypassing the beta freeze, only touch related changes/packages involved
<ogra_> pitti, the comment from stgraber on the bog doesnt sound like agreement to me
<pitti> well, I haven't heard any other solution yet
<pitti> (and I mean "solution", not "let's knowingly introduce race conditions and crashes")
<Laney> having this feature working is something that people constantly ask for, so we need to not be infinitely blocking it
<ogra_> Laney, no, but stgraber is respponsible for the rw stuff, i would like to see him agree to the change
<Laney> http://irclogs.ubuntu.com/2013/09/24/#ubuntu-devel.html#t14:35
<Laney> Anyway, review is fine but I think everyone is agreed on the approach being sound
<Laney> modulo whatever now happens on upgrades due to that borked upload
<pitti> I suppose upgrades will continue to have a mounted /etc/localtime
<pitti> and thus won't be able to change the tz
<pitti> so you need to phablet-flash ubuntu-system -b, I suppose
<Laney> was it in a 'blessed' image?
<pitti> (-b works, I just re-flashed after my first experiments)
<pitti> Laney: yes, I think so; I didn't chose anything exprerimental, and my flash from this morning got it
<Laney> bah, ok
<ogra_> you wont need -b
<ogra_> -b only flashes the recovery partition separately ...
<ogra_> pitti, phablet-flash always wipes the device regardless ... it just backs up some files before and restores them after flaching (namely /home and a few pre-configred config files (like wlan settings)
<pitti> ah, good to know
<ogra_> if you want to wipe that too --no-backup ...
<ogra_> pitti, i assume https://code.launchpad.net/~cwayne18/phablet-tools/phablet-timezone-setup/+merge/186891shouldnt land then ?
<ogra_> (or needs to be rolled back or whatnot)
<pitti> ogra_: pitti | well, as long as adb push resolves symlinks on write, so that it will actualy write /etc/writable/timezone (and friends), it should be okay
<ogra_> ok
<pitti> ogra_: we can/should test that once above changes land; adb push to /etc/timezone should then actually update /etc/writable/timezone
<ogra_> (adb shell just uses bash on the device side)
<pitti> ogra_: and that script ought to work; if it doesn't, we need to update it to push directly to /etc/writable/ instead
<ogra_> yeah
<pitti> bah, it doesn't
<pitti> adb push replaces a symlink with the new file
<ogra_> lovely
 * ogra_ is eager to get rid of adb 
<ogra_> (and replace it qith usb networking and ssh)
<doko> yolanda, hi, did you ever touch graphviz when working on the ruby1.8 demotion?
<yolanda> doko, no, i didn't
<ogra_> pitti, line 100 on "landing asks" https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 ... tell me if i got anything wrong
<xnox> cyphermox: i'm root and talking over dbus to NetworkManager, yet it's returning me "org.freedesktp.DBus.GLib.UnmappedError.NmManagerError.Code4: Not authorized to control networking." Can I force bypass that somehow?
<ogra_> xnox, you can
<xnox> ogra_: oh, please, please, tell me how =)
<pitti> ogra_: livefs-rootfs has a question mark, it does need an update (it's already pushed, but not uploaded)
<ogra_> cat /etc/polkit-1/localauthority/50-local.d/org.freedesktop.NetworkManager.pkla
<ogra_> [indicator-network-service]
<ogra_> Identity=unix-group:sudo
<ogra_> Action=org.freedesktop.NetworkManager.*
<ogra_> ResultAny=yes
<ogra_> ResultInactive=no
<ogra_> ResultActive=yes
<ogra_> xnox, ^^^ with something like that
<xnox> ogra_: right, let me ship that in ubiquity, as at the moment NM hates ubiquity =)
<ogra_> (you can also explicitly use "unix-user" there)
<Laney> xnox: even with logind?
<pitti> I don't think the ubiquity session uses PAM
<xnox> Laney: yeap, cause logind session is established for user "ubuntu" and not for "root".
<ogra_> pitti, yeah, i wasnt sure, removing the question mark then
<xnox> pitti: I have just added that =)
<ogra_> pitti, it uses lightdm iirc
<ogra_> or doesnt it
<xnox> ogra_: nope, ubiquity undermines and starts on starting lightdm, so it comes up just before lightdm.
<ogra_> oh, right
<ogra_> ubiquity-dm ... /me remembers
<xnox> Laney: and I don't want to drop priviliges from root -> ubuntu with the logind session to use NM. Although, let me try to establish session for root and check if that helps.
<ogra_> sed -i 's/<policy user="root">/<policy group="sudo">\n\t\t\t\t<allow send_destination="org.freedesktop.NetworkManager"\/>\n\t\t\t\t<allow send_interface="org.freedesktop.NetworkManager"\/>\n\t\t\t\t<allow send_interface="org.freedesktop.NetworkManager.SecretAgent"\/>\n\t\t<\/policy>\n\t\t<policy user="root">/g' /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf
<ogra_> xnox, ^^^
<ogra_> that should work too (though make sure that doesnt end up in the install :) )
<xnox> ogra_: i think ubiquity already ships some polkit files, i'll see if I can add it there.
<ogra_> the sed line isnt for polkit
<ogra_> that one actually opens dbus for the sudo group directly
 * doko curses a 3 1/2 year graphviz version
<pitti> Laney, ogra_, stgraber: tested systemd debdiff attached
<Laney> pitti: yay!
<Laney> the dbus method works?
<pitti> Laney: well, I tested with timedatectl, but that just uses dbus
<Laney> cool
<pitti> Laney: I reproduced the /etc setup on my workstation; I can't really fully test this on the phone until we land lxc-android-config and livecd-rootfs
<pitti> but I made sure it doesn't touch the files in /etc/
<pitti> Laney, ogra_: so should we wait for stgraber for the final ack of this, and upload this afternoon?
<Laney> SGTM
<Laney> Managed to beat lightdm/polkit :-)
<seb128> speaking about lightdm, what's the status?
<seb128> is it on the current image?
 * Laney sniggers at the Forwarded:
<Laney> seb128: I think it got pulled
<Laney> ogra_:
<ogra_> pitti, we need the spreadsheet ack anyway
<ogra_> seb128, it trashed the maguro images, got fixed and now sits in proposed waiting for the beta freeze to end
<ogra_> seb128, unlikely that you will see it land before late thu. evening
<seb128> ogra_, can I still get an image with it? or just take the current one and install from proposed?
<ogra_> seb128, the latter, but the session isnt switched to lightdm
<seb128> ogra_, jasoncwarner asked me to test system settings with it to see if that makes things work better
<ogra_> you also need to rebuild session-manager-touch with mtertys commit that is held back until it has been proven to not regress any tests
<rickspencer3> seb128, ogra_ I think the idea was that seb128 could grab mako 59 and test the settings to confirm that they "just work" as expected
<ogra_> the prob with that landing is that polkit suddenly working breaks a bunch of stuff talking through dbus, missing pkla files etc
<rickspencer3> since 59 worked on mako with the new light dem
<ogra_> rickspencer3, kind of
<ogra_> we still need to make sure that all apps using dbus can still reach their backends etc
<ogra_> but due to the beta freeze we have 1.5 days time at least
<ogra_> since lightdm is held by the desktop freeze atm
<rickspencer3> oh geez
<xnox> Laney: pitti: so a logind session got created, but it didn't get a seat.
<xnox> and python3-pam is missing misc_setenv call, via which I could set the seat0 before opening pam session.
<xnox> wait, putenv is available and should do the same thing.
<cjwatson> watch out for slightly different semantics if it's the same as C setenv/putenv
<xnox> cjwatson: well the manpage for C api tells me that I need to free the passed string, but I'm using python, so I hope that slangasek made sure it's properly freed/garbage collected. As there doesn't even seem to be a way to call pam_close on the python PAM object =/
<xnox> in other news.....
<xnox> cjwatson: Laney: seat0 logind session is properly established, can connect to WiFi from within ubiquity & the a11y sound plays \o/
<Laney> yay
<alberts> Does anyone knows why there is no network indicator icon in gnome-session-flashback? https://bugs.launchpad.net/indicator-network/+bug/1229294
<ubottu> Ubuntu bug 1229294 in Network Menu "network indicator is not available in gnome flashback session" [Undecided,New]
<cjwatson> xnox: phew.  do you think that's landable for beta?  we're short on time ...
<xnox> cjwatson: yes, I hope it is. I'll do a merge proposal now, but would want a quick review on how sane my pam_* usage is.
<xnox> cjwatson: it will pull in python3-pam binary into main and on to all ubiquity ISOs =/
<xnox> not sure who/where/how python-pam is used, as it's also on all ubiquity ISOs.
<cjwatson> xnox: We could presumably also take lp:~larsu/ubiquity/lp1207890 if you're happy with it
<cjwatson> xnox: An extra Python 3 module isn't the end of the world, I'd have thought
<xnox> oh, larsu fixed the panels?! =)
<cjwatson> It's tiny
<xnox> cjwatson: https://code.launchpad.net/~xnox/ubiquity/pam-logind/+merge/187496
<cjwatson> more idiomatic is probably "for query, type in query_list:" since you don't need the index
<xnox> cjwatson: true, I copy&pasted the example from python-pam docs, and hacked it until it worked for me =)
<xnox> so.... expect style/idiom inconsistency =)
<cjwatson> xnox: would be nice to pick up the VT number from self.active_vt() or whatever it is
<xnox> true, let me see.
<cjwatson> xnox: we don't need XDG_SESSION_ID any more?
<xnox> cjwatson: pam_systemd creates XDG_SESSION_ID, and sets in in the pam env, which I inject into os.environ with update call using everything pam returns in getenvlist()
<xnox> cjwatson: the CLASS/SEAT/VTNR are set before pam_open_session() to hint pam_systemd which session we want to create, otherwise it does auto-detection which doesn't do the right thing for ubiquity.
<xnox> which is documented on the logind wiki page for greeter/display-manager integration with logind
<xnox> =/
<cjwatson> xnox: Ah, got it
<cjwatson> xnox: Not sure you need the build-dep on python3-pam since I doubt ubiquity-dm is run during build, but it doesn't hurt
<xnox> cjwatson: Hm, shouldn't the XDG_VTNR=7 be derived from the self.vt, rather than active_vt? cause XDG_VTNR should match the VT X will be spawned on for the /user-session/
<cjwatson> xnox: I thought self.vt was derived from active_vt
<cjwatson> xnox: But anyway, I hadn't quite worked out exactly which it should be hence "or whatever it is" :-)
<xnox> cjwatson: hm, it looks like /etc/init/ubiquity.conf passes it to ubiquity-dm as a command-line arg =) active_vt call seems to try to stop plymouth sensibly, on whichever vt that is.
<xnox> ok =)
<xnox> oh, you are correct, later self.vt might be overriden by active_vt.
<cjwatson> It was just a knee-jerk allergy to hardcoding the VT number
<cjwatson> But it's not a blocker
<xnox> right, so at the time pam_session is opened self.vt should have the right one in it.
<cjwatson> but has a "vt" prefix
<xnox> yeah int(self.vt[-1]) ?
<cjwatson> vt10
<cjwatson> I'd do vt[2:] instead
<cjwatson> with a comment
<xnox> ok, I need a string and not an 'int' anyway for putenv call =)
<xnox> cjwatson: ok, updated with the fix-ups & retested them as well.
<cjwatson> xnox: yep, LGTM, go ahead and merge
<mapreri> can someone tell me why crtools is still visible in https://merges.ubuntu.com/universe.html even if it doesn't exist anymore in debian?
<xnox> cjwatson: merged larsu fix as well. Release & upload ubiquity?!
<cjwatson> xnox: We ought to figure out bug 1229432, but I bet that's more complex
<ubottu> bug 1229432 in ubiquity (Ubuntu) "Partitioning error when doing normal install after encrypted lvm install" [Undecided,New] https://launchpad.net/bugs/1229432
<cjwatson> xnox: So go for it
<xnox> ok.
<cyphermox> xnox: you shouldn't have to modify the policykit rules for NM ... what we ship on desktop should still be working on ubiquity, just like it used to, seeing as you could connect to a wifi network and stuff.
<stgraber> hey pitti
<pitti> stgraber: bonjour
<ogra_> stgraber, !
<stgraber> so just saw all the highlights but haven't got to my LP bug notifications, anything I should be looking at? :)
<pitti> stgraber: if you have a few minutes, I prepared three patches for bug 1227520
<ubottu> bug 1227520 in systemd (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,Fix committed] https://launchpad.net/bugs/1227520
<ogra_> stgraber, i would like an explicit confirmation for all these changes before i land the,
<ogra_> *them
<pitti> stgraber: and it would be nice if you could eyeball and ack them (i. e. that the /etc/writable/ approach works for you)
<ogra_> since they change how we do readonly mode
<stgraber> so the changes look fine, I'm just not happy with /etc/writable
<stgraber> because we won't be able to add files to it after that upload, so it's not something we can easily re-use for other files after that
<pitti> stgraber: why not?
<pitti> stgraber: is there no upgrade way at all to reset/change stuff in /etc/system-image/writable-files?
<stgraber> pitti: the initrd will only copy stuff from /etc/writable to /userdata/system-data/etc/writable if /userdata/system-data/etc/writable doesn't exist
<stgraber> so typically only on the first boot
<pitti> stgraber: we'd actually need that to revert the addition of /etc/localtime and friends
<stgraber> that's to allow users to remove files within writable directories
<pitti> that unfortunately got landed, and so we need to clean those up somehow
<stgraber> (and not have them show up again at every boot)
<pitti> stgraber: so on upgrade we can't do something like rm -r /userdata/system-data/etc/{adjtime,timezone,localtime} ?
<pitti> (to clean up after the previous livecd-rootfs change)
<pitti> stgraber: so that means for each writable file we'd need a new directory to put a symlink under it? or should that rather use something in /userdata/system-data/ directly?
<pitti> but in the end that woudl amount to pretty much the same thing as just keeping /etc/ writable
<pitti> except without having to patch umpteen packages to deal with r/o etc
<xnox> cyphermox: yeah, afterall it was a bug in how I was setting up logind session. so all good now =)
<stgraber> pitti: so I suppose we could add an extra mode to writable-paths, that's "persistent and add new stuff" which would prevent removals but will copy any new file from the rootfs to the writable path
<cyphermox> xnox: alright, glad it's sorted out :)
<stgraber> pitti: then /etc/writable would be something reasonable (so long as everyone understands that none of those files will be removable by the user as removing a file will just make it be copied again from the rootfs on the next boot)
<pitti> stgraber: OOI, what was the reason to make /etc/ not writable in the first place?
<pitti> stgraber: it's actually an use case to remove /etc/adjtime
<pitti> although not an important one (having 0.0 in there works just as well)
<stgraber> pitti: making /etc writable with a read-only / and no overlays would mean copying the whole of /etc to writable storage and then you end up in the case I described above where you can't know whether a file was intentionaly removed by the user from writable storage or if it's a new file that showed up in the rootfs and needs to be copied over
<pitti> ah, ok
<stgraber> that's why if we discard the file removal use case, we can then add an extra mode that lets you have a writable path that's "in sync" with the rootfs, in the sense that any file introduced in the rootfs will be copied over to writable storage
<pitti> stgraber: ok, so that would be something to keep in mind for adding new files to /e/writable (can't delete them as user)
<stgraber> I'd still prefer not to use that for /etc as a whole and just use that on a path like /etc/writable as using it over the whole of /etc will eventually lead to a bunch of files in writable storage that no longer exist in the rootfs and just use space
<pitti> stgraber: or we would need to put the extra cp from root fs into the upgrade
<pitti> (or rm)
<pitti> stgraber: as we've just seen with the botched livecd-rootfs upload, we'll eventually need some kind of "upgrade postinst" script to clean up anyway
<stgraber> pitti: yeah, if we need to cleanup stuff we could use the (not implemented yet) boot hooks infrastructure to do the cleanup
<pitti> stgraber: well, that shouldn't happen on (every) boot, just after an upgrade?
<stgraber> yeah, the boot-hooks stuff will let you trigger only after upgrade if you want
<stgraber> pitti: so as a summary, I'd agree with the change if you change from "persistent" to "synced" (better names are welcome) and also propose an initramfs-tools-ubuntu-touch change to introduce that new "synced" mode (the code will need to recursively iterate through the source directory and only copy files and directories that don't already exist in the target)
<pitti> meh
<stgraber> and you'll have to check that none of those patched services attempts to unlink a file (or if they do, that they don't mind the original one being back after a reboot)
<pitti> stgraber: they do unlink files in some cases, although they are rather hard to produce with CLI tools, and it doesn't matter if they come back
<stgraber> pitti: right, I guess we should just make sure that whatever is in the rootfs matches what you'd get after an unlink, that way it doesn't matter
<doko> yolanda, ping about https://launchpadlibrarian.net/150506882/buildlog_ubuntu-saucy-amd64.rubyluabridge_0.7.0-2ubuntu1_FAILEDTOBUILD.txt.gz
<yolanda> hi doko
<yolanda> i did an update for it, trying to force new version of ruby, locally it builds because grabs ruby 1.9, but in launchpad it seems to grab ruby 1.8
<pitti> stgraber: how do we make /etc/adjtime and friends not mounts any more on upgrades? or do we just call those installs broken and people have to reinstall?
<stgraber> pitti: just drop them from writable-paths and they no longer will be bind-mounts
<pitti> stgraber: that's what I did, but it seems they somehow still were
<pitti> stgraber: perhaps because they still were in /userdata/ ?
<yolanda> doko, but i see that it still fails, how can we force ruby 1.9 there?
<pitti> or it's because one cannot really apply these kinds of changes in-place
<stgraber> pitti: that shouldn't be possible, are you sure they aren't listed in /etc/system-image/writable-paths?
<pitti> (e. g. I can never go back to a r/o partition after making changes)
<pitti> stgraber: well, I might certainly have done something wrong; I'm not claiming to understand the whole magic yet
<stgraber> pitti: the way things work is that the initrd reads /etc/system-image/writable-paths and generates a fstab from there, so if an entry disappears from it, no fstab entry will be generated and the file will be back to normal (well, with a leftover in /userdata but that's not a big issue for now)
<doko> yolanda, ahh, rubygems pulls in ruby1.8
<yolanda> doko, but why locally, using sbuild, is working?
<doko> yolanda, add a b-d on ruby1.9.1, it is not install on the buildd
<yolanda> doko, actually, it's there: http://bazaar.launchpad.net/~yolanda.robla/ubuntu/saucy/rubyluabridge/lua5.2/view/head:/debian/control
<doko> yolanda, is this newer than the package in -proposed?
<yolanda> doko, looking at my mp, it says "Merged" but i don't see the changes in lp:ubuntu/rubyluabridge
<yolanda> i did the changes on 17/09
<doko> yolanda, well, the changelog in -proposed is the same
<doko> maybe you could prepare a -2ubuntu2?
<ogra_> pitti, stgraber, so did you two come to any consensus ? should i hold back the landing of the code ?
<ogra_> or can it go in
<yolanda> doko, so what happened? changelog is updated, but not debian/control file
<yolanda> do i just create a new entry re-adding that bd?
<doko> yolanda, would be best
<doko> if this is all what is missing
<yolanda> doko, i'll compare all the diffs with my local version, if something more is missing i'll readd it
<stgraber> ogra_: current code can't go in
<ogra_> stgraber, ok
<ogra_> stgraber, btw, do you know that /userdata is really annoying ? i can tab complete /us<tab> anymore with it in place !
<stgraber> ogra_: you know that /us<tab> is just as long as /usr, right? :)
<ogra_> tell that to my finger memory :P
<ogra_> oh, and its actually shorter, it gives me the trailing slash
<ogra_> :)
<wookey> xnox: I just clicked on a link on https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1122120 and it (surprisingly) set the status from 'Fix committed' to 'wont-fix'. If I try to change it back it tells me I'm not allowed to. This is most unhelpful.
<ubottu> Ubuntu bug 1122120 in tk8.5 (Debian) "Multiarchify tcl8.5" [Unknown,Fix committed]
<wookey> Anyway you might want to set that back how it should be
<cjwatson> wookey: I've restored it
<wookey> cheers
<cjwatson> it's deliberate that only bug supervisors get to transition away from wontfix
<cjwatson> though it's a little surprising that you get to transition *to* wontfix
<wookey> yeah I can see the sense in that. I was mostly surprised that just clicknig on that link changed it at all
<cjwatson> cf. bug 294846
<ubottu> bug 294846 in Launchpad itself "Setting to Won't Fix is ACLed but unsetting it isn't" [Medium,Fix released] https://launchpad.net/bugs/294846
<cjwatson> Oh.  You get to transition away from fixreleased if you are the bug reporter, so that you can always reopen.
<wookey> yeah. I'd fogotten I started that bug :-)
<cjwatson> wookey: I've filed bug 1230303.
<ubottu> bug 1230303 in Launchpad itself "Bug reporter can transition from Fix Released to Won't Fix, but not vice versa" [Undecided,New] https://launchpad.net/bugs/1230303
<yolanda> doko, i pushed MP again, updating changelog: https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/rubyluabridge/lua5.2/+merge/187522
<slangasek> pitti: a friend of mine has pointed out that the postgresql metapackage in saucy is at version 9.3+146really9.1+148, whereas testing/unstable has 9.3+149.  Do you know if the server team want 9.1 for saucy, or if that should maybe be bumped?
<pitti> slangasek: 9.3 has arrived after FF; most of the packaged extensions have been ported now
<pitti> slangasek: it would be a rather intrusive change, but if the server team wants it it should boil down to three handful of syncs
<pitti> rbasak: ^ do you care much about which psql version is in saucy? (I had thought not, given that the non-LTSes are not a very attractive server platform anyway)
<slangasek> xnox: I think I only touched python-pam to do a straight python3 port... so I assume that I faithfully transcribed any memory leaks
<slangasek> pitti: ok, no worries, just thought I'd ask :)
<xnox> slangasek: did it work in python3 for you? i had to recompile it such that dh_python3 renames the module from PAMModule.so => PAM.so.$(python3-abi-tag), cause before $ python3 -c "import PAM" was failing.
<slangasek> xnox: hmm, failing how?  I don't remember what level of testing I did at the time
<slangasek> I /assume/ I did an import test, but don't remember for sure
<xnox> slangasek: maybe things changed in how multiarched abi tags are done in python3 + impecable timing in upload to get /wront/old/bitrotted/ compile.
<xnox> anyway, all fixed now =)
<slangasek> ok
<slangasek> are you actually using this module for something?
<xnox> slangasek: ubiquity is now using it to establish a pam session => to get a proper & correct logind session => to unbreak a11y & networking.
<slangasek> xnox: ah, hmm.  given that the code was abandonware that had to be forward-ported to use modern python *2* C extension conventions, that does worry me a little, but I guess there aren't any other options
<xnox> slangasek: the other option is a wrapper binary / shim that will do the same (start, putenv, authenticate, open_session, exec(ubiquity-dm), close_session, stop)
<xnox> at the moment it's nice to do that from ubiquity-dm & at the right time.
<slangasek> right, any other /sane/ options. ;)
<xnox> oh, yeah =) sorry..... ;-)
<cjwatson> zul: Where is python-prb intended to come from to satisfy the dependency of python-tempest (stuck in -proposed due to this)?
<zul> cjwatson:  crud ill fix it up
<cjwatson> Ta
<bdmurray> pitti: give the blacklist for postgresql- in the release upgrader (bug 871893) how are people supposed to upgrade?
<ubottu> bug 871893 in update-manager (Ubuntu Oneiric) "After upgrading postgresql-databases are not accessible any more" [Critical,Fix released] https://launchpad.net/bugs/871893
<doko> yolanda, could you just prepare  a dsc/diff.gz and put it on chinstrap/people?  doesn't apply to -2 nor -2ubuntu1
<yolanda> sure
<doko> cjwatson, mir needed for python-pylibmc, dep of python-werkzeug
<cjwatson> doko: Yeah, I was trying to clean up breakage introduced by Daviey by syncing flask, but it turns out to be a deeper rabbit-hole than I thought
<cjwatson> doko: Also redis
<ogra_> pitti, so do you plan to work on the lxc-android-config changes further today ? else i need to back them out from trunk since i have other MPs waiting for upload
<doko> dbarth_, ping 1217008, could you subscribe the team to the ubuntu package too?
<doko> dbarth_, ahh, ahh, already subscribed
<dbarth_> hang on
<dbarth_> doko: i suppose we're good for this MIR, right?
<slangasek> dbarth_: what is the purpose of bug #1219889?  "include the ubuntu-html5-theme in the upcoming 13.10 release" doesn't make sense, the package is already in the archive
<ubottu> bug 1219889 in ubuntu-html5-theme (Ubuntu) "[FFE] ubuntu-html5-theme" [Undecided,New] https://launchpad.net/bugs/1219889
<dbarth_> slangasek: it is; there has been some confusion as whether SDK runtimes should go in 'main'
<dbarth_> and that's what this MIR was about
<slangasek> dbarth_: that's an FFe, not an MIR
<slangasek> and I don't know what you're asking for a feature freeze exception on
<slangasek> what's the "feature"? "put this package in main" isn't a feature
<dbarth_> well, since the MIR was late, I thought an FFE was required as well
<dbarth_> all in all, i think you can put that aside; i understand that SDK runtime packages do not need to go in main for the phone
<dbarth_> should i comment and mark invalid?
<dbarth_> done
<infinity> chrisccoulson: Was it intentional for {firefox,thunderbird}-globalmenu to fall out of main?
<slangasek> dbarth_: right, thanks :)
<infinity> chrisccoulson: Oh, I see, it's a transitional package.  Probably want to explicitly seed it until post-14.04.  I'll do that.
<infinity> sarnold: How goes glamor-egl?
<sarnold> infinity: pretty well, I'm liking this code base :)
<infinity> sarnold: That's a good sign.
<sarnold> infinity: yeah, so far so good. :)
<smoser> cjwatson, will 'dpkg-reconfigure grub-pc' always run update-grub ?
<infinity>     if test -e /boot/grub/grub.cfg && ! running_in_container; then
<infinity>       update-grub 3>&-
<infinity>     fi
<infinity> smoser: ^
<smoser> yeah. so looks like yes.
<smoser> well, mostly yes
<roaksoax> infinity: howdy! so I dropped the build-dep on libopenais-dev for ocfs2-tools. I have not yet the same for asterisk, since we would be dropping functionality. However, this new functionality is no longer used by new upstream releases as they use the "replacement" for openais it seems. So we could either demote it to universe, or simply drop the use of openais in asterisk
<roaksoax> infinity: as far as pacemaker-mgmt, i need a new upstream release of it, that I'm currently trying to fix because it FTBFS
<infinity> roaksoax: Demoting to universe doesn't help if it's not rebuildable.
<roaksoax> infinity: i agree, i don't mind dropping the use of it in asterisk,
<roaksoax> so we can drop it from the archive
<roaksoax> either way it is deprecated.. no longer supported nor maintained
<infinity> roaksoax: Dropping openais from ocfs2-tools meant it didn't build one of its binaries too.  Is that an issue?
<infinity> roaksoax: Anyhow, if there's a replacement for openais, why have we not packaged it?
<infinity> (Or, we could fix openais to work with the new corosync...?)
<roaksoax> infinity: no issue whatsoever, i had previously dropped other stuff in ocfs2-tools (related to clustering) and openais was just a left over dependency
<roaksoax> infinity: the replacement is corosync, at it is packaged
<roaksoax> infinity: ocfs2-tools upstream have not done anything to support the new cluster stack (which uses corosync 2.X and pacemaker 1.1.11+)
<infinity> roaksoax: Well, you mentioned a "replacement" in terms of asterisk.
<roaksoax> infinity: the "replacement" in terms of asterisk is to use a newer upstream release that supports corosync instead of openais
<infinity> Ahh.
<roaksoax> https://wiki.asterisk.org/wiki/display/AST/Corosync
<infinity> Can any of that be sanely backported?
<roaksoax> infinity: i would need to have a deeper look at asterisk
<infinity> roaksoax: Anyhow, whatever you feel is lowest impact and vaguely supportable, but obviously having a non-buildable openais isn't going to work.
<roaksoax> infinity: yeah In my opinion it is fair to drop the use of openais in asterisk, since it really is old stuff 3+ years
<infinity> roaksoax: And get us a shiny new asterisk for 14.04 that has corosync support?
<infinity> (Since the idea of anyone running an asterisk network on a 9-month-supported releases seems unlikely anyway)
<roaksoax> infinity: i would say so. Release versioning in asterisk is weird, (we currently have 1.8, and the next LTS support in asterisk is 11.x ... so 1.8 -> 11.x weirdness)
<roaksoax> https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
<roaksoax> yeah I would say we should go for a 11.x version of asterisk for 14.04
<roaksoax> infinity: i'll go ahead with that then
<mwhudson> barry: https://wiki.archlinux.org/index.php/OfflineIMAP#SSL_fingerprint_does_not_match
<barry> mwhudson: thx
<mwhudson> (backchannels ftw)
<mwhudson> hi, it seems that the memcached ddeb is somehow out of sync with the memcached deb (for armhf)
<mwhudson> can i prod someone into fixing this somehow?
<mwhudson> infinity, wgrant: you seem like the sort of people who might know about this
<infinity> mwhudson: pitti is the person to poke, so long as ddebs come from magic land.
<mwhudson> heh ok
<mwhudson> file a bug on the affected package and subscribe him i guess?
<infinity> mwhudson: They look in sync to me though.
<mwhudson> infinity: the version numbers are the same, but gdb refuses to consult the debug info
<mwhudson> complains about a crc mismatch
<mwhudson> and the build ids reported by file(1) are different
<infinity> mwhudson: Oh.  That's curious.  And not something pitti can do anything about.
<infinity> mwhudson: Which release is this on?
<mwhudson> infinity: raring
<infinity> http://ddebs.ubuntu.com/pool/main/m/memcached/
<infinity> So, note the suspicious timestamps there.
<infinity> I *bet* someone rebuilt memcached/armhf in a devirt PPA and pitti's scripts picked up the new ddeb. :/
<infinity> Or something like that.
<infinity> There's pretty much nothing we can do about this until we get ddebs in soyuz.
<mwhudson> er
<mwhudson> yeah, that's odd
<mwhudson> luckily memcached builds really quickly :)
<infinity> The whole system is incredibly fragile, sadly.
<infinity> We have all the fixes for this lined up, but we're waiting on a go-ahead from IS to flip the switch, basically.
<mwhudson> it's the "disk is cheap and other lies" thing, right?
<infinity> Pretty much.
#ubuntu-devel 2013-09-26
<pitti> Good morning
<pitti> bdmurray: how do you mean? the metapackages will pull in the last version, the blacklist is just for not automatically removing the old version so that you can run pg_upgradecluster
<pitti> bdmurray: there is a debconf note, README, etc. which explain how to upgrade
<pitti> ogra_: not yesterday, there's only so many hours I can help out with that stuff; but if you upload, please at least revert the addition of the individual files before even more people get them (seems we have no way to fix that on upgrade?)
<pitti> awe_: hey Tony, still here?
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<diwic> asac, hi, I want to improve PulseAudio's quality by fixing a bug that causes crashes on desktop. The bug fix is in a module (module-combine-sink) that we do not use on the phone. Can I upload it?
<brainwash> why do the logind policy rules for "power-off-multiple-sessions" and "reboot-multiple-sessions" differ? and why does logind think that multiple sessions are running after logging out completely? bug 1226509
<ubottu> bug 1226509 in systemd (Ubuntu) "lightdm_get_can_restart returns false in Ubuntu Saucy" [Undecided,New] https://launchpad.net/bugs/1226509
<dholbach> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: beta freeze, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<brainwash> why do the logind policy rules for "power-off-multiple-sessions" and "reboot-multiple-sessions" differ? and why does logind think that multiple sessions are running after logging out completely? bug 1226509 (comment #2)
<ubottu> bug 1226509 in systemd (Ubuntu) "lightdm_get_can_restart returns false in Ubuntu Saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1226509
 * diwic wonders why installing fluidsynth (and only that package) caused an initramfs update.
<Laney> ev: Howdy, got two questions about diagnostics in system-settings. 1. Does whoopsie work there (should we hide the settings?) 2. Do you plan on shipping a pkla to make polkit work there? We've been testing it on the device and that one doesn't work.
<mlankhorst> cjwatson: http://people.canonical.com/~ubuntu-archive/NBS/ redirects to /NBS which 404s
<cjwatson> mlankhorst: Works for me
<cjwatson> Perhaps you mean http://people.canonical.com/~ubuntu-archive/NBS
<cjwatson> And the buggy redirection there is a bug in IS' reverse proxy for http://people.canonical.com/~ubuntu-archive/
<cjwatson> So please ask them
<cjwatson> You probably want http://people.canonical.com/~ubuntu-archive/nbs.html anyway, though
<mlankhorst> 404s too ;)
<cjwatson> Definitely works for me
<mlankhorst> hm weird, fails in firefox, works with wget
<cjwatson> WFM in firefox
<cjwatson> dodgy proxy?
<mlankhorst> if there is a proxy, it would be some transparant one
<cjwatson> shift-reload?
<smoser> anyone else use xchat-indicator and have it not seem to work in saucy ?
<mlankhorst> hm weird stuff
<seb128> smoser, indeed, I've pinged larsu about it (he's doing indicator-messages)
<seb128> smoser, can you open a bug on https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+filebug ?
<smoser> seb128, yes.
<seb128> smoser, thanks
<seb128> smoser, do you know when it stopped working?
<smoser> seb128, its been quite some time.
<smoser> maybe a month.
<seb128> smoser, ok, thanks
<smoser> since i dont log in and out often, i kind of assume things like that might fix themselves on a reboot.
<smoser> and then i'm lazy to ask.
<smoser> anyway, bug sudo apt-get update
<smoser> ooops
<smoser> https://bugs.launchpad.net/ubuntu/+source/xchat-indicator/+bug/1231435
<ubottu> Ubuntu bug 1231435 in xchat-indicator (Ubuntu) "indicator does not change color on new messages in saucy" [Undecided,New]
<smoser> feel free to make it have the right words seb128
<apachelogger> infinity: ping, would be really awesome if you could have a look at bug 1212662
<ubottu> bug 1212662 in eglibc (Ubuntu) "zic -l Foo/Bar leads to broken /etc/localtime" [Medium,Confirmed] https://launchpad.net/bugs/1212662
<cjwatson> pitti: do you have a VCS for the Ubuntu package of systemd?  want to fix bug 1231230
<ubottu> bug 1231230 in systemd (Ubuntu) "Rescue on server image fails to detect partitions" [Undecided,New] https://launchpad.net/bugs/1231230
<pitti> cjwatson: a local one, yes; haven't yet merged to Debian's git (which is finally there)
<pitti> cjwatson: I have two local unreleased commits, but in general, don't block on that; I'm fine with grabbing LP diffs
<pitti> cjwatson: if you don't need that uploaded right now, I can commit it, though
<cjwatson> pitti: I'd like it today I think, but need to go out now to return some unused hardware, so in a bit.  Thanks
<gusch> seb128: hmmm - state handling seems to be pretty broken ...
<seb128> gusch, in system settings or in content-hub?
<gusch> seb128: content-hub
<seb128> gusch, :-(
<seb128> gusch, can you get it fixed today?
<gusch> seb128: let's see - no promises ...
<seb128> gusch, should we think about reverting that update to get back to a working feature?
<seb128> didrocks, asac: ^
<seb128> how did that content-hub land if it's obviously buggy?
<gusch> seb128: when do we need to deside for that?
<seb128> gusch, not sure, let's see what asac and didrocks say
<gusch> seb128: I looked to the content-hub part only - didin't test with the setting, and for the test it worked fine
<didrocks> if gusch can't get a fix in the next hour, let's revert
<didrocks> seb128: can you try reverting and ensuring it's working on latest image?
<doko> Riddell, are you aware of the ftbfs for qtwebkit-source on armhf?
<seb128> didrocks, I did that already, it does
<gusch> didrocks: ok - one hour then
<seb128> thanks
<didrocks> seb128: does this work for you (this one hour + revert if nothing?)? ^
<seb128> didrocks, yes, thank you
<didrocks> ok, let's see
<seb128> gusch, thanks as well, finger crossed you fix it ;-)
<didrocks> gusch: keep us up to date, please ;)
<doko> seb128, is platform-api expected not to build on powerpc?
<doko> pitti, pygobject ftbfs on powerpc
<pitti> doko: thanks for the poke, retrying (sounds like test race condition)
<seb128> doko, I think popwerpc is not supposed indeed
<seb128> sil2100, Mirv, didrocks: ^ can you confirm?
<pitti> doko, seb128: I thought basically anythign which uses Qt5 is !powerpc at this point?
<Riddell> doko: yeah, shadeslayer had an idea to fix it but don't think he get there yes
<Riddell> yet
<seb128> pitti, indeed, I'm unsure the platform-api uses qml though
<seb128> pitti, it's lower in the stack
<didrocks> doko: yeah, no point in having powerpc, I do remember we had issues on platform-api with it
<didrocks> don't have the whole story in mind though
<seb128> pitti, but it use the location service and other bits that might not work on ppc
<sil2100> Same here
<psusi> is there a way to get the original core dump that the stack retracer removed from a bug report?  I really need to poke around in there more to find the cause of this crash...
<geser> you might be lucky and it's still available through the bug history
<psusi> I think there's a permissions thing... once the link is removed from the bug report, launchpadlib disavows it, like it does for private bugs you aren't subscribed to
<psusi> in other words, the link shown in the email where it was removed no longer works
<gusch> seb128: didrocks not looking good to fix it soon :(
<didrocks> ok ok
<seb128> gusch, do you see what's wrong? is there any workaround we could use on the settings side (you said your test example worked)
<gusch> seb128: I'm not yet sure where the problem really is - still debugging
<seb128> gusch, can you confirm the bug at least? (e.g that the settings stopped working)
<gusch> seb128: yes - doens't work for me either anymore
<seb128> ok, at least it's reproducable
<didrocks> ok, reverting then?
<seb128> gusch, ^ do you want another 15 min to see if you get to the bottom of it, or just revert now?
<psusi> wait a minute... what's going on here?  gparted does not have debug symbols.. it is stripped... and not saved... no -dbg package... no symbol file anywhere... no options given to dh_strip... so how is apport retracer providing full stack trace?
<gusch> seb128: I rather guess I will need another hour just to find the point of error
<seb128> gusch, ok, let's revert then
<seb128> didrocks, ^
<gusch> seb128: better, yes :(
<seb128> didrocks, how do we revert nowadays? get a mp to back out the changes from trunk?
<didrocks> seb128: push it to trunk directly even
<didrocks> seb128: if you can avoid doing the same mistake than I did, it will be good ;)
<didrocks> like keep the old changelog
<didrocks> adding a new one
<didrocks> telling "reverting blahblahblah" ;)
<didrocks> seems better than reverting the changelog altogether
<didrocks> (I did that for ubuntu-keyboard before seeing it was nonsense)
<seb128> didrocks, ok, let me try that
<didrocks> seb128: then, if you don't mind, once build, can you add the ppa, upgrade (adding the content-hub package) to your phone and just poke with it?
<didrocks> seb128: that would be perfect ;)
<didrocks> (I can poke you once built)
<seb128> didrocks, sure can
<seb128> didrocks, thanks
<gusch> seb128: but then the seeting change needs to be reverted as well, as that change was incompatible
<seb128> gusch, is that in another component?
<gusch> seb128: in the seetings application (setting the store there)
<seb128> gusch, right, I can do that
<didrocks> seb128: ah, so we'll need another settings altogether?
<seb128> didrocks, seems so :/
<didrocks> sil2100: so maybe wait on that for settings ^
<sil2100> ...:D
 * sil2100 feels like he's picks up and drops things one after another
<sil2100> ;)
<sil2100> seb128: could you give me a sign once it's done
<sil2100> ?
<pitti> psusi: WDYM? http://ddebs.ubuntu.com/pool/main/g/gparted/ has debug symbols, at least for aucy?
 * pitti throws in an "s"
<pitti> awe_: hey Tony
<psusi> oh look at that, we do have a secret repository of debug symbols even when they are supposed to be stripped and not saved
<pitti> psusi: ddebs.u.c. is the one and only repo, by far not secret :)
<psusi> well, when you ask dh_strip to, you end up with a -dbg package in the main archive
<awe_> pitti, hey... just getting going this morning, and trying to read my back-log
<pitti> awe_: no worries
<pitti> awe_: just a quick status update
<awe_> lots to read
<pitti> awe_: so I'm creating a dbusmock for ofono, and test that with the ofono scripts; making nice progress
<psusi> and when you don't... it's not supposed to go anywhere, but it seems it gets stered to ddebs instead... nifty trick
<psusi> now to see if I can pry the original crash dump out of launchpadlib
<pitti> psusi: heh, welcome to 2006 :)
 * pitti pats https://launchpad.net/ubuntu/+source/pkg-create-dbgsym/0.1
<awe_> pitti, I'd like to discuss more but I have a stand-up in ~5m
<pitti> awe_: no worries
<pitti> awe_: I need to leave soon for today anyway
<pitti> awe_: just wanted to say "there's hope" :)
<awe_> pitti, one thought though is what advantage does this have vs. using the internal ofono phone emul?
<awe_> pitti, there's always hope
<awe_> don't you listen to U2?  ;)
<pitti> awe_: well, I'm investigating both; I still failed to get the emulator actually working (see my mail)
<awe_> OK ( still reading emails... ^^ ); ttyl!
<arges> hallyn: ping
<doko> hrm, python-werkzeug now shows another test failure
<seb128> gusch, didrocks, sil2100: https://code.launchpad.net/~seb128/content-hub/revert-buggy-changes/+merge/187812 ... I can't push directly, I'm not in the right team
<didrocks> perfect, let me push it
<seb128> gusch, didrocks, sil2100: I verified with a bzr bd --source that the debdiff has only the changelog between the 20 and 26 version
<didrocks> seb128: thanks for the extra care!
<didrocks> asac: FYI, we are reverting content-hub ^
<didrocks> ok pushed
<didrocks> now, let's rebuild content-hub
<didrocks> seb128: poke me once system-settings is ready, I'll rebuild it as well
<asac> didrocks: your call. .ensure the stakeholders are well aware and jason in particular
<didrocks> asac: I guess they are ;)
<asac> ultimately i am less strict about regressions in apps that have no tests
<asac> so in this case i probably wouldnt have backed it out unless the content-hub folks say we should do :)
<asac> but your call... both is valid :)
<didrocks> asac: gusch says we should do (he's upstream)
<didrocks> and ken is on holidays
<didrocks> so I guess it's the only way to get to a sane state
<doko> yofel, ping about virtuoso-opensource
<asac> didrocks: sounds right
<asac> ack
<hallyn> arges: .
<psusi> pitti: when apport retraces a bug and removes the coredump, is it really deleted, or just no public way to find it any more?  and I have a bug that it incorrectly decided was a dup and removed everything useful without doing a full stack trace... but it isn't a dup.  anything to be done about that?
<mterry> robru, I poked dbarth_ about the cordova MIR and he says we don't need that either, which means we don't need to stress as much about qtaudioengine
<mterry> robru, though if we want to drop it anyway for 14.04, we might as well drop for 13.10 as well.  So question to bzoltan still stands
<didrocks> mterry: +1, we don't need it for now
<pitti> psusi: /away -all
<pitti> sorry, I'm afraid not; I can drop the master bug from the duplicate db, if that's a systematic mis-duplication
<pitti> awe_: ok, got the simulator to work
<awe_> cool!
<pitti> awe_: I also have an initial version of an ofono dbusmock (just took me an hour or so, not much wasted), in case we ever need that in the future
<awe_> pitti, also good news!
<pitti> awe_: EOD for me now, but I'll start writing some autopilot tests for the dialer tomorrow (also followed up by mail again)
<awe_> pitti, ack
<awe_> pitti, I will try and dig thru my overflowing inbox and respond at least once before my EOD.
<awe_> pitti, one question...  I floated the idea of a hangout to discuss progress, brainstorming, ...
<awe_> is 5 UTC too late for you?
<pitti> awe_: monday, anything before 1600 UTC
<awe_> ack
<pitti> awe_: I have taekwondo in the evening; I could miss that in principle, but earlier would be better
<awe_> right
<awe_> I'm loathe to schedule something early my time Monday morning, would Tue early be OK ( 14 UTC )?
<awe_> or as early as 13UTC?
<pitti> awe_: works fine for me
<awe_> coolio
<pitti> awe_: Tuesday I can do anything from 0500 to 1800 UTC
<awe_> I will schedule a hangout for that time then ( tue 14utc )
<pitti> great
<pitti> I'll hopefully have some ap test prototypes by then
<awe_> should I invite everyone on the Connection Testing email?  Or should we make it a smaller group?
<pitti> awe_: can you please invite fginther, if possible? (for how to run this in CI)
 * awe_ notes the To/Cc list is rather large
<pitti> awe_: no need to pull gema, thomi, chris etc. into this IMHO; I think it's fine if I'll be there as a representative of QA; someone from CI, and then of course the dialer/messaging app authors
* infinity changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* infinity changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Guest2048> Hi all! I would like to ask something! I have  a fresh 13.10 Beta installed, and would like to remove the wayland libraries, but...
<Guest2048> sudo apt-get purge libwayland-client0 libwayland-cursor0 libwayland-server0
<Guest2048> Reading package lists... Done
<Guest2048> Building dependency tree
<Guest2048> Reading state information... Done
<Guest2048> Some packages could not be installed. This may mean that you have
<Guest2048> requested an impossible situation or if you are using the unstable
<Guest2048> distribution that some required packages have not yet been created
<Guest2048> or been moved out of Incoming.
<Guest2048> The following information may help to resolve the situation:
<Guest2048> The following packages have unmet dependencies:
<Guest2048>  ubuntu-system-settings : Depends: libtimezonemap1 but it is not going to be installed
<Guest2048> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
<Guest2048> I dont understand how ubuntu-system-settings come to the picture
<Guest2048> Anybody have some idea, how can I remove wayland?
<psusi> you have to fix your broken packages ( u-s-s ) before you can do anything else with apt
<Guest2048> but I can do anything else, example now I installed xchat
<Guest2048> and anyway I dont understand what is broken
<Guest2048> should I install ubuntu-system-settings?
<psusi> u-s-s is broken becuse it depends on libtimezomemap1, but it isn't installed
<Guest2048> sudo apt-get install libtimezonemap1
<Guest2048> Reading package lists... Done
<Guest2048> Building dependency tree
<Guest2048> Reading state information... Done
<Guest2048> libtimezonemap1 is already the newest version.
<Guest2048> 0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.
<Guest2048> now Im installing u-s-s
<slangasek> Guest2048: you shouldn't purge the wayland libraries
<Guest2048> ups... now i can remove wayland, but unity goes with it
<Guest2048> because of unity?
<Guest2048> I thouth its in different libraries now (Mir)
<Guest2048> Im on my way to build the new wayland... So I think gonna install xfce, then remove wayland
<Guest2048> thanks for your help goodbye
<slangasek> Guest2048: because the existing mesa libraries are built against wayland for optional support, so removing them breaks the whole system
<slangasek> (mesa, and also gtk)
<psusi> say, what ever happened to x32?  I still don't see x32 builds in the archive.  Is there a separate archive for that or did it die?
<slangasek> it was never alive
<Guest2048> So how can i build wayland from git?
<psusi> so developmen has stalled or is there ongoing work somewhere?
<Guest2048> Should I build it on xubuntu?
<Guest2048> I mean not just build, but use it, with weston
<Guest2048> I wasnt able to compile weston because of the default wayland libraries
<infinity> psusi: There's been no great push to do a full port.  There's toolchain support for building x32 binaries with -mx32
<infinity> I wouldn't mind doing an x32 port, but I suspect someone needs to make a good case for it.
<infinity> Guest2048: Having old wayland libraries installed shouldn't prevent you from building new ones...
<slangasek> Guest2048: not really a question for this channel, though
<Guest2048> infinity: yes, I can build it, but how can I use by just replacing the wayland libs?
<Guest2048> slangasek: but the not dev ubuntu channel?
<slangasek> Guest2048: I imagine you would want a wayland channel; this channel is for development of Ubuntu
<Guest2048> slangsek: I was there, and they say, the problem, that the old wayland libs
<Guest2048> so I was to remove them, but doesnt understand the problem with ubuntu-system-settings and libtimezonemap1
<Guest2048> so reinstalled the system, because I thout I screwed something
<Guest2048> but no :)
<Guest2048> I will try to install it to a custom location
<Guest2048> thanks for your help
<Guest2048> ubuntu-devs how doing this? making a new package first then upgrading it with dpkg?
<sarnold> Guest2048: if you're still talking wayland you can probably do ./configure --prefix=/opt/guest2048/wayland/  and then continue as directed by their README..
<sarnold> no need to get dpkg involved if you're just building things locally.
<psusi> so if I wanted to build x32, how do you do that?  dpkg-buildpackage -ax32 doesn't seem to work... it doesn't pass -mx32 to gcc for some reason and so ends up still building for amd64
<dobey> x32?
<dobey> i386?
<psusi> no... x32... amd64 with 32 bit pointers
<slangasek> psusi: dpkg-buildpackage -afoo will never use gcc -mbar; you would need an x32-linux-gnu-gcc wrapper
<dobey> right if you want to cross-compile something you need a cross-compiler
<psusi> well it doesn't even seem to be looking for x32-linux-gnu-gcc
<psusi> it's just running regular old gcc
<slangasek> then you're trying to build a package that isn't cross-buildable?
<psusi> it's parted.. what's it take to be cross buildable?  it seems to go out of its way in the rules file to default DEB_BUILD_ and DEB_HOST_ variables and call dpkg-buildflags to get default flags... doesn't dpkg-buildpakcage -afoo set those varibles?  and I would think when they are set dpkg-buildflags would return the correct -mbar flag
<slangasek> yes, it does set them, but does the package pass them in a useful manner to the upstream build system?
<slangasek> psusi: so debian/rules certainly seems to dtrt for passing --build= and --host= to configure; do you see this in the build output?
<infinity> psusi: So, maybe we're asking the wrong questions here.  Why would you try to build with -amx32?  That would give you an _x32.deb, which would be almost certainly useless to you...
<infinity> psusi: Given that we're already pointed out that there isn't an x32 port.
<infinity> s/we're/we've/
<psusi> yes... aha... configure says it can't find the cross compiler and so I guess it falls back to gcc
<psusi> infinity: I figured I'd try making such a port ;)
<psusi> good learning excercize at least
<infinity> psusi: http://ports.debian.net/debian/pool-x32/
<infinity> psusi: I suspect you'll find all the work is already done.
<infinity> psusi: It's just neither an official Debian port, nor an Ubuntu port.
<psusi> ahh, neat
<infinity> I guess http://ftp.debian-ports.org/debian/ is the more canonical URL this decade.
<semiosis> slangasek: ping
<slangasek> semiosis: hello
<semiosis> greetings.  i'm interested in your comment on https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1205075
<ubottu> Ubuntu bug 1205075 in glusterfs (Ubuntu) "mountall doesn't treat glusterfs correctly" [Undecided,Confirmed]
<slangasek> sure :)
<slangasek> I guessed that was what I'd done that had brought people hunting for me
<semiosis> what can we (the upstream community) do to make gluster work better with mountall?
<semiosis> some interface you mentioned?
<semiosis> "the expected interfaces required for mount.$fstype helpers"
<slangasek> semiosis: right, just responded on the bug for reference - short answer is, "anything that mount(8) lists as a valid commandline for mount itself"
<slangasek> there are certain internal options to mount that you don't have to handle... mount -n, mount -f, and of course mount -t
<semiosis> ok i understand
<slangasek> but at least in testing with the 13.10 version of glusterfs-client (whose usage output differs from the version in the bug report), it seems that mount.glusterfs expects <device> <-o$options> <dir>, which is actually *contrary* to what the mount manpage describes, and is incompatible with other helpers
<slangasek> (i.e., mount.nfs)
<slangasek> and mountall shouldn't have to guess which order the arguments go in :)
<semiosis> got it.  i'll open bugs upstream about this
<arges> hallyn: I have a patch for bug 1100843, can you review: http://people.canonical.com/~arges/lp1100843/precise/fix-lp1100843-precise.debdiff . so far my tests pass with this build. thanks
<ubottu> bug 1100843 in qemu-kvm (Ubuntu Precise) "Live Migration Causes Performance Issues" [High,In progress] https://launchpad.net/bugs/1100843
<semiosis> slangasek: i've done most of my testing with precise and haven't run into any of these kinds of problems, as far as I know
<semiosis> slangasek: has anything changed in raring that might affect this?
<semiosis> s/raring/quantal/
<slangasek> semiosis: as far as I know, the mount argument handling in mountall has not changed
<semiosis> ok.  i was planning on putting some time in on the ubuntu packages tonight, i'll dig into this as well while i'm at it
<semiosis> glusterfs ubuntu packages
<slangasek> perhaps this was a glusterfs upstream behavior change between 3.2.5 and 3.2.7
<slangasek> since 13.04/13.10 have 3.2.7, and 12.04/12.10 have 3.2.5, and the bug is only reported against 13.04
<semiosis> right
<semiosis> most people use my PPA packages of glusterfs, and I've never heard of anyone having this problem -- with any glusterfs version since 3.1
<semiosis> but i'll look into that in any case
<doko> barry, could you have a look at the python-werkzeug ftbfs and tell me that the wsgi tests need access to the network?
<jtaylor> doko: fails for me with network enabled and disabled
<doko> hrm, does succeed here locally
<doko> jtaylor, so if you have an idea why ...
<jtaylor> uh its a pybuild package
<jtaylor> how do I get that verbose
<jtaylor> doko: works with LC_ALL=C.UTF-8
#ubuntu-devel 2013-09-27
<hallyn> arges: the one thing i'd say is that buffer_find_nonzero_offset() could be static, and can_use_buffer_find_nonzero_offset() only needs to exist righ tabove that in the same file, but it's no big deal
<hallyn> arges: looks good to me, thanks.
<vish> pitti: hi.. how are you?  Bug #1231763 oops..! :(
<ubottu> bug 1231763 in apport (Ubuntu) "Use png icon instead of the svg source" [Low,Triaged] https://launchpad.net/bugs/1231763
<pitti> Good morning
<pitti> vish: ack, will do; thanks!
<pitti> vish: hm, we used SVG before too, but apparenlty a less complex one?
<pitti> vish: ack, I'll keep the SVG ones in scalable/ then
<mdeslaur> good morning pitti
<vish> pitti: i think, it might be better if we kept the scalable as PNG too, just so that we dont have to revisit it again... it might just be the layers that i used
<pitti> vish: but I want to ship the "source" of the PNGs too, and with these sizes we shoudl have the common use cases covered?
<pitti> PNG isn't scalable
<vish> yea, isnt good with scaling
<vish> pitti: ok, SVG in scalable sounds fine.. :)
<vish> thanks..
<dholbach> good morning
<pitti> Laney, infinity: is it ok if I accept the langpack uploads in saucy? I guess saucy will not thaw any more, i. e. freeze until release?
<tjaalton> doko_: the -ati update was unnecessary, as xorg-server got fixed..
<tjaalton> I was about to respin the builds
<doko_> tjaalton, does this mean you'll have time to look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5005733 ? ;)
<tjaalton> doko_: ouch :)
<tjaalton> "bus error", isn't that a hit-or-miss failure?
<doko_> I can give it back
<tjaalton> hmm we didn't merge 1.6.x
<doko_> tjaalton, persists
<tjaalton> dunno then, at least 1.6.1 builds fine on sbuild
<tjaalton> 1.5.0-0u1 fails right in the beginning
<tjaalton> nls/Makefile.am:41: error: using '$(srcdir)' in TESTS is currently broken: '$(srcdir)/compose-check.pl'
<tjaalton> oh that was fixed in -0u2
<pitti> cjwatson: do you already have a debdiff for the missing *_id in udev-udeb, or want me to work on that now?
<Laney> pitti: langpacks> I think we're basically released modulo announcements, so seems fine to me
<pitti> Laney: can't parse "basically released modulo announcements", but I take the "seems fine" :)
<Laney> I mean that the release is rolled but couldn't be announced because it required London people for whom it was too late
<pitti> Laney: oh, the final beta
<Laney> yeah
<pitti> right, accepting then
<pitti> thanks
<pitti> Laney: are we going to thaw again then, or will it stay frozen?
<Laney> It'll stay frozen now
<infinity> pitti: Staying frozen, but unseeded is now auto-accepted, thanks to some hackish new magic.
<infinity> pitti: So, vaguely a best of both worlds.
<seb128> pitti, infinity: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/16775 \o/
<Laney> I divined that from #-release backlog but probably worth mailing -release about it
<seb128> "[r=wgrant][bug=1201485] Packages copied from PPAs to archive now have
<seb128>  their translations copied as well."
<pitti> seb128: en effet, j'ai le vu !
<infinity> Laney: I'll do that after I get the release announce out.
<seb128> pitti, is that enough to get the templates automagically updated again?
<Laney> sweet
<pitti> seb128: shoudl be
<pitti> seb128: I'm just uploading new langpacks (they were supposed for final beta, but apparently LP had a hiccup and didn't give me an export until last night)
<infinity> seb128: Oh shiny, that got done?  Yay.
<pitti> seb128: but of course that won't have the new translations yet; but after that I'll re-enable the daily cron, so we should get the new love ASAP
<seb128> pitti, ok, thanks
<infinity> seb128: Be sure to thank Ursinha for that when you see her. :)
<seb128> infinity, will do
<cjwatson> pitti: I don't (just to close the thread from another channel ...)
<cjwatson> seb128: Note that that isn't QAed/deployed yet
<cjwatson> http://lpqateam.canonical.com/qa-reports/deployment-stable.html
<cjwatson> But yeah, excellent to have that
<seb128> cjwatson, ok, thanks for pointing it out ... I've no clue about lp deployments, but I guess I can keep watching that page to know when it really lands?
<cjwatson> seb128: yes, once that clears it's landed, give or take half an hour or so
<seb128> great
<seb128> cjwatson, thanks
<diwic> didrocks, hi, is it okay to upload a PulseAudio if the only changes are bug fixes in modules we don't make use of on the phone?
<didrocks> diwic: yeah, please go ahead
<diwic> didrocks, thanks, will do that later today then
<pitti> cjwatson: all prepared (also the cleanup of the two unneeded rules, thanks for pointing out); doing test build now, etc., and standing by for ogra's "go" (for the stack of packages for bug 1227520)
<ubottu> bug 1227520 in systemd (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,Fix committed] https://launchpad.net/bugs/1227520
<infinity> pitti: Did you change timezones between apport releases? :)
<infinity> pitti: (The git log -> ChangeLog autogenration threw everything out by a day, which is entertaining)
<pitti> infinity: yes, I did the previous apport release in New Orleans
<pitti> infinity: git log? apport is in bzr
<infinity> pitti: bzr log, whatever. :P
<infinity> pitti: Maybe your ChangeLog export magic should set TZ=UTC, so ChangeLog doesn't get a 20k diff when you move around. :)
<pitti> infinity: urgh, I didn't consider that it would do that, sorry
<infinity> pitti: No big deal.  Was fascinating reading for the first few entries until I noticed the +/- markers and realised the next 20k of diff was useless. :)
<pitti> infinity: yeah, TBH I just skipped over it and didn't even notice
 * pitti uses "/^--- " to jump to the next file in a diff
<infinity> I was reading it in firefox, which was my first mistake.
<pitti> seb128: new gvfs packaged, tested, uploaded FYI
<seb128> pitti, \o/
<seb128> pitti, danke
<cjwatson> pitti: Great, thanks
<labsin> mardy, I have a question about online accounts. I try to add my mobile provider to online accounts, but it fails.
<labsin> It uses OATH1.0 like the twitter plugin and I've tested my keys and the twitter keys with a Python library and there they both work the same.
<smartboyhw> Which package is the GRUB "Ubuntu" item information put in?
<cjwatson> smartboyhw: Could you elaborate?
<smartboyhw> cjwatson, like, when I select the "Ubuntu" option in the GRUB menu, what's the settings and parameters behind? And which package are these parameters defined?
<cjwatson> smartboyhw: Well, you can press 'e' on it to see the settings
<cjwatson> smartboyhw: They're defined in the grub2 source package
<smartboyhw> cjwatson, OK, but it's difficult to find out the patch that defines it...
<cjwatson> smartboyhw: It's mostly upstream behaviour
<cjwatson> util/grub.d/10_linux
<smartboyhw> cjwatson, what about the UEFI option?
<cjwatson> Well, you can just look at the unpacked source package which will unpack with all the patches applied
<cjwatson> There's some UEFI code added by things like mkconfig_signed_kernel.patch, certainly
<xnox> zul: how about I just take the cherrypy3 autopkgtest into debian & sync into ubuntu, instead of introducing delta?
<zul> xnox:  sure
<mdeslaur> tkamppeter: hi! Is there a public repo for hplip somewhere?
<tkamppeter> mdeslaur, no, there are only the releases. Is there a new security bug?
<mdeslaur> tkamppeter: no, I'm just looking at an old security bug I have not fixed yet, and wanted to look at some historical commits
<mdeslaur> tkamppeter: thanks!
<stokachu> what do we do if a package doesn't have a changelog entry for the series its released in? keepalived for both raring and quantal are exactly the same, should i bump raring to a higher SRU number?
<mdeslaur> stokachu: append the version number of the release. For example: 1ubuntu1 becomes 1ubuntu1.12.10.1 for quantal and 1ubuntu1.13.04.1 for raring
<stokachu> mdeslaur: ah ok thanks!
<cjwatson> stokachu: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has detailed recommendations
<cjwatson> (which agree with what mdeslaur said, of course, but go into more detail)
<stokachu> cjwatson: thanks i got it bookmarked
<stokachu> doko: would you be able to get to bug 995719 by today or monday?
<ubottu> bug 995719 in puppet (Ubuntu Precise) "process_name.rb removed in 2.7.11 but still provided by puppet-common" [High,Confirmed] https://launchpad.net/bugs/995719
<eLpm> Hello. After the latest saucy update, I receive this error on startup: Sep 27 17:40:57 pc4 kernel: [   42.380067] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 2, found 0)
<eLpm> Ubuntu logs in normally so I am not sure about the severity...
<rohan> hi.. does anyone know what power backed does ubuntu 13.10 use? does it still use pm-utils?
<Noskcaj> rohan, It depends on the flavour, i think ubuntu itself does
<rohan> Noskcaj: ubuntu uses pm-utils still?! it has been dead since 2010
<Noskcaj> rohan, I think so (not sure). Xubuntu is missing it and needs it to fix some bugs
<rohan> that's a shame.. pm-utils also doesn't support in-kernel hybrid suspend
<slangasek> Ubuntu uses upower, with pm-utils as the actual low-level "suspend now" interface
<slangasek> I don't think it's interesting that pm-utils is "dead", that just means there are no changes needed
<slangasek> we don't support hibernation on the Ubuntu desktop, period, so in-kernel hybrid suspend is also not interesting
<rohan> slangasek: pm-utils is "dead" dead, because they haven't been accepting patches for a while now.
<rohan> slangasek: on a laptop, not supporting hibernate can be crucially dangerous
<slangasek> rohan: nonsense.  We support suspend, followed by shutdown on critical power
<rohan> slangasek: and how is that a better solution than hybrid suspend?
<slangasek> because it doesn't go pearshaped when the sizing of your swap partition is wrong
<rohan> you end up losing state, when you don't have to
<slangasek> we disabled the hibernate option because it was *unreliable*
<sarnold> are you telling me this sixteen gig swap partition wasn't necessary? :)
<slangasek> sarnold: I assume you're using yours steganographically :P
<rohan> slangasek: i'd love to know more about why it was determined to be unreliable. any links i could read?
<slangasek> rohan: none that I have to hand; I believe there was a blueprint and possibly a UDS discussion at the time the decision was taken
<rohan> also, how is the "critical battery" check done? using timers?
<slangasek> it uses the ACPI support for this
<rohan> seems so much more inefficient and counter-intuitive, than just having hybrid suspend.
<slangasek> hybrid suspend relies on the kernel taking the time to write out the entire system's memory to swap, which a) is slow, b) may not finish before your battery runs out anyway, resulting in even greater risk of data loss than if we'd just done a controlled shutdown
<stgraber> there were talks at last vUDS to support Intel's hardware hybrid-suspend equivalent that got introduced with Ivy Bridge and comes with the relatively sane restriction of working only on machines with <= 8GB of RAM
<rohan> slangasek: i don't mean doing hybrid suspend when battery is critical, i mean doing a hybrid suspend always. just like windows and Mac OS do it.
<stgraber> so on those systems it may be reasonable to allocate 8GB of space for suspend (assuming the user doesn't care about disk encryption, in which case they should opt out of it as the state isn't encrypted)
<stgraber> and there's nothing for the OS to do, the firmware does it all, so we don't have to care about it from our side of things (just need to create the partition with the right label/guid at install time)
<slangasek> rohan: ah, right - sorry, of course hybrid suspend means that you don't actually suspend until you've first written the hibernate image to disk
<slangasek> so you don't have the "wake up, hibernate, run out of time" problem
<rohan> right
<slangasek> but you do have the "takes forever to suspend because it has to write to swap first" problem
<rohan> it will happen after you close the lid, so you're unlikely to notice the higher time anyway. in the long run, it's safer because then your state is saved even if the battery runs out
<stgraber> anyone who doesn't completely trust their hardware will notice. I never put a machine in a bag until I see the suspend led confirming it's fully suspended
<stgraber> I've got way too many machines almost burning me because they didn't suspend properly
<rohan> fair enough. i guess people who took decision are more informed and have done more testing than me; and this channel is probably not the best channel to argue about it :)
<slangasek> The decision was taken directly because hibernate ws found to be unreliable.  Now that's something that could be revisited, but there's a lot of developer time that would have to go into *making* it reliable before we would flip the switch again
<rohan> if your system ACPI is wonky, sleep will be as unreliable as hibernate. as far as i understand, only reason hibernate will be more unreliable is if you have a wrongly sized partition, a case which should be handled by pm-utils (and is, iirc)
#ubuntu-devel 2013-09-28
<johey> If started without quiet and splash kernel parameters, it just says "Loading Linux 3.8.0-31-lowlatency ..." then hangs at the purple screen.
<johey> First question first :)... If my kernel hangs at boot when using lowlatency, how can I start tracking the problem down? Using Ubuntu 13.04 with official lowlatency kernel package.
<johey> You can see a cursor or underscore at the line below, but it won't react on any keypress.
<johey> Using a ThinkPad X1 Carbon, amd64 kernel.
<pjotr> cjwatson: there's a regression in saucy beta, that affects Dutch users: the wrong keyboard layout is selected by default.
<pjotr> I've submitted the following bug report about it: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1232523
<ubottu> Ubuntu bug 1232523 in console-setup (Ubuntu) "Default keyboard layout for Dutch is wrong (regression)" [Undecided,New]
<pjotr> Can you perhaps fix it? It's a rather important bug, because it affects ubiquity as well...
<saiarcot895> How do I go about installing an apport hook? Can I just place it in the debian folder (debian/packagename.apport), or do I need to specify the path in the install or rules file?
<saiarcot895> How do I go about installing an apport hook? Can I just place it in the debian folder (debian/packagename.apport), or do I need to specify the path in the install or rules file?
<slangasek> saiarcot895: easiest way would be to add a build-dependency on dh-apport, and reference it in debian/rules; if using dh(1) (which is strongly recommended), you only need to add --with=apport to the dh call
#ubuntu-devel 2013-09-29
<Noskcaj> Can someone please make jackd2 rebuild? The build crashed because libopus-dev  wasn't ready at the time
<sladen> Noskcaj: I've hit "Retry this build" for jackd2 1.9.9.5+20130622git7de15e7a-1
<Noskcaj> sladen, thanks
<sladen> Noskcaj: "Missing build dependencies: libopus-dev"
<Noskcaj> sladen, I'm stupid, issue is opus isn't in man
<Noskcaj> *main
<infinity> sarnold: Looks like another MIR is waiting on you (bug #1196967) ... No pressure. :)
<ubottu> bug 1196967 in opus (Ubuntu Saucy) "[MIR] opus (b-d of jackd2)" [High,Incomplete] https://launchpad.net/bugs/1196967
<Noskcaj> kirkland, Did you ever finish the vmware for testdrive?
<saiarcot895> If a bug report and stack trace from a PPA package is received, will the Apport retracing service use the appropriate -dbg package from that PPA?
<saiarcot895> *well, crash report and stack trace
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_sdma.bin for module radeon
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_rlc.bin for module radeon
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_mec.bin for module radeon
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_ce.bin for module radeon
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_me.bin for module radeon
<Peace-> W: Possible missing firmware /lib/firmware/radeon/KAVERI_pfp.bin for module radeon
<Peace-> 13.10
<Peace-> ??
<smartboyhw> Peace-, it's OK to ignore
<smartboyhw> Kaveri hasn't even existed yet-.-
<Peace-> ok smartboyhw tx
<ion> Kaveri, huh? Thatâs Finnish for a pal.
<alkisg> In theory, would it be possible to boot 13.10 in a non-pae system, using an appropriate 486 kernel from debian?
<labsin> ping mardy
<rbasak> pitti: re: psql version. I don't think we care enough about it to justify an FFe.
<rbasak> jamespage: ^^ any thoughts? Original message was: 15:44 <pitti> rbasak: ^ do you care much about which psql version is in saucy? (
<rbasak> I had thought not, given that the non-LTSes are not a very attractive server pla
<rbasak> tform anyway)
#ubuntu-devel 2014-09-22
<pitti> Good morning
<dholbach> good morning
<mlankhorst> morning
<manuel___> hi
<manuel___> HI, How can I start with the development from Ubuntu?
<diwic> manuel___, hi, more specifically, what do you want to do?
<manuel___> I have no plan, about the development from Ubuntu. So, I look then. What is a good get to in?
<diwic> manuel___, do you mean you want to help developing Ubuntu itself, or developing your own software that runs on Ubuntu?
<manuel___> Sorry, my last sentence is bad. "What is a good get to in?" should be called "So, what is a good way to get in?"
<manuel___> sorry for my bad english
<manuel___> first point
<diwic> manuel___, no worries about the English, we have many nationalities here - you'll learn gradually just like the rest of us
<diwic> manuel___, so are you interested in coding, testing, writing documentation, advocating Ubuntu, etc...?
<diwic> manuel___, there are many things you can help out with
<manuel___> I am much interested as programming treiber, but that is to high for me now. Right? So, what are other ways.
<manuel___> ?
<manuel___> sorry treiber is german for driver. so I mean driver
<diwic> manuel___, then maybe contacting the German LoCo team could be a good start?
<diwic> manuel___, http://loco.ubuntu.com/teams/ubuntu-de-locoteam/ - they seem to have interesting activities in German
<diwic> manuel___, or, if you're interesting in programming drivers (I assume drivers for hardware?), start with a driver that needs testing or fixing and try to contact people that are already working on that driver
<manuel___> that heard it better.
<diwic> manuel___, often driver developers don't have all hardware themselves, and need people that can test their new drivers. That could be a way to get involved.
<manuel___> Is there a tutorial to learn the basics of driver programming.
<diwic> manuel___, it depends on how much you can code already, but http://lwn.net/Kernel/LDD3/ can be a good start
<manuel___> thanks
<manuel___> And bye. I log me now out.
<ogra_> oh !
<ogra_> mail to the ubuntu-backports list ...
<ogra_> that only happens once a decade !
<Laney> I don't think anyone other than me ever mails that list :(
<mlankhorst> must find doko..
<ogra_> Laney, well, i read it at least ... :)
<pitti> hey stgraber, how are you?
<pitti> stgraber: do you still plan a new LXC upstream version for utopic, or might it be better at this point to cherry-pick the systemd unit fixes, or do you want to postpone them to V altogether?
<pitti> (I'm happy to provide an updated package, but don't want to step on your toes)
<stgraber> pitti: so my current plan is (but we'll see if the release team agrees) to finish the systemd changes upstream this week (still resolving some problems), release alpha-2 ideally by EOW and then get that into utopic
<stgraber> I also have 1.0.6 that's around the corner and aimed at trusty
<pitti> stgraber: ah, great, thanks; please tell me if/when you need assistance with the dh_systemd_* bits
<ScottK> If there's a u-d-a ML moderator around, I just put one in queue for review.
<mdeslaur> cjwatson: FYI, I'm stealing your nginx merge
<Logan_> hallyn: would you mind prepping/uploading the SRU for vde2 (including the fixes for Bug 804647, Bug 629349, and Bug 781411)? I'm kinda tied up with stuff at the moment
<ubottu> bug 804647 in vde2 (Ubuntu Precise) "vdeterm does not restore terminal when it returns in error" [Undecided,Confirmed] https://launchpad.net/bugs/804647
<ubottu> bug 629349 in Kubuntu PPA "libqt4-multimedia package broken" [Undecided,Opinion] https://launchpad.net/bugs/629349
<ubottu> bug 781411 in vde2 (Ubuntu Precise) "slirpvde: Massive memory leak" [High,Triaged] https://launchpad.net/bugs/781411
<hallyn> Logan_: ok, will do
<Logan_> er, second one should've been Bug 629439
<ubottu> bug 629439 in vde2 (Ubuntu) "Bug vde_plug input handling can cause ehter frame loss/corruption or buffer overread by 1" [High,Triaged] https://launchpad.net/bugs/629439
<Logan_> ideally a new version should be uploaded to lucid
<Logan_> and then it can be copied up to precise
<hallyn> Logan_: oh feh.
<hallyn> i was only looking at one bug.  missed the multiple bugs you quoted
<hallyn> arges: are you around?  could you quickly reject the two vde2 packages i uploaded (to lucid-proposed and precise-proposed)
<hallyn> i got ahead of myself
<arges> hallyn: hey
<arges> sure
<hallyn> thx!
<Logan_> heh
<arges> hallyn: ok done
<hallyn> Logan_: though, for https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/781411  i never ws able to reproduce it.  so can't really write a sru justification.  i'd vote for calling it invalid
<ubottu> Launchpad bug 781411 in vde2 (Ubuntu Precise) "slirpvde: Massive memory leak" [High,Triaged]
<Logan_> incomplete, at least
<Noskcaj> ScottK, Can you look at my last comment on 1372224
<Noskcaj> * bug 1372224
<ubottu> bug 1372224 in tortoisehg (Ubuntu) "[FFe] Upload version 3.1.1 to utopic" [High,Triaged] https://launchpad.net/bugs/1372224
<ScottK> Commented
<Noskcaj> ScottK, So are you going to sync it?
<ScottK> No.  Please subscribe sponsors.
<ScottK> Busy with $work.
<Noskcaj> ok
#ubuntu-devel 2014-09-23
<hallyn> stgraber: practical question .  to migrate a kvm vm from old release to newer release, we need the old rom's (like pxe-virtio) on the new releases.  But the new releases have updated versions of the roms.  Is there a good way to support this?  i can't ship binary roms, and the old roms may not build on the new releases...
<hallyn> i may be making this up, maybe it's not an issue excpet in my current broken case, but i'm not sure
<stgraber> hallyn: I'm having a hard time understanding why the VM would need the old ROM
<hallyn> stgraber: bc at the destination qemu you have to start qemu with that romfile loaded
<hallyn> stgraber: so for instance if a precise kvm has a virtio nic, and you want to migrate that to a trusty host,
<hallyn> (for which you have to use my ppa right now,) you have to use:
<hallyn> sudo qemu-system-x86_64 -enable-kvm -drive file=/mnt/mini.iso,if=virtio,cache=none -m 256M -cdrom /mnt/mini.iso -boot d -vnc :1 -incoming tcp:0.0.0.0:5555  -global virtio-net-pci.romfile=pxe-virtio.rom.12.04 -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no -M pc-1.0-qemu-kvm
<hallyn> the "-global virtio-net-pci.romfile=pxe-virtio.rom.12.04" argument tells kvm to load the old romfile.  if you let it load the new rom, thenmigratoin fails
<hallyn> but i don't know how to sanely ship that romfile.  i have little faith that we can actually build a new one in trusty let alone 16.04
<hallyn> anyway i've also asked the question of rharper.  i'll let this sit for a day while we think of alternatives.  mayb ei'm being silly.
* infinity changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<stgraber> hallyn: sounds like a qemu bug to me... bios roms are loaded in memory, so if the VM was actively using the extension, it'd be in memory and so, not a problem. Otherwise, it's just a path to something it needs to read at boot time, so it should be perfectly fine to point it to whatever's current on that box...
<hallyn> stgraber: i think it's just complaining about the file size.  which makes me wonder whether i could just create a file of the right size with all zeros
<stgraber> hallyn: :)
<hallyn> stgraber: lol - it works!
<hallyn> well it hangs at 'detect network hardware' but it did that before too.  (this all feels very flaky)
<pitti> Good morning
<dholbach> good morning
<dupondje> the ubuntu mozilla team seems sleeping? :D
<chrisccoulson> dupondje, not so much sleeping, but dead
<nrange> like to build ubuntu core for arm device, Could any body provide me link for the same.
<pitti> mvo: hey Michael, wie gehts?
<mvo> pitti: not too bad, thanks. how are you?
<pitti> mvo: great, thanks! you don't happen to have an idea about https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/ARCH=amd64,label=adt/31/console ?
<pitti> mvo: the test works fine on i386, but fails on amd64 (severeal times)
<pitti> initially I thought it was something in binNEW or so, but that doesn't seem to be the case
<mvo> pitti: let me investigate and see if I can reprouce it
<pitti> mvo: it works fine for me locally
<pitti> mvo: nevermind for now, I just wanted to know if you already happened to know about it
<pitti> before I start digging
<mvo> pitti: thanks, its probably transient, as it will look at the build-hosts sources.list (which is a bug in itself)
<pitti> mvo: seems to be a little more than that, though; look at the history at https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/
<mvo> pitti: indeed :/
<pitti> mvo: oh, perhaps this is fallout from the new proxy settings; but why would that affect only one arch
<pitti> anyway, I'll poke this
<mvo> pitti: hm, I wonder if I overlooked a mail here?
<mvo> pitti: would jenkins have mailed me about the failure?
<pitti> hm, seems it didn't in this caes
<pitti> case
<mvo> because the failure affects only a single architecture?
<pitti> sheesh, and now it succeeded
<mvo> haha
<mvo> schrÃ¶dingers cat
<pitti> mvo: sorry for the noise then; I retried 5 times in the past days and it kept failing..
<mvo> no worries, I really need to fix it to use proper fixtures data instead :/
<pitti> mvo: yet another instance of "the problem disappears/becomes clear to me as soon as I ask someone"
<mvo> :)
<seb128> jibel, hey, just curious but why do you tag fix released bugs?
<jibel> seb128, they are not fixed on #1
<jibel> 14.09 #1
<seb128> jibel, we are on #56, most of the bugs are not fixed on #1 ;-)
<jibel> seb128, 14.09-proposed is #56 but 14.09 is #1
<seb128> oh ok
<seb128> the tag names are confusing then
<seb128> is that a way to say "needs-fixing-in-stable"?
<nrange> I trying to get ubuntu-core source code ,
<nrange> where do I get ubuntu-core source code & cross compilation link for ARM.
<ogra_> nrange, from archive.ubuntu.com ... it is in source packages
<ogra_> nrange, ubuntu-core itself is assmebled from the corresponding binary packages
<cjwatson> mdeslaur: nginx> no problem, thanks
<nrange> ogra_ :Is it possible to get ubuntu-core source code through apt-get command?
<ogra_> you need the list of packages
<ogra_> then you can apt-get source the packages
<rbasak> mdeslaur: speaking of nginx, looks like it's failed dep8.
<rbasak> (so stuck in -proposed)
<rbasak> I don't think these dep8 tests have ever been in Ubuntu. Debian rewrote the one I submitted.
<rbasak> Is there a tool that will let me easily download the already-built binaries from the archive corresponding to a given source package and architecture?
<rbasak> I know I can fetch them by hand from Launchpad.
<rbasak> (and I'll provide the version, of course)
<rbasak> I just set off a local build to reproduce a dep8 issue in utopic-proposed, and realised that's a bit pointless since I can fetch the archive binaries.
<rbasak> Except that it's tedious.
<rbasak> mdeslaur, pitti, jibel: I can't reproduce nginx dep8 failure in utopic-proposed locally. The logs look about the same, and it passes for me.
<rbasak> The Jenkins result appears to be a 404, which seems a bit odd. That suggests to me some issue in the test rather than the environment, but I don't see anything obvious.
<nrange> ogra_ :  gone through (https://wiki.ubuntu.com/ARM/RootStock) doc, could u provide link for to get ubuntu-core package list.
<ogra_> nrange, rootstock is dead since several years, dont use it
<ogra_> nrange, look at the manifest file at http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<dholbach> salut seb128, is bug 1352142 something that happyaron or FJKong could ACK and we could get uploaded?
<ubottu> bug 1352142 in ubuntu-touch-meta (Ubuntu) "Doesn't load Japanese font on Ubuntu Touch" [Medium,In progress] https://launchpad.net/bugs/1352142
<ogra_> ugh, another font ?
<ogra_> we're just ripping them out like crazy to get the image size down :/
<seb128> dholbach, hey, no idea what are the ffe/release rules for touch
<seb128> dholbach, try asking on #ubuntu-ci-eng I guess
<Laney> why are you asking the chinese guys about a japanese font? :P
<seb128> because japanese looks chinese to him? ;-)
<pitti> rbasak: one possible issue could be that in the DC tests run wiht a proxy
<pitti> rbasak: is this test hitting the network?
<dholbach> Laney, I think they're both in touch a lot with others who look into CJK issues, so they might know where to look up which fonts are recommended
<dholbach> Laney, something I don't know anything about
<Laney> was just doing some minor tuesday trolling, sorry
<rbasak> pitti: aha.
<rbasak> pitti: no, but it is hitting 127.0.0.1.
<Laney> there's some feedback from a Japanese guy in there so I'd think it's okay depending on the touch guys
<rbasak> pitti: and that 404s. So presumably that request is going to a proxy, which 404s on its _own_ 127.0.0.1?
<infinity> If the test rig's proxy proxies for localhost, that pretty much breaks any attempt to test any http daemon.
<rbasak> pitti: can you add a no_proxy environment?
<infinity> Seems like a bug. :P
<dholbach> seb128, I just looked at the MP - looks like it affects desktop as well
<rbasak> Either that or the test needs to specifically unset http_proxy.
<rbasak> I'm not sure it even makes sense to set that in the test environment.
<rbasak> A transparent proxy might work better here (as evil as they are).
<rbasak> mdeslaur, pitti, jibel: filed bug 1372903. As the test passes locally from the built binaries in utopic-proposed, do you want to override the test failure for now?
<ubottu> bug 1372903 in autopkgtest (Ubuntu) "Ubuntu dep8 CI environment sets http_proxy causing http://127.0.0.1 to fail" [Undecided,New] https://launchpad.net/bugs/1372903
<pitti> rbasak: re (sorry, was out for a bit)
<pitti> rbasak: we do set that: http_proxy=http://squid.internal:3128 https_proxy=http://squid.internal:3128 no_proxy=localhost,ubuntu.com,launchpad.net
<pitti> rbasak: ah, we might need to add 127.0.0.1 to no_proxy, not just "localhost"?
<rbasak> pitti: that might be it.
<mdeslaur> yes, the autopkgtest in debian went from localhost to 127.0.0.1
<rbasak> Maybe 127.0.1.1 as well?
<rbasak> I still think there's a bigger issue here though (hence the bug).
<pitti> rbasak: ok, trying that; the machines are a bit busy ATM, so that'll take a while
<pitti> mdeslaur: ah, splendid; that would fit pretty well
<infinity> pitti: It would be a lot more elegant if that was implemented as a transparent proxy outside the VM, rather than exporting http_proxy in the test session.
<pitti> infinity: absolutely
<rbasak> We're changing behaviour in tests by setting these variables, and depending on what is being tested, this won't necessarily do the right thing.
<infinity> pitti: A test session having unexpectedly weird environment is... Weird. :)
<pitti> infinity: but that's not how our data center does it, so we need to set these stupid vars everywhere :/
<rbasak> infinity: I suggest having the test declare that it needs external internet access, and when it does, to require that the test can grok the variables.
<pitti> hopefully we won't have to any more in bootstack
<infinity> pitti: Hrm?  I'm not sure how the DC factors into this.  Your VMs can have transparent proxies on the host that forward to the DC proxies.
<rbasak> A transparent proxy is still not great. It does cause client issues in some cases.
<rbasak> I'd rather push responsibility to the test.
<rbasak> (and use non-transparent caches)
<infinity> rbasak: Well, 99% of tests should never be trying to hit the outside world anyway.
<pitti> infinity: ok, if that's possible I'm happy to send an RT about that
<pitti> right, there's only a handful which need that
<rbasak> Right, so do we need transparent caches on the ones that do?
<pitti> we only added the proxy vars a few weeks ago for two tests which want it
<rbasak> Make them explicit in that case.
<rbasak> (my bug outlines a proposed spec)
<cjwatson> the problem is tests that shouldn't hit the outside world but accidentally do.
<infinity> But trying to hit the local host should be very common, and trying to be clever and guess what that is (or doing a blanket exclude of 127.0.0.0/8) is kludgy.
<cjwatson> for example any of the gazillion things that will sometimes call out to fetch dependencies (maven, pip, etc.)
<rbasak> Yeah, so by default: no inteference, and no access to the outside world.
<cjwatson> oh right yeah
<rbasak> If the test wants access, then it could declare a restriction, and then it would get access, but is required to grok http_access etc.
<rbasak> http_proxy
<infinity> Yeah, that's also workable.
<infinity> I do like the idea of no non-lo network by default.
<infinity> To catch people accidentally doing it rather than intentionally.
<rbasak> Yeah, and also easier to analyse
<rbasak> (to track packages down that are doing it but don't really need it)
<infinity> pitti: So maybe that's the better solution.
<infinity> pitti: Make those few tests actually declare that they need external access instead of granting it to everyone.
<rbasak> Of course the catch here is that pitti now has to implement that :)
<infinity> Sounds pretty trivial.
<infinity> Except for the addition to the spec.
<infinity> No idea how fluid that is.
<rbasak> The spec is designed so that restrictions can be added. But a catch is that we're taking away functionality from existing tests.
<rbasak> But if the number of affected tests is small, then that shouldn't be a problem.
<infinity> rbasak: Well, by pitti's admission, those tests only got this functionality very recently. :P
<pitti> finding and changing the tests is the real work here, not so much juggling the infrastructure
<infinity> rbasak: So, it's a short-lived thing to take away again.
<pitti> well, it also fixed some tests which had failed forevery
<pitti> s/y$/
 * rbasak suspects juju might be affected
<infinity> pitti: I guess no one kept a list of the tests that were fixed by implementing the http_proxy stuff?
<rbasak> Though that's been around for a while now.
<pitti> but we also at some point want to move testing to bootstack, then this will hopefully also be obsolete
<infinity> pitti: Still, I think it's better to be declarative here, rather than assume an external network.
<rbasak> pitti: even after the move, it'd be nice to not have tests arbitrarily accessing the Internet unless they declare that they need to.
<rbasak> That'll help keep things under control.
<infinity> pitti: Cause that also makes it way easier to diagnose, if you say you need an external network, and my test infra doesn't have one, or doesn't have access to the right hosts, I know what's up more easily.
<rbasak> Too many packages hitting the Internet == many arbitrary failures.
<infinity> Plus, yes, reliance on external resources is usually wrong, unless absolutely the only way to test your thing.
<infinity> The internet being such a reliable thing and all.
<rbasak> I had fun with python-websocket (IIRC) having tests that hit a websocket test server on the Internet.
<infinity> PS: Why am I still awake?
<cyphermox> because you're not drunk enough yet?
<infinity> Or at all.
<mdeslaur> lol
<happyaron> dholbach: hey I think if we do want to have Japanese fonts included, then fonts-takao-pgothic is the one to go
<pitti> rbasak: nginx succeeds again
<rbasak> Great. Thanks!
<mdeslaur> thanks pitti, rbasak!
<pitti> rbasak, infinity: I left some thoughts on bug 1372903
<ubottu> bug 1372903 in Auto Package Testing "Ubuntu dep8 CI environment sets http_proxy causing http://127.0.0.1 to fail" [Undecided,Fix released] https://launchpad.net/bugs/1372903
<rbasak> pitti: could you "unshare -n" to enforce the restriction for adt-virt-null, etc?
<pitti> rbasak: (1) breaks installing dependencies, (2) needs root
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: seb128
<pitti> rbasak: we can't cut off the network completely
<rbasak> pitti: for apt, use a proxy that permits only access to the archive.
<pitti> rbasak: otherwise we could simply start qemu without a network card, etc.
<rbasak> Good point about root though.
<pitti> we need a proper network interface, and then restrict it to the set of deb sources
<pitti> (there might be many, cf. testing PPAs, etc.)
<pitti> TBH, I think it's a lot of work for a result which still isn't robust, and for only little gain
<pitti> but maybe I'm missing something, we might discuss that face to face at some point
<pitti> just saying that the proxy thing will go away soon, ev is pressuring hard for getting rid of our current machines
<pitti> and so am I, these are hopelessly overloaded
<rbasak> OK, no worries.
<ev> +1
<pitti> ah, this also fixes php-guzzle
<pitti> and I have a gut feeling that it might also fix the python autopkgtests without the workaround of explicitly unsetting the proxy vars
<pitti> rbasak: anyway, if you have an idea about a robust design, I'm happy to be convinced (honestly)
<rbasak> pitti: thanks. You raise good points. I'll have to think a little and see if I can come up with something that addresses everything.
<pitti> rbasak: let's stick our heads together in DC and add some beer :)
<rbasak> I won't be in DC.
<pitti> oh, too bad
<pitti> servers aren't the right kind of devices? :-)
<rbasak> Yeah, something like that!
<pitti> rbasak: thanks so much for pointing out the proxy bug -- this fixed at least two other tests (and presumably there's some more)
<rbasak> No problem! You provided the vital clue :)
<dholbach> happyaron, if we want this new one, can we drop one we used before?
<dholbach> happyaron, could you comment on the bug and/or MP=
<dholbach> ?
<FJKong> dholbach: he is not at front of computer,maybe
<dholbach> FJKong, do we know who could have a look at the bug or merge proposal and make a decision?
<FJKong> dholbach: you mean bug: https://launchpad.net/bugs/1352142
<ubottu> Launchpad bug 1352142 in ubuntu-touch-meta (Ubuntu) "Doesn't load Japanese font on Ubuntu Touch" [Medium,In progress]
<dholbach> yep
<arges> ChrisTownsend: hey, should i review that unity SRU for trusty...
<ChrisTownsend> arges: Please
<ChrisTownsend> arges: Thanks
<arges> ChrisTownsend: looks like you guys have alot of DPI fixes... did somebody get a fancy monitor?  : )
<ChrisTownsend> arges: lol, well, it's stuff that just needed to be done.
<arges> ChrisTownsend: bug 1349128 is mentioned in the changelog, but it says its already fix released. Do you know what changed there?
<ubottu> bug 1349128 in Unity 7.2 "Ubuntu 14.04 lock screen doesn't accept keyboard input and sends it back to the underlying window (until using indicators)" [Critical,In progress] https://launchpad.net/bugs/1349128
<bregma> arges, that was a security upload that's now been folded back into upstream
<arges> bregma: ok, but I see more details in the changelog that looks like additional logic was added over the security update?
<arges> bregma: ChrisTownsend : also bug 1320071 is this fixed in Utopic?
<ubottu> bug 1320071 in Unity 7.2 "Power buttons do not work when the screen is locked" [Medium,In progress] https://launchpad.net/bugs/1320071
<smoser> kirkland, is http://launchpad.net/bugs/1350810 in correct state ?
<ubottu> Launchpad bug 1350810 in byobu (Ubuntu Utopic) "Shift-F2 no longer working in Byobu in Ubuntu 14.10 (utopic) with tmux 1.9" [Critical,Triaged]
<smoser> it says fix-released for tmux, but not for byobu
<kirkland> smoser: ah, yes, it's fix-release;  fix was in tmux
<kirkland> smoser: so probably invalid for byobu
<bregma> arges, I believe there were additional problems related to 1349128 fixed in trunk that were backported to 14.04 for the non-emergency fix
<kirkland> smoser: updated
<arges> bregma: ok
<bdmurray> pitti: Could you have a look at RT 1372612?
<bdmurray> pitti: I mean bug 1372612
<ubottu> bug 1372612 in apport (Ubuntu) "apport identifies RTM package as third party ones" [Undecided,New] https://launchpad.net/bugs/1372612
<bregma> arges, bug 1320071 is definitely fixed in utopic, don't know why ci-train missed changings its status
<ubottu> bug 1320071 in Unity 7.2 "Power buttons do not work when the screen is locked" [Medium,In progress] https://launchpad.net/bugs/1320071
<arges> bregma: ok i assume you'll update that then?
 * bregma fixes the status manually
<ara> bdmurray, hello! could you have a look to this unapproved SRU, please? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=unity-control-center
<arges> ara: i'm planning on getting to it today (its my day)
<ara> arges, sounds great, thanks!
<ara> arges, not really aware of how the sru queue is managed
<arges> ara: check https://wiki.ubuntu.com/StableReleaseUpdates
<bdmurray> ara: we have a daily rotation of sorts
<arges> section 4 shows SRU vanguards
<Elimin8er> Im trying to build a package.. when I use checkinstall everything works great. but I want to build it with the intent of putting it on my ppa.. anyhow when I use bzr builddeb -- -us -uc, I get error at the end, take a look here: http://paste.ubuntu.com/8408128/ .. I just dont get it.. Hopefully someone can give me a pointer or two.. .. I have asked in every other channel I could think of..
<ara> bdmurray, arges: nice! thanks! and sorry for nagging the wrong person :)
<arges> ara: its all good! glad I had this channel up to see the message
<bdmurray> ara: no problem
<ara> the sru team is too small... you guys are heroes
<bdmurray> ara: thanks
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: mdeslaur, seb128
<ChrisTownsend> arges: Hey again, any chance you look at unity8-desktop-session to get into trusty-proposed?  It's a pretty simple fix.
<arges> ChrisTownsend: yea its all on my radar
<ChrisTownsend> arges: Awesome, thanks man!
<arges> trying to do some kernel debugging ATM... so will context switch into SRU mode in a bit
<ChrisTownsend> arges: Ok, cool
<arges> hallyn: hey is bug 1038139 fixed in utopic already?
<ubottu> bug 1038139 in haproxy (Ubuntu Utopic) "Missing running check on init script" [High,Confirmed] https://launchpad.net/bugs/1038139
<hallyn> arges: I pushed that to utopic right before pushing the SRU packages
<arges> hallyn: ok shall i mark the utopic task fix released (not sure which version has that code in utopic) (also I'm being lazy. : ) )
<hallyn> arges: hm, no, something's not right
<hallyn> arges: d'oh, we're in beta freeze aren't we
<hallyn> arges: so we'll have to wait until that passes
<hallyn> if you don't mind please jsut leave the trusty/precise versions baking in the meantime :)
<arges> hallyn: yup will do. thanks
<hallyn> thank you
<arges> ChrisTownsend: is bug 1340394 fixed in utopic version?
<ubottu> bug 1340394 in Unity 7.2 "Overlay borders aren't scaled to match monitor DPI scaling" [Medium,In progress] https://launchpad.net/bugs/1340394
<ChrisTownsend> arges: I think so, but lemme check to be sure.
<arges> ChrisTownsend: thanks
<arges> ChrisTownsend: also not really something that matters for this SRU, but do you have a script that continually appends AUTHORS?
<ChrisTownsend> arges: Yeah, it was released into Utopic around July 11.
<arges> ChrisTownsend: ok marked that fix released then
<ChrisTownsend> arges: The release script in Unity does muck with AUTHORS.  Is there something wrong?
<arges> ChrisTownsend: well it just seems to be duplicating author names over and over, vs it being a uniq list
<ChrisTownsend> arges: Hmm...
<arges> anyway, doesn't matter for the SRU, might just want ot check your script
<ChrisTownsend> arges: I see 3 new AUTHORS entries and the entries themselves are unique in that the line is indicating the multiple authors are responsible for a commit.
<ChrisTownsend> arges: Do you see something different?
<arges> ChrisTownsend: no that's fine, I just usually see AUTHORS files with just a list of unique authors rather than commit->AUTHORS line mapping
<ChrisTownsend> arges: Ok, I see.  Well, I guess Unity really wants to give credit where credit is due:)
<arges> yep got it
<roaksoax> arges: why did the djanog upload get rejected?
<arges> roaksoax: i explained it in the bug report. there was an extra patch that wasn't explained in the changelog
<arges> 99_fix_test.patch
<roaksoax> arges: yeah that seems that it shouldn't be there for sure.. but it wasn't ebing applied either
<roaksoax> arges: thanks for noticing, let me upload a new one asap
<arges> roaksoax: cool. ping me when you do and I'll re-review
<sarnold> pitti: hello, are the retracers happy? 1372980 hasn't been handled yet (five hours at the moment) -- and lately things have been running pretty smoothly, this seems anomalous :)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: seb128
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<roaksoax> arges: uploaded a new one! thanks
<arges> roaksoax: this looks better... there is an extra line '+  * debian/patches/
<arges> in the changelog. but that shouldn't hurt things
<roaksoax> arges: awesome! thanks
#ubuntu-devel 2014-09-24
<Logan_> what is the easiest way to remove a file from the .diff.gz?
<RAOF> filterdiff?
<Logan_> good call
 * mdeslaur learns about filterdiff
<pitti> bdmurray: known issue, duped to bug 1362496
<ubottu> bug 1362496 in base-files (Ubuntu-rtm 14.09) "LSB release and /etc/os-release still say "Utopic", needs to be RTM" [High,Triaged] https://launchpad.net/bugs/1362496
<pitti> sarnold: hm, nothing stuck, let me check
<pitti> sarnold: ah yes, I think I see the problem; I'll look into it
<pitti> Good morning
<andrewrk> is utopic going to update to the official libav 11 release? current version in utopic is 11~beta1
<pitti> sarnold: I'm afraid I need to rebuild the apt-ftparchive db on ddebs.u.c., which takes painfully long :( (about 24 hours); I'm afraid the retracers will stay broken until then
<YokoZar> oops, I let this sync request stagnate: https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1361047
<ubottu> Launchpad bug 1361047 in libcdio (Ubuntu) "Please sync libcdio" [Undecided,New]
<Logan_> stagnation is sad
<thopre01> Hi there
<thopre01> I submitted a Feature Freeze Exception on 1st September and I was wondering if there is any chance it's going to be processed before the release
<thopre01> (given the short time remaining before release)
<thopre01> The FFe in question is for the ARM embedded toolchain: https://bugs.launchpad.net/ubuntu/+source/gdb-arm-none-eabi/+bug/1363788 https://bugs.launchpad.net/ubuntu/+source/libstdc++-arm-none-eabi/+bug/1363790 https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1363791 https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1363792
<ubottu> Launchpad bug 1363788 in gdb-arm-none-eabi (Ubuntu) "FFe: Sync gdb-arm-none-eabi 6 (universe) from Debian unstable (main)" [Undecided,New]
<ubottu> Launchpad bug 1363790 in libstdc++-arm-none-eabi (Ubuntu) "FFe: Sync libstdc++-arm-none-eabi 4 (universe) from Debian unstable (main)" [Undecided,New]
<ubottu> Launchpad bug 1363791 in newlib (Ubuntu) "FFe: Sync newlib 2.1.0+git20140818.1a8323b-1 (universe) from Debian unstable (main)" [Undecided,New]
<ubottu> Launchpad bug 1363792 in gcc-arm-none-eabi (Ubuntu) "FFe: Sync gcc-arm-none-eabi 11 (universe) from Debian unstable (main)" [Undecided,New]
<dholbach> good morning
<thopre01> Morning
<LocutusOfBorg1> hi people
<apachelogger> stgraber: more lxc problems :) http://paste.ubuntu.com/8416404/  <-  this from an unpriv container start done through a daemon (jenkins) that was sudo started from a user other than the one owning the container
<apachelogger> the execution env in both cases is exactly the same except for jenkins job variables, so I am not quite sure why it happens or how to prevent it (short of not restarting the daemon from other users anyway)
<cjwatson> andrewrk: Yeah, we always intended to.  I've thrown a sync into the queue.
<Laney> thopre01: I'll look at thos thanks for the pointer
<Laney> gremlins ate my "e,"
<thopre01> Laney: Thanks a lot
<caribou> before I go and make a mistake, now that I have PPU rights for sosreport & my fixes are in Utopic, all I have to do for my SRU is to upload (using dput) to trusty-proposed & subscribe ubuntu-sru to the bug, right ?
<caribou> and the difference b/w uploading to debian & to ubuntu is that, with ubuntu I upload the *source.changes, no binary
<RAOF> caribou: You don't actually need to subscribe ubuntu-sru to the bug; we'll process it from the unapproved queue.
<caribou> RAOF: ah, ok. Old habbit
<caribou> RAOF: so just the dput is enough
<RAOF> Yup.
<RAOF> Of course, you need to close the bugs from the changelog, but I presume you're doing that anyway :)
<caribou> RAOF: yep, it was already in the utopic upload
<caribou> hmm, rejected, no upload rights; looks like it has not been processed yet
<pitti> caribou: upload rights are configured by release, I figure it was just forgotten to also add you to previous releases
<pitti> (or maybe that's on purpose/by policy, I'm not sure)
<caribou> pitti: maybe only because my PPU rights got voted on by the DMB monday & they did not have the time to act upon it
<caribou> pitti: trying to upload was one way to check that out
<caribou> pitti: & true, I did not try to upload to Utopic yet
<pitti> caribou: ah, utopic is usually configured first; I thought the utopic upload worked and the trusty one didn't
<pitti> caribou: so yes, probably not acted upon yet
<caribou> pitti: no, it was sponsored to Utopic
<caribou> pitti: but thanks for the details :)
<smoser> cjwatson, i had a question for you at https://bugs.launchpad.net/curtin/+bug/1373137 .
<ubottu> Launchpad bug 1373137 in curtin (Ubuntu) "need to run update-grub when grub-install" [High,Triaged]
<smoser> basically, after blatting a tarball to disk, is there some way that i can know when i need to run update-grub. it seemed that dpkg-reconfigure would sometimes run it.
<cjwatson> smoser: subscribing me to the bug gives me more chance of seeing the question in mail :)
<smoser> cjwatson, i realized that i'd forgotten to subscribe you sometime in the middle of the night.
<cjwatson> answered, anyway
<smoser> cjwatson, so is just 'touch /boot/grub/grub.cfg' enough to convince dpkg-reconfigure to run update-grub ?
<smoser> i do suspect that os_prober is what was slow (and i've disabled that when running it). but doing less is nicer if i can.
<dholbach> pete-woods, everything all right? I'm not sure how I'm supposed to understand "Oh noes. The mod-bot got me!"? :)
<cjwatson> smoser: err I'm not sure, I suppose so, seems weird but if it produces sane output ...
<stgraber> apachelogger: can you pastebin /proc/self/cgroup? I suspect that your current user doesn't own the cgroup it's in and so can't create the cgroups required for lxc
<cjwatson> it's just a test -e
<cjwatson> smoser: I'm pretty sure os-prober can be sped up, that said :)
<pete-woods> dholbach: oh, the auto moderation bot rejected it because of the accounts policy
<cjwatson> I made a start on that last week, but I have ninety concurrent things to do so it hasn't got too far yet
<pete-woods> dholbach: although I still got an email saying it was published
<dholbach> beuno, ^
<smoser> cjwatson, thats fine. this is low priority. i'm worried about saving a couple seconds. not a big deal. thanks for your help.
<apachelogger> stgraber: earliest in 12 hours or so, assuming that is the case is there any way to make sure this doesn't happen?
<cjwatson> smoser: it was annoying me because I was debugging a crash so running it over and over again ...
<pete-woods> dholbach: I'm hoping you're still able to override the "accounts" failure, like happened the previews few times
<dholbach> pete-woods, Approved version:1.0.12
<dholbach> The last submitted upload (1.0.13) failed review.
<dholbach> hum hum
<dholbach> I can't see how to override it
<beuno> pete-woods, I'll take a look
<dholbach> thanks a bunch
<pete-woods> :)
<dholbach> beuno, if you'd prefer I ping somebody else about it, let me know
<stgraber> apachelogger: your best bet is to fix the permissions of the cgroup before dropping privilege to that user, you can do that with something like:
<stgraber> apachelogger: cgm create all <username>
<beuno> pete-woods, link?
<stgraber> apachelogger: cgm chown all <username> <uid> <gid>
<stgraber> apachelogger: cgm movepid all <username> $$
<apachelogger> it's a cgroup problem http://paste.ubuntu.com/8418342/
<stgraber> apachelogger: that'll move the current process (your shell) into a newly created batch of cgroups that are owned by the user you'll be switching to
<apachelogger> stgraber: I do wonder, shouldn't sudo su $user adjust the cgroup accordingly?
<pete-woods> beuno: this is app number 971 (youtube scope). it's been uploaded to the store at version 1.0.13 and the auto moderation bot as failed it because it uses the accounts policy group
<smoser> cjwatson, and for this particular use case, my solution of chmod -x is perfectly fine.
<cjwatson> yep
<stgraber> apachelogger: it's something we've been wondering and I believe it'd make sense but I guess that's not happening because sudo doesn't go through the right parts of the PAM stack and so logind never creates a new session
<smoser> as i dont *want* it to find other operating systems. i just installed the one i want.
<pete-woods> beuno: but dholbach can't seem to override this fail like has happened previously
<smoser> thanks again
<apachelogger> stgraber: I see
<stgraber> apachelogger: so ultimately that's a logind problem and not one we felt confident working around in Ubuntu as it's probable that some stuff depends on that behavior
<apachelogger> *nod*
<pete-woods> beuno: if you're not familiar, the accounts profile group is only currently allowed for canonical / trusted scopes
<stgraber> apachelogger: for one thing, if we were to do that, any process you spawn through sudo in your session will not be linked to your session anymore and so will not be killed at exit time (if you have that logind option enabled)
<beuno> pete-woods, right, we're working out the kinks with these auto-reviews
<beuno> sorry about that
<beuno> let me fix this for you
<pete-woods> beuno: the weird part, is that I still got an email saying my app had been published. even though the bot failed it
<beuno> pete-woods, indeed, that sounds like a bug
<cjwatson> smoser: (GRUB_DISABLE_OS_PROBER=true in /etc/default/grub or /etc/default/grub.d/foo is simpler, though.)
<beuno> pete-woods, the email bug is known and in progress, I'll figure out why it was left as rejected, and how to approve it while we fix and deploy it
<smoser> cjwatson, and that will work for 12.04 + ?
<smoser> then that is great.
<cjwatson> smoser: Yes.  Added in GRUB 1.98.
<smoser> gracias. and do you recommend me doing that in /etc/default/grub
<smoser> or in /etc/grub/default.d/file.conf
<cjwatson> smoser: s/conf/cfg/, but I'd recommend the latter.
<smoser> that is 12.04 also i think .right ?
<beuno> pete-woods, I approved it
<beuno> pete-woods, can you verify for me that the package you get on the phone is correct?
<beuno> I did something... "innovative" to get around this bug
<cjwatson> smoser: yes
<cjwatson> smoser: (I SRUed that)
<smoser> cjwatson, ok. last bother i promise. do you suggest updating GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub or putting that in default.d also
<xnox> argh I hate gnutls =) specifically old gnutls https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1373422
<ubottu> Launchpad bug 1373422 in gnutls26 (Ubuntu) "gnutls fails to connect to https://01.org in trusty" [Undecided,New]
<xnox> looks like gnutls26 decides not to trust if intermediate certificate is not trusted, or some such. Any idea as how to best resolve that issue?
<cjwatson> smoser: if you can keep /etc/default/grub pristine then that will cut down on swearing later
<xnox> given that mass upgrading trusty to gnutls28 by default is not an option.
<cjwatson> smoser: although for GRUB_CMDLINE_LINUX_DEFAULT I think the scripting is supposed to handle it ...
<cjwatson> it's rather fragile though, it's really the one bit of the grub2 packaging I haven't yet summoned the fortitude to understand in totality
<smoser> cjwatson, agreed. i've been through the swearing. and i figure i'll still have more at some point. but thank you for your advice.
<cjwatson> smoser: but d-i updates GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub directly so we have to deal with that in any case
<pete-woods> beuno: thanks, just going to have a look now
<pete-woods> beuno: okay, cool, that looks good :)
<beuno> pete-woods, sweet. We've found the bug (that check wasn't marked as a manual review step), we'll fix it and deploy tomorrow
<beuno> so it shouldn't happen again
<beuno> it won't get auto-approved as it requires a special permission
<beuno> and we haven't gotten to whitelisting permissions
<pete-woods> sure, that's fine, as long as it doesn't stop the manual moderators from overriding :)
<beuno> jdstrand, I'm going to mark that one as a manual review in the scripts  ^
<smoser> cjwatson, just fyi, this change is going to actually fix my issue with petiboot, i'm pretty sure.  i found about this because there was no /boot/grub/grub.cfg , and i'm pretty certain that petiboot was loading/parsing that file. so it did not know of my installation as that file wasn't getting created.
<cjwatson> smoser: that would certainly make sense
<juliank> Security people, please take a look at the privilege dropping in APT and tell us if you find any error; thank you: http://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc?h=debian/experimental#n2176
<juliank> That's inspired by tor's switch_id code, but only checks for errors.
<juliank> and does not log success
<juliank> We'll probably also put it in a seccomp sandbox for even more security
<juliank> (It = The methods fetching files)
<RoyK> how can I get bug 1364091 fixed? the solution is there...
<ubottu> bug 1364091 in mdadm (Ubuntu) "Possible RAID-6 corruption" [Undecided,Confirmed] https://launchpad.net/bugs/1364091
<kdeuser56> cjwatson: os-prober does not detect ubuntu installs that have a btrfs root file system
<kdeuser56> cjwatson: regardless if mounted or not
<cjwatson> kdeuser56: yes, that's a bug, just not one it looks like I'm going to have time to fix
<kdeuser56> cjwatson: remeber the bug number?
<cjwatson> no, sorry
<kdeuser56> cjwatson: maybe https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1294638 ?
<ubottu> Launchpad bug 1294638 in os-prober (Ubuntu) "os-prober does not detect ubuntu installations in btrfs subvolumes with EFI partitioning" [Undecided,Confirmed]
<cjwatson> I guess
<cjwatson> I'm doing about five other things
<kdeuser56> cjwatson: hm ... someone other with commit access and the skills to fix it?
<cjwatson> commit access doesn't matter, send patches
<kdeuser56> cjwatson: ok, one question though: did os-prober in ubuntu ever support detecting subvolumes on btrfs partitions?
<cjwatson> I'm sorry I don't remember right now
<kdeuser56> cjwatson: is there one common upstream for os-prober or does every distro develop their own?
<cjwatson> I don't have the attention available to think about this
<cjwatson> it's developed as part of the debian-installer project, in Debian
<cjwatson> that is the one common upstream
<kdeuser56> cjwatson: then I guess that fedora patch did never go upstream: https://bugzilla.redhat.com/attachment.cgi?id=676324&action=diff
<cjwatson> I don't know, did they send it?
<cjwatson> that's a fairly fearsomely large patch
<kdeuser56> cjwatson: it seems not ... they changed the output format of os-prober (common.sh)
<cjwatson> kdeuser56: looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688336
<ubottu> Debian bug 688336 in os-prober "update-grub finds only one system on btrfs volume" [Normal,Open]
<kdeuser56> cjwatson: ah thanks ... the patch is proposed there ... a shame no one integrated it :-(
<kdeuser56> cjwatson: ok thanks again ... it seems fedora is using the patch already for its last two major releases ... I'll download and test fedora, afterwards report back on the debian bug report, thanks!
<pete-woods> cjwatson: you're a distro-ish kinda person. so random question here. we noticed that the package libunity-core-6.0-9 is no-longer on the devel-proposed phone images, but it is on the RTM ones still
<pete-woods> cjwatson: it provides some icons that the scopes use
<pete-woods> so now it's gone, it means that some fallback icons (for albums with no art, for example) don't appear
<cjwatson> shouldn't you depend on it if you need it?
<pete-woods> do you know how I can find out why / where it went?
<pete-woods> well that's a fair point
<pete-woods> so we should install-depend on it, and it'll come back then, seems fair I guess
<cjwatson> although its ABI keeps changing of course; icons shouldn't be in an ABI-versioned package like that
<cjwatson> I don't know why it went away; I assume all its dependencies went away
<cjwatson> all the packages that depend on it, that is
<pete-woods> okay, just wanted to check it wasn't purged intentionally
<cjwatson> this sort of thing is not generally micromanaged, it's controlled by dependencies
<cjwatson> I can find out what happened if you really need it but it will take about half an hour to track it all down
<pete-woods> no, that's fine, just wanted to check it wasn't on someone's kill list
<cjwatson> doesn't work that way :)
<cjwatson> looks like it first disappeared in http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140920/ if that helps
<pete-woods> thanks for the info :)
<cjwatson> hm, no, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140919.1/
<cjwatson> pete-woods: actually, you know what, I got curious and that wasn't too hard to find.  It dropped out because of http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1276
<pete-woods> cjwatson: awesome, thanks. turns out that we only need a single icon from that package. so would seem a bit nuts to pull it in just for that. (so we'll probably leave it out)
<pete-woods> but again, thanks for the help!
<cjwatson> np
<infinity> pitti: Were those langpack uploads you?
<stgraber> pitti: I just posted my updated init scripts patch to the mailing-list now
<sarnold> pitti: thanks for tending to the retracers :)
<seb128> jibel, I reassigned #1371651 to jodh, that doesn't seem to be a lightdm issue but an upstart/plymouth/udev/... one, I don't think desktop is going to tackle it
<jibel> seb128, k
<seb128> hum, the session indicator is listing hibernate for me in utopic, is that a known issue?
<seb128> slangasek, pitti, whoever knows that stack, ^?
<seb128> didn't we disable that by default some cycles ago?
<slangasek> seb128: erm - I thought that was disabled at the level of the indicator itself
<slangasek> so... it was desktop team ;)
<seb128> slangasek, hum, I doubt we did
<seb128> that would be tedious, it would mean patching the indicator, gnome-session, unity, lightdm, etc
<slangasek> ok, I don't know then
<seb128> didn't we change the polkit rights on the logind/upower actions?
<seb128> http://ubuntuhandbook.org/index.php/2014/04/enable-hibernate-ubuntu-14-04/ suggests tweaking the polkit permissions to re-enable it
<slangasek> I don't know, I wasn't involved
<seb128> ok
<seb128> I guess that's one for pitti then
<seb128> slangasek, just for the record, http://launchpadlibrarian.net/83287567/policykit-desktop-privileges_0.7_0.8.diff.gz seems to be how it was done
<seb128> there is also a similar change on the logind interface
<slangasek> alright
<seb128> that file still has
<seb128> [Disable hibernate by default in logind]
<seb128> Identity=unix-user:*
<seb128> Action=org.freedesktop.login1.hibernate
<seb128> ResultActive=no
<seb128>  
<seb128> I wonder if systemd changed
<seb128> pitti, ^ I guess you are off for today, but a topic for tomorrow if you have some spare cycles to discuss that ;-)
<xnox> mdeslaur: you win! I owe you beverages of your choice next time you are in London =)
<xnox> mdeslaur: if I prepare gnutls update for trusty, would you take that into security pocket or updates only? given that it's effectively false negatives?
<xnox> mdeslaur: everything works as expected now, after flipping the certs around.
<xnox> bug #1371651
<ubottu> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
<cjwatson> hallyn: How do I get cgmanager to let go of a mount?  I have a stale half-created schroot session that I want to kill off, whose only reference appears to be in /proc/27583/mounts, where that pid is cgmanager
<hallyn> cjwatson: is that cgmanager one that was started inside the schrot?
<hallyn> cgmanager shouldn't have any references to anyone else's mounts...
<hallyn> just doing 'stop cgmanager' should be fine, cgmangaer doesn't keep any state
<cjwatson> hallyn: I don't think so, /proc/27583/root -> /
<cjwatson> but thanks, will try stopping it
<cjwatson> oh I should perhaps mention that pid 1 is currently systemd
<hallyn> cjwatson: /proc/pid/root always says it points to '/' :)
<hallyn> check under /proc/27583/root/proc to see if it's the same as /proc
<cjwatson> eh, no, /proc/pid/root can say other things if it's chrooted and you're looking at it from outside the chroot
<cjwatson> anyway, too late, "sudo systemctl restart cgmanager" has cleared it up
<hallyn> systemd version 208?
<cjwatson> yeah, utopic
<hallyn> hm
<hallyn> (i ask bc then at lesat systemd didn't make /sys/fs/cgroup ro)
<mdeslaur> xnox: oh, cool...with the patch, or you got the certs changed on the server?
<xnox> mdeslaur: certs ordering got changed on half the servers, so i'm still pondering about the patch. And I don't like the thing posted on the mailing list = the flags constants values are different from 3.x, off by one.
<sarnold> it'd be worth fixing the ordering, I understand firefox still enforces proper certificate order
<mdeslaur> sarnold: oh? I didn't think nss cared about cert order
<xnox> which is dangerous since 3.x DO_NOT_ALLOW_OUT_OF_ORDER, would become ALLOW_OUT_OF_ORDER, if one uses bitmasks/values instead of contants names.
<mdeslaur> xnox: I see
<xnox> and the tests have not been backported as part of that patch.
<mdeslaur> yeah, the patch probably needs work
<xnox> sarnold: we are only discussing bug in missconfigured servers vs old-gnutls. I can trivially test with curl compiled against each of the libraries. openssl passed, gnutls passes with 3.x, didn't test nss
<xnox> but i think it handles out of order certchains fine.
<sarnold> a friend was whinging two days ago about firefox and gnutls26 enforcing order and complained that "everyone else" (chrome, gnutls28, openssl) supported random ordering just fine...
<mdeslaur> sarnold: huh...firefox and chrome both use nss...I was definitely under the impression it was a gnutls26 only thing
<sarnold> mdeslaur: wonder why he was upset then :)
<mdeslaur> usually it's because of git :)
<sarnold> hahahaha
<xnox> it is git in my case
#ubuntu-devel 2014-09-25
<saiarcot895> Is there any chance that https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openwalnut/armhf-fixes/+merge/232879 will be merged in before Utopic is released?
<saiarcot895> or at least sponsored?
<dobey> saiarcot895: is it seeded in an image?
<saiarcot895> dobey: no
<saiarcot895> At least according to http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<dobey> saiarcot895: shouldn't be too difficult to gt it sponsored if you ping someone then. but final beta freeze is in effect, and beta release tomorrow, so i wouldn't expect too much before friday at least
<pitti> Good morning
<pitti> infinity: langpack uploads> from cron, yes
<pitti> sarnold: yw; the ddeb archive is fixed now
<pitti> stgraber: ah, great, thanks
<sarnold> pitti: yay :) thanks!
<infinity> pitti: Was slightly odd timing, that's why I asked. :)
<pitti> infinity: yeah, sorry; if they are inconvenient you can just reject them
<pitti> infinity: utopic uploads every wednesday
<infinity> pitti: Might make more sense in the future to ensure that devel series uploads happen on Fridays, to minimize possible clashes with milestones.
<pitti> wgrant: ^ I'm happy to swap RTM and Utopic, i. e. Wed and Fri; or Tue and Thu for the LP exports
<infinity> pitti: Not that it matters for utopic anymore, just in the future. :)
<infinity> pitti: For devel series' going forward.
<pitti> infinity: yeah, the final langpack should be a full -base update, and coordinated manually indeed
<dholbach> good morning
<thopre01> Laney: Thanks a lot for the sync
<dholbach> can you all please help out review the incoming sponsoring items? there's 94 of them right now.
<seb128> dholbach, I did some yesterday, I'm going to try to keep doing a few a day
<seb128> like 5 a day or something ;-)
 * dholbach hugs seb128
<dholbach> haha, yes, that'd be great :)
 * seb128 hugs dholbach back
<seb128> cjwatson, hey, do you have api documentation somewhere for libclick?
<chrisccoulson> hey seb128!
<seb128> chrisccoulson, hey, how are you?
<chrisccoulson> seb128, not bad thanks, and you?
<seb128> chrisccoulson, I'm good thanks ;-)
<cjwatson> seb128: just the gtk-doc-style comments in the source, though I'm not sure I've actually generated useful HTML out of them
<cjwatson> should sort that out - build system help welcome :)
<seb128> cjwatson, is using click_db_new/click_db_read/click_db_get_manifests_as_string the correct way to replace an exec "click list --all --manifest"?
<seb128> (seems to work fine)
<cjwatson> seb128: right, if you're just replacing a command then you can just read through click/commands/list.py and do the equivalent things
<cjwatson> seb128: that's indeed right, you might want to drop _as_string if you want structured output
<seb128> cjwatson, that code calls QJsonDocument::fromJson() on the output, seems to work fine like that
<cjwatson> ah, yeah, that's fine too
<seb128> I don't want to refactor the json/parsing code atm, just replace the call to click
<seb128> cjwatson, thanks :-)
<cjwatson> you get a few translations back and forward to json, but that has the effect of guaranteeing that it's valid json and normalising, so I don't think I'll "optimise" that
<seb128> yeah, I'm not concerned about performance
<seb128> the whole listing/parsing takes 100ms with the libclick version
<seb128> which is good enough for me
<cjwatson> that's probably ok, we can maybe look at profiling it at some point
<seb128> yeah, that's good enough for rtm though
<seb128> I'm sure we can do better, but let's do that after the important things are in place ;-)
<mvo> seb128: just curious, what app is that that will use it?
<seb128> mvo, ubuntu-system-settings, about->storage to list the installed clicks
<mvo> aha, nice
<seb128> we already do that
<seb128> but we use a system call to the click command
<seb128> replacing it by the lib
 * mvo nods
<cjwatson> I actually had a stale branch locally for that ages ago :-/
<cjwatson> can't remember what I got stuck on - I think I couldn't figure out how to test it
<seb128> cjwatson,
<seb128> gchar* click_db_get_manifests_as_string (ClickDB* self, gboolean all_versions, GError** error);
<seb128> what happen if all_versions is false? it lists only the current/most recent one?
<cjwatson> looks like I had http://paste.ubuntu.com/8424573/
<cjwatson>          * @all_versions: If true, return manifests for all versions, not
<cjwatson>          * just current ones.
<seb128> k
<cjwatson> if you're emulating click list --all --manifest then you want that as true
<seb128> yeah, I did
<seb128> but we have a bug about some items being duplicated so I was thinking about that
<seb128> but that needs input from design/mpt
<seb128> those are the pre-installed clicks
<seb128> they have their base image version and the store update listed
<seb128> but since they both use space that might be the right thing to do
<cjwatson> they do both use space, but the user can't do anything about the preinstalled ones
<seb128> right
<seb128> but that panel doesn't let you do anything anyway
<cjwatson> I mean they can "remove" (hide) them but they'll still take up space
<seb128> it just gives you info on what uses space
<seb128> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1325656
<ubottu> Launchpad bug 1325656 in Ubuntu UX "[System Settings] Preinstalled apps in the storage list" [Low,Triaged]
<seb128> that's the bug, waiting for design input
<cjwatson> there are a few things you could do; you could do something with the boolean _removable key, or the _directory key tells you the full path
<seb128> cjwatson, you diff looks similar to mine, except you did more and changed some of the json code ... I'm happy to test your version if you want
<cjwatson> I don't mind, didn't have time to do it properly, if you have something working then go ahead
<cjwatson> was just FYI
<cjwatson> if you're using _removable then note the comment in the docs
<cjwatson>  * _removable: 1 if a package is unpacked in a location from which it can be
<seb128> let me see if yours applies/work
<cjwatson>    removed, otherwise 0 (this may be changed to a proper boolean in future;
<cjwatson>    client code should be careful to permit either)
<seb128> ok, thanks
<cjwatson> there's some glib call that makes that natural
<seb128> cjwatson, http://paste.ubuntu.com/8424633/ is my diff which is working, I'm trying your in case, since you did a bit more work that would be a shame to see that wasted if it's working :-)
<cjwatson> well, ok, your call :)
<seb128> cjwatson, none of that applies without conflict :/
<cjwatson> I renamed a couple of files to avoid click.h clashing
<seb128> cjwatson, I'm going to land my change and keep your diff for inspiration if I want to look at the json changes later
<cjwatson> yeah, don't worry about it, it's probably not worth the time
<cjwatson> thanks
<seb128> thank you for the help!
<cjwatson> seb128: your patch looks fine except that you should g_object_unref the db when you're done (looks like I forgot that too)
<seb128> cjwatson, ok, good catch, thanks
<jamespage> barry, any chance I could persuade you to bump a new version of websocket-client (0.18) into Debian? I'd like to get that into 14.10 to support some updates into jujudeployer/jujuclient to suppport SSL
<dgadomski> hello everyone
<dgadomski> mlankhorst: hi, I try to solve bug 1104230 for trusty, I checked and the fix for it may be fairly easy to cherry pick for the utopic kernel
<ubottu> bug 1104230 in xserver-xorg-video-intel (Ubuntu) "DisplayPort 1.2 MST support is missing in the Intel driver" [Undecided,Confirmed] https://launchpad.net/bugs/1104230
<dgadomski> is the utopic kernel packaged for trusty anywhere?
<dgadomski> I was told that there were some *-lts-* backport packages, but I don't know any details
<dgadomski> mlankhorst: I would appreciate your help on this
<rbasak> dgadomski: the lts backport kernel package for Trusty will only arrive in trusty-updates in preparation for 14.04.2. That won't be for a while yet.
<rbasak> I'm not sure if there's another source to get a packaged Utopic kernel for Trusty though.
<dgadomski> rbasak: I see, thank you for info
<rbasak> dgadomski: you could see if https://wiki.ubuntu.com/Kernel/MainlineBuilds can help you.
<rbasak> That's not exactly the same as Utopic though.
<rbasak> Or for testing just try installing a Utopoic kernel .deb directly on Trusty.
<rbasak> (unless somebody says there's a reason that won't work)
<dgadomski> rbasak: thanks, I will try to get the fix to utopic first (since it will be also useful there) and then will work on finding a way to get it to trusty
<mlankhorst> the .deb should work
<mlankhorst> but if you have binary package the dkms drivers might now
<mlankhorst> not*
<barry> jamespage: sure.  will take a look today
<jamespage> barry, ++ thanks
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: rbasak
<mdeslaur> Riddell, ScottK: you've probably seen this already, but just in case: http://www.kde.org/info/security/advisory-20140923-1.txt
<Riddell> mdeslaur: hmm, I'm sure we had that problem last month
<Riddell> mm, a similar one 2014-08-03 krfb integer overflow
<mdeslaur> Riddell: was a different one I believe
<Riddell> I wonder why I didn't get notification of that issue
<Riddell> mdeslaur: anyway, will put on the todo list for today or tomorrow
<mdeslaur> Riddell: cool, thanks!
<barry> jamespage: websocket 0.18.0 pushed to sid.  when it lands there, it will require an ffe and a merge/sync (we have ubuntu deltas).  do you want to take care of that or should i?
<jamespage> barry, I can do that - its OK for a sync - the delta can go now
<jamespage> barry, thanks for that!
<barry> jamespage: \o/
<seb128> zul, hey, is https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1364854 still on your todolist? (it's in the sponsoring queue for a while, should sponsor be unsubscribed since you are assigned to it)
<ubottu> Launchpad bug 1364854 in keystone (Ubuntu) "python-ldap is needed as a dependency of keystone" [Undecided,New]
<zul> seb128:  it is
<seb128> zul, should I unsubscribe sponsors then?
<zul> seb128:  yes please
<seb128> zul, thanks
<slangasek> apw: so if jodh is right and 'plymouth-ready' is never emitted, that points to a problem earlier with plymouth itself failing to start
<apw> slangasek, and indeed plymouth is segv'ing which would be a fail
<apw> jodh, ^ we're over here
<apw> slangasek, so how can we capture that coredump, i assume we arn't rw yet
<ogra_> apw, into /dev
<apw> jodh, on my reproduce we the plymouth-upstart-bridge blows up about .5s before plymouth log wise
<ogra_> (thats always writable)
<apw> ogra_, point
<slangasek> not /dev, /run
<slangasek> :)
<ogra_> both work :)
<ogra_> but /dev is there all the time, do we have /run in initrd already ?
<infinity> ogra_: We do, yes.
<ogra_> ah
<infinity> mount -t tmpfs -o "noexec,nosuid,size=10%,mode=0755" tmpfs /run
<infinity> mkdir /run/initramfs
<infinity> # compatibility symlink for the pre-oneiric locations
<infinity> ln -s /run/initramfs /dev/.initramfs
<infinity> ^--- The last line being to appease people who are too laze to get with the new world order. :P
<ogra_> oh, right, i even remember these lines
<infinity> s/laze/lazy/
<infinity> (Not that it matters at all for a temporary hack)
<infinity> You could write your logs to /dev/bozo-the-clown for all I care.
<infinity> apw: Please write your logs to /dev/bozo-the-clown
<ogra_> ++
<infinity> (This is in no way a statement about your hair style)
<infinity> "Style".
<infinity> "Hair".
<ogra_> lol
<apw> i need a longer knee
<smoser> hey. can i get someone to move cloud-init from -proposed to trusty-updates ?
<smoser> bug 1353008
<ubottu> bug 1353008 in juju-core "MAAS Provider: LXC did not get DHCP address, stuck in "pending"" [High,Triaged] https://launchpad.net/bugs/1353008
<rbasak> If someone wants to sponsor emacs24 in bug 493766 it looks fine to me but I've just noticed it's in main so I can't upload it.
<ubottu> bug 493766 in emacs24 (Ubuntu) "Multi_key / compose does not work when XMODIFIERS="@im=SCIM"" [Undecided,Confirmed] https://launchpad.net/bugs/493766
<rbasak> (though a merge would be better)
<bdmurray> smoser: I'll have a look at cloud-init
<smoser> bdmurray, thank you.
<slangasek> cjwatson: is bug #1334189 something I should assign to you, or should someone else look at it?
<ubottu> bug 1334189 in gfxboot-theme-ubuntu (Ubuntu) "pre-boot menu offers no OEM mode on Utopic live images" [Critical,Confirmed] https://launchpad.net/bugs/1334189
<cjwatson> slangasek: I don't have a *problem* with somebody else looking at it, but I don't think anyone else has any experience at all with the twisty pile of code involved
<slangasek> ok
<cjwatson> (which, I suppose, isn't a good reason not to assign somebody else to it to learn; just budget a few extra days ...)
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<bdmurray> mitya57: where is the verification for bug 1370443?
<ubottu> bug 1370443 in retext (Ubuntu Trusty) "Crash after enabling line numbers" [High,Fix committed] https://launchpad.net/bugs/1370443
<Riddell> mdeslaur: bug 1374043 for your review and upload
<ubottu> bug 1374043 in krfb (Ubuntu Utopic) "vulnerabilities in libvncserver" [Undecided,New] https://launchpad.net/bugs/1374043
<mdeslaur> Riddell: thanks
<bdmurray> seb128: could you have a look at the verification of bug 1353951? one person says it works another says they have an issueâ¦
<ubottu> bug 1353951 in evolution-data-server (Ubuntu Trusty) "gnome online accounts require autentication on startup" [Undecided,Fix committed] https://launchpad.net/bugs/1353951
<bdmurray> arges: bug 1174098 is missing SRU information
<ubottu> bug 1174098 in util-linux (Ubuntu Trusty) "blockdev doesn't work as reported with loop devices" [Medium,In progress] https://launchpad.net/bugs/1174098
<arges> bdmurray: i'll update
<bdmurray> arges: okay, let me know when its good to go
<arges> bdmurray: ok updated
<nadrimajstor> Why LP keeps eating white space when I copy&paste snippet of patch file in to the comments?
<sarnold> probably some "HTML doesn't care about whitespace" thing; everyone's used to it, though, so just paste away and be sure to include the patch as an attachment if you intend someone else to apply it as-is
<warptrosse> [B[Bexit
<pataq> Sorry but where is the 14.10 final beta? i thought i was supposed to be released yesterday
<nadrimajstor> sarnold: A bit annoying... It is snippet of .py to make matters worse... and it strips only lines that begins with `+` :|
<sarnold> nadrimajstor: hehe yeah I've had that happen to python snippets before too. not fantastic :) but you can still document what you mean that way..
 * nadrimajstor will provide patch as a attachment and appropriately changed bash line for applying patch.
 * nadrimajstor popey just loves my rants about LP :D
<nadrimajstor> Goodnight everyone o/
#ubuntu-devel 2014-09-26
<Noskcaj> Should brasero's tracker support be re-added now tracker's in main?
* infinity 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> bdmurray: first, I tested it myself; second, upstream reporter tested 5.0 and said that it worked there.
<mitya57> (the patch for 4.1 is a minimal version of a patch for 5.0)
<Mirv> mlankhorst: cjwatson: bzoltan: Re: qtcreator-plugin-ubuntu autopkgtest GLX error. I see a similar error in the unit tests of Qt. The previous successful build was on Wednesday, before the Mesa 10.3 upload.
<Mirv> the autopkg test error is at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-qtcreator-plugin-ubuntu/lastBuild/ARCH=amd64,label=adt/console
<Mirv> and the Qt error at https://launchpadlibrarian.net/185821388/buildlog_ubuntu-utopic-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu8~utopic1~test1_FAILEDTOBUILD.txt.gz
<Mirv> filed bug #1374355 about it
<ubottu> bug 1374355 in mesa (Ubuntu) "GLX error with the new Mesa 10.3" [Undecided,New] https://launchpad.net/bugs/1374355
<Mirv> /me notices bug #1374131 already filed earlier
<ubottu> bug 1374131 in mesa (Ubuntu) "qtcreator-plugin autopkg test fails on AMD64 mesa mesa_10.3.0" [Critical,New] https://launchpad.net/bugs/1374131
<brainwash> grub-common installs /etc/init.d/grub-common (Record successful boot for GRUB), but no systemd service file yet. should I file a report and request it?
<cjwatson> brainwash: if you can work out how to express it in systemd sure
<cjwatson> it's an "as late as possible after pretty much everything else has started" kind of thing, which is tricky to express
<cjwatson> brainwash: file it in Debian though please
<infinity> mlankhorst: I know you don't work on Fridays, but put on a community hat and pretend it's not work, you have some people to answer to for that mesa upload. :P
<kgunn> mlankhorst: hey any chance you could help us out ?
<lool> cjwatson: hey, latest mesa upload in utopic-proposed (FFE bug #1364003) breaks other packages; should we revert this with an upload of the previous version to unblock them?
<ubottu> bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,Fix committed] https://launchpad.net/bugs/1364003
<lool> cjwatson: seem mlankhorst isn't around today to debug the issue
<lool> kgunn: did someone reproduce the issue outside of the testbed? do we have any details about it? (only thing in jenkins log is Could not initialize GLX)
<kgunn> lool: nope, i couldn't find anyone to help, altho... Mirv might have ? i see he added a comment that it was effecting another package
<Mirv> kgunn: there's a duplicate bug report now attached to yours, showing how qtbase also now fails to build (or actually, fails running a certain unit test) similarly
<kgunn> lool: so there you go ^
<lool> kgunn: that's still the same symptom though
<cjwatson> lool: sorry swamped
<cjwatson> lool: oh I don't see why you need to reupload though
<cjwatson> lool: it's only in -proposed, we could remove it
<lool> cjwatson: ok, let's do that then
<lool> I'll reopen the FFE
<cjwatson> lool: BUT
<lool> there's always a butt
<cjwatson> lool: can you check that nothing else in -proposed depends on the updated version?
<cjwatson> lool: you don't need to reopen the ffe, it's only fix-committed
<cjwatson> that's not a closed state
<lool> I'll check
<caribou> Laney: stgraber: xnox: any easy way to find out if my upload rights have been granted ?
<caribou> i.e. similar than https://ftp-master.debian.org/dm.txt
<lool> cjwatson: I've searched for 10.3.0 versioned deps or build-deps in utopic-proposed {main,universe} for amd64/source and didn't find any; there was a mention in the FFE that this mesa upload would allow demoting llvm, but that has not been uploaded yet afaics
<rbasak> caribou: there's a command called "ubuntu-upload-permission" in ubuntu-dev-tools.
<caribou> rbasak: tks, will check that out
<netforyou1337> Anybody know how i can change the System Details? For example: MyName OS
<netforyou1337> Anybody know how i can change the System Details in Settings? For example: MyName OS
<cjwatson> lool,mlankhorst: removed with a reference to bug 1374131
<ubottu> bug 1374131 in mesa (Ubuntu) "qtcreator-plugin autopkgtest fails on AMD64 mesa mesa_10.3.0" [Critical,Confirmed] https://launchpad.net/bugs/1374131
<lool> cjwatson: thanks
<lool> kgunn: ^
<lool> kgunn: do you know how to retrigger the apt?
<cjwatson> will retry the autopkgtests in a bit; remind me when mesa/utopic-proposed vanishes from rmadison
<lool> ah thanks
<cjwatson> lool: you can't yet
<cjwatson> they're still in the published archive
<lool> I didn't know whetehr I had permission at all
<cjwatson> I have no idea
<lool> will ping you when it's really gone
<cjwatson> you should have, I think core-devs do, but it can be a bit non-obvious to find because HI JENKINS THANKS A BUNCH
<netforyou1337> Anybody know how i can change the System Details? For example: MyName OS
<zul> pitti:  ping
<LocutusOfBorg1> can libjpeg-turbo be synced from debian?
<LocutusOfBorg1> or we are just too late?
<Laney> caribou: lp:ubuntu-archive-tools edit-acl -p launcpad-id -S utopic query
<caribou> Laney: ubuntu-upload-permission did answer my query : my PPU access rights have not been implemented yet
<Laney> oh, I'm not aware of that script
<Laney> stgraber: ^ could you grant them please?
<caribou> Laney: in ubuntu-dev-scripts as rbasak said
<Laney> cool
<caribou> I didn't know about it either
<sil2100> mitya57: hey! Thanks for driving the appmenu-qt5 landing ;)!
<lool> cjwatson: mesa is gone from rmadison, mind kicking autopkgtests again?
<lool> cjwatson: qtcreator-plugin-ubuntu woudl be one, not sure which others
<cjwatson> lool: qtcreator-plugin-ubuntu done
<stgraber> caribou, Laney: add the ACLs and added you to ~ubuntu-dev
<Laney> ty
<caribou> stgraber: thanks
<bdmurray> mitya57: it wasn't clear to me the upstream reporter tested the version in trusty-proposed
<Riddell> mvo: how about changing the bash-completion to say use apt rather than apt-get ?
<mvo> hey Riddell, yes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747094
<ubottu> Debian bug 747094 in bash-completion "bash-completion: [patch] add support for the new "apt" command" [Wishlist,Open]
<mvo> Riddell: open since 5 may :(
<Riddell> mvo: one little delta from debian won't hurt will it? :)
<rbasak> "Ubuntu gets apt ahead of Debian"
<mvo> Riddell: heh :) I think I will just include it in apt directly and we both get it
<mvo> Riddell: my co-maintainer complained that it does not belong into apt directly but given the state of maintenance of bash-completion I think he is wrong :)
<ogra_> rbasak, nah, not clickbaity enough ... "Ubuntu gets new apt, leaving debian behind in desparation !!!11!"
<jdstrand> hallyn: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1373555/+attachment/4216305/+files/lxc_1.1.0%7Ealpha1-0ubuntu5.debdiff
<ubottu> Launchpad bug 1373555 in lxc (Ubuntu) "please restrict signal, ptrace and unix mediation to the container" [High,Triaged]
<mitya57> sil2100: actually, it was Mirv â thank him :)
<jdstrand> hallyn: I built it locally and did my local tests
<jdstrand> hallyn: I'm happy to upload it if you are
<mitya57> bdmurray: he tested 5.0, I tested the version in -proposed, isn't that enough?
<bdmurray> mitya57: in the bug you don't mention that you yourself tested it with the version of the package in -propsed. The upstream reporter didn't test the version of the package in -proposed so that isn't enough.
<T0rch> hello guys
<T0rch> im having a bad day ...
<T0rch> bash version 4.3-9ubuntu3
<T0rch> env ls='() { echo vulnerable; }' bash -c ls
<T0rch> and the result is that im still vulnerable ...
<T0rch> http://seclists.org/oss-sec/2014/q3/741
<mdeslaur> T0rch: that's perfectly normal
<hallyn> jdstrand: looks good, thanks
<hallyn> (that is, please go ahead and upload :)
<jdstrand> hallyn: cool, thanks
<cjwatson> the link above is AFAICS wrong about setuid/setgid scripts, since bash doesn't import functions from the environment in that case
<cjwatson> (though I'd be all for killing the stupidity that is imported functions altogether, e.g. https://lists.debian.org/debian-devel/2014/09/msg00784.html - it just involves rather more work sadly)
<T0rch> ok, so i understand now that im safe
<T0rch> thanks you!
<cjwatson> though scripts called by set-id scripts might have a problem, I'm not sure
<cjwatson> so I don't know that I'd say "safe", but no more vulnerable than anyone else at the moment :-/
<T0rch> yeah, at least from the other two we are now!
<T0rch> i have to say im very happy with the packages from the last branch (utopic). im trying to learn more and trying to get more involved in the future!
<T0rch> Thank you for all the support!
<mdeslaur> cjwatson: yes, I'm waiting to see what upstream bash says about the imported functions before making a decision or possibly using red hat's patch
<hallyn> rharper: stgraber: infinity:  https://wiki.ubuntu.com/QemuPTMigration  This is the summary of what I'm about to create FFE bugs for.
<rharper> reading
<cjwatson> mdeslaur: is that the one that goes to BASH_FUNC_foo() ?
<mdeslaur> cjwatson: yeah
<rharper> hallyn: when we talk about using migrating from P -> T  and then T -> U;  are we expecting the pc-1.0-precise to also work on U (via the P -> T -> U) ?  or would we require users to migrate P -> T, switch machine type from pc-1.0-precise to pc-i440fx-trusty, to migrate from T -> U ?
<rharper> for some reason, I feel we need to discuss the EOL for the machine type (pc-1.0-precise) ...
<rharper> ie, when will we no longer accept/support that machine type
<rharper> and at that point, the solutuion is to "upgrade" the machine by updating the machine type used (and dealing with any issues that arise from that transition, like re-registering windows, as needed)
<ChrisTownsend> hallyn: Hi, I'm having some issue creating a cgroup in a container and stgraber said you might be able to help.  Are you available to discuss and is this a good channel?
<hallyn> rharper: I'm happy to discuss EOL for machine types, makes our lives easier.  Until we do so, I was imply assuming we'd have to carry that machine type forward.  So U would know about pc-1.0-precise.
<hallyn> I think it's reasonable to say that when precise goes EOL, pc-1.0-precise goes EOL
<rharper> yeah, I realized that P will be around while U is here
<rharper> hallyn: agreed
<hallyn> right, and even 16.04.  But at lesat we coudl drop it at 17.04
<rharper> yeah
<hallyn> rharper: how abvout we mention this at the next server irc meeting?
<rharper> I think that's a good idea
<rharper> now, if ppa testing goes well, are we going to push that qemu into P T and U ?
<hallyn> I'll add it to the agenda
<hallyn> yeah.
<hallyn> If we get FFEs in time, we could push into U without an SRU :)
<hallyn> ChrisTownsend: sure, here's good.  (or #ubuntu-server)  what's going on?
<rharper> cool
<ChrisTownsend> hallyn: So I have a container where I'm trying to create a cgroup.   This is a Trusty host and Utopic in the container.  Here is a pastebin of some relevant info: http://pastebin.ubuntu.com/8434980/
<ChrisTownsend> hallyn: So I'm not sure why I'm getting that error and we thought you might have a clue.
<hallyn> ChrisTownsend: just to be sure...  try 'sudo cgm create all x1'
<ChrisTownsend> hallyn: A little back story is that we are trying to get a Unity8 desktop session working in the container which works for the most part.  However, a recent change to how apps are started in Unity8 use the cgroup freezer directive in the upstart script.
<ChrisTownsend> hallyn: Ok, I'll try that.
<ChrisTownsend> hallyn: Same error
<hallyn> lxc/unity8-lxc
<hallyn> gr
<hallyn> ChrisTownsend: it looks like you have the same block of lxc.mount.entry's twice in the container config?
<hallyn> in fact the whole config seems duplicated.  can you cull it down?
<hallyn> i don't think that should be messing with cgmanager, but who knows
<hallyn> ChrisTownsend: then, when that still fails, can you pastebin ls -l /sys/fs/cgroup both in container and on host
<ChrisTownsend> hallyn: Umm, not sure why that looks like that.  It's not supposed to any ways.
<ChrisTownsend> hallyn: I'll fix that up.
<hallyn> ChrisTownsend: given that you're not even doing any id mappings, i can't imagine what's actually going wrong
<ChrisTownsend> hallyn: Oh, I think I hit paste twice accidentally in the pastebin.
<ChrisTownsend> hallyn: http://pastebin.ubuntu.com/8435028/
<hallyn> ok liemme fire up a digitalocean instance to try to reproduce under
<ChrisTownsend> hallyn: Ok
<hallyn> the utopic container is just straight-up utopic, no systemd pid 1 or anything funky?
<ChrisTownsend> hallyn: It's pretty much straight up utopic.  It's the Unity 8 desktop preview ISO that has been unpacked.
<ChrisTownsend> hallyn: http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/
<mlankhorst> cjwatson: if it mentions qxl i bet it's a stupid configuration issue or something :/
<dupondje> Any chance nouveau & hdmi gets fixed before final?
<hallyn> ChrisTownsend: ok, I guess cgmanager on trusty is older than i'd throught.  it doesn't support 'all'.
<hallyn> so you need to create for each controller separately.
<hallyn> not sure if i could get that feature in through an SRU, as not having that for the next 4.5 years of support is gonna hurt
<hallyn> cgm could gain code to check the apiversoin and do 'all' by hand if need be, but that's added complexity and doesn't help all the other places we have to do that (lxc, libvirt, logind, etc)
<hallyn> i suppose cgproxy could do it.
<hallyn> that feels potentially fragile...  but better than doing it in al the clients
<hallyn> i'm already gonna be owing some libations to release team over the various qemu migratoin ffe's going by, not sure i can swing cgmanager too :)
<hallyn> ChrisTownsend: so something lie:
<hallyn> awk -F: '{ print $2 }' /proc/self/cgroup | while read line; do sudo cgm create $line c2; done
<ChrisTownsend> hallyn: Ok, I'll try that.  Sorry if I'm a little laggy in response.  I'm having to help take care of a sick toddler.
<ChrisTownsend> hallyn: That seems to work.
<ChrisTownsend> hallyn: Yeah, seems not having 'all' is going to hurt on Trusty.
<ChrisTownsend> hallyn: I can probably take your awk script there and modify to suit my needs.
<ChrisTownsend> hallyn: Thanks for your help.
<hallyn> ChrisTownsend: cool.  Well I think I'll do the next upstream cgmanager release and then see waht i can do about upping the trusty version
<hallyn> I htink there's an argument to be made that we have hgue amounts of testing of recent stuff, wehereas supporting newer features with older cgmanager is going to only expose more breakages like this
<hallyn> (plus, afte rthe next release, it's "feature complete" in my book :)
<hallyn> rharper: filed bugs 1374612, 1374617, 1374622
<ubottu> bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,New] https://launchpad.net/bugs/1374617
<ubottu> bug 1374622 in libvirt (Ubuntu Trusty) "Support migration from 12.04" [High,New] https://launchpad.net/bugs/1374622
<ubottu> bug 1374612 in qemu (Ubuntu Trusty) "[FFE] add pc-1.0-precise machine type" [High,New] https://launchpad.net/bugs/1374612
<rharper> hallyn: nice!
<sl1rpy> im bored... does anyone need help with something?
<Noskcaj> sl1rpy, What do you want to do? What can you do?
<sl1rpy> well im fairly new with C++ and I want to learn how to make GTK applications but i couldn't find a decent book on it.
<sl1rpy> im better with Java / C#
<Noskcaj> sl1rpy, A good way to start (since you have programming skills) is find and fixing a bug in an app you use
<Noskcaj> bugs.launchpad.net/ubuntu and bugs.debian.org would have a few
<Noskcaj> What desktop do you use?
<sl1rpy> unity
<Noskcaj> I'm not fully sure where to start with it. I'm sure some of it's devs are around if you want to work on it
<Noskcaj> But find a bug that you think you can fix, then i'll walk you through getting the fix into ubuntu (I can't code properly, but have done a lot a packaging)
<sl1rpy> Noskcaj, someone pointed out i could work on bugs but most of the stuff is beyond me.
<dobey> if you want to hack on unity, #ubuntu-unity is where to look at
<Noskcaj> ok. Unfortunately, most of our work is bugfixes for the next month or two
<dobey> sl1rpy: why do you want to write gtk+ apps in c++?
<dobey> it's not the best language for writing gtk+ apps really
<sl1rpy> dobey, really?  what is? C?
<dobey> Vala is probably the best language for it, depending on what you want to build
<dobey> if you want to build apps for Ubuntu, the best thing to use is probably c++/qt and the ubuntu sdk stuff
<dobey> to build apps that work on phone, tablet, pc, or TVs
<dobey> #ubuntu-app-dev might be a good channel for you to hang out in, if you want to write new apps (i think that's the channel name)
#ubuntu-devel 2014-09-27
<dypsilon_> Hi everyone, I want to create a scriptable installation for virtualbox which starts with something absolutely minimal like "ubuntu minimal cd" and proceeds to download packages (scripted) from the net. Could you point me in the right direction?
<sarnold> slangasek,cjwatson,infinity: I've seen a surprising number of instances of 1363519 -- bad debsums on start-stop-daemon -- alongside other, probably unrelated, bug reports -- I'm afraid this may be a symptom of a larger problem and wanted to make sure it doesn't get overlooked by accident. Since it feels like magic it seems like one for you guys :) thanks
<jamin> what's the best way to call attention to a security bug report that you've filed on launchpad but isn't getting any response?
<infinity> sarnold: Wow, that makes a whole lot of no sense.
<sarnold> jamin: which bug?
<sarnold> infinity: heh, thanks for making me feel better
<infinity> sarnold: I can't even fathom how that would happen.
<sarnold> infinity: me neither. but I know I've seen that modified: sbin/start-stop-daemon from more than those two bug reports..
<infinity> sarnold: All on trusty?
<sarnold> infinity: I think so but I didn't keep track :(
<infinity> sarnold: I wonder if there's some other misbehaving package copying around s-s-d binaries.
<infinity> sarnold: If the claim is that installing a fresh xubuntu and then upgrading causes the issue, it should be debuggable, just... Weird
<infinity> Don't see any obvious maintainer script weirdness here, so I guess the only option is to try to reproduce from scratch. :/
<sarnold> :(
<sarnold> infinity: is there an easy way to grep through all the Dependencies.txt on launchpad to look for the [modified: ] bit? it might be possible to find a few more instances and see if there's any hints
<infinity> sarnold: Some lpapi guru might be able to help you, that wouldn't be me.
<infinity> sarnold: I feel like bdmurray would know if it could be done.
<sarnold> infinity: cool, thanks.
<bdmurray> sarnold: I have a local cache of bug attachments for all the foundations packages, that I could easily search. If we did find a fair number then we could move onto searching Launchpad using the API.
<saiarcot895> Anyone active today willing to review a sponsorhip request? https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openwalnut/armhf-fixes/+merge/232879
<saiarcot895> *sponsorship
<tomi__> Anybody know how i can change the System Name in Systemsettings -> Details ? For Example: MyName OS
<tomi__> Anybody know how i can change the System Name in Systemsettings -> Details ? For Example: MyName OS
#ubuntu-devel 2014-09-28
<mitya57> bdmurray: Pasted a verbose testing log (of myself) to bug 1370443
<ubottu> bug 1370443 in retext (Ubuntu Trusty) "Crash after enabling line numbers" [High,Fix committed] https://launchpad.net/bugs/1370443
<ari-tczew> The package khronos-opencl-headers can't be synced. Could some admin check this one?
<TenLeftFingers_> Is this the right Ubuntu tutorial for making my own application caterogy in the Unity Applications view in the dash? http://developer.ubuntu.com/scopes/tutorials/scope-development-procedures/
<TenLeftFingers_> I want to make a "Commodore" section for the games that run on Vice that will be seperate from other games.
#ubuntu-devel 2015-09-21
<mwhudson> what is the expected time between verification being done on an sru bug and it hitting -updates?
<mwhudson> it's only been 3-4 days for the ones i care about but i want to calibrate my expectations :-)
<stgraber> mwhudson: it's usually at least 7 days after the package was accepted in -proposed
<mwhudson> stgraber: ah ok
<mwhudson> i had a memory of something like that but i couldn't find it written down anywhere
<pitti> Good morning
<pitti> infinity: yeah, it was on Friday; we are still missing lcy01, and I had about 500 kernel tests queued up
<pitti> infinity: it seems ppc64el has a problem (lots of in progress), looking
<pitti> infinity: nodejs built everywhere and all of its tests pass (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nodejs)
<pitti> infinity: ok to remove block-proposed, or do you want to do some manual testing too?
<seb128> cyphermox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1482851 ?
<ubottu> Launchpad bug 1482851 in os-prober (Ubuntu) "Windows 10 is detected as Windows 8" [Medium,Triaged]
<cjwatson> pitti: Could you please chase webops about that (lcy01)?  https://rt.admin.canonical.com/Ticket/Display.html?id=84603 has been resolved since Thursday, so if your stuff still doesn't have access to it then that shouldn't be very hard to fix now.
<pitti> cjwatson: oh, I will, thanks
<pitti> cjwatson: webops> that's filing an RT? or the IS IRC channeL?
<cjwatson> pitti: I was thinking #webops, but indeed you'll probably want to file an RT
<pitti> cjwatson: /me files, thanks
<pitti> cjwatson: btw, all bos* builders having this "permission denied (public key)" / Cleaning error is known?
<cjwatson> wgrant: ^-
<cjwatson> pitti: Oh, I think IS are just in the middle of moving that over to a different firewall
<cjwatson> wgrant: ignore
<cjwatson> pitti: happier now
<pitti> yay
<Odd_Bloke> cjwatson: Did you have a chance to play with that build I pasted to you on Friday?
<cjwatson> Odd_Bloke: Oh, not yet, let me finish up my current branch and then try that.
<Odd_Bloke> cjwatson: Cheers. :)
<cjwatson> Odd_Bloke: Sigh, I need to bite the bullet and set up a VM buildd rather than relying on lxc
<Odd_Bloke> cjwatson: :(
<pitti> stgraber: FYI, i386 regression on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lxd
<pitti> stgraber: I tried to run this locally in a VM, but there it doesn't even succeed on amd64 (http://paste.ubuntu.com/12514056/)
<pitti> PSA: I need to take down and rebuild autopkgtest.ubuntu.com (just the debci web UI, not the machiner)
<pitti> machinery
<ogra_> woah ...
<stgraber> pitti: I saw that failure but it confused me a bit, the testsuite never succeeded on i386 (except locally where it passes fine) and the web UI wasn't showing me the actual failure for 0.18-0ubuntu2
 * ogra_ just accidentially typed "ssh cdimage" instead of "ssh nusakan" ... and i noticed that the cdimage entry in my known_hosts not only predates nusakan but also encryption of known_hosts entries 
 * ogra_ feels old
<pitti> stgraber: yeah, that's the reason why I had to rebuild autopkgtest.u.c., it ran out of space
<seb128> cyphermox, hey, did you see my os-propber ping earlier?
<cyphermox> seb128: I did, I just committed this in Debian
<cyphermox> I'm about to apply the changes here now
<cyphermox> just doing a few things at a time :)
<seb128> cyphermox, that's ok, you didn't pong so I was unsure, thanks!
<cyphermox> yeah, sorry :)
 * pitti needs to run, cu tomorrow
<Saviq> pitti, hey, if I wanted to test adt-run on packages as built in a silo/PPA, is something like the following correct?
<Saviq> adt-run --no-built-binaries --binary *.deb --source unity8_*.dsc --- schroot wily-amd64-shm
<Saviq> it does complain about broken deps :/
<tdaitx> infinity, pitti, bdmurray squid3 depends on libecap2, but the build fails because libecap2 is using the old gcc abi while squid3 current build is using the new one, I can get squid3 to build with -D_GLIBCXX_USE_CXX11_ABI=0 but I'm not sure if that is the right approach
<rbasak> tdaitx: thank you for looking at it and sorry for the mess, I intended to merge squid3 before feature freeze but ran out of time. Let me know if I can help with anything. I'm not sure of the answer to that question.
<rbasak> I wonder if we should migrate libecap2 to the new ABI?
<rbasak> IIRC the only libecap2 consumer is squid3.
<tdaitx> rbasak, you are right, reverse-depends (-b) list only squid3 as a dependency, so rebuilding it should work
<tdaitx> rbasak, are you able to trigger a rebuild?
<tdaitx> rbasak, and thanks, I was wondering why we were still at 3.3.8 while debian is at 3.5.7 =)
<tdaitx> anyway, I have been able to fix squid3 FTBFS locally
<sil2100> cjwatson: I'll be doing a bzr pull of my latest changes to cdimage on nusakan - in case it breaks something, feel free to revert ;)
<infinity> rbasak: I wouldn't be against you merging squid3 to be up to date with Debian, if we can test it in any reasonable way.
<infinity> rbasak: We're behind by years.
<cjwatson> sil2100: jfdi, I expect it's just your change
<cjwatson> sil2100: I normally pull immediately
<rbasak> infinity: the merge will take me at least a day, maybe two, to clean it all up. I think that by the time I get round to it we'll be too close to release :(
<seb128> cyphermox, is there any chance you could review https://code.launchpad.net/~binli/ubuntu/wily/modemmanager/lp1441095/+merge/271088 ?
<rbasak> tdaitx: I can upload a no-change rebuild, but I'd prefer to have an uploader more familiar with the GCC 5 ABI transition ack it first since I'm not sure I fully understand the consequences.
<infinity> rbasak: Well, we definitely should get caught up for 16.04, if you'd rather merge first thing in 16.04, that's fine too, but merging now would get rid of that one old library.
<cyphermox> seb128: yes, it's on my list for today
<seb128> cyphermox, excellent, thanks ;-)
<hallyn> pitti: do you have a candidate pkg source for systemd 226 for ubuntu?  should i just use the debian pkg verbatim?
<tdaitx> rbasak, oh, btw, I said libecap2 only required a rebuild, but since a few symbols will change, debian/libecap2.symbols does require a few changes
<tdaitx> infinity, if we rebuild libecap2 and that changes the symbols, would we need to update its version as well? (libecap3, which, btw, is already being used by ecap 1.0)
<infinity> tdaitx: It would need the package name changed, per the C++ transition.
<tdaitx> infinity, thought so... alright, is it ok to build squid3 with -D_GLIBCXX_USE_CXX11_ABI=0 then? at least until we get the merge in?
<infinity> tdaitx: Does it link to any other C++ libraries?
<infinity> tdaitx: Links to libicuuc.so.55, that looks C++ish as well, and I assume has transitioned.
<infinity> tdaitx: So you'd be mixing ABIs.
<infinity> tdaitx: Well, except that ICU probably didn't actually change.  Most libraries didn't.
<infinity> tdaitx: Anyhow, if libecap *does* change on rebuild, it should be transitioned, IMO.
<infinity> tdaitx: Cause a security update would cause a post-release explosion.
<tdaitx> ouch, indeed
<Laney> xnox: I'm going to upload what we have there, can tweak later on
<infinity> tdaitx: When you speak of libecap3, is that only in Debian?
<tdaitx> it seems to be better to get the squid3 merge in and avoid all that
<tdaitx> infinity, no, it is in wily-proposed as well
<infinity> tdaitx: Oh. So.  From the same source package.  That *completely* changes this conversation.
<infinity> tdaitx: Because we're also talking about removing libecap from proposed, and any rdeps (does it have any?)
<infinity> Oh, it really is *just* squid. :P
<infinity> tdaitx: So, either remove libecap from proposed and rename/transition libecap2.  Or work with rbasak to get a merged squid in and give it a bit of testing.
<infinity> tdaitx: I'm really more in favour of the latter, but either workd.
<infinity> s/workd/works/
<tdaitx> right, I also believe getting squid up to date is better
<infinity> tdaitx: Well, and I assume this is why libecap2 never transitioned, because the new version is already "transitioned".
<rbasak> tdaitx: I have some pieces of a merge from a previous merging tutorial I can use. Let me take a look tomorrow.
<tdaitx> rbasak, would you mind if I give that merge a try?
<infinity> Willing to bet most of our delta goes away on a merge anyway.
<infinity> Security updates, etc.
<rbasak> tdaitx: IIRC it's a complex and messy merge, with tons of delta that needs rationalising and IIRC quite a bit of it needs modifying or dropping. I think quite a bit of it needs to remain, too. I've already done half the work.
<rbasak> tdaitx: I use http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html
<tdaitx> rbasak, in that case, keep up the good work =)
<rbasak> tdaitx: you can take it if you really want it, but it'd be duplicating some effort I think.
<tdaitx> yeah, agreed
<rbasak> tdaitx: OK. OTOH if I don't get to it tomorrow then I don't want to block anyone.
<tdaitx> rbasak, don't worry about that, if we can't get a newer squid in, then we only have to transition the current libecap2 and apply a few patches to the current squid3 source package
<tdaitx> rbasak, and thanks for that link ;-)
<ScottK> FYI, it looks like Ben needs a kick since there's several listings in http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4-5.html that are long out of date.
<hjd> How does virtual packages work, or rather, how are they created? libjpeg9 fails to build (https://launchpadlibrarian.net/217954976/buildlog_ubuntu-wily-amd64.libjpeg9_1%3A9a-2_BUILDING.txt.gz) because it is missing automake-1.14. This seems to be a virtual package which is in Debian (https://packages.debian.org/unstable/automake-1.14), but I can't find a trace of it in Ubuntu...
<sarnold> hjd: it does look like it exists... https://launchpad.net/ubuntu/+source/automake-1.14
<hjd> When I try to look up the package name I find http://packages.ubuntu.com/wily/automake, which is built from automake-1.15, but has the same binary package name. Perhaps that is confusing it somehow?
<xclaesse> mardy, signond not giving token to apps happens again
<xclaesse> mardy, sending you syslog in mp (redacted tokens, but in case it still contains something sensing better not post in public chan)
<xclaesse> mardy, what I see the first time evo asks for the token signond says "Stored token is expired", then all subsequent retries it says "One request is already active"
<xclaesse> mardy, if I kill signond it works again
<xclaesse> mardy, my understanding is that it tries to refresh the token, for some reason that operation never completes, then it's stuck forever waiting for that operation to finish before giving a token to any app
<TJ-> hjd it looks like the source claims to be in 'universe' but the copy-from-Utopic applies to 'main' (the .debs are in pool/main/ too)
<pitti> Saviq: this looks ok in principle, but you should add a -B before the dsc, otherwise it'll build the .dsc again
<Saviq> pitti, --no-built-binaries is there
<pitti> Saviq: does wily satisfy all of its dependencies?
<Saviq> pitti, no, the --binaries do
<pitti> Saviq: perhaps you rather want to add the PPA?
<pitti> hallyn: yes, you can use https://launchpad.net/~pitti/+archive/ubuntu/systemd
<Saviq> pitti, that's what I was thinking if I fail to run from dir, just add the PPA to the chroot and run as if it worked from the archive
<pitti> hallyn: this contains the output of the "trunk CI" builds, I regularly run them and they get uploaded if they pass all tests
<Saviq> pitti, but thought it's possible to do locally
<pitti> hallyn: you can poke me if you want/need a new trunk build; it's just calling a single script, but I need to remember doing it often enough
<pitti> Saviq: yes, I often run it like that (adt-run *.deb -B foo.dsc), works fine in general; do you have a log of the error?
<Saviq> pitti, just a sec
<hallyn> pitti: thx, i'll use that.  i just want to build a 226 with some debug added so i can test why sid containers are regressing with journald
<Saviq> pitti, ah, I think I found my issue... my *.deb included armhf and i386 packages...
<Saviq> doh
<pitti> Saviq: :)
<stgraber> pitti: that MAC address test failure is really odd. I'm currently working on our testsuite and I've run it probably about 50 times over this weekend and never saw that one, yet it seems to be easy enough to reproduce in the adt environment
<stgraber> pitti: I'm assuming it's some kind of race, possibly happening on slow storage (all my systems are on SSD)
<stgraber> pitti: I pushed a force-skiptest for LXD since it's clearly not a regression and I'll add a bit more context to that test for the next release, so hopefully I can see whether it's an actual race (no MAC at that point or something) or something's actually messing up the MAC address somehow
<stgraber> (we also run the testsuite on every commit and have never seen that particular failure outside of adt)
<cjwatson> hjd: Virtual packages are things which appear in the Provides field of another package.
<cjwatson> hjd: wily has automake-1.15, not automake-1.14.  libjpeg9 should really not be build-depending on automake-1.14, but rather on automake (>= 1:1.14) - assuming that it works with 1.15, that is.
<cjwatson> (If it's even a sensible thing to have in the archive at all, given that I thought libjpeg-turbo was consciously preferred.  Not sure why doko synced it.)
<sarnold> cjwatson: why do you say that automake-1.14 isn't in wily? https://launchpad.net/ubuntu/+source/automake-1.14 shows that it is published for wily, expanding the little triangle shows an _all.deb file for it that's just about the same size as the 1.15 _all.deb; I just don't see how it's "not in wily"
<sarnold> I mean, the error from the builder looks like it agrees with you :) but I just odn't know how the builder came to the same conclusion you did
<cjwatson> sarnold: the automake-1.14 source produced exactly one binary, "automake", which is superseded in the archive by a binary of the same name built by automake-1.15
<cjwatson> So the fact that the automake-1.14 source is still present is cruft, but essentially irrelevant
<cjwatson> We don't have good reports for that kind of thing so they sometimes aren't cleared up very promptly
<cjwatson> In this case, probably partly because the source doesn't seem to have been removed from Debian unstable yet
<sarnold> cjwatson: aha, thanks for the explanation
<hjd> cjwatson: sarnold: Ok, I see.
<hjd> Btw, what's the story on libjpeg vs libjpeg-turbo?
<cjwatson> The TB decided to go for libjpeg-turbo some time ago
<cjwatson> The Debian technical committee agreed, more recently
<cjwatson> I have absolutely no idea why libjpeg9 is being introduced into wily now
<hjd> cjwatson: Ok, thanks.
<mterry> ogra_, do you know much about system loggers?  Like how one registers as one?  And how /dev/log connects to it?
<mterry> Or anyone else, if anyone knows.  :)
<mterry> slangasek, maybe you know?  ^
<cyphermox> mterry: slangasek is on vacation
 * cyphermox looks
<sarnold> mterry: iirc /dev/log is a unix domain socket with a name in the filesystem; it is probably created by a socket(AF_UNIX), bind(s...) series of system calls
<cyphermox> yep
<sarnold> mterry: if you want to handle some log entries but not others, you probably have to write an rsyslog module; you might also configure rsyslog to forward all entries to a specific tcp or udp port, ip..
<cyphermox> mterry: my reaction was to dig in src/journal in systemd source
<mterry> cyphermox, sarnold: I'm trying to debug a case where syslog() freezes.  Trying to figure out where it's dying before it hits rsyslog.  And there's some evidence that rsyslog isn't correctly being "registered" as the system logger, however that's done (is that simply creating /dev/log?)
<mterry> This is on the phone, so no systemd.  But true that it may be instructive
<sarnold> mterry: syslog() _freezes_? that's odd. can you reproduce it with e.g. logger(1)?
<mterry> sarnold, yes.  I can reproduce it with a one-line main() call to syslog
<mterry> (and logger(1))
<mterry> If I 'restart rsyslog', it no longer freezes
<mterry> But it also doesn't write to syslog
<mterry> So I think rsyslog is having troubles 'registering' as the logger?  first time it gets broken.  and can't do it subsequent times
<mterry> If I gdb into rsyslog, it's waiting on a select, which would seem to be normal rsyslog behavior
<cyphermox> mterry: maybe you're running in a case where some other android thing is picking things up when it shouldn't, if it's some new device
<sarnold> mterry: I think if the file exists, rsyslog ought to be running; if writes into the socket are blocking, that might mean that rsyslog isn't consuming data quickly enough.
<mterry> cyphermox, that's possible
<cyphermox> mterry: unlikely though :)
<cjwatson> it'll be openLogSocket in rsyslog, I expect
<sarnold> mterry: odd that it would be just sitting in select(); I'd expect rsyslog to really be free of select() bugs by now
<mterry> cjwatson, it seemed to be the same place a well-behaved rsyslog was waiting, but I don't recall at the moment.  let me check
<cjwatson> you might want to arrange for rsyslog debugging output to go somewhere useful, since I expect it'll at least issue a debug message if it fails to bind /dev/log
<cjwatson> (I don't know how to do that OTTOMH)
<cjwatson> the process of opening the log is basically socket+bind
<cjwatson> see createLogSocket
<mterry> Yeah, rsyslog is selecting inside of realMain.  Presumably doing its normal looping?
<cjwatson> and bind(2) + unix(7)
<mterry> cjwatson, ok
<mterry> cjwatson, I remember it being awkward to get debug info out of rsyslog...  will see what I can do
<cjwatson> bind() can fail if something else is already bound to the same filesystem socket object
<cjwatson> if I were investigating this I would probably just hack it to spew debug to some hardcoded file under /run
<cjwatson> debugging early boot stuff got a lot easier when /run was devised :)
<mterry> cjwatson, heh
<cjwatson> alternatively you could just hack the upstart job to run it under strace
<cjwatson> and likewise dump the trace to /run
<cjwatson> that would probably be my first resort
<cjwatson> then you can look for it trying to bind to /dev/log, which should be pretty early, and see if it worked
<mterry> cjwatson, great points, thank you.  I'm about to go EOD; I'll try them tomorrow
<mterry> Rsyslog may have won the battle, but it will not win the war  :)
<hallyn> pitti: oh, nm, i see it must be in your bzr or git tree - sorry for the noise
<sarnold> mterry: one possibility is that the /dev/log might have changed underneath you somewhere; I think all it would take to seriously confuse things is for one program to unlink(/dev/log), then create its own socket or fifo
<sarnold> mterry: check lsof for inode numbers for both the hanging client and the running rsyslog; perhaps the /dev/log is a holdover from an android logging daemon? (seems unlikely, but worth mentioning, the situation you've got now is confusing)
<mterry> sarnold, agreed  :)   thanks
<mterry> sarnold, lsof only shows rsyslog on the broken device
<sarnold> mterry: does it have the same inode number as e.g. the blocking logger() or one-liner syslog() program?
<mterry> sarnold, oh, right.  I had run it without the syslog program up  :-/
<mterry> sarnold, with that up, I see:
<mterry> dpmd     2197   root   12u  unix 0xffffffc0675ba000      0t0 19440 /dev/socket/qmux_radio/qmux_client_socket
<mterry> which is unexpected by me
<mterry> Which is some android thing
<mterry> I think I need to talk to the android-side people
<sarnold> qmux radio? o_O
 * mterry shrugs
<mterry> sarnold et al: thanks for the help.  I'm going to knock off soon, but will try digging further with your awesome suggestions tomorrow
<sarnold> have a good evening :)
#ubuntu-devel 2015-09-22
<hallyn> xnox: ping, https://mentors.debian.net/package/netcf
<pitti> Good morning
<pitti> infinity, smoser: wolfe-03 and wolfe-07 are AWOL; could you try and reboot them, please?
<dholbach> good morning
<dupondje> nobody with wily that uses L2TP ? ;) might be cool if somebody could test https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1487183 on wily.
<ubottu> Launchpad bug 1487183 in network-manager-strongswan (Ubuntu) "Upgrade nm-strongswan to latest 1.3.1 with psk support" [Undecided,Incomplete]
<pitti> infinity, smoser: they are back (as mysteriously as they disappeared), so unping
<who_me> hi, is this a good place to ask why building kernel packages using the patches in the mainline ppa fails?
<who_me> the build log is here: https://dl.dropboxusercontent.com/u/3371527/results_4.1.8.txt
<caribou> micahg: did you see my last post regarding LP: #1494141
<ubottu> Launchpad bug 1494141 in trusty-backports "HAProxy 1.5 init script does not terminate processes" [Medium,In progress] https://launchpad.net/bugs/1494141
<cjwatson> who_me: #ubuntu-kernel is more likely to have experts around
<Laney> pitti: do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glib2.0 says that kdeplasma-addons/i386 is FAIL?  http://autopkgtest.ubuntu.com/packages/k/kdeplasma-addons/wily/i386/
<Laney> s/FAIL/regression/
<pitti> Laney: short version: yes, and I retried them
<pitti> Laney: long version: we now track results by trigger, and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/k/kdeplasma-addons/20150921_190755@/log.gz was the result for these triggers
<who_me> cjwatson, yep. I'm on there. Thank you :)
<Laney> pitti: You mean that subsequent runs triggered by other packages (instead of manually) won't turn it green?
<pitti> Laney: queues are just loong again, due to the combined effect of uninstallable linux-meta for the whole night and all of KDE landing, and KDE having achingly long tests (as they all involve rebuilding the package)
<pitti> Laney: right; I need to think about how to make this a bit less strict again for non-kernel triggers
<pitti> or whether we actually want that
<pitti> (I think we do)
<Laney> If it goes green then this package/test can't be broken
<Laney> so we should get a pass state
<pitti> yes, I know
<pitti> for now I retried the failing tests
<Laney> cool, thanks
<Laney> what about click?
<pitti> Laney: I wrote a script to re-run all regressions, FYI
<Laney> is that a firewall thing?
<pitti> Laney: yeah, I suppose firewall changed yet again, and LP download stopped working
<pitti> the rules seem to change on a weekly basis :/
<Laney> bleh
<xnox> hallyn: made source-only upload, as it's fully binary-only package.
<Laney> did you file an RT or should I?
 * Laney wonders what a binary-only package is
<pitti> Laney: I haven't looked at it at all yet
<flexiondotorg> Laney, could you re-open this bug please? https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1484083
<ubottu> Launchpad bug 1484083 in One Hundred Papercuts "Don't work autologin after update lightdm" [High,Confirmed]
<flexiondotorg> See the last 4 comments.
<dholbach> PING PING PING! If you have upload rights and have a bit of time, can you maybe help with http://reqorts.qa.ubuntu.com/reports/sponsoring/? Particularly flexiondotorg was looking to get some uploads in before the beta images are spun.
<tsimonq2> dholbach: Oh wow! I didn't notice that before! Thanks for telling me! XD
<tjaalton> ginggs: the new libclc requires llvm-3.7, which doesn't build on i386, so that'll have to wait for w+1
<Riddell> pitti: there seems to be lots of regressions in update_excuses.html for kde stuff that don't seem to exist in reality, do you know anything about that?
<pitti> Riddell: yes; they are "real" in the sense that at the time they ran they actually were uninstallable
<pitti> Riddell: see scrollback from 1.5 h ago; I retried them, queues are catching up
<pitti> but ARM still has some ~ 290 tests to grind through
<Riddell> pitti: lovely thanks
<ginggs> tjaalton: thanks for the update :)
<Laney> flexiondotorg: you can't?
<flexiondotorg> Laney, sadly not.
<Laney> probably apply for the bug squad
<micahg> caribou: just now, I'd suggest getting the patch SRUd and then we can apply the same one to backports
<caribou> micahg: ok, will do. thanks!
<sil2100> pitti: hey! Any news on LP: #1484882 ? Can I help out with it somehow? I suppose I don't have access to the right machines to work on it, or is there a way I could get this working?
<ubottu> Launchpad bug 1484882 in langpack-o-matic "Set automatic language-pack creation an upload for overlay-ppa" [Medium,Triaged] https://launchpad.net/bugs/1484882
<pitti> sil2100: the machine isn't magic in any way; can we avoid the merging somehow, or is that required due to the way RTM/15.04 is represented in LP?
<pitti> sil2100: otherwise the blocker is mostly to find out why ubuntu-ui-toolkit.po is missing from the packs that are built that way
<sil2100> pitti: I think we can't avoid that, since there's just no other way - it has to be vivid-full + vivid-delta + overlay
<pitti> sil2100: you built/uploaded some packs yourself with that approach, did you have that too?
<sil2100> hmm, I don't remember, I think it was normally translated there
<sil2100> Let me look for some old files
<pitti> sil2100: other than that it's mostly just updating cron.daily.rtm (in the langpack-o-matic bzr) to do these steps
<pitti> but the munging of ubuntu-ui-toolkit.po is a bummer
<sil2100> Ok, let me look into that
<sil2100> So is the cron alteady running the cron.daily.rtm script?
<pitti> sil2100: no, that was for the old 14.09 one (which was complete)
<pitti> sil2100: I basically did the steps in comment 2
<sil2100> pitti: maybe I should make a cron.daily.overlay? ;)
<pitti> sil2100: .rtm is fine, we don't use it for anything right now
<seb128> pitti, speaking of langpacks, how often are wily ones generated?
<pitti> sil2100: so if you want to spend some time figuring out what on earth is wrong with ubuntu-ui-toolkit.po, that'd help a lot
<pitti> seb128: https://translations.launchpad.net/ubuntu/wily/+language-packs -> once a week
<sil2100> pitti: sure, on it right now :)
<sil2100> pitti: I'll also try to modify the cron.daily.rtm to do the right stuff
<pitti> sil2100: : seeing your MP -> why do we need three tarballs?
<pitti> sil2100: I thought LP's RTM/15.04 has all the delta towards vivid?
<seb128> pitti, do you know why we didn't get one on friday then?
<pitti> seb128: hm, no, I don't
<seb128> I guess that would be a question for the launchpad team?
<seb128> wgrant, cjwatson: ^ do you know?
<pitti> wgrant: ^ any idea why https://translations.launchpad.net/ubuntu/wily/+language-packs is missing an export last Fri?
<cjwatson> looking
<seb128> thanks
<cjwatson> DisconnectionError: terminating connection due to conflict with recovery
<cjwatson> I'm not sure exactly what was going on at that time, but today's worked
<cjwatson> pitti: so I guess you need one now?
<sil2100> pitti: we need 3 since there's a vivid full pack and then vivid deltas
<sil2100> pitti: https://translations.launchpad.net/ubuntu/vivid/+language-packs <- as you can see all new langpacks are deltas
<cjwatson> In fact the crash above was Thursday's, Friday's didn't run at all
<sil2100> pitti: and we need the base vivid + the latest vivid delta to get latest vivid translation and then the overlay one
<sil2100> pitti: so it's 3
<cjwatson> But Thursday's was wily
<seb128> cjwatson, pitti, new one would be good, I would like to see if evolution-3.16 and e-d-s-3.16 are getting included now
<cjwatson> seb128,pitti: requested in #webops
<seb128> cjwatson, thanks
<pitti> sil2100: ah, last time I just took vivid final plus the RTM tarball
<pitti> sil2100: I would have thought RTM is relative to vivid final, not vivid-updates
<gQuigs> dÃ©jÃ  vu, this already landed for Ubuntu (Unity), just needs to land for Kylin to - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntukylin-xul.wily/+merge/270991
<sil2100> pitti: the RTM bits are not really relative to anything, they're just detached packs generated out of what's in the overlay-ppa :)
<hallyn> thanks xnox
<hallyn> binary-only package - is that bc there hadn't been an upload since the jessie release?
<gQuigs> pitti: you did the other merge (thanks again!), mind doing kylin as well? ^
<pitti> gQuigs: sorry, not today, swamped :/
<gQuigs> np
<pitti> Laney: click is happy again
<Laney> pitti: yay
<pitti> armhf queue is at 267
 * pitti will check again tomorrow morning, TTFN
<Laney> happy evening
<hikiko> I checked out the planet-ubuntu code
<Laney> but it is on the sidebar here http://planet.ubuntu.com/
<hikiko> and the last entry was willcooke's
<Laney> sooooooooooooooooo
<didrocks> the planet sidebar list him
<willcooke> no, ignore
<willcooke> it's there
<Laney> and the post is there
<Laney> it works
<hikiko> willcooke, yes the posts appear in the feed
<hikiko> there are just too many posts by people :)
<willcooke> yeah, I check it a few days after I posted and it wasnt there, maybe takes longer than I expected
 * willcooke made a hackergotchi especially
<hikiko> hahaha
<didrocks> hikiko: there are even post from the future (30 september) :p
<hikiko> LOL
<hikiko> I'll keep my picture igognito
<willcooke> hikiko, I'll talk you through it after the meeting
 * hikiko is too lazy to do a hackergotchi
<willcooke> it's pretty straight forward
<hikiko> thanks willcooke :)
<pitti> sil2100: responded to https://code.launchpad.net/~sil2100/langpack-o-matic/multi_merge/+merge/271954
<sil2100> pitti: thanks! Comments make sense :)
<jdstrand> pitti: hey, not sure if this is a question for you (feel free to redirect me) but yesterday I uploaded ubuntu-core-security, apparmor-easyprof-ubuntu and ubuntu-personal-security, and update_excuses.html is telling me that they are still waiting on armhf (Test in progress)
<jdstrand> pitti: is there a problem with armhf?
<jdstrand> jibel: do you know? ^
<sarnold> jdstrand: it could be that the huge queue built up from the lcy01 destruction ~two weeks ago hasn't been cleared yet, pitti said something about several hundred kernel tests queued up on saturday..
<jdstrand> sarnold: ah, I see
<jdstrand> I would be nice to be able to see the queue
<jdstrand> I read https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration but don't seem to have access
<jdstrand> oh, there is a bug on that already
<sarnold> jdstrand: yeah, that's on pitti's todo list too :)
<jdstrand> https://launchpad.net/bugs/1479811
<ubottu> Launchpad bug 1479811 in Auto Package Testing "Show pending tests on web UI" [Wishlist,Triaged]
#ubuntu-devel 2015-09-23
<catbus1> Hi, when will be 14.04.4 released? I don't find it on https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
<sarnold> catbus1: if 12.04 LTS serves as a guide, february looks likely https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<pitti> Good morning
<pitti> jdstrand: a "problem" only insofar that there was a looong test request queue
<pitti> jdstrand: the KDE package tests take awfully long, and we got several hundreds of them yesterday, so a lot to catch up with
<pitti> bah, yesterday the queue was at 250, now at 340, what happened
<pitti> ah, more KDE uploads
<pitti> jdstrand: so, it'll catch up eventually
<tjaalton> so is mesa stuck in proposed because of the freeze or something else?
<tjaalton> ok found it in update_excuses.html, but why doesn't http://autopkgtest.ubuntu.com search show any hits?
<tjaalton> sigh arm is slow
<pitti> tjaalton: see scrollback from 20 mins ago
<pitti> tjaalton: there's also the libopengl-perl regression
<tjaalton> which failed three days ago too
<tjaalton> so not really a regression
<tjaalton> in mesa at leaset
<tjaalton> *caused by
<tjaalton> though failed for some other reason, now the deps can't be fulfilled
<pitti>  libgl1-mesa-glx : Breaks: libopengl-perl (< 0.6704+dfsg-2) but 0.6704+dfsg-1 is to be installed
<tjaalton> oh :)
<tjaalton> yeah let's sync that then
<pitti> tjaalton: https://tracker.debian.org/news/707796 ? looks sensible
<tjaalton> yes, forgot the breaks got added recently
<tjaalton> is there a way to test these locally first?
<pitti> so, I added a second worker on each arm machine
<pitti> while this slows down individual tests, this will be a net win on throughput, I do the same on the ppc64el boxes
<pitti> tjaalton: build and install it in a wily-proposed schroot?
<tjaalton> ah
<zyga> good morning
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<pitti> infinity: please let me know if you want me to disable testing on armhf temporarily, the backlog is huge (about a day, I'd say)
<pitti> infinity: if you want to build beta images today or so
<infinity> pitti: Disabling armhf wouldn't hurt, yeah.
<pitti> infinity: okay
<pitti> seb128, Saviq: ^ FYI
<Saviq>  tx
<seb128> pitti, thanks
<pitti> done
<pitti> next britney run should stop showing/caring about armhf
<pitti> infinity: ok, lots of valid candidates now
<seb128> wgrant, cjwatson, still no wily langpack update, do you know if webops did an export retry yesterday?
 * pitti also overrides the boottest regressions while he's at it
<wgrant> seb128: 2015-09-22 16:46:06 INFO    Registered the language pack.
<wgrant> Looks there to me.
<pitti> yes, it's on https://translations.launchpad.net/ubuntu/wily/+language-packs
<pitti> seb128: want me to start a manual cron run?
<pitti> (for wily it usually runs Friday, as we expect the exports on Thu)
<seb128> pitti, yes please, I would like to have those on the beta image
<pitti> seb128: https://launchpad.net/ubuntu/wily/+queue?queue_state=1 is getting the uploads; is there something which you expect in particualr?
<seb128> pitti, I was just checking the -fr source
<seb128> yes, I was looking to know if evo/eds-3.16 were included
<seb128> the .po are in the source
<seb128> let's see if that ends up in the binary
<seb128> pitti, looking good
<seb128> let's see if we can get the langpack updates approved for beta, that would be nice
<pitti> seb128: I was going to accept them now
<seb128> danke
<seb128> can you approved unity-control-center (fix for blutooth pairing) and user-setup (fix for autologin on new installs) as well? ;-)
<pitti> infinity: ^ hm, is that alright?
<pitti> I just realized the beta is already tomorrow, not next week
<seb128> yeah, I got confused by the wiki calendar
<seb128> I though the freeze was tomorrow
<pitti> seb128: so, I'm not sure how frozen we are; if I get a green light from the RT I can approve the langpacks and the others
<seb128> pitti, thanks
<seb128> let's see
<seb128> I'm still unsure why we freeze things like that rather than just getting in proposed and blocking migration
<seb128> like those langpacks could already build
<seb128> they are going to be in before release in any case
<cjwatson> the reason there's still a short freeze even on -proposed is to avoid people complaining that they needed to build their urgent fix but it FTBFS due to junk in -proposed
<cjwatson> that doesn't seem to apply to langpacks though
<pitti> I asked in #u-release
<cjwatson> that said, there's no -proposed block in place at the moment
<pitti> cjwatson: the disabled ("cleaning") lgw builders with the "ongoing neutron problem investigation" is still ongoing, I take it?
<pitti> https://launchpad.net/builders/lgw01-11/+edit is a bit confusing
<pitti> as the builder seems to be enabled, but in "cleaning"
<pitti> then again, lots of other builders are also in "cleaning" and haven't built anything for a week and don't have this note
<pitti> https://launchpad.net/builders/lcy01-08/+history -> last build on Sep 18
<cjwatson> pitti: Occasionally we run into incidents where the reset request gets lost for one reason or another; it has nothing to do with the previous neutron problem.
<cjwatson> pitti: disable/enable typically clears these up; I'll do that now.
<pitti> cjwatson: ok, good to know for the next time; thanks
<cjwatson> pitti: But "haven't built anything for a week" is just because we have plenty of builder capacity now - the whole build farm has been clean more recently than that.
<pitti> so in general that's safe as long as the builder is marked as enabled?
<cjwatson> pitti: Well, best leave it to LP folks in case there's some known incident
<pitti> cjwatson: ah, ok; (and BTW, this is amazing!)
<cjwatson> But normally should be
<pitti> ack
<cjwatson> pitti: should all be unstuck now
<cjwatson> Nice for the special case of being able to build all your language packs in parallel, I suppose :)
<FourDollars> Is it possible to revoke 1.4.10-1ubuntu1 of https://launchpad.net/ubuntu/+source/modemmanager? It didn't fix any issue.
<pitti> FourDollars: the only way is to upload an -1ubuntu2 with the change reverted
<pitti> FourDollars: or in this case, an -1wily1 (or anything which is bigger than 1ubuntu) so that the next time it auto-syncs
<FourDollars> pitti: OK. I see. Thanks for your information.
<pitti> 1-1+build1
<pitti> FourDollars: 1.4.10-1+build1 is a better version number; it's clearer, and bigger than 1ubuntu1
<FourDollars> pitti: I agree.
<FourDollars> @BinLi Could you help to do this for wily first? ^^
<udevbot> Error: "BinLi" is not a valid command.
<FourDollars> BinLi: Could you help to do this for wily first? ^^
<FourDollars> pitti: BTW, what is the next version after 1.4.10-1+build1 if we want to fix some issue?
<pitti> FourDollars: 1+ubuntu1, I figure
<FourDollars> pitti: Thx.
<pitti> FourDollars: OTOH, if the last version isn't actually a regression, just a no-op, you don't need to bother much
<pitti> FourDollars: would just be nice to somehow remember that this can be synced at the next occasion, instead of merged
<FourDollars> pitti: OK.
<FourDollars> pitti: Thx for your information again. :)
<pitti> tjaalton: ah, new libopengl-perl works again, so mesa propagated
<tjaalton> pitti: yeah
<BinLi> FourDollars: ok
<pitti> PSA: I have to reconstruct http://autopkgtest.ubuntu.com/ again, results will come back in the next hour or two; sorry
<tjaalton> pitti: hey, would adding some udev rules for steam controllers belong to systemd?
<pitti> tjaalton: what do they do?
<tjaalton> pitti: good question, the bug doesn't have it attached
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498655
<ubottu> Launchpad bug 1498655 in systemd (Ubuntu) "Steam Controller support: need read-write access to Valve-owned input event device nodes." [Undecided,New]
<tjaalton> but looks like systemd got added already
<mdeslaur> pitti, tjaalton: one sec, I'll attach it, I extracted it to take a look
<tjaalton> ok good
<mdeslaur> attached
<jdstrand> pitti: ok, thanks for getting back to me :)
<jdstrand> pitti: and hello :)
<pitti> hey jdstrand, how are you?
<pitti> jdstrand: FTR, I temporarily disabled armhf in britney to not block final beta; and the arm queue is down to 68 now
<jdstrand> pitti: I'm doing well, yourself?
<jdstrand> pitti: re britney, ok, thanks
<pitti> jdstrand: quite fine, thank you
<pitti> wrestling with britney still :)
<jdstrand> (it looks like the 3 packages I was looking at all migrated)
<jdstrand> heh
<jdstrand> well, don't let me distract you! :)
<sil2100> pitti: hey, checked the langpacks generated by langpack-o-matic manually here locally and all seems ok, I have the UITK updated po files etc.
<sil2100> pitti: I'll modify the cron.daily.rtm script now
<sil2100> pitti: just one question - in the old cron.daily.rtm, after the ./import command, there's also a call to ./merge-touch-upstream-translations
<sil2100> What does that script do?
<sil2100> Is it required?
<sil2100> Since I never really ran it before, the resulting tarballs are just good
<pitti> sil2100: this was for the time when we didn't have translations in the ubuntu (or RTM) packages, only in trunk
<sil2100> Aaah
<sil2100> Ok, so I can just get rid of that
<pitti> sil2100: and IIRC this was down to one or two projects anyway, no? it started out with 15 projects to pull translations for
<pitti> cool
<seb128> quadrispro, pitti, should we sync the new libmtp from debian for wily? it seems to mostly fix bugs and add device ids
<pitti> seb128: sounds good to me; libmtp hardly grows actual features
<pitti> seb128: did you actually mean sync? i. e. did upstream take our "add arale device" patch?
<pitti> seb128: and bq?
<seb128> pitti, https://packages.qa.debian.org/libm/libmtp/news/20150605T162243Z.html
<pitti> yay
<sil2100> pitti: https://code.launchpad.net/~sil2100/langpack-o-matic/new_overlay_cron/+merge/272111 - this would need the multi merge branch to land as well :)
<pitti> sil2100: yay, thanks
<pitti> sil2100: I haven't yet done the previous MP, sorry; it now looks even more complicated than before, I'll see to making this easier
<sil2100> Oh, I need to correct one thing in it
<pitti> sil2100: or merge it if you carefully tested it with two and multiple tarballs
<pitti> but right now it's rather hard to understand
<sil2100> I used it for merging 3 tarballs and it worked
<pitti> ok
<pitti> so then maybe I'll just merge this "blindly", and rewrite the damn thing from scratch
<sil2100> At least, I got the proper langpacks from langpack-o-matic ;p
<sil2100> It's not so complicated, I'm doing the exact steps you did just sequentially, one argument after another
<pitti> sil2100: yeah, wasn't blaming you really -- this script is horrible
<pitti> all this find/copying stuff around is massively overkill
<pitti> sil2100: your idea with cat'ing the mappings to .merged and sort -u at the end is nice, and so much easier
<pitti> with that we can just untar all tarballs on top of each other
<sil2100> Thanks, actually yeah, we might get rid of the find call that way even now I suppose
<sil2100> Well, let's do that later :)
<rbasak> infinity: I've just uploaded new backports for docker.io, to trump the existing packages in -proposed for some upgrade issues that kickinz1 found. They're fixed in Wily and re-backported.
<pitti> sil2100: I'm trying to spot what you changed in the ./import line
<pitti> +find pkgs/ -name changelog -exec sed -i 's/ 15.04;/ vivid;/' "{}" \;
<pitti> sil2100: ^ that looks like a debugging leftover? shouldn't that be s!pkgs!$dir/sources-touch! or something like that?
<sil2100> Argh!
<sil2100> Yes!
<sil2100> uh!
<pitti> sil2100: oh, I see it: $TAR â $TARM, of course
<pitti> that's what I like about PRs on github, the actually changed chars have a stronger color
<teward> if a package is compiled with sse2 instruction set support but not sse support, is that a bug that should be filed?  (generic question based off a discussion in #ubuntu-bugs right now)
<seb128> mardy, thanks for eds oauth refresh patch, that fixes my indicator-datetime not listing calendar events, I backported the fix to wily ;-)
<mardy> seb128: oh, thanks for that!
<seb128> yw!
<seb128> it's funny that you filed that bug/patch today, I started looking at why my calendar was buggy yesterday and filed some upstream bugs with valgrind logs
<seb128> just backported some fixes from Milan for those and your patch as well
<rbasak> teward: I think that depends on what we define to be the minimum instruction set that we support. I'm not sure where that might be documented.
<rbasak> doko might know maybe? ^
<melodie> hi
<melodie> I have installed Bento Openbox Remix in a very old laptop, Compaq Presario 920 with a proc amd athlon XP 2000+, which as the sse flag but no sse2 flag and a few programms don't start there but crash. Is it a bug or are they expected to not work with a non sse2 capable proc? This is glxgears and glxinfo
<melodie> $ LANG=C glxinfo
<melodie> name of display: :0
<melodie> Illegal instruction (core dumped)
<melodie> (for example)
<highvoltage> 1/win 12
<ryao> Is the SRU process used for kernel updates in both LTS releases and non-LTS releases or just LTS releases?
<cjwatson> ryao: Both (although the kernel is a special case for SRUs, https://wiki.ubuntu.com/KernelTeam/KernelUpdates)
<teward> rbasak: it's related to melodie's issue
<teward> rbasak: i know that for an instruction set to be supported on any given system the CPU needs to support it, but that doesn't answer the ultimate question of minimum supported instruction set.  If that's documented somewhere, great, if not, well then meh
<melodie> teward, it seems for now, that only glxgears and glxinfo can't start and spit a 'core dump illegal instruction' message.
<melodie> I have tried several programs so far
<rbasak> I suspect the minimum supported set is known by someone somewhere.
<melodie> including pcmanfm, xchat, synaptic, sakura, libreoffice writer
<seb128> cyphermox, would https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch/+bug/1498805 be one for you or for infinity?
<rbasak> Just not by me.
<ubottu> Launchpad bug 1498805 in usb-modeswitch (Ubuntu Wily) "Please merge usb-modeswitch 2.2.5+repack0-1 from Debian unstable/testing - current 2.2.3 version in Wily has regressions with lots of Huawei modems" [High,Triaged]
<seb128> it claims that the 2.2.3 update in wily regressed things
<rbasak> Maybe ask the ubuntu-devel ML?
<teward> rbasak: indeed, I may.  melodie: perhaps ask the ML?
<teward> rbasak: fwiw i don't ever really have any issues, my proc supports sse and sse2 as well as probably others.  Modern processors are modern :)
<melodie> teward, I am unsure if I should suscribe there... do you think you could ask the question?
<teward> I don't think I'm subbed either
<melodie> then I guess I should :)
<melodie> just one more for the todo list
<melodie> :)
<melodie> humm
<melodie> yes that's the point, "minimum set supported"
<cyphermox> seb128: it's for anyone who wants to tackle it. It involves looking at the diff between the versions of the tcl program, and re-doing those in our C rewrite
<cyphermox> the regression might be something else, like interaction with systemd
<seb128> k
<seb128> cyphermox, well, I was mostly pointing it so it's doesn't get un-noticed
<seb128> I tagged it rls-w-incoming as well
<cyphermox> I would suggest someone very familiar with systemd take a look, in case, even before doing any other update :/
<melodie> thanks, I have to quit now
<seb128> cyphermox, that means pitti? ;-)
<sil2100> pitti: hmmmm
<cyphermox> seb128: not necessarily, but I'm afraid I might not be the best person to look at it
<seb128> k, no worry
<cyphermox> as I recall, it was already "fixed" to deal with systemd and udev in the "new way", but maybe something's still off
<teward> did the latest galculator get on the beta2 image or no?
<teward> (see #ubuntu-bugs, and poke phillw or melodie for more details)
<sil2100> pitti: so I tested the cron script that I prepared just now, and I think there might be something wrong with the tarballs we get through the +latest-*-language-pack link
<sil2100> pitti: since when I manually downloaded the tarballs from LP through the webbrowser and ran ./import, the resulting packages had proper UITK .po files - but when I run the cron script, those are missing as in your case
<sil2100> pitti: looking into that now
<pitti> sil2100: wow -- so I'm not seeing ghosts?
<sil2100> pitti: it's really really strange! Since the cron script does the same things I did manually, with the only difference being how the tarballs got downloaded
<sil2100> I'm downloading them now here to see if that's really the case
<cyphermox> pitti: can you ping me when you have a moment, we can team up against usb-modeswitch and see what might be wrong with the version in wily before we consider updating?
<teward> tjaalton: ping, if you're around
<teward> if not someone else who knows the galculator package will do
<pitti> cyphermox: we are mostly non-overlapping (no time any more today, sorry); what's wrong with it?
<pitti> cyphermox: I fixed a few segfaults earlier in wily which made it work at least for me
<cyphermox> not always running the switching for huawei modem
<cyphermox> if you say it works for you, perhaps this is limited to huawei
<cyphermox> in which case I won't need your help :)
<sil2100> pitti: oh, wait, I think I see the potential problem
<sil2100> Let me test (will take a while)
<pitti> cyphermox: I actually have a huawei stick too, I just never used it (except for testing this, like twice a year)
<tjaalton> teward: ?
<cyphermox> pitti: ok
<cyphermox> well, not today is fine too
<pitti> cyphermox: so this is triggered via udev rules, right?
<cyphermox> yes
<pitti> cyphermox: the main gotcha I'm aware of is that udev rules must never try to launch a process into the background
<pitti> it'll just get killed after a second or so
<teward> tjaalton: galculator complaints, apparently, but it's a proxy report of a problem.  last activity was yesterday, now ubuntu-bug supposedly doesn't see the package as an actual package from the repos
<pitti> cyphermox: but under systemd it should trigger usb_modeswitch@.service, does it?
<cyphermox> pitti: maybe, I don't recall
<cyphermox> in any case, I'll debug it here
<teward> tjaalton: any idea why it wouldn't be read as official, etc. with trying to report new bugs?
<cyphermox> I may have a huawei modem around somewhere
<pitti> cyphermox: so what's really worrying is that the whole /lib/udev/usb_modeswitch runs in teh backgroud
<ryao> cjwatson: Thanks.
<pitti> cyphermox: that cries for race conditions and getting killed prematurely
<teward> tjaalton: since you last synced it, i thought i'd bug you first.
<pitti> cyphermox: we had a similar problem with ifup@.service, if DHCP took more than 3 seconds or so it was killed
 * teward is attempting to reproduce now
<cyphermox> yes, it runs the usb-modeswitch service
<tjaalton> teward: what's the issue? ubuntu-bug galculator seems to work here
<tjaalton> don't even have it installed
<teward> tjaalton: phillw reported that "in paper mode, you cannot type anything in"
<teward> tjaalton: he tried ubuntu-bug and it said it wasn't an official package
<teward> again i'm trying to repro (but my VMs died >.<)
<tjaalton> the old version perhaps?
<tjaalton> i've never used it myself, synced because it was on the sponsor queue
<teward> tjaalton: ack.  may just say manually file, and then do apport-collect
<teward> or w/e it is to get the apport data
 * teward has it written somewhere
<tjaalton> so how to init paper mode?
<tjaalton> oh got it
<tjaalton> seems to work here
<teward> crud i need to redownload the iso >.<
<teward> stupid corruption >.>
<tjaalton> ubuntu-bug not doing it's thing probably means something is out-of-date
<teward> tjaalton: indeed
<tjaalton> so first upgrade to current wily and try again..
<tjaalton> it's fine here
<teward> ack
<teward> tjaalton: looks like you're off the hook, phillw's gonna poke ianlorin about it, but i'm still going to see if I can reproduce with the beta 2 iso
<teward> after it redownloads xD
<tjaalton> i have wily on four systems, it's fine :P
<teward> indeed.  i have power-user'd 14.04 on this laptop, but VMs galore for the other versions xD
<rbasak> stgraber: I've re-uploaded kimchi with the debian/copyright fix. Diff is: http://paste.ubuntu.com/12531981/
<stgraber> rbasak: thanks
<catbus1> Hi, anyone know when 14.04.4 will be released?
<jtaylor> is there a good way to disable the grub quick_boot? grubs save_env is buggy and often ends up waiting for user input when it fails
<jtaylor> without a timeout
<jtaylor> very annoying with a headless server
<jtaylor> only thing I see in the source is a compile time option or editing the etc/grub.d files ..
<cjwatson> GRUB_RECORDFAIL_TIMEOUT in /etc/default/grub
<jtaylor> cjwatson: doesn't work
<jtaylor> or at least assuming it has a default that is not infinity
<jtaylor> its not the grub menu that is the problem, save_env fails which then seemingly goes into some code that does not have a timeout attached
<jtaylor> bug 1311247 bts
<ubottu> bug 1311247 in grub2 (Ubuntu) "[Grubenv] error: malformed file, press any key to continue" [High,Fix released] https://launchpad.net/bugs/1311247
<jtaylor> the fix released should get removed
<cjwatson> cyphermox: ^-
<cjwatson> needs actual analysis, reproduction recipe with recent Ubuntu releases, etc. rather than just saying "grub's save_env is buggy"
<cjwatson> perhaps better to file a new bug rather than piling onto an existing one
<jtaylor> probably, but having a workaround in that bug is useful because thats what you find with google
<jtaylor> the other stuff is questionable
<jtaylor> e.g. changing the default entry used
<cjwatson> well, except that you've just stuck a workaround in that bug which will probably persist on people's systems forever because conffiles
<cjwatson> even after the bug is long fixed
<cyphermox> jtaylor; perhaps it would indeed be best to file a new bug
<cyphermox> that one was indeed showing a "malformed file" error, and seemed to be because of the blocklists, maybe there's something else
<cyphermox> though I agree it needs an SRU
<jtaylor> sure, what do you need to debug it?
<jtaylor> note I'm using 14.04
<cyphermox> so you're not on grub2 ending with -21?
<jtaylor> 2.02~beta2-9ubuntu1.3
<cyphermox> it's a little confusing on that bug because I read at least one comments says they're already on the right version for that fix
<cyphermox> ok
<jtaylor> the first partition starts at block 63 btw, I know that sometimes causes issues
<cjwatson> cyphermox: I don't believe this fix was ever SRUed to trusty
<cyphermox> cjwatson: no, it wasn't
<cjwatson> so that may be all there is to it
<cyphermox> that's the problem
<cyphermox> yes
<cyphermox> just got lost in the noise of new rush things coming it :/
<jtaylor> ah there is a fix, I can test that quickly
<jtaylor> missed that changelog entry in the huge bug ..
<jtaylor> wow grub takes long to build oO
<jtaylor> cyphermox: the patch from -21 backported solves my issue
<sil2100> pitti: hey! If anything, I pushed the required change to the cron branch of langpack-o-matic and now everything seems to work as expected ;) UITK translations present ;p
<nelhage> !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
<nelhage> bug #1499075; python 3.4 SRU broke botocore and awscli in Trusty
<ubottu> bug 1499075 in python3.4 (Ubuntu) "python3.4.3 SRU breaks awscli" [Undecided,New] https://launchpad.net/bugs/1499075
<nelhage> looks like the SRU went out with bug #1348954
<ubottu> bug 1348954 in python3-defaults (Ubuntu) "update Python3 for trusty" [Undecided,New] https://launchpad.net/bugs/1348954
<mdeslaur> smoser: ^
<mdeslaur> smoser: perhaps a awscli fix is required there ^
<nelhage> Yeah, following the rabbit hole further it looks like the fix probably has to go into botocore.
<broder> i just dropped https://launchpadlibrarian.net/218689089/python-botocore_0.29.0%2Brepack-2ubuntu0.1.debdiff on the bug
<broder> it seems like it would be nice if the behavior change in python3.4 could be reverted though?
<broder> surely botocore isn't the only package using inspect
<sarnold> though having a differnt behaviour than other python 3.4.1 or later environments might also lead to bugs
<mdeslaur> yeah, I'm conflicted on that as well
<mdeslaur> it's the SRU team's call
<broder> hmm, probably, though my suspicion is that _not_ throwing an exception seems less likely cause problems? but hard to say
<sarnold> it might be worth poking barry too: https://launchpad.net/bugs/1499075  https://launchpad.net/bugs/1348954
<ubottu> Launchpad bug 1499075 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU breaks awscli" [Critical,Confirmed]
<ubottu> Launchpad bug 1348954 in python3-defaults (Ubuntu) "update Python3 for trusty" [Undecided,New]
<Unit193> robert_ancell: Now that /etc/lightdm/lightdm.conf isn't edited by anything, can you install the example file ( /usr/share/doc/lightdm/lightdm.conf.gz currently) there?
<robert_ancell> Unit193, the convention for Debian / Ubuntu packages is to install example configuration into /usr/share/doc
<robert_ancell> Unit193, and putting a file in /etc/ gets a bit confusing when upgrading packages (it will prompt you to replace any local changes with the package provided one)
<mdeslaur> broder: debdiff looks good, did you test it?
<Unit193> robert_ancell: https://packages.debian.org/sid/i386/lightdm/filelist but yes I did think of the second part, wouldn't be ideal.
<broder> mdeslaur: i've tested it locally off sbuild
<broder> i'm...a bit rusty at the processes :)
<Unit193> (Usually you have a config file in /etc/ to edit, you don't usually have to create it.  Leads people to hunt down config files in /usr/share/ and edit.)
<mdeslaur> broder: ok, I'll upload it to the queue for the sru team, one sec
<mdeslaur> nelhage, broder: I've upladed the python-botocore fix for approval by the sru team and I've asked in #ubuntu-release
 * mdeslaur -> away
<doko> broder, mdeslaur, there was some discussion what the best thing would to be. but afaicr, the expectation to have that the same behaviour as with the upstream version would be better
#ubuntu-devel 2015-09-24
<infinity> happyaron: *poke*
<pitti> Riddell: FYI, kopete regression on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html - seems the package is FTBFS now
<pitti> Riddell: kdepim-runtime also keeps failing on ppc64el; seems it only succeeded twice, so a very racy test; ignore, I suppose?
 * pitti sets it to "always failed"
<pitti> Riddell: and http://autopkgtest.ubuntu.com/packages/b/baloo-kf5/wily/armhf/ fails on the ABI compliance checker, this also looks real
<pitti> sil2100: good morning
<pitti> sil2100: thanks for the MP! as written there, I ran cron.daily.rtm last night; do the packages look ok to you?
<pitti> sil2100: if so, I'll enable it in cron
<pitti> sil2100: every Tuesday afternoon, I suppose
<FourDollars> Why can I not see the latest trusty updates at https://code.launchpad.net/ubuntu/+source/network-manager?
<FourDollars> Not from https://code.launchpad.net/network-manager neither. :-(
<seb128> FourDollars, those packages are not maintained in those vcs and the autoimporter are sometime suboptimals
<FourDollars> seb128: I need to fix some issue on trusty. Do you know where is the bzr repo?
<seb128> FourDollars, none afaik, just get the source package and do a debdiff including your change
<FourDollars> seb128: I saw lp:~network-manager/network-manager/ubuntu, lp:~network-manager/network-manager/ubuntu.vivid, lp:~network-manager/network-manager/ubuntu.precise at https://launchpad.net/ubuntu/+source/network-manager. But no lp:~network-manager/network-manager/ubuntu.trusty. It is weird.
<seb128> check with cyphermox when he's online, maybe he has a vcs...
<FourDollars> OK.
<FourDollars> cyphermox: hi
<jamespage> cjwatson, pitti: I think I know the answer to this question - the latest heat and keystone uploads for wily have broken versioning - they have not built yet and are stuck in proposed - is it possible to remove the source packages from proposed an then correct? thus avoiding bumping epoch
<pitti> jamespage: right, please avoid bumping epoch at all cost, it will make the package forever not syncable
<pitti> jamespage: yes, we can remove them from proposed
<jamespage> pitti, awesome - that would be most helpful
<pitti> jamespage: but the next upload can't re-use the same version number
<jamespage> pitti, it won't - the upstream version number will be corrected, but it will be lower than the current one from dpkg's perspective
<jamespage> is that ok
<jamespage> ?
<pitti> jamespage: I'm not entirely sure; you'll find out at next upload :)
<jamespage> current == the one in proposed
<pitti> jamespage: oh, 0rc1 â  0~rc1 :)
<jamespage> pitti, yes...
 * jamespage sighs
<pitti> jamespage: removed
<jamespage> pitti, thankyou
<pitti> time and again, having -proposed is so immensely helpful
<jamespage> pitti, agreed
<sil2100> pitti: thanks for the test run! I'll triple check them in a moment and give you a sign :)
<pitti> sil2100: nice!
<pitti> sil2100: btw, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html â seems qtmir and -gles were published prematurely? looks like they are missing a new mir?
<pitti> same for unity-system-compositor
<pitti> infinity: is bug 1435466 still actually a blocker?
<ubottu> bug 1435466 in nodejs (Ubuntu) "nodejs fails to build on arm64 due to libv8 dependency" [Undecided,New] https://launchpad.net/bugs/1435466
<pitti> infinity: block-proposed I mean
<infinity> pitti: There was one FTBFS on arm64 that I saw float by that I wanted to make sure wasn't a regression on other arches too.  I think once I've had a chance to play with that, I'll lift the tag
<pitti> infinity: ack, thanks; I mostly wanted to know whether it was still justified, but sounds like it is
<happyaron> infinity: hey
 * happyaron back from dinner
<seb128> jamespage, zul, there is a trivial patch for a typo fix in the package description on https://bugs.launchpad.net/ubuntu/+source/ironic/+bug/1451139 could you include it in the next ironic upload?
<ubottu> Launchpad bug 1451139 in Package Descriptions for Ubuntu "Typo in python-ironic: "libaries"" [Low,Triaged]
<jamespage> seb128, yup
<seb128> jamespage, thanks
<seb128> jamespage, I'm assigning to you and unsubcribing sponsors, is that ok?
<caribou> micahg: Got some bandwidth to sponsor the fix for LP: #1481737 ?
<ubottu> Launchpad bug 1481737 in haproxy (Ubuntu Trusty) "HAProxy init script does not work correctly with nbproc configuration option" [Medium,In progress] https://launchpad.net/bugs/1481737
<Riddell> pitti: I don't get the acc error in baloo, it's just running a dump of symbols isn't it? there's no actual comparison going on.  I can recreate the error but there's no output so I've no idea what it's problem is
<cjwatson> jamespage: lower than a deleted package is OK, yes
<Riddell> pitti: ah yes it's in logs/ "ERROR: can't access '/usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so'"
<pitti> Riddell: I have no idea what abi-compliacne-checker does
<pitti> Riddell: x86_64? it only fails on armhf
<pitti> Riddell: but yeah, some verbose output certainly would be useful, to be able to see what to actually fix
<pitti> Riddell: baloo-kf5 itself didn't change, so I suppose it's due to a dependency change
<pitti> Riddell: ah, nevermind -- it fails on amd64 too (in fact, all platforms)
<Riddell> pitti: so probably a problem in the test, I'll look at it after I do some beta candidates testing
<Laney> You renamed the library
<LocutusOfBorg1> hi folks, how do you feel about a pbuilder merge?
<LocutusOfBorg1> http://debomatic-amd64.debian.net/distribution#wily/pbuilder/0.217ubuntu1/buildlog
 * LocutusOfBorg1 feels crazy
<LocutusOfBorg1> but well, the delta is soo less now
<alkisg> didrocks: hi, http://changelogs.ubuntu.com/changelogs/pool/universe/u/ubuntu-mate-meta/ubuntu-mate-meta_1.134/changelog mentions that you added fcitx in ubuntu-mate-core,
<alkisg> this now runs on login and breaks at least the greek keyboard layout, could it please be removed again, or at least downgraded to suggests or recommends?
<didrocks> alkisg: I did refresh the metapackage on flexiondotorg's request (he added it to the seed)
<alkisg> Thank you
<didrocks> alkisg: let me point you to the commit, one sec
<flexiondotorg> alkisg, Hi
<alkisg> flexiondotorg: could you please have a look at that?
<alkisg> Hello
<flexiondotorg> alkisg, That was added to ensure Japanese users were supported.
<flexiondotorg> What is the issue?
<alkisg> flexiondotorg: is it necessary to run in all users worldwide?
<didrocks> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.wily/revision/18
<alkisg> In Greece, the keyboard layout supports accented characters by pressing e.g. this: ";" + "a" = Î¬
<didrocks> alkisg: recommends make sense, but IIRC, mate doesn't install recommends by default
<didrocks> happyaron: this may be of interest for you ^ (fcitx issue with greek)
<alkisg> Now if fcitx is installed, then this breaks, and produces this instead: Â´Î±
<flexiondotorg> Correct, Ubuntu MATE doesn't install recommends. I've manually resolved what is required in the seeds.
<alkisg> So basically now with fcitx-bin preinstalled, we can't type in our language
<didrocks> alkisg: I guess you have the same issue with the ubuntu desktop image, right?
<alkisg> didrocks: ah I haven't tried it, I could check...
<flexiondotorg> Sadly, there is still some package that I need to submit patches for.
<didrocks> alkisg: do you mind trying? I think we can open a critical bug as it impacts all flavors installing it
<flexiondotorg> Without doing that when the Ubuntu MATE seeds are parsed most of Unity get's pulled in.
<alkisg> didrocks: I'll do so, but it's lunch time here, so I'll report back later on in the afternoon, in e.g. 5 hours
<seb128> happyaron, ^fcitx creating compose issues, is that known?
<didrocks> alkisg: that's fine :)
<didrocks> seb128: already pinged him above
<Laney> alkisg: Do you have /etc/xdg/autostart/fcitx-autostart.desktop?
<happyaron> seb128: what compose issue?
<seb128> happyaron, read backlog
<didrocks> happyaron: please backlog, I pinged you
<happyaron> ok
<ogra_> alkisg, 5h ? wow, that even exceeds a typical spanish lunch
<seb128> didrocks, oh, right, didn't notice that line
<alkisg> ogra_: I like to hug a bit after lunch :P :D
<ogra_> haha
<Laney> TMI
<flexiondotorg> seb128, didrocks fcitx-bin is only in the -live seed for ubuntu.
<flexiondotorg> Where as I have it in the core package.
<alkisg> Laney: in the process of troubleshooting, I removed fcitx-bin, which also removed the mate-core metapackage, I can reinstall it and check
<flexiondotorg> So maybe all that is required is for Ubuntu MATE to move fcitx-bin into live.
<happyaron> didrocks: well it's now using xkbcommon and should not have the problem of behaving differently to ibus
<didrocks> happyaron: seems alkisg triggered some issue, I guess it worths a deep look
<happyaron> Laney: that was fixed in debian yesterday, will syncpackage to Ubuntu today
<happyaron> didrocks: will do
<anestis> Laney: (this is alkisg on a client's pc): yes: fcitx-bin: /etc/xdg/autostart/fcitx-autostart.desktop
<anestis> fcitx-bin      1:4.2.9-2
<Laney> so I think with the next upload this will be removed and hopefully the bug won't happen for you any more
<Laney> try removing it and restarting your session to see if no fcitx resolves the issue
<Laney> but from what happyaro_n said it shouldn't happen anyway...
<Laney> ho hum
<alkisg> Removing fcitx does resolve the issue
<alkisg> Thank you, I will test with newer images and report back
<alkisg> I'll also test with the unity image, e.g. if we can't type our names in the installer it will be an issue...
<alkisg> (i.e. if fcitx-bin is installed in the live image)
<happyaron> don't have syncpackage command on this remote console, it's already handled in -3 at Debian
<Laney> alkisg: try removing just that desktop file
<alkisg> Hmmm I'm missing something... fcitx-bin 1:4.2.9-2 ==> `dpkg -L fcitx-bin | grep autostart` says that /etc/xdg/autostart/fcitx-autostart.desktop is there on one pc, and it isn't there on another...
<alkisg> Maybe a package update happened without a version number bump?
<Laney> It's deleted in that upload but the code to remove the file from upgrading systems was forgotten
<Laney> that's what he handled in -3
<alkisg> Gotcha :)
<cjwatson> package updates without version number bumps aren't possible anyway
<alkisg> Well, dpkg -L produces different results with the same dpkg -l version number
<cjwatson> right, but as Laney says that's due to buggy conffile removal, not because there were two different packages with the same version number
<alkisg> Ah, dpkg -L lists older conffiles that are not inside the .deb, I didn't know that, sorry
<flexiondotorg> Laney, Is that fcitx-bin package sync/update going to happen and the images respun?
<Odd_Bloke> cjwatson: Is there a way I can set up a VM that will behave the same as the Launchpad build slaves?  I'm still trying to get to the bottom of this disk image/loop device issue.
<Laney> flexiondotorg: It's an upgrade issue only, so not really interesting for images
<Laney> indeed systems installed from the beta images won't have the problem
<flexiondotorg> Laney, Ah, great.
 * alkisg waves, bb with info about the live session etc later on. Thanks all! :)
<cjwatson> Odd_Bloke: so, I'm also still trying to get to the bottom of it (along with everything else), but the VM I set up fails in a different and earlier place ...
<cjwatson> + umount chroot/root/config
<cjwatson> umount: chroot/root/config: umount failed: No such file or directory
<cjwatson> haven't got to the bottom of that yet
<cjwatson> Odd_Bloke: I mean, in theory it's https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally and you can start with a cloud image, which is what I did
<cjwatson> and I grabbed a wily amd64 chroot
<cjwatson> Odd_Bloke: I'm still working on it though
<Odd_Bloke> cjwatson: OK, cool; I've just noticed that there is a 'sync' switch on kpartx (that isn't documented in the manpage: bug 1298292) that waits until the partitions are created, so I'm building a livecd-rootfs that uses that to see if it makes any difference.
<ubottu> bug 1298292 in multipath-tools (Ubuntu) "Missing -s option in kpartx's manpage" [Medium,Triaged] https://launchpad.net/bugs/1298292
<cjwatson> Odd_Bloke: oh, I even read the source and looked for that
<Odd_Bloke> We aren't using it when we do stuff on our Jenkins instance in kvm, but maybe it's just a timing problem that this will work around.
<cjwatson>         if (!udev_sync)
<cjwatson>                 dm_udev_set_sync_support(0);
<cjwatson> that could certainly be very relevant
<cjwatson> I didn't notice it because the cookie stuff further down looked unconditional
<jamespage> cjwatson, are you aware of any issues in debian infrastructure that might be causing uploads done in the last 24 hrs or so in Debian to not be noticed?
<jamespage> tracker, rmadison, launchpad are all stale compared to ftp.debian.org
<Laney> jamespage: There was a bug in mirrors being updated
<Laney> I just asked in #debian-mirrors
<Laney> Supposed to be fixed nowish
<jamespage> ack
<cjwatson> Odd_Bloke: sorry for the build delay, it's almost there now - there's an outage somewhere in the scalingstack infrastructure, reported
<Odd_Bloke> cjwatson: No worries. :)
<pitti> apw, infinity, Laney: FYI, first stabs at live test logtail: http://autopkgtest.ubuntu.com/running.html
<pitti> page updates every 10 s (not by itself yet)
<alkisg> didrocks, flexiondotorg, happyaron, Laney, I tested with the today's ubuntu wily unity i386 daily build, and while fcitx-bin was there in the live session, the autostart file wasn't there, so I didn't have a problem with that and the greek keyboard layout. So the problem I reported has already been tackled, thank you very much.
<alkisg> The problem with unity-settings-daemon breaking the keyboard layout is still there, but that has been the case since 12.04, even with the dozens of bug reports filed for that, so I don't think that will be as easily fixed... let's hope it'll be fixed for 16.04. :)
<pitti> apw, infinity, Laney: notice the amazing design, I spent two days on this!
 * pitti adds a refresh header
<Laney> pitti: handy
<Laney> Do you store the full log as you go or just the tail?
<pitti> Laney: just the tail
 * Laney nod
<pitti> Laney: right now the last 1 kB
<pitti> I should probably bump that a bit
<Laney> I was thinking of the way jenkins does it
<pitti> Laney: well, I'd like to cap it a bit -- unlimited seems gross, as logs can sometimes get GBs
<Laney> but anyway, this is cool - thanks
<pitti> maybe 10 kB is right
<pitti> Laney: there is lots missing there -- log size, design, auto-refresh, proper configuration, etc.
<pitti> it's mostly just a prototype
<apw> pitti, interesting
<Laney> integration with the package page I suppose
<pitti> libpng finished, I'll restart some new ones
<pitti> Laney: that too
 * pitti enables that for arm/ppc too
<seb128> pitti, do you know if https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1441008 is an issue with the avahi systemd unit or a systemd issue?
<ubottu> Launchpad bug 1441008 in avahi (Ubuntu) "under systemd avahi-daemon doesn't stay disabled when .local is detected" [Medium,Confirmed]
<pitti> seb128: (meeting, bbl)
<seb128> pitti, no hurry, enjoy!
<pitti> seb128: replied to the bug
<seb128> pitti, thanks
<sil2100> pitti: argh, almost forgot to poke you - the langpacks look fine :)
<sil2100> pitti: you can enable the weekly runs of the job
<Unit193> infinity: I presume you didn't see my openbox debdiff? ;P
#ubuntu-devel 2015-09-25
<pitti> Good morning
<LocutusOfBorg1> hi pitti !
<dholbach> good morning
<FourDollars> Could you help to review my merge proposal at https://code.launchpad.net/~fourdollars/ubuntu/wily/libmbim/1441095/+merge/272352?
<FourDollars> cyphermox: Hi
<seb128> FourDollars, he's in Canada and probably sleep, it's 4am in his tz
<FourDollars> seb128: OK. XD
<FourDollars> seb128: Could you help to review https://code.launchpad.net/~fourdollars/ubuntu/wily/libmbim/1441095/+merge/272352?
<seb128> FourDollars, get it in the sponsoring queue and somebody is going to review it
<FourDollars> seb128: OK
<seb128> FourDollars, I can but probably not today, I'm going to have a look on monday if nobody does before
<seb128> has that been sent to upstream?
<FourDollars> seb128: Yes, just reviewed and accepted by the upstream yesterday.
<FourDollars> seb128: It is the latest piece for https://bugs.launchpad.net/bugs/1441095 on wily.
<ubottu> Launchpad bug 1441095 in OEM Priority Project "novatel: improve probing for Dell branded modems" [High,In progress]
 * xnox feels cheeky =)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1448879
<ubottu> Launchpad bug 1448879 in network-manager-strongswan (Debian) "[regression] network-manager-strongswan configuration GUI broken" [Unknown,New]
<dupondje> could somebody check this and upload the patch or at least reopen the bug? :)
<dupondje> A new sync from debian was requested, but in the meantime there was a patch added in ubuntu, this one was not included anymore :(
<rbasak> cyphermox: ^^
<rbasak> dupondje: you can reopen the bug yourself.
<rbasak> dupondje: you should send the patch to upstream if you haven't already. That will help prevent future regressions.
<mapreri> can I ask for a syncpackage now or is already too late?  #1487031 is a pretty annoying bug and since the last upload is the only relevant change.
<mapreri> (sorry, I manged to upload that package only yesterday :| but would be sad if wily shipped a scribus package bugged like that
<cjwatson> mapreri: looking
 * mapreri notices ubottu does not reply with just the bug number...
<mapreri> cjwatson: thanks :)
<cjwatson> hm, are Debian mirrors still sad I wonder?  the import hasn't picked that up yet
<mapreri> cjwatson: should be fixed by now already
<cjwatson> bzzt
<cjwatson> mapreri: can you keep an eye on https://launchpad.net/debian/+source/scribus occasionally and ask when it notices this version?  I'll see if I can work out what's wrong here
<mapreri> cjwatson: i have to leave in ~30 minutes and will be back tonight, but sure, I can look and repoke as soon as i notices the new version there
<cjwatson> [ 27%] Getting: dists/sid/contrib/source/Sources.diff/2015-05-23-0906.09.gz      #** GET http://ftp.debian.org/debian/dists/sid/contrib/source/Sources.diff/2015-05-23-0906.09.gz ==> 404 Not Found
<cjwatson> why on earth is our mirror trying to fetch a pdiff that old
<cjwatson> oh it's still listed in Index
<cjwatson> so yeah, I call this ftp.debian.org still being sad
<mapreri> oh, guess that might explain why it's not updated :>
<cjwatson> but this is true on coccia too
<mapreri> btw i don't recall such particular problem being reported on #-ftp
<mapreri> cjwatson: oh, btw, the pgreplication is broken, so dak on coccia is not really up-to-date, dunno whether this means something (don't think so, but i want you aware)
<cjwatson> thanks, I don't think that's relevant here though
<cjwatson> reported on -ftp
<mapreri> yeah, saw
<mapreri> thanks for taking care of this
<cjwatson> np.  I think that's as much as it's possible for us to do atm
<cjwatson> though we could switch to --diff=none for our mirror
<cjwatson> wgrant: ^- do you think that would be reasonable?  we should have plenty of bandwidth to ftp.debian.org, it's only every six hours, and it would make us less vulnerable to this kind of nonsense
<StevenK> cjwatson: I thought iron was configured to use ftp.uk.debian.org
<StevenK> If indeed, iron is still where gina runs
<mapreri> cjwatson: if you happen to find a way to sync that this I'd also welcome a sync for src:sigil ;)  (another minimal upload to fix an annoying thing)
<wgrant> StevenK: It is.
 * mapreri leaves, good work! :)
<wgrant> cjwatson: Sounds fine to me, it's not deliberately using pdiffs.
<cjwatson> StevenK: switched back to ftp.debian.org a while back for some reason I don't immediately remember
<cjwatson> probably ftp.uk was broken at the time
 * cjwatson RTs --diff=none
<jamespage> cjwatson, wgrant: the lack of visibility into debian is really blocking our openstack rc1 liberty process atm as we're doing deps directly into debian experimental with zigo
<wgrant> jamespage: https://rt.admin.canonical.com/Ticket/Display.html?id=85018
<jamespage> wgrant: is it ok to pull the source packages directly from ftp.debian.org, test and then sign and upload to wily
<jamespage> ?
<wgrant> Oh, taken two minutes ago.
<wgrant> jamespage: With a bit of luck this will be fixed within the hour.
<cjwatson> jamespage: we'd rather you didn't, we should have this fixed soon
<jamespage> ok holding fire then
<zigo> cjwatson: Phil's ftp.uk is quite often broken... :P
<dupondje> rbasak: I can't reopen the bug .. its greyed out here :)
<dupondje> also its already reported upstream (aka in debian)
<rbasak> dupondje: I mean further upstream - looks like the strongswan project itself.
<cjwatson> jamespage: that should all be sorted for you now
<jamespage> cjwatson, thankyou
<cjwatson> mapreri: synced scribus and sigil for you
<ogasawara> stgraber: hi friend :)  so our usual AA suspects are away and we were hoping you might be able to help us get DPDK accepted out of the new queue for Wily.  This is in regards to bug 1487538.
<ubottu> bug 1487538 in Ubuntu "Add dpdk to wily universe" [Wishlist,New] https://launchpad.net/bugs/1487538
<ogasawara> smb, arges: ^^ fyi
<stgraber> ogasawara: kinda stuck in meetings today, so probably not today, can look at it next week if no AA with existing DPDK knowledge shows up
<ogasawara> stgraber: awesome, thanks
<hallyn> xnox: https://mentors.debian.net/package/netcf   don't suppose there is any chance i got the symbols file right?
<smb> stgraber, that would be something jamespage would appreciate, too :)
<jamespage> ogasawara, stgraber: eek - I also asked slangasek in -release
<jamespage> I'll also have a openvswitch-switch-dpdk package to follow to provide a dpdk enabled ovs for universe
<jamespage> working that now
<ogasawara> jamespage: heh, sweet.  I was going to harass him on Mon too as he's away on holiday this week.
<jamespage> ogasawara, ack
<xnox> hallyn: looks very nice!
<hallyn> phew
<hallyn> my hope was: there's no new symbols, and private symbols need to be updated...
<mdeslaur> xnox: is the fastboot stuff in usb-creator still useful in any way?
<mdeslaur> cyphermox: ^
<cyphermox> I never saw fastboot stuff in usb-creator?
<cyphermox> you mean fastboot as the android flashing tool?
<mdeslaur> cyphermox: yeah, the android option is called --fastboot
<cyphermox> never saw it. I wouldn't know. Is it because you want to remove it?
<mdeslaur> maybe
 * mdeslaur sharpens axe
<infinity> mdeslaur: I would assume it's been superseded by ubuntu-device-flash, but maybe someone like ogra would better know the history?
<ogra_> yeah, not needed anymore
<mdeslaur> cool, thanks
<ogra_> cyphermox, it was added for the enxus7 desktop imaes we built before touch existed
<ogra_> *nexus7
<cyphermox> ah
<xnox> mdeslaur: i believe it has never been used.
<xnox> infinity: cyphermox: mdeslaur: i've implemented that in-parellel to ubuntu-device-flash because PS at the time had that all secret, whilst UE was working on nexus7 tablet desktop.
<mdeslaur> xnox: ok, thanks
<xnox> well i used it =)
#ubuntu-devel 2015-09-26
 * doko welcomes Laney into the club of empty library package uploaders
<mapreri> cjwatson: â¥ thanks very much!
<ogra_> cjwatson, hmm, i have some weird differentce in building snaps locally vs building them on LP (http://paste.ubuntu.com/12573213/ vs https://launchpadlibrarian.net/218891649/buildlog_snap_ubuntu_vivid_amd64_wget_BUILDING.txt.gz both install different sets of packages for the same snapcraft.yaml) ... what would i file that against, snappy or LP ?
<ogra_> s/snappy or/snapcraft or/
<cjwatson> ogra_: I *think* that's snapcraft's fault for not explicitly setting whether it wants to follow Recommends or not
<ogra_> yeah, smells a bit like recommends
 * ogra_ will file against snapcraft 
<cjwatson> ogra_: The difference is whether it follows wget Recommends: ca-certificates
<ogra_> ah
<cjwatson> And it doesn't set it explicitly, so it depends on the apt environment it's run it
<cjwatson> *run in
<ogra_> yeah
<tsimonq2> hello ogra_, I remember you from the snappy open house
<ogra_> :)
<tsimonq2> ogra_: That open house is what really showed me that anybody can be part of a team, and that is what got me started with where I am. I currently do QA and soon Development for Lubuntu. Pass along a thanks for me, as that really showed me the way.
<ogra_> this is awesome to hear :)
<tsimonq2> ogra_: If you wanna have a somewhat informal chat, I am either in ##tsimonq2, #lubuntu-offtopic, or #phillw. Don't be afraid to stop by either of those and say hi! :)
<infinity> doko: It's a pretty exclusive club.  Which library did he break? :)
<doko> socket++
<Laney> pfft, gcc5 uploads, nothing *real* then :)
<NikTh> apw: ping
<NikTh> Hello, how I can build only one flavor regarding a .deb kernel package via launchpad ? I'm using git to configure the kernel, I have created a new flavor , I can build this flavor without problems, but I cannot exclude any other(flavor).
<NikTh> My propose is to minimize the building time, by removing any not required flavors.
<NikTh> I have removed some files from debian.master/config , debian.master/control.d/, also modified debian.master/rules.d/amd64 and i386,  but apparently this is not the right way. I guess I need to modify some scripts as well, but I don't know what scripts.
<NikTh> Here is a build fail log that might help: https://launchpadlibrarian.net/218918782/buildlog_ubuntu-trusty-amd64.linux_4.2.1-999.2015Sep26_BUILDING.txt.gz
<TJ-> NikTh: I usually use something like: "fakeroot debian/rules skipabi=true skipmodules=true flavor=lowlatency binary"
<NikTh> TJ-:  Thanks for answering. I have already configured these parameters inside amd64.mk and i386.mk . There is no problem with abi and modules. Where can I configure the flavor ? I'm not using this command, I'm building the appropriate files and upload them in launchpad.
<TJ-> NikTh: you'd need to grep for it then; I build the packages to ensure the entire process is successful
#ubuntu-devel 2015-09-27
<hallyn> hm, so what is the briefest recommended way to check whether a service is running from a script (preinst actually)?  I guess 'service <service> status | grep -q running'?
<hallyn> (in systemd you can just check return value of service $service status, but not in upstart)
<TJ-> hallyn: isn't there an initctl option with upstart? I seem to recall something
<hallyn> TJ-: yeah but not with systemd
<hallyn> i'm looking for one cmd to work anywhere.
<hallyn> heck i don't know what 'service libvirt-bin status' will do on sysvinit offhand
<TJ-> I can't help with libvirt-bin, but on 12.04 I see this:
<hallyn> my concern with service x status | grep running is that 'running' might show up inthe fail log for x
<TJ-> service tomcat7 status
<TJ->  * Tomcat servlet engine is running with pid 5618y
<hallyn> right, but if it's not running, then "service tomcat7 status && echo running" will show "running" right?  whic his different from with systemd
<TJ-> Yeah; service/initctl return 0
<hallyn> so i might just have to use a helper which checks whether upstart is init.  but i'd like to avoid that
<TJ-> I'm sure I found a tool that changes exit value
<TJ-> probably it was for sysvinit
<hallyn> actually now i'm second-guessing what i'm doing it all.  this is something to think about inthe morning, not sat night.  thanks for rapping :)
<hallyn> hm, when is hte next freeze?
<hallyn> phew, oct 8 looks like
<jtaylor> the installer now downloads prop. graphics drivers before starting to work?
<jtaylor> besides that I have not been asked about that, it also downloads for 10 minutes without any feedback
<jtaylor> giving the impression that its stuck
<NikTh> apw: ping
<node1_>  hi , can anybody guide me how is archlinux  created ? I have read linux from scratch , and want to see the same process for Ubuntu ... thanks
<cjwatson> You'd have to ask an Arch channel how Arch Linux is created.
<eliasps> Hey, can anyone help me in uploading a package? I am at the step where I have run debdiff. Do i need to change anything in the files?
<node1_> please let me know how is ubuntu linux created .... from scratch
<Inoki> Hey everyone, I'm dabbling a bit in code for a VPN reconnect script. This is my first attempt and I would love if someone could have a look and tell me if I got it right http://pastebin.com/MNniCb6u
<cjwatson> node1_: Perhaps https://wiki.ubuntu.com/UbuntuDevelopment is the best place to start for open-ended questions like that
<mapreri> so, I'm about to upload a package (scribus) to debian sid.  is there a way to "be sure" nobody is going to sync it?  it's somewhat experimental (but not so experimental to deserve a exp upload), and even if it might very well fix something I'd prefer a stable thing like wily not to ship it.
<cjwatson> mapreri: I can put it on the sync-blacklist
<cjwatson> mapreri: is it safe to say it can be unblacklisted for the X cycle?
<mapreri> cjwatson: yeah, sure
<TJ-> Any ubiquity experts around can look at bug 1500110 ?
<ubottu> bug 1500110 in ubiquity (Ubuntu) "mount point /tmp/tmp.${RANDOM}/var does not exist" [Undecided,New] https://launchpad.net/bugs/1500110
<cjwatson> mapreri: done
<mapreri> cjwatson: â¥ this week you're saving my days :)  guess just for this you gained a beer at the next DC :)
<mapreri> do i need to poke somebody to get it removed once wily's out?
<cjwatson> mapreri: heh.  it won't be removed automatically - somebody may notice, or there's an outside chance I'll remember, otherwise poke somebody
<cjwatson> mapreri: or you could set up an at job to mail me :)
<mapreri> or I could try to break lp, till I get access to the ubuntu archive and sync it myself :>
<mapreri> cjwatson: ok, I'm pretty sure I'll notice there is something wrong and remember this :)  which team is managing that list?
<cjwatson> mapreri: ~ubuntu-archive
<mapreri> ack
<kees> cjwatson: say, do you have any idea how these got linked? (and how to unlink them?) https://launchpad.net/freediag/+packages (freediag != scantool)
<kees> it does weird things like shows freediag's project description on the ubuntu scantool package page, etc.
<mapreri> kees: there is '-' sign on the right?
<mapreri> kees: also, you can go https://launchpad.net/ubuntu/utopic/+source/scantool and hit the same sign
<kees> mapreri: sure, but how did it _happen_? (will it happen again by the same means after I click the '-', etc?)
<mapreri> the thing is, everybody (i think) can link them
<kees> right
<kees> I assume it's related to freediag's binary being named "scantool"
<mapreri> that doesn't help make things clear ;)
<cjwatson> yeah, a lot of people can link them
<cjwatson> let me unlink
<kees> well, freediag isn't in ubuntu, which is funny
<cjwatson> kees: is the Debian diagnostics package also unrelated?
<mapreri> cjwatson: "a lot" => ?
<cjwatson> er let me unlink these first and then check
<mapreri> sure
<cjwatson> but generally it's in the category of things that LP makes fairly open to encourage people to garden it (decision from waaaay before my time)
<kees> cjwatson: I think so, but I'll check
<kees> I only noticed because the freediag author contacted me, confused about ubuntu and scantool
<cjwatson> ha, look at https://launchpad.net/ubuntu/+source/scantool now
<cjwatson> the suggestion is probably there because of scantool in the description, I'm guessing
<mapreri> [09:06:33 PM] <kees> I assume it's related to freediag's binary being named "scantool"
<cjwatson> yes I don't agree with that being likely
<cjwatson> description is more likely to be a thing LP has noticed
<cjwatson> again, will check in a moment
<cjwatson> (OK, the description is because the binary is named scantool; what I mean is that LP is not going to have been hunting about in branches or tarballs or whatever for names to suggest)
<kees> looks like "diagnostics" is a third scanning tool unrelated
<cjwatson> right, +edit-packaging is literally usable by anyone who's logged in
<mapreri> that's open!
<kees> cjwatson: thanks for poking at it! :)
<cjwatson> and basically what the suggestion widget does is the equivalent of https://launchpad.net/projects/+index?text=scantool
<cjwatson> so I think the suggestion makes sense but it's unfortunate there's no way to blacklist
<NikTh> Hello, any kernel maintainer here? I want to achieve something but I'm following the wrong direction, pretty sure about that. :)
<eliasps> Guys, how can I sent a package to a ppa that I dont have upload rights for sponsorship/upload?
<ogra_> you ask the owner
<eliasps> ogra_ thank you.
#ubuntu-devel 2016-09-26
<tsimonq2> is there a list of packagesets and packages that belong to those packagesets somewhere?
<tsimonq2> I also wonder if I can use the Launchpad API to look at that...
<pitti> Good morning
<Unit193> Howdy.
<pitti> apw: FYI, I reopened bug 1626436, -17 still boots a lot slower than 4.4 and with high loads; although a lot less severe than the previous -14
<ubottu> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436
<didrocks> good morning pitti!
<pitti> bonjour didrocks, Ã§a va ?
<didrocks> pitti: Ã§a va bien, et toi ? :)
<pitti> didrocks: je vais bien aussi; salutations de Berlin, je reste chez larsu :)
<didrocks> pitti: oh, c'est vrai ! Dis-lui bonjour de ma part :)
<pitti> didrocks: je vais le faire, merci ! (il encore dort)
<pitti> happyaro1, cyphermox: I didn't get around to creating a NetworkManager DNS plugin for resolved this cycle, got diverted by too many other things; at this point I'd just revert NM back to using dnsmasq, like we had before; is that ok for you?
<tsimonq2> pitti: morning, could you please take another look at https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html ?
<tsimonq2> (afair you said you would take a look today)
<sil2100> cjwatson_: hey! I was wondering - there's such a strange situation we have right now in -proposed, ubuntu-keyboard 0.100+16.10.20160921-0ubuntu1 is there but the binary for ubuntu-keyboard-data for this version is not, even though it was not removed or anything
<sil2100> cjwatson_: tested in an yakkety-proposed amd64 chroot with apt-cache policy and even launchpad acts strangely here
<sil2100> https://launchpad.net/ubuntu/yakkety/+package/ubuntu-keyboard-data <- this only shows the old version
<sil2100> https://launchpad.net/ubuntu/yakkety/+package/ubuntu-keyboard <- while here's the main ubuntu-keyboard binary from -proposed
<sil2100> cjwatson_: do you know what could be the cause of it?
<sil2100> cjwatson_: does it mean someone removed the binaries from -proposed?
<cjwatson_> https://launchpad.net/ubuntu/yakkety/amd64/ubuntu-keyboard-data is more useful
<cjwatson_> that says it was superseded by ubuntu-keyboard 0.100+16.10.20160921-0ubuntu1
<cjwatson_> er, wait, what
<cjwatson_> this may have been a race of some kind, let me dig through logs a bit
<sil2100> Strangeness I see, 0.100+16.10.20160921-0ubuntu1 should have ubuntu-keyboard-data but it doesn't, even though on the LP build page I see it being generated
<sil2100> This also basically blocks ubuntu-keyboard and unity8 in -proposed
<sil2100> Since, yeah, the autopkgtests can't run since it can't install ubuntu-keyboard-data for the -proposed ubuntu-keyboard, since the binaries are not there! ;)
<cjwatson> there are two copy records here which suggests something like a double-override accident
<sil2100> uh, sounds scary
<sil2100> Thanks for looking into that!
<Mirv> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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 | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots: Mirv
<cjwatson> certainly seems to have been copied rather a lot
<cjwatson> celeryd-production_launchpad_job.log-20160923.gz:[2016-09-22 15:37:07,396: INFO/Worker-1] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33200448) in status Waiting
<cjwatson> celeryd-production_launchpad_job.log-20160923.gz:[2016-09-22 22:45:27,787: INFO/Worker-2] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33204726) in status Waiting
<cjwatson> celeryd-production_launchpad_job.log-20160924.gz:[2016-09-23 23:46:15,121: INFO/Worker-1] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33200448) in status Waiting
<cjwatson> celeryd-production_launchpad_job.log-20160924.gz:[2016-09-23 23:46:16,081: INFO/Worker-3] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33204726) in status Waiting
<sil2100> Oh!
<sil2100> I think I was doing the copy, and I remember that it hanged on the last package
<sil2100> Like, the copy-package script
<sil2100> I think I aborted and re-run again, but that should cause 2 copies at max I guess?
<sil2100> Since the bileto publish job was busted I had to publish some packages manually through copy-package
<cjwatson> the first two of those copies were suspended, i.e. held in UNAPPROVED
<sil2100> (I feel so bad since it might have been me that busted things)
<cjwatson> so I think you did a double copy, both ended up in the queue
<cjwatson> then when they were accepted, two copies of the same package were accepted simultaneously (literally - two celery workers were processing those two copies in parallel)
<cjwatson> and our locking isn't always what it could be
<cjwatson> so, easy to fix, I'll just copy it over itself
<cjwatson> done, should hopefully sort itself out in a bit
<sil2100> cjwatson: thanks!
<sil2100> Sorry for the commotion, I didn't know if the first run copied everything since it seemed hanged so I preferred to just do a second copy, as I didn't expect it to cause two entries in UNAPPROVED
<sil2100> Now I know it's not so low-risk as I thought it is
<ogra_> oh man ...
 * ogra_ has a failed 14.04 -> 16.04.1 server upgrade and in the middle of sending the error report lp goes down ... 
<ogra_> must be my lucky day
<ogra_> sigh
<Laney> no bug here, move along
<ogra_> oh man
<ogra_> ogra@aleph:~$ sudo reboot
<ogra_> sudo: reboot: command not found
<ogra_> that ugrade went *really* wrong
<ogra_> (it tried to do a lot of insserv stuff, re-ordering sysv scripts and so on ... )
<ogra_> hmm, not even remotely a trace of systemd on that machine ...
<ogra_> thats rather unexpected ... specifically since i used do-release-upgrade
<Laney> Anyone know of a dpkg gotcha when replacing directories with symlinks? https://paste.debian.net/841984/
<Laney> It becomes an empty directory instead of a symlink
<Laney> Do I have to do it in postinst?
<jamespage> Laney, I think there is a helper todo that
<cjwatson> Laney: Yep, that's standard.  dpkg-maintscript-helper can help
<cjwatson> (via dh_installdeb, probably)
<cjwatson> dir_to_symlink
<Laney> aha
<Laney> Not sure I've come across this particular one before
<Mirv> sil2100: are you landing the ubuntu-touch-meta part of bug #1625023 ? (asking with my patch pilot hat on)
<ubottu> bug 1625023 in Canonical System Image "switch to systemd on ubuntu phone xenial" [Critical,Confirmed] https://launchpad.net/bugs/1625023
<cyphermox> pitti: no objections
<Mirv> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | 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 | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
<sil2100> Mirv: yeah, I'm on it
<sil2100> Mirv: for now no action required there, we'll do the switch in the nearest days
<Mirv> sil2100: ok
<ogra_> oh sigh
 * dholbach hugs Mirv 
<ogra_> pitti, so i just had my server eat itself completely doing a 14.04->16.04.1 do-release-upgrade ... i now have a ton of insserv complaints every time i use apt ... systemd wasnt installled at all ... grub ended up with only memtest in it ...
<ogra_> pitti, can i just purge insserv ? iirc we dont need it
<ogra_> (i just manually installed grub and systemd so i got at least back to ssh support)
 * ogra_ thinks that was the worst ubuntu expirience he had yet ... just using official tools :(
<pitti> ogra_: hm, you can purge insserv in 16.10, but not yet in 16.04; what did it say? some broken sysv script somewhere without LSB headers?
<ogra_> pitti, about 200 lines every few seconds ...
<ogra_> yeah, LSB header noise
<ogra_> now that i got back to a working system (after installing grub by hand from an old 11.04 CD i had around since mini.iso from USB was to new for the BIOS on that old iron) i just noticed that dist-upgrade wants to still upgrade ~600 packages
<ogra_> so i guess the insserv thing was caused by a half upgraded system ... i'll see that i get to normal first
<ogra_> still pretty bad that do-release-upgrade can get you into such a state
<pitti> Launchpad, where are thou
<caribou> This may sound as a silly question, but what is the normal procedure to generate a _sources.changes file for a debian native package ? dpkg-genchanges -S ?
<LocutusOfBorg> caribou, yes, I do that usually
<LocutusOfBorg> actually -S -d
<LocutusOfBorg> :)
<LocutusOfBorg> and -sa when needed
<caribou> LocutusOfBorg: good, thanks!
<LocutusOfBorg> yw!
<Mirv> sitter: note that this is coming from snappy newbie who is mostly having fun and learning the tool, but I started with https://github.com/tjyrinki/qt-ubuntu and it's available in edge channel (just not sure if any useful at the moment for anything). my main wish is to have a snap that contains the Qt as known in Ubuntu world (hence, "qt-ubuntu"), with all the patches we've wanted to cherry-pick or
<Mirv> backport for our products.
<cjwatson> pitti: network failure
<ogra_> stuck in the cable ?
<sitter> Mirv: seems reasonable. for KDE the current plan (really just vision) is to have an own Qt though to tighter control patches etc.
<Mirv> sitter: right, mine can also be called mostly a vision at the moment. it's really up to how will the eventual needs seem to be - snap does allow a lot of flexibility in all directions, meaning not everyone needs to use the common one, but still eg snapcraft work can be shared
<sitter> Mirv: agreed
 * ogra_ glares at his sever removing config files for usplash 
<ogra_> hmm, i knew this install was old ... i wasnt aware *how* old actually
<bdmurray> flexiondotorg: Is there a reason you mark bugs like bug 1601874 as Incomplete?
<ubottu> Error: Could not gather data from Launchpad for bug #1601874 (https://launchpad.net/bugs/1601874). The error has been logged
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<flexiondotorg> bdmurray, When LP comes back I'll take a look.
<ogra_> oooh ... LP is back (at least for the bug i just reloaded)
<pitti> -ish (slow, but stuff is coming through)
<pitti> smoser:
<pitti> +Before=NetworkManager.service
<pitti>  Before=network-pre.target
<pitti> smb: that's a no-op and looks like some red herring
<pitti> smb: ifupdown, NM, networkd, and similar things all run after network-pre.target (that's its purpose)
<smb> smoser, ^
<pitti> sorry, smoser ^
<smoser> pitti, added for redhat
<smoser> as you say, shoudl be a noop
<smoser> right?
<pitti> smoser: oh, is their NM not doing After=network-pre.target?
<smoser> i think that network-pre.target is an ubuntu-ism, no?
<pitti> no
<pitti> both the target and NM.service are the upstream units
<pitti> we don't have ubuntu specific targets
<pitti> (well, in the systemd package -- obviously there are some from packages like cloud-init)
<smoser> hm..
<smoser> pitti, how'd you see this ?
<pitti> smoser: doing yakkety unapproved queue review
 * pitti felt like some punishment in the evening before dinner :)
<pitti> also, the DC is coming back, so catching up with stuff
<smoser> yea
<pitti> smoser: so, as this shuldn't be different in RH I was just curious what it should do, and if there maybe is some "real" bug somewhere
<smoser> pitti, want to join #cloud-init and see if harlowja will respond ?
<smoser> he is who did this, and uses cent.
<pitti> smoser: done; I'll be AFK for dinner RSN, but I'll get backscroll
<nacc> coreycb: fyi, ftfbs from doko's last e-mail for cinder, I think it's because you need a build-dep on python-pep8 or python3-pep8 for the tests?
<nacc> coreycb: https://launchpadlibrarian.net/285536781/buildlog_ubuntu-yakkety-amd64.cinder_2%3A9.0.0~b2-0ubuntu1_BUILDING.txt.gz
<coreycb> nacc, I think that is fixed by rc1 which is in proposed
<nacc> coreycb: ack, thanks!
<coreycb> nacc, yw, it is great when things are already fixed :)  btw that is stuck in proposed based on a few dependencies we're fixing up.
<nacc> coreycb: np, i'm just trying to keep an eye on the  ubuntu-server ftbfs list
<smoser> pitti, i would like your opinion on https://bugs.launchpad.net/ubuntu/+source/gce-utils/+bug/1627789
<ubottu> Launchpad bug 1627789 in gce-utils (Ubuntu) " ordering cycle prevents google-startup-scripts from running" [High,Triaged]
<nacc> doko: for the ftbfs for libecap, i think the 3 symbols mentioned in https://launchpadlibrarian.net/285536159/buildlog_ubuntu-yakkety-i386.libecap_1.0.1-3ubuntu3_BUILDING.txt.gz (same for all the arch's build logs) are no longer present. `pkgkde-symbolshelper` parsing the build-log as input does seem to want to just elide those 3 -- but I'm inexperienced in this area?
<bdmurray> flexiondotorg: so about bug 1601911 - why is it incomplete?
<ubottu> bug 1601911 in mate-menu (Ubuntu) "/usr/lib/mate-menu/mate-menu-config.py:11:g_type_check_instance_is_fundamentally_a:g_object_unref:model_free_row_data:model_update_current_folder:update_combo_box" [Undecided,Incomplete] https://launchpad.net/bugs/1601911
<flexiondotorg> bdmurray, Reagarding 1601874 you mentioned ealier, it is from an old package from a PPA.
<flexiondotorg> As for 1601911, I've never encountered it and can't reproduce it.
<bdmurray> flexiondotorg: bug 1601874 also occurered with version 16.04.9.1 which is the Xenial version of the package...
<ubottu> bug 1601874 in ubuntu-mate-welcome (Ubuntu) "/usr/bin/ubuntu-mate-welcome:11:_gtk_style_provider_private_get_settings:gtk_css_value_initial_compute:gtk_css_static_style_compute_value:_gtk_css_lookup_resolve:gtk_css_static_style_new_compute" [Undecided,Incomplete] https://launchpad.net/bugs/1601874
<bdmurray> flexiondotorg: I'm trying to understand why you marked a whole bunch of crash reports from the Error Tracker as Incomplete.  Its hard to tell just based off the bug.
<flexiondotorg> bdmurray, The rationale for marking those bugs incomplete is we've spent about 5 days testing Ubuntu MATE Welcome.
<flexiondotorg> The version in Xenial and the version we've been preparing for Yakkety.
<flexiondotorg> None of the team were able to excercise Ubuntu MATE Welcome is such a way to cause those errors :-(
<bdmurray> flexiondotorg: and what about engrampa or atril? e.g. this crash with 340 instances https://errors.ubuntu.com/problem/bf4ee7bcedb2e9da402d6486d69fe3cf5fc783f7
<flexiondotorg> bdmurray, I just requested access errors.ubuntu.com
<bdmurray> flexiondotorg: Maybe we should mark the bugs as New then, rather than causing them to expire in 60 days?
<flexiondotorg> bdmurray, Can you help me understand the correct way to interact with bugs I can't reproduce please?
<flexiondotorg> OK, I can mark them New.
<bdmurray> flexiondotorg: I think the first step would be to look at the crashes, let me give you access to errors.
<bdmurray> flexiondotorg: Can you access this now? https://errors.ubuntu.com/problem/bf4ee7bcedb2e9da402d6486d69fe3cf5fc783f7
<flexiondotorg> Yes. Excellent!
<bdmurray> flexiondotorg: So we can see a Stacktrace there which has details.  Those don't get put in the bug report since it might contain sensitive information.
<bdmurray> flexiondotorg: If you look at the Occurences table there are links to the individual crash reports e.g. https://errors.ubuntu.com/oops/2da4c81a-8358-11e6-8a94-fa163e30221b
<bdmurray> flexiondotorg: That contains the apport crash report information like ProcCmdline which might be useful in recreating the crash
<flexiondotorg> bdmurray, Thanks, this is great.
<bdmurray> flexiondotorg: the version table can also be useful in determining which releases are affected, however just because you don't see it affecting Yakkety doesn't mean it won't.  There aren't a lot of yakkety users yet.
<flexiondotorg> I thought I'd registered for errors before but that just let me manipulate the graphs.
<bdmurray> That doesn't require any special permissions.
<bdmurray> flexiondotorg: if you have any questions about the error tracker or feedback please let me know
<flexiondotorg> bdmurray, Will do.
<nacc> doko: looking at libpam-radius-auth ftbfs, but i'm not able to reproduce it.
<nacc> doko: nm, PEBKAC for libpam-radius-auth, would still appreciate your input on libecap
<nacc> doko: http://paste.ubuntu.com/23234756/ for libpam-radius-auth, does it look sane?
<doko> nacc: I'll NMU that to Debian too, fabbione package ...
<nacc> doko: ok
<nacc> doko: so you'll handle both libpam-radius-auth and libecap?
<doko> nacc: libecap, yes these destructor symbols are not part of the ABI
<nacc> doko: ack
<doko> nacc: are you able to upload libecap yourself? Not sure why we don't see that in Debian
<nacc> doko: yeah, i can
<nacc> doko: i just wanted to check with you first
<nacc> doko: http://paste.ubuntu.com/23234825/ ? also, do you normally file a bug for every ftbfs so it's clear what the failure was?
<doko> nacc: for Ubuntu? no, I gave up on this, because these bugs are then not rracked. maybe we should do that again for main for every package
<nacc> doko: i have been filing them for myself so i have a place to link the logs
<nacc> just wasn't sure if there as a 'best practice' already
<doko> nacc, ahh, libecap in debian doesn't have symbols file ...
<nacc> doko: yeah, i just realized it's a delta
<nacc> doko: did the above debdiff seem reasonable?
<nacc> i can upload now, if so
<nacc> doko: i noticed that with libpam-radius-auth, it's orphaned in debian and we're on a different upstrema there too
<jbicha> nacc: if you use the LP tag 'ftbfs', the bug will show up on http://qa.ubuntuwire.org/ftbfs/
<nacc> jbicha: yep, i realized that last night, so i've been modifying them :)
<nacc> doko: presuming you ack, i can upload both libecap and libpam-radius-auth for yakkety
<nacc> doko: ok, llvm-toolchain-3.6 now :) -- seems like gcc 6.1/6.2 isn't provide gcc-6.1/gcc-6.2, but gcc-6? so do we need to adjust that regex to be 5|6?
<nacc> http://paste.ubuntu.com/23234972/
<pitti> smoser: LP is oopsing on me again -- I guess I'll have a look tmw morning then
<smoser> pitti, fair enough
<smoser> thanks
<pitti> smoser: hmm, https://launchpad.net/ works, but https://launchpad.net/bugs/1627789 oopses
<ubottu> Launchpad bug 1627789 in gce-utils (Ubuntu) " ordering cycle prevents google-startup-scripts from running" [High,Triaged]
<pitti> smoser: can you open it?
<smoser> no. it had worked earlier today
<smoser> interestingly, the private one works :)
<pitti> smoser: https://bugs.launchpad.net/ubuntu/+source/gce-utils/+bug/1627789/+text also works -- I just cannot comment on that
<ubottu> Launchpad bug 1627789 in gce-utils (Ubuntu) " ordering cycle prevents google-startup-scripts from running" [High,Triaged]
<pitti> smoser: looks ok to me; probably all the cloud-init-ish stuff should perhaps rather be installed into cloud-init.target than multi-user, but surely fine for an SRU
<smoser> pitti, right, but i think they want to run even if cloud-init is not present.
<pitti> smoser: oh, ok; then that looks right
<doko> nacc: isn't 3.6 already fixed in Debian, and can be merged? but yes, this should be fixed the same way as in newer llvm's
<nacc> doko: i'll check
<nacc> doko: we're already merged to current llvm-toolchain-3.6 in debian
<nacc> afaict
<nacc> doko: it's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835582
<ubottu> Debian bug 835582 in src:llvm-toolchain-3.6 "llvm-toolchain-3.6: FTBFS with gcc-6" [Serious,Open]
<nacc> doko: fyi, +1 on the idea of auto-opening ftbfs bugs for packages in main
<lfaraone> is there anything I can do to help LP #1571456 (xenial SRU for glibc) get looked at? (waves at infinity :))
<ubottu> Launchpad bug 1571456 in glibc (Ubuntu Xenial) "id crashed with SIGSEGV in sock_eq()" [Medium,Triaged] https://launchpad.net/bugs/1571456
<Odd_Bloke> barry: doko: Any idea what the status of bug 1443704 is?
<ubottu> bug 1443704 in python2.7 (Ubuntu) "Support for TLS 1.2 not present (added in 2.7.9)" [Undecided,Confirmed] https://launchpad.net/bugs/1443704
<doko> nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838945
<ubottu> Debian bug 838945 in src:libecap "please incorporate some patches" [Normal,Open]
<doko> so once applied, this is syncable
<nacc> doko: ack, i'll watch for it
<nacc> doko: i went ahead and submitted the small patch for now, i hope that's ok -- and we can presumably sync once debian is updated
<doko> barry: dropped, because I never had the time to finish it. feel free to pick it up again, but then maybe with the package/version from xenial
<doko> Odd_Bloke: ^^^
<nacc> doko: mako is a debian bug as well (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830178)
<ubottu> Debian bug 830178 in src:mako "mako: FTBFS: ValueError: too many values to unpack" [Serious,Open]
<Odd_Bloke> doko: I'm asking for someone else at a sprint; what approach were you taking to make it work?
#ubuntu-devel 2016-09-27
<doko> Odd_Bloke: basically test building everything with a python dependency twice, once with the current packages, and the proposed packages, on all archs (but main only)
<doko> and then fixing things ...
<Odd_Bloke> doko: OK, cool.  Thanks!
<tsimonq2> http://askubuntu.com/questions/829652/build-my-own-ubuntu-iso - putting a bounty on it tomorrow if it doesn't get answered
<cjwatson> smoser: oh dear, that's a regression from my recent work, could you please file a bug against Launchpad itself about that?
<cjwatson> smoser: (that oops)
<barry> doko, Odd_Bloke i'll take a look tomorrow
<cjwatson> Mostly I think because DistributionSourcePackage.ensure doesn't create an in-DB DSP record for publications in partner, but we may also need to make sure that packages that haven't had a fresh upload since ~2010 have such records too.
<cjwatson> And definitely make that page not OOPS if there's no DSP, since after all the bugtask already exists.
<nacc> doko: just sent debian a potential fix for mako
<happyaron> pitti: it's fine for me, better if you can upload master to get 1.2.4 available in yakkety
<happyaron> (was on long flight
<happyaron> pitti: as for the 802.1x key issue I'm modifying the description as upstream expect only p12 being fixed, and open another report to track remaining stuff
 * mwhudson wonders about a 'maas' autopkgtest backend
<mako> nacc: mako is a debian bug?! ;)
<roaksoax> mwhudson: maas you say ?
<mwhudson> roaksoax: i did, but i am probably being silly
<roaksoax> mwhudson: hehe ok, just wondering what crossed your mind :)
<mwhudson> roaksoax: instead of pointing autopkgtest at nova, or qemu or schroot, why not a maas?
<pitti> happyaron: thanks! yes, I can upload 1.2.4 (but still frozen for beta); did you already test that version?
<nacc> mako: ha! didn't even try to tab-complete, I apologize if you got some random highlights there :)
<tjaalton> pitti: hi, do you have autopkgtest backport for xenial somewhere?
<tjaalton> or should I just install the yak version
<tjaalton> probably will upgrade to it soon anyway
<pitti> autopkgtest | 4.0.2~ubuntu16.04.1  | xenial-backports | source, all
<tjaalton> oh
<tjaalton> hehe
<pitti> tjaalton: it's not the very latest version, but it should do for most stuff
<tjaalton> cool
<pitti> but a good reminder to update it
<pitti> (also for trusty)
<tjaalton> i got confused with some documentation saying to run 'autopkgtest' while xenial had adt-*, and then read the blog post
<pitti> tjaalton: I uploaded 4.0.5 to t/x-backports now
<tjaalton> thanks
<mwhudson> pitti: is that tar: Unexpected EOF in archive in copyup thing still a mystery?
<pitti> mwhudson: yes, it is
<mwhudson> it's happened to me on more than half of my runs today
<pitti> two free beer for the person who debugs it :)
<mwhudson> so if there's anything i can do to help debug it i am (a) willing (b) apparently able
 * pitti ups the ante -- plus a free hug!
<mwhudson> pitti: hints at where to start? (for tomorrow)
<pitti> mwhudson: since this only happens with qemu, I suspect that there is some race condition/bug with the "9p" file system in qemu (setup_shared() in virt/autopkgtest-virt-qemu); this sets up a shared mount between the guest and the host for copying around packages, results, logs etc.
<pitti> mwhudson: and I use tar in between, as 9p sucks for lots of small files (it's liek 10x to 30x faster with a single big tar)
<mwhudson> pitti: i see
<pitti> mwhudson: that is done in lib/VirtSubproc.py, the copy_*
<LocutusOfBorg> sil2100, please ping if you work on filezilla
<LocutusOfBorg> s/ sil2100 / Adri2000
<LocutusOfBorg> or ack an upload, I already have imported it in my personal git repo
 * sil2100 does not ping
<sil2100> ;)
<sil2100> I am, however, working on the zeromq3 pyzmq autopkgtest failure however
<sil2100> uh
<sil2100> -however
<LocutusOfBorg> tumbleweed, can I ask you a few questions about this page? http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
<LocutusOfBorg> I'm listed with my nick and with my name-surname
<LocutusOfBorg> do you know why?
<LocutusOfBorg> my launchpad account has my debian email registered
<Adri2000> LocutusOfBorg: hi, you mean filezille for ubuntu?
<Adri2000> filezilla
<jtaylor> mwhudson: thanks for the docker update in xenial, seems to work in my (quite simple) setup
<mwhudson> jtaylor: glad to hear it
<jtaylor> have you looked at using the new --live-restore to restart the service in package upgrade
<mwhudson> and yeah, the autopackage tests are happy
<mwhudson> ah is that in 1.12?
<jtaylor> I've been using it on a few machines with upstream docker and it seems to work for me
<jtaylor> yes
<mwhudson> tianon: hi :-)
<LocutusOfBorg> Adri2000, also Debian
<LocutusOfBorg> I would like to upload libfilezilla and then filezilla
<LocutusOfBorg> if you agree I can git push
<LocutusOfBorg> I already have the upload ready
<LocutusOfBorg> Adri2000, back, sorry
<Adri2000> LocutusOfBorg: sorry I'm a bit busy, but go ahead I trust you :)
<LocutusOfBorg> uploading and git pushing
<LocutusOfBorg> BTW can you please apply for DM?
<LocutusOfBorg> uploaded and filezilla in deferred/1
<smoser> cjwatson, you still need a bug filed ?
<smoser> cjwatson, well, filed. feel free to close or dupe.
<smoser> https://bugs.launchpad.net/launchpad/+bug/1628091
<ubottu> Launchpad bug 1628091 in Launchpad itself "oops when loading bug" [Undecided,New]
<smoser> hey, does anyone know what group or acl i need to have to upload to parter?  at the moment i cannot accept nomination for bugs in a partner package. so i assume that related to upload. anyone know?
<smoser> digging. must be https://launchpad.net/~canonical-partner-dev
<xnox> stgraber, is there a trick / sample code for updating QATracker result? I called add_result, but doing .result='Passed' and .save() on the object it returns fails with invalid RPC request =(
<xnox> just not going to submit "in progress" results any more, and will just push out pass/fail
<bdmurray> mvo: Did you get a chance to look at those unattended-upgrades bugs?
<stgraber> xnox: I've not used that code in years, but looks like you need a valid build object, then can do .add_result(testcase, "passed")
<dholbach> kenvandine, happy birthday! :)
<stgraber> xnox: doesn't require a save() since that's creating a new object as opposed to modifying one
<kenvandine> dholbach, thanks!
<xnox> stgraber, fair enough. Originally i was trying to testresult = build.add_result(testcase, "in progress") and then testresult.result="passed" if good else "Failed"; testresult.save() but that didn't work. Anyway, nobody else but me tests s390x anyway, so there is like zero chance of duplicate testing efforts =)
<slangasek> stgraber: ah, you're around - TB meeting? you're listed as chairing
 * ogra_ welcomes kenvandine to the "old farts club" and hands him a beer labeled "for grown ups" 
<ogra_> happy birthday kenvandine !
<josepht> indeed, Happy Birthday kenvandine
<happyaron> pitti: thanks for the upload, tested :)
<nacc> doko: i know very little about seabios, but i can reproduce the ftbfs. It seems like if i manually run make, it fails. If i rerun the same cc line, but append -S, then run make again, it finishes ... any idea?
<nacc> oh no, it just fails later :)
<nacc> doko: sorry, i am actually trying to help, but probably making more noise than helping :)
<doko> nacc: I'm trying to ignore you ;p No, really, am at a conference, so I'm looking at irc only from time to time
<nacc> doko: totally fine -- seabios one seems odd, as debian isn't seeing it, afaict
<nacc> doko: ah, it might be this line
<nacc>   movl (MainThread@GOTOFF(%ebp)), %esp
<nacc> yes, that does seem to be it, something is being more pedantic about extra parens now
<nacc> still fails to link, but gets further
<nacc> doko: ok, xen ftbfs (i think you're already aware) is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166
<ubottu> Debian bug 812166 in xen "xen: FTBFS with GCC 6: statement is indented as if..." [Serious,Open]
<coreycb> arges_, hi, would you be able to review the openstack packages in the xenial queue tomorrow?
<arges_> coreycb: sure
<coreycb> arges_, thanks
<doko> apw, ogasawara: fyi, https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1628207
<ubottu> Launchpad bug 1628207 in gcc-5 (Ubuntu Xenial) "boot arguments passed in CONFIG_CMDLINE not being picked up by kernel with gcc-ppc64-linux-gnu v5.4.0 and v6.1.1" [High,New]
<rharper> dupondje_: any chance you can test out the updated packages in the strongswan-plugin bug? https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193
<ubottu> Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Undecided,Confirmed]
<bdmurray> xnox: Is there anything out of date with this? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeFetcherCore.py#L80
<nacc> ok, so i'm trying to sru a package (pollinate) back to {12,14,16}.04. I understand the versioning to use. However, in this particular case, I'm SRU'ing the yakkety version back to all 3. It seems that the way this was done in the prior SRU was to basically drop debian/changelog from the target series altogether and just append a changelog entry for the SRU. (so all 3 prior SRUs look like single
<nacc> changelog entries after the prior yakkety version. It's confusing to do it that way, but so be it. I was wondering if that was 'expected'. Additionally, if, given that we're actually SRU'ing a jump of two upstream releases, should there be two changelog entries? Or is it sufficient for me to say 'New upstream release (LP: #...) and just provide the changelog of both in one long(er) entry?
<nacc> i apologize if that's confusing, i can clarify it with specific examples, etc
#ubuntu-devel 2016-09-28
<tsimonq2> hmm, reading lubuntu-users archives, came across this: https://lists.ubuntu.com/archives/lubuntu-users/2016-September/011194.html
<tsimonq2> wasn't this a global issue at one point?
<sarnold> pity he didn't report bugs with detailed reproducers
<sarnold> the pcmanfm changes may have been intentional, reporting that one upstream too might be nice, they might say "works as designed" or "thanks"
<tsimonq2> sarnold: I was talking about the second one, sorry
<tsimonq2> I can work on the first one ;)
<sarnold> tsimonq2: yeah, i figured, that's more likely to be 'global' :) hehe
 * tsimonq2 nods
<tsimonq2> sarnold: not a lot of people wither on Facebook, Twitter or lubuntu-users report bugs
<tsimonq2> so we usually file them for them
<tsimonq2> not much, but still
<sarnold> tsimonq2: that's very kind of you :) I never know 90% of the programs that people are actually using so I can certainly appreciate when you -do- understand it well enough to report a useful bug ;)
<tsimonq2> sarnold: well sometimes we *do* have to ask follow-up questions (but that's a given), then when we report it, we link them
<tsimonq2> sarnold: but yeah it's something I like to do to make sure Lubuntu is bug-free ;)
<tsimonq2> sarnold: possibly related: https://www.reddit.com/r/Lubuntu/comments/54endb/help_new_install_but_wifi_disconnects_randomly/
<sarnold> tsimonq2: tough to guess :/
<tsimonq2> yeah
<tsimonq2> that's the thing with making bug reports out of FB/Reddit posts. You have to go through and confirm them yourself... :P
<tsimonq2> I don't run standard Lubuntu, I'm on LXQt
<sarnold> and if you don't have that NIC, you're kind of out of luck with that one..
<tsimonq2> well yeah
<pitti> Good morning
<slangasek> seems I don't have privs to set the topic here; someone want to note that yakkety final beta is released?
<dax> slangasek: go for it
<dax> Unit193: might wanna add ^
<smb> nacc, just saw you mention xen in the scrollback. could you point me to which xen where? also I got a xen-4.7 in unapproved for ffe after beta which I believe would/should compile in yakkety
<xnox> bdmurray, yes. in yakkety that is probably broken. Also I'm guessing that gpgv should be used.
<pitti> LocutusOfBorg: http://launchpadlibrarian.net/286884351/libgksu_2.0.13~pre1-9ubuntu1_source.changes
<pitti> LocutusOfBorg: please use -v properly for merges
<pitti> LocutusOfBorg: i. e. to include the relevant Debian changelogs too
<pitti> LocutusOfBorg: for the learning exercise, I'd like to reject and you reupload with the fixed .changes?
<LocutusOfBorg> pitti, let me save it please
<LocutusOfBorg> ok reject
<pitti> LocutusOfBorg: ack
<LocutusOfBorg> dpkg-buildpackage -S -d -V 2.0.13~pre1-8ubuntu1
<LocutusOfBorg> this should do the trick
<LocutusOfBorg> at least changes file looks good
<LocutusOfBorg> BTW there aren't significative changes in that merge, just a lot of better in delta size
<pitti> LocutusOfBorg: right, -v<last Ubuntu upload>
<LocutusOfBorg> I hope I could do that automagically, but I failed to achieve that
<pitti> LocutusOfBorg: rihgt, but the debian part is the "interesting" bit in a merge
<LocutusOfBorg> maybe calling some rmadison...
<LocutusOfBorg> not sure
<pitti> LocutusOfBorg: grep for the first ubuntu-ish record?
<LocutusOfBorg> I really don't like having to remember stuff, and I agree about your point
<pitti> but I usually do that manually, copy the version number, then gbp buildpackage -v<paste>
<LocutusOfBorg> pitti, patch dpkg-buildpackage to do that for me? :)
<pitti> cannot be made foolproof, I'm afraid
<LocutusOfBorg> I guess so
<LocutusOfBorg> reuploaded
<LocutusOfBorg> http://launchpadlibrarian.net/287031706/libgksu_2.0.13~pre1-9ubuntu1_source.changes
<LocutusOfBorg> yay looks better
<xnox> i'm going a bit crazy
<xnox> python3 -c 'import apt_pkg; print(apt_pkg.config.find("Dir::Etc"))'
<xnox> prints nothing
<xnox> what's wrong?
<xnox> apt_pkg.init_config() -> aha
<xnox> got it.
<tsdgeos> mitya57: about the appmenu-qt5 thing, would it even make sense to make it conflict with newer qts so it gets uninstalled? i mean what's the usefulness of it?
<xnox> bdmurray, ubuntu-release-upgrader needs quite a bit of fixing.... loads of things it does, no longer are present in apt.
<LocutusOfBorg> jbicha, why you not DD yet?
<jbicha> LocutusOfBorg: are you interested in being my advocate for it?
 * doko curses completely outdated xfsprogs/xfsdump versions ... coreycb, zul, jamespage: interested in fixing the ftbfs?
<LocutusOfBorg> jbicha, yes
<LocutusOfBorg> maybe after one of two more sponsoring :)
<LocutusOfBorg> we can followup privately if you prefer
<nacc> smb: yeah, sorry! -- the ftbfs was http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html#ubuntu-server, debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166, fix is https://github.com/xenserver/xen-4.6/commit/ef6e53a83dc8948b44ffb4efa27c0c524f6d9f2a
<ubottu> Debian bug 812166 in xen "xen: FTBFS with GCC 6: statement is indented as if..." [Serious,Open]
<smb> nacc, ah ok, so looking at it its just failing due to indentation checking. Which means no need for fixing back in Xenial or so. And since my 4.7 test builds were not complaining I guess it got changed since then. Which would fix the yakkety rebuild once the ffe gets accepted
<nacc> smb: ack, it's a trivial thing for sure
<nacc> smb: i will note that for whatever reason, debian was also having trouble manually reproducing it (per that bug report)
<smb> nacc, could be that we turn on some more hardening flags like treat warnings as errors
<nacc> yeah, although debian also reported it -- regardless trivial fix, and i'll look forward to your ffe build getting through :)
<nacc> so `apt-get changelog` doesn't correctly handle a package whose source is in main, but for which some binary packages are in universe (e.g., openexr) -- it tries to open a URL under universe/
<nacc> has that always been the case?
<nacc> doko: fyi, openexr fix is probably a merge/sync -- testing it now
<Gr33ntea> Hey guys, im trying to make a hello world kernel module, but am getting the following errors. make[1]: Entering directory `/usr/src/linux-headers-3.19.0-64-generic'
<Gr33ntea> make[2]: *** No rule to make target `arch/x86/syscalls/syscall_32.tbl', needed by `arch/x86/syscalls/../include/generated/asm/syscalls_32.h'.  Stop.
<Gr33ntea> Any advice?
* slangasek changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | 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 | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
<nacc> slangasek: are you available for a quick question?
<pitti> http://xkcd.com/1739/ â SO TRUE!
<nacc> pitti: *especially* the hover text
<slangasek> nacc: yes (was that the quick question?)
<nacc> slangasek: I wish! :) i'm trying to sru pollinate and it seems like prior SRUs of new upstream versions basically took the Y-1 version, and just appended a P/X/Z changelog entry to it. Rather than maintaining debian/changelog from P/X/Z and adding a version to it. Is there a best practices? And if SRU'ing a jump of two version (because the intervening version introdcued a bug fixed by the latter),
<nacc> should there be d/changelog entries for both, or is it appropriate to just make one changelog entry?
<nacc> sorry, ended up being two questions :)
<slangasek> nacc: ah - I saw that question flash by yesterday on here while in the midst of beta prep, was hoping someone else would have answered it for you, sorry
<nacc> slangasek: it's ok -- i have my own thoughts, based upon other packages, but given pollinate has already done this once, i wasn't sure what was "best"
<slangasek> nacc: so, there is no strong convention here either way; in theory the SRU changelog should be "append only" so that we get a clean debdiff in the SRU review queue that only shows the new stuff, but in practice we'll let it in either way (because we understand the headache of maintaining separate branches just for the changelogs)
<xnox> pitti, that's like gpg2 transition
<nacc> slangasek: ok, and as to the upstream version jump? Im assuming i can just do one changelog entry that lists all the changes?
<slangasek> nacc: yes, that's also permitted
<nacc> slangasek: ok, thanks for your help!
<doko> chrisccoulson: could you give me some hints how to debug the firefox internal install failures?
<bdmurray> xnox: Could you elaborate on issues with ubuntu-release-upgrader? It'd be good to get it squared away soon...
<slangasek> caribou: any further progress on LP: #1619239? looks like this is blocked on enabling of tests?
<ubottu> Launchpad bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,In progress] https://launchpad.net/bugs/1619239
<dobey> is there any way to do hooks with sbuild, similar to how they  work in pbuilder?
<slangasek> dobey: akin to /etc/schroot/setup.d ?
<dobey> slangasek: maybe? but something more akin to --setup-commands for autopkgtest/adt-run. i need to run different ones depending on the package being built, not something that always happens every time necessarily
<dobey> slangasek: i'm trying to figure out how to enable coverage report building in our jenkaas setup, and found the old cupstream2distro/pbuilderjenkins stuff which uses pbuilder hooks which mess with override_dh_auto_configure in debian/rules in a script, to add the configure options
<dobey> so trying to figure out how i can do something similar with sbuild, which jenkaas uses
<dobey> hmm, then again i have no idea if --pre-build-commands expects me to pass a local script as argument that is simply copied in and then run, or if i have to pass in a script that exists in the chroot
<slangasek> --pre-build-commands is called from outside the chroot, apparently vs. --chroot-setup-commands which is inside
<slangasek> (but I only know this from looking at the manpage)
<dobey> yeah, i must have misread and conflated those
<nacc> mwhudson: would you be able to look at the memcached (test failure) and libwebp (compile failure) ftbfs on armhf? https://launchpadlibrarian.net/285962179/buildlog_ubuntu-yakkety-armhf.memcached_1.4.25-2ubuntu1_BUILDING.txt.gz and https://launchpadlibrarian.net/285964171/buildlog_ubuntu-yakkety-armhf.libwebp_0.5.1-2_BUILDING.txt.gz respectively. I don't know enough about arm to know where to start :/
<xnox> bdmurray, working on them. Will send a merge proposal for review soon.
<bdmurray> xnox: cool, thanks!
<nemo> So... This isn't really about ubuntu-the-distro... But, I've been continually impressed with how much more awesome mozjpeg is than basically anything else out there on default settings at making a jpeg w/ minimum artifacts.
<nemo> I was curious if anyone out there was maintaining a PPA that offered it as a dropin for the standard libjpeg
<nemo> it's been a couple of years since mozjpeg 3.0 release
<nemo> tried poking around on launchpad but didn't see anything obv
<mwhudson> nacc: i guess nuking 32 bit arm from orbit would be a bit premature
<nacc> mwhudson: :)
<nacc> mwhudson: thanks for looking...
<mwhudson> nacc: it's a bit lazy, but have you retried the memcached one?
<nacc> mwhudson: no, i haven't -- not entirely sure how i retry them?
<mwhudson> nacc: find the build page, click retry
<nacc> ah
<mwhudson> or try it on the porter or whatever
<nacc> hrm, i htink i have insufficient permissions? https://launchpad.net/ubuntu/+archive/test-rebuild-20160916/+build/10821181
<mwhudson> nacc: where is that libwepb failure from?
<mwhudson> a test rebuild or something?
<nacc> mwhudson: both are from http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html#ubuntu-server
<mwhudson> ah
<nacc> yeah
<mwhudson> ah so retrying might not be so simple
<nacc> yeah :)
<nacc> i am assuming i could ask doko to do it manually :)
<mwhudson> huh why is that linking to a bug from 2014?
<mwhudson> nacc: is there a new gcc for the test rebuild?
<mwhudson> nacc: anyway, doko would be a better bet for figuring out what's going on there, some change in gcc defaults causing trouble
<mwhudson> i think
<nacc> mwhudson: ack, i'm not sure if there was in that one ... there was a second link in doko's email to the linaro-gcc 6 builds, but that failed the same way
<mwhudson> hmm
<mwhudson> i'll try building it on rugby i guess
<nacc> i'm still learning about all of this, tbh :) just trying to fix as many as i can
<doko> nacc: given back
<mwhudson> nacc: i'm not sure i'd call myself an expert :)
<nacc> doko: which? :)
<mwhudson> memcached
<nacc> doko: interestingly, yakkety can't build the debian seabios either, so i'm guessing it's a compiler change, but i have little idea what (unless it's just more pedantic about the parens)
<mwhudson> memcached failed again in the same way
<mwhudson> and on the porter too
<nacc> mwhudson: would you be able to test current debian/sid ?
<mwhudson> uh
<mwhudson> not so easily
<nacc> not debian itself, just the version of memcached
<mwhudson> ah ok
<mwhudson> yes, that should be doable
<nacc> 1.4.31-1 i think
<mwhudson> uh
<mwhudson> surely there is a debian mirror squid.internal is allowed to access
<mwhudson> heh https://launchpad.net/debian/+archive/primary/+files/memcached_1.4.31-1.dsc works
<nacc> nice
<mwhudson> nacc: the yakkety package fails to build in the xenial chroot too, fwiw
<nacc> mwhudson: ah good check, thanks
<mwhudson> nacc: and the debian package too!
<nacc> interesting -- as it definitely builds under debian: https://buildd.debian.org/status/fetch.php?pkg=memcached&arch=armhf&ver=1.4.31-1&stamp=1471823239
<nacc> *built, i've not tested current, i guess
<ventrical> Mark... I downloaded the current ubuntu iso , installed unity8 desktop and it is in bare bones condition. Could you please tell me whats up with the unity8 project?
<mwhudson> nacc: do you have access to any arm64 hw?
<ventrical> anyone else out there have any idea why the unity8 desktop is deprecating
<ventrical> no ... I am working on the amd64 version without ppa.
<nacc> mwhudson: not immediately, but i could probably try to find some access
<ventrical> sorree i thought I was being spoken too :)
<mwhudson> nacc: wondering about mk-sbuild sid && sbuild -d sid memcached_1.4.31-1
<nacc> mwhudson: i'm assuming crossbuild (if that's even possible) isn't sufficient given the testcase failure?
<mwhudson> nacc: yeah
<mwhudson> nacc: i guess trying to see what this testcase is testing is probably also worth doing ;-)
<nacc> mwhudson: yep, on my todo :)
 * nacc was hoping it would be something obvious to you, but will dig into it more at this point :)
<nacc> doko: fyi, seabios builds fine in xenial (yakkety and debian versions of the package). So I think it must be a compiler issue?
<ventrical> BUMP! Any status reports of the current state of unity8?
<mwhudson> nacc: it's a bit strange, i don't even understand which test case is failing
<nacc> mwhudson: yeah the log is hard to parse
<mwhudson> nacc: and why doesn't the test stop after the message "Terminated" is printed
<mwhudson> ah, it forks
<cjwatson> ventrical: I'm not at all involved with it and cannot answer any further questions, but I think it's still something of a work in progress.  You could try #ubuntu-unity perhaps.
<doko> nacc: could be, but all these boot related packages are usually touchy with new compiler versions... try to build with optimization disabled, or with -O1, and/or watch for warnings
<ventrical> ok.... I tried ubuntu-unity8  but nobody there... lets see..  and thanks..
<cjwatson> #ubuntu-unity8 doesn't exist
<ventrical> ok
<cjwatson> note that the IRC server will auto-create a channel if you try to join it
<cjwatson> so you can /join any random garbage and it'll show you that you've joined but nobody else is there
<ventrical> ahhh .. thanks .. I got it now..
<doko> nacc: maybe try first to disable pie
<doko> because there is no debian rc issue
<nacc> doko: for seabios?
<doko> yes
<nacc> doko: ack, will do, thanks!
<mwhudson> nacc: oh that message about signals is a red herring
<mwhudson> nacc: no i officially don't know what's going on :)
<nacc> mwhudson: :) thank you very much for looking at all
<mwhudson> nacc: a call to read() on a socket is reading 0 bytes and the test code blows up at that
<mwhudson> that's about as much as i know :)
<mwhudson> during tests of binary get
<dobey> how do i make something built with dh-golang, that uses vendor internally, build against packaged version of said vendored code, without removing it from the upstream tree?
<dobey> mwhudson: ^^ might you know?
<nemo> https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet  â  why I'm going to move straight from 14.04 LTS to devuan
<dobey> ventrical: the unity8 session on yakkety ISO is meant to be a "tech preview" and not a final product
<doko> nacc: memcached failed again
<nacc> doko: ack, it was mostly a shot int he dark that it might work; mwhudson's analysis points at some real issue, still need to spend time to track it down
<mwhudson> nacc: fwiw things that only fail on armhf usually turn out to be alignment
<mwhudson> although i can't see how here
<nacc> mwhudson: yeah nothing obvious showed up to me; so i'm now wondering about optimization flags, etc. like doko mentioned
<nacc> doko: as to mako, do you want me to upload my fix (which does build?) I've sent the same upstream, but no comments yet
<nacc> doko: and also sent to debian
<nacc> doko: good call on the PIE on seabios -- it seems like the makefile is using -no-pie, but it should be using -fno-pie. builds with that
#ubuntu-devel 2016-09-29
<tsimonq2> hey everyone
<tsimonq2> hardinfo is currently FTBFS in Yakkety, and it's the only FTBFS in the lubuntu packageset
<tsimonq2> (at the moment)
<tsimonq2> I've already gotten a +1 from several people here, but the fix is detailed in this email: https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html
<tsimonq2> I addressed it to Julien, our developer lead, but unfortunately he has been busy lately, so he asked me to get it sponsored
<tsimonq2> (over FB messenger)
<tsimonq2> so if somebody could upload this for me, that would be awesome
<tsimonq2> have a good evening
<Mirv> pitti: you could kill all autopkgtests that have Triggers: one of the following, as it's no longer the latest version (upstream updated their commit) http://pastebin.ubuntu.com/23249960/
<pitti> Mirv: thanks, I think I caught all the matching queued tests now (not the running ones, too much effort)
<ventrical> any news on the state of unity8 desktop?
<sladen> ventrical: this is quite a broad question.  If you can narrow it down a bit, somebody like popey might be able to help you
<ventrical> I was here yesterday and got no replies. Most testers at ubuntuforums are getting freeze ups , no libertine and no app store and a diminished apps scope with barely any useable icons
<caribou> slangasek: well, I've just noticed that mdeslaur has updated a 0.99-2 everywhere so maybe our best choice is to get that version in Y and see if we still want to MIR tomsfastmath and do it in Z
<caribou> slangasek: so far, the security team was not sure if they could do the MIR security review for 16.10
<caribou> rbasak: maybe there is something you want to add to this ^^^
<david89> Hello. Is the ubuntu sdk available for other distros other than ubuntu?
<Mirv> david89: hi! I think it will be available as a .snap package for other distros too, but I'm not sure if there is an usable snap yet.
<Mirv> there are some first builds done but also some bugs still that may prevent using it in a meaningful way right now
<sil2100> Hey! Does anyone know if a package is in the Unapproved queue, can I push a new (fixed) version of it with the same version number?
<sil2100> Since I found a small typo in an SRU I pushed, would like to fix that but I'm not sure if I should bump the version number or re-upload as the same one
<sil2100> The package currently is still in the Unapproved queue
<sil2100> Should I first ask someone to reject it and then re-upload?
<sil2100> pitti, tjaalton: what do you guys think? ^
<tjaalton> sil2100: use same version, old one will be dropped from the queue
<sil2100> Excellent, thanks :)
<tjaalton> which one is it?
<sil2100> livecd-rootfs
<tjaalton> just xenial?
<sil2100> Yeah
<tjaalton> ok, I'll drop the one from tuesday
<sil2100> tjaalton: thank you
<sil2100> Uploading the updated one
<david89> Mirv: were can I find the alpha builds?
<david89> Also, does the ppa work on derivatives/spins?
<Mirv> david89: let me ask zbenjamin if there is any SDK snap downloadble anywhere, just for fun :) maybe not.
<Mirv> david89: sure PPA should work on any official Ubuntu flavors, and probably derivatives too if they're not too .. derivative
<zbenjamin> Mirv: there is nothing that works atm.
<Mirv> zbenjamin: right, that's what I feared, ok
<david89> thanks anyway!
<david89> Apart from snap, could I possibly try building it?
<zbenjamin> david89: sure, lp:ubuntu-sdk-ide
<zbenjamin> david89: however you will need LXD and lp:ubuntu-sdk-tools
<david89> zbenjamin: LXD could be a problem with my kernel, are there build instructions for the other two?
<zbenjamin> david89: ubuntu-sdk-ide is cmake based, so mkdir build && cd build && cmake <pathtosource> && make
<zbenjamin> david89: the other one is a Go project so you'd need to setup a Go workspace
<david89> zbenjamin: ok, thanks. Ill see what happens
<zbenjamin> david89: but without LXD the SDK will not be much useable. Its a core requirement
<zbenjamin> david89: we use build containers to provide the toolchains
<david89> zbenjamin: LXD containers?
<zbenjamin> david89: yes
<david89> zbenjamin: are they public?
<zbenjamin> david89: sure, https://sdk-images.canonical.com/
<david89> thanks again. Im building linux now
<zbenjamin> david89: thats the script to create new images if you need it http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-sdk-ide/trunk/view/head:/dist/qtcreator/src/plugins/ubuntu/share/qtcreator/ubuntu/scripts/usdk-target-build
<Mirv> pitti: is the akonadi s390x still in endless loop mode?
<Mirv> it's testing a 6 day old build right now
<acheronuk> Mirv: yofl seems not really available for the time being. do you think the release team could be persuaded to repeat what was dicussed here? http://paste.ubuntu.com/23250241/
<Mirv> acheronuk: it totally depends on how grumpy they are :) but yes, possible.
<Mirv> acheronuk: the more Kubuntu people can evaluate the situation yourselves the better - I mean, the autopkgtests are being run anyway and take days, the results should mean something. if it's mostly green, the red ones could be quickly glanced through to see if anything scary. if it's mostly red, then maybe there's something really problematic.
<acheronuk> Mirv: ok. not sure any of us who are available have a great deal of a clue how to decide what is serious on those or not, but I guess if a couple of days or so we can put a case together as best we can
<Mirv> acheronuk: to quickly get a list of stuff on excuses page that has regressions, I use wget -q -O - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | grep Regression | sed 's/^<li>autopkgtest for \([a-z0-9-]*\).*/\1/'| sort | uniq
<acheronuk> Mirv: oooh. nice. :) ^^^^
<acheronuk> ty
<Skuggen> Are there any irc channels for snap?
<ogra_> Skuggen, #snappy
<Skuggen> ogra_: Thanks :)
<tjaalton> is there a list of supported arm hw somewhere?
<pitti> Mirv: I suppose it is, I'll kill it
<pitti> Mirv: oh, I only blacklisted it for y, not for x
<pitti> Mirv: I put it out of its misery now
<pitti> sil2100: rejecting and reuploading with same version number is cleaner
<pitti> sil2100: you can even upload it right away, and in the queue we then reject the older one
<pitti> sbeattie: oh, don't we have a CVE pool any more?
<pitti> sbeattie: I'm applying it to Debian, next SRU etc. now, so I wonder if there's a CVE for the changelog
<jgdx> doko, hi, re bug 1628327, is that last comment an okay solution?
<ubottu> bug 1628327 in golang-gosqlite-dev (Ubuntu) "[MIR] golang-gosqlite-dev" [Undecided,Incomplete] https://launchpad.net/bugs/1628327
<coreycb> hello, can an archive admin please accept python-os-api-ref from the yakkety new queue?  this is a required build-depend for openstack packages.
<mdeslaur> caribou: if tomsfastmath doesn't get the MIR in time, you can just use the bundled one like I did in xenial. It needs a couple of patches, see the xenial package.
<mdeslaur> caribou: I can do that for you if it gets to that
<caribou> mdeslaur: that was my idea, just get your package into Y
<mdeslaur> well, there are a few changes in Y worth keeping
<mdeslaur> I'll just change the tomsfastmath part
<caribou> mdeslaur: the delta was not that big b/w your package & my merge
<dobey> ventrical: you got replies. apparently you just chose to ignore them. no, libertine app/tools aren't installed by default, but you can certainly just apt-get install libertine to use it. the store scope was removed for the time being as clicks are not supported on yakkety, and until we have a usable snap store. the unity8 session is a tech preview, not a finished product.
<smoser> pitti, around ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692 i think needs init-system-helpers let through
<ubottu> Launchpad bug 1576692 in init-system-helpers (Ubuntu Xenial) "fully support package installation in systemd" [High,Fix committed]
<dobey> ventrical: you were also referred to #ubuntu-unity for questions about unity
<ventrical> yes I was  and I did ..
<ventrical> no .. I did not ignore .. I don't understand what you are talking about
<smoser> seems http://people.canonical.com/~ubuntu-archive/pending-sru.html might be blocking init-system-helpers ?
<dobey> ventrical: it sounds like you are expecting unity8 to be a final release product in 16.10, but it's only a technical preview
<ventrical> no I do not expext it to be a final release .. I expect it to be a working release .. there is no place, no where where Mark had said this was a technical preview  that is just plain not correct!
<dobey> it does work; because you only have 3 things installed that work under unity8 doesn't mean unity8 isn't working
<ventrical> dobey  please get facts correct. We at Ubuntu Development Version Testing (U+1) have been working on Unity8  tersting under the premise that it will be a working alternate desktop for 16.10
<ogra_> huh ?
<ogra_> that has definitely never been said
<ventrical> mark said it in his frist webinar .. that he had 90 people commited to working on just unity8
<ogra_> sure ... and that there will be an ability to switch to a unity8 session to preview the state in 16.10
<ogra_> but that an actual switch will only happen when the community agrees it is ready
<ogra_> nobody promised "a working alternative desktop"
<ventrical> well I certainly  would have hoped that this would have been made more clear  a while back after all the time we have put into testing it. I don't think this kind of 'teaze' is very forthright
 * dobey also pretty sure he has "facts correct" here
 * ogra_ doesnt understannd what you mean ... if your expectations went off, how can we help with that 
<ventrical> sorry but I beg to differ .. however I cannot stand up to community council policies so I guess I'll just have to accept it..
<dobey> unity8 is meant to be an alternate preview session on 16.10 ISO
<dobey> i'm pretty sure that it was never stated or implied that it could be a total replacement for all users in 16.10
<ogra_> yes, and it was never advertised any different
<ventrical> hey orga .. no problem .. we are just testers ...
<cjwatson> are you sure Mark said "90 people"?  That really doesn't sound right
<cjwatson> 19, maybe
<ogra_> yeah :)
<ogra_> unless he counted snappy in ;)
<bregma> I would certainly expect Unity 8 to be usable as a limited day-to-day desktop (browsing, playing music, editing files, tame stuff like that) and that's certainly what we're aiming for in 16.10
<bregma> not stable, not reliable, nut usable
<ventrical> yes he said 90 persons commited to just unity8!!
<bregma> *but usable
<dobey> bregma: and it's certainly usable for that
<bregma> dobey, not in the beta release
<ventrical> bregman.. thanks for sharing that
<bregma> there were bugs that rendered it unusable, as you know since you;re fixing them
<bregma> all will be well by 16.10
<ventrical> totally unusable .. those others are using the ppa
<cjwatson> http://news.softpedia.com/news/mark-shuttleworth-we-won-t-make-the-same-mistake-again-with-unity-8-503796.shtml quotes Mark as saying "a team of eighteen people", from the Q&A I believe you're referring to
<dobey> well, you can play music and edit files in the browser just fine. :)
<ogra_> hah, cjwatson found what i was llooking for since 10min :)
<bregma> except you couldn't launch the browser
<bregma> it was a bug, it's being fixed
<ventrical> no .. in the ewebinar he said 90 persons.. ok .. i'm dropping it..
<bregma> there are serious gaps in the QA process that let that bug pass
<dobey> bregma: which bug is that one?
<bregma> dobey, the bug in which no apps appear in the launcher
<dobey> bregma: apps scope, or launcher?
<ogra_> both
<ogra_> i had it on the weekend too when testing
<ogra_> fixed with some update on tuesday or so
<bregma> "no way to use the GUI to launch applications" might sum it up
<ogra_> but that didnt make beta afaik
<dobey> ogra_: no apps in apps scope only happened after installing libertine-tools and creating a container (or if you already had one), though
<dobey> certainly not a default install issue
<bregma> dobey, many people use their desktops
<ogra_> well, that might be ... i'm just telling what i saw when trying it on the weekend
<bregma> "default install" isn't good enough
<jgdx> mterry, hey, could you take a look at my comment for bug 1628327 ?
<ubottu> bug 1628327 in golang-gosqlite-dev (Ubuntu) "[MIR] golang-gosqlite-dev" [Undecided,Incomplete] https://launchpad.net/bugs/1628327
<ogra_> i actually only test u8 when i'm having to reboot my laptop anyway ... because of a kernel upgrade or so
<ogra_> and i guess many people do it like that
<dobey> bregma: "default install" is what ISO testers test; and it pretty much is good enough for the "tame stuff like that" you mentioned. :)
<ogra_> (apart from "popescu sorin" ... who tests every day ;) )
<dobey> i certainly couldn't use it daily, even with fully working libertine
<dobey> ogra_: i'm testing xenial+overlay in a kvm. (was told yakkety had issues because of mesa and such)
<dobey> i'm pretty sure gnuserv/emacs doesn't work under mir
<dobey> anyway
<bregma> I think "we do a half-assed job of automated testing" is a poor excuse for doing a half-assed job of automated testing, as can be demonstrated by the fact that a critical ship-stopping bug got through on the shipped beta version of software
<bregma> what is being done for testing right now is simply Not Good Enough
<mterry> jgdx: if they're in main already and you can replace existing deps, that sounds great to me
<jgdx> mterry, great, thank you for the quick reply
<mterry> (sorry, didn't realize it was a question in the bug, rather than a statement of intent)
<ventrical> dobey and all  here is the kink to the plenary Q&A with sabdfl. Listen closely .. he says "90" people working on unity8. Although he did say he was careful not to "overpromise" he did not say anything about a technical preview http://summit.ubuntu.com/uos-1605/meeting/22664/mark-shuttleworths-qa/
<ogra_> ventrical, then i guess he counted snappy, phone/tablet etc into this number too
<ogra_> in all these areas a few people work on ubity8 integration
<ogra_> *unity
<ventrical> bregma  we are testing the daily ISO in U+1 and there is a small group of us still testing unity8 in yakkety and xenial .. with ppa and without ppa.. the problem is that it was working really well and then evrything went south and (at least) all my installs got broke as I updated upgraded them.
<ventrical> orga .. listen to it please he said specifically 90 people dedicated to unity8 .. unless he meant 19 .. I dunno  sure sounds like 90 to me..
<cjwatson> ventrical: it's 50 minutes, roughly what time?
<ventrical> I think it is over the half way mark ... I'll look see and get back ..
<bregma> at one point we probably had 90 people working on Unity and the entire Touch stack, it seems like an historically reasonable number
<bregma> I do not believe we have that number now as the major development push is over and the long tail begins
<cjwatson> the thing I just heard was "for about 80 people, that is their top priority" (at about 25:30)
<cjwatson> looking through the internal directory, my guess is that that refers to the size of the "Devices - Ubuntu Engineering" department
<cjwatson> (it's a bit off from right now, but close enough)
<bregma> right now, we have about 30 people for whom the new Unity 8 aegis it is their top priority and another 10 or so indirectly involved, plus support staff and management
<cjwatson> so it's the top priority for the department, though that isn't necessarily going to translate in every single person there doing nothing but working on the unity8 codebase
 * bregma has difficulty counting non-engineers as people sometime
<cjwatson> anyway, I don't know that arguing about exact numbers of people is useful, bregma has already given much more informative answers about solidifying automated testing etc.
<cjwatson> which is way closer to how this kind of thing gets better :)
<bregma> ventrical, could you please repost the URL to the U+1 group so I can add it to my monitoring list?
<ventrical> at point 25:00 he starts talking about unity8 .. that it will be an option (not technical preview) and that "80 people" will be working on it .. that it will be an option like gnome and MATE is for 16.04
<ventrical> bregma  https://ubuntuforums.org/forumdisplay.php?f=427
<ventrical> cjwatson  just at the 25:00 minute point mark starts talking about unity8. There is nothing indicating  that it will be a technical preview.  If it was we wouldn't be testing it .. we already went the preview route with lxc
<dobey> it's always been an "option" like gnome and mate, but it's not an "option" like Ubuntu GNOME and Kubuntu and Ubuntu MATE; i think you're reading more out of what was said, than was actually said
<ventrical> dobey .. did you actually listen to it ?
<jbicha> it's still the intent to try to get Unity 8 on the primary yakkety iso, right?
<ventrical> I hope so ... if not then we are jsut wasting a lot of time..
<dobey> jbicha: yes, as a preview session
<bregma> ventrical, it's definitely going to be a technical preview, since we know it will not have full functionality like proper multi-monitor support, but it will also be included on the ISO as an optional login session for those early adopters who wish to try it out and give feedback
<bregma> so, in 16.10 it will not be ready for just anyone to use as their daily driver
<ventrical> bregma    ..wow....
<bregma> on the brave
<bregma> *only the brave
<ventrical> ok... thanks ..
<ventrical> :)
<bregma> we're working hard to get everything through the rogorous Ubuntu approval process so we can include everything necessary on the ISO, and that is taking a lot of effort and explains why it's not yet in ISO images
<bregma> we had to get security and packaging reviews for 110 new packages
<bregma> not all new packages pass their reviews the first time around either
<bregma> some of them not even he second round
<dobey> the transition to snaps and clicks being broken makes things a lot more difficult too
<ventrical> bregma  perhaps I misunderstood Mark. He was so enthusiastic about it. I thought  .. "with 80 people  working on unity8 they are going to get this thing done"
<bregma> dobey, indeed...  it's been a rough ride the last few weeks
<bregma> ventrical, yes, we're getting things done but we're not there yet, and deadlines are looming large
<ventrical> as Mark said  "I want to be running unity8 for my desktop for 16.10"
<ventrical> bregma   no problem... my aplologies   I centianly understand these deadlines..
<lutostag> how do I mark a package that needs to resync from debian for yakkety?
<lutostag> https://bugs.launchpad.net/ubuntu/+source/pepperflashplugin-nonfree/+bug/1628247 in particular
<ubottu> Launchpad bug 1628247 in pepperflashplugin-nonfree (Ubuntu) "yakkety 1.8.2+nmu1ubuntu1 does not install due to changed chrome keys" [Undecided,New]
<Laney> lutostag: subscribe ubuntu-sponsors
<lutostag> Laney: thanks. done. hope that is enough
<ventrical> bregma  I will try to inspire what small part of the U+1 that is testing unity8 to continue testing and sending bug reports.  It was working so well in yakkety at one point without the ppa. And then to have it break like it did has been frustrating for those who have been investing our time in testing it.. bu t.. onwards and upwards :)
<bregma> ventrical, yeah, there should be no need for a PPA in the current Ubuntu dev version, but since it's pre-release, bugs happen
<dobey> ventrical: well, how did it break? we do have a bug reporting system. you didn't mention any specfic bugs in here :)
<bregma> ventrical, we certainly appreciate all the testing effort you folks can do
<dobey> well there is no overlay for yakkety, so adding it wouldn't change anything anyway :)
<ventrical> the bugs were aready reported.. I discussed this last night in another forum
<dobey> ventrical: is it the blank apps scope issue?
<ventrical> yep  https://bugs.launchpad.net/canonical-devices-system-image/+bug/1627759
<ubottu> Launchpad bug 1627759 in unity-scope-click (Ubuntu) "Blank app scope" [Critical,In progress]
<ventrical> and..  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1628807  which is just a rant..
<ubottu> Launchpad bug 1627759 in unity-scope-click (Ubuntu) "duplicate for #1628807 Blank app scope" [Critical,In progress]
<dobey> ventrical: there's one fix in yakkety-proposed for that, which should hopefully migrate today; and another issue we found that causes the same problem, has a fix in the UNAPPROVED queue right now
<ventrical> dobey.. ok thanks .. I am advising the U+1 team to keep testing past 16.10  I am not trying to be a pain here :)
<ventrical> ok... I boosted it up at U+1 (now UDV)  https://ubuntuforums.org/showthread.php?t=2338565&p=13551108#post13551108
<bdmurray> mvo: Have you had a chance to look at those unattended-upgrades bugs?
<ventrical> correction  I stated earlier that MArk stated "90" people working on unity9 when actually it sounded like "80" people. He could have said "18" and perhaps the audio was just not exactly right .. so .. my bad .. mea culpa.
<ventrical> unity8 thats is .. hehehe unity9 .!! heheh .. geesh .. typo there but thinking ahead :)
<nacc> jgrimm: what did you want me to look for in heimdal specifically? it's failing the tests on the three failed archs (armhf, i386, powerpc)
<infinity> nacc: So, all 32-bit arches?
<nacc> infinity: heh, good point :)
<infinity> nacc: Probably a bit of a hint there.
<nacc> infinity: good catch, thanks!
<jgrimm> nacc,  yep, looking into what's broken there.  its been stuck in proposed for something like 87days. :)
<infinity> Some fantastic compiler warnings in those build logs too...
<infinity> error.c:56:24: warning: self-comparison always evaluates to true [-Wtautological-compare]
<infinity>      if (ap->error_code == ap->error_code)
<infinity> LOLWUT.
<nacc> heh
<cjwatson> uh
<dobey> wow
<cjwatson> volatile int error_code;
<smb> dannf, would be nice if you could coordinate uploads to libvirt with me or cpaelzer. And btw the arm64 build seems broken...
<ubloomto> Hello
<ubloomto> Is there a place where overwritten files are stored on the Ubuntu OS?
<apw> ubloomto, as in once you write new contents to the file is the old maintained anywhere ?  not in the general run of things
<dobey> no, the file system itself is not versioned
<apw> if you are using the file manager graphical thing it has a trashcan much how windows does
<apw> otherwise, nothing
<nacc> jgrimm: fyi: http://paste.ubuntu.com/23252145/
<nacc> those are the two failing cases
<dannf> smb: will do. the FTBFS isn't arm64 specific - it's a missing python build-dep that was made apparent by a python3 migration afaict. i have a fixed package prepared, but would you prefer i file a bug so you can merge it?
<smb> dannf, yeah would be nice since we got a lpgit tree which we try to keep in sync
<dannf> smb: ok
<jgrimm> nacc, heimdal?
<nacc> jgrimm: ack
<nacc> jgrimm: spinning up an amd64 build to see what's different
<jgrimm> nacc, yep cool
<smb> dannf, I got some other things staged as well, so if you assign the bug to me I merge everything together
<dannf> smb: ah. checked for that in debian/control before uploading, but just saw the debian repo - and didn't find an ubuntu branch there.
<smb> dannf, not debian -> https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/log/?h=ubuntu/yakkety
<dannf> smb: if you give me a link, i can send you PR in the bug (but patch is fine if you prefer)
<dannf> smb: right - just saying Vcs-Git points to debian's
<dannf> smb: thx
<nacc> smb: we might want to, in ubuntu, do a Xs-Debian-Vcs-Git: and Vcs-Git: for libvirt?
<nacc> with appropriate urls for the ubuntu packaging
<smb> dannf, whatever format is fine, I guess its simply uncommenting the commented out python  line
<smb> nacc, guess makes sense. might add that too if I remember until tomorrow
 * smb needs to send himself some reminder emails
<DRamaekers> can someone help me understanding launchpad? On my laptop, the file /usr/lib/command-not-found is on version 0.3. If I browse the code on lp, its on 0.2.44. What am I missing?
<dannf> smb: LP: #1629041
<ubottu> Launchpad bug 1629041 in libvirt (Ubuntu) "FTBFS: missing dependency on python" [Critical,Triaged] https://launchpad.net/bugs/1629041
<smb> dannf, ack. thanks
<dannf> smb: now, i also need to SRU the previous fix (numa on arm64) for xenial. how do you want me to handle that?
<smb> dannf, I already changed the tree to match your upload, so when doing mine I'd just cover both in the changes file. would that work for you?
<smb> oh wait xenial
<dannf> smb: yeah, however you wanna do yakkety is fine w/ me
<dannf> smb: that was just the debdiff i had prepared
<smb> dannf, I have the bug number in the yakkety branch, So I might pick that change into Xenial and upload it for you
<dannf> smb: want a patch for updating the debian/control git link?
<dannf> smb: ok, thx
<smb> dannf, If you got that done already ... sure whatever way you prefer
<sbeattie> pitti: we have a CVE pool, we can only issue them when issues are private. If they're public, like this one already was, we run the risk of a duplicate CVE assignment, which mitre really wants to avoid, so we have to wait for mitre to assign it.
<dannf> smb: emailed
<tsimonq2> what's the equivalent of Qt Creator for GTK?
<mvo> bdmurray: still not, sorry, I have one more close deadline that making juggling this a bit difficult, I'm pretty sure its straightfoward though, I try again in my morning
<tsimonq2> I'd like to fix a bug in some GTK software that would be stupidly easy to fix using Qt Creator
<mitya57> tsimonq2, https://wiki.gnome.org/Apps/Builder
<tsimonq2> thanks mitya57, I'll look into it
<smb> dannf, got it. thanks
<tsimonq2> mitya57: hmm, no debug feature? or am I looking at this wrong?
<mitya57> I never used it :)
<tsimonq2> oh ok
<tsimonq2> well I'll look into it in a few hours
<bdmurray> mvo: Okay, thanks!
<mitya57> tsimonq2, according https://wiki.gnome.org/Apps/Builder/Planning/Graphical_Debugger it's only planned
<tsimonq2> :/
<infinity> nacc: FWIW, there's a patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822749
<ubottu> Debian bug 822749 in src:heimdal "heimdal ftbfs on all 32bit architectures" [Serious,Open]
<infinity> nacc: Even seems like a vaguely reasonable patch (well, the explicit cast there points to a potential bug elsewhere, but as quick fixes go, it seems reasonable)
<nacc> infinity: thanks -- interestingly, i reproduce the failure on 64-bit too
<nacc> or think i did
<infinity> nacc: That seems like it would be another failure then.
<infinity> nacc: Since the one seen on the buildds in Ubuntu and Debian was clearly "all 32-bit arches fail, all 64-bit don't"
<nacc> oh nm, PEBKAC -- yeah, i can reproduce, i'll test that fix
<mvo> bdmurray: sorry sorry sorry
<dobey> anyone intimately familiar with packaging of golang stuff that uses govendor upstream to have vendored code?
<nacc> doko: jgrimm: fyi, i got llvm-toolchain-3.6 to build (simple patch), but it fails 2 tests: http://paste.ubuntu.com/23252443/
<nacc> i'm not sure i know how to resolve them, though :)
<doko> nacc, jgrimm: port clamav to 3.9, and don't care anymore about 3.6 ;p
<nacc> heh
<nacc> is that the only reason we have llvm-toolchain-3.6 in main?
<nacc> yeah, i guess it's libclamav7
<doko> nacc: yes, only package
<pitti> sbeattie: ah, that makes perfect sense, thanks
<pitti> niedbalski, sbeattie: I followed up to bug 1628687 with pointers to the improved patches; doing the sid/yakkety fixes now
<ubottu> bug 1628687 in systemd (Ubuntu Xenial) "Assertion failure when PID 1 receives a zero-length message over notify socket" [High,In progress] https://launchpad.net/bugs/1628687
<pitti> presumably you want to do the followup via -security as well now, as it's a local DoS
<nacc> infinity: fyi, that patch didn't seem to fix i386, at least
<jamespage> doko_, I have no idea as to why but the tweak to the build process you did for libunwind makes ceph hang:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1629102
<ubottu> Launchpad bug 1629102 in libunwind (Ubuntu) "Unable to start or initialise any ceph process (ceph-mon)" [High,New]
<jamespage> I did a quick revert test to confirm
<doko_> jamespage: is this amd64 only?
<jamespage> doko_, I've not tried on any other archs yet
<jamespage> but yeah - it impacts amd64
<jamespage> doko_, its quite easy to repro in a schroot
<jamespage> I suspect that it does impact amd64 only
<jamespage> libunwind8-dev [amd64] (gperftools)
<jamespage> doko_, I guess that could be limited to arm64 ?
<jamespage> (the flag enablement)
<doko_> well, maybe, if it doesn't break on arm64
<jamespage> doko_, libunwind is not used by ceph on arm64 - ceph-mon commands run OK
<jamespage> (checked on porter)
<doko_> fortunately people requesting that change sit beneath me ... let me check
<jamespage> doko_, are you at linaro connect perchance?
<doko_> yep
<doko_> jamespage: does it get fixed when you rebuild ceph against the new libunwind?
<nacc> jgrimm: so debian may be removing heimdal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
<ubottu> Debian bug 837728 in release.debian.org "RM: heimdal/1.7~git20150920+dfsg-4" [Normal,Open]
<nacc> jgrimm: it seems like debian is at least moving the rdep packages to be |'d with other suitable packages. Obviously late in Y for this, but one of their reasons is this lack of buliding (and lack of upstream response)
<nacc> jgrimm: infinity: sigh, ran the failing heimdal test manually (after it failed during build) and it passed
<doko_> jamespage: hmm, ceph doesn't have any direct dependency on libunwind ...
<nacc> doko_: fyi, python-docutils ftbfs appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837618
<ubottu> Debian bug 837618 in xml-core "xml-core: Makes some packages to FTBFS with 'dh_installxmlcatalogs: Unexpected debhelper version format'" [Serious,Open]
<nacc> has a patch, but not yet accepted, do you want me to test it, or should we wait for debian?
#ubuntu-devel 2016-09-30
<jbicha> nacc: this late in ubuntu's release cycle I suggest to go ahead and upload to Ubuntu now
<nacc> coreycb: would your team be able to look at the ftbfs for python-eventlet and python-taskflow? I think both are openstack umbrella and seem to be test failures
<nacc> jbicha: yep, that makes sense, that's what i was trying to figure out, on the balance, thanks!
<jgrimm> nacc, ah, good to know. thanks
<tsimonq2> thanks sarnold ;)
 * tsimonq2 is testing that it installs cleanly atm
<sarnold> tsimonq2: btw, your patch had dos-style crlf line endings.. I'm curious how you managed to do that :)
 * tsimonq2 looks at .vimrc
<sarnold> patch claimed to strip them all; I haven't verified that by hand yet..
<tsimonq2> for some reason this is enabled... https://github.com/vim-scripts/PreserveNoEOL
<tsimonq2> could that do it maybe?
<tsimonq2> otherwise I'm not seeing what could be doing that
<sarnold> tsimonq2: hrm. could be..
 * tsimonq2 remove it
<tsimonq2> *removes
<tsimonq2> sarnold: thank you
<sarnold> tsimonq2: and also thank you :)
<tsimonq2> :)
<tsimonq2> sarnold: have a good evening
<ventrical> cq , cq goodmorning
<Kinder-Pingvi> Hi guys! What is the difference between ubuntu 16.10 beta 2 and daily builds?
<Kinder-Pingvi> Does daily changes are not included to beta 2?
<ventrical> a beta 2 is like a relase candidate
<Kinder-Pingvi> ventrical, what about new updates from daily? Does it will be included into release candidate?
<ventrical> 4:30 am here in Canada .. I gotta get some rest :)
<smb> Is there any preference whether a Vcs-Git line should become XS-Original-Vcs-Git or XS-Debian-Vcs-Git when I add a Vcs-Git line that points to Ubuntu? The former seems more in line with what is done with maintainer. Lintian does not seem to acknowledge any of those...
<Unit193> pitti: You ever tried usrmerge on Ubuntu?
<Unit193> FWIW, Debian #839046 / #839162.
<ubottu> Debian bug 839046 in debootstrap "debootstrap: enable --merged-usr by default" [Normal,Open] http://bugs.debian.org/839046
<cjwatson> Kinder-Pingvi: betas / release candidates are snapshots.  new updates aren't included in those snapshots, though if you install from the snapshot and apply all network-available updates you'll generally get a similar result.
<cjwatson> smb: We settled on XS-Debian-Vcs-Git many years ago.
<cjwatson> smb: (and yes, different from Maintainer for some reason I forget)
<smb> cjwatson, Ok, thanks.
<Kinder-Pingvi> cjwatson, thanks for answer! So, if I do 'apt full-upgrade' on ubuntu 16.10 I will receive that updated included into daily builds, right?
<cjwatson> Kinder-Pingvi: yep, should do
<Kinder-Pingvi> cjwatson, thank you!
<coreycb> nacc, yep will look at those
<pitti> Unit193: not tried directly on ubuntu, no; but looking forward to it anyway :)
<jbicha> cjwatson: are you aware of any tools that use Xs-Debian-Vcs ?
<pitti> Unit193: this makes the whole thing simpler, more robust, and finally puts a lid on these "but I want to have separate /usr without initramfs, and on NFS" kind of quarrels :)
<cjwatson> jbicha: not off the top of my head
<Unit193> pitti: Heh, as long as nothing breaks I don't really mind it either. :D  (Tempted to try it in a VM.)
<jbicha> for most of the ubuntu-desktop packages, we just dropped the Vcs-Svn (pointing to pkg-gnome) and added Vcs-Bzr
<pitti> Unit193: I think there's 4 packages left that break
<pitti> Unit193: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=md@linux.it
<pitti> Unit193: so that's a case of throwing them out of testing / demoting to -proposed IMHO; the rest is fine
<coreycb> pitti, if you have a chance can you take a look at the xenial python-pylxd upload again please?
<pitti> coreycb: I'm at a conference, just quickly checking IRC; so not today, sorry
<coreycb> pitti, ok
<coreycb> tjaalton, would you be able to review the python-pylxd sru upload to xenial?
<tjaalton> coreycb: sure
<coreycb> tjaalton, thanks
<caribou> what is the best way to be sure that a main package will build w/o Universe dependancies ?
<caribou> I'm using sbuild-launchpad-chroot with only updates+main so it will bomb on me if Universe dependancies exist
<caribou> but that covers both build-only dependancies and binary ones, right ?
<tumbleweed> that's a pretty good way
<caribou> yes, but I need to differentiate b/w build-only & binary, that's what I'm missing
<tumbleweed> I don't understand that question
<caribou> tumbleweed: that's because it's a dump one ;-)
<tumbleweed> build-only dependencise are presumably Build-Depends, which answers the "will build w/o universe" question
<caribou> tumbleweed: all I need to do is check the control file
<jbicha> caribou: are you concerned about runtime dependencies or build dependencies for universe?
<caribou> jbicha: runtime deps; I uploaded clamav w/o noticing that I had added a runtime dep
<caribou> jbicha: just want to trace back what I missed so I don't do it again & get chased by doko to MIR the runtime dep :)
<tumbleweed> caribou: you could run the autopkgtests to tell you that
<tumbleweed> or just manually eyeball the diff for changes in Depends
<caribou> tumbleweed: hmm, good idea
<jbicha> trying to build with only main will cause problems since some things like documentation build dependencies are in universe now since they don't add universe binary depenencies
<tumbleweed> reading diffs is always a goo didea
<Laney> binary debdiffs are quite nice
<Laney> any kind of reading is not foolproof though
 * Laney is a big enough fool
<tumbleweed> sometimes they are too big to read, thoguh. Then filterdiff -i '*/debian/*' is handy
<xnox> caribou, why do you care? universe is always enabled, and one can build-depend on universe packages.
<Laney> xnox: you need to know if runtime universe deps are generated
<xnox> the restriction is no Depends, Recommends, Built-Using in the resultant packages
<caribou> xnox: Laney is right, this  is what happened to me with clamav
<xnox> caribou, use $ check-mir ?
<xnox> however, i wonder if check-mir is still correct
<Laney> it only looks at debian/control IIRC
<xnox> it would be nice to look at debian/$PKG/DEBIAN/control
<caribou> xnox: Laney: yeah, looks like it only checks debian/control
<caribou> ok,  I think I know now why I missed it the first time :
<caribou> libclamav7 has Depends: ${misc:Depends}, ${shlibs:Depends} only
<caribou> that got resolved as a runtime dependancy to libtfm-dev
<caribou> This is not a problem on Debian but it becomes one for us
<caribou> (libtfm-dev is the one in Universe)
<jgrimm> hallyn, are you still looking after https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209 ?
<ubottu> Launchpad bug 1571209 in libvirt (Ubuntu Xenial) "Sockfile check retries too short for a busy system boot" [High,New]
<hallyn> jgrimm: no?   i delete all libvirt related emails automatically
<hallyn> jgrimm: as this is sysvinit and upstart only i doubt you care too much?
<hallyn> and in fact the current solution isn't bad, just not perfect.
<hallyn> (on mine it appears to be doing the 'sleep 2', which is fine.  o fcourse i also have mine overrided to not start to save battery :)
<jgrimm> hallyn, no worries. I was just doing some housekeeping this morning and noticed that one just lingering out there
<hallyn> jgrimm: but that one is 'fix released' right?
<hallyn> it just has a 'maybe we should do it better one day' comment at theend,
<hallyn> but really the 'do it better' should be to use socket activation in upstart
<jgrimm> and your last comment was about planning to sru to trusty
<hallyn> oh
<jgrimm> hallyn, right, reporter was on trusty and hoping to get it SRU'd back.  that's what i was noting
<hallyn> should be a trivial SRU fwiw
 * hallyn bbl
<jgrimm> hallyn, no worries.. that's what i was checking on, whether you'd lost interest or still interesting in seeing it through
<hallyn> jgrimm: it'll be very simple, and would be a good one for a new contributor.  if you find one feel free to have them ping me to sponsor
<jgrimm> hallyn, ack. thanks!
<jgrimm> hallyn, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1285850   is there a SRU required to Xenial or just open task in case there is still an issue?
<ubottu> Launchpad bug 1285850 in lxc (Ubuntu Xenial) "interuppting lxc-clone can destroy source container" [High,Confirmed]
<hallyn> jgrimm: i'm 99% sure that's fixed in xenial as stgraber has sru'd newer pkgs
<nacc> to trigger a rebuild of python-docutils (which should not ftbfs now that there is a new xml-core), do I just upload a new version -- or will the next test rebuild just automatically pick up the fix?
<jgrimm> hallyn, that's what it sort of sounded like. maybe we mark xenial/yakkety as Fix Released (with comment of please open a new bug if <blah, blah, blah>
<hallyn> yup
<jgrimm> tx
<hallyn> thx - ttyl
<nacc> jgrimm: i think you saw my update on heimdal last night -- how did you want to proceed?
<jgrimm> nacc, which part? that debian is investigating dropping? or the current upload's failures?
<nacc> jgrimm: yeah, that debian is dropping it -- and that the failures aren't resolved yet (and i'm not knowledgeable enough to know why ... yet). The debian patch leads to a different failure and i've updated hte upstream bug, but there hasn't been any response yet (afaict)
<jgrimm> oh let me go look at the different failure
<nacc> https://github.com/heimdal/heimdal/issues/175]
<nacc> bah, without the ]
<nacc> jgrimm: so the debian patch does fix something, but the tests still fail for me
<nacc> right at the very end of the test
<nacc> jgrimm: ha! ok, so i did a quick re-run manually and it passed
<nacc> jgrimm: then ran `make check` manually and it passed as well
<nacc> jgrimm: let me see if i can reproduce that, i wonder if the tests are running in parallel again
<jgrimm> nacc, ah .. k
<nacc> so i'm trying to help migrate heimdal along from proposed. I've got a build fix for it that fixes the current issue, but it still fails to sbuild due to a test failure. However, if i drop to the schroot after failure and run the test manually (eitehr `./debian/rules dh_override_auto_test` or `make check`), it passes. Any suggestions on how to debug that?
<nacc> jgrimm: i can upload the fixed version, but i'm not sure what do about the above --^
<jgrimm> nacc, ack
<dobey> hmm, how can i get sbuild to run a script from the host system, inside the builddir
<nacc> dobey: i think setup-hook does that, but it says its deprecated :)
<dobey> and it just adds that to --chroot-setup-commands; which afaik are not executed within the builddir, and not sure it copies scripts into the chroot first
<dobey> and pwd for --pre-build-commands is the wrong place too
<nacc> dobey: yeah, reading https://wiki.debian.org/sbuild external commands
<nacc> the implication is that it can run in the chroot
<nacc> but not obvious which one
<nacc> and not sure it's copied automatically as opposed to you need to copy it in first?
<nacc> man sbuild implies at elast pre-build-commands and chroot-setup-commands are run in the chroot
<nacc> although
<nacc> 'EXTERNAL COMMANDS' contradicts that
<dobey> pre-build-commands is run outside the chroot
<nacc> chroot-setup/cleanup- are run in the chroot
<nacc> dobey: man sbuild implies the wdir for the chroot-setup-command should be the BUILDDIR
<nacc> dobey: but taht doesn't really help with your script question, i wonder if you coud in pre-build-commands copy the script in and then in the chroot-setup-command execute the script?
<dobey> well pwd is nowhere near the chroot with pre-build-commands, so it doesn't help at all afaict
<nacc> dobey: you can use %b
<nacc> mabye?
<dobey> ?
<nacc> to get to the build-dir in the command definition
<nacc> sbuild has some special escapes
<dobey> hmm
<nacc>   %b, %SBUILD_BUILD_DIR
<nacc> and %p, %SBUILD_PKGBUILD_DIR
<nacc> which can be used for these external commands and i guess sbuild substitutes them for you
 * nacc is thinking something like `sbuild --pre-build-commands='cp /path/to/script/ %b/...'
<nacc> dobey: %e might also work
<nacc> dobey: and might be the fastest way, although i don't see any example :)
<dobey> what's difference beetwee BUILD and PKGBUILD though?
<dobey> latter is destinatio nfor binaries?
<nacc> e.g., in my sbuild of heimdal
<nacc> build/heimdal-yPecJ8 is BUILDDIR
<nacc> build/heimdal-yPecJ8/heimdal-1.7~git20160703+dfsg
<nacc> is PKGBUILDDIR
<dobey> hmm ok
<nacc> based upon the log output
<nacc> %e's description implies it's the best way to copy data in/out from the host to the chroot
<nacc> ah i see
<nacc> what that does is something like schroot -c {id} --run-session -q -u root -p -- ....
<nacc> so it runs a script defined in the host system but in the chroot
<dobey> i don't see %e in the man page
<nacc> oh im on 16.10 and it's new :)
<nacc> dobey: sorry about that
<dobey> no worries
<nacc> dobey: so it seems like ther are some options for 16.04's sbuild ... 16.10's makes it a bit easier :)
<dobey> oh nice. %p doesn't exist yet in --pre-build-commands
<nacc> bah
<dobey> but that might be ok
<nacc> dobey: any cahnce you want to run 16.10 :)
<dobey> no
<dobey> i think this is actually running on a 14.04 host
<nacc> ah
<doko_> nacc: were there still some outstanding merges / ftbfs from your side?
<nacc> doko_: i think the ones i've figured out are all uploaded
<nacc> doko_: the openstack ones are all in -proposed per coreycb
<doko_> ok, will be mostly offline until Oct 04
<nacc> doko_: ok, i'll try and get the others figured out soon
<nacc> doko_: http://qa.ubuntuwire.com/ftbfs/ only is for packages in -proposed, or is it the archive but using proposed?
<dobey> 19:14:50 W: The %SBUILD_CHROOT_DIR and %r percentage escapes are deprecated and should not be used anymore. Please use %SBUILD_CHROOT_EXEC or %e instead.
<doko_> nacc: everything is built using -proposed. however the test rebuilds find stuff which gets broken by some changes in the build dependencies
<dobey> ah, hrmm
<nacc> dobey: heh
<nacc> doko_: got it
<nacc> dobey: seems weird if the manpage didn't mention %e ...
<dobey> nacc: i can't run man on the machine where the sbuild actually runs
<dobey> nacc: it has sbuild 0.71 though
<nacc> dobey: oh ok that's whats in 16.10
<nacc> dobey: and afaict only in 16.10
<nacc> yeah, they got rid of SBUILD_CHROOT_DIR when they added SBUILD_CHROOT_EXEC, i think
<dobey> nacc: and whatever PPA it was installed from. this server is definitely not running 16.10 :)
<nacc> dobey: ah true, that could be it
<dobey> well, it's deprecated, but not gone yet
<nacc> dobey: err, right, sorry, meant deprecated (one of the options at the time was to just outright remove it)
<dobey> 'cat blub.txt | %SBUILD_CHROOT_EXEC sh -c "cat > blub.txt"'
<dobey> ewww
<nacc> it doesn't seem lik eyou should need to do that though
<nacc> mabye you do, but that's not how i read the %e bits
<dobey> that's the example in the man page
<nacc> ah
<dobey> and yeah, the description of %e suggests one must funnel data through STDIN/STDOUT of one process in the host and the proccess being run in the chroot
<dobey> which is kind of nasty
<nacc> it seems like if you just need to run a script in the chroot, you could do 'cat script | %e sh -c -s' ?
<nacc> if you just needed to run a script
<dobey> well i need to run a script at start up. but then i need to find files and copy them back out after the build
<dobey> if i could just dumpt them in %SBUILD_BUILD_DIR and sbuild magically copies them back out, that'd work fine, but i'm not sure that's what it does
<nacc> yeah, not obvious to me either ... i guess you could reverse the above command to extract from the chroot, if you konw what they are in post-build-commands
<dobey> hmm, i'll try --finished-build-commands to see if dumping files in build dir just works
<dobey> nope. sbuild doesn't just copy everything out. only the binaries/changes from debuild it seems :-/
<nacc> dobey: hrm :?
<nacc> *:/
<tjaalton> anyone bumped into an issue with autopkgtest on lxd failing with "tar: ./control: Cannot change ownership to uid 12345, gid 12345, invalid argument"?
<dobey> bah, dpkg-source doesn't get run until after --starting-build-commands :(
<tjaalton> ah, needed to use sudo with autopkgtest
<nacc> dobey: you mean the xtract step?
<nacc> jgrimm: did you have a srcpkg handy that needed the vcs field change?
 * jgrimm looks. been a while since I filed that bug
<jgrimm> nacc, it was nspr
<nacc> jgrimm: thanks
<jgrimm> np
<nacc> jgrimm: reproduced the python-cffi ftbfs on diamond, will debug there
<nacc> i'm guessing it's an arch assumption
<nacc> but not sure yet what
<nacc> balloons: fyi, juju-core ftbfs on yakkety-proposed (http://qa.ubuntuwire.com/ftbfs/#ubuntu-server)
<nacc> stgraber: fyi, lxc also ftbfs there
<stgraber> nacc: yeah, doko_ is looking at it. We'll just revert his change if we can't get this resolved soon.
#ubuntu-devel 2016-10-01
<nacc> stgraber: thanks!
<Guest85513> hi
<dadio> ziga: I think it's better to remove your command-not-found launchpad project? I contacted Michael Vogt about that, but he didn't respond.
<dadio> ziga: now people are making bug reports on your project. Does anybody look at these bug reports?
#ubuntu-devel 2016-10-02
<tmus> Yakkety appears to have switch back from resolved to dnsmasq, but it seems resolver server order is broken... Example: we have split-DNS in certain cases. server.example.com resolves to a public IP on the internet, but a 10.x.x.x address when on LAN (or VPN)...
<tmus> Pinging server.example.com from internet, connection to VPN and inging server.example.com again results in the same public IP being pinged... This is not how it used to be and it breaks situations like this.
<tmus> Known problem?
<tmus> DNS issues reported as bug #1629611 for anyone experiencing the same
<ubottu> bug 1629611 in network-manager (Ubuntu) "dns server priority broken" [Undecided,New] https://launchpad.net/bugs/1629611
<amito> hi
<amito> anyone on the multipath-tools source?
<gebruiker> is there a ureadahead patch that gets applied to the ubuntu kernel? https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1176536 ? shows nothing
<ubottu> Launchpad bug 1176536 in ureadahead (Ubuntu) "ureadahead is incompatible with newer kernels" [Undecided,Confirmed]
#ubuntu-devel 2017-09-25
<LocutusOfBorg> mitya57, what about a qtwebkit-opensource-src sync now?
<LocutusOfBorg> hello, what is the plan for unity integration? e.g. I would sync geary from Debian, the delta was about libunity-dev and libmessaging-menu-dev
<LocutusOfBorg> jbicha, ^^^
<sladen> madigens: ircnick@u.c
<mitya57> LocutusOfBorg, one thing that concerns me in new webkit is https://github.com/annulen/webkit/issues/573
<mitya57> Or do you mean sync from unstable? If yes then it is mostly equal to the current upload, so I donât see the point.
<juliank> mitya57: I guess the point is: The diff is not needed anymore, so let's sync it.
<juliank> So people like minimizing diffs *a lot*
<LocutusOfBorg> exactly
<mitya57> Ok, feel free to sync it then :)
<LocutusOfBorg> drop diff autosync FTW
<mitya57> For Qt autosyncs are bad because upgrades such as 5.9.1 â 5.9.2 need to be done through a transition, synced versions without rdeps rebuild will just get stuck in -proposed.
<LocutusOfBorg> rbalint, thanks! sponsored
<LocutusOfBorg> >For Qt autosyncs are bad because upgrades such as 5.9.1 â 5.9.2 need to be done through a transition, synced versions without rdeps rebuild will just get stuck in -proposed.
<LocutusOfBorg> this is how transitions work usually
<LocutusOfBorg> we can even ask to blacklist qt autosyncs and then use silo to transition
<LocutusOfBorg> but having a delta just to avoid autosyncs is worse than having them blacklisted :)
<atkinchris> Has anyone experimented with offering read-only mounts of snapshots/persistent with Casper, much like live-boot's "persistence-read-only"?
<jbicha> LocutusOfBorg: I think our general thinking for 17.10 is that we shouldn't rip out Unity integration without a good reason (like if it's too much work to update a patch)
<jbicha> if you disagree, you're welcome to start a conversation on the mailing lists about that approach (maybe when 18.04 development opens)
<mitya57> LocutusOfBorg, qtwebkit FTBFS on armhf, I am uploading a version with Ubuntu delta again
<mitya57> This is needed only once, the version in experimental builds fine without delta: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2922/+packages
<coreycb> bdmurray: good morning. if you have some cycles this week, i uploaded an ocata point release and a bug fix for python-oslo.middleware to the zesty review queue late last week.
<cpaelzer> infinity: hi can I catch you at some point today to sync on the SLOF FFE testing to DTRT on it?
<cpaelzer> what time would be good for you
<sarnold> cpaelzer: note infinity's not at the rally
<cpaelzer> sarnold: oh really I just searched the doc
<cpaelzer> maybe he is at the not attending or cancel line
<cpaelzer> I didn't check
<cpaelzer> thanks sarnold
<mwhudson> apw, sforshee: well so the making disk images hack worked but i lost all the setuid bits
<cpaelzer> he is on the list sarnold, but you sound like you know as a fact - I hope nothing bad happened
<slangasek> cpaelzer: yes, he's unavailable this week; can you point me at the FFe bug?
<cpaelzer> slangasek: 1706248
<cpaelzer> slangasek: he was "kind of ok" but wanted a test - and I agree but wanted to check quickly what to test
<cpaelzer> slangasek: I can come down and talk with you about it if you are ok?
<cpaelzer> it is just to make sure not doing a verification that isn't worth anything in your POV
<cpaelzer> slangasek: well you just entered our room, so I try to catch you when you leave :-)
<slangasek> cpaelzer: let's sync on the way to lunch ;)
<cpaelzer> ok slangasek
<slangasek> cpaelzer: 'test' here can just be a smoketest, to make sure the new slof works with our existing qemu package in artful and boot an Ubuntu VM
<slangasek> cpaelzer: does slof support netbooting?  If so that would be gravy; AFAIK we don't rely on that functionality anywhere
<cpaelzer> it does support pxe boot IIRC but I have no maas around to test drive that
<cpaelzer> but I can certainly ensure that the usual guest lifecycle works
<cpaelzer> unfortunately artful install seems to be broken again on my test system but I'll get some test going
<slangasek> cpaelzer: since this is slof as we will only use in VMs, and we don't rely on VM netbooting, that's not critical to test
<mwhudson> apw: i managed to hack something that mostly works, thanks for the tip
<rbasak> cjwatson: on dep14 (git branch and tag names), we're importing and tagging our view of Launchpad's publication of Debian package uploads. That's outside the spec I think. It doesn't belong in debian/* as we'd expect the DD to own that namespace. But it doesn't belong in ubuntu/* either.
<rbasak> So I'm not sure if what we're doing there matches your expectations.
<rbasak> https://git.launchpad.net/~usd-import-team/ubuntu/+source/vim/refs/ is an example
<nacc> we could shove all of that under launchpad/ if we wanted
<nacc> but that's just more indirection
<rbasak> We're also using upstream/* as specified by dep14, but those could collide with the DD's tree objects if there are minor import differences.
<rbasak> cjwatson: so I said before to you that "we're following dep14" but I guess that's not really true :-/
<rbasak> Other edge cases are that we need two pristine-tar branches to accomodate orig tarball differences.
<rbasak> Really we're only following dep14 substitution rules I think.
<nacc> (after fixing them :)
<rbasak> :)
<rbasak> nacc: "Patch queue tags" is something I don't remember considering before. Should we use that for our applied tags?
<rbasak> nacc: anyway, sorry, I'll let you get on with other things. We can discuss later.
<nacc> rbasak: it doesn't feel well-defined in dep14. we do use gbp-pq annotation a la dgit
<wxl> \
<LocutusOfBorg> jbicha, I agree ok
<LocutusOfBorg> mitya57, thanks!
<seb128> bdmurray, hey, what's the right way to push a SRU forward if some bugs failed verification (the fix is not perfect but fixes some issues so the SRU is still an improvement and there is no regression so we would like to get it pushed)
<seb128> it's about https://launchpad.net/ubuntu/+source/pulseaudio/1:8.0-0ubuntu3.4
<bdmurray> seb128: talk to me or better talk to an SRU team member who is also an archive admin as they can fully phase the update
<seb128> bdmurray, well first that one needs to be moved out of proposed
<seb128> it's not in updates yet
<bdmurray> seb128: Oh, okay then I can help with that.
<seb128> bdmurray, anyway I'm speaking to you there ... is there an alias that contact sru team people?
<seb128> rather than having to bother you directly (for next time)
<bdmurray> seb128: No, I believe most SRU team members are subscribed to the ubuntu release mailing list so that should work.
<seb128> k
<bdmurray> seb128: so the argument for getting it into updates is that one bug failed verification but the fix for that makes things better and the other bugs are verified?
<seb128> bdmurray, not exactly, the argument is that one fix is not working but 3 other issues are fixed and there are regressions
<seb128> well or rather the 2 fixes fixes 3 of the 4 issues we though they would fix
<seb128> and there is no regression
<seb128> so it's still an improvement
<bdmurray> seb128: ack, will release it in a bit.
<seb128> bdmurray, thanks
<smoser> cjwatson, what is the "syntax" in a git commit message for a debian bug.
<smoser> akin to:
<smoser>  LP: #XXXXXX
<nacc> smoser: do you mean Closes: # ?
<smoser> no.
<smoser> not restricted to debian/changelog.
<smoser> in a git commit message, i reference a bug with new line then LP: #XXXXX
<cjwatson> smoser: https://help.launchpad.net/Code/Git#Linking_to_bugs
<cjwatson> oh a *Debian* bug
<cjwatson> do what you like
<cjwatson> I'd say "Debian: #nnn"
<cjwatson> but it's up to you
<smoser> right. thats what i was asking. if there was something in place already.
<smoser> ok. i'll just use Debian: #nnn
<smoser> thanks.
<nacc> I mean, afaict, it doesn't link it to a Debian bug or anything (where it = Launchpad)
<cjwatson> nothing in place, no - LP doesn't track that directly except by way of bugs that have been synced into LP
<nacc> yep
<mwhudson> bladernr: hey, btw subiquity user testing is in shubert tomorrow morning, the event doesn't have a location and i can't add it
<as2000> how can I get the applications menu extension to work in 17.10?
<nacc> as2000: i think you want #ubuntu+1
<as2000> thanks
#ubuntu-devel 2017-09-26
<LocutusOfBorg> doko, that gcc regression is scary
<LocutusOfBorg> 7.2.0-4 was good, 7.2.0-7 is ICE on i386, I'm testing with 7.2.0-5 right now
<jbicha> Unit193: did you see https://bugs.debian.org/866657 ? xiphos 4.0.7 has a --enable-webkit2 flag that you could try
<ubottu> Debian bug 866657 in src:xiphos "xiphos: depends on libwebkitgtk-3.0-0 which is deprecated" [Serious,Open]
<doko> LocutusOfBorg: please attach the preprocessed source
<rbasak> LocutusOfBorg, rbalint: please see https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2017-September/017697.html
<rbasak> dpkg-vendor isn't available at runtime?
<cjwatson> Not in general; it's in dpkg-dev
<cjwatson> Ah, indeed, that says that
<cjwatson> Usually best to either use lsb_release at runtime or to use dpkg-vendor at build time and substitute the result into scripts
<LocutusOfBorg> rbalint, do I smell a patch?
<rbalint> LocutusOfBorg: yes, thanks for the heads-up
<rbasak> Please thank the guy on the list :)
<LocutusOfBorg> thanks to you too!
<LocutusOfBorg> I?m daily subscribed to that list, somewhat I missed it
<rbalint> LocutusOfBorg: LP: #1719630, please sponsor it if you like the patch
<ubottu> Launchpad bug 1719630 in unattended-upgrades (Ubuntu) "unattended-upgrades uses dpkg-vendor but doesn't depend on dpkg-dev" [High,Confirmed] https://launchpad.net/bugs/1719630
<LocutusOfBorg> done thanks
<LocutusOfBorg> rbalint, can't update the bug report, launchpad OOPS
<LocutusOfBorg>  (Error ID: OOPS-2e3d23b275c4532a522ad06226c897df)
<jdstrand> doko: fyi, I'm getting pulled into a meeting with vendors so may be late/not be able to attend the MIR meeting
<bdmurray> coreycb: come to find out nova has an existing SRU in process / unverified.
<coreycb> bdmurray: ah alright
<coreycb> bdmurray: thanks
<sil2100> robert_ancell: hey!
<robert_ancell> sil2100: hi
<doko> jdstrand, nacc: ping MIR meeting (in the lobby area)
<sarnold> doko: I don't think nacc's here
<doko> yeah, trying to get in touch with him on hangouts
<jdstrand> doko: I sent you a message a little while ago: 10:08 < jdstrand> doko: fyi, I'm getting pulled into a meeting with vendors so may be late/not be able to attend the MIR meeting
<ogra_> persia, pingaling !
<jdstrand> doko: did you see ^ (sorry I didn't make the meeting)
<bmw> rbasak: I wanted to check in on the status of the Certbot SRU
<bmw> the packages have had some time to bake in proposed and the test I wrote up passes for all packages
<smoser> hey. wonder if someone could read my response on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852569
<ubottu> Debian bug 852569 in cloud-initramfs-tools "cloud-initramfs-tools: Update udevadm path" [Serious,Open]
<smoser> i can (and it seems right to me) make 'copy_exec' search the PATH in initramfs-tools
<rbasak> bmw: o/
<rbasak> bmw: I'm sprinting this week. I'm a little concerned about the transitional packages that failed to build. I'm going to ask other SRU team members about that this week.
<rbasak> bmw: apart from that, if the bug is verified then we're good to release.
<rbasak> bmw: as soon as we do, a large number of users will get the update. How confident are you about that?
<bmw> rbasak: great! if the build failures are something where knowledge of Certbot internals would be useful, I'm happy to take a look
<bmw> I'm very confident in the update
<rbasak> bmw: it's because the old certbot (letsencrypt) is building against the new acme I think.
<bmw> the majority of our users are still using "certbot-auto" which is our self updating alternative to packaging where we were waiting for packages to be created
<bmw> this is hundreds of thousands of users and we've been auto updating them the whole time
<rbasak> bmw: example: https://launchpadlibrarian.net/335455860/buildlog_ubuntu-xenial-amd64.python-letsencrypt_0.4.1-1ubuntu0.16.04.1_BUILDING.txt.gz
<bmw> I don't expect any problems at all
<bmw> that'd do it
<rbasak> I didn't think of that issue before. Even if you say it can be patched to work,I think it's probably really a packaging issue that I'd like to discuss with experienced distro people
<rbasak> As a different approach to the one I've taken may be more appropriate.
<bmw> for better or worse, all of the different packages are released in lockstep right now and depend on a specific version
<rbasak> Yeah
<rbasak> Excactly - we don't want to be trying to build the old one against a new library anyway.
<bmw> is the build still failing or did it just fail intermittently as the new packages were being added to the repo?
<rbasak> I made the mistake* of getting those through last, so it's trying to build against the updated packages.
<rbasak> The other way round it would have worked.
<rbasak> But it exposes a fundamental flaw in my approach, so I guess it's good it happened in a way.
<rbasak> The failure is a one-off. I can request a retry, but I believe I understand the problem and it'll recur so there's no point.
<rbasak> I'll explain the details to others this week and see if we can decide how we should approach this instead (or indeed if we need to approach it at all).
<bmw> OK sounds good
<rbasak> My original point is to keep python-letsencrypt still buildable in case some users are using "import letsencrypt" in their own code and we don't want to break them.
<rbasak> But I've now failed at that :-(
<bmw> yeah we definitely want that to still work
<bmw> similarly, which package handles creating a "letsencrypt" executable in the user's path that runs the renamed certbot?
<rbasak> Oh
<rbasak> We may not have handled that.
<rbasak> I'll need to check.
<rbasak> It may be that the certbot package does it correctly already and that came over from Debian.
<bmw> OK
<bmw> my tests scripts don't test things like that as it'll only apply to the xenial packages, but I'll do some testing to make sure both of those things work and if not I strongly think they should be fixed before we release
<rbasak> I agree. Thanks for checking!
<rbasak> bmw: perhaps we should check that for all future SRUs? If it makes sense we should add it to the list of things to check - in the policy document if not in your test script.
<bmw> definitely
<bmw> I should be able to add something like that to my script so it's automated
<rbasak> Thanks!
<slangasek> kees, infinity, stgraber: TB meeting?
<seb128> slangasek, cyphermox, xnox, would anyone be interested helping oSoMoN to figure out why it's artwork has  NetworkManager-wait-online.service delaying boot/timeouting?
<seb128> seems like there are a few similar reports on launchpad and the type of issue we want to see addressed for 17.10?
<slangasek> seb128: it absolutely is something we want addressed, and yes, we're seeing that escalated from several quarters; cyphermox can you take point on that?
<seb128> slangasek, cyphermox, should we come downstair with the machine if you want to have a look with us? we just spend an hour poking in systemd-bootchar and blame and logs but I don't think we are efficient/know where to poke
<cyphermox> seb128: by all means
<cyphermox> or I can come upstairs
<sil2100> seb128: how much is it delaying the boot?
<seb128> cyphermox, if you want to come to the desktop room you are welcome. Laney suggested to just "sudo systemctl mask systemd-networkd-wait-online" which he said xnox is going to make systemd do in his next upload ... is that right?
<seb128> sil2100, 30s timeout from NetworkManager-wait-online.service it seems
<ddstreet> Laney I just re-submitted my merge request for ubuntu-dev-tools, you have a lot of history with pull-lp-source, if you have time can you reivew my changes?  https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/322863
<ddstreet> for lp 1453330
<ubottu> Launchpad bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
<johnnyfive> Hello. I'm writing an implementation of the repo meta-data creation process in Go, and have a few questions.
<johnnyfive> The big one is where the canonical place to get extra information like the Homepage, Bug URL, etc, for any given package? Used in the Packages file: http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
<sarnold> johnnyfive: debian/control files maybe? http://sources.debian.net/src/systemd/234-2/debian/control/
<johnnyfive> sarnold: you rock
<sarnold> \o/
<seb128> which is maintaining unattended-upgrades/is the person to talk about it?
<sarnold> seb128: rbalint and LocutusOfBorg were discussing it earlier, about https://launchpad.net/bugs/1719630
<ubottu> Launchpad bug 1719630 in unattended-upgrades (Ubuntu Artful) "unattended-upgrades uses dpkg-vendor but doesn't depend on dpkg-dev" [High,Fix released]
<seb128> sarnold, thanks
<xnox> seb128, slangasek, oSoMoN, cyphermox - sure, but only with 234-2ubuntu11 installed =)
<seb128> xnox, when can we expect that to be uploaded?
<seb128> xnox, by uploaded I mean approved :p
<xnox> seb128, you can use one from ppa:xnox/nonvirt, and i think you can ping sil2100 about approving it ;-)
<seb128> sil2100, ^
<juliank> I'd have expected most problems to be solved now. Of course, lxd and virtualbox and friends all do the same network-online Wants, but network-online being part of the order is essentially still a bug in rc.local.service
<juliank> now = with apt getting rid of the dep
<sil2100> I already kicked new builds
<juliank> Essentially what will happen eventually (at least in Debian) is systemd dropping debian/extra/units/rc-local.service.d/debian.conf which causes network-online.target to become ordered before the login targets
<juliank> dropping the After=network-online.target, that is
<juliank> This seems far more helpful than just breaking network-online.target IMO
<seb128> xnox, ^ that's for you I guess?
<seb128> sil2100, beta is on thursday, time for new packages and rebuilds :)
<juliank> mbiebl: I noticed that that change ^ (removing the After=network-online.target for the rc.local.service drop-in) we agreed on in #debian-systemd has not been committed yet in the git, I hope we don't forget about this thing
<xnox> juliank, there is no bug in rc.local.service, as rc-local.service is not enabled by default on ubuntu
<juliank> xnox: How else is it pulled in then that it affects actual boot performance?
<juliank> If you have an LSB script, it'd pull it in too, but I think that does not have any ordering related to login and so on.
<juliank> I just spent an entire day looking for bugs on slow boots, and I did not find any, really
<juliank> I mean I see https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1700382, but that just says boot slow
<ubottu> Launchpad bug 1700382 in systemd (Ubuntu) "Boot times slow when LXD installed, due to poorly crafted systemd dependency chain" [Undecided,New]
<juliank> But it's looking for graphical.target or complete boot time, which is the wrong question to ask
<juliank> (you want to know when the system is usable, not when boot is complete, as that stuff might run in the background while you're already working)
<juliank> oh and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714301
<ubottu> Launchpad bug 1714301 in systemd (Ubuntu Artful) "systemd-networkd hangs my boot (wireless)" [Critical,Confirmed]
<juliank> But that contains no information whatsoever
<juliank> I'd be really interested to see the dependency chains that is causing this to be part of the ordering
<seb128> sil2100, should maybe accept the systemd update, that's the sort of changes you want to get more testing/feedback on so better to have in included in beta?
<juliank> xnox: As for rc.local, it was enabled on 16.04 at least. The rc.local file was dropped at some point, but not removed on upgrades. Was the unit explictly disabled  later on?
<Unit193> jbicha: I've seen it, and webkit2 requires gtkhtml which Debian removed.
<jbicha> Unit193: xiphos is on the remove list at LP: #1710318 I'm not sure how much of that will happen for 17.10 but I think it's very unlikely the old webkitgtk will be available in 18.04 LTS
<ubottu> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
 * juliank does not see anything about rc.local in the systemd changelog
<Unit193> Yep.
<juliank> jbicha: I don't understand your report about APT logging to systemd.
<juliank> jbicha: APT never logged to the system log.
<jbicha> juliank: maybe it should
<jbicha> Ubuntu's log viewer app only shows systemd logs, the log viewer in older Ubuntu releases also showed the apt logs
<juliank> jbicha: Well, but the same also applies to dpkg. In any case, we have both a history log and a terminal output capturing. We definitely don't want the latter in the journal.
<juliank> And history.log is Deb822 structured data
<juliank> I don't see how that fits together.
<jbicha> why definitely not?
<juliank> Because it contains all terminal interaction, including conffile prompts and stuff
<juliank> It's like the output of running dpkg in script(1)
<juliank> I'm not sure if it even contains data you wrote into debconf prompts
<jbicha> I would expect the history log to be in the systemd journal though
<jbicha> apt is somewhat unique in the default Ubuntu Desktop install for it to use "traditional" logging instead of the journal
<juliank> I guess you'd have to define a new output format for that
<juliank> I mean, it makes no sense to include the machine-readable deb822 data in such a log
<juliank> It's meant for tools to parse it and display it nicely
<jbicha> I think lots of stuff already dump machine-readable logs into the journal
<juliank> jbicha: And it's questionable if the apt log is that useful compared to the (more-detailed) dpkg.log
<juliank> There's also update-alternatives.log and friends
<juliank> jbicha: I guess it would definitely be an improvement for server workloads with centralized logging if we logged something, even if only history
<juliank> Then you can see that installs/upgrades happened, but if you need to investigate further you need the dpkg, installation planner and term logs likely
<juliank> jbicha: We definitely still need history.log for the eventually happening apt history command
<juliank> So we can have apt history revert ...
<sil2100> seb128: let me look at the changes there
<seb128> sil2100, thanks
<xnox> juliank, it is removed on upgrades in artful.
<xnox> juliank, in the upload that is in the upload queue ;-)
<juliank> Well yeah, but it was there before all the time
<juliank> But really, network-online.target is sort of a failure
<juliank> should not have existed
<sil2100> seb128: ok, let me accept this then and think about re-spinning later
<sil2100> I like the LP: #1714301 idea
<ubottu> Launchpad bug 1714301 in systemd (Ubuntu Artful) "systemd-networkd hangs my boot (wireless)" [Critical,Confirmed] https://launchpad.net/bugs/1714301
<sil2100> Will take ages to migrate probably, will check up on it after dinner
<sarnold> is ubuntu-geoip used for anything these days?
<Unit193> sarnold: unity-webapps-service and indicator-datetime both have: geoclue-ubuntu-geoip | geoclue-provider
<juliank> jbicha: Just sent a mail to the bug. guillem mentioned that chroots would also log to the main log then, which would be weird and not what we want. Imagine every sbuild or pbuilder run spamming your journal with apt logs
<juliank> totally confusing
<sarnold> Unit193: do we still care about webapps?
<sarnold> Unit193: wait. does _anyone_ still care about webapps?
<ddstreet> xnox are you planning on artful for lp 1714505 or post-artful?  just checking
<ubottu> Launchpad bug 1714505 in debian-installer-utils (Ubuntu) "systemd kmod builtin uses out of date kmod context" [Critical,New] https://launchpad.net/bugs/1714505
<sarnold> "oh good it's a web page but doesn't work like my favourite browser"
<sarnold> Unit193: probably the indicator-datetime thing can't be easily skpped. I wonder why I didn't see that one on my achine.
<Unit193> sarnold: That's the better question.  Looks like it was removed from Artful, so only the ohter.
<sarnold> Unit193: thanks.
<jbicha> juliank: I don't understand why chroots would log to the system journal. That sounds wrong. Anyway, I'm sure I'm not the only one that would ask the question so it's good to have a tracker bug for my request
<juliank> jbicha: Well, we'd have to log using syslog() or maybe there's some dbus-journal only thing? If we do syslog it works via /dev/log, which is a device.
<juliank> Obviously, syslog would be more portable
<juliank> I mean, for a lot of chroot scenarios (isolation of services), you want the chroots to report to the main journal, so I'd expect that to log to the parent journal, and not a chroot-specific journal (the chroot would need journald running for that anyway)
<jbicha> I would not assume that things running a in a chroot would typically be changing system files outside the chroot
<juliank> still sounds like a can of worms
<juliank> And logging is actually one socket
<juliank> I think systemd-nspawn at least does forward stuff
<juliank> and as soon as you bind mount /dev and /run you get the socket to journald
#ubuntu-devel 2017-09-27
<sil2100> xnox: the new systemd didn't migrate still, some ADT tests had failures (of course) - I re-run them and waiting for the others to finish
<sil2100> So new image will have to wait till tomorrow
 * sil2100 sighs
<sil2100> I knew that the new systemd is a no-good with its huge amounts of rdep tests to be run
<rbasak> rbalint: please could you reply to Frans on ubuntu-devel-discuss@? Or are you waiting on a moderator?
 * ogra_ tickles persia 
<ginggs> anyone with ben-fu able to help please?  https://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/498 r-api-3.4 is supposed to be good, r-api-3 is supposed to be bad
 * persia pulls ogra_'s tail
<ogra_> persia, hah ! just wrote you an email ...
<ogra_> persia, i'm sitting right above grand central station ... popey and i thought it would be cool to see you again ;)
<ogra_> perhaps you feel like droppying by here before friday
<persia> Clearly I've picked the wrong week to be in the UK :)
<ogra_> booooo !!!!
<sladen> persia: I'll be in the UK next week...
<persia> sladen: I'll not be :)
 * persia is clearly bad at scheduling
<ricotz> doko, hi, is there any progress on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874276 ?
<ubottu> Debian bug 874276 in ca-certificates-java "ca-certificates-java: fails to install on armhf: Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'" [Grave,Open]
<rbalint> rbasak: i'm on it
<rbalint> rbasak: i think it is waiting for moderator
<cpaelzer> doko: can I come down and borrow a few minutes of your time on a FTBFS I face since the last glibc update
<cpaelzer> I got through several stages of debugging to the root cause but currently stare and preprocced output of gcc and don't see where the differenc emight come from
<cpaelzer> if you have a few minutes let me know where to find you and I'll show you the case so you can redirect me the right way
<doko> cpaelzer: sure, I'm in the foundations room (gallery 1)
<gQuigs> xnox: Server classic img/iso i386 images are staying or going?  - they aren't mentioned either way in your email, but it does say to action the below
<nacc> well, fun stuff with update-manager today on artful. "Software Updater" is reporting that "Amazon" has updates, including apt!
<nacc> https://imgur.com/a/n4EIw
<rbasak> rbalint: thanks. I'm sure someone will moderate it soon.
<ogra_> sil2100, slangasek, seems our ubuntu-core-16-amd64.img on cdimage is only 600MB big while it should be 3G sparse, you cant really use it in kvm that way
<ogra_> sil2100, slangasek, that is http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
<ogra_> looks like we build with the wrong options
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/sda3       607M  503M   60M  90% /writable
<sil2100> ogra_: it's being built as it was set in the crontab for dailies
<slangasek> ogra_: correct, for the edge ones we are not currently building them sparse
<ogra_> sil2100, well, we used to build amd64 with a size option passed to ubuntu-image in the past
<slangasek> that is something that needs fixing
<ogra_> bschaefer, ^^^ so if i understand stve correctly you should be able to use the stable image then (if you need any features from edge you can just "snap refresh core --edge")
<ogra_> *steve
<bschaefer> ogra_, cool, no reason really i was using edge
<bschaefer> maybe theres some features i was needing :)
<bschaefer> thanks!
<ogra_> edge is definitely cooler ;)
 * ogra_ only uses edge :P
<ogra_> but yeah, there is usually no reason for normal users to use it
#ubuntu-devel 2017-09-28
<guest12345> hello room, i tried to get help from the ubuntu channel but i can't get in. it says im banned. can someone please help or lift the ban
<RAOF> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1720131 is the logind bug I filed
<ubottu> Launchpad bug 1720131 in systemd (Ubuntu) "logind holds open file descriptor to DRI nodes, preventing nvidia suspend" [Undecided,New]
<LocutusOfBorg> guest12345, register your nick
<LocutusOfBorg> guests are not allowed in some channels
<robert_ancell> RAOF: didn't file upstream?
<RAOF> robert_ancell: Not initially, no.
<RAOF> I guess I can if you want.
<robert_ancell> please :)
<RAOF> robert_ancell: Hah! I'm three days late: https://github.com/systemd/systemd/issues/6908
<robert_ancell> :)
<guest12345> it appears to be an ip ban
<guest12345> we have a static here at the office
<LocutusOfBorg> so go on #freenode and ask there
<LocutusOfBorg> jbicha, boinc mostly syncd :/
<jbicha> LocutusOfBorg: thank you
<doko> stgraber: sru team meeting in the ballroom
<cjwatson> juliank: I know it wasn't you who made the change (https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=cbaf353ead58aa9eefe51542b6ad91e69b6289ce), but do you know why this new bit of config is different from APT::Get::AllowUnauthenticated?
<juliank> cjwatson: no
<juliank> cjwatson: But I know that it's older than 3 years, so I'm not sure we can figure out why
<cjwatson> hmmm
<cjwatson> we just noticed that allow-unauthenticated recently stopped being effective on buildds
<cjwatson> e.g. https://launchpadlibrarian.net/339016030/buildlog_ubuntu-artful-amd64.node-babel_6.25.0+dfsg-7_BUILDING.txt.gz despite APT::Get::AllowUnauthenticated "1"
<cjwatson> (I'm fixing this particular case in another way, but it seems unexpected)
<juliank> cjwatson: Well, it's an unrelated setting, we just flipped the default for AllowInsecureRepositories to 0 recently
<cjwatson> mm.  so AllowInsecureRepositories affects update, AllowUnauthenticated affects other acquisition?
<juliank> cjwatson: mvo split allow-insecure-repositories and AllowDowngradeToInsecureRepositories off from unauthenticated in Oct 1, 2014
<juliank> cjwatson: I think to be complete AllowInsecureRepositories affects downloading unsigned Release files
<juliank> and the rest stuff with missing trust root from a release file
<cjwatson> hm, right
<cjwatson> thanks
<cjwatson> infinity1: ^- so maybe chroots should start setting Acquire::AllowInsecureRepositories as well?
<juliank> You can also set these options per sources.list entry
<cjwatson> Yeah I know
<cjwatson> And we're moving towards that (and indeed to dispatching necessary keys so that it mostly stops mattering)
<cjwatson> We're just not completely there
<cjwatson> In this particular case, https://code.launchpad.net/~cjwatson/launchpad/external-dependencies-trusted/+merge/331490 (plus a bootstrap-package change) should make it not a problem
<cjwatson> (or I guess here [allow-insecure=yes] rather than [trusted=yes] - will experiment)
<LocutusOfBorg> rbalint, unattended-upgrades new merge?
<LocutusOfBorg> and why can't you apply for PPU?
<rbalint> LocutusOfBorg: I applied for core dev
<jbicha> LocutusOfBorg: he is applying for Core Dev now https://wiki.ubuntu.com/BalintReczey/CoreDeveloperApplication
<rbalint> LocutusOfBorg: would be nice to have an other endorsement as two seems not to be not enough :-)
<rbalint> LocutusOfBorg: regarding unattended-upgrades I wanted to give it a few days in unstable but i plan filing the merge this week
<kyrofa> tkamppeter, https://bugs.launchpad.net/snapd/+bug/1655125
<ubottu> Launchpad bug 1655125 in snapd "Missing interface: content sharing in the other direction" [Undecided,Triaged]
<rbasak> bdmurray: http://paste.ubuntu.com/25634196/
<nacc> juliank: how should i loop properly on `apt update`/`apt-get update` completing successfully? It returns 0 (it seems) when it fails to download all index files
<juliank> nacc: You can't, really
<nacc> juliank: sigh :/
<nacc> juliank: ok
<nacc> cjwatson: how do the buildd's ensure they have a valid apt cache?
<nacc> (e.g., start a container, apt update which may or may not update but returns 0 no matter what, ... but we want apt install to work)
<cjwatson> nacc: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/lpbuildd/target/apt.py#L59
<nacc> cjwatson: thanks!
<cjwatson> crude, but good enough
<nacc> cjwatson: but wait, do you get a CalledProcessError?
<cjwatson> it certainly used to return non-zero when it failed to download all index files
<nacc> cjwatson: i thought that only got raised on non-zero?
<nacc> cjwatson: ah ok :)
<cjwatson> or at least in the relevant categories of failure
<nacc> cjwatson: on xenial it does not (in a lxd)
<cjwatson> maybe you're hitting something a bit different than buildds generally do
<nacc> maybe, yeah
<nacc> i can adapt your backoff logic
<nacc> (we have other network retry/backoff stuff anyways)
<cjwatson> it was a while ago, but when we did that our relatively frequent chroot failures basically went away
<nacc> yeah it makes sense
<nacc> cjwatson: juliank: thanks!
<tsimonq2> So I don't want to make Snaps and the backports policy isn't 100% clear... how would I go about requesting a 0 day Backports release of several LXQt components that saw a new upstream release recently?
<tsimonq2> Or rather, can something like that be done?
<tsimonq2> (Backports before a new devel release opens)
<persia> tsimonq2: I'm not sure what you mean by 0-day.  My experience has always been a) get new upstream version in Debian, b) sync to Ubuntu development repo, c) request backport (and providing testing feedback, etc.)
<tsimonq2> persia: Similar to the concept of a 0-day SRU
<persia> Ah.  I don't recall that happening, but I'll defer to someone paying closer attention these days.
<tsimonq2> Ok
<tsimonq2> Because if I test the packages in a PPA now, and they'll be synced when devel opens anyways, but the timing doesn't match up for artful-release, how would that go down?
<tsimonq2> And there's features in the packages.
<nacc> doko: is there any intention for ubuntu-dev-tools to become pythonn3? the wrapper scripts are *all* python2 :(
<nacc> doko: which it turns out when you try to snap them, means you need to build python2 and python3 and build the part twice
<nacc> once to get a python3 lib and once to get the python2 scripts
<sarnold> nacc: while you're fixing things maybe apport scripts too pls <3
<sarnold> hey est31 :)
<doko> nacc: feel free to update them ;) afaik most of them depend on launchpadlib ...
<nacc> doko: sigh :) ok
<est31> hello sarnold
<nacc> sarnold: heh
<doko> cjwatson: ^^^ is there a python3 replacement for launchpadlib?
<nacc> doko: launchpadlib works with python3
<nacc> doko: we use it heavily in git-ubuntu :)
<doko> ohh, then this changed
<doko> this and bzr keeps python2 for me on my laptop
<nacc> doko: it'd be a simple tweak to setup.py for the scripts to install on python3, but then they all nneed updates to not use /usr/bin/python
<cjwatson> python3-launchpadlib is mostly OK now in artful
<cjwatson> it was a bit dodgy in xenial
<nacc> yeah, i'm referring to the one on pypi
<cjwatson> right, it's up to date there now
<nacc> cjwatson: thanks for that :) helped enalbe the git-ubuntu snap
<cjwatson> I have a load of ubuntu-archive-tool updates which I need to get round to landing
<cjwatson> +s
<est31> wow someone on #ubuntu really wondered about TOR browser
<nacc> est31: they had an offensive nick and were being helped
<nacc> unclear why it escalated from there
<est31> I've got about 20 PMs from different nicks
<nacc> yep
<pfsmorigo> I only got two
<nacc> it was basically random, it seems
<ppisati_> doko: am i correct saying that we don't have a cross-compile toolchain from (!x86) to x86? e.g. cross-compile from arm64 host to i386 target?
<ricotz> doko, any chance to get this patch into arful? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874276#25
<ubottu> Debian bug 874276 in ca-certificates-java "ca-certificates-java: fails to install on armhf: Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'" [Grave,Open]
<manjo> meet @6:30 in the lobby for team dinner
* sil2100 changed the topic of #ubuntu-devel to: Zesty Released, Artful Beta 2 Released | Archive: final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
#ubuntu-devel 2017-09-29
<karstensrage> infinity, hope everything is well, maybe we could pick up next week?
<karstensrage> if you need time, i totally understand though
<ginggs> kirkland: hi! calc-stats FTBFS https://launchpad.net/ubuntu/+source/calc-stats/1.4-0ubuntu1 and the README file seems to relate to a different package
<LocutusOfBorg> ricotz, what is the rationale for that ca-certificates-java patch?
<LocutusOfBorg> as said on -release some days ago, the "fix" would be to not have postinsts for circular dependencies
<LocutusOfBorg> and/or to merge the two packages into a single one
<ricotz> LocutusOfBorg, hi, the rationale is obviously to fix its installation on armhf and therefore fixing builds of its rdepends like rustc on artful
<ricotz> LocutusOfBorg, I don't care about a better fix, just about it to be fixed and this did the trick here
<ricotz> e.g. this requires to be built, but fails due to this problem -- https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+build/13512402
<LocutusOfBorg> problem is that I don't get it, I think I can sponsor if you make me understand that change
<LocutusOfBorg>  maybe just for artful, we'll see
<ricotz> LocutusOfBorg, the problem is due to a openjdk-8 change the installation paths on armhf are different from other archs, ca-certificates-java mimics the jvm-*.cfg to work with a half-installed openjdk
<LocutusOfBorg> ok but does that temp_jvm_cfg file gets removed after?
<LocutusOfBorg> why is armhf different?
<ricotz> it will be overwritten by the real one
<LocutusOfBorg> why did this happen only on the last nmu?
<ricotz> LocutusOfBorg, don't ask me, ask the openjdk maintainer
<LocutusOfBorg> ok, can this change make the nmu1 reverted?
<LocutusOfBorg> e.g. switching again to openjdk8
<ricotz> this is not related to the nmu
<LocutusOfBorg> ack
<ricotz> openjdk being the cause is the reason I pinged d*oko about it
<ricotz> I will be back in a few hours
<LocutusOfBorg> I'm sponsoring it
<LocutusOfBorg> with some changelog changes
<ricotz> LocutusOfBorg, thanks
<LocutusOfBorg> ricotz, uploaded in debian
<soc> hey
<soc> is there a reason why wwidgets is still compiled against Gtk2 as a backend instead of Gtk3?
<jbicha> soc: it's a lot of work, there was some discussion on https://bugs.debian.org/790222
<ubottu> Debian bug 790222 in src:wxwidgets3.0 "wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated" [Serious,Fixed]
<soc> jbicha: thanks, just read the messages
<soc> so the old webkit dep is dropped, wxwidgets can use gtk3, but they haven't ported their webkit dep yet?
<jbicha> webkit is not the problem, it's making sure that everything wxwidgets works fine with gtk3
<soc> ah, so wxwidgets could be built with gtk3, but people aren't sure if that wouldn't introduce bugs in applications using wxwidgets?
<soc> jbicha: another, related question: gksu still depends on Gtk2, is there a Gtk3 replacement?
<soc> it looks like MATE ported gksu to gtk3 ..
<jbicha> apps should use PolicyKit
<soc> jbicha: what's the recommendation for launching apps with root privs?
<soc> e.g. gksu synaptic?
<jbicha> the recommendation is don't do it ;)
<soc> I beleive synaptic wont work any other way
<jbicha> you can try gnome-packagekit as an alternative to synaptic
<soc> uargh, caja-gksu depends on gksu?
<soc> just tried gnome-packagekit, that's sadly not what I want to use
<soc> jfc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842184
<ubottu> Debian bug 842184 in policykit-1-gnome "policykit-1: synaptic-pkexec no more work" [Serious,Fixed]
<jbicha> Ubuntu MATE 17.10 uses caja-admin instead of caja-gksu by default
<soc> I'm not sure caja-admin is what I want, it also pulls in a lot of dependencies
<soc> pkexec with those fixes mentioned in the bug report works!
<soc> just got rid of gksu
<soc> thanks!
<jdstrand> cyphermox: hey-- curious if you saw my comment https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1697730/comments/32
<ubottu> Launchpad bug 1697730 in nplan (Ubuntu Artful) "Long boot time due to systemd-networkd-wait-online.service failure" [High,Triaged]
<cyphermox> jdstrand: there was an issue with systemd to begin with, xnox was fixing this week
<cyphermox> but otherwise, yes, networkd should always be running, just not doing anything if it doesn't have configuration to deal with (and it should not have any on a desktop)
<cyphermox> the missing NM file sounds like an upgrade bug maybe?
<seb128> slangasek, bdmurray, is anyone from foundations coming in that stucked updates meeting?
<bdmurray> seb128: I'm not in NYC but could join a hangout.
<slangasek> seb128, bdmurray: sorry, I got pulled into another meeting, how did that phased-updates discussion go?
<bdmurray> slangasek: It was good althought I'd still like to discuss what to do with halted updates e.g. expiration
 * slangasek nods
<jdstrand> cyphermox: I talked to xnox, thanks
<xnox> juliank, is there a way to check that I am not racing with in progress apt at all?
<xnox> juliank, for example, apt-get check succeeds, even when apt-get update is in-flight
<xnox> =/
<kalikiana_> o/
<xnox> jdstrand, i think with libvirt however, there is a release-regression w.r.t. .libvirt machines
<xnox> jdstrand, .lxd is explicitely disabled.
<xnox> jdstrand, also stgraber says enabling .lxd resolution on the host will break things; and may not be possible with lxd-as-a-snap-only.
<cyphermox> jdstrand: cool
<kirkland> ginggs: fixed!  build successful now, thanks ;-)
<ginggs> kirkland: \o/
<Odd_Bloke> Laney: Someone just pointed me at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1530366 which refers to a packaging decision made because of having 4GB of RAM; I've just learned that we now have 8GB of RAM on the builders, so I'm wondering if the decision could be revisited?
<ubottu> Launchpad bug 1530366 in chromium-browser (Ubuntu) "1 second lag when opening URLs from the command line" [Low,Confirmed]
<Odd_Bloke> Laney: (Apologies if my "pick a random desktop person to ping" hasn't resulted in me talking to the correct person. :p)
<jbicha> Odd_Bloke: oSoMoN is the primary chromium-browser packager in Ubuntu now
<Odd_Bloke> oSoMoN: o/ What are your thoughts?
<Odd_Bloke> jbicha: Thanks. :)
<oSoMoN> Odd_Bloke, starting with chromium 61 we are now building with is_component_build=false (finally), so that issue should be fixed
<Odd_Bloke> Faux: ^
<Faux> :D
<xorpad> Hi
<xorpad> Who is in charge of the windows linux subsystem, does MS manage that or is it a FOSS project?
<nacc> !ubuwin | xorpad
<ubottu> xorpad: Canonical and Microsoft have announced that Windows 10 will be able to run Ubuntu programs without needing porting/recompilation. This functionality is still in beta and is not supported in #ubuntu. For discussion and support, see #ubuntu-on-windows.
<nacc> xorpad: afaik, it's Microsoft
<xorpad> Oh okay
<xorpad> I wanted to contribute to it, but MS doesn't like me
<xorpad> well not that they don't like me but they won't hire me
<xorpad> they liked me just fine for a job till I told them I never finished grade 5
 * xorpad shrugs
<ScottK> rbasak: You almost certainly want to sync the postfix I uploaded to Debian yesterday even though it's close to release.  Among other things, multi-instance should work now.
#ubuntu-devel 2017-09-30
<hallyn> so.  the artful desktop isntaller carefully askedme for networking details.
<hallyn> upon reboot, i find all that information has been dumped?
<hallyn> and it's back to "let's use dhcp"
<hallyn> maybe i'm misremembering, and hte desktop install didn't ask for those?
<dobey> i don't recall the installer ever doing network setup like that. you can set up netwokr in the "try ubuntu" shell so you can install updates during install, but i don't recall that it copied that config to the installed system
<d_ven0m> Hello, I'm trying to compile an upstream package with gnutls support. I have libcurl4-gnutls-dev, libgnutls-openssl27, and libgnutls30 installed from the repositories. I can't seem to find libgnutls30-dev anywhere, only libgnutls28-dev seems to be available. I was wondering where and what the right package is to use. Thanks
<maxb> It appears that libgnutls28-dev and libgnutls30 build from the same source package version, so I guess they do actually relate to each other... as odd as that seems
#ubuntu-devel 2017-10-01
<d_ven0m> That IS odd
<d_ven0m> I actually had a similar issue with the gnutls-dev libcurl
<d_ven0m> I have libcurl3, but there is no libcurl3-gnutls-dev, I had to install libcurl4-gnutls-dev
<d_ven0m> Turns out that solved my problem, and looking into it, apparently libcurl3 and libcurl4 don't change symbols so it doesn't affect compiling (at least to my knowledge). But I was always under the assumption that the number after the package name referred to a specific version of the package...
<maxb> If you look at the packages built from gnutls28 source, there are libgnutlsxx28 and libgnutls30
<maxb> So my guess would be that there was a change bumping only one of the libraries (twice), and leaving the -dev package name alone was least disruptive
<d_ven0m> aaah I guess that makes sense
<d_ven0m> Where did you find that btw?
<maxb> 'apt showsrc gnutls28' and some conjecture based on past experience
<d_ven0m> Hm, I get an error about putting source URIs in my sources.list, but shouldn't it be populated with the default repo URI?
<dobey> d_ven0m: no, source repos are disabled by default to speed up updates for people, as most people don't need them
<dobey> that change was made a couple years ago, iirc; they used to be enabled by default
<lotuspsychje> hey guys, im experiencing this bug in latest 17.10 up to date: https://bugzilla.gnome.org/show_bug.cgi?id=745032
<ubottu> Gnome bug 745032 in wayland "Mouse Tracking 'Laggy' on Wayland, and mouse movements cause frame drops in other OpenGL applications" [Normal,New]
<lotuspsychje> not sure if its related to each other, but got this bug running for ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1718653
<ubottu> Launchpad bug 1718653 in gnome-shell (Ubuntu) "Windows buttons gone on specific programs" [Undecided,Confirmed]
<jbicha> lotuspsychje: where did you get your theme from?
<lotuspsychje> jbicha: standard theme ambiance
<lotuspsychje> jbicha: tryed other default themes aswell, no dice
<jbicha> oh ok, you said "ambient" in the bug comments
<lotuspsychje> oh lemme change that my bad
<lotuspsychje> jbicha: gnome runned smooth for long time(on daily), as for few latest updates it went sluggish
<jbicha> lotuspsychje: please add more info about your graphics card and drivers to the 1718653 bug
<lotuspsychje> jbicha: ok will do
<lotuspsychje> jbicha: done
<jbicha> lotuspsychje: could you try booting a 4.12 Linux kernel?
<lotuspsychje> jbicha: yeah ill do it a bit later and add to the bug ok?
<jbicha> sure
<lotuspsychje> tnx
<soc> hey, does someone know where the lighdm maintainers hang around?
<rbasak> ScottK: thank you for letting us know. I'm off for a couple of days but have made a note.
<doko> ppisati_: yes. please send patches
<lotuspsychje> jbicha: booted Linux ArtfullBOX 4.12.0-11-generic but same moue & animations lag
<lotuspsychje> *mouse
<lotuspsychje> jbicha: would you like me to add that to the bug?
#ubuntu-devel 2018-09-24
<juliank> cjwatson, wgrant Regarding delta indexes, I built a fake Deltas index for xenial->xenial-updates with 3 deltas per update, and I landed at 563KB for mains Deltas.xz 829 KB for a Packages.xz
<juliank> The fields were Package, Old-ID, New-ID, Size, SHA256
<juliank> Not convinced
<juliank> I wonder if I should "just" inject SHA256 of complete debs in the dpkg status database
<juliank> and then I can save one hashsum
<juliank> because new-id = sha256 of delta
<juliank> um no
<juliank> I can however safe one ID, by using SHA256(old id | new id) as a field
<juliank> brings us down to 485 KB
<juliank> So, with Deltas index files, we'd be looking at 60% update time increase for a 80% install download-time decrease
<juliank> There was in fact the idea to have "smart" delta indexes once
<juliank> So update would download Packages files, then calculate upgrade download size
<juliank> and if size(Delta indexes) < some% of upgrade size, it would fetch Delta indexes and look for deltas
<juliank> oh, we need 4 deltas per update
<juliank> this does not scale well
<juliank> sizes of Deltas.xz ~ Packages.xz
<juliank> Wondering if a bloom filter might be worht it
<juliank> So update gets a bloom filter file for which updates have deltas
<juliank> "might have deltas"
<juliank> to reduce the number of fetches during install/upgrade
<juliank> when doing a per-source-package signature
<juliank> A SHA256 has 16 16 bit values we can use as hashes
<juliank> we then just need 2**16 bytes for the filter
<juliank> xenial-updates needs 12.3 KB bloom filter for a 0.75% false positive rate
<juliank> sounds OK
<juliank> 1.5% increase in update time to reduce failing delta lookups by about 40% or so
<sladen> juliank: this sounds exciting.  Is there more information somewhere?
<juliank> sladen: Yes, at https://debconf18.debconf.org/talks/66-delta-upgrades-revisited/, https://people.debian.org/~jak/dc18-deltas.pdf for example
<juliank> sladen: unless you mean the bloom filter specifically
<juliank> that just popped in today
<sladen> juliank: one possibly optimisation of this to provide N diff scripts, and 1x literal data per file.  This would allow one deltadeb to match a scalable number of the last $N package versions
<sladen> juliank: so for the moment you could just ship a 1:1 upgrade mapping, but it leaves open the possiblity for future optimisation
<juliank> sladen: complicated
<juliank> I mean, script is the wrong word
<juliank> I'm not sure where you'd integrate this
<juliank> on the ddelta level?
<juliank> Add a CRC32 of input data to each command, and then provide alternating blocks?
 * sladen re-finds https://www.uknof.org.uk/uknof6/Sladen-Delta-upgrades.pdf from a decade ago.  
<sladen> juliank: https://people.debian.org/~jak/dc18-deltas.pdf page 8,  each file has 1x "diff data" and 1x "extra data"
<juliank> Yes
<sladen> juliank: the suggestion would be that each file has Nx "diff data" and 1x "extra data".
<juliank> An there will be a CRC for diff data eventually (for the part we are adding the data too)
<juliank> So you could reasonably have an "or flag", too
<sladen> juliank: where the "bitmask" for the "extra data" can be expanded to cover the last N versions of a package
<juliank> But I think it gets too slow
 * sladen looks confused
<juliank> The problem is simple: If we have multiple diff data, we need to figure out which one to use
<juliank> for that we need to read the block / try to apply it
<juliank> if we fail, we'd have to seek back and start again
<juliank> unless you make the choice first
<sladen> per file, there is {1x input file (optionally validated by some hash), 1x "extra data", and 1x "diff data"}
<sladen> this gives a there is a one-way mapping   X+Y [transform via "diff data"] => Z
<juliank> you're still missing the point
 * sladen listens
<juliank> If I have n diffs for a given file
<juliank> how do I figure out which one to apply
<sladen> switch the question around
<sladen> if I have a starting input file with hash 0xdeadbeef, which diff do I *choose* to reach the end point
<juliank> you don't know anything about the file until you have started applying the delta
<sladen> (one assumes that you're already validating the input before processing it ;-)
<sladen> juliank: if you "don't know anything about the file", how did you find it on disk?
<juliank> I did not
<juliank> That's a different layer
<juliank> The real delta layer can only apply deltas given an old file
<sladen> yes
<juliank> On top of that there's the tree delta layer, which figures out the old name and the new one and stuff like that
<juliank> it's like literally a tarfile and a header with "old name" in it
<juliank> But of course
<juliank> we can just say "delta id 5 inside here is the delta for that combination"
<juliank> that said, you then increase the problem of finding the delta on the server
 * sladen raises an eyebrow
<juliank> your file name needs to identify to which upgrade the delta belongsd
<juliank> then you end up with pkg_id1_id2_id3_ddelta.deltadeb or something
<juliank> I'm not sure on the exact details yet
<juliank> the latest draft stage is at https://lists.debian.org/debian-dpkg/2018/09/msg00019.html
<juliank> and even that is somewhat out of data
<sladen> juliank: perhaps think of it a different way.  Lets say we have a package that is regularly (once a day updated), say the hypothetical "message-of-the-day.deb"
<juliank> as pkg_$old_$new_$algo.deltadeb might become $pkg_$hash($old|$new)_$algo.deltadeb
<juliank> 64 bytes less per delta
<sladen> juliank: only '/etc/motd' is changed in this package.  the other files, such as /usr/share/message-of-the-day/README remain unchanged
<sladen> juliank: for the last 5 versions, N .deltadebs are currently required, which at 98% the same.
 * sladen reads  https://lists.debian.org/debian-dpkg/2018/09/msg00019.html
<juliank> I fully understand the argument for that approach
<juliank> I don't think it's easily doable given the requirements
<juliank> The requirements for deltas are (1) min. seeks on old file (2) no seeks on delta (3) no seeks on new file
<juliank> If you want each block to store $n$ diff data for $n$ old versions (or store $n$ control blocks for $n$ old versions)
<juliank> you can easily do that
<juliank> just assign indexes to them and map indexes to old packages in the control.tar
<juliank> but that's not elegant
<juliank> To get rid of that, you have to make the decision which diffs to pick in the delta itself
<juliank> and that gets nasty.
<sladen> can this avoid duplicating the common parts of new literal data ("extra data")?
<juliank> sladen: Not sure, but duplication does not matter much
<juliank> it's a very tiny overhead after zstd/xz compression
<juliank> you could infact just include $n$ deltas I'd think for $n$ old versions
<sladen> ahhhh, okay it relies on the enormous window size of zstd/xz/etc
<juliank> Now, what will happen is that we get CRC32 soon for the "old" data we are adding diffs to, to ensure we are patching with the correct file
<juliank> s/ensure/increase confidence/
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<juliank> So my idea was that we could give each of these (diff, extra, seek) control triplets an "or" flag
<cyphermox> o/
<juliank> if the CRC does not match, we go to the next control entry
<juliank> that works, but it's somewhat inefficient
<juliank> because the diff block might be MBs large
<juliank> it also does not work after all, because we'd have to undo the write to the new file
<juliank> (i.e. seek back and truncate)
<juliank> but: Both the patch and the new file are a pipe
<juliank> (dpkg reads the patched file from the pipe, and calculates hashes before storing it on the system)
<juliank> You can solve that by just picking a fixed maximum window size you can keep in memory
<juliank> but um, for large files that slows things down a bit
<juliank> that said, for really big files, using windows during creation is a lot more effective
<juliank> I think  bsdiff generation is O(n^2) atm
<juliank> if you use blocks of $B$ bytes, it becomes (n/B*B^2)
<juliank> so it only grows linearly rather than quadratic
<sladen> juliank: in the msg0019 spec,  "if file.mtime >= installed_version.install_time or file.mtime > file.ctime or file.size != expected_size"  <-- probably a lot better to use a checksum to match before ingesting
<sladen> juliank: and once a checksum is used, that can become the primary matching key
<juliank> sladen: that's the paranoid mode
<juliank> our believe is that checksums are too slow to be practical here, and useless in most situations
<juliank> where us is me and some other people I talked to about this
<juliank> :)
<sladen> checkums are really slow if done on the server (rsync), but checksums on clients are $fast (cost of checksum is > than cost of downloading precious bytes)
<sladen> checkums are really slow if done on the server (rsync), but checksums on clients are $fast (cost of checksum is < than cost of downloading precious bytes)
<juliank> What you already have checked is that the files, when unpacked, have the right content
<juliank> because of the IDs identifying the content of the package, and you looking up deltas based on ids
<juliank> I'm unsure about the implications of actually hashing the files
<juliank> we will be reading them with a 60% probability
<juliank> because we'll be applying a delta
<juliank> and dpkg already hashes the files it is writing to the disk
<juliank> so the overhead should be less than 50%
<juliank> but let's measure
<juliank> I spent 47 seconds checking my 3326 packages
<juliank> on a fast Samsung SSD from this year
<juliank> this means that for an upgrade of 300 packages, I'd spent about 5 seconds
<juliank> *35 seconds with caches
<sladen> that's still presumably 99% disk I/O
<juliank> yes
<juliank> the non-paranoid mtime check only takes 1s
<sladen> that's not reading/checking any files, only filesystem structure
<juliank> that's the point
<juliank> we can be reasonably sure that the file has not been modified
<juliank> because it requires extreme stupidness or deviousness to change your mtime back to before install time
<juliank> or even build time
<juliank> When does that happen?
<juliank> Well, I'd say only if your clock is behind a few days/months, you have installed the package with the correct time, and you modify the file while keeping the bit length the same
<sladen> check mtime sounds like an optimisation that an upgrade is /probably/ possible.  -> fetch set of hash(es) is see whether it is really truely possible
<juliank> but we can protect against clock resets too I think
<juliank> I think
<sladen> juliank: is there a directory somewhere, with an extra set of .deltadebs to look at?
<sladen> s/extra/example/
<juliank> no
<juliank> https://github.com/julian-klode/ddelta/tree/demo has a delta generation script
<juliank> ./build-delta.sh $old $new $delta
<juliank> builds a delta from $old to $new and stores it as $delta
<juliank> * delta deb
<juliank> it's very primitive
<juliank> one thing it does is generate normal .deb with debian-binary instead of files with debian-delta
<juliank> but minor details
<juliank> ease of prototyping
<jibel> infinity, hi, could you have a  look at bug 1794137 ?
<ubottu> bug 1794137 in ubiquity (Ubuntu) "ubiquity FTBFS on Cosmic" [Undecided,New] https://launchpad.net/bugs/1794137
<juliank> sladen: I think windowing would definitely be worth it, the memory requirements go down a lot, effectively become constant. as https://github.com/julian-klode/ddelta/commit/05aecc28c2f049cad83d9c7ef2e2439d0ecae295 mentions
<juliank> but I think fixed windows of 8 MB should not work in practice
<juliank> you need some heuristics
<juliank> sladen: If you want to compare with xdelta3 as the algorithm, just use ddelta_generate="xdelta3 -s" instead
<sladen> juliank: where's the customised version of bsdiff()  (specifically the search() function)
<juliank> It's in that repo
<juliank> https://github.com/julian-klode/ddelta/blob/master/ddelta_generate.c
<juliank> it's mostly just Google's bsdiff fork plus some cleanup
<juliank> and without large file support
<juliank> (we don't really need large file support since we are delating individual files, and it reduces memory usage by about 50%)
<juliank> and well, memory usage with LFS is 9m + n
<juliank> so assuming you actually need large files >= 4 GB
<juliank> you end up with at least 36 GB of memory requirements
<juliank> unless you use the windowed branch then you only need 50 MB (or well, 6w for window size w)
<sladen> well, some (variable) window should probably be used, and that should be stated in the debdelta
<sladen> so that eg. an old ARM/whatever maschine with 16MB of RAM can use to choose to only look at deltadebs that declare as only using a 1MB window
<sladen> and if not, download everything
<juliank> memory use when applying is already constant
<juliank> the memory requirement here is when generating
<juliank> not counting stdio, memory use is 64 KB of stack memory for the data blocks
<juliank> + a few bytes here and there, and three levels of recursion or so
<juliank> there are no heap allocations in the program (except for whatever libc does)
<juliank> I suggest reading the ddelta_apply.c (https://github.com/julian-klode/ddelta/blob/master/ddelta_apply.c), it's quite easy to follow
<juliank> there's some wicked vectorization magic in apply_diff(), but apart from that, it's quite easy
<juliank> the be64toh is a bit ugly too
<sladen> juliank: this stuff is drastically simplier than what was being looked at ~10 years ago, which failed because of a desire to bit-for-bit recreate the target .deb; and the checksums to prove that were only available on the recompressed .deb, rather than purely the contents
<sladen> juliank: there did not seem to be an appetite for writing directly to the filesystem, partly because of the inability to roll back to the previous state on failure
<sladen> juliank: is there an appetite for directly writing, verses, re-creating the .deb and getting dpkg -i to apply that?
<juliank> sladen: the rollback ability is exactly the same as for out of space errors and roughly the same as for failing preinsts
<juliank> After all, we apply the delta not to the file itself, but write the .dpkg-new file as before
<juliank> so if some delta fails, dpkg will revert precisely as it does with other unpack failures
<juliank> Or rather try to revert
<juliank> that is, it deletes the .dpkg-new files and calls some maintainer scripts which hopefully work
<juliank> With some modifications to dpkg and apt, it should be possible to make apt download the full deb if installing the delta fails
<juliank> For that, dpkg needs to communicate a failing unpack due to delta
<juliank> via status fd
<juliank> apt needs to interpret that and acquire the full thing
<juliank> sladen: Also, the algorithm does support regenerating the .deb file bit-by-bit
<juliank> well, except for compressor changes, if any
<juliank> But the problem with regenerating the full deb is that you end up with a lot of space usage
<juliank> there is the intermediate step where you regenerate the tar while you're piping it to dpkg
<persia> juliank: most compression tools can be used reproducibly with some set of flags.
<juliank> persia: not really
<juliank> Well, for a given point in time, they can
<juliank> But let's compress our deb now, and then try to regenerate it 5 years later
<persia> juliank: I meant gz, xz, bz, etc., for which time is less important.  For tar, etc. things like "--mtime @$$SOURCE_DATE_EPOCH" work.  5 years is trickier.  Anyway, not important.
<juliank> persia: I think pristine-gz ships like 2 copies of different gzip versions now to enable that use case :)
<persia> :(
<sladen> theoretically one needs to know every choice made by the encoder, and the problem is $impossible.  In practice, it can be achieved in 99% of cases, but 90% of those of gzip -9, and there is code around that eg. has snapshots of the different versions of bzip2
<juliank> yeah, like pristine-gz
<juliank> :)
<juliank> Now you can do bitwise regeneration of most debs
<juliank> but as they use xz it's quite slow
<juliank> ...
<juliank> If you don't care about bitwise, then you can go nuts
<juliank> e.g. regenerate full debs without compression
<juliank> or with zstd -1 if we do zstdf
<juliank> which would not really be noticeable
<sladen> what should be better (and is the same case as 10 years ago), would be to store the hash of the uncompressed tar.deb  then the compression algorithm becomes irrelevant (and can be changed as required)
<juliank> you can do that, yeah
<sladen> juliank: somewhere, there is the 'apt-sync' / 'apt-zsync' package code, with provides an APT-Method using zsync.  It should be possible to copy and adapt that and have a more rounded and working demonstration system
<juliank> also, tardelta (or deltatar; aka a tarball of my deltas) is very easy to regenerate.
<juliank> sladen: Such stuff does not work
<persia> Probably want to store multiple hashes (maybe the same set as in dsc files) to make it harder to game.
<sladen> juliank: why not?
<juliank> sladen: You cannot use rsync/zsync algorithms for binaries
<juliank> also, debs are not built rsyncable
<juliank> Now the first argument is a bit complicated, but should be easy to understand
<juliank> If you add a few bytes at the beginning of your file, all offsets change by that amount
<juliank> the entire file becomes unsyncable
<sladen> juliank: in this case, it is the apt-sync *APT method* that might be usable to get a more complete demonstration of this proposed *debdelta* system working
<juliank> I have a working dpkg that can install deltas directly, and I played around with that
<sladen> juliank: thus making the whole proposed *debdelta* system more denonstratable
<juliank> but yes, you can also builod a method that reconstructs debs
<juliank> but we also need a repository layout anyway
<juliank> a PoC would not have any signature checks I think
<juliank> although
<juliank> the method could do that itself
<sladen> juliank: [regarding zsync]  the gzip --rsyncable is about repeatedly restarting the gzip stream, limiting the window size, in order to better re-use existing literal data.  In the proposed *debdelta*, that literal data is provided in the "extra data" block anyway.  This already presumes that server-side disk space is no longer an issue
<sladen> if server-side disk-space is indeed no longer a issue, then this makes the zsync side of stuff a lot easier (it becomes zsync minus the z); in addition to the compressed .deb, store an uncompressed .deb  on the server, and allow HTTP/1.1 Range: Partial-Content access to this for missing pieces not available in the "extra data" (which could now be zero-length)
<juliank> sladen: rsyncable was about rsync/zsync
<juliank> obviously
<juliank> 2nd, the name is not debdelta
<juliank> 3rd, server-side disk space is an issue
<sladen> deltadeb?
<juliank> sladen: yeah, for now, but it's super confusing
 * sladen happy to use any name preferred
<juliank> would have called them ddebs, but we already have those :(
<juliank> pdeb was in the round as well (patch deb)
<juliank> debdiff and debpatch are both used as well
<juliank> naming software is *hard*
<ogra> call it "frank"
<juliank> I could call it voyager
<juliank> after all, related to delta
<juliank> well, the delta quadrant
<ogra> :D
<sladen> juliank: --rsysncable does two (unrelated) things.  (1) resets the encoding/compression state on a particular input (zeros in the input stream);  (2) more reset points in the stream where it can be entered without knowing state [back-reference window state + current Huffman tree in use].
<juliank> I don't care
<sladen> one *can* jump into the stream at any point if the current Huffman table is known, and the contents of the backreference window is available
<juliank> How's that relevant to the topic of deltas?
<sladen> chosing whether, and how much literal data to duplicate, vs. trying to fetch the literal data from the original .deb
<sladen> (server side disk space vs. bandwidth tradeoffs)
<joelkraehemann> hi all
<xnox> @help
<udevbot_> (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
<xnox> @help pilot
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<xnox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: cyphermox, xnox
<xnox> cyphermox, i think that keeping the patch-pilot name should be fine to be honest =)
<xnox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: cyphermox
<cyphermox> xnox: *shrugs* either way. I was asking, since I figured only dholbach (or very few people) knew where the code was at all
<cyphermox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots:
<xnox> cyphermox, right, but i only had the calendar code, not the irc-bot codes. and i think the feedback was that calendar code is not wanted.
<cyphermox> I don't know
<cyphermox> soem people like being scheduled, that way they know to do it at a specific time
<cyphermox> but I guess that works better for patch piloting that other things, maybe?
<cyphermox> brb
<nacc> ahasenack: congrats!
<mwhudson> ahasenack: congrats!
<joelkraehemann> is this channel anyhow related to snapcraft.io?
<wxl> joelkraehemann: #snappy
<joelkraehemann> wxl: thank you
<stgraber> c
<stgraber> oops
<mwhudson> hmm is there an easy way to update to a new upstream with a git ubuntu clone-ed repo?
<mwhudson> uupdate is almost right, apart from the way it creates a new repo
<mwhudson> gbp import-orig similarly almost but not quite what you want
<nacc> mwhudson: yeah, there's not a great way
<nacc> i think we have a bug for it
<nacc> mwhudson: here's what i've done in the past, it's not ideal
<nacc> mwhudson: clear out all non-debian/ directories and files from the git-ubuntu repo, move all the uupdate'd repo's files over
<nacc> mwhudson: `git add .` (should just be non-debian changes)
<nacc> mwhudson: insert a changelog entry (you can use the topmost from the uupdate'd one as a template for the version)
<nacc> mwhudson: i *think* that mostly works, that's how i would do the php updates by hand
<mwhudson> ah yeah
<mwhudson> i am reading how gbp import-orig is implemented now :)
<nacc> and i imagine is actually similar to what gbp does, with probably more smarts.
<nacc> it's basically 'stash debian, update everything, unstash debian)
<nacc> (in my mind)
<mwhudson> it creates a new tree out of the tarball contents, commits that, then mashes the debian dir from the packaging branch into it
<nacc> yeah, that make sense
<mwhudson> (with vaguely appropriate hashes as commit parents)
<nacc> we could do something similar, tbh, we have git-tree representations of any directory (or can) and can do temporary directory things)
<mwhudson> i have an implementation of gbp's debian directory mashing in shell
<mwhudson> but not the other bit
<mwhudson> https://paste.ubuntu.com/p/qfd6wVksDy/
<nacc> there's LP: #1649940
<ubottu> Launchpad bug 1649940 in usd-importer "can't prepare new upstream releases using gbp" [Medium,Confirmed] https://launchpad.net/bugs/1649940
<nacc> and LP: #1706219
<ubottu> Launchpad bug 1706219 in usd-importer "`git ubuntu upstream-update` wrapper around uupdate/uscan" [Wishlist,Confirmed] https://launchpad.net/bugs/1706219
<nacc> i had some scaffolding in a branch to do the latter
<nacc> i think it's a 'future' item, because we are still stabilizing the importer ABI
<mwhudson> it's slightly frustrating that gbp has all the bits required for this
<mwhudson> but can't actually do it
<nacc> mwhudson: yeah, gbp has some very specific branch requirements, iirc. We were trying to avoid coding too much of that policy yet
<rbasak> You can hack it by messing around with GIT_WORK_TREE
<rbasak> Unpack the tarball somewhere
<nacc> ah good point
<nacc> yeah, that's what my scaffolding started to do
<nacc> basically, did uupdate in a specific place
<nacc> and took that working tree
<rbasak> GIT_WORK_TREE=$there git add -A
<nacc> yep
<nacc> rbasak: could you spit that into one of the two bugs?
<rbasak> Then some messing around with "git reset debian" (I'd have to think about it exactly)
<mwhudson> heh ok i have half a shell script for this now too
<nacc> rbasak: right, that was about where i got
<nacc> yeah, you want to commit changes to non-debian as part of the uupdate
<rbasak> Done
<nacc> but it would be a nice feature :)
#ubuntu-devel 2018-09-25
<mwhudson> rbasak, nacc: i pasted a fairly horrifying but apparently working script to the bug
<nacc> mwhudson: rbasak: tyvm
<nacc> someday i'll find time to get back to it :)
<nacc> rbasak: the nice part about your idea is that `uupdate` already does it for us (the unpack somewhere) ... we can control it a bit, possibly.
<nacc> rbasak: alternatively, the user can provide us the tarball to use in theory
<mwhudson> ararararagh the python upstream tokenize changes broke pylint it seems?
<mwhudson> talking of the importer, it seems to be lagging, https://launchpad.net/ubuntu/+source/astroid/2.0.4-1 hasn't been imported 12 hours after upload
<lathiat> https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1794229
<ubottu> Launchpad bug 1794229 in dh-python (Ubuntu) "python packages should not ship colliding /usr/lib/python3/dist-packages/.pytest_cache" [Critical,New]
<lathiat> i created a bug for thjat
<lathiat> maybe that was premature?
<lathiat> just read the convo above
<lathiat> (affects astroid and alembic)
<alterjsive> is fake raid 1 supported by ubuntu?
<sladen> alterjsive: mirroring, yes:  https://help.ubuntu.com/community/Installation/SoftwareRAID
<alterjsive> sladen: so if it stopped working , I should file a bugreport? I used fake raid 0 without problems for years. it just worked without any extra configuration.
<alterjsive> out of the box
<alterjsive> now boot fails after a kernell update.
<alterjsive> if I switch back to my old kernell version, it boots fine.
<sladen> alterjsive: okay, that is a bug, yes
<sladen> alterjsive: what is the before-kernel (working), and the after-kernel (not working)
<alterjsive> sladen: sorry, i'm not sure, it took me a while to figure out it's not my hardware. I thought it was just a harware faillure. I even bought new ssd's
<alterjsive> sladen: I will file a bugreport tonight, thx
<sladen> alterjsive: it needs hard facts ... version number before and after.  Exact partition arrangement, and how Grub is configured
<sladen> alterjsive: yes, please file a bug in Launchpad with the instructions of exactly what happens
<alterjsive> sladen: ok, will do.
<alterjsive> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "kernel update breaks boot on intel fake raid 1" [Undecided,New]
<alterjsive> anything I need to add?
<alterjsive> bbl going home.
<xnox> alai, you didn't mention
<alai> xnox, wrong nick i guess?
<xnox> alai, yes, alterjsive quit by the time i did autocomplete.....
<xnox> sorry
<alai> np at all
<mdeslaur> infinity, kees, stgraber, slangasek: tech board meeting in 5 min
<xnox> doko, i am confused by python's autopkgtests.
<xnox> e.g. test_tls1_3 (test.test_ssl.ThreadedTests) ... skipped 'test requires TLSv1.3 enabled OpenSSL'
<xnox> is seen in python2.7 test, triggered by openssl, both of which are from proposed, and do have TLSv1.3
<xnox> i wonder, if i'm missing something.
<xnox> i'll retry all of them with all-proposed=1 but it would be nice to go over the "regressions" tomorrow, to figure out what's missing.
#ubuntu-devel 2018-09-26
<cpaelzer> doko: cyphermox: It is always the new guy which struggles but due to that has a chance to make documentation better :-) I wanted to ask what you'd think of the following http://paste.ubuntu.com/p/JXMtDcnYBb/ ?
<cpaelzer> Or to better map asciart with text http://paste.ubuntu.com/p/gX9ZYmntRX/
<alterjsive> sladen: it looks like it breaks after I install vagrant
<alterjsive> I reinstalled my system, did a full update, did a reboot. Then I installed vagrant and now I get a busybox
<alterjsive> after a reboot
<sladen> alterjsive: how was 'vagrant' installed, and from where?
<alterjsive> y boot breaks after I install vagrant(updates initfs?)
<alterjsive> Steps:
<alterjsive> install ubuntu & reboot
<alterjsive> do a full update & reboot
<alterjsive> install vagrant & reboot
<alterjsive> => busybox
<alterjsive> I'm a consultant, can I also pay for support? :)
<sladen> alterjsive: how was 'vagrant' installed, and from where?
<alterjsive> sladen: i just did a sudo apt-get install vagrant -y on a clean updated system.
<sladen> alterjsive: ie. from an Ubuntu package (which exact version), or from a Debian package (which exact version), or from downloading from the internet
<sladen> alterjsive: okay, that this single action (sudo apt-get install vagrant -y ; sudo reboot)  results in getting a busybox loging?
<sladen> login?
<alterjsive> vagrant (2.0.2+dfsg-2ubuntu8) bionic; urgency=medium
<cpaelzer> doko: cyphermox: I'll be unavailable next weeks MIR meeting (PTO)
<cpaelzer> just FYI as I checked next weeks meetings
<alterjsive> 1 sec i'll reboot to check the exact message
<sladen> https://launchpad.net/ubuntu/+source/vagrant/2.0.2+dfsg-2ubuntu8
 * sladen pages Old_Bloke
<alterjsive> Busybox  v 1.27.2 .... (initramfs)
<alterjsive> sladen: any idea how to fix this initramfs issue?
<sladen> alterjsive: what is the *exact* error message(s) on boot up
<alterjsive> sladen: I get a busybox immediatly
<sladen> alterjsive: what does the output say, immediately before "getting a busybox" ?
<cpaelzer> alterjsive: FYI I'm trying to recreate that per steps you listed above to cheeck if it generally applies
<alterjsive> sladen: can I check some logfile?
<sladen> cpaelzer: https://github.com/chef/bento/issues/661  could be a possibility
<sladen> cpaelzer: but don't want to distract alterjsive from trying to debug and get hard facts!
<alterjsive> sladen: should I check the boot log from a bootable usb?
<cpaelzer> steps of about 22 minutes ago work fine for me, vagrant is installed and reboot works as expected
<alterjsive> after a failed boot /var/log/boot.log
<cpaelzer> so yeah, lets try to get reasonable logs from alterjsive case
<alterjsive> ok brb reboot
<alterjsive> any other logs ?
<alterjsive> I'll add /var/log/dmesg too
<sladen> alterjsive: boot log, dmesg, etc.  Something will say *why* this boot up has gone to busybox (and without logs the going to busybox is the only we have indication here of anything non-normal here...)
<alterjsive> sladen: I don't see anything unusual in the boot.log
<alterjsive> https://paste.ubuntu.com/p/vKFz4rc95y/
<alterjsive> dmesg is not a log I found out :)
<alterjsive> I just copied all files in my log dir
<alterjsive> sladen: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318 i've added my logfiles
<ubottu> Launchpad bug 1794318 in linux (Ubuntu) "unable to boot after installing vagrant?" [Undecided,Incomplete]
<alterjsive> all of them
<alterjsive> I'm sure you guys are busy , I should move this conversation to another channel right?
<sladen> alterjsive: well here is good.  keeps all the IRC logs in one place
<alterjsive> did I say that right. an initfs update?
<alterjsive> previous kernel version it works until another initfs update
<alterjsive> my current kernel is working, can I make a backup ? in case I install something which does a update-initramfs ?
<alterjsive> I need to continue my work now(deadline)
<sladen> alterjsive: tihs syslog has four bootups in it.  Which are the good ones, and which are the bad ones
<sladen> this
<sladen> alterjsive: "my current kernel is working"  <-- *which* (exact version) kernel is working?
<sladen> alterjsive: the syslog shows 3x boots with "(Ubuntu 4.15.0-29.31-generic 4.15.18)" and 1x boot with "(Ubuntu 4.15.0-34.37-generic 4.15.18)"
<sladen> alterjsive: $ grep 'Linux version' log/syslog
<alterjsive> grub says my latest kernel is  4.15.0-34-generic and the one i'm using now is 4.15.0-29-generic
<sladen> alterjsive: so 4.15.0-34-generic is the *non*-working
<alterjsive> yes
<sladen> thank you
<alterjsive> I was thinking about reinstalling it
<sladen> and this is nothing to do with vagrant?
<sladen> the *only* change is switching from kernel 4.15.0-29-generic (working) and rebooting with 4.15.0-34-generic (not working)
<alterjsive> sladen: I'm under the impression that a update-initramfs breaks it, just a gut feeling
<sladen> alterjsive: please confirm, that to replicate this, the *only* action needed is selecting one kernel, vs. the other kernel in Grub on bootup
<sladen> s/replicate/reproduce this bug/
<alterjsive> sladen: yes
<sladen> thank you
<sladen> alterjsive: and that in neither case "safe mode" is being selected in Grub
<alterjsive> sladen: yes
<alterjsive> 1 sec I'll be more specific. After installing vagrant it did a update-initramfs which broke booting from kernel 4.15.0-34-generic when I switched back, using the grub menu, to a previous kernel  4.15.0-29-generic I could still boot without problems
<alterjsive> any objections to sudo apt-get install --reinstall linux-image-generic linux-image
<alterjsive> sladen: or do you need anyting more from me for debugging purposes?
<sladen> alterjsive: please upload the working and non-working initramfs
<alterjsive> sladen: how?
<sladen> alterjsive: same way the lof files were uploaded
<sladen> alterjsive: same way the log files were uploaded
<alterjsive> where do they live?
<sladen> alterjsive: ls -l /dev/*init*{4.15.0-29,4.15.0-34}
<sladen> alterjsive: ls -l /boot/*init*{4.15.0-29,4.15.0-34}   sorry
<alterjsive> sladen: it's +-100MB, can I post it on launchpad?
<alterjsive> together
<sladen> alterjsive: or at least post the output of ls -l for the moment
<alterjsive> sladen: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/+attachment/5193066/+files/initramfs.tar.gz
<ubottu> Launchpad bug 1794318 in linux (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> ls -l /boot/*init*
<alterjsive> -rw-r--r-- 1 root root 54060073 sep 26 08:20 /boot/initrd.img-4.15.0-29-generic
<alterjsive> -rw-r--r-- 1 root root 59276945 sep 26 08:36 /boot/initrd.img-4.15.0-34-generic
<alterjsive> sladen: my best guess is that when I install virtualbox, I will break my current kernel aswell
<alterjsive> because it updates initramfs
<alterjsive> sladen: can I try to reinstall the latest kernel now?
<sladen> alterjsive: just before "Log ended: 2018-09-26  08:36:21" there is "Processing triggers for initramfs-tools (0.130ubuntu3.3)" "update-initramfs: Generating /boot/initrd.img-4.15.0-34-generic"
<sladen> alterjsive: yes
<alterjsive> sladen: I see, I don't know the implectations of that
<sladen> alterjsive: this is a place were only "initrd.img-4.15.0-34-generic" is updated, and not the older one
<sladen> alterjsive: did 4.15.0-34 work *before* the initramfs was updated?
<alterjsive> sladen: yes
<sladen> righht...
<alterjsive> I only got the busybox after i installed vagrant
<alterjsive> sudo apt-get install --reinstall linux-image-4.15.0-34-generic
<alterjsive> brb reboot
<alterjsive> sladen: no luck, still busybox
<sladen> alterjsive: and if you remove   apt-get remove --purge vagrant  ?
<alterjsive> sladen: won't it try to remove it from the current kernel?
<alterjsive> ok maybe it's cheaper to buy a new laptop with hardware raid
<alterjsive> sorry bit frustrated
<alterjsive> apt-get remove --purge vagrant, brb reboot
<alterjsive> sladen: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/+attachment/5193074/+files/cannot%20activate%20member%20md127.jpg
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> sladen: looks like it's a fake raid issue
<alterjsive> sladen: luckally I can still boot using the previous kernel
<sladen> alterjsive: from the working kernel.  Please upload   cat /proc/mounts
<sladen> alterjsive: thank you for the screenshot of the actual error message
<alterjsive> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/comments/11
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<sladen> ...
<sladen> alterjsive: looking at this tarball from earlier containing logs, the syslog contains these four boots, including one of -34
<alterjsive> sladen: I tried installing kernel 4.15.0-33-generic, but I get a busybox
<sladen> alterjsive: if the mirror/raid away on mounted on root had not booted, then the syslog from the boot would not have saved.  So this boot of -34 appears to have worked
<sladen> s/away/array/
<alterjsive> sladen: when I installed 33, I tried to reboot, but I had to do a hard shutdown using the button because it hung on a stop job for WPA supplicants, i don't know if this is significant
<alterjsive> this used to happen all the time
<alterjsive> lately
<alterjsive> sladen: yes it worked, before I installed vagrant
<sladen> alterjsive: so 08:20 boot with -29, reboot to -34 at 08:30, install vagrant at 08:36, reboot, (reboot to -34 failed, no logs), reboot at 08:38 to -29, reboo at 08:59 to -29
<alterjsive> sladen: looks like it
<sladen> alterjsive: please upload the output of  find /etc/initramfs-tools/ -ls
<alterjsive> sladen: I just installed virtualbox, I didn't see update-initramfs
<alterjsive> sladen: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/comments/12
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> Setting up virtualbox-dkms (5.2.10-dfsg-6ubuntu18.04.1) ...
<alterjsive> Loading new virtualbox-5.2.10 DKMS files...
<alterjsive> Building for 4.15.0-29-generic 4.15.0-34-generic
<alterjsive> Building initial module for 4.15.0-29-generic
<alterjsive> just so you know
<cpaelzer> doko: didrocks: I'd be happy if one of you here in my TZ could do a quick check if bug 1794219 is really ok (I found nothing) before I grant the MIR Team ack
<ubottu> bug 1794219 in ledmon (Ubuntu) "[MIR] ledmon" [Undecided,Confirmed] https://launchpad.net/bugs/1794219
<cpaelzer> would you run this in valgrind to check for "Incautious use of malloc/sprintf" of the checks in https://wiki.ubuntu.com/MIRTeam ?
<cpaelzer> II did, but just want to learn on best practise for these
<alterjsive> sladen: could you change the status back to posted? https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> sladen: it's complete now right?
<sladen> alterjsive: did installing virtualbox cure things?
<alterjsive> sladen: I don't dare to reboot
<alterjsive> I will reboot the end of the day after my work
<LocutusOfBorg> what is the virtualbox problem?
<LocutusOfBorg> if none, nevermind
<alterjsive> LocutusOfBorg: nothing yet, thx
<alterjsive> sladen: if I want mirroring on linux and to use my self encrypting drive encryption. Should I buy a laptop with hardware raid? is this even possible?
<alterjsive> sorry a bit off topic I know
<alterjsive> ok I'll reboot, here goes nothing
<mwhudson> cpaelzer, rbasak: hey can i ping you guys to get a new package imported?
<mwhudson> cpaelzer, rbasak: in particular, rustc (it's a little large)
<alterjsive> sladen: no lock, luckally I can still boot
<alterjsive> on 27
<alterjsive> 29*
<alterjsive> sladen: are you planning to pick this bug up soon, just for my own indication?
<cpaelzer> mwhudson: I can give it a try
<cpaelzer> mwhudson: do you need a one shot, or a regular re-import?
<cpaelzer> mwhudson: I'll do a --no-push --active-series-only first to check if it is affected by any odd issues before going for all of the history
<sladen> alterjsive: can you run  mdadm --assemble --scan  at some point
<mwhudson> cpaelzer: regular would be awesomest
<mwhudson> (can you not just import all of ubuntu already!! ;-p)
<alterjsive> sladen: ok, will try it tonight, thx
<sladen> xnox: this upload of mdadm (4.1~rc1-3~ubuntu18.04.1) ... https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1779685
<ubottu> Launchpad bug 1779685 in mdadm (Ubuntu Bionic) "[18.04.1] Backport support for Intel VROC arrays in mdadm" [High,Fix released]
<doko> cpaelzer: looks good
<sladen> xnox: (might) be the cause of  https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318  slangasek in particular referred to some udev rules from upstream being pulled into the Ubuntu package
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<sladen> xnox: "IMSM RAID geometry validation failed." and "platform does not support raid1 with 2 disks" + initramfs emergency shell is the result using an initramfs with this copy of mdadm
<cpaelzer> doko: the bug update or the pastebin with the changes?
<sladen> alterjsive: mdadm --detail-platform  also please later
<alterjsive> sladen: ok, will do
<rbasak> mwhudson: I'll try an import and see how it goes
<cpaelzer> rbasak: will you run the real import then, that would be nice
<cpaelzer> rbasak: if my faster already started version stumble ssomewhere I'll let you know
<rbasak> cpaelzer: I'm running it (in the screen) for real. If it succeeds it'll push.
<rbasak> cpaelzer: though it's important to then add it to the whitelist so that it keeps up afterwards
<xnox> sladen, i am sad =/
<xnox> sladen, disabling mdadm raid in the bios screens (typically Ctrl+I) and booting the drives directly might be an option.
<sladen> xnox: currently the user is using their previous initramfs (with previous copy of mdadm included)
<xnox> sladen, however, the install is done on top of intel raid.... as per partman
<xnox> sladen, detail-platform would be useful, as well as the state/healthiness of the array from bios. quite likely there are unclean shutdowns and thus array is out of sync.
<sladen> xnox: can you give a list of useful debugging commands for the user to run?
<xnox> sladen, this user is interesting....
 * xnox is reading logs
<xnox> sladen, specifically they forced mdadm installation from kubuntu desktop
<sladen> xnox: tarball::log/apt/history.log  Start-Date: 2018-09-26  08:35:14  Commandline: apt-get install -y vagrant  ... mdadm:amd64 (4.1~rc1-3~ubuntu18.04.1, automatic).   What are you seeing?
<xnox> sladen, i'm reading installer logs, as to how the system installation was done.
<cpaelzer> rbasak: it ran a while without issues and is done (with the reduced set)
<cpaelzer> rbasak: so your run should hoefully work as well
<alterjsive> did you guys say anything about sed's and raid btw?
<alterjsive> I know i'm a bit ambitious in my IT demands :)))
<cpaelzer> rbasak: thanks for all the MP reviews!
<rbasak> More to come :)
<jbicha> cpaelzer: one comment on your paste: Ubuntu bugs easily get into Confirmed status so I consider New and Confirmed to be equivalent
<tych0> smoser: another aws noob question for you if you have a moment, I'm getting, "ClientError: Unsupported configuration: Multiple etc directories found"
<tych0> my root filesystem is an lvm thin pool, with several thin pools underneath it (all of them have /etc)
<tych0> there are some other lvm volume too (none of them have /etc), but in any case, the one that's specified as / in grub does have a reasonable /etc and is a thin pool. do you know if this is supported? or is something else going on?
<cpaelzer> jbicha: yeah, since confirmed has no meaning yet we can define them as "the same" for this
<cpaelzer> jbicha: updated in the draft thanks
<cpaelzer> updated draft http://paste.ubuntu.com/p/HZXPnGk5sr/
<smoser> tych0: is this pvm ?
<smoser> hvm should use grub2 and grub2 i would think might have issues, but such issues would not be specific to ec2
<smoser> pvm uses grub-legacy-ec2 which writes /boot/grub/menu.lst for a pv-grub loader to load.
<smoser> that is hacky and generally deprecated, and i don tknow of the support for lvm volumes there.
<tych0> smoser: i don't know the difference :)
<tych0> smoser: i just used image-import by following the default docs
<smoser> tych0: its probably hvm then.
<smoser> but if that is the case hten you should most likelyi be able to reproduce outside ec2
<tych0> smoser: sadly, the image boots fine other places
<didrocks> cpaelzer: yeah, +1 for me, double checking by security is needed as you set
<tych0> and it's not that it doesn't boot here, it's that aws won't import it. presumably because it's looking through all th ethin pools and seeing multiple /etc dirs
<smoser> can you do a ec2-describe-images call on it ?
<smoser> i dont know their "import" process. i only have familiarity with the bare bones path
<smoser> where you push bytes and then try to boot them.
<tych0> oh
<tych0> well that sounds interesting :)
<tych0> how do i do that?
<tych0> (smoser)
<tych0> smoser: i don't think i can do describe-images, because it never got successfully imported (the error i pasted above is from the import job)
<smoser> oh.
<smoser> its possible its just a buggy process flagging somethign that would otherwise work
<tych0> yeah, i'm wondering if that's what's happening
<tych0> not a lot of info on the interwebs about this, though
<tych0> admittedly, a nested thinpool for / is a strange situation, i suppose
<hallyn> smoser: btw is it safe to assume that the code for generating and uploading the virtual images to aws is in lp?
<infinity> hallyn: Ish.
<infinity> hallyn: livecd-rootfs is responsible for all the heavy lifting there, but for public clouds, there's also a secret sauce branch that does some extra bits that aren't public.
<infinity> hallyn: Oh, and the "and uploading" part is definitely not public.  Though, I'm not sure there's any strategic reason why it couldn't be, just that it's not, AFAIR.
<hallyn> ok.  a matter of "it would cost time/money to figure out whether there's secret sauce or not" probably
<hallyn> thanks infinity
<Sven_vB> hi! is this the right place for help with debugging ubiquity?
#ubuntu-devel 2018-09-27
<mwhudson> hmm
<mwhudson> sbuild on bionic for me is behaving like debian builders: only considering the first option if there are alternatives
<mwhudson> ubuntu builders aren't like that are they?
<mwhudson> or am i misremembering
<mwhudson> ah yes $resolve_alternatives = 1 in sbuildrc in launchpad-buildd
<jbicha> mwhudson: file a wishlist bug for https://launchpad.net/ubuntu/+source/sbuild-launchpad-chroot ?
<mwhudson> jbicha: i don't think that's used any more
<mwhudson> i guess i could and manybe should file a bug asking for it to be removed from the archive
<jbicha> mwhudson: please don't. I use it
<jbicha> unless you have a reason why I shouldn'tâ¦
<mwhudson> maybe i misunderstand what it is
<mwhudson> i know for ages launchpad used a fork of sbuild
<mwhudson> but i don't think it does any more
<jbicha> it's a tool to help set up sbuild locally to be a bit more like the launchpad builders
<mwhudson> ah ok it's not that
<mapreri> jbicha: btw, I'm following after pylint stuff in debian.  do expect me to follow up in ubuntu as well (I saw you synced at least two related packages - including one that ftbfs because you didn't sync another one)
<mapreri> (and py3.7 stuff in general)
<RAOF> Huh.
<RAOF> Why is Mir still in main?
<RAOF> I thought that packages that were not seeded and did not have any rdepends in main were auto-demoted to universe?
<RAOF> Or, at least, would show up on component-mismatches?
<RAOF> Oh, it's in supported.
<tjaalton> you're not off the hook ;)
<ximion> jbicha: if you have time, can you maybe initiate libundead to be dropped from armhf? As I wrote in my email, this should unblock the LDC migration we are receiving mails about
<ximion> the culprit is an LLVM bug tracked as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908670 which appoarently won't be fixed in time
<ubottu> Debian bug 908670 in llvm-toolchain-6.0 "libundead: ftbfs on armhf" [Serious,Open]
<ximion> (nothing depends on the library on armhf AFAIK, so it's safe to drop - debian has an arch-specific RM request already
<ximion> )
<ximion> :P
<sladen> alterjsive: any updates on  https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318  ?
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> sladen: I 'm curious what would happen if I would install a new kernel right after the installation, without upgrading new packages
<mdeslaur> tkamppeter: I'm debating backporting ghostscript 9.25 to our stable releases all the way back to trusty. Are there any known issues with 9.25, and do you think I'll hit any problems doing so?
<sladen> alterjsive: yeah we are curious too.  But, in the mean-time, please provide the debugging information needed
<alterjsive> sladen: I don't have much time now but if you have a quick question, I can awnser it. I will look at the information request in the launchpad issue tonight
<sladen> alterjsive: a quick question is, how was the IMSM RAID setup.  Was this done purely in the BIOS (before the original-original any Ubuntu install had happened)
<sladen> alterjsive: mdadm --detail-platform    should show the IMSM config
<alterjsive> sladen: yes it's configured in the bios only. My understanding is that fake raid means configured by the bios.
<alterjsive> sladen: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/comments/14
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<sladen> alterjsive: and on this machine it was *only* configured via the BIOS
<alterjsive> sladen: yes
<sladen> alterjsive: thank you (x2).  Please could you also upload the output of  mdadm --assemble --scan
<alterjsive> it's empty
<sladen> alterjsive:  mdadm --examine /dev/sd[a-z]
<alterjsive> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/comments/16
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<xnox> alterjsive, "fake raid means configured by the bios" yes and no. mdadm fully knows how to operate on the intel drives; and can create them, change, monitor them, etc.
<xnox> alterjsive, cause it knows how to talk to the intel raid chipset....
<xnox> bios can configure it too usually
<alterjsive> cool
<xnox> alterjsive, it looks like your motherboard / bios is borked up.
<xnox> alterjsive, and you should reconfigure reshape from raid1 to raid0
<alterjsive> borked up?
<xnox> alterjsive, https://paste.ubuntu.com/p/rsVcy6Vd22/
<xnox> is output for me
<xnox> granted my firmware version appears to be old/out of date (no longer receiving OEM motherboard firmware updates)
<xnox> but I do have RAID Levels : raid0 raid1 raid10 raid5
<xnox> alterjsive, possibly poke things in bios, to see why raid1 is not available.... or like disabled....
<sladen> ahhh, okay, the chipset is saying it can't do raid0
<sladen> but raid1 was clearly setup, and is reported in the actual mdadm --examine  scan.  And was (probably) working just fine
<alterjsive> It's currently configured for mirror raid
<xnox> alterjsive, if you are using the brand new VROC (you don't appear to, because you don't have nvme) note that one has to buy an optional hardware key and intel hard-drives to enable NVMe
<alterjsive> I can select raid 0 too
<sladen> but some new check/validation in the new version of mdadm is then deciding that because raid1 doesn't apepar in the list, the raid1 mapper instance can't be setup
<xnox> alterjsive, sladen - configured yes.... but that's simply the metadata on the drives. i believe it's not actually syncing across the two as one expects from raid1
<xnox> sladen, which is safe.
<xnox> alterjsive, you don't appear to have raid1 capability - or the hard-drives you have plugged in are discredited from able to do raid1
<alterjsive> xnox: i had to select a master and a slave. My hard disks appear to be exactly the same
<xnox> alterjsive, i guess the best you can do, is seek support from your motherboard manufacturer.
<sladen> alterjsive: please can you take a photo from the BIOS of what *it* thinks the capabilities are
<xnox> alterjsive, and they plugged into the intel raid enabled ports? at least on my motherboard only some ports are hooked up.
<sladen> alterjsive: so that we can see if there's a difference between what the BIOS sees of its own capabilities, and what mdadm --detail-platform sees as the capabilities
<alterjsive> sladen: I did a raid checkup using windows intel raid drivers. it said it was functioning normally
<xnox> you have windows installed too on this raid?
<xnox> horum.
<alterjsive> no, on a diffrent disk, but I formatted my hdd to ext4 recently and strangly it messed up my windows boot. It's no longer listed.
<sladen> alterjsive: canother possibility, do certain RAID mode change when the two newer disks were plugged in.  Where they plugged in *after* the initial IMSM setup of the first two disks
<alterjsive> sda, sdb and sdd are ssd's. sdc is hdd. sda & sdb are in mirror raid , sda is a master and sdb is slave
<alterjsive> I installed windows on sdd and when I repartionioned sdc , my windows boot was messed up
<xnox> yeah
<xnox> and installing windows messed up your raid probably
<xnox> you did disconnect sda & sdb from the system, when isntalling windows into sdd?
<alterjsive> xnox: no, I didn't know it was this distructive
<xnox> i've never managed to dual boot windows, unless i keep my intel raid unplugged when touching windows.
<sladen> alterjsive: are you available for more in-depth debugging.  (1) reboot, take picture of BIOS config.  (2) unplug sdc and sdd.  (2) take picture of BIOS config.  (3) boot linux, take screenshot of  mdadm --detail-platform
<xnox> alterjsive, as a fun experiment. power down unplug sdc and sdd
<xnox> alterjsive, boot into bios, resync the raid array in the bios - until it is in sync.
<xnox> alterjsive, then continue normal boot
<xnox> alterjsive, check status with mdadm --detail-platform and --examine
<xnox> alterjsive, if it's still not assembled / detail-platform gives you raid0 only, you need to contact better support - ie. mdadm upstream mailing list & your motherboard support/warranty.
<alterjsive> I have other projects too urg, i've just bougth 4 servers for my openshift cluster :)))
<alterjsive> ok I'll see tonight
 * sladen shrugs
<xnox> possibly need to check if there are any firmware upgrades
<xnox> and possibly replace these.....
<xnox> alterjsive, well, you can launch OnMetal instances in Rackspace cloud -> the v2 ones use Intel Raid by default.
<xnox> alterjsive, and mdadm does work there on variety on machines. and locally for me.... it does smell like your chipset/motherboard is borked.
<xnox> alterjsive, or like forget about this intel raid; and reinstall just using regular linux raid.
<xnox> is the best i can suggest here.
<xnox> alterjsive, http://vger.kernel.org/vger-lists.html#linux-raid is the mailing list
<xnox> for upstream mdadm
<alterjsive> xnox: I tried raid 5 with mdadm, no luck
<alterjsive> I tried for days, gave up in the end
<xnox> alterjsive, mdadm asked chipset, chipset said raid0 only.
<sladen> lets maybe debug the current issue.  Because that has the /potential/ that it might also affect a tonne of other people with real enterprisey systems
<xnox> alterjsive, did you already tell us the specific motherboard / server this is?
<alterjsive> not yet
<xnox> is that confidential?
<alterjsive> MSI GS70 gaming laptop
<alterjsive> https://www.msi.com/Laptop/GS70-2QE-Stealth-Pro/Specification
<xnox> alterjsive, it is odd, that you are offered actual raid on it. typically the intel rapid storage on those is to do effectively bcache to accelerate hdd with an ssd which on windows side, is confusingly call the same thing, and is typically not raid
<xnox> and in bios you should have options to select what type of drivers you want to be used for hard-drives: normal ssd or like raid.
<sladen> well, until we have screenshots of the BIOS, we don't know what it is offered/thinks has been configured
<alterjsive> more specific MSI Gaming Notebook GS70 2QE-046NL 17.3", 4710HQ, 1.5TB, GTX970M
<alterjsive> ok I'll reboot 1 sec
<sladen> alterjsive: dmicode will say more about what the laptop actually is
<xnox> true about dmicode
<alterjsive> dmicode?
<sladen> alterjsive: sudo dmicode > dmidecode.txt  --> upload
<alterjsive> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> brb reboot
<ahasenack> nacc: mwhudson: thanks (delayed, was on pto) :)
<sladen> alterjsive: congrats on owning a "Manufacturer: To Be Filled By O.E.M."  ;-)
<alterjsive> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1794318/comments/19
<ubottu> Launchpad bug 1794318 in mdadm (Ubuntu) "unable to boot after installing vagrant" [Undecided,Incomplete]
<alterjsive> sladen: haha
<alterjsive> sladen: I recently updated my bios too. after these problems.\
<alterjsive> https://www.msi.com/Laptop/support/GS70-2QE-Stealth-Pro-4.html#down-bios
<tkamppeter> mdeslaur, I think not. I did not hear about any regressions in 9.25.
<sladen> so RAID Level: "Recovery (Cont.)", appears to be "Recovery Set" == RAID1
<alterjsive> yeah seems to work fine
<alterjsive> using the kernel that still boots
<sladen> and the newer kernel (newer initramfs + mdadm)
<sladen> ?
<sladen> alterjsive: and what about these two with sdc and sdd unplugged?
<alterjsive> I showed you the mdadm error yesterday when I boot the latest kernel
<alterjsive> screenshot
<alterjsive> I don't have a screwdrive to umplug the ssd's
<alterjsive> I've got a laptop, not a rack server :)
<alterjsive> I can check tonight
<alterjsive> brb
<sladen> alterjsive: yes, the question is whether there is a difference in reporting when non-RAID drives are on the same crontroller.  Hopefully not, but that's what debugging is about
<alterjsive> sladen: ok, I will check tonight
<sladen> xnox: there's another difference isn't there.  the mdadm used in the initramfs on bootup, is a difference mdadm used when alterjsive has run these commands and uploading
<sladen> alterjsive: okay, please can you reboot, select "safe mode" for the *working* kernel.  then Run   mdadm --detail-platform   and take a photo
<sladen> alterjsive: this will show what the older copy of mdadm is successfully seeing on bootup, rather than the mdadm is on the main root filesystem
<alterjsive> sladen: I will do it tonight, I should get back to work sorry :/
<alterjsive> maybe in a few hours
<jbicha> mapreri: ok, I'll let you handle pylint stuff :)
<sladen> alterjsive: can you add  cat /proc/mdstat  to the list too
<alterjsive> using m the safe mode?
<sladen> alterjsive: just, just in the running OS
<alterjsive> cat /proc/mdstat
<alterjsive> Personalities :
<alterjsive> unused devices: <none>
<alterjsive> could I have read somewhere that intelraid switched to another raid manager program since the latest kernel?
<alterjsive> I can't remember
<sladen> there was a switch from dmraid to mdadm, but ages ago
<alterjsive> ah ok
<alterjsive> never u mind then
<alterjsive> I don't understand the /prod/mdstat . When I used linux mdadm to create a raid array it gave a totally diffrent output
<sladen> alterjsive: on *this* machine?
<alterjsive> sladen: yes, I've tried to setup raid 5 after I suddenly couldn't boot my raid 0 system with sda, sdb and sdd.
<mapreri> jbicha: it's nearly through anyway ^^
<mapreri> I've also uploaded a bunch of py3.7-buggy related packages in debian today, guess I'll sync them up tonightâ¦
<alterjsive> https://gist.github.com/samrocketman/9677ca29e0fbaab8f8e55ebc3039172a
<sladen> alterjsive: without de-configuring the BIOS/IMSM mirroing?
<alterjsive> sladen: I disabled raid in the bios first ofc
<sladen> alterjsive: when was this?  A year ago, this week, yesterday?
<alterjsive> sladen: a week ago
<sladen> alterjsive: and how old is this RAID pair we're trying to debug?
<sladen> alterjsive: was it created in the BIOS less than a week ago, or more than a week ago
<alterjsive> few days old
<sladen> alterjsive: after the RAID5 experiment, or before the RAID5 experiment
<alterjsive> after
<cpaelzer> doko: cyphermox: didrocks: I got minimal changes a few +1s and nothing else so I'm going to add the proposed changes to the Wiki page
<cpaelzer> it iw a wiki after all, so we can change it if someone realized it is bad later on
<jdstrand> cpaelzer: nice ascii art :)
<cpaelzer> hehe
<cpaelzer> you can even copy and modify it still :-)
<tjaalton> LocutusOfBorg: does virtualbox run alongside libvirt these days?
<LocutusOfBorg> who knows?
<LocutusOfBorg> :)
<LocutusOfBorg> no idea...
<tjaalton> ok
<LocutusOfBorg> I know I cant run kvm and vbox together
<LocutusOfBorg> because of some race condition on hardware virtualization
<LocutusOfBorg> but this seems to be a cpu problem
<tjaalton> right, ok
<LocutusOfBorg> you mean run them together right?
<tjaalton> yes
<LocutusOfBorg> I think this is an hardware problem, not software, the resource can't be shared
<LocutusOfBorg> but I migth be wrong, vt-x is an obscure word for me
<LocutusOfBorg> the vbox client can stay, but if I run a VM it gives error (kvm gives it)
<tjaalton> i see there's a vbox hypervisor driver for libvirt nowadays, dunno if it'd help here
<LocutusOfBorg> I can run many vbox instances at the same time, not really sure how
<didrocks> cpaelzer: just reviewed your changes, looks good, thanks :)
<cpaelzer> thank you didrocks
<alterjsive> sladen: so you want me to disconnect the hdd's
<alterjsive> sdd and sdc
<xnox> sladen, it is funny, they do claim on the website to support super riad
<xnox> Up to 768GB Super RAID 2 + 1TB HDD 7200rpm
<sarnold> "super raid 2"??
<sarnold> do I even want to know?
<xnox> https://www.msi.com/Laptop/GS70-2QE-Stealth-Pro/Specification
<xnox> sarnold, intel rapid storage raid / imsm stuff -> but appears to be broken with a newer stricter mdadm.
<xnox> grep for alterjsive in the scrollback
#ubuntu-devel 2018-09-28
<Wimpress> cyphermox: I've just email devel-permissions to request vala-panel be added to the MATE package set.
<Wimpress> When you get a sec, can you take a look for me please?
<didrocks> bdmurray: I think the apport regression isn't related to that SRU (or previous one) and is a false positive: https://errors.ubuntu.com/?release=Ubuntu%2018.04&package=apport&version=2.20.9-0ubuntu7.4&period=week
<alterjsive> sladen: Hi sladen, I'm going to continue to debug
<alterjsive> sladen: what exactly did you want me to do after I disconnect them?
<alterjsive> sladen: disconnect sdc and sdd
<alterjsive> sladen: I can't access my raid hdd's anymore lol
<alterjsive> I will turn off my raid now
<sladen> alterjsive: and if you plug the sdc and sdd back in?
<sladen> alterjsive: so, guess that indicates that altering the physical disk arrangement makes the RAID/BIOS/whatever upset
<sladen> alterjsive: (but useless for cold-swapping)
<sladen> bit
<sladen> alterjsive: as noted earlier, more useful.  Is the output of   mdadm --detail-platform  whilst in the recovery initramfs busybox of the working initramfs
<sladen> alterjsive: ie. the output of the older version of mdadm
<sladen> alterjsive: this could also be done by using an older (non-upgraded) boot/live-cd
<sladen> alterjsive: which would not require changing anything
<sladen> alterjsive: or by downgrading mdadm.  Or by mounting the initramfs
<sladen> alterjsive: or if you're at the point of trying to be able to re-install
<sladen> alterjsive: working out the absolute minimal set of actions to reproduce, and recording the before/after output of mdadm etc
#ubuntu-devel 2018-09-29
<alterjsive> sladen: Hi sladen, sorry to disappoint you but I won't be debugging for a while. Got some health problems.
<alterjsive> talk to you guys later
#ubuntu-devel 2019-09-23
<LocutusOfBorg> seb128, do you have any clue wrt why this worked? duplicity on ppc64el?
<LocutusOfBorg> I lost a lot of time, and I can't find out where the bug was...
<LocutusOfBorg> btw I would like to sync the -2 revision...
<seb128> LocutusOfBorg, see my comments on the upstream bug, the Debian maintainers marked the 2 tests that were failing as to skip because flacky
<LocutusOfBorg> ack... so no fix :D
<seb128> no :/
<seb128> LocutusOfBorg, -2 was not picked up by launchpad and couldn't be bothered to do a fakesync, feel free to do it by maybe wait for the current one to migrate to not reset the delay by doing another build?
<LocutusOfBorg> seb128, I was thinking after the migration, of course!
<LocutusOfBorg> I just want to avoid bothering you again tomorrow for this reason
<LocutusOfBorg> so the patch was already there, just uncommented
<LocutusOfBorg> meh
<LocutusOfBorg> seb128, migrated! :D
<LocutusOfBorg> great success!
<seb128> LocutusOfBorg, woot :)
<LocutusOfBorg> btw I added information on the bug report, looks like the volumes issues were already debugged by mterry
<seb128> thx
<seb128> LocutusOfBorg, looks like jbicha snapped you and synced first :)
<jbicha> oh, sorry
<LocutusOfBorg> no problem at all, thanks for doing it
<LocutusOfBorg> juliank, hello, when I do dpkg-buildpackage, I like to copy-paste dpkg-buildpackage log...
<LocutusOfBorg> right now, that debhelper-compat is not a real thing... it would be nice to replace the naming before giving the output?
<LocutusOfBorg> I mean: dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 12)
<juliank> LocutusOfBorg: it's a virtual package provided by debhelper
<LocutusOfBorg> nice!
<LocutusOfBorg> I admit I didn't even try to install it, or probably when I tried it wasn't a virtual package yet
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<GunnarHj> tyhicks, jdstrand: Would be good if you could have a look at comment #37 and #38 in bug #1580463.
<ubottu> bug 1580463 in ibus (Ubuntu) "Snap blocks access to system input methods (ibus, fcitx, ...)" [Medium,In progress] https://launchpad.net/bugs/1580463
<tyhicks> GunnarHj: Hello - I saw your ping in the bug but I'm no longer as focused on AppArmor policy as I used to be. I'm unlikely to be of any help in the near term.
<GunnarHj> tyhicks: Ok. Do you know if Jamie is around?
<tyhicks> GunnarHj: maybe not today but I think he will be around this week and I suspect that he'll be interested in this topic
<GunnarHj> tyhicks: I suspect that too. :) Thanks. It's no urgency.
<tyhicks> GunnarHj: thanks for letting us know about the change :)
<Unit193> tsimonq2: Pinging again on LP 1822672 (and LP 1839129)
<ubottu> Launchpad bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is probably broken" [Medium,Confirmed] https://launchpad.net/bugs/1822672
<ubottu> Launchpad bug 1839129 in popularity-contest (Ubuntu) "fix it or remove it" [Undecided,Incomplete] https://launchpad.net/bugs/1839129
#ubuntu-devel 2019-09-24
<RAOF> Hrmph. What's the turn-around time for LP refreshing my gpg key again?
<cjwatson> Nil in principle, but keyservers are buggy
<cjwatson> So it depends
<cjwatson> curl your key from keyserver.ubuntu.com a few times (to cover both backends) and see if it's updated there ...
<mwhudson> re https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1844628 does lupin do anything useful any more?
<ubottu> Launchpad bug 1844628 in lupin (Ubuntu) "casper loop-mount doesn't work" [Undecided,New]
<amosbird> hello, I'd like to setup a new ppa repo. the instruction I saw is pretty simple: dput ppa:amosbird/ppa <source.changes> (Read about uploading). here are all the files I've packaged https://la.wentropy.com/iqcA . should I just place them into the <source.changes>?
<cjwatson> You should under no circumstances write a .changes file by hand.
<cjwatson> You need to prepare a source package (*not* .debs) that will build the binary packages you want, and upload that.
<cjwatson> The process of doing that will produce a *_source.changes for you
<cjwatson> Usually this is done by something like debuild -S
<amosbird> cjwatson: well, that build script isn't made by me
<cjwatson> Doesn't matter.
<amosbird> I just ran a ./packager and it generates a bunch of debs files and a .changes
<cjwatson> If you want it in a PPA then you need to upload a source package
<amosbird> cjwatson: oh
<cjwatson> Launchpad will reject any attempts to upload .debs directly
<amosbird> hmm, ok
<cjwatson> You might just be able to ignore the ./packager script; I don't know what that does as it's not a conventional way to do things
<cjwatson> Hopefully there are debian/changelog, debian/control, debian/rules, etc. files in the directory you're running that from
<amosbird> lemme see
<amosbird> cjwatson:  https://github.com/ClickHouse/ClickHouse/tree/master/debian
<amosbird> yes there are
<cjwatson> OK, so "debuild -S" will probably more or less work, maybe with some tweaks
<amosbird> cjwatson: do I need to run that command under debian/?
<cjwatson> No
<amosbird> under project root then?
<cjwatson> That's conventional
<amosbird> ok, lemme try that
<cjwatson> IIRC if you run it in debian/ it does the equivalent of cd .. until it finds a context where debian/changelog exists, but it's usual to just run it from the project root
<Skuggen> Most packaging related commands expect to find debian/ in the working directory, i.e. should be run from project root
<Skuggen> I didn't know debuild would go looking for it, since most just throw an error if it's not there :)
<bdmurray> jamespage: Could you have a look at bug 1833229 as you did the last python-pip SRU for Ubuntu 18.04?
<ubottu> bug 1833229 in python-pip (Ubuntu) "`--extra-index-url` not working for PIP" [Undecided,Confirmed] https://launchpad.net/bugs/1833229
<jamespage> bdmurray: yep
<cpaelzer> rbalint: about 1844879 upstreams of systemd/libvirt seem to take a while
<cpaelzer> thre is nothing available right now that I could do other than tracking and pushing the discussions a bit
<cpaelzer> will you add the revert of the change you identified to systemd?
<cpaelzer> after all more cgroups/slices might be unexpectedly reaped than just this libvirt test
<cpaelzer> so in terms of safety a revert seems safer to me
<cpaelzer> rbalint: let me know what you think, but without your feedback the bug feels in some kind of nimbus to me - hence I'm asking
<seb128> cyphermox, hey, do you have a vcs update your forgot to push for your recent ubiquity-slideshow-ubuntu upload? I wanted to merge the ubuntu-slideshow from willcooke but the Vcs is currently outdated, if you have it and forgot to push please do :) (ortherwise I can import the missing revision no worry)
<seb128> willcooke, ^ btw blocking the slideshow upload for a bit on that, hopefully we get a reply on the topic in the afternoon (otherwise I just go ahead and fix the Vcs later)
<cyphermox> seb128: oh, probably, let me check
<willcooke> seb128, thx, I am happy to pull from vcs again and remake my MP
<seb128> cyphermox, ah, hey! thx :)
<willcooke> the hard bit is getting all the images edited, copying them over won't take me long
<seb128> willcooke, I will let you know but hopefully it still merge without conflict
<willcooke> ack, thanks seb128
<willcooke> sorry its so late
<willcooke> theme changes, wallpapers, etc etc
<cyphermox> seb128: don
<seb128> cyphermox, thx!
<rbalint> cpaelzer, thanks, will do a revert, but for now 242 is in -proposed where the regression did not occur yet
<cpaelzer> ok rbalint
<cpaelzer> rbalint: so is 243 not for Eoan then, or is this still up in the air?
<rbalint> cpaelzer, no, 242 is up in the air :-)
<cpaelzer> hehe
<cpaelzer> ok then, I'll track the upstreams on this particular issue but will not put extra urgency on it then
<cpaelzer> let me know if that changes
<LocutusOfBorg> lol seb128 :D
<LocutusOfBorg> http://launchpadlibrarian.net/443929654/gamemode_1.5~git20190722.4ecac89-1build1_1.5~git20190722.4ecac89-1build2.diff.gz
<LocutusOfBorg> I'm happy I'm not alone doing that mistake
<LocutusOfBorg> :D
<seb128> LocutusOfBorg, do you watch every single diff from every single archive upload? ;)
<seb128> LocutusOfBorg, (thx for pointing it out, uploaded again with the correct diff now)
<LocutusOfBorg> seb128, I like to refresh update excuses from time to time, and the changelog was suspicious :)
<seb128> :-)
<rbasak> LocutusOfBorg: https://pastebin.ubuntu.com/p/nXmTDVMws3/
<rbasak> Ah, you take care of it. Thank you!
<bdmurray> ddstreet, rbalint: Is bug 1831296 fixed?
<ubottu> bug 1831296 in systemd (Ubuntu Eoan) "__main__.SeccompTest is failing on Ubuntu CI" [Low,Fix committed] https://launchpad.net/bugs/1831296
<ddstreet> bdmurray it's fixed in debian/master, but looks like it does need pulling into eoan, although rbalint is handling all the eoan work so i'll defer to him
<ddstreet> it was included in the 243 systemd version that originally got into eoan, but was then reverted, back to 242 systemd version we have now
<rbalint> bdmurray, ddstreet re LP: #1831296 the change in d/t/boot-and-services is in 242-6ubuntu1 in eoan-proposed, the upstream fix in v243 is not in the archive
<ubottu> Launchpad bug 1831296 in systemd (Ubuntu Eoan) "__main__.SeccompTest is failing on Ubuntu CI" [Low,Fix committed] https://launchpad.net/bugs/1831296
<bdmurray> rbalint: will it get automatically closed?
<rbalint> bdmurray, no, since the Debian changelog entry did not close the bug
<bdmurray> rbalint: well lets just close it
<ddstreet> bdmurray rbalint i'll close it
<rbalint> bdmurray, ddstreet i also think that it is not an issue anymore since upstream CI is running from the Debian Salsa repo afaik
#ubuntu-devel 2019-09-25
<LocutusOfBorg> rbasak, thanks for the ping!
<LocutusOfBorg> doko, I got the two fixes for nm wrong output and crashes on 32bit... PR25018 and PR25031... any planned binutils update?
<cpaelzer> jamespage: coreycb: thedac: rbasak: does https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/c/cinder/20190924_202508_cfe07@/log.gz ring any bells?
<cpaelzer> the qemu upload that triggered the test should have zero impact on this area of your test
<cpaelzer> and it seems like some cinder/mysql disagreement
<rbasak> cpaelzer: no, but I think we did touch that package during the transition. Is this a missing dependency that has surfaced due to some other change?
<rbasak> https://launchpad.net/ubuntu/+source/python%2Dmysqldb is the source package needed I think.
<rbasak> And python-mysqldb or python3-mysqldb are the binary packages.
<rbasak> Also, this is Disco?
<cpaelzer> rbasak: this is disco
<cpaelzer> rbasak: not mysql 8
<cpaelzer> it is triggered by a qemu SRU which changes nothing that seems related to me (WSL behavior with binfmt)
<cpaelzer> you were mostly on "CC" in the highlight above for mysql, I was more waiting on the openstack people if they know anything
<rbasak> ack
<cpaelzer> rbalint: since systemd 243 is gone from proposed I can't continue all tests
<cpaelzer> rbalint: xnox: do you have an eoan PPA with 243 somewhere?
<rbalint> cpaelzer, yes. please use https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801/+packages
<rbalint> cpaelzer, when i got 242 migrated i'll also set up one with upstream master snapshot
<cpaelzer> thanks rbalint
<rafaeldtinoco> good morning all o/
<santa_> morning
<santa_> rbalint: hey while systemd 243 was available in eoan I still got one of "my" issues (udisks2 fails to install in a container)
<santa_> I have an explanation and a possible patch for that, let me retest and find all my stuff...
<rbalint> santa_, thanks I've opened LP: #1845314 to track that
<ubottu> Launchpad bug 1845314 in systemd (Ubuntu) "udisks2 fails to install in a container with systemd 243" [Undecided,New] https://launchpad.net/bugs/1845314
<rbalint> please attach your patch there
<santa_> rbalint: cool, I will explain the thing there
<coreycb> cpaelzer: is it failing for all architectures? it doesn't ring a bell if it's for disco.
<coreycb> cpaelzer: nm that does ring a bell, No module named 'MySQLdb'
<coreycb> cpaelzer: i'm not quite sure how we didn't hit that until now but in disco sqlalchemy was updated to default to mysqldb so changes were required to override the driver to use pymysql
<coreycb> cpaelzer: so debian/tests/cinder-daemons needs to use mysql+pymysql:// rather than mysql://
<coreycb> jamespage: fyi ^
<coreycb> sahid: fyi ^
<jamespage> yes that's quite astonishing as to why we've not tripped over this already
<coreycb> cpaelzer: do you already have a bug open for this?
<cpaelzer> coreycb: not yet, I wanted to open it once I hear back from you
<cpaelzer> and yes it fails for all arch
<cpaelzer> coreycb: I can open a bug for you if you want ...
<coreycb> cpaelzer: no worries, i'll get it
<coreycb> cpaelzer: will paste here once in progress
<cpaelzer> ok, thanks
<coreycb> cpaelzer: bug 1845321
<ubottu> bug 1845321 in cinder (Ubuntu Eoan) "cinder-daemons autopkgtest must override driver to use pymysql" [High,Triaged] https://launchpad.net/bugs/1845321
<cpaelzer> coreycb: thanks
<cpaelzer> If there is a blocker that prevents this from being solved soon let me know, we can then force-badtest it for now
<coreycb> cpaelzer: i'll get it uploaded today to the disco queue but we are somewhat blocked by current SRUs in proposed
<coreycb> sahid: we'll need to get bug 1837905 verified for disco-proposed
<ubottu> bug 1837905 in horizon (Ubuntu Disco) " [SRU] stein stable releases " [High,Fix committed] https://launchpad.net/bugs/1837905
<coreycb> cpaelzer: once that clears, i will combine the autopkgtest SRU with the SRU for bug 1834845
<ubottu> bug 1834845 in cinder (Ubuntu Disco) "DetachedInstanceError: Parent instance <VolumeAttachment at > is not bound to a Session" [High,In progress] https://launchpad.net/bugs/1834845
<cpaelzer> ok, thanks for the info coreycb
<coreycb> cpaelzer: i'm working on it at https://bileto.ubuntu.com/#/ticket/3813
<cpaelzer> I'll copy that to the bug as I know I'll forget ...
<sahid> coreycb: the problem is we still do not have that patched merged https://review.opendev.org/#/c/683057/
<sahid> so tempest tests are still failling
<coreycb> sahid: ok i think we can make an exception for the 2 failing tests since we know why they are failing and it's unrelated to the SRU
<coreycb> sahid: we can just note that in the bug when putting [Test Case] results in it
<sahid> coreycb: for stein-proposed it's verified, no?
<coreycb> sahid: yes but disco-proposed needs verification
<sahid> but stein is disco, right?
<sahid> i verified for stein (disco) and stein-bionic
<sahid> coreycb: ^
<coreycb> sahid: maybe it just needs tagging then. disco-proposed and stein-proposed (bionic) need testing
<sahid> coreycb: verification-done-bionic (bionic-stein-proposed), verification-done-stein (disco-stein-proposed)
<sahid> i updated the bug
<coreycb> sahid: cool thanks
<tdaitx> Laney: juliank: does autopkgtest infra support the newer restrictions (as in "flaky")? (see https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst)
<juliank> hmm
<juliank> I'll leave that to Laney
<tdaitx> I remember skippable required an infra update
<ahasenack> I'm using skippable in ubuntu packages for eoan
 * ahasenack just jumped into the channel and saw skippable being mentioned, nothing else
<tdaitx> so am I, I am wondering about the newer ones
<tdaitx> =)
<Laney> yes
<Laney> for some value of support
<Laney> we need a newer britney to have 'neutral' results properly represented
<tdaitx> yeah, there's that
<cpaelzer> klebers: I see you retrying http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf recently
<cpaelzer> klebers: have you looked deeper into it or filed a bug already?
<cpaelzer> otherwise I'd give it a shot myself
<klebers> cpaelzer, I have not looked deeper into it. That test is being run on a container, it's not running on the raspi2 kernel, so I did not put effort into investigating it
<klebers> cpaelzer, so feel free to give a shot
<cpaelzer> ok
<cpaelzer> ahasenack: have you found the bug status that we can use along update-excuse tag that still makes clear that it is no bug in that package ?
<ahasenack> cpaelzer: no, I haven't experimented with it. What I know is that "new" works. I filed a bug about it, though
<cpaelzer> ok, keeping new then for now ...
<cpaelzer> let me know if your bug shows any progress
<ahasenack> ...which I'm trying to find now (the bug)
<ahasenack> hm, lp times out when trying to list bugs I reported
<cpaelzer> times out for my bug attachment as well
<ahasenack> ok, found it
<ahasenack> cpaelzer: https://bugs.launchpad.net/ubuntu-archive-scripts/+bug/1844774
<ubottu> Launchpad bug 1844774 in ubuntu-archive-scripts "Show bug blocking migration due to dependent test failures" [Undecided,New]
<cpaelzer> thanks
<bdmurray> tsimonq2: Do you have any plans to fix bug 1822672?
<ubottu> bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is broken due to a bad merge with debian" [Medium,Confirmed] https://launchpad.net/bugs/1822672
<bdmurray> xnox: Is the d-i task in bug 1838525 valid?
<ubottu> bug 1838525 in debian-installer (Ubuntu) "LVM setup fails to install grub on virtio storage" [Undecided,Confirmed] https://launchpad.net/bugs/1838525
<infinity> bdmurray: No.
<infinity> bdmurray: grub-installer isn't in any d-i initrds.
<bdmurray> infinity: thanks, closing
#ubuntu-devel 2019-09-26
<amosbird> hello, why do I get Error, was given host, but we don't know about it. when doing dput ppa:amosbird/ppa <source.changes>
<amosbird> what's pdebuild?
<sarnold>  pdebuild is a wrapper for Debian Developers, to allow running
<sarnold>  pbuilder just like "debuild", as a normal user.
<sarnold> from apt-cache show pbuilder
<Unit193> So, you'd run `pdebuild` in the packaging dir rather than dpkg-buildpackage -sa -S -d -tc && sudo pbuilder build ../*.dsc
<amosbird> ok, what's debuild?
<amosbird> is it better than pdebuild?
<sarnold> debuild does a build just "on your machine", with whatever packages you've got installed
<sarnold> pdebuild uses pbuilder to give some reproducable build, similar to sbuild
<amosbird> ok.
<amosbird> So I have a bunch of local deb files. I'd like to quickly spin up a local repo serving those files for machines in the same LAN. what's the easiest way to achieve this?
<sarnold> apt-utils apt-ftparchive works okay
<sarnold> aptly if you want Something Better (I've not used this one myself, but it sure looks neat)
<Unit193> mini-dinstall if you want something super cheap and easy. :>
<infinity> dpkg-scanpackages is the easiest if you literally just have a directory with some debs.
<infinity> Other stuff is massive overkill.
<amosbird> infinity: hmm, dpkg-scanpackages can setup a repo for all machines in the same LAN?
<infinity> amosbird: I mean, it can generate a Packages file. :P
<amosbird> not sure what that means
<amosbird> https://www.aptly.info/ does look nice
<infinity> amosbird: The "repo for all machine in the LAN" is left to you to decide how to serve.  http (apache, etc), smb, nfs, whatever.
<infinity> aptly is ridiculous overkill (and broken in many fun ways) if you really have "a bunch of local debs" rather than something much larger.
<infinity> Of course, another cheap and easy way to go is build everything in a PPA, mirror the PPA locally, and serve that via apache.
<amosbird> infinity: hmm, that means I need to serve apache
<amosbird> is there a tool that can just do  ./serve <local_deb_dir> ?
<amosbird> and I'm good to go
<infinity> No.
<infinity> Creating repositories and serving them are two distinct concepts.
<infinity> Because it's just a flat directory structure, there's no point writing a tool so serve it, when any httpd will do.
<amosbird> but it shouldn't forbid a easy use case
<infinity> s/so serve/to serve/
<amosbird> I don't understand
<infinity> A repository of debs, at the simplest, is a single directory with debs and a Packages file.  More complex, a tree with pool, dists, etc.  Either way, it's just a directory structure.
<infinity> Creating that locally and serving it are two different things.
<infinity> Serving it via any simple httpd takes seconds to set up, so why would someone write a different one to do the same thing?
<amosbird> infinity: ok. after using httpd to serve that directory, how can clients use that?
<infinity> ...
<amosbird> yeah, centos user here
<infinity> And this handholding has gone way beyond the help that #ubuntu-devel doesn't provide.
<amosbird> ok
<infinity> You don't have to serve it from an Ubuntu system. :P
<infinity> If you have CentOS servers with apache on them, you win.
<amosbird> ...
<infinity> (or, apt-get install apache2, put your debs and Packages files in /var/www or whatever the default dir is, and go to town)
<amosbird> ok
<amosbird> any one liner I can use to add that http server as an apt repo?
<infinity> I'm not sure what you mean.
<infinity> You mean on the client machines?
<infinity> It'll depend on where you serve from relative to the root of the machine.
<amosbird> "You mean on the client machines?"  yes
<amosbird> suppose I put those debs and Packages files in /var/www
<infinity> But adding something like "deb http://my.server.local/ ./" to sources.list on a client, assuming /var/www if where you put your debs, will do the trick.
<infinity> After you dpkg-scanpackages . > Packages in said root.
<amosbird> ah, I see what's going on now
<amosbird> lemme try thta
<amosbird> infinity: btw, my workflow has one additional jump
<amosbird> so my dev box generates deb files, I'll push them into a box serve the repo, then clients pull the packages from that serving box.
<mwhudson> rbalint, cpaelzer__: is the usd-importer stuck again?
<amosbird> my question is, do I need to rerun dpkg-scanpackages after updating the old debs?
<amosbird> or can I just rsync them over
<infinity> dpkg-scanpackages generates the Packages file, so you need to re-scan any time you add new ones.
<infinity> Also, that sources.list line should be "deb [trusted=yes] http://my.server.local/ ./" because it won't be signed (which is fine assuming it's a local network you trust)
<amosbird> "so you need to re-scan any time you add new ones." If I don't add new ones, but replace old ones?
<amosbird> can I use apt-add-repository command instead of deb command?
<amosbird> oh...
<amosbird> E: The repository 'http://10.138.0.2:33992 ./ Release' does not have a Release file.
<infinity> Does apt really require Release files now?  That would be silly.
<infinity> trusted=yes shouldn't need one.
<infinity> Did you use that?
<Unit193> Apt maintainer actually was talking about dropping support for Release(,.gpg) and requiring InRelease, last I knew.
<amosbird> infinity: I do
<amosbird> Ign:4 http://10.138.0.2:33992 ./ InRelease
<amosbird> Err:5 http://10.138.0.2:33992 ./ Release
<amosbird>   404  Not Found [IP: 10.138.0.2 33992]
<amosbird> there is an InRelease request too
<infinity> amosbird: What's your sources.list line?
<amosbird> weird, it's  deb http://10.138.0.2:33992/ ./
<amosbird> but I surely did sudo apt-add-repository 'deb [trusted=yes] http://10.138.0.2:33992/ ./'
<infinity> apt-add-repository isn't really a useful tool for this.
<infinity> You could as easily have said "echo 'deb [trusted=yes] http://10.138.0.2:33992/ ./' > /etc/apt/sources.list.d/my.list" for the same effect.
<infinity> Without wondering what the tool was doing.
<infinity> Oh, and as to your other question, "replacing" files in the repo *is* updating them. :P
<infinity> Unless they're identical, your Packages file would be wrong (it contains sizes and hashes)
<amosbird> ah, I see, so I need to update the Packages file too
<infinity> But it's also generally poor form to replace a package with the same version.
<amosbird> btw, how can I make sure the update process won't break any in-progress apt install?
<amosbird> if any
<infinity> apt locks.  You can't run it twice.
<amosbird> so I first do apt locks, then pull in the updates, then apt unlocks?
<infinity> No, I mean apt locks itself. :P
<infinity> You can't run two at the same time.
<amosbird> but the update process is just scp
<infinity> Oh, you mean updating the repo.
<amosbird> yes
<amosbird> "apt-add-repository isn't really a useful tool for this."   what's  the right tool then?  echo seems ... not appropriate
<infinity> So, if you're pushing new versions (instead of trying to overwrite versions, which is evil and scary and undefined), then you push new debs, dpkg-scanpackages > Packages.new && gzip -c Packages.new > Packages.gz && mv Packages.new Packages, then remove the old versions $later.
<infinity> Why is echo inappropriate?
<infinity> One doesn't need a fancy tool to put a line in a text file.
<amosbird> infinity: ok
<amosbird> so I need to relying the filesystems atomic mv
<infinity> apt-add-repository was designed for the specific use-case of setting up hard-to-remember PPA URLs and fetching the signing keys for them.
<amosbird> ah, ok
<infinity> You know your URL, and you have no key.  So... meh?
<infinity> Basically, the only way to break an in-progress update (if you update Packages atomically) is to remove the old debs while someone's still trying to download them.
<infinity> And, really, that's not world-ending.  The client just needs to apt-get update to get the new Packages file, and carry on with life getting shiny new debs instead.
<amosbird> btw
<amosbird> after a new Packages file uploaded, do clients need to run apt update? Or is apt install <package> just enough?
<infinity> Anyhow, if you have tons of packages you want to do this sort of thing with, something like mini-dinstall will help with building the repos and deleting old versions, etc.
<infinity> It's just serious overkill if your repository is a few source packages and their binaries.
<infinity> apt update fetches the new Packages file, yes.  That's literally its only function.
<amosbird> infinity: so I have to do a apt update first
<infinity> A bit confusing that yum conflated update and upgrade into one command.  That hurt my brain the first time I used it.
<amosbird> .......
<infinity> And I assume the same brain hurtiness happens the other direction.
<amosbird> heh, dpkg-scanpackages doesn't allow selecting debs
<amosbird> but all debs in the directory
<infinity> Right.
<infinity> And apt-ftparchive in its simple mode does the same.
<infinity> You can use apt-ftparchive in the complex and super confusing mode we do for the primary archive, which takes config files and lets you feed in package lists, but again, massive overkill unless you're managing a huge repository.
<amosbird> ok
<infinity> But only you know your limit for simple tooling versus complex infrastructure.
<infinity> I'd recommend mini-dinstall when things get too complex.
<infinity> Or, if none of your packages are secret/proprietary, it really is dirt simple to just let LP PPAs handle it, and then mirror the PPA structure locally so your clients don't all have to hit a remote.
<amosbird> https://github.com/yandex/ClickHouse/blob/master/debian
<amosbird> so the /debian folder looks like this. How can I make debuild exclude clickhouse-common-static-dbg and clickhouse-test?
<amosbird> infinity: hi, how can I apt update this repo only ?   deb [trusted=yes] http://10.138.0.2:33992/ ./
<cpaelzer> mwhudson: yes I was missing imports of tonight
<cpaelzer> I'll check if it has died
<cpaelzer> and you probably meant rbasak instead of rbalint :-)
<cpaelzer> hmm, it wasn't aborted - but maybe stuck
<cpaelzer> Examining publishes in ubuntu since 2019-09-22 05:08:13 is quite old
<cpaelzer> yeah something made it stuck on a futex and a socket it seems
<cpaelzer> mwhudson: thanks for the ping, I restarted the importer ...
<LocutusOfBorg> Unit193, hello, what happened to filezilla upload?
<LocutusOfBorg> filezilla is now rc buggy
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941193
<ubottu> Debian bug 941193 in libfilezilla0 "filezilla: Crash on startup: undefined symbol: _ZTIN2fz6threadE" [Grave,Open]
<LocutusOfBorg> also libfilezilla
<LocutusOfBorg> Adri2000, ^^
<seb128> vorlon, hey, do you plan to send debdiff back to Debian for those pylint changes?
<cpaelzer> mwhudson: FYI the git importer has fully catched up now
<Adri2000> LocutusOfBorg: hello, yes just saw that :(
<Unit193> LocutusOfBorg: Hmm?
<LocutusOfBorg> Unit193, you sponsored it, right?
<LocutusOfBorg> :)
<Unit193> I didn't do a filezilla upload though.
<Adri2000> LocutusOfBorg: I'm asking upstream if they plan to fix the bug in libfilezilla itself... also I can't get filezilla to build with wxwidgets gtk3 (./configure fails, saying gtk3 is missing), so I'm asking upstream about that as well
<Adri2000> I wanted to find a solution for the wxwidgets gtk3 build before uploading filezilla, that's why
<Unit193> What error exactly, if I may?
<Adri2000> checking for gtk+-3.0... no
<Adri2000> configure: error: gtk+-3.0 was not found, even though the used version of wxWidgets depends on it. Are you missing the gtk+3.0 development files?
<Adri2000> I just changed the build-dep from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, as suggested in the bug report
<Adri2000> so either I'm missing something, or the ./configure is buggy
<Unit193> https://launchpadlibrarian.net/441494360/filezilla_3.39.0-2_3.39.0-2aegir1~19.04.diff.gz that's what I did.
<Adri2000> oops, libgtk2.0, that was obvious :s sorry I didn't even see you did it in ubuntu!
<Unit193> Not Ubuntu, a silly PPA. :P
<Adri2000> ah :)
<Adri2000> ok let me fix that and I'll ping you again to upload in debian... :)
<Unit193> LocutusOfBorg: Symbols would really help avoid that bug.
<cpaelzer> rafaeldtinoco: would the cluser-solutions need all to be updated to know about this new features?
<cpaelzer> or do you from your testing think that the admin could to that
<cpaelzer> what I'm wondering is if e.g. some cluster solutions set up those virtual ips/devices themselve dynamically
<cpaelzer> then an admin can't do that, which means all those cluster pkgs would need to know how/where to drop netplan config
<cpaelzer> hence I'm asking about that in regard to your HA testing so far
<cpaelzer> could this work with "just" systemd/netplan changes or will all those packages need updates as well?
<rafaeldtinoco> cpaelzer: my thought is that .. if clusters are putting virtual aliases to interfaces, those should contain the "keep configuration" systemd-networkd flag (discussed in LP: #1815101)
<ubottu> Launchpad bug 1815101 in systemd (Ubuntu Eoan) "[master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)" [Medium,In progress] https://launchpad.net/bugs/1815101
<rafaeldtinoco> cpaelzer: so, usually HA clusters will have private interconnects and public nics, you have to set that flag in those receiving VIPs.
<rafaeldtinoco> for keepalived, haproxy, ipvs, the same thing
<cpaelzer> backporting to 237 and modifying all those packages might be complex, but at least going forward that solution LGTM
<rafaeldtinoco> network:
<rafaeldtinoco>     version: 2
<rafaeldtinoco>     renderer: networkd
<rafaeldtinoco>     ethernets:
<rafaeldtinoco>         eth1:
<rafaeldtinoco>             dhcp4: no
<rafaeldtinoco>             dhcp6: no
<rafaeldtinoco>             addresses: [10.0.1.2/24]
<rafaeldtinoco>             keepaliases: true
<rafaeldtinoco> cpaelzer: netplan could be configured with something like this ^
<rafaeldtinoco> and we would explain what keepaliases mean (or any other word)
<cpaelzer> once you did some doability checks and experiments on it be sure to pull in cyphermox for his opinion on the netplan portion of it
<rafaeldtinoco> +1
<rafaeldtinoco> thx for reviewing this, i'd appreciate constant review in next comments to come
<rafaeldtinoco> =)
<cpaelzer> rafaeldtinoco: the value is more fine grained
<cpaelzer> rafaeldtinoco: so if exposing in netplan expose the full set of values maybe
<rafaeldtinoco> ok
<rafaeldtinoco> makes sense
<cpaelzer> static/dhcp/dhcp-on-stop ...
<cpaelzer> I've read the commits now and I don't have a better idea how to resolve this - which means between the two of us it is the best idea we have so I won#t stop you on it
<cpaelzer> :-)
<cpaelzer> rafaeldtinoco: what about the "older" CriticalConnection attribute?
<cpaelzer> could that be available in earlier systemd?
<cpaelzer> https://github.com/systemd/systemd/commit/c98d78d32abba6aadbe89eece7acf0742f59047c
<rafaeldtinoco> https://github.com/systemd/systemd/issues/12050
<rafaeldtinoco> it does not prevent the issue
<rafaeldtinoco> thus the need to create a new feature
<cpaelzer> ok, thanks for checking that already
<rafaeldtinoco> sure!
<cpaelzer> rafaeldtinoco: -- topic switch -- did you see the  KVM acpi issue was resovled by just not passing acpi to the guest?
<cpaelzer> sometimes trivial solutions are the best
<rafaeldtinoco> cpaelzer: err, i knew that would "solve" the issue
<rafaeldtinoco> but he wanted to shutdown through acpi
<rafaeldtinoco> i thought about checking why acpid was working in previous qemu version
<rafaeldtinoco> likely acpi tables from the new qemu broke older kernels
<rafaeldtinoco> (thats what I had in mind)
<rafaeldtinoco> but I saw your comment on modes
<rafaeldtinoco> I wasn't aware of that
<rafaeldtinoco> hopefully without acpi there is some other way for shutting down
<cpaelzer> TBH he should go on with the non crashing case and resolve the shutdown in one of the "too many ways" to do it
<rafaeldtinoco> guest being rhel does not give big incentive to continue =(
<cpaelzer> anyway lets see what the bgu brings up, it seems ok for now
<rafaeldtinoco> yep
<cpaelzer> we are not a service-portal :-)
<rafaeldtinoco> yep, its tricky to define where to stop
<rafaeldtinoco> im learning =)
<xnox> bdmurray:  infinity: but also that grub-installer upload didn't fix server iso. I don't know if more things are needed in grub-installer, or something else is broke.
<LocutusOfBorg> seb128, can you please also merge gst-plugins-bad1.0?
<seb128> LocutusOfBorg, I would share my corrently open editor if that was easier :p
<seb128> on it atm
<seb128> currently
<seb128> also there are a few from Debian where syncpackage tells me launchpad didn't pick the new version yet
<seb128> which I will also sync
<LocutusOfBorg> yes they have been uploaded half an hour ago, thanks for caring
<LocutusOfBorg> on the gst-plugins-good1.0 merge some changelog entries have been lost... not sure if I made a mistake when updating git
<LocutusOfBorg> http://launchpadlibrarian.net/444275983/gst-plugins-good1.0_1.16.0-3ubuntu2_1.16.1-1ubuntu1.diff.gz
<LocutusOfBorg> looks like the changelog wasn't updated correctly?
<seb128> LocutusOfBorg, what do you mean?
<seb128> what changelog? how not correctly?
<LocutusOfBorg> lots of entries disappeared
<LocutusOfBorg> look at the diff on the queue...
<seb128> debian/changelog?
<LocutusOfBorg> yes
<seb128> that's how I do merges
<seb128> I don't keep the old entries
<seb128> imagine we synced and added back some delta we dropped by error if that helps you :p)
<LocutusOfBorg> actually I was going to do the same on some other package, just I never saw people doing it
<LocutusOfBorg> lots of packages have more delta in changelog than everything else
<seb128> right, well for desktop packages I tend to do it this way
<seb128> the vcs and launchpad have the uploads history anyway
<LocutusOfBorg> ok so the ubuntu/1.16.1-1ubuntu1 tagged differs from the uploaded package because of this pruning, right?
<LocutusOfBorg> oh looks like git is updated
<LocutusOfBorg> thanks, I'll do this on my merges from now on
<seb128> np!
<Laney> how can you do that with git? a debian/changelog merge driver which takes the 'theirs' side?
<tumbleweed> 14
<tumbleweed> with a /
<rafaeldtinoco> cpaelzer: I remember seeing some discussions regarding rolling back the last systemd version in -proposed (242-6ubuntu1).
<rafaeldtinoco> u know anything about it ? wondering which version I should backport the feature to
<cpaelzer> rafaeldtinoco: it already changed from 243 to 242
<cpaelzer> rbalint: will know
<cpaelzer> ^^
<bdmurray> xnox: I'm not seeing any indication that bug 1779767 is fixed in Eoan
<ubottu> bug 1779767 in cron (Ubuntu) "Default cron PATH does not include /snap/bin" [Medium,Confirmed] https://launchpad.net/bugs/1779767
<mwhudson> cpaelzer: thanks
#ubuntu-devel 2019-09-27
<saiarcot895> For the openscenegraph-3.4 package in Bionic for i386, it appears the symbols that are provided by libosg.so.3.4 are different than what the symbols would be if they were recompiled now with current Bionic build environment. In other words, I believe there is a reproduciblity issue
<saiarcot895> I have an application that is trying to use OSG 3.4, and building for i386 fails because the symbols in the library and the symbols expected by the header files are different
<saiarcot895> Symbol differences are here: https://paste.ubuntu.com/p/X93JnhHJmQ/ Most of the changes are due to ptrdiff_t being a long currently instead of int back when this package was compiled
<infinity> saiarcot895: int and long are the same on i386.  Are you sure you didn't recompile for amd64 by accident?
<saiarcot895> infinity: Nope, this is going through i386 chroot in sbuild
<saiarcot895> The size should be the same, but I guess the symbol names that get generated are different for some reason?
<LocutusOfBorg> Adri2000, you should bump libfilezilla soname, or add some break/replaces against filezilla, before uploading filezilla
<LocutusOfBorg> also, fix the two build failures (maybe adding latomic helps)
<LocutusOfBorg> meh, you need break not replaces
<didrocks> cyphermox: hey, mind pushing grub2 2.04-1ubuntu6 to the VCS?
<caribou> Hello, I see that partman-md is a sync from Debian so I would hate to introduce an Ubuntu delta, so is there any other way to get Debian Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838503 SRUed into Bionic so Installs on RAID5 stop being slow as a pig ?
<ubottu> Debian bug 838503 in partman-md "debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation" [Normal,Fixed]
<caribou> I have a workaround in the meantime but it would be nice to fix that one
<Laney> juliank: any chance you want to review https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity/+merge/373302 (small, apt_pkg) please?
<LocutusOfBorg> caribou, let me see if I got it right: the bug is *fixed* in eoan, right?
<LocutusOfBorg> since version 89
<LocutusOfBorg> so fixed in eoan and disco already
<LocutusOfBorg> you want it fixed in bionic?
<juliank> Laney: done
<LocutusOfBorg> caribou, open a bug like this one https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<LocutusOfBorg> and ping back in this case
<LocutusOfBorg> just o be sure, existing isos will probably have the old version of the tool, until the iso is regenerated (18.04.4 is scheduled for 06 feb 2020 or so)
<infinity> Real Sysadmins(tm) don't install from ISOs.
<LocutusOfBorg> :)
<Laney> juliank: thanks!
<infinity> Laney: Is it a bug or a feature that my screen blanking no longer fades out for several seconds before actually blanking/locking (giving me a chance to hammer a key in a panic and make it stop)?
<LocutusOfBorg> in any case, SRUing the fix should be possible the fix seems to be safe enough for bionic
<LocutusOfBorg> infinity just to be sure, real admins probably inside the installation manually fix that bug by calling 	local md_min_sync_speed=$(cat /proc/sys/dev/raid/speed_limit_min)
<LocutusOfBorg> 	echo "$md_min_sync_speed" > /proc/sys/dev/raid/speed_limit_max
<infinity> Probably not. :P
<LocutusOfBorg> :)
<LocutusOfBorg> did the beta testing go successfully?
<LocutusOfBorg> xnox, you patched python-cryptography to run tests only against the current python3 version, back in cosmic days, because python3.7 rc2 was failing to test, and was not the default... I don't see such issues anymore with the new version, so I did sync it again
<LocutusOfBorg> I'll followup with a merge fix in case the test on arm64 is bad, but I think the new 2.6 version is good since the begin, or maybe python fixed the bug when 3.7 went stable
<cpaelzer> rbasak: for the now frequent "please rebuild openssl 1.1.1" bugs and the SRU decision to say yes to those the newest development on bug 1841936 might be interesting to you (and the SRU team)
<ubottu> bug 1841936 in haproxy (Ubuntu Bionic) "Rebuild haproxy with openssl 1.1.1 will change features (bionic)" [Medium,Fix committed] https://launchpad.net/bugs/1841936
<cpaelzer> I'm waiting on seucrity there to chime in, but definetly interesting from an SRU POV
<Laney> infinity: not sure, I haven't heard of it being removed, maybe file a bug
<caribou> @LocutusOfBorg sorry did not see your answer
<udevbot> Error: "LocutusOfBorg" is not a valid command.
<caribou> LocutusOfBorg sorry did not see your answer
<caribou> doing SRU is not the issue. So far partman-md do not have an Ubuntu delta so doing an SRU for it on Bionic will introduce one, I just want to know if there is a specific way to handle this one.If not, I'll fix it and do the SRU
<cjwatson> That's not a problem
<cjwatson> The primary reason to be careful about Ubuntu deltas when there isn't already a delta is that it inhibits autosync, and that's not relevant for stable releases
<LocutusOfBorg> exactly, delta is fine for stable, since autosync can't run there :)
<cjwatson> In this case something like 86ubuntu0.1 is entirely sensible
<LocutusOfBorg> interesting, I was thinking more about 86ubuntu1.18.04.1
<caribou> that's what I thought too, but since I did not see _any_ delta on this one I preferred to ask
<caribou> LocutusOfBorg: and the preseed workaround is what I do btw :)
<cjwatson> 86ubuntu1.18.04.1 makes no sense because there was never an 86ubuntu1
<cjwatson> you could do 86ubuntu0.18.04.1 if you really wanted, but TBH it's a bit over-pedantic because no newer series has version 86
<LocutusOfBorg> nice to know, I usually do it anyway, I never thought about do it only if ubuntu1 never existed, it looks like more "coherent with the rest of the archive" :D
<cjwatson> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging recommends your practice only when pushing the same thing to multiple releases
<rbalint> rafaeldtinoco, 243 had too many regressions, so please plan with 242 being in eoan
<rbalint> rafaeldtinoco, i'm preparing one more upload if it gets FFe, if you seek FFe for your changes then they can go in together
<rbasak> mysql-router (from src:mysql-8.0) ships /usr/bin/mysql-router which needs some shared objects. They don't need to be shared objects because nothing except /usr/bin/mysql-router loads them. I'm not sure I'd call them plugins either. libmysqlrouter.so.1 is one of them. But it's strictly internal. I stuffed them inside /usr/lib/mysql-router/ to try to keep them away from public use. Do you think that's
<rbasak> acceptable, or should packaging go further?
<ahasenack> rbasak: picking your git knowledge,
<ahasenack> rbasak: I have two remotes, two different repositories
<ahasenack> rbasak: I'm working on one, which has a file I want to change
<ahasenack> rbasak: I want to cherry pick that change from the other remote
<ahasenack> but these are different repositories, and that file is in different places in each
<ahasenack> I was hoping for something like a cherry-pick with a -p parameter, like patch's, to just ignore the directory the file is in
<ahasenack> specifically, I want to cherry pick a change that is in the file "scripts/test-postfix.py", but in my local branch that file is in "debian/tests/test-postfix.py"
<rbasak> git checkout <local-branch>; git log -p -1 <source-commit>|patch
<rbasak> Maybe?
<ahasenack> any git tricks for that? Or should I just convert it into a patch
<rbasak> It is a patch :)
<ahasenack> I mean, save it to a file, then apply with patch -p 1
<ahasenack> then commit
<rbasak> Yes, essentially
<ahasenack> k
<rbasak> I suppose that won't preserve the commit metadata if you want that
<rbasak> You could format-patch, hack the path in the patch, and then git am
<rbasak> I assume that the two commits don't have any shared history
<rbasak> Because if they do, git can often do the right thing automatically
<bdmurray> rbasak: I don't think regression-release was appropriate for bug 1845599. Maybe that was an inappropriate stock response?
<ubottu> bug 1845599 in duplicity (Ubuntu) "eoan regression: ImportError: librsync.so.1: cannot open shared object file: No such file or directory" [Undecided,Invalid] https://launchpad.net/bugs/1845599
<rbasak> bdmurray: I thought the claim (not my conclusion) met the definition at https://wiki.ubuntu.com/Bugs/Tags#Regression_specific. Do you disagree?
<bdmurray> rbasak: I read "locally installed version of duplicity".
<bdmurray> which means not our issue as you said.
<rbasak> bdmurray: right, but if I'm wrong, say I made a mistake or the reporter says something like "oh, sorry, I did that to debug the issue, here are full steps to reproduce" then the bug would reopen with the correct tag
<rbasak> So I try to tag according to the claim, and leave it to the bug status field to represent validity
<bdmurray> Oh that's a forward thinking and reasonable idea. Got it!
<rbasak> I'm just defending against my own potential mistakes. I triage heavy on the Invalid and Incomplete statuses, but try to do it with humility and make it clear that with further information or clarification the reporter can always request a second look.
<rbasak> :)
<ahasenack> hi sru team, could someone take a look at base-files in xenial?
<ahasenack> I think https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu4.9 had a regression, and https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu4.10 is there to fix it, but xenial still only has 4ubuntu4.8
<ahasenack> rbasak: if still around ^
<bdmurray> ahasenack: 9.4ubuntu4.9 didn't do what it was supposed to see my comment regarding it failing verification.
<ahasenack> hm, and 4.10 just fixed the syntax error
<ahasenack> bdmurray: ok, thanks, I guess I get to fix it now :)
<bdmurray> ahasenack: you might check with vorlon about what went wrong
<kyrofa> I need an expert to confirm this for me: I have version 1.0 of package A installed. Version 1.1 of package A is released, but it comes with a new dependency. I will NOT update to version 1.1 of package A by running `apt upgrade`. I must run `apt dist-upgrade`. Correct?
<kyrofa> i.e. `apt upgrade` only updates existing software, does not install new or remove existing. `apt dist-upgrade` will update existing software AND install new/remove existing as necessary
<kyrofa> Did I get that right?
<Skuggen> Not 100% sure, but I think no
<Skuggen> upgrade won't _remove_ any packages, I think
<kyrofa> Yeah that's the only clarifier I've found... but I THINK it also applies to NEW dependencies
<kyrofa> Not sure how to confirm
<Skuggen> Actually, it might be different for apt vs apt-get, as well
<kyrofa> Hahaha, nooo
<kyrofa> That's another relationship I have yet to wrap my head around
<kyrofa> I assumed apt just dispatched
<Skuggen> manpage for apt says it will install new deps on upgrade, while the one for apt-get says it won't.
<cjwatson> Right.
<Skuggen> Maybe just make some trivial empty packages to test out?
<cjwatson> No need - what you've got from the man pages is correct
<cjwatson> It was a deliberate change from apt-get to apt because in fact the "install new but don't remove existing" option turns out to be a better conservative choice most of the time for people who want a conservative choice
<Skuggen> Aha, thanks :)
<cjwatson> But not really changeable in apt-get without breaking compatibility
<kyrofa> cjwatson, ah ha! So the behavior is indeed different
<kyrofa> Thank you both, that's what I needed
<vorlon> ahasenack: base-files> It's on my backlog to sort out; your analysis in the bug comment is spot on; are you taking this from me?
<vorlon> ahasenack: (I do not object if you are)
#ubuntu-devel 2019-09-28
<amosbird> Hi, can I run debuild no clean and no build?
<cjwatson> amosbird: What would be left for it to do?
<CarlFK> xnox: can we chat about  bug #1807047
<ubottu> bug 1807047 in debian-installer (Ubuntu) "sync hd-media FLOPPY_SIZE with debian" [Undecided,New] https://launchpad.net/bugs/1807047
<CarlFK> https://git.launchpad.net/ubuntu/+source/debian-installer/tree/build/config/amd64/hd-media.cfg  FLOPPY_SIZE = 801792
<CarlFK> if I want to submit a patch, ... what do I do?
<CarlFK> like is there something like "forking" and Merge Request?
#ubuntu-devel 2019-09-29
<LocutusOfBorg> thanks doko for binutils
