[02:37] <ebroder> bdrung: Have you released a version of ubuntu-dev-tools with SPONSOR_PATCH_BUILDER yet? Because I want to factor that code into a library that sponsor-patch and backportpackage share, at which point it should probably be UBUNTU_TOOLS_BUILDER or something
[02:37] <ebroder> (If you've released it already, I can just leave some backwards compatibility code lying around)
[06:27] <hychen_> freeflying, I added https://launchpad.net/~ubuntu-sru to the bug I reported, is this right?
[06:29] <freeflying> hychen_: subscribed?
[06:29] <hychen_> freeflying, yes
[06:33] <freeflying> hychen_: is the package in universe or main?
[06:33] <hychen_> freeflying, universe
[06:33] <hychen_> freeflying, it is from debian
[06:33] <micahg> in most cases subscribing ubuntu-sru isn't correct anymore as the SRU team reviews in teh upload queue
[06:34] <hychen_> freeflying, I also have a question, when pkg in proposed goes to update archive?
[06:35] <freeflying> hychen_: after ftp-master check and approve it
[06:35] <freeflying> micahg: so, in hychen_'s case, he gonna seek for a sponsor to upload it into maverick-proposed?
[06:35] <hychen_> freeflying, so the issue also need to be fix in next release?
[06:36] <micahg> freeflying: so, ubuntu-sponsors should be subscribed, not ubuntu-sru
[06:37] <micahg> also, Ubuntu doesn't have ftpmasters, the archive admins will move an update from -proposed to -updates after the test case has been verified and it's been in -proposed for a week
[06:37] <krishna_m28> how can i contribute ? I am a experienced C,c++ programmer
[06:38] <hychen_> micahg, is any wiki page mentioned this?
[06:38] <freeflying> micahg: same job, different titles
[06:38] <micahg> hychen_: which thing?
[06:39] <freeflying> hychen_: you can send me debdiff, I will upload it for you :)
[06:39] <micahg> hychen_: should all be here: https://wiki.ubuntu.com/StableReleaseUpdates
[06:40] <hychen_> micahg, thanks , I think I miss some important sections, I'll reviewed it again
[06:42] <hychen_> freeflying, the debdiff is http://tinyurl.com/28ylvl7, but I don't know how to version the package correctly
[06:42] <hychen_> freeflying, should I change the series to maverick-proposed?
[06:43] <freeflying> hychen_: in which version did you find it?
[06:43] <hychen_> freeflying, 1.3.7.20100910-1 in debian
[06:43] <hychen_> freeflying, and is already sync to Natty
[06:44] <micahg> actually, 1.3.9.2-1 is in sid and natty
[06:45] <hychen_> micahg, it is ibus-chewing not ibus
[06:45] <freeflying> hychen_: the one in maverick is ibus-chewing-1.3.6.20100730?
[06:45] <hychen_> freeflying, yes
[06:45] <micahg> ibus is at 1.3.8-1
[06:46] <hychen_> micahg, you are right, my information is old, sorry
[06:46] <freeflying> hychen_: A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.
[06:47] <freeflying> hychen_: maybe you shall consider of backport it from natty
[06:49] <hychen_> freeflying, follow https://help.ubuntu.com/community/UbuntuBackports . right?
[06:51] <freeflying> hychen_: I think so
[06:51] <xnox> There isn't a lp:ubuntu/libtool
[06:51] <xnox> libtool doesn't show up on merges.ubuntu.com (although it should?)
[06:51] <freeflying> hychen_: btw, ibus-chewing is in main
[06:51] <xnox> and it's outdated
[06:51]  * xnox libtool is wonderful
[07:00] <micahg> xnox: no, it's only newer in experimental (that doesn't mean it can't be merged though)
[07:00] <xnox> micahg, will be a bit of pain without lp:ubuntu/libtool and lp:debian/libtool
[07:01] <micahg> xnox: you should have bzr branches available
[07:03] <xnox> micahg, http://package-import.ubuntu.com/status/libtool.html
[07:03] <xnox> AssertionError: Can't find the needed upstream part for version 2.2.6a-4
[07:04] <micahg> xnox: oh well, I guess not
[07:05] <micahg> xnox: just diff natty against sid and apply to experimental
[07:05] <xnox> that's my plan =)
[07:07] <xnox> Anyone ever used pull-debian-debdiff?
[07:07] <micahg> hmm, fascinating
[07:09] <xnox> micahg, I'll use import-dsc to import the three packages - base, mine, other, just to use merge-package
[07:09] <xnox> =)
[07:10] <micahg> xnox: ok, but that seems like a lot harder
[07:10] <xnox> micahg, but I will be able to diff without pain =) push to lp and use a recipe for test builds :-P
[07:11] <xnox> or $ bzr bd-p
[07:11] <xnox> bzr alias bd-p='bd --builder="pdebuild"'
[07:11] <micahg> xnox: there's no Ubuntu branch from what I can tell
[07:12] <xnox> So? =) I can still push to lp:~/libtool/udd-fail
[07:12] <micahg> xnox: if you like :)
[07:12] <micahg> xnox: you can also check for a bug on teh udd project
[07:17] <xnox> micahg,
[07:17] <xnox> $ bzr merge-package ../experimental/Text conflict in debian/patches/series
[07:17] <xnox> 1 conflicts encountered.
[07:17] <xnox> The merge resulted in 1 conflicts. Please resolve these and commit the changes with "bzr commit".
[07:17]  * xnox loves bzr-bd =)))))
[07:20] <didrocks> good morning
[07:37] <dholbach> good morning!
[07:38] <pitti> Good morning
[07:39] <micahg> pitti: good morning, can you take a quick look at a response for me to a bug before I send it?  http://pastebin.ubuntu.com/542951/ for bug 688781
[07:43] <pitti> micahg: it's certainly an answer I can agree to :) we did put new upstream microversions into stables in the past, and sqlite has tons and tons of tests, but if people want to go ahead with that, we need to review the upstream changelog
[07:43] <pitti> micahg: if .2 -> .3 is just three bug fixes, we might as well take it as it is
[07:43] <pitti> if it has 50 changes, then backporting is better
[07:43] <pitti> (IMHO)
[07:44] <micahg> pitti: I can only find one instance of an update of sqlite3 and it was for a single patch in jaunty
[07:44] <pitti> micahg: I mean for other packages, not for sqlite
[07:44] <micahg> pitti: ah, ok
[07:44] <micahg> pitti: .3 adds 2 interfaces, not just bug fixes
[07:45] <micahg> http://www.sqlite.org/releaselog/3_7_3.html
[07:45] <pitti> micahg: I guess it's then worth looking at a diff, and checking if that just adds new code (that should be rather harmless, as existing sw doesn't use it)
[07:46] <pitti> micahg: anyway, this kind of research should be done by the requestor of the SRU
[07:47] <tumbleweed> anyone know what's happening in bug 689345? (ancient amd64 deb still published in natty, arch:any package only seems to get built on i386 these days)
[07:49] <micahg> pitti: ok, I watch the bugs because xulrunner depends on it, also, this started because of a OMGBuntu post, so I'm guessing the users on the bug are less technical
[07:49] <pitti> micahg: I guess in this case your response is just fine :)
[07:51] <micahg> pitti: if you think it's worthwhile, I can review the upstream changes
[07:54] <pitti> micahg: it's a lot of testing and risk involved (sqlite is used by a lot of software), so I'd still like the requestor to at least do a more through analysis of the changes
[07:54] <micahg> pitti: I definitely agree with that, I'll post my comment, thanks
[07:54] <pitti> micahg: "I" wouldn't go ahead with it on my own personally
[07:55] <micahg> pitti: I'm also adding a line about a lot of apps using it and the burden of testing
[08:03] <micahg> pitti: thanks, I have trouble sometimes deciding how much work the reporter should do
[08:04] <pitti> micahg: of course, if you would like to do that, please do
[08:05] <micahg> pitti: not really, I just wanted to make sure I wasn't asking too much
[09:10] <smb> @pilot in
[09:10]  * smb has little clue yet how to go on...
[09:16] <dholbach> hey seb128!
[09:18] <seb128> dholbach, hey! how are you?
[09:18] <dholbach> great - thanks - how are you?
[09:18] <seb128> I'm fine thanks
[09:18] <seb128> we was nice
[09:19] <seb128> I just have to catch up on 3 days backlog now ;-)
[09:33] <cjwatson> doko: is the pastewebkit sync in cocoplum:~lp_archive/syncs/ yours?  perhaps you meant to flush it?
[09:35] <doko> cjwatson: yes, forgot to sync
[09:46] <cjwatson> doko: shall I flush it now?
[09:48] <doko> cjwatson: sorry, otp. done now
[09:49] <cjwatson> ok, thanks
[10:00] <Keybuk> jhunt: maw-neeng
[10:14] <smb> doko, moin, should I be able to dist-upgrade a maverick chroot to natty by now or is that still known to be broken (it seems one I started last week still does not get ahead, but maybe I should start over)?
[10:16] <doko> smb: which package version of python is currently on your system>
[10:16] <doko> ?
[10:17] <smb> doko, Well it is python2.7-minimal that fails with pycompile:240: requested versions not installed. But python2.6 seems still installed
[10:18] <doko> smb: that was not my question. what does dpkg -l python show
[10:18] <doko> ?
[10:19] <smb> python 2.6.6-2ubuntu1
[10:19] <smb> (ii)
[10:20] <doko> and dpkg -l python-dev python-dbg ? (start the lines with ii?)
[10:22] <smb> no
[10:22] <smb> both un
[10:23] <smb> As noted, I started that upgrade last week. Probably some upgrade path was not right then. And now it won't get out. But I can easily just start over
[10:24] <doko> smb: please get the packages python-minimal and python from https://launchpad.net/ubuntu/+source/python-defaults/2.7.1-0ubuntu3/+build/2094391
[10:25] <doko> then do install these two deb's with sudo dpkg --unpack python*deb
[10:25] <doko> and run sudo dpkg --configure --pending
[10:25] <doko> then run an apt-get update && apt-get dist-upgrade
[10:30] <smb> doko, python depends on python2.7 which is not installed
[10:32] <doko> smb: ok, then get this too from the archive, and dpkg --unpack that too
[10:33] <janimo> pitti: hello. Did my previous upload to libgphoto2 introduce a langpack related regression or was that always there (the one you just fixed) ?
[10:33] <pitti> janimo: langpack?
[10:33] <pitti> janimo: the one I fixed came from Debian
[10:33] <smb> doko on the lp page you pointed me to, is that a special name? Cause I do not see a python2.7_...
[10:33] <pitti> I sent the fix there, too
[10:34] <janimo> pitti: ok,, I got some mail related to Chinese .po
[10:34] <janimo> a few days after uploading
[10:34] <pitti> janimo: ah, ignore those
[10:34] <pitti> well, they are bugs in the .po files
[10:34] <pitti> but we don't touch them in Ubuntu
[10:34] <janimo> pitti: ok, thanks
[10:34] <pitti> frankly these are mostly spamn
[10:35] <doko> smb: dpkg -l python2.7-minimal python2.7 ?
[10:36] <smb> ii  python2.7-mini 2.7.1-1ubuntu1 A minimal subset of the Python language (ver
[10:36] <smb> No packages found matching python-2.7.
[10:36] <smb> But I guess I need to follow https://launchpad.net/ubuntu/+source/python2.7
[10:36] <smb> not python-default
[10:42] <smb> doko, Ok, with manually installing python2.7, python (2.7) and python-minimal (2.7), the installation seems to sort itself out
[10:42] <doko> smb: ok, thanks for confirming
[10:43] <smb> doko, sure. thanks for sorting it out.
[10:47] <janimo> Laney: hello
[10:49] <janimo> Laney: ghc6 ftbfs on armel again, but this time it looks like a hung build after 18h+ and not package specific problems.
[10:57] <Keybuk> the funny thing about that exim security notice is that I'd given up with exim and purged it from my mail server about one minute before kees' mail arrived
[10:57] <bdrung> ebroder: i released it already, but we can change it
[11:00] <ebroder> bdrung: I went ahead and wrote up the compatibility code, but whatever you prefer
[11:01] <bdrung> ebroder: it's up to you to drop the compatibility code
[11:02] <ebroder> bdrung: Fine. If you're going to make me make the call, I'll leave it since it's already written
[11:02] <bdrung> ok
[11:09] <smb> @pilot out
[11:09]  * smb -> lunch
[11:10] <ebroder> Keybuk: OOC, are you planning to have Upstart create implicit jobs from .service files for D-Bus activation, or make people that want to use it write proper Upstart jobs?
[11:10] <Keybuk> implicit jobs?
[11:11] <ebroder> I'm not sure what exactly I'd call them. "Use /usr/share/dbus-1 as a configuration source"
[11:11] <Keybuk> you mean jobs that are based on different configuration parsers?
[11:12] <ebroder> Why yes, that's exactly what I was fumbling to say
[11:12] <Keybuk> the main use case for that is parsing /etc/init.d - which is already done by someone else
[11:12] <Keybuk> so es
[11:12] <Keybuk> yes
[11:12] <Keybuk> I'm not sure there'd be a benefit to parsing /usr/share/dbus-1 as long as there's a dbus-daemon
[11:12] <Keybuk> since that's parsing it anyway
[11:12] <Keybuk> you'd need to somehow tell dbus-daemon to ignore its own configuration and send upstart events instead
[11:12] <Laney> janimo: really? looks built to me
[11:13] <ebroder> Keybuk: I had sort of figured that's what you would do. Otherwise what's the point of D-Bus activation?
[11:13] <janimo> Laney: I'll check again, I looked on Saturday and it said it waskilled fter a timeout of 15 minutes
[11:13] <Laney> janimo: don't know if it works though
[11:13] <janimo> Laney: I'll check, thanks
[11:14] <Keybuk> ebroder: the end goal of having init do is that it means dbus-daemon doesn't have to any longer
[11:14] <Keybuk> and means we could get rid of dbus daemon in the future
[11:14] <Keybuk> plus you can combine it with other things only init knows about, e.g. init can know that it can't activate that job right now, because its other requirements aren't met
[11:15] <ebroder> Keybuk: Sure. It seems like a useful intermediate state would be to do exactly what you described, and have D-Bus use Upstart for service supervision
[11:17] <ebroder> Keybuk: It doesn't seem like replacing the service starter with an Upstart event emitter should be that bad. Presumably dbus-daemon already has to separate service activation from actually delivering the message that spawned the service, since the message doesn't get delivered until the service finishes initializing itself
[11:21] <Keybuk> right indeed
[11:21] <Keybuk> I have that bit on my work items for this release
[11:21] <ebroder> Keybuk: I know, I've been following. I was just seeing if I understood the plan correctly
[11:21] <Keybuk> not expecting it to take more than a week to get working
[11:21] <Keybuk> yeah initially the plan is to just have dbus emit the event though
[11:21] <Keybuk> not for upstart to also parse dbus's config for it
[11:21] <bdrung> ebroder: the builder class needs an "update" function
[11:22] <Keybuk> if that turns out to be necessary
[11:22] <Keybuk> then it's not hard
[11:23] <ebroder> bdrung: "update" as in "run apt-get update; apt-get dist-upgrade in this chroot"?
[11:23] <ebroder> Keybuk: Got it. Thanks
[11:23] <bdrung> ebroder: yes. for pbuilder "sudo pbuilder update"
[11:24] <bdrung> ebroder: and then a command line parameter for updating the builder before building
[11:25] <ebroder> bdrung: I'm happy to do that, but can I do it as a separate branch? The backportpackage branch is already starting to become sort of massive
[11:25] <ebroder> bdrung: I can open a ticket about it and assign it to myself
[11:26] <bdrung> ebroder: yes
[11:51] <Laney> janimo: looks broken: see bug 689496, trying the patch there now
[11:51] <janimo> Laney: hmm so it builds packages but does not make them correct?
[11:52] <Laney> right
[11:52] <janimo> ok
[12:06] <janimo> Laney: at least Setup.hs built, since some of the packages progressed on retry
[12:08] <Laney> janimo: It's in the RTS, so I hope the next version will fix it
[12:08] <janimo> great
[12:16] <pitti> cjwatson: would you mind if I test/apply the patch in bug 415038 before you consider it for Debian?
[12:27] <cjwatson> pitti: it's on my queue to review today-ish
[12:27] <cjwatson> pitti: I'd prefer if I reviewed it before we applied it
[12:27] <cjwatson> there are all sorts of amusing things that could go wrong with a broken frontend
[12:27] <pitti> cjwatson: ok; it needs some porting to the current version, so I'll do that and attach the patch
[12:27] <cjwatson> non-trivial porting?
[12:28] <pitti> yes
[12:28] <cjwatson> hm, ok
[12:28] <pitti> the current version disables some window functions (close button, etc); should be "easy", but not just simple fuzz
[12:28] <pitti> and I generally want to test it with synaptic and s-c before we roll this out
[12:29] <cjwatson> I want to test some of the more obscure features of debconf
[12:30] <pitti> cjwatson: right; so it sounds we'll work on different things then
[12:30] <cjwatson> I'll wait 'til you attach your current version before starting
[12:32] <bdrung> ebroder: the "# TODO: Add "retry" and "update" option" was for adding a option to ask_for_manual_fixing() to update the builder from there
[12:32] <pitti> cjwatson: is there a quick method to use "test_debconf.pl" or similar with the gnome frontend? (quicker than rebuild/install/synaptic install xdm)
[12:34] <pitti> aah
[12:34] <pitti> DEBIAN_FRONTEND=gnome samples/demo
[12:36] <cjwatson> yes
[13:08] <asac> pitti: whats the status of the kernel SRU for bug 651370 ?
[13:10] <pitti> asac: it awaits regression testing from our QA team
[13:11] <asac> pitti: thanks. is that happening automatically? or should we send a reminder?
[13:11] <pitti> asac: reminder already happened
[13:12] <asac> kk
[13:18] <pitti> cjwatson: I ported janimo's patch, but it apparently doesn't return correct values now; I'll investigate further after lunch
[13:22] <smb> @pilot in
[14:00] <smb> Hm, for requests that ask for merging newer debian versions into ubuntu and there is a debdiff. Is there a simple way to get the new orig.tar.gz or do I have to search?
[14:01] <cjwatson> you can set up chdist to have a configuration pointing to Debian unstable, and then use 'chdist apt-get unstable -d source <packagename>'
[14:01] <cjwatson> man chdist
[14:01] <pitti> smb: I usually download it from the PTS (http://packages.qa.debian.org/pkgname) or my unstable chroot
[14:02] <smb> pitti, Ah thanks. Dumb follow up: what does PTS stand for?
[14:02] <pitti> smb: Package Tracking System
[14:02] <Keybuk> Package Tracking System
[14:03] <smb> Heh, ok. Thanks
[14:04] <Keybuk> cjwatson: I have a C/POSIX-ish query for you
[14:04] <cjwatson> I always love those
[14:04] <Keybuk> need a competant lawyer to validate my idae
[14:04] <Keybuk> (and my spelling)
[14:04] <Keybuk> would this be wrong?
[14:04] <Keybuk> union {
[14:04] <Keybuk>     struct tm tm;
[14:05] <Keybuk>   int bits[7];
[14:05] <Keybuk> };
[14:05] <cjwatson> what were you then planning to do with that union?
[14:06] <Keybuk> well, the idea is that bits[0] is then directly equivalent to tm.tm_sec
[14:06] <Keybuk> bits[3] is tm.tm_mday
[14:06] <elmo> in the library with the revolver
[14:06] <Keybuk> bits[6] is tm.tm_wday
[14:06] <Keybuk> and use the array as a way of indexing the components of the struct
[14:06] <cjwatson> my gut feel is that that's the sort of thing where strict-aliasing trips you up
[14:08] <cjwatson> which would be likely to cause optimisation difficulties aside from anything else
[14:08] <cjwatson> though are you asking if the alignment is guaranteed to be identical?
[14:08] <Keybuk> ah, but it's a union
[14:09] <Keybuk> strict-aliasing doesn't apply to unions
[14:09] <Keybuk> (that's kinda the point of them)
[14:09] <cjwatson> um
[14:09] <cjwatson> sort of
[14:09] <penguin42> is the ordering of that even vaguely guaranteed to be portable?
[14:10] <Keybuk> penguin42: that's kinda my question really
[14:10] <Keybuk> I'm pretty sure that a struct of 7 ints is directly equivalent to an array of 7 ints
[14:10] <Keybuk> and have put the book down
[14:10] <cjwatson> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html points out that using unions for that is technically undefined unless one of the punned elements is a char *
[14:10] <cjwatson> (although widely supported anyway)
[14:11] <cjwatson> (best explanation I've found of strict-aliasing and related issues)
[14:13] <Keybuk> yeah I was reading that
[14:14] <Keybuk> the idea of my hack above is that by putting the tm and int array into the union
[14:14] <Keybuk> you're declaring to the compiler that they *do* share the same memory location
[14:15] <Keybuk> it's not a pointer to the tm, it's the tm itself that's in the union
[14:16] <cjwatson> OK, so.  structs are memory-ordered in declaration order (6.2.7.1(5,13)).  There may be unnamed padding within a struct (6.2.7.1(13)).  Arrays are "contiguously allocated" (6.2.5(20)), while structs are merely "sequentially allocated".
[14:16] <cjwatson> I think you're in an area that in practice will always work but is not technically defined thus
[14:16] <cjwatson> (because for it not to work, you'd have to need alignment for ints, which would be a strange implementation choice)
[14:17] <Keybuk> even if you had alignment for ints, both the array and struct would have to align on that boundary, no?
[14:17] <Keybuk> it'd only not work if the struct as a whole was aligned to something far wider than the int alignment
[14:17] <cjwatson> that's not how I read "contiguously allocated"
[14:17] <Keybuk> e.g. each member of the struct was on an 8-byte boundary
[14:17] <Keybuk> on a platform with a 2-byte boundary
[14:17] <Keybuk> which I guess the compiler is allowing for
[14:17] <cjwatson> arrays don't get to have internal alignment, even if that's what the platform would normally want
[14:18] <Keybuk> cjwatson: sure they do, otherwise &(a[2]) wouldn't be valid
[14:18] <Keybuk> you can't take the address of an unaligned object
[14:18] <Keybuk> s/compiling is allowing for/standard is allowing for/
[14:18] <cjwatson> err.  char a[16]; &(a[3]) is permitted on any platform, AIUI.
[14:18] <Keybuk> sure because the alignment rules of char * are 1
[14:19] <smoser> pitti, is there any thing blocking moving cloud-init into lucid-updates.  (0.5.10-0ubuntu1.5  bug 683890)
[14:19] <cjwatson> none of this means that arrays ever have internal alignment
[14:19] <cjwatson> show me an example where they ever do
[14:19] <Keybuk> ok, hypothetical platform
[14:19] <cjwatson> my understanding is that that's explicitly forbidden by "contiguous allocation"
[14:19] <Keybuk> this platform has 8-byte alignment for int
[14:19] <Keybuk> but 4-byte ints
[14:20] <cjwatson> otherwise, what does the difference between "contiguous" and "sequential" mean?
[14:20] <Keybuk> if you had an array of two ints that was 4-byte aligned rather than 8-byte aligned
[14:20] <Keybuk> then:
[14:20] <Keybuk>   int *a = &(a[1]);
[14:20] <Keybuk> would be useless
[14:20] <Keybuk> you couldn't retrieve *a or assign to *a without breaking the platform's alignment rules
[14:20] <smb> pitti, Another of my stupid questions: in the maintainers section is a change from "Ubuntu Core Developers" to "Ubuntu Developers" correct?
[14:21] <Keybuk> I was suggesting that the standard is allowing the struct to use a wider alignment if it needs to
[14:21] <Keybuk> e.g. even if the int was 4-byte aligned, it could choose to 8-byte align the struct members
[14:21] <Keybuk> (perhaps it aligns them to the largest alignment of any member)
[14:21] <cjwatson> that works as a reductio ad absurdum, but only if the alignment of ints is the only reason why the platform might insert internal padding into a struct
[14:21] <cjwatson> right, and *that* would break your model.  but in practice I doubt it will happen ...
[14:21] <Keybuk> yeah, it'd be an odd thing to do :p
[14:21] <dholbach> smb, we changed to "Ubuntu Developers" (https://wiki.ubuntu.com/DebianMaintainerField)
[14:22] <Keybuk> deliberately inserting space into structs would be curious
[14:22] <Keybuk> but maybe the standard isn't disallowing it
[14:22] <Keybuk> thus the difference in terminology
[14:22] <dholbach> smb, so we don't distinguish between packages that are in main or in universe
[14:22] <cjwatson> the standard doesn't forbid it, that's all.  and since you were asking for standards lawyering :)
[14:22] <smb> dholbach, Ok, thanks. Then it is correct as it is
[14:22] <Keybuk> (likewise in practice, no platform I've ever heard of uses anything other than word or int-sized alignment for int types)
[14:22] <cjwatson> right
[14:23] <Keybuk> so I guess it's a decision of whether to err on the side of "this works, and gcc doesn't even complain" or not
[14:23] <cjwatson> wait, one other question
[14:23] <cjwatson> POSIX doesn't, AFAICS, guarantee the *ordering* of struct tm members
[14:23] <cjwatson> it says "The <time.h> header shall declare the tm structure, which shall include at least the following members:"
[14:23] <cjwatson> but nothing about what order they come in, whether extra things can be inserted in between, ...
[14:24] <Keybuk> ah
[14:24] <Keybuk> good catch
[14:24] <cjwatson> I imagine most new platforms copy and paste the sequence from POSIX, but I'm not sure about legacy platforms
[14:24] <Keybuk> so glibc could randomly move that around between releases
[14:24] <doko> Laney: how did you find out about the missing -lpthread in ghc6?
[14:24] <Keybuk> well, I don't really care about legacy platforms
[14:24] <Keybuk> but I do care about Drepper having a brain-wave and breaking code
[14:25] <cjwatson> where "legacy" means "anything that was initially created before POSIX"
[14:25] <Keybuk> though that'd be an ABI break I guess
[14:25] <cjwatson> (er, yeah, slightly eccentric meaning of "legacy" there)
[14:25] <smb> dholbach, Hm, reading the link you posted. Should then, instead of XSBC-Original-Maintainer", the "Debian-Maintainer" be used?
[14:26] <Keybuk> Linux's documentation explicitly declares the order of the fields, of course
[14:26] <dholbach> smb, no XSBC-Original-Maintainer should be fine (update-maintainer from ubuntu-dev-tools usually does that for me :-))
[14:26] <cjwatson> smb: the poll said Debian-Maintainer, but we never used that in practice
[14:27] <smb> Ah, ok.
[14:27]  * smb is just looking at the changes from a debdiff
[14:27] <cjwatson> Keybuk: right, and it would indeed be pretty hard (impossible?) to change without breaking existing binaries
[14:27] <Keybuk> impossible, certainly
[14:27] <cjwatson> Keybuk: again, not sanctioned by standards but probably OK in practice
[14:28] <Keybuk> yaeh, hmm
[14:29] <Keybuk> likewise you couldn't actually change the alignment of the struct :p
[14:29] <Keybuk> so if it works now, it'll work forever
[14:29] <Keybuk> and break when we roll out a new architecture
[14:29] <cjwatson> yeah, nothing to stop a new arch having whatever field ordering it feels like - in theory
[14:37] <Keybuk>    * `A member of a union object is accessed using a member of a
[14:37] <Keybuk>      different type (C90 6.3.2.3).'
[14:37] <Keybuk>      The relevant bytes of the representation of the object are treated
[14:37] <Keybuk>      as an object of the type used for the access.  *Note
[14:37] <Keybuk>      Type-punning::.  This may be a trap representation.
[14:37] <Keybuk> ..
[14:37] <Keybuk> It's a Trap!
[14:39] <pitti> smoser: bug 683379 hasn't been verified yet, but otherwise it looks ok
[14:40] <Keybuk> cjwatson: hmm, reading a bit more
[14:41] <Keybuk> apparently it's *recommended practice* for a compiler to align struct members by the most restrictive member
[14:41] <Keybuk> rather than the individual member's own alignment
[14:41] <Keybuk> (c-faq)
[14:41] <Keybuk> ok
[14:41] <Keybuk> I think I've persuaded myself out of doing that now
[14:45] <smoser> pitti, i had verified that last week, just forgot to mark the tag on that bug (since really the 3 bugs fixed were the same bug)
[14:45] <smoser> i'll go ahead and put a quick verify in though.
[14:49] <kirkland> stock natty + unity, dist-upgraded this morning;  everything across the top bar disappeared (ie, no netwok manager, no sound indicator, no messaging menu)
[14:49] <kirkland> suggestions?
[14:50] <kirkland> (besides "reboot into classic desktop")
[14:50] <penguin42> kirkland: Do you see a seg of unity-panel-ser in your dmesg?
[14:52] <kirkland> penguin42: yeah, there is a video related segfault
[14:52] <penguin42> kirkland: I'm trying to file abug against unity-panel-ser but apport is refusing most annyoyingly
[14:53] <kirkland> penguin42: cool, thanks, subscribe me (kirkland) when you do
[14:53] <didrocks> kirkland: uninstall indicator-datetime
[14:53] <didrocks> kirkland: and restart compiz
[15:00] <smb> Ok, so that debdiff looks mostly ok. What would be the usual mode to go on. Ask the person that has provided the debdiff to bzr pull request? Do it ourselves?
[15:01] <kirkland> didrocks: okay, thanks, will do in a few minutes
[15:04] <doko> cjwatson: ping about bug #688839
[15:08] <cjwatson> doko: I'm not confident with that - please bring it up with the Debian dpkg folks
[15:08] <cjwatson> doko: I suspect that the proposed change would break plugins
[15:10] <cjwatson> but buxy will know more
[15:10] <doko> cjwatson: yes, it would. but making this an error for anything in /usr/lib would be a good thing
[15:11] <doko> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unresolved-symbols-so;users=peter.fritzsche@gmx.de
[15:12] <seb128> doko, it seems it would bring extra work for no real reason
[15:13] <seb128> can't we just set it as a soft goal for natty?
[15:13] <seb128> rather than forcing people to have to deal with builds breaking now
[15:14] <doko> seb128: I don't consider unresolvable symbols at runtime a soft reason
[15:15] <cjwatson> doko: I'm not going to take responsibility for making this change - please discuss it with buxy et al, they have more facts than I do
[15:15] <doko> cjwatson: I'll do
[15:15] <cjwatson> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558872 is listed there and I happen to know that that library would break if you didn't allow that unresolved symbol
[15:16] <cjwatson> it's a slightly weird library that requires the application to supply that symbol
[15:16] <Laney> doko: misbuilds on armel
[15:16] <Laney> geser reported it to me
[15:16] <doko> cjwatson: however I know buxy's reply. debian doesn't build with --no-add-needed, so why do you report it here ...
[15:16] <Laney> sorry, ftbfs not misbuilds
[15:16] <cjwatson> doko: why not let buxy reply rather than putting words in his mouth?
[15:17] <cjwatson> anyway, for me, Debian bug 558872 is an example of why this shouldn't be an error across the board - there has to be a way to override it
[15:17] <doko> well, I got similiar replies from him on dpkg-gensymbols ...
[15:18] <Laney> doko: Anyway, I think I can revert the explicit linking on -lpthread as it was only needed for the bootstrap afaics
[15:19] <Laney> the real fix was a patch I grabbed from the upstream tracker together with the one in ubuntu3
[15:19] <doko> Laney: ahh, ok. just wanted to understand why it was needed
[15:20] <Laney> http://hackage.haskell.org/trac/ghc/ticket/4523
[15:20] <Laney> that ticket
[15:21] <RoAkSoAx> doko: I have a question that you might help me with :). I have a package that FTBFS because of the --no-add-needed thingy... So I modify Makefile.am, but the changes don't apply in build time. So, do I also have to manually modify the Makefile.in or should I run autoreconf to recreate the .in file?
[15:22] <sconklin> @pilot in
[15:23] <doko> cjwatson: could you outline why libcgic needs it?
[15:24]  * JFo waves at the friendly neighborhood patch pilots
[15:24] <cjwatson> doko: I followed up to the Debian bug
[15:24] <cjwatson> doko: it's just how the library is designed, it expects the application to provide that symbol.  I wouldn't have done it that way myself, but it is how it is
[15:25] <cjwatson> (just one I happened to recognise off the list since I maintained the Debian package for it at some point in the past)
[15:25] <doko> ok, thanks for the feedback
[15:25] <Keybuk> Ugh, WHY is this necessary?!  http://paste.ubuntu.com/543086/
[15:26] <Keybuk> *cry*
[15:26] <cjwatson> I think the way it works is that libcgic provides main() itself and you provide cgiMain() which it calls after initialisation
[15:26] <cjwatson> bit weird
[15:26] <geser> RoAkSoAx: I prefer to also patch the Makefile.in if the change is simple and the package doesn't already use autoreconf as I don't know exactly how to autoreconf it properly and not break it
[15:27] <doko> RoAkSoAx: depends on the build system ...
[15:27] <RoAkSoAx> geser: ok thanks ;)
[15:28] <RoAkSoAx> doko: debhelper, package is openhpi
[15:31] <hallyn_> mvo: looking to do a vmbuilder upload.  soren points out you recently did an upload.  What was your process? Did you just make the changes to lp:vmbuilder, drop in a copy of debian/ from the package, and then dput the results?
[15:33] <mvo> hallyn_: hello! I used the "packaging" brnach of vmbuilder for the build
[15:33] <mvo> hallyn_: and in there just "bzr-buildpackage --merge"
[15:33] <mvo> hallyn_: well "bzr-buildpackage --merge -S" to be exact :)
[15:34] <kenvandine> kirkland, did you get a chance to test unity with removing indicator-datetime?
[15:34] <hallyn_> mvo: so you didn't touch lp:vmbuilder at all?
[15:34] <mvo> hallyn_: if you do another bzr snapshot, make sure to use the updated bzr revno in the change, bzr-buildpackage will checkout the right one based on this number (I love bzr-buildpackage)
[15:35] <mvo> hallyn_: initially I didn't, I applied some patches into trunk now though, let me quickly check
[15:35] <hallyn_> mvo: i don't know what that means :)  if i do 'bzr co lp:ubuntu/natty/vm-builder', am  'doing a bzr snapshot'?
[15:36] <mvo> hallyn_: oh, sorry. hold on a sec, I will try to express it better
[15:37] <mvo> hallyn_: I did "bzr co lp:~vmbuilder-dev/vmbuilder/packaging" and then in there "bzr-buildpackage -S" to get the source upload (and without -S to get the deb of course)
[15:38] <hallyn_> interesting, trying
[15:38] <kirkland> didrocks: that worked, thanks
[15:38] <kirkland> kenvandine: worked, thanks!
[15:38] <mvo> hallyn_: the version number is current "0.12.4+bzr459-0ubuntu1" in packaging/changelog, if you want to create a upoad from revno480 just add a new version with revno480 in it
[15:38] <mvo> hallyn_: its magic :)
[15:38] <kenvandine> humm
[15:38] <kenvandine> kirkland, thx
[15:38] <mvo> hallyn_: but note that I'm not really attached to this workflow, you are the maintainer, pick the one that you like best
[15:39] <mvo> hallyn_: it was just what soren used (or at least it looked likt it, the branch was later a bit out-of-sync)
[15:40] <hallyn_> mvo: well on the one hand i don't want to decide until i try this way :)  OTOH i'm afraid i'll totally mess up the archive like i did with kvm
[15:40] <hallyn_> wait, now *why* is version # 0.12.4+bzr459-0ubuntu1 ?
[15:42] <mvo> hallyn_: I'm happy to help and check before uploading etc
[15:43] <hallyn_> mvo: so the rationale is that you have multiple small packaging branches (one per distro), with one shared real source branch?
[15:43] <mvo> hallyn_: I used this version because I did not want to make a new upstream release, afterall I'm not maintianer of the upstream branch
[15:43] <highvoltage> Riddell: hey, as an archive admin you probably noticed a bunch of zope and schooltool related packages uploaded to NEW the last week
[15:43] <mvo> hallyn_: yeah, its frowned upon by some people (hey james_w ;) but its nice in the sense that its tiny
[15:44] <hallyn_> so is debian/watch ignored?
[15:44] <james_w> hi mvo :-)
[15:44] <hallyn_> i'm trying to find a reference to lp:vmbuilder for the main source
[15:44] <highvoltage> Riddell: they are a bit of an exception to the usual process since they do not have needs-packaging bugs
[15:45] <Riddell> highvoltage: I don't really care about needs-packaging bugs
[15:45] <Riddell> I'll process new tomorrow
[15:46] <soren> hallyn_: What do you mean?
[15:46] <mvo> hallyn_: no, its used if there is a upstream release
[15:46] <highvoltage> Riddell: ok, great! if there's anything you need with them, feel free to poke me or dholbach
[15:46] <mvo> hallyn_: again, magic, if you put 1.2.23 there and that is a released version, it will automatically download the right file for you
[15:46] <mvo> hallyn_: I love it
[15:47] <mvo> hallyn_: aha, sorry. that one if in .bzr-builddeb/default.conf
[15:47] <hallyn_> oh, i see, so we do have to create a new release tarball of the lp:vmbuilder source in order to get a new release?
[15:47] <mvo> hallyn_: there is a ref to the right branch
[15:47] <hallyn_> oh
[15:47] <mvo> hallyn_: both works
[15:47] <hallyn_> ok
[15:47] <mvo> hallyn_: for releases, just put a release version number and run bzr-builddeb and it will fetch the tarball from LP
[15:47] <mvo> hallyn_: for bzr versions, it will checkout the right branch
[15:48] <hallyn_> yeah,'put a release number' into the packaging changelog?
[15:48]  * hallyn_ likes magic, but onlymagic he can control
[15:50]  * smb wonders how just some additional upload done by pitti to e2fsprogs helps to reduce the cd size. There did not seem to be a change to the package
[15:51] <pitti> smb: I set debian/build_pressure to 10 kPa :)
[15:51] <mvo> hallyn_: ok, so if there is 0.12.5-0ubuntu1 in the changelog, it will look at the debian/watch location
[15:51] <smb> pitti, archive magic...
[15:51] <pitti> smb: seriously, natty's pkgbinarymangler removes upstream changelogs, trims debian changelogs, and optimizes PNG files now
[15:51] <mvo> hallyn_: for a upstream version like this, I think the bzrXXX triggers the magic
[15:52] <pitti> smb: so I made a list of all packages which we have on the CD, haven't been rebuilt in natty, and carry large changelogs or PNG files
[15:52] <smoser> pitti, so apologies for both nagging and being unfamiliar with process, but after I've verified a bug in -proposed , and its sat in -proposed for a week, what then happens ?
[15:52] <pitti> smoser: it can go to -updates
[15:53] <smoser> so you (or someone else on SRU team) then pushes a button ?
[15:53] <smb> smoser, is that in the kernel?
[15:53] <pitti> smb: rightg
[15:53] <pitti> smb: no, cloud-init
[15:53] <smoser> smb, i'm that one, no.
[15:53] <smoser> https://launchpad.net/bugs/651370 would be nice to see pop into -updates sometime this week though
[15:53] <pitti> oh, smoser is a kernel :)
[15:54] <smoser> smb, that should have said "not that one, no".
[15:55] <doko> mterry: cluster MIR ping
[15:55] <smoser> anyone with more familiar wth recent changes in the python stack able to suggest what might have caused bug 688773
[15:55] <mterry> doko, hi
[15:55] <smoser> (euca2ools and boto -- the relevant packages have not recently changed)
[15:57] <pitti> cjwatson: do you want me to commit http://launchpadlibrarian.net/60009278/debconf_1.5.36ubuntu1_1.5.36ubuntu2.diff.gz to the packaging branch? or did you abandon this branch now and use lp:ubuntu/debconf?
[15:57] <pitti> (this just caused some confusion here)
[15:57] <doko> mterry: what do you want me to look at?
[15:58] <mterry> doko, oh, nothing anymore.  I had a question about a library correctness thing, but it got answered by others.  thanks
[15:59] <cjwatson> pitti: I want to use something based on the bzr import of upstream svn, but that's currently failing so I can't
[15:59] <cjwatson> pitti: right now I'm just not using revision control for debconf at all
[15:59] <ari-tczew> cjwatson: could you sponsor lilo merge?
[15:59] <cjwatson> pitti: I'd rather you just attached it to the bug for now
[15:59] <cjwatson> ari-tczew: yes, let me drop everything and do that
[15:59] <pitti> cjwatson: ok
[16:00] <ari-tczew> cjwatson: you've my ACK
[16:01] <doko> mterry: so ok to promote pacemaker, cluster-glue, cluster-agents, heartbeat, libasyncns, libesmtp, libnet, openhpi?
[16:02] <mterry> doko, no, actually.
[16:02] <mterry> doko, there was a licensing issue with pacemaker at least.  waiting on upstream.  I don't know about all those bugs
[16:03] <mterry> doko, but bug status is up to date for my bugs anyway
[16:12] <doko> mterry: so we need to promote these all at once, and it's needed to build for python2.7 ...
[16:12] <mterry> doko, sorry, I don't follow.  You're saying the cluster stack is needed for python2.7 or that the cluster stack hasn't yet been rebuilt for python2.7?
[16:13] <doko> mterry: the latter. ocfs2-tools needs to be rebuilt
[16:13] <mterry> doko, OK.  So what's the issue?
[16:13] <doko> mterry: compoment mismatches
[16:14] <RoAkSoAx> mterry: im working on the licensing thing alreayd. patches have been accepted upstream
[16:14] <mterry> RoAkSoAx, awesome
[16:14] <mterry> doko, I'm just not understanding how the rebuild and the MIR are connected is all
[16:16] <doko> seb128, didrocks: any chance to look at the libgda4 build failure?
[16:16] <doko> mterry: $ apt-cache show ocfs2console|grep Depends
[16:16] <doko> Depends: libblkid1 (>= 2.15~rc2-1ubuntu1), libc6 (>= 2.7), libcomerr2 (>= 1.01), libglib2.0-0 (>= 2.12.0), libuuid1 (>= 2.16), python (<< 2.7), python (>= 2.6), python-support (>= 0.90.0), ocfs2-tools (= 1.4.3-2), python-gtk2
[16:16] <doko> mterry: uninstallable and cannot be rebuilt: https://launchpad.net/ubuntu/+source/ocfs2-tools/1.4.4-3build1
[16:17] <seb128> kenvandine, mterry: ^ how busy are you? could you look at the gda build issue?
[16:17] <seb128> it's gir related and you know those issues the best atm I think
[16:17] <mterry> seb128, I'm doing unity stuff right now, but nothing important
[16:17] <mterry> seb128, can look
[16:17] <kenvandine> seb128, i really want to get to the bottom of this unity/indicator-datetime problem
[16:18] <seb128> kenvandine, mterry: ok thanks, let's say mterry can do it, thanks!
[16:18] <seb128> doko, ^
[16:18] <mterry> doko, ah, I see.  So someone promoted ocfs2-tools too soon?
[16:18] <doko> saw it, thanks
[16:18] <kenvandine> thx mterry
[16:19] <doko> mterry: no, it always was in main, just gained new dependencies
[16:19] <mterry> doko, well we can either depromote it, promote the cluster stack, or wait.  Sounds like you don't want to wait.  I can't speak for how ready the rest of the cluster stack is.  I'd have to look at other MIR bugs
[16:19] <mterry> doko, fine, then gained new dependencies too soon.  :)
[16:20] <seb128> doko, can we promote geoclue? it's blocking an indicator build which is breaking unity...
[16:20] <doko> seb128: mterry did the review, I did ask kees / security at the daemons too
[16:21] <doko> on Friday he said to do it on Monday (today)
[16:21] <seb128> doko, right, what I'm asking is if we really need to wait on security
[16:21] <seb128> unity is broken until we sort that situation
[16:21] <seb128> so we either need to roll back to old versions not using geoclue in some way
[16:21] <seb128> ot to get geoclue promoted
[16:22] <doko> please can we wait until tonight? I think I should write something about pre-promotions ...
[16:23] <seb128> doko, well we can, unity is just broken for everybody running natty while we wait
[16:23] <seb128> no indicator is loading at all
[16:23] <pitti> I thought we could rollback to the previous version for now?
[16:23] <seb128> kenvandine, can you upload a new.is.old version then?
[16:24] <kenvandine> yup
[16:24] <seb128> pitti, well geoclue and ofono got mir review acks from mterry
[16:24] <seb128> pitti, so promoting seemed the easier way forward
[16:24] <seb128> but seems we need a security team review as well before
[16:24] <pitti> seb128: ah, ok; didn't know the full story
[16:24] <kenvandine> seb128, how do i handle that in the bzr branch considering the branch is also merged from the upstream source?
[16:24] <seb128> kenvandine, don't use the vcs
[16:25] <kenvandine> ok
[16:25] <seb128> just take the old version from launchpad, rename it and upload
[16:25] <kenvandine> figured
[16:25] <kenvandine> and with the next upload, i'll just include the changelog entry?
[16:25] <seb128> or not as you want
[16:25] <seb128> but yeah you can
[16:25] <kenvandine> ok
[16:25] <kenvandine> will do
[16:28] <mterry> doko, at least cluster-agents seems unreviewed
[16:33] <mterry> doko, and libasyncns doesn't have a MIR filed?  Is it part of the cluster stack?  So pacemaker has an easily-fixable license oddity change coming, I can review cluster-agents today.  That would leave libasyncns
[16:33] <doko> mterry: heartbeat, libnet and openhpi were already in main, do you want the dh_makeshlibs -V thing happen before the promotion?
[16:34] <doko> mterry: ok, preparing a MIR for libasyncns. can you review it later?
[16:34] <mterry> doko, for cluster-glue?  That change already happened
[16:34] <mterry> doko, sure
[16:35] <doko> ohh, right
[16:42] <kenvandine> kirkland, could you please get me a full package list?
[16:42] <kirkland> kenvandine: on my system?
[16:42] <kenvandine> kirkland, i am trying to narrow down the root cause of the unity panel not loading
[16:42] <kirkland> kenvandine: k
[16:42] <kenvandine> the one with the indicator-datetime problem
[16:42] <kenvandine> thx
[16:43] <kenvandine> kirkland, today's live image works
[16:43] <kenvandine> so something installed is causing the problem
[16:43] <kirkland> kenvandine: https://pastebin.canonical.com/40874/
[16:43] <kenvandine> thx
[16:43] <kirkland> np
[16:55] <smb> pitti, cjwatson Question about style and process:
[16:55] <smb> bug 681418
[16:55] <pitti> looking
[16:56] <pitti> smb: if you mean my extra changelog, feel free to ignore it; it was just a no-change rebuild
[16:56] <smb> The debdif was mostly ok. The guide says sort of "ask for a merge request"
[16:56] <smb> For training I created a branch (with your null change)
[16:57] <smb> but Ted says he has the next version ready soonish
[16:57] <ari-tczew> smb: could you have a look on bug 669363 ?
[16:58] <smb> So would we want to upload the current version anyway? Or wait? And if taking the current version, offer my bzr branch although it is just reflecting the other guys merge work.
[16:59] <smb> ari-tczew, I can, but bear with that I am not too familiar with the process yet and thus slow. :)
[17:00] <pitti> smb: if your branch is not more than just the attached debdiff applied, I don't think it buys much
[17:00] <ari-tczew> smb: not good
[17:00] <benste> hi, no one in #ubunut and #ubuntu-de could yet answer me how to mount smb shares in 10.10 unity
[17:00] <pitti> smb: I don't think there's anything wrong with uploading it now, if it works and was tested
[17:01] <benste> i did it back in 10.4 via gvfs and nautilus cklicking the places menu
[17:01] <pitti> smb: there was no definitive "tomorrow" for the new releasey
[17:01] <smb> pitti, The only small change would be to drop the vcs-git from the control.in as well
[17:02] <benste> someone here who knwos more about how unity works ?
[17:02] <BlackZ> smb: I was about to update the debdiff but I seen you have been more fast than me :) thanks
[17:04] <smb> BlackZ, Hi, well actually I have not done a separate debdiff file (thought that would be quick). I was interested in learning how the bzr merge request would work
[17:05] <smb> As I was neither sure whether the right way is just a debdiff or have that merge request way
[17:06] <BlackZ> smb: yeah, I noted that you haven't update the debdiff but I seen you linked a bzr branch to the bug report (if it contains the corrections it is fine)
[17:06] <BlackZ> smb: either way are fine
[17:06] <smb> pitti, Which happens if you let kernel devs be patch pilots without mandatory training sessions before. ;)
[17:06] <smb> BlackZ, I did?
[17:06] <smb> Must be something magic going on...
[17:06] <cjwatson> ari-tczew: stoppit, I'm doing it.
[17:07] <cjwatson> smb: no need to deal with lilo
[17:07] <smb> cjwatson, Ok, cheers
[17:07] <BlackZ> smb: maybe it's because you close that bug in your bzr revision?
[17:07] <smb> BlackZ, Oh I see. Just having done the debcommit to the bzr branch and then pushing it, created the link. :)
[17:08] <smb> BlackZ, Actually I wanted to ask whether that is a bit rude before doing the link, but automatic things decided that for me.
[17:08] <BlackZ> heh
[17:10] <cjwatson> ari-tczew: in future, please don't bother to ask me to do something if you're just going to ask somebody else about an hour afterwards even when I've said yes.
[17:10] <cjwatson> it's a waste of everyone's time ...
[17:10] <smb> pitti, So the only difference between the attached debdiff and my branch is your changelog entry and the removed vcs-git in control.in
[17:10] <cjwatson> (it's done now)
[17:10] <ari-tczew> cjwatson: I got you response as sarcasm
[17:11] <ari-tczew> (and I re-reply as the same)
[17:11] <cjwatson> well, I *was* doing other things, but nevertheless I did it
[17:20] <tumbleweed> can an archive-admin please reject the googleearth-package maverick-proposed upload?
[17:22] <smb> BlackZ, Ok, as it is actually the same code with just minor changes I just made a merge request for it to get the process ahead
[17:22] <BlackZ> thanks for you work, smb ! :)
[17:22] <smb> BlackZ, NP. Actually you did most of it.
[17:24] <doko> mterry: hmm, libasyncns is unrelated
[17:25] <mterry> doko, k, cool
[17:25] <doko> mterry: well, noticed too late, already updated ...
[17:28]  * smb believes to have done enough chaos for one day
[17:28] <smb> @pilot out
[17:28] <kees> doko, seb128: lost to backscroll... which thing did you want me to look at?
[17:29] <seb128> kees, geoclue
[17:29] <seb128> or ofono
[17:29] <seb128> kees, I think it's ofono (whichis a dep of geoclue)
[17:30] <kees> okay, give me a bit, and I'll look it over.
[17:30] <doko> kees: the daemons in ofono and gypsy, ohh and maybe a security for each unity upstream version? ;p
[17:30] <doko> s review even
[17:34] <SpamapS> Keybuk: around? I'm wondering about abstraction of events in upstart .. seems like 'stop on runlevel [016]' isn't exactly doing what we want (see bug 688541)
[17:34] <Keybuk> hey
[17:34] <Keybuk> abstraction of events?
[17:35] <SpamapS> Yes, like, instead of having people put 'stop on runleve [016]' they'd put 'stop on stopping-network-services'
[17:36] <RoAkSoAx> mterry: would you like to review pacemaker's diff before I upload?
[17:37] <SpamapS> Keybuk: I'm just concerned that by being so explicit in the events of regular services, we are making a lot of work for ourselves later on.
[17:38] <Keybuk> I don't understand, sorry
[17:38] <Keybuk> could you expand a little?
[17:39] <doko> mterry: #689766
[17:44] <SpamapS> Keybuk: I'm suggesting hiding common stop on / start on scenarios behind other events or other jobs... so an example would be mysql .. which does 'start on (local-filesystems and net-device-up IFACE!=lo)' and 'stop on runlevel [016]' .. squid also works this way. But it may be that we need to actually have them stop on something else that commonly happens.. like have them stop *before* unmounting all filesystems .. it would be easier to make th
[17:44] <Keybuk> that's what you're supposed to do
[17:45] <Keybuk> you're supposed to make jobs that encapsulate a comon start on/stop on combination
[17:45] <Keybuk> and then use other jobs off that
[17:45] <Keybuk> rather than copy/pasting lines between jobs
[17:45] <SpamapS> I'm so glad you said that. :) I thought maybe I was crazy thinking this way. ;)
[17:48] <Keybuk> one solution to the rc0/6 race is to have the umountfs job start with
[17:48] <Keybuk>   initctl emit unmounting-filesystems
[17:48] <Keybuk> then if you had any job (or state) wiht stop on unmounting-filesystems
[17:48] <Keybuk> it'd wiat
[17:48] <SpamapS> heh.. GMTA https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/688541/comments/5
[17:49] <SpamapS> Keybuk: basically, local-filesystems needs a mirror event.
[17:50] <Keybuk> yes
[17:55] <mterry> RoAkSoAx, uh, if it fixes the license issue, I can just review after the fact
[17:55] <mterry> RoAkSoAx, should be fine after that is fixed
[17:56] <mterry> doko, so do you want me to review libasyncns after all?  I thought you said we didn't need it?
[17:57] <doko> mterry: no, not now
[18:00] <RoAkSoAx> mterry: there's one file that hasn't been changed given that upstream wasn't unsure to do that because they didn't write that code in particular
[18:00] <RoAkSoAx> mterry: other than that, everything was changed
[18:00] <RoAkSoAx> s/changed/fixed
[18:04] <seb128> who is doing syncs?
[18:05] <seb128> whoever that is it would be nice to -S experimental pyclutter
[18:05] <seb128> -S experimental telepathy-glib
[18:08] <dholbach> ok my friends
[18:08] <dholbach> I call it a day
[18:08] <dholbach> see you
[18:20] <pitti> mdke: here by chance?
[18:32] <bryceh> heya pitti
[18:33] <pitti> hi bryceh
[18:33] <bryceh> pitti, question on bug #680811, which is in maverick-proposed for sruing...
[18:34] <bryceh> pitti, cnd has another xserver patch in the hopper, and we're wondering if it should be numbered 7.2, or if the above sru is not going to go through soon in which case it should be 7.1 ?
[18:35] <ScottK> bryceh: If it's in -proposed already you'll have to bump the version number since soyuz already has marked 7.1 used.
[18:35] <cnd> I'd also like to know why it's 7.1 and not 8?
[18:35] <bryceh> ScottK, ok
[18:35] <ScottK> cnd: We ~always do that for post-release updates
[18:35] <bryceh> cnd, the 8 would presumably be in natty
[18:35] <pitti> bryceh: you always have to bump the version number
[18:36] <cnd> ahh
[18:36] <cnd> ok
[18:36] <pitti> bryceh: the only difference is that you'd build with -v<version_in_updates> if you stack multiple -proposed uploads on top of each other
[18:36] <bryceh> cnd, so if someone upgraded, they can safely upgrade 7.1 -> 8, whereas if both natty and maverick had 8 it wouldn't upgrade them
[18:37] <bryceh> pitti, ok thanks
[18:37] <Daviey> slangasek: Hi... Are you doing Archive Admin stuff today?
[19:27] <c_korn> when do the nvidia drivers in the repository get updated? there is a race condition bug which has been fixed in 260.19.21. it causes some games to crash: http://www.nvidia.com/object/linux-display-amd64-260.19.21-driver.html
[19:44] <SpamapS> c_korn: lots of bug reports here, but I'd guess it would need to be reported and triaged if it hasn't already:  https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers
[19:59] <ari-tczew> c_korn: ask tseliot
[20:01] <c_korn> hm, just filed bug 689832
[20:08] <RoAkSoAx> mterry: uploaded!
[20:08] <RoAkSoAx> (pacemaker)
[20:08] <mterry> RoAkSoAx, oh nice, I'll recheck it
[20:10] <RoAkSoAx> mterry: awesome! Thanks... ;) Btw.. there's only one single file under lib/ without the change given that upstream was not confortable changing that file license header due to that it was not written by them
[20:11] <mterry> RoAkSoAx, but they are comfortable shipping it without knowing the license?
[20:11] <sabdfl> RoAkSoAx: congrats on the graduation
[20:11] <RoAkSoAx> sabdfl: thank you! :)
[20:11] <slangasek> Daviey: I can do some, but haven't been diligent about doing so routinely; anything in particular that you need?
[20:12] <Daviey> slangasek: I'm just wondering why the libvirt lucid SRU has been baking for some time now..   I guessed that perhaps the AA's were uneasy, or had questions about it.
[20:13] <RoAkSoAx> mterry: upstream is. I mean it is not a license change per se but typo on the header. That file used to be in heartbeat afaik (before the split).
[20:13] <Daviey> slangasek: to -proposed, currently in Unapproved
[20:13] <mterry> RoAkSoAx, but do they know what license it should be?
[20:13] <slangasek> Daviey: that's a separate question from AA duty
[20:14] <Daviey> slangasek: I thought these days it was largely one and the same.
[20:14] <slangasek> Daviey: the SRU team decides on SRU acceptance, that's not at all the same as archive admin
[20:14] <RoAkSoAx> mterry: yes, it is GPL 2.1+, when should be LGPL 2.1+, but upstream doesn't feel confortable doing the change given that the code wasn't written by them
[20:14] <mterry> RoAkSoAx, !?  That doesn't make any sense, but OK.  As long as we note that in debian/copyright
[20:15] <slangasek> Daviey: some of us are on both teams, but SRU accepts are definitely not part of the regularly scheduled AA duties
[20:16] <RoAkSoAx> mterry: it is this file: lib/plugins/lrm/raexecstonith.c
[20:16] <RoAkSoAx> mterry: and it has the same error as other files. It says it is GPL2.1+ when should say LGPL2.1+
[20:16] <RoAkSoAx> and as I said, upstream is aware but he said "i don"
[20:17] <Daviey> slangasek: Oh aye... based on what i've been seeing, the divide has become murky.
[20:17] <RoAkSoAx> and as I said, upstream is aware but he said "i didn't write that file so I don't feel confortable doing the license change"
[20:17] <RoAkSoAx> anyway, bbl
[20:18] <slangasek> Daviey: ehm, there's really no reason that should be the case.  Only a minority of the AAs are on the SRU team, and other members of the archive team aren't *authorized* to make decisions about accepting packages into -proposed...
[20:19] <slangasek> anyway, looking at libvirt now with my ubuntu-sru hat on ;)
[20:19] <Daviey> \o/
[20:19] <Daviey> slangasek: you rock :)
[20:23] <slangasek> Daviey: yeesh, someone take the parentheses gun away from that upstream
[20:23] <slangasek> Daviey: accepted
[20:23] <Daviey> slangasek: heh, great - thanks!
[20:25] <kees> slangasek: can I borrow you for upstart debugging for a moment? does a "task" go through "starting" like for "services" ?
[20:27] <kees> slangasek: and how I can get a dump of the emitted events during startup?
[20:32] <slangasek> kees: yes, there's a 'starting' phase, whether it's a task or a service
[20:32] <slangasek> kees: dump of the emitted events - boot with --verbose, grab the log and postprocess
[20:32] <kees> slangasek: really? because nothing seems to be triggering my job
[20:32] <kees> okay, will try
[20:32] <kees> wait, boot with "verbose" not --verbose? kernel cmdline?
[20:33] <slangasek> no, --verbose
[20:33] <slangasek> on the kernel commandline
[20:33] <slangasek> what's the job look like?
[20:34] <kees> /etc/init/networking.conf (the task) and /etc/init/network-interface-security.conf (the prereq)
[20:34] <kees> the latter isn't actually running :(
[20:34] <kees> (testing for apparmor in lucid -proposed uncovered this existing race)
[20:34] <slangasek> odd
[20:35] <kees> yeah, building log...
[20:35] <kees> which log does it spew to?
[20:36] <slangasek> /var/log/syslog, IIRC
[20:36] <kees> oh yes
[20:41] <kees> slangasek: utterly no mentio of /etc/init/network-interface-security.conf
[20:41] <kees> :(
[20:42] <slangasek> kees: but you do see 'network-interface' or 'networking' or something in there?
[20:43] <kees> slangasek: yeah, I watch both network-manager and networking make their way through their entire lifecycles
[20:43] <bigon> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/665768 do you have a list of these pkg?
[20:43] <kees> and n-i-s is shown as "start/running" O_o
[20:44] <kees> slangasek: wait, I liked. I think I was accidentally searching for networkING-inter...
[20:44] <kees> one moment...
[20:55] <kees> slangasek: I'm totally baffled. http://paste.ubuntu.com/543279/ is upstart just not logging events in early boot?
[20:57] <kees> slangasek: it seems like jobs aren't waiting for pre-start stanzas to finish before unblocking.
[20:58] <kees> slangasek: i.e. n-i-s runs when I expect it to, but the jobs it has listed aren't waiting for its pre-start to finish
[21:04] <slangasek> kees: IIRC, upstart is supposed to have a ring buffer internally for logging, which it dumps once syslog comes up; that, or Keybuk and I *talked* about having such a thing and it never got implemented, not sure
[21:05] <kees> slangasek: looks like it was never implemented :(
[21:05] <slangasek> kees: since I don't see any jobs on my system that trigger a dump on rsyslog start, yeah, I guess so
[21:06] <kees> slangasek: if jobB starts on starting jobA, and jobB has a pre-start script, isn't jobA supposed to wait until jobB's pre-start has finished before jobA can move to its own pre-start?
[21:07] <slangasek> er, I'm not sure
[21:07] <kees> this design was predicated on that, based on what Keybuk told me. :(
[21:07] <slangasek> I'd have to check the code; it might be jobB prestart, jobA prestart, job A script, job B script
[21:08] <kees> Oh! nevermind. I think I see the problem.
[21:09] <Keybuk> This is one of the many things that scares me about systemd
[21:09] <Keybuk> http://cgit.freedesktop.org/systemd/tree/src/modules-load.c
[21:09] <kees> I have    start jobX on (starting job1 or starting job2 or starting job3).  job1 -> starting, jobX -> starting, job2 -> starting & runs. jobX -> finishes, job1 -> finishes
[21:09] <kees> Keybuk: just the person I was looking for!
[21:09] <Keybuk> kees: hah
[21:10] <Keybuk> I felt a disturbance in the force
[21:10] <kees> Keybuk: heh. I'm trying to debug a race. it's /etc/init/network-interface-security.conf
[21:11] <kees> Keybuk: it seems like if any 1 of those 3 jobs it waits for start, it will start, but if it takes a while, the other two might start and get to running before n-i-s finishes.
[21:11] <Keybuk> yeah
[21:11] <Keybuk> only the first of the jobs in the "or" to start gets held up
[21:12] <kees> what are my options for making them all wait for it to finish?
[21:12] <Keybuk> huh, doesn't look like there's a bug for that one
[21:13] <Keybuk> don't use starting, instead use started network-interface-security in the named jobs?
[21:13] <Keybuk> https://bugs.launchpad.net/upstart/+bug/568860
[21:13] <Keybuk> ah there it is
[21:13] <Keybuk> I knew it was filed somewhere
[21:13] <kees> Keybuk: so I need to modify each of the jobs I want to block?
[21:13] <Keybuk> yes :-/
[21:14] <kees> and they will trigger the spawning?
[21:14] <Keybuk> "the spawning" ?
[21:14] <kees> ah, nevermind. n-i-s would just become "start on virtual-filesystems"
[21:15] <Keybuk> is n-i-s indemponent and atomic?
[21:15] <Keybuk> ie. could you cope with it being run *again* if the second event happened?
[21:15] <kees> it can, but it's a waste of time
[21:15] <Keybuk> because in that case you could stick instance $JOB in
[21:15] <Keybuk> you'd get a copy for each of the start on clauses
[21:15] <kees> I just want the one.
[21:16] <Keybuk> yeah
[21:16] <Keybuk> just thinking of solutions for you for the time being
[21:17] <slangasek> kees, Keybuk: or since network-interface-security is idempotent, you could 'instance' it?
[21:17] <Keybuk> slangasek: ah, we appear to have reached the middle of this conversation
[21:17] <slangasek> ah
[21:17] <Keybuk> I just suggested that
[21:17]  * slangasek whistles
[21:17] <kees> how does instances help this, exactly?
[21:17] <Keybuk> but I feel really quiet warm, comfortable and fluffy knowing that a signficant portion of my brain has been backed up into yours
[21:18] <slangasek> kees: you get a separate n-i-s job for each of the triggering jobs
[21:18] <Keybuk> just be caseful, I may need my katra back one day
[21:18] <slangasek> heh
[21:18] <Keybuk> caseful? careful!
[21:18] <kees> slangasek: hm. that's the least intrusive change, but it's a small waste of time.
[21:19] <Keybuk> waste of time > bad security
[21:20] <kees> could skip later runs by examining something in /var/run ...
[21:20] <Keybuk> yeah
[21:20] <ebroder> kees: By the way, I think Upstart's output from before rsyslog is up will go to /var/log/boot.log
[21:21] <Keybuk> kees: but this bug is definitely being fixed
[21:21] <Keybuk> the trouble is it isn't a bug so much as a missing feature
[21:21] <Keybuk> start on .. or .. was never designed to block both :p
[21:21]  * kees nods
[21:22] <kees> this race only happens rarely, but I still want to fix it.
[21:22] <kees> so... just add the line "instance $JOB" ?
[21:22] <slangasek> not quite
[21:22] <slangasek> because network-interface itself can have multiple instances
[21:23] <Keybuk> that has $INTERFACE right?
[21:23] <Keybuk> you could do instance $JOB$INTERFACE
[21:23] <Keybuk> :p
[21:23] <slangasek> right
[21:23] <slangasek> I was just looking up the variable :)
[21:23] <ebroder> Will instance $JOB/$INTERFACE work? Because that looks slightly less dumb
[21:23] <Keybuk> if you prefer
[21:24] <Keybuk> it's just an arbitrary string
[21:24] <kees> but it's only to use $INTERFACE when some jobs don't use it? (i.e. network-manager.conf)
[21:25] <Keybuk> it's "" if not
[21:29] <geser> cjwatson: can you please also add "lapack" to Sylvestre Ledru's (sylvestre) PPU (see his recent mail to devel-permission).
[21:29] <kees> ebroder: ah-ha! yes, it is in boot.log. that'll make this easier to debug. :)
[21:30] <ebroder> kees: Though I think there might be a race between when plymouth dumps its log and when rsyslog starts, so there might be a window where you don't get logs
[21:31] <kees> init: Failed to obtain network-interface-security instance: Unknown parameter: INTERFACE
[21:36] <kees> Keybuk, slangasek: adding "instance $JOB/$INTERFACE" failed as above, and reducing it to "instance $JOB" had no change in behavior.
[21:38] <kees> I take it back, it does work, just not with the "network-interface" job due to the lack of $INTERFACE
[21:39] <kees> is there some way to access it?
[21:44] <kees> Keybuk: so, how do I access $INTERFACE? it seems like it's isolated to inside the job, and I can't see it from $JOB.
[21:54] <Keybuk> kees: ?
[21:54] <Keybuk> oh, unknown parameter
[21:54] <Keybuk> what's that shell thing
[21:55] <Keybuk> instance ${JOB:}${INTERFACE:}
[21:55] <Keybuk> or something
[21:55] <Keybuk> use other value if unset
[21:55] <Keybuk> ${JOB:-}${INTERFACE:-}
[21:55] <Keybuk> that one
[21:57]  * kees tries it
[21:59] <kees> Keybuk: it still doesn't see it.
[21:59] <kees> init: network-interface-security (network-interface/) goal changed from stop to start
[21:59] <Keybuk> right
[21:59] <Keybuk> hmm
[21:59] <Keybuk> what was the event again?
[21:59] <kees> init: network-interface (eth0) state changed from waiting to starting
[21:59] <kees> I need $JOB_WITH_INSTANCE
[21:59] <Keybuk> no, no
[22:00] <kees> ?
[22:00] <Keybuk> you're starting on what terms?
[22:00] <Keybuk> can you paste the start on line
[22:00] <Keybuk> oh
[22:00] <Keybuk> wait
[22:00] <Keybuk> it's not using net-device-added is it?
[22:00] <kees> start on (starting network-interface
[22:00] <kees>           or starting network-manager
[22:00] <kees>           or starting networking)
[22:00] <kees> nope
[22:00] <Keybuk> yeah
[22:00] <Keybuk> d'oh
[22:00] <Keybuk> ok
[22:00] <Keybuk> you need to change /etc/init/network-interface.conf
[22:00] <Keybuk> add
[22:00] <Keybuk> export INSTANCE
[22:01] <kees> ah-ha
[22:01] <Keybuk> sorry, had it in my head that your job worked directly off net-device-added
[22:01] <Keybuk> so yeah, network-interface needs to export the INSTANCE thingy
[22:01] <Keybuk> which really begs the question why export isn't the default
[22:01] <Keybuk> that might be useful, or something
[22:01] <Keybuk> (I know why it isn't, but meh)
[22:01]  * kees tries again
[22:02] <kees> \o/
[22:02] <kees> init: network-interface-security (network-interface/eth0) state changed from waiting to starting
[22:03] <Keybuk> ok, now try starting something like network manager
[22:03] <Keybuk> you should see
[22:03] <Keybuk> (network-manager/)
[22:03] <kees> Dec 13 22:02:01 sec-lucid-amd64 init: network-interface-security (network-manager/) goal changed from stop to start
[22:03] <kees> yup
[22:03] <Keybuk> sweet
[22:03] <kees> excellent!
[22:04] <kees> Keybuk, slangasek: thank you! :)
[22:24] <sconklin> @pilot out
[22:30] <RoAkSoAx> kirkland: just made an upload for TestDrive. Apparently just needed a rebuild for python 2.7. Please give a try if you can and let me know!
[22:47] <kirkland> RoAkSoAx: cool, will do
[22:50] <SpamapS> anyone know why lp:ubuntu/sysvinit is so far behind the actual package?
[22:52] <micahg> SpamapS: http://package-import.ubuntu.com/status/sysvinit.html#2010-06-16%2012:21:03.212483
[23:06] <SpamapS> micahg: weird, who can resolve this?
[23:07] <micahg> SpamapS: you can file a bug against the udd project I think (lp.net/udd)
[23:15] <SpamapS> micahg: thanks, bug 513277 seems to be an older one. ;)
[23:34] <hallyn_> anyone deal a lot with debirf?
[23:35] <hallyn_> i'm curious about the fact that it uses debootstrap, which must be run as root, but complains when run as root...