[00:16] <vsingh165> hi, is it possible to have multiple computers registered on your Launchpad acct?
[03:51] <hallyn> say, is http://paste.ubuntu.com/1027991/ (dpkg-shlibdeps warning) something I should worry about?  the symbol (sem_post) is provided by -lrt (according to manpage anyway), in libc...
[03:55] <stgraber> strange it's complaining about it...
[03:58] <hallyn> yeah..  it doesn't stop the build there, at least
[03:59] <hallyn> anyway (since you're here :) lp:~serge-hallyn/+junk/lxcwithapi now has the debian/ to build a set of lxc2* packages.  builds, haven't installed/tested it yet :)  will try it out tomorrow
[03:59] <hallyn> (surely it'll fail spectacularly)
[03:59] <hallyn> (so if i do it now, i'll stay up for hours enjoying the magnificance ofthe failure)
[04:02] <stgraber> hallyn: right, sounds like I should have a look at that tomorrow
[04:02] <stgraber> if I start poking at it, I might end up doing the python work tonight and not sleep at all...
[04:03] <hallyn> heh, we'll poke it with a stick tomorrow.  good night!
[04:03] <stgraber> good night!
[04:06] <RAOF> hallyn: Does it actually *link* to librt?
[04:15] <vibhav> smoser: ping
[04:26] <vibhav> Could any body nominate https://bugs.launchpad.net/ubuntu/+source/postgis/+bug/967162 for oneiric and lucid?
[04:31] <micahg> vibhav: only oneiric appears to be affected
[04:33] <vibhav> micahg: Ah yes, It was stupid of me
[04:33] <vibhav> s/stupid/foolish/
[04:33] <vibhav> micahg: Could you nominate it for oneiric?
[04:33] <micahg> vibhav: task given
[04:33] <vibhav> thanks!
[04:34] <ihashacks> long-time Linux junkie here, fairly recent bug fix contributor - not sure if I even did this right:
[04:34] <ihashacks> https://code.launchpad.net/~ihashacks/ubuntu/precise/atftp/fix-for-383761_972834
[04:35] <ihashacks> Would this be the place for validation? heh
[04:42] <vibhav> micahg: Could you also set the importance to high\medium ?
[04:45] <micahg> vibhav: nope, I'd say that's low
[04:45] <vibhav> why?
[04:45] <micahg> easily worked around
[04:46] <vibhav> By creating symlinks, right?
[04:46] <micahg> that or updating $PATH
[04:47] <vibhav> but users expect these tools to be in their default
[04:47] <vibhav> $PATH, and scripts/cron jobs/etc using them will break after upgrading
[04:47] <vibhav> from 1.5.2 to 1.5.3.
[04:47] <vibhav> </quote
[04:47] <vibhav> >
[04:47] <micahg> https://wiki.ubuntu.com/Bugs/Importance -> Low -> Bugs that have a moderate impact on a non-core application
[04:48] <micahg> vibhav: I'd consider it SRUable for the reason give, just still low importance
[04:49] <micahg> but IANA SRU team member
[04:50] <vibhav> fine
[04:51] <vibhav> micahg: Set the Importance to low then
[04:54] <micahg> done already
[05:00] <vibhav> thanks
[05:57] <rickspencer3> nice, another day of beer in http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[05:57] <rickspencer3> and it's a1 today :)
[05:57] <rickspencer3> thanks infinity
[06:39] <testi> Where does unity calculate transparency? GPU or CPU? For example the transparency of the Dash-Help that appears when you keep pressing the Super-Key.
[07:04] <dholbach> good morning
[09:41] <seb128> @pilot in
[09:43] <vibhav> woo!
[09:51] <seb128> vibhav, you are still using oneiric? I'm not sure all those SRUs to it make sense, there is a new LTS out and users who have been using it for over 6 months probably worked around the issues
[09:51]  * dholbach hugs seb128
[09:51]  * seb128 hugs dholbach
[09:52] <vibhav> seb128: Some of my friends still use oneiric, and are not planning to upgrade for some time
[09:52] <vibhav> s/upgrade/fresh install/
[09:53] <seb128> shrug, users are weird :p
[09:53] <seb128> why would use oneiric when precise is so much better ;-)
[09:53] <seb128> vibhav, still as said, I'm not sure it make sense to SRU minor issues after 6 months, users either worked around or move on to something else
[09:55] <vibhav> only if you could convince them :(
[09:57] <seb128> vibhav, the issue is also that nobody verifies uploads to old version, see the natty and oneiric lists on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[09:58] <vibhav> seb128: :O
[09:58] <seb128> ":0"?
[09:58] <seb128> ":O"?
[09:58] <vibhav> "surprised"
[09:58] <vibhav> at the number of packages
[09:58] <seb128> well, not very surprised, most people run either the current unstable or current stable or current lts
[09:59] <vibhav> ah
[09:59] <seb128> so we have very few contributors still running old stables and doing verifications for those
[09:59] <vibhav> yeah, but in the bug report the reporter only requested a SRU
Can the fix be applied to 11.10 ocelot too please?</quote>
[10:00] <vibhav> hence the SRU
[10:00] <seb128> vibhav, yeah, that was before precise was released though, i.e when oneiric was current stable
[10:00] <vibhav> ah yes
[10:00] <seb128> I'm a bit unsure what to do there
[10:00]  * vibhav should have seen the date
[10:00] <seb128> I feel like uploading it is wasting SRU team time
[10:01] <xnox> seb128: reply to the user: this is not a security update please upgrade to precise *evil laugh* ? =)
[10:01]  * xnox hides
[10:02] <seb128> xnox, ;-) well the contributor is vibhav which is why I'm discussing it here
[10:02] <xnox> ah =)
[10:02]  * vibhav winders what to do
[10:02] <seb128> but I neither like unsuscribing sponsors, not letting it in the queue sitting there, nor uploading it because I think it will be never verified and just waste SRU team time
[10:03] <vibhav> Or wait, Ill verify it
[10:03] <vibhav> on a friends machine
[10:03] <seb128> ok, deal
[10:03] <vibhav> Is that fine?
[10:03] <seb128> yes
[10:03]  * vibhav hugs seb128 
[10:03] <seb128> ;-)
[10:03] <seb128> vibhav, but please do oneiric SRUs only for things really worth it
[10:04] <seb128> there is no real point to spend lot of efforts fixing small issues for it
[10:05] <vibhav> sure :)
[12:44] <xnox> Can somebody please accept tasks for Precise 12.04.1 milestone and Quantal for the bugs in this launchpad bug search query http://tinyurl.com/bv3avz6 I am going to run these through the 12.04.1 release team and hopefully land those for 12.04.1, this is an action item from me from the last 12.04.1 meeting.
[12:45] <xnox> If release team decides on the change the scope I will be amending those bugs as appropriate.
[12:53] <hippiehacker> curl http://ftp.utexas.edu/ubuntu/dists/precise/main/binary-amd64/Packages.gz | zgrep Task: # how are Tasks defined?
[12:54] <hippiehacker> I'm looking at https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/574287 and wanted to see how tasks are created
[13:01] <seb128> xnox, bug like #1006509 seem weird for a SRU?
[13:01] <seb128> xnox, bug #1006509
[13:02] <xnox> seb128: yes it is weird, but it has bugfixes. I need to explain all of them. Some of them should have happened before precise release.
[13:02] <xnox> seb128: potentially autfs one will be split out just to get the bugfixes from the stable upstream branch of upto June.
[13:02] <seb128> xnox, ok, I accepted them, can you set the settings and assigned as appropriate?
[13:03] <xnox> seb128: ok.
[13:03] <xnox> seb128: thank you =)
[13:03] <seb128> xnox, yw ;-)
[13:09] <hallyn> RAOF: well it.s a library.  So no.
[13:10] <hallyn> it is in the LDADD, and binaries linked against it show the right output for ldd
[13:11] <vibhav> Where does pbuilder generate the debs?
[13:30] <cyphermox> vibhav: ~/pbuilder/results or something IIRC ?
[13:31] <tumbleweed> pbuilder-dist uses ~/pbuilder/results. The default is /var/cache/pbuilder/results
[13:31] <cyphermox> ah, my bad :)
[13:31] <vibhav> thanks!
[13:55] <mterry> When moving (renaming) a conffile in the same package, I know to use "dpkg-maintscript-helper mv_conffile".  Is there anything different I should do when moving and renaming a conffile between source packages (besides the Replaces stuff in debian/control)?
[13:57] <seb128> mterry, use a .maintscript rather than calling dpkg-maintscript-helper manually
[13:58] <didrocks> mterry: to answer your question, I guess you don't have anything different to do
[13:58] <seb128> mterry, otherwise for your question I'm not sure, mvo or cjwatson probably knows better about that
[13:59] <mterry> seb128, k, thanks for the hint though, will look at those
[14:00] <seb128> mterry, you can take avahi as a package which does use a .maintscript to move conffiles
[14:01] <mterry> seb128, yup.  man dh_installdeb also talks about them
[14:01] <seb128> mterry, it's cool because with them you don't need to remember which one of the maintainer scripts you need to add calls to
[14:01] <seb128> i.e prerm, postinst, ...
[14:01] <cjwatson> It used to be excruciatingly difficult
[14:02] <cjwatson> to transfer conffiles between packages
[14:02] <mterry> I like the word "used" there
[14:02] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335276 has a bunch of gory details, and you can still see the madness in openssh-server.preinst
[14:02] <cjwatson> But I think nowadays you can just use Replaces
[14:03] <vibhav> smoser: ping
[14:03] <smoser> vibhav, hi
[14:03] <vibhav> smoser: Did you upload the merge?
[14:03] <vibhav> Or do you want a more revised version?
[14:03] <cjwatson> If you're just transferring package ownership rather than changing the filename as well, then you shouldn't need .maintscript
[14:03] <mterry> cjwatson, I see, so conffiles act like normal files when transitioning between packages.  What if I want to move/rename it at the same time?  Do I do Replaces+.maintscript in new package?
[14:03] <smoser> vibhav, i did not.
[14:04] <cjwatson> mterry: [fx: runs]
[14:04] <smoser> vibhav, i wanted to give you a chance to do address the things i brought up
[14:04] <mterry> I guess there wouldn't need to be replaces, since it wouldn't be at the same location...?
[14:04] <cjwatson> mterry: Er, maybe pass a package name to dpkg-maintscript-helper?  I'm not sure - you may just have to try it.
[14:04] <vibhav> smoser: fine, Ill upload a better debdiff
[14:04] <vibhav> thanks, though
[14:04] <smoser> vibhav, i can then take a quick look and upload
[14:04] <mterry> cjwatson, OK, thanks!
[14:04] <cjwatson> mterry: Make sure that you try it both with an unmodified conffile and with a modified one
[14:05] <mterry> cjwatson, k
[14:05] <hippiehacker> I'm looking at https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/574287 and wanted to see how tasks are created... basically what files/process results in the Task headers in  'curl http://ftp.utexas.edu/ubuntu/dists/precise/main/binary-amd64/Packages.gz | zgrep Task:'
[14:07] <cjwatson> hippiehacker: They're written automatically by the Launchpad archive publisher, based on germinate output
[14:08] <cjwatson> hippiehacker: I don't know if that's desperately relevant to that bug though; we don't consider overlapping tasks to be a bug, if that's what you're wowndering
[14:08] <cjwatson> *wondering
[14:09] <vibhav> smoser: Ill file the Debian Bug later, is that fine?
[14:09] <hippiehacker> I'm somewhat looking into the bug, but mostly trying to understand how to create tasks and make them available
[14:09] <smoser> vibhav, sure.
[14:10] <cjwatson> hippiehacker: If you're generating test archives for yourself, you probably want apt-ftparchive extra overrides; our input to apt-ftparchive is in /ubuntu/indices/ on mirrors
[14:10] <cjwatson> hippiehacker: Adding new tasks requires changing /usr/share/tasksel/ubuntu-tasks.desc
[14:11] <hippiehacker> I see that file, but the Packages: header only lists 'task-fields'
[14:11] <hippiehacker> where would one set the packages for a custom task?
[14:13] <hippiehacker> looks like we can drop a file into /usr/local/share/tasksel/
[14:13] <cjwatson> hippiehacker: "task-fields" causes the packages to be implicitly set by the Task fields you're looking at
[14:13] <cjwatson> in Packages
[14:15] <hippiehacker> I'll look at apt-ftparchive + /ubuntu/indices.
[14:15] <hippiehacker> cjwatson: thanks heaps!
[14:17]  * vibhav looks for final changes
[14:21] <hallyn> Ok, what on earth.  Trying again to figure out why fcntl.h doesn't give me AT_EMPTY_PATH.  I find ./debian/patches/any/submitted-bits-fcntl_h-at.diff in eglibc source, which expliclty removes the definition!
[14:21] <vibhav> smoser: done!
[14:23] <hallyn> yay, bugs.debian, here i come
[14:23] <smoser> vibhav, thanks.
[14:38] <hippiehacker> cjwatson: https://gist.github.com/2889140 is my attempt to understand where the dns-server task is defined before the generation of Packages.gz with apt-ftparchive
[14:41] <cjwatson> hippiehacker: bzr co lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal, look at ubuntu.quantal/dns-server
[14:41] <cjwatson> that's the ultimate source, not dependency-expanded
[14:42] <cjwatson> germinate (see package) is responsible for expanding out dependencies in the seeds
[14:42] <cjwatson> http://bazaar.launchpad.net/+branch/launchpad/files/head:/lib/lp/archivepublisher/scripts/generate_extra_overrides.py takes the output and turns it into extra overrides
[14:43] <cjwatson> That's run as part of the Launchpad publisher and isn't something you can run standalone, but the mapping from germinate output files to Task fields is merely tedious rather than anything magic
[14:44] <hippiehacker> quite the process
[14:44] <cjwatson> It's designed to minimise the number of manual changes we have to make as packages' dependencies shift around
[14:44] <cjwatson> Which is the sort of thing you care about rather more at large scale
[14:46] <hippiehacker> what are your thoughts on where Debian went with task-* meta-packages rather than updating the Packages.gz in wheezy and beyond?
[14:47] <hippiehacker> it likely fixes the auto-removal problem, as the meta-packages bascially just have dependencies (I think)
[14:49] <hippiehacker> http://wiki.debian.org/tasksel#Sample_use : "Note that in DebianWheezy and beyond tasksel provides and uses dummy packages (known as meta packages) to pull required dependencies."
[14:50] <cjwatson> hippiehacker: I haven't looked into that much as yet; it's a reversion to an earlier approach, basically
[14:50] <cjwatson> We could do much the same with our existing metapackages, presumably
[14:50] <cjwatson> Well, in those cases where they exist, which isn't all
[14:51] <seb128> ev, hey
[14:51] <ev> hi seb128
[14:51] <seb128> ev, is whoopsie client or server side ever recommending to use ask ubuntu?
[14:51] <seb128> ev, I'm trying to figure where to reassigned https://bugs.launchpad.net/ubuntu/+source/launchpad-integration/+bug/991602
[14:52] <hippiehacker> If a wanted to allow a closer-to-end-user to create a list of packages, similar to a task would a good approach be to streamline the dynamic generation of a new metapackage.deb based on a tasklike name and a list of packages?
[14:52] <seb128> ev, seems "apport" sometimes suggest "Ask Ubuntu is the best place to get free technical support" ... which jcastro complains about because it's creating issue on the askubuntu side
[14:52] <ev> seb128: the user never ever sees whoopsie - it's a daemon. Server side there's no reference to Ask Ubuntu
[14:52] <seb128> ev, ok, that was a random shot, I grepped locally without success and google is not very useful either
[14:52] <seb128> ev, thanks
[14:53] <ev> seb128: sure thing
[14:54] <seb128> oh, found it
[14:58] <seb128> ev, for the record it's coming from the xorg hook
[14:58] <ev> ick
[15:01] <hippiehacker> at the end-user-level: https://help.ubuntu.com/community/MetaPackages#Creating_Metapackages
[15:03] <hippiehacker> cjwatson: thanks for the info, I'll be looking deeper into all this very soon
[15:04] <cjwatson> hippiehacker: OK, no problem
[15:47] <Sweetshark> seb128: do you see any reason my mail to the TB ML wrt to LO MRE hasnt been moderated yet?
[15:48] <Sweetshark> ^ wonder how Joe Average would parse 'TB ML wrt LO MRE'
[15:48] <seb128> Sweetshark, your response to pitti you mean?
[15:49] <seb128> Sweetshark, try pinging cjwatson
[15:49] <seb128> pitti is off today, not sure who else is moderation it
[15:50] <stgraber> Sweetshark: btw, easiest way to avoid moderation is simply to subscribe to it
[15:51] <Sweetshark> stgraber: my inbox already has digestion trouble ..
[15:56] <cjwatson> Sweetshark: Largely because listadmin hates me
[15:57] <cjwatson> You can subscribe and turn off delivery
[15:57] <cjwatson> fetching data for technical-board@lists.ubuntu.com ... Died at /usr/bin/listadmin line 1310.
[15:57] <cjwatson> Ah, there we go, works eventually
[15:57] <cjwatson> Sweetshark: Moderated now
[16:01] <Sweetshark> cjwatson: thx
[16:28] <cnd> argh, I just uploaded to quantal instead of quantal-proposed
[16:28] <cnd> can I get someone to delete my upload to quantal, and then I'll reupload?
[16:29] <stgraber> cnd: unliekly, we're not in hard freeze, anything you upload will hit the archive directly
[16:29] <cnd> stgraber, oh... well, it is a crasher fix
[16:29] <cnd> so I guess it should actually go to quantal directly
[16:30] <stgraber> cnd: we're very unlikely to respin at this point anyway (not a reason to push more stuff to the release pocket though ;))
[16:30] <cnd> ok
[16:36]  * vibhav hugs smoser 
[16:51] <micahg> smoser: -v when uploading merges please :)
[16:59] <Daviey> micahg: if you want to improve on, http://pb.daviey.com/pOI1/
[16:59] <Daviey> more than welcome :)
[17:01] <seb128> @pilot out
[17:03] <smoser> micahg, i realized that. thank you.
[17:03] <smoser> :-(
[17:03] <smoser> it does seem like bzr bd could be smarter there
[17:04] <smoser> but i guess its non-trivial when which version to determine to show against.
[17:06] <Daviey> smoser: see my hacky script above
[17:06] <Daviey> (althought i sponsored a merge recently forgetting to run it.. *sigh*)
[17:08] <smoser> Daviey, right. yo uneed rmadison data to tell you.
[17:08] <smoser> or som eother source of "what is current"
[17:08] <micahg> if you use grab-merge, it provides a ../merge-buildpackage script
[17:11] <james_w> smoser, "bzr bd --package-merge" might do what you want
[17:12] <james_w> it requires a flag, as you can't detect it reliably without hitting e.g. Launchpad
[17:13] <seb128> could somebody set https://code.launchpad.net/~kroq-gar78/ubuntu/precise/visualvm/fix-start/+merge/108089 to merged?
[17:14] <james_w> seb128, done
[17:14] <seb128> james_w, thanks
[17:17] <seb128> yofel, could you look to bug #998179? it seems that https://launchpad.net/ubuntu/+source/kdepim/4:4.8.3-0ubuntu0.1 that you sponsored has a regression compared to 4.8.2
[17:17] <slangasek> james_w: remind me why we can't look for the previous package tag that's on the main branch, without hitting LP?  since any tags for merged versions will be on the different branch that's being merged in
[17:17] <seb128> ScottK, ^
[17:18] <james_w> slangasek, hmm, maybe that would work
[17:18] <james_w> it looks at the changelog currently
[17:18] <yofel> seems fixed in 4.8.4 which we are currently preparing
[17:19] <james_w> we don't currently do anything based on "latest tag", but I don't see why we can't
[17:20] <seb128> yofel, can you comment on the bug and unsubscribe the sponsors if sponsoring is not needed?
[17:21] <slangasek> james_w: for maximum robustness it should make sure it's using a tag that corresponds to a version number that exists in debian/changelog
[17:22] <micahg> slangasek: it doesn't work for the case in -proposed
[17:22] <slangasek> yes, I'm not trying to solve all the world's problems :)
[17:22] <slangasek> sometimes you still need to pass -v
[17:24] <yofel> slangasek: commented, but I can't unsubscribe the sponsors team, insufficient permissions
[17:24] <micahg> yofel: done
[17:25] <yofel> thanks
[17:27] <seb128> yofel, thanks (I guess it was for me and not slangasek)
[17:27] <yofel> oh right, sorry
[17:27] <seb128> np ;-)
[17:32] <infinity> cjwatson: Thoughts on SRUing for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533 ?
[17:32] <infinity> cjwatson: It's clearly a feature, not a "bugfix", except that I'd consider "openssl is really slow, and we can make it more than twice as fast" a pretty big bug in our LTS server offering.
[17:37] <cjwatson> infinity: I kind of thought about doing that pre-release, but there was too much else going on.  Given recent history, can we get it thoroughly exercised in quantal first?
[17:37] <cjwatson> (There's a corresponding Ubuntu bug somewhere reasonably obvious)
[17:39] <slangasek> s/exercised/exorcised/ I think, based on recent experience with openssl
[17:41] <cjwatson> There's that
[17:42] <infinity> Heh.
[17:42] <infinity> Are there good openssl stress-test (and correctness-test) suites?
[17:48] <seb128> infinity, cjwatson: (you seem to be the closest from a live-build maintainer for Ubuntu): could you review the patch from https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/975861 when you have some time?
[17:49] <seb128> jamespage, zul: is ubuntu-sponsors needed on https://bugs.launchpad.net/ubuntu/+source/modsecurity-apache/+bug/988819 or are you guys on it?
[17:53] <zul> seb128: i thnk jamespage and racb are on it
[17:53] <jamespage> seb128, zul: yes
[17:53] <seb128> jamespage, should I unsubscribe sponsors then?
[17:53] <jamespage> seb128, +!
[17:54] <jamespage> or +1 even
[17:54] <seb128> jamespage, zul: thanks ;-)
[17:55] <infinity> seb128: Hooray for using live-build in a mode where it duplicated debootstrap (poorly)?
[17:56] <infinity> seb128: We should probably just merge, rather than cherry-pick.  And I'm not sure if it's worth SRUing for that.
[17:56] <seb128> infinity, your call, can you write that on the bug? ;-)
[17:57] <cjwatson> infinity: qa-regression-testing has some stuff for openssl.  It's not brilliant.
[18:21] <kees> who's the best person to ping about LP: #1010141 ?
[18:21] <kees> "gvfs-gdu-volume-monitor automounts loop devices, preventing them from being unmounted"
[18:41] <hallyn> i realize we're in freeze now, but for the benefit of dropping the qemu-kvm workaround, could someone look at 1010069 ?
[18:43] <Daviey> bug 1010069
[18:46] <hallyn> Daviey: oops, i thought i typed that :)
[18:47] <stgraber> hallyn: no more freeze ;)
[18:48] <hallyn> oh??  i thought it was until tuesday or somehing!
[18:48] <hallyn> heh, i see :)
[18:55] <kees> seb128: can you look at bug 1010141? this is causing problems for image creation, etc.
[18:55] <seb128> kees, is that the one where I just added a comment saying to upstream it?
[18:56] <seb128> kees, it's eod for me but I will have a closer look tomorrow
[18:56] <kees> seb128: ah, whoops, sorry.
[18:57] <seb128> kees, no worry, I wouldn't be on IRC if I was done working, but it's close enough that I will look at it tomorrow not today ;-)
[18:57] <kees> seb128: heh, okay, thanks.
[18:57] <seb128> yw!
[19:14] <mhall119> YokoZar: ping
[19:20] <hippiehacker> If want to automate the creation a metapackage (https://help.ubuntu.com/community/MetaPackages#Creating_Metapackages) that includes packages from other ppas.... ie the way the google-chrome.deb adds googles own repos
[19:21] <hippiehacker> how would I get the package cache updated from the new ppas and then install the desired dependencies from those ppas (from within the metapackage)?
[20:51] <infinity> seb128: Aww, crap.  Was I meant to leave the gnome* stuff in proposed until someone had finished a libgnome-desktop transition?  Did I miss a memo?
[20:55] <infinity> popey: unity has been FTBFS for 2 weeks now.  Do you know what's being done?
[20:56] <seb128> infinity, the libgnome-desktop thing is unknown to me, what's the issue?
[20:59] <broder> ooc, did anybody look at https://github.com/twitter/zipkin ?
[20:59] <broder> seems vaguely interesting
[20:59] <broder> though presumably only if we spent a bunch of time instrumenting
[21:00] <seb128> infinity, oh, soname change, well I guess we will deal with it now that a1 is over
[21:00] <broder> oof, wrong channel, but whatever :)
[21:01] <infinity> seb128: Yeah, SOVER bump.  It's probably just a question of rebuilds for a eog, evo, and a few others.
[21:02] <infinity> seb128: Except that unity is now uninstallable, and it's FTBFS in quantal, so someone needs to get around to fixing that too. :/
[21:03] <seb128> infinity, yeah, popey's team is supposed to be on that for 2 weeks, dunno what they are doing...
[21:03] <seb128> popey, ^
[21:03] <infinity> seb128: I already pinged popey a few lines up. ;)
[21:03] <infinity> seb128: Anyhow, I can do all the !unity rebuilds, but if you guys had new versions staged or something, go ahead.
[21:03] <seb128> infinity, is there any hurry to do the rebuilds?
[21:04] <infinity> seb128: Just that people like to see beer on quantal_probs?
[21:04] <seb128> infinity, we have for sure updates coming soon so things will get rebuild in the next week
[21:04] <infinity> seb128: (And everything is uninstallable)
[21:04] <infinity> seb128: But thanks to unity being broken, fixing the rest won't help. :/
[21:04] <seb128> oh, the different sonames are no co-installable?
[21:04] <seb128> that's an issue for sure
[21:04] <seb128> why so?
[21:04] <infinity> seb128: Sure they are, but the old lib had a hard dep on the arch:all data package. :/
[21:04] <seb128> :-(
[21:05] <seb128> hate the common binaries
[21:05] <seb128> infinity, I will get it sorted tomorrow
[21:06] <infinity> seb128: For future reference, if libfooSOVER has a hard dep on libfoo-data (and maybe that's legit), you should probably version the data name too (ie: libfooSOVER-data)
[21:06] <infinity> seb128: Then nothing would have broken. :/
[21:06] <seb128> imho we should just >= on -data
[21:06] <infinity> Or that.
[21:07] <infinity> But not up to me to decide without looking if the dependency is legitimate. ;)
[21:07] <infinity> (I see no reason why it wouldn't be sane to want data from the same version)
[21:07] <seb128> well, because in practice the next version often works and it avoids such issues :p
[21:07] <infinity> Heh.
[21:08] <infinity> Well, and you'd have to version the data paths and stuff too, if you versioned the package names.
[21:08] <infinity> So, a bit messier.
[21:08] <seb128> like in this case the -data has documentation and icons
[21:08] <infinity> Anyhow.
[21:08] <seb128> and neither of those changed
[21:08] <seb128> but unity is being worked for some time
[21:08] <infinity> seb128: Given the timezone skew between me and most of the people who do unity things, can you be annoying to them tomorrow for me?
[21:08] <seb128> it got bitten by "need to migrate to new boost to build with gcc 4.7"
[21:09] <seb128> infinity, well I've been pushing them for a week, it's a bit of a mess
[21:09] <infinity> Fun.
[21:09] <seb128> infinity, unity needs to be migrated to new boost, but then it segfaults
[21:09] <seb128> so they are down to searching for toolchain regressions
[21:09] <seb128> but that's taking a bit of time
[21:10] <slangasek> is there a backtrace posted somewhere that we could throw our eyeballs at?
[21:10] <seb128> I will see if they can build with gcc4.6
[21:10] <infinity> (Time to revert to unity-2d instead?)
[21:10] <infinity> seb128: That could be the path of least resistance for now, yeah.
[21:10] <seb128> slangasek, the segfault is in nux, it's not clear it's a toolchain issue, out of the fact that the same code works on precise
[21:11] <seb128> slangasek, I will do a status update with didrocks tomorrow morning and see what solutions we have
[21:11] <slangasek> ok
[21:11] <infinity> seb128: Actually, if CC=gcc-4.6 works, I might just upload the current quantal version with that.  And they can keep working on fixing trunk.
[21:11] <infinity> seb128: I'll test locally.
[21:12]  * infinity just wants to clear up the SOVER skew oops for now.
[21:13] <infinity> seb128: And I'll get the other libgnome-desktop stragglers with rebuilds today too, you guys can just focus on your 3.5.x uploads.
[21:16] <seb128> robert_ancell, ^
[21:17] <seb128> infinity, see with robert_ancell to not dup work on rebuilding the rdepends
[21:26] <robert_ancell> infinity, let me know if you want me to help on the rebuilds
[21:34] <popey> infinity: seb128 i understood unity in quantal was building fine now?
[21:35] <seb128> popey, where is the branch?
[21:35] <seb128> popey, it didn't get uploaded for sure
[21:35] <popey> hmm
[21:36] <ScottK> seb128: Thanks.
[21:36] <popey> I'll speak to lukasz in the morning..
[21:36] <ScottK> I guess yofel took care of it.
[21:36] <seb128> ScottK, he did, thanks
[21:43] <infinity> robert_ancell: I should be able to manage; I have the technology.
[22:08] <micahg> infinity: you do realize that most of those desktop packages are managed in ~ubuntu-desktop VCS branches, right?
[22:23] <infinity> micahg: I also realise that I don't care if my changes are dropped, since they're all no-change rebuilds.
[22:24] <infinity> micahg: The extra step of comitting that to several different VCSes is busy work with no discernable win for anyone. :/
[22:24] <micahg> changelog isn't authoratative and someone might try to upload the same version again
[22:24] <infinity> "changelog isn't authoratative"?
[22:24] <micahg> doesn't have the full histroy
[22:24] <infinity> But yes, someone might try to upload the same version again.
[22:25] <infinity> And yes, the branches aren't authoritative, news at 11. :/
[22:25] <infinity> Maybe I'll go on a commit-fest later today.
[22:26] <infinity> Fixing the archive was more important that not offending people's sensibilities.
[22:29] <Bluefoxicy> I don't understand something.
[22:30] <Bluefoxicy> ~$ jigdo-lite http://cdimage.debian.org/debian-cd/6.0.5/kfreebsd-amd64/jigdo-cd/debian-6.0.5-kfreebsd-amd64-CD-1.jigdo
[22:30] <Bluefoxicy> 1: 'Debian GNU/Linux 6.0.5 "Squeeze" - Official kfreebsd-amd64 CD Binary-1 20120512-17:38 (20120512)' (debian-6.0.5-kfreebsd-amd64-CD-1.iso)
[22:31] <Bluefoxicy> The jigdo file refers to files stored on Ubuntu mirrors.
[22:31] <Bluefoxicy> ...  Ubuntu mirrors?
[22:31] <Bluefoxicy> it really does go searching through Ubuntu stuff, too.
[22:31] <Bluefoxicy> Specifically it's using the mirror list at https://launchpad.net/distros/ubuntu/+archivemirrors
[22:32] <Bluefoxicy> ... when given a Debian distribution .jigdo
[22:32] <Bluefoxicy> is this a bug or a feature?
[22:33] <infinity> If it's jigdo on Ubuntu, I'd call it a feature.  I suppose.
[22:33] <infinity> Though, no.
[22:33] <infinity> I guess more of a bug. :P
[22:33] <slangasek> "The jigdo file refers to files stored on Ubuntu mirrors. Please choose a Ubuntu mirror as follows:" <-- that's a bug
[22:34] <infinity> Since we rebuild everything, there's no chance of finding the correct files on an Ubuntu mirror.
[22:34] <slangasek> the text is wrong
[22:34] <slangasek> however, there's probably not enough information available to get it right
[22:34] <Bluefoxicy> Ubuntu mirror [http://us.archive.ubuntu.com/ubuntu/]: us
[22:34] <Bluefoxicy> http://mirror.anl.gov/pub/ubuntu/        # US United States
[22:34] <slangasek> I like this part though:
[22:34] <slangasek> Ubuntu mirror [[arch=amd64]]:
[22:35] <slangasek> misparsing sources.list ftw
[22:35] <Bluefoxicy> slangasek:  yeah I'm thinking it may be a limitation of Jigdo that it can't actually tell what's being asked for?
[22:35]  * infinity hasn't jidone in ages.
[22:35] <infinity> jigdone*
[22:36] <Bluefoxicy> Does Ubuntu even use Jigdo to distribute?
[22:36] <infinity> Bluefoxicy: We do, for alternates.
[22:36] <Bluefoxicy> like 6 releases ago there was a huge buzz about writing an even MORE advanced system that used bittorrent AND http to download chunks of ISO images in parts
[22:36] <infinity> I don't think we widely advertise that we do, but we generate the jigdo files.
[22:36] <Bluefoxicy> like it would use bittorrent, but also pick a dozen mirrors and HTTP GET with resume from an offset, download some KBs, then close the connection
[22:37] <infinity> That said, we're looking to dump the alternates anyway.
[22:37] <slangasek> infinity: or if you're from the rural midwest, "jigdid"
[22:37] <slangasek> as in "has jigdid"
[22:37] <infinity> slangasek: I ain't done jigdid nuttin' in forever.
[22:38] <Bluefoxicy> but then there was also talk about binary upgrades where if you made a 1 line change in OpenOffice.org you'd get a debian patch .deb that was only a few kilobytes, instead of redownloading 600MB of packages >:|
[22:38] <Bluefoxicy> but I still see updates that fix a Depends: or Recommends: and require re-downloading and re-installing the whole package >:|
[22:39] <Bluefoxicy> I'm assuming this is either hard or there's too many ways to do it and people can't pick one that does everything they want
[22:39] <infinity> Bluefoxicy: Some day, someone might make binary diff distribution work sanely, but I suspect that every year, well care a little less, as bandwidth increases.
[22:39] <infinity> s/well/we all/
[22:39] <Bluefoxicy> infinity:  I care a little less because I have an SSD and the changes go through faster.
[22:39] <micahg> and binary compression improves as well (transition to xz debs)
[22:40] <Bluefoxicy> That said, it still takes time for me to download 600-800 megs of stuff without an OC-48 here
[22:40] <Bluefoxicy> I mean I only get 500-800k/s
[22:42] <Bluefoxicy> anyway.  I should file a bug about that Jigdo behavior, just to put it on the record.
[22:47] <infinity> popey: Still around?
[22:55] <popey> infinity: just
[22:58] <infinity> popey: Was curious if you know the state of the nux glew1.7 transition as well.
[22:59] <infinity> popey: But I suppose I'll just assume that's happening in tandem with boost.149 and gcc-4.7
[23:00] <popey> not off the top of my head, no, will check in in my AM (8 hours)
[23:01] <infinity> popey: Mmkay.  Go sleep. :P
[23:01] <popey> ☺
[23:01] <infinity> Checking out unity crashed bzr.  SPECIAL.
[23:04] <infinity> ... reproducibly.
[23:04] <infinity> micahg: And this is why I won't be committing my unity change. :P
[23:05] <micahg> hehe
[23:37] <bdmurray> cnd: can you elaborate on bug 973297 being verification-failed?
[23:38] <cnd> bdmurray, it was failed before I reuploaded a new package
[23:38] <infinity> So, it should have been set back to needed?
[23:38] <bdmurray> cnd: so it should be verification-needed now?
[23:38] <cnd> I figured the SRU team would move it back to verification-needed after approving the new package for precise-proposed
[23:38] <cnd> yeah
[23:40] <bdmurray> okay, I updated the tags
[23:40] <bdmurray> well maybe not due to a timing out bug tracker!
[23:41] <bdmurray> okay now fixed
[23:41] <cnd> :)
[23:41] <cnd> thanks