[00:09] <Viper550> wait GRUB2?
[00:15] <Viper550> and are we ever going to use gfxboot on an install/
[00:15] <cody-somerville> Viper550, we're getting rid of usplash
[00:16] <cody-somerville> Viper550, We think we can boot so quickly we don't need anything like that
[00:23] <TheMuso> cody-somerville: its not going away entirely, it will be used for fsck/dm-crypt password entry.
[00:39] <cjwatson> soren,slangasek: I think livecd-rootfs actually runs in a hardy chroot for hardy CD builds, and we use the hardy version of it; however the ISO building code is central and so has to be guarded as slangasek says
[00:39] <slangasek> ah
[00:39] <slangasek> does that mean we could trim the hardy exceptions in the current version of livecd-rootfs? :)
[00:39] <cjwatson> slangasek: check with Adam, but I think so
[01:37] <Cameron> hi.. i'm trying out grub2, and managed to get it to work on jaunty, both chainload and native.  This was done using a separate hdd for /boot since my root partition is ext4 on lvm.  Now, I wish to test using /boot on my root partition.  I reconfgured /boot to be a normal folder, and ran this : grub-install /dev/sda  I received this error "error: Unknown metadata header" followed by grub-probe: error: no mapping exists for `Ubuntu
[01:37] <Cameron> -jaunty'
[01:37] <Cameron> then this Auto-detection of a filesystem module failed.  Please specify the module with the option `--modules' explicitly.
[01:38] <Cameron> cjwatson: you about ?
[01:47] <shaya> wondering if others are getting spammed like crazy by apport retracing service today on old bugs?
[01:47] <TheMuso> shaya: Yes, I am.
[01:48] <maco> aye
[01:58] <cjwatson> Cameron: about to go to bed, please do file a bug though - not many people have tried grub2 on lvm root yet (at least not in Ubuntu) and we clearly need to sort some things out
[01:59] <Cameron> cjwatson: shall do, thanks
[03:16] <Cameron> cjwatson: fyi the bug is here https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/385428
[03:17] <Cameron> thanks ubottu :)
[04:14] <AnAnt> Hello, is gdm2 available in any PPA ?
[04:14] <AnAnt> gdm 2.26 that is
[04:21] <Hobbsee> AnAnt: #launchpad for ppa questions.
[04:22] <persia> Hobbsee, Including content search?  I thought that was beyond the scope of that channel as well.
[04:22] <Hobbsee> persia: you're probaby right there.  Unless they can point him to where the search over ppas actually is
[04:23] <persia> I remember hearing about the PPA search tool recently, but I understood it to be external to LP itself.
[04:24] <nhandler> persia: You are probably thinking about http://ppa-search.appspot.com/
[04:27] <AnAnt> I thought maybe the ppl working on the new GDM were here, that's why I asked
[04:29] <persia> nhandler, Quite possibly, indeed.
[04:31] <AnAnt> yup, found it, thanks
[04:55] <poolie> hi, i'm running karmic with an intel gm965
[04:55] <poolie> in the last couple of days the screen has started sometimes going irretrievably blank
[04:56] <poolie> can anyone give me a pointer or should i just file a new bug?
[04:59] <persia> poolie, Have you experimented with the xorg-edgers repo?  It may break things more, but it may break them less.
[04:59] <poolie> yeah lifeless just suggested that
[04:59] <persia> (they don't call themselves the "Xorg Crack Pushers" for nothing.
[04:59] <poolie> it feels a bit like randomly changing things
[04:59] <poolie> i'd rather have some tea
[05:00] <persia> It *is* randomly changing things.
[05:00] <persia> But theoretically, if you have an issue, and it's fixed by the crack, that's valuable information to provide in the bug.
[05:00] <poolie> yes
[05:00] <poolie> i'll file a bug then try it
[05:02] <Hobbsee> poolie: oh yeah, i've been noticing that.  it's a pain
[05:03] <poolie> ok bug 385448
[05:03] <poolie> hello Hobbsee
[05:03] <Hobbsee> poolie: heya!
[05:08] <nixternal> come on, accept kdebindings binaries already :p
[05:09]  * nixternal needs python-kde4 to continue working
[05:12] <poolie> so there seem to be no karmic builds in
[05:12] <poolie> deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu jaunty main
[05:13] <lifeless> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
[05:14] <ScottK> nixternal: I'd love to help you, but the package has mono stuff in it.
[05:14] <ScottK> ;-)
[05:14] <nixternal> lol
[05:14] <nixternal> w/o kdebindings getting in, anything with pykde will not work
[05:15] <nixternal> things such as ubiquity, gdebi, printer, and so forth
[05:15] <ScottK> nixternal: I'm looking at it for binary New now.
[05:16] <lifeless> https://edge.launchpad.net/~xorg-edgers is the one : it has the git builds that lead into what will land in ubuntu
[05:17] <ScottK> nixternal: Accepted.  You should have the binary in ~90 minutes.
[05:17]  * nixternal hugs ScottK 
[05:25] <poolie> lifeless: thanks, i think that's a bit too scary atm
[05:25] <poolie> or rather, beyond the depth i want to get into this
[05:25] <poolie> at least til bryce asks
[05:31] <lifeless> poolie: so, bryce has asked somewhat generally :). But thats ok - I'm sure he will
[06:39] <pitti> Good morning
[06:39] <nixternal> and good morning to you sir
[06:39] <pitti> hey nixternal
[07:19] <\sh> moins
[07:19] <\sh> slangasek: thx...I solved it in a more sane way..."do not install menu.lst manually, but call update-grub -y, so it installs a newly created menu.lst"
[07:21] <slangasek> that would also do it
[07:22] <slangasek> "sane" - it discards any existing settings in menu.lst, so it's not usually my first recommendation
[07:23] <\sh> slangasek: the problem was during initial installation...so it doesn't have any changes :)
[07:23] <slangasek> ok
[07:27] <StevenK> Blink
[07:27] <StevenK> Where did the udev rules go ....
[07:27] <pitti> StevenK: to /lib/udev/rules.d/ ?
[07:28] <StevenK> Sigh. Nice if /etc/udev/rules.d was a symlink to that, but dpkg doesn't like that situation
[07:28] <pitti> nah, it shouldn't
[07:28] <pitti> /etc/udev/rules.d is for local customization
[07:28] <dholbach> good morning
[07:28]  * pitti hugs dholbach
[07:28]  * dholbach hugs pitti back
[07:29] <StevenK> pitti: Ah, so I can drop a rule in /etc/udev/rules.d and it will override what is in /lib/udev/rules.d for say, that particular SUBSYSTEM ?
[07:30] <pitti> StevenK: AFAIK they are executed in addition
[07:30] <maxb> same-named files override
[07:30] <maxb> or at least, that's what the manpage claims
[07:30] <pitti> "Files in /etc/udev/rules.d/ have precedence over files with
[07:30] <pitti>        the same name in /lib/udev/rules.d/."
[07:30] <pitti> right
[07:35] <\sh> unsubscribe ubuntu-devel-discuss
[07:35] <\sh> done
[08:03] <ttx> slangasek: created likewise-open5 bug 385475
[08:18] <jamesh> pitti: hi.  there was a bit more discussion about the Erlang packages that it seems you weren't CC'd on.  I've just forwarded you an email with the current status.
[08:29] <\sh> releases.ubuntu.com
[08:29] <\sh> down?
[08:31] <\sh> argl...damn telemaxx carrier
[08:32] <iulian> \sh: Seems so.  It failed to connect here as well.
[08:32] <\sh> iulian: from my home carrier (kabelBW) it works
[08:32] <iulian> Huh?  That's odd.
[08:32] <iulian> It fails to connect here.
[08:39] <\sh> iulian: which ip address do you get for releases.ubuntu.com?
[08:39] <\sh> 130.239.18.163 or 130.239.18.137 ?
[08:41] <\sh> looks like that it's a dns caching problem .. good to know that my DNS on my rooty is configured properly and not doing wile things
[08:41] <\sh> s/wile/wild/
[08:46] <iulian> \sh: releases.ubuntu.com has address 130.239.18.163
[08:50] <\sh> iulian: and that's wrong..dns caching issue...
[08:50] <soren> cjwatson: Ok. Thanks for clarifying.
[08:51] <\sh> I just kicked our DNS admin to do his job
[08:56] <nixternal> pitti: re: apport - should I look at implementing the features that GTK has compred to Qt? is there a reason they aren't implemented already?
[08:57] <nixternal> also, re: apport-qt - it will be rewritten in PyKDE4 - which is what I am messing around with now
[09:03] <AnAnt> Hello, why is wine in Ubuntu different than in Debian ?
[09:03] <AnAnt> I mean that Ubuntu doesn't use Debian's wine package
[09:06] <directhex> YokoZar, customer for you
[09:06] <YokoZar> directhex: oh?
[09:06] <directhex> AnAnt, (yokozar is in a yank timezone, so best to ask when america is awake)
[09:06] <directhex> oh. erm...
[09:06] <directhex> YokoZar, AnAnt's query
[09:07] <YokoZar> AnAnt: Because our Wine package provides more integration stuff and isn't split into useless subpackages
[09:07] <AnAnt> aha, ok
[09:08] <AnAnt> YokoZar: so, will wine 1.1 be in karmic ?
[09:11] <AnAnt_> sorry, I got d/c
[09:11] <AnAnt_> YokoZar: so, will wine 1.1 be in karmic ?
[09:12] <YokoZar> AnAnt_: 1.2 might be released in the Karmic timeframe
[09:12] <YokoZar> I don't want to hold people back on 1.0 for another release
[09:12] <AnAnt_> YokoZar: do you mean, that it is either 1.0 or 1.2 ?
[09:12] <YokoZar> So i've been pushing pretty hard upstream to have 1.2 out
[09:13] <YokoZar> 1.1 are development releases that aren't regression tested
[09:13] <AnAnt_> is 1.1 an unstable release ?
[09:13] <YokoZar> Yes, very much so
[09:13] <AnAnt_> aha, ok, thanks
[09:13] <nixternal> pitti: I am heading to bed, go ahead and highlight me with a response so I can work on it when I get up and about, thanks!
[09:13] <AnAnt_> oh, yes they are in experimental ! my bad !
[09:13] <YokoZar> I may need to pick a 1.1.x version and regression test it heavily around feature freeze if it looks like wine 1.2 isn't coming out in time
[09:45] <tjaalton> asac: hey, do you have plans to upload the fix to bug 220628 to jaunty-proposed?
[09:55] <cjwatson> pitti: Am I right in thinking that valid mount options have to be hardcoded into devicekit-disks - there's no mechanism for filesystems to ship fdi files or equivalent to override that? This is prompted by http://launchpadlibrarian.net/27592171/ntfs-3g_2009.4.4-1ubuntu1.patch (attached to bug 349569) which includes the changelog entry "Don't install HAL fdi file. Mounting is done via devkit-disks now."
[09:55] <cjwatson> pitti: but the fdi file was added as a workaround because the kernel driver doesn't support locale=
[10:07] <asac> tjaalton: oh right.
[10:07] <asac> tjaalton: if you want, go ahead ;)
[10:11] <tjaalton> asac: ok :)
[10:38] <cjwatson> lamont: I don't suppose you could have a look at bug 319656 (presumably wearing your Debian hat)? I can't reproduce the problem here and don't know nmap well enough to want to guess
[10:58] <Ampelbein> cjwatson: I can reproduce the issue with nmap. I sorted out the various "not a file" errors by copying the missing scripts to /usr/share/nmap/scripts, but still get http://paste.ubuntu.com/192405/
[11:02] <cjwatson> Ampelbein: I think it's probably best if lamont deals with it anyway, since he's the Debian maintainer :)
[11:03] <Ampelbein> cjwatson: ok, just in case you (or lamont) need a "victim" to test fixes on: I'm here. ;-)
[11:28]  * cjwatson belatedly remembers that during a soft freeze is a silly time to be catching up on main sponsorship. *blush*
[11:29] <dholbach> cjwatson: do *verse sponsorship instead! :-)
[11:30] <dholbach> unfortunately there's enough to choose from
[11:30] <cjwatson> already am ;-)
[11:31] <dholbach> although we're slowly catching up
[11:31]  * dholbach hugs cjwatson
[11:58] <chrisccoulson> hey pitti / cjwatson - i just saw the comment on bug 349569
[11:58] <chrisccoulson> you had any thoughts about that yet?
[12:19] <pitti> jamesh: ah, thank you
[12:20] <pitti> nixternal: what's still missing in the qt version? It should be on feature parity now, AFAIK
[12:20] <pitti> chrisccoulson, cjwatson: looking (just returned from appointment, sorry for delay)
[12:21] <chrisccoulson> piit - no hurry. i was just wondering if you already discussed it or not
[12:21] <chrisccoulson> **pitti
[12:21] <chrisccoulson> lol
[12:22] <directhex> seb128, ping - do you think it's preferable for banshee's magnatune plugin to spawn a web browser for purchases, or take people's credit card details straight in the app? rhythmbox does both (window for downloads, web page for cd purchases)
[12:23] <seb128> directhex: hello, no real opinion on that I think both are fine, maybe better to ping mpt to get some design team advice though
[12:24] <seb128> directhex: I would tend to say that using the website in a browser we are in a known environment security wise
[12:25] <seb128> so it makes things easier
[12:25] <directhex> seb128, i agree - but it's less "integrated"
[12:25] <directhex> so damned if you do, damned if you don't
[12:26] <seb128> that's why I say "no real opinion"
[12:26] <seb128> I think both options will do
[12:26] <seb128> so whatever somebody is wanting to do
[12:29] <stgraber> pitti: hey, about the numlockx MIR, what do you mean by the two questions from comment 1 ? Didn't I answer them in the following comment (and in the MIR wikipage itself) ? or did I miss something ?
[12:37] <pitti> cjwatson: I asked on the upstream ML
[12:38] <pitti> stgraber: right, I see now that you mentioned the Xsession.d file in the MIR; are you going to look after the package then?
[12:43] <directhex> seb128, a clicky button which spawns "xdg-open https://magnatune.com/buy/choose?sku=XXXXXXXXXXX&sitePrefix=" is the easy option - assuming one can retrieve the value for XXXXXXXXXXXX somehow, without downloading & searching the full site database client-side. i've mailed magnatune to ask foir suggestions
[12:43] <directhex> looks like jamendo's api is miles better
[12:43] <seb128> ok
[12:48] <cjwatson> pitti: thanks
[13:01] <stgraber> pitti: yeah
[13:03] <\sh> cjwatson: are you interested in some theories that the udev.postinst is quite dangerous at some time? :)
[13:05] <siretart`> If I'm reading udev.postinst right, then a dpkg-reconfigure udev will instantly kill /sbin/udevadm
[13:05] <\sh> cjwatson: actually a well configured udev is available then you just do out of couriosity a dpkg-reconfigure -a -f noninteractive and /sbin/udevadm is just gone
[13:05] <siretart`> which is rather bad :-)
[13:07] <stgraber> pitti: btw, didn't I also answer this question in the reply to your comment ? (in-line)
[13:08] <pitti> stgraber: I don't see it anywhere
[13:09] <stgraber> "Oh, thanks for spotting this. I'll update that part of the MIR.
[13:09] <stgraber> I'm fine maintaining it in Ubuntu as I'll be the main user of it anyway."
[13:10] <pitti> ah, heh
[13:11] <lamont> cjwatson: I'll get a look at it this week
[13:12] <cjwatson> \sh: -> Keybuk
[13:12] <cjwatson> lamont: thanks!
[13:12] <Keybuk> \sh: why would you ever dpkg-reconfigure udev?
[13:13] <\sh> Keybuk: tbh...it is an accident of lazyness ;)
[13:13] <ogra> heh, accidential lazyness ? sounds funny
[13:13] <\sh> Keybuk: but nevertheless, if someone would call dpkg-reconfigure -a or dpkg-reconfigure udev he/she will run into this very problem and has a system which can't update any kernel/initramfs anymore
[13:14] <Keybuk> \sh: can't see a bug about it
[13:14] <\sh> Keybuk: I'll file one...
[13:14] <cjwatson> I agree that the current code looks wrong
[13:14] <ogra> accidential lazyness ;)
[13:14] <cjwatson> (although it's a corner case)
[13:14] <\sh> cjwatson: sure :)
[13:14] <Keybuk> cjwatson: any idea for a fix?
[13:15] <cjwatson> Keybuk: wrap the contents of enable_udevadm with if [ -e /sbin/udevadm.upgrade ]; then ... fi
[13:15] <Keybuk> cjwatson: seems sane
[13:15] <Keybuk> though you wouldn't want to restart udevd either
[13:15] <Keybuk> in fact
[13:15] <Keybuk> at a quick glance, none of configure is appropriate
[13:16] <cjwatson> DEBCONF_RECONFIGURE=1 is set in the environment during reconfigure, if you want to guard it
[13:16] <Keybuk> that's probably the easiest
[13:16] <\sh> hmmm...
[13:16] <Keybuk> \sh: bug #366185
[13:17] <\sh> Keybuk: bug #366185 looks just the same...
[13:17] <\sh> Keybuk: I see you just renamed it :)
[13:18] <Keybuk> yeah, just read through the bugs
[13:18] <\sh> Keybuk: thx for taking care :) do you think it's worth an -proposed/-updates upload?
[13:18] <\sh> for jaunty
[13:19] <Keybuk> I always say no until someone says otherwise ;)
[13:20] <\sh> Keybuk: I'd say yes, 2 1/2h of debugging is a lot of time..and time is money ;)
[13:20] <Keybuk> I meant someone in ubuntu-release ;)
[13:23] <\sh> Keybuk: oh I forgot that ;)
[13:29] <stgraber> pitti: thanks
[13:33] <lifeless> should evince be able to print pdf's?
[13:35] <liw> lifeless, I do it frequently
[13:36] <lifeless> ctrl-P is not working and thereis no 'print' in my evince menu...
[13:37] <lifeless> buggeration time
[13:38] <pitti> hm, I print from evince all the time
[13:38] <lifeless> It works if I adda print button to the toolbar
[13:39] <lifeless> just the hotkey and menu item are awol
[13:39] <pitti> lifeless: hm, both work for me, in jaunty and karmic
[13:39] <pitti> weird
[13:39] <lifeless> this is jaunty
[13:42] <soren> lifeless: What are you trying to print?
[13:43] <lifeless> soren: a pdf
[13:43] <soren> lifeless: Clever.
[13:43] <soren> :p
[13:43] <lifeless> that was sent to me to print out and sign
[13:43] <soren> lifeless: Is it something that is likely to be marked "don't print"?
[13:43] <soren> lifeless: Ah.
[13:43] <soren> Ok, then probably not :)
[13:43] <lifeless> soren: see above, adding a toolbar icon let me print
[13:44] <soren> lifeless: Yes, I saw. I was just trying to figure out if *that* was the bug.
[13:44] <pitti> lifeless: do you also get it on /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf ?
[13:44] <soren> Truth be told, I don't know how evince deals with "non-printable" PDF's.
[13:45] <liw> lifeless, if it is the same PDF I was sent, my evince shows a print item in the menu just fine (jaunty)
[13:45] <lifeless> pitti: same behaviour
[13:45] <lifeless> liw: from the isle?
[13:45] <lifeless> liw: if so, yes.
[13:46] <lifeless> foo
[13:46] <lifeless> E [10/Jun/2009:22:40:11 +1000] PID 20891 (/usr/lib/cups/backend/ipp) crashed on signal 6!
[13:48] <lifeless> the above however makes it hard to actually get the paper out of the print
[13:48] <lifeless> er
[13:51] <sabdfl> Setting up linux-restricted-modules-common (2.6.28-13.17) ...
[13:51] <sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
[13:51] <sabdfl> update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
[13:51] <sabdfl> is that normal?
[13:52] <ogra> sabdfl, if the maintainer didnt update the initscript to newer LSB yet, yes ... its just a warning though
[13:53] <ogra> doesnt do any harm
[13:53] <sabdfl> doesn't look like something we should have in a kernel package, though
[13:53] <ogra> agreed
[13:53] <sabdfl> pgraner: ^?
[13:54] <mok0> sabdfl: ah, yes, it's missing all that header stuff
[13:55] <mok0> ... but it does use the proper lsb functions
[13:56] <mok0> Isn't the init system going to be transitioned anyways?
[13:56] <wgrant> mok0: That's been happening next release since Edgy :P
[13:57] <ogra> if Keybuk makes it in time :)
[13:57] <mok0> Heh, ok
[13:57] <mok0> That header information is supposed to give some kind of dependency... allowing stuff to be started in parallel
[13:59] <mok0> wgrant: btw, the science team is dwindling
[14:00] <cjwatson> sabdfl: bug 3055878
[14:00] <cjwatson> oops
[14:00] <mok0> wgrant: only 4 members left :-(
[14:00] <cjwatson> sabdfl: bug 305587
[14:00] <wgrant> mok0: So it seems. :(
[14:00] <sabdfl> thanks colin
[14:00] <Keybuk> ogra, mok0: upstart will still use those LSB headers
[14:00] <Keybuk> in fact, we'll probably start to rely on them
[14:00] <Keybuk> so them being missing or wrong is a bug for Ubuntu
[14:00] <mok0> Keybuk: see sabdfl's question in the scrollback
[14:00] <ogra> well, for karmic :)
[14:01] <ion_> mok0: The more important thing is that their ordering can be automated. If new package baz must start before rc2.d/S20foo and after rc2.d/S20bar, the maintainer must discuss it with two other maintainers, and if 20foo is changed to 21foo and 20bar to 19bar, *that* may have repercussions for an indefinite number of other packages. That’s why Debian is trying to transition to automatic ordering based on LSB headers.
[14:01] <ogra> in jaunty its only cosmetic ... while it will do harm in karmic
[14:01] <Keybuk> mok0: what was sabdfl's question?
[14:02] <ogra> sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
 update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 is that normal?
[14:02] <Keybuk> right, it's not normal, it's a bug
[14:02]  * Keybuk thought he covered that ;)
[14:02] <mok0> Well, back to the old drawing board :-)
[14:02] <mok0> terminal window, rather
[14:03] <Keybuk> our sysv-rc doesn't use them
[14:03] <Keybuk> but when we drop sysv-rc, we will
[14:03] <ogra> and its already drawn :)
[14:03] <mok0> bug 305587
[14:03] <Keybuk> my whiteboard appears to have a picture of a duck on it
[14:03] <Keybuk> don't ask me why
[14:06] <mok0> Keybuk: Ask Pat Robertson
[14:06] <ogra> not walt disney ?
[14:06]  * liw votes for Don Rosa
[14:07] <mok0> ogra: Pat Robertson claims that gay marriage leads to sex with ducks :-P
[14:07] <mok0> http://www.poormojo.org/pmjadaily/archives/026958.php
[14:07] <ogra> aww
[14:10] <mok0> Of course Jon Steward had a field day with that on TDS
[14:14] <directhex> yay ducks
[14:17] <Keybuk> mok0: http://andrewsullivan.theatlantic.com/the_daily_dish/2008/11/the-cosequences.html
[14:30] <mok0> Keybuk: :-D
[14:31] <ogra> asac, its back ! (klicking Keybuk's link got me broken fonts again)
[14:31] <wgrant> ogra: Broken how?
[14:32] <ogra> wgrant, http://people.ubuntu.com/~ogra/ff_fonts.png like that
[14:32] <ion_> liw: Have you had a chance to look at my comments? No hurry at all, just curious to hear whether they are even remotely sane. :-P
[14:32] <wgrant> ogra: That's probably a -intel bug.
[14:32] <wgrant> There was one filed on fd.o a while ago... let's see if I can dig it up.
[14:32] <ogra> wgrant, we werent sure yesterday ...
[14:33] <ogra> that'd be cool
[14:33] <ogra> it isnt really reproducable, just shows up after some time
[14:33] <wgrant> Right.
[14:33] <wgrant> I find it happens more when I close windows.
[14:33] <ogra> and only in FF
[14:33]  * ogra doesnt use windwos :P
[14:34] <ion_> Every time someone talks about (non-)reproducable bugs, i can’t help being reminded of the xkcd strip.
[14:35] <asac> ogra: i was quite sure yesterday that its a driver bug ;)
[14:35] <asac> file it against -intel
[14:36] <ogra> lets see if we can link it to an upstream bug right away ;)
[14:36] <ogra> if wgrant finds it
[14:36] <wgrant> ogra: I can't seem to find it :(
[14:37] <liw> ion_, nope, sorry, still digging myself out into the clear air
[14:37] <liw> ion_, try again tomorrow :)
[14:37] <ion_> :-)
[14:37] <wgrant> Fedora bug #495323 looks relevant.
[14:37] <wgrant> Seems it was a kernel bug?
[14:37] <wgrant> redhat 495323
[14:37] <wgrant> fedora #495323
[14:38] <cjwatson> (I find it sometimes copes better with URLs)
[14:39] <wgrant> https://bugzilla.redhat.com/show_bug.cgi?id=495323
[14:39]  * wgrant grumbles.
[14:40] <wgrant> Aha! It lives.
[14:40] <ogra> yeah, looks the same
[14:41] <wgrant> - Add drm-intel-set-domain-on-fault.patch to fix random gem object corruption when swapping (495323 and probably others).
[14:41] <wgrant> From their kernel changelog.
[14:41] <Sarvatt> ogra, if you want to use UXA it needs a kernel update which went upstream a few weeks ago
[14:41] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=21790
[14:41] <wgrant> Ah, that's the bug I was trying to find.
[14:42] <ogra> Sarvatt, i'm running karmic, uses UXA by default
[14:42] <Sarvatt> 2.6.30-8.9?
[14:46] <asac> pitti: slangasek: StevenK: wonder if you would want to unsubscribe ubuntu-archive from 352968 for now as there will be some traffic now that i fix the build depends up-front
[14:46] <ogra> bug 385561
[14:49] <Sarvatt> the fix is in karmic kernel 2.6.30-8.9 which is why I was asking if you were using that incase you weren't for some reason
[14:51] <ogra> oh, wait, i use -7 still ...
[14:51] <Sarvatt> if you are it could use going upstream because it didnt get fixed in your case
[14:51]  * ogra curses the update-manager behavior once again
[14:51] <Sarvatt> ahh that'd explain it
[14:52] <ogra> let me update manually
[14:53] <StevenK> asac: Done.
[15:04] <tkamppeter> pitti, hi
[15:05] <pitti> hi tkamppeter
[15:10] <tkamppeter> pitti, I have a problem with applying the CUPS changes.
[15:11] <pitti> tkamppeter: I saw your mail
[15:11] <pitti> tkamppeter: Debian didn't take the change?
[15:11] <pitti> tkamppeter: can we apply the change without the new option for now?
[15:12] <pitti> tkamppeter: so that all these regressions will be fixed in both Debian/Ubuntu
[15:12] <pitti> (I get tons of Debian bug reports as well)
[15:12] <pitti> tkamppeter: and then we can upload an Ubuntu-specific cups with the -origpagesizes option
[15:12] <pitti> tkamppeter: and sync back once Debian takes it
[15:15] <tkamppeter> pitti: Debian did not touch my bug report yet (I hope the maintainer comes around with it before our FF).
[15:16] <tkamppeter> What I have done now is to change the patch to make ./configure autodetect the presence of -origpagesizes and to build with it only if it is present.
[15:16] <pitti> tkamppeter: so if you could apply the bulk of the patch to bzr, and then just do an -ubuntu1 upload with the additional -origpagesizes patch, that would be best
[15:17] <pitti> tkamppeter: oh, great
[15:17] <pitti> that's even better
[15:18] <tkamppeter> pitti: So this means I put this bulk into the BZR and do an Ubuntu upload with a versioned Poppler build AND binary dependency in debian/contro;
[15:18] <pitti> tkamppeter: no, you can commit everything to bzr then; you don't need a versioned poppler dependency at all then
[15:18] <pitti> tkamppeter: (pdftops --help 2>&1| grep -q -- -origpagesizes ?)
[15:19] <pitti> tkamppeter: or how do you detect this?
[15:19] <tkamppeter> Yes, I check whether the help message of pdftops contains -origpagesizes.
[15:20] <pitti> cool
[15:20] <tkamppeter> But I do it at build time, so if the build server already switched to the new pdftops but the user not yet, the filter will fail.
[15:20] <pitti> tkamppeter: I have an idea how to fix this; please commit your's to bzr, I'll do the substvars magic
[15:21] <asac> anyone uses bfilter?
[15:23] <tkamppeter> pitti, OK.
[15:34] <Keybuk> WTF
[15:35] <Keybuk> my phone just declared that "a BaseBand Core Dump is in Progress"
[15:35] <liw> Keybuk, thanks
[15:35] <liw> I've been tempted by an evil phone today again, now I'm all better
[15:35] <liw> (and now I can go back to drooling for a freerunner)
[15:38] <ion_> My phone has been automatically changing its timezone to UTC+1 recently.
[15:39] <persia> As "phones" become "computers", we can only expect the quality of service to change to match the functionality.  Long live the ATT Model 500!
[16:01] <slangasek> ttx: thanks, added to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview (which, btw, you're free to edit directly ;)
[16:02] <ttx> slangasek: will do, next time :)
[16:04] <asac> doko: classpath build deps not installable? http://paste.ubuntu.com/192655/
[16:05] <doko> dpkg: unrecoverable fatal error, aborting:
[16:05] <doko>  fork failed: Cannot allocate memory
[16:05] <doko> E: Sub-process /usr/bin/dpkg returned an error code (2)
[16:05] <doko> what does this have to do with classpath?
[16:06] <ion_> Do you have an ulimit that might have something to do with that?
[16:11] <asac> doko: err. well, the problem is that it cannot install the build-deps
[16:11] <asac> let me retry
[16:12] <doko> asac: classpath really should be updated to the 0.98 release
[16:12] <asac> doko: but you spotted it  ;)
[16:12] <ogra> must be the new java implementation of dpkg :P
[16:13] <asac> doko: well. i fix the libxul-dev depend now
[16:13] <asac> to be xulrunner-dev
[16:13] <doko> asac: not an oem task ;-p
[16:13] <asac> thats why i am doing it ;)
[16:16] <asac> so gcj conflicts now gcjdoc.
[16:16] <asac> what a mess
[16:17] <asac> err gcj-jdk conflicts gcjdoc
[16:18] <asac> lets see if moving build depend to that helps ;)
[16:22] <Aquina> hy
[16:23] <Aquina> aa-logprof and aa-genprof ask for usernames and passwords after creation or before reading logs. Unfortunately the server cannot be contacted.
[16:24] <asac> superm1: wanna upload new bluez?
[16:24] <asac> (after alpha2)
[16:24] <superm1> asac, i'm actually thinking i'm gonna sync to debian
[16:24] <mterry> slangasek: BTW, I've seen several packages in Debian that use dep5 already while I've been merging.  Might be larger use that you think
[16:24] <superm1> i've been reviewing all the delta between us
[16:24] <mterry> slangasek: (I remember you suggesting nobody uses it yet)
[16:25] <superm1> but sure, i'll either sync or upload a new version post alpha2
[16:25] <asac> superm1: ok. great. do you think pulse is up to date enough? i would like to call for testing after we updated all the pieces for testing (with the gnome-bluetooth thing)
[16:26] <superm1> asac, i'm not sure the status of that pulse bluetooth plugin, dtchen, can you comment?
[16:26] <superm1> but yeah, a call for testing would be very good
[16:26] <asac> superm1: following the bluetooth-stack spec
[16:26] <asac> superm1: right. i just think we should have all the latest pieces because things seems to be still moving - especially on pulse freont

[16:27] <asac> ok so lets check after alpha2 is out
[16:27] <superm1> ok sounds good to me
[16:28] <slangasek> mterry: no, I'm sure there are some people using it; I just think it's premature because the spec is still subject to *significant* changes before it reaches anything approaching consensus in Debian
[16:28] <mterry> slangasek: OK, well just be assured that there's dep5 love out there.  Though some were using very pre-dep5 versions and the like
[16:29] <slangasek> "pre-dep5 versions" - yeah, I don't count those
[16:29] <asac> superm1: what bluetooth hardware do you have?
[16:29] <persia> The trick to using DEP5 (or a predecessor) is to be sure to specify the *precise revision* of the page that one complies with.  Most users should expect to be non-compliant for their next upload.
[16:29] <slangasek> no one's going to write a parser to handle 300 revisions of a wiki page, chosen at random by the uploaders :P
[16:29] <mterry> slangasek: Meh.  pre-dep5 versions is just an early dep5
[16:30] <superm1> asac, i've  got a variety of dell bluetooth chips, a keyboard mouse stereo headset and mobile phone
[16:32] <persia> slangasek, That something happens to be compliant with a given URL doesn't mean it's compliant with the *goals* of the effort :)
[16:32] <slangasek> persia: that sounds like you may be violently agreeing with me
[16:33] <persia> slangasek, I think the only point of disagreement is that I don't mind if someone happens to use something in that format, and will happily review it against the revision they specify, rather than asking "Why?".
[16:33] <slangasek> oh, I don't mind if someone happens to use something in that format
[16:34] <persia> Well then, yes, I am violently agreeing :)
[16:34] <slangasek> but I don't think it's worth doing validation, visual or otherwise, against arbitrary wiki revisions
[16:34] <ogra> .oO( all that violence here today )
[16:35] <persia> Oh.  I do it mostly to make sure that the person preparing the file is consistent with their claims, rather than just cargo-culting, but perhaps I tend to review packages in a different stage.
[16:35] <asac> doko: http://paste.ubuntu.com/192694/ ... does this still make sense in karmic? or rather vm commands?
[16:35] <persia> (and I don't want to reject just because the spec changed *again* since the last time they edited debian/copyright)
[16:35] <asac> (for 0.98)
[16:36] <slangasek> persia: right - not validating against arbitrary wiki revisions --> not validating at all :)
[16:36] <doko> asac: afaic classpath can be used with cacao or jamvm
[16:37] <persia> slangasek, Not even validating to ensure that it complies with current policy?
[16:37] <asac> ok thanks
[16:37] <slangasek> persia: policy compliance, sure
[16:37] <slangasek> that's separate
[16:37] <persia> Ah.  I understand.  Yes, I think that's the right choice from the archive-admin viewpoint.
[16:40] <slangasek> doko: I was wondering what to do with pycairo, btw; the Debian package has switched to python-support, is there an equivalent to DH_PYCENTRAL=include-links for python-support that we need to worry about?
[16:40] <nxvl> NCommander: can you please take a look at ug #385605
[16:41] <nxvl> Bug #385605
[16:41] <directhex> doko is about? woo!
[16:42] <doko> slangasek: no, python-support doesn't have this
[16:43] <slangasek> doko: is python-support's behavior consistent with what we're trying to achieve with include-links?
[16:43] <slangasek> doko: btw, did you file those bugs against python-support?  I don't have the bug numbers
[16:43] <mvo> slangasek: no include-links in pysupport
[16:44] <mvo> slangasek: but it seems like the links are now kept during upgrades
[16:44] <doko> slangasek: not yet, will try later.
[16:44] <mvo> (i.e. python-foo keeps working after --unpack but before --configure)
[16:44] <slangasek> doko: ok
[16:44] <slangasek> mvo: alrighty, then I can turn that into a sync
[16:45] <slangasek> mvo: thanks
[16:46] <asac> doko: sorry, but now gjdoc --version gives nullpointer exception :(  http://paste.ubuntu.com/192709/ ... do you know which .properties files its looking for there?
[16:48] <doko> asac: no. gjdoc should work (used in the gcj-4.4 build to build the libgcj docs)
[16:48] <asac> doko: yeah. but i get null pointer like above on --version
[16:49] <asac> classpath 0.98 seems to check version in configure ... and it fails because of this
[16:49] <slangasek> doko: should we transition away python2.4 support in python-stdlib-extensions, btw?  The structuring of that package makes it difficult to tell if the reverse-deps need python 2.4 support
[16:50] <yuriy> calc: ping
[16:50] <\sh> hmm...anyone with more initramfs knowledge then me, could explain what tool inside the initramfs would like to create e.g. /var/run/.ramfs ?
[16:50] <\sh> during bootup that is
[16:52] <doko> slangasek: yes, that's one of the things I want to do next week, together with 2.5
[16:52] <slangasek> oh, then I'll leave it for you :)
[16:58] <doko> does somebody know if today's live images are installable?
[17:00] <ogra> tomorrows should be :)
[17:00] <doko> hmm, no lpia images at all
[17:00] <pitti> doko: yesterday's was fine, anyway; haven't tried today's yet
[17:01] <ogra> and its unlikely you'll see any lpia ones
[17:01] <persia> Wasn't the intent to not have lpia images, intentionally?
[17:01] <ogra> the intent was intentionally, yes :)
[17:02]  * persia scores redundancy points, and seeks a acetylcholine refresh
[17:02] <ogra> *g*
[17:05] <calc> yuriy: hi
[17:05] <yuriy> calc: got my email from a week ago?
[17:06] <calc> yuriy: let me see, i had a huge amount of email to deal with so it might have been overlooked
[17:08] <calc> yuriy: ah ok, i'll look into what should be done, and let you know
[17:08] <calc> yuriy: we have a human project setup i might be able to expand it to include your icons as well
[17:10] <calc> yuriy: taking to privmsg
[17:15] <asac> robbiew: who will own foundations-karmic-eclipse-update ?
[17:15] <sabdfl> rickspencer3-afk, jono: dx call?
[17:15] <rickspencer3-afk> heh
[17:16] <rickspencer3-afk> I just dropped off a few minutes ago
[17:16]  * rickspencer3-afk calling
[17:16] <sabdfl> dbarth is moving house, but i'd like to hear from jono re couchdb and rickspencer3-afk re firefox
[17:17] <calc> yuriy: did you see my messages?
[17:17] <jono> sabdfl, oh, dialling in
[17:27] <ogra> Keybuk, oh, have you seen http://mjg59.livejournal.com/111453.html ? "... The Pre uses upstart as its init application. In contrast to mainstream Linux distributions that still mostly use upstart in sysvinit emulation mode, the Pre appears to be almost entirely based on native upstart events..."
[17:28]  * Keybuk knows ;)
[17:28] <ogra> way cool
[17:29] <slangasek> Keybuk: making a little scratch on the side doing upstart consulting, hmm? :)
[17:29] <Keybuk> I've known for a while in a don't-tell-anyone-but kind of way
[17:29] <Keybuk> slangasek: hah, I wish
[17:29] <Keybuk> then I'd be the one with the 73" HDTV
[17:29]  * slangasek grins
[17:29] <robbiew> lol
[17:29] <ogra> haha
[17:30] <Keybuk> Maemo uses it natively too
[17:30] <ogra> yeah
[17:30] <ogra> but only to fire off hildon
[17:31] <robbiew> asac: don't think we will do the eclipse update
[17:32] <asac> robbiew: well. we have to do something, because it blocks bug 352968
[17:32] <asac> robbiew: we cant keep xul 1.8 in the archive for another round. its just too far eol with too many security issues
[17:33] <robbiew> doko: ^^^
[17:33] <robbiew> doko: any suggestions?
[17:34] <asac> maybe we can rebuild eclipse without the feature that requires gecko?
[17:34] <seb128> if we have an outdated and buggy version and nobody works on it just drop it until somebody does the job to update it?
[17:34] <robbiew> seb128: hmm...you make a good point
[17:35] <asac> seb128: well, that was my idea for those rdepends left on xul 1.8, but archive admins didnt like the idea. see the bug
[17:35] <doko> robbiew: need to email some people about eclipse. did talk to somebody from the eclipse foundation last week
[17:35] <seb128> asac: try to convince slangasek ;-)
[17:35] <asac> my idea was: remove xul 1.8; respin all rdepends and if nobody steps up fixing the build failures, remove them from archive
[17:35] <robbiew> doko: okay
[17:35] <asac> seb128: he commented twice on the bug ;)
[17:35] <seb128> I agree we should make some efforts to try to fix those
[17:36] <seb128> but in the eclipse case if it's outdated for cycles and nobody want to work on it
[17:36] <seb128> it doesn't benefit our user anyway
[17:36] <seb128> users
[17:36] <asac> seb128: i am doing that and i planned to do that, i just think it would be easier to get community contributions when we make those build depends fail
[17:36] <seb128> and it can be uploaded again when somebody wants to do the update
[17:36] <seb128> talk to slangasek on IRC ;-)
[17:36] <robbiew> I recall someone sending an email requesting we update eclipse...
[17:36]  * robbiew looks
[17:36] <slangasek> asac, seb128: I was just backing up StevenK
[17:36] <seb128> might be either that to convince him there than by bug tracker
[17:37] <slangasek> pointing out that nothing had changed
[17:37] <slangasek> I don't have a strong feeling about it :)
[17:37] <asac> slangasek: sure. i might have not communicated the idea appropriately
[17:37] <seb128> let's talk to StevenK to see how strongly he believes about that not being right
[17:37] <seb128> I doubt anybody will object to do that early in the cycle
[17:42] <robbiew> asac: seb128: FWIW, we did receive an email some months ago from a journalist mentioning that he was hearing from some people that only having Eclipse 3.2 in Ubuntu is "driving them nuts"
[17:42] <robbiew> but apparently it's not nuts enough to get them to contribute :)
[17:42] <asac> robbiew: yeah. wonder if its better to not have it than to have such an outdated version.
[17:42] <robbiew> right
[17:42] <ogra> it should live in a PPA
[17:42] <robbiew> that might be the way to go
[17:42] <ogra> and find a maintainer team
[17:43] <robbiew> we should probably wait on doko's email
[17:44]  * doko has some email and other backlogs ... :-/
[17:45] <asac> doko: so seems the old gjdoc thing had a version.properties in a jar. the new thing doesnt have that so --version fails
[17:45] <asac> doko: maybe its because i have messed up alternatives for some java stuff? how can i reset all alternatives to something reasonable?
[17:45] <asac> (strace showed that it picked up rt.jar from the sun jdk)
[17:46] <cody-somerville> doh
[17:46] <cody-somerville> my wireless isn't working in karmic anymore
[17:46] <asac> cody-somerville: chipset?
[17:47] <cody-somerville> asac, BCM4322 802.11a/b/g/n
[17:47] <superm1> cody-somerville, if it was by 'wl', then see bug 381682, bug 381683, bug 381678, bug 381687 bug 381686 and bug 381684
[17:48] <superm1> some of them are taken care of, but the rest need to happen for jockey to be able to offer support now
[17:48] <doko> asac: did you set a java home?
[17:48] <cody-somerville> I'm pretty sure I
[17:48] <superm1> in the interim, you should be able to manually install bcmwl-kernel-source and then blacklist ssb and b43 for now
[17:48] <cody-somerville> Okay
[17:49] <cody-somerville> Thanks :)
[17:49] <superm1> np
[17:49] <asac> doko: my env doesnt have a JAVA_HOME
[17:50] <asac> doko: are those bits in gcc-defaults assembled manually?
[17:50] <doko> no
[17:51] <asac> doko: i cannot find anything in the sources that looks like it produces this gjdoc thing
[17:52] <cody-somerville> superm1, w00t
[17:52] <cody-somerville> superm1, worked like a charm
[17:53] <superm1> cody-somerville, great.  if you want to give a go at solving bug 381682 since rtg hasn't had a chance yet, can get it more OOTB experience for jockey to offer and what not...
[17:53] <asac> doko: so gcc-defaults it build depends on gcj-jdk ... but that package it produced by gcc-defaults itself. sounds like its a bootstrapping thing (manually?)
[17:54] <doko> asac: where is gjdoc --version used?
[17:54] <asac> doko: by classpath configure script
[17:55] <asac> (0.98)
[17:55] <asac> doko: i can patch that check out and assume all is good, but that doesnt sound right. gcj-jdk should ship the version.properties imo
[17:56] <asac> doko: previously  (in gjdoc) the version.properties was in /usr/share/java/gnu-classpath-tools-gjdoc.jar
[18:00] <asac> doko: build failure is: http://launchpadlibrarian.net/27733377/buildlog_ubuntu-karmic-i386.classpath_2%3A0.98-0ubuntu1~asac1_FAILEDTOBUILD.txt.gz
[18:01] <doko> asac: please attach a patch for gcj-4.4. gjdoc shouldn't use this file, but just using the method like other classpath tools
[18:04] <asac> doko: whats the source package?
[18:04] <doko> asac: gcj-4.4
[18:04] <asac> doko: there is nothing in there ;)
[18:05] <doko> run debian/rules patch, then you'll find the tools stuff in src/libjava/classpath/tools
[18:05] <asac> (outside of debian)
[18:05] <doko> gjdoc was recently added, so I assume the version handling stuff is still the old one
[18:07] <asac> doko: http://paste.ubuntu.com/192773/
[18:11] <doko> asac: dpkg-checkbuildeps?
[18:11] <asac> aye
[18:17] <asac> doko: i dont think i understand whats the _new_ way of doing it would be.
[18:18] <asac> the current getGjdocVersion does what i expect: open version.properties and get the version properties from there
[18:19] <doko> asac: look at how e.g. gjavah gets the version information
[18:19] <asac> k
[18:22] <stefanlsd> pitti: During UDS there was a discussion on https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-overview re the syncing of Debian security of to Ubuntu. It was mentioned you had a tool or an idea about this?
[18:22] <pitti> stefanlsd: first time I hear about it
[18:22] <stefanlsd> pitti: oh ok. The notes say - automated Debian-security fetch/try/build system (mom, ubuntuwire (rcbugs), pitti may have some)   -  Not sure who volunteered you :)
[18:23] <jdstrand> pitti: we talked about it
[18:23] <kees> stefanlsd: that was my idea, but there's no code.  :(
[18:24] <pitti> ah, I remember that being mentioned over lunch
[18:24] <jdstrand> it was kees' idea, but he wasn't there that day. we talked about using MoM or rcbugs and I thought you mentioned some scripts that could conceivably help
[18:24] <pitti> anyway, can we talk tomorrow? I need to leave for Taekwondo now
[18:24] <stefanlsd> yeah. np.
[18:24] <pitti> jdstrand: indeed, MoM would be ideal for this
[18:24] <pitti> jdstrand: or, alternatively, adapting http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[18:25] <pitti> anyway, bye everyone (sorry, gotta run)
[18:25] <jdstrand> pitti: I think that was the script you mentioned
[18:25] <jdstrand> bye pitti, have fun! :)
[18:25] <asac> doko: so this part? http://paste.ubuntu.com/192792/
[18:26] <asac> or are you asking to move the whole gjdoc thing to the new ClasspathParser?
[18:27] <doko> asac: yes, gjdoc maybe should use that as the default
[18:29]  * calc wishes old bugs were archived or something to that effect where people can't comment on them anymore
[19:02] <\sh> I wonder which piece of software sets $RAMRUN for /lib/init/mount-functions.sh  or /etc/init.d/mountkernfs.sh
[19:03] <\sh> aha...default rcS
[19:11] <puff> hi, I'm not sure this is the right place, but before I submit this brainstorm suggestion, I wanted to ask aroudn abou tit.
[19:11] <puff> I want to suggest that when a package is removed or renamed, that attempts to install (or even search for) the old package should get some sort of useful response, along the lines of "that package has been renamed to foo" or even "that package has been removed, see bug http://etcc"
[19:24] <robbiew> superm1: ping
[19:26] <superm1> robbiew, pong
[20:36] <mterry> evand1: Did you want any help with karmic installer stuff?  Like the ubiquity slideshow or something?
[20:43] <directhex> has there been a definitive answer to the question "was the audio from UDS recorded?"
[21:18] <slangasek> cody-somerville: do you know why xubuntu livefs builds are still failing due to libgoffice-gtk-0-6 being gone?  I'm not finding any references to that package
[21:19] <slangasek> cody-somerville: n/m, just found it in livecd-rootfs
[21:19] <evand1> mterry: slideshow is going to be mostly marketing, but help with the oem-config stuff, and other installer tasks that crop up (if that's what you're more interested in), would be fantastic.
[21:21] <mterry> evand1: Sure.  I don't want to cause more work in figuring out what to give me, but if you point me at a buglist, maybe I can claim some?  Or however you'd like to do it
[21:21] <evand1> mterry: sure, I'll follow up to Robbie's email tomorrow with more concrete ideas.
[21:22] <mterry> evand1: Cool
[21:37] <ZachD> hello
[21:38] <ZachD> im here to give u guys suggestions on ubuntu and improvements!
[21:38] <ZachD> w00t
[21:38] <cody-somerville> oh joy
[21:38] <ZachD> lol your welcome
[21:41] <directhex> doko, seems ironpython 2 works fine in sid's mono, so that blocker on updating is gone
[21:42] <doko> directhex: yes, it is supposed to work with 2.6
[21:43] <directhex> doko, rudimentary testing seems fine on 2.4 - testing the ipy 2.0.1 stable release, not the ipy 2.6 beta
[21:44] <ZachD> _._
[21:44] <ZachD> -.-
[21:44] <ZachD> whooops
[21:46] <doko> directhex: I'd rather go on with 2.6
[21:46] <directhex> doko, mono 2.6 or ipy 2.6?
[21:52] <sladen> Keybuk: ha.  So the first people using a full native upstart system are ... Palm
[21:53] <Keybuk> sladen: not true, others are doing so before them
[21:53] <Keybuk> from this we can discern two things
[21:53] <Keybuk> assumedly they're using 0.3 natively (based on /etc/event.d)
[21:54] <Keybuk> so the first thing is that they deserve a medal for getting any kind of useful native boot to that
[21:54] <Keybuk> and the second thing
[21:54] <Keybuk> I deserve a complimentary Palm Pre
[21:54] <Keybuk> ,g>
[22:00] <sladen> Keybuk: planning on moving to CDMA land to use it? ;-)
[22:01] <Keybuk> sladen: good point
[22:02] <puff> Anybody here know the guts of apt, dkg, etc?
[22:02] <puff> er, dpkg.
[22:03] <puff> I'm typing up a suggestion for brainstorm.ubuntu.org and I'd like to bounce it off somebody.
[22:04] <sladen> puff: you could try asking anyway.  There are people here who do know those parts of the stack /extremely/ well.  They might, or might not see it, so no promises
[22:05] <Nafallo> either that or it might not be as much of the guts that you fear :-)
[22:05] <puff> Two things, really.
[22:07] <puff> The real suggestion  is that when packages are removed or renamed, the package management system should clue you in, rather htan you being mystified, trying to remember if you spelled it right, googling like crazy and eventually finding the bug report where they discuss why kdiff3 was removed because we upgraded to kde4 and kdiff3 isn't kde4 compatible yet and you can compile it by hand, etc.
[22:07] <puff> Instead, when you enter "sudo apt-get install kdiff3" it should simply say "kdiff3 has been removed from the repositories, see ubuntu bug #11343141, http://etc."
[22:09] <puff> The second would be adding annotations to the installed packages;  apt or whatever would prompt the user for a reason, so you know who installed it and why, and whether it was installed as a result of a dependency or deliberately.
[22:09] <cjwatson> puff: it seems like the sort of thing that could fit better higher up the stack, perhaps in the "appcenter" idea that's being kicked around at the moment
[22:09] <cjwatson> (but I'm not really here)
[22:10] <puff> cjwatson: The first or the second?
[22:11] <Keybuk> both
[22:11] <puff> The second suggestion would particularly aid in situations where you have multiple folks managing multiple boxes, although heck, I've had instances where I was trying to remember to myself why I installed something.
[22:11] <cjwatson> the first; I'm not sure about the second, we do already have a record of whether something was installed as a result of a dependency or deliberately
[22:11] <cjwatson> although no more than that single bit of information
[22:11] <cjwatson> (see apt-mark(8) etc.)
[22:11] <puff> The first seems like it should be more at the repository level, since multiple tools use that.
[22:12] <cjwatson> the reason it belongs higher up is that it's the sort of thing that we might want to add richer information to after the fact
[22:12] <cjwatson> and it would be better for it not to be in the repository since that tends to be harder to change
[22:13] <puff> I guess I can see the reasoning there, but I think it's an 80/20 thing.  80% of the value is in simply knowing that the repository changed in a not-backward-compatible way.  Once you figure that out, it's much easier to hunt down *why* it changed via bug tracking, ubuntu forums, etc.
[22:14] <cjwatson> well, you know *that* due to Provides/Replaces/etc. if people are setting dependency relationships correctly
[22:14] <puff> But until you know that you're looking for something that isn't there anymore, it's kind of a crazy-making situation.
[22:14] <cjwatson> but the fact is that people don't :)
[22:14] <puff> It's bitten me at least twice, which is why I'm making the suggestion.
[22:14] <cjwatson> so it's probably better to have it separate, purely for practical maintenance reasons
[22:15] <cjwatson> right, and I'm applying ten years of experience with this kind of system to direct the suggestion to where it seems most likely to work ;-)
[22:15] <cjwatson> I agree that it would be useful
[22:15] <puff> Ah, I see... put the data somewhere that is less gate-keepered, so more folks canhelp keepit up to date.
[22:15] <cjwatson> but I don't honestly think it's likely to work well in the package metadata itself, even though in some theoretical sense that is the *correct* place
[22:15] <cjwatson> right, exactly
[22:16] <puff> I guess the simplest thing then would be to extend aptitude so it can query some sort of aptwiki-ish thing.
[22:16] <puff> Hm, or maybe just build an ubuntu aptwiki and a simple little aptitude-flavored CLI to it.
[22:16] <puff> With everything keyed by package names, etc.
[22:17] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/software-library is the design work happening on this at the moment
[22:17] <puff> Cool.  I will read and cogitate.
[22:18] <cjwatson> I don't know that your specific suggestion has been taken into account there
[22:18] <cjwatson> but it probably ought to be!
[22:18] <cjwatson> in some sense it comes under error-tolerant search but I think it's probably not quite the same
[22:19] <puff> I like adding GUI tools but I prefer it when they complement, not supersede, the underlying tools.
[22:19] <cjwatson> oh, I agree, I don't believe appcenter is intended to replace apt
[22:20] <cjwatson> mpt is the guy coordinating this, although he's not around right now
[22:20] <puff> I'll read up and try to catch up with him.
[22:21] <robbiew> puff: http://wiki.ubuntu.com/AppCenter
[22:21] <puff> Hm, this might dovetail with another idea I've had, which is to factor in platform-specific feedback.
[22:21] <cjwatson> it seems useful for that kind of thing to have a lower-level interface, of course; much of AppCenter is UI design and there are lots of places where the underlying tools are going to have to be extended a bit, or new tools written
[22:22] <cjwatson> e.g. the support lifetime for a package is going to have to be encoded somewhere
[22:22] <cjwatson> there's been talk of using debtags, which is potentially fairly flexible
[22:22] <cjwatson> still has the problem of the index files being frozen at release but I think debtags can use alternative data sources too
[22:23] <cjwatson> I suspect annotations belong lower down
[22:24] <cjwatson> since that doesn't involve any kind of interaction with us, it's purely local to the system
[22:24] <puff> Yeah, that I was thinking belonged in the dpkg records, somewhere.
[22:24] <puff> Or in a database "alongside" the installed packages stuff.
[22:26] <cjwatson> probably apt, I have this pesky desire to keep dpkg simple
[22:26] <cjwatson> and apt already has the auto/not-auto stuff anyway
[22:26] <cjwatson> (and apt would have to tell dpkg about it anyway so ...)
[22:28] <ebroder> Anybody with main upload bits willing to look at my fix for bug #362691? It's been sitting there for 3 weeks now, and includes a change to the version in jaunty-proposed
[22:29] <cjwatson> ebroder: probably better to ask outside a soft freeze
[22:29] <ebroder> Oh, right. Forgot about that
[22:29] <puff> cjwatson: Well, obviously I need to learn more about this whole topic, apt, dpkg, repos, what info's kept where.
[22:30] <puff> I've been bit several times by issues like this and things like problems with suspend/resume cropping up after dist-upgrading.  It seems really silly for something as cool as ubuntu to have problems like this (not silly for it to have problems, silly for people to be caught unaware by them)
[22:31] <puff> Especially since it's mainly a matter of communicating to the community, which ubuntu is pretty good at.
[22:31] <puff> Okay, thanks, I will go off and do my homework now.  Ciao.
[22:35] <cjwatson> puff: oh, don't take me as saying that there aren't bits of existing dependency relations that could be used - as I say I think there's some value in interpreting Conflicts/Replaces, Provides, etc.
[22:36] <sladen> cjwatson: is the actual example given (of removal of kdiff3) covered.  It was presumbly removed because there wasn't a replacement (although it should have said this in the list)
[22:38] <cjwatson> sladen: I don't know that that particular example is covered by package relationship fields, and I think it's pretty hard to cover there, which is one reason I explicitly wasn't suggesting shoehorning everything into package relationship fields
[22:43] <puff> kdiff3 was apparently removed for a while (and then re-added) due to some ubuntu general switchover to kde4, or something:  https://bugs.launchpad.net/ubuntu/+source/kdiff3/+bug/260326
[22:43] <puff> Previously I ran into something similar where some podcast downloading tool, I think ipodder, mysteriously disappeared (mainly because apple threatened a lawsuit over trademark infringement).
[22:45] <puff> And I've run into problems where I upgraded to a new ubuntu release and fundamental stuff like suspend/resume broke, and then when I went researching it, only *then* did I find out that it was a major known issue with that architecture .
[22:53] <cjwatson> ipodder was replaced by castpodder, but the project kind of petered out AFAICT (at least as far as getting packages was concerned) and I'm not sure if the replacement castpodder ever made it into the archive
[23:19] <lizthegrey> what's the proper procedure for recruiting backport testers for a package and deeming the backport sufficiently tested?  I'm trying to get sudo 1.7.0-1ubuntu1 from karmic backported to dapper and hardy - https://bugs.launchpad.net/hardy-backports/+bug/384100
[23:43] <lifeless> kees: how does one debug/fix apparmor profiles: cups is breaking when apparmor is on, on my laptop
[23:56] <mathiaz> lifeless: https://wiki.ubuntu.com/DebuggingApparmor
[23:56] <lifeless> thanks