[01:03] <stgraber> slangasek: I merged your change, then at cjwatson's suggestion, switched to .call() so we wait for the clear call to return and also moved it to a try/except IOError block just in case something goes wrong with /dev/ttyX
[01:06] <psusi> cjwatson, I got a weird problem with grub on oneiric now... fails to install... grub-probe --target=fs /target fails to identify the fs... if I mount my lucid or natty logical volume in /target, it works fine..  nothing jumps out at me comparing the -vvv logs of the working lv with the failing lv... any ideas?
[01:07] <psusi> --target=device works fine, as does abstraction ( lvm )
[01:17] <psusi> cjwatson, everything is ext4 btw
[04:07] <slangasek> stgraber: sweet, thanks :)
[04:25] <ScottK> jbicha: I'm looking at your libmusicbrainz-2.1 sync.  Don't we already have hardening flags enabled via gcc in Ubuntu?  I think that sync is a no-op for us.
[04:27] <ScottK> The wspanish changes don't look very RC either.
[04:28] <micahg> ScottK: depends which flags
[04:28] <ScottK> micahg: Would you look at the diff then, please?
[04:28] <micahg> ScottK: can you point me to it?
[04:28] <micahg> +queue doesn't show it
[04:28] <ScottK> It won't.
[04:28] <ScottK> I had to download and debdiff.
[04:29]  * micahg uses LP
[04:29] <ScottK> (yes, I've file the bug about that)
[04:29] <micahg> https://launchpadlibrarian.net/81986735/libmusicbrainz-2.1_2.1.5-6_2.1.5-6.1.diff.gz
[04:30] <ScottK> That's the one.
[04:30] <micahg> yeah, that won't do anything for us this cycle
[04:31] <ScottK> jbicha: ^^^ I'm going to reject them both.  If you really think they should go in, let's discuss.
[04:32] <micahg> ScottK: you can make LP show a diff here: https://launchpad.net/ubuntu/oneiric/+localpackagediffs for syncs, select All packages
[04:33] <ScottK> Right.  I tend to forget that's around now.
[04:33] <ScottK> Except for syncs on +queue there's generally a diff on the page I'm looking at.
[04:34] <micahg> right
[04:34] <jbicha> ScottK: I thought those updates wouldn't hurt but it's not a big deal to me whether they get in or not
[04:34] <ScottK> jbicha: Generally in the end game we prefer not to touch packages without a good reason.
[04:35] <ScottK> I agree they were almost certainly harmless, but also provided no real benefit.  Stuff like that is better waiting.
[04:35] <jbicha> ok, no problem then
[05:46] <didrocks> good morning
[06:25] <pitti> Good morning
[06:56] <dholbach> good morning
[07:04] <sladen> morgen
[08:01] <jamespage> morning
[08:11] <pitti> cjwatson: lightdm 1.0.1-0ubuntu2 should fix your locale bug
[08:38] <cjwatson> pitti: yay, thanks
[08:38] <cjwatson> I'll tell you in a bit ...
[09:20] <zarlino> i all, I'd like to add my commercial software to the ubuntu software center. I read this http://developer.ubuntu.com/publish/my-apps-packages/, but cannot figure out how exactly I should package my app. Any suggestions?
[09:26] <pitti> zarlino: I suppose you are not using quickly for your app then?
[09:26] <zarlino> pitti: no it's a Qt app
[09:27] <pitti> zarlino: above documentation assumes that, so if you don't use that, you might need to do the packaging manually
[09:27] <zarlino> pitti: I already have a generic .deb for my app
[09:27] <pitti> didrocks: ^ does quickly help with creating packaging if you don't use it for creating the source skeleton etc.?
[09:27] <zarlino> pitti: I just don't know how to provide the "source package" format
[09:27] <pitti> zarlino: oh, so much the better
[09:28] <pitti> zarlino: well, how did you build your deb, if not with debuild or dpkg-buildpackage from a source package?
[09:28] <didrocks> pitti: if the project is converted to the quickly format, yes
[09:28] <didrocks> like library_name and such
[09:28] <zarlino> pitti: yes I used dpkg-buildpackage
[09:29] <zarlino> pitti: i used the "native" debian format, not the "quilt"
[09:30] <pitti> zarlino: then whatever you ran it from is a source package tree; "dpkg-buildpackage -S" will build the source package, which consists of a .dsc, usually a .debian.tar.gz or .diff.gz, and a tarball with the upstream source
[09:30] <pitti> zarlino: so you probably end up with a .tar.gz and a .dsc
[09:31] <zarlino> pitti: ok but I'd prefer not to upload the sources
[09:31] <zarlino> pitti: so how to package the binaries, icons and stuff in a source package format?
[09:32] <pitti> zarlino: then you can't use Launchpad PPAs, but need to provide your own repository
[09:32] <pitti> zarlino: you can also do that, of course
[09:32] <zarlino> pitti: the software center developer site provides an upload form
[09:32] <pitti> zarlino: it's called "source" package because usually it has the source, but technically the only requirement is that running dpkg-buildpackage in it builds .debs
[09:33] <pitti> zarlino: e. g. the sun-java6 or nvidia driver packagages just ship the readily built blobs in the source and merely copy them into the debs
[09:33] <pitti> zarlino: ah, for .debs or source pacakges?
[09:33] <pitti> zarlino: if for .debs, it seems your problem is pretty much solved?
[09:34] <zarlino> pitti: i think both
[09:34] <zarlino> pitti: I'm talking about this: http://developer.ubuntu.com/publish/ to be clear
[09:35] <ajmitch> the page does seem to state that it's a tarball of the source package
[09:35] <pitti> zarlino: right, only source package
[09:35] <ajmitch> it's also a bit too focused on commercial apps, which is fine in this case
[09:36] <pitti> zarlino: for more details I think I defer to mvo, I don't know that process very well
[09:36] <cjwatson> I think #ubuntu-app-devel might have more people who are focused on this kind of thing, BTW
[09:37] <zarlino> cjwatson: thanks will also ask there
[09:37] <cjwatson> (or maybe not, I confess I haven't been in there lately)
[09:37] <ajmitch> it's been fairly quiet there lately
[09:38] <zarlino> pitti: so your suggestion is I should look at nvidia or java debs and how they do it?
[09:38] <pitti> zarlino: as I said, they just have the final binaries, and the debian/ bits are by and large nothing more than installing these binaries
[09:38] <ajmitch> reading the info there, it looks like packaging commercial apps is something canonical offers help with
[09:39] <pitti> zarlino: i. e. just having a debian/mypackage.install file and the standard 3-line debian/rules ought to be enough
[09:40] <zarlino> pitti: It'll look easy to me too when I'll found about what those 3 lines are...
[09:41] <pitti> see "man dh":
[09:41] <pitti> #!/usr/bin/make -f
[09:41] <pitti> %:
[09:41] <pitti>         dh $@
[09:45] <zarlino> pitti: reading that man, thanks for your help!
[09:48] <Laney> congrats new TB :-)
[09:49] <micahg> did I miss an e-mail?
[09:49] <ajmitch> a blog post by sabdfl
[09:49] <ajmitch> maybe an email as well, I haven't checked this evening :)
[09:50] <Laney> just saw the blog
[09:51] <micahg> ah, just saw it
[10:25] <binarymutant> is there a way to search the archives for a particular license?
[10:25] <binarymutant> * an easy way *
[10:27] <Laney> erm, packages.u.c links to .copyright files that don't exist
[10:30] <tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
[10:31] <Laney> binarymutant: I cannot think of any place you can get the copyright file for an Ubuntu package other than from the binary package itself
[10:33] <binarymutant> thanks I found a way :D
[10:34] <Laney> hmm?
[10:34] <binarymutant> google `site:packages.debian.org inurl:changelogs/pool/main filetype:copyright wtfpl`
[10:35] <Laney> I found out that the links from packages.u.c are wrong but the copyright files are actually there
[10:35] <Laney> so yes, s/debian.org/ubuntu.com and s/main// might work
[10:38] <sabdfl> micahg, sorry for the impersonal approach! congrats and welcome
[10:38] <nigelb> sabdfl: Hey! Dictionary alright? We still haven't got a name :D
[10:39] <sabdfl> precisely
[10:39] <ogra_> oh, awesome, stgraber made it !
[10:40] <ogra_> stgraber, congrats !!!
[10:46] <stikonas> dpm: Hello. Can I ask a question about launchpad translations? Something strange happens that I don't understand.
[10:46] <dpm> hi stikonas, sure
[10:47] <stikonas> dpm: according to https://translations.launchpad.net/ubuntu/oneiric/+source/kde4libs/+pots/libplasma/lt/+details there are no differences between upstream and Ubuntu
[10:48] <stikonas> But in upstream  "%1 Settings" is translated as msgstr "Nustatymai: %1|/|$[get-case Kilmininkas %1] nustatymai", while in Launchpad the translation is "Nustatymai: %1"
[10:48] <stikonas> it seems that Launchpad has older translation
[10:49] <stikonas> and has not reimported translations after the change in upstream. But it still thinks that there are no differences
[10:51] <dpm> stikonas, when you say upstream, where are you looking at? Could you point me to the string that differs in the upstream repo?
[10:51] <stikonas> btw, I'm upstream translator who made that change.
[10:51] <stikonas> ok
[10:51] <stikonas> dpm: http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/lt/messages/kdelibs/libplasma.po
[10:51] <stikonas> dpm: please search for msgid "%1 Settings"
[10:52] <dpm> stikonas, I can see the string. Are you certain that the libplasma version this PO file belongs to has already been uploaded to Ubuntu?
[10:53] <stikonas> dpm: it should be. I change the upstream translation in March or April, so it should have been imported with KDE 4.7.0
[10:53] <stikonas> s/change/changed/
[10:54] <stikonas> dpm: and Launchpad lists this new string as a suggestion
[10:55] <dpm> stikonas, hm, I'll have to investigate further, then. In the meantime, if this is an important change, could you please updated in Launchpad, so that at least we ensure that the language packs will contain the correct translation?
[10:55] <dpm> s/updated/update it/
[10:57] <stikonas> dpm: OK, I'll fix it in Launchpad now.
[10:59] <dpm> thanks stikonas
[11:00] <stikonas> dpm: I a few strings in this file. I'll now look at some other file
[11:01] <dpm> ok, thanks stikonas, let me know if you see any other inconsistencies
[11:06] <tseliot> cjwatson, pitti: do you think it would be better to merge the package from debian or would a 2 lines fix be more appropriate, given the fact that we're in final freeze? bug #811016
[11:11] <pitti> tseliot: without having looked at the merge delta, a cherry-pick is generally better at this time IMHO
[11:20] <stikonas> dpm: I have found something similar in https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/+details
[11:21] <tseliot> pitti: I figured as much but I wanted to be sure
[11:22] <tseliot> thanks
[11:22] <stikonas> dpm: If you want, we can leave it as a testcase. It is not as important as the translations that we talked previously.
[11:23] <stikonas> dpm: e.g. this string is not updated: https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/34/+translate
[11:25] <stikonas> dpm: corresponding upstream is http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/lt/messages/kdebase/powerdevilglobalconfig.po
[11:25] <dpm> stikonas, thanks. Perhaps a good idea might be to collect those you notice in an e-mail and send it to the ubuntu-translators list. I cannot promise that we'll be able to look at them straight away or before release, but it will help to keep track of them
[11:53] <tseliot> pitti: ok, I've just uploaded the fix for pbuilder
[12:20] <larsu> tkamppeter, ping
[12:21] <doko> dholbach, updated https://wiki.ubuntu.com/CompilerFlags
[12:21] <tkamppeter> larsu, hi
[12:21] <larsu> tkamppeter, did you get the direct messages I sent you?
[12:23] <dholbach> thanks doko!
[12:40] <jibel> mvo, I tried an upgrade to oneiric on i386 and bug 853688 is still there.
[12:41] <jibel> mvo, to reproduce I installed gcj-4.4-jre-headless on an up to date natty then upgraded to oneiric.
[12:51] <mvo> jibel: thanks let me try to reproduce again
[13:03] <stgraber> ogra_: thanks!
[13:03] <ogra_> stgraber, time for LTSP wold domination then :)
[13:03] <ogra_> *world :)
[13:04] <ogra_> we can talk about it in SW harbor :)
[13:04]  * ogra_ finally got the tickets sorted
[13:04] <stgraber> hehe :)
[13:04] <stgraber> ogra_: cool, when are you arriving in SW harbor?
[13:04] <Chipzz> doko: there's a small "error" on the page you updated
[13:05] <Chipzz> doko: the section about -Wl,--no-copy-dt-needed-entries has this sentence twice: "This option affects the treatment of dynamic libraries referred to by DT_NEEDED tags inside ELF dynamic libraries mentioned on the command line."
[13:05] <ogra_> stgraber, 17:23 it says
[13:05] <ogra_> on the 27th
[13:05] <ogra_> i'll likely need a lift
[13:07] <stgraber> ogra_: ok, I'm sure we'll find someone who can give you a lift. We'll be in SW Harbor at around 1-2pm to pick up pscheie but either someone driving a bit later than we are can pick you up or we'll just have someone drive from SW Harbor.
[13:08] <ogra_> yeah, i know jim likes to do such stuff
[13:08] <ogra_> i'm sure i can get him to pick me up
[13:08] <ogra_> renting a car like i did last time somehow doesnt cut it since i dont really drive around much
[13:08] <doko> Chipzz, thanks, fixed
[13:09] <stgraber> ogra_: are you on the same flight to Orlando as alkisg, highvoltage and I?
[13:10] <ogra_> not sure, let me check the flight '
[13:10] <ogra_> #
[13:10] <Chipzz> doko: yw :)
[13:10] <ogra_> stgraber, US 835
[13:10] <stgraber> ogra_: hmm, different than us. What time is this one leaving from Bangor?
[13:11] <ogra_> leaves PHL at 6pm
[13:11] <ogra_> no, through philly
[13:11] <stgraber> ah, ok, and what time is your flight from Bangor to philly?
[13:12] <rbasak> cyphermox: ping
[13:12] <cyphermox> rbasak: pong
[13:12] <ogra_> stgraber, 3:30 pm
[13:12] <rbasak> cyphermox: got somewhere with bug 856209
[13:12] <rbasak> I think it's an issue in libnl3
[13:13] <rbasak> I have a patch to libnl3 which makes your program work, but it's maybe a bit invasive
[13:13] <rbasak> libnl3 sets routes using multipath destinations only, looks like it expects a single destination to be a special case of that
[13:14] <rbasak> I tried changing it so that if there is only one destination specified, then rather than requesting a multipath route it requests a normal one
[13:14] <rbasak> That worked
[13:14] <rbasak> Also to fix the "::" vs. "default" thing, you have to set the prefixlen to 0.
[13:14] <hallyn_> skaet: Daviey: bug 522710, does nothing but add manpage for libvirtd.  Is a trivial but wishlist fix like that doable during final freeze?  :)
[13:14] <stgraber> ogra_: ah, ok. I see this one arrives quite a bit later in Orlando than ours do (Bangor => NYC => Orlando), my goal was to arrive at the hotel around 6pm.
[13:15] <cyphermox> rbasak: yeah, the default part I knew about, just didn' t bother to touch it, since it didn' t work either way
[13:15] <ogra_> stgraber, my goal was to get a payable flight at all ... since i'm late as usual :)
[13:15] <cyphermox> but yeah, your thing does make sense
[13:15] <rbasak> The catch is that AIUI because the libnl3 API doesn't distinguish between single and multipath, you must set an interface index
[13:15] <rbasak> (since it doesn't have the option of not setting one)
[13:16] <rbasak> So in my patch I ignore an interface index if set and only one destination is specified
[13:16] <cyphermox> and you can' t set it outside multipath :)
[13:16] <stgraber> ogra_: hehe, yeah, I guess there wasn't too many flights left when you booked ;)
[13:16] <ogra_> right
[13:16] <cyphermox> rbasak: you should still be able to set the index if it' s specified in the multipath parameters, as long as there' s only one multipath, set it directly as a destination?:
[13:17] <rbasak> What I'm not sure about is whether there is any case where it does make sense to specify a single destination but with a device index, and if so I'm not sure how to implement that without changing the API
[13:17] <rbasak> Yeah but at the stage where the netlink payload is generated, it's not possible to distinguish between the API user having set an interface and not having set one (AFAICT)
[13:18] <rbasak> There is no sentinel or flag, AFAICT, because in the multipath-only case a per-destination interface is mandatory
[13:19] <cyphermox> rbasak: isn't there already a check being done for whether an interface is set in the multipath struct?
[13:19] <rbasak> This is assuming that the issue isn't something to do with the multipath handling - I fixed it by taking that out
[13:19] <rbasak> No, I don't think so - the only check is to see if multipath is enabled, which happens automatically when you add a single nexthop
[13:20] <rbasak> The reason is that in the wire protocol for multipath an interface isn't an option, it's part of the RTA_MULTIPATH struct
[13:21] <rbasak> so in the add nexthop libnl3 function, I think you're supposed to set one in all cases - you can't leave it undefined
[13:21] <larsu> tkamppeter, okay, I have a non-crashing verions of liblcms1. It does generate lots of "Error: Can't create transform" errors, though
[13:21] <larsu> but that seems to be a deeper problem
[13:21] <cyphermox> rbasak: you have a patch ready no? if you send me I have an idea I could send you back what I mean as a revision of your patch :)
[13:21] <rbasak> Note that when I do "ip -6 route add default gw ..." without a device specified, the kernel nevertheless works one out and adds one - but that's done at kernel level, not in userspace
[13:22] <cyphermox> rbasak: well, something is done by the ip util to send a netlink message, but I suspect it' s an "old"  message
[13:22] <pitti> mterry: is there a bug for the lightdm upload? this change isn't straightforward and obviously regression free, so I'd like to know more details
[13:22] <pitti> mterry: (will answer in a bit, need to run out for some errands)
[13:22] <rbasak> cyphermox: the ip util follows a different path depending on whether you are using multipath or not
[13:23] <rbasak> cyphermox: I tried doing a single destination specified in the multipath syntax and ip rejected it - this might be ipv6 only
[13:23] <mterry> seb128, you said you hadn't seen a bug for the gdmflexiserver thing, that it came over IRC?  I'll search for one
[13:23] <pitti> mterry: in particular, how does this prevent the utility path from appearing in the actual session?
[13:23] <seb128> mterry, right, I had a look and didn't find one open
[13:23] <mterry> pitti, we want it in the actual session.  the bug is that it's not
[13:24] <mterry> pitti, this is how we've had lightdm override gdm's gdmflexiserver
[13:24] <rbasak> cyphermox: patch: http://paste.ubuntu.com/702750/
[13:24] <pitti> mterry: that's strange, though, and might still break with custom $PATH settings in ~/.profile, etc?
[13:24] <pitti> mterry: don't we rather want to put those programs in to $PATH in the .deb?
[13:24] <pitti> anyway, really off now
[13:24] <pitti> (back in ~ 45 mins)
[13:25] <mterry> pitti, only custom PATH settings that completely override PATH, which is bad behavior, no?
[13:26] <mterry> pitti, well, putting it into PATH has its own set of problems.  GDM's executable is already in PATH.  There's another kdm package that adds a divert to it to add their own.  So we could add another divert, switch to an alternatives system, modify PATH, or maybe something else.  PATH was seen as least offensive, although seb128 continues to feel icky about it
[13:33] <mterry> pitti, There is no bug associated with it, because we used to do things this way, then someone noticed that it was no longer being inserted into PATH and commented to seb128 about it on IRC.  I can file one?  To reproduce, uninstall gdm and lock your screen.  Normally, you should be able to switch users from that dialog, but since it can't find gdmflexiserver, you can't.
[13:33] <seb128> mterry, yeah, it's chrisccoulson who asked if the "switch user" was missing in the lock screens for others earlier
[13:34] <chrisccoulson> hi :)
[13:34] <seb128> hey chrisccoulson
[13:34] <chrisccoulson> it was actually jo who noticed it was missing ;)
[13:34] <seb128> chrisccoulson, want to open the bug? ;-) mterry is fixing it
[13:34] <rbasak> cyphermox: so "ip -6 route add default via 2001:db8::1" would be how I'd do it, but I think "ip -6 route add default nexthop via 2001:db8::1" is syntactically correct in that it defines a single entry multipath route. But the latter fails with "Error: an IP address is expected rather than "2001:db8::1"". I wonder if IPv4 single-entry multipath routes work but IPv6 doesn't?
[13:34] <chrisccoulson> seb128, for lightdm or gnome-screensaver?
[13:35] <seb128> chrisccoulson, lightdm
[13:35] <seb128> well lightdm has a gdmflexiserver
[13:35] <cyphermox> rbasak: it's very possible ipv6 doesn't, you' d have to look it up in the libnl or netlink kernel code
[13:35] <seb128> it's just that it fails at injecting the directory in the path
[13:35] <seb128> which mterry has a merge request for now
[13:35] <seb128> that should fix the bug
[13:35] <rbasak> cyphermox: well, that's what libnl3 is requesting from the kernel :-)
[13:35] <rbasak> (without my patch)
[13:36] <seb128> (why did we switch to #ubuntu-devel? ;-)
[13:36] <cyphermox> that said, I want to make sure we don't only cover the default gateway, because if this fails now nothing says it wouldn't also fail for a "<net> dev <dev>" route
[13:36] <seb128> (oh, pitti pinged there)
[13:36] <rbasak> Ah
[13:36] <cyphermox> rbasak: what about this: http://paste.ubuntu.com/702756/
[13:36] <rbasak> Yeah, that's the kind of thing I was worried about, but I didn't think of that very common case!
[13:36] <seb128> chrisccoulson, mterry, pitti: the other option is to patch gnome-screensaver to tech it about the lightdm gdmflexiserver path
[13:37] <seb128> but we might have other things trying to use gdmflexisever
[13:37] <seb128> that command is an hack to start, we should replace it with dbus interfaces next cycle ;-)
[13:37] <rbasak> cyphermox: that's fine, but what if I didn't want to set an ifindex (in the default case)?
[13:37] <seb128> or make gnome-screensaver use those interface if we already have them
[13:37] <cyphermox> rbasak: right, I don' t think it's a common case, but since it is actually correct (e.g. p2p links)... and ifindex is set unconditionally in multipath, so why not set it unconditionally in the route
[13:38] <cyphermox> rbasak: I'd test this first of course, but if you don' t want to set it I think it defaults to nothing
[13:38] <rbasak> cyphermox: I'm concerned that it defaults to undefined
[13:38] <mterry> seb128, it's also gnome-shell and I think one more package
[13:38] <cyphermox> rbasak: isn't that fine?
[13:39] <mterry> maybe gnome-session
[13:39] <cyphermox> rbasak: we' re also always setting it up in NM when the route is being added :)
[13:39] <rbasak> no, because it'll be whatever happened to be at that memory location previously
[13:39] <chrisccoulson> seb128, mterry, pitti - bug 868363
[13:39] <seb128> chrisccoulson, thanks
[13:39] <mterry> chrisccoulson, awesome
[13:39] <rbasak> OK so if NM does set it then it'll be fine in that case
[13:39] <cyphermox> I believe it just defaults to 0, but it would be nice to test it
[13:40] <cyphermox> and doing so couldn' t be easier :)
[13:40] <rbasak> But then the libnl3 API won't allow the "please kernel work it out yourself" case that I do with the ip tool
[13:40] <rbasak> However, if the NM case will work, then I don't think we'll have broken anything and we'll have fixed the bug
[13:41] <rbasak> and it'd be nice to see my ipv6 working in oneiric :)
[13:41] <cyphermox> would be nice to have a second opinion from upstream; do you want to send it to the mailing list?
[13:41] <rbasak> me? :)
[13:41] <cyphermox> or actuially, would be best to give it a bit of testing first, but then I can send it :)
[13:42] <rbasak> I did try writing an email for the list, but I had great difficulty in explaining the issue
[13:43] <rbasak> Please remember to check that it doesn't break ipv4 - that would be embarrassing :-)
[13:43] <cyphermox> hehe
[13:43] <ScottK> RAOF: Is there any actual content in your dbus-sharp sync?  From debian/changelog it looks like a no-change upload.
[13:44] <cyphermox> rbasak: who needs ipv4 now anyway?
[13:44] <rbasak> cyphermox: those of us with a missing ipv6 default route :-P
[14:01] <pitti> mterry: ah, I didn't see the discussion in #u-desktop, I just reviewed the upload
[14:01] <pitti> thanks for the explanatino
[14:02] <mterry> pitti, (it's understood that PATH mangling isn't optimal, but we haven't come up with an amazingly better way that doesn't involve GNOME switching to dbus for this)
[14:03] <pitti> mterry: accepted and closed the bug, thanks!
[14:07] <skaet> hallyn_,  its a reasonable SRU candidate.  If the fix is ready though, we haven't started spinning images, so if Daviey reviews and doesn't see side effects, I'm ok with it going in.
[14:07] <hallyn_> skaet: thanks
[14:08] <hallyn_> skaet: oneiric-proposed won't open until next month I assume?
[14:09] <cjwatson> you can upload to oneiric-proposed right now, although that isn't to say anyone will look at it
[14:09] <cjwatson> (and it's not necessarily a good idea unless you're certain the package in oneiric is at its final version there)
[14:10] <cjwatson> we do sometimes use it just before release
[14:12] <mvo> jibel: I can reproduce and I think I found the problem
[14:12] <SpamapS> jamespage: hey are you familiar with the udevadm settle initramfs bug that adam_g has seen?
[14:12] <mvo> jibel: I will have a word with doko about it, its really odd
[14:14] <jibel> mvo, thanks for confirming, I reopen the report then.
[14:16] <mvo> jibel: please open a task against gcc-4.4-base again
[14:16] <mvo> jibel: the bug is in the breaks of the gcc-4.4-base package
[14:16] <mvo> jibel: I will add details tehre
[14:35] <frafu> Can anybody please tell me whether it is possible to extract the tooltip for translation from the following tag of an xml file?
[14:35] <sladen> frafu: URL?  path?  example?
[14:36] <frafu>                 <key group="bottomrow" id="showclick" image="show-click.svg" button='true' tooltip='Toggle click helpers'/>
[14:37] <frafu> The corresponding program (named Onboard) is written in python.
[14:38] <sladen> frafu: the ideal would be use an XML parser.  Failing that, some quick and dirty grep/awk would do it.
[14:40] <frafu> Is intltool not able to extract the tooltips in order to put them into the pot file?
[14:40] <cjwatson> I think that only works with files in a certain form; in particular (from a quick reading of the code) I think it would need to be _tooltip=
[14:41] <kelemengabor> frafu: have you tried adding translatable="yes" ?
[14:41] <kelemengabor> if this is from a glade file, it should do the trick
[14:41] <cjwatson> that wouldn't help intltool-extract in this case
[14:41] <cjwatson>     while ($input =~ /<(property|atkproperty|col)\s+[^>]*translatable\s*=\s*"yes"(?:\s+[^>]*context\s*=\s*"([^"]*)")?(?:\s+[^>]*comments\s*=\s*"([^"]*)")?[^>]*>([^<]+)<\/\1>/sg) {
[14:41] <cjwatson> does not match <key ...>
[14:42] <kelemengabor> oh
[14:42] <cjwatson> that doesn't look like glade to me anyway?
[14:44] <frafu> I think that  translatable="yes" works for tags that also have a closing tag. But the <key /> tag does not have a closing tag.
[14:49] <frafu> Assuming that I change the xml file to use _tooltip instead of tooltip without underscore. Does it also remove the underscore from the tooltip tag in the xml file (it is not a glade file) before putting it into the source package when calling ./setup.py sdist?
[14:54] <frafu> cjwatson: Here is where the file is hosted.  http://bazaar.launchpad.net/~onboard/onboard/main/view/head:/layouts/Compact.onboard
[14:55] <Riddell> mdke: please add me "jr" to ~ubuntu-core-doc
[14:56] <lamont> my wife is not happy with oneiric
[14:56] <lamont> lpstat got a segv, she let apport report it, and now her display is hung up.
[14:58] <frafu> cjwatson : What approach would you recommend? Manually extracting the tooltips into a separate file, which intltool can read? (We are doing it already for the some labels of the gui. )
[15:00] <cjwatson> don't know sorry
[15:00] <cjwatson> meeting now
[15:01] <cjwatson> my instinct is that if you put things in a .in file in a way that intltool-extract can read then it should drop things like leading _ in the output file - but I cannot help in detail sorry
[15:03] <frafu> cjwatson : I will first try the underscore method. Thanks anyway for the help you have given.
[15:05] <jamespage> SpamapS, I'm familiar with it symptomatically and spent some of yesterday with jhunt trying to diagnose furthur
[15:07] <kelemengabor> frafu: no, removing the _ markers is not automatic, you need to call intltool-merge -x on the files at build time
[15:40] <adam_g> jamespage: were you guys able to gain any insight into Bug #818177 ?
[15:41] <jamespage> adam_g, jhunt tried a few things on my reliable test case - but I don't think we move much further forwards
[15:46] <hallyn_> jamespage: has anyone tried hacking udev to keep handling events until the queue is empty when asked to exit?
[15:47] <hallyn_> I'm still unconvinced that we won't lose kernel netlink uevent msgs between shutdown and startup of the rootfs udev, but...
[15:47] <hallyn_> (but i suppose the replay is supposed to fix that)
[15:49] <adam_g> jamespage: im wondering if the 'udevadm control --exit' is blocking the subsequent move of /dev to ${rootmnt}/dev.
[15:50] <adam_g> hallyn_: ^
[15:51] <adam_g> remounting the udev devtmpfs again after a failed boot shows the directory populated
[15:51] <hallyn_> adam_g: well the udevd does hang (bc there are unhandled events) so yes the move doesn't happen until after that...
[15:52] <hallyn_> but i'm working from memory atm
[15:53] <hallyn_> i never was able to reproduce it with udev instrumented to tell me the *contents* of the non-empty worker and/or event lists :)
[15:55] <adam_g> hallyn_: did you modify udev to output that or were you depending on additional shell commands in the hook?
[15:57] <hallyn_> udev
[15:57] <adam_g> ah :(
[15:57] <hallyn_> just added some code to walk the lsits and print the contents
[15:57] <hallyn_> if i just had it say 'list empty' or 'list not empty' i coudl still reproduce,
[15:58] <hallyn_> but adding looping over the list, that heisenberged on me
[15:58] <bdmurray> jhunt:         - ProcEnviron: A subset of the process' environment (only some standard
[15:58] <bdmurray>           variables that do not disclose potentially sensitive information, plus
[15:58] <bdmurray>           the ones mentioned in extraenv)
[15:59] <jhunt> bdmurray: maybe apport could be tweaked to include all environment variables *names* (but no values)?
[16:00] <jhunt> bdmurray: ... we might get a few 'MY_DODGY_PICS_AND_VIDS_DIR' entries, but... :)
[16:00] <bdmurray> jhunt: what's the value of doing all names?
[16:02] <jhunt> bdmurray: atleast we could know if DISPLAY say has some value. If sensitive, we can then ask for a sample value from the user. Right now, we've only got a small handful of vars. Maybe we just add a few more like DISPLAY in full though.
[16:03] <bdmurray> jhunt: /win last
[16:04] <bdmurray> jhunt: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L392
[16:06] <frafu> kelemengabor : Thanks for the tip about removing the underscore.
[16:06] <kelemengabor> you are welcome :)
[16:08] <jhunt> bdmurray: how about DISPLAY and TERM then? Re env names only, would be useful to just know that LD_LIBRARY_PATH was set to any value I think.
[16:08] <jhunt> bdmurray: and LD_PRELOAD :)
[16:08] <cjwatson> kelemengabor: FYI I corrected a Hungarian translation of gfxboot-theme-ubuntu (s/_/^/)
[16:09] <cjwatson> https://translations.launchpad.net/ubuntu/oneiric/+source/gfxboot-theme-ubuntu/+pots/bootloader/hu/+translate?batch=10&show=all&search=Enlist
[16:10] <kelemengabor> cjwatson: thanks! a bad reflex from me :(
[16:10] <cjwatson> just noticed while merging into the package
[16:13] <bdmurray> jhunt: bug 868501
[16:14] <jhunt> bdmurray: thanks!
[16:38] <Laibsch> Can somebody help me understand where the package alarm-clock-applet picked up the run-time dependency on gconf2 >= 2.28.1-2 although that package is not in the PPA or its dependencies?  The same package locally compiled has a dependency on gconf >= 2.10.1-2
[16:38] <Laibsch> https://launchpad.net/~r0lf/+archive/stable/+packages
[17:05] <jtaylor> is someone working on bug 851383? it would be a shame to release with a broken geany (and possible other gtk2 apps) :/
[17:06] <jtaylor> apparently caused by a libgtk2.0-0 2.24.6 regression
[17:24] <tjaalton> isn't auth-client-config deprecated? still in main, no updates in over three years
[17:30] <micahg> ok, so chromium failed to build on armel, I disabling --no-add-needed will fix it, I hate to do it, but we're close to release and I don't want to block armel images (if they exist for lubuntu/mythbuntu), opinions?
[17:40] <slangasek> tjaalton: I don't believe there's anything else that implements the NSS side of things
[17:41] <tjaalton> slangasek: but it conflicts with pam-auth-update? maybe it just needs some cleanup & love, and of course support for sssd :)
[17:42] <tjaalton> conflicts as in functionality wise
[17:42] <slangasek> didn't I neuter it to *not* conflict with p-a-u?
[17:42] <slangasek> or maybe jdstrand did
[17:42] <tjaalton> oh, the changelod does mention something about that
[17:43] <tjaalton> nevermind then, haven't actually ran it myself, just heard that it exists
[18:02] <jdstrand> I should probably remove it
[18:03] <jdstrand> some people do still use it aiui, so I've been reluctant
[18:08] <tjaalton> jdstrand: not so fast, it could still prove useful :)
[18:11] <jdstrand> heh
[18:12] <jdstrand> well, I'll take some time to look at it
[18:19] <hallyn_> jamespage: fwiw http://people.canonical.com/~serge/udev-debug.debdiff is the simplest patch i'm trying to debug with
[18:25] <infinity> micahg: There are no ARM images for lu/myth, but it would still be nice to not have it broken..
[18:54] <ScottK> jtaylor: there's an upload in queue to address it.
[18:55] <jtaylor> ah good
[18:57] <jtaylor> hm only that one patch added?
[18:57] <jtaylor> that did not fix it for me
[18:58] <barry> ScottK: bzr merging sid's python3-defaults source branch into oneiric's is not conflict-free.  however, i think we can drop the one ubuntu delta in our branch, so i'm thinking a sync would be better, except for this: http://pastebin.ubuntu.com/702924/
[18:58] <barry> ScottK: thoughts?
[18:59] <jtaylor> maybe I screwed it up, building the apcakge
[18:59] <ScottK> I think some of the versions need to be different in the maintainer scripts for when 3.2 became supported.
[18:59] <ScottK> I may be wrong though.
[19:00] <ScottK> It can't actually be a sync though due to the version differences.
[19:00] <barry> ScottK: here are the diffs from doko's last change: http://paste.ubuntu.com/702928/
[19:01] <barry> ScottK: so essentially, all those will be mirrored or overwritten in a "sync"
[19:02] <ScottK> Right, but we need the 3.2~rc1/3.2.2 changes.
[19:03] <barry> ScottK: yes, but after a merge debian/rules will have this:
[19:03] <barry> PREVVER := 3.2.2~rc1
[19:03] <barry>  
[19:03] <ScottK> Right and it needs to be 3.2.2.
[19:04] <superm1> jtaylor, i wasn't able to reproduce it in geany with that patch
[19:04] <barry> probably 3.2.2-0ubuntu2. because of the version numbers, as you say we can't do a straight sync, so i'll try to smack bzr merge-package around some more
[19:05] <superm1> jtaylor, you were just opening the 'file open' dialog several times right?
[19:05] <jtaylor> superm1: weird, I'm almost done building
[19:05] <barry> ScottK: ^^.  not sure why merge-package is puking all over the merge tho :/
[19:05] <jtaylor> superm1: you have to open a file once first
[19:05] <jtaylor> I'm also cloning git to see it there something else needed, but that will take a while with my connection ._.
[19:05] <superm1> jtaylor, yeah i tried several different ways to open it, geany $ARGS followed by opening a file
[19:05] <ScottK> barry: You and your fancy UDD stuff are on your own for that bit ...
[19:06] <barry> ScottK: ;)
[19:06] <superm1> and # geany, open a file and then try to open another
[19:06] <superm1> wasn't getting any crashes with it applied
[19:06] <jtaylor> k maybe I screwed something up while patching
[19:07] <barry> ScottK: yeah, i'm just afraid that if i go old skool, the udd importer will choke on it, which will just make things more crappy.  /me wonders if james_w has any thoughts
[19:08] <ScottK> barry: It won't make things crappier for the actual code in the archive, so I'd suggest short that out later when we aren't in a time crunch.
[19:08] <hallyn_> Daviey: are you around?
[19:09] <barry> ScottK: yeah, you have a point there
[19:15] <james_w> barry, what does the puke look like in this case?
[19:16] <barry> james_w: http://pastebin.ubuntu.com/702939/
[19:17] <james_w> barry, urgh
[19:17] <barry> james_w: i don't get the debian directory conflict
[19:17] <james_w> barry, what's the diff -r ancestor:../sid look like?
[19:18] <barry> james_w: http://paste.ubuntu.com/702940/
[19:20] <james_w> barry, odd, it looks like it somehow has a different root file id or something
[19:20] <james_w> I'm not sure how to deal with that exactly
[19:21] <james_w> a merge and then returning all the contents of the files to what is desired (without using revert) would be one (perhaps painful) way of doing it
[19:21] <barry> james_w: i can generate a diff in the sid branch and manually change the oneiric branch, so for immediate purposes, i can muddle through.  is it possible when p opens to just blow away the oneiric branch and overwrite it with the sid branch (i.e. just sync us back up with debian)?
[19:22] <james_w> that wouldn't reflect reality though
[19:22] <james_w> and likely the problem would continue with p
[19:22] <barry> hmm
[19:22] <james_w> applying the diff indeed works, but the same thing will occur next time you want to do a merge
[19:25] <barry> james_w: my concern is that after the merge debian/ only has the conflict files, while debian.moved/ has all the good stuff in it, though i'm not sure their contents is what we ultimately want
[19:25] <james_w> yeah
[19:26] <james_w> barry, that would be the (perhaps painful) :-)
[19:27] <barry> james_w: so i'm thinking: apply the patch and produce a source package for ScottK to approve for his time-constrained need.  then go through the painful merge to see if i can get some sanity.  that painful merge can even wait in a separate branch until p opens up
[19:28] <james_w> that sounds good to me
[19:28] <barry> cool, thanks
[20:01] <adam_g> slangasek: i just hit the bug with udev event logging.
[20:01] <slangasek> adam_g: yay!  Dump please :)
[20:01] <adam_g> slangasek: http://paste.ubuntu.com/702960/
[20:02] <adam_g> im still hung in manual recovery, if there is anything else you want me to poke at. i can dump a log of a successful boot if thats useful
[20:03] <slangasek> a successful boot would be nice to compare with, yes
[20:03] <slangasek> also, would be great if you can attach both to the bug so we don't lose them
[20:04] <slangasek> adam_g: to be clear, this is bug #818177? or #862823?
[20:06] <adam_g> slangasek: 818177
[20:06] <slangasek> ok
[20:09] <shadeslayer> jono: does half a pitcher of beer count as drunk? :P
[20:12] <adam_g> slangasek: http://paste.ubuntu.com/702962 <- a good boot. both logged on the ticket
[20:21] <Daviey> hallyn_: o/
[20:25] <barry> ScottK: here's the diff.  i'm building it in my ppa for testing and if it looks good, i'll dput the package (unless you want to give the thumbs up now): http://paste.ubuntu.com/702967/
[20:27] <ScottK> prevver shouldn't change.
[20:27] <ScottK> Other than that, looks good.
[20:27] <ScottK> Please upload when that's fixed and you're ready.
[20:27]  * barry nods
[20:32] <hallyn_> Daviey: is there a certain step in package creation that is supposed to substitute in the right values for '@sysconfdir@', or do we need to do that by hand in debian/rules?
[20:39] <hallyn_> suppose i'll just do it by hand...
[20:47] <mdke> I've uploaded a new ubuntu-docs with translations. If someone could approve this so that the translations will be included in the langpacks for the release, that would be much appreciated
[20:50] <jono> shadeslayer, lol
[21:10] <Daviey> hallyn_: Good question.  I believe that is DEB_CONFIGURE_SYSCONFDIR
[21:10] <jtaylor> I supose updating gtk2 to git HEAD for oneiric is not possible at this stage or?
[21:11] <jtaylor> the gtk2 24.6 filechoser mess cleanup is pretty much impossible to backport without making some mistake :/
[21:12] <Daviey> hallyn_: if it is dh, you could do: override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/
[21:12] <micahg> jtaylor: superm1 updated gtk2 for a crash in the filechooser
[21:12] <Daviey> (there is a linebreak and tab between :)
[21:12] <jtaylor> yes but not correctly
[21:12] <superm1> micahg, unfortunately it's sounding like there might be another codepath that was causing the crash too
[21:12] <micahg> ah, ok
[21:12] <superm1> it fixed it for me, but it's still happening to jtaylor
[21:12] <jtaylor> no blame on him, its not easy to backport this 1000 line diff
[21:13] <micahg> well, is it only on installed systems or live media as well?
[21:13] <hallyn_> Daviey: sysconfdir is being set right for the code, it just isn't being expanded in the manpage
[21:14] <hallyn_> Daviey: what you suggest is for if that isn't being set in configure right?
[21:14] <bdmurray> slangasek: would moving bug 745501 to file-roller be the right thing?
[21:20] <RAOF> ScottK: I haven't requested a dbus-sharp sync?  If it's a sync of 0.7.0-4 then it will indeed be a no-op.  That might be Laney driving needless diff-from-debian down.
[21:20] <TheMuso> ScottK: Oh thanks so much for pushing that fix for pulse. I was looking to do the same.
[21:20] <TheMuso> ScottK: Do you have a bzr branch you used anywhere, so I can sync up the packaging branch?
[21:20] <ScottK> TheMuso: Great.
[21:20] <ScottK> TheMuso: No.  I dput it.  I figured the importer would handle it.
[21:21] <TheMuso> Ok.
[21:21] <ScottK> (I grabbed the other change that was pending in bzr, so the diff from what's there is what I added to the package)
[21:21] <TheMuso> ScottK: we don't use the ubuntu branches for packaging. Never mind, I'll fix it up.
[21:21] <ScottK> Oh.  Thanks.
[21:21] <ScottK> I thought the Vcs-* field pointed there.
[21:25] <TheMuso> No it doesn't, but never mind.
[21:28] <slangasek> bdmurray: I suppose so :)
[21:28] <slangasek> bdmurray: (as opposed to redirecting it to someone who speaks German?)
[21:29] <bdmurray> slangasek: don't you? is the german about file-roller or something else?
[21:31] <Daviey> halyno, that is for if it IS for ./configure
[21:31] <Daviey> (DISLAIMER: i have been wrong before.)
[21:32] <Daviey> hallyn_: ^^
[21:32] <slangasek> bdmurray: it's about an "archive", and he reported it via file-roller... so that may be what he's referring to
[21:32] <slangasek> he seems to be saying he can no longer create archive files through file-roller
[21:35] <bdmurray> slangasek: got it thnaks
[22:19] <jtaylor> success! f4814585 aa8f54b736 79d16aab need picking, maybe one of them can still be removed
[22:20] <jtaylor> but that I'll do tomorow gn8
[22:26] <slangasek> adam_g: it would probably be useful to see if some lvm-related scripts are still running at the time everything gives up
[22:38] <broder> "Ubuntu precise" - that's going to take a while to get used to parsing
[22:38] <cjwatson> indeed
[22:44] <barry> stgraber: ping
[22:45] <stgraber> barry: pong
[22:46] <infinity> broder: Yeah, but we'll have the best post-release updates ever with precise-security and precise-updates.
[22:46] <broder> ha!
[22:46]  * ajmitch thinks that quickly should be renamed to precisely
[22:47] <infinity> ajmitch: You've clearly not looked at what it does.
[22:47] <ajmitch> wouldn't you want to 'precisely package'?