[00:09] <cr3> does upstart still load configs from /etc/event.d? it seems mine isn't getting picked up anymore and I seem to be the only one in that directory now
[00:10] <ion> /etc/init
[00:10] <TheMuso> cr3: I think its moved, but can't remember where.
[00:10] <cr3> when I looked at the bzr log, I found: retain loading from /etc/event.d for the time being
[00:11] <TheMuso> hrm
[00:11] <cr3> ion: I've noticed some .conf files directly in /etc/init but I've also noticed in the bzr log something about /etc/init/conf.d
[00:12] <cr3> but the init(8) manpage does mention: /etc/init/*.conf
[00:17] <johanbr> tkamppeter, actually cups sends a ps file
[00:17] <johanbr> the print server doesn't use cups, but rather old-fashioned lpd
[00:18] <johanbr> I guess that may be why... I'll dig a bit more
[00:24] <cr3> slangasek: I noticed you participated in the boot performance sprint back in june which covered something about dh_installupstart. got a minute to hold my hand a bit?
[00:30] <cr3> can someone suggest a package using upstart so that I can inspire myself from the packaging? I looked at apache2, for example, and it still uses sysv style
[00:33] <ion> 0.6 was released so recently that there probably aren’t such packages yet.
[00:34] <ion> Except for upstart itself, of course.
[00:36] <TheMuso> We've hit 400000 bugs.
[00:36] <ScottK> Bug 400000
[00:36] <ScottK> That's no fun.
[00:37] <slangasek> cr3: in upstart 0.6, the config has been moved to /etc/init
[00:37] <slangasek> cr3: /etc/event.d is, AFAIK, no longer used
[00:37] <cr3> slangasek: right, is there a suggested way to write my debian/rules file to account for this?
[00:38] <slangasek> cr3: at this point, no; dh_installupstart has been submitted to the debhelper package, but not yet integrated
[00:38] <cr3> slangasek: I'd rather not have to maintain a separate branch just for karmic, so it would be really sweet to have the same rules apply differently depending on the target where the package is built
[00:38] <slangasek> ah, that definitely isn't going to be the case
[00:39] <slangasek> not sanely, anyway
[00:39] <cr3> slangasek: I don't mind, I've lost my marbles a long time ago
[00:39] <cr3> slangasek: if I'm on my own, that's alright too, but I tend to converge towards checking what others have done beforehand
[00:40] <slangasek> no one else is doing what you're describing, we're not crazy enough to try to use a single branch for multiple releases
[00:40] <infinity> slangasek: Bah.  Why not?  Once the dh_ goo is there, you can easily if-block your dh_installwhatever based on distro and release.
[00:41] <cr3> slangasek: either I revert back to init.d or I hack rules, I really don't want to introduce the overhead of maintaining several branches :(
[00:41] <infinity> cr3: Build-dep on lsb-release if you don't already, and go to town with a branching rules file.
[00:42] <slangasek> cr3: using init.d is the norm anyway, we're still in the process of /introducing/ best practices for shipping upstart jobs in place of init scripts
[00:43] <cr3> slangasek: meh, I'm willing to be your guinea pig as long as I don't lose my soul in the process
[00:43]  * slangasek isn't looking for guinea pigs
[00:43] <cr3> gerbil then?
[00:44] <infinity> ...
[00:44] <cr3> infinity: I don't do that right now, might you suggest a project from which I could learn to do that?
[00:45] <infinity> cr3: I'd suggest gcc, if you like reading.  There are simpler cases, though, I'm sure.
[00:45] <james_w> dpkg-vendor is supposed to help with this now
[00:45] <infinity> cr3: Odds are half of lamont's packages behave differently based on target distro.
[00:46] <infinity> james_w: That gets you vendor, but not release, no?
[00:46] <james_w> ah, true
[00:46] <slangasek> cr3: no, my attention is on getting the toolchain bits in place; I think you're putting the cart before the horse, and I don't think your use case is interesting anyway. :)
[00:47] <slangasek> having separate branches for each distroseries is the /norm/...
[00:47] <cr3> I could probably do something like: dist_release := $(shell lsb_release -rs)... not sure if [ $dist_release -ge "9.10" ] works as expected though
[00:48] <cr3> slangasek: yeah, but the norm typically doesn't touch a package once a release becomes stable except for sru. I maintain a separate repository where my package changes far more often for stable releases
[00:49] <cr3> slangasek: I suspect that this is such a corner case that it's even less interesting :)
[00:50] <infinity> cr3: -ge is an integer operation, so no, that doesn't work.
[00:50] <infinity> cr3: On the other hand, "dpkg --compare-versions" totally DTRT for comparing release numbers. :)
[00:51] <cr3> infinity: aha, so perhaps if [ `echo "$dist_release > 9.10" | bc -l` ]... I can already feel my soul leaving me
[00:51] <cr3> infinity: oh right, forgot about that
[00:52] <cr3> I actually wrote a sorting algorithm in shell using dpkg --compare-versions as the comparison function, fun!
[00:52] <infinity> Ouch.
[00:52] <infinity> That's kinda heavyweight for a sort.
[00:53] <infinity> If only we had C compilers in the archive.
[00:53] <infinity> (isn't writing a bubble sort everyone's second or third C project after hello world and, possibly an MUA?)
[00:54] <cr3> infinity: exactly and, besides, the context was just to sort patches in a package before applying them, so the number of items to sort is likely to remain rather manageable
[01:03] <lifeless> infinity: random_sort ftw
[01:10] <dtchen> Caesar: unlikely pong
[06:38] <rich3376> hello?
[06:39] <rich3376> im not sure if im in the right place (most likely not) just want to ask someone a question if they would be kind enough to answer
[07:25] <pitti> Good morning
[07:25] <pitti> fta: several crashes per program/user> I'm afraid not, you need to copy the .crash files somewhere else for this
[07:26]  * StevenK waves to pitti 
[07:26] <pitti> fta: chrooted> hm, haven't tried that, but since the kernel itself triggers apport, the .crash should land in the outside area
[07:30] <pitti> slangasek: I already did some changes yesterday which should make that up (drop gimp help and pidgin)
[07:30] <pitti> slangasek: I'm afraid we can't avoid webkit much longer, too much of gnome is using it now
[07:35] <slangasek> pitti: right, I realize we can't avoid webkit.  The changes you made appear to have done the trick as far as getting us down to size for now, thanks
[07:35] <slangasek> pitti: can we get rid of gtkhtml this cycle?
[07:36] <StevenK> slangasek: What about the poor dvd image?
[07:37] <slangasek> StevenK: cjwatson was looking into that
[07:38] <pitti> slangasek: unknown, I hope so
[07:39] <slangasek> looks like evolution is the main culprit holding libgtkhtml3.14-19 in
[07:40] <TheMuso> Please bare in mind that moving more and more to webkit reduces accessibility usage somewhat. I haven't tried the latest webkit a11y code, but still think there is a ways to go yet. I'd need to double check on that hoewver.
[07:40] <TheMuso> however
[07:59] <dholbach> good morning
[08:00] <YokoZar> So, users on the Wine 1.0 package (default in Jaunty) should stay at Wine 1.0 for Karmic.  However if they have Wine beta's installed (via PPA or my repo), I'd like to transition them to the wine1.2 package (which conflicts/replaces/provides wine).  Apt won't do this automatically (instead it'll just leave their jaunty beta package) -- would some logic in update-manager be appropriate, or is there a better way to do this?
[08:01] <YokoZar> Essentially I want If Wine Version <= 1.0.1-0ubuntu6 then install Wine, else install wine1.2
[08:02] <mvo> YokoZar: I can add something like this to u-m
[08:03] <YokoZar> Thanks mvo, I suspected we already had a place for this sort of thing
[08:04]  * mvo adds it to gtg
[08:04] <YokoZar> Actually the logic is just "if Wine version >= 1.1, then install wine1.2, else act normally"
[08:04] <StevenK> YokoZar: If wine > 1.0.1-0ubuntu6 then install wine1.2, since otherwise apt will do the right thing
[08:05] <YokoZar> StevenK: Thanks that's a bit better actually
[08:05] <StevenK> pitti: Help? :-)
[08:06] <StevenK> pitti: gnome-session 2.26.2-1ubuntu2 is in NEW, and doesn't list any new components, and gnome-session 2.26.2-1ubuntu3 has been published and built everywhere
[08:22]  * ogra wonders if there is a way to use swap without having swapon available ...
[08:23] <ogra> i know there existes a patch for linux 2.4 to use swap= as a kernel parameter ...
[08:24] <ogra> *exited
[08:27] <slangasek> quadrispro: the avidemux reject was out of binary new, not source new; you'll need to bump the version number
[08:43] <quadrispro> slangasek: thank you
[08:46] <pitti> StevenK: hm, it should build a new -bin
[08:47] <pitti> StevenK: it looks strange indeed, -bin should be N
[08:47] <tseliot> pitti: is there a man page for Jockey's new textual interface?
[08:48] <wgrant> pitti: -bin was in -1ubuntu1 too.
[08:48] <pitti> tseliot: not really, I'm afraid; it's the same arguments as for any other UI
[08:48] <tseliot> pitti: can you give me an example?
[08:49] <pitti> --help should work
[08:49] <pitti> StevenK: I accepted it now, strange though
[08:49] <tseliot> pitti: ok, thanks
[08:51] <tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
[08:51] <tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
[08:51] <tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
[08:51] <tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
[08:51] <tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
[08:51] <tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
[08:52] <dholbach> tweaker25: whatever you're trying to achieve by posting these links - this is not how it works here - I suggest you ask a proper question in #ubuntu-fr
[08:53] <tweaker25> they aren't helping so I will get helped elsewhere
[08:53] <tweaker25> even I have to do every chat of freenode
[08:54] <dholbach> tweaker25: no, that's not how it works - you can't just post a bunch of links in all the channels and expect people to read it all up, translate it and then help you
[08:54] <dholbach> also this is not a support channel, so please be patient and wait until somebody answers your question
[08:55] <dholbach> tweaker25: you can try https://answers.launchpad.net/ubuntu too
[08:56] <modder25> launchpad ???
[08:56] <dholbach> it has a questions / answer tracker
[08:56] <azeem> (tweaker25 even spammed #debian)
[08:56] <dholbach> and you can ask in French there too
[08:56] <dholbach> modder25, tweaker25: I suggest you calm down a bit and be patient or you'll get kicked from the channels for spamming
[08:58] <modder25> even banned you think I have to worry about that I want my stuff working that's all
[08:58] <slangasek> do you think people are going to go out of their way to help you when you're deliberately being rude and abusing IRC channels?
[08:59] <dholbach> modder25: that's not how it works - please respect this and be patient, as slangasek said: people will be less likely to help you if you spam a bunch of channels - especially #ubuntu-devel and #ubuntu-motur is for coordinating work on Ubuntu developent
[09:00] <modder25> but If I cannot have a response I will just be a linux irc channels lamer with proxies, vpn, vnc and more, I got plenty of tricks in my sleeve ...
[09:00] <dholbach> oh man
[09:00] <dholbach> that's boring
[09:01] <dholbach> you won't get a good answer that way
[09:02] <modder25> even if I don't get an answer, it will take days so I will have fun for days until I got an answer
[09:02] <dholbach> that's the most boring kind of fun I can imagine
[09:03] <modder25> boring be less than wait for nothing
[09:03] <dholbach> please go ahead and file the ticket on https://answers.launchpad.net/ubuntu and be patient
[09:04] <modder25> not of my kind sorry
[09:08] <Hobbsee> oh dea
[09:13] <agateau> hi
[09:13] <agateau> upgrading from jaunty to karmic, initramfs-tools fails because it misses /lib/udev/vol_id. any idea?
[09:18] <slangasek> agateau: sounds like a missing Breaks: on the udev package
[09:18] <agateau> slangasek: I am not sure I understand what you mean :/
[09:19] <slangasek> agateau: well, I'm mistaken in any case, because udev already Breaks: initramfs-tools (<< 0.92bubuntu30)
[09:19] <agateau> slangasek: oh it's a flag for debian/control?
[09:19] <slangasek> agateau: /lib/udev/vol_id has gone away, and this is deliberate; the package relationships are in place declaring this
[09:20] <slangasek> yeah
[09:20] <agateau> slangasek: any idea how I could unblock the upgrade?
[09:20] <slangasek> agateau: what package failed to configure?
[09:21] <agateau> slangasek: initramfs-tools
[09:21] <slangasek> you should be able to continue from where it failed, and have apt clean everything up on its own
[09:21] <slangasek> really?  that doesn't make any sense.
[09:21] <slangasek> the initramfs-tools package in karmic doesn't use /lib/udev/vol_id
[09:21] <slangasek> did apport give you an option to file a bug report?
[09:21] <agateau> slangasek: it starts update-initramfs which starts cpio, which complains
[09:21] <agateau> slangasek: no
[09:22] <slangasek> can you post your /var/log/apt/term.log somewhere?
[09:22] <agateau> sure
[09:24] <agateau> slangasek: http://pastebin.com/f11b35e23
[09:25] <agateau> slangasek: sorry it's all in french
[09:26] <slangasek> agateau: no problem - but this log shows that the packages failing to configure are kdepim-groupware and gtk-doc-tools, I don't see any initramfs problems...
[09:26] <agateau> slangasek: just saw this yes
[09:26] <agateau> slangasek: i can paste you the terminal output if you want
[09:27] <slangasek> I guess we need that, yes
[09:27] <StevenK> pitti: Okay, thanks.
[09:29] <agateau> slangasek: http://pastebin.com/m27525fb6
[09:30] <slangasek> agateau: ok, it's trigger-related, I thought that might be the case; now I just have to see what's calling the trigger
[09:32] <slangasek> agateau: and for that, I guess we need more of the terminal output from earlier :(
[09:33] <agateau> slangasek: I can paste more
[09:33] <agateau> just not sure it will be enough
[09:34] <slangasek> agateau: I suspect that somewhere in the output there will be 'update-initramfs: deferring update (trigger activated)" - I need to see the name of the package being configured right before that
[09:35] <agateau> slangasek: http://pastebin.com/m31bb5245
[09:35] <agateau> seems to be ntfs-3g
[09:35] <slangasek> aha
[09:36] <agateau> slangasek: but this seems to happen later as well
[09:36] <agateau> i do not have the complete output :/
[09:37] <agateau> slangasek: console-setup is also triggering this
[09:37] <slangasek> right
[09:37] <slangasek> both packages have correct dependencies, though...
[09:37] <slangasek> i.e., neither package can have its postinst called unless initramfs-tools is configured, which should only be possible while initramfs-tools are both at the jaunty version or both at the karmic version
[09:39] <slangasek> agateau: as far as getting out of this: does 'sudo dpkg --configure -a' work?
[09:39] <agateau> slangasek: no :/ that's the first thing I tried
[09:39] <agateau> slangasek: my initramfs-tools is 0.92bubuntu38
[09:39] <slangasek> gah, that makes no sense
[09:40] <slangasek> agateau: grep -rl lib/udev/vol_id /usr/share/initramfs-tools /etc/initramfs-tools ?
[09:41] <agateau> slangasek: http://pastebin.com/f205a1d1
[09:42] <slangasek> ah!
[09:42] <slangasek> ok, udev is missing a Breaks: on *casper* :)
[09:43] <agateau> slangasek: should i try to dpkg -r casper ?
[09:43] <slangasek> agateau: that might work, yes; if all else fails, "rm /usr/share/initramfs-tools/hooks/casper" to get around the dpkg breakage
[09:44] <agateau> slangasek: ok
[09:44] <slangasek> agateau: then file a bug on udev, saying that it needs Breaks: casper (<< 1.174) for vol_id :)
[09:44] <agateau> slangasek: ok will do
[09:44] <agateau> slangasek: thanks!
[09:45] <slangasek> sure
[09:46] <agateau> dpkg -r lupin-casper casper did the trick
[10:06] <slangasek> pitti, Riddell: bug #339313 is still outstanding, no new information about its status in karmic?
[10:10] <pitti> slangasek: I just know that it apparently got much worse recently (no wpa2 either any more) :(
[10:10] <slangasek> :-(
[10:28]  * pitti chuckles at some hal-info data
[10:28] <pitti>     <match key="system.hardware.vendor" string="To Be Filled By O.E.M.">
[10:28] <ogra> wow
[10:30] <Ng> I have several old motherboards that identify themselves as that
[10:31] <ogra> regulary bought at a shop ?
[10:35] <YokoZar> ok launchpad just sent me the strangest bug email:  status new->triaged  followed by status triaged->new
[10:36] <pochu> somebody quickly changed his mind?
[10:36] <Ng> ogra: yeah, just dirt cheap motherboards ;)
[10:36] <Riddell> slangasek: it's still as unpredictable as its always been.  we ship the most reliable version from upstream and that's about all we can do
[10:36] <ogra> Ng, and slackish OEMs :)
[10:36] <YokoZar> pochu: maybe...I wouldn't expect launchpad to email me then though...
[10:36] <slangasek> Riddell: there's no option to buy upstream lots of caffeine and get them to make it behave sensibly? :)
[10:37] <Ng> ogra: yep. I'm mildly sure one of them was an Asus
[10:38] <Riddell> slangasek: upstream is currently in the process of re-writing it all again, we can only hope the outcome will be an improvement
[10:38] <slangasek> eew :(
[10:41] <pitti> YokoZar: It also happened to me, I think; I keep getting confused by the new edge layout of bug states and the old "change status/add commetn" dropdown
[10:41] <pitti> and if you change the status iwth the ajax thing, and then add a comment, the previous status change is reverted
[10:42] <YokoZar> pitti: Definitely a launchpad beta bug then
[10:43] <wgrant> pitti, YokoZar: Bugs already exist about the commenting and double-click issues, and there's a long-standing bug about not emailing about quickly-reverted changes.
[10:59] <sebner> pitti: I was told you are the hardware hero who can help me debugging my issue. My external harddrive can't get mounted, on recognising it I get errors. (devicekit related? works with windows and jaunty)
[11:00] <Laney> (pastebin the errors?)
[11:01] <sebner> Laney: don't rush :P
[11:03] <sebner> that's the output I get from dmesg: http://paste.ubuntu.com/219650/
[11:16] <dholbach> haha... the logout dialogue doesn't allow me to reboot or shutdown now!
[11:17] <Laney> I just get kicked to gdm
[11:17] <dholbach> I just can suspend or log out
[11:17] <dholbach> feels like Hotel California
[11:17]  * slangasek laughs
[11:18] <ogra> dholbach, its back in the system menu again
[11:19] <Sarvatt> even there it works like he said for me :D oddly on one machine i can shutdown after the "shutdown" in the menu that logs me out but on another machine i can only hibernate and suspend
[11:20] <ogra> heh
[11:20]  * ogra never shuts down unless update-manager tels him to ...
[11:20] <ogra> bu i have all options in the shutdown dialog
[11:21]  * Laney likes to save on electricity bills
[11:21] <dholbach> ogra: it was in the system menu, but when I clicked it it didn't greyed out the shutdown option
[11:21] <dholbach> I rebooted anyway and it's back now
[11:21] <ogra> weird stuff
[11:21] <ogra> i hope the DX team finally gets fusa ported
[11:21] <ogra> so we have it all back as it was
[11:22] <ogra> what annoys me most with the gdm fusa is that it uses my login picture, so i have to see my head as icon in the panel all the time
[11:23] <ogra> i would work in front of a mirror if i wanted to see my ugly face all the time
[11:26] <highvoltage> ogra: a mirror!? you know that you could just use cheese.
[11:27] <highvoltage> (fwiw I also find it a bit annoying)
[11:36] <pitti> hey sebner
[11:36] <sebner> Pitt:)
[11:36] <pitti> dholbach: fixed with this morning's consolekit upload
[11:36] <pitti> ogra: ^ FYI
[11:37] <pitti> sebner: hm, seems it's detected, and then breaks down halfway; do you see it in "devkit-disks --dump"?
[11:40] <sebner> pitti: nope
[11:41] <pitti> sebner: could you try with 2.6.30 or the jaunty kernel on karmic?
[11:44] <sebner> pitti: I tried with .30 already but still not working. jaunty kernel doesn't seem installable on karmic anymore?!
[11:44] <sebner> pitti: or do you mean looking at the --dump under .30er kernel?
[11:44] <pitti> sebner: not installable> how so?
[11:45] <pitti> sebner: I often see those if the drive is underpowered (with USB-powered drives)
[11:45] <sebner> pitti: Package linux-image-2.6.28-11-generic has no available version, but exists in the database.
[11:45] <pitti> but if it works fine under jaunty, it could be a kernel regresssion
[11:45] <pitti> sebner: right, you need jaunty .deb sources, or just grab it from archive.u.c.
[11:46] <sebner> pitti: jaunty was on a different pc though
[11:46] <pitti> aah
[11:46] <pitti> now, that changes things
[11:46] <sebner> pitti: at least it works on windows (7) on *this* pc
[11:56] <sebner> pitti: rebooting now in .30er kernel
[12:02] <sebner> pitti: not working either
[12:02] <pitti> sebner: does a jaunty live CD work?
[12:03] <pitti> just to see whether it's a sw regression or a hw issue
[12:03] <pitti> "hw specific issue"
[12:04] <sebner> pitti: well, I used this external harddrive at jaunty times, it's working on another jaunty pc and on my windows. I tend to say it's devicekit but let's see
[12:04] <pitti> could be
[12:04] <sebner> pitti: I don't need to mention that I tried different ports  ^ ^
[12:04] <pitti> sebner: you could try running devkit in debug mode
[12:05] <pitti> sudo killall devkit-disks-daemon
[12:05] <sebner> pitti: livecd or debug mode?
[12:05] <pitti> sudo /usr/lib/devicekit-disks/devkit-disks-daemon
[12:05] <pitti> and capture the log, what happens
[12:05] <pitti> sebner: on your karmic system
[12:07] <sebner> pitti: kk, kernel version doesn't matter?
[12:08] <sebner> pitti: and usb already plugged in when starting the daemon?
[12:10] <pitti> sebner: no, please plug it in while the logging is running already
[12:11] <pitti> sebner: if it behaves the same with differnet kernels, it doesn't seem to matter, yes
[12:18] <sebner> pitti: http://paste.ubuntu.com/219685/
[12:52] <Keybuk> ok, I've just fallen in love with "git commit --amend"
[13:05] <pitti> sebner: ok, so the kernel sends a remove event, presumably because of that usb error
[13:11] <sebner> pitti: ok, any hint what we should do next?
[13:12] <pitti> sebner: I'm afraid not; ubuntu-bug linux perhaps?
[13:12] <pitti> I've seen other instances of this in the past
[13:12] <pitti> but I have no idea why that happesn
[13:13] <sebner> pitti: I've done bug search and I've already found an old linux bug report bug everything with error -110 and not -71 as I have
[13:14] <Sarvatt> you getting lots of usb errors lately too sebner?
[13:14] <sebner> Sarvatt: well only with my external harddrive. usb sticks are working
[13:15] <Sarvatt> i started getting these flooding dmesg every now and then a few weeks ago when my webcam stopped working http://pastebin.ubuntu.com/219722/
[13:16] <sebner> Sarvatt: exact the same errors as I get
[13:17] <Sarvatt> looks like they started around july 1st or so
[13:17] <sebner> Sarvatt: seems to be a devicekit/kernel error
[13:17] <amitk> hmm.. my application menu disappeared after a karmic dist-upgrade just now
[13:18] <amitk> so did preferences and administration
[13:18] <amitk> in System
[13:19]  * amitk tries logging out and back in...
[13:19] <geser> my Applications menu was also empty but sendind a HUP signal to gnome-panel fixed it
[13:20] <sebner> pitti: anyways, thx for your help. I'll file a bug
[13:21] <pitti> sebner: sorry, no idea about that :/
[13:21] <Sarvatt> does anything depend on usbfs? i was just guessing it was something about usbfs getting moved to embedded in the kernel so we probably dropped it
[13:21] <Sarvatt> (in 2.6.31)
[13:22] <pitti> Sarvatt: is that /proc/bus/usb? That has been deprecated years ago
[13:27] <amitk> yup, logout and login fixes the menu again.
[13:29] <ScottK> cjwatson: I believe I figured out my netbook image background problem (which based on your replies and where I think the problem is, I don't think I was explaining very well).  There's a debian-cd merge proposal waiting that should take care of it.
[13:39] <cjwatson> ScottK: ok, thanks
[13:40] <cjwatson> ScottK: oh, you meant *that* background :)
[13:40] <cjwatson> merged
[13:40] <ScottK> cjwatson: Yes.  Sorry I didn't explain myself very well.
[13:40] <ScottK> Thanks.
[13:52] <pitti> Riddell, ScottK: what bit of KDE watches /var/crash/ and spawns apport-kde?
[14:00] <gleeb_> hey guys... anyone here who's working with mono?
[14:03] <pitti> gleeb_: directhex is the primary mono maintainer
[14:03] <Riddell> pitti: update-notifier-kde
[14:04] <pitti> Riddell: oh, heh; should have guessed, thanks
[14:06] <mterry> How does one request that a source package be removed (say if its binary packages are now provided by a different source package?)
[14:07] <pitti> mterry: file a bug against that package and subscribe ubuntu-archive
[14:07] <pitti> or bug an archive admin on IRC
[14:07] <seb128> the binary case should not require a bug though
[14:07] <pitti> mterry: what's the package?
[14:07] <mterry> pitti, k.  oem-config is obsolete by ubiquity now
[14:08] <pitti> mterry: right, looks like; I'll remove it
[14:08] <mterry> pitti, oh, OK.  Thanks!
[14:09] <pitti> [done]
[14:09] <mterry> That was fast.  :)
[14:21] <pitti> Riddell: would you mind doing s/apport-qt/apport-kde/ in update-notifier-kde? I can't commit to the branch (~kubuntu-members)
[14:23] <Riddell> didn't I do that?  let me check
[14:24] <Riddell> hmm, seems not
[14:25] <Riddell> pitti: you're looking at lp:~jr/apport/kde-fix I take it?
[14:27] <Riddell> pitti: update-notifier-kde done
[14:27] <pitti> Riddell: no, I just apt-get source'd
[14:27] <pitti> Riddell: thanks
[14:28] <pitti> Riddell: I already merged that a while ago
[14:28] <pitti> it's in karmic
[14:28] <Riddell> good, thanks
[14:48] <cr3> Keybuk: ping, was upstart changing from event.d to init announced somewhere? if so, I need to start paying more attention to such announcements :)
[14:48] <Keybuk> cr3: it's in the Upstart NEWS
[14:49] <Keybuk> that's installed as /usr/share/doc/upstart/NEWS.gz
[14:49] <Keybuk> and I always include that in release announcements to upstart-devel, LP, etc.
[14:50] <Keybuk> normally I tend to summarise it in debian/changelog (for any package I maintain, whether upstream or not)
[14:50] <Keybuk> but since the version of Upstart in Ubuntu was so old, the summary of what changed was "everything"
[15:23] <ttx> and the winner is... bug 400000
[15:24] <mvo__> !
[15:25] <ttx> Apport ftw!
[15:28] <pitti> \o/
[15:28] <pitti> that's the proof, seb128 makes our bug tracker explode
[15:35] <seb128> pitti, lol
[15:36] <cr3> where is synaptic configured to check for packages periodically and then popup a window or notification to the user currently logged in?
[15:42] <mvo__> cr3: the interval for this is configured via system/administration/software sources
[15:43] <cr3> mvo__: if I want another application to behave similarly across all flavours of ubuntu, this might not work then
[15:44] <cr3> mvo__: could you suggest a way for me to automatically start an application when a user logs in (who might also get auto-logged in)
[15:45] <mvo__> cr3: /etc/xdg/autostart
[15:45] <mvo__> cr3: check e.g. the update-notifier desktop file in there - but I'm not sure if it will really work on all flavour
[15:46] <mvo__> cr3: for that, somewhere in the xsession is a better bet
[15:46] <mvo__> cr3: /etc/X11/Xsession.d/ - what is your use-case?
[15:48] <cr3> mvo: my use-case is that I have situations where I want testing to automatically start after a system has been installed. I used to use upstart but I'd like the flexibility of running the application as the user in an X context and also as the user in a console context.
[15:49] <cr3> mvo: whether the application actually does testing or not depends on a preseed value, which is set to not test by default
[15:49] <cr3> mvo: for X, I could probably use /etc/X11/Xsession.d. for console, I probably need to use sysv init or upstart
[15:51] <mvo> cr3: yeah, sounds like it. xsession.d is run early, i.e. before the full desktop is up, but if that is ok, then that should be ok I guess
[15:51] <cr3> mvo: worst case, I can probably sleep for a while before doing anything
[15:51]  * mvo nods
[15:52] <cr3> mvo: thanks man!
[15:52] <mvo> np
[16:29] <Keybuk> not for the first time, I wish that dpkg-source -b had a --not-so-damned-picky argument
[16:32] <Keybuk> actually
[16:32] <Keybuk> you know what would be nice
[16:32] <Keybuk> some kind of opposite to -i
[16:33] <Keybuk> "only include changes that match this regexp"
[16:33] <Keybuk> rather than "ignore changes that match"
[16:33] <Keybuk> or just something like dpkg-buildpackage -S --only-debian
[16:35] <jdstrand> Keybuk: hi-- so I am looking at bug #399954. While I can say that it did work ok on jaunty, the technique is obviously too brittle. So rather than figuring out why it broke on karmic and didn't on jaunty, I'm going to just say "let's change it"
[16:36] <Keybuk> jdstrand: it only worked on jaunty because Upstart failed to clear utmp properly on shutdown
[16:36] <Keybuk> so runlevel would return "2" or some nonsense
[16:36] <jdstrand> Keybuk: ah, well that clarifies a lot :)
[16:36] <Keybuk> wtmp, I mean
[16:36] <jdstrand> ok, no matter
[16:37] <Keybuk> suffice it to say, the jaunty runlevel tool was really buggy, and you were relying on those bugs ;)
[16:37] <Keybuk> the reason the kernel change made it break, of course, was that the kernel enabled apparmor again
[16:38] <jdstrand> Keybuk: sure, and I didn't realize I was relying on bugs, I thought that was expected behavior. so my thinking was always that I wanted to know when I left rcS, since apparmor should have been started by that point. is there a way to determine this?
[16:38] <jdstrand> Keybuk: or is that idea flawed
[16:40] <jdstrand> Keybuk: I could probably change the udev rule, but I don't think I want to do that
[16:40] <Keybuk> I think this is one of those cases where we need to figure out how apparmor is supposed to work
[16:41] <Keybuk> you're basically trying to delay an asynchronous operation until apparmor is started
[16:41] <Keybuk> so here's a question
[16:41] <Keybuk> why can't apparmor be started before udev?
[16:41] <Keybuk> (I expect because apparmor is installed under /usr ?)
[16:41] <Keybuk> which leads to my next question
[16:41] <jdstrand> no, apparmor_parser is /sbin
[16:42] <Keybuk> but libapparmor is in /usr/lib
[16:42] <Keybuk> ok, apparmor_parser doesn't depend on that
[16:42] <jdstrand> libabut apparmor_parser doesn't use libapparmor
[16:42] <Keybuk> here's another question
[16:42] <Keybuk> why can't you parse apparmor policies on the fly?
[16:42] <Keybuk> instead of waiting for a "parse all the policies" to happen
[16:42] <Keybuk> why not just have the dhclient script parse the dhcp-related policy if it hasn't already happened?
[16:43] <Keybuk> that kind of model becomes *really* Upstart-friendly
[16:43] <Keybuk> e.g.
[16:43] <Keybuk>     start on starting cupsys
[16:43] <Keybuk>     exec /sbin/apparmor_parser /etc/apparmor.d/cupsys
[16:43] <Keybuk> if and when cupsys is started, the apparmor policy would be parsed for it *first*
[16:44] <jdstrand> bear with me as I am not upstart script fluent yet, but that works fine for cups, when you have an upstart script, but doesn't the udev rule bypass that? I mean, we don't start cups via udev
[16:46] <jdstrand> Keybuk: and btw, I don't care if apparmor loads all the policies at once or not-- I can just as easily do 'apparmor_parser -a /sbin/dhclient...'
[16:46] <jdstrand> Keybuk: but I can't run that until I have /sys/kernel/security/apparmor/profiles
[16:46] <Keybuk> I was just illustrating
[16:46] <Keybuk> obviously while cups is an init script, you'd just paste the apparmor_parser code into it
[16:47] <Keybuk> what creates /sys/kernel/security/apparmor/profiles ?
[16:47] <jdstrand> let me check...
[16:48] <jdstrand> actually, if sbeattie or jjohansen were around, they could answer much more quickly :) ^
[16:48] <jdstrand> but I'm still looking
[16:49] <cr3> pitti: in apport, why is there etc/default/apport and apport.default in the source tree?
[16:49] <pitti> cr3: there isn't?
[16:50] <pitti> cr3: neither in trunk, ubuntu bzr, nor karmic package
[16:50] <pitti> cr3: I remember that this was the case for a few days, but I fixed that ages ago..
[16:50] <cr3> pitti: err, I was looking at apt-get source apport on jaunty
[16:50] <pitti> cr3: which version are you using?
[16:50] <pitti> ah, perhaps
[16:51] <cr3> pitti: cool, I was just checking if there might be a reason for that. as usual, you're way ahead of me :)
[16:51] <pitti> the apport.default was a mistake
[16:51] <jdstrand> Keybuk: it is available when you mount securityfs
[16:51] <Keybuk> jdstrand: ah yes, the bendoverfs!
[16:51] <Keybuk> what mounts that?
[16:51] <pitti> cr3: yeah, the reason was just my stupidity (or rather trying to represent a file rename in a package diff.gz)
[16:51] <jdstrand> Keybuk: /etc/init.d/apparmor
[16:52] <Keybuk> jdstrand: since it's a kernel filesystem we could mount that in mountkernfs.sh
[16:52] <Keybuk> then you could do on-the-fly apparmor policy setting whenever it was needed
[16:55] <jdstrand> Keybuk: ok, then we move the mount into mountkernfs.sh, then I can just check if /sys/kernel/security/apparmor/profiles and run apparmor_parser ... if it is
[16:56] <jdstrand> Keybuk: that is definitely cleaner. will have to implement mountkernfs.sh carefully though... ie if apparmor is available or if some other LSM (or none) are loaded
[16:56] <Keybuk> why mountkernfs.sh ?
[16:56] <Keybuk> surely that can just mount securityfs, whatever provides it?
[16:56] <Keybuk> it's not apparmor-specific no?
[16:57] <Keybuk> it looks like debugfs from what I can tell
[16:57] <Keybuk> "intended to be mounted under /sys most of the time"
[16:57] <jdstrand> oh, well if that is the case, then no problem
[16:57] <rickspencer3> dholbach: can you join #quickly?
[16:59] <jjohansen> Keybuk: everything in /sys/kernel/security/apparmor/ is created by the AppArmor kernel module, the fs is part of securityfs and shows up as soon as securityfs is mounted
[16:59] <jdstrand> Keybuk: alright, thanks for your feedback. it was invaluable. I'll upload a new dhcp3 which will assume the securityfs change (which will fail to load the profile) so people can boot again
[17:00] <jdstrand> Keybuk: then I'll test out the securityfs changes and upload when I have everything going correctly
[17:02] <jdstrand> Keybuk, jjohansen: actually, looking at mountkernfs.sh it seems as long as I check for securityfs in /proc/filesystems (ie, like we do in sysfs), it should be easy
[17:03] <kirkland> mvo: ping
[17:03] <Keybuk> jdstrand: I think domount does that already no?
[17:04] <kirkland> mvo: two more minor changes to update-manager and update-notifier ...
[17:04] <Keybuk> jdstrand: ah, no, yeah copy the sysfs entry
[17:04] <Keybuk> jdstrand: while you're in there, could you add debugfs as well (/sys/kernel/debug)
[17:04] <kirkland> mvo: need to drop the dependency on update-motd, and add a versioned dependency on pam (>= 1.0.1-9ubuntu3)
[17:04] <kirkland> mvo: i was just about to add that now, unless you would prefer to do so yourself?
[17:04] <jdstrand> Keybuk: sure thing, and thanks again! :)
[17:05] <jjohansen> jdstrand: hmm okay.  To actually find if apparmor is enabled you look in /sys/modules/apparmor/parameters/enabled
[17:05] <jjohansen> it has bug currently, that I have just fixed
[17:06] <jjohansen> if you have hit this already, sorry I am still catching up on the scroll back
[17:06] <jdstrand> jjohansen: no, this was a bug in dhclient
[17:07] <jdstrand> jjohansen: udev brings up dhcp interfaces before apparmor is started
[17:08] <jdstrand> jjohansen: so I had a brittle method that worked around that on jaunty, and we were trying to figure out a robust method for karmic
[17:08] <kirkland> mvo: actually,  libpam-modules (>= 1.0.1-9ubuntu3)
[17:08] <jjohansen> jdstrand: yeah, I saw that but there is still a bug where /sys/modules/apparmor/parameters/enabled is reporting AA is enabled even when it isn't
[17:09] <jdstrand> jjohansen: so, if /sys/modules/apparmor/parameters/enabled has '1', then I should be able to run apparmor_parser -a <profile> safely, correct?
[17:09] <jdstrand> jjohansen: do you recommend I check for that and the existence of /sys/kernel/security/apparmor/profiles? for the time being?
[17:09] <jjohansen> jdstrand: in theory yes
[17:10]  * jdstrand goes to work
[17:10] <jjohansen> jdstrand: the parser will actually check for that and fail if it can't find it
[17:17] <jdstrand> jjohansen: how does one disable apparmor on the karmic kernel command line? I'm going to have to change documentation since initscript behavior is changing
[17:17] <jdstrand> security=?
[17:18] <jjohansen> jdstrand: you can currently do either apparmor=0 or security=XXX where XXX is not AppArmor
[17:18] <jdstrand> (ie, simply removing the initscript won't disable apparmor any more)
[17:18] <jdstrand> jjohansen: ok thanks
[17:18] <jjohansen> however apparmor=1 is not enought to enable apparmor
[17:19]  * jdstrand nods
[17:32] <mvo> kirkland: thanks, I can do that - or you just commit it to bzr and I include it in the next upload, both is fine with me
[17:32] <kirkland> mvo: i just did update-manager
[17:32] <kirkland> mvo: doing update-notifier now
[17:33] <kirkland> mvo: i'm prepping the upload, but the debdiff isn't clean; config.* modified; trying to figure that out now
[17:39] <slangasek> ScottK, rgreening: what's the status of kubuntu netbook test cases?  I don't find anything under http://testcases.qa.ubuntu.com/, so I'm not sure what to set up on the ISO tracker
[17:40] <brianchidester> slangasek: what do you mean by kubuntu netbook test cases?
[17:40] <brianchidester> slangasek: is that for a specific build?
[17:40] <slangasek> brianchidester: the kubuntu team is doing a netbook build for karmic
[17:40] <brianchidester> slangasek: will that be a unr based build or something original?
[17:41] <brianchidester> do you know?
[17:41] <slangasek> brianchidester: I don't think it's based on UNR
[17:42] <rgreening> slangasek: hey. I haven't anything up yet... not even sure where to start (seeing I was voluntold to work on it .. hah). Any pointers slangasek?
[17:43] <slangasek> rgreening: mm, not really :/  Maybe ScottK has a notion of what the test case scope needs to be
[17:43] <rgreening> brianchidester: it's going to use the new KDE netbook plasma desktop being developed. (eventually).
[17:44] <brianchidester> rgreening: is this a community project then? and what does the kubuntu team have for qa resources?
[17:44] <rgreening> brianchidester: for now, it's simply a tweaked kubuntu-default-settings for kubuntu-netbook metapackage (change some package defaults and fonts sizes, etc for better visibility on netbooks).
[17:44] <slangasek> rgreening: at the last release meeting, ScottK indicated that work was started on the test cases though, wonder why that is?
[17:44] <rgreening> slangasek: prob cause it sounded better :)
[17:45] <rgreening> brianchidester: it is indeed a community project, like kubuntu is
[17:45] <rgreening> I'm no QA expert... I helped write the usb-creator-kde front-end... I think thats why I was volunteered.
[17:45] <brianchidester> rgreening: and consequently only community qa, ok
[17:46] <rgreening> ya
[17:46] <brianchidester> rgreening: the reason I am interested is because oem has fairly comprehensive test suite but does not have any kde test cases
[17:46]  * rgreening thinks QA is Questions and Answers (just kidding)
[17:47] <rgreening> I can help, but I need very specific things to test/doc/write-up... seeing I have no experience with this.
[17:47] <brianchidester> rgreening: the plan for the not too distant future is a repository of test cases in testcases.qa.ubuntu.com but until then we (I) am doing work to collect/write them for us (oem)
[17:47] <rgreening> ok
[17:48] <brianchidester> but the answer is there has been no work done on that yet rgreening?
[17:48] <rgreening> that would be accurate
[17:49] <brianchidester> rgreening: and are you heading that up or is ScottK?
[17:49]  * rgreening has been bogged down with my paying job.. doing perf reviews
[17:49] <rgreening> I'm going to have to defer to ScottK...
[17:49] <rgreening> unless I get some more detailed direction...
[17:49] <brianchidester> rgreening: i don't mean to put any pressure on you, actually i want to help I just need to know who to coordinate with
[17:50] <rgreening> brianchidester: I'm willing to help, but I need specifics. :) I'm a "here's the list of goals" kind of guy...
[17:50] <rgreening> I PM'd ScottK, but he doesn't seem to be around at the moment...
[17:51] <rgreening> ScottK: Is definately more knowledgable than I in this area.
[17:51] <brianchidester> rgreening: then I will work with you on that, do we have a spec for the kubuntu netbook build? what is that going to be called by the way
[17:51] <brianchidester> i would assume not knr
[17:51] <rgreening> def no remix
[17:51] <rgreening> it's not a remix :)
[17:52] <Riddell> it probably is
[17:52] <rgreening> lol.... Riddellwe discussed at uds, and didn't want to use the term remix
[17:52] <brianchidester> rgreening: i think strictly speaking it is though the term is not clearly defined
[17:52] <slangasek> it's called "Kubuntu Netbook"
[17:52] <rgreening> ya
[17:52] <brianchidester> ok cool
[17:52] <brianchidester> and is there a spec for it yet?
[17:52] <slangasek> the term is clearly defined, and then UNR goes against the definition
[17:53] <brianchidester> that sounds to be a more accurate assessment yes
[17:54] <rgreening> lol
[17:54] <rgreening> brianchidester: let me see if I can locate the spec (unless Riddell can find it faster)
[17:54] <Riddell> https://wiki.kubuntu.org/KubuntuKarmicNetbook
[17:55] <rgreening> see. Riddell is faster than a speeding bullet. no wonder he's our super man :P
[17:55] <brianchidester> Riddell: too bad someone didn't continue with that illiteration then we could have had a nice neat acronym for it like unr only KKK
[17:56] <brianchidester> s/alliteration
[17:57] <rgreening> ouch....
[17:57] <rgreening> hah
[17:57] <rgreening> K2N maybe :)
[17:57] <rgreening> or 2KN
[17:57] <brianchidester> so i'm the only one who thinks its a good acronym, i guess we wont go with it then
[17:58] <rgreening> not unless you want to go join forces with the Satantic version of Ubuntu
[17:58] <rgreening> :P
[17:58] <brianchidester> rgreening: i will take a look at the spec and get back to you and ScottK with your checklist
[17:58] <brianchidester> i always thought that was an interesting little variation...
[17:58] <rgreening> brianchidester: that would be awesome. I can work from a checklist :)
[17:58] <rgreening> heh
[17:58] <brianchidester> alright cool, thanks
[17:59]  * ogra waits for the xubuntu NR ...
[19:02]  * directhex pokes james_w 
[19:07] <cjwatson> brianchidester: ScottK has been using the abbreviation "KNE"
[19:14] <slangasek> kees: 'incomplete' doesn't look like the correct state for bug #202089?
[19:14]  * slangasek sets back to 'triaged'
[19:17] <jdstrand> Keybuk, kees: do you guys know of any security implications of having /sys/kernel/debugfs mounted by default?
[19:17] <jdstrand> mdeslaur: ^
[19:19] <brianchidester> cjwatson: thanks :-)
[19:20] <brianchidester> cjwatson: what does the e stand for?
[19:20]  * jdstrand -> afk
[19:20] <cjwatson> brianchidester: edition
[19:20] <brianchidester> assuming it kubuntu netbook...
[19:20] <brianchidester> gor it
[19:20] <cjwatson> (as in the wiki page name)
[19:20] <kees> slangasek: okay, true
[19:20] <cjwatson> err, or not
[19:21] <brianchidester> s/gor/gotr
[19:21] <kees> slangasek: I've flipped 326532 to triaged as well.
[19:21] <cjwatson> as in the spec name
[19:21] <kees> jdstrand: don't know.
[19:21] <brianchidester> yeah i was wondering which page exactly
[19:21] <kees> jdstrand: seems like it might have funny stuff in it
[19:21] <brianchidester> yes i see
[19:23] <jdstrand> kees: yeah, that is what I was thinking, but I don't know enough about it
[19:26] <jdstrand> Keybuk: I'm not sure I feel comfortable mounting debugfs by default. I'd need to research it and don't have time atm. I think I will make my mountkernfs.sh change without it for now
[19:27] <kees> jdstrand: sounds from other devs like it's not a good thing to have mounted by default
[19:27] <kees> jdstrand: though in theory, it's all only read-only by root
[19:27] <jdstrand> Keybuk: ^
[19:28] <jdstrand> kees: thanks for looking into it-- google wasn't as forthcoming as I would have hoped :)
[19:28] <kees> jdstrand: I asked gregkh, so it's not exactly a wide range of opinions.
[19:29] <jdstrand> kees: it's enough that we are in agreement on concern and the original developer (iirc) of it feels it probably isn't best
[19:29] <Keybuk> jdstrand: it gets mounted anyway if you use sreadahead
[19:29] <jdstrand> it can be revisited if needed
[19:30] <jdstrand> Keybuk: is sreadahead installed by default in all of Ubuntu now?
[19:30] <Keybuk> but sure, I guess it's not suitable for a security team member to make the change if he's uncomfortable with it ;)
[19:30] <Keybuk> jdstrand: planned to be in karmic
[19:31] <jdstrand> Keybuk: huh, even server?
[19:31] <Keybuk> jdstrand: sure
[19:31] <jdstrand> interesting
[19:31] <kees> can we make the mount point 0700  ?
[19:31] <Keybuk> jdstrand: even servers care about a faster boot
[19:31] <jdstrand> anyhoo, I'd rather not add it myself at this point
[19:31] <Keybuk> kees: sure
[19:32] <kees> I'm happier with that then.
[19:32] <cody-somerville> chrisccoulson, I was just wondering if you were going to merge my branch in or if there was any problems with it
[19:36] <cody-somerville> jdstrand, Do you know if Debian uses -Wl,-z,relro and -fstack-protector by default?
[19:37] <jdstrand> cody-somerville: kees is the one to ask. I think they are doing some stuff with hardening-wrapper, but I don't know how much off-hand
[19:38] <cody-somerville> jdstrand, kees: do you know if and how much of a performance impact some of these flags have?
[19:39] <kees> cody-somerville: they do not use it by default.
[19:40] <kees> cody-somerville: relro has literally zero performance cost
[19:40] <kees> cody-somerville: stack-protector adds about 4 instructions per large-stack function, and has no measureable performance hit.
[19:41] <kees> cody-somerville: there are about 29 packages in Debian using hardening-wrapper
[19:42] <kees> cody-somerville: note that h-w adds PIE as well, which has about 4% performance loss, unless it is a very .text-code heavy application (like a JIT, scripting language, etc), where it can in some situations get as high as 15% loss.
[19:42] <kees> cody-somerville: Ubuntu does not use PIE by default.  (note that the performance hit from PIE is ia32 only)
[19:43] <kees> cody-somerville: why do you ask about relro?  (that's an uncommon feature.)  the "next step" for relro is to add -Wl,-z,now but that has start-up time issues, so I was planning to apply those on a case-by-case basis.
[19:44] <andre_pl> I've noticed what I think is a regression from 8.04 to 8.10 with regards to PIL (python-imaging package) on packages.ubuntu.com, the only differences I see are python-central and zlib1g versions. the latter of which appears to have been bumped down a revisions. does anyone know perhaps why this happened or if it could be related to png transparency issues?
[19:47] <cjwatson> I don't know about python-imaging but FWIW I think you're mistaken about zlib1g ...
[19:47] <cjwatson>     zlib1g | 1:1.2.3.3.dfsg-7ubuntu1 |         hardy | amd64, i386
[19:47] <cjwatson>     zlib1g | 1:1.2.3.3.dfsg-12ubuntu1 |      intrepid | amd64, i386
[19:47] <cjwatson> (says rmadison)
[19:48] <andre_pl> cjwatson: http://packages.ubuntu.com/intrepid/python/python-imaging http://packages.ubuntu.com/hardy/python/python-imaging
[19:48] <andre_pl> that site must be wrong then
[19:50] <cjwatson> andre_pl: oh, minimum version of the dependency isn't the same as what you'll actually have installed
[19:50] <andre_pl> I see.
[19:50] <cjwatson> andre_pl: that's probably just because there were changes in dpkg-dev a while back to try to weaken shared library dependencies a bit when stronger ones weren't necessary
[19:51] <andre_pl> how can I deltermine exactly which version is installed? because the problems I'm see could definitely be caused by zlib, and it seems to be the only dependency that might be different.
[19:51] <andre_pl> and heavily used by libpng
[19:51] <cjwatson> dpkg-query -W zlib1g
[19:52] <andre_pl> ok, so the intrepid version is slightly newer, -12ubuntu1 vs -7ubuntu1
[19:53] <andre_pl> could it be catastrophic to try installing the hardy packages on jaunty?
[19:53] <andre_pl> intrepid rather
[19:55] <cody-somerville> kees, Just pondering about why people report that they feel Debian is faster than Ubuntu sometimes
[19:55] <cjwatson> andre_pl: beware that it's a long-known bug in dpkg that it doesn't report dependency problems on downgrade
[19:55] <cjwatson> andre_pl: so quite possibly yes, you'd have to be careful
[19:56] <cjwatson> andre_pl: would be safer to unpack the old zlib1g in your home directory and use LD_LIBRARY_PATH to point to it
[19:56] <andre_pl> is there a safer alternative? maybe a backport from 9.x?
[19:56] <kees> cody-somerville: I would guess kernel, honestly.
[19:57] <andre_pl> i suppose i could test on jaunty and see if it has the issue too
[19:57] <cjwatson> andre_pl: can't say without knowing what the problem is :)
[19:58] <cjwatson> (err, that's not really "please tell me what the problem is", since I doubt it's my area of expertise ...)
[20:00] <andre_pl> haha, understandable. I'm willing to do all the legwork, I'm just not sure whats generally the safer option, bacport or downgrade.
[20:03] <cjwatson> andre_pl: usually safest of all is "find patch, backport just that patch"; in the absence of that, for reasonably stable libraries backporting is on the whole safer because that way you don't tend to lose ABIs
[20:06] <andre_pl> ok, i'll see what I can do, thanks
[20:10] <andre_pl> cjwatson: is there somewhere I can find a changelog of each small revision to a package? because the PIL version differs slightly too.
[20:11] <cjwatson> andre_pl: just look in /usr/share/doc/<package>/changelog.Debian.gz
[20:11] <cjwatson> or if that's missing changelog.gz
[20:11] <cjwatson> you can also get the source packages from Launchpad (https://launchpad.net/ubuntu/+source/<package>) and use debdiff (in the devscripts package) to compare them, if you want to get more detail than that
[20:12] <andre_pl> cool thanks
[20:16] <andre_pl> cjwatson: FWIW the bug exists in jaunty too
[20:16] <andre_pl> i need a second hardy machine to test on i think.
[20:17] <andre_pl> maybe i did something to fix it on hardy that I have zero recollection of
[20:32] <cudev> Anyone know what the message "if-up.d/mountnfs [device__]: lock /var/run/network/mountnfs exist, not mounting" at boot time means? It is preventing me from bringing up my devices at interface cards at boot. Of my 6 nics, only the one with a static IP comes up, but I can bring up the others after boot using 'ifconfig device__ up"
[21:23] <soreau> Hello
[21:24] <soreau> I was wondering if compiz will be shipping with Karmic despite it's incompatibility with gnome-shell and if it will remain in the repos, which version will it be?
[21:27] <seb128> soreau, why shouldn't compiz be shipped, there is some ten thousand softwares in ubuntu, why would you want to remove something lot of people are using just because it's incompatible with some other software?
[21:28] <soreau> I never said I didn't want anything shipped, I was just asking for factual information in general
[21:28] <soreau> I assume compiz-0.8.2 will be in the repos, but not the default WM with gnome-shell
[21:29] <soreau> Maybe I should be asking if gnome-shell will be default in 9.10 because I am merely assuming that it will be
[21:30] <seb128> soreau, no it will not, it's an new project which has 0 tarball yet
[21:30] <seb128> soreau, it will not be default before 10.10 in any case
[21:31] <soreau> huh
[21:31] <seb128> soreau, it's a new project, has no tarball, has not been shipped by GNOME or any distro and has opengl requirements which don't fit for a default install
[21:31] <soreau> seb128: Well thanks for the information
[21:31] <seb128> you're welcome
[21:38] <A|i> is it safe to install mysql-server-5.1 for hardy from jaunty repository? I cannot find it for hardy
[21:38] <A|i> only this one: http://packages.ubuntu.com/search?keywords=mysql-server-5.1
[21:44] <lool> Hmm I'm seeing hangs in update-grub; it seems to be a debconf issue, perhaps in grub, but these packages didn't change recently
[21:44] <lool> bug #400397
[21:46] <lool> Could be new grub-common, but I don't see how
[22:04] <cjwatson> lool: commented
[22:04] <cjwatson> (summary: use db_stop only with ridiculous amounts of care or you will shoot yourself in the foot)
[22:06] <cjwatson> lool: I suggest removing that db_stop line and testing that, since you have a test rig handy ...
[22:41] <sladen> 400k++