[00:44] <kees> asac: when you get a moment, can you take a look at bug 455151 please?
[00:53] <slangasek> kirkland: did you build test this eucalyptus upload before uploading? (FTBFS, not sure if it's because of your change or the rash of maven syncs that's to blame)
[00:55] <slangasek> kirkland: sigh - looks like it's the maven syncs that are to blame, yes
[01:00] <afmaway> Hey guys, I would like to setup a secure/restrict apt repository and grant users access based on certificates
[01:00] <afmaway> is that possible?
[01:03] <kirkland> slangasek: ack
[01:03] <kirkland> slangasek: i did locally build my change (as always)
[01:04] <kirkland> slangasek: that went fine on my side
[01:04] <slangasek> kirkland: <nod> - I'm beating up on libgoogle-collections-java now
[01:04] <kirkland> slangasek: ttx warned me about a bunch of java changes that might hurt us
[01:04] <slangasek> kirkland: do you understand java build systems better than I do?
[01:04] <kirkland> slangasek: i absolutely do not
[01:04] <slangasek> heh
[01:32] <slangasek> kirkland: bug #455931 opened; I'm making only slow progress, it would be good to have someone who knows java looking at this
[01:32] <slangasek> s/java/ant/
[01:40] <smoser> slangasek, i'm here if you're around.
[01:41] <slangasek> smoser: sorry, gotten sucked into this eucalyptus build failure now, and have to break for dinner shortly :(
[01:41] <smoser> fair. whenever you have a chance. i'm gonna be done for the night here, though.
[01:42] <smoser> that link i pasted above is, i think, mostly done
[01:42]  * slangasek nods
[01:42] <smoser> the promote to release should be pretty easy
[01:42] <smoser> i just tested this process myself today.
[01:43] <lifeless> slangasek: hi
[01:43] <smoser> but, slangasek, i still need some direction at least on doing HEADER stuff.
[01:43] <lifeless> slangasek: google-collect.jar is the symlink that may be needed
[01:44] <lifeless> /usr/share/java/google-collect.jar -> /usr/share/java/google-collections-0.8.jar
[01:45] <slangasek> lifeless: I think I've found where in the eucalyptus build it references this, I think we should just update eucalyptus with the new path; test building now
[01:45] <slangasek> lifeless: thanks for looking, though
[01:45] <lifeless> it may be an upstream change unrelated to the maven2 transition
[01:45] <lifeless> that said, java building on debian/ubuntu is fundamentally broken :(
[01:46] <slangasek> lifeless: it's not a new upstream version of the package <sigh>
[01:46] <lifeless> the packages represent ABI's, so the binary names should be versioned like they are for C/C++ libraries.
[01:46] <lifeless> slangasek: ah, _fun_
[02:26] <Caesar> slangasek: is Ubuntu considering switching to eglibc?
[02:28] <DGMurdockIII> what with the pluse audo support in ubuntu
[02:28] <TheMuso> DGMurdockIII: What about it?
[02:28] <DGMurdockIII> why is so buggy in ubuntu
[02:28] <lifeless> as opposed to in ???
[02:29] <dotblank> If anything its more stable then it was before
[02:29] <DGMurdockIII> fedora
[02:29] <ScottK> Caesar: Already switched
[02:29] <sladen> Caesar: Debian switched for us
[02:29] <dotblank> Im tired of people complaining about pulse....
[02:29] <dotblank> I like pulse
[02:30] <dotblank> Makes my life actually easier
[02:30] <pwnguin> dotblank: http://0pointer.de/blog/projects/pa-in-ubuntu.html
[02:30] <sladen> dotblank: http://bugs.launchpad.net/ubuntu/+source/pulseaudio/+filebug
[02:31] <DGMurdockIII> ii like it to if you get it working right but with my ati all in wonder hd it took my 8 hourd to get my sound to work over HDMI using the all in wonder card
[02:31] <TheMuso> DGMurdockIII: how is it more buggy?
[02:33] <dotblank> hmm I see
[02:33] <dotblank> well it works for me
[02:34] <bryce__> vorian, -vmmouse is missing from main - LP #69780, #407816.
[02:34] <bryce__> er
[02:34] <bryce__> slangasek, -vmmouse is missing from main - LP #69780, #407816.
[02:34] <pwnguin> probably the best linux audio strategy is to ask what laptops the distro developers own and buy them
[02:34] <pwnguin> because everything always "works for me"
[02:34] <dotblank> wow ok that is stupid why cant they use that patch?
[02:34] <DGMurdockIII> ii like it to if you get it working right but with my ati all in wonder hd it took my 8 hourd to get my sound to work over HDMI using the all in wonder card
[02:35] <bryce__> slangasek, I've got a commit sitting in xorg's git to add as an explicit dependency on xserver-xorg-input-vmmouse - should I upload this, or is something more needed?
[02:35] <DGMurdockIII> i sold not have to go througt all that trouble it should work out of the box
[02:37] <TheMuso> DGMurdockIII: What version of Fedora are you comparing it against?
[02:37] <DGMurdockIII> fedora 11
[02:37] <TheMuso> DGMurdockIII: and what version of Ubuntu are you trying to use?
[02:38] <DGMurdockIII> ubuntu 9.04
[02:38] <TheMuso> Right, well 9.10 has changed a lot, so I suspect your problem is fixed in 9.10.
[02:39] <DGMurdockIII> ok
[02:40] <pwnguin> really, to make any claim about this youd need to know how many bugs were fixed, and how many are still remaining. but its worth a shot
[02:40] <pwnguin> esp since you know it's possible to make it work
[03:07] <slangasek> Caesar: no, because Ubuntu is already switched to eglibc ;)
[03:11] <slangasek> bryce__: which package gets the dep on -vmmouse, how much does it change our CD sizes?
[03:12] <slangasek> bryce__: anyway, please upload and I'll have a look at it in the queue
[03:17] <bryce__> slangasek, its uploaded, package is 'xorg'
[03:18] <slangasek> ok
[03:22] <YokoZar> slangasek: can I have 8kb of cd space to put a missing icon in app-install-data? pretty please :)
[03:23] <YokoZar> actually it's probably way less than that compressed
[03:23] <slangasek> really?  if it's way less than that compressed, sounds like you're using the wrong image format ;)
[03:24] <slangasek> we can spare 8k on the CDs, yes
[03:29] <slangasek> bryce__: new files in the debdiff, not documented in the changelog: debian/local/Xsession.d/60x11-common_localhost, debian/local/dexconf.patch ?
[03:30] <directhex> um... is it me, or is karmic unhappy about the idea of changing timezone?
[03:31] <directhex> /etc/timezone seems unchanged by what i poke in system/administration/time and date - and it resets my changes to london time
[03:31] <slangasek> works if I change it via gnome panel
[03:35] <slangasek> bryce__: welp, the extra changes in the debdiff don't seem to imply any changes to the actual binary packages, unless they cause a build failure... so accepted, and hopefully it won't cause a build failure
[03:35] <bryce__> slangasek, hmm
[03:35] <slangasek> and -vmmouse promoted back
[03:35] <bryce__> thanks
[03:36] <bryce__> slangasek, 60x11-common_localhost I'm not sure where that came from
[03:36] <bryce__> the dexconf.patch is stray from an earlier review, my bad.
[03:37] <bryce__> damn git trees
[03:38] <bryce__> slangasek, I'd like to upload a new version with these two files removed.  They shouldn't be there and I'd be more comfortable if they weren't.
[03:38] <slangasek> bryce__: ok, go ahead
[03:39] <jsgotangco> jcastro: damn dude you posted a very old pic! I look thin :P
[03:42] <LaserJock> jsgotangco: and so young!
[03:46] <YokoZar> slangasek: the image format is .svg ;)
[03:47] <slangasek> oh, yes, xml, *definitely* the wrong format >:)
[03:52] <slangasek> superm1: is anyone working on bug #438875, that you know of?
[04:04] <LaserJock> slangasek: is it possible to know with what revision of debian-cd the .isos have been built with?
[04:04] <slangasek> LaserJock: I don't think that's logged anywhere, no
[04:05] <LaserJock> slangasek: darn, oh well
[04:05] <slangasek> LaserJock: is that information actually useful anyway?  Is there a public branch corresponding to the debian-cd used on the builder?
[04:06] <kirkland> slangasek: that's going to have to be ttx
[04:06] <slangasek> kirkland: for java?  already fixed
[04:06] <LaserJock> slangasek: well, I assume so
[04:06] <kirkland> slangasek: he's the best person for it
[04:06] <kirkland> slangasek: oh, sorry, just reading scrollback now
[04:06] <slangasek> kirkland: no problem :)
[04:06] <kirkland> slangasek: sorry, been under the weather today, in and out of bed
[04:07] <slangasek> LaserJock: that's quite an assumption; the builder is somewhat contained wrt network access, and I know the changes I make to debian-cd don't get published to the outside world as part of anything /I/ do...
[04:07] <LaserJock> slangasek: I assume http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
[04:07] <LaserJock> is what gets used
[04:07] <slangasek> LaserJock: oh right, people keep repeating that URL, and I keep forgetting it :-)
[04:07] <slangasek> (that implies cjwatson pulls periodically, then, yes)
[04:08] <LaserJock> I just expected an important change to show up and it appears it didn't
[04:09] <LaserJock> so I'm wondering if it's because of the timing of the bzr merge or if I need to dig more
[04:09] <LaserJock> sometimes I wish we had hourlies ;-)
[04:09] <LaserJock> but I'm guessing you wouldn't like that very much
[04:10] <slangasek> on account of it not working
[04:11] <slangasek> LaserJock: what part of the change isn't showing up?
[04:11] <slangasek> LaserJock: part of the change is the 'Install an LTSP server' option, which should certainly be easy to confirm/deny
[04:12] <LaserJock> slangasek: yeah, problem is it's a "deny"
[04:12] <slangasek> because bzr respects timestamps, I can't really tell whether the update was done before or after the edubuntu build; so if you don't see the boot option, I think we should just respin
[04:13] <LaserJock> slangasek: k
[04:13] <LaserJock> I need to check if Ubuntu Alternate has it
[04:14] <LaserJock> first I'll check that the seed file is there
[04:14] <slangasek> actually, the preseed changes are there in the current edubuntu AFAICS
[04:14] <LaserJock> ok, yeah
[04:15] <LaserJock> the ltsp.seed is on the DVD
[04:15] <LaserJock> why the heck isn't it showing up
[04:15] <LaserJock> anybody have an Ubuntu Alternate daily handy to check if LTSP is in the F4 menu?
[04:15] <slangasek> LaserJock: you're looking at 20091020?
[04:15] <LaserJock> yeah
[04:16] <slangasek> yeah, I see the changes present in gfxboot.cfg as well
[04:17] <slangasek> LaserJock: F4> what do you see in that menu? f4.txt doesn't mention anything about ltsp
[04:17] <slangasek> there's f3.txt, which gives a list of boot methods; ltsp isn't mentioned there either
[04:17] <LaserJock> in previous Ubuntu releases it's been in the F4 menu
[04:18] <slangasek> what is the F4 menu?  I don't have a booted ISO in front of me, I'm trying to figure this out based on inspecting the scratch dir
[04:18] <slangasek> the f4.txt isn't menu-y at all
[04:18] <slangasek> it mentions 'rescue', that's it
[04:19] <LaserJock> I have: normal, safe graphics, and Use driver update disc
[04:19] <slangasek> ok
[04:19] <slangasek> so that's all taken from gfxboot.cfg, indeed
[04:20] <slangasek> I don't actively understand how that's supposed to work, though, so don't know why ltsp isn't showing up
[04:22] <LaserJock> is 20091020 still being built for Ubuntu Alternate?
[04:22] <slangasek> no, images only get built when manually triggered now
[04:26] <LaserJock> I see
[04:27] <LaserJock> well poo, why didn't this work
[04:27] <LaserJock> I guess I need to download an Ubuntu Alternate and see if it works there as the seed file, etc. are the same
[04:28] <TheMuso> LaserJock: It may be quicker to pull the debian-cd bzr branch and check there...
[04:28] <slangasek> no, the changes in question are changes that he /pushed/
[04:28] <slangasek> we just don't know why they don't work
[04:28] <TheMuso> slangasek: ah ok.
[04:43] <shtylman> ccheney: will take a look at it
[05:03] <Laibsch> Hi ArneGoetje
[05:04] <Laibsch> Can you briefly explain to me the difference and similarity between ttf-arphic-{ukai,uming}?
[05:10] <Laibsch> They are just different styles, right?
[05:10] <Laibsch> I'm asking because some packages recommend uming and others ukai
[05:10] <LaserJock> slangasek: ok, so the Ubuntu Alternate from 20091019.1 has the LTSP F4 option
[05:11] <Laibsch> ArneGoetje: What do you think about making {chinese,japanase,...} fonts provide the virtual package $lang-font and encourage packages to depend on that?
[05:17] <Laibsch> brb
[05:38] <ArneGoetje> Laibsch: what benefit would that have?
[05:38] <Laibsch> that's like asking what benefit do virtual packages have
[05:39] <Laibsch> These packages all provide essentially a similar functionality
[05:39] <Laibsch> in different "implementations"
[05:39] <Laibsch> why depend on uming for package A and ukai for package B when in fact the dependency for a Japanese font could be fulfilled by just any Japanese font
[05:40] <Laibsch> ?
[05:40] <ArneGoetje> Laibsch: different fonts have different styles and are made for different usages... do you really want to mix that up by suggesting "any" Chinese, Japanese, etc. font to packages?
[05:40] <Laibsch> I doubt that the packager meant to depend on a specific style
[05:40] <Laibsch> If they do, fine.  Keep that recommendation.
[05:42] <Laibsch> It's more like that in 99% of the cases the packager wants to indicate that scim will not be really usable without a CJKV font, for example
[05:43] <ArneGoetje> Laibsch: I would be OK with that if we limit this to desktop (screen friendly) fonts...
[05:45] <Laibsch> that includes and excludes which fonts for example?
[05:46] <ArneGoetje> Laibsch: includes wqy-zenhei (which is installed by default anyways), ttf-arphic-uming and exclude ttf-arphic-ukai, since that font is only suitable for high resolution devices, e.g. printers
[05:52] <Laibsch> I see
[05:52] <Laibsch> Why would scim-pinyin recommend ttf-arphic-ukai, then?
[05:53] <ArneGoetje> Laibsch: a package which teaches CJK characters for example, would want to recommend ttf-arphic-ukai explicitly and display the glyphs in a larger font size.
[05:53] <ArneGoetje> Laibsch: I don't
[05:53] <Laibsch> you don't "know"?
[05:53] <ArneGoetje> Laibsch: recommend scim-pinyin to use ttf-arphic-ukai
[05:53] <Laibsch> other way round
[05:54] <Laibsch> $ aptitude why ttf-arphic-ukai
[05:54] <Laibsch> i   scim-pinyin Recommends ttf-arphic-ukai
[05:54] <Laibsch> judging from your explanation
[05:54] <ArneGoetje> Laibsch: I don't recommend scim-pinyin to use ttf-arphic-ukai
[05:54] <Laibsch> that looks like the wrong font
[05:54] <ArneGoetje> Laibsch: +1
[05:54] <Laibsch> OK
[05:55] <Laibsch> ttf-arphic is not screen friendly?
[05:55] <Laibsch> ???
[05:55] <Laibsch> ttf-arphic-ukai is not screen friendly?
[05:55] <ArneGoetje> Laibsch: should be changed to Recommends: ttf-wqy-zehei | ttf-arphic-uming
[05:55] <Laibsch> OK
[05:55] <Laibsch> I'll see to that
[05:55] <ArneGoetje> Laibsch: ttf-wqy-zenhei that is
[05:56] <TheMuso> cd
[05:56] <TheMuso> gah wrong tab
[05:57] <ArneGoetje> Laibsch: ttf-arphic-ukai is a Kaishu font (brush stroke), which is great for teaching how to write characters, but only looks good on high resolution devices or at larger font sizes. Something which doesn't go well with 96dpi screens and 10pt font sizes. :)
[05:57] <Laibsch> I see
[05:58] <Laibsch> For Japanese I'm basically aware of three main font categories: Mincho, Gothic and those Kaishu fonts
[05:59] <ArneGoetje> Laibsch: yes. For desktop/screen Gothic is preferred. Mincho is used for printed articles, Kaishu for calligraphy printings
[06:00] <Laibsch> I like Mincho for everything
[06:00] <Laibsch> It's softer and got the brushy feel to it while still being readable
[06:01] <ArneGoetje> Laibsch: for Chinese we have similar categories: Heiti or Yuanti (= Gothic) for screen, Mingti/Songti for articles, Kaiti for calligraphy
[06:02] <Laibsch> i see
[06:06] <ArneGoetje> Laibsch: anyways, for Ubuntu I don't see the need for those virtual font packages, since we ship desktop friendly fonts for CJK by default on the LiveCD. For Debian those would make sense however.
[06:07] <Laibsch> Ubuntu is not only the LiveCD
[06:07] <Laibsch> I think it makes a lot of sense for Ubuntu as well
[06:07] <Laibsch> And once it's in Debian, it's in Ubuntu, too, anyway
[06:07] <superm1> slangasek, i had hearrd that it was fixed at some point, but i've not confirmed it myself yet
[06:08] <superm1> with all the usplash changes and what not, i've seen mixed behaviors recently
[06:08] <ArneGoetje> Laibsch: they are dependencies of ubuntu-desktop
[06:08] <slangasek> superm1: seems like something we would want fixed, so would be good to know whether it /is/ fixed :)
[06:08] <Laibsch> ArneGoetje: Which I for example have removed
[06:09] <superm1> slangasek, yeah.  it should be the exact same behaviors on all *buntu disks too, nothing special for myth*
[06:09] <superm1> slangasek, neither 1019 nor 10191.1 appear to have ISOs in the folders though, so i'll have to defer an hour or so until 1020 is made to verify
[06:10] <slangasek> superm1: we're in manual mode on ISO builds; best is to ask me if you see something missing
[06:10] <superm1> slangasek, Ah, then yes can you try to regenerate ours?  the last two haven't showed up
[06:10] <slangasek> yep, doing an ISO-only rebuild now
[06:10] <slangasek> (i.e., using the existing lives)
[06:10] <slangasek> livefs
[06:11] <superm1> thanks
[06:11] <ArneGoetje> Laibsch: okay... what would be the best approach for such virtual packages?
[06:12] <Laibsch> I'm in the process of opening a ticket on LP
[06:12] <Laibsch> We can then collect the fonts that should be made to provide the virtual package
[06:13] <shtylman> ccheney: patch is good
[06:13] <Laibsch> once those changes are in Debian and/or Ubuntu, the next step is to adjust dependencies of the packages that hardwire their dependency on particular fonts
[06:13] <Laibsch> and relax that to the appropriate virtual package
[06:15] <maco> i'm getting differing advice from different devs (no surprise i guess). is it best to add, say, quilt to a package if patching it or to simply apply the patch? one says add a patch management system so syncs dont break it. other says whomever's doing syncs should know to check for merging being necessary. opinions?
[06:17] <Laibsch> maco: my opinion is that if you can add a patch system like quilt or dpatch it's generally the better option
[06:17] <ScottK> maco: The current advice is don't bother adding a patch system if Debian doesn't have one.
[06:17] <ScottK> Laibsch: Why?
[06:17] <maco> *snort*
[06:17] <maco> its still a tie!
[06:18] <Laibsch> no
[06:18] <ScottK> No, not actually.
[06:18] <Laibsch> ScottK is right
[06:18] <Laibsch> I was talking about something else
[06:18] <Laibsch> let me explain
[06:19] <Laibsch> if you really manage a package (iow you are Debian package maintainer) then it's a good idea to install a patch system like quilt or dpatch
[06:19] <Laibsch> it keeps things cleaner and more manageable imho
[06:19] <slangasek> maco: "syncs" are a red herring; if you're patching it at all then whoever is nominating it for a sync needs to explain why those changes should be dropped, whether or not a patch system is used
[06:19] <Laibsch> but scottk is absolutely right that if Debian does not have a patch system in place and you want to prepare a ubuntu1 package, then it's probably better to patch directly
[06:20] <ScottK> Laibsch: That's one way to do it.  Using a VCS is all the rage too these days.
[06:20] <Laibsch> how is that an alternative?  I use a VCS for my Debian packages, yet still use quilt when applying Debian-only patches
[06:21] <slangasek> I don't agree that it's better to patch directly unless you *also* point the Vcs-* fields at a relevant repo
[06:21] <Laibsch> So far, I'm using then as tools for different things
[06:21] <ScottK> Laibsch: VCS of the full source, not just a debian dir.
[06:21] <Laibsch> I see
[06:21] <ScottK> slangasek: If you have free time, I just filed a couple of removal bugs.  The gtk1.2 cleanup appears incomplete.
[06:22] <slangasek> ScottK: currently running the unapproved queue, can have a look at those after
[06:22] <ScottK> No rush
[06:23] <Laibsch> I'm still packaging tarball-releases only so far
[06:23] <Laibsch> I'm packaging gnucash cvs for private use
[06:23] <Laibsch> I'm sure the way I do it is a mess ;-)
[06:31] <slangasek> kirkland: isn't this mpich2 upload missing a FFe, seeing that it's bumping sonames?
[06:48] <slangasek> robert_ancell__: I'm uneasy with this gdm upload.  switching from g-p-m to devkit, the week of RC?
[06:50] <slangasek> robert_ancell__: or is this the 21_dkpower.patch that we already had?
[06:52] <slangasek> robert_ancell__: right, seems that it is - that's ok then
[06:52] <slangasek> -DI_KNOW_THE_DEVICEKIT_POWER_API_IS_SUBJECT_TO_CHANGE - heh, nice
[06:53] <slangasek> robert_ancell__: it looks like our local patch had support for hibernate in addition to suspend, though, and that's missing in the upstream code?
[06:55] <slangasek> robert_ancell__: also, the path for at-spi-registryd is now wrong.  I'm not sure that it was right before, but it's definitely wrong now, /usr/libexec isn't part of the FHS
[06:56] <slangasek> (the prefix was configurable before, now it's hardcoded, meh)
[06:56] <slangasek> asac, pitti: seahorse-plugins is dropping epiphany-browser in time for RC?
[07:01] <superm1> slangasek, well is the expected behavior that that question in bug 438875 is asked via usplash?  it comes up, but it's just sitting on a plane vt
[07:01] <superm1> *plain
[07:22] <siretart> morning
[07:24] <slangasek> superm1: I /think/ usplash is supposed to exit, then the question is supposed to be displayed
[07:24] <siretart> dtchen: a friend pointed me to it yesterday, shouldn't /etc/libao.conf use pulseaudio by default in the package?
[07:26] <superm1> slangasek, well if that's the case, then this is working "properly".  i recall in earlier releases the question was actually posed via usplash
[07:28] <slangasek> superm1: yes, the code in casper is there to do that if usplash is still running; I think that's probably worth a bug report against usplash
[07:28] <slangasek> but doesn't seem like a blocker
[07:29] <superm1> slangasek, okay i'll close that original bug then and file a new one against usplash
[07:29] <slangasek> ok, cheers
[07:29] <robert_ancell__> slangasek, the gdm patch should be ok because we don't use the buttons in upstream for shutdown - 22_shutdown_menu reimplements them in the bottom panel
[07:34] <slangasek> robert_ancell__: aha, confirmed
[07:34] <pitti> Good morning
[07:34] <slangasek> robert_ancell__: the at-spi-registryd bit might bear further looking into?  But accepting this upload, in the meantime
[07:34]  * slangasek waves to pitti 
[07:35] <pitti> slangasek: I talked about this with asac and seb128 yesterday, and the plan was to drop the recommends in the 2.28.1 upload
[07:35] <slangasek> pitti: ok, so I should watch for that upload
[07:35] <pitti> slangasek: btw, tzdata 2009o is out; would you mind if I sync that?
[07:35] <slangasek> s/watch for/sponsor/ ;)
[07:35] <slangasek> pitti: go ahead
[07:36] <robert_ancell__> hey is anyone a pkg-config expert here? Bug 455614 was raised where Debian has removed a recommends from a .pc file, any idea why you would want to do that?
[07:36] <pitti> it seems Argentina changed rules slightly (probably for the Saint Louis special case *sigh*)
[07:36] <superm1> slangasek, re that alsa-utils thing from the other day, i can confirm reverting debian/init back to ubuntu3 from ubuntu5 does solve the problem too.
[07:37] <slangasek> superm1: right - I haven't seen a fixed upload yet that just does this, however
[07:37] <superm1> slangasek, yeah i was going to confirm with you that it's okay to upload such a thing first (after I confirmed that it really did fix it)
[07:37] <slangasek> yes, please
[07:38] <superm1> okay will do in a few min
[07:39] <pitti> slangasek: seahorse-plugins> oh, you are going to? I'll sponsor the other bits then (gdm, g-d-sharp, etc.)
[07:40] <slangasek> pitti, asac: well, the bzr branch doesn't yet have the epiphany change
[07:40] <slangasek> and I would have to hunt down the upstream tarball; better if someone else does it, I think
[07:40] <pitti> slangasek: *nod*
[07:41] <pitti> slangasek: I'll talk to asac about the epy change when he's up and upload ASAP
[07:50] <robert_ancell> TheMuso: Do you know about the Exec field in /usr/share/gdm/autostart/LoginWindow/at-spi-registryd-wrapper.desktop? It's changed in gdm-2.28.1 but I don't know what the effect is
[07:55] <slangasek> robert_ancell: note that for the other instance of usr/libexec in the source, debian/patches/04_fix_external_program_directories.patch fixes this up
[07:57] <robert_ancell> slangasek, yeah, the thing that's got me is there is nothing providing the current path.  So I'm thinking it may not make any difference what path is in there currently
[07:57] <slangasek> robert_ancell: sure, that was my rationale for accepting it as-is :)
[07:58] <robert_ancell> slangasek, :)
[07:59] <robert_ancell> mvo, should the gnome-codec-install changes you pushed into bzr be released? bug 455131
[07:59] <slangasek> mvo: does update-manager need an update yet to s/karmic/9.10/ for release?
[08:01] <pitti> seb128: do you know the plan (how) to drop epy from seahorse-plugins? there's a sponsoring request for 2.8.1, but it doesn't have that change
[08:02] <seb128> pitti, asac said he would work on that, I assigned the bug to him yesterday
[08:02] <pitti> seb128: ok, thanks
[08:02]  * StevenK blinks at autologin not working
[08:03] <robert_ancell> StevenK, not working?
[08:04] <mvo> slangasek: no, but I have a change for 431473 pending
[08:04] <slangasek> mvo: ok, cool; DistUpgrade/ReleaseAnnouncement seems ready, wasn't sure if there was anything else needed
[08:05] <mvo> robert_ancell: yes, the changes should be fine, I meant to do triage on the open bugs and see if there are low hanging fruits, but I did not manage to :/
[08:05] <slangasek> mvo: is that the right bug number?
[08:05] <StevenK> robert_ancell: I could have sworn Moblin Remix, UNR and desktop should autologin. Moblin Remix is at gdm, and I can't login
[08:05] <mvo> slangasek: yeah, this time we have two release notes that we can switch more dynamically)
[08:05] <mvo> slangasek: bug #434173
[08:06] <slangasek> mvo: good plan :)
[08:06] <slangasek> mvo: ah yes, that bug number looks much better :)
[08:06] <slangasek> StevenK: 2.28.0 or 2.28.1?
[08:06] <slangasek> (not that it should matter, from what I saw of the code)
[08:06]  * StevenK checks
[08:06] <StevenK> Hm
[08:06] <StevenK> "unknown user: ubuntu"
[08:06] <StevenK> I suspect this is my own problem
[08:06] <StevenK> Nevermind :-)(
[08:07] <slangasek> mmk
[08:07] <TheMuso> robert_ancell: I actually shipped a .desktop file in the at-spi package to work around the incorrect path given in the gdm wrapper desktop file, thinking that that file would be gotten rid of from gdm.
[08:08] <slangasek> TheMuso: heh; so we can go on ignoring it, I guess
[08:09] <TheMuso> slangasek: works for me.
[08:09] <slangasek> TheMuso: please check that things still work as expected with the latest gdm, in any event :)
[08:09] <TheMuso> slangasek: It doesn't break anything, noting from that desktop file gets started
[08:09] <TheMuso> slangasek: Will do.
[08:10]  * StevenK suspects the initrd he built is broken
[08:18] <ArneGoetje> cjwatson: I just installed Ubuntu from the LiveCD with en_US as target language into a VM. Ubiquity pulled all the language-support and translation dependencies, but at 97% of the installation it purged some of them again together with all the other unused langpacks...
[08:21] <slangasek> ArneGoetje: was there anything in the latest ubiquity that should help there? I don't remember
[08:23] <ArneGoetje> slangasek: it is supposed to call check-language-support and install all the packages it gets fed from there... and it does that. I just don't know why some of those packages get marked for deletion afterwards.
[08:24] <ArneGoetje> slangasek: namely language-support-writing and its dependencies.
[08:28] <slangasek> ArneGoetje: right; no idea then, sorry
[08:29] <slangasek> superm1: do you know if bugs 432660, 447204, 447395, 447413 need reopened on alsa-utils then?  (Bugs that were closed with the -2ubuntu4 upload)
[08:33] <apachelogger> asac: ping
[08:35] <seb128> slangasek, hey
[08:35] <slangasek> seb128: hello
[08:35] <seb128> slangasek, so we are mostly there for GNOME, we still have bug #455900 to fix before rc or karmic
[08:36] <seb128> and I'm not sure dxteam wants an updated notify-osd, MacSlow has been fixing bugs in a karmic bzr apparently
[08:36] <seb128> otherwise I think we are done from the desktop side now
[08:37] <slangasek> seb128: ok, great!
[08:38] <slangasek> seb128: that doesn't include seahorse yet, though?
[08:39] <seb128> slangasek, oh no, waiting news from asac for this one since he wanted to port to xul 1.9.1
[08:39] <seb128> he said he would do that yesterday and upload
[08:39] <slangasek> asac: ping?
[08:41] <slangasek> pitti: hum, no builders currently building karmic on i386 or amd64?  anything that needs looked at there?
[08:42] <slangasek> ah, official builders are all "Building private source"
[08:55] <Laibsch> whois sistpoty
[08:55] <Laibsch> He doesn't seem to be online
[08:56] <pecisk> hi people, if PA wrongly detects my sound card, where in the source I should look at and against what I shall report the bug?
[08:56] <Hobbsee> Laibsch: [18:56] [Notice] -NickServ- Last seen  : Oct 11 14:49:01 2009 (1 week, 1 day, 17:07:04 ago)
[08:56] <Laibsch> quite a while
[08:56] <pecisk> PA wrongly detects my sound card = it doesn't appear in Volume Settings => Output
[08:56] <Laibsch> thanks, Hobbsee
[08:56] <Hobbsee> Laibsch: you're welcome
[08:57] <soren> Laibsch: He was here yesterday.
[08:58] <soren> 16:56:20 *** sistpoty|work n=sistpoty@ubuntu/member/sistpoty has quit ["Back to work, really."]
[08:58] <soren> From yesterday.
[08:58] <soren> (UTC timestamp)
[08:58] <TheMuso> pecisk: What version of Ubuntu are you running?
[08:59] <pecisk> Karmic Koala last updates
[08:59] <TheMuso> pecisk: Hrm ok. Do you happen to have the sl-modem daemon running?
[08:59] <pecisk> TheMuso, not on this computer
[08:59] <slangasek> pecisk: is there more than one user session active on the system, does your session show up in the output of ck-list-sessions, does getfacl /dev/snd/pcm* show your user?
[09:00] <pecisk> TheMuso, there was laptop with sl-modem and there also Karmic didn't show sound card
[09:00] <pecisk> but this is computer ir different matter
[09:00] <pecisk> slangasek, one sec
[09:00] <pecisk> slangasek, there is only one user
[09:00] <pecisk> :)
[09:03] <TheMuso> pecisk: You could try disabling pulseaudio auto-spawning, killing pulseaudio, and restarting it...
[09:05] <slangasek> pecisk: what about the other two questions?
[09:07] <pecisk> slangasek, I can't find getfacl command
[09:07] <pecisk> shall I install something?
[09:07] <slangasek> pecisk: the 'acl' package
[09:07] <soren> Running "getfacl" should tell you this.
[09:07] <pecisk> slangasek, what ck-list-sessions should show?
[09:07] <slangasek> pecisk: your user's session
[09:07] <soren> No command 'getfacl' found, did you mean: Command 'getfacl' from package 'acl' (universe)
[09:07] <pecisk> slangasek, then it shows it so
[09:07] <soren> Or some such.
[09:08] <slangasek> pecisk: ok
[09:08] <pecisk> installing acl...
[09:08] <ogra> soren, it tells you the apt line for copy/paste as well :)
[09:09] <soren> ogra: Yeah, I thought so. It just didn't for me, since I already had it installed :)
[09:09] <ogra> yeah
[09:10] <pecisk> slangasek, getfacl gives me report about all pcm devices and it shows that user:peteris has rw- for all of them
[09:10] <pecisk> in fact
[09:10] <slangasek> ok
[09:10] <pecisk> my scenario here is complicated
[09:10] <pecisk> it shows one device
[09:10] <pecisk> which seems to be part of my multichannel card
[09:10] <TheMuso> Ah, multi-channel card?
[09:10] <slangasek> in that case I'll turn you back over to TheMuso, since we've ruled out consolekit :)
[09:10] <pecisk> yeah :)
[09:11] <TheMuso> pecisk: What card is it?
[09:12] <pecisk> Terratech EWS88MT, uses ice1712 chipset, fully supported
[09:19] <TheMuso> pecisk: Right, theres the problem right there, pulseaudio does not yet deal with those cards very well.
[09:20] <TheMuso> pecisk: And there is already a few bugs filed about it.
[09:20] <TheMuso> pecisk: So if you want to add your voice, feel free to look for bugs relating to ice1712 and pulseaudio.
[09:20] <pecisk> I see
[09:20] <pecisk> old PA didn't have huge problems :)
[09:20] <pecisk> but I see that rather big changes happened
[09:20] <TheMuso> Yeah well a lot has changed for PA in karmic
[09:20] <pecisk> yeah
[09:21] <pecisk> actually how that card detection happens in PA?
[09:22] <TheMuso> pecisk: It uses udev to find the card, but it then uses various channel map profiles to work out how to control the volume/outputs of the card.
[09:22] <TheMuso> pecisk: have a look in /usr/share/pulseaudio/alsa-mixer/
[09:22] <TheMuso> I think users in those bugs have done something to try and get things working.
[09:22] <pecisk> I see
[09:23] <pecisk> ok, I will search LP
[09:23] <pecisk> thanks for the tips :)
[09:23] <TheMuso> pecisk: You're welcome.
[09:23] <cjwatson> ArneGoetje: could I see the log? remember that ubiquity removes things that are in the live filesystem but that it determines aren't needed on the target system
[09:23] <pitti> slangasek: doko moved them to manual yesterday, but this looks like something else
[09:23] <cjwatson> but I may be misunderstanding you, and the log should make it clearer
[09:26] <ArneGoetje> cjwatson: which log file?
[09:26] <cjwatson> /var/log/installer/syslog
[09:26] <doko_> pitti: ?
[09:26] <slangasek> doko_: autobuilders
[09:27] <cjwatson> slangasek: my guess on LaserJock's problem is that he got confused by the fact that the LTSP server option is only available when certain main menu items are selected (it doesn't work on a ubiquity-based install, for instance), but he left IRC so ...
[09:27] <slangasek> doko_: the queue of needs-built packages gets longer, the autobuilders are off doing something else :/
[09:28] <slangasek> cjwatson: oh, interesting
[09:28] <doko_> yeah, another one ...
[09:28] <doko_> # 48 "/usr/include/libvisual-0.4/libvisual/lv_defines.h"
[09:28] <doko_> #define inline inline __attribute__ ((always_inline))
[09:28] <doko_>  /usr/include/c++/4.4/powerpc-linux-gnu/bits/c++config.h:214: error: expected unqualified-id before 'namespace'
[09:29] <cjwatson> one of these days, we'll have build pooling, and will be able to use PPA builds to bolster the distro at times like this
[09:29] <cjwatson> build*d*s
[09:30] <doko_> #if __GNUC__ >= 3
[09:30] <doko_> # define inline                 inline __attribute__ ((always_inline))
[09:30] <doko_>  /* Compiler specific optimalization macros */
[09:32] <slangasek> doko_: bug #446478> this should be deferred, shouldn't it?  Since you ditched the testsuite-only fix
[09:32] <asac> slangasek: seb128: i am doing seahorse now
[09:32] <slangasek> asac: ok, cheers
[09:32] <seb128> asac, thanks
[09:32] <seb128> asac, robert_ancell did the upgrade cf sponsoring queue
[09:33] <ArneGoetje> cjwatson: https://rookery.canonical.com/~arne/syslog
[09:33] <asac> seb128: ok. i can pick it then
[09:33] <ArneGoetje> cjwatson: at the end it removes language-support-en, which removes language-support-writing-en and all dependencies
[09:35] <cjwatson> hmm, check-language-support doesn't output packages you've already installed, does it?
[09:36] <cjwatson> that's the problem - how is ubiquity supposed to know which of the packages it already has installed it should keep?
[09:36] <cjwatson> I think we'll need to add an option to check-language-support to change that
[09:38] <doko_> slangasek: yes
[09:38]  * sivang notes he just bugged sabdfl with some morning chitchat and was gently hinted ubunt  isin the thick of release and wish all devs good luck with the reelase and happy testing on ION Based hardware
[09:39] <slangasek> ArneGoetje, cjwatson: is this bug #452516, effectively?
[09:40] <cjwatson> slangasek: modulo the usual gripes about reopening bugs when the added code doesn't quite work ...
[09:41] <slangasek> cjwatson: though no one seems to have closed that bug ever :)
[09:44] <cjwatson> I thought I did
[09:44] <cjwatson> huh, maybe not, how odd
[09:44] <cjwatson> bug 434173
[09:44] <cjwatson> that's the one I closed; actually, yeah, bug 452516 is different
[09:45] <cjwatson> 452516 is about the fact that we don't have complete language support for *any* language on the CD, and can't, and what to do about that
[09:45] <cjwatson> since it is unsightly to declare that everyone has incomplete language support
[09:46]  * slangasek nods
[09:46] <mvo> lool: http://paste.ubuntu.com/297340/ is probably something you want to add to the debian package
[09:48] <cjwatson> ArneGoetje: I'm thinking http://paste.ubuntu.com/297341/ - what do you think?
[09:49] <cjwatson> also, should we stop including language-support-LL on the CDs, and maybe include language-support-writing-LL or something instead?
[09:50] <cjwatson> hmm, language-support-LL still has interesting dependencies
[09:51] <cjwatson> ArneGoetje: if language-support-LL is still useful, perhaps check-language-support should list it?
[09:54] <lool> mvo: committed; thanks
[09:55] <Riddell> evand: any quick ideas on bug 455580 ?
[10:01] <mvo> lool: thanks
[10:03] <evand> Riddell: looking now
[10:06] <lool> doko_: #455718
[10:07] <doko_> bug 455718
[10:07] <lool> doko_: Looks like xml-apis isn't ship in http://packages.debian.org/sid/all/libxalan2-java/filelist
[10:07] <lool> doko_: So I guess we should explicitely disable the xml-apis target in rules
[10:07] <lool> (in libxalan2-java)
[10:07] <lool> doko_: Do you agree this is the way we want to fix it?
[10:08] <doko_> lool: it is fixed, the gap between the builds was a bit longer than expected
[10:08] <pecisk> TheMuso, found one bug, did a fix suggested in comments, works now
[10:08] <pecisk> thanks
[10:08] <TheMuso> pecisk: great
[10:08] <TheMuso> pecisk: np
[10:09]  * pecisk turns on Keane in full power
[10:09] <slangasek> doko_: it's not fixed, there must be a missing versioned Replaces if you're seeing that error
[10:10] <lool> doko_: I just updated again and I dont get any new .deb
[10:10] <lool> I can add a replace in libjaxp1.3-java
[10:12] <doko_> ahh, I hate <= replaces/conflicts: Conflicts: libxalan2-java (<= 2.7.1-2)
[10:12] <doko_> adding this ...
[10:13] <slangasek> oh, if the conflicts was there, why did it fail
[10:14] <slangasek> ah, we had 2.7.1-2ubuntu1 before, right
[10:15] <lifeless> doko_: what do you think of the idea of a ABI/header split for java packages - with the pom in the -dev
[10:16] <lifeless> doko_: and/or making java binary packages have the 'soname' - the jar version - in the package name, so that multiple versions are able to be installed [to satisfy various maven dependencies more readily]
[10:16] <joaopinto> mvo, is there any support on update-manager to fetch changelogs for packages from 3rd party repositories ?
[10:17] <mvo> joaopinto: not currently, what repos do providem them? we can add it in lucid
[10:18] <joaopinto> mvo, I am still researching on the subject, I would like to provide it for playdeb/getdeb
[10:19] <joaopinto> the archive packages changelogs are extracted during build ?
[10:19] <doko_> lifeless: do you volunteer to implement this?
[10:20] <mvo> joaopinto: right
[10:20] <doko_> we did discuss this at debconf, but for the reason to know when the ABI breaks.
[10:21] <mvo> joaopinto: well, its more complicated during build from LP and later again with a script on changelogs.ubuntu.com
[10:21] <mvo> joaopinto: I guess you could just that script too
[10:21] <joaopinto> I check u-m source, I guess the main issue is how do you setup the changelogs source url from a custom respository
[10:21] <mvo> joaopinto: the goal for lucid is to make it all LP based
[10:21] <mvo> joaopinto: yeah
[10:26] <TheMuso> /c/c
[10:26] <joaopinto> mvo, a grep reveals, both http://changelogs.ubuntu.com/changelogs/pool... and http://launchpad.net/ubuntu/+source/%s/%s/+changelog
[10:26] <joaopinto> LP is the one actively used ?
[10:28] <mvo> joaopinto: the changelogs one, the other is just a fallback, the format is different currently
[10:28] <joaopinto> ok, so an easy way to do it would be to use changelogs.repository_domain.com/ for non ubuntu sources
[10:28] <mvo> joaopinto: but the goal is to switch to LP for the ubuntu ones (but it can/should support different sources if there is a need for this)
[10:29] <joaopinto> there are some enterprise internal repositories which would also like to have this feature
[10:30] <mvo> joaopinto: yeah, that sounds reasonable
[10:31] <mdz> cjwatson: re: bug 455619, just mailed some analysis to the bug
[10:33] <yoritomo> hello all
[10:35] <mdz> slangasek: ^^
[10:35] <cjwatson> mdz: I don't know how much we can do about this; the missing Conflicts was an error, precisely because there were files installed by both packages that didn't cause an error due to Replaces
[10:35] <cjwatson> and that's the error that led to your /usr/sbin/update-grub going missing
[10:35] <mdz> cjwatson: indeed. I guess I'm mostly looking for validation of my hypothesis, so that we have an explanation for what happened
[10:35] <cjwatson> it won't affect jaunty->karmic upgrades, because the conflicts was there in jaunty
[10:35] <yoritomo>  it has a bug with glipper which can't be reported by karmic, it crash everytime starting karmic,  and when i access to the logs i get this error on top on the window http://paste.ubuntu.com/297346/ which logs may i provide to you to fix that problem ?
[10:36] <cjwatson> mdz: your hypothesis is completed by observing the Replaces fields; it seems correct to me
[10:36] <cjwatson> mdz: I would like to see the older apt logs to see why grub-pc was pulled in
[10:36] <joaopinto> hum, evern simpler, just use the repository base url+/changelogs/pool/..., no need for an additional hostname just for the changelogs
[10:37] <mdz> cjwatson: is the conflict bug 410886?
[10:37] <slangasek> asac: your seahorse-plugins upload doesn't include any changes to the build-depends
[10:37] <cjwatson> mdz: that's the bug due to which I noticed the problem, although it was actually about something else
[10:37] <slangasek> asac: --> rejected
[10:37] <asac> slangasek: argh ... gnome control.in i guess
[10:38]  * asac wonders how often he needs to end up in that trap
[10:38] <slangasek> mdz: analysis looks accurate, yes; have seen a couple of other reports of the same :9
[10:38] <slangasek> h:(
[10:38] <seb128> slangasek, pitti: ok, notify-osd for dxteam uploaded
[10:38] <mdz> cjwatson: http://people.canonical.com/~mdz/temp/apt-logs-mizar.tar.gz
[10:38] <seb128> slangasek, I'm done with changes now
[10:38] <yoritomo> nobody interested by that bug ?
[10:39] <seb128> slangasek, there is still a compiz fix coming from mvo before lunch
[10:39] <pitti> seb128: thanks, will review
[10:39] <seb128> slangasek, pitti: we are done for desktop otherwise I think
[10:39] <pitti> seb128: great job with 2.28.1!
[10:40] <seb128> pitti, danke ;-)
[10:40] <joaopinto> mvo, this was already request 3 years ago: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/45129 :P
[10:40] <joaopinto> requested
[10:40] <pitti> seb128: well, we still need seahorse-plugins, no?
[10:40] <mdz> slangasek: cjwatson: mightn't it fix the problem to just make a new grub upload, so that if grub-pc is removed, grub gets upgraded as well and /usr/sbin/update-grub comes back?
[10:40] <seb128> pitti, right, asac is one this one, it has been uploaded and need a quick round because of control.in control
[10:41] <asac> seb128: slangasek: searhorse-plugins reuploaded
[10:41] <yoritomo> ok bye, have a nice day
[10:41] <seb128> pitti, ^
[10:41] <pitti> great
[10:41] <seb128> pitti, oh btw glib gettext change doesn't translate X-GNOME-FullName=
[10:41] <slangasek> mdz: if the new grub also adds a Conflicts to ensure the removal of grub-pc happens first, yes
[10:41] <seb128> which is used in GNOME 2.28 by some programs now
[10:42] <pitti> seb128: oh, we should fix that (for lucid)
[10:42] <seb128> pitti, I don't think it's something we want to address in karmic now?
[10:42] <seb128> ok
[10:43] <slangasek> pitti: ah, you already grabbed seahorse-plugins?
[10:43] <mdz> slangasek: that seems like a simple and safe fix which would avoid the fallout
[10:43] <pitti> slangasek: reviewing notify-osd right now, will still take me some minutes
[10:43] <cjwatson> mdz: yes, probably - I'll do that
[10:44] <pitti> slangasek: I didn't touch seahorse yet
[10:44] <mdz> cjwatson: it looks like I tried updating this system to grub-pc, but it didn't work (due to the error you can see in the bug description)
[10:44] <mdz> perhaps I re-installed grub during the window where it didn't conflict
[10:44] <slangasek> pitti: oh, confused by queuebot's delay :)
[10:44] <cjwatson> mdz: I can't guarantee that it will avoid all fallout, since there may well be a period between removal of grub-pc and upgrade of grub in which update-grub is missing
[10:44] <cjwatson> but I can't think of a sane way to do better
[10:47] <slangasek> asac: why are all these xulrunner/firefox changes only landing now?  GNOME 2.28.1 I was expecting this week, because it wasn't out before, but why weren't these other uploads done last week?
[10:48] <asac> slangasek: the transitional packages?
[10:48] <slangasek> asac: any of it
[10:48] <asac> slangasek: my bad. i wanted to get those RC bugs fixed and once i know that the fixes were good i did this stuff
[10:50] <slangasek> asac: it makes for a very bad day when I have to wait hours longer than expected for FF builds before I can start rolling final ISOs
[10:51] <asac> slangasek: yes, really sorry. i should have uploaded the stuff last night, but i was too tired and did want to do the final review of this upload after sleep
[10:55] <asac> the important fix i needed for xulrunner 1.9 is bug 441552
[10:55] <asac> 1.9.1
[10:57] <Riddell> Keybuk: ubuntu desktop uses usplash still?
[10:57] <slangasek> Riddell: yes
[11:00] <slangasek> asac: xulrunner-1.9 transition package> is that really sensible?  Isn't the whole reason for the different package name that they have differing ABIs?
[11:01] <asac> slangasek: for consumers that use only stable XPCOM components there was no ABI change
[11:01] <slangasek> asac: is that an accurate description of all the reverse-deps of xulrunner-1.9 in Ubuntu? :)
[11:02] <asac> slangasek: no. but now there shouldnt be anything left
[11:02] <slangasek> asac: then why do we need a transition package?
[11:04] <slangasek> asac: transition packages ought to be used only for leaf packages that users will install directly, or for -dev packages that are needed on an interim basis due to a large number of revdeps that need to be transitioned; AIUI, you've already /finished/ the library transition here, so I don't think this xulrunner-1.9 transition package helps us - AFAICS it can only hurt
[11:06] <asac> slangasek: yes. but xulrunner is also a leave package for some users (sorry, had to say that) .... anyway, i trust your feeling on this, if you want me to remove the transitional packages and just upload the fix i can do that
[11:07] <slangasek> asac: I strongly recommend it given the timing, yes
[11:08] <slangasek> asac: rejected current upload
[11:10] <asac> slangasek: ok thx. reuploaded with just the fix. making a removal bug out of the other bug then.
[11:10] <slangasek> asac: thanks
[11:18] <pitti> mvo: the g-c-install upload has a 200 line effective code diff..
[11:19] <pitti> oh, there's some whitespace noise
[11:19] <mvo> pitti: it should be much less and the changes should be pretty striaghtfoward
[11:19] <mvo> let me look at the diff again
[11:20] <pitti> http://pastebin.com/f7c91d8a7 is the effective diff
[11:20]  * mvo nods
[11:21] <pitti> mvo: and string changes..
[11:21] <pitti> -             "• These restrictions do not apply in your country "
[11:21] <pitti> +             "* These restrictions do not apply in your country "
[11:21] <mvo> that one is needed to fix a gettext issue
[11:21] <pitti> (translatable)
[11:21] <mvo> well, work around it
[11:21] <pitti> how so?
[11:21] <mvo> with the • no translation works
[11:21] <mvo> works
[11:21] <slangasek> pitti: you can't have non-ascii in source strings
[11:21] <slangasek> because .po files may be in a charset other than UTF-8
[11:21] <mvo> I did unfuzzy all the strings, it should be fine (and I tested it with german)
[11:22] <pitti> isn't that why .po/.pot have an encoding?
[11:22] <pitti> slangasek: oh, you mean in case in that other charset, the • char isn't representable?
[11:22] <slangasek> pitti: yes
[11:22] <pitti> mvo: unfuzz> ah, ok
[11:22] <slangasek> ascii is the only common charset that gettext can guarantee
[11:23] <pitti> ok, so that's fine, and the whitespace noise is ok, too
[11:23] <pitti> the transient window fix is pretty intrusive and it doesn't seem OMGurgent?
[11:23] <mvo> no, not OMG
[11:23] <mvo> just nice
[11:23] <pitti> mvo: did you test this in different scenarios? (e. g. synaptic running in the background and not)
[11:24] <mvo> i did test, but not this particular case, I can do that now
[11:25] <mvo> pitti: its fine with me if you reject it, I'm sorry for the lateness of the merge :(
[11:27] <mvo> but I think its pretty safe from reading the diff/testing
[11:30] <simon-o> Hi, I'm looking at a package which FTBFS. There is a new upstream version with a "rewritten" build system. Imho it would be the easiest to sync the package from Debian, but I don't know if this is ok, this late in the cycle...
[11:30] <simon-o> http://launchpadlibrarian.net/31810058/buildlog_ubuntu-karmic-i386.givaro_3.2.10-1_FAILEDTOBUILD.txt.gz
[11:31] <ScottK> simon-o: If the current package FTBFS, then we should consider it.
[11:32] <jernst> YokoZar: hello, I just tried your “gnome-exe-thumbnailer” package on karmic and wondered if you noticed the same problem as me : all icons are the same and nautilus says wrestool: file:///home/jernst/Bureau/Firefox%20Setup%203.5.3.exe: no such directory or file
[11:32] <slangasek> asac: heh; firefox-3.0 landed in new because it adds an abrowser-3.0 transitional package, there's never been an abrowser-3.0 before
[11:32] <simon-o> ScottK: Yes it FTBFS, I just tried it with pbuilder. The package from Debian builds fine
[11:33] <YokoZar> jernst: I had noticed it.  I can't figure out why the error is there, because wrestool is definitely available
[11:33] <YokoZar> (it's in icoutils, which is a dependency of teh thumbnailer package)
[11:33] <YokoZar> when i run the thumbnailer script manually from the command line it works fine
[11:34] <slangasek> YokoZar: because something is passing URL-encoded filenames to wrestool as an argument?
[11:34] <YokoZar> slangasek: hmm, that would make sense as some crazy undocumented behavior
[11:35] <slangasek> YokoZar: well, that's what the error message says to me
[11:35] <YokoZar> what's the quick way to convert url-encoding to normal filename
[11:35] <slangasek> use some corresponding g_ function
[11:37] <slangasek> YokoZar: symbol table suggests g_filename_from_uri
[11:37] <jernst> YokoZar: yes that's the problem, wrestool doesn't understand file://
[11:40] <liw> YokoZar, http://library.gnome.org/devel/glib/stable/glib-Character-Set-Conversion.html#g-filename-from-uri
[11:40] <YokoZar> slangasek: that's a C function the thumbnailer is actually a simple shell script :)
[11:47] <YokoZar> hmm, so to fix my shell script I can choose between pulling in glib, crafting something in sed/awk, or 2 lines of python
[11:48] <jernst> YokoZar: I thought about sed awk, seems a little bit too hackish ;-) what 2 lines of python are you thinking about ?
[11:48] <YokoZar> jernst: import urlparse \ print urlparse.urlparse("foo").path
[11:49] <liw> python -c 'import sys, urlparse; print urlparse.urlparse(sys.argv[1]).path' file:///home/liw/README (tested :)
[11:51] <jernst> liw YokoZar : doesn't seem to work with %20 though (file:///home/jernst/Firefox%20Setup%203.5.3.exe)
[11:52] <YokoZar> jernst: so it's not converting %20 to "\ "
[11:52] <jernst> YokoZar:  that's the problem I see yes
[11:54] <liw> is %xx defined for file: urls?
[11:54] <YokoZar> yup urlparse.urlparse.__doc__ says it doesn't expand % escapes
[11:55] <YokoZar> liw: good question, easiest way is to just build a test package and see, heh.  I'll do that now
[11:56] <jernst> liw: nautilus uses %20 for spaces in URI sent to thumbnailers, I can see it here
[11:56] <liw> hm, is one supposed to decode %xx first, and then the rest?
[11:58] <asac> ArneGoetje: lang packs all ok?
[11:58] <asac> ArneGoetje: did the full export happen?
[12:00] <liw> hm, no, can't do %xx separately (silly me)
[12:00] <YokoZar> liw: well how about urllib.unquote
[12:01] <liw> python -c 'import sys, urlparse, urllib; print urllib.unquote(urlparse.urlparse(sys.argv[1]).path)' file:///home/jernst/Firefox%20Setup%203.5.3.exe
[12:01] <liw> YokoZar, yeah
[12:08] <jernst> YokoZar: http://pastebin.ubuntu.com/297380/
[12:08] <jernst> wfm
[12:12] <YokoZar> jernst: heh that's exactly what I wrote (except I used "deurled" for the filename)
[12:12] <YokoZar> I believe we've just discovered the art of synchronous coding
[12:14] <jernst> YokoZar: I guess so ! ;-) by the way thank you for your efforts to better integrate Wine in Ubuntu !
[12:19] <simon-o> ScottK: I filed this as bug 456231.
[12:20] <jernst> YokoZar: do you have already filed a bug for the automatic borders ?
[12:21] <jernst> YokoZar: I was wondering why you don't compose your icon with a transparent background of the correct size to workaround the forced borders instead of using the frame ?
[12:22] <YokoZar> jernst: it's intentional that the icon is small and in the middle, if that's what you mean
[12:23] <YokoZar> but yeah the whole thumbnail is a bit big
[12:23] <YokoZar> although putting transparent borders on it results in other weirdness in nautilus like extra spacing
[12:23] <jernst> YokoZar: you mean you don't want to show only the icon (with maybe a small wine icon) and not the whole window arround it?
[12:24] <YokoZar> jernst: the idea is to show just the programs icon if it's marked executable, and otherwise show it embedded inside a larger (generic) executable container
[12:24] <Keybuk> pitti: random question of the day
[12:25] <YokoZar> the point is to make executable applications (wine .exe, python files, elf binaries, etc) look visually distinct until they've been given explicit execute permissions
[12:25] <Keybuk> you know how bcmwl-kernel-source is on the USB key pool?
[12:25] <Keybuk> how are you actually meant to install that? :p
[12:25] <YokoZar> once they have u+x then they can be presumed trusted and we use their embedded icon
[12:25] <pitti> Keybuk: what's an USB pool?
[12:26] <Keybuk> pitti: you know, on the Live image?
[12:26] <Keybuk> the pool/dists directory and archive
[12:26] <Keybuk> ship seed
[12:26] <Keybuk> etc.
[12:26] <pitti> ah; so, what's the problem with it?
[12:26] <pitti> I wonder why we have it at all, though, it's dependencies should be very heavy
[12:27] <pitti> gcc, make, and all that
[12:27] <Keybuk> well, how do you use it?
[12:27] <jernst> YokoZar: I see
[12:27] <Keybuk> all of the deps are either in the same pool, or already installed
[12:27] <pitti> Keybuk: jockey, or mere apt-get install
[12:27] <Keybuk> I've never known how to *actually* use that key
[12:27] <Keybuk> how?
[12:27] <Keybuk> jockey doesn't appear :)
[12:27] <amitk> tseliot: nvidia update blew up again (identically) http://pastebin.ubuntu.com/297390/
[12:27] <YokoZar> jernst: it would be nice to not have nautilus force the size of thumbnails though
[12:28] <Keybuk> pitti: if you start it from System, all it says is "No proprietary drivers are in use on this system"
[12:28] <pitti> Keybuk: is the USB key archive actually added to apt sources?
[12:28] <Keybuk> pitti: even if it was, it wouldn't work
[12:28] <Keybuk> since the rest of the apt sources will fail
[12:29] <Keybuk> because the driver in that pool is the network card driver ;)
[12:29] <Keybuk> but no
[12:29] <Keybuk> that archive is not in the default sources.list
[12:29] <Keybuk> cjwatson: maybe you know?
[12:30] <pitti> Keybuk: jockey won't display a driver whose package isn't available, so that would explain it
[12:32] <pitti> hm, tricky; I don't think many people woudl appreciate if apt keeps asking them to insert their USB stick instead of just fetching packages from the net; but in this case it would be preferable indeed
[12:34] <cjwatson> Keybuk: it's supposed to be added, can I see the installer syslog?
[12:35] <cjwatson> well, hmm, is it. I think it is, for the moment
[12:35] <cjwatson> whether that's a bug or not
[12:35] <Keybuk> cjwatson: sure, one moment
[12:35] <Keybuk> just doing the reboot to install wl ;)
[12:37] <Keybuk> cjwatson: http://people.canonical.com/~scott/installer-logs.tgz
[12:38] <cjwatson> of course, this is all emergent behaviour, we didn't sit down and think "let's put a pool on the USB stick"
[12:39]  * slangasek chuckles
[12:39] <cjwatson> oh, that's right, now I remember, we disable the cdrom source in sources.list if any other apt sources are present, so that the user doesn't get prompted all the time
[12:39] <steveire> Hey
[12:39] <cjwatson> so in short I have no idea how this is supposed to work automatically, although it's clearly available for manual use
[12:40] <steveire> My laptop is doing its first hard drive check since I installed the beta
[12:40] <steveire> It doesn't give any progress at all anymore.
[12:40] <Keybuk> cjwatson: how do I do it manually? :p
[12:40] <steveire> No 33% done or anything
[12:40] <Keybuk> steveire: I *just* uploaded the fix for that ;)
[12:40] <steveire> Keybuk: Cool.
[12:40] <cjwatson> Keybuk: fiddle sources.list?
[12:40] <Keybuk> cjwatson: 'cos basically I just run dpkg -i on the mentally expanded bunch of packages I know I need :p
[12:40] <Keybuk> cjwatson: I'd have to comment out all the archive things, no? :p
[12:41] <cjwatson> is that actually still true? I know it whines ...
[12:41] <Keybuk> cjwatson: it appears to fail currently
[12:41] <YokoZar> steveire: is it ext4?
[12:41] <slangasek> chrisccoulson: was there any more information you need from me on bug #447431?
[12:42] <cjwatson> Keybuk: obviously there are tricks you can pull with temporary sources.list files and such, but personally I'd just comment out the other lines
[12:42] <steveire> YokoZar: I don't remember. How do I check?
[12:42] <YokoZar> Whomever the fast archive admin was that just approved gnome-exe-thumbnailer after I uploaded it 2 minutes ago thanks :)
[12:42] <steveire> fdisk -l doesn't tell me
[12:43] <Keybuk> cjwatson: it's easier to just install it manually
[12:43] <Keybuk> *but*
[12:43] <Keybuk> since the whole point of *having* bcmwl-kernel-source there is so people can actually get their wireless working
[12:43] <Keybuk> shouldn't this be much easier in general?
[12:44] <cjwatson> it definitely should; until you just described this problem now, I didn't know it was difficult
[12:44] <cjwatson> Michael's dynamic cdrom patch to apt should help a lot
[12:44] <cjwatson> since that will make it possible to have 'deb cdrom'-type things in sources.list without having to worry about changing device names
[12:45] <chrisccoulson> slangasek - i'm a bit confused about the trace actually. unless i'm misunderstanding something, "minor_code 7" corresponds to "XRRSetScreenSize", although perhaps i'm confused about what the minor_code really represents
[12:46] <steveire> It was ext3
[12:46] <chrisccoulson> anyway, if i understand minor_code correctly, then the trace is still running asynchronously. that might be because this is code loaded from a plugin, and perhaps the "--sync" option has no effect there (ie, XSynchronize is never called on the display connection)
[12:46] <steveire> Although I think it also checked a different ext4 partition at the same time which also gave no feedback
[12:47] <chrisccoulson> i need to ask on #ubuntu-x really
[12:47] <slangasek> chrisccoulson: eh?  the plugins are separate X clients?
[12:47] <cjwatson> steveire,YokoZar: doesn't matter which filesystem was in use anyway, usplash integration was just missing in the new mountall package
[12:47] <cjwatson> as Keybuk said, fixed now
[12:47] <YokoZar> ahh ok
[12:48] <YokoZar> I thought there might have been a chance it just wasn't shown for ext4 since it was fast enough
[12:50] <slangasek> chrisccoulson: I can confirm your understanding of the minor code, though
[12:50] <chrisccoulson> slangasek - i don't think they are separate X clients. but the information about whether it runs synchronously or not is stored client side in the Display structure (i think), which might not be shared between plugins
[12:51] <slangasek> chrisccoulson: hmm, that would be weird
[12:51] <chrisccoulson> i'm just going to have a quick look at the xlib code, perhaps i'm misunderstanding it
[12:56]  * Riddell hugs evand 
[12:56] <evand> :)
[13:00] <cjwatson> dpm: would you mind sorting out bug 363990 in LP and letting the translator know about the problem? it's the same as bug 409785, except for Hebrew
[13:00] <cjwatson> I'm annoyed that msgfmt --check-format doesn't catch this
[13:00] <dpm> cjwatson, sure, on it
[13:01] <cjwatson> I've checked other languages, it's just Arabic and Hebrew
[13:02] <slangasek> bwuh, seriously, msgfmt --check-format doesn't catch that?  are the strings properly marked as format strings?
[13:03] <cjwatson> yes, python-format
[13:03] <cjwatson> I think it gets confused by plural forms
[13:03] <cjwatson> or else its python-format handling sucks, I haven't checked ...
[13:03]  * slangasek nods
[13:05] <tseliot> amitk: let's see if doko knows what happened
[13:05] <tseliot> doko: http://pastebin.ubuntu.com/297390/ (see the end of the file)
[13:05] <tseliot> doko_: any ideas??
[13:06] <doko_> tseliot: look at the sanity check
[13:07] <tseliot> doko_: but reinstalling the nvidia package fixes it, right amitk?
[13:08] <tseliot> which is weird
[13:11] <Keybuk> not for the first time, I think we should generate a quiet noise on the sound card when there's hard-drive activity for SSD
[13:20] <evand> haha
[13:27] <amitk> tseliot: not this time. It didn't fix it with a reinstall
[13:28] <tseliot> amitk: maybe try reinstalling the compiler instead. As doko said, the CC sanity check failed
[13:28] <tseliot> well, as the dkms log said ;)
[13:35] <amitk> tseliot: my compiler seems to work (just tried compiling some trivial programs)
[13:35] <tseliot> doko_: ^^
[13:37] <amitk> tseliot: in any case I've filed bug 456240
[13:37] <tseliot> amitk: ok, thanks
[13:46] <zul> asac: ping
[13:46] <dpm> ArneGoetje, re: bug 363990 and bug 409785, I see in the template's admin page that language-selector still has the checkbox for using language packs checked. If I understand it correctly, this will override cjwatson' fix, since the language pack translations will be used instead of the package's ones, won't they?
[13:47] <asac> zul: hi
[13:47] <asac> zul: .symbols?
[13:47] <zul> yep
[13:47] <asac> zul: what info do you need?
[13:48] <zul> how to do it basically
[13:48] <asac> zul: cdbs?
[13:48] <asac> zul: DEB_DH_MAKESHLIBS_ARGS = -- -c4
[13:48] <asac> and add an empty .symbols files for your lib
[13:48] <zul> that it?
[13:48] <asac> i think that should make it fail and dump a patch with the symbols that you need to put in there
[13:49] <asac> remember to remove the ubuntu revisions from the versions it chooses
[13:49] <zul> ok thanks
[13:49] <asac> zul: for cdbs thats it. yes.
[13:50] <hadess> asac: way to work upstream
[13:50] <hadess> asac: you were waiting until when to send me those gnome-bluetooth patches?
[13:50] <seb128> lol
[13:50] <asac> hadess: until i have time to argue
[13:50] <asac> hadess: i will rebase and submit the rest
[13:50] <seb128> I was ready to bet that was going to happen ;-)
[13:51] <seb128> hadess, you know by being aggressive on bug reports etc you don't invite people are quickly drop a change your way
[13:51] <asac> hadess: actually, i try to be a good upstream citizen :)
[13:52] <hadess> seb128: aggressive on bug reports?
[13:52] <seb128> hadess, and getting things nicely described in proper format etc can take a bit you don't always have when you are in a hurry
[13:52] <hadess> asac: why do you ship 4 or 5 non-upstreamed patches?
[13:52] <asac> hadess: for networkmanager for instance, i didnt add a single patch this cycle
[13:52] <seb128> hadess, you tend to rant when the patch is not using proper git format, or the description lacks something you would have wanted to see there, etc
[13:53] <hadess> seb128: you must have me confused with somebody else
[13:53] <seb128> hadess, that's probably it
[13:53] <hadess> seb128: i rant like that on shared-mime-info bugs, because there's a lot of work to be done on whatever reports we get
[13:54] <hadess> and it's funny that i seem to have no problems working with other people either...
[13:54] <hadess> anyway, i'm waiting for your updated patches
[13:54] <asac> hadess: it was a deadline thing. usually i submit everything while doing. this one is an exception
[13:55] <hadess> sconklin: what's up
[13:55] <seb128> hadess, I don't think I've problem working with you, I just said I would not add a patch in a hurry on something you maintain
[13:55] <seb128> hadess, you expect the submitter to do his side of the work which is fair but can take a bit
[13:55] <sconklin> hadess: hi! it's been awhile, good to see you again
[13:56] <asac> hadess: one reason also is that i did them after the .1 release - and i didnt think there would be a new .2 before we release so i lowered prio on that
[13:56] <asac> hadess: will do better and give you the rest asap, ok?
[13:56] <hadess> seb128: don't you think it would be better if you upstreamed the patch and marked it as needs-work instead of holding it back?
[13:57] <asac> thats a mood point imo. nobody is holding patches back here. really
[13:58] <jono> hadess, how do you feel the patches should be provided?
[13:59] <hadess> asac: whether you were holding them back on purpose or not isn't the point
[13:59] <jono> it seems that they were not purely because of time constraints
[13:59] <jono> this just seems a miscommunication
[14:01] <asac> in this case it was clearly a time constraints ... i did them as a side-job while working on other stuff
[14:02] <hadess> asac: and now you're going to have a hard time rebasing them
[14:02] <asac> hadess: yes, thats the pain i bought by not following up
[14:02] <hadess> given that a good bunch of patches went in upstream
[14:03] <jono> maybe a middle ground is for asac to just make his raw patches available and then rebase them when things are easier time-wise
[14:03] <jono> particularly as we are a week from release
[14:03] <jono> would that be acceptable, hadess?
[14:04] <asac> thats what we do now ;)
[14:04] <jono> thats what I originally thought
[14:04] <hadess> asac: the problem is that you didn't do that...
[14:05] <jono> hadess, can you think of a better solution, given the time constraints asac is talking about?
[14:05] <slangasek> of course the raw patches are available
[14:05] <asac> hadess: this one slipped through as release times are overly busy  ... more i cant say ... except that i am sorry
[14:05] <asac> though i am not really sorry ;)
[14:05] <asac> just see that we can work better together in future
[14:06] <dholbach> pitti, slangasek: can we sync mootools from Debian? it'll make phpmyadmin installable again
[14:07] <jono> hadess, would you be happy to be a little more patient with things, due to the release?
[14:07] <dholbach> pitti, slangasek: do I need to go through all the release/archive-admin stuff?
[14:07] <pitti> dholbach: any package that will go on DVDs or CDs can't right now
[14:07] <pitti> we could sync it after RC
[14:07] <hadess> jono: we have a release too, and i make a point of making upstream releases for all the distros
[14:08] <pitti> dholbach: it would be better to have an RC bug for that, so that we can do it after RC and not forget
[14:08] <jono> hadess, I agree, I just don't really know what the solution is when the problem is lack of time
[14:08] <jono> brb call
[14:08] <dholbach> pitti: hm? it's in universe
[14:08] <pitti> dholbach: mono-tools is main
[14:08] <dholbach> pitti: mootools!
[14:08] <dholbach> :-)
[14:08] <asac> hadess: this was one of the things that i also didnt have in mind. i always thought fedora releases 3 weeks or so after us ... just found out that you planned to release on 31st yesterday
[14:08] <pitti> dholbach: oops :)
[14:08] <asac> while talking to dcbw
[14:08] <pitti> dholbach: ah, iti's a new package
[14:08] <dholbach> yep
[14:08] <hadess> asac: this isn't a fedora vs. ubuntu thing
[14:09] <hadess> asac: this is me being pissed off as upstream for a lot of packages
[14:10] <asac> hadess: ok, if its not just gnome-bluetooth i would like to help as good as i can.  if you want i can through whatever package you are upstream for and discuss all patches with you etc. ...
[14:10] <pitti> hadess: understandable, but pretty much all distros (including Fedora) have shipped patches for years, so I don't see why you particularly pick on asac now when he sends a patch two days later..
[14:11] <asac> hadess: is there a list of packages we should look at?
[14:12] <hadess> pitti: because i've spent time fixing the exact same bug he did because he didn't send them upstream
[14:13] <hadess> and i'm pretty sure his patches aren't enough to fix the problems either...
[14:13] <pitti> so in the future, would it be a compromise to give a quick followup on the upstream bug "I have a fix for this, will send in two days"?
[14:13] <asac> hadess: right. as i said above. i thought there was no way you would do a .2 release - that was the misjudment that led me to lower the upstreaming prio a bit, which made this fall off from radar and duplicated work.
[14:13] <asac> shit happens
[14:13] <pitti> so that you at least know about it?
[14:13] <hadess> asac: why didn't you ask me instead?
[14:13] <asac> hadess: instead of what?
[14:14] <asac> instead of misjudging?
[14:14] <hadess> pitti: that would certainly be better, although stuff like git-bz makes it easy to upstream patches
[14:14] <dholbach> pitti: need a bug for mootools?
[14:14] <hadess> asac: instead of not asking...
[14:14] <pitti> dholbach: at it now
[14:14]  * dholbach hugs pitti
[14:14] <asac> hadess: i havent use git-bz ... i guess that would have helped me to not not upstream them instantly. will check that out. tahnks
[14:14] <dholbach> rebooting - brb
[14:15] <hadess> asac: git bz file gnome-bluetooth general <commit-ids>
[14:15] <asac> hadess: asking failed because of the time-constraint thing i talked about. i did this in a night shift to meet some deadline together with other stuff.
[14:15] <asac> hadess: thanks. do i need to setup password?
[14:16] <hadess> asac: no, you do that from your git tree, and it will read your cookies from the browser
[14:16] <asac> cool
[14:16] <asac> good to know
[14:16] <asac> hadess: so moving forward: i rebase stuff and give the rest to you. and in future i just submit all patches using git bz ;) ....
[14:16] <asac> hadess: if you want me to help you on the other packages you are upstrewam for feel free to ping me
[14:17] <asac> deal?
[14:17] <hadess> asac: gnome-user-share, nautilus-sendto, shared-mime-info, totem, totem-pl-parser, rhythmbox, gvfs
[14:19] <pitti> gvfs> our patches are either applied in git or in bz (and were sent there even before uploading)
[14:20] <pitti> so that should be clear (I'm keen myself to keep it patch free)
[14:20] <hadess> pitti: good
[14:21] <fatal^> talking about patches.... http://patches.ubuntu.com doesn't seem to be very up to date anymore... are there some other place to look for patches?
[14:21] <pitti> hm, merge-o-matic seems to not run any more?
[14:21] <pitti> fatal^: looking for a particular package?
[14:22] <slangasek> pitti: correct; I asked out loud about this a couple weeks ago, nobody admitted responsibility
[14:22] <slangasek> (and the page lists no contact information)
[14:22] <fatal^> pitti: not really.... I usually dig stuff out of the packages themselves, but it'd be nice if there was a more convienient way.
[14:22] <cjwatson> Keybuk and doko are the contacts for merge-o-matic, AFAIK
[14:22] <pitti> fatal^: for packages which we have in revision control, it's usually easier to pick them off the web UI
[14:23] <fatal^> pitti: what's the url for that?
[14:23] <pitti> fatal^: e. g. for gvfs: http://bazaar.launchpad.net/%7Eubuntu-desktop/gvfs/ubuntu/files
[14:23] <pitti> -> debian/patches
[14:23] <fatal^> thanks
[14:24] <pitti> fatal^: https://code.launchpad.net/~ubuntu-desktop/ has all the GNOMEish packaging branches
[14:26] <Keybuk> drwxrwsr-x  2 merge merge       4096 2009-09-10 13:05 .lock
[14:26] <Keybuk> huh
[14:26] <Keybuk> it's running
[14:26] <Keybuk> oh
[14:26] <pitti> stuck perhaps? running for over a month?
[14:26] <Keybuk> yeah, read that date the wrong way round ;)
[14:26] <Keybuk> right, it was locked out
[14:27] <Keybuk> looks like IS locked it out after a reboot but then never re-enabled it
[14:27] <Keybuk> BAD IS
[14:27] <Keybuk> (given nick is in wtmp at that time ;p)
[14:32] <EtienneG> happy 5th anniversay of Ubuntu to everyone!
[14:39] <dholbach> thanks pitti
[14:39] <dholbach> paulliu, lool: glad to see the moblin bits are in
[14:40] <lool> dholbach: We're going to close the remaining syncs as it's too late for them to be processed
[14:40] <lool> (too risky)
[14:40] <lool> we'll just live with what we have now
[14:41] <dholbach> hm, they're in universe and new packages - it's not like they'll cause regressions
[14:42] <paulliu> dholbach: the problem is.. OEM team have to update moblin stuff before this week. So I've done it in Debian unstable first. If we sync those packages to too new versions we'll break.
[14:42] <dholbach> ok
[14:51] <hadess> asac: and i fixed more killswitch bugs and did another release just to spite you...
[14:52] <kirkland> slangasek: erg, yes, probably it was missing an FFe.  I see it's been approved now.  Basically, the previous version we had was DoA (sync'd from Debian mentors in the interest of getting more testing on Karmic).  Finally, lucas just uploaded a working version to Sid.  I just figured it was worth a shot trying to sync that to Karmic.  If it was declined, I wasn't going to complain.
[14:54] <slangasek> kirkland: "If it was declined" - cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-October/000634.html
[14:55] <slangasek> kirkland: it's assumed that universe packages that have been uploaded are supposed to be there
[14:56] <kirkland> slangasek: thanks
[14:56] <slangasek> well, that means I noticed it because it generated a bunch of sudden NBSes and needed NEW processing :)
[15:00] <asac> hadess: ok. not sure why you have to spite me though ... if it helps ;)
[15:00]  * asac on a call now
[15:00] <hadess> asac: that was supposed to be a joke
[15:01] <hadess> asac: but i'm pretty sure that your patches aren't enough to fix the bugs i just fixed
[15:01] <asac> ok thanks. will check out what you did and see if there is anything left to rebase
[15:02] <superm1> slangasek, well for some of those bugs, the behavior was already reverted in ubuntu5.  i'll check with dtchen as for what he expects for the others
[15:03] <slangasek> superm1: ok, thanks
[15:11] <free> pitti, mathiaz: hi, bug #444743 is still not fixed, any blocker for the acceptance of the smart SRU in intrepid-proposed (see also bug #347983)
[15:12] <free> ?
[15:14] <mathiaz> free: it's in the unapproved queued: https://launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=
[15:14] <mathiaz> free: waiting on the ubuntu-sru team to review the change
[15:14] <free> mathiaz: I see, thanks for the pointer
[15:15] <LaserJock> cjwatson: so it seems like the F4 menu misses several options on the Edubuntu DVD and I think on the Ubuntu DVD as well
[15:15] <LaserJock> cjwatson: the .seed files are present and the gfxboot.cfg has entries, but the menu options don't appear in the end
[15:16] <cjwatson> LaserJock: did you remember to select "Install in text mode" or whatever it is before pressing F4?
[15:16] <cjwatson> LaserJock: the options in gfxboot.cfg, inc. LTSP, only apply to certain main menu items
[15:16] <LaserJock> ohhhhhh
[15:16] <cjwatson> if you press F4 directly at boot, you'll get those options suitable for the selected main menu item
[15:16] <LaserJock> bah
[15:16] <LaserJock> I'm an idiot
[15:16] <LaserJock> let me go verify
[15:17] <dtchen> superm1: in terms of alsa-utils, they're fine at Fix Released; they may need separate tasks for pulseaudio, etc.
[15:18] <LaserJock> cjwatson: yep it's there, I'm an idiot
[15:18] <dtchen> siretart: that's probably a good idea
[15:18] <LaserJock> although it's not necessarily intuitive that the menu would be context sensitive
[15:19] <superm1> dtchen, so does pulseaudio at some point call alsactl store?
[15:20] <superm1> it's not clear what that flag is still used for since the pulseaudio stuff was reverted from ubuntu4 to ubuntu5
[15:21] <cjwatson> LaserJock: I'm not entirely certain it's intuitive, but OTOH I'm not certain how it could be done better :) anyway it's not unique to Edubuntu
[15:21] <LaserJock> cjwatson: no, and we can document it
[15:22] <LaserJock> cjwatson: once you realize what it's doing, it's actually rather nice
[15:22] <LaserJock> cjwatson: we wouldn't want people selecting LTSP and Ubiquity at the same time
[15:22] <dtchen> superm1: err, there shouldn't be any flag at all, and no, PA doesn't invoke alsactl store, though it does sync its ctl status with ALSA's hw ctl status
[15:22] <dtchen> superm1: perhaps I'm confused about which flag you're referring to?
[15:23] <superm1> dtchen, http://pastebin.com/f7f047be9
[15:25] <pitti> free: sorry, will catch up on SRUs after TB meeting; last week was a bit crazy due to karmic release
[15:25] <dtchen> superm1: that flag isn't used anymore; it's not even present
[15:25] <superm1> dtchen, well your upstart changes that backed it out were not accepted this late, not sure if you saw that
[15:26] <superm1> so this is the smaller delta to back out just that flag stuff
[15:26] <dtchen> superm1: yes, I'm aware. In the current ubuntu6, it's fine as-is.
[15:28] <superm1> dtchen, ah i didn't realize that got pulled out of unaccepted already - that's my mistake.
[15:29] <superm1> so what's the best approach to ensure that those other bugs closed from ubuntu4 and ubuntu5 don't see regressions from this?
[15:31] <ccheney> shtylman: thanks
[15:33] <dtchen> superm1: they won't AFA alsa-utils is concerned. Any problems must be in pulseaudio.
[15:33] <superm1> dtchen, okay thanks
[15:45] <slangasek> smoser: should we post the 20Oct uec build as an RC candidate?
[15:47] <smoser> slangasek, i think so. http://uec-images.ubuntu.com/karmic/20091020/
[15:47] <smoser> slangasek, but i did just now tag bug 407949 as targetted to karmic
[15:49] <smoser> slangasek, i need guidance on exactly how much grief there will be for requesting that change (possibly post RC if we choose to use the ones there).
[15:49] <smoser> the source change is very trivial
[15:49] <slangasek> smoser: I've cleaned up the make-web-indices integration for uec overnight; does http://uec-images.ubuntu.com/karmic/20091020/unpacked/ now look the way you think it should, is anything missing?
[15:50] <smoser> http://pastebin.com/f35e24c27
[15:50] <smoser> that has patch
[15:50] <ccheney> slangasek: i will need to do another upload (if possible) for bug 452518, just got the patch last night, what do you think about when to do it? as an update or directly after RC, etc?
[15:50] <slangasek> smoser: the next step is that I'm going to try to integrate populating the "EC2 published AMIs" table from a text file
[15:51] <ArneGoetje> cjwatson: language-support-LL just pulls in the other language-support-{fonts|input|writing}-LL packages if available. This one exists only for upgrading. Language-selector won't install that package anymore, but the other language-support-{fonts|input|writing}-LL packages directly when the corresponding checkboxes are checked.
[15:52] <slangasek> ccheney: how long does an OOo build take on armel these days?
[15:53] <smoser> slangasek, so one thing to note is that as it is right now, the publish to ec2 occurs after checksum-dir is run
[15:53] <ccheney> slangasek: last build took 18 hours
[15:53] <james_w> ogasawara: hey, is the "ECC is not currently enabled in the BIOS" bug pattern needed due to kerneloops?
[15:53] <ccheney> slangasek: oh no, 1 day 19 hours
[15:53] <ccheney> slangasek: misread when it finished
[15:53] <ttx> smoser: about bug 407949 > you nominated for karmic in "Ubuntu on EC2" project, not "Ubuntu", want me to fix that ?
[15:53] <jdong> out of curiousity, what are the armel builders? Real ARM systems or some sort of emulator?
[15:53] <ogasawara> james_w: it is
[15:54] <slangasek> ccheney: yeah, no way that's going in in time for RC.  If the kubuntu folks think this is urgent to have before release then we can shove it in after RC, otherwise SRU
[15:54] <james_w> ogasawara: does it need to be a WARN_ON in the code?
[15:54] <ccheney> slangasek: ok
[15:54] <smoser> ttx, yeah. please.
[15:54] <ogasawara> james_w: I'd need to check
[15:54] <james_w> ogasawara: I would think that would be a better way to avoid the message
[15:54] <ogasawara> james_w: agreed
[15:54] <james_w> granted, it may not be the best way to do it at this point
[15:54] <slangasek> smoser: I don't see a reason that it needs to be done in that order?
[15:55] <ccheney> Riddell: opinions of when to do bug 452518, it causes files to be saved in the wrong format and in the instance of the bug report not save certain types of data in the file (apparently saved in a really old version of the format)
[15:55] <ogasawara> james_w: I'd consider it a bandaid for now
[15:55] <james_w> but to stop users getting that every boot just to be told "you can't report this" would be good
[15:55] <james_w> ogasawara: thanks for being on top of it :-)
[15:55] <Riddell> ccheney: after RC (Thursday afternoon) would be good then
[15:56] <ccheney> Riddell: ok
[15:56] <smoser> slangasek, it is just how it is right now. a build happens, and then another cronjob notices that there is a new build that isn't published.
[15:57] <slangasek> smoser: do we care about having the daily build pages link to EC2 AMIs though, or do we only care for milestones?
[15:57] <ArneGoetje> dpm: language-selector translations should not go into langpacks, no. I remember I have disabled theat before... no idea who enabled it again.
[15:58] <smoser> slangasek, i think it would be nice if they did. so if we can make the header "generate header" such that it can be called once, and then again later , that would be really nice.
[15:59] <smoser> the "again later" would just be when the publish-to-ec2 had finished. i could have it call the generate header, which would pick up the published-ec2-nightly.txt
[16:00] <slangasek> smoser: in that case, I think it would make more sense to integrate it into a single cronjob
[16:00] <siretart`> dtchen: I just wonder, since kubuntu doesn't use pulseaudio, wouldn't that break libao application under kde?
[16:01] <ScottK> ccheney: Yes please (on fixing that).  I had that bug, but the doc in question wasn't one I could attach to a bug report.  Fixing that would be huge.
[16:02] <pitti> free: done now
[16:02] <slangasek> ogasawara: could the weather report pick up http://uec-images.ubuntu.com/karmic/current/karmic-uec-{amd64,i386}.manifest?
[16:02] <free> pitti: awesome! thanks
[16:02] <ogasawara> slangasek: yup, gimme a minute and I'll get it updated
[16:02] <pitti> free: sorry for the delay
[16:02] <slangasek> ogasawara: thanks!
[16:02] <ccheney> ScottK: ok
[16:02] <free> pitti: np
[16:03] <smoser> slangasek, so you'd want the cronjob that did the build to finish only when build and publish and HEADER generation were done
[16:03] <slangasek> smoser: yes
[16:04] <smoser> i dont know why i dont like that :)
[16:04] <slangasek> smoser: since each action is really dependent on the earlier actions anyway, there's not much point to having separate cronjobs... that just introduces a race condition
[16:04] <slangasek> I don't know either :)
[16:04] <smoser> but it would not be that hard to integrate it.
[16:04] <smoser> there isn't a race condition
[16:05] <smoser> the last thing done is 'link current' and the watcher only looks at current
[16:05] <dtchen> siretart`: yes, that's why many of these settings were left at 'alsa'
[16:05] <dutchie> is there an official opinion re: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/404435?
[16:05] <slangasek> smoser: well, that's still a race in the sense that if the latest build hasn't finished yet, you get the old one published instead
[16:05] <dutchie> (specifically https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002752.html)
[16:06] <dtchen> siretart`: in light of release, it doesn't make sense to bump it; I don't know of any libao apps that break because 'alsa' is used
[16:06] <smoser> slangasek, well, thats covered. i will admit to a sub-second race condition, though.
[16:06] <smoser> the race you're  mentioning is not an issue though.  the publisher script marks that its working on a dir with the $(readlink -f dir) name. and marks that it finished that also.
[16:07] <smoser> i can take your suggestion to wrap it all up
[16:07] <siretart`> dtchen: sure. I'm not going to touch it, but rather wanted to confirm my understanding of the issue here
[16:07] <smoser> then the output will have publish-nightly-ec2.txt in it when you take over
[16:08] <ArneGoetje> asac: mozilla looks translated to me, however it reports the version of the translations as 3.5.2 although I uploaded 3.5.3 already into Rosetta.
[16:08] <smoser> slangasek, should we sign published-ec2-nightly.txt ?
[16:08] <slangasek> smoser: I don't think that matters
[16:09] <smoser> it contains the ids.
[16:09] <smoser> a tampering with that file could allow someone to get their amis run appearing to be ours
[16:10] <slangasek> smoser: except people are generally grabbing them from the header anyway, which isn't signed
[16:10] <slangasek> if they're concerned about it, they can go directly to the AWS website, no?
[16:10] <slangasek> indeed, we give them links right to the site
[16:10] <smoser> they can definitely verify that 'canonical' published an image
[16:11] <ScottK> Is the site https?
[16:11] <smoser> so, slangasek, you can assume then that when a build finishes the output looks like it does for 20091020
[16:12] <slangasek> smoser: ok, great
[16:12] <smoser> it is not, but s/http/https/ works. so we should do that.
[16:13] <smoser> slangasek, what script are you running ?
[16:13] <slangasek> smoser: for what part?
[16:13] <ScottK> smoser: I worry that without https and an appropriate cert, DNS cache poisoning attacks could still be used to give people wrong images.
[16:14] <slangasek> smoser: for the header generation, it's make-web-indices - I've added a call to build-ec2-image
[16:15] <smoser> ScottK, you're correct. so we absolutely should change the link to use the https
[16:15] <smoser> right? that would calm your concerns ?
[16:15] <smoser> its just a matter of 's/http/https/'
[16:15] <ScottK> smoser: With an appropriate cert, I think so.  I'd ask kees to make sure
[16:17] <kees> smoser: https with a valid cert is fine
[16:17] <kees> smoser: that may need IS support, though, since www.ubuntu.com isn't https
[16:18] <smoser> ah.
[16:18] <smoser> sorry, i missed the point of ScottK's objection.
[16:18] <smoser> the uec-images is not https available with valid cert. the amazon site is.
[16:19] <pitti> ogra, lool: oh, how come that UNR is just 680 MB nowadays? I thought it was almost 1 GB before
[16:19] <ogra> pitti, .iso restriction
[16:19] <ScottK> smoser: Do you have it now?
[16:19] <pitti> ogra: I thought it was supposed to be just installed from USB sticks
[16:20] <ogra> not anymore, since karmic it should be installable from CD as well
[16:20] <smoser> yes. i see what you were saying. and i dont hav ea solution for 'uec-images.ubuntu.com' is not https
[16:20] <ogra> there was apparently demand
[16:23] <pitti> mat_t: bdmurray_ says that the beep on the mini 9 is gone with yesterday's live images; can you confirm on current karmic?
[16:23] <mat_t> pitti: thanks, will try to confirm it later today
[16:23] <mat_t> pitti: will let you know!
[16:23] <mat_t> :)
[16:23] <pitti> mat_t: cheers
[16:23] <bdmurray_> mat_t: also in alsamixer there is a beep option which might be the cause
[16:24] <mat_t> bdmurray_: ok, I'll check it out, thanks1
[16:24] <mat_t> !
[16:25] <ogasawara> slangasek: ok, uec should be on the weather report now
[16:26] <slangasek> ogasawara: thanks
[16:28] <lool> pitti: We switched to ISO and went to make sure it fits the 700 MB bill
[16:28] <lool> pitti: As some people even run it on regular laptops
[16:29] <pitti> lool: nice; how painful was that? (I'm just curious)
[16:29] <lool> Since UNR is supposed to have a lighter stack, it made sense to target 700 MB
[16:29] <pitti> it's nice to be able to download/rsync it much faster now
[16:29] <lool> pitti: For some reason it wasn't too bad; after I cleaned up the seeds to match the desktop we were already in the same zone, usually a bit higher than desktop; not sure why we're doing so good (it's suspicious!)
[16:29] <lool> We did drop things like openoffice help IIRC
[16:30] <lool> We miss things like brasero or the VNC stuff
[16:30] <lool> xsane
[16:30] <lool> and gimp and gdm-guest-session
[16:30] <lool> I bet gimp saves us a lot
[16:31] <lool> pitti: Basically excluding things which were expected to be unusable on the typical netbook made a big difference I guess
[16:33] <pitti> lool: makes sense; thanks for the heads-up!
[16:33] <pitti> lool: gimp is 6 MB (without documentation), but with docs it's like 20
[16:33] <pitti> but indeed it doesn't make much sense to have by default on a netbook
[16:35] <lool> pitti: I suspect gimp pulls a bunch of things
[16:35] <lool> At some point it even pulled webkit  ;)
[16:36] <pitti> you managed to keep webkit off the image? nice
[16:37] <dholbach> Keybuk: did you get anywhere with the vserver people?
[16:38] <Keybuk> dholbach: they made a karmic template that worked for them
[16:38] <dholbach> oh, is that documented somewhere?
[16:38] <dholbach> do you think we should get it into the release notes?
[16:39] <Keybuk> I'll defer to slangasek on that one
[16:41] <smoser> slangasek, so did we leave that you would put the ami from http://uec-images.ubuntu.com/karmic/20091020/published-ec2-nightly.txt into iso tracker ?
[16:41] <lool> pitti: Oh no we did not
[16:41] <lool> pitti: I mean gimp is a hog
[16:42] <Keybuk> dholbach: certainly you can't upgrade a current vserver to karmic
[16:42] <Keybuk> you have to start over with a new template
[16:42] <lool> webkit is pulled by empathy so no luck there
[16:42] <dholbach> Keybuk: ugh
[16:42] <slangasek> dholbach: yes; can you open a bug on the ubuntu-release-notes project and suggest some text?
[16:42] <Keybuk> (unless you can switch templates? I don't know much about vserver)
[16:42] <slangasek> smoser: I think so?
[16:42] <Keybuk> dholbach: you have to change your vserver to be one that actually has an init daemon
[16:42] <dholbach> slangasek: no, I can't - I have no clue about how it gets fixed
[16:43] <Keybuk> - then you need to disable things like /etc/init/udev.conf, /etc/init/mountall.conf, etc.
[16:43] <dutchie> is there an official opinion re: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/404435?
[16:43] <dutchie> (specifically https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002752.html)
[16:43] <Keybuk> - and you need an /etc/init/vserver.conf that has initctl emit lines for the events that mountall makes
[16:43] <dholbach> Keybuk: right, so the text should advise people to get in touch with their ISPs and restart the servers afterwards
[16:43] <lool> dholbach: moblin remix is built from universe + ppa; if we push a version which forces a library transition on us, we're screwed
[16:43] <smoser> slangasek, so, please do that. (not meaning to nag, just didn't know if it was lost)
[16:43] <Keybuk> (you probably need more for X to start too)
[16:43] <dholbach> lool: ok
[16:43] <lool> dholbach: (It's very fragile to build from universe + ppa)
[16:43] <Keybuk> dholbach: if we're going to *have* release notes text, it should probably tell the ISPs what to do too :p
[16:43] <dholbach> Keybuk: right
[16:44] <dholbach> Keybuk: did anybody of them made notes about the config changes?
[16:45] <slangasek> smoser: ec2 done
[16:45] <ScottK> pitti: You may recall a private bug I filed against apport that you redirected to gdb.  I'm not comfortable with making the bug public, is there someone I should subscribe to it to give it a better chance of being looked at?
[16:46] <mvo> dutchie: this is just about karmic vs 9.10 ? fixing it now is a bit of work as it quires manual unfuzzing the strings
[16:46] <dutchie> mvo: though it'd be something like that
[16:46] <pitti> ScottK: ubuntu-dev perhaps?
[16:47] <ScottK> pitti: Thanks
[16:48] <mvo> dutchie: given that very few people are likely to see it, I'm inclined to just leave it as it is
[16:48] <slangasek> smoser: are we going to use the same filename, "published-ec2-nightly.txt", for the actual milestones?
[16:48] <dutchie> mvo: Shall I mark it as Fix Released then?
[16:48] <slangasek> smoser: oh, n/m, you cover this in the wiki
[16:48] <Keybuk> dholbach: no idea
[16:48] <Keybuk> dholbach: in the words of your boss, I give negative shit about vserver ;)
[16:48] <smoser> right.
[16:48] <dholbach> Keybuk: I realise :)
[16:48] <dholbach> :-(
[16:48] <dholbach> I'll try to find out
[16:48] <dholbach> this sucks
[16:49] <smoser> slangasek, i originally did not have the '-nightly' in it, but then when i went to publish a named release from a nightly dir, i realized i would overwrite the existing file (or refuse to do it becaues that file existed)
[16:50] <mvo> dutchie: that is best I think
[16:50] <slangasek> smoser: "daily" would've been more friendly to the existing scripts which all use this label, but no mind, I'll roll with it :)
[16:50] <mvo> dutchie: we may need the string again for lucid, but IIRC there was no arm port in hardy, so hardy->lucid upgrades will not be a problem
[16:51] <smoser> we can change that easily enough.
[16:51] <dpm> ArneGoetje, I remember we discussed at the platform sprint that we could use langpacks for language-selector after release, but I don't remember having enabled it myself
[16:51] <ScottK> mvo: You recall correctly.  No armel in Hardy
[16:51] <smoser> almost certainly i can sed -i with 's/nightly/daily/'
[16:51] <dpm> ArneGoetje, I remember we discussed at the platform sprint that we could use langpacks for language-selector after release, but I don't remember having enabled it myself
[16:52] <asac> ArneGoetje: rosetta is not used for those that have .xpis ... remember?
[16:52] <asac> ArneGoetje: what i wanted to verify is that the 1.9 and 3.0 lang packs are finally gone
[16:53] <asac> and dont show up in the addons manager anymore
[16:53] <asac> ArneGoetje: can you give an ack on that?
[16:53] <rgreening> o/
[16:53]  * rgreening sendds greetz from winnipeg
[16:53] <asac> ArneGoetje: they were still left in last rounds -base packs
[16:53] <slangasek> smoser: can we go with just "daily" and "release", then?
[16:53] <asac> the idea was that they go away completely after the last full export
[16:54] <smoser> you mean ditch 'milestone' ?
[16:54] <slangasek> smoser: I don't think that at this level, we care about what kind of milestone it is - that just means more code I have to write to find the filename
[16:54] <slangasek> smoser: whereas if it's daily vs. release, that matches the existing args to make-web-indices
[16:55] <mvo> thanks ScottK
[16:55] <smoser> ok. so that file, you want named as publish-ec2-daily.txt or publish-ec2-release.txt ?
[16:55] <slangasek> smoser: yes, please
[16:55] <smoser> you're ok with distinguishing 'milestone' other places (like the bucket names) , right?
[16:56] <smoser> because we expect to leave those around, i'd like to separate them (in a sorted list) from actual releases... the 'milestone' bucket did that.
[16:56] <slangasek> smoser: yes, certainly
[16:56] <slangasek> (I don't see any mention of buckets on https://wiki.ubuntu.com/UEC/Images/Publishing, fwiw; does this correspond to "LABEL" there?)
[16:57] <smoser> ok. then i will rename nightly to daily, and smash 'label' in publish-ec2-<name>.txt to fit daily/release.
[16:57] <smoser> slangasek, in NamingConvention
[16:57] <smoser> a beta/rc/alpha go into bucket named ubuntu-images-milestone-us
[16:57] <smoser> a release goes into ubunt-images-us
[16:57] <smoser> well, spelled correctly hopefully.
[16:58] <slangasek> spelling is ovreraetd
[16:58] <smoser> but label there is 'beta' or 'rc' or 'alpha1'
[16:58] <smoser> the resultant published filename has that in it.
[16:59] <ArneGoetje> asac: ack
[16:59] <asac> thx
[16:59] <asac> now i can sleep again ;)
[17:12] <slangasek> smoser: http://uec-images.ubuntu.com/karmic/20091020/ updated now with the AMI table; not sure why this table renders differently from the one you had before, though
[17:13] <smoser> slangasek, looks fine to me. i had copied and pasted some stylesheet stuff to get what was there.
[17:13] <smoser> slangasek, it really looks great. thank you for your work on it.
[17:14] <slangasek> smoser: well, I copy pasted the same stylesheet stuff from you, but it looks different :)
[17:14] <smoser> oh well. who are we to question firefox's authority
[17:14] <slangasek> anyway, if that looks ok, I think we have something now that we can use for publishing the RC
[17:15] <smoser> i think so.
[17:15] <smoser> so when we publish as RC, we'll:
[17:15] <smoser> a.) copy 20091020 dir to 'rc' dir
[17:16] <smoser> b.) publish to ec2 as 'rc'
[17:16] <smoser> c.) make-indices
[17:16] <smoser> d.) remove published-ec2-nightly
[17:16] <smoser> probably swap c and d order
[17:16] <smoser> anything else ?
[17:17] <smoser> slangasek,
[17:18] <tseliot> Keybuk: is there a patch which allows Moblin's  X "not to clear the screen until the desktop appears", as you said? If so, where can I find it?
[17:19] <slangasek> smoser: actually, I was going to wire up publish-release to be able to do a-c for me
[17:20] <slangasek> smoser: but not until after I get some sleep, I'm afraid
[17:20] <smoser> thats fine. what do you mean by 'publish-release' ?
[17:20] <smoser> is that another cdimage script ?
[17:20] <slangasek> smoser: cdimage/bin/publish-release
[17:20] <slangasek> yep
[17:20] <smoser> awesome. i'll look at that. thanks again.
[17:20] <slangasek> smoser: sure - thank you!
[17:37] <slangasek> smoser: there are a handful of package updates that apply to UEC for RC: http://qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/uec-amd64.html - I think we should reroll the images / AMIs for this
[17:37] <smoser> i'm ok with that. but then i have to ask if i can sneak in one other.
[17:38] <slangasek> smoser: ok?
[17:38] <smoser> ec2-init for bug 407949
[17:39] <slangasek> smoser: sure; get it uploaded and we can push it in
[17:39] <smoser> i have to test the patch here, but i is viewable at http://bazaar.launchpad.net/~smoser/+junk/ec2-init.karmic/revision/33
[17:39] <smoser> ok. let me run the test first although it surely seems like it should be fine to me.
[17:50] <slangasek> smoser: I need to go get some sleep now; if pitti or cjwatson are around when you have ec2-init ready, please prod them about accepting it; in the meantime, I think the images that have been posted should be smoke tested
[17:51] <smoser> slangasek, i just booted one, so at very least it boots in us / i386
[18:00] <ArneGoetje> @core-devs: could someone please sponsor bug #409813 for me? Thanks!
[18:04] <smoser> soren, ping
[18:04] <asac> bug 409813
[18:05] <smoser> soren, http://paste.ubuntu.com/297648/ or zul i'd appreciate your sanity check on that patch.
[18:05] <smoser> i just tested in both ec2 and uec
[18:06] <smoser> but just want to be sure.
[18:06] <zul> smoser: looks sane
[18:07] <tripzero> why doesn't ubuntu kernel maintainers include the tuxonice patches?
[18:11] <jdstrand> mdz: fyi, bug #455832 is a regression from jaunty (I wasn't sure you got server team bug mail, so mentioning it here)
[18:12] <jdstrand> mdz: it also isn't limited to AoE, but seems any physical device (ie /dev/sdc)
[18:13] <jdstrand> s/physical//
[18:18] <mdz> jdstrand: thanks, please tag it as such
[18:19] <jdstrand> mdz: since it is marked as "Won't Fix" for karmic, I'll add regression-release
[18:21] <mdz> jdstrand: ok
[18:25] <smoser> pitti, or cjwatson ping per slangasek's comment above. I've attached debdiff (bzr diff) at http://launchpadlibrarian.net/34061675/bug407949-catch-exception.diff to bug 407949 and requested sponsorship.
[18:30] <pitti> smoser: looking
[18:31] <pitti> smoser: so ec2.get_mirror_from_availability_zone(availability_zone)
[18:31] <pitti> smoser: won't need the same treatment?
[18:33] <smoser> i put a comment there to that affect, but no.
[18:33] <smoser> http://paste.ubuntu.com/297660/
[18:33] <smoser> thats what it looks like.
[18:33] <pitti> smoser: or is the try/except just meant to catch missing entries in ec2.location_locale_map?
[18:33] <pitti> smoser: ah, good
[18:35] <pitti> smoser: thanks, uploaded
[18:36] <pitti> lool: accepting mobile-meta, since the images need a respin anyway for casper
[18:36] <smoser> pitti, thank you.
[18:36] <smoser> so, how do I know when that reaches archive ?
[18:36] <smoser> i will respin UEC images at that point.
[18:36] <pitti> smoser: we need to respin ubuntu server images with that as well, I guess?
[18:37] <smoser> ubuntu server does not include ec2-init. only UEC.
[18:37] <pitti> ah, good
[18:37] <pitti> smoser: how about
[18:37] <pitti> wget -q -O - http://archive.ubuntu.com/ubuntu/dists/karmic/main/binary-i386/Packages.gz | zgrep -A 10 'Package: ec2-init'|grep ^Version
[18:37] <pitti> smoser: and check that it is 0.4.999-0ubuntu4
[18:37] <pitti> then it should be ok
[18:38] <smoser> pitti, thanks.
[18:38] <dupondje> could some developper please check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[18:39] <dupondje> its such an extremely annoying job :
[18:39] <dupondje> :(
[18:42] <dupondje> nobody ? :(
[18:58] <lool> pitti: we don't use mobile-meta in any image I think
[19:15] <kees> pitti: what is the state of builders, I have a 3rd attempt at a jaunty kernel build coming in soon.  is there a preferred time for it?
[19:18] <pitti> kees: fine from my side, we are rebuilding images for RC now, and have everything we currently need; I'd appreciate if you could just build one at a time, so that we keep one buildd for doko_'s maven efforts and possible emergency rebuilds; does that work?
[19:19] <kees> pitti: it's just jaunty this time, the others are done.  i can't control per-arch builds.
[19:19] <pitti> kees: per-arch isn't necessary; I meant one source building at a time
[19:19] <pitti> kees: if it's just jaunty, that's fine
[19:20] <pitti> thanks for coordinating
[19:20] <kees> pitti: yeah, just jaunty.  thanks!
[19:48] <pitti> smoser: new ec2-init is on the master archive (cocoplum), but not on archive.u.c. mirror yet
[19:48] <pitti> smoser: where do you build the EC2 images? on antimony?
[19:48] <smoser> nectarine is in data center
[19:49] <smoser> its view of archive.u.c has it
[19:49] <smoser> so i'll start them. thanks for the ping.
[19:49] <pitti> smoser: right, please do verify the version there; I suppose it has a local mirror as well?
[19:50] <pitti> smoser: our cdimage server (antimony) doesn't have it yet either
[19:50] <pitti> so it might be in limbo on syncproxy
[19:50] <smoser> i verified from nectarine with what you suggested above.
[19:51] <smoser> so i think it should be good. it'll be a 10  minutes or so anyway before i start this.
[19:52] <zul> how do I add testcases to the iso testing wiki?
[19:55] <eviljussi01> +could anyone explain to me the rational for removing libstdc++5 from the karmic repos?
[19:58] <geser> eviljussi01: it was carried over from Debian: Debian bug #536776
[19:59] <eviljussi01> geser: right. thats really sad :( Im noticing several things that depend on it. :/
[20:03] <dupondje> who can I contact for aptitude bug ?
[20:03] <dupondje> did a bugreport
[20:03] <dupondje> and seems like I found the fix for it
[20:05] <zul> pitti: is it normal to have postgresql-8.3 and postgresql-8.4 installed at the same time when you are upgrading from jaunty to karmic?
[20:05] <pitti> zul: yes; you should get a debconf note that 8.3 is obsolete, and instructions how to upgrade
[20:05] <zul> pitti: ok just making sure
[20:06] <pitti> we can't do db upgrades during dist upgrades
[20:06]  * mneptok and co. are a few days from upgrading the MySQL universe :)
[20:06] <dupondje> pitti: can I stalk you for the bugfix ? Its a quite annoying bug in aptitude, and got it fixed now. Would be great if it was fixed in Karmic
[20:07] <dupondje> bug: https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[20:07] <pitti> dupondje: please subscribe ubuntu-main-sponsors if you have a fix; sorry, I don't have time right now (busy with doing the RC release stuff)
[20:07] <dupondje> k
[20:22] <avb1> guys, why there is so many dependencies to libgnome2-0 and libgnomeui-0? accordning to http://www.gnome.org/~fpeters/299.html only gnome-panel should depend on it
[20:24] <avb1> ok, seems there is only gdm
[20:29] <dholbach> avb1: if you look at http://www.gnome.org/~fpeters/299.html there's a bunch more for LibGnome and LibGnomeUi
[20:30] <avb1> yes, in others :)
[20:30] <avb1> most important is that gdm should not depend on it
[20:33] <avb1> im wrong, /usr/lib/gdm/gdm-user-switch-applet depends on it
[20:37] <pitti> smoser: please tell me when images are ready, and I should add them to the ISO tracker; or can you do that yourself?
[20:37] <smoser> i will need help on that.
[20:39] <smoser> i just started a build. its minimum 1 hour before everything is done and published to ec2, pitti
[20:39] <pitti> smoser: ok, I think I can stay awake for another hour
[20:49] <jdstrand> kirkland: fyi-- fta asked my about this in #ubuntu-mozillateam. is a failed install for an XP guest via virt-install/virt-manager/libvirt a priority for karmic? see bug #456602
[21:14] <kirkland> jdstrand: if someone has a tested patch, that I can eyeball, test, and sponsor, I'll gladly take it
[21:15] <kirkland> jdstrand: but I'm in documentation mode at this point
[21:16] <jdstrand> kirkland: this is a regression. can you add the appropriate karmic Won't Fix task, and add regression-release? this did work in jaunty and will like need to be in the release notes
[21:17] <jdstrand> kirkland: I would do it myself, but since I am not the one making the call, it seems more appropriate for someone else to do it
[21:18] <dupondje> I have a patch ;) tho not for that problem ;)
[21:19] <kirkland> jdstrand: done
[21:24] <wasabi__> NIce. Ya'll are coming to visit me this year (Dallas.)
[21:24] <wasabi__> See that? "Ya'll". Get used to it.
[21:29] <chrisccoulson> slangasek - would you mind trying to get an xtrace log of your g-s-d crash at some point (although you're probably quite busy at the moment ;))
[21:43] <smoser> pitti, i'm sorry but it appears like its going to be another 30 minutes. build is going, publish to ec2 still running.
[21:45] <smoser> i'd guess around 21:00 UTC you'll see http://uec-images.ubuntu.com/karmic/20091020.1 populated.  the file published-ec2-daily.txt will have the AMIs you need. (the format is like http://uec-images.ubuntu.com/karmic/20091020/published-ec2-daily.txt and you are concerned with the first 4 lines)
[21:52] <pitti> smoser: sorry, I killed my X, had to reboot; were you saying anything to me?
[21:53] <smoser> :)
[21:53] <smoser> i'd guess around 21:00 UTC you'll see http://uec-images.ubuntu.com/karmic/20091020.1 populated.  the file published-ec2-daily.txt will have the AMIs you need. (the format is like http://uec-images.ubuntu.com/karmic/20091020/published-ec2-daily.txt and you are concerned with the first 4 lines)
[21:53] <pitti> smoser: I still see the "[22:45:00] i'd guess around 21:00 UTC you'll see..."
[21:53] <smoser> thats all.
[21:53] <pitti> smoser: ah, ok; I was afraid I missed something before that, since that didn't include a highlight
[21:54] <smoser> there was something before it, but the above is good
[21:55] <pitti> ok, will poll for that and add to iso tracker when it appears
[21:57] <pitti> smoser: so those are ec2 ami US/Europe i386+amd64
[21:57] <pitti> smoser: is there a different place for "server UEC"?
[21:57] <pitti> or shouldn't these be added?
[21:58] <smoser> yes, the published-ec2-daily.txt contains the ec2 {eu-west-1,us-east-1}/{i386,amd64}
[21:58] <smoser> for "server UEC" i think just reference 20091020.1 (and that url i posted with that number in it above)
[21:59] <pitti> ok, thanks
[22:16] <smoser> pitti, http://uec-images.ubuntu.com/karmic/20091020.1/ is updated.
[22:16] <smoser> just use the information in the ec2 table
[22:16] <smoser> have a nice night. i have to run now, and thank you for your patience.
[22:17] <pitti> smoser: ok, that's UEC?
[22:17] <pitti> smoser: no ec2?
[22:17] <pitti> ah, I see
[22:17] <smoser> at that link, there is a table of ec2 info
[22:17] <smoser> ok.
[22:17] <pitti> I'll just use the same build number then
[22:17] <smoser> apparently slangasek made the published-ec2-daily.txt file not shown in the index.
[22:18] <pitti> smoser: added
[22:18] <smoser> thanks.
[22:18] <smoser> pitti, i'm looking
[22:18] <smoser> http://iso.qa.ubuntu.com/qatracker/build/ubuntuserver/all
[22:19] <smoser> in the past, that has had the AMIs in paren for ec2 . ie, ami-8e5c77fa
[22:22] <pitti> smoser: hm, I don't know how to do that, I'm afraid
[22:22] <smoser> well where did you put the AMIs ?
[22:23] <pitti> smoser: nowhere; I can just state a build ID
[22:23] <pitti> s/ID/timestamp/
[22:23] <pitti> like 20091020.1
[22:23] <smoser> and it woouldn't take an ami there ?
[22:23] <smoser> i think steve was just putting the ami there before. for the ec2 and for the UEC using the timestamp
[22:24] <smoser> but maybe i'm wrong
[22:25] <pitti> smoser: check now, that better? (added amd64 europe)
[22:25] <pitti> it doesn't have a build timestamp any more, though
[22:25] <smoser> yeah, i think thats what steve did before
[22:25] <smoser> its fine.
[22:25] <smoser> thanks again. i have to run now.
[22:26] <smoser> have a good night.
[22:26] <pitti> all updated
[22:27] <pitti> bye!
[22:37] <rickspencer3> g'night pitti
[22:37] <pitti> oh, that was supposed to go to smoser
[22:37] <rickspencer3> ;)
[22:41] <seb128> siretart, hey
[22:41] <seb128> siretart, do you know if anybody is working on libdvdread?
[22:41] <seb128> siretart, there is a frequent crasher but there seems to be no active upstream there
[22:42] <seb128> siretart, bug #435968
[22:42] <seb128> ^ or if anybody knowns ;-)
[22:44] <chrisccoulson> slangasek - i figured out why your g-s-d trace doesn't look right
[22:44] <siretart> seb128: TBH: no idea, I didn't follow libdvdread lately...
[22:44] <seb128> siretart, ok thanks anyway
[22:45] <chrisccoulson> there is no call to _XReply in XRRSetScreenSize (which I'm sure is the call that generates the error), so you will never catch any errors synchronously on that call anyway
[22:45] <chrisccoulson> the error will always be caught on the next call
[22:45] <chrisccoulson> which is a pain :-/