[00:04] <seb128> james_w: do you know who is the guy who blogged about banshee and rhythmbox?
[00:05] <Laney> directhex
[00:05] <Laney> seb128: ^
[00:05] <seb128> Laney: thanks
[00:05] <pwnguin> are we angry or excited?
[00:05] <seb128> none of those
[00:06] <seb128> just wanting to say that those several megabytes are the user documentation
[00:06] <pwnguin> heh
[00:06] <seb128> rhythmbox has 6megs of those with translations version where banshee has none
[00:06] <pwnguin> d'oh!
[00:06] <seb128> so the argument is rather in defavor of banshee if you ask me
[00:06] <directhex> fiddlesticks
[00:08] <seb128> directhex: so the space is the user documentation translated in 11 locales
[00:09] <seb128> directhex: we can start dropping all user documentation to work CD space but I don't think that's a good move
[00:09] <seb128> directhex: I'm fine discussion rhythmbox against banshee but I'll not take that CD space argument as a valid one ;-)
[00:09] <seb128> discussion -> discussing
[00:09] <seb128> can't type tonight ;-)
[00:10] <directhex> seb128, fair enough
[00:10] <directhex> seb128, i'd still like a desktop team assessment ANYWAY, so they have a hit list of bugs
[00:10] <Picklesworth> I would be sad to see Magnatune and Jamendo support drop out of the default install, so hopefully those plugins can find their way into Banshee
[00:11] <seb128> we already discussed rhythmbox and banshee at UDS one year ago
[00:11] <directhex> seb128, we really need a better solution for all these localised PNGs than bundling the lot with every app though
[00:11] <directhex> one year ago, so... end of the hardy cycle?
[00:11] <seb128> we can rediscuss it, but it was not clear banshee was bringing lot that rhythmbox doesn't have and that users want
[00:11] <directhex> ah, 0.13
[00:12] <seb128> directhex: yeah, there is a spec about having user documentation translations in language packs, that's blocked on soyuz changes though
[00:12] <directhex> s' been rewritten since then, so as a minimum it should be considered a pretty different app. for better for worse
[00:12] <seb128> directhex: we did look at the new banshee codebase I think, the thing is that they are similar applications
[00:12] <seb128> there is some things banshee do better and that would be nice to get in rhythmbox
[00:13] <directhex> and vice versa
[00:13] <directhex> bien sur
[00:13] <seb128> but it was not clear that we should rather spend some ressources getting those in rhythmbox
[00:13] <seb128> ie ipod syncing
[00:13] <seb128> otherwise there is only the "banshee looks nicer"
[00:14] <seb128> anyway let's wait UDS to have a proper discussion, I will try banshee again for a week or something before that
[00:14] <seb128> but as mentioned before if things which are available now as magnatune are not in banshee I doubt we will switch if there is no compeling reasons to do so
[00:14] <pwnguin> does rhythmbox have a decent video-podcast tool?
[00:14] <directhex> RB doesn't do video afaik
[00:14] <seb128> no, rhythmbox is a music library software, not a video one
[00:15] <pwnguin> im kinda finding it unfortunate to check rss feeds in multiple places
[00:15] <seb128> there has been not a lot of user requests for video podcasting support until now
[00:16] <pwnguin> "until now"
[00:16] <seb128> I'm not sure what would be the best place for those, totem, rhythmbox
[00:16] <seb128> a podcast application
[00:16] <pwnguin> is there actually lots of user requests for it, or are we being generous on my behalf?
[00:16] <seb128> well in theory I guess than getting video podcast support in rhythmbox shouldn't be too hard
[00:16] <seb128> it has a video widget already for effects
[00:17] <seb128> and it's using gstreamer for rendering
[00:17] <seb128> pwnguin: I'm just considering it as a valid request and something nice to have, not sure how much requests we have for it, not many on lists and launchpad
[00:18] <pwnguin> i have no particular favorite between banshee or rhythmbox, but rhythmbox currently holds all my ratings
[00:18] <pwnguin> so im somewhat hostage to their xml
[00:18] <seb128> somebody wrote on one of those blog comments than banshee can do rhythmbox import now
[00:19] <seb128> dunno if it imports ratings too though
[00:20] <directhex> pwnguin, sqlite isn't it, not xml?
[00:20] <pwnguin> directhex: its very clearly xml
[00:20] <directhex> seb128, there's an open bug about ratings. afaik it doesn't handle 3-star ratings right now
[00:20] <directhex> pwnguin, really? that scales?
[00:21] <directhex> wheeee... xml in one app, embedded mysql in another. aren't media players fun
[00:21] <seb128> ah good, the gsoc project for rhythmbox syncing has been accepted
[00:21] <directhex> (amarok for the latter before someone asks)
[00:21] <pwnguin> directhex: are you arguing that sqllite scales?
[00:21] <seb128> so maybe ipod syncing will work in karmic in rhythmbox
[00:22] <pwnguin> ive got a few thousand items in rhythmbox
[00:22] <pwnguin> probably not the biggest you'll find
[00:24] <pwnguin> directhex: i think the main point of the day is: everyone benefits when you back up claims with proof :)
[00:25] <pwnguin> it might be handy to publish some measurements before UDS
[00:34] <directhex> pwnguin, i don't have enough dodgy music to test scalability well
[00:34] <directhex> pwnguin, i was under the impression that sql engines, even sqlite, were a bit more scalable than xml, especially for searching (unless the entire xml file is loaded to ram, i suppose)
[00:36] <directhex> hah! at this moment banshee picks a song for me whose main lyric is "all that i want is keeping it easy"
[00:40] <directhex> bah, car accident paperwork sucks
[00:47] <slangasek> I see an extra word in that sentence
[00:49] <directhex> the car accident sucked in march when it happened. now i'm focused on more immediate concerns
[00:49] <directhex> like how the courtesy car sucks. and the aforementioned paperwork
[00:49] <directhex> and i shouldn't be distracting a release manager. NAUGHTY directhex
[01:21] <directhex> 15 pages down
[01:21] <directhex> i hope google maps links count as sketches
[01:43] <rlaager> I'm trying to add support for the Verizon Wireless USB 760 modem. Making it actually work is trivial; it involves adding a new device ID in the right place. However, it has a useless (in Ubuntu) mass storage partition. How might I prevent that from mounting?
[01:43] <lifeless> rlaager: whats useless about it?
[01:43] <directhex> windows drivers?
[01:43] <rlaager> lifeless: It contains the Windows drivers.
[01:44] <lifeless> ok
[01:44] <TheMuso> rlaager: I believe there are a lot of these around, and they are tricky to get working right. Keybuk who is not online at the moment would be able to give you the best help I think.
[01:45] <rlaager> TheMuso: ok. For now I'll focus on getting the four-or-so-character patch for the device ID to the right people.
[02:54] <rlaager> It turns out I was wrong. The device doesn't show up as *both* types, but magically switches once the mass storage device is ejected. The fix here is the usb-modeswitch package, which is packaged for Debian but is not in Ubuntu.
[02:54] <rlaager> So, this will obviously have to be a Jaunty+1 thing. Pulling usb-modeswitch into main should be sufficient to make a pile of these devices work out of the box.
[02:55] <ScottK> rlaager: If it's in Debian, we should get it automatically for the next release.
[02:56] <rlaager> Yes, in universe. I'd suggest promoting it to main, but I'm not an Ubuntu developer.
[02:56] <dtchen> rlaager: https://wiki.ubuntu.com/MainInclusionReportTemplate
[02:58] <ScottK> No need to be a developer to suggest it.
[03:06] <rlaager> I'm going to send some patches upstream. That should help me answer some of those questions.
[03:24] <pace_t_zulu> has anyone noticed that when you change screen resolutions, panel objects and applets can get disorganized and out of order?
[03:35] <cody-somerville> Is there a metapackage for mobile-live?
[03:37] <pwnguin> cody-somerville: the flash UI?
[03:37] <cody-somerville> No
[03:37] <cody-somerville> the task
[03:38] <pwnguin> oh
[03:39] <pwnguin> im not sure what mobile-live is, but there's ubuntu-netbook-remix and ubuntu-mid
[03:40] <StevenK> cody-somerville: No, there isn't
[03:40] <StevenK> cody-somerville: But apt-get install mobile-live^ will pull it in
[03:40] <cody-somerville> indeed
[03:41] <cody-somerville> StevenK, Why is gimp in mobile-live?
[03:42] <cody-somerville> It doesn't seem like something you'd put in the live seed.
[03:42] <StevenK> It isn't ... ?
[03:43] <cody-somerville> StevenK, it sure is
[03:43] <StevenK> % grep -c gimp live
[03:43] <StevenK> 0
[03:43] <StevenK> But gimp is in UNR
[03:43]  * cody-somerville does an apt-get update to see if maybe his cache is out of date
[03:43] <StevenK> Actually, gimp doesn't appear in the seed lists at all
[03:44] <cody-somerville> do an apt-get show gimp
[03:44] <cody-somerville> Task: ubuntu-desktop, edubuntu-desktop, xubuntu-desktop, mobile-live
[03:44] <cody-somerville> It also appears your meta packages might be out of date, they seem to pull in extra packages that aren't by the tasks
[03:45] <StevenK> I doubt that
[03:47] <StevenK> language-support-en Depend gimp-help-en
[03:47] <StevenK> gimp-help-en      Depend gimp-helpbrowser
[03:47] <StevenK> gimp              Provides gimp-helpbrowser
[03:47] <StevenK> There's your answer
[03:48] <cody-somerville> joy
[03:51] <cody-somerville> StevenK, I'll know for sure in a little bit
[04:19] <lfaraone> Hobbsee: think there'd be any way that https://edge.launchpad.net/ubuntu/+source/python-parted could get into karmic, or has the code bitrotted? (I'm not up-to-date on that)
[04:21] <Hobbsee> lfaraone: no idea, sorry
[04:23] <lfaraone> Hobbsee: kk. Upstream corpo went AWOL, I'm not sure what the proper way (in the wider FOSS world, not just in the ubuntu sense) to adopt the project.
[04:23] <Hobbsee> lfaraone: i've no idea, sorry. Good luck!
[05:12] <pwnguin> lfaraone: the project's on LP, no? just start a new branch
[05:12] <pwnguin> err, i misread
[05:16] <pwnguin> lfaraone: first step is to rebuild it. if it went AWOL by 2006, it may not even build anymore.
[06:37] <pitti> Good morning
[06:42] <jdong> cody-somerville: are you involved in the mass updating of the Dell mini repo? I'm trying to find the right people to thank
[06:43] <cody-somerville> jdong, I am.
[06:43] <jdong> cody-somerville: thank you so much for your hard work
[06:43] <jdong> it's quite a pleasant surprise :)
[06:44] <cody-somerville> I'll be sure to pass that on.
[06:44] <jdong> thank you, please do :)
[06:44] <cody-somerville> What do your sources.list look like? (including any files in sources.list.d)
[06:45] <jdong> I think I pastebinned it here on our Friday discussion
[06:45] <jdong> the sources.list.d are mostly empty
[06:45] <cody-somerville> jdong, I think the latest update may have made changes.
[06:45] <jdong> ah
[06:45] <jdong> I will check that tomorrow morning
[06:45] <jdong> I don't have the system on handy access here
[06:45] <cody-somerville> Ah, okay.
[06:53] <wgrant> Erm.
[06:53] <wgrant> Packages mutating sources.list?
[06:59] <cody-somerville> wgrant, what do you think update-manager does every 6 months?
[06:59] <wgrant> cody-somerville: That's the release upgrader. I expect it to do that.
[06:59] <wgrant> I don't expect routine upgrades to do that.
[06:59] <cody-somerville> Then I guess its a good thing you don't have a dell mini
[07:00] <ScottK>  ... running something other than Ubuntu.
[07:01]  * cody-somerville raises an eyebrow.
[07:01] <ScottK> UNR hardy isn't an Ubuntu repo.  It's a Canonical remix of Ubuntu.
[07:02] <cody-somerville> Right
[07:05] <cody-somerville> Thank god thats changed for Jaunty
[07:06] <ScottK> Although continuing to describe it as a remix seems odd to me given how remix is used in the Trademark policy.
[07:07] <dholbach> good morning
[07:07] <cody-somerville> ScottK, Its a remix because it contains bad things I think
[07:08] <ScottK> The way remix is used in the Trademark policy is as a term for what are essentially minor derivatives.
[07:08] <ScottK> I don't know enough about what's in it for Jaunty to have a stron opinion.  It just seemed odd.
[07:08] <ScottK> since it's in the repos.
[07:09] <ScottK> Anyway, I said I was going to bed a long time ago ....
[07:09] <ScottK> Good night.
[07:09] <wgrant> Night ScottK.
[07:21] <Hobbsee> wgrant: on that mail, i'm going to go with it being something automatix, or automatix-like, fwiw.
[07:22] <wgrant> Hobbsee: We'll see.
[07:22] <ajmitch> Hobbsee: with the sid in sources.list?
[07:22] <Hobbsee> ajmitch: yeah, that's the one
[07:23] <ajmitch> I wonder what the installer thing for cadsoft does
[07:23] <liw> any Kubuntu people around? does http://imagebin.org/46426 look normal for the OEM installer's user-setup dialog? I mean, the huge menu at the left
[07:23] <ajmitch> unless it's something run in wine, it wouldn't surprise me if that were the cause
[09:01] <pitti> mvo: bug 363465 is a jaunty or intrepid SRU? can you please add appropriate stable tasks?
[09:01] <mvo> pitti: sorry, doing that now (its jaunty)
[09:02]  * mvo checks the others as well
[09:02] <pitti> mvo: ah, I see the u-m jaunty-proposed upload, thanks
[09:02] <pitti> mvo: I'll make sure that this goes in ASAP after release
[09:03] <mvo> pitti: thanks a lot. I attached logs for all the upgrade ones to shw that they fix the problems in the report
[09:05] <pitti> mvo: please upload nvidia-common to the queue as well, so that everything is ready on Friday
[09:05]  * pitti hugs mvo
[09:06] <mvo> pitti: nvidia-common made into -final :) - but let me check if the bugreport got closed already
[09:06] <pitti> mvo: ah, nice; no, it was still open
[09:06] <pitti> mvo: wrt. bug 364583, nice! a friend of mine recently had to upgrade an old feisty of a friend of his', and it was a nightmare
[09:07] <pitti> apparently he didn't get this "not supported anymore" thing
[09:07] <mvo> pitti: :(
[09:07] <pitti> mvo: for those cases, do you think it would be feasible to have update-manager fall back to old-releases.u.c. for such upgrades?
[09:07] <pitti> I asked him to do that manually in sources.list, but it still failed with u-m, so I had him do dist-upgrade
[09:08] <mvo> pitti: u-m does not well for old-release.u.c - one problem is that we can no longer do srus for old-release (or can we?)
[09:08] <pitti> mvo: no, but why would we?
[09:09] <pitti> mvo: I thought for the feisty->gutsy upgrade it would download u-m from gutsy?
[09:09] <mvo> pitti: for the "no longer supported" message it would be nice
[09:43] <pitti> #u-release has been quiet all day
[09:43] <pitti> oops, ECHAN, sorry
[09:48] <davmor2> pitti: here's why http://iso.qa.ubuntu.com/qatracker/build/all/all
[09:49] <pitti> davmor2: I bet 3/4 of those are from you! :-)
[09:49]  * pitti hugs davmor2
[09:50] <davmor2> :) No only about 3/5 this time lots of other people got involved :)
[09:50] <cjwatson> rlaager: the trend upstream is to change the kernel to detect the situation and automatically deal with switching the devices around
[09:50] <cjwatson> rlaager: see the 'option' driver, for instance
[09:59] <stefanlsd> Does anyone use a macbook for their ubuntu dev stuff? im looking at one and was wondering how / if it works out...?
[10:13] <mdz> pitti: any guess why apport-collect didn't seem to run the hook on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/364830 ?
[10:14] <james_w> you currently have to specify the binary package name when using apport-collect for the kernel
[10:16] <james_w> the instructions should say "apport-collect -p linux-image-$(uname -r) <bug>" I guess
[10:26] <mdz> james_w: hmm, I thought pitti fixed that
[10:28] <pitti> mdz: I special-cased it in ubuntu-bug, but not in apport-collect yet
[10:29] <pitti> mdz: this is a much more general problem than just "linux", thus I wanted to ponder it a bit more
[10:29] <pitti> running the source_* hooks is no problem
[10:29] <pitti> but you won't get any binary package data
[10:29] <pitti> well, I guess it's not topmost interesting either
[10:31] <mdz> pitti: I think the same special case as in ubuntu-bug is appropriate in apport-collect
[10:31] <pitti> bug 350131, FYI
[10:31] <mdz> odd that ogasawara documented it without trying it though ;-)
[10:31] <pitti> mdz: *nod*
[10:41] <Riddell> liw: that's intended
[11:36] <PecisDarbs> which I should poke about a bug in Ubuntu Security Notifications RSS feed?
[11:37] <Laney> jdstrand and kees: ^
[11:39] <PecisDarbs> jdstrand: Ubuntu Security Notifications RSS feed is nice feature, but it throws everything together without line breaks, which results in ugly mess. Propably one line fix :)
[11:47] <Le-Chuck_ITA> Hi there. I see an obvious bug that seems to have not been noticed before. Before reporting I'd like to hear from you. When updating the system, dpkg may hang waiting for input from the user, e.g. if a configuration file was "manually" edited (possibly by some system program). In that case, since the terminal window is not expanded, the user can't notice the situation. She just sees a blocked progress bar. As I know my mother, she would
[11:58] <cjwatson> Le-Chuck_ITA: the terminal window ought to be expanded if we notice an attempted read on the terminal, which indicates something like dpkg waiting for input. mvo put a lot of work into this in the past and it used to work. If it doesn't work now, then that bug should be filed on https://bugs.launchpad.net/ubuntu/+source/synaptic/+filebug
[11:58] <cjwatson> (or actually, 'ubuntu-bug synaptic')
[11:58] <cjwatson> Le-Chuck_ITA: (you don't need to include such extensive justification, by the way; and note that very long lines are cut off on IRC anyway. It's clearly a bug)
[11:58] <Le-Chuck_ITA> cjwatson: I am trying to reproduce but er... don't know how to downgrade a package (say readahead) to the previous version
[11:59] <Le-Chuck_ITA> I tried apt-get install readahead=previous_version but it won't find it
[11:59] <cjwatson> download the .deb file and use dpkg -i
[11:59] <Le-Chuck_ITA> cjwatson: ok but where's the deb file? Still on the servers?
[12:00] <cjwatson> https://launchpad.net/ubuntu/+source/readahead and follow links
[12:00] <Le-Chuck_ITA> aaaah thanks cjwatson, I recalled that page but tought it was on the binary package page
[12:00] <mvo> Le-Chuck_ITA: conf file prompt will be automatically detected without a terminal. it might have been a ucf prompt (but that should use gtk debconf) - if you put the /var/log/dist-upgrade/apt-term.log and main.log somewhere I can have a look
[12:01] <Le-Chuck_ITA> mvo: I just retry for now.
[12:01] <wgrant> Le-Chuck_ITA, cjwatson: The source seems to be readahead-list these days.
[12:01] <Le-Chuck_ITA> wgrant: in fact I was wondering...
[12:03] <Le-Chuck_ITA> in https://edge.launchpad.net/ubuntu/+source/readahead-list/1:0.20050517.0220-1ubuntu4 I can't find the i386 binary for jaunty...
[12:06] <wgrant> Le-Chuck_ITA: It was copied from intrepid.
[12:07] <Le-Chuck_ITA> ok installed the intrepid binary and re-upgraded
[12:07] <Le-Chuck_ITA> Now I have a popup
[12:07] <Le-Chuck_ITA> 15 minutes ago I had to open the terminal manually, thing that I can't do now because the popup is blocking focus
[12:07] <Le-Chuck_ITA> for the terminal window
[12:07] <Le-Chuck_ITA> so I can't have let the popup unnoticed
[12:08] <Le-Chuck_ITA> ok they are waiting me for lunch, mvo: later I will give you the files but... hmmm... me dumb, are those overwritten now or are they usually appended?
[12:08] <mvo> Le-Chuck_ITA: there is a backup copy made into a subdir of /v/l/dist-upgrade/
[12:09] <Le-Chuck_ITA> mvo: ok I have to hurry up now, see you later
[12:09] <mvo> see you
[12:19] <directhex> hm.
[12:20] <directhex> is there anything special about gtk on ubuntu that could cause "GdkWindow *gdk = parent->GetGdkWindow ();" to throw "Cannot access memory at address 0x7ffeffffffc8"?
[12:26] <liw> directhex, afaik on ubuntu only the usual reasons apply (i.e., it's a pointer problem in the code; solution: rewrite in Python ;-)
[12:27] <soren> directhex: It also depends quite a bit on what parent is.
[12:29] <directhex> soren, "naughty"
[12:30] <soren> directhex: That's why then :)
[13:04] <Le-Chuck_ITA> mvo: Hi, what files would you like to see and where should I put them?
[13:04] <Le-Chuck_ITA> mvo: however we might also conclude that it won't happen anymore.
[13:08] <mvo> Le-Chuck_ITA: please file a bug against update-manager, attach the full logs (all of /var/log/dist-upgrade) and describe the problem again - I have a look then. thanks!
[13:09] <Le-Chuck_ITA> mvo: thanks
[13:09] <lfaraone> pwnguin: just the changelog afaict, it's not a lp project.
[13:09] <Le-Chuck_ITA> mvoLe-Chuck_ITA: there is a backup copy made into a subdir of /v/l/dist-upgrade/
[13:09] <Le-Chuck_ITA> mvo I don't have a backup copy there...
[13:10] <Le-Chuck_ITA> mvo forget it
[13:10] <Le-Chuck_ITA> I used tab completion and was trying to find /var/lib/dist-upgrade :)
[13:15] <lfaraone> pitti: re bug 363759, "ubuntu-bug echo" (the test case I specified) still doesn't work.
[13:16] <lfaraone> pitti: am I missing something? (I'm on 1.0-0ubuntu5)
[13:17] <Le-Chuck_ITA> mvo: nope: in /var/log/dist-upgrade/apt-term.log I can only see the log of 23 march
[13:17] <Le-Chuck_ITA> mvo: it's the day I installed ubuntu on this machine
[13:18] <mvo> Le-Chuck_ITA: was this a fresh install of jaunty with subsequent updates or a intrepid machine that got upgraded via update-manager to jaunty?
[13:18] <liw> hmm, my desktop machine doesn't want to halt
[13:19] <Le-Chuck_ITA> mvo: a fresh install of jaunty
[13:19] <mvo> Le-Chuck_ITA: aha, in this case the log to look at is /var/log/apt/term.log
[13:20] <pitti> lfaraone: /bin/echo will work
[13:20] <Le-Chuck_ITA> mvo: ok but now I can't see the log of the first time the terminal didn't open
[13:20] <pitti> lfaraone: a single word is considered a package name
[13:20] <Le-Chuck_ITA> mvo: only the second time, when I correctly got a popup
[13:21] <Le-Chuck_ITA> the two things are clearly related :)
[13:21] <Le-Chuck_ITA> mvo: the system didn't notice the terminal
[13:21] <mvo> Le-Chuck_ITA: what package was it that caused it?
[13:22] <Le-Chuck_ITA> mvo: if you're busy I will open a bug as you told me. Here are the two log lines
[13:22] <Le-Chuck_ITA> Mi preparo a sostituire readahead 1:0.20050517.0220-1ubuntu4 (con .../readahead_1%3a0.20050517.0220-1ubuntu5_i386.deb) ...
[13:22] <Le-Chuck_ITA> Spacchetto il sostituto di readahead ...
[13:22] <Le-Chuck_ITA> (sorry it's in italian)=
[13:22] <Le-Chuck_ITA> this is the first time
[13:22] <Le-Chuck_ITA> the second time:
[13:22] <Le-Chuck_ITA> Configuro readahead (1:0.20050517.0220-1ubuntu5) ...
[13:22] <Le-Chuck_ITA> File di configurazione `/etc/readahead/boot'
[13:22] <Le-Chuck_ITA>  ==> Modificato (da te o da uno script) dopo l'installazione.
[13:22] <Le-Chuck_ITA> [... and the usual prompt follows ...]
[13:22] <Le-Chuck_ITA> but the first time I found the question in the "folded" terminal
[13:24] <lfaraone> pitti: I understand, I was proposing for jaunty+1 that we look up the full path-to-binary with "whereis" if it doesn't exist as a package.
[13:25] <pitti> lfaraone: ah, I see; can you please reopen the bug then?
[13:26] <lfaraone> pitti: I'll set it to "triaged" if that's OK then.
[13:26] <mvo> Le-Chuck_ITA: I try to reproduce now
[13:28] <pitti> lfaraone: right, thanks
[13:29] <mvo> Le-Chuck_ITA: hm, I get a dialog "replace configuration file" when I test this (as I was expecting :) - you did not get this dialog?
[13:29]  * mvo tries again with different settings
[13:31] <Le-Chuck_ITA> mvo: first time, no, second time yes
[13:31] <Le-Chuck_ITA> mvo: first time, I found the progress bar stuck, and I unfolded the terminal to see what was going on, and I find it waiting for me
[13:31] <Le-Chuck_ITA> in fact you can see from the logs that the system acted like no question had been asked
[13:50] <mvo> Le-Chuck_ITA: interessting, that is a bit suprising - could you mail me the log please ( mvo at ubuntu.com) ?
[13:52] <Le-Chuck_ITA> mvo done
[13:55] <mvo> thanks Le-Chuck_ITA
[13:56] <Le-Chuck_ITA> mvo: thank you for taking a look at them
[14:00] <mvo> Le-Chuck_ITA: looking at the log it seems like something releated to acroread caused this maybe? did you get it from mediaubuntu (I ask to see if I can get more info about it)
[14:00] <Le-Chuck_ITA> let me check. I think it can't upgrade because it overwrites a file from an ubuntu package
[14:01] <lfaraone> pitti: if I wanted to implement that functionality, I should just write a patch for the next version of apport rather than adding that functionality in the debian package.
[14:01] <lfaraone> pitti: right
[14:01] <lfaraone> *?
[14:01] <Le-Chuck_ITA> mvo: in fact, the second time I disabled acroread!
[14:01] <Le-Chuck_ITA> mvo: will now check with acroread enabled, again
[14:02] <Le-Chuck_ITA> mvo the reason why acroread can't be installed is because it overwrites a file in acroread-debian-files, which is part of medibuntu too
[14:06] <Le-Chuck_ITA> mvo: bingo. I have the hanged progress bar in front of me
[14:10] <mvo> Le-Chuck_ITA: execllent, if you expand that now, that is the last that is written there?
[14:13] <Le-Chuck_ITA> mvo: in the dialog window, I see the italian for "executing post-install command for man-db". In the terminal window, I see error messages for acroread, that possibly defeat recognition of an input request, and then the usual question wether to replace conffiles. Let me pastebin it
[14:14] <Le-Chuck_ITA> woops, did you know what ctrl+c does there? :)
[14:14] <Le-Chuck_ITA> mvo: http://paste.ubuntu.com/155913/
[14:15] <Ampelbein> Le-Chuck_ITA, mvo: the acroread-issue is known: bug 359518
[14:15] <mvo> Ampelbein: thanks, I'm trying to figure out why this confuses synaptic to not show the conffile prompt
[14:16]  * Le-Chuck_ITA admires the ability of mvo to summarise a problem
[14:18]  * mvo scratches his head, makes more tea and collects the required deb packages to reproduce the problem
[14:19] <mvo> Le-Chuck_ITA: will you be around for a bit longer? there are some debug switch to try, but first I try to reproduce it here
[14:20] <Le-Chuck_ITA> mvo: yes I'll be around
[14:20] <Le-Chuck_ITA> otherwise I am vincenzo_ml on launchpad, and vincenzo_ml at yahoo dot it in the rest of the world :)
[14:35] <LaserJock> slangasek: is arranging for Edubuntu mirrors something I have to do?
[14:37] <slangasek> LaserJock: well, it's not required, certainly; but it's not likely to happen otherwise, if that's what you mean
[14:37] <LaserJock> slangasek: right
[14:38] <LaserJock> slangasek: when was this decided? It's a bit of a shock tbh
[14:38] <LaserJock> slangasek: I can understand needing the space though
[14:39] <slangasek> LaserJock: when it was determined that UNR needed to fit on there because it's being heavily promoted, and it was seen that this was going to increase our mirror footprint beyond the target size - which we noticed shortly before RC
[14:40] <LaserJock> slangasek: k
[14:41] <LaserJock> slangasek: do you happen to know if it's still supported by Canonical then?
[14:42] <slangasek> LaserJock: I don't have an answer to that, sorry.  The placement on cdimage vs. releases is orthogonal to support
[14:42] <LaserJock> slangasek: ok, thanks
[14:42] <LaserJock> slangasek: do you have a deadline for the release announcement?
[14:42] <LaserJock> slangasek: considering the number of changes we made this release we really should have one
[14:43] <slangasek> LaserJock: tomorrow at 11:00 UTC
[14:44] <LaserJock> slangasek: ok
[14:44] <LaserJock> slangasek: thanks for the info, we'll get something put together
[14:45] <slangasek> great, thanks :)
[14:45] <cjwatson> slangasek: sorry for the delay - looking at your release notes changes now
[14:45] <slangasek> cjwatson: okie
[14:46] <savvas> release notes are changed?
[14:46] <savvas> hrm, back to translating :p
[14:46] <cjwatson> expect frequent changes, I'm afraid
[14:46] <cjwatson> hopefully not major, but ...
[14:46] <savvas> sure, no problem :)
[14:46] <savvas> do you happen to have the wiki link?
[14:47] <slangasek> https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes
[14:47] <savvas> thank you!
[14:47] <slangasek> you may want to subscribe to the page, if you're a translator :)
[14:48] <savvas> that's a good idea - I didn't do much of the work in /el, I'm just the guy that notifies the person who volunteered to translate it :)
[14:53] <cjwatson> slangasek: ok, largely looks fine, I made some style changes
[14:54] <slangasek> cjwatson: ok, thanks
[14:54] <slangasek> cjwatson: since when does 'apt-get purge' work, though?
[14:55] <slangasek> (nice that it does - it's just news to me)
[14:57] <LaserJock> slangasek: would it be possible to get the Edubuntu .iso on the torrent tracker?
[14:57] <mvo> Le-Chuck_ITA: hm, no luck here to reproduce, could you please run "sudo apt-get dist-upgrade -o Debug::pkgDPkgProgress=true" and mail me the output please?
[14:58] <mvo> Le-Chuck_ITA: and in what repo is acroread9 ?
[14:58] <cjwatson> slangasek: apt 0.7.7, Oct 2007
[14:58] <slangasek> cjwatson: er, wow
[14:58] <slangasek> where has the time gone
[14:58] <cjwatson> well, that's when it was fixed to actually work; I think it was added before that
[14:58] <cjwatson> I only noticed its existence recently
[14:58] <slangasek> LaserJock: do you mean in advance of the release?
[14:59] <ogra> slangasek, he indeed meand for the release
[14:59] <ogra> *meant
[14:59] <slangasek> all of the release ISOs are supposed to end up on the torrent tracker, TTBOMK
[14:59] <LaserJock> slangasek: ok
[14:59] <Le-Chuck_ITA> mvo: acroread9 is in medibuntu
[15:00] <Le-Chuck_ITA> mvo: did you manage to have a package that overwrites somebody's else file?
[15:00] <Le-Chuck_ITA> I see it must fail *before* readahead
[15:00] <slangasek> LaserJock, ogra: confirmed, http://cdimage.ubuntu.com/edubuntu/releases/jaunty/rc/edubuntu-9.04-rc-addon-amd64.iso.torrent works fine
[15:01] <ogra> good
[15:02] <Le-Chuck_ITA> mvo: in console, the order of unpacking is reversed
[15:04] <mvo> Le-Chuck_ITA: I don't see it here http://packages.medibuntu.org/pool/non-free/a/acroread/
[15:05] <Le-Chuck_ITA> mvo: me dumb
[15:05] <Le-Chuck_ITA> http://archive.canonical.com jaunty/partner acroread 9.1.0-7jaunty1
[15:05] <Le-Chuck_ITA> that's the output from apt
[15:07] <mvo> Le-Chuck_ITA: execllent, thanks
[15:10] <LaserJock> slangasek: should we make both a release announcement (single paragraph or so) and release notes?
[15:10] <LaserJock> RichEd was the one that's been doing this stuff for the last couple releases, I'm not positive what all needs to be done
[15:10] <slangasek> LaserJock: the release announcement is ideally something stand-alone that I can link to from <https://wiki.ubuntu.com/JauntyJackalope/ReleaseAnnouncement>, à la the other flavors
[15:11] <slangasek> (the release announcement for final is always heavily trimmed)
[15:13] <mvo> Le-Chuck_ITA: rock! reproducable
[15:13]  * Le-Chuck_ITA parties 
[15:14] <Le-Chuck_ITA> mvo: shall I open a bug report?
[15:19] <Le-Chuck_ITA> tjaalton: if possible the fact that Xorg crashes when wacom entries are there should be in the release notes... I bet that most people will copy their xorg.conf and go crazy.
[15:20] <Le-Chuck_ITA> tjaalton: where "most" people is referred to the few that use a tablet with ubuntu :)
[15:20] <tjaalton> Le-Chuck_ITA: on the way
[15:20] <tjaalton> later this evening
[15:24] <Le-Chuck_ITA> tjaalton: thanks
[15:32] <mvo> Le-Chuck_ITA: please do, I'm debugging it currently
[15:33] <slangasek> pitti: 321404> I don't think that's the right answer.  If cdbs is going to symlink changelogs around, then cdbs should enforce the package deps too
[15:33] <pitti> well, we can't do the latter
[15:34] <pitti> so all we could do is to not symlink at all
[15:34] <pitti> and I still refuse to accept that we should sacrice several MBs on the CDs to support a small (and unsupported) corner case which is only interesting to developers anyway
[15:35] <pitti> (corner case being partial upgrades)
[15:36] <slangasek> why can't you do the latter?
[15:36] <pitti> slangasek: cdbs automatically add versions do dependencies?
[15:36] <slangasek> just populate ${misc:Depends}?
[15:37] <pitti> then (1) we'd destroy the very corner case that this bug is all about in the first place, and second
[15:37] <pitti> (2) people would rightfully grill me for doing dependency changes behind their backs
[15:37] <Keybuk> pitti: is the retracer working today?
[15:37] <slangasek> heh
[15:37] <slangasek> pitti: you can direct those people to me then :)
[15:37] <seb128> Keybuk: it keeps crashing on launchpadlib bugs apparently
[15:38] <pitti> Keybuk: it had several failures, seems that something in Launchpad changed again to make launchpadlib fall over; but it should catch up
[15:38] <Keybuk> pitti: any way you can prod one through a bit faster
[15:38] <pitti> slangasek: do you really think that this is such an importnat issue?
[15:38] <Keybuk> we're tying to debug why I don't receive crash mails
[15:38] <pitti> Keybuk: sure, which #?
[15:38] <seb128> Keybuk: because you don't get emails about private bugs and crash are private
[15:38] <slangasek> pitti: I think having /usr/share/doc/$pkg/changelog.Debian.gz actually *be the changelog for the package that's installed* is an important invariant, yes
[15:39] <Keybuk> pitti: #365126
[15:39] <Keybuk> seb128: mdz claims you do ;)
[15:39] <Keybuk> you specifically, in fact
[15:39] <seb128> no you don't
[15:39] <pitti> slangasek: well, as I said, the only other option that I see is to not symlink changelog.Debian.gz then
[15:39] <seb128> that's something which is annoying me for years
[15:39] <mdz> seb128: I assumed since you reply to them
[15:39] <seb128> I'm polling on apport-crash tagged but by the launchpad UI every week
[15:39] <slangasek> pitti: I think you're far too quick to rule out having cdbs enforce the dep
[15:39] <seb128> mdz: ^
[15:39] <seb128> but -> bugs
[15:40] <slangasek> if cdbs can mangle the package contents in this manner, there's no reason it can't also mangle the package metadata to match
[15:40] <pitti> slangasek: technically it can
[15:40] <pitti> slangasek: but what would you gain?
[15:40] <seb128> mdz: you can see those in the web interface but you don't get emails, we are looking manually to this list regularly
[15:40] <pitti> you'd loose the ability to do partial upgrades (for the binaries of a source package)
[15:40] <sistpoty|work> slangasek: btw.: duplicate of bug 194574 :P
[15:41] <slangasek> pitti: not being confused all to hell by packages that are behaving in a way that's inconsistent with what the changelog says
[15:41] <seb128> mdz: you just get an email when somebody is marking the bug public, which bug triagers try to do
[15:41] <seb128> Keybuk: ^
[15:41] <pitti> Keybuk: it's already retraced
[15:42] <pitti> Keybuk: (2 minutes ago)
[15:42] <slangasek> pitti: having fewer opportunities for partial upgrades is not something I'm bothered by, when those partial upgrades cause (minor, but still annoying) breakage
[15:43] <slangasek> the rule isn't "support partial upgrades with as much granularity as possible", it's "ensure that any time a partial upgrade succeeds, the packages are actually in a proper state"
[15:45] <pitti> slangasek: it will cause a higher number of held-back packages for version skew between arch all/any, but that's not too bad, I think
[15:45] <soren> What if we changed cdbs the other way around and only let it do the symlink thing if the dependency was appropriately versioned?
[15:45] <slangasek> soren: that would cost us CD space, as pitti pointed out
[15:45] <pitti> soren: that woudl basically be equal to "never"
[15:45] <soren> pitti: Ah.
[15:46] <pitti> applications link to libraries by shlibs versions, not package versions
[15:46] <soren> slangasek: I have no idea about the scale of that?
[15:46] <slangasek> apparently, "large enough" :)
[15:46] <soren> pitti: Er.. Huh?
[15:46] <soren> pitti: Oh, I get it.
[15:46] <pitti> soren: few packages do Depends: libfoo (= ${source:version}
[15:47] <pitti> which is what cdbs would need to add to enforce changelog consistency
[15:47] <chrisccoulson> hey slangasek, i just noticed you added a u-r-n task to bug 361205
[15:47] <chrisccoulson> do you think bug 359207 should be mentioned in the release notes too?
[15:47] <pitti> chrisccoulson: just discussing in #u-release
[15:47] <slangasek> chrisccoulson: yes; we were just discussing this on #ubuntu-release
[15:47] <pitti> chrisccoulson: we should document the effect and workaround
[15:47] <pitti> chrisccoulson: do you think it's still on track for an early SRU?
[15:48] <pitti> it's only an issue for upgrades
[15:48] <soren> pitti: Is the /usr/share/doc/$pkg symlinked or are the individual files symlinked?
[15:48] <chrisccoulson> slangasek + pitti - i just sent a patch upstream to fix the removable media issue, and it has now been committed to git
[15:48] <pitti> so if we can SRU it early, it won't hit so many people
[15:48] <slangasek> 359207> hmm, that seems less in need of release-noting, IMHO
[15:48] <chrisccoulson> so we can do a SRU quite early for that one
[15:48] <pitti> soren: individual files, since dpkg's handling of symlinks vs. directories is a bit special and would wreak havoc too often
[15:49] <rlaager> cjwatson: I see that the option driver supports the device I have, but I'm not seeing where it does the switching.
[15:49] <soren> pitti: Ok.
[15:49] <Le-Chuck_ITA> mvo: bug #365129
[15:49]  * pitti tries to understand Keybuk's conclusion in the test bug
[15:55] <kees> PecisDarbs: it's, unfortunately, not a one line fix.  :(  We will be addressing it after Jaunty releases, though.  It's been a long-standing blemish.  :)
[15:59] <pitti> chrisccoulson: mind to review https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Tracker%20index%20corruption ?
[15:59] <magcius> Would some people mind helping me with the notify-osd codebase?
[16:00] <joaopinto> magcius, is that about the notify-osd-better project ?
[16:00] <magcius> joaopinto, yes :(
[16:00] <chrisccoulson> pitti - that's mostly ok, but the more "official" workaround would be to run "tracker-processes -r". that will kill all tracker related processes, and delete all info in ~/.cache/tracker and ~/.local/share/tracker too, all in one go
[16:01] <pitti> chrisccoulson: even better, thanks
[16:01] <chrisccoulson> no problem
[16:01] <pitti> that doesn't even need a session restart, right?
[16:01] <magcius> joaopinto, I have some stuff working but I'm having difficulty understanding "stack.c"
[16:02] <pitti> chrisccoulson: wiki updated
[16:02] <joaopinto> magcius, I would like to see a description on the project, like, why is it "better" and why have you decided to fork the notify-osd instead of improving it
[16:03] <chrisccoulson> pitti - thanks
[16:03] <magcius> joaopinto, design differences.
[16:04] <magcius> Like the image scaling and multiple notifications at one time.
[16:04] <rtg> superm1: are you aware of any Ricoh SD host driver quirks? I've a SanDisk 16GB SDHC that works in a XPS1330, but won't in an Inspiron 1420. AFAICT the SD/MMC parts are identical.
[16:05] <magcius> joaopinto, if they ever change these design decisions, I'll be glad to let them merge it back into the original codebase.
[16:07] <joaopinto> magcius, using "better" in a project name to describe a different design decision is not very friendly
[16:07] <magcius> joaopinto, it's meant to address the things that the community doesn't like about notify-osd.
[16:07] <joaopinto> your fork may be better according to your view/goals, while the current main project is better according to it's own goals/perspective
[16:08] <magcius> Well, what should I rename it?
[16:09] <joaopinto> something that matches with your changes ? or just some codename ?
[16:11] <LaserJock> notify-osd-meilleur ? :-)
[16:11] <joaopinto> is that better in some other language ?
[16:11] <joaopinto> :P
[16:11] <magcius> notification-osd
[16:11] <magcius> :P
[16:11] <magcius> notify-daemon
[16:12] <LaserJock> joaopinto: french I think
[16:12] <magcius> vowel
[16:12] <magcius> (pun on growl)
[16:12] <magcius> iunno
[16:13] <magcius> yano? (yet another notify-osd?)
[16:13] <joaopinto> magcius, have you tried to contact the notify-osd team about your improvements ?
[16:14] <magcius> joaopinto, I talked to people in #ubuntu+1 and they say that the design decisions are final. :(
[16:15] <LaserJock> magcius: final for Jaunty
[16:15] <magcius> LaserJock, that's not what I heard them say.
[16:15] <joaopinto> magcius, we are on a final phase, that's kind of obvious
[16:16] <LaserJock> magcius: you really should go to the source though, #ubuntu+1 isn't exactly authoritative (not that they are necessarily wrong)
[16:16] <magcius> LaserJock, is the notify-osd team on a channel somewhere here?
[16:17] <LaserJock> not sure where they're hanging out these days, you could ask tedg or mpt in #ubuntu-desktop
[16:17] <LaserJock> https://lists.canonical.com/mailman/listinfo/ayatana-project might also be helpful
[16:17] <Pici> #ayatana exists
[16:17] <LaserJock> ah, I wondered
[16:17] <tedg> magcius: #ayatana
[16:18] <magcius> ayatana?
[16:18] <LaserJock> magcius: that's the name for the overall project in Canonical
[16:18] <magcius> Oh, ayatana is the codename for the Ubuntu Desktop Experience project?
[16:19] <LaserJock> I think so
[16:22] <Hobbsee> yes
[16:37] <pacejr> is anyone willing to guess on whether or not 2.6.31 will be included in 9.10? Along with the whole updated radeon stack that's being guinea-pigged on F11?
[16:39] <pacejr> R300-R500 users are left in a bit of a bind, since fglrx dropped support and won't work with the X server in jaunty, but the new radeon stuff isn't going to hit the end user for a while
[16:40] <arpu> hello
[16:40] <arpu> i cannot mount my cdrom
[16:40] <arpu> Apr 22 17:02:39 arpu-jipiiiibox kernel: [42701.940393] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[16:40] <arpu> Apr 22 17:02:39 arpu-jipiiiibox kernel: [42701.940404] end_request: I/O error, dev sr0, sector 1248
[16:40] <arpu> Apr 22 17:02:39 arpu-jipiiiibox kernel: [42701.943970] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[16:40] <arpu> Apr 22 17:02:39 arpu-jipiiiibox kernel: [42701.943978] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
[17:26] <stephen_> Hi.
[17:28] <steveire> I'm looking for info on the netbook remix. I'm installing kubuntu and I want to make sure I get the same benefits that the netbook remix brings ubuntu. Does it use a different kernel, or ext4 by default or something?
[17:29] <steveire> http://www.canonical.com/projects/ubuntu/unr <<< This page only says the ui is different, but it doesn't have any technical details.
[17:34] <ogra> mvo, an intresting question just came up in #ubuntu-server ... does the cdromupgrade script work in non gui mode ?
[17:35] <ogra> evand, https://blueprints.launchpad.net/ubuntu/+spec/img-writing-from-usb-creator
[17:37] <evand> ogra: Thanks.  Have you seen this one: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-usb-creator-for-windows
[17:37] <ogra> heh, have you seen https://wiki.ubuntu.com/Win32DiskImager ?
[17:38] <evand> heh, "I see you a spec and raise you a wiki page"
[17:38] <ogra> its the tool we promote for UNR and MID images ... written by the son of one of the mobile team guys
[17:38] <evand> I hadn't seen it, but davidm mentioned it
[17:38] <ogra> ah, ok
[17:39] <ogra> we hsould probably just build on top of that
[17:39] <evand> I'd like to see us create windows and mac backends to usb-creator and use pygtk for the frontends
[17:39] <ogra> aww
[17:39] <ogra> that will get you huge dependency installs
[17:39] <evand> I'm refactoring the usb-creator code at the moment, but it's already well core/ui split
[17:39] <evand> not really
[17:40] <evand> py2win or cx_freeze make pretty small binaries
[17:40] <evand> I believe
[17:40] <ogra> well, the redhat liveusb-creator thing uses pyqt
[17:40] <ogra> the download is something like 30M
[17:41] <ogra> why not have generic C based backends and native frontends ?
[17:41] <evand> yikes.  Definitely not that big for pygtk, as I understand it, but as I told davidm, we could use Wubi's winui, which is a layer on top of ctypes to create MFC windows UI
[17:41] <ogra> yeah, that sounds closer to what i imagine
[17:41] <evand> I prefer writing in python.  It's easier to debug and especially easier to work with hal/dbus.
[17:42] <ogra> me too, but it always brings you the dependency probs on other OSes
[17:43] <ogra> but up to you anyway, since you are likely the one implementing it
[17:43] <evand> I think we can get them quite small with py2exe or a similar program
[17:43] <evand> heh, indeed :)
[17:43] <ogra> i'm only shameless promoter of whatever you write to get my images to people :)
[17:43] <evand> lol, duly noted
[17:46] <davidm> we have talked about this here in millbank, but I don't want to see a 30 meg download that is for sure.....
[18:03] <calc> will karmic be open for uploads next week? (the schedule seems to imply this)
[18:05]  * ogra would give it a week more by experience based on former releases
[18:05] <ogra> until the new toolchain is built and in place
[18:06] <calc> oh yea
[18:06]  * calc wants to get OOo 3.1 in as early as possible
[18:07] <calc> esp since i am moving to oem end of next week
[18:07] <ogra> upload it before the toolchain is built then :P
[18:11] <calc> ogra: i will if it doesn't cause anyone to scream ;-)
[18:11] <cjwatson> ogra: is bug 353196 important enough to need a release note?
[18:11] <cjwatson> ogra: (I don't know what previous experience you have, but mine is that it's open well within a week)
[18:11] <calc> it will only be OOo 3.1 rc2 at that point anyway so will need rebuild several times later at minimum anyway so will get plenty of toolchain testing
[18:12] <cjwatson> people always seem to massively overestimate opening time for some reason
[18:12] <ogra> cjwatson, well, it would be worth to people wanting a proper clock setting :)
[18:12] <calc> cjwatson: people being overly anxious to upload new crack ;-)
[18:12] <cjwatson> ogra: can you open a task on ubuntu-release-notes and suggest some text, please?
[18:12] <ogra> (the bug that is)
[18:12] <calc> like watching water boil :)
[18:13] <Riddell> steveire: yo
[18:13] <cjwatson> Jaunty opened for development on 4 Nov, five days after release. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-November/000510.html
[18:14] <cjwatson> Intrepid opened for development on 2 May, eight days after release. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-May/000424.html
[18:14] <ogra> and it took a week until we had a usable toolchain, no ?
[18:14] <cjwatson> Hardy opened for development on 24 Oct, six days after release. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-October/000348.html
[18:15] <cjwatson> ogra: err, we don't send the "open for development" mails until we have a usable toolchain
[18:15] <ogra> oh
[18:15] <calc> so does the new toolchain get tested by rebuilding the whole archive privately or something like that?
[18:15] <Riddell> steveire: it's release day tomorrow so people may be busy, what's your interest?
[18:15] <cjwatson> Gutsy opened for development on 26 Apr, seven days after release. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000285.html
[18:16] <cjwatson> calc: yes
[18:16] <calc> ok
[18:16] <cjwatson> or at least so I understand it, doko tends to handle all this pretty quietly :)
[18:16] <cjwatson> doko: ^- (how's it going?)
[18:17] <Riddell> steveire: the likes of lool, ogra, persia, NCommander and others are probably good to ask about UNR
[18:17] <directhex> cjwatson, people overestimate opening time because they subconsciously add freeze time to it
[18:17]  * NCommander waves
[18:18] <Riddell> steveire: or there's a #ubuntu-mobile channel
[18:18] <ogra> steveire, and we tend to hang around in #ubuntu-mobile :)
[18:18] <cjwatson> directhex: it annoys me because I've been personally putting vast effort into getting it open really quickly for the last several releases, and yet people continue to say it takes multiple weeks
[18:18] <cjwatson> when it just plain doesn't
[18:18] <broonie> Where would I expect to find people working on the Ubuntu ARM kernels?
[18:19] <lool> broonie: Probably on #ubuntu-kernel or -arm
[18:19] <directhex> cjwatson, sadly it's inevitable
[18:19] <lool> Depends what you'd like to ask
[18:19] <directhex> oh, anyone know how to generate -dbgsym packages with pbuilder?
[18:19] <cjwatson> directhex: I'm not going to stop calling people on it
[18:19] <mvo_> ogra: yes
[18:19] <broonie> lool: Thanks.
[18:19] <ogra> mvo_, already solved :)
[18:19] <lool> directhex: I'd guess that you need to install the relevant package; I'd be curious to hear how it works
[18:19] <directhex> cjwatson, i never said you should stop, i said it's inevitable!
[18:20] <lool> pkg-create-dbgsym would be the one I guess
[18:20] <doko> cjwatson: wanted to address this in today's platform meeting ...
[18:21] <mvo_> ogra: just out of curisosity, it should detect that it needs text mode automatically, was that not working?
[18:21] <mvo_> ogra:  who was it that came up with the question?
[18:21]  * calc hugs cjwatson for ensuring new releases open on time :)
[18:21] <infinity> doko: Speaking of...
[18:22] <infinity> doko: Which architectures did you want that toolchain test on?  And is the version in your PPA now the one you actually want tested?
[18:22] <infinity> doko: (And does it come with a shiny gcc-defaults to match too?)
[18:22] <ogra> mvo_, pmatulis
[18:23] <mvo_> ogra: thanks, I will ask him for more details
[18:23] <cjwatson> doko: can we address it here and now? :-)
[18:23] <cjwatson> infinity: meep, it hasn't started?
[18:25] <directhex> lool, it looks simple-ish. testing
[18:25] <doko> infinity: shiny gcc-defaults just uploaded
[18:25] <infinity> cjwatson: Nein.
[18:25] <doko> infinity: the gcc-4.4 package is ok for the test rebuild
[18:25] <infinity> cjwatson: But if it's just main on $fast_arch, it won't really take that long.
[18:25] <doko> infinity: archs: i386, maybe lpia
[18:26] <infinity> doko: I don't deal in maybes. :)
[18:26] <lool> directhex: There's the EXTRAPACKAGES option in pbuilderrc to add such packages permanently
[18:26] <doko> infinity: archs: i386 lpia
[18:26] <infinity> doko: Alrighty.  I'll make that a priority today.
[18:26] <directhex> lool, yes, at "pbuilder create" time. and i need to make sure it actually works
[18:26] <doko> infinity: thanks
[18:26] <lool> directhex: It works on updates too
[18:27] <steveire> Riddell: Aha, I was looking for #ubuntu-netbook and such... Cheers.
[18:28] <infinity> cjwatson: What else is on the opener TODO list for me?  I've got "test rebuild of new toolchain, karmic chroots, and karmic livefs environments"... The latter two obviously happening once the rebuild is in swing.
[18:32] <directhex> lool, confirmed as working btw
[18:33] <doko> cjwatson: well, I'd like to look at the rebuild first, and then decide, if we switch to 4.4 now, or better a bit later
[18:34] <lool> directhex: Cool
[18:35] <ogra> cjwatson, bug updated with task and text ... if you need more from me, shout now, else i'll go for the day
[18:35] <cjwatson> infinity: test rebuild absolutely top priority, that's probably most of it
[18:36] <cjwatson> I think most of the rest is ours
[18:37] <cjwatson> ogra: that's fine, thanks
[18:37] <calc> can i create a repo of this type on launchpad?: Shared repository with trees (format: pack-0.92)
[18:37] <ogra> ok, i wasnt sure there wasnt more ARM stuff on your list, but i'll be around tomorrow morning if there is more
[18:38] <calc> it appears that type of repo allows multiple sub repos under it, looking at how bzr works on debian anyway.
[18:40] <cjwatson> calc: Launchpad deals in terms of individual branches; you can certainly push up a branch in that form, and it will work fine, although the whole repository won't get pushed up to LP
[18:41] <calc> cjwatson: ah ok
[18:41] <cjwatson> mvo__: bug 364620 looks as if it could do with a release note?
[18:41]  * calc had hoped that worked around the individual branch limitation of lp
[18:42] <cjwatson> calc: read up on stacked branches
[18:42] <cjwatson> calc: https://help.launchpad.net/LaunchpadReleases/2.1.10
[18:43] <cjwatson> oh, and indeed
[18:43] <cjwatson> calc: http://blog.launchpad.net/cool-new-stuff/stacked-branches-holding-post
[18:44] <mvo__> cjwatson: yes, I add some (there is a sru for this pending already)
[18:44] <calc> ok
[18:44] <cjwatson> calc: of course this depends on whether there's something sensible you can set as the development focus branch
[18:45] <cjwatson> calc: we have a proper namespace for source package branches in Launchpad now, which we're going to start using RSN
[18:45] <cjwatson> calc: kiko thinks that stacked branches should work with this - i.e. you'll be able to say that the Ubuntu karmic openoffice.org branch is the development focus and push branches stacked on that
[18:46] <cjwatson> but we'll need to test this since we haven't really started using source package branches yet
[18:46] <calc> ok
[18:47] <cjwatson> mvo__: ok, thanks, I've created an ubuntu-release-notes task
[18:48] <calc> really what i had wanted when i was working on the split build (which is postponed now) was a way to have partial checkouts, or some other way to group related package-wise branches together, that aren't actually related from a scm point of view
[18:48] <cjwatson> lool: does bug 364621 require a release note, or even a respin to remove that option?
[18:48] <mvo__> cjwatson: thanks
[18:48] <calc> so i would have one openoffice.org split build top level branch that 15 or so subdirs i could pull out separately, which can be done in subversion already, not sure about other scm's
[18:48] <doko> infinity: bah, archive too big, I've put the package on chinstrap:~doko. See question #68267. have to run now
[18:48] <cjwatson> lool: and is bug 364623 important?
[18:50] <infinity> doko: Okay.  The import will take a while anyway.  I'll ping you later if I run into any pitfalls.
[18:59] <mvo__> Riddell: https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes?action=diff&rev2=61&rev1=60 <- ok ?
[19:00] <directhex> what should sizeof (GdkNativeWindow) be?
[19:01] <mdz> lool: is there any reason bug 364516 needs to stay private?
[19:01] <mdz> lool: it's your gvfs-fuse-daemon crash on armel, I assume the coredump doesn't have any private data
[19:01] <mdz> I don't expect there is an apport retracer for armel yet, so it will stay private indefinitely unless we just make it public
[19:01] <mdz> lool: if you agree, please go ahead and make it public when you get this message
[19:02] <cjwatson> directhex: I believe it's typedeffed to guint32 on Linux, so 4
[19:03] <directhex> cjwatson, even on amd64?
[19:05] <cjwatson> directhex: apparently
[19:05] <cjwatson> it's an x window id or something not a pointer, AFAICS
[19:22] <mdz> bdmurray: I got the following numbers for the past 30 days:
[19:22] <mdz>  9% apport automated crash reports
[19:22] <mdz>  5% apport automated package failure reports
[19:22] <mdz> 10% apport automated kernel bug reports
[19:22] <mdz> 17% apport manual bug reports
[19:22] <mdz> 56% non-apport
[19:23] <mdz> that's just a simple scan of the tags (apport-crash, apport-package, apport-kerneloops, apport-bug)
[19:24] <bdmurray> mdz: out of how many bugs?
[19:24] <mdz> bdmurray: that's out of 7094 bug tasks
[19:24] <mdz> (it counts tasks rather than bugs)
[19:24] <bdmurray> mdz: right, that makes sense
[19:25] <bdmurray> mdz: I'd neglected the kerneloops ones in my counting - thanks for the reminder
[19:31] <calc> ouch 56% non-apport :\
[19:36] <bdmurray> calc: its better than before!
[19:38] <directhex> cjwatson, GdkNativeWindow is typedeffed to either gpointer or guint32, depending on whether GDK_NATIVE_WINDOW_POINTER is defined
[19:38] <calc> bdmurray: just turn off web submission... :-)
[19:38]  * calc wonders what percentage of non-apport bugs are actually useful
[19:39] <cjwatson> directhex: yes, and GDK_NATIVE_WINDOW_POINTER is (AFAICS) only defined on Windows
[19:40] <directhex> cjwatson, a header in the app i'm trying to debug has
[19:40] <directhex> #if GLIB_SIZEOF_VOID_P == 8
[19:40] <directhex> #define GDK_NATIVE_WINDOW_POINTER 1
[19:40] <directhex> #endif
[19:40] <cjwatson> haha, err
[19:40]  * cjwatson runs away
[19:41] <directhex> cjwatson, yeah, i know ^_^
[19:41] <directhex> i wish i didn't suck with C
[20:06] <Riddell> mvo: good with me thanks
[20:46] <NCommander> hey cjwatson, you got a minute between now and release to chat about PowerPC releasability (I doubt its possible for jaunty (although the images I've tested thus far work great aside from some minor usplash bugs with NVIDIA hardware) but I'd like to have a roadmap in place for karmic)
[21:47] <LaserJock> is the DC getting hit very hard yet? some ubuntu sites are bit slow
[21:47] <elmo> LaserJock: no
[22:03] <LaserJock> slangasek: http://www.edubuntu.org/news/9.04-release exists
[22:36] <cjwatson> NCommander: if it seems to basically work now, why shouldn't we release it? that's about all the standard we apply to ports ...
[22:36] <NCommander> cjwatson, works for me :-)
[22:36] <cjwatson> NCommander: it won't go on releases.ubuntu.com, but that's just a mirroring consideration, that doesn't govern whether it's "released" or not
[22:37] <NCommander> cjwatson, no, I know (same reason ports isn't on the normal mirror network)
[23:51] <LaserJock> slangasek: is it ok if I edit the release announcement wiki page to include Edubuntu?